On Wed, Apr 25, 2018 at 02:04:56PM -0700, David Collins wrote:
> > Using -EAGAIN for "I can't ever read the configuration from this
> > regulator" doesn't seem right - it's not like any number of retries
> > will ever manage to read the value back.
> In this case, the _regulator_get_voltage() cal
>>> I think that's probably only OK if we have a specific error code for the
>>> regulator being limited in this way otherwise our error handling for I/O
>>> problems involves us trying to reconfigure supplies which seems like it
>>> would be risky.
>> Would you be ok with -EAGAIN being used for
On Tue, Apr 24, 2018 at 02:09:47PM -0700, David Collins wrote:
> On 04/24/2018 10:45 AM, Mark Brown wrote:
> > I think that's probably only OK if we have a specific error code for the
> > regulator being limited in this way otherwise our error handling for I/O
> > problems involves us trying to re
On 04/24/2018 10:45 AM, Mark Brown wrote:
>>> You'd need to ask Mark if he's OK with it, but a option #3 is to add a
>>> patch to your series fix the regulator framework to try setting the
>>> voltage if _regulator_get_voltage() fails. Presumably in
>>> machine_constraints_voltage() you'd now do s
On Fri, Apr 20, 2018 at 03:08:57PM -0700, David Collins wrote:
> On 04/19/2018 09:16 AM, Doug Anderson wrote:
> > On Wed, Apr 18, 2018 at 4:30 PM, David Collins
> > wrote:
Please delete unneeded context from mails when replying. Doing this
makes it much easier to find your reply in the message,
On 04/19/2018 09:16 AM, Doug Anderson wrote:
> On Wed, Apr 18, 2018 at 4:30 PM, David Collins
> wrote:
+ * @drms_mode: Array of regulator framework modes which
can
+ * be configured dynamically for this
regulator
+ *
Hi,
On Wed, Apr 18, 2018 at 4:30 PM, David Collins wrote:
>>> + * @drms_mode: Array of regulator framework modes which can
>>> + * be configured dynamically for this regulator
>>> + * via the set_load() callback.
>>
>> Using
Quoting David Collins (2018-04-18 16:30:26)
> On 04/17/2018 01:02 PM, Doug Anderson wrote:
> > On Fri, Apr 13, 2018 at 7:50 PM, David Collins
> > wrote:
> >> +#define RPMH_REGULATOR_DISABLE 0x0
> >> +#define RPMH_REGULATOR_ENABLE 0x1
> >
> > In the last version S
On 04/17/2018 01:02 PM, Doug Anderson wrote:
> On Fri, Apr 13, 2018 at 7:50 PM, David Collins
> wrote:
>> +#define RPMH_REGULATOR_DISABLE 0x0
>> +#define RPMH_REGULATOR_ENABLE 0x1
>
> In the last version Stephen said he didn't like the above two #defines
> and yo
Hi,
On Fri, Apr 13, 2018 at 7:50 PM, David Collins wrote:
> +#define RPMH_REGULATOR_DISABLE 0x0
> +#define RPMH_REGULATOR_ENABLE 0x1
In the last version Stephen said he didn't like the above two #defines
and you said you'd remove them, yet they are still here. E
Add the QCOM RPMh regulator driver to manage PMIC regulators
which are controlled via RPMh on some Qualcomm Technologies, Inc.
SoCs. RPMh is a hardware block which contains several
accelerators which are used to manage various hardware resources
that are shared between the processors of the SoC.
11 matches
Mail list logo
