Re: [PATCH V2 2/3] soc: qcom: boot_stat: Add Driver Support for Boot Stats

From: Souradeep Chowdhury
Date: Wed Apr 12 2023 - 10:22:27 EST




On 4/12/2023 1:47 PM, Krzysztof Kozlowski wrote:
On 10/04/2023 08:48, Souradeep Chowdhury wrote:


On 4/7/2023 9:11 PM, Bjorn Andersson wrote:
On Fri, Apr 07, 2023 at 07:34:36PM +0530, Souradeep Chowdhury wrote:
All of Qualcomm's proprietary Android boot-loaders capture boot time
stats, like the time when the bootloader started execution and at what
point the bootloader handed over control to the kernel etc. in the IMEM
region. This information is captured in a specific format by this driver
by mapping a structure to the IMEM memory region and then accessing the
members of the structure to print the information. This information is
useful in verifying if the existing boot KPIs have regressed or not.
A sample log in SM8450(waipio) device is as follows:-

KPI: Pre ABL Time = 3s
KPI: ABL Time = 14s

Why are these in whole seconds?

This is to give a granular view of time.


KPI: Kernel MPM timestamp = 890206

And why is this presented in cycles?

This timestamp is used as an intermediate value for calculating one of
the KPIs. Can be changed to seconds as well for consistency.



The Module Power Manager(MPM) sleep counter starts ticking at the PBL
stage and the timestamp generated by the sleep counter is logged by
the Qualcomm proprietary bootloader(ABL) at two points-> First when it
starts execution which is logged here as "Pre ABL Time" and the second
when it is about to load the kernel logged as "ABL Time". Both are
logged in the unit of seconds.

We have a policy to not taint the kernel log with "useless" information,
for kernel developers this seems to add no value and for end users
there's no benefit to this.

The current kernel timestamp is
printed by the boot_stats driver as well.


Why?

Same as stated above.

You did not answer. The question is "why do you think printing this
during boot is suitable for wide usage?". I don't find answer "give a
granular view of time" anyway related.

Please come with rationale why such printing should be used in Linux
kernel at all, given that as Bjorn said - we do not print
debugging/profiling information.

You should probably come with a debugfs interface for this.

Ack. The debugfs interface for this will be present in the next version.


Best regards,
Krzysztof