from:"Nicolas Ferre"

Re: [PATCH 2/3] kbuild: remove unnecessary variable initializaions

2014-09-09 Thread Nicolas Ferre

On 09/09/2014 12:26, Masahiro Yamada :
 Clearing obj-y, obj-m, obj-n, obj- in each Makefile is
 a useless habit.
 
 They are non-exported variables; therefore they are always empty
 whenever descending into each subdirectory.
 (Moreorver, obj-y and obj-m are also set to empty at the beginning
 of scripts/Makefile.build)
 
 Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com
 ---
 
  arch/arm/mach-at91/Makefile   | 3 ---
  arch/arm/mach-ebsa110/Makefile| 3 ---
  arch/arm/mach-ep93xx/Makefile | 3 ---
  arch/arm/mach-exynos/Makefile | 5 -
  arch/arm/mach-footbridge/Makefile | 3 ---
  arch/arm/mach-iop13xx/Makefile| 5 -
  arch/arm/mach-iop32x/Makefile | 3 ---
  arch/arm/mach-iop33x/Makefile | 3 ---
  arch/arm/mach-ks8695/Makefile | 3 ---
  arch/arm/mach-rpc/Makefile| 4 
  arch/arm/mach-s3c24xx/Makefile| 5 -
  arch/arm/mach-s3c64xx/Makefile| 5 -
  arch/arm/mach-s5pv210/Makefile| 5 -
  arch/arm/mach-sa1100/Makefile | 3 ---
  arch/arm/mach-u300/Makefile   | 3 ---
  arch/arm/plat-iop/Makefile| 6 --
  arch/arm/plat-omap/Makefile   | 3 ---
  arch/arm/plat-samsung/Makefile| 4 
  18 files changed, 69 deletions(-)
 
 diff --git a/arch/arm/mach-at91/Makefile b/arch/arm/mach-at91/Makefile
 index 78e9cec..75033839 100644
 --- a/arch/arm/mach-at91/Makefile
 +++ b/arch/arm/mach-at91/Makefile
 @@ -3,9 +3,6 @@
  #
  
  obj-y:= irq.o gpio.o setup.o sysirq_mask.o
 -obj-m:=
 -obj-n:=
 -obj- :=

I agree:
Acked-by: Nicolas Ferre nicolas.fe...@atmel.com

But I have patches that will mess with these changes already queued for
3.18. You may have to signal these conflicts when carrying the patch
upstream.

Thanks, best regards,

  obj-$(CONFIG_OLD_CLK_AT91)   += clock.o
  obj-$(CONFIG_AT91_SAM9_ALT_RESET) += at91sam9_alt_reset.o
 diff --git a/arch/arm/mach-ebsa110/Makefile b/arch/arm/mach-ebsa110/Makefile
 index 935e4af..a7d68c1 100644
 --- a/arch/arm/mach-ebsa110/Makefile
 +++ b/arch/arm/mach-ebsa110/Makefile
 @@ -5,6 +5,3 @@
  # Object file lists.
  
  obj-y:= core.o io.o leds.o
 -obj-m:=
 -obj-n:=
 -obj- :=
 diff --git a/arch/arm/mach-ep93xx/Makefile b/arch/arm/mach-ep93xx/Makefile
 index 0dc51f9..78d427b 100644
 --- a/arch/arm/mach-ep93xx/Makefile
 +++ b/arch/arm/mach-ep93xx/Makefile
 @@ -2,9 +2,6 @@
  # Makefile for the linux kernel.
  #
  obj-y:= core.o clock.o
 -obj-m:=
 -obj-n:=
 -obj- :=
  
  obj-$(CONFIG_EP93XX_DMA) += dma.o
  
 diff --git a/arch/arm/mach-exynos/Makefile b/arch/arm/mach-exynos/Makefile
 index 788f26d..27ae614 100644
 --- a/arch/arm/mach-exynos/Makefile
 +++ b/arch/arm/mach-exynos/Makefile
 @@ -7,11 +7,6 @@
  
  ccflags-$(CONFIG_ARCH_MULTIPLATFORM) += -I$(srctree)/$(src)/include 
 -I$(srctree)/arch/arm/plat-samsung/include
  
 -obj-y:=
 -obj-m:=
 -obj-n:=
 -obj- :=
 -
  # Core
  
  obj-$(CONFIG_ARCH_EXYNOS)+= exynos.o pmu.o exynos-smc.o firmware.o
 diff --git a/arch/arm/mach-footbridge/Makefile 
 b/arch/arm/mach-footbridge/Makefile
 index c3faa3b..e83d5c8 100644
 --- a/arch/arm/mach-footbridge/Makefile
 +++ b/arch/arm/mach-footbridge/Makefile
 @@ -5,9 +5,6 @@
  # Object file lists.
  
  obj-y:= common.o dma.o isa-irq.o
 -obj-m:=
 -obj-n:=
 -obj- :=
  
  pci-y+= dc21285.o
  pci-$(CONFIG_ARCH_CATS) += cats-pci.o
 diff --git a/arch/arm/mach-iop13xx/Makefile b/arch/arm/mach-iop13xx/Makefile
 index cad015f..a3d9260 100644
 --- a/arch/arm/mach-iop13xx/Makefile
 +++ b/arch/arm/mach-iop13xx/Makefile
 @@ -1,8 +1,3 @@
 -obj-y:=
 -obj-m:=
 -obj-n:=
 -obj- :=
 -
  obj-$(CONFIG_ARCH_IOP13XX) += setup.o
  obj-$(CONFIG_ARCH_IOP13XX) += irq.o
  obj-$(CONFIG_ARCH_IOP13XX) += pci.o
 diff --git a/arch/arm/mach-iop32x/Makefile b/arch/arm/mach-iop32x/Makefile
 index cfdf8a1..2d4010a 100644
 --- a/arch/arm/mach-iop32x/Makefile
 +++ b/arch/arm/mach-iop32x/Makefile
 @@ -3,9 +3,6 @@
  #
  
  obj-y:= irq.o
 -obj-m:=
 -obj-n:=
 -obj- :=
  
  obj-$(CONFIG_MACH_GLANTANK) += glantank.o
  obj-$(CONFIG_ARCH_IQ80321) += iq80321.o
 diff --git a/arch/arm/mach-iop33x/Makefile b/arch/arm/mach-iop33x/Makefile
 index 90081d8..e95db30 100644
 --- a/arch/arm/mach-iop33x/Makefile
 +++ b/arch/arm/mach-iop33x/Makefile
 @@ -3,9 +3,6 @@
  #
  
  obj-y:= irq.o uart.o
 -obj-m:=
 -obj-n:=
 -obj- :=
  
  obj

Re: [PATCH v2 19/26] irqchip: atmel-aic: convert to handle_domain_irq

2014-09-01 Thread Nicolas Ferre

On 26/08/2014 12:03, Marc Zyngier :
 Use the new handle_domain_irq method to handle interrupts.
 
 Signed-off-by: Marc Zyngier marc.zyng...@arm.com

Booting okay:

Acked-by: Nicolas Ferre nicolas.fe...@atmel.com

 ---
  drivers/irqchip/irq-atmel-aic.c | 4 +---
  1 file changed, 1 insertion(+), 3 deletions(-)
 
 diff --git a/drivers/irqchip/irq-atmel-aic.c b/drivers/irqchip/irq-atmel-aic.c
 index a82869e..9a2cf3c 100644
 --- a/drivers/irqchip/irq-atmel-aic.c
 +++ b/drivers/irqchip/irq-atmel-aic.c
 @@ -68,12 +68,10 @@ aic_handle(struct pt_regs *regs)
   irqnr = irq_reg_readl(gc-reg_base + AT91_AIC_IVR);
   irqstat = irq_reg_readl(gc-reg_base + AT91_AIC_ISR);
  
 - irqnr = irq_find_mapping(aic_domain, irqnr);
 -
   if (!irqstat)
   irq_reg_writel(0, gc-reg_base + AT91_AIC_EOICR);
   else
 - handle_IRQ(irqnr, regs);
 + handle_domain_irq(aic_domain, irqnr, regs);
  }
  
  static int aic_retrigger(struct irq_data *d)
 


-- 
Nicolas Ferre
--
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 20/26] irqchip: atmel-aic5: convert to handle_domain_irq

2014-09-01 Thread Nicolas Ferre

On 26/08/2014 12:03, Marc Zyngier :
 Use the new handle_domain_irq method to handle interrupts.
 
 Signed-off-by: Marc Zyngier marc.zyng...@arm.com

Ok, thanks:

Acked-by: Nicolas Ferre nicolas.fe...@atmel.com

 ---
  drivers/irqchip/irq-atmel-aic5.c | 4 +---
  1 file changed, 1 insertion(+), 3 deletions(-)
 
 diff --git a/drivers/irqchip/irq-atmel-aic5.c 
 b/drivers/irqchip/irq-atmel-aic5.c
 index edb2270..04fe2c1 100644
 --- a/drivers/irqchip/irq-atmel-aic5.c
 +++ b/drivers/irqchip/irq-atmel-aic5.c
 @@ -78,12 +78,10 @@ aic5_handle(struct pt_regs *regs)
   irqnr = irq_reg_readl(gc-reg_base + AT91_AIC5_IVR);
   irqstat = irq_reg_readl(gc-reg_base + AT91_AIC5_ISR);
  
 - irqnr = irq_find_mapping(aic5_domain, irqnr);
 -
   if (!irqstat)
   irq_reg_writel(0, gc-reg_base + AT91_AIC5_EOICR);
   else
 - handle_IRQ(irqnr, regs);
 + handle_domain_irq(aic5_domain, irqnr, regs);
  }
  
  static void aic5_mask(struct irq_data *d)
 


-- 
Nicolas Ferre
--
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] ARM: drop explicit selection of HAVE_CLK and CLKDEV_LOOKUP

2013-09-25 Thread Nicolas Ferre


On 24/09/2013 19:41, Uwe Kleine-König :

CLKDEV_LOOKUP selects HAVE_CLK and COMMON_CLK selects CLKDEV_LOOKUP. So
all symbols that select at least two of these symbols can be simplified.

For imx, omap2 and ux500 some rearrangements were necessary before the
simplification.

Signed-off-by: Uwe Kleine-König u.kleine-koe...@pengutronix.de
---
  arch/arm/Kconfig   | 12 
  arch/arm/mach-highbank/Kconfig |  1 -
  arch/arm/mach-imx/Kconfig  | 10 +-
  arch/arm/mach-omap2/Kconfig|  9 +
  arch/arm/mach-socfpga/Kconfig  |  1 -
  arch/arm/mach-spear/Kconfig|  2 --
  arch/arm/mach-tegra/Kconfig|  2 --
  arch/arm/mach-u300/Kconfig |  1 -
  arch/arm/mach-ux500/Kconfig| 29 -
  arch/arm/mach-vexpress/Kconfig |  2 --
  arch/arm/mach-vt8500/Kconfig   |  1 -
  11 files changed, 14 insertions(+), 56 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 3230f4c..66164a0 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -360,7 +360,6 @@ config ARCH_AT91
bool Atmel AT91
select ARCH_REQUIRE_GPIOLIB
select CLKDEV_LOOKUP
-   select HAVE_CLK


For AT91:

Acked-by: Nicolas Ferre nicolas.fe...@atmel.com



select IRQ_DOMAIN
select NEED_MACH_GPIO_H
select NEED_MACH_IO_H if PCCARD


[..]

Thanks Uwe, bye,
--
Nicolas Ferre
--
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 36/51] DMA-API: usb: use dma_set_coherent_mask()

2013-09-23 Thread Nicolas Ferre


On 20/09/2013 00:01, Russell King :

The correct way for a driver to specify the coherent DMA mask is
not to directly access the field in the struct device, but to use
dma_set_coherent_mask().  Only arch and bus code should access this
member directly.

Convert all direct write accesses to using the correct API.

Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
  drivers/usb/chipidea/ci_hdrc_imx.c |5 +++--
  drivers/usb/dwc3/dwc3-exynos.c |5 +++--
  drivers/usb/gadget/lpc32xx_udc.c   |4 +++-
  drivers/usb/host/ehci-atmel.c  |5 +++--


For Atmel driver:

Acked-by: Nicolas Ferre nicolas.fe...@atmel.com

[..]


diff --git a/drivers/usb/host/ehci-atmel.c b/drivers/usb/host/ehci-atmel.c
index 3b645ff..5831a88 100644
--- a/drivers/usb/host/ehci-atmel.c
+++ b/drivers/usb/host/ehci-atmel.c
@@ -92,8 +92,9 @@ static int ehci_atmel_drv_probe(struct platform_device *pdev)
 */
if (!pdev-dev.dma_mask)
pdev-dev.dma_mask = pdev-dev.coherent_dma_mask;
-   if (!pdev-dev.coherent_dma_mask)
-   pdev-dev.coherent_dma_mask = DMA_BIT_MASK(32);
+   retval = dma_set_coherent_mask(pdev-dev, DMA_BIT_MASK(32));
+   if (retval)
+   goto fail_create_hcd;

hcd = usb_create_hcd(driver, pdev-dev, dev_name(pdev-dev));
if (!hcd) {


[..]

Thanks,
--
Nicolas Ferre
--
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 37/51] DMA-API: usb: use new dma_coerce_mask_and_coherent()

2013-09-23 Thread Nicolas Ferre


On 20/09/2013 00:02, Russell King :

Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
  drivers/usb/chipidea/ci_hdrc_imx.c |4 +---
  drivers/usb/dwc3/dwc3-exynos.c |4 +---
  drivers/usb/host/ehci-atmel.c  |4 +---


For Atmel driver:

Acked-by: Nicolas Ferre nicolas.fe...@atmel.com

[..]


diff --git a/drivers/usb/host/ehci-atmel.c b/drivers/usb/host/ehci-atmel.c
index 5831a88..8e7323e 100644
--- a/drivers/usb/host/ehci-atmel.c
+++ b/drivers/usb/host/ehci-atmel.c
@@ -90,9 +90,7 @@ static int ehci_atmel_drv_probe(struct platform_device *pdev)
 * Since shared usb code relies on it, set it here for now.
 * Once we have dma capability bindings this can go away.
 */
-   if (!pdev-dev.dma_mask)
-   pdev-dev.dma_mask = pdev-dev.coherent_dma_mask;
-   retval = dma_set_coherent_mask(pdev-dev, DMA_BIT_MASK(32));
+   retval = dma_coerce_mask_and_coherent(pdev-dev, DMA_BIT_MASK(32));
if (retval)
goto fail_create_hcd;



[..]

Thanks Russell,
--
Nicolas Ferre
--
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] ARM: DTS: SAMA5: Add PMU support

