From: Dong Aisheng <dongas86@gmail.com>
To: jmondi <jacopo@jmondi.org>
Cc: Linus Walleij <linus.walleij@linaro.org>,
Andy Shevchenko <andy.shevchenko@gmail.com>,
Jacopo Mondi <jacopo+renesas@jmondi.org>,
Chris Brandt <Chris.Brandt@renesas.com>,
Geert Uytterhoeven <geert+renesas@glider.be>,
Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
Rob Herring <robh+dt@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
Russell King - ARM Linux <linux@armlinux.org.uk>,
Linux-Renesas <linux-renesas-soc@vger.kernel.org>,
"linux-gpio@vger.kernel.org" <linux-gpio@vger.kernel.org>,
devicetree <devicetree@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Dong Aisheng <aisheng.dong@nxp.com>
Subject: Re: [PATCH v5 01/10] pinctrl: generic: Add bi-directional and output-enable
Date: Tue, 13 Jun 2017 14:25:08 +0800 [thread overview]
Message-ID: <CAA+hA=RmDEybOkbimtyQBq+vK=6T9GYJn9Jw-GcDy7XxR0b0AA@mail.gmail.com> (raw)
In-Reply-To: <20170612094424.GG15739@w540>
On Mon, Jun 12, 2017 at 5:44 PM, jmondi <jacopo@jmondi.org> wrote:
> Hi Linus,
>
> On Sun, Jun 11, 2017 at 11:45:49PM +0200, Linus Walleij wrote:
>> On Fri, Jun 9, 2017 at 9:50 AM, jmondi <jacopo@jmondi.org> wrote:
>> > On Fri, Jun 09, 2017 at 03:26:57PM +0800, Dong Aisheng wrote:
>>
>> >> > I see three options here:
>> >> >
>> >> > 1) Add "output-buffer-enable" and "input-buffer-enable"
>> >> > we end up with
>> >> > "output-high"
>> >> > "output-low"
>> >> > "input-enable"
>> >> > "output-buffer-enable"
>> >> > "input-buffer-enable"
>> >> >
>> >> > 2) Add "output-buffer-enable" only
>> >> > we end up with
>> >> > "output-high"
>> >> > "output-low"
>> >> > "input-enable"
>> >> > "output-buffer-enable"
>> >> >
>> >> > Binding may be confusing as in one case we use "output-buffer-enable"
>> >> > while in the other "input-enable"
>> >> >
>> >> > 3) Add "output-enable" only
>> >> > "output-high"
>> >> > "output-low"
>> >> > "input-enable"
>> >> > "output-enable"
>> >> >
>> >> > As you, I don't like "output-enable" that much but it pairs better with
>> >> > "input-enable".
>> >> >
>> >> > I'll let you and DT people decide on this, as it's really an ABI definition
>> >> > problem and you have better judgment there.
>> >> >
>> >>
>> >> What's the final decision of this?
>> >
>> > I admit a was buying a bit of time and post-poned the gentle ping for
>> > any final word on this. But since you're asking I'll second your
>> > question :)
>>
>> I suspect it is time to quote
>> Documentation/process/management-style.rst
>> (Torvalds):
>>
>> 1) Decisions
>>
>> Everybody thinks managers make decisions, and that decision-making is
>> important. The bigger and more painful the decision, the bigger the
>> manager must be to make it. That's very deep and obvious, but it's not
>> actually true.
>>
>> The name of the game is to **avoid** having to make a decision. In
>> particular, if somebody tells you "choose (a) or (b), we really need you
>> to decide on this", you're in trouble as a manager. The people you
>> manage had better know the details better than you, so if they come to
>> you for a technical decision, you're screwed. You're clearly not
>> competent to make that decision for them.
>>
>> (It goes on, it's the best part of the entire Documentation/* dir in my
>> opinion, please take the time to read it in full.)
>>
>> So: what do you guys, using this feature, and Andy, who raised serious
>> concerns, think is the right binding? That is what *I* need to know.
>
> Fair enough :)
>
> I'll try to keep this short: I don't like "output-enable", and at the
> same time I don't think "output-high" and "output-low" fit well for
> this purpose, as they electrically means something different from what
> our (and IMX) use case is: enabling/disabling input/output
> buffers internal to pin controller/gpio block HW and not driving a value
> there.
>
> This seems clear to me from the "GPIO mode pitfalls" section of
> pinctrl.txt documentation examples and from the fact that generic bindings
> did not expose an "output" flag because if you drive an output line, you
> reasonably either drive it high or low.
>
> Unfortunately I cannot convince myself that the same reasons apply
> to the input use case. Enabling input on a pin implies the pinctrl/gpio driver
> has to enable any input buffer required to use that pin as a properly
> working input line, and enabling an input buffer implies being able to sense
> the line value from there, so I don't see that much use for "input-buffer-enable"
> alone.
>
> So, even if bindings could look a bit weird as there won't be a direct
> matching between properties names used to enable input/output buffers,
> my vote is to add "output-buffer-enable" only, and keep using the
> already there "input-enable" properties for the input use case.
>
Yes, it may be a bit weird.
I'm not pad internal details expert and can't tell much difference between
output-enable and output-buffer-enable.
I just feel a bit confuse if only using output-buffer-enable.
If enable both input and output, it becomes:
pinctrl_xxx: gpios_xxx_grp {
pins = <
ULP1_PAD_PTD0__PTD0
>;
input-enable;
output-buffer-enable;
bias-pull-up;
};
How about still use output-enable in pairs to input-enable but explain more
in comments?
Aslo update 'input-enable' comment to 'enable input buffer'.
e.g.
diff --git a/drivers/pinctrl/pinconf-generic.c
b/drivers/pinctrl/pinconf-generic.c
index 720a19f..96c83a4 100644
--- a/drivers/pinctrl/pinconf-generic.c
+++ b/drivers/pinctrl/pinconf-generic.c
@@ -172,6 +172,7 @@ static const struct pinconf_generic_params dt_params[] = {
{ "input-schmitt-enable", PIN_CONFIG_INPUT_SCHMITT_ENABLE, 1 },
{ "low-power-disable", PIN_CONFIG_LOW_POWER_MODE, 0 },
{ "low-power-enable", PIN_CONFIG_LOW_POWER_MODE, 1 },
+ { "output-enable", PIN_CONFIG_OUTPUT_ENABLE, 1 },
{ "output-high", PIN_CONFIG_OUTPUT, 1, },
{ "output-low", PIN_CONFIG_OUTPUT, 0, },
{ "power-source", PIN_CONFIG_POWER_SOURCE, 0 },
diff --git a/include/linux/pinctrl/pinconf-generic.h
b/include/linux/pinctrl/pinconf-generic.h
index 7620eb1..d30f4fe 100644
--- a/include/linux/pinctrl/pinconf-generic.h
+++ b/include/linux/pinctrl/pinconf-generic.h
@@ -59,9 +59,9 @@
* which means it will wait for signals to settle when reading inputs. The
* argument gives the debounce time in usecs. Setting the
* argument to zero turns debouncing off.
- * @PIN_CONFIG_INPUT_ENABLE: enable the pin's input. Note that this does not
- * affect the pin's ability to drive output. 1 enables input, 0 disables
- * input.
+ * @PIN_CONFIG_INPUT_ENABLE: enable the pin's input buffer. Note
that this does
+ * not affect the pin's ability to drive output.
+ * 1 enables input, 0 disables input.
* @PIN_CONFIG_INPUT_SCHMITT: this will configure an input pin to run in
* schmitt-trigger mode. If the schmitt-trigger has adjustable hysteresis,
* the threshold value is given on a custom format as argument when
@@ -73,6 +73,9 @@
* operation, if several modes of operation are supported these can be
* passed in the argument on a custom form, else just use argument 1
* to indicate low power mode, argument 0 turns low power mode off.
+ * @PIN_CONFIG_OUTPUT_ENABLE: only enable the pin's output buffer, not driving
+ * a value.
+ * 1 enables output buffer, 0 disables output buffer.
* @PIN_CONFIG_OUTPUT: this will configure the pin as an output. Use argument
* 1 to indicate high level, argument 0 to indicate low level. (Please
* see Documentation/pinctrl.txt, section "GPIO mode pitfalls" for a
Or
invent both input-buffer-enable and output-buffer-enable and
deprecated input-enable?
Andy,
how about your comments?
Regards
Dong Aisheng
> Thanks
> j
>
>>
>> Yours,
>> Linus Walleij
next prev parent reply other threads:[~2017-06-13 6:25 UTC|newest]
Thread overview: 79+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-27 8:19 [PATCH v5 00/10] Renesas RZ/A1 pin and gpio controller Jacopo Mondi
2017-04-27 8:19 ` [PATCH v5 01/10] pinctrl: generic: Add bi-directional and output-enable Jacopo Mondi
2017-04-27 14:56 ` Andy Shevchenko
2017-04-28 8:32 ` Linus Walleij
2017-04-28 10:09 ` Geert Uytterhoeven
2017-05-07 7:50 ` Linus Walleij
2017-04-28 12:07 ` Chris Brandt
2017-04-28 12:15 ` Andy Shevchenko
2017-04-28 13:18 ` Chris Brandt
2017-04-28 14:53 ` Andy Shevchenko
2017-04-28 15:16 ` Chris Brandt
2017-04-28 15:37 ` Andy Shevchenko
2017-04-28 16:46 ` Chris Brandt
2017-05-07 7:52 ` Linus Walleij
2017-05-08 16:01 ` jmondi
2017-05-08 16:08 ` Andy Shevchenko
2017-05-08 17:02 ` Chris Brandt
2017-05-08 18:26 ` Andy Shevchenko
2017-05-08 20:05 ` Chris Brandt
2017-05-08 17:25 ` jmondi
2017-05-08 17:47 ` Andy Shevchenko
2017-05-09 9:55 ` jmondi
2017-05-08 21:19 ` Linus Walleij
2017-05-09 10:54 ` Geert Uytterhoeven
2017-05-12 9:00 ` Linus Walleij
2017-05-12 9:04 ` Linus Walleij
2017-05-12 11:11 ` Geert Uytterhoeven
2017-05-12 12:13 ` Chris Brandt
2017-05-12 12:25 ` Geert Uytterhoeven
2017-05-12 12:57 ` Chris Brandt
2017-05-12 11:44 ` Chris Brandt
2017-05-23 10:08 ` Dong Aisheng
2017-05-23 18:37 ` jmondi
2017-05-29 8:45 ` Linus Walleij
2017-05-29 10:42 ` jmondi
2017-05-30 14:12 ` Chris Brandt
2017-06-09 7:26 ` Dong Aisheng
2017-06-09 7:50 ` jmondi
2017-06-11 21:45 ` Linus Walleij
2017-06-12 9:44 ` jmondi
2017-06-13 6:25 ` Dong Aisheng [this message]
2017-06-15 11:11 ` jmondi
2017-06-19 15:43 ` Dong Aisheng
2017-04-27 8:19 ` [PATCH v5 02/10] pinctrl: generic: Add macros to unpack properties Jacopo Mondi
2017-04-27 8:37 ` Geert Uytterhoeven
2017-04-28 8:16 ` Linus Walleij
2017-04-28 10:06 ` Geert Uytterhoeven
2017-04-28 12:49 ` jmondi
2017-04-28 16:23 ` Andy Shevchenko
2017-04-27 8:19 ` [PATCH v5 03/10] pinctrl: Renesas RZ/A1 pin and gpio controller Jacopo Mondi
2017-04-27 8:37 ` Geert Uytterhoeven
2017-04-27 8:19 ` [PATCH v5 04/10] dt-bindings: pinctrl: Add RZ/A1 bindings doc Jacopo Mondi
2017-04-27 8:37 ` Geert Uytterhoeven
2017-04-28 21:03 ` Rob Herring
2017-04-27 8:19 ` [PATCH v5 05/10] arm: dts: dt-bindings: Add Renesas RZ/A1 pinctrl header Jacopo Mondi
2017-04-27 8:38 ` Geert Uytterhoeven
2017-04-28 5:19 ` Simon Horman
2017-04-27 8:19 ` [PATCH v5 06/10] arm: dts: r7s72100: Add pin controller node Jacopo Mondi
2017-04-27 8:19 ` [PATCH v5 07/10] arm: dts: genmai: Add SCIF2 pin group Jacopo Mondi
2017-04-28 5:21 ` Simon Horman
2017-04-27 8:19 ` [PATCH v5 08/10] arm: dts: genmai: Add RIIC2 " Jacopo Mondi
2017-04-27 8:19 ` [PATCH v5 09/10] arm: dts: genmai: Add user led device nodes Jacopo Mondi
2017-04-27 8:19 ` [PATCH v5 10/10] arm: dts: genmai: Add ethernet pin group Jacopo Mondi
2017-04-27 9:56 ` Geert Uytterhoeven
2017-04-27 10:48 ` Chris Brandt
2017-04-28 5:22 ` Simon Horman
2017-04-28 7:18 ` Geert Uytterhoeven
2017-04-28 14:48 ` Chris Brandt
2017-05-05 12:06 ` Linus Walleij
2017-05-05 12:20 ` Geert Uytterhoeven
2017-05-05 12:45 ` Chris Brandt
2017-05-11 13:48 ` Linus Walleij
2017-04-28 8:49 ` Linus Walleij
2017-04-28 13:50 ` Chris Brandt
2017-04-27 8:42 ` [PATCH v5 00/10] Renesas RZ/A1 pin and gpio controller Geert Uytterhoeven
2017-04-28 5:22 ` Simon Horman
2017-04-28 7:24 ` jmondi
2017-04-28 7:30 ` Geert Uytterhoeven
2017-04-28 7:31 ` Simon Horman
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='CAA+hA=RmDEybOkbimtyQBq+vK=6T9GYJn9Jw-GcDy7XxR0b0AA@mail.gmail.com' \
--to=dongas86@gmail.com \
--cc=Chris.Brandt@renesas.com \
--cc=aisheng.dong@nxp.com \
--cc=andy.shevchenko@gmail.com \
--cc=devicetree@vger.kernel.org \
--cc=geert+renesas@glider.be \
--cc=jacopo+renesas@jmondi.org \
--cc=jacopo@jmondi.org \
--cc=laurent.pinchart@ideasonboard.com \
--cc=linus.walleij@linaro.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-renesas-soc@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=mark.rutland@arm.com \
--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).