[Intel-gfx] [PATCH] drm/i915: Expose engine properties via sysfs

[Tvrtko Ursulin]

On 11/10/2019 13:31, Chris Wilson wrote:
> Quoting Tvrtko Ursulin (2019-10-11 13:16:33)

[snip]

>> Looks fine in principle.
>>
>> I am tempted to go with some of the engine->flags from the start but I
>> don't have an use case apart from saying that it sounds like it makes sense.
> 
> The problem I saw with engine->flags is that are mostly internal
> details; the public parts become caps.scheduler. That seemed reasonable
> to add, but where? cardN/scheduler (same level as cardN/engine)? But
> there's a large overlap between that and the per-engine controls. So
> cardN/engine/scheduler? Then the user has to remember that not all
> entries are engines.
> 
> I suppose cardN/engine/all/ would fit the pattern of some other sysfs
> interfaces [cardN/engine/all/scheduler/caps?] Only problem then is you
> would reasonably expect to have some global controls :)
> 
>> Preemption cap may make sense in conjunction with heartbeat interval to
>> tell userspace something more?
>>
>> Busy_stats might make sense for people interested in doing perf stat?
>>
>> What worries me slightly is not being able to tell if a cap is supported
>> just not exported, or not supported but exported, if you are able to
>> follow. :) Which would happen if we decided to later add something from
>> flags.
> 
> Along that path we end up with bcs0/available_flags and bcs0/flags (or
> bcs0/available_capabilities and bcs0/capabilities). Or
> cardN/engine/version?

available_capabilities sounds good enough and future proof.

Regards,

Tvrtko