Re: [Intel-gfx] [PATCH] drm/i915: remove pixel doubled HDMI modes from valid modes list
On Mon, Aug 11, 2014 at 03:33:02PM -0700, clinton.a.tay...@intel.com wrote: > From: Clint Taylor > > Intel HDMI does not correctly configure pixel replicated HDMI modes > 480i and 576i. Remove support for these modes until DRM has been > changed to correctly identify SD interlaced modes by reporting there > true horizontal resolution 720 instead of the pre-pixel doubled 1440. > > Signed-off-by: Clint Taylor > --- > drivers/gpu/drm/i915/intel_hdmi.c |3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/drivers/gpu/drm/i915/intel_hdmi.c > b/drivers/gpu/drm/i915/intel_hdmi.c > index 5f47d35..ab32523 100644 > --- a/drivers/gpu/drm/i915/intel_hdmi.c > +++ b/drivers/gpu/drm/i915/intel_hdmi.c > @@ -873,6 +873,9 @@ intel_hdmi_mode_valid(struct drm_connector *connector, > if (mode->flags & DRM_MODE_FLAG_DBLSCAN) > return MODE_NO_DBLESCAN; > If it is just a workaround for a drm bug. You need a big comment explaining why you w/a rather than pressing for the bug fix. > + if (mode->flags & DRM_MODE_FLAG_DBLCLK) > + return MODE_NO_INTERLACE; > + -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 5/6] drm/i915: Add 180 degree primary plane rotation support
On 8/11/2014 5:53 PM, Daniel Vetter wrote:
On Mon, Aug 11, 2014 at 05:37:20PM +0530, Jindal, Sonika wrote:
On 8/11/2014 5:12 PM, Daniel Vetter wrote:
On Mon, Aug 11, 2014 at 04:37:00PM +0530, Jindal, Sonika wrote:
Hi Daniel,
Are you taking this patch back in drm-intel?
We should still call the primary_plane->update hook directly instead of
open-coding it.
-Daniel
But we are already doing dev_priv->display.update_primary_plane. Can you
please elaborate? Last time we had a discussion on this same point, and we
thought for some platforms more work might be needed but for current
platforms this looks ok. Following was the discussion:
That's a different cook used internally in the driver (mostly for
historical reasons nowadays). I'm talking about the
drm_plane->fops->update_plane hook, which is implemented for primary
planes by intel_primary_plane_setplane.
Ok, let me add that and post a new patch for this.
-Sonika
The idea is to have the exact same code flow as for sprite planes, since
once we have atomic modesets that will be what we need. In the sprite
set_prop function you pretty directly call the update_plane hook, and I
think we should do the same here. Actually we might as well directly reuse
the intel_plane_restore function, it seems to exactly do what we want.
"> >Also Chris mentioned that on some platforms this won't work and it's
more future-proof to just do a full modeset until we have the proper
infrastructure.
Can you please elaborate on this? What needs to be done?
Apparently nothing, it turned out that on the platforms currently supported
everything is fine with your patch. Damien promised to follow up with the
details on internal mailing lists.
Damien follow up internally. Since we're now allowed to talk about skl
I'll paste this here:
"On SKL, for 90/270, we'll also need to update the watermarks and remap
the fb.
"We already duplicate some of the logic: the FBC update, wait for
pending flips, ...
"So maybe we should try to find a way to take the same path for all
updates. I'm not too sure how practical this is though."
Damien also said that he doesn't want to still the series on this, but
since we now have universal plane support for the primary plane I think it
makes a lot of sense.
-Daniel
-Daniel
"
-Sonika
On 8/7/2014 5:41 PM, Daniel Vetter wrote:
On Thu, Aug 07, 2014 at 01:45:31PM +0200, Daniel Vetter wrote:
On Tue, Jul 15, 2014 at 11:11:37AM +0200, Daniel Vetter wrote:
On Tue, Jul 15, 2014 at 02:10:28PM +0530, sonika.jin...@intel.com wrote:
+ /* FBC does not work on some platforms for rotated planes */
+ if (INTEL_INFO(dev)->gen <= 4 && !IS_G4X(dev)) {
+ if (dev_priv->fbc.plane == intel_crtc->plane &&
+ intel_plane->rotation != BIT(DRM_ROTATE_0))
+ intel_disable_fbc(dev);
+ /* If rotation was set earlier and new rotation is 0,
+ we might have disabled fbc earlier. So update it now */
+ else if (intel_plane->rotation ==
BIT(DRM_ROTATE_0)
+ && old_val != BIT(DRM_ROTATE_0)) {
+ mutex_lock(&dev->struct_mutex);
+ intel_update_fbc(dev);
+ mutex_unlock(&dev->struct_mutex);
+ }
+ }
Indentation is screwed up here. Also if we convert some of the checks into
early bails we could de-indent this by one level.
Also Chris mentioned that on some platforms this won't work and it's more
future-proof to just do a full modeset until we have the proper
infrastructure.
Apparently this review here was never addressed, as Chris just pointed out
on irc. I've dropped the patch again.
I think we need:
- The same sequence as with the sprite set_property function, i.e. we need
to call the update_plane function (not the raw low-level one, the
high-level with all the checks).
- The fbc check is wrong and will miss updates when the crtc is off. We
need to move this into the general list of checks in intel_update_fbc.
- Since this seems to be buggy I want added testcases to combine fbc
correctness with screen rotation. Probably best to reuse the existing
fbc testcase and add a bunch or rotated tests.
Ok, the check in update_fbc is there, I've been blind. Sorry about all the
confusion. So just amounts of calling the higher level function and we can
forgo the fbc testing.
-Daniel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: remove pixel doubled HDMI modes from valid modes list
From: Clint Taylor Intel HDMI does not correctly configure pixel replicated HDMI modes 480i and 576i. Remove support for these modes until DRM has been changed to correctly identify SD interlaced modes by reporting there true horizontal resolution 720 instead of the pre-pixel doubled 1440. Signed-off-by: Clint Taylor --- drivers/gpu/drm/i915/intel_hdmi.c |3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_hdmi.c b/drivers/gpu/drm/i915/intel_hdmi.c index 5f47d35..ab32523 100644 --- a/drivers/gpu/drm/i915/intel_hdmi.c +++ b/drivers/gpu/drm/i915/intel_hdmi.c @@ -873,6 +873,9 @@ intel_hdmi_mode_valid(struct drm_connector *connector, if (mode->flags & DRM_MODE_FLAG_DBLSCAN) return MODE_NO_DBLESCAN; + if (mode->flags & DRM_MODE_FLAG_DBLCLK) + return MODE_NO_INTERLACE; + return MODE_OK; } -- 1.7.9.5 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3] drm/i915/bdw: BDW Software Turbo
The expected design is a constant timer which will trigger GT busyness
calculation steadily, I understand.
Yet the case is that we would have to wrap up BDW related works as we
mentioned with Jesse, there are not enough resources to do further
development on the constant timer scheme, sorry that I'll not able to
rework this patch.
It would be great if Linux validation could at least do some
power/performance comparison study on the current solution to settle the
concerns. We feel this proposal has minimum package C-state impact and
hopefully better performance/watt impact.
Thanks,
Daisy
On 8/11/2014 2:33 PM, Daniel Vetter wrote:
On Mon, Aug 11, 2014 at 11:08:38AM -0700, Daisy Sun wrote:
BDW supports GT C0 residency reporting in constant time unit. Driver
calculates GT utilization based on C0 residency and adjusts RP
frequency up/down accordingly. For offscreen workload specificly,
set frequency to RP0.
Offscreen task is not restricted by frame rate, it can be
executed as soon as possible. Transcoding and serilized workload
between CPU and GPU both need high GT performance, RP0 is a good
option in this case. RC6 will kick in to compensate power
consumption when GT is not active.
v2: Rebase on recent drm-intel-nightly
v3: Add flip timerout monitor, when no flip is deteced within
100ms, set frequency to RP0.
Ok, let's make this really clear:
If you wire this into the flip handling in any way, I will not merge your
patch. The timer should be fully independant and tie into the gpu
busy/idle handling we already have.
Thanks, Daniel
Signed-off-by: Daisy Sun
[torourke: rebased on latest and resolved conflict]
Signed-off-by: Tom O'Rourke
---
drivers/gpu/drm/i915/i915_drv.h | 22
drivers/gpu/drm/i915/i915_irq.c | 21
drivers/gpu/drm/i915/i915_reg.h | 4 +
drivers/gpu/drm/i915/intel_display.c | 3 +
drivers/gpu/drm/i915/intel_pm.c | 230 +--
5 files changed, 241 insertions(+), 39 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index ef38c3b..f1c4c5b 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -915,6 +915,23 @@ struct intel_rps_ei {
u32 media_c0;
};
+struct intel_rps_bdw_cal {
+ u32 it_threshold_pct; /* interrupt, in percentage */
+ u32 eval_interval; /* evaluation interval, in us */
+ u32 last_ts;
+ u32 last_c0;
+ bool is_up;
+};
+
+struct intel_rps_bdw_turbo {
+ struct intel_rps_bdw_cal up;
+ struct intel_rps_bdw_cal down;
+ struct timer_list flip_timer;
+ u32 timeout;
+ atomic_t flip_received;
+ struct work_struct work_max_freq;
+};
+
struct intel_gen6_power_mgmt {
/* work and pm_iir are protected by dev_priv->irq_lock */
struct work_struct work;
@@ -948,6 +965,9 @@ struct intel_gen6_power_mgmt {
bool enabled;
struct delayed_work delayed_resume_work;
+ bool is_bdw_sw_turbo; /* Switch of BDW software turbo */
+ struct intel_rps_bdw_turbo sw_turbo; /* Calculate RP interrupt timing */
+
/* manual wa residency calculations */
struct intel_rps_ei up_ei, down_ei;
@@ -2703,6 +2723,8 @@ extern void intel_disable_fbc(struct drm_device *dev);
extern bool ironlake_set_drps(struct drm_device *dev, u8 val);
extern void intel_init_pch_refclk(struct drm_device *dev);
extern void gen6_set_rps(struct drm_device *dev, u8 val);
+extern void bdw_software_turbo(struct drm_device *dev);
+extern void gen8_flip_interrupt(struct drm_device *dev);
extern void valleyview_set_rps(struct drm_device *dev, u8 val);
extern void intel_set_memory_cxsr(struct drm_i915_private *dev_priv,
bool enable);
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 6ef9d6f..367f8e1 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1961,6 +1961,27 @@ static void i9xx_pipe_crc_irq_handler(struct drm_device
*dev, enum pipe pipe)
res1, res2);
}
+void gen8_flip_interrupt(struct drm_device *dev)
+{
+ struct drm_i915_private *dev_priv = dev->dev_private;
+
+ if (!dev_priv->rps.is_bdw_sw_turbo)
+ return;
+
+ if(atomic_read(&dev_priv->rps.sw_turbo.flip_received)) {
+ mod_timer(&dev_priv->rps.sw_turbo.flip_timer,
+
usecs_to_jiffies(dev_priv->rps.sw_turbo.timeout) + jiffies);
+ }
+ else {
+ dev_priv->rps.sw_turbo.flip_timer.expires =
+
usecs_to_jiffies(dev_priv->rps.sw_turbo.timeout) + jiffies;
+ add_timer(&dev_priv->rps.sw_turbo.flip_timer);
+ atomic_set(&dev_priv->rps.sw_turbo.flip_received, true);
+ }
+
+ bdw_software_turbo(dev);
+}
+
/* The RPS events need forcewake, so we add them to a work queue and mask
their
*
Re: [Intel-gfx] [PATCH v3] drm/i915/bdw: BDW Software Turbo
On Mon, Aug 11, 2014 at 11:08:38AM -0700, Daisy Sun wrote:
> BDW supports GT C0 residency reporting in constant time unit. Driver
> calculates GT utilization based on C0 residency and adjusts RP
> frequency up/down accordingly. For offscreen workload specificly,
> set frequency to RP0.
>
> Offscreen task is not restricted by frame rate, it can be
> executed as soon as possible. Transcoding and serilized workload
> between CPU and GPU both need high GT performance, RP0 is a good
> option in this case. RC6 will kick in to compensate power
> consumption when GT is not active.
>
> v2: Rebase on recent drm-intel-nightly
> v3: Add flip timerout monitor, when no flip is deteced within
> 100ms, set frequency to RP0.
Ok, let's make this really clear:
If you wire this into the flip handling in any way, I will not merge your
patch. The timer should be fully independant and tie into the gpu
busy/idle handling we already have.
Thanks, Daniel
>
> Signed-off-by: Daisy Sun
> [torourke: rebased on latest and resolved conflict]
> Signed-off-by: Tom O'Rourke
> ---
> drivers/gpu/drm/i915/i915_drv.h | 22
> drivers/gpu/drm/i915/i915_irq.c | 21
> drivers/gpu/drm/i915/i915_reg.h | 4 +
> drivers/gpu/drm/i915/intel_display.c | 3 +
> drivers/gpu/drm/i915/intel_pm.c | 230
> +--
> 5 files changed, 241 insertions(+), 39 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index ef38c3b..f1c4c5b 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -915,6 +915,23 @@ struct intel_rps_ei {
> u32 media_c0;
> };
>
> +struct intel_rps_bdw_cal {
> + u32 it_threshold_pct; /* interrupt, in percentage */
> + u32 eval_interval; /* evaluation interval, in us */
> + u32 last_ts;
> + u32 last_c0;
> + bool is_up;
> +};
> +
> +struct intel_rps_bdw_turbo {
> + struct intel_rps_bdw_cal up;
> + struct intel_rps_bdw_cal down;
> + struct timer_list flip_timer;
> + u32 timeout;
> + atomic_t flip_received;
> + struct work_struct work_max_freq;
> +};
> +
> struct intel_gen6_power_mgmt {
> /* work and pm_iir are protected by dev_priv->irq_lock */
> struct work_struct work;
> @@ -948,6 +965,9 @@ struct intel_gen6_power_mgmt {
> bool enabled;
> struct delayed_work delayed_resume_work;
>
> + bool is_bdw_sw_turbo; /* Switch of BDW software turbo */
> + struct intel_rps_bdw_turbo sw_turbo; /* Calculate RP interrupt timing */
> +
> /* manual wa residency calculations */
> struct intel_rps_ei up_ei, down_ei;
>
> @@ -2703,6 +2723,8 @@ extern void intel_disable_fbc(struct drm_device *dev);
> extern bool ironlake_set_drps(struct drm_device *dev, u8 val);
> extern void intel_init_pch_refclk(struct drm_device *dev);
> extern void gen6_set_rps(struct drm_device *dev, u8 val);
> +extern void bdw_software_turbo(struct drm_device *dev);
> +extern void gen8_flip_interrupt(struct drm_device *dev);
> extern void valleyview_set_rps(struct drm_device *dev, u8 val);
> extern void intel_set_memory_cxsr(struct drm_i915_private *dev_priv,
> bool enable);
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index 6ef9d6f..367f8e1 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -1961,6 +1961,27 @@ static void i9xx_pipe_crc_irq_handler(struct
> drm_device *dev, enum pipe pipe)
>res1, res2);
> }
>
> +void gen8_flip_interrupt(struct drm_device *dev)
> +{
> + struct drm_i915_private *dev_priv = dev->dev_private;
> +
> + if (!dev_priv->rps.is_bdw_sw_turbo)
> + return;
> +
> + if(atomic_read(&dev_priv->rps.sw_turbo.flip_received)) {
> + mod_timer(&dev_priv->rps.sw_turbo.flip_timer,
> +
> usecs_to_jiffies(dev_priv->rps.sw_turbo.timeout) + jiffies);
> + }
> + else {
> + dev_priv->rps.sw_turbo.flip_timer.expires =
> +
> usecs_to_jiffies(dev_priv->rps.sw_turbo.timeout) + jiffies;
> + add_timer(&dev_priv->rps.sw_turbo.flip_timer);
> + atomic_set(&dev_priv->rps.sw_turbo.flip_received, true);
> + }
> +
> + bdw_software_turbo(dev);
> +}
> +
> /* The RPS events need forcewake, so we add them to a work queue and mask
> their
> * IMR bits until the work is done. Other interrupts can be processed without
> * the work queue. */
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index fe5c276..088e0e1 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -5453,6 +5453,10 @@ enum punit_power_well {
> #define GEN8_UCGCTL6 0x9430
> #define GEN8_SDEUNIT_CLOCK_GATE_DISABLE(1<<14)
>
> +#define TIMESTAMP_CTR0x44070
> +#define FREQ_
Re: [Intel-gfx] [PATCH 29/43] drm/i915/bdw: Write the tail pointer, LRC style
On Thu, Jul 24, 2014 at 05:04:37PM +0100, Thomas Daniel wrote:
> From: Oscar Mateo
>
> Each logical ring context has the tail pointer in the context object,
> so update it before submission.
>
> v2: New namespace.
>
> Signed-off-by: Oscar Mateo
> ---
> drivers/gpu/drm/i915/intel_lrc.c | 19 +++
> 1 file changed, 19 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_lrc.c
> b/drivers/gpu/drm/i915/intel_lrc.c
> index 535ef98..5b6f416 100644
> --- a/drivers/gpu/drm/i915/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/intel_lrc.c
> @@ -176,6 +176,21 @@ static void execlists_elsp_write(struct intel_engine_cs
> *ring,
> gen6_gt_force_wake_put(dev_priv, FORCEWAKE_ALL);
> }
>
> +static int execlists_ctx_write_tail(struct drm_i915_gem_object *ctx_obj, u32
> tail)
> +{
> + struct page *page;
> + uint32_t *reg_state;
> +
> + page = i915_gem_object_get_page(ctx_obj, 1);
> + reg_state = kmap_atomic(page);
> +
> + reg_state[CTX_RING_TAIL+1] = tail;
> +
> + kunmap_atomic(reg_state);
> +
> + return 0;
> +}
> +
> static int execlists_submit_context(struct intel_engine_cs *ring,
> struct intel_context *to0, u32 tail0,
> struct intel_context *to1, u32 tail1)
> @@ -187,10 +202,14 @@ static int execlists_submit_context(struct
> intel_engine_cs *ring,
> BUG_ON(!ctx_obj0);
> BUG_ON(!i915_gem_obj_is_pinned(ctx_obj0));
>
> + execlists_ctx_write_tail(ctx_obj0, tail0);
> +
> if (to1) {
> ctx_obj1 = to1->engine[ring->id].state;
> BUG_ON(!ctx_obj1);
> BUG_ON(!i915_gem_obj_is_pinned(ctx_obj1));
> +
> + execlists_ctx_write_tail(ctx_obj1, tail1);
Ok, now I'm totally surprised - here's the tail write and elsp submit like
excepted. So why do we need the dance in the previous patch?
I'll look at this again tomorrow and will stop merging for today.
-Daniel
> }
>
> execlists_elsp_write(ring, ctx_obj0, ctx_obj1);
> --
> 1.7.9.5
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 28/43] drm/i915/bdw: Implement context switching (somewhat)
On Thu, Jul 24, 2014 at 05:04:36PM +0100, Thomas Daniel wrote:
> From: Ben Widawsky
>
> A context switch occurs by submitting a context descriptor to the
> ExecList Submission Port. Given that we can now initialize a context,
> it's possible to begin implementing the context switch by creating the
> descriptor and submitting it to ELSP (actually two, since the ELSP
> has two ports).
>
> The context object must be mapped in the GGTT, which means it must exist
> in the 0-4GB graphics VA range.
>
> Signed-off-by: Ben Widawsky
>
> v2: This code has changed quite a lot in various rebases. Of particular
> importance is that now we use the globally unique Submission ID to send
> to the hardware. Also, context pages are now pinned unconditionally to
> GGTT, so there is no need to bind them.
>
> v3: Use LRCA[31:12] as hwCtxId[19:0]. This guarantees that the HW context
> ID we submit to the ELSP is globally unique and != 0 (Bspec requirements
> of the software use-only bits of the Context ID in the Context Descriptor
> Format) without the hassle of the previous submission Id construction.
> Also, re-add the ELSP porting read (it was dropped somewhere during the
> rebases).
>
> v4:
> - Squash with "drm/i915/bdw: Add forcewake lock around ELSP writes" (BSPEC
> says: "SW must set Force Wakeup bit to prevent GT from entering C6 while
> ELSP writes are in progress") as noted by Thomas Daniel
> (thomas.dan...@intel.com).
> - Rename functions and use an execlists/intel_execlists_ namespace.
> - The BUG_ON only checked that the LRCA was <32 bits, but it didn't make
> sure that it was properly aligned. Spotted by Alistair Mcaulay
> .
>
> v5:
> - Improved source code comments as suggested by Chris Wilson.
> - No need to abstract submit_ctx away, as pointed by Brad Volkin.
>
> Signed-off-by: Oscar Mateo
> ---
> drivers/gpu/drm/i915/intel_lrc.c | 116
> +-
> drivers/gpu/drm/i915/intel_lrc.h |1 +
> 2 files changed, 115 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_lrc.c
> b/drivers/gpu/drm/i915/intel_lrc.c
> index 4549eec..535ef98 100644
> --- a/drivers/gpu/drm/i915/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/intel_lrc.c
> @@ -47,6 +47,7 @@
> #define GEN8_LR_CONTEXT_ALIGN 4096
>
> #define RING_ELSP(ring) ((ring)->mmio_base+0x230)
> +#define RING_EXECLIST_STATUS(ring) ((ring)->mmio_base+0x234)
> #define RING_CONTEXT_CONTROL(ring) ((ring)->mmio_base+0x244)
>
> #define CTX_LRI_HEADER_0 0x01
> @@ -78,6 +79,26 @@
> #define CTX_R_PWR_CLK_STATE 0x42
> #define CTX_GPGPU_CSR_BASE_ADDRESS 0x44
>
> +#define GEN8_CTX_VALID (1<<0)
> +#define GEN8_CTX_FORCE_PD_RESTORE (1<<1)
> +#define GEN8_CTX_FORCE_RESTORE (1<<2)
> +#define GEN8_CTX_L3LLC_COHERENT (1<<5)
> +#define GEN8_CTX_PRIVILEGE (1<<8)
> +enum {
> + ADVANCED_CONTEXT=0,
> + LEGACY_CONTEXT,
> + ADVANCED_AD_CONTEXT,
> + LEGACY_64B_CONTEXT
> +};
> +#define GEN8_CTX_MODE_SHIFT 3
> +enum {
> + FAULT_AND_HANG=0,
> + FAULT_AND_HALT, /* Debug only */
> + FAULT_AND_STREAM,
> + FAULT_AND_CONTINUE /* Unsupported */
> +};
> +#define GEN8_CTX_ID_SHIFT 32
> +
> int intel_sanitize_enable_execlists(struct drm_device *dev, int
> enable_execlists)
> {
> if (enable_execlists == 0)
> @@ -90,6 +111,93 @@ int intel_sanitize_enable_execlists(struct drm_device
> *dev, int enable_execlists
> return 0;
> }
>
> +u32 intel_execlists_ctx_id(struct drm_i915_gem_object *ctx_obj)
> +{
> + u32 lrca = i915_gem_obj_ggtt_offset(ctx_obj);
> +
> + /* LRCA is required to be 4K aligned so the more significant 20 bits
> + * are globally unique */
> + return lrca >> 12;
> +}
> +
> +static uint64_t execlists_ctx_descriptor(struct drm_i915_gem_object *ctx_obj)
> +{
> + uint64_t desc;
> + uint64_t lrca = i915_gem_obj_ggtt_offset(ctx_obj);
> + BUG_ON(lrca & 0x0FFFULL);
> +
> + desc = GEN8_CTX_VALID;
> + desc |= LEGACY_CONTEXT << GEN8_CTX_MODE_SHIFT;
> + desc |= GEN8_CTX_L3LLC_COHERENT;
> + desc |= GEN8_CTX_PRIVILEGE;
> + desc |= lrca;
> + desc |= (u64)intel_execlists_ctx_id(ctx_obj) << GEN8_CTX_ID_SHIFT;
> +
> + /* TODO: WaDisableLiteRestore when we start using semaphore
> + * signalling between Command Streamers */
> + /* desc |= GEN8_CTX_FORCE_RESTORE; */
> +
> + return desc;
> +}
> +
> +static void execlists_elsp_write(struct intel_engine_cs *ring,
> + struct drm_i915_gem_object *ctx_obj0,
> + struct drm_i915_gem_object *ctx_obj1)
> +{
> + struct drm_i915_private *dev_priv = ring->dev->dev_private;
> + uint64_t temp = 0;
> + uint32_t desc[4];
> +
> + /* XXX: You must always write both descriptors in the order below. */
> + if (ctx_obj1)
> + temp = execlists_ctx_descriptor(ctx_obj1);
> + else
> + temp = 0;
> + desc[1] = (u32)(temp >> 32);
> +
Re: [Intel-gfx] [PATCH 27/43] drm/i915/bdw: Render state init for Execlists
On Thu, Jul 24, 2014 at 05:04:35PM +0100, Thomas Daniel wrote:
> From: Oscar Mateo
>
> The batchbuffer that sets the render context state is submitted
> in a different way, and from different places.
>
> We needed to make both the render state preparation and free functions
> outside accesible, and namespace accordingly. This mess is so that all
> LR, LRC and Execlists functionality can go together in intel_lrc.c: we
> can fix all of this later on, once the interfaces are clear.
>
> v2: Create a separate ctx->rcs_initialized for the Execlists case, as
> suggested by Chris Wilson.
>
> Signed-off-by: Oscar Mateo
> ---
> drivers/gpu/drm/i915/i915_drv.h |4 +--
> drivers/gpu/drm/i915/i915_gem_context.c | 17 +-
> drivers/gpu/drm/i915/i915_gem_render_state.c | 40 ++
> drivers/gpu/drm/i915/i915_gem_render_state.h | 47
> ++
> drivers/gpu/drm/i915/intel_lrc.c | 46 +
> drivers/gpu/drm/i915/intel_lrc.h |2 ++
> drivers/gpu/drm/i915/intel_renderstate.h |8 +
> 7 files changed, 139 insertions(+), 25 deletions(-)
> create mode 100644 drivers/gpu/drm/i915/i915_gem_render_state.h
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 4303e2c..b7cf0ec 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -37,6 +37,7 @@
> #include "intel_ringbuffer.h"
> #include "intel_lrc.h"
> #include "i915_gem_gtt.h"
> +#include "i915_gem_render_state.h"
> #include
> #include
> #include
> @@ -623,6 +624,7 @@ struct intel_context {
> } legacy_hw_ctx;
>
> /* Execlists */
> + bool rcs_initialized;
> struct {
> struct drm_i915_gem_object *state;
> struct intel_ringbuffer *ringbuf;
> @@ -2553,8 +2555,6 @@ int i915_gem_context_create_ioctl(struct drm_device
> *dev, void *data,
> int i915_gem_context_destroy_ioctl(struct drm_device *dev, void *data,
> struct drm_file *file);
>
> -/* i915_gem_render_state.c */
> -int i915_gem_render_state_init(struct intel_engine_cs *ring);
> /* i915_gem_evict.c */
> int __must_check i915_gem_evict_something(struct drm_device *dev,
> struct i915_address_space *vm,
> diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
> b/drivers/gpu/drm/i915/i915_gem_context.c
> index 9085ff1..0dc6992 100644
> --- a/drivers/gpu/drm/i915/i915_gem_context.c
> +++ b/drivers/gpu/drm/i915/i915_gem_context.c
> @@ -513,8 +513,23 @@ int i915_gem_context_enable(struct drm_i915_private
> *dev_priv)
> ppgtt->enable(ppgtt);
> }
>
> - if (i915.enable_execlists)
> + if (i915.enable_execlists) {
> + struct intel_context *dctx;
> +
> + ring = &dev_priv->ring[RCS];
> + dctx = ring->default_context;
> +
> + if (!dctx->rcs_initialized) {
> + ret = intel_lr_context_render_state_init(ring, dctx);
> + if (ret) {
> + DRM_ERROR("Init render state failed: %d\n",
> ret);
> + return ret;
> + }
> + dctx->rcs_initialized = true;
> + }
> +
> return 0;
> + }
This looks very much like the wrong place. We should init the render state
when we create the context, or when we switch to it for the first time.
The later is what the legacy contexts currently do in do_switch.
But ctx_enable should do the switch to the default context and that's
about it. If there's some depency then I guess we should stall the
creation of the default context a bit, maybe.
In any case someone needs to explain this better and if there's not other
wey this at least needs a bit comment. So I'll punt for now.
-Daniel
>
> /* FIXME: We should make this work, even in reset */
> if (i915_reset_in_progress(&dev_priv->gpu_error))
> diff --git a/drivers/gpu/drm/i915/i915_gem_render_state.c
> b/drivers/gpu/drm/i915/i915_gem_render_state.c
> index e60be3f..a9a62d7 100644
> --- a/drivers/gpu/drm/i915/i915_gem_render_state.c
> +++ b/drivers/gpu/drm/i915/i915_gem_render_state.c
> @@ -28,13 +28,6 @@
> #include "i915_drv.h"
> #include "intel_renderstate.h"
>
> -struct render_state {
> - const struct intel_renderstate_rodata *rodata;
> - struct drm_i915_gem_object *obj;
> - u64 ggtt_offset;
> - int gen;
> -};
> -
> static const struct intel_renderstate_rodata *
> render_state_get_rodata(struct drm_device *dev, const int gen)
> {
> @@ -127,30 +120,47 @@ static int render_state_setup(struct render_state *so)
> return 0;
> }
>
> -static void render_state_fini(struct render_state *so)
> +void i915_gem_render_state_fini(struct render_state *so)
> {
> i915_gem_object_ggtt_unpin(so->obj);
> drm_gem_object_unreference(&so->obj->base);
> }
Re: [Intel-gfx] [PATCH 24/43] drm/i915/bdw: GEN-specific logical ring emit batchbuffer start
On Mon, Aug 11, 2014 at 11:09:39PM +0200, Daniel Vetter wrote:
> On Thu, Jul 24, 2014 at 05:04:32PM +0100, Thomas Daniel wrote:
> > From: Oscar Mateo
> >
> > Dispatch_execbuffer's evil twin.
> >
> > Signed-off-by: Oscar Mateo
> > ---
> > drivers/gpu/drm/i915/intel_lrc.c| 28
> > drivers/gpu/drm/i915/intel_ringbuffer.h |2 ++
> > 2 files changed, 30 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_lrc.c
> > b/drivers/gpu/drm/i915/intel_lrc.c
> > index a6dcb3a..55ee8dd 100644
> > --- a/drivers/gpu/drm/i915/intel_lrc.c
> > +++ b/drivers/gpu/drm/i915/intel_lrc.c
> > @@ -384,6 +384,29 @@ static int gen8_init_render_ring(struct
> > intel_engine_cs *ring)
> > return ret;
> > }
> >
> > +static int gen8_emit_bb_start(struct intel_ringbuffer *ringbuf,
> > + u64 offset, unsigned flags)
> > +{
> > + struct intel_engine_cs *ring = ringbuf->ring;
> > + struct drm_i915_private *dev_priv = ring->dev->dev_private;
> > + bool ppgtt = dev_priv->mm.aliasing_ppgtt != NULL &&
>
> The aliasing ppgtt check here is fairly decent bullocks, especially since
> full ppgtt is a requirement for execlists. I've ditched it since a series
> from myself will otherwise break this patch.
> -Daniel
>
> > + !(flags & I915_DISPATCH_SECURE);
> > + int ret;
> > +
> > + ret = intel_logical_ring_begin(ringbuf, 4);
> > + if (ret)
> > + return ret;
> > +
> > + /* FIXME(BDW): Address space and security selectors. */
> > + intel_logical_ring_emit(ringbuf, MI_BATCH_BUFFER_START_GEN8 |
> > (ppgtt<<8));
Also please follow up with a patch to replace the magic 8 here with a
proper define. Usual approach is to build this up with an u32 cmd_flags or
so. Patch should obviously also rectify the legacy ring stuff.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 24/43] drm/i915/bdw: GEN-specific logical ring emit batchbuffer start
On Thu, Jul 24, 2014 at 05:04:32PM +0100, Thomas Daniel wrote:
> From: Oscar Mateo
>
> Dispatch_execbuffer's evil twin.
>
> Signed-off-by: Oscar Mateo
> ---
> drivers/gpu/drm/i915/intel_lrc.c| 28
> drivers/gpu/drm/i915/intel_ringbuffer.h |2 ++
> 2 files changed, 30 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_lrc.c
> b/drivers/gpu/drm/i915/intel_lrc.c
> index a6dcb3a..55ee8dd 100644
> --- a/drivers/gpu/drm/i915/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/intel_lrc.c
> @@ -384,6 +384,29 @@ static int gen8_init_render_ring(struct intel_engine_cs
> *ring)
> return ret;
> }
>
> +static int gen8_emit_bb_start(struct intel_ringbuffer *ringbuf,
> + u64 offset, unsigned flags)
> +{
> + struct intel_engine_cs *ring = ringbuf->ring;
> + struct drm_i915_private *dev_priv = ring->dev->dev_private;
> + bool ppgtt = dev_priv->mm.aliasing_ppgtt != NULL &&
The aliasing ppgtt check here is fairly decent bullocks, especially since
full ppgtt is a requirement for execlists. I've ditched it since a series
from myself will otherwise break this patch.
-Daniel
> + !(flags & I915_DISPATCH_SECURE);
> + int ret;
> +
> + ret = intel_logical_ring_begin(ringbuf, 4);
> + if (ret)
> + return ret;
> +
> + /* FIXME(BDW): Address space and security selectors. */
> + intel_logical_ring_emit(ringbuf, MI_BATCH_BUFFER_START_GEN8 |
> (ppgtt<<8));
> + intel_logical_ring_emit(ringbuf, lower_32_bits(offset));
> + intel_logical_ring_emit(ringbuf, upper_32_bits(offset));
> + intel_logical_ring_emit(ringbuf, MI_NOOP);
> + intel_logical_ring_advance(ringbuf);
> +
> + return 0;
> +}
> +
> static bool gen8_logical_ring_get_irq(struct intel_engine_cs *ring)
> {
> struct drm_device *dev = ring->dev;
> @@ -615,6 +638,7 @@ static int logical_render_ring_init(struct drm_device
> *dev)
> ring->emit_flush = gen8_emit_flush_render;
> ring->irq_get = gen8_logical_ring_get_irq;
> ring->irq_put = gen8_logical_ring_put_irq;
> + ring->emit_bb_start = gen8_emit_bb_start;
>
> return logical_ring_init(dev, ring);
> }
> @@ -639,6 +663,7 @@ static int logical_bsd_ring_init(struct drm_device *dev)
> ring->emit_flush = gen8_emit_flush;
> ring->irq_get = gen8_logical_ring_get_irq;
> ring->irq_put = gen8_logical_ring_put_irq;
> + ring->emit_bb_start = gen8_emit_bb_start;
>
> return logical_ring_init(dev, ring);
> }
> @@ -663,6 +688,7 @@ static int logical_bsd2_ring_init(struct drm_device *dev)
> ring->emit_flush = gen8_emit_flush;
> ring->irq_get = gen8_logical_ring_get_irq;
> ring->irq_put = gen8_logical_ring_put_irq;
> + ring->emit_bb_start = gen8_emit_bb_start;
>
> return logical_ring_init(dev, ring);
> }
> @@ -687,6 +713,7 @@ static int logical_blt_ring_init(struct drm_device *dev)
> ring->emit_flush = gen8_emit_flush;
> ring->irq_get = gen8_logical_ring_get_irq;
> ring->irq_put = gen8_logical_ring_put_irq;
> + ring->emit_bb_start = gen8_emit_bb_start;
>
> return logical_ring_init(dev, ring);
> }
> @@ -711,6 +738,7 @@ static int logical_vebox_ring_init(struct drm_device *dev)
> ring->emit_flush = gen8_emit_flush;
> ring->irq_get = gen8_logical_ring_get_irq;
> ring->irq_put = gen8_logical_ring_put_irq;
> + ring->emit_bb_start = gen8_emit_bb_start;
>
> return logical_ring_init(dev, ring);
> }
> diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h
> b/drivers/gpu/drm/i915/intel_ringbuffer.h
> index 09102b2..c885d5c 100644
> --- a/drivers/gpu/drm/i915/intel_ringbuffer.h
> +++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
> @@ -228,6 +228,8 @@ struct intel_engine_cs {
> int (*emit_flush)(struct intel_ringbuffer *ringbuf,
> u32 invalidate_domains,
> u32 flush_domains);
> + int (*emit_bb_start)(struct intel_ringbuffer *ringbuf,
> + u64 offset, unsigned flags);
>
> /**
>* List of objects currently involved in rendering from the
> --
> 1.7.9.5
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 23/43] drm/i915/bdw: Interrupts with logical rings
On Thu, Jul 24, 2014 at 05:04:31PM +0100, Thomas Daniel wrote:
> From: Oscar Mateo
>
> We need to attend context switch interrupts from all rings. Also, fixed
> writing
> IMR/IER and added HWSTAM at ring init time.
>
> Notice that, if added to irq_enable_mask, the context switch interrupts would
> be incorrectly masked out when the user interrupts are due to no users waiting
> on a sequence number. Therefore, this commit adds a bitmask of interrupts to
> be kept unmasked at all times.
>
> v2: Disable HWSTAM, as suggested by Damien (nobody listens to these
> interrupts,
> anyway).
>
> v3: Add new get/put_irq functions.
>
> Signed-off-by: Thomas Daniel (v1)
> Signed-off-by: Oscar Mateo (v2 & v3)
> ---
> drivers/gpu/drm/i915/i915_irq.c | 19 --
> drivers/gpu/drm/i915/i915_reg.h |3 ++
> drivers/gpu/drm/i915/intel_lrc.c| 58
> +++
> drivers/gpu/drm/i915/intel_ringbuffer.h |1 +
> 4 files changed, 78 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index a38b5c3..f77a4ca 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -1643,6 +1643,8 @@ static irqreturn_t gen8_gt_irq_handler(struct
> drm_device *dev,
> notify_ring(dev, &dev_priv->ring[RCS]);
> if (bcs & GT_RENDER_USER_INTERRUPT)
> notify_ring(dev, &dev_priv->ring[BCS]);
> + if ((rcs | bcs) & GEN8_GT_CONTEXT_SWITCH_INTERRUPT)
> + DRM_DEBUG_DRIVER("TODO: Context switch\n");
> } else
> DRM_ERROR("The master control interrupt lied (GT0)!\n");
> }
> @@ -1655,9 +1657,13 @@ static irqreturn_t gen8_gt_irq_handler(struct
> drm_device *dev,
> vcs = tmp >> GEN8_VCS1_IRQ_SHIFT;
> if (vcs & GT_RENDER_USER_INTERRUPT)
> notify_ring(dev, &dev_priv->ring[VCS]);
> + if (vcs & GEN8_GT_CONTEXT_SWITCH_INTERRUPT)
> + DRM_DEBUG_DRIVER("TODO: Context switch\n");
> vcs = tmp >> GEN8_VCS2_IRQ_SHIFT;
> if (vcs & GT_RENDER_USER_INTERRUPT)
> notify_ring(dev, &dev_priv->ring[VCS2]);
> + if (vcs & GEN8_GT_CONTEXT_SWITCH_INTERRUPT)
> + DRM_DEBUG_DRIVER("TODO: Context switch\n");
> } else
> DRM_ERROR("The master control interrupt lied (GT1)!\n");
> }
> @@ -1681,6 +1687,8 @@ static irqreturn_t gen8_gt_irq_handler(struct
> drm_device *dev,
> vcs = tmp >> GEN8_VECS_IRQ_SHIFT;
> if (vcs & GT_RENDER_USER_INTERRUPT)
> notify_ring(dev, &dev_priv->ring[VECS]);
> + if (vcs & GEN8_GT_CONTEXT_SWITCH_INTERRUPT)
> + DRM_DEBUG_DRIVER("TODO: Context switch\n");
> } else
> DRM_ERROR("The master control interrupt lied (GT3)!\n");
> }
> @@ -3768,12 +3776,17 @@ static void gen8_gt_irq_postinstall(struct
> drm_i915_private *dev_priv)
> /* These are interrupts we'll toggle with the ring mask register */
> uint32_t gt_interrupts[] = {
> GT_RENDER_USER_INTERRUPT << GEN8_RCS_IRQ_SHIFT |
> + GEN8_GT_CONTEXT_SWITCH_INTERRUPT << GEN8_RCS_IRQ_SHIFT |
> GT_RENDER_L3_PARITY_ERROR_INTERRUPT |
> - GT_RENDER_USER_INTERRUPT << GEN8_BCS_IRQ_SHIFT,
> + GT_RENDER_USER_INTERRUPT << GEN8_BCS_IRQ_SHIFT |
> + GEN8_GT_CONTEXT_SWITCH_INTERRUPT << GEN8_BCS_IRQ_SHIFT,
> GT_RENDER_USER_INTERRUPT << GEN8_VCS1_IRQ_SHIFT |
> - GT_RENDER_USER_INTERRUPT << GEN8_VCS2_IRQ_SHIFT,
> + GEN8_GT_CONTEXT_SWITCH_INTERRUPT << GEN8_VCS1_IRQ_SHIFT
> |
> + GT_RENDER_USER_INTERRUPT << GEN8_VCS2_IRQ_SHIFT |
> + GEN8_GT_CONTEXT_SWITCH_INTERRUPT << GEN8_VCS2_IRQ_SHIFT,
> 0,
> - GT_RENDER_USER_INTERRUPT << GEN8_VECS_IRQ_SHIFT
> + GT_RENDER_USER_INTERRUPT << GEN8_VECS_IRQ_SHIFT |
> + GEN8_GT_CONTEXT_SWITCH_INTERRUPT << GEN8_VECS_IRQ_SHIFT
> };
>
> for (i = 0; i < ARRAY_SIZE(gt_interrupts); i++)
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 70dddac..bfc0c01 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -1062,6 +1062,7 @@ enum punit_power_well {
> #define RING_ACTHD_UDW(base) ((base)+0x5c)
> #define RING_NOPID(base) ((base)+0x94)
> #define RING_IMR(base) ((base)+0xa8)
> +#define RING_HWSTAM(base)((base)+0x98)
> #define RING_TIMESTAMP(base) ((base)+0
Re: [Intel-gfx] [PATCH 23/43] drm/i915/bdw: Interrupts with logical rings
On Thu, Jul 24, 2014 at 05:04:31PM +0100, Thomas Daniel wrote:
> From: Oscar Mateo
>
> We need to attend context switch interrupts from all rings. Also, fixed
> writing
> IMR/IER and added HWSTAM at ring init time.
>
> Notice that, if added to irq_enable_mask, the context switch interrupts would
> be incorrectly masked out when the user interrupts are due to no users waiting
> on a sequence number. Therefore, this commit adds a bitmask of interrupts to
> be kept unmasked at all times.
>
> v2: Disable HWSTAM, as suggested by Damien (nobody listens to these
> interrupts,
> anyway).
>
> v3: Add new get/put_irq functions.
>
> Signed-off-by: Thomas Daniel (v1)
> Signed-off-by: Oscar Mateo (v2 & v3)
irq_keep_mask is a nifty idea, would be pretty to roll it out for legacy
rings too. But totally optional.
-Daniel
> ---
> drivers/gpu/drm/i915/i915_irq.c | 19 --
> drivers/gpu/drm/i915/i915_reg.h |3 ++
> drivers/gpu/drm/i915/intel_lrc.c| 58
> +++
> drivers/gpu/drm/i915/intel_ringbuffer.h |1 +
> 4 files changed, 78 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index a38b5c3..f77a4ca 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -1643,6 +1643,8 @@ static irqreturn_t gen8_gt_irq_handler(struct
> drm_device *dev,
> notify_ring(dev, &dev_priv->ring[RCS]);
> if (bcs & GT_RENDER_USER_INTERRUPT)
> notify_ring(dev, &dev_priv->ring[BCS]);
> + if ((rcs | bcs) & GEN8_GT_CONTEXT_SWITCH_INTERRUPT)
> + DRM_DEBUG_DRIVER("TODO: Context switch\n");
> } else
> DRM_ERROR("The master control interrupt lied (GT0)!\n");
> }
> @@ -1655,9 +1657,13 @@ static irqreturn_t gen8_gt_irq_handler(struct
> drm_device *dev,
> vcs = tmp >> GEN8_VCS1_IRQ_SHIFT;
> if (vcs & GT_RENDER_USER_INTERRUPT)
> notify_ring(dev, &dev_priv->ring[VCS]);
> + if (vcs & GEN8_GT_CONTEXT_SWITCH_INTERRUPT)
> + DRM_DEBUG_DRIVER("TODO: Context switch\n");
> vcs = tmp >> GEN8_VCS2_IRQ_SHIFT;
> if (vcs & GT_RENDER_USER_INTERRUPT)
> notify_ring(dev, &dev_priv->ring[VCS2]);
> + if (vcs & GEN8_GT_CONTEXT_SWITCH_INTERRUPT)
> + DRM_DEBUG_DRIVER("TODO: Context switch\n");
> } else
> DRM_ERROR("The master control interrupt lied (GT1)!\n");
> }
> @@ -1681,6 +1687,8 @@ static irqreturn_t gen8_gt_irq_handler(struct
> drm_device *dev,
> vcs = tmp >> GEN8_VECS_IRQ_SHIFT;
> if (vcs & GT_RENDER_USER_INTERRUPT)
> notify_ring(dev, &dev_priv->ring[VECS]);
> + if (vcs & GEN8_GT_CONTEXT_SWITCH_INTERRUPT)
> + DRM_DEBUG_DRIVER("TODO: Context switch\n");
> } else
> DRM_ERROR("The master control interrupt lied (GT3)!\n");
> }
> @@ -3768,12 +3776,17 @@ static void gen8_gt_irq_postinstall(struct
> drm_i915_private *dev_priv)
> /* These are interrupts we'll toggle with the ring mask register */
> uint32_t gt_interrupts[] = {
> GT_RENDER_USER_INTERRUPT << GEN8_RCS_IRQ_SHIFT |
> + GEN8_GT_CONTEXT_SWITCH_INTERRUPT << GEN8_RCS_IRQ_SHIFT |
> GT_RENDER_L3_PARITY_ERROR_INTERRUPT |
> - GT_RENDER_USER_INTERRUPT << GEN8_BCS_IRQ_SHIFT,
> + GT_RENDER_USER_INTERRUPT << GEN8_BCS_IRQ_SHIFT |
> + GEN8_GT_CONTEXT_SWITCH_INTERRUPT << GEN8_BCS_IRQ_SHIFT,
> GT_RENDER_USER_INTERRUPT << GEN8_VCS1_IRQ_SHIFT |
> - GT_RENDER_USER_INTERRUPT << GEN8_VCS2_IRQ_SHIFT,
> + GEN8_GT_CONTEXT_SWITCH_INTERRUPT << GEN8_VCS1_IRQ_SHIFT
> |
> + GT_RENDER_USER_INTERRUPT << GEN8_VCS2_IRQ_SHIFT |
> + GEN8_GT_CONTEXT_SWITCH_INTERRUPT << GEN8_VCS2_IRQ_SHIFT,
> 0,
> - GT_RENDER_USER_INTERRUPT << GEN8_VECS_IRQ_SHIFT
> + GT_RENDER_USER_INTERRUPT << GEN8_VECS_IRQ_SHIFT |
> + GEN8_GT_CONTEXT_SWITCH_INTERRUPT << GEN8_VECS_IRQ_SHIFT
> };
>
> for (i = 0; i < ARRAY_SIZE(gt_interrupts); i++)
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 70dddac..bfc0c01 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -1062,6 +1062,7 @@ enum punit_power_well {
> #define RING_ACTHD_UDW(base) ((base)+0x5c)
> #define RING_NOPID(base) ((base)+0x94)
> #define RING_IMR(base)
Re: [Intel-gfx] [PATCH 21/43] drm/i915/bdw: Emission of requests with logical rings
On Thu, Jul 24, 2014 at 05:04:29PM +0100, Thomas Daniel wrote:
> From: Oscar Mateo
>
> On a previous iteration of this patch, I created an Execlists
> version of __i915_add_request and asbtracted it away as a
> vfunc. Daniel Vetter wondered then why that was needed:
>
> "with the clean split in command submission I expect every
> function to know wether it'll submit to an lrc (everything in
> intel_lrc.c) or wether it'll submit to a legacy ring (existing
> code), so I don't see a need for an add_request vfunc."
>
> The honest, hairy truth is that this patch is the glue keeping
> the whole logical ring puzzle together:
Oops, I didn't spot this and it's indeed not terribly pretty.
>
> - i915_add_request is used by intel_ring_idle, which in turn is
> used by i915_gpu_idle, which in turn is used in several places
> inside the eviction and gtt codes.
This should probably be folded in with the lrc specific version of
stop_rings and so should work out.
> - Also, it is used by i915_gem_check_olr, which is littered all
> over i915_gem.c
We now always preallocate the request struct, so olr is officially dead.
Well almost, except for non-execbuf stuff that we emit through the rings.
Which is nothing for lrc/execlist mode.
Also there's the icky-bitty problem with ringbuf->ctx which makes this
patch not apply any more. I think we need to revise or at least discuss a
bit.
> - ...
>
> If I were to duplicate all the code that directly or indirectly
> uses __i915_add_request, I'll end up creating a separate driver.
>
> To show the differences between the existing legacy version and
> the new Execlists one, this time I have special-cased
> __i915_add_request instead of adding an add_request vfunc. I
> hope this helps to untangle this Gordian knot.
>
> Signed-off-by: Oscar Mateo
> ---
> drivers/gpu/drm/i915/i915_gem.c | 72
> --
> drivers/gpu/drm/i915/intel_lrc.c | 30 +---
> drivers/gpu/drm/i915/intel_lrc.h |1 +
> 3 files changed, 80 insertions(+), 23 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 9560b40..1c83b9c 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -2327,10 +2327,21 @@ int __i915_add_request(struct intel_engine_cs *ring,
> {
> struct drm_i915_private *dev_priv = ring->dev->dev_private;
> struct drm_i915_gem_request *request;
> + struct intel_ringbuffer *ringbuf;
> u32 request_ring_position, request_start;
> int ret;
>
> - request_start = intel_ring_get_tail(ring->buffer);
> + request = ring->preallocated_lazy_request;
> + if (WARN_ON(request == NULL))
> + return -ENOMEM;
> +
> + if (i915.enable_execlists) {
> + struct intel_context *ctx = request->ctx;
> + ringbuf = ctx->engine[ring->id].ringbuf;
> + } else
> + ringbuf = ring->buffer;
> +
> + request_start = intel_ring_get_tail(ringbuf);
> /*
>* Emit any outstanding flushes - execbuf can fail to emit the flush
>* after having emitted the batchbuffer command. Hence we need to fix
> @@ -2338,24 +2349,32 @@ int __i915_add_request(struct intel_engine_cs *ring,
>* is that the flush _must_ happen before the next request, no matter
>* what.
>*/
> - ret = intel_ring_flush_all_caches(ring);
> - if (ret)
> - return ret;
> -
> - request = ring->preallocated_lazy_request;
> - if (WARN_ON(request == NULL))
> - return -ENOMEM;
> + if (i915.enable_execlists) {
> + ret = logical_ring_flush_all_caches(ringbuf);
> + if (ret)
> + return ret;
> + } else {
> + ret = intel_ring_flush_all_caches(ring);
> + if (ret)
> + return ret;
> + }
>
> /* Record the position of the start of the request so that
>* should we detect the updated seqno part-way through the
>* GPU processing the request, we never over-estimate the
>* position of the head.
>*/
> - request_ring_position = intel_ring_get_tail(ring->buffer);
> + request_ring_position = intel_ring_get_tail(ringbuf);
>
> - ret = ring->add_request(ring);
> - if (ret)
> - return ret;
> + if (i915.enable_execlists) {
> + ret = ring->emit_request(ringbuf);
> + if (ret)
> + return ret;
> + } else {
> + ret = ring->add_request(ring);
> + if (ret)
> + return ret;
> + }
>
> request->seqno = intel_ring_get_seqno(ring);
> request->ring = ring;
> @@ -2370,12 +2389,14 @@ int __i915_add_request(struct intel_engine_cs *ring,
>*/
> request->batch_obj = obj;
>
> - /* Hold a reference to the current context so that we can inspect
> - * it later in case a hangcheck error event fires.
> -
Re: [Intel-gfx] [PATCH 26/43] drm/i915/bdw: Always use MMIO flips with Execlists
On Thu, Jul 24, 2014 at 05:04:34PM +0100, Thomas Daniel wrote: > From: Oscar Mateo > > The normal flip function places things in the ring in the legacy > way, so we either fix that or force MMIO flips always as we do in > this patch. > > Signed-off-by: Oscar Mateo > --- > drivers/gpu/drm/i915/intel_display.c |2 ++ > drivers/gpu/drm/i915/intel_lrc.c |3 ++- > 2 files changed, 4 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/intel_display.c > b/drivers/gpu/drm/i915/intel_display.c > index 5ed6a1a..8129af4 100644 > --- a/drivers/gpu/drm/i915/intel_display.c > +++ b/drivers/gpu/drm/i915/intel_display.c > @@ -9482,6 +9482,8 @@ static bool use_mmio_flip(struct intel_engine_cs *ring, > return false; > else if (i915.use_mmio_flip > 0) > return true; > + else if (i915.enable_execlists) > + return true; > else > return ring != obj->ring; > } > diff --git a/drivers/gpu/drm/i915/intel_lrc.c > b/drivers/gpu/drm/i915/intel_lrc.c > index cd834b3..0a04c03 100644 > --- a/drivers/gpu/drm/i915/intel_lrc.c > +++ b/drivers/gpu/drm/i915/intel_lrc.c > @@ -83,7 +83,8 @@ int intel_sanitize_enable_execlists(struct drm_device *dev, > int enable_execlists > if (enable_execlists == 0) > return 0; > > - if (HAS_LOGICAL_RING_CONTEXTS(dev) && USES_PPGTT(dev)) > + if (HAS_LOGICAL_RING_CONTEXTS(dev) && USES_PPGTT(dev) && > + i915.use_mmio_flip >= 0) Almost every patch gets the alignment wrong somewhere. Not terribly amused. -Daniel > return 1; > > return 0; > -- > 1.7.9.5 > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 18/43] drm/i915/bdw: New logical ring submission mechanism
On Thu, Jul 24, 2014 at 05:04:26PM +0100, Thomas Daniel wrote:
> From: Oscar Mateo
>
> Well, new-ish: if all this code looks familiar, that's because it's
> a clone of the existing submission mechanism (with some modifications
> here and there to adapt it to LRCs and Execlists).
>
> And why did we do this instead of reusing code, one might wonder?
> Well, there are some fears that the differences are big enough that
> they will end up breaking all platforms.
>
> Also, Execlists offer several advantages, like control over when the
> GPU is done with a given workload, that can help simplify the
> submission mechanism, no doubt. I am interested in getting Execlists
> to work first and foremost, but in the future this parallel submission
> mechanism will help us to fine tune the mechanism without affecting
> old gens.
>
> v2: Pass the ringbuffer only (whenever possible).
>
> Signed-off-by: Oscar Mateo
> ---
> drivers/gpu/drm/i915/intel_lrc.c| 193
> +++
> drivers/gpu/drm/i915/intel_lrc.h| 12 ++
> drivers/gpu/drm/i915/intel_ringbuffer.c | 20 ++--
> drivers/gpu/drm/i915/intel_ringbuffer.h |3 +
> 4 files changed, 218 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_lrc.c
> b/drivers/gpu/drm/i915/intel_lrc.c
> index f171fd5..bd37d51 100644
> --- a/drivers/gpu/drm/i915/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/intel_lrc.c
> @@ -106,6 +106,199 @@ void intel_logical_ring_stop(struct intel_engine_cs
> *ring)
> /* TODO */
> }
>
> +void intel_logical_ring_advance_and_submit(struct intel_ringbuffer *ringbuf)
> +{
> + intel_logical_ring_advance(ringbuf);
> +
> + if (intel_ring_stopped(ringbuf->ring))
> + return;
> +
> + /* TODO: how to submit a context to the ELSP is not here yet */
> +}
> +
> +static int logical_ring_alloc_seqno(struct intel_engine_cs *ring)
> +{
> + if (ring->outstanding_lazy_seqno)
> + return 0;
> +
> + if (ring->preallocated_lazy_request == NULL) {
> + struct drm_i915_gem_request *request;
> +
> + request = kmalloc(sizeof(*request), GFP_KERNEL);
> + if (request == NULL)
> + return -ENOMEM;
> +
> + ring->preallocated_lazy_request = request;
> + }
> +
> + return i915_gem_get_seqno(ring->dev, &ring->outstanding_lazy_seqno);
> +}
> +
> +static int logical_ring_wait_request(struct intel_ringbuffer *ringbuf, int
> bytes)
> +{
> + struct intel_engine_cs *ring = ringbuf->ring;
> + struct drm_i915_gem_request *request;
> + u32 seqno = 0;
> + int ret;
> +
> + if (ringbuf->last_retired_head != -1) {
> + ringbuf->head = ringbuf->last_retired_head;
> + ringbuf->last_retired_head = -1;
> +
> + ringbuf->space = intel_ring_space(ringbuf);
> + if (ringbuf->space >= bytes)
> + return 0;
> + }
> +
> + list_for_each_entry(request, &ring->request_list, list) {
> + if (__intel_ring_space(request->tail, ringbuf->tail,
> + ringbuf->size) >= bytes) {
> + seqno = request->seqno;
> + break;
> + }
> + }
> +
> + if (seqno == 0)
> + return -ENOSPC;
> +
> + ret = i915_wait_seqno(ring, seqno);
> + if (ret)
> + return ret;
> +
> + /* TODO: make sure we update the right ringbuffer's last_retired_head
> + * when retiring requests */
> + i915_gem_retire_requests_ring(ring);
> + ringbuf->head = ringbuf->last_retired_head;
> + ringbuf->last_retired_head = -1;
> +
> + ringbuf->space = intel_ring_space(ringbuf);
> + return 0;
> +}
> +
> +static int logical_ring_wait_for_space(struct intel_ringbuffer *ringbuf, int
> bytes)
> +{
> + struct intel_engine_cs *ring = ringbuf->ring;
> + struct drm_device *dev = ring->dev;
> + struct drm_i915_private *dev_priv = dev->dev_private;
> + unsigned long end;
> + int ret;
> +
> + ret = logical_ring_wait_request(ringbuf, bytes);
> + if (ret != -ENOSPC)
> + return ret;
> +
> + /* Force the context submission in case we have been skipping it */
> + intel_logical_ring_advance_and_submit(ringbuf);
> +
> + /* With GEM the hangcheck timer should kick us out of the loop,
> + * leaving it early runs the risk of corrupting GEM state (due
> + * to running on almost untested codepaths). But on resume
> + * timers don't work yet, so prevent a complete hang in that
> + * case by choosing an insanely large timeout. */
> + end = jiffies + 60 * HZ;
> +
> + do {
> + ringbuf->head = I915_READ_HEAD(ring);
> + ringbuf->space = intel_ring_space(ringbuf);
> + if (ringbuf->space >= bytes) {
> + ret = 0;
> + break;
> + }
> +
> + if (!drm_core_check_feature(dev, DRIVER_MODESET) &&
>
Re: [Intel-gfx] [PATCH 25/43] drm/i915/bdw: Workload submission mechanism for Execlists
On Thu, Jul 24, 2014 at 05:04:33PM +0100, Thomas Daniel wrote:
> From: Oscar Mateo
>
> This is what i915_gem_do_execbuffer calls when it wants to execute some
> worload in an Execlists world.
>
> v2: Check arguments before doing stuff in intel_execlists_submission. Also,
> get rel_constants parsing right.
>
> Signed-off-by: Oscar Mateo
> ---
> drivers/gpu/drm/i915/i915_drv.h|6 ++
> drivers/gpu/drm/i915/i915_gem_execbuffer.c |4 +-
> drivers/gpu/drm/i915/intel_lrc.c | 130
> +++-
> 3 files changed, 137 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 1caed52..4303e2c 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -2239,6 +2239,12 @@ int i915_gem_set_domain_ioctl(struct drm_device *dev,
> void *data,
> struct drm_file *file_priv);
> int i915_gem_sw_finish_ioctl(struct drm_device *dev, void *data,
>struct drm_file *file_priv);
> +void i915_gem_execbuffer_move_to_active(struct list_head *vmas,
> + struct intel_engine_cs *ring);
> +void i915_gem_execbuffer_retire_commands(struct drm_device *dev,
> + struct drm_file *file,
> + struct intel_engine_cs *ring,
> + struct drm_i915_gem_object *obj);
> int i915_gem_ringbuffer_submission(struct drm_device *dev,
> struct drm_file *file,
> struct intel_engine_cs *ring,
> diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> index 8c63d79..cae7df8 100644
> --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> @@ -962,7 +962,7 @@ i915_gem_validate_context(struct drm_device *dev, struct
> drm_file *file,
> return ctx;
> }
>
> -static void
> +void
> i915_gem_execbuffer_move_to_active(struct list_head *vmas,
> struct intel_engine_cs *ring)
> {
> @@ -994,7 +994,7 @@ i915_gem_execbuffer_move_to_active(struct list_head *vmas,
> }
> }
>
> -static void
> +void
> i915_gem_execbuffer_retire_commands(struct drm_device *dev,
> struct drm_file *file,
> struct intel_engine_cs *ring,
> diff --git a/drivers/gpu/drm/i915/intel_lrc.c
> b/drivers/gpu/drm/i915/intel_lrc.c
> index 55ee8dd..cd834b3 100644
> --- a/drivers/gpu/drm/i915/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/intel_lrc.c
> @@ -89,6 +89,57 @@ int intel_sanitize_enable_execlists(struct drm_device
> *dev, int enable_execlists
> return 0;
> }
>
> +static int logical_ring_invalidate_all_caches(struct intel_ringbuffer
> *ringbuf)
> +{
> + struct intel_engine_cs *ring = ringbuf->ring;
> + uint32_t flush_domains;
> + int ret;
> +
> + flush_domains = 0;
> + if (ring->gpu_caches_dirty)
> + flush_domains = I915_GEM_GPU_DOMAINS;
> +
> + ret = ring->emit_flush(ringbuf, I915_GEM_GPU_DOMAINS, flush_domains);
> + if (ret)
> + return ret;
> +
> + ring->gpu_caches_dirty = false;
> + return 0;
> +}
> +
> +static int execlists_move_to_gpu(struct intel_ringbuffer *ringbuf,
> + struct list_head *vmas)
> +{
> + struct intel_engine_cs *ring = ringbuf->ring;
> + struct i915_vma *vma;
> + uint32_t flush_domains = 0;
> + bool flush_chipset = false;
> + int ret;
> +
> + list_for_each_entry(vma, vmas, exec_list) {
> + struct drm_i915_gem_object *obj = vma->obj;
> + ret = i915_gem_object_sync(obj, ring);
> + if (ret)
> + return ret;
> +
> + if (obj->base.write_domain & I915_GEM_DOMAIN_CPU)
> + flush_chipset |= i915_gem_clflush_object(obj, false);
> +
> + flush_domains |= obj->base.write_domain;
> + }
> +
> + if (flush_chipset)
> + i915_gem_chipset_flush(ring->dev);
chipset flush is gen5 and earlier only. I'll ditch it.
> +
> + if (flush_domains & I915_GEM_DOMAIN_GTT)
> + wmb();
> +
> + /* Unconditionally invalidate gpu caches and ensure that we do flush
> + * any residual writes from the previous batch.
> + */
> + return logical_ring_invalidate_all_caches(ringbuf);
> +}
> +
> int intel_execlists_submission(struct drm_device *dev, struct drm_file *file,
> struct intel_engine_cs *ring,
> struct intel_context *ctx,
> @@ -97,7 +148,84 @@ int intel_execlists_submission(struct drm_device *dev,
> struct drm_file *file,
> struct drm_i915_gem_object *batch_obj,
> u64 exec_start, u32 flags)
> {
> - /* TODO */
>
Re: [Intel-gfx] [PATCH] drm/i915: Wait for vblank after enabling the primary plane on BDW
2014-06-30 7:10 GMT-03:00 Jani Nikula :
> On Thu, 26 Jun 2014, Rodrigo Vivi wrote:
>> I'm sure this might affect Wayne, so, cc'ing him here.
>>
>> from my point of view this is right so:
>> Reviewed-by: Rodrigo Vivi
>
> Pushed to -fixes, thanks for the patch and review.
>
> BR,
> Jani.
>
>
>>
>>
>> On Tue, Jun 24, 2014 at 3:59 AM, wrote:
>>
>>> From: Ville Syrjälä
>>>
>>> BDW signals the flip done interrupt immediately after the DSPSURF write
>>> when the plane is disabled. This is true even if we've already armed
>>> DSPCNTR to enable the plane at the next vblank. This causes major
>>> problems for our page flip code which relies on the flip done interrupts
>>> happening at vblank time.
>>>
>>> So what happens is that we enable the plane, and immediately allow
>>> userspace to submit a page flip. If the plane is still in the process
>>> of being enabled when the page flip is issued, the flip done gets
>>> signalled immediately. Our DSPSURFLIVE check catches this to prevent
>>> premature flip completion, but it also means that we don't get a flip
>>> done interrupt when the plane actually gets enabled, and so the page
>>> flip is never completed.
>>>
>>> Work around this by re-introducing blocking vblank waits on BDW
>>> whenever we enable the primary plane.
>>>
>>> I removed some of the vblank waits here:
>>> commit 6304cd91e7f05f8802ea6f91287cac09741d9c46
>>> Author: Ville Syrjälä
>>> Date: Fri Apr 25 13:30:12 2014 +0300
>>>
>>> drm/i915: Drop the excessive vblank waits from modeset codepaths
>>>
>>> To avoid these blocking vblank waits we should start using the vblank
>>> interrupt instead of the flip done interrupt to complete page flips.
>>> But that's material for another patch.
>>>
>>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=79354
>>> Tested-by: Guo Jinxian
>>> Signed-off-by: Ville Syrjälä
>>> ---
>>> drivers/gpu/drm/i915/intel_display.c | 9 +
>>> drivers/gpu/drm/i915/intel_sprite.c | 8
>>> 2 files changed, 17 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/i915/intel_display.c
>>> b/drivers/gpu/drm/i915/intel_display.c
>>> index 9188fed..f92efc6 100644
>>> --- a/drivers/gpu/drm/i915/intel_display.c
>>> +++ b/drivers/gpu/drm/i915/intel_display.c
>>> @@ -2087,6 +2087,7 @@ void intel_flush_primary_plane(struct
>>> drm_i915_private *dev_priv,
>>> static void intel_enable_primary_hw_plane(struct drm_i915_private
>>> *dev_priv,
>>> enum plane plane, enum pipe pipe)
>>> {
>>> + struct drm_device *dev = dev_priv->dev;
>>> struct intel_crtc *intel_crtc =
>>> to_intel_crtc(dev_priv->pipe_to_crtc_mapping[pipe]);
>>> int reg;
>>> @@ -2106,6 +2107,14 @@ static void intel_enable_primary_hw_plane(struct
>>> drm_i915_private *dev_priv,
>>>
>>> I915_WRITE(reg, val | DISPLAY_PLANE_ENABLE);
>>> intel_flush_primary_plane(dev_priv, plane);
>>> +
>>> + /*
>>> +* BDW signals flip done immediately if the plane
>>> +* is disabled, even if the plane enable is already
>>> +* armed to occur at the next vblank :(
>>> +*/
>>> + if (IS_BROADWELL(dev))
>>> + intel_wait_for_vblank(dev, intel_crtc->pipe);
This chunk triggers "WARN(ret == 0)" from drm_wait_one_vblank when
using HDMI on BDW.
>>> }
>>>
>>> /**
>>> diff --git a/drivers/gpu/drm/i915/intel_sprite.c
>>> b/drivers/gpu/drm/i915/intel_sprite.c
>>> index 1b66ddc..9a17b4e 100644
>>> --- a/drivers/gpu/drm/i915/intel_sprite.c
>>> +++ b/drivers/gpu/drm/i915/intel_sprite.c
>>> @@ -691,6 +691,14 @@ intel_post_enable_primary(struct drm_crtc *crtc)
>>> struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
>>>
>>> /*
>>> +* BDW signals flip done immediately if the plane
>>> +* is disabled, even if the plane enable is already
>>> +* armed to occur at the next vblank :(
>>> +*/
>>> + if (IS_BROADWELL(dev))
>>> + intel_wait_for_vblank(dev, intel_crtc->pipe);
>>> +
>>> + /*
>>> * FIXME IPS should be fine as long as one plane is
>>> * enabled, but in practice it seems to have problems
>>> * when going from primary only to sprite only and vice
>>> --
>>> 1.8.5.5
>>>
>>> ___
>>> Intel-gfx mailing list
>>> Intel-gfx@lists.freedesktop.org
>>> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>>>
>>
>>
>>
>> --
>> Rodrigo Vivi
>> Blog: http://blog.vivi.eng.br
>> ___
>> Intel-gfx mailing list
>> Intel-gfx@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
> --
> Jani Nikula, Intel Open Source Technology Center
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Paulo Zanoni
___
Intel-gfx mailing lis
[Intel-gfx] [PATCH 4/4] drm/i915: don't try to retrain a DP link on an inactive CRTC
Atm we may retrain the DP link even if the CRTC is inactive through
HPD work->intel_dp_check_link_status(). This in turn can lock up the PHY
(at least on BYT), since the DP port is disabled.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=81948
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/intel_dp.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index d7f5d0a..49de9be 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -3551,6 +3551,9 @@ intel_dp_check_link_status(struct intel_dp *intel_dp)
if (WARN_ON(!intel_encoder->base.crtc))
return;
+ if (!to_intel_crtc(intel_encoder->base.crtc)->active)
+ return;
+
/* Try to read receiver status if the link appears to be up */
if (!intel_dp_get_link_status(intel_dp, link_status)) {
return;
--
1.8.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/4] drm/i915: make sure VDD is turned off during system suspend
Atm we may leave eDP VDD enabled during system suspend after the CRTCs
are disabled through an HPD->DPCD read event. So disable VDD during
suspend at a point when no HPDs can occur.
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/i915_drv.c | 15 +++
drivers/gpu/drm/i915/intel_dp.c | 13 +++--
drivers/gpu/drm/i915/intel_drv.h | 6 ++
3 files changed, 32 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 0653761..1c7979e 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -501,6 +501,19 @@ void intel_hpd_cancel_work(struct drm_i915_private
*dev_priv)
cancel_delayed_work_sync(&dev_priv->hotplug_reenable_work);
}
+static void intel_suspend_encoders(struct drm_i915_private *dev_priv)
+{
+ struct drm_device *dev = dev_priv->dev;
+ struct intel_encoder *intel_encoder;
+
+ drm_modeset_lock_all(dev);
+ for_each_intel_encoder(dev, intel_encoder) {
+ if (intel_encoder->suspend)
+ intel_encoder->suspend(intel_encoder);
+ }
+ drm_modeset_unlock_all(dev);
+}
+
static int i915_drm_freeze(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev->dev_private;
@@ -547,6 +560,8 @@ static int i915_drm_freeze(struct drm_device *dev)
intel_runtime_pm_disable_interrupts(dev);
intel_hpd_cancel_work(dev_priv);
+ intel_suspend_encoders(dev_priv);
+
intel_suspend_gt_powersave(dev);
intel_modeset_suspend_hw(dev);
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 34e3c47..d7f5d0a 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1291,8 +1291,6 @@ static void edp_panel_vdd_off(struct intel_dp *intel_dp,
bool sync)
if (!is_edp(intel_dp))
return;
- WARN(!intel_dp->want_panel_vdd, "eDP VDD not forced on");
-
intel_dp->want_panel_vdd = false;
if (sync)
@@ -4003,6 +4001,16 @@ void intel_dp_encoder_destroy(struct drm_encoder
*encoder)
kfree(intel_dig_port);
}
+void intel_dp_encoder_suspend(struct intel_encoder *intel_encoder)
+{
+ struct intel_dp *intel_dp = enc_to_intel_dp(&intel_encoder->base);
+
+ if (!is_edp(intel_dp))
+ return;
+
+ edp_panel_vdd_off(intel_dp, true);
+}
+
static void intel_dp_encoder_reset(struct drm_encoder *encoder)
{
intel_edp_panel_vdd_sanitize(to_intel_encoder(encoder));
@@ -4722,6 +4730,7 @@ intel_dp_init(struct drm_device *dev, int output_reg,
enum port port)
intel_encoder->disable = intel_disable_dp;
intel_encoder->get_hw_state = intel_dp_get_hw_state;
intel_encoder->get_config = intel_dp_get_config;
+ intel_encoder->suspend = intel_dp_encoder_suspend;
if (IS_CHERRYVIEW(dev)) {
intel_encoder->pre_pll_enable = chv_dp_pre_pll_enable;
intel_encoder->pre_enable = chv_pre_enable_dp;
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 1b3d1d7..cefd337 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -153,6 +153,12 @@ struct intel_encoder {
* be set correctly before calling this function. */
void (*get_config)(struct intel_encoder *,
struct intel_crtc_config *pipe_config);
+ /*
+* Called during system suspend after all pending requests for the
+* encoder are flushed (for example for DP AUX transactions) and
+* device interrupts are disabled.
+*/
+ void (*suspend)(struct intel_encoder *);
int crtc_mask;
enum hpd_pin hpd_pin;
};
--
1.8.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/4] drm/i915: cancel hotplug and dig_port work during suspend and unload
Make sure these work handlers don't run after we system suspend or
unload the driver. Note that we don't cancel the handlers during runtime
suspend. That could lead to a lockup, since we take a runtime PM ref
from the handlers themselves. Fortunaltely canceling there is not needed
since the RPM ref itself provides for the needed serialization.
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/i915_drv.c | 8
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/intel_display.c | 3 +--
3 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index ec96f9a..0653761 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -494,6 +494,13 @@ bool i915_semaphore_is_enabled(struct drm_device *dev)
return true;
}
+void intel_hpd_cancel_work(struct drm_i915_private *dev_priv)
+{
+ cancel_work_sync(&dev_priv->hotplug_work);
+ cancel_work_sync(&dev_priv->dig_port_work);
+ cancel_delayed_work_sync(&dev_priv->hotplug_reenable_work);
+}
+
static int i915_drm_freeze(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev->dev_private;
@@ -538,6 +545,7 @@ static int i915_drm_freeze(struct drm_device *dev)
flush_delayed_work(&dev_priv->rps.delayed_resume_work);
intel_runtime_pm_disable_interrupts(dev);
+ intel_hpd_cancel_work(dev_priv);
intel_suspend_gt_powersave(dev);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 35d150a..8776847 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2218,6 +2218,7 @@ extern void i915_update_gfx_val(struct drm_i915_private
*dev_priv);
int vlv_force_gfx_clock(struct drm_i915_private *dev_priv, bool on);
extern void intel_console_resume(struct work_struct *work);
+void intel_hpd_cancel_work(struct drm_i915_private *dev_priv);
/* i915_irq.c */
void i915_queue_hangcheck(struct drm_device *dev);
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index b3a3168..ab90301 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13100,8 +13100,7 @@ void intel_modeset_cleanup(struct drm_device *dev)
* experience fancy races otherwise.
*/
drm_irq_uninstall(dev);
- cancel_work_sync(&dev_priv->hotplug_work);
- cancel_delayed_work_sync(&dev_priv->hotplug_reenable_work);
+ intel_hpd_cancel_work(dev_priv);
dev_priv->pm._irqs_disabled = true;
/*
--
1.8.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/4] drm/i915: fix HPD IRQ reenable work cancelation
Atm, the HPD IRQ reenable timer can get rearmed right after it's
canceled. Also to access the HPD IRQ mask registers we need to wake up
the HW.
Solve both issues by converting the reenable timer to a delayed work and
grabbing a runtime PM reference in the work. By this we can also forgo
canceling the timer during runtime suspend, since the only important
thing there is that the HW is awake when we write the registers and
that's ensured by the RPM ref. So do the cancelation only during driver
unload time; this is also a requirement for an upcoming patch where we
want to cancel all HPD related works only during system suspend and
driver unload time, but not during runtime suspend.
Note that there is still a race between the HPD IRQ reenable work and
drm_irq_uninstall() during driver unload, where the work can reenable
the HPD IRQs disabled by drm_irq_uninstall(). This isn't a problem since
the HPD IRQs will still be effectively masked by the first level
interrupt mask.
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/i915_drv.h | 2 +-
drivers/gpu/drm/i915/i915_irq.c | 33 -
drivers/gpu/drm/i915/intel_display.c | 1 +
3 files changed, 14 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 9198f1c..35d150a 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1483,7 +1483,7 @@ struct drm_i915_private {
} hpd_mark;
} hpd_stats[HPD_NUM_PINS];
u32 hpd_event_bits;
- struct timer_list hotplug_reenable_timer;
+ struct delayed_work hotplug_reenable_work;
struct i915_fbc fbc;
struct i915_drrs drrs;
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 8e6729e..fbf1eff 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1189,8 +1189,8 @@ static void i915_hotplug_work_func(struct work_struct
*work)
* some connectors */
if (hpd_disabled) {
drm_kms_helper_poll_enable(dev);
- mod_timer(&dev_priv->hotplug_reenable_timer,
- jiffies +
msecs_to_jiffies(I915_REENABLE_HOTPLUG_DELAY));
+ schedule_delayed_work(&dev_priv->hotplug_reenable_work,
+ msecs_to_jiffies(I915_REENABLE_HOTPLUG_DELAY));
}
spin_unlock_irqrestore(&dev_priv->irq_lock, irqflags);
@@ -1213,11 +1213,6 @@ static void i915_hotplug_work_func(struct work_struct
*work)
drm_kms_helper_hotplug_event(dev);
}
-static void intel_hpd_irq_uninstall(struct drm_i915_private *dev_priv)
-{
- del_timer_sync(&dev_priv->hotplug_reenable_timer);
-}
-
static void ironlake_rps_change_irq_handler(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev->dev_private;
@@ -3886,8 +3881,6 @@ static void gen8_irq_uninstall(struct drm_device *dev)
if (!dev_priv)
return;
- intel_hpd_irq_uninstall(dev_priv);
-
gen8_irq_reset(dev);
}
@@ -3902,8 +3895,6 @@ static void valleyview_irq_uninstall(struct drm_device
*dev)
I915_WRITE(VLV_MASTER_IER, 0);
- intel_hpd_irq_uninstall(dev_priv);
-
for_each_pipe(pipe)
I915_WRITE(PIPESTAT(pipe), 0x);
@@ -3982,8 +3973,6 @@ static void ironlake_irq_uninstall(struct drm_device *dev)
if (!dev_priv)
return;
- intel_hpd_irq_uninstall(dev_priv);
-
ironlake_irq_reset(dev);
}
@@ -4354,8 +4343,6 @@ static void i915_irq_uninstall(struct drm_device * dev)
struct drm_i915_private *dev_priv = dev->dev_private;
int pipe;
- intel_hpd_irq_uninstall(dev_priv);
-
if (I915_HAS_HOTPLUG(dev)) {
I915_WRITE(PORT_HOTPLUG_EN, 0);
I915_WRITE(PORT_HOTPLUG_STAT, I915_READ(PORT_HOTPLUG_STAT));
@@ -4591,8 +4578,6 @@ static void i965_irq_uninstall(struct drm_device * dev)
if (!dev_priv)
return;
- intel_hpd_irq_uninstall(dev_priv);
-
I915_WRITE(PORT_HOTPLUG_EN, 0);
I915_WRITE(PORT_HOTPLUG_STAT, I915_READ(PORT_HOTPLUG_STAT));
@@ -4608,14 +4593,18 @@ static void i965_irq_uninstall(struct drm_device * dev)
I915_WRITE(IIR, I915_READ(IIR));
}
-static void intel_hpd_irq_reenable(unsigned long data)
+static void intel_hpd_irq_reenable(struct work_struct *work)
{
- struct drm_i915_private *dev_priv = (struct drm_i915_private *)data;
+ struct drm_i915_private *dev_priv =
+ container_of(work, typeof(*dev_priv),
+hotplug_reenable_work.work);
struct drm_device *dev = dev_priv->dev;
struct drm_mode_config *mode_config = &dev->mode_config;
unsigned long irqflags;
int i;
+ intel_runtime_pm_get(dev_priv);
+
spin_lock_irqsave(&dev_priv->irq_lock, irqflags);
for (i = (HPD_NONE + 1); i < HPD_NUM_PINS; i++
[Intel-gfx] [PATCH v3] drm/i915/bdw: BDW Software Turbo
BDW supports GT C0 residency reporting in constant time unit. Driver
calculates GT utilization based on C0 residency and adjusts RP
frequency up/down accordingly. For offscreen workload specificly,
set frequency to RP0.
Offscreen task is not restricted by frame rate, it can be
executed as soon as possible. Transcoding and serilized workload
between CPU and GPU both need high GT performance, RP0 is a good
option in this case. RC6 will kick in to compensate power
consumption when GT is not active.
v2: Rebase on recent drm-intel-nightly
v3: Add flip timerout monitor, when no flip is deteced within
100ms, set frequency to RP0.
Signed-off-by: Daisy Sun
[torourke: rebased on latest and resolved conflict]
Signed-off-by: Tom O'Rourke
---
drivers/gpu/drm/i915/i915_drv.h | 22
drivers/gpu/drm/i915/i915_irq.c | 21
drivers/gpu/drm/i915/i915_reg.h | 4 +
drivers/gpu/drm/i915/intel_display.c | 3 +
drivers/gpu/drm/i915/intel_pm.c | 230 +--
5 files changed, 241 insertions(+), 39 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index ef38c3b..f1c4c5b 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -915,6 +915,23 @@ struct intel_rps_ei {
u32 media_c0;
};
+struct intel_rps_bdw_cal {
+ u32 it_threshold_pct; /* interrupt, in percentage */
+ u32 eval_interval; /* evaluation interval, in us */
+ u32 last_ts;
+ u32 last_c0;
+ bool is_up;
+};
+
+struct intel_rps_bdw_turbo {
+ struct intel_rps_bdw_cal up;
+ struct intel_rps_bdw_cal down;
+ struct timer_list flip_timer;
+ u32 timeout;
+ atomic_t flip_received;
+ struct work_struct work_max_freq;
+};
+
struct intel_gen6_power_mgmt {
/* work and pm_iir are protected by dev_priv->irq_lock */
struct work_struct work;
@@ -948,6 +965,9 @@ struct intel_gen6_power_mgmt {
bool enabled;
struct delayed_work delayed_resume_work;
+ bool is_bdw_sw_turbo; /* Switch of BDW software turbo */
+ struct intel_rps_bdw_turbo sw_turbo; /* Calculate RP interrupt timing */
+
/* manual wa residency calculations */
struct intel_rps_ei up_ei, down_ei;
@@ -2703,6 +2723,8 @@ extern void intel_disable_fbc(struct drm_device *dev);
extern bool ironlake_set_drps(struct drm_device *dev, u8 val);
extern void intel_init_pch_refclk(struct drm_device *dev);
extern void gen6_set_rps(struct drm_device *dev, u8 val);
+extern void bdw_software_turbo(struct drm_device *dev);
+extern void gen8_flip_interrupt(struct drm_device *dev);
extern void valleyview_set_rps(struct drm_device *dev, u8 val);
extern void intel_set_memory_cxsr(struct drm_i915_private *dev_priv,
bool enable);
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 6ef9d6f..367f8e1 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1961,6 +1961,27 @@ static void i9xx_pipe_crc_irq_handler(struct drm_device
*dev, enum pipe pipe)
res1, res2);
}
+void gen8_flip_interrupt(struct drm_device *dev)
+{
+ struct drm_i915_private *dev_priv = dev->dev_private;
+
+ if (!dev_priv->rps.is_bdw_sw_turbo)
+ return;
+
+ if(atomic_read(&dev_priv->rps.sw_turbo.flip_received)) {
+ mod_timer(&dev_priv->rps.sw_turbo.flip_timer,
+
usecs_to_jiffies(dev_priv->rps.sw_turbo.timeout) + jiffies);
+ }
+ else {
+ dev_priv->rps.sw_turbo.flip_timer.expires =
+
usecs_to_jiffies(dev_priv->rps.sw_turbo.timeout) + jiffies;
+ add_timer(&dev_priv->rps.sw_turbo.flip_timer);
+ atomic_set(&dev_priv->rps.sw_turbo.flip_received, true);
+ }
+
+ bdw_software_turbo(dev);
+}
+
/* The RPS events need forcewake, so we add them to a work queue and mask their
* IMR bits until the work is done. Other interrupts can be processed without
* the work queue. */
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index fe5c276..088e0e1 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -5453,6 +5453,10 @@ enum punit_power_well {
#define GEN8_UCGCTL6 0x9430
#define GEN8_SDEUNIT_CLOCK_GATE_DISABLE (1<<14)
+#define TIMESTAMP_CTR 0x44070
+#define FREQ_1_28_US(us) (((us) * 100) >> 7)
+#define MCHBAR_PCU_C0 (MCHBAR_MIRROR_BASE_SNB + 0x5960)
+
#define GEN6_GFXPAUSE 0xA000
#define GEN6_RPNSWREQ 0xA008
#define GEN6_TURBO_DISABLE (1<<31)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 99eb7ca..1dd8a7c 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i91
Re: [Intel-gfx] [PATCH] drm/i915: fix plane/cursor handling when runtime suspended
2014-08-11 11:42 GMT-03:00 Ville Syrjälä :
> On Mon, Aug 11, 2014 at 11:29:21AM -0300, Paulo Zanoni wrote:
>> 2014-08-11 8:32 GMT-03:00 Ville Syrjälä :
>> > On Wed, Aug 06, 2014 at 06:26:01PM -0300, Paulo Zanoni wrote:
>> >> From: Paulo Zanoni
>> >>
>> >> If we're runtime suspended and try to use the plane interfaces, we
>> >> will get a lot of WARNs saying we did the wrong thing.
>> >>
>> >> For intel_crtc_update_cursor(), all we need to do is return if the
>> >> CRTC is not active, since writing the registers won't really have any
>> >> effect if the screen is not visible, and we will write the registers
>> >> later when enabling the screen.
>> >>
>> >> For all the other cases, we need to get runtime PM references to
>> >> pin/unpin the objects, and to change the fences. The pin/unpin
>> >> functions are the ideal places for this, but
>> >> intel_crtc_cursor_set_obj() doesn't call them, so we also have to add
>> >> get/put calls inside it. There is no problem if we runtime suspend
>> >> right after these functions are finished, because the registers
>> >> weitten are forwarded to system memory.
>> >>
>> >> v2: - Narrow the put/get calls on intel_crtc_cursor_set_obj() (Daniel)
>> >> v3: - Make get/put also surround the fence and unpin calls (Daniel and
>> >> Ville).
>> >> - Merge all the plane changes into a single patch since they're
>> >> the same fix.
>> >> - Add the comment requested by Daniel.
>> >>
>> >> Testcase: igt/pm_rpm/cursor
>> >> Testcase: igt/pm_rpm/cursor-dpms
>> >> Testcase: igt/pm_rpm/legacy-planes
>> >> Testcase: igt/pm_rpm/legacy-planes-dpms
>> >> Testcase: igt/pm_rpm/universal-planes
>> >> Testcase: igt/pm_rpm/universal-planes-dpms
>> >> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=81645
>> >> Cc: sta...@vger.kernel.org
>> >> Signed-off-by: Paulo Zanoni
>> >> ---
>> >> drivers/gpu/drm/i915/intel_display.c | 39
>> >> +++-
>> >> 1 file changed, 38 insertions(+), 1 deletion(-)
>> >>
>> >> diff --git a/drivers/gpu/drm/i915/intel_display.c
>> >> b/drivers/gpu/drm/i915/intel_display.c
>> >> index 4f659eb..a86d67c 100644
>> >> --- a/drivers/gpu/drm/i915/intel_display.c
>> >> +++ b/drivers/gpu/drm/i915/intel_display.c
>> >> @@ -2212,6 +2212,15 @@ intel_pin_and_fence_fb_obj(struct drm_device *dev,
>> >> if (need_vtd_wa(dev) && alignment < 256 * 1024)
>> >> alignment = 256 * 1024;
>> >>
>> >> + /*
>> >> + * Global gtt pte registers are special registers which actually
>> >> forward
>> >> + * writes to a chunk of system memory. Which means that there is no
>> >> risk
>> >> + * that the register values disappear as soon as we call
>> >> + * intel_runtime_pm_put(), so it is correct to wrap only the
>> >> + * pin/unpin/fence and not more.
>> >> + */
>> >> + intel_runtime_pm_get(dev_priv);
>> >> +
>> >> dev_priv->mm.interruptible = false;
>> >> ret = i915_gem_object_pin_to_display_plane(obj, alignment,
>> >> pipelined);
>> >> if (ret)
>> >> @@ -2229,21 +2238,30 @@ intel_pin_and_fence_fb_obj(struct drm_device *dev,
>> >> i915_gem_object_pin_fence(obj);
>> >>
>> >> dev_priv->mm.interruptible = true;
>> >> + intel_runtime_pm_put(dev_priv);
>> >> return 0;
>> >>
>> >> err_unpin:
>> >> i915_gem_object_unpin_from_display_plane(obj);
>> >> err_interruptible:
>> >> dev_priv->mm.interruptible = true;
>> >> + intel_runtime_pm_put(dev_priv);
>> >> return ret;
>> >> }
>> >>
>> >> void intel_unpin_fb_obj(struct drm_i915_gem_object *obj)
>> >> {
>> >> - WARN_ON(!mutex_is_locked(&obj->base.dev->struct_mutex));
>> >> + struct drm_device *dev = obj->base.dev;
>> >> + struct drm_i915_private *dev_priv = dev->dev_private;
>> >> +
>> >> + WARN_ON(!mutex_is_locked(&dev->struct_mutex));
>> >> +
>> >> + intel_runtime_pm_get(dev_priv);
>> >>
>> >> i915_gem_object_unpin_fence(obj);
>> >> i915_gem_object_unpin_from_display_plane(obj);
>> >> +
>> >> + intel_runtime_pm_put(dev_priv);
>> >
>> > I don't think we touch the hardware during unpin so these aren't
>> > strictly needed.
>> >
>>
>> Daniel requested them.
>>
>>
>> >> }
>> >>
>> >> /* Computes the linear offset to the base tile and adjusts x, y. bytes
>> >> per pixel
>> >> @@ -8285,6 +8303,9 @@ static void intel_crtc_update_cursor(struct
>> >> drm_crtc *crtc,
>> >> if (base == 0 && intel_crtc->cursor_base == 0)
>> >> return;
>> >>
>> >> + if (!intel_crtc->active)
>> >> + return;
>> >> +
>> >
>> > Did you actually manage to get by the base==0 check above with a
>> > disabled pipe? I don't think this should happen.
>>
>> Yes, since we enabled runtime suspend during DPMS. Remember that
>> crtc->active != crtc->enabled.
>
> Then I think there's a bug somewhere a bit earlier. We should consider
> the cursor to be invisible when crtc->active==false. That's how we deal
> with all other planes.
Why? I am not ve
Re: [Intel-gfx] [PATCH] drm/i915: Make hpd debug messages less cryptic
On Mon, Aug 11, 2014 at 06:05:24PM +0100, Damien Lespiau wrote:
> On Mon, Aug 11, 2014 at 06:37:37PM +0300, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > Don't print raw numbers, use port_name() and tell the user whether it's
> > long or short without having to figure out what the other magic number
> > means.
> >
> > Signed-off-by: Ville Syrjälä
>
> Reviewed-by: Damien Lespiau
Queued for -next, thanks for the patch.
-Daniel
>
> --
> Damien
>
> > ---
> > drivers/gpu/drm/i915/i915_irq.c | 4 +++-
> > drivers/gpu/drm/i915/intel_dp.c | 3 ++-
> > 2 files changed, 5 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_irq.c
> > b/drivers/gpu/drm/i915/i915_irq.c
> > index 8e6729e..4a86fc5 100644
> > --- a/drivers/gpu/drm/i915/i915_irq.c
> > +++ b/drivers/gpu/drm/i915/i915_irq.c
> > @@ -1777,7 +1777,9 @@ static inline void intel_hpd_irq_handler(struct
> > drm_device *dev,
> > long_hpd = (dig_hotplug_reg >> dig_shift) &
> > PORTB_HOTPLUG_LONG_DETECT;
> > }
> >
> > - DRM_DEBUG_DRIVER("digital hpd port %d %d\n", port,
> > long_hpd);
> > + DRM_DEBUG_DRIVER("digital hpd port %c - %s\n",
> > +port_name(port),
> > +long_hpd ? "long" : "short");
> > /* for long HPD pulses we want to have the digital
> > queue happen,
> >but we still want HPD storm detection to function. */
> > if (long_hpd) {
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > b/drivers/gpu/drm/i915/intel_dp.c
> > index 34e3c47..e5ada4f 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -4043,7 +4043,8 @@ intel_dp_hpd_pulse(struct intel_digital_port
> > *intel_dig_port, bool long_hpd)
> > if (intel_dig_port->base.type != INTEL_OUTPUT_EDP)
> > intel_dig_port->base.type = INTEL_OUTPUT_DISPLAYPORT;
> >
> > - DRM_DEBUG_KMS("got hpd irq on port %d - %s\n", intel_dig_port->port,
> > + DRM_DEBUG_KMS("got hpd irq on port %c - %s\n",
> > + port_name(intel_dig_port->port),
> > long_hpd ? "long" : "short");
> >
> > if (long_hpd) {
> > --
> > 1.8.5.5
> >
> > ___
> > 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
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Update PSR on resume.
On Mon, Aug 11, 2014 at 09:57:12AM -0700, Rodrigo Vivi wrote: > Well, this fix the issue Linus faced. > > Actually the issue I was aware of and trying to fix with this patch for a > long time was reported by chromeos guys saying the psr wasn't propperly > working after suspend/resume. They got the screen back but never got psr > back again. > > The original patch fix suspend/resume issues with psr and I decided to keep > the same and subject for reference of what the problem this fixes and what > was the patch history, but changed the place for the full setup to > crtc_enable per your recommendation. So if I read your patch correctly then we no do the initial psr setup in crtc_enable, but only after driver load/resume. Before we do it always when crtc_enable is called. That doesn't make sense. Also note that Linus said it's also sometimes broken when using X normally. Otoh if there's really something we need to in crtc_enable in addition to what we do already, then we _must_ do it always. Otherwise runtime pm (which is pretty much the same as system resume) will not work. -Daniel > > Thanks, > Rodrigo. > > > > On Sat, Aug 9, 2014 at 12:40 AM, Daniel Vetter > wrote: > > > On Fri, Aug 8, 2014 at 7:19 PM, Rodrigo Vivi > > wrote: > > > From: Rodrigo Vivi > > > > > > Some registers set during setup might not be persistent after > > suspend/resume. > > > This was causing bugs for some people that was unable to get PSR entry > > state > > > after resume cycle. > > > > > > v2: Adding some comments and better commit message explaining why this > > is needed. > > > v3: Getting back old setup_done variable and move from resume to > > crtc_enable > > > as Daniel requested. > > > > > > Cc: Daniel Vetter > > > Signed-off-by: Rodrigo Vivi > > > > I'm confused ... whats the use of this? Afaict that's exactly what the > > code currently does. > > -Daniel > > -- > > Daniel Vetter > > Software Engineer, Intel Corporation > > +41 (0) 79 365 57 48 - http://blog.ffwll.ch > > > > > > -- > Rodrigo Vivi > Blog: http://blog.vivi.eng.br -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Make hpd debug messages less cryptic
On Mon, Aug 11, 2014 at 06:37:37PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Don't print raw numbers, use port_name() and tell the user whether it's
> long or short without having to figure out what the other magic number
> means.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Damien Lespiau
--
Damien
> ---
> drivers/gpu/drm/i915/i915_irq.c | 4 +++-
> drivers/gpu/drm/i915/intel_dp.c | 3 ++-
> 2 files changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index 8e6729e..4a86fc5 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -1777,7 +1777,9 @@ static inline void intel_hpd_irq_handler(struct
> drm_device *dev,
> long_hpd = (dig_hotplug_reg >> dig_shift) &
> PORTB_HOTPLUG_LONG_DETECT;
> }
>
> - DRM_DEBUG_DRIVER("digital hpd port %d %d\n", port,
> long_hpd);
> + DRM_DEBUG_DRIVER("digital hpd port %c - %s\n",
> + port_name(port),
> + long_hpd ? "long" : "short");
> /* for long HPD pulses we want to have the digital
> queue happen,
> but we still want HPD storm detection to function. */
> if (long_hpd) {
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 34e3c47..e5ada4f 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -4043,7 +4043,8 @@ intel_dp_hpd_pulse(struct intel_digital_port
> *intel_dig_port, bool long_hpd)
> if (intel_dig_port->base.type != INTEL_OUTPUT_EDP)
> intel_dig_port->base.type = INTEL_OUTPUT_DISPLAYPORT;
>
> - DRM_DEBUG_KMS("got hpd irq on port %d - %s\n", intel_dig_port->port,
> + DRM_DEBUG_KMS("got hpd irq on port %c - %s\n",
> + port_name(intel_dig_port->port),
> long_hpd ? "long" : "short");
>
> if (long_hpd) {
> --
> 1.8.5.5
>
> ___
> 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 2/7] drm/i915: Renaming DP training vswing pre emph defines
On Fri, Aug 08, 2014 at 04:23:41PM +0530, sonika.jin...@intel.com wrote:
> From: Sonika Jindal
>
> Rename the defines to have levels instead of values for vswing and
> pre-emph levels as the values may differ in other scenarios like low vswing of
> eDP1.4 where the values are different.
>
> Done using following cocci patch for each define:
> @@
> @@
>
> # define DP_TRAIN_VOLTAGE_SWING_400 (0 << 0)
> + # define DP_TRAIN_VOLTAGE_SWING_LEVEL_0 (0 << 0)
>
> ...
>
> Signed-off-by: Sonika Jindal
Reviewed-by: Damien Lespiau
--
Damien
> ---
> drivers/gpu/drm/i915/intel_bios.c | 16 +--
> drivers/gpu/drm/i915/intel_dp.c | 194
> ++---
> 2 files changed, 105 insertions(+), 105 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_bios.c
> b/drivers/gpu/drm/i915/intel_bios.c
> index 031c565..e871f68 100644
> --- a/drivers/gpu/drm/i915/intel_bios.c
> +++ b/drivers/gpu/drm/i915/intel_bios.c
> @@ -627,16 +627,16 @@ parse_edp(struct drm_i915_private *dev_priv, struct
> bdb_header *bdb)
>
> switch (edp_link_params->preemphasis) {
> case EDP_PREEMPHASIS_NONE:
> - dev_priv->vbt.edp_preemphasis = DP_TRAIN_PRE_EMPHASIS_0;
> + dev_priv->vbt.edp_preemphasis = DP_TRAIN_PRE_EMPH_LEVEL_0;
> break;
> case EDP_PREEMPHASIS_3_5dB:
> - dev_priv->vbt.edp_preemphasis = DP_TRAIN_PRE_EMPHASIS_3_5;
> + dev_priv->vbt.edp_preemphasis = DP_TRAIN_PRE_EMPH_LEVEL_1;
> break;
> case EDP_PREEMPHASIS_6dB:
> - dev_priv->vbt.edp_preemphasis = DP_TRAIN_PRE_EMPHASIS_6;
> + dev_priv->vbt.edp_preemphasis = DP_TRAIN_PRE_EMPH_LEVEL_2;
> break;
> case EDP_PREEMPHASIS_9_5dB:
> - dev_priv->vbt.edp_preemphasis = DP_TRAIN_PRE_EMPHASIS_9_5;
> + dev_priv->vbt.edp_preemphasis = DP_TRAIN_PRE_EMPH_LEVEL_3;
> break;
> default:
> DRM_DEBUG_KMS("VBT has unknown eDP pre-emphasis value %u\n",
> @@ -646,16 +646,16 @@ parse_edp(struct drm_i915_private *dev_priv, struct
> bdb_header *bdb)
>
> switch (edp_link_params->vswing) {
> case EDP_VSWING_0_4V:
> - dev_priv->vbt.edp_vswing = DP_TRAIN_VOLTAGE_SWING_400;
> + dev_priv->vbt.edp_vswing = DP_TRAIN_VOLTAGE_SWING_LEVEL_0;
> break;
> case EDP_VSWING_0_6V:
> - dev_priv->vbt.edp_vswing = DP_TRAIN_VOLTAGE_SWING_600;
> + dev_priv->vbt.edp_vswing = DP_TRAIN_VOLTAGE_SWING_LEVEL_1;
> break;
> case EDP_VSWING_0_8V:
> - dev_priv->vbt.edp_vswing = DP_TRAIN_VOLTAGE_SWING_800;
> + dev_priv->vbt.edp_vswing = DP_TRAIN_VOLTAGE_SWING_LEVEL_2;
> break;
> case EDP_VSWING_1_2V:
> - dev_priv->vbt.edp_vswing = DP_TRAIN_VOLTAGE_SWING_1200;
> + dev_priv->vbt.edp_vswing = DP_TRAIN_VOLTAGE_SWING_LEVEL_3;
> break;
> default:
> DRM_DEBUG_KMS("VBT has unknown eDP voltage swing value %u\n",
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 34e3c47..01f264c 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -2381,13 +2381,13 @@ intel_dp_voltage_max(struct intel_dp *intel_dp)
> enum port port = dp_to_dig_port(intel_dp)->port;
>
> if (IS_VALLEYVIEW(dev))
> - return DP_TRAIN_VOLTAGE_SWING_1200;
> + return DP_TRAIN_VOLTAGE_SWING_LEVEL_3;
> else if (IS_GEN7(dev) && port == PORT_A)
> - return DP_TRAIN_VOLTAGE_SWING_800;
> + return DP_TRAIN_VOLTAGE_SWING_LEVEL_2;
> else if (HAS_PCH_CPT(dev) && port != PORT_A)
> - return DP_TRAIN_VOLTAGE_SWING_1200;
> + return DP_TRAIN_VOLTAGE_SWING_LEVEL_3;
> else
> - return DP_TRAIN_VOLTAGE_SWING_800;
> + return DP_TRAIN_VOLTAGE_SWING_LEVEL_2;
> }
>
> static uint8_t
> @@ -2398,49 +2398,49 @@ intel_dp_pre_emphasis_max(struct intel_dp *intel_dp,
> uint8_t voltage_swing)
>
> if (IS_HASWELL(dev) || IS_BROADWELL(dev)) {
> switch (voltage_swing & DP_TRAIN_VOLTAGE_SWING_MASK) {
> - case DP_TRAIN_VOLTAGE_SWING_400:
> - return DP_TRAIN_PRE_EMPHASIS_9_5;
> - case DP_TRAIN_VOLTAGE_SWING_600:
> - return DP_TRAIN_PRE_EMPHASIS_6;
> - case DP_TRAIN_VOLTAGE_SWING_800:
> - return DP_TRAIN_PRE_EMPHASIS_3_5;
> - case DP_TRAIN_VOLTAGE_SWING_1200:
> + case DP_TRAIN_VOLTAGE_SWING_LEVEL_0:
> + return DP_TRAIN_PRE_EMPH_LEVEL_3;
> + case DP_TRAIN_VOLTAGE_SWING_LEVEL_1:
> + return DP_TRAIN_PRE_EMPH_LEVEL_2;
> + case DP_TRAIN_VOLTAGE_SWING_LEVEL_2:
> + return DP_TRAIN_PRE_EMPH_LEVEL_1;
> + case DP_TRAIN_VOLTAGE_SWING_LEVEL_3:
> defaul
Re: [Intel-gfx] [PATCH 1/7] drm: Renaming DP training vswing pre emph defines
On Fri, Aug 08, 2014 at 04:23:40PM +0530, sonika.jin...@intel.com wrote: > From: Sonika Jindal > > Adding new defines, older one will be removed in the last patch in the series. > This is to rename the defines to have levels instead of values for vswing and > pre-emph levels as the values may differ in other scenarios like low vswing of > eDP1.4 where the values are different. > > Done using following cocci patch for each define: > @@ > @@ > > # define DP_TRAIN_VOLTAGE_SWING_400 (0 << 0) > + # define DP_TRAIN_VOLTAGE_SWING_LEVEL_0 (0 << 0) > > ... > Cc: dri-de...@lists.freedesktop.org > > Signed-off-by: Sonika Jindal Reviewed-by: Damien Lespiau -- Damien > --- > include/drm/drm_dp_helper.h |8 > 1 file changed, 8 insertions(+) > > diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h > index a21568b..3840a05 100644 > --- a/include/drm/drm_dp_helper.h > +++ b/include/drm/drm_dp_helper.h > @@ -191,15 +191,23 @@ > # define DP_TRAIN_VOLTAGE_SWING_SHIFT0 > # define DP_TRAIN_MAX_SWING_REACHED (1 << 2) > # define DP_TRAIN_VOLTAGE_SWING_400 (0 << 0) > +# define DP_TRAIN_VOLTAGE_SWING_LEVEL_0 (0 << 0) > # define DP_TRAIN_VOLTAGE_SWING_600 (1 << 0) > +# define DP_TRAIN_VOLTAGE_SWING_LEVEL_1 (1 << 0) > # define DP_TRAIN_VOLTAGE_SWING_800 (2 << 0) > +# define DP_TRAIN_VOLTAGE_SWING_LEVEL_2 (2 << 0) > # define DP_TRAIN_VOLTAGE_SWING_1200 (3 << 0) > +# define DP_TRAIN_VOLTAGE_SWING_LEVEL_3 (3 << 0) > > # define DP_TRAIN_PRE_EMPHASIS_MASK (3 << 3) > # define DP_TRAIN_PRE_EMPHASIS_0 (0 << 3) > +# define DP_TRAIN_PRE_EMPH_LEVEL_0 (0 << 3) > # define DP_TRAIN_PRE_EMPHASIS_3_5 (1 << 3) > +# define DP_TRAIN_PRE_EMPH_LEVEL_1 (1 << 3) > # define DP_TRAIN_PRE_EMPHASIS_6 (2 << 3) > +# define DP_TRAIN_PRE_EMPH_LEVEL_2 (2 << 3) > # define DP_TRAIN_PRE_EMPHASIS_9_5 (3 << 3) > +# define DP_TRAIN_PRE_EMPH_LEVEL_3 (3 << 3) > > # define DP_TRAIN_PRE_EMPHASIS_SHIFT 3 > # define DP_TRAIN_MAX_PRE_EMPHASIS_REACHED (1 << 5) > -- > 1.7.10.4 > > ___ > 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] drm/i915: Update PSR on resume.
Well, this fix the issue Linus faced. Actually the issue I was aware of and trying to fix with this patch for a long time was reported by chromeos guys saying the psr wasn't propperly working after suspend/resume. They got the screen back but never got psr back again. The original patch fix suspend/resume issues with psr and I decided to keep the same and subject for reference of what the problem this fixes and what was the patch history, but changed the place for the full setup to crtc_enable per your recommendation. Thanks, Rodrigo. On Sat, Aug 9, 2014 at 12:40 AM, Daniel Vetter wrote: > On Fri, Aug 8, 2014 at 7:19 PM, Rodrigo Vivi > wrote: > > From: Rodrigo Vivi > > > > Some registers set during setup might not be persistent after > suspend/resume. > > This was causing bugs for some people that was unable to get PSR entry > state > > after resume cycle. > > > > v2: Adding some comments and better commit message explaining why this > is needed. > > v3: Getting back old setup_done variable and move from resume to > crtc_enable > > as Daniel requested. > > > > Cc: Daniel Vetter > > Signed-off-by: Rodrigo Vivi > > I'm confused ... whats the use of this? Afaict that's exactly what the > code currently does. > -Daniel > -- > Daniel Vetter > Software Engineer, Intel Corporation > +41 (0) 79 365 57 48 - http://blog.ffwll.ch > -- Rodrigo Vivi Blog: http://blog.vivi.eng.br ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Make hpd debug messages less cryptic
From: Ville Syrjälä
Don't print raw numbers, use port_name() and tell the user whether it's
long or short without having to figure out what the other magic number
means.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_irq.c | 4 +++-
drivers/gpu/drm/i915/intel_dp.c | 3 ++-
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 8e6729e..4a86fc5 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1777,7 +1777,9 @@ static inline void intel_hpd_irq_handler(struct
drm_device *dev,
long_hpd = (dig_hotplug_reg >> dig_shift) &
PORTB_HOTPLUG_LONG_DETECT;
}
- DRM_DEBUG_DRIVER("digital hpd port %d %d\n", port,
long_hpd);
+ DRM_DEBUG_DRIVER("digital hpd port %c - %s\n",
+port_name(port),
+long_hpd ? "long" : "short");
/* for long HPD pulses we want to have the digital
queue happen,
but we still want HPD storm detection to function. */
if (long_hpd) {
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 34e3c47..e5ada4f 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4043,7 +4043,8 @@ intel_dp_hpd_pulse(struct intel_digital_port
*intel_dig_port, bool long_hpd)
if (intel_dig_port->base.type != INTEL_OUTPUT_EDP)
intel_dig_port->base.type = INTEL_OUTPUT_DISPLAYPORT;
- DRM_DEBUG_KMS("got hpd irq on port %d - %s\n", intel_dig_port->port,
+ DRM_DEBUG_KMS("got hpd irq on port %c - %s\n",
+ port_name(intel_dig_port->port),
long_hpd ? "long" : "short");
if (long_hpd) {
--
1.8.5.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 17/43] drm/i915/bdw: GEN-specific logical ring set/get seqno
On Thu, Jul 24, 2014 at 05:04:25PM +0100, Thomas Daniel wrote:
> From: Oscar Mateo
>
> No mistery here: the seqno is still retrieved from the engine's
> HW status page (the one in the default context. For the moment,
> I see no reason to worry about other context's HWS page).
>
> Signed-off-by: Oscar Mateo
Ok, merged or bikeshedded up to this one. I need a bit a break to
recharge, will continue later on.
Cheers, Daniel
> ---
> drivers/gpu/drm/i915/intel_lrc.c | 20
> 1 file changed, 20 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_lrc.c
> b/drivers/gpu/drm/i915/intel_lrc.c
> index 7c8b75e..f171fd5 100644
> --- a/drivers/gpu/drm/i915/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/intel_lrc.c
> @@ -149,6 +149,16 @@ static int gen8_init_render_ring(struct intel_engine_cs
> *ring)
> return ret;
> }
>
> +static u32 gen8_get_seqno(struct intel_engine_cs *ring, bool lazy_coherency)
> +{
> + return intel_read_status_page(ring, I915_GEM_HWS_INDEX);
> +}
> +
> +static void gen8_set_seqno(struct intel_engine_cs *ring, u32 seqno)
> +{
> + intel_write_status_page(ring, I915_GEM_HWS_INDEX, seqno);
> +}
> +
> void intel_logical_ring_cleanup(struct intel_engine_cs *ring)
> {
> if (!intel_ring_initialized(ring))
> @@ -221,6 +231,8 @@ static int logical_render_ring_init(struct drm_device
> *dev)
>
> ring->init = gen8_init_render_ring;
> ring->cleanup = intel_fini_pipe_control;
> + ring->get_seqno = gen8_get_seqno;
> + ring->set_seqno = gen8_set_seqno;
>
> return logical_ring_init(dev, ring);
> }
> @@ -237,6 +249,8 @@ static int logical_bsd_ring_init(struct drm_device *dev)
> GT_RENDER_USER_INTERRUPT << GEN8_VCS1_IRQ_SHIFT;
>
> ring->init = gen8_init_common_ring;
> + ring->get_seqno = gen8_get_seqno;
> + ring->set_seqno = gen8_set_seqno;
>
> return logical_ring_init(dev, ring);
> }
> @@ -253,6 +267,8 @@ static int logical_bsd2_ring_init(struct drm_device *dev)
> GT_RENDER_USER_INTERRUPT << GEN8_VCS2_IRQ_SHIFT;
>
> ring->init = gen8_init_common_ring;
> + ring->get_seqno = gen8_get_seqno;
> + ring->set_seqno = gen8_set_seqno;
>
> return logical_ring_init(dev, ring);
> }
> @@ -269,6 +285,8 @@ static int logical_blt_ring_init(struct drm_device *dev)
> GT_RENDER_USER_INTERRUPT << GEN8_BCS_IRQ_SHIFT;
>
> ring->init = gen8_init_common_ring;
> + ring->get_seqno = gen8_get_seqno;
> + ring->set_seqno = gen8_set_seqno;
>
> return logical_ring_init(dev, ring);
> }
> @@ -285,6 +303,8 @@ static int logical_vebox_ring_init(struct drm_device *dev)
> GT_RENDER_USER_INTERRUPT << GEN8_VECS_IRQ_SHIFT;
>
> ring->init = gen8_init_common_ring;
> + ring->get_seqno = gen8_get_seqno;
> + ring->set_seqno = gen8_set_seqno;
>
> return logical_ring_init(dev, ring);
> }
> --
> 1.7.9.5
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 16/43] drm/i915/bdw: GEN-specific logical ring init
On Thu, Jul 24, 2014 at 05:04:24PM +0100, Thomas Daniel wrote:
> From: Oscar Mateo
>
> Logical rings do not need most of the initialization their
> legacy ringbuffer counterparts do: we just need the pipe
> control object for the render ring, enable Execlists on the
> hardware and a few workarounds.
>
> v2: Squash with: "drm/i915: Extract pipe control fini & make
> init outside accesible".
>
> Signed-off-by: Oscar Mateo
> ---
> drivers/gpu/drm/i915/intel_lrc.c| 54
> +++
> drivers/gpu/drm/i915/intel_ringbuffer.c | 34 +++
> drivers/gpu/drm/i915/intel_ringbuffer.h |3 ++
> 3 files changed, 78 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_lrc.c
> b/drivers/gpu/drm/i915/intel_lrc.c
> index 05b7069..7c8b75e 100644
> --- a/drivers/gpu/drm/i915/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/intel_lrc.c
> @@ -106,6 +106,49 @@ void intel_logical_ring_stop(struct intel_engine_cs
> *ring)
> /* TODO */
> }
>
> +static int gen8_init_common_ring(struct intel_engine_cs *ring)
> +{
> + struct drm_device *dev = ring->dev;
> + struct drm_i915_private *dev_priv = dev->dev_private;
> +
> + I915_WRITE(RING_MODE_GEN7(ring),
> + _MASKED_BIT_DISABLE(GFX_REPLAY_MODE) |
> + _MASKED_BIT_ENABLE(GFX_RUN_LIST_ENABLE));
Please build up a bit a closer relationship with checkpatch.pl, thanks.
Fixed while merging.
-Daniel
> + POSTING_READ(RING_MODE_GEN7(ring));
> + DRM_DEBUG_DRIVER("Execlists enabled for %s\n", ring->name);
> +
> + memset(&ring->hangcheck, 0, sizeof(ring->hangcheck));
> +
> + return 0;
> +}
> +
> +static int gen8_init_render_ring(struct intel_engine_cs *ring)
> +{
> + struct drm_device *dev = ring->dev;
> + struct drm_i915_private *dev_priv = dev->dev_private;
> + int ret;
> +
> + ret = gen8_init_common_ring(ring);
> + if (ret)
> + return ret;
> +
> + /* We need to disable the AsyncFlip performance optimisations in order
> + * to use MI_WAIT_FOR_EVENT within the CS. It should already be
> + * programmed to '1' on all products.
> + *
> + * WaDisableAsyncFlipPerfMode:snb,ivb,hsw,vlv,bdw,chv
> + */
> + I915_WRITE(MI_MODE, _MASKED_BIT_ENABLE(ASYNC_FLIP_PERF_DISABLE));
> +
> + ret = intel_init_pipe_control(ring);
> + if (ret)
> + return ret;
> +
> + I915_WRITE(INSTPM, _MASKED_BIT_ENABLE(INSTPM_FORCE_ORDERING));
> +
> + return ret;
> +}
> +
> void intel_logical_ring_cleanup(struct intel_engine_cs *ring)
> {
> if (!intel_ring_initialized(ring))
> @@ -176,6 +219,9 @@ static int logical_render_ring_init(struct drm_device
> *dev)
> ring->irq_enable_mask =
> GT_RENDER_USER_INTERRUPT << GEN8_RCS_IRQ_SHIFT;
>
> + ring->init = gen8_init_render_ring;
> + ring->cleanup = intel_fini_pipe_control;
> +
> return logical_ring_init(dev, ring);
> }
>
> @@ -190,6 +236,8 @@ static int logical_bsd_ring_init(struct drm_device *dev)
> ring->irq_enable_mask =
> GT_RENDER_USER_INTERRUPT << GEN8_VCS1_IRQ_SHIFT;
>
> + ring->init = gen8_init_common_ring;
> +
> return logical_ring_init(dev, ring);
> }
>
> @@ -204,6 +252,8 @@ static int logical_bsd2_ring_init(struct drm_device *dev)
> ring->irq_enable_mask =
> GT_RENDER_USER_INTERRUPT << GEN8_VCS2_IRQ_SHIFT;
>
> + ring->init = gen8_init_common_ring;
> +
> return logical_ring_init(dev, ring);
> }
>
> @@ -218,6 +268,8 @@ static int logical_blt_ring_init(struct drm_device *dev)
> ring->irq_enable_mask =
> GT_RENDER_USER_INTERRUPT << GEN8_BCS_IRQ_SHIFT;
>
> + ring->init = gen8_init_common_ring;
> +
> return logical_ring_init(dev, ring);
> }
>
> @@ -232,6 +284,8 @@ static int logical_vebox_ring_init(struct drm_device *dev)
> ring->irq_enable_mask =
> GT_RENDER_USER_INTERRUPT << GEN8_VECS_IRQ_SHIFT;
>
> + ring->init = gen8_init_common_ring;
> +
> return logical_ring_init(dev, ring);
> }
>
> diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
> b/drivers/gpu/drm/i915/intel_ringbuffer.c
> index 20eb1a4..ca45c58 100644
> --- a/drivers/gpu/drm/i915/intel_ringbuffer.c
> +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
> @@ -573,8 +573,25 @@ out:
> return ret;
> }
>
> -static int
> -init_pipe_control(struct intel_engine_cs *ring)
> +void
> +intel_fini_pipe_control(struct intel_engine_cs *ring)
> +{
> + struct drm_device *dev = ring->dev;
> +
> + if (ring->scratch.obj == NULL)
> + return;
> +
> + if (INTEL_INFO(dev)->gen >= 5) {
> + kunmap(sg_page(ring->scratch.obj->pages->sgl));
> + i915_gem_object_ggtt_unpin(ring->scratch.obj);
> + }
> +
> + drm_gem_object_unreference(&ring->scratch.obj->base);
> + ring->scratch.obj = NULL;
> +}
> +
> +int
> +intel_init_pipe_control(struct intel_engine_cs *ring)
> {
> int ret;
>
Re: [Intel-gfx] [PATCH 13/43] drm/i915: Abstract the legacy workload submission mechanism away
On Thu, Jul 24, 2014 at 05:04:21PM +0100, Thomas Daniel wrote:
> From: Oscar Mateo
>
> As suggested by Daniel Vetter. The idea, in subsequent patches, is to
> provide an alternative to these vfuncs for the Execlists submission
> mechanism.
>
> v2: Splitted into two and reordered to illustrate our intentions, instead
> of showing it off. Also, remove the add_request vfunc and added the
> stop_ring one.
>
> Signed-off-by: Oscar Mateo
> ---
> drivers/gpu/drm/i915/i915_drv.h| 24
> drivers/gpu/drm/i915/i915_gem.c| 15 +++
> drivers/gpu/drm/i915/i915_gem_execbuffer.c | 20 ++--
> 3 files changed, 45 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index ff2c373..1caed52 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1617,6 +1617,21 @@ struct drm_i915_private {
> /* Old ums support infrastructure, same warning applies. */
> struct i915_ums_state ums;
>
> + /* Abstract the submission mechanism (legacy ringbuffer or execlists)
> away */
> + struct {
> + int (*do_execbuf) (struct drm_device *dev, struct drm_file
> *file,
> +struct intel_engine_cs *ring,
> +struct intel_context *ctx,
> +struct drm_i915_gem_execbuffer2 *args,
> +struct list_head *vmas,
> +struct drm_i915_gem_object *batch_obj,
> +u64 exec_start, u32 flags);
> + int (*init_rings) (struct drm_device *dev);
> + void (*cleanup_ring) (struct intel_engine_cs *ring);
> + void (*stop_ring) (struct intel_engine_cs *ring);
> + bool (*is_ring_initialized) (struct intel_engine_cs *ring);
Aside: ring here is a bit a misnomer, we talk about the engines. I guess
at the end of all this we should throw a few patches on top to name things
correctly with ring/engine where appropriate.
-Daniel
> + } gt;
> +
> /*
>* NOTE: This is the dri1/ums dungeon, don't add stuff here. Your patch
>* will be rejected. Instead look for a better place.
> @@ -2224,6 +2239,14 @@ int i915_gem_set_domain_ioctl(struct drm_device *dev,
> void *data,
> struct drm_file *file_priv);
> int i915_gem_sw_finish_ioctl(struct drm_device *dev, void *data,
>struct drm_file *file_priv);
> +int i915_gem_ringbuffer_submission(struct drm_device *dev,
> +struct drm_file *file,
> +struct intel_engine_cs *ring,
> +struct intel_context *ctx,
> +struct drm_i915_gem_execbuffer2 *args,
> +struct list_head *vmas,
> +struct drm_i915_gem_object *batch_obj,
> +u64 exec_start, u32 flags);
> int i915_gem_execbuffer(struct drm_device *dev, void *data,
> struct drm_file *file_priv);
> int i915_gem_execbuffer2(struct drm_device *dev, void *data,
> @@ -2376,6 +2399,7 @@ void i915_gem_reset(struct drm_device *dev);
> bool i915_gem_clflush_object(struct drm_i915_gem_object *obj, bool force);
> int __must_check i915_gem_object_finish_gpu(struct drm_i915_gem_object *obj);
> int __must_check i915_gem_init(struct drm_device *dev);
> +int i915_gem_init_rings(struct drm_device *dev);
> int __must_check i915_gem_init_hw(struct drm_device *dev);
> int i915_gem_l3_remap(struct intel_engine_cs *ring, int slice);
> void i915_gem_init_swizzling(struct drm_device *dev);
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index d8bf4fa..6544286 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -4518,7 +4518,7 @@ i915_gem_stop_ringbuffers(struct drm_device *dev)
> int i;
>
> for_each_ring(ring, dev_priv, i)
> - intel_stop_ring_buffer(ring);
> + dev_priv->gt.stop_ring(ring);
> }
>
> int
> @@ -4635,7 +4635,7 @@ intel_enable_blt(struct drm_device *dev)
> return true;
> }
>
> -static int i915_gem_init_rings(struct drm_device *dev)
> +int i915_gem_init_rings(struct drm_device *dev)
> {
> struct drm_i915_private *dev_priv = dev->dev_private;
> int ret;
> @@ -4718,7 +4718,7 @@ i915_gem_init_hw(struct drm_device *dev)
>
> i915_gem_init_swizzling(dev);
>
> - ret = i915_gem_init_rings(dev);
> + ret = dev_priv->gt.init_rings(dev);
> if (ret)
> return ret;
>
> @@ -4759,6 +4759,13 @@ int i915_gem_init(struct drm_device *dev)
> DRM_DEBUG_DRIVER("allow wake ack timed out\n");
> }
>
> + if (!i915.enable_execlists) {
> + dev_priv->gt.d
Re: [Intel-gfx] [PATCH 15/43] drm/i915/bdw: Generic logical ring init and cleanup
On Thu, Jul 24, 2014 at 05:04:23PM +0100, Thomas Daniel wrote:
> From: Oscar Mateo
>
> Allocate and populate the default LRC for every ring, call
> gen-specific init/cleanup, init/fini the command parser and
> set the status page (now inside the LRC object). These are
> things all engines/rings have in common.
>
> Stopping the ring before cleanup and initializing the seqnos
> is left as a TODO task (we need more infrastructure in place
> before we can achieve this).
>
> v2: Check the ringbuffer backing obj for ring_is_initialized,
> instead of the context backing obj (similar, but not exactly
> the same).
>
> Signed-off-by: Oscar Mateo
> ---
> drivers/gpu/drm/i915/i915_gem_context.c |4 ---
> drivers/gpu/drm/i915/intel_lrc.c| 54
> +--
> drivers/gpu/drm/i915/intel_ringbuffer.c | 17 ++
> drivers/gpu/drm/i915/intel_ringbuffer.h |6 +---
> 4 files changed, 70 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
> b/drivers/gpu/drm/i915/i915_gem_context.c
> index 288f5de..9085ff1 100644
> --- a/drivers/gpu/drm/i915/i915_gem_context.c
> +++ b/drivers/gpu/drm/i915/i915_gem_context.c
> @@ -450,10 +450,6 @@ int i915_gem_context_init(struct drm_device *dev)
>
> /* NB: RCS will hold a ref for all rings */
> ring->default_context = ctx;
> -
> - /* FIXME: we really only want to do this for initialized rings
> */
> - if (i915.enable_execlists)
> - intel_lr_context_deferred_create(ctx, ring);
Ah, here we go ;-)
> }
>
> DRM_DEBUG_DRIVER("%s context support initialized\n",
> diff --git a/drivers/gpu/drm/i915/intel_lrc.c
> b/drivers/gpu/drm/i915/intel_lrc.c
> index cb56bb8..05b7069 100644
> --- a/drivers/gpu/drm/i915/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/intel_lrc.c
> @@ -108,12 +108,60 @@ void intel_logical_ring_stop(struct intel_engine_cs
> *ring)
>
> void intel_logical_ring_cleanup(struct intel_engine_cs *ring)
> {
> - /* TODO */
> + if (!intel_ring_initialized(ring))
> + return;
> +
> + /* TODO: make sure the ring is stopped */
> + ring->preallocated_lazy_request = NULL;
> + ring->outstanding_lazy_seqno = 0;
> +
> + if (ring->cleanup)
> + ring->cleanup(ring);
> +
> + i915_cmd_parser_fini_ring(ring);
> +
> + if (ring->status_page.obj) {
> + kunmap(sg_page(ring->status_page.obj->pages->sgl));
> + ring->status_page.obj = NULL;
> + }
> }
>
> static int logical_ring_init(struct drm_device *dev, struct intel_engine_cs
> *ring)
> {
> - /* TODO */
> + int ret;
> + struct intel_context *dctx = ring->default_context;
> + struct drm_i915_gem_object *dctx_obj;
> +
> + /* Intentionally left blank. */
> + ring->buffer = NULL;
> +
> + ring->dev = dev;
> + INIT_LIST_HEAD(&ring->active_list);
> + INIT_LIST_HEAD(&ring->request_list);
> + init_waitqueue_head(&ring->irq_queue);
> +
> + ret = intel_lr_context_deferred_create(dctx, ring);
> + if (ret)
> + return ret;
> +
> + /* The status page is offset 0 from the context object in LRCs. */
> + dctx_obj = dctx->engine[ring->id].state;
> + ring->status_page.gfx_addr = i915_gem_obj_ggtt_offset(dctx_obj);
> + ring->status_page.page_addr = kmap(sg_page(dctx_obj->pages->sgl));
> + if (ring->status_page.page_addr == NULL)
> + return -ENOMEM;
> + ring->status_page.obj = dctx_obj;
> +
> + ret = i915_cmd_parser_init_ring(ring);
> + if (ret)
> + return ret;
> +
> + if (ring->init) {
> + ret = ring->init(ring);
> + if (ret)
> + return ret;
> + }
> +
> return 0;
> }
>
> @@ -397,6 +445,8 @@ int intel_lr_context_deferred_create(struct intel_context
> *ctx,
> int ret;
>
> BUG_ON(ctx->legacy_hw_ctx.rcs_state != NULL);
> + if (ctx->engine[ring->id].state)
> + return 0;
>
> context_size = round_up(get_lr_context_size(ring), 4096);
>
> diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
> b/drivers/gpu/drm/i915/intel_ringbuffer.c
> index 279dda4..20eb1a4 100644
> --- a/drivers/gpu/drm/i915/intel_ringbuffer.c
> +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
> @@ -40,6 +40,23 @@
> */
> #define CACHELINE_BYTES 64
>
> +bool
> +intel_ring_initialized(struct intel_engine_cs *ring)
> +{
> + struct drm_device *dev = ring->dev;
> +
> + if (!dev)
> + return false;
> +
> + if (i915.enable_execlists) {
> + struct intel_context *dctx = ring->default_context;
> + struct intel_ringbuffer *ringbuf =
> dctx->engine[ring->id].ringbuf;
> +
> + return ringbuf->obj;
> + } else
> + return ring->buffer && ring->buffer->obj;
> +}
Looks like I'll not regret having ditched gt.ring_is_initialized.
-Daniel
> +
> static inline int __ring_space(int head,
Re: [Intel-gfx] [PATCH] drm/i915: fix plane/cursor handling when runtime suspended
On Mon, Aug 11, 2014 at 11:29:21AM -0300, Paulo Zanoni wrote:
> 2014-08-11 8:32 GMT-03:00 Ville Syrjälä :
> > On Wed, Aug 06, 2014 at 06:26:01PM -0300, Paulo Zanoni wrote:
> >> From: Paulo Zanoni
> >>
> >> If we're runtime suspended and try to use the plane interfaces, we
> >> will get a lot of WARNs saying we did the wrong thing.
> >>
> >> For intel_crtc_update_cursor(), all we need to do is return if the
> >> CRTC is not active, since writing the registers won't really have any
> >> effect if the screen is not visible, and we will write the registers
> >> later when enabling the screen.
> >>
> >> For all the other cases, we need to get runtime PM references to
> >> pin/unpin the objects, and to change the fences. The pin/unpin
> >> functions are the ideal places for this, but
> >> intel_crtc_cursor_set_obj() doesn't call them, so we also have to add
> >> get/put calls inside it. There is no problem if we runtime suspend
> >> right after these functions are finished, because the registers
> >> weitten are forwarded to system memory.
> >>
> >> v2: - Narrow the put/get calls on intel_crtc_cursor_set_obj() (Daniel)
> >> v3: - Make get/put also surround the fence and unpin calls (Daniel and
> >> Ville).
> >> - Merge all the plane changes into a single patch since they're
> >> the same fix.
> >> - Add the comment requested by Daniel.
> >>
> >> Testcase: igt/pm_rpm/cursor
> >> Testcase: igt/pm_rpm/cursor-dpms
> >> Testcase: igt/pm_rpm/legacy-planes
> >> Testcase: igt/pm_rpm/legacy-planes-dpms
> >> Testcase: igt/pm_rpm/universal-planes
> >> Testcase: igt/pm_rpm/universal-planes-dpms
> >> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=81645
> >> Cc: sta...@vger.kernel.org
> >> Signed-off-by: Paulo Zanoni
> >> ---
> >> drivers/gpu/drm/i915/intel_display.c | 39
> >> +++-
> >> 1 file changed, 38 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/intel_display.c
> >> b/drivers/gpu/drm/i915/intel_display.c
> >> index 4f659eb..a86d67c 100644
> >> --- a/drivers/gpu/drm/i915/intel_display.c
> >> +++ b/drivers/gpu/drm/i915/intel_display.c
> >> @@ -2212,6 +2212,15 @@ intel_pin_and_fence_fb_obj(struct drm_device *dev,
> >> if (need_vtd_wa(dev) && alignment < 256 * 1024)
> >> alignment = 256 * 1024;
> >>
> >> + /*
> >> + * Global gtt pte registers are special registers which actually
> >> forward
> >> + * writes to a chunk of system memory. Which means that there is no
> >> risk
> >> + * that the register values disappear as soon as we call
> >> + * intel_runtime_pm_put(), so it is correct to wrap only the
> >> + * pin/unpin/fence and not more.
> >> + */
> >> + intel_runtime_pm_get(dev_priv);
> >> +
> >> dev_priv->mm.interruptible = false;
> >> ret = i915_gem_object_pin_to_display_plane(obj, alignment,
> >> pipelined);
> >> if (ret)
> >> @@ -2229,21 +2238,30 @@ intel_pin_and_fence_fb_obj(struct drm_device *dev,
> >> i915_gem_object_pin_fence(obj);
> >>
> >> dev_priv->mm.interruptible = true;
> >> + intel_runtime_pm_put(dev_priv);
> >> return 0;
> >>
> >> err_unpin:
> >> i915_gem_object_unpin_from_display_plane(obj);
> >> err_interruptible:
> >> dev_priv->mm.interruptible = true;
> >> + intel_runtime_pm_put(dev_priv);
> >> return ret;
> >> }
> >>
> >> void intel_unpin_fb_obj(struct drm_i915_gem_object *obj)
> >> {
> >> - WARN_ON(!mutex_is_locked(&obj->base.dev->struct_mutex));
> >> + struct drm_device *dev = obj->base.dev;
> >> + struct drm_i915_private *dev_priv = dev->dev_private;
> >> +
> >> + WARN_ON(!mutex_is_locked(&dev->struct_mutex));
> >> +
> >> + intel_runtime_pm_get(dev_priv);
> >>
> >> i915_gem_object_unpin_fence(obj);
> >> i915_gem_object_unpin_from_display_plane(obj);
> >> +
> >> + intel_runtime_pm_put(dev_priv);
> >
> > I don't think we touch the hardware during unpin so these aren't
> > strictly needed.
> >
>
> Daniel requested them.
>
>
> >> }
> >>
> >> /* Computes the linear offset to the base tile and adjusts x, y. bytes
> >> per pixel
> >> @@ -8285,6 +8303,9 @@ static void intel_crtc_update_cursor(struct drm_crtc
> >> *crtc,
> >> if (base == 0 && intel_crtc->cursor_base == 0)
> >> return;
> >>
> >> + if (!intel_crtc->active)
> >> + return;
> >> +
> >
> > Did you actually manage to get by the base==0 check above with a
> > disabled pipe? I don't think this should happen.
>
> Yes, since we enabled runtime suspend during DPMS. Remember that
> crtc->active != crtc->enabled.
Then I think there's a bug somewhere a bit earlier. We should consider
the cursor to be invisible when crtc->active==false. That's how we deal
with all other planes.
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-g
Re: [Intel-gfx] [PATCH 13/43] drm/i915: Abstract the legacy workload submission mechanism away
On Thu, Jul 24, 2014 at 05:04:21PM +0100, Thomas Daniel wrote: > @@ -1408,8 +1408,8 @@ i915_gem_do_execbuffer(struct drm_device *dev, void > *data, > else > exec_start += i915_gem_obj_offset(batch_obj, vm); > > - ret = legacy_ringbuffer_submission(dev, file, ring, ctx, > - args, &eb->vmas, batch_obj, exec_start, flags); > + ret = dev_priv->gt.do_execbuf(dev, file, ring, ctx, args, > + &eb->vmas, batch_obj, exec_start, flags); Also misaligned and too long line here. Fixed, too. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 13/43] drm/i915: Abstract the legacy workload submission mechanism away
On Mon, Aug 11, 2014 at 04:36:53PM +0200, Daniel Vetter wrote:
> On Thu, Jul 24, 2014 at 05:04:21PM +0100, Thomas Daniel wrote:
> > From: Oscar Mateo
> >
> > As suggested by Daniel Vetter. The idea, in subsequent patches, is to
> > provide an alternative to these vfuncs for the Execlists submission
> > mechanism.
> >
> > v2: Splitted into two and reordered to illustrate our intentions, instead
> > of showing it off. Also, remove the add_request vfunc and added the
> > stop_ring one.
> >
> > Signed-off-by: Oscar Mateo
> > ---
> > drivers/gpu/drm/i915/i915_drv.h| 24
> > drivers/gpu/drm/i915/i915_gem.c| 15 +++
> > drivers/gpu/drm/i915/i915_gem_execbuffer.c | 20 ++--
> > 3 files changed, 45 insertions(+), 14 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index ff2c373..1caed52 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -1617,6 +1617,21 @@ struct drm_i915_private {
> > /* Old ums support infrastructure, same warning applies. */
> > struct i915_ums_state ums;
> >
> > + /* Abstract the submission mechanism (legacy ringbuffer or execlists)
> > away */
> > + struct {
> > + int (*do_execbuf) (struct drm_device *dev, struct drm_file
> > *file,
> > + struct intel_engine_cs *ring,
> > + struct intel_context *ctx,
> > + struct drm_i915_gem_execbuffer2 *args,
> > + struct list_head *vmas,
> > + struct drm_i915_gem_object *batch_obj,
> > + u64 exec_start, u32 flags);
> > + int (*init_rings) (struct drm_device *dev);
> > + void (*cleanup_ring) (struct intel_engine_cs *ring);
> > + void (*stop_ring) (struct intel_engine_cs *ring);
>
> My rule of thumb is that with just one caller it's probably better to not
> have a vtable - just makes it harder to follow the code flow.
>
> Usually (with non-borked code design at least) init/teardown functions
> have only one caller, so there's a good chance I'll ask you to remove them
> again.
Also checkpatch (and my eyes!) where unhappy about the space you've put
between ) and (. Fixed that too.
-Daniel
>
> > + bool (*is_ring_initialized) (struct intel_engine_cs *ring);
>
> This one is unused and I didn't really like the taste of it. So I killed
> it.
> -Daniel
>
> > + } gt;
> > +
> > /*
> > * NOTE: This is the dri1/ums dungeon, don't add stuff here. Your patch
> > * will be rejected. Instead look for a better place.
> > @@ -2224,6 +2239,14 @@ int i915_gem_set_domain_ioctl(struct drm_device
> > *dev, void *data,
> > struct drm_file *file_priv);
> > int i915_gem_sw_finish_ioctl(struct drm_device *dev, void *data,
> > struct drm_file *file_priv);
> > +int i915_gem_ringbuffer_submission(struct drm_device *dev,
> > + struct drm_file *file,
> > + struct intel_engine_cs *ring,
> > + struct intel_context *ctx,
> > + struct drm_i915_gem_execbuffer2 *args,
> > + struct list_head *vmas,
> > + struct drm_i915_gem_object *batch_obj,
> > + u64 exec_start, u32 flags);
> > int i915_gem_execbuffer(struct drm_device *dev, void *data,
> > struct drm_file *file_priv);
> > int i915_gem_execbuffer2(struct drm_device *dev, void *data,
> > @@ -2376,6 +2399,7 @@ void i915_gem_reset(struct drm_device *dev);
> > bool i915_gem_clflush_object(struct drm_i915_gem_object *obj, bool force);
> > int __must_check i915_gem_object_finish_gpu(struct drm_i915_gem_object
> > *obj);
> > int __must_check i915_gem_init(struct drm_device *dev);
> > +int i915_gem_init_rings(struct drm_device *dev);
> > int __must_check i915_gem_init_hw(struct drm_device *dev);
> > int i915_gem_l3_remap(struct intel_engine_cs *ring, int slice);
> > void i915_gem_init_swizzling(struct drm_device *dev);
> > diff --git a/drivers/gpu/drm/i915/i915_gem.c
> > b/drivers/gpu/drm/i915/i915_gem.c
> > index d8bf4fa..6544286 100644
> > --- a/drivers/gpu/drm/i915/i915_gem.c
> > +++ b/drivers/gpu/drm/i915/i915_gem.c
> > @@ -4518,7 +4518,7 @@ i915_gem_stop_ringbuffers(struct drm_device *dev)
> > int i;
> >
> > for_each_ring(ring, dev_priv, i)
> > - intel_stop_ring_buffer(ring);
> > + dev_priv->gt.stop_ring(ring);
> > }
> >
> > int
> > @@ -4635,7 +4635,7 @@ intel_enable_blt(struct drm_device *dev)
> > return true;
> > }
> >
> > -static int i915_gem_init_rings(struct drm_device *dev)
> > +int i915_gem_init_rings(struct drm_device *dev)
> > {
> > struct drm_i915_private *dev_p
Re: [Intel-gfx] [PATCH 13/43] drm/i915: Abstract the legacy workload submission mechanism away
On Thu, Jul 24, 2014 at 05:04:21PM +0100, Thomas Daniel wrote:
> From: Oscar Mateo
>
> As suggested by Daniel Vetter. The idea, in subsequent patches, is to
> provide an alternative to these vfuncs for the Execlists submission
> mechanism.
>
> v2: Splitted into two and reordered to illustrate our intentions, instead
> of showing it off. Also, remove the add_request vfunc and added the
> stop_ring one.
>
> Signed-off-by: Oscar Mateo
> ---
> drivers/gpu/drm/i915/i915_drv.h| 24
> drivers/gpu/drm/i915/i915_gem.c| 15 +++
> drivers/gpu/drm/i915/i915_gem_execbuffer.c | 20 ++--
> 3 files changed, 45 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index ff2c373..1caed52 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1617,6 +1617,21 @@ struct drm_i915_private {
> /* Old ums support infrastructure, same warning applies. */
> struct i915_ums_state ums;
>
> + /* Abstract the submission mechanism (legacy ringbuffer or execlists)
> away */
> + struct {
> + int (*do_execbuf) (struct drm_device *dev, struct drm_file
> *file,
> +struct intel_engine_cs *ring,
> +struct intel_context *ctx,
> +struct drm_i915_gem_execbuffer2 *args,
> +struct list_head *vmas,
> +struct drm_i915_gem_object *batch_obj,
> +u64 exec_start, u32 flags);
> + int (*init_rings) (struct drm_device *dev);
> + void (*cleanup_ring) (struct intel_engine_cs *ring);
> + void (*stop_ring) (struct intel_engine_cs *ring);
My rule of thumb is that with just one caller it's probably better to not
have a vtable - just makes it harder to follow the code flow.
Usually (with non-borked code design at least) init/teardown functions
have only one caller, so there's a good chance I'll ask you to remove them
again.
> + bool (*is_ring_initialized) (struct intel_engine_cs *ring);
This one is unused and I didn't really like the taste of it. So I killed
it.
-Daniel
> + } gt;
> +
> /*
>* NOTE: This is the dri1/ums dungeon, don't add stuff here. Your patch
>* will be rejected. Instead look for a better place.
> @@ -2224,6 +2239,14 @@ int i915_gem_set_domain_ioctl(struct drm_device *dev,
> void *data,
> struct drm_file *file_priv);
> int i915_gem_sw_finish_ioctl(struct drm_device *dev, void *data,
>struct drm_file *file_priv);
> +int i915_gem_ringbuffer_submission(struct drm_device *dev,
> +struct drm_file *file,
> +struct intel_engine_cs *ring,
> +struct intel_context *ctx,
> +struct drm_i915_gem_execbuffer2 *args,
> +struct list_head *vmas,
> +struct drm_i915_gem_object *batch_obj,
> +u64 exec_start, u32 flags);
> int i915_gem_execbuffer(struct drm_device *dev, void *data,
> struct drm_file *file_priv);
> int i915_gem_execbuffer2(struct drm_device *dev, void *data,
> @@ -2376,6 +2399,7 @@ void i915_gem_reset(struct drm_device *dev);
> bool i915_gem_clflush_object(struct drm_i915_gem_object *obj, bool force);
> int __must_check i915_gem_object_finish_gpu(struct drm_i915_gem_object *obj);
> int __must_check i915_gem_init(struct drm_device *dev);
> +int i915_gem_init_rings(struct drm_device *dev);
> int __must_check i915_gem_init_hw(struct drm_device *dev);
> int i915_gem_l3_remap(struct intel_engine_cs *ring, int slice);
> void i915_gem_init_swizzling(struct drm_device *dev);
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index d8bf4fa..6544286 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -4518,7 +4518,7 @@ i915_gem_stop_ringbuffers(struct drm_device *dev)
> int i;
>
> for_each_ring(ring, dev_priv, i)
> - intel_stop_ring_buffer(ring);
> + dev_priv->gt.stop_ring(ring);
> }
>
> int
> @@ -4635,7 +4635,7 @@ intel_enable_blt(struct drm_device *dev)
> return true;
> }
>
> -static int i915_gem_init_rings(struct drm_device *dev)
> +int i915_gem_init_rings(struct drm_device *dev)
> {
> struct drm_i915_private *dev_priv = dev->dev_private;
> int ret;
> @@ -4718,7 +4718,7 @@ i915_gem_init_hw(struct drm_device *dev)
>
> i915_gem_init_swizzling(dev);
>
> - ret = i915_gem_init_rings(dev);
> + ret = dev_priv->gt.init_rings(dev);
> if (ret)
> return ret;
>
> @@ -4759,6 +4759,13 @@ int i915_gem_init(str
Re: [Intel-gfx] [PATCH 12/43] drm/i915/bdw: Don't write PDP in the legacy way when using LRCs
On Thu, Aug 07, 2014 at 01:17:40PM +0100, Thomas Daniel wrote:
> From: Oscar Mateo
>
> This is mostly for correctness so that we know we are running the LR
> context correctly (this is, the PDPs are contained inside the context
> object).
>
> v2: Move the check to inside the enable PPGTT function. The switch
> happens in two places: the legacy context switch (that we won't hit
> when Execlists are enabled) and the PPGTT enable, which unfortunately
> we need. This would look much nicer if the ppgtt->enable was part of
> the ring init, where it logically belongs.
>
> v3: Move the check to the start of the enable PPGTT function. None
> of the legacy PPGTT enabling is required when using LRCs as the
> PPGTT is enabled in the context descriptor and the PDPs are written
> in the LRC.
>
> Signed-off-by: Oscar Mateo
> Signed-off-by: Thomas Daniel
> ---
> drivers/gpu/drm/i915/i915_gem_gtt.c |5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
> b/drivers/gpu/drm/i915/i915_gem_gtt.c
> index 5188936..cfbf272 100644
> --- a/drivers/gpu/drm/i915/i915_gem_gtt.c
> +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
> @@ -843,6 +843,11 @@ static int gen8_ppgtt_enable(struct i915_hw_ppgtt *ppgtt)
> struct intel_engine_cs *ring;
> int j, ret;
>
> + /* In the case of Execlists, we don't want to write the PDPs
This comment is misleading since you now also disable the ppgtt enable bit
setting. Not that the code disabled in v2 of this patch is for aliasing
ppgtt mode only anyway, so irrelevant for execlist mode. Aside: A few
patches from myself will clear this up a bit better.
As-is this just looks confusing, so I'll punt for now.
-Daniel
> + * in the legacy way (they live inside the context now) */
> + if (i915.enable_execlists)
> + return 0;
> +
> for_each_ring(ring, dev_priv, j) {
> I915_WRITE(RING_MODE_GEN7(ring),
> _MASKED_BIT_ENABLE(GFX_PPGTT_ENABLE));
> --
> 1.7.9.5
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: fix plane/cursor handling when runtime suspended
From: Paulo Zanoni
If we're runtime suspended and try to use the plane interfaces, we
will get a lot of WARNs saying we did the wrong thing.
For intel_crtc_update_cursor(), all we need to do is return if the
CRTC is not active, since writing the registers won't really have any
effect if the screen is not visible, and we will write the registers
later when enabling the screen.
For all the other cases, we need to get runtime PM references to
pin/unpin the objects, and to change the fences. The pin/unpin
functions are the ideal places for this, but
intel_crtc_cursor_set_obj() doesn't call them, so we also have to add
get/put calls inside it. There is no problem if we runtime suspend
right after these functions are finished, because the registers
weitten are forwarded to system memory.
v2: - Narrow the put/get calls on intel_crtc_cursor_set_obj() (Daniel)
v3: - Make get/put also surround the fence and unpin calls (Daniel and
Ville).
- Merge all the plane changes into a single patch since they're
the same fix.
- Add the comment requested by Daniel.
v4: - Remove spurious whitespace (Ville).
Testcase: igt/pm_rpm/cursor
Testcase: igt/pm_rpm/cursor-dpms
Testcase: igt/pm_rpm/legacy-planes
Testcase: igt/pm_rpm/legacy-planes-dpms
Testcase: igt/pm_rpm/universal-planes
Testcase: igt/pm_rpm/universal-planes-dpms
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=81645
Cc: sta...@vger.kernel.org
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_display.c | 38 +++-
1 file changed, 37 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index e9b578e..4e1c957 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2149,6 +2149,15 @@ intel_pin_and_fence_fb_obj(struct drm_device *dev,
if (need_vtd_wa(dev) && alignment < 256 * 1024)
alignment = 256 * 1024;
+ /*
+* Global gtt pte registers are special registers which actually forward
+* writes to a chunk of system memory. Which means that there is no risk
+* that the register values disappear as soon as we call
+* intel_runtime_pm_put(), so it is correct to wrap only the
+* pin/unpin/fence and not more.
+*/
+ intel_runtime_pm_get(dev_priv);
+
dev_priv->mm.interruptible = false;
ret = i915_gem_object_pin_to_display_plane(obj, alignment, pipelined);
if (ret)
@@ -2166,21 +2175,30 @@ intel_pin_and_fence_fb_obj(struct drm_device *dev,
i915_gem_object_pin_fence(obj);
dev_priv->mm.interruptible = true;
+ intel_runtime_pm_put(dev_priv);
return 0;
err_unpin:
i915_gem_object_unpin_from_display_plane(obj);
err_interruptible:
dev_priv->mm.interruptible = true;
+ intel_runtime_pm_put(dev_priv);
return ret;
}
void intel_unpin_fb_obj(struct drm_i915_gem_object *obj)
{
- WARN_ON(!mutex_is_locked(&obj->base.dev->struct_mutex));
+ struct drm_device *dev = obj->base.dev;
+ struct drm_i915_private *dev_priv = dev->dev_private;
+
+ WARN_ON(!mutex_is_locked(&dev->struct_mutex));
+
+ intel_runtime_pm_get(dev_priv);
i915_gem_object_unpin_fence(obj);
i915_gem_object_unpin_from_display_plane(obj);
+
+ intel_runtime_pm_put(dev_priv);
}
/* Computes the linear offset to the base tile and adjusts x, y. bytes per
pixel
@@ -8154,6 +8172,9 @@ static void intel_crtc_update_cursor(struct drm_crtc
*crtc,
if (base == 0 && intel_crtc->cursor_base == 0)
return;
+ if (!intel_crtc->active)
+ return;
+
I915_WRITE(CURPOS(pipe), pos);
if (IS_IVYBRIDGE(dev) || IS_HASWELL(dev) || IS_BROADWELL(dev))
@@ -8209,6 +8230,16 @@ static int intel_crtc_cursor_set_obj(struct drm_crtc
*crtc,
/* we only need to pin inside GTT if cursor is non-phy */
mutex_lock(&dev->struct_mutex);
+
+ /*
+* Global gtt pte registers are special registers which actually forward
+* writes to a chunk of system memory. Which means that there is no risk
+* that the register values disappear as soon as we call
+* intel_runtime_pm_put(), so it is correct to wrap only the
+* pin/unpin/fence and not more.
+*/
+ intel_runtime_pm_get(dev_priv);
+
if (!INTEL_INFO(dev)->cursor_needs_physical) {
unsigned alignment;
@@ -8261,6 +8292,10 @@ static int intel_crtc_cursor_set_obj(struct drm_crtc
*crtc,
i915_gem_track_fb(intel_crtc->cursor_bo, obj,
INTEL_FRONTBUFFER_CURSOR(pipe));
+
+ if (obj)
+ intel_runtime_pm_put(dev_priv);
+
mutex_unlock(&dev->struct_mutex);
old_width = intel_crtc->cursor_width;
@@ -8282,6 +8317,7 @@ static int intel_crtc_cursor_set_obj(struct drm_crtc
*crtc,
fail_unpin:
i915_gem_object_un
Re: [Intel-gfx] [PATCH] drm/i915: WARN if module opt sanitization goes out of order
On Mon, Aug 11, 2014 at 03:59:52PM +0200, Daniel Vetter wrote:
> Depending upon one module option to be sanitized (through USES_PPGTT)
> for the other is a bit too fragile for my taste. At least WARN about
> this.
>
> Cc: Ben Widawsky
> Cc: Damien Lespiau
> Cc: Oscar Mateo
> Signed-off-by: Daniel Vetter
Sounds like a safety measure we'd want. Until we try to fix these kind
of dependencies in a more adequate manner that is.
Reviewed-by: Damien Lespiau
--
Damien
> ---
> drivers/gpu/drm/i915/intel_lrc.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_lrc.c
> b/drivers/gpu/drm/i915/intel_lrc.c
> index 21f7f1cce86e..44721292eb77 100644
> --- a/drivers/gpu/drm/i915/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/intel_lrc.c
> @@ -43,6 +43,8 @@
>
> int intel_sanitize_enable_execlists(struct drm_device *dev, int
> enable_execlists)
> {
> + WARN_ON(i915.enable_ppgtt == -1);
> +
> if (enable_execlists == 0)
> return 0;
>
> --
> 2.0.1
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 11/43] drm/i915/bdw: Render moot context reset and switch with Execlists
On Thu, Jul 24, 2014 at 05:04:19PM +0100, Thomas Daniel wrote:
> From: Oscar Mateo
>
> These two functions make no sense in an Logical Ring Context & Execlists
> world.
>
> v2: We got rid of lrc_enabled and centralized everything in the sanitized
> i915.enbale_execlists instead.
>
> Signed-off-by: Oscar Mateo
> ---
> drivers/gpu/drm/i915/i915_gem_context.c |9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
> b/drivers/gpu/drm/i915/i915_gem_context.c
> index fbe7278..288f5de 100644
> --- a/drivers/gpu/drm/i915/i915_gem_context.c
> +++ b/drivers/gpu/drm/i915/i915_gem_context.c
> @@ -380,6 +380,9 @@ void i915_gem_context_reset(struct drm_device *dev)
> struct drm_i915_private *dev_priv = dev->dev_private;
> int i;
>
> + if (i915.enable_execlists)
> + return;
This will conflict badly with Alistair's patch at a functional level. I'm
pretty sure that we want _some_ form of reset for the context state, since
the hw didn't just magically load the previously running context. So NACK
on this hunk.
> +
> /* Prevent the hardware from restoring the last context (which hung) on
>* the next switch */
> for (i = 0; i < I915_NUM_RINGS; i++) {
> @@ -514,6 +517,9 @@ int i915_gem_context_enable(struct drm_i915_private
> *dev_priv)
> ppgtt->enable(ppgtt);
> }
>
> + if (i915.enable_execlists)
> + return 0;
Again this conflicts with Alistair's patch. Furthermore it looks redudant
since you no-op out i915_switch_context separately.
> +
> /* FIXME: We should make this work, even in reset */
> if (i915_reset_in_progress(&dev_priv->gpu_error))
> return 0;
> @@ -769,6 +775,9 @@ int i915_switch_context(struct intel_engine_cs *ring,
> {
> struct drm_i915_private *dev_priv = ring->dev->dev_private;
>
> + if (i915.enable_execlists)
> + return 0;
I've hoped we don't need this with the legacy ringbuffer cmdsubmission
fuly split out. If there are other paths (resume, gpu reset) where this
comes into play then I guess we need to look at where the best place is to
make this call. So until this comes with a bit a better justification I'll
punt on this for now.
-Daniel
> +
> WARN_ON(!mutex_is_locked(&dev_priv->dev->struct_mutex));
>
> if (to->legacy_hw_ctx.rcs_state == NULL) { /* We have the fake context
> */
> --
> 1.7.9.5
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: fix plane/cursor handling when runtime suspended
2014-08-11 8:32 GMT-03:00 Ville Syrjälä :
> On Wed, Aug 06, 2014 at 06:26:01PM -0300, Paulo Zanoni wrote:
>> From: Paulo Zanoni
>>
>> If we're runtime suspended and try to use the plane interfaces, we
>> will get a lot of WARNs saying we did the wrong thing.
>>
>> For intel_crtc_update_cursor(), all we need to do is return if the
>> CRTC is not active, since writing the registers won't really have any
>> effect if the screen is not visible, and we will write the registers
>> later when enabling the screen.
>>
>> For all the other cases, we need to get runtime PM references to
>> pin/unpin the objects, and to change the fences. The pin/unpin
>> functions are the ideal places for this, but
>> intel_crtc_cursor_set_obj() doesn't call them, so we also have to add
>> get/put calls inside it. There is no problem if we runtime suspend
>> right after these functions are finished, because the registers
>> weitten are forwarded to system memory.
>>
>> v2: - Narrow the put/get calls on intel_crtc_cursor_set_obj() (Daniel)
>> v3: - Make get/put also surround the fence and unpin calls (Daniel and
>> Ville).
>> - Merge all the plane changes into a single patch since they're
>> the same fix.
>> - Add the comment requested by Daniel.
>>
>> Testcase: igt/pm_rpm/cursor
>> Testcase: igt/pm_rpm/cursor-dpms
>> Testcase: igt/pm_rpm/legacy-planes
>> Testcase: igt/pm_rpm/legacy-planes-dpms
>> Testcase: igt/pm_rpm/universal-planes
>> Testcase: igt/pm_rpm/universal-planes-dpms
>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=81645
>> Cc: sta...@vger.kernel.org
>> Signed-off-by: Paulo Zanoni
>> ---
>> drivers/gpu/drm/i915/intel_display.c | 39
>> +++-
>> 1 file changed, 38 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_display.c
>> b/drivers/gpu/drm/i915/intel_display.c
>> index 4f659eb..a86d67c 100644
>> --- a/drivers/gpu/drm/i915/intel_display.c
>> +++ b/drivers/gpu/drm/i915/intel_display.c
>> @@ -2212,6 +2212,15 @@ intel_pin_and_fence_fb_obj(struct drm_device *dev,
>> if (need_vtd_wa(dev) && alignment < 256 * 1024)
>> alignment = 256 * 1024;
>>
>> + /*
>> + * Global gtt pte registers are special registers which actually
>> forward
>> + * writes to a chunk of system memory. Which means that there is no
>> risk
>> + * that the register values disappear as soon as we call
>> + * intel_runtime_pm_put(), so it is correct to wrap only the
>> + * pin/unpin/fence and not more.
>> + */
>> + intel_runtime_pm_get(dev_priv);
>> +
>> dev_priv->mm.interruptible = false;
>> ret = i915_gem_object_pin_to_display_plane(obj, alignment, pipelined);
>> if (ret)
>> @@ -2229,21 +2238,30 @@ intel_pin_and_fence_fb_obj(struct drm_device *dev,
>> i915_gem_object_pin_fence(obj);
>>
>> dev_priv->mm.interruptible = true;
>> + intel_runtime_pm_put(dev_priv);
>> return 0;
>>
>> err_unpin:
>> i915_gem_object_unpin_from_display_plane(obj);
>> err_interruptible:
>> dev_priv->mm.interruptible = true;
>> + intel_runtime_pm_put(dev_priv);
>> return ret;
>> }
>>
>> void intel_unpin_fb_obj(struct drm_i915_gem_object *obj)
>> {
>> - WARN_ON(!mutex_is_locked(&obj->base.dev->struct_mutex));
>> + struct drm_device *dev = obj->base.dev;
>> + struct drm_i915_private *dev_priv = dev->dev_private;
>> +
>> + WARN_ON(!mutex_is_locked(&dev->struct_mutex));
>> +
>> + intel_runtime_pm_get(dev_priv);
>>
>> i915_gem_object_unpin_fence(obj);
>> i915_gem_object_unpin_from_display_plane(obj);
>> +
>> + intel_runtime_pm_put(dev_priv);
>
> I don't think we touch the hardware during unpin so these aren't
> strictly needed.
>
Daniel requested them.
>> }
>>
>> /* Computes the linear offset to the base tile and adjusts x, y. bytes per
>> pixel
>> @@ -8285,6 +8303,9 @@ static void intel_crtc_update_cursor(struct drm_crtc
>> *crtc,
>> if (base == 0 && intel_crtc->cursor_base == 0)
>> return;
>>
>> + if (!intel_crtc->active)
>> + return;
>> +
>
> Did you actually manage to get by the base==0 check above with a
> disabled pipe? I don't think this should happen.
Yes, since we enabled runtime suspend during DPMS. Remember that
crtc->active != crtc->enabled.
To hit this return, just run "sudo ./pm_rpm --run-subtest cursor-dpms".
>
>> I915_WRITE(CURPOS(pipe), pos);
>>
>> if (IS_IVYBRIDGE(dev) || IS_HASWELL(dev) || IS_BROADWELL(dev))
>> @@ -8340,9 +8361,20 @@ static int intel_crtc_cursor_set_obj(struct drm_crtc
>> *crtc,
>>
>> /* we only need to pin inside GTT if cursor is non-phy */
>> mutex_lock(&dev->struct_mutex);
>> +
>> + /*
>> + * Global gtt pte registers are special registers which actually
>> forward
>> + * writes to a chunk of system memory. Which means that there is no
>> risk
>> + * that the register values disappear as soon as we call
>> +
Re: [Intel-gfx] [PATCH 10/43] drm/i915/bdw: Deferred creation of user-created LRCs
On Thu, Jul 24, 2014 at 05:04:18PM +0100, Thomas Daniel wrote:
> From: Oscar Mateo
>
> The backing objects and ringbuffers for contexts created via open
> fd are actually empty until the user starts sending execbuffers to
> them. At that point, we allocate & populate them. We do this because,
> at create time, we really don't know which engine is going to be used
> with the context later on (and we don't want to waste memory on
> objects that we might never use).
>
> v2: As contexts created via ioctl can only be used with the render
> ring, we have enough information to allocate & populate them right
> away.
>
> v3: Defer the creation always, even with ioctl-created contexts, as
> requested by Daniel Vetter.
>
> Signed-off-by: Oscar Mateo
This patch seems to miss the hunk to remove
/* FIXME: we really only want to do this for initialized rings
*/
if (i915.enable_execlists)
intel_lr_context_deferred_create(ctx, ring);
Also I just realized that that code completely lacks error handling.
If it's not already there please quickly submit a fixup patch.
-Daniel
> ---
> drivers/gpu/drm/i915/i915_gem_context.c|7 +++
> drivers/gpu/drm/i915/i915_gem_execbuffer.c |8
> 2 files changed, 11 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
> b/drivers/gpu/drm/i915/i915_gem_context.c
> index 48d7476..fbe7278 100644
> --- a/drivers/gpu/drm/i915/i915_gem_context.c
> +++ b/drivers/gpu/drm/i915/i915_gem_context.c
> @@ -784,9 +784,9 @@ int i915_switch_context(struct intel_engine_cs *ring,
> return do_switch(ring, to);
> }
>
> -static bool hw_context_enabled(struct drm_device *dev)
> +static bool contexts_enabled(struct drm_device *dev)
> {
> - return to_i915(dev)->hw_context_size;
> + return i915.enable_execlists || to_i915(dev)->hw_context_size;
> }
>
> int i915_gem_context_create_ioctl(struct drm_device *dev, void *data,
> @@ -797,8 +797,7 @@ int i915_gem_context_create_ioctl(struct drm_device *dev,
> void *data,
> struct intel_context *ctx;
> int ret;
>
> - /* FIXME: allow user-created LR contexts as well */
> - if (!hw_context_enabled(dev))
> + if (!contexts_enabled(dev))
> return -ENODEV;
>
> ret = i915_mutex_lock_interruptible(dev);
> diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> index c5115957..4e9b387 100644
> --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> @@ -951,6 +951,14 @@ i915_gem_validate_context(struct drm_device *dev, struct
> drm_file *file,
> return ERR_PTR(-EIO);
> }
>
> + if (i915.enable_execlists && !ctx->engine[ring->id].state) {
> + int ret = intel_lr_context_deferred_create(ctx, ring);
> + if (ret) {
> + DRM_DEBUG("Could not create LRC %u: %d\n", ctx_id, ret);
> + return ERR_PTR(ret);
> + }
> + }
> +
> return ctx;
> }
>
> --
> 1.7.9.5
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 08/43] drm/i915/bdw: Add a context and an engine pointers to the ringbuffer
On Mon, Aug 11, 2014 at 04:14:13PM +0200, Daniel Vetter wrote:
> On Thu, Jul 24, 2014 at 05:04:16PM +0100, Thomas Daniel wrote:
> > From: Oscar Mateo
> >
> > Any given ringbuffer is unequivocally tied to one context and one engine.
> > By setting the appropriate pointers to them, the ringbuffer struct holds
> > all the infromation you might need to submit a workload for processing,
> > Execlists style.
> >
> > Signed-off-by: Oscar Mateo
> > ---
> > drivers/gpu/drm/i915/intel_lrc.c|2 ++
> > drivers/gpu/drm/i915/intel_ringbuffer.c |2 ++
> > drivers/gpu/drm/i915/intel_ringbuffer.h |3 +++
> > 3 files changed, 7 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_lrc.c
> > b/drivers/gpu/drm/i915/intel_lrc.c
> > index 0a12b8c..2eb7db6 100644
> > --- a/drivers/gpu/drm/i915/intel_lrc.c
> > +++ b/drivers/gpu/drm/i915/intel_lrc.c
> > @@ -132,6 +132,8 @@ int intel_lr_context_deferred_create(struct
> > intel_context *ctx,
> > return ret;
> > }
> >
> > + ringbuf->ring = ring;
> > + ringbuf->ctx = ctx;
> > ringbuf->size = 32 * PAGE_SIZE;
> > ringbuf->effective_size = ringbuf->size;
> > ringbuf->head = 0;
> > diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
> > b/drivers/gpu/drm/i915/intel_ringbuffer.c
> > index 01e9840..279dda4 100644
> > --- a/drivers/gpu/drm/i915/intel_ringbuffer.c
> > +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
> > @@ -1570,6 +1570,8 @@ static int intel_init_ring_buffer(struct drm_device
> > *dev,
> > INIT_LIST_HEAD(&ring->active_list);
> > INIT_LIST_HEAD(&ring->request_list);
> > ringbuf->size = 32 * PAGE_SIZE;
> > + ringbuf->ring = ring;
> > + ringbuf->ctx = ring->default_context;
>
> That doesn't make a terribly lot of sense tbh. I fear it's one of these
> slight confusions which will take tons of patches to clean up. Why exactly
> do we need the ring->ctx pointer?
>
> If we only need this for lrc I want to name it accordingly, to make sure
> legacy code doesn't grow stupid ideas. And also we should only initialize
> this in the lrc ctx init then.
>
> All patches up to this one merged.
Ok, I've discussed this quickly with Damien on irc. We decided to cut away
the ring->ctx part of this patch for now to be able to move on.
-Daniel
> -Daniel
>
> > memset(ring->semaphore.sync_seqno, 0,
> > sizeof(ring->semaphore.sync_seqno));
> >
> > init_waitqueue_head(&ring->irq_queue);
> > diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h
> > b/drivers/gpu/drm/i915/intel_ringbuffer.h
> > index 053d004..be40788 100644
> > --- a/drivers/gpu/drm/i915/intel_ringbuffer.h
> > +++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
> > @@ -88,6 +88,9 @@ struct intel_ringbuffer {
> > struct drm_i915_gem_object *obj;
> > void __iomem *virtual_start;
> >
> > + struct intel_engine_cs *ring;
> > + struct intel_context *ctx;
> > +
> > u32 head;
> > u32 tail;
> > int space;
> > --
> > 1.7.9.5
> >
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 08/43] drm/i915/bdw: Add a context and an engine pointers to the ringbuffer
On Thu, Jul 24, 2014 at 05:04:16PM +0100, Thomas Daniel wrote:
> From: Oscar Mateo
>
> Any given ringbuffer is unequivocally tied to one context and one engine.
> By setting the appropriate pointers to them, the ringbuffer struct holds
> all the infromation you might need to submit a workload for processing,
> Execlists style.
>
> Signed-off-by: Oscar Mateo
> ---
> drivers/gpu/drm/i915/intel_lrc.c|2 ++
> drivers/gpu/drm/i915/intel_ringbuffer.c |2 ++
> drivers/gpu/drm/i915/intel_ringbuffer.h |3 +++
> 3 files changed, 7 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_lrc.c
> b/drivers/gpu/drm/i915/intel_lrc.c
> index 0a12b8c..2eb7db6 100644
> --- a/drivers/gpu/drm/i915/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/intel_lrc.c
> @@ -132,6 +132,8 @@ int intel_lr_context_deferred_create(struct intel_context
> *ctx,
> return ret;
> }
>
> + ringbuf->ring = ring;
> + ringbuf->ctx = ctx;
> ringbuf->size = 32 * PAGE_SIZE;
> ringbuf->effective_size = ringbuf->size;
> ringbuf->head = 0;
> diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
> b/drivers/gpu/drm/i915/intel_ringbuffer.c
> index 01e9840..279dda4 100644
> --- a/drivers/gpu/drm/i915/intel_ringbuffer.c
> +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
> @@ -1570,6 +1570,8 @@ static int intel_init_ring_buffer(struct drm_device
> *dev,
> INIT_LIST_HEAD(&ring->active_list);
> INIT_LIST_HEAD(&ring->request_list);
> ringbuf->size = 32 * PAGE_SIZE;
> + ringbuf->ring = ring;
> + ringbuf->ctx = ring->default_context;
That doesn't make a terribly lot of sense tbh. I fear it's one of these
slight confusions which will take tons of patches to clean up. Why exactly
do we need the ring->ctx pointer?
If we only need this for lrc I want to name it accordingly, to make sure
legacy code doesn't grow stupid ideas. And also we should only initialize
this in the lrc ctx init then.
All patches up to this one merged.
-Daniel
> memset(ring->semaphore.sync_seqno, 0,
> sizeof(ring->semaphore.sync_seqno));
>
> init_waitqueue_head(&ring->irq_queue);
> diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h
> b/drivers/gpu/drm/i915/intel_ringbuffer.h
> index 053d004..be40788 100644
> --- a/drivers/gpu/drm/i915/intel_ringbuffer.h
> +++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
> @@ -88,6 +88,9 @@ struct intel_ringbuffer {
> struct drm_i915_gem_object *obj;
> void __iomem *virtual_start;
>
> + struct intel_engine_cs *ring;
> + struct intel_context *ctx;
> +
> u32 head;
> u32 tail;
> int space;
> --
> 1.7.9.5
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 04/43] drm/i915/bdw: Initialization for Logical Ring Contexts
On Thu, Jul 24, 2014 at 05:04:12PM +0100, Thomas Daniel wrote:
> From: Oscar Mateo
>
> For the moment this is just a placeholder, but it shows one of the
> main differences between the good ol' HW contexts and the shiny
> new Logical Ring Contexts: LR contexts allocate and free their
> own backing objects. Another difference is that the allocation is
> deferred (as the create function name suggests), but that does not
> happen in this patch yet, because for the moment we are only dealing
> with the default context.
>
> Early in the series we had our own gen8_gem_context_init/fini
> functions, but the truth is they now look almost the same as the
> legacy hw context init/fini functions. We can always split them
> later if this ceases to be the case.
>
> Also, we do not fall back to legacy ringbuffers when logical ring
> context initialization fails (not very likely to happen and, even
> if it does, hw contexts would probably fail as well).
>
> v2: Daniel says "explain, do not showcase".
>
> Signed-off-by: Oscar Mateo
> ---
> drivers/gpu/drm/i915/i915_gem_context.c | 29 +++--
> drivers/gpu/drm/i915/intel_lrc.c| 15 +++
> drivers/gpu/drm/i915/intel_lrc.h|5 +
> 3 files changed, 43 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
> b/drivers/gpu/drm/i915/i915_gem_context.c
> index de72a28..718150e 100644
> --- a/drivers/gpu/drm/i915/i915_gem_context.c
> +++ b/drivers/gpu/drm/i915/i915_gem_context.c
> @@ -182,7 +182,10 @@ void i915_gem_context_free(struct kref *ctx_ref)
> typeof(*ctx), ref);
> struct i915_hw_ppgtt *ppgtt = NULL;
>
> - if (ctx->legacy_hw_ctx.rcs_state) {
> + if (i915.enable_execlists) {
> + ppgtt = ctx_to_ppgtt(ctx);
> + intel_lr_context_free(ctx);
> + } else if (ctx->legacy_hw_ctx.rcs_state) {
> /* We refcount even the aliasing PPGTT to keep the code
> symmetric */
> if (USES_PPGTT(ctx->legacy_hw_ctx.rcs_state->base.dev))
> ppgtt = ctx_to_ppgtt(ctx);
> @@ -419,7 +422,11 @@ int i915_gem_context_init(struct drm_device *dev)
> if (WARN_ON(dev_priv->ring[RCS].default_context))
> return 0;
>
> - if (HAS_HW_CONTEXTS(dev)) {
> + if (i915.enable_execlists) {
> + /* NB: intentionally left blank. We will allocate our own
> + * backing objects as we need them, thank you very much */
> + dev_priv->hw_context_size = 0;
> + } else if (HAS_HW_CONTEXTS(dev)) {
> dev_priv->hw_context_size = round_up(get_context_size(dev),
> 4096);
> if (dev_priv->hw_context_size > (1<<20)) {
> DRM_DEBUG_DRIVER("Disabling HW Contexts; invalid size
> %d\n",
> @@ -435,11 +442,20 @@ int i915_gem_context_init(struct drm_device *dev)
> return PTR_ERR(ctx);
> }
>
> - /* NB: RCS will hold a ref for all rings */
> - for (i = 0; i < I915_NUM_RINGS; i++)
> - dev_priv->ring[i].default_context = ctx;
> + for (i = 0; i < I915_NUM_RINGS; i++) {
> + struct intel_engine_cs *ring = &dev_priv->ring[i];
> +
> + /* NB: RCS will hold a ref for all rings */
> + ring->default_context = ctx;
> +
> + /* FIXME: we really only want to do this for initialized rings
> */
> + if (i915.enable_execlists)
> + intel_lr_context_deferred_create(ctx, ring);
> + }
>
> - DRM_DEBUG_DRIVER("%s context support initialized\n",
> dev_priv->hw_context_size ? "HW" : "fake");
> + DRM_DEBUG_DRIVER("%s context support initialized\n",
> + i915.enable_execlists ? "LR" :
> + dev_priv->hw_context_size ? "HW" : "fake");
> return 0;
> }
>
> @@ -781,6 +797,7 @@ int i915_gem_context_create_ioctl(struct drm_device *dev,
> void *data,
> struct intel_context *ctx;
> int ret;
>
> + /* FIXME: allow user-created LR contexts as well */
> if (!hw_context_enabled(dev))
> return -ENODEV;
>
> diff --git a/drivers/gpu/drm/i915/intel_lrc.c
> b/drivers/gpu/drm/i915/intel_lrc.c
> index 21f7f1c..8cc6b55 100644
> --- a/drivers/gpu/drm/i915/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/intel_lrc.c
> @@ -51,3 +51,18 @@ int intel_sanitize_enable_execlists(struct drm_device
> *dev, int enable_execlists
>
> return 0;
> }
> +
> +void intel_lr_context_free(struct intel_context *ctx)
> +{
> + /* TODO */
> +}
> +
> +int intel_lr_context_deferred_create(struct intel_context *ctx,
> + struct intel_engine_cs *ring)
> +{
> + BUG_ON(ctx->legacy_hw_ctx.rcs_state != NULL);
I command thy:
Thou shalt not use BUG_ON except in especially dire circumstances!
Fixed while applying.
-Daniel
> +
> + /* TODO */
> +
> + return 0;
> +}
> diff --git a/drivers/gpu/drm/i91
[Intel-gfx] [PATCH] drm/i915: WARN if module opt sanitization goes out of order
Depending upon one module option to be sanitized (through USES_PPGTT)
for the other is a bit too fragile for my taste. At least WARN about
this.
Cc: Ben Widawsky
Cc: Damien Lespiau
Cc: Oscar Mateo
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_lrc.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 21f7f1cce86e..44721292eb77 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -43,6 +43,8 @@
int intel_sanitize_enable_execlists(struct drm_device *dev, int
enable_execlists)
{
+ WARN_ON(i915.enable_ppgtt == -1);
+
if (enable_execlists == 0)
return 0;
--
2.0.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/4] module: add module_param_unsafe and module_param_named_unsafe
Add the helpers to be used by modules wishing to expose unsafe debugging or testing module parameters that taint the kernel when set. Cc: Rusty Russell Cc: Jean Delvare Cc: Andrew Morton Cc: Li Zhong Cc: Jon Mason Cc: Daniel Vetter Signed-off-by: Jani Nikula --- include/linux/moduleparam.h | 18 ++ 1 file changed, 18 insertions(+) diff --git a/include/linux/moduleparam.h b/include/linux/moduleparam.h index 1e3ffb839daa..9531f9f9729e 100644 --- a/include/linux/moduleparam.h +++ b/include/linux/moduleparam.h @@ -123,6 +123,12 @@ struct kparam_array module_param_named(name, name, type, perm) /** + * module_param_unsafe - same as module_param but taints kernel + */ +#define module_param_unsafe(name, type, perm) \ + module_param_named_unsafe(name, name, type, perm) + +/** * module_param_named - typesafe helper for a renamed module/cmdline parameter * @name: a valid C identifier which is the parameter name. * @value: the actual lvalue to alter. @@ -139,6 +145,14 @@ struct kparam_array __MODULE_PARM_TYPE(name, #type) /** + * module_param_named_unsafe - same as module_param_named but taints kernel + */ +#define module_param_named_unsafe(name, value, type, perm) \ + param_check_##type(name, &(value)); \ + module_param_cb_unsafe(name, ¶m_ops_##type, &value, perm); \ + __MODULE_PARM_TYPE(name, #type) + +/** * module_param_cb - general callback for a module/cmdline parameter * @name: a valid C identifier which is the parameter name. * @ops: the set & get operations for this parameter. @@ -149,6 +163,10 @@ struct kparam_array #define module_param_cb(name, ops, arg, perm)\ __module_param_call(MODULE_PARAM_PREFIX, name, ops, arg, perm, -1, 0) +#define module_param_cb_unsafe(name, ops, arg, perm) \ + __module_param_call(MODULE_PARAM_PREFIX, name, ops, arg, perm, -1,\ + KERNEL_PARAM_FL_UNSAFE) + /** * _param_cb - general callback for a module/cmdline parameter *to be evaluated before certain initcall level -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/4] drm/i915: taint the kernel if unsafe module parameters are set
Taint the kernel if the semaphores, enable_rc6, enable_fbc, or ppgtt module parameters are modified. These module parameters are for debugging and testing only, and should never be changed from their platform specific default values by the users. We do not provide support for people enabling all the experimental features. Make this clear by tainting the kernel if the parameters are set. Signed-off-by: Jani Nikula --- drivers/gpu/drm/i915/i915_params.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_params.c b/drivers/gpu/drm/i915/i915_params.c index 62ee8308d682..bba4225ba575 100644 --- a/drivers/gpu/drm/i915/i915_params.c +++ b/drivers/gpu/drm/i915/i915_params.c @@ -66,12 +66,12 @@ module_param_named(powersave, i915.powersave, int, 0600); MODULE_PARM_DESC(powersave, "Enable powersavings, fbc, downclocking, etc. (default: true)"); -module_param_named(semaphores, i915.semaphores, int, 0400); +module_param_named_unsafe(semaphores, i915.semaphores, int, 0400); MODULE_PARM_DESC(semaphores, "Use semaphores for inter-ring sync " "(default: -1 (use per-chip defaults))"); -module_param_named(enable_rc6, i915.enable_rc6, int, 0400); +module_param_named_unsafe(enable_rc6, i915.enable_rc6, int, 0400); MODULE_PARM_DESC(enable_rc6, "Enable power-saving render C-state 6. " "Different stages can be selected via bitmask values " @@ -79,7 +79,7 @@ MODULE_PARM_DESC(enable_rc6, "For example, 3 would enable rc6 and deep rc6, and 7 would enable everything. " "default: -1 (use per-chip default)"); -module_param_named(enable_fbc, i915.enable_fbc, int, 0600); +module_param_named_unsafe(enable_fbc, i915.enable_fbc, int, 0600); MODULE_PARM_DESC(enable_fbc, "Enable frame buffer compression for power savings " "(default: -1 (use per-chip default))"); @@ -113,7 +113,7 @@ MODULE_PARM_DESC(enable_hangcheck, "WARNING: Disabling this can cause system wide hangs. " "(default: true)"); -module_param_named(enable_ppgtt, i915.enable_ppgtt, int, 0400); +module_param_named_unsafe(enable_ppgtt, i915.enable_ppgtt, int, 0400); MODULE_PARM_DESC(enable_ppgtt, "Override PPGTT usage. " "(-1=auto [default], 0=disabled, 1=aliasing, 2=full)"); -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 03/43] drm/i915/bdw: Macro for LRCs and module option for Execlists
On Thu, Jul 24, 2014 at 05:04:11PM +0100, Thomas Daniel wrote:
> From: Oscar Mateo
>
> GEN8 brings an expansion of the HW contexts: "Logical Ring Contexts".
> These expanded contexts enable a number of new abilities, especially
> "Execlists".
>
> The macro is defined to off until we have things in place to hope to
> work.
>
> v2: Rename "advanced contexts" to the more correct "logical ring
> contexts".
>
> v3: Add a module parameter to enable execlists. Execlist are relatively
> new, and so it'd be wise to be able to switch back to ring submission
> to debug subtle problems that will inevitably arise.
>
> v4: Add an intel_enable_execlists function.
>
> v5: Sanitize early, as suggested by Daniel. Remove lrc_enabled.
>
> Signed-off-by: Ben Widawsky (v1)
> Signed-off-by: Damien Lespiau (v3)
> Signed-off-by: Oscar Mateo (v2, v4 & v5)
> ---
> drivers/gpu/drm/i915/i915_drv.h|2 ++
> drivers/gpu/drm/i915/i915_gem.c|3 +++
> drivers/gpu/drm/i915/i915_params.c |6 ++
> drivers/gpu/drm/i915/intel_lrc.c | 11 +++
> drivers/gpu/drm/i915/intel_lrc.h |3 +++
> 5 files changed, 25 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 54c2bd9..a793d6d 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -2037,6 +2037,7 @@ struct drm_i915_cmd_table {
> #define I915_NEED_GFX_HWS(dev) (INTEL_INFO(dev)->need_gfx_hws)
>
> #define HAS_HW_CONTEXTS(dev) (INTEL_INFO(dev)->gen >= 6)
> +#define HAS_LOGICAL_RING_CONTEXTS(dev) 0
> #define HAS_ALIASING_PPGTT(dev) (INTEL_INFO(dev)->gen >= 6)
> #define HAS_PPGTT(dev) (INTEL_INFO(dev)->gen >= 7 &&
> !IS_GEN8(dev))
> #define USES_PPGTT(dev) intel_enable_ppgtt(dev, false)
> @@ -2122,6 +2123,7 @@ struct i915_params {
> int enable_rc6;
> int enable_fbc;
> int enable_ppgtt;
> + int enable_execlists;
> int enable_psr;
> unsigned int preliminary_hw_support;
> int disable_power_well;
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index e5d4d73..d8bf4fa 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -4746,6 +4746,9 @@ int i915_gem_init(struct drm_device *dev)
> struct drm_i915_private *dev_priv = dev->dev_private;
> int ret;
>
> + i915.enable_execlists = intel_sanitize_enable_execlists(dev,
> + i915.enable_execlists);
The ordering constraint on i915.enabel_ppgtt sanitization is imo
super-fragile. You'll all get a big price (and grumpy maintainer) if this
blows up. I'll add a patch on top to WARN about this.
-Daniel
> +
> mutex_lock(&dev->struct_mutex);
>
> if (IS_VALLEYVIEW(dev)) {
> diff --git a/drivers/gpu/drm/i915/i915_params.c
> b/drivers/gpu/drm/i915/i915_params.c
> index bbdee21..7f0fb72 100644
> --- a/drivers/gpu/drm/i915/i915_params.c
> +++ b/drivers/gpu/drm/i915/i915_params.c
> @@ -35,6 +35,7 @@ struct i915_params i915 __read_mostly = {
> .vbt_sdvo_panel_type = -1,
> .enable_rc6 = -1,
> .enable_fbc = -1,
> + .enable_execlists = -1,
> .enable_hangcheck = true,
> .enable_ppgtt = -1,
> .enable_psr = 1,
> @@ -117,6 +118,11 @@ MODULE_PARM_DESC(enable_ppgtt,
> "Override PPGTT usage. "
> "(-1=auto [default], 0=disabled, 1=aliasing, 2=full)");
>
> +module_param_named(enable_execlists, i915.enable_execlists, int, 0400);
> +MODULE_PARM_DESC(enable_execlists,
> + "Override execlists usage. "
> + "(-1=auto [default], 0=disabled, 1=enabled)");
> +
> module_param_named(enable_psr, i915.enable_psr, int, 0600);
> MODULE_PARM_DESC(enable_psr, "Enable PSR (default: true)");
>
> diff --git a/drivers/gpu/drm/i915/intel_lrc.c
> b/drivers/gpu/drm/i915/intel_lrc.c
> index 49bb6fc..21f7f1c 100644
> --- a/drivers/gpu/drm/i915/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/intel_lrc.c
> @@ -40,3 +40,14 @@
> #include
> #include
> #include "i915_drv.h"
> +
> +int intel_sanitize_enable_execlists(struct drm_device *dev, int
> enable_execlists)
> +{
> + if (enable_execlists == 0)
> + return 0;
> +
> + if (HAS_LOGICAL_RING_CONTEXTS(dev) && USES_PPGTT(dev))
> + return 1;
> +
> + return 0;
> +}
> diff --git a/drivers/gpu/drm/i915/intel_lrc.h
> b/drivers/gpu/drm/i915/intel_lrc.h
> index f6830a4..75ee9c3 100644
> --- a/drivers/gpu/drm/i915/intel_lrc.h
> +++ b/drivers/gpu/drm/i915/intel_lrc.h
> @@ -24,4 +24,7 @@
> #ifndef _INTEL_LRC_H_
> #define _INTEL_LRC_H_
>
> +/* Execlists */
> +int intel_sanitize_enable_execlists(struct drm_device *dev, int
> enable_execlists);
> +
> #endif /* _INTEL_LRC_H_ */
> --
> 1.7.9.5
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365
[Intel-gfx] [PATCH 0/4] module: add support for unsafe, tainting parameters
This is a generic version of Daniel's patch [1] letting us have unsafe module parameters (experimental, debugging, testing, etc.) that taint the kernel when set. Quoting Daniel, """ Users just love to set random piles of options since surely enabling all the experimental stuff helps. Later on we get bug reports because it all fell apart. Even more fun when it's labelled a regression when some change only just made the feature possible (e.g. stolen memory fixes suddenly making fbc possible). Make it clear that users are playing with fire here. """ Patches 1-3 add the core functionality, patch 4 is our use case as an example. BR, Jani. [1] http://lkml.kernel.org/r/1394011994-30604-1-git-send-email-daniel.vet...@ffwll.ch Jani Nikula (4): module: rename KERNEL_PARAM_FL_NOARG to avoid confusion module: make it possible to have unsafe, tainting module params module: add module_param_unsafe and module_param_named_unsafe drm/i915: taint the kernel if unsafe module parameters are set drivers/gpu/drm/i915/i915_params.c | 8 ++--- drivers/tty/serial/8250/8250_core.c | 2 +- include/linux/moduleparam.h | 64 +++-- kernel/module.c | 2 +- kernel/params.c | 17 -- security/apparmor/lsm.c | 4 +-- 6 files changed, 76 insertions(+), 21 deletions(-) -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/4] module: rename KERNEL_PARAM_FL_NOARG to avoid confusion
Make it clear this is about kernel_param_ops, not kernel_param (which
will soon have a flags field of its own). No functional changes.
Cc: Rusty Russell
Cc: Jean Delvare
Cc: Andrew Morton
Cc: Li Zhong
Cc: Jon Mason
Cc: Daniel Vetter
Signed-off-by: Jani Nikula
---
include/linux/moduleparam.h | 2 +-
kernel/module.c | 2 +-
kernel/params.c | 6 +++---
security/apparmor/lsm.c | 4 ++--
4 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/include/linux/moduleparam.h b/include/linux/moduleparam.h
index 494f99e852da..16fdddab856a 100644
--- a/include/linux/moduleparam.h
+++ b/include/linux/moduleparam.h
@@ -42,7 +42,7 @@ struct kernel_param;
* NOARG - the parameter allows for no argument (foo instead of foo=1)
*/
enum {
- KERNEL_PARAM_FL_NOARG = (1 << 0)
+ KERNEL_PARAM_OPS_FL_NOARG = (1 << 0)
};
struct kernel_param_ops {
diff --git a/kernel/module.c b/kernel/module.c
index ae79ce615cb9..c8f04f9bdba0 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -135,7 +135,7 @@ static int param_set_bool_enable_only(const char *val,
}
static const struct kernel_param_ops param_ops_bool_enable_only = {
- .flags = KERNEL_PARAM_FL_NOARG,
+ .flags = KERNEL_PARAM_OPS_FL_NOARG,
.set = param_set_bool_enable_only,
.get = param_get_bool,
};
diff --git a/kernel/params.c b/kernel/params.c
index 34f527023794..8a484fc8bde8 100644
--- a/kernel/params.c
+++ b/kernel/params.c
@@ -104,7 +104,7 @@ static int parse_one(char *param,
return 0;
/* No one handled NULL, so do it here. */
if (!val &&
- !(params[i].ops->flags & KERNEL_PARAM_FL_NOARG))
+ !(params[i].ops->flags & KERNEL_PARAM_OPS_FL_NOARG))
return -EINVAL;
pr_debug("handling %s with %p\n", param,
params[i].ops->set);
@@ -318,7 +318,7 @@ int param_get_bool(char *buffer, const struct kernel_param
*kp)
EXPORT_SYMBOL(param_get_bool);
struct kernel_param_ops param_ops_bool = {
- .flags = KERNEL_PARAM_FL_NOARG,
+ .flags = KERNEL_PARAM_OPS_FL_NOARG,
.set = param_set_bool,
.get = param_get_bool,
};
@@ -369,7 +369,7 @@ int param_set_bint(const char *val, const struct
kernel_param *kp)
EXPORT_SYMBOL(param_set_bint);
struct kernel_param_ops param_ops_bint = {
- .flags = KERNEL_PARAM_FL_NOARG,
+ .flags = KERNEL_PARAM_OPS_FL_NOARG,
.set = param_set_bint,
.get = param_get_int,
};
diff --git a/security/apparmor/lsm.c b/security/apparmor/lsm.c
index 998100093332..65ca451a764d 100644
--- a/security/apparmor/lsm.c
+++ b/security/apparmor/lsm.c
@@ -668,7 +668,7 @@ static int param_set_aabool(const char *val, const struct
kernel_param *kp);
static int param_get_aabool(char *buffer, const struct kernel_param *kp);
#define param_check_aabool param_check_bool
static struct kernel_param_ops param_ops_aabool = {
- .flags = KERNEL_PARAM_FL_NOARG,
+ .flags = KERNEL_PARAM_OPS_FL_NOARG,
.set = param_set_aabool,
.get = param_get_aabool
};
@@ -685,7 +685,7 @@ static int param_set_aalockpolicy(const char *val, const
struct kernel_param *kp
static int param_get_aalockpolicy(char *buffer, const struct kernel_param *kp);
#define param_check_aalockpolicy param_check_bool
static struct kernel_param_ops param_ops_aalockpolicy = {
- .flags = KERNEL_PARAM_FL_NOARG,
+ .flags = KERNEL_PARAM_OPS_FL_NOARG,
.set = param_set_aalockpolicy,
.get = param_get_aalockpolicy
};
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/4] module: make it possible to have unsafe, tainting module params
Add flags field to struct kernel_params, and add the first flag: unsafe
parameter. Modifying a kernel parameter with the unsafe flag set, either
via the kernel command line or sysfs, will issue a warning and taint the
kernel.
Cc: Rusty Russell
Cc: Jean Delvare
Cc: Andrew Morton
Cc: Li Zhong
Cc: Jon Mason
Cc: Daniel Vetter
Signed-off-by: Jani Nikula
---
drivers/tty/serial/8250/8250_core.c | 2 +-
include/linux/moduleparam.h | 44 +
kernel/params.c | 11 ++
3 files changed, 47 insertions(+), 10 deletions(-)
diff --git a/drivers/tty/serial/8250/8250_core.c
b/drivers/tty/serial/8250/8250_core.c
index 1d42dba6121d..bd672948f2f1 100644
--- a/drivers/tty/serial/8250/8250_core.c
+++ b/drivers/tty/serial/8250/8250_core.c
@@ -3587,7 +3587,7 @@ static void __used s8250_options(void)
#ifdef CONFIG_SERIAL_8250_RSA
__module_param_call(MODULE_PARAM_PREFIX, probe_rsa,
¶m_array_ops, .arr = &__param_arr_probe_rsa,
- 0444, -1);
+ 0444, -1, 0);
#endif
}
#else
diff --git a/include/linux/moduleparam.h b/include/linux/moduleparam.h
index 16fdddab856a..1e3ffb839daa 100644
--- a/include/linux/moduleparam.h
+++ b/include/linux/moduleparam.h
@@ -56,11 +56,21 @@ struct kernel_param_ops {
void (*free)(void *arg);
};
+/*
+ * Flags available for kernel_param
+ *
+ * UNSAFE - the parameter is dangerous and setting it will taint the kernel
+ */
+enum {
+ KERNEL_PARAM_FL_UNSAFE = (1 << 0)
+};
+
struct kernel_param {
const char *name;
const struct kernel_param_ops *ops;
u16 perm;
- s16 level;
+ s8 level;
+ u8 flags;
union {
void *arg;
const struct kparam_string *str;
@@ -137,7 +147,7 @@ struct kparam_array
* The ops can have NULL set or get functions.
*/
#define module_param_cb(name, ops, arg, perm)\
- __module_param_call(MODULE_PARAM_PREFIX, name, ops, arg, perm, -1)
+ __module_param_call(MODULE_PARAM_PREFIX, name, ops, arg, perm, -1, 0)
/**
* _param_cb - general callback for a module/cmdline parameter
@@ -149,7 +159,7 @@ struct kparam_array
* The ops can have NULL set or get functions.
*/
#define __level_param_cb(name, ops, arg, perm, level) \
- __module_param_call(MODULE_PARAM_PREFIX, name, ops, arg, perm, level)
+ __module_param_call(MODULE_PARAM_PREFIX, name, ops, arg, perm, level, 0)
#define core_param_cb(name, ops, arg, perm)\
__level_param_cb(name, ops, arg, perm, 1)
@@ -184,14 +194,14 @@ struct kparam_array
/* This is the fundamental function for registering boot/module
parameters. */
-#define __module_param_call(prefix, name, ops, arg, perm, level) \
+#define __module_param_call(prefix, name, ops, arg, perm, level, flags)
\
/* Default value instead of permissions? */ \
static const char __param_str_##name[] = prefix #name; \
static struct kernel_param __moduleparam_const __param_##name \
__used \
__attribute__ ((unused,__section__ ("__param"),aligned(sizeof(void * \
= { __param_str_##name, ops, VERIFY_OCTAL_PERMISSIONS(perm),\
- level, { arg } }
+ level, flags, { arg } }
/* Obsolete - use module_param_cb() */
#define module_param_call(name, set, get, arg, perm) \
@@ -199,7 +209,7 @@ struct kparam_array
{ 0, (void *)set, (void *)get };\
__module_param_call(MODULE_PARAM_PREFIX,\
name, &__param_ops_##name, arg, \
- (perm) + sizeof(__check_old_set_param(set))*0, -1)
+ (perm) + sizeof(__check_old_set_param(set))*0, -1,
0)
/* We don't get oldget: it's often a new-style param_get_uint, etc. */
static inline int
@@ -279,7 +289,7 @@ static inline void __kernel_param_unlock(void)
*/
#define core_param(name, var, type, perm) \
param_check_##type(name, &(var)); \
- __module_param_call("", name, ¶m_ops_##type, &var, perm, -1)
+ __module_param_call("", name, ¶m_ops_##type, &var, perm, -1, 0)
#endif /* !MODULE */
/**
@@ -297,7 +307,7 @@ static inline void __kernel_param_unlock(void)
= { len, string }; \
__module_param_call(MODULE_PARAM_PREFIX, name, \
¶m_ops_string, \
- .str = &__param_string_##name, perm, -1); \
+ .str = &__param_string_##name, perm, -1, 0);\
__MODULE_PARM_TYPE(name, "string")
/**
@@ -346,6 +356,22 @@ static inline void destroy_params(const struct
k
Re: [Intel-gfx] xrandr issue
Hi When you have this type of question, please always CC our mailing list, since you're more likely to get a fast answer when using it. And it also helps documenting all the common problems people have. 2014-08-09 13:31 GMT-03:00 Brayden Williams : > Hi Paulo, > > I have been desperately trying to get my 3 monitor setup to work with Intel > graphics in Ubuntu. After hours of Googling I finally came across your > comment on this bug report > (https://bugs.freedesktop.org/show_bug.cgi?id=68485) but I am still having > trouble getting it working. Ubuntu gives me the following error: > > [4.700920] [drm:intel_ddi_pll_mode_set] *ERROR* No WRPLLs available! > > The output of my xrandr --verbose command can be found at > https://gist.github.com/redstar504/6b630e3e664d0db6a2f5 > > It seems like the pixel clock is the same for HDMI1 and HDMI2 so this should > be working shouldn't it? Yes, it should be working, but only if you have a Kernel that actually contains the patch mentioned in the bugzilla. Which Kernel version are you running? You could also try to set things manually after you boot: xrandr --output HDMI1 --mode 0x4a xrandr --output HDMI2 --mode 0x4a xrandr --output HDMI3 --mode 0x4a If your Kernel is old, you could try to use the DP or VGA outputs instead of using HDMI for every port. DId you try to use any newer Kernels? If this problem happens with the latest development or stable Kernels, you should probably open another bug (or reopen the one you mentioned). > > I'd truly appreciate any help you can provide. > > Thank You, > Brayden Williams -- Paulo Zanoni ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm: Fix drm_crtc vs. drm_plane type bug in plane->reset() handling
On Mon, Aug 11, 2014 at 03:12:34PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> s/struct drm_crtc/struct drm_plane/ in drm_mode_config_reset() so that we
> actually dereference the correct type of structure when calling the
> plane->reset() hook.
>
> Imre mentioned that his VLV was crashing there on resume. I deciced to have
> a quick look at the code and immediately spotted the problem.
>
> The problem was introduced when the plane->reset() hook was added here:
> commit 2aaa4b6f6f6be8c23de8ae60ee30e5d6059c3c64
> Author: Daniel Vetter
> Date: Tue Jul 29 15:32:37 2014 +0200
>
> drm: Add a plane->reset hook
>
> Cc: Daniel Vetter
> Signed-off-by: Ville Syrjälä
Oops, thanks for tracking this down. Squashed into the relevant commit in
topic/core-stuff.
-Daniel
> ---
> drivers/gpu/drm/drm_crtc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 23c9c9f..f09b752 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -4664,7 +4664,7 @@ out:
> void drm_mode_config_reset(struct drm_device *dev)
> {
> struct drm_crtc *crtc;
> - struct drm_crtc *plane;
> + struct drm_plane *plane;
> struct drm_encoder *encoder;
> struct drm_connector *connector;
>
> --
> 1.8.5.5
>
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 5/6] drm/i915: Add 180 degree primary plane rotation support
On Mon, Aug 11, 2014 at 05:37:20PM +0530, Jindal, Sonika wrote:
>
>
> On 8/11/2014 5:12 PM, Daniel Vetter wrote:
> >On Mon, Aug 11, 2014 at 04:37:00PM +0530, Jindal, Sonika wrote:
> >>
> >>Hi Daniel,
> >>Are you taking this patch back in drm-intel?
> >
> >We should still call the primary_plane->update hook directly instead of
> >open-coding it.
> >-Daniel
> >
> But we are already doing dev_priv->display.update_primary_plane. Can you
> please elaborate? Last time we had a discussion on this same point, and we
> thought for some platforms more work might be needed but for current
> platforms this looks ok. Following was the discussion:
That's a different cook used internally in the driver (mostly for
historical reasons nowadays). I'm talking about the
drm_plane->fops->update_plane hook, which is implemented for primary
planes by intel_primary_plane_setplane.
The idea is to have the exact same code flow as for sprite planes, since
once we have atomic modesets that will be what we need. In the sprite
set_prop function you pretty directly call the update_plane hook, and I
think we should do the same here. Actually we might as well directly reuse
the intel_plane_restore function, it seems to exactly do what we want.
> "> >Also Chris mentioned that on some platforms this won't work and it's
> > >more future-proof to just do a full modeset until we have the proper
> > >infrastructure.
> > >
> > Can you please elaborate on this? What needs to be done?
>
> Apparently nothing, it turned out that on the platforms currently supported
> everything is fine with your patch. Damien promised to follow up with the
> details on internal mailing lists.
Damien follow up internally. Since we're now allowed to talk about skl
I'll paste this here:
"On SKL, for 90/270, we'll also need to update the watermarks and remap
the fb.
"We already duplicate some of the logic: the FBC update, wait for
pending flips, ...
"So maybe we should try to find a way to take the same path for all
updates. I'm not too sure how practical this is though."
Damien also said that he doesn't want to still the series on this, but
since we now have universal plane support for the primary plane I think it
makes a lot of sense.
-Daniel
> -Daniel
> "
>
> >>
> >>-Sonika
> >>
> >>On 8/7/2014 5:41 PM, Daniel Vetter wrote:
> >>>On Thu, Aug 07, 2014 at 01:45:31PM +0200, Daniel Vetter wrote:
> On Tue, Jul 15, 2014 at 11:11:37AM +0200, Daniel Vetter wrote:
> >On Tue, Jul 15, 2014 at 02:10:28PM +0530, sonika.jin...@intel.com wrote:
> >>+ /* FBC does not work on some platforms for rotated
> >>planes */
> >>+ if (INTEL_INFO(dev)->gen <= 4 && !IS_G4X(dev)) {
> >>+ if (dev_priv->fbc.plane ==
> >>intel_crtc->plane &&
> >>+ intel_plane->rotation !=
> >>BIT(DRM_ROTATE_0))
> >>+ intel_disable_fbc(dev);
> >>+ /* If rotation was set earlier and new rotation
> >>is 0,
> >>+ we might have disabled fbc earlier. So update
> >>it now */
> >>+ else if (intel_plane->rotation ==
> >>BIT(DRM_ROTATE_0)
> >>+ && old_val !=
> >>BIT(DRM_ROTATE_0)) {
> >>+ mutex_lock(&dev->struct_mutex);
> >>+ intel_update_fbc(dev);
> >>+
> >>mutex_unlock(&dev->struct_mutex);
> >>+ }
> >>+ }
> >
> >Indentation is screwed up here. Also if we convert some of the checks
> >into
> >early bails we could de-indent this by one level.
> >
> >Also Chris mentioned that on some platforms this won't work and it's more
> >future-proof to just do a full modeset until we have the proper
> >infrastructure.
>
> Apparently this review here was never addressed, as Chris just pointed out
> on irc. I've dropped the patch again.
>
> I think we need:
> - The same sequence as with the sprite set_property function, i.e. we need
> to call the update_plane function (not the raw low-level one, the
> high-level with all the checks).
> - The fbc check is wrong and will miss updates when the crtc is off. We
> need to move this into the general list of checks in intel_update_fbc.
> - Since this seems to be buggy I want added testcases to combine fbc
> correctness with screen rotation. Probably best to reuse the existing
> fbc testcase and add a bunch or rotated tests.
> >>>
> >>>Ok, the check in update_fbc is there, I've been blind. Sorry about all the
> >>>confusion. So just amounts of calling the higher level function and we can
> >>>forgo the fbc testing.
> >>>-Daniel
> >>>
> >
--
Daniel Vetter
Software Engineer, Inte
Re: [Intel-gfx] [PATCH 4/4] drm/i915: Simplify relocate_entry_gtt() and make 64-bit safe
On Sun, Aug 10, 2014 at 06:29:11AM +0100, Chris Wilson wrote:
> Even though we should not try to use 4+GiB GTTs on 32-bit systems, by
> using a local variable we can future proof the code whilst making it
> easier to read.
>
> Signed-off-by: Chris Wilson
Appeased checkpatch a bit for the long lines and pulled this in with the
other patches from this series, except the likely/unlikely one.
Thanks, Daniel
> ---
> drivers/gpu/drm/i915/i915_gem_execbuffer.c | 23 ++-
> 1 file changed, 10 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> index e6fcd0594bd5..5c04f77f8a66 100644
> --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> @@ -302,7 +302,7 @@ relocate_entry_gtt(struct drm_i915_gem_object *obj,
> struct drm_device *dev = obj->base.dev;
> struct drm_i915_private *dev_priv = dev->dev_private;
> uint64_t delta = reloc->delta + target_offset;
> - uint32_t __iomem *reloc_entry;
> + uint64_t offset;
> void __iomem *reloc_page;
> int ret;
>
> @@ -315,25 +315,22 @@ relocate_entry_gtt(struct drm_i915_gem_object *obj,
> return ret;
>
> /* Map the page containing the relocation we're going to perform. */
> - reloc->offset += i915_gem_obj_ggtt_offset(obj);
> + offset = i915_gem_obj_ggtt_offset(obj);
> + offset += reloc->offset;
> reloc_page = io_mapping_map_atomic_wc(dev_priv->gtt.mappable,
> - reloc->offset & PAGE_MASK);
> - reloc_entry = (uint32_t __iomem *)
> - (reloc_page + offset_in_page(reloc->offset));
> - iowrite32(lower_32_bits(delta), reloc_entry);
> + offset & PAGE_MASK);
> + iowrite32(lower_32_bits(delta), reloc_page + offset_in_page(offset));
>
> if (INTEL_INFO(dev)->gen >= 8) {
> - reloc_entry += 1;
> + offset += sizeof(uint32_t);
>
> - if (offset_in_page(reloc->offset + sizeof(uint32_t)) == 0) {
> + if (offset_in_page(offset) == 0) {
> io_mapping_unmap_atomic(reloc_page);
> - reloc_page = io_mapping_map_atomic_wc(
> - dev_priv->gtt.mappable,
> - reloc->offset + sizeof(uint32_t));
> - reloc_entry = reloc_page;
> + reloc_page =
> io_mapping_map_atomic_wc(dev_priv->gtt.mappable,
> + offset);
> }
>
> - iowrite32(upper_32_bits(delta), reloc_entry);
> + iowrite32(upper_32_bits(delta), reloc_page +
> offset_in_page(offset));
> }
>
> io_mapping_unmap_atomic(reloc_page);
> --
> 2.1.0.rc1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm: Fix drm_crtc vs. drm_plane type bug in plane->reset() handling
From: Ville Syrjälä
s/struct drm_crtc/struct drm_plane/ in drm_mode_config_reset() so that we
actually dereference the correct type of structure when calling the
plane->reset() hook.
Imre mentioned that his VLV was crashing there on resume. I deciced to have
a quick look at the code and immediately spotted the problem.
The problem was introduced when the plane->reset() hook was added here:
commit 2aaa4b6f6f6be8c23de8ae60ee30e5d6059c3c64
Author: Daniel Vetter
Date: Tue Jul 29 15:32:37 2014 +0200
drm: Add a plane->reset hook
Cc: Daniel Vetter
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_crtc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 23c9c9f..f09b752 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -4664,7 +4664,7 @@ out:
void drm_mode_config_reset(struct drm_device *dev)
{
struct drm_crtc *crtc;
- struct drm_crtc *plane;
+ struct drm_plane *plane;
struct drm_encoder *encoder;
struct drm_connector *connector;
--
1.8.5.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/4] drm/i915: Mark the execbuffer validation failures as unlikely
On Sun, Aug 10, 2014 at 06:29:09AM +0100, Chris Wilson wrote:
> This just allows the compiler to pessimise callers who try to abuse the
> ioctl in the hope of making the correct users faster.
>
> Signed-off-by: Chris Wilson
I'm not that much of a fan of likely/unlikely really. If it helps with
documenting code then I'm ok, but mass-sprinkling looks like too much.
For this case here I think an unlikely on the return value of
validate_exec_list is about all I want to stomach. gcc should reach all
the other conclusions itself.
-Daniel
> ---
> drivers/gpu/drm/i915/i915_gem_execbuffer.c | 36
> +-
> 1 file changed, 15 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> index 4304d8b9e17c..0ba1e7bbd09d 100644
> --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> @@ -870,41 +870,38 @@ i915_gem_execbuffer_move_to_gpu(struct intel_engine_cs
> *ring,
> return intel_ring_invalidate_all_caches(ring);
> }
>
> -static bool
> -i915_gem_check_execbuffer(struct drm_i915_gem_execbuffer2 *exec)
> -{
> - if (exec->flags & __I915_EXEC_UNKNOWN_FLAGS)
> - return false;
> -
> - return ((exec->batch_start_offset | exec->batch_len) & 0x7) == 0;
> -}
> -
> static int
> validate_exec_list(struct drm_device *dev,
> -struct drm_i915_gem_exec_object2 *exec,
> -int count)
> +const struct drm_i915_gem_execbuffer2 *args,
> +const struct drm_i915_gem_exec_object2 *exec)
> {
> unsigned relocs_total = 0;
> unsigned relocs_max = UINT_MAX / sizeof(struct
> drm_i915_gem_relocation_entry);
> unsigned invalid_flags;
> int i;
>
> + if (unlikely(args->flags & __I915_EXEC_UNKNOWN_FLAGS))
> + return -EINVAL;
> +
> + if (unlikely((args->batch_start_offset | args->batch_len) & 0x7))
> + return -EINVAL;
> +
> invalid_flags = __EXEC_OBJECT_UNKNOWN_FLAGS;
> if (USES_FULL_PPGTT(dev))
> invalid_flags |= EXEC_OBJECT_NEEDS_GTT;
>
> - for (i = 0; i < count; i++) {
> + for (i = 0; i < args->buffer_count; i++) {
> char __user *ptr = to_user_ptr(exec[i].relocs_ptr);
> int length; /* limited by fault_in_pages_readable() */
>
> - if (exec[i].flags & invalid_flags)
> + if (unlikely(exec[i].flags & invalid_flags))
> return -EINVAL;
>
> /* First check for malicious input causing overflow in
>* the worst case where we need to allocate the entire
>* relocation tree as a single array.
>*/
> - if (exec[i].relocation_count > relocs_max - relocs_total)
> + if (unlikely(exec[i].relocation_count > relocs_max -
> relocs_total))
> return -EINVAL;
> relocs_total += exec[i].relocation_count;
>
> @@ -915,11 +912,11 @@ validate_exec_list(struct drm_device *dev,
>* to read, but since we may need to update the presumed
>* offsets during execution, check for full write access.
>*/
> - if (!access_ok(VERIFY_WRITE, ptr, length))
> + if (unlikely(!access_ok(VERIFY_WRITE, ptr, length)))
> return -EFAULT;
>
> if (likely(!i915.prefault_disable)) {
> - if (fault_in_multipages_readable(ptr, length))
> + if (unlikely(fault_in_multipages_readable(ptr, length)))
> return -EFAULT;
> }
> }
> @@ -1256,11 +1253,8 @@ i915_gem_do_execbuffer(struct drm_device *dev, void
> *data,
> int ret;
> bool need_relocs;
>
> - if (!i915_gem_check_execbuffer(args))
> - return -EINVAL;
> -
> - ret = validate_exec_list(dev, exec, args->buffer_count);
> - if (ret)
> + ret = validate_exec_list(dev, args, exec);
> + if (unlikely(ret))
> return ret;
>
> flags = 0;
> --
> 2.1.0.rc1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 5/6] drm/i915: Add 180 degree primary plane rotation support
On 8/11/2014 5:12 PM, Daniel Vetter wrote:
On Mon, Aug 11, 2014 at 04:37:00PM +0530, Jindal, Sonika wrote:
Hi Daniel,
Are you taking this patch back in drm-intel?
We should still call the primary_plane->update hook directly instead of
open-coding it.
-Daniel
But we are already doing dev_priv->display.update_primary_plane. Can you
please elaborate? Last time we had a discussion on this same point, and
we thought for some platforms more work might be needed but for current
platforms this looks ok. Following was the discussion:
"> >Also Chris mentioned that on some platforms this won't work and it's
> >more future-proof to just do a full modeset until we have the proper
> >infrastructure.
> >
> Can you please elaborate on this? What needs to be done?
Apparently nothing, it turned out that on the platforms currently
supported everything is fine with your patch. Damien promised to follow
up with the details on internal mailing lists.
-Daniel
"
-Sonika
On 8/7/2014 5:41 PM, Daniel Vetter wrote:
On Thu, Aug 07, 2014 at 01:45:31PM +0200, Daniel Vetter wrote:
On Tue, Jul 15, 2014 at 11:11:37AM +0200, Daniel Vetter wrote:
On Tue, Jul 15, 2014 at 02:10:28PM +0530, sonika.jin...@intel.com wrote:
+ /* FBC does not work on some platforms for rotated planes */
+ if (INTEL_INFO(dev)->gen <= 4 && !IS_G4X(dev)) {
+ if (dev_priv->fbc.plane == intel_crtc->plane &&
+ intel_plane->rotation != BIT(DRM_ROTATE_0))
+ intel_disable_fbc(dev);
+ /* If rotation was set earlier and new rotation is 0,
+ we might have disabled fbc earlier. So update it now */
+ else if (intel_plane->rotation ==
BIT(DRM_ROTATE_0)
+ && old_val != BIT(DRM_ROTATE_0)) {
+ mutex_lock(&dev->struct_mutex);
+ intel_update_fbc(dev);
+ mutex_unlock(&dev->struct_mutex);
+ }
+ }
Indentation is screwed up here. Also if we convert some of the checks into
early bails we could de-indent this by one level.
Also Chris mentioned that on some platforms this won't work and it's more
future-proof to just do a full modeset until we have the proper
infrastructure.
Apparently this review here was never addressed, as Chris just pointed out
on irc. I've dropped the patch again.
I think we need:
- The same sequence as with the sprite set_property function, i.e. we need
to call the update_plane function (not the raw low-level one, the
high-level with all the checks).
- The fbc check is wrong and will miss updates when the crtc is off. We
need to move this into the general list of checks in intel_update_fbc.
- Since this seems to be buggy I want added testcases to combine fbc
correctness with screen rotation. Probably best to reuse the existing
fbc testcase and add a bunch or rotated tests.
Ok, the check in update_fbc is there, I've been blind. Sorry about all the
confusion. So just amounts of calling the higher level function and we can
forgo the fbc testing.
-Daniel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Fix secure dispatch with full ppgtt
On Mon, Aug 11, 2014 at 12:35:42PM +0100, Chris Wilson wrote: > On Mon, Aug 11, 2014 at 01:22:19PM +0200, Daniel Vetter wrote: > > On Mon, Aug 11, 2014 at 11:17:40AM +0100, Chris Wilson wrote: > > > On Mon, Aug 11, 2014 at 12:08:58PM +0200, Daniel Vetter wrote: > > > > Based upon a hunk from a patch from Chris Wilson, but augmented to: > > > > - Process the batch in the full ppgtt vm so that self-relocations > > > > match again with userspace's expectations.. > > > > - Add a comment why plain pin for the global gtt binding is safe at > > > > that point. > > > > > > > > v2: Drop local bind_vm variable (Chris). > > > > > > > > Cc: Chris Wilson > > > > Cc: Ben Widawsky > > > > Signed-off-by: Daniel Vetter > > > > > > /me jaw drops > > > > > > Oh nice, yes you are right that does fix the issue with the relocations > > > being in one address space whilst the exec needs to be done from gGTT. > > > > > > Reviewed-by: Chris Wilson > > > > Actually it's not that simple - with this patch we don't add the ggtt vma > > for the batch to the active list, which we probably should. So needs to be > > revised a bit more I think ... > > The only thing that comes unstuck is eviction, and even there that we > keep them all in order of last GTT access, should prevent most random > stalls. As the batch object itself is still being tracked for gpu > busyness, it is only a level of finese required rather than being > outright broken wrt to serialisation. > > It is still a massive leap forward in our understanding of the > potential solution, and not one step back. Yeah, you're right. Added a FIXME comment as discussed on irc and pulled it in. I guess in the end we should still smash the ggtt batch vma onto the eb list somehow, to make sure that it goes through all the proper move_to_active processing _before_ we call add_request. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 5/6] drm/i915: Add 180 degree primary plane rotation support
On Mon, Aug 11, 2014 at 04:37:00PM +0530, Jindal, Sonika wrote:
>
> Hi Daniel,
> Are you taking this patch back in drm-intel?
We should still call the primary_plane->update hook directly instead of
open-coding it.
-Daniel
>
> -Sonika
>
> On 8/7/2014 5:41 PM, Daniel Vetter wrote:
> >On Thu, Aug 07, 2014 at 01:45:31PM +0200, Daniel Vetter wrote:
> >>On Tue, Jul 15, 2014 at 11:11:37AM +0200, Daniel Vetter wrote:
> >>>On Tue, Jul 15, 2014 at 02:10:28PM +0530, sonika.jin...@intel.com wrote:
> + /* FBC does not work on some platforms for rotated planes */
> + if (INTEL_INFO(dev)->gen <= 4 && !IS_G4X(dev)) {
> + if (dev_priv->fbc.plane == intel_crtc->plane &&
> + intel_plane->rotation != BIT(DRM_ROTATE_0))
> + intel_disable_fbc(dev);
> + /* If rotation was set earlier and new rotation is 0,
> + we might have disabled fbc earlier. So update it now */
> + else if (intel_plane->rotation ==
> BIT(DRM_ROTATE_0)
> + && old_val != BIT(DRM_ROTATE_0)) {
> + mutex_lock(&dev->struct_mutex);
> + intel_update_fbc(dev);
> + mutex_unlock(&dev->struct_mutex);
> + }
> + }
> >>>
> >>>Indentation is screwed up here. Also if we convert some of the checks into
> >>>early bails we could de-indent this by one level.
> >>>
> >>>Also Chris mentioned that on some platforms this won't work and it's more
> >>>future-proof to just do a full modeset until we have the proper
> >>>infrastructure.
> >>
> >>Apparently this review here was never addressed, as Chris just pointed out
> >>on irc. I've dropped the patch again.
> >>
> >>I think we need:
> >>- The same sequence as with the sprite set_property function, i.e. we need
> >> to call the update_plane function (not the raw low-level one, the
> >> high-level with all the checks).
> >>- The fbc check is wrong and will miss updates when the crtc is off. We
> >> need to move this into the general list of checks in intel_update_fbc.
> >>- Since this seems to be buggy I want added testcases to combine fbc
> >> correctness with screen rotation. Probably best to reuse the existing
> >> fbc testcase and add a bunch or rotated tests.
> >
> >Ok, the check in update_fbc is there, I've been blind. Sorry about all the
> >confusion. So just amounts of calling the higher level function and we can
> >forgo the fbc testing.
> >-Daniel
> >
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Fix secure dispatch with full ppgtt
On Mon, Aug 11, 2014 at 01:22:19PM +0200, Daniel Vetter wrote: > On Mon, Aug 11, 2014 at 11:17:40AM +0100, Chris Wilson wrote: > > On Mon, Aug 11, 2014 at 12:08:58PM +0200, Daniel Vetter wrote: > > > Based upon a hunk from a patch from Chris Wilson, but augmented to: > > > - Process the batch in the full ppgtt vm so that self-relocations > > > match again with userspace's expectations.. > > > - Add a comment why plain pin for the global gtt binding is safe at > > > that point. > > > > > > v2: Drop local bind_vm variable (Chris). > > > > > > Cc: Chris Wilson > > > Cc: Ben Widawsky > > > Signed-off-by: Daniel Vetter > > > > /me jaw drops > > > > Oh nice, yes you are right that does fix the issue with the relocations > > being in one address space whilst the exec needs to be done from gGTT. > > > > Reviewed-by: Chris Wilson > > Actually it's not that simple - with this patch we don't add the ggtt vma > for the batch to the active list, which we probably should. So needs to be > revised a bit more I think ... The only thing that comes unstuck is eviction, and even there that we keep them all in order of last GTT access, should prevent most random stalls. As the batch object itself is still being tracked for gpu busyness, it is only a level of finese required rather than being outright broken wrt to serialisation. It is still a massive leap forward in our understanding of the potential solution, and not one step back. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Double check ring is idle before declaring the GPU wedged
On Mon, Aug 11, 2014 at 11:07:10AM +0100, Damien Lespiau wrote:
> On Mon, Aug 11, 2014 at 10:35:25AM +0100, Chris Wilson wrote:
> > On Mon, Aug 11, 2014 at 10:30:09AM +0100, Damien Lespiau wrote:
> > > On Mon, Aug 11, 2014 at 09:21:35AM +0100, Chris Wilson wrote:
> > > > During ring initialisation, sometimes we observe, though not in
> > > > production hardware, that the idle flag is not set even though the ring
> > > > is empty. Double check before giving up.
> > > >
> > > > Signed-off-by: Chris Wilson
> > > > Cc: Damien Lespiau
> > > > ---
> > > > drivers/gpu/drm/i915/intel_ringbuffer.c | 7 ++-
> > > > 1 file changed, 6 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
> > > > b/drivers/gpu/drm/i915/intel_ringbuffer.c
> > > > index a0831c309eab..d72d5e0e693d 100644
> > > > --- a/drivers/gpu/drm/i915/intel_ringbuffer.c
> > > > +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
> > > > @@ -467,7 +467,12 @@ static bool stop_ring(struct intel_engine_cs *ring)
> > > > I915_WRITE_MODE(ring, _MASKED_BIT_ENABLE(STOP_RING));
> > > > if (wait_for((I915_READ_MODE(ring) & MODE_IDLE) != 0,
> > > > 1000)) {
> > > > DRM_ERROR("%s : timed out trying to stop
> > > > ring\n", ring->name);
> > > > - return false;
> > > > + /* Sometimes we observe that the idle flag is
> > > > not
> > > > +* set even though the ring is empty. So double
> > > > +* check before giving up.
> > > > +*/
> > > > + if (I915_READ_HEAD(ring) !=
> > > > I915_READ_TAIL(ring))
> > > > + return false;
> > >
> > > That means we propably want to just put the user visible error message
> > > there as well?
> >
> > It is still a 1 second timeout, so having a warning there that something
> > is wrong is important I thought.
>
> Ah, I missed the "not in production hw" bits of the commit message, It
> may mean simulation and then the guess is that flag is not implemented.
> If that makes us not totally give up, I guess that's something.
>
> Reviewed-by: Damien Lespiau
Queued for -next, thanks for the patch.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
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: Skip load detect when intel_crtc->new_enable==true
On Mon, Aug 11, 2014 at 01:15:36PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> During suspend we turn off the crtcs, but leave the staged config in
> place so that we can restore the display(s) to their previous state on
> resume.
>
> During resume when we attempt to apply the force pipe A quirk we use the
> load detect mechanism. That doesn't check whether there was an already
> staged configuration for the crtc since that's not even possible during
> normal runtime load detection. But during resume it is possible, and if
> we just blindly go and overwrite the staged crtc configuration for the
> load detection we can no longer restore the display to the correct
> state.
>
> Even worse, we don't even clear all the staged connector->encoder->crtc
> links so we may end up using a cloned setup for the load detection, and
> after we're done we just clear the links related to the VGA output
> leaving the links for the other outputs in place. This will eventually
> result in calling intel_set_mode() with mode==NULL but with valid
> connector->encoder->crtc links which will result in dereferencing the
> NULL mode since the code thinks it will have to a modeset.
>
> To avoid these problems don't use any crtc with new_enabled==true for
> load detection.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Daniel Vetter
Cc: sta...@vger.kernel.org
> ---
> drivers/gpu/drm/i915/intel_display.c | 12
> 1 file changed, 8 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 7953b46..ec12e31d1 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -8478,10 +8478,14 @@ retry:
> i++;
> if (!(encoder->possible_crtcs & (1 << i)))
> continue;
> - if (!possible_crtc->enabled) {
> - crtc = possible_crtc;
> - break;
> - }
> + if (possible_crtc->enabled)
> + continue;
> + /* This can occur when applying the pipe A quirk on resume. */
> + if (to_intel_crtc(possible_crtc)->new_enabled)
> + continue;
> +
> + crtc = possible_crtc;
> + break;
> }
>
> /*
> --
> 1.8.5.5
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: fix plane/cursor handling when runtime suspended
On Wed, Aug 06, 2014 at 06:26:01PM -0300, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> If we're runtime suspended and try to use the plane interfaces, we
> will get a lot of WARNs saying we did the wrong thing.
>
> For intel_crtc_update_cursor(), all we need to do is return if the
> CRTC is not active, since writing the registers won't really have any
> effect if the screen is not visible, and we will write the registers
> later when enabling the screen.
>
> For all the other cases, we need to get runtime PM references to
> pin/unpin the objects, and to change the fences. The pin/unpin
> functions are the ideal places for this, but
> intel_crtc_cursor_set_obj() doesn't call them, so we also have to add
> get/put calls inside it. There is no problem if we runtime suspend
> right after these functions are finished, because the registers
> weitten are forwarded to system memory.
>
> v2: - Narrow the put/get calls on intel_crtc_cursor_set_obj() (Daniel)
> v3: - Make get/put also surround the fence and unpin calls (Daniel and
> Ville).
> - Merge all the plane changes into a single patch since they're
> the same fix.
> - Add the comment requested by Daniel.
>
> Testcase: igt/pm_rpm/cursor
> Testcase: igt/pm_rpm/cursor-dpms
> Testcase: igt/pm_rpm/legacy-planes
> Testcase: igt/pm_rpm/legacy-planes-dpms
> Testcase: igt/pm_rpm/universal-planes
> Testcase: igt/pm_rpm/universal-planes-dpms
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=81645
> Cc: sta...@vger.kernel.org
> Signed-off-by: Paulo Zanoni
> ---
> drivers/gpu/drm/i915/intel_display.c | 39
> +++-
> 1 file changed, 38 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 4f659eb..a86d67c 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -2212,6 +2212,15 @@ intel_pin_and_fence_fb_obj(struct drm_device *dev,
> if (need_vtd_wa(dev) && alignment < 256 * 1024)
> alignment = 256 * 1024;
>
> + /*
> + * Global gtt pte registers are special registers which actually forward
> + * writes to a chunk of system memory. Which means that there is no risk
> + * that the register values disappear as soon as we call
> + * intel_runtime_pm_put(), so it is correct to wrap only the
> + * pin/unpin/fence and not more.
> + */
> + intel_runtime_pm_get(dev_priv);
> +
> dev_priv->mm.interruptible = false;
> ret = i915_gem_object_pin_to_display_plane(obj, alignment, pipelined);
> if (ret)
> @@ -2229,21 +2238,30 @@ intel_pin_and_fence_fb_obj(struct drm_device *dev,
> i915_gem_object_pin_fence(obj);
>
> dev_priv->mm.interruptible = true;
> + intel_runtime_pm_put(dev_priv);
> return 0;
>
> err_unpin:
> i915_gem_object_unpin_from_display_plane(obj);
> err_interruptible:
> dev_priv->mm.interruptible = true;
> + intel_runtime_pm_put(dev_priv);
> return ret;
> }
>
> void intel_unpin_fb_obj(struct drm_i915_gem_object *obj)
> {
> - WARN_ON(!mutex_is_locked(&obj->base.dev->struct_mutex));
> + struct drm_device *dev = obj->base.dev;
> + struct drm_i915_private *dev_priv = dev->dev_private;
> +
> + WARN_ON(!mutex_is_locked(&dev->struct_mutex));
> +
> + intel_runtime_pm_get(dev_priv);
>
> i915_gem_object_unpin_fence(obj);
> i915_gem_object_unpin_from_display_plane(obj);
> +
> + intel_runtime_pm_put(dev_priv);
I don't think we touch the hardware during unpin so these aren't
strictly needed.
> }
>
> /* Computes the linear offset to the base tile and adjusts x, y. bytes per
> pixel
> @@ -8285,6 +8303,9 @@ static void intel_crtc_update_cursor(struct drm_crtc
> *crtc,
> if (base == 0 && intel_crtc->cursor_base == 0)
> return;
>
> + if (!intel_crtc->active)
> + return;
> +
Did you actually manage to get by the base==0 check above with a
disabled pipe? I don't think this should happen.
> I915_WRITE(CURPOS(pipe), pos);
>
> if (IS_IVYBRIDGE(dev) || IS_HASWELL(dev) || IS_BROADWELL(dev))
> @@ -8340,9 +8361,20 @@ static int intel_crtc_cursor_set_obj(struct drm_crtc
> *crtc,
>
> /* we only need to pin inside GTT if cursor is non-phy */
> mutex_lock(&dev->struct_mutex);
> +
> + /*
> + * Global gtt pte registers are special registers which actually forward
> + * writes to a chunk of system memory. Which means that there is no risk
> + * that the register values disappear as soon as we call
> + * intel_runtime_pm_put(), so it is correct to wrap only the
> + * pin/unpin/fence and not more.
> + */
> + intel_runtime_pm_get(dev_priv);
> +
> if (!INTEL_INFO(dev)->cursor_needs_physical) {
> unsigned alignment;
>
> +
Spurious whitespace
And now that I look at our cursor code I see we're doing dubious stuff
like unpinni
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Agnostic INTEL_INFO
On Mon, Aug 11, 2014 at 01:25:49PM +0200, Daniel Vetter wrote:
> On Mon, Aug 11, 2014 at 11:26:07AM +0100, Chris Wilson wrote:
> > On Mon, Aug 11, 2014 at 01:14:50PM +0300, Jani Nikula wrote:
> > > On Sat, 09 Aug 2014, Chris Wilson wrote:
> > > > Adapt the macro so that we can pass either the struct drm_device or the
> > > > struct drm_i915_private pointers and get the answer we want. Over time,
> > > > my plan is to convert all users over to using drm_i915_private and so
> > > > trimming down the pointer dance. Having spent a few hours chasing that
> > > > goal and achieved over 8k of object code saving, it appears to be a
> > > > worthwhile target. This interim macro allows us to slowly convert over.
> > > >
> > > > Signed-off-by: Chris Wilson
> > > > ---
> > > > drivers/gpu/drm/i915/i915_dma.c | 3 +++
> > > > drivers/gpu/drm/i915/i915_drv.h | 3 ++-
> > > > 2 files changed, 5 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/i915_dma.c
> > > > b/drivers/gpu/drm/i915/i915_dma.c
> > > > index 39988940d468..49149406fcd8 100644
> > > > --- a/drivers/gpu/drm/i915/i915_dma.c
> > > > +++ b/drivers/gpu/drm/i915/i915_dma.c
> > > > @@ -1585,6 +1585,9 @@ int i915_driver_load(struct drm_device *dev,
> > > > unsigned long flags)
> > > > if (!drm_core_check_feature(dev, DRIVER_MODESET) && !dev->agp)
> > > > return -EINVAL;
> > > >
> > > > + /* For the ugly agnostic INTEL_INFO macro */
> > > > + BUILD_BUG_ON(sizeof(*dev_priv) == sizeof(*dev));
> > > > +
> > > > dev_priv = kzalloc(sizeof(*dev_priv), GFP_KERNEL);
> > > > if (dev_priv == NULL)
> > > > return -ENOMEM;
> > > > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > > > b/drivers/gpu/drm/i915/i915_drv.h
> > > > index 0aef763ffa75..e66465430bdc 100644
> > > > --- a/drivers/gpu/drm/i915/i915_drv.h
> > > > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > > > @@ -2063,7 +2063,8 @@ struct drm_i915_cmd_table {
> > > > int count;
> > > > };
> > > >
> > > > -#define INTEL_INFO(p) (&to_i915(p)->info)
> > > > +#define __I915__(p)((sizeof(*(p)) == sizeof(struct
> > > > drm_i915_private)) ? (struct drm_i915_private *)(p) : to_i915((struct
> > > > drm_device *)p))
> > >
> > > The explicit casts make me uncomfortable. Indeed, aren't they completely
> > > unnecessary? If the sizeof matches, p is expected to be struct
> > > drm_i915_private *, and if not, it's expected to be struct drm_device *,
> > > right?
> >
> > Yes, killing the typesafety is bad. Sadly it is to quiesce the compiler
> > as the type-mismatch warnings are generated before it does the dead code
> > elimination removing the constant ?: expression. Too bad we couldn't
> > simply write typeof(*p) == typeof(T).
>
> Do we need the 2nd cast for (struct drm_device *)? If we could drop that
> we'd have about as much type-safety as before, presuming no one manages to
> matche our drm_i915_private exactly in size.
The compiler is happy with that. I can't remember exactly why I added
it first time, it certainly wasn't for its looks.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
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: Fix locking for intel_enable_pipe_a()
On Mon, Aug 11, 2014 at 01:15:35PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> intel_enable_pipe_a() gets called with all the modeset locks already
> held (by drm_modeset_lock_all()), so trying to grab the same
> locks using another drm_modeset_acquire_ctx is going to fail miserably.
>
> Move most of the drm_modeset_acquire_ctx handling (init/drop/fini)
> out from intel_{get,release}_load_detect_pipe() into the callers
> (intel_{crt,tv}_detect()). Only the actual locking and backoff
> handling is left in intel_get_load_detect_pipe(). And in
> intel_enable_pipe_a() we just share the mode_config.acquire_ctx from
> drm_modeset_lock_all() which is already holding all the relevant locks.
>
> It's perfectly legal to lock the same ww_mutex multiple times using the
> same ww_acquire_ctx. drm_modeset_lock() will convert the returned
> -EALREADY into 0, so the caller doesn't need to do antyhing special.
>
> Fixes a hang on resume on my 830.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Daniel Vetter
Cc: sta...@vger.kernel.org (for 3.16)
> ---
> drivers/gpu/drm/i915/intel_crt.c | 7 ++-
> drivers/gpu/drm/i915/intel_display.c | 21 -
> drivers/gpu/drm/i915/intel_drv.h | 3 +--
> drivers/gpu/drm/i915/intel_tv.c | 7 ++-
> 4 files changed, 17 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_crt.c
> b/drivers/gpu/drm/i915/intel_crt.c
> index 2efaf8e..e8abfce 100644
> --- a/drivers/gpu/drm/i915/intel_crt.c
> +++ b/drivers/gpu/drm/i915/intel_crt.c
> @@ -699,16 +699,21 @@ intel_crt_detect(struct drm_connector *connector, bool
> force)
> goto out;
> }
>
> + drm_modeset_acquire_init(&ctx, 0);
> +
> /* for pre-945g platforms use load detect */
> if (intel_get_load_detect_pipe(connector, NULL, &tmp, &ctx)) {
> if (intel_crt_detect_ddc(connector))
> status = connector_status_connected;
> else
> status = intel_crt_load_detect(crt);
> - intel_release_load_detect_pipe(connector, &tmp, &ctx);
> + intel_release_load_detect_pipe(connector, &tmp);
> } else
> status = connector_status_unknown;
>
> + drm_modeset_drop_locks(&ctx);
> + drm_modeset_acquire_fini(&ctx);
> +
> out:
> intel_display_power_put(dev_priv, power_domain);
> return status;
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 51f48d9..7953b46 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -8440,8 +8440,6 @@ bool intel_get_load_detect_pipe(struct drm_connector
> *connector,
> connector->base.id, connector->name,
> encoder->base.id, encoder->name);
>
> - drm_modeset_acquire_init(ctx, 0);
> -
> retry:
> ret = drm_modeset_lock(&config->connection_mutex, ctx);
> if (ret)
> @@ -8552,15 +8550,11 @@ fail_unlock:
> goto retry;
> }
>
> - drm_modeset_drop_locks(ctx);
> - drm_modeset_acquire_fini(ctx);
> -
> return false;
> }
>
> void intel_release_load_detect_pipe(struct drm_connector *connector,
> - struct intel_load_detect_pipe *old,
> - struct drm_modeset_acquire_ctx *ctx)
> + struct intel_load_detect_pipe *old)
> {
> struct intel_encoder *intel_encoder =
> intel_attached_encoder(connector);
> @@ -8584,17 +8578,12 @@ void intel_release_load_detect_pipe(struct
> drm_connector *connector,
> drm_framebuffer_unreference(old->release_fb);
> }
>
> - goto unlock;
> return;
> }
>
> /* Switch crtc and encoder back off if necessary */
> if (old->dpms_mode != DRM_MODE_DPMS_ON)
> connector->funcs->dpms(connector, old->dpms_mode);
> -
> -unlock:
> - drm_modeset_drop_locks(ctx);
> - drm_modeset_acquire_fini(ctx);
> }
>
> static int i9xx_pll_refclk(struct drm_device *dev,
> @@ -12652,7 +12641,7 @@ static void intel_enable_pipe_a(struct drm_device
> *dev)
> struct intel_connector *connector;
> struct drm_connector *crt = NULL;
> struct intel_load_detect_pipe load_detect_temp;
> - struct drm_modeset_acquire_ctx ctx;
> + struct drm_modeset_acquire_ctx *ctx = dev->mode_config.acquire_ctx;
>
> /* We can't just switch on the pipe A, we need to set things up with a
>* proper mode and output configuration. As a gross hack, enable pipe A
> @@ -12669,10 +12658,8 @@ static void intel_enable_pipe_a(struct drm_device
> *dev)
> if (!crt)
> return;
>
> - if (intel_get_load_detect_pipe(crt, NULL, &load_detect_temp, &ctx))
> - intel_release_load_detect_pipe(crt, &load_detect_temp, &ctx);
> -
> -
> + if (intel_get_load_
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Agnostic INTEL_INFO
On Mon, Aug 11, 2014 at 11:26:07AM +0100, Chris Wilson wrote:
> On Mon, Aug 11, 2014 at 01:14:50PM +0300, Jani Nikula wrote:
> > On Sat, 09 Aug 2014, Chris Wilson wrote:
> > > Adapt the macro so that we can pass either the struct drm_device or the
> > > struct drm_i915_private pointers and get the answer we want. Over time,
> > > my plan is to convert all users over to using drm_i915_private and so
> > > trimming down the pointer dance. Having spent a few hours chasing that
> > > goal and achieved over 8k of object code saving, it appears to be a
> > > worthwhile target. This interim macro allows us to slowly convert over.
> > >
> > > Signed-off-by: Chris Wilson
> > > ---
> > > drivers/gpu/drm/i915/i915_dma.c | 3 +++
> > > drivers/gpu/drm/i915/i915_drv.h | 3 ++-
> > > 2 files changed, 5 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/i915_dma.c
> > > b/drivers/gpu/drm/i915/i915_dma.c
> > > index 39988940d468..49149406fcd8 100644
> > > --- a/drivers/gpu/drm/i915/i915_dma.c
> > > +++ b/drivers/gpu/drm/i915/i915_dma.c
> > > @@ -1585,6 +1585,9 @@ int i915_driver_load(struct drm_device *dev,
> > > unsigned long flags)
> > > if (!drm_core_check_feature(dev, DRIVER_MODESET) && !dev->agp)
> > > return -EINVAL;
> > >
> > > + /* For the ugly agnostic INTEL_INFO macro */
> > > + BUILD_BUG_ON(sizeof(*dev_priv) == sizeof(*dev));
> > > +
> > > dev_priv = kzalloc(sizeof(*dev_priv), GFP_KERNEL);
> > > if (dev_priv == NULL)
> > > return -ENOMEM;
> > > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > > b/drivers/gpu/drm/i915/i915_drv.h
> > > index 0aef763ffa75..e66465430bdc 100644
> > > --- a/drivers/gpu/drm/i915/i915_drv.h
> > > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > > @@ -2063,7 +2063,8 @@ struct drm_i915_cmd_table {
> > > int count;
> > > };
> > >
> > > -#define INTEL_INFO(p)(&to_i915(p)->info)
> > > +#define __I915__(p) ((sizeof(*(p)) == sizeof(struct
> > > drm_i915_private)) ? (struct drm_i915_private *)(p) : to_i915((struct
> > > drm_device *)p))
> >
> > The explicit casts make me uncomfortable. Indeed, aren't they completely
> > unnecessary? If the sizeof matches, p is expected to be struct
> > drm_i915_private *, and if not, it's expected to be struct drm_device *,
> > right?
>
> Yes, killing the typesafety is bad. Sadly it is to quiesce the compiler
> as the type-mismatch warnings are generated before it does the dead code
> elimination removing the constant ?: expression. Too bad we couldn't
> simply write typeof(*p) == typeof(T).
Do we need the 2nd cast for (struct drm_device *)? If we could drop that
we'd have about as much type-safety as before, presuming no one manages to
matche our drm_i915_private exactly in size.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
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: Copy PCI device id into the device info block
On Mon, Aug 11, 2014 at 01:05:03PM +0300, Jani Nikula wrote:
> On Sat, 09 Aug 2014, Chris Wilson wrote:
> > This is so that we can make the drm_i915_private->info always the
> > preferred source for chipset type and feature queries.
>
> Reviewed-by: Jani Nikula
Queued for -next, thanks for the patch.
-Daniel
>
> > Signed-off-by: Chris Wilson
> > ---
> > drivers/gpu/drm/i915/i915_dma.c | 5 +++--
> > drivers/gpu/drm/i915/i915_drv.h | 50
> > +
> > 2 files changed, 29 insertions(+), 26 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_dma.c
> > b/drivers/gpu/drm/i915/i915_dma.c
> > index 96bf11e7a011..39988940d468 100644
> > --- a/drivers/gpu/drm/i915/i915_dma.c
> > +++ b/drivers/gpu/drm/i915/i915_dma.c
> > @@ -1592,9 +1592,10 @@ int i915_driver_load(struct drm_device *dev,
> > unsigned long flags)
> > dev->dev_private = dev_priv;
> > dev_priv->dev = dev;
> >
> > - /* copy initial configuration to dev_priv->info */
> > + /* Setup the write-once "constant" device info */
> > device_info = (struct intel_device_info *)&dev_priv->info;
> > - *device_info = *info;
> > + memcpy(device_info, info, sizeof(dev_priv->info));
> > + device_info->device_id = dev->pdev->device;
> >
> > spin_lock_init(&dev_priv->irq_lock);
> > spin_lock_init(&dev_priv->gpu_error.lock);
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index b3d42b085790..0aef763ffa75 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -563,6 +563,7 @@ struct intel_uncore {
> >
> > struct intel_device_info {
> > u32 display_mmio_offset;
> > + u16 device_id;
> > u8 num_pipes:3;
> > u8 num_sprites[I915_MAX_PIPES];
> > u8 gen;
> > @@ -2062,51 +2063,52 @@ struct drm_i915_cmd_table {
> > int count;
> > };
> >
> > -#define INTEL_INFO(dev)(&to_i915(dev)->info)
> > +#define INTEL_INFO(p) (&to_i915(p)->info)
> > +#define INTEL_DEVID(p) (INTEL_INFO(p)->device_id)
> >
> > -#define IS_I830(dev) ((dev)->pdev->device == 0x3577)
> > -#define IS_845G(dev) ((dev)->pdev->device == 0x2562)
> > +#define IS_I830(dev) (INTEL_DEVID(dev) == 0x3577)
> > +#define IS_845G(dev) (INTEL_DEVID(dev) == 0x2562)
> > #define IS_I85X(dev) (INTEL_INFO(dev)->is_i85x)
> > -#define IS_I865G(dev) ((dev)->pdev->device == 0x2572)
> > +#define IS_I865G(dev) (INTEL_DEVID(dev) == 0x2572)
> > #define IS_I915G(dev) (INTEL_INFO(dev)->is_i915g)
> > -#define IS_I915GM(dev) ((dev)->pdev->device == 0x2592)
> > -#define IS_I945G(dev) ((dev)->pdev->device == 0x2772)
> > +#define IS_I915GM(dev) (INTEL_DEVID(dev) == 0x2592)
> > +#define IS_I945G(dev) (INTEL_DEVID(dev) == 0x2772)
> > #define IS_I945GM(dev) (INTEL_INFO(dev)->is_i945gm)
> > #define IS_BROADWATER(dev) (INTEL_INFO(dev)->is_broadwater)
> > #define IS_CRESTLINE(dev) (INTEL_INFO(dev)->is_crestline)
> > -#define IS_GM45(dev) ((dev)->pdev->device == 0x2A42)
> > +#define IS_GM45(dev) (INTEL_DEVID(dev) == 0x2A42)
> > #define IS_G4X(dev)(INTEL_INFO(dev)->is_g4x)
> > -#define IS_PINEVIEW_G(dev) ((dev)->pdev->device == 0xa001)
> > -#define IS_PINEVIEW_M(dev) ((dev)->pdev->device == 0xa011)
> > +#define IS_PINEVIEW_G(dev) (INTEL_DEVID(dev) == 0xa001)
> > +#define IS_PINEVIEW_M(dev) (INTEL_DEVID(dev) == 0xa011)
> > #define IS_PINEVIEW(dev) (INTEL_INFO(dev)->is_pineview)
> > #define IS_G33(dev)(INTEL_INFO(dev)->is_g33)
> > -#define IS_IRONLAKE_M(dev) ((dev)->pdev->device == 0x0046)
> > +#define IS_IRONLAKE_M(dev) (INTEL_DEVID(dev) == 0x0046)
> > #define IS_IVYBRIDGE(dev) (INTEL_INFO(dev)->is_ivybridge)
> > -#define IS_IVB_GT1(dev)((dev)->pdev->device == 0x0156 || \
> > -(dev)->pdev->device == 0x0152 || \
> > -(dev)->pdev->device == 0x015a)
> > -#define IS_SNB_GT1(dev)((dev)->pdev->device == 0x0102 || \
> > -(dev)->pdev->device == 0x0106 || \
> > -(dev)->pdev->device == 0x010A)
> > +#define IS_IVB_GT1(dev)(INTEL_DEVID(dev) == 0x0156 || \
> > +INTEL_DEVID(dev) == 0x0152 || \
> > +INTEL_DEVID(dev) == 0x015a)
> > +#define IS_SNB_GT1(dev)(INTEL_DEVID(dev) == 0x0102 || \
> > +INTEL_DEVID(dev) == 0x0106 || \
> > +INTEL_DEVID(dev) == 0x010A)
> > #define IS_VALLEYVIEW(dev) (INTEL_INFO(dev)->is_valleyview)
> > #define IS_CHERRYVIEW(dev) (INTEL_INFO(dev)->is_valleyview && IS_GEN8(dev))
> > #define IS_HASWELL(dev)(INTEL_INFO(dev)->is_haswell)
> > #define IS_BROADWELL(dev) (!INTEL_INFO(dev)->is_valleyview &&
> > IS_GEN8(dev))
> > #define
Re: [Intel-gfx] [PATCH] drm/i915: Fix secure dispatch with full ppgtt
On Mon, Aug 11, 2014 at 11:17:40AM +0100, Chris Wilson wrote: > On Mon, Aug 11, 2014 at 12:08:58PM +0200, Daniel Vetter wrote: > > Based upon a hunk from a patch from Chris Wilson, but augmented to: > > - Process the batch in the full ppgtt vm so that self-relocations > > match again with userspace's expectations.. > > - Add a comment why plain pin for the global gtt binding is safe at > > that point. > > > > v2: Drop local bind_vm variable (Chris). > > > > Cc: Chris Wilson > > Cc: Ben Widawsky > > Signed-off-by: Daniel Vetter > > /me jaw drops > > Oh nice, yes you are right that does fix the issue with the relocations > being in one address space whilst the exec needs to be done from gGTT. > > Reviewed-by: Chris Wilson Actually it's not that simple - with this patch we don't add the ggtt vma for the batch to the active list, which we probably should. So needs to be revised a bit more I think ... -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 5/6] drm/i915: Add 180 degree primary plane rotation support
Hi Daniel,
Are you taking this patch back in drm-intel?
-Sonika
On 8/7/2014 5:41 PM, Daniel Vetter wrote:
On Thu, Aug 07, 2014 at 01:45:31PM +0200, Daniel Vetter wrote:
On Tue, Jul 15, 2014 at 11:11:37AM +0200, Daniel Vetter wrote:
On Tue, Jul 15, 2014 at 02:10:28PM +0530, sonika.jin...@intel.com wrote:
+ /* FBC does not work on some platforms for rotated planes */
+ if (INTEL_INFO(dev)->gen <= 4 && !IS_G4X(dev)) {
+ if (dev_priv->fbc.plane == intel_crtc->plane &&
+ intel_plane->rotation != BIT(DRM_ROTATE_0))
+ intel_disable_fbc(dev);
+ /* If rotation was set earlier and new rotation is 0,
+ we might have disabled fbc earlier. So update it now */
+ else if (intel_plane->rotation ==
BIT(DRM_ROTATE_0)
+ && old_val != BIT(DRM_ROTATE_0)) {
+ mutex_lock(&dev->struct_mutex);
+ intel_update_fbc(dev);
+ mutex_unlock(&dev->struct_mutex);
+ }
+ }
Indentation is screwed up here. Also if we convert some of the checks into
early bails we could de-indent this by one level.
Also Chris mentioned that on some platforms this won't work and it's more
future-proof to just do a full modeset until we have the proper
infrastructure.
Apparently this review here was never addressed, as Chris just pointed out
on irc. I've dropped the patch again.
I think we need:
- The same sequence as with the sprite set_property function, i.e. we need
to call the update_plane function (not the raw low-level one, the
high-level with all the checks).
- The fbc check is wrong and will miss updates when the crtc is off. We
need to move this into the general list of checks in intel_update_fbc.
- Since this seems to be buggy I want added testcases to combine fbc
correctness with screen rotation. Probably best to reuse the existing
fbc testcase and add a bunch or rotated tests.
Ok, the check in update_fbc is there, I've been blind. Sorry about all the
confusion. So just amounts of calling the higher level function and we can
forgo the fbc testing.
-Daniel
___
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: Agnostic INTEL_INFO
On Mon, Aug 11, 2014 at 01:14:50PM +0300, Jani Nikula wrote:
> On Sat, 09 Aug 2014, Chris Wilson wrote:
> > Adapt the macro so that we can pass either the struct drm_device or the
> > struct drm_i915_private pointers and get the answer we want. Over time,
> > my plan is to convert all users over to using drm_i915_private and so
> > trimming down the pointer dance. Having spent a few hours chasing that
> > goal and achieved over 8k of object code saving, it appears to be a
> > worthwhile target. This interim macro allows us to slowly convert over.
> >
> > Signed-off-by: Chris Wilson
> > ---
> > drivers/gpu/drm/i915/i915_dma.c | 3 +++
> > drivers/gpu/drm/i915/i915_drv.h | 3 ++-
> > 2 files changed, 5 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_dma.c
> > b/drivers/gpu/drm/i915/i915_dma.c
> > index 39988940d468..49149406fcd8 100644
> > --- a/drivers/gpu/drm/i915/i915_dma.c
> > +++ b/drivers/gpu/drm/i915/i915_dma.c
> > @@ -1585,6 +1585,9 @@ int i915_driver_load(struct drm_device *dev, unsigned
> > long flags)
> > if (!drm_core_check_feature(dev, DRIVER_MODESET) && !dev->agp)
> > return -EINVAL;
> >
> > + /* For the ugly agnostic INTEL_INFO macro */
> > + BUILD_BUG_ON(sizeof(*dev_priv) == sizeof(*dev));
> > +
> > dev_priv = kzalloc(sizeof(*dev_priv), GFP_KERNEL);
> > if (dev_priv == NULL)
> > return -ENOMEM;
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index 0aef763ffa75..e66465430bdc 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -2063,7 +2063,8 @@ struct drm_i915_cmd_table {
> > int count;
> > };
> >
> > -#define INTEL_INFO(p) (&to_i915(p)->info)
> > +#define __I915__(p)((sizeof(*(p)) == sizeof(struct
> > drm_i915_private)) ? (struct drm_i915_private *)(p) : to_i915((struct
> > drm_device *)p))
>
> The explicit casts make me uncomfortable. Indeed, aren't they completely
> unnecessary? If the sizeof matches, p is expected to be struct
> drm_i915_private *, and if not, it's expected to be struct drm_device *,
> right?
Yes, killing the typesafety is bad. Sadly it is to quiesce the compiler
as the type-mismatch warnings are generated before it does the dead code
elimination removing the constant ?: expression. Too bad we couldn't
simply write typeof(*p) == typeof(T).
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/3] drm/i915: Remove fenced_gpu_access and pending_fenced_gpu_access
On Sat, Aug 09, 2014 at 05:37:24PM +0100, Chris Wilson wrote:
> This migrates the fence tracking onto the existing seqno
> infrastructure so that the later conversion to tracking via requests is
> simplified.
>
> Signed-off-by: Chris Wilson
Pulled in all 3 with the changes to patch 2 as discussed on irc.
Thanks, Daniel
> ---
> drivers/gpu/drm/i915/i915_drv.h| 7 --
> drivers/gpu/drm/i915/i915_gem.c| 17 ---
> drivers/gpu/drm/i915/i915_gem_execbuffer.c | 34
> +-
> drivers/gpu/drm/i915/i915_gem_tiling.c | 2 +-
> 4 files changed, 20 insertions(+), 40 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index fab97bc3215f..5c3f033ff928 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1777,13 +1777,6 @@ struct drm_i915_gem_object {
>* Only honoured if hardware has relevant pte bit
>*/
> unsigned long gt_ro:1;
> -
> - /*
> - * Is the GPU currently using a fence to access this buffer,
> - */
> - unsigned int pending_fenced_gpu_access:1;
> - unsigned int fenced_gpu_access:1;
> -
> unsigned int cache_level:3;
>
> unsigned int has_aliasing_ppgtt_mapping:1;
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 6366230c4e32..e808b449ac75 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -2163,8 +2163,6 @@ static void
> i915_gem_object_move_to_active(struct drm_i915_gem_object *obj,
> struct intel_engine_cs *ring)
> {
> - struct drm_device *dev = obj->base.dev;
> - struct drm_i915_private *dev_priv = dev->dev_private;
> u32 seqno = intel_ring_get_seqno(ring);
>
> BUG_ON(ring == NULL);
> @@ -2183,19 +2181,6 @@ i915_gem_object_move_to_active(struct
> drm_i915_gem_object *obj,
> list_move_tail(&obj->ring_list, &ring->active_list);
>
> obj->last_read_seqno = seqno;
> -
> - if (obj->fenced_gpu_access) {
> - obj->last_fenced_seqno = seqno;
> -
> - /* Bump MRU to take account of the delayed flush */
> - if (obj->fence_reg != I915_FENCE_REG_NONE) {
> - struct drm_i915_fence_reg *reg;
> -
> - reg = &dev_priv->fence_regs[obj->fence_reg];
> - list_move_tail(®->lru_list,
> -&dev_priv->mm.fence_list);
> - }
> - }
> }
>
> void i915_vma_move_to_active(struct i915_vma *vma,
> @@ -2231,7 +2216,6 @@ i915_gem_object_move_to_inactive(struct
> drm_i915_gem_object *obj)
> obj->base.write_domain = 0;
>
> obj->last_fenced_seqno = 0;
> - obj->fenced_gpu_access = false;
>
> obj->active = 0;
> drm_gem_object_unreference(&obj->base);
> @@ -3176,7 +3160,6 @@ i915_gem_object_wait_fence(struct drm_i915_gem_object
> *obj)
> obj->last_fenced_seqno = 0;
> }
>
> - obj->fenced_gpu_access = false;
> return 0;
> }
>
> diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> index 87e9599f9e4b..fbac7b51736c 100644
> --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> @@ -542,7 +542,6 @@ i915_gem_execbuffer_reserve_vma(struct i915_vma *vma,
> {
> struct drm_i915_gem_object *obj = vma->obj;
> struct drm_i915_gem_exec_object2 *entry = vma->exec_entry;
> - bool has_fenced_gpu_access = INTEL_INFO(ring->dev)->gen < 4;
> uint64_t flags;
> int ret;
>
> @@ -560,17 +559,13 @@ i915_gem_execbuffer_reserve_vma(struct i915_vma *vma,
>
> entry->flags |= __EXEC_OBJECT_HAS_PIN;
>
> - if (has_fenced_gpu_access) {
> - if (entry->flags & EXEC_OBJECT_NEEDS_FENCE) {
> - ret = i915_gem_object_get_fence(obj);
> - if (ret)
> - return ret;
> -
> - if (i915_gem_object_pin_fence(obj))
> - entry->flags |= __EXEC_OBJECT_HAS_FENCE;
> + if (entry->flags & EXEC_OBJECT_NEEDS_FENCE) {
> + ret = i915_gem_object_get_fence(obj);
> + if (ret)
> + return ret;
>
> - obj->pending_fenced_gpu_access = true;
> - }
> + if (i915_gem_object_pin_fence(obj))
> + entry->flags |= __EXEC_OBJECT_HAS_FENCE;
> }
>
> if (entry->offset != vma->node.start) {
> @@ -658,8 +653,9 @@ i915_gem_execbuffer_reserve(struct intel_engine_cs *ring,
> obj = vma->obj;
> entry = vma->exec_entry;
>
> + if (!has_fenced_gpu_access)
> + entry->flags &= ~EXEC_OBJECT_NEEDS_FENCE;
> need_fence =
> - has_fenced_gpu_access &&
> entry->flags &
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Agnostic INTEL_INFO
On Sat, 09 Aug 2014, Chris Wilson wrote:
> Adapt the macro so that we can pass either the struct drm_device or the
> struct drm_i915_private pointers and get the answer we want. Over time,
> my plan is to convert all users over to using drm_i915_private and so
> trimming down the pointer dance. Having spent a few hours chasing that
> goal and achieved over 8k of object code saving, it appears to be a
> worthwhile target. This interim macro allows us to slowly convert over.
>
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/i915/i915_dma.c | 3 +++
> drivers/gpu/drm/i915/i915_drv.h | 3 ++-
> 2 files changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
> index 39988940d468..49149406fcd8 100644
> --- a/drivers/gpu/drm/i915/i915_dma.c
> +++ b/drivers/gpu/drm/i915/i915_dma.c
> @@ -1585,6 +1585,9 @@ int i915_driver_load(struct drm_device *dev, unsigned
> long flags)
> if (!drm_core_check_feature(dev, DRIVER_MODESET) && !dev->agp)
> return -EINVAL;
>
> + /* For the ugly agnostic INTEL_INFO macro */
> + BUILD_BUG_ON(sizeof(*dev_priv) == sizeof(*dev));
> +
> dev_priv = kzalloc(sizeof(*dev_priv), GFP_KERNEL);
> if (dev_priv == NULL)
> return -ENOMEM;
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 0aef763ffa75..e66465430bdc 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -2063,7 +2063,8 @@ struct drm_i915_cmd_table {
> int count;
> };
>
> -#define INTEL_INFO(p)(&to_i915(p)->info)
> +#define __I915__(p) ((sizeof(*(p)) == sizeof(struct drm_i915_private)) ?
> (struct drm_i915_private *)(p) : to_i915((struct drm_device *)p))
The explicit casts make me uncomfortable. Indeed, aren't they completely
unnecessary? If the sizeof matches, p is expected to be struct
drm_i915_private *, and if not, it's expected to be struct drm_device *,
right?
#define __I915__(p) ((sizeof(*(p)) == sizeof(struct drm_i915_private)) ?
(p) : to_i915(p))
Otherwise you won't even get a compiler warning if you pass a random
pointer to this macro.
BR,
Jani.
> +#define INTEL_INFO(p)(&__I915__(p)->info)
> #define INTEL_DEVID(p) (INTEL_INFO(p)->device_id)
>
> #define IS_I830(dev) (INTEL_DEVID(dev) == 0x3577)
> --
> 2.1.0.rc1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/i915: Skip load detect when intel_crtc->new_enable==true
From: Ville Syrjälä
During suspend we turn off the crtcs, but leave the staged config in
place so that we can restore the display(s) to their previous state on
resume.
During resume when we attempt to apply the force pipe A quirk we use the
load detect mechanism. That doesn't check whether there was an already
staged configuration for the crtc since that's not even possible during
normal runtime load detection. But during resume it is possible, and if
we just blindly go and overwrite the staged crtc configuration for the
load detection we can no longer restore the display to the correct
state.
Even worse, we don't even clear all the staged connector->encoder->crtc
links so we may end up using a cloned setup for the load detection, and
after we're done we just clear the links related to the VGA output
leaving the links for the other outputs in place. This will eventually
result in calling intel_set_mode() with mode==NULL but with valid
connector->encoder->crtc links which will result in dereferencing the
NULL mode since the code thinks it will have to a modeset.
To avoid these problems don't use any crtc with new_enabled==true for
load detection.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 7953b46..ec12e31d1 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -8478,10 +8478,14 @@ retry:
i++;
if (!(encoder->possible_crtcs & (1 << i)))
continue;
- if (!possible_crtc->enabled) {
- crtc = possible_crtc;
- break;
- }
+ if (possible_crtc->enabled)
+ continue;
+ /* This can occur when applying the pipe A quirk on resume. */
+ if (to_intel_crtc(possible_crtc)->new_enabled)
+ continue;
+
+ crtc = possible_crtc;
+ break;
}
/*
--
1.8.5.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Fix secure dispatch with full ppgtt
On Mon, Aug 11, 2014 at 12:08:58PM +0200, Daniel Vetter wrote: > Based upon a hunk from a patch from Chris Wilson, but augmented to: > - Process the batch in the full ppgtt vm so that self-relocations > match again with userspace's expectations.. > - Add a comment why plain pin for the global gtt binding is safe at > that point. > > v2: Drop local bind_vm variable (Chris). > > Cc: Chris Wilson > Cc: Ben Widawsky > Signed-off-by: Daniel Vetter /me jaw drops Oh nice, yes you are right that does fix the issue with the relocations being in one address space whilst the exec needs to be done from gGTT. Reviewed-by: Chris Wilson -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] drm/i915: Fix locking for intel_enable_pipe_a()
From: Ville Syrjälä
intel_enable_pipe_a() gets called with all the modeset locks already
held (by drm_modeset_lock_all()), so trying to grab the same
locks using another drm_modeset_acquire_ctx is going to fail miserably.
Move most of the drm_modeset_acquire_ctx handling (init/drop/fini)
out from intel_{get,release}_load_detect_pipe() into the callers
(intel_{crt,tv}_detect()). Only the actual locking and backoff
handling is left in intel_get_load_detect_pipe(). And in
intel_enable_pipe_a() we just share the mode_config.acquire_ctx from
drm_modeset_lock_all() which is already holding all the relevant locks.
It's perfectly legal to lock the same ww_mutex multiple times using the
same ww_acquire_ctx. drm_modeset_lock() will convert the returned
-EALREADY into 0, so the caller doesn't need to do antyhing special.
Fixes a hang on resume on my 830.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_crt.c | 7 ++-
drivers/gpu/drm/i915/intel_display.c | 21 -
drivers/gpu/drm/i915/intel_drv.h | 3 +--
drivers/gpu/drm/i915/intel_tv.c | 7 ++-
4 files changed, 17 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_crt.c b/drivers/gpu/drm/i915/intel_crt.c
index 2efaf8e..e8abfce 100644
--- a/drivers/gpu/drm/i915/intel_crt.c
+++ b/drivers/gpu/drm/i915/intel_crt.c
@@ -699,16 +699,21 @@ intel_crt_detect(struct drm_connector *connector, bool
force)
goto out;
}
+ drm_modeset_acquire_init(&ctx, 0);
+
/* for pre-945g platforms use load detect */
if (intel_get_load_detect_pipe(connector, NULL, &tmp, &ctx)) {
if (intel_crt_detect_ddc(connector))
status = connector_status_connected;
else
status = intel_crt_load_detect(crt);
- intel_release_load_detect_pipe(connector, &tmp, &ctx);
+ intel_release_load_detect_pipe(connector, &tmp);
} else
status = connector_status_unknown;
+ drm_modeset_drop_locks(&ctx);
+ drm_modeset_acquire_fini(&ctx);
+
out:
intel_display_power_put(dev_priv, power_domain);
return status;
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 51f48d9..7953b46 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -8440,8 +8440,6 @@ bool intel_get_load_detect_pipe(struct drm_connector
*connector,
connector->base.id, connector->name,
encoder->base.id, encoder->name);
- drm_modeset_acquire_init(ctx, 0);
-
retry:
ret = drm_modeset_lock(&config->connection_mutex, ctx);
if (ret)
@@ -8552,15 +8550,11 @@ fail_unlock:
goto retry;
}
- drm_modeset_drop_locks(ctx);
- drm_modeset_acquire_fini(ctx);
-
return false;
}
void intel_release_load_detect_pipe(struct drm_connector *connector,
- struct intel_load_detect_pipe *old,
- struct drm_modeset_acquire_ctx *ctx)
+ struct intel_load_detect_pipe *old)
{
struct intel_encoder *intel_encoder =
intel_attached_encoder(connector);
@@ -8584,17 +8578,12 @@ void intel_release_load_detect_pipe(struct
drm_connector *connector,
drm_framebuffer_unreference(old->release_fb);
}
- goto unlock;
return;
}
/* Switch crtc and encoder back off if necessary */
if (old->dpms_mode != DRM_MODE_DPMS_ON)
connector->funcs->dpms(connector, old->dpms_mode);
-
-unlock:
- drm_modeset_drop_locks(ctx);
- drm_modeset_acquire_fini(ctx);
}
static int i9xx_pll_refclk(struct drm_device *dev,
@@ -12652,7 +12641,7 @@ static void intel_enable_pipe_a(struct drm_device *dev)
struct intel_connector *connector;
struct drm_connector *crt = NULL;
struct intel_load_detect_pipe load_detect_temp;
- struct drm_modeset_acquire_ctx ctx;
+ struct drm_modeset_acquire_ctx *ctx = dev->mode_config.acquire_ctx;
/* We can't just switch on the pipe A, we need to set things up with a
* proper mode and output configuration. As a gross hack, enable pipe A
@@ -12669,10 +12658,8 @@ static void intel_enable_pipe_a(struct drm_device *dev)
if (!crt)
return;
- if (intel_get_load_detect_pipe(crt, NULL, &load_detect_temp, &ctx))
- intel_release_load_detect_pipe(crt, &load_detect_temp, &ctx);
-
-
+ if (intel_get_load_detect_pipe(crt, NULL, &load_detect_temp, ctx))
+ intel_release_load_detect_pipe(crt, &load_detect_temp);
}
static bool
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 1b3d1d7..0dd23f1 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/dr
Re: [Intel-gfx] [PATCH] drm/i915: Double check ring is idle before declaring the GPU wedged
On Mon, Aug 11, 2014 at 11:07:10AM +0100, Damien Lespiau wrote:
> On Mon, Aug 11, 2014 at 10:35:25AM +0100, Chris Wilson wrote:
> > On Mon, Aug 11, 2014 at 10:30:09AM +0100, Damien Lespiau wrote:
> > > On Mon, Aug 11, 2014 at 09:21:35AM +0100, Chris Wilson wrote:
> > > > During ring initialisation, sometimes we observe, though not in
> > > > production hardware, that the idle flag is not set even though the ring
> > > > is empty. Double check before giving up.
> > > >
> > > > Signed-off-by: Chris Wilson
> > > > Cc: Damien Lespiau
> > > > ---
> > > > drivers/gpu/drm/i915/intel_ringbuffer.c | 7 ++-
> > > > 1 file changed, 6 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
> > > > b/drivers/gpu/drm/i915/intel_ringbuffer.c
> > > > index a0831c309eab..d72d5e0e693d 100644
> > > > --- a/drivers/gpu/drm/i915/intel_ringbuffer.c
> > > > +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
> > > > @@ -467,7 +467,12 @@ static bool stop_ring(struct intel_engine_cs *ring)
> > > > I915_WRITE_MODE(ring, _MASKED_BIT_ENABLE(STOP_RING));
> > > > if (wait_for((I915_READ_MODE(ring) & MODE_IDLE) != 0,
> > > > 1000)) {
> > > > DRM_ERROR("%s : timed out trying to stop
> > > > ring\n", ring->name);
> > > > - return false;
> > > > + /* Sometimes we observe that the idle flag is
> > > > not
> > > > +* set even though the ring is empty. So double
> > > > +* check before giving up.
> > > > +*/
> > > > + if (I915_READ_HEAD(ring) !=
> > > > I915_READ_TAIL(ring))
> > > > + return false;
> > >
> > > That means we propably want to just put the user visible error message
> > > there as well?
> >
> > It is still a 1 second timeout, so having a warning there that something
> > is wrong is important I thought.
>
> Ah, I missed the "not in production hw" bits of the commit message, It
> may mean simulation and then the guess is that flag is not implemented.
> If that makes us not totally give up, I guess that's something.
I was trying to avoid saying that it was only to work around sim bugs :)
Otherwise, it looks to be a useful piece of paranoia and logging against
hw trying to screw us over.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Fix secure dispatch with full ppgtt
Based upon a hunk from a patch from Chris Wilson, but augmented to:
- Process the batch in the full ppgtt vm so that self-relocations
match again with userspace's expectations..
- Add a comment why plain pin for the global gtt binding is safe at
that point.
v2: Drop local bind_vm variable (Chris).
Cc: Chris Wilson
Cc: Ben Widawsky
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 42 ++
1 file changed, 19 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 6320a385841b..01fa9aa2b90e 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -95,7 +95,6 @@ eb_lookup_vmas(struct eb_vmas *eb,
struct i915_address_space *vm,
struct drm_file *file)
{
- struct drm_i915_private *dev_priv = vm->dev->dev_private;
struct drm_i915_gem_object *obj;
struct list_head objects;
int i, ret;
@@ -130,7 +129,6 @@ eb_lookup_vmas(struct eb_vmas *eb,
i = 0;
while (!list_empty(&objects)) {
struct i915_vma *vma;
- struct i915_address_space *bind_vm = vm;
if (exec[i].flags & EXEC_OBJECT_NEEDS_GTT &&
USES_FULL_PPGTT(vm->dev)) {
@@ -138,13 +136,6 @@ eb_lookup_vmas(struct eb_vmas *eb,
goto err;
}
- /* If we have secure dispatch, or the userspace assures us that
-* they know what they're doing, use the GGTT VM.
-*/
- if (((args->flags & I915_EXEC_SECURE) &&
- (i == (args->buffer_count - 1
- bind_vm = &dev_priv->gtt.base;
-
obj = list_first_entry(&objects,
struct drm_i915_gem_object,
obj_exec_link);
@@ -157,7 +148,7 @@ eb_lookup_vmas(struct eb_vmas *eb,
* from the (obj, vm) we don't run the risk of creating
* duplicated vmas for the same vm.
*/
- vma = i915_gem_obj_lookup_or_create_vma(obj, bind_vm);
+ vma = i915_gem_obj_lookup_or_create_vma(obj, vm);
if (IS_ERR(vma)) {
DRM_DEBUG("Failed to lookup VMA\n");
ret = PTR_ERR(vma);
@@ -1387,25 +1378,30 @@ i915_gem_do_execbuffer(struct drm_device *dev, void
*data,
/* snb/ivb/vlv conflate the "batch in ppgtt" bit with the "non-secure
* batch" bit. Hence we need to pin secure batches into the global gtt.
* hsw should have this fixed, but bdw mucks it up again. */
- if (flags & I915_DISPATCH_SECURE &&
- !batch_obj->has_global_gtt_mapping) {
- /* When we have multiple VMs, we'll need to make sure that we
-* allocate space first */
- struct i915_vma *vma = i915_gem_obj_to_ggtt(batch_obj);
- BUG_ON(!vma);
- vma->bind_vma(vma, batch_obj->cache_level, GLOBAL_BIND);
- }
+ if (flags & I915_DISPATCH_SECURE) {
+ /*
+* So on first glance it looks freaky that we pin the batch here
+* outside of the reservation loop. But:
+* - The batch is already pinned into the relevant ppgtt, so we
+* already have the backing storage fully allocated.
+* - No other BO uses the global gtt (well contexts, but meh),
+* so we don't really have issues with mutliple objects not
+* fitting due to fragmentation.
+* So this is actually safe.
+*/
+ ret = i915_gem_obj_ggtt_pin(batch_obj, 0, 0);
+ if (ret)
+ goto err;
- if (flags & I915_DISPATCH_SECURE)
exec_start += i915_gem_obj_ggtt_offset(batch_obj);
- else
+ } else
exec_start += i915_gem_obj_offset(batch_obj, vm);
ret = legacy_ringbuffer_submission(dev, file, ring, ctx,
- args, &eb->vmas, batch_obj, exec_start, flags);
- if (ret)
- goto err;
+ args, &eb->vmas, batch_obj,
exec_start, flags);
+ if (flags & I915_DISPATCH_SECURE)
+ i915_gem_object_ggtt_unpin(batch_obj);
err:
/* the request owns the ref now */
i915_gem_context_unreference(ctx);
--
2.0.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Double check ring is idle before declaring the GPU wedged
On Mon, Aug 11, 2014 at 10:35:25AM +0100, Chris Wilson wrote:
> On Mon, Aug 11, 2014 at 10:30:09AM +0100, Damien Lespiau wrote:
> > On Mon, Aug 11, 2014 at 09:21:35AM +0100, Chris Wilson wrote:
> > > During ring initialisation, sometimes we observe, though not in
> > > production hardware, that the idle flag is not set even though the ring
> > > is empty. Double check before giving up.
> > >
> > > Signed-off-by: Chris Wilson
> > > Cc: Damien Lespiau
> > > ---
> > > drivers/gpu/drm/i915/intel_ringbuffer.c | 7 ++-
> > > 1 file changed, 6 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
> > > b/drivers/gpu/drm/i915/intel_ringbuffer.c
> > > index a0831c309eab..d72d5e0e693d 100644
> > > --- a/drivers/gpu/drm/i915/intel_ringbuffer.c
> > > +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
> > > @@ -467,7 +467,12 @@ static bool stop_ring(struct intel_engine_cs *ring)
> > > I915_WRITE_MODE(ring, _MASKED_BIT_ENABLE(STOP_RING));
> > > if (wait_for((I915_READ_MODE(ring) & MODE_IDLE) != 0, 1000)) {
> > > DRM_ERROR("%s : timed out trying to stop ring\n",
> > > ring->name);
> > > - return false;
> > > + /* Sometimes we observe that the idle flag is not
> > > + * set even though the ring is empty. So double
> > > + * check before giving up.
> > > + */
> > > + if (I915_READ_HEAD(ring) != I915_READ_TAIL(ring))
> > > + return false;
> >
> > That means we propably want to just put the user visible error message
> > there as well?
>
> It is still a 1 second timeout, so having a warning there that something
> is wrong is important I thought.
Ah, I missed the "not in production hw" bits of the commit message, It
may mean simulation and then the guess is that flag is not implemented.
If that makes us not totally give up, I guess that's something.
Reviewed-by: Damien Lespiau
--
Damien
___
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: Copy PCI device id into the device info block
On Sat, 09 Aug 2014, Chris Wilson wrote:
> This is so that we can make the drm_i915_private->info always the
> preferred source for chipset type and feature queries.
Reviewed-by: Jani Nikula
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/i915/i915_dma.c | 5 +++--
> drivers/gpu/drm/i915/i915_drv.h | 50
> +
> 2 files changed, 29 insertions(+), 26 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
> index 96bf11e7a011..39988940d468 100644
> --- a/drivers/gpu/drm/i915/i915_dma.c
> +++ b/drivers/gpu/drm/i915/i915_dma.c
> @@ -1592,9 +1592,10 @@ int i915_driver_load(struct drm_device *dev, unsigned
> long flags)
> dev->dev_private = dev_priv;
> dev_priv->dev = dev;
>
> - /* copy initial configuration to dev_priv->info */
> + /* Setup the write-once "constant" device info */
> device_info = (struct intel_device_info *)&dev_priv->info;
> - *device_info = *info;
> + memcpy(device_info, info, sizeof(dev_priv->info));
> + device_info->device_id = dev->pdev->device;
>
> spin_lock_init(&dev_priv->irq_lock);
> spin_lock_init(&dev_priv->gpu_error.lock);
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index b3d42b085790..0aef763ffa75 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -563,6 +563,7 @@ struct intel_uncore {
>
> struct intel_device_info {
> u32 display_mmio_offset;
> + u16 device_id;
> u8 num_pipes:3;
> u8 num_sprites[I915_MAX_PIPES];
> u8 gen;
> @@ -2062,51 +2063,52 @@ struct drm_i915_cmd_table {
> int count;
> };
>
> -#define INTEL_INFO(dev) (&to_i915(dev)->info)
> +#define INTEL_INFO(p)(&to_i915(p)->info)
> +#define INTEL_DEVID(p) (INTEL_INFO(p)->device_id)
>
> -#define IS_I830(dev) ((dev)->pdev->device == 0x3577)
> -#define IS_845G(dev) ((dev)->pdev->device == 0x2562)
> +#define IS_I830(dev) (INTEL_DEVID(dev) == 0x3577)
> +#define IS_845G(dev) (INTEL_DEVID(dev) == 0x2562)
> #define IS_I85X(dev) (INTEL_INFO(dev)->is_i85x)
> -#define IS_I865G(dev)((dev)->pdev->device == 0x2572)
> +#define IS_I865G(dev)(INTEL_DEVID(dev) == 0x2572)
> #define IS_I915G(dev)(INTEL_INFO(dev)->is_i915g)
> -#define IS_I915GM(dev) ((dev)->pdev->device == 0x2592)
> -#define IS_I945G(dev)((dev)->pdev->device == 0x2772)
> +#define IS_I915GM(dev) (INTEL_DEVID(dev) == 0x2592)
> +#define IS_I945G(dev)(INTEL_DEVID(dev) == 0x2772)
> #define IS_I945GM(dev) (INTEL_INFO(dev)->is_i945gm)
> #define IS_BROADWATER(dev) (INTEL_INFO(dev)->is_broadwater)
> #define IS_CRESTLINE(dev)(INTEL_INFO(dev)->is_crestline)
> -#define IS_GM45(dev) ((dev)->pdev->device == 0x2A42)
> +#define IS_GM45(dev) (INTEL_DEVID(dev) == 0x2A42)
> #define IS_G4X(dev) (INTEL_INFO(dev)->is_g4x)
> -#define IS_PINEVIEW_G(dev) ((dev)->pdev->device == 0xa001)
> -#define IS_PINEVIEW_M(dev) ((dev)->pdev->device == 0xa011)
> +#define IS_PINEVIEW_G(dev) (INTEL_DEVID(dev) == 0xa001)
> +#define IS_PINEVIEW_M(dev) (INTEL_DEVID(dev) == 0xa011)
> #define IS_PINEVIEW(dev) (INTEL_INFO(dev)->is_pineview)
> #define IS_G33(dev) (INTEL_INFO(dev)->is_g33)
> -#define IS_IRONLAKE_M(dev) ((dev)->pdev->device == 0x0046)
> +#define IS_IRONLAKE_M(dev) (INTEL_DEVID(dev) == 0x0046)
> #define IS_IVYBRIDGE(dev)(INTEL_INFO(dev)->is_ivybridge)
> -#define IS_IVB_GT1(dev) ((dev)->pdev->device == 0x0156 || \
> - (dev)->pdev->device == 0x0152 || \
> - (dev)->pdev->device == 0x015a)
> -#define IS_SNB_GT1(dev) ((dev)->pdev->device == 0x0102 || \
> - (dev)->pdev->device == 0x0106 || \
> - (dev)->pdev->device == 0x010A)
> +#define IS_IVB_GT1(dev) (INTEL_DEVID(dev) == 0x0156 || \
> + INTEL_DEVID(dev) == 0x0152 || \
> + INTEL_DEVID(dev) == 0x015a)
> +#define IS_SNB_GT1(dev) (INTEL_DEVID(dev) == 0x0102 || \
> + INTEL_DEVID(dev) == 0x0106 || \
> + INTEL_DEVID(dev) == 0x010A)
> #define IS_VALLEYVIEW(dev) (INTEL_INFO(dev)->is_valleyview)
> #define IS_CHERRYVIEW(dev) (INTEL_INFO(dev)->is_valleyview && IS_GEN8(dev))
> #define IS_HASWELL(dev) (INTEL_INFO(dev)->is_haswell)
> #define IS_BROADWELL(dev)(!INTEL_INFO(dev)->is_valleyview &&
> IS_GEN8(dev))
> #define IS_MOBILE(dev) (INTEL_INFO(dev)->is_mobile)
> #define IS_HSW_EARLY_SDV(dev)(IS_HASWELL(dev) && \
> - ((dev)->pdev->device & 0xFF00) == 0x0C00)
> + (INTEL_DEVID(dev) & 0xFF00) == 0
[Intel-gfx] [PATCH] drm/i915: Fix secure dispatch with full ppgtt
Based upon a hunk from a patch from Chris Wilson, but augmented to:
- Process the batch in the full ppgtt vm so that self-relocations
match again with userspace's expectations..
- Add a comment why plain pin for the global gtt binding is safe at
that point.
Cc: Chris Wilson
Cc: Ben Widawsky
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 38 ++
1 file changed, 18 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 6320a385841b..697b3d5f161a 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -138,13 +138,6 @@ eb_lookup_vmas(struct eb_vmas *eb,
goto err;
}
- /* If we have secure dispatch, or the userspace assures us that
-* they know what they're doing, use the GGTT VM.
-*/
- if (((args->flags & I915_EXEC_SECURE) &&
- (i == (args->buffer_count - 1
- bind_vm = &dev_priv->gtt.base;
-
obj = list_first_entry(&objects,
struct drm_i915_gem_object,
obj_exec_link);
@@ -1387,25 +1380,30 @@ i915_gem_do_execbuffer(struct drm_device *dev, void
*data,
/* snb/ivb/vlv conflate the "batch in ppgtt" bit with the "non-secure
* batch" bit. Hence we need to pin secure batches into the global gtt.
* hsw should have this fixed, but bdw mucks it up again. */
- if (flags & I915_DISPATCH_SECURE &&
- !batch_obj->has_global_gtt_mapping) {
- /* When we have multiple VMs, we'll need to make sure that we
-* allocate space first */
- struct i915_vma *vma = i915_gem_obj_to_ggtt(batch_obj);
- BUG_ON(!vma);
- vma->bind_vma(vma, batch_obj->cache_level, GLOBAL_BIND);
- }
+ if (flags & I915_DISPATCH_SECURE) {
+ /*
+* So on first glance it looks freaky that we pin the batch here
+* outside of the reservation loop. But:
+* - The batch is already pinned into the relevant ppgtt, so we
+* already have the backing storage fully allocated.
+* - No other BO uses the global gtt (well contexts, but meh),
+* so we don't really have issues with mutliple objects not
+* fitting due to fragmentation.
+* So this is actually safe.
+*/
+ ret = i915_gem_obj_ggtt_pin(batch_obj, 0, 0);
+ if (ret)
+ goto err;
- if (flags & I915_DISPATCH_SECURE)
exec_start += i915_gem_obj_ggtt_offset(batch_obj);
- else
+ } else
exec_start += i915_gem_obj_offset(batch_obj, vm);
ret = legacy_ringbuffer_submission(dev, file, ring, ctx,
- args, &eb->vmas, batch_obj, exec_start, flags);
- if (ret)
- goto err;
+ args, &eb->vmas, batch_obj,
exec_start, flags);
+ if (flags & I915_DISPATCH_SECURE)
+ i915_gem_object_ggtt_unpin(batch_obj);
err:
/* the request owns the ref now */
i915_gem_context_unreference(ctx);
--
2.0.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Force CPU relocations if not GTT mapped
On Sun, Aug 10, 2014 at 08:06:57AM +0100, Chris Wilson wrote:
> Move the decision on whether we need to have a mappable object during
> execbuffer to the fore and then reuse that decision by propagating the
> flag through to reservation. As a corollary, before doing the actual
> relocation through the GTT, we can make sure that we do have a GTT
> mapping through which to operate.
>
> v2: Revamp and resend to ease future patches.
> v3: Refresh patch rationale
>
> References: https://bugs.freedesktop.org/show_bug.cgi?id=81094
> Signed-off-by: Chris Wilson
> Cc: Ben Widawsky
> Cc: Daniel Vetter
Ok, the secure batch hunk in here looks rather unrelated and imo also a
bit incomplete. I've dropped it. And I've added a bit of text to the
commit message to explain why this patch touches map_and_fenceable logic.
-Daniel
> ---
> drivers/gpu/drm/i915/i915_gem.c| 8 +--
> drivers/gpu/drm/i915/i915_gem_execbuffer.c | 80
> ++
> 2 files changed, 42 insertions(+), 46 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 99250d27668d..6366230c4e32 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -2930,9 +2930,8 @@ int i915_vma_unbind(struct i915_vma *vma)
> vma->unbind_vma(vma);
>
> list_del_init(&vma->mm_list);
> - /* Avoid an unnecessary call to unbind on rebind. */
> if (i915_is_ggtt(vma->vm))
> - obj->map_and_fenceable = true;
> + obj->map_and_fenceable = false;
>
> drm_mm_remove_node(&vma->node);
> i915_gem_vma_destroy(vma);
> @@ -3284,6 +3283,9 @@ i915_gem_object_get_fence(struct drm_i915_gem_object
> *obj)
> return 0;
> }
> } else if (enable) {
> + if (WARN_ON(!obj->map_and_fenceable))
> + return -EINVAL;
> +
> reg = i915_find_fence_reg(dev);
> if (IS_ERR(reg))
> return PTR_ERR(reg);
> @@ -4333,8 +4335,6 @@ void i915_gem_object_init(struct drm_i915_gem_object
> *obj,
>
> obj->fence_reg = I915_FENCE_REG_NONE;
> obj->madv = I915_MADV_WILLNEED;
> - /* Avoid an unnecessary call to unbind on the first bind. */
> - obj->map_and_fenceable = true;
>
> i915_gem_info_add_obj(obj->base.dev->dev_private, obj->base.size);
> }
> diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> index 60998fc4e5b2..8b734d5d16b4 100644
> --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> @@ -35,6 +35,7 @@
>
> #define __EXEC_OBJECT_HAS_PIN (1<<31)
> #define __EXEC_OBJECT_HAS_FENCE (1<<30)
> +#define __EXEC_OBJECT_NEEDS_MAP (1<<29)
> #define __EXEC_OBJECT_NEEDS_BIAS (1<<28)
>
> #define BATCH_OFFSET_BIAS (256*1024)
> @@ -535,14 +536,6 @@ i915_gem_execbuffer_relocate(struct eb_vmas *eb)
> }
>
> static int
> -need_reloc_mappable(struct i915_vma *vma)
> -{
> - struct drm_i915_gem_exec_object2 *entry = vma->exec_entry;
> - return entry->relocation_count && !use_cpu_reloc(vma->obj) &&
> - i915_is_ggtt(vma->vm);
> -}
> -
> -static int
> i915_gem_execbuffer_reserve_vma(struct i915_vma *vma,
> struct intel_engine_cs *ring,
> bool *need_reloc)
> @@ -550,19 +543,12 @@ i915_gem_execbuffer_reserve_vma(struct i915_vma *vma,
> struct drm_i915_gem_object *obj = vma->obj;
> struct drm_i915_gem_exec_object2 *entry = vma->exec_entry;
> bool has_fenced_gpu_access = INTEL_INFO(ring->dev)->gen < 4;
> - bool need_fence;
> uint64_t flags;
> int ret;
>
> flags = 0;
> -
> - need_fence =
> - has_fenced_gpu_access &&
> - entry->flags & EXEC_OBJECT_NEEDS_FENCE &&
> - obj->tiling_mode != I915_TILING_NONE;
> - if (need_fence || need_reloc_mappable(vma))
> + if (entry->flags & __EXEC_OBJECT_NEEDS_MAP)
> flags |= PIN_MAPPABLE;
> -
> if (entry->flags & EXEC_OBJECT_NEEDS_GTT)
> flags |= PIN_GLOBAL;
> if (entry->flags & __EXEC_OBJECT_NEEDS_BIAS)
> @@ -601,26 +587,40 @@ i915_gem_execbuffer_reserve_vma(struct i915_vma *vma,
> }
>
> static bool
> -eb_vma_misplaced(struct i915_vma *vma, bool has_fenced_gpu_access)
> +need_reloc_mappable(struct i915_vma *vma)
> {
> struct drm_i915_gem_exec_object2 *entry = vma->exec_entry;
> - struct drm_i915_gem_object *obj = vma->obj;
> - bool need_fence, need_mappable;
>
> - need_fence =
> - has_fenced_gpu_access &&
> - entry->flags & EXEC_OBJECT_NEEDS_FENCE &&
> - obj->tiling_mode != I915_TILING_NONE;
> - need_mappable = need_fence || need_reloc_mappable(vma);
> + if (entry->relocation_count == 0)
> + return false;
>
> - WARN_ON((need_mappable || need_fence) &&
> + if (!i915_is_gg
Re: [Intel-gfx] [PATCH 2/3] drm/i915: Remove an unreachable 'return'
On Sat, Aug 09, 2014 at 11:00:57PM +0100, Damien Lespiau wrote: > Running smatch adds quite a few checks to what sparse is doing. This is > one of them. > > Signed-off-by: Damien Lespiau > --- > drivers/gpu/drm/i915/intel_display.c | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/intel_display.c > b/drivers/gpu/drm/i915/intel_display.c > index 4b89447..a6af1b2 100644 > --- a/drivers/gpu/drm/i915/intel_display.c > +++ b/drivers/gpu/drm/i915/intel_display.c > @@ -8646,7 +8646,6 @@ void intel_release_load_detect_pipe(struct > drm_connector *connector, > } > > goto unlock; > - return; I have a locking fix that removes the goto and keeps the return :) I'll send it out now. > } > > /* Switch crtc and encoder back off if necessary */ > -- > 1.8.3.1 > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Ville Syrjälä Intel OTC ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/3] drm/i915: Only perform set-to-gtt domain for objects bound to the global gtt
On Sat, Aug 09, 2014 at 05:37:22PM +0100, Chris Wilson wrote:
> If an object is not bound into the global GTT, then it cannot be
> accessed via the GTT. This restores the original code that was muddled
> by ppGTT. In the process, we remove a WARN that had long outlived its
> usefulness and was simply being coded around instead.
>
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/i915/i915_gem.c | 22 +-
> 1 file changed, 5 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 80b807b724a6..99250d27668d 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -3594,11 +3594,12 @@ int
> i915_gem_object_set_to_gtt_domain(struct drm_i915_gem_object *obj, bool
> write)
> {
> struct drm_i915_private *dev_priv = obj->base.dev->dev_private;
> + struct i915_vma *vma = i915_gem_obj_to_ggtt(obj);
> uint32_t old_write_domain, old_read_domains;
> int ret;
>
> /* Not valid to be called on unbound objects. */
> - if (!i915_gem_obj_bound_any(obj))
> + if (vma == NULL)
> return -EINVAL;
>
> if (obj->base.write_domain == I915_GEM_DOMAIN_GTT)
> @@ -3640,13 +3641,9 @@ i915_gem_object_set_to_gtt_domain(struct
> drm_i915_gem_object *obj, bool write)
> old_write_domain);
>
> /* And bump the LRU for this access */
> - if (i915_gem_object_is_inactive(obj)) {
> - struct i915_vma *vma = i915_gem_obj_to_ggtt(obj);
> - if (vma)
> - list_move_tail(&vma->mm_list,
> -&dev_priv->gtt.base.inactive_list);
> -
> - }
> + if (i915_gem_object_is_inactive(obj))
Ben will put a few more needles into his danvet voodoo doll, but I guess
this here is a fairly clear indicator that tracking the active bit on the
object instead of the vma wasn't an awesome idea ...
Anyway, patch looks good, merged.
-Daniel
> + list_move_tail(&vma->mm_list,
> +&dev_priv->gtt.base.inactive_list);
>
> return 0;
> }
> @@ -3810,9 +3807,6 @@ static bool is_pin_display(struct drm_i915_gem_object
> *obj)
> {
> struct i915_vma *vma;
>
> - if (list_empty(&obj->vma_list))
> - return false;
> -
> vma = i915_gem_obj_to_ggtt(obj);
> if (!vma)
> return false;
> @@ -5255,12 +5249,6 @@ struct i915_vma *i915_gem_obj_to_ggtt(struct
> drm_i915_gem_object *obj)
> {
> struct i915_vma *vma;
>
> - /* This WARN has probably outlived its usefulness (callers already
> - * WARN if they don't find the GGTT vma they expect). When removing,
> - * remember to remove the pre-check in is_pin_display() as well */
> - if (WARN_ON(list_empty(&obj->vma_list)))
> - return NULL;
> -
> vma = list_first_entry(&obj->vma_list, typeof(*vma), vma_link);
> if (vma->vm != obj_to_ggtt(obj))
> return NULL;
> --
> 2.1.0.rc1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Double check ring is idle before declaring the GPU wedged
On Mon, Aug 11, 2014 at 10:30:09AM +0100, Damien Lespiau wrote:
> On Mon, Aug 11, 2014 at 09:21:35AM +0100, Chris Wilson wrote:
> > During ring initialisation, sometimes we observe, though not in
> > production hardware, that the idle flag is not set even though the ring
> > is empty. Double check before giving up.
> >
> > Signed-off-by: Chris Wilson
> > Cc: Damien Lespiau
> > ---
> > drivers/gpu/drm/i915/intel_ringbuffer.c | 7 ++-
> > 1 file changed, 6 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
> > b/drivers/gpu/drm/i915/intel_ringbuffer.c
> > index a0831c309eab..d72d5e0e693d 100644
> > --- a/drivers/gpu/drm/i915/intel_ringbuffer.c
> > +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
> > @@ -467,7 +467,12 @@ static bool stop_ring(struct intel_engine_cs *ring)
> > I915_WRITE_MODE(ring, _MASKED_BIT_ENABLE(STOP_RING));
> > if (wait_for((I915_READ_MODE(ring) & MODE_IDLE) != 0, 1000)) {
> > DRM_ERROR("%s : timed out trying to stop ring\n",
> > ring->name);
> > - return false;
> > + /* Sometimes we observe that the idle flag is not
> > +* set even though the ring is empty. So double
> > +* check before giving up.
> > +*/
> > + if (I915_READ_HEAD(ring) != I915_READ_TAIL(ring))
> > + return false;
>
> That means we propably want to just put the user visible error message
> there as well?
It is still a 1 second timeout, so having a warning there that something
is wrong is important I thought.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Double check ring is idle before declaring the GPU wedged
On Mon, Aug 11, 2014 at 09:21:35AM +0100, Chris Wilson wrote:
> During ring initialisation, sometimes we observe, though not in
> production hardware, that the idle flag is not set even though the ring
> is empty. Double check before giving up.
>
> Signed-off-by: Chris Wilson
> Cc: Damien Lespiau
> ---
> drivers/gpu/drm/i915/intel_ringbuffer.c | 7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
> b/drivers/gpu/drm/i915/intel_ringbuffer.c
> index a0831c309eab..d72d5e0e693d 100644
> --- a/drivers/gpu/drm/i915/intel_ringbuffer.c
> +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
> @@ -467,7 +467,12 @@ static bool stop_ring(struct intel_engine_cs *ring)
> I915_WRITE_MODE(ring, _MASKED_BIT_ENABLE(STOP_RING));
> if (wait_for((I915_READ_MODE(ring) & MODE_IDLE) != 0, 1000)) {
> DRM_ERROR("%s : timed out trying to stop ring\n",
> ring->name);
> - return false;
> + /* Sometimes we observe that the idle flag is not
> + * set even though the ring is empty. So double
> + * check before giving up.
> + */
> + if (I915_READ_HEAD(ring) != I915_READ_TAIL(ring))
> + return false;
That means we propably want to just put the user visible error message
there as well?
--
Damien
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Fix wrong number of HDMI translation entries
On Mon, Aug 11, 2014 at 11:22:51AM +0300, Jani Nikula wrote:
> On Sat, 09 Aug 2014, Damien Lespiau wrote:
> > I keep telling myself that those tables aren't great because their size
> > is the number of dwords we need to program and not the number of entries
> > (number of dwords = number of entries * 2).
> >
> > And... I got it wrong when I refactored the code. Fortunately, it was
> > only wrong when the VBT table (or the code parsing it) is itself
> > erroneous. Long story short, it shouldn't matter, but still, there's a
> > potential array overflow and random programming of the DDI translation
> > tables.
>
> Ugh I looked at the code. I think it would benefit from making the
> tables have the right amount of entries, with struct { u32 hi, lo; } for
> each element. I also dislike the ARRAY_SIZE(hsw_ddi_translations_fdi) in
> the first loop, and magic 2 in the second. But that's for a rainy day.
>
> Reviewed-by: Jani Nikula
Queued for -next, thanks for the patch.
-Daniel
>
> >
> > Cc: Paulo Zanoni
> > Signed-off-by: Damien Lespiau
> > ---
> > drivers/gpu/drm/i915/intel_ddi.c | 6 +++---
> > 1 file changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> > b/drivers/gpu/drm/i915/intel_ddi.c
> > index ca1f9a8..02d5584 100644
> > --- a/drivers/gpu/drm/i915/intel_ddi.c
> > +++ b/drivers/gpu/drm/i915/intel_ddi.c
> > @@ -169,14 +169,14 @@ static void intel_prepare_ddi_buffers(struct
> > drm_device *dev, enum port port)
> > ddi_translations_dp = bdw_ddi_translations_dp;
> > ddi_translations_edp = bdw_ddi_translations_edp;
> > ddi_translations_hdmi = bdw_ddi_translations_hdmi;
> > - n_hdmi_entries = ARRAY_SIZE(bdw_ddi_translations_hdmi);
> > + n_hdmi_entries = ARRAY_SIZE(bdw_ddi_translations_hdmi) / 2;
> > hdmi_800mV_0dB = 7;
> > } else if (IS_HASWELL(dev)) {
> > ddi_translations_fdi = hsw_ddi_translations_fdi;
> > ddi_translations_dp = hsw_ddi_translations_dp;
> > ddi_translations_edp = hsw_ddi_translations_dp;
> > ddi_translations_hdmi = hsw_ddi_translations_hdmi;
> > - n_hdmi_entries = ARRAY_SIZE(hsw_ddi_translations_hdmi);
> > + n_hdmi_entries = ARRAY_SIZE(hsw_ddi_translations_hdmi) / 2;
> > hdmi_800mV_0dB = 6;
> > } else {
> > WARN(1, "ddi translation table missing\n");
> > @@ -184,7 +184,7 @@ static void intel_prepare_ddi_buffers(struct drm_device
> > *dev, enum port port)
> > ddi_translations_fdi = bdw_ddi_translations_fdi;
> > ddi_translations_dp = bdw_ddi_translations_dp;
> > ddi_translations_hdmi = bdw_ddi_translations_hdmi;
> > - n_hdmi_entries = ARRAY_SIZE(bdw_ddi_translations_hdmi);
> > + n_hdmi_entries = ARRAY_SIZE(bdw_ddi_translations_hdmi) / 2;
> > hdmi_800mV_0dB = 7;
> > }
> >
> > --
> > 1.8.3.1
> >
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
> --
> Jani Nikula, Intel Open Source Technology Center
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915: Continuation of future readiness series
On Mon, Aug 11, 2014 at 09:06:39AM +0530, sonika.jin...@intel.com wrote:
> From: Sonika Jindal
>
> Removing the check for HAS_PCH_SPLIT, it looks redundant here. Anyways all the
> platforms are checked separately.
>
> v2: Reordering as per the gen (Ville)
>
> Signed-off-by: Sonika Jindal
Queued for -next, thanks for the patch.
-Daniel
> ---
> drivers/gpu/drm/i915/intel_display.c | 42
> --
> 1 file changed, 20 insertions(+), 22 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 89e0ac5..7e0b68a 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -12421,29 +12421,27 @@ static void intel_init_display(struct drm_device
> *dev)
> dev_priv->display.get_display_clock_speed =
> i830_get_display_clock_speed;
>
> - if (HAS_PCH_SPLIT(dev)) {
> - if (IS_GEN5(dev)) {
> - dev_priv->display.fdi_link_train =
> ironlake_fdi_link_train;
> - dev_priv->display.write_eld = ironlake_write_eld;
> - } else if (IS_GEN6(dev)) {
> - dev_priv->display.fdi_link_train = gen6_fdi_link_train;
> - dev_priv->display.write_eld = ironlake_write_eld;
> - dev_priv->display.modeset_global_resources =
> - snb_modeset_global_resources;
> - } else if (IS_IVYBRIDGE(dev)) {
> - /* FIXME: detect B0+ stepping and use auto training */
> - dev_priv->display.fdi_link_train =
> ivb_manual_fdi_link_train;
> - dev_priv->display.write_eld = ironlake_write_eld;
> - dev_priv->display.modeset_global_resources =
> - ivb_modeset_global_resources;
> - } else if (IS_HASWELL(dev) || IS_GEN8(dev)) {
> - dev_priv->display.fdi_link_train = hsw_fdi_link_train;
> - dev_priv->display.write_eld = haswell_write_eld;
> - dev_priv->display.modeset_global_resources =
> - haswell_modeset_global_resources;
> - }
> - } else if (IS_G4X(dev)) {
> + if (IS_G4X(dev)) {
> dev_priv->display.write_eld = g4x_write_eld;
> + } else if (IS_GEN5(dev)) {
> + dev_priv->display.fdi_link_train = ironlake_fdi_link_train;
> + dev_priv->display.write_eld = ironlake_write_eld;
> + } else if (IS_GEN6(dev)) {
> + dev_priv->display.fdi_link_train = gen6_fdi_link_train;
> + dev_priv->display.write_eld = ironlake_write_eld;
> + dev_priv->display.modeset_global_resources =
> + snb_modeset_global_resources;
> + } else if (IS_IVYBRIDGE(dev)) {
> + /* FIXME: detect B0+ stepping and use auto training */
> + dev_priv->display.fdi_link_train = ivb_manual_fdi_link_train;
> + dev_priv->display.write_eld = ironlake_write_eld;
> + dev_priv->display.modeset_global_resources =
> + ivb_modeset_global_resources;
> + } else if (IS_HASWELL(dev) || IS_GEN8(dev)) {
> + dev_priv->display.fdi_link_train = hsw_fdi_link_train;
> + dev_priv->display.write_eld = haswell_write_eld;
> + dev_priv->display.modeset_global_resources =
> + haswell_modeset_global_resources;
> } else if (IS_VALLEYVIEW(dev)) {
> dev_priv->display.modeset_global_resources =
> valleyview_modeset_global_resources;
> --
> 1.7.10.4
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] [v2] drm/i915: Fix another another use-after-free in do_switch
On Sun, Aug 10, 2014 at 09:04:10AM +0100, Chris Wilson wrote: > On Sat, Aug 09, 2014 at 01:15:16PM -0700, Ben Widawsky wrote: > > See the following for many more details. > > > > commit acc240d41ea1ab9c488a79219fb313b5b46265ae > > Author: Daniel Vetter > > Date: Thu Dec 5 15:42:34 2013 +0100 > > > > drm/i915: Fix use-after-free in do_switch > > > > In this case, the issue is only for full PPGTT: > > do_switch > > context_unref > > ppgtt_release > > i915_gpu_idle > > switch_to_default > > from changes to default context Pardon my ignorance (well this stuff is just hard), but can the above still happen with Michel Thierry's patch to rework ppgtt_release? In particular I seem to be too dense to find the ppgtt_release -> gpu_idle step once the forcefull vma unbinding is gone. Doe I miss something? Someone please enlighten me ... Thanks, Daniel > > > > This could be backported to the pre do_switch cleanup I did in this > > series. However, it's much cleaner and more obvious as a patch on top, > > so I'd really like to do this as a post cleanup patch. > > > > v2: There was a bug in the original patch where the ring->last_context > > was set too early. I am not sure how this wasn't being hit when I sent > > this previously. Perhaps I tested the wrong patch previously. > > > > Signed-off-by: Ben Widawsky > > Ok, I convinced myself that the you are fixing the bug you describe and > don't seem to be introducing a new one, so > > Reviewed-by: Chris Wilson > -Chris > > -- > Chris Wilson, Intel Open Source Technology Centre > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] WARNING on i915 - intel_panel
On Mon, Aug 11, 2014 at 12:38:41AM +0100, Pedro Ribeiro wrote: > On 2 June 2014 21:15, Pedro Ribeiro wrote: > > On 27 May 2014 08:15, Daniel Vetter wrote: > >> On Mon, May 26, 2014 at 9:44 PM, Pedro Ribeiro wrote: > >>> Kern.log is attached, but as you can see it does not contain the same > >>> verbose drm debug information as dmesg... Should I just keep piping > >>> dmesg to a file and then cat it all together? > >>> I never really understood why there are so many logs: kern, messages, > >>> syslog, instead of a single central log. > >> > >> Indeed, that one isn't useful either :( Next idea: Increase the > >> in-kernel dmesg buffer size and hope it all fits with log_buf_size=4M > >> (on the kernel cmdline). Maybe you can go even higher, not sure. > >> -Daniel > >> -- > >> Daniel Vetter > >> Software Engineer, Intel Corporation > >> +41 (0) 79 365 57 48 - http://blog.ffwll.ch > > > > Daniel, doesn't seem like that is working. > > > > I'll leave it be and try to test new kernels and see if it just goes > > away. I'll report back if it doesn't. > > > > Regards, > > Pedro > > Hi Daniel, > > the problem is still there with the latest 3.14.14. But the good news > is that I have finally been able to get a full dmesg log! > Please find it attached. I hope this helps and let me know what else I > need to do to assist. > > The log shows two hibernate-resume cycles, and you can see the bug > being triggered at line 4274. As I said previously this looks like it > doesn't affect the operation much, although it seems to happen very > frequently as I do more hibernate cycles. Yeah, log looks interesting, but I don't immediately see what's wrong. Can you please fiel a new bug on bugs.freedeskopt.org against DRI -> DRM (Intel) and please don't forget to put [regression] into the summary. Also, if you manually disable the lvds with e.g. $ xrandr --output LVDS1 --off ; xrandr --output LVDS1 --auto does it happen, too? Or do you only see this over a hibernate cycle? > PS: if I hibernate with a external monitor connected, and resume > without that monitor connected, will the kernel handle it correctly? Well the kernel won't do much, but it will generate a hotplug event to inform userspace that the configuration changed. Then userspace needs to figure out what to do - by default we keep pumping pixels to the screen presuming that the cable fell out for a bit and that the user will replug. But a good DE reconfigures or shows you a dialog box on one of the remaining enabled screens. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Fix wrong number of HDMI translation entries
On Sat, 09 Aug 2014, Damien Lespiau wrote:
> I keep telling myself that those tables aren't great because their size
> is the number of dwords we need to program and not the number of entries
> (number of dwords = number of entries * 2).
>
> And... I got it wrong when I refactored the code. Fortunately, it was
> only wrong when the VBT table (or the code parsing it) is itself
> erroneous. Long story short, it shouldn't matter, but still, there's a
> potential array overflow and random programming of the DDI translation
> tables.
Ugh I looked at the code. I think it would benefit from making the
tables have the right amount of entries, with struct { u32 hi, lo; } for
each element. I also dislike the ARRAY_SIZE(hsw_ddi_translations_fdi) in
the first loop, and magic 2 in the second. But that's for a rainy day.
Reviewed-by: Jani Nikula
>
> Cc: Paulo Zanoni
> Signed-off-by: Damien Lespiau
> ---
> drivers/gpu/drm/i915/intel_ddi.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> b/drivers/gpu/drm/i915/intel_ddi.c
> index ca1f9a8..02d5584 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -169,14 +169,14 @@ static void intel_prepare_ddi_buffers(struct drm_device
> *dev, enum port port)
> ddi_translations_dp = bdw_ddi_translations_dp;
> ddi_translations_edp = bdw_ddi_translations_edp;
> ddi_translations_hdmi = bdw_ddi_translations_hdmi;
> - n_hdmi_entries = ARRAY_SIZE(bdw_ddi_translations_hdmi);
> + n_hdmi_entries = ARRAY_SIZE(bdw_ddi_translations_hdmi) / 2;
> hdmi_800mV_0dB = 7;
> } else if (IS_HASWELL(dev)) {
> ddi_translations_fdi = hsw_ddi_translations_fdi;
> ddi_translations_dp = hsw_ddi_translations_dp;
> ddi_translations_edp = hsw_ddi_translations_dp;
> ddi_translations_hdmi = hsw_ddi_translations_hdmi;
> - n_hdmi_entries = ARRAY_SIZE(hsw_ddi_translations_hdmi);
> + n_hdmi_entries = ARRAY_SIZE(hsw_ddi_translations_hdmi) / 2;
> hdmi_800mV_0dB = 6;
> } else {
> WARN(1, "ddi translation table missing\n");
> @@ -184,7 +184,7 @@ static void intel_prepare_ddi_buffers(struct drm_device
> *dev, enum port port)
> ddi_translations_fdi = bdw_ddi_translations_fdi;
> ddi_translations_dp = bdw_ddi_translations_dp;
> ddi_translations_hdmi = bdw_ddi_translations_hdmi;
> - n_hdmi_entries = ARRAY_SIZE(bdw_ddi_translations_hdmi);
> + n_hdmi_entries = ARRAY_SIZE(bdw_ddi_translations_hdmi) / 2;
> hdmi_800mV_0dB = 7;
> }
>
> --
> 1.8.3.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Double check ring is idle before declaring the GPU wedged
During ring initialisation, sometimes we observe, though not in
production hardware, that the idle flag is not set even though the ring
is empty. Double check before giving up.
Signed-off-by: Chris Wilson
Cc: Damien Lespiau
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index a0831c309eab..d72d5e0e693d 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -467,7 +467,12 @@ static bool stop_ring(struct intel_engine_cs *ring)
I915_WRITE_MODE(ring, _MASKED_BIT_ENABLE(STOP_RING));
if (wait_for((I915_READ_MODE(ring) & MODE_IDLE) != 0, 1000)) {
DRM_ERROR("%s : timed out trying to stop ring\n",
ring->name);
- return false;
+ /* Sometimes we observe that the idle flag is not
+* set even though the ring is empty. So double
+* check before giving up.
+*/
+ if (I915_READ_HEAD(ring) != I915_READ_TAIL(ring))
+ return false;
}
}
--
2.1.0.rc1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
