linux-toradex.git/drivers/dma, branch v3.0.41

dmaengine: at_hdmac: remove clear-on-read in atc_dostart()

2012-05-07T15:56:33+00:00

commit ed8b0d67f33518a16c6b2450fe5ebebf180c2d04 upstream.

This loop on EBCISR register was designed to clear IRQ sources before enabling
a DMA channel. This register is clear-on-read so a race condition can appear if
another channel is already active and has just finished its transfer.
Removing this read on EBCISR is fixing the issue as there is no case where an IRQ
could be pending: we already make sure that this register is drained at probe()
time and during resume.

Signed-off-by: Nicolas Ferre 
Signed-off-by: Vinod Koul 
Signed-off-by: Greg Kroah-Hartman

pch_dma: Support new device LAPIS Semiconductor ML7831 IOH

2012-04-22T23:21:44+00:00

commit ca7fe2db892dcf91b2c72ee352eda4ff867903a7 upstream.

ML7831 is companion chip for Intel Atom E6xx series.

Signed-off-by: Tomoya MORINAGA 
Signed-off-by: Vinod Koul 
Signed-off-by: Greg Kroah-Hartman

pch_dma: Fix suspend issue

2012-04-22T23:21:44+00:00

commit c43f1508686e8e4746012bf87995085eeb0f5307 upstream.

Currently, executing suspend/hibernation,
memory access violation occurs.

In pch_dma_save_regs() called by suspend(),
you can see the following code.

static void pch_dma_save_regs(struct pch_dma *pd)
{
snip...
        list_for_each_entry_safe(chan, _c, &pd->dma.channels, device_node) {
                pd_chan = to_pd_chan(chan);

                pd->ch_regs[i].dev_addr = channel_readl(pd_chan, DEV_ADDR);
                pd->ch_regs[i].mem_addr = channel_readl(pd_chan, MEM_ADDR);
                pd->ch_regs[i].size = channel_readl(pd_chan, SIZE);
                pd->ch_regs[i].next = channel_readl(pd_chan, NEXT);

                i++;
        }
}

Max loop count is 12 defined at pci_table.
So, this caused memory access violation.

This patch fixes the issue
 - Modify array size (MAX_CHAN_NR)

Signed-off-by: Tomoya MORINAGA 
Signed-off-by: Vinod Koul 
Signed-off-by: Tomoya MORINAGA 
Signed-off-by: Greg Kroah-Hartman

pch_dma: Fix CTL register access issue

2012-04-22T23:21:44+00:00

commit 0b052f4a088ddc47a5da23dd733522241314cfb4 upstream.

Currently, Mode-Control register is accessed by read-modify-write.

According to DMA hardware specifications datasheet, prohibits this method.
Because this register resets to 0 by DMA HW after DMA transfer completes.
Thus, current read-modify-write processing can cause unexpected behavior.

The datasheet says in case of writing Mode-Control register, set the value for only target channel, the others must set '11b'.
e.g. Set DMA0=01b  DMA11=10b
CTL0=33333331h
CTL2=00002333h

NOTE:
CTL0 includes DMA0~7 Mode-Control register.
CTL2 includes DMA8~11 Mode-Control register.

This patch modifies the issue.

Signed-off-by: Tomoya MORINAGA 
Signed-off-by: Vinod Koul 
Signed-off-by: Tomoya MORINAGA 
Signed-off-by: Greg Kroah-Hartman

pch_dma: Fix channel locking

2012-04-22T23:21:44+00:00

commit 70f18915846f092e0e1c988f1726a532fa3ab3a1 upstream.

Fix for the following INFO message

=================================
[ INFO: inconsistent lock state ]
2.6.39+ #89
---------------------------------
inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage.
rs232/822 [HC1[1]:SC0[0]:HE0:SE1] takes:
 (&(&pd_chan->lock)->rlock){?.....}, at: [] pdc_desc_get+0x16/0xab
{HARDIRQ-ON-W} state was registered at:
  [] mark_irqflags+0xbd/0x11a
  [] __lock_acquire+0x501/0x6bb
  [] lock_acquire+0x63/0x7b
  [] _raw_spin_lock_bh+0x43/0x51
  [] pd_alloc_chan_resources+0x92/0x11e
  [] dma_chan_get+0x9b/0x107
  [] __dma_request_channel+0x61/0xdc
  [] pch_request_dma+0x61/0x19e
  [] pch_uart_startup+0x16a/0x1a2
  [] uart_startup+0x87/0x147
  [] uart_open+0x117/0x13e
  [] tty_open+0x23c/0x34c
  [] chrdev_open+0x140/0x15f
  [] __dentry_open.clone.14+0x14a/0x22b
  [] nameidata_to_filp+0x36/0x40
  [] do_last+0x513/0x635
  [] path_openat+0x9c/0x2aa
  [] do_filp_open+0x27/0x69
  [] do_sys_open+0xfd/0x184
  [] sys_open+0x24/0x2a
  [] sysenter_do_call+0x12/0x32
