linux-toradex.git/drivers/dma/ioat, branch v3.4.45

ioat: Fix DMA memory sync direction correct flag

2013-01-28T04:47:44+00:00

commit ac4989874af56435c308bdde9ad9c837a26f8b23 upstream.

ioat does DMA memory sync with DMA_TO_DEVICE direction on a buffer allocated
for DMA_FROM_DEVICE dma, resulting in the following warning from dma debug.
Fixed the dma_sync_single_for_device() call to use the correct direction.

[  226.288947] WARNING: at lib/dma-debug.c:990 check_sync+0x132/0x550()
[  226.288948] Hardware name: ProLiant DL380p Gen8
[  226.288951] ioatdma 0000:00:04.0: DMA-API: device driver syncs DMA memory with different direction [device address=0x00000000ffff7000] [size=4096 bytes] [mapped with DMA_FROM_DEVICE] [synced with DMA_TO_DEVICE]
[  226.288953] Modules linked in: iTCO_wdt(+) sb_edac(+) ioatdma(+) microcode serio_raw pcspkr edac_core hpwdt(+) iTCO_vendor_support hpilo(+) dca acpi_power_meter ata_generic pata_acpi sd_mod crc_t10dif ata_piix libata hpsa tg3 netxen_nic(+) sunrpc dm_mirror dm_region_hash dm_log dm_mod
[  226.288967] Pid: 1055, comm: work_for_cpu Tainted: G        W    3.3.0-0.20.el7.x86_64 #1
[  226.288968] Call Trace:
[  226.288974]  [] warn_slowpath_common+0x7f/0xc0
[  226.288977]  [] warn_slowpath_fmt+0x46/0x50
[  226.288980]  [] check_sync+0x132/0x550
[  226.288983]  [] debug_dma_sync_single_for_device+0x3f/0x50
[  226.288988]  [] ? wait_for_common+0x72/0x180
[  226.288995]  [] ioat_xor_val_self_test+0x3e5/0x832 [ioatdma]
[  226.288999]  [] ? kfree+0x259/0x270
[  226.289004]  [] ioat3_dma_self_test+0x1b/0x20 [ioatdma]
[  226.289008]  [] ioat_probe+0x2f8/0x348 [ioatdma]
[  226.289011]  [] ioat3_dma_probe+0x1d5/0x2aa [ioatdma]
[  226.289016]  [] ioat_pci_probe+0x139/0x17c [ioatdma]
[  226.289020]  [] local_pci_probe+0x5c/0xd0
[  226.289023]  [] ? destroy_work_on_stack+0x20/0x20
[  226.289025]  [] do_work_for_cpu+0x18/0x30
[  226.289029]  [] kthread+0xb7/0xc0
[  226.289033]  [] kernel_thread_helper+0x4/0x10
[  226.289036]  [] ? _raw_spin_unlock_irq+0x30/0x50
[  226.289038]  [] ? retint_restore_args+0x13/0x13
[  226.289041]  [] ? kthread_worker_fn+0x1a0/0x1a0
[  226.289044]  [] ? gs_change+0x13/0x13
[  226.289045] ---[ end trace e1618afc7a606089 ]---
[  226.289047] Mapped at:
[  226.289048]  [] debug_dma_map_page+0x87/0x150
[  226.289050]  [] dma_map_page.constprop.18+0x70/0xb34 [ioatdma]
[  226.289054]  [] ioat_xor_val_self_test+0x1d8/0x832 [ioatdma]
[  226.289058]  [] ioat3_dma_self_test+0x1b/0x20 [ioatdma]
[  226.289061]  [] ioat_probe+0x2f8/0x348 [ioatdma]

Signed-off-by: Shuah Khan 
Signed-off-by: Vinod Koul 
Signed-off-by: Greg Kroah-Hartman

Merge tag 'dmaengine-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/djbw/dmaengine

2012-04-10T22:30:16+00:00

Pull dmaengine fixes from Dan Williams:

1/ regression fix for Xen as it now trips over a broken assumption
   about the dma address size on 32-bit builds

2/ new quirk for netdma to ignore dma channels that cannot meet
   netdma alignment requirements

3/ fixes for two long standing issues in ioatdma (ring size overflow)
   and iop-adma (potential stack corruption)

* tag 'dmaengine-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/djbw/dmaengine:
  netdma: adding alignment check for NETDMA ops
  ioatdma: DMA copy alignment needed to address IOAT DMA silicon errata
  ioat: ring size variables need to be 32bit to avoid overflow
  iop-adma: Corrected array overflow in RAID6 Xscale(R) test.
  ioat: fix size of 'completion' for Xen

ioatdma: DMA copy alignment needed to address IOAT DMA silicon errata

2012-04-05T22:24:35+00:00

Silicon errata where when RAID and legacy descriptors are mixed, the legacy
(memcpy and friends) operation must have alignment of 64 bytes to avoid
hanging. This effects Intel Xeon C55xx, C35xx, E5-2600.

Signed-off-by: Dave Jiang 
Signed-off-by: Dan Williams

ioat: ring size variables need to be 32bit to avoid overflow

2012-04-05T22:22:58+00:00

The alloc order can be up to 16 and 1 << 16 will over flow the 16bit
integer. Change the appropriate variables to 16bit to avoid overflow.

Reported-by: Jim Harris 
Signed-off-by: Dave Jiang 
Signed-off-by: Dan Williams

ioat: fix size of 'completion' for Xen

2012-03-23T20:36:42+00:00

Starting with v3.2 Jonathan reports that Xen crashes loading the ioatdma
driver.  A debug run shows:

  ioatdma 0000:00:16.4: desc[0]: (0x300cc7000->0x300cc7040) cookie: 0 flags: 0x2 ctl: 0x29 (op: 0 int_en: 1 compl: 1)
  ...
  ioatdma 0000:00:16.4: ioat_get_current_completion: phys_complete: 0xcc7000

...which shows that in this environment GFP_KERNEL memory may be backed
by a 64-bit dma address.  This breaks the driver's assumption that an
unsigned long should be able to contain the physical address for
descriptor memory.  Switch to dma_addr_t which beyond being the right
size, is the true type for the data i.e. an io-virtual address
inidicating the engine's last processed descriptor.

[stable: 3.2+]
Cc: 
Reported-by: Jonathan Nieder 
Reported-by: William Dauchy 
Tested-by: William Dauchy 
Tested-by: Dave Jiang 
Signed-off-by: Dan Williams

dmaengine: fix for cookie changes and merge

2012-03-13T06:28:12+00:00

Fixed trivial issues in drivers:
	drivers/dma/imx-sdma.c
	drivers/dma/intel_mid_dma.c
	drivers/dma/ioat/dma_v3.c
	drivers/dma/iop-adma.c
	drivers/dma/sirf-dma.c
	drivers/dma/timb_dma.c

Signed-off-by: Vinod Koul

dmaengine: ensure all DMA engine drivers initialize their cookies

2012-03-13T06:07:42+00:00

Ensure all DMA engine drivers initialize their cookies in the same way,
so that they all behave in a similar fashion.  This means their first
issued cookie will be 2 rather than 1, and will increment to INT_MAX
before returning 1 and starting over.

In connection with this, Dan Williams said:
> Russell King wrote:
> > Secondly, some DMA engine drivers initialize the dma_chan cookie to 0,
> > others to 1.  Is there a reason for this, or are these all buggy?
>
> I know that ioat and iop-adma expect 0 to mean "I have cleaned up this
> descriptor and it is idle", and would break if zero was an in-flight
> cookie value.  The reserved usage of zero is an driver internal
> concern, but I have no problem formalizing it as a reserved value.

Signed-off-by: Russell King 
Tested-by: Linus Walleij 
Reviewed-by: Linus Walleij 
Acked-by: Jassi Brar 
[imx-sdma.c & mxs-dma.c]
Tested-by: Shawn Guo 
Signed-off-by: Vinod Koul

dmaengine: consolidate tx_status functions

2012-03-13T06:07:14+00:00

Now that we have the completed cookie in the dma_chan structure, we
can consolidate the tx_status functions by providing a function to set
the txstate structure and returning the DMA status.  We also provide
a separate helper to set the residue for cookies which are still in
progress.

Signed-off-by: Russell King 
Tested-by: Linus Walleij 
Reviewed-by: Linus Walleij 
Acked-by: Jassi Brar 
[imx-sdma.c & mxs-dma.c]
Tested-by: Shawn Guo 
Signed-off-by: Vinod Koul

dmaengine: provide a common function for completing a dma descriptor

2012-03-13T06:07:01+00:00

Provide a common function to do the cookie mechanics for completing
a DMA descriptor.

Signed-off-by: Russell King 
Tested-by: Linus Walleij 
Reviewed-by: Linus Walleij 
Acked-by: Jassi Brar 
[imx-sdma.c & mxs-dma.c]
Tested-by: Shawn Guo 
Signed-off-by: Vinod Koul

dmaengine: consolidate assignment of DMA cookies

2012-03-13T06:06:52+00:00

Everyone deals with assigning DMA cookies in the same way (it's part of
the API so they should be), so lets consolidate the common code into a
helper function to avoid this duplication.

Signed-off-by: Russell King 
Tested-by: Linus Walleij 
Reviewed-by: Linus Walleij 
Acked-by: Jassi Brar 
[imx-sdma.c & mxs-dma.c]
Tested-by: Shawn Guo 
Signed-off-by: Vinod Koul