For some reason this was rejected earlier..
> >>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.
>
Actually, I was trying to generalize the way the arm arch already did it
with the arch/arm/mach-sa1100/pcipool.c see the comments in pcipool.c as it
was added for the ohci case.
As for working as is: So did the uml-hcd, I was trying to forward port it
from 2.4.0-test6 when it was last updated, by Johan Verrept.
It seemed to work 2.4.18, 2.4.19 was harder and 2.5.36 is still giving me
problems, I seem to remember it working around 2.5.31
>
> > 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.
>
Not DMA setup itself but allocation buffers for DMA and yes that may be part
of the HCD that has moved up to the common layer, but it has moved to the
common layer
> - 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.
Not so much linkage but that the usb core now includes references to the
pci_pool functions and seems to assume that everything is now PCI, the
execption appearing to be, the arm arch where a mem pool interface was
created seemingly for usb see the comments in arch/arm/mach-sa1100/pcipool.c
>
> 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.)
>
About the gadget, looks like it could take advantage of a usb loopback
interface-> that would take the urb and send it back to (I guess) a Target
Controller Driver and the TCD would feed the incomming
Control/Bulk/Interrupt/Isochronous up to the drivers with everything going
in pretty much the other direction since the target side acts as a dumb
slave to the host side, or so it appears.
By the way submit/unlink/complete is HCD side I would expect a
catch?/unlink/reply?/complete paradime on the TCD side.
Was that what you ment by the two phase API?
> - Dave
>
By the way I found these comments quite helpful you might want to put them
up somewhere for expansion.
-------------------------------------------------------
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
