usb gadget on zaurus and kexec

usb gadget on zaurus and kexec

[Cyril Hrubis]

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?

-- 
Cyril Hrubis

Re: usb gadget on zaurus and kexec

[Eric Miao]

On Wed, May 19, 2010 at 11:46 PM, Cyril Hrubis <metan@ucw.cz> 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.

Re: usb gadget on zaurus and kexec

[Eric Miao]

On Thu, May 20, 2010 at 1:05 PM, Eric Miao <eric.y.miao@gmail.com> wrote:
> On Wed, May 19, 2010 at 11:46 PM, Cyril Hrubis <metan@ucw.cz> 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?

Re: usb gadget on zaurus and kexec

[Marek Vasut]

Dne Čt 10. června 2010 08:10:22 Eric Miao napsal(a):
> On Thu, May 20, 2010 at 1:05 PM, Eric Miao <eric.y.miao@gmail.com> wrote:
> > On Wed, May 19, 2010 at 11:46 PM, Cyril Hrubis <metan@ucw.cz> 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
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: usb gadget on zaurus and kexec

[Robert Jarzmik]

Marek Vasut <marek.vasut@gmail.com> 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

Re: usb gadget on zaurus and kexec

[Cyril Hrubis]

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

Re: usb gadget on zaurus and kexec

[Stanislav Brabec]

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