[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Fri, 12 Dec 2014 10:53:56 +0100
From: Philipp Zabel <p.zabel@...gutronix.de>
To: Janusz Użycki <j.uzycki@...roma.com.pl>
Cc: Mike Turquette <mturquette@...aro.org>,
Thierry Reding <thierry.reding@...il.com>,
Rob Herring <robh+dt@...nel.org>,
Pawel Moll <pawel.moll@....com>,
Mark Rutland <mark.rutland@....com>,
Ian Campbell <ijc+devicetree@...lion.org.uk>,
Kumar Gala <galak@...eaurora.org>, devicetree@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-pwm@...r.kernel.org
Subject: Re: [PATCH v3] clk: Add PWM clock driver
Hi Janusz,
Am Freitag, den 12.12.2014, 09:58 +0100 schrieb Janusz Użycki:
> Hi Philipp,
>
> It moved .enable to .prepare which can sleep and it works
> without any bug.
> The dirty fix:
> const struct clk_ops clk_pwm_ops = {
> - .enable = clk_pwm_enable,
> - .disable = clk_pwm_disable,
> + .prepare = clk_pwm_enable,
> + .unprepare = clk_pwm_disable,
> .recalc_rate = clk_pwm_recalc_rate,
> };
>
> What do you think about?
Thanks! Since the pwm API does not give any guarantees that
pwm_enable/disable may be called from atomic context, I think this
change is correct. The PWM documentation says:
"Currently the PWM core does not enforce any locking to pwm_enable(),
pwm_disable() and pwm_config(), so the calling context is currently
driver specific. This is an issue derived from the former barebone
API and should be fixed soon."
clk_enable should support reentrancy, but calling clk_prepare_enable
inside a clk_enable callback is not going to work.
regards
Philipp
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists