Re: [PATCH] drm/i915/guc: symbolic names for user load/submission preferences

[Dave Gordon <david.s.gordon@intel.com>]

On 11/07/16 20:58, Chris Wilson wrote:
> On Mon, Jul 11, 2016 at 06:12:40PM +0100, Dave Gordon wrote:
>> The existing code that accesses the "enable_guc_loading" and
>> "enable_guc_submission" parameters uses explicit numerical
>> values for the various possibilities, including in some cases
>> relying on boolean 0/1 mapping to specific values (which could
>> be confusing for maintainers).
>>
>> So this patch just provides and uses names for the values
>> representing the DEFAULT, DISABLED, PREFERRED, and MANDATORY
>> options that the user can select (-1, 0, 1, 2 respectively).
>
> When is MANDATORY a good idea? If the hw doesn't support any other
> mechanism, then it will shut itself down gracefully if setup fails. If
> the user wants to force guc for testing, they only need to set the
> module parameter then check the guc is enabled afterwards and fail the
> test. At what point do we need such a warty user interface to the kernel?
> -Chris

Validation like it, so it's REALLY REALLY OBVIOUS if the system is 
misconfigured (e.g. wrong firmware version) as driver initialisation 
will fail rather than quietly continue by falling back to execlists.

Remember Daniel originally insisted on NO FALLBACK -- again, so that 
developers and testers didn't get confused by the system continuing to 
work despite the presence of a (hardware,firmware,driver) bug  -- so 
that's the option that provides it.

Of course it's not what end-users want, and so it's not what end-users 
get. You only get NO-FALLBACK mode if you specifically ask for it.

Note also, all this is already implemented, this patch just provides 
symbolic names for the code to use instead of literal numbers.

.Dave.
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx