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@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
