[PATCH v2] lib: sync PCI ID macros with kernel

[Lucas De Marchi]

On Mon, Nov 11, 2024 at 11:07:39AM +0200, Jani Nikula wrote:
>On Fri, 08 Nov 2024, Lucas De Marchi <lucas.demarchi at intel.com> wrote:
>> On Fri, Nov 08, 2024 at 12:20:44PM +0200, Jani Nikula wrote:
>>>On Thu, 07 Nov 2024, Ngai-Mint Kwan <ngai-mint.kwan at linux.intel.com> wrote:
>>>> diff --git a/lib/i915/perf.c b/lib/i915/perf.c
>>>> index ef2f74be8..9eb1141d4 100644
>>>> --- a/lib/i915/perf.c
>>>> +++ b/lib/i915/perf.c
>>>> @@ -37,7 +37,7 @@
>>>>
>>>>  #include <i915_drm.h>
>>>>
>>>> -#include "i915_pciids.h"
>>>> +#include "pciids.h"
>>>>  #include "i915_pciids_local.h"
>>>
>>>After this gets merged, maybe you could write a follow-up patch that
>>>renames i915_pciids_local.h to pciids_local.h and cleans it up; there's
>>
>> Actually to remove it. Why are we still carrying that?
>
>To cater for igt perf code, which uses smaller granularity than the
>kernel. It's a good question whether we should split the macros up
>further in kernel for the needs of perf.

ugh... I rather think we need to have a query or some identifier to
allow userspace to have these decisions rather than splitting the PCI
IDs.

And for whatever reason that perf (aka OA) thing still have cannonlake
there :-/

Lucas De Marchi

>
>> Or maybe keep it just for the IDs from the topic branch (which we won't
>> add more to, hopefully) so we can keep sync'ing with drm-xe, or
>> drm-intel or drm-next, depending on the context.
>
>There no more PCI IDs in the topic branches, even PVC IDs are now in
>-next, but we just enable those PCI IDs in the topic branch.
>
>BR,
>Jani.
>
>
>-- 
>Jani Nikula, Intel