[GIT PULL] Qualcomm driver updates for v6.3

[Trilok Soni]

On 2/27/2023 4:43 AM, Souradeep Chowdhury wrote:
> 
> 
> On 2/22/2023 5:43 PM, Leo Yan wrote:
>> Hi Souradeep,
>>
>> On Wed, Feb 22, 2023 at 04:46:07PM +0530, Souradeep Chowdhury wrote:
>>> On 2/22/2023 7:13 AM, Leo Yan wrote:
>>>> On Wed, Feb 15, 2023 at 04:05:36PM +0100, Arnd Bergmann wrote:
>>
>> [...]
>>
>>>>> If the possible use is purely for saving some state across
>>>>> a reboot, as opposed to other events, I wonder if there is
>>>>> a good way to integrate it into the fs/pstore/ code, which
>>>>> already has a way to multiplex various kinds of input (log
>>>>> buffer, ftrace call chain, userspace strings, ...) into
>>>>> various kinds of persistent buffers (sram, blockdev, mtd,
>>>>> efivars, ...) with the purpose of helping analyze the
>>>>> state after a reboot.
>>>>
>>>> Good point!
>>>>
>>>> I understand pstore/ramoops is somehow like a sink which routes the
>>>> tracing data (software tracing data but not hadware tracing data) to
>>>> persistent memory.  This is why we also can route these software
>>>> tracing data to STM (hardware sink!).
>>>>
>>>> Seems to me, Arnd suggests to connect two sinks between DCC and
>>>> pstore (to persistent memory).  But I cannot give an example code in
>>>> kernel for doing this way, sorry if I miss something.
>>>>
>>>> Essentially, a good user case is to keep a persistent memory for the
>>>> tracing data, then after rebooting cycle we can retrieve the tracing
>>>> data via user space interface (like sysfs node).
>>>
>>> Hi Leo/Arnd,
>>>
>>> Just wanted to let you know that the justification of not using 
>>> PStore was
>>> already given in the version 1 of this patch series as below
>>>
>>> https://lore.kernel.org/linux-arm-msm/ab30490c016f906fd9bc5d789198530b@codeaurora.org/#r
>>>
>>> PStore/Ramoops only persists across warm-reboots which is present for 
>>> chrome
>>> devices but not for android ones.
>>
>> Thanks for the info.  Just remind a subtle difference of reboots.
>>
>> Besides warm reboot, kernel can reboot system after panic (see kernel
>> command line option `panic`) and watchdog can reboot the system as well.
>>
>> Even though Android doesn't support warm reboot, system still can reboot
>> on panic or by watchdog (in particular after bus lockup), pstore/ramoops
>> also can support these cases.
> 
> 
> So for the SoCs that doesn't support warm reboots, the DDR memory is non
> persistent across panics or watchdog bites in which case the 
> PStore/Ramoops cannot be of use.
> 
> 
>>
>>> Also the dcc_sram contents can
>>> also be collected by going for a software trigger after loading the 
>>> kernel
>>> and the dcc_sram is parsed to get the register values with the
>>> opensource parser as below
>>>
>>> https://source.codeaurora.org/quic/la/platform/vendor/qcom-opensource/tools/tree/dcc_parser
>>
>> To be clear, current driver is fine for me (TBH, I didn't spend much
>> time to read it but it's very neat after quickly went through it), I
>> just share some info in case it's helpful for the discussion.


What is the conclusion here? Can we pick up the DCC now if we rebase to 
the latest tree? It seems so far response here is that driver is fine 
as-is and it can be included without any changes. I want this driver 
discussion to be concluded since we are trying to submit it for more 
than 23 months (as Bjorn counted :) ).

---Trilok Soni