On 11/10/2019 09:49, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-10-11 09:44:16)

On 10/10/2019 08:14, Chris Wilson wrote:
Preliminary stub to add engines underneath /sys/class/drm/cardN/, so
that we can expose properties on each engine to the sysadmin.

To start with we have basic analogues of the i915_query ioctl so that we
can pretty print engine discovery from the shell, and flesh out the
directory structure. Later we will add writeable sysadmin properties such
as per-engine timeout controls.

An example tree of the engine properties on Braswell:
      └── engine
          ├── bcs0
          │   ├── class
          │   ├── heartbeat_interval_ms

Not present in this patch.

I did say an example tree, not this tree :)

          │   ├── instance
          │   ├── mmio_base

I vote for putting mmio_base in a followup patch.

Darn your eagle eyes ;)

And how about we add capabilities in the first patch? So we get another
way of engine discovery. Ideally with mapping of bits to user friendly

Right, I was about to ask if we should do a /proc/cpuinfo style
capabilities. Do we need both? Or just stick to the more human readable
output for sysfs?

Interesting question and I am not sure. I'd definitely have human readable and that even being an aggregation of engine->flags and engine->uabi_capabilities. Whether or not to also put hex in there.. For uabi_capabilities it's possible, but for the rest not so much. So that probably means only human readable?


Intel-gfx mailing list

Reply via email to