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

H. Nikolaus Schaller hns at goldelico.com
Tue Dec 18 19:07:19 CET 2018

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 
< 4.19-10
> 4.20-rc7
< DISPC_IRQSTATUS                                    000000a2
> DISPC_IRQSTATUS                                    00000000
< DISPC_CONTROL                                      00018309
> DISPC_CONTROL                                      00018308
< DISPC_LINE_STATUS                                  00000288
> DISPC_LINE_STATUS                                  00000fff
< DISPC_OVL_BA0(GFX)                                 d0003440
< DISPC_OVL_BA1(GFX)                                 d0003440
> DISPC_OVL_BA0(GFX)                                 7fb00000
> DISPC_OVL_BA1(GFX)                                 7fb00000
< DISPC_OVL_ATTRIBUTES(GFX)                          220040b1
> DISPC_OVL_ATTRIBUTES(GFX)                          020040b0
< DISPC_OVL_ROW_INC(GFX)                             000034c1
> DISPC_OVL_ROW_INC(GFX)                             000004c1
< DSI_VC_CTRL(0)                      20808f91
> DSI_VC_CTRL(0)                      20808f81
< 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

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,

-------------- 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>

More information about the Letux-kernel mailing list