[Intel-gfx] [PATCH 03/11] drm/i915: Disable HDCP signalling on transcoder disable

[Daniel Vetter]

On Mon, Dec 09, 2019 at 11:13:36AM -0500, Sean Paul wrote:
> On Mon, Dec 9, 2019 at 10:18 AM Ville Syrjälä
> <ville.syrjala at linux.intel.com> wrote:
> >
> > On Fri, Dec 06, 2019 at 08:55:09AM -0500, Sean Paul wrote:
> > > On Thu, Dec 05, 2019 at 09:33:19PM +0200, Ville Syrjälä wrote:
> > > > On Tue, Dec 03, 2019 at 12:36:26PM -0500, Sean Paul wrote:
> > > > > From: Sean Paul <seanpaul at chromium.org>
> > > > >
> > > > > Currently we rely on intel_hdcp_disable() to disable HDCP signalling in
> > > > > the DDI Function Control register. This patch adds a safety net by also
> > > > > clearing the bit when we disable the transcoder.
> > > > >
> > > > > Once we have HDCP over MST and disappearing connectors, we want to make
> > > > > sure that the signalling is truly disabled even if HDCP teardown doesn't
> > > > > go as planned.
> > > >
> > > > Why wouldn't it go as planned?
> > > >
> > >
> > > Because things can fail in weird and wonderful ways on unplug :-)
> >
> > Not really.
> >
> 
> That is a bold position to take, bugs happen, hardware flakes, etc.
> 
> > >
> > > It's a safety net. I saw this function and figured HDCP signalling should be
> > > explicitly cleared here as well.
> >
> > I call it dead and confusing code.
> 
> ...adding a bit to an existing register clear is confusing? That might
> be a touch hyperbolic.
> 
> > If we get here with HDCP still
> > enabled we have a more serious bug somewhere else.
> >
> 
> Ok, I suppose it's your call as to whether you take this patch, feel
> free to drop.

Maybe some expansion on this discussion here. We've had super-defensive
modeset code back 10 years ago when i915 started.

It was a mess, since all that "for safety" thing papered over real bugs,
except thanks to the safety net you mostly couldn't observe machines dying
for real. That's why we've gone pretty radical towards "you better know
what state your hw is in".

If you do want safatey, add a WARN_ON or similar that reads back hw state
and double checks it is what we think it should be. That's much better for
validating your driver than papering over all kinds of busg preemptively
and making the real ones very hard to track down.

tldr; WARN_ON hw/sw consistency safety checks good, "let me reclear/set
this" safety code bad. At least if it doesn't come with a huge WARN_ON
that things have gone terribly wrong so we can actually catch bugs in CI
and testing.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch