From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
To: Andrew Lunn <andrew@lunn.ch>
Cc: Mark Rutland <mark.rutland@arm.com>,
Alexandre Courbot <gnurou@gmail.com>,
Jason Cooper <jason@lakedaemon.net>,
linux-pwm@vger.kernel.org,
Linus Walleij <linus.walleij@linaro.org>,
Russell King <linux@armlinux.org.uk>,
Rob Herring <robh+dt@kernel.org>,
linux-kernel@vger.kernel.org,
Gregory Clement <gregory.clement@free-electrons.com>,
devicetree@vger.kernel.org,
Thierry Reding <thierry.reding@gmail.com>,
linux-gpio@vger.kernel.org,
Ralph Sennhauser <ralph.sennhauser@gmail.com>,
linux-arm-kernel@lists.infradead.org,
Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Subject: Re: [PATCH v5 1/4] gpio: mvebu: Add limited PWM support
Date: Fri, 21 Apr 2017 11:19:52 +0200 [thread overview]
Message-ID: <20170421111952.54978e80@free-electrons.com> (raw)
In-Reply-To: <20170412151932.GE7023@lunn.ch>
Hello,
On Wed, 12 Apr 2017 17:19:32 +0200, Andrew Lunn wrote:
> Yep. It was a compromise. By adding a new binding for the GPIO driver,
> this might be possible. But it did not seem worth such a major change.
>
> The prime use of this feature is for controlling a fan. So far, i've
> not seen any hardware with more than one fan, i.e. needs more than one
> PWM. Nor have i seen any hardware with the GPIO for the fan being on
> the third bank. A hardware manufacture could add multiple fans, but i
> doubt it, they make noise and fail. And if a manufacture does place a
> fan on the third bank, it can still be controlled as a plain GPIO fan,
> as we have been doing for the last few years.
Right.
> So i personally think it is an O.K. compromise.
I clearly don't want to block this, but I believe this is a very good
illustration of why stable DT bindings simply don't work. We are
realizing here that having each GPIO bank represented as a separate DT
node doesn't work, because this blinking functionality is not per GPIO
bank, but global to all GPIO banks.
I am totally fine with compromise, and having things simple first, and
extend them later if needed. But this stable DT binding rule makes this
quite impossible: what is a compromise today might put you in big
troubles tomorrow.
Anyway, it's fine for me, I don't think it's worth the effort making a
much more complicated solution/change.
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
WARNING: multiple messages have this Message-ID (diff)
From: thomas.petazzoni@free-electrons.com (Thomas Petazzoni)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v5 1/4] gpio: mvebu: Add limited PWM support
Date: Fri, 21 Apr 2017 11:19:52 +0200 [thread overview]
Message-ID: <20170421111952.54978e80@free-electrons.com> (raw)
In-Reply-To: <20170412151932.GE7023@lunn.ch>
Hello,
On Wed, 12 Apr 2017 17:19:32 +0200, Andrew Lunn wrote:
> Yep. It was a compromise. By adding a new binding for the GPIO driver,
> this might be possible. But it did not seem worth such a major change.
>
> The prime use of this feature is for controlling a fan. So far, i've
> not seen any hardware with more than one fan, i.e. needs more than one
> PWM. Nor have i seen any hardware with the GPIO for the fan being on
> the third bank. A hardware manufacture could add multiple fans, but i
> doubt it, they make noise and fail. And if a manufacture does place a
> fan on the third bank, it can still be controlled as a plain GPIO fan,
> as we have been doing for the last few years.
Right.
> So i personally think it is an O.K. compromise.
I clearly don't want to block this, but I believe this is a very good
illustration of why stable DT bindings simply don't work. We are
realizing here that having each GPIO bank represented as a separate DT
node doesn't work, because this blinking functionality is not per GPIO
bank, but global to all GPIO banks.
I am totally fine with compromise, and having things simple first, and
extend them later if needed. But this stable DT binding rule makes this
quite impossible: what is a compromise today might put you in big
troubles tomorrow.
Anyway, it's fine for me, I don't think it's worth the effort making a
much more complicated solution/change.
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
WARNING: multiple messages have this Message-ID (diff)
From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
To: Andrew Lunn <andrew@lunn.ch>
Cc: Ralph Sennhauser <ralph.sennhauser@gmail.com>,
Thierry Reding <thierry.reding@gmail.com>,
Mark Rutland <mark.rutland@arm.com>,
Jason Cooper <jason@lakedaemon.net>,
Alexandre Courbot <gnurou@gmail.com>,
Linus Walleij <linus.walleij@linaro.org>,
Russell King <linux@armlinux.org.uk>,
linux-pwm@vger.kernel.org, linux-kernel@vger.kernel.org,
Gregory Clement <gregory.clement@free-electrons.com>,
devicetree@vger.kernel.org, Rob Herring <robh+dt@kernel.org>,
linux-gpio@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Subject: Re: [PATCH v5 1/4] gpio: mvebu: Add limited PWM support
Date: Fri, 21 Apr 2017 11:19:52 +0200 [thread overview]
Message-ID: <20170421111952.54978e80@free-electrons.com> (raw)
In-Reply-To: <20170412151932.GE7023@lunn.ch>
Hello,
On Wed, 12 Apr 2017 17:19:32 +0200, Andrew Lunn wrote:
> Yep. It was a compromise. By adding a new binding for the GPIO driver,
> this might be possible. But it did not seem worth such a major change.
>
> The prime use of this feature is for controlling a fan. So far, i've
> not seen any hardware with more than one fan, i.e. needs more than one
> PWM. Nor have i seen any hardware with the GPIO for the fan being on
> the third bank. A hardware manufacture could add multiple fans, but i
> doubt it, they make noise and fail. And if a manufacture does place a
> fan on the third bank, it can still be controlled as a plain GPIO fan,
> as we have been doing for the last few years.
Right.
> So i personally think it is an O.K. compromise.
I clearly don't want to block this, but I believe this is a very good
illustration of why stable DT bindings simply don't work. We are
realizing here that having each GPIO bank represented as a separate DT
node doesn't work, because this blinking functionality is not per GPIO
bank, but global to all GPIO banks.
I am totally fine with compromise, and having things simple first, and
extend them later if needed. But this stable DT binding rule makes this
quite impossible: what is a compromise today might put you in big
troubles tomorrow.
Anyway, it's fine for me, I don't think it's worth the effort making a
much more complicated solution/change.
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
next prev parent reply other threads:[~2017-04-21 9:19 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-09 18:09 [PATCH v5 0/4] gpio: mvebu: Add PWM fan support Ralph Sennhauser
2017-04-09 18:09 ` Ralph Sennhauser
[not found] ` <20170409180931.4884-1-ralph.sennhauser-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2017-04-09 18:09 ` [PATCH v5 1/4] gpio: mvebu: Add limited PWM support Ralph Sennhauser
2017-04-09 18:09 ` Ralph Sennhauser
2017-04-09 18:09 ` Ralph Sennhauser
2017-04-12 14:31 ` Thomas Petazzoni
2017-04-12 14:31 ` Thomas Petazzoni
2017-04-12 15:19 ` Andrew Lunn
2017-04-12 15:19 ` Andrew Lunn
2017-04-21 9:19 ` Thomas Petazzoni [this message]
2017-04-21 9:19 ` Thomas Petazzoni
2017-04-21 9:19 ` Thomas Petazzoni
2017-04-24 9:15 ` Linus Walleij
2017-04-24 9:15 ` Linus Walleij
2017-04-12 17:11 ` Thierry Reding
2017-04-12 17:11 ` Thierry Reding
2017-04-13 7:45 ` Ralph Sennhauser
2017-04-13 7:45 ` Ralph Sennhauser
2017-04-12 17:21 ` Thierry Reding
2017-04-12 17:21 ` Thierry Reding
[not found] ` <20170409180931.4884-2-ralph.sennhauser-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2017-04-13 20:14 ` Rob Herring
2017-04-13 20:14 ` Rob Herring
2017-04-13 20:14 ` Rob Herring
2017-04-09 18:09 ` [PATCH v5 2/4] ARM: dts: mvebu: Add PWM properties to .dtsi files Ralph Sennhauser
2017-04-09 18:09 ` Ralph Sennhauser
2017-04-09 18:09 ` Ralph Sennhauser
2017-04-09 18:09 ` [PATCH v5 3/4] ARM: mvebu: Enable SENSORS_PWM_FAN in defconfig Ralph Sennhauser
2017-04-09 18:09 ` Ralph Sennhauser
2017-04-09 18:09 ` [PATCH v5 4/4] ARM: dts: armada-xp: Use pwm-fan rather than gpio-fan Ralph Sennhauser
2017-04-09 18:09 ` Ralph Sennhauser
2017-04-12 9:11 ` [PATCH v5 0/4] gpio: mvebu: Add PWM fan support Gregory CLEMENT
2017-04-12 9:11 ` Gregory CLEMENT
2017-04-12 17:16 ` Thierry Reding
2017-04-12 17:16 ` Thierry Reding
[not found] ` <20170412171656.GC11964-EkSeR96xj6Pcmrwk2tT4+A@public.gmane.org>
2017-04-13 7:49 ` Ralph Sennhauser
2017-04-13 7:49 ` Ralph Sennhauser
2017-04-13 7:49 ` Ralph Sennhauser
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=20170421111952.54978e80@free-electrons.com \
--to=thomas.petazzoni@free-electrons.com \
--cc=andrew@lunn.ch \
--cc=devicetree@vger.kernel.org \
--cc=gnurou@gmail.com \
--cc=gregory.clement@free-electrons.com \
--cc=jason@lakedaemon.net \
--cc=linus.walleij@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pwm@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=mark.rutland@arm.com \
--cc=ralph.sennhauser@gmail.com \
--cc=robh+dt@kernel.org \
--cc=sebastian.hesselbarth@gmail.com \
--cc=thierry.reding@gmail.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.