Re: [PATCH V2 11/19] ARM: dts: am57xx: sbc-am57x: add basic board support

[Rob Herring]

On Tue, Dec 01, 2015 at 08:03:13PM +0200, Dmitry Lifshitz wrote:
> SBC-AM57x is a single board computer designed for industrial and
> embedded applications. It is based on the Texas Instruments Sitara AM57x
> system-on-chip family. SBC-AM57x is implemented with the CL-SOM-AM57x
> computer-on-module providing most of the functions, and SB-SOM-AM57x
> carrier board providing additional peripheral functions and connectors.
> 
> https://www.compulab.co.il/products/sbcs/sbc-am57x-ti-am5728-am5718-single-board-computer/
> 
> https://www.compulab.co.il/products/computer-on-modules/cl-som-am57x-ti-am5728-am5718-system-on-module/
> 
> Add basic board support, including UART3, used as a serial console.
> 
> Signed-off-by: Dmitry Lifshitz 
> Acked-by: Igor Grinberg 

Acked-by: Rob Herring 

> ---
> 
>   v2:
> 
>* No fuctional changes
>* Reformat subject
> 
>  .../devicetree/bindings/arm/omap/omap.txt  |  3 ++
>  arch/arm/boot/dts/Makefile |  1 +
>  arch/arm/boot/dts/am57xx-sbc-am57x.dts | 36 
> ++
>  3 files changed, 40 insertions(+)
>  create mode 100644 arch/arm/boot/dts/am57xx-sbc-am57x.dts
> 
> diff --git a/Documentation/devicetree/bindings/arm/omap/omap.txt 
> b/Documentation/devicetree/bindings/arm/omap/omap.txt
> index dd53c90..42cdad1 100644
> --- a/Documentation/devicetree/bindings/arm/omap/omap.txt
> +++ b/Documentation/devicetree/bindings/arm/omap/omap.txt
> @@ -159,6 +159,9 @@ Boards:
>  - AM57XX CL-SOM-AM57x
>compatible = "compulab,cl-som-am57x", "ti,am5728", "ti,dra742", 
> "ti,dra74", "ti,dra7"
>  
> +- AM57XX SBC-AM57x
> +  compatible = "compulab,sbc-am57x", "compulab,cl-som-am57x", "ti,am5728", 
> "ti,dra742", "ti,dra74", "ti,dra7"
> +
>  - DRA742 EVM:  Software Development Board for DRA742
>compatible = "ti,dra7-evm", "ti,dra742", "ti,dra74", "ti,dra7"
>  
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index 803a020..4c73ab9 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -479,6 +479,7 @@ dtb-$(CONFIG_SOC_OMAP5) += \
>  dtb-$(CONFIG_SOC_DRA7XX) += \
>   am57xx-beagle-x15.dtb \
>   am57xx-cl-som-am57x.dtb \
> + am57xx-sbc-am57x.dtb \
>   dra7-evm.dtb \
>   dra72-evm.dtb
>  dtb-$(CONFIG_ARCH_ORION5X) += \
> diff --git a/arch/arm/boot/dts/am57xx-sbc-am57x.dts 
> b/arch/arm/boot/dts/am57xx-sbc-am57x.dts
> new file mode 100644
> index 000..804ad72
> --- /dev/null
> +++ b/arch/arm/boot/dts/am57xx-sbc-am57x.dts
> @@ -0,0 +1,36 @@
> +/*
> + * Support for CompuLab SBC-AM57x single board computer
> + *
> + * Copyright (C) 2015 CompuLab Ltd. - http://www.compulab.co.il/
> + * Author: Dmitry Lifshitz 
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License version 2 as published 
> by
> + * the Free Software Foundation.
> + */
> +
> +#include "am57xx-cl-som-am57x.dts"
> +#include "compulab-sb-som.dtsi"
> +
> +/ {
> + model = "CompuLab CL-SOM-AM57x on SB-SOM-AM57x";
> + compatible = "compulab,sbc-am57x", "compulab,cl-som-am57x", 
> "ti,am5728", "ti,dra742", "ti,dra74", "ti,dra7";
> +};
> +
> +_pmx_core {
> + uart3_pins_default: uart3_pins_default {
> + pinctrl-single,pins = <
> + DRA7XX_CORE_IOPAD(0x37f8, PIN_INPUT_SLEW | MUX_MODE2)   
> /* uart2_ctsn.uart3_rxd */
> + DRA7XX_CORE_IOPAD(0x37fc, PIN_INPUT_SLEW | MUX_MODE1)   
> /* uart2_rtsn.uart3_txd */
> + >;
> + };
> +};
> +
> + {
> + status = "okay";
> + interrupts-extended = <_mpu GIC_SPI 69 IRQ_TYPE_LEVEL_HIGH>,
> +   <_pmx_core 0x3f8>;
> +
> + pinctrl-names = "default";
> + pinctrl-0 = <_pins_default>;
> +};
> -- 
> 1.9.1
> 
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC v02 03/15] dmaengine: core: Introduce new, universal API to request a channel

[Tony Lindgren]

* Peter Ujfalusi  [151202 02:01]:
> On 12/01/2015 07:00 PM, Tony Lindgren wrote:
> >> I see. The dm81xx basically am33xx/am43xx?
> > 
> > Yeah similar to am33xx with different clocks and with a bunch of 
> > accelerators.
> > 
> >> Actually I would prefer to use the dmaengine's event router framework and 
> >> we
> >> do have support for the am33xx/am43xx type of crossbar already implemented.
> >> I'm going to resend the DTS series for am33xx/am43xx to convert them to use
> >> the new DT bindings along with the dma event router support:
> >> https://www.mail-archive.com/linux-omap%40vger.kernel.org/msg120828.html
> > 
> > OK yes a dmaengine event router works too when available. Good to see
> > them as separate driver instances now :) Are only the dts changes missing
> > now?
> > 
> > FYI, when we have separate interconnect driver instances, we don't want to
> > and cannot tweak registers outside the interconnect instance because of them
> > being in separate clock and/or power domains :p
> 
> What does this mean in practice? We can not touch these registers? The DMA
> crossbar is a separate driver from the eDMA driver.

Seem like it should not affect DMA crossbar as it's a separate driver.

What I meant is we need a separate driver for clocks, pinctrl, regulators,
PHY, crossbar or syscon to use the SCM registers from drivers sitting on a
L4 interonnect.

> > In any case, it seems there's no harm using pinctrl for evtmux on dm81xx
> > until the event router is available. It's currently only needed on the
> > t410 emmc that I'm aware of :)
> 
> The AM33xx/AM43xx DMA crossbar support is in 4.4 already:
> 42dbdcc6bf96 dmaengine: ti-dma-crossbar: Add support for crossbar on 
> AM33xx/AM43xx

OK great.

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V3 01/19] ARM: dts: am57xx: cl-som-am57x: add basic module support

[Rob Herring]

On Tue, Dec 01, 2015 at 08:03:03PM +0200, Dmitry Lifshitz wrote:
> Add support for CompuLab CM-SOM-AM57X board.
> 
> CL-SOM-AM57x is a miniature System-on-Module (SoM) based on
> TI Sitara AM57x ARM Cortex-A15 System-on-Chip family.
> 
> https://www.compulab.co.il/products/computer-on-modules/cl-som-am57x-ti-am5728-am5718-system-on-module/
> 
> Add basic DT support for standalone module (without a carrier board):
> 
> * Memory configuration
> * Heartbeat led
> * I2C1 and I2C4
> * PMIC
> * SATA
> 
> Signed-off-by: Dmitry Lifshitz 
> Acked-by: Igor Grinberg 

Acked-by: Rob Herring 

> ---
>  v3:
>  
>* Move PMIC to I2C4
>* Reformat subject
>  
>  v2: 
> 
>* Fixed voltages (for OPP_HIGH) for VDD_GPU, VDD_IVA, VDD_DSPEVE
>* Added comments for VDDA_1V8_PHYA/B
>* Add "regulator-always-on" property for ldousb_reg 
> 
>  .../devicetree/bindings/arm/omap/omap.txt  |   3 +
>  arch/arm/boot/dts/Makefile |   3 +-
>  arch/arm/boot/dts/am57xx-cl-som-am57x.dts  | 274 
> +
>  3 files changed, 279 insertions(+), 1 deletion(-)
>  create mode 100644 arch/arm/boot/dts/am57xx-cl-som-am57x.dts
> 
> diff --git a/Documentation/devicetree/bindings/arm/omap/omap.txt 
> b/Documentation/devicetree/bindings/arm/omap/omap.txt
> index da84372..dd53c90 100644
> --- a/Documentation/devicetree/bindings/arm/omap/omap.txt
> +++ b/Documentation/devicetree/bindings/arm/omap/omap.txt
> @@ -156,6 +156,9 @@ Boards:
>  - AM437x SK EVM: AM437x StarterKit Evaluation Module
>compatible = "ti,am437x-sk-evm", "ti,am4372", "ti,am43"
>  
> +- AM57XX CL-SOM-AM57x
> +  compatible = "compulab,cl-som-am57x", "ti,am5728", "ti,dra742", 
> "ti,dra74", "ti,dra7"
> +
>  - DRA742 EVM:  Software Development Board for DRA742
>compatible = "ti,dra7-evm", "ti,dra742", "ti,dra74", "ti,dra7"
>  
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index 5492a24..803a020 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -477,8 +477,9 @@ dtb-$(CONFIG_SOC_OMAP5) += \
>   omap5-sbc-t54.dtb \
>   omap5-uevm.dtb
>  dtb-$(CONFIG_SOC_DRA7XX) += \
> - dra7-evm.dtb \
>   am57xx-beagle-x15.dtb \
> + am57xx-cl-som-am57x.dtb \
> + dra7-evm.dtb \
>   dra72-evm.dtb
>  dtb-$(CONFIG_ARCH_ORION5X) += \
>   orion5x-lacie-d2-network.dtb \
> diff --git a/arch/arm/boot/dts/am57xx-cl-som-am57x.dts 
> b/arch/arm/boot/dts/am57xx-cl-som-am57x.dts
> new file mode 100644
> index 000..087d62e
> --- /dev/null
> +++ b/arch/arm/boot/dts/am57xx-cl-som-am57x.dts
> @@ -0,0 +1,274 @@
> +/*
> + * Support for CompuLab CL-SOM-AM57x System-on-Module
> + *
> + * Copyright (C) 2015 CompuLab Ltd. - http://www.compulab.co.il/
> + * Author: Dmitry Lifshitz 
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License version 2 as published 
> by
> + * the Free Software Foundation.
> + */
> +
> +/dts-v1/;
> +
> +#include 
> +#include 
> +#include "dra74x.dtsi"
> +
> +/ {
> + model = "CompuLab CL-SOM-AM57x";
> + compatible = "compulab,cl-som-am57x", "ti,am5728", "ti,dra742", 
> "ti,dra74", "ti,dra7";
> +
> + memory {
> + device_type = "memory";
> + reg = <0x8000 0x2000>; /* 512 MB - minimal 
> configuration */
> + };
> +
> + leds {
> + compatible = "gpio-leds";
> + pinctrl-names = "default";
> + pinctrl-0 = <_pins_default>;
> +
> + led@0 {
> + label = "cl-som-am57x:green";
> + gpios = < 5 GPIO_ACTIVE_HIGH>;
> + linux,default-trigger = "heartbeat";
> + default-state = "off";
> + };
> + };
> +};
> +
> +_pmx_core {
> + leds_pins_default: leds_pins_default {
> + pinctrl-single,pins = <
> + DRA7XX_CORE_IOPAD(0x347c, PIN_OUTPUT | MUX_MODE14)  
> /* gpmc_a15.gpio2_5 */
> + >;
> + };
> +
> + i2c1_pins_default: i2c1_pins_default {
> + pinctrl-single,pins = <
> + DRA7XX_CORE_IOPAD(0x3800, PIN_INPUT_PULLUP | MUX_MODE0) 
> /* i2c1_sda.sda */
> + DRA7XX_CORE_IOPAD(0x3804, PIN_INPUT_PULLUP | MUX_MODE0) 
> /* i2c1_scl.scl */
> + >;
> + };
> +
> + i2c4_pins_default: i2c4_pins_default {
> + pinctrl-single,pins = <
> + DRA7XX_CORE_IOPAD(0x36ac, PIN_INPUT| MUX_MODE10)
> /* mcasp1_acl.i2c4_sda */
> + DRA7XX_CORE_IOPAD(0x36b0, PIN_INPUT| MUX_MODE10)
> /* mcasp1_fsr.i2c4_scl */
> + >;
> + };
> +
> + tps659038_pins_default: tps659038_pins_default {
> + pinctrl-single,pins = <
> + DRA7XX_CORE_IOPAD(0x3818, PIN_INPUT_PULLUP | 
> MUX_MODE14) /* wakeup0.gpio1_0 

Re: [RFC v03 00/15] dmaengine: New 'universal' API for requesting channel

[Andy Shevchenko]

On Wed, Dec 2, 2015 at 3:59 PM, Peter Ujfalusi  wrote:
> Hi,
>
> I keep this still as RFC.
>
> Changes since RFC v02:
> - Using has_acpi_companion() instead ACPI_HANDLE()
> - mask matching change within private_candidate()
> - Fallback in dma_request_chan() when DT/ACPI lookup fails.
> - Rename dma_get_channel() -> find_candidate()
> - Arch code changes as suggested by Arnd
> - Some documentation updated, more need to be done.
>
> Changes since RFC v01:
> - dma_request_chan(); lost the mask parameter
> - The new API does not rely on RESOURCE_DMA, instead the dma_filter_map table
>   will be used to provide the needed information to the filter function in
>   legacy mode
> - Extended the example patches to convert most of daVinci to use the new API 
> to
>   request the DMA channels.
>
> TODO: Documentation update ;)
>
> As it has been discussed in the following thread:
> http://www.gossamer-threads.com/lists/linux/kernel/2181487#2181487
>
> Andy: I did looked at the unified device properties, but I decided to not to 
> use
> it as I don't see it to fit well and most of the legacy board files are using
> resources to specify at least their memory regions so adding the DMA resource
> to them would be more inline with the rest of the code.
>
> The ARM, mmc and spi patches are converting daVinci drivers board files to use
> the new method of requesting DMA channel.
>
> With this series I have taken a path which would result two new API, which can
> be used to convert most of the current users already and with some work all
> users might be able to move to this set.
> With this set the filter_fn used for legacy (non DT/ACPI) channel request is 
> no
> longer needed to be exported to client drivers since the selection of the
> correct filter_fn will be done in the core.
>
> So, the first proposal is to have:
>
> struct dma_chan *dma_request_chan(struct device *dev, const char *name);
> struct dma_chan *dma_request_chan_by_mask(const dma_cap_mask_t *mask);
>
> The dma_request_chan_by_mask() is to request any channel matching with the
> requested capabilities, can be used to request channel for memcpy, memset, 
> xor,
> etc where no hardware synchronization is needed.
>
> The dma_request_chan() is to request a slave channel. The dma_request_chan() 
> will try to find the
> channel via DT, ACPI or in case if the kernel booted in non DT/ACPI mode
> it will use a filter lookup table and retrieves the needed information from
> the dma_filter_map provided by the DMA drivers.
> This legacy mode needs changes in platform code, in dmaengine drivers and
> finally the dmaengine user drivers can be converted:
>
> For each dmaengine driver an array of DMA device, slave and the parameter
> for the filter function needs to be added:
>
> static const struct dma_filter_map da830_edma_map[] = {
> { "davinci-mcasp.0", "rx", EDMA_FILTER_PARAM(0, 0) },
> { "davinci-mcasp.0", "tx", EDMA_FILTER_PARAM(0, 1) },
> { "davinci-mcasp.1", "rx", EDMA_FILTER_PARAM(0, 2) },
> { "davinci-mcasp.1", "tx", EDMA_FILTER_PARAM(0, 3) },
> { "davinci-mcasp.2", "rx", EDMA_FILTER_PARAM(0, 4) },
> { "davinci-mcasp.2", "tx", EDMA_FILTER_PARAM(0, 5) },
> { "spi_davinci.0", "rx", EDMA_FILTER_PARAM(0, 14) },
> { "spi_davinci.0", "tx", EDMA_FILTER_PARAM(0, 15) },
> { "da830-mmc.0", "rx", EDMA_FILTER_PARAM(0, 16) },
> { "da830-mmc.0", "tx", EDMA_FILTER_PARAM(0, 17) },
> { "spi_davinci.1", "rx", EDMA_FILTER_PARAM(0, 18) },
> { "spi_davinci.1", "tx", EDMA_FILTER_PARAM(0, 19) },
> };
>
> This information is going to be needed by the dmaengine driver, so
> modification to the platform_data is needed, and the driver map should be
> added to the pdata of the DMA driver:
>
> da8xx_edma0_pdata.slave_map = da830_edma_map;
> da8xx_edma0_pdata.slavecnt = ARRAY_SIZE(da830_edma_map);
>
> The DMA driver then needs to configure the needed device -> filter_fn
> mapping before it registers with dma_async_device_register() :
>
> if (info->slave_map) {
> ecc->dma_slave.filter_map.map = info->slave_map;
> ecc->dma_slave.filter_map.mapcnt = info->slavecnt;
> ecc->dma_slave.filter_map.filter_fn = edma_filter_fn;
> }
>
> When neither DT or ACPI lookup is available the dma_request_chan() will
> try to match the requester's device name with the filter_map's list of
> device names, when a match found it will use the information from the
> dma_filter_map to get the channel with the dma_get_channel() internal
> function.
>

I like patches 1 & 2 in current shape.
Though few comments to patch 3.

> Regards,
> Peter
> ---
> Peter Ujfalusi (15):
>   dmaengine: core: Skip mask matching when it is not provided to
> private_candidate
>   dmaengine: core: Move and merge the code paths using private_candidate
>   dmaengine: core: Introduce new, universal API to request a channel
>   dmaengine: edma: Add support for DMA filter mapping to slave devices
>   

Re: [RFC v03 03/15] dmaengine: core: Introduce new, universal API to request a channel

[Andy Shevchenko]

On Wed, Dec 2, 2015 at 3:59 PM, Peter Ujfalusi  wrote:
> The two API function can cover most, if not all current APIs used to
> request a channel. With minimal effort dmaengine drivers, platforms and
> dmaengine user drivers can be converted to use the two function.
>
> struct dma_chan *dma_request_chan_by_mask(const dma_cap_mask_t *mask);
>
> To request any channel matching with the requested capabilities, can be
> used to request channel for memcpy, memset, xor, etc where no hardware
> synchronization is needed.
>
> struct dma_chan *dma_request_chan(struct device *dev, const char *name);
> To request a slave channel. The dma_request_chan() will try to find the
> channel via DT, ACPI or in case if the kernel booted in non DT/ACPI mode
> it will use a filter lookup table and retrieves the needed information from
> the dma_filter_map provided by the DMA drivers.
> This legacy mode needs changes in platform code, in dmaengine drivers and
> finally the dmaengine user drivers can be converted:
>
> For each dmaengine driver an array of DMA device, slave and the parameter
> for the filter function needs to be added:
>
> static const struct dma_filter_map da830_edma_map[] = {
> { "davinci-mcasp.0", "rx", EDMA_FILTER_PARAM(0, 0) },
> { "davinci-mcasp.0", "tx", EDMA_FILTER_PARAM(0, 1) },
> { "davinci-mcasp.1", "rx", EDMA_FILTER_PARAM(0, 2) },
> { "davinci-mcasp.1", "tx", EDMA_FILTER_PARAM(0, 3) },
> { "davinci-mcasp.2", "rx", EDMA_FILTER_PARAM(0, 4) },
> { "davinci-mcasp.2", "tx", EDMA_FILTER_PARAM(0, 5) },
> { "spi_davinci.0", "rx", EDMA_FILTER_PARAM(0, 14) },
> { "spi_davinci.0", "tx", EDMA_FILTER_PARAM(0, 15) },
> { "da830-mmc.0", "rx", EDMA_FILTER_PARAM(0, 16) },
> { "da830-mmc.0", "tx", EDMA_FILTER_PARAM(0, 17) },
> { "spi_davinci.1", "rx", EDMA_FILTER_PARAM(0, 18) },
> { "spi_davinci.1", "tx", EDMA_FILTER_PARAM(0, 19) },
> };
>
> This information is going to be needed by the dmaengine driver, so
> modification to the platform_data is needed, and the driver map should be
> added to the pdata of the DMA driver:
>
> da8xx_edma0_pdata.slave_map = da830_edma_map;
> da8xx_edma0_pdata.slavecnt = ARRAY_SIZE(da830_edma_map);
>
> The DMA driver then needs to configure the needed device -> filter_fn
> mapping before it registers with dma_async_device_register() :
>
> if (info->slave_map) {
> ecc->dma_slave.filter_map.map = info->slave_map;
> ecc->dma_slave.filter_map.mapcnt = info->slavecnt;
> ecc->dma_slave.filter_map.filter_fn = edma_filter_fn;
> }
>
> When neither DT or ACPI lookup is available the dma_request_chan() will
> try to match the requester's device name with the filter_map's list of
> device names, when a match found it will use the information from the
> dma_filter_map to get the channel with the dma_get_channel() internal
> function.
>

Few nitpicks below.

> Signed-off-by: Peter Ujfalusi 
> ---
>  Documentation/dmaengine/client.txt | 23 +++--
>  drivers/dma/dmaengine.c| 98 
> ++
>  include/linux/dmaengine.h  | 27 +++
>  3 files changed, 131 insertions(+), 17 deletions(-)
>
> diff --git a/Documentation/dmaengine/client.txt 
> b/Documentation/dmaengine/client.txt
> index d9f9f461102a..6c72a06eb1a5 100644
> --- a/Documentation/dmaengine/client.txt
> +++ b/Documentation/dmaengine/client.txt
> @@ -22,25 +22,14 @@ The slave DMA usage consists of following steps:
> Channel allocation is slightly different in the slave DMA context,
> client drivers typically need a channel from a particular DMA
> controller only and even in some cases a specific channel is desired.
> -   To request a channel dma_request_channel() API is used.
> +   To request a channel dma_request_chan() API is used.
>
> Interface:
> -   struct dma_chan *dma_request_channel(dma_cap_mask_t mask,
> -   dma_filter_fn filter_fn,
> -   void *filter_param);
> -   where dma_filter_fn is defined as:
> -   typedef bool (*dma_filter_fn)(struct dma_chan *chan, void 
> *filter_param);
> -
> -   The 'filter_fn' parameter is optional, but highly recommended for
> -   slave and cyclic channels as they typically need to obtain a specific
> -   DMA channel.
> -
> -   When the optional 'filter_fn' parameter is NULL, dma_request_channel()
> -   simply returns the first channel that satisfies the capability mask.
> -
> -   Otherwise, the 'filter_fn' routine will be called once for each free
> -   channel which has a capability in 'mask'.  'filter_fn' is expected to
> -   return 'true' when the desired DMA channel is found.
> +   struct dma_chan *dma_request_chan(struct device *dev, const char 
> *name);
> +
> +   Which will find and return the 'name' DMA channel associated with the 
> 'dev'
> +   device. The association is done via DT, ACPI or board file based
> +   

Re: [PATCH 10/10] ARM: dts: Fix dm814x pinctrl address and mask

[Tony Lindgren]

* Tony Lindgren  [151201 17:23]:
> * Matthijs van Duin  [151201 17:15]:
> > On 2 December 2015 at 01:46, Tony Lindgren  wrote:
> > > Ouch. We should probably have separate PIN_INPUT_3V3 and PIN_OUTPUT_3V3
> > > dts macros that ensure that?
> > 
> > Can't we just keep bit 18 out of the function mask? The bootloader
> > should already have made sure all pins have bit 18 set (and bit 19 set
> > to correct values after ROM mucked them up, see advisory 2.1.88), so
> > all that needs to be done is avoid touching them.
> 
> Sounds good to me. And people who really want to override the mask can
> do it in the board specifc dts file.
> 
> > Are the power savings from disabling unnecessary inputs significant
> > enough to spend any headache on it?
> 
> Only for some battery powered devices, not in this case for sure.

And here's an updated version of this patch.

Regards,

Tony

8< 
From: Tony Lindgren 
Date: Tue, 1 Dec 2015 15:04:38 -0800
Subject: [PATCH] ARM: dts: Fix dm814x pinctrl address and mask

Otherwise pinctrl won't work. Because of silicon errata for some dm814x
versions, let's also keep bit 18 out of the function-mask and rely on
the bootloader configuration for bit 18  as suggested by
Matthijs van Duin .

Devices with that need to use bit 18 can override the function-mask in
the board specific dts file if really needed.

Signed-off-by: Tony Lindgren 

--- a/arch/arm/boot/dts/dm814x.dtsi
+++ b/arch/arm/boot/dts/dm814x.dtsi
@@ -205,13 +205,21 @@
};
};
 
+   /*
+* Note that silicon revision 2.1 and older
+* require input enabled (bit 18 set) for all
+* 3.3V I/Os to avoid cumulative hardware 
damage.
+* For more info, see errata advisory 2.1.87.
+* We leave bit 18 out of function-mask and rely
+* on the bootloader for it.
+*/
pincntl: pinmux@800 {
compatible = "pinctrl-single";
-   reg = <0x800 0xc38>;
+   reg = <0x800 0x438>;
#address-cells = <1>;
#size-cells = <0>;
pinctrl-single,register-width = <32>;
-   pinctrl-single,function-mask = 
<0x300ff>;
+   pinctrl-single,function-mask = 
<0x307ff>;
};
};
 
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 10/10] ARM: dts: Fix dm814x pinctrl address and mask

