| Message ID | 1461001397-25446-2-git-send-email-grygorii.strashko@ti.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
* Grygorii Strashko <grygorii.strashko@ti.com> [160418 10:44]: > The Davinci MDIO hwod perform only one function now - registers "fck" > clock alias for MDIO functional clock. From all other points of view > it's fake: it's part of cpsw and do not have clkctrl or sysc > registers. > > Hence, its safe to remove it now, because "fck" clock is added > in DT for Davinci MDIO node explicitly. I think you're right here. At least dra7 has just a single module for cpsw at 0x48484000, ap 3 10.0, size 0x4000. I'll check the other SoCs too. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
* Tony Lindgren <tony@atomide.com> [160418 16:34]: > * Grygorii Strashko <grygorii.strashko@ti.com> [160418 10:44]: > > The Davinci MDIO hwod perform only one function now - registers "fck" > > clock alias for MDIO functional clock. From all other points of view > > it's fake: it's part of cpsw and do not have clkctrl or sysc > > registers. > > > > Hence, its safe to remove it now, because "fck" clock is added > > in DT for Davinci MDIO node explicitly. > > I think you're right here. At least dra7 has just a single module > for cpsw at 0x48484000, ap 3 10.0, size 0x4000. I'll check the > other SoCs too. Yeah it seems we only have one module for all the cpsw related IP blocks. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
* Tony Lindgren <tony@atomide.com> [160418 17:15]: > * Tony Lindgren <tony@atomide.com> [160418 16:34]: > > * Grygorii Strashko <grygorii.strashko@ti.com> [160418 10:44]: > > > The Davinci MDIO hwod perform only one function now - registers "fck" > > > clock alias for MDIO functional clock. From all other points of view > > > it's fake: it's part of cpsw and do not have clkctrl or sysc > > > registers. > > > > > > Hence, its safe to remove it now, because "fck" clock is added > > > in DT for Davinci MDIO node explicitly. > > > > I think you're right here. At least dra7 has just a single module > > for cpsw at 0x48484000, ap 3 10.0, size 0x4000. I'll check the > > other SoCs too. > > Yeah it seems we only have one module for all the cpsw related > IP blocks. So are these safe to apply in whatever order? Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 06/21/2016 02:56 PM, Tony Lindgren wrote: > * Tony Lindgren <tony@atomide.com> [160418 17:15]: >> * Tony Lindgren <tony@atomide.com> [160418 16:34]: >>> * Grygorii Strashko <grygorii.strashko@ti.com> [160418 10:44]: >>>> The Davinci MDIO hwod perform only one function now - registers "fck" >>>> clock alias for MDIO functional clock. From all other points of view >>>> it's fake: it's part of cpsw and do not have clkctrl or sysc >>>> registers. >>>> >>>> Hence, its safe to remove it now, because "fck" clock is added >>>> in DT for Davinci MDIO node explicitly. >>> >>> I think you're right here. At least dra7 has just a single module >>> for cpsw at 0x48484000, ap 3 10.0, size 0x4000. I'll check the >>> other SoCs too. >> >> Yeah it seems we only have one module for all the cpsw related >> IP blocks. > > So are these safe to apply in whatever order? > Patch 1 should go first. but do you agree with comment I've added in patch 1: >>> RFC: because it will break DT ABI, mdio will not work on devices with old DTs and new kernel which still do have [ti,hwmods = "davinci_mdio"] property defined in DT: platform 48485000.mdio: Cannot lookup hwmod 'davinci_mdio' davinci_mdio 48485000.mdio: _od_fail_runtime_resume: FIXME: missing hwmod/omap_dev info davinci_mdio: probe of 48485000.mdio failed with error -5 <<<
* Grygorii Strashko <grygorii.strashko@ti.com> [160621 05:21]: > On 06/21/2016 02:56 PM, Tony Lindgren wrote: > > So are these safe to apply in whatever order? > > > > Patch 1 should go first. > > but do you agree with comment I've added in patch 1: > >>> > > RFC: because it will break DT ABI, mdio will not work on devices with > old DTs and new kernel which still do have [ti,hwmods = "davinci_mdio"] > property defined in DT: > platform 48485000.mdio: Cannot lookup hwmod 'davinci_mdio' > davinci_mdio 48485000.mdio: _od_fail_runtime_resume: FIXME: missing > hwmod/omap_dev info > davinci_mdio: probe of 48485000.mdio failed with error -5 Well the ti,hwmods entry we can keep and remove later. How about parse it manually in the driver and just print a warning if no clocks are found and ti,hwmods is set? I think that's the best we can do here. With the warning people know at least what to do. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 06/21/2016 07:50 PM, Tony Lindgren wrote: > * Grygorii Strashko <grygorii.strashko@ti.com> [160621 05:21]: >> On 06/21/2016 02:56 PM, Tony Lindgren wrote: >>> So are these safe to apply in whatever order? >>> >> >> Patch 1 should go first. >> >> but do you agree with comment I've added in patch 1: >>>>> >> >> RFC: because it will break DT ABI, mdio will not work on devices with >> old DTs and new kernel which still do have [ti,hwmods = "davinci_mdio"] >> property defined in DT: >> platform 48485000.mdio: Cannot lookup hwmod 'davinci_mdio' >> davinci_mdio 48485000.mdio: _od_fail_runtime_resume: FIXME: missing >> hwmod/omap_dev info >> davinci_mdio: probe of 48485000.mdio failed with error -5 > > Well the ti,hwmods entry we can keep and remove later. How > about parse it manually in the driver and just print a warning > if no clocks are found and ti,hwmods is set? > > I think that's the best we can do here. With the warning people > know at least what to do. > Yeh. But it will fail not only from the driver :( First of all, it will fail because of commit f5c33b070de3fdb8ad995b767ad0e3487cf0d242 Author: Nishanth Menon <nm@ti.com> Date: Tue Dec 3 19:39:13 2013 -0600 ARM: OMAP2+: omap_device: add fail hook for runtime_pm when bad data is detected ^ which will cause all PM runtime calls to fail if there is ti,hwmods prop in DT, but no hwmod in code. I invented few ways to fix above problem: - introduce list of obsolete hwmods - any hwmods listed in this per SoC list will be ignored by hwmod and omap_device frameworks; - implement mach_desc->dt_fixup() and patch DT on the fly by removing known deprecated props; - Or just ignore... In general, "fck" problem can be solved by adding clk_dev alias (if it's still possible/acceptable), like: DT_CLK(NULL, "dss_deshdcp_clk", "dss_deshdcp_clk"), + DT_CLK("48485000.mdio", "fck", "dpll_gmac_ck"), { .node_name = NULL },
* Grygorii Strashko <grygorii.strashko@ti.com> [160621 10:15]: > On 06/21/2016 07:50 PM, Tony Lindgren wrote: > > * Grygorii Strashko <grygorii.strashko@ti.com> [160621 05:21]: > >> On 06/21/2016 02:56 PM, Tony Lindgren wrote: > >>> So are these safe to apply in whatever order? > >>> > >> > >> Patch 1 should go first. > >> > >> but do you agree with comment I've added in patch 1: > >>>>> > >> > >> RFC: because it will break DT ABI, mdio will not work on devices with > >> old DTs and new kernel which still do have [ti,hwmods = "davinci_mdio"] > >> property defined in DT: > >> platform 48485000.mdio: Cannot lookup hwmod 'davinci_mdio' > >> davinci_mdio 48485000.mdio: _od_fail_runtime_resume: FIXME: missing > >> hwmod/omap_dev info > >> davinci_mdio: probe of 48485000.mdio failed with error -5 > > > > Well the ti,hwmods entry we can keep and remove later. How > > about parse it manually in the driver and just print a warning > > if no clocks are found and ti,hwmods is set? > > > > I think that's the best we can do here. With the warning people > > know at least what to do. > > > > Yeh. But it will fail not only from the driver :( > First of all, it will fail because of > commit f5c33b070de3fdb8ad995b767ad0e3487cf0d242 > Author: Nishanth Menon <nm@ti.com> > Date: Tue Dec 3 19:39:13 2013 -0600 > > ARM: OMAP2+: omap_device: add fail hook for runtime_pm when bad data is detected > > ^ which will cause all PM runtime calls to fail if there is ti,hwmods prop in DT, > but no hwmod in code. > > I invented few ways to fix above problem: > - introduce list of obsolete hwmods - any hwmods listed in this per SoC list > will be ignored by hwmod and omap_device frameworks; > - implement mach_desc->dt_fixup() and patch DT on the fly by removing > known deprecated props; > - Or just ignore... OK I see where the RFC comes from then.. Sounds like we need to think about this a bit more for the safe set of patches. > In general, "fck" problem can be solved by adding clk_dev alias (if it's still > possible/acceptable), like: > DT_CLK(NULL, "dss_deshdcp_clk", "dss_deshdcp_clk"), > + DT_CLK("48485000.mdio", "fck", "dpll_gmac_ck"), > { .node_name = NULL }, Seems like that's a good place to start before disabling the bogus hwmod for this module. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c index 9442d89..32b6ca2 100644 --- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c +++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c @@ -331,20 +331,6 @@ static struct omap_hwmod dra7xx_gmac_hwmod = { }; /* - * 'mdio' class - */ -static struct omap_hwmod_class dra7xx_mdio_hwmod_class = { - .name = "davinci_mdio", -}; - -static struct omap_hwmod dra7xx_mdio_hwmod = { - .name = "davinci_mdio", - .class = &dra7xx_mdio_hwmod_class, - .clkdm_name = "gmac_clkdm", - .main_clk = "dpll_gmac_ck", -}; - -/* * 'dcan' class * */ @@ -2607,12 +2593,6 @@ static struct omap_hwmod_ocp_if dra7xx_l4_per2__cpgmac0 = { .user = OCP_USER_MPU, }; -static struct omap_hwmod_ocp_if dra7xx_gmac__mdio = { - .master = &dra7xx_gmac_hwmod, - .slave = &dra7xx_mdio_hwmod, - .user = OCP_USER_MPU, -}; - /* l4_wkup -> dcan1 */ static struct omap_hwmod_ocp_if dra7xx_l4_wkup__dcan1 = { .master = &dra7xx_l4_wkup_hwmod, @@ -3486,7 +3466,6 @@ static struct omap_hwmod_ocp_if *dra7xx_hwmod_ocp_ifs[] __initdata = { &dra7xx_l4_per2__cpgmac0, &dra7xx_l4_per2__mcasp3, &dra7xx_l3_main_1__mcasp3, - &dra7xx_gmac__mdio, &dra7xx_l4_cfg__dma_system, &dra7xx_l3_main_1__tpcc, &dra7xx_l3_main_1__tptc0,
The Davinci MDIO hwod perform only one function now - registers "fck" clock alias for MDIO functional clock. From all other points of view it's fake: it's part of cpsw and do not have clkctrl or sysc registers. Hence, its safe to remove it now, because "fck" clock is added in DT for Davinci MDIO node explicitly. Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com> --- See comments to patch 1. arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 21 --------------------- 1 file changed, 21 deletions(-)