devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Johan Hovold <johan+linaro@kernel.org>
To: Alexandre Belloni <alexandre.belloni@bootlin.com>,
	Bjorn Andersson <andersson@kernel.org>
Cc: Rob Herring <robh@kernel.org>,
	Krzysztof Kozlowski <krzk+dt@kernel.org>,
	Conor Dooley <conor+dt@kernel.org>,
	Konrad Dybcio <konradybcio@kernel.org>,
	Jonathan Marek <jonathan@marek.ca>,
	Ard Biesheuvel <ardb@kernel.org>,
	Maximilian Luz <luzmaximilian@gmail.com>,
	Jens Glathe <jens.glathe@oldschoolsolutions.biz>,
	Joel Stanley <joel@jms.id.au>, Sebastian Reichel <sre@kernel.org>,
	Steev Klimaszewski <steev@kali.org>,
	linux-arm-msm@vger.kernel.org, linux-rtc@vger.kernel.org,
	devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
	Johan Hovold <johan+linaro@kernel.org>
Subject: [PATCH v2 0/6] arm64: dts: qcom: x1e80100: enable rtc
Date: Wed, 19 Feb 2025 14:41:12 +0100	[thread overview]
Message-ID: <20250219134118.31017-1-johan+linaro@kernel.org> (raw)

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.

Included is also a patch to switch the Lenovo ThinkPad X13s over to
using the UEFI offset.

The RTCs in many Qualcomm devices are effectively broken due to the time
registers being read-only. Instead some other non-volatile memory can be
used to store an offset which a driver can take into account. On Windows
on Arm laptops, the UEFI firmware (and Windows) use a UEFI variable for
storing such an offset.

When RTC support for the X13s was added two years ago we did not yet
have UEFI variable support for these machines in mainline and there were
also some concerns regarding flash wear. [1] As not all Qualcomm
platforms have UEFI firmware anyway, we instead opted to use a PMIC
scratch register for storing the offset. [2]

On the UEFI machines in question this is however arguably not correct
as it means that the RTC time can differ between the UEFI firmware (and
Windows) and Linux.

Now that the (reverse engineered) UEFI variable implementation has been
merged and thoroughly tested, let's switch to using that to store the
RTC offset also on Linux. The flash wear concerns can be mitigated by
deferring writes due to clock drift until shutdown.

Note that this also avoids having to wait for months for Qualcomm to
provide a free PMIC SDAM scratch register for X1E and future platforms,
and specifically allows us to enable the RTC on X1E laptops today.

The first version of this series (and the RFC) used a DT property to
determine whether the UEFI firmware uses a variable for storing the RTC
offset. This is strictly only needed if we ever are to allow (further)
modular efivars implementations as otherwise a driver can just check if
the variable is there during probe (and assume efivars are available at
module init time).

The Qualcomm efivars implementation (qcom_qseecom_uefisecapp) cannot be
built as a module currently to avoid similar problems with user space
expecting efivarfs to be available during early boot. As changing this
now would cause a regression, let's assume at least the Qualcomm
implementation will remain built-in indefinitely.

Hopefully this all goes away (for future platforms) once Qualcomm fix
their UEFI implementation so that the UEFI time (and variable) services
can be used directly.

Johan


Changes in v2
 - drop DT property in favour of probing for the UEFI variable (Rob)
 - rebase on 6.14-rc1; use bool constant for device_init_wakeup()
 - fix flash wear commit message (X13s typo, example)

Changes since UEFI offset RFC [1]:
 - clarify that UEFI variable format is not arbitrary (Alexandre)
 - add missing use_uefi kernel doc
 - use dev_dbg() instead of dev_err() (Alexandre)
 - rename epoch define RTC_TIMESTAMP_EPOCH_GPS (Alexandre)
 - mitigate flash wear by deferring writes due to clock drift until
   shutdown

Changes since Jonathan's X1E series v3 [3]:
 - tweak qcom,no-alarm binding update (and drop Krystzof's Reviewed-by tag)
 - drop no-alarm flag and restructure probe() to clear feature flag before
   registering RTC
 - use UEFI variable offset on X1E

[1] https://lore.kernel.org/lkml/20230126142057.25715-1-johan+linaro@kernel.org/
[2] https://lore.kernel.org/lkml/20230202155448.6715-1-johan+linaro@kernel.org/
[3] https://lore.kernel.org/lkml/20241015004945.3676-1-jonathan@marek.ca/


Johan Hovold (4):
  rtc: pm8xxx: add support for uefi offset
  rtc: pm8xxx: mitigate flash wear
  arm64: dts: qcom: sc8280xp-x13s: switch to uefi rtc offset
  arm64: dts: qcom: x1e80100: enable rtc

Jonathan Marek (2):
  dt-bindings: rtc: qcom-pm8xxx: document qcom,no-alarm flag
  rtc: pm8xxx: implement qcom,no-alarm flag for non-HLOS owned alarm

 .../bindings/rtc/qcom-pm8xxx-rtc.yaml         |   5 +
 .../qcom/sc8280xp-lenovo-thinkpad-x13s.dts    |  11 -
 arch/arm64/boot/dts/qcom/x1e80100-pmics.dtsi  |   3 +-
 drivers/rtc/rtc-pm8xxx.c                      | 225 ++++++++++++++----
 include/linux/rtc.h                           |   1 +
 5 files changed, 189 insertions(+), 56 deletions(-)

-- 
2.45.3


             reply	other threads:[~2025-02-19 13:43 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-02-19 13:41 Johan Hovold [this message]
2025-02-19 13:41 ` [PATCH v2 1/6] dt-bindings: rtc: qcom-pm8xxx: document qcom,no-alarm flag Johan Hovold
2025-02-19 13:41 ` [PATCH v2 2/6] rtc: pm8xxx: add support for uefi offset Johan Hovold
2025-02-19 13:41 ` [PATCH v2 3/6] rtc: pm8xxx: mitigate flash wear Johan Hovold
2025-02-19 13:41 ` [PATCH v2 4/6] rtc: pm8xxx: implement qcom,no-alarm flag for non-HLOS owned alarm Johan Hovold
2025-02-19 13:41 ` [PATCH v2 5/6] arm64: dts: qcom: sc8280xp-x13s: switch to uefi rtc offset Johan Hovold
2025-02-19 13:41 ` [PATCH v2 6/6] arm64: dts: qcom: x1e80100: enable rtc Johan Hovold
2025-03-10 12:27 ` [PATCH v2 0/6] " Johan Hovold
2025-03-17 11:06   ` Alexandre Belloni
2025-03-17 11:52     ` Johan Hovold
2025-03-17 11:05 ` (subset) " Alexandre Belloni
2025-03-17 14:51 ` Bjorn Andersson

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=20250219134118.31017-1-johan+linaro@kernel.org \
    --to=johan+linaro@kernel.org \
    --cc=alexandre.belloni@bootlin.com \
    --cc=andersson@kernel.org \
    --cc=ardb@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=jens.glathe@oldschoolsolutions.biz \
    --cc=joel@jms.id.au \
    --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=luzmaximilian@gmail.com \
    --cc=robh@kernel.org \
    --cc=sre@kernel.org \
    --cc=steev@kali.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).