> > The reverse mapping
> > code hast to be less than 0.1KB.
>
> If reverse mapping means bus_to_virt(), then I would suggest not to
> provide it since it is a confusing interface. OTOH, only a few drivers
> need or want to retrieve the virtual address that lead to some bus dma
Your SCSI
On Fri, 9 Mar 2001, David Brownell wrote:
> Gérard --
>
> > Just for information to people that want to complexify the
> > pci_alloc_consistent() interface thats looks simple and elegant to me:
>
> I certainly didn't propose that! Just a layer on top of the
> pci_alloc_consistent code --
Gérard --
> Just for information to people that want to complexify the
> pci_alloc_consistent() interface thats looks simple and elegant to me:
I certainly didn't propose that! Just a layer on top of the
pci_alloc_consistent code -- used as a page allocator, just
like you used it.
> The
> 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
> 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
> > 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.
On Fri, 9 Mar 2001, David Brownell wrote:
> > > > > extern void *
> > > > > pci_pool_dma_to_cpu (struct pci_pool *pool, dma_addr_t handle);
> > > >
> > > > Do lots of drivers need the reverse mapping? It wasn't on my todo list
> > > > yet.
> > >
> > > Some hardware (like OHCI) talks to
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
David Brownell writes:
> > Do lots of drivers need the reverse mapping? It wasn't on my todo list
> > yet.
>
> Some hardware (like OHCI) talks to drivers using those dma handles.
Drivers for such hardware will this keep track of the information
necessary to make this reverse mapping.
Pete Zaitcev writes:
> > Some hardware (like OHCI) talks to drivers using those dma handles.
>
> 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
> > > 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
> > > > extern void *
> > > > pci_pool_dma_to_cpu (struct pci_pool *pool, dma_addr_t handle);
> > >
> > > Do lots of drivers need the reverse mapping? It wasn't on my todo list
> > > yet.
> >
> > Some hardware (like OHCI) talks to drivers using those dma handles.
>
> I wonder if it may be
> Date: Fri, 09 Mar 2001 10:29:22 -0800
> From: David Brownell <[EMAIL PROTECTED]>
> > > extern void *
> > > pci_pool_dma_to_cpu (struct pci_pool *pool, dma_addr_t handle);
> >
> > Do lots of drivers need the reverse mapping? It wasn't on my todo list
> > yet.
>
> Some hardware (like OHCI)
> 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
> > unlike the slab allocator bug(s) I pointed out. (And which
> > Manfred seems to have gone silent on.)
>
> which bugs?
See my previous email ... its behavior contradicts its spec,
and I'd sent a patch. You said you wanted kmalloc to have
an "automagic redzoning" feature, which would
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
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 since the rest
of the PCI dma API does not provide such an interface neither
David S. Miller writes:
> Russell King writes:
> > A while ago, I looked at what was required to convert the OHCI driver
> > to pci_alloc_consistent, and it turns out that the current interface is
> > highly sub-optimal. It looks good on the face of it, but it _really_
> > does need sub-page
David S. Miller writes:
Russell King writes:
A while ago, I looked at what was required to convert the OHCI driver
to pci_alloc_consistent, and it turns out that the current interface is
highly sub-optimal. It looks good on the face of it, but it _really_
does need sub-page
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 since the rest
of the PCI dma API does not provide such an interface neither
Date: Fri, 09 Mar 2001 10:29:22 -0800
From: David Brownell [EMAIL PROTECTED]
extern void *
pci_pool_dma_to_cpu (struct pci_pool *pool, dma_addr_t handle);
Do lots of drivers need the reverse mapping? It wasn't on my todo list
yet.
Some hardware (like OHCI) talks to drivers
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 since the
unlike the slab allocator bug(s) I pointed out. (And which
Manfred seems to have gone silent on.)
which bugs?
See my previous email ... its behavior contradicts its spec,
and I'd sent a patch. You said you wanted kmalloc to have
an "automagic redzoning" feature, which would involve one
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
extern void *
pci_pool_dma_to_cpu (struct pci_pool *pool, dma_addr_t handle);
Do lots of drivers need the reverse mapping? It wasn't on my todo list
yet.
Some hardware (like OHCI) talks to drivers using those dma handles.
I wonder if it may be feasible to allocate a
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 issue,
David Brownell writes:
Do lots of drivers need the reverse mapping? It wasn't on my todo list
yet.
Some hardware (like OHCI) talks to drivers using those dma handles.
Drivers for such hardware will this keep track of the information
necessary to make this reverse mapping.
Later,
Pete Zaitcev writes:
Some hardware (like OHCI) talks to drivers using those dma handles.
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
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
On Fri, 9 Mar 2001, David Brownell wrote:
extern void *
pci_pool_dma_to_cpu (struct pci_pool *pool, dma_addr_t handle);
Do lots of drivers need the reverse mapping? It wasn't on my todo list
yet.
Some hardware (like OHCI) talks to drivers using those dma handles.
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. You have
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 way
Grard --
Just for information to people that want to complexify the
pci_alloc_consistent() interface thats looks simple and elegant to me:
I certainly didn't propose that! Just a layer on top of the
pci_alloc_consistent code -- used as a page allocator, just
like you used it.
The object
On Fri, 9 Mar 2001, David Brownell wrote:
Grard --
Just for information to people that want to complexify the
pci_alloc_consistent() interface thats looks simple and elegant to me:
I certainly didn't propose that! Just a layer on top of the
pci_alloc_consistent code -- used as a
The reverse mapping
code hast to be less than 0.1KB.
If reverse mapping means bus_to_virt(), then I would suggest not to
provide it since it is a confusing interface. OTOH, only a few drivers
need or want to retrieve the virtual address that lead to some bus dma
Your SCSI code went
35 matches
Mail list logo
