From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Clemens Gruber <clemens.gruber@pqgruber.com>,
Thierry Reding <thierry.reding@gmail.com>
Cc: linux-pwm@vger.kernel.org, linux-kernel@vger.kernel.org,
Florian Vaussard <florian.vaussard@heig-vd.ch>,
Mika Westerberg <mika.westerberg@linux.intel.com>
Subject: Re: [PATCH 2/2] pwm: pca9685: fix prescaler initialization
Date: Thu, 19 Jan 2017 18:10:08 +0200 [thread overview]
Message-ID: <1484842208.2133.245.camel@linux.intel.com> (raw)
In-Reply-To: <20170119144925.GA1660@archie.localdomain>
On Thu, 2017-01-19 at 15:49 +0100, Clemens Gruber wrote:
> On Thu, Jan 19, 2017 at 02:34:39PM +0200, Andy Shevchenko wrote:
> > On Wed, 2017-01-18 at 15:25 +0100, Clemens Gruber wrote:
> > > Yes, that's what this patch tries to solve by verifying that the
> > > external setting (the prescale register) is set to its hardware
> > > default
> > > value of 0x1E (corresponding to a period of 1/200 Hz).
> > > If it is not 0x1E, the driver will reconfigure the prescaler
> > > according
> > > to the desired period at the time of the next configuration.
> >
> > Yes, and my question is what is possible go wrong if you just
> > enforce
> > prescaler to be 1/200Hz?
>
> If we enforce a default of 1 / 200 Hz, we have to go through the SLEEP
> mode and udelay for 0.5ms once for our default and then again for the
> user, if he does not want a period of 1 / 200 Hz.
> -> Number of prescaler changes: 1 or 2
>
> I think it is better as it is now + my patch applied: We verify if the
> prescaler is already set to 1 / 200 Hz.
> Then, as soon as the user configures his PWM channels, we either do
> not
> have to change the prescaler at all (if he wants 1 / 200 Hz) or do it
> once at the time of configuration.
> -> Number of prescaler changes: 0 or 1
>
> What's the advantage of enforcing the prescaler to 1 / 200 Hz in the
> probe function when we do not know yet if 1 / 200 Hz is the period the
> user is going to configure?
Advantage of this proposal is to get to known state.
Combining with your proposal I would see the best approach is to set
pca->period_ns accordingly to current prescaler value if you want to.
In your patch I see no benefit, since it's quite unlikely user will want
to have 5ms period among all possibilities.
The 500us delay at the _first_ configuration is not a big deal.
So, summarize, I prefer (in order of preference from high to low):
- enforce default prescaler value based on default period (it's just one
line to write a register)
- calculate default period based on actual prescaler value
- your or similar solution
If you still disagree with that, I rest my case.
--
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Intel Finland Oy
next prev parent reply other threads:[~2017-01-19 16:10 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-12-13 15:52 [PATCH 1/2] pwm: pca9685: fix period change with same duty cycle Clemens Gruber
2016-12-13 15:52 ` [PATCH 2/2] pwm: pca9685: fix prescaler initialization Clemens Gruber
2017-01-18 10:57 ` Thierry Reding
2017-01-18 11:09 ` Andy Shevchenko
2017-01-18 13:53 ` Clemens Gruber
2017-01-18 14:01 ` Andy Shevchenko
2017-01-18 14:25 ` Clemens Gruber
2017-01-19 12:34 ` Andy Shevchenko
2017-01-19 14:49 ` Clemens Gruber
2017-01-19 16:10 ` Andy Shevchenko [this message]
2017-01-19 16:52 ` Clemens Gruber
2017-01-19 16:58 ` Andy Shevchenko
2017-01-20 6:39 ` Thierry Reding
2017-01-20 9:58 ` Andy Shevchenko
2017-01-25 18:05 ` Clemens Gruber
2017-01-13 12:43 ` [PATCH 1/2] pwm: pca9685: fix period change with same duty cycle Clemens Gruber
2017-01-18 10:56 ` Thierry Reding
2017-01-18 11:09 ` Mika Westerberg
2017-01-20 6:44 ` 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=1484842208.2133.245.camel@linux.intel.com \
--to=andriy.shevchenko@linux.intel.com \
--cc=clemens.gruber@pqgruber.com \
--cc=florian.vaussard@heig-vd.ch \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pwm@vger.kernel.org \
--cc=mika.westerberg@linux.intel.com \
--cc=thierry.reding@gmail.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.