Re: [PATCH v5 6/9] ARM: davinci: Remoteproc driver support for OMAP-L138 DSP

2013-01-15 Thread Sekhar Nori 
On 1/15/2013 6:19 PM, Ohad Ben-Cohen wrote:
> On Tue, Jan 15, 2013 at 2:29 PM, Sekhar Nori  wrote:
>> May be rproc_alloc() could auto-assign the firmware name to something
>> like 'rproc%d-fw' if firmware name passed to it is NULL?
> 
> I prefer we use name-based filenames instead to make it easier for
> users (and us developers).
> 
> We can probably do something like "rproc-%s-fw" with pdata->name
> assuming we/you do maintain a meaningful name in the latter.

Are you thinking of passing name of the remote processor (like m3, dsp0,
dsp1 etc) in pdata->name? That sounds OK since the processor name is
actually tied to the platform. BTW, the current driver seems to be
written for OMAP-L138 rather tightly so you could as well hardcode the
firmware name to 'rproc-dsp-fw'.

Thanks,
Sekhar
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

[PATCH V4 3/3] ARM: davinci: da850: add NAND driver DT entries

2013-01-15 Thread Kumar, Anil 
Add NAND driver DT node and related pinctrl DT data to export NAND
functionality on da850 evm.

Signed-off-by: Kumar, Anil 
---
:100644 100644 c7609d0... 433027f... M  arch/arm/boot/dts/da850-evm.dts
:100644 100644 e9c6e82... 59e6ea4... M  arch/arm/boot/dts/da850.dtsi
 arch/arm/boot/dts/da850-evm.dts |5 +
 arch/arm/boot/dts/da850.dtsi|   30 ++
 2 files changed, 35 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/da850-evm.dts b/arch/arm/boot/dts/da850-evm.dts
index c7609d0..433027f 100644
--- a/arch/arm/boot/dts/da850-evm.dts
+++ b/arch/arm/boot/dts/da850-evm.dts
@@ -28,4 +28,9 @@
status = "okay";
};
};
+   nand_cs3@6200 {
+   status = "okay";
+   pinctrl-names = "default";
+   pinctrl-0 = <&nand_cs3_pins>;
+   };
 };
diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
index e9c6e82..59e6ea4 100644
--- a/arch/arm/boot/dts/da850.dtsi
+++ b/arch/arm/boot/dts/da850.dtsi
@@ -38,6 +38,23 @@
pinctrl-single,register-width = <32>;
pinctrl-single,function-mask = <0x>;
status = "disabled";
+
+   nand_cs3_pins: pinmux_nand_pins {
+   pinctrl-single,bits = <
+   /* EMA_OE, EMA_WE */
+   0x1c 0x0011  0x00ff
+   /* EMA_CS[4],EMA_CS[3]*/
+   0x1c 0x0110  0x0ff0
+   /*
+* EMA_D[0], EMA_D[1], EMA_D[2],
+* EMA_D[3], EMA_D[4], EMA_D[5],
+* EMA_D[6], EMA_D[7]
+*/
+   0x24 0x  0x
+   /* EMA_A[1], EMA_A[2] */
+   0x30 0x0110  0x0ff0
+   >;
+   };
};
serial0: serial@1c42000 {
compatible = "ns16550a";
@@ -67,4 +84,17 @@
status = "disabled";
};
};
+   nand_cs3@6200 {
+   compatible = "ti,davinci-nand";
+   reg = <0x6200 0x807ff
+   0x6800 0x8000>;
+   ti,davinci-chipselect = <1>;
+   ti,davinci-mask-ale = <0>;
+   ti,davinci-mask-cle = <0>;
+   ti,davinci-mask-chipsel = <0>;
+   ti,davinci-ecc-mode = "hw";
+   ti,davinci-ecc-bits = <4>;
+   ti,davinci-nand-use-bbt;
+   status = "disabled";
+   };
 };
-- 
1.7.4.1

___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

[PATCH V4 1/3] ARM: davinci: da850: add pinctrl driver DT entries

2013-01-15 Thread Kumar, Anil 
For DT, DaVinci platform can use pinctrl-single driver for handling
padconf registers.

Enable PINCTRL Kconfig for MACH_DA8XX_DT platform. Add required
pinctrl DT entries in da850 dts file.

 Test procedure
  1)Populate DT file with NAND node information.
  2)Populate board DT file with pinmux information for NAND.
  3)Boot and confirm NAND is detected by the kernel.
  4)cat /proc/mtd to show partitions.

Signed-off-by: Kumar, Anil 
---
:100644 100644 37dc5a3... c7609d0... M  arch/arm/boot/dts/da850-evm.dts
:100644 100644 fbada87... e9c6e82... M  arch/arm/boot/dts/da850.dtsi
:100644 100644 0153950... a075b3e... M  arch/arm/mach-davinci/Kconfig
 arch/arm/boot/dts/da850-evm.dts |3 +++
 arch/arm/boot/dts/da850.dtsi|   10 ++
 arch/arm/mach-davinci/Kconfig   |1 +
 3 files changed, 14 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/da850-evm.dts b/arch/arm/boot/dts/da850-evm.dts
index 37dc5a3..c7609d0 100644
--- a/arch/arm/boot/dts/da850-evm.dts
+++ b/arch/arm/boot/dts/da850-evm.dts
@@ -15,6 +15,9 @@
model = "DA850/AM1808/OMAP-L138 EVM";
 
