All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jani Nikula <jani.nikula@linux.intel.com>
To: Mika Kahola <mika.kahola@intel.com>, intel-gfx@lists.freedesktop.org
Cc: gustavo.sousa@intel.com, raag.jadav@intel.com,
	Mika Kahola <mika.kahola@intel.com>
Subject: Re: [PATCH v5 1/2] drm/i915/xe3lpd: Power request asserting/deasserting
Date: Tue, 26 Nov 2024 11:30:00 +0200	[thread overview]
Message-ID: <877c8qxrzb.fsf@intel.com> (raw)
In-Reply-To: <20241105131732.331436-2-mika.kahola@intel.com>

On Tue, 05 Nov 2024, Mika Kahola <mika.kahola@intel.com> wrote:
> There is a HW issue that arises when there are race conditions
> between TCSS entering/exiting TC7 or TC10 states while the
> driver is asserting/deasserting TCSS power request. As a
> workaround, Display driver will implement a mailbox sequence
> to ensure that the TCSS is in TC0 when TCSS power request is
> asserted/deasserted.
>
> The sequence is the following
>
> 1. Read mailbox command status and wait until run/busy bit is
>    clear
> 2. Write mailbox data value '1' for power request asserting
>    and '0' for power request deasserting
> 3. Write mailbox command run/busy bit and command value with 0x1
> 4. Read mailbox command and wait until run/busy bit is clear
>    before continuing power request.
>
> v2: Rename WA function (Gustavo)
>     Limit WA only for PTL platform with a TODO note (Gustavo)
>     Add TCSS_DISP_MAILBOX_IN_CMD_RUN_BUSY for clarity when writing
>     register data (Gustavo)
>     Move register defs from i915_reg.h to intel_cx0_phy_regs.h (Gustavo)
> v3: Use "struct intel_display" instead of "struct drm_i915_private" (Jani)
>     Move defs above C10 definitions in the
>     intel_cx0_phy_regs.h file (Gustavo)
>     Move drm_WARN_ON() inside WA function (Gustavo)
>     Rename workaround function as wa_14020908590() (Gustvo)
>     Use boolean enable instead of if-else structure (Raag)
> v4: Drop drm_WARN_ON() (Raag)
>     Fix function definition to fit into a single line (Raag)
>
> Reviewed-by: Raag Jadav <raag.jadav@intel.com>
> Signed-off-by: Mika Kahola <mika.kahola@intel.com>
> ---
>  .../gpu/drm/i915/display/intel_cx0_phy_regs.h |  8 +++++
>  drivers/gpu/drm/i915/display/intel_tc.c       | 31 +++++++++++++++++++
>  2 files changed, 39 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy_regs.h b/drivers/gpu/drm/i915/display/intel_cx0_phy_regs.h
> index f0e5c196eae4..5a0b55cca4a3 100644
> --- a/drivers/gpu/drm/i915/display/intel_cx0_phy_regs.h
> +++ b/drivers/gpu/drm/i915/display/intel_cx0_phy_regs.h
> @@ -200,6 +200,14 @@
>  #define   XELPDP_SSC_ENABLE_PLLA			REG_BIT(1)
>  #define   XELPDP_SSC_ENABLE_PLLB			REG_BIT(0)
>  
> +#define TCSS_DISP_MAILBOX_IN_CMD		_MMIO(0x161300)
> +#define   TCSS_DISP_MAILBOX_IN_CMD_RUN_BUSY	REG_BIT(31)
> +#define   TCSS_DISP_MAILBOX_IN_CMD_CMD_MASK	REG_GENMASK(7, 0)
> +#define   TCSS_DISP_MAILBOX_IN_CMD_DATA(val)	(TCSS_DISP_MAILBOX_IN_CMD_RUN_BUSY | \

Why does this contain TCSS_DISP_MAILBOX_IN_CMD_RUN_BUSY? You set it
separately anyway (and that's how it should be).

> +						REG_FIELD_PREP(TCSS_DISP_MAILBOX_IN_CMD_CMD_MASK, val))
> +
> +#define TCSS_DISP_MAILBOX_IN_DATA		_MMIO(0x161304)
> +
>  /* C10 Vendor Registers */
>  #define PHY_C10_VDR_PLL(idx)		(0xC00 + (idx))
>  #define   C10_PLL0_FRACEN		REG_BIT8(4)
> diff --git a/drivers/gpu/drm/i915/display/intel_tc.c b/drivers/gpu/drm/i915/display/intel_tc.c
> index b16c4d2d4077..e40d55f4c0c4 100644
> --- a/drivers/gpu/drm/i915/display/intel_tc.c
> +++ b/drivers/gpu/drm/i915/display/intel_tc.c
> @@ -1013,6 +1013,30 @@ xelpdp_tc_phy_wait_for_tcss_power(struct intel_tc_port *tc, bool enabled)
>  	return true;
>  }
>  
> +static void wa_14020908590(struct intel_display *display, bool enable)

