Intel-GFX Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Jani Nikula <jani.nikula@linux.intel.com>
To: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH 2/3] drm/i915: Nuke PCH_MCC
Date: Fri, 01 Jul 2022 16:51:40 +0300	[thread overview]
Message-ID: <87letdlz4j.fsf@intel.com> (raw)
In-Reply-To: <Yr7msEAS9XwAtrVU@intel.com>

On Fri, 01 Jul 2022, Ville Syrjälä <ville.syrjala@linux.intel.com> wrote:
> On Fri, Jul 01, 2022 at 12:55:43PM +0300, Jani Nikula wrote:
>> On Thu, 30 Jun 2022, Ville Syrjala <ville.syrjala@linux.intel.com> wrote:
>> > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
>> >
>> > MCC is derived from TGP, and we have no real need to
>> > differentiate between the two. Thus remove PCH_MCC and
>> > just declare it to be PCH_TGP compatible.
>> >
>> > Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
>> > ---
>> >  drivers/gpu/drm/i915/display/intel_ddi.c  | 2 +-
>> >  drivers/gpu/drm/i915/display/intel_hdmi.c | 2 +-
>> >  drivers/gpu/drm/i915/intel_pch.c          | 3 ++-
>> >  drivers/gpu/drm/i915/intel_pch.h          | 4 +---
>> >  4 files changed, 5 insertions(+), 6 deletions(-)
>> >
>> > diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c b/drivers/gpu/drm/i915/display/intel_ddi.c
>> > index 272e1bf6006b..2330604b0bcc 100644
>> > --- a/drivers/gpu/drm/i915/display/intel_ddi.c
>> > +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
>> > @@ -4179,7 +4179,7 @@ static enum hpd_pin ehl_hpd_pin(struct drm_i915_private *dev_priv,
>> >  	if (port == PORT_D)
>> >  		return HPD_PORT_A;
>> >  
>> > -	if (HAS_PCH_MCC(dev_priv))
>> > +	if (HAS_PCH_TGP(dev_priv))
>> >  		return icl_hpd_pin(dev_priv, port);
>> >  
>> >  	return HPD_PORT_A + port - PORT_A;
>> > diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c b/drivers/gpu/drm/i915/display/intel_hdmi.c
>> > index 1ae09431f53a..ebd91aa69dd2 100644
>> > --- a/drivers/gpu/drm/i915/display/intel_hdmi.c
>> > +++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
>> > @@ -2852,7 +2852,7 @@ static u8 intel_hdmi_ddc_pin(struct intel_encoder *encoder)
>> >  		ddc_pin = rkl_port_to_ddc_pin(dev_priv, port);
>> >  	else if (DISPLAY_VER(dev_priv) == 9 && HAS_PCH_TGP(dev_priv))
>> >  		ddc_pin = gen9bc_tgp_port_to_ddc_pin(dev_priv, port);
>> > -	else if (HAS_PCH_MCC(dev_priv))
>> > +	else if (IS_JSL_EHL(dev_priv) && HAS_PCH_TGP(dev_priv))
>> >  		ddc_pin = mcc_port_to_ddc_pin(dev_priv, port);
>> 
>> Nitpick, mcc_ prefix is now an outlier here, and could be named after
>> the CPU/PCH combo like above for gen 9 and TGP. But no big deal.
>
> I want to rewrite these entirely. They should be doing 99% the same
> thing as the foo_hpd_pin() functions, yet they are written in all
> various kinds of different ways (none of which match the hpd_pin()
> stuff).
>
> Also while looking at that I stumbled on the VBT code doing a
> slightly different variant of the same stuff using arrays. And on
> top of that we have the VBT AUX CH mapping code as well, written
> in yet another style. So I think I want to try to unify it all
> to a common approach.

Ack. I've looked at all of this before, but haven't really come up with
anything neat, just grumbling about how it's split between VBT parsing
and this.

> I'm thinking the array approach might be the easiest to parse for
> mere mortals, so kinda leaning towards that. What do you think?

Sounds good, and it has a better separation of platforms, instead of a
bunch of magic conditions. OTOH I'm not overly enthusiastic about how
dvo_port_to_port() ended up looking, and why it needs to be platform
specific at all, oh well. I think you'll only know for real when you've
played with the code and have half the implementation written...

> Although one hurdle between me and arrays for the VBT AUX CH stuff
> is the VBT values which are shifted up into the upper nibble of
> the byte. So using those directly would result in giant arrays
> which are mostly empty. But I could redefine the VBT values as
> just the upper four bits and shift down when parsing the VBT.

If we can hide that in intel_bios.c or something, should be fine I
think.

BR,
Jani.

>
>> 
>> Reviewed-by: Jani Nikula <jani.nikula@intel.com>
>
> Thanks.
>
>> 
>> 
>> 
>> >  	else if (INTEL_PCH_TYPE(dev_priv) >= PCH_ICP)
>> >  		ddc_pin = icl_port_to_ddc_pin(dev_priv, port);
>> > diff --git a/drivers/gpu/drm/i915/intel_pch.c b/drivers/gpu/drm/i915/intel_pch.c
>> > index 94446cac6605..b45c504c6f03 100644
>> > --- a/drivers/gpu/drm/i915/intel_pch.c
>> > +++ b/drivers/gpu/drm/i915/intel_pch.c
>> > @@ -116,7 +116,8 @@ intel_pch_type(const struct drm_i915_private *dev_priv, unsigned short id)
>> >  	case INTEL_PCH_MCC_DEVICE_ID_TYPE:
>> >  		drm_dbg_kms(&dev_priv->drm, "Found Mule Creek Canyon PCH\n");
>> >  		drm_WARN_ON(&dev_priv->drm, !IS_JSL_EHL(dev_priv));
>> > -		return PCH_MCC;
>> > +		/* MCC is TGP compatible */
>> > +		return PCH_TGP;
>> >  	case INTEL_PCH_TGP_DEVICE_ID_TYPE:
>> >  	case INTEL_PCH_TGP2_DEVICE_ID_TYPE:
>> >  		drm_dbg_kms(&dev_priv->drm, "Found Tiger Lake LP PCH\n");
>> > diff --git a/drivers/gpu/drm/i915/intel_pch.h b/drivers/gpu/drm/i915/intel_pch.h
>> > index b7a8cf409d48..07f6f5517968 100644
>> > --- a/drivers/gpu/drm/i915/intel_pch.h
>> > +++ b/drivers/gpu/drm/i915/intel_pch.h
>> > @@ -24,8 +24,7 @@ enum intel_pch {
>> >  	PCH_CNP,        /* Cannon/Comet Lake PCH */
>> >  	PCH_ICP,	/* Ice Lake PCH */
>> >  	PCH_JSP,	/* Jasper Lake PCH */
>> > -	PCH_MCC,        /* Mule Creek Canyon PCH */
>> > -	PCH_TGP,	/* Tiger Lake PCH */
>> > +	PCH_TGP,	/* Tiger Lake/Mule Creek Canyon PCH */
>> >  	PCH_ADP,	/* Alder Lake PCH */
>> >  
>> >  	/* Fake PCHs, functionality handled on the same PCI dev */
>> > @@ -69,7 +68,6 @@ enum intel_pch {
>> >  #define HAS_PCH_ADP(dev_priv)			(INTEL_PCH_TYPE(dev_priv) == PCH_ADP)
>> >  #define HAS_PCH_DG1(dev_priv)			(INTEL_PCH_TYPE(dev_priv) == PCH_DG1)
>> >  #define HAS_PCH_JSP(dev_priv)			(INTEL_PCH_TYPE(dev_priv) == PCH_JSP)
>> > -#define HAS_PCH_MCC(dev_priv)			(INTEL_PCH_TYPE(dev_priv) == PCH_MCC)
>> >  #define HAS_PCH_TGP(dev_priv)			(INTEL_PCH_TYPE(dev_priv) == PCH_TGP)
>> >  #define HAS_PCH_ICP(dev_priv)			(INTEL_PCH_TYPE(dev_priv) == PCH_ICP)
>> >  #define HAS_PCH_CNP(dev_priv)			(INTEL_PCH_TYPE(dev_priv) == PCH_CNP)
>> 
>> -- 
>> Jani Nikula, Intel Open Source Graphics Center

-- 
Jani Nikula, Intel Open Source Graphics Center

  reply	other threads:[~2022-07-01 13:51 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-30 15:05 [Intel-gfx] [PATCH 0/3] drm/i915: PCH type cleanup Ville Syrjala
2022-06-30 15:05 ` [Intel-gfx] [PATCH 1/3] drm/i915: Use short PCH names consistently Ville Syrjala
2022-06-30 15:50   ` Murthy, Arun R
2022-06-30 17:00     ` Ville Syrjälä
2022-07-01  9:53       ` Jani Nikula
2022-06-30 15:05 ` [Intel-gfx] [PATCH 2/3] drm/i915: Nuke PCH_MCC Ville Syrjala
2022-07-01  9:55   ` Jani Nikula
2022-07-01 12:21     ` Ville Syrjälä
2022-07-01 13:51       ` Jani Nikula [this message]
2022-06-30 15:06 ` [Intel-gfx] [PATCH 3/3] drm/i915: Nuke PCH_JSP Ville Syrjala
2022-06-30 15:55   ` Murthy, Arun R
2022-06-30 16:59     ` Ville Syrjälä
2022-07-01  9:57   ` Jani Nikula
2022-06-30 17:58 ` [Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: PCH type cleanup Patchwork
2022-06-30 18:19 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2022-07-01  9:47 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork

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=87letdlz4j.fsf@intel.com \
    --to=jani.nikula@linux.intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=ville.syrjala@linux.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