> > Now I'm not following _you_ ... could you give an example of
> > what you mean?
>
> A driver on a 64bit system with a 32bit host controller, if the system
> has more than 4GB of RAM.
By the time such systems become problematic, I'd expect hardware
vendors would be phasing out such 32bit I/O controllers. Remember
they're mostly integrated on motherboards.
Simple fix: instead of a combined EHCI+{O,U}HCI controller, use
EHCI with a USB 2.0 hub chip. Same number of motherboard USB
connectors, same full/low/high speed flexibility, but only using one
64bit controller. (Assuming an EHCI implementing that option! :)
> > In my proposal, device drivers would be able to either use
> > the current rules (which they do already, so no problem :)
> > OR (new) specify highmem buffers by {page+offset, length}.
>
> I am not convinced that the current rules will remain OK.
If they don't remain OK, then USB won't be the only subsystem to
need PCI-related surgery. Best to have them all use the same kind
of operation, so either everyone gets three arms or nobody does.
> At present AFAIK GFP_KERNEL will allocate memory the PCI layer can deal
> with. Now I might be wrong but "dealing with" could be quite expensive.
> In fact on a 64bit system without an IO-MMU it might mean a physical copy.
> Even with an IO-MMU there might be a default setting that's cheaper to
> use.
>
> So either we restrict the drivers in many cases needlessly to a subset
> of memory or we waste performance.
That's not fundamentally "our" call, given that such a potential restriction
would apply to every device driver that ever talks through PCI. Which is
to say, almost everything on current systems. (Subject to change in a
few years, with higher speed serial busses like HyperChannel.)
On the other hand, I have a hard time seeing a "low 4 GBytes" kind
of allocation restriction being a real problem any time soon, or seeing
it become a problem without a new generation of I/O hardware in place
to alleviate such headaches ... :)
- Dave
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
