[Intel-gfx] [PATCH] drm/i915: Inherit Kabylake platform features from Skylake

[Rodrigo Vivi]

On Thu, Sep 28, 2017 at 05:00:53PM +0000, Chris Wilson wrote:
> Quoting Rodrigo Vivi (2017-09-28 17:33:48)
> > On Thu, Sep 28, 2017 at 02:59:13PM +0000, Chris Wilson wrote:
> > > I recently tried to update the gen9 feature matrix and to my unpleasant
> > > surprise found that Kabylake still acted like Broadwell and didn't
> > > enable the feature. This is because kbl/cfl are inheriting their
> > > defaults from Broadwell and not Skylake.
> > 
> > Hmm... I should've considered this would happen someday sooner than later...
> > My Bad...
> > 
> > > 
> > > Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>
> > > Cc: Rodrigo Vivi <rodrigo.vivi at intel.com>
> > > Cc: Paulo Zanoni <paulo.r.zanoni at intel.com>
> > > Cc: Mika Kuoppala <mika.kuoppala at linux.intel.com>
> > > ---
> > >  drivers/gpu/drm/i915/i915_pci.c | 21 +++++----------------
> > >  1 file changed, 5 insertions(+), 16 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
> > > index da60866b6628..01d4b569b2cc 100644
> > > --- a/drivers/gpu/drm/i915/i915_pci.c
> > > +++ b/drivers/gpu/drm/i915/i915_pci.c
> > > @@ -495,13 +495,9 @@ static const struct intel_device_info intel_geminilake_info __initconst = {
> > >  };
> > >  
> > >  #define KBL_PLATFORM \
> > > -     BDW_FEATURES, \
> > 
> > Note that BDW has _FEATURES and _PLATFORM.
> > The idea is that _FEATURES would be he place to get inherited
> > while platform was for that specific one and shouldn't be imported by a different platform.
> > so we wouldn't need to overwrite any specific value like .platform.
> > And we would have a placeholder for the specific values and features that we want only
> > on that particular platform and never propagated to newer ones.
> > 
> > But yeah... that is lame, fragile, non documented and caused confusion. Sorry.
> 
> I honestly don't mind, just my expectation was that cfl/kbl == skl +
> constant so that I could enable a feature in one gen and expect it to
> forward propagate (and I prefer intel_device_info for its debug/error
> reporting and opportunity for its fine granularity).
> 
> I don't think you want to mix the platform name with features then, i.e.
> GEN8_FEATURES, GEN8_LP_FEATURES
> GEN9_FEATURES, GEN9_LP_FEATURES
> 
> #define KBL_PLATFORM GEN9_FEATURES, ...

Good idea.
Only doubt is how to rename HSW_FEATURES
GEN7_5_FEATURES ?
GEN75_FEATURES ?
or just leave HSW_FEATURES as the exception?

> 
> > >  static const struct intel_device_info intel_cannonlake_gt2_info __initconst = {
> > > -     BDW_FEATURES,
> > > +     SKL_PLATFORM,
> > 
> > my OCD doesn't like to read cannonlake as skylake platform...
> 
> We don't appear to support Cannonlake as a whole ;)
> Just a couple of CI devices?
> 
> > So maybe we should just kill "_PLATFORM" and rename everything back to "FEATURES"
> > and on this case also it would be better for CFL to inherit KBL one and CNL inherit CFL one and on.
> 
> The FEATURES / PLATFORM split is fine, it can even extend to multiple
> inheritance (for as long as the last-one-wins rule works).
> -Chris