From: "Roman Beranek" <roman.beranek@prusa3d.cz>
To: "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>
Cc: "Thierry Reding" <thierry.reding@gmail.com>,
"Lee Jones" <lee.jones@linaro.org>,
"Maxime Ripard" <mripard@kernel.org>,
"Chen-Yu Tsai" <wens@csie.org>,
"Jernej Skrabec" <jernej.skrabec@siol.net>,
<linux-pwm@vger.kernel.org>,
<linux-arm-kernel@lists.infradead.org>,
<linux-sunxi@lists.linux.dev>, <linux-sunxi@googlegroups.com>,
"Roman Beranek" <roman.beranek@prusa3d.com>
Subject: Re: [PATCH] pwm: sun4i: Round delay time up to a nearest jiffy
Date: Fri, 30 Apr 2021 09:17:49 +0200 [thread overview]
Message-ID: <CB0VI785HYEE.3PXPB7BDOUPFC@zen.local> (raw)
In-Reply-To: <20210430064145.nzlcw3lpayzapnbx@pengutronix.de>
Hello Uwe,
On Fri Apr 30, 2021 at 8:41 AM CEST, Uwe Kleine-König wrote:
> On Fri, Apr 30, 2021 at 04:19:32AM +0200, Roman Beránek wrote:
> > On Thu, Apr 29, 2021 at 2:04 PM Uwe Kleine-König wrote:
> > > On Wed, Apr 28, 2021 at 02:14:31PM +0200, Roman Beránek wrote:
> > > > Correct, the output may stay in an active state. I only discovered this
> > > > bug as I investigated a report of unreliable screen timeout. The period
> > > > we use the PWM with is 50 us.
> > >
> > > What I don't like here is that the delay is quite coarse and might still
> > > be too short. (Maybe I miss something, but consider the current period
> > > is quite long, then you configure a short one and then disable. In this
> > > case the inital long setting might still be active.)
> >
> > The delay is calculated from the original period (cstate.period),
> > not the one that was just written into PWM_CHx_PRD 2 lines above.
>
> Yes, but that's not good enough. Consider the PWM is running with a
> period of 4s and the period just started. Then you call
>
> pwm_apply_state(mypwm, &(struct pwm_state){
> .period = 20,
> .enabled = 1,
> ...
> })
>
> This doesn't result into the waiting code being run, because
> .enabled = 1. Then immidiately after that call:
>
> pwm_apply_state(mypwm, &(struct pwm_state){
> .period = 20,
> .enabled = 0,
> ...
> })
>
> which triggers the waiting but only based on a period of 20 ns while the
> 4s period is still active.
OK, now I see what you mean. To remedy this, the delay shall occur
regardless of state->enabled.
In my view, this lies beneath the scope of the patch though and would be
better served as a follow-up.
Cheers,
Roman
next prev parent reply other threads:[~2021-04-30 8:47 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-28 0:19 [PATCH] pwm: sun4i: Round delay time up to a nearest jiffy Roman Beranek
2021-04-28 6:13 ` Uwe Kleine-König
2021-04-28 12:07 ` Roman Beránek
2021-04-28 12:14 ` Roman Beránek
2021-04-29 12:04 ` Uwe Kleine-König
2021-04-30 2:19 ` Roman Beránek
2021-04-30 6:41 ` Uwe Kleine-König
2021-04-30 7:17 ` Roman Beranek [this message]
2021-04-30 9:51 ` Uwe Kleine-König
2021-04-30 15:10 ` Roman Beranek
2021-04-30 16:18 ` [linux-sunxi] " dev
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=CB0VI785HYEE.3PXPB7BDOUPFC@zen.local \
--to=roman.beranek@prusa3d.cz \
--cc=jernej.skrabec@siol.net \
--cc=lee.jones@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-pwm@vger.kernel.org \
--cc=linux-sunxi@googlegroups.com \
--cc=linux-sunxi@lists.linux.dev \
--cc=mripard@kernel.org \
--cc=roman.beranek@prusa3d.com \
--cc=thierry.reding@gmail.com \
--cc=u.kleine-koenig@pengutronix.de \
--cc=wens@csie.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 read-only IMAP folder(s) and NNTP newsgroup(s).