| Message ID | 20121017181354.GA2412@netboy.at.omicron.at (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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
* 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
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
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 <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
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: > 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, > }; > >
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 >
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 <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
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
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 > > >
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 <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
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 >
* 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
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
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: > > > 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: > > > > 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
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, };