From: Sascha Hauer <s.hauer@pengutronix.de>
To: Olof Johansson <olof@lixom.net>
Cc: Russell King - ARM Linux <linux@arm.linux.org.uk>,
linux-pwm@vger.kernel.org,
Thierry Reding <thierry.reding@gmail.com>,
arm@kernel.org, linux-arm-kernel@lists.infradead.org,
devicetree@vger.kernel.org
Subject: Re: PWM...
Date: Mon, 20 Jan 2014 08:21:02 +0100 [thread overview]
Message-ID: <20140120072102.GA19940@pengutronix.de> (raw)
In-Reply-To: <20140119190324.GC28056@quad.lixom.net>
On Sun, Jan 19, 2014 at 11:03:24AM -0800, Olof Johansson wrote:
> [Adding devicetree list since we're talking bindings]
>
> On Sun, Jan 19, 2014 at 04:49:57PM +0000, Russell King - ARM Linux wrote:
> > So, having looked at what else I can add support for on the cubox-i, I
> > decided it would be nice and simple to add support for the front panel
> > LED. What could possibly go wrong with this.
> >
> > Well, the hardware is wired such that the LED is connected between the
> > PWM output and +3.3v. So, a constant low turns the LED on full, whereas
> > a constant high turns the LED off.
> >
> > So, the polarity of the LED is inverted - but this _can't_ be specified
> > in the totally and utterly fucked misdesigned crap that DT is:
> >
> > pwmleds {
> > compatible = "pwm-leds";
> > pinctrl-names = "default";
> > pinctrl-0 = <&pinctrl_cubox_i_pwm1>;
> >
> > front {
> > label = "imx6:red:front";
> > pwms = <&pwm1 0 50000>;
> > max-brightness = <248>;
> > };
> > };
> >
> > pwm1: pwm@02080000 {
> > #pwm-cells = <2>;
> > compatible = "fsl,imx6q-pwm", "fsl,imx27-pwm";
> > reg = <0x02080000 0x4000>;
> > interrupts = <0 83 0x04>;
> > clocks = <&clks 62>, <&clks 145>;
> > clock-names = "ipg", "per";
> > };
> >
> > Yes, because iMX6 specifies #pwm-cells as 2, there's no flags able to
> > be specified in the pwms declaration in pwmleds. So that doesn't work.
> > There's no property to tell pwmleds that it should use inverted sense
> > either.
>
> Adding a property for active-low to the pwm-leds binding would be
> easy, and backwards compatible. I'm surprised the original binding
> didn't specify it. The leds-pwm driver already seems to support it for
> C-configured instances.
>
> I'm also surprised that the imx pwm driver even has a #pwm-cells of
> two, since the driver only supports one output. It'd be nice if they
> had allocated the extra cell for flags, but it's hard to change now,
> unless you do a new binding/compatible value and deprecate the old one.
>
> > Moreover, there's no way to specify a default brightness for the LED
> > in the absence of any trigger, so this results in the LED being fully
> > on.
>
> That seems to be missing from the led-pwm driver altogether, not just the DT
> bindings? Shouldn't be too bad to add a default-brightness property and plumb
> that up through the driver in this case.
>
> > So, something which _should_ be nice and simple is turned into a major
> > fuckup because of the total and utter crappiness that DT is and the
> > total misdesign that this shite is.
>
> It's not a major fuckup. None of the above is unfixable.
Indeed, and we already have a patch for this:
http://comments.gmane.org/gmane.linux.ports.arm.kernel/294823
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
WARNING: multiple messages have this Message-ID (diff)
From: s.hauer@pengutronix.de (Sascha Hauer)
To: linux-arm-kernel@lists.infradead.org
Subject: PWM...
Date: Mon, 20 Jan 2014 08:21:02 +0100 [thread overview]
Message-ID: <20140120072102.GA19940@pengutronix.de> (raw)
In-Reply-To: <20140119190324.GC28056@quad.lixom.net>
On Sun, Jan 19, 2014 at 11:03:24AM -0800, Olof Johansson wrote:
> [Adding devicetree list since we're talking bindings]
>
> On Sun, Jan 19, 2014 at 04:49:57PM +0000, Russell King - ARM Linux wrote:
> > So, having looked at what else I can add support for on the cubox-i, I
> > decided it would be nice and simple to add support for the front panel
> > LED. What could possibly go wrong with this.
> >
> > Well, the hardware is wired such that the LED is connected between the
> > PWM output and +3.3v. So, a constant low turns the LED on full, whereas
> > a constant high turns the LED off.
> >
> > So, the polarity of the LED is inverted - but this _can't_ be specified
> > in the totally and utterly fucked misdesigned crap that DT is:
> >
> > pwmleds {
> > compatible = "pwm-leds";
> > pinctrl-names = "default";
> > pinctrl-0 = <&pinctrl_cubox_i_pwm1>;
> >
> > front {
> > label = "imx6:red:front";
> > pwms = <&pwm1 0 50000>;
> > max-brightness = <248>;
> > };
> > };
> >
> > pwm1: pwm at 02080000 {
> > #pwm-cells = <2>;
> > compatible = "fsl,imx6q-pwm", "fsl,imx27-pwm";
> > reg = <0x02080000 0x4000>;
> > interrupts = <0 83 0x04>;
> > clocks = <&clks 62>, <&clks 145>;
> > clock-names = "ipg", "per";
> > };
> >
> > Yes, because iMX6 specifies #pwm-cells as 2, there's no flags able to
> > be specified in the pwms declaration in pwmleds. So that doesn't work.
> > There's no property to tell pwmleds that it should use inverted sense
> > either.
>
> Adding a property for active-low to the pwm-leds binding would be
> easy, and backwards compatible. I'm surprised the original binding
> didn't specify it. The leds-pwm driver already seems to support it for
> C-configured instances.
>
> I'm also surprised that the imx pwm driver even has a #pwm-cells of
> two, since the driver only supports one output. It'd be nice if they
> had allocated the extra cell for flags, but it's hard to change now,
> unless you do a new binding/compatible value and deprecate the old one.
>
> > Moreover, there's no way to specify a default brightness for the LED
> > in the absence of any trigger, so this results in the LED being fully
> > on.
>
> That seems to be missing from the led-pwm driver altogether, not just the DT
> bindings? Shouldn't be too bad to add a default-brightness property and plumb
> that up through the driver in this case.
>
> > So, something which _should_ be nice and simple is turned into a major
> > fuckup because of the total and utter crappiness that DT is and the
> > total misdesign that this shite is.
>
> It's not a major fuckup. None of the above is unfixable.
Indeed, and we already have a patch for this:
http://comments.gmane.org/gmane.linux.ports.arm.kernel/294823
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
next prev parent reply other threads:[~2014-01-20 7:21 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-19 16:49 PWM Russell King - ARM Linux
2014-01-19 16:49 ` PWM Russell King - ARM Linux
2014-01-19 19:03 ` PWM Olof Johansson
2014-01-19 19:03 ` PWM Olof Johansson
2014-01-19 19:08 ` PWM Arnd Bergmann
2014-01-19 19:08 ` PWM Arnd Bergmann
2014-01-19 19:11 ` PWM Olof Johansson
2014-01-19 19:11 ` PWM Olof Johansson
2014-01-19 19:30 ` PWM Russell King - ARM Linux
2014-01-19 19:30 ` PWM Russell King - ARM Linux
2014-01-19 20:26 ` PWM Arnd Bergmann
2014-01-19 20:26 ` PWM Arnd Bergmann
2014-01-19 23:33 ` PWM Olof Johansson
2014-01-19 23:33 ` PWM Olof Johansson
2014-01-20 0:14 ` PWM Simon Horman
2014-01-20 0:14 ` PWM Simon Horman
2014-01-20 7:24 ` PWM Sascha Hauer
2014-01-20 7:24 ` PWM Sascha Hauer
2014-01-20 16:11 ` PWM Mark Brown
2014-01-20 16:11 ` PWM Mark Brown
2014-01-21 0:39 ` PWM Simon Horman
2014-01-21 0:39 ` PWM Simon Horman
2014-01-20 7:21 ` Sascha Hauer [this message]
2014-01-20 7:21 ` PWM Sascha Hauer
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=20140120072102.GA19940@pengutronix.de \
--to=s.hauer@pengutronix.de \
--cc=arm@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-pwm@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=olof@lixom.net \
--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.