Message-ID: <30aba45d0e657fd77adba119e5fad345@codeaurora.org>
Date:   Mon, 16 Aug 2021 16:08:52 +0530
From:   Sai Prakash Ranjan <saiprakash.ranjan@...eaurora.org>
To:     Stephen Boyd <swboyd@...omium.org>,
        Trilok Soni <quic_tsoni@...cinc.com>, quic_eberman@...cinc.com
Cc:     Andy Gross <agross@...nel.org>,
        Bjorn Andersson <bjorn.andersson@...aro.org>,
        Rob Herring <robh+dt@...nel.org>, devicetree@...r.kernel.org,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
        linux-arm-msm@...r.kernel.org,
        Rajendra Nayak <rnayak@...eaurora.org>,
        Sibi Sankar <sibis@...eaurora.org>
Subject: Re: [PATCH 0/3] soc: qcom: Add download mode support for QTI
 platforms

On 2021-08-13 05:46, Stephen Boyd wrote:
> Quoting Sai Prakash Ranjan (2021-08-12 02:17:39)
>> Collecting ramdumps on QTI platforms mainly require two things,
>> SDI (System Debug Image) enabled firmware and kernel support to
>> configure download mode cookies and SDI settings. Ramdumps can
>> be collected once the system enters the download mode. To enter
>> download mode, magic values or cookies need to be set in IMEM
>> which is used by firmware to decide to enter download mode or not.
>> Download mode cookies remain the same across targets and SDI disable
>> register needs to be set or SDI needs to be disabled in case of normal
>> reboot since ramdumps are supposed to be for crash debugging and
>> not for every reboot. This series adds the kernel support required
>> to enter download mode.
> 
> I don't recall if we discussed this on the list, but I'd really prefer
> that we don't make kernel changes to support this beyond implementing
> PSCI SYSTEM_RESET2 support and then some sort of vendor specific (or if
> ARM is willing to update the spec then ARM specific) reset command on
> panic reboot paths. The idea is to set the cookie in the bootloader
> before the kernel is booted, then any insta-reboots/watchdogs would go
> into download mode, no special init code required to lay down the 
> cookie
> or clear it on normal reboot. The normal reboot PSCI call would clear
> the cookie in the firmware, in case something goes wrong after the
> kernel hands off control to PSCI, and then panics that want to go into
> download mode would make the SYSTEM_RESET2 reboot call into PSCI that
> sets the cookie.
> 
> Maybe it could be a linux specific psci number or maybe we could
> configure the reboot call in the psci node to be this specific number 
> so
> that it can be different based on the firmware implementation if
> consolidating around a single number doesn't work. Either way, that all
> seems manageable and we can keep these cookie details out of the kernel
> and the reboot/panic paths.
> 

Alright, I think we can probably make it work without much/any changes
in kernel. So following what you said, we can just implement
PSCI_SYSTEM_RESET2 in firmware to enter the download mode having cookies
already set by default and the cookie is cleared when we have a normal
reboot via PSCI_SYSTEM_RESET. For panic reboot, we already have a 
cmdline
*reboot=panic_warm* to identify panic reboots and can call into
PSCI_SYSTEM_RESET2. I have just tested and it works fine if we have
psci_system_reset2_supported as true.

@Trilok/@...iot, you can check if above works for your usecases in 
android
as well and it doesn't need any of your additional changes to kernel.

Thanks,
Sai

>> 
>> Currently this series doesn't add support for android targets where
>> a couple of SCM calls are required to set/unset the download mode
>> cookies and SDI configuration but can be easily added gradually to
>> the same driver, so as of now only chrome platforms are supported
>> and tested.
>> 
>> Sai Prakash Ranjan (3):
>>   soc: qcom: Add download mode support
>>   dt-bindings: msm: Add QTI download mode support binding
>>   arm64: dts: qcom: sc7180: Add IMEM, pil info and download mode 
>> region
>> 
>>  .../bindings/arm/msm/qcom,dload-mode.yaml     |  53 ++++++
>>  MAINTAINERS                                   |   7 +
>>  arch/arm64/boot/dts/qcom/sc7180.dtsi          |  21 +++
>>  drivers/soc/qcom/Kconfig                      |  10 ++
>>  drivers/soc/qcom/Makefile                     |   1 +
>>  drivers/soc/qcom/download_mode.c              | 152 
>> ++++++++++++++++++
>>  6 files changed, 244 insertions(+)
>>  create mode 100644 
>> Documentation/devicetree/bindings/arm/msm/qcom,dload-mode.yaml
>>  create mode 100644 drivers/soc/qcom/download_mode.c
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@...ts.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

Powered by blists - more mailing lists