2013-08-21 Thread Nicolas Ferre


On 05/08/2013 17:26, Alexandre Belloni :

ARM Performance Monitor Units are available on the sama5d3, add the support in
the dtsi.

Tested with perf and oprofile on the sama5d31ek.

Signed-off-by: Alexandre Belloni alexandre.bell...@free-electrons.com


Acked-by: Nicolas Ferre nicolas.fe...@atmel.com

Stacked on at91-3.12-dt.

Thanks.


---
  arch/arm/boot/dts/sama5d3.dtsi | 5 +
  1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/sama5d3.dtsi b/arch/arm/boot/dts/sama5d3.dtsi
index a1d5e25..afa68ac 100644
--- a/arch/arm/boot/dts/sama5d3.dtsi
+++ b/arch/arm/boot/dts/sama5d3.dtsi
@@ -48,6 +48,11 @@
};
};

+   pmu {
+   compatible = arm,cortex-a5-pmu;
+   interrupts = 46 IRQ_TYPE_LEVEL_HIGH 0;
+   };
+
memory {
reg = 0x2000 0x800;
};




--
Nicolas Ferre
--
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] drivers: video: use module_platform_driver_probe()

2013-03-15 Thread Nicolas Ferre

On 03/15/2013 10:00 AM, Fabio Porcedda :
 This patch converts the drivers to use the
 module_platform_driver_probe() macro which makes the code smaller and
 a bit simpler.
 
 Signed-off-by: Fabio Porcedda fabio.porce...@gmail.com
 Cc: Florian Tobias Schandinat florianschandi...@gmx.de
 Cc: Nicolas Ferre nicolas.fe...@atmel.com

For atmel_lcdfb.c:

Acked-by: Nicolas Ferre nicolas.fe...@atmel.com

Thanks Fabio.

 Cc: Tomi Valkeinen tomi.valkei...@ti.com
 Cc: David Howells dhowe...@redhat.com
 Cc: Geert Uytterhoeven ge...@linux-m68k.org
 Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com
 Cc: Kuninori Morimoto kuninori.morimoto...@renesas.com
 ---
 
 Notes:
 v3:
  - add missing drivers: amifb, atmel_lcdfb, vrfb
  - split patch set to each maintainer to easy up respin
 v2:
  - rebased over linux-next and remove already converted drivers
 
  drivers/video/amifb.c  | 14 +-
  drivers/video/atmel_lcdfb.c| 13 +
  drivers/video/omap2/vrfb.c | 13 +
  drivers/video/sh_mipi_dsi.c| 12 +---
  drivers/video/sh_mobile_hdmi.c | 12 +---
  5 files changed, 5 insertions(+), 59 deletions(-)
 
 diff --git a/drivers/video/amifb.c b/drivers/video/amifb.c
 index 7fa1bf8..03e2de2 100644
 --- a/drivers/video/amifb.c
 +++ b/drivers/video/amifb.c
 @@ -3788,19 +3788,7 @@ static struct platform_driver amifb_driver = {
   },
  };
  
 -static int __init amifb_init(void)
 -{
 - return platform_driver_probe(amifb_driver, amifb_probe);
 -}
 -
 -module_init(amifb_init);
 -
 -static void __exit amifb_exit(void)
 -{
 - platform_driver_unregister(amifb_driver);
 -}
 -
 -module_exit(amifb_exit);
 +return module_platform_driver_probe(amifb_driver, amifb_probe);
  
  MODULE_LICENSE(GPL);
  MODULE_ALIAS(platform:amiga-video);
 diff --git a/drivers/video/atmel_lcdfb.c b/drivers/video/atmel_lcdfb.c
 index 12cf5f3..654e102 100644
 --- a/drivers/video/atmel_lcdfb.c
 +++ b/drivers/video/atmel_lcdfb.c
 @@ -1150,18 +1150,7 @@ static struct platform_driver atmel_lcdfb_driver = {
   },
  };
  
 -static int __init atmel_lcdfb_init(void)
 -{
 - return platform_driver_probe(atmel_lcdfb_driver, atmel_lcdfb_probe);
 -}
 -
 -static void __exit atmel_lcdfb_exit(void)
 -{
 - platform_driver_unregister(atmel_lcdfb_driver);
 -}
 -
 -module_init(atmel_lcdfb_init);
 -module_exit(atmel_lcdfb_exit);
 +module_platform_driver_probe(atmel_lcdfb_driver, atmel_lcdfb_probe);
  
  MODULE_DESCRIPTION(AT91/AT32 LCD Controller framebuffer driver);
  MODULE_AUTHOR(Nicolas Ferre nicolas.fe...@atmel.com);
 diff --git a/drivers/video/omap2/vrfb.c b/drivers/video/omap2/vrfb.c
 index 10560ef..5261229 100644
 --- a/drivers/video/omap2/vrfb.c
 +++ b/drivers/video/omap2/vrfb.c
 @@ -397,18 +397,7 @@ static struct platform_driver vrfb_driver = {
   .remove = __exit_p(vrfb_remove),
  };
  
 -static int __init vrfb_init(void)
 -{
 - return platform_driver_probe(vrfb_driver, vrfb_probe);
 -}
 -
 -static void __exit vrfb_exit(void)
 -{
 - platform_driver_unregister(vrfb_driver);
 -}
 -
 -module_init(vrfb_init);
 -module_exit(vrfb_exit);
 +module_platform_driver_probe(vrfb_driver, vrfb_probe);
  
  MODULE_AUTHOR(Tomi Valkeinen tomi.valkei...@ti.com);
  MODULE_DESCRIPTION(OMAP VRFB);
 diff --git a/drivers/video/sh_mipi_dsi.c b/drivers/video/sh_mipi_dsi.c
 index 701b461..6cad530 100644
 --- a/drivers/video/sh_mipi_dsi.c
 +++ b/drivers/video/sh_mipi_dsi.c
 @@ -581,17 +581,7 @@ static struct platform_driver sh_mipi_driver = {
   },
  };
  
 -static int __init sh_mipi_init(void)
 -{
 - return platform_driver_probe(sh_mipi_driver, sh_mipi_probe);
 -}
 -module_init(sh_mipi_init);
 -
 -static void __exit sh_mipi_exit(void)
 -{
 - platform_driver_unregister(sh_mipi_driver);
 -}
 -module_exit(sh_mipi_exit);
 +module_platform_driver_probe(sh_mipi_driver, sh_mipi_probe);
  
  MODULE_AUTHOR(Guennadi Liakhovetski g.liakhovet...@gmx.de);
  MODULE_DESCRIPTION(SuperH / ARM-shmobile MIPI DSI driver);
 diff --git a/drivers/video/sh_mobile_hdmi.c b/drivers/video/sh_mobile_hdmi.c
 index 930e550..bfe4728 100644
 --- a/drivers/video/sh_mobile_hdmi.c
 +++ b/drivers/video/sh_mobile_hdmi.c
 @@ -1445,17 +1445,7 @@ static struct platform_driver sh_hdmi_driver = {
   },
  };
  
 -static int __init sh_hdmi_init(void)
 -{
 - return platform_driver_probe(sh_hdmi_driver, sh_hdmi_probe);
 -}
 -module_init(sh_hdmi_init);
 -
 -static void __exit sh_hdmi_exit(void)
 -{
 - platform_driver_unregister(sh_hdmi_driver);
 -}
 -module_exit(sh_hdmi_exit);
 +module_platform_driver_probe(sh_hdmi_driver, sh_hdmi_probe);
  
  MODULE_AUTHOR(Guennadi Liakhovetski g.liakhovet...@gmx.de);
  MODULE_DESCRIPTION(SuperH / ARM-shmobile HDMI driver);
 


-- 
Nicolas Ferre
--
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 119/493] usb: remove use of __devexit_p

2012-11-20 Thread Nicolas Ferre

On 11/19/2012 07:21 PM, Bill Pemberton :
 CONFIG_HOTPLUG is going away as an option so __devexit_p is no longer
 needed.
 
 Signed-off-by: Bill Pemberton wf...@virginia.edu
 Cc: Peter Korsgaard jac...@sunsite.dk 
 Cc: Alexander Shishkin alexander.shish...@linux.intel.com 
 Cc: Felipe Balbi ba...@ti.com 
 Cc: Li Yang le...@freescale.com 
 Cc: Alan Stern st...@rowland.harvard.edu 
 Cc: Wan ZongShun mcuos@gmail.com 
 Cc: Ben Dooks ben-li...@fluff.org 
 Cc: Kukjin Kim kgene@samsung.com 
 Cc: linux-...@vger.kernel.org 
 Cc: linux-omap@vger.kernel.org 
 Cc: linuxppc-...@lists.ozlabs.org 
 Cc: linux-arm-ker...@lists.infradead.org 
 Cc: linux-samsung-...@vger.kernel.org 

[..]

  drivers/usb/host/ehci-atmel.c| 2 +-

  drivers/usb/host/ohci-at91.c | 2 +-

For Atmel:

Acked-by: Nicolas Ferre nicolas.fe...@atmel.com