soc {
+   pmx_core:pinmux@1c14120 {
+   status = "okay";
+   };
serial0: serial@1c42000 {
status = "okay";
};
diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
index fbada87..e9c6e82 100644
--- a/arch/arm/boot/dts/da850.dtsi
+++ b/arch/arm/boot/dts/da850.dtsi
@@ -29,6 +29,16 @@
#size-cells = <1>;
ranges = <0x0 0x01c0 0x40>;
 
+   pmx_core:pinmux@1c14120 {
+   compatible = "pinctrl-single";
+   reg = <0x14120 0x50>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   pinctrl-single,bit-per-mux;
+   pinctrl-single,register-width = <32>;
+   pinctrl-single,function-mask = <0x>;
+   status = "disabled";
+   };
serial0: serial@1c42000 {
compatible = "ns16550a";
reg = <0x42000 0x100>;
diff --git a/arch/arm/mach-davinci/Kconfig b/arch/arm/mach-davinci/Kconfig
index 0153950..a075b3e 100644
--- a/arch/arm/mach-davinci/Kconfig
+++ b/arch/arm/mach-davinci/Kconfig
@@ -62,6 +62,7 @@ config MACH_DA8XX_DT
bool "Support DA8XX platforms using device tree"
default y
depends on ARCH_DAVINCI_DA8XX
+   select PINCTRL
help
  Say y here to include support for TI DaVinci DA850 based using
  Flattened Device Tree. More information at Documentation/devicetree
-- 
1.7.4.1

___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

[PATCH V4 2/3] ARM: davinci: da8xx defconfig: enable pinctrl config option

2013-01-15 Thread Kumar, Anil 
Enable pinctrl related config option in da8xx_omapl_defconfig

Signed-off-by: Kumar, Anil 
---
:100644 100644 f292239... 0892db4... M  arch/arm/configs/da8xx_omapl_defconfig
 arch/arm/configs/da8xx_omapl_defconfig |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/arch/arm/configs/da8xx_omapl_defconfig 
b/arch/arm/configs/da8xx_omapl_defconfig
index f292239..0892db4 100644
--- a/arch/arm/configs/da8xx_omapl_defconfig
+++ b/arch/arm/configs/da8xx_omapl_defconfig
@@ -81,6 +81,7 @@ CONFIG_SERIAL_OF_PLATFORM=y
 CONFIG_I2C=y
 CONFIG_I2C_CHARDEV=y
 CONFIG_I2C_DAVINCI=y
+CONFIG_PINCTRL_SINGLE=y
 # CONFIG_HWMON is not set
 CONFIG_WATCHDOG=y
 CONFIG_REGULATOR=y
-- 
1.7.4.1

___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

[PATCH V4 0/3] ARM: davinci: da850: add pinctrl support

2013-01-15 Thread Kumar, Anil 
This set of patches adds:

* Add pinctrl-single for handling Padconf registers.
* Add NAND node to export NAND functionality on da850 EVM.
* Add NAND pinctrl node to do pin mux according to pinctrl-single driver.


This series applies on top of tag next-20130107 git tree
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
and the following patch

 -drivers/pinctrl: grab default handles from device core
  https://patchwork.kernel.org/patch/1862231/

This series is tested on da850 EVM.

Changes since V3:

 -Move NAND related pinctrl DT data into the da850.dtsi file so it can
  be reused.
 
Changes since V2:

 -Move NAND pins configuration into the nand_cs3 DT node to avoid pins
  configuration if it is not probed.

Changes since V1:

 -Remove the binding documentation as already documented as part of
  Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt
 -Enable PINCTRL Kconfig for MACH_DA8XX_DT platform only.
 -Fix the pinctrl driver node unit-address.
 -Make separate patch for da8xx_omapl_defconfig changes.

Kumar, Anil (3):
  ARM: davinci: da850: add pinctrl driver DT entries
  ARM: davinci: da8xx defconfig: enable pinctrl config option
  ARM: davinci: da850: add NAND driver DT entries

 arch/arm/boot/dts/da850-evm.dts|8 ++
 arch/arm/boot/dts/da850.dtsi   |   40 
 arch/arm/configs/da8xx_omapl_defconfig |1 +
 arch/arm/mach-davinci/Kconfig  |1 +
 4 files changed, 50 insertions(+), 0 deletions(-)

-- 
1.7.4.1

___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

Re: [PATCH v5 6/9] ARM: davinci: Remoteproc driver support for OMAP-L138 DSP

2013-01-15 Thread Ohad Ben-Cohen 
On Wed, Jan 16, 2013 at 1:06 AM, Tivy, Robert  wrote:
> This sounds good, although it will introduce the need to handle dynamic 
> storage for the generated name.  I think I can jam that storage on the end of 
> the already-dynamically-sized 'struct rproc + sizeof(pdata)' allocation in 
> rproc_alloc().

Or you can generate it when needed, without storing the result. This
rarely happens and anyway is negligible.

Thanks,
Ohad.
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

RE: [PATCH v5 6/9] ARM: davinci: Remoteproc driver support for OMAP-L138 DSP

2013-01-15 Thread Tivy, Robert 
> -Original Message-
> From: Ohad Ben-Cohen [mailto:o...@wizery.com]
> Sent: Tuesday, January 15, 2013 4:49 AM
> To: Nori, Sekhar
> Cc: Tivy, Robert; davinci-linux-open-source; linux-arm; Ring, Chris;
> Grosen, Mark; r...@landley.net; linux-...@vger.kernel.org; Chemparathy,
> Cyril
> Subject: Re: [PATCH v5 6/9] ARM: davinci: Remoteproc driver support for
> OMAP-L138 DSP
> 
> On Tue, Jan 15, 2013 at 2:29 PM, Sekhar Nori  wrote:
> > May be rproc_alloc() could auto-assign the firmware name to something
> > like 'rproc%d-fw' if firmware name passed to it is NULL?
> 
> I prefer we use name-based filenames instead to make it easier for
> users (and us developers).
> 
> We can probably do something like "rproc-%s-fw" with pdata->name
> assuming we/you do maintain a meaningful name in the latter.

This sounds good, although it will introduce the need to handle dynamic storage 
for the generated name.  I think I can jam that storage on the end of the 
already-dynamically-sized 'struct rproc + sizeof(pdata)' allocation in 
rproc_alloc().

Thanks & Regards,

- Rob

> 
> Thanks,
> Ohad.
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

[PATCH v5 14/14] ARM: dts: add AM33XX SPI DMA support

2013-01-15 Thread Matt Porter 
Adds DMA resources to the AM33XX SPI nodes.

Signed-off-by: Matt Porter 
---
 arch/arm/boot/dts/am33xx.dtsi |   10 ++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 278b75d..8fd3648 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -356,6 +356,11 @@
interrupt = <65>;
ti,spi-num-cs = <2>;
ti,hwmods = "spi0";
+   dmas = <&edma 16
+   &edma 17
+   &edma 18
+   &edma 19>;
+   dma-names = "tx0", "rx0", "tx1", "rx1";
status = "disabled";
};
 
@@ -367,6 +372,11 @@
interrupt = <125>;
ti,spi-num-cs = <2>;
ti,hwmods = "spi1";
+   dmas = <&edma 42
+   &edma 43
+   &edma 44
+   &edma 45>;
+   dma-names = "tx0", "rx0", "tx1", "rx1";
status = "disabled";
};
 
-- 
1.7.9.5

___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

[PATCH v5 11/14] ARM: dts: add AM33XX MMC support

2013-01-15 Thread Matt Porter 
Adds AM33XX MMC support for am335x-bone, am335x-evm, and
am335x-evmsk.

Signed-off-by: Matt Porter 
Acked-by: Tony Lindgren 
---
 arch/arm/boot/dts/am335x-bone.dts  |7 +++
 arch/arm/boot/dts/am335x-evm.dts   |7 +++
 arch/arm/boot/dts/am335x-evmsk.dts |7 +++
 arch/arm/boot/dts/am33xx.dtsi  |   28 
 4 files changed, 49 insertions(+)

diff --git a/arch/arm/boot/dts/am335x-bone.dts 
b/arch/arm/boot/dts/am335x-bone.dts
index 11b240c..a154ce0 100644
--- a/arch/arm/boot/dts/am335x-bone.dts
+++ b/arch/arm/boot/dts/am335x-bone.dts
@@ -120,6 +120,8 @@
};
 
ldo3_reg: regulator@5 {
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <330>;
regulator-always-on;
};
 
@@ -136,3 +138,8 @@
 &cpsw_emac1 {
phy_id = <&davinci_mdio>, <1>;
 };
+
+&mmc1 {
+   status = "okay";
+   vmmc-supply = <&ldo3_reg>;
+};
diff --git a/arch/arm/boot/dts/am335x-evm.dts b/arch/arm/boot/dts/am335x-evm.dts
index d649644..2907da6 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -232,6 +232,8 @@
};
 
vmmc_reg: regulator@12 {
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <330>;
regulator-always-on;
};
};
@@ -244,3 +246,8 @@
 &cpsw_emac1 {
phy_id = <&davinci_mdio>, <1>;
 };
+
+&mmc1 {
+   status = "okay";
+   vmmc-supply = <&vmmc_reg>;
+};
diff --git a/arch/arm/boot/dts/am335x-evmsk.dts 
b/arch/arm/boot/dts/am335x-evmsk.dts
index f5a6162..f050c46 100644
--- a/arch/arm/boot/dts/am335x-evmsk.dts
+++ b/arch/arm/boot/dts/am335x-evmsk.dts
@@ -244,7 +244,14 @@
};
 
vmmc_reg: regulator@12 {
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <330>;
regulator-always-on;
};
};
 };
+
+&mmc1 {
+   status = "okay";
+   vmmc-supply = <&vmmc_reg>;
+};
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index e711ffb..278b75d 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -235,6 +235,34 @@
status = "disabled";
};
 
