From: Konrad Dybcio <konrad.dybcio@linaro.org>
To: linux-arm-msm@vger.kernel.org, andersson@kernel.org,
agross@kernel.org, krzysztof.kozlowski@linaro.org
Cc: marijn.suijten@somainline.org,
Konrad Dybcio <konrad.dybcio@linaro.org>,
Linus Walleij <linus.walleij@linaro.org>,
Rob Herring <robh+dt@kernel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
linux-gpio@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: [RFC PATCH 2/2] pinctrl: pinconf-generic: Add an overridable way to set bias property
Date: Mon, 30 Jan 2023 17:54:35 +0100 [thread overview]
Message-ID: <20230130165435.2347569-2-konrad.dybcio@linaro.org> (raw)
In-Reply-To: <20230130165435.2347569-1-konrad.dybcio@linaro.org>
We came to a point where we sometimes we support a few dozen boards
with a given SoC. Sometimes, we have to take into consideration
configurations which deviate rather significatly from the reference
or most common designs. In the context of pinctrl, this often comes
down to wildly different pin configurations. While pins, function and
drive-strength are easily overridable, the (mostly) boolean properties
associated with setting bias, aren't. This wouldn't be much of a
problem if they didn't differ between boards so often, preventing us
from having a "nice" baseline setup without inevitably having to go
with an ugly /delete-property/.
Introduce logic to handle bias-type, a property which sets a single
boolean type of bias on the pin (more than one type of BIAS_ does not
make sense, anyway) to make it easily overridable.
Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
---
drivers/pinctrl/pinconf-generic.c | 35 ++++++++++++++++++++++---
include/linux/pinctrl/pinconf-generic.h | 1 +
2 files changed, 32 insertions(+), 4 deletions(-)
diff --git a/drivers/pinctrl/pinconf-generic.c b/drivers/pinctrl/pinconf-generic.c
index 365c4b0ca465..b99c2a85486e 100644
--- a/drivers/pinctrl/pinconf-generic.c
+++ b/drivers/pinctrl/pinconf-generic.c
@@ -206,11 +206,38 @@ static void parse_dt_cfg(struct device_node *np,
unsigned int count, unsigned long *cfg,
unsigned int *ncfg)
{
- int i;
+ int i, ret;
+ u32 val;
+
+ /* Let's assume only one type of bias is used.. as it should be.. */
+ ret = of_property_read_u32(np, "bias-type", &val);
+ if (!ret) {
+ /* Bias properties end at idx PIN_CONFIG_BIAS_PULL_UP */
+ if (ret > PIN_CONFIG_BIAS_PULL_UP) {
+ pr_err("invalid type: %u\n", val);
+ goto generic_parse;
+ }
- for (i = 0; i < count; i++) {
- u32 val;
- int ret;
+ pr_debug("found bias type %u\n", val);
+ /*
+ * Properties between PIN_CONFIG_BIAS_PULL_DOWN and PIN_CONFIG_BIAS_PULL_UP
+ * have a default value of one, others default to zero.
+ */
+ cfg[*ncfg] = pinconf_to_config_packed(val, val >= PIN_CONFIG_BIAS_PULL_DOWN);
+ (*ncfg)++;
+
+ /* Start the generic property read loop where bias properties end. */
+ i = PIN_CONFIG_DRIVE_OPEN_DRAIN;
+ } else {
+ /*
+ * If we don't set bias through bias-type, search for all DT
+ * properties like nothing ever happened.
+ */
+generic_parse:
+ i = 0;
+ }
+
+ for (; i < count; i++) {
const struct pinconf_generic_params *par = ¶ms[i];
ret = of_property_read_u32(np, par->property, &val);
diff --git a/include/linux/pinctrl/pinconf-generic.h b/include/linux/pinctrl/pinconf-generic.h
index d74b7a4ea154..bcf68ba1ea46 100644
--- a/include/linux/pinctrl/pinconf-generic.h
+++ b/include/linux/pinctrl/pinconf-generic.h
@@ -117,6 +117,7 @@ struct pinctrl_map;
* presented using the packed format.
*/
enum pin_config_param {
+ /* Keep in sync with dt-bindings/pinctrl/pinconf-generic.h! */
PIN_CONFIG_BIAS_BUS_HOLD,
PIN_CONFIG_BIAS_DISABLE,
PIN_CONFIG_BIAS_HIGH_IMPEDANCE,
--
2.39.1
next prev parent reply other threads:[~2023-01-30 16:54 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-30 16:54 [RFC PATCH 1/2] dt-bindings: pincfg-node: Introduce an overridable way to set bias on pins Konrad Dybcio
2023-01-30 16:54 ` Konrad Dybcio [this message]
2023-01-30 23:10 ` Linus Walleij
2023-01-30 23:50 ` Konrad Dybcio
2023-01-31 13:21 ` Linus Walleij
2023-02-01 1:57 ` Rob Herring
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=20230130165435.2347569-2-konrad.dybcio@linaro.org \
--to=konrad.dybcio@linaro.org \
--cc=agross@kernel.org \
--cc=andersson@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=krzysztof.kozlowski@linaro.org \
--cc=linus.walleij@linaro.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=marijn.suijten@somainline.org \
--cc=robh+dt@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).