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@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. So it seems that my conjecture: > Am 05.08.2020 um 13:49 schrieb H. Nikolaus Schaller <hns@xxxxxxxxxxxxx>: > > 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@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 >
