Author: avg
Date: Mon Oct 12 11:03:26 2020
New Revision: 366642
URL: https://svnweb.freebsd.org/changeset/base/366642
Log:
MFC r366142: aw_pwm: add a check and some comments related to long periods
The hardware supports periods as long as 196 seconds[*] when using the
maximal prescaling of 72000 and maximum cycle count of 2^16.
But the code becomes incorrect when the period length approaches 1 second.
That's because of things like NS_PER_SEC / period.
[*] At the same time I must note that the KPI provides for maximum
period of about 4 seconds (2^32 nanoseconds).
Modified:
stable/12/sys/arm/allwinner/aw_pwm.c
Directory Properties:
stable/12/ (props changed)
Modified: stable/12/sys/arm/allwinner/aw_pwm.c
==============================================================================
--- stable/12/sys/arm/allwinner/aw_pwm.c Mon Oct 12 11:01:54 2020
(r366641)
+++ stable/12/sys/arm/allwinner/aw_pwm.c Mon Oct 12 11:03:26 2020
(r366642)
@@ -259,6 +259,20 @@ aw_pwm_channel_config(device_t dev, u_int channel, u_i
period_freq = NS_PER_SEC / period;
if (period_freq > AW_PWM_MAX_FREQ)
return (EINVAL);
+
+ /*
+ * FIXME. The hardware is capable of sub-Hz frequencies, that is,
+ * periods longer than a second. But the current code cannot deal
+ * with those properly.
+ */
+ if (period_freq == 0)
+ return (EINVAL);
+
+ /*
+ * FIXME. There is a great loss of precision when the period and the
+ * duty are near 1 second. In some cases period_freq and duty_freq can
+ * be equal even if the period and the duty are significantly different.
+ */
duty_freq = NS_PER_SEC / duty;
if (duty_freq < period_freq) {
device_printf(sc->dev, "duty < period\n");
_______________________________________________
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
