v3.6-rc1 DSS issues/regression

v3.6-rc1 DSS issues/regression

[Aaro Koskinen]

Hi,

I can't get the display on N900 (SDI, acx565akm) to work with v3.6-rc1
kernel, it's just full of flicker/noise.

According to git-bisect, the problem is introduced by the commit:

    commit f476ae9dab3234532d41d36beb4ba7be838fa786
    Author: Archit Taneja <archit@ti.com>
    Date:   Fri Jun 29 14:37:03 2012 +0530

    OMAPDSS: APPLY: Remove DISPC writes to manager's lcd parameters in interface

Any ideas?

Thanks,

A.

Re: v3.6-rc1 DSS issues/regression

[Tomi Valkeinen]

[-- Attachment #1: Type: text/plain, Size: 821 bytes --]

On Mon, 2012-08-06 at 19:47 +0300, Aaro Koskinen wrote:
> Hi,
> 
> I can't get the display on N900 (SDI, acx565akm) to work with v3.6-rc1
> kernel, it's just full of flicker/noise.
> 
> According to git-bisect, the problem is introduced by the commit:
> 
>     commit f476ae9dab3234532d41d36beb4ba7be838fa786
>     Author: Archit Taneja <archit@ti.com>
>     Date:   Fri Jun 29 14:37:03 2012 +0530
> 
>     OMAPDSS: APPLY: Remove DISPC writes to manager's lcd parameters in interface
> 
> Any ideas?

Looks strange, that particular commit more or less just moves the
writing of the configs to another place. And it works for DPI and DSI,
at least.

Can you take a dump of debugfs/omapdss/dss and debugfs/omapdss/dispc,
for both working and non-working versions, to see if there's a diff?

 Tomi


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: v3.6-rc1 DSS issues/regression

[Archit Taneja]

Hi,

On Monday 06 August 2012 10:54 PM, Tomi Valkeinen wrote:
> On Mon, 2012-08-06 at 19:47 +0300, Aaro Koskinen wrote:
>> Hi,
>>
>> I can't get the display on N900 (SDI, acx565akm) to work with v3.6-rc1
>> kernel, it's just full of flicker/noise.
>>
>> According to git-bisect, the problem is introduced by the commit:
>>
>>      commit f476ae9dab3234532d41d36beb4ba7be838fa786
>>      Author: Archit Taneja <archit@ti.com>
>>      Date:   Fri Jun 29 14:37:03 2012 +0530
>>
>>      OMAPDSS: APPLY: Remove DISPC writes to manager's lcd parameters in interface
>>
>> Any ideas?

Thanks for pointing this out.

The commit delays the register writes to a later point. But these 
registers are shadowed, i.e, they shouldn't take impact till the time 
the overlay manager is enabled. It's possible that some fields of the 
registers in question may have a direct impact, and hence messing up 
some sequence with respect to sdi registers.

The diff I have shared introduces the register writes back. This should 
make it work like before. But we need to figure out which parameter 
write needs to be done immediately. If this works, could you remove each 
dispc register write turn by turn, and point out which is the culprit one?

Sorry about the manual process, but we don't have any way to test SDI 
here :)

Thanks
Archit

diff --git a/drivers/video/omap2/dss/sdi.c b/drivers/video/omap2/dss/sdi.c
index 5d31699..d397e96 100644
--- a/drivers/video/omap2/dss/sdi.c
+++ b/drivers/video/omap2/dss/sdi.c
@@ -46,6 +46,22 @@ static void sdi_config_lcd_manager(struct 
omap_dss_device *dssdev)
         sdi.mgr_config.video_port_width = 24;
         sdi.mgr_config.lcden_sig_polarity = 1;

+
+       dispc_mgr_set_io_pad_mode(sdi.mgr_config.io_pad_mode);
+       dispc_mgr_enable_stallmode(dssdev->manager->id,
+                       sdi.mgr_config.stallmode);
+       dispc_mgr_enable_fifohandcheck(dssdev->manager->id,
+                       sdi.mgr_config.fifohandcheck);
+
+       dispc_mgr_set_clock_div(dssdev->manager->id,
+                       &sdi.mgr_config.clock_info);
+
+       dispc_mgr_set_tft_data_lines(dssdev->manager->id,
+                       sdi.mgr_config.video_port_width);
+       dispc_lcd_enable_signal_polarity(sdi.mgr_config.lcden_sig_polarity);
+
+       dispc_mgr_set_lcd_type_tft(dssdev->manager->id);
+

