On 2019/08/05, Laurent Pinchart wrote: > Hi Sam, > > Thank you for the patch. > > On Sun, Aug 04, 2019 at 10:16:35PM +0200, Sam Ravnborg wrote: > > Many panel drivers duplicate logic to prevent prepare to be called > > for a panel that is already prepared. > > Likewise for enable. > > > > Implement this logic in drm_panel so the individual drivers > > no longer needs this. > > A panel is considered prepared/enabled only if the prepare/enable call > > succeeds. > > For disable/unprepare it is unconditionally considered > > disabled/unprepared. > > > > This allows calls to prepare/enable again, even if there were > > some issue disabling a regulator or similar during disable/unprepare. > > Is this the right place to handle this ? Shouldn't the upper layers > ensure than enable/disable and prepare/unprepare are correcty balanced, > and not called multiple times ? Adding enabled and prepared state to > drm_panel not only doesn't align well with atomic state handling, but > also would hide issues in upper layers that should really be fixed > there. > Fully agreed. Mistakes happen - hiding them, by returning "success" does not sound like a wise approach. HTH Emil
