RE: [RFC PATCH 01/13] ARM: davinci: move private EDMA API to arm/common

2012-09-21 Thread Hebbar, Gururaja 
On Thu, Sep 20, 2012 at 20:13:34, Porter, Matt wrote:
> Move mach-davinci/dma.c to common/edma.c so it can be used
> by OMAP (specifically AM33xx atm) as well. This just moves
> the private EDMA API but does not support OMAP.
> 
> Signed-off-by: Matt Porter 
> ---
>  arch/arm/Kconfig   |1 +
>  arch/arm/common/Kconfig|3 +
>  arch/arm/common/Makefile   |1 +
>  arch/arm/common/edma.c | 1588 
> 
>  arch/arm/include/asm/mach/edma.h   |  267 +
>  arch/arm/mach-davinci/Makefile |2 +-
>  arch/arm/mach-davinci/devices.c|3 +-
>  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/dma.c| 1588 
> 


Please use –M option, while generating patches via git-format-patch. 
This reduces the patch size if files are copied/renamed/moved.

>  arch/arm/mach-davinci/include/mach/asp.h   |2 +-
>  arch/arm/mach-davinci/include/mach/da8xx.h |3 +-
>  arch/arm/mach-davinci/include/mach/edma.h  |  267 -
>  arch/arm/mach-davinci/include/mach/spi.h   |2 +-
>  arch/arm/plat-omap/Kconfig |1 +
>  17 files changed, 1872 insertions(+), 1864 deletions(-)
>  create mode 100644 arch/arm/common/edma.c
>  create mode 100644 arch/arm/include/asm/mach/edma.h
>  delete mode 100644 arch/arm/mach-davinci/dma.c
>  delete mode 100644 arch/arm/mach-davinci/include/mach/edma.h
> 

...snip...
...snip...
...snip...

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


Regards, 
Gururaja

--
Got visibility?
Most devs has no idea what their production app looks like.
Find out how fast your code is with AppDynamics Lite.
http://ad.doubleclick.net/clk;262219671;13503038;y?
http://info.appdynamics.com/FreeJavaPerformanceDownload.html
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

[PATCH] spi: sh-hspi: fix return value check in hspi_probe()

2012-09-21 Thread Wei Yongjun 
From: Wei Yongjun 

In case of error, the function clk_get() returns ERR_PTR()
and never returns NULL pointer. The NULL test in the error
handling should be replaced with IS_ERR().

dpatch engine is used to auto generated this patch.
(https://github.com/weiyj/dpatch)

Signed-off-by: Wei Yongjun 
---
 drivers/spi/spi-sh-hspi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/spi/spi-sh-hspi.c b/drivers/spi/spi-sh-hspi.c
index 934138c..ecb99f3 100644
--- a/drivers/spi/spi-sh-hspi.c
+++ b/drivers/spi/spi-sh-hspi.c
@@ -251,7 +251,7 @@ static int __devinit hspi_probe(struct platform_device 
*pdev)
}
 
