[Intel-gfx] [PATCH] drm/i915: Use graphics ver, rel info for media on old platforms

Jani Nikula jani.nikula at linux.intel.com
Tue Oct 11 10:10:26 UTC 2022


On Tue, 11 Oct 2022, "Sripada, Radhakrishna" <radhakrishna.sripada at intel.com> wrote:
> Hi Jani,
>
>> -----Original Message-----
>> From: Jani Nikula <jani.nikula at linux.intel.com>
>> Sent: Tuesday, October 11, 2022 12:28 AM
>> To: Sripada, Radhakrishna <radhakrishna.sripada at intel.com>; intel-
>> gfx at lists.freedesktop.org
>> Cc: dri-devel at lists.freedesktop.org; Sripada, Radhakrishna
>> <radhakrishna.sripada at intel.com>; De Marchi, Lucas
>> <lucas.demarchi at intel.com>; Roper, Matthew D
>> <matthew.d.roper at intel.com>
>> Subject: Re: [PATCH] drm/i915: Use graphics ver, rel info for media on old
>> platforms
>> 
>> On Mon, 10 Oct 2022, Radhakrishna Sripada <radhakrishna.sripada at intel.com>
>> wrote:
>> > Platforms prior to MTL do not have a separate media and graphics version.
>> > On platforms where GMD id is not supported, reuse the graphics ip version,
>> > release info for media.
>> >
>> > The rest of the IP graphics, display versions would be copied during driver
>> > creation.
>> >
>> > While at it warn if GMD is not used for platforms greater than gen12.
>> >
>> > Fixes: c2c7075225ef ("drm/i915: Read graphics/media/display arch version
>> from hw")
>> > Cc: Jani Nikula <jani.nikula at linux.intel.com>
>> > Cc: Lucas De Marchi <lucas.demarchi at intel.com>
>> > Cc: Matt Roper <matthew.d.roper at intel.com>
>> > Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada at intel.com>
>> > ---
>> >  drivers/gpu/drm/i915/intel_device_info.c | 12 +++++++++++-
>> >  1 file changed, 11 insertions(+), 1 deletion(-)
>> >
>> > diff --git a/drivers/gpu/drm/i915/intel_device_info.c
>> b/drivers/gpu/drm/i915/intel_device_info.c
>> > index 090097bb3c0a..ba178b61bceb 100644
>> > --- a/drivers/gpu/drm/i915/intel_device_info.c
>> > +++ b/drivers/gpu/drm/i915/intel_device_info.c
>> > @@ -329,8 +329,18 @@ static void intel_ipver_early_init(struct
>> drm_i915_private *i915)
>> >  {
>> >  	struct intel_runtime_info *runtime = RUNTIME_INFO(i915);
>> >
>> > -	if (!HAS_GMD_ID(i915))
>> > +	if (!HAS_GMD_ID(i915)) {
>> > +		drm_WARN_ON(&i915->drm, RUNTIME_INFO(i915)-
>> >graphics.ip.ver > 12);
>> > +		/*
>> > +		 * On older platforms, graphics and media share the same ip
>> > +		 * version and release.
>> > +		 */
>> > +		RUNTIME_INFO(i915)->media.ip.ver =
>> > +			RUNTIME_INFO(i915)->graphics.ip.ver;
>> > +		RUNTIME_INFO(i915)->media.ip.rel =
>> > +			RUNTIME_INFO(i915)->graphics.ip.rel;
>> 
>> You could assign the whole struct ip_version (*) at once, or is there a
>> reason you're intentionally not assigning step?
> Step info would anyways be determined later in the function intel_step_init.
> We already have macros in place to handle common gt and media steps there.
>
> Do you suggest we memcpy(&RUNTIME_INFO(i915)->media.ip, &RUNTIME_INFO->graphics.ip, sizeof(struct ip_version)) here?

Simple assign should do it for such a small struct.

BR,
Jani.

>
>> 
>> BR,
>> Jani.
>> 
>> (*) Why does that name not have intel_ prefix?
> Good question. Since introduced in " a5b7ef27da60 drm/i915: Add struct to hold IP version"
> we have been using as is. The author might have felt that the structure is not big enough/used in as many places
> to have an intel_ prefix. Do you see a symbol collision here that we
> need to add intel_ prefix?

It's not just about avoiding any immediate symbol collisions, it's also
about setting an example. People see this and think it's fine not to
have the prefix. And then the practice proliferates until there's a
collision.

> If so should we do it in a separate patch?

If there's a semantically separate change, it should always be a
separate patch.

BR,
Jani.

>
> Thanks,
> Radhakrishna(RK) Sripada
>> 
>> >  		return;
>> > +	}
>> >
>> >  	ip_ver_read(i915, i915_mmio_reg_offset(GMD_ID_GRAPHICS),
>> >  		    &runtime->graphics.ip);
>> 
>> --
>> Jani Nikula, Intel Open Source Graphics Center

-- 
Jani Nikula, Intel Open Source Graphics Center


More information about the Intel-gfx mailing list