On Tuesday 13 January 2009, Tony Lindgren wrote:
> The the read/write_reg should be in drivers/mfd somewhere.
I wouldn't think so ... it's not an MFD, it's just a
regulator that has a feature that's not yet envisioned
by the current regulator framework. (Floor/Ceiling
controls, basically.)
> > @@ -160,5 +218,14 @@ int __init omap_register_i2c_bus(int bus_id, u32
> > clkrate, }
> >
> > omap_i2c_mux_pins(bus_id - 1);
> > - return platform_device_register(pdev);
> > + platform_device_register(pdev);
> > +#if defined(CONFIG_OMAP3EVM_PR785)
> > + if (bus_id == 1) {
> > + omap_i2c_register_child(pdev, "vdd2_consumer", \
> > + &vdd2_platform_device);
> > + omap_i2c_register_child(pdev, "vdd1_consumer", \
> > + &vdd1_platform_device);
> > + }
> > +#endif
> > + return 0;
> > }
>
> Argh, i2c-omap.c is the _bus_ driver, not i2c device!
Right. I don't understand why there's this urge to
scatter board-specific code throughout the driver
tree, instead of leaving it all in mach-omap2/pr785.c
and having the tps6235x.c driver be a pure regulator
driver...
> How different tps6235 is from the twl4030? Maybe you can just add
> functionality to the existing drivers/mfd/twl4030-core.c.
It's very different ... the tps623x chips are trivial,
with about four registers each. No capability OTHER
than being a voltage regulator.
Which is why it's puzzling to see it take so long to
just get a simple voltage regulator driver patch...
Admittedly, the regulator framework is new, and parts
of it still seem to me like they have design problems.
But even so, it's not so hard to figure out how to pass
board-specific regulator configuration data down to the
regulator drivers from a pr785.c board driver.
Now, there *can* be a bit of chicken/egg going on in
some of that initialization. But I don't think that
applies to all of the PR785 support.
- Dave
--
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
