Fwd: [PATCH 2/5] ARM: OMAP3+: hwmod: Add AM33XX HWMOD data for davinci_mdio

Fwd: [PATCH 2/5] ARM: OMAP3+: hwmod: Add AM33XX HWMOD data for davinci_mdio

[Richard Cochran]

Paul,

Would you please take this bugfix for 3.7-rc2? The suggestion to mail
you came from Toni Lindgren. The context where it came from is here:

http://lists.arm.linux.org.uk/lurker/message/20121015.191630.bdae3c50.en.html

Thanks,
Richard

----- Forwarded message from Richard Cochran <richardcochran@gmail.com> -----

Date: Mon, 15 Oct 2012 21:16:32 +0200
From: Richard Cochran <richardcochran@gmail.com>
To: netdev@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org, Arnd Bergmann <arnd@arndb.de>,
	David Miller <davem@davemloft.net>,
	Russell King <linux@arm.linux.org.uk>,
	Mugunthan V N <mugunthanvnm@ti.com>
Subject: [PATCH 2/5] ARM: OMAP3+: hwmod: Add AM33XX HWMOD data for davinci_mdio
X-Mailer: git-send-email 1.7.2.5

From: Mugunthan V N <mugunthanvnm@ti.com>

This patch adds minimal hwmod support for davinci mdio driver. This patch
requires rework on parent child relation between cpsw and davinci mdio
hwmod data to support runtime PM.

Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
---
 arch/arm/mach-omap2/omap_hwmod_33xx_data.c |   34 ++++++++++++++++++++++++++-
 1 files changed, 32 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
index 59d5c1c..f96bbc0 100644
--- a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
@@ -650,8 +650,7 @@ static struct omap_hwmod_class_sysconfig am33xx_cpgmac_sysc = {
 	.rev_offs	= 0x0,
 	.sysc_offs	= 0x8,
 	.syss_offs	= 0x4,
-	.sysc_flags	= (SYSC_HAS_SIDLEMODE | SYSC_HAS_MIDLEMODE |
-			   SYSS_HAS_RESET_STATUS),
+	.sysc_flags	= (SYSC_HAS_SIDLEMODE | SYSC_HAS_MIDLEMODE),
 	.idlemodes	= (SIDLE_FORCE | SIDLE_NO | MSTANDBY_FORCE |
 			   MSTANDBY_NO),
 	.sysc_fields	= &omap_hwmod_sysc_type3,
@@ -682,6 +681,8 @@ static struct omap_hwmod am33xx_cpgmac0_hwmod = {
 			.modulemode	= MODULEMODE_SWCTRL,
 		},
 	},