+   mmc1: mmc@4806 {
+   compatible = "ti,omap3-hsmmc";
+   ti,hwmods = "mmc1";
+   ti,dual-volt;
+   ti,needs-special-reset;
+   dmas = <&edma 24
+   &edma 25>;
+   dma-names = "tx", "rx";
+   status = "disabled";
+   };
+
+   mmc2: mmc@481d8000 {
+   compatible = "ti,omap3-hsmmc";
+   ti,hwmods = "mmc2";
+   ti,needs-special-reset;
+   dmas = <&edma 2
+   &edma 3>;
+   dma-names = "tx", "rx";
+   status = "disabled";
+   };
+
+   mmc3: mmc@4781 {
+   compatible = "ti,omap3-hsmmc";
+   ti,hwmods = "mmc3";
+   ti,needs-special-reset;
+   status = "disabled";
+   };
+
wdt2: wdt@44e35000 {
compatible = "ti,omap3-wdt";
ti,hwmods = "wd_timer2";
-- 
1.7.9.5

___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

[PATCH v5 12/14] spi: omap2-mcspi: convert to dma_request_slave_channel_compat()

2013-01-15 Thread Matt Porter 
Convert dmaengine channel requests to use
dma_request_slave_channel_compat(). This supports the DT case of
platforms requiring channel selection from either the OMAP DMA or
the EDMA engine. AM33xx only boots from DT and is the only user
implementing EDMA so in the !DT case we can default to the OMAP DMA
filter.

Signed-off-by: Matt Porter 
---
 drivers/spi/spi-omap2-mcspi.c |   65 -
 1 file changed, 45 insertions(+), 20 deletions(-)

diff --git a/drivers/spi/spi-omap2-mcspi.c b/drivers/spi/spi-omap2-mcspi.c
index b610f52..2c02c02 100644
--- a/drivers/spi/spi-omap2-mcspi.c
+++ b/drivers/spi/spi-omap2-mcspi.c
@@ -102,6 +102,9 @@ struct omap2_mcspi_dma {
 
struct completion dma_tx_completion;
struct completion dma_rx_completion;
+
+   char dma_rx_ch_name[14];
+   char dma_tx_ch_name[14];
 };
 
 /* use PIO for small transfers, avoiding DMA setup/teardown overhead and
@@ -822,14 +825,23 @@ static int omap2_mcspi_request_dma(struct spi_device *spi)
dma_cap_zero(mask);
dma_cap_set(DMA_SLAVE, mask);
sig = mcspi_dma->dma_rx_sync_dev;
-   mcspi_dma->dma_rx = dma_request_channel(mask, omap_dma_filter_fn, &sig);
+
+   mcspi_dma->dma_rx =
+   dma_request_slave_channel_compat(mask, omap_dma_filter_fn,
+&sig, &master->dev,
+mcspi_dma->dma_rx_ch_name);
+
if (!mcspi_dma->dma_rx) {
dev_err(&spi->dev, "no RX DMA engine channel for McSPI\n");
return -EAGAIN;
}
 
sig = mcspi_dma->dma_tx_sync_dev;
-   mcspi_dma->dma_tx = dma_request_channel(mask, omap_dma_filter_fn, &sig);
+   mcspi_dma->dma_tx =
+   dma_request_slave_channel_compat(mask, omap_dma_filter_fn,
+&sig, &master->dev,
+mcspi_dma->dma_tx_ch_name);
+
if (!mcspi_dma->dma_tx) {
dev_err(&spi->dev, "no TX DMA engine channel for McSPI\n");
dma_release_channel(mcspi_dma->dma_rx);
@@ -1223,29 +1235,42 @@ static int omap2_mcspi_probe(struct platform_device 
*pdev)
goto free_master;
 
for (i = 0; i < master->num_chipselect; i++) {
-   char dma_ch_name[14];
+   char *dma_rx_ch_name = mcspi->dma_channels[i].dma_rx_ch_name;
+   char *dma_tx_ch_name = mcspi->dma_channels[i].dma_tx_ch_name;
struct resource *dma_res;
 
-   sprintf(dma_ch_name, "rx%d", i);
-   dma_res = platform_get_resource_byname(pdev, IORESOURCE_DMA,
-   dma_ch_name);
-   if (!dma_res) {
-   dev_dbg(&pdev->dev, "cannot get DMA RX channel\n");
-   status = -ENODEV;
-   break;
-   }
+   sprintf(dma_rx_ch_name, "rx%d", i);
+   if (!pdev->dev.of_node) {
+   dma_res =
+   platform_get_resource_byname(pdev,
+IORESOURCE_DMA,
+dma_rx_ch_name);
+   if (!dma_res) {
+   dev_dbg(&pdev->dev,
+   "cannot get DMA RX channel\n");
+   status = -ENODEV;
+   break;
+   }
 
-   mcspi->dma_channels[i].dma_rx_sync_dev = dma_res->start;
-   sprintf(dma_ch_name, "tx%d", i);
-   dma_res = platform_get_resource_byname(pdev, IORESOURCE_DMA,
-   dma_ch_name);
-   if (!dma_res) {
-   dev_dbg(&pdev->dev, "cannot get DMA TX channel\n");
-   status = -ENODEV;
-   break;
+   mcspi->dma_channels[i].dma_rx_sync_dev =
+   dma_res->start;
}
+   sprintf(dma_tx_ch_name, "tx%d", i);
+   if (!pdev->dev.of_node) {
+   dma_res =
+   platform_get_resource_byname(pdev,
+IORESOURCE_DMA,
+dma_tx_ch_name);
+   if (!dma_res) {
+   dev_dbg(&pdev->dev,
+   "cannot get DMA TX channel\n");
+   status = -ENODEV;
+   break;
+   }
 
-   mcspi->dma_channels[i].dma_tx_sync_dev = dma_res->start;
+   mcspi->dma_channels[i].dma_tx_sync_dev =
+   dma_res->start;
+

[PATCH v5 10/14] mmc: omap_hsmmc: add generic DMA request support to the DT binding

2013-01-15 Thread Matt Porter 
The binding definition is based on the generic DMA request binding.

Signed-off-by: Matt Porter 
Acked-by: Tony Lindgren 
---
 .../devicetree/bindings/mmc/ti-omap-hsmmc.txt  |   25 +++-
 1 file changed, 24 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt 
b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
index ed271fc..826cc51 100644
--- a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
+++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
@@ -20,8 +20,28 @@ ti,dual-volt: boolean, supports dual voltage cards
 ti,non-removable: non-removable slot (like eMMC)
 ti,needs-special-reset: Requires a special softreset sequence
 ti,needs-special-hs-handling: HSMMC IP needs special setting for handling High 
Speed
+dmas: DMA controller phandle and DMA request value ordered pair
+One tx and one rx pair is required.
+dma-names: DMA request names. These strings correspond 1:1 with
+the ordered pairs in dmas. The RX request must be "rx" and the
+TX request must be "tx".
+
+Examples:
+
+[hwmod populated DMA resources]
+
+   mmc1: mmc@0x4809c000 {
+   compatible = "ti,omap4-hsmmc";
+   reg = <0x4809c000 0x400>;
+   ti,hwmods = "mmc1";
+   ti,dual-volt;
+   bus-width = <4>;
+   vmmc-supply = <&vmmc>; /* phandle to regulator node */
+   ti,non-removable;
+   };
+
+[generic DMA request binding]
 
-Example:
mmc1: mmc@0x4809c000 {
compatible = "ti,omap4-hsmmc";
reg = <0x4809c000 0x400>;
@@ -30,4 +50,7 @@ Example:
bus-width = <4>;
vmmc-supply = <&vmmc>; /* phandle to regulator node */
ti,non-removable;
+   dmas = <&edma 24
+   &edma 25>;
+   dma-names = "tx", "rx";
};
-- 
1.7.9.5

___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

[PATCH v5 09/14] mmc: omap_hsmmc: set max_segs based on dma engine limitations

2013-01-15 Thread Matt Porter 
The EDMA DMAC has a hardware limitation that prevents supporting
scatter gather lists with any number of segments. The DMA Engine
API reports the maximum number of segments a channel can support
via the optional dma_get_channel_caps() API. If the nr_segs
capability is present, the value is used to configure mmc->max_segs
appropriately.

Signed-off-by: Matt Porter 
Acked-by: Tony Lindgren 
---
 drivers/mmc/host/omap_hsmmc.c |6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index e79b12d..f74bd69 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -1769,6 +1769,7 @@ static int omap_hsmmc_probe(struct platform_device *pdev)
const struct of_device_id *match;
dma_cap_mask_t mask;
unsigned tx_req, rx_req;
+   struct dmaengine_chan_caps *dma_chan_caps;
struct pinctrl *pinctrl;
 
match = of_match_device(of_match_ptr(omap_mmc_of_match), &pdev->dev);
@@ -1935,6 +1936,11 @@ static int omap_hsmmc_probe(struct platform_device *pdev)
goto err_irq;
}
 
+   /* Some DMA Engines only handle a limited number of SG segments */
+   dma_chan_caps = dma_get_channel_caps(host->rx_chan, DMA_DEV_TO_MEM);
+   if (dma_chan_caps && dma_chan_caps->seg_nr)
+   mmc->max_segs = dma_chan_caps->seg_nr;
+
/* Request IRQ for MMC operations */
ret = request_irq(host->irq, omap_hsmmc_irq, 0,
mmc_hostname(mmc), host);
-- 
1.7.9.5

___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

