[PATCH 0/2] Add support for am437x StarterKit

[PATCH 0/2] Add support for am437x StarterKit

[Felipe Balbi]

Hi,

The following two patches (one of which is a resend from a patch which has been
pending since May 19th!) enable AM437x StarterKit to boot in mainline.

Patches have been tested on top of 27a4e439fe5cd92b70137ae237c7aa6888c07b5a
(next-20140610). With these we even have X with I3 running on this board, with
audio, touchscreen, networking, blinky leds and others.

Felipe Balbi (1):
  arm: dts: add support for AM437x StarterKit

Sathya Prakash M R (1):
  ARM: AM43xx: hwmod: add DSS hwmod data

 .../devicetree/bindings/arm/omap/omap.txt          |   3 +
 arch/arm/boot/dts/Makefile                         |   1 +
 arch/arm/boot/dts/am437x-sk-evm.dts                | 539 +++++++++++++++++++++
 arch/arm/mach-omap2/omap_hwmod_43xx_data.c         |  98 ++++
 arch/arm/mach-omap2/prcm43xx.h                     |   1 +
 5 files changed, 642 insertions(+)
 create mode 100644 arch/arm/boot/dts/am437x-sk-evm.dts

-- 
2.0.0.rc1

[RESEND PATCH 1/2] ARM: AM43xx: hwmod: add DSS hwmod data

[Felipe Balbi]

From: Sathya Prakash M R <sathyap@ti.com>

Add DSS hwmod data for AM43xx.

Cc: Andrew Morton <akpm@linux-foundation.org>
Acked-by: Rajendra Nayak <rnayak@ti.com>
Signed-off-by: Sathya Prakash M R <sathyap@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
---

Note that this patch was originally send on May 9th [1], changes were requested
and a new version was sent on May 19th [2], then on May 27th [3] Tomi pinged
maintainer again and go no response.

Without this patch, we cannot get display working on any AM437x devices.

[1] http://marc.info/?l=linux-arm-kernel&m=139963677925227&w=2
[2] http://marc.info/?l=linux-arm-kernel&m=140049799425512&w=2
[3] http://marc.info/?l=linux-arm-kernel&m=140117232826754&w=2

 arch/arm/mach-omap2/omap_hwmod_43xx_data.c | 98 ++++++++++++++++++++++++++++++
 arch/arm/mach-omap2/prcm43xx.h             |  1 +
 2 files changed, 99 insertions(+)

diff --git a/arch/arm/mach-omap2/omap_hwmod_43xx_data.c b/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
index 5c2cc80..d2a7b6d 100644
--- a/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
@@ -19,6 +19,8 @@
 #include "omap_hwmod.h"
 #include "omap_hwmod_33xx_43xx_common_data.h"
 #include "prcm43xx.h"
+#include "omap_hwmod_common_data.h"
+
 
 /* IP blocks */
 static struct omap_hwmod am43xx_l4_hs_hwmod = {
@@ -415,6 +417,70 @@ static struct omap_hwmod am43xx_qspi_hwmod = {
 	},
 };
 
+/* Display sub system - DSS */
+
+struct omap_dss_dispc_dev_attr am43xx_dss_dispc_dev_attr = {
+	.manager_count		= 1,
+	.has_framedonetv_irq	= 0
+};
+
+
+static struct omap_hwmod_class_sysconfig am43xx_dispc_sysc = {
+	.rev_offs	= 0x0000,
+	.sysc_offs	= 0x0010,
+	.syss_offs	= 0x0014,
+	.sysc_flags	= (SYSC_HAS_SIDLEMODE | SYSC_HAS_MIDLEMODE),
+	.idlemodes	= (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+	.sysc_fields	= &omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class am43xx_dispc_hwmod_class = {
+	.name	= "dispc",
+	.sysc	= &am43xx_dispc_sysc,
+};
+
+static struct omap_hwmod am43xx_dss_core_hwmod = {
+	.name		= "dss_core",
+	.class		= &omap2_dss_hwmod_class,
+	.clkdm_name	= "dss_clkdm",
+	.main_clk	= "disp_clk",
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = AM43XX_CM_PER_DSS_CLKCTRL_OFFSET,
+			.modulemode   = MODULEMODE_SWCTRL,
+		},
+	},
+};
+
+/* display controller -dispc*/
+
+static struct omap_hwmod am43xx_dss_dispc_hwmod = {
+	.name		= "dss_dispc",
+	.class		= &am43xx_dispc_hwmod_class,
+	.clkdm_name	= "dss_clkdm",
+	.main_clk	= "disp_clk",
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = AM43XX_CM_PER_DSS_CLKCTRL_OFFSET,
+		},
+	},
+	.dev_attr	= &am43xx_dss_dispc_dev_attr,
+};
+
+/*RFBI*/
+
+static struct omap_hwmod am43xx_dss_rfbi_hwmod = {
+	.name		= "dss_rfbi",
+	.class		= &omap2_rfbi_hwmod_class,
+	.clkdm_name	= "dss_clkdm",
+	.main_clk	= "disp_clk",
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = AM43XX_CM_PER_DSS_CLKCTRL_OFFSET,
+		},
+	},
+};
+
 /* Interfaces */
 static struct omap_hwmod_ocp_if am43xx_l3_main__l4_hs = {
 	.master		= &am33xx_l3_main_hwmod,
@@ -654,6 +720,34 @@ static struct omap_hwmod_ocp_if am43xx_l3_s__qspi = {
 	.user           = OCP_USER_MPU | OCP_USER_SDMA,
 };
 
+static struct omap_hwmod_ocp_if am43xx_dss__l3_main = {
+	.master		= &am43xx_dss_core_hwmod,
+	.slave		= &am33xx_l3_main_hwmod,
+	.clk		= "l3_gclk",
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+static struct omap_hwmod_ocp_if am43xx_l4_ls__dss = {
+	.master		= &am33xx_l4_ls_hwmod,
+	.slave		= &am43xx_dss_core_hwmod,
+	.clk		= "l4ls_gclk",
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+static struct omap_hwmod_ocp_if am43xx_l4_ls__dss_dispc = {
+	.master		= &am33xx_l4_ls_hwmod,
+	.slave		= &am43xx_dss_dispc_hwmod,
+	.clk		= "l4ls_gclk",
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+static struct omap_hwmod_ocp_if am43xx_l4_ls__dss_rfbi = {
+	.master		= &am33xx_l4_ls_hwmod,
+	.slave		= &am43xx_dss_rfbi_hwmod,
+	.clk		= "l4ls_gclk",
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
 static struct omap_hwmod_ocp_if *am43xx_hwmod_ocp_ifs[] __initdata = {
 	&am33xx_l4_wkup__synctimer,
 	&am43xx_l4_ls__timer8,
@@ -748,6 +842,10 @@ static struct omap_hwmod_ocp_if *am43xx_hwmod_ocp_ifs[] __initdata = {
 	&am43xx_l4_ls__ocp2scp1,
 	&am43xx_l3_s__usbotgss0,
 	&am43xx_l3_s__usbotgss1,
+	&am43xx_dss__l3_main,
+	&am43xx_l4_ls__dss,
+	&am43xx_l4_ls__dss_dispc,
+	&am43xx_l4_ls__dss_rfbi,
 	NULL,
 };
 
diff --git a/arch/arm/mach-omap2/prcm43xx.h b/arch/arm/mach-omap2/prcm43xx.h
index 7785be9..ad7b3e9 100644
--- a/arch/arm/mach-omap2/prcm43xx.h
+++ b/arch/arm/mach-omap2/prcm43xx.h
@@ -142,5 +142,6 @@
 #define AM43XX_CM_PER_USBPHYOCP2SCP0_CLKCTRL_OFFSET	0x05B8
 #define AM43XX_CM_PER_USB_OTG_SS1_CLKCTRL_OFFSET        0x0268
 #define AM43XX_CM_PER_USBPHYOCP2SCP1_CLKCTRL_OFFSET	0x05C0
+#define AM43XX_CM_PER_DSS_CLKCTRL_OFFSET		0x0a20
 
 #endif
-- 
2.0.0.rc1

Re: [RESEND PATCH 1/2] ARM: AM43xx: hwmod: add DSS hwmod data

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 5451 bytes --]

On Fri, Jun 13, 2014 at 11:15:46AM -0500, Felipe Balbi wrote:
> From: Sathya Prakash M R <sathyap@ti.com>
> 
> Add DSS hwmod data for AM43xx.
> 
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Acked-by: Rajendra Nayak <rnayak@ti.com>
> Signed-off-by: Sathya Prakash M R <sathyap@ti.com>
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
> Signed-off-by: Felipe Balbi <balbi@ti.com>
> ---
> 
> Note that this patch was originally send on May 9th [1], changes were requested
> and a new version was sent on May 19th [2], then on May 27th [3] Tomi pinged
> maintainer again and go no response.
> 
> Without this patch, we cannot get display working on any AM437x devices.
> 
> [1] http://marc.info/?l=linux-arm-kernel&m=139963677925227&w=2
> [2] http://marc.info/?l=linux-arm-kernel&m=140049799425512&w=2
> [3] http://marc.info/?l=linux-arm-kernel&m=140117232826754&w=2
> 
>  arch/arm/mach-omap2/omap_hwmod_43xx_data.c | 98 ++++++++++++++++++++++++++++++
>  arch/arm/mach-omap2/prcm43xx.h             |  1 +
>  2 files changed, 99 insertions(+)
> 
> diff --git a/arch/arm/mach-omap2/omap_hwmod_43xx_data.c b/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
> index 5c2cc80..d2a7b6d 100644
> --- a/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
> +++ b/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
> @@ -19,6 +19,8 @@
>  #include "omap_hwmod.h"
>  #include "omap_hwmod_33xx_43xx_common_data.h"
>  #include "prcm43xx.h"
> +#include "omap_hwmod_common_data.h"
> +
>  
>  /* IP blocks */
>  static struct omap_hwmod am43xx_l4_hs_hwmod = {
> @@ -415,6 +417,70 @@ static struct omap_hwmod am43xx_qspi_hwmod = {
>  	},
>  };
>  
> +/* Display sub system - DSS */
> +
> +struct omap_dss_dispc_dev_attr am43xx_dss_dispc_dev_attr = {
> +	.manager_count		= 1,
> +	.has_framedonetv_irq	= 0
> +};
> +
> +
> +static struct omap_hwmod_class_sysconfig am43xx_dispc_sysc = {
> +	.rev_offs	= 0x0000,
> +	.sysc_offs	= 0x0010,
> +	.syss_offs	= 0x0014,
> +	.sysc_flags	= (SYSC_HAS_SIDLEMODE | SYSC_HAS_MIDLEMODE),
> +	.idlemodes	= (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
> +	.sysc_fields	= &omap_hwmod_sysc_type1,
> +};
> +
> +static struct omap_hwmod_class am43xx_dispc_hwmod_class = {
> +	.name	= "dispc",
> +	.sysc	= &am43xx_dispc_sysc,
> +};
> +
> +static struct omap_hwmod am43xx_dss_core_hwmod = {
> +	.name		= "dss_core",
> +	.class		= &omap2_dss_hwmod_class,
> +	.clkdm_name	= "dss_clkdm",
> +	.main_clk	= "disp_clk",
> +	.prcm = {
> +		.omap4 = {
> +			.clkctrl_offs = AM43XX_CM_PER_DSS_CLKCTRL_OFFSET,
> +			.modulemode   = MODULEMODE_SWCTRL,
> +		},
> +	},
> +};
> +
> +/* display controller -dispc*/
> +
> +static struct omap_hwmod am43xx_dss_dispc_hwmod = {
> +	.name		= "dss_dispc",
> +	.class		= &am43xx_dispc_hwmod_class,
> +	.clkdm_name	= "dss_clkdm",
> +	.main_clk	= "disp_clk",
> +	.prcm = {
> +		.omap4 = {
> +			.clkctrl_offs = AM43XX_CM_PER_DSS_CLKCTRL_OFFSET,
> +		},
> +	},
> +	.dev_attr	= &am43xx_dss_dispc_dev_attr,
> +};
> +
> +/*RFBI*/
> +
> +static struct omap_hwmod am43xx_dss_rfbi_hwmod = {
> +	.name		= "dss_rfbi",
> +	.class		= &omap2_rfbi_hwmod_class,
> +	.clkdm_name	= "dss_clkdm",
> +	.main_clk	= "disp_clk",
> +	.prcm = {
> +		.omap4 = {
> +			.clkctrl_offs = AM43XX_CM_PER_DSS_CLKCTRL_OFFSET,
> +		},
> +	},
> +};
> +
>  /* Interfaces */
>  static struct omap_hwmod_ocp_if am43xx_l3_main__l4_hs = {
>  	.master		= &am33xx_l3_main_hwmod,
> @@ -654,6 +720,34 @@ static struct omap_hwmod_ocp_if am43xx_l3_s__qspi = {
>  	.user           = OCP_USER_MPU | OCP_USER_SDMA,
>  };
>  
> +static struct omap_hwmod_ocp_if am43xx_dss__l3_main = {
> +	.master		= &am43xx_dss_core_hwmod,
> +	.slave		= &am33xx_l3_main_hwmod,
> +	.clk		= "l3_gclk",
> +	.user		= OCP_USER_MPU | OCP_USER_SDMA,
> +};
> +
> +static struct omap_hwmod_ocp_if am43xx_l4_ls__dss = {
> +	.master		= &am33xx_l4_ls_hwmod,
> +	.slave		= &am43xx_dss_core_hwmod,
> +	.clk		= "l4ls_gclk",
> +	.user		= OCP_USER_MPU | OCP_USER_SDMA,
> +};
> +
> +static struct omap_hwmod_ocp_if am43xx_l4_ls__dss_dispc = {
> +	.master		= &am33xx_l4_ls_hwmod,
> +	.slave		= &am43xx_dss_dispc_hwmod,
> +	.clk		= "l4ls_gclk",
> +	.user		= OCP_USER_MPU | OCP_USER_SDMA,
> +};
> +
> +static struct omap_hwmod_ocp_if am43xx_l4_ls__dss_rfbi = {
> +	.master		= &am33xx_l4_ls_hwmod,
> +	.slave		= &am43xx_dss_rfbi_hwmod,
> +	.clk		= "l4ls_gclk",
> +	.user		= OCP_USER_MPU | OCP_USER_SDMA,
> +};
> +
>  static struct omap_hwmod_ocp_if *am43xx_hwmod_ocp_ifs[] __initdata = {
>  	&am33xx_l4_wkup__synctimer,
>  	&am43xx_l4_ls__timer8,
> @@ -748,6 +842,10 @@ static struct omap_hwmod_ocp_if *am43xx_hwmod_ocp_ifs[] __initdata = {
>  	&am43xx_l4_ls__ocp2scp1,
>  	&am43xx_l3_s__usbotgss0,
>  	&am43xx_l3_s__usbotgss1,
> +	&am43xx_dss__l3_main,
> +	&am43xx_l4_ls__dss,
> +	&am43xx_l4_ls__dss_dispc,
> +	&am43xx_l4_ls__dss_rfbi,
>  	NULL,
>  };
>  
> diff --git a/arch/arm/mach-omap2/prcm43xx.h b/arch/arm/mach-omap2/prcm43xx.h
> index 7785be9..ad7b3e9 100644
> --- a/arch/arm/mach-omap2/prcm43xx.h
> +++ b/arch/arm/mach-omap2/prcm43xx.h
> @@ -142,5 +142,6 @@
>  #define AM43XX_CM_PER_USBPHYOCP2SCP0_CLKCTRL_OFFSET	0x05B8
>  #define AM43XX_CM_PER_USB_OTG_SS1_CLKCTRL_OFFSET        0x0268
>  #define AM43XX_CM_PER_USBPHYOCP2SCP1_CLKCTRL_OFFSET	0x05C0
> +#define AM43XX_CM_PER_DSS_CLKCTRL_OFFSET		0x0a20
>  
>  #endif
> -- 
> 2.0.0.rc1
> 

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [RESEND PATCH 1/2] ARM: AM43xx: hwmod: add DSS hwmod data

[Paul Walmsley]

Hi Felipe, Tomi,

On Fri, 13 Jun 2014, Felipe Balbi wrote:

> On Fri, Jun 13, 2014 at 11:15:46AM -0500, Felipe Balbi wrote:
> > From: Sathya Prakash M R <sathyap@ti.com>
> > 
> > Add DSS hwmod data for AM43xx.
> > 
> > Cc: Andrew Morton <akpm@linux-foundation.org>
> > Acked-by: Rajendra Nayak <rnayak@ti.com>
> > Signed-off-by: Sathya Prakash M R <sathyap@ti.com>
> > Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
> > Signed-off-by: Felipe Balbi <balbi@ti.com>
> > ---
> > 
> > Note that this patch was originally send on May 9th [1], changes were requested
> > and a new version was sent on May 19th [2], then on May 27th [3] Tomi pinged
> > maintainer again and go no response.
> > 
> > Without this patch, we cannot get display working on any AM437x devices.
> > 
> > [1] http://marc.info/?l=linux-arm-kernel&m=139963677925227&w=2
> > [2] http://marc.info/?l=linux-arm-kernel&m=140049799425512&w=2
> > [3] http://marc.info/?l=linux-arm-kernel&m=140117232826754&w=2
> > 
> >  arch/arm/mach-omap2/omap_hwmod_43xx_data.c | 98 ++++++++++++++++++++++++++++++
> >  arch/arm/mach-omap2/prcm43xx.h             |  1 +
> >  2 files changed, 99 insertions(+)

Sorry for the delay on this.  Have been corresponding with TI management 
to figure out what to do about patches for AM43xx.  I don't have boards or 
public documentation for these devices, so it's impossible for me to 
meaningfully review the patches.  Looks like boards and/or public docs 
won't be coming any time soon.

So for my part, here's what I'll need to merge any hwmod or PRCM patches 
that involve AM437x:

1. A Reviewed-by: from one of the following folks (which should come from
a different person than who is submitting the patches):

Roger Quadros
Nishanth Menon
Rajendra Nayak
Kevin Hilman
Tony Lindgren

2. A Tested-by: from one of the following folks (who can be the same as 
the person who is the same as the person who is submitting the patches):

Nishanth Menon
Rajendra Nayak
Kevin Hilman 
Tony Lindgren


- Paul

Re: [RESEND PATCH 1/2] ARM: AM43xx: hwmod: add DSS hwmod data

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 3865 bytes --]

Hi,

On Fri, Jun 13, 2014 at 07:11:58PM +0000, Paul Walmsley wrote:
> > > From: Sathya Prakash M R <sathyap@ti.com>
> > > 
> > > Add DSS hwmod data for AM43xx.
> > > 
> > > Cc: Andrew Morton <akpm@linux-foundation.org>
> > > Acked-by: Rajendra Nayak <rnayak@ti.com>
> > > Signed-off-by: Sathya Prakash M R <sathyap@ti.com>
> > > Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
> > > Signed-off-by: Felipe Balbi <balbi@ti.com>
> > > ---
> > > 
> > > Note that this patch was originally send on May 9th [1], changes were requested
> > > and a new version was sent on May 19th [2], then on May 27th [3] Tomi pinged
> > > maintainer again and go no response.
> > > 
> > > Without this patch, we cannot get display working on any AM437x devices.
> > > 
> > > [1] http://marc.info/?l=linux-arm-kernel&m=139963677925227&w=2
> > > [2] http://marc.info/?l=linux-arm-kernel&m=140049799425512&w=2
> > > [3] http://marc.info/?l=linux-arm-kernel&m=140117232826754&w=2
> > > 
> > >  arch/arm/mach-omap2/omap_hwmod_43xx_data.c | 98 ++++++++++++++++++++++++++++++
> > >  arch/arm/mach-omap2/prcm43xx.h             |  1 +
> > >  2 files changed, 99 insertions(+)
> 
> Sorry for the delay on this.  Have been corresponding with TI management 
> to figure out what to do about patches for AM43xx.  I don't have boards or 
> public documentation for these devices, so it's impossible for me to 
> meaningfully review the patches.  Looks like boards and/or public docs 
> won't be coming any time soon.
> 
> So for my part, here's what I'll need to merge any hwmod or PRCM patches 
> that involve AM437x:
> 
> 1. A Reviewed-by: from one of the following folks (which should come from
> a different person than who is submitting the patches):
> 
> Roger Quadros
> Nishanth Menon
> Rajendra Nayak
> Kevin Hilman
> Tony Lindgren
> 
> 2. A Tested-by: from one of the following folks (who can be the same as 
> the person who is the same as the person who is submitting the patches):
> 
> Nishanth Menon
> Rajendra Nayak
> Kevin Hilman 
> Tony Lindgren

What you're saying here is that it's pointless for anybody else in TI to
review and/or test patches because you will only accept such tags from
this list of 4 ~ 5 people. It doesn't take a brain surgeon to note how
this won't scale and, if you continue to ignore patches during the
entire development cycle and only reply after it's too late for $this
merge window, it won't help much.

Quite frankly, it's very upsetting to see an affirmation that all the
work that I (personally) and many others do is seen as "pointless" from
your side *unless* it gets the blessing from the few folks listed above.

This just makes it ever more difficult for anything, which is clearly
*BROKEN* to be fixed upstream and will just contribute to people
vanishing from mainline development.

The very fact that you will only accept patches blessed by the gang-of-4
goes against the very foundations of open source development. Just
because you don't have access to documentation - and granted, that
_does_ make things a lot more difficult - does not mean you have to
consider an entire company as a non-trust worthy organization. Specially
when there are so many here who have been doing mainline development for
quite some time.

Anyway, whatever... I just hope that if we go through *another* merge
window without $subject being merged, someone takes the patch because
this already has a ridiculous amount of bureaucratic bariers to patches
which are, to put it very bluntly, *CORRECT*.

ps: $subject in particular, has been tested by 3 different people.
Actually 4, if you consider Darren Etheridge who used $subject to help
me get display working on AM437x SK.

pps: Darren, can you reply with your (according to Paul) pointless
Tested-by ?

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [RESEND PATCH 1/2] ARM: AM43xx: hwmod: add DSS hwmod data

[Paul Walmsley]

Hi

On Fri, 13 Jun 2014, Felipe Balbi wrote:

> On Fri, Jun 13, 2014 at 07:11:58PM +0000, Paul Walmsley wrote:
> > > > From: Sathya Prakash M R <sathyap@ti.com>
> > > > 
> > > > Add DSS hwmod data for AM43xx.
> > > > 
> > > > Cc: Andrew Morton <akpm@linux-foundation.org>
> > > > Acked-by: Rajendra Nayak <rnayak@ti.com>
> > > > Signed-off-by: Sathya Prakash M R <sathyap@ti.com>
> > > > Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
> > > > Signed-off-by: Felipe Balbi <balbi@ti.com>
> > > > ---
> > > > 
> > > > Note that this patch was originally send on May 9th [1], changes were requested
> > > > and a new version was sent on May 19th [2], then on May 27th [3] Tomi pinged
> > > > maintainer again and go no response.
> > > > 
> > > > Without this patch, we cannot get display working on any AM437x devices.
> > > > 
> > > > [1] http://marc.info/?l=linux-arm-kernel&m=139963677925227&w=2
> > > > [2] http://marc.info/?l=linux-arm-kernel&m=140049799425512&w=2
> > > > [3] http://marc.info/?l=linux-arm-kernel&m=140117232826754&w=2
> > > > 
> > > >  arch/arm/mach-omap2/omap_hwmod_43xx_data.c | 98 ++++++++++++++++++++++++++++++
> > > >  arch/arm/mach-omap2/prcm43xx.h             |  1 +
> > > >  2 files changed, 99 insertions(+)
> > 
> > Sorry for the delay on this.  Have been corresponding with TI management 
> > to figure out what to do about patches for AM43xx.  I don't have boards or 
> > public documentation for these devices, so it's impossible for me to 
> > meaningfully review the patches.  Looks like boards and/or public docs 
> > won't be coming any time soon.
> > 
> > So for my part, here's what I'll need to merge any hwmod or PRCM patches 
> > that involve AM437x:
> > 
> > 1. A Reviewed-by: from one of the following folks (which should come from
> > a different person than who is submitting the patches):
> > 
> > Roger Quadros
> > Nishanth Menon
> > Rajendra Nayak
> > Kevin Hilman
> > Tony Lindgren
> > 
> > 2. A Tested-by: from one of the following folks (who can be the same as 
> > the person who is the same as the person who is submitting the patches):
> > 
> > Nishanth Menon
> > Rajendra Nayak
> > Kevin Hilman 
> > Tony Lindgren
> 
> What you're saying here is that it's pointless for anybody else in TI to
> review and/or test patches because you will only accept such tags from
> this list of 4 ~ 5 people.

That might be how you interpreted the E-mail.  But that's not what was 
written.

For the record, I'm pleased to accept Reviewed-by:s and Tested-by:s from 
anyone.  But, like most maintainers, there are some folks who I think do a 
better job of reviewing and testing hwmod and PRCM patches than others.

The people listed above are a first cut at that list.  I'm certainly happy 
to consider adding others, but the reviewers need:

1. to have experience with those parts of the kernel;

2. to have access to the canonical documentation for AM43xx to review 
against; and

3. to have some kind of track record doing in-depth reviews of patches for 
that subsystem, or writing clean code for that subsystem.


Similarly, for testers, the folks listed above are people who:

1. could actually have AM43xx boards; and

2. who have a history of testing patches against mainline kernels in 
public forums, rather than testing against vendor kernels; and

3. who I think would be mortally embarrassed if a patch was broken 
that they had a Tested-by: for.

(N.B. In the case of anything involving DSS, such as this patch, I'd be 
happy to accept Tested-by:s from Archit or Tomi.)

If you have other people that you think I'm missing from the above two 
lists, who meet those requirements, please suggest some names!

> Quite frankly, it's very upsetting to see an affirmation that all the
> work that I (personally) and many others do is seen as "pointless" from
> your side *unless* it gets the blessing from the few folks listed above.

I'd be curious to know how many of the people listed in the Signed-off-by: 
for these patches have double-checked the data against the TRM (or 
whatever documentation is canonical for this chip).  And have thought 
through whether the data actually makes sense with regards to the SoC 
integration.  I consider those to be the prerequisites for reviewing hwmod 
device data patches.  That's what I generally do myself, and that's what I 
expect from trusted reviewers.

> This just makes it ever more difficult for anything, which is clearly
> *BROKEN* to be fixed upstream and will just contribute to people
> vanishing from mainline development.

Sounds like you might be mixing mailing list threads.  

The description for these patches states:

"Add DSS hwmod data for AM43xx"

Unless I'm missing something, these patches add a feature.  They are not 
fixing something that is broken.

> The very fact that you will only accept patches blessed by the gang-of-4
> goes against the very foundations of open source development. Just
> because you don't have access to documentation - and granted, that
> _does_ make things a lot more difficult - does not mean you have to
> consider an entire company as a non-trust worthy organization. Specially
> when there are so many here who have been doing mainline development for
> quite some time.

As stated, I'm happy to consider adding more folks to the list, but they 
need to have a track record of doing good work in that area, or doing 
in-depth reviews.  If they don't have one yet, well, there's no better 
time to start than the present.

I'm also happy to do the reviews and a basic test myself, if I have 
documentation and a board.

> It doesn't take a brain surgeon to note how this won't scale and, if you 
> continue to ignore patches during the entire development cycle and only 
> reply after it's too late for $this merge window, it won't help much.

...

> Anyway, whatever... I just hope that if we go through *another* merge
> window without $subject being merged

What is this business about "*another* merge window" and "continue to 
ignore"?  Using the dates from your own E-mail message above, the original 
patches were sent May 9th.  This was the same day that v3.15-rc5 was 
released. According to your message, the revised patches were sent May 
19th - three days before v3.15-rc6.

So by the time these patches were ready to go, we'd already reached the 
cutoff point for getting anything merged into v3.16.

I was rather hoping that I'd be able to review it against the AM43xx 
documentation in time, but that turned out not to be available.

If all this has nothing to do with the $SUBJECT patches, and is about the 
DSS clocking issue, and not these patches, that's fine; but please direct 
your flames to that thread instead.

> ps: $subject in particular, has been tested by 3 different people.
> Actually 4, if you consider Darren Etheridge who used $subject to help
> me get display working on AM437x SK.

There are no Tested-by:s on this patch.  It seems likely to me that Tomi 
has tested it against something close to mainline, just based on general 
experience with his level of patch quality in the past, but in general, I 
have no way of knowing this.

So if folks actually tested it against mainline, please do send 
Tested-by:s, and note the mainline commit that it was tested on, along 
with other patches were needed for this patch to apply and/or work.  It's 
also helpful to include a serial console boot log to a Tested-by: message.  
That adds confidence that the patches don't add extra warnings and that 
the commit ID is what's expected.

...

For the specific case of this patch, since it's already been reviewed by 
Rajendra, once there are good Tested-by:s sent to the list, I'd say it's 
ready to merge.


- Paul

Re: [RESEND PATCH 1/2] ARM: AM43xx: hwmod: add DSS hwmod data

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 11961 bytes --]

Hi,

On Sat, Jun 14, 2014 at 02:57:32AM +0000, Paul Walmsley wrote:
> > > > > From: Sathya Prakash M R <sathyap@ti.com>
> > > > > 
> > > > > Add DSS hwmod data for AM43xx.
> > > > > 
> > > > > Cc: Andrew Morton <akpm@linux-foundation.org>
> > > > > Acked-by: Rajendra Nayak <rnayak@ti.com>
> > > > > Signed-off-by: Sathya Prakash M R <sathyap@ti.com>
> > > > > Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
> > > > > Signed-off-by: Felipe Balbi <balbi@ti.com>
> > > > > ---
> > > > > 
> > > > > Note that this patch was originally send on May 9th [1], changes were requested
> > > > > and a new version was sent on May 19th [2], then on May 27th [3] Tomi pinged
> > > > > maintainer again and go no response.
> > > > > 
> > > > > Without this patch, we cannot get display working on any AM437x devices.
> > > > > 
> > > > > [1] http://marc.info/?l=linux-arm-kernel&m=139963677925227&w=2
> > > > > [2] http://marc.info/?l=linux-arm-kernel&m=140049799425512&w=2
> > > > > [3] http://marc.info/?l=linux-arm-kernel&m=140117232826754&w=2
> > > > > 
> > > > >  arch/arm/mach-omap2/omap_hwmod_43xx_data.c | 98 ++++++++++++++++++++++++++++++
> > > > >  arch/arm/mach-omap2/prcm43xx.h             |  1 +
> > > > >  2 files changed, 99 insertions(+)
> > > 
> > > Sorry for the delay on this.  Have been corresponding with TI management 
> > > to figure out what to do about patches for AM43xx.  I don't have boards or 
> > > public documentation for these devices, so it's impossible for me to 
> > > meaningfully review the patches.  Looks like boards and/or public docs 
> > > won't be coming any time soon.
> > > 
> > > So for my part, here's what I'll need to merge any hwmod or PRCM patches 
> > > that involve AM437x:
> > > 
> > > 1. A Reviewed-by: from one of the following folks (which should come from
> > > a different person than who is submitting the patches):
> > > 
> > > Roger Quadros
> > > Nishanth Menon
> > > Rajendra Nayak
> > > Kevin Hilman
> > > Tony Lindgren
> > > 
> > > 2. A Tested-by: from one of the following folks (who can be the same as 
> > > the person who is the same as the person who is submitting the patches):
> > > 
> > > Nishanth Menon
> > > Rajendra Nayak
> > > Kevin Hilman 
> > > Tony Lindgren
> > 
> > What you're saying here is that it's pointless for anybody else in TI to
> > review and/or test patches because you will only accept such tags from
> > this list of 4 ~ 5 people.
> 
> That might be how you interpreted the E-mail.  But that's not what was 
> written.

of course it was. Read what you wrote:

"here's what I'll need to *merge* any hwmod or PRCM patches that involve
AM437x".

That basically puts down the requirements to getting any patches
accepted and those requirements are the blessings of a handful.

> For the record, I'm pleased to accept Reviewed-by:s and Tested-by:s from 
> anyone.  But, like most maintainers, there are some folks who I think do a 
> better job of reviewing and testing hwmod and PRCM patches than others.
> 
> The people listed above are a first cut at that list.  I'm certainly
> happy to consider adding others, but the reviewers need:
> 
> 1. to have experience with those parts of the kernel;
> 
> 2. to have access to the canonical documentation for AM43xx to review
> against; and

anybody in ti.com have access to those.

> 3. to have some kind of track record doing in-depth reviews of patches
> for that subsystem, or writing clean code for that subsystem.
> 
> 
> Similarly, for testers, the folks listed above are people who:
> 
> 1. could actually have AM43xx boards; and

well, quite a few have rather easy access to multiple (3, to be exact)
different am437x platforms.

> 2. who have a history of testing patches against mainline kernels in 
> public forums, rather than testing against vendor kernels; and

$subject and patch two have both been tested on top of linux next from
june 10th. Is that bleeding edge enough for you ? Moreover, *only* these
two patches were applied on top of Stephen's linux-next.

> 3. who I think would be mortally embarrassed if a patch was broken 
> that they had a Tested-by: for.

right, and when those guys try to get bugs fixed, we spend half a year
discussing pointless might-happen-when-the-sun-dies problems with other
drivers even when... aaaah what the heck, you'll just say I'm mixing
threads again...

The point is that it has been this back and forth for quite a while now,
in countless occasions we have missed merge windows because this or that
maintainer just stops responding and *nobody* else has balls to pick the
patch up.

Weeks later social network posts start to arise blaming TI for not
sending patches upstream.

> (N.B. In the case of anything involving DSS, such as this patch, I'd be 
> happy to accept Tested-by:s from Archit or Tomi.)
> 
> If you have other people that you think I'm missing from the above two 
> lists, who meet those requirements, please suggest some names!

the point is about not having a list. Sure, you need to know some folks
who you can trust, but sometimes, when it's clear that the patch doesn't
break anything, follows standard code practices, have passed through
more than one hand and soaked in the mailing list for months, it's time
to give up and just let the patch sit in linux-next for a while. You can
always revert if someone else starts to scream.

I'm *not* saying that you should blindly accept anything, but not
accepting patches without a reason isn't fair.

> > Quite frankly, it's very upsetting to see an affirmation that all the
> > work that I (personally) and many others do is seen as "pointless" from
> > your side *unless* it gets the blessing from the few folks listed above.
> 
> I'd be curious to know how many of the people listed in the Signed-off-by: 
> for these patches have double-checked the data against the TRM (or 

I know I've done it. Have latest am437x Datasheed, TRM and board
schematics open for quite a while now as I've been hacking this am437x
StarterKit.

Also, the thing is functional. Xorg + i3 runs just fine without any
glitches or bogus colors, or any sort of warnings, errors, anything at
all.

> whatever documentation is canonical for this chip).  And have thought 
> through whether the data actually makes sense with regards to the SoC 
> integration.  I consider those to be the prerequisites for reviewing hwmod 

how else would we get the freaking thing to enable clocks ? Or are you
forgetting that long ago the entire OMAP architecture was made tightly
coupled with runtime PM and HWMOD; and are you also forgetting that no
driver is now allowed to call clk_get() directly without hurting
somebody's feelings ?

With these details in mind, there's no SoC who depends on mach-omap2
that can have any chance of *working* without hwmod data.

> device data patches.  That's what I generally do myself, and that's what I 
> expect from trusted reviewers.

alright, so do you see any problems with the patch ? Do you think the
data isn't necessary ? Instead of just being silent for months, why
don't you just drop a line ? Reply to the f-ing thread ? How can we make
any progress if you don't ? Is this what we have to go now ? Send a
patch and hopefully, some day, it will make its way to mainline ?

> > This just makes it ever more difficult for anything, which is clearly
> > *BROKEN* to be fixed upstream and will just contribute to people
> > vanishing from mainline development.
> 
> Sounds like you might be mixing mailing list threads.  
> 
> The description for these patches states:
> 
> "Add DSS hwmod data for AM43xx"
> 
> Unless I'm missing something, these patches add a feature.  They are not 
> fixing something that is broken.

without DSS hwmod data, how can display work ? So it _is_ broken indeed.
The same DSS code is functional in many other SoCs, but it's *broken* in
am437x because $subject has been pending without *any* reply since
May 19th.

> > The very fact that you will only accept patches blessed by the gang-of-4
> > goes against the very foundations of open source development. Just
> > because you don't have access to documentation - and granted, that
> > _does_ make things a lot more difficult - does not mean you have to
> > consider an entire company as a non-trust worthy organization. Specially
> > when there are so many here who have been doing mainline development for
> > quite some time.
> 
> As stated, I'm happy to consider adding more folks to the list, but they 
> need to have a track record of doing good work in that area, or doing 
> in-depth reviews.  If they don't have one yet, well, there's no better 
> time to start than the present.
> 
> I'm also happy to do the reviews and a basic test myself, if I have 
> documentation and a board.
> 
> > It doesn't take a brain surgeon to note how this won't scale and, if you 
> > continue to ignore patches during the entire development cycle and only 
> > reply after it's too late for $this merge window, it won't help much.
> 
> ...
> 
> > Anyway, whatever... I just hope that if we go through *another* merge
> > window without $subject being merged
> 
> What is this business about "*another* merge window" and "continue to 
> ignore"?  Using the dates from your own E-mail message above, the original 
> patches were sent May 9th.  This was the same day that v3.15-rc5 was 
> released. According to your message, the revised patches were sent May 
> 19th - three days before v3.15-rc6.

right, right.. I'm talking in general. This *could* have made it into
v3.16. There are also other patches which were missed. One of them since
january.

> So by the time these patches were ready to go, we'd already reached the 
> cutoff point for getting anything merged into v3.16.

not really. We had 3 more tags (3 more weeks) until v3.15 final was
tagged. Add to that the fact that the merge window is 2 weeks long, 4
weeks (leaving the last week as padding) seems like enough time.

> I was rather hoping that I'd be able to review it against the AM43xx 
> documentation in time, but that turned out not to be available.
> 
> If all this has nothing to do with the $SUBJECT patches, and is about the 
> DSS clocking issue, and not these patches, that's fine; but please direct 
> your flames to that thread instead.
> 
> > ps: $subject in particular, has been tested by 3 different people.
> > Actually 4, if you consider Darren Etheridge who used $subject to help
> > me get display working on AM437x SK.
> 
> There are no Tested-by:s on this patch.  It seems likely to me that Tomi 
> has tested it against something close to mainline, just based on general 
> experience with his level of patch quality in the past, but in general, I 
> have no way of knowing this.

SoB usually means the patch was tested by that person. Or are you
implying that neither me nor Sathya (patch author!!) ever tested the
patch ? I can post a video on youtube if that makes you happy, but boy
do I want to avoid doing that...

> So if folks actually tested it against mainline, please do send 
> Tested-by:s, and note the mainline commit that it was tested on, along 
> with other patches were needed for this patch to apply and/or work.  It's 
> also helpful to include a serial console boot log to a Tested-by: message.  
> That adds confidence that the patches don't add extra warnings and that 
> the commit ID is what's expected.

sure thing, but don't expect everybody to just figure out what's going
on inside your head. Silent gets us nowhere.

> For the specific case of this patch, since it's already been reviewed by 
> Rajendra, once there are good Tested-by:s sent to the list, I'd say it's 
> ready to merge.

good Tested-by:s ?

nice

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [RESEND PATCH 1/2] ARM: AM43xx: hwmod: add DSS hwmod data

[Paul Walmsley]

Hi,

On Fri, 13 Jun 2014, Felipe Balbi wrote:

> On Sat, Jun 14, 2014 at 02:57:32AM +0000, Paul Walmsley wrote:
> > > > > > From: Sathya Prakash M R <sathyap@ti.com>
> > > > > > 
> > > > > > Add DSS hwmod data for AM43xx.
> > > > > > 
> > > > > > Cc: Andrew Morton <akpm@linux-foundation.org>
> > > > > > Acked-by: Rajendra Nayak <rnayak@ti.com>
> > > > > > Signed-off-by: Sathya Prakash M R <sathyap@ti.com>
> > > > > > Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
> > > > > > Signed-off-by: Felipe Balbi <balbi@ti.com>
> > > > > > ---
> > > > > > 
> > > > > > Note that this patch was originally send on May 9th [1], changes were requested
> > > > > > and a new version was sent on May 19th [2], then on May 27th [3] Tomi pinged
> > > > > > maintainer again and go no response.
> > > > > > 
> > > > > > Without this patch, we cannot get display working on any AM437x devices.
> > > > > > 
> > > > > > [1] http://marc.info/?l=linux-arm-kernel&m=139963677925227&w=2
> > > > > > [2] http://marc.info/?l=linux-arm-kernel&m=140049799425512&w=2
> > > > > > [3] http://marc.info/?l=linux-arm-kernel&m=140117232826754&w=2
> > > > > > 
> > > > > >  arch/arm/mach-omap2/omap_hwmod_43xx_data.c | 98 ++++++++++++++++++++++++++++++
> > > > > >  arch/arm/mach-omap2/prcm43xx.h             |  1 +
> > > > > >  2 files changed, 99 insertions(+)
> > > > 
> > > > Sorry for the delay on this.  Have been corresponding with TI management 
> > > > to figure out what to do about patches for AM43xx.  I don't have boards or 
> > > > public documentation for these devices, so it's impossible for me to 
> > > > meaningfully review the patches.  Looks like boards and/or public docs 
> > > > won't be coming any time soon.
> > > > 
> > > > So for my part, here's what I'll need to merge any hwmod or PRCM patches 
> > > > that involve AM437x:
> > > > 
> > > > 1. A Reviewed-by: from one of the following folks (which should come from
> > > > a different person than who is submitting the patches):
> > > > 
> > > > Roger Quadros
> > > > Nishanth Menon
> > > > Rajendra Nayak
> > > > Kevin Hilman
> > > > Tony Lindgren
> > > > 
> > > > 2. A Tested-by: from one of the following folks (who can be the same as 
> > > > the person who is the same as the person who is submitting the patches):
> > > > 
> > > > Nishanth Menon
> > > > Rajendra Nayak
> > > > Kevin Hilman 
> > > > Tony Lindgren
> > > 
> > > What you're saying here is that it's pointless for anybody else in TI to
> > > review and/or test patches because you will only accept such tags from
> > > this list of 4 ~ 5 people.
> > 
> > That might be how you interpreted the E-mail.  But that's not what was 
> > written.
> 
> of course it was. Read what you wrote:
> 
> "here's what I'll need to *merge* any hwmod or PRCM patches that involve
> AM437x".
> 
> That basically puts down the requirements to getting any patches
> accepted and those requirements are the blessings of a handful.
> 
> > For the record, I'm pleased to accept Reviewed-by:s and Tested-by:s from 
> > anyone.  But, like most maintainers, there are some folks who I think do a 
> > better job of reviewing and testing hwmod and PRCM patches than others.
> > 
> > The people listed above are a first cut at that list.  I'm certainly
> > happy to consider adding others, but the reviewers need:
> > 
> > 1. to have experience with those parts of the kernel;
> > 
> > 2. to have access to the canonical documentation for AM43xx to review
> > against; and
> 
> anybody in ti.com have access to those.
> 
> > 3. to have some kind of track record doing in-depth reviews of patches
> > for that subsystem, or writing clean code for that subsystem.
> > 
> > 
> > Similarly, for testers, the folks listed above are people who:
> > 
> > 1. could actually have AM43xx boards; and
> 
> well, quite a few have rather easy access to multiple (3, to be exact)
> different am437x platforms.
> 
> > 2. who have a history of testing patches against mainline kernels in 
> > public forums, rather than testing against vendor kernels; and
> 
> $subject and patch two have both been tested on top of linux next from
> june 10th. Is that bleeding edge enough for you ? Moreover, *only* these
> two patches were applied on top of Stephen's linux-next.
> 
> > 3. who I think would be mortally embarrassed if a patch was broken 
> > that they had a Tested-by: for.
> 
> right, and when those guys try to get bugs fixed, we spend half a year
> discussing pointless might-happen-when-the-sun-dies problems with other
> drivers even when... aaaah what the heck, you'll just say I'm mixing
> threads again...
> 
> The point is that it has been this back and forth for quite a while now,
> in countless occasions we have missed merge windows because this or that
> maintainer just stops responding and *nobody* else has balls to pick the
> patch up.
> 
> Weeks later social network posts start to arise blaming TI for not
> sending patches upstream.
> 
> > (N.B. In the case of anything involving DSS, such as this patch, I'd be 
> > happy to accept Tested-by:s from Archit or Tomi.)
> > 
> > If you have other people that you think I'm missing from the above two 
> > lists, who meet those requirements, please suggest some names!
> 
> the point is about not having a list. Sure, you need to know some folks
> who you can trust, but sometimes, when it's clear that the patch doesn't
> break anything, follows standard code practices, have passed through
> more than one hand and soaked in the mailing list for months, it's time
> to give up and just let the patch sit in linux-next for a while. You can
> always revert if someone else starts to scream.
> 
> I'm *not* saying that you should blindly accept anything, but not
> accepting patches without a reason isn't fair.
> 
> > > Quite frankly, it's very upsetting to see an affirmation that all the
> > > work that I (personally) and many others do is seen as "pointless" from
> > > your side *unless* it gets the blessing from the few folks listed above.
> > 
> > I'd be curious to know how many of the people listed in the Signed-off-by: 
> > for these patches have double-checked the data against the TRM (or 
> 
> I know I've done it. Have latest am437x Datasheed, TRM and board
> schematics open for quite a while now as I've been hacking this am437x
> StarterKit.
> 
> Also, the thing is functional. Xorg + i3 runs just fine without any
> glitches or bogus colors, or any sort of warnings, errors, anything at
> all.
> 
> > whatever documentation is canonical for this chip).  And have thought 
> > through whether the data actually makes sense with regards to the SoC 
> > integration.  I consider those to be the prerequisites for reviewing hwmod 
> 
> how else would we get the freaking thing to enable clocks ? Or are you
> forgetting that long ago the entire OMAP architecture was made tightly
> coupled with runtime PM and HWMOD; and are you also forgetting that no
> driver is now allowed to call clk_get() directly without hurting
> somebody's feelings ?
> 
> With these details in mind, there's no SoC who depends on mach-omap2
> that can have any chance of *working* without hwmod data.
> 
> > device data patches.  That's what I generally do myself, and that's what I 
> > expect from trusted reviewers.
> 
> alright, so do you see any problems with the patch ? Do you think the
> data isn't necessary ? Instead of just being silent for months, why
> don't you just drop a line ? Reply to the f-ing thread ? How can we make
> any progress if you don't ? Is this what we have to go now ? Send a
> patch and hopefully, some day, it will make its way to mainline ?
> 
> > > This just makes it ever more difficult for anything, which is clearly
> > > *BROKEN* to be fixed upstream and will just contribute to people
> > > vanishing from mainline development.
> > 
> > Sounds like you might be mixing mailing list threads.  
> > 
> > The description for these patches states:
> > 
> > "Add DSS hwmod data for AM43xx"
> > 
> > Unless I'm missing something, these patches add a feature.  They are not 
> > fixing something that is broken.
> 
> without DSS hwmod data, how can display work ? So it _is_ broken indeed.
> The same DSS code is functional in many other SoCs, but it's *broken* in
> am437x because $subject has been pending without *any* reply since
> May 19th.
> 
> > > The very fact that you will only accept patches blessed by the gang-of-4
> > > goes against the very foundations of open source development. Just
> > > because you don't have access to documentation - and granted, that
> > > _does_ make things a lot more difficult - does not mean you have to
> > > consider an entire company as a non-trust worthy organization. Specially
> > > when there are so many here who have been doing mainline development for
> > > quite some time.
> > 
> > As stated, I'm happy to consider adding more folks to the list, but they 
> > need to have a track record of doing good work in that area, or doing 
> > in-depth reviews.  If they don't have one yet, well, there's no better 
> > time to start than the present.
> > 
> > I'm also happy to do the reviews and a basic test myself, if I have 
> > documentation and a board.
> > 
> > > It doesn't take a brain surgeon to note how this won't scale and, if you 
> > > continue to ignore patches during the entire development cycle and only 
> > > reply after it's too late for $this merge window, it won't help much.
> > 
> > ...
> > 
> > > Anyway, whatever... I just hope that if we go through *another* merge
> > > window without $subject being merged
> > 
> > What is this business about "*another* merge window" and "continue to 
> > ignore"?  Using the dates from your own E-mail message above, the original 
> > patches were sent May 9th.  This was the same day that v3.15-rc5 was 
> > released. According to your message, the revised patches were sent May 
> > 19th - three days before v3.15-rc6.
> 
> right, right.. I'm talking in general. This *could* have made it into
> v3.16. There are also other patches which were missed. One of them since
> january.
> 
> > So by the time these patches were ready to go, we'd already reached the 
> > cutoff point for getting anything merged into v3.16.
> 
> not really. We had 3 more tags (3 more weeks) until v3.15 final was
> tagged. Add to that the fact that the merge window is 2 weeks long, 4
> weeks (leaving the last week as padding) seems like enough time.
> 
> > I was rather hoping that I'd be able to review it against the AM43xx 
> > documentation in time, but that turned out not to be available.
> > 
> > If all this has nothing to do with the $SUBJECT patches, and is about the 
> > DSS clocking issue, and not these patches, that's fine; but please direct 
> > your flames to that thread instead.
> > 
> > > ps: $subject in particular, has been tested by 3 different people.
> > > Actually 4, if you consider Darren Etheridge who used $subject to help
> > > me get display working on AM437x SK.
> > 
> > There are no Tested-by:s on this patch.  It seems likely to me that Tomi 
> > has tested it against something close to mainline, just based on general 
> > experience with his level of patch quality in the past, but in general, I 
> > have no way of knowing this.
> 
> SoB usually means the patch was tested by that person. Or are you
> implying that neither me nor Sathya (patch author!!) ever tested the
> patch ? I can post a video on youtube if that makes you happy, but boy
> do I want to avoid doing that...
> 
> > So if folks actually tested it against mainline, please do send 
> > Tested-by:s, and note the mainline commit that it was tested on, along 
> > with other patches were needed for this patch to apply and/or work.  It's 
> > also helpful to include a serial console boot log to a Tested-by: message.  
> > That adds confidence that the patches don't add extra warnings and that 
> > the commit ID is what's expected.
> 
> sure thing, but don't expect everybody to just figure out what's going
> on inside your head. Silent gets us nowhere.
> 
> > For the specific case of this patch, since it's already been reviewed by 
> > Rajendra, once there are good Tested-by:s sent to the list, I'd say it's 
> > ready to merge.
> 
> good Tested-by:s ?
> 
> nice

Felipe, here's what I need:

For boards that I don't have access to, that I don't have 
documentation for, such as the AM43xx and DRA7xx), for me to merge or ack 
SoC infrastructure or PM-related patches, I want to have:

1. a Reviewed-by: from people who:

a. I think know something about SoC integration or PM in general, and 
about OMAP-style integration specifically; and

b. who have a track record of doing strong and detailed reviews of that 
code, or who have contributed significantly to that code in the past.

My initial list of those reviewers is listed above, and I am happy to 
consider extending it or modifying that list.


2. confidence that the patch or series has been tested against a mainline 
commit and isn't obviously breaking other things, like PM, and confidence 
that it's not adding new runtime warnings.

I've listed an initial set of people above who I feel have proven track 
records in testing who I'm happy to accept Tested-by:s without further 
explanation.  I'm sure I've missed some folks and if anyone who should be 
on that list is offended that I didn't mention them, please accept my 
apologies.  For other folks, like yourself, who aren't on that list (yet), 
please just specifically state:

a. what mainline commit they've tested the patch against,

b. what other prerequisite patches were needed for the patch to apply,

c. and a cut-and-paste of the serial console boot log from the boot 
portion of the test.

in such a way that myself or someone else can easily doublecheck it. 

And frankly, I'll probably be happy to merge it.

After someone has done these three things a few times, and I gain 
confidence that they're doing the right thing, I'm happy to add them to 
my list.

The testing doesn't have to be expressed via a Tested-by: tag in cases 
where you're testing as part of a Signed-off-by:.  Just be sure to state 
those three things above as part of the patch or series message.  The boot 
log can either be placed on a different page and linked to, or sent in 
another public E-mail.

If you can get two or three people to do the above, that's great - the 
more, the better.

...

These two steps do not apply to boards that I have in my testbed or which 
I have documentation for (although they would definitely be very welcome 
in those cases too).

...

Regarding the various other complaints in your E-mail:  if you really 
have a burning desire for me to address any of them, aside from just 
wanting to let off frustration and steam, kindly put them in separate 
public E-mails and make sure that I'm included in the To: line.


regards,

- Paul

Re: [RESEND PATCH 1/2] ARM: AM43xx: hwmod: add DSS hwmod data

[Felipe Balbi]

[-- Attachment #1.1: Type: text/plain, Size: 16757 bytes --]

Hi,

On Sun, Jun 15, 2014 at 03:29:40AM +0000, Paul Walmsley wrote:
> Hi,
> 
> On Fri, 13 Jun 2014, Felipe Balbi wrote:
> 
> > On Sat, Jun 14, 2014 at 02:57:32AM +0000, Paul Walmsley wrote:
> > > > > > > From: Sathya Prakash M R <sathyap@ti.com>
> > > > > > > 
> > > > > > > Add DSS hwmod data for AM43xx.
> > > > > > > 
> > > > > > > Cc: Andrew Morton <akpm@linux-foundation.org>
> > > > > > > Acked-by: Rajendra Nayak <rnayak@ti.com>
> > > > > > > Signed-off-by: Sathya Prakash M R <sathyap@ti.com>
> > > > > > > Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
> > > > > > > Signed-off-by: Felipe Balbi <balbi@ti.com>
> > > > > > > ---
> > > > > > > 
> > > > > > > Note that this patch was originally send on May 9th [1], changes were requested
> > > > > > > and a new version was sent on May 19th [2], then on May 27th [3] Tomi pinged
> > > > > > > maintainer again and go no response.
> > > > > > > 
> > > > > > > Without this patch, we cannot get display working on any AM437x devices.
> > > > > > > 
> > > > > > > [1] http://marc.info/?l=linux-arm-kernel&m=139963677925227&w=2
> > > > > > > [2] http://marc.info/?l=linux-arm-kernel&m=140049799425512&w=2
> > > > > > > [3] http://marc.info/?l=linux-arm-kernel&m=140117232826754&w=2
> > > > > > > 
> > > > > > >  arch/arm/mach-omap2/omap_hwmod_43xx_data.c | 98 ++++++++++++++++++++++++++++++
> > > > > > >  arch/arm/mach-omap2/prcm43xx.h             |  1 +
> > > > > > >  2 files changed, 99 insertions(+)
> > > > > 
> > > > > Sorry for the delay on this.  Have been corresponding with TI management 
> > > > > to figure out what to do about patches for AM43xx.  I don't have boards or 
> > > > > public documentation for these devices, so it's impossible for me to 
> > > > > meaningfully review the patches.  Looks like boards and/or public docs 
> > > > > won't be coming any time soon.
> > > > > 
> > > > > So for my part, here's what I'll need to merge any hwmod or PRCM patches 
> > > > > that involve AM437x:
> > > > > 
> > > > > 1. A Reviewed-by: from one of the following folks (which should come from
> > > > > a different person than who is submitting the patches):
> > > > > 
> > > > > Roger Quadros
> > > > > Nishanth Menon
> > > > > Rajendra Nayak
> > > > > Kevin Hilman
> > > > > Tony Lindgren
> > > > > 
> > > > > 2. A Tested-by: from one of the following folks (who can be the same as 
> > > > > the person who is the same as the person who is submitting the patches):
> > > > > 
> > > > > Nishanth Menon
> > > > > Rajendra Nayak
> > > > > Kevin Hilman 
> > > > > Tony Lindgren
> > > > 
> > > > What you're saying here is that it's pointless for anybody else in TI to
> > > > review and/or test patches because you will only accept such tags from
> > > > this list of 4 ~ 5 people.
> > > 
> > > That might be how you interpreted the E-mail.  But that's not what was 
> > > written.
> > 
> > of course it was. Read what you wrote:
> > 
> > "here's what I'll need to *merge* any hwmod or PRCM patches that involve
> > AM437x".
> > 
> > That basically puts down the requirements to getting any patches
> > accepted and those requirements are the blessings of a handful.
> > 
> > > For the record, I'm pleased to accept Reviewed-by:s and Tested-by:s from 
> > > anyone.  But, like most maintainers, there are some folks who I think do a 
> > > better job of reviewing and testing hwmod and PRCM patches than others.
> > > 
> > > The people listed above are a first cut at that list.  I'm certainly
> > > happy to consider adding others, but the reviewers need:
> > > 
> > > 1. to have experience with those parts of the kernel;
> > > 
> > > 2. to have access to the canonical documentation for AM43xx to review
> > > against; and
> > 
> > anybody in ti.com have access to those.
> > 
> > > 3. to have some kind of track record doing in-depth reviews of patches
> > > for that subsystem, or writing clean code for that subsystem.
> > > 
> > > 
> > > Similarly, for testers, the folks listed above are people who:
> > > 
> > > 1. could actually have AM43xx boards; and
> > 
> > well, quite a few have rather easy access to multiple (3, to be exact)
> > different am437x platforms.
> > 
> > > 2. who have a history of testing patches against mainline kernels in 
> > > public forums, rather than testing against vendor kernels; and
> > 
> > $subject and patch two have both been tested on top of linux next from
> > june 10th. Is that bleeding edge enough for you ? Moreover, *only* these
> > two patches were applied on top of Stephen's linux-next.
> > 
> > > 3. who I think would be mortally embarrassed if a patch was broken 
> > > that they had a Tested-by: for.
> > 
> > right, and when those guys try to get bugs fixed, we spend half a year
> > discussing pointless might-happen-when-the-sun-dies problems with other
> > drivers even when... aaaah what the heck, you'll just say I'm mixing
> > threads again...
> > 
> > The point is that it has been this back and forth for quite a while now,
> > in countless occasions we have missed merge windows because this or that
> > maintainer just stops responding and *nobody* else has balls to pick the
> > patch up.
> > 
> > Weeks later social network posts start to arise blaming TI for not
> > sending patches upstream.
> > 
> > > (N.B. In the case of anything involving DSS, such as this patch, I'd be 
> > > happy to accept Tested-by:s from Archit or Tomi.)
> > > 
> > > If you have other people that you think I'm missing from the above two 
> > > lists, who meet those requirements, please suggest some names!
> > 
> > the point is about not having a list. Sure, you need to know some folks
> > who you can trust, but sometimes, when it's clear that the patch doesn't
> > break anything, follows standard code practices, have passed through
> > more than one hand and soaked in the mailing list for months, it's time
> > to give up and just let the patch sit in linux-next for a while. You can
> > always revert if someone else starts to scream.
> > 
> > I'm *not* saying that you should blindly accept anything, but not
> > accepting patches without a reason isn't fair.
> > 
> > > > Quite frankly, it's very upsetting to see an affirmation that all the
> > > > work that I (personally) and many others do is seen as "pointless" from
> > > > your side *unless* it gets the blessing from the few folks listed above.
> > > 
> > > I'd be curious to know how many of the people listed in the Signed-off-by: 
> > > for these patches have double-checked the data against the TRM (or 
> > 
> > I know I've done it. Have latest am437x Datasheed, TRM and board
> > schematics open for quite a while now as I've been hacking this am437x
> > StarterKit.
> > 
> > Also, the thing is functional. Xorg + i3 runs just fine without any
> > glitches or bogus colors, or any sort of warnings, errors, anything at
> > all.
> > 
> > > whatever documentation is canonical for this chip).  And have thought 
> > > through whether the data actually makes sense with regards to the SoC 
> > > integration.  I consider those to be the prerequisites for reviewing hwmod 
> > 
> > how else would we get the freaking thing to enable clocks ? Or are you
> > forgetting that long ago the entire OMAP architecture was made tightly
> > coupled with runtime PM and HWMOD; and are you also forgetting that no
> > driver is now allowed to call clk_get() directly without hurting
> > somebody's feelings ?
> > 
> > With these details in mind, there's no SoC who depends on mach-omap2
> > that can have any chance of *working* without hwmod data.
> > 
> > > device data patches.  That's what I generally do myself, and that's what I 
> > > expect from trusted reviewers.
> > 
> > alright, so do you see any problems with the patch ? Do you think the
> > data isn't necessary ? Instead of just being silent for months, why
> > don't you just drop a line ? Reply to the f-ing thread ? How can we make
> > any progress if you don't ? Is this what we have to go now ? Send a
> > patch and hopefully, some day, it will make its way to mainline ?
> > 
> > > > This just makes it ever more difficult for anything, which is clearly
> > > > *BROKEN* to be fixed upstream and will just contribute to people
> > > > vanishing from mainline development.
> > > 
> > > Sounds like you might be mixing mailing list threads.  
> > > 
> > > The description for these patches states:
> > > 
> > > "Add DSS hwmod data for AM43xx"
> > > 
> > > Unless I'm missing something, these patches add a feature.  They are not 
> > > fixing something that is broken.
> > 
> > without DSS hwmod data, how can display work ? So it _is_ broken indeed.
> > The same DSS code is functional in many other SoCs, but it's *broken* in
> > am437x because $subject has been pending without *any* reply since
> > May 19th.
> > 
> > > > The very fact that you will only accept patches blessed by the gang-of-4
> > > > goes against the very foundations of open source development. Just
> > > > because you don't have access to documentation - and granted, that
> > > > _does_ make things a lot more difficult - does not mean you have to
> > > > consider an entire company as a non-trust worthy organization. Specially
> > > > when there are so many here who have been doing mainline development for
> > > > quite some time.
> > > 
> > > As stated, I'm happy to consider adding more folks to the list, but they 
> > > need to have a track record of doing good work in that area, or doing 
> > > in-depth reviews.  If they don't have one yet, well, there's no better 
> > > time to start than the present.
> > > 
> > > I'm also happy to do the reviews and a basic test myself, if I have 
> > > documentation and a board.
> > > 
> > > > It doesn't take a brain surgeon to note how this won't scale and, if you 
> > > > continue to ignore patches during the entire development cycle and only 
> > > > reply after it's too late for $this merge window, it won't help much.
> > > 
> > > ...
> > > 
> > > > Anyway, whatever... I just hope that if we go through *another* merge
> > > > window without $subject being merged
> > > 
> > > What is this business about "*another* merge window" and "continue to 
> > > ignore"?  Using the dates from your own E-mail message above, the original 
> > > patches were sent May 9th.  This was the same day that v3.15-rc5 was 
> > > released. According to your message, the revised patches were sent May 
> > > 19th - three days before v3.15-rc6.
> > 
> > right, right.. I'm talking in general. This *could* have made it into
> > v3.16. There are also other patches which were missed. One of them since
> > january.
> > 
> > > So by the time these patches were ready to go, we'd already reached the 
> > > cutoff point for getting anything merged into v3.16.
> > 
> > not really. We had 3 more tags (3 more weeks) until v3.15 final was
> > tagged. Add to that the fact that the merge window is 2 weeks long, 4
> > weeks (leaving the last week as padding) seems like enough time.
> > 
> > > I was rather hoping that I'd be able to review it against the AM43xx 
> > > documentation in time, but that turned out not to be available.
> > > 
> > > If all this has nothing to do with the $SUBJECT patches, and is about the 
> > > DSS clocking issue, and not these patches, that's fine; but please direct 
> > > your flames to that thread instead.
> > > 
> > > > ps: $subject in particular, has been tested by 3 different people.
> > > > Actually 4, if you consider Darren Etheridge who used $subject to help
> > > > me get display working on AM437x SK.
> > > 
> > > There are no Tested-by:s on this patch.  It seems likely to me that Tomi 
> > > has tested it against something close to mainline, just based on general 
> > > experience with his level of patch quality in the past, but in general, I 
> > > have no way of knowing this.
> > 
> > SoB usually means the patch was tested by that person. Or are you
> > implying that neither me nor Sathya (patch author!!) ever tested the
> > patch ? I can post a video on youtube if that makes you happy, but boy
> > do I want to avoid doing that...
> > 
> > > So if folks actually tested it against mainline, please do send 
> > > Tested-by:s, and note the mainline commit that it was tested on, along 
> > > with other patches were needed for this patch to apply and/or work.  It's 
> > > also helpful to include a serial console boot log to a Tested-by: message.  
> > > That adds confidence that the patches don't add extra warnings and that 
> > > the commit ID is what's expected.
> > 
> > sure thing, but don't expect everybody to just figure out what's going
> > on inside your head. Silent gets us nowhere.
> > 
> > > For the specific case of this patch, since it's already been reviewed by 
> > > Rajendra, once there are good Tested-by:s sent to the list, I'd say it's 
> > > ready to merge.
> > 
> > good Tested-by:s ?
> > 
> > nice
> 
> Felipe, here's what I need:
> 
> For boards that I don't have access to, that I don't have 
> documentation for, such as the AM43xx and DRA7xx), for me to merge or ack 
> SoC infrastructure or PM-related patches, I want to have:
> 
> 1. a Reviewed-by: from people who:
> 
> a. I think know something about SoC integration or PM in general, and 
> about OMAP-style integration specifically; and
> 
> b. who have a track record of doing strong and detailed reviews of that 
> code, or who have contributed significantly to that code in the past.
> 
> My initial list of those reviewers is listed above, and I am happy to 
> consider extending it or modifying that list.
> 
> 
> 2. confidence that the patch or series has been tested against a mainline 
> commit and isn't obviously breaking other things, like PM, and confidence 
> that it's not adding new runtime warnings.
> 
> I've listed an initial set of people above who I feel have proven track 
> records in testing who I'm happy to accept Tested-by:s without further 
> explanation.  I'm sure I've missed some folks and if anyone who should be 
> on that list is offended that I didn't mention them, please accept my 
> apologies.  For other folks, like yourself, who aren't on that list (yet), 
> please just specifically state:
> 
> a. what mainline commit they've tested the patch against,

As I said, linux-next from June 10th.

commit 27a4e439fe5cd92b70137ae237c7aa6888c07b5a
Author: Stephen Rothwell <sfr@canb.auug.org.au>
Date:   Tue Jun 10 16:37:52 2014 +1000

    Add linux-next specific files for 20140610
    
    Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>

> b. what other prerequisite patches were needed for the patch to apply,

only these two patches I sent here.

> c. and a cut-and-paste of the serial console boot log from the boot 
> portion of the test.

attached minicom.cap. The "dirty" part is just another set of minor
changes (see below) I'm testing to, hopefully, include in the final DTS
too; and the WARNING you see, was caused by RMK's L2 rework but IIRC
Sekhar already had a fix for it, not sure if it has already reached
next.

diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index 49fa596..e3830d4 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -270,7 +270,7 @@
 			ti,hwmods = "counter_32k";
 		};
 
-		rtc@44e3e000 {
+		rtc: rtc@44e3e000 {
 			compatible = "ti,am4372-rtc","ti,da830-rtc";
 			reg = <0x44e3e000 0x1000>;
 			interrupts = <GIC_SPI 75 IRQ_TYPE_LEVEL_HIGH
@@ -279,7 +279,7 @@
 			status = "disabled";
 		};
 
-		wdt@44e35000 {
+		wdt: wdt@44e35000 {
 			compatible = "ti,am4372-wdt","ti,omap3-wdt";
 			reg = <0x44e35000 0x1000>;
 			interrupts = <GIC_SPI 91 IRQ_TYPE_LEVEL_HIGH>;
diff --git a/arch/arm/boot/dts/am437x-sk-evm.dts b/arch/arm/boot/dts/am437x-sk-evm.dts
index 51ffab1..59b620b 100644
--- a/arch/arm/boot/dts/am437x-sk-evm.dts
+++ b/arch/arm/boot/dts/am437x-sk-evm.dts
@@ -374,6 +374,16 @@
 		DRVDD-supply = <&v33_fixed>;
 		DVDD-supply = <&v18_fixed>;
 	};
+
+	lis331dlh@18 {
+		compatible = "st,lis331dlh";
+		reg = <0x18>;
+		status = "okay";
+
+		Vdd-supply = <&v33_fixed>;
+		Vdd_IO-supply = <&v33_fixed>;
+		interrupts-extended = <&gpio1 6 0>, <&gpio2 1 0>;
+	};
 };
 
 &epwmss0 {
@@ -537,3 +547,23 @@
 		};
 	};
 };
+
+&sham {
+	status = "okay";
+};
+
+&aes {
+	status = "okay";
+};
+
+&des {
+	status = "okay";
+};
+
+&rtc {
+	status = "okay";
+};
+
+&wdt {
+	status = "okay";
+};


-- 
balbi

[-- Attachment #1.2: minicom.cap --]
[-- Type: application/vnd.tcpdump.pcap, Size: 32913 bytes --]

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [RESEND PATCH 1/2] ARM: AM43xx: hwmod: add DSS hwmod data

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 1644 bytes --]

Hi,

On Fri, Jun 13, 2014 at 07:11:58PM +0000, Paul Walmsley wrote:
> Hi Felipe, Tomi,
> 
> On Fri, 13 Jun 2014, Felipe Balbi wrote:
> 
> > On Fri, Jun 13, 2014 at 11:15:46AM -0500, Felipe Balbi wrote:
> > > From: Sathya Prakash M R <sathyap@ti.com>
> > > 
> > > Add DSS hwmod data for AM43xx.
> > > 
> > > Cc: Andrew Morton <akpm@linux-foundation.org>
> > > Acked-by: Rajendra Nayak <rnayak@ti.com>
> > > Signed-off-by: Sathya Prakash M R <sathyap@ti.com>
> > > Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
> > > Signed-off-by: Felipe Balbi <balbi@ti.com>
> > > ---
> > > 
> > > Note that this patch was originally send on May 9th [1], changes were requested
> > > and a new version was sent on May 19th [2], then on May 27th [3] Tomi pinged
> > > maintainer again and go no response.
> > > 
> > > Without this patch, we cannot get display working on any AM437x devices.
> > > 
> > > [1] http://marc.info/?l=linux-arm-kernel&m=139963677925227&w=2
> > > [2] http://marc.info/?l=linux-arm-kernel&m=140049799425512&w=2
> > > [3] http://marc.info/?l=linux-arm-kernel&m=140117232826754&w=2
> > > 
> > >  arch/arm/mach-omap2/omap_hwmod_43xx_data.c | 98 ++++++++++++++++++++++++++++++
> > >  arch/arm/mach-omap2/prcm43xx.h             |  1 +
> > >  2 files changed, 99 insertions(+)
> 
> Sorry for the delay on this.  Have been corresponding with TI management 
> to figure out what to do about patches for AM43xx.  I don't have boards or 
> public documentation for these devices, so it's impossible for me to 

documentation is now available publicly

http://www.ti.com/product/AM4379

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [RESEND PATCH 1/2] ARM: AM43xx: hwmod: add DSS hwmod data

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 2051 bytes --]

On Tue, Jul 01, 2014 at 10:22:49PM -0500, Felipe Balbi wrote:
> Hi,
> 
> On Fri, Jun 13, 2014 at 07:11:58PM +0000, Paul Walmsley wrote:
> > Hi Felipe, Tomi,
> > 
> > On Fri, 13 Jun 2014, Felipe Balbi wrote:
> > 
> > > On Fri, Jun 13, 2014 at 11:15:46AM -0500, Felipe Balbi wrote:
> > > > From: Sathya Prakash M R <sathyap@ti.com>
> > > > 
> > > > Add DSS hwmod data for AM43xx.
> > > > 
> > > > Cc: Andrew Morton <akpm@linux-foundation.org>
> > > > Acked-by: Rajendra Nayak <rnayak@ti.com>
> > > > Signed-off-by: Sathya Prakash M R <sathyap@ti.com>
> > > > Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
> > > > Signed-off-by: Felipe Balbi <balbi@ti.com>
> > > > ---
> > > > 
> > > > Note that this patch was originally send on May 9th [1], changes were requested
> > > > and a new version was sent on May 19th [2], then on May 27th [3] Tomi pinged
> > > > maintainer again and go no response.
> > > > 
> > > > Without this patch, we cannot get display working on any AM437x devices.
> > > > 
> > > > [1] http://marc.info/?l=linux-arm-kernel&m=139963677925227&w=2
> > > > [2] http://marc.info/?l=linux-arm-kernel&m=140049799425512&w=2
> > > > [3] http://marc.info/?l=linux-arm-kernel&m=140117232826754&w=2
> > > > 
> > > >  arch/arm/mach-omap2/omap_hwmod_43xx_data.c | 98 ++++++++++++++++++++++++++++++
> > > >  arch/arm/mach-omap2/prcm43xx.h             |  1 +
> > > >  2 files changed, 99 insertions(+)
> > 
> > Sorry for the delay on this.  Have been corresponding with TI management 
> > to figure out what to do about patches for AM43xx.  I don't have boards or 
> > public documentation for these devices, so it's impossible for me to 
> 
> documentation is now available publicly
> 
> http://www.ti.com/product/AM4379

at [1] you can find most (all?) board-related documentation. [2] will
give you AM437x GP EVM schematics.

[1] http://processors.wiki.ti.com/index.php/AM437X_EVM_Boards
[2] http://processors.wiki.ti.com/images/9/95/Am437x_gp_evm_3k0006_schematic_rev1_4a.pdf

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [RESEND PATCH 1/2] ARM: AM43xx: hwmod: add DSS hwmod data

[Tony Lindgren]

* Felipe Balbi <balbi@ti.com> [140613 09:17]:
> From: Sathya Prakash M R <sathyap@ti.com>
> 
> Add DSS hwmod data for AM43xx.
> 
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Acked-by: Rajendra Nayak <rnayak@ti.com>
> Signed-off-by: Sathya Prakash M R <sathyap@ti.com>
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
> Signed-off-by: Felipe Balbi <balbi@ti.com>
> ---
> 
> Note that this patch was originally send on May 9th [1], changes were requested
> and a new version was sent on May 19th [2], then on May 27th [3] Tomi pinged
> maintainer again and go no response.
> 
> Without this patch, we cannot get display working on any AM437x devices.
> 
> [1] http://marc.info/?l=linux-arm-kernel&m=139963677925227&w=2
> [2] http://marc.info/?l=linux-arm-kernel&m=140049799425512&w=2
> [3] http://marc.info/?l=linux-arm-kernel&m=140117232826754&w=2
> 
>  arch/arm/mach-omap2/omap_hwmod_43xx_data.c | 98 ++++++++++++++++++++++++++++++
>  arch/arm/mach-omap2/prcm43xx.h             |  1 +
>  2 files changed, 99 insertions(+)
> 
> diff --git a/arch/arm/mach-omap2/omap_hwmod_43xx_data.c b/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
> index 5c2cc80..d2a7b6d 100644
> --- a/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
> +++ b/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
> @@ -19,6 +19,8 @@
>  #include "omap_hwmod.h"
>  #include "omap_hwmod_33xx_43xx_common_data.h"
>  #include "prcm43xx.h"
> +#include "omap_hwmod_common_data.h"
> +
>  
>  /* IP blocks */
>  static struct omap_hwmod am43xx_l4_hs_hwmod = {
> @@ -415,6 +417,70 @@ static struct omap_hwmod am43xx_qspi_hwmod = {
>  	},
>  };
>  
> +/* Display sub system - DSS */
> +
> +struct omap_dss_dispc_dev_attr am43xx_dss_dispc_dev_attr = {
> +	.manager_count		= 1,
> +	.has_framedonetv_irq	= 0
> +};
> +
> +
> +static struct omap_hwmod_class_sysconfig am43xx_dispc_sysc = {
> +	.rev_offs	= 0x0000,
> +	.sysc_offs	= 0x0010,
> +	.syss_offs	= 0x0014,
> +	.sysc_flags	= (SYSC_HAS_SIDLEMODE | SYSC_HAS_MIDLEMODE),
> +	.idlemodes	= (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
> +	.sysc_fields	= &omap_hwmod_sysc_type1,
> +};

Looking at the TRM, "Table 13-43. DISPC_SYSCFG Register Field
Descriptions" seems to list the folowing bits available:

13-12	MIDLEMODE 
9-8	CLOCK_ACTIVITY 
4-3	SIDLEMODE 
2	ENWAKEUP 
1	SOFTRESET 
0	AUTOIDLE 

Have I missed something or how come we don't define them all
as available?

The .idlemodes available values and .sysc_fields seems to match
the TRM.

Regards,

Tony

Re: [RESEND PATCH 1/2] ARM: AM43xx: hwmod: add DSS hwmod data

[Tomi Valkeinen]

[-- Attachment #1: Type: text/plain, Size: 3331 bytes --]

On 16/06/14 12:22, Tony Lindgren wrote:
> * Felipe Balbi <balbi@ti.com> [140613 09:17]:
>> From: Sathya Prakash M R <sathyap@ti.com>
>>
>> Add DSS hwmod data for AM43xx.
>>
>> Cc: Andrew Morton <akpm@linux-foundation.org>
>> Acked-by: Rajendra Nayak <rnayak@ti.com>
>> Signed-off-by: Sathya Prakash M R <sathyap@ti.com>
>> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
>> Signed-off-by: Felipe Balbi <balbi@ti.com>
>> ---
>>
>> Note that this patch was originally send on May 9th [1], changes were requested
>> and a new version was sent on May 19th [2], then on May 27th [3] Tomi pinged
>> maintainer again and go no response.
>>
>> Without this patch, we cannot get display working on any AM437x devices.
>>
>> [1] http://marc.info/?l=linux-arm-kernel&m=139963677925227&w=2
>> [2] http://marc.info/?l=linux-arm-kernel&m=140049799425512&w=2
>> [3] http://marc.info/?l=linux-arm-kernel&m=140117232826754&w=2
>>
>>  arch/arm/mach-omap2/omap_hwmod_43xx_data.c | 98 ++++++++++++++++++++++++++++++
>>  arch/arm/mach-omap2/prcm43xx.h             |  1 +
>>  2 files changed, 99 insertions(+)
>>
>> diff --git a/arch/arm/mach-omap2/omap_hwmod_43xx_data.c b/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
>> index 5c2cc80..d2a7b6d 100644
>> --- a/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
>> +++ b/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
>> @@ -19,6 +19,8 @@
>>  #include "omap_hwmod.h"
>>  #include "omap_hwmod_33xx_43xx_common_data.h"
>>  #include "prcm43xx.h"
>> +#include "omap_hwmod_common_data.h"
>> +
>>  
>>  /* IP blocks */
>>  static struct omap_hwmod am43xx_l4_hs_hwmod = {
>> @@ -415,6 +417,70 @@ static struct omap_hwmod am43xx_qspi_hwmod = {
>>  	},
>>  };
>>  
>> +/* Display sub system - DSS */
>> +
>> +struct omap_dss_dispc_dev_attr am43xx_dss_dispc_dev_attr = {
>> +	.manager_count		= 1,
>> +	.has_framedonetv_irq	= 0
>> +};
>> +
>> +
>> +static struct omap_hwmod_class_sysconfig am43xx_dispc_sysc = {
>> +	.rev_offs	= 0x0000,
>> +	.sysc_offs	= 0x0010,
>> +	.syss_offs	= 0x0014,
>> +	.sysc_flags	= (SYSC_HAS_SIDLEMODE | SYSC_HAS_MIDLEMODE),
>> +	.idlemodes	= (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
>> +	.sysc_fields	= &omap_hwmod_sysc_type1,
>> +};
> 
> Looking at the TRM, "Table 13-43. DISPC_SYSCFG Register Field
> Descriptions" seems to list the folowing bits available:
> 
> 13-12	MIDLEMODE 
> 9-8	CLOCK_ACTIVITY 
> 4-3	SIDLEMODE 
> 2	ENWAKEUP 
> 1	SOFTRESET 
> 0	AUTOIDLE 
> 
> Have I missed something or how come we don't define them all
> as available?

Yes, you're right. I don't see why they shouldn't be there.

> The .idlemodes available values and .sysc_fields seems to match
> the TRM.

Shouldn't idlemodes also have:

	MSTANDBY_FORCE | MSTANDBY_NO | MSTANDBY_SMART

I changed the dispc flags to:

	.sysc_flags	= (SYSC_HAS_AUTOIDLE | SYSC_HAS_SOFTRESET |
		SYSC_HAS_ENAWAKEUP | SYSC_HAS_SIDLEMODE |
		SYSC_HAS_CLOCKACTIVITY | SYSC_HAS_MIDLEMODE),
	.idlemodes	= (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
		MSTANDBY_FORCE | MSTANDBY_NO | MSTANDBY_SMART),

and DSS seems to work fine for me. Then again, I don't think there's any
proper PM going on (or at least things like debugfs/pm_debug/count shows
no sensible values), so it could well be that those flags are not even
used at the moment.

 Tomi



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [RESEND PATCH 1/2] ARM: AM43xx: hwmod: add DSS hwmod data

[Tony Lindgren]

* Tomi Valkeinen <tomi.valkeinen@ti.com> [140617 00:10]:
> On 16/06/14 12:22, Tony Lindgren wrote:
> > * Felipe Balbi <balbi@ti.com> [140613 09:17]:
> >> From: Sathya Prakash M R <sathyap@ti.com>
> >>
> >> Add DSS hwmod data for AM43xx.
> >>
> >> Cc: Andrew Morton <akpm@linux-foundation.org>
> >> Acked-by: Rajendra Nayak <rnayak@ti.com>
> >> Signed-off-by: Sathya Prakash M R <sathyap@ti.com>
> >> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
> >> Signed-off-by: Felipe Balbi <balbi@ti.com>
> >> ---
> >>
> >> Note that this patch was originally send on May 9th [1], changes were requested
> >> and a new version was sent on May 19th [2], then on May 27th [3] Tomi pinged
> >> maintainer again and go no response.
> >>
> >> Without this patch, we cannot get display working on any AM437x devices.
> >>
> >> [1] http://marc.info/?l=linux-arm-kernel&m=139963677925227&w=2
> >> [2] http://marc.info/?l=linux-arm-kernel&m=140049799425512&w=2
> >> [3] http://marc.info/?l=linux-arm-kernel&m=140117232826754&w=2
> >>
> >>  arch/arm/mach-omap2/omap_hwmod_43xx_data.c | 98 ++++++++++++++++++++++++++++++
> >>  arch/arm/mach-omap2/prcm43xx.h             |  1 +
> >>  2 files changed, 99 insertions(+)
> >>
> >> diff --git a/arch/arm/mach-omap2/omap_hwmod_43xx_data.c b/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
> >> index 5c2cc80..d2a7b6d 100644
> >> --- a/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
> >> +++ b/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
> >> @@ -19,6 +19,8 @@
> >>  #include "omap_hwmod.h"
> >>  #include "omap_hwmod_33xx_43xx_common_data.h"
> >>  #include "prcm43xx.h"
> >> +#include "omap_hwmod_common_data.h"
> >> +
> >>  
> >>  /* IP blocks */
> >>  static struct omap_hwmod am43xx_l4_hs_hwmod = {
> >> @@ -415,6 +417,70 @@ static struct omap_hwmod am43xx_qspi_hwmod = {
> >>  	},
> >>  };
> >>  
> >> +/* Display sub system - DSS */
> >> +
> >> +struct omap_dss_dispc_dev_attr am43xx_dss_dispc_dev_attr = {
> >> +	.manager_count		= 1,
> >> +	.has_framedonetv_irq	= 0
> >> +};
> >> +
> >> +
> >> +static struct omap_hwmod_class_sysconfig am43xx_dispc_sysc = {
> >> +	.rev_offs	= 0x0000,
> >> +	.sysc_offs	= 0x0010,
> >> +	.syss_offs	= 0x0014,
> >> +	.sysc_flags	= (SYSC_HAS_SIDLEMODE | SYSC_HAS_MIDLEMODE),
> >> +	.idlemodes	= (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
> >> +	.sysc_fields	= &omap_hwmod_sysc_type1,
> >> +};
> > 
> > Looking at the TRM, "Table 13-43. DISPC_SYSCFG Register Field
> > Descriptions" seems to list the folowing bits available:
> > 
> > 13-12	MIDLEMODE 
> > 9-8	CLOCK_ACTIVITY 
> > 4-3	SIDLEMODE 
> > 2	ENWAKEUP 
> > 1	SOFTRESET 
> > 0	AUTOIDLE 
> > 
> > Have I missed something or how come we don't define them all
> > as available?
> 
> Yes, you're right. I don't see why they shouldn't be there.
> 
> > The .idlemodes available values and .sysc_fields seems to match
> > the TRM.
> 
> Shouldn't idlemodes also have:
> 
> 	MSTANDBY_FORCE | MSTANDBY_NO | MSTANDBY_SMART

Oops yes indeed looking at the MIDDLEDMOE values in addition to
to SIDLEMODE.
 
> I changed the dispc flags to:
> 
> 	.sysc_flags	= (SYSC_HAS_AUTOIDLE | SYSC_HAS_SOFTRESET |
> 		SYSC_HAS_ENAWAKEUP | SYSC_HAS_SIDLEMODE |
> 		SYSC_HAS_CLOCKACTIVITY | SYSC_HAS_MIDLEMODE),
> 	.idlemodes	= (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
> 		MSTANDBY_FORCE | MSTANDBY_NO | MSTANDBY_SMART),
> 
> and DSS seems to work fine for me. Then again, I don't think there's any
> proper PM going on (or at least things like debugfs/pm_debug/count shows
> no sensible values), so it could well be that those flags are not even
> used at the moment.

Right. Having these set correctly for devices is pretty much a
requirement for PM to have any chance of working :)

Regards,

Tony

[PATCH 2/2] arm: dts: add support for AM437x StarterKit

[Felipe Balbi]

Add support for TI's AM437x StarterKit Evaluation
Module.

Cc: Josh Elliot <jelliott@ti.com>
Cc: Darren Etheridge <detheridge@ti.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
---

Thanks to Josh and Darren for helping out with Audio and Display parts of this
DTS.

 .../devicetree/bindings/arm/omap/omap.txt          |   3 +
 arch/arm/boot/dts/Makefile                         |   1 +
 arch/arm/boot/dts/am437x-sk-evm.dts                | 539 +++++++++++++++++++++
 3 files changed, 543 insertions(+)
 create mode 100644 arch/arm/boot/dts/am437x-sk-evm.dts

diff --git a/Documentation/devicetree/bindings/arm/omap/omap.txt b/Documentation/devicetree/bindings/arm/omap/omap.txt
index d22b216..0edc903 100644
--- a/Documentation/devicetree/bindings/arm/omap/omap.txt
+++ b/Documentation/devicetree/bindings/arm/omap/omap.txt
@@ -129,6 +129,9 @@ Boards:
 - AM437x GP EVM
   compatible = "ti,am437x-gp-evm", "ti,am4372", "ti,am43"
 
+- AM437x SK EVM: AM437x StarterKit Evaluation Module
+  compatible = "ti,am437x-sk-evm", "ti,am4372", "ti,am43"
+
 - DRA742 EVM:  Software Development Board for DRA742
   compatible = "ti,dra7-evm", "ti,dra742", "ti,dra74", "ti,dra7"
 
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 0f1e8be..749cdc8 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -306,6 +306,7 @@ dtb-$(CONFIG_ARCH_OMAP4) += omap4-duovero-parlor.dtb \
 	omap4-var-dvk-om44.dtb \
 	omap4-var-stk-om44.dtb
 dtb-$(CONFIG_SOC_AM43XX) += am43x-epos-evm.dtb \
+	am437x-sk-evm.dtb \
 	am437x-gp-evm.dtb
 dtb-$(CONFIG_SOC_OMAP5) += omap5-cm-t54.dtb \
 	omap5-sbc-t54.dtb \
diff --git a/arch/arm/boot/dts/am437x-sk-evm.dts b/arch/arm/boot/dts/am437x-sk-evm.dts
new file mode 100644
index 0000000..51ffab1
--- /dev/null
+++ b/arch/arm/boot/dts/am437x-sk-evm.dts
@@ -0,0 +1,539 @@
+/*
+ * Copyright (C) 2014 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+/* AM437x SK EVM */
+
+/dts-v1/;
+
+#include "am4372.dtsi"
+#include <dt-bindings/pinctrl/am43xx.h>
+#include <dt-bindings/pwm/pwm.h>
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/input.h>
+
+/ {
+	model = "TI AM437x SK EVM";
+	compatible = "ti,am437x-sk-evm","ti,am4372","ti,am43";
+
+	aliases {
+		display0 = &lcd0;
+	};
+
+	vmmcsd_fixed: fixedregulator-sd {
+		compatible = "regulator-fixed";
+		regulator-name = "vmmcsd_fixed";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		enable-active-high;
+	};
+
+	v33_fixed: fixedregulator-v33 {
+		compatible = "regulator-fixed";
+		regulator-name = "v33_fixed";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		enable-active-high;
+	};
+
+	v18_fixed: fixedregulator-v18 {
+		compatible = "regulator-fixed";
+		regulator-name = "v18_fixed";
+		regulator-min-microvolt = <1800000>;
+		regulator-max-microvolt = <1800000>;
+		enable-active-high;
+	};
+
+	backlight {
+		compatible = "pwm-backlight";
+		pwms = <&ecap0 0 50000 PWM_POLARITY_INVERTED>;
+		brightness-levels = <0 51 53 56 62 75 101 152 255>;
+		default-brightness-level = <8>;
+	};
+
+	sound {
+		compatible = "ti,da830-evm-audio";
+		ti,model = "AM437x-SK-EVM";
+		ti,audio-codec = <&tlv320aic3106>;
+		ti,mcasp-controller = <&mcasp1>;
+		ti,codec-clock-rate = <24000000>;
+		ti,audio-routing =
+			"Headphone Jack",       "HPLOUT",
+			"Headphone Jack",       "HPROUT";
+	};
+
+	matrix_keypad: matrix_keypad@0 {
+		compatible = "gpio-matrix-keypad";
+
+		debounce-delay-ms = <5>;
+		col-scan-delay-us = <1500>;
+
+		row-gpios = <&gpio5 5 GPIO_ACTIVE_HIGH		/* Bank5, pin5 */
+				&gpio5 6 GPIO_ACTIVE_HIGH>;	/* Bank5, pin6 */
+
+		col-gpios = <&gpio5 13 GPIO_ACTIVE_HIGH		/* Bank5, pin13 */
+				&gpio5 4 GPIO_ACTIVE_HIGH>;	/* Bank5, pin4 */
+
+		linux,keymap = <
+				MATRIX_KEY(0, 0, KEY_DOWN)
+				MATRIX_KEY(0, 1, KEY_RIGHT)
+				MATRIX_KEY(1, 0, KEY_LEFT)
+				MATRIX_KEY(1, 1, KEY_UP)
+			>;
+	};
+
+	leds {
+		compatible = "gpio-leds";
+
+		led@0 {
+			label = "am437x-sk:red:heartbeat";
+			gpios = <&gpio5 0 GPIO_ACTIVE_HIGH>;	/* Bank 5, pin 0 */
+			linux,default-trigger = "heartbeat";
+			default-state = "off";
+		};
+
+		led@1 {
+			label = "am437x-sk:green:mmc1";
+			gpios = <&gpio5 1 GPIO_ACTIVE_HIGH>;	/* Bank 5, pin 1 */
+			linux,default-trigger = "mmc0";
+			default-state = "off";
+		};
+
+		led@2 {
+			label = "am437x-sk:blue:cpu0";
+			gpios = <&gpio5 2 GPIO_ACTIVE_HIGH>;	/* Bank 5, pin 2 */
+			linux,default-trigger = "cpu0";
+			default-state = "off";
+		};
+
+		led@3 {
+			label = "am437x-sk:blue:usr3";
+			gpios = <&gpio5 3 GPIO_ACTIVE_HIGH>;	/* Bank 5, pin 3 */
+			default-state = "off";
+		};
+	};
+
+	lcd0: display {
+		compatible = "osddisplays,osd057T0559-34ts", "panel-dpi";
+		label = "lcd";
+
+		pinctrl-names = "default";
+		pinctrl-0 = <&lcd_pins>;
+
+		enable-gpios = <&gpio1 7 GPIO_ACTIVE_HIGH>;
+
+		panel-timing {
+			clock-frequency = <9000000>;
+			hactive = <480>;
+			vactive = <272>;
+			hfront-porch = <8>;
+			hback-porch = <43>;
+			hsync-len = <4>;
+			vback-porch = <12>;
+			vfront-porch = <4>;
+			vsync-len = <10>;
+			hsync-active = <0>;
+			vsync-active = <0>;
+			de-active = <1>;
+			pixelclk-active = <1>;
+		};
+
+		port {
+			lcd_in: endpoint {
+				remote-endpoint = <&dpi_out>;
+			};
+		};
+	};
+};
+
+&am43xx_pinmux {
+	i2c0_pins: i2c0_pins {
+		pinctrl-single,pins = <
+			0x188 (PIN_INPUT_PULLUP | SLEWCTRL_FAST | MUX_MODE0)  /* i2c0_sda.i2c0_sda */
+			0x18c (PIN_INPUT_PULLUP | SLEWCTRL_FAST | MUX_MODE0)  /* i2c0_scl.i2c0_scl */
+		>;
+	};
+
+	i2c1_pins: i2c1_pins {
+		pinctrl-single,pins = <
+			0x15c (PIN_INPUT_PULLUP | SLEWCTRL_FAST | MUX_MODE2)  /* spi0_cs0.i2c1_scl */
+			0x158 (PIN_INPUT_PULLUP | SLEWCTRL_FAST | MUX_MODE2)  /* spi0_d1.i2c1_sda  */
+		>;
+	};
+
+	mmc1_pins: pinmux_mmc1_pins {
+		pinctrl-single,pins = <
+			0x160 (PIN_INPUT | MUX_MODE7) /* spi0_cs1.gpio0_6 */
+		>;
+	};
+
+	ecap0_pins: backlight_pins {
+		pinctrl-single,pins = <
+			0x164 MUX_MODE0       /* eCAP0_in_PWM0_out.eCAP0_in_PWM0_out MODE0 */
+		>;
+	};
+
+	edt_ft5306_ts_pins: edt_ft5306_ts_pins {
+		pinctrl-single,pins = <
+			0x74 (PIN_INPUT | MUX_MODE7)	/* gpmc_wpn.gpio0_31 */
+			0x78 (PIN_OUTPUT | MUX_MODE7)	/* gpmc_be1n.gpio1_28 */
+		>;
+	};
+
+	cpsw_default: cpsw_default {
+		pinctrl-single,pins = <
+			/* Slave 1 */
+			0x12c (PIN_OUTPUT_PULLDOWN | MUX_MODE2)	/* mii1_txclk.rmii1_tclk */
+			0x114 (PIN_OUTPUT_PULLDOWN | MUX_MODE2)	/* mii1_txen.rgmii1_tctl */
+			0x128 (PIN_OUTPUT_PULLDOWN | MUX_MODE2)	/* mii1_txd0.rgmii1_td0 */
+			0x124 (PIN_OUTPUT_PULLDOWN | MUX_MODE2)	/* mii1_txd1.rgmii1_td1 */
+			0x120 (PIN_OUTPUT_PULLDOWN | MUX_MODE2)	/* mii1_txd0.rgmii1_td2 */
+			0x11c (PIN_OUTPUT_PULLDOWN | MUX_MODE2)	/* mii1_txd1.rgmii1_td3 */
+			0x130 (PIN_INPUT_PULLDOWN | MUX_MODE2)	/* mii1_rxclk.rmii1_rclk */
+			0x118 (PIN_INPUT_PULLDOWN | MUX_MODE2)	/* mii1_rxdv.rgmii1_rctl */
+			0x140 (PIN_INPUT_PULLDOWN | MUX_MODE2)	/* mii1_rxd0.rgmii1_rd0 */
+			0x13c (PIN_INPUT_PULLDOWN | MUX_MODE2)	/* mii1_rxd1.rgmii1_rd1 */
+			0x138 (PIN_INPUT_PULLDOWN | MUX_MODE2)	/* mii1_rxd0.rgmii1_rd2 */
+			0x134 (PIN_INPUT_PULLDOWN | MUX_MODE2)	/* mii1_rxd1.rgmii1_rd3 */
+
+			/* Slave 2 */
+			0x58 (PIN_OUTPUT_PULLDOWN | MUX_MODE2)	/* gpmc_a6.rgmii2_tclk */
+			0x40 (PIN_OUTPUT_PULLDOWN | MUX_MODE2)	/* gpmc_a0.rgmii2_tctl */
+			0x54 (PIN_OUTPUT_PULLDOWN | MUX_MODE2)	/* gpmc_a5.rgmii2_td0 */
+			0x50 (PIN_OUTPUT_PULLDOWN | MUX_MODE2)	/* gpmc_a4.rgmii2_td1 */
+			0x4c (PIN_OUTPUT_PULLDOWN | MUX_MODE2)	/* gpmc_a3.rgmii2_td2 */
+			0x48 (PIN_OUTPUT_PULLDOWN | MUX_MODE2)	/* gpmc_a2.rgmii2_td3 */
+			0x5c (PIN_INPUT_PULLDOWN | MUX_MODE2)	/* gpmc_a7.rgmii2_rclk */
+			0x44 (PIN_INPUT_PULLDOWN | MUX_MODE2)	/* gpmc_a1.rgmii2_rtcl */
+			0x6c (PIN_INPUT_PULLDOWN | MUX_MODE2)	/* gpmc_a11.rgmii2_rd0 */
+			0x68 (PIN_INPUT_PULLDOWN | MUX_MODE2)	/* gpmc_a10.rgmii2_rd1 */
+			0x64 (PIN_INPUT_PULLDOWN | MUX_MODE2)	/* gpmc_a9.rgmii2_rd2 */
+			0x60 (PIN_INPUT_PULLDOWN | MUX_MODE2)	/* gpmc_a8.rgmii2_rd3 */
+		>;
+	};
+
+	cpsw_sleep: cpsw_sleep {
+		pinctrl-single,pins = <
+			/* Slave 1 reset value */
+			0x12c (PIN_INPUT_PULLDOWN | MUX_MODE7)
+			0x114 (PIN_INPUT_PULLDOWN | MUX_MODE7)
+			0x128 (PIN_INPUT_PULLDOWN | MUX_MODE7)
+			0x124 (PIN_INPUT_PULLDOWN | MUX_MODE7)
+			0x120 (PIN_INPUT_PULLDOWN | MUX_MODE7)
+			0x11c (PIN_INPUT_PULLDOWN | MUX_MODE7)
+			0x130 (PIN_INPUT_PULLDOWN | MUX_MODE7)
+			0x118 (PIN_INPUT_PULLDOWN | MUX_MODE7)
+			0x140 (PIN_INPUT_PULLDOWN | MUX_MODE7)
+			0x13c (PIN_INPUT_PULLDOWN | MUX_MODE7)
+			0x138 (PIN_INPUT_PULLDOWN | MUX_MODE7)
+			0x134 (PIN_INPUT_PULLDOWN | MUX_MODE7)
+
+			/* Slave 2 reset value */
+			0x58 (PIN_INPUT_PULLDOWN | MUX_MODE7)
+			0x40 (PIN_INPUT_PULLDOWN | MUX_MODE7)
+			0x54 (PIN_INPUT_PULLDOWN | MUX_MODE7)
+			0x50 (PIN_INPUT_PULLDOWN | MUX_MODE7)
+			0x4c (PIN_INPUT_PULLDOWN | MUX_MODE7)
+			0x48 (PIN_INPUT_PULLDOWN | MUX_MODE7)
+			0x5c (PIN_INPUT_PULLDOWN | MUX_MODE7)
+			0x44 (PIN_INPUT_PULLDOWN | MUX_MODE7)
+			0x6c (PIN_INPUT_PULLDOWN | MUX_MODE7)
+			0x68 (PIN_INPUT_PULLDOWN | MUX_MODE7)
+			0x64 (PIN_INPUT_PULLDOWN | MUX_MODE7)
+			0x60 (PIN_INPUT_PULLDOWN | MUX_MODE7)
+		>;
+	};
+
+	davinci_mdio_default: davinci_mdio_default {
+		pinctrl-single,pins = <
+			/* MDIO */
+			0x148 (PIN_INPUT_PULLUP | SLEWCTRL_FAST | MUX_MODE0)	/* mdio_data.mdio_data */
+			0x14c (PIN_OUTPUT_PULLUP | MUX_MODE0)			/* mdio_clk.mdio_clk */
+		>;
+	};
+
+	davinci_mdio_sleep: davinci_mdio_sleep {
+		pinctrl-single,pins = <
+			/* MDIO reset value */
+			0x148 (PIN_INPUT_PULLDOWN | MUX_MODE7)
+			0x14c (PIN_INPUT_PULLDOWN | MUX_MODE7)
+		>;
+	};
+
+	dss_pins: dss_pins {
+		pinctrl-single,pins = <
+			0x020 (PIN_OUTPUT_PULLUP | MUX_MODE1)	/* gpmc ad 8 -> DSS DATA 23 */
+			0x024 (PIN_OUTPUT_PULLUP | MUX_MODE1)
+			0x028 (PIN_OUTPUT_PULLUP | MUX_MODE1)
+			0x02c (PIN_OUTPUT_PULLUP | MUX_MODE1)
+			0x030 (PIN_OUTPUT_PULLUP | MUX_MODE1)
+			0x034 (PIN_OUTPUT_PULLUP | MUX_MODE1)
+			0x038 (PIN_OUTPUT_PULLUP | MUX_MODE1)
+			0x03c (PIN_OUTPUT_PULLUP | MUX_MODE1)	/* gpmc ad 15 -> DSS DATA 16 */
+			0x0a0 (PIN_OUTPUT_PULLUP | MUX_MODE0)	/* DSS DATA 0 */
+			0x0a4 (PIN_OUTPUT_PULLUP | MUX_MODE0)
+			0x0a8 (PIN_OUTPUT_PULLUP | MUX_MODE0)
+			0x0ac (PIN_OUTPUT_PULLUP | MUX_MODE0)
+			0x0b0 (PIN_OUTPUT_PULLUP | MUX_MODE0)
+			0x0b4 (PIN_OUTPUT_PULLUP | MUX_MODE0)
+			0x0b8 (PIN_OUTPUT_PULLUP | MUX_MODE0)
+			0x0bc (PIN_OUTPUT_PULLUP | MUX_MODE0)
+			0x0c0 (PIN_OUTPUT_PULLUP | MUX_MODE0)
+			0x0c4 (PIN_OUTPUT_PULLUP | MUX_MODE0)
+			0x0c8 (PIN_OUTPUT_PULLUP | MUX_MODE0)
+			0x0cc (PIN_OUTPUT_PULLUP | MUX_MODE0)
+			0x0d0 (PIN_OUTPUT_PULLUP | MUX_MODE0)
+			0x0d4 (PIN_OUTPUT_PULLUP | MUX_MODE0)
+			0x0d8 (PIN_OUTPUT_PULLUP | MUX_MODE0)
+			0x0dc (PIN_OUTPUT_PULLUP | MUX_MODE0)	/* DSS DATA 15 */
+			0x0e0 (PIN_OUTPUT_PULLUP | MUX_MODE0)	/* DSS VSYNC */
+			0x0e4 (PIN_OUTPUT_PULLUP | MUX_MODE0)	/* DSS HSYNC */
+			0x0e8 (PIN_OUTPUT_PULLUP | MUX_MODE0)	/* DSS PCLK */
+			0x0ec (PIN_OUTPUT_PULLUP | MUX_MODE0)	/* DSS AC BIAS EN */
+
+		>;
+	};
+
+	qspi_pins: qspi_pins {
+		pinctrl-single,pins = <
+			0x7c (PIN_OUTPUT_PULLUP | MUX_MODE3)	/* gpmc_csn0.qspi_csn */
+			0x88 (PIN_OUTPUT | MUX_MODE2)		/* gpmc_csn3.qspi_clk */
+			0x90 (PIN_INPUT_PULLUP | MUX_MODE3)	/* gpmc_advn_ale.qspi_d0 */
+			0x94 (PIN_INPUT_PULLUP | MUX_MODE3)	/* gpmc_oen_ren.qspi_d1 */
+			0x98 (PIN_INPUT_PULLUP | MUX_MODE3)	/* gpmc_wen.qspi_d2 */
+			0x9c (PIN_INPUT_PULLUP | MUX_MODE3)	/* gpmc_be0n_cle.qspi_d3 */
+		>;
+	};
+
+	mcasp1_pins: mcasp1_pins {
+		pinctrl-single,pins = <
+			0x10c (PIN_INPUT_PULLDOWN | MUX_MODE4)	/* mii1_crs.mcasp1_aclkx */
+			0x110 (PIN_INPUT_PULLDOWN | MUX_MODE4)	/* mii1_rxerr.mcasp1_fsx */
+			0x108 (PIN_OUTPUT_PULLDOWN | MUX_MODE4)	/* mii1_col.mcasp1_axr2 */
+			0x144 (PIN_INPUT_PULLDOWN | MUX_MODE4)	/* rmii1_ref_clk.mcasp1_axr3 */
+		>;
+	};
+
+	lcd_pins: lcd_pins {
+		pinctrl-single,pins = <
+			/* GPIO 5_8 to select LCD / HDMI */
+			0x238 (PIN_OUTPUT_PULLUP | MUX_MODE7)
+		>;
+	};
+};
+
+&i2c0 {
+        status = "okay";
+        pinctrl-names = "default";
+        pinctrl-0 = <&i2c0_pins>;
+
+	tps@2d {
+		compatible = "ti,tps65218";
+		reg = <0x2d>;
+	};
+
+	at24@50 {
+		compatible = "at24,24c256";
+		pagesize = <64>;
+		reg = <0x50>;
+	};
+};
+
+&i2c1 {
+        status = "okay";
+        pinctrl-names = "default";
+        pinctrl-0 = <&i2c1_pins>;
+
+	edt-ft5306@38 {
+		status = "okay";
+		compatible = "edt,edt-ft5306", "edt,edt-ft5x06";
+		pinctrl-names = "default";
+		pinctrl-0 = <&edt_ft5306_ts_pins>;
+		reg = <0x38>;
+		interrupt-parent = <&gpio0>;
+		interrupts = <31 0>;
+
+		wake-gpios = <&gpio1 28 GPIO_ACTIVE_HIGH>;
+
+		touchscreen-size-x = <800>;
+		touchscreen-size-y = <600>;
+	};
+
+	tlv320aic3106: tlv320aic3106@1b {
+		compatible = "ti,tlv320aic3106";
+		reg = <0x1b>;
+		status = "okay";
+
+		/* Regulators */
+		AVDD-supply = <&v33_fixed>;
+		IOVDD-supply = <&v33_fixed>;
+		DRVDD-supply = <&v33_fixed>;
+		DVDD-supply = <&v18_fixed>;
+	};
+};
+
+&epwmss0 {
+	status = "okay";
+};
+
+&ecap0 {
+	status = "okay";
+	pinctrl-names = "default";
+	pinctrl-0 = <&ecap0_pins>;
+};
+
+&gpio0 {
+	status = "okay";
+};
+
+&gpio1 {
+	status = "okay";
+};
+
+&gpio5 {
+	status = "okay";
+};
+
+&mmc1 {
+	status = "okay";
+	vmmc-supply = <&vmmcsd_fixed>;
+	bus-width = <4>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&mmc1_pins>;
+	cd-gpios = <&gpio0 6 GPIO_ACTIVE_HIGH>;
+};
+
+&usb2_phy1 {
+	status = "okay";
+};
+
+&usb1 {
+	dr_mode = "peripheral";
+	status = "okay";
+};
+
+&usb2_phy2 {
+	status = "okay";
+};
+
+&usb2 {
+	dr_mode = "host";
+	status = "okay";
+};
+
+&qspi {
+	status = "okay";
+	pinctrl-names = "default";
+	pinctrl-0 = <&qspi_pins>;
+
+	spi-max-frequency = <48000000>;
+	m25p80@0 {
+		compatible = "mx66l51235l";
+		spi-max-frequency = <48000000>;
+		reg = <0>;
+		spi-cpol;
+		spi-cpha;
+		spi-tx-bus-width = <1>;
+		spi-rx-bus-width = <4>;
+		#address-cells = <1>;
+		#size-cells = <1>;
+
+		/* MTD partition table.
+		 * The ROM checks the first 512KiB
+		 * for a valid file to boot(XIP).
+		 */
+		partition@0 {
+			label = "QSPI.U_BOOT";
+			reg = <0x00000000 0x000080000>;
+		};
+		partition@1 {
+			label = "QSPI.U_BOOT.backup";
+			reg = <0x00080000 0x00080000>;
+		};
+		partition@2 {
+			label = "QSPI.U-BOOT-SPL_OS";
+			reg = <0x00100000 0x00010000>;
+		};
+		partition@3 {
+			label = "QSPI.U_BOOT_ENV";
+			reg = <0x00110000 0x00010000>;
+		};
+		partition@4 {
+			label = "QSPI.U-BOOT-ENV.backup";
+			reg = <0x00120000 0x00010000>;
+		};
+		partition@5 {
+			label = "QSPI.KERNEL";
+			reg = <0x00130000 0x0800000>;
+		};
+		partition@6 {
+			label = "QSPI.FILESYSTEM";
+			reg = <0x00930000 0x36D0000>;
+		};
+	};
+};
+
+&mac {
+	pinctrl-names = "default", "sleep";
+	pinctrl-0 = <&cpsw_default>;
+	pinctrl-1 = <&cpsw_sleep>;
+	dual_emac = <1>;
+	status = "okay";
+};
+
+&davinci_mdio {
+	pinctrl-names = "default", "sleep";
+	pinctrl-0 = <&davinci_mdio_default>;
+	pinctrl-1 = <&davinci_mdio_sleep>;
+	status = "okay";
+};
+
+&cpsw_emac0 {
+	phy_id = <&davinci_mdio>, <4>;
+	phy-mode = "rgmii";
+	dual_emac_res_vlan = <1>;
+};
+
+&cpsw_emac1 {
+	phy_id = <&davinci_mdio>, <5>;
+	phy-mode = "rgmii";
+	dual_emac_res_vlan = <2>;
+};
+
+&elm {
+	status = "okay";
+};
+
+&mcasp1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&mcasp1_pins>;
+
+	status = "okay";
+
+	op-mode = <0>;
+	tdm-slots = <2>;
+	serial-dir = <
+		0 0 1 2
+	>;
+
+	tx-num-evt = <1>;
+	rx-num-evt = <1>;
+};
+
+&dss {
+	status = "okay";
+
+	pinctrl-names = "default";
+	pinctrl-0 = <&dss_pins>;
+
+	port {
+		dpi_out: endpoint@0 {
+			remote-endpoint = <&lcd_in>;
+			data-lines = <24>;
+		};
+	};
+};
-- 
2.0.0.rc1

Re: [PATCH 2/2] arm: dts: add support for AM437x StarterKit

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 17674 bytes --]

On Fri, Jun 13, 2014 at 11:15:47AM -0500, Felipe Balbi wrote:
> Add support for TI's AM437x StarterKit Evaluation
> Module.
> 
> Cc: Josh Elliot <jelliott@ti.com>
> Cc: Darren Etheridge <detheridge@ti.com>
> Signed-off-by: Felipe Balbi <balbi@ti.com>
> ---
> 
> Thanks to Josh and Darren for helping out with Audio and Display parts of this
> DTS.
> 
>  .../devicetree/bindings/arm/omap/omap.txt          |   3 +
>  arch/arm/boot/dts/Makefile                         |   1 +
>  arch/arm/boot/dts/am437x-sk-evm.dts                | 539 +++++++++++++++++++++
>  3 files changed, 543 insertions(+)
>  create mode 100644 arch/arm/boot/dts/am437x-sk-evm.dts
> 
> diff --git a/Documentation/devicetree/bindings/arm/omap/omap.txt b/Documentation/devicetree/bindings/arm/omap/omap.txt
> index d22b216..0edc903 100644
> --- a/Documentation/devicetree/bindings/arm/omap/omap.txt
> +++ b/Documentation/devicetree/bindings/arm/omap/omap.txt
> @@ -129,6 +129,9 @@ Boards:
>  - AM437x GP EVM
>    compatible = "ti,am437x-gp-evm", "ti,am4372", "ti,am43"
>  
> +- AM437x SK EVM: AM437x StarterKit Evaluation Module
> +  compatible = "ti,am437x-sk-evm", "ti,am4372", "ti,am43"
> +
>  - DRA742 EVM:  Software Development Board for DRA742
>    compatible = "ti,dra7-evm", "ti,dra742", "ti,dra74", "ti,dra7"
>  
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index 0f1e8be..749cdc8 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -306,6 +306,7 @@ dtb-$(CONFIG_ARCH_OMAP4) += omap4-duovero-parlor.dtb \
>  	omap4-var-dvk-om44.dtb \
>  	omap4-var-stk-om44.dtb
>  dtb-$(CONFIG_SOC_AM43XX) += am43x-epos-evm.dtb \
> +	am437x-sk-evm.dtb \
>  	am437x-gp-evm.dtb
>  dtb-$(CONFIG_SOC_OMAP5) += omap5-cm-t54.dtb \
>  	omap5-sbc-t54.dtb \
> diff --git a/arch/arm/boot/dts/am437x-sk-evm.dts b/arch/arm/boot/dts/am437x-sk-evm.dts
> new file mode 100644
> index 0000000..51ffab1
> --- /dev/null
> +++ b/arch/arm/boot/dts/am437x-sk-evm.dts
> @@ -0,0 +1,539 @@
> +/*
> + * Copyright (C) 2014 Texas Instruments Incorporated - http://www.ti.com/
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +/* AM437x SK EVM */
> +
> +/dts-v1/;
> +
> +#include "am4372.dtsi"
> +#include <dt-bindings/pinctrl/am43xx.h>
> +#include <dt-bindings/pwm/pwm.h>
> +#include <dt-bindings/gpio/gpio.h>
> +#include <dt-bindings/input/input.h>
> +
> +/ {
> +	model = "TI AM437x SK EVM";
> +	compatible = "ti,am437x-sk-evm","ti,am4372","ti,am43";
> +
> +	aliases {
> +		display0 = &lcd0;
> +	};
> +
> +	vmmcsd_fixed: fixedregulator-sd {
> +		compatible = "regulator-fixed";
> +		regulator-name = "vmmcsd_fixed";
> +		regulator-min-microvolt = <3300000>;
> +		regulator-max-microvolt = <3300000>;
> +		enable-active-high;
> +	};
> +
> +	v33_fixed: fixedregulator-v33 {
> +		compatible = "regulator-fixed";
> +		regulator-name = "v33_fixed";
> +		regulator-min-microvolt = <3300000>;
> +		regulator-max-microvolt = <3300000>;
> +		enable-active-high;
> +	};
> +
> +	v18_fixed: fixedregulator-v18 {
> +		compatible = "regulator-fixed";
> +		regulator-name = "v18_fixed";
> +		regulator-min-microvolt = <1800000>;
> +		regulator-max-microvolt = <1800000>;
> +		enable-active-high;
> +	};
> +
> +	backlight {
> +		compatible = "pwm-backlight";
> +		pwms = <&ecap0 0 50000 PWM_POLARITY_INVERTED>;
> +		brightness-levels = <0 51 53 56 62 75 101 152 255>;
> +		default-brightness-level = <8>;
> +	};
> +
> +	sound {
> +		compatible = "ti,da830-evm-audio";
> +		ti,model = "AM437x-SK-EVM";
> +		ti,audio-codec = <&tlv320aic3106>;
> +		ti,mcasp-controller = <&mcasp1>;
> +		ti,codec-clock-rate = <24000000>;
> +		ti,audio-routing =
> +			"Headphone Jack",       "HPLOUT",
> +			"Headphone Jack",       "HPROUT";
> +	};
> +
> +	matrix_keypad: matrix_keypad@0 {
> +		compatible = "gpio-matrix-keypad";
> +
> +		debounce-delay-ms = <5>;
> +		col-scan-delay-us = <1500>;
> +
> +		row-gpios = <&gpio5 5 GPIO_ACTIVE_HIGH		/* Bank5, pin5 */
> +				&gpio5 6 GPIO_ACTIVE_HIGH>;	/* Bank5, pin6 */
> +
> +		col-gpios = <&gpio5 13 GPIO_ACTIVE_HIGH		/* Bank5, pin13 */
> +				&gpio5 4 GPIO_ACTIVE_HIGH>;	/* Bank5, pin4 */
> +
> +		linux,keymap = <
> +				MATRIX_KEY(0, 0, KEY_DOWN)
> +				MATRIX_KEY(0, 1, KEY_RIGHT)
> +				MATRIX_KEY(1, 0, KEY_LEFT)
> +				MATRIX_KEY(1, 1, KEY_UP)
> +			>;
> +	};
> +
> +	leds {
> +		compatible = "gpio-leds";
> +
> +		led@0 {
> +			label = "am437x-sk:red:heartbeat";
> +			gpios = <&gpio5 0 GPIO_ACTIVE_HIGH>;	/* Bank 5, pin 0 */
> +			linux,default-trigger = "heartbeat";
> +			default-state = "off";
> +		};
> +
> +		led@1 {
> +			label = "am437x-sk:green:mmc1";
> +			gpios = <&gpio5 1 GPIO_ACTIVE_HIGH>;	/* Bank 5, pin 1 */
> +			linux,default-trigger = "mmc0";
> +			default-state = "off";
> +		};
> +
> +		led@2 {
> +			label = "am437x-sk:blue:cpu0";
> +			gpios = <&gpio5 2 GPIO_ACTIVE_HIGH>;	/* Bank 5, pin 2 */
> +			linux,default-trigger = "cpu0";
> +			default-state = "off";
> +		};
> +
> +		led@3 {
> +			label = "am437x-sk:blue:usr3";
> +			gpios = <&gpio5 3 GPIO_ACTIVE_HIGH>;	/* Bank 5, pin 3 */
> +			default-state = "off";
> +		};
> +	};
> +
> +	lcd0: display {
> +		compatible = "osddisplays,osd057T0559-34ts", "panel-dpi";
> +		label = "lcd";
> +
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&lcd_pins>;
> +
> +		enable-gpios = <&gpio1 7 GPIO_ACTIVE_HIGH>;
> +
> +		panel-timing {
> +			clock-frequency = <9000000>;
> +			hactive = <480>;
> +			vactive = <272>;
> +			hfront-porch = <8>;
> +			hback-porch = <43>;
> +			hsync-len = <4>;
> +			vback-porch = <12>;
> +			vfront-porch = <4>;
> +			vsync-len = <10>;
> +			hsync-active = <0>;
> +			vsync-active = <0>;
> +			de-active = <1>;
> +			pixelclk-active = <1>;
> +		};
> +
> +		port {
> +			lcd_in: endpoint {
> +				remote-endpoint = <&dpi_out>;
> +			};
> +		};
> +	};
> +};
> +
> +&am43xx_pinmux {
> +	i2c0_pins: i2c0_pins {
> +		pinctrl-single,pins = <
> +			0x188 (PIN_INPUT_PULLUP | SLEWCTRL_FAST | MUX_MODE0)  /* i2c0_sda.i2c0_sda */
> +			0x18c (PIN_INPUT_PULLUP | SLEWCTRL_FAST | MUX_MODE0)  /* i2c0_scl.i2c0_scl */
> +		>;
> +	};
> +
> +	i2c1_pins: i2c1_pins {
> +		pinctrl-single,pins = <
> +			0x15c (PIN_INPUT_PULLUP | SLEWCTRL_FAST | MUX_MODE2)  /* spi0_cs0.i2c1_scl */
> +			0x158 (PIN_INPUT_PULLUP | SLEWCTRL_FAST | MUX_MODE2)  /* spi0_d1.i2c1_sda  */
> +		>;
> +	};
> +
> +	mmc1_pins: pinmux_mmc1_pins {
> +		pinctrl-single,pins = <
> +			0x160 (PIN_INPUT | MUX_MODE7) /* spi0_cs1.gpio0_6 */
> +		>;
> +	};
> +
> +	ecap0_pins: backlight_pins {
> +		pinctrl-single,pins = <
> +			0x164 MUX_MODE0       /* eCAP0_in_PWM0_out.eCAP0_in_PWM0_out MODE0 */
> +		>;
> +	};
> +
> +	edt_ft5306_ts_pins: edt_ft5306_ts_pins {
> +		pinctrl-single,pins = <
> +			0x74 (PIN_INPUT | MUX_MODE7)	/* gpmc_wpn.gpio0_31 */
> +			0x78 (PIN_OUTPUT | MUX_MODE7)	/* gpmc_be1n.gpio1_28 */
> +		>;
> +	};
> +
> +	cpsw_default: cpsw_default {
> +		pinctrl-single,pins = <
> +			/* Slave 1 */
> +			0x12c (PIN_OUTPUT_PULLDOWN | MUX_MODE2)	/* mii1_txclk.rmii1_tclk */
> +			0x114 (PIN_OUTPUT_PULLDOWN | MUX_MODE2)	/* mii1_txen.rgmii1_tctl */
> +			0x128 (PIN_OUTPUT_PULLDOWN | MUX_MODE2)	/* mii1_txd0.rgmii1_td0 */
> +			0x124 (PIN_OUTPUT_PULLDOWN | MUX_MODE2)	/* mii1_txd1.rgmii1_td1 */
> +			0x120 (PIN_OUTPUT_PULLDOWN | MUX_MODE2)	/* mii1_txd0.rgmii1_td2 */
> +			0x11c (PIN_OUTPUT_PULLDOWN | MUX_MODE2)	/* mii1_txd1.rgmii1_td3 */
> +			0x130 (PIN_INPUT_PULLDOWN | MUX_MODE2)	/* mii1_rxclk.rmii1_rclk */
> +			0x118 (PIN_INPUT_PULLDOWN | MUX_MODE2)	/* mii1_rxdv.rgmii1_rctl */
> +			0x140 (PIN_INPUT_PULLDOWN | MUX_MODE2)	/* mii1_rxd0.rgmii1_rd0 */
> +			0x13c (PIN_INPUT_PULLDOWN | MUX_MODE2)	/* mii1_rxd1.rgmii1_rd1 */
> +			0x138 (PIN_INPUT_PULLDOWN | MUX_MODE2)	/* mii1_rxd0.rgmii1_rd2 */
> +			0x134 (PIN_INPUT_PULLDOWN | MUX_MODE2)	/* mii1_rxd1.rgmii1_rd3 */
> +
> +			/* Slave 2 */
> +			0x58 (PIN_OUTPUT_PULLDOWN | MUX_MODE2)	/* gpmc_a6.rgmii2_tclk */
> +			0x40 (PIN_OUTPUT_PULLDOWN | MUX_MODE2)	/* gpmc_a0.rgmii2_tctl */
> +			0x54 (PIN_OUTPUT_PULLDOWN | MUX_MODE2)	/* gpmc_a5.rgmii2_td0 */
> +			0x50 (PIN_OUTPUT_PULLDOWN | MUX_MODE2)	/* gpmc_a4.rgmii2_td1 */
> +			0x4c (PIN_OUTPUT_PULLDOWN | MUX_MODE2)	/* gpmc_a3.rgmii2_td2 */
> +			0x48 (PIN_OUTPUT_PULLDOWN | MUX_MODE2)	/* gpmc_a2.rgmii2_td3 */
> +			0x5c (PIN_INPUT_PULLDOWN | MUX_MODE2)	/* gpmc_a7.rgmii2_rclk */
> +			0x44 (PIN_INPUT_PULLDOWN | MUX_MODE2)	/* gpmc_a1.rgmii2_rtcl */
> +			0x6c (PIN_INPUT_PULLDOWN | MUX_MODE2)	/* gpmc_a11.rgmii2_rd0 */
> +			0x68 (PIN_INPUT_PULLDOWN | MUX_MODE2)	/* gpmc_a10.rgmii2_rd1 */
> +			0x64 (PIN_INPUT_PULLDOWN | MUX_MODE2)	/* gpmc_a9.rgmii2_rd2 */
> +			0x60 (PIN_INPUT_PULLDOWN | MUX_MODE2)	/* gpmc_a8.rgmii2_rd3 */
> +		>;
> +	};
> +
> +	cpsw_sleep: cpsw_sleep {
> +		pinctrl-single,pins = <
> +			/* Slave 1 reset value */
> +			0x12c (PIN_INPUT_PULLDOWN | MUX_MODE7)
> +			0x114 (PIN_INPUT_PULLDOWN | MUX_MODE7)
> +			0x128 (PIN_INPUT_PULLDOWN | MUX_MODE7)
> +			0x124 (PIN_INPUT_PULLDOWN | MUX_MODE7)
> +			0x120 (PIN_INPUT_PULLDOWN | MUX_MODE7)
> +			0x11c (PIN_INPUT_PULLDOWN | MUX_MODE7)
> +			0x130 (PIN_INPUT_PULLDOWN | MUX_MODE7)
> +			0x118 (PIN_INPUT_PULLDOWN | MUX_MODE7)
> +			0x140 (PIN_INPUT_PULLDOWN | MUX_MODE7)
> +			0x13c (PIN_INPUT_PULLDOWN | MUX_MODE7)
> +			0x138 (PIN_INPUT_PULLDOWN | MUX_MODE7)
> +			0x134 (PIN_INPUT_PULLDOWN | MUX_MODE7)
> +
> +			/* Slave 2 reset value */
> +			0x58 (PIN_INPUT_PULLDOWN | MUX_MODE7)
> +			0x40 (PIN_INPUT_PULLDOWN | MUX_MODE7)
> +			0x54 (PIN_INPUT_PULLDOWN | MUX_MODE7)
> +			0x50 (PIN_INPUT_PULLDOWN | MUX_MODE7)
> +			0x4c (PIN_INPUT_PULLDOWN | MUX_MODE7)
> +			0x48 (PIN_INPUT_PULLDOWN | MUX_MODE7)
> +			0x5c (PIN_INPUT_PULLDOWN | MUX_MODE7)
> +			0x44 (PIN_INPUT_PULLDOWN | MUX_MODE7)
> +			0x6c (PIN_INPUT_PULLDOWN | MUX_MODE7)
> +			0x68 (PIN_INPUT_PULLDOWN | MUX_MODE7)
> +			0x64 (PIN_INPUT_PULLDOWN | MUX_MODE7)
> +			0x60 (PIN_INPUT_PULLDOWN | MUX_MODE7)
> +		>;
> +	};
> +
> +	davinci_mdio_default: davinci_mdio_default {
> +		pinctrl-single,pins = <
> +			/* MDIO */
> +			0x148 (PIN_INPUT_PULLUP | SLEWCTRL_FAST | MUX_MODE0)	/* mdio_data.mdio_data */
> +			0x14c (PIN_OUTPUT_PULLUP | MUX_MODE0)			/* mdio_clk.mdio_clk */
> +		>;
> +	};
> +
> +	davinci_mdio_sleep: davinci_mdio_sleep {
> +		pinctrl-single,pins = <
> +			/* MDIO reset value */
> +			0x148 (PIN_INPUT_PULLDOWN | MUX_MODE7)
> +			0x14c (PIN_INPUT_PULLDOWN | MUX_MODE7)
> +		>;
> +	};
> +
> +	dss_pins: dss_pins {
> +		pinctrl-single,pins = <
> +			0x020 (PIN_OUTPUT_PULLUP | MUX_MODE1)	/* gpmc ad 8 -> DSS DATA 23 */
> +			0x024 (PIN_OUTPUT_PULLUP | MUX_MODE1)
> +			0x028 (PIN_OUTPUT_PULLUP | MUX_MODE1)
> +			0x02c (PIN_OUTPUT_PULLUP | MUX_MODE1)
> +			0x030 (PIN_OUTPUT_PULLUP | MUX_MODE1)
> +			0x034 (PIN_OUTPUT_PULLUP | MUX_MODE1)
> +			0x038 (PIN_OUTPUT_PULLUP | MUX_MODE1)
> +			0x03c (PIN_OUTPUT_PULLUP | MUX_MODE1)	/* gpmc ad 15 -> DSS DATA 16 */
> +			0x0a0 (PIN_OUTPUT_PULLUP | MUX_MODE0)	/* DSS DATA 0 */
> +			0x0a4 (PIN_OUTPUT_PULLUP | MUX_MODE0)
> +			0x0a8 (PIN_OUTPUT_PULLUP | MUX_MODE0)
> +			0x0ac (PIN_OUTPUT_PULLUP | MUX_MODE0)
> +			0x0b0 (PIN_OUTPUT_PULLUP | MUX_MODE0)
> +			0x0b4 (PIN_OUTPUT_PULLUP | MUX_MODE0)
> +			0x0b8 (PIN_OUTPUT_PULLUP | MUX_MODE0)
> +			0x0bc (PIN_OUTPUT_PULLUP | MUX_MODE0)
> +			0x0c0 (PIN_OUTPUT_PULLUP | MUX_MODE0)
> +			0x0c4 (PIN_OUTPUT_PULLUP | MUX_MODE0)
> +			0x0c8 (PIN_OUTPUT_PULLUP | MUX_MODE0)
> +			0x0cc (PIN_OUTPUT_PULLUP | MUX_MODE0)
> +			0x0d0 (PIN_OUTPUT_PULLUP | MUX_MODE0)
> +			0x0d4 (PIN_OUTPUT_PULLUP | MUX_MODE0)
> +			0x0d8 (PIN_OUTPUT_PULLUP | MUX_MODE0)
> +			0x0dc (PIN_OUTPUT_PULLUP | MUX_MODE0)	/* DSS DATA 15 */
> +			0x0e0 (PIN_OUTPUT_PULLUP | MUX_MODE0)	/* DSS VSYNC */
> +			0x0e4 (PIN_OUTPUT_PULLUP | MUX_MODE0)	/* DSS HSYNC */
> +			0x0e8 (PIN_OUTPUT_PULLUP | MUX_MODE0)	/* DSS PCLK */
> +			0x0ec (PIN_OUTPUT_PULLUP | MUX_MODE0)	/* DSS AC BIAS EN */
> +
> +		>;
> +	};
> +
> +	qspi_pins: qspi_pins {
> +		pinctrl-single,pins = <
> +			0x7c (PIN_OUTPUT_PULLUP | MUX_MODE3)	/* gpmc_csn0.qspi_csn */
> +			0x88 (PIN_OUTPUT | MUX_MODE2)		/* gpmc_csn3.qspi_clk */
> +			0x90 (PIN_INPUT_PULLUP | MUX_MODE3)	/* gpmc_advn_ale.qspi_d0 */
> +			0x94 (PIN_INPUT_PULLUP | MUX_MODE3)	/* gpmc_oen_ren.qspi_d1 */
> +			0x98 (PIN_INPUT_PULLUP | MUX_MODE3)	/* gpmc_wen.qspi_d2 */
> +			0x9c (PIN_INPUT_PULLUP | MUX_MODE3)	/* gpmc_be0n_cle.qspi_d3 */
> +		>;
> +	};
> +
> +	mcasp1_pins: mcasp1_pins {
> +		pinctrl-single,pins = <
> +			0x10c (PIN_INPUT_PULLDOWN | MUX_MODE4)	/* mii1_crs.mcasp1_aclkx */
> +			0x110 (PIN_INPUT_PULLDOWN | MUX_MODE4)	/* mii1_rxerr.mcasp1_fsx */
> +			0x108 (PIN_OUTPUT_PULLDOWN | MUX_MODE4)	/* mii1_col.mcasp1_axr2 */
> +			0x144 (PIN_INPUT_PULLDOWN | MUX_MODE4)	/* rmii1_ref_clk.mcasp1_axr3 */
> +		>;
> +	};
> +
> +	lcd_pins: lcd_pins {
> +		pinctrl-single,pins = <
> +			/* GPIO 5_8 to select LCD / HDMI */
> +			0x238 (PIN_OUTPUT_PULLUP | MUX_MODE7)
> +		>;
> +	};
> +};
> +
> +&i2c0 {
> +        status = "okay";
> +        pinctrl-names = "default";
> +        pinctrl-0 = <&i2c0_pins>;
> +
> +	tps@2d {
> +		compatible = "ti,tps65218";
> +		reg = <0x2d>;
> +	};
> +
> +	at24@50 {
> +		compatible = "at24,24c256";
> +		pagesize = <64>;
> +		reg = <0x50>;
> +	};
> +};
> +
> +&i2c1 {
> +        status = "okay";
> +        pinctrl-names = "default";
> +        pinctrl-0 = <&i2c1_pins>;
> +
> +	edt-ft5306@38 {
> +		status = "okay";
> +		compatible = "edt,edt-ft5306", "edt,edt-ft5x06";
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&edt_ft5306_ts_pins>;
> +		reg = <0x38>;
> +		interrupt-parent = <&gpio0>;
> +		interrupts = <31 0>;
> +
> +		wake-gpios = <&gpio1 28 GPIO_ACTIVE_HIGH>;
> +
> +		touchscreen-size-x = <800>;
> +		touchscreen-size-y = <600>;
> +	};
> +
> +	tlv320aic3106: tlv320aic3106@1b {
> +		compatible = "ti,tlv320aic3106";
> +		reg = <0x1b>;
> +		status = "okay";
> +
> +		/* Regulators */
> +		AVDD-supply = <&v33_fixed>;
> +		IOVDD-supply = <&v33_fixed>;
> +		DRVDD-supply = <&v33_fixed>;
> +		DVDD-supply = <&v18_fixed>;
> +	};
> +};
> +
> +&epwmss0 {
> +	status = "okay";
> +};
> +
> +&ecap0 {
> +	status = "okay";
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&ecap0_pins>;
> +};
> +
> +&gpio0 {
> +	status = "okay";
> +};
> +
> +&gpio1 {
> +	status = "okay";
> +};
> +
> +&gpio5 {
> +	status = "okay";
> +};
> +
> +&mmc1 {
> +	status = "okay";
> +	vmmc-supply = <&vmmcsd_fixed>;
> +	bus-width = <4>;
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&mmc1_pins>;
> +	cd-gpios = <&gpio0 6 GPIO_ACTIVE_HIGH>;
> +};
> +
> +&usb2_phy1 {
> +	status = "okay";
> +};
> +
> +&usb1 {
> +	dr_mode = "peripheral";
> +	status = "okay";
> +};
> +
> +&usb2_phy2 {
> +	status = "okay";
> +};
> +
> +&usb2 {
> +	dr_mode = "host";
> +	status = "okay";
> +};
> +
> +&qspi {
> +	status = "okay";
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&qspi_pins>;
> +
> +	spi-max-frequency = <48000000>;
> +	m25p80@0 {
> +		compatible = "mx66l51235l";
> +		spi-max-frequency = <48000000>;
> +		reg = <0>;
> +		spi-cpol;
> +		spi-cpha;
> +		spi-tx-bus-width = <1>;
> +		spi-rx-bus-width = <4>;
> +		#address-cells = <1>;
> +		#size-cells = <1>;
> +
> +		/* MTD partition table.
> +		 * The ROM checks the first 512KiB
> +		 * for a valid file to boot(XIP).
> +		 */
> +		partition@0 {
> +			label = "QSPI.U_BOOT";
> +			reg = <0x00000000 0x000080000>;
> +		};
> +		partition@1 {
> +			label = "QSPI.U_BOOT.backup";
> +			reg = <0x00080000 0x00080000>;
> +		};
> +		partition@2 {
> +			label = "QSPI.U-BOOT-SPL_OS";
> +			reg = <0x00100000 0x00010000>;
> +		};
> +		partition@3 {
> +			label = "QSPI.U_BOOT_ENV";
> +			reg = <0x00110000 0x00010000>;
> +		};
> +		partition@4 {
> +			label = "QSPI.U-BOOT-ENV.backup";
> +			reg = <0x00120000 0x00010000>;
> +		};
> +		partition@5 {
> +			label = "QSPI.KERNEL";
> +			reg = <0x00130000 0x0800000>;
> +		};
> +		partition@6 {
> +			label = "QSPI.FILESYSTEM";
> +			reg = <0x00930000 0x36D0000>;
> +		};
> +	};
> +};
> +
> +&mac {
> +	pinctrl-names = "default", "sleep";
> +	pinctrl-0 = <&cpsw_default>;
> +	pinctrl-1 = <&cpsw_sleep>;
> +	dual_emac = <1>;
> +	status = "okay";
> +};
> +
> +&davinci_mdio {
> +	pinctrl-names = "default", "sleep";
> +	pinctrl-0 = <&davinci_mdio_default>;
> +	pinctrl-1 = <&davinci_mdio_sleep>;
> +	status = "okay";
> +};
> +
> +&cpsw_emac0 {
> +	phy_id = <&davinci_mdio>, <4>;
> +	phy-mode = "rgmii";
> +	dual_emac_res_vlan = <1>;
> +};
> +
> +&cpsw_emac1 {
> +	phy_id = <&davinci_mdio>, <5>;
> +	phy-mode = "rgmii";
> +	dual_emac_res_vlan = <2>;
> +};
> +
> +&elm {
> +	status = "okay";
> +};
> +
> +&mcasp1 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&mcasp1_pins>;
> +
> +	status = "okay";
> +
> +	op-mode = <0>;
> +	tdm-slots = <2>;
> +	serial-dir = <
> +		0 0 1 2
> +	>;
> +
> +	tx-num-evt = <1>;
> +	rx-num-evt = <1>;
> +};
> +
> +&dss {
> +	status = "okay";
> +
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&dss_pins>;
> +
> +	port {
> +		dpi_out: endpoint@0 {
> +			remote-endpoint = <&lcd_in>;
> +			data-lines = <24>;
> +		};
> +	};
> +};
> -- 
> 2.0.0.rc1
> 

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH 2/2] arm: dts: add support for AM437x StarterKit

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 18989 bytes --]

