From: Daniel Stodden <stodden@in.tum.de>
To: Russell King <rmk@arm.linux.org.uk>
Cc: "David S. Miller" <davem@redhat.com>,
groudier@free.fr, alan@lxorguk.ukuu.org.uk, zaitcev@redhat.com,
Linux Kernel <linux-kernel@vger.kernel.org>
Subject: Re: pci_pool reap?
Date: 12 Feb 2002 18:27:02 +0100 [thread overview]
Message-ID: <1013534853.1598.270.camel@bitch> (raw)
In-Reply-To: <20020212154816.E31425@flint.arm.linux.org.uk>
In-Reply-To: <E16a6sw-0005Jw-00@the-village.bc.nu> <20020210211352.Q1910-100000@gerard> <20020211.184412.35663889.davem@redhat.com> <1013528224.2240.245.camel@bitch> <20020212154816.E31425@flint.arm.linux.org.uk>
[-- Attachment #1: Type: text/plain, Size: 1535 bytes --]
hi.
On Tue, 2002-02-12 at 16:48, Russell King wrote:
> On Tue, Feb 12, 2002 at 04:36:34PM +0100, Daniel Stodden wrote:
> > ARM does GFP_KERNEL, and then __ioremaps the underlying pages.
> > ugh. is that the only way to get the area coherent?
>
> Yes. Cache bits are in the page tables, and it would be idiotic to
> manipulate the cache bits on a 1MB granularity over the kernel
> direct mapped space.
>
> > furthermore i don't see why this could not be interrupt safe.
>
> GFP_KERNEL in the page table allocation functions mainly. We've been
> around and around this recently on this mailing list, so I'm not going
> to say anything further. I don't want another long discussion about
> this subject taking my time away from doing real work on ARM. If you're
> really interested in the outcome, please examine the lkml archives.
ok. i read part of the old thread now. sorry. didn't know that this had
already been issued.
so, based on the fact that
1. _most_ archs can easily do atomically.
2. those which don't aren't necessarily the better ones.
3. many drivers may prefer/be able to alloc through during
_init()/_release()
3.5 some may not.
4. even on arm, __ioremap() takes a gfp for quite some time now
and nobody seems to disagree.
then why does pci_alloc_consistent() not just take gfp flags and people
put in what their personal preference is?
regards,
dns
--
___________________________________________________________________________
mailto:stodden@in.tum.de
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 232 bytes --]
next prev parent reply other threads:[~2002-02-12 17:29 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <mailman.1013388420.27877.linux-kernel2news@redhat.com>
2002-02-11 2:49 ` pci_pool reap? Pete Zaitcev
2002-02-11 3:12 ` Alan Cox
2002-02-10 20:20 ` Gérard Roudier
2002-02-12 2:44 ` David S. Miller
2002-02-11 20:34 ` Gérard Roudier
2002-02-12 15:36 ` Daniel Stodden
2002-02-11 21:10 ` Gérard Roudier
2002-02-12 21:14 ` Daniel Stodden
2002-02-12 15:48 ` Russell King
2002-02-12 15:50 ` David S. Miller
2002-02-12 15:59 ` Russell King
2002-02-12 17:27 ` Daniel Stodden [this message]
2002-02-12 15:49 ` David S. Miller
2002-02-11 0:44 Daniel Stodden
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1013534853.1598.270.camel@bitch \
--to=stodden@in.tum.de \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=davem@redhat.com \
--cc=groudier@free.fr \
--cc=linux-kernel@vger.kernel.org \
--cc=rmk@arm.linux.org.uk \
--cc=zaitcev@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox