intel-xe.lists.freedesktop.org archive mirror
 help / color / mirror / Atom feed
From: Jani Nikula <jani.nikula@linux.intel.com>
To: "Kandpal, Suraj" <suraj.kandpal@intel.com>,
	"Atwood, Matthew S" <matthew.s.atwood@intel.com>
Cc: "intel-xe@lists.freedesktop.org" <intel-xe@lists.freedesktop.org>,
	"intel-gfx@lists.freedesktop.org"
	<intel-gfx@lists.freedesktop.org>,
	"Murthy, Arun R" <arun.r.murthy@intel.com>
Subject: RE: [PATCH 09/10] drm/i915/xe3lpd: Add check to see if edp over type c is allowed
Date: Thu, 10 Oct 2024 11:20:13 +0300	[thread overview]
Message-ID: <871q0o8j42.fsf@intel.com> (raw)
In-Reply-To: <SN7PR11MB6750C1D264E35F66C2105804E3782@SN7PR11MB6750.namprd11.prod.outlook.com>

On Thu, 10 Oct 2024, "Kandpal, Suraj" <suraj.kandpal@intel.com> wrote:
>> -----Original Message-----
>> From: Atwood, Matthew S <matthew.s.atwood@intel.com>
>> Sent: Thursday, October 10, 2024 4:36 AM
>> To: Kandpal, Suraj <suraj.kandpal@intel.com>
>> Cc: intel-xe@lists.freedesktop.org; intel-gfx@lists.freedesktop.org; Kandpal,
>> Suraj <suraj.kandpal@intel.com>
>> Subject: Re: [PATCH 09/10] drm/i915/xe3lpd: Add check to see if edp over
>> type c is allowed
>> 
>> On Wed, Oct 09, 2024 at 10:53:56AM +0300, Jani Nikula wrote:
>> > On Tue, 08 Oct 2024, Matt Atwood <matthew.s.atwood@intel.com> wrote:
>> > > From: Suraj Kandpal <suraj.kandpal@intel.com>
>> > >
>> > > Read PICA register to see if edp over type C is possible and then
>> > > add the appropriate tables for it.
>> >
>> > There's clearly more to be done for the feature than this.
>
> From what I could see in the spec we just need to read this the rest of the framework
> Already seemed to be in place and removing the checks where we didn't allow edp to go ahead when
> It was type c

Is it driven by VBT?

