Re: [PATCH 03/10] drm/i915: Expose engine properties via sysfs

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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




[Index of Archives]     [AMD Graphics]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux