From: Hans de Goede <hdegoede@redhat.com>
To: "Thierry Reding" <thierry.reding@gmail.com>,
"Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>,
"Jani Nikula" <jani.nikula@linux.intel.com>,
"Joonas Lahtinen" <joonas.lahtinen@linux.intel.com>,
"Ville Syrjälä" <ville.syrjala@linux.intel.com>,
"Rafael J . Wysocki" <rjw@rjwysocki.net>,
"Len Brown" <lenb@kernel.org>
Cc: Hans de Goede <hdegoede@redhat.com>,
linux-pwm@vger.kernel.org,
intel-gfx <intel-gfx@lists.freedesktop.org>,
dri-devel@lists.freedesktop.org,
Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
Mika Westerberg <mika.westerberg@linux.intel.com>,
linux-acpi@vger.kernel.org
Subject: [PATCH v3 07/15] pwm: crc: Fix off-by-one error in the clock-divider calculations
Date: Sat, 20 Jun 2020 14:17:50 +0200 [thread overview]
Message-ID: <20200620121758.14836-8-hdegoede@redhat.com> (raw)
In-Reply-To: <20200620121758.14836-1-hdegoede@redhat.com>
The CRC PWM controller has a clock-divider which divides the clock with
a value between 1-128. But as can seen from the PWM_DIV_CLK_xxx
defines, this range maps to a register value of 0-127.
So after calculating the clock-divider we must subtract 1 to get the
register value, unless the requested frequency was so high that the
calculation has already resulted in a (rounded) divider value of 0.
Note that before this fix, setting a period of PWM_MAX_PERIOD_NS which
corresponds to the max. divider value of 128 could have resulted in a
bug where the code would use 128 as divider-register value which would
have resulted in an actual divider value of 0 (and the enable bit being
set). A rounding error stopped this bug from actually happen. This
same rounding error means that after the subtraction of 1 it is impossible
to set the divider to 128. Also bump PWM_MAX_PERIOD_NS by 1 ns to allow
setting a divider of 128 (register-value 127).
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
Changes in v3:
- Introduce crc_pwm_calc_clk_div() here instead of later in the patch-set
to reduce the amount of churn in the patch-set a bit
---
drivers/pwm/pwm-crc.c | 17 ++++++++++++++---
1 file changed, 14 insertions(+), 3 deletions(-)
diff --git a/drivers/pwm/pwm-crc.c b/drivers/pwm/pwm-crc.c
index c056eb9b858c..44ec7d5b63e1 100644
--- a/drivers/pwm/pwm-crc.c
+++ b/drivers/pwm/pwm-crc.c
@@ -22,7 +22,7 @@
#define PWM_MAX_LEVEL 0xFF
#define PWM_BASE_CLK_MHZ 6 /* 6 MHz */
-#define PWM_MAX_PERIOD_NS 5461333 /* 183 Hz */
+#define PWM_MAX_PERIOD_NS 5461334 /* 183 Hz */
/**
* struct crystalcove_pwm - Crystal Cove PWM controller
@@ -39,6 +39,18 @@ static inline struct crystalcove_pwm *to_crc_pwm(struct pwm_chip *pc)
return container_of(pc, struct crystalcove_pwm, chip);
}
+static int crc_pwm_calc_clk_div(int period_ns)
+{
+ int clk_div;
+
+ clk_div = PWM_BASE_CLK_MHZ * period_ns / (256 * NSEC_PER_USEC);
+ /* clk_div 1 - 128, maps to register values 0-127 */
+ if (clk_div > 0)
+ clk_div--;
+
+ return clk_div;
+}
+
static int crc_pwm_enable(struct pwm_chip *c, struct pwm_device *pwm)
{
struct crystalcove_pwm *crc_pwm = to_crc_pwm(c);
@@ -68,11 +80,10 @@ static int crc_pwm_config(struct pwm_chip *c, struct pwm_device *pwm,
}
if (pwm_get_period(pwm) != period_ns) {
- int clk_div;
+ int clk_div = crc_pwm_calc_clk_div(period_ns);
/* changing the clk divisor, need to disable fisrt */
crc_pwm_disable(c, pwm);
- clk_div = PWM_BASE_CLK_MHZ * period_ns / (256 * NSEC_PER_USEC);
regmap_write(crc_pwm->regmap, PWM0_CLK_DIV,
clk_div | PWM_OUTPUT_ENABLE);
--
2.26.2
next prev parent reply other threads:[~2020-06-20 12:19 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-20 12:17 [PATCH v3 00/15] acpi/pwm/i915: Convert pwm-crc and i915 driver's PWM code to use the atomic PWM API Hans de Goede
2020-06-20 12:17 ` [PATCH v3 01/15] ACPI / LPSS: Resume Cherry Trail PWM controller in no-irq phase Hans de Goede
2020-06-22 16:03 ` Rafael J. Wysocki
2020-06-20 12:17 ` [PATCH v3 02/15] ACPI / LPSS: Save Cherry Trail PWM ctx registers only once (at activation) Hans de Goede
2020-06-22 16:04 ` Rafael J. Wysocki
2020-06-20 12:17 ` [PATCH v3 03/15] pwm: lpss: Fix off by one error in base_unit math in pwm_lpss_prepare() Hans de Goede
2020-06-22 7:25 ` Uwe Kleine-König
2020-06-20 12:17 ` [PATCH v3 04/15] pwm: lpss: Add range limit check for the base_unit register value Hans de Goede
2020-06-22 7:35 ` Uwe Kleine-König
2020-07-06 20:53 ` Hans de Goede
2020-07-07 7:34 ` Uwe Kleine-König
2020-07-07 8:04 ` Hans de Goede
2020-07-07 17:31 ` Hans de Goede
2020-07-07 19:09 ` Uwe Kleine-König
2020-07-07 19:41 ` Hans de Goede
2020-06-20 12:17 ` [PATCH v3 05/15] pwm: lpss: Use pwm_lpss_apply() when restoring state on resume Hans de Goede
2020-06-20 12:17 ` [PATCH v3 06/15] pwm: crc: Fix period / duty_cycle times being off by a factor of 256 Hans de Goede
2020-06-20 12:17 ` Hans de Goede [this message]
2020-06-20 12:17 ` [PATCH v3 08/15] pwm: crc: Fix period changes not having any effect Hans de Goede
2020-06-20 12:17 ` [PATCH v3 09/15] pwm: crc: Enable/disable PWM output on enable/disable Hans de Goede
2020-06-22 7:55 ` Uwe Kleine-König
2020-07-06 21:03 ` Hans de Goede
2020-07-07 7:26 ` Uwe Kleine-König
2020-06-20 12:17 ` [PATCH v3 10/15] pwm: crc: Implement apply() method to support the new atomic PWM API Hans de Goede
2020-06-20 12:17 ` [PATCH v3 11/15] pwm: crc: Implement get_state() method Hans de Goede
2020-06-22 7:57 ` Uwe Kleine-König
2020-07-06 21:05 ` Hans de Goede
2020-07-07 7:24 ` Uwe Kleine-König
2020-06-20 12:17 ` [PATCH v3 12/15] drm/i915: panel: Add get_vbt_pwm_freq() helper Hans de Goede
2020-06-20 12:17 ` [PATCH v3 13/15] drm/i915: panel: Honor the VBT PWM frequency for devs with an external PWM controller Hans de Goede
2020-06-20 12:17 ` [PATCH v3 14/15] drm/i915: panel: Honor the VBT PWM min setting " Hans de Goede
2020-06-20 12:17 ` [PATCH v3 15/15] drm/i915: panel: Use atomic PWM API " Hans de Goede
2020-07-07 7:50 ` Uwe Kleine-König
2020-07-07 19:21 ` Hans de Goede
2020-06-30 13:51 ` [PATCH v3 00/15] acpi/pwm/i915: Convert pwm-crc and i915 driver's PWM code to use the atomic PWM API Jani Nikula
2020-07-06 20:53 ` Hans de Goede
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=20200620121758.14836-8-hdegoede@redhat.com \
--to=hdegoede@redhat.com \
--cc=andriy.shevchenko@linux.intel.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=jani.nikula@linux.intel.com \
--cc=joonas.lahtinen@linux.intel.com \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-pwm@vger.kernel.org \
--cc=mika.westerberg@linux.intel.com \
--cc=rjw@rjwysocki.net \
--cc=thierry.reding@gmail.com \
--cc=u.kleine-koenig@pengutronix.de \
--cc=ville.syrjala@linux.intel.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).