[PATCH libdrm 1/4] intel: add IS_GENX() generic macro

[Chris Wilson]

Quoting Lucas De Marchi (2018-08-25 00:56:46)
> diff --git a/intel/intel_chipset.h b/intel/intel_chipset.h
> index 4a34b7be..8a0e3e76 100644
> --- a/intel/intel_chipset.h
> +++ b/intel/intel_chipset.h
> @@ -568,6 +568,26 @@
>  
>  #define IS_GEN11(devid)                (IS_ICELAKE_11(devid))
>  
> +/* New platforms use kernel pci ids */
> +#include "i915_pciids.h"
> +
> +struct pci_device_id {

Don't call it pci_device_id, depending on caller that name may already
be taken by libpciaccess.

> +       uint32_t unused0, device;
> +       uint32_t unused1, unused2;
> +       uint32_t unused3, unused4;
These are all uint16_t.

> +       unsigned long unused5;

Simply make the unused disappear from the macro.

> +};
> +
> +#define IS_GENX(x, devid) ({ \
> +       struct pci_device_id __ids[] = { INTEL_ ## x ## _IDS(0) };      \

While that's a neat trick it's instantiating the array for each caller,
and it does appear that we repeat a few of the macros.

The best I can offer to keep the change non-invasive (other than just
switching to a platform bitmask and filling (devid, gen, platform) from
the pci match data on initialisation) is a two pass approach.

static inline int __find_in_pciid(uint16_t devid,
	const struct pci_device_id *ids, size_t count)
{
	size_t i = 0; /* we should rethink this if we think there are more than 4B of them! */
	for (i = 0; i < count; i++) {
		if (ids[i].device == devid)
			return 1;
	}
	return 0;
}


#define __is_genx(x) \
static inline int __is_gen##x(uint16_t devid) \
{ \
	static const struct pci_device_id __ids[] = { INTEL_ ## x ## _IDS(0) }; \
	return __find_in_pciid(devid, __ids, sizeof(__ids)/sizeof(__ids[0]); \
}
__is_genx(3);
__is_genx(4);
__is_genx(5);
__is_genx(6);
__is_genx(7);
__is_genx(8);
__is_genx(9);
__is_genx(10);
__is_genx(11);

#define IS_GENX(x, devid) __is_gen##x(devid)

That should help cut down the object size expansion. But longer term I'd
prefer if we moved to towards finding the match data once. Also we need
to pull into the canonical header the friendly names for mesa.
-Chris