[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <99c2ad07-ddce-2473-fb30-388760a924e7@intel.com>
Date: Wed, 9 Feb 2022 19:57:55 +0000
From: "Wang, Zhi A" <zhi.a.wang@...el.com>
To: Jani Nikula <jani.nikula@...ux.intel.com>,
Christoph Hellwig <hch@....de>
CC: Zhi Wang <zhi.wang.linux@...il.com>,
"jgg@...dia.com" <jgg@...dia.com>,
"intel-gfx@...ts.freedesktop.org" <intel-gfx@...ts.freedesktop.org>,
"intel-gvt-dev@...ts.freedesktop.org"
<intel-gvt-dev@...ts.freedesktop.org>,
"dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"Joonas Lahtinen" <joonas.lahtinen@...ux.intel.com>,
"Vivi, Rodrigo" <rodrigo.vivi@...el.com>,
Zhenyu Wang <zhenyuw@...ux.intel.com>,
"Xu, Terrence" <terrence.xu@...el.com>
Subject: Re: [PATCH v6 1/3] i915/gvt: Introduce the mmio table to support VFIO
new mdev API
On 2/9/22 9:04 AM, Jani Nikula wrote:
> On Wed, 09 Feb 2022, Christoph Hellwig <hch@....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! ;)
Thanks so much for the comments and the support. :)
>
> BR,
> Jani.
>
>
Powered by blists - more mailing lists