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

Tony Lindgren tony at atomide.com
Thu Feb 25 12:46:43 UTC 2021


* Tomi Valkeinen <tomi.valkeinen at ideasonboard.com> [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?

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

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

Regards,

Tony


More information about the dri-devel mailing list