Hi,
On Mon, Mar 31, 2025 at 6:52 PM Dmitry Baryshkov
<dmitry.barysh...@oss.qualcomm.com> wrote:
>
> > > ...although I think you said that the DRM framework ignores errors
> > > from prepare() and still calls unprepare(). I guess this is in
> > > panel_bridge_atomic_pre_enable() where drm_panel_prepare()'s error
> > > code is ignored?
> >
>
> Hmm... Most of the drivers ignore the results of the drm_panel_prepare()
> / _unprepare() / _enable() / _disable(), but then the framework handles
> error values of the callbacks and skips calling the corresponding
> en/dis callback if the previous call has failed. Which means I was
> incorrect here.
Oh, right. LOL, that was even me adding that code in commit
d2aacaf07395 ("drm/panel: Check for already prepared/enabled in
drm_panel"). It wasn't my intention there to work around the fact that
the panel_bridge ignores the error, but it's a happy accident. I guess
that means that the warning:
dev_warn(panel->dev, "Skipping unprepare of already unprepared panel\n");
...would also happen any time a panel prepare returned an error code
that was ignored by the bridge. That seems OK-ish to me even if the
comment above the warning doesn't list that as one of the reasons the
warning might be printed. I didn't test this myself, but assuming I
got it right does anyone want to submit a patch to add this reason to
the comment? ...or, maybe even better, we could fix the panel bridge
code to not call the panel unprepare if the prepare failed...
tl;dr for Tejas in this patch is that I still think he should spin his
patch to fix it so the regulators get disabled in the error case.
-Doug
