From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Andrzej Hajda <andrzej.hajda@intel.com>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH v2 08/15] drm/i915: Fix region start during initial plane readout
Date: Fri, 12 Jan 2024 16:53:50 +0200 [thread overview]
Message-ID: <ZaFSfqYHyHOVnZ3o@intel.com> (raw)
In-Reply-To: <ZYDdS0xqHT2_tS61@intel.com>
On Tue, Dec 19, 2023 at 02:01:15AM +0200, Ville Syrjälä wrote:
> On Mon, Dec 18, 2023 at 02:00:10PM +0100, Andrzej Hajda wrote:
> > On 15.12.2023 11:59, Ville Syrjala wrote:
> > > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > >
> > > On MTL the stolen region starts at offset 8MiB from the start of
> > > LMEMBAR. The dma addresses are thus also offset by 8MiB. However the
> > > mm_node/etc. is zero based, and i915_pages_create_for_stolen() will
> > > add the appropriate region.start into the sg dma address. So when
> > > we do the readout we need to convert the dma address read from
> > > the PTE to be zero based as well.
> > >
> > > Note that currently we don't take this path on MTL, but we should
> > > and thus this needs to be fixed. For lmem this works correctly
> > > already as the lmem region.start==0.
> > >
> > > While at it let's also make sure the address points to somewhere within
> > > the memory region. We don't need to check the size as
> > > i915_gem_object_create_region_at() should later fail if the object size
> > > exceeds the region size.
> > >
> > > Cc: Paz Zcharya <pazz@chromium.org>
> > > Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > > ---
> > > drivers/gpu/drm/i915/display/intel_plane_initial.c | 8 +++++---
> > > 1 file changed, 5 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_plane_initial.c b/drivers/gpu/drm/i915/display/intel_plane_initial.c
> > > index ffc92b18fcf5..db594ccf0323 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_plane_initial.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_plane_initial.c
> > > @@ -79,16 +79,18 @@ initial_plane_vma(struct drm_i915_private *i915,
> > > * We don't currently expect this to ever be placed in the
> > > * stolen portion.
> > > */
> > > - if (phys_base >= resource_size(&mem->region)) {
> > > + if (phys_base < mem->region.start || phys_base > mem->region.end) {
> >
> > Maybe better:
> > phys_base + fb_size > mem->region.end" ?
> > Btw it seems redundant with later checks in
> > i915_gem_object_create_region_at.
> > IMO at this moment we need only check if "phys_base -=
> > mem->region.start" makes sense.
>
> Yeah, I guess that alone would be sufficient. I left out the size
> check exactly because I knew it would fail later, and making an
> accurate check here (with page size rounding and whatnot) would
> be tedious. But this should also be true when the start offset
> is past the end of the region as well, so yeah I suppose I can
> just drop the second check.
After further pondering I think I'm leaning towards keeping this
as is, just to give a slightly more obvious debug message.
>
>
> >
> > Regards
> > Andrzej
> >
> >
> > > drm_err(&i915->drm,
> > > - "Initial plane programming using invalid range, phys_base=%pa\n",
> > > - &phys_base);
> > > + "Initial plane programming using invalid range, phys_base=%pa (%s [%pa-%pa])\n",
> > > + &phys_base, mem->region.name, &mem->region.start, &mem->region.end);
> > > return NULL;
> > > }
> > >
> > > drm_dbg(&i915->drm,
> > > "Using phys_base=%pa, based on initial plane programming\n",
> > > &phys_base);
> > > +
> > > + phys_base -= mem->region.start;
> > > } else {
> > > phys_base = base;
> > > mem = i915->mm.stolen_region;
>
> --
> Ville Syrjälä
> Intel
--
Ville Syrjälä
Intel
next prev parent reply other threads:[~2024-01-12 14:53 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-15 10:59 [PATCH v2 00/15] drm/i915: (stolen) memory region related fixes Ville Syrjala
2023-12-15 10:59 ` [PATCH v2 01/15] drm/i915: Use struct resource for memory region IO as well Ville Syrjala
2023-12-15 10:59 ` [PATCH v2 02/15] drm/i915: Print memory region info during probe Ville Syrjala
2023-12-15 10:59 ` [PATCH v2 03/15] drm/i915: Remove ad-hoc lmem/stolen debugs Ville Syrjala
2023-12-15 10:59 ` [PATCH v2 04/15] drm/i915: Bypass LMEMBAR/GTTMMADR for MTL stolen memory access Ville Syrjala
2023-12-15 21:58 ` Sripada, Radhakrishna
2024-01-10 9:13 ` Andrzej Hajda
2024-01-10 10:49 ` Nirmoy Das
2024-01-10 11:48 ` Nirmoy Das
2024-01-12 15:12 ` Ville Syrjälä
2024-01-12 16:31 ` Nirmoy Das
2024-01-12 16:55 ` Ville Syrjälä
2023-12-15 10:59 ` [PATCH v2 05/15] drm/i915: Disable the "binder" Ville Syrjala
2024-01-10 10:28 ` Andrzej Hajda
2023-12-15 10:59 ` [PATCH v2 06/15] drm/i915: Rename the DSM/GSM registers Ville Syrjala
2023-12-15 13:56 ` Andrzej Hajda
2023-12-15 10:59 ` [PATCH v2 07/15] drm/i915: Fix PTE decode during initial plane readout Ville Syrjala
2023-12-18 12:36 ` Andrzej Hajda
2023-12-15 10:59 ` [PATCH v2 08/15] drm/i915: Fix region start " Ville Syrjala
2023-12-18 13:00 ` Andrzej Hajda
2023-12-19 0:01 ` Ville Syrjälä
2024-01-12 14:53 ` Ville Syrjälä [this message]
2023-12-15 10:59 ` [PATCH v2 09/15] drm/i915: Fix MTL " Ville Syrjala
2023-12-19 10:58 ` Andrzej Hajda
2024-01-12 14:52 ` Ville Syrjälä
2023-12-15 10:59 ` [PATCH v2 10/15] drm/i915: s/phys_base/dma_addr/ Ville Syrjala
2023-12-19 10:55 ` Andrzej Hajda
2023-12-15 10:59 ` [PATCH v2 11/15] drm/i915: Split the smem and lmem plane readout apart Ville Syrjala
2023-12-19 10:55 ` Andrzej Hajda
2023-12-19 12:47 ` Ville Syrjälä
2023-12-15 10:59 ` [PATCH v2 12/15] drm/i915: Simplify intel_initial_plane_config() calling convention Ville Syrjala
2023-12-19 10:59 ` Andrzej Hajda
2024-01-13 0:55 ` kernel test robot
2024-01-13 6:27 ` kernel test robot
2023-12-15 10:59 ` [PATCH v2 13/15] drm/i915/fbdev: Fix smem_start for LMEMBAR stolen objects Ville Syrjala
2024-01-10 9:12 ` Andrzej Hajda
2023-12-15 10:59 ` [PATCH v2 14/15] drm/i915: Tweak BIOS fb reuse check Ville Syrjala
2024-01-10 9:36 ` Andrzej Hajda
2023-12-15 10:59 ` [PATCH v2 15/15] drm/i915: Try to relocate the BIOS fb to the start of ggtt Ville Syrjala
2024-01-10 10:11 ` Andrzej Hajda
2024-01-11 13:42 ` Ville Syrjälä
2024-01-11 14:06 ` [PATCH v3 " Ville Syrjala
2023-12-15 15:45 ` ✗ Fi.CI.CHECKPATCH: warning for drm/i915: (stolen) memory region related fixes (rev3) Patchwork
2023-12-15 15:45 ` ✗ Fi.CI.SPARSE: " Patchwork
2023-12-15 16:02 ` ✗ Fi.CI.BAT: failure " Patchwork
2024-01-11 17:08 ` ✗ Fi.CI.CHECKPATCH: warning for drm/i915: (stolen) memory region related fixes (rev5) Patchwork
2024-01-11 17:08 ` ✗ Fi.CI.SPARSE: " Patchwork
2024-01-11 17:22 ` ✓ Fi.CI.BAT: success " Patchwork
2024-01-11 22:46 ` ✓ Fi.CI.IGT: " 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=ZaFSfqYHyHOVnZ3o@intel.com \
--to=ville.syrjala@linux.intel.com \
--cc=andrzej.hajda@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