[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