summaryrefslogtreecommitdiffstats
path: root/arch/sparc64/kernel/iommu_common.h
Commit message (Collapse)AuthorAgeFilesLines
* sparc64: use iommu_num_pages function in IOMMU codeJoerg Roedel2008-10-161-12/+2
| | | | | | | | | Signed-off-by: Joerg Roedel <joerg.roedel@amd.com> Acked-by: David S. Miller <davem@davemloft.net> Cc: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> Cc: Muli Ben-Yehuda <muli@il.ibm.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* sparc64: rename iommu_num_pages function to iommu_nr_pagesJoerg Roedel2008-10-161-2/+2
| | | | | | | | | | | This is a preparation patch for introducing a generic iommu_num_pages function. Signed-off-by: Joerg Roedel <joerg.roedel@amd.com> Acked-by: David S. Miller <davem@davemloft.net> Cc: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> Cc: Muli Ben-Yehuda <muli@il.ibm.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* PAGE_ALIGN(): correctly handle 64-bit values on 32-bit architecturesAndrea Righi2008-07-241-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On 32-bit architectures PAGE_ALIGN() truncates 64-bit values to the 32-bit boundary. For example: u64 val = PAGE_ALIGN(size); always returns a value < 4GB even if size is greater than 4GB. The problem resides in PAGE_MASK definition (from include/asm-x86/page.h for example): #define PAGE_SHIFT 12 #define PAGE_SIZE (_AC(1,UL) << PAGE_SHIFT) #define PAGE_MASK (~(PAGE_SIZE-1)) ... #define PAGE_ALIGN(addr) (((addr)+PAGE_SIZE-1)&PAGE_MASK) The "~" is performed on a 32-bit value, so everything in "and" with PAGE_MASK greater than 4GB will be truncated to the 32-bit boundary. Using the ALIGN() macro seems to be the right way, because it uses typeof(addr) for the mask. Also move the PAGE_ALIGN() definitions out of include/asm-*/page.h in include/linux/mm.h. See also lkml discussion: http://lkml.org/lkml/2008/6/11/237 [akpm@linux-foundation.org: fix drivers/media/video/uvc/uvc_queue.c] [akpm@linux-foundation.org: fix v850] [akpm@linux-foundation.org: fix powerpc] [akpm@linux-foundation.org: fix arm] [akpm@linux-foundation.org: fix mips] [akpm@linux-foundation.org: fix drivers/media/video/pvrusb2/pvrusb2-dvb.c] [akpm@linux-foundation.org: fix drivers/mtd/maps/uclinux.c] [akpm@linux-foundation.org: fix powerpc] Signed-off-by: Andrea Righi <righi.andrea@gmail.com> Cc: <linux-arch@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* sparc64: remove unused calc_npages() in iommu_common.hFUJITA Tomonori2008-03-281-13/+0
| | | | | | Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: David S. Miller <davem@davemloft.net>
* sparc64: add the segment boundary checking to IOMMUs while merging SG entriesFUJITA Tomonori2008-03-281-0/+13
| | | | | | | | | | | | | | | | | | | | Some IOMMUs allocate memory areas spanning LLD's segment boundary limit. It forces low level drivers to have a workaround to adjust scatter lists that the IOMMU builds. We are in the process of making all the IOMMUs respect the segment boundary limits to remove such work around in LLDs. SPARC64 IOMMUs were rewritten to use the IOMMU helper functions and the commit 89c94f2f70d093f59b55d3ea8042d13889169346 made the IOMMUs not allocate memory areas spanning the segment boundary limit. However, SPARC64 IOMMUs allocate memory areas first then try to merge them (while some IOMMUs walk through all the sg entries to see how they can be merged first and allocate memory areas). So SPARC64 IOMMUs also need the boundary limit checking when they try to merge sg entries. Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: David S. Miller <davem@davemloft.net>
* [SPARC64]: IOMMU allocations using iommu-helper layer.David S. Miller2008-02-091-0/+8
| | | | Signed-off-by: David S. Miller <davem@davemloft.net>
* [SPARC64]: iommu_common.h tidy ups...David S. Miller2008-02-091-3/+7
| | | | | | Add missing multiple-include guards and update copyright. Signed-off-by: David S. Miller <davem@davemloft.net>
* [SPARC64]: Remove unused declarations from iommu_common.hDavid S. Miller2008-02-091-19/+0
| | | | Signed-off-by: David S. Miller <davem@davemloft.net>
* [SPARC64]: Temporarily remove IOMMU merging code.David S. Miller2008-02-061-0/+26
| | | | | | | | | | | | | | Changeset fde6a3c82d67f592eb587be4d12222b0ae6d4321 ("iommu sg merging: sparc64: make iommu respect the segment size limits") broke sparc64 because whilst it added the segment limiting code to the first pass of SG mapping (in prepare_sg()) it did not add matching code to the second pass handling (in fill_sg()) As a result the two passes disagree where the segment boundaries should be, resulting in OOPSes, DMA corruption, and corrupted superblocks. Signed-off-by: David S. Miller <davem@davemloft.net>
* iommu sg merging: sparc64: make iommu respect the segment size limitsFUJITA Tomonori2008-02-051-1/+2
| | | | | | | | | | | | | This patch makes iommu respect segment size limits when merging sg lists. Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> Cc: Jeff Garzik <jeff@garzik.org> Cc: James Bottomley <James.Bottomley@steeleye.com> Acked-by: Jens Axboe <jens.axboe@oracle.com> Cc: "David S. Miller" <davem@davemloft.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* SPARC64: fix iommu sg chainingFUJITA Tomonori2007-10-171-0/+1
| | | | | | | | Commit 2c941a204070ab32d92d40318a3196a7fb994c00 looks incomplete. The helper functions like prepare_sg() need to support sg chaining too. Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
* Linux-2.6.12-rc2v2.6.12-rc2Linus Torvalds2005-04-161-0/+48
Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
OpenPOWER on IntegriCloud