Hi David, > Am 06.08.2020 um 20:44 schrieb David Shah <dave@xxxxxx>: > > 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. yes, it makes the LCD work (tested so far on 5.8-rc7). But even with HDMI enabled. > > 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. I didn't have to disable or reverse the order. Maybe the speed of the SD card also has an influcence... So I'll backport it to all our affected Letux kernels until it is merged/fixed upstream. Then we can work on debugging/testing a module_mipi_dsi_driver based panel drivers as soon as Sebastian's new patches become available. 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@xxxxxxxxxxxxx>: >>>>>> >>>>>> 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@xxxxxxxxxxxxxxx >>> http://lists.goldelico.com/mailman/listinfo.cgi/letux-kernel >> >> _______________________________________________ >> Kernel mailing list >> Kernel@xxxxxxxxxxxxxxxxx >> http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel >
