Re: [Intel-gfx] [PATCH 2/2] drm/i915: Don't do MTRR setup if PAT is enabled
On Wed, Mar 14, 2012 at 11:22:11AM -0400, Adam Jackson wrote: Some newer BIOSes are shipping with all MTRRs already populated. These BIOSes are all on machines with sufficiently new CPUs that the referenced errata doesn't apply anyway, so just don't try to claim the MTRR. Signed-off-by: Adam Jackson a...@redhat.com Queued both patches for -next (with a bz link added to the later one), thanks. -Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Add wait_for in init_ring_common
On Fri, Mar 16, 2012 at 12:43:22PM -0400, Sean Paul wrote: I have seen a number of blt ring initialization failed messages where the ctl or start registers are not the correct value. Upon further inspection, if the code just waited a little bit, it would read the correct value. Adding the wait_for to these reads should eliminate the issue. Signed-off-by: Sean Paul seanp...@chromium.org I've picked up both patches into my -next tree. Thanks, Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Thinkpad T420 and single/dual channel lvds
Am 18.03.2012 um 18:50 schrieb Daniel Vetter:
On Fri, Mar 16, 2012 at 09:29:24PM +0100, Takashi Iwai wrote:
At Fri, 16 Mar 2012 15:55:52 -0400,
Adam Jackson wrote:
On 3/15/12 10:42 AM, Takashi Iwai wrote:
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index f851db7..314af26 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -356,6 +356,23 @@ static const intel_limit_t
intel_limits_ironlake_display_port = {
.find_pll = intel_find_pll_ironlake_dp,
};
+static bool is_dual_link_lvds(struct drm_i915_private *dev_priv,
+unsigned int reg)
+{
+ /* BIOS should set the proper LVDS register value at boot, but
+ * in reality, it doesn't set the value when the lid is closed;
+ * thus when a machine is booted with the lid closed, the LVDS
+ * reg value can't be trusted. So we need to check the value
+ * to be set in VBT at first.
+ */
+ if ((dev_priv-bios_lvds_val LVDS_CLKB_POWER_MASK) ==
+ LVDS_CLKB_POWER_UP)
+ return true;
Would slightly prefer if this was more like:
if (dev_priv-bios_lvds_val)
return !!(dev_priv-bios_lvds_val LVDS_CLKB_POWER_MASK);
Since that way it eliminates some useless register reads in the normal
case even for single-link. Not going to insist on it though.
Sounds reasonable, yes.
Also, it'd be good to have a module option to override the lvds
channel setup, e.g. lvds_channel=0 for probing BIOS like this,
lvds_channel=1 and 2 are to set the single and dual-channel mode
forcibly, respectively. If you guys think it's worth, I'll write an
additional patch after fixing this as suggested.
I think we can wait with adding debug options until this blows up. And if
there are indeed broken bios out there, we need a full quirk table anyway.
I'll wait for the new patch with Adam's suggestion for merging into -next.
-Daniel
Hi,
I tried this patch on a Macbook Pro 6,2 and indeed still need to manually set
lvds_channel=2.
It'd be great if this patch with the override parameter or some other way to
fix it would end up in mainline.
Cheers,
Andreas
--
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915: Add BUG_ON when ring-private is NULL
On Fri, Mar 16, 2012 at 12:43:21PM -0400, Sean Paul wrote: I have experienced a number of NULL pointer dereferences on suspend/resume where ring-private is NULL. These come from failed initialization of the ring buffer. Sincce this doesn't seem to be easily recoverable, this patch adds a BUG_ON and a bread crumb pointer for people who might encounter this in the future. Signed-off-by: Sean Paul seanp...@chromium.org Chris shot this down on irc, BUG_ON isn't really more useful than a NULL pointer oops. I agree, so I've dropped this from -next. -Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Thinkpad T420 and single/dual channel lvds
At Sun, 18 Mar 2012 18:50:31 +0100,
Daniel Vetter wrote:
On Fri, Mar 16, 2012 at 09:29:24PM +0100, Takashi Iwai wrote:
At Fri, 16 Mar 2012 15:55:52 -0400,
Adam Jackson wrote:
On 3/15/12 10:42 AM, Takashi Iwai wrote:
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index f851db7..314af26 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -356,6 +356,23 @@ static const intel_limit_t
intel_limits_ironlake_display_port = {
.find_pll = intel_find_pll_ironlake_dp,
};
+static bool is_dual_link_lvds(struct drm_i915_private *dev_priv,
+ unsigned int reg)
+{
+ /* BIOS should set the proper LVDS register value at boot, but
+* in reality, it doesn't set the value when the lid is closed;
+* thus when a machine is booted with the lid closed, the LVDS
+* reg value can't be trusted. So we need to check the value
+* to be set in VBT at first.
+*/
+ if ((dev_priv-bios_lvds_val LVDS_CLKB_POWER_MASK) ==
+ LVDS_CLKB_POWER_UP)
+ return true;
Would slightly prefer if this was more like:
if (dev_priv-bios_lvds_val)
return !!(dev_priv-bios_lvds_val LVDS_CLKB_POWER_MASK);
Since that way it eliminates some useless register reads in the normal
case even for single-link. Not going to insist on it though.
Sounds reasonable, yes.
Also, it'd be good to have a module option to override the lvds
channel setup, e.g. lvds_channel=0 for probing BIOS like this,
lvds_channel=1 and 2 are to set the single and dual-channel mode
forcibly, respectively. If you guys think it's worth, I'll write an
additional patch after fixing this as suggested.
I think we can wait with adding debug options until this blows up. And if
there are indeed broken bios out there, we need a full quirk table anyway.
The module option is often the easiest way to check, so I believe
it's a good thing. It won't break the current behavior, at least.
I'll wait for the new patch with Adam's suggestion for merging into -next.
I'll respin the patches tomorrow with people's suggestions.
thanks,
Takashi
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Thinkpad T420 and single/dual channel lvds
At Sun, 18 Mar 2012 19:01:21 +0100,
Andreas Heider wrote:
Am 18.03.2012 um 18:50 schrieb Daniel Vetter:
On Fri, Mar 16, 2012 at 09:29:24PM +0100, Takashi Iwai wrote:
At Fri, 16 Mar 2012 15:55:52 -0400,
Adam Jackson wrote:
On 3/15/12 10:42 AM, Takashi Iwai wrote:
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index f851db7..314af26 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -356,6 +356,23 @@ static const intel_limit_t
intel_limits_ironlake_display_port = {
.find_pll = intel_find_pll_ironlake_dp,
};
+static bool is_dual_link_lvds(struct drm_i915_private *dev_priv,
+ unsigned int reg)
+{
+/* BIOS should set the proper LVDS register value at boot, but
+ * in reality, it doesn't set the value when the lid is closed;
+ * thus when a machine is booted with the lid closed, the LVDS
+ * reg value can't be trusted. So we need to check the value
+ * to be set in VBT at first.
+ */
+if ((dev_priv-bios_lvds_val LVDS_CLKB_POWER_MASK) ==
+LVDS_CLKB_POWER_UP)
+return true;
Would slightly prefer if this was more like:
if (dev_priv-bios_lvds_val)
return !!(dev_priv-bios_lvds_val LVDS_CLKB_POWER_MASK);
Since that way it eliminates some useless register reads in the normal
case even for single-link. Not going to insist on it though.
Sounds reasonable, yes.
Also, it'd be good to have a module option to override the lvds
channel setup, e.g. lvds_channel=0 for probing BIOS like this,
lvds_channel=1 and 2 are to set the single and dual-channel mode
forcibly, respectively. If you guys think it's worth, I'll write an
additional patch after fixing this as suggested.
I think we can wait with adding debug options until this blows up. And if
there are indeed broken bios out there, we need a full quirk table anyway.
I'll wait for the new patch with Adam's suggestion for merging into -next.
-Daniel
Hi,
I tried this patch on a Macbook Pro 6,2 and indeed still need to manually set
lvds_channel=2.
OK, that's expected. Basically my patch would fix only the case where
the default BIOS works but doesn't work in some exceptional case (e.g.
boot with the closed lid).
It'd be great if this patch with the override parameter or some other way to
fix it would end up in mainline.
I think the module option would be good. It's needed to give an easy
way for testing. Then we can add the entries in some quirk tables.
thanks,
Takashi
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915: Check VBIOS value for determining LVDS dual channel mode, too
At Sat, 17 Mar 2012 12:01:17 -0700, Keith Packard wrote: #part sign=pgpmime On Sat, 17 Mar 2012 08:59:56 +0100, Takashi Iwai ti...@suse.de wrote: Well, the LVDS reg data isn't in lvds_dvo_timing but in lvds_fp_timing, thus you need to look at a different entry in anyway. Right, a parallel function which returns the lvds_fp_timing structure instead of pulling the data out of it. Just makes the code look more like the existing stuff. And, if we need more data from the lvds_fp_timing in the future, we'll have it available directly. Ah, OK I got your point now. This makes sense. I'll rewrite the patch tomorrow. I skipped it to simplify the code, but that'd be safer, indeed. Reducing the chances for regressions is my primary concern here; most people boot their machines with the lid open, so if we avoid the new code in that case, we'll be more likely to not break things. Yes, that's my biggest concern too. So I'd really appreciate if anyone else checks whether the patch doesn't break, at least (and helps sometimes). thanks, Takashi -- keith.pack...@intel.com ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915: Add BUG_ON when ring-private is NULL
On Sun, Mar 18, 2012 at 2:09 PM, Daniel Vetter dan...@ffwll.ch wrote: On Fri, Mar 16, 2012 at 12:43:21PM -0400, Sean Paul wrote: I have experienced a number of NULL pointer dereferences on suspend/resume where ring-private is NULL. These come from failed initialization of the ring buffer. Sincce this doesn't seem to be easily recoverable, this patch adds a BUG_ON and a bread crumb pointer for people who might encounter this in the future. Signed-off-by: Sean Paul seanp...@chromium.org Chris shot this down on irc, BUG_ON isn't really more useful than a NULL pointer oops. I agree, so I've dropped this from -next. Yep, makes sense, I agree. Thanks for the explanation. Sean -Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 00/18] i915 HW Context Support
The patches have changed quite a bit since the RFC, and therefore I didn't feel comfortable trying to do v2 information. I didn't feel comfortable taking the few r-bs that I had from the RFC except for the one patch that I applied wholesale. Summary: - Completely redid the patch splitting. The number of patches increased, but LOC is about the same, and a handful of the new patches are either because of more splitting, or completely new bits. - Reference counted context allows freeing the data structure and freeing the BO independently. This is probably the most significant change. - Convert ILK RC6 code to use context code. I'm hopefuly this will make things more stable, but have no proof. - Added trace events for context create/destroy/switch. - Only support render ring context switch (previous code supported any ring, though media ring is the only other ring which *should* work). Testing summary. ILK RC6, just booted to desktop SNB module load/unload testing 20 consecutive suspend resume cycles nexuiz with experimental mesa piglit quick.tests with experimental mesa I've seen time-elapsed, and polygonOffset intermittently fail, I believe this is caused by the following... Missed IRQs now seem to occur once every other piglit run. I have some new code to try to fix this... coming soon, I hope. IVB No testing done since RFC I'll respond to this email with links to what I used to test (code is currently not in pushable form). kernel libdrm mesa intel-gpu-tools Thanks to Chris Wilson, Daniel Vetter, and Eric Anholt for providing useful feedback in the RFC. Ben Widawsky (18): drm/i915: CXT_SIZE register offsets added drm/i915: preliminary context support drm/i915: context basic create destroy drm/i915: add context information to objects drm/i915: context switch implementation drm/i915: trace events for contexts drm/i915: Ivybridge MI_ARB_ON_OFF context w/a drm/i915: PIPE_CONTROL_TLB_INVALIDATE drm/i915: possibly invalidate TLB before context switch drm/i915: use the default context drm/i915: switch to default context on idle drm/i915: try to reset the gpu before unload drm/i915/context: create destroy ioctls drm/i915/context: switch contexts with execbuf2 drm/i915/context: add params drm/i915/context: anonymous context interfaces drm/i915: Ironlake rc6 can use context interfaces drm/i915: try to enable rc6 on Ironlake... again drivers/gpu/drm/i915/Makefile |1 + drivers/gpu/drm/i915/i915_debugfs.c|8 +- drivers/gpu/drm/i915/i915_dma.c|9 + drivers/gpu/drm/i915/i915_drv.c|1 + drivers/gpu/drm/i915/i915_drv.h| 43 ++- drivers/gpu/drm/i915/i915_gem.c| 11 + drivers/gpu/drm/i915/i915_gem_context.c| 513 drivers/gpu/drm/i915/i915_gem_execbuffer.c |6 + drivers/gpu/drm/i915/i915_reg.h| 26 ++ drivers/gpu/drm/i915/i915_trace.h | 59 drivers/gpu/drm/i915/intel_display.c | 95 +- drivers/gpu/drm/i915/intel_ringbuffer.c| 49 +++ drivers/gpu/drm/i915/intel_ringbuffer.h| 11 + include/drm/i915_drm.h | 21 +- 14 files changed, 755 insertions(+), 98 deletions(-) create mode 100644 drivers/gpu/drm/i915/i915_gem_context.c -- 1.7.9.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 01/18] drm/i915: CXT_SIZE register offsets added
From: Ben Widawsky bwida...@gmail.com The GPUs can have different default context layouts, and the sizes could vary based on platform or BIOS. In order to back the context object with a properly sized BO, we must read this register in order to find out a sufficient size. Thankfully (sarcarm!), the register moves and changes meanings throughout generations. CTX and CXT differences are intentional as that is how it is in the documentation (prior to GEN6 it was CXT). Signed-off-by: Ben Widawsky b...@bwidawsk.net --- drivers/gpu/drm/i915/i915_reg.h | 21 + 1 file changed, 21 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index 52a06be..9e518f4 100644 --- a/drivers/gpu/drm/i915/i915_reg.h +++ b/drivers/gpu/drm/i915/i915_reg.h @@ -1357,6 +1357,27 @@ */ #define CCID 0x2180 #define CCID_EN (10) +#define CXT_SIZE 0x21a0 +#define GEN6_CXT_POWER_SIZE(cxt_reg) ((cxt_reg 24) 0x3f) +#define GEN6_CXT_RING_SIZE(cxt_reg)((cxt_reg 18) 0x3f) +#define GEN6_CXT_RENDER_SIZE(cxt_reg) ((cxt_reg 12) 0x3f) +#define GEN6_CXT_EXTENDED_SIZE(cxt_reg)((cxt_reg 6) 0x3f) +#define GEN6_CXT_PIPELINE_SIZE(cxt_reg)((cxt_reg 0) 0x3f) +#define GEN6_CXT_TOTAL_SIZE(cxt_reg) (GEN6_CXT_POWER_SIZE(cxt_reg) + \ + GEN6_CXT_RING_SIZE(cxt_reg) + \ + GEN6_CXT_RENDER_SIZE(cxt_reg) + \ + GEN6_CXT_EXTENDED_SIZE(cxt_reg) + \ + GEN6_CXT_PIPELINE_SIZE(cxt_reg)) +#define GEN7_CTX_SIZE 0x21a8 +#define GEN7_CTX_RENDER_SIZE(ctx_reg) ((ctx_reg 16) 0x3f) +#define GEN7_CTX_EXTENDED_SIZE(ctx_reg)((ctx_reg 9) 0x7f) +#define GEN7_CTX_GT1_SIZE(ctx_reg) ((ctx_reg 6) 0x7) +#define GEN7_CTX_VFSTATE_SIZE(ctx_reg) ((ctx_reg 0) 0x3f) +#define GEN7_CTX_TOTAL_SIZE(ctx_reg) (GEN7_CTX_RENDER_SIZE(ctx_reg) + \ +GEN7_CTX_EXTENDED_SIZE(ctx_reg) + \ +GEN7_CTX_GT1_SIZE(ctx_reg) + \ +GEN7_CTX_VFSTATE_SIZE(ctx_reg)) + /* * Overlay regs */ -- 1.7.9.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 02/18] drm/i915: preliminary context support
Very basic code for context setup/destruction in the driver.
There are 4 entry points into the contexts, load, unload, open, close.
The names are self-explanatory except that load can be called during
reset, and also during pm thaw/resume. As we expect our context to be
preserved across these events, we do not reinitialize in this case.
Also an important note, as I intend to use contexts for ILK RC6, the
context initialization must always come before RC6 initialization.
As Adam Jackson pointed out, I picked an arbitrary cutoff of 1MB where I
decide the HW context is too big. The reason for this is even though
context sizes are increasing with every generation, they are still
measured in pages. If we somehow read back way more than that, it
probably means BIOS has done something strange, or we're running on a
platform that wasn't designed for this.
The 1MB was just a nice round number. I'm open to changing it to
something sensible if someone has a better idea.
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
drivers/gpu/drm/i915/Makefile |1 +
drivers/gpu/drm/i915/i915_dma.c |4 ++
drivers/gpu/drm/i915/i915_drv.c |1 +
drivers/gpu/drm/i915/i915_drv.h |9 +++
drivers/gpu/drm/i915/i915_gem.c |1 +
drivers/gpu/drm/i915/i915_gem_context.c | 114 +++
6 files changed, 130 insertions(+)
create mode 100644 drivers/gpu/drm/i915/i915_gem_context.c
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index ce7fc77..a625d30 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -7,6 +7,7 @@ i915-y := i915_drv.o i915_dma.o i915_irq.o \
i915_debugfs.o \
i915_suspend.o \
i915_gem.o \
+ i915_gem_context.o \
i915_gem_debug.o \
i915_gem_evict.o \
i915_gem_execbuffer.o \
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 9341eb8..4c7c1dc 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -2155,6 +2155,7 @@ int i915_driver_unload(struct drm_device *dev)
ret = i915_gpu_idle(dev, true);
if (ret)
DRM_ERROR(failed to idle hardware: %d\n, ret);
+ i915_gem_context_unload(dev);
mutex_unlock(dev-struct_mutex);
/* Cancel the retire work handler, which should be idle now. */
@@ -2244,6 +2245,8 @@ int i915_driver_open(struct drm_device *dev, struct
drm_file *file)
spin_lock_init(file_priv-mm.lock);
INIT_LIST_HEAD(file_priv-mm.request_list);
+ i915_gem_context_open(dev, file);
+
return 0;
}
@@ -2276,6 +2279,7 @@ void i915_driver_lastclose(struct drm_device * dev)
void i915_driver_preclose(struct drm_device * dev, struct drm_file *file_priv)
{
+ i915_gem_context_close(dev, file_priv);
i915_gem_release(dev, file_priv);
}
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 0694e17..b2c56db 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -742,6 +742,7 @@ int i915_reset(struct drm_device *dev, u8 flags)
if (HAS_BLT(dev))
dev_priv-ring[BCS].init(dev_priv-ring[BCS]);
+ i915_gem_context_load(dev);
i915_gem_init_ppgtt(dev);
mutex_unlock(dev-struct_mutex);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index c0f19f5..33c232a 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -779,6 +779,9 @@ typedef struct drm_i915_private {
struct drm_property *broadcast_rgb_property;
struct drm_property *force_audio_property;
+
+ bool hw_contexts_disabled;
+ uint32_t hw_context_size;
} drm_i915_private_t;
enum hdmi_force_audio {
@@ -1280,6 +1283,12 @@ i915_gem_get_unfenced_gtt_alignment(struct drm_device
*dev,
int i915_gem_object_set_cache_level(struct drm_i915_gem_object *obj,
enum i915_cache_level cache_level);
+/* i915_gem_context.c */
+void i915_gem_context_load(struct drm_device *dev);
+void i915_gem_context_unload(struct drm_device *dev);
+void i915_gem_context_open(struct drm_device *dev, struct drm_file *file);
+void i915_gem_context_close(struct drm_device *dev, struct drm_file *file);
+
/* i915_gem_gtt.c */
int __must_check i915_gem_init_aliasing_ppgtt(struct drm_device *dev);
void i915_gem_cleanup_aliasing_ppgtt(struct drm_device *dev);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 1f441f5..6343a82 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3811,6 +3811,7 @@ i915_gem_init_hw(struct drm_device *dev)
dev_priv-next_seqno = 1;
+ i915_gem_context_load(dev);
i915_gem_init_ppgtt(dev);
return 0;
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
[Intel-gfx] [PATCH 04/18] drm/i915: add context information to objects
Handy mostly for assertions.
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
drivers/gpu/drm/i915/i915_drv.h |5 +
drivers/gpu/drm/i915/i915_gem.c |1 +
drivers/gpu/drm/i915/i915_gem_context.c |3 +++
3 files changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index e49e2f7..f458a8f 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -953,6 +953,11 @@ struct drm_i915_gem_object {
* reaches 0, dev_priv-pending_flip_queue will be woken up.
*/
atomic_t pending_flip;
+
+ /**
+* = 0 if this object is the object for a context.
+*/
+ int context_id;
};
#define to_intel_bo(x) container_of(x, struct drm_i915_gem_object, base)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 6343a82..0985aa5 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3629,6 +3629,7 @@ struct drm_i915_gem_object *i915_gem_alloc_object(struct
drm_device *dev,
obj-madv = I915_MADV_WILLNEED;
/* Avoid an unnecessary call to unbind on the first bind. */
obj-map_and_fenceable = true;
+ obj-context_id = -1;
return obj;
}
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index 2c9116d..321bafd 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -127,6 +127,7 @@ again:
} else if (ret)
goto err_out;
+ (*ctx_out)-obj-context_id = (*ctx_out)-id;
return 0;
err_out:
@@ -171,6 +172,8 @@ static int create_default_context(struct drm_i915_private
*dev_priv)
* default context.
*/
ctx = dev_priv-ring[RCS].default_context;
+ ctx-id = DEFAULT_CONTEXT_ID;
+ ctx-obj-context_id = DEFAULT_CONTEXT_ID;
ret = i915_gem_object_pin(ctx-obj, CONTEXT_ALIGN, false);
if (ret)
do_destroy(ctx);
--
1.7.9.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 05/18] drm/i915: context switch implementation
Implement the context switch code as well as the interfaces to do the
context switch. This patch also doesn't match 1:1 with the RFC patches.
The main difference is that from Daniel's responses the last context
object is now stored instead of the last context. This aids in allows us
to free the context data structure, and context object independently.
There is room for optimization: this code will pin the context object
until the next context is active. The optimal way to do it is to
actually pin the object, move it to the active list, do the context
switch, and then unpin it. This allows the eviction code to actually
evict the context object if needed.
The context switch code is missing workarounds, they will be implemented
in future patches.
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
drivers/gpu/drm/i915/i915_drv.h |5 ++
drivers/gpu/drm/i915/i915_gem_context.c | 118 ++-
drivers/gpu/drm/i915/intel_ringbuffer.c | 26 +++
drivers/gpu/drm/i915/intel_ringbuffer.h |5 ++
4 files changed, 153 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index f458a8f..c6c2ada 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1303,10 +1303,15 @@ int i915_gem_object_set_cache_level(struct
drm_i915_gem_object *obj,
enum i915_cache_level cache_level);
/* i915_gem_context.c */
+#define I915_CONTEXT_FORCED_SWITCH (10)
+#define I915_CONTEXT_INITIAL_SWITCH (11)
void i915_gem_context_load(struct drm_device *dev);
void i915_gem_context_unload(struct drm_device *dev);
void i915_gem_context_open(struct drm_device *dev, struct drm_file *file);
void i915_gem_context_close(struct drm_device *dev, struct drm_file *file);
+int i915_switch_context(struct intel_ring_buffer *ring,
+ struct drm_file *file,
+ int to_id, u32 seqno, u32 flags);
/* i915_gem_gtt.c */
int __must_check i915_gem_init_aliasing_ppgtt(struct drm_device *dev);
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index 321bafd..cc508d5 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -262,7 +262,7 @@ void i915_gem_context_close(struct drm_device *dev, struct
drm_file *file)
mutex_unlock(dev-struct_mutex);
}
-static __used struct i915_hw_context *
+static struct i915_hw_context *
i915_gem_context_get(struct drm_i915_file_private *file_priv, u32 id)
{
struct i915_hw_context *ctx = NULL;
@@ -279,3 +279,119 @@ i915_gem_context_get(struct drm_i915_file_private
*file_priv, u32 id)
return ctx;
}
+
+static int do_switch(struct drm_i915_gem_object *from_obj,
+struct i915_hw_context *to,
+u32 seqno, u32 flags)
+{
+ bool initial_switch = (flags I915_CONTEXT_INITIAL_SWITCH) ? true :
false;
+ bool force = (flags I915_CONTEXT_FORCED_SWITCH) ? true : false;
+ struct intel_ring_buffer *ring = NULL;
+ u32 hw_flags = 0;
+ int ret;
+
+ BUG_ON(to == NULL);
+ BUG_ON(from_obj != NULL from_obj-pin_count == 0);
+ BUG_ON((from_obj != NULL from_obj-context_id 0) ||
to-obj-context_id 0);
+
+ ret = i915_gem_object_pin(to-obj, CONTEXT_ALIGN, false);
+ if (ret)
+ return ret;
+
+ if (initial_switch)
+ hw_flags |= MI_RESTORE_INHIBIT;
+ if (force)
+ hw_flags |= MI_FORCE_RESTORE;
+
+ ring = to-ring;
+ ret = intel_ring_mi_set_context(ring, to, hw_flags);
+ if (ret) {
+ i915_gem_object_unpin(to-obj);
+ return ret;
+ }
+
+ /* The backing object for the context is done after switching to the
+* *next* context. Therefore we cannot retire the previous context until
+* the next context has already started running. In fact, the below code
+* is a bit suboptimal because the retiring can occur simply after the
+* MI_SET_CONTEXT instead of when the next seqno has completed.
+*/
+ if (from_obj != NULL) {
+ i915_gem_object_move_to_active(from_obj, ring, seqno);
+ /* As long as MI_SET_CONTEXT is serializing, ie. it flushes the
+* whole damn pipeline, we don't need to explicitly mark the
+* object dirty. It should be safe to evict the object at any
+* point after MI_SET_CONTEXT has finished executing... true as
+* of GEN7. If not from_obj-dirty=1 would make this safer.
+*/
+ BUG_ON(from_obj-ring != to-ring);
+ }
+
+ if (from_obj)
+ i915_gem_object_unpin(from_obj);
+
+ ring-last_context_obj = to-obj;
+
+ return 0;
+}
+
+/**
+ * i915_switch_context() - perform a GPU context switch.
+ * @ring: ring for which we'll execute the
[Intel-gfx] [PATCH 06/18] drm/i915: trace events for contexts
Recommended by Daniel Vetter. The original code used DRM_DEBUG_DRIVER. With this we track context creation, destruction, and switching. Signed-off-by: Ben Widawsky b...@bwidawsk.net --- drivers/gpu/drm/i915/i915_gem_context.c |7 +++- drivers/gpu/drm/i915/i915_trace.h | 59 +++ 2 files changed, 65 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_gem_context.c b/drivers/gpu/drm/i915/i915_gem_context.c index cc508d5..f1559285 100644 --- a/drivers/gpu/drm/i915/i915_gem_context.c +++ b/drivers/gpu/drm/i915/i915_gem_context.c @@ -72,6 +72,8 @@ static void do_destroy(struct i915_hw_context *ctx) else BUG_ON(ctx != dev_priv-ring[RCS].default_context); + trace_i915_context_destroy(ctx); + drm_gem_object_unreference(ctx-obj-base); kfree(ctx); } @@ -105,7 +107,7 @@ create_hw_context(struct drm_device *dev, /* Default context will never have a file_priv */ if (file_priv == NULL) - return 0; + goto out; (*ctx_out)-file_priv = file_priv; @@ -127,7 +129,9 @@ again: } else if (ret) goto err_out; +out: (*ctx_out)-obj-context_id = (*ctx_out)-id; + trace_i915_context_create(*ctx_out); return 0; err_out: @@ -332,6 +336,7 @@ static int do_switch(struct drm_i915_gem_object *from_obj, ring-last_context_obj = to-obj; + trace_i915_context_switch(from_obj, to); return 0; } diff --git a/drivers/gpu/drm/i915/i915_trace.h b/drivers/gpu/drm/i915/i915_trace.h index dac7bba..d72a6f1 100644 --- a/drivers/gpu/drm/i915/i915_trace.h +++ b/drivers/gpu/drm/i915/i915_trace.h @@ -410,6 +410,65 @@ TRACE_EVENT(i915_reg_rw, (u32)(__entry-val 32)) ); +/* Context tracking */ +TRACE_EVENT(i915_context_create, + TP_PROTO(struct i915_hw_context *ctx), + TP_ARGS(ctx), + + TP_STRUCT__entry( +__field(struct i915_hw_context *, ctx) +__field(u32, id) +__field(struct drm_i915_gem_object *, obj) +), + + TP_fast_assign( + __entry-ctx = ctx; + __entry-id = ctx-id; + __entry-obj = ctx-obj; + ), + + TP_printk(ctx=%p, id=%u, obj=%p, + __entry-ctx, __entry-id, __entry-obj) +); + +TRACE_EVENT(i915_context_destroy, + TP_PROTO(struct i915_hw_context *ctx), + TP_ARGS(ctx), + + TP_STRUCT__entry( +__field(struct i915_hw_context *, ctx) +__field(u32, id) +), + + TP_fast_assign( + __entry-ctx = ctx; + __entry-id = ctx-id; + ), + + TP_printk(ctx=%p, id=%u, __entry-ctx, __entry-id) +); + +TRACE_EVENT(i915_context_switch, + TP_PROTO(struct drm_i915_gem_object *from, struct i915_hw_context *to), + TP_ARGS(from, to), + + TP_STRUCT__entry( +__field(struct drm_i915_gem_object *, fobj) +__field(struct drm_i915_gem_object *, tobj) +__field(u32, idf) +__field(u32, idt) + ), + + TP_fast_assign( + __entry-fobj = from; + __entry-idf = (from == NULL) ? -1 : to-obj-context_id; + __entry-tobj = to-obj; + __entry-idt = to-id; + ), + + TP_printk(context switch from %u (%p) to %u (%p), + __entry-idf, __entry-fobj, __entry-idt, __entry-tobj) +); #endif /* _I915_TRACE_H_ */ /* This part must be outside protection */ -- 1.7.9.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 07/18] drm/i915: Ivybridge MI_ARB_ON_OFF context w/a
The workaround itself applies to gen7 only (according to the docs) and
as Eric Anholt points out shouldn't be required since we don't use HW
scheduling features, and therefore arbitration. Though since it is a
small, and simple addition, and we don't really understand the issue,
just do it.
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
drivers/gpu/drm/i915/i915_reg.h |3 +++
drivers/gpu/drm/i915/intel_ringbuffer.c | 12 +++-
2 files changed, 14 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 9e518f4..1a83b4b 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -197,6 +197,9 @@
#define MI_DISPLAY_FLIPMI_INSTR(0x14, 2)
#define MI_DISPLAY_FLIP_I915 MI_INSTR(0x14, 1)
#define MI_DISPLAY_FLIP_PLANE(n) ((n) 20)
+#define MI_ARB_ON_OFF MI_INSTR(0x08, 0)
+#define MI_ARB_ENABLE(10)
+#define MI_ARB_DISABLE (00)
#define MI_SET_CONTEXT MI_INSTR(0x18, 0)
#define MI_MM_SPACE_GTT (18)
#define MI_MM_SPACE_PHYSICAL (08)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index cd74f86..1c1d6a6 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -926,10 +926,15 @@ int intel_ring_mi_set_context(struct intel_ring_buffer
*ring,
{
int ret;
- ret = intel_ring_begin(ring, 4);
+ ret = intel_ring_begin(ring, 6);
if (ret)
return ret;
+ if (IS_GEN7(ring-dev))
+ intel_ring_emit(ring, MI_ARB_ON_OFF | MI_ARB_DISABLE);
+ else
+ intel_ring_emit(ring, MI_NOOP);
+
intel_ring_emit(ring, MI_NOOP);
intel_ring_emit(ring, MI_SET_CONTEXT);
intel_ring_emit(ring, new_context-obj-gtt_offset |
@@ -940,6 +945,11 @@ int intel_ring_mi_set_context(struct intel_ring_buffer
*ring,
/* w/a: MI_SET_CONTEXT must always be followed by MI_NOOP */
intel_ring_emit(ring, MI_NOOP);
+ if (IS_GEN7(ring-dev))
+ intel_ring_emit(ring, MI_ARB_ON_OFF | MI_ARB_ENABLE);
+ else
+ intel_ring_emit(ring, MI_NOOP);
+
intel_ring_advance(ring);
return ret;
--
1.7.9.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 08/18] drm/i915: PIPE_CONTROL_TLB_INVALIDATE
This has showed up in several other patches. It's required for the next context workaround. I tested this one on its own and saw no differences in basic tests (performance or otherwise). Signed-off-by: Ben Widawsky b...@bwidawsk.net --- drivers/gpu/drm/i915/i915_reg.h |1 + drivers/gpu/drm/i915/intel_ringbuffer.c |1 + 2 files changed, 2 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index 1a83b4b..6b6d685 100644 --- a/drivers/gpu/drm/i915/i915_reg.h +++ b/drivers/gpu/drm/i915/i915_reg.h @@ -280,6 +280,7 @@ #define DISPLAY_PLANE_B (120) #define GFX_OP_PIPE_CONTROL(len) ((0x329)|(0x327)|(0x224)|(len-2)) #define PIPE_CONTROL_CS_STALL(120) +#define PIPE_CONTROL_TLB_INVALIDATE (118) #define PIPE_CONTROL_QW_WRITE(114) #define PIPE_CONTROL_DEPTH_STALL (113) #define PIPE_CONTROL_WRITE_FLUSH (112) diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c b/drivers/gpu/drm/i915/intel_ringbuffer.c index 1c1d6a6..e892364 100644 --- a/drivers/gpu/drm/i915/intel_ringbuffer.c +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c @@ -209,6 +209,7 @@ gen6_render_ring_flush(struct intel_ring_buffer *ring, * impact. */ flags |= PIPE_CONTROL_RENDER_TARGET_CACHE_FLUSH; + flags |= PIPE_CONTROL_TLB_INVALIDATE; flags |= PIPE_CONTROL_INSTRUCTION_CACHE_INVALIDATE; flags |= PIPE_CONTROL_TEXTURE_CACHE_INVALIDATE; flags |= PIPE_CONTROL_DEPTH_CACHE_FLUSH; -- 1.7.9.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 09/18] drm/i915: possibly invalidate TLB before context switch
From http://intellinuxgraphics.org/documentation/SNB/IHD_OS_Vol1_Part3.pdf
[DevSNB] If Flush TLB invalidation Mode is enabled it’s the driver’s
responsibility to invalidate the TLBs at least once after the previous
context switch after any GTT mappings changed (including new GTT
entries). This can be done by a pipelined PIPE_CONTROL with TLB inv bit
set immediately before MI_SET_CONTEXT.
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 12
drivers/gpu/drm/i915/intel_ringbuffer.h |4
2 files changed, 16 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index e892364..392e782 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -399,6 +399,10 @@ static int init_render_ring(struct intel_ring_buffer *ring)
return ret;
}
+ if (INTEL_INFO(dev)-gen == 6)
+ ring-itlb_before_ctx_switch =
+ !!(I915_READ(GFX_MODE) GFX_TLB_INVALIDATE_ALWAYS);
+
if (INTEL_INFO(dev)-gen = 6) {
I915_WRITE(INSTPM,
INSTPM_FORCE_ORDERING 16 | INSTPM_FORCE_ORDERING);
@@ -927,6 +931,14 @@ int intel_ring_mi_set_context(struct intel_ring_buffer
*ring,
{
int ret;
+ if (IS_GEN6(ring-dev) ring-itlb_before_ctx_switch) {
+ /* w/a: If Flush TLB Invalidation Mode is enabled, driver must
+* do a TLB invalidation prior to MI_SET_CONTEXT
+*/
+ gen6_render_ring_flush(ring, 0, 0);
+ }
+
+
ret = intel_ring_begin(ring, 6);
if (ret)
return ret;
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index 0ed98bb..e404e52 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -120,6 +120,10 @@ struct intel_ring_buffer {
wait_queue_head_t irq_queue;
drm_local_map_t map;
+ /**
+* Do an explicit TLB flush before MI_SET_CONTEXT
+*/
+ bool itlb_before_ctx_switch;
struct i915_hw_context *default_context;
struct drm_i915_gem_object *last_context_obj;
--
1.7.9.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 10/18] drm/i915: use the default context
With the code to do HW context switches in place have the driver load the
default context for the render ring when the driver loads.
The default context will be an ever present context that is available to
switch to at any time for the given ring.
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
drivers/gpu/drm/i915/i915_gem_context.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index f1559285..d9a08f2 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -37,6 +37,9 @@
static struct i915_hw_context *
i915_gem_context_get(struct drm_i915_file_private *file_priv, u32 id);
+static int do_switch(struct drm_i915_gem_object *from_obj,
+struct i915_hw_context *to, u32 seqno,
+u32 flags);
static int get_context_size(struct drm_device *dev)
{
@@ -182,6 +185,14 @@ static int create_default_context(struct drm_i915_private
*dev_priv)
if (ret)
do_destroy(ctx);
+ ret = do_switch(NULL, ctx, 0, I915_CONTEXT_INITIAL_SWITCH);
+ if (ret) {
+ i915_gem_object_unpin(ctx-obj);
+ BUG_ON(kref_put(dev_priv-ring[RCS].default_context-nref,
+ destroy_hw_context) == 0);
+ } else
+ DRM_DEBUG_DRIVER(Default HW context loaded\n);
+
return ret;
}
--
1.7.9.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 11/18] drm/i915: switch to default context on idle
To keep things as sane as possible, switch to the default context before
idling. This should help free context objects, as well as put things in
a more well defined state before suspending.
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
drivers/gpu/drm/i915/i915_gem.c |6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 0985aa5..c1aab45 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3685,6 +3685,8 @@ int
i915_gem_idle(struct drm_device *dev)
{
drm_i915_private_t *dev_priv = dev-dev_private;
+ struct intel_ring_buffer *ring = dev_priv-ring[RCS];
+ u32 seqno;
int ret;
mutex_lock(dev-struct_mutex);
@@ -3694,6 +3696,10 @@ i915_gem_idle(struct drm_device *dev)
return 0;
}
+ seqno = i915_gem_next_request_seqno(ring);
+ i915_switch_context(ring, NULL, DEFAULT_CONTEXT_ID, seqno, 0);
+ WARN_ON(i915_wait_request(ring, seqno, false));
+
ret = i915_gpu_idle(dev, true);
if (ret) {
mutex_unlock(dev-struct_mutex);
--
1.7.9.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 14/18] drm/i915/context: switch contexts with execbuf2
Use the rsvd1 field in execbuf2 to specify the context ID associated
with the workload. This will allow the driver to do the proper context
switch when/if needed.
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
drivers/gpu/drm/i915/i915_gem_execbuffer.c |6 ++
include/drm/i915_drm.h |4 +++-
2 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 81687af..c365e12 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -1058,6 +1058,7 @@ i915_gem_do_execbuffer(struct drm_device *dev, void *data,
struct drm_i915_gem_object *batch_obj;
struct drm_clip_rect *cliprects = NULL;
struct intel_ring_buffer *ring;
+ u32 ctx_id = args-context_info I915_EXEC_CONTEXT_ID_MASK;
u32 exec_start, exec_len;
u32 seqno;
u32 mask;
@@ -1266,6 +1267,10 @@ i915_gem_do_execbuffer(struct drm_device *dev, void
*data,
goto err;
}
+ ret = i915_switch_context(ring, file, ctx_id, seqno, 0);
+ if (ret)
+ goto err;
+
trace_i915_gem_ring_dispatch(ring, seqno);
exec_start = batch_obj-gtt_offset + args-batch_start_offset;
@@ -1372,6 +1377,7 @@ i915_gem_execbuffer(struct drm_device *dev, void *data,
exec2.num_cliprects = args-num_cliprects;
exec2.cliprects_ptr = args-cliprects_ptr;
exec2.flags = I915_EXEC_RENDER;
+ exec2.context_info = 0;
ret = i915_gem_do_execbuffer(dev, data, file, exec2, exec2_list);
if (!ret) {
diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h
index bead13e..03d159f 100644
--- a/include/drm/i915_drm.h
+++ b/include/drm/i915_drm.h
@@ -660,13 +660,15 @@ struct drm_i915_gem_execbuffer2 {
#define I915_EXEC_CONSTANTS_ABSOLUTE (16)
#define I915_EXEC_CONSTANTS_REL_SURFACE (26) /* gen4/5 only */
__u64 flags;
- __u64 rsvd1;
+ __u64 context_info;
__u64 rsvd2;
};
/** Resets the SO write offset registers for transform feedback on gen7. */
#define I915_EXEC_GEN7_SOL_RESET (18)
+#define I915_EXEC_CONTEXT_ID_MASK (0x)
+
struct drm_i915_gem_pin {
/** Handle of the buffer to be pinned. */
__u32 handle;
--
1.7.9.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 15/18] drm/i915/context: add params
From: Ben Widawsky bwida...@gmail.com
Parameters tell user space if contexts are available.
Signed-off-by: Ben Widawsky b...@bwidawsk.net
Reviewed-by: Eugeni Dodonov eugeni.dodo...@intel.com
Reviewed-by: Eric Anholt e...@anholt.net
---
drivers/gpu/drm/i915/i915_dma.c |3 +++
include/drm/i915_drm.h |1 +
2 files changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index fb3fccb..07d4b96 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -781,6 +781,9 @@ static int i915_getparam(struct drm_device *dev, void *data,
case I915_PARAM_HAS_RELAXED_DELTA:
value = 1;
break;
+ case I915_PARAM_HAS_CONTEXTS:
+ value = dev_priv-hw_contexts_disabled ? 0 : 1;
+ break;
case I915_PARAM_HAS_GEN7_SOL_RESET:
value = 1;
break;
diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h
index 03d159f..dd985e1 100644
--- a/include/drm/i915_drm.h
+++ b/include/drm/i915_drm.h
@@ -302,6 +302,7 @@ typedef struct drm_i915_irq_wait {
#define I915_PARAM_HAS_RELAXED_DELTA15
#define I915_PARAM_HAS_GEN7_SOL_RESET 16
#define I915_PARAM_HAS_LLC 17
+#define I915_PARAM_HAS_CONTEXTS 18
typedef struct drm_i915_getparam {
int param;
--
1.7.9.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 16/18] drm/i915/context: anonymous context interfaces
Ironlake RC6 needs to allocate a power context object which the hardware
can automatically switch to. Since the new context code nicely handles
contexts, create some interfaces so we can hook up the existing code to
the new code.
The right way to do this is to move a bunch of code out of
intel_display.c but I don't feel like doing it at this time. This patch
is a step in the right direction though.
CC: Jesse Barnes jbar...@virtuousgeek.org
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
drivers/gpu/drm/i915/i915_drv.h |3 +++
drivers/gpu/drm/i915/i915_gem_context.c | 40 +--
2 files changed, 41 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index d49615e..003b62e 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -280,6 +280,7 @@ struct i915_hw_ppgtt {
/* This must match up with the value previously used for execbuf2.rsvd1. */
#define DEFAULT_CONTEXT_ID 0
+#define ANONYMOUS_CONTEXT_ID 1
struct i915_hw_context {
struct drm_i915_file_private *file_priv;
struct kref nref;
@@ -1316,6 +1317,8 @@ int i915_gem_context_create_ioctl(struct drm_device *dev,
void *data,
struct drm_file *file);
int i915_gem_context_destroy_ioctl(struct drm_device *dev, void *data,
struct drm_file *file);
+struct i915_hw_context *i915_context_alloc_anonymous(struct drm_device *dev);
+void i915_context_destroy_anonymous(struct i915_hw_context *ctx);
/* i915_gem_gtt.c */
int __must_check i915_gem_init_aliasing_ppgtt(struct drm_device *dev);
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index accb3de..de1f3ce 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -122,7 +122,7 @@ again:
spin_lock(file_priv-context_lock);
ret = idr_get_new_above(file_priv-context_idr, *ctx_out,
- DEFAULT_CONTEXT_ID + 1, id);
+ ANONYMOUS_CONTEXT_ID + 1, id);
if (ret == 0)
(*ctx_out)-id = id;
spin_unlock(file_priv-context_lock);
@@ -254,7 +254,7 @@ static int context_idr_cleanup(int id, void *p, void *data)
struct drm_i915_file_private *file_priv = file-driver_priv;
struct i915_hw_context *ctx;
- BUG_ON(id == DEFAULT_CONTEXT_ID);
+ BUG_ON(id == DEFAULT_CONTEXT_ID || id == ANONYMOUS_CONTEXT_ID);
ctx = i915_gem_context_get(file_priv, id);
BUG_ON(ctx == NULL);
kref_put(ctx-nref, destroy_hw_context);
@@ -380,6 +380,8 @@ int i915_switch_context(struct intel_ring_buffer *ring,
if (ring != dev_priv-ring[RCS])
return 0;
+ BUG_ON(to_id == ANONYMOUS_CONTEXT_ID);
+
if (file)
file_priv = file-driver_priv;
@@ -475,3 +477,37 @@ int i915_gem_context_destroy_ioctl(struct drm_device *dev,
void *data,
DRM_DEBUG_DRIVER(HW context %d destroyed\n, args-ctx_id);
return 0;
}
+
+struct i915_hw_context *
+i915_context_alloc_anonymous(struct drm_device *dev)
+{
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ struct i915_hw_context *ctx;
+ int ret;
+
+ if (dev_priv-hw_contexts_disabled)
+ return NULL;
+
+ ret = create_hw_context(dev, NULL, ctx);
+ if (ret)
+ return NULL;
+
+ ctx-id = ANONYMOUS_CONTEXT_ID;
+ ctx-obj-context_id = ANONYMOUS_CONTEXT_ID;
+
+ /* Anonymous contexts are assumed to be always pinned */
+ ret = i915_gem_object_pin(ctx-obj, CONTEXT_ALIGN, false);
+ if (ret)
+ do_destroy(ctx);
+
+ return ctx;
+}
+
+void i915_context_destroy_anonymous(struct i915_hw_context *ctx)
+{
+ BUG_ON(ctx-id != ANONYMOUS_CONTEXT_ID);
+ BUG_ON(ctx-obj-context_id != ANONYMOUS_CONTEXT_ID);
+
+ i915_gem_object_unpin(ctx-obj);
+ kref_put(ctx-nref, destroy_hw_context);
+}
--
1.7.9.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 17/18] drm/i915: Ironlake rc6 can use context interfaces
Use the context interfaces to create the power context. Assuming we
have a default context, there should be no need to switch to
the render context anymore as the default context should already serve
this purpose.
As a double cautionary measure we check the CCID to make sure everything
looks kosher, and don't enable RC6 if it doesn't.
There is an important difference in logic when switching to the context
interface. The old code use MI_SUSPEND_FLUSH before MI_SET_CONTEXT which was an
ILK specific workaround I remember seeing in old docs but can no longer find.
That workaround is not implemented in the standard context code.
PS. I think there is a double mutex_unlock in the existing error path
CC: Jesse Barnes jbar...@virtuousgeek.org
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
drivers/gpu/drm/i915/i915_debugfs.c |8 +--
drivers/gpu/drm/i915/i915_drv.h |3 +-
drivers/gpu/drm/i915/i915_reg.h |1 +
drivers/gpu/drm/i915/intel_display.c | 89 +++---
4 files changed, 10 insertions(+), 91 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index fdb7cce..6c98d18 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1372,13 +1372,7 @@ static int i915_context_status(struct seq_file *m, void
*unused)
if (dev_priv-pwrctx) {
seq_printf(m, power context );
- describe_obj(m, dev_priv-pwrctx);
- seq_printf(m, \n);
- }
-
- if (dev_priv-renderctx) {
- seq_printf(m, render context );
- describe_obj(m, dev_priv-renderctx);
+ describe_obj(m, dev_priv-pwrctx-obj);
seq_printf(m, \n);
}
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 003b62e..1329b1f 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -352,8 +352,7 @@ typedef struct drm_i915_private {
drm_dma_handle_t *status_page_dmah;
uint32_t counter;
drm_local_map_t hws_map;
- struct drm_i915_gem_object *pwrctx;
- struct drm_i915_gem_object *renderctx;
+ struct i915_hw_context *pwrctx;
struct resource mch_res;
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 6b6d685..4965638 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -1360,6 +1360,7 @@
* Logical Context regs
*/
#define CCID 0x2180
+#define CCID_MASK 0xf000
#define CCID_EN (10)
#define CXT_SIZE 0x21a0
#define GEN6_CXT_POWER_SIZE(cxt_reg) ((cxt_reg 24) 0x3f)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index de1ba19..4ef968a 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -7948,42 +7948,6 @@ static const struct drm_mode_config_funcs
intel_mode_funcs = {
.output_poll_changed = intel_fb_output_poll_changed,
};
-static struct drm_i915_gem_object *
-intel_alloc_context_page(struct drm_device *dev)
-{
- struct drm_i915_gem_object *ctx;
- int ret;
-
- WARN_ON(!mutex_is_locked(dev-struct_mutex));
-
- ctx = i915_gem_alloc_object(dev, 4096);
- if (!ctx) {
- DRM_DEBUG(failed to alloc power context, RC6 disabled\n);
- return NULL;
- }
-
- ret = i915_gem_object_pin(ctx, 4096, true);
- if (ret) {
- DRM_ERROR(failed to pin power context: %d\n, ret);
- goto err_unref;
- }
-
- ret = i915_gem_object_set_to_gtt_domain(ctx, 1);
- if (ret) {
- DRM_ERROR(failed to set-domain on power context: %d\n, ret);
- goto err_unpin;
- }
-
- return ctx;
-
-err_unpin:
- i915_gem_object_unpin(ctx);
-err_unref:
- drm_gem_object_unreference(ctx-base);
- mutex_unlock(dev-struct_mutex);
- return NULL;
-}
-
bool ironlake_set_drps(struct drm_device *dev, u8 val)
{
struct drm_i915_private *dev_priv = dev-dev_private;
@@ -8667,15 +8631,8 @@ static void ironlake_teardown_rc6(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev-dev_private;
- if (dev_priv-renderctx) {
- i915_gem_object_unpin(dev_priv-renderctx);
- drm_gem_object_unreference(dev_priv-renderctx-base);
- dev_priv-renderctx = NULL;
- }
-
if (dev_priv-pwrctx) {
- i915_gem_object_unpin(dev_priv-pwrctx);
- drm_gem_object_unreference(dev_priv-pwrctx-base);
+ i915_context_destroy_anonymous(dev_priv-pwrctx);
dev_priv-pwrctx = NULL;
}
}
@@ -8704,13 +8661,11 @@ static int ironlake_setup_rc6(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev-dev_private;
- if (dev_priv-renderctx
Re: [Intel-gfx] Updated -next
Hi Dave, QA beat on the -next tree in my absence and filed 3 new issue. Afaict they're all new sightings of old issues (hooray for improved test-suites) safe for a very funky sporadic failure on ilk - investigation is still going on this one. Otherwise the missed irq on snb poped up again, but Ben confirmed that the full ivb voodoo works. You likely get a one-liner to enable that on snb, too. And imo the swizzling regression has been fixed as well as possible given the ugly situation - the patch to fix lying kernels prior to 3.2 is submitted to stable (needed for correctness with updated mesa git/8.0) and the mesa patch to correctly detile the stencil buffer is on track to get into the next 8.0 release (the only affected mesa release branch). Highlights of this pull request: - gmbus fixes and reenabling gmbus by default (one-liner to switch back). Note that this also contains a i2c core change and a i2c patch for nouveau. - random smaller fixes and some quirks - the finish_gpu patch, despite the lack of a clear testcase and and obviously correct theory how exactly this fixes anything. But this does paper too well over various issues (among them the hibernate desaster, at least to some extent), so I've grumpily included it. i.e. winding down for 3.4. PSA to everyone else: I expect the next -next to go into 3.5 already, so if I've picked up patches that you think should go into 3.4, please annoy Keith about them. As usual, qa report below the pull request. Cheers, Daniel The following changes since commit ff5f4b0585620e5c158ecaad84d91c5bf3c5d0a1: Merge remote-tracking branch 'airlied/drm-next' into for-airlied (2012-02-23 14:56:11 +0100) are available in the git repository at: git://people.freedesktop.org/~danvet/drm-intel tags/drm-intel-next-2012-03-01 for you to fetch changes up to c501ae7f332cdaf42e31af30b72b4b66cbbb1604: drm/i915: Only clear the GPU domains upon a successful finish (2012-03-01 21:36:13 +0100) Benson Leung (1): drm/i915: Fix single msg gmbus_xfers writes Chris Wilson (5): drm/i915/bios: Downgrade the signature missing DRM_ERROR to debug drm/i915: Only bump refcnt on objects scheduled for eviction drm/i915: No need to search again after retiring requests drm/i915: Silence the error message from i915_wait_request() drm/i915: Only clear the GPU domains upon a successful finish Daniel Vetter (9): drm/i915: use the new hdmi_force_audio enum more drm/i915: error_buffer-ring should be signed drm/i915: add dev_priv to intel_gmbus drm/nouveau: do a better job at hiding the NIH i2c bit-banging algo i2c: export bit-banging algo functions drm/i915: merge struct intel_gpio into struct intel_gmbus drm/i915: merge gmbus and gpio i2c adpater into one drm/i915: i2c: unconditionally set up gpio fallback drm/i915: reenable gmbus on gen3+ again Marc Gariepy (1): drm/i915: Ignore LVDS on hp t5745 and hp st5747 thin client Philipp Grete (1): drm/i915: Fixes distorted external screen image on HP 2730p drivers/gpu/drm/i915/i915_drv.h | 19 +++- drivers/gpu/drm/i915/i915_gem.c | 12 +-- drivers/gpu/drm/i915/i915_gem_evict.c | 19 +--- drivers/gpu/drm/i915/intel_bios.c |2 +- drivers/gpu/drm/i915/intel_display.c |2 - drivers/gpu/drm/i915/intel_dp.c | 10 +- drivers/gpu/drm/i915/intel_i2c.c | 190 +--- drivers/gpu/drm/i915/intel_lvds.c | 16 +++ drivers/gpu/drm/i915/intel_sdvo.c | 10 +- drivers/gpu/drm/nouveau/nouveau_i2c.c |8 +- drivers/i2c/algos/i2c-algo-bit.c |3 +- include/linux/i2c-algo-bit.h |1 + 12 files changed, 130 insertions(+), 162 deletions(-) On Thu, Mar 08, 2012 at 08:10:47AM +, Sun, Yi wrote: New round Kernel testing is finished. This time we covered the platform IVB, SNB, ILK, G45, PNV. The kernel commit is: Kernel: (drm-intel-testing) 9c5a1897768918a941aebbeaefd9f698358c7cf9 Merge: c501ae7 108b0d3 Author: Daniel Vetter daniel.vet...@ffwll.ch Date: Thu Mar 1 21:47:53 2012 +0100 Merge remote-tracking branch 'airlied/drm-fixes' into drm-intel-testing Conflicts: drivers/gpu/drm/i915/intel_ringbuffer.c New filed bugs: Bug 47034 - [G45]testdisplay can't show all modes with VGA interface and black screen (https://bugs.freedesktop.org/show_bug.cgi?id=47034) Bug 47082 - [G33]GPU hung while running gem_cs_prefetch of intel-gpu-tools (https://bugs.freedesktop.org/show_bug.cgi?id=47082) Bug 47085 - [ILK]I-G-T/gem_pipe_control_store_loop fail unstablely (https://bugs.freedesktop.org/show_bug.cgi?id=47085) Note that, the bug 47082 and 47085 are unstable issue. If run the test cases separately, both two cases would pass. But if run the whole i-g-t suite with make test, the two cases which involved in the bug report would fail sometimes. It's
Re: [Intel-gfx] VA-API brightness property
Please, can anyone tell me if there is a list for user questions about VAAPI? I have several questions... The list for VAAPI is li...@lists.freedesktop.org As for brightness property, the driver doesn't support it. Thanks Haihao Greets, Kiste Am 09.03.2012 08:04, schrieb Oliver Seitz: Hi! I'm using the patched, VA-API enabled MPlayer on SandyBridge. System is Debian Wheezy. Works great, decodes BluRay-like quality with neglectable CPU load (below 5%). Now, I'm trying to adjust brightness. I think I've read that VA-API defines a brightness property, but MPlayer can not set it. Is this feature still missing in the driver, or is MPlayer calling for it in the wrong way? Thanks for any hints! Greets, Kiste ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 00/18] i915 HW Context Support
On Sun, Mar 18, 2012 at 01:39:40PM -0700, Ben Widawsky wrote: The patches have changed quite a bit since the RFC, and therefore I didn't feel comfortable trying to do v2 information. I didn't feel comfortable taking the few r-bs that I had from the RFC except for the one patch that I applied wholesale. Summary: - Completely redid the patch splitting. The number of patches increased, but LOC is about the same, and a handful of the new patches are either because of more splitting, or completely new bits. - Reference counted context allows freeing the data structure and freeing the BO independently. This is probably the most significant change. - Convert ILK RC6 code to use context code. I'm hopefuly this will make things more stable, but have no proof. - Added trace events for context create/destroy/switch. - Only support render ring context switch (previous code supported any ring, though media ring is the only other ring which *should* work). Testing summary. ILK RC6, just booted to desktop SNB module load/unload testing 20 consecutive suspend resume cycles nexuiz with experimental mesa piglit quick.tests with experimental mesa I've seen time-elapsed, and polygonOffset intermittently fail, I believe this is caused by the following... Missed IRQs now seem to occur once every other piglit run. I have some new code to try to fix this... coming soon, I hope. IVB No testing done since RFC I'll respond to this email with links to what I used to test (code is currently not in pushable form). kernel libdrm mesa intel-gpu-tools Kernel: git://people.freedesktop.org/~bwidawsk/drm-intel context_support libdrm: git://people.freedesktop.org/~bwidawsk/drm context_support mesa: git://people.freedesktop.org/~bwidawsk/mesa context_support intel-gpu-tools git://people.freedesktop.org/~bwidawsk/intel-gpu-tools context_support ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
