linux/drivers/dma, branch v3.0.6

dmaengine: shdma: SH_DMAC_MAX_CHANNELS message fix

2011-06-14T06:03:07Z

Fix the recently added SH_DMAC_MAX_CHANNELS handling code in 300e5f9 dmaengine: shdma: Fix SH_DMAC_MAX_CHANNELS handling Without this fix the shdma driver outputs silly messages in case SH_DMAC_MAX_CHANNELS happens to match the platform data: sh-dma-engine sh-dma-engine.0: Attempting to register 20 DMA channels when a max imum of 20 are supported. Signed-off-by: Magnus Damm Signed-off-by: Paul Mundt

dmaengine: shdma: fix a regression: initialise DMA channels for memcpy

2011-06-02T05:40:43Z

A recent patch has introduced a regression, where repeating a memcpy DMA test with shdma module unloading between them skips the DMA channel configuration. Fix this regression by always configuring the channel during its allocation. Signed-off-by: Guennadi Liakhovetski Signed-off-by: Paul Mundt

dmaengine: shdma: Fix up fallout from runtime PM changes.

2011-05-31T06:53:03Z

The runtime PM changes introduce sh_dmae_rst() wrapping via the runtime_resume helper, depending on dev_get_drvdata() to fetch the platform data needed for the DMAOR initialization default at a time where drvdata hasn't yet been established by the probe path, resulting in general probe misery: Unable to handle kernel NULL pointer dereference at virtual address 000000c4 pc = 8025adee *pde = 00000000 Oops: 0000 [#1] Modules linked in: Pid : 1, Comm: swapper CPU : 0 Not tainted (3.0.0-rc1-00012-g9436b4a-dirty #1456) PC is at sh_dmae_rst+0x28/0x86 PR is at sh_dmae_rst+0x22/0x86 PC : 8025adee SP : 9e803d10 SR : 400080f1 TEA : 000000c4 R0 : 000000c4 R1 : 0000fff8 R2 : 00000000 R3 : 00000040 R4 : 000000f0 R5 : 00000000 R6 : 00000000 R7 : 804f184c R8 : 00000000 R9 : 804dd0e8 R10 : 80283204 R11 : ffffffda R12 : 000000a0 R13 : 804dd18c R14 : 9e803d10 MACH: 00000000 MACL: 00008f20 GBR : 00000000 PR : 8025ade8 Call trace: [<8025ae70>] sh_dmae_runtime_resume+0x24/0x34 [<80283238>] pm_generic_runtime_resume+0x34/0x3c [<80283370>] rpm_callback+0x4a/0x7e [<80283efc>] rpm_resume+0x240/0x384 [<80283f54>] rpm_resume+0x298/0x384 [<8028428c>] __pm_runtime_resume+0x44/0x7c [<8038a358>] __ioremap_caller+0x0/0xec [<80284296>] __pm_runtime_resume+0x4e/0x7c [<8038a358>] __ioremap_caller+0x0/0xec [<80666254>] sh_dmae_probe+0x180/0x6a0 [<802803ae>] platform_drv_probe+0x26/0x2e Fix up the ordering accordingly. Signed-off-by: Paul Mundt

Merge branch 'next' of git://git.kernel.org/pub/scm/linux/kernel/git/djbw/async_tx

2011-05-28T19:35:15Z

* 'next' of git://git.kernel.org/pub/scm/linux/kernel/git/djbw/async_tx: (33 commits) x86: poll waiting for I/OAT DMA channel status maintainers: add dma engine tree details dmaengine: add TODO items for future work on dma drivers dmaengine: Add API documentation for slave dma usage dmaengine/dw_dmac: Update maintainer-ship dmaengine: move link order dmaengine/dw_dmac: implement pause and resume in dwc_control dmaengine/dw_dmac: Replace spin_lock* with irqsave variants and enable submission from callback dmaengine/dw_dmac: Divide one sg to many desc, if sg len is greater than DWC_MAX_COUNT dmaengine/dw_dmac: set residue as total len in dwc_tx_status if status is !DMA_SUCCESS dmaengine/dw_dmac: don't call callback routine in case dmaengine_terminate_all() is called dmaengine: at_hdmac: pause: no need to wait for FIFO empty pch_dma: modify pci device table definition pch_dma: Support new device ML7223 IOH pch_dma: Support I2S for ML7213 IOH pch_dma: Fix DMA setting issue pch_dma: modify for checkpatch pch_dma: fix dma direction issue for ML7213 IOH video-in dmaengine: at_hdmac: use descriptor chaining help function dmaengine: at_hdmac: implement pause and resume in atc_control ... Fix up trivial conflict in drivers/dma/dw_dmac.c

x86: poll waiting for I/OAT DMA channel status

2011-05-27T00:11:24Z

For certain system configurations a 5 usec udelay before checking I/OAT DMA channel status is sometimes not sufficient, resulting in a false failure status and unnecessary freeing of channel resources. Conversely, for many configurations 5 usec is longer than necessary. Loop for up to 20 usec waiting for successful status before failing. Signed-off-by: Dimitri Sivanich Signed-off-by: Dan Williams

dmaengine: add TODO items for future work on dma drivers

2011-05-26T21:44:30Z

Signed-off-by: Vinod Koul Signed-off-by: Dan Williams

mfd: Use mfd cell platform_data for timberdale cells platform bits

2011-05-26T17:45:05Z

With the addition of a device platform mfd_cell pointer, MFD drivers can go back to passing platform data back to their sub drivers. This allows for an mfd_cell->mfd_data removal and thus keep the sub drivers MFD agnostic. This is mostly needed for non MFD aware sub drivers. Acked-by: Richard Röjfors Signed-off-by: Samuel Ortiz

dmaengine/dw_dmac: Update maintainer-ship

2011-05-25T13:00:37Z

Nobody is currently maintaining dw_dmac. We are using dw_dmac for SPEAr13xx and are currently maintaining it. After discussing with Vinod, sending this patch to update maintainer-ship of dw_dmac. Signed-off-by: Viresh Kumar Acked-by: Havard Skinnemoen Signed-off-by: Vinod Koul

dmaengine: shdma: Update SH_DMAC_MAX_CHANNELS to 20

2011-05-25T02:36:17Z

Update SH_DMAC_MAX_CHANNELS to support the 20 DMA channels included in the sh73a0 SY-DMAC hardware. Signed-off-by: Magnus Damm Signed-off-by: Paul Mundt

dmaengine: shdma: Fix SH_DMAC_MAX_CHANNELS handling

2011-05-25T02:36:15Z

Fix the shdma.c handing of SH_DMAC_MAX_CHANNELS to avoid overwriting the chan_irq[] and chan_flag[] arrays in the case of pdata->channel_num is larger than SH_DMAC_MAX_CHANNELS. With this patch applied up to SH_DMAC_MAX_CHANNELS will be used by the shdma.c driver. If more channels are available in the platform data the user will be notified on the console. Signed-off-by: Magnus Damm Signed-off-by: Paul Mundt