Hello,
I was wondering if a mechanism currently exists which allows regulator
devices which have probed via device tree to support regulator consumer
drivers which have probed via a board file (and thus have no associated
device tree device_node). It seems that the current setup is such that if
a regulator driver probes via a board file device, then it will be passed
a struct regulator_init_data pointer containing a consumer_supplies list
via platform_data. This allows the regulator driver to support consumers
that are probed via device tree nodes or via a board file. However, if a
regulator driver probes via a device tree node, then it will only be
accessible to consumer drivers which have nodes in device tree and which
specify their own foo-supply=<®ulator_phandle>; mappings. When a
regulator device is probed via device tree, the consumer_supplies pointer
is left null by of_get_regulator_init_data(). This seems to make
regulators probed via device tree nodes inaccessible to non-device tree
consumers.
In the long term, this problem should go away of its own accord. However,
in the short term, many systems are converting over to using device tree.
Therefore, we are left with a situation currently where some regulator
consumer drivers are being probed via device tree and some are being
probed via board file devices within a single platform. If the regulator
driver supporting the consumer drivers is converted to use device tree and
probed via device tree, then the non-device tree consumer drivers will not
be able to make use of the regulator devices.
Would it be possible to add a new binding that is handled inside of
of_get_regulator_init_data() or of_get_regulation_constraints() that
provides a means to directly specify regulator_init_data.consumer_supplies
entries? Is there some other mechanism that could be used instead to
handle the mapping?
One potentially binding could be:
regulator-consumer-supplies = "supply_name1", "device_name1",
"supply_name2", "device_name2", ...
Thank you,
David Collins
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
On Tue, Jun 05, 2012 at 09:16:22AM -0700, David Collins wrote:
> Therefore, we are left with a situation currently where some regulator
> consumer drivers are being probed via device tree and some are being
> probed via board file devices within a single platform. If the regulator
> driver supporting the consumer drivers is converted to use device tree and
> probed via device tree, then the non-device tree consumer drivers will not
> be able to make use of the regulator devices.
This isn't something anyone else seems to be running into - most of the
world is converting entire boards to device tree in one fell swoop and
sticking with normal style until that works.
> Would it be possible to add a new binding that is handled inside of
> of_get_regulator_init_data() or of_get_regulation_constraints() that
> provides a means to directly specify regulator_init_data.consumer_supplies
> entries? Is there some other mechanism that could be used instead to
> handle the mapping?
> One potentially binding could be:
> regulator-consumer-supplies = "supply_name1", "device_name1",
> "supply_name2", "device_name2", ...
Well, we certainly shouldn't be putting this in the device tree as that
rather defeats the point... Some sort of auxdata style thing would be
possible I guess but I'm not sure it's worth bothering.
On Tuesday 05 June 2012 09:46 PM, David Collins wrote:
> In the long term, this problem should go away of its own accord. However,
> in the short term, many systems are converting over to using device tree.
> Therefore, we are left with a situation currently where some regulator
> consumer drivers are being probed via device tree and some are being
> probed via board file devices within a single platform.
Is this a situation you are facing in your mainline kernel or internal
trees? What you explain would need you to work with hybrid board files
with some devices created through device tree and some others statically
from the board file in the kernel, and that approach was already shot
down as unacceptable.
On Wed, Jun 06, 2012 at 10:38:42AM +0530, Rajendra Nayak wrote:
> On Tuesday 05 June 2012 09:46 PM, David Collins wrote:
> >In the long term, this problem should go away of its own accord. However,
> >in the short term, many systems are converting over to using device tree.
> > Therefore, we are left with a situation currently where some regulator
> >consumer drivers are being probed via device tree and some are being
> >probed via board file devices within a single platform.
>
> Is this a situation you are facing in your mainline kernel or internal
> trees? What you explain would need you to work with hybrid board files
> with some devices created through device tree and some others statically
> from the board file in the kernel, and that approach was already shot
> down as unacceptable.
As I understand, this is something being done on our internal kernel.
I don't think this really applies to the mainline kernel, since none
of these transitionary drivers are going into the upstream kernel
without being made to work with device tree.
Thanks,
David
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.