Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Sender: saiprakash.ranjan=codeaurora.org@mg.codeaurora.org
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII;
 format=flowed
Content-Transfer-Encoding: 7bit
Date:   Mon, 16 Aug 2021 16:08:52 +0530
From:   Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>
To:     Stephen Boyd <swboyd@chromium.org>,
        Trilok Soni <quic_tsoni@quicinc.com>, quic_eberman@quicinc.com
Cc:     Andy Gross <agross@kernel.org>,
        Bjorn Andersson <bjorn.andersson@linaro.org>,
        Rob Herring <robh+dt@kernel.org>, devicetree@vger.kernel.org,
        linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org,
        linux-arm-msm@vger.kernel.org,
        Rajendra Nayak <rnayak@codeaurora.org>,
        Sibi Sankar <sibis@codeaurora.org>
Subject: Re: [PATCH 0/3] soc: qcom: Add download mode support for QTI
 platforms
In-Reply-To: <CAE-0n52PzadMxB_4h2DGJGLO++Bu_PCSsxS8NHe+cuhv=Mw0sA@mail.gmail.com>
References: <cover.1628757036.git.saiprakash.ranjan@codeaurora.org>
 <CAE-0n52PzadMxB_4h2DGJGLO++Bu_PCSsxS8NHe+cuhv=Mw0sA@mail.gmail.com>
Message-ID: <30aba45d0e657fd77adba119e5fad345@codeaurora.org>
User-Agent: Roundcube Webmail/1.3.9
Precedence: bulk

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/@Elliot, 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@lists.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