[Tony Lindgren]

* Matthijs van Duin  [151201 17:23]:
> On 2 December 2015 at 01:46, Tony Lindgren  wrote:
> > We should probably have separate PIN_INPUT_3V3 and PIN_OUTPUT_3V3
> > dts macros that ensure that?
> 
> I'm in general no fan of such macros: it feels really awkward to have
> to make that distinction in dts when doing pin config.
> 
> Note that if you're feeling really enthausiastic about putting in
> effort to allow inputs to be disabled while staying clear of the
> erratum, I think you can detect at runtime which I/O supplies are 3.3V
> by inspecting this register:
> 
> #define CTRL_CQDETECT_STATUS0x48140e00

OK and if really needed needed the SoC revision information can be
passed to pinctrl-singl.c in it's platform_data that we already have
in addition to the dts configuration. And then pinctrl-single.c could
modify the mask based on IO voltage and SoC revision.

I think we're already covered as the boards can override the pinctrl
function-mask in the board specific dts file if really needed :)

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 00/27] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms

[Brian Norris]

On Wed, Dec 02, 2015 at 07:03:17AM -0800, Tony Lindgren wrote:
> * Roger Quadros  [151201 21:13]:
> > On 02/12/15 08:56, Brian Norris wrote:
> > > 
> > > I'll take another pass over your patch set, but if things are looking
> > > better, how do you expect to merge this? There are significant portions
> > > that touch at least 2 or 3 different subsystem trees, AFAICT.
> > 
> > Tony could create an immutable branch with all the dts and memory changes.
> > You could base the mtd changes on top of that?
> 
> If we all agree on that it will be immutable Roger can set up the branch
> with our acks and we can all merge it in as needed. I believe v4.4-rc1
> should work as a base for us all?

There are oustanding comments about the NAND ready/busy GPIO naming in
patch 18, which I'd like addressed. I'll re-review the rest before the
end of the day (West Coast U.S.A.). I'm not sure my acks are worth much
beyond the MTD stuff.

Regarding branches, 4.4-rc1 is fine with me.

Regards,
Brian
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 00/27] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms

[Brian Norris]

Hi Roger,

On Wed, Dec 02, 2015 at 10:42:12AM +0530, Roger Quadros wrote:
> On 02/12/15 08:56, Brian Norris wrote:
> > On Tue, Dec 01, 2015 at 04:41:16PM +0200, Roger Quadros wrote:
> >> On 30/11/15 21:54, Brian Norris wrote:
> >>> But anyway, I'm not sure that completely answered my question. My
> >>> question was whether you were removing the irqchip code solely for
> >>> performance reasons, or are there others?
> >>
> >> Yes. Only for performance reasons.
> > 
> > Hmm, that's not my favorite answer. I'd prefer that more analysis was
> > done here before scrapping irqchip...
> 
> I agree. We could retain the irqchip model till we have more satisfying
> analysis.

I won't insist, though if it's not too ugly/horrible to do so, I think
that would make sense. I'll leave it as your call.

Brian
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 00/27] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms

[Tony Lindgren]

* Brian Norris  [151202 10:14]:
> On Wed, Dec 02, 2015 at 07:03:17AM -0800, Tony Lindgren wrote:
> > * Roger Quadros  [151201 21:13]:
> > > On 02/12/15 08:56, Brian Norris wrote:
> > > > 
> > > > I'll take another pass over your patch set, but if things are looking
> > > > better, how do you expect to merge this? There are significant portions
> > > > that touch at least 2 or 3 different subsystem trees, AFAICT.
> > > 
> > > Tony could create an immutable branch with all the dts and memory changes.
> > > You could base the mtd changes on top of that?
> > 
> > If we all agree on that it will be immutable Roger can set up the branch
> > with our acks and we can all merge it in as needed. I believe v4.4-rc1
> > should work as a base for us all?
> 
> There are oustanding comments about the NAND ready/busy GPIO naming in
> patch 18, which I'd like addressed. I'll re-review the rest before the
> end of the day (West Coast U.S.A.). I'm not sure my acks are worth much
> beyond the MTD stuff.

OK, I'm happy with the gpmc related parts.

> Regarding branches, 4.4-rc1 is fine with me.

OK

Thanks,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 1/5] spi: introduce accelerated read support for spi flash devices

[Mark Brown]

On Mon, Nov 30, 2015 at 10:45:11AM +0530, Vignesh R wrote:
> In addition to providing direct access to SPI bus, some spi controller
> hardwares (like ti-qspi) provide special port (like memory mapped port)
> that are optimized to improve SPI flash read performance.

I'm reasonably OK with this from the SPI side but I'd really like to see
people working on MTD say that this makes sense.


signature.asc
Description: PGP signature

Re: [PATCH v3 0/3] soc: ti: Introduce wkup_m3_ipc driver

[Dave Gerlach]

Hi,
On 10/20/2015 11:18 AM, Tony Lindgren wrote:

Hi all,

* Dave Gerlach  [150922 17:20]:

Hi,
This series is version 3 of the code to introduce a wkup_m3_ipc driver
to handle communication between the MPU and Cortex M3 present on TI AM335x
and AM437x SoCs. v2 of this series can be found at [1]. Only patch 3
has been changed based on a request from Tony and a few cleanups:

- Rather than exporting all of the functionality of the driver, added
   wkup_m3_ipc_get and wkup_m3_ipc_put to allow users to just get a handle
   containing an ops structure for use.

- Changed all ops (previously exported functions) to take pointer to
   struct wkup_m3_ipc as an argument now that user code will get this
   from wkup_m3_ipc_get.

- General cleanup to probe function

- Added MODULE_DEVICE_TABLE so driver can probe automatically.

The series containing the DT nodes can be found here [2]. The actual dt
nodes for wkup_m3_ipc (last two patches) have been merged but discussion
is still open for the ti,mbox-send-noirq flag patches and depends on the
comments provided for the omap-mailbox change presented in patch 1 of
this series.

A full branch containing all necessary PM code for both am335x and am437x
has been pushed here [3] to provide a big picture view of the plan for
this series.

This driver relies on the firmware at [4] in the next-upstream branch
being present in /lib/firmware in the rootfs or built in to the kernel.


Anybody got comments on this one? Should I pick up this series or
what's the plan?


Now that Patch 1 has been merged [1] can patch 2 and 3 be picked up? 
These apply cleanly on v4.4-rc3.


Regards,
Dave

[1] 
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=8e3c5952144f045a0c81bf674d3f5e1d9aafceb7




Regards,

Tony



[1] https://lkml.org/lkml/2015/7/17/797
[2] https://lkml.org/lkml/2015/7/17/813
[3] https://github.com/dgerlach/linux-pm/tree/pm-v4.3-rc1-amx3-suspend
[4] https://git.ti.com/ti-cm3-pm-firmware

Dave Gerlach (3):
   mailbox/omap: Add ti,mbox-send-noirq quirk to fix AM33xx CPU Idle
   Documentation: dt: add bindings for TI Wakeup M3 IPC device
   soc: ti: Add wkup_m3_ipc driver

  .../devicetree/bindings/mailbox/omap-mailbox.txt   |   8 +
  .../devicetree/bindings/soc/ti/wkup_m3_ipc.txt |  57 +++
  drivers/mailbox/omap-mailbox.c |  49 +-
  drivers/soc/ti/Kconfig |  10 +
  drivers/soc/ti/Makefile|   1 +
  drivers/soc/ti/wkup_m3_ipc.c   | 508 +
  include/linux/wkup_m3_ipc.h|  55 +++
  7 files changed, 684 insertions(+), 4 deletions(-)
  create mode 100644 Documentation/devicetree/bindings/soc/ti/wkup_m3_ipc.txt
  create mode 100644 drivers/soc/ti/wkup_m3_ipc.c
  create mode 100644 include/linux/wkup_m3_ipc.h

--
2.4.6



--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC v02 00/15] dmaengine: New 'universal' API for requesting channel

[Arnd Bergmann]

On Wednesday 02 December 2015 10:22:09 Vinod Koul wrote:
> > 
> > > > This legacy mode needs changes in platform code, in dmaengine drivers 
> > > > and
> > > > finally the dmaengine user drivers can be converted:
> > > 
> > > Are you marking the current APIs as dericated in the end of this series
> > 
> > I think we practically stopped marking things as deprecated in general.
> > Per Linus decree, whenever we want to get rid of something, we should
> > instead change all users in tree and then remove the API, expecting
> > driver maintainers to do something just because you marked it as deprecated
> > often doesn't work.
> 
> Yes but while we do conversion we don't know if new users get added which use
> old API..

We probably don't need to worry about new users of dma_request_channel(),
as we don't add new ARM platforms without DT, and other architectures
don't add a lot of new platforms. Similarly, I don't expect a whole lot
of dma_request_slave_channel_compat() users, because the conversion from
board files to DT based booting has slowed down a lot after most of the
actively maintained platforms are done with it.

If you do a one-line patch to add dma_request_chan() as an alias for
dma_request_slave_channel_reason() now, we can probably convert most
users of dma_request_slave_channel() and dma_request_slave_channel_reason()
to dma_request_chan() in the next merge window and do a patch to
replace the few remaining ones and remove the API one merge window later.

If wewant to stage out the conversion of the
dma_request_slave_channel_compat() and dma_request_channel() similarly,
it would be good to have all the interface changes for the dmaengine
core basically in place, so we can start to convert the platforms
independently for the 4.5 merge window without having a dependency on
dmaengine patches. It's probably best to not convert a slave driver
away from dma_request_channel() until the dma map has been created
for all platforms using that driver, again to avoid having too many
dependencies.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 17/25] mtd: nand: remove useless mtd->priv = chip assignments

[Boris Brezillon]

mtd_to_nand() now uses the container_of() approach to transform an
mtd_info pointer into a nand_chip one. Drop useless mtd->priv
assignments from NAND controller drivers.

Signed-off-by: Boris Brezillon 
---
Patch generated with the following coccinelle script:

---8<
virtual patch

@@
struct mtd_info m;
struct mtd_info *mp;
struct nand_chip *c;
@@
(
-(m).priv = c;
|
-(mp)->priv = c;
|
-(mp)->priv = (void *)c;
)
---8<
---
Changes since v2:
- fixes a compilation warning

 drivers/mtd/nand/ams-delta.c   | 3 ---
 drivers/mtd/nand/atmel_nand.c  | 1 -
 drivers/mtd/nand/au1550nd.c| 1 -
 drivers/mtd/nand/bcm47xxnflash/main.c  | 1 -
 drivers/mtd/nand/bf5xx_nand.c  | 1 -
 drivers/mtd/nand/brcmnand/brcmnand.c   | 1 -
 drivers/mtd/nand/cafe_nand.c   | 1 -
 drivers/mtd/nand/cmx270_nand.c | 1 -
 drivers/mtd/nand/cs553x_nand.c | 1 -
 drivers/mtd/nand/davinci_nand.c| 1 -
 drivers/mtd/nand/denali.c  | 1 -
 drivers/mtd/nand/diskonchip.c  | 1 -
 drivers/mtd/nand/docg4.c   | 1 -
 drivers/mtd/nand/fsl_elbc_nand.c   | 1 -
 drivers/mtd/nand/fsl_ifc_nand.c| 1 -
 drivers/mtd/nand/fsl_upm.c | 1 -
 drivers/mtd/nand/fsmc_nand.c   | 1 -
 drivers/mtd/nand/gpio.c| 1 -
 drivers/mtd/nand/gpmi-nand/gpmi-nand.c | 1 -
 drivers/mtd/nand/hisi504_nand.c| 1 -
 drivers/mtd/nand/jz4740_nand.c | 1 -
 drivers/mtd/nand/lpc32xx_mlc.c | 1 -
 drivers/mtd/nand/lpc32xx_slc.c | 1 -
 drivers/mtd/nand/mpc5121_nfc.c | 1 -
 drivers/mtd/nand/mxc_nand.c| 1 -
 drivers/mtd/nand/nandsim.c | 1 -
 drivers/mtd/nand/ndfc.c| 1 -
 drivers/mtd/nand/nuc900_nand.c | 1 -
 drivers/mtd/nand/omap2.c   | 1 -
 drivers/mtd/nand/orion_nand.c  | 1 -
 drivers/mtd/nand/pasemi_nand.c | 1 -
 drivers/mtd/nand/plat_nand.c   | 1 -
 drivers/mtd/nand/pxa3xx_nand.c | 1 -
 drivers/mtd/nand/r852.c| 1 -
 drivers/mtd/nand/s3c2410.c | 2 --
 drivers/mtd/nand/sh_flctl.c| 1 -
 drivers/mtd/nand/sharpsl.c | 1 -
 drivers/mtd/nand/socrates_nand.c   | 1 -
 drivers/mtd/nand/sunxi_nand.c  | 1 -
 drivers/mtd/nand/tmio_nand.c   | 1 -
 drivers/mtd/nand/txx9ndfmc.c   | 2 --
 drivers/mtd/nand/vf610_nfc.c   | 1 -
 42 files changed, 46 deletions(-)

