| Age | Commit message (Collapse) | Author |
|---|
|
dmaengine drivers should always use sg_dma_address instead of sg_phys to get the
addresses for the transfer from a sg element.
To quote Russel King:
sg_phys(sg) of course has nothing to do with DMA addresses. It's the
physical address _to the CPU_ of the memory associated with the scatterlist
entry. That may, or may not have the same value for the DMA engine,
particularly if IOMMUs are involved.
And if these drivers are used on ARM, they must be fixed, sooner rather
than later. There's patches in the works which will mean we will end up
with IOMMU support in the DMA mapping later, which means everything I've
said above will become reality.
The patch has been generated using the following coccinelle patch:
<smpl>
@@
struct scatterlist *sg;
@@
-sg_phys(sg)
+sg_dma_address(sg)
</smpl>
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
|
|
Add context parameter to device_prep_slave_sg() and device_prep_dma_cyclic()
interfaces to allow passing client/target specific information associated
with the data transfer.
Modify all affected DMA engine drivers.
Signed-off-by: Alexandre Bounine <alexandre.bounine@idt.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
|
|
Provide a common function to initialize a channels cookie values.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Tested-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Jassi Brar <jassisinghbrar@gmail.com>
[imx-sdma.c & mxs-dma.c]
Tested-by: Shawn Guo <shawn.guo@linaro.org>
Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
|
|
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 <rmk+kernel@arm.linux.org.uk>
Tested-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Jassi Brar <jassisinghbrar@gmail.com>
[imx-sdma.c & mxs-dma.c]
Tested-by: Shawn Guo <shawn.guo@linaro.org>
Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
|
|
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 <rmk+kernel@arm.linux.org.uk>
Tested-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Jassi Brar <jassisinghbrar@gmail.com>
[imx-sdma.c & mxs-dma.c]
Tested-by: Shawn Guo <shawn.guo@linaro.org>
Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
|
|
Add a local private header file to contain definitions and declarations
which should only be used by DMA engine drivers.
We also fix linux/dmaengine.h to use LINUX_DMAENGINE_H to guard against
multiple inclusion.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Tested-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Jassi Brar <jassisinghbrar@gmail.com>
[imx-sdma.c & mxs-dma.c]
Tested-by: Shawn Guo <shawn.guo@linaro.org>
Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
|
|
Every DMA engine implementation declares a last completed dma cookie
in their private dma channel structures. This is pointless, and
forces driver specific code. Move this out into the common dma_chan
structure.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Tested-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Jassi Brar <jassisinghbrar@gmail.com>
[imx-sdma.c & mxs-dma.c]
Tested-by: Shawn Guo <shawn.guo@linaro.org>
Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
|
|
resolved conflicts:
drivers/media/video/mx3_camera.c
|
|
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>
|
|
On October 1 in 2011,
OKI SEMICONDUCTOR Co., Ltd. changed the company name in to LAPIS Semiconductor
Co., Ltd.
Signed-off-by: Tomoya MORINAGA <tomoya.rohm@gmail.com>
Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
|
|
fixup usage of dma direction by introducing dma_transfer_direction,
this patch moves dma/drivers/* to use new enum
Cc: Jassi Brar <jaswinder.singh@linaro.org>
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
Cc: Viresh Kumar <viresh.kumar@st.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Nicolas Ferre <nicolas.ferre@atmel.com>
Cc: Mika Westerberg <mika.westerberg@iki.fi>
Cc: H Hartley Sweeten <hartleys@visionengravers.com>
Cc: Li Yang <leoli@freescale.com>
Cc: Zhang Wei <zw@zh-kernel.org>
Cc: Sascha Hauer <s.hauer@pengutronix.de>
Cc: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Cc: Shawn Guo <shawn.guo@freescale.com>
Cc: Yong Wang <yong.y.wang@intel.com>
Cc: Tomoya MORINAGA <tomoya-linux@dsn.lapis-semi.com>
Cc: Boojin Kim <boojin.kim@samsung.com>
Cc: Barry Song <Baohua.Song@csr.com>
Acked-by: Mika Westerberg <mika.westerberg@iki.fi>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Viresh Kumar <viresh.kumar@st.com>
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
|
|
nr_channels is defined in "struct pch_dma".
and struct pch_dma_chan is defined in "struct pch_dma".
So, "sizeof(struct pch_dma_chan) * nr_channels" is unnecessary.
Signed-off-by: Tomoya MORINAGA <tomoya-linux@dsn.lapis-semi.com>
Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
|
|
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>
|
|
dma_async_device_register will re-init chan_id and chancnt,
so whatever chan_id and chancnt are set in drivers, they will
be re-written by dma_async_device_register.
Cc: Nicolas Ferre <nicolas.ferre@atmel.com>
Cc: Viresh Kumar <viresh.kumar@st.com>
Cc: Vinod Koul <vinod.koul@intel.com>
Cc: Piotr Ziecik <kosmo@semihalf.com>
Cc: Yong Wang <yong.y.wang@intel.com>
Cc: Jaswinder Singh <jassi.brar@samsung.com>
Cc: Pelagicore AB <info@pelagicore.com>
Signed-off-by: Barry Song <Baohua.Song@csr.com>
Acked-by: Viresh Kumar <viresh.kumar@st.com>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
|
|
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>
|
|
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>
|
|
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-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>
|
|
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>
|
|
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>
|
|
Fix checkpatch warnings.
Signed-off-by: Tomoya MORINAGA <tomoya-linux@dsn.okisemi.com>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
|
|
Currently, even-channel number is set as tx direction and odd is set as rx.
However, though video-in uses ch6, the direction is not tx but rx.
This patch sets video-in's DMA direction correctly.
Signed-off-by: Tomoya MORINAGA <tomoya-linux@dsn.okisemi.com>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
|
|
In the function pdc_desc_get(), var 'i' is not
initialized before use. This patch fixes it.
Signed-off-by: Liu Yuan <tailai.ly@taobao.com>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
|
|
When CONFIG_PM=n, we get the following warning:
drivers/dma/pch_dma.c:741: warning: ‘pch_dma_suspend’ defined but not used
drivers/dma/pch_dma.c:755: warning: ‘pch_dma_resume’ defined but not used
To fix it, wrap pch_dma_{suspend,resume} and
pch_dma_{save,restore}_regs functions with CONFIG_PM.
Signed-off-by: Rakib Mullick <rakib.mullick@gmail.com>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
|
|
set the number of array correctly.
Signed-off-by: Tomoya MORINAGA <tomoya-linux@dsn.okisemi.com>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
|
|
fix the following kernel error
------------[ cut here ]------------
WARNING: at kernel/softirq.c:159 _local_bh_enable_ip.clone.5+0x35/0x71()
Hardware name: To be filled by O.E.M.
Modules linked in: pch_uart pch_dma fuse mga drm cpufreq_ondemand acpi_cpufreq mperf ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables ipv6 uinput snd_hda_codec_realtek snd_hda_intel snd_hda_codec matroxfb_base snd_hwdep 8250_pnp snd_seq snd_seq_device matroxfb_DAC1064 snd_pcm joydev 8250 matroxfb_accel snd_timer matroxfb_Ti3026 ppdev pegasus parport_pc snd parport matroxfb_g450 g450_pll serial_core video output matroxfb_misc soundcore snd_page_alloc serio_raw pcspkr ext4 jbd2 crc16 sdhci_pci sdhci mmc_core floppy [last unloaded: scsi_wait_scan]
Pid: 0, comm: swapper Not tainted 2.6.37.upstream_check+ #8
Call Trace:
[<c0433add>] warn_slowpath_common+0x65/0x7a
[<c043825b>] ? _local_bh_enable_ip.clone.5+0x35/0x71
[<c0433b01>] warn_slowpath_null+0xf/0x13
[<c043825b>] _local_bh_enable_ip.clone.5+0x35/0x71
[<c043829f>] local_bh_enable_ip+0x8/0xa
[<c06ec471>] _raw_spin_unlock_bh+0x10/0x12
[<f82b57dd>] pd_prep_slave_sg+0xba/0x200 [pch_dma]
[<f82f7b7a>] pch_uart_interrupt+0x44d/0x6aa [pch_uart]
[<c046fa97>] handle_IRQ_event+0x1d/0x9e
[<c047146f>] handle_fasteoi_irq+0x90/0xc7
[<c04713df>] ? handle_fasteoi_irq+0x0/0xc7
<IRQ> [<c04045af>] ? do_IRQ+0x3e/0x89
[<c04035a9>] ? common_interrupt+0x29/0x30
[<c04400d8>] ? sys_getpriority+0x12d/0x1a2
[<c058bb2b>] ? arch_local_irq_enable+0x5/0xb
[<c058c740>] ? acpi_idle_enter_bm+0x22a/0x261
[<c0648b11>] ? cpuidle_idle_call+0x70/0xa1
[<c0401f44>] ? cpu_idle+0x49/0x6a
[<c06d9fc4>] ? rest_init+0x58/0x5a
[<c089e762>] ? start_kernel+0x2d0/0x2d5
[<c089e0ce>] ? i386_start_kernel+0xce/0xd5
Signed-off-by: Tomoya MORINAGA <tomoya-linux@dsn.okisemi.com>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
|
|
Support new device OKI SEMICONDUCTOR's ML7213 IOH(Input/Output Hub) which is for
IVI(In-Vehicle Infotainment) use.
The ML7213 is companion chip for Intel Atom E6xx series.
The ML7213 is completely compatible for Intel EG20T PCH.
Signed-off-by: Tomoya MORINAGA <tomoya-linux@dsn.okisemi.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
|
|
Currently, in case of using scatter/gather mode, head of data is not sent to
destination. The cause is second descriptor address is set to NEXT.
The NEXT must have head of descriptor address.
This patch sets head of descriptor address to the NEXT.
Acked-by: Yong Wang <youg.y.wang@intel.com>
Signed-off-by: Tomoya MORINAGA <tomoya-linux@dsn.okisemi.com>
[dan.j.williams@intel.com: fixed up usage of virt_to_phys()]
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
|
|
NULL-terminating pci_device_id in pch_dma.c and scx200_acb.c
for appying MODULE_DEVICE_TABLE (to publish modalias-es).
Signed-off-by: Dzianis Kahanovich <mahatma@eu.by>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
|
|
Use {read|write}l instead of __raw_{read|write}l since PCH DMA
controller is PCI device.
Signed-off-by: Yong Wang <yong.y.wang@intel.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
|
|
Topcliff PCH is the platform controller hub that is going to
be used in Intel's upcoming general embedded platforms. This
adds the driver for Topcliff PCH DMA controller. The DMA
channels are strictly for device to host or host to device
transfers and cannot be used for generic memcpy.
Signed-off-by: Yong Wang <yong.y.wang@intel.com>
[kill GFP_ATOMIC, kill __raw_{read|write}l, locking fixlet]
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
|
