From: Christopher Wedgwood <cw@sgi.com>
To: linux-ia64@vger.kernel.org
Subject: Re: [PATCH] (2.4.x bk) efi_memmap_walk_uc
Date: Tue, 29 Jul 2003 18:34:07 +0000 [thread overview]
Message-ID: <marc-linux-ia64-105950380701651@msgid-missing> (raw)
In-Reply-To: <marc-linux-ia64-105883467032028@msgid-missing>
On Thu, Jul 24, 2003 at 06:15:42PM -0700, David Mosberger wrote:
> I really would like to see the code that's using
> efi_memmap_walk_uc() first.
I think Jack sent this to you already, but for the benefit of the
list (relevant functions rather than send to the list the entire
driver):
/*
* fetchop_build_memmap,
*
* Called at boot time to build a map of pages that can be used for
* fetchops.
*/
static int __init
fetchop_build_memmap(unsigned long start, unsigned long end, void *arg)
{
struct node_fetchops *fops;
long count, bytes;
count = (end - start) >> PAGE_SHIFT;
bytes = sizeof(struct node_fetchops) + count/8;
fops = vmalloc(bytes);
memset(fops, 0, bytes);
fops->maddr = FETCHOP_KADDR_TO_MSPEC_ADDR(start);
fops->count = count;
atomic_add(count, &fops->free);
fetchop_stats.pages_total += count;
node_fetchops[MSPEC_TO_NID(start)] = fops;
sn_flush_all_caches((long)__va(start), end - start);
return 0;
}
/*
* fetchop_init
*
* Called at boot time to initialize the fetchop facility.
*/
int __init
fetchop_init(void)
{
[...]
efi_memmap_walk_uc(fetchop_build_memmap, 0);
printk(KERN_INFO "%s: v%s\n", DRIVER_ID_STR, REVISION);
return 0;
}
> Also, a check like this:
>
> Chris> if (md->attribute = EFI_MEMORY_UC)
>
> is almost certainly wrong (md->attribute is a bitmap).
I think the logic here seems to have been uncached ONLY (ie. all other
bits zero). I guess this falls down if new attributes are added so
something like:
if ((md->attribute & SOME_MASK) = EFI_MEMORY_UC)
[...]
would then be required. Since this is the only consumer of this
interface thus far I'm not sure it's obvious how the function should
best work.
The issue right now seems to be whether or not this or some variation
of this is useful and/or desirable in the mainline kernel or whether
for now it's best to hide this in the driver until a later stage when
the EFI interfaces are abstracted out a little more to make this
easier?
Thanks,
--cw
next prev parent reply other threads:[~2003-07-29 18:34 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-07-22 0:43 [PATCH] (2.4.x bk) efi_memmap_walk_uc Christopher Wedgwood
2003-07-22 2:16 ` Bjorn Helgaas
2003-07-22 2:58 ` Christopher Wedgwood
2003-07-22 3:08 ` Bjorn Helgaas
2003-07-22 4:43 ` Christopher Wedgwood
2003-07-25 1:15 ` David Mosberger
2003-07-29 18:34 ` Christopher Wedgwood [this message]
2003-07-29 18:45 ` Luck, Tony
2003-07-29 19:03 ` Christopher Wedgwood
2003-07-29 20:41 ` David Mosberger
2003-07-29 21:15 ` Christopher Wedgwood
2003-07-29 21:31 ` David Mosberger
2003-07-29 21:34 ` Luck, Tony
2003-07-29 22:05 ` Jack Steiner
2003-07-29 22:07 ` Christopher Wedgwood
2003-07-29 22:26 ` Luck, Tony
2003-07-29 22:30 ` David Mosberger
2003-07-29 22:35 ` Christopher Wedgwood
2003-07-29 22:37 ` Christopher Wedgwood
2003-07-29 22:47 ` Luck, Tony
2003-07-29 22:48 ` David Mosberger
2003-07-29 22:54 ` David Mosberger
2003-07-29 23:49 ` Jack Steiner
2003-07-29 23:54 ` Christopher Wedgwood
2003-07-29 23:56 ` Jack Steiner
2003-07-30 0:00 ` Christopher Wedgwood
2003-07-30 0:02 ` Christopher Wedgwood
2003-07-30 0:05 ` David Mosberger
2003-07-30 0:12 ` David Mosberger
2003-07-30 0:22 ` Jack Steiner
2003-07-30 9:21 ` Christoph Hellwig
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=marc-linux-ia64-105950380701651@msgid-missing \
--to=cw@sgi.com \
--cc=linux-ia64@vger.kernel.org \
/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