>
>> >
>> > >
>> > > Bspec: 68846
>> > > Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
>> > > Signed-off-by: Matt Atwood <matthew.s.atwood@intel.com>
>> > > ---
>> > >  drivers/gpu/drm/i915/display/intel_cx0_phy.c     |  2 ++
>> > >  .../gpu/drm/i915/display/intel_display_types.h   |  1 +
>> > >  drivers/gpu/drm/i915/display/intel_dp.c          | 16 ++++++++++++++++
>> > >  drivers/gpu/drm/i915/i915_reg.h                  |  3 +++
>> > >  4 files changed, 22 insertions(+)
>> > >
>> > > diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
>> > > b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
>> > > index 0d6f75ae35f5..1c8c2a2b05e1 100644
>> > > --- a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
>> > > +++ b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
>> > > @@ -2261,6 +2261,8 @@ intel_c20_pll_tables_get(struct intel_crtc_state
>> *crtc_state,
>> > >  		if (intel_crtc_has_type(crtc_state, INTEL_OUTPUT_EDP)) {
>> > >  			if (DISPLAY_VER_FULL(i915) == IP_VER(14, 1))
>> > >  				return xe2hpd_c20_edp_tables;
>> > > +			if (DISPLAY_VER(i915) >= 30 && encoder-
>> >typec_supp)
>> > > +				return xe3lpd_c20_dp_edp_tables;
>> > >  		}
>> > >
>> > >  		if (DISPLAY_VER_FULL(i915) == IP_VER(14, 1)) diff --git
>> > > a/drivers/gpu/drm/i915/display/intel_display_types.h
>> > > b/drivers/gpu/drm/i915/display/intel_display_types.h
>> > > index 2bb1fa64da2f..e9dc7707fbcd 100644
>> > > --- a/drivers/gpu/drm/i915/display/intel_display_types.h
>> > > +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
>> > > @@ -158,6 +158,7 @@ struct intel_encoder {
>> > >  	enum port port;
>> > >  	u16 cloneable;
>> > >  	u8 pipe_mask;
>> > > +	bool typec_supp;
>> >
>> > The register is global, why do we store this per encoder?
>
> Do you think having this in drm_i915_private makes sense wanted to put it there originally

Ugh no. We've stopped putting *anything* in drm_i915_private.

I couldn't find much detail about how the register behaves, but it looks
like a strap. I think I'd put the info in struct
intel_display_runtime_info and initialize in
__intel_display_device_info_runtime_init() based on the register,
similar to a ton of other things there.

>
>> >
>> > Side not, please let's not abbreviate stuff like _supp for the sake of
>> > abbreviating stuff.
>
> Sure will fix the naming
> Also quick question what would be the rule when abbreviating variables or
> When would we want to abbreviate the a variable if we want to

It's all about conventions, scope, and context. Certain things always
have the same name. Shorter names are fine in tight scope. Context can
allow you to shorten the name if parts of it are obvious from context.

>
>> >
>> > >
>> > >  	/* Check and recover a bad link state. */
>> > >  	struct delayed_work link_check_work; diff --git
>> > > a/drivers/gpu/drm/i915/display/intel_dp.c
>> > > b/drivers/gpu/drm/i915/display/intel_dp.c
>> > > index fbb096be02ad..917a503cc43b 100644
>> > > --- a/drivers/gpu/drm/i915/display/intel_dp.c
>> > > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
>> > > @@ -5570,6 +5570,20 @@ intel_dp_detect_sdp_caps(struct intel_dp
>> *intel_dp)
>> > >  		drm_dp_as_sdp_supported(&intel_dp->aux, intel_dp-
>> >dpcd);  }
>> > >
>> > > +static void
>> > > +intel_dp_check_edp_typec_supp(struct intel_encoder *encoder)
>> >
>> > It's not about checking anything, it's about reading, right?
>
> Yes will rename this to intel_dp_read_edp_typec_support

If we move the check to runtime info, the function shouldn't be needed.

>
>> >
>> > > +{
>> > > +	struct drm_i915_private *i915 = to_i915(encoder->base.dev);
>> > > +	bool is_tc_port = intel_encoder_is_tc(encoder);
>> > > +	u32 ret = 0;
>> > > +
>> > > +	if (encoder->type != INTEL_OUTPUT_EDP || !is_tc_port)
>> >
>> > Currently we warn at connector init for eDP type-C combo.
>
> That's true we will need to remove that check for DISPLAY_VER > 20
> Thanks will add that in this patch

That check should be amended with the runtime info check.

>
>> >
>> > > +		return;
>> > > +
>> > > +	ret = intel_de_read(i915, PICA_PHY_CONFIG_CONTROL);
>> > > +	encoder->typec_supp = ret & EDP_ON_TYPEC; }
>> > > +
>> > >  static int
>> > >  intel_dp_detect(struct drm_connector *connector,
>> > >  		struct drm_modeset_acquire_ctx *ctx, @@ -5595,6 +5609,8
>> @@
>> > > intel_dp_detect(struct drm_connector *connector,
>> > >  	if (!intel_display_driver_check_access(dev_priv))
>> > >  		return connector->status;
>> > >
>> > > +	intel_dp_check_edp_typec_supp(encoder);
>> > > +
>> >
>> > Isn't this something that should be determined at intel_ddi_init() time?
>
> Or intel_dp_connector_init can add it there what do you think ?

Yes, that's where we check the type-C/eDP combo currently.

BR,
Jani.

>
> Regards,
> Suraj Kandpal
>> >
>> > BR,
>> > Jani.
>> Please respond to Jani's comments
>> MattA
>> >
>> >
>> > >  	/* Can't disconnect eDP */
>> > >  	if (intel_dp_is_edp(intel_dp))
>> > >  		status = edp_detect(intel_dp);
>> > > diff --git a/drivers/gpu/drm/i915/i915_reg.h
>> > > b/drivers/gpu/drm/i915/i915_reg.h index da65500cd0c8..5f5a6ade5f8c
>> > > 100644
>> > > --- a/drivers/gpu/drm/i915/i915_reg.h
>> > > +++ b/drivers/gpu/drm/i915/i915_reg.h
>> > > @@ -4583,4 +4583,7 @@ enum skl_power_gate {
>> > >
>> > >  #define MTL_MEDIA_GSI_BASE		0x380000
>> > >
>> > > +#define PICA_PHY_CONFIG_CONTROL 	_MMIO(0x16FE68)
>> > > +#define   EDP_ON_TYPEC			REG_BIT(31)
>> > > +
>> > >  #endif /* _I915_REG_H_ */
>> >
>> > --
>> > Jani Nikula, Intel

-- 
Jani Nikula, Intel

  reply	other threads:[~2024-10-10  8:20 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-08 22:37 [PATCH 00/10] Add xe3lpd edp enabling Matt Atwood
2024-10-08 22:37 ` [PATCH 01/10] drm/i915/xe3lpd: reuse xe2lpd definition Matt Atwood
2024-10-08 23:17   ` Matt Roper
2024-10-08 22:37 ` [PATCH 02/10] drm/i915/xe3lpd: Adjust watermark calculations Matt Atwood
2024-10-09 10:53   ` Govindapillai, Vinod
2024-10-08 22:37 ` [PATCH 03/10] drm/i915/xe3lpd: Add new display power wells Matt Atwood
2024-10-09  8:51   ` Luca Coelho
2024-10-08 22:37 ` [PATCH 04/10] drm/i915/xe3lpd: Update pmdemand programming Matt Atwood
2024-10-09 13:09   ` Govindapillai, Vinod
2024-10-09 13:53     ` Gustavo Sousa
2024-10-08 22:37 ` [PATCH 05/10] drm/i915/xe3lpd: Add cdclk changes Matt Atwood
2024-10-08 23:30   ` Matt Roper
2024-10-08 22:37 ` [PATCH 06/10] drm/i915/xe3lpd: Add macro to choose HDCP_LINE_REKEY bit Matt Atwood
2024-10-08 23:37   ` Matt Roper
2024-10-10  4:14     ` Kandpal, Suraj
2024-10-09  7:39   ` Jani Nikula
2024-10-10  4:17     ` Kandpal, Suraj
2024-10-10  8:09       ` Jani Nikula
2024-10-08 22:37 ` [PATCH 07/10] drm/i915/xe3lpd: Add C20 Phy consolidated programming table Matt Atwood
2024-10-09 20:32   ` Taylor, Clinton A
2024-10-08 22:37 ` [PATCH 08/10] drm/i915/xe3lpd: Add new bit range of MAX swing setup Matt Atwood
2024-10-09  6:13   ` Chauhan, Shekhar
2024-10-09  7:41   ` Jani Nikula
2024-10-08 22:37 ` [PATCH 09/10] drm/i915/xe3lpd: Add check to see if edp over type c is allowed Matt Atwood
2024-10-09  7:53   ` Jani Nikula
2024-10-09 23:06     ` Matt Atwood
2024-10-10  4:46       ` Kandpal, Suraj
2024-10-10  8:20         ` Jani Nikula [this message]
2024-10-08 22:37 ` [PATCH 10/10] drm/i915/xe3lpd: Add powerdown value of eDP over type c Matt Atwood
2024-10-09  5:57   ` Chauhan, Shekhar
2024-10-09  7:57   ` Jani Nikula
2024-10-09 23:05     ` Matt Atwood
2024-10-10  3:37       ` Kandpal, Suraj
2024-10-08 22:43 ` ✓ CI.Patch_applied: success for Add xe3lpd edp enabling Patchwork
2024-10-08 22:43 ` ✗ CI.checkpatch: warning " Patchwork
2024-10-08 22:56 ` ✓ CI.Build: success " Patchwork
2024-10-08 22:58 ` ✓ CI.Hooks: " Patchwork
2024-10-08 23:00 ` ✗ CI.checksparse: warning " Patchwork
2024-10-08 23:25 ` ✓ CI.BAT: success " Patchwork
2024-10-09  7:16 ` ✗ CI.FULL: 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=871q0o8j42.fsf@intel.com \
    --to=jani.nikula@linux.intel.com \
    --cc=arun.r.murthy@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=matthew.s.atwood@intel.com \
    --cc=suraj.kandpal@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;
as well as URLs for NNTP newsgroup(s).