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:
/sys/class/drm/card0
└── 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
strings.
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?
Regards,
Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
