On 03/24/2017 01:59 AM, Chris Wilson wrote:
On Thu, Mar 23, 2017 at 09:36:10AM -0700, Oscar Mateo wrote:
On 03/23/2017 03:57 PM, Chris Wilson wrote:
I'm not happy with moving subfeature detection logic into the core GEM
code. if (i915.enable_guc_loading) firstly should never be a module
parameter (it's derived state!) and secondly it should reside next to
the dependent logic and not be interrupting the central control flow.
What do you mean it's derived state? from what?
The set of features, whether to use guc submission, huc, or whether
there is a platform requirement to load the firmware, define whether or
not we need to request and upload a particular firmware. Every module
option should be a quirk to alter driver behaviour (i.e. a debugging
crutch), few and strongly justified (we have too many) and necessarily
global in scope. Device specific options should ideally use a more
specific interface (most clear examples are the panel specific quirks).
-Chris
Ok, I see what you mean now. I didn't follow the GuC development, so I
don't know how we got here (separate enable_guc_loading and
enable_guc_submission module parameters, a lot of different
HAS_GUC_UCODE/HAS_GUC_SCHED/HAS_HUC_UCODE that test the same thing, etc...).
I'll create a patch with a cleanup proposal and send it as an RFC.
-- Oscar
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
