* [PATCH v6 04/10] DMA: PL330: Add device tree support
From: Thomas Abraham @ 2011-10-10 18:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1318270538-30450-4-git-send-email-thomas.abraham@linaro.org>
For PL330 dma controllers instantiated from device tree, the channel
lookup is based on phandle of the dma controller and dma request id
specified by the client node. During probe, the private data of each
channel of the controller is set to point to the device node of the
dma controller. The 'chan_id' of the each channel is used as the
dma request id.
Client driver requesting dma channels specify the phandle of the
dma controller and the request id. The pl330 filter function
converts the phandle to the device node pointer and matches that
with channel's private data. If a match is found, the request id
from the client node and the 'chan_id' of the channel is matched.
A channel is found if both the values match.
Cc: Jassi Brar <jassisinghbrar@gmail.com>
Cc: Boojin Kim <boojin.kim@samsung.com>
Signed-off-by: Thomas Abraham <thomas.abraham@linaro.org>
Reviewed-by: Rob Herring <rob.herring@calxeda.com>
Acked-by: Jassi Brar <jassisinghbrar@gmail.com>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
---
.../devicetree/bindings/dma/arm-pl330.txt | 30 ++++++++++++++++++
drivers/dma/pl330.c | 33 +++++++++++++++++--
2 files changed, 59 insertions(+), 4 deletions(-)
create mode 100644 Documentation/devicetree/bindings/dma/arm-pl330.txt
diff --git a/Documentation/devicetree/bindings/dma/arm-pl330.txt b/Documentation/devicetree/bindings/dma/arm-pl330.txt
new file mode 100644
index 0000000..a4cd273
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/arm-pl330.txt
@@ -0,0 +1,30 @@
+* ARM PrimeCell PL330 DMA Controller
+
+The ARM PrimeCell PL330 DMA controller can move blocks of memory contents
+between memory and peripherals or memory to memory.
+
+Required properties:
+ - compatible: should include both "arm,pl330" and "arm,primecell".
+ - reg: physical base address of the controller and length of memory mapped
+ region.
+ - interrupts: interrupt number to the cpu.
+
+Example:
+
+ pdma0: pdma at 12680000 {
+ compatible = "arm,pl330", "arm,primecell";
+ reg = <0x12680000 0x1000>;
+ interrupts = <99>;
+ };
+
+Client drivers (device nodes requiring dma transfers from dev-to-mem or
+mem-to-dev) should specify the DMA channel numbers using a two-value pair
+as shown below.
+
+ [property name] = <[phandle of the dma controller] [dma request id]>;
+
+ where 'dma request id' is the dma request number which is connected
+ to the client controller. The 'property name' is recommended to be
+ of the form <name>-dma-channel.
+
+ Example: tx-dma-channel = <&pdma0 12>;
diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
index 992bf82..7a4ebf1 100644
--- a/drivers/dma/pl330.c
+++ b/drivers/dma/pl330.c
@@ -19,6 +19,7 @@
#include <linux/amba/pl330.h>
#include <linux/pm_runtime.h>
#include <linux/scatterlist.h>
+#include <linux/of.h>
#define NR_DEFAULT_DESC 16
@@ -277,6 +278,20 @@ bool pl330_filter(struct dma_chan *chan, void *param)
if (chan->device->dev->driver != &pl330_driver.drv)
return false;
+#ifdef CONFIG_OF
+ if (chan->device->dev->of_node) {
+ const __be32 *prop_value;
+ phandle phandle;
+ struct device_node *node;
+
+ prop_value = ((struct property *)param)->value;
+ phandle = be32_to_cpup(prop_value++);
+ node = of_find_node_by_phandle(phandle);
+ return ((chan->private == node) &&
+ (chan->chan_id == be32_to_cpup(prop_value)));
+ }
+#endif
+
peri_id = chan->private;
return *peri_id == (unsigned)param;
}
@@ -855,12 +870,17 @@ pl330_probe(struct amba_device *adev, const struct amba_id *id)
INIT_LIST_HEAD(&pd->channels);
/* Initialize channel parameters */
- num_chan = max(pdat ? pdat->nr_valid_peri : 0, (u8)pi->pcfg.num_chan);
+ num_chan = max(pdat ? pdat->nr_valid_peri : (u8)pi->pcfg.num_peri,
+ (u8)pi->pcfg.num_chan);
pdmac->peripherals = kzalloc(num_chan * sizeof(*pch), GFP_KERNEL);
for (i = 0; i < num_chan; i++) {
pch = &pdmac->peripherals[i];
- pch->chan.private = pdat ? &pdat->peri_id[i] : NULL;
+ if (!adev->dev.of_node)
+ pch->chan.private = pdat ? &pdat->peri_id[i] : NULL;
+ else
+ pch->chan.private = adev->dev.of_node;
+
INIT_LIST_HEAD(&pch->work_list);
spin_lock_init(&pch->lock);
pch->pl330_chid = NULL;
@@ -874,10 +894,15 @@ pl330_probe(struct amba_device *adev, const struct amba_id *id)
}
pd->dev = &adev->dev;
- if (pdat)
+ if (pdat) {
pd->cap_mask = pdat->cap_mask;
- else
+ } else {
dma_cap_set(DMA_MEMCPY, pd->cap_mask);
+ if (pi->pcfg.num_peri) {
+ dma_cap_set(DMA_SLAVE, pd->cap_mask);
+ dma_cap_set(DMA_CYCLIC, pd->cap_mask);
+ }
+ }
pd->device_alloc_chan_resources = pl330_alloc_chan_resources;
pd->device_free_chan_resources = pl330_free_chan_resources;
--
1.6.6.rc2
^ permalink raw reply related
* [PATCH v6 03/10] ARM: EXYNOS4: Modify platform data for pl330 driver
From: Thomas Abraham @ 2011-10-10 18:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1318270538-30450-3-git-send-email-thomas.abraham@linaro.org>
With the 'struct dma_pl330_peri' removed, the platfrom data for dma
driver can be simplified to a simple list of peripheral request ids.
Cc: Jassi Brar <jassisinghbrar@gmail.com>
Cc: Boojin Kim <boojin.kim@samsung.com>
Signed-off-by: Thomas Abraham <thomas.abraham@linaro.org>
Acked-by: Kukjin Kim <kgene.kim@samsung.com>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
---
arch/arm/mach-exynos4/dma.c | 223 ++++++++++++-------------------------------
1 files changed, 62 insertions(+), 161 deletions(-)
diff --git a/arch/arm/mach-exynos4/dma.c b/arch/arm/mach-exynos4/dma.c
index 9667c61..c3c0d17 100644
--- a/arch/arm/mach-exynos4/dma.c
+++ b/arch/arm/mach-exynos4/dma.c
@@ -35,95 +35,40 @@
static u64 dma_dmamask = DMA_BIT_MASK(32);
-struct dma_pl330_peri pdma0_peri[28] = {
- {
- .peri_id = (u8)DMACH_PCM0_RX,
- .rqtype = DEVTOMEM,
- }, {
- .peri_id = (u8)DMACH_PCM0_TX,
- .rqtype = MEMTODEV,
- }, {
- .peri_id = (u8)DMACH_PCM2_RX,
- .rqtype = DEVTOMEM,
- }, {
- .peri_id = (u8)DMACH_PCM2_TX,
- .rqtype = MEMTODEV,
- }, {
- .peri_id = (u8)DMACH_MSM_REQ0,
- }, {
- .peri_id = (u8)DMACH_MSM_REQ2,
- }, {
- .peri_id = (u8)DMACH_SPI0_RX,
- .rqtype = DEVTOMEM,
- }, {
- .peri_id = (u8)DMACH_SPI0_TX,
- .rqtype = MEMTODEV,
- }, {
- .peri_id = (u8)DMACH_SPI2_RX,
- .rqtype = DEVTOMEM,
- }, {
- .peri_id = (u8)DMACH_SPI2_TX,
- .rqtype = MEMTODEV,
- }, {
- .peri_id = (u8)DMACH_I2S0S_TX,
- .rqtype = MEMTODEV,
- }, {
- .peri_id = (u8)DMACH_I2S0_RX,
- .rqtype = DEVTOMEM,
- }, {
- .peri_id = (u8)DMACH_I2S0_TX,
- .rqtype = MEMTODEV,
- }, {
- .peri_id = (u8)DMACH_UART0_RX,
- .rqtype = DEVTOMEM,
- }, {
- .peri_id = (u8)DMACH_UART0_TX,
- .rqtype = MEMTODEV,
- }, {
- .peri_id = (u8)DMACH_UART2_RX,
- .rqtype = DEVTOMEM,
- }, {
- .peri_id = (u8)DMACH_UART2_TX,
- .rqtype = MEMTODEV,
- }, {
- .peri_id = (u8)DMACH_UART4_RX,
- .rqtype = DEVTOMEM,
- }, {
- .peri_id = (u8)DMACH_UART4_TX,
- .rqtype = MEMTODEV,
- }, {
- .peri_id = (u8)DMACH_SLIMBUS0_RX,
- .rqtype = DEVTOMEM,
- }, {
- .peri_id = (u8)DMACH_SLIMBUS0_TX,
- .rqtype = MEMTODEV,
- }, {
- .peri_id = (u8)DMACH_SLIMBUS2_RX,
- .rqtype = DEVTOMEM,
- }, {
- .peri_id = (u8)DMACH_SLIMBUS2_TX,
- .rqtype = MEMTODEV,
- }, {
- .peri_id = (u8)DMACH_SLIMBUS4_RX,
- .rqtype = DEVTOMEM,
- }, {
- .peri_id = (u8)DMACH_SLIMBUS4_TX,
- .rqtype = MEMTODEV,
- }, {
- .peri_id = (u8)DMACH_AC97_MICIN,
- .rqtype = DEVTOMEM,
- }, {
- .peri_id = (u8)DMACH_AC97_PCMIN,
- .rqtype = DEVTOMEM,
- }, {
- .peri_id = (u8)DMACH_AC97_PCMOUT,
- .rqtype = MEMTODEV,
- },
+u8 pdma0_peri[] = {
+ DMACH_PCM0_RX,
+ DMACH_PCM0_TX,
+ DMACH_PCM2_RX,
+ DMACH_PCM2_TX,
+ DMACH_MSM_REQ0,
+ DMACH_MSM_REQ2,
+ DMACH_SPI0_RX,
+ DMACH_SPI0_TX,
+ DMACH_SPI2_RX,
+ DMACH_SPI2_TX,
+ DMACH_I2S0S_TX,
+ DMACH_I2S0_RX,
+ DMACH_I2S0_TX,
+ DMACH_UART0_RX,
+ DMACH_UART0_TX,
+ DMACH_UART2_RX,
+ DMACH_UART2_TX,
+ DMACH_UART4_RX,
+ DMACH_UART4_TX,
+ DMACH_SLIMBUS0_RX,
+ DMACH_SLIMBUS0_TX,
+ DMACH_SLIMBUS2_RX,
+ DMACH_SLIMBUS2_TX,
+ DMACH_SLIMBUS4_RX,
+ DMACH_SLIMBUS4_TX,
+ DMACH_AC97_MICIN,
+ DMACH_AC97_PCMIN,
+ DMACH_AC97_PCMOUT,
};
struct dma_pl330_platdata exynos4_pdma0_pdata = {
.nr_valid_peri = ARRAY_SIZE(pdma0_peri),
- .peri = pdma0_peri,
+ .peri_id = pdma0_peri,
};
struct amba_device exynos4_device_pdma0 = {
@@ -142,86 +87,37 @@ struct amba_device exynos4_device_pdma0 = {
.periphid = 0x00041330,
};
-struct dma_pl330_peri pdma1_peri[25] = {
- {
- .peri_id = (u8)DMACH_PCM0_RX,
- .rqtype = DEVTOMEM,
- }, {
- .peri_id = (u8)DMACH_PCM0_TX,
- .rqtype = MEMTODEV,
- }, {
- .peri_id = (u8)DMACH_PCM1_RX,
- .rqtype = DEVTOMEM,
- }, {
- .peri_id = (u8)DMACH_PCM1_TX,
- .rqtype = MEMTODEV,
- }, {
- .peri_id = (u8)DMACH_MSM_REQ1,
- }, {
- .peri_id = (u8)DMACH_MSM_REQ3,
- }, {
- .peri_id = (u8)DMACH_SPI1_RX,
- .rqtype = DEVTOMEM,
- }, {
- .peri_id = (u8)DMACH_SPI1_TX,
- .rqtype = MEMTODEV,
- }, {
- .peri_id = (u8)DMACH_I2S0S_TX,
- .rqtype = MEMTODEV,
- }, {
- .peri_id = (u8)DMACH_I2S0_RX,
- .rqtype = DEVTOMEM,
- }, {
- .peri_id = (u8)DMACH_I2S0_TX,
- .rqtype = MEMTODEV,
- }, {
- .peri_id = (u8)DMACH_I2S1_RX,
- .rqtype = DEVTOMEM,
- }, {
- .peri_id = (u8)DMACH_I2S1_TX,
- .rqtype = MEMTODEV,
- }, {
- .peri_id = (u8)DMACH_UART0_RX,
- .rqtype = DEVTOMEM,
- }, {
- .peri_id = (u8)DMACH_UART0_TX,
- .rqtype = MEMTODEV,
- }, {
- .peri_id = (u8)DMACH_UART1_RX,
- .rqtype = DEVTOMEM,
- }, {
- .peri_id = (u8)DMACH_UART1_TX,
- .rqtype = MEMTODEV,
- }, {
- .peri_id = (u8)DMACH_UART3_RX,
- .rqtype = DEVTOMEM,
- }, {
- .peri_id = (u8)DMACH_UART3_TX,
- .rqtype = MEMTODEV,
- }, {
- .peri_id = (u8)DMACH_SLIMBUS1_RX,
- .rqtype = DEVTOMEM,
- }, {
- .peri_id = (u8)DMACH_SLIMBUS1_TX,
- .rqtype = MEMTODEV,
- }, {
- .peri_id = (u8)DMACH_SLIMBUS3_RX,
- .rqtype = DEVTOMEM,
- }, {
- .peri_id = (u8)DMACH_SLIMBUS3_TX,
- .rqtype = MEMTODEV,
- }, {
- .peri_id = (u8)DMACH_SLIMBUS5_RX,
- .rqtype = DEVTOMEM,
- }, {
- .peri_id = (u8)DMACH_SLIMBUS5_TX,
- .rqtype = MEMTODEV,
- },
+u8 pdma1_peri[] = {
+ DMACH_PCM0_RX,
+ DMACH_PCM0_TX,
+ DMACH_PCM1_RX,
+ DMACH_PCM1_TX,
+ DMACH_MSM_REQ1,
+ DMACH_MSM_REQ3,
+ DMACH_SPI1_RX,
+ DMACH_SPI1_TX,
+ DMACH_I2S0S_TX,
+ DMACH_I2S0_RX,
+ DMACH_I2S0_TX,
+ DMACH_I2S1_RX,
+ DMACH_I2S1_TX,
+ DMACH_UART0_RX,
+ DMACH_UART0_TX,
+ DMACH_UART1_RX,
+ DMACH_UART1_TX,
+ DMACH_UART3_RX,
+ DMACH_UART3_TX,
+ DMACH_SLIMBUS1_RX,
+ DMACH_SLIMBUS1_TX,
+ DMACH_SLIMBUS3_RX,
+ DMACH_SLIMBUS3_TX,
+ DMACH_SLIMBUS5_RX,
+ DMACH_SLIMBUS5_TX,
};
struct dma_pl330_platdata exynos4_pdma1_pdata = {
.nr_valid_peri = ARRAY_SIZE(pdma1_peri),
- .peri = pdma1_peri,
+ .peri_id = pdma1_peri,
};
struct amba_device exynos4_device_pdma1 = {
@@ -242,7 +138,12 @@ struct amba_device exynos4_device_pdma1 = {
static int __init exynos4_dma_init(void)
{
+ dma_cap_set(DMA_SLAVE, exynos4_pdma0_pdata.cap_mask);
+ dma_cap_set(DMA_CYCLIC, exynos4_pdma0_pdata.cap_mask);
amba_device_register(&exynos4_device_pdma0, &iomem_resource);
+
+ dma_cap_set(DMA_SLAVE, exynos4_pdma1_pdata.cap_mask);
+ dma_cap_set(DMA_CYCLIC, exynos4_pdma1_pdata.cap_mask);
amba_device_register(&exynos4_device_pdma1, &iomem_resource);
return 0;
--
1.6.6.rc2
^ permalink raw reply related
* [PATCH v6 02/10] DMA: PL330: Infer transfer direction from transfer request instead of platform data
From: Thomas Abraham @ 2011-10-10 18:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1318270538-30450-2-git-send-email-thomas.abraham@linaro.org>
The transfer direction for a channel can be inferred from the transfer
request and the need for specifying transfer direction in platfrom data
can be eliminated. So the structure definition 'struct dma_pl330_peri'
is no longer required.
The channel's private data is set to point to a channel id specified in
the platform data (instead of an instance of type 'struct dma_pl330_peri').
The filter function is correspondingly modified to match the channel id.
With the 'struct dma_pl330_peri' removed from platform data, the dma
controller transfer capabilities cannot be inferred any more. Hence,
the dma controller capabilities is specified using platform data.
Cc: Jassi Brar <jassisinghbrar@gmail.com>
Cc: Boojin Kim <boojin.kim@samsung.com>
Signed-off-by: Thomas Abraham <thomas.abraham@linaro.org>
Acked-by: Jassi Brar <jassisinghbrar@gmail.com>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
---
drivers/dma/pl330.c | 65 +++++++++++---------------------------------
include/linux/amba/pl330.h | 13 ++-------
2 files changed, 19 insertions(+), 59 deletions(-)
diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
index 5f1d24c..992bf82 100644
--- a/drivers/dma/pl330.c
+++ b/drivers/dma/pl330.c
@@ -272,13 +272,13 @@ static void dma_pl330_rqcb(void *token, enum pl330_op_err err)
bool pl330_filter(struct dma_chan *chan, void *param)
{
- struct dma_pl330_peri *peri;
+ u8 *peri_id;
if (chan->device->dev->driver != &pl330_driver.drv)
return false;
- peri = chan->private;
- return peri->peri_id == (unsigned)param;
+ peri_id = chan->private;
+ return *peri_id == (unsigned)param;
}
EXPORT_SYMBOL(pl330_filter);
@@ -512,7 +512,7 @@ pluck_desc(struct dma_pl330_dmac *pdmac)
static struct dma_pl330_desc *pl330_get_desc(struct dma_pl330_chan *pch)
{
struct dma_pl330_dmac *pdmac = pch->dmac;
- struct dma_pl330_peri *peri = pch->chan.private;
+ u8 *peri_id = pch->chan.private;
struct dma_pl330_desc *desc;
/* Pluck one desc from the pool of DMAC */
@@ -537,13 +537,7 @@ static struct dma_pl330_desc *pl330_get_desc(struct dma_pl330_chan *pch)
desc->txd.cookie = 0;
async_tx_ack(&desc->txd);
- if (peri) {
- desc->req.rqtype = peri->rqtype;
- desc->req.peri = pch->chan.chan_id;
- } else {
- desc->req.rqtype = MEMTOMEM;
- desc->req.peri = 0;
- }
+ desc->req.peri = peri_id ? pch->chan.chan_id : 0;
dma_async_tx_descriptor_init(&desc->txd, &pch->chan);
@@ -630,12 +624,14 @@ static struct dma_async_tx_descriptor *pl330_prep_dma_cyclic(
case DMA_TO_DEVICE:
desc->rqcfg.src_inc = 1;
desc->rqcfg.dst_inc = 0;
+ desc->req.rqtype = MEMTODEV;
src = dma_addr;
dst = pch->fifo_addr;
break;
case DMA_FROM_DEVICE:
desc->rqcfg.src_inc = 0;
desc->rqcfg.dst_inc = 1;
+ desc->req.rqtype = DEVTOMEM;
src = pch->fifo_addr;
dst = dma_addr;
break;
@@ -661,16 +657,12 @@ pl330_prep_dma_memcpy(struct dma_chan *chan, dma_addr_t dst,
{
struct dma_pl330_desc *desc;
struct dma_pl330_chan *pch = to_pchan(chan);
- struct dma_pl330_peri *peri = chan->private;
struct pl330_info *pi;
int burst;
if (unlikely(!pch || !len))
return NULL;
- if (peri && peri->rqtype != MEMTOMEM)
- return NULL;
-
pi = &pch->dmac->pif;
desc = __pl330_prep_dma_memcpy(pch, dst, src, len);
@@ -679,6 +671,7 @@ pl330_prep_dma_memcpy(struct dma_chan *chan, dma_addr_t dst,
desc->rqcfg.src_inc = 1;
desc->rqcfg.dst_inc = 1;
+ desc->req.rqtype = MEMTOMEM;
/* Select max possible burst size */
burst = pi->pcfg.data_bus_width / 8;
@@ -707,24 +700,13 @@ pl330_prep_slave_sg(struct dma_chan *chan, struct scatterlist *sgl,
{
struct dma_pl330_desc *first, *desc = NULL;
struct dma_pl330_chan *pch = to_pchan(chan);
- struct dma_pl330_peri *peri = chan->private;
struct scatterlist *sg;
unsigned long flags;
int i;
dma_addr_t addr;
- if (unlikely(!pch || !sgl || !sg_len || !peri))
- return NULL;
-
- /* Make sure the direction is consistent */
- if ((direction == DMA_TO_DEVICE &&
- peri->rqtype != MEMTODEV) ||
- (direction == DMA_FROM_DEVICE &&
- peri->rqtype != DEVTOMEM)) {
- dev_err(pch->dmac->pif.dev, "%s:%d Invalid Direction\n",
- __func__, __LINE__);
+ if (unlikely(!pch || !sgl || !sg_len))
return NULL;
- }
addr = pch->fifo_addr;
@@ -765,11 +747,13 @@ pl330_prep_slave_sg(struct dma_chan *chan, struct scatterlist *sgl,
if (direction == DMA_TO_DEVICE) {
desc->rqcfg.src_inc = 1;
desc->rqcfg.dst_inc = 0;
+ desc->req.rqtype = MEMTODEV;
fill_px(&desc->px,
addr, sg_dma_address(sg), sg_dma_len(sg));
} else {
desc->rqcfg.src_inc = 0;
desc->rqcfg.dst_inc = 1;
+ desc->req.rqtype = DEVTOMEM;
fill_px(&desc->px,
sg_dma_address(sg), addr, sg_dma_len(sg));
}
@@ -876,28 +860,7 @@ pl330_probe(struct amba_device *adev, const struct amba_id *id)
for (i = 0; i < num_chan; i++) {
pch = &pdmac->peripherals[i];
- if (pdat) {
- struct dma_pl330_peri *peri = &pdat->peri[i];
-
- switch (peri->rqtype) {
- case MEMTOMEM:
- dma_cap_set(DMA_MEMCPY, pd->cap_mask);
- break;
- case MEMTODEV:
- case DEVTOMEM:
- dma_cap_set(DMA_SLAVE, pd->cap_mask);
- dma_cap_set(DMA_CYCLIC, pd->cap_mask);
- break;
- default:
- dev_err(&adev->dev, "DEVTODEV Not Supported\n");
- continue;
- }
- pch->chan.private = peri;
- } else {
- dma_cap_set(DMA_MEMCPY, pd->cap_mask);
- pch->chan.private = NULL;
- }
-
+ pch->chan.private = pdat ? &pdat->peri_id[i] : NULL;
INIT_LIST_HEAD(&pch->work_list);
spin_lock_init(&pch->lock);
pch->pl330_chid = NULL;
@@ -911,6 +874,10 @@ pl330_probe(struct amba_device *adev, const struct amba_id *id)
}
pd->dev = &adev->dev;
+ if (pdat)
+ pd->cap_mask = pdat->cap_mask;
+ else
+ dma_cap_set(DMA_MEMCPY, pd->cap_mask);
pd->device_alloc_chan_resources = pl330_alloc_chan_resources;
pd->device_free_chan_resources = pl330_free_chan_resources;
diff --git a/include/linux/amba/pl330.h b/include/linux/amba/pl330.h
index 6db72da..12e023c 100644
--- a/include/linux/amba/pl330.h
+++ b/include/linux/amba/pl330.h
@@ -15,15 +15,6 @@
#include <linux/dmaengine.h>
#include <asm/hardware/pl330.h>
-struct dma_pl330_peri {
- /*
- * Peri_Req i/f of the DMAC that is
- * peripheral could be reached from.
- */
- u8 peri_id; /* specific dma id */
- enum pl330_reqtype rqtype;
-};
-
struct dma_pl330_platdata {
/*
* Number of valid peripherals connected to DMAC.
@@ -34,7 +25,9 @@ struct dma_pl330_platdata {
*/
u8 nr_valid_peri;
/* Array of valid peripherals */
- struct dma_pl330_peri *peri;
+ u8 *peri_id;
+ /* Operational capabilities */
+ dma_cap_mask_t cap_mask;
/* Bytes to allocate for MC buffer */
unsigned mcbuf_sz;
};
--
1.6.6.rc2
^ permalink raw reply related
* [PATCH v6 01/10] DMA: PL330: move filter function into driver
From: Thomas Abraham @ 2011-10-10 18:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1318270538-30450-1-git-send-email-thomas.abraham@linaro.org>
The dma channel selection filter function is moved from plat-samsung
into the pl330 driver. In additon to that, a check is added in the
filter function to ensure that the channel on which the filter has
been invoked is pl330 channel instance (and avoid any incorrect
access of chan->private in a system with multiple types of DMA
drivers).
Suggested-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Thomas Abraham <thomas.abraham@linaro.org>
Acked-by: Jassi Brar <jassisinghbrar@gmail.com>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
---
arch/arm/plat-samsung/dma-ops.c | 6 ------
drivers/dma/pl330.c | 15 +++++++++++++++
include/linux/amba/pl330.h | 2 ++
3 files changed, 17 insertions(+), 6 deletions(-)
diff --git a/arch/arm/plat-samsung/dma-ops.c b/arch/arm/plat-samsung/dma-ops.c
index 6e3d9ab..8d18425 100644
--- a/arch/arm/plat-samsung/dma-ops.c
+++ b/arch/arm/plat-samsung/dma-ops.c
@@ -17,12 +17,6 @@
#include <mach/dma.h>
-static inline bool pl330_filter(struct dma_chan *chan, void *param)
-{
- struct dma_pl330_peri *peri = chan->private;
- return peri->peri_id == (unsigned)param;
-}
-
static unsigned samsung_dmadev_request(enum dma_ch dma_ch,
struct samsung_dma_info *info)
{
diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
index 621134f..5f1d24c 100644
--- a/drivers/dma/pl330.c
+++ b/drivers/dma/pl330.c
@@ -116,6 +116,9 @@ struct dma_pl330_desc {
struct dma_pl330_chan *pchan;
};
+/* forward declaration */
+static struct amba_driver pl330_driver;
+
static inline struct dma_pl330_chan *
to_pchan(struct dma_chan *ch)
{
@@ -267,6 +270,18 @@ static void dma_pl330_rqcb(void *token, enum pl330_op_err err)
tasklet_schedule(&pch->task);
}
+bool pl330_filter(struct dma_chan *chan, void *param)
+{
+ struct dma_pl330_peri *peri;
+
+ if (chan->device->dev->driver != &pl330_driver.drv)
+ return false;
+
+ peri = chan->private;
+ return peri->peri_id == (unsigned)param;
+}
+EXPORT_SYMBOL(pl330_filter);
+
static int pl330_alloc_chan_resources(struct dma_chan *chan)
{
struct dma_pl330_chan *pch = to_pchan(chan);
diff --git a/include/linux/amba/pl330.h b/include/linux/amba/pl330.h
index d12f077..6db72da 100644
--- a/include/linux/amba/pl330.h
+++ b/include/linux/amba/pl330.h
@@ -12,6 +12,7 @@
#ifndef __AMBA_PL330_H_
#define __AMBA_PL330_H_
+#include <linux/dmaengine.h>
#include <asm/hardware/pl330.h>
struct dma_pl330_peri {
@@ -38,4 +39,5 @@ struct dma_pl330_platdata {
unsigned mcbuf_sz;
};
+extern bool pl330_filter(struct dma_chan *chan, void *param);
#endif /* __AMBA_PL330_H_ */
--
1.6.6.rc2
^ permalink raw reply related
* [PATCH v6 00/10] Add device tree support for PL330 dma controller driver
From: Thomas Abraham @ 2011-10-10 18:15 UTC (permalink / raw)
To: linux-arm-kernel
Changes since v5:
- Added alias clocks for pdma clocks on Exynos4.
- Modified platform data for s5p64x0, s5pc100 and s5pv210.
- Rebased on the tip of for-next branch of linux-samsung kernel and tested.
Changes since v4:
- Rebased with Samsung maintainer's for-next branch which is at linux-3.1-rc7
- Modified Patch 6/6 to apply cleanly.
Changes since v3:
- In Patch 4/6, a recommendation is added in the pl330 binding documentation
for the name of the property which specifies the dma channel in the client
device node.
- In Patch 6/6, dropped #ifdef around of_have_populated_dt.
Changes since v2:
- Only the sixth patch is changed, to make dma platform data conditionally
selectable.
- Tested with v8 version of pl330 dma driver update patches from Boojin Kim.
Changes since v1:
- Removed "arm,pl330-pdma" and "arm,pl330-mdma" compatible values.
- Removed "arm,primecell-periphid" and "arm,pl330-peri-reqs"
property requirements.
This patchset adds device tree support for PL330 driver and uses it to add
device tree support for Samsung platforms, specifically Exynos4.
Patch 1 moves the pl330_filter function from Samsung specific wrappers to pl330
dma driver and also adds a check to ensure that the filter function proceeds
only if it the dma channel being investigated belongs to pl330 dma controller
instance.
Patch 2 adds support to infer the direction of the dma transfer using the
direction specified with the transfer request instead of including this
information in the platform data. This simlifies the addition of device tree
support. Patch 3 simplifies the platform data for Exynos4 pl330 dma controllers.
Patch 4 adds device tree support for pl330 dma controller driver. A dma channel
is represented using a phandle of the dma controller node and the channel id
within that controller. Client driver request a dma channel using the phandle
and channel id pair. Correspondingly, the pl330 filter function has been
modified to lookup a channel based on this value.
Patch 5 adds device tree support for Samsung's DMA engine wrappers. Client
drivers retrive the channel property from their device node and pass it to the
wrappers. The wrapper functions use the property value as the filter function
parameter. Patch 6 restricts the usage of pl330 device and platform data
instances to non-dt platforms.
Patch 7 adds clock alias for both the pdma clocks. When pdma controllers are
instantiated from device tree, the amba device registration process enables
clock to the controllers to read the peripheral id of the PDMA amba device. In
case of Exynos4, the clocks to the PDMA controllers are named as 'dma' but
amba_device_register() looks up the clock using the name 'apb_pclk'. Hence,
alias clocks with name 'apb_pclk' clock are created for clocks with name 'dma'.
Patch 8 to 10 simplifies the pdma platform data for s5p64x0, s5pc100 and
s5pv210.
This patchset is based on the following tree:
https://github.com/kgene/linux-samsung.git branch: for-next
and tested tested for both device-tree and non-device-tree kernel on smdkv310.
This patchset has dependency on the following patchset.
[PATCH V2 0/2] Add a common macro for creating struct clk_lookup entries.
Thomas Abraham (10):
DMA: PL330: move filter function into driver
DMA: PL330: Infer transfer direction from transfer request instead of platform data
ARM: EXYNOS4: Modify platform data for pl330 driver
DMA: PL330: Add device tree support
ARM: SAMSUNG: Add device tree support for pl330 dma engine wrappers
ARM: EXYNOS4: Limit usage of pl330 device instance to non-dt build
ARM: Exynos4: Add a alias for pdma clocks
ARM: S5P64x0: Modify platform data for pl330 driver
ARM: S5PC100: Modify platform data for pl330 driver
ARM: S5PV210: Modify platform data for pl330 driver
.../devicetree/bindings/dma/arm-pl330.txt | 30 +++
arch/arm/mach-exynos4/Kconfig | 10 +
arch/arm/mach-exynos4/Makefile | 3 +-
arch/arm/mach-exynos4/clock.c | 35 ++-
arch/arm/mach-exynos4/dma.c | 227 ++++++-------------
arch/arm/mach-s5p64x0/dma.c | 227 +++++-------------
arch/arm/mach-s5pc100/dma.c | 247 ++++++--------------
arch/arm/mach-s5pv210/dma.c | 241 ++++++--------------
arch/arm/plat-samsung/dma-ops.c | 15 +-
arch/arm/plat-samsung/include/plat/dma-ops.h | 1 +
arch/arm/plat-samsung/include/plat/dma-pl330.h | 3 +-
drivers/dma/pl330.c | 99 +++++----
include/linux/amba/pl330.h | 15 +-
13 files changed, 405 insertions(+), 748 deletions(-)
create mode 100644 Documentation/devicetree/bindings/dma/arm-pl330.txt
^ permalink raw reply
* [PATCH v2 10/14] ARM: tegra: tegra_powergate_is_powered should be static
From: Olof Johansson @ 2011-10-10 18:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4E92CC72.3030809@ru.mvista.com>
Hi,
On Mon, Oct 10, 2011 at 3:44 AM, Sergei Shtylyov
<sshtylyov@ru.mvista.com> wrote:
> Hello.
>
> On 10-10-2011 9:28, Olof Johansson wrote:
>
>> Not exported and not used externally.
>
>> Also, fix return type ?and change to instead WARN_ON on bad parameters.
>
> ? Change to what? You're changing _to_ WARN_ON() as we can see, not from
> it...
I guess I wasn't entirely clear in the commit message, thanks for
pointing it out.
I revised the text just now when I applied the series -- not really
warranting a repost of the patch though.
Thanks,
-Olof
^ permalink raw reply
* Please update linux-next url for tegra
From: Olof Johansson @ 2011-10-10 18:09 UTC (permalink / raw)
To: linux-arm-kernel
Hi Stephen,
I'm taking over running the main tegra repo for a while, so please
change the old android.git.kernel.org-hosted branch to instead pull:
git://git.kernel.org/pub/scm/linux/kernel/git/olof/tegra.git for-next
And please pull it after the arm-soc tree.
I don't expect to have much long-lived contents in here -- they should
find their way into arm-soc quickly. But I also want to get patches
into linux-next as soon as possible without sending arm-soc pull
requests every few days.
-Olof
^ permalink raw reply
* [PATCH 00/24 V2] OMAP4: PM: suspend, CPU-hotplug and CPUilde support
From: Kevin Hilman @ 2011-10-10 18:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1316844884-21700-1-git-send-email-santosh.shilimkar@ti.com>
Hi Santosh,
Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
> The series adds OMAP4 MPUSS (MPU SubSystem) power management support for
> suspend (S2R), CPU hotplug and CPUidle.
There are a few more compile errors when doing OMAP1-only builds.
You'll need a way to eliminate the secure calls for OMAP1.
This series causes a couple build errors when doing OMAP1-only builds
(I used omap1_defconfig):
First:
/work/kernel/omap/pm/arch/arm/plat-omap/common.c:24:30: fatal error: mach/omap-secure.h: No such file or directory
And trying creating a dummy header to see if it would continue to build gives:
/work/kernel/omap/pm/arch/arm/plat-omap/common.c: In function 'omap_reserve':
/work/kernel/omap/pm/arch/arm/plat-omap/common.c:70:2: error: implicit declaration of function 'omap_secure_ram_reserve_memblock'
make[2]: *** [arch/arm/plat-omap/common.o] Error 1
make[1]: *** [arch/arm/plat-omap] Error 2
Kevin
^ permalink raw reply
* [PATCH] fix ehci alignment error
From: Greg KH @ 2011-10-10 17:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20115.11246.991917.639835@pilspetsen.it.uu.se>
On Mon, Oct 10, 2011 at 07:31:26PM +0200, Mikael Pettersson wrote:
> Greg KH writes:
> > On Mon, Oct 10, 2011 at 05:29:13PM +0100, M?ns Rullg?rd wrote:
> > > Greg KH <gregkh@suse.de> writes:
> > >
> > > > On Mon, Oct 10, 2011 at 02:38:27PM +0200, Harro Haan wrote:
> > > >> The Kirkwood gave an unaligned memory access error on
> > > >> line 742 of drivers/usb/host/echi-hcd.c:
> > > >> "ehci->last_periodic_enable = ktime_get_real();"
> > > >
> > > > What is "The Kirkwood"? What size processor is this?
> > >
> > > It's an ARM926-like CPU from Marvell.
> >
> > 32 or 64bit?
>
> All ARMs are 32-bit, but some have instructions for loading or
> storing 2 x 32 bits at a time, but also require the corresponding
> memory address to be 64-bit aligned.
Ah, ok, that makes more sense here. I'll go queue it up.
greg k-h
^ permalink raw reply
* [PATCH 2/5] drivercore: Add driver probe deferral mechanism
From: Andrei Warkentin @ 2011-10-10 17:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111008155502.GB616@kroah.com>
Hi,
----- Original Message -----
> From: "Greg KH" <greg@kroah.com>
> To: "Josh Triplett" <josh@joshtriplett.org>
> Cc: "G, Manjunath Kondaiah" <manjugk@ti.com>, linux-arm-kernel at lists.infradead.org, "Grant Likely"
> <grant.likely@secretlab.ca>, linux-omap at vger.kernel.org, linux-mmc at vger.kernel.org, linux-kernel at vger.kernel.org,
> "Dilan Lee" <dilee@nvidia.com>, "Mark Brown" <broonie@opensource.wolfsonmicro.com>, Manjunath at jasper.es
> Sent: Saturday, October 8, 2011 11:55:02 AM
> Subject: Re: [PATCH 2/5] drivercore: Add driver probe deferral mechanism
>
I'm a bit of a fly on the wall here, but I'm curious how this impacts suspend/resume.
device_initialize->device_pm_init are called from device_register, so certainly this
patch doesn't also ensure that the PM ordering matches probe ordering, which is bound
to break suspend, right? Was this ever tested with the OMAP target? Shouldn't the
PM change be also part of this patch set? I don't see why you would want to have this in
without the PM changes.
Maybe I have it all wrong though :-).
A
^ permalink raw reply
* [PATCH v2 5/5] regulator: map consumer regulator based on device tree
From: Mark Brown @ 2011-10-10 17:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1318263578-7407-6-git-send-email-rnayak@ti.com>
On Mon, Oct 10, 2011 at 09:49:38PM +0530, Rajendra Nayak wrote:
> Device nodes in DT can associate themselves with one or more
> regulators/supply by providing a list of phandles (to regulator nodes)
> and corresponding supply names.
Mostly looks good.
> +/**
> + * of_get_regulator - get a regulator device node based on supply name
> + * @dev: Device pointer for the consumer (of regulator) device
> + * @supply: regulator supply name
> + *
> + * Extract the regulator device node corresponding to the supply name.
> + * retruns the device node corresponding to the regulator if found, else
> + * returns NULL.
> + */
> +struct device_node *of_get_regulator(struct device *dev, const char *supply)
> +{
Should be static.
> @@ -1178,6 +1225,10 @@ static struct regulator *_regulator_get(struct device *dev, const char *id,
> goto found;
> }
> }
> + if (!dev)
> + list_for_each_entry(rdev, ®ulator_list, list)
> + if (strcmp(rdev_get_name(rdev), id))
> + goto found;
>
This looks really strange, we didn't remove any old lookup code and the
DT lookup jumps to found by iself so why are we adding code here?
> + if (supply) {
> + struct regulator_dev *r;
> + struct device_node *node;
> +
> + /* first do a dt based lookup */
> + if (dev) {
> + node = of_get_regulator(dev, supply);
> + if (node)
> + list_for_each_entry(r, ®ulator_list, list)
> + if (node == r->dev.parent->of_node)
> + goto found;
> }
>
> - if (!found) {
> - dev_err(dev, "Failed to find supply %s\n",
> - init_data->supply_regulator);
> - ret = -ENODEV;
> - goto scrub;
> - }
> + /* next try doing it non-dt way */
> + list_for_each_entry(r, ®ulator_list, list)
> + if (strcmp(rdev_get_name(r), supply) == 0)
> + goto found;
>
> + dev_err(dev, "Failed to find supply %s\n", supply);
> + ret = -ENODEV;
> + goto scrub;
> +
> +found:
This is all getting *really* complicated and illegible. I'm not sure
what the best way to structure is but erroring out early looks useful.
^ permalink raw reply
* [PATCH] fix ehci alignment error
From: Mikael Pettersson @ 2011-10-10 17:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111010170042.GB24166@suse.de>
Greg KH writes:
> On Mon, Oct 10, 2011 at 05:29:13PM +0100, M?ns Rullg?rd wrote:
> > Greg KH <gregkh@suse.de> writes:
> >
> > > On Mon, Oct 10, 2011 at 02:38:27PM +0200, Harro Haan wrote:
> > >> The Kirkwood gave an unaligned memory access error on
> > >> line 742 of drivers/usb/host/echi-hcd.c:
> > >> "ehci->last_periodic_enable = ktime_get_real();"
> > >
> > > What is "The Kirkwood"? What size processor is this?
> >
> > It's an ARM926-like CPU from Marvell.
>
> 32 or 64bit?
All ARMs are 32-bit, but some have instructions for loading or
storing 2 x 32 bits at a time, but also require the corresponding
memory address to be 64-bit aligned.
^ permalink raw reply
* [PATCH] ARM: OMAP: omap_device: Add omap_device_{alloc, delete, register}_ss
From: Kevin Hilman @ 2011-10-10 17:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAK=WgbbqG4qFAafJ49jdYwf19whxBGhtywTWVTnsejZ0F_ekog@mail.gmail.com>
Ohad Ben-Cohen <ohad@wizery.com> writes:
> Hi Kevin,
>
> On Wed, Oct 5, 2011 at 6:54 PM, Ohad Ben-Cohen <ohad@wizery.com> wrote:
>> Split omap_device_build_ss() into two smaller functions:
> ...
>> This patch is considered an interim solution until DT fully materializes
>> for omap; at that point, this functionality will be removed.
>
> Good news: we might not need this after all.
Great.
> I need the remoteproc devices to exists at ->reserve() time, so I can
> assign them a private CMA pool, which means I can't wait for
> omap_device_build_ss() and must create the devices beforehand.
>
> ... which makes Benoit's alloc/delete methods perfect for me.
>
> So please hold this one off for now. I'd just need a s/static// patch
> that will allow me to use Benoit's methods outside of omap_device.c,
> but I'll wait for things to settle down a bit before sending it, to
> minimize this kind of churn.
OK. Sounds good.
Thanks,
Kevin
> Thanks and sorry for the noise,
> Ohad.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH v2 3/5] regulator: helper routine to extract regulator_init_data
From: Mark Brown @ 2011-10-10 17:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1318263578-7407-4-git-send-email-rnayak@ti.com>
On Mon, Oct 10, 2011 at 09:49:36PM +0530, Rajendra Nayak wrote:
> +- regulator-change-voltage: boolean, Output voltage can be changed by software
> +- regulator-change-current: boolean, Output current can be chnaged by software
> +- regulator-change-mode: boolean, Operating mode can be changed by software
> +- regulator-change-status: boolean, Enable/Disable control for regulator exists
> +- regulator-change-drms: boolean, Dynamic regulator mode switching is enabled
> +- regulator-mode-fast: boolean, allow/set fast mode for the regulator
> +- regulator-mode-normal: boolean, allow/set normal mode for the regulator
> +- regulator-mode-idle: boolean, allow/set idle mode for the regulator
> +- regulator-mode-standby: boolean, allow/set standby mode for the regulator
> +- regulator-input-uV: Input voltage for regulator when supplied by another regulator
> +- regulator-always-on: boolean, regulator should never be disabled
Thinking about this I'm not sure that these should go in the device
tree, they're as much talking about what Linux is able to cope with as
they are talking about what the hardware is able to do. Sometimes
they'll be fixed by the design but they are sometimes also restricted by
what the software is currently capable of. DRMS is a prime example
here, it depends on how good we are at telling the API about how much
current we're using.
^ permalink raw reply
* [PATCH v3 1/6] iommu/core: split mapping to page sizes as supported by the hardware
From: Ohad Ben-Cohen @ 2011-10-10 17:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111010153609.GB2138@amd.com>
Hi Joerg,
On Mon, Oct 10, 2011 at 5:36 PM, Roedel, Joerg <Joerg.Roedel@amd.com> wrote:
> The master branch is best to base your patches on for generic work.
Oh, great. thanks.
> It can happen when there is a bug somewhere :)
Hmm, bug ? ;)
Ok, I'll add a BUG_ON :)
> Yes, somthing like that. Probably the iommu_ops->unmap function should
> be turned into a unmap_page function call which only takes an iova and
> no size parameter. The iommu-driver unmaps the page pointing to that
> iova and returns the size of the page unmapped. This still allows the
> simple implementation for the unmap-call.
Yes, exactly. It will take some time to migrate all drivers (today we
have 4 drivers, each of which is implementing a slightly different
->unmap() semantics), but at least let's not accept any new driver
that doesn't adhere to this, otherwise it's going to be even harder
for the API to evolve.
> This change is no requirement for this patch-set, but if we agree on it
> this patch-set should keep that direction in mind.
Definitely, thanks.
> We don't need to really
> enforce the calls to be symetric. But we can define that we only give
> the guarantee about what will be unmapped when the calls are symetric.
Sounds good to me. I'll add this to the kernel doc patch (which I'll
submit after this patch set materializes), and when/if we move to
symmetric only, we will update it.
> The alternative is that we implement page-splitting in the iommu_unmap
> function. But that introduces complexity I am not sure we really need.
Yeah, me neither.
> Yes, this get_order thing should be changes to size long-term.
Good. That should be a simple change, I'll do it after this patch set.
Thanks,
Ohad.
^ permalink raw reply
* [PATCH] fix ehci alignment error
From: Greg KH @ 2011-10-10 17:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <yw1xipnwzu7a.fsf@unicorn.mansr.com>
On Mon, Oct 10, 2011 at 05:29:13PM +0100, M?ns Rullg?rd wrote:
> Greg KH <gregkh@suse.de> writes:
>
> > On Mon, Oct 10, 2011 at 02:38:27PM +0200, Harro Haan wrote:
> >> The Kirkwood gave an unaligned memory access error on
> >> line 742 of drivers/usb/host/echi-hcd.c:
> >> "ehci->last_periodic_enable = ktime_get_real();"
> >
> > What is "The Kirkwood"? What size processor is this?
>
> It's an ARM926-like CPU from Marvell.
32 or 64bit?
^ permalink raw reply
* [PATCH v2 00/14] Sparse fixes for tegra
From: Arnd Bergmann @ 2011-10-10 17:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1318224484-2090-1-git-send-email-olof@lixom.net>
On Monday 10 October 2011, Olof Johansson wrote:
> Some trivial fixes removing sparse warnings on tegra code.
>
> Changes since v1:
>
> * Implemented Arnd's suggestion to push annotation all the way down to IO_*_VIRT defines
> * Based on above, no longer needed IO_TO_VIRT() -> IO_ADDRESS() changes
> * Added two more fixes for cpu-tegra.
>
> Stephen; I didn't explicitly apply your Acked-by lines to this batch yet,
> I will do so when I collect final acks before pushing a branch.
>
Acked-by: Arnd Bergmann <arnd@arndb.de>
^ permalink raw reply
* [PATCH] PM: HIBERNATION: add resume_delay kernel param as well as resume_delay
From: Pavel Machek @ 2011-10-10 16:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1318225452-10397-1-git-send-email-Barry.Song@csr.com>
On Sun 2011-10-09 22:44:12, Barry Song wrote:
> From: Barry Song <baohua.song@csr.com>
>
> patch "PM: HIBERNATION: add resume_wait param to support MMC-like devices
> as resume file" add resume_wait param. this patch adds resume_delay so that
> resume_wait/delay has the same model with root_wait/delay.
>
> Signed-off-by: Barry Song <baohua.song@csr.com>
ACK.
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply
* [PATCH v2 00/14] Sparse fixes for tegra
From: Stephen Warren @ 2011-10-10 16:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1318224484-2090-1-git-send-email-olof@lixom.net>
Olof Johansson wrote at Sunday, October 09, 2011 11:28 PM:
> Some trivial fixes removing sparse warnings on tegra code.
>
> Changes since v1:
>
> * Implemented Arnd's suggestion to push annotation all the way down to IO_*_VIRT defines
> * Based on above, no longer needed IO_TO_VIRT() -> IO_ADDRESS() changes
> * Added two more fixes for cpu-tegra.
>
> Stephen; I didn't explicitly apply your Acked-by lines to this batch yet,
> I will do so when I collect final acks before pushing a branch.
Just for the record; my ack still applies to the updated series.
--
nvpublic
^ permalink raw reply
* [PATCH V2 4/4] ARM: at91/dma: DMA controller registering with DT support
From: Nicolas Ferre @ 2011-10-10 16:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <e292fbb24a98b7cfda8ea83364956a50e1cb120f.1318264339.git.nicolas.ferre@atmel.com>
Device tree support on at91sam9g45 family SoC. Only call
platform_device_register() if no compatible dma-controller
node is found in device tree.
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
---
V2: use compatible string to match device.
arch/arm/mach-at91/at91sam9g45_devices.c | 8 +++++++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-at91/at91sam9g45_devices.c b/arch/arm/mach-at91/at91sam9g45_devices.c
index 9390ae6..2120055 100644
--- a/arch/arm/mach-at91/at91sam9g45_devices.c
+++ b/arch/arm/mach-at91/at91sam9g45_devices.c
@@ -64,7 +64,13 @@ static struct platform_device at_hdmac_device = {
void __init at91_add_device_hdmac(void)
{
- platform_device_register(&at_hdmac_device);
+ struct device_node *np = of_find_node_by_name(NULL, "dma-controller");
+
+ if (np && of_device_is_compatible(np, "atmel,at91sam9g45-dma")) {
+ of_node_put(np);
+ } else {
+ platform_device_register(&at_hdmac_device);
+ }
}
#else
void __init at91_add_device_hdmac(void) {}
--
1.7.5.4
^ permalink raw reply related
* [PATCH v7 3/3] arm/tegra: device tree support for ventana board
From: Stephen Warren @ 2011-10-10 16:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111010080109.GQ9003@tbergstrom-lnx.Nvidia.com>
Peter De Schrijver wrote at Monday, October 10, 2011 2:01 AM:
> On Fri, Oct 07, 2011 at 08:04:34PM +0200, Stephen Warren wrote:
> > Peter De Schrijver wrote at Monday, October 03, 2011 7:19 AM:
> > ...
> > > diff --git a/arch/arm/mach-tegra/board-dt.c b/arch/arm/mach-tegra/board-dt.c
> > ...
> > > - if (of_machine_is_compatible("nvidia,harmony"))
> > > - harmony_pinmux_init();
> > > - else if (of_machine_is_compatible("nvidia,seaboard"))
> > > - seaboard_pinmux_init();
> > > + for (i = 0; i < ARRAY_SIZE(pinmux_configs); i++) {
> > > + if (of_machine_is_compatible(pinmux_configs[i].machine)) {
> > > + pinmux_configs[i].init();
> > > + break;
> > > + }
> > > + }
> > > +
> > > + if (i == ARRAY_SIZE(pinmux_configs))
> > > + printk(KERN_WARNING "Unknown platform! Pinmuxing not initialized\n");
> >
> > Should that be WARN() instead of printk?
>
> pr_warning() might be better. Or do we want a backtrace and a tainted kernel
> in this case?
Well, tainting seems like a good idea. I'm less thrilled about the backtrace,
but perhaps it is a good idea to bring attention to this condition.
--
nvpublic
^ permalink raw reply
* [PATCH 4/4] ARM: at91/dma: DMA controller registering with DT support
From: Nicolas Ferre @ 2011-10-10 16:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <9723283e7097730f568bf7c2f3a93ae42c6bc5ca.1318264339.git.nicolas.ferre@atmel.com>
Device tree support on at91sam9g45 family SoC. Only call
platform_device_register() if no dma-controller node is
found in device tree.
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
---
arch/arm/mach-at91/at91sam9g45_devices.c | 9 ++++++++-
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-at91/at91sam9g45_devices.c b/arch/arm/mach-at91/at91sam9g45_devices.c
index c9b897f..cee7287 100644
--- a/arch/arm/mach-at91/at91sam9g45_devices.c
+++ b/arch/arm/mach-at91/at91sam9g45_devices.c
@@ -64,7 +64,14 @@ static struct platform_device at_hdmac_device = {
void __init at91_add_device_hdmac(void)
{
- platform_device_register(&at_hdmac_device);
+ struct device_node *of_node =
+ of_find_node_by_name(NULL, "dma-controller");
+
+ if (of_node) {
+ of_node_put(of_node);
+ } else {
+ platform_device_register(&at_hdmac_device);
+ }
}
#else
void __init at91_add_device_hdmac(void) {}
--
1.7.5.4
^ permalink raw reply related
* [PATCH 3/4] ARM: at91/dma: remove platform data from DMA controller
From: Nicolas Ferre @ 2011-10-10 16:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <9723283e7097730f568bf7c2f3a93ae42c6bc5ca.1318264339.git.nicolas.ferre@atmel.com>
DMA controller can deduce its configuration data from
the platform. Remove the platform data and match device
types with the compatible ones.
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
---
arch/arm/mach-at91/at91sam9g45_devices.c | 9 +--------
arch/arm/mach-at91/at91sam9rl_devices.c | 8 +-------
2 files changed, 2 insertions(+), 15 deletions(-)
diff --git a/arch/arm/mach-at91/at91sam9g45_devices.c b/arch/arm/mach-at91/at91sam9g45_devices.c
index 600bffb..c9b897f 100644
--- a/arch/arm/mach-at91/at91sam9g45_devices.c
+++ b/arch/arm/mach-at91/at91sam9g45_devices.c
@@ -38,10 +38,6 @@
#if defined(CONFIG_AT_HDMAC) || defined(CONFIG_AT_HDMAC_MODULE)
static u64 hdmac_dmamask = DMA_BIT_MASK(32);
-static struct at_dma_platform_data atdma_pdata = {
- .nr_channels = 8,
-};
-
static struct resource hdmac_resources[] = {
[0] = {
.start = AT91_BASE_SYS + AT91_DMA,
@@ -56,12 +52,11 @@ static struct resource hdmac_resources[] = {
};
static struct platform_device at_hdmac_device = {
- .name = "at_hdmac",
+ .name = "at91sam9g45_dma",
.id = -1,
.dev = {
.dma_mask = &hdmac_dmamask,
.coherent_dma_mask = DMA_BIT_MASK(32),
- .platform_data = &atdma_pdata,
},
.resource = hdmac_resources,
.num_resources = ARRAY_SIZE(hdmac_resources),
@@ -69,8 +64,6 @@ static struct platform_device at_hdmac_device = {
void __init at91_add_device_hdmac(void)
{
- dma_cap_set(DMA_MEMCPY, atdma_pdata.cap_mask);
- dma_cap_set(DMA_SLAVE, atdma_pdata.cap_mask);
platform_device_register(&at_hdmac_device);
}
#else
diff --git a/arch/arm/mach-at91/at91sam9rl_devices.c b/arch/arm/mach-at91/at91sam9rl_devices.c
index aacb19d..81954f7 100644
--- a/arch/arm/mach-at91/at91sam9rl_devices.c
+++ b/arch/arm/mach-at91/at91sam9rl_devices.c
@@ -33,10 +33,6 @@
#if defined(CONFIG_AT_HDMAC) || defined(CONFIG_AT_HDMAC_MODULE)
static u64 hdmac_dmamask = DMA_BIT_MASK(32);
-static struct at_dma_platform_data atdma_pdata = {
- .nr_channels = 2,
-};
-
static struct resource hdmac_resources[] = {
[0] = {
.start = AT91_BASE_SYS + AT91_DMA,
@@ -51,12 +47,11 @@ static struct resource hdmac_resources[] = {
};
static struct platform_device at_hdmac_device = {
- .name = "at_hdmac",
+ .name = "at91sam9rl_dma",
.id = -1,
.dev = {
.dma_mask = &hdmac_dmamask,
.coherent_dma_mask = DMA_BIT_MASK(32),
- .platform_data = &atdma_pdata,
},
.resource = hdmac_resources,
.num_resources = ARRAY_SIZE(hdmac_resources),
@@ -64,7 +59,6 @@ static struct platform_device at_hdmac_device = {
void __init at91_add_device_hdmac(void)
{
- dma_cap_set(DMA_MEMCPY, atdma_pdata.cap_mask);
platform_device_register(&at_hdmac_device);
}
#else
--
1.7.5.4
^ permalink raw reply related
* [PATCH 2/4] dmaengine: at_hdmac: add device tree support
From: Nicolas Ferre @ 2011-10-10 16:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <9723283e7097730f568bf7c2f3a93ae42c6bc5ca.1318264339.git.nicolas.ferre@atmel.com>
Add device tree probe support for atmel at_hdmac DMA driver.
Bindings are added to specify DMA controller configuration.
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
---
.../devicetree/bindings/dma/atmel-dma.txt | 14 +++++++++
drivers/dma/at_hdmac.c | 30 +++++++++++++++++++-
2 files changed, 43 insertions(+), 1 deletions(-)
create mode 100644 Documentation/devicetree/bindings/dma/atmel-dma.txt
diff --git a/Documentation/devicetree/bindings/dma/atmel-dma.txt b/Documentation/devicetree/bindings/dma/atmel-dma.txt
new file mode 100644
index 0000000..3c046ee
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/atmel-dma.txt
@@ -0,0 +1,14 @@
+* Atmel Direct Memory Access Controller (DMA)
+
+Required properties:
+- compatible: Should be "atmel,<chip>-dma"
+- reg: Should contain DMA registers location and length
+- interrupts: Should contain DMA interrupt
+
+Examples:
+
+dma at ffffec00 {
+ compatible = "atmel,at91sam9g45-dma";
+ reg = <0xffffec00 0x200>;
+ interrupts = <21>;
+};
diff --git a/drivers/dma/at_hdmac.c b/drivers/dma/at_hdmac.c
index fef57bc..6d25b6a 100644
--- a/drivers/dma/at_hdmac.c
+++ b/drivers/dma/at_hdmac.c
@@ -23,6 +23,8 @@
#include <linux/module.h>
#include <linux/platform_device.h>
#include <linux/slab.h>
+#include <linux/of.h>
+#include <linux/of_device.h>
#include "at_hdmac_regs.h"
@@ -1175,6 +1177,20 @@ static void atc_free_chan_resources(struct dma_chan *chan)
/*-- Module Management -----------------------------------------------*/
+#if defined(CONFIG_OF)
+static const struct of_device_id atmel_dma_dt_ids[] = {
+ {
+ .compatible = "atmel,at91sam9rl-dma",
+ .data = (void *)ATDMA_DEVTYPE_SAM9RL
+ }, {
+ .compatible = "atmel,at91sam9g45-dma",
+ .data = (void *)ATDMA_DEVTYPE_SAM9G45
+ }, { /* sentinel */ }
+};
+
+MODULE_DEVICE_TABLE(of, atmel_dma_dt_ids);
+#endif
+
static struct platform_device_id atdma_devtypes[] = {
{
.name = "at91sam9rl_dma",
@@ -1187,6 +1203,17 @@ static struct platform_device_id atdma_devtypes[] = {
}
};
+static inline enum atdma_devtype __init at_dma_get_driver_data(
+ struct platform_device *pdev)
+{
+ if (pdev->dev.of_node) {
+ const struct of_device_id *match;
+ match = of_match_node(atmel_dma_dt_ids, pdev->dev.of_node);
+ return (enum atdma_devtype)match->data;
+ }
+ return platform_get_device_id(pdev)->driver_data;
+}
+
/**
* at_dma_off - disable DMA controller
* @atdma: the Atmel HDAMC device
@@ -1218,7 +1245,7 @@ static int __init at_dma_probe(struct platform_device *pdev)
dma_cap_set(DMA_MEMCPY, cap_mask);
/* get DMA parameters from controller type */
- atdmatype = platform_get_device_id(pdev)->driver_data;
+ atdmatype = at_dma_get_driver_data(pdev);
switch (atdmatype) {
case ATDMA_DEVTYPE_SAM9RL:
@@ -1526,6 +1553,7 @@ static struct platform_driver at_dma_driver = {
.driver = {
.name = "at_hdmac",
.pm = &at_dma_dev_pm_ops,
+ .of_match_table = of_match_ptr(atmel_dma_dt_ids),
},
};
--
1.7.5.4
^ permalink raw reply related
* [PATCH 1/4] dmaengine: at_hdmac: platform data move to use .id_table
From: Nicolas Ferre @ 2011-10-10 16:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1314075338.22120.3.camel@vkoul-udesk3>
We remove platform data from DMA controller and move
to the use of .id_table to distinguish between compatible
types. The two implementations allow to determine the
number of channels and the capabilities of the controller.
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
---
drivers/dma/at_hdmac.c | 48 ++++++++++++++++++++++++++++++++++---------
drivers/dma/at_hdmac_regs.h | 8 +++++++
2 files changed, 46 insertions(+), 10 deletions(-)
diff --git a/drivers/dma/at_hdmac.c b/drivers/dma/at_hdmac.c
index fcfa0a8..fef57bc 100644
--- a/drivers/dma/at_hdmac.c
+++ b/drivers/dma/at_hdmac.c
@@ -1175,6 +1175,18 @@ static void atc_free_chan_resources(struct dma_chan *chan)
/*-- Module Management -----------------------------------------------*/
+static struct platform_device_id atdma_devtypes[] = {
+ {
+ .name = "at91sam9rl_dma",
+ .driver_data = ATDMA_DEVTYPE_SAM9RL,
+ }, {
+ .name = "at91sam9g45_dma",
+ .driver_data = ATDMA_DEVTYPE_SAM9G45,
+ }, {
+ /* sentinel */
+ }
+};
+
/**
* at_dma_off - disable DMA controller
* @atdma: the Atmel HDAMC device
@@ -1193,18 +1205,32 @@ static void at_dma_off(struct at_dma *atdma)
static int __init at_dma_probe(struct platform_device *pdev)
{
- struct at_dma_platform_data *pdata;
struct resource *io;
struct at_dma *atdma;
size_t size;
int irq;
int err;
int i;
+ u32 nr_channels;
+ dma_cap_mask_t cap_mask = {};
+ enum atdma_devtype atdmatype;
+
+ dma_cap_set(DMA_MEMCPY, cap_mask);
+
+ /* get DMA parameters from controller type */
+ atdmatype = platform_get_device_id(pdev)->driver_data;
- /* get DMA Controller parameters from platform */
- pdata = pdev->dev.platform_data;
- if (!pdata || pdata->nr_channels > AT_DMA_MAX_NR_CHANNELS)
+ switch (atdmatype) {
+ case ATDMA_DEVTYPE_SAM9RL:
+ nr_channels = 2;
+ break;
+ case ATDMA_DEVTYPE_SAM9G45:
+ nr_channels = 8;
+ dma_cap_set(DMA_SLAVE, cap_mask);
+ break;
+ default:
return -EINVAL;
+ }
io = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (!io)
@@ -1215,14 +1241,15 @@ static int __init at_dma_probe(struct platform_device *pdev)
return irq;
size = sizeof(struct at_dma);
- size += pdata->nr_channels * sizeof(struct at_dma_chan);
+ size += nr_channels * sizeof(struct at_dma_chan);
atdma = kzalloc(size, GFP_KERNEL);
if (!atdma)
return -ENOMEM;
- /* discover transaction capabilites from the platform data */
- atdma->dma_common.cap_mask = pdata->cap_mask;
- atdma->all_chan_mask = (1 << pdata->nr_channels) - 1;
+ /* discover transaction capabilites */
+ atdma->dma_common.cap_mask = cap_mask;
+ atdma->all_chan_mask = (1 << nr_channels) - 1;
+ atdma->devtype = atdmatype;
size = resource_size(io);
if (!request_mem_region(io->start, size, pdev->dev.driver->name)) {
@@ -1268,7 +1295,7 @@ static int __init at_dma_probe(struct platform_device *pdev)
/* initialize channels related values */
INIT_LIST_HEAD(&atdma->dma_common.channels);
- for (i = 0; i < pdata->nr_channels; i++) {
+ for (i = 0; i < nr_channels; i++) {
struct at_dma_chan *atchan = &atdma->chan[i];
atchan->chan_common.device = &atdma->dma_common;
@@ -1313,7 +1340,7 @@ static int __init at_dma_probe(struct platform_device *pdev)
dev_info(&pdev->dev, "Atmel AHB DMA Controller ( %s%s), %d channels\n",
dma_has_cap(DMA_MEMCPY, atdma->dma_common.cap_mask) ? "cpy " : "",
dma_has_cap(DMA_SLAVE, atdma->dma_common.cap_mask) ? "slave " : "",
- pdata->nr_channels);
+ nr_channels);
dma_async_device_register(&atdma->dma_common);
@@ -1495,6 +1522,7 @@ static const struct dev_pm_ops at_dma_dev_pm_ops = {
static struct platform_driver at_dma_driver = {
.remove = __exit_p(at_dma_remove),
.shutdown = at_dma_shutdown,
+ .id_table = atdma_devtypes,
.driver = {
.name = "at_hdmac",
.pm = &at_dma_dev_pm_ops,
diff --git a/drivers/dma/at_hdmac_regs.h b/drivers/dma/at_hdmac_regs.h
index aa4c9ae..d7d6737 100644
--- a/drivers/dma/at_hdmac_regs.h
+++ b/drivers/dma/at_hdmac_regs.h
@@ -248,9 +248,16 @@ static inline struct at_dma_chan *to_at_dma_chan(struct dma_chan *dchan)
/*-- Controller ------------------------------------------------------*/
+enum atdma_devtype {
+ ATDMA_DEVTYPE_UNDEFINED = 0,
+ ATDMA_DEVTYPE_SAM9RL, /* compatible with SAM9RL DMA controller */
+ ATDMA_DEVTYPE_SAM9G45, /* compatible with SAM9G45 DMA controller */
+};
+
/**
* struct at_dma - internal representation of an Atmel HDMA Controller
* @chan_common: common dmaengine dma_device object members
+ * @atdma_devtype: identifier of DMA controller compatibility
* @ch_regs: memory mapped register base
* @clk: dma controller clock
* @save_imr: interrupt mask register that is saved on suspend/resume cycle
@@ -260,6 +267,7 @@ static inline struct at_dma_chan *to_at_dma_chan(struct dma_chan *dchan)
*/
struct at_dma {
struct dma_device dma_common;
+ enum atdma_devtype devtype;
void __iomem *regs;
struct clk *clk;
u32 save_imr;
--
1.7.5.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox