| Message ID | k80da6$61d$1@ger.gmane.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Hi, On Wed, Nov 14, 2012 at 4:28 PM, Igor Mazanov <i.mazanov@gmail.com> wrote: > Hello, > > Beaglebone boot process is broken with the current git kernel. I use > omap2plus_defconfig for tests. > > It looks like the boot process stops due to the last changes in the AM33xx > clock sysbsystem. A following patch resolves this issue: > > diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c > b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c > index ad8d43b..858e180 100644 > --- a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c > +++ b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c > @@ -586,7 +586,7 @@ static struct omap_hwmod am33xx_smartreflex0_hwmod = { > .class = &am33xx_smartreflex_hwmod_class, > .clkdm_name = "l4_wkup_clkdm", > .mpu_irqs = am33xx_smartreflex0_irqs, > - .main_clk = "smartreflex0_fck", > + .main_clk = "smartreflex_mpu_fck", > .prcm = { > .omap4 = { > .clkctrl_offs = > AM33XX_CM_WKUP_SMARTREFLEX0_CLKCTRL_OFFSET, > @@ -606,7 +606,7 @@ static struct omap_hwmod am33xx_smartreflex1_hwmod = { > .class = &am33xx_smartreflex_hwmod_class, > .clkdm_name = "l4_wkup_clkdm", > .mpu_irqs = am33xx_smartreflex1_irqs, > - .main_clk = "smartreflex1_fck", > + .main_clk = "smartreflex_core_fck", > .prcm = { > .omap4 = { > .clkctrl_offs = > AM33XX_CM_WKUP_SMARTREFLEX1_CLKCTRL_OFFSET, > About the name field in the hwmod entry: the SR code checks on the value of "smartreflex_mpu_iva" to differentiate the SR IP blocks and to apply the correct parameters to each of them. Cf. the function sr_set_regfields in drivers/power/avs/smartreflex.c. The patch should change the name of the hwmod entry as well, can you fold this change in the current patch? Note: I know the name "smartreflex_mpu_iva" is not perfect since it does not apply to all OMAP3 variants, maybe we could change the SR code to be more generic. Nishant, what do you think? Regards, Jean > > Regards, > Igor. > > -- > 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 -- 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 11/14/2012 10:41 AM, Jean Pihet wrote: > Hi, > > On Wed, Nov 14, 2012 at 4:28 PM, Igor Mazanov <i.mazanov@gmail.com> wrote: >> Hello, >> >> Beaglebone boot process is broken with the current git kernel. I use >> omap2plus_defconfig for tests. >> >> It looks like the boot process stops due to the last changes in the AM33xx >> clock sysbsystem. A following patch resolves this issue: >> >> diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c >> b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c >> index ad8d43b..858e180 100644 >> --- a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c >> +++ b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c >> @@ -586,7 +586,7 @@ static struct omap_hwmod am33xx_smartreflex0_hwmod = { >> .class = &am33xx_smartreflex_hwmod_class, >> .clkdm_name = "l4_wkup_clkdm", >> .mpu_irqs = am33xx_smartreflex0_irqs, >> - .main_clk = "smartreflex0_fck", >> + .main_clk = "smartreflex_mpu_fck", >> .prcm = { >> .omap4 = { >> .clkctrl_offs = >> AM33XX_CM_WKUP_SMARTREFLEX0_CLKCTRL_OFFSET, >> @@ -606,7 +606,7 @@ static struct omap_hwmod am33xx_smartreflex1_hwmod = { >> .class = &am33xx_smartreflex_hwmod_class, >> .clkdm_name = "l4_wkup_clkdm", >> .mpu_irqs = am33xx_smartreflex1_irqs, >> - .main_clk = "smartreflex1_fck", >> + .main_clk = "smartreflex_core_fck", >> .prcm = { >> .omap4 = { >> .clkctrl_offs = >> AM33XX_CM_WKUP_SMARTREFLEX1_CLKCTRL_OFFSET, >> > > About the name field in the hwmod entry: the SR code checks on the > value of "smartreflex_mpu_iva" to differentiate the SR IP blocks and > to apply the correct parameters to each of them. Cf. the function > sr_set_regfields in drivers/power/avs/smartreflex.c. > > The patch should change the name of the hwmod entry as well, can you > fold this change in the current patch? > > Note: I know the name "smartreflex_mpu_iva" is not perfect since it > does not apply to all OMAP3 variants, maybe we could change the SR > code to be more generic. > > Nishant, what do you think? > Might be an better idea to remove the entire function sr_set_regfields instead provide the err_weight, max_limit, accum_data, avgweights to platform_data. -- Regards, Nishanth Menon -- 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
* Jean Pihet <jean.pihet@newoldbits.com> [121114 08:43]: > > The patch should change the name of the hwmod entry as well, can you > fold this change in the current patch? This was caused by the merge of omap-for-v3.8/pm into omap-for-v3.8/clock. I noticed a smilar issue for omap3, but missed at least this one. Jean, can you please check omap-for-v3.8/clock for the smartreflex clock names in case there are more issues like this remaining? 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
Hi Tony, On Wed, Nov 14, 2012 at 6:51 PM, Tony Lindgren <tony@atomide.com> wrote: > * Jean Pihet <jean.pihet@newoldbits.com> [121114 08:43]: >> >> The patch should change the name of the hwmod entry as well, can you >> fold this change in the current patch? > > This was caused by the merge of omap-for-v3.8/pm into omap-for-v3.8/clock. > I noticed a smilar issue for omap3, but missed at least this one. > > Jean, can you please check omap-for-v3.8/clock for the smartreflex > clock names in case there are more issues like this remaining? The hwmod clock names are OK for 3xxx, 36xx, 33xx and 44xx. The hwmod names are OK excepted for 33xx where they respectively should be "smartreflex_mpu_iva" and ""smartreflex_core". This issue is caused by 99e7938d "ARM: OMAP3: clock: Add 3xxx data using common struct clk" in omap-for-v3.8/clock. > Regards, > > Tony Regards, Jean -- 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
* Jean Pihet <jean.pihet@newoldbits.com> [121115 06:49]: > Hi Tony, > > On Wed, Nov 14, 2012 at 6:51 PM, Tony Lindgren <tony@atomide.com> wrote: > > * Jean Pihet <jean.pihet@newoldbits.com> [121114 08:43]: > >> > >> The patch should change the name of the hwmod entry as well, can you > >> fold this change in the current patch? > > > > This was caused by the merge of omap-for-v3.8/pm into omap-for-v3.8/clock. > > I noticed a smilar issue for omap3, but missed at least this one. > > > > Jean, can you please check omap-for-v3.8/clock for the smartreflex > > clock names in case there are more issues like this remaining? > The hwmod clock names are OK for 3xxx, 36xx, 33xx and 44xx. The hwmod > names are OK excepted for 33xx where they respectively should be > "smartreflex_mpu_iva" and ""smartreflex_core". > > This issue is caused by 99e7938d "ARM: OMAP3: clock: Add 3xxx data > using common struct clk" in omap-for-v3.8/clock. OK thanks for checking. 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
* Jean Pihet <jean.pihet@newoldbits.com> [121114 08:43]: > On Wed, Nov 14, 2012 at 4:28 PM, Igor Mazanov <i.mazanov@gmail.com> wrote: > > > > Beaglebone boot process is broken with the current git kernel. I use > > omap2plus_defconfig for tests. > > > > It looks like the boot process stops due to the last changes in the AM33xx > > clock sysbsystem. A following patch resolves this issue: ... > The patch should change the name of the hwmod entry as well, can you > fold this change in the current patch? Any news on updating this? 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 Wed, Nov 21, 2012 at 9:38 PM, Tony Lindgren <tony@atomide.com> wrote: > * Jean Pihet <jean.pihet@newoldbits.com> [121114 08:43]: >> On Wed, Nov 14, 2012 at 4:28 PM, Igor Mazanov <i.mazanov@gmail.com> wrote: >> > >> > Beaglebone boot process is broken with the current git kernel. I use >> > omap2plus_defconfig for tests. >> > >> > It looks like the boot process stops due to the last changes in the AM33xx >> > clock sysbsystem. A following patch resolves this issue: > ... > >> The patch should change the name of the hwmod entry as well, can you >> fold this change in the current patch? > > Any news on updating this? The current kernel boots, but after a switching to CCF doesn't work the debugss - it's just disabled in the current hwmod code. So, it looks like we can't use JTAG to connect to the running kernel. Regards, Igor. > 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 Thu, Nov 22, 2012 at 6:49 PM, Hiremath, Vaibhav <hvaibhav@ti.com> wrote: > On Thu, Nov 22, 2012 at 20:17:26, Hiremath, Vaibhav wrote: >> On Thu, Nov 22, 2012 at 17:46:50, Igor Mazanov wrote: >> > On Thu, Nov 22, 2012 at 9:42 AM, Vaibhav Hiremath <hvaibhav@ti.com> wrote: >> > > >> > > >> > > On 11/22/2012 1:30 AM, Igor Mazanov wrote: >> > >> On Wed, Nov 21, 2012 at 9:38 PM, Tony Lindgren <tony@atomide.com> wrote: >> > >>> * Jean Pihet <jean.pihet@newoldbits.com> [121114 08:43]: >> > >>>> On Wed, Nov 14, 2012 at 4:28 PM, Igor Mazanov <i.mazanov@gmail.com> wrote: >> > >>>>> >> > >>>>> Beaglebone boot process is broken with the current git kernel. I use >> > >>>>> omap2plus_defconfig for tests. >> > >>>>> >> > >>>>> It looks like the boot process stops due to the last changes in the AM33xx >> > >>>>> clock sysbsystem. A following patch resolves this issue: >> > >>> ... >> > >>> >> > >>>> The patch should change the name of the hwmod entry as well, can you >> > >>>> fold this change in the current patch? >> > >>> >> > >>> Any news on updating this? >> > >> >> > >> The current kernel boots, but after a switching to CCF doesn't work >> > >> the debugss - it's just disabled in the current hwmod code. So, it >> > >> looks like we can't use JTAG to connect to the running kernel. >> > >> >> > > >> > > just resumed from vacation... >> > > >> > > JTAG clock will get disabled because, CONFIG_OMAP_RESET_CLOCKS will >> > > disable unused clocks, so as debugss clock. >> > > >> > > There is another thread started by Joel on the similar issue, >> > > >> > > http://www.mail-archive.com/linux-omap@vger.kernel.org/msg80863.html >> > > >> > > Something below should be done for debugss on AM33xx, >> > > >> > > diff --git a/arch/arm/mach-omap2/clock33xx_data.c >> > > b/arch/arm/mach-omap2/clock33xx_data.c >> > > index 17e3de5..60e0b53 100644 >> > > --- a/arch/arm/mach-omap2/clock33xx_data.c >> > > +++ b/arch/arm/mach-omap2/clock33xx_data.c >> > > @@ -584,6 +584,9 @@ static struct clk debugss_ick = { >> > > .clkdm_name = "l3_aon_clkdm", >> > > .parent = &dpll_core_m4_ck, >> > > .ops = &clkops_omap2_dflt, >> > > +#ifdef CONFIG_DEBUG_KERNEL >> > > + .flags = ENABLE_ON_INIT, >> > > +#endif >> > > .enable_reg = AM33XX_CM_WKUP_DEBUGSS_CLKCTRL, >> > > .enable_bit = AM33XX_MODULEMODE_SWCTRL, >> > > .recalc = &followparent_recalc, >> > >> > Yes, I noticed this thread. But now a clock subsystem in the current >> > kernel is switched to Common Clock Framework and debugss (and several >> > another modules) is disabled >> >> Still this can be handled and enabled during init. >> >> >> > (#if 0 .... #endif) in >> > omap_hwmod_33xx_data.c. >> > >> > From omap_hwmod_33xx_data.c: >> > >> > /* >> > * Modules omap_hwmod structures >> > * >> > * The following IPs are excluded for the moment because: >> > * - They do not need an explicit SW control using omap_hwmod API. >> > * - They still need to be validated with the driver >> > * properly adapted to omap_hwmod / omap_device >> > * >> > * - cEFUSE (doesn't fall under any ocp_if) >> > * - clkdiv32k >> > * - debugss >> > * - ocmc ram >> > * - ocp watch point >> > * - aes0 >> > * - sha0 >> > */ >> > >> > I uncommented the debugss entry in the omap_hwmod settings, but only >> > got a warning like: >> > >> > CC arch/arm/mach-omap2/omap_hwmod_33xx_data.o >> > arch/arm/mach-omap2/omap_hwmod_33xx_data.c:472:26: warning: >> > 'am33xx_debugss_hwmod' defined but not used [-Wunused-variable] >> > >> > By the way, I need to use JTAG to trace a problem described in this thread: >> > >> > http://marc.info/?l=linux-omap&m=135307646415429&w=2 >> > >> > May be, it's the clocks related issue too... >> > >> >> >> I have quickly created patch for you, can you try below patch and let me >> know? >> >> >> >> diff --git a/arch/arm/mach-omap2/cclock33xx_data.c b/arch/arm/mach-omap2/cclock33xx_data.c >> index ea64ad6..c9af78c 100644 >> --- a/arch/arm/mach-omap2/cclock33xx_data.c >> +++ b/arch/arm/mach-omap2/cclock33xx_data.c >> @@ -920,6 +920,7 @@ static const char *enable_init_clks[] = { >> "l4hs_gclk", >> "l4fw_gclk", >> "l4ls_gclk", >> + "debugss_ick", >> }; >> >> int __init am33xx_clk_init(void) >> diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c >> index ad8d43b..750b897 100644 >> --- a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c >> +++ b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c >> @@ -460,27 +460,6 @@ static struct omap_hwmod am33xx_clkdiv32k_hwmod = { >> }, >> }; >> >> -/* >> - * 'debugss' class >> - * debug sub system >> - */ >> -static struct omap_hwmod_class am33xx_debugss_hwmod_class = { >> - .name = "debugss", >> -}; >> - >> -static struct omap_hwmod am33xx_debugss_hwmod = { >> - .name = "debugss", >> - .class = &am33xx_debugss_hwmod_class, >> - .clkdm_name = "l3_aon_clkdm", >> - .main_clk = "debugss_ick", >> - .prcm = { >> - .omap4 = { >> - .clkctrl_offs = AM33XX_CM_WKUP_DEBUGSS_CLKCTRL_OFFSET, >> - .modulemode = MODULEMODE_SWCTRL, >> - }, >> - }, >> -}; >> - >> /* ocmcram */ >> static struct omap_hwmod_class am33xx_ocmcram_hwmod_class = { >> .name = "ocmcram", >> @@ -570,6 +549,28 @@ static struct omap_hwmod am33xx_sha0_hwmod = { >> >> #endif >> >> +/* >> + * 'debugss' class >> + * debug sub system >> + */ >> +static struct omap_hwmod_class am33xx_debugss_hwmod_class = { >> + .name = "debugss", >> +}; >> + >> +static struct omap_hwmod am33xx_debugss_hwmod = { >> + .name = "debugss", >> + .class = &am33xx_debugss_hwmod_class, >> + .clkdm_name = "l3_aon_clkdm", >> + .main_clk = "debugss_ick", >> + .flags = (HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET), >> + .prcm = { >> + .omap4 = { >> + .clkctrl_offs = AM33XX_CM_WKUP_DEBUGSS_CLKCTRL_OFFSET, >> + .modulemode = MODULEMODE_SWCTRL, >> + }, >> + }, >> +}; >> + >> /* 'smartreflex' class */ >> static struct omap_hwmod_class am33xx_smartreflex_hwmod_class = { >> .name = "smartreflex", >> @@ -2261,6 +2262,24 @@ static struct omap_hwmod_ocp_if am33xx_l3_main__gfx = { >> .user = OCP_USER_MPU | OCP_USER_SDMA, >> }; >> >> +/* l3_main -> debugss */ >> +static struct omap_hwmod_addr_space am33xx_debugss_addrs[] = { >> + { >> + .pa_start = 0x4b000000, >> + .pa_end = 0x4b000000 + SZ_16M - 1, >> + .flags = ADDR_TYPE_RT >> + }, >> + { } >> +}; >> + >> +static struct omap_hwmod_ocp_if am33xx_l3_main__debugss = { >> + .master = &am33xx_l3_main_hwmod, >> + .slave = &am33xx_debugss_hwmod, >> + .clk = "debugss_ick", >> + .addr = am33xx_debugss_addrs, >> + .user = OCP_USER_MPU, >> +}; >> + >> /* l4 wkup -> smartreflex0 */ >> static struct omap_hwmod_addr_space am33xx_smartreflex0_addrs[] = { >> { >> @@ -3315,6 +3334,7 @@ static struct omap_hwmod_ocp_if *am33xx_hwmod_ocp_ifs[] __initdata = { >> &am33xx_pruss__l3_main, >> &am33xx_wkup_m3__l4_wkup, >> &am33xx_gfx__l3_main, >> + &am33xx_l3_main__debugss, >> &am33xx_l4_wkup__wkup_m3, >> &am33xx_l4_wkup__control, >> &am33xx_l4_wkup__smartreflex0, >> >> > > > > Missed to mention that, > > I have boot tested it on Bone platform and made sure that debugs module > stays enabled after boot (after applying this patch). > I applied your patch and it works for me too. JTAG interface is working now. Thanks! Regards, Igor. > Thanks, > Vaibhav -- 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
Hi Vaibhav, Igor, On and off due to vacation time too,.. Not sure but I missed the below patch from Vaibhav as it probably wasn't copied to linux-omap so I got confused which patch was Igor testing, whether it was the one in which we set ENABLE_ON_INIT or the one in which hwmod data is changed. I think Igor tried the latter and it works. In that case, I guess we can drop the ENABLE_ON_INIT patch if this is a better fix. I had some comments though... On Thu, Nov 22, 2012 at 10:40 AM, Igor Mazanov <i.mazanov@gmail.com> wrote: > On Thu, Nov 22, 2012 at 6:49 PM, Hiremath, Vaibhav <hvaibhav@ti.com> wrote: [..] >>> I have quickly created patch for you, can you try below patch and let me >>> know? >>> >>> >>> >>> diff --git a/arch/arm/mach-omap2/cclock33xx_data.c b/arch/arm/mach-omap2/cclock33xx_data.c >>> index ea64ad6..c9af78c 100644 >>> --- a/arch/arm/mach-omap2/cclock33xx_data.c >>> +++ b/arch/arm/mach-omap2/cclock33xx_data.c >>> @@ -920,6 +920,7 @@ static const char *enable_init_clks[] = { >>> "l4hs_gclk", >>> "l4fw_gclk", >>> "l4ls_gclk", >>> + "debugss_ick", >>> }; >>> >>> int __init am33xx_clk_init(void) >>> diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c >>> index ad8d43b..750b897 100644 >>> --- a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c >>> +++ b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c >>> @@ -460,27 +460,6 @@ static struct omap_hwmod am33xx_clkdiv32k_hwmod = { >>> }, >>> }; >>> >>> -/* >>> - * 'debugss' class >>> - * debug sub system >>> - */ >>> -static struct omap_hwmod_class am33xx_debugss_hwmod_class = { >>> - .name = "debugss", >>> -}; >>> - >>> -static struct omap_hwmod am33xx_debugss_hwmod = { >>> - .name = "debugss", >>> - .class = &am33xx_debugss_hwmod_class, >>> - .clkdm_name = "l3_aon_clkdm", >>> - .main_clk = "debugss_ick", >>> - .prcm = { >>> - .omap4 = { >>> - .clkctrl_offs = AM33XX_CM_WKUP_DEBUGSS_CLKCTRL_OFFSET, >>> - .modulemode = MODULEMODE_SWCTRL, >>> - }, >>> - }, >>> -}; >>> - >>> /* ocmcram */ >>> static struct omap_hwmod_class am33xx_ocmcram_hwmod_class = { >>> .name = "ocmcram", >>> @@ -570,6 +549,28 @@ static struct omap_hwmod am33xx_sha0_hwmod = { >>> >>> #endif >>> >>> +/* >>> + * 'debugss' class >>> + * debug sub system >>> + */ >>> +static struct omap_hwmod_class am33xx_debugss_hwmod_class = { >>> + .name = "debugss", >>> +}; >>> + >>> +static struct omap_hwmod am33xx_debugss_hwmod = { >>> + .name = "debugss", >>> + .class = &am33xx_debugss_hwmod_class, >>> + .clkdm_name = "l3_aon_clkdm", >>> + .main_clk = "debugss_ick", >>> + .flags = (HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET), Setting these flags would still leave the problem where JTAG clocks are on when its not required no? In that case, what is the advantage of this patch? Regards, Joel -- 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 Fri, Nov 23, 2012 at 02:26:40, Joel A Fernandes wrote: > Hi Vaibhav, Igor, > > On and off due to vacation time too,.. > > Not sure but I missed the below patch from Vaibhav as it probably > wasn't copied to linux-omap so I got confused which patch was Igor > testing, whether it was the one in which we set ENABLE_ON_INIT or the > one in which hwmod data is changed. > > I think Igor tried the latter and it works. In that case, I guess we > can drop the ENABLE_ON_INIT patch if this is a better fix. I had some > comments though... > Let try to explain why we should go with hwmod patches, When I submitted clock tree patch, we decided to remove all leaf-nodes from the data, but since modules like debugs were not enabled in hwmod (as done for omap) I had explicitly keep these nodes in clock-tree to disable them with RESET_CLOCKS flag. Please refer to the comment in file clock33xx_data.c 567 /* 568 * Modules clock nodes 569 * 570 * The following clock leaf nodes are added for the moment because: 571 * 572 * - hwmod data is not present for these modules, either hwmod 573 * control is not required or its not populated. 574 * - Driver code is not yet migrated to use hwmod/runtime pm 575 * - Modules outside kernel access (to disable them by default) 576 * 577 * - debugss 578 * - mmu (gfx domain) 579 * - cefuse 580 * - usbotg_fck (its additional clock and not really a modulemode) 581 * - ieee5000 582 */ Ideally (and to keep consistency with existing implementation), we should enable hwmod node and remove clock-tree node. > On Thu, Nov 22, 2012 at 10:40 AM, Igor Mazanov <i.mazanov@gmail.com> wrote: > > On Thu, Nov 22, 2012 at 6:49 PM, Hiremath, Vaibhav <hvaibhav@ti.com> wrote: > [..] > >>> I have quickly created patch for you, can you try below patch and let me > >>> know? > >>> > >>> > >>> > >>> diff --git a/arch/arm/mach-omap2/cclock33xx_data.c b/arch/arm/mach-omap2/cclock33xx_data.c > >>> index ea64ad6..c9af78c 100644 > >>> --- a/arch/arm/mach-omap2/cclock33xx_data.c > >>> +++ b/arch/arm/mach-omap2/cclock33xx_data.c > >>> @@ -920,6 +920,7 @@ static const char *enable_init_clks[] = { > >>> "l4hs_gclk", > >>> "l4fw_gclk", > >>> "l4ls_gclk", > >>> + "debugss_ick", > >>> }; > >>> > >>> int __init am33xx_clk_init(void) > >>> diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c > >>> index ad8d43b..750b897 100644 > >>> --- a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c > >>> +++ b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c > >>> @@ -460,27 +460,6 @@ static struct omap_hwmod am33xx_clkdiv32k_hwmod = { > >>> }, > >>> }; > >>> > >>> -/* > >>> - * 'debugss' class > >>> - * debug sub system > >>> - */ > >>> -static struct omap_hwmod_class am33xx_debugss_hwmod_class = { > >>> - .name = "debugss", > >>> -}; > >>> - > >>> -static struct omap_hwmod am33xx_debugss_hwmod = { > >>> - .name = "debugss", > >>> - .class = &am33xx_debugss_hwmod_class, > >>> - .clkdm_name = "l3_aon_clkdm", > >>> - .main_clk = "debugss_ick", > >>> - .prcm = { > >>> - .omap4 = { > >>> - .clkctrl_offs = AM33XX_CM_WKUP_DEBUGSS_CLKCTRL_OFFSET, > >>> - .modulemode = MODULEMODE_SWCTRL, > >>> - }, > >>> - }, > >>> -}; > >>> - > >>> /* ocmcram */ > >>> static struct omap_hwmod_class am33xx_ocmcram_hwmod_class = { > >>> .name = "ocmcram", > >>> @@ -570,6 +549,28 @@ static struct omap_hwmod am33xx_sha0_hwmod = { > >>> > >>> #endif > >>> > >>> +/* > >>> + * 'debugss' class > >>> + * debug sub system > >>> + */ > >>> +static struct omap_hwmod_class am33xx_debugss_hwmod_class = { > >>> + .name = "debugss", > >>> +}; > >>> + > >>> +static struct omap_hwmod am33xx_debugss_hwmod = { > >>> + .name = "debugss", > >>> + .class = &am33xx_debugss_hwmod_class, > >>> + .clkdm_name = "l3_aon_clkdm", > >>> + .main_clk = "debugss_ick", > >>> + .flags = (HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET), > > Setting these flags would still leave the problem where JTAG clocks > are on when its not required no? In that case, what is the advantage > of this patch? > I missed to wrap it around #ifdef CONFIG_DEBUG_KERNEL. I will submit the formal patch shortly. Thanks, Vaibhav -- 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 Thu, Nov 22, 2012 at 22:10:07, Igor Mazanov wrote: > On Thu, Nov 22, 2012 at 6:49 PM, Hiremath, Vaibhav <hvaibhav@ti.com> wrote: > > On Thu, Nov 22, 2012 at 20:17:26, Hiremath, Vaibhav wrote: > >> On Thu, Nov 22, 2012 at 17:46:50, Igor Mazanov wrote: > >> > On Thu, Nov 22, 2012 at 9:42 AM, Vaibhav Hiremath <hvaibhav@ti.com> wrote: > >> > > > >> > > > >> > > On 11/22/2012 1:30 AM, Igor Mazanov wrote: > >> > >> On Wed, Nov 21, 2012 at 9:38 PM, Tony Lindgren <tony@atomide.com> wrote: > >> > >>> * Jean Pihet <jean.pihet@newoldbits.com> [121114 08:43]: > >> > >>>> On Wed, Nov 14, 2012 at 4:28 PM, Igor Mazanov <i.mazanov@gmail.com> wrote: > >> > >>>>> > >> > >>>>> Beaglebone boot process is broken with the current git kernel. I use > >> > >>>>> omap2plus_defconfig for tests. > >> > >>>>> > >> > >>>>> It looks like the boot process stops due to the last changes in the AM33xx > >> > >>>>> clock sysbsystem. A following patch resolves this issue: > >> > >>> ... > >> > >>> > >> > >>>> The patch should change the name of the hwmod entry as well, can you > >> > >>>> fold this change in the current patch? > >> > >>> > >> > >>> Any news on updating this? > >> > >> > >> > >> The current kernel boots, but after a switching to CCF doesn't work > >> > >> the debugss - it's just disabled in the current hwmod code. So, it > >> > >> looks like we can't use JTAG to connect to the running kernel. > >> > >> > >> > > > >> > > just resumed from vacation... > >> > > > >> > > JTAG clock will get disabled because, CONFIG_OMAP_RESET_CLOCKS will > >> > > disable unused clocks, so as debugss clock. > >> > > > >> > > There is another thread started by Joel on the similar issue, > >> > > > >> > > http://www.mail-archive.com/linux-omap@vger.kernel.org/msg80863.html > >> > > > >> > > Something below should be done for debugss on AM33xx, > >> > > > >> > > diff --git a/arch/arm/mach-omap2/clock33xx_data.c > >> > > b/arch/arm/mach-omap2/clock33xx_data.c > >> > > index 17e3de5..60e0b53 100644 > >> > > --- a/arch/arm/mach-omap2/clock33xx_data.c > >> > > +++ b/arch/arm/mach-omap2/clock33xx_data.c > >> > > @@ -584,6 +584,9 @@ static struct clk debugss_ick = { > >> > > .clkdm_name = "l3_aon_clkdm", > >> > > .parent = &dpll_core_m4_ck, > >> > > .ops = &clkops_omap2_dflt, > >> > > +#ifdef CONFIG_DEBUG_KERNEL > >> > > + .flags = ENABLE_ON_INIT, > >> > > +#endif > >> > > .enable_reg = AM33XX_CM_WKUP_DEBUGSS_CLKCTRL, > >> > > .enable_bit = AM33XX_MODULEMODE_SWCTRL, > >> > > .recalc = &followparent_recalc, > >> > > >> > Yes, I noticed this thread. But now a clock subsystem in the current > >> > kernel is switched to Common Clock Framework and debugss (and several > >> > another modules) is disabled > >> > >> Still this can be handled and enabled during init. > >> > >> > >> > (#if 0 .... #endif) in > >> > omap_hwmod_33xx_data.c. > >> > > >> > From omap_hwmod_33xx_data.c: > >> > > >> > /* > >> > * Modules omap_hwmod structures > >> > * > >> > * The following IPs are excluded for the moment because: > >> > * - They do not need an explicit SW control using omap_hwmod API. > >> > * - They still need to be validated with the driver > >> > * properly adapted to omap_hwmod / omap_device > >> > * > >> > * - cEFUSE (doesn't fall under any ocp_if) > >> > * - clkdiv32k > >> > * - debugss > >> > * - ocmc ram > >> > * - ocp watch point > >> > * - aes0 > >> > * - sha0 > >> > */ > >> > > >> > I uncommented the debugss entry in the omap_hwmod settings, but only > >> > got a warning like: > >> > > >> > CC arch/arm/mach-omap2/omap_hwmod_33xx_data.o > >> > arch/arm/mach-omap2/omap_hwmod_33xx_data.c:472:26: warning: > >> > 'am33xx_debugss_hwmod' defined but not used [-Wunused-variable] > >> > > >> > By the way, I need to use JTAG to trace a problem described in this thread: > >> > > >> > http://marc.info/?l=linux-omap&m=135307646415429&w=2 > >> > > >> > May be, it's the clocks related issue too... > >> > > >> > >> > >> I have quickly created patch for you, can you try below patch and let me > >> know? > >> > >> > >> > >> diff --git a/arch/arm/mach-omap2/cclock33xx_data.c b/arch/arm/mach-omap2/cclock33xx_data.c > >> index ea64ad6..c9af78c 100644 > >> --- a/arch/arm/mach-omap2/cclock33xx_data.c > >> +++ b/arch/arm/mach-omap2/cclock33xx_data.c > >> @@ -920,6 +920,7 @@ static const char *enable_init_clks[] = { > >> "l4hs_gclk", > >> "l4fw_gclk", > >> "l4ls_gclk", > >> + "debugss_ick", > >> }; > >> > >> int __init am33xx_clk_init(void) > >> diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c > >> index ad8d43b..750b897 100644 > >> --- a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c > >> +++ b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c > >> @@ -460,27 +460,6 @@ static struct omap_hwmod am33xx_clkdiv32k_hwmod = { > >> }, > >> }; > >> > >> -/* > >> - * 'debugss' class > >> - * debug sub system > >> - */ > >> -static struct omap_hwmod_class am33xx_debugss_hwmod_class = { > >> - .name = "debugss", > >> -}; > >> - > >> -static struct omap_hwmod am33xx_debugss_hwmod = { > >> - .name = "debugss", > >> - .class = &am33xx_debugss_hwmod_class, > >> - .clkdm_name = "l3_aon_clkdm", > >> - .main_clk = "debugss_ick", > >> - .prcm = { > >> - .omap4 = { > >> - .clkctrl_offs = AM33XX_CM_WKUP_DEBUGSS_CLKCTRL_OFFSET, > >> - .modulemode = MODULEMODE_SWCTRL, > >> - }, > >> - }, > >> -}; > >> - > >> /* ocmcram */ > >> static struct omap_hwmod_class am33xx_ocmcram_hwmod_class = { > >> .name = "ocmcram", > >> @@ -570,6 +549,28 @@ static struct omap_hwmod am33xx_sha0_hwmod = { > >> > >> #endif > >> > >> +/* > >> + * 'debugss' class > >> + * debug sub system > >> + */ > >> +static struct omap_hwmod_class am33xx_debugss_hwmod_class = { > >> + .name = "debugss", > >> +}; > >> + > >> +static struct omap_hwmod am33xx_debugss_hwmod = { > >> + .name = "debugss", > >> + .class = &am33xx_debugss_hwmod_class, > >> + .clkdm_name = "l3_aon_clkdm", > >> + .main_clk = "debugss_ick", > >> + .flags = (HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET), > >> + .prcm = { > >> + .omap4 = { > >> + .clkctrl_offs = AM33XX_CM_WKUP_DEBUGSS_CLKCTRL_OFFSET, > >> + .modulemode = MODULEMODE_SWCTRL, > >> + }, > >> + }, > >> +}; > >> + > >> /* 'smartreflex' class */ > >> static struct omap_hwmod_class am33xx_smartreflex_hwmod_class = { > >> .name = "smartreflex", > >> @@ -2261,6 +2262,24 @@ static struct omap_hwmod_ocp_if am33xx_l3_main__gfx = { > >> .user = OCP_USER_MPU | OCP_USER_SDMA, > >> }; > >> > >> +/* l3_main -> debugss */ > >> +static struct omap_hwmod_addr_space am33xx_debugss_addrs[] = { > >> + { > >> + .pa_start = 0x4b000000, > >> + .pa_end = 0x4b000000 + SZ_16M - 1, > >> + .flags = ADDR_TYPE_RT > >> + }, > >> + { } > >> +}; > >> + > >> +static struct omap_hwmod_ocp_if am33xx_l3_main__debugss = { > >> + .master = &am33xx_l3_main_hwmod, > >> + .slave = &am33xx_debugss_hwmod, > >> + .clk = "debugss_ick", > >> + .addr = am33xx_debugss_addrs, > >> + .user = OCP_USER_MPU, > >> +}; > >> + > >> /* l4 wkup -> smartreflex0 */ > >> static struct omap_hwmod_addr_space am33xx_smartreflex0_addrs[] = { > >> { > >> @@ -3315,6 +3334,7 @@ static struct omap_hwmod_ocp_if *am33xx_hwmod_ocp_ifs[] __initdata = { > >> &am33xx_pruss__l3_main, > >> &am33xx_wkup_m3__l4_wkup, > >> &am33xx_gfx__l3_main, > >> + &am33xx_l3_main__debugss, > >> &am33xx_l4_wkup__wkup_m3, > >> &am33xx_l4_wkup__control, > >> &am33xx_l4_wkup__smartreflex0, > >> > >> > > > > > > > > Missed to mention that, > > > > I have boot tested it on Bone platform and made sure that debugs module > > stays enabled after boot (after applying this patch). > > > > I applied your patch and it works for me too. JTAG interface is > working now. Thanks! > Thanks Igor, I will submit formal patch shortly, care to test and review/ack it. Thanks, Vaibhav -- 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
"Hiremath, Vaibhav" <hvaibhav@ti.com> writes: >> >>> +static struct omap_hwmod am33xx_debugss_hwmod = { >> >>> + .name = "debugss", >> >>> + .class = &am33xx_debugss_hwmod_class, >> >>> + .clkdm_name = "l3_aon_clkdm", >> >>> + .main_clk = "debugss_ick", >> >>> + .flags = (HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET), >> >> Setting these flags would still leave the problem where JTAG clocks >> are on when its not required no? In that case, what is the advantage >> of this patch? >> > > I missed to wrap it around #ifdef CONFIG_DEBUG_KERNEL. I will submit the > formal patch shortly. IMO, this should not be handled in the data at all (neither clock nor hwmod), and should be handled at runtime/boot-time, not compile time. The solution to this is to rather to have a small bit of code that requests the debugss clocks that are needed for JTAG debug, so the kernel knows they are in use. That code could then be enabled at boot time via command-line or DT option. Kevin -- 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 Mon, Dec 03, 2012 at 23:49:36, Kevin Hilman wrote: > "Hiremath, Vaibhav" <hvaibhav@ti.com> writes: > > >> >>> +static struct omap_hwmod am33xx_debugss_hwmod = { > >> >>> + .name = "debugss", > >> >>> + .class = &am33xx_debugss_hwmod_class, > >> >>> + .clkdm_name = "l3_aon_clkdm", > >> >>> + .main_clk = "debugss_ick", > >> >>> + .flags = (HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET), > >> > >> Setting these flags would still leave the problem where JTAG clocks > >> are on when its not required no? In that case, what is the advantage > >> of this patch? > >> > > > > I missed to wrap it around #ifdef CONFIG_DEBUG_KERNEL. I will submit the > > formal patch shortly. > > IMO, this should not be handled in the data at all (neither clock nor > hwmod), and should be handled at runtime/boot-time, not compile time. > Wouldn't that become another interface/control for debug? We already have various (standard) debug kernel parameters available. But I see your point, compile-time option will force users to rebuild kernel just in order to disable JTAG/Debug clock. > The solution to this is to rather to have a small bit of code that > requests the debugss clocks that are needed for JTAG debug, so the > kernel knows they are in use. > > That code could then be enabled at boot time via command-line or DT > option. > In case of command-line, something like below??? static int __init omap2_debug_clk_enable(char *str) { if (!str) return 0; if (!strcmp(str, "debug")) <enable debug clock> return 0; } early_param("debug", omap2_debug_clk_enable); In case of DT, one thought, It can be part of omap_generic_init() in board-generic.c file, We can parse there for debug node and required property to enable debug module. Any thought? Or Other options??? Thanks, Vaibhav -- 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 Mon, Dec 3, 2012 at 10:01 PM, Hiremath, Vaibhav <hvaibhav@ti.com> wrote: > > On Mon, Dec 03, 2012 at 23:49:36, Kevin Hilman wrote: > > "Hiremath, Vaibhav" <hvaibhav@ti.com> writes: > > > > >> >>> +static struct omap_hwmod am33xx_debugss_hwmod = { > > >> >>> + .name = "debugss", > > >> >>> + .class = &am33xx_debugss_hwmod_class, > > >> >>> + .clkdm_name = "l3_aon_clkdm", > > >> >>> + .main_clk = "debugss_ick", > > >> >>> + .flags = (HWMOD_INIT_NO_IDLE | > > >> >>> HWMOD_INIT_NO_RESET), > > >> > > >> Setting these flags would still leave the problem where JTAG clocks > > >> are on when its not required no? In that case, what is the advantage > > >> of this patch? > > >> > > > > > > I missed to wrap it around #ifdef CONFIG_DEBUG_KERNEL. I will submit > > > the > > > formal patch shortly. > > > > IMO, this should not be handled in the data at all (neither clock nor > > hwmod), and should be handled at runtime/boot-time, not compile time. > > > > Wouldn't that become another interface/control for debug? We already have > various (standard) debug kernel parameters available. > > But I see your point, compile-time option will force users to rebuild > kernel > just in order to disable JTAG/Debug clock. > > > The solution to this is to rather to have a small bit of code that > > requests the debugss clocks that are needed for JTAG debug, so the > > kernel knows they are in use. > > > > That code could then be enabled at boot time via command-line or DT > > option. > > > > In case of command-line, something like below??? > > static int __init omap2_debug_clk_enable(char *str) > { > if (!str) > return 0; > > if (!strcmp(str, "debug")) > <enable debug clock> > > return 0; > } > early_param("debug", omap2_debug_clk_enable); > This approach looks , I wrote similar code replacing "enable debug clock" with: jtag_clk = clk_get(NULL, "debugss_ick"); if(!IS_ERR_OR_NULL(jtag_clk)) clk_enable(jtag_clk); > > In case of DT, one thought, > > It can be part of omap_generic_init() in board-generic.c file, > We can parse there for debug node and required property to enable debug > module. > > Any thought? Or Other options??? Not sure, but can we append to bootargs from DT itself thus the above cmdline code can be used to enable debugss for both regular bootargs as well DT? Regards, Joel -- 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
"Hiremath, Vaibhav" <hvaibhav@ti.com> writes: > On Mon, Dec 03, 2012 at 23:49:36, Kevin Hilman wrote: >> "Hiremath, Vaibhav" <hvaibhav@ti.com> writes: >> >> >> >>> +static struct omap_hwmod am33xx_debugss_hwmod = { >> >> >>> + .name = "debugss", >> >> >>> + .class = &am33xx_debugss_hwmod_class, >> >> >>> + .clkdm_name = "l3_aon_clkdm", >> >> >>> + .main_clk = "debugss_ick", >> >> >>> + .flags = (HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET), >> >> >> >> Setting these flags would still leave the problem where JTAG clocks >> >> are on when its not required no? In that case, what is the advantage >> >> of this patch? >> >> >> > >> > I missed to wrap it around #ifdef CONFIG_DEBUG_KERNEL. I will submit the >> > formal patch shortly. >> >> IMO, this should not be handled in the data at all (neither clock nor >> hwmod), and should be handled at runtime/boot-time, not compile time. >> > > Wouldn't that become another interface/control for debug? We already have > various (standard) debug kernel parameters available. > > But I see your point, compile-time option will force users to rebuild kernel > just in order to disable JTAG/Debug clock. > >> The solution to this is to rather to have a small bit of code that >> requests the debugss clocks that are needed for JTAG debug, so the >> kernel knows they are in use. >> >> That code could then be enabled at boot time via command-line or DT >> option. >> > > In case of command-line, something like below??? > > static int __init omap2_debug_clk_enable(char *str) > { > if (!str) > return 0; > > if (!strcmp(str, "debug")) > <enable debug clock> > > return 0; > } > early_param("debug", omap2_debug_clk_enable); Yes, that's the idea I had in mind. Though you don't want to override "debug" here. The debug option is specifically about default log levels for the console and isn't really related to clocks. Kevin -- 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_33xx_data.c b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c index ad8d43b..858e180 100644 --- a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c +++ b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c @@ -586,7 +586,7 @@ static struct omap_hwmod am33xx_smartreflex0_hwmod = { .class = &am33xx_smartreflex_hwmod_class, .clkdm_name = "l4_wkup_clkdm", .mpu_irqs = am33xx_smartreflex0_irqs, - .main_clk = "smartreflex0_fck", + .main_clk = "smartreflex_mpu_fck", .prcm = { .omap4 = { .clkctrl_offs =
Hello, Beaglebone boot process is broken with the current git kernel. I use omap2plus_defconfig for tests. It looks like the boot process stops due to the last changes in the AM33xx clock sysbsystem. A following patch resolves this issue: AM33XX_CM_WKUP_SMARTREFLEX0_CLKCTRL_OFFSET, @@ -606,7 +606,7 @@ static struct omap_hwmod am33xx_smartreflex1_hwmod = { .class = &am33xx_smartreflex_hwmod_class, .clkdm_name = "l4_wkup_clkdm", .mpu_irqs = am33xx_smartreflex1_irqs, - .main_clk = "smartreflex1_fck", + .main_clk = "smartreflex_core_fck", .prcm = { .omap4 = { .clkctrl_offs = AM33XX_CM_WKUP_SMARTREFLEX1_CLKCTRL_OFFSET, Regards, Igor. -- 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