>
> Looks strange, that particular commit more or less just moves the
> writing of the configs to another place. And it works for DPI and DSI,
> at least.
>
> Can you take a dump of debugfs/omapdss/dss and debugfs/omapdss/dispc,
> for both working and non-working versions, to see if there's a diff?
>
>   Tomi
>

Re: v3.6-rc1 DSS issues/regression

[Aaro Koskinen]

Hi,

On Mon, Aug 06, 2012 at 11:06:28PM +0530, Archit Taneja wrote:
> >On Mon, 2012-08-06 at 19:47 +0300, Aaro Koskinen wrote:
> >>I can't get the display on N900 (SDI, acx565akm) to work with v3.6-rc1
> >>kernel, it's just full of flicker/noise.
> >>
> >>According to git-bisect, the problem is introduced by the commit:
> >>
> >>     commit f476ae9dab3234532d41d36beb4ba7be838fa786
> >>     Author: Archit Taneja <archit@ti.com>
> >>     Date:   Fri Jun 29 14:37:03 2012 +0530
> >>
> >>     OMAPDSS: APPLY: Remove DISPC writes to manager's lcd parameters in interface

[...]

> The diff I have shared introduces the register writes back. This
> should make it work like before. But we need to figure out which
> parameter write needs to be done immediately. If this works, could
> you remove each dispc register write turn by turn, and point out
> which is the culprit one?

Thanks, the following one makes the display to work again:

diff --git a/drivers/video/omap2/dss/sdi.c b/drivers/video/omap2/dss/sdi.c
index 5d31699..3c9f598 100644
--- a/drivers/video/omap2/dss/sdi.c
+++ b/drivers/video/omap2/dss/sdi.c
@@ -46,6 +46,9 @@ static void sdi_config_lcd_manager(struct omap_dss_device *dssdev)
 	sdi.mgr_config.video_port_width = 24;
 	sdi.mgr_config.lcden_sig_polarity = 1;
 
+	dispc_mgr_set_clock_div(dssdev->manager->id,
+				&sdi.mgr_config.clock_info);
+
 	dss_mgr_set_lcd_config(dssdev->manager, &sdi.mgr_config);
 }
 
A.

Re: v3.6-rc1 DSS issues/regression

[Archit Taneja]

On Tuesday 07 August 2012 03:44 AM, Aaro Koskinen wrote:
> Hi,
>
> On Mon, Aug 06, 2012 at 11:06:28PM +0530, Archit Taneja wrote:
>>> On Mon, 2012-08-06 at 19:47 +0300, Aaro Koskinen wrote:
>>>> I can't get the display on N900 (SDI, acx565akm) to work with v3.6-rc1
>>>> kernel, it's just full of flicker/noise.
>>>>
>>>> According to git-bisect, the problem is introduced by the commit:
>>>>
>>>>      commit f476ae9dab3234532d41d36beb4ba7be838fa786
>>>>      Author: Archit Taneja <archit@ti.com>
>>>>      Date:   Fri Jun 29 14:37:03 2012 +0530
>>>>
>>>>      OMAPDSS: APPLY: Remove DISPC writes to manager's lcd parameters in interface
>
> [...]
>
>> The diff I have shared introduces the register writes back. This
>> should make it work like before. But we need to figure out which
>> parameter write needs to be done immediately. If this works, could
>> you remove each dispc register write turn by turn, and point out
>> which is the culprit one?
>
> Thanks, the following one makes the display to work again:
>
> diff --git a/drivers/video/omap2/dss/sdi.c b/drivers/video/omap2/dss/sdi.c
> index 5d31699..3c9f598 100644
> --- a/drivers/video/omap2/dss/sdi.c
> +++ b/drivers/video/omap2/dss/sdi.c
> @@ -46,6 +46,9 @@ static void sdi_config_lcd_manager(struct omap_dss_device *dssdev)
>   	sdi.mgr_config.video_port_width = 24;
>   	sdi.mgr_config.lcden_sig_polarity = 1;
>
> +	dispc_mgr_set_clock_div(dssdev->manager->id,
> +				&sdi.mgr_config.clock_info);
> +

