Hi,
On Tue, Feb 11, 2025 at 2:16 PM Doug Anderson <diand...@chromium.org> wrote:
>
> Hi,
>
> On Tue, Feb 4, 2025 at 7:01 AM Maxime Ripard <mrip...@kernel.org> wrote:
> >
> > @@ -374,12 +377,15 @@ static int __maybe_unused ti_sn65dsi86_resume(struct
> > device *dev)
> > * panel (including the aux channel) w/out any need for an input
> > clock
> > * so we can do it in resume which lets us read the EDID before
> > * pre_enable(). Without a reference clock we need the MIPI
> > reference
> > * clock so reading early doesn't work.
> > */
> > - if (pdata->refclk)
> > - ti_sn65dsi86_enable_comms(pdata);
> > + if (pdata->refclk) {
> > + drm_modeset_lock(&pdata->bridge.base.lock, NULL);
> > + ti_sn65dsi86_enable_comms(pdata,
> > drm_bridge_get_current_state(&pdata->bridge));
> > + drm_modeset_unlock(&pdata->bridge.base.lock);
>
> Oh. I haven't tested yet (my device is at home, but I think there is
> an easy solution to my deadlock problems. Drop the modeset locks here
> and just pass NULL for the state. We only end up here if
> "pdata->refclk" is not NULL. Then we only use the passed state if
> "pdata->refclk" _is_ NULL.
I can confirm this works. At the very least I was able to boot up both
with a hardcoded panel and with "edp-panel" and both worked. Seems
like a good solution for your patch.
Long term we should probably get rid of the support for working
without a "refclk". It's theoretically possible to use the hardware
that way and some super early prototypes I worked on used that. ...but
it's a bad idea and I'm fairly certain nobody is _actually_ using it.
That means that the code for handling it is likely not tested and may
have bugs.
-Doug
