[Intel-gfx] [PATCH 16/27] drm/i915/icl: Check for fused-off VDBOX and VEBOX instances
Oscar Mateo
oscar.mateo at intel.com
Wed Jan 10 23:02:08 UTC 2018
On 01/10/2018 11:33 AM, Chris Wilson wrote:
> Quoting Chris Wilson (2018-01-10 19:32:09)
>> Quoting Oscar Mateo (2018-01-10 19:25:39)
>>>
>>> On 01/10/2018 01:36 AM, Chris Wilson wrote:
>>>>> +/*
>>>>> + * Determine which engines are fused off in our particular hardware.
>>>>> + *
>>>>> + * This function needs to be called after the MMIO has been setup (as we need
>>>>> + * to read registers) but before uncore init (because the powerwell for the
>>>>> + * fused off engines doesn't exist, so we cannot initialize forcewake for them)
>>>>> + */
>>>>> +void intel_device_info_fused_off_engines(struct drm_i915_private *dev_priv)
>>>>> +{
>>>>> + struct intel_device_info *info = mkwrite_device_info(dev_priv);
>>>>> + u32 media_fuse;
>>>>> + int i;
>>>>> +
>>>>> + if (INTEL_GEN(dev_priv) < 11)
>>>>> + return;
>>>>> +
>>>>> + GEM_BUG_ON(!dev_priv->regs);
>>>>> +
>>>>> + media_fuse = I915_READ_FW(GEN11_GT_VEBOX_VDBOX_DISABLE);
>>>>> +
>>>>> + info->vdbox_disable = media_fuse & GEN11_GT_VDBOX_DISABLE_MASK;
>>>>> + info->vebox_disable = (media_fuse & GEN11_GT_VEBOX_DISABLE_MASK) >>
>>>>> + GEN11_GT_VEBOX_DISABLE_SHIFT;
>>>> We don't need to keep these (just locals will do), the permanent
>>>> information is in info->ring_mask.
>>> There are subsequent patches that pass this info to GuC, that's why I
>>> was keeping them. I could retrieve the information back from
>>> info->ring_mask, but it's a pity since we already have it in the right
>>> format here.
>> If there's a use, sure. You can always add it later along with the user
>> if the patches are separated into a different series. Just nothing in
>> this patch justified keeping them.
> The counter argument is that if there is only a single use case, reading
> the registers again isn't an issue, especially if, as you say, the
> register contents are exactly what the guc wants to be told.
> -Chris
That's fair enough. I'll resend.
More information about the Intel-gfx
mailing list