Re: USB Host port inoperative after kexec on Beagleboard
On Mon, Jan 09, 2012 at 10:54:03PM +, Will Deacon wrote:
> On Mon, Jan 09, 2012 at 10:09:54PM +, Peter Chubb wrote:
> >
> > Hi Will,
>
> Hi Peter [adding linux-arm-kernel],
*Actually* adding linux-arm-kernel this time...
>
> >Thanks for the fixes to kexec for ARM that went into mainline this
> >week. Mostly things work now.
>
> Great, that's good to hear!
>
> >One issue: the USB EHCI port on the (rev C2) beagleboard doesn't
> >work after a kexec. During boot after kexec, the host device is
> >detected and initialised, but nothing plugged in works, even when
> >everything was working corectly before the kexec. Das U-boot
> >must set up something that is then undone during the kexec reboot.
>
> Ouch. Have you had a chance to look at the u-boot sources to see what it
> does?
>
> >I've traced all calls to clk_enable() and clk_disable(), and
> >everything looks all right --- in particular I can't see
> >anything explicitly disabled during kexec that isn't reenabled
> >during boot of the subsequent kernel.
> >
> >Voltages that I can measure look correct on the port.
> >
> >Do you have any suggestions as to what else could be wrong?
>
> I'm afraid I'm not familiar with the Beagleboard, so I can't begin to guess.
> Have you tried re-initialising the host controller in the new kernel
> manually (perhaps my building the driver as a module and {un}loading it a
> few times?). It could be that some hardware state persists across the kexec
> and it just needs resetting.
>
> Will
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: USB Host port inoperative after kexec on Beagleboard
On Mon, Jan 09, 2012 at 10:09:54PM +, Peter Chubb wrote:
>
> Hi Will,
Hi Peter [adding linux-arm-kernel],
>Thanks for the fixes to kexec for ARM that went into mainline this
>week. Mostly things work now.
Great, that's good to hear!
>One issue: the USB EHCI port on the (rev C2) beagleboard doesn't
>work after a kexec. During boot after kexec, the host device is
>detected and initialised, but nothing plugged in works, even when
>everything was working corectly before the kexec. Das U-boot
>must set up something that is then undone during the kexec reboot.
Ouch. Have you had a chance to look at the u-boot sources to see what it
does?
>I've traced all calls to clk_enable() and clk_disable(), and
>everything looks all right --- in particular I can't see
>anything explicitly disabled during kexec that isn't reenabled
>during boot of the subsequent kernel.
>
>Voltages that I can measure look correct on the port.
>
>Do you have any suggestions as to what else could be wrong?
I'm afraid I'm not familiar with the Beagleboard, so I can't begin to guess.
Have you tried re-initialising the host controller in the new kernel
manually (perhaps my building the driver as a module and {un}loading it a
few times?). It could be that some hardware state persists across the kexec
and it just needs resetting.
Will
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
USB Host port inoperative after kexec on Beagleboard
Hi Will, Thanks for the fixes to kexec for ARM that went into mainline this week. Mostly things work now. One issue: the USB EHCI port on the (rev C2) beagleboard doesn't work after a kexec. During boot after kexec, the host device is detected and initialised, but nothing plugged in works, even when everything was working corectly before the kexec. Das U-boot must set up something that is then undone during the kexec reboot. I've traced all calls to clk_enable() and clk_disable(), and everything looks all right --- in particular I can't see anything explicitly disabled during kexec that isn't reenabled during boot of the subsequent kernel. Voltages that I can measure look correct on the port. Do you have any suggestions as to what else could be wrong? -- Dr Peter Chubb http://www.gelato.unsw.edu.au peterc AT gelato.unsw.edu.au http://www.ertos.nicta.com.au ERTOS within National ICT Australia -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
