From: Ville Syrjala <ville.syrjala@linux.intel.com>
To: intel-gfx@lists.freedesktop.org
Subject: [PATCH 3/3] drm/i915: Pin error_capture to high end of mappable
Date: Fri, 15 Dec 2023 13:09:33 +0200 [thread overview]
Message-ID: <20231215110933.9188-4-ville.syrjala@linux.intel.com> (raw)
In-Reply-To: <20231215110933.9188-1-ville.syrjala@linux.intel.com>
From: Ville Syrjälä <ville.syrjala@linux.intel.com>
If we fail to pin error_capture to the start of ggtt (which
is likely given the BIOS fb is usually there), we currently
fall back to pinning it at the next available low address.
This seems somewhat sub-optimal to me in case we later discard
the BIOS fb (fairly likely if there are multiple different sized
displays connected at boot). We are then then left with a
permanenly pinned object somewhere in the middle of the mappable
range of ggtt. It seems more sensible to pin the error capture
object to the end of mappable as a fallback, so even if we discard
the BIOS fb we are left with the mappable region mostly in one
piece (potentially allowing for more/larger objects to be pinned
there later).
Though I suppose we are chopping the ggtt address space as a
whole into two chunks in a slightly different way. Essentially
reducing the size of the second (larger) chunk a bit. So perhaps
pinning truly massive objects (which don't strictly need to
be mappable) could become a bit more difficult.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
drivers/gpu/drm/i915/gt/intel_ggtt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c b/drivers/gpu/drm/i915/gt/intel_ggtt.c
index 21a7e3191c18..f62008962eb5 100644
--- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
@@ -876,7 +876,7 @@ static int init_ggtt(struct i915_ggtt *ggtt)
ggtt->error_capture.size, 0,
ggtt->error_capture.color,
0, ggtt->mappable_end,
- DRM_MM_INSERT_LOW);
+ DRM_MM_INSERT_HIGH);
}
if (drm_mm_node_allocated(&ggtt->error_capture)) {
u64 start = ggtt->error_capture.start;
--
2.41.0
next prev parent reply other threads:[~2023-12-15 11:09 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-15 11:09 [PATCH 0/3] drm/i915: Eaerly ggtt pinning stuff Ville Syrjala
2023-12-15 11:09 ` [PATCH 1/3] drm/i915/hdcp: Do intel_hdcp_component_init() much later during init Ville Syrjala
2024-01-10 15:31 ` Andrzej Hajda
2023-12-15 11:09 ` [PATCH 2/3] drm/i915/hdcp: Pin the hdcp gsc message high in ggtt Ville Syrjala
2024-01-10 15:42 ` Andrzej Hajda
2023-12-15 11:09 ` Ville Syrjala [this message]
2024-01-10 16:09 ` [PATCH 3/3] drm/i915: Pin error_capture to high end of mappable Andrzej Hajda
2024-01-11 13:27 ` Ville Syrjälä
2023-12-15 16:56 ` ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Eaerly ggtt pinning stuff Patchwork
2023-12-15 16:56 ` ✗ Fi.CI.SPARSE: " Patchwork
2023-12-15 17:15 ` ✓ Fi.CI.BAT: success " Patchwork
2023-12-16 0:32 ` ✗ Fi.CI.IGT: failure " 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=20231215110933.9188-4-ville.syrjala@linux.intel.com \
--to=ville.syrjala@linux.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 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.