On 18/02/2021 07:57, Tony Lindgren wrote:
- Tomi Valkeinen tomi.valkeinen@ideasonboard.com [210217 07:42]:
On 11/02/2021 19:35, Tony Lindgren wrote:
- Tomi Valkeinen tomi.valkeinen@ideasonboard.com [210211 07:35]:
On 08/02/2021 19:55, Tony Lindgren wrote:
Hi,
- Tomi Valkeinen tomi.valkeinen@ti.com [201124 12:47]:
From: Sebastian Reichel sebastian.reichel@collabora.com
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.
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...
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