* _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
[parent not found: <20040518190319.95305.qmail@web50004.mail.yahoo.com>]
* 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