On Thu, May 23, 2019 at 10:35:46AM +0200, Jorge Ramirez wrote:
> Would you accept if I wrote a separate driver specific to pms405 or do
> you want me to integrate in qcom-spmi_regulator.c?
> I am asking because none of the ops will use the common functions (I
> wont be reusing much code from
On 5/6/19 06:38, Mark Brown wrote:
> On Fri, May 03, 2019 at 10:29:42AM +0200, Jorge Ramirez wrote:
>> On 5/3/19 08:26, Mark Brown wrote:
>>> On Thu, May 02, 2019 at 01:30:48PM +0200, Jorge Ramirez wrote:
>
>>> It seems a bit of a jump to add a new driver - it's just another
>>> descriptor and
On Fri, May 03, 2019 at 10:29:42AM +0200, Jorge Ramirez wrote:
> On 5/3/19 08:26, Mark Brown wrote:
> > On Thu, May 02, 2019 at 01:30:48PM +0200, Jorge Ramirez wrote:
> > It seems a bit of a jump to add a new driver - it's just another
> > descriptor and ops structure isn't it? Though as ever
On 5/3/19 08:26, Mark Brown wrote:
> On Thu, May 02, 2019 at 01:30:48PM +0200, Jorge Ramirez wrote:
>> On 5/2/19 04:33, Mark Brown wrote:
>
>>> I'm not sure I follow here, sorry - I can see that the driver needs a
>>> custom get/set selector operation but shouldn't it be able to use the
>>>
On Thu, May 02, 2019 at 01:30:48PM +0200, Jorge Ramirez wrote:
> On 5/2/19 04:33, Mark Brown wrote:
> > I'm not sure I follow here, sorry - I can see that the driver needs a
> > custom get/set selector operation but shouldn't it be able to use the
> > standard list and map operations for linear
On 5/2/19 04:33, Mark Brown wrote:
> On Mon, Apr 29, 2019 at 02:31:55PM +0200, Jorge Ramirez wrote:
>> On 4/27/19 20:21, Mark Brown wrote:
>
>>> Since the point of this change is AFAICT that this regulator only has a
>>> single linear range it seems like it should just be able to use the
>>>
On Mon, Apr 29, 2019 at 02:31:55PM +0200, Jorge Ramirez wrote:
> On 4/27/19 20:21, Mark Brown wrote:
> > Since the point of this change is AFAICT that this regulator only has a
> > single linear range it seems like it should just be able to use the
> > existing generic functions shouldn't it?
On 4/27/19 20:21, Mark Brown wrote:
> On Thu, Apr 25, 2019 at 09:44:00PM +0200, Jorge Ramirez wrote:
>
>> the way I see it, if I follow your suggestion and since we are not
>> allowed to extend spmi_regulator_find_range(), the only options are:
>
>> 1) duplicate verbatim this whole function
>>
On Thu, Apr 25, 2019 at 09:44:00PM +0200, Jorge Ramirez wrote:
> the way I see it, if I follow your suggestion and since we are not
> allowed to extend spmi_regulator_find_range(), the only options are:
> 1) duplicate verbatim this whole function
> (spmi_regulator_select_voltage_same_range) with
On 4/25/19 20:37, Mark Brown wrote:
> On Fri, Apr 19, 2019 at 07:29:48PM +0200, Jorge Ramirez wrote:
>> On 2/4/19 10:03, Mark Brown wrote:
>
+ /* we know we only have one range for this type */
+ if (vreg->logical_type == SPMI_REGULATOR_LOGICAL_TYPE_HFS430)
+ return
On Fri, Apr 19, 2019 at 07:29:48PM +0200, Jorge Ramirez wrote:
> On 2/4/19 10:03, Mark Brown wrote:
> >> + /* we know we only have one range for this type */
> >> + if (vreg->logical_type == SPMI_REGULATOR_LOGICAL_TYPE_HFS430)
> >> + return range;
> > Rather than have special casing
On 2/4/19 10:03, Mark Brown wrote:
> On Mon, Jan 28, 2019 at 12:45:03PM +0100, Jorge Ramirez-Ortiz wrote:
>
>> @@ -653,6 +708,10 @@ spmi_regulator_find_range(struct spmi_regulator *vreg)
>> range = vreg->set_points->range;
>> end = range + vreg->set_points->count;
>>
>> +/* we
On Mon, Jan 28, 2019 at 12:45:03PM +0100, Jorge Ramirez-Ortiz wrote:
> @@ -653,6 +708,10 @@ spmi_regulator_find_range(struct spmi_regulator *vreg)
> range = vreg->set_points->range;
> end = range + vreg->set_points->count;
>
> + /* we know we only have one range for this type */
The PMS405 has 5 HFSMPS and 13 LDO regulators,
This commit adds support for one of the 5 HFSMPS regulators (s3) to
the spmi regulator driver.
The PMIC HFSMPS 430 regulators have 8 mV step size and a voltage
control scheme consisting of two 8-bit registers defining a 16-bit
voltage set point in
14 matches
Mail list logo