[..]

 diff --git a/drivers/usb/c67x00/c67x00-drv.c b/drivers/usb/c67x00/c67x00-drv.c
 index 6f3b6e2..855d538 100644
 --- a/drivers/usb/c67x00/c67x00-drv.c
 +++ b/drivers/usb/c67x00/c67x00-drv.c
 @@ -219,7 +219,7 @@ static int __devexit c67x00_drv_remove(struct 
 platform_device *pdev)
  
  static struct platform_driver c67x00_driver = {
   .probe  = c67x00_drv_probe,
 - .remove = __devexit_p(c67x00_drv_remove),
 + .remove = c67x00_drv_remove,
   .driver = {
   .owner = THIS_MODULE,
   .name = c67x00,
 diff --git a/drivers/usb/chipidea/ci13xxx_imx.c 
 b/drivers/usb/chipidea/ci13xxx_imx.c
 index 0f5ca4b..5659730 100644
 --- a/drivers/usb/chipidea/ci13xxx_imx.c
 +++ b/drivers/usb/chipidea/ci13xxx_imx.c
 @@ -252,7 +252,7 @@ MODULE_DEVICE_TABLE(of, ci13xxx_imx_dt_ids);
  
  static struct platform_driver ci13xxx_imx_driver = {
   .probe = ci13xxx_imx_probe,
 - .remove = __devexit_p(ci13xxx_imx_remove),
 + .remove = ci13xxx_imx_remove,
   .driver = {
   .name = imx_usb,
   .owner = THIS_MODULE,
 diff --git a/drivers/usb/chipidea/ci13xxx_msm.c 
 b/drivers/usb/chipidea/ci13xxx_msm.c
 index b01feb3..406c5af 100644
 --- a/drivers/usb/chipidea/ci13xxx_msm.c
 +++ b/drivers/usb/chipidea/ci13xxx_msm.c
 @@ -89,7 +89,7 @@ static int __devexit ci13xxx_msm_remove(struct 
 platform_device *pdev)
  
  static struct platform_driver ci13xxx_msm_driver = {
   .probe = ci13xxx_msm_probe,
 - .remove = __devexit_p(ci13xxx_msm_remove),
 + .remove = ci13xxx_msm_remove,
   .driver = { .name = msm_hsusb, },
  };
  
 diff --git a/drivers/usb/chipidea/ci13xxx_pci.c 
 b/drivers/usb/chipidea/ci13xxx_pci.c
 index 918e149..e1cb2fb 100644
 --- a/drivers/usb/chipidea/ci13xxx_pci.c
 +++ b/drivers/usb/chipidea/ci13xxx_pci.c
 @@ -147,7 +147,7 @@ static struct pci_driver ci13xxx_pci_driver = {
   .name = UDC_DRIVER_NAME,
   .id_table = ci13xxx_pci_id_table,
   .probe= ci13xxx_pci_probe,
 - .remove   = __devexit_p(ci13xxx_pci_remove),
 + .remove   = ci13xxx_pci_remove,
  };
  
  module_pci_driver(ci13xxx_pci_driver);
 diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
 index f69d029..46f23f2 100644
 --- a/drivers/usb/chipidea/core.c
 +++ b/drivers/usb/chipidea/core.c
 @@ -523,7 +523,7 @@ static int __devexit ci_hdrc_remove(struct 
 platform_device *pdev)
  
  static struct platform_driver ci_hdrc_driver = {
   .probe  = ci_hdrc_probe,
 - .remove = __devexit_p(ci_hdrc_remove),
 + .remove = ci_hdrc_remove,
   .driver = {
   .name   = ci_hdrc,
   },
 diff --git a/drivers/usb/chipidea/usbmisc_imx6q.c 
 b/drivers/usb/chipidea/usbmisc_imx6q.c
 index 416e3fc..81238a4 100644
 --- a/drivers/usb/chipidea/usbmisc_imx6q.c
 +++ b/drivers/usb/chipidea/usbmisc_imx6q.c
 @@ -136,7 +136,7 @@ static int __devexit usbmisc_imx6q_remove(struct 
 platform_device *pdev)
  
  static struct platform_driver usbmisc_imx6q_driver = {
   .probe = usbmisc_imx6q_probe,
 - .remove = __devexit_p(usbmisc_imx6q_remove),
 + .remove = usbmisc_imx6q_remove,
   .driver = {
   .name = usbmisc_imx6q,
   .owner = THIS_MODULE,
 diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
 index e71a62a..1a02442 100644
 --- a/drivers/usb/dwc3/core.c
 +++ b/drivers/usb/dwc3/core.c
 @@ -583,7 +583,7 @@ static int __devexit dwc3_remove(struct platform_device 
 *pdev)
  
  static struct platform_driver dwc3_driver = {
   .probe  = dwc3_probe,
 - .remove = __devexit_p(dwc3_remove),
 + .remove = dwc3_remove,
   .driver = {
   .name   = dwc3,
   },
 diff --git a/drivers/usb/dwc3/dwc3-exynos.c b/drivers/usb/dwc3/dwc3-exynos.c
 index dc35c54..19a9818 100644
 --- a/drivers/usb/dwc3/dwc3-exynos.c
 +++ b/drivers/usb/dwc3/dwc3-exynos.c
 @@ -196,7 +196,7 @@ MODULE_DEVICE_TABLE(of, exynos_dwc3_match);
  
  static struct platform_driver dwc3_exynos_driver = {
   .probe  = dwc3_exynos_probe,
 - .remove = __devexit_p(dwc3_exynos_remove),
 + .remove

Re: [PATCH V6 2/2] dmaengine: add helper function to request a slave DMA channel

2012-11-16 Thread Nicolas Ferre

On 11/16/2012 02:37 AM, Vinod Koul :
 On Fri, 2012-11-09 at 14:01 -0600, Jon Hunter wrote:
 Hi Vinod,

 A few people have been asking me if getting device-tree support for DMA
 engine is plan for record for v3.8. I know that you were working through
 implementing a common interface and so I wanted to check how that is
 going. Do you have any insight to when device-tree support may get added?

 I have not been able to do much work on this for last couple of weeks. I
 hope to do it in by this weekend. If not I will merge yours and then
 uppdate.
 
 Anyway, DT would be there in 3.8 with or without my changes.

Vinod,

So, can we imagine having this tree in linux-next rapidly (with or
without your changes)?

Thanks, best regards,
-- 
Nicolas Ferre
--
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: IS_ERR_OR_NULL - please STOP telling people to use this on a whim

2012-10-18 Thread Nicolas Ferre

On 10/17/2012 11:33 PM, Russell King - ARM Linux :
 On Wed, Oct 17, 2012 at 11:28:48PM +0300, Phil Carmody wrote:
 So, what to do? It can and has been used sensibly, so I don't think removing
 it is the best option.
 
 Well, the first thing that needs to be done is a full review of every user
 and fixes applied.
 
 The second thing is that we need eyes on code _and_ review comments, and
 educate those who are telling people to use IS_ERR_OR_NULL() whenever they
 see an IS_ERR() to think about the code a little more - that's kind of the
 purpose of my email.
 
 Unfortunately, it's going to take time to achieve a change, and if I end
 up being the only one who's spotting these errors, I'm going to get
 incredibly pissed off at doing so (because it will feel like I'm being
 ignored when there's a constant stream of it.)
 
 Another thing would be to work out whether we can get checkpatch to
 detect usage of IS_ERR_OR_NULL(p) followed by PTR_ERR(p) without any
 explicit NULL checks against p in the same block.  That's probably
 going to be interesting to code up in perl.

True that it would make sense to include in checkpatch to be able to
block code beforehand.
But for sure correction of existing code seems to be a work for Coccinelle.

Best regards,
-- 
Nicolas Ferre
--
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 14/24] USB: ohci: merge ohci_finish_controller_resume with ohci_resume

2012-10-05 Thread Nicolas Ferre

On 10/04/2012 05:17 PM, Florian Fainelli :
 Merge ohci_finish_controller_resume with ohci_resume as suggested by Alan
 Stern. Since ohci_finish_controller_resume no longer exists, update the
 various OHCI drivers to call ohci_resume() instead. Some drivers used to set
 themselves the bit HCD_FLAG_HW_ACCESSIBLE, which is now handled by
 ohci_resume().
 
 Signed-off-by: Florian Fainelli flor...@openwrt.org
 ---
  drivers/usb/host/ohci-at91.c |2 +-

Seems ok for AT91, so

Acked-by: Nicolas Ferre nicolas.fe...@atmel.com

Thanks Florian, bye,

  drivers/usb/host/ohci-ep93xx.c   |2 +-
  drivers/usb/host/ohci-exynos.c   |5 +
  drivers/usb/host/ohci-hcd.c  |   41 +++--
  drivers/usb/host/ohci-hub.c  |   42 
 --
  drivers/usb/host/ohci-omap.c |2 +-
  drivers/usb/host/ohci-platform.c |2 +-
  drivers/usb/host/ohci-pxa27x.c   |2 +-
  drivers/usb/host/ohci-s3c2410.c  |3 +--
  drivers/usb/host/ohci-spear.c|2 +-
  drivers/usb/host/ohci-tmio.c |2 +-
  11 files changed, 48 insertions(+), 57 deletions(-)
 
 diff --git a/drivers/usb/host/ohci-at91.c b/drivers/usb/host/ohci-at91.c
 index 0bf72f9..908d84a 100644
 --- a/drivers/usb/host/ohci-at91.c
 +++ b/drivers/usb/host/ohci-at91.c
 @@ -705,7 +705,7 @@ static int ohci_hcd_at91_drv_resume(struct 
 platform_device *pdev)
   if (!clocked)
   at91_start_clock();
  
 - ohci_finish_controller_resume(hcd);
 + ohci_resume(hcd, false);
   return 0;
  }
  #else
 diff --git a/drivers/usb/host/ohci-ep93xx.c b/drivers/usb/host/ohci-ep93xx.c
 index dbfbd1d..a982f04 100644
 --- a/drivers/usb/host/ohci-ep93xx.c
 +++ b/drivers/usb/host/ohci-ep93xx.c
 @@ -194,7 +194,7 @@ static int ohci_hcd_ep93xx_drv_resume(struct 
 platform_device *pdev)
  
   ep93xx_start_hc(pdev-dev);
  
 - ohci_finish_controller_resume(hcd);
 + ohci_resume(hcd, false);
   return 0;
  }
  #endif
 diff --git a/drivers/usb/host/ohci-exynos.c b/drivers/usb/host/ohci-exynos.c
 index fc3091b..53c5a989 100644
 --- a/drivers/usb/host/ohci-exynos.c
 +++ b/drivers/usb/host/ohci-exynos.c
 @@ -252,10 +252,7 @@ static int exynos_ohci_resume(struct device *dev)
   if (pdata  pdata-phy_init)
   pdata-phy_init(pdev, S5P_USB_PHY_HOST);
  
 - /* Mark hardware accessible again as we are out of D3 state by now */
 - set_bit(HCD_FLAG_HW_ACCESSIBLE, hcd-flags);
 -
 - ohci_finish_controller_resume(hcd);
 + ohci_resume(hcd, false);
  
   return 0;
  }
 diff --git a/drivers/usb/host/ohci-hcd.c b/drivers/usb/host/ohci-hcd.c
 index 5d30992..568bdb3 100644
 --- a/drivers/usb/host/ohci-hcd.c
 +++ b/drivers/usb/host/ohci-hcd.c
 @@ -1003,13 +1003,50 @@ static int __maybe_unused ohci_suspend(struct usb_hcd 
 *hcd, bool do_wakeup)
  
  static int __maybe_unused ohci_resume(struct usb_hcd *hcd, bool hibernated)
  {
 + struct ohci_hcd *ohci = hcd_to_ohci(hcd);
 + int port;
 + boolneed_reinit = false;
 +
   set_bit(HCD_FLAG_HW_ACCESSIBLE, hcd-flags);
  
   /* Make sure resume from hibernation re-enumerates everything */
   if (hibernated)
 - ohci_usb_reset(hcd_to_ohci(hcd));
 + ohci_usb_reset(ohci);
 +
 + /* See if the controller is already running or has been reset */
 + ohci-hc_control = ohci_readl(ohci, ohci-regs-control);
 + if (ohci-hc_control  (OHCI_CTRL_IR | OHCI_SCHED_ENABLES)) {
 + need_reinit = true;
 + } else {
 + switch (ohci-hc_control  OHCI_CTRL_HCFS) {
 + case OHCI_USB_OPER:
 + case OHCI_USB_RESET:
 + need_reinit = true;
 + }
 + }
 +
 + /* If needed, reinitialize and suspend the root hub */
 + if (need_reinit) {
 + spin_lock_irq(ohci-lock);
 + ohci_rh_resume(ohci);
 + ohci_rh_suspend(ohci, 0);
 + spin_unlock_irq(ohci-lock);
 + }
 +
 + /* Normally just turn on port power and enable interrupts */
 + else {
 + ohci_dbg(ohci, powerup ports\n);
 + for (port = 0; port  ohci-num_ports; port++)
 + ohci_writel(ohci, RH_PS_PPS,
 + ohci-regs-roothub.portstatus[port]);
 +
 + ohci_writel(ohci, OHCI_INTR_MIE, ohci-regs-intrenable);
 + ohci_readl(ohci, ohci-regs-intrenable);
 + msleep(20);
 + }
 +
 + usb_hcd_resume_root_hub(hcd);
  
 - ohci_finish_controller_resume(hcd);
   return 0;
  }
  
 diff --git a/drivers/usb/host/ohci-hub.c b/drivers/usb/host/ohci-hub.c
 index 2f3619e..db09dae 100644
 --- a/drivers/usb/host/ohci-hub.c
 +++ b/drivers/usb/host/ohci-hub.c
 @@ -316,48 +316,6 @@ static int ohci_bus_resume (struct usb_hcd *hcd)
   return rc;
  }
  
 -/* Carry out the final steps of resuming the controller device */
 -static void __maybe_unused

Re: [PATCH v3 04/15] dmaengine: Pass flags via device_prep_dma_cyclic() callback

2012-09-17 Thread Nicolas Ferre

On 09/14/2012 02:05 PM, Peter Ujfalusi :
 Change the parameter list of device_prep_dma_cyclic() so the DMA drivers
 can receive the flags coming from clients.
 This feature can be used during audio operation to disable all audio
 related interrupts when the DMA_PREP_INTERRUPT is cleared from the flags.
 
 Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
 CC: Nicolas Ferre nicolas.fe...@atmel.com
 CC: Barry Song baohua.s...@csr.com
 CC: Srinidhi Kasagar srinidhi.kasa...@stericsson.com
 CC: Russell King - ARM Linux li...@arm.linux.org.uk
 CC: Vista Silicon javier.mar...@vista-silicon.com
 CC: Zhangfei Gao zhangfei@marvell.com
 CC: Shawn Guo shawn@linaro.org
 CC: Laxman Dewangan ldewan...@nvidia.com
 ---
  drivers/dma/at_hdmac.c| 3 ++-

For Atmel's driver:

Acked-by: Nicolas Ferre nicolas.fe...@atmel.com

  drivers/dma/ep93xx_dma.c  | 4 +++-
  drivers/dma/imx-dma.c | 2 +-
  drivers/dma/imx-sdma.c| 2 +-
  drivers/dma/mmp_tdma.c| 2 +-
  drivers/dma/mxs-dma.c | 2 +-
  drivers/dma/omap-dma.c| 3 ++-
  drivers/dma/pl330.c   | 2 +-
  drivers/dma/sa11x0-dma.c  | 2 +-
  drivers/dma/sirf-dma.c| 2 +-
  drivers/dma/ste_dma40.c   | 3 ++-
  drivers/dma/tegra20-apb-dma.c | 2 +-
  include/linux/dmaengine.h | 4 ++--
  13 files changed, 19 insertions(+), 14 deletions(-)
 
 diff --git a/drivers/dma/at_hdmac.c b/drivers/dma/at_hdmac.c
 index 3934fcc..7e5f6b6 100644
 --- a/drivers/dma/at_hdmac.c
 +++ b/drivers/dma/at_hdmac.c
 @@ -841,12 +841,13 @@ atc_dma_cyclic_fill_desc(struct dma_chan *chan, struct 
 at_desc *desc,
   * @buf_len: total number of bytes for the entire buffer
   * @period_len: number of bytes for each period
   * @direction: transfer direction, to or from device
 + * @flags: tx descriptor status flags
   * @context: transfer context (ignored)
   */
  static struct dma_async_tx_descriptor *
  atc_prep_dma_cyclic(struct dma_chan *chan, dma_addr_t buf_addr, size_t 
 buf_len,
   size_t period_len, enum dma_transfer_direction direction,
 - void *context)
 + unsigned long flags, void *context)
  {
   struct at_dma_chan  *atchan = to_at_dma_chan(chan);
   struct at_dma_slave *atslave = chan-private;
 diff --git a/drivers/dma/ep93xx_dma.c b/drivers/dma/ep93xx_dma.c
 index c64917e..493735b 100644
 --- a/drivers/dma/ep93xx_dma.c
 +++ b/drivers/dma/ep93xx_dma.c
 @@ -1120,6 +1120,7 @@ fail:
   * @buf_len: length of the buffer (in bytes)
   * @period_len: lenght of a single period
   * @dir: direction of the operation
 + * @flags: tx descriptor status flags
   * @context: operation context (ignored)
   *
   * Prepares a descriptor for cyclic DMA operation. This means that once the
 @@ -1133,7 +1134,8 @@ fail:
  static struct dma_async_tx_descriptor *
  ep93xx_dma_prep_dma_cyclic(struct dma_chan *chan, dma_addr_t dma_addr,
  size_t buf_len, size_t period_len,
 -enum dma_transfer_direction dir, void *context)
 +enum dma_transfer_direction dir, unsigned long flags,
 +void *context)
  {
   struct ep93xx_dma_chan *edmac = to_ep93xx_dma_chan(chan);
   struct ep93xx_dma_desc *desc, *first;
 diff --git a/drivers/dma/imx-dma.c b/drivers/dma/imx-dma.c
 index 5084975..41b4376 100644
 --- a/drivers/dma/imx-dma.c
 +++ b/drivers/dma/imx-dma.c
 @@ -801,7 +801,7 @@ static struct dma_async_tx_descriptor 
 *imxdma_prep_slave_sg(
  static struct dma_async_tx_descriptor *imxdma_prep_dma_cyclic(
   struct dma_chan *chan, dma_addr_t dma_addr, size_t buf_len,
   size_t period_len, enum dma_transfer_direction direction,
 - void *context)
 + unsigned long flags, void *context)
  {
   struct imxdma_channel *imxdmac = to_imxdma_chan(chan);
   struct imxdma_engine *imxdma = imxdmac-imxdma;
 diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
 index 1dc2a4a..2c5fd3e 100644
 --- a/drivers/dma/imx-sdma.c
 +++ b/drivers/dma/imx-sdma.c
 @@ -1012,7 +1012,7 @@ err_out:
  static struct dma_async_tx_descriptor *sdma_prep_dma_cyclic(
   struct dma_chan *chan, dma_addr_t dma_addr, size_t buf_len,
   size_t period_len, enum dma_transfer_direction direction,
 - void *context)
 + unsigned long flags, void *context)
  {
   struct sdma_channel *sdmac = to_sdma_chan(chan);
   struct sdma_engine *sdma = sdmac-sdma;
 diff --git a/drivers/dma/mmp_tdma.c b/drivers/dma/mmp_tdma.c
 index 8a15cf2..6d52bd4 100644
 --- a/drivers/dma/mmp_tdma.c
 +++ b/drivers/dma/mmp_tdma.c
 @@ -358,7 +358,7 @@ struct mmp_tdma_desc *mmp_tdma_alloc_descriptor(struct 
 mmp_tdma_chan *tdmac)
  static struct dma_async_tx_descriptor *mmp_tdma_prep_dma_cyclic(
   struct dma_chan *chan, dma_addr_t dma_addr, size_t buf_len,
   size_t period_len, enum dma_transfer_direction direction,
 - void *context

Re: [PATCH V5 1/2] of: Add generic device tree DMA helpers

2012-09-14 Thread Nicolas Ferre

On 09/14/2012 05:18 PM, Jon Hunter :
 This is based upon the work by Benoit Cousson [1] and Nicolas Ferre [2]
 to add some basic helpers to retrieve a DMA controller device_node and the
 DMA request/channel information.
 
 Aim of DMA helpers
 - The purpose of device-tree is to describe the capabilites of the hardware.
   Thinking about DMA controllers purely from the context of the hardware to
   begin with, we can describe a device in terms of a DMA controller as
   follows ...
   1. Number of DMA controllers
   2. Number of channels (maybe physical or logical)
   3. Mapping of DMA requests signals to DMA controller
   4. Number of DMA interrupts
   5. Mapping of DMA interrupts to channels
 - With the above in mind the aim of the DT DMA helper functions is to extract
   the above information from the DT and provide to the appropriate driver.
   However, due to the vast number of DMA controllers and not all are using a
   common driver (such as DMA Engine) it has been seen that this is not a
   trivial task. In previous discussions on this topic the following concerns
   have been raised ...
   1. How does the binding support devices with multiple DMA controllers?
   2. How to support both legacy DMA controllers not using DMA Engine as
  well as those that support DMA Engine.
   3. When using with DMA Engine how do we support the various
  implementations where the opaque filter function parameter differs
  between implementations?
   4. How do we handle DMA channels that are identified with a string
  versus a integer?
 - Hence the design of the DMA helpers has to accomodate the above or align on
   an agreement what can be or should be supported.
 
 Design of DMA helpers
 
 1. Registering DMA controllers
 
In the case of DMA controllers that are using DMA Engine, requesting a
channel is performed by calling the following function.
 
   struct dma_chan *dma_request_channel(dma_cap_mask_t mask,
   dma_filter_fn filter_fn,
   void *filter_param);
 
The mask variable is used to match a type of the device controller in a 
 list
of controllers. The filter_fn and filter_param are used to identify the
required dma channel and return a handle to the dma channel of type 
 dma_chan.
 
From the examples I have seen, the mask and filter_fn are constant
for a given DMA controller and therefore, we can specify these as 
 controller
specific data when registering the DMA controller with the device-tree DMA
helpers.
 
The filter_param variable is of an unknown type and is typically specific
to the DMA engine implementation for a given DMA controller. To allow some
flexibility in the type and formating of this filter_param we employ an
xlate to translate the device-tree binding information into the appropriate
format. The xlate function used for a DMA controller can also be specified
when registering the DMA controller with the device-tree DMA helpers.
 
Based upon the above, a function for registering the DMA controller with 
 the
DMA helpers now looks like the below. The data variable is used to pass a
pointer to DMA controller specific data used by the xlate function.
 
   int of_dma_controller_register(struct device_node *np,
   struct dma_chan *(*of_dma_xlate)
   (struct of_phandle_args *, struct of_dma *),
   void *data)
 
For example, in the case where DMA engine is used, we define the following
structure (that stores the DMA engine capability mask and filter function)
and pass this to the data variable in the above function.
 
   struct of_dma_filter_info {
   dma_cap_mask_t  dma_cap;
   dma_filter_fn   filter_fn;
   };
 
 2. Representing and requesting channel information
 
Please see the dma binding documentation included in this patch for a
description of how DMA controllers and client information should be
represented with device-tree. For more information on how this binding
came about please see [3]. In addition to this, feedback received from
the Linux kernel summit showed a consensus (among those who attended) to
use a name to identify DMA client information [4].
 
A DMA channel can be requested by calling the following function, where 
 name
is a required parameter used for identifying a DMA channel. This function
has been designed to return a structure of type dma_chan to work with the
DMA engine driver. Note that if DMA engine is used then drivers should be
using the DMA engine API dma_request_slave_channel() (implemented in part 2
of this series, dmaengine: add helper function to request a slave DMA
channel) which will in turn call the below function if device-tree is
present. The aim being to have a common DMA engine interface regardless of
whether device tree is being used

[PATCH v2 1/2] of: Add generic device tree DMA helpers

2012-03-20 Thread Nicolas Ferre

Add some basic helpers to retrieve a DMA controller device_node and the
DMA request specifications. By making DMA controllers register a generic
translation function, we allow the management of any type of DMA requests
specification.
The void * output of an of_dma_xlate() function that will be implemented
by the DMA controller can carry any type of dma-request argument.

The DMA client will search its associated DMA controller in the list and
call the registered of_dam_xlate() function to retrieve the request values.

One simple xlate function is provided for the single number type of
request binding.

This implementation is independent from dmaengine so it can also be used
by legacy drivers.

Signed-off-by: Nicolas Ferre nicolas.fe...@atmel.com
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Stephen Warren swar...@nvidia.com
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Russell King li...@arm.linux.org.uk
Cc: Rob Herring rob.herr...@calxeda.com
Cc: Arnd Bergmann a...@arndb.de
---
Hi all,

v2: - remove of_dma_to_resource API
- make property #dma-cells required (no fallback anymore)
- another check in of_dma_xlate_onenumbercell() function

This patch is just for the record as it seems that those helpers will not cover
every people expectations. So I let interested people build on top of this or
redo the whole stuff from the gound up.

Bye,

 Documentation/devicetree/bindings/dma/dma.txt |   45 +
 drivers/of/Makefile   |2 +-
 drivers/of/dma.c  |  215 +
 include/linux/of_dma.h|   60 +++
 4 files changed, 321 insertions(+), 1 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/dma/dma.txt
 create mode 100644 drivers/of/dma.c
 create mode 100644 include/linux/of_dma.h

diff --git a/Documentation/devicetree/bindings/dma/dma.txt 
b/Documentation/devicetree/bindings/dma/dma.txt
new file mode 100644
index 000..c49e98d
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/dma.txt
@@ -0,0 +1,45 @@
+* Generic DMA Controller and DMA request bindings
+
+Generic binding to provide a way for a driver to retrieve the
+DMA request line that goes from an IP to a DMA controller.
+
+
+* DMA controller
+
+Required property:
+- #dma-cells: Number of cells for each DMA line.
+
+
+Example:
+
+   sdma: dma-controller@4800 {
+   compatible = ti,sdma-omap4
+   reg = 0x4800 0x1000;
+   interrupts = 12;
+   #dma-cells = 1;
+   };
+
+
+
+* DMA client
+
+Client drivers should specify the DMA request property using a phandle to
+the controller. If needed, the DMA request identity on that controller is then
+added followed by optional request specifications.
+
+Required property:
+- dma-request: List of phandle + dma-request + request specifications,
+  one group per request line.
+Optional property:
+- dma-request-names: list of strings in the same order as the dma-request
+  in the dma-request property.
+
+
+Example:
+
+   i2c1: i2c@1 {
+   ...
+   dma-request = sdma 2 sdma 3;
+   dma-request-names = tx, rx;
+   ...
+   };
diff --git a/drivers/of/Makefile b/drivers/of/Makefile
index a73f5a5..338c2ee 100644
--- a/drivers/of/Makefile
+++ b/drivers/of/Makefile
@@ -1,4 +1,4 @@
-obj-y = base.o
+obj-y = base.o dma.o
 obj-$(CONFIG_OF_FLATTREE) += fdt.o
 obj-$(CONFIG_OF_PROMTREE) += pdt.o
 obj-$(CONFIG_OF_ADDRESS)  += address.o
diff --git a/drivers/of/dma.c b/drivers/of/dma.c
new file mode 100644
index 000..e58a0dd
--- /dev/null
+++ b/drivers/of/dma.c
@@ -0,0 +1,215 @@
+/*
+ * Device tree helpers for DMA request / controller
+ *
+ * Based on of_gpio.c
+ *
+ * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * 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 linux/device.h
+#include linux/err.h
+#include linux/module.h
+#include linux/rculist.h
+#include linux/slab.h
+#include linux/of.h
+#include linux/of_dma.h
+
+static LIST_HEAD(of_dma_list);
+
+struct of_dma {
+   struct list_head of_dma_controllers;
+   struct device_node *of_node;
+   int of_dma_n_cells;
+   int (*of_dma_xlate)(struct of_phandle_args *dma_spec, void *data);
+};
+
+/**
+ * of_dma_find_controller() - Find a DMA controller in DT DMA helpers list
+ * @np:device node of DMA controller
+ */
+static struct of_dma *of_dma_find_controller(struct device_node *np)
+{
+   struct of_dma   *ofdma;
+
+   list_for_each_entry_rcu(ofdma, of_dma_list, of_dma_controllers) {
+   if (ofdma-of_node == np)
+   return ofdma;
+   }
+
+   return NULL;
+}
+
+/**
+ * of_dma_controller_register() - Register a DMA controller to DT DMA helpers
+ * @np

[PATCH 2/2] of: selftest/dma: Add selftest for new DT DMA request helpers

2012-03-20 Thread Nicolas Ferre

Those selftests are covering the new DT DMA helpers. They will test both
error and normal cases.
A custom .xlate() function is also provided to show the use of this API in case
of a different need than the single cell argument.

Signed-off-by: Nicolas Ferre nicolas.fe...@atmel.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Stephen Warren swar...@nvidia.com
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Russell King li...@arm.linux.org.uk
Cc: Rob Herring rob.herr...@calxeda.com
Cc: Arnd Bergmann a...@arndb.de
---
 arch/arm/boot/dts/at91sam9m10g45ek.dts |2 +
 arch/arm/boot/dts/testcases/tests-dma.dtsi |   24 +++
 arch/arm/boot/dts/testcases/tests.dtsi |1 +
 drivers/of/selftest.c  |  100 
 4 files changed, 127 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/boot/dts/testcases/tests-dma.dtsi

diff --git a/arch/arm/boot/dts/at91sam9m10g45ek.dts 
b/arch/arm/boot/dts/at91sam9m10g45ek.dts
index a387e77..18a8f3c 100644
--- a/arch/arm/boot/dts/at91sam9m10g45ek.dts
+++ b/arch/arm/boot/dts/at91sam9m10g45ek.dts
@@ -38,3 +38,5 @@
};
};
 };
+
+/include/ testcases/tests.dtsi
diff --git a/arch/arm/boot/dts/testcases/tests-dma.dtsi 
b/arch/arm/boot/dts/testcases/tests-dma.dtsi
new file mode 100644
index 000..5f0ba93
--- /dev/null
+++ b/arch/arm/boot/dts/testcases/tests-dma.dtsi
@@ -0,0 +1,24 @@
+
+/ {
+   testcase-data {
+   dma-tests {
+   testdmac0: test-dma-controller0 {
+   #dma-cells = 1;
+   };
+
+   testdmac1: test-dma-controller1 {
+   #dma-cells = 2;
+   };
+
+   dma-slave-a {
+   dma-request = testdmac0 42;
+   };
+   dma-slave-b {
+   dma-request = testdmac1 24; /* wrong number 
of values */
+   };
+   dma-slave-c {
+   dma-request = testdmac1 24 25;
+   };
+   };
+   };
+};
diff --git a/arch/arm/boot/dts/testcases/tests.dtsi 
b/arch/arm/boot/dts/testcases/tests.dtsi
index a7c5067..e3afb2b 100644
--- a/arch/arm/boot/dts/testcases/tests.dtsi
+++ b/arch/arm/boot/dts/testcases/tests.dtsi
@@ -1 +1,2 @@
 /include/ tests-phandle.dtsi
+/include/ tests-dma.dtsi
diff --git a/drivers/of/selftest.c b/drivers/of/selftest.c
index f24ffd7..3281bfd 100644
--- a/drivers/of/selftest.c
+++ b/drivers/of/selftest.c
@@ -9,6 +9,7 @@
 #include linux/errno.h
 #include linux/module.h
 #include linux/of.h
+#include linux/of_dma.h
 #include linux/list.h
 #include linux/mutex.h
 #include linux/slab.h
@@ -148,6 +149,104 @@ static void __init of_selftest_property_match_string(void)
selftest(rc == -EILSEQ, unterminated string; rc=%i, rc);
 }
 
+struct two_cells {
+   int cell1;
+   int cell2;
+};
+
+static int of_dma_xlate_twonumbercell(struct of_phandle_args *dma_spec, void 
*cells)
+{
+   struct two_cells *tc;
+
+   if (!dma_spec)
+   return -EINVAL;
+   if (!cells)
+   return -ENOBUFS;
+   if (WARN_ON(dma_spec-args_count != 2))
+   return -EINVAL;
+
+   tc = (struct two_cells *)cells;
+
+   tc-cell1 = dma_spec-args[0];
+   tc-cell2 = dma_spec-args[1];
+   return 0;
+}
+
+static void __init of_selftest_dma(void)
+{
+   struct device_node *dma_controller0_np;
+   struct device_node *dma_controller1_np;
+   struct device_node *dma_slave_np;
+   int rc;
+   int dma_req;
+   struct two_cells tc;
+
+   pr_info(start\n);
+   dma_controller0_np = 
of_find_node_by_path(/testcase-data/dma-tests/test-dma-controller0);
+   dma_slave_np = 
of_find_node_by_path(/testcase-data/dma-tests/dma-slave-a);
+   if (!dma_controller0_np || !dma_slave_np) {
+   pr_err(No testcase data in device tree\n);
+   return;
+   }
+
+   /* wrong usage: DMA controller not registered yet! */
+   rc = of_get_dma_request(dma_slave_np, 0, dma_req);
+   selftest(rc == -ENODEV, selftest DMA slave request expected:-ENODEV 
got:%i\n, rc);
+
+   /* test DMA controller registration */
+   rc = of_dma_controller_register(dma_controller0_np, 
of_dma_xlate_onenumbercell);
+   selftest(rc == 0, selftest DMA controller not found: got:%i\n, rc);
+
+   /* wrong usage and error code tests */
+   rc = of_get_dma_request(dma_slave_np, 1, dma_req);
+   selftest(rc == -EINVAL, selftest DMA slave request expected:-EINVAL 
got:%i\n, rc);
+
+   rc = of_get_dma_request(dma_slave_np, 0, NULL);
+   selftest(rc == -ENOBUFS, selftest DMA slave request expected:-ENOBUFS 
got:%i\n, rc);
+
+   /* proper use of the API */
+   rc = of_get_dma_request(dma_slave_np, 0, dma_req);
+   selftest(rc == 0, selftest DMA slave request error: got:%i

[PATCH] of: dma/fixup

2012-03-20 Thread Nicolas Ferre

---
 include/linux/of_dma.h |6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/include/linux/of_dma.h b/include/linux/of_dma.h
index 2865480..da95e37 100644
--- a/include/linux/of_dma.h
+++ b/include/linux/of_dma.h
@@ -18,7 +18,7 @@
 
 struct device_node;
 
-#ifdef CONFIG_OF_DMA
+#ifdef CONFIG_OF
 
 extern int of_dma_controller_register(struct device_node *np,
int (*of_dma_xlate)(struct of_phandle_args *, void *));
@@ -29,7 +29,7 @@ extern unsigned int of_dma_count(struct device_node *np);
 
 extern int of_dma_xlate_onenumbercell(struct of_phandle_args *dma_spec,
  void *dma_req);
-#else /* CONFIG_OF_DMA */
+#else /* CONFIG_OF */
 
 static int of_dma_controller_register(struct device_node *np,
int (*of_dma_xlate)(struct of_phandle_args *, void *))
@@ -55,6 +55,6 @@ static int of_dma_xlate_onenumbercell(struct of_phandle_args 
*dma_spec,
 {
return -ENOSYS;
 }
-#endif /* CONFIG_OF_DMA */
+#endif /* CONFIG_OF */
 
 #endif /* __LINUX_OF_DMA_H */
-- 
1.7.9

--
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] of: Add generic device tree DMA helpers

2012-03-20 Thread Nicolas Ferre

On 03/19/2012 03:45 PM, Grant Likely :
 On Mon, 19 Mar 2012 14:30:05 +0100, Nicolas Ferre nicolas.fe...@atmel.com 
 wrote:
 On 03/17/2012 10:40 AM, Grant Likely :
 On Thu, 15 Mar 2012 09:38:10 +0100, Nicolas Ferre nicolas.fe...@atmel.com 
 wrote:
 +struct of_dma {
 +  struct list_head of_dma_controllers;
 +  struct device_node *of_node;
 +  int of_dma_n_cells;
 +  int (*of_dma_xlate)(struct of_phandle_args *dma_spec, void *data);
 +};

 This _xlate is nearly useless as a generic API.  It solves the problem for
 the specific case where the driver is hard-coded to know which DMA engine
 to talk to, but since the returned data doesn't provide any context, it
 isn't useful if there are multiple DMA controllers to choose from.

 You mean, if there is no DMA controller phandle specified in the
 property?
 
 No; I'm assuming that dma-channel properties will alwasy have a
 phandle to the dma controller node.
 
 I think that it is not the purpose of this API to choose a DMA
 controller, Nor to provide a channel. The only purpose of this API is to
 give a HW request to be used by a DMA slave driver. This slave should
 already have a channel to use and a controller to talk to.
 
 Then where is the function that finds the reference to the DMA
 controller?  I don't understand why it would be useful to decode that
 separately.
 
 The void *data pointer must be replaced with a typed structure so that
 context can be returned.

 I am not sure to follow you entirely... How do I address the fact that
 several types of request value can be returned then?

 BTW, can we imagine a phandle property with a sting as a argument?
 should it be written this way?
 dma-request = testdmac1, slave-rx, slave-tx;
 
 No, I'm not suggesting that.  Mixing phandles and strings in a single
 property is possible but ugly.  The phandle-args pattern which uses
 zero or more cells as arguments should be used.
 

 If yes, the of_parse_phandle_with_args() is not working on this type...
 
 Right; of_parse_phandle_with_args() should do the job.
 

 (I realize that there seems to be no way out for a generic API: maybe we
 should move to one or two cases to address and concentrate on them).
 
 The way I read this patch, the xlate function returns a single
 integer representing the DMA request number, but it doesn't provide
 any data about *which* dma controller is associated with that channel.
 The result of xlate needs to be something like a dma_chan reference
 that identifies both the DMA engine and the channel/request on that
 dma engine.
 
 [...]
 +/**
 + * of_dma_xlate_onenumbercell() - Generic DMA xlate for direct one cell 
 bindings
 + *
 + * Device Tree DMA translation function which works with one cell bindings
 + * where the cell values map directly to the hardware request number 
 understood
 + * by the DMA controller.
 + */
 +int of_dma_xlate_onenumbercell(struct of_phandle_args *dma_spec, void 
 *dma_req)
 +{
 +  if (!dma_spec)
 +  return -EINVAL;
 +  if (WARN_ON(dma_spec-args_count != 1))
 +  return -EINVAL;
 +  *(int *)dma_req = dma_spec-args[0];

 Following on from comment above; the void *dma_req parameter is dangerous.  
 How
 does this function know that it has been passed an int* pointer?

 Well, that is a drawback that comes from having to address generic
 cases.
 
 Not if you do it right.  If a specific data structure is returned,
 then there can be context attached as to what the data means and which
 dma controller knows how to parse it.
 
 But anyway, if the DMA controller decide to register a .xlate()
 function that returns an integer, the slave driver that will ask a
 request line to this DMA controller will be aware that an integer has
 to be passed to of_get_dma_request().
 
 The problem still remains; I don't see how the dma slave can figure
 out *which* dma controller it needs to talk to.

Is not it what the phandle to the dma controller is made for?

Bye,
-- 
Nicolas Ferre
--
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] of: Add generic device tree DMA helpers

2012-03-19 Thread Nicolas Ferre

On 03/17/2012 10:40 AM, Grant Likely :
 On Thu, 15 Mar 2012 09:38:10 +0100, Nicolas Ferre nicolas.fe...@atmel.com 
 wrote:
 Add some basic helpers to retrieve a DMA controller device_node and the
 DMA request specifications. By making DMA controllers register a generic
 translation function, we allow the management of any type of DMA requests
 specification.
 The void * output of an of_dma_xlate() function that will be implemented
 by the DMA controller can carry any type of dma-request argument.

 The DMA client will search its associated DMA controller in the list and
 call the registered of_dam_xlate() function to retrieve the request values.

 One simple xlate function is provided for the single number type of
 request binding.

 This implementation is independent from dmaengine so it can also be used
 by legacy drivers.

 For legacy reason another API will export the DMA request number into a
 Linux resource of type IORESOURCE_DMA.

 Signed-off-by: Nicolas Ferre nicolas.fe...@atmel.com
 Signed-off-by: Benoit Cousson b-cous...@ti.com
 
 Hi Nicolas,
 
 Comments below.
 
 Cc: Stephen Warren swar...@nvidia.com
 Cc: Grant Likely grant.lik...@secretlab.ca
 Cc: Russell King li...@arm.linux.org.uk
 Cc: Rob Herring rob.herr...@calxeda.com
 ---
  Documentation/devicetree/bindings/dma/dma.txt |   45 +
  drivers/of/Kconfig|5 +
  drivers/of/Makefile   |1 +
  drivers/of/dma.c  |  260 
 +
  include/linux/of_dma.h|   67 +++
  5 files changed, 378 insertions(+), 0 deletions(-)
  create mode 100644 Documentation/devicetree/bindings/dma/dma.txt
  create mode 100644 drivers/of/dma.c
  create mode 100644 include/linux/of_dma.h

 diff --git a/Documentation/devicetree/bindings/dma/dma.txt 
 b/Documentation/devicetree/bindings/dma/dma.txt
 new file mode 100644
 index 000..c49e98d
 --- /dev/null
 +++ b/Documentation/devicetree/bindings/dma/dma.txt
 @@ -0,0 +1,45 @@
 +* Generic DMA Controller and DMA request bindings
 +
 +Generic binding to provide a way for a driver to retrieve the
 +DMA request line that goes from an IP to a DMA controller.
 +
 +
 +* DMA controller
 +
 +Required property:
 +- #dma-cells: Number of cells for each DMA line.
 +
 +
 +Example:
 +
 +sdma: dma-controller@4800 {
 +compatible = ti,sdma-omap4
 +reg = 0x4800 0x1000;
 +interrupts = 12;
 +#dma-cells = 1;
 +};
 +
 +
 +
 +* DMA client
 +
 +Client drivers should specify the DMA request property using a phandle to
 +the controller. If needed, the DMA request identity on that controller is 
 then
 +added followed by optional request specifications.
 +
 +Required property:
 +- dma-request: List of phandle + dma-request + request specifications,
 +  one group per request line.
 +Optional property:
 +- dma-request-names: list of strings in the same order as the 
 dma-request
 +  in the dma-request property.
 +
 +
 +Example:
 +
 +i2c1: i2c@1 {
 +...
 +dma-request = sdma 2 sdma 3;
 +dma-request-names = tx, rx;
 +...
 +};
 diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig
 index 268163d..7d1f06b 100644
 --- a/drivers/of/Kconfig
 +++ b/drivers/of/Kconfig
 @@ -90,4 +90,9 @@ config OF_PCI_IRQ
  help
OpenFirmware PCI IRQ routing helpers
  
 +config OF_DMA
 +def_bool y
 +help
 +  Device Tree DMA routing helpers
 
 Not really any point in having this config symbol at all if it is
 always enabled.

Well, it is the same for:
config OF_DEVICE

But for sure, I can remove it: so I will add it to
obj-y = base.o here
in the Makefile.

  endmenu # OF
 diff --git a/drivers/of/Makefile b/drivers/of/Makefile
 index a73f5a5..6eb50c6 100644
 --- a/drivers/of/Makefile
 +++ b/drivers/of/Makefile
 @@ -12,3 +12,4 @@ obj-$(CONFIG_OF_SELFTEST) += selftest.o
  obj-$(CONFIG_OF_MDIO)   += of_mdio.o
  obj-$(CONFIG_OF_PCI)+= of_pci.o
  obj-$(CONFIG_OF_PCI_IRQ)  += of_pci_irq.o
 +obj-$(CONFIG_OF_DMA)+= dma.o
 diff --git a/drivers/of/dma.c b/drivers/of/dma.c
 new file mode 100644
 index 000..3315844
 --- /dev/null
 +++ b/drivers/of/dma.c
 @@ -0,0 +1,260 @@
 +/*
 + * Device tree helpers for DMA request / controller
 + *
 + * Based on of_gpio.c
 + *
 + * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/
 + *
 + * 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 linux/device.h
 +#include linux/err.h
 +#include linux/module.h
 +#include linux/rculist.h
 +#include linux/slab.h
 +#include linux/of.h
 +#include linux/of_dma.h
 +
 +static LIST_HEAD(of_dma_list);
 +
 +struct of_dma {
 +struct list_head of_dma_controllers;
 +struct device_node *of_node;
 +int of_dma_n_cells;
 +int

Re: [PATCH] of: Add generic device tree DMA helpers

2012-03-19 Thread Nicolas Ferre

On 03/18/2012 09:13 PM, Arnd Bergmann :
 On Saturday 17 March 2012, Grant Likely wrote:
 +static LIST_HEAD(of_dma_list);
 +
 +struct of_dma {
 + struct list_head of_dma_controllers;
 + struct device_node *of_node;
 + int of_dma_n_cells;
 + int (*of_dma_xlate)(struct of_phandle_args *dma_spec, void *data);
 +};

 This _xlate is nearly useless as a generic API.  It solves the problem for
 the specific case where the driver is hard-coded to know which DMA engine
 to talk to, but since the returned data doesn't provide any context, it
 isn't useful if there are multiple DMA controllers to choose from.

 The void *data pointer must be replaced with a typed structure so that
 context can be returned.
 
 I've read up a bit more on how the existing drivers use the filter
 functions, it seems there are multiple classes of them, the classes
 that I've encountered are:
 
 1. matches on chan-device pointer and/or chan_id

I have the impression that we are now talking about *channel* selection.
It is not the purpose of those helper functions. It is just to retrieve
a *request line* for a particular slave interface. The
selection/filtering of a channel is a different topic (that we can
address in the future).
Maybe some DMA controllers are able to handle several request lines
among several DMA controller instances. But I suspect that this case
should be handled in another place, before calling this API.

(8 drivers)
 2. will match anything
(6 drivers)
 3. requires specific dma engine driver, then behaves like 1 or 2
(8 drivers, almost all freescale)
 4. one of a kind, matches resource name string or device-dev_id
(two drivers)
 5. filter function and data both provided by platform code,
platform picks dmaengine driver.
(4 amba pl* drivers, used on ARM, ux500, ...)
 
 The last category is interesting because here, the dmaengine
 driver (pl330, coh901318, sirf-dma, ste_dma40) provides the filter
 function while in the other cases that is provided by the device
 driver! Out of these, the ste_dma40 is special because it's the
 only one where the data is a complex data structure describing the
 constraints on the driver, while all others just find the right
 channel.
 
 Some drivers also pass assign driver specific data to chan-private.
 
 I would hope that we can all make them use something like
  struct dma_channel *of_dma_request_channel(struct of_node*,
   int index, void *driver_data);
 with an appropriate common definition behind it. In the cases
 where the driver can just match anything, I'd assume that all
 channels are equal, so #dma-cells would be 0. For the ste_dma40,
 #dma-cells needs to cover all of stedma40_chan_cfg. In most
 other cases, #dma-cells can be 1 and just enumerate the channels,
 unless we want to simplify the cases that Russell mentioned where
 we want to keep a two stage mapping channel identifiers and physical
 channel numbers.
 
 How about an implementation like this:?
 
 typedef bool dma_filter_simple(struct dma_chan *chan, void *filter_param)
 {
   /* zero #dma-cells, accept anything */
   return true;
 }
 
 struct dma_channel *of_dma_request_channel(struct of_node*, int index,
   dma_cap_mask_t *mask,
   void *driver_data)
 {
   struct of_phandle_args dma_spec;
   struct dma_device *device;
   struct dma_chan *chan = NULL;
   dma_filter_fn *filter;
 
   ret = of_parse_phandle_with_args(np, dma-request, #dma-cells,
index, dma_spec);

Well, this property handles request lines not channels. So if we
move the selection/filtering of channels in DT, we may need to create a
new property of this purpose...


 
   device = dma_find_device(dma_spec-np);
   if (!device)
   goto out;
 
   if (dma_spec-args_count == 0)
   filter = dma_filter_simple;
   else
   filter = device-dma_dt_filter; /* new member */
 
   chan = private_candidate(mask, device, filter, dma_spec-args);
 
   if (chan  !chan-private)
   chan-private = driver_data;
 out:
   return chan;
 }
 
   Arnd
 


-- 
Nicolas Ferre
--
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] of: Add generic device tree DMA helpers

2012-03-19 Thread Nicolas Ferre

On 03/19/2012 04:33 PM, Russell King - ARM Linux :
 On Mon, Mar 19, 2012 at 02:06:34PM +, Arnd Bergmann wrote:
  mmci 
 /* in drivers/dma/ste_dma40.c, others in pl330.c, coh901318.c, ... */
 bool stedma40_filter(struct dma_chan *chan, void *data)
 {   
 struct stedma40_chan_cfg *info = data;
 struct d40_chan *d40c = container_of(chan, struct d40_chan, chan);
 int err;
 
 err = d40_validate_conf(d40c, info);
 if (!err)
 d40c-dma_cfg = *info;
 d40c-configured = true;
 
 return err == 0;
 }
 EXPORT_SYMBOL(stedma40_filter);

 /* in mmci.h */
 struct mmci_platform_data {
  ...
 bool (*dma_filter)(struct dma_chan *chan, void *filter_param);
 void *dma_rx_param;
 void *dma_tx_param;
 };

 /* in mmci.c */
 static void __devinit mmci_dma_setup(struct mmci_host *host)
 {
  ...
 host-dma_rx_channel = dma_request_channel(mask, plat-dma_filter, 
 plat-dma_rx_param);
  ...
 }

 

 Whatever we come up with obviously needs to work with both drivers.
 I think we will end up with something closer to the second one, except
 that the dma parameters do not come from platform_data but from the
 #dma-request property, which also identifies the controller and channel.
 
 Firstly, define what you mean by the DMA parameters.  Things like burst
 size, register width, register address?  That should all be known by the
 peripheral driver and _not_ be encoded into DT in any way - and this
 information should be passed to the DMA engine driver for the well defined
 API for that purpose.
 
 Secondly, there are platforms (Samsung) where peripherals are connected
 to more than one DMA controller, and either DMA controller can be used -
 I'm told by Jassi that there's reasons why you'd want to select one or
 other as the target at runtime.
 
 Whether it's appropriate for DT to know that or not, I'm not certain at
 the moment - I suspect the _right_ solution would be a radical DMA engine
 redesign which moves _all_ slave DMA to a virtual channel representation,
 and for the virtual channels to be scheduled onto a set of physical DMA
 channels over a range of DMA devices.  Obviously, there's restrictions on
 which virtual channels could be scheduled onto which physical channels of
 which DMA devices.

OMG! the dmaengine drivers are already not so obvious to understand. I
fear that trying to mimic some special behaviors within relatively
simple dmaengine drivers will bring confusion and prevent people to
read/contribute and fix those simple ones...

 It seems to me, therefore, that any attempt to come up with some kind of
 DT based representation of the current scheme is doomed to fail, and will
 at some point become obsolete.
 
 I think instead, rather than trying to fix this now, we persist with what
 we have, but organize an effort to clean up and restructure the DMA engine
 code so that:
 
 (a) things like the Samsung, and ARM board oddities can be easily dealt
  with in a driver independent manner.
 (b) get rid of all the duplicated functionality between each different
  DMA engine implementation, separating this out into core code, and
  simplifying the drivers.
 
 The _big_ problem I see is that if we try to represent the existing
 solution in DT, we're going to get locked into that way of doing things
 and then any major restructuring of the DMA engine stuff will become an
 impossibility - especially if we start specifying things by DMA request
 signal numbers on DMA engines.

Even if I understand your point, I wonder what is the solution for us
that have a pretty simple representation of *hardware* to code into DT:
should we wait for a big rework? Should we go for a private DMA binding
for each of us that have just the need for a quite simple representation?

I must say that I am puzzled by recent discussion on the topic (mix of
channel and request notions, plan for a complete rework of dmaengine
that can delay DT representation of DMA slave-controller relationship,
even my own doubts on the void * output parameter, etc.). It seems
that I am not familiar with all those cases and that I cannot go further
with a generic DT representation...

Best regards,
-- 
Nicolas Ferre
--
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] of: Add generic device tree DMA helpers

2012-03-16 Thread Nicolas Ferre

On 03/16/2012 02:28 PM, Cousson, Benoit :
 On 3/16/2012 1:04 PM, Arnd Bergmann wrote:
 On Friday 16 March 2012, Cousson, Benoit wrote:
 And it seems that other ARM SoCs are using it for the same purpose.
 There are at least 230+ IORESOURCE_DMA instances in the kernel today.

 These tend to be the ones that don't use dmaengine but either the
 ISA dma api or a platform specific variant of that, right?

 Also, I think that most of those definitions are for the same few
 devices. The number that I see is much lower:

 $ git grep -l IORESOURCE_DMA drivers/ sound/ | wc -l
   51
 
 Gosh, good point... I've just done a dumb grep, but most of them are in
 the device creation inside arch code:-(
 
 Assuming OMAP driver does contains omap in the name, the result is
 indeed way smaller.
 
 git grep -l IORESOURCE_DMA drivers/ sound/ | grep omap
 
 drivers/crypto/omap-aes.c
 drivers/crypto/omap-sham.c
 drivers/spi/spi-omap2-mcspi.c
 drivers/tty/serial/omap-serial.c
 sound/soc/omap/omap-dmic.c
 sound/soc/omap/omap-hdmi.c
 
 We do have 127 DMA requests and only 6 drivers are using them, that's a
 pity...
 
 Out of those, a quite number are mips or blackfin or xtensa based, or are
 for legacy ISA devices, which leaves 29 drivers for ARM.

 For the moment it is still used in a lot of places, and without any
 other better API yet, it is still useful. As written it is there only
 for simple single DMA controller case.

 By maintaining that IORESOURCE_DMA for the moment we can adapt some
 driver to DT without having to change the way they are retrieving
 information. By using IORESOURCE_IRQ and IORESOURCE_MEM, we had the same
 advantage.

 The main difference to IORESOURCE_IRQ and IORESOURCE_MEM that I see
 is that those are going to start for any forseeable time and are actually
 helpful in a lot of ways. We are not going to remove the single number
 space for interrupts in the next few years. For DMA, the dmaengine API
 has already moved away from the flat number space of the ISA API.

 Otherwise how are we supposed to get the DMA channel for non-DT boot
 until we have migrated everything to DT? A bunch of ARM SoC are using
 IORESOURCE_DMA for the same purpose.

 The goal here is really to maintain that during the transition phase
 only. As soon as the full DT support is there, we can switch to the
 of_ API.

 Ideally, we should define and use a generic API non dependent of DT.
 AFAIK, that does not exist so far.
 And since most drivers are not using dmaengine, we do not even have a
 common DMA fmwk to define an API on top.

 I fully agree that this IORESOURCE_DMA is not scalable for multiple
 controller, ugly, and must be avoided like the plague.
 But what other options do we have during the transition?

 We could use the same binding for the nonstandard controllers, but
 keep the dma channel number lookup separate for those, and let them
 call of_get_dma_request directly.

 Since there are not too many drivers using those controllers with
 dma resources today, it's fairly easy to go through those as we write
 the driver bindings and just do

 err = of_get_dma_request(pdev-dev.of_node, 0,dma);
 if (err) {
 struct resource *r = platform_get_resource(pdev,
 IORESOURCE_DMA, 0);
 if (r)
 dma = r-start;
 }

 For the drivers that we convert to DT before we convert them to
 dmaengine,
 and not do anything if we convert them to dmaengine first.
 
 Considering the small amount of OMAP drivers really using
 IORESOURCE_DMA, I guess this is fair enough.
 
 Bottom-line, I do not have any more issue removing this of_dma_to_resource.
 
 
 Nico,
 Is that OK for you to repost the patch without this function?

Yes sure, I will repost a V2 soon.

I also try to have an integration in DT selftest.c:
- that will show some possibilities of the API
- that will give some examples of usage (1 or 2 xlate() functions)
- that made me review my code and find a weakness
- that will allow to monitor non-regression (obviously)
= WIP...

Bye,
-- 
Nicolas Ferre
--
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] of: Add generic device tree DMA helpers

2012-03-15 Thread Nicolas Ferre

Add some basic helpers to retrieve a DMA controller device_node and the
DMA request specifications. By making DMA controllers register a generic
translation function, we allow the management of any type of DMA requests
specification.
The void * output of an of_dma_xlate() function that will be implemented
by the DMA controller can carry any type of dma-request argument.

The DMA client will search its associated DMA controller in the list and
call the registered of_dam_xlate() function to retrieve the request values.

One simple xlate function is provided for the single number type of
request binding.

This implementation is independent from dmaengine so it can also be used
by legacy drivers.

For legacy reason another API will export the DMA request number into a
Linux resource of type IORESOURCE_DMA.

Signed-off-by: Nicolas Ferre nicolas.fe...@atmel.com
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Stephen Warren swar...@nvidia.com
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Russell King li...@arm.linux.org.uk
Cc: Rob Herring rob.herr...@calxeda.com
---
 Documentation/devicetree/bindings/dma/dma.txt |   45 +
 drivers/of/Kconfig|5 +
 drivers/of/Makefile   |1 +
 drivers/of/dma.c  |  260 +
 include/linux/of_dma.h|   67 +++
 5 files changed, 378 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/dma/dma.txt
 create mode 100644 drivers/of/dma.c
 create mode 100644 include/linux/of_dma.h

diff --git a/Documentation/devicetree/bindings/dma/dma.txt 
b/Documentation/devicetree/bindings/dma/dma.txt
new file mode 100644
index 000..c49e98d
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/dma.txt
@@ -0,0 +1,45 @@
+* Generic DMA Controller and DMA request bindings
+
+Generic binding to provide a way for a driver to retrieve the
+DMA request line that goes from an IP to a DMA controller.
+
+
+* DMA controller
+
+Required property:
+- #dma-cells: Number of cells for each DMA line.
+
+
+Example:
+
+   sdma: dma-controller@4800 {
+   compatible = ti,sdma-omap4
+   reg = 0x4800 0x1000;
+   interrupts = 12;
+   #dma-cells = 1;
+   };
+
+
+
+* DMA client
+
+Client drivers should specify the DMA request property using a phandle to
+the controller. If needed, the DMA request identity on that controller is then
+added followed by optional request specifications.
+
+Required property:
+- dma-request: List of phandle + dma-request + request specifications,
+  one group per request line.
+Optional property:
+- dma-request-names: list of strings in the same order as the dma-request
+  in the dma-request property.
+
+
+Example:
+
+   i2c1: i2c@1 {
+   ...
+   dma-request = sdma 2 sdma 3;
+   dma-request-names = tx, rx;
+   ...
+   };
diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig
index 268163d..7d1f06b 100644
--- a/drivers/of/Kconfig
+++ b/drivers/of/Kconfig
@@ -90,4 +90,9 @@ config OF_PCI_IRQ
help
  OpenFirmware PCI IRQ routing helpers
 
+config OF_DMA
+   def_bool y
+   help
+ Device Tree DMA routing helpers
+
 endmenu # OF
diff --git a/drivers/of/Makefile b/drivers/of/Makefile
index a73f5a5..6eb50c6 100644
--- a/drivers/of/Makefile
+++ b/drivers/of/Makefile
@@ -12,3 +12,4 @@ obj-$(CONFIG_OF_SELFTEST) += selftest.o
 obj-$(CONFIG_OF_MDIO)  += of_mdio.o
 obj-$(CONFIG_OF_PCI)   += of_pci.o
 obj-$(CONFIG_OF_PCI_IRQ)  += of_pci_irq.o
+obj-$(CONFIG_OF_DMA)   += dma.o
diff --git a/drivers/of/dma.c b/drivers/of/dma.c
new file mode 100644
index 000..3315844
--- /dev/null
+++ b/drivers/of/dma.c
@@ -0,0 +1,260 @@
+/*
+ * Device tree helpers for DMA request / controller
+ *
+ * Based on of_gpio.c
+ *
+ * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * 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 linux/device.h
+#include linux/err.h
+#include linux/module.h
+#include linux/rculist.h
+#include linux/slab.h
+#include linux/of.h
+#include linux/of_dma.h
+
+static LIST_HEAD(of_dma_list);
+
+struct of_dma {
+   struct list_head of_dma_controllers;
+   struct device_node *of_node;
+   int of_dma_n_cells;
+   int (*of_dma_xlate)(struct of_phandle_args *dma_spec, void *data);
+};
+
+/**
+ * of_dma_find_controller() - Find a DMA controller in DT DMA helpers list
+ * @np:device node of DMA controller
+ */
+static struct of_dma *of_dma_find_controller(struct device_node *np)
+{
+   struct of_dma   *ofdma;
+
+   list_for_each_entry_rcu(ofdma, of_dma_list, of_dma_controllers) {
+   if (ofdma-of_node == np)
+   return ofdma

Re: [RFC PATCH] of: DMA helpers: manage generic requests specification

2012-03-14 Thread Nicolas Ferre

On 03/05/2012 04:36 PM, Grant Likely :
 On Wed, Feb 29, 2012 at 03:54:08PM +0100, Nicolas Ferre wrote:
 By making DMA controllers register a generic translation
 function, we allow the management of any type of DMA requests
 specification.
 The void * output of an of_dma_xlate() function that will be implemented
 by the DMA controller can carry any type of dma-request argument.

 The DMA client will search its associated DMA controller in the list
 and call the registered of_dam_xlate() function to retrieve the
 request values.

 One simple xlate function is provided for the single number type
 of request biding.

 This implementation is independent from dmaengine so it can also be
 used by legacy drivers.

 Signed-off-by: Nicolas Ferre nicolas.fe...@atmel.com
 Cc: Benoit Cousson b-cous...@ti.com
 Cc: Stephen Warren swar...@nvidia.com
 Cc: Grant Likely grant.lik...@secretlab.ca
 Cc: Russell King li...@arm.linux.org.uk
 Cc: Rob Herring rob.herr...@calxeda.com
 ---
 Hi all,

 Here are my thoughts about the DMA helpers for device tree.
 This patch goes on top of Benoit's ones. My goal was to keep this separated
 from any DMA infrastructure (dmaengine not needed, nor any other DMA
 implementation).

 It is to keep the ball rolling, so do not hesitate to comment.

 Best regards,


  Documentation/devicetree/bindings/dma/dma.txt |   29 +++--
  drivers/of/dma.c  |  161 
 ++---
  include/linux/of_dma.h|   33 +-
  3 files changed, 186 insertions(+), 37 deletions(-)

 diff --git a/Documentation/devicetree/bindings/dma/dma.txt 
 b/Documentation/devicetree/bindings/dma/dma.txt
 index 7f2a301..c49e98d 100644
 --- a/Documentation/devicetree/bindings/dma/dma.txt
 +++ b/Documentation/devicetree/bindings/dma/dma.txt
 @@ -6,9 +6,8 @@ DMA request line that goes from an IP to a DMA controller.
  
  * DMA controller
  
 -Required properties:
 -- dma-controller: Mark the device as a DMA controller
 -- #dma-cells: Number of cell for each DMA line, must be one.
 +Required property:
 +- #dma-cells: Number of cells for each DMA line.
  
  
  Example:
 @@ -17,7 +16,6 @@ Example:
  compatible = ti,sdma-omap4
  reg = 0x4800 0x1000;
  interrupts = 12;
 -dma-controller;
  #dma-cells = 1;
  };
  
 @@ -25,20 +23,23 @@ Example:
  
  * DMA client
  
 -Client drivers should specify the DMA request numbers using a phandle to
 -the controller + the DMA request number on that controller.
 +Client drivers should specify the DMA request property using a phandle to
 +the controller. If needed, the DMA request identity on that controller is 
 then
 +added followed by optional request specifications.
  
 -Required properties:
 -- dma-request: List of pair phandle + dma-request per line
 +Required property:
 +- dma-request: List of phandle + dma-request + request specifications,
 +  one group per request line.
 +Optional property:
  - dma-request-names: list of strings in the same order as the 
 dma-request
in the dma-request property.
  
  
  Example:
  
 -i2c1: i2c@1 {
 -...
 -dma-request = sdma 2 sdma 3;
 -dma-request-names = tx, rx;
 -...
 -};
 +i2c1: i2c@1 {
 +...
 +dma-request = sdma 2 sdma 3;
 +dma-request-names = tx, rx;
 +...
 +};
 diff --git a/drivers/of/dma.c b/drivers/of/dma.c
 index d4927e2..e0c6fd9 100644
 --- a/drivers/of/dma.c
 +++ b/drivers/of/dma.c
 @@ -13,41 +13,145 @@
  #include linux/device.h
  #include linux/err.h
  #include linux/module.h
 +#include linux/rculist.h
 +#include linux/slab.h
  #include linux/of.h
  #include linux/of_dma.h
  
 +static LIST_HEAD(of_dma_list);
 +
 +/**
 + * of_dma_find_controller() - Find a DMA controller in DT DMA helpers list
 + * @np: device node of DMA controller
 + */
 +static struct of_dma *of_dma_find_controller(struct device_node *np)
 +{
 +struct of_dma   *ofdma;
 +
 +list_for_each_entry_rcu(ofdma, of_dma_list, of_dma_controllers) {
 +if (ofdma-of_node == np)
 +return ofdma;
 +}
 +
 +return NULL;
 +}
 +
  /**
 - * of_get_dma_request() - Get a DMA request number and dma-controller node
 + * of_dma_controller_register() - Register a DMA controller to DT DMA 
 helpers
 + * @np: device node of DMA controller
 + * @of_dma_xlate:   generic translation function which converts a phandle
 + *  arguments list into a generic output value
 + *
 + * Returns 0 on success or appropriate errno value on error.
 + *
 + * If #dma-cells is not specified in DMA controller device tree node, we 
 assume
 + * that the DMA controller phandle will come without argument.
 + *
 + * Allocated memory sould be freed with apropriate of_dma_controller_free()
 + * call.
 + */
 +int of_dma_controller_register(struct device_node *np,
 +int

[RFC PATCH] of: DMA helpers: manage generic requests specification

2012-02-29 Thread Nicolas Ferre

By making DMA controllers register a generic translation
function, we allow the management of any type of DMA requests
specification.
The void * output of an of_dma_xlate() function that will be implemented
by the DMA controller can carry any type of dma-request argument.

The DMA client will search its associated DMA controller in the list
and call the registered of_dam_xlate() function to retrieve the
request values.

One simple xlate function is provided for the single number type
of request biding.

This implementation is independent from dmaengine so it can also be
used by legacy drivers.

Signed-off-by: Nicolas Ferre nicolas.fe...@atmel.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Stephen Warren swar...@nvidia.com
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Russell King li...@arm.linux.org.uk
Cc: Rob Herring rob.herr...@calxeda.com
---
Hi all,

Here are my thoughts about the DMA helpers for device tree.
This patch goes on top of Benoit's ones. My goal was to keep this separated
from any DMA infrastructure (dmaengine not needed, nor any other DMA
implementation).

It is to keep the ball rolling, so do not hesitate to comment.

Best regards,


 Documentation/devicetree/bindings/dma/dma.txt |   29 +++--
 drivers/of/dma.c  |  161 ++---
 include/linux/of_dma.h|   33 +-
 3 files changed, 186 insertions(+), 37 deletions(-)

diff --git a/Documentation/devicetree/bindings/dma/dma.txt 
b/Documentation/devicetree/bindings/dma/dma.txt
index 7f2a301..c49e98d 100644
--- a/Documentation/devicetree/bindings/dma/dma.txt
+++ b/Documentation/devicetree/bindings/dma/dma.txt
@@ -6,9 +6,8 @@ DMA request line that goes from an IP to a DMA controller.
 
 * DMA controller
 
-Required properties:
-- dma-controller: Mark the device as a DMA controller
-- #dma-cells: Number of cell for each DMA line, must be one.
+Required property:
+- #dma-cells: Number of cells for each DMA line.
 
 
 Example:
@@ -17,7 +16,6 @@ Example:
compatible = ti,sdma-omap4
reg = 0x4800 0x1000;
interrupts = 12;
-dma-controller;
#dma-cells = 1;
};
 
@@ -25,20 +23,23 @@ Example:
 
 * DMA client
 
-Client drivers should specify the DMA request numbers using a phandle to
-the controller + the DMA request number on that controller.
+Client drivers should specify the DMA request property using a phandle to
+the controller. If needed, the DMA request identity on that controller is then
+added followed by optional request specifications.
 
-Required properties:
-- dma-request: List of pair phandle + dma-request per line
+Required property:
+- dma-request: List of phandle + dma-request + request specifications,
+  one group per request line.
+Optional property:
 - dma-request-names: list of strings in the same order as the dma-request
   in the dma-request property.
 
 
 Example:
 
-i2c1: i2c@1 {
-...
-dma-request = sdma 2 sdma 3;
-dma-request-names = tx, rx;
-...
-};
+   i2c1: i2c@1 {
+   ...
+   dma-request = sdma 2 sdma 3;
+   dma-request-names = tx, rx;
+   ...
+   };
diff --git a/drivers/of/dma.c b/drivers/of/dma.c
index d4927e2..e0c6fd9 100644
--- a/drivers/of/dma.c
+++ b/drivers/of/dma.c
@@ -13,41 +13,145 @@
 #include linux/device.h
 #include linux/err.h
 #include linux/module.h
+#include linux/rculist.h
+#include linux/slab.h
 #include linux/of.h
 #include linux/of_dma.h
 
+static LIST_HEAD(of_dma_list);
+
+/**
+ * of_dma_find_controller() - Find a DMA controller in DT DMA helpers list
+ * @np:device node of DMA controller
+ */
+static struct of_dma *of_dma_find_controller(struct device_node *np)
+{
+   struct of_dma   *ofdma;
+
+   list_for_each_entry_rcu(ofdma, of_dma_list, of_dma_controllers) {
+   if (ofdma-of_node == np)
+   return ofdma;
+   }
+
+   return NULL;
+}
+
 /**
- * of_get_dma_request() - Get a DMA request number and dma-controller node
+ * of_dma_controller_register() - Register a DMA controller to DT DMA helpers
+ * @np:device node of DMA controller
+ * @of_dma_xlate:  generic translation function which converts a phandle
+ * arguments list into a generic output value
+ *
+ * Returns 0 on success or appropriate errno value on error.
+ *
+ * If #dma-cells is not specified in DMA controller device tree node, we assume
+ * that the DMA controller phandle will come without argument.
+ *
+ * Allocated memory sould be freed with apropriate of_dma_controller_free()
+ * call.
+ */
+int of_dma_controller_register(struct device_node *np,
+   int (*of_dma_xlate)(struct of_phandle_args *, void *))
+{
+   struct of_dma   *ofdma;
+   int *nbcells;
+
+   if (!np || !of_dma_xlate) {
+   pr_err(%s

Re: [RFC PATCH 1/2] of: Add generic device tree DMA helpers

2012-02-27 Thread Nicolas Ferre

On 02/27/2012 03:22 PM, Cousson, Benoit :
 On 2/27/2012 2:09 PM, Nicolas Ferre wrote:
 On 02/23/2012 04:57 PM, Cousson, Benoit :
 On 2/23/2012 4:51 PM, Nicolas Ferre wrote:
 On 02/23/2012 11:03 AM, Cousson, Benoit :
 Salut Nico,

 Coucou Benoit ;-)

 On 2/22/2012 11:59 AM, Nicolas Ferre wrote:
 On 01/27/2012 06:29 PM, Cousson, Benoit :
 Add some basic helpers to retrieve a DMA controller device_node
 and the DMA request line number.

 For legacy reason another API will export the DMA request number
 into a Linux resource of type IORESOURCE_DMA.
 This API is usable only on system with an unique DMA controller.

 Hi,

 I followed that discussion and I like very much the biding that
 Benoit
 is proposing. It will help me a lot with my current work on Atmel DMA
 controller.

 If I understand correctly, some rework is needed before it can be
 integrated in a stable git tree (I mean before we can base our
 work on
 top of it). So, in the meantime, what should I do to help and make
 things go forward? to be quite frank, I would be interested to have a
 working DMA enabled device soon ;-)

 Me too, but unfortunately, I was busy trying to add irq_domain and
 fixing issues with SPARSE_IRQ on OMAP :-(

 Been there, loved that ;-)

 Do you think that 3.4 is out of reach?

 Maybe not, from the comments, it looks like we should add a .xlate
 callback to allow any custom parsing of the DMA nodes attributes.

 I'll be more than happy, if you can finalize that patch :-)

 I will try to figure out what I can understand from the irq
 mechanism of
 .xlate and try to see if I can implement it on top of your patch.

 In fact that dma code is a big copy/paste of the of/gpio one and gpio
 was already managing .xlate function.
 I removed it because I thought it was useless for the DMA :-)

 You might just have to copy the original code...

 The thing is that with gpio, we can rely on the gpio_chip structure for
 having a common storage location of such .xlate callbacks.
 In our DMA case, I guess that we should not cling to dmaengine
 infrastructure because not all of us are using it right now.
 
 Yep, that's the main issue compared to GPIO or IRQ.
 
 So, maybe we should provide some simple xlate helpers like the
 irqdomain ones. But I fear that a callback directly called from the
 of_get_dma_request() function is not possible (the gpio code model).
 
 I think a well that we cannot much but a simple very abstract callback
 since we do not have any formal DMA representation?
 
 I'm not sure to understand you concern?

Well, in fact I cannot find a place where to store a xlate callback:
- it have to be provided by the DMA controller (the one pointed out by
the phandle) and not the caller of the of_get_dma_request() funtion
- it has to be generic enough to match the dmaengine/non-dmaengine cases
(so it cannot be stored in the dmaengine struct dma_device).

So I guess that the very basic idea of returning the full DMA specifier
(struct of_phandle_args) is the best... My only concern is that the
helper becomes very short and empty in this case...

Bye,
-- 
Nicolas Ferre
--
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 PATCH 1/2] of: Add generic device tree DMA helpers

2012-02-23 Thread Nicolas Ferre

On 02/23/2012 11:03 AM, Cousson, Benoit :
 Salut Nico,

Coucou Benoit ;-)

 On 2/22/2012 11:59 AM, Nicolas Ferre wrote:
 On 01/27/2012 06:29 PM, Cousson, Benoit :
 Add some basic helpers to retrieve a DMA controller device_node
 and the DMA request line number.

 For legacy reason another API will export the DMA request number
 into a Linux resource of type IORESOURCE_DMA.
 This API is usable only on system with an unique DMA controller.

 Hi,

 I followed that discussion and I like very much the biding that Benoit
 is proposing. It will help me a lot with my current work on Atmel DMA
 controller.

 If I understand correctly, some rework is needed before it can be
 integrated in a stable git tree (I mean before we can base our work on
 top of it). So, in the meantime, what should I do to help and make
 things go forward? to be quite frank, I would be interested to have a
 working DMA enabled device soon ;-)
 
 Me too, but unfortunately, I was busy trying to add irq_domain and
 fixing issues with SPARSE_IRQ on OMAP :-(

Been there, loved that ;-)

 Do you think that 3.4 is out of reach?
 
 Maybe not, from the comments, it looks like we should add a .xlate
 callback to allow any custom parsing of the DMA nodes attributes.
 
 I'll be more than happy, if you can finalize that patch :-)