[PATCH v5 13/14] spi: omap2-mcspi: add generic DMA request support to the DT binding

2013-01-15 Thread Matt Porter 
The binding definition is based on the generic DMA request binding.

Signed-off-by: Matt Porter 
---
 Documentation/devicetree/bindings/spi/omap-spi.txt |   28 +++-
 1 file changed, 27 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/spi/omap-spi.txt 
b/Documentation/devicetree/bindings/spi/omap-spi.txt
index 938809c..3bd8eed 100644
--- a/Documentation/devicetree/bindings/spi/omap-spi.txt
+++ b/Documentation/devicetree/bindings/spi/omap-spi.txt
@@ -10,7 +10,18 @@ Required properties:
  input. The default is D0 as input and
  D1 as output.
 
-Example:
+Optional properties:
+- dmas: List of DMA controller phandle and DMA request ordered
+   pairs. One tx and one rx pair is required for each chip
+   select.
+- dma-names: List of DMA request names. These strings correspond
+   1:1 with the ordered pairs in dmas. The string naming is
+   to be "rxN" and "txN" for RX and TX requests,
+   respectively, where N equals the chip select number.
+
+Examples:
+
+[hwmod populated DMA resources]
 
 mcspi1: mcspi@1 {
 #address-cells = <1>;
@@ -20,3 +31,18 @@ mcspi1: mcspi@1 {
 ti,spi-num-cs = <4>;
 };
 
+[generic DMA request binding]
+
+mcspi1: mcspi@1 {
+#address-cells = <1>;
+#size-cells = <0>;
+compatible = "ti,omap4-mcspi";
+ti,hwmods = "mcspi1";
+ti,spi-num-cs = <2>;
+dmas = <&edma 42
+   &edma 43
+   &edma 44
+   &edma 45>;
+dma-names = "tx0", "rx0", "tx1", "rx1";
+};
+
-- 
1.7.9.5

___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

[PATCH v5 07/14] dmaengine: add dma_request_slave_channel_compat()

2013-01-15 Thread Matt Porter 
Adds a dma_request_slave_channel_compat() wrapper which accepts
both the arguments from dma_request_channel() and
dma_request_slave_channel(). Based on whether the driver is
instantiated via DT, the appropriate channel request call will be
made.

This allows for a much cleaner migration of drivers to the
dmaengine DT API as platforms continue to be mixed between those
that boot using DT and those that do not.

Suggested-by: Tony Lindgren 
Signed-off-by: Matt Porter 
Acked-by: Tony Lindgren 
---
 include/linux/dmaengine.h |   10 ++
 1 file changed, 10 insertions(+)

diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
index 9fd0c5b..64f9f69 100644
--- a/include/linux/dmaengine.h
+++ b/include/linux/dmaengine.h
@@ -1047,6 +1047,16 @@ void dma_run_dependencies(struct dma_async_tx_descriptor 
*tx);
 struct dma_chan *dma_find_channel(enum dma_transaction_type tx_type);
 struct dma_chan *net_dma_find_channel(void);
 #define dma_request_channel(mask, x, y) __dma_request_channel(&(mask), x, y)
+static inline struct dma_chan
+*dma_request_slave_channel_compat(dma_cap_mask_t mask, dma_filter_fn fn,
+ void *fn_param, struct device *dev,
+ char *name)
+{
+   if (dev->of_node)
+   return dma_request_slave_channel(dev, name);
+   else
+   return dma_request_channel(mask, fn, fn_param);
+}
 
 /* --- Helper iov-locking functions --- */
 
-- 
1.7.9.5

___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

[PATCH v5 06/14] ARM: dts: add AM33XX EDMA support

2013-01-15 Thread Matt Porter 
Adds AM33XX EDMA support to the am33xx.dtsi as documented in
Documentation/devicetree/bindings/dma/ti-edma.txt

Signed-off-by: Matt Porter 
---
 arch/arm/boot/dts/am33xx.dtsi |   20 
 1 file changed, 20 insertions(+)

diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index c2f14e8..e711ffb 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -87,6 +87,26 @@
reg = <0x4820 0x1000>;
};
 
