lkml.org 
[lkml]   [2018]   [Apr]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH v2 2/2] regulator: add QCOM RPMh regulator driver
From
Date
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 something like:
>>>
>>> int target_min, target_max;
>>> int current_uV = _regulator_get_voltage(rdev);
>>> if (current_uV < 0) {
>>> /* Maybe this regulator's hardware can't be read and needs to be initted */
>>> _regulator_do_set_voltage(
>>> rdev, rdev->constraints->min_uV, rdev->constraints->min_uV);
>>> current_uV = _regulator_get_voltage(rdev);
>>> }
>>> if (current_uV < 0) {
>>> rdev_err(rdev,
>>> "failed to get the current voltage(%d)\n",
>>> current_uV);
>>> return current_uV;
>>> }
>
>>> If Mark doesn't like that then I guess I'd be OK w/ initting it to 0
>>> but this needs to be documented _somewhere_ (unlike for bypass it's
>>> not obvious, so you need to find someplace to put it). I'd rather not
>>> hack the DT to deal with our software limitations.
>
>> I'm not opposed to your option #3 though it does seem a little hacky and
>> tailored to the qcom_rpmh-regulator specific case. Note that I think it
>> would be better to vote for min_uV to max_uV than min_uV to min_uV though.
>
>> Mark, what are your thoughts on the best way to handle this situation?
>
> 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 this purpose?

Thanks,
David

--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

\
 
 \ /
  Last update: 2018-04-24 23:10    [W:0.083 / U:0.636 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site