I will try to figure out what I can understand from the irq mechanism of
.xlate and try to see if I can implement it on top of your patch.

I will keep you informed...

Bye,


 Best regards,

 Signed-off-by: Benoit Coussonb-cous...@ti.com
 Cc: Grant Likelygrant.lik...@secretlab.ca
 Cc: Rob Herringrob.herr...@calxeda.com
 ---
   Documentation/devicetree/bindings/dma/dma.txt |   44 +
   drivers/of/Kconfig|5 +
   drivers/of/Makefile   |1 +
   drivers/of/dma.c  |  130
 +
   include/linux/of_dma.h|   49 +
   5 files changed, 229 insertions(+), 0 deletions(-)
   create mode 100644 Documentation/devicetree/bindings/dma/dma.txt
   create mode 100644 drivers/of/dma.c
   create mode 100644 include/linux/of_dma.h

 diff --git a/Documentation/devicetree/bindings/dma/dma.txt
 b/Documentation/devicetree/bindings/dma/dma.txt
 new file mode 100644
 index 000..7f2a301
 --- /dev/null
 +++ b/Documentation/devicetree/bindings/dma/dma.txt
 @@ -0,0 +1,44 @@
 +* Generic DMA Controller and DMA request bindings
 +
 +Generic binding to provide a way for a driver to retrieve the
 +DMA request line that goes from an IP to a DMA controller.
 +
 +
 +* DMA controller
 +
 +Required properties:
 +- dma-controller: Mark the device as a DMA controller
 +- #dma-cells: Number of cell for each DMA line, must be one.
 +
 +
 +Example:
 +
 +sdma: dma-controller@4800 {
 +compatible = ti,sdma-omap4
 +reg =0x4800 0x1000;
 +interrupts =12;
 +dma-controller;
 +#dma-cells =1;
 +};
 +
 +
 +
 +* DMA client
 +
 +Client drivers should specify the DMA request numbers using a
 phandle to
 +the controller + the DMA request number on that controller.
 +
 +Required properties:
 +- dma-request: List of pair phandle + dma-request per line
 +- dma-request-names: list of strings in the same order as the
 dma-request
 +  in the dma-request property.
 +
 +
 +Example:
 +
 +i2c1: i2c@1 {
 +...
 +dma-request =sdma 2sdma 3;
 +dma-request-names = tx, rx;
 +...
 +};
 diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig
 index 268163d..7d1f06b 100644
 --- a/drivers/of/Kconfig
 +++ b/drivers/of/Kconfig
 @@ -90,4 +90,9 @@ config OF_PCI_IRQ
   help
 OpenFirmware PCI IRQ routing helpers

 +config OF_DMA
 +def_bool y
 +help
 +  Device Tree DMA routing helpers
 +
   endmenu # OF
 diff --git a/drivers/of/Makefile b/drivers/of/Makefile
 index a73f5a5..d08443b 100644
 --- a/drivers/of/Makefile
 +++ b/drivers/of/Makefile
 @@ -12,3 +12,4 @@ obj-$(CONFIG_OF_SELFTEST) += selftest.o
   obj-$(CONFIG_OF_MDIO)+= of_mdio.o
   obj-$(CONFIG_OF_PCI)+= of_pci.o
   obj-$(CONFIG_OF_PCI_IRQ)  += of_pci_irq.o
 +obj-$(CONFIG_OF_DMA)  += dma.o
 diff --git a/drivers/of/dma.c b/drivers/of/dma.c
 new file mode 100644
 index 000..d4927e2
 --- /dev/null
 +++ b/drivers/of/dma.c
 @@ -0,0 +1,130 @@
 +/*
 + * Device tree helpers for DMA request / controller
 + *
 + * Based on of_gpio.c
 + *
 + * Copyright (C) 2012 Texas Instruments Incorporated -
 http://www.ti.com/
 + *
 + * 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.
 + */
 +
 +#includelinux/device.h
 +#includelinux/err.h
 +#includelinux/module.h
 +#includelinux/of.h
 +#includelinux/of_dma.h
 +
 +/**
 + * of_get_dma_request() - Get a DMA request number and
 dma-controller node
 + * @np:device node to get DMA request from

Re: [RFC PATCH 1/2] of: Add generic device tree DMA helpers

2012-02-22 Thread Nicolas Ferre

-cells,
 +  index, dma_spec);
 + if (ret) {
 + pr_debug(%s: can't parse dma property\n, __func__);
 + goto err0;
 + }
 +
 + if (dma_spec.args_count  0)
 + ret = dma_spec.args[0];
 +
 + if (ctrl_np)
 + *ctrl_np = dma_spec.np;
 + else
 + of_node_put(dma_spec.np);
 +
 +err0:
 + pr_debug(%s exited with status %d\n, __func__, ret);
 + return ret;
 +}
 +EXPORT_SYMBOL(of_get_dma_request);
 +
 +/**
 + * of_dma_count - Count DMA requests for a device
 + * @np:  device node to count DMAs for
 + *
 + * The function returns the count of DMA requests specified for a node.
 + *
 + * Note that the empty DMA specifiers counts too. For example,
 + *
 + * dma-request = 0
 + *sdma 1
 + *0
 + *sdma 3;
 + *
 + * defines four DMAs (so this function will return 4), two of which
 + * are not specified.
 + */
 +unsigned int of_dma_count(struct device_node *np)
 +{
 + unsigned int cnt = 0;
 +
 + do {
 + int ret;
 +
 + ret = of_parse_phandle_with_args(np, dma-request,
 +  #dma-cells, cnt, NULL);
 + /* A hole in the dma-request =  counts anyway. */
 + if (ret  0  ret != -EEXIST)
 + break;
 + } while (++cnt);
 +
 + return cnt;
 +}
 +EXPORT_SYMBOL(of_dma_count);
 +
 +/**
 + * of_dma_to_resource - Decode a node's DMA and return it as a resource
 + * @dev: pointer to device tree node
 + * @index: zero-based index of the DMA request
 + * @r: pointer to resource structure to return result into.
 + *
 + * Using a resource to export a DMA request number to a driver should
 + * be used only for legacy purpose and on system when only one DMA controller
 + * is present.
 + * The proper and only scalable way is to use the native of_get_dma_request 
 API
 + * in order retrieve both the DMA controller device node and the DMA request
 + * line for that controller.
 + */
 +int of_dma_to_resource(struct device_node *dev, int index, struct resource 
 *r)
 +{
 + const char *name = NULL;
 + int dma;
 +
 + if (!r)
 + return -EINVAL;
 +
 + dma = of_get_dma_request(dev, index, NULL);
 + if (dma  0)
 + return dma;
 +
 + /*
 +  * Get optional dma-request-names property to add a name
 +  * to the resource.
 +  */
 + of_property_read_string_index(dev, dma-request-names, index,
 +   name);
 +
 + r-start = dma;
 + r-end = dma;
 + r-flags = IORESOURCE_DMA;
 + r-name = name ? name : dev-full_name;
 +
 + return dma;
 +}
 +EXPORT_SYMBOL_GPL(of_dma_to_resource);
 diff --git a/include/linux/of_dma.h b/include/linux/of_dma.h
 new file mode 100644
 index 000..575163d
 --- /dev/null
 +++ b/include/linux/of_dma.h
 @@ -0,0 +1,49 @@
 +/*
 + * OF helpers for DMA request / controller
 + *
 + * Based on of_gpio.h
 + *
 + * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/
 + *
 + * 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.
 + */
 +
 +#ifndef __LINUX_OF_DMA_H
 +#define __LINUX_OF_DMA_H
 +
 +#include linux/of.h
 +
 +struct device_node;
 +
 +#ifdef CONFIG_OF_GPIO
 +
 +extern int of_get_dma_request(struct device_node *np, int index,
 +struct device_node **ctrl_np);
 +extern unsigned int of_dma_count(struct device_node *np);
 +extern int of_dma_to_resource(struct device_node *dev, int index,
 +   struct resource *r);
 +
 +#else /* CONFIG_OF_DMA */
 +
 +static int of_get_dma_request(struct device_node *np, int index,
 +   struct device_node **ctrl_np);
 +{
 + return -ENOSYS;
 +}
 +
 +static inline unsigned int of_dma_count(struct device_node *np)
 +{
 + return 0;
 +}
 +
 +static int of_dma_to_resource(struct device_node *dev, int index,
 +   struct resource *r);
 +{
 + return -ENOSYS;
 +}
 +
 +#endif /* CONFIG_OF_DMA */
 +
 +#endif /* __LINUX_OF_DMA_H */


-- 
Nicolas Ferre
--
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: ARM/ARM-SoC plans for v3.4 merge window

2012-02-08 Thread Nicolas Ferre

On 02/08/2012 02:18 AM, Olof Johansson :
 Hi,
 
 On Mon, Jan 30, 2012 at 2:08 AM, Nicolas Ferre nicolas.fe...@atmel.com 
 wrote:
 On 01/29/2012 12:57 AM, Olof Johansson :
 Hi,


 On Thu, Jan 26, 2012 at 1:23 PM, Russell King - ARM Linux
 li...@arm.linux.org.uk wrote:


 And we're now there.  So...

 Arnd, Olaf,

 Please incorporate the latest ARM (for-armsoc branch) changes, which can 
 be found at:


 git://ftp.arm.linux.org.uk/pub/linux/arm/kernel/git-cur/linux-arm.git 
 for-armsoc

 with SHA1 dcf81c1af839b77b44404453ecae6e5ac5a75f05.

 Thanks. I have added this as depends/rmk/for-armsoc in the arm-soc repo.

 Any next/ branch we start will have this as the base of said branch,
 so any vendor branches must either already be developed against this
 stable branch, or merge on top of this with minimal conflicts.

 Ok, great.

 I just let you know that there is a conflict between the current Linus'
 tree (with recently updated at91 fixes) and this rmk/for-armsoc branch.

 I can give you the resolution of this conflict easily but I would like
 to know which way I execute the merge:

 I use this rmk/for-armsoc as a baseline and merge the fixes already in
 Linus' tree on top of it or the other way around?

 Maybe it is preferable that I wait for 3.3-rc2 and merge rmk/for-armsoc
 on top of it. This result can be the base of our AT91 work for 3.4
 preparation.

 Your thought?
 
 I missed replying to this email until now when I started looking at
 picking up branches for the 3.4 staging, sorry for the delay.
 
 Russell, would you prefer merging in v3.3-rc2 into your branch so I
 can pull the exact same resolution from there, or should we do it
 locally in arm-soc? It probably makes sense for you to do it so
 there's no more conflicts from there on out for dependent branches.

Olof,

For your information the conflict resolution is already present in
linux-next (and in my 3.4 preparation branches actually).

Best regards,
-- 
Nicolas Ferre
--
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: ARM/ARM-SoC plans for v3.4 merge window

2012-01-30 Thread Nicolas Ferre

On 01/29/2012 12:57 AM, Olof Johansson :
 Hi,
 
 
 On Thu, Jan 26, 2012 at 1:23 PM, Russell King - ARM Linux
 li...@arm.linux.org.uk wrote:
 
 
 And we're now there.  So...

 Arnd, Olaf,

 Please incorporate the latest ARM (for-armsoc branch) changes, which can be 
 found at:

git://ftp.arm.linux.org.uk/pub/linux/arm/kernel/git-cur/linux-arm.git 
 for-armsoc

 with SHA1 dcf81c1af839b77b44404453ecae6e5ac5a75f05.
 
 Thanks. I have added this as depends/rmk/for-armsoc in the arm-soc repo.
 
 Any next/ branch we start will have this as the base of said branch,
 so any vendor branches must either already be developed against this
 stable branch, or merge on top of this with minimal conflicts.

Ok, great.

I just let you know that there is a conflict between the current Linus'
tree (with recently updated at91 fixes) and this rmk/for-armsoc branch.

I can give you the resolution of this conflict easily but I would like
to know which way I execute the merge:

I use this rmk/for-armsoc as a baseline and merge the fixes already in
Linus' tree on top of it or the other way around?

Maybe it is preferable that I wait for 3.3-rc2 and merge rmk/for-armsoc
on top of it. This result can be the base of our AT91 work for 3.4
preparation.

Your thought?

Best regards,
-- 
Nicolas Ferre
--
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 PATCH] Consolidate SRAM support

