Re: [RFC] drm/i915: Split out intel_vtd_active and run_as_guest to own header

[Jani Nikula <jani.nikula@intel.com>]

On Thu, 24 Mar 2022, Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> wrote:
> On 24/03/2022 11:57, Jani Nikula wrote:
>> On Thu, 24 Mar 2022, Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> wrote:
>>> On 24/03/2022 09:31, Jani Nikula wrote:
>>>> On Tue, 22 Mar 2022, Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> wrote:
>>>>> From: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
>>>>>
>>>>> ...
>>>>>
>>>>> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
>>>>> Cc: Jani Nikula <jani.nikula@intel.com>
>>>>> Cc: Lucas De Marchi <lucas.demarchi@intel.com>
>>>>> ---
>>>>> Typed up how I see it - bash away.
>>>>
>>>> So is intel_vtd_active() so performance critical that it needs to be
>>>> inline?
>>>>
>>>> We're passing struct drm_i915_private * everywhere we can, and it just
>>>> feels silly to use struct drm_device * to avoid the include.
>>>>
>>>> Static inlines considered harmful. :p
>>>
>>> Same as it is ;), and gee, who was it that he said he was just trying to
>>> declutter i915_drv.h.. ;p
>> 
>> Not at the cost of clarity elsewhere!
>
> To be clear now you oppose intel_vtd_active taking struct device? I 
> thought you expressed general agreement when I presented the idea in the 
> previous thread.
>
> I don't mind hugely to go either way, but I also don't see how taking 
> struct device makes anything unclear. (I only think 
> intel_vtd_run_as_guest is really wrong in this story but that's old news.)
>
> And if I make it take i915 then I would want to name it i915_vtd_active 
> as well. But then you wouldn't like that.
>
> Should we just stuff all this into i915_utils for now, as I think Lucas 
> suggested? Static inline or not, I don't care.

Just general grumpiness.

Acked-by: Jani Nikula <jani.nikula@intel.com>


>
> Regards,
>
> Tvrtko

-- 
Jani Nikula, Intel Open Source Graphics Center