Re: (allocating non-cachable memory) (or More on the i82596)

On Fri, Jun 29, 2001 at 10:48:45AM -0700, Paul White wrote:

Btw...Where are these "consistent_alloc()" functions?  I've not seen theses
anywhere.

I also can't imagine how they would possibly work on any CPU using BATs.
Since the BAT is setup as cacheable space, you can't just take a "chunk"
of it and make it non-cacheable.  Not possible.

Now, yes, for the 4xx and 8xx proccessors that don't use BATs, I would
assume that when you do one of these "non-cache" allocs, it would
simply allocate you a batch of 4k pages, and set them as Caching
Inhibited.

Is there something I'm missing here?

If you are on broken 6xx/7xx/82xx implementation then you can use the
"nobats" kernel argument to map memory with only PTEs.  Then the
consistent_alloc() stuff that Dan has brought over from arch/arm
will work fine.  The implementation is simply to get_free_pages(),
virt_to_phys(), ioremap(), and finally throw away the original
cacheable mappings.

Hrm, I see this stuff Dan's been talking about isn't in linuxppc_devel
(bad Dan).  If we all nag him perhaps it will get there faster. :)

In the meantime, look at the arch/arm's implementation to get an
idea of how it optimizes software coherency with the knowledge of
how you are using the memory region.

--
Matt Porter
MontaVista Software, Inc.
mporter@mvista.com

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Matt Porter wrote:

Hrm, I see this stuff Dan's been talking about isn't in linuxppc_devel
(bad Dan).  If we all nag him perhaps it will get there faster. :)

Nag Tom :-).  I'll check with him to see what has happened to all of
these changes.  I'll get it in there.


	-- Dan

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

On Fri, 29 Jun 2001, Matt Porter wrote:

If you are on broken 6xx/7xx/82xx implementation then you can use the
"nobats" kernel argument to map memory with only PTEs.  Then the
consistent_alloc() stuff that Dan has brought over from arch/arm
will work fine.  The implementation is simply to get_free_pages(),
virt_to_phys(), ioremap(), and finally throw away the original
cacheable mappings.

Hrm, I see this stuff Dan's been talking about isn't in linuxppc_devel
(bad Dan).  If we all nag him perhaps it will get there faster. :)

In the meantime, look at the arch/arm's implementation to get an
idea of how it optimizes software coherency with the knowledge of
how you are using the memory region.

I've been poking around in the arch/arm code, impatiently contemplating
bringing the code over the my 2_4_devel tree on my own until it's been
done by someone more powerful. I looks like the big this done in the
consistent_alloc function is the calling of SetPageReserved for each page
allocated- this is a macro that sets the PG_reserved bit for the page,
which looks like it is a linux kernel thing, and not a hardware thig. Am I
missing something here, or will this actually prevent caching of those
pages? Or is the real magic done in the ioremap call, and the PG_reserved
bit tells the kernel not to touch the page (though it can still access the
data)? I presume the latter is the case, but I'd rather be sure before I
muck with this and add make my debugging job even harder.

Thanks
--Gus


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

"Justin (Gus) Hurwitz" wrote:

.....Am I
missing something here,....

Yeah.

I'll have this upgraded shortly.

	-- Dan

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/