linux-pwm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Clemens Gruber <clemens.gruber@pqgruber.com>
To: "Thierry Reding" <thierry.reding@gmail.com>,
	"Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>,
	"Sven Van Asbroeck" <thesven73@gmail.com>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	linux-pwm@vger.kernel.org
Subject: Re: [PATCH v5 2/7] pwm: pca9685: Support hardware readout
Date: Sun, 3 Jan 2021 18:04:10 +0100	[thread overview]
Message-ID: <X/H5CqcRHelg5M4p@workstation.tuxnet> (raw)
In-Reply-To: <CAGngYiUYOL6EF3VTGwcwTuN4EmE26ML3ye7689FTEpowjEcU2w@mail.gmail.com>

Hi everyone,

happy new year, hope you are all well!

On Thu, Dec 17, 2020 at 12:52:42PM -0500, Sven Van Asbroeck wrote:
> On Thu, Dec 17, 2020 at 12:43 PM Clemens Gruber
> <clemens.gruber@pqgruber.com> wrote:
> > >
> > > Conclusion: .get_state() will always return "pwm disabled", so why do we
> > > bother reading out the h/w?
> >
> > If there are no plans for the PWM core to call .get_state more often in
> > the future, we could just read out the period and return 0 duty and
> > disabled.
> 
> I'm not sure why we should even read out the period?
> When a channel is disabled, the period is not externally visible,
> therefore it's meaningless ?
> 
> As far as I can tell, we can use this for .get_state():
> memset(&pwm->state, 0, sizeof(pwm_state));
> 
> >
> > Thierry, Uwe, what's your take on this?

I will continue working on this series in the upcoming weeks.
Feedback on the .get_state issue would be greatly appreciated.

To summarize:
Is it OK for a driver to expect the chip->ops->get_state function to be
only called from the place in pwm core it is currently called from?
(Namely in pwm_device_request after chip->ops->request)

If yes, we could always return a 0 duty cycle and disabled state,
because this is the state we left it in after .probe (and .free).

However, if in the future, the pwm core adds additional calls to
chip->ops->get_state in other places, this could lead to problems.

--

Another point is the period: Sven suggested we do not read out the
period at all, as the PWM is disabled anyway (see above).
Is this acceptable?

And, if we never return anything but 0 in .get_state, should it be
implemented at all?

> >
> > > Of course, if we choose to leave the pwm enabled after .free(), then
> > > .get_state() can even be left out! Do we want that? Genuine question, I do
> > > not know the answer.
> >
> > I do not think we should leave it enabled after free. It is less
> > complicated if we know that unrequested channels are not in use.
> >
> 
> Good point, I agree with you.

Thanks and best regards,
Clemens

  reply	other threads:[~2021-01-03 17:05 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20201216125320.5277-1-clemens.gruber@pqgruber.com>
     [not found] ` <20201216125320.5277-2-clemens.gruber@pqgruber.com>
2020-12-17  4:00   ` [PATCH v5 2/7] pwm: pca9685: Support hardware readout Sven Van Asbroeck
2020-12-17 17:43     ` Clemens Gruber
2020-12-17 17:52       ` Sven Van Asbroeck
2021-01-03 17:04         ` Clemens Gruber [this message]
2021-01-07 14:18           ` Sven Van Asbroeck
2021-01-11 20:43           ` Uwe Kleine-König
2021-03-22  8:34             ` Thierry Reding
2021-03-31 10:25               ` Uwe Kleine-König
2021-03-31 15:52                 ` Thierry Reding
2021-04-06  6:33                   ` Uwe Kleine-König
2021-04-06 13:47                     ` Thierry Reding
2021-04-06 20:44                       ` Uwe Kleine-König
2021-03-22  8:15           ` Thierry Reding
2021-01-11 20:35       ` Uwe Kleine-König
2021-01-14 17:16         ` Clemens Gruber
2021-01-14 18:05           ` Uwe Kleine-König
2021-03-22  8:53           ` Thierry Reding
2021-01-29 13:42         ` Sven Van Asbroeck
2021-01-29 16:31           ` Clemens Gruber
2021-01-29 18:05             ` Sven Van Asbroeck
2021-01-29 20:37               ` Clemens Gruber
2021-01-29 21:24                 ` Sven Van Asbroeck
2021-01-29 22:16                   ` Sven Van Asbroeck
2021-02-01 17:24                     ` Clemens Gruber
2021-03-01 21:52                       ` Uwe Kleine-König
2021-03-04 13:22                         ` Clemens Gruber
2021-02-14 14:46                 ` Clemens Gruber
2021-03-22  9:19                 ` Thierry Reding
2021-03-22  9:38                   ` Andy Shevchenko
2021-03-22 11:22                     ` Uwe Kleine-König
2021-03-22 11:40                       ` Andy Shevchenko
2021-03-22 11:48                         ` Uwe Kleine-König
2021-03-22 12:15                           ` Andy Shevchenko
2021-03-22 13:25                             ` Uwe Kleine-König
2021-03-27 16:05                   ` Clemens Gruber
2021-03-22  9:14               ` Thierry Reding
2021-03-22  8:47         ` Thierry Reding
2020-12-15 21:22 [PATCH v5 1/7] pwm: pca9685: Switch to atomic API Clemens Gruber
2020-12-15 21:22 ` [PATCH v5 2/7] pwm: pca9685: Support hardware readout Clemens Gruber

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=X/H5CqcRHelg5M4p@workstation.tuxnet \
    --to=clemens.gruber@pqgruber.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pwm@vger.kernel.org \
    --cc=thesven73@gmail.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).