irq event stamp: 2522
hardirqs last  enabled at (2521): [] _raw_spin_unlock_irqrestore+0x36/0x52
hardirqs last disabled at (2522): [] common_interrupt+0x27/0x34
softirqs last  enabled at (2354): [] __do_softirq+0x10a/0x11a
softirqs last disabled at (2299): [] do_softirq+0x57/0xa4

other info that might help us debug this:
2 locks held by rs232/822:
 #0:  (&tty->atomic_write_lock){+.+.+.}, at: [] tty_write_lock+0x14/0x3c
 #1:  (&port_lock_key){-.....}, at: [] pch_uart_interrupt+0x17/0x1e9

stack backtrace:
Pid: 822, comm: rs232 Not tainted 2.6.39+ #89
Call Trace:
 [] ? printk+0x19/0x1b
 [] print_usage_bug+0x184/0x18f
 [] ? print_irq_inversion_bug+0x10e/0x10e
 [] mark_lock_irq+0xa5/0x1f6
 [] mark_lock+0x208/0x2d7
 [] mark_irqflags+0x55/0x11a
 [] __lock_acquire+0x501/0x6bb
 [] ? dump_trace+0x92/0xb6
 [] lock_acquire+0x63/0x7b
 [] ? pdc_desc_get+0x16/0xab
 [] _raw_spin_lock+0x3e/0x4c
 [] ? pdc_desc_get+0x16/0xab
 [] pdc_desc_get+0x16/0xab
 [] ? __lock_acquire+0x653/0x6bb
 [] pd_prep_slave_sg+0x7c/0x1cb
 [] ? nommu_map_sg+0x6e/0x81
 [] dma_handle_tx+0x2cf/0x344
 [] ? pch_uart_interrupt+0x17/0x1e9
 [] pch_uart_interrupt+0x160/0x1e9
 [] handle_irq_event_percpu+0x25/0x127
 [] handle_irq_event+0x2c/0x43
 [] ? handle_fasteoi_irq+0x84/0x84
 [] handle_edge_irq+0xac/0xce
   [] ? do_IRQ+0x38/0x9d
 [] ? common_interrupt+0x2e/0x34
 [] ? __lock_acquire+0x1f6/0x6bb
 [] ? _raw_spin_unlock_irqrestore+0x38/0x52
 [] ? uart_start+0x2d/0x32
 [] ? uart_flush_chars+0x8/0xa
 [] ? n_tty_write+0x12c/0x1c6
 [] ? try_to_wake_up+0x251/0x251
 [] ? tty_write+0x169/0x1dc
 [] ? n_tty_ioctl+0xb7/0xb7
 [] ? vfs_write+0x91/0x10d
 [] ? tty_write_lock+0x3c/0x3c
 [] ? sys_write+0x3e/0x63
 [] ? sysenter_do_call+0x12/0x32

Signed-off-by: Alexander Stein 
Tested-by: Tomoya MORINAGA 
Signed-off-by: Vinod Koul 
Signed-off-by: Tomoya MORINAGA 
Signed-off-by: Greg Kroah-Hartman

pch_dma: fix DMA issue(ch8-ch11)

2012-04-22T23:21:44+00:00

commit c3d4913cd4cd469cbf29d411293e937729e83f3a upstream.

ISSUE: In case PCH_DMA with I2S communications with ch8~ch11, sometimes I2S data
is not send correctly.
CAUSE: The following patch I submitted before was not enough modification for
supporting DMA ch8~ch11. The modification for status register of ch8~11 was not
enough.

pch_dma: Support I2S for ML7213 IOH
author	Tomoya MORINAGA 
	Mon, 9 May 2011 07:09:38 +0000 (16:09 +0900)
committer	Vinod Koul 
	Mon, 9 May 2011 11:42:23 +0000 (16:42 +0530)
commit	194f5f2706c7472f9c6bb2d17fa788993606581f
tree	c9d4903ea02b18939a4f390956a48be1a3734517
parent	60092d0bde4c8741198da4a69b693d3709385bf1

This patch fixes the issue.
We can confirm PCH_DMA with I2S communications with ch8~ch11 works well.

Signed-off-by: Tomoya MORINAGA 
Signed-off-by: Vinod Koul 
Signed-off-by: Tomoya MORINAGA 
Signed-off-by: Greg Kroah-Hartman

at_hdmac: bugfix for enabling channel irq

2012-02-13T19:06:07+00:00

commit bda3a47c886664e86ee14eb79e9072b9e341f575 upstream.

commit 463894705e4089d0ff69e7d877312d496ac70e5b deleted redundant
chan_id and chancnt initialization in dma drivers as this is done
in dma_async_device_register().

However, atc_enable_irq() relied on chan_id set before registering
the device, what left only channel 0 functional for this driver.

This patch introduces atc_enable/disable_chan_irq() as a variant
of atc_enable/disable_irq() with the channel as explicit argument.

Signed-off-by: Nikolaus Voss 
Signed-off-by: Nicolas Ferre 
Signed-off-by: Vinod Koul 
Signed-off-by: Greg Kroah-Hartman

dmaengine: shdma: SH_DMAC_MAX_CHANNELS message fix

2011-06-14T06:03:07+00:00

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:43+00:00

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:03+00:00

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