From: Johan Hovold <johan@kernel.org>
To: Rob Clark <robdclark@gmail.com>
Cc: Rob Herring <robh@kernel.org>,
Johan Hovold <johan+linaro@kernel.org>,
Alexandre Belloni <alexandre.belloni@bootlin.com>,
Bjorn Andersson <andersson@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>,
Konrad Dybcio <konradybcio@kernel.org>,
Jonathan Marek <jonathan@marek.ca>,
linux-arm-msm@vger.kernel.org, linux-rtc@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
Rob Clark <robdclark@chromium.org>
Subject: Re: [PATCH 0/7] arm64: dts: qcom: x1e80100: enable rtc
Date: Tue, 22 Apr 2025 15:39:46 +0200 [thread overview]
Message-ID: <aAecIkgmTTlThKEZ@hovoldconsulting.com> (raw)
In-Reply-To: <CAF6AEGsfke=x0p1b2-uNX6DuQfRyEjVbJaxTbVLDT2YvSkGJbg@mail.gmail.com>
On Mon, Apr 21, 2025 at 07:36:28AM -0700, Rob Clark wrote:
> On Sun, Jan 26, 2025 at 4:20 PM Rob Herring <robh@kernel.org> wrote:
> > On Mon, Jan 20, 2025 at 03:41:45PM +0100, Johan Hovold wrote:
> > > This series adds support for utilising the UEFI firmware RTC offset to
> > > the Qualcomm PMIC RTC driver and uses that to enable the RTC on all X
> > > Elite machines.
> > > Rob had some concerns about adding a DT property for indicating that a
> > > machine uses UEFI for storing the offset and suggested that the driver
> > > should probe for this instead. Unfortunately, this is easier said than
> > > done given that UEFI variable support itself is probed for and may not
> > > be available until after the RTC driver probes.
> >
> > This information would be useful in the binding commit...
> >
> > Seems like something I would say, but this is v1 and I have no memory of
> > discussing this. I would also say probe ordering is not a DT problem,
> > but sounds like an OS problem. Aren't there other things needing EFI
> > variables earlyish too? Do you really want to have to update the DT to
> > enable this?
>
> I was debugging why RTC offset was not working properly for me, and
> eventually realized it was exactly this problem (efivars not avail
> when rtc probes).
Hmm. It seems dropping that property for v2 under the assumption that
efivars would be available at module init time (since the driver can
only be built-in) was a mistake.
I see now that the current qcom efivars driver does not probe until
module init time itself, but even if we change that the scm driver
depends on an interconnect driver which can be built as a module...
> Hacking up rtc-pm8xxx to return -EPROBE_DEFER "fixes" it
> > OTOH, it's one property, meh.
I guess we need that property on these platforms as I had initially
concluded after all. As with the rest of this driver, hopefully all of
this goes away for future Qualcomm platforms once they fix their UEFI
implementation so that the time service can be used directly.
Johan
prev parent reply other threads:[~2025-04-22 13:39 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-20 14:41 [PATCH 0/7] arm64: dts: qcom: x1e80100: enable rtc Johan Hovold
2025-01-20 14:41 ` [PATCH 1/7] dt-bindings: rtc: qcom-pm8xxx: add uefi-variable offset Johan Hovold
2025-01-20 14:41 ` [PATCH 2/7] dt-bindings: rtc: qcom-pm8xxx: document qcom,no-alarm flag Johan Hovold
2025-01-27 18:00 ` Rob Herring (Arm)
2025-01-20 14:41 ` [PATCH 3/7] rtc: pm8xxx: add support for uefi offset Johan Hovold
2025-01-20 15:10 ` Sudeep Holla
2025-01-20 15:15 ` Johan Hovold
2025-01-20 15:17 ` Johan Hovold
2025-01-20 17:13 ` Sudeep Holla
2025-01-24 12:56 ` Tobias Heider
2025-01-24 14:07 ` Johan Hovold
2025-01-20 14:41 ` [PATCH 4/7] rtc: pm8xxx: mitigate flash wear Johan Hovold
2025-01-23 11:39 ` Johan Hovold
2025-01-20 14:41 ` [PATCH 5/7] rtc: pm8xxx: implement qcom,no-alarm flag for non-HLOS owned alarm Johan Hovold
2025-01-20 14:41 ` [PATCH 6/7] arm64: dts: qcom: sc8280xp-x13s: switch to uefi rtc offset Johan Hovold
2025-01-20 18:08 ` Jens Glathe
2025-01-23 12:26 ` Konrad Dybcio
2025-01-20 14:41 ` [PATCH 7/7] arm64: dts: qcom: x1e80100: enable rtc Johan Hovold
2025-01-20 18:12 ` Jens Glathe
2025-01-21 10:06 ` Johan Hovold
2025-01-23 12:26 ` Konrad Dybcio
2025-01-20 21:19 ` [PATCH 0/7] " Steev Klimaszewski
2025-01-21 10:06 ` Johan Hovold
2025-01-21 3:48 ` Joel Stanley
2025-01-21 10:07 ` Johan Hovold
2025-01-23 12:28 ` Konrad Dybcio
2025-01-25 18:46 ` Sebastian Reichel
2025-01-27 0:20 ` Rob Herring
2025-02-19 13:37 ` Johan Hovold
2025-04-21 14:36 ` Rob Clark
2025-04-22 13:39 ` Johan Hovold [this message]
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=aAecIkgmTTlThKEZ@hovoldconsulting.com \
--to=johan@kernel.org \
--cc=alexandre.belloni@bootlin.com \
--cc=andersson@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=johan+linaro@kernel.org \
--cc=jonathan@marek.ca \
--cc=konradybcio@kernel.org \
--cc=krzk+dt@kernel.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rtc@vger.kernel.org \
--cc=robdclark@chromium.org \
--cc=robdclark@gmail.com \
--cc=robh@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).