clk = clk_get(NULL, "shyway_clk");
-   if (!clk) {
+   if (IS_ERR(clk)) {
dev_err(&pdev->dev, "shyway_clk is required\n");
ret = -EINVAL;
goto error0;



--
Got visibility?
Most devs has no idea what their production app looks like.
Find out how fast your code is with AppDynamics Lite.
http://ad.doubleclick.net/clk;262219671;13503038;y?
http://info.appdynamics.com/FreeJavaPerformanceDownload.html
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

Re: [PATCH] spi/imx: set the inactive state of the clock according to the clock polarity

2012-09-21 Thread Dirk Behme 
On 31.08.2012 04:35, Shawn Guo wrote:
> Copy Uwe ...

Ping ;)

Any opinions on this?

Thanks

Dirk

> On Fri, Aug 31, 2012 at 10:55:11AM +0200, Dirk Behme wrote:
>> From: Knut Wohlrab 
>>
>> There are SPI devices which need a SPI clock with active low polarity and
>> high inactive state.
>>
>> Add the setting of the inactive state ECSPIx_CONFIGREG:SCLK CTL
>> according to the clock polarity ECSPIx_CONFIGREG:SCLK POL:
>>
>> DT without "spi-cpol" = 0 = clock active high polarity = inactive state low
>> DT with"spi-cpol" = 1 = clock active low  polarity = inactive state high
>>
>> Signed-off-by: Knut Wohlrab 
>> ---
>>
>> Question: Are there real world examples for a need of an individual setting 
>> of
>> clock polarity/inactive state?
> 
> I'm less concerned about that.  We can always patch the driver when
> the real world example occurs?
> 
> Regards,
> Shawn
> 
>>  drivers/spi/spi-imx.c |6 --
>>  1 files changed, 4 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/spi/spi-imx.c b/drivers/spi/spi-imx.c
>> index e834ff8..d64655b 100644
>> --- a/drivers/spi/spi-imx.c
>> +++ b/drivers/spi/spi-imx.c
>> @@ -197,6 +197,7 @@ static unsigned int spi_imx_clkdiv_2(unsigned int fin,
>>  #define MX51_ECSPI_CONFIG_SCLKPOL(cs)   (1 << ((cs) +  4))
>>  #define MX51_ECSPI_CONFIG_SBBCTRL(cs)   (1 << ((cs) +  8))
>>  #define MX51_ECSPI_CONFIG_SSBPOL(cs)(1 << ((cs) + 12))
>> +#define MX51_ECSPI_CONFIG_SCLKCTL(cs)   (1 << ((cs) + 20))
>>  
>>  #define MX51_ECSPI_INT  0x10
>>  #define MX51_ECSPI_INT_TEEN (1 <<  0)
>> @@ -287,9 +288,10 @@ static int __maybe_unused mx51_ecspi_config(struct 
>> spi_imx_data *spi_imx,
>>  if (config->mode & SPI_CPHA)
>>  cfg |= MX51_ECSPI_CONFIG_SCLKPHA(config->cs);
>>  
>> -if (config->mode & SPI_CPOL)
>> +if (config->mode & SPI_CPOL) {
>>  cfg |= MX51_ECSPI_CONFIG_SCLKPOL(config->cs);
>> -
>> +cfg |= MX51_ECSPI_CONFIG_SCLKCTL(config->cs);
>> +}
>>  if (config->mode & SPI_CS_HIGH)
>>  cfg |= MX51_ECSPI_CONFIG_SSBPOL(config->cs);
>>  
>> -- 
>> 1.7.0.4

--
Got visibility?
Most devs has no idea what their production app looks like.
Find out how fast your code is with AppDynamics Lite.
http://ad.doubleclick.net/clk;262219671;13503038;y?
http://info.appdynamics.com/FreeJavaPerformanceDownload.html
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

Re: [PATCH] spi/imx: set the inactive state of the clock according to the clock polarity

2012-09-21 Thread Uwe Kleine-König 
On Fri, Sep 21, 2012 at 09:36:51AM +0200, Dirk Behme wrote:
> On 31.08.2012 04:35, Shawn Guo wrote:
> >Copy Uwe ...
Copy our kernel mailing list ...

> Ping ;)
> 
> Any opinions on this?
Assuming it fixes access to a device I'm ok with your patch, but I don't
really feel responsible for the driver (i.e. me not acking shouldn't
have a negative influence on getting the patch in).

> >On Fri, Aug 31, 2012 at 10:55:11AM +0200, Dirk Behme wrote:
> >>From: Knut Wohlrab 
> >>
> >>There are SPI devices which need a SPI clock with active low polarity and
> >>high inactive state.
> >>
> >>Add the setting of the inactive state ECSPIx_CONFIGREG:SCLK CTL
> >>according to the clock polarity ECSPIx_CONFIGREG:SCLK POL:
> >>
> >>DT without "spi-cpol" = 0 = clock active high polarity = inactive state low
> >>DT with"spi-cpol" = 1 = clock active low  polarity = inactive state high
> >>
> >>Signed-off-by: Knut Wohlrab 
If you forward a patch you must add your S-o-b.

> >>---
> >>
> >>Question: Are there real world examples for a need of an individual setting 
> >>of
> >>clock polarity/inactive state?
> >
> >I'm less concerned about that.  We can always patch the driver when
> >the real world example occurs?
yes.

Thanks
Uwe

> >> drivers/spi/spi-imx.c |6 --
> >> 1 files changed, 4 insertions(+), 2 deletions(-)
> >>
> >>diff --git a/drivers/spi/spi-imx.c b/drivers/spi/spi-imx.c
> >>index e834ff8..d64655b 100644
> >>--- a/drivers/spi/spi-imx.c
> >>+++ b/drivers/spi/spi-imx.c
> >>@@ -197,6 +197,7 @@ static unsigned int spi_imx_clkdiv_2(unsigned int fin,
> >> #define MX51_ECSPI_CONFIG_SCLKPOL(cs)  (1 << ((cs) +  4))
> >> #define MX51_ECSPI_CONFIG_SBBCTRL(cs)  (1 << ((cs) +  8))
> >> #define MX51_ECSPI_CONFIG_SSBPOL(cs)   (1 << ((cs) + 12))
> >>+#define MX51_ECSPI_CONFIG_SCLKCTL(cs)  (1 << ((cs) + 20))
> >> #define MX51_ECSPI_INT 0x10
> >> #define MX51_ECSPI_INT_TEEN(1 <<  0)
> >>@@ -287,9 +288,10 @@ static int __maybe_unused mx51_ecspi_config(struct 
> >>spi_imx_data *spi_imx,
> >>if (config->mode & SPI_CPHA)
> >>cfg |= MX51_ECSPI_CONFIG_SCLKPHA(config->cs);
> >>-   if (config->mode & SPI_CPOL)
> >>+   if (config->mode & SPI_CPOL) {
> >>cfg |= MX51_ECSPI_CONFIG_SCLKPOL(config->cs);
> >>-
> >>+   cfg |= MX51_ECSPI_CONFIG_SCLKCTL(config->cs);
> >>+   }
> >>if (config->mode & SPI_CS_HIGH)
> >>cfg |= MX51_ECSPI_CONFIG_SSBPOL(config->cs);
> >>-- 
> >>1.7.0.4
> 
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 

-- 
Pengutronix e.K.   | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/  |

--
Got visibility?
Most devs has no idea what their production app looks like.
Find out how fast your code is with AppDynamics Lite.
http://ad.doubleclick.net/clk;262219671;13503038;y?
http://info.appdynamics.com/FreeJavaPerformanceDownload.html
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

RE: [RFC PATCH 00/13] DMA Engine support for AM33xx

2012-09-21 Thread Hebbar, Gururaja 
On Thu, Sep 20, 2012 at 20:13:33, Porter, Matt wrote:
> 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.
> 
> There are a mind-boggling number of dependencies for this series:
> 
>   - Jon Hunter's OF DMA helpers series
> https://patchwork.kernel.org/patch/1461061/
> https://patchwork.kernel.org/patch/1461051/
>   - Patch to address OF DMA helpers naming issues:
> https://patchwork.kernel.org/patch/1477921/
>   - EDMA DMA Engine wrapper driver in linux-next
> c2dde5f8f2095d7c623ff3565c1462e190272273
>   - EDMA DMA Engine wrapper driver bug fix:
> https://patchwork.kernel.org/patch/1474411/  
>   - A huge number of patches in linux-next for AM33xx boot
> (too numerous to list)
> 
> 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.
> 
> What works? Well, with this series we now have MMC and SPI support
> on AM33xx. The only caveat for MMC is that the mmc3 controller has
> its events on the crossbar and is not usable right now.
> 
> This is tested on BeagleBone with a SPI framebuffer driver and SD
> card.
> 
> After this series, the plan is to convert the last in-tree user
> of the private EDMA API (davinci-pcm/mcasp) and then eliminate
> the private EDMA API by folding its functionality into
> drivers/dma/edma.c.
> 
> TODO:
>   add AM33xx crossbar support to the private EDMA API
>   (any EDMA events on the crossbar are not supported)
> 


Can you please mention the base repo you have taken as starting point.
(repo + extra patches ...).

This will help us to test the code.

This is because I looked at the patch 12/13 and I see that mmc
device-node is modified. But in mainline I don’t see device 
node for mmc (yet).

> Matt Porter (13):
>   ARM: davinci: move private EDMA API to arm/common
>   ARM: edma: remove unused transfer controller handlers
>   ARM: edma: add DT and runtime PM support for AM335x
>   dmaengine: edma: enable build for AM335x
>   dma: Add TI EDMA device tree binding
>   ARM: omap: add hsmmc am33xx specific init
>   mmc: omap_hsmmc: dma_request_slave_channel() support for DT platforms
>   mmc: omap_hsmmc: limit max_segs with the EDMA DMAC
>   mmc: omap_hsmmc: add generic DMA request support to the DT binding
>   spi: omap2-mcspi: dma_request_slave_channel() support for DT
> platforms
>   spi: omap2-mcspi: add generic DMA request support to the DT binding
>   ARM: dts: add am33xx EDMA support
>   Documentation: add schedule for removing private EDMA API
> 
>  Documentation/devicetree/bindings/dma/ti-edma.txt  |   49 +
>  .../devicetree/bindings/mmc/ti-omap-hsmmc.txt  |   25 +-
>  Documentation/devicetree/bindings/spi/omap-spi.txt |   27 +-
>  Documentation/feature-removal-schedule.txt |   10 +
>  arch/arm/Kconfig   |1 +
>  arch/arm/boot/dts/am33xx.dtsi  |   46 +
>  arch/arm/common/Kconfig|3 +
>  arch/arm/common/Makefile   |1 +
>  arch/arm/common/edma.c | 1779 
> 
>  arch/arm/include/asm/mach/edma.h   |  267 +++
>  arch/arm/mach-davinci/Makefile |2 +-
>  arch/arm/mach-davinci/devices.c|3 +-
>  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/dma.c| 1588 -
>  arch/arm/mach-davinci/include/mach/asp.h   |2 +-
>  arch/arm/mach-davinci/include/mach/da8xx.h |3 +-
>  arch/arm/mach-davinci/include/mach/edma.h  |  267 ---
>  arch/arm/mach-davinci/include/mach/spi.h   |2 +-
>  arch/arm/mach-omap2/hsmmc.c|7 +-
>  arch/arm/plat-omap/Kconfig |1 +
>  drivers/dma/Kconfig|2 +-
>  drivers/dma/edma.c |2 +-
>  drivers/mmc/host/omap_hsmmc.c  |   26 +-
>  drivers/spi/spi-omap2-mcspi.c  |   68 +-
>  27 files changed, 2296 insertions(+), 18

RE: [RFC PATCH 05/13] dma: Add TI EDMA device tree binding

2012-09-21 Thread Hebbar, Gururaja 
On Thu, Sep 20, 2012 at 20:13:38, Porter, Matt wrote:
> 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..06402eb
> --- /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
> +
> +Example:
> +
> +edma: edma@4900 {
> + #address-cells = <1>;
> + #size-cells = <0>;

address-cells & size-cells are only required when current node is a parent 
node & it has sibling/child nodes (that too if the child node uses "reg" 
property).


> + 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>;
> +};
> +
> -- 
> 1.7.9.5
> 
> ___
> Davinci-linux-open-source mailing list
> davinci-linux-open-sou...@linux.davincidsp.com
> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
> 


Regards, 
Gururaja

--
Got visibility?
Most devs has no idea what their production app looks like.
Find out how fast your code is with AppDynamics Lite.
http://ad.doubleclick.net/clk;262219671;13503038;y?
http://info.appdynamics.com/FreeJavaPerformanceDownload.html
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

RE: [RFC PATCH 03/13] ARM: edma: add DT and runtime PM support for AM335x

2012-09-21 Thread Hebbar, Gururaja 
On Thu, Sep 20, 2012 at 20:13:36, Porter, Matt wrote:
> Adds support for parsing the TI EDMA DT data into the required
> EDMA private API platform data.
> 
> Calls runtime PM API only in the DT case in order to unidle the
> associated hwmods on AM335x.
> 
> Signed-off-by: Matt Porter 
> ---
>  arch/arm/common/edma.c   |  252 
> --
>  arch/arm/include/asm/mach/edma.h |8 +-
>  2 files changed, 244 insertions(+), 16 deletions(-)

The binding documentation should be updated along with the driver
change that does introduce the binding. You could just merged patch #4
and #5.

> 
> diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
> index 001d268..f337f81 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 
>  
> @@ -1366,30 +1373,236 @@ 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_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;
> + s16 (*rsv_chans)[2], (*rsv_slots)[2];
> + s8 (*queue_tc_map)[2], (*queue_priority_map)[2];
> +
> + 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)
> + return ret;
> + pdata->n_slot = value;
> +
> + pdata->n_cc = 1;
> + /* This is unused */
> + pdata->n_tc = 3;
> +
> + rsv_info =
> + devm_kzalloc(dev, sizeof(struct edma_rsv_info), GFP_KERNEL);
> + if (!rsv_info)
> + return -ENOMEM;
> + pdata->rsv = rsv_info;
> +
> + /* Build the reserved channel/slots arrays */
> + prop = of_find_property(node, "ti,edma-reserved-channels", &sz);
> + if (!prop)
> + return -EINVAL;
> +
> + rsv_chans =
> + devm_kzalloc(dev, sz/sizeof(s16) + 2*sizeof(s16), GFP_KERNEL);
> + if (!rsv_chans)
> + return -ENOMEM;
> + pdata->rsv->rsv_chans = rsv_chans;
> +
> + ret = edma_of_read_u32_to_s16_array(node, "ti,edma-reserved-channels",
> + (s16 *)rsv_chans, sz/sizeof(u32));
> + if (ret < 0)
> + return ret;
> +
> + prop = of_find_property(node, "ti,edma-reserved-slots", &sz);
> + if (!prop)
> + return -EINVAL;
> +

Binding Documentation mentions edma-reserved-[channels/slots] as optional. 
But here the code returns as error if they are not found. Kindly reconfirm

>From patch-set 5/13

+Optional properties:
+- ti,edma-reserved-channels: List of reserved channel regions
+- ti,edma-reserved-slots: List of reserved slot regions

> + rsv_slots = devm_kzalloc(dev,
> +  sz/sizeof(s16) + 2*sizeof(s16),
> +  GFP_KERNEL);
> + if (!rsv_slots)
> + return -

Re: [RFC PATCH 01/13] ARM: davinci: move private EDMA API to arm/common

2012-09-21 Thread Russell King - ARM Linux 
On Thu, Sep 20, 2012 at 10:43:34AM -0400, Matt Porter wrote:
> Move mach-davinci/dma.c to common/edma.c so it can be used
> by OMAP (specifically AM33xx atm) as well. This just moves
> the private EDMA API but does not support OMAP.
> 
> Signed-off-by: Matt Porter 
> ---
>  arch/arm/Kconfig   |1 +
>  arch/arm/common/Kconfig|3 +
>  arch/arm/common/Makefile   |1 +
>  arch/arm/common/edma.c | 1588 
> 
>  arch/arm/include/asm/mach/edma.h   |  267 +

asm/mach should not be used as a dumping ground for platform header files.
It is there to provide the interfaces between generic ARM architecture
code and platform code.  (At least four files that are there at the
moment need to be moved out of there - patch series to follow...)

--
Got visibility?
Most devs has no idea what their production app looks like.
Find out how fast your code is with AppDynamics Lite.
http://ad.doubleclick.net/clk;262219671;13503038;y?
http://info.appdynamics.com/FreeJavaPerformanceDownload.html
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

RE: [RFC PATCH 01/13] ARM: davinci: move private EDMA API to arm/common

2012-09-21 Thread Hebbar, Gururaja 
On Fri, Sep 21, 2012 at 14:59:23, Russell King - ARM Linux wrote:
> On Thu, Sep 20, 2012 at 10:43:34AM -0400, Matt Porter wrote:
> > Move mach-davinci/dma.c to common/edma.c so it can be used
> > by OMAP (specifically AM33xx atm) as well. This just moves
> > the private EDMA API but does not support OMAP.
> > 
> > Signed-off-by: Matt Porter 
> > ---
> >  arch/arm/Kconfig   |1 +
> >  arch/arm/common/Kconfig|3 +
> >  arch/arm/common/Makefile   |1 +
> >  arch/arm/common/edma.c | 1588 
> > 
> >  arch/arm/include/asm/mach/edma.h   |  267 +
> 
> asm/mach should not be used as a dumping ground for platform header files.
> It is there to provide the interfaces between generic ARM architecture
> code and platform code.  (At least four files that are there at the
> moment need to be moved out of there - patch series to follow...)

Can this be moved to include/linux/platform_data/ ?

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


Regards, 
Gururaja

--
Got visibility?
Most devs has no idea what their production app looks like.
Find out how fast your code is with AppDynamics Lite.
http://ad.doubleclick.net/clk;262219671;13503038;y?
http://info.appdynamics.com/FreeJavaPerformanceDownload.html
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

Re: [RFC PATCH 01/13] ARM: davinci: move private EDMA API to arm/common

2012-09-21 Thread Russell King - ARM Linux 
On Fri, Sep 21, 2012 at 09:33:42AM +, Hebbar, Gururaja wrote:
> On Fri, Sep 21, 2012 at 14:59:23, Russell King - ARM Linux wrote:
> > On Thu, Sep 20, 2012 at 10:43:34AM -0400, Matt Porter wrote:
> > > Move mach-davinci/dma.c to common/edma.c so it can be used
> > > by OMAP (specifically AM33xx atm) as well. This just moves
> > > the private EDMA API but does not support OMAP.
> > > 
> > > Signed-off-by: Matt Porter 
> > > ---
> > >  arch/arm/Kconfig   |1 +
> > >  arch/arm/common/Kconfig|3 +
> > >  arch/arm/common/Makefile   |1 +
> > >  arch/arm/common/edma.c | 1588 
> > > 
> > >  arch/arm/include/asm/mach/edma.h   |  267 +
> > 
> > asm/mach should not be used as a dumping ground for platform header files.
> > It is there to provide the interfaces between generic ARM architecture
> > code and platform code.  (At least four files that are there at the
> > moment need to be moved out of there - patch series to follow...)
> 
> Can this be moved to include/linux/platform_data/ ?

Here's the pertinant question: "is it platform data?"  Looking at the
file, it appears to be internal data structures and register definitions
for the driver itself.  Therefore, it isn't platform data, and it
shouldn't be living separately from the driver.

If the driver itself only makes use of the data structures, the data
structures should be defined either within the driver, or a header file
co-located next to the driver itself.  The same goes for register
definitions too.

The only structure that I can find which isn't internal to the driver
is struct edma_soc_info, struct edma_rsv_info, and the enum dma_event_q.
Those can go to include/linux/platform_data, but the rest should not.

--
Got visibility?
Most devs has no idea what their production app looks like.
Find out how fast your code is with AppDynamics Lite.
http://ad.doubleclick.net/clk;262219671;13503038;y?
http://info.appdynamics.com/FreeJavaPerformanceDownload.html
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

Re: [RFC PATCH 10/13] spi: omap2-mcspi: dma_request_slave_channel() support for DT platforms

2012-09-21 Thread Arnd Bergmann 
On Thursday 20 September 2012, Tony Lindgren wrote:
> >  /* use PIO for small transfers, avoiding DMA setup/teardown overhead and
> > @@ -798,14 +801,26 @@ 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);
> > + if (spi->dev.of_node)
> > + mcspi_dma->dma_rx =
> > + dma_request_slave_channel(&master->dev,
> > +   mcspi_dma->dma_rx_ch_name);
> > + else
> > + mcspi_dma->dma_rx =
> > + dma_request_channel(mask, omap_dma_filter_fn, &sig);
> >   if (!mcspi_dma->dma_rx) {
> >   dev_err(&spi->dev, "no RX DMA engine channel for McSPI\n");
> >   return -EAGAIN;
> >   }
> >  
> 
> Hmm this does not look nice.. We should be able to somehow not to care about
> the configuration at the mcspi driver level.

I agree, but as far as I understand Vinod's plans, we would actually move
all drivers over to dma_request_slave_channel() when we have an interface
to register the lookup tables from platform code.

I think the above is ok for a transitional phase and we can remove the
fallback path when we have converted all platforms using this driver
to either use DT or move to the new style way of passing the channel
configuration.

Arnd


--
Got visibility?
Most devs has no idea what their production app looks like.
Find out how fast your code is with AppDynamics Lite.
http://ad.doubleclick.net/clk;262219671;13503038;y?
http://info.appdynamics.com/FreeJavaPerformanceDownload.html
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

[PATCH 2/4] spi: Add SH Mobile series as dependency to MSIOF controller

2012-09-21 Thread Bastian Hecht 
The MSIOF hardware block is used in the SH Mobile series as well, so we
add it here.

Signed-off-by: Bastian Hecht 
---
 drivers/spi/Kconfig |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index cd2fe35..cf77a4b 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -318,10 +318,10 @@ config SPI_S3C64XX
 
 config SPI_SH_MSIOF
tristate "SuperH MSIOF SPI controller"
-   depends on SUPERH && HAVE_CLK
+   depends on (SUPERH || ARCH_SHMOBILE) && HAVE_CLK
select SPI_BITBANG
help
- SPI driver for SuperH MSIOF blocks.
+ SPI driver for SuperH and SH Mobile MSIOF blocks.
 
 config SPI_SH
tristate "SuperH SPI controller"
-- 
1.7.5.4


--
Got visibility?
Most devs has no idea what their production app looks like.
Find out how fast your code is with AppDynamics Lite.
http://ad.doubleclick.net/clk;262219671;13503038;y?
http://info.appdynamics.com/FreeJavaPerformanceDownload.html
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

[PATCH 1/4] spi: sh-msiof: Remove unneeded clock name

2012-09-21 Thread Bastian Hecht 
clk_get() no longer needs a character string for associating the right
clock as this is done via the device struct now.

Signed-off-by: Bastian Hecht 
---
 drivers/spi/spi-sh-msiof.c |6 ++
 1 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/spi/spi-sh-msiof.c b/drivers/spi/spi-sh-msiof.c
index 1f466bc..96358d0 100644
--- a/drivers/spi/spi-sh-msiof.c
+++ b/drivers/spi/spi-sh-msiof.c
@@ -597,7 +597,6 @@ static int sh_msiof_spi_probe(struct platform_device *pdev)
struct resource *r;
struct spi_master *master;
struct sh_msiof_spi_priv *p;
-   char clk_name[16];
int i;
int ret;
 
@@ -614,10 +613,9 @@ static int sh_msiof_spi_probe(struct platform_device *pdev)
p->info = pdev->dev.platform_data;
init_completion(&p->done);
 
-   snprintf(clk_name, sizeof(clk_name), "msiof%d", pdev->id);
-   p->clk = clk_get(&pdev->dev, clk_name);
+   p->clk = clk_get(&pdev->dev, NULL);
if (IS_ERR(p->clk)) {
-   dev_err(&pdev->dev, "cannot get clock \"%s\"\n", clk_name);
+   dev_err(&pdev->dev, "cannot get clock\n");
ret = PTR_ERR(p->clk);
goto err1;
}
-- 
1.7.5.4


--
Got visibility?
Most devs has no idea what their production app looks like.
Find out how fast your code is with AppDynamics Lite.
http://ad.doubleclick.net/clk;262219671;13503038;y?
http://info.appdynamics.com/FreeJavaPerformanceDownload.html
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

[PATCH 3/4] spi: sh-msiof: Add device tree parsing to driver

2012-09-21 Thread Bastian Hecht 
This adds the capability to retrieve setup data from the device tree
node. The usage of platform data is still available.

The type of chip_select has been changed from u16 to int so that
of_property_read_u32 does not overwrite other data.

Signed-off-by: Bastian Hecht 
---
 drivers/spi/spi-sh-msiof.c   |   51 +-
 include/linux/spi/sh_msiof.h |2 +-
 2 files changed, 51 insertions(+), 2 deletions(-)

diff --git a/drivers/spi/spi-sh-msiof.c b/drivers/spi/spi-sh-msiof.c
index 96358d0..467d645 100644
--- a/drivers/spi/spi-sh-msiof.c
+++ b/drivers/spi/spi-sh-msiof.c
@@ -20,6 +20,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -592,6 +593,32 @@ static u32 sh_msiof_spi_txrx_word(struct spi_device *spi, 
unsigned nsecs,
return 0;
 }
 
+#ifdef CONFIG_OF
+static struct sh_msiof_spi_info *sh_msiof_spi_parse_dt(struct device *dev)
+{
+   struct sh_msiof_spi_info *info;
+   struct device_node *np = dev->of_node;
+
+   info = devm_kzalloc(dev, sizeof(struct sh_msiof_spi_info), GFP_KERNEL);
+   if (!info) {
+   dev_err(dev, "failed to allocate setup data\n");
+   return NULL;
+   }
+
+   /* Parse the MSIOF properties */
+   of_property_read_u32(np, "chip-select", &info->num_chipselect);
+   of_property_read_u32(np, "tx_fifo_size", &info->tx_fifo_override);
+   of_property_read_u32(np, "rx_fifo_size", &info->rx_fifo_override);
+
+   return info;
+}
+#else
+static struct sh_msiof_spi_info *sh_msiof_spi_parse_dt(struct device *dev)
+{
+   return NULL;
+}
+#endif
+
 static int sh_msiof_spi_probe(struct platform_device *pdev)
 {
struct resource *r;
@@ -610,7 +637,17 @@ static int sh_msiof_spi_probe(struct platform_device *pdev)
p = spi_master_get_devdata(master);
 
platform_set_drvdata(pdev, p);
-   p->info = pdev->dev.platform_data;
+   if (pdev->dev.of_node)
+   p->info = sh_msiof_spi_parse_dt(&pdev->dev);
+   else
+   p->info = pdev->dev.platform_data;
+
+   if (!p->info) {
+   dev_err(&pdev->dev, "failed to obtain device info\n");
+   ret = -ENXIO;
+   goto err1;
+   }
+
init_completion(&p->done);
 
p->clk = clk_get(&pdev->dev, NULL);
@@ -715,6 +752,17 @@ static int sh_msiof_spi_runtime_nop(struct device *dev)
return 0;
 }
 
+#ifdef CONFIG_OF
+static const struct of_device_id sh_msiof_match[] = {
+   { .compatible = "renesas,sh-msiof", },
+   { .compatible = "renesas,sh-mobile-msiof", },
+   {},
+};
+MODULE_DEVICE_TABLE(of, sh_msiof_match);
+#else
+#define sh_msiof_match NULL
+#endif
+
 static struct dev_pm_ops sh_msiof_spi_dev_pm_ops = {
.runtime_suspend = sh_msiof_spi_runtime_nop,
.runtime_resume = sh_msiof_spi_runtime_nop,
@@ -727,6 +775,7 @@ static struct platform_driver sh_msiof_spi_drv = {
.name   = "spi_sh_msiof",
.owner  = THIS_MODULE,
.pm = &sh_msiof_spi_dev_pm_ops,
+   .of_match_table = sh_msiof_match,
},
 };
 module_platform_driver(sh_msiof_spi_drv);
diff --git a/include/linux/spi/sh_msiof.h b/include/linux/spi/sh_msiof.h
index 2e8db3d..58bc0e1 100644
--- a/include/linux/spi/sh_msiof.h
+++ b/include/linux/spi/sh_msiof.h
@@ -4,7 +4,7 @@
 struct sh_msiof_spi_info {
int tx_fifo_override;
int rx_fifo_override;
-   u16 num_chipselect;
+   int num_chipselect;
 };
 
 #endif /* __SPI_SH_MSIOF_H__ */
-- 
1.7.5.4


--
Got visibility?
Most devs has no idea what their production app looks like.
Find out how fast your code is with AppDynamics Lite.
http://ad.doubleclick.net/clk;262219671;13503038;y?
http://info.appdynamics.com/FreeJavaPerformanceDownload.html
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

[PATCH 4/4] devicetree: Add Renesas SH Mobile MSIOF spi controller binding doc

2012-09-21 Thread Bastian Hecht 
Add binding documentation for Renesas' MSIOF SPI controller.

Signed-off-by: Bastian Hecht 
---
 Documentation/devicetree/bindings/spi/sh-msiof.txt |   12 
 1 files changed, 12 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/spi/sh-msiof.txt

diff --git a/Documentation/devicetree/bindings/spi/sh-msiof.txt 
b/Documentation/devicetree/bindings/spi/sh-msiof.txt
new file mode 100644
index 000..0d60e04
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/sh-msiof.txt
@@ -0,0 +1,12 @@
+Renesas MSIOF spi controller
+
+Required properties:
+- compatible : "renesas,sh-msiof" for SuperH or
+   "renesas,sh-mobile-msiof" for SH Mobile series
+- reg : Offset and length of the register set for the device
+- interrupts : interrupt line used by MSIOF
+
+Optional properties:
+- chip_select  : Chip select, needed if not 0
+- tx_fifo_size : Overrides the default tx fifo size given in words
+- rx_fifo_size : Overrides the default rx fifo size given in words
-- 
1.7.5.4


--
Got visibility?
Most devs has no idea what their production app looks like.
Find out how fast your code is with AppDynamics Lite.
http://ad.doubleclick.net/clk;262219671;13503038;y?
http://info.appdynamics.com/FreeJavaPerformanceDownload.html
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

Re: [RFC PATCH 10/13] spi: omap2-mcspi: dma_request_slave_channel() support for DT platforms

2012-09-21 Thread Tony Lindgren 
* Arnd Bergmann  [120921 02:19]:
> On Thursday 20 September 2012, Tony Lindgren wrote:
> > >  /* use PIO for small transfers, avoiding DMA setup/teardown overhead and
> > > @@ -798,14 +801,26 @@ 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);
> > > + if (spi->dev.of_node)
> > > + mcspi_dma->dma_rx =
> > > + dma_request_slave_channel(&master->dev,
> > > +   
> > > mcspi_dma->dma_rx_ch_name);
> > > + else
> > > + mcspi_dma->dma_rx =
> > > + dma_request_channel(mask, omap_dma_filter_fn, &sig);
> > >   if (!mcspi_dma->dma_rx) {
> > >   dev_err(&spi->dev, "no RX DMA engine channel for McSPI\n");
> > >   return -EAGAIN;
> > >   }
> > >  
> > 
> > Hmm this does not look nice.. We should be able to somehow not to care about
> > the configuration at the mcspi driver level.
> 
> I agree, but as far as I understand Vinod's plans, we would actually move
> all drivers over to dma_request_slave_channel() when we have an interface
> to register the lookup tables from platform code.
> 
> I think the above is ok for a transitional phase and we can remove the
> fallback path when we have converted all platforms using this driver
> to either use DT or move to the new style way of passing the channel
> configuration.

Can't we come up with a version of dma_request_slave_channel that works
both ways for now:

mcspi_dma->dma_rx =
dma_request_slave_channel_compat(mask, omap_dma_filter_fn, &sig,
&master->dev, 
mcspi_dma->dma_rx_ch_name);
... 

Then it's just question of patching away two lines later on rather than
having to add all this if else to all the drivers first, then patching
it away again.

Regards,

Tony

--
Got visibility?
Most devs has no idea what their production app looks like.
Find out how fast your code is with AppDynamics Lite.
http://ad.doubleclick.net/clk;262219671;13503038;y?
http://info.appdynamics.com/FreeJavaPerformanceDownload.html
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

Re: [RFC PATCH 08/13] mmc: omap_hsmmc: limit max_segs with the EDMA DMAC

2012-09-21 Thread S, Venkatraman 
On Thu, Sep 20, 2012 at 8:13 PM, Matt Porter  wrote:
> The EDMA DMAC has a hardware limitation that prevents supporting
> scatter gather lists with any number of segments. Since the EDMA
> DMA Engine driver sets the maximum segments to 16, we do the
> same.
>
> Note: this can be removed once the DMA Engine API supports an
> API to query the DMAC's segment limitations.
>

I wouldn't want to bind the properties of EDMA to omap_hsmmc as this patch
suggests. Why don't we have a max_segs property, which when explicitly specified
in DT, will override the default ?

--
Got visibility?
Most devs has no idea what their production app looks like.
Find out how fast your code is with AppDynamics Lite.
http://ad.doubleclick.net/clk;262219671;13503038;y?
http://info.appdynamics.com/FreeJavaPerformanceDownload.html
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

Re: [RFC PATCH 08/13] mmc: omap_hsmmc: limit max_segs with the EDMA DMAC

2012-09-21 Thread S, Venkatraman 
On Fri, Sep 21, 2012 at 10:45 PM, S, Venkatraman  wrote:
> On Thu, Sep 20, 2012 at 8:13 PM, Matt Porter  wrote:
>> The EDMA DMAC has a hardware limitation that prevents supporting
>> scatter gather lists with any number of segments. Since the EDMA
>> DMA Engine driver sets the maximum segments to 16, we do the
>> same.
>>
>> Note: this can be removed once the DMA Engine API supports an
>> API to query the DMAC's segment limitations.
>>
>
> I wouldn't want to bind the properties of EDMA to omap_hsmmc as this patch
> suggests. Why don't we have a max_segs property, which when explicitly 
> specified
> in DT, will override the default ?

If you are adventurous, this can be a generic mmc DT binding instead
of restricting it to OMAP.

--
Got visibility?
Most devs has no idea what their production app looks like.
Find out how fast your code is with AppDynamics Lite.
http://ad.doubleclick.net/clk;262219671;13503038;y?
http://info.appdynamics.com/FreeJavaPerformanceDownload.html
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

Re: [RFC PATCH 08/13] mmc: omap_hsmmc: limit max_segs with the EDMA DMAC

2012-09-21 Thread S, Venkatraman 
On Fri, Sep 21, 2012 at 10:48 PM, Felipe Balbi  wrote:
> On Fri, Sep 21, 2012 at 10:47:30PM +0530, S, Venkatraman wrote:
>> On Fri, Sep 21, 2012 at 10:45 PM, S, Venkatraman  wrote:
>> > On Thu, Sep 20, 2012 at 8:13 PM, Matt Porter  wrote:
>> >> The EDMA DMAC has a hardware limitation that prevents supporting
>> >> scatter gather lists with any number of segments. Since the EDMA
>> >> DMA Engine driver sets the maximum segments to 16, we do the
>> >> same.
>> >>
>> >> Note: this can be removed once the DMA Engine API supports an
>> >> API to query the DMAC's segment limitations.
>> >>
>> >
>> > I wouldn't want to bind the properties of EDMA to omap_hsmmc as this patch
>> > suggests. Why don't we have a max_segs property, which when explicitly 
>> > specified
>> > in DT, will override the default ?
>>
>> If you are adventurous, this can be a generic mmc DT binding instead
>> of restricting it to OMAP.
>
> I say if it's a limitation in the DMAC, then DMAC's driver should handle
> it, no ? Meaning that in this case you would copy from one multi-segment
> sg into a one-segment sg and when transfer is complete, before calling
> user's callback, copy data the other way around (?)
>

Right ! So even if the property is defined for MMC, Matt will end up coding the
limitation into every peripheral driver that uses EMAC, which doesn't scale.
Your solution is better.

--
Got visibility?
Most devs has no idea what their production app looks like.
Find out how fast your code is with AppDynamics Lite.
http://ad.doubleclick.net/clk;262219671;13503038;y?
http://info.appdynamics.com/FreeJavaPerformanceDownload.html
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

Re: [RFC PATCH 00/13] DMA Engine support for AM33xx

2012-09-21 Thread Matt Porter 
On Fri, Sep 21, 2012 at 08:27:07AM +, Hebbar, Gururaja wrote:
> On Thu, Sep 20, 2012 at 20:13:33, Porter, Matt wrote:
> > 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.
> > 
> > There are a mind-boggling number of dependencies for this series:
> > 
> > - Jon Hunter's OF DMA helpers series
> >   https://patchwork.kernel.org/patch/1461061/
> >   https://patchwork.kernel.org/patch/1461051/
> > - Patch to address OF DMA helpers naming issues:
> >   https://patchwork.kernel.org/patch/1477921/
> > - EDMA DMA Engine wrapper driver in linux-next
> >   c2dde5f8f2095d7c623ff3565c1462e190272273
> > - EDMA DMA Engine wrapper driver bug fix:
> >   https://patchwork.kernel.org/patch/1474411/  
> > - A huge number of patches in linux-next for AM33xx boot
> >   (too numerous to list)
> > 
> > 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.
> > 
> > What works? Well, with this series we now have MMC and SPI support
> > on AM33xx. The only caveat for MMC is that the mmc3 controller has
> > its events on the crossbar and is not usable right now.
> > 
> > This is tested on BeagleBone with a SPI framebuffer driver and SD
> > card.
> > 
> > After this series, the plan is to convert the last in-tree user
> > of the private EDMA API (davinci-pcm/mcasp) and then eliminate
> > the private EDMA API by folding its functionality into
> > drivers/dma/edma.c.
> > 
> > TODO:
> > add AM33xx crossbar support to the private EDMA API
> > (any EDMA events on the crossbar are not supported)
> > 
> 
> 
> Can you please mention the base repo you have taken as starting point.
> (repo + extra patches ...).

It's mainline 3.6-rc6 and you can see the complete set of patches
at https://github.com/ohporter/linux/tree/edma-dmaengine-am33xx-rfc-v1
after commit 5698bd757d55b1bb87edd1a9744ab09c142abfc2

> This will help us to test the code.
> 
> This is because I looked at the patch 12/13 and I see that mmc
> device-node is modified. But in mainline I don’t see device 
> node for mmc (yet).

Oops. You'll need e62aae450bcdefbe9d7bc277ae0ef645 and
fe97304557d2c6f7d0aaf1ea028ea48ffca366a9 which I forgot to include
in this series. I'll have them in for v2.

-Matt

> > Matt Porter (13):
> >   ARM: davinci: move private EDMA API to arm/common
> >   ARM: edma: remove unused transfer controller handlers
> >   ARM: edma: add DT and runtime PM support for AM335x
> >   dmaengine: edma: enable build for AM335x
> >   dma: Add TI EDMA device tree binding
> >   ARM: omap: add hsmmc am33xx specific init
> >   mmc: omap_hsmmc: dma_request_slave_channel() support for DT platforms
> >   mmc: omap_hsmmc: limit max_segs with the EDMA DMAC
> >   mmc: omap_hsmmc: add generic DMA request support to the DT binding
> >   spi: omap2-mcspi: dma_request_slave_channel() support for DT
> > platforms
> >   spi: omap2-mcspi: add generic DMA request support to the DT binding
> >   ARM: dts: add am33xx EDMA support
> >   Documentation: add schedule for removing private EDMA API
> > 
> >  Documentation/devicetree/bindings/dma/ti-edma.txt  |   49 +
> >  .../devicetree/bindings/mmc/ti-omap-hsmmc.txt  |   25 +-
> >  Documentation/devicetree/bindings/spi/omap-spi.txt |   27 +-
> >  Documentation/feature-removal-schedule.txt |   10 +
> >  arch/arm/Kconfig   |1 +
> >  arch/arm/boot/dts/am33xx.dtsi  |   46 +
> >  arch/arm/common/Kconfig|3 +
> >  arch/arm/common/Makefile   |1 +
> >  arch/arm/common/edma.c | 1779 
> > 
> >  arch/arm/include/asm/mach/edma.h   |  267 +++
> >  arch/arm/mach-davinci/Makefile |2 +-
> >  arch/arm/mach-davinci/devices.c|3 +-
> >  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/dma.c| 1588 -
> >  arch/arm/mach-davinci/include/mach/asp.h   |2 +-
> >  arch/arm/mach-davinci/

Re: [RFC PATCH 05/13] dma: Add TI EDMA device tree binding

2012-09-21 Thread Matt Porter 
On Fri, Sep 21, 2012 at 08:45:53AM +, Hebbar, Gururaja wrote:
> On Thu, Sep 20, 2012 at 20:13:38, Porter, Matt wrote:
> > 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..06402eb
> > --- /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
> > +
> > +Example:
> > +
> > +edma: edma@4900 {
> > +   #address-cells = <1>;
> > +   #size-cells = <0>;
> 
> address-cells & size-cells are only required when current node is a parent 
> node & it has sibling/child nodes (that too if the child node uses "reg" 
> property).

Ok. will drop that in v2.

> 
> 
> > +   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>;
> > +};
> > +
> > -- 
> > 1.7.9.5
> > 
> > ___
> > Davinci-linux-open-source mailing list
> > davinci-linux-open-sou...@linux.davincidsp.com
> > http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
> > 
> 
> 
> Regards, 
> Gururaja
> ___
> Davinci-linux-open-source mailing list
> davinci-linux-open-sou...@linux.davincidsp.com
> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

--
Got visibility?
Most devs has no idea what their production app looks like.
Find out how fast your code is with AppDynamics Lite.
http://ad.doubleclick.net/clk;262219671;13503038;y?
http://info.appdynamics.com/FreeJavaPerformanceDownload.html
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

Re: [RFC PATCH 01/13] ARM: davinci: move private EDMA API to arm/common

2012-09-21 Thread Matt Porter 
On Fri, Sep 21, 2012 at 07:10:52AM +, Hebbar, Gururaja wrote:
> On Thu, Sep 20, 2012 at 20:13:34, Porter, Matt wrote:
> > Move mach-davinci/dma.c to common/edma.c so it can be used
> > by OMAP (specifically AM33xx atm) as well. This just moves
> > the private EDMA API but does not support OMAP.
> > 
> > Signed-off-by: Matt Porter 
> > ---
> >  arch/arm/Kconfig   |1 +
> >  arch/arm/common/Kconfig|3 +
> >  arch/arm/common/Makefile   |1 +
> >  arch/arm/common/edma.c | 1588 
> > 
> >  arch/arm/include/asm/mach/edma.h   |  267 +
> >  arch/arm/mach-davinci/Makefile |2 +-
> >  arch/arm/mach-davinci/devices.c|3 +-
> >  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/dma.c| 1588 
> > 
> 
> 
> Please use –M option, while generating patches via git-format-patch. 
> This reduces the patch size if files are copied/renamed/moved.

Yes, I didn't notice until the arm kernel list caught the >100k post.
Will take care of this in v2.

-Matt

--
Got visibility?
Most devs has no idea what their production app looks like.
Find out how fast your code is with AppDynamics Lite.
http://ad.doubleclick.net/clk;262219671;13503038;y?
http://info.appdynamics.com/FreeJavaPerformanceDownload.html
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

Re: [RFC PATCH 01/13] ARM: davinci: move private EDMA API to arm/common

2012-09-21 Thread Matt Porter 
On Fri, Sep 21, 2012 at 10:42:05AM +0100, Russell King wrote:
> On Fri, Sep 21, 2012 at 09:33:42AM +, Hebbar, Gururaja wrote:
> > On Fri, Sep 21, 2012 at 14:59:23, Russell King - ARM Linux wrote:
> > > On Thu, Sep 20, 2012 at 10:43:34AM -0400, Matt Porter wrote:
> > > > Move mach-davinci/dma.c to common/edma.c so it can be used
> > > > by OMAP (specifically AM33xx atm) as well. This just moves
> > > > the private EDMA API but does not support OMAP.
> > > > 
> > > > Signed-off-by: Matt Porter 
> > > > ---
> > > >  arch/arm/Kconfig   |1 +
> > > >  arch/arm/common/Kconfig|3 +
> > > >  arch/arm/common/Makefile   |1 +
> > > >  arch/arm/common/edma.c | 1588 
> > > > 
> > > >  arch/arm/include/asm/mach/edma.h   |  267 +
> > > 
> > > asm/mach should not be used as a dumping ground for platform header files.
> > > It is there to provide the interfaces between generic ARM architecture
> > > code and platform code.  (At least four files that are there at the
> > > moment need to be moved out of there - patch series to follow...)
> > 
> > Can this be moved to include/linux/platform_data/ ?
> 
> Here's the pertinant question: "is it platform data?"  Looking at the
> file, it appears to be internal data structures and register definitions
> for the driver itself.  Therefore, it isn't platform data, and it
> shouldn't be living separately from the driver.
> 
> If the driver itself only makes use of the data structures, the data
> structures should be defined either within the driver, or a header file
> co-located next to the driver itself.  The same goes for register
> definitions too.
> 
> The only structure that I can find which isn't internal to the driver
> is struct edma_soc_info, struct edma_rsv_info, and the enum dma_event_q.
> Those can go to include/linux/platform_data, but the rest should not.

Ok, but is it ok to keep the actual private EDMA API portion in
arch/arm/include/asm/mach/? It's not a problem to move the internal
portions to a local include and that pdata to the appropriate place.
We still need a place independent of mach-davinci and mach-omap2 to
keep that portion of the include. I suppose it could be put in with
the dmaengine wrapper's include/linux/edma.h but I hate to clutter
that up when the private API will go away later.

-Matt

--
Got visibility?
Most devs has no idea what their production app looks like.
Find out how fast your code is with AppDynamics Lite.
http://ad.doubleclick.net/clk;262219671;13503038;y?
http://info.appdynamics.com/FreeJavaPerformanceDownload.html
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

Re: [RFC PATCH 10/13] spi: omap2-mcspi: dma_request_slave_channel() support for DT platforms

2012-09-21 Thread Matt Porter 
On Fri, Sep 21, 2012 at 08:42:47AM -0700, Tony Lindgren wrote:
> * Arnd Bergmann  [120921 02:19]:
> > On Thursday 20 September 2012, Tony Lindgren wrote:
> > > >  /* use PIO for small transfers, avoiding DMA setup/teardown overhead 
> > > > and
> > > > @@ -798,14 +801,26 @@ 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);
> > > > + if (spi->dev.of_node)
> > > > + mcspi_dma->dma_rx =
> > > > + dma_request_slave_channel(&master->dev,
> > > > +   
> > > > mcspi_dma->dma_rx_ch_name);
> > > > + else
> > > > + mcspi_dma->dma_rx =
> > > > + dma_request_channel(mask, omap_dma_filter_fn, 
> > > > &sig);
> > > >   if (!mcspi_dma->dma_rx) {
> > > >   dev_err(&spi->dev, "no RX DMA engine channel for 
> > > > McSPI\n");
> > > >   return -EAGAIN;
> > > >   }
> > > >  
> > > 
> > > Hmm this does not look nice.. We should be able to somehow not to care 
> > > about
> > > the configuration at the mcspi driver level.
> > 
> > I agree, but as far as I understand Vinod's plans, we would actually move
> > all drivers over to dma_request_slave_channel() when we have an interface
> > to register the lookup tables from platform code.
> > 
> > I think the above is ok for a transitional phase and we can remove the
> > fallback path when we have converted all platforms using this driver
> > to either use DT or move to the new style way of passing the channel
> > configuration.
> 
> Can't we come up with a version of dma_request_slave_channel that works
> both ways for now:
> 
>   mcspi_dma->dma_rx =
>   dma_request_slave_channel_compat(mask, omap_dma_filter_fn, &sig,
>   &master->dev, 
> mcspi_dma->dma_rx_ch_name);
>   ... 
> 
> Then it's just question of patching away two lines later on rather than
> having to add all this if else to all the drivers first, then patching
> it away again.

I think that something like that is workable with the implementation
simply checking for of_node to do the right thing.

-Matt

--
Got visibility?
Most devs has no idea what their production app looks like.
Find out how fast your code is with AppDynamics Lite.
http://ad.doubleclick.net/clk;262219671;13503038;y?
http://info.appdynamics.com/FreeJavaPerformanceDownload.html
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

Re: [RFC PATCH 08/13] mmc: omap_hsmmc: limit max_segs with the EDMA DMAC

2012-09-21 Thread Matt Porter 
On Fri, Sep 21, 2012 at 10:47:30PM +0530, S, Venkatraman wrote:
> On Fri, Sep 21, 2012 at 10:45 PM, S, Venkatraman  wrote:
> > On Thu, Sep 20, 2012 at 8:13 PM, Matt Porter  wrote:
> >> The EDMA DMAC has a hardware limitation that prevents supporting
> >> scatter gather lists with any number of segments. Since the EDMA
> >> DMA Engine driver sets the maximum segments to 16, we do the
> >> same.
> >>
> >> Note: this can be removed once the DMA Engine API supports an
> >> API to query the DMAC's segment limitations.
> >>
> >
> > I wouldn't want to bind the properties of EDMA to omap_hsmmc as this patch
> > suggests. Why don't we have a max_segs property, which when explicitly 
> > specified
> > in DT, will override the default ?
> 
> If you are adventurous, this can be a generic mmc DT binding instead
> of restricting it to OMAP.

I think it's bad practice to add something to a binding that is not part
of the hardware definition for the device. In this case, the limitations
comes strictly from the DMAC. As I noted, the proper fix for this is to
have the DMA Engine API extended to allow querying the DMAC SG
capabilities before setting up a DMA transfer. I brought this up
previously in the thread where the actual EDMA dmaengine wrapper driver
was discussed and Vinod indicated that he was open to dmaengine
providing this information.

It makes sense as DMA Engine should tell the slave driver everything it
needs to know to set up a transfer...this is just a missing piece right
now. FWIW, we have this issue in davinci_mmc.c as well...it just was
already hardcoded with a value to satisfy the EDMA DMAC. However, I'd
like to see that go away as well.

-Matt

--
Got visibility?
Most devs has no idea what their production app looks like.
Find out how fast your code is with AppDynamics Lite.
http://ad.doubleclick.net/clk;262219671;13503038;y?
http://info.appdynamics.com/FreeJavaPerformanceDownload.html
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

Re: [RFC PATCH 08/13] mmc: omap_hsmmc: limit max_segs with the EDMA DMAC

2012-09-21 Thread Russell King - ARM Linux 
On Fri, Sep 21, 2012 at 10:45:29PM +0530, S, Venkatraman wrote:
> On Thu, Sep 20, 2012 at 8:13 PM, Matt Porter  wrote:
> > The EDMA DMAC has a hardware limitation that prevents supporting
> > scatter gather lists with any number of segments. Since the EDMA
> > DMA Engine driver sets the maximum segments to 16, we do the
> > same.
> >
> > Note: this can be removed once the DMA Engine API supports an
> > API to query the DMAC's segment limitations.
> >
> 
> I wouldn't want to bind the properties of EDMA to omap_hsmmc as this patch
> suggests. Why don't we have a max_segs property, which when explicitly 
> specified
> in DT, will override the default ?

Why not have a generic way that DMA engine can export these kinds of
properties?

--
Got visibility?
Most devs has no idea what their production app looks like.
Find out how fast your code is with AppDynamics Lite.
http://ad.doubleclick.net/clk;262219671;13503038;y?
http://info.appdynamics.com/FreeJavaPerformanceDownload.html
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

Re: [RFC PATCH 01/13] ARM: davinci: move private EDMA API to arm/common

2012-09-21 Thread Russell King - ARM Linux 
On Fri, Sep 21, 2012 at 02:34:46PM -0400, Matt Porter wrote:
> On Fri, Sep 21, 2012 at 10:42:05AM +0100, Russell King wrote:
> > Here's the pertinant question: "is it platform data?"  Looking at the
> > file, it appears to be internal data structures and register definitions
> > for the driver itself.  Therefore, it isn't platform data, and it
> > shouldn't be living separately from the driver.
> > 
> > If the driver itself only makes use of the data structures, the data
> > structures should be defined either within the driver, or a header file
> > co-located next to the driver itself.  The same goes for register
> > definitions too.
> > 
> > The only structure that I can find which isn't internal to the driver
> > is struct edma_soc_info, struct edma_rsv_info, and the enum dma_event_q.
> > Those can go to include/linux/platform_data, but the rest should not.
> 
> Ok, but is it ok to keep the actual private EDMA API portion in
> arch/arm/include/asm/mach/? It's not a problem to move the internal
> portions to a local include and that pdata to the appropriate place.

Move the platform data parts to include/linux/platform_data.
Move the driver specific parts to be either in the .c file for the
driver, or in a .h file _along_ _side_ the .c file.

Private data for drivers should be kept as close to the driver as
possible, whether that be in the same .c file as the driver itself,
or a header co-located with the .c file.

--
Got visibility?
Most devs has no idea what their production app looks like.
Find out how fast your code is with AppDynamics Lite.
http://ad.doubleclick.net/clk;262219671;13503038;y?
http://info.appdynamics.com/FreeJavaPerformanceDownload.html
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

Re: [RFC PATCH 08/13] mmc: omap_hsmmc: limit max_segs with the EDMA DMAC

2012-09-21 Thread Matt Porter 
On Fri, Sep 21, 2012 at 08:18:41PM +0300, Felipe Balbi wrote:
> On Fri, Sep 21, 2012 at 10:47:30PM +0530, S, Venkatraman wrote:
> > On Fri, Sep 21, 2012 at 10:45 PM, S, Venkatraman  wrote:
> > > On Thu, Sep 20, 2012 at 8:13 PM, Matt Porter  wrote:
> > >> The EDMA DMAC has a hardware limitation that prevents supporting
> > >> scatter gather lists with any number of segments. Since the EDMA
> > >> DMA Engine driver sets the maximum segments to 16, we do the
> > >> same.
> > >>
> > >> Note: this can be removed once the DMA Engine API supports an
> > >> API to query the DMAC's segment limitations.
> > >>
> > >
> > > I wouldn't want to bind the properties of EDMA to omap_hsmmc as this patch
> > > suggests. Why don't we have a max_segs property, which when explicitly 
> > > specified
> > > in DT, will override the default ?
> > 
> > If you are adventurous, this can be a generic mmc DT binding instead
> > of restricting it to OMAP.
> 
> I say if it's a limitation in the DMAC, then DMAC's driver should handle
> it, no ? Meaning that in this case you would copy from one multi-segment
> sg into a one-segment sg and when transfer is complete, before calling
> user's callback, copy data the other way around (?)

With this DMAC, we would have to do a CPU-based copy or a series of
smaller DMA-based 16 segment copies with completion interrupts in between.

The reason the EDMA DMA Engine driver sets this limit is that we have
a hardware limitation preventing setting up a large multi-segment
transfer. The limitation is set by how many EDMA PaRaM slots are
available (varies based on how the hwmod is instantiated) but on AM335x
it's 256. You can't use all of those for just one slave device and so
the EDMA dmaengine driver arbitrarily hardcodes (atm) 16 as the max
any one channel can claim.  Even if you could use all of them, it's
common for an unrestricted scatter gather transfer to exceed even our
best case hardware limitation.

This is a case where asking the DMA Engine driver to handle any length
SG is going to result in a big peformance hit, since the MMC subsystem
provides this hook for a reason, we just need the proper DMA Engine API
to find out how to set it.

So I guess I'm going to need to write up an API proposal unless Vinod
has already been thinking about this...

-Matt

--
Got visibility?
Most devs has no idea what their production app looks like.
Find out how fast your code is with AppDynamics Lite.
http://ad.doubleclick.net/clk;262219671;13503038;y?
http://info.appdynamics.com/FreeJavaPerformanceDownload.html
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

Re: [RFC PATCH 08/13] mmc: omap_hsmmc: limit max_segs with the EDMA DMAC

2012-09-21 Thread Matt Porter 
On Fri, Sep 21, 2012 at 07:47:21PM +0100, Russell King wrote:
> On Fri, Sep 21, 2012 at 10:45:29PM +0530, S, Venkatraman wrote:
> > On Thu, Sep 20, 2012 at 8:13 PM, Matt Porter  wrote:
> > > The EDMA DMAC has a hardware limitation that prevents supporting
> > > scatter gather lists with any number of segments. Since the EDMA
> > > DMA Engine driver sets the maximum segments to 16, we do the
> > > same.
> > >
> > > Note: this can be removed once the DMA Engine API supports an
> > > API to query the DMAC's segment limitations.
> > >
> > 
> > I wouldn't want to bind the properties of EDMA to omap_hsmmc as this patch
> > suggests. Why don't we have a max_segs property, which when explicitly 
> > specified
> > in DT, will override the default ?
> 
> Why not have a generic way that DMA engine can export these kinds of
> properties?

That's exactly what my note above is suggesting...

Something along the lines of:

struct slave_sg_caps
{
int max_segs;   /* <0 is no limit */
}

struct slave_sg_cap *
dmaengine_get_slave_sg_caps(struct dma_chan *chan);

I'm sure there are or will be other characteristics worth providing to
slave drivers.

-Matt

--
Got visibility?
Most devs has no idea what their production app looks like.
Find out how fast your code is with AppDynamics Lite.
http://ad.doubleclick.net/clk;262219671;13503038;y?
http://info.appdynamics.com/FreeJavaPerformanceDownload.html
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

Maigrissez sans vous priver

2012-09-21 Thread Methode Chocolat par Duano 
Pour voir le message, veuillez utiliser un lecteur de mail compatible HTML

Lien miroir : 
http://m10-fr.com/mc10_m/YT0xMyZiPTIwNjEyJmM9NDgzNjEyJmQ9MjAxMi0wOS0yMSAyMToyMDowMSZlPTEmaD0yMDYxMSZmPTIwNjEyJmc9MjA2MTI=

Lien de désinscription : 
http://m10-fr.com/mc10_unsub/YT0xMyZiPTIwNjEyJmM9NDgzNjEyJmQ9MjAxMi0wOS0yMSAyMToyMDowMSZlPTEmaD0yMDYxMSZmPTIwNjEyJmc9MjA2MTI=


--
Got visibility?
Most devs has no idea what their production app looks like.
Find out how fast your code is with AppDynamics Lite.
http://ad.doubleclick.net/clk;262219671;13503038;y?
http://info.appdynamics.com/FreeJavaPerformanceDownload.html
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

[SPAM] Re: Question

2012-09-21 Thread David Zabawa 
Get Approved for $50K - $200K Unsecured Business Credit 
No personal credit check - No personal guarantee – Guaranteed!  

To get info call (888) 386-9221 

> PLUS 5 VENDOR CREDIT LINES & 3 BUSINESS CREDIT CARDS  
> PEACE OF MIND SEPARATING PERSONAL FROM BUSINESS CREDIT
> PERSONAL FUNDING/CREDIT BUILDER COACH GUIDES YOU ENTIRE WAY   
> INCREASE VALUE OF YOUR BUSINESS WITH A CREDIT RATING ASSET
> PERSONAL CREDIT NOT SO GOOD?  WE’LL REPAIR THAT TOO   
> CREATIVE FUNDING FOR ANY KIND OF BUSINESS 

Utilizing our unique and exclusive private money corporate credit program, 
ANYONE   
CAN PARTICIPATE.  Regardless of your credit!

* Become a referral affiliate and start earning commissions for referring your 
clients! 
Call 1 (888) 386 9221 today!
  
BUSINESS ASSISTANCE FOUNDATION, INC 
1 (888) 386 9221









Click This Link to Stop Future Messages 




--
Got visibility?
Most devs has no idea what their production app looks like.
Find out how fast your code is with AppDynamics Lite.
http://ad.doubleclick.net/clk;262219671;13503038;y?
http://info.appdynamics.com/FreeJavaPerformanceDownload.html
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

Les bonnes affaires de septembre jusqu'à -40 pourcent

2012-09-21 Thread 3Suisses par Duano 
Pour voir le message, veuillez utiliser un lecteur de mail compatible HTML

Lien miroir : 
http://m10-fr.com/mc10_m/YT0xMyZiPTIwMjc3JmM9NDgzNjEyJmQ9MjAxMi0wOS0yMSAyMzo1MDowMSZlPTEmaD0yMDI3NiZmPTIwMjc3Jmc9MjAyNzc=

Lien de désinscription : 
http://m10-fr.com/mc10_unsub/YT0xMyZiPTIwMjc3JmM9NDgzNjEyJmQ9MjAxMi0wOS0yMSAyMzo1MDowMSZlPTEmaD0yMDI3NiZmPTIwMjc3Jmc9MjAyNzc=


--
How fast is your code?
3 out of 4 devs don\\\'t know how their code performs in production.
Find out how slow your code is with AppDynamics Lite.
http://ad.doubleclick.net/clk;262219672;13503038;z?
http://info.appdynamics.com/FreeJavaPerformanceDownload.html
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

Re: [PATCH] spi/imx: set the inactive state of the clock according to the clock polarity

2012-09-21 Thread Dirk Behme 
On 21.09.2012 09:54, Uwe Kleine-König wrote:
> On Fri, Sep 21, 2012 at 09:36:51AM +0200, Dirk Behme wrote:
>> On 31.08.2012 04:35, Shawn Guo wrote:
>>> Copy Uwe ...
> Copy our kernel mailing list ...
>
>> Ping ;)
>>
>> Any opinions on this?
> Assuming it fixes access to a device I'm ok with your patch, but I don't
> really feel responsible for the driver (i.e. me not acking shouldn't
> have a negative influence on getting the patch in).

