Hi David,
Thanks for the hint.
- The first is about the get_frame_number. I see that the 'glue' driver can provide a function to read this value and that's good news for me because there is an errata for this chips that specify the red value should be corrected. However, there are two places in the code where the OHCI_FRAME_NO(ohci->hcca) macro is called instead of hcd->driver->get_frame_number(hcd), on line 248 & 626 of ohci-hcd.
I actually count six references ("grep"), not two; in iso scheduling and urb unlinking, not fast paths. Easy enough to fix ... though I'd say to avoid calling usb_bus operations. Just define an OHCI routine that optionally applies that quirk, and call it everywhere the frame number is needed (including from that usb_bus operation).
Why avoid calling usb_bus operation ?
Because re-traversing those layers is just pointless waste.
What you mean by 'define an OHCI routine' is use macro each time, like changing the OHCI_FRAME_NO ? Because what I'd need to use
the same driver for a OHCI on PCI (no quirk) and for the OnChip one (with quirk).
I mean something like
static unsigned ohci_frame_number(struct ohci_hcd *) { ... }
- The other problems is that this chip is Big Endian ( power pc ) and that all it's internal registers including the OHCI ones are big endian ... And that's a bigger problem. The 2.4 port for this processor just uses #ifdef #define ... to override any call to cpu_to_le16 or such function when needed. However I don't want that solution because I have another OHCI controler on the PCI bus that requires those ... So what should I do ?
The register reads should always give results in native byte order, even across PCI. I'm not sure what you're saying here ... that driver mostly needs byteswapping for the in-memory data structures (TD, ED).
Yes indeed, I have misunderstood the problem. For each access to the ohci io/mapped registers, the access is thru writel/readl ( as it should be ). But in my asm/io.h, readl is defined as little endian ( cpu_to_le32 and so ). That is OK for PCI but not for the onchip
Huh, I thought those were guaranteed to return values in native byte order on PCI ... something seems screwey there, it's not as if any PCI device will treat bit 0 in its registers as MSB or LSB depending on what kind of host you've got.
controller, and if I change it to use big endian, then all the PCI are gonna fail. So I guess I have to solutions :
- Duplicate all the OHCI code, one with for PCI in LE, the other for Onchip in BE.
- At each readl/writel, check is a certain flag is set and use the good one.
There's going to be an ohci_readl() to handle that one SHARP controller erratum ... that'd be a fair place to hid this kind of thing. You'd have to add an ohci_writel() too.
Thing is, I didn't think that readl()/writel() was supposed to be bus-specific.
But there seem to be another problem than the readl/writel issue. Ive modified them to have the correct endianness and now I have this message at boot :
usb 1-1: control timeout on ep0out
mpc5xxx_ohci 03: Unlink after no-IRQ? Different ACPI or APIC settings may help.
And the USB interrupt is triggered somthing like 2000 times a sec.
The "no-IRQ" might be because your IRQ handler doesn't look enough like usb_hcd_irq(), which sets that flag as appropriate. That may also trigger the 2000/sec rate.
That control timeout message isn't necessarily a problem, if it only happens a few times and things basically work.
- Dave
------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
