| Message ID | 20130106033455.GH1357@kw.sim.vm.gnt (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Sun, Jan 06, 2013 at 04:34:55AM +0100, Simon Guinot wrote: > Hi Andrew and Jason, > > While testing 3.8-rc2 on the ns2 boards (DT based), I noticed that > reboot is not working. After issuing a reboot, the kernel hangs. No > error messages are displayed. Moreover, on my non-DT Kirkwood boards, > reboot is working as expected. > > Am I the only one to experiment this issue ? Hi Simon No you are not the only one. There is a patch available, authored by me, which is identical to what you found. We have been a bit slow recently pushing fixes into 3.8-rc, vacations, etc. I plan to spend some time today collecting the fixes together and sending them upstream. Andrew
On Sun, Jan 06, 2013 at 09:35:21AM +0100, Andrew Lunn wrote: > On Sun, Jan 06, 2013 at 04:34:55AM +0100, Simon Guinot wrote: > > Hi Andrew and Jason, > > > > While testing 3.8-rc2 on the ns2 boards (DT based), I noticed that > > reboot is not working. After issuing a reboot, the kernel hangs. No > > error messages are displayed. Moreover, on my non-DT Kirkwood boards, > > reboot is working as expected. > > > > Am I the only one to experiment this issue ? > > Hi Simon > > No you are not the only one. There is a patch available, authored by > me, which is identical to what you found. Arf, it's a shame I have missed this reports. It could have spared some time by asking at you earlier. About the issue itself. I understand that a clock is needed by the orion-ehci driver. But even if the clock is not provided by the DT, it should have been fixed by kirkwood_legacy_clk_init(), isn't ? What's wrong with this workaround ? Simon
On Mon, Jan 07, 2013 at 04:09:18PM +0100, Simon Guinot wrote: > On Sun, Jan 06, 2013 at 09:35:21AM +0100, Andrew Lunn wrote: > > On Sun, Jan 06, 2013 at 04:34:55AM +0100, Simon Guinot wrote: > > > Hi Andrew and Jason, > > > > > > While testing 3.8-rc2 on the ns2 boards (DT based), I noticed that > > > reboot is not working. After issuing a reboot, the kernel hangs. No > > > error messages are displayed. Moreover, on my non-DT Kirkwood boards, > > > reboot is working as expected. > > > > > > Am I the only one to experiment this issue ? > > > > Hi Simon > > > > No you are not the only one. There is a patch available, authored by > > me, which is identical to what you found. > > Arf, it's a shame I have missed this reports. It could have spared some > time by asking at you earlier. Hi Simon Its often worth asking, or at least googling, before heading into a git bisect. > About the issue itself. I understand that a clock is needed by the > orion-ehci driver. But even if the clock is not provided by the DT, it > should have been fixed by kirkwood_legacy_clk_init(), isn't ? What's > wrong with this workaround ? kirkwood_legacy_clk_init() provides a clock with the old name. When using DT, the device has the name "f1050000.ehci" and it looks for a clock called "f1050000.ehci ". The legacy clock is called "orion-ehci.0", which is what is expected when using old style platform drivers instantiated in C. Andrew
On Mon, Jan 07, 2013 at 04:25:10PM +0100, Andrew Lunn wrote: > On Mon, Jan 07, 2013 at 04:09:18PM +0100, Simon Guinot wrote: > > On Sun, Jan 06, 2013 at 09:35:21AM +0100, Andrew Lunn wrote: > > > On Sun, Jan 06, 2013 at 04:34:55AM +0100, Simon Guinot wrote: > > > > Hi Andrew and Jason, > > > > > > > > While testing 3.8-rc2 on the ns2 boards (DT based), I noticed that > > > > reboot is not working. After issuing a reboot, the kernel hangs. No > > > > error messages are displayed. Moreover, on my non-DT Kirkwood boards, > > > > reboot is working as expected. > > > > > > > > Am I the only one to experiment this issue ? > > > > > > Hi Simon > > > > > > No you are not the only one. There is a patch available, authored by > > > me, which is identical to what you found. > > > > Arf, it's a shame I have missed this reports. It could have spared some > > time by asking at you earlier. > > Hi Simon > > Its often worth asking, or at least googling, before heading into a > git bisect. > > > About the issue itself. I understand that a clock is needed by the > > orion-ehci driver. But even if the clock is not provided by the DT, it > > should have been fixed by kirkwood_legacy_clk_init(), isn't ? What's > > wrong with this workaround ? > > kirkwood_legacy_clk_init() provides a clock with the old name. When > using DT, the device has the name "f1050000.ehci" and it looks for a > clock called "f1050000.ehci ". The legacy clock is called > "orion-ehci.0", which is what is expected when using old style > platform drivers instantiated in C. OK, I get it. Thanks for the explanation. Simon
diff --git a/arch/arm/boot/dts/kirkwood.dtsi b/arch/arm/boot/dts/kirkwood.dtsi index 7735cee..110d6cb 100644 --- a/arch/arm/boot/dts/kirkwood.dtsi +++ b/arch/arm/boot/dts/kirkwood.dtsi @@ -144,6 +144,7 @@ compatible = "marvell,orion-ehci"; reg = <0x50000 0x1000>; interrupts = <19>; + clocks = <&gate_clk 3>; status = "okay"; };