USB on AU1550

I'm trying to get USB working on my AU1550 board, and I'm getting an error I don't understand. I've searched the web and the mailing list archives, but haven't found anything relevant.

I'm using 2.6.12, in big-endian mode.

After the kernel comes up, I plug in a USB flash drive and get this on the console:

    au1xxx-ohci au1xxx-ohci.0: GetStatus roothub.portstatus [1] = 0x00010101 CSC
PPS CCS
    hub 1-0:1.0: port 2, status 0101, change 0001, 12 Mb/s
    hub 1-0:1.0: debounce: port 2: total 100ms stable 100ms status 0x101
    au1xxx-ohci au1xxx-ohci.0: GetStatus roothub.portstatus [1] = 0x00100103

PRSC PPS PES CCS
usb 1-2: new full speed USB device using au1xxx-ohci and address 2 au1xxx-ohci au1xxx-ohci.0: Unlink after no-IRQ? Controller is probably
using the wrong IRQ.

This is the comment in the code before that printk():

	/* IRQ setup can easily be broken so that USB controllers
	 * never get completion IRQs ... maybe even the ones we need to
	 * finish unlinking the initial failed usb_set_address()
	 * or device descriptor fetch.
	 */
	if (!hcd->saw_irq && hcd->self.root_hub != urb->dev) {
		dev_warn (hcd->self.controller, "Unlink after no-IRQ?  "
			"Controller is probably using the wrong IRQ."
			"\n");
		hcd->saw_irq = 1;
	}

When I get here in the code, hcd->saw_irq is 0, and it looks like this function (hcd_unlink_urb()) is getting called from run_timer_softirq(), so I guess I'm not getting the interrupt. However, immediately after returning, usb_hcd_irq() does get called. As far as I can tell, the interrupt gets serviced as soon as hcd_unlink_urb returns.

It looks like the timer function causing this is timeout_kill(), initialized in usb_start_wait_urb() which has this comment:

	// Starts urb and waits for completion or timeout
	// note that this call is NOT interruptible, while
	// many device driver i/o requests should be interruptible

Can anyone point me in the right direction to get this working?

Thanks.

Hi

Not the answer to you question, but I have some problems with USB on AU1200 board too. I use AirStar2 USB card (this is DVB-T card) and it is recognized by AU1200 and can communicate with it. I can tune to transporder, but the data (transport stream) is not send from the USB card.
The card conforms to USB 1.1.
I tried it on a PC running Linux and it works fine.

AU1200 kernel: 2.6.11, PC kernel: 2.6.13.2.

Any thoughts?

BR,
Matej

P.S.: This is the log:
----------------------------------------------------------------------------------
flexcop_usb: running at FULL speed.
DVB: registering new adapter (FlexCop Digital TV device). f010
b2c2-flexcop: MAC address = <DELETED>
b2c2-flexcop: found the mt352 at i2c address: 0x0f
DVB: registering frontend 0 (Zarlink MT352 DVB-T)...
b2c2-flexcop: initialization of 'Air2PC/AirStar 2 DVB-T' at the 'USB' bus controlled by a 'FlexCopIII' complete
creating 4 iso-urbs with 4 frames each of 1023 bytes size = 16368. initializing and submitting urb no. 0 (buf_offset: 0).
urb no: 0, frame: 0, frame_offset: 0
urb no: 0, frame: 1, frame_offset: 1023
urb no: 0, frame: 2, frame_offset: 2046
urb no: 0, frame: 3, frame_offset: 3069
submitted urb no. 0.
initializing and submitting urb no. 1 (buf_offset: 4092). urb no: 1, frame: 0, frame_offset: 0
urb no: 1, frame: 1, frame_offset: 1023
urb no: 1, frame: 2, frame_offset: 2046
urb no: 1, frame: 3, frame_offset: 3069
submitted urb no. 1.
initializing and submitting urb no. 2 (buf_offset: 8184). urb no: 2, frame: 0, frame_offset: 0
urb no: 2, frame: 1, frame_offset: 1023
urb no: 2, frame: 2, frame_offset: 2046
urb no: 2, frame: 3, frame_offset: 3069
submitted urb no. 2.
initializing and submitting urb no. 3 (buf_offset: 12276). urb no: 3, frame: 0, frame_offset: 0
urb no: 3, frame: 1, frame_offset: 1023
urb no: 3, frame: 2, frame_offset: 2046
urb no: 3, frame: 3, frame_offset: 3069
submitted urb no. 3.
flexcop_usb: Technisat/B2C2 FlexCop II/IIb/III Digital TV USB Driver successfully initialized and connected.
usbcore: registered new driver b2c2_flexcop_usb
----------------------------------------------------------------------------------

hello,

there was a post of mine, dating back to 22 Nov 2004 which could have been relevant to your cause :-)

[..]

don't know whether you still require being pointed in to any direction; however, the following patch (against current GIT HEAD, works for me, YMMV :-) might provide a hint:

index ed1899d..914b964 100644
@@ -100,12 +100,14 @@ config USB_OHCI_HCD_PCI
 config USB_OHCI_BIG_ENDIAN
 	bool
 	depends on USB_OHCI_HCD
+	default y if SOC_AU1X00 && CPU_BIG_ENDIAN
 	default n
 
 config USB_OHCI_LITTLE_ENDIAN
 	bool
 	depends on USB_OHCI_HCD
 	default n if STB03xxx || PPC_MPC52xx
+	default n if SOC_AU1X00 && CPU_BIG_ENDIAN
 	default y
 
 config USB_UHCI_HCD

index caacf14..bf18351 100644
@@ -462,6 +462,11 @@ static inline struct usb_hcd *ohci_to_hc
 #define writel_be(val, addr)	out_be32((__force unsigned *)addr, val)
 #endif
 
+#if defined(CONFIG_SOC_AU1X00)
+#define readl_be(addr)          __raw_readl((__force u32 *)(addr))
+#define writel_be(val, addr)    __raw_writel(val, (__force u32 *)(addr))
+#endif
+
 static inline unsigned int ohci_readl (const struct ohci_hcd *ohci,
 							__hc32 __iomem * regs)
 {

greetings,

Herbert Valerio Riedel <[email protected]>
GnuPG Key Fingerprint: 7BB9 2D6C D485 CE64 4748  5F65 4981 E064 883F 4142

Maybe it's already in the code but That patch also activates the OHCI_BIG_ENDIAN flag in the struct ohci_hcd. If not big endian mode will be choosed only if USB_OHCI_LITTLE_ENDIAN is not selected as well (both can be selected at once and if they are, it's that plag in the hcd sruct that selects what to use)

Sylvain