2011-04-15 Thread Nicolas Ferre

Le 15/04/2011 16:50, Detlef Vollmann :
 On 04/15/11 15:06, Russell King - ARM Linux wrote:
 This is work in progress.
 Thanks, very useful.

[..]

 Another question is whether we should allow multiple SRAM pools or not -
 this code does allow multiple pools, but so far we only have one pool
 per SoC.  Overdesign?  Maybe, but it prevents SoCs wanting to duplicate
 it if they want to partition the SRAM, or have peripheral-local SRAMs.
 Having the option to partition the SRAM is probably useful.
 What I'm missing is sram_pool_add: on AT91SAM9G20 you have two banks
 of SRAM, and you might want to combine them into a single pool.

In fact on at91sam9g20 (and some other at91) you can use the mirroring
of the SRAM until next bank... so you end up with a single pool.

Base @ sram1 base - sram0 size
size = sram 0 size + sram 1 size

Best regards,
-- 
Nicolas Ferre

--
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: [GIT PULL] omap changes for v2.6.39 merge window

2011-04-04 Thread Nicolas Ferre

Le 01/04/2011 17:30, Detlef Vollmann :
 On 04/01/11 16:59, Arnd Bergmann wrote:
 On Friday 01 April 2011, Detlef Vollmann wrote:
 On 04/01/11 15:54, Arnd Bergmann wrote:

 9. All interesting work is going into a handful of platforms, all of
 which
  are ARMv7 based.
 Define interesting.

 The ones that are causing the churn that we're talking about.
 Platforms that have been working forever and only need to get
 the occasional bug fix are boring, i.e. not the problem.
 In the ARM tree I only know mach-at91.
 Atmel still introduces new SOCs based on ARM926EJ-S, and that makes
 perfect sense for lots of applications.
 And if they add support for a new SOC, they just copy an existing one,
 change some GPIOs, and submit it as new files (sorry, I'm over-
 simplifying here).
 And if you happen to wire your board a bit differently than they do,
 you have to patch theur generic file (in addidtion to add your own
 board file).
 And though I only know the mach-at91 closely, I'm pretty sure quite
 a number of other mach-* are not better.
 So this is actually why the ARM tree has such a bad reputation:
 lot's of code repetition, and still more of that.

