On Thu, 2011-05-05 at 14:02 +0100, Mark Brown wrote: > On Thu, May 05, 2011 at 02:36:48PM +0300, Tomi Valkeinen wrote: > > > 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. > > I'm not sure I see a problem that needs solving here? This wiring is > all totally system specific. Once we have viable device tree for > relevant platforms I'd expect to see these things mapped in the device > tree for the system with a standard regulator API device tree mapping. I think there are two things here: The first is that we want to avoid unnecessary board file changes, and as almost all boards configure the DSS powers the same way, it'd be nice to have a default config for these. The second thing is that even if the power source for vdds_dsi may be configured differently on different boards, the same vdds_dsi goes to multiple DSS HW blocks inside OMAP, each represented by a separate omap_device. So it'd be much nicer to configure just the vdds_dsi power in the board file, but let the omap display code configure the regulators properly for all the DSS HW blocks in that particular OMAP. I'm not familiar with the capabilities of the device tree, so it may solve these neatly (at least from kernel's perspective). I guess Tony just wants to try to minimize arch/arm changes wherever possible due to the recent arch/arm dispute. Tomi -- 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
