From: Tony Lindgren <tony@atomide.com>
To: Lokesh Vutla <lokeshvutla@ti.com>
Cc: "Thierry Reding" <thierry.reding@gmail.com>,
"Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>,
"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>,
"Sebastian Reichel" <sre@kernel.org>
Subject: Re: [PATCH v2 4/6] pwm: omap-dmtimer: Fix pwm disabling sequence
Date: Tue, 10 Mar 2020 08:52:42 -0700 [thread overview]
Message-ID: <20200310155242.GT37466@atomide.com> (raw)
In-Reply-To: <666dbb7a-db98-d16a-ee73-27d353d2a317@ti.com>
* Lokesh Vutla <lokeshvutla@ti.com> [200310 07:06]:
> Hi Tony,
>
> [...snip...]
>
> >>>>
> >>>> + /*
> >>>> + * Disable auto reload so that the current cycle gets completed and
> >>>> + * then the counter stops.
> >>>> + */
> >>>> mutex_lock(&omap->mutex);
> >>>> - omap->pdata->stop(omap->dm_timer);
> >>>> + omap->pdata->set_pwm(omap->dm_timer,
> >>>> + pwm_get_polarity(pwm) == PWM_POLARITY_INVERSED,
> >>>> + true, OMAP_TIMER_TRIGGER_OVERFLOW_AND_COMPARE,
> >>>> + false);
> >>>> +
> >>>> mutex_unlock(&omap->mutex);
> >>>> }
> >>>
> >>> I'm seeing an issue with this patch where after use something is
> >>> left on and power consumption stays higher by about 30 mW after
> >>> use.
> >>
> >> Interesting...What is the PWM period and duty cycle in the test case?
> >> Can you dump the following registers before and after disabling:
> >> - TLDR
> >> - TMAR
> >> - TCLR
> >
> > Here's the state dumped before and after in omap_dm_timer_set_pwm():
> >
> > omap_timer 4803e000.timer: XXX set_pwm before: tldr: fffffeb8 tmar: fffffffe tclr: 00000040
> > omap_timer 4803e000.timer: XXX set_pwm after: tldr: fffffeb8 tmar: fffffffe tclr: 00001842
> > omap_timer 4013e000.timer: XXX set_pwm before: tldr: fffffeb8 tmar: fffffffe tclr: 00000040
> > omap_timer 4013e000.timer: XXX set_pwm after: tldr: fffffeb8 tmar: fffffffe tclr: 00001842
> > omap_timer 4013e000.timer: XXX set_pwm before: tldr: fffffeb8 tmar: fffffffe tclr: 00001843
> > omap_timer 4013e000.timer: XXX set_pwm after: tldr: fffffeb8 tmar: fffffffe tclr: 00001841
> > omap_timer 4803e000.timer: XXX set_pwm before: tldr: fffffeb8 tmar: fffffffe tclr: 00001843
> > omap_timer 4803e000.timer: XXX set_pwm after: tldr: fffffeb8 tmar: fffffffe tclr: 00001841
> >
>
> Looking at the registers:
> period = 327 *(1000/clk_freq in MHz) ns
> duty_cycle = perioid.
>
> I did simulate this behavior on BeagleBoneBlack on timer7. PWM is going down
> after disabling.
>
> > So looks like the start bit is still enabled after use?
>
> Right, that is expected. The start bit gets disabled automatically once the pwm
> period completes. This is because auto reload bit is off. That's the main idea
> of this patch so that PWM period is completed after disabling, else PWM is
> stopped abruptly.
OK
> Not sure why it is not happening in your case. If you think it is not needed, I
> can drop this patch and add a limitation saying that PWM gets disabled
> immediately without completing the current cycle.
Could it be that we now have the cpu_pm notifier restore something
invalid after exiting idle that restarts the counter?
Regards,
Tony
next prev parent reply other threads:[~2020-03-10 15:52 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-28 9:56 [PATCH v2 0/5] pwm: omap-dmtimer: Allow for dynamic pwm period updates Lokesh Vutla
2020-02-28 9:56 ` Lokesh Vutla
2020-02-28 9:56 ` [PATCH v2 1/6] pwm: omap-dmtimer: Drop unused header file Lokesh Vutla
2020-02-28 9:56 ` Lokesh Vutla
2020-03-06 18:03 ` Tony Lindgren
2020-02-28 9:56 ` [PATCH v2 2/6] pwm: omap-dmtimer: Update description for pwm omap dm timer Lokesh Vutla
2020-02-28 9:56 ` Lokesh Vutla
2020-03-06 18:03 ` Tony Lindgren
2020-02-28 9:56 ` [PATCH v2 3/6] pwm: omap-dmtimer: Fix pwm enabling sequence Lokesh Vutla
2020-02-28 9:56 ` Lokesh Vutla
2020-03-06 18:04 ` Tony Lindgren
2020-02-28 9:56 ` [PATCH v2 4/6] pwm: omap-dmtimer: Fix pwm disabling sequence Lokesh Vutla
2020-02-28 9:56 ` Lokesh Vutla
2020-03-06 18:14 ` Tony Lindgren
2020-03-09 4:51 ` Lokesh Vutla
2020-03-09 12:30 ` Sebastian Reichel
2020-03-09 18:01 ` Tony Lindgren
2020-03-10 7:04 ` Lokesh Vutla
2020-03-10 15:52 ` Tony Lindgren [this message]
2020-03-11 4:12 ` Lokesh Vutla
2020-03-12 0:58 ` Tony Lindgren
2020-03-13 15:34 ` Tony Lindgren
2020-03-13 15:50 ` Tony Lindgren
2020-02-28 9:56 ` [PATCH v2 5/6] pwm: omap-dmtimer: Do not disable pwm before changing period/duty_cycle Lokesh Vutla
2020-02-28 9:56 ` Lokesh Vutla
2020-03-06 18:17 ` Tony Lindgren
2020-02-28 9:56 ` [PATCH v2 6/6] pwm: omap-dmtimer: Implement .apply callback Lokesh Vutla
2020-02-28 9:56 ` Lokesh Vutla
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=20200310155242.GT37466@atomide.com \
--to=tony@atomide.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=sre@kernel.org \
--cc=thierry.reding@gmail.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 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.