> -----Original Message----- > From: Tomi Valkeinen [mailto:tomi.valkeinen@xxxxxxxxx] > Sent: Monday, February 15, 2010 4:28 PM > To: Hiremath, Vaibhav > Cc: linux-omap@xxxxxxxxxxxxxxx; linux-fbdev@xxxxxxxxxxxxxxx > Subject: RE: [PATCH 01/13] OMAP: DSS2: enable VDDS_DSI when using > DPI > > On Mon, 2010-02-15 at 11:22 +0100, ext Hiremath, Vaibhav wrote: > > > -----Original Message----- > > > From: linux-omap-owner@xxxxxxxxxxxxxxx [mailto:linux-omap- > > > owner@xxxxxxxxxxxxxxx] On Behalf Of Tomi Valkeinen > > > Sent: Monday, February 08, 2010 9:26 PM > > > To: linux-omap@xxxxxxxxxxxxxxx; linux-fbdev@xxxxxxxxxxxxxxx > > > Cc: Tomi Valkeinen > > > Subject: [PATCH 01/13] OMAP: DSS2: enable VDDS_DSI when using > DPI > > > > > > It looks like on OMAP3 some DSS pins need VDDS_DSI to function > > > properly. > > > > > > This has not been confirmed from TI, but looking at figure 15-1 > > > "Display > > > subsystem highlight" from the TRM, some data pins come near the > DSI > > > and SDI > > > blocks. This is not very hard evidence, but the fact remains > that > > > with the > > > power on, pixels are ok, and with the power off, pixels are not > ok. > > > > > [Hiremath, Vaibhav] Tomi, sorry for delayed response. As usual > stuck with some other issues. Below are some quick comments - > > > > I am not regulator expert, but as per my finding I believe it is > nothing to do with pins position closure to each other. The actual > root cause is TWL4030 Ownership bit. Please refer to the below mail- > chain - > > > > http://marc.info/?l=linux-omap&m=126045146600334&w=2 > > But why is there a dependency on a regulator, if it has nothing to > do > with the pins? Why is vdds_dsi/vdds_sdi needed to get all pixels > through? [Hiremath, Vaibhav] I am not sure, what role ownership bit is playing here. Thanks, Vaibhav > > 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
