James McMechan wrote:
>>It's just an issue of UML not wanting to honor a traditional hack ... :)
>
> Not so much, not honoring, as I was thinking that the traditional hack
> should be made generic?
In 2.5, the way such stuff gets made generic is to evolve it into the
generic device/driver model ... :)
> If both UML and ARM need nearly identical hacks why not share?
That's a good basic direction, though the details matter. And it's worth
pointing out that the SA-1111 support doesn't _need_ anything, it works
already as-is. I pointed out that it could work a bit better, if someone
found an appropriate way to factor/package things.
> And it appears, to me at least, that both need it for the same reason.
> To wit, the USB midlayer setting up DMA rather the leaving that to the HCD
> in this case.
Actually the HCD _does_ set it up, you're misreading the layering.
- Today, the "usb core" is mostly a "usb master" library, including
hub driver, that manages the host side of device enumeration
(including device and config descriptors) as well as providing
a framework for device drivers.
- It talks to HCDs using "struct usb_bus", which is so painfully
thin that every 2.4 HCD re-invented some basic/core logic ... in
different ways, causing lots of HCD-specific bugs/behaviors.
- Yours truly started to do the EHCI driver and couldn't stomach
the notion of making that situation inevitably worse, so the
more sharable parts of the HCD logic got stripped out into
"struct hcd_driver" (and "struct usb_hcd"). Lately I've been
characterizing that as the "sharable and hardware-independant"
part of those HCDs. It still talks to usbcore with usb_bus.
- So now in 2.5 the HCDs are mostly (but not entirely, there's
the sl811hs and cris stuff) shrunk, using that sharable logic.
Which, as of a bit earlier in the 2.5.3x series, includes
managing the DMA memory ... letting usb device drivers help
out when naive approaches are sub-optimal.
That is, that upper level of HCD code is linked into usbcore but
is still logically separate. You _could_ write a 2.4-style HCD
and do those DMA bits yourself. (I'd encourage you not to do so.)
Linkage != layering.
Is that the perfect/ideal setup? Certainly not. Factoring for
better support of non-PCI HCDs is just one issue. And I confess
I was a bit surprised to see such a simple solution for SA-1111,
since I'd thought more work "generalizing" non-PCI drivers was
going to be necessary ... longer term, it still seems to be.
Also, I'd be happier if we had the device side ("gadget")
APIs further along. Both should be using the same URBs, the
same submit/unlink/complete model ... with the split pretty
much right there at "usb_bus". In one case the requests would
go to some HCD, that multiplexes devices, schedules periodic
traffic, and "knows" how to talk to the hub driver. In the
other, requests would go more directly to hardware, and rely
on the host to do everything except actually send/receive data.
(And "slave" drivers would look at control requests differently
too ... responding to requests, needing a two-phase API.)
- Dave
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
