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