Intel-GFX Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Lucas De Marchi <lucas.demarchi@intel.com>
To: "Srivatsa, Anusha" <anusha.srivatsa@intel.com>
Cc: "intel-gfx@lists.freedesktop.org" <intel-gfx@lists.freedesktop.org>
Subject: Re: [Intel-gfx] [PATCH] drm/i915/dmc: Add MMIO range restrictions
Date: Mon, 25 Apr 2022 11:16:34 -0700	[thread overview]
Message-ID: <20220425181634.jjckffwautqmecou@ldmartin-desk2> (raw)
In-Reply-To: <79b46ab821c64ac69661f64a6cf18568@intel.com>

On Wed, Apr 06, 2022 at 08:53:56PM +0000, Anusha Srivatsa wrote:
>
>
>> -----Original Message-----
>> From: De Marchi, Lucas <lucas.demarchi@intel.com>
>> Sent: Wednesday, April 6, 2022 10:46 AM
>> To: Srivatsa, Anusha <anusha.srivatsa@intel.com>
>> Cc: intel-gfx@lists.freedesktop.org
>> Subject: Re: [Intel-gfx] [PATCH] drm/i915/dmc: Add MMIO range restrictions
>>
>> On Wed, Apr 06, 2022 at 10:16:55AM -0700, Anusha Srivatsa wrote:
>> >
>> >
>> >> -----Original Message-----
>> >> From: De Marchi, Lucas <lucas.demarchi@intel.com>
>> >> Sent: Tuesday, April 5, 2022 11:03 AM
>> >> To: Srivatsa, Anusha <anusha.srivatsa@intel.com>
>> >> Cc: intel-gfx@lists.freedesktop.org
>> >> Subject: Re: [Intel-gfx] [PATCH] drm/i915/dmc: Add MMIO range
>> >> restrictions
>> >>
>> >> On Tue, Apr 05, 2022 at 10:14:29AM -0700, Anusha Srivatsa wrote:
>> >> >Bspec has added some steps that check for DMC MMIO range before
>> >> >programming them.
>> >> >
>> >> >v2: Fix for CI failure for v1
>> >> >
>> >> >Cc: Lucas De Marchi <lucas.demarchi@intel.com>
>> >> >Signed-off-by: Anusha Srivatsa <anusha.srivatsa@intel.com>
>> >> >---
>> >> > drivers/gpu/drm/i915/display/intel_dmc.c | 42
>> >> ++++++++++++++++++++++++
>> >> > 1 file changed, 42 insertions(+)
>> >> >
>> >> >diff --git a/drivers/gpu/drm/i915/display/intel_dmc.c
>> >> >b/drivers/gpu/drm/i915/display/intel_dmc.c
>> >> >index 257cf662f9f4..05d8e90854ec 100644
>> >> >--- a/drivers/gpu/drm/i915/display/intel_dmc.c
>> >> >+++ b/drivers/gpu/drm/i915/display/intel_dmc.c
>> >> >@@ -103,6 +103,18 @@ MODULE_FIRMWARE(BXT_DMC_PATH);
>> >> > #define DMC_V1_MAX_MMIO_COUNT		8
>> >> > #define DMC_V3_MAX_MMIO_COUNT		20
>> >> > #define DMC_V1_MMIO_START_RANGE		0x80000
>> >> >+#define TGL_MAIN_MMIO_START		0x8F000
>> >> >+#define TGL_MAIN_MMIO_END		0x8FFFF
>> >> >+#define TGL_PIPEA_MMIO_START		0x92000
>> >> >+#define TGL_PIPEA_MMIO_END		0x93FFF
>> >> >+#define TGL_PIPEB_MMIO_START		0x96000
>> >> >+#define TGL_PIPEB_MMIO_END		0x97FFF
>> >> >+#define TGL_PIPEC_MMIO_START		0x9A000
>> >> >+#define TGL_PIPEC_MMIO_END		0x9BFFF
>> >> >+#define TGL_PIPED_MMIO_START		0x9E000
>> >> >+#define TGL_PIPED_MMIO_END		0x9FFFF
>> >> >+#define ADLP_PIPE_MMIO_START		0x5F000
>> >> >+#define ADLP_PIPE_MMIO_END		0x5FFFF
>> >> >
>> >> > struct intel_css_header {
>> >> > 	/* 0x09 for DMC */
>> >> >@@ -374,6 +386,30 @@ static void dmc_set_fw_offset(struct intel_dmc
>> >> *dmc,
>> >> > 	}
>> >> > }
>> >> >
>> >> >+static bool dmc_mmio_addr_sanity_check(struct intel_dmc *dmc, const
>> >> >+u32 *mmioaddr,
>> >> >+u32 mmio_count)
>> >> >+{
>> >> >+	struct drm_i915_private *i915 = container_of(dmc, typeof(*i915),
>> >> dmc);
>> >> >+	int i;
>> >> >+
>> >> >+	if (IS_DG2(i915) || IS_ALDERLAKE_P(i915)) {
>> >> >+		for (i = 0; i < mmio_count; i++) {
>> >> >+			if (!((mmioaddr[i] >= TGL_MAIN_MMIO_START &&
>> >> mmioaddr[i] <= TGL_MAIN_MMIO_END) ||
>> >> >+			      (mmioaddr[i] >= ADLP_PIPE_MMIO_START &&
>> >> mmioaddr[i] <= ADLP_PIPE_MMIO_END)))
>> >> >+				return false;
>> >> >+		}
>> >> >+	} else if (IS_TIGERLAKE(i915) || IS_DG1(i915) ||
>> >> IS_ALDERLAKE_S(i915))
>> >> >+		for (i = 0; i < mmio_count; i++) {
>> >> >+			if (!((mmioaddr[i] >= TGL_MAIN_MMIO_START &&
>> >> mmioaddr[i] <= TGL_MAIN_MMIO_END) ||
>> >> >+			      (mmioaddr[i] >= TGL_PIPEA_MMIO_START &&
>> >> mmioaddr[i] <= TGL_PIPEA_MMIO_END) ||
>> >> >+			      (mmioaddr[i] >= TGL_PIPEB_MMIO_START &&
>> >> mmioaddr[i] <= TGL_PIPEB_MMIO_END) ||
>> >> >+			      (mmioaddr[i] >= TGL_PIPEC_MMIO_START &&
>> >> mmioaddr[i] <= TGL_PIPEC_MMIO_END) ||
>> >> >+			      (mmioaddr[i] >= TGL_PIPED_MMIO_START &&
>> >> mmioaddr[i] <= TGL_PIPEC_MMIO_END)))
>> >> >+				return false;
>> >>
>> >> wonder if we should check for each pipe DMC range independently
>> >> rather than just checking all the ranges.
>> > Can convert this to a switch case in that scenario. "If it is PIPE A then it must
>> be within this range". But it will be 2 switches one for DG2 and ADLP and one
>> for TGL and the rest which have individual ranges for every pipe.
>>
>> I was thinking more about like this:
>>
>> #define _TGL_PIPEA_MMIO	0x92000
>> #define _TGL_PIPEB_MMIO	0x96000
>> #define TGL_PIPE_MMIO(pipe)	_MMIO_PIPE(pipe, _TGL_PIPEA_MMIO,
>> _TGL_PIPEB_MMIO)
>> #define TGL_PIPE_MMIO_SIZE	0x1000
>
>Hmm, does it make sense to add something like:
>
>#define DMC_MMIO(dmc_id)	_MMIO(_PICK(DMC_ID, DMC_FW_MAIN, DMC_FW_PIPEA, DMC_FW_PIPEB, DMC_FW_PIPEC, DMC_FW_PIPED)

typo here ----------------------------------^^^^^^

_PICK(dmc_id, DMC_FW_MAIN, DMC_FW_PIPEA, ...) would return 0, 1, ....
Why are you converting it to _MMIO? Did you mean to use the address?

If the main blob is not handled differently than it could make sense,
yes.


Lucas De Marchi

  reply	other threads:[~2022-04-25 18:16 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-05 17:14 [Intel-gfx] [PATCH] drm/i915/dmc: Add MMIO range restrictions Anusha Srivatsa
2022-04-05 18:02 ` Lucas De Marchi
2022-04-06 17:16   ` Srivatsa, Anusha
2022-04-06 17:46     ` Lucas De Marchi
2022-04-06 20:53       ` Srivatsa, Anusha
2022-04-25 18:16         ` Lucas De Marchi [this message]
2022-04-05 22:19 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/dmc: Add MMIO range restrictions (rev2) Patchwork
2022-04-05 22:24 ` [Intel-gfx] ✗ Fi.CI.DOCS: " Patchwork
2022-04-05 22:52 ` [Intel-gfx] ✗ Fi.CI.BAT: failure " Patchwork
2022-04-05 23:18 ` [Intel-gfx] [PATCH] drm/i915/dmc: Add MMIO range restrictions kernel test robot
2022-04-06  6:58 ` kernel test robot
  -- strict thread matches above, loose matches on Subject: below --
2022-05-06 17:35 Anusha Srivatsa
2022-05-04 18:32 Anusha Srivatsa
2022-05-04  0:13 Anusha Srivatsa
2022-05-04  0:31 ` Lucas De Marchi
2022-05-04  0:36   ` Srivatsa, Anusha
2022-05-03 23:36 Anusha Srivatsa
2022-05-03 22:04 Anusha Srivatsa
2022-04-27  0:35 Anusha Srivatsa
2022-04-27  4:26 ` kernel test robot
2022-04-27  5:41 ` Lucas De Marchi
2022-04-29 20:39   ` Srivatsa, Anusha
2022-04-29 20:49     ` Lucas De Marchi
2022-04-29 22:57       ` Srivatsa, Anusha
2022-05-02 18:09       ` Lucas De Marchi
2022-04-27  7:49 ` kernel test robot
2022-04-27 12:42 ` Andi Shyti
2022-04-05  0:35 Anusha Srivatsa

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=20220425181634.jjckffwautqmecou@ldmartin-desk2 \
    --to=lucas.demarchi@intel.com \
    --cc=anusha.srivatsa@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    /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