On Thu, May 20, 2010 at 1:05 PM, Eric Miao <[email protected]> wrote:
> On Wed, May 19, 2010 at 11:46 PM, Cyril Hrubis <[email protected]> wrote:
>> Hi!
>> After some testing I found out that no usb gadget (g_ether, g_mass_storage, ...)
>> is working after zaurus boots with kexec. So it seems like some missing
>> initalization (it's working after doing reboot again) anybody has any clue,
>> patch or ideas how to debug this?
>>
>
> Dumping out the registers of the two situations and doing a comparison then
> might be a quick way.
>
Any debugging update on this?
Dne Čt 10. června 2010 08:10:22 Eric Miao napsal(a):
> On Thu, May 20, 2010 at 1:05 PM, Eric Miao <[email protected]> wrote:
> > On Wed, May 19, 2010 at 11:46 PM, Cyril Hrubis <[email protected]> wrote:
> >> Hi!
> >> After some testing I found out that no usb gadget (g_ether,
> >> g_mass_storage, ...) is working after zaurus boots with kexec. So it
> >> seems like some missing initalization (it's working after doing reboot
> >> again) anybody has any clue, patch or ideas how to debug this?
> >
> > Dumping out the registers of the two situations and doing a comparison
> > then might be a quick way.
>
> Any debugging update on this?
Yeah, there's a workaround. Cyril's working on a proper fix, but that might take
some time. Simply -- UP2OCR is misconfigured.
>
> _______________________________________________
> linux-arm-kernel mailing list
> [email protected]
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Marek Vasut <[email protected]> writes:
>> > Dumping out the registers of the two situations and doing a comparison
>> > then might be a quick way.
>>
>> Any debugging update on this?
>
> Yeah, there's a workaround. Cyril's working on a proper fix, but that might take
> some time. Simply -- UP2OCR is misconfigured.
That's quite interesting. In the pxa27x_udc gadget driver, I seem to have a
regression on the resume from suspend to RAM path. My USB UDC is not enumerated
anymore.
The might be a correlation, as UP2OCR is lost in the suspend process. I'm very
interested by your analysis of the issue you have on kexec, as that might ease
my work :)
Besides, it's been some time I've been thinking that the pxa deserves a proper
encapsulation of the USB internal routing paths (ie. a proper way to switch from
usb host handled by ohci-pxa27x to an usb client handled by pxa2x_udc), to
reflect the setup of the Pad Unit (see TRM chapter 12.4 : tables 12.2, 12.15,
12.17, 12.18 and 12.19).
Whatever you find on the USB Port2 configuration register would help me design
the Pad block.
Cheers.
--
Robert
Hi!
> >> > Dumping out the registers of the two situations and doing a comparison
> >> > then might be a quick way.
> >>
> >> Any debugging update on this?
> >
> > Yeah, there's a workaround. Cyril's working on a proper fix, but that might take
> > some time. Simply -- UP2OCR is misconfigured.
>
> That's quite interesting. In the pxa27x_udc gadget driver, I seem to have a
> regression on the resume from suspend to RAM path. My USB UDC is not enumerated
> anymore.
>
>
> The might be a correlation, as UP2OCR is lost in the suspend process. I'm very
> interested by your analysis of the issue you have on kexec, as that might ease
> my work :)
Well it seems, at least for spitz that UP2OCR is set to host at the
initialization and not touched anymore (spitz.c). I guess that the OE kernel,
that is flashed in my spitz, changes UP2OCR when gadget/host driver is loaded
but this doesn't work in vanilla kernels for some time. That would clarify why
gadgets doesn't work after kexec at least for me.
> Besides, it's been some time I've been thinking that the pxa deserves a proper
> encapsulation of the USB internal routing paths (ie. a proper way to switch from
> usb host handled by ohci-pxa27x to an usb client handled by pxa2x_udc), to
> reflect the setup of the Pad Unit (see TRM chapter 12.4 : tables 12.2, 12.15,
> 12.17, 12.18 and 12.19).
>
> Whatever you find on the USB Port2 configuration register would help me design
> the Pad block.
>
Would be great. So far the GPIO for usb host/slave cable detection is not used
on spitz so there is no way to switch to USB slave for gadgets to work if you
don't want to play with devmem2.
There is some otg code in drivers/usb/otg/ but I haven't time to look on that yet.
--
metan
Cyril Hrubis wrote:
> Would be great. So far the GPIO for usb host/slave cable detection is not used
> on spitz so there is no way to switch to USB slave for gadgets to work if you
> don't want to play with devmem2.
Well, just the driver is missing, the hardware is there. See attached
usb-auto script using pxaregs utility.
There is another issue in the gadget mode (probably including the latest
kernels): If host mode is not active, it should turn USB power off. It
does not, and it causes soft short circuit in client mode. It also makes
impossible to differentiate between no cable and client cable.
Here are GPIOs to control OTG:
SPITZ_GPIO_USB_DEVICE GPIO35 USB Client power is present
SPITZ_GPIO_USB_HOST GPIO37 USB OTG 5V Host power supply control
SPITZ_GPIO_USB_CONNECT GPIO41 USB Host Cable is connected
----------- usb-auto ----------
#!/bin/sh
if test -z "$CLIENT_MODULE" ; then
# Uncomment client module you want by default (only one at a time is possible in 2.6.26RP):
CLIENT_MODULE=g_ether
#CLIENT_MODULE=g_file_storage
fi
if test `pxaregs GPLR1_41 | sed -n 's/.*\(.\) GPIO.*/\1/p'` = 0 ; then
echo "Host cable is present."
pxaregs GPSR1_37 1 # Turn on USB power
rmmod g_file_storage g_ether pxa27x_udc 2>/dev/null
sleep 1
modprobe ohci-hcd 2>/dev/null
else
pxaregs GPCR1_37 1 # Turn off USB power
sleep 1 # Wait a bit to discharge capacitors
if test `pxaregs GPLR1_35 | sed -n 's/.*\(.\) GPIO.*/\1/p'` = 0 ; then
echo "No cable in USB."
ifdown usb0 2>/dev/null
sleep 1
rmmod g_file_storage g_ether pxa27x_udc 2>/dev/null
sleep 1
rmmod ohci-hcd 2>/dev/null
else
echo "Client cable is present."
rmmod ohci-hcd 2>/dev/null
sleep 1
modprobe pxa27x_udc
modprobe $CLIENT_MODULE
ifup usb0 2>/dev/null
fi
fi
-------------------------------
--
Stanislav Brabec
http://www.penguin.cz/~utx/zaurus