[PATCH 6/6] ARM: EXYNOS4: Limit usage of pl330 device instance to non-dt build
The pl330 device instances and associated platform data is required only
for non-device-tree builds. With device tree enabled, the data about the
platform is obtained from the device tree. For images that include both
dt and non-dt platforms, an addditional check is added to ensure that
static amba device registrations is applicable to only non-dt platforms.
Cc: Kukjin Kim
Cc: Kyungmin Park
Signed-off-by: Thomas Abraham
Acked-by: Grant Likely
---
arch/arm/mach-exynos4/Kconfig | 10 ++
arch/arm/mach-exynos4/Makefile |3 ++-
arch/arm/mach-exynos4/dma.c|4
3 files changed, 16 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-exynos4/Kconfig b/arch/arm/mach-exynos4/Kconfig
index d4d401c..679ba48 100644
--- a/arch/arm/mach-exynos4/Kconfig
+++ b/arch/arm/mach-exynos4/Kconfig
@@ -21,6 +21,11 @@ config EXYNOS4_MCT
help
Use MCT (Multi Core Timer) as kernel timers
+config EXYNOS4_DEV_DMA
+ bool
+ help
+ Compile in amba device definitions for DMA controller
+
config EXYNOS4_DEV_AHCI
bool
help
@@ -129,6 +134,7 @@ config MACH_SMDKC210
select EXYNOS4_SETUP_FIMD0
select EXYNOS4_SETUP_I2C1
select EXYNOS4_SETUP_SDHCI
+ select EXYNOS4_DEV_DMA
help
Machine support for Samsung SMDKC210
@@ -153,6 +159,7 @@ config MACH_SMDKV310
select EXYNOS4_SETUP_I2C1
select EXYNOS4_SETUP_KEYPAD
select EXYNOS4_SETUP_SDHCI
+ select EXYNOS4_DEV_DMA
help
Machine support for Samsung SMDKV310
@@ -191,6 +198,7 @@ config MACH_UNIVERSAL_C210
select EXYNOS4_SETUP_I2C3
select EXYNOS4_SETUP_I2C5
select EXYNOS4_SETUP_SDHCI
+ select EXYNOS4_DEV_DMA
help
Machine support for Samsung Mobile Universal S5PC210 Reference
Board.
@@ -215,6 +223,7 @@ config MACH_NURI
select EXYNOS4_SETUP_USB_PHY
select SAMSUNG_DEV_PWM
select SAMSUNG_DEV_ADC
+ select EXYNOS4_DEV_DMA
help
Machine support for Samsung Mobile NURI Board.
@@ -222,6 +231,7 @@ config MACH_EXYNOS4_DT
bool "Samsung Exynos4 Machine using device tree"
select CPU_EXYNOS4210
select USE_OF
+ select ARM_AMBA
help
Machine support for Samsung Exynos4 machine with device tree enabled.
diff --git a/arch/arm/mach-exynos4/Makefile b/arch/arm/mach-exynos4/Makefile
index d2bf5bf..a2f33dc 100644
--- a/arch/arm/mach-exynos4/Makefile
+++ b/arch/arm/mach-exynos4/Makefile
@@ -13,7 +13,8 @@ obj- :=
# Core support for EXYNOS4 system
obj-$(CONFIG_CPU_EXYNOS4210) += cpu.o init.o clock.o irq-combiner.o
-obj-$(CONFIG_CPU_EXYNOS4210) += setup-i2c0.o irq-eint.o dma.o pmu.o
+obj-$(CONFIG_CPU_EXYNOS4210) += setup-i2c0.o irq-eint.o pmu.o
+obj-$(CONFIG_EXYNOS4_DEV_DMA) += dma.o
obj-$(CONFIG_PM) += pm.o sleep.o
obj-$(CONFIG_CPU_IDLE) += cpuidle.o
diff --git a/arch/arm/mach-exynos4/dma.c b/arch/arm/mach-exynos4/dma.c
index c3c0d17..921d31d 100644
--- a/arch/arm/mach-exynos4/dma.c
+++ b/arch/arm/mach-exynos4/dma.c
@@ -24,6 +24,7 @@
#include
#include
#include
+#include
#include
#include
@@ -138,6 +139,9 @@ struct amba_device exynos4_device_pdma1 = {
static int __init exynos4_dma_init(void)
{
+ if (of_have_populated_dt())
+ return 0;
+
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);
--
1.6.6.rc2
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/6] ARM: SAMSUNG: Add device tree support for pl330 dma engine wrappers
A new dma request id 'DMACH_DT_PROP' is introduced for client drivers
requesting a dma channel. This request indicates that a device tree
node property represting the dma channel is available in
'struct samsung_dma_info'. The dma channel request wrapper uses the
node property value as the value for the filter parameter.
Signed-off-by: Thomas Abraham
Acked-by: Kukjin Kim
Acked-by: Grant Likely
---
arch/arm/plat-samsung/dma-ops.c|9 -
arch/arm/plat-samsung/include/plat/dma-ops.h |1 +
arch/arm/plat-samsung/include/plat/dma-pl330.h |3 ++-
3 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/arch/arm/plat-samsung/dma-ops.c b/arch/arm/plat-samsung/dma-ops.c
index 8d18425..b1135dd 100644
--- a/arch/arm/plat-samsung/dma-ops.c
+++ b/arch/arm/plat-samsung/dma-ops.c
@@ -23,11 +23,18 @@ static unsigned samsung_dmadev_request(enum dma_ch dma_ch,
struct dma_chan *chan;
dma_cap_mask_t mask;
struct dma_slave_config slave_config;
+ void *filter_param;
dma_cap_zero(mask);
dma_cap_set(info->cap, mask);
- chan = dma_request_channel(mask, pl330_filter, (void *)dma_ch);
+ /*
+* If a dma channel property of a device node from device tree is
+* specified, use that as the fliter parameter.
+*/
+ filter_param = (dma_ch == DMACH_DT_PROP) ? (void *)info->dt_dmach_prop :
+ (void *)dma_ch;
+ chan = dma_request_channel(mask, pl330_filter, filter_param);
if (info->direction == DMA_FROM_DEVICE) {
memset(&slave_config, 0, sizeof(struct dma_slave_config));
diff --git a/arch/arm/plat-samsung/include/plat/dma-ops.h
b/arch/arm/plat-samsung/include/plat/dma-ops.h
index 4c1a363..22eafc3 100644
--- a/arch/arm/plat-samsung/include/plat/dma-ops.h
+++ b/arch/arm/plat-samsung/include/plat/dma-ops.h
@@ -31,6 +31,7 @@ struct samsung_dma_info {
enum dma_slave_buswidth width;
dma_addr_t fifo;
struct s3c2410_dma_client *client;
+ struct property *dt_dmach_prop;
};
struct samsung_dma_ops {
diff --git a/arch/arm/plat-samsung/include/plat/dma-pl330.h
b/arch/arm/plat-samsung/include/plat/dma-pl330.h
index 2e55e59..c5eaad5 100644
--- a/arch/arm/plat-samsung/include/plat/dma-pl330.h
+++ b/arch/arm/plat-samsung/include/plat/dma-pl330.h
@@ -21,7 +21,8 @@
* use these just as IDs.
*/
enum dma_ch {
- DMACH_UART0_RX,
+ DMACH_DT_PROP = -1,
+ DMACH_UART0_RX = 0,
DMACH_UART0_TX,
DMACH_UART1_RX,
DMACH_UART1_TX,
--
1.6.6.rc2
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/6] DMA: PL330: Add device tree support
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
Cc: Boojin Kim
Signed-off-by: Thomas Abraham
Reviewed-by: Rob Herring
Acked-by: Jassi Brar
Acked-by: Grant Likely
---
.../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 000..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@1268 {
+ compatible = "arm,pl330", "arm,primecell";
+ reg = <0x1268 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 -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
#include
#include
+#include
#define NR_DEFAULT_DESC16
@@ -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 = p
[PATCH 3/6] ARM: EXYNOS4: Modify platform data for pl330 driver
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
Cc: Boojin Kim
Signed-off-by: Thomas Abraham
Acked-by: Kukjin Kim
Acked-by: Grant Likely
---
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_
[PATCH 2/6] DMA: PL330: Infer transfer direction from transfer request instead of platform data
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
Cc: Boojin Kim
Signed-off-by: Thomas Abraham
Acked-by: Jassi Brar
Acked-by: Grant Likely
---
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
[PATCH 1/6] DMA: PL330: move filter function into driver
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
Signed-off-by: Thomas Abraham
Acked-by: Jassi Brar
Acked-by: Grant Likely
---
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
-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
#include
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
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 0/6] Add device tree support for PL330 dma controller driver
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. First patch 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. Second patch 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. Third patch simplifies the platform data for Exynos4 pl330 dma controllers. Similar patches simplifying the platform data for other Samsung platforms is under development. Fourth patch 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. Fifth patch 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. Sixth patch restricts the usage of pl330 device and platform data instances to non-dt platforms. This patchset is based on Linux 3.1-rc6 with the following patch sets. * To use DMA generic APIs for Samsung DMA - v8 - (16 patches) * ARM: Samsung: use dma-pl330 device name for clock (3 patches) * ARM: S5P64X0: Add the devname for DMA clock. * ARM: SAMSUNG: register the second instance of PL330 DMAC (3 patches) This patchset has been tested for both device-tree and non-device-tree based linux 3.1-rc6 kernel. Thomas Abraham (6): 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 .../devicetree/bindings/dma/arm-pl330.txt | 30 +++ arch/arm/mach-exynos4/Kconfig | 10 + arch/arm/mach-exynos4/Makefile |3 +- arch/arm/mach-exynos4/dma.c| 227 ++-- 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 +- 9 files changed, 177 insertions(+), 226 deletions(-) create mode 100644 Documentation/devicetree/bindings/dma/arm-pl330.txt -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v8 00/16] To use DMA generic APIs for Samsung DMA
On Wed, 2011-09-14 at 17:03 +0530, Jassi Brar wrote: > On 14 September 2011 16:47, Vinod Koul wrote: > > >> The changelog for [PATCH v8 04/16] is misleading - we don't need any > >> modification for the reason mentioned in changelog. But the modification > >> has positive side-effect of preventing callbacks during terminate_all which > >> is no way understood from the changelog. So I would like to changelog > >> corrected. > > I thought change log was correct in depicting what patch does and Boojin > > had replied I will check again... > > I didn't reply because I ran out of ways to explain the same thing in > different words. I checked again the patch, change log and your comments. I agree with current change log, and also your observation is right but that is just a side effect, which IMO should be best left to developer to choose or not, in this case she ignored it So no changes to this and I a ready to merge it to my next in a day or two... -- ~Vinod -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 7/7] s3c-adc: Add support for S3C2416/S3C2450
The ADC of the S3C2416/2450 SoC is 10 or 12 bit wide, has its
source selection in the register base+0x18 and its width
selection in bit 03 of the ADCCON register.
Signed-off-by: Heiko Stuebner
---
changes since v1:
move setname call
arch/arm/mach-s3c2416/s3c2416.c |3 +++
arch/arm/plat-samsung/adc.c | 24 +++-
2 files changed, 22 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-s3c2416/s3c2416.c b/arch/arm/mach-s3c2416/s3c2416.c
index 494ce91..4261bdc 100644
--- a/arch/arm/mach-s3c2416/s3c2416.c
+++ b/arch/arm/mach-s3c2416/s3c2416.c
@@ -60,6 +60,7 @@
#include
#include
#include
+#include
static struct map_desc s3c2416_iodesc[] __initdata = {
IODESC_ENT(WATCHDOG),
@@ -97,6 +98,8 @@ int __init s3c2416_init(void)
s3c_fb_setname("s3c2443-fb");
+ s3c_adc_setname("s3c2416-adc");
+
register_syscore_ops(&s3c2416_pm_syscore_ops);
register_syscore_ops(&s3c24xx_irq_syscore_ops);
diff --git a/arch/arm/plat-samsung/adc.c b/arch/arm/plat-samsung/adc.c
index af16957..c53c509 100644
--- a/arch/arm/plat-samsung/adc.c
+++ b/arch/arm/plat-samsung/adc.c
@@ -358,6 +358,7 @@ static int s3c_adc_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
struct adc_device *adc;
+ int cpu = platform_get_device_id(pdev)->driver_data;
struct resource *regs;
int ret;
unsigned tmp;
@@ -421,9 +422,12 @@ static int s3c_adc_probe(struct platform_device *pdev)
clk_enable(adc->clk);
tmp = adc->prescale | S3C2410_ADCCON_PRSCEN;
- if (platform_get_device_id(pdev)->driver_data & S3C_ADC_QUIRK_12BIT) {
- /* Enable 12-bit ADC resolution */
- tmp |= S3C64XX_ADCCON_RESSEL;
+ /* Enable 12-bit ADC resolution */
+ if (cpu & S3C_ADC_QUIRK_12BIT) {
+ if (cpu & S3C_ADC_QUIRK_RESSEL03)
+ tmp |= S3C2416_ADCCON_RESSEL;
+ else
+ tmp |= S3C64XX_ADCCON_RESSEL;
}
writel(tmp, adc->regs + S3C2410_ADCCON);
@@ -491,6 +495,7 @@ static int s3c_adc_resume(struct device *dev)
struct platform_device *pdev = container_of(dev,
struct platform_device, dev);
struct adc_device *adc = platform_get_drvdata(pdev);
+ int cpu = platform_get_device_id(pdev)->driver_data;
int ret;
unsigned long tmp;
@@ -502,8 +507,12 @@ static int s3c_adc_resume(struct device *dev)
tmp = adc->prescale | S3C2410_ADCCON_PRSCEN;
/* Enable 12-bit ADC resolution */
- if (platform_get_device_id(pdev)->driver_data & S3C_ADC_QUIRK_12BIT)
- tmp |= S3C64XX_ADCCON_RESSEL;
+ if (cpu & S3C_ADC_QUIRK_12BIT) {
+ if (cpu & S3C_ADC_QUIRK_RESSEL03)
+ tmp |= S3C2416_ADCCON_RESSEL;
+ else
+ tmp |= S3C64XX_ADCCON_RESSEL;
+ }
writel(tmp, adc->regs + S3C2410_ADCCON);
return 0;
@@ -524,6 +533,11 @@ static struct platform_device_id s3c_adc_driver_ids[] = {
.driver_data= S3C_ADC_QUIRK_10BIT |
S3C_ADC_QUIRK_MUX18,
}, {
+ .name = "s3c2416-adc",
+ .driver_data= S3C_ADC_QUIRK_12BIT |
+ S3C_ADC_QUIRK_MUX18 |
+ S3C_ADC_QUIRK_RESSEL03,
+ }, {
.name = "s3c64xx-adc",
.driver_data= S3C_ADC_QUIRK_12BIT |
S3C_ADC_QUIRK_MUXADCCON |
--
1.7.2.3
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 6/7] s3c-adc: Add support for S3C2443
The S3C2443-adc is 10 bit wide and has its mux-select
in an extra register at base+0x18
Signed-off-by: Heiko Stuebner
---
changes since v1:
wrap line over 80 chars and move setname call
arch/arm/mach-s3c2443/s3c2443.c |3 +++
arch/arm/plat-samsung/adc.c |7 +++
2 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-s3c2443/s3c2443.c b/arch/arm/mach-s3c2443/s3c2443.c
index e6a28ba..11dae3e 100644
--- a/arch/arm/mach-s3c2443/s3c2443.c
+++ b/arch/arm/mach-s3c2443/s3c2443.c
@@ -41,6 +41,7 @@
#include
#include
#include
+#include
static struct map_desc s3c2443_iodesc[] __initdata = {
IODESC_ENT(WATCHDOG),
@@ -70,6 +71,8 @@ int __init s3c2443_init(void)
s3c_nand_setname("s3c2412-nand");
s3c_fb_setname("s3c2443-fb");
+ s3c_adc_setname("s3c2443-adc");
+
/* change WDT IRQ number */
s3c_device_wdt.resource[1].start = IRQ_S3C2443_WDT;
s3c_device_wdt.resource[1].end = IRQ_S3C2443_WDT;
diff --git a/arch/arm/plat-samsung/adc.c b/arch/arm/plat-samsung/adc.c
index 05030ca..af16957 100644
--- a/arch/arm/plat-samsung/adc.c
+++ b/arch/arm/plat-samsung/adc.c
@@ -129,6 +129,9 @@ static inline void s3c_adc_select(struct adc_device *adc,
if (!client->is_ts) {
if (cpu & S3C_ADC_QUIRK_MUX1C)
writel(client->channel & 0xf, adc->regs + S5P_ADCMUX);
+ else if (cpu & S3C_ADC_QUIRK_MUX18)
+ writel(client->channel & 0xf,
+ adc->regs + S3C2443_ADCMUX);
else
con |= S3C2410_ADCCON_SELMUX(client->channel);
}
@@ -517,6 +520,10 @@ static struct platform_device_id s3c_adc_driver_ids[] = {
.driver_data= S3C_ADC_QUIRK_10BIT |
S3C_ADC_QUIRK_MUXADCCON,
}, {
+ .name = "s3c2443-adc",
+ .driver_data= S3C_ADC_QUIRK_10BIT |
+ S3C_ADC_QUIRK_MUX18,
+ }, {
.name = "s3c64xx-adc",
.driver_data= S3C_ADC_QUIRK_12BIT |
S3C_ADC_QUIRK_MUXADCCON |
--
1.7.2.3
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/7] S3C24XX: Allow overriding of adc device name
The adc blocks of S3C2443 and S3C2416 contain quirks not present
in the stock S3C24xx adc. Therefore allow them to alter the
device name via s3c_adc_setname.
Signed-off-by: Heiko Stuebner
---
arch/arm/plat-samsung/include/plat/adc-core.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/plat-samsung/include/plat/adc-core.h
b/arch/arm/plat-samsung/include/plat/adc-core.h
index a281568..a927bee 100644
--- a/arch/arm/plat-samsung/include/plat/adc-core.h
+++ b/arch/arm/plat-samsung/include/plat/adc-core.h
@@ -20,7 +20,7 @@
/* re-define device name depending on support. */
static inline void s3c_adc_setname(char *name)
{
-#ifdef CONFIG_SAMSUNG_DEV_ADC
+#if defined(CONFIG_SAMSUNG_DEV_ADC) || defined(CONFIG_PLAT_S3C24XX)
s3c_device_adc.name = name;
#endif
}
--
1.7.2.3
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/7] s3c-adc: Fix mux bit modification in s3c_adc_select
The mux bits in the adccon register should be cleared only if muxing is really done in ADCCON and not another register. This patch introduces a conditional for this. Signed-off-by: Heiko Stuebner --- arch/arm/plat-samsung/adc.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/arch/arm/plat-samsung/adc.c b/arch/arm/plat-samsung/adc.c index e3456d6..05030ca 100644 --- a/arch/arm/plat-samsung/adc.c +++ b/arch/arm/plat-samsung/adc.c @@ -121,7 +121,8 @@ static inline void s3c_adc_select(struct adc_device *adc, client->select_cb(client, 1); - con &= ~S3C2410_ADCCON_MUXMASK; + if (cpu & S3C_ADC_QUIRK_MUXADCCON) + con &= ~S3C2410_ADCCON_MUXMASK; con &= ~S3C2410_ADCCON_STDBM; con &= ~S3C2410_ADCCON_STARTMASK; -- 1.7.2.3 -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/7] s3c-adc: Replace TYPE_ADCVx conditionals with quirks
This patch replaces the static TYPE_ADCVs checks with checks for
specific features of an adc block. For this the s3c_cpu_type enum
in driver_data ist int containing containing the bit values
describing the indivial adc block.
This patch contains no functional changes, it merely replaces
the type checks with checks for indidual quirks.
Signed-off-by: Heiko Stuebner
---
arch/arm/plat-samsung/adc.c | 33 +
1 files changed, 17 insertions(+), 16 deletions(-)
diff --git a/arch/arm/plat-samsung/adc.c b/arch/arm/plat-samsung/adc.c
index b209d58..e3456d6 100644
--- a/arch/arm/plat-samsung/adc.c
+++ b/arch/arm/plat-samsung/adc.c
@@ -39,12 +39,6 @@
* action is required.
*/
-enum s3c_cpu_type {
- TYPE_ADCV1, /* S3C24XX */
- TYPE_ADCV2, /* S3C64XX, S5P64X0, S5PC100 */
- TYPE_ADCV3, /* S5PV210, S5PC110, EXYNOS4210 */
-};
-
/*
* Resolution of the ADC - 10 or 12 bit
*/
@@ -123,7 +117,7 @@ static inline void s3c_adc_select(struct adc_device *adc,
struct s3c_adc_client *client)
{
unsigned con = readl(adc->regs + S3C2410_ADCCON);
- enum s3c_cpu_type cpu = platform_get_device_id(adc->pdev)->driver_data;
+ int cpu = platform_get_device_id(adc->pdev)->driver_data;
client->select_cb(client, 1);
@@ -132,7 +126,7 @@ static inline void s3c_adc_select(struct adc_device *adc,
con &= ~S3C2410_ADCCON_STARTMASK;
if (!client->is_ts) {
- if (cpu == TYPE_ADCV3)
+ if (cpu & S3C_ADC_QUIRK_MUX1C)
writel(client->channel & 0xf, adc->regs + S5P_ADCMUX);
else
con |= S3C2410_ADCCON_SELMUX(client->channel);
@@ -308,7 +302,7 @@ static irqreturn_t s3c_adc_irq(int irq, void *pw)
{
struct adc_device *adc = pw;
struct s3c_adc_client *client = adc->cur;
- enum s3c_cpu_type cpu = platform_get_device_id(adc->pdev)->driver_data;
+ int cpu = platform_get_device_id(adc->pdev)->driver_data;
unsigned data0, data1;
if (!client) {
@@ -322,7 +316,7 @@ static irqreturn_t s3c_adc_irq(int irq, void *pw)
client->nr_samples--;
- if (cpu != TYPE_ADCV1) {
+ if (cpu & S3C_ADC_QUIRK_12BIT) {
/* S3C64XX/S5P ADC resolution is 12-bit */
data0 &= 0xfff;
data1 &= 0xfff;
@@ -349,7 +343,7 @@ static irqreturn_t s3c_adc_irq(int irq, void *pw)
}
exit:
- if (cpu != TYPE_ADCV1) {
+ if (cpu & S3C_ADC_QUIRK_CLRINT) {
/* Clear ADC interrupt */
writel(0, adc->regs + S3C64XX_ADCCLRINT);
}
@@ -423,7 +417,7 @@ static int s3c_adc_probe(struct platform_device *pdev)
clk_enable(adc->clk);
tmp = adc->prescale | S3C2410_ADCCON_PRSCEN;
- if (platform_get_device_id(pdev)->driver_data != TYPE_ADCV1) {
+ if (platform_get_device_id(pdev)->driver_data & S3C_ADC_QUIRK_12BIT) {
/* Enable 12-bit ADC resolution */
tmp |= S3C64XX_ADCCON_RESSEL;
}
@@ -504,7 +498,7 @@ static int s3c_adc_resume(struct device *dev)
tmp = adc->prescale | S3C2410_ADCCON_PRSCEN;
/* Enable 12-bit ADC resolution */
- if (platform_get_device_id(pdev)->driver_data != TYPE_ADCV1)
+ if (platform_get_device_id(pdev)->driver_data & S3C_ADC_QUIRK_12BIT)
tmp |= S3C64XX_ADCCON_RESSEL;
writel(tmp, adc->regs + S3C2410_ADCCON);
@@ -519,13 +513,20 @@ static int s3c_adc_resume(struct device *dev)
static struct platform_device_id s3c_adc_driver_ids[] = {
{
.name = "s3c24xx-adc",
- .driver_data= TYPE_ADCV1,
+ .driver_data= S3C_ADC_QUIRK_10BIT |
+ S3C_ADC_QUIRK_MUXADCCON,
}, {
.name = "s3c64xx-adc",
- .driver_data= TYPE_ADCV2,
+ .driver_data= S3C_ADC_QUIRK_12BIT |
+ S3C_ADC_QUIRK_MUXADCCON |
+ S3C_ADC_QUIRK_RESSEL16 |
+ S3C_ADC_QUIRK_CLRINT,
}, {
.name = "samsung-adc-v3",
- .driver_data= TYPE_ADCV3,
+ .driver_data= S3C_ADC_QUIRK_12BIT |
+ S3C_ADC_QUIRK_MUX1C |
+ S3C_ADC_QUIRK_RESSEL16 |
+ S3C_ADC_QUIRK_CLRINT,
},
{ }
};
--
1.7.2.3
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/7] s3c-adc: describe features via quirk constants
The adc blocks of S3C2410 through S5P have a multitude of
quirks, i.e. moved bits or whole new registers.
This patch tries to describe these individual features
through constants which can be used to describe an adc.
As SoCs sometimes share only some of these quirks defining
TYPE_ADCVx values for each one wouldn't scale well when
adding more variants.
Signed-off-by: Heiko Stuebner
---
arch/arm/plat-samsung/adc.c | 29 +
1 files changed, 29 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-samsung/adc.c b/arch/arm/plat-samsung/adc.c
index ee8deef..b209d58 100644
--- a/arch/arm/plat-samsung/adc.c
+++ b/arch/arm/plat-samsung/adc.c
@@ -45,6 +45,35 @@ enum s3c_cpu_type {
TYPE_ADCV3, /* S5PV210, S5PC110, EXYNOS4210 */
};
+/*
+ * Resolution of the ADC - 10 or 12 bit
+ */
+#define S3C_ADC_QUIRK_10BIT0
+#define S3C_ADC_QUIRK_12BIT(1<<0)
+
+/*
+ * 12bit ADC can switch resolution between 10 bit and 12 bit
+ * ADCCON bit 03 for S3C2416
+ * ADCCON bit 16 for S3C64XX and up
+ */
+#define S3C_ADC_QUIRK_RESSEL03 (1<<1)
+#define S3C_ADC_QUIRK_RESSEL16 (1<<2)
+
+/*
+ * Input channel select can either be in
+ * - reg ADCCON, bit for S3C24XX and S3C64XX
+ * - reg base+0x18 for 2443/2416/2450
+ * - reg base+0x1C for S5P
+ */
+#define S3C_ADC_QUIRK_MUXADCCON(1<<3)
+#define S3C_ADC_QUIRK_MUX18(1<<4)
+#define S3C_ADC_QUIRK_MUX1C(1<<5)
+
+/*
+ * CLRINT register on S3C64xx
+ */
+#define S3C_ADC_QUIRK_CLRINT (1<<6)
+
struct s3c_adc_client {
struct platform_device *pdev;
struct list_head pend;
--
1.7.2.3
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] video: s3c-fb: Add window positioning support
Hi Florian,
On Sunday 18 September 2011 21:29:57 Florian Tobias Schandinat wrote:
> On 09/07/2011 03:31 PM, Laurent Pinchart wrote:
> > On Thursday 01 September 2011 18:45:18 Florian Tobias Schandinat wrote:
> >> On 08/25/2011 07:51 PM, Ajay Kumar wrote:
> >>> Just as a note, there are many drivers like mx3fb.c, au1200fb.c and
> >>> OMAP seem to be doing window/plane positioning in their driver code.
> >>> Is it possible to have this window positioning support at a common
> >>> place?
> >>
> >> Good point. Congratulations for figuring out that I like to standardize
> >> things. But I think your suggestion is far from being enough to be
> >> useful for userspace (which is our goal so that applications can be
> >> reused along drivers and don't need to know about individual drivers).
> >
> > Beside standardizing things, do you also like to take them one level
> > higher to solve challenging issues ? I know the answer must be yes :-)
> >
> > The problem at hand here is something we have solved in V4L2
> > (theoretically only for part of it) with the media controller API, the
> > V4L2 subdevs and their pad-level format API.
> >
> > In a nutshell, the media controller lets drivers model hardware as a
> > graph of buliding blocks connected through their pads and expose that
> > description to userspace applications. In V4L2 most of those blocks are
> > V4L2 subdevs, which are abstract building blocks that implement sets of
> > standard operations. Those operations are exposed to userspace through
> > the V4L2 subdevs pad-level format API, allowing application to configure
> > sizes and selection rectangles at all pads in the graph. Selection
> > rectangles can be used to configure cropping and composing, which is
> > exactly what the window positioning API needs to do.
> >
> > Instead of creating a new fbdev-specific API to do the same, shouldn't we
> > try to join forces ?
>
> Okay, thanks for the pointer. After having a look at your API I understand
> that it would solve the problem to discover how many windows (in this
> case) are there and how they can be accessed. It looks fine for this
> purpose, powerful enough and not too complex. So if I get it correct we
> still need at least a way to configure the position of the
> windows/overlays/sink pads similar to what Ajay proposed.
Yes, the media controller API can only expose the topology to userspace, it
can't be used to configure FB-specific parameters on the pipeline.
> Additionally a way to get and/or set the z-position of the overlays if
> multiple overlays overlap and set/get how the overlays work (overdraw,
> constant alpha, source/destination color keying). Normally I'd consider
> these link properties but I think implementing them as properties of the
> source framebuffer or sink pad would work as well.
> Is this correct or did I miss something?
That's correct.
What bothers me is that both V4L2 and DRM/KMS have the exact same needs. I
don't think it makes sense to implement three different solutions to the same
problem in our three video-related APIs. What's your opinion about that ?
I've tried to raise the issue on the dri-devel mailing list ("Proposal for a
low-level Linux display framework"), but there's still a long way to go before
convincing everybody. Feel free to help me :-)
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/7] S3C2443/S3C2416: Add adc registers
The adc blocks of the S3C2443 and S3C2416 define some additional registers and bits. Signed-off-by: Heiko Stuebner --- arch/arm/plat-samsung/include/plat/regs-adc.h |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/arch/arm/plat-samsung/include/plat/regs-adc.h b/arch/arm/plat-samsung/include/plat/regs-adc.h index 035e8c3..f42c445 100644 --- a/arch/arm/plat-samsung/include/plat/regs-adc.h +++ b/arch/arm/plat-samsung/include/plat/regs-adc.h @@ -20,6 +20,7 @@ #define S3C2410_ADCDAT0 S3C2410_ADCREG(0x0C) #define S3C2410_ADCDAT1 S3C2410_ADCREG(0x10) #define S3C64XX_ADCUPDNS3C2410_ADCREG(0x14) +#define S3C2443_ADCMUX S3C2410_ADCREG(0x18) #define S3C64XX_ADCCLRINT S3C2410_ADCREG(0x18) #define S5P_ADCMUX S3C2410_ADCREG(0x1C) #define S3C64XX_ADCCLRINTPNDNUPS3C2410_ADCREG(0x20) @@ -33,6 +34,7 @@ #define S3C2410_ADCCON_PRSCVLMASK (0xFF<<6) #define S3C2410_ADCCON_SELMUX(x) (((x)&0x7)<<3) #define S3C2410_ADCCON_MUXMASK (0x7<<3) +#define S3C2416_ADCCON_RESSEL (1<<3) #define S3C2410_ADCCON_STDBM (1<<2) #define S3C2410_ADCCON_READ_START (1<<1) #define S3C2410_ADCCON_ENABLE_START(1<<0) @@ -40,6 +42,7 @@ /* ADCTSC Register Bits */ +#define S3C2443_ADCTSC_UD_SEN (1<<8) #define S3C2410_ADCTSC_YM_SEN (1<<7) #define S3C2410_ADCTSC_YP_SEN (1<<6) #define S3C2410_ADCTSC_XM_SEN (1<<5) -- 1.7.2.3 -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/7] S3C2443/S3C2416: Implement support for ADC
The adc blocks of S3C2443 and S3C2416/2450 differ in some regards from previous (S3C2410, etc) and later (S3C64XX, S5P) SoCs. Defining more TYPE_ADCVx types for these SoCs would complicate the necessary checks a lot. Therefore I opted for the use of quirk constants which can describe the features of the respective adc block and can be tested directly against. This patch series replaces the type checks with checks for specific quirks and adds support for S3C2443 and S3C2416/2450 on top of this. Each patch was compile tested, and I tried to only do "equivalent transforms" for the stuff on lower levels. But as I have only access to S3C2416 hardware, real life testing happened only there. Changes since v1: added a wrap for a line over 80 and moved the adc_setname call to the s3c24XX.c files where all the other names are set. Heiko Stuebner (7): S3C2443/S3C2416: Add adc registers s3c-adc: describe features via quirk constants s3c-adc: Replace TYPE_ADCVx conditionals with quirks s3c-adc: Fix mux bit modification in s3c_adc_select S3C24XX: Allow overriding of adc device name s3c-adc: Add support for S3C2443 s3c-adc: Add support for S3C2416/S3C2450 arch/arm/mach-s3c2416/s3c2416.c |3 + arch/arm/mach-s3c2443/s3c2443.c |3 + arch/arm/plat-samsung/adc.c | 90 +++- arch/arm/plat-samsung/include/plat/adc-core.h |2 +- arch/arm/plat-samsung/include/plat/regs-adc.h |3 + 5 files changed, 80 insertions(+), 20 deletions(-) -- 1.7.2.3 -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] video: s3c-fb: Add window positioning support
Hi Laurent, On 09/07/2011 03:31 PM, Laurent Pinchart wrote: > Hi Florian, > > On Thursday 01 September 2011 18:45:18 Florian Tobias Schandinat wrote: >> Hi all, >> >> On 08/25/2011 07:51 PM, Ajay Kumar wrote: >>> Just as a note, there are many drivers like mx3fb.c, au1200fb.c and OMAP >>> seem to be doing window/plane positioning in their driver code. >>> Is it possible to have this window positioning support at a common place? >> >> Good point. Congratulations for figuring out that I like to standardize >> things. But I think your suggestion is far from being enough to be useful >> for userspace (which is our goal so that applications can be reused along >> drivers and don't need to know about individual drivers). > > Beside standardizing things, do you also like to take them one level higher > to > solve challenging issues ? I know the answer must be yes :-) > > The problem at hand here is something we have solved in V4L2 (theoretically > only for part of it) with the media controller API, the V4L2 subdevs and > their > pad-level format API. > > In a nutshell, the media controller lets drivers model hardware as a graph of > buliding blocks connected through their pads and expose that description to > userspace applications. In V4L2 most of those blocks are V4L2 subdevs, which > are abstract building blocks that implement sets of standard operations. > Those > operations are exposed to userspace through the V4L2 subdevs pad-level format > API, allowing application to configure sizes and selection rectangles at all > pads in the graph. Selection rectangles can be used to configure cropping and > composing, which is exactly what the window positioning API needs to do. > > Instead of creating a new fbdev-specific API to do the same, shouldn't we try > to join forces ? Okay, thanks for the pointer. After having a look at your API I understand that it would solve the problem to discover how many windows (in this case) are there and how they can be accessed. It looks fine for this purpose, powerful enough and not too complex. So if I get it correct we still need at least a way to configure the position of the windows/overlays/sink pads similar to what Ajay proposed. Additionally a way to get and/or set the z-position of the overlays if multiple overlays overlap and set/get how the overlays work (overdraw, constant alpha, source/destination color keying). Normally I'd consider these link properties but I think implementing them as properties of the source framebuffer or sink pad would work as well. Is this correct or did I miss something? Best regards, Florian Tobias Schandinat -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] ARM: EXYNOS4: Modify PMU register setting function
Hi Jongpill,
On 09/15/2011 04:03 AM, Jongpill Lee wrote:
> This patch modifies PMU register setting function to support the other
> Exynos4 series.
>
> Signed-off-by: Jongpill Lee
> ---
> arch/arm/mach-exynos4/include/mach/pmu.h |5 +
> arch/arm/mach-exynos4/include/mach/regs-pmu.h |1 -
> arch/arm/mach-exynos4/pmu.c | 238
> +---
> 3 files changed, 94 insertions(+), 150 deletions(-)
>
> diff --git a/arch/arm/mach-exynos4/include/mach/pmu.h
> b/arch/arm/mach-exynos4/include/mach/pmu.h
> index a952904..430e917 100644
> --- a/arch/arm/mach-exynos4/include/mach/pmu.h
> +++ b/arch/arm/mach-exynos4/include/mach/pmu.h
> @@ -20,6 +20,11 @@ enum sys_powerdown {
> NUM_SYS_POWERDOWN,
> };
>
> +struct exynos4_pmu_conf {
> + void __iomem *reg;
> + unsigned long val[NUM_SYS_POWERDOWN];
Why unsigned long? It's for the registers value, wouldn't u32 fit better?
> +};
> +
> extern void exynos4_sys_powerdown_conf(enum sys_powerdown mode);
>
> #endif /* __ASM_ARCH_PMU_H */
> diff --git a/arch/arm/mach-exynos4/include/mach/regs-pmu.h
> b/arch/arm/mach-exynos4/include/mach/regs-pmu.h
> index cdf9b47..7fa44b9 100644
> --- a/arch/arm/mach-exynos4/include/mach/regs-pmu.h
> +++ b/arch/arm/mach-exynos4/include/mach/regs-pmu.h
> @@ -27,7 +27,6 @@
> #define S5P_USE_STANDBY_WFI1(1<< 17)
> #define S5P_USE_STANDBY_WFE0(1<< 24)
> #define S5P_USE_STANDBY_WFE1(1<< 25)
> -#define S5P_USE_MASK ((0x3<< 16) | (0x3<< 24))
>
> #define S5P_SWRESET S5P_PMUREG(0x0400)
>
> diff --git a/arch/arm/mach-exynos4/pmu.c b/arch/arm/mach-exynos4/pmu.c
> index 7ea9eb2..0210231 100644
> --- a/arch/arm/mach-exynos4/pmu.c
> +++ b/arch/arm/mach-exynos4/pmu.c
> @@ -16,160 +16,100 @@
> #include
> #include
>
> -static void __iomem *sys_powerdown_reg[] = {
> - S5P_ARM_CORE0_LOWPWR,
...
> - S5P_GPS_ALIVE_LOWPWR,
> -};
> +static struct exynos4_pmu_conf *exynos4_pmu_config;
> +
> +static unsigned int exynos4_pmu_entry_cnt;
>
> -static const unsigned int sys_powerdown_val[][NUM_SYS_POWERDOWN] = {
> - /* { AFTR, LPA, SLEEP }*/
> - { 0, 0, 2 },/* ARM_CORE0 */
...
> - { 7, 0, 0 },/* GPS_ALIVE */
> +static struct exynos4_pmu_conf exynos4210_pmu_config[] = {
> + /* { .reg = address, .val = { AFTR, LPA, SLEEP } */
> + { S5P_ARM_CORE0_LOWPWR, { 0x0, 0x0, 0x2 } },
...
> + { S5P_GPS_ALIVE_LOWPWR, { 0x7, 0x0, 0x0 } },
> };
>
> void exynos4_sys_powerdown_conf(enum sys_powerdown mode)
> {
> - unsigned int count = ARRAY_SIZE(sys_powerdown_reg);
> + unsigned int count = exynos4_pmu_entry_cnt;
How about using a sentinel at the array end and getting rid of the global
'exynos4_pmu_entry_cnt' variable? For instance an empty entry { } ?
>
> for (; count> 0; count--)
> - __raw_writel(sys_powerdown_val[count - 1][mode],
> - sys_powerdown_reg[count - 1]);
> + __raw_writel(exynos4_pmu_config[count - 1].val[mode],
> + exynos4_pmu_config[count - 1].reg);
> +}
> +
> +static int __init exynos4_pmu_init(void)
> +{
> + exynos4_pmu_config = exynos4210_pmu_config;
> + exynos4_pmu_entry_cnt = ARRAY_SIZE(exynos4210_pmu_config);
> + printk(KERN_INFO "EXYNOS4210 PMU Initialize\n");
"EXYNOS4210 PMU initialized\n", "EXYNOS4210 PMU initialization
completed\n" ?
Moreover AFAIK pr_info is preferred.
> +
> + return 0;
> }
> +arch_initcall(exynos4_pmu_init);
--
Thanks,
Sylwester
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
