From: Stephan Gerhold <email@example.com>
To: Krzysztof Kozlowski <firstname.lastname@example.org>
Cc: "David S. Miller" <email@example.com>,
Jakub Kicinski <firstname.lastname@example.org>,
Rob Herring <email@example.com>,
Bongsu Jeon <firstname.lastname@example.org>,
Subject: Re: [linux-nfc] Re: [PATCH 2/2] nfc: s3fwrn5: i2c: Enable optional clock from device tree
Date: Wed, 19 May 2021 10:07:59 +0200 [thread overview]
Message-ID: <YKTHXzUhcYa5YJIs@gerhold.net> (raw)
On Tue, May 18, 2021 at 11:25:55AM -0400, Krzysztof Kozlowski wrote:
> On 18/05/2021 11:00, Stephan Gerhold wrote:
> > On Tue, May 18, 2021 at 10:30:43AM -0400, Krzysztof Kozlowski wrote:
> >> On 18/05/2021 09:39, Stephan Gerhold wrote:
> >>> s3fwrn5 has a NFC_CLK_REQ output GPIO, which is asserted whenever
> >>> the clock is needed for the current operation. This GPIO can be either
> >>> connected directly to the clock provider, or must be monitored by
> >>> this driver.
> >>> As an example for the first case, on many Qualcomm devices the
> >>> NFC clock is provided by the main PMIC. The clock can be either
> >>> permanently enabled (clocks = <&rpmcc RPM_SMD_BB_CLK2>) or enabled
> >>> only when requested through a special input pin on the PMIC
> >>> (clocks = <&rpmcc RPM_SMD_BB_CLK2_PIN>).
> >>> On the Samsung Galaxy A3/A5 (2015, Qualcomm MSM8916) this mechanism
> >>> is used with S3FWRN5's NFC_CLK_REQ output GPIO to enable the clock
> >>> only when necessary. However, to make that work the s3fwrn5 driver
> >>> must keep the RPM_SMD_BB_CLK2_PIN clock enabled.
> >> This contradicts the code. You wrote that pin should be kept enabled
> >> (somehow... by driver? by it's firmware?) but your code requests the
> >> clock from provider.
> > Yeah, I see how that's a bit confusing. Let me try to explain it a bit
> > better. So the Samsung Galaxy A5 (2015) has a "S3FWRN5XS1-YF30", some
> > variant of S3FWRN5 I guess. That S3FWRN5 has a "XI" and "XO" pin in the
> > schematics. "XO" seems to be floating, but "XI" goes to "BB_CLK2"
> > on PM8916 (the main PMIC).
> > Then, there is "GPIO2/NFC_CLK_REQ" on the S3FWRN5. This goes to
> > GPIO_2_NFC_CLK_REQ on PM8916. (Note: I'm talking about two different
> > GPIO2 here, one on S3FWRN5 and one on PM8916, they just happen to have
> > the same number...)
> > So in other words, S3FWRN5 gets some clock from BB_CLK2 on PM8916,
> > and can tell PM8916 that it needs the clock via GPIO2/NFC_CLK_REQ.
> > Now the confusing part is that the rpmcc/clk-smd-rpm driver has two
> > clocks that represent BB_CLK2 (see include/dt-bindings/clock/qcom,rpmcc.h):
> > - RPM_SMD_BB_CLK2
> > - RPM_SMD_BB_CLK2_PIN
> > (There are also *_CLK2_A variants but they are even more confusing
> > and not needed here...)
> > Those end up in different register settings in PM8916. There is one bit
> > to permanently enable BB_CLK2 (= RPM_SMD_BB_CLK2), and one bit to enable
> > BB_CLK2 based on the status of GPIO_2_NFC_CLK_REQ on PM8916
> > (= RPM_SMD_BB_CLK2_PIN).
> > So there is indeed some kind of "AND" inside PM8916 (the register bit
> > and "NFC_CLK_REQ" input pin). To make that "AND" work I need to make
> > some driver (here: the s3fwrn5 driver) enable the clock so the register
> > bit in PM8916 gets set.
> Thanks for the explanation, it sounds good. The GPIO2 (or how you call
> it NFC_CLK_REQ) on S3FWRN5 looks like non-configurable from Linux point
> of view. Probably the device firmware plays with it always or at least
> handles it in an unknown way for us.
FWIW, I was looking at some more s3fwrn5 code yesterday and came
across this (in s3fwrn5_nci_rf_configure()):
/* Set default clock configuration for external crystal */
fw_cfg.clk_type = 0x01;
fw_cfg.clk_speed = 0xff;
fw_cfg.clk_req = 0xff;
ret = nci_prop_cmd(info->ndev, NCI_PROP_FW_CFG,
sizeof(fw_cfg), (__u8 *)&fw_cfg);
if (ret < 0)
It does look quite suspiciously like that configures how s3fwrn5 expects
the clock and possibly (fw_cfg.clk_req?) how GPIO2 behaves. But it's not
particularly useful without some documentation for the magic numbers.
Personally, I just skip all firmware/RF configuration (which works thanks
to commit 4fb7b98c7be3 ("nfc: s3fwrn5: skip the NFC bootloader mode")).
That way, S3FWRN5 just continues using the proper configuration
that was loaded by the vendor drivers at some point. :)
next prev parent reply other threads:[~2021-05-19 8:08 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-18 13:39 [PATCH 1/2] dt-bindings: net: nfc: s3fwrn5: Add optional clock Stephan Gerhold
2021-05-18 13:39 ` [PATCH 2/2] nfc: s3fwrn5: i2c: Enable optional clock from device tree Stephan Gerhold
2021-05-18 14:30 ` [linux-nfc] " Krzysztof Kozlowski
2021-05-18 15:00 ` Stephan Gerhold
2021-05-18 15:25 ` [linux-nfc] " Krzysztof Kozlowski
2021-05-18 15:37 ` Stephan Gerhold
2021-05-19 8:07 ` Stephan Gerhold [this message]
2021-05-19 15:58 ` Krzysztof Kozlowski
2021-05-20 7:41 ` Stephan Gerhold
2021-05-20 11:40 ` Bongsu Jeon
2021-05-21 15:02 ` Krzysztof Kozlowski
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:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* 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).