Re: [linux-usb-devel] Re: SLAB vs. pci_alloc_xxx in usb-uhci patch [RFC: API]

2001-03-09 Thread Pete Zaitcev
> Date: Fri, 09 Mar 2001 13:14:03 -0800 > From: David Brownell <[EMAIL PROTECTED]> >[...] > It feels to me like you're being inconsistent here, objecting > to a library API for some functionality (mapping) yet not for > any of the other functionality (alignment, small size, poisoning > and so on)

Re: [linux-usb-devel] Re: SLAB vs. pci_alloc_xxx in usb-uhci patch [RFC: API]

2001-03-09 Thread Alan Cox
> I wonder if it may be feasible to allocate a bunch of contiguous > pages. Then, whenever the hardware returns a bus address, subtract > the remembered bus address of the zone start, add the offset to > the virtual and voila. Even if not you can hash by page number not low bits so the hash is wa

Re: [linux-usb-devel] Re: SLAB vs. pci_alloc_xxx in usb-uhci patch[RFC: API]

2001-03-09 Thread David Brownell
> > Given that some hardware must return the dma addresses, why > > should it be a good thing to have an API that doesn't expose > > the notion of a reverse mapping? At this level -- not the lower > > level code touching hardware PTEs. > > Because its' _very_ expensive on certain machines.

Re: [linux-usb-devel] Re: SLAB vs. pci_alloc_xxx in usb-uhci patch[RFC: API]

2001-03-09 Thread David S. Miller
David Brownell writes: > Given that some hardware must return the dma addresses, why > should it be a good thing to have an API that doesn't expose > the notion of a reverse mapping? At this level -- not the lower > level code touching hardware PTEs. Because its' _very_ expensive on certain

Re: [linux-usb-devel] Re: SLAB vs. pci_alloc_xxx in usb-uhci patch[RFC: API]

2001-03-09 Thread David Brownell
> > > Do lots of drivers need the reverse mapping? It wasn't on my todo list > > > yet. > > > > I am against any API which provides this. It can be extremely > > expensive to do this on some architectures, The implementation I posted needed no architecture-specific knowledge. If cost is the

Re: [linux-usb-devel] Re: SLAB vs. pci_alloc_xxx in usb-uhci patch [RFC: API]

2001-03-09 Thread Alan Cox
> Drivers can keep track of this kind of information themselves, > and that is what I tell every driver author to do who complains > of a lack of a "bus_to_virt()" type thing, it's just lazy > programming. I'd agree. There are _good_ reasons for having reverse mappings especially on certain archi

Re: [linux-usb-devel] Re: SLAB vs. pci_alloc_xxx in usb-uhci patch [RFC: API]

2001-03-09 Thread Johannes Erdfelt
On Fri, Mar 09, 2001, David S. Miller <[EMAIL PROTECTED]> wrote: > Manfred Spraul writes: > > Do lots of drivers need the reverse mapping? It wasn't on my todo list > > yet. > > I am against any API which provides this. It can be extremely > expensive to do this on some architectures, and sinc

RE: [linux-usb-devel] Re: SLAB vs. pci_alloc_xxx in usb-uhci patch

2001-03-09 Thread Hicks, Jamey
Are there any large-memory machines that need pci_alloc_consistent() in the USB controller driver? If not, then let's just set up an uncached mapping of all of DRAM and use a modified version of virt_to_bus and bus_to_virt. It gets around all the issues of having a better allocator of uncached m

Re: [linux-usb-devel] Re: SLAB vs. pci_alloc_xxx in usb-uhci patch

2001-03-06 Thread David Brownell
> > At the time, I didn't feel like creating a custom sub-allocator just > > for USB, ... > > > > I'd be good to get it done "properly" at some point though. > > Something like > > struct pci_pool *pci_alloc_consistent_pool(int objectsize, int align) struct pci_pool * pci_create_consist