svn commit: r366642 - stable/12/sys/arm/allwinner

[Andriy Gapon]

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");