RE: [v3, 3/3] ARM: dts: AM33XX: Add NAND flash device tree data to am335x-evm
> -Original Message-
> From: Gupta, Pekon
> Sent: Thursday, May 02, 2013 2:18 PM
> To: Gupta, Pekon; Cousson, Benoit; t...@atomide.com;
> li...@arm.linux.org.uk
> Cc: Philip, Avinash; linux-o...@vger.kernel.org; devicetree-
> disc...@lists.ozlabs.org; linux-arm-ker...@lists.infradead.org; linux-
> ker...@vger.kernel.org; Nori, Sekhar; Hebbar, Gururaja; Hiremath,
> Vaibhav; zon...@gmail.com; jac...@sunsite.dk
> Subject: [v3, 3/3] ARM: dts: AM33XX: Add NAND flash device tree data to
> am335x-evm
>
> From: avinash philip
>
> NAND flash connected in am335x-evm on GPMC controller. This patch adds
> device tree node in am3355-evm with GPMC contoller timing for NAND
> flash
> interface, NAND partition table, ECC scheme, elm handle id.
>
> Signed-off-by: Philip Avinash
> Signed-off-by: Gupta, Pekon
> ---
> arch/arm/boot/dts/am335x-evm.dts | 95
>
> 1 file changed, 95 insertions(+)
>
> diff --git a/arch/arm/boot/dts/am335x-evm.dts
> b/arch/arm/boot/dts/am335x-evm.dts
> index d649644..07761fd 100644
> --- a/arch/arm/boot/dts/am335x-evm.dts
> +++ b/arch/arm/boot/dts/am335x-evm.dts
> @@ -44,6 +44,26 @@
> 0x154 0x27 /* spi0_d0.gpio0_3, INPUT |
> MODE7
> */
> >;
> };
> +
> + nandflash_pins_s0: nandflash_pins_s0 {
> + pinctrl-single,pins = <
> + 0x0 0x30/* gpmc_ad0.gpmc_ad0, INPUT |
> PULLUP | MODE0 */
> + 0x4 0x30/* gpmc_ad1.gpmc_ad1, INPUT |
> PULLUP | MODE0 */
> + 0x8 0x30/* gpmc_ad2.gpmc_ad2, INPUT |
> PULLUP | MODE0 */
> + 0xc 0x30/* gpmc_ad3.gpmc_ad3, INPUT |
> PULLUP | MODE0 */
> + 0x10 0x30 /* gpmc_ad4.gpmc_ad4, INPUT |
> PULLUP | MODE0 */
> + 0x14 0x30 /* gpmc_ad5.gpmc_ad5, INPUT |
> PULLUP | MODE0 */
> + 0x18 0x30 /* gpmc_ad6.gpmc_ad6, INPUT |
> PULLUP | MODE0 */
> + 0x1c 0x30 /* gpmc_ad7.gpmc_ad7, INPUT |
> PULLUP | MODE0 */
> + 0x70 0x30 /* gpmc_wait0.gpmc_wait0, INPUT
> |
> PULLUP | MODE0 */
> + 0x74 0x37 /* gpmc_wpn.gpio0_30, INPUT |
> PULLUP | MODE7 */
> + 0x7c 0x8/* gpmc_csn0.gpmc_csn0, PULL
> DISA
> */
> + 0x90 0x8/* gpmc_advn_ale.gpmc_advn_ale,
> PULL DISA */
> + 0x94 0x8/* gpmc_oen_ren.gpmc_oen_ren,
> PULL
> DISA */
> + 0x98 0x8/* gpmc_wen.gpmc_wen, PULL DISA
> */
> + 0x9c 0x8/* gpmc_be0n_cle.gpmc_be0n_cle,
> PULL DISA */
> + >;
> + };
> };
>
> ocp {
> @@ -102,6 +122,81 @@
> reg = <0x48>;
> };
> };
> +
> + elm: elm@4808 {
> + status = "okay";
> + };
> +
> + gpmc: gpmc@5000 {
> + status = "okay";
> + pinctrl-0 = <&nandflash_pins_s0>;
It would be good, if you label this pin configuration with 'default' name,
as below -
pinctrl-names = "default";
Thanks,
Vaibhav
> + ranges = <0 0 0x0800 0x1000>; /* CS0:
> NAND */
> + nand@0,0 {
> + reg = <0 0 0>; /* CS0, offset 0 */
> + nand-bus-width = <8>;
> + ti,nand-ecc-opt = "bch8";
> +
> + gpmc,sync-clk = <0>;
> + gpmc,cs-on = <0>;
> + gpmc,cs-rd-off = <44>;
> + gpmc,cs-wr-off = <44>;
> + gpmc,adv-on = <6>;
> + gpmc,adv-rd-off = <34>;
> + gpmc,adv-wr-off = <44>;
> + gpmc,we-off = <40>;
> + gpmc,oe-off = <54>;
> + gpmc,access = <64>;
> + gpmc,rd-cycle = <82>;
> + gpmc,wr-cycle = <82>;
> + gpmc,wr-access = <40>;
> +
RE: drm/tilcdc: LCD panels clocks initialization and earlier backlight initialization
> -Original Message-
> From: devicetree-discuss [mailto:devicetree-discuss-
> bounces+hvaibhav=ti@lists.ozlabs.org] On Behalf Of Michal Bachraty
> Sent: Thursday, March 28, 2013 11:02 PM
> To: dri-de...@lists.freedesktop.org; devicetree-
> disc...@lists.ozlabs.org
> Cc: robdcl...@gmail.com; k...@dominion.thruhere.net
> Subject: drm/tilcdc: LCD panels clocks initialization and earlier
> backlight initialization
>
> Hi,
>
> I'm trying to use tilcdc driver for KWH050TG08 LCD panel connected to
> AM335x
> processor (3.9 rc1 kernel). I have prepared DT bindings for that
> (listed
> bellow). I see fb0 device but I have no clocks going from cpu to LCD.
> My
> clocks for LCD seems not properly to be set ...
>
> virt_2500_ck 1 12500
> sys_clkin_ck8 19 2500
>dpll_disp_ck 0 12500
> dpll_disp_m2_ck 0 12500
> lcd_gclk 0 12500
>
> and tilcdc_crtc is not called. I also set lcd_gclk to 300MHz, but I got
> same
> result. The question is there any way how to properly set clocks for
> LCD?
>
Not sure about the LCDC DRM driver, but I just tested clk_set_rate()
For lcdc_gclk clock and it is working for me. I could able to set
300MHz freq on my BeagleBone platform, with below code -
diff --git a/arch/arm/mach-omap2/board-generic.c
b/arch/arm/mach-omap2/board-generic.c
index e54a480..443fb26 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -11,6 +11,7 @@
* it under the terms of the GNU General Public License version 2 as
* published by the Free Software Foundation.
*/
+#include
#include
#include
#include
@@ -37,6 +38,8 @@ static struct of_device_id omap_dt_match_table[] __initdata =
{
static void __init omap_generic_init(void)
{
+ struct clk *clk;
+
omap_sdrc_init(NULL, NULL);
of_platform_populate(NULL, omap_dt_match_table, NULL, NULL);
@@ -49,6 +52,15 @@ static void __init omap_generic_init(void)
omap4_panda_display_init_of();
else if (of_machine_is_compatible("ti,omap4-sdp"))
omap_4430sdp_display_init_of();
+
+ clk = clk_get(NULL, "lcd_gclk");
+ if (IS_ERR(clk))
+ printk("Can not get lcd_gclk clock\n");
+
+ printk("%s:%d gclk_rate - %lu\n", __func__, __LINE__,
clk_get_rate(clk));
+ clk_set_rate(clk, 3);
+ printk("%s:%d clk_rate - %lu\n", __func__, __LINE__, clk_get_rate(clk));
+ clk_put(clk);
}
#ifdef CONFIG_SOC_OMAP2420
Thanks,
Vaibhav
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
RE: [PATCH-V2 0/6] ARM: dts: AM33XX: Cleanup and pinctrl binding support
> -Original Message- > From: Cousson, Benoit > Sent: Thursday, March 28, 2013 5:57 PM > To: Hiremath, Vaibhav > Cc: linux-o...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; > devicetree-discuss@lists.ozlabs.org; Porter, Matt; jac...@sunsite.dk > Subject: Re: [PATCH-V2 0/6] ARM: dts: AM33XX: Cleanup and pinctrl > binding support > > Hi Vaibhav, > > The series looks good to me, but unfortunately does not apply cleanly > on > top of the latest for_3.10/dts branch. > > Could you rebase it? > Benoit, You can simply skip below two patches, [PATCH 1/6] ARM: dts: AM33XX: Fix the i2c numbering to match hardware/TRM [PATCH 3/6] ARM: dts: AM33XX: Fix gpio numbering to match hardware/TRM You have already merged Anil Kumar's patch into your branch. commit 9115b7c03565b5797714b2e819f6a79f040d8782 Author: AnilKumar Ch Date: Wed Nov 21 17:22:17 2012 +0530 ARM: dts: AM33XX: Rename I2C and GPIO nodes NOTE: I have build and boot tested by skipping above 2 patches. Thanks, Vaibhav ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
RE: [PATCH 1/5] ARM: dts: AM33XX: Fix the i2c numbering to match hardware/TRM
> -Original Message- > From: Peter Korsgaard [mailto:jac...@gmail.com] On Behalf Of Peter > Korsgaard > Sent: Wednesday, March 27, 2013 6:52 PM > To: Hiremath, Vaibhav > Cc: linux-o...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; > Cousson, Benoit; Porter, Matt; devicetree-discuss@lists.ozlabs.org > Subject: Re: [PATCH 1/5] ARM: dts: AM33XX: Fix the i2c numbering to > match hardware/TRM > > >>>>> "Vaibhav" == Vaibhav Hiremath writes: > > Vaibhav> With DT support, where naming convention is based on base- > addr > Vaibhav> and not id, so we should follow TRM/Spec numbering label. > > Vaibhav> This patch changes I2C numbering as per TRM, as I2C0, I2C1 > and I2C2. > > Acked-by: Peter Korsgaard > > What about the uart numbers while we're at it? > Just responded to Matt on the same note, I will change it and submit the next version with your acked-by. Thanks, Vaibhav ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
RE: [PATCH 5/5] ARM: dts: AM33XX: Add default pinctrl binding for UART0 device
> -Original Message-
> From: Matt Porter [mailto:ohio...@gmail.com] On Behalf Of Porter, Matt
> Sent: Wednesday, March 27, 2013 7:03 PM
> To: Hiremath, Vaibhav
> Cc: linux-o...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> Cousson, Benoit; devicetree-discuss@lists.ozlabs.org
> Subject: Re: [PATCH 5/5] ARM: dts: AM33XX: Add default pinctrl binding
> for UART0 device
>
> On Wed, Mar 27, 2013 at 12:59:16PM +, Vaibhav Hiremath wrote:
> > Add pin control binding for UART0 device nodes in all
> > board specific DT files.
> >
> > Signed-off-by: Vaibhav Hiremath
> > Cc: Benoit Cousson
>
> Except for trivial comments below I'll add my
>
> Acked-by: Matt Porter
>
> > ---
> > arch/arm/boot/dts/am335x-bone.dts | 10 ++
> > arch/arm/boot/dts/am335x-evm.dts | 10 ++
> > arch/arm/boot/dts/am335x-evmsk.dts | 10 ++
> > 3 files changed, 30 insertions(+), 0 deletions(-)
> >
> > diff --git a/arch/arm/boot/dts/am335x-bone.dts
> b/arch/arm/boot/dts/am335x-bone.dts
> > index 1d623e4..3c4c66f 100644
> > --- a/arch/arm/boot/dts/am335x-bone.dts
> > +++ b/arch/arm/boot/dts/am335x-bone.dts
> > @@ -43,10 +43,20 @@
> > 0x18c 0x30 /* i2c0_scl.i2c0_scl PULLUP |
> INPUTENABLE | MODE0 */
> > >;
> > };
> > +
> > + uart0_pins: pinmux_uart0_pins {
> > + pinctrl-single,pins = <
> > + 0x170 0x30 /* uart0_rxd.uart0_rxd PULLUP |
> INPUTENABLE | MODE0 */
> > + 0x174 0x00 /* uart0_txd.uart0_txd PULLDOWN
> > |
> MODE0 */
> > + >;
> > + };
> > };
> >
> > ocp {
> > uart1: serial@44e09000 {
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&uart0_pins>;
> > +
>
> Please change this to be uart0 so it all matches.
>
Yes, you are right, this also can be changed now.
I tested it with changed uart numbering and it is working.
I didn’t touch uart, as I recall earlier discussion of
Having 1-based uart numbering and also it is being documented
In DT for hwmod -
ti,hwmods : Must be "uart", n being the instance number (1-based)
I will change it and submit the next version with your acked-by.
Thanks,
Vaibhav
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
RE: [PATCH 2/2] ARM: dts: add AM33XX MMC support
> -Original Message- > From: Matt Porter [mailto:ohio...@gmail.com] On Behalf Of Porter, Matt > Sent: Thursday, March 07, 2013 9:33 PM > To: Hiremath, Vaibhav > Cc: Linux OMAP List; Russell King; Krishnamoorthy, Balaji T; Devicetree > Discuss; Linux MMC List; Linux Kernel Mailing List; Chris Ball; Linux > ARM Kernel List > Subject: Re: [PATCH 2/2] ARM: dts: add AM33XX MMC support > > On Thu, Mar 07, 2013 at 03:50:01PM +, Vaibhav Hiremath wrote: > > > > > -Original Message- > > > From: Matt Porter [mailto:ohio...@gmail.com] On Behalf Of Porter, > Matt > > > Sent: Thursday, March 07, 2013 8:34 PM > > > To: Hiremath, Vaibhav > > > Cc: Chris Ball; Russell King; Krishnamoorthy, Balaji T; Devicetree > > > Discuss; Linux MMC List; Linux Kernel Mailing List; Linux OMAP > List; > > > Linux ARM Kernel List > > > Subject: Re: [PATCH 2/2] ARM: dts: add AM33XX MMC support > > > > > > On Thu, Mar 07, 2013 at 02:59:42PM +, Vaibhav Hiremath wrote: > > > > > > > > > -Original Message- > > > > > From: Hiremath, Vaibhav > > > > > Sent: Thursday, March 07, 2013 8:24 PM > > > > > To: Porter, Matt > > > > > Cc: Linux OMAP List; Russell King; Krishnamoorthy, Balaji T; > > > Devicetree > > > > > Discuss; Linux MMC List; Linux Kernel Mailing List; Chris Ball; > > > Linux > > > > > ARM Kernel List > > > > > Subject: RE: [PATCH 2/2] ARM: dts: add AM33XX MMC support > > > > > > > > > > > -Original Message- > > > > > > From: Matt Porter [mailto:ohio...@gmail.com] On Behalf Of > Porter, > > > > > Matt > > > > > > Sent: Thursday, March 07, 2013 8:17 PM > > > > > > To: Hiremath, Vaibhav > > > > > > Cc: Linux OMAP List; Russell King; Krishnamoorthy, Balaji T; > > > > > Devicetree > > > > > > Discuss; Linux MMC List; Linux Kernel Mailing List; Chris > Ball; > > > Linux > > > > > > ARM Kernel List > > > > > > Subject: Re: [PATCH 2/2] ARM: dts: add AM33XX MMC support > > > > > > > > > > > > On Thu, Mar 07, 2013 at 02:39:55PM +, Vaibhav Hiremath > wrote: > > > > > > > > > > > > > > > -Original Message- > > > > > > > > From: Matt Porter [mailto:ohio...@gmail.com] On Behalf Of > > > Porter, > > > > > > Matt > > > > > > > > Sent: Thursday, March 07, 2013 7:43 PM > > > > > > > > To: Hiremath, Vaibhav > > > > > > > > Cc: Krishnamoorthy, Balaji T; Chris Ball; Cousson, > Benoit; > > > Tony > > > > > > > > Lindgren; Russell King; Devicetree Discuss; Linux ARM > Kernel > > > > > List; > > > > > > > > Linux OMAP List; Linux Kernel Mailing List; Linux MMC > List > > > > > > > > Subject: Re: [PATCH 2/2] ARM: dts: add AM33XX MMC support > > > > > > > > > > > > > > > > On Thu, Mar 07, 2013 at 05:29:24AM +, Vaibhav > Hiremath > > > wrote: > > > > > > > > > > -Original Message- > > > > > > > > > > From: linux-omap-ow...@vger.kernel.org [mailto:linux- > > > omap- > > > > > > > > > > ow...@vger.kernel.org] On Behalf Of Porter, Matt > > > > > > > > > > Sent: Thursday, March 07, 2013 9:47 AM > > > > > > > > > > To: Krishnamoorthy, Balaji T; Chris Ball; Cousson, > > > Benoit; > > > > > Tony > > > > > > > > > > Lindgren; Russell King > > > > > > > > > > Cc: Devicetree Discuss; Linux ARM Kernel List; Linux > OMAP > > > > > List; > > > > > > > > Linux > > > > > > > > > > Kernel Mailing List; Linux MMC List > > > > > > > > > > Subject: [PATCH 2/2] ARM: dts: add AM33XX MMC support > > > > > > > > > > > > > > > > > > > > > > > > I believe you meant "CONFIG_TI_EDMA" right? > > > > > > > > > > Yes, I just enabled it and the result is still same. > > > > > > > > > > > > > > > > > > > > [root@arago /]# dmesg | grep -ir mmc > > >
RE: [PATCH 2/2] ARM: dts: add AM33XX MMC support
> -Original Message- > From: Matt Porter [mailto:ohio...@gmail.com] On Behalf Of Porter, Matt > Sent: Thursday, March 07, 2013 8:34 PM > To: Hiremath, Vaibhav > Cc: Chris Ball; Russell King; Krishnamoorthy, Balaji T; Devicetree > Discuss; Linux MMC List; Linux Kernel Mailing List; Linux OMAP List; > Linux ARM Kernel List > Subject: Re: [PATCH 2/2] ARM: dts: add AM33XX MMC support > > On Thu, Mar 07, 2013 at 02:59:42PM +, Vaibhav Hiremath wrote: > > > > > -----Original Message- > > > From: Hiremath, Vaibhav > > > Sent: Thursday, March 07, 2013 8:24 PM > > > To: Porter, Matt > > > Cc: Linux OMAP List; Russell King; Krishnamoorthy, Balaji T; > Devicetree > > > Discuss; Linux MMC List; Linux Kernel Mailing List; Chris Ball; > Linux > > > ARM Kernel List > > > Subject: RE: [PATCH 2/2] ARM: dts: add AM33XX MMC support > > > > > > > -Original Message- > > > > From: Matt Porter [mailto:ohio...@gmail.com] On Behalf Of Porter, > > > Matt > > > > Sent: Thursday, March 07, 2013 8:17 PM > > > > To: Hiremath, Vaibhav > > > > Cc: Linux OMAP List; Russell King; Krishnamoorthy, Balaji T; > > > Devicetree > > > > Discuss; Linux MMC List; Linux Kernel Mailing List; Chris Ball; > Linux > > > > ARM Kernel List > > > > Subject: Re: [PATCH 2/2] ARM: dts: add AM33XX MMC support > > > > > > > > On Thu, Mar 07, 2013 at 02:39:55PM +, Vaibhav Hiremath wrote: > > > > > > > > > > > -Original Message- > > > > > > From: Matt Porter [mailto:ohio...@gmail.com] On Behalf Of > Porter, > > > > Matt > > > > > > Sent: Thursday, March 07, 2013 7:43 PM > > > > > > To: Hiremath, Vaibhav > > > > > > Cc: Krishnamoorthy, Balaji T; Chris Ball; Cousson, Benoit; > Tony > > > > > > Lindgren; Russell King; Devicetree Discuss; Linux ARM Kernel > > > List; > > > > > > Linux OMAP List; Linux Kernel Mailing List; Linux MMC List > > > > > > Subject: Re: [PATCH 2/2] ARM: dts: add AM33XX MMC support > > > > > > > > > > > > On Thu, Mar 07, 2013 at 05:29:24AM +, Vaibhav Hiremath > wrote: > > > > > > > > -Original Message- > > > > > > > > From: linux-omap-ow...@vger.kernel.org [mailto:linux- > omap- > > > > > > > > ow...@vger.kernel.org] On Behalf Of Porter, Matt > > > > > > > > Sent: Thursday, March 07, 2013 9:47 AM > > > > > > > > To: Krishnamoorthy, Balaji T; Chris Ball; Cousson, > Benoit; > > > Tony > > > > > > > > Lindgren; Russell King > > > > > > > > Cc: Devicetree Discuss; Linux ARM Kernel List; Linux OMAP > > > List; > > > > > > Linux > > > > > > > > Kernel Mailing List; Linux MMC List > > > > > > > > Subject: [PATCH 2/2] ARM: dts: add AM33XX MMC support > > > > > > > > > > > > > > > > I believe you meant "CONFIG_TI_EDMA" right? > > > > > > Yes, I just enabled it and the result is still same. > > > > > > > > > > > > [root@arago /]# dmesg | grep -ir mmc > > > [0.506844] vmmc: 1800 <--> 3300 mV at 3300 mV > > > [0.506970] vmmc: supplied by vbat > > > [root@arago /]# > > > [root@arago /]# > > > [root@arago /]# dmesg | grep -ir dma > > > [0.217063] DMA: preallocated 256 KiB pool for atomic coherent > > > allocations > > > [0.236321] platform 4900.edma: alias fck already exists > > > [0.236360] platform 4900.edma: alias fck already exists > > > [0.236381] platform 4900.edma: alias fck already exists > > > [0.370705] edma-dma-engine edma-dma-engine.0: TI EDMA DMA > engine > > > driver > > > [0.445156] omap-dma-engine omap-dma-engine: OMAP DMA engine > driver > > > [root@arago /]# > > > [root@arago /]# > > > > > > > > I have applied below patches from your recent post > > > > > > [2/2] ARM: dts: add AM33XX MMC support > > [1/2] mmc: omap_hsmmc: set max_segs based on dma engine limits > > [v4,3/3] mmc: davinci: get SG segment limits with > dma_get_slave_sg_limits() > > [v4,2/3] dma: edma: add device_slave_sg_limits() support > > [v4,1/3] dmaengine: add dma_get_slave_sg_limits() > > [v9,9/9] ARM: dts: add
RE: [PATCH 2/2] ARM: dts: add AM33XX MMC support
> -Original Message- > From: Matt Porter [mailto:ohio...@gmail.com] On Behalf Of Porter, Matt > Sent: Thursday, March 07, 2013 8:31 PM > To: Hiremath, Vaibhav > Cc: Chris Ball; Russell King; Krishnamoorthy, Balaji T; Devicetree > Discuss; Linux MMC List; Linux Kernel Mailing List; Linux OMAP List; > Linux ARM Kernel List > Subject: Re: [PATCH 2/2] ARM: dts: add AM33XX MMC support > > On Thu, Mar 07, 2013 at 02:53:51PM +, Vaibhav Hiremath wrote: > > > -Original Message- > > > From: Matt Porter [mailto:ohio...@gmail.com] On Behalf Of Porter, > Matt > > > Sent: Thursday, March 07, 2013 8:17 PM > > > To: Hiremath, Vaibhav > > > Cc: Linux OMAP List; Russell King; Krishnamoorthy, Balaji T; > Devicetree > > > Discuss; Linux MMC List; Linux Kernel Mailing List; Chris Ball; > Linux > > > ARM Kernel List > > > Subject: Re: [PATCH 2/2] ARM: dts: add AM33XX MMC support > > > > > > On Thu, Mar 07, 2013 at 02:39:55PM +, Vaibhav Hiremath wrote: > > > > > > > > > -Original Message----- > > > > > From: Matt Porter [mailto:ohio...@gmail.com] On Behalf Of > Porter, > > > Matt > > > > > Sent: Thursday, March 07, 2013 7:43 PM > > > > > To: Hiremath, Vaibhav > > > > > Cc: Krishnamoorthy, Balaji T; Chris Ball; Cousson, Benoit; Tony > > > > > Lindgren; Russell King; Devicetree Discuss; Linux ARM Kernel > List; > > > > > Linux OMAP List; Linux Kernel Mailing List; Linux MMC List > > > > > Subject: Re: [PATCH 2/2] ARM: dts: add AM33XX MMC support > > > > > > > > > > On Thu, Mar 07, 2013 at 05:29:24AM +, Vaibhav Hiremath > wrote: > > > > > > > -Original Message- > > > > > > > From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- > > > > > > > ow...@vger.kernel.org] On Behalf Of Porter, Matt > > > > > > > Sent: Thursday, March 07, 2013 9:47 AM > > > > > > > To: Krishnamoorthy, Balaji T; Chris Ball; Cousson, Benoit; > Tony > > > > > > > Lindgren; Russell King > > > > > > > Cc: Devicetree Discuss; Linux ARM Kernel List; Linux OMAP > List; > > > > > Linux > > > > > > > Kernel Mailing List; Linux MMC List > > > > > > > Subject: [PATCH 2/2] ARM: dts: add AM33XX MMC support > > > > > > > > > > > > > > Adds AM33XX MMC support for am335x-bone, am335x-evm, and > > > > > > > am335x-evmsk. > > > > > > > > > What's the full log now? At least that fragment you show me is better, > you now have the correct dmaengine driver active. > Here we go. Boot Log: == U-Boot# mmc rescan 0 U-Boot# fatload mmc 0 8000 am335x-evm.dtb reading am335x-evm.dtb 11419 bytes read in 10 ms (1.1 MiB/s) U-Boot# fatload mmc 0 8100 uImage reading uImage 4029168 bytes read in 441 ms (8.7 MiB/s) U-Boot# fatload mmc 0 8200 ramdisk.ext2.gz reading ramdisk.ext2.gz 3274441 bytes read in 363 ms (8.6 MiB/s) U-Boot# setenv bootargs mem=256M console=ttyO0,115200n8 root=/dev/ram rw initrd=0x8200,16MB ramdisk_size=65536 earlyprintk=serial omap_debugss_en U-Boot# bootm 8100 - 8000 ## Booting kernel from Legacy Image at 8100 ... Image Name: Linux-3.9.0-rc1-00124-g68f2d92-d Image Type: ARM Linux Kernel Image (uncompressed) Data Size:4029104 Bytes = 3.8 MiB Load Address: 80008000 Entry Point: 80008000 Verifying Checksum ... OK ## Flattened Device Tree blob at 8000 Booting using the fdt blob at 0x8000 Loading Kernel Image ... OK OK Using Device Tree in place at 8000, end 80005c9a Starting kernel ... [0.00] Booting Linux on physical CPU 0x0 [0.00] Linux version 3.9.0-rc1-00124-g68f2d92-dirty (XXX@psplinux064) (gcc version 4.5.3 20110311 (prerelease) (GCC) ) #5 SMP Thu Mar 7 20:19:23 IST 2013 [0.00] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c53c7d [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache [0.00] Machine: Generic AM33XX (Flattened Device Tree), model: TI AM335x EVM [0.00] cma: CMA: reserved 16 MiB at 8e80 [0.00] Memory policy: ECC disabled, Data cache writeback [0.00] CPU: All CPU(s) started in SVC mode. [0.00] AM335X ES2.0 (neon ) [0.00] PERCPU: Embedded 9 pages/cpu @c0f75000 s13632 r8192 d15040 u36864 [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 64768 [0.00] Kernel command line: mem=256M console=ttyO0,115200n8 root=/dev/ram rw initrdD
RE: [PATCH 2/2] ARM: dts: add AM33XX MMC support
> -Original Message- > From: Hiremath, Vaibhav > Sent: Thursday, March 07, 2013 8:24 PM > To: Porter, Matt > Cc: Linux OMAP List; Russell King; Krishnamoorthy, Balaji T; Devicetree > Discuss; Linux MMC List; Linux Kernel Mailing List; Chris Ball; Linux > ARM Kernel List > Subject: RE: [PATCH 2/2] ARM: dts: add AM33XX MMC support > > > -Original Message- > > From: Matt Porter [mailto:ohio...@gmail.com] On Behalf Of Porter, > Matt > > Sent: Thursday, March 07, 2013 8:17 PM > > To: Hiremath, Vaibhav > > Cc: Linux OMAP List; Russell King; Krishnamoorthy, Balaji T; > Devicetree > > Discuss; Linux MMC List; Linux Kernel Mailing List; Chris Ball; Linux > > ARM Kernel List > > Subject: Re: [PATCH 2/2] ARM: dts: add AM33XX MMC support > > > > On Thu, Mar 07, 2013 at 02:39:55PM +, Vaibhav Hiremath wrote: > > > > > > > -Original Message- > > > > From: Matt Porter [mailto:ohio...@gmail.com] On Behalf Of Porter, > > Matt > > > > Sent: Thursday, March 07, 2013 7:43 PM > > > > To: Hiremath, Vaibhav > > > > Cc: Krishnamoorthy, Balaji T; Chris Ball; Cousson, Benoit; Tony > > > > Lindgren; Russell King; Devicetree Discuss; Linux ARM Kernel > List; > > > > Linux OMAP List; Linux Kernel Mailing List; Linux MMC List > > > > Subject: Re: [PATCH 2/2] ARM: dts: add AM33XX MMC support > > > > > > > > On Thu, Mar 07, 2013 at 05:29:24AM +, Vaibhav Hiremath wrote: > > > > > > -Original Message- > > > > > > From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- > > > > > > ow...@vger.kernel.org] On Behalf Of Porter, Matt > > > > > > Sent: Thursday, March 07, 2013 9:47 AM > > > > > > To: Krishnamoorthy, Balaji T; Chris Ball; Cousson, Benoit; > Tony > > > > > > Lindgren; Russell King > > > > > > Cc: Devicetree Discuss; Linux ARM Kernel List; Linux OMAP > List; > > > > Linux > > > > > > Kernel Mailing List; Linux MMC List > > > > > > Subject: [PATCH 2/2] ARM: dts: add AM33XX MMC support > > > > > > > > I believe you meant "CONFIG_TI_EDMA" right? > > Yes, I just enabled it and the result is still same. > > > > [root@arago /]# dmesg | grep -ir mmc > [0.506844] vmmc: 1800 <--> 3300 mV at 3300 mV > [0.506970] vmmc: supplied by vbat > [root@arago /]# > [root@arago /]# > [root@arago /]# dmesg | grep -ir dma > [0.217063] DMA: preallocated 256 KiB pool for atomic coherent > allocations > [0.236321] platform 4900.edma: alias fck already exists > [0.236360] platform 4900.edma: alias fck already exists > [0.236381] platform 4900.edma: alias fck already exists > [0.370705] edma-dma-engine edma-dma-engine.0: TI EDMA DMA engine > driver > [0.445156] omap-dma-engine omap-dma-engine: OMAP DMA engine driver > [root@arago /]# > [root@arago /]# > > I have applied below patches from your recent post [2/2] ARM: dts: add AM33XX MMC support [1/2] mmc: omap_hsmmc: set max_segs based on dma engine limits [v4,3/3] mmc: davinci: get SG segment limits with dma_get_slave_sg_limits() [v4,2/3] dma: edma: add device_slave_sg_limits() support [v4,1/3] dmaengine: add dma_get_slave_sg_limits() [v9,9/9] ARM: dts: add AM33XX SPI DMA support [v9,8/9] spi: omap2-mcspi: add generic DMA request support to the DT binding [v9,7/9] spi: omap2-mcspi: convert to dma_request_slave_channel_compat() [v9,6/9] ARM: dts: add AM33XX EDMA support [v9,5/9] dmaengine: edma: Add TI EDMA device tree binding [v9,4/9] dmaengine: edma: enable build for AM33XX [v9,3/9] ARM: edma: add AM33XX support to the private EDMA API [v9,2/9] ARM: edma: remove unused transfer controller handlers [v9,1/9] ARM: davinci: move private EDMA API to arm/common [v3,2/2] mmc: omap_hsmmc: add generic DMA request support to the DT binding [v3,1/2] mmc: omap_hsmmc: convert to dma_request_slave_channel_compat() Am I missing anything here? Thanks, Vaibhav ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
RE: [PATCH 2/2] ARM: dts: add AM33XX MMC support
> -Original Message-
> From: Matt Porter [mailto:ohio...@gmail.com] On Behalf Of Porter, Matt
> Sent: Thursday, March 07, 2013 8:17 PM
> To: Hiremath, Vaibhav
> Cc: Linux OMAP List; Russell King; Krishnamoorthy, Balaji T; Devicetree
> Discuss; Linux MMC List; Linux Kernel Mailing List; Chris Ball; Linux
> ARM Kernel List
> Subject: Re: [PATCH 2/2] ARM: dts: add AM33XX MMC support
>
> On Thu, Mar 07, 2013 at 02:39:55PM +, Vaibhav Hiremath wrote:
> >
> > > -Original Message-
> > > From: Matt Porter [mailto:ohio...@gmail.com] On Behalf Of Porter,
> Matt
> > > Sent: Thursday, March 07, 2013 7:43 PM
> > > To: Hiremath, Vaibhav
> > > Cc: Krishnamoorthy, Balaji T; Chris Ball; Cousson, Benoit; Tony
> > > Lindgren; Russell King; Devicetree Discuss; Linux ARM Kernel List;
> > > Linux OMAP List; Linux Kernel Mailing List; Linux MMC List
> > > Subject: Re: [PATCH 2/2] ARM: dts: add AM33XX MMC support
> > >
> > > On Thu, Mar 07, 2013 at 05:29:24AM +, Vaibhav Hiremath wrote:
> > > > > -Original Message-
> > > > > From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
> > > > > ow...@vger.kernel.org] On Behalf Of Porter, Matt
> > > > > Sent: Thursday, March 07, 2013 9:47 AM
> > > > > To: Krishnamoorthy, Balaji T; Chris Ball; Cousson, Benoit; Tony
> > > > > Lindgren; Russell King
> > > > > Cc: Devicetree Discuss; Linux ARM Kernel List; Linux OMAP List;
> > > Linux
> > > > > Kernel Mailing List; Linux MMC List
> > > > > Subject: [PATCH 2/2] ARM: dts: add AM33XX MMC support
> > > > >
> > > > > Adds AM33XX MMC support for am335x-bone, am335x-evm, and
> > > > > am335x-evmsk.
> > > > >
> > > > > Signed-off-by: Matt Porter
> > > > > Acked-by: Tony Lindgren
> > > > > ---
> > > > > arch/arm/boot/dts/am335x-bone.dts |7 +++
> > > > > arch/arm/boot/dts/am335x-evm.dts |7 +++
> > > > > arch/arm/boot/dts/am335x-evmsk.dts |7 +++
> > > > > arch/arm/boot/dts/am33xx.dtsi | 28
> > >
> > > > > 4 files changed, 49 insertions(+)
> > > > >
> > > > > diff --git a/arch/arm/boot/dts/am335x-bone.dts
> > > > > b/arch/arm/boot/dts/am335x-bone.dts
> > > > > index 11b240c..a154ce0 100644
> > > > > --- a/arch/arm/boot/dts/am335x-bone.dts
> > > > > +++ b/arch/arm/boot/dts/am335x-bone.dts
> > > > > @@ -120,6 +120,8 @@
> > > > > };
> > > > >
> > > > > ldo3_reg: regulator@5 {
> > > > > + regulator-min-microvolt = <180>;
> > > > > + regulator-max-microvolt = <330>;
> > > > > regulator-always-on;
> > > > > };
> > > > >
> > > > > @@ -136,3 +138,8 @@
> > > > > &cpsw_emac1 {
> > > > > phy_id = <&davinci_mdio>, <1>;
> > > > > };
> > > > > +
> > > > > +&mmc1 {
> > > > > + status = "okay";
> > > > > + vmmc-supply = <&ldo3_reg>;
> > > > > +};
> > > > > diff --git a/arch/arm/boot/dts/am335x-evm.dts
> > > > > b/arch/arm/boot/dts/am335x-evm.dts
> > > > > index d649644..2907da6 100644
> > > > > --- a/arch/arm/boot/dts/am335x-evm.dts
> > > > > +++ b/arch/arm/boot/dts/am335x-evm.dts
> > > > > @@ -232,6 +232,8 @@
> > > > > };
> > > > >
> > > > > vmmc_reg: regulator@12 {
> > > > > + regulator-min-microvolt = <180>;
> > > > > + regulator-max-microvolt = <330>;
> > > > > regulator-always-on;
> > > > > };
> > > > > };
> > > > > @@ -244,3 +246,8 @@
> > > > > &cpsw_emac1 {
> > > > > phy_id = <&davinci_mdio>, <1>;
> > > > > };
> > > > > +
> > > > > +&mmc1 {
> > > > > + status = "okay";
> > > > > + vmmc-supply = <&vmmc_reg>;
> > > > > +};
> >
RE: [PATCH 2/2] ARM: dts: add AM33XX MMC support
> -Original Message-
> From: Matt Porter [mailto:ohio...@gmail.com] On Behalf Of Porter, Matt
> Sent: Thursday, March 07, 2013 7:43 PM
> To: Hiremath, Vaibhav
> Cc: Krishnamoorthy, Balaji T; Chris Ball; Cousson, Benoit; Tony
> Lindgren; Russell King; Devicetree Discuss; Linux ARM Kernel List;
> Linux OMAP List; Linux Kernel Mailing List; Linux MMC List
> Subject: Re: [PATCH 2/2] ARM: dts: add AM33XX MMC support
>
> On Thu, Mar 07, 2013 at 05:29:24AM +, Vaibhav Hiremath wrote:
> > > -Original Message-
> > > From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
> > > ow...@vger.kernel.org] On Behalf Of Porter, Matt
> > > Sent: Thursday, March 07, 2013 9:47 AM
> > > To: Krishnamoorthy, Balaji T; Chris Ball; Cousson, Benoit; Tony
> > > Lindgren; Russell King
> > > Cc: Devicetree Discuss; Linux ARM Kernel List; Linux OMAP List;
> Linux
> > > Kernel Mailing List; Linux MMC List
> > > Subject: [PATCH 2/2] ARM: dts: add AM33XX MMC support
> > >
> > > Adds AM33XX MMC support for am335x-bone, am335x-evm, and
> > > am335x-evmsk.
> > >
> > > Signed-off-by: Matt Porter
> > > Acked-by: Tony Lindgren
> > > ---
> > > arch/arm/boot/dts/am335x-bone.dts |7 +++
> > > arch/arm/boot/dts/am335x-evm.dts |7 +++
> > > arch/arm/boot/dts/am335x-evmsk.dts |7 +++
> > > arch/arm/boot/dts/am33xx.dtsi | 28
>
> > > 4 files changed, 49 insertions(+)
> > >
> > > diff --git a/arch/arm/boot/dts/am335x-bone.dts
> > > b/arch/arm/boot/dts/am335x-bone.dts
> > > index 11b240c..a154ce0 100644
> > > --- a/arch/arm/boot/dts/am335x-bone.dts
> > > +++ b/arch/arm/boot/dts/am335x-bone.dts
> > > @@ -120,6 +120,8 @@
> > > };
> > >
> > > ldo3_reg: regulator@5 {
> > > + regulator-min-microvolt = <180>;
> > > + regulator-max-microvolt = <330>;
> > > regulator-always-on;
> > > };
> > >
> > > @@ -136,3 +138,8 @@
> > > &cpsw_emac1 {
> > > phy_id = <&davinci_mdio>, <1>;
> > > };
> > > +
> > > +&mmc1 {
> > > + status = "okay";
> > > + vmmc-supply = <&ldo3_reg>;
> > > +};
> > > diff --git a/arch/arm/boot/dts/am335x-evm.dts
> > > b/arch/arm/boot/dts/am335x-evm.dts
> > > index d649644..2907da6 100644
> > > --- a/arch/arm/boot/dts/am335x-evm.dts
> > > +++ b/arch/arm/boot/dts/am335x-evm.dts
> > > @@ -232,6 +232,8 @@
> > > };
> > >
> > > vmmc_reg: regulator@12 {
> > > + regulator-min-microvolt = <180>;
> > > + regulator-max-microvolt = <330>;
> > > regulator-always-on;
> > > };
> > > };
> > > @@ -244,3 +246,8 @@
> > > &cpsw_emac1 {
> > > phy_id = <&davinci_mdio>, <1>;
> > > };
> > > +
> > > +&mmc1 {
> > > + status = "okay";
> > > + vmmc-supply = <&vmmc_reg>;
> > > +};
> > > diff --git a/arch/arm/boot/dts/am335x-evmsk.dts
> > > b/arch/arm/boot/dts/am335x-evmsk.dts
> > > index f5a6162..f050c46 100644
> > > --- a/arch/arm/boot/dts/am335x-evmsk.dts
> > > +++ b/arch/arm/boot/dts/am335x-evmsk.dts
> > > @@ -244,7 +244,14 @@
> > > };
> > >
> > > vmmc_reg: regulator@12 {
> > > + regulator-min-microvolt = <180>;
> > > + regulator-max-microvolt = <330>;
> > > regulator-always-on;
> > > };
> > > };
> > > };
> > > +
> > > +&mmc1 {
> > > + status = "okay";
> > > + vmmc-supply = <&vmmc_reg>;
> > > +};
> > > diff --git a/arch/arm/boot/dts/am33xx.dtsi
> > > b/arch/arm/boot/dts/am33xx.dtsi
> > > index c3c781a..e029eea 100644
> > > --- a/arch/arm/boot/dts/am33xx.dtsi
> > > +++ b/arch/arm/boot/dts/am33xx.dtsi
> > > @@ -234,6 +234,34 @@
> > > status = "disabled";
> > > };
> > >
> > > + mmc1: mmc@4806 {
> > > + compatible = "ti,omap3-hsmmc";
> > > + ti,hwmods = "m
RE: [PATCH 2/2] ARM: dts: add AM33XX MMC support
> -Original Message-
> From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
> ow...@vger.kernel.org] On Behalf Of Porter, Matt
> Sent: Thursday, March 07, 2013 9:47 AM
> To: Krishnamoorthy, Balaji T; Chris Ball; Cousson, Benoit; Tony
> Lindgren; Russell King
> Cc: Devicetree Discuss; Linux ARM Kernel List; Linux OMAP List; Linux
> Kernel Mailing List; Linux MMC List
> Subject: [PATCH 2/2] ARM: dts: add AM33XX MMC support
>
> Adds AM33XX MMC support for am335x-bone, am335x-evm, and
> am335x-evmsk.
>
> Signed-off-by: Matt Porter
> Acked-by: Tony Lindgren
> ---
> arch/arm/boot/dts/am335x-bone.dts |7 +++
> arch/arm/boot/dts/am335x-evm.dts |7 +++
> arch/arm/boot/dts/am335x-evmsk.dts |7 +++
> arch/arm/boot/dts/am33xx.dtsi | 28
> 4 files changed, 49 insertions(+)
>
> diff --git a/arch/arm/boot/dts/am335x-bone.dts
> b/arch/arm/boot/dts/am335x-bone.dts
> index 11b240c..a154ce0 100644
> --- a/arch/arm/boot/dts/am335x-bone.dts
> +++ b/arch/arm/boot/dts/am335x-bone.dts
> @@ -120,6 +120,8 @@
> };
>
> ldo3_reg: regulator@5 {
> + regulator-min-microvolt = <180>;
> + regulator-max-microvolt = <330>;
> regulator-always-on;
> };
>
> @@ -136,3 +138,8 @@
> &cpsw_emac1 {
> phy_id = <&davinci_mdio>, <1>;
> };
> +
> +&mmc1 {
> + status = "okay";
> + vmmc-supply = <&ldo3_reg>;
> +};
> diff --git a/arch/arm/boot/dts/am335x-evm.dts
> b/arch/arm/boot/dts/am335x-evm.dts
> index d649644..2907da6 100644
> --- a/arch/arm/boot/dts/am335x-evm.dts
> +++ b/arch/arm/boot/dts/am335x-evm.dts
> @@ -232,6 +232,8 @@
> };
>
> vmmc_reg: regulator@12 {
> + regulator-min-microvolt = <180>;
> + regulator-max-microvolt = <330>;
> regulator-always-on;
> };
> };
> @@ -244,3 +246,8 @@
> &cpsw_emac1 {
> phy_id = <&davinci_mdio>, <1>;
> };
> +
> +&mmc1 {
> + status = "okay";
> + vmmc-supply = <&vmmc_reg>;
> +};
> diff --git a/arch/arm/boot/dts/am335x-evmsk.dts
> b/arch/arm/boot/dts/am335x-evmsk.dts
> index f5a6162..f050c46 100644
> --- a/arch/arm/boot/dts/am335x-evmsk.dts
> +++ b/arch/arm/boot/dts/am335x-evmsk.dts
> @@ -244,7 +244,14 @@
> };
>
> vmmc_reg: regulator@12 {
> + regulator-min-microvolt = <180>;
> + regulator-max-microvolt = <330>;
> regulator-always-on;
> };
> };
> };
> +
> +&mmc1 {
> + status = "okay";
> + vmmc-supply = <&vmmc_reg>;
> +};
> diff --git a/arch/arm/boot/dts/am33xx.dtsi
> b/arch/arm/boot/dts/am33xx.dtsi
> index c3c781a..e029eea 100644
> --- a/arch/arm/boot/dts/am33xx.dtsi
> +++ b/arch/arm/boot/dts/am33xx.dtsi
> @@ -234,6 +234,34 @@
> status = "disabled";
> };
>
> + mmc1: mmc@4806 {
> + compatible = "ti,omap3-hsmmc";
> + ti,hwmods = "mmc1";
> + ti,dual-volt;
> + ti,needs-special-reset;
> + dmas = <&edma 24
> + &edma 25>;
> + dma-names = "tx", "rx";
> + status = "disabled";
> + };
> +
> + mmc2: mmc@481d8000 {
> + compatible = "ti,omap3-hsmmc";
> + ti,hwmods = "mmc2";
> + ti,needs-special-reset;
> + dmas = <&edma 2
> + &edma 3>;
> + dma-names = "tx", "rx";
> + status = "disabled";
> + };
> +
> + mmc3: mmc@4781 {
> + compatible = "ti,omap3-hsmmc";
> + ti,hwmods = "mmc3";
> + ti,needs-special-reset;
> + status = "disabled";
> + };
Any specific reason why you did not add edma entry here as well?
Also, I wonder why "interrupt" property is not coming here, I understand
That hwmod is filling the gap here; but I would still recommend you to complete
The DT node, as we only support DT boot.
I will test the whole patch series today and update you.
Thanks,
Vaibhav
> +
> wdt2: wdt@44e35000 {
> compatible = "ti,omap3-wdt";
> ti,hwmods = "wd_timer2";
> --
> 1.7.9.5
>
> --
> 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
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
RE: [GIT PULL] ARM part of USB patches
On Tue, Feb 05, 2013 at 23:49:47, Tony Lindgren wrote: > * gre...@linuxfoundation.org [130205 09:28]: > > On Tue, Feb 05, 2013 at 08:56:13PM +0530, kishon wrote: > > > Hi Tony, Greg, > > > > > > On Tuesday 05 February 2013 08:54 PM, kishon wrote: > > > >Hi Tony, > > > > > > > >As discussed, I'm sending a pull request for the arch/arm part of my USB > > > >patches. These patches are necessary to get MUSB functional in both dt > > > >and non-dt boot. Also added dt data for dwc3 present in OMAP. This patch > > > >series *depends* on some of the patches which are merged in usb-next. > > > > > > This patch series should go in only after USB. Or else it will break > > > compilation. > > > > Then it probably should go through the USB tree, right? We don't want > > to break bisectability. > > Looks like this branch needs to be based on at least 01658f0f (usb: phy: > add a new driver for usb part of control module) to compile. Probably > needs other USB patches too to make sense. > > This branch has a high likelihood of conflicting with .dts files, so > Kishon, I suggest you do two branches: > > 1. A branch for Greg based on top of the USB changes > >This branch should contain: > >ARM: OMAP4: remove control module address space from PHY and OTG >ARM: OMAP: devices: create device for usb part of control module >ARM: OMAP2: MUSB: Specify omap4 has mailbox >ARM: OMAP: USB: Add phy binding information > >Naturally please make sure they compile and boot on their own. >Looks like this will only cause few trivial include merge conflicts >with what I have queued up. > >You can add my Acked-by: Tony Lindgren for those. > > 2. A branch for Benoit based on v3.8-rc6 > >That branch should contain all the .dts changes as those will >most likely cause nasty merge conflicts otherwise with what >Benoit has queued up. > Tony/Benoit, There are few AM33xx DTS patches pending from long time, how do you want to take it forward? You want me to put it into one branch and share? OR just provide the list of all patches to you? Thanks, Vaibhav > Regards, > > Tony > ___ > devicetree-discuss mailing list > devicetree-discuss@lists.ozlabs.org > https://lists.ozlabs.org/listinfo/devicetree-discuss > ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
RE: [PATCH v4 5/8] MFD: ti_am335x_tscadc: Add DT support
On Thu, Jan 31, 2013 at 09:41:11, Patil, Rachna wrote:
> On Wed, Jan 30, 2013 at 16:10:09, Koen Kooi wrote:
> >
> > Op 24 jan. 2013, om 04:45 heeft "Patil, Rachna" het
> > volgende geschreven:
> >
> > > From: "Patil, Rachna"
> > >
> > > Make changes to add DT support in the MFD core driver.
> > >
> > > Signed-off-by: Patil, Rachna
> > > ---
> > > Changes in v4:
> > > Non-standard properties prefixed with vendor name.
> > >
> > > drivers/mfd/ti_am335x_tscadc.c | 28 +++-
> > > 1 file changed, 23 insertions(+), 5 deletions(-)
> > >
> > > diff --git a/drivers/mfd/ti_am335x_tscadc.c
> > > b/drivers/mfd/ti_am335x_tscadc.c index e9f3fb5..87b446b 100644
> > > --- a/drivers/mfd/ti_am335x_tscadc.c
> > > +++ b/drivers/mfd/ti_am335x_tscadc.c
> > > @@ -22,6 +22,8 @@
> > > #include
> > > #include
> > > #include
> > > +#include
> > > +#include
> > >
> > > #include #include
> > >
> > > @@ -64,20 +66,31 @@ staticint ti_tscadc_probe(struct
> > > platform_device *pdev)
> > > struct resource *res;
> > > struct clk *clk;
> > > struct mfd_tscadc_board *pdata = pdev->dev.platform_data;
> > > + struct device_node *node = pdev->dev.of_node;
> > > struct mfd_cell *cell;
> > > int err, ctrl;
> > > int clk_value, clock_rate;
> > > - int tsc_wires, adc_channels = 0, total_channels;
> > > + int tsc_wires = 0, adc_channels = 0, total_channels;
> > >
> > > - if (!pdata) {
> > > + if (!pdata && !pdev->dev.of_node) {
> > > dev_err(&pdev->dev, "Could not find platform data\n");
> > > return -EINVAL;
> > > }
> > >
> > > - if (pdata->adc_init)
> > > - adc_channels = pdata->adc_init->adc_channels;
> > > + if (pdev->dev.platform_data) {
> > > + if (pdata->tsc_init)
> > > + tsc_wires = pdata->tsc_init->wires;
> > > +
> > > + if (pdata->adc_init)
> > > + adc_channels = pdata->adc_init->adc_channels;
> > > + } else {
> > > + node = of_find_node_by_name(pdev->dev.of_node, "tsc");
> > > + of_property_read_u32(node, "ti,wires", &tsc_wires);
> > > +
> > > + node = of_find_node_by_name(pdev->dev.of_node, "adc");
> > > + of_property_read_u32(node, "ti,adc-channels", &adc_channels);
> > > + }
> >
> > Since AM335x is DT only, why is there a platform data codepath and why is
> > it the first branch it tries? And I guess the next question is related to
> > the first: why doesn't it work when used with DT? When I copy over the
> > nodes from the evm.dts to my board I get "tsc tsc: Missing platform data"
> > in dmesg.
>
> This IP came up 1st on AM335x, but it is not platform dependent. The driver
> can be used on other platforms where-in DT is not supported.
> According to the maintainers platform data takes precedence over DT. Hence
> the order.
>
Rachana,
I see no point adding support for platform_data when you know that none of
older platforms are going to use this driver and all future platforms _must_
follow device-tree model.
So I agree that you should remove board file dependency from the driver.
> I do not see "Missing platform data" error msg in the latest driver. I am not
> able to trace from where this got populated.
>
Can you share the branch which you have tested?
Thanks,
Vaibhav
> >
> > What are the chances this driver will work when applied on top of 3.8-rcX?
> > Has it even been tested with that? Has it been tested at all?
>
> This driver has been tested on top of v3.8-rc3 on a AM335x EVM.
>
> Regards,
> Rachna
>
> ___
> devicetree-discuss mailing list
> devicetree-discuss@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/devicetree-discuss
>
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
RE: [PATCH 3/8] ARM: OMAP: AM33xx hwmod: Add parent-child relationship for PWM subsystem
On Tue, Nov 06, 2012 at 15:39:11, Bedia, Vaibhav wrote:
> On Mon, Nov 05, 2012 at 14:42:24, Philip, Avinash wrote:
> [...]
>
> > +
> > +static struct omap_hwmod_ocp_if am33xx_epwmss0__ecap0 = {
> > + .master = &am33xx_epwmss0_hwmod,
> > + .slave = &am33xx_ecap0_hwmod,
> > + .clk= "l4ls_gclk",
> > + .addr = am33xx_ecap0_addr_space,
> > + .user = OCP_USER_MPU,
> > +};
>
> Noticed this in another patch which is quite similar so commenting here
> again. Is the user field required if you are just creating a parent-child
> relationship here?
>
I think user field is not related to parent-child nodes, it defines the
initiator to interact with hwmod
Copy-pasted from "arch/arm/plat-omap/include/plat/omap_hwmod.h"
"indicate the initiators that use this interface to interact with the
hwmod"
And in this case, its MPU is the initiator to interact with this interface.
Thanks,
Vaibhav
> Regards,
> Vaibhav
>
>
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
RE: [PATCH V4 1/5] ARM: dts: OMAP: Add timer nodes
On Fri, Oct 26, 2012 at 00:44:26, Hunter, Jon wrote:
> Hi Benoit,
>
> On 10/24/2012 10:41 AM, Benoit Cousson wrote:
> > Hi Jon,
> >
> > On 10/19/2012 04:59 PM, Jon Hunter wrote:
> >> Add the 12 GP timers nodes present in OMAP2.
> >> Add the 12 GP timers nodes present in OMAP3.
> >> Add the 11 GP timers nodes present in OMAP4.
> >> Add the 7 GP timers nodes present in AM33xx.
> >>
> >> Add documentation for timer properties specific to OMAP.
> >>
> >> Thanks to Vaibhav Hiremath for creating the AM33xx timer nodes. I have
> >> modified
> >> Vaibhav's original nodes adding information on which timers support a PWM
> >> output.
> >>
> >> Cc: Benoit Cousson
> >> Signed-off-by: Jon Hunter
> >
> > I updated the patch to remove the interrupt-parent from the DTS nodes and
> > the documentation, as discussed on the list in the context of OMAP5 DTS for
> > GPIO.
> >
> > If you are OK with that version, I'll push it to Tony along with the others
> > DTS patches.
>
> Per our discussion please find below an updated patch with corrected
> register sizes.
>
> Vaibhav, I have changed the AM335x register size for timers to be 1KB
> instead of 4KB to align with the AM335x HWMOD. I have boot tested on
> the AM335x.
>
Make sense Jon.
Thanks,
Vaibhav
> Cheers
> Jon
>
> From 1bf082d78ecff2c1a08ffccc133010975d7478f5 Mon Sep 17 00:00:00 2001
> From: Jon Hunter
> Date: Fri, 19 Oct 2012 09:59:00 -0500
> Subject: [PATCH] ARM: dts: OMAP: Add timer nodes
>
> Add the 12 GP timers nodes present in OMAP2.
> Add the 12 GP timers nodes present in OMAP3.
> Add the 11 GP timers nodes present in OMAP4.
> Add the 7 GP timers nodes present in AM33xx.
>
> Add documentation for timer properties specific to OMAP.
>
> Thanks to Vaibhav Hiremath for creating the AM33xx timer nodes. I have
> modified
> Vaibhav's original nodes adding information on which timers support a PWM
> output.
>
> V5 changes:
> - Updated timer register sizes for OMAP2/3/4.
> - Modified AM335x timer register size to be 1KB instead of 4KB to align with
> HWMOD.
>
> Signed-off-by: Jon Hunter
> ---
> .../devicetree/bindings/arm/omap/timer.txt | 31 +++
> arch/arm/boot/dts/am33xx.dtsi | 54 +++
> arch/arm/boot/dts/omap2.dtsi | 85 ++
> arch/arm/boot/dts/omap2420.dtsi|8 ++
> arch/arm/boot/dts/omap2430.dtsi|8 ++
> arch/arm/boot/dts/omap3.dtsi | 95
>
> arch/arm/boot/dts/omap4.dtsi | 86 ++
> 7 files changed, 367 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/arm/omap/timer.txt
>
> diff --git a/Documentation/devicetree/bindings/arm/omap/timer.txt
> b/Documentation/devicetree/bindings/arm/omap/timer.txt
> new file mode 100644
> index 000..8732d4d
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/omap/timer.txt
> @@ -0,0 +1,31 @@
> +OMAP Timer bindings
> +
> +Required properties:
> +- compatible:Must be "ti,omap2-timer" for OMAP2+ controllers.
> +- reg: Contains timer register address range (base
> address and
> + length).
> +- interrupts:Contains the interrupt information for the
> timer. The
> + format is being dependent on which interrupt controller
> + the OMAP device uses.
> +- ti,hwmods: Name of the hwmod associated to the timer, "timer",
> + where is the instance number of the timer from the
> + HW spec.
> +
> +Optional properties:
> +- ti,timer-alwon:Indicates the timer is in an alway-on power domain.
> +- ti,timer-dsp: Indicates the timer can interrupt the on-chip
> DSP in
> + addition to the ARM CPU.
> +- ti,timer-pwm: Indicates the timer can generate a PWM output.
> +- ti,timer-secure: Indicates the timer is reserved on a secure OMAP device
> + and therefore cannot be used by the kernel.
> +
> +Example:
> +
> +timer12: timer@48304000 {
> + compatible = "ti,omap2-timer";
> + reg = <0x48304000 0x400>;
> + interrupts = <95>;
> + ti,hwmods = "timer12"
> + ti,timer-alwon;
> + ti,timer-secure;
> +};
> diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
> index 4709269..70d24b8 100644
> --- a/arch/arm/boot/dts/am33xx.dtsi
> +++ b/arch/arm/boot/dts/am33xx.dtsi
> @@ -237,5 +237,59 @@
> interrupts = <55>;
> status = "disabled";
> };
> +
> + timer1: timer@44e31000 {
> + compatible = "ti,omap2-timer";
> + reg = <0x44e31000 0x400>;
> + interrupts = <67>;
> + ti,hwmods = "timer1";
> + ti,timer-alwon;
> + };
> +
> + timer2: timer@4804 {
> +
RE: [PATCH V3 1/5] ARM: dts: OMAP: Add timer nodes
On Thu, Oct 25, 2012 at 18:03:37, Hunter, Jon wrote:
>
> On 10/25/2012 07:18 AM, Jon Hunter wrote:
>
> ...
>
> >> @@ -113,6 +114,9 @@ static int omap_timer_interrupt_test(struct
> >> omap_dm_timer *gptimer)
> >>
> >> irq_data.gptimer = gptimer;
> >> init_completion(&irq_data.complete);
> >> +
> >> + omap_dm_timer_enable(gptimer);
> >> +
> >> omap_dm_timer_set_int_enable(gptimer, OMAP_TIMER_INT_OVERFLOW);
> >> omap_dm_timer_set_load_start(gptimer, 0, 0xff00);
> >>
> >> @@ -128,6 +132,8 @@ static int omap_timer_interrupt_test(struct
> >> omap_dm_timer *gptimer)
> >>
> >> omap_dm_timer_stop(gptimer);
> >> omap_dm_timer_set_int_enable(gptimer, 0);
> >> + omap_dm_timer_disable(gptimer);
> >> +
> >
> > Hmmm ... I am wondering if there is another bug lingering in the dmtimer
> > driver. Ideally, the context should be preserved by the driver.
>
> Looking at omap_dm_timer_set_load_start() we have the following code to
> restore context ...
>
> if (!(timer->capability & OMAP_TIMER_ALWON)) {
> if (omap_pm_get_dev_context_loss_count(&timer->pdev->dev) !=
> timer->ctx_loss_count)
> omap_timer_restore_context(timer);
> }
>
> Can you see if this is getting called for AM33xx for the failing timers?
> If not then it would suggest that we are not detecting context loss
> correctly and not restoring the context. With the above context restore
> code we should not need those extra omap_dm_timer_enable/disable calls.
>
OK, below log explains all now,
--
Testing 48042000.timer with 2400 Hz clock ...
omap_dm_timer_set_load_start:559 ctx_loss_count - 0, get_dev_context - 0
Timer read test PASSED! No errors, 100 loops
omap_dm_timer_set_int_enable:665: irq_ena - 0
omap_dm_timer_set_int_enable:671: irq_ena - 2
omap_dm_timer_set_load_start:559 ctx_loss_count - 0, get_dev_context - 0
Timer interrupt test FAILED! No interrupt occurred in 1 sec
omap_dm_timer_set_int_enable:665: irq_ena - 0
omap_dm_timer_set_int_enable:671: irq_ena - 0
Testing 48042000.timer with 32768 Hz clock ...
omap_dm_timer_set_load_start:559 ctx_loss_count - 0, get_dev_context - 0
--
So below condition is not passing for AM33xx which results into context loss.
if (omap_pm_get_dev_context_loss_count(&timer->pdev->dev) !=
timer->ctx_loss_count)
Let me debug on this, this looks something specific to am33xx missing from
baseport.
Thanks,
Vaibhav
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
RE: [PATCH V3 1/5] ARM: dts: OMAP: Add timer nodes
On Thu, Oct 25, 2012 at 17:48:47, Hunter, Jon wrote: > > On 10/25/2012 07:12 AM, Hiremath, Vaibhav wrote: > > On Thu, Oct 25, 2012 at 04:30:37, Hunter, Jon wrote: > >> > >> On 10/24/2012 01:17 PM, Hiremath, Vaibhav wrote: > >>> On Wed, Oct 17, 2012 at 23:31:09, Hunter, Jon wrote: > >>>> Add the 12 GP timers nodes present in OMAP2. > >>>> Add the 12 GP timers nodes present in OMAP3. > >>>> Add the 11 GP timers nodes present in OMAP4. > >>>> Add the 7 GP timers nodes present in AM33xx. > >>>> > >>>> Add documentation for timer properties specific to OMAP. > >>>> > >>>> Please note that for OMAP2/3 devices, there is only one interrupt > >>>> controller > >>>> for the ARM CPU (which has the label "intc") and so globally define this > >>>> as the > >>>> interrupt parent to save duplicating the interrupt parent for all device > >>>> nodes. > >>>> > >>>> Thanks to Vaibhav Hiremath for creating the AM33xx timer nodes. I have > >>>> modified > >>>> Vaibhav's original nodes adding information on which timers support a PWM > >>>> output. > >>>> > >>>> Cc: Benoit Cousson > >>>> Signed-off-by: Jon Hunter > >>>> --- > >>>> .../devicetree/bindings/arm/omap/timer.txt | 29 ++ > >>>> arch/arm/boot/dts/am33xx.dtsi | 61 + > >>>> arch/arm/boot/dts/omap2.dtsi | 86 > >>>> ++ > >>>> arch/arm/boot/dts/omap2420.dtsi|8 ++ > >>>> arch/arm/boot/dts/omap2430.dtsi|8 ++ > >>>> arch/arm/boot/dts/omap3.dtsi | 96 > >>>> > >>>> arch/arm/boot/dts/omap4.dtsi | 86 > >>>> ++ > >>>> 7 files changed, 374 insertions(+) > >>>> create mode 100644 Documentation/devicetree/bindings/arm/omap/timer.txt > >>>> > >>> > >>> Although I have not tested this version of patch series at my end, but > >>> whole patch-series Looks ok to me. > >>> > >>> Acked-By: Vaibhav Hiremath > >> > >> Thanks. I made a couple cosmetic changes in V4 apart from the > >> "interrupt-parent" addition which we are now dropping. Care to ACK > >> patches 2-5 of V4? > >> > > > > Jon, > > > > Good news, I could able to spend some time today on Timer issue on Am33xx > > and figure out what is going wrong there. The register context is loosing, > > which leads to failure of interrupt test cases. > > Thanks! > > > Below log describes more on this, > > > > > > [root@arago /]# echo 1 > /tmp/omap-test/timer/all > > [9.156122] Testing 48042000.timer with 2400 Hz clock ... > > [root@arago /]# > > [root@arago /]# > > [root@arago /]# > > [root@arago /]# [ 11.505497] Timer read test PASSED! No errors, 100 loops > > [ 11.511493] omap_dm_timer_set_int_enable:664: irq_ena - 0 > > [ 11.517277] omap_dm_timer_set_int_enable:670: irq_ena - 2 > > [ 11.523095] omap_timer_interrupt_test:120: irq_ena - 0 [BM] > > [ 12.52] Timer interrupt test FAILED! No interrupt occurred in 1 sec > > > > > > I changed the Test code as below, and not with your Timer patches, I have > > tested all the timers without any issues. > > > > So for all patch series, > > > > Acked-Reviewed-&-Tested-By: Vaibhav Hiremath > > Thanks! > > > > > Test code diff: > > === > > > > diff --git a/timer_test.c b/timer_test.c > > index e502881..c87a830 100644 > > --- a/timer_test.c > > +++ b/timer_test.c > > @@ -13,6 +13,7 @@ > > > > #define OMAP1_NUM_TIMERS 8 > > #define OMAP2_NUM_TIMERS 11 > > +#define AM33XX_NUM_TIMERS 7 > > #define OMAP_MAX_NUM_TIMERS12 > > #define OMAP_TIMER_SRC_CLKS2 > > #define TIMER_TIMEOUT (msecs_to_jiffies(1000)) > > @@ -113,6 +114,9 @@ static int omap_timer_interrupt_test(struct > > omap_dm_timer *gptimer) > > > > irq_data.gptimer = gptimer; > > init_completion(&irq_data.complete); > > + > > + omap_dm_timer_enable(gptimer); > > + > >
RE: [PATCH V3 1/5] ARM: dts: OMAP: Add timer nodes
On Thu, Oct 25, 2012 at 04:30:37, Hunter, Jon wrote:
>
> On 10/24/2012 01:17 PM, Hiremath, Vaibhav wrote:
> > On Wed, Oct 17, 2012 at 23:31:09, Hunter, Jon wrote:
> >> Add the 12 GP timers nodes present in OMAP2.
> >> Add the 12 GP timers nodes present in OMAP3.
> >> Add the 11 GP timers nodes present in OMAP4.
> >> Add the 7 GP timers nodes present in AM33xx.
> >>
> >> Add documentation for timer properties specific to OMAP.
> >>
> >> Please note that for OMAP2/3 devices, there is only one interrupt
> >> controller
> >> for the ARM CPU (which has the label "intc") and so globally define this
> >> as the
> >> interrupt parent to save duplicating the interrupt parent for all device
> >> nodes.
> >>
> >> Thanks to Vaibhav Hiremath for creating the AM33xx timer nodes. I have
> >> modified
> >> Vaibhav's original nodes adding information on which timers support a PWM
> >> output.
> >>
> >> Cc: Benoit Cousson
> >> Signed-off-by: Jon Hunter
> >> ---
> >> .../devicetree/bindings/arm/omap/timer.txt | 29 ++
> >> arch/arm/boot/dts/am33xx.dtsi | 61 +
> >> arch/arm/boot/dts/omap2.dtsi | 86
> >> ++
> >> arch/arm/boot/dts/omap2420.dtsi|8 ++
> >> arch/arm/boot/dts/omap2430.dtsi|8 ++
> >> arch/arm/boot/dts/omap3.dtsi | 96
> >>
> >> arch/arm/boot/dts/omap4.dtsi | 86
> >> ++
> >> 7 files changed, 374 insertions(+)
> >> create mode 100644 Documentation/devicetree/bindings/arm/omap/timer.txt
> >>
> >
> > Although I have not tested this version of patch series at my end, but
> > whole patch-series Looks ok to me.
> >
> > Acked-By: Vaibhav Hiremath
>
> Thanks. I made a couple cosmetic changes in V4 apart from the
> "interrupt-parent" addition which we are now dropping. Care to ACK
> patches 2-5 of V4?
>
Jon,
Good news, I could able to spend some time today on Timer issue on Am33xx
and figure out what is going wrong there. The register context is loosing,
which leads to failure of interrupt test cases.
Below log describes more on this,
[root@arago /]# echo 1 > /tmp/omap-test/timer/all
[9.156122] Testing 48042000.timer with 2400 Hz clock ...
[root@arago /]#
[root@arago /]#
[root@arago /]#
[root@arago /]# [ 11.505497] Timer read test PASSED! No errors, 100 loops
[ 11.511493] omap_dm_timer_set_int_enable:664: irq_ena - 0
[ 11.517277] omap_dm_timer_set_int_enable:670: irq_ena - 2
[ 11.523095] omap_timer_interrupt_test:120: irq_ena - 0 [BM]
[ 12.52] Timer interrupt test FAILED! No interrupt occurred in 1 sec
I changed the Test code as below, and not with your Timer patches, I have
tested all the timers without any issues.
So for all patch series,
Acked-Reviewed-&-Tested-By: Vaibhav Hiremath
Test code diff:
===
diff --git a/timer_test.c b/timer_test.c
index e502881..c87a830 100644
--- a/timer_test.c
+++ b/timer_test.c
@@ -13,6 +13,7 @@
#define OMAP1_NUM_TIMERS 8
#define OMAP2_NUM_TIMERS 11
+#define AM33XX_NUM_TIMERS 7
#define OMAP_MAX_NUM_TIMERS12
#define OMAP_TIMER_SRC_CLKS2
#define TIMER_TIMEOUT (msecs_to_jiffies(1000))
@@ -113,6 +114,9 @@ static int omap_timer_interrupt_test(struct omap_dm_timer
*gptimer)
irq_data.gptimer = gptimer;
init_completion(&irq_data.complete);
+
+ omap_dm_timer_enable(gptimer);
+
omap_dm_timer_set_int_enable(gptimer, OMAP_TIMER_INT_OVERFLOW);
omap_dm_timer_set_load_start(gptimer, 0, 0xff00);
@@ -128,6 +132,8 @@ static int omap_timer_interrupt_test(struct omap_dm_timer
*gptimer)
omap_dm_timer_stop(gptimer);
omap_dm_timer_set_int_enable(gptimer, 0);
+ omap_dm_timer_disable(gptimer);
+
free_irq(timer_irq, &irq_data);
return r;
@@ -141,6 +147,8 @@ static u32 omap_timer_num_timers(void)
max_num_timers = OMAP1_NUM_TIMERS;
else if (cpu_is_omap34xx() && (omap_type() == OMAP2_DEVICE_TYPE_GP))
max_num_timers = OMAP2_NUM_TIMERS + 1;
+ else if (soc_is_am33xx())
+ max_num_timers = AM33XX_NUM_TIMERS;
else
max_num_timers = OMAP2_NUM_TIMERS;
@@ -222,6 +230,7 @@ static int omap_timer_test_all(void)
}
for (i = 0; i < count; i++) {
+ pr_info("\n\n");
r = omap_timer_run_tests(gptimers[i]);
if (r)
errors += r;
Thanks,
Vaibhav
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
RE: [PATCH V4 1/5] ARM: dts: OMAP: Add timer nodes
On Wed, Oct 24, 2012 at 21:11:13, Cousson, Benoit wrote:
> Hi Jon,
>
> On 10/19/2012 04:59 PM, Jon Hunter wrote:
> > Add the 12 GP timers nodes present in OMAP2.
> > Add the 12 GP timers nodes present in OMAP3.
> > Add the 11 GP timers nodes present in OMAP4.
> > Add the 7 GP timers nodes present in AM33xx.
> >
> > Add documentation for timer properties specific to OMAP.
> >
> > Thanks to Vaibhav Hiremath for creating the AM33xx timer nodes. I have
> > modified
> > Vaibhav's original nodes adding information on which timers support a PWM
> > output.
> >
> > Cc: Benoit Cousson
> > Signed-off-by: Jon Hunter
>
> I updated the patch to remove the interrupt-parent from the DTS nodes and the
> documentation, as discussed on the list in the context of OMAP5 DTS for GPIO.
>
> If you are OK with that version, I'll push it to Tony along with the others
> DTS patches.
>
> Regards,
> Benoit
>
> ---
> From 531cc8142ecd6da7929628772c4035dcf7996fef Mon Sep 17 00:00:00 2001
> From: Jon Hunter
> Date: Fri, 19 Oct 2012 09:59:00 -0500
> Subject: [PATCH] ARM: dts: OMAP: Add timer nodes
>
> Add the 12 GP timers nodes present in OMAP2.
> Add the 12 GP timers nodes present in OMAP3.
> Add the 11 GP timers nodes present in OMAP4.
> Add the 7 GP timers nodes present in AM33xx.
>
> Add documentation for timer properties specific to OMAP.
>
> Thanks to Vaibhav Hiremath for creating the AM33xx timer nodes. I have
> modified
> Vaibhav's original nodes adding information on which timers support a PWM
> output.
>
> Signed-off-by: Jon Hunter
> [b-cous...@ti.com: Remove the interrupt-parent from nodes]
> Signed-off-by: Benoit Cousson
> ---
> .../devicetree/bindings/arm/omap/timer.txt | 31 +++
> arch/arm/boot/dts/am33xx.dtsi | 54 +++
> arch/arm/boot/dts/omap2.dtsi | 85 +
> arch/arm/boot/dts/omap2420.dtsi|8 ++
> arch/arm/boot/dts/omap2430.dtsi|8 ++
> arch/arm/boot/dts/omap3.dtsi | 95
>
> arch/arm/boot/dts/omap4.dtsi | 86 ++
> 7 files changed, 367 insertions(+), 0 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/arm/omap/timer.txt
>
Benoit,
I have boot tested this on BeagleBone, so,
Tested-By: Vaibhav Hiremath
Thanks,
Vaibhav
> diff --git a/Documentation/devicetree/bindings/arm/omap/timer.txt
> b/Documentation/devicetree/bindings/arm/omap/timer.txt
> new file mode 100644
> index 000..b073d89
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/omap/timer.txt
> @@ -0,0 +1,31 @@
> +OMAP Timer bindings
> +
> +Required properties:
> +- compatible:Must be "ti,omap2-timer" for OMAP2+ controllers.
> +- reg: Contains timer register address range (base
> address and
> + length).
> +- interrupts:Contains the interrupt information for the
> timer. The
> + format is being dependent on which interrupt controller
> + the OMAP device uses.
> +- ti,hwmods: Name of the hwmod associated to the timer, "timer",
> + where is the instance number of the timer from the
> + HW spec.
> +
> +Optional properties:
> +- ti,timer-alwon:Indicates the timer is in an alway-on power domain.
> +- ti,timer-dsp: Indicates the timer can interrupt the on-chip
> DSP in
> + addition to the ARM CPU.
> +- ti,timer-pwm: Indicates the timer can generate a PWM output.
> +- ti,timer-secure: Indicates the timer is reserved on a secure OMAP device
> + and therefore cannot be used by the kernel.
> +
> +Example:
> +
> +timer12: timer@48304000 {
> + compatible = "ti,omap2-timer";
> + reg = <0x48304000 0xfff>;
> + interrupts = <95>;
> + ti,hwmods = "timer12"
> + ti,timer-alwon;
> + ti,timer-secure;
> +};
> diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
> index 4709269..7522e16 100644
> --- a/arch/arm/boot/dts/am33xx.dtsi
> +++ b/arch/arm/boot/dts/am33xx.dtsi
> @@ -237,5 +237,59 @@
> interrupts = <55>;
> status = "disabled";
> };
> +
> + timer1: timer@44e31000 {
> + compatible = "ti,omap2-timer";
> + reg = <0x44e31000 0x1000>;
> + interrupts = <67>;
> + ti,hwmods = "timer1";
> + ti,timer-alwon;
> + };
> +
> + timer2: timer@4804 {
> + compatible = "ti,omap2-timer";
> + reg = <0x4804 0x1000>;
> + interrupts = <68>;
> + ti,hwmods = "timer2";
> + };
> +
> + timer3: timer@48042000 {
> + compatible = "ti,omap2-timer";
>
RE: [PATCH V3 1/5] ARM: dts: OMAP: Add timer nodes
On Wed, Oct 17, 2012 at 23:31:09, Hunter, Jon wrote:
> Add the 12 GP timers nodes present in OMAP2.
> Add the 12 GP timers nodes present in OMAP3.
> Add the 11 GP timers nodes present in OMAP4.
> Add the 7 GP timers nodes present in AM33xx.
>
> Add documentation for timer properties specific to OMAP.
>
> Please note that for OMAP2/3 devices, there is only one interrupt controller
> for the ARM CPU (which has the label "intc") and so globally define this as
> the
> interrupt parent to save duplicating the interrupt parent for all device
> nodes.
>
> Thanks to Vaibhav Hiremath for creating the AM33xx timer nodes. I have
> modified
> Vaibhav's original nodes adding information on which timers support a PWM
> output.
>
> Cc: Benoit Cousson
> Signed-off-by: Jon Hunter
> ---
> .../devicetree/bindings/arm/omap/timer.txt | 29 ++
> arch/arm/boot/dts/am33xx.dtsi | 61 +
> arch/arm/boot/dts/omap2.dtsi | 86 ++
> arch/arm/boot/dts/omap2420.dtsi|8 ++
> arch/arm/boot/dts/omap2430.dtsi|8 ++
> arch/arm/boot/dts/omap3.dtsi | 96
>
> arch/arm/boot/dts/omap4.dtsi | 86 ++
> 7 files changed, 374 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/arm/omap/timer.txt
>
Although I have not tested this version of patch series at my end, but
whole patch-series Looks ok to me.
Acked-By: Vaibhav Hiremath
Thanks,
Vaibhav
> diff --git a/Documentation/devicetree/bindings/arm/omap/timer.txt
> b/Documentation/devicetree/bindings/arm/omap/timer.txt
> new file mode 100644
> index 000..d9449d0
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/omap/timer.txt
> @@ -0,0 +1,29 @@
> +OMAP Timer bindings
> +
> +Required properties:
> +- compatible:Must be "ti,omap2-timer" for OMAP2+ controllers
> +- reg: Contains timer register address range (base address and
> length)
> +- interrupts:Contains the interrupt information for the timer. The
> format is
> + being dependent on which interrupt controller the OMAP device
> + uses.
> +- ti,hwmods: Name of the hwmod associated to the timer, "timer", where
> + is the instance number of the timer from the HW spec.
> +
> +Optional properties:
> +- ti,timer-alwon:Indicates the timer is in an alway-on power domain.
> +- ti,timer-dsp: Indicates the timer can interrupt the on-chip
> DSP in
> + addition to the ARM CPU.
> +- ti,timer-pwm: Indicates the timer can generate a PWM output.
> +- ti,timer-secure: Indicates the timer is reserved on a secure OMAP device
> + and therefore cannot be used by the kernel.
> +
> +Example:
> +
> +timer12: timer@48304000 {
> + compatible = "ti,omap2-timer";
> + reg = <0x48304000 0xfff>;
> + interrupts = <95>;
> + ti,hwmods = "timer12"
> + ti,timer-alwon;
> + ti,timer-secure;
> +};
> diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
> index bb31bff..fd5074c 100644
> --- a/arch/arm/boot/dts/am33xx.dtsi
> +++ b/arch/arm/boot/dts/am33xx.dtsi
> @@ -210,5 +210,66 @@
> interrupt-parent = <&intc>;
> interrupts = <91>;
> };
> +
> + timer1: timer@44e31000 {
> + compatible = "ti,omap2-timer";
> + reg = <0x44e31000 0x1000>;
> + interrupt-parent = <&intc>;
> + interrupts = <67>;
> + ti,hwmods = "timer1";
> + ti,timer-alwon;
> + };
> +
> + timer2: timer@4804 {
> + compatible = "ti,omap2-timer";
> + reg = <0x4804 0x1000>;
> + interrupt-parent = <&intc>;
> + interrupts = <68>;
> + ti,hwmods = "timer2";
> + };
> +
> + timer3: timer@48042000 {
> + compatible = "ti,omap2-timer";
> + reg = <0x48042000 0x1000>;
> + interrupt-parent = <&intc>;
> + interrupts = <69>;
> + ti,hwmods = "timer3";
> + };
> +
> + timer4: timer@48044000 {
> + compatible = "ti,omap2-timer";
> + reg = <0x48044000 0x1000>;
> + interrupt-parent = <&intc>;
> + interrupts = <92>;
> + ti,hwmods = "timer4";
> + ti,timer-pwm;
> + };
> +
> + timer5: timer@48046000 {
> + compatible = "ti,omap2-timer";
> + reg = <0x48046000 0x1000>;
> + interrupt-parent = <&intc>;
> + interrupts = <93>;
> +
RE: [PATCH] ARM: dts: OMAP: Move interrupt-parent to the root node to avoid duplication
On Wed, Oct 24, 2012 at 15:32:14, Cousson, Benoit wrote:
> The interrupt-parent attribute does not have to be added in each
> node since the DT framework will check for the parent as well to get it.
>
> Create an interrupt-parent for OMAP2, OMAP3, AM33xx and remove the
> attributes from every nodes that were using it.
>
> Signed-off-by: Benoit Cousson
> Cc: Vaibhav Hiremath
> Cc: Peter Ujfalusi
> Cc: Sebastien Guiriec
> ---
>
> This patch was triggered by the thread about Seb's patch [1].
> So let's clean the current OMAP/AM stuff right now to be consistent.
>
> The patch applies on top of the for_3.8/dts [2] branch.
>
> Regards,
> Benoit
>
> [1] https://lkml.org/lkml/2012/10/24/85
> [2] git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git
>
>
> arch/arm/boot/dts/am33xx.dtsi | 17 +
> arch/arm/boot/dts/omap2.dtsi|1 +
> arch/arm/boot/dts/omap2420.dtsi |2 --
> arch/arm/boot/dts/omap2430.dtsi |5 -
> arch/arm/boot/dts/omap3.dtsi|6 +-
> arch/arm/boot/dts/omap4.dtsi|6 --
> arch/arm/boot/dts/omap5.dtsi|5 -
> 7 files changed, 3 insertions(+), 39 deletions(-)
>
Looks good to me.
Acked-by: Vaibhav Hiremath
Thanks,
Vaibhav
> diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
> index 64c2efe..4709269 100644
> --- a/arch/arm/boot/dts/am33xx.dtsi
> +++ b/arch/arm/boot/dts/am33xx.dtsi
> @@ -12,6 +12,7 @@
>
> / {
> compatible = "ti,am33xx";
> + interrupt-parent = <&intc>;
>
> aliases {
> serial0 = &uart1;
> @@ -94,7 +95,6 @@
> interrupt-controller;
> #interrupt-cells = <1>;
> reg = <0x44e07000 0x1000>;
> - interrupt-parent = <&intc>;
> interrupts = <96>;
> };
>
> @@ -106,7 +106,6 @@
> interrupt-controller;
> #interrupt-cells = <1>;
> reg = <0x4804c000 0x1000>;
> - interrupt-parent = <&intc>;
> interrupts = <98>;
> };
>
> @@ -118,7 +117,6 @@
> interrupt-controller;
> #interrupt-cells = <1>;
> reg = <0x481ac000 0x1000>;
> - interrupt-parent = <&intc>;
> interrupts = <32>;
> };
>
> @@ -130,7 +128,6 @@
> interrupt-controller;
> #interrupt-cells = <1>;
> reg = <0x481ae000 0x1000>;
> - interrupt-parent = <&intc>;
> interrupts = <62>;
> };
>
> @@ -139,7 +136,6 @@
> ti,hwmods = "uart1";
> clock-frequency = <4800>;
> reg = <0x44e09000 0x2000>;
> - interrupt-parent = <&intc>;
> interrupts = <72>;
> status = "disabled";
> };
> @@ -149,7 +145,6 @@
> ti,hwmods = "uart2";
> clock-frequency = <4800>;
> reg = <0x48022000 0x2000>;
> - interrupt-parent = <&intc>;
> interrupts = <73>;
> status = "disabled";
> };
> @@ -159,7 +154,6 @@
> ti,hwmods = "uart3";
> clock-frequency = <4800>;
> reg = <0x48024000 0x2000>;
> - interrupt-parent = <&intc>;
> interrupts = <74>;
> status = "disabled";
> };
> @@ -169,7 +163,6 @@
> ti,hwmods = "uart4";
> clock-frequency = <4800>;
> reg = <0x481a6000 0x2000>;
> - interrupt-parent = <&intc>;
> interrupts = <44>;
> status = "disabled";
> };
> @@ -179,7 +172,6 @@
> ti,hwmods = "uart5";
> clock-frequency = <4800>;
> reg = <0x481a8000 0x2000>;
> - interrupt-parent = <&intc>;
> interrupts = <45>;
> status = "disabled";
> };
> @@ -189,7 +181,6 @@
> ti,hwmods = "uart6";
> clock-frequency = <4800>;
> reg = <0x481aa000 0x2000>;
> - interrupt-parent = <&intc>;
> interrupts = <46>;
> status = "disabled";
> };
> @@ -200,7 +191,6 @@
> #size-cells = <0>;
> ti,hwmods = "i2c1";
> reg = <0x44e0b000 0x1000>;
> - interrupt-parent = <&intc>;
> interrupts = <70>;
> sta
RE: [PATCH] ARM: OMAP2+: gpmc: Fix kernel BUG for DT boot mode
On Wed, Oct 10, 2012 at 19:30:27, Porter, Matt wrote: > On Tue, Oct 09, 2012 at 02:27:20PM +0530, Vaibhav Hiremath wrote: > > With recent changes in omap gpmc driver code, in case of DT > > boot mode, where bootloader does not configure gpmc cs space > > will result into kernel BUG() inside gpmc_mem_init() function, > > as gpmc cs0 gpmc_config7[0].csvalid bit is set to '1' and > > gpmc_config7[0].baseaddress is set to '0' on reset. > > > > This use-case is applicable for any board/EVM which doesn't have > > any peripheral connected to gpmc cs0, for example BeagleXM and > > BeagleBone, so DT boot mode fails. > > > > This patch adds of_have_populated_dt() check before creating > > device, so that for DT boot mode, gpmc probe will not be called > > which is expected behavior, as gpmc is not supported yet from DT. > > > > Signed-off-by: Vaibhav Hiremath > > Cc: Afzal Mohammed > > Cc: Tony Lindgren > > Cc Paul Walmsley > > --- > > This should go in for rc1, as this breaks AM33xx boot. > > Fixes BeagleBone on mainline. > > Tested-by: Matt Porter > Thanks Matt and Afzal, Tony can this be picked up for rc1?? I know you have already sent pull request for rc1, but by any chance you are planning to send another request? Thanks, Vaibhav > -Matt > ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
RE: [PATCH V2 0/7] ARM: OMAP2+: Add device-tree support for timers
On Sat, Sep 29, 2012 at 03:17:51, Hunter, Jon wrote: > > On 09/28/2012 01:51 PM, Vaibhav Hiremath wrote: > > > > > > On 9/26/2012 10:23 PM, Jon Hunter wrote: > >> > >> On 09/20/2012 06:53 PM, Tony Lindgren wrote: > >>> * Benoit Cousson [120919 19:24]: > Hi Tony, > > I was about to take the DTS patch, but was wondering if you will pull > the driver changes for 3.7. > >>> > >>> I suggest that you do a separate branch on top of Paul's hwmod series > >>> when he posts those if that works for you? > >> > >> Benoit, I see that you have pulled in the DTS patch. > >> > >> Do you guys want me to rebase the remaining patches with Rob's change on > >> Tony's master branch and re-submit? > >> > > > > Jon, > > > > Sorry for delayed response, But I tried using your omap_test application > > to validate this patch series, but it is failing for me. > > > > How did you test it? Are you running same test application at your end? > > Sorry, I now see you are using the latest test code! I was too hasty > when I saw the first error ;-) > Jon, have patience ;-) I understand, sometimes it happens un-intentionally. > > I am debugging this issue, i just thought I should tell you this before > > its too late. > > Thanks. > > > Below is the log - > > > > [root@arago /]# echo 3 > /tmp/omap-test/timer/one > > [ 79.612223] omap_dm_timer_request_specific: Please use > > omap_dm_timer_request_by_cap() > > [ 79.620636] Timer 3 not available! > > This is expected because omap_dm_timer_request_specific() is no longer > supported. I should remove in the omap-test/timer/one going forward. > > > [root@arago /]# > > [root@arago /]# echo 3 > /tmp/omap-test/timer/all > > [ 135.111949] Testing 48042000.timer with 2400 Hz clock ... > > [root@arago /]# [ 137.457389] Timer read test PASSED! No errors, 100 loops > > [ 137.463267] Timer interrupt test PASSED! > > [ 137.467650] Testing 48042000.timer with 32768 Hz clock ... > > [ 139.816892] Timer read test PASSED! No errors, 100 loops > > [ 139.830776] Timer interrupt test PASSED! > > [ 139.835245] Testing 48044000.timer with 2400 Hz clock ... > > [ 142.183912] Timer read test PASSED! No errors, 100 loops > > [ 142.189734] Timer interrupt test PASSED! > > [ 142.194076] Testing 48044000.timer with 32768 Hz clock ... > > [ 144.543451] Timer read test PASSED! No errors, 100 loops > > [ 144.557334] Timer interrupt test PASSED! > > [ 144.561806] Testing 48046000.timer with 2400 Hz clock ... > > [ 146.910469] Timer read test PASSED! No errors, 100 loops > > [ 147.910493] Timer interrupt test FAILED! No interrupt occurred in 1 sec > > [ 147.917598] Testing 48046000.timer with 32768 Hz clock ... > > [ 150.262203] Timer read test PASSED! No errors, 100 loops > > [ 151.262049] Timer interrupt test FAILED! No interrupt occurred in 1 sec > > [ 151.269298] Testing 48048000.timer with 2400 Hz clock ... > > [ 153.613596] Timer read test PASSED! No errors, 100 loops > > [ 154.613618] Timer interrupt test FAILED! No interrupt occurred in 1 sec > > [ 154.620725] Testing 48048000.timer with 32768 Hz clock ... > > [ 156.965324] Timer read test PASSED! No errors, 100 loops > > [ 157.965176] Timer interrupt test FAILED! No interrupt occurred in 1 sec > > [ 157.972419] Testing 4804a000.timer with 2400 Hz clock ... > > > > [root@arago /]# [ 160.316753] Timer read test PASSED! No errors, 100 loops > > > > [root@arago /]# [ 161.316728] Timer interrupt test FAILED! No interrupt > > occurred in 1 sec > > [ 161.323912] Testing 4804a000.timer with 32768 Hz clock ... > > > > [root@arago /]# [ 163.668490] Timer read test PASSED! No errors, 100 loops > > [ 164.668328] Timer interrupt test FAILED! No interrupt occurred in 1 sec > > [ 164.675545] Tested 5 timers, skipped 6 timers and detected 6 errors > > [ 164.682202] Test iteration 0 complete in 29 secs > > [ 164.687104] Test summary: Iterations 1, Errors 6 > > What is interesting is that it is the interrupt test that is failing for > timers 5-7. Any chance there is a problem with the interrupt mapping? I > checked the documentation for AM335x and I don't see anything obvious > that is wrong with the binding unless the documentation itself is wrong. > > Given that the interrupts work on timers 3 and 4 it appears to be a > interrupt configuration problem somewhere. We could adapt the test to > see if an interrupt is pending in the timer peripheral when it fails. > This would tell us that the timer is working but the interrupt is not > being enabled correctly in the interrupt controller. > I am also surprised to see this, and as you mentioned, nothing I looks obviously wrong to me in timer5-7. I have to debug this further and will keep you updated. Thanks, Vaibhav > Cheers > Jon > ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
RE: [PATCH v2 1/8] ARM/dts: OMAP2: Add McBSP entries for OMAP2420 and OMAP2430 SoC
+ Andrew, On Thu, Sep 06, 2012 at 20:12:07, Cousson, Benoit wrote: > > On 09/05/2012 04:41 PM, Hiremath, Vaibhav wrote: > ... > > There are other patches which are pending, > > > > arm/dts: AM33XX: Convert all hex numbers to lower-case > > https://patchwork.kernel.org/patch/1377351/ > > arm/dts: AM33XX: Specify reg and interrupt property for all nodes > > https://patchwork.kernel.org/patch/1377361/ > > OK, so these ones are fine, you should just rebase them because theyu > are conflicting with patches already inside lo/devel-dt > > > Probably your Ack is required for, > > > > ARM: AM33XX: clock: Add dcan clock aliases for device-tree > > https://patchwork.kernel.org/patch/1377061/ > > Paul already queued this one so it is fine. > > > RTC: > > I am not sure how to deal with RTC DT support, as I understand the list is > > very unresponsive there. > > OK, so I did have the same issue for TWL RTC since the maintainer is no > longer very active. In that case you should go through Andrew Morton. > Andrew, Can you please merge these omap-rtc patches, there are no review comments so far and I believe it should be safe now to merge. Thanks, Vaiibhav > Regards, > Benoit > > > http://www.mail-archive.com/davinci-linux-open-source@linux.davincidsp.com/msg23253.html > > ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
RE: [PATCH v2 3/3] usb: musb: omap: Add device tree support for omap musb glue
On Tue, Sep 11, 2012 at 16:54:37, ABRAHAM, KISHON VIJAY wrote:
> Hi,
>
> On Tue, Sep 11, 2012 at 3:23 PM, Vaibhav Hiremath wrote:
> >
> >
> > On 9/11/2012 2:39 PM, Kishon Vijay Abraham I wrote:
> >> Added device tree support for omap musb driver and updated the
> >> Documentation with device tree binding information.
> >>
> >> Signed-off-by: Kishon Vijay Abraham I
> >> ---
> >> Documentation/devicetree/bindings/usb/omap-usb.txt | 33
> >> drivers/usb/musb/omap2430.c| 54
> >>
> >> 2 files changed, 87 insertions(+)
> >> create mode 100644 Documentation/devicetree/bindings/usb/omap-usb.txt
> >>
> >> diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt
> >> b/Documentation/devicetree/bindings/usb/omap-usb.txt
> >> new file mode 100644
> >> index 000..29a043e
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/usb/omap-usb.txt
> >> @@ -0,0 +1,33 @@
> >> +OMAP GLUE
> >> +
> >> +OMAP MUSB GLUE
> >> + - compatible : Should be "ti,omap4-musb" or "ti,omap3-musb"
> >> + - ti,hwmods : must be "usb_otg_hs"
> >> + - multipoint : Should be "1" indicating the musb controller supports
> >> + multipoint. This is a MUSB configuration-specific setting.
> >> + - num_eps : Specifies the number of endpoints. This is also a
> >> + MUSB configuration-specific setting. Should be set to "16"
> >> + - ram_bits : Specifies the ram address size. Should be set to "12"
> >> + - interface_type : This is a board specific setting to describe the type
> >> of
> >> + interface between the controller and the phy. It should be "0" or "1"
> >> + specifying ULPI and UTMI respectively.
> >> + - mode : Should be "3" to represent OTG. "1" signifies HOST and "2"
> >> + represents PERIPHERAL.
> >> + - power : Should be "50". This signifies the controller can supply upto
> >> + 100mA when operating in host mode.
> >> +
> >> +SOC specific device node entry
> >> +usb_otg_hs: usb_otg_hs@4a0ab000 {
> >> + compatible = "ti,omap4-musb";
> >> + ti,hwmods = "usb_otg_hs";
> >> + multipoint = <1>;
> >> + num_eps = <16>;
> >> + ram_bits = <12>;
> >> +};
> >
> >
> > reg and interrupt properties are missing here.
> >
> > I would encourage to specify "reg" and "interrupt" properties in every
> > node getting newly added to the OMAP DTS files.
>
> Sure. will add that in my next version.
>
I saw there is some discussion going-on for which baseline to use, so make
sure that you test the patches on top of below patch (already available in
linux-omap/devel-dt)
http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap.git;a=commit;h=b82b04e8eb27abe0cfe9cd7bf4fee8bb1bb9b013
Thanks,
Vaibhav
> Thanks
> Kishon
>
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
RE: [PATCH] ARM: dts: AM33XX: fix gpio node numbering to match hardware
On Tue, Sep 11, 2012 at 16:59:05, Porter, Matt wrote:
> On Tue, Sep 11, 2012 at 04:57:08AM +0000, Hiremath, Vaibhav wrote:
> > On Mon, Sep 10, 2012 at 21:50:20, Porter, Matt wrote:
> > > On AM33xx, the datasheet and TRM refer to four GPIO instances that
> > > are 0-based, GPIO0-3.
> > >
> >
> > Thanks Matt,
> > I think Anil labeled it as gpio1-4 due to hwmod naming convention, as you
> > can not have gpioo id = 0 (refer to arch/arm/mach-omap2/gpio.c).
>
> Right, and that convention originally came from the assumption that
> everything would be 1-based like OMAP3/4.
>
> > But in case of DT we should simply follow TRM/Spec, as naming convention is
> > based on base-addr and not id, so your patch looks good me.
>
> Yes, my biggest concern here was the coming frustration that the end
> "user" or system integrator would have with these labels not matching
> the docs that have been around for a year. It would be !sane to have
> somebody look at a schematic and then write their dts with a value that
> doesn't match the h/w. That would run counter to the fundamental
> requirement that DT is a description of the hardware. The user led patch
> was already the first example of that where the comments mentioned gpio1
> in the pinmux data but the data referenced the gpio2 label.
>
I understand and your patch is already fixing the "biggest concern" here,
right.
Thanks,
Vaibhav
> -Matt
>
> > > Signed-off-by: Matt Porter
> > > ---
> > > arch/arm/boot/dts/am33xx.dtsi |8
> > > 1 file changed, 4 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
> > > index bb31bff..1369bfc 100644
> > > --- a/arch/arm/boot/dts/am33xx.dtsi
> > > +++ b/arch/arm/boot/dts/am33xx.dtsi
> > > @@ -62,7 +62,7 @@
> > > reg = <0x4820 0x1000>;
> > > };
> > >
> > > - gpio1: gpio@44e07000 {
> > > + gpio0: gpio@44e07000 {
> > > compatible = "ti,omap4-gpio";
> > > ti,hwmods = "gpio1";
> > > gpio-controller;
> > > @@ -74,7 +74,7 @@
> > > interrupts = <96>;
> > > };
> > >
> > > - gpio2: gpio@4804c000 {
> > > + gpio1: gpio@4804c000 {
> > > compatible = "ti,omap4-gpio";
> > > ti,hwmods = "gpio2";
> > > gpio-controller;
> > > @@ -86,7 +86,7 @@
> > > interrupts = <98>;
> > > };
> > >
> > > - gpio3: gpio@481ac000 {
> > > + gpio2: gpio@481ac000 {
> > > compatible = "ti,omap4-gpio";
> > > ti,hwmods = "gpio3";
> > > gpio-controller;
> > > @@ -98,7 +98,7 @@
> > > interrupts = <32>;
> > > };
> > >
> > > - gpio4: gpio@481ae000 {
> > > + gpio3: gpio@481ae000 {
> > > compatible = "ti,omap4-gpio";
> > > ti,hwmods = "gpio4";
> > > gpio-controller;
> > > --
> > > 1.7.9.5
> > >
> > >
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to majord...@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at http://www.tux.org/lkml/
>
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
RE: [PATCH] ARM: OMAP2+: Makefile.boot: Add am335x evm and bone targets
On Fri, Aug 31, 2012 at 23:24:34, Hiremath, Vaibhav wrote: > This adds am335x-evm and am335x-bone dtb targets to > 'make dtbs', just like other platforms. > > Signed-off-by: Vaibhav Hiremath > Cc: Tony Lindgren > --- > arch/arm/mach-omap2/Makefile.boot |1 + > 1 files changed, 1 insertions(+), 0 deletions(-) > > diff --git a/arch/arm/mach-omap2/Makefile.boot > b/arch/arm/mach-omap2/Makefile.boot > index 6cf1c2d..1136072 100644 > --- a/arch/arm/mach-omap2/Makefile.boot > +++ b/arch/arm/mach-omap2/Makefile.boot > @@ -7,3 +7,4 @@ dtb-$(CONFIG_ARCH_OMAP3) += omap3-beagle.dtb > omap3-evm.dtb > dtb-$(CONFIG_ARCH_OMAP4) += omap4-panda.dtb omap4-pandaES.dtb > dtb-$(CONFIG_ARCH_OMAP4) += omap4-var_som.dtb omap4-sdp.dtb > dtb-$(CONFIG_SOC_OMAP5) += omap5-evm.dtb > +dtb-$(CONFIG_SOC_AM33XX) += am335x-evm.dtb am335x-bone.dtb Tony, Gentle reminder on this patch !!! Thanks, Vaibhav > -- > 1.7.0.4 > > ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
RE: [PATCH v2 0/2] ARM: dts: AM33xx: Correct gpio labels to match docs
On Tue, Sep 11, 2012 at 01:15:10, Porter, Matt wrote: > Changes since v1: > - Series now applies on top of Anil's AM33XX DTS series > > This series applies on top of the for_3.7/dts/ branch and Anil's > "[v7,2/3] arm/dts: AM33XX: Configure pinmuxs for user leds control on Bone" > patch that is part of the overall series adding led and pinctrl DTS data > for AM33xx. > > It is intended to correct the current labeling of gpios in the DTS before > too many more drivers are submitted for AM33xx that have gpios not matching > the docs. > > Matt Porter (2): > ARM: dts: AM33XX: fix gpio node numbering to match hardware > ARM: dts: AM33XX: adjust leds to use the corrected gpio label > I have tested this series on BeagleBone, also validated LED functionality. Tested-Acked-By: Vaibhav Hiremath Thanks, Vaibhav > arch/arm/boot/dts/am335x-bone.dts |8 > arch/arm/boot/dts/am33xx.dtsi |8 > 2 files changed, 8 insertions(+), 8 deletions(-) > > -- > 1.7.9.5 > > ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
RE: [PATCH] ARM: dts: AM33XX: fix gpio node numbering to match hardware
On Mon, Sep 10, 2012 at 22:29:21, Cousson, Benoit wrote:
> On 09/10/2012 06:52 PM, Matt Porter wrote:
> > On Mon, Sep 10, 2012 at 06:34:20PM +0200, Benoit Cousson wrote:
> >> + Tony
> >>
> >> Hi Matt,
> >>
> >> 30 minutes too late for my pull request :-(
> >>
> >> There are a couple of am33xx patches under discussion, so I'll take them
> >> and send a for_3.7/dts-part2 pull request if this is not too late for Tony.
> >
> > Yeah, believe me, I did a faceplant when I saw your pull request come by
> > at the same time I discovered this issue. ;) In particular, AnilKumar's
> > user leds patch would need to be adjusted for this change. I can
> > resubmit with the user leds dts changes adjusted as well if that
> > discussion comes to a conclusion and his patches accepted.
>
> Yeah, I was wondering if the gpios label were already used somewhere.
> I've just added this patch on top of my current series.
> So you or Anil should just post the missing patches whenever they'll be
> available and accepted.
>
> >> On 09/10/2012 06:20 PM, Matt Porter wrote:
> >>> On AM33xx, the datasheet and TRM refer to four GPIO instances that
> >>> are 0-based, GPIO0-3.
> >>
> >> Or maybe you should just update the spec to use a 1-based GPIO number
> >> like OMAP :-)
> >
> > I am powerless here. :)
>
> That's too bad :-(
>
I agree with Matt here. Also at this point of time it is too much change to
modify spec for this, and certainly it would be very confusing.
Thanks,
Vaibhav
> Benoit
>
> >
> > -Matt
> >
> >>> Signed-off-by: Matt Porter
> >>> ---
> >>> arch/arm/boot/dts/am33xx.dtsi |8
> >>> 1 file changed, 4 insertions(+), 4 deletions(-)
> >>>
> >>> diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
> >>> index bb31bff..1369bfc 100644
> >>> --- a/arch/arm/boot/dts/am33xx.dtsi
> >>> +++ b/arch/arm/boot/dts/am33xx.dtsi
> >>> @@ -62,7 +62,7 @@
> >>> reg = <0x4820 0x1000>;
> >>> };
> >>>
> >>> - gpio1: gpio@44e07000 {
> >>> + gpio0: gpio@44e07000 {
> >>> compatible = "ti,omap4-gpio";
> >>> ti,hwmods = "gpio1";
> >>> gpio-controller;
> >>> @@ -74,7 +74,7 @@
> >>> interrupts = <96>;
> >>> };
> >>>
> >>> - gpio2: gpio@4804c000 {
> >>> + gpio1: gpio@4804c000 {
> >>> compatible = "ti,omap4-gpio";
> >>> ti,hwmods = "gpio2";
> >>> gpio-controller;
> >>> @@ -86,7 +86,7 @@
> >>> interrupts = <98>;
> >>> };
> >>>
> >>> - gpio3: gpio@481ac000 {
> >>> + gpio2: gpio@481ac000 {
> >>> compatible = "ti,omap4-gpio";
> >>> ti,hwmods = "gpio3";
> >>> gpio-controller;
> >>> @@ -98,7 +98,7 @@
> >>> interrupts = <32>;
> >>> };
> >>>
> >>> - gpio4: gpio@481ae000 {
> >>> + gpio3: gpio@481ae000 {
> >>> compatible = "ti,omap4-gpio";
> >>> ti,hwmods = "gpio4";
> >>> gpio-controller;
> >>>
> >>
> >> --
> >> 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
>
>
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
RE: [PATCH] ARM: dts: AM33XX: fix gpio node numbering to match hardware
On Mon, Sep 10, 2012 at 21:50:20, Porter, Matt wrote:
> On AM33xx, the datasheet and TRM refer to four GPIO instances that
> are 0-based, GPIO0-3.
>
Thanks Matt,
I think Anil labeled it as gpio1-4 due to hwmod naming convention, as you
can not have gpioo id = 0 (refer to arch/arm/mach-omap2/gpio.c).
But in case of DT we should simply follow TRM/Spec, as naming convention is
based on base-addr and not id, so your patch looks good me.
Thanks,
Vaibhav
> Signed-off-by: Matt Porter
> ---
> arch/arm/boot/dts/am33xx.dtsi |8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
> index bb31bff..1369bfc 100644
> --- a/arch/arm/boot/dts/am33xx.dtsi
> +++ b/arch/arm/boot/dts/am33xx.dtsi
> @@ -62,7 +62,7 @@
> reg = <0x4820 0x1000>;
> };
>
> - gpio1: gpio@44e07000 {
> + gpio0: gpio@44e07000 {
> compatible = "ti,omap4-gpio";
> ti,hwmods = "gpio1";
> gpio-controller;
> @@ -74,7 +74,7 @@
> interrupts = <96>;
> };
>
> - gpio2: gpio@4804c000 {
> + gpio1: gpio@4804c000 {
> compatible = "ti,omap4-gpio";
> ti,hwmods = "gpio2";
> gpio-controller;
> @@ -86,7 +86,7 @@
> interrupts = <98>;
> };
>
> - gpio3: gpio@481ac000 {
> + gpio2: gpio@481ac000 {
> compatible = "ti,omap4-gpio";
> ti,hwmods = "gpio3";
> gpio-controller;
> @@ -98,7 +98,7 @@
> interrupts = <32>;
> };
>
> - gpio4: gpio@481ae000 {
> + gpio3: gpio@481ae000 {
> compatible = "ti,omap4-gpio";
> ti,hwmods = "gpio4";
> gpio-controller;
> --
> 1.7.9.5
>
>
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
RE: [RFC PATCH] ARM: OMAP2+: omap-device: Do not overwrite resources allocated by OF layer
On Fri, Sep 07, 2012 at 23:17:37, Cousson, Benoit wrote:
> Hi Vaibhav,
>
> The following patch is hacing some checkpatch issues.
>
> CHECK: Alignment should match open parenthesis
> #169: FILE: arch/arm/plat-omap/omap_device.c:591:
> + dev_dbg(&pdev->dev, "%s(): resources already allocated
> %d\n",
> + __func__, res_count);
>
> CHECK: Alignment should match open parenthesis
> #171: FILE: arch/arm/plat-omap/omap_device.c:593:
> + memcpy(res, pdev->resource,
> + sizeof(struct resource) * pdev->num_resources);
>
> CHECK: Alignment should match open parenthesis
> #173: FILE: arch/arm/plat-omap/omap_device.c:595:
> + omap_device_fill_dma_resources(od,
> + &res[pdev->num_resources]);
>
> CHECK: Alignment should match open parenthesis
> #176: FILE: arch/arm/plat-omap/omap_device.c:598:
> + dev_dbg(&pdev->dev, "%s(): using resources from hwmod
> %d\n",
> + __func__, res_count);
>
> total: 0 errors, 0 warnings, 4 checks, 130 lines checked
>
>
> Since I was in a nice mood, because the week-end is almost there, I fixed
> them myself.
>
My bad...I usually do check for checkpatch.pl and sparse warnings, not sure
how did I miss this one. I will be more careful here onwards.
> Please note that I had to rename the API becasue it was way too long to do a
> proper alignement.
>
> omap_device_fill_dma_resources -> _od_fill_dma_resources
>
> In fact I realized that some private APIs should probably be renamed as well
> like that for
> consistency.
>
> Just let me know if you have any issue with that version.
>
Looks ok to me.
Thanks,
Vaibhav
> Regards,
> Benoit
>
> ---
> From b82b04e8eb27abe0cfe9cd7bf4fee8bb1bb9b013 Mon Sep 17 00:00:00 2001
> From: Vaibhav Hiremath
> Date: Wed, 29 Aug 2012 15:18:11 +0530
> Subject: [PATCH] ARM: OMAP: omap_device: Do not overwrite resources allocated
> by OF layer
>
> With the new devices (like, AM33XX and OMAP5) we now only support
> DT boot mode of operation and now it is the time to start killing
> slowly the dependency on hwmod, so with this patch, we are starting
> with device resources.
> The idea here is implemented considering to both boot modes -
> - DT boot mode
> OF framework will construct the resource structure (currently
> does for MEM & IRQ resource) and we should respect/use these
> resources, killing hwmod dependency.
> If pdev->num_resources > 0, we assume that MEM & IRQ resources
> have been allocated by OF layer already (through DTB).
>
> Once DMA resource is available from OF layer, we should
> kill filling any resources from hwmod.
>
> - Non-DT boot mode
> Here, pdev->num_resources = 0, and we should get all the
> resources from hwmod (following existing steps)
>
> Signed-off-by: Vaibhav Hiremath
> Cc: Tony Lindgren
> Cc: Paul Walmsley
> Cc: Kevin Hilman
> [b-cous...@ti.com: Fix some checkpatch CHECK issues]
> Signed-off-by: Benoit Cousson
> ---
> arch/arm/mach-omap2/omap_hwmod.c | 27 ++
> arch/arm/plat-omap/include/plat/omap_hwmod.h |1 +
> arch/arm/plat-omap/omap_device.c | 71 +
> 3 files changed, 87 insertions(+), 12 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/omap_hwmod.c
> b/arch/arm/mach-omap2/omap_hwmod.c
> index 6ca8e51..7768804 100644
> --- a/arch/arm/mach-omap2/omap_hwmod.c
> +++ b/arch/arm/mach-omap2/omap_hwmod.c
> @@ -3158,6 +3158,33 @@ int omap_hwmod_fill_resources(struct omap_hwmod *oh,
> struct resource *res)
> }
>
> /**
> + * omap_hwmod_fill_dma_resources - fill struct resource array with dma data
> + * @oh: struct omap_hwmod *
> + * @res: pointer to the array of struct resource to fill
> + *
> + * Fill the struct resource array @res with dma resource data from the
> + * omap_hwmod @oh. Intended to be called by code that registers
> + * omap_devices. See also omap_hwmod_count_resources(). Returns the
> + * number of array elements filled.
> + */
> +int omap_hwmod_fill_dma_resources(struct omap_hwmod *oh, struct resource
> *res)
> +{
> + int i, sdma_reqs_cnt;
> + int r = 0;
> +
> + sdma_reqs_cnt = _count_sdma_reqs(oh);
> + for (i = 0; i < sdma_reqs_cnt; i++) {
> + (res + r)->name = (oh->sdma_reqs + i)->name;
> + (res + r)->start = (oh->sdma_reqs + i)->dma_req;
> + (res + r)->end = (oh->sdma_reqs + i)->dma_req;
> + (res + r)->flags = IORESOURCE_DMA;
> + r++;
> + }
> +
> + return r;
> +}
> +
> +/**
> * omap_hwmod_get_resource_byname - fetch IP block integration data by name
> * @oh: struct omap_hwmod * to operate on
> * @type: one of the IORESOURCE_* constants from include/linux/ioport.h
> diff --git a/arch/arm/plat-omap/include/plat/omap_hwmod.h
> b/arch/arm/plat-omap/include/plat/omap_hwmod.h
> i
RE: [PATCH 1/3] arm: omap: hwmod: add a new addr space in otg for writing to control module
On Thu, Sep 06, 2012 at 22:43:03, Balbi, Felipe wrote:
> Hi,
>
> On Thu, Sep 06, 2012 at 09:04:58PM +0530, Vaibhav Hiremath wrote:
> >
> >
> > On 9/6/2012 8:25 PM, Kishon Vijay Abraham I wrote:
> > > The mailbox register for usb otg in omap is present in control module.
> > > On detection of any events VBUS or ID, this register should be written
> > > to send the notification to musb core.
> > >
> > > Till we have a separate control module driver to write to control module,
> > > omap2430 will handle the register writes to control module by itself. So
> > > a new address space to represent this control module register is added
> > > to usb_otg_hs.
> > >
> > > Cc: Benoit Cousson
> > > Signed-off-by: Kishon Vijay Abraham I
> > > ---
> > > arch/arm/mach-omap2/omap_hwmod_44xx_data.c |5 +
> > > 1 file changed, 5 insertions(+)
> > >
> > > diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> > > b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> > > index 242aee4..02341bc 100644
> > > --- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> > > +++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> > > @@ -5890,6 +5890,11 @@ static struct omap_hwmod_addr_space
> > > omap44xx_usb_otg_hs_addrs[] = {
> > > .pa_end = 0x4a0ab003,
> > > .flags = ADDR_TYPE_RT
> > > },
> > > + {
> > > + .pa_start = 0x4a00233c,
> > > + .pa_end = 0x4a00233f,
> > > + .flags = ADDR_TYPE_RT
> > > + },
> >
> > I do not have any objection/comment here, but I believe this is control
> > module address space required for USB module, right?
> > I am not sure this is right way of accessing control module space.
> > Actually Control Module Access required for drivers is one of the
> > blocking issue we have currently.
> >
> > Also there was some effort put up by 'Konstantine' to convert Control
> > module to MFD driver, I haven't seen any further update on it. But it
> > would be good to check with him.
>
> this was an agreement with Benoit since we already lost a couple merge
> windows for this patchset. We agreed to wait until -rc4 for SCM driver
> and if it wasn't ready, we'd go ahead with this and SCM author would fix
> it up on a patch converting users to new SCM driver.
>
Understood and thanks for confirming.
Thanks,
Vaibhav
> --
> balbi
>
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
RE: [PATCH v2 1/8] ARM/dts: OMAP2: Add McBSP entries for OMAP2420 and OMAP2430 SoC
On Wed, Sep 05, 2012 at 19:01:55, Cousson, Benoit wrote: > Hi Vaibhav, > > On 09/05/2012 11:15 AM, Hiremath, Vaibhav wrote: > > On Wed, Sep 05, 2012 at 13:53:58, Ujfalusi, Peter wrote: > >> Hi, > >> > >> On 09/05/2012 09:11 AM, Hiremath, Vaibhav wrote: > >>>> Not yet, but we discussed that with Peter and since he does have these > >>>> patches for DT, he'll be able to test your series with the McBSP changes. > >>>> > >>> > >>> Great. > >> > >> With his series and your patch for omap-hwmod audio was probing and > >> working on > >> OMAP3/4/5 without issues. > >> > > Peter, > > Care to provide your Tested-By?? > > > > Benoit, > > Can we merge this patch now? > > Yes, I'll include it in the pull request along with DTS patches. > > I've just tested it as well on OMAP4 by hacking the DTS for GPIO. > I'll try to update at least all the OMAP4 IPs as well with the proper > DTS resources for 3.7. > Thanks Benoit, There are other patches which are pending, arm/dts: AM33XX: Convert all hex numbers to lower-case https://patchwork.kernel.org/patch/1377351/ arm/dts: AM33XX: Specify reg and interrupt property for all nodes https://patchwork.kernel.org/patch/1377361/ Probably your Ack is required for, ARM: AM33XX: clock: Add dcan clock aliases for device-tree https://patchwork.kernel.org/patch/1377061/ RTC: I am not sure how to deal with RTC DT support, as I understand the list is very unresponsive there. http://www.mail-archive.com/davinci-linux-open-source@linux.davincidsp.com/msg23253.html Thanks, Vaibhav ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
RE: [PATCH v2 1/8] ARM/dts: OMAP2: Add McBSP entries for OMAP2420 and OMAP2430 SoC
On Wed, Sep 05, 2012 at 13:53:58, Ujfalusi, Peter wrote: > Hi, > > On 09/05/2012 09:11 AM, Hiremath, Vaibhav wrote: > >> Not yet, but we discussed that with Peter and since he does have these > >> patches for DT, he'll be able to test your series with the McBSP changes. > >> > > > > Great. > > With his series and your patch for omap-hwmod audio was probing and working on > OMAP3/4/5 without issues. > Peter, Care to provide your Tested-By?? Benoit, Can we merge this patch now? Thanks, Vaibhav ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
RE: [PATCH v2 1/8] ARM/dts: OMAP2: Add McBSP entries for OMAP2420 and OMAP2430 SoC
On Tue, Sep 04, 2012 at 15:47:59, Cousson, Benoit wrote:
> Hi Vaibhav,
>
> On 09/04/2012 05:42 AM, Vaibhav Hiremath wrote:
> > On 9/3/2012 8:16 PM, Benoit Cousson wrote:
> >> Hi Peter,
> >>
> >> The overall series looks good to me, but I do have a couple of comments.
> >>
> >> On 08/29/2012 03:31 PM, Peter Ujfalusi wrote:
> >>> The McBSP IP within OMAP2420 and 2430 is different we need to create
> >>> separate
> >>> dtsi files for them.
> >>>
> >>> Signed-off-by: Peter Ujfalusi
> >>> ---
> >>> arch/arm/boot/dts/omap2420.dtsi | 39 ++
> >>> arch/arm/boot/dts/omap2430.dtsi | 83
> >>> +++
> >>> 2 files changed, 122 insertions(+), 0 deletions(-)
> >>> create mode 100644 arch/arm/boot/dts/omap2420.dtsi
> >>> create mode 100644 arch/arm/boot/dts/omap2430.dtsi
> >>>
> >>> diff --git a/arch/arm/boot/dts/omap2420.dtsi
> >>> b/arch/arm/boot/dts/omap2420.dtsi
> >>> new file mode 100644
> >>> index 000..f375c68
> >>> --- /dev/null
> >>> +++ b/arch/arm/boot/dts/omap2420.dtsi
> >>> @@ -0,0 +1,39 @@
> >>> +/*
> >>> + * Device Tree Source for OMAP2420 SoC
> >>> + *
> >>> + * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com/
> >>
> >> Nit: 2012
> >>
> >>> + *
> >>> + * This file is licensed under the terms of the GNU General Public
> >>> License
> >>> + * version 2. This program is licensed "as is" without any warranty of
> >>> any
> >>> + * kind, whether express or implied.
> >>> + */
> >>> +
> >>> +/include/ "omap2.dtsi"
> >>> +
> >>> +/ {
> >>> + compatible = "ti,omap2420", "ti,omap2";
> >>> +
> >>> + ocp {
> >>> + mcbsp1: mcbsp@48074000 {
> >>> + compatible = "ti,omap2420-mcbsp";
> >>> + reg = <0x48074000 0xff>;
> >>> + reg-names = "mpu";
> >>> + interrupts = <0 59 0x4>, /* TX interrupt */
> >>> + <0 60 0x4>; /* RX interrupt */
> >>
> >> That one is not correct because it does comply with the interrupt
> >> controller specifier that require only one cell:
> >>
> >>intc: interrupt-controller@4820 {
> >>compatible = "ti,omap2-intc";
> >>interrupt-controller;
> >>#interrupt-cells = <1>;
> >> ...
> >>
> >> The one you are using is for GIC IRQ controller.
> >> It works probably because we are using hwmod so far :-)
> >>
> >
> > I think now we should kill the resource overwrite path, and should
> > respect and use resources passed from DT.
> >
> > Benoit,
> > Did you get a chance to validate patch submitted towards this??
>
> Not yet, but we discussed that with Peter and since he does have these
> patches for DT, he'll be able to test your series with the McBSP changes.
>
Great.
> I still want to update a couple of DTS to test that on some other IPs.
>
Ohh ok. Please let me know if I can help you here by any means.
I am equipped with AM37xEVM, BeagleBoard and Panda.
Thanks,
Vaibhav
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
RE: [PATCH 0/3] gpio-twl4030: add new device tree properties
On Mon, Sep 03, 2012 at 19:58:09, Cousson, Benoit wrote: > + Vaibhav for the omap3-evm > Reviewing and testing it now... Thanks, Vaibhav > Hi Florian, > > On 09/03/2012 03:54 PM, Florian Vaussard wrote: > > A number of platform data are missing when using twl4030/gpio from a > > device tree. > > Yeah, I know, I was too lazy when I did the DT conversion at that time :-) > > Many thanks for completing the work. > > > This patchset adds the missing properties, updates > > existing device trees and updates the documentation of bindings. > > It mainly enables LEDA and LEDB outputs, as well as pullups / > > pulldowns on GPIOs. > > > > The 1st patch changes the device driver. > > The 2nd patch updates the device trees for BeagleBoard and omap3-evm. > > The 3rd patch updates the documentation of bindings. > > OK, that's a nit, but in general, you'd better introduce the binding > before using it. > > The binding documentation could/should be updated along with the driver > change that does introduce the binding. You could just merged patch #1 > and #3. > > > Tested: > > - Boot tested on Gumstix Overo for "ti,use-leds". Corresponding > > patch is not provided, as the device tree is not yet merged. > > The support can be found in the git tree [1], branch > > omap3-devel-dt-overo. > > - Device trees for BeagleBoard and omap3-evm were compiled, but not > > tested on hardware. > > > > Would someone be willing to test on BeagleBoard / omap3-evm? > > I'll try to do it on Beagle. This is the least I can do since I did not > do the job myself :-) > > I added vaibhav as well since I do not have any omap3-evm board. > > > > > Regards, > > Florian > > > > [1] https://github.com/vaussard/linux.git (not safe for merge) > > > > > > Florian Vaussard (3): > > gpio-twl4030: get platform data from device tree > > gpio-twl4030: new dt properties for BeagleBoard and omap3-EVM > > Nit #2: the DTS file does not belong to the gpio subsystem. So you > should prefix them using the *convention* for ARM DTS patches: > > arm/dts: omap3: Add gpio-twl4030 properties for BeagleBoard and omap3-EVM > > Or maybe "ARM: dts: " because it looks like most people are using that > nowadays. > > The convention for the gpio directory is similar: > gpio/twl4030: get platform data from device tree > > > gpio-twl4030: updates the bindings for new dt properties > > > > .../devicetree/bindings/gpio/gpio-twl4030.txt |6 ++ > > arch/arm/boot/dts/omap3-beagle.dts | 20 + > > arch/arm/boot/dts/omap3-evm.dts| 13 +++ > > drivers/gpio/gpio-twl4030.c| 86 > > +-- > > 4 files changed, 98 insertions(+), 27 deletions(-) > > Thanks, > Benoit > > ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
RE: [RFC PATCH] ARM: OMAP2+: omap-device: Do not overwrite resources allocated by OF layer
On Fri, Aug 31, 2012 at 20:54:53, Cousson, Benoit wrote:
> Hi Vaibhav,
>
> On 08/29/2012 11:48 AM, Vaibhav Hiremath wrote:
> > With the new devices (like, AM33XX and OMAP5) we now only support
> > DT boot mode of operation and now it is the time to start killing
> > slowly the dependency on hwmod, so with this patch, we are starting
> > with device resources.
>
> Thanks for working on that.
>
> > The idea here is implemented considering to both boot modes -
> > - DT boot mode
> > OF framework will construct the resource structure (currently
> > does for MEM & IRQ resource) and we should respect/use these
> > resources, killing hwmod dependency.
> > If pdev->num_resources > 0, we assume that MEM & IRQ resources
> > have been allocated by OF layer already (through DTB).
> >
> > Once DMA resource is available from OF layer, we should
> > kill filling any resources from hwmod.
>
> Yeap, I did a similar patch some months ago and decided to drop it
> because I was expected the DMA binding to be there and wanted to avoid
> adding more code that we are going to remove later.
>
> The other potential issue is that when the binding will be there, we
> will have to update all the drivers and DTS first before being able to
> change the hwmod code from hwmod DMA to DTS DMA.
> I was thinking of something smoother that will check if DMA is in DTS
> and fall back to hwmod if not to avoid that.
> But again, I'm not sure it worth the effort.
>
> > - Non-DT boot mode
> > Here, pdev->num_resources = 0, and we should get all the
> > resources from hwmod (following existing steps)
> >
> > Signed-off-by: Vaibhav Hiremath
> > Cc: Benoit Cousson
> > Cc: Tony Lindgren
> > Cc: Paul Walmsley
> > Cc: Kevin Hilman
> > ---
> > This patch is tested on BeagleBone and AM37xEVM.
>
> I'll try to do more testing on Panda next week.
>
Thanks a lot.
> > Why RFC?
> > Still we have function duplication omap_device_fill_resources() and
> > omap_device_fill_dma_resources(), we can actually split the function
> > into 3 resources and avoid duplication -
> > - omap_device_fill_dma_resources()
> > - omap_device_fill_mem_resources()
> > - omap_device_fill_irq_resources()
> >
> > Actually I wanted to clean it further but thought of getting
> > feedback first and then proceed further.
>
> Well, that's anyway temporary code that should be gone in 6 months from
> now (ideally). So that looks pretty good to me.
>
> > arch/arm/mach-omap2/omap_hwmod.c | 27 ++
> > arch/arm/plat-omap/include/plat/omap_hwmod.h |1 +
> > arch/arm/plat-omap/omap_device.c | 72
> > +
> > 3 files changed, 88 insertions(+), 12 deletions(-)
> >
> > diff --git a/arch/arm/mach-omap2/omap_hwmod.c
> > b/arch/arm/mach-omap2/omap_hwmod.c
> > index 31ec283..edabfb3 100644
> > --- a/arch/arm/mach-omap2/omap_hwmod.c
> > +++ b/arch/arm/mach-omap2/omap_hwmod.c
> > @@ -3330,6 +3330,33 @@ int omap_hwmod_fill_resources(struct omap_hwmod *oh,
> > struct resource *res)
> > }
> >
> > /**
> > + * omap_hwmod_fill_dma_resources - fill struct resource array with dma data
> > + * @oh: struct omap_hwmod *
> > + * @res: pointer to the array of struct resource to fill
> > + *
> > + * Fill the struct resource array @res with dma resource data from the
> > + * omap_hwmod @oh. Intended to be called by code that registers
> > + * omap_devices. See also omap_hwmod_count_resources(). Returns the
> > + * number of array elements filled.
> > + */
> > +int omap_hwmod_fill_dma_resources(struct omap_hwmod *oh, struct resource
> > *res)
> > +{
> > + int i, sdma_reqs_cnt;
> > + int r = 0;
> > +
> > + sdma_reqs_cnt = _count_sdma_reqs(oh);
> > + for (i = 0; i < sdma_reqs_cnt; i++) {
> > + (res + r)->name = (oh->sdma_reqs + i)->name;
> > + (res + r)->start = (oh->sdma_reqs + i)->dma_req;
> > + (res + r)->end = (oh->sdma_reqs + i)->dma_req;
> > + (res + r)->flags = IORESOURCE_DMA;
> > + r++;
> > + }
> > +
> > + return r;
> > +}
> > +
> > +/**
> > * omap_hwmod_get_resource_byname - fetch IP block integration data by name
> > * @oh: struct omap_hwmod * to operate on
> > * @type: one of the IORESOURCE_* constants from include/linux/ioport.h
> > diff --git a/arch/arm/plat-omap/include/plat/omap_hwmod.h
> > b/arch/arm/plat-omap/include/plat/omap_hwmod.h
> > index 9b9646c..0533073 100644
> > --- a/arch/arm/plat-omap/include/plat/omap_hwmod.h
> > +++ b/arch/arm/plat-omap/include/plat/omap_hwmod.h
> > @@ -615,6 +615,7 @@ int omap_hwmod_softreset(struct omap_hwmod *oh);
> >
> > int omap_hwmod_count_resources(struct omap_hwmod *oh);
> > int omap_hwmod_fill_resources(struct omap_hwmod *oh, struct resource *res);
> > +int omap_hwmod_fill_dma_resources(struct omap_hwmod *oh, struct resource
> > *res);
> > int omap_hwmod_get_resource_byname(struct omap_hwmod *oh, unsigned int
> > type,
> >const
RE: [PATCH] ARM: AM33XX: clock: Add dcan clock aliases for device-tree
On Tue, Aug 28, 2012 at 00:06:45, Paul Walmsley wrote: > On Mon, 27 Aug 2012, Hiremath, Vaibhav wrote: > > > On Mon, Aug 27, 2012 at 22:50:12, Paul Walmsley wrote: > > > > > Is the dcan driver present in v3.6-rc kernels? > > > > Multiple versions have been submitted already, I have validated using them. > > Irrespective of this, it is independent change and required for the driver. > > OK, will queue it for 3.7. > Thanks Paul. Thanks, Vaibhav ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
RE: [PATCH] ARM: AM33XX: clock: Add dcan clock aliases for device-tree
On Mon, Aug 27, 2012 at 22:50:12, Paul Walmsley wrote: > Hi > > On Mon, 27 Aug 2012, Vaibhav Hiremath wrote: > > > Currently, the device names for the dcan module follows the > > format "dcan.X", where 'X' is the dcan instance number. > > On other side, driver may request for clock with/without con_id > > and dev_id, and it is expected that platform should respect this > > request and return the requested clock handle. > > > > Now, when using device tree, the format of the device name created > > by OF layer is different, ".", > > assuming that the device-tree "reg" property is specified. > > This causes the look-up failure for clock node in dcan driver > > > > To fix this add new dcan clock alias for using device-tree. > > Is the dcan driver present in v3.6-rc kernels? Multiple versions have been submitted already, I have validated using them. Irrespective of this, it is independent change and required for the driver. Thanks, Vaibhav ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
RE: [RFC RESEND 2/4] ARM: OMAP3: Dynamically disable secure timer nodes for secure devices
On Fri, Aug 17, 2012 at 17:54:09, Hunter, Jon wrote:
>
> On 08/17/2012 12:32 AM, Hiremath, Vaibhav wrote:
> > On Thu, Aug 16, 2012 at 22:27:42, Hunter, Jon wrote:
> >>
> >> On 08/15/2012 04:13 AM, Vaibhav Hiremath wrote:
> >>>
> >>>
> >>> On 7/14/2012 3:56 AM, Jon Hunter wrote:
> >>>> OMAP3 devices may or may not have security features enabled. Security
> >>>> enabled
> >>>> devices are known as high-secure (HS) and devices without security are
> >>>> known as
> >>>> general purpose (GP).
> >>>>
> >>>> For OMAP3 devices there are 12 general purpose timers available. On
> >>>> secure
> >>>> devices the 12th timer is reserved for secure usage and so cannot be
> >>>> used by
> >>>> the kernel, where as for a GP device it is available. We can detect the
> >>>> OMAP
> >>>> device type, secure or GP, at runtime via an on-chip register. Today,
> >>>> when not
> >>>> using DT, we do not register the 12th timer as a linux device if the
> >>>> device is
> >>>> secure.
> >>>>
> >>>> When using device tree, device tree is going to register all the timer
> >>>> devices
> >>>> it finds in the device tree blob. To prevent device tree from
> >>>> registering 12th
> >>>> timer on a secure OMAP3 device we can add a status property to the timer
> >>>> binding with the value "disabled" at boot time. Note that timer 12 on a
> >>>> OMAP3
> >>>> device has a property "ti,timer-secure" to indicate that it will not be
> >>>> available on a secure device and so for secure OMAP3 devices, we search
> >>>> for
> >>>> timers with this property and then disable them. Using the
> >>>> prom_add_property()
> >>>> function to dynamically add a property was a recommended approach
> >>>> suggested by
> >>>> Rob Herring [1].
> >>>>
> >>>> I have tested this on an OMAP3 GP device and faking it to pretend to be a
> >>>> secure device to ensure that any timers marked with "ti,timer-secure"
> >>>> are not
> >>>> registered on boot. I have also made sure that all timers are registered
> >>>> as
> >>>> expected on a GP device by default.
> >>>>
> >>>> [1] http://comments.gmane.org/gmane.linux.ports.arm.omap/79203
> >>>>
> >>>> Signed-off-by: Jon Hunter
> >>>> ---
> >>>> arch/arm/mach-omap2/board-generic.c |1 +
> >>>> arch/arm/mach-omap2/common.h|1 +
> >>>> arch/arm/mach-omap2/timer.c | 36
> >>>> +++
> >>>> 3 files changed, 38 insertions(+)
> >>>>
> >>>> diff --git a/arch/arm/mach-omap2/board-generic.c
> >>>> b/arch/arm/mach-omap2/board-generic.c
> >>>> index 6f93a20..20124d7 100644
> >>>> --- a/arch/arm/mach-omap2/board-generic.c
> >>>> +++ b/arch/arm/mach-omap2/board-generic.c
> >>>> @@ -40,6 +40,7 @@ static struct of_device_id omap_dt_match_table[]
> >>>> __initdata = {
> >>>> static void __init omap_generic_init(void)
> >>>> {
> >>>> omap_sdrc_init(NULL, NULL);
> >>>> +omap_dmtimer_init();
> >>>>
> >>>> of_platform_populate(NULL, omap_dt_match_table, NULL, NULL);
> >>>> }
> >>>> diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
> >>>> index 1f65b18..d6a4875 100644
> >>>> --- a/arch/arm/mach-omap2/common.h
> >>>> +++ b/arch/arm/mach-omap2/common.h
> >>>> @@ -326,6 +326,7 @@ extern void omap_sdrc_init(struct omap_sdrc_params
> >>>> *sdrc_cs0,
> >>>>struct omap_sdrc_params
> >>>> *sdrc_cs1);
> >>>> struct omap2_hsmmc_info;
> >>>> extern int omap4_twl6030_hsmmc_init(struct omap2_hsmmc_info
> >>>> *controllers);
> >>>> +extern void omap_dmtimer_init(void);
> >>>>
> >>>> #endif /* __ASSEMBLER__ */
> >>>> #endif /* __ARCH_ARM_MACH_OMAP2PLUS_COMMON_H */
> >>>> di
RE: [RFC RESEND 2/4] ARM: OMAP3: Dynamically disable secure timer nodes for secure devices
On Thu, Aug 16, 2012 at 22:27:42, Hunter, Jon wrote:
>
> On 08/15/2012 04:13 AM, Vaibhav Hiremath wrote:
> >
> >
> > On 7/14/2012 3:56 AM, Jon Hunter wrote:
> >> OMAP3 devices may or may not have security features enabled. Security
> >> enabled
> >> devices are known as high-secure (HS) and devices without security are
> >> known as
> >> general purpose (GP).
> >>
> >> For OMAP3 devices there are 12 general purpose timers available. On secure
> >> devices the 12th timer is reserved for secure usage and so cannot be used
> >> by
> >> the kernel, where as for a GP device it is available. We can detect the
> >> OMAP
> >> device type, secure or GP, at runtime via an on-chip register. Today, when
> >> not
> >> using DT, we do not register the 12th timer as a linux device if the
> >> device is
> >> secure.
> >>
> >> When using device tree, device tree is going to register all the timer
> >> devices
> >> it finds in the device tree blob. To prevent device tree from registering
> >> 12th
> >> timer on a secure OMAP3 device we can add a status property to the timer
> >> binding with the value "disabled" at boot time. Note that timer 12 on a
> >> OMAP3
> >> device has a property "ti,timer-secure" to indicate that it will not be
> >> available on a secure device and so for secure OMAP3 devices, we search for
> >> timers with this property and then disable them. Using the
> >> prom_add_property()
> >> function to dynamically add a property was a recommended approach
> >> suggested by
> >> Rob Herring [1].
> >>
> >> I have tested this on an OMAP3 GP device and faking it to pretend to be a
> >> secure device to ensure that any timers marked with "ti,timer-secure" are
> >> not
> >> registered on boot. I have also made sure that all timers are registered as
> >> expected on a GP device by default.
> >>
> >> [1] http://comments.gmane.org/gmane.linux.ports.arm.omap/79203
> >>
> >> Signed-off-by: Jon Hunter
> >> ---
> >> arch/arm/mach-omap2/board-generic.c |1 +
> >> arch/arm/mach-omap2/common.h|1 +
> >> arch/arm/mach-omap2/timer.c | 36
> >> +++
> >> 3 files changed, 38 insertions(+)
> >>
> >> diff --git a/arch/arm/mach-omap2/board-generic.c
> >> b/arch/arm/mach-omap2/board-generic.c
> >> index 6f93a20..20124d7 100644
> >> --- a/arch/arm/mach-omap2/board-generic.c
> >> +++ b/arch/arm/mach-omap2/board-generic.c
> >> @@ -40,6 +40,7 @@ static struct of_device_id omap_dt_match_table[]
> >> __initdata = {
> >> static void __init omap_generic_init(void)
> >> {
> >>omap_sdrc_init(NULL, NULL);
> >> + omap_dmtimer_init();
> >>
> >>of_platform_populate(NULL, omap_dt_match_table, NULL, NULL);
> >> }
> >> diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
> >> index 1f65b18..d6a4875 100644
> >> --- a/arch/arm/mach-omap2/common.h
> >> +++ b/arch/arm/mach-omap2/common.h
> >> @@ -326,6 +326,7 @@ extern void omap_sdrc_init(struct omap_sdrc_params
> >> *sdrc_cs0,
> >> struct omap_sdrc_params *sdrc_cs1);
> >> struct omap2_hsmmc_info;
> >> extern int omap4_twl6030_hsmmc_init(struct omap2_hsmmc_info *controllers);
> >> +extern void omap_dmtimer_init(void);
> >>
> >> #endif /* __ASSEMBLER__ */
> >> #endif /* __ARCH_ARM_MACH_OMAP2PLUS_COMMON_H */
> >> diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
> >> index 13d20c8..e3b9931 100644
> >> --- a/arch/arm/mach-omap2/timer.c
> >> +++ b/arch/arm/mach-omap2/timer.c
> >> @@ -36,6 +36,7 @@
> >> #include
> >> #include
> >> #include
> >> +#include
> >>
> >> #include
> >> #include
> >> @@ -482,6 +483,41 @@ static int __init omap2_dm_timer_init(void)
> >> }
> >> arch_initcall(omap2_dm_timer_init);
> >>
> >> +static struct property timer_disabled = {
> >> + .name = "status",
> >> + .length = sizeof("disabled"),
> >> + .value = "disabled",
> >> +};
> >> +
> >> +static struct of_device_id omap3_timer_match[] __initdata = {
> >> + { .compatible = "ti,omap3-timer", },
> >> + { }
> >> +};
> >> +
> >> +/**
> >> + * omap_dmtimer_init - initialisation function when device tree is used
> >> + *
> >> + * For secure OMAP3 devices, timers with device type "timer-secure" cannot
> >> + * be used by the kernel as they are reserved. Therefore, to prevent the
> >> + * kernel registering these devices remove them dynamically from the
> >> device
> >> + * tree on boot.
> >> + */
> >> +void __init omap_dmtimer_init(void)
> >> +{
> >> + struct device_node *np;
> >> +
> >> + if (!cpu_is_omap34xx())
> >> + return;
> >> +
> >
> > Sorry for responding so late, but why only omap34xx check here?
> > Isn't this applicable to all omap & non-omap devices?
>
> It is only applicable to omap3 devices as far as omap is concerned.
>
> By non-omap, you are referring to the AMxxx stuff?
>
> Do AMxxx devices even support security (ie. secure boot and have secure
> peripherals)? If not then this will work for AMxxx devices too.
>
Ye
RE: [PATCH] arm/dts: AM33XX: Set the default status of module to "disabled" state
On Tue, Aug 14, 2012 at 12:25:54, AnilKumar, Chimata wrote:
> Hi Vaibhav,
>
> On Mon, Aug 06, 2012 at 16:59:04, Hiremath, Vaibhav wrote:
> > Ideally in common SoC dtsi file we should set all modules
> > to "disabled" state and it should get enabled in respective
> > EVM/Board dts file as per usage.
> >
> > This patch sets default status of all modules to "disabled"
> > state in am33xx.dtsi file, and as per board requirement, enabled
> > in board dts file (like, bone, evm, etc...).
> >
> > Signed-off-by: Vaibhav Hiremath
> > Cc: Benoit Cousson
> > Cc: Grant Likely
> > Cc: Arnd Bergmann
> > CC: Tony Lindgren
> > ---
> > This patch is tested on BeagleBone platform.
> >
> > arch/arm/boot/dts/am335x-bone.dts |6 ++
> > arch/arm/boot/dts/am335x-evm.dts |6 ++
> > arch/arm/boot/dts/am33xx.dtsi |9 +
> > 3 files changed, 21 insertions(+), 0 deletions(-)
> >
> > diff --git a/arch/arm/boot/dts/am335x-bone.dts
> > b/arch/arm/boot/dts/am335x-bone.dts
> > index a9af4db..df672b4 100644
> > --- a/arch/arm/boot/dts/am335x-bone.dts
> > +++ b/arch/arm/boot/dts/am335x-bone.dts
> > @@ -17,4 +17,10 @@
> > device_type = "memory";
> > reg = <0x8000 0x1000>; /* 256 MB */
> > };
> > +
> > + ocp {
> > + uart1: serial@44E09000 {
> > + status = "okay";
> > + };
>
> Minor change, correct indentation here.
>
Thanks Anil for pointing me to this, my vi rules screwed up here,
I will correct it and send next version with Ack-by Arnd.
Thanks,
Vaibhav
> > + };
> > };
> > diff --git a/arch/arm/boot/dts/am335x-evm.dts
> > b/arch/arm/boot/dts/am335x-evm.dts
> > index d6a97d9..00bbae8 100644
> > --- a/arch/arm/boot/dts/am335x-evm.dts
> > +++ b/arch/arm/boot/dts/am335x-evm.dts
> > @@ -17,4 +17,10 @@
> > device_type = "memory";
> > reg = <0x8000 0x1000>; /* 256 MB */
> > };
> > +
> > + ocp {
> > + uart1: serial@44E09000 {
> > + status = "okay";
> > + };
>
> ditto
>
> Regards
> AnilKumar
>
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
RE: [PATCH v4 3/3] can: c_can: Add runtime PM support to Bosch C_CAN/D_CAN controller
On Sat, Aug 04, 2012 at 00:39:25, Marc Kleine-Budde wrote: > On 08/03/2012 08:32 AM, Hiremath, Vaibhav wrote: > > On Thu, Aug 02, 2012 at 18:43:11, AnilKumar, Chimata wrote: > >> Add Runtime PM support to C_CAN/D_CAN controller. The runtime PM > >> APIs control clocks for C_CAN/D_CAN IP and prevent access to the > >> register of C_CAN/D_CAN IP when clock is turned off. > >> > >> Signed-off-by: AnilKumar Ch > >> --- > >> drivers/net/can/c_can/c_can_platform.c |8 > >> 1 file changed, 8 insertions(+) > >> > >> diff --git a/drivers/net/can/c_can/c_can_platform.c > >> b/drivers/net/can/c_can/c_can_platform.c > >> index d0a66cf..83a1e17 100644 > >> --- a/drivers/net/can/c_can/c_can_platform.c > >> +++ b/drivers/net/can/c_can/c_can_platform.c > >> @@ -32,6 +32,7 @@ > >> #include > >> #include > >> #include > >> +#include > >> > >> #include > >> > >> @@ -177,6 +178,9 @@ static int __devinit c_can_plat_probe(struct > >> platform_device *pdev) > >>goto exit_free_device; > >>} > >> > >> + pm_runtime_enable(&pdev->dev); > >> + pm_runtime_get_sync(&pdev->dev); > >> + > > > > If module is inserted or built into the kernel, module stays in enabled > > state always, isn't that wrong? > > Ideally, you should enable the module when it is required or being used. > > Good point. > > If you don't access the module's registers in the probe- (or its > subroutines) it should be enough to enable the module in the open() > function. Have a look at clk_prepare_enable / clk_disable_unprepare in > the flexcan driver. > Yeah Marc, something similar, above runtime pm api's should be moved to open-n-close. Thanks, Vaibhav > Marc > > -- > Pengutronix e.K. | Marc Kleine-Budde | > Industrial Linux Solutions| Phone: +49-231-2826-924 | > Vertretung West/Dortmund | Fax: +49-5121-206917- | > Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de | > > ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
RE: [PATCH v7 00/11] usb: musb: adding multi instance support
On Mon, Aug 06, 2012 at 01:22:53, Daniel Mack wrote: > On 03.08.2012 17:48, Hiremath, Vaibhav wrote: > > On Fri, Aug 03, 2012 at 17:11:38, Daniel Mack wrote: > >> On 03.08.2012 11:07, Hiremath, Vaibhav wrote: > >>> I have just pushed the code (V7 which Ravi submitted), so can you please > >>> try > >>> with below branch? > >>> > >>> https://github.com/hvaibhav/am335x-linux/tree/am335x-upstream-staging-usb > >> > >> Thanks for doing this, but I'm unfortunately getting tons of merge > >> conflicts when I try to put this on top of 3.6-rc1. Still pondering > >> which way around is the easiest to get this solved. > >> > >> OTOH, I wonder whether your staging branches would need to rebased > >> sooner or later anyway? > >> > > > > I have already pushed branch based on v3.6-rc1 (boot tested), > > > > https://github.com/hvaibhav/am335x-linux/tree/am335x-linux-next-master > > Sorry, I don't get it yet. Your am335x-linux-next-master can be merged > into v3.6-rc1 without problems, but it doesn't contain Ravi's patches. > And am335x-upstream-staging-usb doesn't apply on top of either > am335x-linux-next-master or v3.6-rc1. > > Maybe I just miss a detail here. Could you again explain which branch > will you publish for merging in the 3.7 merge window, and what are its > dependencies? > Daniel, Every developer is supposed to submit the patches on top of their maintainer's repository, which may or may not be in-sync with latest linux- next or Linus's tree at given time OR their could be some extra dependency from framework. For example, linux-omap is still not updated to v3.6-rc1, but I have to use linux-omap/master for all patch submissions. It becomes extra work for each developers to maintain branch for both, one against their maintainer HEAD and one against linux-next/master. So I am just pushing the branch which is being tested/validated (on BeagleBone) before submitting patches to the list. I hope this clarifies all your confusion. Thanks, Vaibhav > > Thanks for your work, > Daniel > ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
RE: [PATCH v7 00/11] usb: musb: adding multi instance support
On Fri, Aug 03, 2012 at 17:11:38, Daniel Mack wrote: > On 03.08.2012 11:07, Hiremath, Vaibhav wrote: > > I have just pushed the code (V7 which Ravi submitted), so can you please > > try > > with below branch? > > > > https://github.com/hvaibhav/am335x-linux/tree/am335x-upstream-staging-usb > > Thanks for doing this, but I'm unfortunately getting tons of merge > conflicts when I try to put this on top of 3.6-rc1. Still pondering > which way around is the easiest to get this solved. > > OTOH, I wonder whether your staging branches would need to rebased > sooner or later anyway? > I have already pushed branch based on v3.6-rc1 (boot tested), https://github.com/hvaibhav/am335x-linux/tree/am335x-linux-next-master Thanks, Vaibhav ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
RE: am33xx: default to status = "disabled"?
On Fri, Aug 03, 2012 at 04:58:16, Arnd Bergmann wrote: > On Thursday 02 August 2012, Daniel Mack wrote: > > currently, all devices in arch/arm/boot/dts/am33xx.dtsi are enabled by > > default. However, depending on the actual board dts, only some of the > > devices should actually be initialized, given that they only make sense > > if their pins are actually wired on the board. > > > > On other platform, such devices are marked with status = "disabled", and > > the board files re-enable those they really use by overriding that > > status again. That approach seems to make sense - shouldn't the same be > > done in am33xx.dtsi or am I missing something? > > I agree, they should be disabled, at least the serial ports, and probably > also the i2c controllers. > You are right, it needs to be disabled. I will create a patch and submit it. Thanks, Vaibhav ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
RE: [PATCH v7 00/11] usb: musb: adding multi instance support
On Fri, Aug 03, 2012 at 14:32:35, Daniel Mack wrote: > On 03.08.2012 10:43, Ajay Gupta wrote: > >> On 03.08.2012 02:54, B, Ravi wrote: > On 02.08.2012 14:12, Ravi Babu wrote: > > >> However, I needed to add a phandle "usb0-phy = <&usb0_phy>" to the > >> usb_otg_hs DTSI block, otherwise devm_usb_get_phy_by_phandle() in > >> drivers/usb/musb/musb_dsps.c would fail. Is that correct? I can't seem to > >> find that in your patches. > > > > It's getting done in patch 11/11. > > Ah, ok. > > >> With this addition, I see the following: > >> > >> [1.782180] musb-hdrc: version 6.0, ?dma?, otg (peripheral+host) > >> [1.809966] musb-hdrc musb-hdrc.0: MUSB HDRC host driver > >> [1.819068] musb-hdrc musb-hdrc.0: new USB bus registered, assigned > >> bus number 1 > >> [1.827970] usb usb1: New USB device found, idVendor=1d6b, > >> idProduct=0002 > >> [1.835184] usb usb1: New USB device strings: Mfr=3, Product=2, > >> SerialNumber=1 > >> [1.842818] usb usb1: Product: MUSB HDRC host driver > >> [1.848031] usb usb1: Manufacturer: Linux > >> 3.6.0-rc1-00038-g8a1ec8f-dirty musb-hcd > >> [1.855933] usb usb1: SerialNumber: musb-hdrc.0 > >> [1.866913] hub 1-0:1.0: USB hub found > >> [1.871192] hub 1-0:1.0: 1 port detected > >> [1.878106] musb-hdrc musb-hdrc.0: USB Host mode controller at > >> d08c using PIO, IRQ 18 > >> > >> ... but no USB functions. Also, every two seconds, the following message is > >> printed: > >> > >> [ 11.036608] musb_bus_suspend 2308: trying to suspend as a_wait_vrise > >> while active > >> [ 13.044811] musb_bus_suspend 2308: trying to suspend as a_wait_vrise > >> while active > >> [ 15.052196] musb_bus_suspend 2308: trying to suspend as a_wait_vrise > >> while active > > > > Do you see them even when you connect a device to port? > > Yes. Will investigate more later today. Just wanted to know whether this > is a typical config problem. > Daniel I have just pushed the code (V7 which Ravi submitted), so can you please try with below branch? https://github.com/hvaibhav/am335x-linux/tree/am335x-upstream-staging-usb Thanks, Vaibhav ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
RE: [PATCH v4 3/3] can: c_can: Add runtime PM support to Bosch C_CAN/D_CAN controller
On Thu, Aug 02, 2012 at 18:43:11, AnilKumar, Chimata wrote: > Add Runtime PM support to C_CAN/D_CAN controller. The runtime PM > APIs control clocks for C_CAN/D_CAN IP and prevent access to the > register of C_CAN/D_CAN IP when clock is turned off. > > Signed-off-by: AnilKumar Ch > --- > drivers/net/can/c_can/c_can_platform.c |8 > 1 file changed, 8 insertions(+) > > diff --git a/drivers/net/can/c_can/c_can_platform.c > b/drivers/net/can/c_can/c_can_platform.c > index d0a66cf..83a1e17 100644 > --- a/drivers/net/can/c_can/c_can_platform.c > +++ b/drivers/net/can/c_can/c_can_platform.c > @@ -32,6 +32,7 @@ > #include > #include > #include > +#include > > #include > > @@ -177,6 +178,9 @@ static int __devinit c_can_plat_probe(struct > platform_device *pdev) > goto exit_free_device; > } > > + pm_runtime_enable(&pdev->dev); > + pm_runtime_get_sync(&pdev->dev); > + If module is inserted or built into the kernel, module stays in enabled state always, isn't that wrong? Ideally, you should enable the module when it is required or being used. Thanks, Vaibhav ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
RE: [PATCH 1/2] net: davinci_mdio: enable and disable clock
On Fri, Aug 03, 2012 at 10:52:40, Daniel Mack wrote:
> On 03.08.2012 07:16, Vaibhav Hiremath wrote:
> >
> >
> > On 8/3/2012 1:13 AM, Daniel Mack wrote:
> >> Make the driver control the device clocks. Appearantly, the Davinci
> >> platform probes this driver with the clock all powered up, but on OMAP,
> >> this isn't the case.
> >>
> >> Signed-off-by: Daniel Mack
> >> ---
> >> drivers/net/ethernet/ti/davinci_mdio.c | 16 ++--
> >> 1 file changed, 14 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/drivers/net/ethernet/ti/davinci_mdio.c
> >> b/drivers/net/ethernet/ti/davinci_mdio.c
> >> index cd7ee20..b4b6015 100644
> >> --- a/drivers/net/ethernet/ti/davinci_mdio.c
> >> +++ b/drivers/net/ethernet/ti/davinci_mdio.c
> >> @@ -332,6 +332,8 @@ static int __devinit davinci_mdio_probe(struct
> >> platform_device *pdev)
> >>goto bail_out;
> >>}
> >>
> >> + clk_enable(data->clk);
> >> +
> >>dev_set_drvdata(dev, data);
> >>data->dev = dev;
> >>spin_lock_init(&data->lock);
> >> @@ -379,8 +381,11 @@ bail_out:
> >>if (data->bus)
> >>mdiobus_free(data->bus);
> >>
> >> - if (data->clk)
> >> + if (data->clk) {
> >> + clk_disable(data->clk);
> >>clk_put(data->clk);
> >> + }
> >> +
> >>pm_runtime_put_sync(&pdev->dev);
> >>pm_runtime_disable(&pdev->dev);
> >>
> >> @@ -397,8 +402,11 @@ static int __devexit davinci_mdio_remove(struct
> >> platform_device *pdev)
> >>if (data->bus)
> >>mdiobus_free(data->bus);
> >>
> >> - if (data->clk)
> >> + if (data->clk) {
> >> + clk_disable(data->clk);
> >>clk_put(data->clk);
> >> + }
> >> +
> >>pm_runtime_put_sync(&pdev->dev);
> >>pm_runtime_disable(&pdev->dev);
> >>
> >> @@ -427,6 +435,8 @@ static int davinci_mdio_suspend(struct device *dev)
> >>data->suspended = true;
> >>spin_unlock(&data->lock);
> >>
> >> + clk_disable(data->clk);
> >> +
> >>return 0;
> >> }
> >>
> >> @@ -435,6 +445,8 @@ static int davinci_mdio_resume(struct device *dev)
> >>struct davinci_mdio_data *data = dev_get_drvdata(dev);
> >>u32 ctrl;
> >>
> >> + clk_enable(data->clk);
> >> +
> >
> > Danial,
> >
> > I would request you to wait for this, its not that simple and straight.
> > And once you migrate to runtime PM you don't need clk_enable/disable,
> > this should get handled under runtime PM api's.
>
> As I said, it can be dropped.
>
> > Also have you read my another email post -
> >
> > http://comments.gmane.org/gmane.linux.ports.arm.omap/80796
> >
> > Certainly, with respect to CPSW & MDIO, this patch is not enough and
> > requires further investigation. I have started looking at this and
> > hopefully will have some solution soon...
>
> Ok, no problem. We certainly need the DT bindings for davinci_mdio. With
> that applied, and the hwmod added (in the patch I posted yesterday), I
> can at least mount the rootfs via NFS, which is all I currently need.
>
>
I certainly understand your requirement here.
Actually this is not the only device we have, the same issue is applicable
to PWM subsystem available in AM335x. Hopefully I should have something soon
on this.
Thanks,
Vaibhav
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
RE: [PATCH-V1] arm/dts: Add support for TI OMAP3 EVM board
On Thu, Mar 01, 2012 at 04:09:27, Cousson, Benoit wrote: > On 2/29/2012 11:31 PM, Tony Lindgren wrote: > > * Hiremath, Vaibhav [120105 02:46]: > ... > >> Can this merged? OR anybody has any comments here? > > > > For reference, looks like this one is queued up as > > commit f0e15e2b0c6b3e89daade25a1e9a2d80136c14c3. > > Yes, it is, I included it in my DTS pull-request because it was the only > one with Grant's ack. > > I have the whole series ready to be pulled but was waiting for DT > maintainers acked-by. > > I still have these four ones in my branch. > > d5c9442 arm/dts: Add support for TI AM3517/05 EVM board > 3b5fa9a arm/dts: omap3-evm: Add i2c and twl4030 support > 7f4ca5f arm/dts: Add support for TI AM335x EVM board > d0c3aca ARM: OMAP2+: board-generic: Add DT support for AM33xx devices > > In fact the board one already has the proper ack, only the DTS are > missing it. > Ping to Grant !!! Thanks, Vaibhav > Regards, > Benoit > ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
RE: [PATCH 2/2] arm/dts: Add support for TI AM335x EVM board
On Wed, Jan 18, 2012 at 12:43:59, Hiremath, Vaibhav wrote:
> Add AM335x EVM DTS file to use the omap3.dtsi SoC file,
> along with memory node and i2c information.
>
> Signed-off-by: Vaibhav Hiremath
> Cc: Benoit Cousson
> Cc: Grant Likely
> Cc: Tony Lindgren
> ---
> arch/arm/boot/dts/am335x-evm.dts | 39
> ++
> 1 files changed, 39 insertions(+), 0 deletions(-)
> create mode 100644 arch/arm/boot/dts/am335x-evm.dts
>
> diff --git a/arch/arm/boot/dts/am335x-evm.dts
> b/arch/arm/boot/dts/am335x-evm.dts
> new file mode 100644
> index 000..8cc877f
> --- /dev/null
> +++ b/arch/arm/boot/dts/am335x-evm.dts
> @@ -0,0 +1,39 @@
> +/*
> + * Copyright (C) 2011 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.
> + */
> +/dts-v1/;
> +
> +/include/ "omap3.dtsi"
> +
> +/ {
> + model = "TI AM335x EVM";
> + compatible = "ti,am335x-evm", "ti,am33xx", "ti,omap3";
> +
> + memory {
> + device_type = "memory";
> + reg = <0x8000 0x1000>; /* 256 MB */
> + };
> +};
> +
> +&intc {
> + /*
> + * AM33XX family of devices have 128 interrupts
> + */
> + ti,intc-size = <128>;
> +};
> +
> +&i2c1 {
> + clock-frequency = <40>;
> +};
> +
> +&i2c2 {
> + clock-frequency = <40>;
> +};
> +
> +&i2c3 {
> + clock-frequency = <40>;
> +};
Grant,
If there are not review comments, can you also ack this patch as well?
Thanks,
Vaibhav
> --
> 1.7.0.4
>
>
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
RE: [PATCH-V2] arm/dts: omap3-evm: Add i2c and twl4030 support
On Wed, Feb 01, 2012 at 11:56:08, Hiremath, Vaibhav wrote:
> Add support for TWL4030, which is interfaced on i2c1 bus.
> Also add clock frequencies for other i2c instances(2 & 3)
> required for client-device exist on OMAP3EVM board.
>
> Signed-off-by: Vaibhav Hiremath
> Cc: Benoit Cousson
> Cc: Grant Likely
> Cc: Tony Lindgren
> ---
> Changes from V1:
> - As per comment from Benoit, changed hex representation
> from uppercase to lowercase.
>
> arch/arm/boot/dts/omap3-evm.dts | 28
> 1 files changed, 28 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/boot/dts/omap3-evm.dts b/arch/arm/boot/dts/omap3-evm.dts
> index 2eee16e..f349ee9 100644
> --- a/arch/arm/boot/dts/omap3-evm.dts
> +++ b/arch/arm/boot/dts/omap3-evm.dts
> @@ -18,3 +18,31 @@
> reg = <0x8000 0x1000>; /* 256 MB */
> };
> };
> +
> +&i2c1 {
> + clock-frequency = <260>;
> +
> + twl: twl@48 {
> + reg = <0x48>;
> + interrupts = <7>; /* SYS_NIRQ cascaded to intc */
> + interrupt-parent = <&intc>;
> + };
> +};
> +
> +/include/ "twl4030.dtsi"
> +
> +&i2c2 {
> + clock-frequency = <40>;
> +};
> +
> +&i2c3 {
> + clock-frequency = <40>;
> +
> + /*
> + * TVP5146 Video decoder-in for analog input support.
> + */
> + tvp5146@5c {
> + compatible = "ti,tvp5146m2";
> + reg = <0x5c>;
> + };
> +};
Grant,
Can you ack this patch and below patch as well, so that
Benoit can queue it in his tree?
arm/dts: Add support for TI AM3517/05 EVM board
Thanks,
Vaibhav
> --
> 1.7.0.4
>
>
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
RE: [PATCH] arm/dts: OMAP3: Add omap3evm and am335xevm support
On Thu, Feb 02, 2012 at 10:26:29, Grant Likely wrote: > On Wed, Feb 01, 2012 at 11:57:00AM +0530, Vaibhav Hiremath wrote: > > TI's OMAP3EVM and AM335xEVM are software development boards > > available for OMAP35x(AM/DM37x) and AM335x devices respectively; > > and these devices are considered under omap3 family. > > > > Signed-off-by: Vaibhav Hiremath > > Cc: Benoit Cousson > > Cc: Grant Likely > > Cc: Tony Lindgren > > Applied, thanks. > Benoit and/or Grant, Can you also pull-in/merge all other patches which I had submitted recently? arm/dts: omap3-evm: Add i2c and twl4030 support arm/dts: Add support for TI AM3517/05 EVM board arm:omap2:board-generic: Add DT support for AM33xx devices arm/dts: Add support for TI AM335x EVM board Thanks, Vaibhav > g. > > > --- > > .../devicetree/bindings/arm/omap/omap.txt |6 ++ > > 1 files changed, 6 insertions(+), 0 deletions(-) > > > > diff --git a/Documentation/devicetree/bindings/arm/omap/omap.txt > > b/Documentation/devicetree/bindings/arm/omap/omap.txt > > index dbdab40..ce78498 100644 > > --- a/Documentation/devicetree/bindings/arm/omap/omap.txt > > +++ b/Documentation/devicetree/bindings/arm/omap/omap.txt > > @@ -41,3 +41,9 @@ Boards: > > > > - OMAP4 PandaBoard : Low cost community board > >compatible = "ti,omap4-panda", "ti,omap4430" > > + > > +- OMAP3 EVM : Software Developement Board for OMAP35x, AM/DM37x > > + compatible = "ti,omap3-evm", "ti,omap3" > > + > > +- AM335X EVM : Software Developement Board for AM335x > > + compatible = "ti,am335x-evm", "ti,am33xx", "ti,omap3" > > -- > > 1.7.0.4 > > > > > > ___ > > linux-arm-kernel mailing list > > linux-arm-ker...@lists.infradead.org > > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel > ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
RE: [PATCH] arm/dts: omap3-evm: Add i2c and twl4030 support
On Wed, Jan 18, 2012 at 12:25:39, Hiremath, Vaibhav wrote:
> Add support for TWL4030, which is interfaced on i2c1 bus.
> Also add clock frequencies for other i2c instances(2 & 3)
> required for client-device exist on OMAP3EVM board.
>
> Signed-off-by: Vaibhav Hiremath
> Cc: Benoit Cousson
> Cc: Grant Likely
> Cc: Tony Lindgren
> ---
> arch/arm/boot/dts/omap3-evm.dts | 28
> 1 files changed, 28 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/boot/dts/omap3-evm.dts b/arch/arm/boot/dts/omap3-evm.dts
> index 2eee16e..530bdc0 100644
> --- a/arch/arm/boot/dts/omap3-evm.dts
> +++ b/arch/arm/boot/dts/omap3-evm.dts
> @@ -18,3 +18,31 @@
> reg = <0x8000 0x1000>; /* 256 MB */
> };
> };
> +
> +&i2c1 {
> + clock-frequency = <260>;
> +
> + twl: twl@48 {
> + reg = <0x48>;
> + interrupts = <7>; /* SYS_NIRQ cascaded to intc */
> + interrupt-parent = <&intc>;
> + };
> +};
> +
> +/include/ "twl4030.dtsi"
> +
> +&i2c2 {
> + clock-frequency = <40>;
> +};
> +
> +&i2c3 {
> + clock-frequency = <40>;
> +
> + /*
> + * TVP5146 Video decoder-in for analog input support.
> + */
> + tvp5146@5C {
> + compatible = "ti,tvp5146m2";
> + reg = <0x5C>;
> + };
> +};
> --
> 1.7.0.4
>
>
Benoit,
Can this (and also AM3517 DT support patch) be merged to your
next pull request?
Thanks,
Vaibhav
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
RE: [PATCH 1/2] arm:omap2:board-generic: Add DT support for AM33xx devices
On Thu, Jan 19, 2012 at 02:28:28, Grant Likely wrote:
> On Wed, Jan 18, 2012 at 12:43:58PM +0530, Vaibhav Hiremath wrote:
> > Although we consider am33xx device under omap34xx family of devices,
> > there is indeed difference between them, for example,
> >
> > - Initial required mapping (->map_io)
> > - Early init (->init_early)
> > Here, the whole sequence/data is different than omap3,
> > For example, clock/hwmod/power/voltage data.
> > - clock event/source timer (name and instances)
> >
> > So, this patch adds seperate machine descriptor for AM33XX family
> > of devices in board-generic.c file.
> >
> > Signed-off-by: Vaibhav Hiremath
> > CC: Benoit Cousson
> > Cc: Grant Likely
> > Cc: Tony Lindgren
> > ---
> > Tested it on AM335x-EVM, AM37xEVM and AM3517EVM.
> >
> > arch/arm/mach-omap2/board-generic.c | 19 +++
> > 1 files changed, 19 insertions(+), 0 deletions(-)
> >
> > diff --git a/arch/arm/mach-omap2/board-generic.c
> > b/arch/arm/mach-omap2/board-generic.c
> > index f7b4b24..2faecc8 100644
> > --- a/arch/arm/mach-omap2/board-generic.c
> > +++ b/arch/arm/mach-omap2/board-generic.c
> > @@ -106,6 +106,25 @@ DT_MACHINE_START(OMAP3_DT, "Generic OMAP3 (Flattened
> > Device Tree)")
> > MACHINE_END
> > #endif
> >
> > +#if defined(CONFIG_SOC_OMAPAM33XX)
> > +static const char *am33xx_boards_compat[] __initdata = {
> > + "ti,am33xx",
>
> Don't forget to add the new compatible values to
> Documentation/device-tree/bindings.
>
> > + NULL,
> > +};
> > +
> > +DT_MACHINE_START(AM33XX_DT, "Generic AM33XX (Flattened Device Tree)")
> > + .atag_offset= 0x100,
>
> Unneeded for DT booting.
>
> Otherwise, you can add:
>
> Acked-by: Grant Likely
>
Benoit,
Can you please merge this patch-series for next pull request?
Thanks,
Vaibhav
> > + .reserve= omap_reserve,
> > + .map_io = am33xx_map_io,
> > + .init_early = am33xx_init_early,
> > + .init_irq = omap_init_irq,
> > + .handle_irq = omap3_intc_handle_irq,
> > + .init_machine = omap_generic_init,
> > + .timer = &omap3_am33xx_timer,
> > + .dt_compat = am33xx_boards_compat,
> > +MACHINE_END
> > +#endif
> > +
> > #if defined(CONFIG_ARCH_OMAP4)
> > static const char *omap4_boards_compat[] __initdata = {
> > "ti,omap4",
> > --
> > 1.7.0.4
> >
>
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
RE: [PATCH 1/2] arm:omap2:board-generic: Add DT support for AM33xx devices
On Thu, Jan 19, 2012 at 02:28:28, Grant Likely wrote:
> On Wed, Jan 18, 2012 at 12:43:58PM +0530, Vaibhav Hiremath wrote:
> > Although we consider am33xx device under omap34xx family of devices,
> > there is indeed difference between them, for example,
> >
> > - Initial required mapping (->map_io)
> > - Early init (->init_early)
> > Here, the whole sequence/data is different than omap3,
> > For example, clock/hwmod/power/voltage data.
> > - clock event/source timer (name and instances)
> >
> > So, this patch adds seperate machine descriptor for AM33XX family
> > of devices in board-generic.c file.
> >
> > Signed-off-by: Vaibhav Hiremath
> > CC: Benoit Cousson
> > Cc: Grant Likely
> > Cc: Tony Lindgren
> > ---
> > Tested it on AM335x-EVM, AM37xEVM and AM3517EVM.
> >
> > arch/arm/mach-omap2/board-generic.c | 19 +++
> > 1 files changed, 19 insertions(+), 0 deletions(-)
> >
> > diff --git a/arch/arm/mach-omap2/board-generic.c
> > b/arch/arm/mach-omap2/board-generic.c
> > index f7b4b24..2faecc8 100644
> > --- a/arch/arm/mach-omap2/board-generic.c
> > +++ b/arch/arm/mach-omap2/board-generic.c
> > @@ -106,6 +106,25 @@ DT_MACHINE_START(OMAP3_DT, "Generic OMAP3 (Flattened
> > Device Tree)")
> > MACHINE_END
> > #endif
> >
> > +#if defined(CONFIG_SOC_OMAPAM33XX)
> > +static const char *am33xx_boards_compat[] __initdata = {
> > + "ti,am33xx",
>
> Don't forget to add the new compatible values to
> Documentation/device-tree/bindings.
>
Thanks for pointing me to this. I will send separate patch updating
Documentation/devicetree/bindings file for this.
> > + NULL,
> > +};
> > +
> > +DT_MACHINE_START(AM33XX_DT, "Generic AM33XX (Flattened Device Tree)")
> > + .atag_offset= 0x100,
>
> Unneeded for DT booting.
>
> Otherwise, you can add:
>
> Acked-by: Grant Likely
>
Thanks for review and ack.
Thanks,
Vaibhav
> > + .reserve= omap_reserve,
> > + .map_io = am33xx_map_io,
> > + .init_early = am33xx_init_early,
> > + .init_irq = omap_init_irq,
> > + .handle_irq = omap3_intc_handle_irq,
> > + .init_machine = omap_generic_init,
> > + .timer = &omap3_am33xx_timer,
> > + .dt_compat = am33xx_boards_compat,
> > +MACHINE_END
> > +#endif
> > +
> > #if defined(CONFIG_ARCH_OMAP4)
> > static const char *omap4_boards_compat[] __initdata = {
> > "ti,omap4",
> > --
> > 1.7.0.4
> >
>
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
RE: [PATCH v2 4/5] arm/dts: OMAP3: Add interrupt-controller bindings for INTC
On Fri, Jan 13, 2012 at 18:31:24, Cousson, Benoit wrote:
> On 1/13/2012 1:31 PM, Hiremath, Vaibhav wrote:
> > On Fri, Jan 13, 2012 at 16:33:07, Cousson, Benoit wrote:
> >> Hi Vaibhav,
> >>
> >> On 1/13/2012 7:14 AM, Hiremath, Vaibhav wrote:
> >>> On Tue, Dec 20, 2011 at 19:09:57, Cousson, Benoit wrote:
> >>
> >> [...]
> >>
> >>>> +++ b/arch/arm/boot/dts/omap3.dtsi
> >>>> @@ -54,10 +54,12 @@
> >>>> ranges;
> >>>> ti,hwmods = "l3_main";
> >>>>
> >>>> -intc: interrupt-controller@1 {
> >>>> -compatible = "ti,omap3-intc";
> >>>> +intc: interrupt-controller@4820 {
> >>>> +compatible = "ti,omap2-intc";
> >>>> interrupt-controller;
> >>>> #interrupt-cells =<1>;
> >>>> +ti,intc-size =<96>;
> >>> Can we configure/change this field in platform specific .dts file?
> >>> OR
> >>> Is there condition based configuration possible in DT?
> >>
> >> I'm not sure to fully understand how your two options differ.
> >> Otherwise, yes the DT it can be configured, that why I exposed this
> >> attribute.
> >> The intc code was already supporting the ti81xx with 128 lines as well,
> >> hence the need to make it configurable.
> >
> > I wanted to use DT configuration completely here, using existing
> > omap_init_irq.
> > And I personally think, lets not use different implementation only because
> > number of interrupts are different.
>
> Sure, that was the goal of that binding. Anyway, my point was that the
> driver was already generic enough to handle OMAP2, OMAP3 and TI81xx.
>
> >> The other option was two handle that in the driver with 2 different
> >> compatible strings.
> >>
> >>> To be specific,
> >>>
> >>> I am adding support for AM335x EVM (using all your DT support patches),
> >>> The device is considered as OMAP3 variant and when it comes to INTC
> >>> support,
> >>> I need to configure it to value "128", rest everything is same
> >>> (including base add).
> >>>
> >>> Can I do something like
> >>>
> >>> File - am335x-evm.dts
> >>>
> >>> /include/ "omap3.dtsi"
> >>>
> >>>
> >>> Again change the specific fields of " intc: interrupt-controller"?
> >>
> >> Yes.
> >>
> >>>
> >>>
> >>> How can this be handled?
> >>
> >> After the include, you can redefine the node and the hierarchy:
> >>
> >> + ocp {
> >> + intc: interrupt-controller@4820 {
> >> + ti,intc-size =<128>;
> >> + };
> >> ...
> >>
> >> or use the label directly:
> >>
> >> +&intc: {
> >> + ti,intc-size =<128>;
> >> +}
> >>
> >> You can have a look at the way i2c or twl are using the include so far.
> >>
> > Thanks, I will trying this now...
> > And if it works, then I can submit the patches...
>
> Well, it should in theory :-)
>
Thanks Benoit, it is working. Submitting patches now...
Thanks,
Vaibhav
> Regards,
> Benoit
>
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
RE: [PATCH v2 4/5] arm/dts: OMAP3: Add interrupt-controller bindings for INTC
On Fri, Jan 13, 2012 at 16:33:07, Cousson, Benoit wrote:
> Hi Vaibhav,
>
> On 1/13/2012 7:14 AM, Hiremath, Vaibhav wrote:
> > On Tue, Dec 20, 2011 at 19:09:57, Cousson, Benoit wrote:
>
> [...]
>
> >> +++ b/arch/arm/boot/dts/omap3.dtsi
> >> @@ -54,10 +54,12 @@
> >>ranges;
> >>ti,hwmods = "l3_main";
> >>
> >> - intc: interrupt-controller@1 {
> >> - compatible = "ti,omap3-intc";
> >> + intc: interrupt-controller@4820 {
> >> + compatible = "ti,omap2-intc";
> >>interrupt-controller;
> >>#interrupt-cells =<1>;
> >> + ti,intc-size =<96>;
> > Can we configure/change this field in platform specific .dts file?
> > OR
> > Is there condition based configuration possible in DT?
>
> I'm not sure to fully understand how your two options differ.
> Otherwise, yes the DT it can be configured, that why I exposed this
> attribute.
> The intc code was already supporting the ti81xx with 128 lines as well,
> hence the need to make it configurable.
I wanted to use DT configuration completely here, using existing
omap_init_irq.
And I personally think, lets not use different implementation only because
number of interrupts are different.
> The other option was two handle that in the driver with 2 different
> compatible strings.
>
> > To be specific,
> >
> > I am adding support for AM335x EVM (using all your DT support patches),
> > The device is considered as OMAP3 variant and when it comes to INTC support,
> > I need to configure it to value "128", rest everything is same
> > (including base add).
> >
> > Can I do something like
> >
> > File - am335x-evm.dts
> >
> > /include/ "omap3.dtsi"
> >
> >
> > Again change the specific fields of " intc: interrupt-controller"?
>
> Yes.
>
> >
> >
> > How can this be handled?
>
> After the include, you can redefine the node and the hierarchy:
>
> + ocp {
> + intc: interrupt-controller@4820 {
> + ti,intc-size = <128>;
> + };
> ...
>
> or use the label directly:
>
> +&intc: {
> + ti,intc-size =<128>;
> +}
>
> You can have a look at the way i2c or twl are using the include so far.
>
Thanks, I will trying this now...
And if it works, then I can submit the patches...
Thanks,
Vaibhav
> Regards,
> Benoit
>
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
RE: [PATCH v2 4/5] arm/dts: OMAP3: Add interrupt-controller bindings for INTC
On Tue, Dec 20, 2011 at 19:09:57, Cousson, Benoit wrote:
> Update the DTS with the proper information required by the
> INTC bindings.
>
> - Add the number of interrupt lines
> - Add the reg and the compatible entries.
>
> Signed-off-by: Benoit Cousson
> Cc: Rob Herring
> ---
> arch/arm/boot/dts/omap3.dtsi |6 --
> 1 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
> index d202bb5..6866dc7 100644
> --- a/arch/arm/boot/dts/omap3.dtsi
> +++ b/arch/arm/boot/dts/omap3.dtsi
> @@ -54,10 +54,12 @@
> ranges;
> ti,hwmods = "l3_main";
>
> - intc: interrupt-controller@1 {
> - compatible = "ti,omap3-intc";
> + intc: interrupt-controller@4820 {
> + compatible = "ti,omap2-intc";
> interrupt-controller;
> #interrupt-cells = <1>;
> + ti,intc-size = <96>;
Can we configure/change this field in platform specific .dts file?
OR
Is there condition based configuration possible in DT?
To be specific,
I am adding support for AM335x EVM (using all your DT support patches),
The device is considered as OMAP3 variant and when it comes to INTC support,
I need to configure it to value "128", rest everything is same
(including base add).
Can I do something like
File - am335x-evm.dts
/include/ "omap3.dtsi"
Again change the specific fields of " intc: interrupt-controller"?
How can this be handled?
Thanks,
Vaibhav
> + reg = <0x4820 0x1000>;
> };
> };
> };
> --
> 1.7.0.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
RE: [PATCH-V1] arm/dts: Add support for TI OMAP3 EVM board
> -Original Message-
> From: Hiremath, Vaibhav
> Sent: Friday, December 16, 2011 12:36 PM
> To: linux-o...@vger.kernel.org
> Cc: t...@atomide.com; linux-arm-ker...@lists.infradead.org; devicetree-
> disc...@lists.ozlabs.org; grant.lik...@secretlab.ca; Cousson, Benoit;
> Hiremath, Vaibhav
> Subject: [PATCH-V1] arm/dts: Add support for TI OMAP3 EVM board
>
> Add OMAP3 EVM (OMAP3530, AM/DM37x) DTS file to use the omap3.dtsi SoC file,
> along with memory node information.
>
> Signed-off-by: Vaibhav Hiremath
> ---
> Boot tested it on AM/DM37x EVM, kernel parses the info correctly.
>
> arch/arm/boot/dts/omap3-evm.dts | 20
> 1 files changed, 20 insertions(+), 0 deletions(-)
> create mode 100644 arch/arm/boot/dts/omap3-evm.dts
>
> diff --git a/arch/arm/boot/dts/omap3-evm.dts b/arch/arm/boot/dts/omap3-
> evm.dts
> new file mode 100644
> index 000..2eee16e
> --- /dev/null
> +++ b/arch/arm/boot/dts/omap3-evm.dts
> @@ -0,0 +1,20 @@
> +/*
> + * Copyright (C) 2011 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.
> + */
> +/dts-v1/;
> +
> +/include/ "omap3.dtsi"
> +
> +/ {
> + model = "TI OMAP3 EVM (OMAP3530, AM/DM37x)";
> + compatible = "ti,omap3-evm", "ti,omap3";
> +
> + memory {
> + device_type = "memory";
> + reg = <0x8000 0x1000>; /* 256 MB */
> + };
> +};
Can this merged? OR anybody has any comments here?
Thanks,
Vaibhav
> --
> 1.7.0.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
RE: [PATCH] arm/dts: Add support for OMAP3 Mistral EVM board
> -Original Message-
> From: Hiremath, Vaibhav
> Sent: Friday, December 16, 2011 11:36 AM
> To: linux-o...@vger.kernel.org
> Cc: t...@atomide.com; linux-arm-ker...@lists.infradead.org; devicetree-
> disc...@lists.ozlabs.org; grant.lik...@secretlab.ca; Cousson, Benoit;
> Hiremath, Vaibhav
> Subject: [PATCH] arm/dts: Add support for OMAP3 Mistral EVM board
>
> Add OMAP3 Mistral EVM DTS file to use the omap3.dtsi SoC file,
> along with memory node information.
>
> Signed-off-by: Vaibhav Hiremath
> ---
> Boot tested it on DM37x Mistral EVM, kernel parses the info correctly.
>
> arch/arm/boot/dts/omap3-evm.dts | 20
> 1 files changed, 20 insertions(+), 0 deletions(-)
> create mode 100644 arch/arm/boot/dts/omap3-evm.dts
>
> diff --git a/arch/arm/boot/dts/omap3-evm.dts b/arch/arm/boot/dts/omap3-
> evm.dts
> new file mode 100644
> index 000..59b2de0
> --- /dev/null
> +++ b/arch/arm/boot/dts/omap3-evm.dts
> @@ -0,0 +1,20 @@
> +/*
> + * Copyright (C) 2011 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.
> + */
> +/dts-v1/;
> +
> +/include/ "omap3.dtsi"
> +
> +/ {
> + model = "TI OMAP3 Mistral EVM";
Just realized that, this is not in sync with current code. We always referred
this EVM as "AM37x TI EVM".
Reposting it again... (with correction).
Thanks,
Vaibhav
> + compatible = "ti,omap3-evm", "ti,omap3";
> +
> + memory {
> + device_type = "memory";
> + reg = <0x8000 0x1000>; /* 256 MB */
> + };
> +};
> --
> 1.7.0.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
RE: [RFC 1/3] pinctrl: add a driver for the OMAP pinmux
> -Original Message-
> From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
> ow...@vger.kernel.org] On Behalf Of Koen Kooi
> Sent: Wednesday, November 23, 2011 8:51 PM
> To: Tony Lindgren
> Cc: Linus Walleij; Thomas Abraham; Nayak, Rajendra; linux-
> o...@vger.kernel.org; linaro-...@lists.linaro.org;
> linus.wall...@stericsson.com; linux-samsung-soc; devicetree-
> disc...@lists.ozlabs.org
> Subject: Re: [RFC 1/3] pinctrl: add a driver for the OMAP pinmux
>
>
> Op 22 nov. 2011, om 18:54 heeft Tony Lindgren het volgende geschreven:
>
> > * Linus Walleij [22 03:30]:
> >> On Tue, Nov 22, 2011 at 12:09 PM, Thomas Abraham
> >> wrote:
> >>> On 17 November 2011 19:27, Linus Walleij
> wrote:
>
> Maybe I'm mistaken about the device tree ambitions, but
> I was sort of hoping that it would not contain too much
> custom magic numbers that need to be cross-referenced
> elsewhere ... or rather - the more understandable the device
> tree is, the more we win.
> >>>
> >>> Device tree is expected to describe the hardware. So to
> >>> cross-reference the hardware manual to understand device tree should
> >>> be fine I guess. For instance, GPIO numbers in dts would be written as
> >>> a numeric number and not a enum or other format. And by looking up the
> >>> manual, we understand the actual details of the GPIO pin.
> >>>
> >>> If dt-compiler had a option to support #define like in C, the numbers
> >>> could have been made more easier to understand. Like, 3 to mean
> >>> GPIO_PULL_UP in Exynos dts file.
> >>
> >> OK I think I get it now, so DT bindings shall really NOT be read
> >> by any of the pinctrl core, it is *supposed* to be all driver-specific.
> >> Then it makes perfect sense to have it as it is.
> >
> > Yes the driver nodes should describe in DT which pins to use:
> >
> >serial@1234 {
> >compatible = "8250";
> >reg = <0x1234 0x40>;
> >reg-shift = <2>;
> >interrupts = < 10 >;
> > pins = "uart1_rx", "uart1_tx";
> >};
> >
> > Note that we should use the actual signal names, not package specific
> > pad names. This way they have a high likelyhood to work for new packages
> > too by just mapping the signals to the new package.
>
> How would this handle the situation where you can mux a signal to multiple
> pins? IIRC omap3 and am335x can do funny stuff with the display pins like
> being able to map the blue bits to different pinblocks.
>
That's quite not true, in case of omap3 pins are labeled as R0-R7, B0-B7 and
G0-G7; what changes is pixel format.
AM335x LCDC is completely different IP altogether and spec doesn't map
Colors to pins. It barely maps bit0 from memory to pinX.
Now you call it as a standard or legacy or may be due to SGX software,
the pixel format we use is BGR (as in memory).
It is completely depends on how you interface the pins to LCD (considering)
Software support/requirement.
Thanks,
Vaibhav
> regards,
>
> Koen
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
