[Intel-gfx] [PATCH 03/10] drm/i915: Expose engine properties via sysfs
Tvrtko Ursulin
tvrtko.ursulin at linux.intel.com
Fri Oct 11 09:04:22 UTC 2019
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
More information about the Intel-gfx
mailing list