Thanks for finding this. It's a bit peculiar why this is happening. The 
DISPC_DIVISOR is a shadow register for sure.

I don't know much about SDI, but it looks like the SDI PLL needs the 
free running pixel clock from the LCD manager. To achieve this, we set 
PCKFREEENABLE. The thing I don't understand is that whether the free 
running pixel clock at this point would be derived out of the old LCD 
and PCD values, or the new ones? It should have been old since LCD and 
PCD are shadowed registers.

In other words, I am suspecting that the field PCKFREEENABLE does a copy 
of the LCD and PCD dividers from the shadow registers to the working 
registers.

The regdump shows that there were issues in SDI initialization.

Tomi,

Any ideas about this?

Archit

Re: v3.6-rc1 DSS issues/regression

[Tomi Valkeinen]

[-- Attachment #1: Type: text/plain, Size: 3011 bytes --]

On Tue, 2012-08-07 at 12:05 +0530, Archit Taneja wrote:
> On Tuesday 07 August 2012 03:44 AM, Aaro Koskinen wrote:
> > Hi,
> >
> > On Mon, Aug 06, 2012 at 11:06:28PM +0530, Archit Taneja wrote:
> >>> On Mon, 2012-08-06 at 19:47 +0300, Aaro Koskinen wrote:
> >>>> I can't get the display on N900 (SDI, acx565akm) to work with v3.6-rc1
> >>>> kernel, it's just full of flicker/noise.
> >>>>
> >>>> According to git-bisect, the problem is introduced by the commit:
> >>>>
> >>>>      commit f476ae9dab3234532d41d36beb4ba7be838fa786
> >>>>      Author: Archit Taneja <archit@ti.com>
> >>>>      Date:   Fri Jun 29 14:37:03 2012 +0530
> >>>>
> >>>>      OMAPDSS: APPLY: Remove DISPC writes to manager's lcd parameters in interface
> >
> > [...]
> >
> >> The diff I have shared introduces the register writes back. This
> >> should make it work like before. But we need to figure out which
> >> parameter write needs to be done immediately. If this works, could
> >> you remove each dispc register write turn by turn, and point out
> >> which is the culprit one?
> >
> > Thanks, the following one makes the display to work again:
> >
> > diff --git a/drivers/video/omap2/dss/sdi.c b/drivers/video/omap2/dss/sdi.c
> > index 5d31699..3c9f598 100644
> > --- a/drivers/video/omap2/dss/sdi.c
> > +++ b/drivers/video/omap2/dss/sdi.c
> > @@ -46,6 +46,9 @@ static void sdi_config_lcd_manager(struct omap_dss_device *dssdev)
> >   	sdi.mgr_config.video_port_width = 24;
> >   	sdi.mgr_config.lcden_sig_polarity = 1;
> >
> > +	dispc_mgr_set_clock_div(dssdev->manager->id,
> > +				&sdi.mgr_config.clock_info);
> > +
> 
> Thanks for finding this. It's a bit peculiar why this is happening. The 
> DISPC_DIVISOR is a shadow register for sure.
> 
> I don't know much about SDI, but it looks like the SDI PLL needs the 
> free running pixel clock from the LCD manager. To achieve this, we set 
> PCKFREEENABLE. The thing I don't understand is that whether the free 
> running pixel clock at this point would be derived out of the old LCD 
> and PCD values, or the new ones? It should have been old since LCD and 
> PCD are shadowed registers.
> 
> In other words, I am suspecting that the field PCKFREEENABLE does a copy 
> of the LCD and PCD dividers from the shadow registers to the working 
> registers.
> 
> The regdump shows that there were issues in SDI initialization.
> 
> Tomi,
> 
> Any ideas about this?

No real ideas. I think adding the line above, and a big HACK comment
above it, is ok for the time being. It's quite simple hack and shouldn't
cause any problems anywhere.

Aaro, if you have spare time, you could test and move the call to
dispc_mgr_set_clock_div later, and see where calling it stops fixing the
issue. 

My guess is that calling it after dss_sdi_init() will still work, but
calling it after dss_sdi_enable() does not work. And most likely inside
dss_sdi_enable() it won't work if placed after dispc_pck_free_enable(). 

 Tomi


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: v3.6-rc1 DSS issues/regression

[Aaro Koskinen]

Hi,

On Tue, Aug 07, 2012 at 04:22:02PM +0300, Tomi Valkeinen wrote:
> On Tue, 2012-08-07 at 12:05 +0530, Archit Taneja wrote:
> > On Tuesday 07 August 2012 03:44 AM, Aaro Koskinen wrote:
> > > On Mon, Aug 06, 2012 at 11:06:28PM +0530, Archit Taneja wrote:
> > >>> On Mon, 2012-08-06 at 19:47 +0300, Aaro Koskinen wrote:
> > >>>> I can't get the display on N900 (SDI, acx565akm) to work with v3.6-rc1
> > >>>> kernel, it's just full of flicker/noise.
> > >>>>
> > >>>> According to git-bisect, the problem is introduced by the commit:
> > >>>>
> > >>>>      commit f476ae9dab3234532d41d36beb4ba7be838fa786
> > >>>>      Author: Archit Taneja <archit@ti.com>
> > >>>>      Date:   Fri Jun 29 14:37:03 2012 +0530
> > >>>>
> > >>>>      OMAPDSS: APPLY: Remove DISPC writes to manager's lcd parameters in interface
> > >
> > > [...]
> > >
> > >> The diff I have shared introduces the register writes back. This
> > >> should make it work like before. But we need to figure out which
> > >> parameter write needs to be done immediately. If this works, could
> > >> you remove each dispc register write turn by turn, and point out
> > >> which is the culprit one?
> > >
> > > Thanks, the following one makes the display to work again:
> > >
> > > diff --git a/drivers/video/omap2/dss/sdi.c b/drivers/video/omap2/dss/sdi.c
> > > index 5d31699..3c9f598 100644
> > > --- a/drivers/video/omap2/dss/sdi.c
> > > +++ b/drivers/video/omap2/dss/sdi.c
> > > @@ -46,6 +46,9 @@ static void sdi_config_lcd_manager(struct omap_dss_device *dssdev)
> > >   	sdi.mgr_config.video_port_width = 24;
> > >   	sdi.mgr_config.lcden_sig_polarity = 1;
> > >
> > > +	dispc_mgr_set_clock_div(dssdev->manager->id,
> > > +				&sdi.mgr_config.clock_info);
> > > +
> > 
> > Thanks for finding this. It's a bit peculiar why this is happening. The 
> > DISPC_DIVISOR is a shadow register for sure.
> > 
> > I don't know much about SDI, but it looks like the SDI PLL needs the 
> > free running pixel clock from the LCD manager. To achieve this, we set 
> > PCKFREEENABLE. The thing I don't understand is that whether the free 
> > running pixel clock at this point would be derived out of the old LCD 
> > and PCD values, or the new ones? It should have been old since LCD and 
> > PCD are shadowed registers.
> > 
> > In other words, I am suspecting that the field PCKFREEENABLE does a copy 
> > of the LCD and PCD dividers from the shadow registers to the working 
> > registers.
> > 
> > The regdump shows that there were issues in SDI initialization.
> > 
> > Tomi,
> > 
> > Any ideas about this?
> 
> No real ideas. I think adding the line above, and a big HACK comment
> above it, is ok for the time being. It's quite simple hack and shouldn't
> cause any problems anywhere.

Will you be sending a patch (i.e. the HACK mentioned above) to fix this
during the 3.6-rc cycle?

> Aaro, if you have spare time, you could test and move the call to
> dispc_mgr_set_clock_div later, and see where calling it stops fixing the
> issue. 
> 
> My guess is that calling it after dss_sdi_init() will still work, but
> calling it after dss_sdi_enable() does not work. And most likely inside
> dss_sdi_enable() it won't work if placed after dispc_pck_free_enable(). 

You are right that dss_sdi_enable() is the critical function. According
to my tests, the exact breaking point is the

	/* Waiting for PLL to lock */

loop. If dispc_mgr_set_clock_div() is called before it works, but if I
put it after the loop the display fails to work.

A.

Re: v3.6-rc1 DSS issues/regression

[Tomi Valkeinen]

[-- Attachment #1: Type: text/plain, Size: 4038 bytes --]

On Wed, 2012-08-15 at 00:31 +0300, Aaro Koskinen wrote:
> Hi,
> 
> On Tue, Aug 07, 2012 at 04:22:02PM +0300, Tomi Valkeinen wrote:
> > On Tue, 2012-08-07 at 12:05 +0530, Archit Taneja wrote:
> > > On Tuesday 07 August 2012 03:44 AM, Aaro Koskinen wrote:
> > > > On Mon, Aug 06, 2012 at 11:06:28PM +0530, Archit Taneja wrote:
> > > >>> On Mon, 2012-08-06 at 19:47 +0300, Aaro Koskinen wrote:
> > > >>>> I can't get the display on N900 (SDI, acx565akm) to work with v3.6-rc1
> > > >>>> kernel, it's just full of flicker/noise.
> > > >>>>
> > > >>>> According to git-bisect, the problem is introduced by the commit:
> > > >>>>
> > > >>>>      commit f476ae9dab3234532d41d36beb4ba7be838fa786
> > > >>>>      Author: Archit Taneja <archit@ti.com>
> > > >>>>      Date:   Fri Jun 29 14:37:03 2012 +0530
> > > >>>>
> > > >>>>      OMAPDSS: APPLY: Remove DISPC writes to manager's lcd parameters in interface
> > > >
> > > > [...]
> > > >
> > > >> The diff I have shared introduces the register writes back. This
> > > >> should make it work like before. But we need to figure out which
> > > >> parameter write needs to be done immediately. If this works, could
> > > >> you remove each dispc register write turn by turn, and point out
> > > >> which is the culprit one?
> > > >
> > > > Thanks, the following one makes the display to work again:
> > > >
> > > > diff --git a/drivers/video/omap2/dss/sdi.c b/drivers/video/omap2/dss/sdi.c
> > > > index 5d31699..3c9f598 100644
> > > > --- a/drivers/video/omap2/dss/sdi.c
> > > > +++ b/drivers/video/omap2/dss/sdi.c
> > > > @@ -46,6 +46,9 @@ static void sdi_config_lcd_manager(struct omap_dss_device *dssdev)
> > > >   	sdi.mgr_config.video_port_width = 24;
> > > >   	sdi.mgr_config.lcden_sig_polarity = 1;
> > > >
> > > > +	dispc_mgr_set_clock_div(dssdev->manager->id,
> > > > +				&sdi.mgr_config.clock_info);
> > > > +
> > > 
> > > Thanks for finding this. It's a bit peculiar why this is happening. The 
> > > DISPC_DIVISOR is a shadow register for sure.
> > > 
> > > I don't know much about SDI, but it looks like the SDI PLL needs the 
> > > free running pixel clock from the LCD manager. To achieve this, we set 
> > > PCKFREEENABLE. The thing I don't understand is that whether the free 
> > > running pixel clock at this point would be derived out of the old LCD 
> > > and PCD values, or the new ones? It should have been old since LCD and 
> > > PCD are shadowed registers.
> > > 
> > > In other words, I am suspecting that the field PCKFREEENABLE does a copy 
> > > of the LCD and PCD dividers from the shadow registers to the working 
> > > registers.
> > > 
> > > The regdump shows that there were issues in SDI initialization.
> > > 
> > > Tomi,
> > > 
> > > Any ideas about this?
> > 
> > No real ideas. I think adding the line above, and a big HACK comment
> > above it, is ok for the time being. It's quite simple hack and shouldn't
> > cause any problems anywhere.
> 
> Will you be sending a patch (i.e. the HACK mentioned above) to fix this
> during the 3.6-rc cycle?

Yes, I'll queue it up.

> > Aaro, if you have spare time, you could test and move the call to
> > dispc_mgr_set_clock_div later, and see where calling it stops fixing the
> > issue. 
> > 
> > My guess is that calling it after dss_sdi_init() will still work, but
> > calling it after dss_sdi_enable() does not work. And most likely inside
> > dss_sdi_enable() it won't work if placed after dispc_pck_free_enable(). 
> 
> You are right that dss_sdi_enable() is the critical function. According
> to my tests, the exact breaking point is the
> 
> 	/* Waiting for PLL to lock */
> 
> loop. If dispc_mgr_set_clock_div() is called before it works, but if I
> put it after the loop the display fails to work.

That's interesting. I think that basically tells us that the shadow
register mechanism is somehow bypassed for pck-free. And if so, then the
above hack is not really a hack at all, but something required.

 Tomi


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: v3.6-rc1 DSS issues/regression

[Aaro Koskinen]

Hi,

On Mon, Aug 06, 2012 at 08:24:28PM +0300, Tomi Valkeinen wrote:
> On Mon, 2012-08-06 at 19:47 +0300, Aaro Koskinen wrote:
> > Hi,
> > 
> > I can't get the display on N900 (SDI, acx565akm) to work with v3.6-rc1
> > kernel, it's just full of flicker/noise.
> > 
> > According to git-bisect, the problem is introduced by the commit:
> > 
> >     commit f476ae9dab3234532d41d36beb4ba7be838fa786
> >     Author: Archit Taneja <archit@ti.com>
> >     Date:   Fri Jun 29 14:37:03 2012 +0530
> > 
> >     OMAPDSS: APPLY: Remove DISPC writes to manager's lcd parameters in interface
> > 
> > Any ideas?
> 
> Looks strange, that particular commit more or less just moves the
> writing of the configs to another place. And it works for DPI and DSI,
> at least.
> 
> Can you take a dump of debugfs/omapdss/dss and debugfs/omapdss/dispc,
> for both working and non-working versions, to see if there's a diff?

Here's a diff:

--- dss-n900-ok	2012-08-06 23:54:07.000000000 +0300
+++ dss-n900-broken	2012-08-06 23:51:08.000000000 +0300
@@ -1,150 +1,150 @@
 # cat clk
 - DSS -
 dpll4_ck 432000000
 DSS_FCK (DSS1_ALWON_FCLK) = 432000000 / 12 * 2 = 72000000
 - DISPC -
 dispc fclk source = DSS_FCK (DSS1_ALWON_FCLK)
 fck		72000000        
 - LCD -
 LCD clk source = DSS_FCK (DSS1_ALWON_FCLK)
 lck		72000000        lck div	1
 pck		24000000        pck div	3
 # cat dispc
 DISPC_REVISION                                     00000030
 DISPC_SYSCONFIG                                    00002015
 DISPC_SYSSTATUS                                    00000001
 DISPC_IRQSTATUS                                    000100a2
 DISPC_IRQENABLE                                    0000d640
 DISPC_CONTROL                                      38018309
 DISPC_CONFIG                                       00004204
 DISPC_CAPABLE                                      000003ff
-DISPC_LINE_STATUS                                  00000036
+DISPC_LINE_STATUS                                  000000bf
 DISPC_LINE_NUMBER                                  00000000
 DISPC_GLOBAL_ALPHA                                 000000ff
 DISPC_DEFAULT_COLOR(LCD)                           00000000
 DISPC_TRANS_COLOR(LCD)                             00000000
 DISPC_SIZE_MGR(LCD)                                01df031f
 DISPC_DEFAULT_COLOR(LCD)                           00000000
 DISPC_TRANS_COLOR(LCD)                             00000000
 DISPC_TIMING_H(LCD)                                01701b03
 DISPC_TIMING_V(LCD)                                00400302
 DISPC_POL_FREQ(LCD)                                00033000
 DISPC_DIVISORo(LCD)                                00010003
 DISPC_SIZE_MGR(LCD)                                01df031f
 DISPC_DATA_CYCLE1(LCD)                             00000000
 DISPC_DATA_CYCLE2(LCD)                             00000000
 DISPC_DATA_CYCLE3(LCD)                             00000000
 DISPC_CPR_COEF_R(LCD)                              00000000
 DISPC_CPR_COEF_G(LCD)                              00000000
 DISPC_CPR_COEF_B(LCD)                              00000000
 DISPC_DEFAULT_COLOR(TV)                            00000000
 DISPC_TRANS_COLOR(TV)                              00000000
 DISPC_SIZE_MGR(TV)                                 00000000
 DISPC_OVL_BA0(GFX)                                 8f000000
 DISPC_OVL_BA1(GFX)                                 8f000000
 DISPC_OVL_POSITION(GFX)                            00000000
 DISPC_OVL_SIZE(GFX)                                01df031f
 DISPC_OVL_ATTRIBUTES(GFX)                          000000ad
 DISPC_OVL_FIFO_THRESHOLD(GFX)                      0bff03c0
 DISPC_OVL_FIFO_SIZE_STATUS(GFX)                    00000400
 DISPC_OVL_ROW_INC(GFX)                             00000001
 DISPC_OVL_PIXEL_INC(GFX)                           00000001
 DISPC_OVL_PRELOAD(GFX)                             00000100
 DISPC_OVL_WINDOW_SKIP(GFX)                         00000000
 DISPC_OVL_TABLE_BA(GFX)                            00000000
 DISPC_OVL_BA0(VID1)                                00000000
 DISPC_OVL_BA1(VID1)                                00000000
 DISPC_OVL_POSITION(VID1)                           00000000
 DISPC_OVL_SIZE(VID1)                               00000000
 DISPC_OVL_ATTRIBUTES(VID1)                         00008000
 DISPC_OVL_FIFO_THRESHOLD(VID1)                     00000000
 DISPC_OVL_FIFO_SIZE_STATUS(VID1)                   00000400
 DISPC_OVL_ROW_INC(VID1)                            00000001
 DISPC_OVL_PIXEL_INC(VID1)                          00000001
 DISPC_OVL_PRELOAD(VID1)                            00000100
 DISPC_OVL_FIR(VID1)                                00000000
 DISPC_OVL_PICTURE_SIZE(VID1)                       00000000
 DISPC_OVL_ACCU0(VID1)                              00000000
 DISPC_OVL_ACCU1(VID1)                              00000000
 DISPC_OVL_PRELOAD(VID1)                            00000100
 DISPC_OVL_BA0(VID2)                                00000000
 DISPC_OVL_BA1(VID2)                                00000000
 DISPC_OVL_POSITION(VID2)                           00000000
 DISPC_OVL_SIZE(VID2)                               00000000
 DISPC_OVL_ATTRIBUTES(VID2)                         00008000
 DISPC_OVL_FIFO_THRESHOLD(VID2)                     00000000
 DISPC_OVL_FIFO_SIZE_STATUS(VID2)                   00000400
 DISPC_OVL_ROW_INC(VID2)                            00000001
 DISPC_OVL_PIXEL_INC(VID2)                          00000001
 DISPC_OVL_PRELOAD(VID2)                            00000100
 DISPC_OVL_FIR(VID2)                                00000000
 DISPC_OVL_PICTURE_SIZE(VID2)                       00000000
 DISPC_OVL_ACCU0(VID2)                              00000000
 DISPC_OVL_ACCU1(VID2)                              00000000
 DISPC_OVL_PRELOAD(VID2)                            00000100
 DISPC_OVL_FIR_COEF_H_0(VID1)                       00000000
 DISPC_OVL_FIR_COEF_H_1(VID1)                       00000000
 DISPC_OVL_FIR_COEF_H_2(VID1)                       00000000
 DISPC_OVL_FIR_COEF_H_3(VID1)                       00000000
 DISPC_OVL_FIR_COEF_H_4(VID1)                       00000000
 DISPC_OVL_FIR_COEF_H_5(VID1)                       00000000
 DISPC_OVL_FIR_COEF_H_6(VID1)                       00000000
 DISPC_OVL_FIR_COEF_H_7(VID1)                       00000000
 DISPC_OVL_FIR_COEF_HV_0(VID1)                      00000000
 DISPC_OVL_FIR_COEF_HV_1(VID1)                      00000000
 DISPC_OVL_FIR_COEF_HV_2(VID1)                      00000000
 DISPC_OVL_FIR_COEF_HV_3(VID1)                      00000000
 DISPC_OVL_FIR_COEF_HV_4(VID1)                      00000000
 DISPC_OVL_FIR_COEF_HV_5(VID1)                      00000000
 DISPC_OVL_FIR_COEF_HV_6(VID1)                      00000000
 DISPC_OVL_FIR_COEF_HV_7(VID1)                      00000000
 DISPC_OVL_CONV_COEF_0(VID1)                        0199012a
 DISPC_OVL_CONV_COEF_1(VID1)                        012a0000
 DISPC_OVL_CONV_COEF_2(VID1)                        079c0730
 DISPC_OVL_CONV_COEF_3(VID1)                        0000012a
 DISPC_OVL_CONV_COEF_4(VID1)                        00000205
 DISPC_OVL_FIR_COEF_V_0(VID1)                       00000000
 DISPC_OVL_FIR_COEF_V_1(VID1)                       00000000
 DISPC_OVL_FIR_COEF_V_2(VID1)                       00000000
 DISPC_OVL_FIR_COEF_V_3(VID1)                       00000000
 DISPC_OVL_FIR_COEF_V_4(VID1)                       00000000
 DISPC_OVL_FIR_COEF_V_5(VID1)                       00000000
 DISPC_OVL_FIR_COEF_V_6(VID1)                       00000000
 DISPC_OVL_FIR_COEF_V_7(VID1)                       00000000
 DISPC_OVL_FIR_COEF_H_0(VID2)                       00000000
 DISPC_OVL_FIR_COEF_H_1(VID2)                       00000000
 DISPC_OVL_FIR_COEF_H_2(VID2)                       00000000
 DISPC_OVL_FIR_COEF_H_3(VID2)                       00000000
 DISPC_OVL_FIR_COEF_H_4(VID2)                       00000000
 DISPC_OVL_FIR_COEF_H_5(VID2)                       00000000
 DISPC_OVL_FIR_COEF_H_6(VID2)                       00000000
 DISPC_OVL_FIR_COEF_H_7(VID2)                       00000000
 DISPC_OVL_FIR_COEF_HV_0(VID2)                      00000000
 DISPC_OVL_FIR_COEF_HV_1(VID2)                      00000000
 DISPC_OVL_FIR_COEF_HV_2(VID2)                      00000000
 DISPC_OVL_FIR_COEF_HV_3(VID2)                      00000000
 DISPC_OVL_FIR_COEF_HV_4(VID2)                      00000000
 DISPC_OVL_FIR_COEF_HV_5(VID2)                      00000000
 DISPC_OVL_FIR_COEF_HV_6(VID2)                      00000000
 DISPC_OVL_FIR_COEF_HV_7(VID2)                      00000000
 DISPC_OVL_CONV_COEF_0(VID2)                        0199012a
 DISPC_OVL_CONV_COEF_1(VID2)                        012a0000
 DISPC_OVL_CONV_COEF_2(VID2)                        079c0730
 DISPC_OVL_CONV_COEF_3(VID2)                        0000012a
 DISPC_OVL_CONV_COEF_4(VID2)                        00000205
 DISPC_OVL_FIR_COEF_V_0(VID2)                       00000000
 DISPC_OVL_FIR_COEF_V_1(VID2)                       00000000
 DISPC_OVL_FIR_COEF_V_2(VID2)                       00000000
 DISPC_OVL_FIR_COEF_V_3(VID2)                       00000000
 DISPC_OVL_FIR_COEF_V_4(VID2)                       00000000
 DISPC_OVL_FIR_COEF_V_5(VID2)                       00000000
 DISPC_OVL_FIR_COEF_V_6(VID2)                       00000000
 DISPC_OVL_FIR_COEF_V_7(VID2)                       00000000
 # cat dss
 DSS_REVISION                        00000020
 DSS_SYSCONFIG                       00000001
 DSS_SYSSTATUS                       00000001
 DSS_CONTROL                         00000018
 DSS_SDI_CONTROL                     00078006
 DSS_PLL_CONTROL                     01c45968
-DSS_SDI_STATUS                      000000a5
+DSS_SDI_STATUS                      000000bd

A.