* v3.6-rc1 DSS issues/regression
@ 2012-08-06 16:47 Aaro Koskinen
2012-08-06 17:24 ` Tomi Valkeinen
0 siblings, 1 reply; 9+ messages in thread
From: Aaro Koskinen @ 2012-08-06 16:47 UTC (permalink / raw)
To: linux-omap, archit; +Cc: tomi.valkeinen
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.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: v3.6-rc1 DSS issues/regression
2012-08-06 16:47 v3.6-rc1 DSS issues/regression Aaro Koskinen
@ 2012-08-06 17:24 ` Tomi Valkeinen
2012-08-06 17:36 ` Archit Taneja
2012-08-06 21:09 ` Aaro Koskinen
0 siblings, 2 replies; 9+ messages in thread
From: Tomi Valkeinen @ 2012-08-06 17:24 UTC (permalink / raw)
To: Aaro Koskinen; +Cc: linux-omap, archit
[-- 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 --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: v3.6-rc1 DSS issues/regression
2012-08-06 17:24 ` Tomi Valkeinen
@ 2012-08-06 17:36 ` Archit Taneja
2012-08-06 22:14 ` Aaro Koskinen
2012-08-06 21:09 ` Aaro Koskinen
1 sibling, 1 reply; 9+ messages in thread
From: Archit Taneja @ 2012-08-06 17:36 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: Aaro Koskinen, linux-omap
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
>
^ permalink raw reply related [flat|nested] 9+ messages in thread
* Re: v3.6-rc1 DSS issues/regression
2012-08-06 17:24 ` Tomi Valkeinen
2012-08-06 17:36 ` Archit Taneja
@ 2012-08-06 21:09 ` Aaro Koskinen
1 sibling, 0 replies; 9+ messages in thread
From: Aaro Koskinen @ 2012-08-06 21:09 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: linux-omap, archit
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.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: v3.6-rc1 DSS issues/regression
2012-08-06 17:36 ` Archit Taneja
@ 2012-08-06 22:14 ` Aaro Koskinen
2012-08-07 6:35 ` Archit Taneja
0 siblings, 1 reply; 9+ messages in thread
From: Aaro Koskinen @ 2012-08-06 22:14 UTC (permalink / raw)
To: Archit Taneja; +Cc: Tomi Valkeinen, linux-omap
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.
^ permalink raw reply related [flat|nested] 9+ messages in thread
* Re: v3.6-rc1 DSS issues/regression
2012-08-06 22:14 ` Aaro Koskinen
@ 2012-08-07 6:35 ` Archit Taneja
2012-08-07 13:22 ` Tomi Valkeinen
0 siblings, 1 reply; 9+ messages in thread
From: Archit Taneja @ 2012-08-07 6:35 UTC (permalink / raw)
To: Aaro Koskinen; +Cc: Tomi Valkeinen, linux-omap
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: v3.6-rc1 DSS issues/regression
2012-08-07 6:35 ` Archit Taneja
@ 2012-08-07 13:22 ` Tomi Valkeinen
2012-08-14 21:31 ` Aaro Koskinen
0 siblings, 1 reply; 9+ messages in thread
From: Tomi Valkeinen @ 2012-08-07 13:22 UTC (permalink / raw)
To: Archit Taneja, Aaro Koskinen; +Cc: linux-omap
[-- 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 --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: v3.6-rc1 DSS issues/regression
2012-08-07 13:22 ` Tomi Valkeinen
@ 2012-08-14 21:31 ` Aaro Koskinen
2012-08-15 6:50 ` Tomi Valkeinen
0 siblings, 1 reply; 9+ messages in thread
From: Aaro Koskinen @ 2012-08-14 21:31 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: Archit Taneja, linux-omap
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.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: v3.6-rc1 DSS issues/regression
2012-08-14 21:31 ` Aaro Koskinen
@ 2012-08-15 6:50 ` Tomi Valkeinen
0 siblings, 0 replies; 9+ messages in thread
From: Tomi Valkeinen @ 2012-08-15 6:50 UTC (permalink / raw)
To: Aaro Koskinen; +Cc: Archit Taneja, linux-omap
[-- 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 --]
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2012-08-15 6:50 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-08-06 16:47 v3.6-rc1 DSS issues/regression Aaro Koskinen
2012-08-06 17:24 ` Tomi Valkeinen
2012-08-06 17:36 ` Archit Taneja
2012-08-06 22:14 ` Aaro Koskinen
2012-08-07 6:35 ` Archit Taneja
2012-08-07 13:22 ` Tomi Valkeinen
2012-08-14 21:31 ` Aaro Koskinen
2012-08-15 6:50 ` Tomi Valkeinen
2012-08-06 21:09 ` Aaro Koskinen
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.