[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAA8avJ8hn5n_gpu7EqiQBcxe=-SvNrpSy9VskkMhdC16PYQU+A@mail.gmail.com>
Date: Sat, 21 Nov 2015 19:41:54 +0530
From: Saurabh Sengar <saurabh.truth@...il.com>
To: Mark Brown <broonie@...nel.org>
Cc: Liam Girdwood <lgirdwood@...il.com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] regulator: of: simplifing the parsing code
On 21 November 2015 at 18:52, Mark Brown <broonie@...nel.org> wrote:
> On Fri, Nov 20, 2015 at 01:27:27PM +0530, Saurabh Sengar wrote:
>
>> I also have concern related to how we are passing 'regulator-mode' and
>> 'regulator-initial-mode'. Currently this require a extra function to be
>> set in 'of_map_mode', which can be avoided.
>> These two parameters can be set directly from the device tree as in below patch:
>> https://lkml.org/lkml/2014/1/16/263
>
> No, they can't - the values we set for modes in the DT are defined per
> regulator and we need to translate these into the regulator API
> definitions.
>
What I want to say is there are only 4 possible values which can be
set for initial_mode and suspend_state modes:
#define REGULATOR_MODE_FAST 0x1
#define REGULATOR_MODE_NORMAL 0x2
#define REGULATOR_MODE_IDLE 0x4
#define REGULATOR_MODE_STANDBY 0x8
these are defined in include/linux/regulator/consumer.h (core regulator file).
'of_map_modes' of each regulator driver ultimately set these values only.
I want to suggest that these values can directly be pass from dts.
Different dts can pass different values according to the regulator
they are using,
no need to decode them from of_map_modes function.
Let me know your comments on this.
Regards,
Saurabh
--
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