"Hiremath, Vaibhav" <hvaib...@ti.com> writes:

> On Mon, Dec 03, 2012 at 23:49:36, Kevin Hilman wrote:
>> "Hiremath, Vaibhav" <hvaib...@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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to