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

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 [off-list ref] -----

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 [off-list ref],
	Russell King [off-list ref],
	Mugunthan V N [off-list ref]
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 <redacted>

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 <redacted>
---
 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 -----

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

- Paul

* Paul Walmsley [off-list ref] [121017 16:39]:

Hi Richard

On Wed, 17 Oct 2012, Richard Cochran wrote:

quoted

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

On Wed, Oct 17, 2012 at 04:50:46PM -0700, Tony Lindgren wrote:

* Paul Walmsley [off-list ref] [121017 16:39]:

quoted

Hi Richard

On Wed, 17 Oct 2012, Richard Cochran wrote:

quoted

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

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

Op 18 okt. 2012, om 05:06 heeft Richard Cochran [off-list ref] het volgende geschreven:

On Wed, Oct 17, 2012 at 04:50:46PM -0700, Tony Lindgren wrote:

quoted

* Paul Walmsley [off-list ref] [121017 16:39]:

quoted

Hi Richard

On Wed, 17 Oct 2012, Richard Cochran wrote:

quoted

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

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

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

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

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

On 10/17/2012 11:43 PM, Richard Cochran wrote:

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

On 10/19/2012 12:14 AM, Richard Cochran wrote:

On Thu, Oct 18, 2012 at 03:46:15AM +0000, Paul Walmsley wrote:

quoted

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.

...

quoted

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

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

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

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

* Richard Cochran [off-list ref] [121018 23:18]:

On Fri, Oct 19, 2012 at 02:18:29AM +0530, Vaibhav Hiremath wrote:

quoted

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

On Fri, Oct 19, 2012 at 09:00:41AM -0700, Tony Lindgren wrote:

* Richard Cochran [off-list ref] [121018 23:18]:

quoted

On Fri, Oct 19, 2012 at 02:18:29AM +0530, Vaibhav Hiremath wrote:

quoted

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

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:

quoted

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

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

On Fri, Oct 19, 2012 at 21:30:41, Tony Lindgren wrote:

* Richard Cochran [off-list ref] [121018 23:18]:

quoted

On Fri, Oct 19, 2012 at 02:18:29AM +0530, Vaibhav Hiremath wrote:

quoted

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 

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:

quoted

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

* Hiremath, Vaibhav [off-list ref] [121026 01:24]:

On Fri, Oct 19, 2012 at 21:30:41, Tony Lindgren wrote:

quoted

* Richard Cochran [off-list ref] [121018 23:18]:

quoted

On Fri, Oct 19, 2012 at 02:18:29AM +0530, Vaibhav Hiremath wrote:

quoted

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

On Fri, Oct 26, 2012 at 23:36:28, Tony Lindgren wrote:

* Hiremath, Vaibhav [off-list ref] [121026 01:24]:

quoted

On Fri, Oct 19, 2012 at 21:30:41, Tony Lindgren wrote:

quoted

* Richard Cochran [off-list ref] [121018 23:18]:

quoted

On Fri, Oct 19, 2012 at 02:18:29AM +0530, Vaibhav Hiremath wrote:

quoted

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.
 

quoted

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

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

On Mon, Oct 29, 2012 at 10:49:54, Paul Walmsley wrote:

Hi Vaibhav

On Fri, 19 Oct 2012, Vaibhav Hiremath wrote:

quoted

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

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

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:

quoted

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