linux-toradex.git/drivers/dma/pch_dma.c, branch v3.0.88 Linux kernel for Apalis and Colibri modules pch_dma: Use GFP_ATOMIC because called from interrupt context 2013-05-19T17:04:47+00:00 Tomoya MORINAGA tomoya.rohm@gmail.com 2013-02-12T02:25:33+00:00 b89396eaa22b921245b4d30f7e26e406e89aa51c commit 5c1ef59168c485318e40ba485c1eba57d81d0faa upstream. pdc_desc_get() is called from pd_prep_slave_sg, and the function is called from interrupt context(e.g. Uart driver "pch_uart.c"). In fact, I saw kernel error message. So, GFP_ATOMIC must be used not GFP_NOIO. Signed-off-by: Tomoya MORINAGA <tomoya.rohm@gmail.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 5c1ef59168c485318e40ba485c1eba57d81d0faa upstream.

pdc_desc_get() is called from pd_prep_slave_sg, and the function is
called from interrupt context(e.g. Uart driver "pch_uart.c").
In fact, I saw kernel error message.
So, GFP_ATOMIC must be used not GFP_NOIO.

Signed-off-by: Tomoya MORINAGA <tomoya.rohm@gmail.com>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
pch_dma: Support new device LAPIS Semiconductor ML7831 IOH 2012-04-22T23:21:44+00:00 Tomoya MORINAGA tomoya.rohm@gmail.com 2011-11-17T07:14:23+00:00 127f90d6ff47e9095261f442d1ad511930cd7fd4 commit ca7fe2db892dcf91b2c72ee352eda4ff867903a7 upstream. ML7831 is companion chip for Intel Atom E6xx series. Signed-off-by: Tomoya MORINAGA <tomoya.rohm@gmail.com> Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit ca7fe2db892dcf91b2c72ee352eda4ff867903a7 upstream.

ML7831 is companion chip for Intel Atom E6xx series.

