svn commit: r366142 - head/sys/arm/allwinner

[Andriy Gapon]

Author: avg
Date: Fri Sep 25 07:41:51 2020
New Revision: 366142
URL: https://svnweb.freebsd.org/changeset/base/366142

Log:
  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).
  
  MFC after:	2 weeks

Modified:
  head/sys/arm/allwinner/aw_pwm.c

Modified: head/sys/arm/allwinner/aw_pwm.c
==============================================================================
--- head/sys/arm/allwinner/aw_pwm.c	Fri Sep 25 07:40:56 2020	(r366141)
+++ head/sys/arm/allwinner/aw_pwm.c	Fri Sep 25 07:41:51 2020	(r366142)
@@ -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");