Hi,

adding devicetree and some others

On Fri, Jun 13, 2014 at 11:23:34AM -0500, Felipe Balbi wrote:
> On Fri, Jun 13, 2014 at 11:15:47AM -0500, Felipe Balbi wrote:
> > Add support for TI's AM437x StarterKit Evaluation
> > Module.
> > 
> > Cc: Josh Elliot <jelliott@ti.com>
> > Cc: Darren Etheridge <detheridge@ti.com>
> > Signed-off-by: Felipe Balbi <balbi@ti.com>
> > ---
> > 
> > Thanks to Josh and Darren for helping out with Audio and Display parts of this
> > DTS.
> > 
> >  .../devicetree/bindings/arm/omap/omap.txt          |   3 +
> >  arch/arm/boot/dts/Makefile                         |   1 +
> >  arch/arm/boot/dts/am437x-sk-evm.dts                | 539 +++++++++++++++++++++
> >  3 files changed, 543 insertions(+)
> >  create mode 100644 arch/arm/boot/dts/am437x-sk-evm.dts
> > 
> > diff --git a/Documentation/devicetree/bindings/arm/omap/omap.txt b/Documentation/devicetree/bindings/arm/omap/omap.txt
> > index d22b216..0edc903 100644
> > --- a/Documentation/devicetree/bindings/arm/omap/omap.txt
> > +++ b/Documentation/devicetree/bindings/arm/omap/omap.txt
> > @@ -129,6 +129,9 @@ Boards:
> >  - AM437x GP EVM
> >    compatible = "ti,am437x-gp-evm", "ti,am4372", "ti,am43"
> >  
> > +- AM437x SK EVM: AM437x StarterKit Evaluation Module
> > +  compatible = "ti,am437x-sk-evm", "ti,am4372", "ti,am43"
> > +
> >  - DRA742 EVM:  Software Development Board for DRA742
> >    compatible = "ti,dra7-evm", "ti,dra742", "ti,dra74", "ti,dra7"
> >  
> > diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> > index 0f1e8be..749cdc8 100644
> > --- a/arch/arm/boot/dts/Makefile
> > +++ b/arch/arm/boot/dts/Makefile
> > @@ -306,6 +306,7 @@ dtb-$(CONFIG_ARCH_OMAP4) += omap4-duovero-parlor.dtb \
> >  	omap4-var-dvk-om44.dtb \
> >  	omap4-var-stk-om44.dtb
> >  dtb-$(CONFIG_SOC_AM43XX) += am43x-epos-evm.dtb \
> > +	am437x-sk-evm.dtb \
> >  	am437x-gp-evm.dtb
> >  dtb-$(CONFIG_SOC_OMAP5) += omap5-cm-t54.dtb \
> >  	omap5-sbc-t54.dtb \
> > diff --git a/arch/arm/boot/dts/am437x-sk-evm.dts b/arch/arm/boot/dts/am437x-sk-evm.dts
> > new file mode 100644
> > index 0000000..51ffab1
> > --- /dev/null
> > +++ b/arch/arm/boot/dts/am437x-sk-evm.dts
> > @@ -0,0 +1,539 @@
> > +/*
> > + * Copyright (C) 2014 Texas Instruments Incorporated - http://www.ti.com/
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License version 2 as
> > + * published by the Free Software Foundation.
> > + */
> > +
> > +/* AM437x SK EVM */
> > +
> > +/dts-v1/;
> > +
> > +#include "am4372.dtsi"
> > +#include <dt-bindings/pinctrl/am43xx.h>
> > +#include <dt-bindings/pwm/pwm.h>
> > +#include <dt-bindings/gpio/gpio.h>
> > +#include <dt-bindings/input/input.h>
> > +
> > +/ {
> > +	model = "TI AM437x SK EVM";
> > +	compatible = "ti,am437x-sk-evm","ti,am4372","ti,am43";
> > +
> > +	aliases {
> > +		display0 = &lcd0;
> > +	};
> > +
> > +	vmmcsd_fixed: fixedregulator-sd {
> > +		compatible = "regulator-fixed";
> > +		regulator-name = "vmmcsd_fixed";
> > +		regulator-min-microvolt = <3300000>;
> > +		regulator-max-microvolt = <3300000>;
> > +		enable-active-high;
> > +	};
> > +
> > +	v33_fixed: fixedregulator-v33 {
> > +		compatible = "regulator-fixed";
> > +		regulator-name = "v33_fixed";
> > +		regulator-min-microvolt = <3300000>;
> > +		regulator-max-microvolt = <3300000>;
> > +		enable-active-high;
> > +	};
> > +
> > +	v18_fixed: fixedregulator-v18 {
> > +		compatible = "regulator-fixed";
> > +		regulator-name = "v18_fixed";
> > +		regulator-min-microvolt = <1800000>;
> > +		regulator-max-microvolt = <1800000>;
> > +		enable-active-high;
> > +	};
> > +
> > +	backlight {
> > +		compatible = "pwm-backlight";
> > +		pwms = <&ecap0 0 50000 PWM_POLARITY_INVERTED>;
> > +		brightness-levels = <0 51 53 56 62 75 101 152 255>;
> > +		default-brightness-level = <8>;
> > +	};
> > +
> > +	sound {
> > +		compatible = "ti,da830-evm-audio";
> > +		ti,model = "AM437x-SK-EVM";
> > +		ti,audio-codec = <&tlv320aic3106>;
> > +		ti,mcasp-controller = <&mcasp1>;
> > +		ti,codec-clock-rate = <24000000>;
> > +		ti,audio-routing =
> > +			"Headphone Jack",       "HPLOUT",
> > +			"Headphone Jack",       "HPROUT";
> > +	};
> > +
> > +	matrix_keypad: matrix_keypad@0 {
> > +		compatible = "gpio-matrix-keypad";
> > +
> > +		debounce-delay-ms = <5>;
> > +		col-scan-delay-us = <1500>;
> > +
> > +		row-gpios = <&gpio5 5 GPIO_ACTIVE_HIGH		/* Bank5, pin5 */
> > +				&gpio5 6 GPIO_ACTIVE_HIGH>;	/* Bank5, pin6 */
> > +
> > +		col-gpios = <&gpio5 13 GPIO_ACTIVE_HIGH		/* Bank5, pin13 */
> > +				&gpio5 4 GPIO_ACTIVE_HIGH>;	/* Bank5, pin4 */
> > +
> > +		linux,keymap = <
> > +				MATRIX_KEY(0, 0, KEY_DOWN)
> > +				MATRIX_KEY(0, 1, KEY_RIGHT)
> > +				MATRIX_KEY(1, 0, KEY_LEFT)
> > +				MATRIX_KEY(1, 1, KEY_UP)
> > +			>;
> > +	};
> > +
> > +	leds {
> > +		compatible = "gpio-leds";
> > +
> > +		led@0 {
> > +			label = "am437x-sk:red:heartbeat";
> > +			gpios = <&gpio5 0 GPIO_ACTIVE_HIGH>;	/* Bank 5, pin 0 */
> > +			linux,default-trigger = "heartbeat";
> > +			default-state = "off";
> > +		};
> > +
> > +		led@1 {
> > +			label = "am437x-sk:green:mmc1";
> > +			gpios = <&gpio5 1 GPIO_ACTIVE_HIGH>;	/* Bank 5, pin 1 */
> > +			linux,default-trigger = "mmc0";
> > +			default-state = "off";
> > +		};
> > +
> > +		led@2 {
> > +			label = "am437x-sk:blue:cpu0";
> > +			gpios = <&gpio5 2 GPIO_ACTIVE_HIGH>;	/* Bank 5, pin 2 */
> > +			linux,default-trigger = "cpu0";
> > +			default-state = "off";
> > +		};
> > +
> > +		led@3 {
> > +			label = "am437x-sk:blue:usr3";
> > +			gpios = <&gpio5 3 GPIO_ACTIVE_HIGH>;	/* Bank 5, pin 3 */
> > +			default-state = "off";
> > +		};
> > +	};
> > +
> > +	lcd0: display {
> > +		compatible = "osddisplays,osd057T0559-34ts", "panel-dpi";
> > +		label = "lcd";
> > +
> > +		pinctrl-names = "default";
> > +		pinctrl-0 = <&lcd_pins>;
> > +
> > +		enable-gpios = <&gpio1 7 GPIO_ACTIVE_HIGH>;
> > +
> > +		panel-timing {
> > +			clock-frequency = <9000000>;
> > +			hactive = <480>;
> > +			vactive = <272>;
> > +			hfront-porch = <8>;
> > +			hback-porch = <43>;
> > +			hsync-len = <4>;
> > +			vback-porch = <12>;
> > +			vfront-porch = <4>;
> > +			vsync-len = <10>;
> > +			hsync-active = <0>;
> > +			vsync-active = <0>;
> > +			de-active = <1>;
> > +			pixelclk-active = <1>;
> > +		};
> > +
> > +		port {
> > +			lcd_in: endpoint {
> > +				remote-endpoint = <&dpi_out>;
> > +			};
> > +		};
> > +	};
> > +};
> > +
> > +&am43xx_pinmux {
> > +	i2c0_pins: i2c0_pins {
> > +		pinctrl-single,pins = <
> > +			0x188 (PIN_INPUT_PULLUP | SLEWCTRL_FAST | MUX_MODE0)  /* i2c0_sda.i2c0_sda */
> > +			0x18c (PIN_INPUT_PULLUP | SLEWCTRL_FAST | MUX_MODE0)  /* i2c0_scl.i2c0_scl */
> > +		>;
> > +	};
> > +
> > +	i2c1_pins: i2c1_pins {
> > +		pinctrl-single,pins = <
> > +			0x15c (PIN_INPUT_PULLUP | SLEWCTRL_FAST | MUX_MODE2)  /* spi0_cs0.i2c1_scl */
> > +			0x158 (PIN_INPUT_PULLUP | SLEWCTRL_FAST | MUX_MODE2)  /* spi0_d1.i2c1_sda  */
> > +		>;
> > +	};
> > +
> > +	mmc1_pins: pinmux_mmc1_pins {
> > +		pinctrl-single,pins = <
> > +			0x160 (PIN_INPUT | MUX_MODE7) /* spi0_cs1.gpio0_6 */
> > +		>;
> > +	};
> > +
> > +	ecap0_pins: backlight_pins {
> > +		pinctrl-single,pins = <
> > +			0x164 MUX_MODE0       /* eCAP0_in_PWM0_out.eCAP0_in_PWM0_out MODE0 */
> > +		>;
> > +	};
> > +
> > +	edt_ft5306_ts_pins: edt_ft5306_ts_pins {
> > +		pinctrl-single,pins = <
> > +			0x74 (PIN_INPUT | MUX_MODE7)	/* gpmc_wpn.gpio0_31 */
> > +			0x78 (PIN_OUTPUT | MUX_MODE7)	/* gpmc_be1n.gpio1_28 */
> > +		>;
> > +	};
> > +
> > +	cpsw_default: cpsw_default {
> > +		pinctrl-single,pins = <
> > +			/* Slave 1 */
> > +			0x12c (PIN_OUTPUT_PULLDOWN | MUX_MODE2)	/* mii1_txclk.rmii1_tclk */
> > +			0x114 (PIN_OUTPUT_PULLDOWN | MUX_MODE2)	/* mii1_txen.rgmii1_tctl */
> > +			0x128 (PIN_OUTPUT_PULLDOWN | MUX_MODE2)	/* mii1_txd0.rgmii1_td0 */
> > +			0x124 (PIN_OUTPUT_PULLDOWN | MUX_MODE2)	/* mii1_txd1.rgmii1_td1 */
> > +			0x120 (PIN_OUTPUT_PULLDOWN | MUX_MODE2)	/* mii1_txd0.rgmii1_td2 */
> > +			0x11c (PIN_OUTPUT_PULLDOWN | MUX_MODE2)	/* mii1_txd1.rgmii1_td3 */
> > +			0x130 (PIN_INPUT_PULLDOWN | MUX_MODE2)	/* mii1_rxclk.rmii1_rclk */
> > +			0x118 (PIN_INPUT_PULLDOWN | MUX_MODE2)	/* mii1_rxdv.rgmii1_rctl */
> > +			0x140 (PIN_INPUT_PULLDOWN | MUX_MODE2)	/* mii1_rxd0.rgmii1_rd0 */
> > +			0x13c (PIN_INPUT_PULLDOWN | MUX_MODE2)	/* mii1_rxd1.rgmii1_rd1 */
> > +			0x138 (PIN_INPUT_PULLDOWN | MUX_MODE2)	/* mii1_rxd0.rgmii1_rd2 */
> > +			0x134 (PIN_INPUT_PULLDOWN | MUX_MODE2)	/* mii1_rxd1.rgmii1_rd3 */
> > +
> > +			/* Slave 2 */
> > +			0x58 (PIN_OUTPUT_PULLDOWN | MUX_MODE2)	/* gpmc_a6.rgmii2_tclk */
> > +			0x40 (PIN_OUTPUT_PULLDOWN | MUX_MODE2)	/* gpmc_a0.rgmii2_tctl */
> > +			0x54 (PIN_OUTPUT_PULLDOWN | MUX_MODE2)	/* gpmc_a5.rgmii2_td0 */
> > +			0x50 (PIN_OUTPUT_PULLDOWN | MUX_MODE2)	/* gpmc_a4.rgmii2_td1 */
> > +			0x4c (PIN_OUTPUT_PULLDOWN | MUX_MODE2)	/* gpmc_a3.rgmii2_td2 */
> > +			0x48 (PIN_OUTPUT_PULLDOWN | MUX_MODE2)	/* gpmc_a2.rgmii2_td3 */
> > +			0x5c (PIN_INPUT_PULLDOWN | MUX_MODE2)	/* gpmc_a7.rgmii2_rclk */
> > +			0x44 (PIN_INPUT_PULLDOWN | MUX_MODE2)	/* gpmc_a1.rgmii2_rtcl */
> > +			0x6c (PIN_INPUT_PULLDOWN | MUX_MODE2)	/* gpmc_a11.rgmii2_rd0 */
> > +			0x68 (PIN_INPUT_PULLDOWN | MUX_MODE2)	/* gpmc_a10.rgmii2_rd1 */
> > +			0x64 (PIN_INPUT_PULLDOWN | MUX_MODE2)	/* gpmc_a9.rgmii2_rd2 */
> > +			0x60 (PIN_INPUT_PULLDOWN | MUX_MODE2)	/* gpmc_a8.rgmii2_rd3 */
> > +		>;
> > +	};
> > +
> > +	cpsw_sleep: cpsw_sleep {
> > +		pinctrl-single,pins = <
> > +			/* Slave 1 reset value */
> > +			0x12c (PIN_INPUT_PULLDOWN | MUX_MODE7)
> > +			0x114 (PIN_INPUT_PULLDOWN | MUX_MODE7)
> > +			0x128 (PIN_INPUT_PULLDOWN | MUX_MODE7)
> > +			0x124 (PIN_INPUT_PULLDOWN | MUX_MODE7)
> > +			0x120 (PIN_INPUT_PULLDOWN | MUX_MODE7)
> > +			0x11c (PIN_INPUT_PULLDOWN | MUX_MODE7)
> > +			0x130 (PIN_INPUT_PULLDOWN | MUX_MODE7)
> > +			0x118 (PIN_INPUT_PULLDOWN | MUX_MODE7)
> > +			0x140 (PIN_INPUT_PULLDOWN | MUX_MODE7)
> > +			0x13c (PIN_INPUT_PULLDOWN | MUX_MODE7)
> > +			0x138 (PIN_INPUT_PULLDOWN | MUX_MODE7)
> > +			0x134 (PIN_INPUT_PULLDOWN | MUX_MODE7)
> > +
> > +			/* Slave 2 reset value */
> > +			0x58 (PIN_INPUT_PULLDOWN | MUX_MODE7)
> > +			0x40 (PIN_INPUT_PULLDOWN | MUX_MODE7)
> > +			0x54 (PIN_INPUT_PULLDOWN | MUX_MODE7)
> > +			0x50 (PIN_INPUT_PULLDOWN | MUX_MODE7)
> > +			0x4c (PIN_INPUT_PULLDOWN | MUX_MODE7)
> > +			0x48 (PIN_INPUT_PULLDOWN | MUX_MODE7)
> > +			0x5c (PIN_INPUT_PULLDOWN | MUX_MODE7)
> > +			0x44 (PIN_INPUT_PULLDOWN | MUX_MODE7)
> > +			0x6c (PIN_INPUT_PULLDOWN | MUX_MODE7)
> > +			0x68 (PIN_INPUT_PULLDOWN | MUX_MODE7)
> > +			0x64 (PIN_INPUT_PULLDOWN | MUX_MODE7)
> > +			0x60 (PIN_INPUT_PULLDOWN | MUX_MODE7)
> > +		>;
> > +	};
> > +
> > +	davinci_mdio_default: davinci_mdio_default {
> > +		pinctrl-single,pins = <
> > +			/* MDIO */
> > +			0x148 (PIN_INPUT_PULLUP | SLEWCTRL_FAST | MUX_MODE0)	/* mdio_data.mdio_data */
> > +			0x14c (PIN_OUTPUT_PULLUP | MUX_MODE0)			/* mdio_clk.mdio_clk */
> > +		>;
> > +	};
> > +
> > +	davinci_mdio_sleep: davinci_mdio_sleep {
> > +		pinctrl-single,pins = <
> > +			/* MDIO reset value */
> > +			0x148 (PIN_INPUT_PULLDOWN | MUX_MODE7)
> > +			0x14c (PIN_INPUT_PULLDOWN | MUX_MODE7)
> > +		>;
> > +	};
> > +
> > +	dss_pins: dss_pins {
> > +		pinctrl-single,pins = <
> > +			0x020 (PIN_OUTPUT_PULLUP | MUX_MODE1)	/* gpmc ad 8 -> DSS DATA 23 */
> > +			0x024 (PIN_OUTPUT_PULLUP | MUX_MODE1)
> > +			0x028 (PIN_OUTPUT_PULLUP | MUX_MODE1)
> > +			0x02c (PIN_OUTPUT_PULLUP | MUX_MODE1)
> > +			0x030 (PIN_OUTPUT_PULLUP | MUX_MODE1)
> > +			0x034 (PIN_OUTPUT_PULLUP | MUX_MODE1)
> > +			0x038 (PIN_OUTPUT_PULLUP | MUX_MODE1)
> > +			0x03c (PIN_OUTPUT_PULLUP | MUX_MODE1)	/* gpmc ad 15 -> DSS DATA 16 */
> > +			0x0a0 (PIN_OUTPUT_PULLUP | MUX_MODE0)	/* DSS DATA 0 */
> > +			0x0a4 (PIN_OUTPUT_PULLUP | MUX_MODE0)
> > +			0x0a8 (PIN_OUTPUT_PULLUP | MUX_MODE0)
> > +			0x0ac (PIN_OUTPUT_PULLUP | MUX_MODE0)
> > +			0x0b0 (PIN_OUTPUT_PULLUP | MUX_MODE0)
> > +			0x0b4 (PIN_OUTPUT_PULLUP | MUX_MODE0)
> > +			0x0b8 (PIN_OUTPUT_PULLUP | MUX_MODE0)
> > +			0x0bc (PIN_OUTPUT_PULLUP | MUX_MODE0)
> > +			0x0c0 (PIN_OUTPUT_PULLUP | MUX_MODE0)
> > +			0x0c4 (PIN_OUTPUT_PULLUP | MUX_MODE0)
> > +			0x0c8 (PIN_OUTPUT_PULLUP | MUX_MODE0)
> > +			0x0cc (PIN_OUTPUT_PULLUP | MUX_MODE0)
> > +			0x0d0 (PIN_OUTPUT_PULLUP | MUX_MODE0)
> > +			0x0d4 (PIN_OUTPUT_PULLUP | MUX_MODE0)
> > +			0x0d8 (PIN_OUTPUT_PULLUP | MUX_MODE0)
> > +			0x0dc (PIN_OUTPUT_PULLUP | MUX_MODE0)	/* DSS DATA 15 */
> > +			0x0e0 (PIN_OUTPUT_PULLUP | MUX_MODE0)	/* DSS VSYNC */
> > +			0x0e4 (PIN_OUTPUT_PULLUP | MUX_MODE0)	/* DSS HSYNC */
> > +			0x0e8 (PIN_OUTPUT_PULLUP | MUX_MODE0)	/* DSS PCLK */
> > +			0x0ec (PIN_OUTPUT_PULLUP | MUX_MODE0)	/* DSS AC BIAS EN */
> > +
> > +		>;
> > +	};
> > +
> > +	qspi_pins: qspi_pins {
> > +		pinctrl-single,pins = <
> > +			0x7c (PIN_OUTPUT_PULLUP | MUX_MODE3)	/* gpmc_csn0.qspi_csn */
> > +			0x88 (PIN_OUTPUT | MUX_MODE2)		/* gpmc_csn3.qspi_clk */
> > +			0x90 (PIN_INPUT_PULLUP | MUX_MODE3)	/* gpmc_advn_ale.qspi_d0 */
> > +			0x94 (PIN_INPUT_PULLUP | MUX_MODE3)	/* gpmc_oen_ren.qspi_d1 */
> > +			0x98 (PIN_INPUT_PULLUP | MUX_MODE3)	/* gpmc_wen.qspi_d2 */
> > +			0x9c (PIN_INPUT_PULLUP | MUX_MODE3)	/* gpmc_be0n_cle.qspi_d3 */
> > +		>;
> > +	};
> > +
> > +	mcasp1_pins: mcasp1_pins {
> > +		pinctrl-single,pins = <
> > +			0x10c (PIN_INPUT_PULLDOWN | MUX_MODE4)	/* mii1_crs.mcasp1_aclkx */
> > +			0x110 (PIN_INPUT_PULLDOWN | MUX_MODE4)	/* mii1_rxerr.mcasp1_fsx */
> > +			0x108 (PIN_OUTPUT_PULLDOWN | MUX_MODE4)	/* mii1_col.mcasp1_axr2 */
> > +			0x144 (PIN_INPUT_PULLDOWN | MUX_MODE4)	/* rmii1_ref_clk.mcasp1_axr3 */
> > +		>;
> > +	};
> > +
> > +	lcd_pins: lcd_pins {
> > +		pinctrl-single,pins = <
> > +			/* GPIO 5_8 to select LCD / HDMI */
> > +			0x238 (PIN_OUTPUT_PULLUP | MUX_MODE7)
> > +		>;
> > +	};
> > +};
> > +
> > +&i2c0 {
> > +        status = "okay";
> > +        pinctrl-names = "default";
> > +        pinctrl-0 = <&i2c0_pins>;
> > +
> > +	tps@2d {
> > +		compatible = "ti,tps65218";
> > +		reg = <0x2d>;
> > +	};
> > +
> > +	at24@50 {
> > +		compatible = "at24,24c256";
> > +		pagesize = <64>;
> > +		reg = <0x50>;
> > +	};
> > +};
> > +
> > +&i2c1 {
> > +        status = "okay";
> > +        pinctrl-names = "default";
> > +        pinctrl-0 = <&i2c1_pins>;
> > +
> > +	edt-ft5306@38 {
> > +		status = "okay";
> > +		compatible = "edt,edt-ft5306", "edt,edt-ft5x06";
> > +		pinctrl-names = "default";
> > +		pinctrl-0 = <&edt_ft5306_ts_pins>;
> > +		reg = <0x38>;
> > +		interrupt-parent = <&gpio0>;
> > +		interrupts = <31 0>;
> > +
> > +		wake-gpios = <&gpio1 28 GPIO_ACTIVE_HIGH>;
> > +
> > +		touchscreen-size-x = <800>;
> > +		touchscreen-size-y = <600>;
> > +	};
> > +
> > +	tlv320aic3106: tlv320aic3106@1b {
> > +		compatible = "ti,tlv320aic3106";
> > +		reg = <0x1b>;
> > +		status = "okay";
> > +
> > +		/* Regulators */
> > +		AVDD-supply = <&v33_fixed>;
> > +		IOVDD-supply = <&v33_fixed>;
> > +		DRVDD-supply = <&v33_fixed>;
> > +		DVDD-supply = <&v18_fixed>;
> > +	};
> > +};
> > +
> > +&epwmss0 {
> > +	status = "okay";
> > +};
> > +
> > +&ecap0 {
> > +	status = "okay";
> > +	pinctrl-names = "default";
> > +	pinctrl-0 = <&ecap0_pins>;
> > +};
> > +
> > +&gpio0 {
> > +	status = "okay";
> > +};
> > +
> > +&gpio1 {
> > +	status = "okay";
> > +};
> > +
> > +&gpio5 {
> > +	status = "okay";
> > +};
> > +
> > +&mmc1 {
> > +	status = "okay";
> > +	vmmc-supply = <&vmmcsd_fixed>;
> > +	bus-width = <4>;
> > +	pinctrl-names = "default";
> > +	pinctrl-0 = <&mmc1_pins>;
> > +	cd-gpios = <&gpio0 6 GPIO_ACTIVE_HIGH>;
> > +};
> > +
> > +&usb2_phy1 {
> > +	status = "okay";
> > +};
> > +
> > +&usb1 {
> > +	dr_mode = "peripheral";
> > +	status = "okay";
> > +};
> > +
> > +&usb2_phy2 {
> > +	status = "okay";
> > +};
> > +
> > +&usb2 {
> > +	dr_mode = "host";
> > +	status = "okay";
> > +};
> > +
> > +&qspi {
> > +	status = "okay";
> > +	pinctrl-names = "default";
> > +	pinctrl-0 = <&qspi_pins>;
> > +
> > +	spi-max-frequency = <48000000>;
> > +	m25p80@0 {
> > +		compatible = "mx66l51235l";
> > +		spi-max-frequency = <48000000>;
> > +		reg = <0>;
> > +		spi-cpol;
> > +		spi-cpha;
> > +		spi-tx-bus-width = <1>;
> > +		spi-rx-bus-width = <4>;
> > +		#address-cells = <1>;
> > +		#size-cells = <1>;
> > +
> > +		/* MTD partition table.
> > +		 * The ROM checks the first 512KiB
> > +		 * for a valid file to boot(XIP).
> > +		 */
> > +		partition@0 {
> > +			label = "QSPI.U_BOOT";
> > +			reg = <0x00000000 0x000080000>;
> > +		};
> > +		partition@1 {
> > +			label = "QSPI.U_BOOT.backup";
> > +			reg = <0x00080000 0x00080000>;
> > +		};
> > +		partition@2 {
> > +			label = "QSPI.U-BOOT-SPL_OS";
> > +			reg = <0x00100000 0x00010000>;
> > +		};
> > +		partition@3 {
> > +			label = "QSPI.U_BOOT_ENV";
> > +			reg = <0x00110000 0x00010000>;
> > +		};
> > +		partition@4 {
> > +			label = "QSPI.U-BOOT-ENV.backup";
> > +			reg = <0x00120000 0x00010000>;
> > +		};
> > +		partition@5 {
> > +			label = "QSPI.KERNEL";
> > +			reg = <0x00130000 0x0800000>;
> > +		};
> > +		partition@6 {
> > +			label = "QSPI.FILESYSTEM";
> > +			reg = <0x00930000 0x36D0000>;
> > +		};
> > +	};
> > +};
> > +
> > +&mac {
> > +	pinctrl-names = "default", "sleep";
> > +	pinctrl-0 = <&cpsw_default>;
> > +	pinctrl-1 = <&cpsw_sleep>;
> > +	dual_emac = <1>;
> > +	status = "okay";
> > +};
> > +
> > +&davinci_mdio {
> > +	pinctrl-names = "default", "sleep";
> > +	pinctrl-0 = <&davinci_mdio_default>;
> > +	pinctrl-1 = <&davinci_mdio_sleep>;
> > +	status = "okay";
> > +};
> > +
> > +&cpsw_emac0 {
> > +	phy_id = <&davinci_mdio>, <4>;
> > +	phy-mode = "rgmii";
> > +	dual_emac_res_vlan = <1>;
> > +};
> > +
> > +&cpsw_emac1 {
> > +	phy_id = <&davinci_mdio>, <5>;
> > +	phy-mode = "rgmii";
> > +	dual_emac_res_vlan = <2>;
> > +};
> > +
> > +&elm {
> > +	status = "okay";
> > +};
> > +
> > +&mcasp1 {
> > +	pinctrl-names = "default";
> > +	pinctrl-0 = <&mcasp1_pins>;
> > +
> > +	status = "okay";
> > +
> > +	op-mode = <0>;
> > +	tdm-slots = <2>;
> > +	serial-dir = <
> > +		0 0 1 2
> > +	>;
> > +
> > +	tx-num-evt = <1>;
> > +	rx-num-evt = <1>;
> > +};
> > +
> > +&dss {
> > +	status = "okay";
> > +
> > +	pinctrl-names = "default";
> > +	pinctrl-0 = <&dss_pins>;
> > +
> > +	port {
> > +		dpi_out: endpoint@0 {
> > +			remote-endpoint = <&lcd_in>;
> > +			data-lines = <24>;
> > +		};
> > +	};
> > +};
> > -- 
> > 2.0.0.rc1
> > 
> 
> -- 
> balbi



