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@xxxxxxxxx> wrote:
> > On Thu, Nov 22, 2012 at 6:49 PM, Hiremath, Vaibhav <hvaibhav@xxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