+   edma: edma@4900 {
+   compatible = "ti,edma3";
+   ti,hwmods = "tpcc", "tptc0", "tptc1", "tptc2";
+   reg =   <0x4900 0x1>,
+   <0x44e10f90 0x10>;
+   interrupt-parent = <&intc>;
+   interrupts = <12 13 14>;
+   #dma-cells = <1>;
+   dma-channels = <64>;
+   ti,edma-regions = <4>;
+   ti,edma-slots = <256>;
+   ti,edma-queue-tc-map = <0 0
+   1 1
+   2 2>;
+   ti,edma-queue-priority-map = <0 0
+ 1 1
+ 2 2>;
+   ti,edma-default-queue = <0>;
+   };
+
gpio1: gpio@44e07000 {
compatible = "ti,omap4-gpio";
ti,hwmods = "gpio1";
-- 
1.7.9.5

___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

[PATCH v5 05/14] dmaengine: edma: Add TI EDMA device tree binding

2013-01-15 Thread Matt Porter 
The binding definition is based on the generic DMA controller
binding.

Signed-off-by: Matt Porter 
---
 Documentation/devicetree/bindings/dma/ti-edma.txt |   49 +
 1 file changed, 49 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/dma/ti-edma.txt

diff --git a/Documentation/devicetree/bindings/dma/ti-edma.txt 
b/Documentation/devicetree/bindings/dma/ti-edma.txt
new file mode 100644
index 000..075a60e3
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/ti-edma.txt
@@ -0,0 +1,49 @@
+TI EDMA
+
+Required properties:
+- compatible : "ti,edma3"
+- ti,hwmods: Name of the hwmods associated to the EDMA
+- ti,edma-regions: Number of regions
+- ti,edma-slots: Number of slots
+- ti,edma-queue-tc-map: List of transfer control to queue mappings
+- ti,edma-queue-priority-map: List of queue priority mappings
+- ti,edma-default-queue: Default queue value
+
+Optional properties:
+- ti,edma-reserved-channels: List of reserved channel regions
+- ti,edma-reserved-slots: List of reserved slot regions
+- ti,edma-xbar-event-map: Crossbar event to channel map
+
+Example:
+
+edma: edma@4900 {
+   reg = <0x4900 0x1>;
+   interrupt-parent = <&intc>;
+   interrupts = <12 13 14>;
+   compatible = "ti,edma3";
+   ti,hwmods = "tpcc", "tptc0", "tptc1", "tptc2";
+   #dma-cells = <1>;
+   dma-channels = <64>;
+   ti,edma-regions = <4>;
+   ti,edma-slots = <256>;
+   ti,edma-reserved-channels = <0  2
+14 2
+26 6
+48 4
+56 8>;
+   ti,edma-reserved-slots = <0  2
+ 14 2
+ 26 6
+ 48 4
+ 56 8
+ 64 127>;
+   ti,edma-queue-tc-map = <0 0
+   1 1
+   2 2>;
+   ti,edma-queue-priority-map = <0 0
+ 1 1
+ 2 2>;
+   ti,edma-default-queue = <0>;
+   ti,edma-xbar-event-map = <1 12
+ 2 13>;
+};
-- 
1.7.9.5

___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

[PATCH v5 00/14] DMA Engine support for AM33XX

2013-01-15 Thread Matt Porter 
Changes since v4:
- Fixed debug section mismatch in private edma api [01/14]
- Respun format-patch to catch the platform_data/edma.h rename [01/14]
- Removed address/size-cells from the EDMA binding [05/14]

Changes since v3:
- Rebased on 3.8-rc3
- No longer an RFC
- Fixed bugs in DT/pdata parsing reported by Vaibhav Bedia
- Restored all the Davinci pdata to const
- Removed max_segs hack in favor of using dma_get_channel_caps()
- Fixed extra parens, __raw_* accessors and, ioremap error checks
  in xbar handling
- Removed excess license info in platform_data/edma.h
- Removed unneeded reserved channels data for AM33xx
- Removed test-specific pinmuxing from dts files
- Adjusted mmc1 node to be disabled by default in the dtsi

Changes since v2:
- Rebased on 3.7-rc1
- Fixed bug in DT/pdata parsing first found by Gururaja
  that turned out to be masked by some toolchains
- Dropped unused mach-omap2/devices.c hsmmc patch
- Added AM33XX crossbar DMA event mux support
- Added am335x-evm support

Changes since v1:
- Rebased on top of mainline from 12250d8
- Dropped the feature removal schedule patch
- Implemented dma_request_slave_channel_compat() and
  converted the mmc and spi drivers to use it
- Dropped unneeded #address-cells and #size-cells from
  EDMA DT support
- Moved private EDMA header to linux/platform_data/ and
  removed some unneeded definitions
- Fixed parsing of optional properties

This series adds DMA Engine support for AM33xx, which uses
an EDMA DMAC. The EDMA DMAC has been previously supported by only
a private API implementation (much like the situation with OMAP
DMA) found on the DaVinci family of SoCs.

The series applies on top of 3.8-rc3 and the following patches:

- TPS65910 REGMAP_IRQ build fix:
  https://patchwork.kernel.org/patch/1857701/
- dmaengine DT support from Vinod's dmaengine_dt branch in
  git://git.infradead.org/users/vkoul/slave-dma.git since
  027478851791df751176398be02a3b1c5f6aa824
- edma dmaengine driver fix:
  https://patchwork.kernel.org/patch/1961521/
- dmaengine dma_get_channel_caps v2:
  https://patchwork.kernel.org/patch/1961601/
- dmaengine edma driver channel caps support v2:
  https://patchwork.kernel.org/patch/1961591/

The approach taken is similar to how OMAP DMA is being converted to
DMA Engine support. With the functional EDMA private API already
existing in mach-davinci/dma.c, we first move that to an ARM common
area so it can be shared. Adding DT and runtime PM support to the
private EDMA API implementation allows it to run on AM33xx. AM33xx
*only* boots using DT so we leverage Jon's generic DT DMA helpers to
register EDMA DMAC with the of_dma framework and then add support
for calling the dma_request_slave_channel() API to both the mmc
and spi drivers.

With this series both BeagleBone and the AM335x EVM have working
MMC and SPI support.

This is tested on BeagleBone with a SPI framebuffer driver and MMC
rootfs. A trivial gpio DMA event misc driver was used to test the
crossbar DMA event support. It is also tested on the AM335x EVM
with the onboard SPI flash and MMC rootfs. The branch at
https://github.com/ohporter/linux/tree/edma-dmaengine-am33xx-v4
has the complete series, dependencies, and some test
drivers/defconfigs.

Regression testing was done on AM180x-EVM (which also makes use
of the EDMA dmaengine driver and the EDMA private API) using SD,
SPI flash, and the onboard audio supported by the ASoC Davinci
driver. Regression testing was also done on a BeagleBoard xM
booting from the legacy board file using MMC rootfs.

Matt Porter (14):
  ARM: davinci: move private EDMA API to arm/common
  ARM: edma: remove unused transfer controller handlers
  ARM: edma: add AM33XX support to the private EDMA API
  dmaengine: edma: enable build for AM33XX
  dmaengine: edma: Add TI EDMA device tree binding
  ARM: dts: add AM33XX EDMA support
  dmaengine: add dma_request_slave_channel_compat()
  mmc: omap_hsmmc: convert to dma_request_slave_channel_compat()
  mmc: omap_hsmmc: set max_segs based on dma engine limitations
  mmc: omap_hsmmc: add generic DMA request support to the DT binding
  ARM: dts: add AM33XX MMC support
  spi: omap2-mcspi: convert to dma_request_slave_channel_compat()
  spi: omap2-mcspi: add generic DMA request support to the DT binding
  ARM: dts: add AM33XX SPI DMA support

 Documentation/devicetree/bindings/dma/ti-edma.txt  |   49 +++
 .../devicetree/bindings/mmc/ti-omap-hsmmc.txt  |   25 +-
 Documentation/devicetree/bindings/spi/omap-spi.txt |   28 +-
 arch/arm/Kconfig   |1 +
 arch/arm/boot/dts/am335x-bone.dts  |7 +
 arch/arm/boot/dts/am335x-evm.dts   |7

[PATCH v5 08/14] mmc: omap_hsmmc: convert to dma_request_slave_channel_compat()

2013-01-15 Thread Matt Porter 
Convert dmaengine channel requests to use
dma_request_slave_channel_compat(). This supports the DT case of
platforms requiring channel selection from either the OMAP DMA or
the EDMA engine. AM33xx only boots from DT and is the only user
implementing EDMA so in the !DT case we can default to the OMAP DMA
filter.

Signed-off-by: Matt Porter 
Acked-by: Tony Lindgren 
---
 drivers/mmc/host/omap_hsmmc.c |   10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index bc58078..e79b12d 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -1915,14 +1915,20 @@ static int omap_hsmmc_probe(struct platform_device 
*pdev)
dma_cap_zero(mask);
dma_cap_set(DMA_SLAVE, mask);
 
-   host->rx_chan = dma_request_channel(mask, omap_dma_filter_fn, &rx_req);
+   host->rx_chan =
+   dma_request_slave_channel_compat(mask, omap_dma_filter_fn,
+&rx_req, &pdev->dev, "rx");
+
if (!host->rx_chan) {
dev_err(mmc_dev(host->mmc), "unable to obtain RX DMA engine 
channel %u\n", rx_req);
ret = -ENXIO;
goto err_irq;
}
 
-   host->tx_chan = dma_request_channel(mask, omap_dma_filter_fn, &tx_req);
+   host->tx_chan =
+   dma_request_slave_channel_compat(mask, omap_dma_filter_fn,
+&tx_req, &pdev->dev, "tx");
+
if (!host->tx_chan) {
dev_err(mmc_dev(host->mmc), "unable to obtain TX DMA engine 
channel %u\n", tx_req);
ret = -ENXIO;
-- 
1.7.9.5

___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

[PATCH v5 04/14] dmaengine: edma: enable build for AM33XX

2013-01-15 Thread Matt Porter 
Enable TI EDMA option on OMAP.

Signed-off-by: Matt Porter 
---
 drivers/dma/Kconfig |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index d4c1218..20ef955 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -221,7 +221,7 @@ config SIRF_DMA
 
 config TI_EDMA
tristate "TI EDMA support"
-   depends on ARCH_DAVINCI
+   depends on ARCH_DAVINCI || ARCH_OMAP
select DMA_ENGINE
select DMA_VIRTUAL_CHANNELS
default n
-- 
1.7.9.5

___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

[PATCH v5 01/14] ARM: davinci: move private EDMA API to arm/common

2013-01-15 Thread Matt Porter 
Move mach-davinci/dma.c to common/edma.c so it can be used
by OMAP (specifically AM33xx) as well. This just moves the
private EDMA API and enables it to build on OMAP.

Signed-off-by: Matt Porter 
---
 arch/arm/Kconfig   |1 +
 arch/arm/common/Kconfig|3 +
 arch/arm/common/Makefile   |1 +
 arch/arm/{mach-davinci/dma.c => common/edma.c} |4 +-
 arch/arm/mach-davinci/Makefile |2 +-
 arch/arm/mach-davinci/board-tnetv107x-evm.c|2 +-
 arch/arm/mach-davinci/davinci.h|2 +-
 arch/arm/mach-davinci/devices-tnetv107x.c  |2 +-
 arch/arm/mach-davinci/devices.c|7 +-
 arch/arm/mach-davinci/dm355.c  |2 +-
 arch/arm/mach-davinci/dm365.c  |2 +-
 arch/arm/mach-davinci/dm644x.c |2 +-
 arch/arm/mach-davinci/dm646x.c |2 +-
 arch/arm/mach-davinci/include/mach/da8xx.h |2 +-
 arch/arm/plat-omap/Kconfig |1 +
 drivers/dma/edma.c |2 +-
 drivers/mmc/host/davinci_mmc.c |1 +
 include/linux/mfd/davinci_voicecodec.h |3 +-
 .../mach => include/linux/platform_data}/edma.h|   89 +---
 include/linux/platform_data/spi-davinci.h  |2 +-
 sound/soc/davinci/davinci-evm.c|1 +
 sound/soc/davinci/davinci-pcm.c|1 +
 sound/soc/davinci/davinci-pcm.h|2 +-
 sound/soc/davinci/davinci-sffsdr.c |6 +-
 24 files changed, 33 insertions(+), 109 deletions(-)
 rename arch/arm/{mach-davinci/dma.c => common/edma.c} (99%)
 rename {arch/arm/mach-davinci/include/mach => 
include/linux/platform_data}/edma.h (59%)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 67874b8..7637d31 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -932,6 +932,7 @@ config ARCH_DAVINCI
select GENERIC_IRQ_CHIP
select HAVE_IDE
select NEED_MACH_GPIO_H
+   select TI_PRIV_EDMA
select USE_OF
select ZONE_DMA
help
diff --git a/arch/arm/common/Kconfig b/arch/arm/common/Kconfig
index 45ceeb0..9e32d0d 100644
--- a/arch/arm/common/Kconfig
+++ b/arch/arm/common/Kconfig
@@ -40,3 +40,6 @@ config SHARP_PARAM
 
 config SHARP_SCOOP
bool
+
+config TI_PRIV_EDMA
+   bool
diff --git a/arch/arm/common/Makefile b/arch/arm/common/Makefile
index e8a4e58..d09a39b 100644
--- a/arch/arm/common/Makefile
+++ b/arch/arm/common/Makefile
@@ -13,3 +13,4 @@ obj-$(CONFIG_SHARP_PARAM) += sharpsl_param.o
 obj-$(CONFIG_SHARP_SCOOP)  += scoop.o
 obj-$(CONFIG_PCI_HOST_ITE8152)  += it8152.o
 obj-$(CONFIG_ARM_TIMER_SP804)  += timer-sp.o
+obj-$(CONFIG_TI_PRIV_EDMA) += edma.o
diff --git a/arch/arm/mach-davinci/dma.c b/arch/arm/common/edma.c
similarity index 99%
rename from arch/arm/mach-davinci/dma.c
rename to arch/arm/common/edma.c
index a685e97..be3c04a 100644
--- a/arch/arm/mach-davinci/dma.c
+++ b/arch/arm/common/edma.c
@@ -25,7 +25,7 @@
 #include 
 #include 
 
-#include 
+#include 
 
 /* Offsets matching "struct edmacc_param" */
 #define PARM_OPT   0x00
@@ -1387,7 +1387,7 @@ EXPORT_SYMBOL(edma_clear_event);
 
 /*---*/
 
-static int __init edma_probe(struct platform_device *pdev)
+static int edma_probe(struct platform_device *pdev)
 {
struct edma_soc_info**info = pdev->dev.platform_data;
const s8(*queue_priority_mapping)[2];
diff --git a/arch/arm/mach-davinci/Makefile b/arch/arm/mach-davinci/Makefile
index fb5c1aa..493a36b 100644
--- a/arch/arm/mach-davinci/Makefile
+++ b/arch/arm/mach-davinci/Makefile
@@ -5,7 +5,7 @@
 
 # Common objects
 obj-y  := time.o clock.o serial.o psc.o \
-  dma.o usb.o common.o sram.o aemif.o
+  usb.o common.o sram.o aemif.o
 
 obj-$(CONFIG_DAVINCI_MUX)  += mux.o
 
diff --git a/arch/arm/mach-davinci/board-tnetv107x-evm.c 
b/arch/arm/mach-davinci/board-tnetv107x-evm.c
index be30997..86f55ba 100644
--- a/arch/arm/mach-davinci/board-tnetv107x-evm.c
+++ b/arch/arm/mach-davinci/board-tnetv107x-evm.c
@@ -26,12 +26,12 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/arch/arm/mach-davinci/davinci.h b/arch/arm/mach-davinci/davinci.h
index 12d544b..d26a6bc 100644
--- a/arch/arm/mach-davinci/davinci.h
+++ b/arch/arm/mach-davinci/davinci.h
@@ -23,9 +23,9 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
-#include 
 
 #include 
 #include 
diff --git a/arch/arm/mach-davinci/devices-tnetv107x.c 
b/arch/arm/mach-davinci/devices-tnetv107x.c
index 773ab07..ba37760 100644
--- a/arch/arm/mach-davinci/devices-tnetv107x.c

[PATCH v5 03/14] ARM: edma: add AM33XX support to the private EDMA API

2013-01-15 Thread Matt Porter 
Adds support for parsing the TI EDMA DT data into the required
EDMA private API platform data. Enables runtime PM support to
initialize the EDMA hwmod. Adds AM33XX EMDA crossbar event mux
support.

Signed-off-by: Matt Porter 
---
 arch/arm/common/edma.c |  314 ++--
 include/linux/platform_data/edma.h |1 +
 2 files changed, 306 insertions(+), 9 deletions(-)

diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
index 2dce245..beeb1d2 100644
--- a/arch/arm/common/edma.c
+++ b/arch/arm/common/edma.c
@@ -24,6 +24,13 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
 
 #include 
 
@@ -723,6 +730,9 @@ EXPORT_SYMBOL(edma_free_channel);
  */
 int edma_alloc_slot(unsigned ctlr, int slot)
 {
+   if (!edma_cc[ctlr])
+   return -EINVAL;
+
if (slot >= 0)
slot = EDMA_CHAN_SLOT(slot);
 
@@ -1366,31 +1376,291 @@ void edma_clear_event(unsigned channel)
 EXPORT_SYMBOL(edma_clear_event);
 
 /*---*/
+static int edma_of_read_u32_to_s8_array(const struct device_node *np,
+const char *propname, s8 *out_values,
+size_t sz)
+{
+   struct property *prop = of_find_property(np, propname, NULL);
+   const __be32 *val;
+
+   if (!prop)
+   return -EINVAL;
+   if (!prop->value)
+   return -ENODATA;
+   if ((sz * sizeof(u32)) > prop->length)
+   return -EOVERFLOW;
+
+   val = prop->value;
+
+   while (sz--)
+   *out_values++ = (s8)(be32_to_cpup(val++) & 0xff);
+
+   /* Terminate it */
+   *out_values++ = -1;
+   *out_values++ = -1;
+
+   return 0;
+}
+
+static int edma_of_read_u32_to_s16_array(const struct device_node *np,
+const char *propname, s16 *out_values,
+size_t sz)
+{
+   struct property *prop = of_find_property(np, propname, NULL);
+   const __be32 *val;
+
+   if (!prop)
+   return -EINVAL;
+   if (!prop->value)
+   return -ENODATA;
+   if ((sz * sizeof(u32)) > prop->length)
+   return -EOVERFLOW;
+
+   val = prop->value;
+
+   while (sz--)
+   *out_values++ = (s16)(be32_to_cpup(val++) & 0x);
+
+   /* Terminate it */
+   *out_values++ = -1;
+   *out_values++ = -1;
+
+   return 0;
+}
+
+static int edma_xbar_event_map(struct device *dev,
+  struct device_node *node,
+  struct edma_soc_info *pdata, int len)
+{
+   int ret = 0;
+   int i;
+   struct resource res;
+   void *xbar;
+   const s16 (*xbar_chans)[2];
+   u32 shift, offset, mux;
+
+   xbar_chans = devm_kzalloc(dev,
+ len/sizeof(s16) + 2*sizeof(s16),
+ GFP_KERNEL);
+   if (!xbar_chans)
+   return -ENOMEM;
+
+   ret = of_address_to_resource(node, 1, &res);
+   if (IS_ERR_VALUE(ret))
+   return -EIO;
+
+   xbar = devm_ioremap(dev, res.start, resource_size(&res));
+   if (!xbar)
+   return -ENOMEM;
+
+   ret = edma_of_read_u32_to_s16_array(node,
+   "ti,edma-xbar-event-map",
+   (s16 *)xbar_chans,
+   len/sizeof(u32));
+   if (IS_ERR_VALUE(ret))
+   return -EIO;
+
+   for (i = 0; xbar_chans[i][0] != -1; i++) {
+   shift = (xbar_chans[i][1] % 4) * 8;
+   offset = xbar_chans[i][1] >> 2;
+   offset <<= 2;
+   mux = readl((void *)((u32)xbar + offset));
+   mux &= ~(0xff << shift);
+   mux |= xbar_chans[i][0] << shift;
+   writel(mux, (void *)((u32)xbar + offset));
+   }
+
+   pdata->xbar_chans = xbar_chans;
+
+   return 0;
+}
+
+static int edma_of_parse_dt(struct device *dev,
+   struct device_node *node,
+   struct edma_soc_info *pdata)
+{
+   int ret = 0;
+   u32 value;
+   struct property *prop;
+   size_t sz;
+   struct edma_rsv_info *rsv_info;
+   const s16 (*rsv_chans)[2], (*rsv_slots)[2];
+   const s8 (*queue_tc_map)[2], (*queue_priority_map)[2];
+
+   memset(pdata, 0, sizeof(struct edma_soc_info));
+
+   ret = of_property_read_u32(node, "dma-channels", &value);
+   if (ret < 0)
+   return ret;
+   pdata->n_channel = value;
+
+   ret = of_property_read_u32(node, "ti,edma-regions", &value);
+   if (ret < 0)
+   return ret;
+   pdata->n_region = value;
+
+   ret = of_property_read_u32(node, "ti,edma-slots", &value);
+   if (ret < 0)
+

[PATCH v5 02/14] ARM: edma: remove unused transfer controller handlers

2013-01-15 Thread Matt Porter 
Fix build on OMAP, the irqs are undefined on AM33xx.
These error interrupt handlers were hardcoded as disabled
so since they are unused code, simply remove them.

Signed-off-by: Matt Porter 
---
 arch/arm/common/edma.c |   37 -
 1 file changed, 37 deletions(-)

diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
index be3c04a..2dce245 100644
--- a/arch/arm/common/edma.c
+++ b/arch/arm/common/edma.c
@@ -494,26 +494,6 @@ static irqreturn_t dma_ccerr_handler(int irq, void *data)
return IRQ_HANDLED;
 }
 
-/**
- *
- * Transfer controller error interrupt handlers
- *
- */
-
-#define tc_errs_handledfalse   /* disabled as long as they're NOPs */
-
-static irqreturn_t dma_tc0err_handler(int irq, void *data)
-{
-   dev_dbg(data, "dma_tc0err_handler\n");
-   return IRQ_HANDLED;
-}
-
-static irqreturn_t dma_tc1err_handler(int irq, void *data)
-{
-   dev_dbg(data, "dma_tc1err_handler\n");
-   return IRQ_HANDLED;
-}
-
 static int reserve_contiguous_slots(int ctlr, unsigned int id,
 unsigned int num_slots,
 unsigned int start_slot)
@@ -1538,23 +1518,6 @@ static int edma_probe(struct platform_device *pdev)
arch_num_cc++;
}
 
-   if (tc_errs_handled) {
-   status = request_irq(IRQ_TCERRINT0, dma_tc0err_handler, 0,
-   "edma_tc0", &pdev->dev);
-   if (status < 0) {
-   dev_dbg(&pdev->dev, "request_irq %d failed --> %d\n",
-   IRQ_TCERRINT0, status);
-   return status;
-   }
-   status = request_irq(IRQ_TCERRINT, dma_tc1err_handler, 0,
-   "edma_tc1", &pdev->dev);
-   if (status < 0) {
-   dev_dbg(&pdev->dev, "request_irq %d --> %d\n",
-   IRQ_TCERRINT, status);
-   return status;
-   }
-   }
-
return 0;
 
 fail:
-- 
1.7.9.5

___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

Re: [PATCH] davinci_nand: fix compilation with CONFIG_OF=y

2013-01-15 Thread Artem Bityutskiy 
On Wed, 2013-01-02 at 23:22 +0300, Sergei Shtylyov wrote:
> Commit cdeadd712f52b16a9285386d61ee26fd14eb4085 (mtd: nand: davinci: add OF
> support for davinci nand controller) obviously has never been really build
> tested with CONFIG_OF=y.  Now it prevents DaVinci family kernels from 
> building:
> all due to stupidly missing semicolon after a structure initializer...
> 
> Signed-off-by: Sergei Shtylyov 
> Cc: sta...@vger.kernel.org # 3.7

This patch is currently sitting in the mtd tree, and I believe will be
merged to 3.8.

-- 
Best Regards,
Artem Bityutskiy


signature.asc
Description: This is a digitally signed message part
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

Re: [PATCH v5 6/9] ARM: davinci: Remoteproc driver support for OMAP-L138 DSP

2013-01-15 Thread Ohad Ben-Cohen 
On Tue, Jan 15, 2013 at 2:29 PM, Sekhar Nori  wrote:
> May be rproc_alloc() could auto-assign the firmware name to something
> like 'rproc%d-fw' if firmware name passed to it is NULL?

I prefer we use name-based filenames instead to make it easier for
users (and us developers).

We can probably do something like "rproc-%s-fw" with pdata->name
assuming we/you do maintain a meaningful name in the latter.

Thanks,
Ohad.
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

Re: [PATCH v5 6/9] ARM: davinci: Remoteproc driver support for OMAP-L138 DSP

2013-01-15 Thread Sekhar Nori 
On 1/15/2013 3:33 PM, Ohad Ben-Cohen wrote:
> On Tue, Jan 15, 2013 at 11:15 AM, Sekhar Nori  wrote:
>> Right, and platform data is not the way to achieve this.
> 
> How do you suggest to handle platforms with multiple different remote
> processors (driven by the same driver) ?
> 
> Requiring the user to indicate the fw name for each processor is
> somewhat error prone/cumbersome.

May be rproc_alloc() could auto-assign the firmware name to something
like 'rproc%d-fw' if firmware name passed to it is NULL?

Thanks,
Sekhar
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

Re: [PATCH V2 3/3] ARM: davinci: da850: add NAND driver entries

2013-01-15 Thread Sekhar Nori 
On 1/15/2013 4:06 PM, Kumar, Anil wrote:
> On Thu, Jan 10, 2013 at 17:49:13, Nori, Sekhar wrote:
>> On 1/10/2013 1:07 PM, Kumar, Anil wrote:
>>> On Wed, Jan 09, 2013 at 18:17:46, Nori, Sekhar wrote:
>>
>>> I do not think that it is good idea to move NAND pin mux information
>>> into da850.dtsi because this information is evm specific.
>>> if we will use this approach then we must use the same approach for
>>> other modules also as ASoC etc.   
>>
>> Why do you consider this EVM specific. IOW, which pins do you see
>> changing on another board? BTW, if there are additional pins needed than
>> what are listed, we can always add more pinux entries in the .dts files.
>> The pins present in dtsi file should the base case.
>  
> Ok, we can use this approach for DaVinci as its SoC modules do not
> have multiple pin configuration option. I will do the changes in 
> next patch series.

You could do this even if this was the case by defining multiple pin groups.

Thanks,
Sekhar
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

RE: [PATCH V2 3/3] ARM: davinci: da850: add NAND driver entries

2013-01-15 Thread Kumar, Anil 
On Thu, Jan 10, 2013 at 17:49:13, Nori, Sekhar wrote:
> On 1/10/2013 1:07 PM, Kumar, Anil wrote:
> > On Wed, Jan 09, 2013 at 18:17:46, Nori, Sekhar wrote:
> 
> > I do not think that it is good idea to move NAND pin mux information
> > into da850.dtsi because this information is evm specific.
> > if we will use this approach then we must use the same approach for
> > other modules also as ASoC etc.   
> 
> Why do you consider this EVM specific. IOW, which pins do you see
> changing on another board? BTW, if there are additional pins needed than
> what are listed, we can always add more pinux entries in the .dts files.
> The pins present in dtsi file should the base case.
 
Ok, we can use this approach for DaVinci as its SoC modules do not
have multiple pin configuration option. I will do the changes in 
next patch series.

Thanks,
Anil
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

Re: [PATCH v5 6/9] ARM: davinci: Remoteproc driver support for OMAP-L138 DSP

2013-01-15 Thread Ohad Ben-Cohen 
On Tue, Jan 15, 2013 at 11:15 AM, Sekhar Nori  wrote:
> Right, and platform data is not the way to achieve this.

How do you suggest to handle platforms with multiple different remote
processors (driven by the same driver) ?

Requiring the user to indicate the fw name for each processor is
somewhat error prone/cumbersome.

Thanks,
Ohad.
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

Re: [PATCH v5 6/9] ARM: davinci: Remoteproc driver support for OMAP-L138 DSP

2013-01-15 Thread Ohad Ben-Cohen 
Hi Rob,

On Sat, Jan 12, 2013 at 4:26 AM, Tivy, Robert  wrote:
> Is FW_CONFIG above supposed to be FW_LOADER?

That FW_CONFIG is completely bogus of course. care to fix it in your series?

> We're currently handling the CHIPINT lines as "level"s, since they're 
> completely controlled by SW.  The interruptor raises the line and the 
> interruptee lowers (clears) it.  In a situation where every interrupt is 
> considered to be a signal of new data arrival we need to make sure that the 
> other side has "seen" the previous interrupt before we raise another one.

What if we don't ? Can the DSP side just go over the vrings until no
new msg is left (similar to what you do on the Linux side) ?

> Is this suggesting that there be separate platform device instances for each 
> different potential fw, and that each platform device instance hardcodes the 
> fw filename?

In principle this same driver can drive many instances of remote
processors you may have on your board. E.g. in OMAP the same driver
controls both the M3s and the DSP. pdata is then used to hold
information specific to the hw instance.

I'm not sure if there's (or will be) any DaVinci platform with several
remote processors but it's a better practice to write the code as if
there is/will be - it's usually cleaner and will just work in case a
platform with multiple rprocs does show up one day.

> Sekhar asked that there not be a default fw name, so there's conflicting 
> feedback on this point.  I prefer to have a default name plus the module 
> parameter override (but don't have much opinion on whether it should be 
> davinci-specific (and passed with davinci_remoteproc.ko) or general (and 
> passed with remoteproc.ko), please advise).
>
> Since the fw file (i.e., DSP program) is typically paired with a particular 
> Linux app, I like the ability to specify the fw filename at runtime, 
> depending on the Linux app I need to run.

Sure, no reason why not to allow users to override the default fw name.

Thanks,
Ohad.
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

[GIT PULL FOR v3.9] Davinci media trivial fixes

2013-01-15 Thread Prabhakar Lad 
Hi Mauro,

Please pull the following patches for DaVinci media, fixing trivial issues.

Regards,
--Prabhakar Lad

The following changes since commit 3151d14aa6e983aa36d51a80d0477859f9ba12af:

  [media] media: remove __dev* annotations (2013-01-11 13:03:24 -0200)

are available in the git repository at:
  git://linuxtv.org/mhadli/v4l-dvb-davinci_devices.git for_mauro

Lad, Prabhakar (2):
  davinci: dm355: Fix uninitialized variable compiler warnings
  davinci: dm644x: fix enum ccdc_gama_width and enum
ccdc_data_size comparision warning

Wei Yongjun (1):
  davinci: vpbe: fix missing unlock on error in vpbe_initialize()

 drivers/media/platform/davinci/dm355_ccdc.c  |2 +-
 drivers/media/platform/davinci/dm644x_ccdc.c |5 -
 drivers/media/platform/davinci/vpbe.c|6 --
 3 files changed, 9 insertions(+), 4 deletions(-)
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

Re: [PATCH v5 6/9] ARM: davinci: Remoteproc driver support for OMAP-L138 DSP

2013-01-15 Thread Sekhar Nori 
On 1/12/2013 7:56 AM, Tivy, Robert wrote:

>> From: Ohad Ben-Cohen [mailto:o...@wizery.com]
>> Sent: Friday, January 11, 2013 4:26 AM

>> On Fri, Jan 11, 2013 at 2:23 AM, Robert Tivy  wrote:
>>> +static int davinci_rproc_probe(struct platform_device *pdev)
>>> +{
>>> +   struct da8xx_rproc_pdata *pdata = pdev->dev.platform_data;
>>> +   struct davinci_rproc *drproc;
>>> +   struct rproc *rproc;
>>> +   struct clk *dsp_clk;
>>> +   int ret;
>>> +
>>> +   if (!fw_name) {
>>> +   dev_err(&pdev->dev, "No firmware file specified\n");
>>> +
>>> +   return -EINVAL;
>>> +   }

>> There are a few issues with this fw_name module param:
>>
>> 1. Usually we don't rely on users providing the firmware file name for
>> drivers to work. Drivers should know the name beforehand, and if there
>> may be several different instances of firmwares (for different cores
>> you may have), then it's just better to get it from the platform data.
> 
> Is this suggesting that there be separate platform device instances for each 
> different potential fw, and that each platform device instance hardcodes the 
> fw filename?

I am not convinced firmware name should be in platform data (or DT)
since it is not hardware specific. User can choose multiple different
firmwares to load on the DSP depending the application he is running all
for the same platform (da850 evm).

> 
>>
>> 2. You may still want to have such a module param in order to be able
>> to override the default firmware name (for debugging purposes?), but
>> I'm not sure it should be davinci-specific. if we do want it to be
>> then please prefix the name with 'davinci'.
> 
> Sekhar asked that there not be a default fw name, so there's conflicting 
> feedback on this point.  I prefer to have a default name plus the module 
> parameter override (but don't have much opinion on whether it should be 
> davinci-specific (and passed with davinci_remoteproc.ko) or general (and 
> passed with remoteproc.ko), please advise).

Rob, I don't remember objecting to a default firmware name if module
parameter is not passed. On 29th November 2012 you wrote:

"
Sounds OK.  I propose then to have the above be the default firmware
name, along with a module parameter that will override if specified.
"

and I wrote back:

"
Sounds good.
"

As you can see, there was no objection from me.

> 
> Since the fw file (i.e., DSP program) is typically paired with a particular 
> Linux app, I like the ability to specify the fw filename at runtime, 
> depending on the Linux app I need to run.

Right, and platform data is not the way to achieve this.

Thanks,
Sekhar
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

[GIT PULL FOR v3.9] media i2c devices trivial fixes

2013-01-15 Thread Prabhakar Lad 
Hi Mauro,

Please pull the following patches, which use devm_kzalloc() instead of
kzalloc().

Regards,
--Prabhakar Lad

The following changes since commit 3151d14aa6e983aa36d51a80d0477859f9ba12af:

  [media] media: remove __dev* annotations (2013-01-11 13:03:24 -0200)

are available in the git repository at:
  git://linuxtv.org/mhadli/v4l-dvb-davinci_devices.git media-i2c-fixes

Lad, Prabhakar (4):
  ths7303: use devm_kzalloc() instead of kzalloc()
  tvp7002: use devm_kzalloc() instead of kzalloc()
  tvp514x: use devm_kzalloc() instead of kzalloc()
  adv7343: use devm_kzalloc() instead of kzalloc()

 drivers/media/i2c/adv7343.c |9 +++--
 drivers/media/i2c/ths7303.c |3 +--
 drivers/media/i2c/tvp514x.c |4 +---
 drivers/media/i2c/tvp7002.c |   18 ++
 4 files changed, 11 insertions(+), 23 deletions(-)
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

[PATCH] ARM: davinci: da850 evm: pass platform data for adv7343 encoder

2013-01-15 Thread Lad, Prabhakar 
Without this patch the adv7343 encoder was being set to default
configuration which caused display not to work on this board.
This patch passes the necessary platform data required for adv7343
encoder to work on da850 evm.

Signed-off-by: Lad, Prabhakar 
---
 This patch is dependent on http://patchwork.linuxtv.org/patch/16272/

 arch/arm/mach-davinci/board-da850-evm.c |   13 +
 1 files changed, 13 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-davinci/board-da850-evm.c 
b/arch/arm/mach-davinci/board-da850-evm.c
index 0299915..d0e3ec3 100644
--- a/arch/arm/mach-davinci/board-da850-evm.c
+++ b/arch/arm/mach-davinci/board-da850-evm.c
@@ -1256,11 +1256,24 @@ static struct vpif_capture_config 
da850_vpif_capture_config = {
 };
 
 /* VPIF display configuration */
+
+static struct adv7343_platform_data adv7343_pdata = {
+   .mode_config = {
+   .dac_3 = 1,
+   .dac_2 = 1,
+   .dac_1 = 1,
+   },
+   .sd_config = {
+   .sd_dac_out1 = 1,
+   },
+};
+
 static struct vpif_subdev_info da850_vpif_subdev[] = {
{
.name = "adv7343",
.board_info = {
I2C_BOARD_INFO("adv7343", 0x2a),
+   .platform_data = &adv7343_pdata,
},
},
 };
-- 
1.7.4.1

___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source