diff --git a/drivers/mtd/nand/ams-delta.c b/drivers/mtd/nand/ams-delta.c
index 0f638c6..1a18938 100644
--- a/drivers/mtd/nand/ams-delta.c
+++ b/drivers/mtd/nand/ams-delta.c
@@ -193,9 +193,6 @@ static int ams_delta_init(struct platform_device *pdev)
ams_delta_mtd = nand_to_mtd(this);
ams_delta_mtd->owner = THIS_MODULE;
 
-   /* Link the private data with the MTD structure */
-   ams_delta_mtd->priv = this;
-
/*
 * Don't try to request the memory region from here,
 * it should have been already requested from the
diff --git a/drivers/mtd/nand/atmel_nand.c b/drivers/mtd/nand/atmel_nand.c
index 9ba2831..18c4e14 100644
--- a/drivers/mtd/nand/atmel_nand.c
+++ b/drivers/mtd/nand/atmel_nand.c
@@ -2128,7 +2128,6 @@ static int atmel_nand_probe(struct platform_device *pdev)
}
 
nand_chip->priv = host; /* link the private data structures */
-   mtd->priv = nand_chip;
mtd->dev.parent = >dev;
 
/* Set address of NAND IO lines */
diff --git a/drivers/mtd/nand/au1550nd.c b/drivers/mtd/nand/au1550nd.c
index 280e5b6..341ea49 100644
--- a/drivers/mtd/nand/au1550nd.c
+++ b/drivers/mtd/nand/au1550nd.c
@@ -441,7 +441,6 @@ static int au1550nd_probe(struct platform_device *pdev)
 
this = >chip;
mtd = nand_to_mtd(this);
-   mtd->priv = this;
mtd->dev.parent = >dev;
 
/* figure out which CS# r->start belongs to */
diff --git a/drivers/mtd/nand/bcm47xxnflash/main.c 
b/drivers/mtd/nand/bcm47xxnflash/main.c
index 4711ca2b..0f0a798 100644
--- a/drivers/mtd/nand/bcm47xxnflash/main.c
+++ b/drivers/mtd/nand/bcm47xxnflash/main.c
@@ -37,7 +37,6 @@ static int bcm47xxnflash_probe(struct platform_device *pdev)
b47n->nand_chip.priv = b47n;
mtd = nand_to_mtd(>nand_chip);
mtd->dev.parent = >dev;
-   mtd->priv = >nand_chip; /* Required */
b47n->cc = container_of(nflash, struct bcma_drv_cc, nflash);
 
