Hi Bart, On 03/23/2018 07:30 PM, Suman Anna wrote: > Hi Bart, > > On 03/23/2018 12:16 PM, Bartosz Golaszewski wrote: >> 2018-03-23 18:08 GMT+01:00 Stephen Boyd <sboyd@xxxxxxxxxx>: >>> Quoting Bartosz Golaszewski (2018-03-23 09:55:47) >>>> 2018-03-23 17:49 GMT+01:00 Stephen Boyd <sboyd@xxxxxxxxxx>: >>>>> Quoting Bartosz Golaszewski (2018-03-23 06:04:47) >>>>>> From: Bartosz Golaszewski <bgolaszewski@xxxxxxxxxxxx> >>>>>> >>>>>> This series converts the only user of the handcoded, mach-specific reset >>>>>> routines in the davinci platform to using the reset framework. >>>>>> >>>>>> Patch 1 modifies the way lookup entries are registered with the reset >>>>>> framework. >>>>>> >>>>>> Patches 2-4 add necessary lookups/DT-properties. >>>>>> >>>>>> Patches 5-7 convert the davinci-rproc driver to the reset framework. >>>>>> >>>>>> Patch 8 removes now dead code. >>>>>> >>>>>> Philipp: it turned out that it's indeed better to use the reset >>>>>> controller's device name for the entry lookup. >>>>>> >>>>>> Tested both in DT and legacy modes by booting the examples from >>>>>> ti-ipc-rtos recipe in meta-ti. >>>>>> >>>>>> This series applies on top of David Lechner's common-clk-v9 branch[1] >>>>>> with Philipp Zabel's reset/next branch[2] pulled in. >>>>>> >>>>>> It can be found in my github tree as well[3]. >>>>>> >>>>> >>>>> What's the merge strategy for the rest of the patches? I should apply >>>>> the clk ones after the next -rc1? >>>> >>>> Or maybe Philipp can provide us with an immutable branch with the reset patches? >>>> >>>> The you could apply the driver patches and let Sekhar take all the >>>> platform code? >>>> >>> >>> Ok that could work too. >> >> Ohad, Bjorn can you ack the remoteproc patches? Are you OK with >> Stephen taking them through the clock tree? Otherwise it would get >> complicated since they depend on the first clk patch and the last clk >> patch depends on them. > > I will take a closer look and test on Mon. A quick glance of the > remoteproc changes seem to be fine. I will let Bjorn comment on the > patch flow. > > The only reason I had to use the clock in the driver was for the reset > before, and hopefully this will allow me to actually switch to using > pm_runtime API like I do with the rest of the TI remoteproc drivers > (Keystone remoteproc driver also uses PSC for clock and reset but then > it goes through different set of drivers). > > So, I see a mix of driver and dts patches in the series, are all the dts > patches coming through Sekhar? I tried booting your tree [3] on the OMAPL138-LCDK board. I am using NFS, and I am unable to get to the console. I don't have any issues booting latest -next branch (next-20180326) which only has the reset and clock driver related changes. Here's the log towards the end of the boot.. --- pinctrl-single 1c14120.pinmux: 160 pins, size 80 Serial: 8250/16550 driver, 3 ports, IRQ sharing disabled console [ttyS2] disabled 1d0d000.serial: ttyS2 at MMIO 0x1d0d000 (irq = 61, base_baud = 8250000) is a TI DA8xx/66AK2x console [ttyS2] enabled brd: module loaded libphy: Fixed MDIO Bus: probed davinci_mdio 1e24000.mdio: davinci mdio revision 1.5, bus freq 2200000 davinci_mdio 1e24000.mdio: no live phy, scanning all davinci_mdio: probe of 1e24000.mdio failed with error -5 i2c /dev entries driver <nothing after this> regards Suman > > regards > Suman > >> >> Thanks, >> Bart >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-remoteproc" in >> the body of a message to majordomo@xxxxxxxxxxxxxxx >> More majordomo info at http://vger.kernel.org/majordomo-info.html >> > > -- > To unsubscribe from this list: send the line "unsubscribe linux-remoteproc" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
