On Thu, Dec 21, 2017 at 02:29:14PM +0100, Maciej Purski wrote:
> Now I can understand your point, but I still have doubts what is the
> advantage of that solution. For non-coupled regulators we end up with
> useless data structure - coupling_desc. That also might cause some
> confusion. We expect
On 12/15/2017 04:19 PM, Mark Brown wrote:
On Wed, Dec 13, 2017 at 10:25:00AM +0100, Maciej Purski wrote:
shared. To that end I'd adjust the code so that we always have a
coupling descriptor and then handle the case where there's only one
regulator described in there.
Do you have any sugge
On Wed, Dec 13, 2017 at 10:25:00AM +0100, Maciej Purski wrote:
> > shared. To that end I'd adjust the code so that we always have a
> > coupling descriptor and then handle the case where there's only one
> > regulator described in there.
> Do you have any suggestion, how should I implement that
On 12/12/2017 12:54 PM, Mark Brown wrote:
On Thu, Dec 07, 2017 at 10:46:15AM +0100, Maciej Purski wrote:
@@ -2447,10 +2482,9 @@ static int _regulator_is_enabled(struct regulator_dev
*rdev)
return rdev->desc->ops->is_enabled(rdev);
}
-static int _regulator_list_voltage(struct reg
On Thu, Dec 07, 2017 at 10:46:15AM +0100, Maciej Purski wrote:
> @@ -2447,10 +2482,9 @@ static int _regulator_is_enabled(struct regulator_dev
> *rdev)
> return rdev->desc->ops->is_enabled(rdev);
> }
>
> -static int _regulator_list_voltage(struct regulator *regulator,
> -
On Odroid XU3/4 and other Exynos5422 based boards there is a case, that
different devices on the board are supplied by different regulators
with non-fixed voltages. If one of these devices temporarily requires
higher voltage, there might occur a situation that the spread between
two devices' voltag
6 matches
Mail list logo
