> -----Original Message----- > From: Roper, Matthew D <matthew.d.roper@xxxxxxxxx> > Sent: Saturday, October 26, 2024 12:28 AM > To: Kandpal, Suraj <suraj.kandpal@xxxxxxxxx> > Cc: Atwood, Matthew S <matthew.s.atwood@xxxxxxxxx>; intel- > xe@xxxxxxxxxxxxxxxxxxxxx; intel-gfx@xxxxxxxxxxxxxxxxxxxxx > Subject: Re: [PATCH v4 3/7] drm/i915/xe3lpd: Disable HDCP Line Rekeying for > Xe3 > > On Thu, Oct 24, 2024 at 02:52:14AM +0000, Kandpal, Suraj wrote: > > > > > > > -----Original Message----- > > > From: Roper, Matthew D <matthew.d.roper@xxxxxxxxx> > > > Sent: Wednesday, October 23, 2024 11:22 PM > > > To: Atwood, Matthew S <matthew.s.atwood@xxxxxxxxx> > > > Cc: intel-xe@xxxxxxxxxxxxxxxxxxxxx; intel-gfx@xxxxxxxxxxxxxxxxxxxxx; > > > Kandpal, Suraj <suraj.kandpal@xxxxxxxxx> > > > Subject: Re: [PATCH v4 3/7] drm/i915/xe3lpd: Disable HDCP Line > > > Rekeying for > > > Xe3 > > > > > > On Fri, Oct 18, 2024 at 01:03:07PM -0700, Matt Atwood wrote: > > > > From: Suraj Kandpal <suraj.kandpal@xxxxxxxxx> > > > > > > > > We need to disable HDCP Line Rekeying for Xe3 when we are using an > > > > HDMI encoder. > > > > > > This is still missing the "why" for this change. Is there a bspec > > > reference that gives the details? From the description of the bit > > > itself, it sounds like the setting here (for both Xe3 and earlier > > > Xe2) should be based on the HDCP version rather than the > platform/stepping. > > > > > > As mentioned previously, this entire function is labeled as "/* WA: > > > 16022217614 */" If we're now using this function for something > > > other than that specific workaround, then we need to fix/move that > comment. > > > > > > > > > > Bspec: 68933 > > I think you pasted the wrong number here? This is a generic page that just > has links to four transcoder DDI registers and nothing else. It doesn't have > anything to do with HDCP rekeying. > > Maybe you meant 69964 (which is one of the four links from the page > above) that gives the register definition of TRANS_DDI_FUNC_CTL? But the > info there implies that we're not really handling this properly since it says that > we need to enable/disable rekeying based on the HDCP version. We're > disabling for HDCP 2.0 and above here (correct), but I don't see where we're > handling the enabling for HDCP 1.4 and earlier? > Unless I'm overlooking something, it seems like the driver always updates > TRANS_DDI_FUNC_CTL with a rmw cycle rather than building a new value > from scratch, so we can't really rely on the bit being 0 by default for the cases > where rekeying should be enabled.