Signed-off-by: Tomoya MORINAGA <tomoya.rohm@gmail.com>
Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
pch_dma: Fix suspend issue 2012-04-22T23:21:44+00:00 Tomoya MORINAGA tomoya-linux@dsn.lapis-semi.com 2011-10-11T12:43:21+00:00 5e051465ef7ef611bcf6cb83d4dd85483417276f 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 <tomoya-linux@dsn.lapis-semi.com> Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com> Signed-off-by: Tomoya MORINAGA <tomoya.rohm@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
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 <tomoya-linux@dsn.lapis-semi.com>
Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
Signed-off-by: Tomoya MORINAGA <tomoya.rohm@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
pch_dma: Fix CTL register access issue 2012-04-22T23:21:44+00:00 Tomoya MORINAGA tomoya-linux@dsn.okisemi.com 2011-07-14T00:52:38+00:00 c9f52d613590b10630ab8bb222ae05c551389425 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 <tomoya-linux@dsn.okisemi.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com> Signed-off-by: Tomoya MORINAGA <tomoya.rohm@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
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 <tomoya-linux@dsn.okisemi.com>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Tomoya MORINAGA <tomoya.rohm@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
pch_dma: Fix channel locking 2012-04-22T23:21:44+00:00 Alexander Stein alexander.stein@systec-electronic.com 2011-06-22T15:05:33+00:00 724d7ad550fb6ed11ce40425eb0206f90faf665a 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: [<c123b9a1>] pdc_desc_get+0x16/0xab {HARDIRQ-ON-W} state was registered at: [<c104fe28>] mark_irqflags+0xbd/0x11a [<c1050386>] __lock_acquire+0x501/0x6bb [<c1050945>] lock_acquire+0x63/0x7b [<c131c51d>] _raw_spin_lock_bh+0x43/0x51 [<c123bee4>] pd_alloc_chan_resources+0x92/0x11e [<c123ad62>] dma_chan_get+0x9b/0x107 [<c123b2d1>] __dma_request_channel+0x61/0xdc [<c11ba24b>] pch_request_dma+0x61/0x19e [<c11bb3b8>] pch_uart_startup+0x16a/0x1a2 [<c11b8446>] uart_startup+0x87/0x147 [<c11b9183>] uart_open+0x117/0x13e [<c11a5c7d>] tty_open+0x23c/0x34c [<c1097705>] chrdev_open+0x140/0x15f [<c10930a6>] __dentry_open.clone.14+0x14a/0x22b [<c1093dfb>] nameidata_to_filp+0x36/0x40 [<c109f28b>] do_last+0x513/0x635 [<c109f4af>] path_openat+0x9c/0x2aa [<c109f6e4>] do_filp_open+0x27/0x69 [<c1093f02>] do_sys_open+0xfd/0x184 [<c1093fad>] sys_open+0x24/0x2a [<c131d58c>] sysenter_do_call+0x12/0x32 irq event stamp: 2522 hardirqs last enabled at (2521): [<c131ca3b>] _raw_spin_unlock_irqrestore+0x36/0x52 hardirqs last disabled at (2522): [<c131db27>] common_interrupt+0x27/0x34 softirqs last enabled at (2354): [<c102fa11>] __do_softirq+0x10a/0x11a softirqs last disabled at (2299): [<c10041a4>] do_softirq+0x57/0xa4 other info that might help us debug this: 2 locks held by rs232/822: #0: (&tty->atomic_write_lock){+.+.+.}, at: [<c11a4b7a>] tty_write_lock+0x14/0x3c #1: (&port_lock_key){-.....}, at: [<c11bad72>] pch_uart_interrupt+0x17/0x1e9 stack backtrace: Pid: 822, comm: rs232 Not tainted 2.6.39+ #89 Call Trace: [<c1319f90>] ? printk+0x19/0x1b [<c104f893>] print_usage_bug+0x184/0x18f [<c104e5b1>] ? print_irq_inversion_bug+0x10e/0x10e [<c104f943>] mark_lock_irq+0xa5/0x1f6 [<c104fc9c>] mark_lock+0x208/0x2d7 [<c104fdc0>] mark_irqflags+0x55/0x11a [<c1050386>] __lock_acquire+0x501/0x6bb [<c10042ee>] ? dump_trace+0x92/0xb6 [<c1050945>] lock_acquire+0x63/0x7b [<c123b9a1>] ? pdc_desc_get+0x16/0xab [<c131c2d0>] _raw_spin_lock+0x3e/0x4c [<c123b9a1>] ? pdc_desc_get+0x16/0xab [<c123b9a1>] pdc_desc_get+0x16/0xab [<c10504d8>] ? __lock_acquire+0x653/0x6bb [<c123bb2c>] pd_prep_slave_sg+0x7c/0x1cb [<c1006c3f>] ? nommu_map_sg+0x6e/0x81 [<c11bace6>] dma_handle_tx+0x2cf/0x344 [<c11bad72>] ? pch_uart_interrupt+0x17/0x1e9 [<c11baebb>] pch_uart_interrupt+0x160/0x1e9 [<c10642fb>] handle_irq_event_percpu+0x25/0x127 [<c1064429>] handle_irq_event+0x2c/0x43 [<c1065e0d>] ? handle_fasteoi_irq+0x84/0x84 [<c1065eb9>] handle_edge_irq+0xac/0xce <IRQ> [<c1003ecb>] ? do_IRQ+0x38/0x9d [<c131db2e>] ? common_interrupt+0x2e/0x34 [<c105007b>] ? __lock_acquire+0x1f6/0x6bb [<c131ca3d>] ? _raw_spin_unlock_irqrestore+0x38/0x52 [<c11b798b>] ? uart_start+0x2d/0x32 [<c11b7998>] ? uart_flush_chars+0x8/0xa [<c11a7962>] ? n_tty_write+0x12c/0x1c6 [<c1027a73>] ? try_to_wake_up+0x251/0x251 [<c11a4d0b>] ? tty_write+0x169/0x1dc [<c11a7836>] ? n_tty_ioctl+0xb7/0xb7 [<c1094841>] ? vfs_write+0x91/0x10d [<c11a4ba2>] ? tty_write_lock+0x3c/0x3c [<c1094a69>] ? sys_write+0x3e/0x63 [<c131d58c>] ? sysenter_do_call+0x12/0x32 Signed-off-by: Alexander Stein <alexander.stein@systec-electronic.com> Tested-by: Tomoya MORINAGA <tomoya-linux@dsn.okisemi.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com> Signed-off-by: Tomoya MORINAGA <tomoya.rohm@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
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: [<c123b9a1>] pdc_desc_get+0x16/0xab
{HARDIRQ-ON-W} state was registered at:
  [<c104fe28>] mark_irqflags+0xbd/0x11a
  [<c1050386>] __lock_acquire+0x501/0x6bb
  [<c1050945>] lock_acquire+0x63/0x7b
  [<c131c51d>] _raw_spin_lock_bh+0x43/0x51
  [<c123bee4>] pd_alloc_chan_resources+0x92/0x11e
  [<c123ad62>] dma_chan_get+0x9b/0x107
  [<c123b2d1>] __dma_request_channel+0x61/0xdc
  [<c11ba24b>] pch_request_dma+0x61/0x19e
  [<c11bb3b8>] pch_uart_startup+0x16a/0x1a2
  [<c11b8446>] uart_startup+0x87/0x147
  [<c11b9183>] uart_open+0x117/0x13e
  [<c11a5c7d>] tty_open+0x23c/0x34c
  [<c1097705>] chrdev_open+0x140/0x15f
  [<c10930a6>] __dentry_open.clone.14+0x14a/0x22b
  [<c1093dfb>] nameidata_to_filp+0x36/0x40
  [<c109f28b>] do_last+0x513/0x635
  [<c109f4af>] path_openat+0x9c/0x2aa
  [<c109f6e4>] do_filp_open+0x27/0x69
  [<c1093f02>] do_sys_open+0xfd/0x184
  [<c1093fad>] sys_open+0x24/0x2a
  [<c131d58c>] sysenter_do_call+0x12/0x32
