public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* _PAGE_PCD bit in DMAable memory
@ 2004-05-17  1:12 fc scsi
  2004-05-17  2:20 ` Roland Dreier
  0 siblings, 1 reply; 4+ messages in thread
From: fc scsi @ 2004-05-17  1:12 UTC (permalink / raw)
  To: linux-kernel; +Cc: scsi_fc_group

Hi,
 
I am trying to get DMAable memory on i386
(kmalloc(GFP_DMA,)) but seems 
_PAGE_PCD is not set on the pages that i get back the
memory from. Am I 
getting the correct results? If yes, then is it not
that GFP_DMA should 
give me non-cacheable memory (equivalent to setting
_PAGE_PCD along 
with _PAGE_PWT on i386). Can anyone confirm for me
that GFP_DMA will 
*always* give me non-cacheable and contiguous memory.
 
Many thanks in advance.




	
		
__________________________________
Do you Yahoo!?
SBC Yahoo! - Internet access at a great low price.
http://promo.yahoo.com/sbc/

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: _PAGE_PCD bit in DMAable memory
  2004-05-17  1:12 _PAGE_PCD bit in DMAable memory fc scsi
@ 2004-05-17  2:20 ` Roland Dreier
  2004-05-17 15:48   ` fc scsi
  0 siblings, 1 reply; 4+ messages in thread
From: Roland Dreier @ 2004-05-17  2:20 UTC (permalink / raw)
  To: fc scsi; +Cc: linux-kernel

    fc> Hi, I am trying to get DMAable memory on i386
    fc> (kmalloc(GFP_DMA,)) but seems _PAGE_PCD is not set on the
    fc> pages that i get back the memory from. Am I getting the
    fc> correct results? If yes, then is it not that GFP_DMA should
    fc> give me non-cacheable memory (equivalent to setting _PAGE_PCD
    fc> along with _PAGE_PWT on i386). Can anyone confirm for me that
    fc> GFP_DMA will *always* give me non-cacheable and contiguous
    fc> memory.

On i386, the GFP_DMA flag controls _where_ the memory will be
allocated, namely in the low 16 MB.  This is really a relic of the
days of 24-bit ISA DMA.

On i386, the memory does not have to be non-cacheable, since in the PC
architecture the bus controller will maintain consistency by snooping
the CPU.  However, to be portable, your code should use
pci_alloc_consistent() to get memory for DMAing.  This will do the
right thing on all platforms, including making sure that the memory is
non-cacheable on architectures where the bus controller does not snoop.

(By the way, kmalloc() will always return contiguous memory, but you
should still use pci_alloc_consistent for DMA memory)

 - Roland

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: _PAGE_PCD bit in DMAable memory
  2004-05-17  2:20 ` Roland Dreier
@ 2004-05-17 15:48   ` fc scsi
  0 siblings, 0 replies; 4+ messages in thread
From: fc scsi @ 2004-05-17 15:48 UTC (permalink / raw)
  To: Roland Dreier; +Cc: linux-kernel

Hi,

Thanks for the reply and the information. Actually,
the code will have to run on Intel Xscale
processor(ARM based). Since I don't have Linux running
on the board as of now, I was trying out things on my
i386 machine to get non-cacheable memory. That was
when I thought that GFP_DMA should give me
non-cacheable memory(_PAGE_PCD on i386 should be set
for such a memory, and L_PTE_CACHEABLE should be clear
on Xscale by this analogy). But, as you have explained
_PAGE_PCD need not be set for non-cacheable memory for
i386. I am new to Xscale architecture and don't know
if pci_alloc_consistent() will give me non-cacheable
memory or not. Can anyone who has worked on Xscale
confirm this.

Another curiousity for me is, if
pci_alloc_consistent() gives non-cacheable memory for
Xscale(arm) then will the L_PTE_CACHEABLE bit set in
it or not?

Anyway, thanks Roland for the previous answer. It was
a great help.

Regards.


--- Roland Dreier <roland@topspin.com> wrote:
>     fc> Hi, I am trying to get DMAable memory on
> i386
>     fc> (kmalloc(GFP_DMA,)) but seems _PAGE_PCD is
> not set on the
>     fc> pages that i get back the memory from. Am I
> getting the
>     fc> correct results? If yes, then is it not that
> GFP_DMA should
>     fc> give me non-cacheable memory (equivalent to
> setting _PAGE_PCD
>     fc> along with _PAGE_PWT on i386). Can anyone
> confirm for me that
>     fc> GFP_DMA will *always* give me non-cacheable
> and contiguous
>     fc> memory.
> 
> On i386, the GFP_DMA flag controls _where_ the
> memory will be
> allocated, namely in the low 16 MB.  This is really
> a relic of the
> days of 24-bit ISA DMA.
> 
> On i386, the memory does not have to be
> non-cacheable, since in the PC
> architecture the bus controller will maintain
> consistency by snooping
> the CPU.  However, to be portable, your code should
> use
> pci_alloc_consistent() to get memory for DMAing. 
> This will do the
> right thing on all platforms, including making sure
> that the memory is
> non-cacheable on architectures where the bus
> controller does not snoop.
> 
> (By the way, kmalloc() will always return contiguous
> memory, but you
> should still use pci_alloc_consistent for DMA
> memory)
> 
>  - Roland



	
		
__________________________________
Do you Yahoo!?
SBC Yahoo! - Internet access at a great low price.
http://promo.yahoo.com/sbc/

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: _PAGE_PCD bit in DMAable memory
       [not found] <20040518190319.95305.qmail@web50004.mail.yahoo.com>
@ 2004-05-18 20:29 ` Ingo Oeser
  0 siblings, 0 replies; 4+ messages in thread
From: Ingo Oeser @ 2004-05-18 20:29 UTC (permalink / raw)
  To: fc scsi; +Cc: linux-kernel

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tuesday 18 May 2004 21:03, you wrote:
> Thanks much for the reply. I forgot to mention I am on
> Linux 2.4.20. I looked into 2.6 and could see what you
> described in your email. The comment on top of
> consistent_alloc() for arm (2.4.20) says it will give
> cache-coherent memory, but i am not able to see how
> this is made possible for Xscale when if it doesn't
> set the L_PTE_CACHEABLE to 0 (for 2.4.20, again).

There it is hidden in arch/arm/mm/ioremap.c

look at the L_ flags there and how L_PTE_CACHEABLE is missing there by default.

PS: This can be found easily with grep. Try this little Bash script to grep recursively 
      through the kernel and answer your questions more quickly:

#!/bin/bash
if [ $# -lt 2 ]; then
        PROGNAME=`basename $0`
        echo -e "$PROGNAME - find a string in a tree of *.c and *.h files"
        echo -e "Usage:\t$PROGNAME <start dir> <what>\n"
        exit 1
fi

DIR=$1
shift
exec find "${DIR}" -type f -name '*.[ch]' -print0 |xargs -0 grep -A8 "$@"


Regards

Ingo Oeser
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAqnIhU56oYWuOrkARAv6xAKCgcq/WebDhbLunZA9m/MnDhbKAVgCffZDE
SPn4VpSWK57wFxjmdicyIok=
=KjNv
-----END PGP SIGNATURE-----

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2004-05-18 20:29 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-05-17  1:12 _PAGE_PCD bit in DMAable memory fc scsi
2004-05-17  2:20 ` Roland Dreier
2004-05-17 15:48   ` fc scsi
     [not found] <20040518190319.95305.qmail@web50004.mail.yahoo.com>
2004-05-18 20:29 ` Ingo Oeser

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox