From: "Srivatsa, Anusha" <anusha.srivatsa@intel.com>
To: "De Marchi, Lucas" <lucas.demarchi@intel.com>
Cc: "intel-gfx@lists.freedesktop.org"
<intel-gfx@lists.freedesktop.org>,
"stable@vger.kernel.org" <stable@vger.kernel.org>
Subject: RE: [PATCH] drm/i915/dmc: Add MMIO range restrictions
Date: Wed, 4 May 2022 00:36:10 +0000 [thread overview]
Message-ID: <3dd28d33bbcc440791b8cdfa30fd4b4b@intel.com> (raw)
In-Reply-To: <20220504003123.7z4cpxdae43tnuor@ldmartin-desk2>
> -----Original Message-----
> From: De Marchi, Lucas <lucas.demarchi@intel.com>
> Sent: Tuesday, May 3, 2022 5:31 PM
> To: Srivatsa, Anusha <anusha.srivatsa@intel.com>
> Cc: intel-gfx@lists.freedesktop.org; stable@vger.kernel.org
> Subject: Re: [PATCH] drm/i915/dmc: Add MMIO range restrictions
>
> On Tue, May 03, 2022 at 05:13:46PM -0700, Anusha Srivatsa wrote:
> >Bspec has added some steps that check forDMC MMIO range before
> >programming them
> >
> >v2: Fix for CI
> >v3: move register defines to .h (Anusha)
> >- Check MMIO restrictions per pipe
> >- Add MMIO restricton for v1 dmc header as well (Lucas)
> >v4: s/_PICK/_PICK_EVEN and use it only for Pipe DMC scenario.
> >- clean up sanity check logic.(Lucas)
> >- Add MMIO range for RKL as well.(Anusha)
> >
> >BSpec: 49193
> >
> >Cc: <stable@vger.kernel.org>
> >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 | 43 +++++++++++++++++++
> > drivers/gpu/drm/i915/display/intel_dmc_regs.h | 18 +++++++-
> > 2 files changed, 60 insertions(+), 1 deletion(-)
> >
> >diff --git a/drivers/gpu/drm/i915/display/intel_dmc.c
> >b/drivers/gpu/drm/i915/display/intel_dmc.c
> >index 257cf662f9f4..e37ba75e68da 100644
> >--- a/drivers/gpu/drm/i915/display/intel_dmc.c
> >+++ b/drivers/gpu/drm/i915/display/intel_dmc.c
> >@@ -374,6 +374,44 @@ 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, int header_ver, u8
> dmc_id) {
> >+ struct drm_i915_private *i915 = container_of(dmc, typeof(*i915),
> dmc);
> >+ u32 start_range, end_range;
> >+ int i;
> >+
> >+ if (dmc_id >= DMC_FW_MAX || dmc_id < DMC_FW_MAIN) {
>
> dmc_id is unsigned and DMC_FW_MAIN is 0. dmc_id < DMC_FW_MAIN can't
> ever possibly happen so you can remove it.
>
> >+ drm_warn(&i915->drm, "Unsupported firmware id %u\n",
> dmc_id);
> >+ return false;
> >+ }
> >+
> >+ if (header_ver == 1) {
> >+ start_range = DMC_MMIO_START_RANGE;
> >+ end_range = DMC_MMIO_END_RANGE;
> >+ } else if (dmc_id == DMC_FW_MAIN) {
> >+ start_range = TGL_MAIN_MMIO_START;
> >+ end_range = TGL_MAIN_MMIO_END;
> >+ } else if (IS_DG2(i915) || IS_ALDERLAKE_P(i915)) {
>
> } else if (DISPLAY_VER(i915) >= 13) {
>
> ?
>
> >+ start_range = ADLP_PIPE_MMIO_START;
> >+ end_range = ADLP_PIPE_MMIO_END;
> >+ } else if (IS_TIGERLAKE(i915) || IS_DG1(i915) ||
> IS_ALDERLAKE_S(i915) ||
> >+ IS_ROCKETLAKE(i915)) {
>
> } else if (DISPLAY_VER(i915) >= 12) {
>
> ?
>
> maintaining the if/else ladder fine grained by platform is somewhat painful.
Agreed.
> >+ start_range = TGL_PIPE_MMIO_START(dmc_id);
> >+ end_range = TGL_PIPE_MMIO_END(dmc_id);
> >+ } else {
> >+ drm_warn(&i915->drm, "Unknown mmio range for sanity
> check");
> >+ return false;
> >+ }
> >+
> >+ for (i = 0; i < mmio_count; i++) {
> >+ if (mmioaddr[i] < start_range || mmioaddr[i] > end_range)
> >+ return false;
> >+ }
> >+
> >+ return true;
> >+}
> >+
> > static u32 parse_dmc_fw_header(struct intel_dmc *dmc,
> > const struct intel_dmc_header_base
> *dmc_header,
> > size_t rem_size, u8 dmc_id)
> >@@ -443,6 +481,11 @@ static u32 parse_dmc_fw_header(struct intel_dmc
> *dmc,
> > return 0;
> > }
> >
> >+ if (!dmc_mmio_addr_sanity_check(dmc, mmioaddr, mmio_count,
> dmc_header->header_ver, dmc_id)) {
> >+ drm_err(&i915->drm, "DMC firmware has Wrong MMIO
> Addresses\n");
> >+ return 0;
> >+ }
> >+
> > for (i = 0; i < mmio_count; i++) {
> > dmc_info->mmioaddr[i] = _MMIO(mmioaddr[i]);
> > dmc_info->mmiodata[i] = mmiodata[i]; diff --git
> >a/drivers/gpu/drm/i915/display/intel_dmc_regs.h
> >b/drivers/gpu/drm/i915/display/intel_dmc_regs.h
> >index d65e698832eb..67e14eb96a7a 100644
> >--- a/drivers/gpu/drm/i915/display/intel_dmc_regs.h
> >+++ b/drivers/gpu/drm/i915/display/intel_dmc_regs.h
> >@@ -16,7 +16,23 @@
> > #define DMC_LAST_WRITE _MMIO(0x8F034)
> > #define DMC_LAST_WRITE_VALUE 0xc003b400
> > #define DMC_MMIO_START_RANGE 0x80000
> >-#define DMC_MMIO_END_RANGE 0x8FFFF
> >+#define DMC_MMIO_END_RANGE 0x8FFFF
> >+#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 ADLP_PIPE_MMIO_START 0x5F000
> >+#define ADLP_PIPE_MMIO_END 0x5FFFF
>
> don't we have per-pipe range for ADLP_? Or is there only pipe A?
>
We don't have per-pipe range. We have one big chunk of range for all pipe DMC MMIOs.
> with the above fixes, feel free to add my Reviewed-by: Lucas De Marchi
> <lucas.demarchi@intel.com> in the next version.
Thanks!
> Lucas De Marchi
>
> >+
> >+#define TGL_PIPE_MMIO_START(dmc_id) _PICK_EVEN(((dmc_id) - 1),
> _TGL_PIPEA_MMIO_START,\
> >+ _TGL_PIPEB_MMIO_START)
> >+
> >+#define TGL_PIPE_MMIO_END(dmc_id) _PICK_EVEN(((dmc_id) - 1),
> _TGL_PIPEA_MMIO_END,\
> >+ _TGL_PIPEB_MMIO_END)
> >+
> > #define SKL_DMC_DC3_DC5_COUNT _MMIO(0x80030)
> > #define SKL_DMC_DC5_DC6_COUNT _MMIO(0x8002C)
> > #define BXT_DMC_DC3_DC5_COUNT _MMIO(0x80038)
> >--
> >2.25.1
> >
next prev parent reply other threads:[~2022-05-04 0:36 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-04 0:13 [PATCH] drm/i915/dmc: Add MMIO range restrictions Anusha Srivatsa
2022-05-04 0:31 ` Lucas De Marchi
2022-05-04 0:36 ` Srivatsa, Anusha [this message]
-- 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-03 23:36 Anusha Srivatsa
2022-05-03 22:04 Anusha Srivatsa
2022-04-27 0:35 Anusha Srivatsa
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
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=3dd28d33bbcc440791b8cdfa30fd4b4b@intel.com \
--to=anusha.srivatsa@intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=lucas.demarchi@intel.com \
--cc=stable@vger.kernel.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;
as well as URLs for NNTP newsgroup(s).