Bug 109303 - [CI][SHARDS] igt@i915_query@query-topology-known-pci-ids - skip - Test requirement: IS_HASWELL(devid) || IS_BROADWELL(devid) || IS_SKYLAKE(devid) || IS_KABYLAKE(devid) || IS_COFFEELAKE(devid), SKIP
Summary: [CI][SHARDS] igt@i915_query@query-topology-known-pci-ids - skip - Test requir...
Status: CLOSED NOTABUG
Alias: None
Product: DRI
Classification: Unclassified
Component: IGT (show other bugs)
Version: XOrg git
Hardware: Other All
: medium normal
Assignee: Default DRI bug account
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-01-11 09:36 UTC by Martin Peres
Modified: 2019-01-18 15:36 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Martin Peres 2019-01-11 09:36:51 UTC
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5388/shard-iclb2/igt@i915_query@query-topology-known-pci-ids.html

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)

I doubt that this would only be supported on these platforms and not on CNL and ICL.
Comment 1 CI Bug Log 2019-01-11 09:39:25 UTC
The CI Bug Log issue associated to this bug has been updated.

### New filters associated

* ICL: igt@i915_query@query-topology-known-pci-ids - skip - Test requirement: IS_HASWELL(devid) || IS_BROADWELL(devid) || IS_SKYLAKE(devid) ||
  - https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5388/shard-iclb2/igt@i915_query@query-topology-known-pci-ids.html
Comment 2 Lionel Landwerlin 2019-01-11 10:43:44 UTC
(In reply to Martin Peres from comment #0)
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5388/shard-iclb2/
> igt@i915_query@query-topology-known-pci-ids.html
> 
> 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)
> 
> I doubt that this would only be supported on these platforms and not on CNL
> and ICL.

It does only support haswell/gen8/gen9 because that's the only place 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.

One way to extend coverage would be to beef up lib/intel_device_info.c to contain information about the topology of the device.

Thoughts welcome.
Comment 3 Chris Wilson 2019-01-11 18:49:07 UTC
(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-iclb2/
> > igt@i915_query@query-topology-known-pci-ids.html
> > 
> > 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)
> > 
> > I doubt that this would only be supported on these platforms and not on CNL
> > and ICL.
> 
> It does only support haswell/gen8/gen9 because that's the only place 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.
> 
> One way to extend coverage would be to beef up lib/intel_device_info.c to
> contain information about the topology of the device.

Not really, I think. The purpose of the topology i915_query is precisely to retrieve the more flexible configurations that are not simply defined in static pci-id tables.

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.

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).
Comment 4 Martin Peres 2019-01-18 15:36:49 UTC
(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/shard-iclb2/
> > > igt@i915_query@query-topology-known-pci-ids.html
> > > 
> > > 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)
> > > 
> > > I doubt that this would only be supported on these platforms and not on CNL
> > > and ICL.
> > 
> > It does only support haswell/gen8/gen9 because that's the only place 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.
> > 
> > One way to extend coverage would be to beef up lib/intel_device_info.c to
> > contain information about the topology of the device.
> 
> Not really, I think. The purpose of the topology i915_query is precisely to
> retrieve the more flexible configurations that are not simply defined in
> static pci-id tables.
> 
> 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.
> 
> 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-iclb2/
> > igt@i915_query@query-topology-known-pci-ids.html
> > 
> > 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)
> > 
> > I doubt that this would only be supported on these platforms and not on CNL
> > and ICL.
> 
> It does only support haswell/gen8/gen9 because that's the only place 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.
> 
> One way to extend coverage would be to beef up lib/intel_device_info.c to
> contain information about the topology of the device.
> 
> Thoughts welcome.

Thanks for the info! Maybe you could create a Jira to implement something like Chris is describing so we don't forget about this gap in coverage?


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.