[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240103103421.GA3758@francesco-nb>
Date: Wed, 3 Jan 2024 11:34:21 +0100
From: Francesco Dolcini <francesco@...cini.it>
To: pratikmanvar09@...il.com
Cc: thierry.reding@...il.com, u.kleine-koenig@...gutronix.de,
shawnguo@...nel.org, s.hauer@...gutronix.de, kernel@...gutronix.de,
festevam@...il.com, linux-imx@....com, linux-pwm@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
Clark Wang <xiaoning.wang@....com>, Jun Li <jun.li@....com>,
Pratik Manvar <pratik.manvar@....com>
Subject: Re: [PATCH] pwm: imx27: workaround of the pwm output bug
On Fri, Dec 29, 2023 at 12:00:07PM +0530, pratikmanvar09@...il.com wrote:
> From: Clark Wang <xiaoning.wang@....com>
>
> This fixes the pwm output bug when decrease the duty cycle.
> This is a limited workaround for the PWM IP issue TKT0577206.
>
> Root cause:
> When the SAR FIFO is empty, the new write value will be directly applied
> to SAR even the current period is not over.
> If the new SAR value is less than the old one, and the counter is
> greater than the new SAR value, the current period will not filp the
> level. This will result in a pulse with a duty cycle of 100%.
>
> Workaround:
> Add an old value SAR write before updating the new duty cycle to SAR.
> This will keep the new value is always in a not empty fifo, and can be
> wait to update after a period finished.
>
> Limitation:
> This workaround can only solve this issue when the PWM period is longer
> than 2us(or <500KHz).
>
> Reviewed-by: Jun Li <jun.li@....com>
> Signed-off-by: Clark Wang <xiaoning.wang@....com>
> Link: https://github.com/nxp-imx/linux-imx/commit/16181cc4eee61d87cbaba0e5a479990507816317
> Tested-by: Pratik Manvar <pratik.manvar@....com>
You need to add your signed-off-by at the end when sending a patch, no
matter if you are the author or not.
Francesco
Powered by blists - more mailing lists