Intel-GFX Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: "Hogander, Jouni" <jouni.hogander@intel.com>
To: "intel-gfx@lists.freedesktop.org"
	<intel-gfx@lists.freedesktop.org>,
	"jani.nikula@linux.intel.com" <jani.nikula@linux.intel.com>,
	"Souza, Jose" <jose.souza@intel.com>
Subject: Re: [Intel-gfx] [PATCH 1/2] drm/i915/opregion: add function to check if headless sku
Date: Wed, 8 Jun 2022 09:41:40 +0000	[thread overview]
Message-ID: <02ce1ff0d1968e54dfc43ef62fb6e2c0857ba21d.camel@intel.com> (raw)
In-Reply-To: <8a83b4595e603df3ed8975a31425639b714b57bd.camel@intel.com>

On Mon, 2022-06-06 at 13:15 +0000, Souza, Jose wrote:
> On Mon, 2022-06-06 at 11:16 +0300, Jani Nikula wrote:
> > On Mon, 06 Jun 2022, "Hogander, Jouni" <jouni.hogander@intel.com>
> > wrote:
> > > On Fri, 2022-06-03 at 16:32 +0000, Souza, Jose wrote:
> > > > On Fri, 2022-06-03 at 13:14 +0000, Hogander, Jouni wrote:
> > > > > On Fri, 2022-06-03 at 15:43 +0300, Jani Nikula wrote:
> > > > > > On Fri, 03 Jun 2022, Jouni Högander <
> > > > > > jouni.hogander@intel.com>
> > > > > > wrote:
> > > > > > > Export headless sku bit (bit 13) from opregion->header-
> > > > > > > >pcon as
> > > > > > > an
> > > > > > > interface to check if our device is headless
> > > > > > > configuration.
> > > > > > > 
> > > > > > > Bspec: 53441
> > > > > > > Signed-off-by: Jouni Högander <jouni.hogander@intel.com>
> > > > > > > ---
> > > > > > >  drivers/gpu/drm/i915/display/intel_opregion.c | 12
> > > > > > > ++++++++++++
> > > > > > >  drivers/gpu/drm/i915/display/intel_opregion.h |  7
> > > > > > > +++++++
> > > > > > >  2 files changed, 19 insertions(+)
> > > > > > > 
> > > > > > > diff --git
> > > > > > > a/drivers/gpu/drm/i915/display/intel_opregion.c
> > > > > > > b/drivers/gpu/drm/i915/display/intel_opregion.c
> > > > > > > index f31e8c3f8ce0..eab3f2e6b786 100644
> > > > > > > --- a/drivers/gpu/drm/i915/display/intel_opregion.c
> > > > > > > +++ b/drivers/gpu/drm/i915/display/intel_opregion.c
> > > > > > > @@ -53,6 +53,8 @@
> > > > > > >  #define MBOX_ASLE_EXTBIT(4)/* Mailbox #5 */
> > > > > > >  #define MBOX_BACKLIGHTBIT(5)/* Mailbox #2
> > > > > > > (valid from v3.x) */
> > > > > > > 
> > > > > > > +#define PCON_HEADLESS_SKUBIT(13)
> > > > > > 
> > > > > > Here we go again.
> > > > > > 
> > > > > > What does headless mean here? The spec does not say. Does
> > > > > > it have
> > > > > > display hardware? Apparently yes, since otherwise we
> > > > > > wouldn't be
> > > > > > here.
> > > > > 
> > > > > This is for hybrid setup with several display hw and the
> > > > > panel wont
> > > > > be
> > > > > connected into device driven by i915 driver.
> > > > > 
> > > > > > We have INTEL_DISPLAY_ENABLED() which should do the right
> > > > > > thing
> > > > > > when
> > > > > > you
> > > > > > do have display hardware and have done output setup etc.
> > > > > > but want
> > > > > > to
> > > > > > force them disconnected, i.e. you take the hardware over
> > > > > > properly,
> > > > > > but
> > > > > > put it to sleep for power savings.
> > > > > > 
> > > > > > Maybe we should bolt this opregion check in that macro?
> > > > > > 
> > > > > > Maybe we need to use INTEL_DISPLAY_ENABLED() also to
> > > > > > prevent
> > > > > > polling.
> > > > > 
> > > > > Thank you for pointing this out. HAS_DISPLAY I already notice
> > > > > and
> > > > > it's
> > > > > not suitable for what we want here. I think bolting this
> > > > > check into
> > > > > INTEL_DISPLAY_ENABLED as you suggested is enough. That will
> > > > > prevent
> > > > > waking up the hw into D0 state for polling.
> > > > 
> > > > A headless sku should not have any DDI ports enabled, much
> > > > easier
> > > > check for that.
> > > 
> > > Could you please clarify this a bit? What exactly you are
> > > thinking
> > > should be checked? Aren't DDI port also disabled when non-
> > > headless
> > > setup is in runtime suspend?
> > 
> > I also think "headless" and "DDI ports enabled" need clarification.
> > They
> > are overloaded terms.
> 
> In a properly setup headless sku, VBT should have all ports marked as
> disabled.

Should we take into account headless bit in opregion possibly
conflicting with VBT contents?

Now as you pointed out this I started to think
intel_opregion_headless_sku check could be also in here as additional
check:

