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

[Ville Syrjälä]

On Wed, Sep 30, 2020 at 12:11:48AM +0300, Ville Syrjälä wrote:
> 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.

Oh and JSP does not show up in bspec even once. MCC appears exactly once
where it talks about the differences between MCC and ICL-N PCH (which I
guess is the same as JSP?).

Furthermore the spec never really talks about EHL except in very select
places. So the IS_ELKHARTLAKE is already totally confusing and IMO more
likely to cause maintenance problems than the split. Making it
IS_JSL||IS_EHL at least gives the reader some hint as to where they
should look in the spec.

Another argument why the split is fine is CFL/CML. Those are more
or less exactly in the same boat as EHL. Ie. only really mentioned
in the "configurations" section. Beyond that only KBL is ever really
mentioned. And yet we have separate IS_FOOs for all of them, and
apparently no one had any objections to that situation.

tldr;we have an established way to handle these things, so IMO lets
just follow it and stop adding special cases.

-- 
Ville Syrjälä
Intel