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