[Letux-kernel] DSI panels with omapdrm on 4.20-rc

[H. Nikolaus Schaller]

Hi Tomi,

> Am 18.12.2018 um 13:05 schrieb Tomi Valkeinen <tomi.valkeinen at ti.com>:
> 
> On 18/12/18 13:21, H. Nikolaus Schaller wrote:
>> Hi all,
>> I am still fighting to get our DSI panel on OMAP5 working again with
>> 4.20-rc.
>> 
>>> Am 20.11.2018 um 10:17 schrieb H. Nikolaus Schaller <hns at goldelico.com>:
>>> 
>>> Hi,
>>> 
>>>> Am 19.11.2018 um 15:18 schrieb Sebastian Reichel <sre at kernel.org>:
>>>> 
>>>> Hi,
>>>> 
>>>>> So how can I debug the panel->enable()?
>>>>> Where should it be called from dss core?
>>>>> Then I could check the conditions to call enable().
>>>> 
>>>> This is called in omap_encoder_enable(). For debugging I suggest to
>>>> add "drm.debug=0xf" kernel argument. "drm/omap: don't check dispc
>>>> timings for DSI" fixes a similar problem for panel-dsi-cm.
>>> 
>>> I have checked that and it looks all reasonable and I did enable
>>> the same on the 4.19 kernel and they are basically the same (some
>>> not obviously significant diffs in sequence or connector numbers).
>> 
>> We now have added Sebastian's latest patches and found a small bug in
>> our panel driver that prevented it from being enabled in v4.20-rc.
>> 
>> And we also include:
>> * drm/omap: Work around missing DISPC in runtime PM handlers
> 
> That shouldn't be needed with -rc7.
> 
>> Firstly, /sys/kernel/debug/omapdss/clk does not include the DSI1 clocks.
>> Therefore
>> I can't check if dividers etc. are correct.
> 
> It's "dsi1_clks".

Ah, I see. Clocks are now in separate files.

I didn't notice because I reused the same script as for 4.19 and didn't update.

> 
>> And trying to read dsi1_regs ends in a NULL pointer dereference in
>> dsi_runtime_get()
>> called from dsi_dump_dsi_regs().
> 
> Ok... I guess we have broken the debug facilities.
> 
> How's it with the attached patch?

Yes, this patch solves the NULL pointer problem!

Now I get the attached debug register sets.

Good news: the clock and dividers are set up 100% the same now.
Bad news: panel is still black with blakc background (backlight on).

Good for debugging: there aren't many diffs:

iMac:master hns$ diff 4.19.txt 4.20.txt 
1c1
< 4.19-10
---
> 4.20-rc7
38c38
< DISPC_IRQSTATUS                                    000000a2
---
> DISPC_IRQSTATUS                                    00000000
40c40
< DISPC_CONTROL                                      00018309
---
> DISPC_CONTROL                                      00018308
43c43
< DISPC_LINE_STATUS                                  00000288
---
> DISPC_LINE_STATUS                                  00000fff
93,94c93,94
< DISPC_OVL_BA0(GFX)                                 d0003440
< DISPC_OVL_BA1(GFX)                                 d0003440
---
> DISPC_OVL_BA0(GFX)                                 7fb00000
> DISPC_OVL_BA1(GFX)                                 7fb00000
97c97
< DISPC_OVL_ATTRIBUTES(GFX)                          220040b1
---
> DISPC_OVL_ATTRIBUTES(GFX)                          020040b0
100c100
< DISPC_OVL_ROW_INC(GFX)                             000034c1
---
> DISPC_OVL_ROW_INC(GFX)                             000004c1
374c374
< DSI_VC_CTRL(0)                      20808f91
---
> DSI_VC_CTRL(0)                      20808f81
404c404
< DSI_DSIPHY_CFG2                     b800000f
---
> DSI_DSIPHY_CFG2                     b83c000f
iMac:master hns$ 


I think we can probably ignore the LINE_STATUS and the OVL things and IRQSTATUS.
So the remaning diffs are

DISPC_CONTROL	bit 0
DSI_VC_CTRL(0)  bit 4		which may be the problem behind the VC(x) error (but the error did not appear this time)
DSI_DSIPHY_CFG2	bits 16-23

BR and thanks,
Nikolaus


-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: 4.19.txt
URL: <http://lists.goldelico.com/pipermail/letux-kernel/attachments/20181218/d100a21f/attachment-0002.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: 4.20.txt
URL: <http://lists.goldelico.com/pipermail/letux-kernel/attachments/20181218/d100a21f/attachment-0003.txt>