RE: DSS2 and power supplies

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> -----Original Message-----
> From: linux-omap-owner@xxxxxxxxxxxxxxx [mailto:linux-omap-
> owner@xxxxxxxxxxxxxxx] On Behalf Of Grazvydas Ignotas
> Sent: Monday, December 07, 2009 3:57 PM
> To: Tomi Valkeinen
> Cc: linux-omap@xxxxxxxxxxxxxxx
> Subject: Re: DSS2 and power supplies
> 
> On Mon, Dec 7, 2009 at 10:44 AM, Tomi Valkeinen
> <tomi.valkeinen@xxxxxxxxx> wrote:
> > Hi,
> >
> > On Fri, 2009-12-04 at 11:53 +0100, ext Grazvydas Ignotas wrote:
> >> hi,
> >>
> >> it seems DSS block in OMAP needs SDI/DSI supplies to operate
> properly
> >> even with parallel displays, or else it doesn't drive some data
> lines
> >> resulting in missing/wrong colors. Take a look at figure 15-1 on
> OMAP3
> >> TRM (page 2119 on spruf98d), some dss_data lines are going out of
> >> SDI/DSI blocks, which are fed by vdds_sdi and vdds_dsi supplies
> >> (vdss_sdi in fig 15-1 seems to be a typo). Those 2 are typically
> >> connected to VPLL2 on TWL4030/TPS65950 (see fig. 25-2 on p3482),
> so
> >> that regulator needs to be activated for proper operation (if you
> have
> >> a parallel display and a board with TWL4030 you can reproduce
> this by
> >> not enabling VPLL2 in bootloader and kernel; mainline u-boot
> enables
> >> it).
> >
> > Hmm, this would explain the color errors. Have you seen this on
> some
> > other board than TI's SDP?
> >
> > 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.

Thanks,
Vaibhav

> >
> >> Right now DSS2 requests vdds_dsi in DSI driver only, any plans to
> >> request vdds_dsi/vdds_sdi for parallel displays too?
> >
> > I didn't have any plans, but if what you said is true, it sure
> needs to
> > be added.
> 
> Yeah that would be nice.
> 
> >
> >  Tomi
> >
> > Ps. Adding l-o, as others may be interested also.
> >
> >
> >
> --
> 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
--
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

[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux