RE: mach-omap2/timer.c: Bug introduced while merging patch - ff931c82
> -Original Message- > From: Tony Lindgren [mailto:t...@atomide.com] > Sent: Tuesday, May 07, 2013 5:08 AM > To: Hiremath, Vaibhav > Cc: linux-o...@vger.kernel.org; linux-kernel@vger.kernel.org; linux- > arm-ker...@lists.infradead.org > Subject: Re: mach-omap2/timer.c: Bug introduced while merging patch - > ff931c82 > > * Hiremath, Vaibhav [130506 11:35]: > > > > Ohh yeah, I already have a patch for it - > > Thanks, I'll add that into omap-for-v3.10/fixes. I modified > the comments a bit trying to figure out where it changed, updated > patch below. > Thanks Tony. Thanks, Vaibhav -- 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/
RE: mach-omap2/timer.c: Bug introduced while merging patch - ff931c82
> -Original Message-
> From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
> ow...@vger.kernel.org] On Behalf Of Tony Lindgren
> Sent: Monday, May 06, 2013 8:57 PM
> To: Hiremath, Vaibhav
> Cc: linux-o...@vger.kernel.org; linux-kernel@vger.kernel.org; linux-
> arm-ker...@lists.infradead.org
> Subject: Re: mach-omap2/timer.c: Bug introduced while merging patch -
> ff931c82
>
> * Hiremath, Vaibhav [130506 00:12]:
> > Hi,
> >
> > Not sure whether this got discussed and fixed already, but Google
> didn't give me anything :)
> >
> > The below commit got merged wrongly to Mainline (Changes from timer.c
> got missed), and
> > due to this none of omap boards will boot.
> >
> >
> > From ff931c821bab6713a52b768b0cd7ee7e90713b36 Mon Sep 17 00:00:00
> 2001
> > From: Rajendra Nayak
> > Date: Thu, 21 Mar 2013 11:04:52 +
> > Subject: ARM: OMAP: clocks: Delay clk inits atleast until slab is
> initialized
> >
> >
> > It seems Linux-omap tree has the fix patch for this, and it should
> get pushed ASAP.
> > Below are links for Linus's mainline commit [1], the actual patch
> submitted to the list [2] and
> > Commit present in Linux-omap [3].
>
> Can you please provide a proper patch for the regression since sounds
> like you already figured out what happened?
>
Ohh yeah, I already have a patch for it -
From: Vaibhav Hiremath
Date: Mon, 6 May 2013 13:23:27 +0530
Subject: [PATCH] ARM: OMAP2+: Regression: Add missing code while merging commit
ff931c82 to Mainline
While merging commit ff931c82 [1] to Mainline,, it seems not all the changes
from
the original patch [2] have been merged; changes from mach-omap2/timer.c have
been
dropped, which invokes xxx_clk_init() function required to register platform
clock table. And without this none of OMAP family of devices will boot from
Mainline.
[1]
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/arch/arm/mach-omap2/io.c?id=ff931c821bab6713a52b768b0cd7ee7e90713b36
[2] https://patchwork.kernel.org/patch/2300071/
Signed-off-by: Vaibhav Hiremath
---
arch/arm/mach-omap2/timer.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index f12aa6c..31ae764 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -549,6 +549,8 @@ static inline void __init realtime_counter_init(void)
clksrc_nr, clksrc_src, clksrc_prop) \
void __init omap##name##_gptimer_timer_init(void) \
{ \
+ if (omap_clk_init) \
+ omap_clk_init();\
omap_dmtimer_init();\
omap2_gp_clockevent_init((clkev_nr), clkev_src, clkev_prop);\
omap2_gptimer_clocksource_init((clksrc_nr), clksrc_src, \
@@ -559,6 +561,8 @@ void __init omap##name##_gptimer_timer_init(void)
\
clksrc_nr, clksrc_src, clksrc_prop) \
void __init omap##name##_sync32k_timer_init(void) \
{ \
+ if (omap_clk_init) \
+ omap_clk_init();\
omap_dmtimer_init();\
omap2_gp_clockevent_init((clkev_nr), clkev_src, clkev_prop);\
/* Enable the use of clocksource="gp_timer" kernel parameter */ \
Thanks,
Vaibhav
--
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/
mach-omap2/timer.c: Bug introduced while merging patch - ff931c82
Hi, Not sure whether this got discussed and fixed already, but Google didn't give me anything :) The below commit got merged wrongly to Mainline (Changes from timer.c got missed), and due to this none of omap boards will boot. >From ff931c821bab6713a52b768b0cd7ee7e90713b36 Mon Sep 17 00:00:00 2001 From: Rajendra Nayak Date: Thu, 21 Mar 2013 11:04:52 + Subject: ARM: OMAP: clocks: Delay clk inits atleast until slab is initialized It seems Linux-omap tree has the fix patch for this, and it should get pushed ASAP. Below are links for Linus's mainline commit [1], the actual patch submitted to the list [2] and Commit present in Linux-omap [3]. [1] http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/arch/arm/mach-omap2/io.c?id=ff931c821bab6713a52b768b0cd7ee7e90713b36 [2] https://patchwork.kernel.org/patch/2300071/ [3] http://git.kernel.org/cgit/linux/kernel/git/tmlind/linux-omap.git/commit/arch/arm/mach-omap2/timer.c?id=ff931c821bab6713a52b768b0cd7ee7e90713b36 Thanks, Vaibhav -- 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/
RE: mach-omap2/timer.c: Bug introduced while merging patch - ff931c82
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Tony Lindgren
Sent: Monday, May 06, 2013 8:57 PM
To: Hiremath, Vaibhav
Cc: linux-o...@vger.kernel.org; linux-kernel@vger.kernel.org; linux-
arm-ker...@lists.infradead.org
Subject: Re: mach-omap2/timer.c: Bug introduced while merging patch -
ff931c82
* Hiremath, Vaibhav hvaib...@ti.com [130506 00:12]:
Hi,
Not sure whether this got discussed and fixed already, but Google
didn't give me anything :)
The below commit got merged wrongly to Mainline (Changes from timer.c
got missed), and
due to this none of omap boards will boot.
From ff931c821bab6713a52b768b0cd7ee7e90713b36 Mon Sep 17 00:00:00
2001
From: Rajendra Nayak rna...@ti.com
Date: Thu, 21 Mar 2013 11:04:52 +
Subject: ARM: OMAP: clocks: Delay clk inits atleast until slab is
initialized
It seems Linux-omap tree has the fix patch for this, and it should
get pushed ASAP.
Below are links for Linus's mainline commit [1], the actual patch
submitted to the list [2] and
Commit present in Linux-omap [3].
Can you please provide a proper patch for the regression since sounds
like you already figured out what happened?
Ohh yeah, I already have a patch for it -
From: Vaibhav Hiremath hvaib...@ti.com
Date: Mon, 6 May 2013 13:23:27 +0530
Subject: [PATCH] ARM: OMAP2+: Regression: Add missing code while merging commit
ff931c82 to Mainline
While merging commit ff931c82 [1] to Mainline,, it seems not all the changes
from
the original patch [2] have been merged; changes from mach-omap2/timer.c have
been
dropped, which invokes xxx_clk_init() function required to register platform
clock table. And without this none of OMAP family of devices will boot from
Mainline.
[1]
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/arch/arm/mach-omap2/io.c?id=ff931c821bab6713a52b768b0cd7ee7e90713b36
[2] https://patchwork.kernel.org/patch/2300071/
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
---
arch/arm/mach-omap2/timer.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index f12aa6c..31ae764 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -549,6 +549,8 @@ static inline void __init realtime_counter_init(void)
clksrc_nr, clksrc_src, clksrc_prop) \
void __init omap##name##_gptimer_timer_init(void) \
{ \
+ if (omap_clk_init) \
+ omap_clk_init();\
omap_dmtimer_init();\
omap2_gp_clockevent_init((clkev_nr), clkev_src, clkev_prop);\
omap2_gptimer_clocksource_init((clksrc_nr), clksrc_src, \
@@ -559,6 +561,8 @@ void __init omap##name##_gptimer_timer_init(void)
\
clksrc_nr, clksrc_src, clksrc_prop) \
void __init omap##name##_sync32k_timer_init(void) \
{ \
+ if (omap_clk_init) \
+ omap_clk_init();\
omap_dmtimer_init();\
omap2_gp_clockevent_init((clkev_nr), clkev_src, clkev_prop);\
/* Enable the use of clocksource=gp_timer kernel parameter */ \
Thanks,
Vaibhav
--
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/
mach-omap2/timer.c: Bug introduced while merging patch - ff931c82
Hi, Not sure whether this got discussed and fixed already, but Google didn't give me anything :) The below commit got merged wrongly to Mainline (Changes from timer.c got missed), and due to this none of omap boards will boot. From ff931c821bab6713a52b768b0cd7ee7e90713b36 Mon Sep 17 00:00:00 2001 From: Rajendra Nayak rna...@ti.com Date: Thu, 21 Mar 2013 11:04:52 + Subject: ARM: OMAP: clocks: Delay clk inits atleast until slab is initialized It seems Linux-omap tree has the fix patch for this, and it should get pushed ASAP. Below are links for Linus's mainline commit [1], the actual patch submitted to the list [2] and Commit present in Linux-omap [3]. [1] http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/arch/arm/mach-omap2/io.c?id=ff931c821bab6713a52b768b0cd7ee7e90713b36 [2] https://patchwork.kernel.org/patch/2300071/ [3] http://git.kernel.org/cgit/linux/kernel/git/tmlind/linux-omap.git/commit/arch/arm/mach-omap2/timer.c?id=ff931c821bab6713a52b768b0cd7ee7e90713b36 Thanks, Vaibhav -- 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/
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 = <_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>;
> + gpmc,wr-data-mux-bus = <0>;
> +
> +
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 avinashphi...@ti.com
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 avinashphi...@ti.com
Signed-off-by: Gupta, Pekon pe...@ti.com
---
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;
+ gpmc,wr-data-mux-bus = 0;
+
+ #address-cells = 1;
+ #size-cells = 1;
+ elm_id = elm;
+
+ /* MTD partition table */
+ partition@0 {
+ label = SPL1;
+ reg = 0x 0x2;
+ };
+
+ partition@1 {
+ label = SPL2;
+ reg = 0x0002 0x0002
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 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 snip 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? Yes, you
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 hash
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
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
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 @@
> > > > > _emac1 {
> > > > > phy_id = <_mdio>, <1>;
> > > > > };
> > > > > +
> > > > > + {
> > > > > + status = "okay";
> > > > > + vmmc-supply = <_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 @@
> > > > > _emac1 {
> > > > > phy_id = <_mdio>, <1>;
> > > > > };
> > > > > +
> > > > > + {
> > > > > + status = "okay";
> > > > > + vmmc-supply = <_reg>;
> > > > > +};
> > > > > diff --git a/arch/arm/boot/dts/am335x-evmsk.dts
> > >
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 @@
> > > _emac1 {
> > > phy_id = <_mdio>, <1>;
> > > };
> > > +
> > > + {
> > > + status = "okay";
> > > + vmmc-supply = <_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 @@
> > > _emac1 {
> > > phy_id = <_mdio>, <1>;
> > > };
> > > +
> > > + {
> > > + status = "okay";
> > > + vmmc-supply = <_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;
> > > };
> > > };
> > > };
> > > +
> > > + {
> > > + status = "okay";
> > > + vmmc-supply = <_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;
> > > +
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 mpor...@ti.com
Acked-by: Tony Lindgren t...@atomide.com
---
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?
Yes, I've answered this one before and I think this illustrates a need
for a comment in the .dtsi. mmc3 edma event are on the crossbar and so
the event that will be mapped is system-specific. Since Luca is still
working on DT support for WiLink, there's no way to show an example of
how this is used upstream as that's the only in-kernel user.
I have a test driver I've cited in the postings that shows how the
crossbar is configured via the board .dts. It doesn't belong in the
.dtsi, however, in this case. When WiLink DT support
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 mpor...@ti.com
Acked-by: Tony Lindgren t...@atomide.com
---
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
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
snip
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
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�j:+v���zZ+��+zf���h���~i���z� �w���?��)ߢf��^jǫy�m��@A�a���
0��h���i
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. snip 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 hash table entries: 1024 (order: 0, 4096 bytes) [0.00] Dentry cache hash table entries: 32768 (order: 5, 131072 bytes) [0.00] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes) [0.00] __ex_table already sorted, skipping sort [0.00] Memory: 255MB = 255MB total [0.00] Memory: 212236k/212236k available, 49908k reserved, 0K highmem [0.00] Virtual kernel memory layout: [0.00] vector : 0x - 0x1000 ( 4 kB) [0.00] fixmap : 0xfff0 - 0xfffe ( 896 kB) [0.00] vmalloc : 0xd080 - 0xff00 ( 744 MB) [0.00] lowmem : 0xc000 - 0xd000 ( 256 MB) [0.00] pkmap : 0xbfe0 - 0xc000 ( 2 MB) [0.00] modules : 0xbf00 - 0xbfe0 ( 14 MB
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
snip
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?
Yes, you missed the
http://www.spinics.net/lists/arm-kernel/msg227886.html dependency
mentioned first in the cover letter.
Matt, I manually edited the file with above patch and result is still the same.
Can you point me to branch where you have tested MMC code?
diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
index 8c3b1fa..e68ac38 100644
--- a/arch/arm/common/edma.c
+++ b/arch/arm/common/edma.c
@@ -730,6 +730,9 @@ EXPORT_SYMBOL(edma_free_channel);
*/
int edma_alloc_slot(unsigned ctlr, int slot)
{
+ if (!edma_cc[ctlr])
+ return -EINVAL;
+
if (slot = 0)
slot = EDMA_CHAN_SLOT(slot);
Thanks,
Vaibhav
--
To unsubscribe from this list: send the line
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 @@
> _emac1 {
> phy_id = <_mdio>, <1>;
> };
> +
> + {
> + status = "okay";
> + vmmc-supply = <_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 @@
> _emac1 {
> phy_id = <_mdio>, <1>;
> };
> +
> + {
> + status = "okay";
> + vmmc-supply = <_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;
> };
> };
> };
> +
> + {
> + status = "okay";
> + vmmc-supply = <_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 = < 24
> + 25>;
> + dma-names = "tx", "rx";
> + status = "disabled";
> + };
> +
> + mmc2: mmc@481d8000 {
> + compatible = "ti,omap3-hsmmc";
> + ti,hwmods = "mmc2";
> + ti,needs-special-reset;
> + dmas = < 2
> + 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
--
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/
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 mpor...@ti.com
Acked-by: Tony Lindgren t...@atomide.com
---
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
--
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/
RE: [PATCH 1/7] ARM: OMAP: AM33xx hwmod: Corrects PWM subsystem HWMOD entries
On Fri, Feb 08, 2013 at 20:40:18, Paul Walmsley wrote:
> Hi
>
> On Wed, 2 Jan 2013, Philip Avinash wrote:
>
> > EQEP entry is HWMOD entry is not present in HWMOD entry.
>
> Patch descriptions need to make sense. This one does not. I've fixed it
> for you this time, but please take more care in the future.
>
>
> - Paul
>
>
> From: Philip Avinash
> Date: Wed, 2 Jan 2013 18:54:48 +0530
> Subject: [PATCH] ARM: OMAP: AM33xx hwmod: Corrects PWM subsystem HWMOD
> entries
>
> EQEP IP block integration data is not present in HWMOD data. Also
> address ranges specified for EACP & EHRPWM are not correct & HWMOD
> flags of ADDR_TYPE_RT are added to PWM subsystem register address
> space. This patch:
> 1. Corrects register address mapping for ECAP & EHRPWM
> 2. Removes HWMOD flags in PWM submodule register address space.
> 3. Adds EQEP HWMOD entries.
>
> Signed-off-by: Philip Avinash
> [p...@pwsan.com: tweaked patch description]
> Signed-off-by: Paul Walmsley
Feel free to add my Acked-by on this.
Thanks,
Vaibhav
> ---
> arch/arm/mach-omap2/omap_hwmod_33xx_data.c | 158
> +---
> 1 file changed, 145 insertions(+), 13 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
> b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
> index 9e34d4c..4b1cc4d 100644
> --- a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
> +++ b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
> @@ -784,7 +784,7 @@ static struct omap_hwmod am33xx_elm_hwmod = {
> };
>
> /*
> - * 'epwmss' class: ecap0,1,2, ehrpwm0,1,2
> + * 'epwmss' class: ehrpwm0,1,2 eqep0,1,2 ecap0,1,2
> */
> static struct omap_hwmod_class_sysconfig am33xx_epwmss_sysc = {
> .rev_offs = 0x0,
> @@ -864,6 +864,66 @@ static struct omap_hwmod am33xx_ehrpwm2_hwmod = {
> },
> };
>
> +/* eqep0 */
> +static struct omap_hwmod_irq_info am33xx_eqep0_irqs[] = {
> + { .irq = 79 + OMAP_INTC_START, },
> + { .irq = -1 },
> +};
> +
> +static struct omap_hwmod am33xx_eqep0_hwmod = {
> + .name = "eqep0",
> + .class = _epwmss_hwmod_class,
> + .clkdm_name = "l4ls_clkdm",
> + .mpu_irqs = am33xx_eqep0_irqs,
> + .main_clk = "l4ls_gclk",
> + .prcm = {
> + .omap4 = {
> + .clkctrl_offs = AM33XX_CM_PER_EPWMSS0_CLKCTRL_OFFSET,
> + .modulemode = MODULEMODE_SWCTRL,
> + },
> + },
> +};
> +
> +/* eqep1 */
> +static struct omap_hwmod_irq_info am33xx_eqep1_irqs[] = {
> + { .irq = 88 + OMAP_INTC_START, },
> + { .irq = -1 },
> +};
> +
> +static struct omap_hwmod am33xx_eqep1_hwmod = {
> + .name = "eqep1",
> + .class = _epwmss_hwmod_class,
> + .clkdm_name = "l4ls_clkdm",
> + .mpu_irqs = am33xx_eqep1_irqs,
> + .main_clk = "l4ls_gclk",
> + .prcm = {
> + .omap4 = {
> + .clkctrl_offs = AM33XX_CM_PER_EPWMSS1_CLKCTRL_OFFSET,
> + .modulemode = MODULEMODE_SWCTRL,
> + },
> + },
> +};
> +
> +/* eqep2 */
> +static struct omap_hwmod_irq_info am33xx_eqep2_irqs[] = {
> + { .irq = 89 + OMAP_INTC_START, },
> + { .irq = -1 },
> +};
> +
> +static struct omap_hwmod am33xx_eqep2_hwmod = {
> + .name = "eqep2",
> + .class = _epwmss_hwmod_class,
> + .clkdm_name = "l4ls_clkdm",
> + .mpu_irqs = am33xx_eqep2_irqs,
> + .main_clk = "l4ls_gclk",
> + .prcm = {
> + .omap4 = {
> + .clkctrl_offs = AM33XX_CM_PER_EPWMSS2_CLKCTRL_OFFSET,
> + .modulemode = MODULEMODE_SWCTRL,
> + },
> + },
> +};
> +
> /* ecap0 */
> static struct omap_hwmod_irq_info am33xx_ecap0_irqs[] = {
> { .irq = 31 + OMAP_INTC_START, },
> @@ -2559,8 +2619,7 @@ static struct omap_hwmod_addr_space
> am33xx_ehrpwm0_addr_space[] = {
> },
> {
> .pa_start = 0x48300200,
> - .pa_end = 0x48300200 + SZ_256 - 1,
> - .flags = ADDR_TYPE_RT
> + .pa_end = 0x48300200 + SZ_128 - 1,
> },
> { }
> };
> @@ -2585,8 +2644,7 @@ static struct omap_hwmod_addr_space
> am33xx_ehrpwm1_addr_space[] = {
> },
> {
> .pa_start = 0x48302200,
> - .pa_end = 0x48302200 + SZ_256 - 1,
> - .flags = ADDR_TYPE_RT
> + .pa_end = 0x48302200 + SZ_128 - 1,
> },
> { }
> };
> @@ -2611,8 +2669,7 @@ static struct omap_hwmod_addr_space
> am33xx_ehrpwm2_addr_space[] = {
> },
> {
> .pa_start = 0x48304200,
> - .pa_end = 0x48304200 + SZ_256 - 1,
> - .flags = ADDR_TYPE_RT
> + .pa_end = 0x48304200 + SZ_128 - 1,
> },
> { }
> };
> @@ -2629,6 +2686,81 @@ static struct omap_hwmod_ocp_if
RE: [PATCH 1/7] ARM: OMAP: AM33xx hwmod: Corrects PWM subsystem HWMOD entries
On Fri, Feb 08, 2013 at 20:40:18, Paul Walmsley wrote:
Hi
On Wed, 2 Jan 2013, Philip Avinash wrote:
EQEP entry is HWMOD entry is not present in HWMOD entry.
Patch descriptions need to make sense. This one does not. I've fixed it
for you this time, but please take more care in the future.
- Paul
From: Philip Avinash avinashphi...@ti.com
Date: Wed, 2 Jan 2013 18:54:48 +0530
Subject: [PATCH] ARM: OMAP: AM33xx hwmod: Corrects PWM subsystem HWMOD
entries
EQEP IP block integration data is not present in HWMOD data. Also
address ranges specified for EACP EHRPWM are not correct HWMOD
flags of ADDR_TYPE_RT are added to PWM subsystem register address
space. This patch:
1. Corrects register address mapping for ECAP EHRPWM
2. Removes HWMOD flags in PWM submodule register address space.
3. Adds EQEP HWMOD entries.
Signed-off-by: Philip Avinash avinashphi...@ti.com
[p...@pwsan.com: tweaked patch description]
Signed-off-by: Paul Walmsley p...@pwsan.com
Feel free to add my Acked-by on this.
Thanks,
Vaibhav
---
arch/arm/mach-omap2/omap_hwmod_33xx_data.c | 158
+---
1 file changed, 145 insertions(+), 13 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
index 9e34d4c..4b1cc4d 100644
--- a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
@@ -784,7 +784,7 @@ static struct omap_hwmod am33xx_elm_hwmod = {
};
/*
- * 'epwmss' class: ecap0,1,2, ehrpwm0,1,2
+ * 'epwmss' class: ehrpwm0,1,2 eqep0,1,2 ecap0,1,2
*/
static struct omap_hwmod_class_sysconfig am33xx_epwmss_sysc = {
.rev_offs = 0x0,
@@ -864,6 +864,66 @@ static struct omap_hwmod am33xx_ehrpwm2_hwmod = {
},
};
+/* eqep0 */
+static struct omap_hwmod_irq_info am33xx_eqep0_irqs[] = {
+ { .irq = 79 + OMAP_INTC_START, },
+ { .irq = -1 },
+};
+
+static struct omap_hwmod am33xx_eqep0_hwmod = {
+ .name = eqep0,
+ .class = am33xx_epwmss_hwmod_class,
+ .clkdm_name = l4ls_clkdm,
+ .mpu_irqs = am33xx_eqep0_irqs,
+ .main_clk = l4ls_gclk,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = AM33XX_CM_PER_EPWMSS0_CLKCTRL_OFFSET,
+ .modulemode = MODULEMODE_SWCTRL,
+ },
+ },
+};
+
+/* eqep1 */
+static struct omap_hwmod_irq_info am33xx_eqep1_irqs[] = {
+ { .irq = 88 + OMAP_INTC_START, },
+ { .irq = -1 },
+};
+
+static struct omap_hwmod am33xx_eqep1_hwmod = {
+ .name = eqep1,
+ .class = am33xx_epwmss_hwmod_class,
+ .clkdm_name = l4ls_clkdm,
+ .mpu_irqs = am33xx_eqep1_irqs,
+ .main_clk = l4ls_gclk,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = AM33XX_CM_PER_EPWMSS1_CLKCTRL_OFFSET,
+ .modulemode = MODULEMODE_SWCTRL,
+ },
+ },
+};
+
+/* eqep2 */
+static struct omap_hwmod_irq_info am33xx_eqep2_irqs[] = {
+ { .irq = 89 + OMAP_INTC_START, },
+ { .irq = -1 },
+};
+
+static struct omap_hwmod am33xx_eqep2_hwmod = {
+ .name = eqep2,
+ .class = am33xx_epwmss_hwmod_class,
+ .clkdm_name = l4ls_clkdm,
+ .mpu_irqs = am33xx_eqep2_irqs,
+ .main_clk = l4ls_gclk,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = AM33XX_CM_PER_EPWMSS2_CLKCTRL_OFFSET,
+ .modulemode = MODULEMODE_SWCTRL,
+ },
+ },
+};
+
/* ecap0 */
static struct omap_hwmod_irq_info am33xx_ecap0_irqs[] = {
{ .irq = 31 + OMAP_INTC_START, },
@@ -2559,8 +2619,7 @@ static struct omap_hwmod_addr_space
am33xx_ehrpwm0_addr_space[] = {
},
{
.pa_start = 0x48300200,
- .pa_end = 0x48300200 + SZ_256 - 1,
- .flags = ADDR_TYPE_RT
+ .pa_end = 0x48300200 + SZ_128 - 1,
},
{ }
};
@@ -2585,8 +2644,7 @@ static struct omap_hwmod_addr_space
am33xx_ehrpwm1_addr_space[] = {
},
{
.pa_start = 0x48302200,
- .pa_end = 0x48302200 + SZ_256 - 1,
- .flags = ADDR_TYPE_RT
+ .pa_end = 0x48302200 + SZ_128 - 1,
},
{ }
};
@@ -2611,8 +2669,7 @@ static struct omap_hwmod_addr_space
am33xx_ehrpwm2_addr_space[] = {
},
{
.pa_start = 0x48304200,
- .pa_end = 0x48304200 + SZ_256 - 1,
- .flags = ADDR_TYPE_RT
+ .pa_end = 0x48304200 + SZ_128 - 1,
},
{ }
};
@@ -2629,6 +2686,81 @@ static struct omap_hwmod_ocp_if am33xx_l4_ls__ehrpwm2
= {
* Splitting the resources to handle access of PWMSS config space
* and module
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-disc...@lists.ozlabs.org > https://lists.ozlabs.org/listinfo/devicetree-discuss > -- 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/
RE: [GIT PULL] ARM part of USB patches
On Tue, Feb 05, 2013 at 23:49:47, Tony Lindgren wrote: * gre...@linuxfoundation.org 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 t...@atomide.com 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-disc...@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss -- 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/
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(>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", _wires);
> > > +
> > > + node = of_find_node_by_name(pdev->dev.of_node, "adc");
> > > + of_property_read_u32(node, "ti,adc-channels", _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-disc...@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/devicetree-discuss
>
--
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/
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 rac...@ti.com het
volgende geschreven:
From: Patil, Rachna rac...@ti.com
Make changes to add DT support in the MFD core driver.
Signed-off-by: Patil, Rachna rac...@ti.com
---
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 linux/regmap.h
#include linux/mfd/core.h
#include linux/pm_runtime.h
+#include linux/of.h
+#include linux/of_device.h
#include linux/mfd/ti_am335x_tscadc.h #include
linux/input/ti_am335x_tsc.h
@@ -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-disc...@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
--
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/
RE: [PATCH] da8xx: Allow use by am33xx based devices
On Wed, Dec 12, 2012 at 12:50:28, Manjunathappa, Prakash wrote: > Hi Vaibhav, > > On Mon, Dec 10, 2012 at 14:32:06, Hiremath, Vaibhav wrote: > > > > > > On 12/6/2012 1:38 PM, Manjunathappa, Prakash wrote: > > > Hi Tomi, > > > > > > On Wed, Oct 31, 2012 at 10:52:59, Manjunathappa, Prakash wrote: > > >> Hi, > > >> > > >> On Wed, Oct 31, 2012 at 21:26:08, Pantelis Antoniou wrote: > > >>> This driver can be used for AM33xx devices, like the popular beaglebone. > > >>> > > >>> Signed-off-by: Pantelis Antoniou > > >>> --- > > >>> drivers/video/Kconfig | 2 +- > > >>> 1 file changed, 1 insertion(+), 1 deletion(-) > > >>> > > >>> diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig > > >>> index 9791d10..e7868d8 100644 > > >>> --- a/drivers/video/Kconfig > > >>> +++ b/drivers/video/Kconfig > > >>> @@ -2202,7 +2202,7 @@ config FB_SH7760 > > >>> > > >>> config FB_DA8XX > > >>> tristate "DA8xx/OMAP-L1xx Framebuffer support" > > >>> - depends on FB && ARCH_DAVINCI_DA8XX > > >>> + depends on FB && (ARCH_DAVINCI_DA8XX || SOC_AM33XX) > > >> > > >> Agreed this is present on da8xx and am33xx, but moving forward for > > >> supporting DT, we should be avoiding these dependencies. So instead > > >> change this to remove machine dependencies. > > >> > > > > > > I could be wrong here, having dependency on platform seems to be right. > > > Otherwise may lead to build errors for other platforms. > > > > No, it should not result in to build error unless driver uses some > > platform specific api's. > > > > Agreed, should not result in build error. But is it ok to show this option > on the platforms which do not have this IP? > You can choose to put machine dependency here, as this patch is already doing it. The side-effect of this would be, list may grow and you may have to edit this file everytime. Thanks, Vaibhav -- 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/
RE: [PATCH] da8xx: Allow use by am33xx based devices
On Wed, Dec 12, 2012 at 12:50:28, Manjunathappa, Prakash wrote: Hi Vaibhav, On Mon, Dec 10, 2012 at 14:32:06, Hiremath, Vaibhav wrote: On 12/6/2012 1:38 PM, Manjunathappa, Prakash wrote: Hi Tomi, On Wed, Oct 31, 2012 at 10:52:59, Manjunathappa, Prakash wrote: Hi, On Wed, Oct 31, 2012 at 21:26:08, Pantelis Antoniou wrote: This driver can be used for AM33xx devices, like the popular beaglebone. Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com --- drivers/video/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig index 9791d10..e7868d8 100644 --- a/drivers/video/Kconfig +++ b/drivers/video/Kconfig @@ -2202,7 +2202,7 @@ config FB_SH7760 config FB_DA8XX tristate DA8xx/OMAP-L1xx Framebuffer support - depends on FB ARCH_DAVINCI_DA8XX + depends on FB (ARCH_DAVINCI_DA8XX || SOC_AM33XX) Agreed this is present on da8xx and am33xx, but moving forward for supporting DT, we should be avoiding these dependencies. So instead change this to remove machine dependencies. I could be wrong here, having dependency on platform seems to be right. Otherwise may lead to build errors for other platforms. No, it should not result in to build error unless driver uses some platform specific api's. Agreed, should not result in build error. But is it ok to show this option on the platforms which do not have this IP? You can choose to put machine dependency here, as this patch is already doing it. The side-effect of this would be, list may grow and you may have to edit this file everytime. Thanks, Vaibhav -- 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/
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 = _epwmss0_hwmod,
> > + .slave = _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
>
>
--
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/
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
--
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/
RE: [PATCH] omap2-clk: Add missing lcdc clock definition
On Wed, Oct 31, 2012 at 11:19:44, Paul Walmsley wrote:
> On Wed, 31 Oct 2012, Hiremath, Vaibhav wrote:
>
> > As far as lck clock node is concerned, we had deliberately dropped all leaf-
> > node clocks from the clock tree, please refer to the description mentioned
> > in -
> > http://lists.infradead.org/pipermail/linux-arm-kernel/2012-May/101987.html
>
> Ach, should have remembered that :-( Indeed there is an LCDC hwmod:
>
> static struct omap_hwmod am33xx_lcdc_hwmod = {
> .name = "lcdc",
> .class = _lcdc_hwmod_class,
> .clkdm_name = "lcdc_clkdm",
> .mpu_irqs = am33xx_lcdc_irqs,
> .flags = HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY,
> .main_clk = "lcd_gclk",
> .prcm = {
> .omap4 = {
> .clkctrl_offs = AM33XX_CM_PER_LCDC_CLKCTRL_OFFSET,
> .modulemode = MODULEMODE_SWCTRL,
> },
> },
> };
>
> > >From LCDC driver perspective, driver is using,
> >
> > fb_clk = clk_get(>dev, NULL);
> >
> > This I feel needs to be corrected for valid name as per Spec (mostly I
> > would
> > vote for "fck") and then every platform should make sure that it returns
> > valid clock-node for it.
> >
> > Change in Driver would be,
> >
> > fb_clk = clk_get(>dev, "fck");
>
Ok, thanks. Let me submit patch for this.
Thanks,
Vaibhav
> Indeed.
>
>
> - Paul
>
--
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/
RE: [PATCH] omap2-clk: Add missing lcdc clock definition
On Wed, Oct 31, 2012 at 11:19:44, Paul Walmsley wrote:
On Wed, 31 Oct 2012, Hiremath, Vaibhav wrote:
As far as lck clock node is concerned, we had deliberately dropped all leaf-
node clocks from the clock tree, please refer to the description mentioned
in -
http://lists.infradead.org/pipermail/linux-arm-kernel/2012-May/101987.html
Ach, should have remembered that :-( Indeed there is an LCDC hwmod:
static struct omap_hwmod am33xx_lcdc_hwmod = {
.name = lcdc,
.class = am33xx_lcdc_hwmod_class,
.clkdm_name = lcdc_clkdm,
.mpu_irqs = am33xx_lcdc_irqs,
.flags = HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY,
.main_clk = lcd_gclk,
.prcm = {
.omap4 = {
.clkctrl_offs = AM33XX_CM_PER_LCDC_CLKCTRL_OFFSET,
.modulemode = MODULEMODE_SWCTRL,
},
},
};
From LCDC driver perspective, driver is using,
fb_clk = clk_get(device-dev, NULL);
This I feel needs to be corrected for valid name as per Spec (mostly I
would
vote for fck) and then every platform should make sure that it returns
valid clock-node for it.
Change in Driver would be,
fb_clk = clk_get(device-dev, fck);
Ok, thanks. Let me submit patch for this.
Thanks,
Vaibhav
Indeed.
- Paul
--
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/
RE: [PATCH] omap2-clk: Add missing lcdc clock definition
On Wed, Oct 31, 2012 at 04:56:40, Paul Walmsley wrote: > + Vaibhav Hiremath > > On Tue, 30 Oct 2012, Tony Lindgren wrote: > > > * Pantelis Antoniou [121030 11:04]: > > > Looks like the lcdc clock definition got dropped. > > > It is required for the LCD controller to work. Reintroduce. > > > > This looks like a regression, can you also add the commit > > causing it? > > Looks like probably a new "feature," in that this clock didn't exist in > the original check-in. Would be good to get Vaibhav's opinion on this; > also the common clock patches will need to be updated. > Thanks Paul for looping me in, something went wrong with my l-o subscription, so I didn't receive these Patches. As far as lck clock node is concerned, we had deliberately dropped all leaf- node clocks from the clock tree, please refer to the description mentioned in - http://lists.infradead.org/pipermail/linux-arm-kernel/2012-May/101987.html >From LCDC driver perspective, driver is using, fb_clk = clk_get(>dev, NULL); This I feel needs to be corrected for valid name as per Spec (mostly I would vote for "fck") and then every platform should make sure that it returns valid clock-node for it. Change in Driver would be, fb_clk = clk_get(>dev, "fck"); Thanks, Vaibhav > > - Paul > -- 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/
RE: [PATCH] omap2-clk: Add missing lcdc clock definition
On Wed, Oct 31, 2012 at 04:56:40, Paul Walmsley wrote: + Vaibhav Hiremath On Tue, 30 Oct 2012, Tony Lindgren wrote: * Pantelis Antoniou pa...@antoniou-consulting.com [121030 11:04]: Looks like the lcdc clock definition got dropped. It is required for the LCD controller to work. Reintroduce. This looks like a regression, can you also add the commit causing it? Looks like probably a new feature, in that this clock didn't exist in the original check-in. Would be good to get Vaibhav's opinion on this; also the common clock patches will need to be updated. Thanks Paul for looping me in, something went wrong with my l-o subscription, so I didn't receive these Patches. As far as lck clock node is concerned, we had deliberately dropped all leaf- node clocks from the clock tree, please refer to the description mentioned in - http://lists.infradead.org/pipermail/linux-arm-kernel/2012-May/101987.html From LCDC driver perspective, driver is using, fb_clk = clk_get(device-dev, NULL); This I feel needs to be corrected for valid name as per Spec (mostly I would vote for fck) and then every platform should make sure that it returns valid clock-node for it. Change in Driver would be, fb_clk = clk_get(device-dev, fck); Thanks, Vaibhav - Paul -- 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/
RE: [PATCH] ARM: OMAP2+: AM33XX: clock data: fix mcasp entries
On Wed, Oct 10, 2012 at 20:00:49, Porter, Matt wrote:
> 6ea74cb ARM: OMAP2+: hwmod: get rid of all omap_clk_get_by_name usage
> exposes a bug in the AM33XX clock data for mcasp. After moving to
> clk_get() usage, the _init() of all registered hwmods fails on mcasp0
> due to incorrect clock data causing clk_get() to fail. This causes all
> successive hwmods to fail to _init() leaving them in a bad state.
>
> This patch updates the mcasp clock entries so clk_get() will succeed.
> It is tested on BeagleBone and is needed for 3.7-rc1 to fix AM33xx
> boot.
>
Matt,
I have already submitted patch for this and it is accepted and merged in
Tony's pull request.
https://patchwork.kernel.org/patch/1499271/
Thanks,
Vaibhav
> Signed-off-by: Matt Porter
> ---
> arch/arm/mach-omap2/clock33xx_data.c |4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/clock33xx_data.c
> b/arch/arm/mach-omap2/clock33xx_data.c
> index b87b88c..0a64139 100644
> --- a/arch/arm/mach-omap2/clock33xx_data.c
> +++ b/arch/arm/mach-omap2/clock33xx_data.c
> @@ -1033,8 +1033,8 @@ static struct omap_clk am33xx_clks[] = {
> CLK("481d.d_can", NULL, _fck, CK_AM33XX),
> CLK(NULL, "debugss_ick", _ick, CK_AM33XX),
> CLK(NULL, "pruss_ocp_gclk", _ocp_gclk,
> CK_AM33XX),
> - CLK("davinci-mcasp.0", NULL, _fck,CK_AM33XX),
> - CLK("davinci-mcasp.1", NULL, _fck,CK_AM33XX),
> + CLK(NULL, "mcasp0_fck", _fck,CK_AM33XX),
> + CLK(NULL, "mcasp1_fck", _fck,CK_AM33XX),
> CLK("NULL", "mmc2_fck", _fck, CK_AM33XX),
> CLK(NULL, "mmu_fck", _fck, CK_AM33XX),
> CLK(NULL, "smartreflex0_fck", _fck,
> CK_AM33XX),
> --
> 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/
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 > -- 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/
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 hvaib...@ti.com Cc: Afzal Mohammed af...@ti.com Cc: Tony Lindgren t...@atomide.com Cc Paul Walmsley p...@pwsan.com --- This should go in for rc1, as this breaks AM33xx boot. Fixes BeagleBone on mainline. Tested-by: Matt Porter mpor...@ti.com 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 -- 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/
RE: [PATCH] ARM: OMAP2+: AM33XX: clock data: fix mcasp entries
On Wed, Oct 10, 2012 at 20:00:49, Porter, Matt wrote:
6ea74cb ARM: OMAP2+: hwmod: get rid of all omap_clk_get_by_name usage
exposes a bug in the AM33XX clock data for mcasp. After moving to
clk_get() usage, the _init() of all registered hwmods fails on mcasp0
due to incorrect clock data causing clk_get() to fail. This causes all
successive hwmods to fail to _init() leaving them in a bad state.
This patch updates the mcasp clock entries so clk_get() will succeed.
It is tested on BeagleBone and is needed for 3.7-rc1 to fix AM33xx
boot.
Matt,
I have already submitted patch for this and it is accepted and merged in
Tony's pull request.
https://patchwork.kernel.org/patch/1499271/
Thanks,
Vaibhav
Signed-off-by: Matt Porter mpor...@ti.com
---
arch/arm/mach-omap2/clock33xx_data.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/clock33xx_data.c
b/arch/arm/mach-omap2/clock33xx_data.c
index b87b88c..0a64139 100644
--- a/arch/arm/mach-omap2/clock33xx_data.c
+++ b/arch/arm/mach-omap2/clock33xx_data.c
@@ -1033,8 +1033,8 @@ static struct omap_clk am33xx_clks[] = {
CLK(481d.d_can, NULL, dcan1_fck, CK_AM33XX),
CLK(NULL, debugss_ick, debugss_ick, CK_AM33XX),
CLK(NULL, pruss_ocp_gclk, pruss_ocp_gclk,
CK_AM33XX),
- CLK(davinci-mcasp.0, NULL, mcasp0_fck,CK_AM33XX),
- CLK(davinci-mcasp.1, NULL, mcasp1_fck,CK_AM33XX),
+ CLK(NULL, mcasp0_fck, mcasp0_fck,CK_AM33XX),
+ CLK(NULL, mcasp1_fck, mcasp1_fck,CK_AM33XX),
CLK(NULL, mmc2_fck, mmc2_fck, CK_AM33XX),
CLK(NULL, mmu_fck, mmu_fck, CK_AM33XX),
CLK(NULL, smartreflex0_fck, smartreflex0_fck,
CK_AM33XX),
--
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/
RE: [PATCH 2/2] ARM: AM33XX: hwmod: Add OMAP_INTC_START offset to all module int nos
On Thu, Sep 13, 2012 at 03:22:32, Tony Lindgren wrote:
> * Vaibhav Hiremath [120912 14:17]:
> > With recent migration of omap architectures to SPARSE_IRQ framework,
> > it is important to add OMAP_INTC_START to all interrupt numbers
> > which will be eventually requested by drivers.
> >
> > This is required in order to get AM33XX boot functionality.
> >
> > Signed-off-by: Vaibhav Hiremath
> > Cc: Paul Walmsley
> > ---
> > arch/arm/mach-omap2/omap_hwmod_33xx_data.c | 168
> > ++--
> > 1 files changed, 84 insertions(+), 84 deletions(-)
> >
> > diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
> > b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
> > index 7b7ed08..3c320f4 100644
> > --- a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
> > +++ b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
>
> You should just have on top of this file:
>
> #define OMAP_INTC_START 0
>
> Then Paul can apply this, and while merging with the sparseirq
> changes, the above can be removed.
>
Ok, I will add this at the top of the file and resend this patch.
> > @@ -72,7 +72,7 @@ static struct omap_hwmod_class am33xx_emif_hwmod_class = {
> > };
> >
> > static struct omap_hwmod_irq_info am33xx_emif_irqs[] = {
> > - { .name = "ddrerr0", .irq = 101 },
> > + { .name = "ddrerr0", .irq = 101 + OMAP_INTC_START },
> > { .irq = -1 }
> > };
> >
>
> Then these should be fixed up to have trailing commas
> as requested by Russell earlier on several occasions.
>
Ok, I will fix this and all other places as well and resend.
Thanks,
Vaibhav
--
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/
RE: [PATCH 2/2] ARM: AM33XX: hwmod: Add OMAP_INTC_START offset to all module int nos
On Thu, Sep 13, 2012 at 03:22:32, Tony Lindgren wrote:
* Vaibhav Hiremath hvaib...@ti.com [120912 14:17]:
With recent migration of omap architectures to SPARSE_IRQ framework,
it is important to add OMAP_INTC_START to all interrupt numbers
which will be eventually requested by drivers.
This is required in order to get AM33XX boot functionality.
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Cc: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/omap_hwmod_33xx_data.c | 168
++--
1 files changed, 84 insertions(+), 84 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
index 7b7ed08..3c320f4 100644
--- a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
You should just have on top of this file:
#define OMAP_INTC_START 0
Then Paul can apply this, and while merging with the sparseirq
changes, the above can be removed.
Ok, I will add this at the top of the file and resend this patch.
@@ -72,7 +72,7 @@ static struct omap_hwmod_class am33xx_emif_hwmod_class = {
};
static struct omap_hwmod_irq_info am33xx_emif_irqs[] = {
- { .name = ddrerr0, .irq = 101 },
+ { .name = ddrerr0, .irq = 101 + OMAP_INTC_START },
{ .irq = -1 }
};
Then these should be fixed up to have trailing commas
as requested by Russell earlier on several occasions.
Ok, I will fix this and all other places as well and resend.
Thanks,
Vaibhav
--
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/
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
>
--
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/
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/
>
--
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/
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 > > -- 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/
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 > > -- 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/
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 hvaib...@ti.com 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 -- 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/
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 hvaib...@ti.com Cc: Tony Lindgren t...@atomide.com --- 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 -- 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/
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 +, 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 mpor...@ti.com
---
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/
--
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/
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 hvaib...@ti.com 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 kis...@ti.com
---
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
--
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/
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
>
>
--
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/
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
>
>
--
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/
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 mpor...@ti.com
---
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/
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 mpor...@ti.com
---
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
--
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/
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(>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,
> + [pdev->num_resources]);
>
> CHECK: Alignment should match open parenthesis
> #176: FILE: arch/arm/plat-omap/omap_device.c:598:
> + dev_dbg(>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
> index
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 hvaib...@ti.com
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 hvaib...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Kevin Hilman khil...@ti.com
[b-cous...@ti.com: Fix some checkpatch CHECK issues]
Signed-off-by: Benoit Cousson b-cous...@ti.com
---
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
index 6132972..5857b9c 100644
---
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
>
--
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/
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 b-cous...@ti.com
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
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
--
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/
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: [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 hvaib...@ti.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Kevin Hilman khil...@ti.com
---
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 char *name, struct resource *res);
diff --git a/arch/arm/plat-omap/omap_device.c
b/arch/arm/plat-omap/omap_device.c
index c490240..fd15a3a 100644
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 -- 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/
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 -- 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/
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, reg-address.device-name, 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 -- 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/
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 -- 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/
