On Tuesday 25 October 2011 12:22 PM, Shawn Guo wrote:
On Tue, Oct 25, 2011 at 11:30:19AM +0530, Rajendra Nayak wrote:
On Monday 24 October 2011 07:17 PM, Shawn Guo wrote:
On Mon, Oct 24, 2011 at 02:43:58PM +0530, Rajendra Nayak wrote:
Case 2:
One device for all regulators:
DT nodes look something like this
regulators {
reg1: reg@1 {
...
...
};
reg2: reg@2 {
...
...
};
};
The regulator driver probes only one device and the dev->of_node
points to the "regulators" node above.
The mc13892 example I put in the reply to Grant demonstrates that
for some case, dev->of_node is NULL (devices are created by mfd core).
In that case should you not be first converting the mfd driver to
register regulator devices using DT?
The mc13892 mfd driver calls mfd_add_devices() to add device for
mc13892 regulator driver. Are you suggesting that I should hack
mfd_add_devices() to have device_node of 'regulators' attached?
The mfd is not a bus like i2c and spi, so I'm not sure this is the
right thing to do.
Thats what we did for OMAP, and hence we always have the of_node
populated when the regulator devices are probed.
See this patch from Benoit on how thats done for twl devices..
http://marc.info/?l=linux-omap&m=131489864814428&w=2
OMAP is "Case 1", and we are talking about "Case 2".
I don't see why it wouldn't work for "Case 2". The only difference
is in case of "Case 1", the dev->of_node would already point to
the right regulator node, like 'reg1', 'reg2' above.
In case of "Case 2", the dev->of_node would point to the 'regulators'
node instead, and the driver could then do a for_each_child_of_node()
to iterate over all its children to get 'reg1', 'reg2' etc.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