if (!init_dp && !init_hdmi || intel_opregion_headless_sku()) {

This would prevent initializing any connector including setting them up
for polling?

> 
> intel_ddi_init() {
> ...
> 
> if (!init_dp && !init_hdmi) {
> drm_dbg_kms(&dev_priv->drm,
>     "VBT says port %c is not DVI/HDMI/DP compatible, respect it\n",
>     port_name(port));
> return;
> }
> 
> 
> All DDI should return earlier in the above.
> So you can use the number of enabled connectors to know if it is a
> headless sku or not.
> 
> So you can skip the pooling in case there is no connectors.
> 
> > Seems to me the use case here could be the same as
> > INTEL_DISPLAY_ENABLED(), and that could benefit from polling
> > disable.
> > 
> > BR,
> > Jani.
> > 
> > 
> > > > > > I certainly would not want to add another mode that's
> > > > > > separate
> > > > > > from
> > > > > > HAS_DISPLAY() and INTEL_DISPLAY_ENABLED().
> > > > > 
> > > > > No need for this. I think we can go with
> > > > > INTEL_DISPLAY_ENABLED.
> > > > > > > +
> > > > > > >  struct opregion_header {
> > > > > > >  u8 signature[16];
> > > > > > >  u32 size;
> > > > > > > @@ -1135,6 +1137,16 @@ struct edid
> > > > > > > *intel_opregion_get_edid(struct
> > > > > > > intel_connector *intel_connector)
> > > > > > >  return new_edid;
> > > > > > >  }
> > > > > > > 
> > > > > > > +bool intel_opregion_headless_sku(struct drm_i915_private
> > > > > > > *i915)
> > > > > > > +{
> > > > > > > +struct intel_opregion *opregion = &i915->opregion;
> > > > > > > +
> > > > > > > +if (!opregion->header)
> > > > > > > +return false;
> > > > > > > +
> > > > > > > +return opregion->header->pcon & PCON_HEADLESS_SKU;
> > > > > > 
> > > > > > We should probably start checking for opregion version for
> > > > > > this
> > > > > > stuff
> > > > > > too.
> > > > > > 
> > > > > 
> > > > > Yes, I will do this change.
> > > > > 
> > > > > > BR,
> > > > > > Jani.
> > > > > > 
> > > > > > > +}
> > > > > > > +
> > > > > > >  void intel_opregion_register(struct drm_i915_private
> > > > > > > *i915)
> > > > > > >  {
> > > > > > >  struct intel_opregion *opregion = &i915->opregion;
> > > > > > > diff --git
> > > > > > > a/drivers/gpu/drm/i915/display/intel_opregion.h
> > > > > > > b/drivers/gpu/drm/i915/display/intel_opregion.h
> > > > > > > index 82cc0ba34af7..5ad96e1d8278 100644
> > > > > > > --- a/drivers/gpu/drm/i915/display/intel_opregion.h
> > > > > > > +++ b/drivers/gpu/drm/i915/display/intel_opregion.h
> > > > > > > @@ -76,6 +76,8 @@ int
> > > > > > > intel_opregion_notify_adapter(struct
> > > > > > > drm_i915_private *dev_priv,
> > > > > > >  int intel_opregion_get_panel_type(struct
> > > > > > > drm_i915_private
> > > > > > > *dev_priv);
> > > > > > >  struct edid *intel_opregion_get_edid(struct
> > > > > > > intel_connector
> > > > > > > *connector);
> > > > > > > 
> > > > > > > +bool intel_opregion_headless_sku(struct drm_i915_private
> > > > > > > *i915);
> > > > > > > +
> > > > > > >  #else /* CONFIG_ACPI*/
> > > > > > > 
> > > > > > >  static inline int intel_opregion_setup(struct
> > > > > > > drm_i915_private
> > > > > > > *dev_priv)
> > > > > > > @@ -127,6 +129,11 @@ intel_opregion_get_edid(struct
> > > > > > > intel_connector
> > > > > > > *connector)
> > > > > > >  return NULL;
> > > > > > >  }
> > > > > > > 
> > > > > > > +bool intel_opregion_headless_sku(struct drm_i915_private
> > > > > > > *i915)
> > > > > > > +{
> > > > > > > +return false;
> > > > > > > +}
> > > > > > > +
> > > > > > >  #endif /* CONFIG_ACPI */
> > > > > > > 
> > > > > > >  #endif


  parent reply	other threads:[~2022-06-08  9:41 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-03 10:14 [Intel-gfx] [PATCH 0/2] Disable connector polling for a headless sku Jouni Högander
2022-06-03 10:14 ` [Intel-gfx] [PATCH 1/2] drm/i915/opregion: add function to check if " Jouni Högander
2022-06-03 12:43   ` Jani Nikula
2022-06-03 13:14     ` Hogander, Jouni
2022-06-03 16:32       ` Souza, Jose
2022-06-06  8:03         ` Hogander, Jouni
2022-06-06  8:16           ` Jani Nikula
2022-06-06 13:15             ` Souza, Jose
2022-06-07  7:36               ` Jani Nikula
2022-06-07 13:05                 ` Hogander, Jouni
2022-06-07 13:26                   ` Souza, Jose
2022-06-08  9:41               ` Hogander, Jouni [this message]
2022-06-10  7:25               ` Hogander, Jouni
2022-06-03 10:14 ` [Intel-gfx] [PATCH 2/2] drm/i915: do not start connector polling when " Jouni Högander
2022-06-03 11:01 ` [Intel-gfx] ✗ Fi.CI.SPARSE: warning for Disable connector polling for a " Patchwork
2022-06-03 13:01 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2022-06-03 15:38 ` [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=02ce1ff0d1968e54dfc43ef62fb6e2c0857ba21d.camel@intel.com \
    --to=jouni.hogander@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=jani.nikula@linux.intel.com \
    --cc=jose.souza@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