- 19 Sep, 2008 19 commits
-
-
Joerg Roedel authored
Remove the memset and use __GFP_ZERO at allocation time instead. Signed-off-by:
Joerg Roedel <joerg.roedel@amd.com> Signed-off-by:
Ingo Molnar <mingo@elte.hu>
-
FUJITA Tomonori authored
x86's common alloc_coherent (dma_alloc_coherent in dma-mapping.h) sets up the gfp flag according to the device dma_mask but AMD IOMMU doesn't need it for devices that the IOMMU can do virtual mappings for. This patch avoids unnecessary low zone allocation. Signed-off-by:
FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> Signed-off-by:
-
Joerg Roedel authored
Remove some magic numbers and split the pte_root using standard functions. Signed-off-by:
-
Joerg Roedel authored
In isolation mode the protection domains for the devices are preallocated and preassigned. This is bad if a device should be passed to a virtualization guest because the IOMMU code does not know if it is in use by a driver. This patch changes the code to assign the device to the preallocated domain only if there are dma mapping requests for it. Signed-off-by:
-
Joerg Roedel authored
This function determines if the AMD IOMMU implementation is responsible for a given device. So the DMA layer can get this information from the driver. Signed-off-by:
-
Joerg Roedel authored
There is a bit in the device entry to suppress all IO page faults generated by a device. This bit was set until now because there was no event logging. Now that there is event logging this patch allows IO page faults from devices to see them in the kernel log. Signed-off-by:
-
Joerg Roedel authored
The code to log IOMMU events is in place now. So enable event logging with this patch. Signed-off-by:
-
Joerg Roedel authored
This patch adds code for polling and printing out events generated by the AMD IOMMU. Signed-off-by:
-
Joerg Roedel authored
The AMD IOMMU can generate interrupts for various reasons. This patch adds the basic interrupt enabling infrastructure to the driver. Signed-off-by:
-
Joerg Roedel authored
We need the pci_dev later anyways to enable MSI for the IOMMU hardware. So remove the devid pointing to the BDF and replace it with the pci_dev structure where the IOMMU is implemented. Signed-off-by:
-
Joerg Roedel authored
This patch adds the pci_seg field to the amd_iommu structure and fills it with the corresponding value from the ACPI table. Signed-off-by:
-
Joerg Roedel authored
This patch adds the allocation of a event buffer for each AMD IOMMU in the system. The hardware will log events like device page faults or other errors to this buffer once this is enabled. Signed-off-by:
-
Joerg Roedel authored
The API definition for dma_alloc_coherent states that the bus address has to be aligned to the next power of 2 boundary greater than the allocation size. This is violated by AMD IOMMU so far and this patch fixes it. Signed-off-by:
-
Joerg Roedel authored
This patch adds branch hints to the cecks if a completion_wait is necessary. The completion_waits in the mapping paths are unlikly because they will only happen on software implementations of AMD IOMMU which don't exists today or with lazy IO/TLB flushing when the allocator wraps around the address space. With lazy IO/TLB flushing the completion_wait in the unmapping path is unlikely too. Signed-off-by:
-
Joerg Roedel authored
The IO/TLB flushing on every unmaping operation is the most expensive part in AMD IOMMU code and not strictly necessary. It is sufficient to do the flush before any entries are reused. This is patch implements lazy IO/TLB flushing which does exactly this. Signed-off-by:
-
Joerg Roedel authored
The GART currently implements the iommu=[no]fullflush command line parameters which influence its IO/TLB flushing strategy. This patch makes these parameters generic so that they can be used by the AMD IOMMU too. Signed-off-by:
-
Joerg Roedel authored
This patch moves the invocation of the flushing functions to the map/unmap helpers because its common code in all dma_ops relevant mapping/unmapping code. Signed-off-by:
-
Joerg Roedel authored
Currently AMD IOMMU code triggers a BUG_ON if NULL is passed as the device. This is inconsistent with other IOMMU implementations. Signed-off-by:
-
FUJITA Tomonori authored
swiotlb can use dma_get_mask() instead of the homegrown function. Signed-off-by:
-
- 14 Sep, 2008 6 commits
-
-
FUJITA Tomonori authored
gart alloc_coherent need to do virtual mapppings only when an allocated buffer is not DMA-capable for a device. Signed-off-by:
-
FUJITA Tomonori authored
x86's common alloc_coherent (dma_alloc_coherent in dma-mapping.h) sets up the gfp flag according to the device dma_mask but Calgary doesn't need it because of virtual mappings. This patch avoids unnecessary low zone allocation. Signed-off-by:
Muli Ben-Yehuda <muli@il.ibm.com> Signed-off-by:
-
FUJITA Tomonori authored
Currently, GART IOMMU ingores device's dma_mask when it does virtual mappings. So it could give a device a virtual address that the device can't access to. This patch fixes the above problem. Signed-off-by:
-
FUJITA Tomonori authored
Several IOMMUs do the same thing to get the dma_mask of a device. This adds a helper function to do the same thing to sweep them. Signed-off-by:
-
FUJITA Tomonori authored
This function helps IOMMUs to know the highest address that a device can access to. Signed-off-by:
-
Ingo Molnar authored
Conflicts: lib/swiotlb.c Signed-off-by:
-
- 13 Sep, 2008 15 commits
-
-
Linus Torvalds authored
* master.kernel.org:/home/rmk/linux-2.6-arm: [ARM] Fix PCI_DMA_BUS_IS_PHYS for ARM [ARM] 5247/1: tosa: SW_EAR_IN support [ARM] 5246/1: tosa: add proper clock alias for tc6393xb clock [ARM] 5245/1: Fix warning about unused return value in drivers/pcmcia [ARM] OMAP: Fix MMC device data imx serial: fix rts handling for non imx1 based hardware imx serial: set RXD mux bit on i.MX27 and i.MX31 i.MX serial: fix init failure pcm037: add rts/cts support for serial port
-
git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-devLinus Torvalds authored
* 'upstream-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev: [libata] LBA28/LBA48 off-by-one bug in ata.h sata_inic162x: enable LED blinking ata: duplicate variable sparse warning
-
git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/pci-2.6Linus Torvalds authored
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/pci-2.6: PCI: re-add debug prints for unmodified BARs PCI: fix pciehp_free_irq() PCI Hotplug: fakephp: fix deadlock... again PCI: Fix printk warnings in setup-bus.c PCI: Fix printk warnings in probe.c PCI/iommu: blacklist DMAR on Intel G31/G33 chipsets
-
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6Linus Torvalds authored
* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6: niu: panic on reset netlink: fix overrun in attribute iteration [Bluetooth] Fix regression from using default link policy ath9k: Assign seq# when mac80211 requests this
-
git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc-2.6Linus Torvalds authored
* git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc-2.6: sparc: Fix user_regset 'n' field values. sparc64: Fix PCI error interrupt registry on PSYCHO. sparc32: Fix function signature of of_bus_sbus_get_flags(). sparc64: Fix interrupt register calculations on Psycho and Sabre.
-
Alex Dubov authored
- 8-bit interface mode never worked properly. The only adapter I have which supports the 8b mode (the Jmicron) had some problems with its clock wiring and they discovered it only now. We also discovered that ProHG media is more sensitive to the ordering of initialization commands. - Make the driver fall back to highest supported mode instead of always falling back to serial. The driver will attempt the switch to 8b mode for any new MSPro card, but not all of them support it. Previously, these new cards ended up in serial mode, which is not the best idea (they work fine with 4b, after all). - Edit some macros for better conformance to Sony documentation Signed-off-by:
Alex Dubov <oakad@yahoo.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Andrew Morton authored
Herton Krzesinski reports that the error-checking changes in 04ebd4ae ("block/ioctl.c and fs/partition/check.c: check value returned by add_partition") cause his buggy USB camera to no longer mount. "The camera is an Olympus X-840. The original issue comes from the camera itself: its format program creates a partition with an off by one error". Buggy devices happen. It is better for the kernel to warn and to proceed with the mount. Reported-by:
Herton Ronaldo Krzesinski <herton@mandriva.com.br> Cc: Abdel Benamrouche <draconux@gmail.com> Cc: Jens Axboe <jens.axboe@oracle.com> Cc: Alan Stern <stern@rowland.harvard.edu> Cc: David Brownell <david-b@pacbell.net> Signed-off-by:
-
Ben Dooks authored
Fix the section mismatch warning generated by the incorrect naming of s3c24xx_spidrv which should be s3c24xx_spi_driver: WARNING: drivers/spi/spi_s3c24xx.o(.data+0x4): Section mismatch in reference from the variable s3c24xx_spidrv to the (unknown reference) .exit.text:(unknown) Signed-off-by:
Ben Dooks <ben-linux@fluff.org> Signed-off-by:
David Brownell <dbrownell@users.sourceforge.net> Signed-off-by:
-
Haavard Skinnemoen authored
When suspending the system with atmel_lcdfb enabled, I sometimes see this: atmel_lcdfb atmel_lcdfb.0: FIFO underflow 0x10 Which can be explained by the fact that we're not stopping the LCD controller and its DMA engine when suspending, we're just gating the clocks to them. There's another potential issue which may be harder to trigger but much more nasty: If we gate the clocks at _just_ the right moment, e.g. when the DMA engine is doing a bus transaction, we may cause the DMA engine to violate the system bus protocol and cause a lockup. Avoid these issues by shutting down the LCD controller before entering suspend (and restarting it when resuming). This prevents the underrun from happening in the first place, and prevents whatever nastiness is happening when the bus clock stops in the middle of a DMA transfer. Signed-off-by:
Haavard Skinnemoen <haavard.skinnemoen@atmel.com> Acked-by:
Nicolas Ferre <nicolas.ferre@atmel.com> Signed-off-by:
-
Robin Holt authored
If you are on ia64 and you modprobe xpc then modprobe -r xpc, you immediately get a panic. xpc depends on xp which depends on gru for a symbol. That symbol is only used when we are running on UV hardware. Currently, the GRU driver detects we are not on UV hardware and does no initializing. It does not do the same check when unloading. As a result, the gru driver attempts to tear down stuff that was not setup. This is a simple two-line workaround to get us through this release. Once 2.6.28 is opened, we need to rework the symbols that xp is depending on from gru so the gru driver can properly fail to load when hardware is not available. Signed-off-by:
Robin Holt <holt@sgi.com> Cc: "Luck, Tony" <tony.luck@intel.com> Signed-off-by:
-
Ming Lei authored
It should be linux-uvc-devel@lists.berlios.de. Signed-off-by:
Ming Lei <tom.leiming@gmail.com> Cc: Mauro Carvalho Chehab <mchehab@infradead.org> Signed-off-by:
-
David Brownell authored
Provide summary ABI docs about the /sys/class/gpio files. Signed-off-by:
-
Mel Gorman authored
The iterator for_each_zone_zonelist() uses a struct zoneref *z cursor when scanning zonelists to keep track of where in the zonelist it is. The zoneref that is returned corresponds to the the next zone that is to be scanned, not the current one. It was intended to be treated as an opaque list. When the page allocator is scanning a zonelist, it marks elements in the zonelist corresponding to zones that are temporarily full. As the zonelist is being updated, it uses the cursor here; if (NUMA_BUILD) zlc_mark_zone_full(zonelist, z); This is intended to prevent rescanning in the near future but the zoneref cursor does not correspond to the zone that has been found to be full. This is an easy misunderstanding to make so this patch corrects the problem by changing zoneref cursor to be the current zone being scanned instead of the next one. Signed-off-by:Mel Gorman <mel@csn.ul.ie> Cc: Andy Whitcroft <apw@shadowen.org> Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> Cc: <stable@kernel.org> [2.6.26.x] Signed-off-by:
-
Ned Forrester authored
Fixes two DMA bugs in the pxa2xx_spi driver. The first bug is in all versions of this driver; the second was introduced in the 2.6.20 kernel, and prevents using the driver with chips like m25p16 flash (which can issue large DMA reads). 1. Zero length transfers are permitted for use to insert timing, but pxa2xx_spi.c will fail if this is requested in DMA mode. Fixed by using programmed I/O (PIO) mode for such transfers. 2. Transfers larger than 8191 are not permitted in DMA mode. A test for length rejects all large transfers regardless of DMA or PIO mode. Worked around by rejecting only large transfers with DMA mapped buffers, and forcing all other transfers larger than 8191 to use PIO mode. A rate limited warning is issued for DMA transfers forced to PIO mode. This patch should apply to all kernels back to and including 2.6.20; it was test patched against 2.6.20. An additional patch would be required for older kernels, but those versions are very buggy anyway. Signed-off-by:Ned Forrester <nforrester@whoi.edu> Cc: Vernon Sauder <vernoninhand@gmail.com> Cc: Eric Miao <eric.y.miao@gmail.com> Signed-off-by:
-
Ned Forrester authored
Fixes several chipselect bugs in the pxa2xx_spi driver. These bugs are in all versions of this driver and prevent using it with chips like m25p16 flash. 1. The spi_transfer.cs_change flag is handled too early: before spi_transfer.delay_usecs applies, thus making the delay ineffective at holding chip select. 2. spi_transfer.delay_usecs is ignored on the last transfer of a message (likewise not holding chipselect long enough). 3. If spi_transfer.cs_change is set on the last transfer, the chip select is always disabled, instead of the intended meaning: optionally holding chip select enabled for the next message. Those first three bugs were fixed with a relocation of delays and chip select de-assertions. 4. If a message has the cs_change flag set on the last transfer, and had the chip select stayed enabled as requested (see 3, above), it would not have been disabled if the next message is for a different chip. Fixed by dropping chip select regardless of cs_change at end of a message, if there is no next message or if the next message is for a different chip. This patch should apply to all kernels back to and including 2.6.20; it was test patched against 2.6.20. An additional patch would be required for older kernels, but those versions are very buggy anyway. Signed-off-by:
-