+	.flags		= (HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY |
+			   HWMOD_INIT_NO_RESET | HWMOD_INIT_NO_IDLE),
 };
 
 /*
@@ -2510,6 +2511,34 @@ static struct omap_hwmod_addr_space am33xx_elm_addr_space[] = {
 	{ }
 };
 
+/* mdio class */
+static struct omap_hwmod_class am33xx_mdio_hwmod_class = {
+	.name		= "davinci_mdio",
+};
+
+struct omap_hwmod_addr_space am33xx_mdio_addr_space[] = {
+	{
+		.pa_start	= 0x4A101000,
+		.pa_end		= 0x4A101000 + SZ_256 - 1,
+		.flags		= ADDR_MAP_ON_INIT,
+	},
+	{ }
+};
+
+static struct omap_hwmod am33xx_mdio_hwmod = {
+	.name		= "davinci_mdio",
+	.class		= &am33xx_mdio_hwmod_class,
+	.clkdm_name	= "cpsw_125mhz_clkdm",
+	.main_clk	= "cpsw_125mhz_gclk",
+};
+
+struct omap_hwmod_ocp_if am33xx_cpgmac0__mdio = {
+	.master		= &am33xx_cpgmac0_hwmod,
+	.slave		= &am33xx_mdio_hwmod,
+	.addr		= am33xx_mdio_addr_space,
+	.user		= OCP_USER_MPU,
+};
+
 static struct omap_hwmod_ocp_if am33xx_l4_ls__elm = {
 	.master		= &am33xx_l4_ls_hwmod,
 	.slave		= &am33xx_elm_hwmod,
@@ -3371,6 +3400,7 @@ static struct omap_hwmod_ocp_if *am33xx_hwmod_ocp_ifs[] __initdata = {
 	&am33xx_l3_main__tptc2,
 	&am33xx_l3_s__usbss,
 	&am33xx_l4_hs__cpgmac0,
+	&am33xx_cpgmac0__mdio,
 	NULL,
 };
 
-- 
1.7.2.5


----- End forwarded message -----

Fwd: [PATCH 2/5] ARM: OMAP3+: hwmod: Add AM33XX HWMOD data for davinci_mdio

[Richard Cochran]

Paul,

Would you please take this bugfix for 3.7-rc2? The suggestion to mail
you came from Toni Lindgren. The context where it came from is here:

http://lists.arm.linux.org.uk/lurker/message/20121015.191630.bdae3c50.en.html

Thanks,
Richard

----- Forwarded message from Richard Cochran <richardcochran@gmail.com> -----

Date: Mon, 15 Oct 2012 21:16:32 +0200
From: Richard Cochran <richardcochran@gmail.com>
To: netdev at vger.kernel.org
Cc: linux-arm-kernel at lists.infradead.org, Arnd Bergmann <arnd@arndb.de>,
	David Miller <davem@davemloft.net>,
	Russell King <linux@arm.linux.org.uk>,
	Mugunthan V N <mugunthanvnm@ti.com>
Subject: [PATCH 2/5] ARM: OMAP3+: hwmod: Add AM33XX HWMOD data for davinci_mdio
X-Mailer: git-send-email 1.7.2.5

From: Mugunthan V N <mugunthanvnm@ti.com>

This patch adds minimal hwmod support for davinci mdio driver. This patch
requires rework on parent child relation between cpsw and davinci mdio
hwmod data to support runtime PM.

Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
---
 arch/arm/mach-omap2/omap_hwmod_33xx_data.c |   34 ++++++++++++++++++++++++++-
 1 files changed, 32 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
index 59d5c1c..f96bbc0 100644
--- a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
@@ -650,8 +650,7 @@ static struct omap_hwmod_class_sysconfig am33xx_cpgmac_sysc = {
 	.rev_offs	= 0x0,
 	.sysc_offs	= 0x8,
 	.syss_offs	= 0x4,
-	.sysc_flags	= (SYSC_HAS_SIDLEMODE | SYSC_HAS_MIDLEMODE |
-			   SYSS_HAS_RESET_STATUS),
+	.sysc_flags	= (SYSC_HAS_SIDLEMODE | SYSC_HAS_MIDLEMODE),
 	.idlemodes	= (SIDLE_FORCE | SIDLE_NO | MSTANDBY_FORCE |
 			   MSTANDBY_NO),
 	.sysc_fields	= &omap_hwmod_sysc_type3,
@@ -682,6 +681,8 @@ static struct omap_hwmod am33xx_cpgmac0_hwmod = {
 			.modulemode	= MODULEMODE_SWCTRL,
 		},
 	},
+	.flags		= (HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY |
+			   HWMOD_INIT_NO_RESET | HWMOD_INIT_NO_IDLE),
 };
 
 /*
@@ -2510,6 +2511,34 @@ static struct omap_hwmod_addr_space am33xx_elm_addr_space[] = {
 	{ }
 };
 
+/* mdio class */
+static struct omap_hwmod_class am33xx_mdio_hwmod_class = {
+	.name		= "davinci_mdio",
+};
+
+struct omap_hwmod_addr_space am33xx_mdio_addr_space[] = {
+	{
+		.pa_start	= 0x4A101000,
+		.pa_end		= 0x4A101000 + SZ_256 - 1,
+		.flags		= ADDR_MAP_ON_INIT,
+	},
+	{ }
+};
+
+static struct omap_hwmod am33xx_mdio_hwmod = {
+	.name		= "davinci_mdio",
+	.class		= &am33xx_mdio_hwmod_class,
+	.clkdm_name	= "cpsw_125mhz_clkdm",
+	.main_clk	= "cpsw_125mhz_gclk",
+};
+
+struct omap_hwmod_ocp_if am33xx_cpgmac0__mdio = {
+	.master		= &am33xx_cpgmac0_hwmod,
+	.slave		= &am33xx_mdio_hwmod,
+	.addr		= am33xx_mdio_addr_space,
+	.user		= OCP_USER_MPU,
+};
+
 static struct omap_hwmod_ocp_if am33xx_l4_ls__elm = {
 	.master		= &am33xx_l4_ls_hwmod,
 	.slave		= &am33xx_elm_hwmod,
@@ -3371,6 +3400,7 @@ static struct omap_hwmod_ocp_if *am33xx_hwmod_ocp_ifs[] __initdata = {
 	&am33xx_l3_main__tptc2,
 	&am33xx_l3_s__usbss,
 	&am33xx_l4_hs__cpgmac0,
+	&am33xx_cpgmac0__mdio,
 	NULL,
 };
 
-- 
1.7.2.5


----- End forwarded message -----

Re: Fwd: [PATCH 2/5] ARM: OMAP3+: hwmod: Add AM33XX HWMOD data for davinci_mdio

[Paul Walmsley]

Hi Richard

On Wed, 17 Oct 2012, Richard Cochran wrote:

> Would you please take this bugfix for 3.7-rc2? The suggestion to mail
> you came from Toni Lindgren. The context where it came from is here:
> 
> http://lists.arm.linux.org.uk/lurker/message/20121015.191630.bdae3c50.en.html

This patch appears to add a new feature, correct?  I don't think the CPSW 
could have worked in the past without this data present.  So it looks to 
me like this is 3.8 material, unless Tony would like it to go in sooner?


- Paul

> 
> Thanks,
> Richard
> 
> ----- Forwarded message from Richard Cochran <richardcochran@gmail.com> -----
> 
> Date: Mon, 15 Oct 2012 21:16:32 +0200
> From: Richard Cochran <richardcochran@gmail.com>
> To: netdev@vger.kernel.org
> Cc: linux-arm-kernel@lists.infradead.org, Arnd Bergmann <arnd@arndb.de>,
> 	David Miller <davem@davemloft.net>,
> 	Russell King <linux@arm.linux.org.uk>,
> 	Mugunthan V N <mugunthanvnm@ti.com>
> Subject: [PATCH 2/5] ARM: OMAP3+: hwmod: Add AM33XX HWMOD data for davinci_mdio
> X-Mailer: git-send-email 1.7.2.5
> 
> From: Mugunthan V N <mugunthanvnm@ti.com>
> 
> This patch adds minimal hwmod support for davinci mdio driver. This patch
> requires rework on parent child relation between cpsw and davinci mdio
> hwmod data to support runtime PM.
> 
> Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
> ---
>  arch/arm/mach-omap2/omap_hwmod_33xx_data.c |   34 ++++++++++++++++++++++++++-
>  1 files changed, 32 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
> index 59d5c1c..f96bbc0 100644
> --- a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
> +++ b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
> @@ -650,8 +650,7 @@ static struct omap_hwmod_class_sysconfig am33xx_cpgmac_sysc = {
>  	.rev_offs	= 0x0,
>  	.sysc_offs	= 0x8,
>  	.syss_offs	= 0x4,
> -	.sysc_flags	= (SYSC_HAS_SIDLEMODE | SYSC_HAS_MIDLEMODE |
> -			   SYSS_HAS_RESET_STATUS),
> +	.sysc_flags	= (SYSC_HAS_SIDLEMODE | SYSC_HAS_MIDLEMODE),
>  	.idlemodes	= (SIDLE_FORCE | SIDLE_NO | MSTANDBY_FORCE |
>  			   MSTANDBY_NO),
>  	.sysc_fields	= &omap_hwmod_sysc_type3,
> @@ -682,6 +681,8 @@ static struct omap_hwmod am33xx_cpgmac0_hwmod = {
>  			.modulemode	= MODULEMODE_SWCTRL,
>  		},
>  	},
> +	.flags		= (HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY |
> +			   HWMOD_INIT_NO_RESET | HWMOD_INIT_NO_IDLE),
>  };
>  
>  /*
> @@ -2510,6 +2511,34 @@ static struct omap_hwmod_addr_space am33xx_elm_addr_space[] = {
>  	{ }
>  };
>  
> +/* mdio class */
> +static struct omap_hwmod_class am33xx_mdio_hwmod_class = {
> +	.name		= "davinci_mdio",
> +};
> +
> +struct omap_hwmod_addr_space am33xx_mdio_addr_space[] = {
> +	{
> +		.pa_start	= 0x4A101000,
> +		.pa_end		= 0x4A101000 + SZ_256 - 1,
> +		.flags		= ADDR_MAP_ON_INIT,
> +	},
> +	{ }
> +};
> +
> +static struct omap_hwmod am33xx_mdio_hwmod = {
> +	.name		= "davinci_mdio",
> +	.class		= &am33xx_mdio_hwmod_class,
> +	.clkdm_name	= "cpsw_125mhz_clkdm",
> +	.main_clk	= "cpsw_125mhz_gclk",
> +};
> +
> +struct omap_hwmod_ocp_if am33xx_cpgmac0__mdio = {
> +	.master		= &am33xx_cpgmac0_hwmod,
> +	.slave		= &am33xx_mdio_hwmod,
> +	.addr		= am33xx_mdio_addr_space,
> +	.user		= OCP_USER_MPU,
> +};
> +
>  static struct omap_hwmod_ocp_if am33xx_l4_ls__elm = {
>  	.master		= &am33xx_l4_ls_hwmod,
>  	.slave		= &am33xx_elm_hwmod,
> @@ -3371,6 +3400,7 @@ static struct omap_hwmod_ocp_if *am33xx_hwmod_ocp_ifs[] __initdata = {
>  	&am33xx_l3_main__tptc2,
>  	&am33xx_l3_s__usbss,
>  	&am33xx_l4_hs__cpgmac0,
> +	&am33xx_cpgmac0__mdio,
>  	NULL,
>  };
>  
> -- 
> 1.7.2.5
> 
> 
> ----- End forwarded message -----
> 


- Paul

Fwd: [PATCH 2/5] ARM: OMAP3+: hwmod: Add AM33XX HWMOD data for davinci_mdio

[Paul Walmsley]

Hi Richard

On Wed, 17 Oct 2012, Richard Cochran wrote:

> Would you please take this bugfix for 3.7-rc2? The suggestion to mail
> you came from Toni Lindgren. The context where it came from is here:
> 
> http://lists.arm.linux.org.uk/lurker/message/20121015.191630.bdae3c50.en.html

This patch appears to add a new feature, correct?  I don't think the CPSW 
could have worked in the past without this data present.  So it looks to 
me like this is 3.8 material, unless Tony would like it to go in sooner?


- Paul

> 
> Thanks,
> Richard
> 
> ----- Forwarded message from Richard Cochran <richardcochran@gmail.com> -----
> 
> Date: Mon, 15 Oct 2012 21:16:32 +0200
> From: Richard Cochran <richardcochran@gmail.com>
> To: netdev at vger.kernel.org
> Cc: linux-arm-kernel at lists.infradead.org, Arnd Bergmann <arnd@arndb.de>,
> 	David Miller <davem@davemloft.net>,
> 	Russell King <linux@arm.linux.org.uk>,
> 	Mugunthan V N <mugunthanvnm@ti.com>
> Subject: [PATCH 2/5] ARM: OMAP3+: hwmod: Add AM33XX HWMOD data for davinci_mdio
> X-Mailer: git-send-email 1.7.2.5
> 
> From: Mugunthan V N <mugunthanvnm@ti.com>
> 
> This patch adds minimal hwmod support for davinci mdio driver. This patch
> requires rework on parent child relation between cpsw and davinci mdio
> hwmod data to support runtime PM.
> 
> Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
> ---
>  arch/arm/mach-omap2/omap_hwmod_33xx_data.c |   34 ++++++++++++++++++++++++++-
>  1 files changed, 32 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
> index 59d5c1c..f96bbc0 100644
> --- a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
> +++ b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
> @@ -650,8 +650,7 @@ static struct omap_hwmod_class_sysconfig am33xx_cpgmac_sysc = {
>  	.rev_offs	= 0x0,
>  	.sysc_offs	= 0x8,
>  	.syss_offs	= 0x4,
> -	.sysc_flags	= (SYSC_HAS_SIDLEMODE | SYSC_HAS_MIDLEMODE |
> -			   SYSS_HAS_RESET_STATUS),
> +	.sysc_flags	= (SYSC_HAS_SIDLEMODE | SYSC_HAS_MIDLEMODE),
>  	.idlemodes	= (SIDLE_FORCE | SIDLE_NO | MSTANDBY_FORCE |
>  			   MSTANDBY_NO),
>  	.sysc_fields	= &omap_hwmod_sysc_type3,
> @@ -682,6 +681,8 @@ static struct omap_hwmod am33xx_cpgmac0_hwmod = {
>  			.modulemode	= MODULEMODE_SWCTRL,
>  		},
>  	},
> +	.flags		= (HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY |
> +			   HWMOD_INIT_NO_RESET | HWMOD_INIT_NO_IDLE),
>  };
>  
>  /*
> @@ -2510,6 +2511,34 @@ static struct omap_hwmod_addr_space am33xx_elm_addr_space[] = {
>  	{ }
>  };
>  
> +/* mdio class */
> +static struct omap_hwmod_class am33xx_mdio_hwmod_class = {
> +	.name		= "davinci_mdio",
> +};
> +
> +struct omap_hwmod_addr_space am33xx_mdio_addr_space[] = {
> +	{
> +		.pa_start	= 0x4A101000,
> +		.pa_end		= 0x4A101000 + SZ_256 - 1,
> +		.flags		= ADDR_MAP_ON_INIT,
> +	},
> +	{ }
> +};
> +
> +static struct omap_hwmod am33xx_mdio_hwmod = {
> +	.name		= "davinci_mdio",
> +	.class		= &am33xx_mdio_hwmod_class,
> +	.clkdm_name	= "cpsw_125mhz_clkdm",
> +	.main_clk	= "cpsw_125mhz_gclk",
> +};
> +
> +struct omap_hwmod_ocp_if am33xx_cpgmac0__mdio = {
> +	.master		= &am33xx_cpgmac0_hwmod,
> +	.slave		= &am33xx_mdio_hwmod,
> +	.addr		= am33xx_mdio_addr_space,
> +	.user		= OCP_USER_MPU,
> +};
> +
>  static struct omap_hwmod_ocp_if am33xx_l4_ls__elm = {
>  	.master		= &am33xx_l4_ls_hwmod,
>  	.slave		= &am33xx_elm_hwmod,
> @@ -3371,6 +3400,7 @@ static struct omap_hwmod_ocp_if *am33xx_hwmod_ocp_ifs[] __initdata = {
>  	&am33xx_l3_main__tptc2,
>  	&am33xx_l3_s__usbss,
>  	&am33xx_l4_hs__cpgmac0,
> +	&am33xx_cpgmac0__mdio,
>  	NULL,
>  };
>  
> -- 
> 1.7.2.5
> 
> 
> ----- End forwarded message -----
> 


- Paul

Re: Fwd: [PATCH 2/5] ARM: OMAP3+: hwmod: Add AM33XX HWMOD data for davinci_mdio

[Tony Lindgren]

* Paul Walmsley <paul@pwsan.com> [121017 16:39]:
> Hi Richard
> 
> On Wed, 17 Oct 2012, Richard Cochran wrote:
> 
> > Would you please take this bugfix for 3.7-rc2? The suggestion to mail
> > you came from Toni Lindgren. The context where it came from is here:
> > 
> > http://lists.arm.linux.org.uk/lurker/message/20121015.191630.bdae3c50.en.html
> 
> This patch appears to add a new feature, correct?  I don't think the CPSW 
> could have worked in the past without this data present.  So it looks to 
> me like this is 3.8 material, unless Tony would like it to go in sooner?

Yeah unless it fixes something, we should just queue it for v3.8 merge
window.

Regards,

Tony

Fwd: [PATCH 2/5] ARM: OMAP3+: hwmod: Add AM33XX HWMOD data for davinci_mdio

[Tony Lindgren]

* Paul Walmsley <paul@pwsan.com> [121017 16:39]:
> Hi Richard
> 
> On Wed, 17 Oct 2012, Richard Cochran wrote:
> 
> > Would you please take this bugfix for 3.7-rc2? The suggestion to mail
> > you came from Toni Lindgren. The context where it came from is here:
> > 
> > http://lists.arm.linux.org.uk/lurker/message/20121015.191630.bdae3c50.en.html
> 
> This patch appears to add a new feature, correct?  I don't think the CPSW 
> could have worked in the past without this data present.  So it looks to 
> me like this is 3.8 material, unless Tony would like it to go in sooner?

Yeah unless it fixes something, we should just queue it for v3.8 merge
window.

Regards,

Tony

Re: Fwd: [PATCH 2/5] ARM: OMAP3+: hwmod: Add AM33XX HWMOD data for davinci_mdio

[Richard Cochran]

On Wed, Oct 17, 2012 at 04:50:46PM -0700, Tony Lindgren wrote:
> * Paul Walmsley <paul@pwsan.com> [121017 16:39]:
> > Hi Richard
> > 
> > On Wed, 17 Oct 2012, Richard Cochran wrote:
> > 
> > > Would you please take this bugfix for 3.7-rc2? The suggestion to mail
> > > you came from Toni Lindgren. The context where it came from is here:
> > > 
> > > http://lists.arm.linux.org.uk/lurker/message/20121015.191630.bdae3c50.en.html
> > 
> > This patch appears to add a new feature, correct?  I don't think the CPSW 
> > could have worked in the past without this data present.  So it looks to 
> > me like this is 3.8 material, unless Tony would like it to go in sooner?
> 
> Yeah unless it fixes something, we should just queue it for v3.8 merge
> window.

So there has been this cpsw driver since v3.4-rc1~177^2~5

   df82859 netdev: driver: ethernet: Add TI CPSW driver

and four people signed off on it, so it must have been working at one
point. Since the device tree make-over, the driver is a derelict, and
thus the present patch is fixing a regression.

I just want the already merged driver to work with the vanilla
kernel. Is that too much to ask?

Thanks,
Richard

Fwd: [PATCH 2/5] ARM: OMAP3+: hwmod: Add AM33XX HWMOD data for davinci_mdio

[Richard Cochran]

On Wed, Oct 17, 2012 at 04:50:46PM -0700, Tony Lindgren wrote:
> * Paul Walmsley <paul@pwsan.com> [121017 16:39]:
> > Hi Richard
> > 
> > On Wed, 17 Oct 2012, Richard Cochran wrote:
> > 
> > > Would you please take this bugfix for 3.7-rc2? The suggestion to mail
> > > you came from Toni Lindgren. The context where it came from is here:
> > > 
> > > http://lists.arm.linux.org.uk/lurker/message/20121015.191630.bdae3c50.en.html
> > 
> > This patch appears to add a new feature, correct?  I don't think the CPSW 
> > could have worked in the past without this data present.  So it looks to 
> > me like this is 3.8 material, unless Tony would like it to go in sooner?
> 
> Yeah unless it fixes something, we should just queue it for v3.8 merge
> window.

So there has been this cpsw driver since v3.4-rc1~177^2~5

   df82859 netdev: driver: ethernet: Add TI CPSW driver

and four people signed off on it, so it must have been working at one
point. Since the device tree make-over, the driver is a derelict, and
thus the present patch is fixing a regression.

I just want the already merged driver to work with the vanilla
kernel. Is that too much to ask?

Thanks,
Richard

Re: Fwd: [PATCH 2/5] ARM: OMAP3+: hwmod: Add AM33XX HWMOD data for davinci_mdio

[Paul Walmsley]

On Thu, 18 Oct 2012, Richard Cochran wrote:

> So there has been this cpsw driver since v3.4-rc1~177^2~5
> 
>    df82859 netdev: driver: ethernet: Add TI CPSW driver
> 
> and four people signed off on it, so it must have been working at one
> point.

The signoffs just mean that those people are asserting that the code is 
covered under an appropriate license, or are passing it on through the 
maintainer hierarchy.  See 

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob;f=Documentation/SubmittingPatches;h=c379a2a6949f1c1cac04fb6f185c633512f37061;hb=HEAD#l298

It doesn't necessarily mean that the driver is usable in that kernel 
release.

> Since the device tree make-over, the driver is a derelict, and thus the 
> present patch is fixing a regression.

Probably the driver was submitted before any SoC integration support was 
available.  Grepping for 'cpsw' under arch/ turns up only AM33xx.  AM335x 
didn't have device enumeration support in the mainline kernel until 3.7, 
via commit a2cfc509bc4eeef9f5c4607b1203f17f22ea2a36 ("ARM: OMAP3+: hwmod: 
Add AM33XX HWMOD data").  So I don't see how it could have worked with 
mainline.

> I just want the already merged driver to work with the vanilla
> kernel. Is that too much to ask?

It's a very reasonable wish and your patches are certainly appreciated.

But it seems that the CPSW has never worked in the mainline kernel.  So 
this particular patch is not fixing a regression.  Therefore we shouldn't 
send it upstream during the -rc time period.  Instead we'll schedule it to 
be sent a few weeks later, during the 3.8 merge window.

Either way, the patch is likely to make it into the mainline kernel.  
It's just that it will probably take a few weeks longer than you might 
like.


- Paul

Fwd: [PATCH 2/5] ARM: OMAP3+: hwmod: Add AM33XX HWMOD data for davinci_mdio

[Paul Walmsley]

On Thu, 18 Oct 2012, Richard Cochran wrote:

> So there has been this cpsw driver since v3.4-rc1~177^2~5
> 
>    df82859 netdev: driver: ethernet: Add TI CPSW driver
> 
> and four people signed off on it, so it must have been working at one
> point.

The signoffs just mean that those people are asserting that the code is 
covered under an appropriate license, or are passing it on through the 
maintainer hierarchy.  See 

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob;f=Documentation/SubmittingPatches;h=c379a2a6949f1c1cac04fb6f185c633512f37061;hb=HEAD#l298

It doesn't necessarily mean that the driver is usable in that kernel 
release.

> Since the device tree make-over, the driver is a derelict, and thus the 
> present patch is fixing a regression.

Probably the driver was submitted before any SoC integration support was 
available.  Grepping for 'cpsw' under arch/ turns up only AM33xx.  AM335x 
didn't have device enumeration support in the mainline kernel until 3.7, 
via commit a2cfc509bc4eeef9f5c4607b1203f17f22ea2a36 ("ARM: OMAP3+: hwmod: 
Add AM33XX HWMOD data").  So I don't see how it could have worked with 
mainline.

> I just want the already merged driver to work with the vanilla
> kernel. Is that too much to ask?

It's a very reasonable wish and your patches are certainly appreciated.

But it seems that the CPSW has never worked in the mainline kernel.  So 
this particular patch is not fixing a regression.  Therefore we shouldn't 
send it upstream during the -rc time period.  Instead we'll schedule it to 
be sent a few weeks later, during the 3.8 merge window.

Either way, the patch is likely to make it into the mainline kernel.  
It's just that it will probably take a few weeks longer than you might 
like.


- Paul

Re: Fwd: [PATCH 2/5] ARM: OMAP3+: hwmod: Add AM33XX HWMOD data for davinci_mdio

[Richard Cochran]

On Thu, Oct 18, 2012 at 03:46:15AM +0000, Paul Walmsley wrote:
> 
> It doesn't necessarily mean that the driver is usable in that kernel 
> release.

Well, it should. We have staging for half-baked stuff.

> Either way, the patch is likely to make it into the mainline kernel.  
> It's just that it will probably take a few weeks longer than you might 
> like.

I don't mind waiting for a driver that is held off because of missing
background support.

I *do* mind if y'all go merging all kinds of code that has never been
tested. Those who submit and their reviewers should ensure that the
code is actually working. Before buying hardware or starting projects,
I often check what is in mainline. I expect that mainline has been at
least minimally tested.

Maybe that is just me, or maybe people working on the ARM tree have
different expectations.

Thanks,
Richard

Fwd: [PATCH 2/5] ARM: OMAP3+: hwmod: Add AM33XX HWMOD data for davinci_mdio

[Richard Cochran]

On Thu, Oct 18, 2012 at 03:46:15AM +0000, Paul Walmsley wrote:
> 
> It doesn't necessarily mean that the driver is usable in that kernel 
> release.

Well, it should. We have staging for half-baked stuff.

> Either way, the patch is likely to make it into the mainline kernel.  
> It's just that it will probably take a few weeks longer than you might 
> like.

I don't mind waiting for a driver that is held off because of missing
background support.

I *do* mind if y'all go merging all kinds of code that has never been
tested. Those who submit and their reviewers should ensure that the
code is actually working. Before buying hardware or starting projects,
I often check what is in mainline. I expect that mainline has been at
least minimally tested.

Maybe that is just me, or maybe people working on the ARM tree have
different expectations.

Thanks,
Richard

Re: Fwd: [PATCH 2/5] ARM: OMAP3+: hwmod: Add AM33XX HWMOD data for davinci_mdio

[Paul Walmsley]

On Thu, 18 Oct 2012, Richard Cochran wrote:

> I *do* mind if y'all go merging all kinds of code that has never been
> tested. Those who submit and their reviewers should ensure that the
> code is actually working. Before buying hardware or starting projects,
> I often check what is in mainline. I expect that mainline has been at
> least minimally tested.
> 
> Maybe that is just me, or maybe people working on the ARM tree have
> different expectations.

Any complaints or assumptions you might have in that regard should be 
directed towards the netdev folks, since they're the ones who merged this 
driver.

- Paul

Fwd: [PATCH 2/5] ARM: OMAP3+: hwmod: Add AM33XX HWMOD data for davinci_mdio

[Paul Walmsley]

On Thu, 18 Oct 2012, Richard Cochran wrote:

> I *do* mind if y'all go merging all kinds of code that has never been
> tested. Those who submit and their reviewers should ensure that the
> code is actually working. Before buying hardware or starting projects,
> I often check what is in mainline. I expect that mainline has been at
> least minimally tested.
> 
> Maybe that is just me, or maybe people working on the ARM tree have
> different expectations.

Any complaints or assumptions you might have in that regard should be 
directed towards the netdev folks, since they're the ones who merged this 
driver.

- Paul

Re: Fwd: [PATCH 2/5] ARM: OMAP3+: hwmod: Add AM33XX HWMOD data for davinci_mdio

[Richard Cochran]

On Thu, Oct 18, 2012 at 03:46:15AM +0000, Paul Walmsley wrote:
> 
> Probably the driver was submitted before any SoC integration support was 
> available.  Grepping for 'cpsw' under arch/ turns up only AM33xx.  AM335x 
> didn't have device enumeration support in the mainline kernel until 3.7, 
> via commit a2cfc509bc4eeef9f5c4607b1203f17f22ea2a36 ("ARM: OMAP3+: hwmod: 
> Add AM33XX HWMOD data").  So I don't see how it could have worked with 
> mainline.

...

> But it seems that the CPSW has never worked in the mainline kernel.  So 
> this particular patch is not fixing a regression.  Therefore we shouldn't 
> send it upstream during the -rc time period.  Instead we'll schedule it to 
> be sent a few weeks later, during the 3.8 merge window.

Let's think about this some more:

The driver's commit is from March and is included in v3.4-rc1.

You say it will be working in 3.8, after 3.7 comes out, in about
December.

So how long does it take between merging code and actually getting it
working?

Sorry to harp on this so much, but I try out my patches with the tip
of the appropriate tree before sending them, or when I cannot, at
least I put into the log "compile tested only" or something like that.

Thanks,
Richard

Fwd: [PATCH 2/5] ARM: OMAP3+: hwmod: Add AM33XX HWMOD data for davinci_mdio

[Richard Cochran]

On Thu, Oct 18, 2012 at 03:46:15AM +0000, Paul Walmsley wrote:
> 
> Probably the driver was submitted before any SoC integration support was 
> available.  Grepping for 'cpsw' under arch/ turns up only AM33xx.  AM335x 
> didn't have device enumeration support in the mainline kernel until 3.7, 
> via commit a2cfc509bc4eeef9f5c4607b1203f17f22ea2a36 ("ARM: OMAP3+: hwmod: 
> Add AM33XX HWMOD data").  So I don't see how it could have worked with 
> mainline.

...

> But it seems that the CPSW has never worked in the mainline kernel.  So 
> this particular patch is not fixing a regression.  Therefore we shouldn't 
> send it upstream during the -rc time period.  Instead we'll schedule it to 
> be sent a few weeks later, during the 3.8 merge window.

Let's think about this some more:

The driver's commit is from March and is included in v3.4-rc1.

You say it will be working in 3.8, after 3.7 comes out, in about
December.

So how long does it take between merging code and actually getting it
working?

Sorry to harp on this so much, but I try out my patches with the tip
of the appropriate tree before sending them, or when I cannot, at
least I put into the log "compile tested only" or something like that.

Thanks,
Richard

Re: Fwd: [PATCH 2/5] ARM: OMAP3+: hwmod: Add AM33XX HWMOD data for davinci_mdio

[Paul Walmsley]

On Thu, 18 Oct 2012, Richard Cochran wrote:

> You say it will be working in 3.8, after 3.7 comes out, in about
> December.

I wrote that we'll schedule the SoC integration patch for sending upstream 
for 3.8.  This does not necessarily mean that our upstreams will take it, 
or that it will result in a working CPSW.

> Sorry to harp on this so much, but I try out my patches with the tip of 
> the appropriate tree before sending them, or when I cannot, at least I 
> put into the log "compile tested only" or something like that.

Great!


- Paul

Fwd: [PATCH 2/5] ARM: OMAP3+: hwmod: Add AM33XX HWMOD data for davinci_mdio

[Paul Walmsley]

On Thu, 18 Oct 2012, Richard Cochran wrote:

> You say it will be working in 3.8, after 3.7 comes out, in about
> December.

I wrote that we'll schedule the SoC integration patch for sending upstream 
for 3.8.  This does not necessarily mean that our upstreams will take it, 
or that it will result in a working CPSW.

> Sorry to harp on this so much, but I try out my patches with the tip of 
> the appropriate tree before sending them, or when I cannot, at least I 
> put into the log "compile tested only" or something like that.

Great!


- Paul

Re: Fwd: [PATCH 2/5] ARM: OMAP3+: hwmod: Add AM33XX HWMOD data for davinci_mdio

[Richard Cochran]

On Thu, Oct 18, 2012 at 07:27:22PM +0000, Paul Walmsley wrote:
> I wrote that we'll schedule the SoC integration patch for sending upstream 
> for 3.8.  This does not necessarily mean that our upstreams will take it, 
> or that it will result in a working CPSW.

Forgive me for barking up the wrong tree at you, Paul. This is
directed toward the omap people:

Please, PLEASE, make sure that the mainline code is working.
It is easy to verify. Just compile the code and boot it.

Thanks,
Richard

Fwd: [PATCH 2/5] ARM: OMAP3+: hwmod: Add AM33XX HWMOD data for davinci_mdio

[Richard Cochran]

On Thu, Oct 18, 2012 at 07:27:22PM +0000, Paul Walmsley wrote:
> I wrote that we'll schedule the SoC integration patch for sending upstream 
> for 3.8.  This does not necessarily mean that our upstreams will take it, 
> or that it will result in a working CPSW.

Forgive me for barking up the wrong tree at you, Paul. This is
directed toward the omap people:

Please, PLEASE, make sure that the mainline code is working.
It is easy to verify. Just compile the code and boot it.

Thanks,
Richard

Re: Fwd: [PATCH 2/5] ARM: OMAP3+: hwmod: Add AM33XX HWMOD data for davinci_mdio

[Vaibhav Hiremath]

On 10/19/2012 12:14 AM, Richard Cochran wrote:
> On Thu, Oct 18, 2012 at 03:46:15AM +0000, Paul Walmsley wrote:
>>
>> Probably the driver was submitted before any SoC integration support was 
>> available.  Grepping for 'cpsw' under arch/ turns up only AM33xx.  AM335x 
>> didn't have device enumeration support in the mainline kernel until 3.7, 
>> via commit a2cfc509bc4eeef9f5c4607b1203f17f22ea2a36 ("ARM: OMAP3+: hwmod: 
>> Add AM33XX HWMOD data").  So I don't see how it could have worked with 
>> mainline.
> 
> ...
> 
>> But it seems that the CPSW has never worked in the mainline kernel.  So 
>> this particular patch is not fixing a regression.  Therefore we shouldn't 
>> send it upstream during the -rc time period.  Instead we'll schedule it to 
>> be sent a few weeks later, during the 3.8 merge window.
> 
> Let's think about this some more:
> 
> The driver's commit is from March and is included in v3.4-rc1.
> 
> You say it will be working in 3.8, after 3.7 comes out, in about
> December.
> 
> So how long does it take between merging code and actually getting it
> working?
> 
> Sorry to harp on this so much, but I try out my patches with the tip
> of the appropriate tree before sending them, or when I cannot, at
> least I put into the log "compile tested only" or something like that.
> 

Another important point is, this driver is also required and used for
Davinci family of devices (arch/mach/mach-davinci/).

Thanks,
Vaibhav

> Thanks,
> Richard
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 

Fwd: [PATCH 2/5] ARM: OMAP3+: hwmod: Add AM33XX HWMOD data for davinci_mdio

[Vaibhav Hiremath]

On 10/19/2012 12:14 AM, Richard Cochran wrote:
> On Thu, Oct 18, 2012 at 03:46:15AM +0000, Paul Walmsley wrote:
>>
>> Probably the driver was submitted before any SoC integration support was 
>> available.  Grepping for 'cpsw' under arch/ turns up only AM33xx.  AM335x 
>> didn't have device enumeration support in the mainline kernel until 3.7, 
>> via commit a2cfc509bc4eeef9f5c4607b1203f17f22ea2a36 ("ARM: OMAP3+: hwmod: 
>> Add AM33XX HWMOD data").  So I don't see how it could have worked with 
>> mainline.
> 
> ...
> 
>> But it seems that the CPSW has never worked in the mainline kernel.  So 
>> this particular patch is not fixing a regression.  Therefore we shouldn't 
>> send it upstream during the -rc time period.  Instead we'll schedule it to 
>> be sent a few weeks later, during the 3.8 merge window.
> 
> Let's think about this some more:
> 
> The driver's commit is from March and is included in v3.4-rc1.
> 
> You say it will be working in 3.8, after 3.7 comes out, in about
> December.
> 
> So how long does it take between merging code and actually getting it
> working?
> 
> Sorry to harp on this so much, but I try out my patches with the tip
> of the appropriate tree before sending them, or when I cannot, at
> least I put into the log "compile tested only" or something like that.
> 

Another important point is, this driver is also required and used for
Davinci family of devices (arch/mach/mach-davinci/).

Thanks,
Vaibhav

> Thanks,
> Richard
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 

Re: Fwd: [PATCH 2/5] ARM: OMAP3+: hwmod: Add AM33XX HWMOD data for davinci_mdio

[Richard Cochran]

On Fri, Oct 19, 2012 at 02:18:29AM +0530, Vaibhav Hiremath wrote:
> 
> Another important point is, this driver is also required and used for
> Davinci family of devices (arch/mach/mach-davinci/).

That is really beside the point. If the code isn't ready yet, then
don't merge it.

When I asked about the beaglebone, I was given the impression that it
will be ready for v3.7-rc1.  But, as I know realize, at the current
rate, it might not even be ready for v3.8.

I don't mind waiting, but please make sure that whatever lands into a
release is really, truly working.

Thanks,
Richard

Fwd: [PATCH 2/5] ARM: OMAP3+: hwmod: Add AM33XX HWMOD data for davinci_mdio

[Richard Cochran]

On Fri, Oct 19, 2012 at 02:18:29AM +0530, Vaibhav Hiremath wrote:
> 
> Another important point is, this driver is also required and used for
> Davinci family of devices (arch/mach/mach-davinci/).

That is really beside the point. If the code isn't ready yet, then
don't merge it.

When I asked about the beaglebone, I was given the impression that it
will be ready for v3.7-rc1.  But, as I know realize, at the current
rate, it might not even be ready for v3.8.

I don't mind waiting, but please make sure that whatever lands into a
release is really, truly working.

Thanks,
Richard

Re: Fwd: [PATCH 2/5] ARM: OMAP3+: hwmod: Add AM33XX HWMOD data for davinci_mdio

[Tony Lindgren]

* Richard Cochran <richardcochran@gmail.com> [121018 23:18]:
> On Fri, Oct 19, 2012 at 02:18:29AM +0530, Vaibhav Hiremath wrote:
> > 
> > Another important point is, this driver is also required and used for
> > Davinci family of devices (arch/mach/mach-davinci/).
> 
> That is really beside the point. If the code isn't ready yet, then
> don't merge it.
> 
> When I asked about the beaglebone, I was given the impression that it
> will be ready for v3.7-rc1.  But, as I know realize, at the current
> rate, it might not even be ready for v3.8.
> 
> I don't mind waiting, but please make sure that whatever lands into a
> release is really, truly working.

Indeed. This has been a problem with many of the TI patches in
general. People are working on separate product trees and then produce
patches for the mainline kernel that are poorly tested.

The requirement should be: Do your patch on an omap board then send the
patch from your omap board after booting your board with the patch :)

Regards,

Tony

Fwd: [PATCH 2/5] ARM: OMAP3+: hwmod: Add AM33XX HWMOD data for davinci_mdio

[Tony Lindgren]

* Richard Cochran <richardcochran@gmail.com> [121018 23:18]:
> On Fri, Oct 19, 2012 at 02:18:29AM +0530, Vaibhav Hiremath wrote:
> > 
> > Another important point is, this driver is also required and used for
> > Davinci family of devices (arch/mach/mach-davinci/).
> 
> That is really beside the point. If the code isn't ready yet, then
> don't merge it.
> 
> When I asked about the beaglebone, I was given the impression that it
> will be ready for v3.7-rc1.  But, as I know realize, at the current
> rate, it might not even be ready for v3.8.
> 
> I don't mind waiting, but please make sure that whatever lands into a
> release is really, truly working.

Indeed. This has been a problem with many of the TI patches in
general. People are working on separate product trees and then produce
patches for the mainline kernel that are poorly tested.

The requirement should be: Do your patch on an omap board then send the
patch from your omap board after booting your board with the patch :)

Regards,

Tony

Re: Fwd: [PATCH 2/5] ARM: OMAP3+: hwmod: Add AM33XX HWMOD data for davinci_mdio

[Matt Porter]

On Fri, Oct 19, 2012 at 09:00:41AM -0700, Tony Lindgren wrote:
> * Richard Cochran <richardcochran@gmail.com> [121018 23:18]:
> > On Fri, Oct 19, 2012 at 02:18:29AM +0530, Vaibhav Hiremath wrote:
> > > 
> > > Another important point is, this driver is also required and used for
> > > Davinci family of devices (arch/mach/mach-davinci/).
> > 
> > That is really beside the point. If the code isn't ready yet, then
> > don't merge it.
> > 
> > When I asked about the beaglebone, I was given the impression that it
> > will be ready for v3.7-rc1.  But, as I know realize, at the current
> > rate, it might not even be ready for v3.8.
> > 
> > I don't mind waiting, but please make sure that whatever lands into a
> > release is really, truly working.
> 
> Indeed. This has been a problem with many of the TI patches in
> general. People are working on separate product trees and then produce
> patches for the mainline kernel that are poorly tested.
> 
> The requirement should be: Do your patch on an omap board then send the
> patch from your omap board after booting your board with the patch :)

s/should be/is/

I fixed that for you. :) That's always been the requirement for the
kernel, period. There's also a lot of dead/unused code in the davinci
driver world too...so omap isn't alone with this phenomenon.

-Matt

Fwd: [PATCH 2/5] ARM: OMAP3+: hwmod: Add AM33XX HWMOD data for davinci_mdio

[Matt Porter]

On Fri, Oct 19, 2012 at 09:00:41AM -0700, Tony Lindgren wrote:
> * Richard Cochran <richardcochran@gmail.com> [121018 23:18]:
> > On Fri, Oct 19, 2012 at 02:18:29AM +0530, Vaibhav Hiremath wrote:
> > > 
> > > Another important point is, this driver is also required and used for
> > > Davinci family of devices (arch/mach/mach-davinci/).
> > 
> > That is really beside the point. If the code isn't ready yet, then
> > don't merge it.
> > 
> > When I asked about the beaglebone, I was given the impression that it
> > will be ready for v3.7-rc1.  But, as I know realize, at the current
> > rate, it might not even be ready for v3.8.
> > 
> > I don't mind waiting, but please make sure that whatever lands into a
> > release is really, truly working.
> 
> Indeed. This has been a problem with many of the TI patches in
> general. People are working on separate product trees and then produce
> patches for the mainline kernel that are poorly tested.
> 
> The requirement should be: Do your patch on an omap board then send the
> patch from your omap board after booting your board with the patch :)

s/should be/is/

I fixed that for you. :) That's always been the requirement for the
kernel, period. There's also a lot of dead/unused code in the davinci
driver world too...so omap isn't alone with this phenomenon.

-Matt

RE: Fwd: [PATCH 2/5] ARM: OMAP3+: hwmod: Add AM33XX HWMOD data for davinci_mdio

[Hiremath, Vaibhav]

On Fri, Oct 19, 2012 at 21:30:41, Tony Lindgren wrote:
> * Richard Cochran <richardcochran@gmail.com> [121018 23:18]:
> > On Fri, Oct 19, 2012 at 02:18:29AM +0530, Vaibhav Hiremath wrote:
> > > 
> > > Another important point is, this driver is also required and used for
> > > Davinci family of devices (arch/mach/mach-davinci/).
> > 
> > That is really beside the point. If the code isn't ready yet, then
> > don't merge it.
> > 
> > When I asked about the beaglebone, I was given the impression that it
> > will be ready for v3.7-rc1.  But, as I know realize, at the current
> > rate, it might not even be ready for v3.8.
> > 
> > I don't mind waiting, but please make sure that whatever lands into a
> > release is really, truly working.
> 
> Indeed. This has been a problem with many of the TI patches in
> general. People are working on separate product trees and then produce
> patches for the mainline kernel that are poorly tested.
> 

Tony,

It may not be true always, as we always work simultaneously and there are 
high chances that some patches/development is dependent on others from 
functionality perspective (especially baseport), but still they are 
independent modules (may be for other devices).

Lets take a example of AM33xx and OMAP5 here, we started submitting baseport 
patches to the list (almost 6-8 months now), not all the patches gets 
accepted together in one shot.
As you know, when we started pushing AM33xx and OMAP5 baseport patches, we 
were at the stage where both DT and hwmod was required. First attempt for 
board file submission did not went through, since we decided to force all 
new devices migrate to DT, right?

So the criteria initially was, build should not break and submit patches 
step-by-step.

Now, with baseport patches submitted to list, individual developer can also 
start submitting patches to the respective driver's list, making sure that, 
driver doesn't change irrespective of platform. I do not see anything wrong
with this, as we always consider driver independent.

In this particular case, note that, all the patches Richard posted recently 
are AM33xx SoC integration specific patches only.

Thanks,
Vaibhav 

Fwd: [PATCH 2/5] ARM: OMAP3+: hwmod: Add AM33XX HWMOD data for davinci_mdio

[Hiremath, Vaibhav]

On Fri, Oct 19, 2012 at 21:30:41, Tony Lindgren wrote:
> * Richard Cochran <richardcochran@gmail.com> [121018 23:18]:
> > On Fri, Oct 19, 2012 at 02:18:29AM +0530, Vaibhav Hiremath wrote:
> > > 
> > > Another important point is, this driver is also required and used for
> > > Davinci family of devices (arch/mach/mach-davinci/).
> > 
> > That is really beside the point. If the code isn't ready yet, then
> > don't merge it.
> > 
> > When I asked about the beaglebone, I was given the impression that it
> > will be ready for v3.7-rc1.  But, as I know realize, at the current
> > rate, it might not even be ready for v3.8.
> > 
> > I don't mind waiting, but please make sure that whatever lands into a
> > release is really, truly working.
> 
> Indeed. This has been a problem with many of the TI patches in
> general. People are working on separate product trees and then produce
> patches for the mainline kernel that are poorly tested.
> 

Tony,

It may not be true always, as we always work simultaneously and there are 
high chances that some patches/development is dependent on others from 
functionality perspective (especially baseport), but still they are 
independent modules (may be for other devices).

Lets take a example of AM33xx and OMAP5 here, we started submitting baseport 
patches to the list (almost 6-8 months now), not all the patches gets 
accepted together in one shot.
As you know, when we started pushing AM33xx and OMAP5 baseport patches, we 
were at the stage where both DT and hwmod was required. First attempt for 
board file submission did not went through, since we decided to force all 
new devices migrate to DT, right?

So the criteria initially was, build should not break and submit patches 
step-by-step.

Now, with baseport patches submitted to list, individual developer can also 
start submitting patches to the respective driver's list, making sure that, 
driver doesn't change irrespective of platform. I do not see anything wrong
with this, as we always consider driver independent.

In this particular case, note that, all the patches Richard posted recently 
are AM33xx SoC integration specific patches only.

Thanks,
Vaibhav 

Re: Fwd: [PATCH 2/5] ARM: OMAP3+: hwmod: Add AM33XX HWMOD data for davinci_mdio

[Tony Lindgren]

* Hiremath, Vaibhav <hvaibhav@ti.com> [121026 01:24]:
> On Fri, Oct 19, 2012 at 21:30:41, Tony Lindgren wrote:
> > * Richard Cochran <richardcochran@gmail.com> [121018 23:18]:
> > > On Fri, Oct 19, 2012 at 02:18:29AM +0530, Vaibhav Hiremath wrote:
> > > > 
> > > > Another important point is, this driver is also required and used for
> > > > Davinci family of devices (arch/mach/mach-davinci/).
> > > 
> > > That is really beside the point. If the code isn't ready yet, then
> > > don't merge it.
> > > 
> > > When I asked about the beaglebone, I was given the impression that it
> > > will be ready for v3.7-rc1.  But, as I know realize, at the current
> > > rate, it might not even be ready for v3.8.
> > > 
> > > I don't mind waiting, but please make sure that whatever lands into a
> > > release is really, truly working.
> > 
> > Indeed. This has been a problem with many of the TI patches in
> > general. People are working on separate product trees and then produce
> > patches for the mainline kernel that are poorly tested.
> > 
> 
> Tony,
> 
> It may not be true always, as we always work simultaneously and there are 
> high chances that some patches/development is dependent on others from 
> functionality perspective (especially baseport), but still they are 
> independent modules (may be for other devices).
> 
> Lets take a example of AM33xx and OMAP5 here, we started submitting baseport 
> patches to the list (almost 6-8 months now), not all the patches gets 
> accepted together in one shot.
> As you know, when we started pushing AM33xx and OMAP5 baseport patches, we 
> were at the stage where both DT and hwmod was required. First attempt for 
> board file submission did not went through, since we decided to force all 
> new devices migrate to DT, right?

I think you guys have done a pretty good job with the am33xx patches
in general to get the core omap changes merged.
 
> So the criteria initially was, build should not break and submit patches 
> step-by-step.
> 
> Now, with baseport patches submitted to list, individual developer can also 
> start submitting patches to the respective driver's list, making sure that, 
> driver doesn't change irrespective of platform. I do not see anything wrong
> with this, as we always consider driver independent.
> 
> In this particular case, note that, all the patches Richard posted recently 
> are AM33xx SoC integration specific patches only.

Yes now the core omap patches are merged, and people want to use
the devices with mainline kernel. That's usually good news :)

Regards,

Tony

Fwd: [PATCH 2/5] ARM: OMAP3+: hwmod: Add AM33XX HWMOD data for davinci_mdio

[Tony Lindgren]

* Hiremath, Vaibhav <hvaibhav@ti.com> [121026 01:24]:
> On Fri, Oct 19, 2012 at 21:30:41, Tony Lindgren wrote:
> > * Richard Cochran <richardcochran@gmail.com> [121018 23:18]:
> > > On Fri, Oct 19, 2012 at 02:18:29AM +0530, Vaibhav Hiremath wrote:
> > > > 
> > > > Another important point is, this driver is also required and used for
> > > > Davinci family of devices (arch/mach/mach-davinci/).
> > > 
> > > That is really beside the point. If the code isn't ready yet, then
> > > don't merge it.
> > > 
> > > When I asked about the beaglebone, I was given the impression that it
> > > will be ready for v3.7-rc1.  But, as I know realize, at the current
> > > rate, it might not even be ready for v3.8.
> > > 
> > > I don't mind waiting, but please make sure that whatever lands into a
> > > release is really, truly working.
> > 
> > Indeed. This has been a problem with many of the TI patches in
> > general. People are working on separate product trees and then produce
> > patches for the mainline kernel that are poorly tested.
> > 
> 
> Tony,
> 
> It may not be true always, as we always work simultaneously and there are 
> high chances that some patches/development is dependent on others from 
> functionality perspective (especially baseport), but still they are 
> independent modules (may be for other devices).
> 
> Lets take a example of AM33xx and OMAP5 here, we started submitting baseport 
> patches to the list (almost 6-8 months now), not all the patches gets 
> accepted together in one shot.
> As you know, when we started pushing AM33xx and OMAP5 baseport patches, we 
> were at the stage where both DT and hwmod was required. First attempt for 
> board file submission did not went through, since we decided to force all 
> new devices migrate to DT, right?

I think you guys have done a pretty good job with the am33xx patches
in general to get the core omap changes merged.
 
> So the criteria initially was, build should not break and submit patches 
> step-by-step.
> 
> Now, with baseport patches submitted to list, individual developer can also 
> start submitting patches to the respective driver's list, making sure that, 
> driver doesn't change irrespective of platform. I do not see anything wrong
> with this, as we always consider driver independent.
> 
> In this particular case, note that, all the patches Richard posted recently 
> are AM33xx SoC integration specific patches only.

Yes now the core omap patches are merged, and people want to use
the devices with mainline kernel. That's usually good news :)

Regards,

Tony

RE: Fwd: [PATCH 2/5] ARM: OMAP3+: hwmod: Add AM33XX HWMOD data for davinci_mdio

[Hiremath, Vaibhav]

On Fri, Oct 26, 2012 at 23:36:28, Tony Lindgren wrote:
> * Hiremath, Vaibhav <hvaibhav@ti.com> [121026 01:24]:
> > On Fri, Oct 19, 2012 at 21:30:41, Tony Lindgren wrote:
> > > * Richard Cochran <richardcochran@gmail.com> [121018 23:18]:
> > > > On Fri, Oct 19, 2012 at 02:18:29AM +0530, Vaibhav Hiremath wrote:
> > > > > 
> > > > > Another important point is, this driver is also required and used for
> > > > > Davinci family of devices (arch/mach/mach-davinci/).
> > > > 
> > > > That is really beside the point. If the code isn't ready yet, then
> > > > don't merge it.
> > > > 
> > > > When I asked about the beaglebone, I was given the impression that it
> > > > will be ready for v3.7-rc1.  But, as I know realize, at the current
> > > > rate, it might not even be ready for v3.8.
> > > > 
> > > > I don't mind waiting, but please make sure that whatever lands into a
> > > > release is really, truly working.
> > > 
> > > Indeed. This has been a problem with many of the TI patches in
> > > general. People are working on separate product trees and then produce
> > > patches for the mainline kernel that are poorly tested.
> > > 
> > 
> > Tony,
> > 
> > It may not be true always, as we always work simultaneously and there are 
> > high chances that some patches/development is dependent on others from 
> > functionality perspective (especially baseport), but still they are 
> > independent modules (may be for other devices).
> > 
> > Lets take a example of AM33xx and OMAP5 here, we started submitting baseport 
> > patches to the list (almost 6-8 months now), not all the patches gets 
> > accepted together in one shot.
> > As you know, when we started pushing AM33xx and OMAP5 baseport patches, we 
> > were at the stage where both DT and hwmod was required. First attempt for 
> > board file submission did not went through, since we decided to force all 
> > new devices migrate to DT, right?
> 
> I think you guys have done a pretty good job with the am33xx patches
> in general to get the core omap changes merged.
>  
> > So the criteria initially was, build should not break and submit patches 
> > step-by-step.
> > 
> > Now, with baseport patches submitted to list, individual developer can also 
> > start submitting patches to the respective driver's list, making sure that, 
> > driver doesn't change irrespective of platform. I do not see anything wrong
> > with this, as we always consider driver independent.
> > 
> > In this particular case, note that, all the patches Richard posted recently 
> > are AM33xx SoC integration specific patches only.
> 
> Yes now the core omap patches are merged, and people want to use
> the devices with mainline kernel. That's usually good news :)
> 

Yes, absolutely. 

Now the expectation has grown to the level where people expect everything in 
the Mainline kernel and not in some custom kernel release.

I believe and expect, v3.8 merge window would be really meaningful in this 
regard for AM33xx platform.

Thanks,
Vaibhav

Fwd: [PATCH 2/5] ARM: OMAP3+: hwmod: Add AM33XX HWMOD data for davinci_mdio

[Hiremath, Vaibhav]

On Fri, Oct 26, 2012 at 23:36:28, Tony Lindgren wrote:
> * Hiremath, Vaibhav <hvaibhav@ti.com> [121026 01:24]:
> > On Fri, Oct 19, 2012 at 21:30:41, Tony Lindgren wrote:
> > > * Richard Cochran <richardcochran@gmail.com> [121018 23:18]:
> > > > On Fri, Oct 19, 2012 at 02:18:29AM +0530, Vaibhav Hiremath wrote:
> > > > > 
> > > > > Another important point is, this driver is also required and used for
> > > > > Davinci family of devices (arch/mach/mach-davinci/).
> > > > 
> > > > That is really beside the point. If the code isn't ready yet, then
> > > > don't merge it.
> > > > 
> > > > When I asked about the beaglebone, I was given the impression that it
> > > > will be ready for v3.7-rc1.  But, as I know realize, at the current
> > > > rate, it might not even be ready for v3.8.
> > > > 
> > > > I don't mind waiting, but please make sure that whatever lands into a
> > > > release is really, truly working.
> > > 
> > > Indeed. This has been a problem with many of the TI patches in
> > > general. People are working on separate product trees and then produce
> > > patches for the mainline kernel that are poorly tested.
> > > 
> > 
> > Tony,
> > 
> > It may not be true always, as we always work simultaneously and there are 
> > high chances that some patches/development is dependent on others from 
> > functionality perspective (especially baseport), but still they are 
> > independent modules (may be for other devices).
> > 
> > Lets take a example of AM33xx and OMAP5 here, we started submitting baseport 
> > patches to the list (almost 6-8 months now), not all the patches gets 
> > accepted together in one shot.
> > As you know, when we started pushing AM33xx and OMAP5 baseport patches, we 
> > were at the stage where both DT and hwmod was required. First attempt for 
> > board file submission did not went through, since we decided to force all 
> > new devices migrate to DT, right?
> 
> I think you guys have done a pretty good job with the am33xx patches
> in general to get the core omap changes merged.
>  
> > So the criteria initially was, build should not break and submit patches 
> > step-by-step.
> > 
> > Now, with baseport patches submitted to list, individual developer can also 
> > start submitting patches to the respective driver's list, making sure that, 
> > driver doesn't change irrespective of platform. I do not see anything wrong
> > with this, as we always consider driver independent.
> > 
> > In this particular case, note that, all the patches Richard posted recently 
> > are AM33xx SoC integration specific patches only.
> 
> Yes now the core omap patches are merged, and people want to use
> the devices with mainline kernel. That's usually good news :)
> 

Yes, absolutely. 

Now the expectation has grown to the level where people expect everything in 
the Mainline kernel and not in some custom kernel release.

I believe and expect, v3.8 merge window would be really meaningful in this 
regard for AM33xx platform.

Thanks,
Vaibhav

Re: Fwd: [PATCH 2/5] ARM: OMAP3+: hwmod: Add AM33XX HWMOD data for davinci_mdio

[Richard Cochran]

On Mon, Oct 29, 2012 at 04:58:23AM +0000, Hiremath, Vaibhav wrote:
> 
> Now the expectation has grown to the level where people expect everything in 
> the Mainline kernel and not in some custom kernel release.

You are right, except for the "has grown" part. I have always expected
the official kernel releases to be working and complete, without the
kind of half baked stumps that the embedded vendors are pushing.

In my experience with Freescale (and now TI also), the vendor supports
Linux on their platform by providing a heavily patched, quick and
dirty, customized kernel that is kinda, sorta working, somehow. This
provides a way for their customers to get started with the development
kits right away, and as such I have no problem with it.

What I do have a problem with is the fact the vendors then drop the
ball and don't follow through by getting their changes into
mainline. This makes a huge problem for the vendor's customers later
on, when the choice becomes either stay with the dead end vendor
kernel, or try to get mainline working all by themselves.

And so I am pleased to hear that the Ethernet ports on the am335x will
be working in v3.8. Better late than never.

Thanks,
Richard

Fwd: [PATCH 2/5] ARM: OMAP3+: hwmod: Add AM33XX HWMOD data for davinci_mdio

[Richard Cochran]

On Mon, Oct 29, 2012 at 04:58:23AM +0000, Hiremath, Vaibhav wrote:
> 
> Now the expectation has grown to the level where people expect everything in 
> the Mainline kernel and not in some custom kernel release.

You are right, except for the "has grown" part. I have always expected
the official kernel releases to be working and complete, without the
kind of half baked stumps that the embedded vendors are pushing.

In my experience with Freescale (and now TI also), the vendor supports
Linux on their platform by providing a heavily patched, quick and
dirty, customized kernel that is kinda, sorta working, somehow. This
provides a way for their customers to get started with the development
kits right away, and as such I have no problem with it.

What I do have a problem with is the fact the vendors then drop the
ball and don't follow through by getting their changes into
mainline. This makes a huge problem for the vendor's customers later
on, when the choice becomes either stay with the dead end vendor
kernel, or try to get mainline working all by themselves.

And so I am pleased to hear that the Ethernet ports on the am335x will
be working in v3.8. Better late than never.

Thanks,
Richard

RE: Fwd: [PATCH 2/5] ARM: OMAP3+: hwmod: Add AM33XX HWMOD data for davinci_mdio

[Hiremath, Vaibhav]

On Mon, Oct 29, 2012 at 13:20:03, Richard Cochran wrote:
> On Mon, Oct 29, 2012 at 04:58:23AM +0000, Hiremath, Vaibhav wrote:
> > 
> > Now the expectation has grown to the level where people expect everything in 
> > the Mainline kernel and not in some custom kernel release.
> 
> You are right, except for the "has grown" part. I have always expected
> the official kernel releases to be working and complete, without the
> kind of half baked stumps that the embedded vendors are pushing.
> 
> In my experience with Freescale (and now TI also), the vendor supports
> Linux on their platform by providing a heavily patched, quick and
> dirty, customized kernel that is kinda, sorta working, somehow. This
> provides a way for their customers to get started with the development
> kits right away, and as such I have no problem with it.
> 
> What I do have a problem with is the fact the vendors then drop the
> ball and don't follow through by getting their changes into
> mainline. This makes a huge problem for the vendor's customers later
> on, when the choice becomes either stay with the dead end vendor
> kernel, or try to get mainline working all by themselves.
> 

I completely understand and I can only say that, we have learned our lessons 
long time back on this and we now try to push all our code to Mainline.

Even with TI release kernel we try to stay closer to mainline, so that later
it would be easier to submit the patches to mainline.
For example, in some cases we have back-ported some of the framework changes 
to v3.2 kernel to stay closer to mainline.

 
> And so I am pleased to hear that the Ethernet ports on the am335x will
> be working in v3.8. Better late than never.
> 

Just submitted patches to the list, care to ack them.

Thanks,
Vaibhav 

Fwd: [PATCH 2/5] ARM: OMAP3+: hwmod: Add AM33XX HWMOD data for davinci_mdio

[Hiremath, Vaibhav]

On Mon, Oct 29, 2012 at 13:20:03, Richard Cochran wrote:
> On Mon, Oct 29, 2012 at 04:58:23AM +0000, Hiremath, Vaibhav wrote:
> > 
> > Now the expectation has grown to the level where people expect everything in 
> > the Mainline kernel and not in some custom kernel release.
> 
> You are right, except for the "has grown" part. I have always expected
> the official kernel releases to be working and complete, without the
> kind of half baked stumps that the embedded vendors are pushing.
> 
> In my experience with Freescale (and now TI also), the vendor supports
> Linux on their platform by providing a heavily patched, quick and
> dirty, customized kernel that is kinda, sorta working, somehow. This
> provides a way for their customers to get started with the development
> kits right away, and as such I have no problem with it.
> 
> What I do have a problem with is the fact the vendors then drop the
> ball and don't follow through by getting their changes into
> mainline. This makes a huge problem for the vendor's customers later
> on, when the choice becomes either stay with the dead end vendor
> kernel, or try to get mainline working all by themselves.
> 

I completely understand and I can only say that, we have learned our lessons 
long time back on this and we now try to push all our code to Mainline.

Even with TI release kernel we try to stay closer to mainline, so that later
it would be easier to submit the patches to mainline.
For example, in some cases we have back-ported some of the framework changes 
to v3.2 kernel to stay closer to mainline.

 
> And so I am pleased to hear that the Ethernet ports on the am335x will
> be working in v3.8. Better late than never.
> 

Just submitted patches to the list, care to ack them.

Thanks,
Vaibhav 

RE: Fwd: [PATCH 2/5] ARM: OMAP3+: hwmod: Add AM33XX HWMOD data for davinci_mdio

[Hiremath, Vaibhav]

On Fri, Oct 19, 2012 at 11:46:30, Richard Cochran wrote:
> On Fri, Oct 19, 2012 at 02:18:29AM +0530, Vaibhav Hiremath wrote:
> > 
> > Another important point is, this driver is also required and used for
> > Davinci family of devices (arch/mach/mach-davinci/).
> 
> That is really beside the point. If the code isn't ready yet, then
> don't merge it.
> 

With respect to AM33xx the driver may not be ready, but that doesn't mean 
driver itself is not ready. As I mentioned before, driver is used on davinci 
platform and it could be functional there. 

In case of AM33xx, where DT only boot mode is supported, you are forced to 
migrate driver to DT, which is addition to the driver.

Note that, all the patches you have posted recently are AM33xx SoC 
integration specific patches.

> When I asked about the beaglebone, I was given the impression that it
> will be ready for v3.7-rc1.  But, as I know realize, at the current
> rate, it might not even be ready for v3.8.
> 

I understand, and as you mentioned we are not fully there at v3.7-rc1 with 
all the drivers/module support, due to all known reasons. Its good that with 
v3.7-rc2, Beaglebone boots up out of box from mainline. 


Thanks,
Vaibhav
> I don't mind waiting, but please make sure that whatever lands into a
> release is really, truly working.
> 
> Thanks,
> Richard
> 
> 
> 

Fwd: [PATCH 2/5] ARM: OMAP3+: hwmod: Add AM33XX HWMOD data for davinci_mdio

[Hiremath, Vaibhav]

On Fri, Oct 19, 2012 at 11:46:30, Richard Cochran wrote:
> On Fri, Oct 19, 2012 at 02:18:29AM +0530, Vaibhav Hiremath wrote:
> > 
> > Another important point is, this driver is also required and used for
> > Davinci family of devices (arch/mach/mach-davinci/).
> 
> That is really beside the point. If the code isn't ready yet, then
> don't merge it.
> 

With respect to AM33xx the driver may not be ready, but that doesn't mean 
driver itself is not ready. As I mentioned before, driver is used on davinci 
platform and it could be functional there. 

In case of AM33xx, where DT only boot mode is supported, you are forced to 
migrate driver to DT, which is addition to the driver.

Note that, all the patches you have posted recently are AM33xx SoC 
integration specific patches.

> When I asked about the beaglebone, I was given the impression that it
> will be ready for v3.7-rc1.  But, as I know realize, at the current
> rate, it might not even be ready for v3.8.
> 

I understand, and as you mentioned we are not fully there at v3.7-rc1 with 
all the drivers/module support, due to all known reasons. Its good that with 
v3.7-rc2, Beaglebone boots up out of box from mainline. 


Thanks,
Vaibhav
> I don't mind waiting, but please make sure that whatever lands into a
> release is really, truly working.
> 
> Thanks,
> Richard
> 
> 
> 

Re: Fwd: [PATCH 2/5] ARM: OMAP3+: hwmod: Add AM33XX HWMOD data for davinci_mdio

[Richard Cochran]

On Tue, Oct 23, 2012 at 10:12:29AM +0000, Hiremath, Vaibhav wrote:
> 
> I understand, and as you mentioned we are not fully there at v3.7-rc1 with 
> all the drivers/module support, due to all known reasons. Its good that with 
> v3.7-rc2, Beaglebone boots up out of box from mainline. 

Can you say whether we have working Ethernet on the beaglebone in v3.7?

Thanks,
Richard

Fwd: [PATCH 2/5] ARM: OMAP3+: hwmod: Add AM33XX HWMOD data for davinci_mdio

[Richard Cochran]

On Tue, Oct 23, 2012 at 10:12:29AM +0000, Hiremath, Vaibhav wrote:
> 
> I understand, and as you mentioned we are not fully there at v3.7-rc1 with 
> all the drivers/module support, due to all known reasons. Its good that with 
> v3.7-rc2, Beaglebone boots up out of box from mainline. 

Can you say whether we have working Ethernet on the beaglebone in v3.7?

Thanks,
Richard

RE: Fwd: [PATCH 2/5] ARM: OMAP3+: hwmod: Add AM33XX HWMOD data for davinci_mdio

[Hiremath, Vaibhav]

On Wed, Oct 24, 2012 at 10:38:53, Richard Cochran wrote:
> On Tue, Oct 23, 2012 at 10:12:29AM +0000, Hiremath, Vaibhav wrote:
> > 
> > I understand, and as you mentioned we are not fully there at v3.7-rc1 with 
> > all the drivers/module support, due to all known reasons. Its good that with 
> > v3.7-rc2, Beaglebone boots up out of box from mainline. 
> 
> Can you say whether we have working Ethernet on the beaglebone in v3.7?
> 

No, certainly not. The DT patches are still pending to get merged and v3.7 
merge window is closed now. I expect it to get merged to v3.8.

Thanks,
Vaibhav

> Thanks,
> Richard
> 

Fwd: [PATCH 2/5] ARM: OMAP3+: hwmod: Add AM33XX HWMOD data for davinci_mdio

[Hiremath, Vaibhav]

On Wed, Oct 24, 2012 at 10:38:53, Richard Cochran wrote:
> On Tue, Oct 23, 2012 at 10:12:29AM +0000, Hiremath, Vaibhav wrote:
> > 
> > I understand, and as you mentioned we are not fully there at v3.7-rc1 with 
> > all the drivers/module support, due to all known reasons. Its good that with 
> > v3.7-rc2, Beaglebone boots up out of box from mainline. 
> 
> Can you say whether we have working Ethernet on the beaglebone in v3.7?
> 

No, certainly not. The DT patches are still pending to get merged and v3.7 
merge window is closed now. I expect it to get merged to v3.8.

Thanks,
Vaibhav

> Thanks,
> Richard
> 

Re: [PATCH 2/5] ARM: OMAP3+: hwmod: Add AM33XX HWMOD data for davinci_mdio

[Koen Kooi]

Op 18 okt. 2012, om 05:06 heeft Richard Cochran <richardcochran@gmail.com> het volgende geschreven:

> On Wed, Oct 17, 2012 at 04:50:46PM -0700, Tony Lindgren wrote:
>> * Paul Walmsley <paul@pwsan.com> [121017 16:39]:
>>> Hi Richard
>>> 
>>> On Wed, 17 Oct 2012, Richard Cochran wrote:
>>> 
>>>> Would you please take this bugfix for 3.7-rc2? The suggestion to mail
>>>> you came from Toni Lindgren. The context where it came from is here:
>>>> 
>>>> http://lists.arm.linux.org.uk/lurker/message/20121015.191630.bdae3c50.en.html
>>> 
>>> This patch appears to add a new feature, correct?  I don't think the CPSW 
>>> could have worked in the past without this data present.  So it looks to 
>>> me like this is 3.8 material, unless Tony would like it to go in sooner?
>> 
>> Yeah unless it fixes something, we should just queue it for v3.8 merge
>> window.
> 
> So there has been this cpsw driver since v3.4-rc1~177^2~5
> 
>   df82859 netdev: driver: ethernet: Add TI CPSW driver
> 
> and four people signed off on it, so it must have been working at one
> point. Since the device tree make-over, the driver is a derelict, and
> thus the present patch is fixing a regression.

Have a look at the tscadc driver for am335x that has had a few rounds of review. That one lacks DT bindings, so it can't be tested on this DT only platform. That a driver has been accepted in mainline does not mean it works, for am335x it just means that it compiles.

The patches I needed to get cpsw to work on beaglebone: https://github.com/beagleboard/kernel/tree/3.7/patches/cpsw

regards,

Koen

[PATCH 2/5] ARM: OMAP3+: hwmod: Add AM33XX HWMOD data for davinci_mdio

[Koen Kooi]

Op 18 okt. 2012, om 05:06 heeft Richard Cochran <richardcochran@gmail.com> het volgende geschreven:

> On Wed, Oct 17, 2012 at 04:50:46PM -0700, Tony Lindgren wrote:
>> * Paul Walmsley <paul@pwsan.com> [121017 16:39]:
>>> Hi Richard
>>> 
>>> On Wed, 17 Oct 2012, Richard Cochran wrote:
>>> 
>>>> Would you please take this bugfix for 3.7-rc2? The suggestion to mail
>>>> you came from Toni Lindgren. The context where it came from is here:
>>>> 
>>>> http://lists.arm.linux.org.uk/lurker/message/20121015.191630.bdae3c50.en.html
>>> 
>>> This patch appears to add a new feature, correct?  I don't think the CPSW 
>>> could have worked in the past without this data present.  So it looks to 
>>> me like this is 3.8 material, unless Tony would like it to go in sooner?
>> 
>> Yeah unless it fixes something, we should just queue it for v3.8 merge
>> window.
> 
> So there has been this cpsw driver since v3.4-rc1~177^2~5
> 
>   df82859 netdev: driver: ethernet: Add TI CPSW driver
> 
> and four people signed off on it, so it must have been working at one
> point. Since the device tree make-over, the driver is a derelict, and
> thus the present patch is fixing a regression.

Have a look at the tscadc driver for am335x that has had a few rounds of review. That one lacks DT bindings, so it can't be tested on this DT only platform. That a driver has been accepted in mainline does not mean it works, for am335x it just means that it compiles.

The patches I needed to get cpsw to work on beaglebone: https://github.com/beagleboard/kernel/tree/3.7/patches/cpsw

regards,

Koen

Re: Fwd: [PATCH 2/5] ARM: OMAP3+: hwmod: Add AM33XX HWMOD data for davinci_mdio

[Vaibhav Hiremath]

On 10/17/2012 11:43 PM, Richard Cochran wrote:
> Paul,
> 
> Would you please take this bugfix for 3.7-rc2? The suggestion to mail
> you came from Toni Lindgren. The context where it came from is here:
> 
> http://lists.arm.linux.org.uk/lurker/message/20121015.191630.bdae3c50.en.html
> 
> Thanks,
> Richard
> 
> ----- Forwarded message from Richard Cochran <richardcochran@gmail.com> -----
> 
> Date: Mon, 15 Oct 2012 21:16:32 +0200
> From: Richard Cochran <richardcochran@gmail.com>
> To: netdev@vger.kernel.org
> Cc: linux-arm-kernel@lists.infradead.org, Arnd Bergmann <arnd@arndb.de>,
> 	David Miller <davem@davemloft.net>,
> 	Russell King <linux@arm.linux.org.uk>,
> 	Mugunthan V N <mugunthanvnm@ti.com>
> Subject: [PATCH 2/5] ARM: OMAP3+: hwmod: Add AM33XX HWMOD data for davinci_mdio
> X-Mailer: git-send-email 1.7.2.5
> 
> From: Mugunthan V N <mugunthanvnm@ti.com>
> 
> This patch adds minimal hwmod support for davinci mdio driver. This patch
> requires rework on parent child relation between cpsw and davinci mdio
> hwmod data to support runtime PM.
> 
> Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
> ---
>  arch/arm/mach-omap2/omap_hwmod_33xx_data.c |   34 ++++++++++++++++++++++++++-
>  1 files changed, 32 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
> index 59d5c1c..f96bbc0 100644
> --- a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
> +++ b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
> @@ -650,8 +650,7 @@ static struct omap_hwmod_class_sysconfig am33xx_cpgmac_sysc = {
>  	.rev_offs	= 0x0,
>  	.sysc_offs	= 0x8,
>  	.syss_offs	= 0x4,
> -	.sysc_flags	= (SYSC_HAS_SIDLEMODE | SYSC_HAS_MIDLEMODE |
> -			   SYSS_HAS_RESET_STATUS),
> +	.sysc_flags	= (SYSC_HAS_SIDLEMODE | SYSC_HAS_MIDLEMODE),
>  	.idlemodes	= (SIDLE_FORCE | SIDLE_NO | MSTANDBY_FORCE |
>  			   MSTANDBY_NO),
>  	.sysc_fields	= &omap_hwmod_sysc_type3,
> @@ -682,6 +681,8 @@ static struct omap_hwmod am33xx_cpgmac0_hwmod = {
>  			.modulemode	= MODULEMODE_SWCTRL,
>  		},
>  	},
> +	.flags		= (HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY |
> +			   HWMOD_INIT_NO_RESET | HWMOD_INIT_NO_IDLE),

Hey Richard,

I feel you have picked up this patch in premature state, I didn't like
this NO_RESET and NO_IDLE flag to be set for MDIO.

Couple of reasons,

1. These flags were added for validation, so I expect cpsw driver
should work without these flags set. I tested it mounting NFS as rootFS
and it works for me.

2. There is HW bug as far as idle (in turn ocp reset) is concerned, and
needs special handling for this. I already have patch for this, which I
will submit it to the list.

http://arago-project.org/git/projects/?p=linux-am33x.git;a=commitdiff;h=a28da2ac98f173f97dbbb46be1ce0a3879f21a11


Note: Sorry for long commit description, it was screwed up by someone
while git push.


I have pushed the tested branch to (linux-omap/master + CPSW patches) -
https://github.com/hvaibhav/am335x-linux/tree/am335x-upstream-staging

Thanks,
Vaibhav
>  };
>  
>  /*
> @@ -2510,6 +2511,34 @@ static struct omap_hwmod_addr_space am33xx_elm_addr_space[] = {
>  	{ }
>  };
>  
> +/* mdio class */
> +static struct omap_hwmod_class am33xx_mdio_hwmod_class = {
> +	.name		= "davinci_mdio",
> +};
> +
> +struct omap_hwmod_addr_space am33xx_mdio_addr_space[] = {
> +	{
> +		.pa_start	= 0x4A101000,
> +		.pa_end		= 0x4A101000 + SZ_256 - 1,
> +		.flags		= ADDR_MAP_ON_INIT,
> +	},
> +	{ }
> +};
> +
> +static struct omap_hwmod am33xx_mdio_hwmod = {
> +	.name		= "davinci_mdio",
> +	.class		= &am33xx_mdio_hwmod_class,
> +	.clkdm_name	= "cpsw_125mhz_clkdm",
> +	.main_clk	= "cpsw_125mhz_gclk",
> +};
> +
> +struct omap_hwmod_ocp_if am33xx_cpgmac0__mdio = {
> +	.master		= &am33xx_cpgmac0_hwmod,
> +	.slave		= &am33xx_mdio_hwmod,
> +	.addr		= am33xx_mdio_addr_space,
> +	.user		= OCP_USER_MPU,
> +};
> +
>  static struct omap_hwmod_ocp_if am33xx_l4_ls__elm = {
>  	.master		= &am33xx_l4_ls_hwmod,
>  	.slave		= &am33xx_elm_hwmod,
> @@ -3371,6 +3400,7 @@ static struct omap_hwmod_ocp_if *am33xx_hwmod_ocp_ifs[] __initdata = {
>  	&am33xx_l3_main__tptc2,
>  	&am33xx_l3_s__usbss,
>  	&am33xx_l4_hs__cpgmac0,
> +	&am33xx_cpgmac0__mdio,
>  	NULL,
>  };
>  
> 

Fwd: [PATCH 2/5] ARM: OMAP3+: hwmod: Add AM33XX HWMOD data for davinci_mdio

[Vaibhav Hiremath]

On 10/17/2012 11:43 PM, Richard Cochran wrote:
> Paul,
> 
> Would you please take this bugfix for 3.7-rc2? The suggestion to mail
> you came from Toni Lindgren. The context where it came from is here:
> 
> http://lists.arm.linux.org.uk/lurker/message/20121015.191630.bdae3c50.en.html
> 
> Thanks,
> Richard
> 
> ----- Forwarded message from Richard Cochran <richardcochran@gmail.com> -----
> 
> Date: Mon, 15 Oct 2012 21:16:32 +0200
> From: Richard Cochran <richardcochran@gmail.com>
> To: netdev at vger.kernel.org
> Cc: linux-arm-kernel at lists.infradead.org, Arnd Bergmann <arnd@arndb.de>,
> 	David Miller <davem@davemloft.net>,
> 	Russell King <linux@arm.linux.org.uk>,
> 	Mugunthan V N <mugunthanvnm@ti.com>
> Subject: [PATCH 2/5] ARM: OMAP3+: hwmod: Add AM33XX HWMOD data for davinci_mdio
> X-Mailer: git-send-email 1.7.2.5
> 
> From: Mugunthan V N <mugunthanvnm@ti.com>
> 
> This patch adds minimal hwmod support for davinci mdio driver. This patch
> requires rework on parent child relation between cpsw and davinci mdio
> hwmod data to support runtime PM.
> 
> Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
> ---
>  arch/arm/mach-omap2/omap_hwmod_33xx_data.c |   34 ++++++++++++++++++++++++++-
>  1 files changed, 32 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
> index 59d5c1c..f96bbc0 100644
> --- a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
> +++ b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
> @@ -650,8 +650,7 @@ static struct omap_hwmod_class_sysconfig am33xx_cpgmac_sysc = {
>  	.rev_offs	= 0x0,
>  	.sysc_offs	= 0x8,
>  	.syss_offs	= 0x4,
> -	.sysc_flags	= (SYSC_HAS_SIDLEMODE | SYSC_HAS_MIDLEMODE |
> -			   SYSS_HAS_RESET_STATUS),
> +	.sysc_flags	= (SYSC_HAS_SIDLEMODE | SYSC_HAS_MIDLEMODE),
>  	.idlemodes	= (SIDLE_FORCE | SIDLE_NO | MSTANDBY_FORCE |
>  			   MSTANDBY_NO),
>  	.sysc_fields	= &omap_hwmod_sysc_type3,
> @@ -682,6 +681,8 @@ static struct omap_hwmod am33xx_cpgmac0_hwmod = {
>  			.modulemode	= MODULEMODE_SWCTRL,
>  		},
>  	},
> +	.flags		= (HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY |
> +			   HWMOD_INIT_NO_RESET | HWMOD_INIT_NO_IDLE),

Hey Richard,

I feel you have picked up this patch in premature state, I didn't like
this NO_RESET and NO_IDLE flag to be set for MDIO.

Couple of reasons,

1. These flags were added for validation, so I expect cpsw driver
should work without these flags set. I tested it mounting NFS as rootFS
and it works for me.

2. There is HW bug as far as idle (in turn ocp reset) is concerned, and
needs special handling for this. I already have patch for this, which I
will submit it to the list.

http://arago-project.org/git/projects/?p=linux-am33x.git;a=commitdiff;h=a28da2ac98f173f97dbbb46be1ce0a3879f21a11


Note: Sorry for long commit description, it was screwed up by someone
while git push.


I have pushed the tested branch to (linux-omap/master + CPSW patches) -
https://github.com/hvaibhav/am335x-linux/tree/am335x-upstream-staging

Thanks,
Vaibhav
>  };
>  
>  /*
> @@ -2510,6 +2511,34 @@ static struct omap_hwmod_addr_space am33xx_elm_addr_space[] = {
>  	{ }
>  };
>  
> +/* mdio class */
> +static struct omap_hwmod_class am33xx_mdio_hwmod_class = {
> +	.name		= "davinci_mdio",
> +};
> +
> +struct omap_hwmod_addr_space am33xx_mdio_addr_space[] = {
> +	{
> +		.pa_start	= 0x4A101000,
> +		.pa_end		= 0x4A101000 + SZ_256 - 1,
> +		.flags		= ADDR_MAP_ON_INIT,
> +	},
> +	{ }
> +};
> +
> +static struct omap_hwmod am33xx_mdio_hwmod = {
> +	.name		= "davinci_mdio",
> +	.class		= &am33xx_mdio_hwmod_class,
> +	.clkdm_name	= "cpsw_125mhz_clkdm",
> +	.main_clk	= "cpsw_125mhz_gclk",
> +};
> +
> +struct omap_hwmod_ocp_if am33xx_cpgmac0__mdio = {
> +	.master		= &am33xx_cpgmac0_hwmod,
> +	.slave		= &am33xx_mdio_hwmod,
> +	.addr		= am33xx_mdio_addr_space,
> +	.user		= OCP_USER_MPU,
> +};
> +
>  static struct omap_hwmod_ocp_if am33xx_l4_ls__elm = {
>  	.master		= &am33xx_l4_ls_hwmod,
>  	.slave		= &am33xx_elm_hwmod,
> @@ -3371,6 +3400,7 @@ static struct omap_hwmod_ocp_if *am33xx_hwmod_ocp_ifs[] __initdata = {
>  	&am33xx_l3_main__tptc2,
>  	&am33xx_l3_s__usbss,
>  	&am33xx_l4_hs__cpgmac0,
> +	&am33xx_cpgmac0__mdio,
>  	NULL,
>  };
>  
> 

Re: Fwd: [PATCH 2/5] ARM: OMAP3+: hwmod: Add AM33XX HWMOD data for davinci_mdio

[Paul Walmsley]

On Fri, 19 Oct 2012, Vaibhav Hiremath wrote:

> 2. There is HW bug as far as idle (in turn ocp reset) is concerned, and
> needs special handling for this. I already have patch for this, which I
> will submit it to the list.
> 
> http://arago-project.org/git/projects/?p=linux-am33x.git;a=commitdiff;h=a28da2ac98f173f97dbbb46be1ce0a3879f21a11

OK, will drop the original patch and wait for you to post the updated one.


- Paul

Fwd: [PATCH 2/5] ARM: OMAP3+: hwmod: Add AM33XX HWMOD data for davinci_mdio

[Paul Walmsley]

On Fri, 19 Oct 2012, Vaibhav Hiremath wrote:

> 2. There is HW bug as far as idle (in turn ocp reset) is concerned, and
> needs special handling for this. I already have patch for this, which I
> will submit it to the list.
> 
> http://arago-project.org/git/projects/?p=linux-am33x.git;a=commitdiff;h=a28da2ac98f173f97dbbb46be1ce0a3879f21a11

OK, will drop the original patch and wait for you to post the updated one.


- Paul

Re: Fwd: [PATCH 2/5] ARM: OMAP3+: hwmod: Add AM33XX HWMOD data for davinci_mdio

[Paul Walmsley]

Hi Vaibhav

On Fri, 19 Oct 2012, Vaibhav Hiremath wrote:

> Couple of reasons,
> 
> 1. These flags were added for validation, so I expect cpsw driver
> should work without these flags set. I tested it mounting NFS as rootFS
> and it works for me.
> 
> 2. There is HW bug as far as idle (in turn ocp reset) is concerned, and
> needs special handling for this. I already have patch for this, which I
> will submit it to the list.
> 
> http://arago-project.org/git/projects/?p=linux-am33x.git;a=commitdiff;h=a28da2ac98f173f97dbbb46be1ce0a3879f21a11
> 
> 
> Note: Sorry for long commit description, it was screwed up by someone
> while git push.
> 
> 
> I have pushed the tested branch to (linux-omap/master + CPSW patches) -
> https://github.com/hvaibhav/am335x-linux/tree/am335x-upstream-staging

Just checking on this one.  I don't mean to rush you, but if you have 
some patches you'd like to see integrated for 3.8 here, it would be good 
to get them posted before the end of the week.


- Paul

Fwd: [PATCH 2/5] ARM: OMAP3+: hwmod: Add AM33XX HWMOD data for davinci_mdio

[Paul Walmsley]

Hi Vaibhav

On Fri, 19 Oct 2012, Vaibhav Hiremath wrote:

> Couple of reasons,
> 
> 1. These flags were added for validation, so I expect cpsw driver
> should work without these flags set. I tested it mounting NFS as rootFS
> and it works for me.
> 
> 2. There is HW bug as far as idle (in turn ocp reset) is concerned, and
> needs special handling for this. I already have patch for this, which I
> will submit it to the list.
> 
> http://arago-project.org/git/projects/?p=linux-am33x.git;a=commitdiff;h=a28da2ac98f173f97dbbb46be1ce0a3879f21a11
> 
> 
> Note: Sorry for long commit description, it was screwed up by someone
> while git push.
> 
> 
> I have pushed the tested branch to (linux-omap/master + CPSW patches) -
> https://github.com/hvaibhav/am335x-linux/tree/am335x-upstream-staging

Just checking on this one.  I don't mean to rush you, but if you have 
some patches you'd like to see integrated for 3.8 here, it would be good 
to get them posted before the end of the week.


- Paul

RE: Fwd: [PATCH 2/5] ARM: OMAP3+: hwmod: Add AM33XX HWMOD data for davinci_mdio

[Hiremath, Vaibhav]

On Mon, Oct 29, 2012 at 10:49:54, Paul Walmsley wrote:
> Hi Vaibhav
> 
> On Fri, 19 Oct 2012, Vaibhav Hiremath wrote:
> 
> > Couple of reasons,
> > 
> > 1. These flags were added for validation, so I expect cpsw driver
> > should work without these flags set. I tested it mounting NFS as rootFS
> > and it works for me.
> > 
> > 2. There is HW bug as far as idle (in turn ocp reset) is concerned, and
> > needs special handling for this. I already have patch for this, which I
> > will submit it to the list.
> > 
> > http://arago-project.org/git/projects/?p=linux-am33x.git;a=commitdiff;h=a28da2ac98f173f97dbbb46be1ce0a3879f21a11
> > 
> > 
> > Note: Sorry for long commit description, it was screwed up by someone
> > while git push.
> > 
> > 
> > I have pushed the tested branch to (linux-omap/master + CPSW patches) -
> > https://github.com/hvaibhav/am335x-linux/tree/am335x-upstream-staging
> 
> Just checking on this one.  I don't mean to rush you, but if you have 
> some patches you'd like to see integrated for 3.8 here, it would be good 
> to get them posted before the end of the week.
> 

Paul,

I have just integrated all patches on top of linux-omap/master and testing 
it now. 
Shortly I will submit to the list...


Thanks,
Vaibhav

Fwd: [PATCH 2/5] ARM: OMAP3+: hwmod: Add AM33XX HWMOD data for davinci_mdio

[Hiremath, Vaibhav]

On Mon, Oct 29, 2012 at 10:49:54, Paul Walmsley wrote:
> Hi Vaibhav
> 
> On Fri, 19 Oct 2012, Vaibhav Hiremath wrote:
> 
> > Couple of reasons,
> > 
> > 1. These flags were added for validation, so I expect cpsw driver
> > should work without these flags set. I tested it mounting NFS as rootFS
> > and it works for me.
> > 
> > 2. There is HW bug as far as idle (in turn ocp reset) is concerned, and
> > needs special handling for this. I already have patch for this, which I
> > will submit it to the list.
> > 
> > http://arago-project.org/git/projects/?p=linux-am33x.git;a=commitdiff;h=a28da2ac98f173f97dbbb46be1ce0a3879f21a11
> > 
> > 
> > Note: Sorry for long commit description, it was screwed up by someone
> > while git push.
> > 
> > 
> > I have pushed the tested branch to (linux-omap/master + CPSW patches) -
> > https://github.com/hvaibhav/am335x-linux/tree/am335x-upstream-staging
> 
> Just checking on this one.  I don't mean to rush you, but if you have 
> some patches you'd like to see integrated for 3.8 here, it would be good 
> to get them posted before the end of the week.
> 

Paul,

I have just integrated all patches on top of linux-omap/master and testing 
it now. 
Shortly I will submit to the list...


Thanks,
Vaibhav