-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH 2/2] arm: dts: add support for AM437x StarterKit

[Tony Lindgren]

* Felipe Balbi <balbi@ti.com> [140613 09:33]:
> On Fri, Jun 13, 2014 at 11:23:34AM -0500, Felipe Balbi wrote:
> > On Fri, Jun 13, 2014 at 11:15:47AM -0500, Felipe Balbi wrote:
> > > --- /dev/null
> > > +++ b/arch/arm/boot/dts/am437x-sk-evm.dts
> > > @@ -0,0 +1,539 @@
> > > +/*
> > > + * Copyright (C) 2014 Texas Instruments Incorporated - http://www.ti.com/
> > > + *
> > > + * This program is free software; you can redistribute it and/or modify
> > > + * it under the terms of the GNU General Public License version 2 as
> > > + * published by the Free Software Foundation.
> > > + */
> > > +
> > > +/* AM437x SK EVM */
> > > +
> > > +/dts-v1/;
> > > +
> > > +#include "am4372.dtsi"
> > > +#include <dt-bindings/pinctrl/am43xx.h>
> > > +#include <dt-bindings/pwm/pwm.h>
> > > +#include <dt-bindings/gpio/gpio.h>
> > > +#include <dt-bindings/input/input.h>
> > > +
> > > +/ {
> > > +	model = "TI AM437x SK EVM";
> > > +	compatible = "ti,am437x-sk-evm","ti,am4372","ti,am43";
> > > +
> > > +	aliases {
> > > +		display0 = &lcd0;
> > > +	};
> > > +
> > > +	vmmcsd_fixed: fixedregulator-sd {
> > > +		compatible = "regulator-fixed";
> > > +		regulator-name = "vmmcsd_fixed";
> > > +		regulator-min-microvolt = <3300000>;
> > > +		regulator-max-microvolt = <3300000>;
> > > +		enable-active-high;
> > > +	};
> > > +
> > > +	v33_fixed: fixedregulator-v33 {
> > > +		compatible = "regulator-fixed";
> > > +		regulator-name = "v33_fixed";
> > > +		regulator-min-microvolt = <3300000>;
> > > +		regulator-max-microvolt = <3300000>;
> > > +		enable-active-high;
> > > +	};
> > > +
> > > +	v18_fixed: fixedregulator-v18 {
> > > +		compatible = "regulator-fixed";
> > > +		regulator-name = "v18_fixed";
> > > +		regulator-min-microvolt = <1800000>;
> > > +		regulator-max-microvolt = <1800000>;
> > > +		enable-active-high;
> > > +	};

Chances are these are not fixed regulators.. Typically the these
come from external regulators controlled by GPIO pins. Sounds
like you have the schematics so it would be best to verify it.
If they come from something not yet supported, let's at least
document it with comments.

Also looks like all the am43xx boards are using vmmcsd_fixed,
might be worth checking those as well while at it.

Regards,

Tony

Re: [PATCH 2/2] arm: dts: add support for AM437x StarterKit

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 2598 bytes --]

