LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Wesley Terpstra <wesley@sifive.com>
To: Thierry Reding <thierry.reding@gmail.com>
Cc: "Rob Herring" <robh+dt@kernel.org>,
"Mark Rutland" <mark.rutland@arm.com>,
"Andreas Färber" <afaerber@suse.de>,
"Noralf Trønnes" <noralf@tronnes.org>,
"David Lechner" <david@lechnology.com>,
"Alexandre Belloni" <alexandre.belloni@free-electrons.com>,
"SZ Lin" <sz.lin@moxa.com>,
linux-pwm@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/3] dt-bindings: added new pwm-sifive driver documentation
Date: Mon, 30 Apr 2018 12:09:29 -0700 [thread overview]
Message-ID: <CAMgXwThTd32cyEBcbGnYw72x-P9_P8ks2J6QJV69RUUUDsT+3A@mail.gmail.com> (raw)
In-Reply-To: <20180430082750.GI2484@ulmo>
On Mon, Apr 30, 2018 at 1:27 AM, Thierry Reding
<thierry.reding@gmail.com> wrote:
> I don't like the idea of specifying something in DT that is completely
> approximate because it doesn't give users any kind of control over what
> is considered acceptable. In some cases an approximation to within 10%
> might be acceptable, in other cases users may only want to allow 5%. In
> this case there's even no way to catch or report a deviation from the
> desired value.
My view was that you basically don't have period control on this IP.
You can give it a target that it tries to get as close to as possible,
but there's no guarantee of any kind wrt. the period.
I saw there were a couple other PWM drivers which had no period
control whatsoever. They just allowed duty cycle control. Because this
IP has such a broken period-control interface, I was essentially
trying to bin it in the same category as those drivers.
Perhaps I should just remove all pretense of supporting period and
just always default to the fastest period possible?
> How about you allow users to specify a valid frequency range with
> something like:
>
> frequency-range = <MIN MAX>;
>
> or
>
> period-range = <MIN MAX>;
Ok, but now you have to define what happens if a clock change prevents
you from staying within this range.
Rejecting the clock frequency change does not seem a good option for
the actual SoC for which I wrote this driver. There, all the PWM does
is drive an LED bank and clock changes are used to change the core
frequency.
> you could disable the PWM if it was fed with an invalid range.
Is that really desirable behavior? If the period is defined as being
best effort for this PWM IP, which is essentially what I've done, it's
clear you want the PWM to continue to operate. That's certainly the
behavior I want on the actual SoC with this IP.
I'll make all the DTS changes you guys suggested. ie: "-v0", clarified
clocks description, and remove unused interrupts comment.
next prev parent reply other threads:[~2018-04-30 19:09 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-27 22:59 [PATCH 0/3] SiFive SoC PWM driver Wesley W. Terpstra
2018-04-27 22:59 ` [PATCH 1/3] dt-bindings: added new pwm-sifive driver documentation Wesley W. Terpstra
2018-04-29 5:54 ` Thierry Reding
2018-04-29 20:51 ` Wesley Terpstra
2018-04-29 21:01 ` Andreas Färber
2018-04-29 21:08 ` Wesley Terpstra
2018-04-30 8:19 ` Thierry Reding
2018-04-30 10:45 ` Andreas Färber
2018-05-01 16:11 ` Rob Herring
2018-04-30 8:27 ` Thierry Reding
2018-04-30 19:09 ` Wesley Terpstra [this message]
2018-04-30 9:42 ` Thierry Reding
2018-04-27 22:59 ` [PATCH 2/3] dt-bindings: Add "sifive" vendor prefix Wesley W. Terpstra
2018-04-28 11:21 ` Andreas Färber
[not found] ` <CAMgXwThXvdzi27GjTD-q4Fw7kM5WOCtMewh7U3M4wcLwEx+VQw@mail.gmail.com>
2018-05-01 16:14 ` Rob Herring
2018-05-01 16:32 ` Palmer Dabbelt
2018-04-27 22:59 ` [PATCH 3/3] pwm-sifive: add a driver for SiFive SoC PWM Wesley W. Terpstra
2018-04-30 9:39 ` Thierry Reding
2018-04-30 19:09 ` Wesley Terpstra
2018-05-04 8:43 ` kbuild test robot
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=CAMgXwThTd32cyEBcbGnYw72x-P9_P8ks2J6QJV69RUUUDsT+3A@mail.gmail.com \
--to=wesley@sifive.com \
--cc=afaerber@suse.de \
--cc=alexandre.belloni@free-electrons.com \
--cc=david@lechnology.com \
--cc=devicetree@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pwm@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=noralf@tronnes.org \
--cc=robh+dt@kernel.org \
--cc=sz.lin@moxa.com \
--cc=thierry.reding@gmail.com \
--subject='Re: [PATCH 1/3] dt-bindings: added new pwm-sifive driver documentation' \
/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
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).