On Thu, Dec 10, 2009 at 3:23 PM, Hiremath, Vaibhav <hvaibhav@xxxxxx> wrote: <snip> >> > >> > To me the fig 15-1 does not tell that the powers are needed. The >> > DSS_DATA[] pins do not come from SDI/DSI blocks, but from the main >> DSS >> > block. And the pin muxing component is outside also. This of >> course >> > doesn't really prove anything. =) >> >> True, but apparently vdds_dsi and/or vdds_sdi are also used to drive >> some data lines then (not supplying them produces blue-ish display >> with some parts missing). I'm working with pandora board, and I'm >> sure >> VPLL2 is not connected to anything else. >> > [Hiremath, Vaibhav] No, I think the "vdds_dsi" doesn't drive any data in parallel mode of operation. > I have also observed similar issue with OMAP3EVM, when you switch the output to DVI interface, you will get bluish image. > > The issue came out as VPLL2_DEV_GRP (Bits 7-5) register configuration. When you are working with LCD panel (in my case sharp-ls037v7dw01.c), this file calls regulator_get and regulator_enable functions which configures VPLL2_DEV_GRP to 0x2 [Owns to P1 device group]. > But when you switch the output to DVI, it doesn't do any regulator_get/enable call so the VPLL2_DEV_GRP register becomes 0 [Owns to no device group] leading to color loss. > > I am not regulator framework expert, so could not comment on what is the relation of VPLL2_DEV_GRP with this issue. > > So what is required here is, panel_generic.c also should enable regulator for "vdvi" > > I have a patch (tested on OMAP3EVM) which I submit once DSS2 goes in. I think this regulator is misnamed, does VPLL2 really power DVI on OMAP3EVM? Can you check the schematics? At least on pandora it's connected to vdds_dsi/vdds_sdi and has nothing to do with the panel. -- 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
