From: Thierry Reding <thierry.reding@gmail.com>
To: Lokesh Vutla <lokeshvutla@ti.com>
Cc: "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>,
"Tony Lindgren" <tony@atomide.com>,
"Linux OMAP Mailing List" <linux-omap@vger.kernel.org>,
linux-kernel@vger.kernel.org, linux-pwm@vger.kernel.org,
"Sekhar Nori" <nsekhar@ti.com>, "Vignesh R" <vigneshr@ti.com>
Subject: Re: [PATCH v3 4/5] pwm: omap-dmtimer: Do not disable pwm before changing period/duty_cycle
Date: Tue, 31 Mar 2020 22:10:14 +0200 [thread overview]
Message-ID: <20200331201014.GA2954599@ulmo> (raw)
In-Reply-To: <638d7136-6a74-8069-5331-b2248c948ed4@ti.com>
[-- Attachment #1: Type: text/plain, Size: 2710 bytes --]
On Tue, Mar 31, 2020 at 08:59:47PM +0530, Lokesh Vutla wrote:
> Hi Thierry,
>
> On 30/03/20 7:44 PM, Thierry Reding wrote:
> > On Thu, Mar 12, 2020 at 07:40:42AM +0100, Uwe Kleine-König wrote:
> >> On Thu, Mar 12, 2020 at 09:52:09AM +0530, Lokesh Vutla wrote:
> >>> Only the Timer control register(TCLR) cannot be updated when the timer
> >>> is running. Registers like Counter register(TCRR), loader register(TLDR),
> >>> match register(TMAR) can be updated when the counter is running. Since
> >>> TCLR is not updated in pwm_omap_dmtimer_config(), do not stop the
> >>> timer for period/duty_cycle update.
> >>
> >> I'm not sure what is sensible here. Stopping the PWM for a short period
> >> is bad, but maybe emitting a wrong period isn't better. You can however
> >> optimise it if only one of period or duty_cycle changes.
> >>
> >> @Thierry, what is your position here? I tend to say a short stop is
> >> preferable.
> >
> > It's not clear to me from the above description how exactly the device
> > behaves, but I suspect that it may latch the values in those registers
> > and only update the actual signal output once a period has finished. I
> > know of a couple of other devices that do that, so it wouldn't be
> > surprising.
> >
> > Even if that was not the case, I think this is just the kind of thing
> > that we have to live with. Sometimes it just isn't possible to have all
> > supported devices adhere strictly to an API. So I think the best we can
> > do is have an API that loosely defines what's supposed to happen and
> > make a best effort to implement those semantics. If a device deviates
> > slightly from those expectations, we can always cross fingers and hope
> > that things still work. And it looks like they are.
> >
> > So I think if Lokesh and Tony agree that this is the right thing to do
> > and have verified that things still work after this, that's about as
> > good as it's going to get.
>
> Yes this is needed especially in the use-case[0] that I am trying to enable
> using PWM. In this case PWM cannot be stopped in between and needs to be updated
> dynamically. Also hardware doesn't provide any restrictions on updating the
> period. So IMHO, this might be the right thing to do.
>
> Tony did provide tested-by and I measured PWM signals on scope with these
> changes. Let me know if any thing else is required?
>
> [0] https://sourceforge.net/p/linuxptp/mailman/message/36943248/
From you measurements, can you tell whether or not the signal actually
gets updated in the middle of a period, or does it only get updated at
the end of a full period?
Does the reference manual document this?
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2020-03-31 20:10 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-12 4:22 [PATCH v3 0/5] pwm: omap-dmtimer: Allow for dynamic pwm period updates Lokesh Vutla
2020-03-12 4:22 ` [PATCH v3 1/5] pwm: omap-dmtimer: Drop unused header file Lokesh Vutla
2020-03-12 6:35 ` Uwe Kleine-König
2020-03-12 4:22 ` [PATCH v3 2/5] pwm: omap-dmtimer: Update description for pwm omap dm timer Lokesh Vutla
2020-03-12 6:35 ` Uwe Kleine-König
2020-03-12 4:22 ` [PATCH v3 3/5] pwm: omap-dmtimer: Fix pwm enabling sequence Lokesh Vutla
2020-03-12 4:22 ` [PATCH v3 4/5] pwm: omap-dmtimer: Do not disable pwm before changing period/duty_cycle Lokesh Vutla
2020-03-12 6:40 ` Uwe Kleine-König
2020-03-12 8:05 ` Lokesh Vutla
2020-03-12 8:47 ` Uwe Kleine-König
2020-03-12 10:44 ` Lokesh Vutla
2020-03-12 14:21 ` Richard Cochran
2020-03-12 17:14 ` Lokesh Vutla
2020-03-18 4:40 ` Lokesh Vutla
2020-03-30 14:14 ` Thierry Reding
2020-03-30 19:16 ` Uwe Kleine-König
2020-03-31 20:45 ` Thierry Reding
2020-04-01 8:22 ` Uwe Kleine-König
2020-04-01 10:22 ` Lokesh Vutla
2020-04-01 11:47 ` Uwe Kleine-König
2020-04-01 18:39 ` Thierry Reding
2020-04-01 20:36 ` Uwe Kleine-König
2020-04-01 18:28 ` Thierry Reding
2020-04-01 20:31 ` Uwe Kleine-König
2020-04-01 21:37 ` Thierry Reding
2020-04-02 14:02 ` Uwe Kleine-König
2020-04-03 8:51 ` Lokesh Vutla
2020-04-03 13:59 ` Uwe Kleine-König
2020-03-31 15:29 ` Lokesh Vutla
2020-03-31 20:10 ` Thierry Reding [this message]
2020-04-01 10:15 ` Lokesh Vutla
2020-03-12 4:22 ` [PATCH v3 5/5] pwm: omap-dmtimer: Implement .apply callback Lokesh Vutla
2020-03-13 15:31 ` Tony Lindgren
2020-03-23 11:30 ` [PATCH v3 0/5] pwm: omap-dmtimer: Allow for dynamic pwm period updates Lokesh Vutla
2020-03-30 14:04 ` Thierry Reding
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=20200331201014.GA2954599@ulmo \
--to=thierry.reding@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=linux-pwm@vger.kernel.org \
--cc=lokeshvutla@ti.com \
--cc=nsekhar@ti.com \
--cc=tony@atomide.com \
--cc=u.kleine-koenig@pengutronix.de \
--cc=vigneshr@ti.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 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).