From: Marc Gonzalez <marc.w.gonzalez@free.fr>
To: gpio <linux-gpio@vger.kernel.org>, MSM <linux-arm-msm@vger.kernel.org>
Cc: Linus Walleij <linus.walleij@linaro.org>,
Bjorn Andersson <bjorn.andersson@linaro.org>,
Wolfram Sang <wsa+renesas@sang-engineering.com>,
Jeffrey Hugo <jhugo@codeaurora.org>
Subject: Pinctrl DT for msm8998
Date: Wed, 24 Apr 2019 17:19:27 +0200 [thread overview]
Message-ID: <7b8c15a8-8a17-e16e-8974-4a0c3a202daa@free.fr> (raw)
Hello,
linusw wrote:
> Some drivers prefer to handle individual pins by name, such as msm.
> Some drivers, especially those with hardware tailored to handle pin
> muxing groupwise, prefer to handle them by function group name. In
> the case of msm, every group consists of one pin and these groups are
> all named "gpioNN". What the pin control subsystem does is assign
> functions to 1 or several groups of pins. In the msm case as there is
> just one pin in every group, this becomes a bit confusing, it is easy
> to mix up what is a pin and what is a group. The pin multiplexing is
> done on groups while the pin configuration is done on individual
> pins. As to why there is one-to-one pin to group name mapping in the
> msm driver you need to ask bamse, for the pin control subsystem this
> is just some string. I suppose there was a good reason to set it up
> this way on msm. I think the msm may be set up this way because the
> pins can be configured in so many ways that it is hard to come up
> with natural groups that map to physical use cases (these are often
> enumerable on other platforms). In many systems the driver authors
> are restricted to how groups can be activated with functions, see eg
> pinctrl-gemini.c, in many other cases the driver author tries to
> half-guess the groups based on use cases that makes sense.
bamse wrote:
> You don't have to specify pinconf/pinmux in different subnodes
> anymore, that changed a few years back. For the blsp you typically
> want subnodes for each pin though, because they have different
> configuration...but you don't need to split e.g gpio88 in a mux and
> conf. Or per your production example, you don't need any subnodes at
> all...just put the properties in i2c_5_{active,sleep} directly. And
> as each gpioXX is configurable we need to define how we want each one
> to be configured...and we need to list all the configureables in the
> driver. In the qcom platform you can mux i2c on gpio87 at the same
> time as running gpio88 as gpio. Not that it would make sense in this
> case, but there are other such cases where we need the control of
> each configurable item.
diff --git a/arch/arm64/boot/dts/qcom/msm8998-pins.dtsi b/arch/arm64/boot/dts/qcom/msm8998-pins.dtsi
index 6db70acd38ee..bc1a1a4081da 100644
--- a/arch/arm64/boot/dts/qcom/msm8998-pins.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8998-pins.dtsi
@@ -75,4 +75,18 @@
drive-strength = <2>; /* 2 mA */
};
};
+
+ i2c5_default: i2c5_default {
+ pins = "gpio87", "gpio88";
+ function = "blsp_i2c5";
+ drive-strength = <2>;
+ bias-disable;
+ };
+
+ i2c5_sleep: i2c5_sleep {
+ pins = "gpio87", "gpio88";
+ function = "blsp_i2c5";
+ drive-strength = <2>;
+ bias-disable;
+ };
};
Note that the two nodes are identical. Do I still need both then?
&blsp1_i2c5 {
status = "ok";
clock-frequency = <100000>;
pinctrl-names = "default", "sleep";
pinctrl-0 = <&i2c5_default>;
pinctrl-1 = <&i2c5_sleep>;
};
Couldn't I just change the above to:
&blsp1_i2c5 {
status = "ok";
clock-frequency = <100000>;
pinctrl-names = "default";
pinctrl-0 = <&i2c5_default>;
};
Regards.
next reply other threads:[~2019-04-24 15:19 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-24 15:19 Marc Gonzalez [this message]
2019-04-24 17:17 ` Pinctrl DT for msm8998 Linus Walleij
2019-04-25 4:16 ` 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=7b8c15a8-8a17-e16e-8974-4a0c3a202daa@free.fr \
--to=marc.w.gonzalez@free.fr \
--cc=bjorn.andersson@linaro.org \
--cc=jhugo@codeaurora.org \
--cc=linus.walleij@linaro.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-gpio@vger.kernel.org \
--cc=wsa+renesas@sang-engineering.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.