Yes, certainly time has come for a change.

Note however that AT91 community is making great effort to:
- publish and maintain every single chip/board support since more than 5
years (and far before for first venerable at91rm9200) : if you recall
well, it was before most of code that appeared in arch/arm/mach-*
directories ;-)
- integrate ideas and patches from contributors for simplifying and
reducing board duplication
- try to conform to new infrastructures that are appearing on ARM Linux
for better convergence of code: gpiolib, leds, buttons, clocks (work in
progress)...

We know that work has to be done and we will for sure follow this effort
of consolidation. And remember: contributions welcomed ;-).

Best regards,
-- 
Nicolas Ferre

--
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 2/3] kbuild: remove unnecessary variable initializaions

Re: [PATCH v2 19/26] irqchip: atmel-aic: convert to handle_domain_irq

Re: [PATCH v2 20/26] irqchip: atmel-aic5: convert to handle_domain_irq

Re: [PATCH] ARM: drop explicit selection of HAVE_CLK and CLKDEV_LOOKUP

Re: [PATCH 36/51] DMA-API: usb: use dma_set_coherent_mask()

Re: [PATCH 37/51] DMA-API: usb: use new dma_coerce_mask_and_coherent()

Re: [PATCH] ARM: DTS: SAMA5: Add PMU support

