[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140923085130.GO30514@ulmo>
Date: Tue, 23 Sep 2014 10:51:31 +0200
From: Thierry Reding <thierry.reding@...il.com>
To: Janusz Użycki <j.uzycki@...roma.com.pl>
Cc: Mike Turquette <mturquette@...aro.org>,
Philipp Zabel <p.zabel@...gutronix.de>,
linux-kernel@...r.kernel.org, devicetree@...r.kernel.org,
linux-pwm@...r.kernel.org
Subject: Re: [PATCH] clk: Add PWM clock driver
On Wed, Sep 10, 2014 at 10:05:17PM +0200, Janusz Użycki wrote:
> Hi,
>
> http://patchwork.ozlabs.org/patch/359069/
> https://lkml.org/lkml/2014/6/12/186
>
> Will the patch ever included to linux-next?
I've never seen this patch before. From a quick look it doesn't seem
like it would work as is, but the idea is certainly interesting. If
somebody decides to continue work on it, please Cc me and the linux-pwm
mailing list.
> pwm_config() API could be extended to support
> not only period [ns] and duty [ns] time
> but also frequency [Hz] and duty cycle fraction [1/1000?]
> (instead of time in ns) as parameters.
> Then ns (rounded by pwm) to freq. conversion problem
> inclk_pwm_recalc_rate() usingpwm_get_period()
> could be avoided.
> To extend the API pwm_config() can support
> new flags forduty_ns and period_ns,
> eg. PWM_DUTY_PERCENT and PWM_PERIOD_HZ.
Is that rounding really a problem? Also the PWM chips will most likely
use the concept of period and duty-cycle internally anyway, so it will
convert back from Hz/percentage to nanoseconds and fall victim to
similar rounding effects.
Thierry
Content of type "application/pgp-signature" skipped
Powered by blists - more mailing lists