devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Elliot Berman <quic_eberman@quicinc.com>
To: Sudeep Holla <sudeep.holla@arm.com>
Cc: Bjorn Andersson <andersson@kernel.org>,
	Konrad Dybcio <konrad.dybcio@linaro.org>,
	Sebastian Reichel <sre@kernel.org>, Rob Herring <robh@kernel.org>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
	Conor Dooley <conor+dt@kernel.org>, Vinod Koul <vkoul@kernel.org>,
	Andy Yan <andy.yan@rock-chips.com>,
	Lorenzo Pieralisi <lpieralisi@kernel.org>,
	"Mark Rutland" <mark.rutland@arm.com>,
	Bartosz Golaszewski <bartosz.golaszewski@linaro.org>,
	Satya Durga Srinivasu Prabhala <quic_satyap@quicinc.com>,
	Melody Olvera <quic_molvera@quicinc.com>,
	Shivendra Pratap <quic_spratap@quicinc.com>,
	<devicetree@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
	<linux-arm-kernel@lists.infradead.org>,
	Florian Fainelli <florian.fainelli@broadcom.com>,
	<linux-pm@vger.kernel.org>, <linux-arm-msm@vger.kernel.org>
Subject: Re: [PATCH v5 3/4] firmware: psci: Read and use vendor reset types
Date: Wed, 19 Jun 2024 08:28:06 -0700	[thread overview]
Message-ID: <20240619080933071-0700.eberman@hu-eberman-lv.qualcomm.com> (raw)
In-Reply-To: <20240619135143.kr2tx4ynxayc5v3a@bogus>

On Wed, Jun 19, 2024 at 02:51:43PM +0100, Sudeep Holla wrote:
> On Mon, Jun 17, 2024 at 10:18:09AM -0700, Elliot Berman wrote:
> > SoC vendors have different types of resets and are controlled through
> > various registers. For instance, Qualcomm chipsets can reboot to a
> > "download mode" that allows a RAM dump to be collected. Another example
> > is they also support writing a cookie that can be read by bootloader
> > during next boot. PSCI offers a mechanism, SYSTEM_RESET2, for these
> > vendor reset types to be implemented without requiring drivers for every
> > register/cookie.
> > 
> > Add support in PSCI to statically map reboot mode commands from
> > userspace to a vendor reset and cookie value using the device tree.
> > 
> > A separate initcall is needed to parse the devicetree, instead of using
> > psci_dt_init because mm isn't sufficiently set up to allocate memory.
> > 
> > Reboot mode framework is close but doesn't quite fit with the
> > design and requirements for PSCI SYSTEM_RESET2. Some of these issues can
> > be solved but doesn't seem reasonable in sum:
> >  1. reboot mode registers against the reboot_notifier_list, which is too
> >     early to call SYSTEM_RESET2. PSCI would need to remember the reset
> >     type from the reboot-mode framework callback and use it
> >     psci_sys_reset.
> >  2. reboot mode assumes only one cookie/parameter is described in the
> >     device tree. SYSTEM_RESET2 uses 2: one for the type and one for
> >     cookie.
> >  3. psci cpuidle driver already registers a driver against the
> >     arm,psci-1.0 compatible. Refactoring would be needed to have both a
> >     cpuidle and reboot-mode driver.
> >
> 
> I need to think through it but when you first introduced the generic
> Documentation/devicetree/bindings/power/reset/reboot-mode.yaml bindings
> I also looked at drivers/power/reset/reboot-mode.c
> 
> I assumed this extension to that binding would reuse the same and
> PSCI would just do reboot_mode_register(). I didn't expect to see these
> changes. I might have missing something but since the bindings is still
> quite generic with additional cells that act as additional cookie for
> reboot call, I still think that should be possible.
> 
> What am I missing here then ?
> 

Right, if that was only thing to "solve" to make it easy to use
reboot-mode framework, I agree we should update reboot mode framework to
work with the additional cells. There are a few other issues I mention
above which, when combined, make me feel that PSCI is different enough
from how reboot mode framework works that we shouldn't try to make PSCI
work with the framework. Issues #1 and #2 are pretty easy to solve
(whether they should be solved is different); I'm not sure a good
approach to issue #3.

Thanks,
Elliot


  reply	other threads:[~2024-06-19 15:28 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-17 17:18 [PATCH v5 0/4] Implement vendor resets for PSCI SYSTEM_RESET2 Elliot Berman
2024-06-17 17:18 ` [PATCH v5 1/4] dt-bindings: power: reset: Convert mode-.* properties to array Elliot Berman
2024-06-27 20:10   ` Rob Herring (Arm)
2024-06-17 17:18 ` [PATCH v5 2/4] dt-bindings: arm: Document reboot mode magic Elliot Berman
2024-06-27 20:11   ` Rob Herring (Arm)
2024-06-17 17:18 ` [PATCH v5 3/4] firmware: psci: Read and use vendor reset types Elliot Berman
2024-06-19 13:51   ` Sudeep Holla
2024-06-19 15:28     ` Elliot Berman [this message]
2024-06-20 23:37       ` Elliot Berman
2024-06-24 15:41         ` Sudeep Holla
2024-07-02 23:06           ` Elliot Berman
2024-07-02 23:42             ` Trilok Soni
2024-07-09  3:50               ` Trilok Soni
2024-07-09 11:19                 ` Sudeep Holla
2024-08-06 14:38                   ` Shivendra Pratap
2024-06-24 15:56   ` Sudeep Holla
2024-08-07 15:02   ` Lorenzo Pieralisi
2024-08-07 18:10     ` Elliot Berman
2024-08-09 13:30       ` Lorenzo Pieralisi
2024-08-09 16:58         ` Elliot Berman
2024-08-12 18:16           ` Shivendra Pratap
2024-08-15 14:40             ` Lorenzo Pieralisi
2024-08-15 18:05               ` Elliot Berman
2024-08-16 18:21                 ` Shivendra Pratap
2024-10-15 12:26                 ` Lorenzo Pieralisi
2024-06-17 17:18 ` [PATCH v5 4/4] arm64: dts: qcom: Add PSCI SYSTEM_RESET2 types for qcm6490-idp Elliot Berman
2024-06-18 14:23   ` Konrad Dybcio

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20240619080933071-0700.eberman@hu-eberman-lv.qualcomm.com \
    --to=quic_eberman@quicinc.com \
    --cc=andersson@kernel.org \
    --cc=andy.yan@rock-chips.com \
    --cc=bartosz.golaszewski@linaro.org \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=florian.fainelli@broadcom.com \
    --cc=konrad.dybcio@linaro.org \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=lpieralisi@kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=quic_molvera@quicinc.com \
    --cc=quic_satyap@quicinc.com \
    --cc=quic_spratap@quicinc.com \
    --cc=robh@kernel.org \
    --cc=sre@kernel.org \
    --cc=sudeep.holla@arm.com \
    --cc=vkoul@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).