* Tomi Valkeinen <[email protected]> [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 [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to