[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