aboutsummaryrefslogtreecommitdiff
path: root/arch/sparc64/kernel/pci_iommu.c
AgeCommit message (Collapse)Author
2006-05-23[SPARC64]: Respect gfp_t argument to dma_alloc_coherent().David S. Miller
Using asm-generic/dma-mapping.h does not work because pushing the call down to pci_alloc_coherent() causes the gfp_t argument of dma_alloc_coherent() to be ignored. Fix this by implementing things directly, and adding a gfp_t argument we can use in the internal call down to the PCI DMA implementation of pci_alloc_coherent(). This fixes massive memory corruption when using the sound driver layer, which passes things like __GFP_COMP down into these routines and (correctly) expects that to work. Signed-off-by: David S. Miller <davem@davemloft.net>
2006-03-20[SPARC64]: kzalloc() conversionEric Sesterhenn
this patch converts arch/sparc64 to kzalloc usage. Crosscompile tested with allyesconfig. Signed-off-by: Eric Sesterhenn <snakebyte@gmx.de> Signed-off-by: David S. Miller <davem@davemloft.net>
2006-03-20[SPARC64]: First cut at SUN4V PCI IOMMU handling.David S. Miller
Signed-off-by: David S. Miller <davem@davemloft.net>
2006-03-20[SPARC64]: Beginnings of SUN4V PCI controller support.David S. Miller
Abstract out IOMMU operations so that we can have a different set of calls on sun4v, which needs to do things through hypervisor calls. Signed-off-by: David S. Miller <davem@davemloft.net>
2005-10-13[SPARC64]: Eliminate PCI IOMMU dma mapping size limit.David S. Miller
The hairy fast allocator in the sparc64 PCI IOMMU code has a hard limit of 256 pages. Certain devices can exceed this when performing very large I/Os. So replace with a more simple allocator, based largely upon the arch/ppc64/kernel/iommu.c code. Signed-off-by: David S. Miller <davem@davemloft.net>
2005-10-13[SPARC64]: Consolidate common PCI IOMMU init code.David S. Miller
All the PCI controller drivers were doing the same thing setting up the IOMMU software state, put it all in one spot. Signed-off-by: David S. Miller <davem@davemloft.net>
2005-08-29[SPARC64]: More fully work around Spitfire Errata 51.David S. Miller
It appears that a memory barrier soon after a mispredicted branch, not just in the delay slot, can cause the hang condition of this cpu errata. So move them out-of-line, and explicitly put them into a "branch always, predict taken" delay slot which should fully kill this problem. Signed-off-by: David S. Miller <davem@davemloft.net>
2005-05-31[SPARC64]: Refine PCI strbuf ctx-based flush.David S. Miller
The initial peek read PIO of the match register is just a waste. Just do the flush writes first, as that is more efficient. Signed-off-by: David S. Miller <davem@davemloft.net>
2005-05-31[SPARC64]: Fix streaming buffer flushing on PCI and SBUS.David S. Miller
Firstly, if the direction is TODEVICE, then dirty data in the streaming cache is impossible so we can elide the flush-flag synchronization in that case. Next, the context allocator is broken. It is highly likely that contexts get used multiple times for different dma mappings, which confuses the strbuf flushing code and makes it run inefficiently. Signed-off-by: David S. Miller <davem@davemloft.net>
2005-05-20[SPARC64]: Fix bad performance side effect of strbuf timeout changes.David S. Miller
The recent change to add a timeout to strbuf flushing had a negative performance impact. The udelay()'s are too long, and they were done in the wrong order wrt. the register read checks. Fix both, and things are happy again. There are more possible improvements in this area. In fact, PCI streaming buffer flushing seems to be part of the bottleneck in network receive performance on my SunBlade1000 box. Signed-off-by: David S. Miller <davem@davemloft.net>
2005-05-11[SPARC64]: Add timeouts to streaming buffer synchronization.David S. Miller
If some hardware error occurs and the flush flag never updates, we will hang forever in these routines. Add a timeout, and print out a diagnostic if it is reached. Signed-off-by: David S. Miller <davem@davemloft.net>
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!