On 25/02/2021 14:46, Tony Lindgren wrote:
* Tomi Valkeinen <tomi.valkeinen@xxxxxxxxxxxxxxxx> [210222 08:47]:
On 18/02/2021 07:57, Tony Lindgren wrote:
Oh cool that you have those running again/still :) In this case there
is no te-gpios if that might make a difference.
No, GPIO TE is not used on OMAP4 SDP either.
OK
So these errors start from the boot? Or only when running something
specific?
They start from the boot when modules are loaded.
Normally there are no updates happening unless an userspace app is
running, but I guess you have fb console enabled, with the blinking
cursor which makes the updates.
I usually don't have fbcon enabled, but OMAP4 SDP works fine for me with
fbcon too...
I'm using loadable modules with omap2plus_defconfig in case that makes
a difference. Maybe there's some state preserved somewhere if deferred
probe happens?
I don't think the drivers do much unless probe succeeds. I'm also using
modules.
Is there a bootloader that initializes the display?
Yes it boots with kexec.
Is that open source? Can you disable the display setup from the
bootloader? Maybe the DSS or the panel is left into a state that for
whatever reason makes the kernel drivers break.
Well that's a signed kernel booting kexec. But it has been working
just fine for years now so I'd rather not blame that.
I'm just looking for the difference with droid4 and omap4 sdp so that I
could reproduce.
Or maybe a DSS or DSI reset via SYSCONFIG at probe would help, or panel
reset if it has such a feature.
Maybe. But why would the $subject patch cause the errors?
Hmm, if I read the code right, TE was not enabled at all before this
patch. And this patch enables it. So maybe TE has never worked with that
panel?
You could try changing the enable_te calls to pass false.
Or with the upstream driver, comment out
mipi_dsi_dcs_set_tear_on(ddata->dsi, MIPI_DSI_DCS_TEAR_MODE_VBLANK);
Tomi
