[PATCH v4 24/80] drm/omap: dsi: move TE GPIO handling into core

Tomi Valkeinen tomi.valkeinen at ideasonboard.com
Mon Feb 22 08:47:06 UTC 2021


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


More information about the dri-devel mailing list