irq event stamp: 2522
hardirqs last  enabled at (2521): [<c131ca3b>] _raw_spin_unlock_irqrestore+0x36/0x52
hardirqs last disabled at (2522): [<c131db27>] common_interrupt+0x27/0x34
softirqs last  enabled at (2354): [<c102fa11>] __do_softirq+0x10a/0x11a
softirqs last disabled at (2299): [<c10041a4>] do_softirq+0x57/0xa4

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

stack backtrace:
Pid: 822, comm: rs232 Not tainted 2.6.39+ #89
Call Trace:
 [<c1319f90>] ? printk+0x19/0x1b
 [<c104f893>] print_usage_bug+0x184/0x18f
 [<c104e5b1>] ? print_irq_inversion_bug+0x10e/0x10e
 [<c104f943>] mark_lock_irq+0xa5/0x1f6
 [<c104fc9c>] mark_lock+0x208/0x2d7
 [<c104fdc0>] mark_irqflags+0x55/0x11a
 [<c1050386>] __lock_acquire+0x501/0x6bb
 [<c10042ee>] ? dump_trace+0x92/0xb6
 [<c1050945>] lock_acquire+0x63/0x7b
 [<c123b9a1>] ? pdc_desc_get+0x16/0xab
 [<c131c2d0>] _raw_spin_lock+0x3e/0x4c
 [<c123b9a1>] ? pdc_desc_get+0x16/0xab
 [<c123b9a1>] pdc_desc_get+0x16/0xab
 [<c10504d8>] ? __lock_acquire+0x653/0x6bb
 [<c123bb2c>] pd_prep_slave_sg+0x7c/0x1cb
 [<c1006c3f>] ? nommu_map_sg+0x6e/0x81
 [<c11bace6>] dma_handle_tx+0x2cf/0x344
 [<c11bad72>] ? pch_uart_interrupt+0x17/0x1e9
 [<c11baebb>] pch_uart_interrupt+0x160/0x1e9
 [<c10642fb>] handle_irq_event_percpu+0x25/0x127
 [<c1064429>] handle_irq_event+0x2c/0x43
 [<c1065e0d>] ? handle_fasteoi_irq+0x84/0x84
 [<c1065eb9>] handle_edge_irq+0xac/0xce
 <IRQ>  [<c1003ecb>] ? do_IRQ+0x38/0x9d
 [<c131db2e>] ? common_interrupt+0x2e/0x34
 [<c105007b>] ? __lock_acquire+0x1f6/0x6bb
 [<c131ca3d>] ? _raw_spin_unlock_irqrestore+0x38/0x52
 [<c11b798b>] ? uart_start+0x2d/0x32
 [<c11b7998>] ? uart_flush_chars+0x8/0xa
 [<c11a7962>] ? n_tty_write+0x12c/0x1c6
 [<c1027a73>] ? try_to_wake_up+0x251/0x251
 [<c11a4d0b>] ? tty_write+0x169/0x1dc
 [<c11a7836>] ? n_tty_ioctl+0xb7/0xb7
 [<c1094841>] ? vfs_write+0x91/0x10d
 [<c11a4ba2>] ? tty_write_lock+0x3c/0x3c
 [<c1094a69>] ? sys_write+0x3e/0x63
 [<c131d58c>] ? sysenter_do_call+0x12/0x32

