Re: [PATCH 1/9] OMAP: DSS2: Change DSI platform device name from "omapdss_dsi1" to "omapdss_dsi"

[Tomi Valkeinen <tomi.valkeinen@ti.com>]

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