if (b47n->cc->core->bus->chipinfo.id == BCMA_CHIP_ID_BCM4706) {
diff --git a/drivers/mtd/nand/bf5xx_nand.c b/drivers/mtd/nand/bf5xx_nand.c
index 928d599..9514e13 100644
--- a/drivers/mtd/nand/bf5xx_nand.c
+++ b/drivers/mtd/nand/bf5xx_nand.c
@@ -782,7 +782,6 @@ static int bf5xx_nand_probe(struct platform_device *pdev)
chip->chip_delay   = 0;
 
/* initialise mtd info data struct */
-   mtd->priv   = chip;
mtd->dev.parent = >dev;
 
/* initialise the hardware */
diff --git 

Re: [PATCH v2 17/25] mtd: nand: remove useless mtd->priv = chip assignments

[Boris Brezillon]

Hi Brian,

On Tue, 1 Dec 2015 14:17:47 -0800
Brian Norris  wrote:

> On Tue, Dec 01, 2015 at 12:03:14PM +0100, Boris Brezillon wrote:
> > mtd_to_nand() now uses the container_of() approach to transform an
> > mtd_info pointer into a nand_chip one. Drop useless mtd->priv
> > assignments from NAND controller drivers.
> > 
> > Signed-off-by: Boris Brezillon 
> > ---
> > Patch generated with the following coccinelle script:
> > 
> > ---8<
> > virtual patch
> > 
> > @@
> > struct mtd_info m;
> > struct mtd_info *mp;
> > struct nand_chip *c;
> > @@
> > (
> > -(m).priv = c;
> > |
> > -(mp)->priv = c;
> > |
> > -(mp)->priv = (void *)c;
> > )
> > ---8<
> > ---
> 
> ...
> 
> > diff --git a/drivers/mtd/nand/s3c2410.c b/drivers/mtd/nand/s3c2410.c
> > index 3f29734..ed4184c 100644
> > --- a/drivers/mtd/nand/s3c2410.c
> > +++ b/drivers/mtd/nand/s3c2410.c
> > @@ -834,7 +834,6 @@ static void s3c2410_nand_init_chip(struct 
> > s3c2410_nand_info *info,
> > chip->IO_ADDR_R = chip->IO_ADDR_W;
> >  
> > nmtd->info = info;
> > -   mtd->priv  = chip;
> 
> After this one, we have:
> 
> drivers/mtd/nand/s3c2410.c: In function ‘s3c2410_nand_init_chip’:
> drivers/mtd/nand/s3c2410.c:791:19: warning: unused variable ‘mtd’ 
> [-Wunused-variable]

I fixed all the warnings/errors you pointed in patch 12 and 17 and
resent a v3 only for those patches to avoid annoying all recipients
again. Let me know if you want me to resend the whole patchset.

Best Regards,

Boris

-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 11/27] mtd: nand: omap: Clean up device tree support

[Brian Norris]

Hi Roger,

On Tue, Oct 06, 2015 at 01:35:48PM +0300, Roger Quadros wrote:
> Move NAND specific device tree parsing to NAND driver.
> 
> The NAND controller node must have a compatible id, register space
> resource and interrupt resource.
> 
> Signed-off-by: Roger Quadros 

This one's going to need rebased, as there are some conflicting of_node
changes in l2-mtd.git.

> ---
> v4: Warn if using older incompatible DT i.e. compatible property not present
> in nand node.
> 
>  arch/arm/mach-omap2/gpmc-nand.c  |   5 +-
>  drivers/memory/omap-gpmc.c   | 143 
> +++
>  drivers/mtd/nand/omap2.c | 136 +
>  include/linux/platform_data/mtd-nand-omap2.h |   3 +-
>  4 files changed, 155 insertions(+), 132 deletions(-)

Also, this is going to be hard to manage across trees, as you touch
three drivers all at once. Is it not possible to split any of this apart
better?

> 
> diff --git a/arch/arm/mach-omap2/gpmc-nand.c b/arch/arm/mach-omap2/gpmc-nand.c
> index ffe646a..e07ca27 100644
> --- a/arch/arm/mach-omap2/gpmc-nand.c
> +++ b/arch/arm/mach-omap2/gpmc-nand.c
> @@ -95,10 +95,7 @@ int gpmc_nand_init(struct omap_nand_platform_data 
> *gpmc_nand_data,
>   gpmc_nand_res[1].start = gpmc_get_irq();
>  
>   memset(, 0, sizeof(struct gpmc_settings));
> - if (gpmc_nand_data->of_node)
> - gpmc_read_settings_dt(gpmc_nand_data->of_node, );
> - else
> - gpmc_set_legacy(gpmc_nand_data, );
> + gpmc_set_legacy(gpmc_nand_data, );
>  
>   s.device_nand = true;
>  
> diff --git a/drivers/memory/omap-gpmc.c b/drivers/memory/omap-gpmc.c
> index e75226d..318c187 100644
> --- a/drivers/memory/omap-gpmc.c
> +++ b/drivers/memory/omap-gpmc.c
> @@ -29,7 +29,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  
>  #include 
> @@ -1716,105 +1715,6 @@ static void __maybe_unused 
> gpmc_read_timings_dt(struct device_node *np,
>   of_property_read_bool(np, "gpmc,time-para-granularity");
>  }
>  
> -#if IS_ENABLED(CONFIG_MTD_NAND)
> -
> -static const char * const nand_xfer_types[] = {
> - [NAND_OMAP_PREFETCH_POLLED] = "prefetch-polled",
> - [NAND_OMAP_POLLED]  = "polled",
> - [NAND_OMAP_PREFETCH_DMA]= "prefetch-dma",
> - [NAND_OMAP_PREFETCH_IRQ]= "prefetch-irq",
> -};
> -
> -static int gpmc_probe_nand_child(struct platform_device *pdev,
> -  struct device_node *child)
> -{
> - u32 val;
> - const char *s;
> - struct gpmc_timings gpmc_t;
> - struct omap_nand_platform_data *gpmc_nand_data;
> -
> - if (of_property_read_u32(child, "reg", ) < 0) {
> - dev_err(>dev, "%s has no 'reg' property\n",
> - child->full_name);
> - return -ENODEV;
> - }
> -
> - gpmc_nand_data = devm_kzalloc(>dev, sizeof(*gpmc_nand_data),
> -   GFP_KERNEL);
> - if (!gpmc_nand_data)
> - return -ENOMEM;
> -
> - gpmc_nand_data->cs = val;
> - gpmc_nand_data->of_node = child;
> -
> - /* Detect availability of ELM module */
> - gpmc_nand_data->elm_of_node = of_parse_phandle(child, "ti,elm-id", 0);
> - if (gpmc_nand_data->elm_of_node == NULL)
> - gpmc_nand_data->elm_of_node =
> - of_parse_phandle(child, "elm_id", 0);
> -
> - /* select ecc-scheme for NAND */
> - if (of_property_read_string(child, "ti,nand-ecc-opt", )) {
> - pr_err("%s: ti,nand-ecc-opt not found\n", __func__);
> - return -ENODEV;
> - }
> -
> - if (!strcmp(s, "sw"))
> - gpmc_nand_data->ecc_opt = OMAP_ECC_HAM1_CODE_SW;
> - else if (!strcmp(s, "ham1") ||
> -  !strcmp(s, "hw") || !strcmp(s, "hw-romcode"))
> - gpmc_nand_data->ecc_opt =
> - OMAP_ECC_HAM1_CODE_HW;
> - else if (!strcmp(s, "bch4"))
> - if (gpmc_nand_data->elm_of_node)
> - gpmc_nand_data->ecc_opt =
> - OMAP_ECC_BCH4_CODE_HW;
> - else
> - gpmc_nand_data->ecc_opt =
> - OMAP_ECC_BCH4_CODE_HW_DETECTION_SW;
> - else if (!strcmp(s, "bch8"))
> - if (gpmc_nand_data->elm_of_node)
> - gpmc_nand_data->ecc_opt =
> - OMAP_ECC_BCH8_CODE_HW;
> - else
> - gpmc_nand_data->ecc_opt =
> - OMAP_ECC_BCH8_CODE_HW_DETECTION_SW;
> - else if (!strcmp(s, "bch16"))
> - if (gpmc_nand_data->elm_of_node)
> - gpmc_nand_data->ecc_opt =
> - OMAP_ECC_BCH16_CODE_HW;
> - else
> - pr_err("%s: BCH16 requires ELM support\n", __func__);
> - else
> - pr_err("%s: ti,nand-ecc-opt 

Re: [PATCH v3 00/27] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms

[Roger Quadros]

Brian,

On 03/12/15 10:39, Brian Norris wrote:
> Hi,
> 
> On Fri, Sep 18, 2015 at 05:53:22PM +0300, Roger Quadros wrote:
>> Hi,
>>
>> We do a couple of things in this series which result in
>> cleaner device tree implementation, faster perfomance and
>> multi-platform support. As an added bonus we get new GPI/Interrupt pins
>> for use in the system.
>>
>> - Establish a custom interface between NAND and GPMC driver. This is
>> needed because all of the NAND registers sit in the GPMC register space.
>> Some bits like NAND IRQ are even shared with GPMC.
>>
>> - Remove NAND IRQ handling from omap-gpmc driver, share the GPMC IRQ
>> with the omap2-nand driver and handle NAND IRQ events in the NAND driver.
>> This causes performance increase when using prefetch-irq mode.
>> 30% increase in read, 17% increase in write in prefetch-irq mode.
>>
>> - Clean up device tree support so that omap-gpmc IP and the omap2 NAND
>> driver can be used on non-OMAP platforms. e.g. Keystone.
>>
>> - Implement GPIOCHIP + IRQCHIP for the GPMC WAITPINS. SoCs can contain
>> 2 to 4 of these and most of them would be unused otherwise. It also
>> allows a cleaner implementation of NAND Ready pin status for the NAND driver.
>>
>> - Implement GPIOlib based NAND ready pin checking for OMAP NAND driver.
>>
>> This series is available at
>> g...@github.com:rogerq/linux.git
>> in branch
>> for-v4.4/gpmc-v3
>>
>> cheers,
>> -roger
>>
>> Changelog:
>> v3:
>> -Fixed and tested NAND using legacy boot on omap3-beagle.
>> -Support rising and falling edge interrupts on WAITpins.
>> -Update DT node of all gpmc users.
> 
> The MTD stuff looks mostly good to me know. I've made all my comments
> for now, but I'm not sure how you're going to end up rebasing/splitting
> and what you're going to do with the irqchip removal, so I'll refrain
> from ack's for now. Hopefully I can either ack or merge v4.

I'll retain the irqchip model for now and send a v4 with all comments
addressed and better subsystem wise patch split.

> 
> I brought it up on one other patch, but it's not really clear to me what
> the split is on board file vs. device tree handling, since you seem to
> have a combination of both (i.e., platform data that passes along device
> nodes). What's the plan on that?

Platform data no longer passes device nodes. We're either true device tree
or plain legacy. The deprecated fields are no longer used once the series is
applied.

> 
> And of course, there's the question of how exactly to merge this, given
> the:
> (1) conflicts already existing in the MTD dev tree

I'll rebase the series on top of MTD dev tree.

> (2) this touches several trees, often in the same patch and

I'll try my best to split the patches but not sure if this could be 100%
clean split without functional breakage.

> (3) even if the patches were split out a little better into MTD and
> non-MTD stuff, I think there would still be dependencies such that
> we'd need at least 1 (probably 2) cross merges to get it all
> straight

That is correct.
Is it OK if functionality breaks if for example only MTD changes are considered?

cheers,
-roger
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 11/27] mtd: nand: omap: Clean up device tree support

[Brian Norris]

On Thu, Dec 03, 2015 at 11:27:13AM +0530, Roger Quadros wrote:
> On 03/12/15 09:59, Brian Norris wrote:
> > On Tue, Oct 06, 2015 at 01:35:48PM +0300, Roger Quadros wrote:
> >>  arch/arm/mach-omap2/gpmc-nand.c  |   5 +-
> >>  drivers/memory/omap-gpmc.c   | 143 
> >> +++
> >>  drivers/mtd/nand/omap2.c | 136 
> >> +
> >>  include/linux/platform_data/mtd-nand-omap2.h |   3 +-
> >>  4 files changed, 155 insertions(+), 132 deletions(-)
> > 
> > Also, this is going to be hard to manage across trees, as you touch
> > three drivers all at once. Is it not possible to split any of this apart
> > better?
> 
> Will need some more effort and I can do it. Butm if we're going to start
> an with immutable branch with everything in, is it worth the effort?

I don't think I noticed the "everything in it" part. I was assuming
you'd have non-MTD changes in the immutable branch, and MTD stuff on
top. But that is indeed more difficult. I'm fine with everything going
in one branch, and pulling that all into MTD.

Then the hangup is that you'll need to have some of l2-mtd.git in that
branch as a prerequisite, if you're going to rebase. Or else I have to
fix it up when merging back into l2-mtd.git...

...

> >> diff --git a/include/linux/platform_data/mtd-nand-omap2.h 
> >> b/include/linux/platform_data/mtd-nand-omap2.h
> >> index a067f58..ff27e5a 100644
> >> --- a/include/linux/platform_data/mtd-nand-omap2.h
> >> +++ b/include/linux/platform_data/mtd-nand-omap2.h
> >> @@ -76,11 +76,10 @@ struct omap_nand_platform_data {
> >>int devsize;
> >>enum omap_ecc   ecc_opt;
> >>  
> >> -  /* for passing the partitions */
> >> -  struct device_node  *of_node;
> >>struct device_node  *elm_of_node;
> >>  
> >>/* deprecated */
> >>struct gpmc_nand_regs   reg;
> >> +  struct device_node  *of_node;
> > 
> > I'm a little confused here. Do you have a mixed platform data / device
> > tree setup here? That's odd. (It also seems if that was really
> > necessary, you could have the board file set pdev->dev.of_node before
> > registering it, then you don't need this field.) But really, if you're
> > partly using device tree, can't you just convert completely? Or is this
> > a two-phase process, and you're planning to convert omap2 to full device
> > tree?
> 
> The existing device tree implementation for omap2-nand was like this:
> omap-gpmc.c driver was creating a platform device for the nand device and
> passing the device node via platform data.
> 
> After this series we no longer do this and that's why of_node is marked
> deprecated in platform data. I might as well could just get rid of it
> but wasn't sure of how we're going to integrate the changes into the
> subsystem trees so just marked it deprecated.

Whoops, sorry I didn't read the "deprecated" header there this time. I
thought the movement was odd. *facepalm*

But yes, especially if we're putting everything in one branch, it'd be
more clear to simply kill off things instead of marking things
deprecated. It's especially confusing, since you're actually still using
the field.

Brian
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 00/27] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms

[Brian Norris]

Hi,

On Fri, Sep 18, 2015 at 05:53:22PM +0300, Roger Quadros wrote:
> Hi,
> 
> We do a couple of things in this series which result in
> cleaner device tree implementation, faster perfomance and
> multi-platform support. As an added bonus we get new GPI/Interrupt pins
> for use in the system.
> 
> - Establish a custom interface between NAND and GPMC driver. This is
> needed because all of the NAND registers sit in the GPMC register space.
> Some bits like NAND IRQ are even shared with GPMC.
> 
> - Remove NAND IRQ handling from omap-gpmc driver, share the GPMC IRQ
> with the omap2-nand driver and handle NAND IRQ events in the NAND driver.
> This causes performance increase when using prefetch-irq mode.
> 30% increase in read, 17% increase in write in prefetch-irq mode.
> 
> - Clean up device tree support so that omap-gpmc IP and the omap2 NAND
> driver can be used on non-OMAP platforms. e.g. Keystone.
> 
> - Implement GPIOCHIP + IRQCHIP for the GPMC WAITPINS. SoCs can contain
> 2 to 4 of these and most of them would be unused otherwise. It also
> allows a cleaner implementation of NAND Ready pin status for the NAND driver.
> 
> - Implement GPIOlib based NAND ready pin checking for OMAP NAND driver.
> 
> This series is available at
> g...@github.com:rogerq/linux.git
> in branch
> for-v4.4/gpmc-v3
> 
> cheers,
> -roger
> 
> Changelog:
> v3:
> -Fixed and tested NAND using legacy boot on omap3-beagle.
> -Support rising and falling edge interrupts on WAITpins.
> -Update DT node of all gpmc users.

The MTD stuff looks mostly good to me know. I've made all my comments
for now, but I'm not sure how you're going to end up rebasing/splitting
and what you're going to do with the irqchip removal, so I'll refrain
from ack's for now. Hopefully I can either ack or merge v4.

I brought it up on one other patch, but it's not really clear to me what
the split is on board file vs. device tree handling, since you seem to
have a combination of both (i.e., platform data that passes along device
nodes). What's the plan on that?

And of course, there's the question of how exactly to merge this, given
the:
(1) conflicts already existing in the MTD dev tree
(2) this touches several trees, often in the same patch and
(3) even if the patches were split out a little better into MTD and
non-MTD stuff, I think there would still be dependencies such that
we'd need at least 1 (probably 2) cross merges to get it all
straight

I'd be happy to hear your thoughts.

Brian
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 11/27] mtd: nand: omap: Clean up device tree support

[Roger Quadros]

Brian,

On 03/12/15 09:59, Brian Norris wrote:
> Hi Roger,
> 
> On Tue, Oct 06, 2015 at 01:35:48PM +0300, Roger Quadros wrote:
>> Move NAND specific device tree parsing to NAND driver.
>>
>> The NAND controller node must have a compatible id, register space
>> resource and interrupt resource.
>>
>> Signed-off-by: Roger Quadros 
> 
> This one's going to need rebased, as there are some conflicting of_node
> changes in l2-mtd.git.

Al right. I'll rebase on top of l2-mtd.git
> 
>> ---
>> v4: Warn if using older incompatible DT i.e. compatible property not present
>> in nand node.
>>
>>  arch/arm/mach-omap2/gpmc-nand.c  |   5 +-
>>  drivers/memory/omap-gpmc.c   | 143 
>> +++
>>  drivers/mtd/nand/omap2.c | 136 +
>>  include/linux/platform_data/mtd-nand-omap2.h |   3 +-
>>  4 files changed, 155 insertions(+), 132 deletions(-)
> 
> Also, this is going to be hard to manage across trees, as you touch
> three drivers all at once. Is it not possible to split any of this apart
> better?

Will need some more effort and I can do it. Butm if we're going to start
an with immutable branch with everything in, is it worth the effort?
> 
>>
>> diff --git a/arch/arm/mach-omap2/gpmc-nand.c 
>> b/arch/arm/mach-omap2/gpmc-nand.c
>> index ffe646a..e07ca27 100644
>> --- a/arch/arm/mach-omap2/gpmc-nand.c
>> +++ b/arch/arm/mach-omap2/gpmc-nand.c
>> @@ -95,10 +95,7 @@ int gpmc_nand_init(struct omap_nand_platform_data 
>> *gpmc_nand_data,
>>  gpmc_nand_res[1].start = gpmc_get_irq();
>>  
>>  memset(, 0, sizeof(struct gpmc_settings));
>> -if (gpmc_nand_data->of_node)
>> -gpmc_read_settings_dt(gpmc_nand_data->of_node, );
>> -else
>> -gpmc_set_legacy(gpmc_nand_data, );
>> +gpmc_set_legacy(gpmc_nand_data, );
>>  
>>  s.device_nand = true;
>>  
>> diff --git a/drivers/memory/omap-gpmc.c b/drivers/memory/omap-gpmc.c
>> index e75226d..318c187 100644
>> --- a/drivers/memory/omap-gpmc.c
>> +++ b/drivers/memory/omap-gpmc.c
>> @@ -29,7 +29,6 @@
>>  #include 
>>  #include 
>>  #include 
>> -#include 
>>  #include 
>>  



>>  
>> -ppdata.of_node = pdata->of_node;
>> -mtd_device_parse_register(mtd, NULL, , pdata->parts,
>> -  pdata->nr_parts);
>> +if (dev->of_node) {
>> +ppdata.of_node = dev->of_node;
> 
> The latest l2-mtd.git changed how the partitions' of_node is passed. Now
> this is handled by nand_set_flash_node().

OK.
> 
>> +mtd_device_parse_register(mtd, NULL, , NULL, 0);
>> +
>> +} else {
>> +mtd_device_register(mtd, pdata->parts, pdata->nr_parts);
>> +}
>>  
>>  platform_set_drvdata(pdev, mtd);
>>  
>> @@ -2083,11 +2173,17 @@ static int omap_nand_remove(struct platform_device 
>> *pdev)
>>  return 0;
>>  }
>>  
>> +static const struct of_device_id omap_nand_ids[] = {
>> +{ .compatible = "ti,omap2-nand", },
>> +{},
>> +};
>> +
>>  static struct platform_driver omap_nand_driver = {
>>  .probe  = omap_nand_probe,
>>  .remove = omap_nand_remove,
>>  .driver = {
>>  .name   = DRIVER_NAME,
>> +.of_match_table = of_match_ptr(omap_nand_ids),
>>  },
>>  };
>>  
>> diff --git a/include/linux/platform_data/mtd-nand-omap2.h 
>> b/include/linux/platform_data/mtd-nand-omap2.h
>> index a067f58..ff27e5a 100644
>> --- a/include/linux/platform_data/mtd-nand-omap2.h
>> +++ b/include/linux/platform_data/mtd-nand-omap2.h
>> @@ -76,11 +76,10 @@ struct omap_nand_platform_data {
>>  int devsize;
>>  enum omap_ecc   ecc_opt;
>>  
>> -/* for passing the partitions */
>> -struct device_node  *of_node;
>>  struct device_node  *elm_of_node;
>>  
>>  /* deprecated */
>>  struct gpmc_nand_regs   reg;
>> +struct device_node  *of_node;
> 
> I'm a little confused here. Do you have a mixed platform data / device
> tree setup here? That's odd. (It also seems if that was really
> necessary, you could have the board file set pdev->dev.of_node before
> registering it, then you don't need this field.) But really, if you're
> partly using device tree, can't you just convert completely? Or is this
> a two-phase process, and you're planning to convert omap2 to full device
> tree?

The existing device tree implementation for omap2-nand was like this:
omap-gpmc.c driver was creating a platform device for the nand device and
passing the device node via platform data.

After this series we no longer do this and that's why of_node is marked
deprecated in platform data. I might as well could just get rid of it
but wasn't sure of how we're going to integrate the changes into the
subsystem trees so just marked it deprecated.

cheers,
-roger
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  

Re: [PATCH v3 18/27] mtd: nand: omap2: Implement NAND ready using gpiolib

[Brian Norris]

(to be clear, this branch of discussion isn't directly regarding the TI
changes; we can handle any generic handling afterward, as long as we get
the DT binding right now)

On Tue, Oct 27, 2015 at 09:28:32AM +0100, Boris Brezillon wrote:
> On Mon, 26 Oct 2015 13:49:00 -0700
> Brian Norris  wrote:
> > On Fri, Sep 18, 2015 at 05:53:40PM +0300, Roger Quadros wrote:
> > > @@ -1782,7 +1780,9 @@ static int omap_nand_probe(struct platform_device 
> > > *pdev)
> > >   info->reg = pdata->reg;
> > >   info->of_node = pdata->of_node;
> > >   info->ecc_opt = pdata->ecc_opt;
> > > - info->dev_ready = pdata->dev_ready;
> > > + if (pdata->dev_ready)
> > > + dev_info(>dev, "pdata->dev_ready is 
> > > deprecated\n");
> > > +
> > >   info->xfer_type = pdata->xfer_type;
> > >   info->devsize = pdata->devsize;
> > >   info->elm_of_node = pdata->elm_of_node;
> > > @@ -1815,6 +1815,13 @@ static int omap_nand_probe(struct platform_device 
> > > *pdev)
> > >   nand_chip->IO_ADDR_W = nand_chip->IO_ADDR_R;
> > >   nand_chip->cmd_ctrl  = omap_hwcontrol;
> > >  
> > > + info->ready_gpiod = devm_gpiod_get_optional(>dev, "ready",
> > > + GPIOD_IN);
> > 
> > Others have been looking at using GPIOs for the ready/busy pin too. At a
> > minimum, we need an updated DT binding doc for this, since I see you're
> > adding this via device tree in a later patch (I don't see any DT binding
> > patch for this; but I could just be overlooking it). It'd also be great
> > if this support was moved to nand_dt_init() so other platforms can
> > benefit, but I won't require that.
> 
> Actually I started to work on a generic solution parsing the DT and
> creating CS, WP and RB gpios when they are provided, but I think it's a
> bit more complicated than just moving the rb-gpios parsing into
> nand_dt_init().
> First you'll need something to store your gpio_desc pointers, which
> means you'll have to allocate a table of gpio_desc pointers (or a table
> of struct embedding a gpio_desc pointer).

I'm not sure what you mean by table. It seems like we would just have a
few gpio_desc pointers in struct nand_chip, no?

> The other blocking point is that when nand_scan_ident() is called, the
> caller is supposed to have filled the ->dev_ready() or ->waitfunc()
> fields, and to choose how to implement it he may need to know
> which kind of RB handler should be used (this is the case in the sunxi
> driver, where the user can either use a GPIO or native R/B pin directly
> connected to the controller).

Right, I was thinking about this one.

> All this makes me think that maybe nand_dt_init() should be called
> separately or in a different helper (nand_init() ?) taking care of the
> basic nand_chip initializations/allocations without interacting with
> the NAND itself.

Yeah, I feel like there have been other good reasons for something like
this before, and we just have worked around them so far. Maybe something
more like the alloc/add split in many other subsystems? e.g.,
platform_device_{alloc,add}, spi_{alloc,add}_device. Now we might want
nand_alloc()?

On a slight tangent, it seems silly that nand_scan_tail() doesn't
register the MTD, but nand_release() unregisters it. That shouldn't be.

> Another solution would be to add an ->init() function to nand_chip
> and call it after the generic initialization has been done (but before
> NAND chip detection). This way the NAND controller driver could adapt
> some fields and parse controller specific properties.

That could work too, I guess.

> What do you think?

Brian
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 04/27] mtd: nand: omap2: Use gpmc_omap_get_nand_ops() to get NAND registers

[Brian Norris]

On Fri, Sep 18, 2015 at 05:53:26PM +0300, Roger Quadros wrote:
> Deprecate nand register passing via platform data and use
> gpmc_omap_get_nand_ops() instead.
> 
> Signed-off-by: Roger Quadros 
> ---
>  arch/arm/mach-omap2/gpmc-nand.c  | 2 --
>  drivers/mtd/nand/omap2.c | 9 -
>  include/linux/platform_data/mtd-nand-omap2.h | 4 +++-
>  3 files changed, 11 insertions(+), 4 deletions(-)

This one also seems a bit oddly-split, if you're trying to allow
bringing these into different trees. The nand/omap2.c changes seem like
they can be done completely on their own (after the previous patches),
and the arch/arm/mach-omap2/gpmc-nand.c and
include/linux/platform_data/mtd-nand-omap2.h changes can come in their
own patch afterward.

That does still make things a little complicated for applying to
different trees, though, as we have some arch/arm -> drivers/mtd ->
arch/arm dependencies.

If it helps, I can try to provide Tony with a stable v4.4-rc1-based
piece of the MTD tree, and just take everything through there (with
acks). (FWIW, everything in l2-mtd.git can be considered stable,
git-wise. I've been keeping a clean history. But it'd be best to
coordinate what points to cross-merge.)

Then if we do that, we'd have to keep a close eye to make sure I don't
take any more conflicting changes to drivers/mtd/nand/omap2.c, or else
do another cross-merge...

Any better suggestions?

Brian

> 
> diff --git a/arch/arm/mach-omap2/gpmc-nand.c b/arch/arm/mach-omap2/gpmc-nand.c
> index 72918c4..04e6998 100644
> --- a/arch/arm/mach-omap2/gpmc-nand.c
> +++ b/arch/arm/mach-omap2/gpmc-nand.c
> @@ -121,8 +121,6 @@ int gpmc_nand_init(struct omap_nand_platform_data 
> *gpmc_nand_data,
>   if (err < 0)
>   goto out_free_cs;
>  
> - gpmc_update_nand_reg(_nand_data->reg, gpmc_nand_data->cs);
> -
>   if (!gpmc_hwecc_bch_capable(gpmc_nand_data->ecc_opt)) {
>   pr_err("omap2-nand: Unsupported NAND ECC scheme selected\n");
>   err = -EINVAL;
> diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
> index 60fa899..f214fe2 100644
> --- a/drivers/mtd/nand/omap2.c
> +++ b/drivers/mtd/nand/omap2.c
> @@ -28,6 +28,7 @@
>  #include 
>  #include 
>  
> +#include 
>  #include 
>  
>  #define  DRIVER_NAME "omap2-nand"
> @@ -169,7 +170,9 @@ struct omap_nand_info {
>   } iomode;
>   u_char  *buf;
>   int buf_len;
> + /* Interface to GPMC */
>   struct gpmc_nand_regs   reg;
> + struct gpmc_nand_ops*ops;
>   /* generated at runtime depending on ECC algorithm and layout selected 
> */
>   struct nand_ecclayout   oobinfo;
>   /* fields specific for BCHx_HW ECC scheme */
> @@ -1677,9 +1680,13 @@ static int omap_nand_probe(struct platform_device 
> *pdev)
>  
>   platform_set_drvdata(pdev, info);
>  
> + info->ops = gpmc_omap_get_nand_ops(>reg, info->gpmc_cs);
> + if (!info->ops) {
> + dev_err(>dev, "Failed to get GPMC->NAND interface\n");
> + return -ENODEV;
> + }
>   info->pdev  = pdev;
>   info->gpmc_cs   = pdata->cs;
> - info->reg   = pdata->reg;
>   info->of_node   = pdata->of_node;
>   info->ecc_opt   = pdata->ecc_opt;
>   mtd = >mtd;
> diff --git a/include/linux/platform_data/mtd-nand-omap2.h 
> b/include/linux/platform_data/mtd-nand-omap2.h
> index 090bbab..a067f58 100644
> --- a/include/linux/platform_data/mtd-nand-omap2.h
> +++ b/include/linux/platform_data/mtd-nand-omap2.h
> @@ -75,10 +75,12 @@ struct omap_nand_platform_data {
>   enum nand_ioxfer_type;
>   int devsize;
>   enum omap_ecc   ecc_opt;
> - struct gpmc_nand_regs   reg;
>  
>   /* for passing the partitions */
>   struct device_node  *of_node;
>   struct device_node  *elm_of_node;
> +
> + /* deprecated */
> + struct gpmc_nand_regs   reg;
>  };
>  #endif
> -- 
> 2.1.4
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 00/27] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms

[Brian Norris]

Hi,

On Thu, Dec 03, 2015 at 11:38:14AM +0530, Roger Quadros wrote:
> On 03/12/15 10:39, Brian Norris wrote:
> > On Fri, Sep 18, 2015 at 05:53:22PM +0300, Roger Quadros wrote:
> >> We do a couple of things in this series which result in
> >> cleaner device tree implementation, faster perfomance and
> >> multi-platform support. As an added bonus we get new GPI/Interrupt pins
> >> for use in the system.
> >>
> >> - Establish a custom interface between NAND and GPMC driver. This is
> >> needed because all of the NAND registers sit in the GPMC register space.
> >> Some bits like NAND IRQ are even shared with GPMC.
> >>
> >> - Remove NAND IRQ handling from omap-gpmc driver, share the GPMC IRQ
> >> with the omap2-nand driver and handle NAND IRQ events in the NAND driver.
> >> This causes performance increase when using prefetch-irq mode.
> >> 30% increase in read, 17% increase in write in prefetch-irq mode.
> >>
> >> - Clean up device tree support so that omap-gpmc IP and the omap2 NAND
> >> driver can be used on non-OMAP platforms. e.g. Keystone.
> >>
> >> - Implement GPIOCHIP + IRQCHIP for the GPMC WAITPINS. SoCs can contain
> >> 2 to 4 of these and most of them would be unused otherwise. It also
> >> allows a cleaner implementation of NAND Ready pin status for the NAND 
> >> driver.
> >>
> >> - Implement GPIOlib based NAND ready pin checking for OMAP NAND driver.
> >>
> >> This series is available at
> >> g...@github.com:rogerq/linux.git
> >> in branch
> >> for-v4.4/gpmc-v3
> >>
> >> cheers,
> >> -roger
> >>
> >> Changelog:
> >> v3:
> >> -Fixed and tested NAND using legacy boot on omap3-beagle.
> >> -Support rising and falling edge interrupts on WAITpins.
> >> -Update DT node of all gpmc users.
> > 
> > The MTD stuff looks mostly good to me know. I've made all my comments
> > for now, but I'm not sure how you're going to end up rebasing/splitting
> > and what you're going to do with the irqchip removal, so I'll refrain
> > from ack's for now. Hopefully I can either ack or merge v4.
> 
> I'll retain the irqchip model for now and send a v4 with all comments
> addressed and better subsystem wise patch split.
> 
> > 
> > I brought it up on one other patch, but it's not really clear to me what
> > the split is on board file vs. device tree handling, since you seem to
> > have a combination of both (i.e., platform data that passes along device
> > nodes). What's the plan on that?
> 
> Platform data no longer passes device nodes. We're either true device tree
> or plain legacy. The deprecated fields are no longer used once the series is
> applied.

Well, they're still sorta used (you assign info->of_node =
pdata->of_node, for instance). As dicussed in the other thread, I think
we can avoid the deprecation part and just kill the fields though, and
that would make things clearer.

> > And of course, there's the question of how exactly to merge this, given
> > the:
> > (1) conflicts already existing in the MTD dev tree
> 
> I'll rebase the series on top of MTD dev tree.

OK. FWIW, we so far only need to base them on commit a61ae81a1907 ("mtd:
nand: drop unnecessary partition parser data"). Maybe when queueing up a
branch, that'd be the best starting point for Tony, so he doesn't need
to have all of MTD's stuff in his tree too? I can set up a signed tag or
something, if that would be helpful.

But for sending patches, the latest l2-mtd.git is fine too.

> > (2) this touches several trees, often in the same patch and
> 
> I'll try my best to split the patches but not sure if this could be 100%
> clean split without functional breakage.
> 
> > (3) even if the patches were split out a little better into MTD and
> > non-MTD stuff, I think there would still be dependencies such that
> > we'd need at least 1 (probably 2) cross merges to get it all
> > straight
> 
> That is correct.
> Is it OK if functionality breaks if for example only MTD changes are 
> considered?

I think I may have misunderstood the branch proposal. If Tony queues up:

  l2-mtd.git (or just up to commit a61ae81a1907)
  +
  your patches

and I pull that back into l2-mtd.git as well, then we don't need to
worry about patches that touch multiple "trees". Just do whatever makes
things clearest, including disregarding some of my comments along the
line of (3).

Sorry for any confusion.

Brian
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC v02 04/15] dmaengine: edma: Add support for DMA filter mapping to slave devices

[Peter Ujfalusi]

On 12/02/2015 06:37 AM, Vinod Koul wrote:
> On Tue, Dec 01, 2015 at 09:20:28PM +0100, Arnd Bergmann wrote:
>> On Tuesday 01 December 2015 22:52:12 Vinod Koul wrote:
>>> On Mon, Nov 30, 2015 at 03:45:34PM +0200, Peter Ujfalusi wrote:
 Add support for providing device to filter_fn mapping so client drivers
 can switch to use the dma_request_chan() API.
>>>
>>> Any reason why we dont want to go with DT based only for edma here?
>>
>> I think the OMAP2 based platforms using edma are all DT-only, but 
>> mach-davinci
>> would need a lot of work for that.
> 
> Okay sound fine then

Yes, daVinci is mostly board file based and the problem is that those devices
are hard to find to do the conversion to DT.

-- 
Péter
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 1/6] ARM: OMAP2+: dts: cm-t335: add initial support

[Uri Mashiach]

Hi Tony,

On 11/30/2015 09:51 PM, Tony Lindgren wrote:

* Uri Mashiach  [151124 06:03]:

--- /dev/null
+++ b/arch/arm/boot/dts/am335x-cm-t335.dts

...


+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
+
+   status = "okay";
+};
+


