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
>
