lkml.org 
[lkml]   [2002]   [Feb]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: pci_pool reap?
From
Date
hi.

On Tue, 2002-02-12 at 03:44, David S. Miller wrote:
> From: Gérard Roudier <groudier@free.fr>
> Date: Sun, 10 Feb 2002 21:20:05 +0100 (CET)
>
> On Mon, 11 Feb 2002, Alan Cox wrote:
>
> > This function may not be called in interrupt context.
>
> Such limitation looks poor implementation to me.
>
> I agree with you Gerard, and probably nobody truly even requires
> this limitation. I do plan to remove it after I've done a thorough
> investigation of the platform implementations.

ok, i've looked through most of 2.5.4 now.
results look like this:

pci_alloc_consistent() pci_free_consistent()
i386:
[1] ok ok

ppc:
[1] ok ok

mips:
[1] ok ok

sh:
[1] ok ok
stm: [1] ok ok
dc: [3] ok ok

mips64:
ip32: [1] ok ok
ip27: [1] ok ok

sparc:
[1] GFP_KERNEL ok
sparc64:
[2] ok ok

arm: [4] BUG()/GFP_KERNEL BUG()

alpha:
[2] ok ok

ia64: [5] ok? ok?


[1]
gfp() + __pa() (or similar)

[2]
gfp() + IOMMU

[3]
dummy, offsets only

[4]
ARM does GFP_KERNEL, and then __ioremaps the underlying pages.
ugh. is that the only way to get the area coherent?
furthermore i don't see why this could not be interrupt safe.

[5]
i don't understand ia64. but it looks somewhat atomic :)

well, assuming i didn't oversee anything, there are indeed few reasons
left why the whole _consistent() machinery shouldn't be callable from
interrupts.

back to my original question: what were the last trees with shrinking
pools? would the original version still work or any redesigns needed?


regards,
dns

--
___________________________________________________________________________
mailto:stodden@in.tum.de

[unhandled content-type:application/pgp-signature]
\
 
 \ /
  Last update: 2005-03-22 13:24    [W:0.079 / U:0.176 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site