Commen=
t # 4
on bug 10930=
3
from Martin Peres
(In reply to Chris Wilson from comment #3)
> (In reply to Lionel Landwerlin from comment #2)
> > (In reply to Martin Peres from comment #0)
> > > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5388/shar=
d-iclb2/
> > > igt@i915_query@query-topology-known-pci-ids.html
> > >=20
> > > Test requirement: IS_HASWELL(devid) || IS_BROADWELL(devid) ||
> > > IS_SKYLAKE(devid) || IS_KABYLAKE(devid) || IS_COFFEELAKE(dev=
id)
> > > Subtest query-topology-known-pci-ids: SKIP (0.000s)
> > >=20
> > > I doubt that this would only be supported on these platforms=
and not on CNL
> > > and ICL.
> >=20
> > It does only support haswell/gen8/gen9 because that's the only pl=
ace where
> > based off the GT we can deduct the number of slices/subslices and=
do some
> > actual checks on the values returned by i915.
> > On gen10+ fusing is a lot more fuzzy.
> >=20
> > One way to extend coverage would be to beef up lib/intel_device_i=
nfo.c to
> > contain information about the topology of the device.
>=20
> Not really, I think. The purpose of the topology i915_query is precise=
ly to
> retrieve the more flexible configurations that are not simply defined =
in
> static pci-id tables.
>=20
> So long as we have sanity checks on the ioctl to catch garbage returns;
> along with the static checks to make sure known configs are reported, =
that
> seems like we have our boundary conditions covered.
>=20
> If were possible to use the topology and verify that matches hw, that =
would
> be a useful test (I presume that would also closely match use).
(In reply to Lionel Landwerlin from comment #2)
> (In reply to Martin Peres from comment #0)
> > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5388/shard-icl=
b2/
> > igt@i915_query@query-topology-known-pci-ids.html
> >=20
> > Test requirement: IS_HASWELL(devid) || IS_BROADWELL(devid) ||
> > IS_SKYLAKE(devid) || IS_KABYLAKE(devid) || IS_COFFEELAKE(devid)
> > Subtest query-topology-known-pci-ids: SKIP (0.000s)
> >=20
> > I doubt that this would only be supported on these platforms and =
not on CNL
> > and ICL.
>=20
> It does only support haswell/gen8/gen9 because that's the only place w=
here
> based off the GT we can deduct the number of slices/subslices and do s=
ome
> actual checks on the values returned by i915.
> On gen10+ fusing is a lot more fuzzy.
>=20
> One way to extend coverage would be to beef up lib/intel_device_info.c=
to
> contain information about the topology of the device.
>=20
> Thoughts welcome.
Thanks for the info! Maybe you could create a Jira to implement something l=
ike
Chris is describing so we don't forget about this gap in coverage?