[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140602122332.GA31751@sirena.org.uk>
Date: Mon, 2 Jun 2014 13:23:32 +0100
From: Mark Brown <broonie@...nel.org>
To: Viresh Kumar <viresh.kumar@...aro.org>
Cc: "Rafael J. Wysocki" <rjw@...ysocki.net>,
Lists linaro-kernel <linaro-kernel@...ts.linaro.org>,
"linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Arvind Chauhan <arvind.chauhan@....com>,
Eduardo Valentin <edubezval@...il.com>,
Pavel Machek <pavel@....cz>,
Liam Girdwood <lgirdwood@...il.com>
Subject: Re: [PATCH 1/2] regulators: Add definition of
regulator_set_voltage_time() for !CONFIG_REGULATOR
On Mon, Jun 02, 2014 at 03:45:37PM +0530, Viresh Kumar wrote:
> On 2 June 2014 15:32, Mark Brown <broonie@...nel.org> wrote:
> > No, think about what you're changing here. You're changing the stub -
> > the stub has a regulator_get() which always succeeeds.
> Now, why do we want to return -EINVAL from set_voltage here ? Similar
> routines in clk-API are returning 0 and even clk_get_rate() returns zero,
> unlike in regulators, as we return -EINVAL..
If the consumer tried to set a voltage presumably it cares if that
voltage was set - for example if your cpufreq driver tries to increase
the voltage of a core supply so that it can then raise the frequency the
user is going to be upset if the voltage was not actually raised and it
goes off and raises the clock rate causing the system to become unstable.
> Not sure which of these frameworks is doing the right thing.
I don't think the clock API should have clk_set_rate() report success if
it was ignored.
Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)
Powered by blists - more mailing lists