aboutsummaryrefslogtreecommitdiff
path: root/arch/sparc64/kernel/iommu_common.h
AgeCommit message (Collapse)Author
2008-02-09[SPARC64]: IOMMU allocations using iommu-helper layer.David S. Miller
Signed-off-by: David S. Miller <davem@davemloft.net>
2008-02-09[SPARC64]: iommu_common.h tidy ups...David S. Miller
Add missing multiple-include guards and update copyright. Signed-off-by: David S. Miller <davem@davemloft.net>
2008-02-09[SPARC64]: Remove unused declarations from iommu_common.hDavid S. Miller
Signed-off-by: David S. Miller <davem@davemloft.net>
2008-02-06[SPARC64]: Temporarily remove IOMMU merging code.David S. Miller
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>
2008-02-05iommu sg merging: sparc64: make iommu respect the segment size limitsFUJITA Tomonori
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>
2007-10-17SPARC64: fix iommu sg chainingFUJITA Tomonori
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>
2005-04-16Linux-2.6.12-rc2Linus Torvalds
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!