Hi,

On Mon, Jun 16, 2014 at 12:27:21AM -0700, Tony Lindgren wrote:
> * Felipe Balbi <balbi-l0cyMroinI0@public.gmane.org> [140613 09:33]:
> > On Fri, Jun 13, 2014 at 11:23:34AM -0500, Felipe Balbi wrote:
> > > On Fri, Jun 13, 2014 at 11:15:47AM -0500, Felipe Balbi wrote:
> > > > --- /dev/null
> > > > +++ b/arch/arm/boot/dts/am437x-sk-evm.dts
> > > > @@ -0,0 +1,539 @@
> > > > +/*
> > > > + * Copyright (C) 2014 Texas Instruments Incorporated - http://www.ti.com/
> > > > + *
> > > > + * This program is free software; you can redistribute it and/or modify
> > > > + * it under the terms of the GNU General Public License version 2 as
> > > > + * published by the Free Software Foundation.
> > > > + */
> > > > +
> > > > +/* AM437x SK EVM */
> > > > +
> > > > +/dts-v1/;
> > > > +
> > > > +#include "am4372.dtsi"
> > > > +#include <dt-bindings/pinctrl/am43xx.h>
> > > > +#include <dt-bindings/pwm/pwm.h>
> > > > +#include <dt-bindings/gpio/gpio.h>
> > > > +#include <dt-bindings/input/input.h>
> > > > +
> > > > +/ {
> > > > +	model = "TI AM437x SK EVM";
> > > > +	compatible = "ti,am437x-sk-evm","ti,am4372","ti,am43";
> > > > +
> > > > +	aliases {
> > > > +		display0 = &lcd0;
> > > > +	};
> > > > +
> > > > +	vmmcsd_fixed: fixedregulator-sd {
> > > > +		compatible = "regulator-fixed";
> > > > +		regulator-name = "vmmcsd_fixed";
> > > > +		regulator-min-microvolt = <3300000>;
> > > > +		regulator-max-microvolt = <3300000>;
> > > > +		enable-active-high;
> > > > +	};
> > > > +
> > > > +	v33_fixed: fixedregulator-v33 {
> > > > +		compatible = "regulator-fixed";
> > > > +		regulator-name = "v33_fixed";
> > > > +		regulator-min-microvolt = <3300000>;
> > > > +		regulator-max-microvolt = <3300000>;
> > > > +		enable-active-high;
> > > > +	};
> > > > +
> > > > +	v18_fixed: fixedregulator-v18 {
> > > > +		compatible = "regulator-fixed";
> > > > +		regulator-name = "v18_fixed";
> > > > +		regulator-min-microvolt = <1800000>;
> > > > +		regulator-max-microvolt = <1800000>;
> > > > +		enable-active-high;
> > > > +	};
> 
> Chances are these are not fixed regulators.. Typically the these
> come from external regulators controlled by GPIO pins. Sounds
> like you have the schematics so it would be best to verify it.
> If they come from something not yet supported, let's at least
> document it with comments.

sure, let me just make sure of it.

> Also looks like all the am43xx boards are using vmmcsd_fixed,
> might be worth checking those as well while at it.

I'll need help testing, but sure thing.

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH 0/2] Add support for am437x StarterKit

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 1113 bytes --]

