[GIT PULL] Qualcomm driver updates for v6.3

[Trilok Soni]

On 3/13/2023 9:55 AM, Trilok Soni wrote:
> 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 :) ).


Bjorn and Arnd can you please check and provide feedback? I really want 
this driver to get merged or open issues resolved.

---Trilok Soni