[Intel-gfx] [PATCH v4 03/13] drm/i915/guc: Add onion teardown to the GuC setup

[Oscar Mateo]

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