Re: [PATCH v3] drivers: video: use module_platform_driver_probe()

Re: [PATCH 119/493] usb: remove use of __devexit_p

Re: [PATCH V6 2/2] dmaengine: add helper function to request a slave DMA channel

Re: IS_ERR_OR_NULL - please STOP telling people to use this on a whim

Re: [PATCH 14/24] USB: ohci: merge ohci_finish_controller_resume with ohci_resume

Re: [PATCH v3 04/15] dmaengine: Pass flags via device_prep_dma_cyclic() callback

Re: [PATCH V5 1/2] of: Add generic device tree DMA helpers

[PATCH v2 1/2] of: Add generic device tree DMA helpers

[PATCH 2/2] of: selftest/dma: Add selftest for new DT DMA request helpers

[PATCH] of: dma/fixup

Re: [PATCH] of: Add generic device tree DMA helpers

Re: [PATCH] of: Add generic device tree DMA helpers

Re: [PATCH] of: Add generic device tree DMA helpers

Re: [PATCH] of: Add generic device tree DMA helpers

Re: [PATCH] of: Add generic device tree DMA helpers

[PATCH] of: Add generic device tree DMA helpers

Re: [RFC PATCH] of: DMA helpers: manage generic requests specification

[RFC PATCH] of: DMA helpers: manage generic requests specification

Re: [RFC PATCH 1/2] of: Add generic device tree DMA helpers

Re: [RFC PATCH 1/2] of: Add generic device tree DMA helpers

Re: [RFC PATCH 1/2] of: Add generic device tree DMA helpers

Re: ARM/ARM-SoC plans for v3.4 merge window

Re: ARM/ARM-SoC plans for v3.4 merge window

Re: [RFC PATCH] Consolidate SRAM support

Re: [GIT PULL] omap changes for v2.6.39 merge window

32 matches

Site Navigation

Mail list logo

Footer information