Date: Fri, 25 Sep 2020 07:41:51 +0000 (UTC) From: Andriy Gapon <avg@FreeBSD.org> To: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: svn commit: r366142 - head/sys/arm/allwinner Message-ID: <202009250741.08P7fpUb001725@repo.freebsd.org>
next in thread | raw e-mail | index | archive | help
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");
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?202009250741.08P7fpUb001725>