> > 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
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
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
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
> > (1) CONFIG_SLAB_DEBUG breaks the documented
> > requirement that the slab cache return adequately aligned
> > data ...
>
> adequately aligned for the _cpu_, not for some controllers. It's neither
> documented that HW_CACHEALIGN aligns to 16 byte boundaries
It's documented in mm/slab.c (line
(1) CONFIG_SLAB_DEBUG breaks the documented
requirement that the slab cache return adequately aligned
data ...
adequately aligned for the _cpu_, not for some controllers. It's neither
documented that HW_CACHEALIGN aligns to 16 byte boundaries
It's documented in mm/slab.c (line 612 in
David Brownell wrote:
>
> There are two problems I see.
>
> (1) CONFIG_SLAB_DEBUG breaks the documented
> requirement that the slab cache return adequately aligned
> data ...
adequately aligned for the _cpu_, not for some controllers. It's neither
documented that HW_CACHEALIGN aligns to 16
> > 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 *
> Anyways, is this the end of the discussion regarding my patch?
I think one of the maintainers for usb-uhci (Georg) said he'd
want the general fix ...
> Manfred said plainly "usb-uhci is broken", Alan kinda
> manuevered around my small problem, Dave Brownell looks
> unconvinced. So?
There are
Anyways, is this the end of the discussion regarding my patch?
I think one of the maintainers for usb-uhci (Georg) said he'd
want the general fix ...
Manfred said plainly "usb-uhci is broken", Alan kinda
manuevered around my small problem, Dave Brownell looks
unconvinced. So?
There are two
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_consistent_pool
David Brownell wrote:
There are two problems I see.
(1) CONFIG_SLAB_DEBUG breaks the documented
requirement that the slab cache return adequately aligned
data ...
adequately aligned for the _cpu_, not for some controllers. It's neither
documented that HW_CACHEALIGN aligns to 16 byte
> From: "David S. Miller" <[EMAIL PROTECTED]>
> Date: Mon, 5 Mar 2001 20:53:21 -0800 (PST)
>[...]
> Gerard Roudier wrote for the sym53c8xx driver the exact thing
> UHCI/OHCI need for this.
Thanks for the hint.
***
Anyways, is this the end of the discussion regarding my patch?
If it goes in,
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 allocations to make sense for
> At the time, I didn't feel like creating a custom sub-allocator just
> for USB, and since then I haven't had the inclination nor motivation
> to go back to trying to get my USB mouse or iPAQ communicating via USB.
> (I've not used this USB port for 3 years anyway).
>
> I'd be good to get it
On Mon, Mar 05, 2001 at 02:52:24PM -0800, David Brownell wrote:
> I didn't see that thread. I agree, pci_alloc_consistent() already has
> a signature that's up to the job. The change you suggest would need
> to affect every architecture's implementation of that code ... which
> somehow seems
> > And mm/slab.c changes semantics when CONFIG_SLAB_DEBUG
> > is set: it ignores SLAB_HWCACHE_ALIGN. That seems more like
> > the root cause of the problem to me!
>
> HWCACHE_ALIGN does not guarantee a certain byte alignment. And
> additionally it's not even guaranteed that kmalloc() uses that
> And mm/slab.c changes semantics when CONFIG_SLAB_DEBUG
> is set: it ignores SLAB_HWCACHE_ALIGN. That seems more like
> the root cause of the problem to me!
>
HWCACHE_ALIGN does not guarantee a certain byte alignment. And
additionally it's not even guaranteed that kmalloc() uses that
Hi, everyone:
When I turn FORCE_DEBUG on in mm/slab.c, usb-uhci driver stops
working. It turned out that DMA headers must be aligned on 16.
Slab poisoning violates that assumption.
I have come up with a fix which USB folks did not like, but
they did not object to discussion on linux-kernel.
Hi, everyone:
When I turn FORCE_DEBUG on in mm/slab.c, usb-uhci driver stops
working. It turned out that DMA headers must be aligned on 16.
Slab poisoning violates that assumption.
I have come up with a fix which USB folks did not like, but
they did not object to discussion on linux-kernel.
On Mon, Mar 05, 2001 at 02:52:24PM -0800, David Brownell wrote:
I didn't see that thread. I agree, pci_alloc_consistent() already has
a signature that's up to the job. The change you suggest would need
to affect every architecture's implementation of that code ... which
somehow seems not
And mm/slab.c changes semantics when CONFIG_SLAB_DEBUG
is set: it ignores SLAB_HWCACHE_ALIGN. That seems more like
the root cause of the problem to me!
HWCACHE_ALIGN does not guarantee a certain byte alignment. And
additionally it's not even guaranteed that kmalloc() uses that
HWCACHE_ALIGN.
And mm/slab.c changes semantics when CONFIG_SLAB_DEBUG
is set: it ignores SLAB_HWCACHE_ALIGN. That seems more like
the root cause of the problem to me!
HWCACHE_ALIGN does not guarantee a certain byte alignment. And
additionally it's not even guaranteed that kmalloc() uses that
At the time, I didn't feel like creating a custom sub-allocator just
for USB, and since then I haven't had the inclination nor motivation
to go back to trying to get my USB mouse or iPAQ communicating via USB.
(I've not used this USB port for 3 years anyway).
I'd be good to get it done
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 allocations to make sense for USB.
From: "David S. Miller" [EMAIL PROTECTED]
Date: Mon, 5 Mar 2001 20:53:21 -0800 (PST)
[...]
Gerard Roudier wrote for the sym53c8xx driver the exact thing
UHCI/OHCI need for this.
Thanks for the hint.
***
Anyways, is this the end of the discussion regarding my patch?
If it goes in, then
59 matches
Mail list logo
