On 2/9/22 9:04 AM, Jani Nikula wrote: > On Wed, 09 Feb 2022, Christoph Hellwig <h...@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! ;)
Thanks so much for the comments and the support. :) > > BR, > Jani. > >
