Re: [Intel-gfx] [PATCH v2] drm/i915/edp/jsl: Update vswing table for HBR and HBR2

["Ville Syrjälä" <ville.syrjala@linux.intel.com>]

On Tue, Sep 29, 2020 at 02:01:44PM -0700, Matt Roper wrote:
> On Tue, Sep 29, 2020 at 11:30:22PM +0300, Ville Syrjälä wrote:
> > On Tue, Sep 29, 2020 at 08:20:22PM +0000, Souza, Jose wrote:
> > > On Tue, 2020-09-29 at 23:02 +0300, Ville Syrjälä wrote:
> > > > On Tue, Sep 29, 2020 at 07:33:45PM +0000, Souza, Jose wrote:
> > > > > On Tue, 2020-09-29 at 17:41 +0530, Tejas Upadhyay wrote:
> > > > > > JSL has update in vswing table for eDP
> > > > > 
> > > > > Would be nice to mention in the commit description why PCH is being used, that would avoid Ville's question.
> > > > 
> > > > If the thing has nothing to do PCH then it should not use the PCH type
> > > > for the the check. Instead we should just do the EHL/JSL split.
> > > 
> > > In the first version Matt Roper suggested to use PCH to differentiate between EHL and JSL, Jani also agreed with this solution.This 2 PCHs can only be
> > > associate with EHL and JSL respectively, so no downsides here.
> > 
> > The downside is that the code makes no sense on the first glance.
> > It's going to generate a "wtf?" exception in the brain and require
> > me to take a second look to figure what is going on. Exception
> > handling is expensive and shouldn't be needed in cases where it's
> > trivial to make the code 100% obvious.
> 
> The bspec documents EHL and JSL as being the same platform and identical
> in all programming since they are literally the same display IP; this
> vswing table is the one and only place where the two are treated in a
> distinct manner for reasons that lie outside the display controller.  If
> you had to stop and take a closer look at the code here, that's a
> probably a good thing since in general there should generally never be a
> difference in the behavior between the two.  Adding an additional
> clarifying comment is probably in order too since this is a very
> exceptional special case.
> 
> If we deviate from the bspec's guidance and try to split IS_ELKHARTLAKE
> and IS_JASPERLAKE across the whole driver, that's going to be a lot more
> pain to maintain down the road since we'll almost certainly have cases
> where someone silently leaves one or the other off a condition and gets
> unexepcted behavior.  I could see arguments for using a SUBPLATFORM here
> like we do for TGL_U vs TGL_Y, but even that seems like overkill if we
> already have a clear way to distinguish the two cases (PCH pairing) and
> can just leave a clarifying comment.

That fixed PCH pairing is totally undocumented AFAICS. And vswing has
nothing to do with the south display, so the wtf will still happen.
Comment or no comment.

-- 
Ville Syrjälä
Intel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx