Re: Crash in msm serial on dragonboard with ftrace bootargs

[Srinivas Kandagatla]

On 15/11/18 10:33, Sai Prakash Ranjan wrote:
> On 11/13/2018 3:14 PM, Srinivas Kandagatla wrote:
> > Hi Sai,
> >
> >
> >
> > On 25/10/18 15:36, saiprakash.ranjan@xxxxxxxxxxxxxx wrote:
> > > "If I disable dma node and LS-UART0, then I don't see any crash and
> > > ftrace also works fine"
> > >
> > > And one more observation is that even without ftrace cmdline, if I use
> > > earlycon and disable dma, I face the same crash.
> > >
> > > So basically this seems to be some kind of earlycon and dma issue and
> > > not ftrace(I can be wrong).
> > >
> > > So adding Srinivas for more info on this dma node.
> >
> > Its Interesting that my old email conversations with SBoyd show that I 
> > have investigated this issue in early 2016!
> >
> > My analysis so far:
> >
> > This reason for such behavior is due the common iface clock
> > (GCC_BLSP1_AHB_CLK) across multiple drivers(serial ports, bam dma
> > and other low speed devices).
> > The code flow in DB410C is bit different, as the uart0 is first
> > attempted to set as console and then uart1, this ordering triggers
> > pm state change uart_change_pm(state, UART_PM_STATE_OFF) from serial
> > core while setting up uart0, this would go and disable all the
> > clocks for uart0.
> > As uart1 is not setup Yet, and earlycon is still active, any
> > attempts by earlycon to write to registers would trigger a system
> > reboot as the clock was just disabled by uart0 change_pm code.
> >
> > This can even be triggered with any drivers like spi which uses same
> > clock I guess.
> >
> > Hope it helps,
> >
> > Either earlycon needs to reference the clocks or those clocks needs to
> > be marked always-on (but only with earlycon).
> >
> > > Also just for a note: apq8096-db820c.dtsi shows UART0 is disabled 
> > > because
> > > bootloader does not allow access to it. Could this also be the case 
> > > for db410c?
> > No, this is not the case with DB410c. DB820c has added restrictions in 
> > TZ, I think new booloaders should have solved this issue.
>
> Hi Srinivas,
>
> Thanks a lot for pointing out the cause of crash.
> I just tried setting GCC_BLSP1_AHB_CLK with flag CLK_IS_CRITICAL and the
> crash disappears.
>
> But I suppose setting CLK_IS_CRITICAL is not the solution?

Yes, this is not the solution, but it proves that the hand-off between 
booloaders and kernel is the issue.

In general there is wider issue with resources hand-off between 
bootloader and kernel.

There has been some proposal in the past by Viresh for a new framework 
called boot-constriants (https://lkml.org/lkml/2017/12/14/440) which am 
not sure if its still actively looked at. But something similar should 
be the way to address such issues.

--srini




> Thanks,
> Sai