Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
From:   Jani Nikula <jani.nikula@linux.intel.com>
To:     Christoph Hellwig <hch@lst.de>
Cc:     Zhi Wang <zhi.wang.linux@gmail.com>, hch@lst.de, jgg@nvidia.com,
        intel-gfx@lists.freedesktop.org,
        intel-gvt-dev@lists.freedesktop.org,
        dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org,
        Joonas Lahtinen <joonas.lahtinen@linux.intel.com>,
        Vivi Rodrigo <rodrigo.vivi@intel.com>,
        Zhenyu Wang <zhenyuw@linux.intel.com>,
        Zhi Wang <zhi.a.wang@intel.com>,
        Terrence Xu <terrence.xu@intel.com>
Subject: Re: [PATCH v6 1/3] i915/gvt: Introduce the mmio table to support
 VFIO new mdev API
In-Reply-To: <20220209072805.GA9050@lst.de>
Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo
References: <20220208111151.13115-1-zhi.a.wang@intel.com>
 <871r0dqtjf.fsf@intel.com> <20220209072805.GA9050@lst.de>
Date:   Wed, 09 Feb 2022 11:04:57 +0200
Message-ID: <87v8xopg06.fsf@intel.com>
MIME-Version: 1.0
Content-Type: text/plain
Precedence: bulk

On Wed, 09 Feb 2022, Christoph Hellwig <hch@lst.de> wrote:
> On Tue, Feb 08, 2022 at 05:15:00PM +0200, Jani Nikula wrote:
>> >  #ifdef CONFIG_DRM_I915_GVT
>> > +
>> > +#define D_BDW   (1 << 0)
>> > +#define D_SKL	(1 << 1)
>> > +#define D_KBL	(1 << 2)
>> > +#define D_BXT	(1 << 3)
>> > +#define D_CFL	(1 << 4)
>> > +
>> > +#define D_GEN9PLUS	(D_SKL | D_KBL | D_BXT | D_CFL)
>> > +#define D_GEN8PLUS	(D_BDW | D_SKL | D_KBL | D_BXT | D_CFL)
>> > +
>> > +#define D_SKL_PLUS	(D_SKL | D_KBL | D_BXT | D_CFL)
>> > +#define D_BDW_PLUS	(D_BDW | D_SKL | D_KBL | D_BXT | D_CFL)
>> > +
>> > +#define D_PRE_SKL	(D_BDW)
>> > +#define D_ALL		(D_BDW | D_SKL | D_KBL | D_BXT | D_CFL)
>> 
>> If these really need to be in a header in i915/, I think they need to be
>> longer with some namespacing or something. I do wish these could be
>> hidden though.
>
> I think we could actually kill them off entirely.  They are used as
> arguments to the macros that setup the mmio table.
>
> Thefunctions to build these tabls are already organized by families,
> so we'd need relatively few conditions to just build them the right
> way.  There also are some runtime checks in the callbacks, but they
> seem entirely superflous as far as I can tell.
>
> Only the cmd parser is a bit messy.  So maybe we could keep these
> constants just for the cmd parser inside of gvt for now (and clean
> that up later) and remove them entirely from the mmio table.

I'm fine with cleaning this up in follow-up, provided the follow-up
actually happens! ;)

BR,
Jani.


-- 
Jani Nikula, Intel Open Source Graphics Center