Re: Crash in msm serial on dragonboard with ftrace bootargs

Sai Prakash Ranjan
2018-11-15T10:33:29Z

On 11/13/2018 3:14 PM, Srinivas Kandagatla wrote:
> Hi Sai,
>
>
>
> On 25/10/18 15:36, saiprakash.ranjan@codeaurora.org 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?

Thanks,
Sai

--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation