* Tomi Valkeinen <tomi.valkeinen@xxxxxx> [110505 04:33]: > On Wed, 2011-05-04 at 12:40 +0300, Tony Lindgren wrote: > > > > Looks like we should first combine all this cut and paste data > > for each board file into some common init function to cut > > down the "crazy churn". > > Sorry, I don't see how this would be possible with the regulator > framework. What we would need is to setup some > regulator_consumer_supplies dynamically depending on the omap and on the > given parameters. > > Adding Liam and Mark for possible comments. A short summary of the > situation: > > OMAP display subsystem (DSS) HW needs a few power supplies (vdds_dsi, > vdds_sdi, vdda_dac), depending on the OMAP version. All the known boards > have the standard TWL power chip which provides these powers, and they > are connected almost always the same way. However, there's no reason > that the powers for DSS couldn't be provided from some other source. > > As an example, on OMAP3 we could have: > (regulator -> name -> driver) > VDDA_DAC -> "vdda_dac" -> omapdss_venc > VPLL2 -> "vdds_dsi" -> omapdss > VPLL2 -> "vdds_dsi" -> omapdss_dsi > > So currently we have REGULATOR_SUPPLY defines for each board in all the > board files which support display. It would be much better to have an > overrideable standard setup for the DSS powers, but this would require > dynamically setting up the regulator_consumer_supplies. And I can't see > how this could be done, except dynamically creating the > regulator_consumer_supply array before initializing the TWL chip, but as > DSS is not the only user of those powers the end result could be quite a > mess with changes needed in every board file. What if you just do all common DSS REGULATOR_SUPPLY entries in the common platform init code for DSS? Then just set the regulator_init_data pointers based on the desired configuration. Or maybe I misunderstood your problem.. Tony -- 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
