[Letux-kernel] module_mipi_dsi_driver panel with omapdrm?

[H. Nikolaus Schaller]

Hi David,
thanks for finding a fix faster than I could take a look at it!

> Am 06.08.2020 um 20:44 schrieb David Shah <dave at ds0.me>:
> 
> Following a bit of testing, the DSI issues are fixed by 
> https://github.com/daveshah1/pyra-kernel-devel/commit/3161275854a0f2cd44a55b8eb039bd201f894486
> (I will prepare a proper patch set shortly).
> This makes the display
> work with HDMI disabled.

So it seems that my conjecture:

> Am 05.08.2020 um 13:49 schrieb H. Nikolaus Schaller <hns at goldelico.com>:
> 
> There are 715a5a978733f0 and 671ab615bd507f which arrived in v5.7-rc1 as well
> and are related to hdmi clocks. So this may be (or not) an influencing factor.

was almost true. You patch seems to fix
5a507162f096b5 ("ARM: dts: Configure interconnect target module for omap5 dsi1")

> There also seems to be a race condition between the hdmi0 connector
> and tpd12s015 "encoder". This results in the tpd12s015 permanently
> returning EPROBE_DEFER and the display subsystem never successfully
> probing.
> 
> Reversing the order of the encoder and connector in the device tree
> (omap5-board-common.dtsi) makes the display work again with HDMI
> enabled; as does adding some printks to the display-connector driver.

Good to know where to look at.

So we will then have a fix for v5.7 and v5.8 and can start to test/compare
our module_mipi_dsi_driver with Sebastian's patches as soon as they
arrive and see what happens.

BR and thanks,
Nikolaus

> 
> On Thu, 2020-08-06 at 17:04 +0100, David Shah wrote:
>> Sorry, my error. I forgot the Pyra is LPAE and therefore using 64-bit
>> physical addresses.
>> 
>> The start is indeed a correct physical address, 0x58005000, but off
>> by
>> 0x1000 from what the DSI driver is expecting.
>> 
>> On Thu, 2020-08-06 at 16:50 +0100, David Shah wrote:
>>> I had a moment to give letux-5.7.y a test on the Pyra hardware.
>>> 
>>> I notice an error in dmesg:
>>> 
>>> DSI: omapdss DSI error: unsupported DSI module
>>> 
>>> which comes from this code (with a small patch added by me):
>>> 
>>> 	d = dsi->data->modules;
>>> 	while (d->address != 0 && d->address != dsi_mem->start)
>>> 		d++;
>>> 
>>> 	if (d->address == 0) {
>>> 		DSSERR("unsupported DSI module (start: %08x)\n",
>>> dsi_mem->start);
>>> 		return -ENODEV;
>>> 	}
>>> 
>>> "start" here is c0b3ba5c - a kernel virtual address - which
>>> definitely
>>> doesn't seem right as it would never match. 
>>> 
>>> Not sure my kernel-fu is quite up to tracking this down yet, but I
>>> will
>>> keep trying to trace out what is happening.
>>> 
>>> Best
>>> 
>>> Davidg
>>> 
>>> On Wed, 2020-08-05 at 15:08 +0300, Tomi Valkeinen wrote:
>>>> On 05/08/2020 14:49, H. Nikolaus Schaller wrote:
>>>>> Hi,
>>>>> 
>>>>>> Am 05.08.2020 um 13:28 schrieb Sebastian Reichel <
>>>>>> sebastian.reichel at collabora.com>:
>>>>>> 
>>>>>> Hi,
>>>>>> 
>>>>>> On Wed, Aug 05, 2020 at 11:19:20AM +0200, H. Nikolaus
>>>>>> Schaller
>>>>>> wrote:
>>>>>>> What I do not yet understand is how Laurent's patch should
>>>>>>> be
>>>>>>> able
>>>>>>> to break it.
>>>>>> 
>>>>>> omapdrm will not probe successfully if any DT enabled
>>>>>> component
>>>>>> does not probe correctly. Since the patch you identified
>>>>>> touched
>>>>>> HDMI and VENC and you are probably using HDMI, I suggest
>>>>>> looking
>>>>>> there first.
>>>>> 
>>>>> Yes, that is a very good explanation.
>>>>> 
>>>>> Maybe there is a subtle change in how the HDMI connector has to
>>>>> be
>>>>> defined
>>>>> which is missing in our (private) DTB. Maybe the OMAP5-uEVM DTS
>>>>> gives a hint.
>>>>> 
>>>>> A quick check shows last hdmi specific change for omap5-board-
>>>>> common or uevm
>>>>> was in 2017 but I may have missed something.
>>>>> 
>>>>> There are 715a5a978733f0 and 671ab615bd507f which arrived in
>>>>> v5.7-
>>>>> rc1 as well
>>>>> and are related to hdmi clocks. So this may be (or not) and
>>>>> influencing factor.
>>>> 
>>>> HDMI should "just work", and has been tested. But maybe there's
>>>> some
>>>> conflict with HDMI and DSI.
>>>> 
>>>> Tomi
>>>> 
>>> 
>>> _______________________________________________
>>> https://projects.goldelico.com/p/gta04-kernel/
>>> Letux-kernel mailing list
>>> Letux-kernel at openphoenux.org
>>> http://lists.goldelico.com/mailman/listinfo.cgi/letux-kernel
>> 
>> _______________________________________________
>> Kernel mailing list
>> Kernel at pyra-handheld.com
>> http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel
>