FYI, the extra line break at the end of the file causes whitespace
warnings when applying. And fixing that causes extra hassles with
applying the other patches in the series as the patches won't apply..
So for the next time, you may want to check that ;)


Yes, I will definitely do that.



Also, the subject line should be "ARM: dts: ..." for the dts changes
so the git log loooks unified for all the ARM SoCs.


Got it. Thanks!



Anyways, I've fixed up those locally and applying into omap-for-v4.5/dt.



Thank you Tony!

--
Regards,
Uri.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC v02 03/15] dmaengine: core: Introduce new, universal API to request a channel

[Peter Ujfalusi]

On 12/01/2015 07:00 PM, Tony Lindgren wrote:
>> I see. The dm81xx basically am33xx/am43xx?
> 
> Yeah similar to am33xx with different clocks and with a bunch of accelerators.
> 
>> Actually I would prefer to use the dmaengine's event router framework and we
>> do have support for the am33xx/am43xx type of crossbar already implemented.
>> I'm going to resend the DTS series for am33xx/am43xx to convert them to use
>> the new DT bindings along with the dma event router support:
>> https://www.mail-archive.com/linux-omap%40vger.kernel.org/msg120828.html
> 
> OK yes a dmaengine event router works too when available. Good to see
> them as separate driver instances now :) Are only the dts changes missing
> now?
> 
> FYI, when we have separate interconnect driver instances, we don't want to
> and cannot tweak registers outside the interconnect instance because of them
> being in separate clock and/or power domains :p

What does this mean in practice? We can not touch these registers? The DMA
crossbar is a separate driver from the eDMA driver.

> In any case, it seems there's no harm using pinctrl for evtmux on dm81xx
> until the event router is available. It's currently only needed on the
> t410 emmc that I'm aware of :)

The AM33xx/AM43xx DMA crossbar support is in 4.4 already:
42dbdcc6bf96 dmaengine: ti-dma-crossbar: Add support for crossbar on 
AM33xx/AM43xx

-- 
Péter
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC v02 00/15] dmaengine: New 'universal' API for requesting channel

[Peter Ujfalusi]

On 12/01/2015 04:24 PM, Arnd Bergmann wrote:
> On Tuesday 01 December 2015 15:45:32 Peter Ujfalusi wrote:
 static struct dma_filter_map da830_edma_map[] = {
 DMA_FILTER_ENTRY("davinci-mcasp.0", "rx", EDMA_CTLR_CHAN(0, 0)),
 DMA_FILTER_ENTRY("davinci-mcasp.0", "tx", EDMA_CTLR_CHAN(0, 1)),
 DMA_FILTER_ENTRY("davinci-mcasp.1", "rx", EDMA_CTLR_CHAN(0, 2)),
 DMA_FILTER_ENTRY("davinci-mcasp.1", "tx", EDMA_CTLR_CHAN(0, 3)),
 DMA_FILTER_ENTRY("davinci-mcasp.2", "rx", EDMA_CTLR_CHAN(0, 4)),
 DMA_FILTER_ENTRY("davinci-mcasp.2", "tx", EDMA_CTLR_CHAN(0, 5)),
 DMA_FILTER_ENTRY("spi_davinci.0", "rx", EDMA_CTLR_CHAN(0, 14)),
 DMA_FILTER_ENTRY("spi_davinci.0", "tx", EDMA_CTLR_CHAN(0, 15)),
 DMA_FILTER_ENTRY("da830-mmc.0", "rx", EDMA_CTLR_CHAN(0, 16)),
 DMA_FILTER_ENTRY("da830-mmc.0", "tx", EDMA_CTLR_CHAN(0, 17)),
 DMA_FILTER_ENTRY("spi_davinci.1", "rx", EDMA_CTLR_CHAN(0, 18)),
 DMA_FILTER_ENTRY("spi_davinci.1", "tx", EDMA_CTLR_CHAN(0, 19)),
>>>
>>> Does this ".2" and so prevent driver to use auto ID for platform devices?
>>
>> Yes, as all the infra around the traditional board files with platform_device
>> creation does. Ideally we could have 'phandle' pointing from this table to 
>> the
>> device in question (or other way around), but I'm not aware of anything we 
>> can
>> use.
> 
> I was thinking that we could use a pointer to the device structure, but
> if you have that, you can also just read the name from it.

Hrm to have pdev pointer instead of the devname string? In the core we could
get the pdev from the caller's device with to_platform_device(dev) and simply
compare the pointers...

One of the issue I see (in mach-davinci and mach-omap1/2) is that the pdevs
are scattered around in the c files so gathering the pointers to a place where
we can see them to be able to use it in the dma_filter_map is not going to be
light weight task.
Furthermore we have the omap_hwmod for OMAP2+ which creates the actual pdevs
and resources from the omap_hwmod data structures so getting out the DMA event
numbers there is not going to be easy either...

I'll hold back the RFC v3 to see if we should switch to pdev pointer or stay
with the devname strings here.

-- 
Péter
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC v02 00/15] dmaengine: New 'universal' API for requesting channel

[Peter Ujfalusi]

On 12/01/2015 10:17 PM, Arnd Bergmann wrote:
> On Tuesday 01 December 2015 22:29:54 Vinod Koul wrote:
>> On Mon, Nov 30, 2015 at 03:45:30PM +0200, Peter Ujfalusi wrote:
>>> channel via DT, ACPI or in case if the kernel booted in non DT/ACPI mode
>>> it will use a filter lookup table and retrieves the needed information from
>>> the dma_filter_map provided by the DMA drivers.
>>
>> That sounds right, for the third case would the arch, driver or someone else
>> configure this?
> 
> The typical case is for the configuration to be defined in arch or platform
> code and passed down to the dmaengine driver.
> 
> I just noticed that the text above (and probably the code too) should
> be changed so we always fall back to this. There are cases where the
> platform is booted with DT in principle, but the DMA engine does not
> (yet) use DT and still wants to be converted. I think we can easily
> handle that case by always trying this if the other methods fail.

Yes, it was intentional actually to not fall back to legacy lookup. With the
dma_request_slave_channel_compat() I have had cases when the DT binding was
not correct - or actually when trying to get deferred working that the code
would fall back to legacy mode and it got me a channel which is not usable.
I did not know that we have platforms booting in DT but the dma binding is not
working so it uses other method to get channel.
I think, if we allow the fall back within dma_request_chan() it would not
cause the same issue as the dma_request_slave_channel_compat() did as long as
we are not providing the lookup table on DT booted cases when the DMA binding
is working correctly.
Let me see the flow, but I think it is doable.

-- 
Péter
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC v02 00/15] dmaengine: New 'universal' API for requesting channel

[Arnd Bergmann]

On Wednesday 02 December 2015 12:51:43 Peter Ujfalusi wrote:
> On 12/01/2015 04:24 PM, Arnd Bergmann wrote:
> > On Tuesday 01 December 2015 15:45:32 Peter Ujfalusi wrote:
>  static struct dma_filter_map da830_edma_map[] = {
>  DMA_FILTER_ENTRY("davinci-mcasp.0", "rx", EDMA_CTLR_CHAN(0, 0)),
>  DMA_FILTER_ENTRY("davinci-mcasp.0", "tx", EDMA_CTLR_CHAN(0, 1)),
>  DMA_FILTER_ENTRY("davinci-mcasp.1", "rx", EDMA_CTLR_CHAN(0, 2)),
>  DMA_FILTER_ENTRY("davinci-mcasp.1", "tx", EDMA_CTLR_CHAN(0, 3)),
>  DMA_FILTER_ENTRY("davinci-mcasp.2", "rx", EDMA_CTLR_CHAN(0, 4)),
>  DMA_FILTER_ENTRY("davinci-mcasp.2", "tx", EDMA_CTLR_CHAN(0, 5)),
>  DMA_FILTER_ENTRY("spi_davinci.0", "rx", EDMA_CTLR_CHAN(0, 14)),
>  DMA_FILTER_ENTRY("spi_davinci.0", "tx", EDMA_CTLR_CHAN(0, 15)),
>  DMA_FILTER_ENTRY("da830-mmc.0", "rx", EDMA_CTLR_CHAN(0, 16)),
>  DMA_FILTER_ENTRY("da830-mmc.0", "tx", EDMA_CTLR_CHAN(0, 17)),
>  DMA_FILTER_ENTRY("spi_davinci.1", "rx", EDMA_CTLR_CHAN(0, 18)),
>  DMA_FILTER_ENTRY("spi_davinci.1", "tx", EDMA_CTLR_CHAN(0, 19)),
> >>>
> >>> Does this ".2" and so prevent driver to use auto ID for platform devices?
> >>
> >> Yes, as all the infra around the traditional board files with 
> >> platform_device
> >> creation does. Ideally we could have 'phandle' pointing from this table to 
> >> the
> >> device in question (or other way around), but I'm not aware of anything we 
> >> can
> >> use.
> > 
> > I was thinking that we could use a pointer to the device structure, but
> > if you have that, you can also just read the name from it.
> 
> Hrm to have pdev pointer instead of the devname string? In the core we could
> get the pdev from the caller's device with to_platform_device(dev) and simply
> compare the pointers...
> 
> One of the issue I see (in mach-davinci and mach-omap1/2) is that the pdevs
> are scattered around in the c files so gathering the pointers to a place where
> we can see them to be able to use it in the dma_filter_map is not going to be
> light weight task.
> Furthermore we have the omap_hwmod for OMAP2+ which creates the actual pdevs
> and resources from the omap_hwmod data structures so getting out the DMA event
> numbers there is not going to be easy either...
> 
> I'll hold back the RFC v3 to see if we should switch to pdev pointer or stay
> with the devname strings here.

Sorry, what I meant to say above is that I had already concluded that using
device pointers was a bad idea and we should stay with names.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC v03 01/15] dmaengine: core: Skip mask matching when it is not provided to private_candidate

[Peter Ujfalusi]

If mask is NULL skip the mask matching against the DMA device capabilities.

Signed-off-by: Peter Ujfalusi 
---
 drivers/dma/dmaengine.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/dma/dmaengine.c b/drivers/dma/dmaengine.c
index daf54a39bcc7..6311e1fc80be 100644
--- a/drivers/dma/dmaengine.c
+++ b/drivers/dma/dmaengine.c
@@ -515,7 +515,7 @@ static struct dma_chan *private_candidate(const 
dma_cap_mask_t *mask,
 {
struct dma_chan *chan;
 
-   if (!__dma_device_satisfies_mask(dev, mask)) {
+   if (mask && !__dma_device_satisfies_mask(dev, mask)) {
pr_debug("%s: wrong capabilities\n", __func__);
return NULL;
}
-- 
2.6.3

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC v03 12/15] ARM: davinci: devices-da8xx: Remove DMA resources for MMC and SPI

[Peter Ujfalusi]

The drivers are now converted to not use the DMA resource.

Signed-off-by: Peter Ujfalusi 
---
 arch/arm/mach-davinci/devices-da8xx.c | 49 ---
 1 file changed, 49 deletions(-)

diff --git a/arch/arm/mach-davinci/devices-da8xx.c 
b/arch/arm/mach-davinci/devices-da8xx.c
index 9ffdcd5de0f8..242fb48371ae 100644
--- a/arch/arm/mach-davinci/devices-da8xx.c
+++ b/arch/arm/mach-davinci/devices-da8xx.c
@@ -57,15 +57,6 @@
 #define DA8XX_EMAC_RAM_OFFSET  0x
 #define DA8XX_EMAC_CTRL_RAM_SIZE   SZ_8K
 
-#define DA8XX_DMA_SPI0_RX  EDMA_CTLR_CHAN(0, 14)
-#define DA8XX_DMA_SPI0_TX  EDMA_CTLR_CHAN(0, 15)
-#define DA8XX_DMA_MMCSD0_RXEDMA_CTLR_CHAN(0, 16)
-#define DA8XX_DMA_MMCSD0_TXEDMA_CTLR_CHAN(0, 17)
-#define DA8XX_DMA_SPI1_RX  EDMA_CTLR_CHAN(0, 18)
-#define DA8XX_DMA_SPI1_TX  EDMA_CTLR_CHAN(0, 19)
-#define DA850_DMA_MMCSD1_RXEDMA_CTLR_CHAN(1, 28)
-#define DA850_DMA_MMCSD1_TXEDMA_CTLR_CHAN(1, 29)
-
 void __iomem *da8xx_syscfg0_base;
 void __iomem *da8xx_syscfg1_base;
 
@@ -751,16 +742,6 @@ static struct resource da8xx_mmcsd0_resources[] = {
.end= IRQ_DA8XX_MMCSDINT0,
.flags  = IORESOURCE_IRQ,
},
-   {   /* DMA RX */
-   .start  = DA8XX_DMA_MMCSD0_RX,
-   .end= DA8XX_DMA_MMCSD0_RX,
-   .flags  = IORESOURCE_DMA,
-   },
-   {   /* DMA TX */
-   .start  = DA8XX_DMA_MMCSD0_TX,
-   .end= DA8XX_DMA_MMCSD0_TX,
-   .flags  = IORESOURCE_DMA,
-   },
 };
 
 static struct platform_device da8xx_mmcsd0_device = {
@@ -788,16 +769,6 @@ static struct resource da850_mmcsd1_resources[] = {
.end= IRQ_DA850_MMCSDINT0_1,
.flags  = IORESOURCE_IRQ,
},
-   {   /* DMA RX */
-   .start  = DA850_DMA_MMCSD1_RX,
-   .end= DA850_DMA_MMCSD1_RX,
-   .flags  = IORESOURCE_DMA,
-   },
-   {   /* DMA TX */
-   .start  = DA850_DMA_MMCSD1_TX,
-   .end= DA850_DMA_MMCSD1_TX,
-   .flags  = IORESOURCE_DMA,
-   },
 };
 
 static struct platform_device da850_mmcsd1_device = {
@@ -984,16 +955,6 @@ static struct resource da8xx_spi0_resources[] = {
.end= IRQ_DA8XX_SPINT0,
.flags  = IORESOURCE_IRQ,
},
-   [2] = {
-   .start  = DA8XX_DMA_SPI0_RX,
-   .end= DA8XX_DMA_SPI0_RX,
-   .flags  = IORESOURCE_DMA,
-   },
-   [3] = {
-   .start  = DA8XX_DMA_SPI0_TX,
-   .end= DA8XX_DMA_SPI0_TX,
-   .flags  = IORESOURCE_DMA,
-   },
 };
 
 static struct resource da8xx_spi1_resources[] = {
@@ -1007,16 +968,6 @@ static struct resource da8xx_spi1_resources[] = {
.end= IRQ_DA8XX_SPINT1,
.flags  = IORESOURCE_IRQ,
},
-   [2] = {
-   .start  = DA8XX_DMA_SPI1_RX,
-   .end= DA8XX_DMA_SPI1_RX,
-   .flags  = IORESOURCE_DMA,
-   },
-   [3] = {
-   .start  = DA8XX_DMA_SPI1_TX,
-   .end= DA8XX_DMA_SPI1_TX,
-   .flags  = IORESOURCE_DMA,
-   },
 };
 
 static struct davinci_spi_platform_data da8xx_spi_pdata[] = {
-- 
2.6.3

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC v03 15/15] ARM: davinci: dm365: Remove DMA resources for SPI

[Peter Ujfalusi]

The driver is converted to not use the DMA resource.

Signed-off-by: Peter Ujfalusi 
---
 arch/arm/mach-davinci/dm365.c | 8 
 1 file changed, 8 deletions(-)

diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach-davinci/dm365.c
index e794bff7d589..664ee6bbef22 100644
--- a/arch/arm/mach-davinci/dm365.c
+++ b/arch/arm/mach-davinci/dm365.c
@@ -660,14 +660,6 @@ static struct resource dm365_spi0_resources[] = {
.start = IRQ_DM365_SPIINT0_0,
.flags = IORESOURCE_IRQ,
},
-   {
-   .start = 17,
-   .flags = IORESOURCE_DMA,
-   },
-   {
-   .start = 16,
-   .flags = IORESOURCE_DMA,
-   },
 };
 
 static struct platform_device dm365_spi0_device = {
-- 
2.6.3

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC v03 10/15] mmc: davinci_mmc: Use dma_request_chan() to requesting DMA channel