Yeah I still don't like functions named wa_14020908590. It's
meaningless. What does it do?

> +{
> +	/* check if mailbox is running busy */
> +	if (intel_de_wait_for_clear(display, TCSS_DISP_MAILBOX_IN_CMD,
> +				    TCSS_DISP_MAILBOX_IN_CMD_RUN_BUSY, 10)) {
> +		drm_dbg_kms(display->drm,
> +			    "Timeout waiting for TCSS mailbox run/busy bit to clear\n");
> +		return;
> +	}
> +
> +	intel_de_write(display, TCSS_DISP_MAILBOX_IN_DATA, enable);

Not a fan of bool -> u32 implicit conversion here, with the register
contents not described.

> +	intel_de_write(display, TCSS_DISP_MAILBOX_IN_CMD,
> +		       TCSS_DISP_MAILBOX_IN_CMD_RUN_BUSY |
> +		       TCSS_DISP_MAILBOX_IN_CMD_DATA(0x1));
> +
> +	/* wait to clear mailbox running busy bit before continuing */
> +	if (intel_de_wait_for_clear(display, TCSS_DISP_MAILBOX_IN_CMD,
> +				    TCSS_DISP_MAILBOX_IN_CMD_RUN_BUSY, 10)) {
> +		drm_dbg_kms(display->drm,
> +			    "Timeout after writing data to mailbox. Mailbox run/busy bit did not clear\n");
> +		return;
> +	}
> +}
> +
>  static void __xelpdp_tc_phy_enable_tcss_power(struct intel_tc_port *tc, bool enable)
>  {
>  	struct drm_i915_private *i915 = tc_to_i915(tc);
> @@ -1022,6 +1046,13 @@ static void __xelpdp_tc_phy_enable_tcss_power(struct intel_tc_port *tc, bool ena
>  
>  	assert_tc_cold_blocked(tc);
>  
> +	/*
> +	 * Gfx driver WA 14020908590 for PTL tcss_rxdetect_clkswb_req/ack
> +	 * handshake violation when pwwreq= 0->1 during TC7/10 entry
> +	 */
> +	if (DISPLAY_VER(i915) == 30)
> +		wa_14020908590(&i915->display, enable);

You should add

	struct intel_display *display = &i915->display;

local variable already in this patch, so the next patch doesn't have to
modify the above line again. You can do the subsequent conversions in
the follow-up.

BR,
Jani.


> +
>  	val = intel_de_read(i915, reg);
>  	if (enable)
>  		val |= XELPDP_TCSS_POWER_REQUEST;

-- 
Jani Nikula, Intel

  reply	other threads:[~2024-11-26  9:30 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-11-05 13:17 [PATCH v5 0/2] drm/i915/display: Power request asserting/deasserting Mika Kahola
2024-11-05 13:17 ` [PATCH v5 1/2] drm/i915/xe3lpd: " Mika Kahola
2024-11-26  9:30   ` Jani Nikula [this message]
2024-11-26 13:20     ` Kahola, Mika
2024-11-26 13:36       ` Jani Nikula
2024-11-05 13:17 ` [PATCH v5 2/2] drm/i915/display: Use struct intel_display instead of struct drm_i915_private Mika Kahola
2024-11-26  9:03   ` Borah, Chaitanya Kumar
2024-11-26 11:18     ` Kahola, Mika
2024-11-05 13:55 ` ✗ Fi.CI.CHECKPATCH: warning for drm/i915/display: Power request asserting/deasserting (rev3) Patchwork
2024-11-05 13:55 ` ✗ Fi.CI.SPARSE: " Patchwork
2024-11-05 14:33 ` ✓ Fi.CI.BAT: success " 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=877c8qxrzb.fsf@intel.com \
    --to=jani.nikula@linux.intel.com \
    --cc=gustavo.sousa@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=mika.kahola@intel.com \
    --cc=raag.jadav@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.