On Mon, 23 Mar 2009, Zoltan Devai wrote: > Here's some followup: > > 2009/3/21 Zoltan Devai <zdevai@xxxxxxxxx>: > > I'm using an embedded system (IXP42x) with an ISP1563 HC, > > with kernel 2.6.29-rc6. > > When only the OHCI driver is loaded, the storage driver does not > > recognise an attached high-speed or full-speed MSC device. > > The problem really seems to be that after the short read, the next urbs > TD is completed with cc 3, Which means Data Toggle Mismatch, right? > but the HC doesn't generate any interrupt, > so nothing happens until the storage driver cancels the request after > 30 seconds. > > With this patch, everything goes well, but I doubt this is the correct > way to solve it. > > --- ohci-q.c.orig 2009-02-23 05:19:40.000000000 +0100 > +++ ohci-q.c 2009-03-23 11:25:25.000000000 +0100 > @@ -795,6 +795,8 @@ > wmb (); > ed->hwHeadP &= ~cpu_to_hc32 (ohci, ED_H); > > + ed->hwHeadP ^= cpu_to_hc32 (ohci, ED_C); > + > /* Get rid of all later tds from this urb. We don't have > * to be careful: no errors and nothing was transferred. > * Also patch the ed so it looks as if those tds completed normally. This certainly isn't the right way to fix the problem, because a little farther down the driver conditionally overwrites ed->hwHeadP anyway. > Is it the HCs fault that is requires toggling of ED_C after the short read ? > Do other HCs do it automatically, or simply don't require it ? If other HCs didn't work right with this code, we would have known many years ago. So it probably is the fault of your HC. To find out whether your HC really is at fault you would need to know the actual toggle values before and after the short read. > Isn't the HC supposed to give an (WDH?) interrupt regardless of the cc ? Let's put it this way: The HC is supposed to give a WDH interrupt whenever HccaDoneHead is updated, regardless of the cc. But in your case HccaDoneHead _wasn't_ updated, since bulk queues don't advance when there's a toggle mismatch. > Anyway, with this patch applied, data transfer still fails after some point > with TDs returning cc 8. You know, it would helpful if you would include information like the fact that cc = 8 means Data Overrun so that your readers don't have to get out the OHCI spec and look it up for themselves. In fact, you could just write "TDs returning Data Overrun" -- the actual cc value is unimportant. > The EHCI controller seems to show similar problems, but I haven't > debugged that yet. > So, a more general question: Has anybody been using the ISP1563 > with Linux ? I don't know of anybody. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