Fixing Benoit's address

On Fri, Jun 13, 2014 at 11:15:45AM -0500, Felipe Balbi wrote:
> Hi,
> 
> The following two patches (one of which is a resend from a patch which has been
> pending since May 19th!) enable AM437x StarterKit to boot in mainline.
> 
> Patches have been tested on top of 27a4e439fe5cd92b70137ae237c7aa6888c07b5a
> (next-20140610). With these we even have X with I3 running on this board, with
> audio, touchscreen, networking, blinky leds and others.
> 
> Felipe Balbi (1):
>   arm: dts: add support for AM437x StarterKit
> 
> Sathya Prakash M R (1):
>   ARM: AM43xx: hwmod: add DSS hwmod data
> 
>  .../devicetree/bindings/arm/omap/omap.txt          |   3 +
>  arch/arm/boot/dts/Makefile                         |   1 +
>  arch/arm/boot/dts/am437x-sk-evm.dts                | 539 +++++++++++++++++++++
>  arch/arm/mach-omap2/omap_hwmod_43xx_data.c         |  98 ++++
>  arch/arm/mach-omap2/prcm43xx.h                     |   1 +
>  5 files changed, 642 insertions(+)
>  create mode 100644 arch/arm/boot/dts/am437x-sk-evm.dts
> 
> -- 
> 2.0.0.rc1
> 

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]