[PATCH v7 21/21] OMAP2+: UART: Do not gate uart clocks if used for debug_prints

Mohammed, Afzal afzal at ti.com
Wed Oct 19 10:20:06 EDT 2011


Hi Govindraj,

On Wed, Oct 19, 2011 at 18:22:58, Govindraj wrote:
> On Wed, Oct 19, 2011 at 11:05 AM, Mohammed, Afzal <afzal at ti.com> wrote:
> > Hi Govindraj,
> >
> > On Tue, Oct 18, 2011 at 21:05:41, R, Govindraj wrote:
> >> If OMAP UART is used as console uart and debug is enabled,
> >> avoid gating of uart clocks to print all debug prints.
> > :
> > :
> >>                       console_uart_id = uart->num;
> >>
> >> +                     if (cmdline_find_option("debug")) {
> >> +                             uart_debug = true;
> >
> > Shouldn't "loglevel" also be checked?
> >
> 
> Might not be necessary,
> 
> loglevel only sets the option in console driver how a printk should be handled
> from vprintk so any printk should be to sent to console or to syslogd action
> where it will be buffered to a file(var/log/messages).
> 
> Any print's with any log level should be handled and printed to console.
> 
> consider below path below path
> 
> uart->ops
>  -> runtime_get_sync
>       -> omap_device_enable
>           -> clock_enable
> 
> All the prints in given path are dev_dbgs for which we need debug to be set from
> command line argument.
> 
> As stated in change log any dev_dbg prints from these path can be
> redirect to uart->ops
> so even before our clock was enabled we got redirected back to uart code.
> 
> So for dev_dbg prints from above path we need debug to be set from command-line
> and we can prevent uart clock gating to this scenario.

Isn't passing bootargs "loglevel=10" same as "debug"? (init/main.c)

Regards
Afzal



More information about the linux-arm-kernel mailing list