| Message ID | 5287AB20.9070407@collabora.co.uk (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Hi Javier, On Sat, Nov 16, 2013 at 06:28:00PM +0100, Javier Martinez Canillas wrote: > > The hack, as being sent by Javier, will result in the wrong > > regulator being used on the Nokia N900, which is using vaux1. > > It must depend on the machine. > > I see, so this hack is not generic enough to be usable for all OMAP3 boards so I > think is better to just add the hack on the DTS. > > I was more found about adding a hack on dpi.c since the DTB is an stable ABI > while the dpi.c implementation is not. I agree with this. My suggestion would be to get the vdds_dsi regulator name from platform data. This way each board can setup its own quirk until omapdss supports DT. > But I guess is not that bad to change the DTS later once DSS DT > bindings are added to mainline. As far as I know DT bindings are supposed to be as stable as possible. > > At the same time the N900 device tree file uses V28 as > > regulator-name for vaux1 (which is the same one as legacy boot > > used). Nothing depends on this, but I don't think it's a > > good idea to use this property. Apparently it does not work > > if multiple drivers need the same regulator under different > > names. > > > > -- Sebastian > > > > So, what do you think about the following patch instead? > > [PATCH] For Nokia N900 vaux1 is also used for si4713 radio chip, lis3lv02d accelerometer and battery cover sensor, so I don't like this hack. If vppl2 is only used for omapdss.dsi on IGEP boards it might be sensible to label it, though? So it might be ok there. -- Sebastian
Hi Sebastian, On 11/17/2013 01:26 AM, Sebastian Reichel wrote: > Hi Javier, > > On Sat, Nov 16, 2013 at 06:28:00PM +0100, Javier Martinez Canillas wrote: >> > The hack, as being sent by Javier, will result in the wrong >> > regulator being used on the Nokia N900, which is using vaux1. >> > It must depend on the machine. >> >> I see, so this hack is not generic enough to be usable for all OMAP3 boards so I >> think is better to just add the hack on the DTS. >> >> I was more found about adding a hack on dpi.c since the DTB is an stable ABI >> while the dpi.c implementation is not. > > I agree with this. My suggestion would be to get the vdds_dsi regulator name > from platform data. This way each board can setup its own quirk until omapdss > supports DT. > >> But I guess is not that bad to change the DTS later once DSS DT >> bindings are added to mainline. > > As far as I know DT bindings are supposed to be as stable as > possible. > Indeed, although as far as I understood on the latest ARM kernel summit it was decided that DT bindings (and DTS) can be changed in incompatible ways if it can be reasonably argued that nobody will be affected by the change. IMHO this is the case for IGEP boards since the vendor (ISEE) is still shipping the boards using an old 2.6.37 forked kernel that uses board files. So I think is reasonable to remove this DT hack later once we have omapdss + CDF bindings in mainline since current users that choose to use the mainline kernel instead of the vendor one have to be able to replace the stock kernel + bootloader that comes with the boards anyways. >> > At the same time the N900 device tree file uses V28 as >> > regulator-name for vaux1 (which is the same one as legacy boot >> > used). Nothing depends on this, but I don't think it's a >> > good idea to use this property. Apparently it does not work >> > if multiple drivers need the same regulator under different >> > names. >> > >> > -- Sebastian >> > >> >> So, what do you think about the following patch instead? >> >> [PATCH] > > For Nokia N900 vaux1 is also used for si4713 radio chip, lis3lv02d > accelerometer and battery cover sensor, so I don't like this hack. > > If vppl2 is only used for omapdss.dsi on IGEP boards it might be > sensible to label it, though? So it might be ok there. > Yes, you can't use this hack for the N900 since other devices already use the vaux1 regulator named as "V28" so you can't just rename it to "vdds_dsi". But for IGEP boards vpll2 is only used for omapdss DPI so we don't have that issue. Let's see what Tomi says that is the best way to handle this to have DVI working with DT until the propers bindings land in mainline. > -- Sebastian > Thanks a lot for your feedback and best regards, Javier -- 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/boot/dts/omap3-igep0020.dts b/arch/arm/boot/dts/omap3-igep0020.dts index b9a9e17..1c7e74d 100644 --- a/arch/arm/boot/dts/omap3-igep0020.dts +++ b/arch/arm/boot/dts/omap3-igep0020.dts @@ -215,3 +215,8 @@ &usbhsehci { phys = <&hsusb1_phy>; }; + +&vpll2 { + /* Needed for DSS */ + regulator-name = "vdds_dsi"; +};