| Message ID | 1304494704-7285-2-git-send-email-archit@ti.com (mailing list archive) |
|---|---|
| State | Superseded |
| Delegated to: | Tomi Valkeinen |
| Headers | show |
* Archit Taneja <archit@ti.com> [110504 10:30]: > --- a/arch/arm/mach-omap2/board-3430sdp.c > +++ b/arch/arm/mach-omap2/board-3430sdp.c > @@ -401,7 +401,7 @@ static struct regulator_consumer_supply sdp3430_vdda_dac_supplies[] = { > /* VPLL2 for digital video outputs */ > static struct regulator_consumer_supply sdp3430_vpll2_supplies[] = { > REGULATOR_SUPPLY("vdds_dsi", "omapdss"), > - REGULATOR_SUPPLY("vdds_dsi", "omapdss_dsi1"), > + REGULATOR_SUPPLY("vdds_dsi", "omapdss_dsi.0"), > }; > > static struct regulator_consumer_supply sdp3430_vmmc1_supplies[] = { > diff --git a/arch/arm/mach-omap2/board-4430sdp.c b/arch/arm/mach-omap2/board-4430sdp.c > index 570e83f..eafadb4 100644 > --- a/arch/arm/mach-omap2/board-4430sdp.c > +++ b/arch/arm/mach-omap2/board-4430sdp.c > @@ -375,7 +375,7 @@ static struct regulator_consumer_supply sdp4430_vmmc_supply[] = { > }; > static struct regulator_consumer_supply sdp4430_vcxio_supply[] = { > REGULATOR_SUPPLY("vdds_dsi", "omapdss_dss"), > - REGULATOR_SUPPLY("vdds_dsi", "omapdss_dsi1"), > + REGULATOR_SUPPLY("vdds_dsi", "omapdss_dsi.0"), > }; ... 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". Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, 2011-05-04 at 12:40 +0300, Tony Lindgren wrote: > * Archit Taneja <archit@ti.com> [110504 10:30]: > > --- a/arch/arm/mach-omap2/board-3430sdp.c > > +++ b/arch/arm/mach-omap2/board-3430sdp.c > > @@ -401,7 +401,7 @@ static struct regulator_consumer_supply sdp3430_vdda_dac_supplies[] = { > > /* VPLL2 for digital video outputs */ > > static struct regulator_consumer_supply sdp3430_vpll2_supplies[] = { > > REGULATOR_SUPPLY("vdds_dsi", "omapdss"), > > - REGULATOR_SUPPLY("vdds_dsi", "omapdss_dsi1"), > > + REGULATOR_SUPPLY("vdds_dsi", "omapdss_dsi.0"), > > }; > > > > static struct regulator_consumer_supply sdp3430_vmmc1_supplies[] = { > > diff --git a/arch/arm/mach-omap2/board-4430sdp.c b/arch/arm/mach-omap2/board-4430sdp.c > > index 570e83f..eafadb4 100644 > > --- a/arch/arm/mach-omap2/board-4430sdp.c > > +++ b/arch/arm/mach-omap2/board-4430sdp.c > > @@ -375,7 +375,7 @@ static struct regulator_consumer_supply sdp4430_vmmc_supply[] = { > > }; > > static struct regulator_consumer_supply sdp4430_vcxio_supply[] = { > > REGULATOR_SUPPLY("vdds_dsi", "omapdss_dss"), > > - REGULATOR_SUPPLY("vdds_dsi", "omapdss_dsi1"), > > + REGULATOR_SUPPLY("vdds_dsi", "omapdss_dsi.0"), > > }; > ... > > 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". I was actually thinking about this earlier today. All the boards I have seen use vdds_dsi the same way (depending on the omap version, though). For OMAP3 it comes from VPPL2 and for OMAP4 it's VCXIO. Optimally a common piece of code would just set up the regulator properly. But I think in the end the config has to come from the board data, as I don't see that the above config would be the only possibility. The vdds_dsi could be supplied from anywhere (with suitable voltage, of course), as far as I understand. What we could do is: 1. The board file tells the common display code which regulator is used for vdds_dsi, and the common code can setup the regulator supply for all DSS devices which need it (omapdss_dss, omapdss_dsi1, omapdss_dsi2). I guess this needs dynamically adding the regulator supply in display.c, and I'm not quite sure if that's possible. We have to look at this. 2. The common code could default to the power source that is most commonly used, so the board file would have to config the regulator only if it uses a non-common one. Together 1. and 2. would remove the DSS regulator stuff totally from the board files. But regulators for the panels would still be in the board files, of course. Tomi -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, 2011-05-04 at 13:53 +0300, Tomi Valkeinen wrote: > On Wed, 2011-05-04 at 12:40 +0300, Tony Lindgren wrote: > > * Archit Taneja <archit@ti.com> [110504 10:30]: > > > --- a/arch/arm/mach-omap2/board-3430sdp.c > > > +++ b/arch/arm/mach-omap2/board-3430sdp.c > > > @@ -401,7 +401,7 @@ static struct regulator_consumer_supply sdp3430_vdda_dac_supplies[] = { > > > /* VPLL2 for digital video outputs */ > > > static struct regulator_consumer_supply sdp3430_vpll2_supplies[] = { > > > REGULATOR_SUPPLY("vdds_dsi", "omapdss"), > > > - REGULATOR_SUPPLY("vdds_dsi", "omapdss_dsi1"), > > > + REGULATOR_SUPPLY("vdds_dsi", "omapdss_dsi.0"), > > > }; > > > > > > static struct regulator_consumer_supply sdp3430_vmmc1_supplies[] = { > > > diff --git a/arch/arm/mach-omap2/board-4430sdp.c b/arch/arm/mach-omap2/board-4430sdp.c > > > index 570e83f..eafadb4 100644 > > > --- a/arch/arm/mach-omap2/board-4430sdp.c > > > +++ b/arch/arm/mach-omap2/board-4430sdp.c > > > @@ -375,7 +375,7 @@ static struct regulator_consumer_supply sdp4430_vmmc_supply[] = { > > > }; > > > static struct regulator_consumer_supply sdp4430_vcxio_supply[] = { > > > REGULATOR_SUPPLY("vdds_dsi", "omapdss_dss"), > > > - REGULATOR_SUPPLY("vdds_dsi", "omapdss_dsi1"), > > > + REGULATOR_SUPPLY("vdds_dsi", "omapdss_dsi.0"), > > > }; > > ... > > > > 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". > > I was actually thinking about this earlier today. > > All the boards I have seen use vdds_dsi the same way (depending on the > omap version, though). For OMAP3 it comes from VPPL2 and for OMAP4 it's > VCXIO. Optimally a common piece of code would just set up the regulator > properly. > > But I think in the end the config has to come from the board data, as I > don't see that the above config would be the only possibility. The > vdds_dsi could be supplied from anywhere (with suitable voltage, of > course), as far as I understand. > > What we could do is: > > 1. The board file tells the common display code which regulator is used > for vdds_dsi, and the common code can setup the regulator supply for all > DSS devices which need it (omapdss_dss, omapdss_dsi1, omapdss_dsi2). > > I guess this needs dynamically adding the regulator supply in display.c, > and I'm not quite sure if that's possible. We have to look at this. I don't see how this would be possible. As far as I see, the regulator consumers have to be given statically at init time. We could get the whole VPLL2 or VCXIO supply array from a common display code, but that would prevent adding any other consumers to those regulators, so that's not an option either. Tomi -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wednesday 04 May 2011 04:51 PM, Valkeinen, Tomi wrote: > On Wed, 2011-05-04 at 13:53 +0300, Tomi Valkeinen wrote: >> On Wed, 2011-05-04 at 12:40 +0300, Tony Lindgren wrote: >>> * Archit Taneja<archit@ti.com> [110504 10:30]: >>>> --- a/arch/arm/mach-omap2/board-3430sdp.c >>>> +++ b/arch/arm/mach-omap2/board-3430sdp.c >>>> @@ -401,7 +401,7 @@ static struct regulator_consumer_supply sdp3430_vdda_dac_supplies[] = { >>>> /* VPLL2 for digital video outputs */ >>>> static struct regulator_consumer_supply sdp3430_vpll2_supplies[] = { >>>> REGULATOR_SUPPLY("vdds_dsi", "omapdss"), >>>> - REGULATOR_SUPPLY("vdds_dsi", "omapdss_dsi1"), >>>> + REGULATOR_SUPPLY("vdds_dsi", "omapdss_dsi.0"), >>>> }; >>>> >>>> static struct regulator_consumer_supply sdp3430_vmmc1_supplies[] = { >>>> diff --git a/arch/arm/mach-omap2/board-4430sdp.c b/arch/arm/mach-omap2/board-4430sdp.c >>>> index 570e83f..eafadb4 100644 >>>> --- a/arch/arm/mach-omap2/board-4430sdp.c >>>> +++ b/arch/arm/mach-omap2/board-4430sdp.c >>>> @@ -375,7 +375,7 @@ static struct regulator_consumer_supply sdp4430_vmmc_supply[] = { >>>> }; >>>> static struct regulator_consumer_supply sdp4430_vcxio_supply[] = { >>>> REGULATOR_SUPPLY("vdds_dsi", "omapdss_dss"), >>>> - REGULATOR_SUPPLY("vdds_dsi", "omapdss_dsi1"), >>>> + REGULATOR_SUPPLY("vdds_dsi", "omapdss_dsi.0"), >>>> }; >>> ... >>> >>> 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". >> >> I was actually thinking about this earlier today. >> >> All the boards I have seen use vdds_dsi the same way (depending on the >> omap version, though). For OMAP3 it comes from VPPL2 and for OMAP4 it's >> VCXIO. Optimally a common piece of code would just set up the regulator >> properly. >> >> But I think in the end the config has to come from the board data, as I >> don't see that the above config would be the only possibility. The >> vdds_dsi could be supplied from anywhere (with suitable voltage, of >> course), as far as I understand. >> >> What we could do is: >> >> 1. The board file tells the common display code which regulator is used >> for vdds_dsi, and the common code can setup the regulator supply for all >> DSS devices which need it (omapdss_dss, omapdss_dsi1, omapdss_dsi2). >> >> I guess this needs dynamically adding the regulator supply in display.c, >> and I'm not quite sure if that's possible. We have to look at this. > > I don't see how this would be possible. As far as I see, the regulator > consumers have to be given statically at init time. We could get the > whole VPLL2 or VCXIO supply array from a common display code, but that > would prevent adding any other consumers to those regulators, so that's > not an option either. Also, I think the twl driver expects all the regulators to come from the twl4030_platform_data struct, so if we set vpll2 to NULL in twl4030_platform_data and declare it in our common display code, the twl driver will throw an error. Archit -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
* Tomi Valkeinen <tomi.valkeinen@ti.com> [110504 03:50]: > On Wed, 2011-05-04 at 12:40 +0300, Tony Lindgren wrote: > > * Archit Taneja <archit@ti.com> [110504 10:30]: > > > --- a/arch/arm/mach-omap2/board-3430sdp.c > > > +++ b/arch/arm/mach-omap2/board-3430sdp.c > > > @@ -401,7 +401,7 @@ static struct regulator_consumer_supply sdp3430_vdda_dac_supplies[] = { > > > /* VPLL2 for digital video outputs */ > > > static struct regulator_consumer_supply sdp3430_vpll2_supplies[] = { > > > REGULATOR_SUPPLY("vdds_dsi", "omapdss"), > > > - REGULATOR_SUPPLY("vdds_dsi", "omapdss_dsi1"), > > > + REGULATOR_SUPPLY("vdds_dsi", "omapdss_dsi.0"), > > > }; > > > > > > static struct regulator_consumer_supply sdp3430_vmmc1_supplies[] = { > > > diff --git a/arch/arm/mach-omap2/board-4430sdp.c b/arch/arm/mach-omap2/board-4430sdp.c > > > index 570e83f..eafadb4 100644 > > > --- a/arch/arm/mach-omap2/board-4430sdp.c > > > +++ b/arch/arm/mach-omap2/board-4430sdp.c > > > @@ -375,7 +375,7 @@ static struct regulator_consumer_supply sdp4430_vmmc_supply[] = { > > > }; > > > static struct regulator_consumer_supply sdp4430_vcxio_supply[] = { > > > REGULATOR_SUPPLY("vdds_dsi", "omapdss_dss"), > > > - REGULATOR_SUPPLY("vdds_dsi", "omapdss_dsi1"), > > > + REGULATOR_SUPPLY("vdds_dsi", "omapdss_dsi.0"), > > > }; > > ... > > > > 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". > > I was actually thinking about this earlier today. > > All the boards I have seen use vdds_dsi the same way (depending on the > omap version, though). For OMAP3 it comes from VPPL2 and for OMAP4 it's > VCXIO. Optimally a common piece of code would just set up the regulator > properly. > > But I think in the end the config has to come from the board data, as I > don't see that the above config would be the only possibility. The > vdds_dsi could be supplied from anywhere (with suitable voltage, of > course), as far as I understand. > > What we could do is: > > 1. The board file tells the common display code which regulator is used > for vdds_dsi, and the common code can setup the regulator supply for all > DSS devices which need it (omapdss_dss, omapdss_dsi1, omapdss_dsi2). > > I guess this needs dynamically adding the regulator supply in display.c, > and I'm not quite sure if that's possible. We have to look at this. > > 2. The common code could default to the power source that is most > commonly used, so the board file would have to config the regulator only > if it uses a non-common one. > > Together 1. and 2. would remove the DSS regulator stuff totally from the > board files. But regulators for the panels would still be in the board > files, of course. Sounds doable. And you could still allow overriding it if the typical configuration does not work. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, 2011-05-04 at 12:40 +0300, Tony Lindgren wrote: > * Archit Taneja <archit@ti.com> [110504 10:30]: > > --- a/arch/arm/mach-omap2/board-3430sdp.c > > +++ b/arch/arm/mach-omap2/board-3430sdp.c > > @@ -401,7 +401,7 @@ static struct regulator_consumer_supply sdp3430_vdda_dac_supplies[] = { > > /* VPLL2 for digital video outputs */ > > static struct regulator_consumer_supply sdp3430_vpll2_supplies[] = { > > REGULATOR_SUPPLY("vdds_dsi", "omapdss"), > > - REGULATOR_SUPPLY("vdds_dsi", "omapdss_dsi1"), > > + REGULATOR_SUPPLY("vdds_dsi", "omapdss_dsi.0"), > > }; > > > > static struct regulator_consumer_supply sdp3430_vmmc1_supplies[] = { > > diff --git a/arch/arm/mach-omap2/board-4430sdp.c b/arch/arm/mach-omap2/board-4430sdp.c > > index 570e83f..eafadb4 100644 > > --- a/arch/arm/mach-omap2/board-4430sdp.c > > +++ b/arch/arm/mach-omap2/board-4430sdp.c > > @@ -375,7 +375,7 @@ static struct regulator_consumer_supply sdp4430_vmmc_supply[] = { > > }; > > static struct regulator_consumer_supply sdp4430_vcxio_supply[] = { > > REGULATOR_SUPPLY("vdds_dsi", "omapdss_dss"), > > - REGULATOR_SUPPLY("vdds_dsi", "omapdss_dsi1"), > > + REGULATOR_SUPPLY("vdds_dsi", "omapdss_dsi.0"), > > }; > ... > > 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. Tomi -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
* Tomi Valkeinen <tomi.valkeinen@ti.com> [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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, 2011-05-05 at 04:50 -0700, Tony Lindgren wrote: > * Tomi Valkeinen <tomi.valkeinen@ti.com> [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.. The problem with that approach is that there could be other users for the same regulator, so the consumer_supplies list could also need to contain some other entries than dss. Then again, I guess those cases are minority, so we would still get majority of the board files cleaned up. Thanks for the idea, I'll try this approach. Tomi -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, May 09, 2011 at 06:34:34PM +0300, Tomi Valkeinen wrote: > 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. Right, makes sense. > 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. For this I'd suggest setting up an arrangement with supplies where you have one thing on the OMAP is supplied by board configuration and then it has child supplies within the device but right now that's not so easy to do. I was just writing some stuff for that this afternoon but it'll be next week before I can test it properly. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, 2011-05-09 at 21:19 +0200, Mark Brown wrote: > On Mon, May 09, 2011 at 06:34:34PM +0300, Tomi Valkeinen wrote: > > 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. > > For this I'd suggest setting up an arrangement with supplies where you > have one thing on the OMAP is supplied by board configuration and then > it has child supplies within the device but right now that's not so easy > to do. I was just writing some stuff for that this afternoon but it'll > be next week before I can test it properly. This sounds just the thing we need here. Do you think there's a chance the code could get merged in the next window? And I'm also happy to test the code with omapdss, whenever you have something ready. I think we'll go forward with this patch set in a modified form: we'll leave the board files untouched and add the DSS driver parts (which is 99% of the patch set) with a small hack which makes things work with the current device setup. This means we won't be able to use the second DSI LCD yet, but getting the biggest bulk of code in is more important. Tomi -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/arch/arm/mach-omap2/board-3430sdp.c b/arch/arm/mach-omap2/board-3430sdp.c index 9afd087..9da362b 100644 --- a/arch/arm/mach-omap2/board-3430sdp.c +++ b/arch/arm/mach-omap2/board-3430sdp.c @@ -401,7 +401,7 @@ static struct regulator_consumer_supply sdp3430_vdda_dac_supplies[] = { /* VPLL2 for digital video outputs */ static struct regulator_consumer_supply sdp3430_vpll2_supplies[] = { REGULATOR_SUPPLY("vdds_dsi", "omapdss"), - REGULATOR_SUPPLY("vdds_dsi", "omapdss_dsi1"), + REGULATOR_SUPPLY("vdds_dsi", "omapdss_dsi.0"), }; static struct regulator_consumer_supply sdp3430_vmmc1_supplies[] = { diff --git a/arch/arm/mach-omap2/board-4430sdp.c b/arch/arm/mach-omap2/board-4430sdp.c index 570e83f..eafadb4 100644 --- a/arch/arm/mach-omap2/board-4430sdp.c +++ b/arch/arm/mach-omap2/board-4430sdp.c @@ -375,7 +375,7 @@ static struct regulator_consumer_supply sdp4430_vmmc_supply[] = { }; static struct regulator_consumer_supply sdp4430_vcxio_supply[] = { REGULATOR_SUPPLY("vdds_dsi", "omapdss_dss"), - REGULATOR_SUPPLY("vdds_dsi", "omapdss_dsi1"), + REGULATOR_SUPPLY("vdds_dsi", "omapdss_dsi.0"), }; static int omap4_twl6030_hsmmc_late_init(struct device *dev) diff --git a/arch/arm/mach-omap2/board-devkit8000.c b/arch/arm/mach-omap2/board-devkit8000.c index 65f9fde..81f9c64 100644 --- a/arch/arm/mach-omap2/board-devkit8000.c +++ b/arch/arm/mach-omap2/board-devkit8000.c @@ -279,7 +279,7 @@ static struct twl4030_gpio_platform_data devkit8000_gpio_data = { static struct regulator_consumer_supply devkit8000_vpll1_supplies[] = { REGULATOR_SUPPLY("vdds_dsi", "omapdss"), - REGULATOR_SUPPLY("vdds_dsi", "omapdss_dsi1"), + REGULATOR_SUPPLY("vdds_dsi", "omapdss_dsi.0"), }; /* VMMC1 for MMC1 pins CMD, CLK, DAT0..DAT3 (20 mA, plus card == max 220 mA) */ diff --git a/arch/arm/mach-omap2/board-igep0020.c b/arch/arm/mach-omap2/board-igep0020.c index 34cf982..279a553 100644 --- a/arch/arm/mach-omap2/board-igep0020.c +++ b/arch/arm/mach-omap2/board-igep0020.c @@ -487,7 +487,7 @@ static struct omap_dss_board_info igep2_dss_data = { static struct regulator_consumer_supply igep2_vpll2_supplies[] = { REGULATOR_SUPPLY("vdds_dsi", "omapdss"), - REGULATOR_SUPPLY("vdds_dsi", "omapdss_dsi1"), + REGULATOR_SUPPLY("vdds_dsi", "omapdss_dsi.0"), }; static struct regulator_init_data igep2_vpll2 = { diff --git a/arch/arm/mach-omap2/board-omap3beagle.c b/arch/arm/mach-omap2/board-omap3beagle.c index 33007fd..8197d0d 100644 --- a/arch/arm/mach-omap2/board-omap3beagle.c +++ b/arch/arm/mach-omap2/board-omap3beagle.c @@ -236,7 +236,7 @@ static struct regulator_consumer_supply beagle_vdac_supply = static struct regulator_consumer_supply beagle_vdvi_supplies[] = { REGULATOR_SUPPLY("vdds_dsi", "omapdss"), - REGULATOR_SUPPLY("vdds_dsi", "omapdss_dsi1"), + REGULATOR_SUPPLY("vdds_dsi", "omapdss_dsi.0"), }; static void __init beagle_display_init(void) diff --git a/arch/arm/mach-omap2/board-omap3evm.c b/arch/arm/mach-omap2/board-omap3evm.c index 5a1a916..e5b74f8 100644 --- a/arch/arm/mach-omap2/board-omap3evm.c +++ b/arch/arm/mach-omap2/board-omap3evm.c @@ -562,7 +562,7 @@ static struct regulator_init_data omap3_evm_vdac = { /* VPLL2 for digital video outputs */ static struct regulator_consumer_supply omap3_evm_vpll2_supplies[] = { REGULATOR_SUPPLY("vdds_dsi", "omapdss"), - REGULATOR_SUPPLY("vdds_dsi", "omapdss_dsi1"), + REGULATOR_SUPPLY("vdds_dsi", "omapdss_dsi.0"), }; static struct regulator_init_data omap3_evm_vpll2 = { diff --git a/arch/arm/mach-omap2/board-omap3pandora.c b/arch/arm/mach-omap2/board-omap3pandora.c index 07dba88..3554892 100644 --- a/arch/arm/mach-omap2/board-omap3pandora.c +++ b/arch/arm/mach-omap2/board-omap3pandora.c @@ -347,7 +347,7 @@ static struct regulator_consumer_supply pandora_vdda_dac_supply = static struct regulator_consumer_supply pandora_vdds_supplies[] = { REGULATOR_SUPPLY("vdds_sdi", "omapdss"), REGULATOR_SUPPLY("vdds_dsi", "omapdss"), - REGULATOR_SUPPLY("vdds_dsi", "omapdss_dsi1"), + REGULATOR_SUPPLY("vdds_dsi", "omapdss_dsi.0"), }; static struct regulator_consumer_supply pandora_vcc_lcd_supply = diff --git a/arch/arm/mach-omap2/board-omap3stalker.c b/arch/arm/mach-omap2/board-omap3stalker.c index a6e0b91..c369e8e 100644 --- a/arch/arm/mach-omap2/board-omap3stalker.c +++ b/arch/arm/mach-omap2/board-omap3stalker.c @@ -459,7 +459,7 @@ static struct regulator_init_data omap3_stalker_vdac = { /* VPLL2 for digital video outputs */ static struct regulator_consumer_supply omap3_stalker_vpll2_supplies[] = { REGULATOR_SUPPLY("vdds_dsi", "omapdss"), - REGULATOR_SUPPLY("vdds_dsi", "omapdss_dsi1"), + REGULATOR_SUPPLY("vdds_dsi", "omapdss_dsi.0"), }; static struct regulator_init_data omap3_stalker_vpll2 = { diff --git a/arch/arm/mach-omap2/board-overo.c b/arch/arm/mach-omap2/board-overo.c index 59ca333..e281c7e 100644 --- a/arch/arm/mach-omap2/board-overo.c +++ b/arch/arm/mach-omap2/board-overo.c @@ -380,7 +380,7 @@ static struct regulator_consumer_supply overo_vdda_dac_supply = static struct regulator_consumer_supply overo_vdds_dsi_supply[] = { REGULATOR_SUPPLY("vdds_dsi", "omapdss"), - REGULATOR_SUPPLY("vdds_dsi", "omapdss_dsi1"), + REGULATOR_SUPPLY("vdds_dsi", "omapdss_dsi.0"), }; static struct mtd_partition overo_nand_partitions[] = { diff --git a/arch/arm/mach-omap2/board-zoom-peripherals.c b/arch/arm/mach-omap2/board-zoom-peripherals.c index 8dee754..6f75d7a 100644 --- a/arch/arm/mach-omap2/board-zoom-peripherals.c +++ b/arch/arm/mach-omap2/board-zoom-peripherals.c @@ -228,7 +228,7 @@ static struct omap2_hsmmc_info mmc[] = { static struct regulator_consumer_supply zoom_vpll2_supplies[] = { REGULATOR_SUPPLY("vdds_dsi", "omapdss"), - REGULATOR_SUPPLY("vdds_dsi", "omapdss_dsi1"), + REGULATOR_SUPPLY("vdds_dsi", "omapdss_dsi.0"), }; static struct regulator_consumer_supply zoom_vdda_dac_supply = diff --git a/arch/arm/mach-omap2/display.c b/arch/arm/mach-omap2/display.c index fa83eb3..f0e9cbf 100644 --- a/arch/arm/mach-omap2/display.c +++ b/arch/arm/mach-omap2/display.c @@ -74,7 +74,7 @@ static const struct omap_dss_hwmod_data omap3_dss_hwmod_data[] __initdata = { { "dss_dispc", "omapdss_dispc", -1 }, { "dss_rfbi", "omapdss_rfbi", -1 }, { "dss_venc", "omapdss_venc", -1 }, - { "dss_dsi1", "omapdss_dsi1", -1 }, + { "dss_dsi1", "omapdss_dsi", 0 }, }; static const struct omap_dss_hwmod_data omap4_dss_hwmod_data[] __initdata = { @@ -82,8 +82,7 @@ static const struct omap_dss_hwmod_data omap4_dss_hwmod_data[] __initdata = { { "dss_dispc", "omapdss_dispc", -1 }, { "dss_rfbi", "omapdss_rfbi", -1 }, { "dss_venc", "omapdss_venc", -1 }, - { "dss_dsi1", "omapdss_dsi1", -1 }, - { "dss_dsi2", "omapdss_dsi2", -1 }, + { "dss_dsi1", "omapdss_dsi", 0 }, { "dss_hdmi", "omapdss_hdmi", -1 }, }; diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c index 3d1dec3..6c528b7 100644 --- a/drivers/video/omap2/dss/dsi.c +++ b/drivers/video/omap2/dss/dsi.c @@ -4128,8 +4128,8 @@ static void dsi_exit(void) DSSDBG("omap_dsi_exit\n"); } -/* DSI1 HW IP initialisation */ -static int omap_dsi1hw_probe(struct platform_device *pdev) +/* DSI HW IP initialisation */ +static int omap_dsihw_probe(struct platform_device *pdev) { int r; dsi.pdev = pdev; @@ -4142,28 +4142,28 @@ err_dsi: return r; } -static int omap_dsi1hw_remove(struct platform_device *pdev) +static int omap_dsihw_remove(struct platform_device *pdev) { dsi_exit(); WARN_ON(dsi.scp_clk_refcount > 0); return 0; } -static struct platform_driver omap_dsi1hw_driver = { - .probe = omap_dsi1hw_probe, - .remove = omap_dsi1hw_remove, +static struct platform_driver omap_dsihw_driver = { + .probe = omap_dsihw_probe, + .remove = omap_dsihw_remove, .driver = { - .name = "omapdss_dsi1", + .name = "omapdss_dsi", .owner = THIS_MODULE, }, }; int dsi_init_platform_driver(void) { - return platform_driver_register(&omap_dsi1hw_driver); + return platform_driver_register(&omap_dsihw_driver); } void dsi_uninit_platform_driver(void) { - return platform_driver_unregister(&omap_dsi1hw_driver); + return platform_driver_unregister(&omap_dsihw_driver); }
Currently, there are 2 differently named platform devices generated for the 2 DSS DSI modules. In order to use the same driver, the dsi devices should be 2 instances of the same platform device. Change the platform device name from "omapdss_dsi1" to omapdss_dsi". Propagate this change across all omap board files which need to use this new name. Don't create a DSI2 platform device instance for now. Signed-off-by: Archit Taneja <archit@ti.com> --- arch/arm/mach-omap2/board-3430sdp.c | 2 +- arch/arm/mach-omap2/board-4430sdp.c | 2 +- arch/arm/mach-omap2/board-devkit8000.c | 2 +- arch/arm/mach-omap2/board-igep0020.c | 2 +- arch/arm/mach-omap2/board-omap3beagle.c | 2 +- arch/arm/mach-omap2/board-omap3evm.c | 2 +- arch/arm/mach-omap2/board-omap3pandora.c | 2 +- arch/arm/mach-omap2/board-omap3stalker.c | 2 +- arch/arm/mach-omap2/board-overo.c | 2 +- arch/arm/mach-omap2/board-zoom-peripherals.c | 2 +- arch/arm/mach-omap2/display.c | 5 ++--- drivers/video/omap2/dss/dsi.c | 18 +++++++++--------- 12 files changed, 21 insertions(+), 22 deletions(-)