[Peter Ujfalusi]

With the new dma_request_chan() the clinet driver does not need to look for
the DMA resource and it does not need to pass filter_fn anymore.
By switching to the new API the davinci_mmc driver can now support deferred
probing against DMA.

Signed-off-by: Peter Ujfalusi 
---
 drivers/mmc/host/davinci_mmc.c | 52 --
 1 file changed, 14 insertions(+), 38 deletions(-)

diff --git a/drivers/mmc/host/davinci_mmc.c b/drivers/mmc/host/davinci_mmc.c
index ea2a2ebc6b91..8a0a2c291e0c 100644
--- a/drivers/mmc/host/davinci_mmc.c
+++ b/drivers/mmc/host/davinci_mmc.c
@@ -32,12 +32,10 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
 
-#include 
 #include 
 
 /*
@@ -517,35 +515,20 @@ davinci_release_dma_channels(struct mmc_davinci_host 
*host)
 
 static int __init davinci_acquire_dma_channels(struct mmc_davinci_host *host)
 {
-   int r;
-   dma_cap_mask_t mask;
-
-   dma_cap_zero(mask);
-   dma_cap_set(DMA_SLAVE, mask);
-
-   host->dma_tx =
-   dma_request_slave_channel_compat(mask, edma_filter_fn,
-   >txdma, mmc_dev(host->mmc), "tx");
-   if (!host->dma_tx) {
+   host->dma_tx = dma_request_chan(mmc_dev(host->mmc), "tx");
+   if (IS_ERR(host->dma_tx)) {
dev_err(mmc_dev(host->mmc), "Can't get dma_tx channel\n");
-   return -ENODEV;
+   return PTR_ERR(host->dma_tx);
}
 
-   host->dma_rx =
-   dma_request_slave_channel_compat(mask, edma_filter_fn,
-   >rxdma, mmc_dev(host->mmc), "rx");
-   if (!host->dma_rx) {
+   host->dma_rx = dma_request_chan(mmc_dev(host->mmc), "rx");
+   if (IS_ERR(host->dma_rx)) {
dev_err(mmc_dev(host->mmc), "Can't get dma_rx channel\n");
-   r = -ENODEV;
-   goto free_master_write;
+   dma_release_channel(host->dma_tx);
+   return PTR_ERR(host->dma_rx);
}
 
return 0;
-
-free_master_write:
-   dma_release_channel(host->dma_tx);
-
-   return r;
 }
 
 /*--*/
@@ -1262,18 +1245,6 @@ static int __init davinci_mmcsd_probe(struct 
platform_device *pdev)
host = mmc_priv(mmc);
host->mmc = mmc;/* Important */
 
-   r = platform_get_resource(pdev, IORESOURCE_DMA, 0);
-   if (!r)
-   dev_warn(>dev, "RX DMA resource not specified\n");
-   else
-   host->rxdma = r->start;
-
-   r = platform_get_resource(pdev, IORESOURCE_DMA, 1);
-   if (!r)
-   dev_warn(>dev, "TX DMA resource not specified\n");
-   else
-   host->txdma = r->start;
-
host->mem_res = mem;
host->base = ioremap(mem->start, mem_size);
if (!host->base)
@@ -1300,8 +1271,13 @@ static int __init davinci_mmcsd_probe(struct 
platform_device *pdev)
host->mmc_irq = irq;
host->sdio_irq = platform_get_irq(pdev, 1);
 
-   if (host->use_dma && davinci_acquire_dma_channels(host) != 0)
-   host->use_dma = 0;
+   if (host->use_dma) {
+   ret = davinci_acquire_dma_channels(host);
+   if (ret == -EPROBE_DEFER)
+   goto out;
+   else if (ret)
+   host->use_dma = 0;
+   }
 
/* REVISIT:  someday, support IRQ-driven card detection.  */
mmc->caps |= MMC_CAP_NEEDS_POLL;
-- 
2.6.3

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC v03 14/15] ARM: davinci: dm355: Remove DMA resources for SPI

[Peter Ujfalusi]

The driver is converted to not use the DMA resource.

Signed-off-by: Peter Ujfalusi 
---
 arch/arm/mach-davinci/dm355.c | 8 
 1 file changed, 8 deletions(-)

diff --git a/arch/arm/mach-davinci/dm355.c b/arch/arm/mach-davinci/dm355.c
index ee7656fa0c52..bed8f49eb60c 100644
--- a/arch/arm/mach-davinci/dm355.c
+++ b/arch/arm/mach-davinci/dm355.c
@@ -397,14 +397,6 @@ static struct resource dm355_spi0_resources[] = {
.start = IRQ_DM355_SPINT0_0,
.flags = IORESOURCE_IRQ,
},
-   {
-   .start = 17,
-   .flags = IORESOURCE_DMA,
-   },
-   {
-   .start = 16,
-   .flags = IORESOURCE_DMA,
-   },
 };
 
 static struct davinci_spi_platform_data dm355_spi0_pdata = {
-- 
2.6.3

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC v03 06/15] ARM: davinci: dm355: Add dma_filter_map to edma

[Peter Ujfalusi]

Provide the dma_filter_map to edma which will allow us to move the drivers
to the new, simpler dmaengine API and we can remove the DMA resources also
for the devices.

Signed-off-by: Peter Ujfalusi 
---
 arch/arm/mach-davinci/dm355.c | 20 
 1 file changed, 20 insertions(+)

diff --git a/arch/arm/mach-davinci/dm355.c b/arch/arm/mach-davinci/dm355.c
index 609950b8c191..ee7656fa0c52 100644
--- a/arch/arm/mach-davinci/dm355.c
+++ b/arch/arm/mach-davinci/dm355.c
@@ -13,6 +13,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -576,9 +577,28 @@ static s8 queue_priority_mapping[][2] = {
{-1, -1},
 };
 
+static const struct dma_filter_map da355_edma_map[] = {
+   { "davinci-mcbsp.0", "tx", EDMA_FILTER_PARAM(0, 2) },
+   { "davinci-mcbsp.0", "rx", EDMA_FILTER_PARAM(0, 3) },
+   { "davinci-mcbsp.1", "tx", EDMA_FILTER_PARAM(0, 8) },
+   { "davinci-mcbsp.1", "rx", EDMA_FILTER_PARAM(0, 9) },
+   { "spi_davinci.2", "tx", EDMA_FILTER_PARAM(0, 10) },
+   { "spi_davinci.2", "rx", EDMA_FILTER_PARAM(0, 11) },
+   { "spi_davinci.1", "tx", EDMA_FILTER_PARAM(0, 14) },
+   { "spi_davinci.1", "rx", EDMA_FILTER_PARAM(0, 15) },
+   { "spi_davinci.0", "tx", EDMA_FILTER_PARAM(0, 16) },
+   { "spi_davinci.0", "rx", EDMA_FILTER_PARAM(0, 17) },
+   { "dm6441-mmc.0", "rx", EDMA_FILTER_PARAM(0, 26) },
+   { "dm6441-mmc.0", "tx", EDMA_FILTER_PARAM(0, 27) },
+   { "dm6441-mmc.1", "rx", EDMA_FILTER_PARAM(0, 30) },
+   { "dm6441-mmc.1", "tx", EDMA_FILTER_PARAM(0, 31) },
+};
+
 static struct edma_soc_info dm355_edma_pdata = {
.queue_priority_mapping = queue_priority_mapping,
.default_queue  = EVENTQ_1,
+   .slave_map  = da355_edma_map,
+   .slavecnt   = ARRAY_SIZE(da355_edma_map),
 };
 
 static struct resource edma_resources[] = {
-- 
2.6.3

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC v03 09/15] ARM: davinci: dm646x: Add dma_filter_map to edma

[Peter Ujfalusi]

Provide the dma_filter_map to edma which will allow us to move the drivers
to the new, simpler dmaengine API and we can remove the DMA resources also
for the devices.

Signed-off-by: Peter Ujfalusi 
---
 arch/arm/mach-davinci/dm646x.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/arch/arm/mach-davinci/dm646x.c b/arch/arm/mach-davinci/dm646x.c
index 70eb42725eec..0f2dada231a1 100644
--- a/arch/arm/mach-davinci/dm646x.c
+++ b/arch/arm/mach-davinci/dm646x.c
@@ -9,6 +9,7 @@
  * or implied.
  */
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -540,9 +541,19 @@ static s8 dm646x_queue_priority_mapping[][2] = {
{-1, -1},
 };
 
+static const struct dma_filter_map da646x_edma_map[] = {
+   { "davinci-mcasp.0", "tx", EDMA_FILTER_PARAM(0, 6) },
+   { "davinci-mcasp.0", "rx", EDMA_FILTER_PARAM(0, 9) },
+   { "davinci-mcasp.1", "tx", EDMA_FILTER_PARAM(0, 12) },
+   { "spi_davinci", "tx", EDMA_FILTER_PARAM(0, 16) },
+   { "spi_davinci", "rx", EDMA_FILTER_PARAM(0, 17) },
+};
+
 static struct edma_soc_info dm646x_edma_pdata = {
.queue_priority_mapping = dm646x_queue_priority_mapping,
.default_queue  = EVENTQ_1,
+   .slave_map  = da646x_edma_map,
+   .slavecnt   = ARRAY_SIZE(da646x_edma_map),
 };
 
 static struct resource edma_resources[] = {
-- 
2.6.3

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC v03 04/15] dmaengine: edma: Add support for DMA filter mapping to slave devices

[Peter Ujfalusi]

Add support for providing device to filter_fn mapping so client drivers
can switch to use the dma_request_chan() API.

Signed-off-by: Peter Ujfalusi 
---
 drivers/dma/edma.c | 6 ++
 include/linux/platform_data/edma.h | 7 +++
 2 files changed, 13 insertions(+)

diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index 0675e268d577..46b305ea0d21 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -2297,6 +2297,12 @@ static int edma_probe(struct platform_device *pdev)
edma_set_chmap(>slave_chans[i], ecc->dummy_slot);
}
 
