From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id CA62FC4338F for ; Mon, 16 Aug 2021 10:39:34 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id AEF2061BC1 for ; Mon, 16 Aug 2021 10:39:34 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235701AbhHPKkF (ORCPT ); Mon, 16 Aug 2021 06:40:05 -0400 Received: from so254-9.mailgun.net ([198.61.254.9]:62912 "EHLO so254-9.mailgun.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233207AbhHPKkE (ORCPT ); Mon, 16 Aug 2021 06:40:04 -0400 DKIM-Signature: a=rsa-sha256; v=1; c=relaxed/relaxed; d=mg.codeaurora.org; q=dns/txt; s=smtp; t=1629110373; h=Message-ID: References: In-Reply-To: Subject: Cc: To: From: Date: Content-Transfer-Encoding: Content-Type: MIME-Version: Sender; bh=7FQMN00bWUtkew/aYXgY67FhLuXjMYkzri60rq8/V1I=; b=ivqIeJHMtvbH1kAevmFVT8qcRjK5UzPMJwHUzxMdeqN1Mx583aJ9jtQBL6wNeUGIfTAxODtH ErY7dSuCJNJhUst6W1hnjxmvFbbZKYcm6wWtXYdlujuUGEuxQTo980tjFSqtihWlZx7cgh6Q dM0tSkUSwNIy8daST1iGqtwfJBc= X-Mailgun-Sending-Ip: 198.61.254.9 X-Mailgun-Sid: WyI1YmJiNiIsICJkZXZpY2V0cmVlQHZnZXIua2VybmVsLm9yZyIsICJiZTllNGEiXQ== Received: from smtp.codeaurora.org (ec2-35-166-182-171.us-west-2.compute.amazonaws.com [35.166.182.171]) by smtp-out-n05.prod.us-west-2.postgun.com with SMTP id 611a403e454b7a558fc1c90b (version=TLS1.2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256); Mon, 16 Aug 2021 10:38:54 GMT Sender: saiprakash.ranjan=codeaurora.org@mg.codeaurora.org Received: by smtp.codeaurora.org (Postfix, from userid 1001) id 8B089C4360C; Mon, 16 Aug 2021 10:38:54 +0000 (UTC) Received: from mail.codeaurora.org (localhost.localdomain [127.0.0.1]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: saiprakash.ranjan) by smtp.codeaurora.org (Postfix) with ESMTPSA id C8AF0C4338F; Mon, 16 Aug 2021 10:38:52 +0000 (UTC) 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 To: Stephen Boyd , Trilok Soni , quic_eberman@quicinc.com Cc: Andy Gross , Bjorn Andersson , Rob Herring , devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org, Rajendra Nayak , Sibi Sankar Subject: Re: [PATCH 0/3] soc: qcom: Add download mode support for QTI platforms In-Reply-To: References: Message-ID: <30aba45d0e657fd77adba119e5fad345@codeaurora.org> X-Sender: saiprakash.ranjan@codeaurora.org User-Agent: Roundcube Webmail/1.3.9 Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org 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