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