Signed-off-by: Alexander Stein <alexander.stein@systec-electronic.com>
Tested-by: Tomoya MORINAGA <tomoya-linux@dsn.okisemi.com>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Tomoya MORINAGA <tomoya.rohm@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
pch_dma: fix DMA issue(ch8-ch11) 2012-04-22T23:21:44+00:00 Tomoya MORINAGA tomoya-linux@dsn.okisemi.com 2011-05-31T01:34:45+00:00 e65f3a58ad648c5b33c97ef5861b590d0dd8f74c 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 <tomoya-linux@dsn.okisemi.com> Mon, 9 May 2011 07:09:38 +0000 (16:09 +0900) committer Vinod Koul <vinod.koul@intel.com> 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 <tomoya-linux@dsn.okisemi.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com> Signed-off-by: Tomoya MORINAGA <tomoya.rohm@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
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 <tomoya-linux@dsn.okisemi.com>
	Mon, 9 May 2011 07:09:38 +0000 (16:09 +0900)
committer	Vinod Koul <vinod.koul@intel.com>
	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 <tomoya-linux@dsn.okisemi.com>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Tomoya MORINAGA <tomoya.rohm@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
pch_dma: modify pci device table definition 2011-05-09T11:42:24+00:00 Tomoya MORINAGA tomoya-linux@dsn.okisemi.com 2011-05-09T07:09:40+00:00 eb8590b504caacb029dea4540e0b0dcc98da4381 Signed-off-by: Tomoya MORINAGA <tomoya-linux@dsn.okisemi.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com> 
Signed-off-by: Tomoya MORINAGA <tomoya-linux@dsn.okisemi.com>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
pch_dma: Support new device ML7223 IOH 2011-05-09T11:42:23+00:00 Tomoya MORINAGA tomoya-linux@dsn.okisemi.com 2011-05-09T07:09:39+00:00 c0dfc04ac96847913a791f5459f4ac83a81a4745 Support new device OKI SEMICONDUCTOR ML7223 IOH(Input/Output Hub). The ML7223 IOH is for MP(Media Phone) use. The ML7223 is companion chip for Intel Atom E6xx series. The ML7223 is completely compatible for Intel EG20T PCH. Signed-off-by: Tomoya MORINAGA <tomoya-linux@dsn.okisemi.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com> 
Support new device OKI SEMICONDUCTOR ML7223 IOH(Input/Output Hub).
The ML7223 IOH is for MP(Media Phone) use.
The ML7223 is companion chip for Intel Atom E6xx series.
The ML7223 is completely compatible for Intel EG20T PCH.

Signed-off-by: Tomoya MORINAGA <tomoya-linux@dsn.okisemi.com>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
pch_dma: Support I2S for ML7213 IOH 2011-05-09T11:42:23+00:00 Tomoya MORINAGA tomoya-linux@dsn.okisemi.com 2011-05-09T07:09:38+00:00 194f5f2706c7472f9c6bb2d17fa788993606581f Support I2S device for ML7213 IOH Signed-off-by: Tomoya MORINAGA <tomoya-linux@dsn.okisemi.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com> 
Support I2S device for ML7213 IOH

Signed-off-by: Tomoya MORINAGA <tomoya-linux@dsn.okisemi.com>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
pch_dma: Fix DMA setting issue 2011-05-09T11:42:23+00:00 Tomoya MORINAGA tomoya-linux@dsn.okisemi.com 2011-05-09T07:09:37+00:00 60092d0bde4c8741198da4a69b693d3709385bf1 Currently, Direct-Start mode(*) is enabled. Our IOH's devices must not use this mode. This causes unexpected behavior. This patch deletes Direct-Start setting. (*) This mode is used in order for CPU to generate the DMA request. Signed-off-by: Tomoya MORINAGA <tomoya-linux@dsn.okisemi.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com> 
Currently, Direct-Start mode(*) is enabled.
Our IOH's devices must not use this mode.
This causes unexpected behavior.
This patch deletes Direct-Start setting.
(*) This mode is used in order for CPU to generate the DMA request.

Signed-off-by: Tomoya MORINAGA <tomoya-linux@dsn.okisemi.com>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>