On 18/02/2021 07:57, Tony Lindgren wrote:

* Tomi Valkeinen [off-list ref] [210217 07:42]:

quoted

On 11/02/2021 19:35, Tony Lindgren wrote:

quoted

* Tomi Valkeinen [off-list ref] [210211 07:35]:

quoted

On 08/02/2021 19:55, Tony Lindgren wrote:

quoted

Hi,

* Tomi Valkeinen [off-list ref] [201124 12:47]:

quoted

From: Sebastian Reichel <redacted>

In preparation for removing custom DSS calls from the DSI
panel driver, this moves support for external tearing event
GPIOs into the DSI host driver. This way tearing events are
always handled in the core resulting in simplification of
the panel drivers.

The TE GPIO acquisition follows works in the same way as the
exynos DSI implementation.

Looks like this patch causes the following warnings:

DSI: omapdss DSI error: Failed to receive BTA
DSI: omapdss DSI error: bta sync failed
DSI: omapdss DSI error: vc(0) busy when trying to config for VP
DSI: omapdss DSI error: Failed to receive BTA
DSI: omapdss DSI error: bta sync failed
DSI: omapdss DSI error: vc(0) busy when trying to config for VP
DSI: omapdss DSI error: Failed to receive BTA
DSI: omapdss DSI error: bta sync failed
DSI: omapdss DSI error: vc(0) busy when trying to config for VP
...

Any ideas? The display works for me despite the constant
warnings.

Which board is that? Do the errors start right from the boot, or only
after running something in userspace?

This is with droid4, that's about the only device I use with a display
on regular basis. I'm pretty sure some earlier version of Sebastian's
patches worked fine.

OMAP4 SDP doesn't produce these errors and the HW looks rather
identical. Although I noticed something odd there, running kmstest
--flip on the first display works fine, but running on the second
display gets a bit erratic fps. Which is a bit odd as everything should
be identical.

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.

quoted

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

quoted

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.

Or maybe a DSS or DSI reset via SYSCONFIG at probe would help, or panel
reset if it has such a feature.

 Tomi