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
next prev parent 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).