+   if (info->slave_map) {
+   ecc->dma_slave.filter_map.map = info->slave_map;
+   ecc->dma_slave.filter_map.mapcnt = info->slavecnt;
+   ecc->dma_slave.filter_map.filter_fn = edma_filter_fn;
+   }
+
ret = dma_async_device_register(>dma_slave);
if (ret) {
dev_err(dev, "slave ddev registration failed (%d)\n", ret);
diff --git a/include/linux/platform_data/edma.h 
b/include/linux/platform_data/edma.h
index e2878baeb90e..4e78a946e0c1 100644
--- a/include/linux/platform_data/edma.h
+++ b/include/linux/platform_data/edma.h
@@ -53,12 +53,16 @@ enum dma_event_q {
 #define EDMA_CTLR(i)   ((i) >> 16)
 #define EDMA_CHAN_SLOT(i)  ((i) & 0x)
 
+#define EDMA_FILTER_PARAM(ctlr, chan)  ((int[]) { EDMA_CTLR_CHAN(ctlr, chan) })
+
 struct edma_rsv_info {
 
const s16   (*rsv_chans)[2];
const s16   (*rsv_slots)[2];
 };
 
+struct dma_filter_map;
+
 /* platform_data for EDMA driver */
 struct edma_soc_info {
/*
@@ -76,6 +80,9 @@ struct edma_soc_info {
 
s8  (*queue_priority_mapping)[2];
const s16   (*xbar_chans)[2];
+
+   const struct dma_filter_map *slave_map;
+   int slavecnt;
 };
 
 #endif
-- 
2.6.3

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC v03 07/15] ARM: davinci: dm365: Add dma_filter_map to edma

[Peter Ujfalusi]

Provide the dma_filter_map to edma which will allow us to move the drivers
to the new, simpler dmaengine API and we can remove the DMA resources also
for the devices.

Signed-off-by: Peter Ujfalusi 
---
 arch/arm/mach-davinci/dm365.c | 22 ++
 1 file changed, 22 insertions(+)

diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach-davinci/dm365.c
index 2068cbeaeb03..e794bff7d589 100644
--- a/arch/arm/mach-davinci/dm365.c
+++ b/arch/arm/mach-davinci/dm365.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -862,9 +863,30 @@ static s8 dm365_queue_priority_mapping[][2] = {
{-1, -1},
 };
 
+static const struct dma_filter_map da365_edma_map[] = {
+   { "davinci-mcbsp.0", "tx", EDMA_FILTER_PARAM(0, 2) },
+   { "davinci-mcbsp.0", "rx", EDMA_FILTER_PARAM(0, 3) },
+   { "davinci_voicecodec", "tx", EDMA_FILTER_PARAM(0, 2) },
+   { "davinci_voicecodec", "rx", EDMA_FILTER_PARAM(0, 3) },
+   { "spi_davinci.2", "tx", EDMA_FILTER_PARAM(0, 10) },
+   { "spi_davinci.2", "rx", EDMA_FILTER_PARAM(0, 11) },
+   { "spi_davinci.1", "tx", EDMA_FILTER_PARAM(0, 14) },
+   { "spi_davinci.1", "rx", EDMA_FILTER_PARAM(0, 15) },
+   { "spi_davinci.0", "tx", EDMA_FILTER_PARAM(0, 16) },
+   { "spi_davinci.0", "rx", EDMA_FILTER_PARAM(0, 17) },
+   { "spi_davinci.3", "tx", EDMA_FILTER_PARAM(0, 18) },
+   { "spi_davinci.3", "rx", EDMA_FILTER_PARAM(0, 19) },
+   { "dm6441-mmc.0", "rx", EDMA_FILTER_PARAM(0, 26) },
+   { "dm6441-mmc.0", "tx", EDMA_FILTER_PARAM(0, 27) },
+   { "dm6441-mmc.1", "rx", EDMA_FILTER_PARAM(0, 30) },
+   { "dm6441-mmc.1", "tx", EDMA_FILTER_PARAM(0, 31) },
+};
+
 static struct edma_soc_info dm365_edma_pdata = {
.queue_priority_mapping = dm365_queue_priority_mapping,
.default_queue  = EVENTQ_3,
+   .slave_map  = da365_edma_map,
+   .slavecnt   = ARRAY_SIZE(da365_edma_map),
 };
 
 static struct resource edma_resources[] = {
-- 
2.6.3

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC v03 00/15] dmaengine: New 'universal' API for requesting channel

[Peter Ujfalusi]

Hi,

I keep this still as RFC.

Changes since RFC v02:
- Using has_acpi_companion() instead ACPI_HANDLE()
- mask matching change within private_candidate()
- Fallback in dma_request_chan() when DT/ACPI lookup fails.
- Rename dma_get_channel() -> find_candidate()
- Arch code changes as suggested by Arnd
- Some documentation updated, more need to be done.

Changes since RFC v01:
- dma_request_chan(); lost the mask parameter
- The new API does not rely on RESOURCE_DMA, instead the dma_filter_map table
  will be used to provide the needed information to the filter function in
  legacy mode
- Extended the example patches to convert most of daVinci to use the new API to
  request the DMA channels.

TODO: Documentation update ;)

As it has been discussed in the following thread:
http://www.gossamer-threads.com/lists/linux/kernel/2181487#2181487

Andy: I did looked at the unified device properties, but I decided to not to use
it as I don't see it to fit well and most of the legacy board files are using
resources to specify at least their memory regions so adding the DMA resource
to them would be more inline with the rest of the code.

The ARM, mmc and spi patches are converting daVinci drivers board files to use
the new method of requesting DMA channel.

With this series I have taken a path which would result two new API, which can
be used to convert most of the current users already and with some work all
users might be able to move to this set.
With this set the filter_fn used for legacy (non DT/ACPI) channel request is no
longer needed to be exported to client drivers since the selection of the
correct filter_fn will be done in the core.

So, the first proposal is to have:

struct dma_chan *dma_request_chan(struct device *dev, const char *name);
struct dma_chan *dma_request_chan_by_mask(const dma_cap_mask_t *mask);

The dma_request_chan_by_mask() is to request any channel matching with the
requested capabilities, can be used to request channel for memcpy, memset, xor,
etc where no hardware synchronization is needed.

The dma_request_chan() is to request a slave channel. The dma_request_chan() 
will try to find the
channel via DT, ACPI or in case if the kernel booted in non DT/ACPI mode
it will use a filter lookup table and retrieves the needed information from
the dma_filter_map provided by the DMA drivers.
This legacy mode needs changes in platform code, in dmaengine drivers and
finally the dmaengine user drivers can be converted:

For each dmaengine driver an array of DMA device, slave and the parameter
for the filter function needs to be added:

static const struct dma_filter_map da830_edma_map[] = {
{ "davinci-mcasp.0", "rx", EDMA_FILTER_PARAM(0, 0) },
{ "davinci-mcasp.0", "tx", EDMA_FILTER_PARAM(0, 1) },
{ "davinci-mcasp.1", "rx", EDMA_FILTER_PARAM(0, 2) },
{ "davinci-mcasp.1", "tx", EDMA_FILTER_PARAM(0, 3) },
{ "davinci-mcasp.2", "rx", EDMA_FILTER_PARAM(0, 4) },
{ "davinci-mcasp.2", "tx", EDMA_FILTER_PARAM(0, 5) },
{ "spi_davinci.0", "rx", EDMA_FILTER_PARAM(0, 14) },
{ "spi_davinci.0", "tx", EDMA_FILTER_PARAM(0, 15) },
{ "da830-mmc.0", "rx", EDMA_FILTER_PARAM(0, 16) },
{ "da830-mmc.0", "tx", EDMA_FILTER_PARAM(0, 17) },
{ "spi_davinci.1", "rx", EDMA_FILTER_PARAM(0, 18) },
{ "spi_davinci.1", "tx", EDMA_FILTER_PARAM(0, 19) },
};

This information is going to be needed by the dmaengine driver, so
modification to the platform_data is needed, and the driver map should be
added to the pdata of the DMA driver:

da8xx_edma0_pdata.slave_map = da830_edma_map;
da8xx_edma0_pdata.slavecnt = ARRAY_SIZE(da830_edma_map);

The DMA driver then needs to configure the needed device -> filter_fn
mapping before it registers with dma_async_device_register() :

if (info->slave_map) {
ecc->dma_slave.filter_map.map = info->slave_map;
ecc->dma_slave.filter_map.mapcnt = info->slavecnt;
ecc->dma_slave.filter_map.filter_fn = edma_filter_fn;
}

When neither DT or ACPI lookup is available the dma_request_chan() will
try to match the requester's device name with the filter_map's list of
device names, when a match found it will use the information from the
dma_filter_map to get the channel with the dma_get_channel() internal
function.

Regards,
Peter
---
Peter Ujfalusi (15):
  dmaengine: core: Skip mask matching when it is not provided to
private_candidate
  dmaengine: core: Move and merge the code paths using private_candidate
  dmaengine: core: Introduce new, universal API to request a channel
  dmaengine: edma: Add support for DMA filter mapping to slave devices
  ARM: davinci: devices-da8xx: Add dma_filter_map to edma
  ARM: davinci: dm355: Add dma_filter_map to edma
  ARM: davinci: dm365: Add dma_filter_map to edma
  ARM: davinci: dm644x: Add dma_filter_map to edma
  ARM: davinci: dm646x: Add dma_filter_map to edma
  mmc: davinci_mmc: Use dma_request_chan() to requesting DMA channel
  spi: davinci: Use 

[RFC v03 05/15] ARM: davinci: devices-da8xx: Add dma_filter_map to edma

[Peter Ujfalusi]

Provide the dma_filter_map to edma which will allow us to move the drivers
to the new, simpler dmaengine API and we can remove the DMA resources also
for the devices.

Signed-off-by: Peter Ujfalusi 
---
 arch/arm/mach-davinci/devices-da8xx.c | 46 +++
 1 file changed, 46 insertions(+)

diff --git a/arch/arm/mach-davinci/devices-da8xx.c 
b/arch/arm/mach-davinci/devices-da8xx.c
index 28c90bc372bd..9ffdcd5de0f8 100644
--- a/arch/arm/mach-davinci/devices-da8xx.c
+++ b/arch/arm/mach-davinci/devices-da8xx.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -233,16 +234,54 @@ static const struct platform_device_info 
da850_edma1_device __initconst = {
.size_data  = sizeof(da850_edma1_pdata),
 };
 
+static const struct dma_filter_map da830_edma_map[] = {
+   { "davinci-mcasp.0", "rx", EDMA_FILTER_PARAM(0, 0) },
+   { "davinci-mcasp.0", "tx", EDMA_FILTER_PARAM(0, 1) },
+   { "davinci-mcasp.1", "rx", EDMA_FILTER_PARAM(0, 2) },
+   { "davinci-mcasp.1", "tx", EDMA_FILTER_PARAM(0, 3) },
+   { "davinci-mcasp.2", "rx", EDMA_FILTER_PARAM(0, 4) },
+   { "davinci-mcasp.2", "tx", EDMA_FILTER_PARAM(0, 5) },
+   { "spi_davinci.0", "rx", EDMA_FILTER_PARAM(0, 14) },
+   { "spi_davinci.0", "tx", EDMA_FILTER_PARAM(0, 15) },
+   { "da830-mmc.0", "rx", EDMA_FILTER_PARAM(0, 16) },
+   { "da830-mmc.0", "tx", EDMA_FILTER_PARAM(0, 17) },
+   { "spi_davinci.1", "rx", EDMA_FILTER_PARAM(0, 18) },
+   { "spi_davinci.1", "tx", EDMA_FILTER_PARAM(0, 19) },
+};
+
 int __init da830_register_edma(struct edma_rsv_info *rsv)
 {
struct platform_device *edma_pdev;
 
da8xx_edma0_pdata.rsv = rsv;
 
+   da8xx_edma0_pdata.slave_map = da830_edma_map;
+   da8xx_edma0_pdata.slavecnt = ARRAY_SIZE(da830_edma_map);
+
edma_pdev = platform_device_register_full(_edma0_device);
return IS_ERR(edma_pdev) ? PTR_ERR(edma_pdev) : 0;
 }
 
+static const struct dma_filter_map da850_edma0_map[] = {
+   { "davinci-mcasp.0", "rx", EDMA_FILTER_PARAM(0, 0) },
+   { "davinci-mcasp.0", "tx", EDMA_FILTER_PARAM(0, 1) },
+   { "davinci-mcbsp.0", "rx", EDMA_FILTER_PARAM(0, 2) },
+   { "davinci-mcbsp.0", "tx", EDMA_FILTER_PARAM(0, 3) },
+   { "davinci-mcbsp.1", "rx", EDMA_FILTER_PARAM(0, 4) },
+   { "davinci-mcbsp.1", "tx", EDMA_FILTER_PARAM(0, 5) },
+   { "spi_davinci.0", "rx", EDMA_FILTER_PARAM(0, 14) },
+   { "spi_davinci.0", "tx", EDMA_FILTER_PARAM(0, 15) },
+   { "da830-mmc.0", "rx", EDMA_FILTER_PARAM(0, 16) },
+   { "da830-mmc.0", "tx", EDMA_FILTER_PARAM(0, 17) },
+   { "spi_davinci.1", "rx", EDMA_FILTER_PARAM(0, 18) },
+   { "spi_davinci.1", "tx", EDMA_FILTER_PARAM(0, 19) },
+};
+
+static const struct dma_filter_map da850_edma1_map[] = {
+   { "da830-mmc.1", "tx", EDMA_FILTER_PARAM(0, 28) },
+   { "da830-mmc.1", "rx", EDMA_FILTER_PARAM(0, 29) },
+};
+
 int __init da850_register_edma(struct edma_rsv_info *rsv[2])
 {
struct platform_device *edma_pdev;
@@ -252,11 +291,18 @@ int __init da850_register_edma(struct edma_rsv_info 
*rsv[2])
da850_edma1_pdata.rsv = rsv[1];
}
 
+   da8xx_edma0_pdata.slave_map = da850_edma0_map;
+   da8xx_edma0_pdata.slavecnt = ARRAY_SIZE(da850_edma0_map);
+
edma_pdev = platform_device_register_full(_edma0_device);
if (IS_ERR(edma_pdev)) {
pr_warn("%s: Failed to register eDMA0\n", __func__);
return PTR_ERR(edma_pdev);
}
+
+   da850_edma1_pdata.slave_map = da850_edma1_map;
+   da850_edma1_pdata.slavecnt = ARRAY_SIZE(da850_edma1_map);
+
edma_pdev = platform_device_register_full(_edma1_device);
return IS_ERR(edma_pdev) ? PTR_ERR(edma_pdev) : 0;
 }
-- 
2.6.3

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC v03 08/15] ARM: davinci: dm644x: Add dma_filter_map to edma

[Peter Ujfalusi]

Provide the dma_filter_map to edma which will allow us to move the drivers
to the new, simpler dmaengine API and we can remove the DMA resources also
for the devices.

Signed-off-by: Peter Ujfalusi 
---
 arch/arm/mach-davinci/dm644x.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-davinci/dm644x.c
index d38f5049d56e..59fae2c3b8f4 100644
--- a/arch/arm/mach-davinci/dm644x.c
+++ b/arch/arm/mach-davinci/dm644x.c
@@ -11,6 +11,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -505,9 +506,20 @@ static s8 queue_priority_mapping[][2] = {
{-1, -1},
 };
 
+static const struct dma_filter_map da644x_edma_map[] = {
+   { "davinci-mcbsp", "tx", EDMA_FILTER_PARAM(0, 2) },
+   { "davinci-mcbsp", "rx", EDMA_FILTER_PARAM(0, 3) },
+   { "spi_davinci", "tx", EDMA_FILTER_PARAM(0, 16) },
+   { "spi_davinci", "rx", EDMA_FILTER_PARAM(0, 17) },
+   { "dm6441-mmc.0", "rx", EDMA_FILTER_PARAM(0, 26) },
+   { "dm6441-mmc.0", "tx", EDMA_FILTER_PARAM(0, 27) },
+};
+
 static struct edma_soc_info dm644x_edma_pdata = {
.queue_priority_mapping = queue_priority_mapping,
.default_queue  = EVENTQ_1,
+   .slave_map  = da644x_edma_map,
+   .slavecnt   = ARRAY_SIZE(da644x_edma_map),
 };
 
 static struct resource edma_resources[] = {
-- 
2.6.3

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC v03 13/15] ARM: davinci: devices: Remove DMA resources for MMC

[Peter Ujfalusi]

The driver is converted to not use the DMA resource.

Signed-off-by: Peter Ujfalusi 
---
 arch/arm/mach-davinci/devices.c | 19 ---
 1 file changed, 19 deletions(-)

diff --git a/arch/arm/mach-davinci/devices.c b/arch/arm/mach-davinci/devices.c
index 6257aa452568..3ae70f2909b0 100644
--- a/arch/arm/mach-davinci/devices.c
+++ b/arch/arm/mach-davinci/devices.c
@@ -36,9 +36,6 @@
 #define DM365_MMCSD0_BASE   0x01D11000
 #define DM365_MMCSD1_BASE   0x01D0
 
-#define DAVINCI_DMA_MMCRXEVT   26
-#define DAVINCI_DMA_MMCTXEVT   27
-
 void __iomem  *davinci_sysmod_base;
 
 void davinci_map_sysmod(void)
@@ -144,14 +141,6 @@ static struct resource mmcsd0_resources[] = {
.start = IRQ_SDIOINT,
.flags = IORESOURCE_IRQ,
},
-   /* DMA channels: RX, then TX */
-   {
-   .start = EDMA_CTLR_CHAN(0, DAVINCI_DMA_MMCRXEVT),
-   .flags = IORESOURCE_DMA,
-   }, {
-   .start = EDMA_CTLR_CHAN(0, DAVINCI_DMA_MMCTXEVT),
-   .flags = IORESOURCE_DMA,
-   },
 };
 
 static struct platform_device davinci_mmcsd0_device = {
@@ -181,14 +170,6 @@ static struct resource mmcsd1_resources[] = {
.start = IRQ_DM355_SDIOINT1,
.flags = IORESOURCE_IRQ,
},
-   /* DMA channels: RX, then TX */
-   {
-   .start = EDMA_CTLR_CHAN(0, 30), /* rx */
-   .flags = IORESOURCE_DMA,
-   }, {
-   .start = EDMA_CTLR_CHAN(0, 31), /* tx */
-   .flags = IORESOURCE_DMA,
-   },
 };
 
 static struct platform_device davinci_mmcsd1_device = {
-- 
2.6.3

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC v03 11/15] spi: davinci: Use dma_request_chan() to requesting DMA channel

[Peter Ujfalusi]

With the new dma_request_chan() the clinet driver does not need to look for
the DMA resource and it does not need to pass filter_fn anymore.
By switching to the new API the davinci_mmc driver can now support deferred
probing against DMA.

Signed-off-by: Peter Ujfalusi 
---
 drivers/spi/spi-davinci.c | 76 +++
 1 file changed, 24 insertions(+), 52 deletions(-)

diff --git a/drivers/spi/spi-davinci.c b/drivers/spi/spi-davinci.c
index 7d3af3eacf57..540fc8754085 100644
--- a/drivers/spi/spi-davinci.c
+++ b/drivers/spi/spi-davinci.c
@@ -23,7 +23,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -33,8 +32,6 @@
 
 #include 
 
-#define SPI_NO_RESOURCE((resource_size_t)-1)
-
 #define CS_DEFAULT 0xFF
 
 #define SPIFMT_PHASE_MASK  BIT(16)
@@ -130,8 +127,6 @@ struct davinci_spi {
 
struct dma_chan *dma_rx;
struct dma_chan *dma_tx;
-   int dma_rx_chnum;
-   int dma_tx_chnum;
 
struct davinci_spi_platform_data pdata;
 
@@ -796,35 +791,19 @@ static irqreturn_t davinci_spi_irq(s32 irq, void *data)
 
 static int davinci_spi_request_dma(struct davinci_spi *dspi)
 {
-   dma_cap_mask_t mask;
struct device *sdev = dspi->bitbang.master->dev.parent;
-   int r;
-
-   dma_cap_zero(mask);
-   dma_cap_set(DMA_SLAVE, mask);
 
-   dspi->dma_rx = dma_request_channel(mask, edma_filter_fn,
-  >dma_rx_chnum);
-   if (!dspi->dma_rx) {
-   dev_err(sdev, "request RX DMA channel failed\n");
-   r = -ENODEV;
-   goto rx_dma_failed;
-   }
+   dspi->dma_rx = dma_request_chan(sdev, "rx");
+   if (IS_ERR(dspi->dma_rx))
+   return PTR_ERR(dspi->dma_rx);
 
-   dspi->dma_tx = dma_request_channel(mask, edma_filter_fn,
-  >dma_tx_chnum);
-   if (!dspi->dma_tx) {
-   dev_err(sdev, "request TX DMA channel failed\n");
-   r = -ENODEV;
-   goto tx_dma_failed;
+   dspi->dma_tx = dma_request_chan(sdev, "tx");
+   if (IS_ERR(dspi->dma_tx)) {
+   dma_release_channel(dspi->dma_rx);
+   return PTR_ERR(dspi->dma_tx);
}
 
return 0;
-
-tx_dma_failed:
-   dma_release_channel(dspi->dma_rx);
-rx_dma_failed:
-   return r;
 }
 
 #if defined(CONFIG_OF)
@@ -935,8 +914,6 @@ static int davinci_spi_probe(struct platform_device *pdev)
struct davinci_spi *dspi;
struct davinci_spi_platform_data *pdata;
struct resource *r;
-   resource_size_t dma_rx_chan = SPI_NO_RESOURCE;
-   resource_size_t dma_tx_chan = SPI_NO_RESOURCE;
int ret = 0;
u32 spipc0;
 
@@ -1043,27 +1020,15 @@ static int davinci_spi_probe(struct platform_device 
*pdev)
}
}
 
-   r = platform_get_resource(pdev, IORESOURCE_DMA, 0);
-   if (r)
-   dma_rx_chan = r->start;
-   r = platform_get_resource(pdev, IORESOURCE_DMA, 1);
-   if (r)
-   dma_tx_chan = r->start;
-
dspi->bitbang.txrx_bufs = davinci_spi_bufs;
-   if (dma_rx_chan != SPI_NO_RESOURCE &&
-   dma_tx_chan != SPI_NO_RESOURCE) {
-   dspi->dma_rx_chnum = dma_rx_chan;
-   dspi->dma_tx_chnum = dma_tx_chan;
-
-   ret = davinci_spi_request_dma(dspi);
-   if (ret)
-   goto free_clk;
-
-   dev_info(>dev, "DMA: supported\n");
-   dev_info(>dev, "DMA: RX channel: %pa, TX channel: %pa, 
event queue: %d\n",
-   _rx_chan, _tx_chan,
-   pdata->dma_event_q);
+
+   ret = davinci_spi_request_dma(dspi);
+   if (ret == -EPROBE_DEFER) {
+   goto free_clk;
+   } else if (ret) {
+   dev_info(>dev, "DMA is not supported (%d)\n", ret);
+   dspi->dma_rx = NULL;
+   dspi->dma_tx = NULL;
}
 
dspi->get_rx = davinci_spi_rx_buf_u8;
@@ -1101,8 +1066,10 @@ static int davinci_spi_probe(struct platform_device 
*pdev)
return ret;
 
 free_dma:
-   dma_release_channel(dspi->dma_rx);
-   dma_release_channel(dspi->dma_tx);
+   if (dspi->dma_rx) {
+   dma_release_channel(dspi->dma_rx);
+   dma_release_channel(dspi->dma_tx);
+   }
 free_clk:
clk_disable_unprepare(dspi->clk);
 free_master:
@@ -1133,6 +1100,11 @@ static int davinci_spi_remove(struct platform_device 
*pdev)
clk_disable_unprepare(dspi->clk);
spi_master_put(master);
 
+   if (dspi->dma_rx) {
+   dma_release_channel(dspi->dma_rx);
+   dma_release_channel(dspi->dma_tx);
+   }
+
return 0;
 }
 
-- 
2.6.3

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to 

[RFC v03 02/15] dmaengine: core: Move and merge the code paths using private_candidate

[Peter Ujfalusi]

Channel matching with private_candidate() is used in two paths, the error
checking is slightly different in them and they are duplicating code also.
Move the code under find_candidate() to provide consistent execution and
going to allow us to reuse this mode of channel lookup later.

Signed-off-by: Peter Ujfalusi 
---
 drivers/dma/dmaengine.c | 81 +
 1 file changed, 42 insertions(+), 39 deletions(-)

diff --git a/drivers/dma/dmaengine.c b/drivers/dma/dmaengine.c
index 6311e1fc80be..ea9d66982d40 100644
--- a/drivers/dma/dmaengine.c
+++ b/drivers/dma/dmaengine.c
@@ -546,6 +546,42 @@ static struct dma_chan *private_candidate(const 
dma_cap_mask_t *mask,
return NULL;
 }
 
+static struct dma_chan *find_candidate(struct dma_device *device,
+  const dma_cap_mask_t *mask,
+  dma_filter_fn fn, void *fn_param)
+{
+   struct dma_chan *chan = private_candidate(mask, device, fn, fn_param);
+   int err;
+
+   if (chan) {
+   /* Found a suitable channel, try to grab, prep, and return it.
+* We first set DMA_PRIVATE to disable balance_ref_count as this
+* channel will not be published in the general-purpose
+* allocator
+*/
+   dma_cap_set(DMA_PRIVATE, device->cap_mask);
+   device->privatecnt++;
+   err = dma_chan_get(chan);
+
+   if (err) {
+   if (err == -ENODEV) {
+   pr_debug("%s: %s module removed\n", __func__,
+dma_chan_name(chan));
+   list_del_rcu(>global_node);
+   } else
+   pr_debug("%s: failed to get %s: (%d)\n",
+__func__, dma_chan_name(chan), err);
+
+   if (--device->privatecnt == 0)
+   dma_cap_clear(DMA_PRIVATE, device->cap_mask);
+
+   chan = ERR_PTR(err);
+   }
+   }
+
+   return chan ? chan : ERR_PTR(-EPROBE_DEFER);
+}
+
 /**
  * dma_get_slave_channel - try to get specific channel exclusively
  * @chan: target channel
@@ -584,7 +620,6 @@ struct dma_chan *dma_get_any_slave_channel(struct 
dma_device *device)
 {
dma_cap_mask_t mask;
struct dma_chan *chan;
-   int err;
 
dma_cap_zero(mask);
dma_cap_set(DMA_SLAVE, mask);
@@ -592,23 +627,11 @@ struct dma_chan *dma_get_any_slave_channel(struct 
dma_device *device)
/* lock against __dma_request_channel */
mutex_lock(_list_mutex);
 
-   chan = private_candidate(, device, NULL, NULL);
-   if (chan) {
-   dma_cap_set(DMA_PRIVATE, device->cap_mask);
-   device->privatecnt++;
-   err = dma_chan_get(chan);
-   if (err) {
-   pr_debug("%s: failed to get %s: (%d)\n",
-   __func__, dma_chan_name(chan), err);
-   chan = NULL;
-   if (--device->privatecnt == 0)
-   dma_cap_clear(DMA_PRIVATE, device->cap_mask);
-   }
-   }
+   chan = find_candidate(device, , NULL, NULL);
 
mutex_unlock(_list_mutex);
 
-   return chan;
+   return IS_ERR(chan) ? NULL : chan;
 }
 EXPORT_SYMBOL_GPL(dma_get_any_slave_channel);
 
@@ -625,35 +648,15 @@ struct dma_chan *__dma_request_channel(const 
dma_cap_mask_t *mask,
 {
struct dma_device *device, *_d;
struct dma_chan *chan = NULL;
-   int err;
 
/* Find a channel */
mutex_lock(_list_mutex);
list_for_each_entry_safe(device, _d, _device_list, global_node) {
-   chan = private_candidate(mask, device, fn, fn_param);
-   if (chan) {
-   /* Found a suitable channel, try to grab, prep, and
-* return it.  We first set DMA_PRIVATE to disable
-* balance_ref_count as this channel will not be
-* published in the general-purpose allocator
-*/
-   dma_cap_set(DMA_PRIVATE, device->cap_mask);
-   device->privatecnt++;
-   err = dma_chan_get(chan);
+   chan = find_candidate(device, mask, fn, fn_param);
+   if (!IS_ERR(chan))
+   break;
 
-   if (err == -ENODEV) {
-   pr_debug("%s: %s module removed\n",
-__func__, dma_chan_name(chan));
-   list_del_rcu(>global_node);
-   } else if (err)
-   pr_debug("%s: failed to get %s: (%d)\n",
-__func__, 

[RFC v03 03/15] dmaengine: core: Introduce new, universal API to request a channel

[Peter Ujfalusi]

The two API function can cover most, if not all current APIs used to
request a channel. With minimal effort dmaengine drivers, platforms and
dmaengine user drivers can be converted to use the two function.

struct dma_chan *dma_request_chan_by_mask(const dma_cap_mask_t *mask);

To request any channel matching with the requested capabilities, can be
used to request channel for memcpy, memset, xor, etc where no hardware
synchronization is needed.

struct dma_chan *dma_request_chan(struct device *dev, const char *name);
To request a slave channel. The dma_request_chan() will try to find the
channel via DT, ACPI or in case if the kernel booted in non DT/ACPI mode
it will use a filter lookup table and retrieves the needed information from
the dma_filter_map provided by the DMA drivers.
This legacy mode needs changes in platform code, in dmaengine drivers and
finally the dmaengine user drivers can be converted:

For each dmaengine driver an array of DMA device, slave and the parameter
for the filter function needs to be added:

static const struct dma_filter_map da830_edma_map[] = {
{ "davinci-mcasp.0", "rx", EDMA_FILTER_PARAM(0, 0) },
{ "davinci-mcasp.0", "tx", EDMA_FILTER_PARAM(0, 1) },
{ "davinci-mcasp.1", "rx", EDMA_FILTER_PARAM(0, 2) },
{ "davinci-mcasp.1", "tx", EDMA_FILTER_PARAM(0, 3) },
{ "davinci-mcasp.2", "rx", EDMA_FILTER_PARAM(0, 4) },
{ "davinci-mcasp.2", "tx", EDMA_FILTER_PARAM(0, 5) },
{ "spi_davinci.0", "rx", EDMA_FILTER_PARAM(0, 14) },
{ "spi_davinci.0", "tx", EDMA_FILTER_PARAM(0, 15) },
{ "da830-mmc.0", "rx", EDMA_FILTER_PARAM(0, 16) },
{ "da830-mmc.0", "tx", EDMA_FILTER_PARAM(0, 17) },
{ "spi_davinci.1", "rx", EDMA_FILTER_PARAM(0, 18) },
{ "spi_davinci.1", "tx", EDMA_FILTER_PARAM(0, 19) },
};

This information is going to be needed by the dmaengine driver, so
modification to the platform_data is needed, and the driver map should be
added to the pdata of the DMA driver:

da8xx_edma0_pdata.slave_map = da830_edma_map;
da8xx_edma0_pdata.slavecnt = ARRAY_SIZE(da830_edma_map);

The DMA driver then needs to configure the needed device -> filter_fn
mapping before it registers with dma_async_device_register() :

if (info->slave_map) {
ecc->dma_slave.filter_map.map = info->slave_map;
ecc->dma_slave.filter_map.mapcnt = info->slavecnt;
ecc->dma_slave.filter_map.filter_fn = edma_filter_fn;
}

When neither DT or ACPI lookup is available the dma_request_chan() will
try to match the requester's device name with the filter_map's list of
device names, when a match found it will use the information from the
dma_filter_map to get the channel with the dma_get_channel() internal
function.

Signed-off-by: Peter Ujfalusi 
---
 Documentation/dmaengine/client.txt | 23 +++--
 drivers/dma/dmaengine.c| 98 ++
 include/linux/dmaengine.h  | 27 +++
 3 files changed, 131 insertions(+), 17 deletions(-)

diff --git a/Documentation/dmaengine/client.txt 
b/Documentation/dmaengine/client.txt
index d9f9f461102a..6c72a06eb1a5 100644
--- a/Documentation/dmaengine/client.txt
+++ b/Documentation/dmaengine/client.txt
@@ -22,25 +22,14 @@ The slave DMA usage consists of following steps:
Channel allocation is slightly different in the slave DMA context,
client drivers typically need a channel from a particular DMA
controller only and even in some cases a specific channel is desired.
-   To request a channel dma_request_channel() API is used.
+   To request a channel dma_request_chan() API is used.
 
Interface:
-   struct dma_chan *dma_request_channel(dma_cap_mask_t mask,
-   dma_filter_fn filter_fn,
-   void *filter_param);
-   where dma_filter_fn is defined as:
-   typedef bool (*dma_filter_fn)(struct dma_chan *chan, void 
*filter_param);
-
-   The 'filter_fn' parameter is optional, but highly recommended for
-   slave and cyclic channels as they typically need to obtain a specific
-   DMA channel.
-
-   When the optional 'filter_fn' parameter is NULL, dma_request_channel()
-   simply returns the first channel that satisfies the capability mask.
-
-   Otherwise, the 'filter_fn' routine will be called once for each free
-   channel which has a capability in 'mask'.  'filter_fn' is expected to
-   return 'true' when the desired DMA channel is found.
+   struct dma_chan *dma_request_chan(struct device *dev, const char *name);
+
+   Which will find and return the 'name' DMA channel associated with the 'dev'
+   device. The association is done via DT, ACPI or board file based
+   dma_map_filter matching table.
 
A channel allocated via this interface is exclusive to the caller,
until dma_release_channel() is called.
diff --git a/drivers/dma/dmaengine.c b/drivers/dma/dmaengine.c
index ea9d66982d40..b9dc1512c4aa 100644
--- a/drivers/dma/dmaengine.c
+++ 

[PATCH 0/2] Clock driver for dm814x ADPLL

[Tony Lindgren]

Hi all,

Here's a clock driver for the ADPLL on dm814x. It's still in read-only
mode for the PLL, but is already usable with the gates and dividers
and allows us to add devices like MMC and USB.

To test this please apply the patches from below on v4.4-rc3:

http://marc.info/?l=linux-omap=144901336001085=2

And also make sure you have the initcall level change patch that
is needed for having omap clock drivers regular Linux device
drivers:

http://marc.info/?l=linux-omap=14489008207=2


Regards,

Tony

Tony Lindgren (2):
  clk: ti: Add support for dm814x ADPLL
  ARM: dts: Add clocks for dm814x ADPLL

 .../devicetree/bindings/clock/ti/adpll.txt |   42 +
 arch/arm/boot/dts/dm814x-clocks.dtsi   |  256 -
 drivers/clk/Kconfig|1 +
 drivers/clk/ti/Kconfig |6 +
 drivers/clk/ti/Makefile|2 +
 drivers/clk/ti/adpll.c | 1027 
 drivers/clk/ti/clk-814x.c  |   53 +
 7 files changed, 1356 insertions(+), 31 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/clock/ti/adpll.txt
 create mode 100644 drivers/clk/ti/Kconfig
 create mode 100644 drivers/clk/ti/adpll.c

-- 
2.6.2

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/2] ARM: dts: Add clocks for dm814x ADPLL

[Tony Lindgren]

These use the standard clock bindings and now we can make some
of the fixed clocks into real clocks.

Cc: Tero Kristo 
Signed-off-by: Tony Lindgren 
---
 arch/arm/boot/dts/dm814x-clocks.dtsi | 256 ++-
 1 file changed, 225 insertions(+), 31 deletions(-)

diff --git a/arch/arm/boot/dts/dm814x-clocks.dtsi 
b/arch/arm/boot/dts/dm814x-clocks.dtsi
index 2600158..84fbfb1 100644
--- a/arch/arm/boot/dts/dm814x-clocks.dtsi
+++ b/arch/arm/boot/dts/dm814x-clocks.dtsi
@@ -4,6 +4,170 @@
  * published by the Free Software Foundation.
  */
 
+ {
+   /*
+* See TRM "2.6.10 Connected outputso DPLLS" and
+* "2.6.11 Connected Outputs of DPLLJ". Only clkout is
+* connected except for hdmi and usb.
+*/
+   adpll_mpu_ck: adpll@40 {
+   #clock-cells = <1>;
+   compatible = "ti,dm814-adpll-s-clock";
+   reg = <0x40 0x40>;
+   clocks = <_ck _ck _ck>;
+   clock-names = "clkinp", "clkinpulow", "clkinphif";
+   clock-indices = <0>, <1>, <2>, <3>;
+   clock-output-names = "481c5040.adpll.dcoclkldo",
+"481c5040.adpll.clkout",
+"481c5040.adpll.clkoutx2",
+"481c5040.adpll.clkouthif";
+   };
+
+   adpll_dsp_ck: adpll@80 {
+   #clock-cells = <1>;
+   compatible = "ti,dm814-adpll-j-clock";
+   reg = <0x80 0x30>;
+   clocks = <_ck _ck>;
+   clock-names = "clkinp", "clkinpulow";
+   clock-indices = <0>, <1>, <2>;
+   clock-output-names = "481c5080.adpll.clkdcoldo",
+"481c5080.adpll.clkout",
+"481c5080.adpll.clkoutldo";
+   };
+
+   adpll_sgx_ck: adpll@b0 {
+   #clock-cells = <1>;
+   compatible = "ti,dm814-adpll-j-clock";
+   reg = <0xb0 0x30>;
+   clocks = <_ck _ck>;
+   clock-names = "clkinp", "clkinpulow";
+   clock-indices = <0>, <1>, <2>;
+   clock-output-names = "481c50b0.adpll.clkdcoldo",
+"481c50b0.adpll.clkout",
+"481c50b0.adpll.clkoutldo";
+   };
+
+   adpll_hdvic_ck: adpll@e0 {
+   #clock-cells = <1>;
+   compatible = "ti,dm814-adpll-j-clock";
+   reg = <0xe0 0x30>;
+   clocks = <_ck _ck>;
+   clock-names = "clkinp", "clkinpulow";
+   clock-indices = <0>, <1>, <2>;
+   clock-output-names = "481c50e0.adpll.clkdcoldo",
+"481c50e0.adpll.clkout",
+"481c50e0.adpll.clkoutldo";
+   };
+
+   adpll_l3_ck: adpll@110 {
+   #clock-cells = <1>;
+   compatible = "ti,dm814-adpll-j-clock";
+   reg = <0x110 0x30>;
+   clocks = <_ck _ck>;
+   clock-names = "clkinp", "clkinpulow";
+   clock-indices = <0>, <1>, <2>;
+   clock-output-names = "481c5110.adpll.clkdcoldo",
+"481c5110.adpll.clkout",
+"481c5110.adpll.clkoutldo";
+   };
+
+   adpll_isp_ck: adpll@140 {
+   #clock-cells = <1>;
+   compatible = "ti,dm814-adpll-j-clock";
+   reg = <0x140 0x30>;
+   clocks = <_ck _ck>;
+   clock-names = "clkinp", "clkinpulow";
+   clock-indices = <0>, <1>, <2>;
+   clock-output-names = "481c5140.adpll.clkdcoldo",
+"481c5140.adpll.clkout",
+"481c5140.adpll.clkoutldo";
+   };
+
+   adpll_dss_ck: adpll@170 {
+   #clock-cells = <1>;
+   compatible = "ti,dm814-adpll-j-clock";
+   reg = <0x170 0x30>;
+   clocks = <_ck _ck>;
+   clock-names = "clkinp", "clkinpulow";
+   clock-indices = <0>, <1>, <2>;
+   clock-output-names = "481c5170.adpll.clkdcoldo",
+"481c5170.adpll.clkout",
+"481c5170.adpll.clkoutldo";
+   };
+
+   adpll_video0_ck: adpll@1a0 {
+   #clock-cells = <1>;
+   compatible = "ti,dm814-adpll-j-clock";
+   reg = <0x1a0 0x30>;
+   clocks = <_ck _ck>;
+   clock-names = "clkinp", "clkinpulow";
+   clock-indices = <0>, <1>, <2>;
+   clock-output-names = "481c51a0.adpll.clkdcoldo",
+"481c51a0.adpll.clkout",
+"481c51a0.adpll.clkoutldo";
+   };
+
+   adpll_video1_ck: adpll@1d0 {
+   #clock-cells = <1>;
+   compatible 

[PATCH 1/2] clk: ti: Add support for dm814x ADPLL

[Tony Lindgren]

On dm814x we have 13 ADPLLs with 3 to 4 outputs on each. The
ADPLLs have several dividers and muxes controlled by a shared
control register for each PLL.

Note that for the clocks to work as device drivers for booting on
dm814x, this patch depends on "ARM: OMAP2+: Change core_initcall
levels to postcore_initcall".

Also note that this patch does not implement clk_set_rate,
that will be posted later on when available.

Cc: Tero Kristo 
Signed-off-by: Tony Lindgren 
---
 .../devicetree/bindings/clock/ti/adpll.txt |   42 +
 drivers/clk/Kconfig|1 +
 drivers/clk/ti/Kconfig |6 +
 drivers/clk/ti/Makefile|2 +
 drivers/clk/ti/adpll.c | 1027 
 drivers/clk/ti/clk-814x.c  |   53 +
 6 files changed, 1131 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/clock/ti/adpll.txt
 create mode 100644 drivers/clk/ti/Kconfig
 create mode 100644 drivers/clk/ti/adpll.c

diff --git a/Documentation/devicetree/bindings/clock/ti/adpll.txt 
b/Documentation/devicetree/bindings/clock/ti/adpll.txt
new file mode 100644
index 000..8098583
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/ti/adpll.txt
@@ -0,0 +1,42 @@
+Binding for Texas Instruments FAPLL clock.
+
+Binding status: Unstable - ABI compatibility may be broken in the future
+
+This binding uses the common clock binding[1]. It assumes a
+register-mapped ADPLL with two to three selectable input clocks
+and three to four children..
+
+[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+Required properties:
+- compatible : shall be one of "ti,dm814-adpll-s-clock" or
+  "ti,dm814-adpll-j-clock" depending on the type of the ADPLL
+- #clock-cells : from common clock binding; shall be set to 0.
+- clocks : link phandles of parent clocks (clk-ref and clk-bypass)
+- reg : address and length of the register set for controlling the FAPLL.
+
+Examples:
+   adpll_mpu_ck: adpll@40 {
+   #clock-cells = <1>;
+   compatible = "ti,dm814-adpll-s-clock";
+   reg = <0x40 0x40>;
+   clocks = <_ck _ck _ck>;
+   clock-names = "clkinp", "clkinpulow", "clkinphif";
+   clock-indices = <0>, <1>, <2>, <3>;
+   clock-output-names = "481c5040.adpll.dcoclkldo",
+"481c5040.adpll.clkout",
+"481c5040.adpll.clkoutx2",
+"481c5040.adpll.clkouthif";
+   };
+
+   adpll_dsp_ck: adpll@80 {
+   #clock-cells = <1>;
+   compatible = "ti,dm814-adpll-j-clock";
+   reg = <0x80 0x30>;
+   clocks = <_ck _ck>;
+   clock-names = "clkinp", "clkinpulow";
+   clock-indices = <0>, <1>, <2>;
+   clock-output-names = "481c5080.adpll.clkdcoldo",
+"481c5080.adpll.clkout",
+"481c5080.adpll.clkoutldo";
+   };
diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index c3e3a02f..c0c9868 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -190,6 +190,7 @@ config COMMON_CLK_CDCE706
 
 source "drivers/clk/bcm/Kconfig"
 source "drivers/clk/hisilicon/Kconfig"
+source "drivers/clk/ti/Kconfig"
 source "drivers/clk/qcom/Kconfig"
 
 endmenu
diff --git a/drivers/clk/ti/Kconfig b/drivers/clk/ti/Kconfig
new file mode 100644
index 000..a9d5474
--- /dev/null
+++ b/drivers/clk/ti/Kconfig
@@ -0,0 +1,6 @@
+config COMMON_CLK_TI_ADPLL
+   tristate "Clock driver for dm814x ADPLL"
+   depends on ARCH_OMAP2PLUS
+   default y if SOC_TI81XX
+   ---help---
+ ADPLL clock driver for the dm814x SoC using common clock framework.
diff --git a/drivers/clk/ti/Makefile b/drivers/clk/ti/Makefile
index d4ac960..dfe91d7 100644
--- a/drivers/clk/ti/Makefile
+++ b/drivers/clk/ti/Makefile
@@ -18,3 +18,5 @@ obj-$(CONFIG_SOC_AM43XX)  += $(clk-common) 
dpll3xxx.o clk-43xx.o
 ifdef CONFIG_ATAGS
 obj-$(CONFIG_ARCH_OMAP3)+= clk-3xxx-legacy.o
 endif
+
+obj-$(CONFIG_COMMON_CLK_TI_ADPLL)  += adpll.o
diff --git a/drivers/clk/ti/adpll.c b/drivers/clk/ti/adpll.c
new file mode 100644
index 000..12252b9
--- /dev/null
+++ b/drivers/clk/ti/adpll.c
@@ -0,0 +1,1027 @@
+/*
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+