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@xxxxxxxxxxxxxxx> 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@xxxxxxxxxxxx> > > > > > > > > > > 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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
