Intel-GFX Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Jani Nikula <jani.nikula@linux.intel.com>
To: "Sripada, Radhakrishna" <radhakrishna.sripada@intel.com>,
	"intel-gfx@lists.freedesktop.org"
	<intel-gfx@lists.freedesktop.org>
Cc: "De Marchi, Lucas" <lucas.demarchi@intel.com>,
	"dri-devel@lists.freedesktop.org"
	<dri-devel@lists.freedesktop.org>
Subject: Re: [Intel-gfx] [PATCH] drm/i915: Use graphics ver, rel info for media on old platforms
Date: Tue, 11 Oct 2022 13:10:26 +0300	[thread overview]
Message-ID: <87k056y8kt.fsf@intel.com> (raw)
In-Reply-To: <DM4PR11MB59714D6C8D496B5538DA27AB87239@DM4PR11MB5971.namprd11.prod.outlook.com>

On Tue, 11 Oct 2022, "Sripada, Radhakrishna" <radhakrishna.sripada@intel.com> wrote:
> Hi Jani,
>
>> -----Original Message-----
>> From: Jani Nikula <jani.nikula@linux.intel.com>
>> Sent: Tuesday, October 11, 2022 12:28 AM
>> To: Sripada, Radhakrishna <radhakrishna.sripada@intel.com>; intel-
>> gfx@lists.freedesktop.org
>> Cc: dri-devel@lists.freedesktop.org; Sripada, Radhakrishna
>> <radhakrishna.sripada@intel.com>; De Marchi, Lucas
>> <lucas.demarchi@intel.com>; Roper, Matthew D
>> <matthew.d.roper@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@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@linux.intel.com>
>> > Cc: Lucas De Marchi <lucas.demarchi@intel.com>
>> > Cc: Matt Roper <matthew.d.roper@intel.com>
>> > Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@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

  reply	other threads:[~2022-10-11 10:10 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-10 23:17 [Intel-gfx] [PATCH] drm/i915: Use graphics ver, rel info for media on old platforms Radhakrishna Sripada
2022-10-11  0:10 ` [Intel-gfx] ✓ Fi.CI.BAT: success for " Patchwork
2022-10-11  6:26 ` [Intel-gfx] ✓ Fi.CI.IGT: " Patchwork
2022-10-11  7:27 ` [Intel-gfx] [PATCH] " Jani Nikula
2022-10-11  8:30   ` Sripada, Radhakrishna
2022-10-11 10:10     ` Jani Nikula [this message]
2022-10-11 10:32       ` Ville Syrjälä
2022-10-11 18:57         ` Sripada, Radhakrishna

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87k056y8kt.fsf@intel.com \
    --to=jani.nikula@linux.intel.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=lucas.demarchi@intel.com \
    --cc=radhakrishna.sripada@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox