Re: [PATCH 0/3] pwm: bcm2835: Minor fixes

[Stefan Wahren <wahrenst@gmx.net>]

Hi Uwe,

Am 24.08.19 um 11:25 schrieb Uwe Kleine-König:
> Hello Stefan,
>
> On Sat, Aug 24, 2019 at 09:07:22AM +0200, Stefan Wahren wrote:
>> This small patch series contains minor fixes for clock handling and the
>> period range check.
> I'd like to understand the various different usecases of PWMs. The
> in-kernel consumers are kind of obvious, but sysfs users are not. It
> seems you are one of the latter.
>
> Would you mind sharing what you control using the PWM?
not really a PWM user with BCM2835. It's more the motivation as a
platform maintainer to keep the drivers in shape. At work we are using
sysfs interface for user applications to control ventilation (via hwmon
interface) and EV charging (IEC 61851) with a different SoC.
>  Does it bother
> you that the sysfs interface doesn't allow atomic configuration?
To be honest not really, but i think a lot of user could benefit and
might stop using hacky Python scripts which manipulate the registers
directly.
>
> Assuming you have some interest in this driver: It still uses the legacy
> stuff implementing .config, .enable, .disable, .set_polarity. Are you
> willing to test (or even implement) a switch to .apply instead?
Yes, definitely. This is one of my never ending TODO list [1]. But i
would be suprised that you wont have access to a Raspberry Pi.
>
> Just from a quick lock into the driver I wonder a few things, maybe you
> can shed some light here. If there is publicly available documenation
> for this piece of hardware, feel free to point this out, then I might be
> able to work out some of the answers myself.
Fortunately yes [2]
>
> The overall (and common) design of the PWM is an input clk, a counter, a
> duty and a period register.
>
> The slightly simplified logic in .config is:
>
> 	scaler = DIV_ROUND_CLOSEST(NSEC_PER_SEC, rate);
> 	writel(DIV_ROUND_CLOSEST(duty_ns, scaler), PWM_DUTY);
> 	writel(DIV_ROUND_CLOSEST(period_ns, scaler), PWM_PERIOD);
>
> This is loosing precision while the calculation could be cheaper (in CPU
> cycles) and more exact when using:
>
> 	writel(DIV_ROUND_CLOSEST(duty_ns * rate, NSEC_PER_SEC), PWM_DUTY);
> 	writel(DIV_ROUND_CLOSEST(period_ns * rate, NSEC_PER_SEC), PWM_PERIOD);
>
> This is only two divisions instead of three. And assuming a rate of 9.2
> MHz and a request of duty_ns = 499945, period_ns = 999891 the original
> calculation yields
>
> 	DUTY = 4587
> 	PERIOD = 9173
>
> 	real_duty_ns = 498586.95652173914
> 	real_period_ns = 997065.2173913043
>
> 	error_duty_ns = 1358.0434782608645
> 	error_period_ns = 2825.7826086956775
>
> With my suggestion you'd get
>
> 	DUTY = 4599
> 	PERIOD = 9199
>
> 	real_duty_ns = 499891.3043478261
> 	real_period_ns = 999891.304347826
>
> 	error_duty_ns = 53.69565217389027
> 	error_period_ns = -0.30434782605152577
>
> (But having said this, I'd prefer to use rounding down instead of
> rounding closest).
>
> Also I wonder if reprogramming the hardware completes the currently
> running period and how the hardware behaves on disable. (In the latter
> case I'm interested in "Does it complete the running period?" and "Which
> state does the output stop in?")

I need to make logic analyzer traces to make any statement.

Thanks

[1] - https://github.com/lategoodbye/rpi-zero/issues/16

[2] -
https://www.raspberrypi.org/app/uploads/2012/02/BCM2835-ARM-Peripherals.pdf

>
> Best regards
> Uwe
>

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel