[Intel-gfx] [PATCH 3/4] drm/i915: expose engine availability through sysfs

[Tvrtko Ursulin]

On 28/11/2017 21:39, Chris Wilson wrote:
> Quoting Chris Wilson (2017-11-28 20:56:23)
>> Quoting Tvrtko Ursulin (2017-11-28 18:17:54)
>>>
>>> On 20/11/2017 12:23, Lionel Landwerlin wrote:
>>>> This enables userspace to discover the engines available on the GPU.
>>>> Here is the layout on a Skylake GT4:
>>>>
>>>> /sys/devices/pci0000:00/0000:00:02.0/drm/card0/gt
>>>
>>> On this one I think Joonas had a concern that it is difficult for
>>> userspace to get to the sysfs root from the drm file descriptor.
>>>
>>> Lionel pointed out that for master nodes it is quite easy:
>>>
>>> fstat(fd, &st);
>>> sprintf(sysfs_root, "/sys/dev/char/%u:%u", major(st.st_rdev), minor(st.st_rdev));
>>>
>>> For render nodes it is trickier in a way that they would have to
>>> additional resolve an unknown master drm card number. For instance:
>>>
>>> /sys/dev/char/%u:%u/device/drm/cardX
>>>
>>> Where the "X" is unknown.
>>>
>>> But, is it even an use case for render nodes to try and get to the
>>> sysfs root of the master card? Are they allowed to do so?
>>
>> Yes. Mesa uses render nodes, and mesa needs the topology for its
>> performance monitoring api.
> 
> So /sys/dev/char/226:128/ does not link to /sys/dev/char/226:0/. Maybe
> we should just add a card symlink from each minor back to our sysfs
> root? That seems doable.
> 
> Then we just need open("/sys/dev/char/%u:%u/card");

There is a link via what I wrote above - 
"/sys/dev/char/%u:%u/device/drm/cardX", but the "X" part is cumbersome.

Adding a link with a constant name would indeed be better, but I wasn't 
sure if it is conceptually allowed and even forgot to mention it.

Regards,

Tvrtko