[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-id: <d7555270-5be3-a104-233c-ac0e6383f41b@samsung.com>
Date: Thu, 21 Dec 2017 14:29:14 +0100
From: Maciej Purski <m.purski@...sung.com>
To: Mark Brown <broonie@...nel.org>
Cc: linux-kernel@...r.kernel.org, devicetree@...r.kernel.org,
Liam Girdwood <lgirdwood@...il.com>,
Rob Herring <robh+dt@...nel.org>,
Mark Rutland <mark.rutland@....com>,
Marek Szyprowski <m.szyprowski@...sung.com>,
Bartlomiej Zolnierkiewicz <b.zolnierkie@...sung.com>
Subject: Re: [PATCH v3 4/4] regulator: core: Balance coupled regulators
voltages
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 suggestion, how should I implement that path? The thing which
>> makes it more complicated is locking, because set_voltage_unlocked is done
>> under one regulator's mutex and its suppliers, while balance procedure locks
>> every coupled regulator without its suppliers. The suppliers for a single
>> regulator are locked when setting a single regulator's voltage takes place.
>
> We only really need to lock the supplies when doing the actual mechanics
> of voltage changes so I'm not sure I see a big issue here - if we always
> go through balancing first then voltage setting it should be fine. If
> everything is always balancing (even uncoupled regulators) then part of
> the transition should be moving some if not all of the data updates to
> balancing.
>
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
coupled regulators to be a very rare case, so in most of the cases we will have
a pointless structure in reg_dev with a pointer to itself. Maybe you suggest
that coupling_desc should contain something different?
Powered by blists - more mailing lists