Ok, thanks.

I'm not so familiar with the SPI world: Who would be the best person 
to ack this, and in case it's ok finally apply it, then?

Thanks

Dirk

>>> On Fri, Aug 31, 2012 at 10:55:11AM +0200, Dirk Behme wrote:
 From: Knut Wohlrab

 There are SPI devices which need a SPI clock with active low polarity and
 high inactive state.

 Add the setting of the inactive state ECSPIx_CONFIGREG:SCLK CTL
 according to the clock polarity ECSPIx_CONFIGREG:SCLK POL:

 DT without "spi-cpol" = 0 = clock active high polarity = inactive state low
 DT with"spi-cpol" = 1 = clock active low  polarity = inactive state 
 high

 Signed-off-by: Knut Wohlrab
> If you forward a patch you must add your S-o-b.
>
 ---

 Question: Are there real world examples for a need of an individual 
 setting of
 clock polarity/inactive state?
>>>
>>> I'm less concerned about that.  We can always patch the driver when
>>> the real world example occurs?
> yes.
>
> Thanks
> Uwe
>
 drivers/spi/spi-imx.c |6 --
 1 files changed, 4 insertions(+), 2 deletions(-)

 diff --git a/drivers/spi/spi-imx.c b/drivers/spi/spi-imx.c
 index e834ff8..d64655b 100644
 --- a/drivers/spi/spi-imx.c
 +++ b/drivers/spi/spi-imx.c
 @@ -197,6 +197,7 @@ static unsigned int spi_imx_clkdiv_2(unsigned int fin,
 #define MX51_ECSPI_CONFIG_SCLKPOL(cs)  (1<<  ((cs) +  4))
 #define MX51_ECSPI_CONFIG_SBBCTRL(cs)  (1<<  ((cs) +  8))
 #define MX51_ECSPI_CONFIG_SSBPOL(cs)   (1<<  ((cs) + 12))
 +#define MX51_ECSPI_CONFIG_SCLKCTL(cs) (1<<  ((cs) + 20))
 #define MX51_ECSPI_INT 0x10
 #define MX51_ECSPI_INT_TEEN(1<<   0)
 @@ -287,9 +288,10 @@ static int __maybe_unused mx51_ecspi_config(struct 
 spi_imx_data *spi_imx,
if (config->mode&  SPI_CPHA)
cfg |= MX51_ECSPI_CONFIG_SCLKPHA(config->cs);
 -  if (config->mode&  SPI_CPOL)
 +  if (config->mode&  SPI_CPOL) {
cfg |= MX51_ECSPI_CONFIG_SCLKPOL(config->cs);
 -
 +  cfg |= MX51_ECSPI_CONFIG_SCLKCTL(config->cs);
 +  }
if (config->mode&  SPI_CS_HIGH)
cfg |= MX51_ECSPI_CONFIG_SSBPOL(config->cs);
 --
 1.7.0.4
>>
>> ___
>> linux-arm-kernel mailing list
>> linux-arm-ker...@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>>
>


--
How fast is your code?
3 out of 4 devs don\\\'t know how their code performs in production.
Find out how slow your code is with AppDynamics Lite.
http://ad.doubleclick.net/clk;262219672;13503038;z?
http://info.appdynamics.com/FreeJavaPerformanceDownload.html
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

Selection d'offres jusqu'à -70%

2012-09-21 Thread Voyage Prive par Duano 
Pour voir le message, veuillez utiliser un lecteur de mail compatible HTML

Lien miroir : 
http://m10-fr.com/mc10_m/YT0xMyZiPTIwMzEwJmM9NDgzNjEyJmQ9MjAxMi0wOS0yMiAwNzowMDowMSZlPTEmaD0yMDMwOSZmPTIwMzEwJmc9MjAzMTA=

Lien de désinscription : 
http://m10-fr.com/mc10_unsub/YT0xMyZiPTIwMzEwJmM9NDgzNjEyJmQ9MjAxMi0wOS0yMiAwNzowMDowMSZlPTEmaD0yMDMwOSZmPTIwMzEwJmc9MjAzMTA=


--
How fast is your code?
3 out of 4 devs don\\\'t know how their code performs in production.
Find out how slow your code is with AppDynamics Lite.
http://ad.doubleclick.net/clk;262219672;13503038;z?
http://info.appdynamics.com/FreeJavaPerformanceDownload.html
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general