Hello Nylon, I took another look in the driver and found another problem: On Tue, Jan 21, 2025 at 07:12:10PM +0100, Uwe Kleine-König wrote: > On Tue, Jan 21, 2025 at 04:47:46PM +0800, Nylon Chen wrote: > > Uwe Kleine-König <u.kleine-koenig@xxxxxxxxxxxx> 於 2025年1月21日 週二 下午3:47寫道： > > > > > > Hello, > > > > > > On Sun, Jan 19, 2025 at 03:03:16PM +0800, Nylon Chen wrote: > > > > I ran some basic tests by changing the period and duty cycle in both > > > > decreasing and increasing sequences (see the script below). > > > > > > What is clk_get_rate(ddata->clk) for you? > > 130 MHz > > OK, so the possible period lengths are > > (1 << (16 + scale)) / (130 MHz) > > for scale in [0, .. 15], right? That's > > 2^scale * 504123.07692307694 ns > > So testing period in the range between 5000 ns and 15000 ns isn't > sensible? Did I get something wrong? If the above is right, switching > between period=1008246 ns and 1008247 ns is likely to trigger a > warning. The possible periods are of the form 2^scale * A where A is constant and only depends on the input clock rate. scale ranges over [0, ... 15]. (If I got it right in my last mail, we have A = 504123.07692307694 ns.) If you request say: .period = 3.9 * A .duty_cycle = 1.9 * A the period actually emitted by the PWM will be 2 * A. But to calculate frac the originally requested period (i.e. 3.9 * A) is used. So frac becomes 31927 resulting in .duty_cycle being ~0.974 A. A better value would be frac = 62259 which results in .duty_cycle ≅ 1.9 * A. (Depending on A the values for frac might be off by one due to rounding differences.) So I would expect that PWM_DEBUG is angry with you if you go from .period = 2 * A .duty_cycle = 1.9 * A to .period = 3.9 * A .duty_cycle = 1.9 * A . Best regards Uwe
Attachment:
signature.asc
Description: PGP signature
