From: Sean Young <sean@mess.org>
To: "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>
Cc: Lino Sanfilippo <LinoSanfilippo@gmx.de>,
thierry.reding@gmail.com, lee.jones@linaro.org,
nsaenzjulienne@suse.de, f.fainelli@gmail.com, rjui@broadcom.com,
sbranden@broadcom.com, bcm-kernel-feedback-list@broadcom.com,
linux-pwm@vger.kernel.org, linux-rpi-kernel@lists.infradead.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] pwm: bcm2835: Support apply function for atomic configuration
Date: Mon, 7 Dec 2020 09:43:20 +0000 [thread overview]
Message-ID: <20201207094320.GA10460@gofer.mess.org> (raw)
In-Reply-To: <20201207081628.tm3yg7az5k5sbivu@pengutronix.de>
Hello Uwe,
Thank you for taking the time to explain your thinking.
On Mon, Dec 07, 2020 at 09:16:28AM +0100, Uwe Kleine-König wrote:
> On Sun, Dec 06, 2020 at 02:19:41PM +0000, Sean Young wrote:
> > On Sat, Dec 05, 2020 at 08:25:10PM +0100, Uwe Kleine-König wrote:
> > > On Sat, Dec 05, 2020 at 05:34:44PM +0000, Sean Young wrote:
> > > > What real life uses-cases are there for round down? If you want to round
> > > > down, is there any need for round up?
> > >
> > > The scenario I have in mind is for driving a motor. I have to admit
> > > however that usually the period doesn't matter much and it's the
> > > duty_cycle that defines the motor's speed. So for this case the
> > > conservative behaviour is round-down to not make the motor run faster
> > > than expected.
> >
> > I am reading here that for driving motors, only the duty cycle matters,
> > not the period.
>
> There is an upper limit (usually around 1 ms) for the period, but if you
> choose 0.1 ms or 0.001 ms doesn't matter much AFAICT.
>
> @Thierry: Do you have further use cases in mind?
>
> > > For other usecases (fan, backlight, LED) exactness typically doesn't
> > > matter that much.
> >
> > So, the use-cases you have are driving motor, fan, backlight, and led.
> > And in all these cases the exact Hz does not matter.
> >
> > The only uses case where the exact Hz does matter is pwm-ir-tx.
> >
> > So, I gather there are no use-cases for round-down. Yes, should round-down
> > be needed, then this is more difficult to implement if the driver always
> > does a round-closest. But, since there is no reason to have round-down,
> > this is all academic.
> >
> > Your policy of forcing new pwm drivers to use round-down is breaking
> > pwm-ir-tx.
>
> So you're indeed suggesting that the "right" rounding strategy for
> lowlevel drivers should be:
>
> - Use the period length closest to the requested period (in doubt round
> down?)
> - With the chosen period length use the biggest duty_cycle not bigger
> than the requested duty_cycle.
>
> While this seems technically fine I think for maintenance this is a
> nightmare.
>
> My preference would be to stick to the rounding strategy we used so far
> (i.e.:
>
> - Use the biggest period length not bigger than the requested period
> - With the chosen period length use the biggest duty_cycle not bigger
> than the requested duty_cycle.
>
> ) and for pwm-ir-tx add support to the PWM API to still make it possible
> (and easy) to select the best setting.
>
> The reasons why I think that this rounding-down strategy is the best
> are (in order of importance):
>
> - It is easier to implement correctly [1]
Yes, you are right. You have given a great example where a simple
DIV_ROUND_CLOSEST() does not give the result you want.
> - Same rounding method for period and duty cycle
> - most drivers already do this (I think)
>
> The (IMHO nice) result would then mean:
>
> - All consumers can get the setting they want; and
Once there is a nice pwm api for selecting round-nearest, then yes.
For the uses cases you've given, fan, backlight, and led a round-nearest
is the rounding they would want, I would expect.
> - Code in lowlevel drivers is simple and the complexity is in common
> code and so a single place.
>
> And it would also allow the pwm-ir-tx driver to notice if the PWM to be
> used can for example only support frequencies under 400 kHz.
I doubt pwm-ir-tx cares about this, however it is a nice-to-have. It would
also be nice if the rounding could be used with atomic configuration
as well.
Please let me know when/if this new API exists for pwm so that pwm-ir-tx
can select the right rounding.
> [1] Consider a PWM with a parent frequency of 66 MHz, to select the
> period you can pick an integer divider "div" resulting in the period
> 4096 / (pclk * d). So the obvious implementation for round-nearest
> would be:
>
> pclk = clk_get_rate(myclk);
> div = DIV_ROUND_CLOSEST(NSEC_PER_SEC * 4096, targetperiod * pclk);
Note NSEC_PER_SEC * 4096 >> 2^32 so this would need to be
DIV_ROUND_CLOSEST_ULL.
> , right?
>
> With targetperiod = 2641 ns this picks div = 23 and so a period of
> 2698.2872200263505 ns (delta = 57.2872200263505 ns).
> The optimal divider however is div = 24. (implemented period =
> 2585.8585858585857 ns, delta = 55.14141414141448 ns)
>
> For round-down the correct implementation is:
>
> pclk = clk_get_rate(myclk);
> div = DIV_ROUND_UP(NSEC_PER_SEC * 4096, targetperiod * pclk);
>
> Exercise for the reader: Come up with a correct implementation for
> "round-nearest" and compare its complexity to the round-down code.
To be fair, I haven't been been able to come up with a solution without
control flow.
Thank you for an interesting conversation about this.
Sean
next prev parent reply other threads:[~2020-12-07 9:44 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <202011281128.54eLfMWr-lkp@intel.com>
2020-11-28 12:02 ` [PATCH v2] pwm: bcm2835: Support apply function for atomic configuration Lino Sanfilippo
2020-11-29 18:10 ` Uwe Kleine-König
2020-12-03 23:42 ` Lino Sanfilippo
2020-12-04 8:44 ` Sean Young
2020-12-04 8:58 ` Sean Young
2020-12-04 11:13 ` Uwe Kleine-König
2020-12-04 11:38 ` Sean Young
2020-12-04 23:28 ` Uwe Kleine-König
2020-12-05 17:34 ` Sean Young
2020-12-05 19:25 ` Uwe Kleine-König
2020-12-06 14:19 ` Sean Young
2020-12-07 8:16 ` Uwe Kleine-König
2020-12-07 9:43 ` Sean Young [this message]
2020-12-07 13:52 ` Uwe Kleine-König
2020-12-07 15:29 ` Thierry Reding
2020-12-07 21:46 ` Uwe Kleine-König
2020-12-07 18:18 ` Sean Young
2020-12-08 0:00 ` Lino Sanfilippo
2020-12-08 9:07 ` Uwe Kleine-König
2020-12-04 23:16 ` Lino Sanfilippo
2020-12-04 11:21 ` Uwe Kleine-König
2020-12-04 11:40 ` Sean Young
2020-12-04 21:55 ` Uwe Kleine-König
2020-12-04 22:44 ` Sean Young
2020-12-04 23:25 ` Lino Sanfilippo
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=20201207094320.GA10460@gofer.mess.org \
--to=sean@mess.org \
--cc=LinoSanfilippo@gmx.de \
--cc=bcm-kernel-feedback-list@broadcom.com \
--cc=f.fainelli@gmail.com \
--cc=lee.jones@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pwm@vger.kernel.org \
--cc=linux-rpi-kernel@lists.infradead.org \
--cc=nsaenzjulienne@suse.de \
--cc=rjui@broadcom.com \
--cc=sbranden@broadcom.com \
--cc=thierry.reding@gmail.com \
--cc=u.kleine-koenig@pengutronix.de \
/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).