[Intel-gfx] [PATCH] drm/i915/guc: symbolic names for user load/submission preferences
Dave Gordon
david.s.gordon at intel.com
Tue Jul 12 11:49:36 UTC 2016
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.
More information about the Intel-gfx
mailing list