Re: [Intel-gfx] [PATCH] drm/i915: Check for driver readyness before handling an underrun interrupt
On Fri, 27 Feb 2015, Jani Nikula wrote:
> On Thu, 26 Feb 2015, Chris Wilson wrote:
>> When we takeover from the BIOS and install our interrupt handler, the
>> BIOS may have left us a few surprises in the form of spontaneous
>> interrupts. (This is especially likely on hardware like 965gm where
>> display fifo underruns are continuous and the GMCH cannot filter that
>> interrupt souce.) As we enable our IRQ early so that we can use it
>> during hardware probing, our interrupt handler must be prepared to
>> handle a few sources prior to being fully configured. As such, we need
>> to add a simple is-ready check prior to dereferencing our KMS state for
>> reporting underruns.
>>
>> Reported-by: Rob Clark
>> Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1193972
>
> "You are not authorized to access bug #1193972. To see this bug, you
> must first log in to an account with the appropriate permissions."
>
> Meh.
Pushed to drm-intel-fixes, thanks for the patch and review. If someone
both cares and has access to the bugzilla, please update it.
BR,
Jani.
>
>> Signed-off-by: Chris Wilson
>> Reviewed-by: Daniel Vetter
>> Cc: sta...@vger.kernel.org
>> ---
>> drivers/gpu/drm/i915/intel_fifo_underrun.c | 18 +++---
>> 1 file changed, 7 insertions(+), 11 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_fifo_underrun.c
>> b/drivers/gpu/drm/i915/intel_fifo_underrun.c
>> index 04e248dd2259..f2fd992e3cd8 100644
>> --- a/drivers/gpu/drm/i915/intel_fifo_underrun.c
>> +++ b/drivers/gpu/drm/i915/intel_fifo_underrun.c
>> @@ -282,16 +282,6 @@ bool intel_set_cpu_fifo_underrun_reporting(struct
>> drm_i915_private *dev_priv,
>> return ret;
>> }
>>
>> -static bool
>> -__cpu_fifo_underrun_reporting_enabled(struct drm_i915_private *dev_priv,
>> - enum pipe pipe)
>> -{
>> -struct drm_crtc *crtc = dev_priv->pipe_to_crtc_mapping[pipe];
>> -struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
>> -
>> -return !intel_crtc->cpu_fifo_underrun_disabled;
>> -}
>> -
>> /**
>> * intel_set_pch_fifo_underrun_reporting - set PCH fifo underrun reporting
>> state
>> * @dev_priv: i915 device instance
>> @@ -352,9 +342,15 @@ bool intel_set_pch_fifo_underrun_reporting(struct
>> drm_i915_private *dev_priv,
>> void intel_cpu_fifo_underrun_irq_handler(struct drm_i915_private *dev_priv,
>> enum pipe pipe)
>> {
>> +struct drm_crtc *crtc = dev_priv->pipe_to_crtc_mapping[pipe];
>> +
>> +/* We may be called too early in init, thanks BIOS! */
>> +if (crtc == NULL)
>> +return;
>> +
>> /* GMCH can't disable fifo underruns, filter them. */
>> if (HAS_GMCH_DISPLAY(dev_priv->dev) &&
>> -!__cpu_fifo_underrun_reporting_enabled(dev_priv, pipe))
>> +!to_intel_crtc(crtc)->cpu_fifo_underrun_disabled)
>> return;
>>
>> if (intel_set_cpu_fifo_underrun_reporting(dev_priv, pipe, false))
>> --
>> 2.1.4
>>
>> ___
>> Intel-gfx mailing list
>> Intel-gfx@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
> --
> Jani Nikula, Intel Open Source Technology Center
--
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Check DVO reads for errors
On Thu, Feb 26, 2015 at 10:09:49PM +, Chris Wilson wrote: > On Thu, Feb 26, 2015 at 06:47:14PM +0100, Quentin Casasnovas wrote: > > On Thu, Feb 26, 2015 at 05:10:17PM +, Chris Wilson wrote: > > > Not all of the DVO functions were checking the return value from their > > > i2c routines when reading registers. This could lead to us feeding > > > garbage values back into the hardware, possible causing further > > > failures. In some cases the uninitialised stack values were being > > > written into the kernel log. > > > > > > Quentin Casasnovas suggested the simple solution of just initialising > > > the output parameter to zero in all cases, but we may as well spend the > > > extra few moments to fix it correctly. > > > > I'm not sure your patch would be -stable material mainly because of the > > diffstat. Given the security implications, I would still rather have my > > patch merged first so it can easily be back-ported to -stable and distro > > kernels easily, and then have your patch on top when it gets properly > > reviewed. Especially since your patch looks like it's doing other > > not strictly related stuffs like these: > > I don't agree that your patch is stable material since it is not > obviously correct (it potentially changes values written to hw), hasn't > been tested and doesn't qualify as a "real bug that impacts people". > I must admit I'm not quite sure what you mean by saying it potentially changes values written to the hardware. IIRC, in the current code, we might be writting garbage values from the stack to the hardware (so hard to tell in that case what is it we are writting..), and use that junk to test some flags/print some debug output. I thought my patch was helping in that matter by at least not using/printing that junk. > To fix the security concerns you expressed, you could have equally > removed the DRM_DEBUG_KMS(). Agreed, though we'd still be using some garbage values in some conditional expressions and potentially write them back to the hardware. But yeah I'm no expert so up to you really, I just thought your patch was quite big and still maybe not complete since it does check every *read() return values - we might as well take my approach as a first baby step and you can then go ahead and properly fix the callers to check for the return value? Not saying this is critical material anyway, just that the code looked wrong so I tried a minimal fix so it could be easily backported. Quentin ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] Suspend/resume problems on Broadwell
Hi, I'm having a few problems with i915 on my Broadwell Thinkpad (T450s, i7-5600U), apparently suspend/resume related. During every suspend/resume cycle, I see this in my kernel log after wakeup: Freezing user space processes ... (elapsed 0.001 seconds) done. Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done. PM: Entering mem sleep Suspending console(s) (use no_console_suspend to debug) sd 0:0:0:0: [sda] Synchronizing SCSI cache sd 0:0:0:0: [sda] Stopping disk e1000e: EEE TX LPI TIMER: 0011 [drm:stop_ring] *ERROR* render ring : timed out trying to stop ring I also get a lot of these at random times, and during glxgears once for every frame presented. I'm assuming it's for every GL frame, but I've only confirmed that for glxgears: [drm:hsw_unclaimed_reg_detect.isra.11 [i915]] *ERROR* Unclaimed register detected. Please use the i915.mmio_debug=1 to debug this problem. With mmio_debug, I get these: WARNING: CPU: 0 PID: 360 at drivers/gpu/drm/i915/intel_uncore.c:726 hsw_unclaimed_reg_debug+0x7d/0xa0() Unclaimed register detected before writing to register 0x44404 CPU: 0 PID: 360 Comm: Xorg Tainted: GW 3.19.0 #1 Hardware name: LENOVO 20BWS03F00/20BWS03F00, BIOS JBET39WW (1.04 ) 12/09/2014 70c52c75 88032d8a3b18 819f0e8b 0007 88032d8a3b70 88032d8a3b58 810c7205 0246 88032cd0 00044404 00044404 Call Trace: [] dump_stack+0x4c/0x6e [] warn_slowpath_common+0x85/0xc0 [] warn_slowpath_fmt+0x55/0x70 [] hsw_unclaimed_reg_debug+0x7d/0xa0 [] gen8_write32+0x58/0x1a0 [] gen8_enable_vblank+0x6b/0xa0 [] drm_vblank_enable+0x8d/0x100 [] drm_vblank_get+0xab/0xe0 [] drm_wait_vblank+0x92/0x620 [] ? i915_gem_retire_requests_ring+0x3c/0x180 [] drm_ioctl+0x1df/0x680 [] ? __hrtimer_start_range_ns+0x2fc/0x410 [] do_vfs_ioctl+0x2f8/0x500 [] ? __fget+0x72/0xb0 [] SyS_ioctl+0x81/0xa0 [] system_call_fastpath+0x12/0x17 About every one in three suspend/resume cycles, X graphics are almost completely broken after resume. Window decorations are still drawn (mostly, anyway), but window contents are mostly absent. What survived the cycle is killed off entirely by redraw events. Restarting everything X doesn't work, virtual terminals work fine. Also, it seems that running or having run a GL application has some impact on this. With an instance of glxgears running during suspend/resume, this doesn't seem to happen. Moreover, running a GL app seems to fix the problem. Is this known already, or can I somehow help to fix this? Greetings, Phoebe ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Check DVO reads for errors
On Thu, Feb 26, 2015 at 05:10:17PM +, Chris Wilson wrote:
> Not all of the DVO functions were checking the return value from their
> i2c routines when reading registers. This could lead to us feeding
> garbage values back into the hardware, possible causing further
> failures. In some cases the uninitialised stack values were being
> written into the kernel log.
>
> Quentin Casasnovas suggested the simple solution of just initialising
> the output parameter to zero in all cases, but we may as well spend the
> extra few moments to fix it correctly.
I'm not sure your patch would be -stable material mainly because of the
diffstat. Given the security implications, I would still rather have my
patch merged first so it can easily be back-ported to -stable and distro
kernels easily, and then have your patch on top when it gets properly
reviewed. Especially since your patch looks like it's doing other
not strictly related stuffs like these:
> --- a/drivers/gpu/drm/i915/dvo_ivch.c
> +++ b/drivers/gpu/drm/i915/dvo_ivch.c
> @@ -151,8 +151,6 @@
> struct ivch_priv {
> bool quiet;
>-
>- uint16_t width, height;
> };
>
>
> @@ -263,9 +261,6 @@ static bool ivch_init(struct intel_dvo_device *dvo,
> goto out;
> }
>
> - ivch_read(dvo, VR20, &priv->width);
> - ivch_read(dvo, VR21, &priv->height);
> -
> return true;
So again, I think my fix as a start would be preferable since it's quite
small and easily reviewable.
Quentin
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Check for driver readyness before handling an underrun interrupt
On Fri, Feb 27, 2015 at 10:20:05AM +0200, Jani Nikula wrote: > On Fri, 27 Feb 2015, Jani Nikula wrote: > > On Thu, 26 Feb 2015, Chris Wilson wrote: > >> When we takeover from the BIOS and install our interrupt handler, the > >> BIOS may have left us a few surprises in the form of spontaneous > >> interrupts. (This is especially likely on hardware like 965gm where > >> display fifo underruns are continuous and the GMCH cannot filter that > >> interrupt souce.) As we enable our IRQ early so that we can use it > >> during hardware probing, our interrupt handler must be prepared to > >> handle a few sources prior to being fully configured. As such, we need > >> to add a simple is-ready check prior to dereferencing our KMS state for > >> reporting underruns. > >> > >> Reported-by: Rob Clark > >> Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1193972 > > > > "You are not authorized to access bug #1193972. To see this bug, you > > must first log in to an account with the appropriate permissions." > > > > Meh. > > Pushed to drm-intel-fixes, thanks for the patch and review. If someone > both cares and has access to the bugzilla, please update it. Jani, I goofed... > >>/* GMCH can't disable fifo underruns, filter them. */ > >>if (HAS_GMCH_DISPLAY(dev_priv->dev) && > >> - !__cpu_fifo_underrun_reporting_enabled(dev_priv, pipe)) > >> + !to_intel_crtc(crtc)->cpu_fifo_underrun_disabled) Should be without the '!': if (HAS_GMCH_DISPLAY(dev_priv->dev) && to_intel_crtc(crtc)->cpu_fifo_underrun_disabled) -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 6/8] drm/i915/skl: Updated watermark programming
On 02/26/2015 04:45 PM, Damien Lespiau wrote:
On Wed, Feb 25, 2015 at 04:47:22PM +, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Recent BSpect updates have changed the watermark calculation to avoid
display flickering in some cases.
Signed-off-by: Tvrtko Ursulin
---
There are really several changes in this patch, it would have been
easier for the review to split them (and that's usually how we are
supposed to split patches).
From my point of view - this patch changes the computation from what it
was documented two weeks ago, to what was documented one week ago. I
don't see that it would be natural to be so inventive to start splitting
that.
- Convert the inner computations to number of blocks
- W/A to increase the nb of blocks for level 1-7 by 1
- Move max block test to >= instead of >
Anyway, which the couple of comments below addressd (of which only the
'>=' is a real problem), this is:
Reviewed-by: Damien Lespiau
Will fix up the details and tag it then, thanks!
drivers/gpu/drm/i915/intel_pm.c | 52 +
1 file changed, 32 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index f7c9938..626c3c2 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -2595,7 +2595,7 @@ static uint32_t skl_wm_method1(uint32_t pixel_rate,
uint8_t bytes_per_pixel,
if (latency == 0)
return UINT_MAX;
- wm_intermediate_val = latency * pixel_rate * bytes_per_pixel;
+ wm_intermediate_val = latency * pixel_rate * bytes_per_pixel / 512;
ret = DIV_ROUND_UP(wm_intermediate_val, 1000);
return ret;
@@ -2605,15 +2605,18 @@ static uint32_t skl_wm_method2(uint32_t pixel_rate,
uint32_t pipe_htotal,
uint32_t horiz_pixels, uint8_t bytes_per_pixel,
uint32_t latency)
{
- uint32_t ret, plane_bytes_per_line, wm_intermediate_val;
+ uint32_t ret;
+ uint32_t plane_bytes_per_line, plane_blocks_per_line;
+ uint32_t wm_intermediate_val;
if (latency == 0)
return UINT_MAX;
plane_bytes_per_line = horiz_pixels * bytes_per_pixel;
+ plane_blocks_per_line = DIV_ROUND_UP(plane_bytes_per_line, 512);
wm_intermediate_val = latency * pixel_rate;
ret = DIV_ROUND_UP(wm_intermediate_val, pipe_htotal * 1000) *
- plane_bytes_per_line;
+ plane_blocks_per_line;
return ret;
}
@@ -2693,39 +2696,47 @@ static void skl_compute_wm_pipe_parameters(struct
drm_crtc *crtc,
}
}
-static bool skl_compute_plane_wm(struct skl_pipe_wm_parameters *p,
+static bool skl_compute_plane_wm(const struct drm_i915_private *dev_priv,
+struct skl_pipe_wm_parameters *p,
struct intel_plane_wm_parameters *p_params,
uint16_t ddb_allocation,
-uint32_t mem_value,
+int level,
uint16_t *out_blocks, /* out */
uint8_t *out_lines /* out */)
{
- uint32_t method1, method2, plane_bytes_per_line, res_blocks, res_lines;
- uint32_t result_bytes;
+ uint32_t latency = dev_priv->wm.skl_latency[level];
+ uint32_t method1, method2;
+ uint32_t plane_bytes_per_line, plane_blocks_per_line;
+ uint32_t res_blocks, res_lines;
+ uint32_t result_blocks;
we now have res_blocks and result_blocks, a bit confusing. Maybe rename
result_blocks to selected_result (which happens to be in blocks)
Will change.
- if (mem_value == 0 || !p->active || !p_params->enabled)
+ if (latency == 0 || !p->active || !p_params->enabled)
return false;
method1 = skl_wm_method1(p->pixel_rate,
p_params->bytes_per_pixel,
-mem_value);
+latency);
method2 = skl_wm_method2(p->pixel_rate,
p->pipe_htotal,
p_params->horiz_pixels,
p_params->bytes_per_pixel,
-mem_value);
+latency);
plane_bytes_per_line = p_params->horiz_pixels *
p_params->bytes_per_pixel;
+ plane_blocks_per_line = DIV_ROUND_UP(plane_bytes_per_line, 512);
/* For now xtile and linear */
- if (((ddb_allocation * 512) / plane_bytes_per_line) >= 1)
- result_bytes = min(method1, method2);
+ if ((ddb_allocation / plane_blocks_per_line) >= 1)
+ result_blocks = min(method1, method2);
else
- result_bytes = method1;
+ result_blocks = method1;
+
+ res_b
Re: [Intel-gfx] [PATCH 7/8] drm/i915/skl: Update watermarks for Y tiling
On 02/26/2015 04:59 PM, Damien Lespiau wrote:
On Wed, Feb 25, 2015 at 04:47:23PM +, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Display watermarks need different programming for different tiling
modes.
Set the relevant flag so this happens during the plane commit and
add relevant data into a structure made available to the watermark
computation code.
v2: Pass in tiling info to sprite plane updates as well.
v3: Rebased for plane handling changes.
v4: Handle fb == NULL when plane is disabled.
v5: Refactored for addfb2 interface.
v6: Refactored for fb modifier changes.
v7: Updated for atomic commit by only updating watermarks when tiling changes.
v8: BSpec watermark calculation updates.
Signed-off-by: Tvrtko Ursulin
Acked-by: Ander Conselvan de Oliveira
Acked-by: Matt Roper
---
drivers/gpu/drm/i915/intel_display.c | 6
drivers/gpu/drm/i915/intel_drv.h | 1 +
drivers/gpu/drm/i915/intel_pm.c | 56 ++--
drivers/gpu/drm/i915/intel_sprite.c | 6
4 files changed, 60 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 626e6538..1d50934 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -11994,6 +11994,12 @@ intel_check_primary_plane(struct drm_plane *plane,
INTEL_FRONTBUFFER_PRIMARY(intel_crtc->pipe);
intel_crtc->atomic.update_fbc = true;
+
+ /* Update watermarks on tiling changes. */
+ if (!plane->state->fb || !state->base.fb ||
+ plane->state->fb->modifier[0] !=
+ state->base.fb->modifier[0])
+ intel_crtc->atomic.update_wm = true;
}
return 0;
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 399d2b2..b124548 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -501,6 +501,7 @@ struct intel_plane_wm_parameters {
uint8_t bytes_per_pixel;
bool enabled;
bool scaled;
+ u64 tiling;
};
struct intel_plane {
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 626c3c2..e0d6ebc 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -2603,7 +2603,7 @@ static uint32_t skl_wm_method1(uint32_t pixel_rate,
uint8_t bytes_per_pixel,
static uint32_t skl_wm_method2(uint32_t pixel_rate, uint32_t pipe_htotal,
uint32_t horiz_pixels, uint8_t bytes_per_pixel,
- uint32_t latency)
+ uint64_t tiling, uint32_t latency)
{
Hum, does this compile? I'm seeing an extra argument to skl_wm_method2()
but no update at the calling site?
Not only that, but it even works! :) (Extra argument is there, you must
have missed it!)
uint32_t ret;
uint32_t plane_bytes_per_line, plane_blocks_per_line;
@@ -2613,7 +2613,16 @@ static uint32_t skl_wm_method2(uint32_t pixel_rate,
uint32_t pipe_htotal,
return UINT_MAX;
plane_bytes_per_line = horiz_pixels * bytes_per_pixel;
- plane_blocks_per_line = DIV_ROUND_UP(plane_bytes_per_line, 512);
+
+ if (tiling == I915_FORMAT_MOD_Y_TILED ||
+ tiling == I915_FORMAT_MOD_Yf_TILED) {
+ plane_bytes_per_line *= 4;
+ plane_blocks_per_line = DIV_ROUND_UP(plane_bytes_per_line, 512);
+ plane_blocks_per_line /= 4;
+ } else {
+ plane_blocks_per_line = DIV_ROUND_UP(plane_bytes_per_line, 512);
+ }
+
wm_intermediate_val = latency * pixel_rate;
ret = DIV_ROUND_UP(wm_intermediate_val, pipe_htotal * 1000) *
plane_blocks_per_line;
@@ -2665,6 +2674,7 @@ static void skl_compute_wm_pipe_parameters(struct
drm_crtc *crtc,
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
enum pipe pipe = intel_crtc->pipe;
struct drm_plane *plane;
+ struct drm_framebuffer *fb;
int i = 1; /* Index for sprite planes start */
p->active = intel_crtc_active(crtc);
@@ -2680,6 +2690,14 @@ static void skl_compute_wm_pipe_parameters(struct
drm_crtc *crtc,
crtc->primary->fb->bits_per_pixel / 8;
p->plane[0].horiz_pixels = intel_crtc->config->pipe_src_w;
p->plane[0].vert_pixels = intel_crtc->config->pipe_src_h;
+ p->plane[0].tiling = DRM_FORMAT_MOD_NONE;
+ fb = crtc->primary->fb;
+ /*
+* Framebuffer can be NULL on plane disable, but it does not
+* matter for watermarks if we assume no tiling in that case.
+*/
+ if (fb)
+ p->plane[0].tiling = fb->modifier[0];
p->cursor.enabled = true;
p->cursor.bytes_per_pixel = 4;
@@ -2709,6 +2727,7 @@
Re: [Intel-gfx] [PATCH 8/8] drm/i915/skl: Allow Y (and Yf) frame buffer creation
On 02/26/2015 04:44 PM, Daniel Vetter wrote:
On Wed, Feb 25, 2015 at 04:47:24PM +, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
By this patch all underlying bits have been implemented and this
patch actually enables the feature.
v2: Validate passed in fb modifiers to reject garbage. (Daniel Vetter)
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Damien Lespiau (v1)
---
drivers/gpu/drm/i915/intel_display.c | 26 +-
1 file changed, 21 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 1d50934..3232ddd 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -12783,6 +12783,19 @@ static int intel_framebuffer_init(struct drm_device
*dev,
WARN_ON(!mutex_is_locked(&dev->struct_mutex));
if (mode_cmd->flags & DRM_MODE_FB_MODIFIERS) {
+ /* Passed in modifier sanity checking. */
+ switch (mode_cmd->modifier[0]) {
+ case DRM_FORMAT_MOD_NONE:
+ case I915_FORMAT_MOD_X_TILED:
+ case I915_FORMAT_MOD_Y_TILED:
+ case I915_FORMAT_MOD_Yf_TILED:
+ break;
+ default:
+ DRM_ERROR("Unsupported fb modifier 0x%llx!\n",
+ mode_cmd->modifier[0]);
+ return -EINVAL;
+ }
+
/* Enforce that fb modifier and tiling mode match, but only for
* X-tiled. This is needed for FBC. */
if (!!(obj->tiling_mode == I915_TILING_X) !=
@@ -12790,6 +12803,14 @@ static int intel_framebuffer_init(struct drm_device
*dev,
DRM_DEBUG("tiling_mode doesn't match fb modifier\n");
return -EINVAL;
}
+
+ if (INTEL_INFO(dev)->gen < 9 &&
+ (mode_cmd->modifier[0] == I915_FORMAT_MOD_Y_TILED ||
+mode_cmd->modifier[0] == I915_FORMAT_MOD_Yf_TILED)) {
+ DRM_DEBUG("Unsupported tiling 0x%llx!\n",
+ mode_cmd->modifier[0]);
+ return -EINVAL;
+ }
} else {
if (obj->tiling_mode == I915_TILING_X)
mode_cmd->modifier[0] = I915_FORMAT_MOD_X_TILED;
@@ -12799,11 +12820,6 @@ static int intel_framebuffer_init(struct drm_device
*dev,
}
}
- if (mode_cmd->modifier[0] == I915_FORMAT_MOD_Y_TILED) {
- DRM_DEBUG("hardware does not support tiling Y\n");
- return -EINVAL;
- }
My idea was actually to put the switch here (reduces one indent level) and
put the per-gen stuff into the switch statement too. I.e.
/* Passed in modifier sanity checking. */
switch (mode_cmd->modifier[0]) {
case I915_FORMAT_MOD_Y_TILED:
case I915_FORMAT_MOD_Yf_TILED:
if (INTEL_INFO(dev)->gen < 9) {
DRM_DEBUG("Unsupported tiling 0x%llx!\n",
mode_cmd->modifier[0]);
return -EINVAL;
}
case DRM_FORMAT_MOD_NONE:
case I915_FORMAT_MOD_X_TILED:
break;
default:
DRM_ERROR("Unsupported fb modifier 0x%llx!\n",
mode_cmd->modifier[0]);
return -EINVAL;
}
That gives us a natural place for extensions later on if we need to add
more special cases.
Yes I agree this patch being only on v2 was way disproportionate
compared to some others from this series. ;)
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t] kms_universal_plane: Check for cursor fb leaks
On Thu, Feb 26, 2015 at 07:00:19PM -0800, Matt Roper wrote:
> We've been leaking the framebuffers that get created inside the
> legacy -> universal cursor compatibility layer and nobody noticed. Add
> an i-g-t test to check debugfs and ensure we end up the same number of
> framebuffers we started with after performing cursor operations.
>
> + /*
> + * Exercise both legacy and universal code paths. Note that legacy
> + * handling in the kernel redirects through universal codepaths
> + * internally, so that redirection is where we're most worried about
> + * leaking.
> + */
> + for (i = 0; i < 10; i++) {
> + igt_plane_set_fb(cursor, &cursor_fb[i]);
> + igt_display_commit2(display, COMMIT_UNIVERSAL);
> + }
> + for (i = 0; i < 10; i++) {
> + igt_plane_set_fb(cursor, &cursor_fb[i]);
> + igt_display_commit2(display, COMMIT_LEGACY);
> + }
Oh, magic igt. The comment had me searching for how COMMIT_UNIVERSAL
triggered DRM_MODE_CURSOR_BO - it took me a while to spot you had two
loops! I think it would be better to split these tests up (or at
least mix the combinations of universal | legacy) to have finer grained
tests in case something does go wrong again in the future.
Another useful test (that maybe xfail for a while) is to check that the
active cursor (and other planes) are cleared after close(fd).
-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: Check for driver readyness before handling an underrun interrupt
On Fri, 27 Feb 2015, Chris Wilson wrote: > On Fri, Feb 27, 2015 at 10:20:05AM +0200, Jani Nikula wrote: >> On Fri, 27 Feb 2015, Jani Nikula wrote: >> > On Thu, 26 Feb 2015, Chris Wilson wrote: >> >> When we takeover from the BIOS and install our interrupt handler, the >> >> BIOS may have left us a few surprises in the form of spontaneous >> >> interrupts. (This is especially likely on hardware like 965gm where >> >> display fifo underruns are continuous and the GMCH cannot filter that >> >> interrupt souce.) As we enable our IRQ early so that we can use it >> >> during hardware probing, our interrupt handler must be prepared to >> >> handle a few sources prior to being fully configured. As such, we need >> >> to add a simple is-ready check prior to dereferencing our KMS state for >> >> reporting underruns. >> >> >> >> Reported-by: Rob Clark >> >> Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1193972 >> > >> > "You are not authorized to access bug #1193972. To see this bug, you >> > must first log in to an account with the appropriate permissions." >> > >> > Meh. >> >> Pushed to drm-intel-fixes, thanks for the patch and review. If someone >> both cares and has access to the bugzilla, please update it. > > Jani, I goofed... > >> >> /* GMCH can't disable fifo underruns, filter them. */ >> >> if (HAS_GMCH_DISPLAY(dev_priv->dev) && >> >> - !__cpu_fifo_underrun_reporting_enabled(dev_priv, pipe)) >> >> + !to_intel_crtc(crtc)->cpu_fifo_underrun_disabled) > > Should be without the '!': > if (HAS_GMCH_DISPLAY(dev_priv->dev) && > to_intel_crtc(crtc)->cpu_fifo_underrun_disabled) It never happened. BR, Jani. > -Chris > > -- > Chris Wilson, Intel Open Source Technology Centre -- Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: DP link training optimization
On 2/27/2015 1:14 PM, Jani Nikula wrote:
On Fri, 27 Feb 2015, Todd Previte wrote:
Hi Mika,
On 2/26/2015 2:26 AM, Mika Kahola wrote:
In a case when DP link has been once trained we can reuse
the existing link training parameters i.e. voltage swing
and pre-emphasis levels from cache when there is a need to
restart link training. In a case of eDP we initially try
to train the link by using the parameter set that we can find
from VBT. The fallback on both cases is to reset the link
training parameters and restart.
I think you have a good idea here for the eDP case. But the way it's
coded, there appear to be cases where the code will try to reuse the
same training settings for regular DP as well. That will likely have
some unfortunate results, as there's no guarantee for a normal external
Displayport connection that training settings which worked once will
work the next time. This would be of particular concern when
disconnecting and reconnecting Displayport sink devices, as it appears
as though it would try to retrain the newly connected device using the
previously valid settings for the old device.
Hmm, I thought it would be all right on external DP also if we ensure we
reset the train set when the sink may have changed, i.e. at suspend and
hotplug.
BR,
Jani.
Though VBT fields for Fast Link Training has been available for a long
time it was not always filled and there was no way to know if the values
in VBT are valid or not. Hence it is more than likely to be entering the
failing condition. There was a field added in BDW timeline to say if the
VBT fields for FLT values is valid or not, so please use them only after
such a check.
regards,
Sivakumar
IMHO, this really needs to be written as eDP only and such that it can
never occur on an external Displayport device. Otherwise, it seems like
there's a good chance of ending up with a black screen when you plug in
a Displayport monitor.
Signed-off-by: Mika Kahola
---
drivers/gpu/drm/i915/intel_dp.c | 93
+++-
drivers/gpu/drm/i915/intel_drv.h | 1 +
2 files changed, 84 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index d1141d3..8482f58 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -3288,8 +3288,39 @@ static bool
intel_dp_reset_link_train(struct intel_dp *intel_dp, uint32_t *DP,
uint8_t dp_train_pat)
{
- memset(intel_dp->train_set, 0, sizeof(intel_dp->train_set));
+ struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
+ struct drm_device *dev = intel_dig_port->base.base.dev;
+ struct drm_i915_private *dev_priv = dev->dev_private;
+ int i;
+
+ /* in case of eDP, get link training parameters from VBT */
+ if (is_edp(intel_dp)) {
+ for (i=0; ilane_count; i++)
+ intel_dp->train_set[i] = dev_priv->vbt.edp_vswing |
dev_priv->vbt.edp_preemphasis;
+ }
+ else
+ memset(intel_dp->train_set, 0, sizeof(intel_dp->train_set));
+
+ intel_dp_set_signal_levels(intel_dp, DP);
+ return intel_dp_set_link_train(intel_dp, DP, dp_train_pat);
+}
+
+static bool
+intel_dp_reuse_link_train(struct intel_dp *intel_dp, uint32_t *DP,
+ uint8_t dp_train_pat)
+{
+ struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
+ struct drm_device *dev = intel_dig_port->base.base.dev;
+ struct drm_i915_private *dev_priv = dev->dev_private;
+
intel_dp_set_signal_levels(intel_dp, DP);
+
+ I915_WRITE(intel_dp->output_reg, *DP);
+ POSTING_READ(intel_dp->output_reg);
+
+ drm_dp_dpcd_write(&intel_dp->aux, DP_TRAINING_LANE0_SET,
+ intel_dp->train_set, intel_dp->lane_count);
+
return intel_dp_set_link_train(intel_dp, DP, dp_train_pat);
}
I'm not sure you want to be updating the sink device at this point. This
should be checked against the spec to be sure it's not out of sequence.
@@ -3356,6 +3387,8 @@ intel_dp_start_link_train(struct intel_dp *intel_dp)
int voltage_tries, loop_tries;
uint32_t DP = intel_dp->DP;
uint8_t link_config[2];
+ uint8_t link_status[DP_LINK_STATUS_SIZE];
+ bool reuse_train_set = false;
if (HAS_DDI(dev))
intel_ddi_prepare_link_retrain(encoder);
@@ -3373,20 +3406,44 @@ intel_dp_start_link_train(struct intel_dp *intel_dp)
DP |= DP_PORT_EN;
- /* clock recovery */
- if (!intel_dp_reset_link_train(intel_dp, &DP,
- DP_TRAINING_PATTERN_1 |
- DP_LINK_SCRAMBLING_DISABLE)) {
- DRM_ERROR("failed to enable link training\n");
- return;
+ /*
+* check if DP has already trained. Reset voltage swing and
+* pre-emphasis levels if that's not the case.
+
[Intel-gfx] [PATCH v2] drm/dp: add DPCD definitions from DP 1.1 and 1.2a
Add a number of DPCD definitions from DP 1.1 and 1.2a. v2: drop wrong DP version reference, rename DP training set macros (Sonika). Reviewed-by: Sonika Jindal Signed-off-by: Jani Nikula --- include/drm/drm_dp_helper.h | 93 ++--- 1 file changed, 88 insertions(+), 5 deletions(-) diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h index a3ecaa06c9db..319d5edfb3b5 100644 --- a/include/drm/drm_dp_helper.h +++ b/include/drm/drm_dp_helper.h @@ -92,6 +92,15 @@ # define DP_MSA_TIMING_PAR_IGNORED (1 << 6) /* eDP */ # define DP_OUI_SUPPORT(1 << 7) +#define DP_RECEIVE_PORT_0_CAP_00x008 +# define DP_LOCAL_EDID_PRESENT (1 << 1) +# define DP_ASSOCIATED_TO_PRECEDING_PORT(1 << 2) + +#define DP_RECEIVE_PORT_0_BUFFER_SIZE 0x009 + +#define DP_RECEIVE_PORT_1_CAP_00x00a +#define DP_RECEIVE_PORT_1_BUFFER_SIZE 0x00b + #define DP_I2C_SPEED_CAP 0x00c/* DPI */ # define DP_I2C_SPEED_1K 0x01 # define DP_I2C_SPEED_5K 0x02 @@ -101,10 +110,16 @@ # define DP_I2C_SPEED_1M 0x20 #define DP_EDP_CONFIGURATION_CAP0x00d /* XXX 1.2? */ +# define DP_ALTERNATE_SCRAMBLER_RESET_CAP (1 << 0) +# define DP_FRAMING_CHANGE_CAP (1 << 1) # define DP_DPCD_DISPLAY_CONTROL_CAPABLE (1 << 3) /* edp v1.2 or higher */ #define DP_TRAINING_AUX_RD_INTERVAL 0x00e /* XXX 1.2? */ +#define DP_ADAPTER_CAP 0x00f /* 1.2 */ +# define DP_FORCE_LOAD_SENSE_CAP (1 << 0) +# define DP_ALTERNATE_I2C_PATTERN_CAP (1 << 1) + #define DP_SUPPORTED_LINK_RATES0x010 /* eDP 1.4 */ # define DP_MAX_SUPPORTED_RATES 8 /* 16-bit little-endian */ @@ -115,6 +130,44 @@ #define DP_MSTM_CAP0x021 /* 1.2 */ # define DP_MST_CAP(1 << 0) +#define DP_NUMBER_OF_AUDIO_ENDPOINTS 0x022 /* 1.2 */ + +/* AV_SYNC_DATA_BLOCK 1.2 */ +#define DP_AV_GRANULARITY 0x023 +# define DP_AG_FACTOR_MASK (0xf << 0) +# define DP_AG_FACTOR_3MS (0 << 0) +# define DP_AG_FACTOR_2MS (1 << 0) +# define DP_AG_FACTOR_1MS (2 << 0) +# define DP_AG_FACTOR_500US(3 << 0) +# define DP_AG_FACTOR_200US(4 << 0) +# define DP_AG_FACTOR_100US(5 << 0) +# define DP_AG_FACTOR_10US (6 << 0) +# define DP_AG_FACTOR_1US (7 << 0) +# define DP_VG_FACTOR_MASK (0xf << 4) +# define DP_VG_FACTOR_3MS (0 << 4) +# define DP_VG_FACTOR_2MS (1 << 4) +# define DP_VG_FACTOR_1MS (2 << 4) +# define DP_VG_FACTOR_500US(3 << 4) +# define DP_VG_FACTOR_200US(4 << 4) +# define DP_VG_FACTOR_100US(5 << 4) + +#define DP_AUD_DEC_LAT00x024 +#define DP_AUD_DEC_LAT10x025 + +#define DP_AUD_PP_LAT0 0x026 +#define DP_AUD_PP_LAT1 0x027 + +#define DP_VID_INTER_LAT 0x028 + +#define DP_VID_PROG_LAT0x029 + +#define DP_REP_LAT 0x02a + +#define DP_AUD_DEL_INS00x02b +#define DP_AUD_DEL_INS10x02c +#define DP_AUD_DEL_INS20x02d +/* End of AV_SYNC_DATA_BLOCK */ + #define DP_GUID0x030 /* 1.2 */ #define DP_PSR_SUPPORT 0x070 /* XXX 1.2? */ @@ -173,11 +226,12 @@ # define DP_TRAINING_PATTERN_3 3 /* 1.2 */ # define DP_TRAINING_PATTERN_MASK 0x3 -# define DP_LINK_QUAL_PATTERN_DISABLE (0 << 2) -# define DP_LINK_QUAL_PATTERN_D10_2(1 << 2) -# define DP_LINK_QUAL_PATTERN_ERROR_RATE(2 << 2) -# define DP_LINK_QUAL_PATTERN_PRBS7(3 << 2) -# define DP_LINK_QUAL_PATTERN_MASK (3 << 2) +/* DPCD 1.1 only. For DPCD >= 1.2 see per-lane DP_LINK_QUAL_LANEn_SET */ +# define DP_LINK_QUAL_PATTERN_11_DISABLE(0 << 2) +# define DP_LINK_QUAL_PATTERN_11_D10_2 (1 << 2) +# define DP_LINK_QUAL_PATTERN_11_ERROR_RATE (2 << 2) +# define DP_LINK_QUAL_PATTERN_11_PRBS7 (3 << 2) +# define DP_LINK_QUAL_PATTERN_11_MASK (3 << 2) # define DP_RECOVERED_CLOCK_OUT_EN (1 << 4) # define DP_LINK_SCRAMBLING_DISABLE(1 << 5) @@ -220,14 +274,43 @@ /* bitmask as for DP_I2C_SPEED_CAP */ #define DP_EDP_CONFIGURATION_SET0x10a /* XXX 1.2? */ +# define DP_ALTERNATE_SCRAMBLER_RESET_ENABLE (1 << 0) +# define DP_FRAMING_CHANGE_ENABLE (1 << 1) +# define DP_PANEL_SELF_TEST_ENABLE (1 << 7) + +#define DP_LINK_QUAL_LANE0_SET 0x10b /* DPCD >= 1.2 */ +#define DP_
[Intel-gfx] [PATCH v2] drm/dp: add DPCD definitions from eDP 1.4
Add a number of DPCD definitions from eDP 1.4. v2: s/DP_ALPM_LOCK_TIMEOUT_ERROR_STATUS/DP_ALPM_LOCK_TIMEOUT_ERROR/ (Sonika) Signed-off-by: Jani Nikula --- include/drm/drm_dp_helper.h | 37 + 1 file changed, 37 insertions(+) diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h index 319d5edfb3b5..c5fdc2d3ca97 100644 --- a/include/drm/drm_dp_helper.h +++ b/include/drm/drm_dp_helper.h @@ -168,10 +168,18 @@ #define DP_AUD_DEL_INS20x02d /* End of AV_SYNC_DATA_BLOCK */ +#define DP_RECEIVER_ALPM_CAP 0x02e /* eDP 1.4 */ +# define DP_ALPM_CAP (1 << 0) + +#define DP_SINK_DEVICE_AUX_FRAME_SYNC_CAP 0x02f /* eDP 1.4 */ +# define DP_AUX_FRAME_SYNC_CAP (1 << 0) + #define DP_GUID0x030 /* 1.2 */ #define DP_PSR_SUPPORT 0x070 /* XXX 1.2? */ # define DP_PSR_IS_SUPPORTED1 +# define DP_PSR2_IS_SUPPORTED 2 /* eDP 1.4 */ + #define DP_PSR_CAPS 0x071 /* XXX 1.2? */ # define DP_PSR_NO_TRAIN_ON_EXIT1 # define DP_PSR_SETUP_TIME_330 (0 << 1) @@ -211,6 +219,7 @@ /* link configuration */ #defineDP_LINK_BW_SET 0x100 +# define DP_LINK_RATE_TABLE0x00/* eDP 1.4 */ # define DP_LINK_BW_1_62 0x06 # define DP_LINK_BW_2_70x0a # define DP_LINK_BW_5_40x14/* 1.2 */ @@ -307,15 +316,30 @@ #define DP_AUDIO_DELAY20x114 #define DP_LINK_RATE_SET 0x115 /* eDP 1.4 */ +# define DP_LINK_RATE_SET_SHIFT0 +# define DP_LINK_RATE_SET_MASK (7 << 0) + +#define DP_RECEIVER_ALPM_CONFIG0x116 /* eDP 1.4 */ +# define DP_ALPM_ENABLE(1 << 0) +# define DP_ALPM_LOCK_ERROR_IRQ_HPD_ENABLE (1 << 1) + +#define DP_SINK_DEVICE_AUX_FRAME_SYNC_CONF 0x117 /* eDP 1.4 */ +# define DP_AUX_FRAME_SYNC_ENABLE (1 << 0) +# define DP_IRQ_HPD_ENABLE (1 << 1) #define DP_UPSTREAM_DEVICE_DP_PWR_NEED 0x118 /* 1.2 */ # define DP_PWR_NOT_NEEDED (1 << 0) +#define DP_AUX_FRAME_SYNC_VALUE0x15c /* eDP 1.4 */ +# define DP_AUX_FRAME_SYNC_VALID (1 << 0) + #define DP_PSR_EN_CFG 0x170 /* XXX 1.2? */ # define DP_PSR_ENABLE (1 << 0) # define DP_PSR_MAIN_LINK_ACTIVE (1 << 1) # define DP_PSR_CRC_VERIFICATION (1 << 2) # define DP_PSR_FRAME_CAPTURE (1 << 3) +# define DP_PSR_SELECTIVE_UPDATE (1 << 4) +# define DP_PSR_IRQ_HPD_WITH_CRC_ERRORS (1 << 5) #define DP_ADAPTER_CTRL0x1a0 # define DP_ADAPTER_CTRL_FORCE_LOAD_SENSE (1 << 0) @@ -423,6 +447,10 @@ # define DP_SET_POWER_MASK 0x3 #define DP_EDP_DPCD_REV0x700/* eDP 1.2 */ +# define DP_EDP_11 0x00 +# define DP_EDP_12 0x01 +# define DP_EDP_13 0x02 +# define DP_EDP_14 0x03 #define DP_EDP_GENERAL_CAP_1 0x701 @@ -430,6 +458,8 @@ #define DP_EDP_GENERAL_CAP_2 0x703 +#define DP_EDP_GENERAL_CAP_3 0x704/* eDP 1.4 */ + #define DP_EDP_DISPLAY_CONTROL_REGISTER 0x720 #define DP_EDP_BACKLIGHT_MODE_SET_REGISTER 0x721 @@ -456,6 +486,9 @@ #define DP_EDP_DBC_MINIMUM_BRIGHTNESS_SET 0x732 #define DP_EDP_DBC_MAXIMUM_BRIGHTNESS_SET 0x733 +#define DP_EDP_REGIONAL_BACKLIGHT_BASE 0x740/* eDP 1.4 */ +#define DP_EDP_REGIONAL_BACKLIGHT_00x741/* eDP 1.4 */ + #define DP_SIDEBAND_MSG_DOWN_REQ_BASE 0x1000 /* 1.2 MST */ #define DP_SIDEBAND_MSG_UP_REP_BASE0x1200 /* 1.2 MST */ #define DP_SIDEBAND_MSG_DOWN_REP_BASE 0x1400 /* 1.2 MST */ @@ -474,6 +507,7 @@ #define DP_PSR_ERROR_STATUS 0x2006 /* XXX 1.2? */ # define DP_PSR_LINK_CRC_ERROR (1 << 0) # define DP_PSR_RFB_STORAGE_ERROR (1 << 1) +# define DP_PSR_VSC_SDP_UNCORRECTABLE_ERROR (1 << 2) /* eDP 1.4 */ #define DP_PSR_ESI 0x2007 /* XXX 1.2? */ # define DP_PSR_CAPS_CHANGE (1 << 0) @@ -487,6 +521,9 @@ # define DP_PSR_SINK_INTERNAL_ERROR 7 # define DP_PSR_SINK_STATE_MASK 0x07 +#define DP_RECEIVER_ALPM_STATUS0x200b /* eDP 1.4 */ +# define DP_ALPM_LOCK_TIMEOUT_ERROR(1 << 0) + /* DP 1.2 Sideband message defines */ /* peer device type - DP 1.2a Table 2-92 */ #define DP_PEER_DEVICE_NONE0x0 -- 2.1.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/dp: add DPCD definitions from DP 1.1 and 1.2a
Apologies, this was supposed to be in reply to http://mid.gmane.org/54eeecc9.4010...@intel.com On Fri, 27 Feb 2015, Jani Nikula wrote: > Add a number of DPCD definitions from DP 1.1 and 1.2a. > > v2: drop wrong DP version reference, rename DP training set macros > (Sonika). > > Reviewed-by: Sonika Jindal > Signed-off-by: Jani Nikula > --- > include/drm/drm_dp_helper.h | 93 > ++--- > 1 file changed, 88 insertions(+), 5 deletions(-) > > diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h > index a3ecaa06c9db..319d5edfb3b5 100644 > --- a/include/drm/drm_dp_helper.h > +++ b/include/drm/drm_dp_helper.h > @@ -92,6 +92,15 @@ > # define DP_MSA_TIMING_PAR_IGNORED (1 << 6) /* eDP */ > # define DP_OUI_SUPPORT (1 << 7) > > +#define DP_RECEIVE_PORT_0_CAP_0 0x008 > +# define DP_LOCAL_EDID_PRESENT (1 << 1) > +# define DP_ASSOCIATED_TO_PRECEDING_PORT(1 << 2) > + > +#define DP_RECEIVE_PORT_0_BUFFER_SIZE0x009 > + > +#define DP_RECEIVE_PORT_1_CAP_0 0x00a > +#define DP_RECEIVE_PORT_1_BUFFER_SIZE 0x00b > + > #define DP_I2C_SPEED_CAP 0x00c/* DPI */ > # define DP_I2C_SPEED_1K 0x01 > # define DP_I2C_SPEED_5K 0x02 > @@ -101,10 +110,16 @@ > # define DP_I2C_SPEED_1M 0x20 > > #define DP_EDP_CONFIGURATION_CAP0x00d /* XXX 1.2? */ > +# define DP_ALTERNATE_SCRAMBLER_RESET_CAP (1 << 0) > +# define DP_FRAMING_CHANGE_CAP (1 << 1) > # define DP_DPCD_DISPLAY_CONTROL_CAPABLE (1 << 3) /* edp v1.2 or higher > */ > > #define DP_TRAINING_AUX_RD_INTERVAL 0x00e /* XXX 1.2? */ > > +#define DP_ADAPTER_CAP 0x00f /* 1.2 */ > +# define DP_FORCE_LOAD_SENSE_CAP (1 << 0) > +# define DP_ALTERNATE_I2C_PATTERN_CAP(1 << 1) > + > #define DP_SUPPORTED_LINK_RATES 0x010 /* eDP 1.4 */ > # define DP_MAX_SUPPORTED_RATES 8 /* 16-bit > little-endian */ > > @@ -115,6 +130,44 @@ > #define DP_MSTM_CAP 0x021 /* 1.2 */ > # define DP_MST_CAP (1 << 0) > > +#define DP_NUMBER_OF_AUDIO_ENDPOINTS 0x022 /* 1.2 */ > + > +/* AV_SYNC_DATA_BLOCK 1.2 */ > +#define DP_AV_GRANULARITY0x023 > +# define DP_AG_FACTOR_MASK (0xf << 0) > +# define DP_AG_FACTOR_3MS(0 << 0) > +# define DP_AG_FACTOR_2MS(1 << 0) > +# define DP_AG_FACTOR_1MS(2 << 0) > +# define DP_AG_FACTOR_500US (3 << 0) > +# define DP_AG_FACTOR_200US (4 << 0) > +# define DP_AG_FACTOR_100US (5 << 0) > +# define DP_AG_FACTOR_10US (6 << 0) > +# define DP_AG_FACTOR_1US(7 << 0) > +# define DP_VG_FACTOR_MASK (0xf << 4) > +# define DP_VG_FACTOR_3MS(0 << 4) > +# define DP_VG_FACTOR_2MS(1 << 4) > +# define DP_VG_FACTOR_1MS(2 << 4) > +# define DP_VG_FACTOR_500US (3 << 4) > +# define DP_VG_FACTOR_200US (4 << 4) > +# define DP_VG_FACTOR_100US (5 << 4) > + > +#define DP_AUD_DEC_LAT0 0x024 > +#define DP_AUD_DEC_LAT1 0x025 > + > +#define DP_AUD_PP_LAT0 0x026 > +#define DP_AUD_PP_LAT1 0x027 > + > +#define DP_VID_INTER_LAT 0x028 > + > +#define DP_VID_PROG_LAT 0x029 > + > +#define DP_REP_LAT 0x02a > + > +#define DP_AUD_DEL_INS0 0x02b > +#define DP_AUD_DEL_INS1 0x02c > +#define DP_AUD_DEL_INS2 0x02d > +/* End of AV_SYNC_DATA_BLOCK */ > + > #define DP_GUID 0x030 /* 1.2 */ > > #define DP_PSR_SUPPORT 0x070 /* XXX 1.2? */ > @@ -173,11 +226,12 @@ > # define DP_TRAINING_PATTERN_3 3 /* 1.2 */ > # define DP_TRAINING_PATTERN_MASK0x3 > > -# define DP_LINK_QUAL_PATTERN_DISABLE(0 << 2) > -# define DP_LINK_QUAL_PATTERN_D10_2 (1 << 2) > -# define DP_LINK_QUAL_PATTERN_ERROR_RATE(2 << 2) > -# define DP_LINK_QUAL_PATTERN_PRBS7 (3 << 2) > -# define DP_LINK_QUAL_PATTERN_MASK (3 << 2) > +/* DPCD 1.1 only. For DPCD >= 1.2 see per-lane DP_LINK_QUAL_LANEn_SET */ > +# define DP_LINK_QUAL_PATTERN_11_DISABLE(0 << 2) > +# define DP_LINK_QUAL_PATTERN_11_D10_2 (1 << 2) > +# define DP_LINK_QUAL_PATTERN_11_ERROR_RATE (2 << 2) > +# define DP_LINK_QUAL_PATTERN_11_PRBS7 (3 << 2) > +# define DP_LINK_QUAL_PATTERN_11_MASK(3 << 2) > > # define DP_RECOVERED_CLOCK_OUT_EN (1 << 4) > # define DP_LINK_SCRAMBLING_DISABLE (1 << 5) > @@ -220,14 +274,43 @@ > /*
[Intel-gfx] [PATCH 3/8] drm/i915/skl: Adjust intel_fb_align_height() for Yb/Yf tiling
From: Damien Lespiau
We now need the bpp of the fb as Yf tiling has different tile widths
depending on it.
v2: Rebased for the new addfb2 interface. (Tvrtko Ursulin)
v3: Rebased for fb modifier changes. (Tvrtko Ursulin)
v4: Added missing case and 128-bit pixel warning. (Damien Lespiau)
Signed-off-by: Damien Lespiau
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Tvrtko Ursulin
Reviewed-by: Damien Lespiau (v3)
---
drivers/gpu/drm/i915/intel_display.c | 39 ++--
1 file changed, 37 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index cf0eadc..1db63c9 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2195,9 +2195,44 @@ intel_fb_align_height(struct drm_device *dev, int height,
uint64_t fb_format_modifier)
{
int tile_height;
+ uint32_t bits_per_pixel;
- tile_height = fb_format_modifier == I915_FORMAT_MOD_X_TILED ?
- (IS_GEN2(dev) ? 16 : 8) : 1;
+ switch (fb_format_modifier) {
+ case DRM_FORMAT_MOD_NONE:
+ tile_height = 1;
+ break;
+ case I915_FORMAT_MOD_X_TILED:
+ tile_height = IS_GEN2(dev) ? 16 : 8;
+ break;
+ case I915_FORMAT_MOD_Y_TILED:
+ tile_height = 32;
+ break;
+ case I915_FORMAT_MOD_Yf_TILED:
+ bits_per_pixel = drm_format_plane_cpp(pixel_format, 0) * 8;
+ switch (bits_per_pixel) {
+ default:
+ case 8:
+ tile_height = 64;
+ break;
+ case 16:
+ case 32:
+ tile_height = 32;
+ break;
+ case 64:
+ tile_height = 16;
+ break;
+ case 128:
+ WARN_ONCE(1,
+ "128-bit pixels are not supported for
display!");
+ tile_height = 16;
+ break;
+ }
+ break;
+ default:
+ MISSING_CASE(fb_format_modifier);
+ tile_height = 1;
+ break;
+ }
return ALIGN(height, tile_height);
}
--
2.3.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/8] drm/i915/skl: Add new displayable tiling formats
From: Tvrtko Ursulin Starting with SKL display engine can scan out Y, and newly introduced Yf tiling formats so add the latter to the frame buffer modifier space. v2: Definitions moved to drm_fourcc.h. v3: Try to document the format better. Signed-off-by: Tvrtko Ursulin Reviewed-by: Damien Lespiau --- include/uapi/drm/drm_fourcc.h | 15 +++ 1 file changed, 15 insertions(+) diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h index 1a5a357..e6efac2 100644 --- a/include/uapi/drm/drm_fourcc.h +++ b/include/uapi/drm/drm_fourcc.h @@ -192,4 +192,19 @@ */ #define I915_FORMAT_MOD_Y_TILEDfourcc_mod_code(INTEL, 2) +/* + * Intel Yf-tiling layout + * + * This is a tiled layout using 4Kb tiles in row-major layout. + * Within the tile pixels are laid out in 16 256 byte units / sub-tiles which + * are arranged in four groups (two wide, two high) with column-major layout. + * Each group therefore consits out of four 256 byte units, which are also laid + * out as 2x2 column-major. + * 256 byte units are made out of four 64 byte blocks of pixels, producing + * either a square block or a 2:1 unit. + * 64 byte blocks of pixels contain four pixel rows of 16 bytes, where the width + * in pixel depends on the pixel depth. + */ +#define I915_FORMAT_MOD_Yf_TILED fourcc_mod_code(INTEL, 3) + #endif /* DRM_FOURCC_H */ -- 2.3.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/8] drm/i915/skl: Allow scanning out Y and Yf fbs
From: Damien Lespiau
Skylake is able to scannout those tiling formats. We need to allow them
in the ADDFB ioctl and tell the harware about it.
v2: Rebased for addfb2 interface. (Tvrtko Ursulin)
v3: Rebased for fb modifier changes. (Tvrtko Ursulin)
v4: Don't allow Y tiled fbs just yet. (Tvrtko Ursulin)
v5: Check for stride alignment and max pitch. (Tvrtko Ursulin)
v6: Simplify maximum pitch check. (Ville Syrjälä)
v7: Drop the gen9 check since requirements are no different. (Ville Syrjälä)
v8: Gen2 has different X tiling stride. (Ville Syrjälä)
Signed-off-by: Damien Lespiau
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Damien Lespiau (v7)
Reviewed-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 121 +--
drivers/gpu/drm/i915/intel_drv.h | 2 +
drivers/gpu/drm/i915/intel_sprite.c | 18 --
3 files changed, 101 insertions(+), 40 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 94efacb..cf0eadc 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2734,6 +2734,40 @@ static void ironlake_update_primary_plane(struct
drm_crtc *crtc,
POSTING_READ(reg);
}
+u32 intel_fb_stride_alignment(struct drm_device *dev, uint64_t fb_modifier,
+ uint32_t pixel_format)
+{
+ u32 bits_per_pixel = drm_format_plane_cpp(pixel_format, 0) * 8;
+
+ /*
+* The stride is either expressed as a multiple of 64 bytes
+* chunks for linear buffers or in number of tiles for tiled
+* buffers.
+*/
+ switch (fb_modifier) {
+ case DRM_FORMAT_MOD_NONE:
+ return 64;
+ case I915_FORMAT_MOD_X_TILED:
+ if (INTEL_INFO(dev)->gen == 2)
+ return 128;
+ return 512;
+ case I915_FORMAT_MOD_Y_TILED:
+ /* No need to check for old gens and Y tiling since this is
+* about the display engine and those will be blocked before
+* we get here.
+*/
+ return 128;
+ case I915_FORMAT_MOD_Yf_TILED:
+ if (bits_per_pixel == 8)
+ return 64;
+ else
+ return 128;
+ default:
+ MISSING_CASE(fb_modifier);
+ return 64;
+ }
+}
+
static void skylake_update_primary_plane(struct drm_crtc *crtc,
struct drm_framebuffer *fb,
int x, int y)
@@ -2741,10 +2775,9 @@ static void skylake_update_primary_plane(struct drm_crtc
*crtc,
struct drm_device *dev = crtc->dev;
struct drm_i915_private *dev_priv = dev->dev_private;
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
- struct intel_framebuffer *intel_fb;
struct drm_i915_gem_object *obj;
int pipe = intel_crtc->pipe;
- u32 plane_ctl, stride;
+ u32 plane_ctl, stride_div;
if (!intel_crtc->primary_enabled) {
I915_WRITE(PLANE_CTL(pipe, 0), 0);
@@ -2788,29 +2821,30 @@ static void skylake_update_primary_plane(struct
drm_crtc *crtc,
BUG();
}
- intel_fb = to_intel_framebuffer(fb);
- obj = intel_fb->obj;
-
- /*
-* The stride is either expressed as a multiple of 64 bytes chunks for
-* linear buffers or in number of tiles for tiled buffers.
-*/
switch (fb->modifier[0]) {
case DRM_FORMAT_MOD_NONE:
- stride = fb->pitches[0] >> 6;
break;
case I915_FORMAT_MOD_X_TILED:
plane_ctl |= PLANE_CTL_TILED_X;
- stride = fb->pitches[0] >> 9;
+ break;
+ case I915_FORMAT_MOD_Y_TILED:
+ plane_ctl |= PLANE_CTL_TILED_Y;
+ break;
+ case I915_FORMAT_MOD_Yf_TILED:
+ plane_ctl |= PLANE_CTL_TILED_YF;
break;
default:
- BUG();
+ MISSING_CASE(fb->modifier[0]);
}
plane_ctl |= PLANE_CTL_PLANE_GAMMA_DISABLE;
if (crtc->primary->state->rotation == BIT(DRM_ROTATE_180))
plane_ctl |= PLANE_CTL_ROTATE_180;
+ obj = intel_fb_obj(fb);
+ stride_div = intel_fb_stride_alignment(dev, fb->modifier[0],
+ fb->pixel_format);
+
I915_WRITE(PLANE_CTL(pipe, 0), plane_ctl);
DRM_DEBUG_KMS("Writing base %08lX %d,%d,%d,%d pitch=%d\n",
@@ -2823,7 +2857,7 @@ static void skylake_update_primary_plane(struct drm_crtc
*crtc,
I915_WRITE(PLANE_SIZE(pipe, 0),
(intel_crtc->config->pipe_src_h - 1) << 16 |
(intel_crtc->config->pipe_src_w - 1));
- I915_WRITE(PLANE_STRIDE(pipe, 0), stride);
+ I915_WRITE(PLANE_STRIDE(pipe, 0), fb->pitches[0] / stride_div);
I915_WRITE(PLANE_SURF(pipe, 0), i915
[Intel-gfx] [PATCH 6/8] drm/i915/skl: Updated watermark programming
From: Tvrtko Ursulin
Recent BSpect updates have changed the watermark calculation to avoid
display flickering in some cases.
v2: Fix check against DDB allocation and tidy the code a bit. (Damien Lespiau)
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Damien Lespiau
---
drivers/gpu/drm/i915/intel_pm.c | 54 +
1 file changed, 33 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 7dcb5b6..0b18e5d 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -2609,7 +2609,7 @@ static uint32_t skl_wm_method1(uint32_t pixel_rate,
uint8_t bytes_per_pixel,
if (latency == 0)
return UINT_MAX;
- wm_intermediate_val = latency * pixel_rate * bytes_per_pixel;
+ wm_intermediate_val = latency * pixel_rate * bytes_per_pixel / 512;
ret = DIV_ROUND_UP(wm_intermediate_val, 1000);
return ret;
@@ -2619,15 +2619,18 @@ static uint32_t skl_wm_method2(uint32_t pixel_rate,
uint32_t pipe_htotal,
uint32_t horiz_pixels, uint8_t bytes_per_pixel,
uint32_t latency)
{
- uint32_t ret, plane_bytes_per_line, wm_intermediate_val;
+ uint32_t ret;
+ uint32_t plane_bytes_per_line, plane_blocks_per_line;
+ uint32_t wm_intermediate_val;
if (latency == 0)
return UINT_MAX;
plane_bytes_per_line = horiz_pixels * bytes_per_pixel;
+ plane_blocks_per_line = DIV_ROUND_UP(plane_bytes_per_line, 512);
wm_intermediate_val = latency * pixel_rate;
ret = DIV_ROUND_UP(wm_intermediate_val, pipe_htotal * 1000) *
- plane_bytes_per_line;
+ plane_blocks_per_line;
return ret;
}
@@ -2707,41 +2710,49 @@ static void skl_compute_wm_pipe_parameters(struct
drm_crtc *crtc,
}
}
-static bool skl_compute_plane_wm(struct skl_pipe_wm_parameters *p,
+static bool skl_compute_plane_wm(const struct drm_i915_private *dev_priv,
+struct skl_pipe_wm_parameters *p,
struct intel_plane_wm_parameters *p_params,
uint16_t ddb_allocation,
-uint32_t mem_value,
+int level,
uint16_t *out_blocks, /* out */
uint8_t *out_lines /* out */)
{
- uint32_t method1, method2, plane_bytes_per_line, res_blocks, res_lines;
- uint32_t result_bytes;
+ uint32_t latency = dev_priv->wm.skl_latency[level];
+ uint32_t method1, method2;
+ uint32_t plane_bytes_per_line, plane_blocks_per_line;
+ uint32_t res_blocks, res_lines;
+ uint32_t selected_result;
- if (mem_value == 0 || !p->active || !p_params->enabled)
+ if (latency == 0 || !p->active || !p_params->enabled)
return false;
method1 = skl_wm_method1(p->pixel_rate,
p_params->bytes_per_pixel,
-mem_value);
+latency);
method2 = skl_wm_method2(p->pixel_rate,
p->pipe_htotal,
p_params->horiz_pixels,
p_params->bytes_per_pixel,
-mem_value);
+latency);
plane_bytes_per_line = p_params->horiz_pixels *
p_params->bytes_per_pixel;
+ plane_blocks_per_line = DIV_ROUND_UP(plane_bytes_per_line, 512);
/* For now xtile and linear */
- if (((ddb_allocation * 512) / plane_bytes_per_line) >= 1)
- result_bytes = min(method1, method2);
+ if ((ddb_allocation / plane_blocks_per_line) >= 1)
+ selected_result = min(method1, method2);
else
- result_bytes = method1;
+ selected_result = method1;
+
+ res_blocks = selected_result + 1;
+ res_lines = DIV_ROUND_UP(selected_result, plane_blocks_per_line);
- res_blocks = DIV_ROUND_UP(result_bytes, 512) + 1;
- res_lines = DIV_ROUND_UP(result_bytes, plane_bytes_per_line);
+ if (level >= 1 && level <= 7)
+ res_blocks++;
- if (res_blocks > ddb_allocation || res_lines > 31)
+ if (res_blocks >= ddb_allocation || res_lines > 31)
return false;
*out_blocks = res_blocks;
@@ -2758,23 +2769,24 @@ static void skl_compute_wm_level(const struct
drm_i915_private *dev_priv,
int num_planes,
struct skl_wm_level *result)
{
- uint16_t latency = dev_priv->wm.skl_latency[level];
uint16_t ddb_blocks;
int i;
for (i = 0; i < num_planes; i++) {
ddb_blocks = skl_ddb_en
[Intel-gfx] [PATCH 8/8] drm/i915/skl: Allow Y (and Yf) frame buffer creation
From: Tvrtko Ursulin
By this patch all underlying bits have been implemented and this
patch actually enables the feature.
v2: Validate passed in fb modifiers to reject garbage. (Daniel Vetter)
v3: Rearrange validation checks per code review comments. (Daniel Vetter)
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Damien Lespiau (v1)
---
drivers/gpu/drm/i915/intel_display.c | 17 +++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 4056fad..1dd0326 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -12825,8 +12825,21 @@ static int intel_framebuffer_init(struct drm_device
*dev,
}
}
- if (mode_cmd->modifier[0] == I915_FORMAT_MOD_Y_TILED) {
- DRM_DEBUG("hardware does not support tiling Y\n");
+ /* Passed in modifier sanity checking. */
+ switch (mode_cmd->modifier[0]) {
+ case I915_FORMAT_MOD_Y_TILED:
+ case I915_FORMAT_MOD_Yf_TILED:
+ if (INTEL_INFO(dev)->gen < 9) {
+ DRM_DEBUG("Unsupported tiling 0x%llx!\n",
+ mode_cmd->modifier[0]);
+ return -EINVAL;
+ }
+ case DRM_FORMAT_MOD_NONE:
+ case I915_FORMAT_MOD_X_TILED:
+ break;
+ default:
+ DRM_ERROR("Unsupported fb modifier 0x%llx!\n",
+ mode_cmd->modifier[0]);
return -EINVAL;
}
--
2.3.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 7/8] drm/i915/skl: Update watermarks for Y tiling
From: Tvrtko Ursulin
Display watermarks need different programming for different tiling
modes.
Set the relevant flag so this happens during the plane commit and
add relevant data into a structure made available to the watermark
computation code.
v2: Pass in tiling info to sprite plane updates as well.
v3: Rebased for plane handling changes.
v4: Handle fb == NULL when plane is disabled.
v5: Refactored for addfb2 interface.
v6: Refactored for fb modifier changes.
v7: Updated for atomic commit by only updating watermarks when tiling changes.
v8: BSpec watermark calculation updates.
v9: Restrict scope of y_tile_minimum variable. (Damien Lespiau)
Signed-off-by: Tvrtko Ursulin
Acked-by: Ander Conselvan de Oliveira
Acked-by: Matt Roper
---
drivers/gpu/drm/i915/intel_display.c | 6
drivers/gpu/drm/i915/intel_drv.h | 1 +
drivers/gpu/drm/i915/intel_pm.c | 55 ++--
drivers/gpu/drm/i915/intel_sprite.c | 6
4 files changed, 59 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 753894d..4056fad 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -12022,6 +12022,12 @@ intel_check_primary_plane(struct drm_plane *plane,
INTEL_FRONTBUFFER_PRIMARY(intel_crtc->pipe);
intel_crtc->atomic.update_fbc = true;
+
+ /* Update watermarks on tiling changes. */
+ if (!plane->state->fb || !state->base.fb ||
+ plane->state->fb->modifier[0] !=
+ state->base.fb->modifier[0])
+ intel_crtc->atomic.update_wm = true;
}
return 0;
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index e21d26c..c6db290 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -501,6 +501,7 @@ struct intel_plane_wm_parameters {
uint8_t bytes_per_pixel;
bool enabled;
bool scaled;
+ u64 tiling;
};
struct intel_plane {
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 0b18e5d..39516aa 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -2617,7 +2617,7 @@ static uint32_t skl_wm_method1(uint32_t pixel_rate,
uint8_t bytes_per_pixel,
static uint32_t skl_wm_method2(uint32_t pixel_rate, uint32_t pipe_htotal,
uint32_t horiz_pixels, uint8_t bytes_per_pixel,
- uint32_t latency)
+ uint64_t tiling, uint32_t latency)
{
uint32_t ret;
uint32_t plane_bytes_per_line, plane_blocks_per_line;
@@ -2627,7 +2627,16 @@ static uint32_t skl_wm_method2(uint32_t pixel_rate,
uint32_t pipe_htotal,
return UINT_MAX;
plane_bytes_per_line = horiz_pixels * bytes_per_pixel;
- plane_blocks_per_line = DIV_ROUND_UP(plane_bytes_per_line, 512);
+
+ if (tiling == I915_FORMAT_MOD_Y_TILED ||
+ tiling == I915_FORMAT_MOD_Yf_TILED) {
+ plane_bytes_per_line *= 4;
+ plane_blocks_per_line = DIV_ROUND_UP(plane_bytes_per_line, 512);
+ plane_blocks_per_line /= 4;
+ } else {
+ plane_blocks_per_line = DIV_ROUND_UP(plane_bytes_per_line, 512);
+ }
+
wm_intermediate_val = latency * pixel_rate;
ret = DIV_ROUND_UP(wm_intermediate_val, pipe_htotal * 1000) *
plane_blocks_per_line;
@@ -2679,6 +2688,7 @@ static void skl_compute_wm_pipe_parameters(struct
drm_crtc *crtc,
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
enum pipe pipe = intel_crtc->pipe;
struct drm_plane *plane;
+ struct drm_framebuffer *fb;
int i = 1; /* Index for sprite planes start */
p->active = intel_crtc_active(crtc);
@@ -2694,6 +2704,14 @@ static void skl_compute_wm_pipe_parameters(struct
drm_crtc *crtc,
crtc->primary->fb->bits_per_pixel / 8;
p->plane[0].horiz_pixels = intel_crtc->config->pipe_src_w;
p->plane[0].vert_pixels = intel_crtc->config->pipe_src_h;
+ p->plane[0].tiling = DRM_FORMAT_MOD_NONE;
+ fb = crtc->primary->fb;
+ /*
+* Framebuffer can be NULL on plane disable, but it does not
+* matter for watermarks if we assume no tiling in that case.
+*/
+ if (fb)
+ p->plane[0].tiling = fb->modifier[0];
p->cursor.enabled = true;
p->cursor.bytes_per_pixel = 4;
@@ -2734,23 +2752,34 @@ static bool skl_compute_plane_wm(const struct
drm_i915_private *dev_priv,
p->pipe_htotal,
p_params->horiz_pixels,
p_params->bytes_per_pixel,
+
[Intel-gfx] [PATCH 4/8] drm/i915/skl: Teach pin_and_fence_fb_obj() about Y tiling constraints
From: Damien Lespiau 1Mb! v2: Rebased for addfb2 interface. (Tvrtko Ursulin) v3: Rebased for fb modifier changes. (Tvrtko Ursulin) Signed-off-by: Damien Lespiau Signed-off-by: Tvrtko Ursulin Reviewed-by: Tvrtko Ursulin --- drivers/gpu/drm/i915/intel_display.c | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 1db63c9..cb17b16 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -2270,8 +2270,12 @@ intel_pin_and_fence_fb_obj(struct drm_plane *plane, } break; case I915_FORMAT_MOD_Y_TILED: - WARN(1, "Y tiled bo slipped through, driver bug!\n"); - return -EINVAL; + case I915_FORMAT_MOD_Yf_TILED: + if (WARN_ONCE(INTEL_INFO(dev)->gen < 9, + "Y tiling bo slipped through, driver bug!\n")) + return -EINVAL; + alignment = 1 * 1024 * 1024; + break; default: MISSING_CASE(fb->modifier[0]); return -EINVAL; -- 2.3.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 5/8] drm/i915/skl: Adjust get_plane_config() to support Yb/Yf tiling
From: Damien Lespiau
v2: Rebased for addfb2 interface and consolidated a bit. (Tvrtko Ursulin)
v3: Rebased for fb modifier changes. (Tvrtko Ursulin)
v4: Use intel_fb_stride_alignment instead of open coding. (Damien Lespiau)
Signed-off-by: Damien Lespiau
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Tvrtko Ursulin
Reviewed-by: Damien Lespiau
---
drivers/gpu/drm/i915/intel_display.c | 40 +---
1 file changed, 23 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index cb17b16..753894d 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -7755,7 +7755,7 @@ skylake_get_initial_plane_config(struct intel_crtc *crtc,
{
struct drm_device *dev = crtc->base.dev;
struct drm_i915_private *dev_priv = dev->dev_private;
- u32 val, base, offset, stride_mult;
+ u32 val, base, offset, stride_mult, tiling;
int pipe = crtc->pipe;
int fourcc, pixel_format;
int aligned_height;
@@ -7774,11 +7774,6 @@ skylake_get_initial_plane_config(struct intel_crtc *crtc,
if (!(val & PLANE_CTL_ENABLE))
goto error;
- if (val & PLANE_CTL_TILED_MASK) {
- plane_config->tiling = I915_TILING_X;
- fb->modifier[0] = I915_FORMAT_MOD_X_TILED;
- }
-
pixel_format = val & PLANE_CTL_FORMAT_MASK;
fourcc = skl_format_to_fourcc(pixel_format,
val & PLANE_CTL_ORDER_RGBX,
@@ -7786,6 +7781,26 @@ skylake_get_initial_plane_config(struct intel_crtc *crtc,
fb->pixel_format = fourcc;
fb->bits_per_pixel = drm_format_plane_cpp(fourcc, 0) * 8;
+ tiling = val & PLANE_CTL_TILED_MASK;
+ switch (tiling) {
+ case PLANE_CTL_TILED_LINEAR:
+ fb->modifier[0] = DRM_FORMAT_MOD_NONE;
+ break;
+ case PLANE_CTL_TILED_X:
+ plane_config->tiling = I915_TILING_X;
+ fb->modifier[0] = I915_FORMAT_MOD_X_TILED;
+ break;
+ case PLANE_CTL_TILED_Y:
+ fb->modifier[0] = I915_FORMAT_MOD_Y_TILED;
+ break;
+ case PLANE_CTL_TILED_YF:
+ fb->modifier[0] = I915_FORMAT_MOD_Yf_TILED;
+ break;
+ default:
+ MISSING_CASE(tiling);
+ goto error;
+ }
+
base = I915_READ(PLANE_SURF(pipe, 0)) & 0xf000;
plane_config->base = base;
@@ -7796,17 +7811,8 @@ skylake_get_initial_plane_config(struct intel_crtc *crtc,
fb->width = ((val >> 0) & 0x1fff) + 1;
val = I915_READ(PLANE_STRIDE(pipe, 0));
- switch (plane_config->tiling) {
- case I915_TILING_NONE:
- stride_mult = 64;
- break;
- case I915_TILING_X:
- stride_mult = 512;
- break;
- default:
- MISSING_CASE(plane_config->tiling);
- goto error;
- }
+ stride_mult = intel_fb_stride_alignment(dev, fb->modifier[0],
+ fb->pixel_format);
fb->pitches[0] = (val & 0x3ff) * stride_mult;
aligned_height = intel_fb_align_height(dev, fb->height,
--
2.3.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5 0/8] Skylake Y tiled scanout
From: Tvrtko Ursulin Starting with Skylake the display engine can scan out Y tiled objects. (Both legacy Y tiled, and the new Yf format.) This series takes the original work by Damien Lespiau and converts it to use the new frame buffer modifiers instead of object set/get tiling. Some patches needed to be dropped, some added and some refactored. Lightly tested with "testdisplay -m -y" and "testdisplay -m --yf". v2: Rebased on v2 of "i915 fb modifier support, respun". v3: * Part which allows Y tiled fb creation extracted out and moved to the end of series. * Dropped redundant "drm/i915/skl: Allow Y tiling for sprites". * Also see individual change logs. v4: * New to the series - watermark programming updates per BSpec. * Addressed review comments in individual patches. v5: * Addressed review comments in individual patches. Damien Lespiau (4): drm/i915/skl: Allow scanning out Y and Yf fbs drm/i915/skl: Adjust intel_fb_align_height() for Yb/Yf tiling drm/i915/skl: Teach pin_and_fence_fb_obj() about Y tiling constraints drm/i915/skl: Adjust get_plane_config() to support Yb/Yf tiling Tvrtko Ursulin (4): drm/i915/skl: Add new displayable tiling formats drm/i915/skl: Updated watermark programming drm/i915/skl: Update watermarks for Y tiling drm/i915/skl: Allow Y (and Yf) frame buffer creation drivers/gpu/drm/i915/intel_display.c | 231 ++- drivers/gpu/drm/i915/intel_drv.h | 3 + drivers/gpu/drm/i915/intel_pm.c | 97 +++ drivers/gpu/drm/i915/intel_sprite.c | 24 +++- include/uapi/drm/drm_fourcc.h| 15 +++ 5 files changed, 283 insertions(+), 87 deletions(-) -- 2.3.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v6 06/32] drm/i915: Extract context switch skip and pd load logic
Michel Thierry writes:
> From: Ben Widawsky
>
> We have some fanciness coming up. This patch just breaks out the logic
> of context switch skip, pd load pre, and pd load post.
>
> v2: Use new functions to replace the logic right away (Daniel)
>
> Cc: Daniel Vetter
> Signed-off-by: Ben Widawsky
> Signed-off-by: Michel Thierry (v2)
> ---
> drivers/gpu/drm/i915/i915_gem_context.c | 40
> +
> 1 file changed, 31 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
> b/drivers/gpu/drm/i915/i915_gem_context.c
> index 755b415..6206d27 100644
> --- a/drivers/gpu/drm/i915/i915_gem_context.c
> +++ b/drivers/gpu/drm/i915/i915_gem_context.c
> @@ -565,6 +565,33 @@ mi_set_context(struct intel_engine_cs *ring,
> return ret;
> }
>
> +static inline bool should_skip_switch(struct intel_engine_cs *ring,
> + struct intel_context *from,
> + struct intel_context *to)
> +{
> + if (from == to && !to->remap_slice)
> + return true;
> +
> + return false;
> +}
> +
> +static bool
> +needs_pd_load_pre(struct intel_engine_cs *ring, struct intel_context *to)
> +{
> + struct drm_i915_private *dev_priv = ring->dev->dev_private;
> +
> + return ((INTEL_INFO(ring->dev)->gen < 8) ||
> + (ring != &dev_priv->ring[RCS])) && to->ppgtt;
> +}
> +
> +static bool
> +needs_pd_load_post(struct intel_engine_cs *ring, struct intel_context *to)
> +{
> + return (!to->legacy_hw_ctx.initialized ||
> + i915_gem_context_is_default(to)) &&
> + to->ppgtt && IS_GEN8(ring->dev);
> +}
> +
> static int do_switch(struct intel_engine_cs *ring,
>struct intel_context *to)
> {
> @@ -573,9 +600,6 @@ static int do_switch(struct intel_engine_cs *ring,
> u32 hw_flags = 0;
> bool uninitialized = false;
> struct i915_vma *vma;
> - bool needs_pd_load_pre = ((INTEL_INFO(ring->dev)->gen < 8) ||
> - (ring != &dev_priv->ring[RCS])) && to->ppgtt;
> - bool needs_pd_load_post = false;
There is no such code in drm-intel-nightly. On top of which tree this is
for?
-Mika
> int ret, i;
>
> if (from != NULL && ring == &dev_priv->ring[RCS]) {
> @@ -583,7 +607,7 @@ static int do_switch(struct intel_engine_cs *ring,
> BUG_ON(!i915_gem_obj_is_pinned(from->legacy_hw_ctx.rcs_state));
> }
>
> - if (from == to && !to->remap_slice)
> + if (should_skip_switch(ring, from, to))
> return 0;
>
> /* Trying to pin first makes error handling easier. */
> @@ -601,7 +625,7 @@ static int do_switch(struct intel_engine_cs *ring,
>*/
> from = ring->last_context;
>
> - if (needs_pd_load_pre) {
> + if (needs_pd_load_pre(ring, to)) {
> /* Older GENs and non render rings still want the load first,
>* "PP_DCLV followed by PP_DIR_BASE register through Load
>* Register Immediate commands in Ring Buffer before submitting
> @@ -646,16 +670,14 @@ static int do_switch(struct intel_engine_cs *ring,
>* XXX: If we implemented page directory eviction code, this
>* optimization needs to be removed.
>*/
> - if (!to->legacy_hw_ctx.initialized || i915_gem_context_is_default(to)) {
> + if (!to->legacy_hw_ctx.initialized || i915_gem_context_is_default(to))
> hw_flags |= MI_RESTORE_INHIBIT;
> - needs_pd_load_post = to->ppgtt && IS_GEN8(ring->dev);
> - }
>
> ret = mi_set_context(ring, to, hw_flags);
> if (ret)
> goto unpin_out;
>
> - if (needs_pd_load_post) {
> + if (needs_pd_load_post(ring, to)) {
> ret = to->ppgtt->switch_mm(to->ppgtt, ring);
> /* The hardware context switch is emitted, but we haven't
>* actually changed the state - so it's probably safe to bail
> --
> 2.1.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm: Fixup racy refcounting in plane_force_disable
Originally it was impossible to be dropping the last refcount in this
function since there was always one around still from the idr. But in
commit 83f45fc360c8e16a330474860ebda872d1384c8c
Author: Daniel Vetter
Date: Wed Aug 6 09:10:18 2014 +0200
drm: Don't grab an fb reference for the idr
we've switched to weak references, broke that assumption but forgot to
fix it up.
Since we still force-disable planes it's only possible to hit this
when racing multiple rmfb with fbdev restoring or similar evil things.
As long as userspace is nice it's impossible to hit the BUG_ON.
But the BUG_ON would most likely be hit from fbdev code, which usually
invovles the console_lock besides all modeset locks. So very likely
we'd never get the bug reports if this was hit in the wild, hence
better be safe than sorry and backport.
Spotted by Matt Roper while reviewing other patches.
Cc: sta...@vger.kernel.org
Cc: Matt Roper
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_crtc.c | 13 +
1 file changed, 1 insertion(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index cc548ecd3634..897f51beaadd 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -524,17 +524,6 @@ void drm_framebuffer_reference(struct drm_framebuffer *fb)
}
EXPORT_SYMBOL(drm_framebuffer_reference);
-static void drm_framebuffer_free_bug(struct kref *kref)
-{
- BUG();
-}
-
-static void __drm_framebuffer_unreference(struct drm_framebuffer *fb)
-{
- DRM_DEBUG("%p: FB ID: %d (%d)\n", fb, fb->base.id,
atomic_read(&fb->refcount.refcount));
- kref_put(&fb->refcount, drm_framebuffer_free_bug);
-}
-
/**
* drm_framebuffer_unregister_private - unregister a private fb from the
lookup idr
* @fb: fb to unregister
@@ -1319,7 +1308,7 @@ void drm_plane_force_disable(struct drm_plane *plane)
return;
}
/* disconnect the plane from the fb and crtc: */
- __drm_framebuffer_unreference(plane->old_fb);
+ drm_framebuffer_unreference(plane->old_fb);
plane->old_fb = NULL;
plane->fb = NULL;
plane->crtc = NULL;
--
2.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 01/51] drm/i915: Rename 'flags' to 'dispatch_flags' for better code reading
On 25/02/2015 21:34, Daniel Vetter wrote:
On Fri, Feb 13, 2015 at 11:48:10AM +, john.c.harri...@intel.com wrote:
From: John Harrison
There is a flags word that is passed through the execbuffer code path all the
way from initial decoding of the user parameters down to the very final dispatch
buffer call. It is simply called 'flags'. Unfortuantely, there are many other
flags words floating around in the same blocks of code. Even more once the GPU
scheduler arrives.
This patch makes it more obvious exactly which flags word is which by renaming
'flags' to 'dispatch_flags'. Note that the bit definitions for this flags word
already have an 'I915_DISPATCH_' prefix on them and so are not quite so
ambiguous.
For: VIZ-1587
I've thought we've decided that the tag is OTC-Jira or similar. For:
certainly looks a bit too generic, and a prefix helps in namespacing if
you want to scan with automated tools for this.
The wiki page about GMIN tagging (which comes from the OTC) very clearly
says to use 'For:' in the case of multi-patch series or 'Issue:' for
single patches and talks about automated tools using these tags to
update and/or close bugs. It also says the tags should be used for linux
kernel upstreaming as well.
Signed-off-by: John Harrison
Anyway looks like a good idea, queued for -next, thanks for the patch.
-Daniel
---
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 25 ++--
drivers/gpu/drm/i915/intel_lrc.c | 10
drivers/gpu/drm/i915/intel_lrc.h |2 +-
drivers/gpu/drm/i915/intel_ringbuffer.c| 35
drivers/gpu/drm/i915/intel_ringbuffer.h|4 ++--
5 files changed, 41 insertions(+), 35 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index b773368..ec9ea45 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -1138,7 +1138,7 @@ i915_gem_ringbuffer_submission(struct drm_device *dev,
struct drm_file *file,
struct drm_i915_gem_execbuffer2 *args,
struct list_head *vmas,
struct drm_i915_gem_object *batch_obj,
- u64 exec_start, u32 flags)
+ u64 exec_start, u32 dispatch_flags)
{
struct drm_clip_rect *cliprects = NULL;
struct drm_i915_private *dev_priv = dev->dev_private;
@@ -1266,19 +1266,19 @@ i915_gem_ringbuffer_submission(struct drm_device *dev,
struct drm_file *file,
ret = ring->dispatch_execbuffer(ring,
exec_start, exec_len,
- flags);
+ dispatch_flags);
if (ret)
goto error;
}
} else {
ret = ring->dispatch_execbuffer(ring,
exec_start, exec_len,
- flags);
+ dispatch_flags);
if (ret)
return ret;
}
- trace_i915_gem_ring_dispatch(intel_ring_get_request(ring), flags);
+ trace_i915_gem_ring_dispatch(intel_ring_get_request(ring),
dispatch_flags);
i915_gem_execbuffer_move_to_active(vmas, ring);
i915_gem_execbuffer_retire_commands(dev, file, ring, batch_obj);
@@ -1353,7 +1353,7 @@ i915_gem_do_execbuffer(struct drm_device *dev, void *data,
struct i915_address_space *vm;
const u32 ctx_id = i915_execbuffer2_get_context_id(*args);
u64 exec_start = args->batch_start_offset;
- u32 flags;
+ u32 dispatch_flags;
int ret;
bool need_relocs;
@@ -1364,15 +1364,15 @@ i915_gem_do_execbuffer(struct drm_device *dev, void *data,
if (ret)
return ret;
- flags = 0;
+ dispatch_flags = 0;
if (args->flags & I915_EXEC_SECURE) {
if (!file->is_master || !capable(CAP_SYS_ADMIN))
return -EPERM;
- flags |= I915_DISPATCH_SECURE;
+ dispatch_flags |= I915_DISPATCH_SECURE;
}
if (args->flags & I915_EXEC_IS_PINNED)
- flags |= I915_DISPATCH_PINNED;
+ dispatch_flags |= I915_DISPATCH_PINNED;
if ((args->flags & I915_EXEC_RING_MASK) > LAST_USER_RING) {
DRM_DEBUG("execbuf with unknown ring: %d\n",
@@ -1495,7 +1495,7 @@ i915_gem_do_execbuffer(struct drm_device *dev, void *data,
args->batch_start_offset,
args->batch_len,
file->is_master,
- &flags);
+
Re: [Intel-gfx] [PATCH] drm/i915: fix failure to power off after hibernate
On Thu, Feb 26, 2015 at 09:01:27PM +0100, Daniel Vetter wrote: > On Thu, Feb 26, 2015 at 08:50:48PM +0200, Imre Deak wrote: [snip] > > > > The problem seems to be that after the kernel puts the device into D3 > > the BIOS still tries to access it, or otherwise assumes that it's in D0. > > This is clearly bogus, since ACPI mandates that devices are put into D3 > > by the OSPM if they are not wake-up sources. In the future we want to > > unify more of the driver's runtime and system suspend paths, for example > > by skipping all the system suspend/hibernation hooks if the device is > > runtime suspended already. Accordingly for all other platforms the goal > > is still to properly power down the device during hibernation. [snip] > > If we see more of these troublesome machines we might need to apply an > even bigger hammer like gen < 5 or so. But as long as there's just 1 > report I think this is the right approach. > > Bjorn, as soon as we have your tested-by that this work we can apply this > and shovel it through the backporting machinery. Isn't there a risk that this will negatively impact machines using gen4 that *don't* have a buggy BIOS? Wouldn't a quirk tied to the laptop or BIOS version be better suited -- or possibly a parameter that can be passed to the driver, which would make it easier to test if others suffering from similar symptoms on other systems suffer from the same issue or not? Just my 2¢. Kind regards, David Weinehall ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 04/51] drm/i915: Merged the many do_execbuf() parameters into a structure
On 25/02/2015 21:52, Daniel Vetter wrote:
On Fri, Feb 13, 2015 at 11:48:13AM +, john.c.harri...@intel.com wrote:
From: John Harrison
The do_execbuf() function takes quite a few parameters. The actual set of
parameters is going to change with the conversion to passing requests around.
Further, it is due to grow massively with the arrival of the GPU scheduler.
This patch simplies the prototype by passing a parameter structure instead.
Changing the parameter set in the future is then simply a matter of
adding/removing items to the structure.
Note that the structure does not contain absolutely everything that is passed
in. This is because the intention is to use this structure more extensively
later in this patch series and more especially in the GPU scheduler that is
coming soon. The latter requires hanging on to the structure as the final
hardware submission can be delayed until long after the execbuf IOCTL has
returned to user land. Thus it is unsafe to put anything in the structure that
is local to the IOCTL call itself - such as the 'args' parameter. All entries
must be copies of data or pointers to structures that are reference counted in
someway and guaranteed to exist for the duration of the batch buffer's life.
For: VIZ-5115
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/i915_drv.h| 27 +++---
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 56 ++--
drivers/gpu/drm/i915/intel_lrc.c | 26 +++--
drivers/gpu/drm/i915/intel_lrc.h |9 ++---
4 files changed, 67 insertions(+), 51 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index e90b786..e6d616b 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1640,6 +1640,16 @@ struct i915_workarounds {
u32 count;
};
+struct i915_execbuffer_params {
+ struct drm_device *dev;
+ struct drm_file *file;
+ uint32_tdispatch_flags;
+ uint32_tbatch_obj_vm_offset;
+ struct intel_engine_cs *ring;
+ struct drm_i915_gem_object *batch_obj;
+ struct intel_context*ctx;
+};
tbh I'm not a fan of parameter objects in C. C is verbose and explicit.
If we add the request then we can remove ring and ctx, which already
improves things. We also have the eb structure we use to pass around a
pile of things, which we could somewhat reuse here. What else do you plan
to add? Just want to figure out whether this is really required ...
-Daniel
The major advantage of this is when the GPU scheduler arrives. It splits
the execbuffer code path in half - front half is all the software state
verification and management, back half is the actual hardware writes to
post the buffer. This structure is used to bridge the two. It contains
all the state created by the front half that is later used by the back
half. It is saved away with the request/scheduler node until such a time
as the back half is called. Hence some kind of structure is required and
it does not really make sense to add all this information to the generic
request structure. Also, with the full pre-emptive scheduler, the
structure grows to about twenty entries and passing that quantity of
individual parameters to a function is just unwieldly!
+
struct drm_i915_private {
struct drm_device *dev;
struct kmem_cache *slab;
@@ -1891,13 +1901,9 @@ struct drm_i915_private {
/* 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,
+ int (*do_execbuf)(struct i915_execbuffer_params *params,
struct drm_i915_gem_execbuffer2 *args,
- struct list_head *vmas,
- struct drm_i915_gem_object *batch_obj,
- u64 exec_start, u32 flags);
+ struct list_head *vmas);
int (*init_rings)(struct drm_device *dev);
void (*cleanup_ring)(struct intel_engine_cs *ring);
void (*stop_ring)(struct intel_engine_cs *ring);
@@ -2622,14 +2628,9 @@ 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,
- struct intel_con
Re: [Intel-gfx] [PATCH 07/51] drm/i915: Early alloc request in execbuff
On 25/02/2015 22:22, Daniel Vetter wrote: On Fri, Feb 13, 2015 at 11:48:16AM +, john.c.harri...@intel.com wrote: From: John Harrison Start of explicit request management in the execbuffer code path. This patch adds a call to allocate a request structure before all the actual hardware work is done. Thus guaranteeing that all that work is tagged by a known request. At present, nothing further is done with the request, the rest comes later in the series. The only noticable change is that failure to get a request (e.g. due to lack of memory) will be caught earlier in the sequence. It now occurs right at the start before any un-undoable work has been done. For: VIZ-5115 Signed-off-by: John Harrison --- drivers/gpu/drm/i915/i915_gem_execbuffer.c | 13 ++--- 1 file changed, 10 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/i915_gem_execbuffer.c index ca85803..61471e9 100644 --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c @@ -1356,7 +1356,7 @@ i915_gem_do_execbuffer(struct drm_device *dev, void *data, const u32 ctx_id = i915_execbuffer2_get_context_id(*args); u32 dispatch_flags; int ret; - bool need_relocs; + bool need_relocs, batch_pinned = false; if (!i915_gem_check_execbuffer(args)) return -EINVAL; @@ -1525,10 +1525,16 @@ i915_gem_do_execbuffer(struct drm_device *dev, void *data, if (ret) goto err; + batch_pinned = true; params->batch_obj_vm_offset = i915_gem_obj_ggtt_offset(batch_obj); } else params->batch_obj_vm_offset = i915_gem_obj_offset(batch_obj, vm); + /* Allocate a request for this batch buffer nice and early. */ + ret = dev_priv->gt.alloc_request(ring, ctx); + if (ret) + goto err; + /* * Save assorted stuff away to pass through to *_submission(). * NB: This data should be 'persistent' and not local as it will @@ -1544,15 +1550,16 @@ i915_gem_do_execbuffer(struct drm_device *dev, void *data, ret = dev_priv->gt.do_execbuf(params, args, &eb->vmas); +err: /* * FIXME: We crucially rely upon the active tracking for the (ppgtt) * batch vma for correctness. For less ugly and less fragility this * needs to be adjusted to also track the ggtt batch vma properly as * active. */ - if (dispatch_flags & I915_DISPATCH_SECURE) + if (batch_pinned) i915_gem_object_ggtt_unpin(batch_obj); -err: + /* the request owns the ref now */ i915_gem_context_unreference(ctx); eb_destroy(eb); This hunk here looks wrong, or maybe the context changed sufficiently already (but I can't find that in previous patches). Why do we need to change the pinning for the ggtt batch pin hack when allocating the request earlier? -Daniel It doesn't change the behaviour. It is just coping with the extra error path. If the alloc request call fails, we need to jump past the do_execbuf() call but not past the batch unpin. Hence the 'err:' tag is moved upwards. That means it is now possible to get to the batch unpin test from an error that occurred before the pin call actually happened. Hence it is no longer safe to just test the dispatch flag. Instead an explicit 'did this get pinned yet' boolean is required. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 08/51] drm/i915: Update alloc_request to return the allocated request
On 25/02/2015 21:08, Daniel Vetter wrote: On Fri, Feb 13, 2015 at 12:21:29PM +, Chris Wilson wrote: On Fri, Feb 13, 2015 at 11:48:17AM +, john.c.harri...@intel.com wrote: From: John Harrison The alloc_request() function does not actually return the newly allocated request. Instead, it must be pulled from ring->outstanding_lazy_request. This patch fixes this so that code can create a request and start using it knowing exactly which request it actually owns. Why do we have different functions in the first place? There seems to be a bit a layer fumble going on with the lrc alloc request also pinning the lrc context. We could pull that out and then share the function again since there's indeed no reason no to. At least afaics. Also we should probably assign the ctx (if there is any) right in the request alloc function so that these two bits are always tied together. -Daniel See later patch 'set context in request creation...'. That moves the ctx assignment out of _i915_add_request() and into alloc_request() for the legacy code path. Thus bringing the legacy and lrc versions back into alignment. As for the pinning, I am leaving that exactly as is as I don't really know the ins and outs of it. One of the execlist experts might be able to comment as to whether that is the right place for it or not. Also, I am currently working on the conversion to struct fence. As part of that, the request allocation changes quite a bit. Rather than have two clones of the code that have to be independently maintained, I have a patch to unify the common portion. We then have i915_gem_request_alloc() that all the driver calls instead of the indirected function pointer. That then does all the common work and chains on to the legacy/execlist specific helper at the end (which currently only sets the ringbuffer field for legacy mode and also does the LRC pinning for execlist mode). ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 24/51] drm/i915: Update deferred context creation to do explicit request management
On 25/02/2015 21:15, Daniel Vetter wrote: On Wed, Feb 18, 2015 at 03:27:38PM +, John Harrison wrote: On 13/02/2015 12:15, Chris Wilson wrote: On Fri, Feb 13, 2015 at 11:48:33AM +, john.c.harri...@intel.com wrote: From: John Harrison In execlist mode, context initialisation is deferred until first use of the given context. This is because execlist mode has many more contexts than legacy mode and many are never actually used. That's not correct. There are no more contexts in execlists than legacy. There are more ringbuffers, or rather the contexts have an extra state object associated with them. Okay, I should have said sub-contexts. Or context state objects. Or something. per-engine ctx state? Naming stuff is hard ;-) Previously, the initialisation commands were written to the ring and tagged with some random request structure via the OLR. This seemed to be causing a null pointer deference bug under certain circumstances (BZ:40112). This patch adds explicit request creation and submission to the deferred initialisation code path. Thus removing any reliance on or randomness caused by the OLR. This is upside down though. The request should be referencing the context (thus instantiating it on demand) and nothing in the context allocation requires the request. The initialisation here should be during i915_request_switch_context(), since it can be entirely shared with legacy. -Chris The request does reference the context - the alloc_reques() function takes a context object as a parameter. Thus it is impossible for the request to be used/supplied/required during context creation. The issue here is the lazy initialisation of the per ring context state which requires sending commands to the ring on first usage of the given context object on the given ring. One problem is that the initialisation request and the batch buffer request cannot be merged at the moment. They both use request->batch_obj for tracking the command object. Thus this patch only works due to the deferred intialisation occurring during the i915_gem_validate_context() call very early on in execbuffer() rather than as part of the context switch within the batch buffer execution which is much later. My request struct doesn't have a batch_obj pointer. Where is that from and why do we need it? Atm just chasing Chris' comments, haven't read the full series yet. It should do! It was added way back in June 2013 by Mika in 'drm/i915: add batch bo to i915_add_request()'. So unless someone has removed it again since I last fetched a tree, you should definitely have it. I'm not sure what you mean by i915_request_switch_context(). The existing i915_switch_context() does now take just a request structure rather than a ring/ringbuf/context mixture. However, it is not really a good idea to do the context switch automatically as part of creating the request. The request creation and request execution could be quite separated in time, especially with a scheduler. It should be possible to move the deferred initialisation within the context switch if the object tracking can be resolved. Thus they could share the same request and there would not be effectively two separate execution calls at the hardware level. Again, that's potentially work that could be done as a follow up task of improving the context management independent of the current task of removing the OLR. I think the biggest risk with adding a separate request for the lrc deferred init is in accidentally nesting request when someone moves around the lrc validation. Atm it's at the top of execbuf but we tend to shuffle things around a lot. Is there some simple WARN_ON we could smash into the alloc function to make sure this never happens? ring->olr would be it, but since we want to kill that that's not great. Or do I see risks which aren't really there? -Daniel There is a WARN_ON that the batch object in the request structure does not get overwritten. Although, that could only happen if the lazy setup and the batch buffer execution were sharing the same request. Nesting multiple requests shouldn't really be a problem. Without the OLR, there is no globally shared state. Having multiple requests being created in parallel is fine. The lazy context setup must be completed before the execbuffer is executed otherwise Bad Things are going to happen irrespective of request usage. So even if the execbuffer request is created first, the lazy setup will still happen at the right time without breaking the execbuffer's request. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 47/51] drm/i915: Update ironlake_enable_rc6() to do explicit request management
On 25/02/2015 21:31, Daniel Vetter wrote: On Wed, Feb 18, 2015 at 02:28:16PM +, John Harrison wrote: On 13/02/2015 17:03, Chris Wilson wrote: On Fri, Feb 13, 2015 at 04:58:24PM +, John Harrison wrote: On 13/02/2015 12:19, Chris Wilson wrote: On Fri, Feb 13, 2015 at 11:48:56AM +, john.c.harri...@intel.com wrote: From: John Harrison Updated ironlake_enable_rc6() to do explicit request creation and submission. If you merged the context here with the common context switching code, we don't even need to touch the ring here. -Chris It would certainly be preferable to not have any ring commands written from deep within the power management code. However, I didn't want to change anything I didn't really need to, especially in code that I'm not at all sure about. Plus I don't have an ironlake to test any significant change on. I did and tested extensively. -Chris Do you have a patch that just does the move of this from PM code to context switch code? Something that I can drop into this series would be great. If not, exactly where about in the context switch code should it go? Should it be in the start of day initialisation, in the per context intialisation, every context switch, only the first switch after a resume, ...? Tracing back to where/when this code is currently executed seems to be quite complicated. The _enable_rc6() function is called during ring reset but only for Gen6+ because Ironlake is broken according to the comment. It is also called by a system power management callback but it is unclear when that would occur. Finally, it is also called from the display code in intel_modeset_init_hw(). ilk rc6 is disabled by default because it crashes machines hard and doesn't seem to be all that useful really. Compared to gen6+ rc6 which has a massive impact on idle power consumption, more with each generation. I've also never heard of anyone managing to make this work reliably. We could also just rip the entire code out I think, at least I wouldn't be surprised if it has bitrot completely by now. -Daniel So just remove the ironlake_enable_rc6() function completely? Or keep it as a stub that just says '/* this has never worked so has been removed */'. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 47/51] drm/i915: Update ironlake_enable_rc6() to do explicit request management
On Wed, Feb 25, 2015 at 10:31:13PM +0100, Daniel Vetter wrote: > On Wed, Feb 18, 2015 at 02:28:16PM +, John Harrison wrote: > > On 13/02/2015 17:03, Chris Wilson wrote: > > >On Fri, Feb 13, 2015 at 04:58:24PM +, John Harrison wrote: > > >>On 13/02/2015 12:19, Chris Wilson wrote: > > >>>On Fri, Feb 13, 2015 at 11:48:56AM +, john.c.harri...@intel.com > > >>>wrote: > > From: John Harrison > > > > Updated ironlake_enable_rc6() to do explicit request creation and > > submission. > > >>>If you merged the context here with the common context switching code, > > >>>we don't even need to touch the ring here. > > >>>-Chris > > >>> > > >>It would certainly be preferable to not have any ring commands > > >>written from deep within the power management code. However, I > > >>didn't want to change anything I didn't really need to, especially > > >>in code that I'm not at all sure about. Plus I don't have an > > >>ironlake to test any significant change on. > > >I did and tested extensively. > > >-Chris > > > > Do you have a patch that just does the move of this from PM code to context > > switch code? Something that I can drop into this series would be great. If > > not, exactly where about in the context switch code should it go? Should it > > be in the start of day initialisation, in the per context intialisation, > > every context switch, only the first switch after a resume, ...? > > > > Tracing back to where/when this code is currently executed seems to be quite > > complicated. The _enable_rc6() function is called during ring reset but only > > for Gen6+ because Ironlake is broken according to the comment. It is also > > called by a system power management callback but it is unclear when that > > would occur. Finally, it is also called from the display code in > > intel_modeset_init_hw(). > > ilk rc6 is disabled by default because it crashes machines hard and > doesn't seem to be all that useful really. Compared to gen6+ rc6 which has > a massive impact on idle power consumption, more with each generation. > > I've also never heard of anyone managing to make this work reliably. We > could also just rip the entire code out I think, at least I wouldn't be > surprised if it has bitrot completely by now. I was running with it when Ben had those ILK context+rc6 patches flying around. But I admit that was some time ago. -- 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 v2] drm/dp: add DPCD definitions from DP 1.1 and 1.2a
On Fri, Feb 27, 2015 at 01:12:46PM +0200, Jani Nikula wrote: > > Apologies, this was supposed to be in reply to > http://mid.gmane.org/54eeecc9.4010...@intel.com > > > On Fri, 27 Feb 2015, Jani Nikula wrote: > > Add a number of DPCD definitions from DP 1.1 and 1.2a. > > > > v2: drop wrong DP version reference, rename DP training set macros > > (Sonika). > > > > Reviewed-by: Sonika Jindal > > Signed-off-by: Jani Nikula Merged to drm-misc, thanks. -Daniel > > --- > > include/drm/drm_dp_helper.h | 93 > > ++--- > > 1 file changed, 88 insertions(+), 5 deletions(-) > > > > diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h > > index a3ecaa06c9db..319d5edfb3b5 100644 > > --- a/include/drm/drm_dp_helper.h > > +++ b/include/drm/drm_dp_helper.h > > @@ -92,6 +92,15 @@ > > # define DP_MSA_TIMING_PAR_IGNORED (1 << 6) /* eDP */ > > # define DP_OUI_SUPPORT(1 << 7) > > > > +#define DP_RECEIVE_PORT_0_CAP_00x008 > > +# define DP_LOCAL_EDID_PRESENT (1 << 1) > > +# define DP_ASSOCIATED_TO_PRECEDING_PORT(1 << 2) > > + > > +#define DP_RECEIVE_PORT_0_BUFFER_SIZE 0x009 > > + > > +#define DP_RECEIVE_PORT_1_CAP_00x00a > > +#define DP_RECEIVE_PORT_1_BUFFER_SIZE 0x00b > > + > > #define DP_I2C_SPEED_CAP 0x00c/* DPI */ > > # define DP_I2C_SPEED_1K 0x01 > > # define DP_I2C_SPEED_5K 0x02 > > @@ -101,10 +110,16 @@ > > # define DP_I2C_SPEED_1M 0x20 > > > > #define DP_EDP_CONFIGURATION_CAP0x00d /* XXX 1.2? */ > > +# define DP_ALTERNATE_SCRAMBLER_RESET_CAP (1 << 0) > > +# define DP_FRAMING_CHANGE_CAP (1 << 1) > > # define DP_DPCD_DISPLAY_CONTROL_CAPABLE (1 << 3) /* edp v1.2 or > > higher */ > > > > #define DP_TRAINING_AUX_RD_INTERVAL 0x00e /* XXX 1.2? */ > > > > +#define DP_ADAPTER_CAP 0x00f /* 1.2 */ > > +# define DP_FORCE_LOAD_SENSE_CAP (1 << 0) > > +# define DP_ALTERNATE_I2C_PATTERN_CAP (1 << 1) > > + > > #define DP_SUPPORTED_LINK_RATES0x010 /* eDP 1.4 */ > > # define DP_MAX_SUPPORTED_RATES 8 /* 16-bit > > little-endian */ > > > > @@ -115,6 +130,44 @@ > > #define DP_MSTM_CAP0x021 /* 1.2 */ > > # define DP_MST_CAP(1 << 0) > > > > +#define DP_NUMBER_OF_AUDIO_ENDPOINTS 0x022 /* 1.2 */ > > + > > +/* AV_SYNC_DATA_BLOCK 1.2 */ > > +#define DP_AV_GRANULARITY 0x023 > > +# define DP_AG_FACTOR_MASK (0xf << 0) > > +# define DP_AG_FACTOR_3MS (0 << 0) > > +# define DP_AG_FACTOR_2MS (1 << 0) > > +# define DP_AG_FACTOR_1MS (2 << 0) > > +# define DP_AG_FACTOR_500US(3 << 0) > > +# define DP_AG_FACTOR_200US(4 << 0) > > +# define DP_AG_FACTOR_100US(5 << 0) > > +# define DP_AG_FACTOR_10US (6 << 0) > > +# define DP_AG_FACTOR_1US (7 << 0) > > +# define DP_VG_FACTOR_MASK (0xf << 4) > > +# define DP_VG_FACTOR_3MS (0 << 4) > > +# define DP_VG_FACTOR_2MS (1 << 4) > > +# define DP_VG_FACTOR_1MS (2 << 4) > > +# define DP_VG_FACTOR_500US(3 << 4) > > +# define DP_VG_FACTOR_200US(4 << 4) > > +# define DP_VG_FACTOR_100US(5 << 4) > > + > > +#define DP_AUD_DEC_LAT00x024 > > +#define DP_AUD_DEC_LAT10x025 > > + > > +#define DP_AUD_PP_LAT0 0x026 > > +#define DP_AUD_PP_LAT1 0x027 > > + > > +#define DP_VID_INTER_LAT 0x028 > > + > > +#define DP_VID_PROG_LAT0x029 > > + > > +#define DP_REP_LAT 0x02a > > + > > +#define DP_AUD_DEL_INS00x02b > > +#define DP_AUD_DEL_INS10x02c > > +#define DP_AUD_DEL_INS20x02d > > +/* End of AV_SYNC_DATA_BLOCK */ > > + > > #define DP_GUID0x030 /* 1.2 */ > > > > #define DP_PSR_SUPPORT 0x070 /* XXX 1.2? */ > > @@ -173,11 +226,12 @@ > > # define DP_TRAINING_PATTERN_3 3 /* 1.2 */ > > # define DP_TRAINING_PATTERN_MASK 0x3 > > > > -# define DP_LINK_QUAL_PATTERN_DISABLE (0 << 2) > > -# define DP_LINK_QUAL_PATTERN_D10_2(1 << 2) > > -# define DP_LINK_QUAL_PATTERN_ERROR_RATE(2 << 2) > > -# define DP_LINK_QUAL_PATTERN_PRBS7(3 << 2) > > -# define DP_LINK_QUAL_PATTERN_MASK (3 << 2) > > +/* DPCD 1.1 only. For DPCD >= 1.2 see per-lane DP_LINK_QUAL_LANEn_SET */ > > +# define DP_LINK_QUAL_PATTERN_11_DISABLE(0 << 2) > > +# define DP_LINK_QUAL_PATTERN_11_D10_2 (1 << 2) > > +# defin
Re: [Intel-gfx] [PATCH 01/51] drm/i915: Rename 'flags' to 'dispatch_flags' for better code reading
On Fri, Feb 27, 2015 at 12:14:06PM +, John Harrison wrote:
> On 25/02/2015 21:34, Daniel Vetter wrote:
> >On Fri, Feb 13, 2015 at 11:48:10AM +, john.c.harri...@intel.com wrote:
> >>From: John Harrison
> >>
> >>There is a flags word that is passed through the execbuffer code path all
> >>the
> >>way from initial decoding of the user parameters down to the very final
> >>dispatch
> >>buffer call. It is simply called 'flags'. Unfortuantely, there are many
> >>other
> >>flags words floating around in the same blocks of code. Even more once the
> >>GPU
> >>scheduler arrives.
> >>
> >>This patch makes it more obvious exactly which flags word is which by
> >>renaming
> >>'flags' to 'dispatch_flags'. Note that the bit definitions for this flags
> >>word
> >>already have an 'I915_DISPATCH_' prefix on them and so are not quite so
> >>ambiguous.
> >>
> >>For: VIZ-1587
> >I've thought we've decided that the tag is OTC-Jira or similar. For:
> >certainly looks a bit too generic, and a prefix helps in namespacing if
> >you want to scan with automated tools for this.
>
> The wiki page about GMIN tagging (which comes from the OTC) very clearly
> says to use 'For:' in the case of multi-patch series or 'Issue:' for single
> patches and talks about automated tools using these tags to update and/or
> close bugs. It also says the tags should be used for linux kernel
> upstreaming as well.
Well I guess that wasn't a very nice decision to make without the
namespacing ... Whom do I need to send a mail to to make a fuzz about
this? I really don't think For: and Issue: are really great ideas for tags
to internal tracking when we're supposed to add them to the public git
repo.
Maybe just add them all to cc on this thread.
-Daniel
>
>
> >
> >>Signed-off-by: John Harrison
> >Anyway looks like a good idea, queued for -next, thanks for the patch.
> >-Daniel
> >>---
> >> drivers/gpu/drm/i915/i915_gem_execbuffer.c | 25 ++--
> >> drivers/gpu/drm/i915/intel_lrc.c | 10
> >> drivers/gpu/drm/i915/intel_lrc.h |2 +-
> >> drivers/gpu/drm/i915/intel_ringbuffer.c| 35
> >>
> >> drivers/gpu/drm/i915/intel_ringbuffer.h|4 ++--
> >> 5 files changed, 41 insertions(+), 35 deletions(-)
> >>
> >>diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> >>b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> >>index b773368..ec9ea45 100644
> >>--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> >>+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> >>@@ -1138,7 +1138,7 @@ i915_gem_ringbuffer_submission(struct drm_device
> >>*dev, struct drm_file *file,
> >> struct drm_i915_gem_execbuffer2 *args,
> >> struct list_head *vmas,
> >> struct drm_i915_gem_object *batch_obj,
> >>- u64 exec_start, u32 flags)
> >>+ u64 exec_start, u32 dispatch_flags)
> >> {
> >>struct drm_clip_rect *cliprects = NULL;
> >>struct drm_i915_private *dev_priv = dev->dev_private;
> >>@@ -1266,19 +1266,19 @@ i915_gem_ringbuffer_submission(struct drm_device
> >>*dev, struct drm_file *file,
> >>ret = ring->dispatch_execbuffer(ring,
> >>exec_start, exec_len,
> >>- flags);
> >>+ dispatch_flags);
> >>if (ret)
> >>goto error;
> >>}
> >>} else {
> >>ret = ring->dispatch_execbuffer(ring,
> >>exec_start, exec_len,
> >>- flags);
> >>+ dispatch_flags);
> >>if (ret)
> >>return ret;
> >>}
> >>- trace_i915_gem_ring_dispatch(intel_ring_get_request(ring), flags);
> >>+ trace_i915_gem_ring_dispatch(intel_ring_get_request(ring),
> >>dispatch_flags);
> >>i915_gem_execbuffer_move_to_active(vmas, ring);
> >>i915_gem_execbuffer_retire_commands(dev, file, ring, batch_obj);
> >>@@ -1353,7 +1353,7 @@ i915_gem_do_execbuffer(struct drm_device *dev, void
> >>*data,
> >>struct i915_address_space *vm;
> >>const u32 ctx_id = i915_execbuffer2_get_context_id(*args);
> >>u64 exec_start = args->batch_start_offset;
> >>- u32 flags;
> >>+ u32 dispatch_flags;
> >>int ret;
> >>bool need_relocs;
> >>@@ -1364,15 +1364,15 @@ i915_gem_do_execbuffer(struct drm_device *dev, void
> >>*data,
> >>if (ret)
> >>return ret;
> >>- flags = 0;
> >>+ dispatch_flags = 0;
> >>if (args->flags & I915_EXEC_SECURE) {
> >>if (!file->is_master || !capable(CAP_SYS_ADMIN))
> >>return -EPERM;
> >>- flags |= I915_DISPATCH_SECURE;
> >>+ dispatch_flags |= I915_DISPATCH_SECURE;
> >>}
> >>if
Re: [Intel-gfx] [PATCH 04/51] drm/i915: Merged the many do_execbuf() parameters into a structure
On Fri, Feb 27, 2015 at 12:22:42PM +, John Harrison wrote:
> On 25/02/2015 21:52, Daniel Vetter wrote:
> >On Fri, Feb 13, 2015 at 11:48:13AM +, john.c.harri...@intel.com wrote:
> >>From: John Harrison
> >>
> >>The do_execbuf() function takes quite a few parameters. The actual set of
> >>parameters is going to change with the conversion to passing requests
> >>around.
> >>Further, it is due to grow massively with the arrival of the GPU scheduler.
> >>
> >>This patch simplies the prototype by passing a parameter structure instead.
> >>Changing the parameter set in the future is then simply a matter of
> >>adding/removing items to the structure.
> >>
> >>Note that the structure does not contain absolutely everything that is
> >>passed
> >>in. This is because the intention is to use this structure more extensively
> >>later in this patch series and more especially in the GPU scheduler that is
> >>coming soon. The latter requires hanging on to the structure as the final
> >>hardware submission can be delayed until long after the execbuf IOCTL has
> >>returned to user land. Thus it is unsafe to put anything in the structure
> >>that
> >>is local to the IOCTL call itself - such as the 'args' parameter. All
> >>entries
> >>must be copies of data or pointers to structures that are reference counted
> >>in
> >>someway and guaranteed to exist for the duration of the batch buffer's life.
> >>
> >>For: VIZ-5115
> >>Signed-off-by: John Harrison
> >>---
> >> drivers/gpu/drm/i915/i915_drv.h| 27 +++---
> >> drivers/gpu/drm/i915/i915_gem_execbuffer.c | 56
> >> ++--
> >> drivers/gpu/drm/i915/intel_lrc.c | 26 +++--
> >> drivers/gpu/drm/i915/intel_lrc.h |9 ++---
> >> 4 files changed, 67 insertions(+), 51 deletions(-)
> >>
> >>diff --git a/drivers/gpu/drm/i915/i915_drv.h
> >>b/drivers/gpu/drm/i915/i915_drv.h
> >>index e90b786..e6d616b 100644
> >>--- a/drivers/gpu/drm/i915/i915_drv.h
> >>+++ b/drivers/gpu/drm/i915/i915_drv.h
> >>@@ -1640,6 +1640,16 @@ struct i915_workarounds {
> >>u32 count;
> >> };
> >>+struct i915_execbuffer_params {
> >>+ struct drm_device *dev;
> >>+ struct drm_file *file;
> >>+ uint32_tdispatch_flags;
> >>+ uint32_tbatch_obj_vm_offset;
> >>+ struct intel_engine_cs *ring;
> >>+ struct drm_i915_gem_object *batch_obj;
> >>+ struct intel_context*ctx;
> >>+};
> >tbh I'm not a fan of parameter objects in C. C is verbose and explicit.
> >
> >If we add the request then we can remove ring and ctx, which already
> >improves things. We also have the eb structure we use to pass around a
> >pile of things, which we could somewhat reuse here. What else do you plan
> >to add? Just want to figure out whether this is really required ...
> >-Daniel
>
> The major advantage of this is when the GPU scheduler arrives. It splits the
> execbuffer code path in half - front half is all the software state
> verification and management, back half is the actual hardware writes to post
> the buffer. This structure is used to bridge the two. It contains all the
> state created by the front half that is later used by the back half. It is
> saved away with the request/scheduler node until such a time as the back
> half is called. Hence some kind of structure is required and it does not
> really make sense to add all this information to the generic request
> structure. Also, with the full pre-emptive scheduler, the structure grows to
> about twenty entries and passing that quantity of individual parameters to a
> function is just unwieldly!
Well we already have an execbuf tracking structure with eb_vmas. And then
there's requests. So if this is more than just a parameter object I wonder
whether we shouldn't reuse either of these. Adding them all to requests is
imo totally ok.
Oh and a bikeshed aside: imo the ->do_exebuf name is really confusing,
since it clashes with the the various do_execbuf functions we have which
are at a higher level. Also the implementations all have a _submission
postfix. Imo better names would be do_submission or engine_submit or
something simlar. The only caveat is that we need to make sure the
lifetime rules for any pointers are ok. E.g. before we return from the
ioctl we need to clear out drm_i915_gem_execbuffer2 *args pointers if we
store them in the request structure.
Can you please pick a name and insert that rename patch somewhere
convenient (for you) in your series?
Thanks, Daniel
>
>
> >>+
> >> struct drm_i915_private {
> >>struct drm_device *dev;
> >>struct kmem_cache *slab;
> >>@@ -1891,13 +1901,9 @@ struct drm_i915_private {
> >>/* Abstract the submission mechanism (legacy ringbuffer or execlists)
> >> away */
> >>struct {
> >>- int (*do_execbuf)(struct drm_device *dev, struct drm_file *file,
> >>- struct intel_engine_c
[Intel-gfx] [PATCH] drm/i915: Extract context switch skip and add pd load logic
From: Ben Widawsky
This patch just breaks out the logic of context switch skip.
It also adds pd load pre, and pd load post logic (for GEN8).
v2: Use new functions to replace the logic right away (Daniel)
v3: Add missing pd load logic.
Cc: Daniel Vetter
Signed-off-by: Ben Widawsky
Signed-off-by: Michel Thierry (v2+)
---
drivers/gpu/drm/i915/i915_gem_context.c | 48 +++--
1 file changed, 46 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index 70346b0..8474e2c 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -569,6 +569,33 @@ mi_set_context(struct intel_engine_cs *ring,
return ret;
}
+static inline bool should_skip_switch(struct intel_engine_cs *ring,
+ struct intel_context *from,
+ struct intel_context *to)
+{
+ if (from == to && !to->remap_slice)
+ return true;
+
+ return false;
+}
+
+static bool
+needs_pd_load_pre(struct intel_engine_cs *ring, struct intel_context *to)
+{
+ struct drm_i915_private *dev_priv = ring->dev->dev_private;
+
+ return ((INTEL_INFO(ring->dev)->gen < 8) ||
+ (ring != &dev_priv->ring[RCS])) && to->ppgtt;
+}
+
+static bool
+needs_pd_load_post(struct intel_engine_cs *ring, struct intel_context *to)
+{
+ return (!to->legacy_hw_ctx.initialized ||
+ i915_gem_context_is_default(to)) &&
+ to->ppgtt && IS_GEN8(ring->dev);
+}
+
static int do_switch(struct intel_engine_cs *ring,
struct intel_context *to)
{
@@ -584,7 +611,7 @@ static int do_switch(struct intel_engine_cs *ring,
BUG_ON(!i915_gem_obj_is_pinned(from->legacy_hw_ctx.rcs_state));
}
- if (from == to && !to->remap_slice)
+ if (should_skip_switch(ring, from, to))
return 0;
/* Trying to pin first makes error handling easier. */
@@ -602,7 +629,11 @@ static int do_switch(struct intel_engine_cs *ring,
*/
from = ring->last_context;
- if (to->ppgtt) {
+ if (needs_pd_load_pre(ring, to)) {
+ /* Older GENs and non render rings still want the load first,
+* "PP_DCLV followed by PP_DIR_BASE register through Load
+* Register Immediate commands in Ring Buffer before submitting
+* a context."*/
trace_switch_mm(ring, to);
ret = to->ppgtt->switch_mm(to->ppgtt, ring);
if (ret)
@@ -644,6 +675,19 @@ static int do_switch(struct intel_engine_cs *ring,
if (ret)
goto unpin_out;
+ if (needs_pd_load_post(ring, to)) {
+ ret = to->ppgtt->switch_mm(to->ppgtt, ring);
+ /* The hardware context switch is emitted, but we haven't
+* actually changed the state - so it's probably safe to bail
+* here. Still, let the user know something dangerous has
+* happened.
+*/
+ if (ret) {
+ DRM_ERROR("Failed to change address space on context
switch\n");
+ goto unpin_out;
+ }
+ }
+
for (i = 0; i < MAX_L3_SLICES; i++) {
if (!(to->remap_slice & (1
Re: [Intel-gfx] [PATCH 07/51] drm/i915: Early alloc request in execbuff
On Fri, Feb 27, 2015 at 12:27:15PM +, John Harrison wrote: > On 25/02/2015 22:22, Daniel Vetter wrote: > >On Fri, Feb 13, 2015 at 11:48:16AM +, john.c.harri...@intel.com wrote: > >>From: John Harrison > >> > >>Start of explicit request management in the execbuffer code path. This patch > >>adds a call to allocate a request structure before all the actual hardware > >>work > >>is done. Thus guaranteeing that all that work is tagged by a known request. > >>At > >>present, nothing further is done with the request, the rest comes later in > >>the > >>series. > >> > >>The only noticable change is that failure to get a request (e.g. due to > >>lack of > >>memory) will be caught earlier in the sequence. It now occurs right at the > >>start > >>before any un-undoable work has been done. > >> > >>For: VIZ-5115 > >>Signed-off-by: John Harrison > >>--- > >> drivers/gpu/drm/i915/i915_gem_execbuffer.c | 13 ++--- > >> 1 file changed, 10 insertions(+), 3 deletions(-) > >> > >>diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c > >>b/drivers/gpu/drm/i915/i915_gem_execbuffer.c > >>index ca85803..61471e9 100644 > >>--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c > >>+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c > >>@@ -1356,7 +1356,7 @@ i915_gem_do_execbuffer(struct drm_device *dev, void > >>*data, > >>const u32 ctx_id = i915_execbuffer2_get_context_id(*args); > >>u32 dispatch_flags; > >>int ret; > >>- bool need_relocs; > >>+ bool need_relocs, batch_pinned = false; > >>if (!i915_gem_check_execbuffer(args)) > >>return -EINVAL; > >>@@ -1525,10 +1525,16 @@ i915_gem_do_execbuffer(struct drm_device *dev, void > >>*data, > >>if (ret) > >>goto err; > >>+ batch_pinned = true; > >>params->batch_obj_vm_offset = > >> i915_gem_obj_ggtt_offset(batch_obj); > >>} else > >>params->batch_obj_vm_offset = i915_gem_obj_offset(batch_obj, > >> vm); > >>+ /* Allocate a request for this batch buffer nice and early. */ > >>+ ret = dev_priv->gt.alloc_request(ring, ctx); > >>+ if (ret) > >>+ goto err; > >>+ > >>/* > >> * Save assorted stuff away to pass through to *_submission(). > >> * NB: This data should be 'persistent' and not local as it will > >>@@ -1544,15 +1550,16 @@ i915_gem_do_execbuffer(struct drm_device *dev, void > >>*data, > >>ret = dev_priv->gt.do_execbuf(params, args, &eb->vmas); > >>+err: > >>/* > >> * FIXME: We crucially rely upon the active tracking for the (ppgtt) > >> * batch vma for correctness. For less ugly and less fragility this > >> * needs to be adjusted to also track the ggtt batch vma properly as > >> * active. > >> */ > >>- if (dispatch_flags & I915_DISPATCH_SECURE) > >>+ if (batch_pinned) > >>i915_gem_object_ggtt_unpin(batch_obj); > >>-err: > >>+ > >>/* the request owns the ref now */ > >>i915_gem_context_unreference(ctx); > >>eb_destroy(eb); > >This hunk here looks wrong, or maybe the context changed sufficiently > >already (but I can't find that in previous patches). Why do we need to > >change the pinning for the ggtt batch pin hack when allocating the request > >earlier? > >-Daniel > > It doesn't change the behaviour. It is just coping with the extra error > path. If the alloc request call fails, we need to jump past the do_execbuf() > call but not past the batch unpin. Hence the 'err:' tag is moved upwards. > That means it is now possible to get to the batch unpin test from an error > that occurred before the pin call actually happened. Hence it is no longer > safe to just test the dispatch flag. Instead an explicit 'did this get > pinned yet' boolean is required. Ah I see what's going on. The usual pattern is to just duplicate goto targets, i.e. here: err_batch_unpin: /* * FIXME: We crucially rely upon the active tracking for the (ppgtt) * batch vma for correctness. For less ugly and less fragility this * needs to be adjusted to also track the ggtt batch vma properly as * active. */ if (dispatch_flags & I915_DISPATCH_SECURE) i915_gem_object_ggtt_unpin(batch_obj); err: /* the request owns the ref now */ i915_gem_context_unreference(ctx); eb_destroy(eb); Then you can let gcc deal with how to best structure the control flow for you. It means a bit larger diff since you need to change a pile of goto err; to goto err_batch_unpin, but imo that also makes it easier for reviewers to double-check there's no error case with funky requirements now broken. Cheers, 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
[Intel-gfx] [PATCH] drm/i915: Initialize all contexts
From: Ben Widawsky
The problem is we're going to switch to a new context, which could be
the default context. The plan was to use restore inhibit, which would be
fine, except if we are using dynamic page tables (which we will). If we
use dynamic page tables and we don't load new page tables, the previous
page tables might go away, and future operations will fault.
CTXA runs.
switch to default, restore inhibit
CTXA dies and has its address space taken away.
Run CTXB, tries to save using the context A's address space - this
fails.
The general solution is to make sure every context has it's own state,
and its own address space. For cases when we must restore inhibit, first
thing we do is load a valid address space. I thought this would be
enough, but apparently there are references within the context itself
which will refer to the old address space - therefore, we also must
reinitialize.
It was tricky to track this down as we don't have much insight into what
happens in a context save.
This is required for the next patch which enables dynamic page tables.
v2: to->ppgtt is only valid in full ppgtt.
v3: Rebased.
Signed-off-by: Ben Widawsky
Signed-off-by: Michel Thierry (v2+)
---
drivers/gpu/drm/i915/i915_gem_context.c | 25 ++---
1 file changed, 14 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index 8b288a8..1ff86f1 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -600,13 +600,6 @@ needs_pd_load_pre(struct intel_engine_cs *ring, struct
intel_context *to)
(ring != &dev_priv->ring[RCS])) && to->ppgtt;
}
-static bool
-needs_pd_load_post(struct intel_engine_cs *ring, struct intel_context *to)
-{
- return IS_GEN8(ring->dev) &&
- (to->ppgtt || &to->ppgtt->pd_dirty_rings);
-}
-
static int do_switch(struct intel_engine_cs *ring,
struct intel_context *to)
{
@@ -685,16 +678,26 @@ static int do_switch(struct intel_engine_cs *ring,
goto unpin_out;
}
- if (!to->legacy_hw_ctx.initialized || i915_gem_context_is_default(to))
+ /* GEN8 does *not* require an explicit reload if the PDPs have been
+* setup, and we do not wish to move them.
+*/
+ if (!to->legacy_hw_ctx.initialized) {
hw_flags |= MI_RESTORE_INHIBIT;
- else if (to->ppgtt && test_and_clear_bit(ring->id,
&to->ppgtt->pd_dirty_rings))
+ /* NB: If we inhibit the restore, the context is not allowed to
+* die because future work may end up depending on valid address
+* space. This means we must enforce that a page table load
+* occur when this occurs. */
+ } else if (to->ppgtt && test_and_clear_bit(ring->id,
&to->ppgtt->pd_dirty_rings))
hw_flags |= MI_FORCE_RESTORE;
ret = mi_set_context(ring, to, hw_flags);
if (ret)
goto unpin_out;
- if (needs_pd_load_post(ring, to)) {
+ if (IS_GEN8(ring->dev) && to->ppgtt && (hw_flags & MI_RESTORE_INHIBIT))
{
+ /* We have a valid page directory (scratch) to switch to. This
+* allows the old VM to be freed. Note that if anything occurs
+* between the set context, and here, we are f*cked */
ret = to->ppgtt->switch_mm(to->ppgtt, ring);
/* The hardware context switch is emitted, but we haven't
* actually changed the state - so it's probably safe to bail
@@ -744,7 +747,7 @@ static int do_switch(struct intel_engine_cs *ring,
i915_gem_context_unreference(from);
}
- uninitialized = !to->legacy_hw_ctx.initialized && from == NULL;
+ uninitialized = !to->legacy_hw_ctx.initialized;
to->legacy_hw_ctx.initialized = true;
done:
--
2.1.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 08/51] drm/i915: Update alloc_request to return the allocated request
On Fri, Feb 27, 2015 at 12:34:29PM +, John Harrison wrote: > On 25/02/2015 21:08, Daniel Vetter wrote: > >On Fri, Feb 13, 2015 at 12:21:29PM +, Chris Wilson wrote: > >>On Fri, Feb 13, 2015 at 11:48:17AM +, john.c.harri...@intel.com wrote: > >>>From: John Harrison > >>> > >>>The alloc_request() function does not actually return the newly allocated > >>>request. Instead, it must be pulled from ring->outstanding_lazy_request. > >>>This > >>>patch fixes this so that code can create a request and start using it > >>>knowing > >>>exactly which request it actually owns. > >>Why do we have different functions in the first place? > >There seems to be a bit a layer fumble going on with the lrc alloc request > >also pinning the lrc context. We could pull that out and then share the > >function again since there's indeed no reason no to. At least afaics. > > > >Also we should probably assign the ctx (if there is any) right in the > >request alloc function so that these two bits are always tied together. > >-Daniel > > See later patch 'set context in request creation...'. That moves the ctx > assignment out of _i915_add_request() and into alloc_request() for the > legacy code path. Thus bringing the legacy and lrc versions back into > alignment. As for the pinning, I am leaving that exactly as is as I don't > really know the ins and outs of it. One of the execlist experts might be > able to comment as to whether that is the right place for it or not. > > Also, I am currently working on the conversion to struct fence. As part of > that, the request allocation changes quite a bit. Rather than have two > clones of the code that have to be independently maintained, I have a patch > to unify the common portion. We then have i915_gem_request_alloc() that all > the driver calls instead of the indirected function pointer. That then does > all the common work and chains on to the legacy/execlist specific helper at > the end (which currently only sets the ringbuffer field for legacy mode and > also does the LRC pinning for execlist mode). That sounds exactly like what I'd want to see here. So no need for additional frobbing in the mean time imo. -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 v2] drm/dp: add DPCD definitions from eDP 1.4
Reviewed-by: Sonika Jindal On 2/27/2015 4:41 PM, Jani Nikula wrote: Add a number of DPCD definitions from eDP 1.4. v2: s/DP_ALPM_LOCK_TIMEOUT_ERROR_STATUS/DP_ALPM_LOCK_TIMEOUT_ERROR/ (Sonika) Signed-off-by: Jani Nikula --- include/drm/drm_dp_helper.h | 37 + 1 file changed, 37 insertions(+) diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h index 319d5edfb3b5..c5fdc2d3ca97 100644 --- a/include/drm/drm_dp_helper.h +++ b/include/drm/drm_dp_helper.h @@ -168,10 +168,18 @@ #define DP_AUD_DEL_INS2 0x02d /* End of AV_SYNC_DATA_BLOCK */ +#define DP_RECEIVER_ALPM_CAP 0x02e /* eDP 1.4 */ +# define DP_ALPM_CAP (1 << 0) + +#define DP_SINK_DEVICE_AUX_FRAME_SYNC_CAP 0x02f /* eDP 1.4 */ +# define DP_AUX_FRAME_SYNC_CAP (1 << 0) + #define DP_GUID 0x030 /* 1.2 */ #define DP_PSR_SUPPORT 0x070 /* XXX 1.2? */ # define DP_PSR_IS_SUPPORTED1 +# define DP_PSR2_IS_SUPPORTED 2 /* eDP 1.4 */ + #define DP_PSR_CAPS 0x071 /* XXX 1.2? */ # define DP_PSR_NO_TRAIN_ON_EXIT1 # define DP_PSR_SETUP_TIME_330 (0 << 1) @@ -211,6 +219,7 @@ /* link configuration */ #define DP_LINK_BW_SET 0x100 +# define DP_LINK_RATE_TABLE0x00/* eDP 1.4 */ # define DP_LINK_BW_1_62 0x06 # define DP_LINK_BW_2_7 0x0a # define DP_LINK_BW_5_4 0x14/* 1.2 */ @@ -307,15 +316,30 @@ #define DP_AUDIO_DELAY2 0x114 #define DP_LINK_RATE_SET 0x115 /* eDP 1.4 */ +# define DP_LINK_RATE_SET_SHIFT0 +# define DP_LINK_RATE_SET_MASK (7 << 0) + +#define DP_RECEIVER_ALPM_CONFIG0x116 /* eDP 1.4 */ +# define DP_ALPM_ENABLE(1 << 0) +# define DP_ALPM_LOCK_ERROR_IRQ_HPD_ENABLE (1 << 1) + +#define DP_SINK_DEVICE_AUX_FRAME_SYNC_CONF 0x117 /* eDP 1.4 */ +# define DP_AUX_FRAME_SYNC_ENABLE (1 << 0) +# define DP_IRQ_HPD_ENABLE (1 << 1) #define DP_UPSTREAM_DEVICE_DP_PWR_NEED0x118 /* 1.2 */ # define DP_PWR_NOT_NEEDED(1 << 0) +#define DP_AUX_FRAME_SYNC_VALUE0x15c /* eDP 1.4 */ +# define DP_AUX_FRAME_SYNC_VALID (1 << 0) + #define DP_PSR_EN_CFG 0x170 /* XXX 1.2? */ # define DP_PSR_ENABLE(1 << 0) # define DP_PSR_MAIN_LINK_ACTIVE (1 << 1) # define DP_PSR_CRC_VERIFICATION (1 << 2) # define DP_PSR_FRAME_CAPTURE (1 << 3) +# define DP_PSR_SELECTIVE_UPDATE (1 << 4) +# define DP_PSR_IRQ_HPD_WITH_CRC_ERRORS (1 << 5) #define DP_ADAPTER_CTRL 0x1a0 # define DP_ADAPTER_CTRL_FORCE_LOAD_SENSE (1 << 0) @@ -423,6 +447,10 @@ # define DP_SET_POWER_MASK 0x3 #define DP_EDP_DPCD_REV 0x700/* eDP 1.2 */ +# define DP_EDP_11 0x00 +# define DP_EDP_12 0x01 +# define DP_EDP_13 0x02 +# define DP_EDP_14 0x03 #define DP_EDP_GENERAL_CAP_1 0x701 @@ -430,6 +458,8 @@ #define DP_EDP_GENERAL_CAP_2 0x703 +#define DP_EDP_GENERAL_CAP_3 0x704/* eDP 1.4 */ + #define DP_EDP_DISPLAY_CONTROL_REGISTER 0x720 #define DP_EDP_BACKLIGHT_MODE_SET_REGISTER 0x721 @@ -456,6 +486,9 @@ #define DP_EDP_DBC_MINIMUM_BRIGHTNESS_SET 0x732 #define DP_EDP_DBC_MAXIMUM_BRIGHTNESS_SET 0x733 +#define DP_EDP_REGIONAL_BACKLIGHT_BASE 0x740/* eDP 1.4 */ +#define DP_EDP_REGIONAL_BACKLIGHT_00x741/* eDP 1.4 */ + #define DP_SIDEBAND_MSG_DOWN_REQ_BASE 0x1000 /* 1.2 MST */ #define DP_SIDEBAND_MSG_UP_REP_BASE 0x1200 /* 1.2 MST */ #define DP_SIDEBAND_MSG_DOWN_REP_BASE 0x1400 /* 1.2 MST */ @@ -474,6 +507,7 @@ #define DP_PSR_ERROR_STATUS 0x2006 /* XXX 1.2? */ # define DP_PSR_LINK_CRC_ERROR (1 << 0) # define DP_PSR_RFB_STORAGE_ERROR (1 << 1) +# define DP_PSR_VSC_SDP_UNCORRECTABLE_ERROR (1 << 2) /* eDP 1.4 */ #define DP_PSR_ESI 0x2007 /* XXX 1.2? */ # define DP_PSR_CAPS_CHANGE (1 << 0) @@ -487,6 +521,9 @@ # define DP_PSR_SINK_INTERNAL_ERROR 7 # define DP_PSR_SINK_STATE_MASK 0x07 +#define DP_RECEIVER_ALPM_STATUS0x200b /* eDP 1.4 */ +# define DP_ALPM_LOCK_TIMEOUT_ERROR(1 << 0) + /* DP 1.2 Sideband message defines */ /* peer device type - DP 1.2a Table 2-92 */ #define DP_PEER_DEVICE_NONE 0x0 ___ Intel-gfx mailing list Intel-gfx@li
Re: [Intel-gfx] [PATCH 24/51] drm/i915: Update deferred context creation to do explicit request management
On Fri, Feb 27, 2015 at 12:45:19PM +, John Harrison wrote: > On 25/02/2015 21:15, Daniel Vetter wrote: > >On Wed, Feb 18, 2015 at 03:27:38PM +, John Harrison wrote: > >>On 13/02/2015 12:15, Chris Wilson wrote: > >>>On Fri, Feb 13, 2015 at 11:48:33AM +, john.c.harri...@intel.com wrote: > From: John Harrison > > In execlist mode, context initialisation is deferred until first use of > the > given context. This is because execlist mode has many more contexts than > legacy > mode and many are never actually used. > >>>That's not correct. There are no more contexts in execlists than legacy. > >>>There are more ringbuffers, or rather the contexts have an extra state > >>>object associated with them. > >>Okay, I should have said sub-contexts. Or context state objects. Or > >>something. > >per-engine ctx state? Naming stuff is hard ;-) > > > >Previously, the initialisation commands > were written to the ring and tagged with some random request structure > via the > OLR. This seemed to be causing a null pointer deference bug under certain > circumstances (BZ:40112). > > This patch adds explicit request creation and submission to the deferred > initialisation code path. Thus removing any reliance on or randomness > caused by > the OLR. > >>>This is upside down though. The request should be referencing the > >>>context (thus instantiating it on demand) and nothing in the context > >>>allocation requires the request. The initialisation here should be during > >>>i915_request_switch_context(), since it can be entirely shared with > >>>legacy. > >>>-Chris > >>The request does reference the context - the alloc_reques() function takes a > >>context object as a parameter. Thus it is impossible for the request to be > >>used/supplied/required during context creation. The issue here is the lazy > >>initialisation of the per ring context state which requires sending commands > >>to the ring on first usage of the given context object on the given ring. > >> > >>One problem is that the initialisation request and the batch buffer request > >>cannot be merged at the moment. They both use request->batch_obj for > >>tracking the command object. Thus this patch only works due to the deferred > >>intialisation occurring during the i915_gem_validate_context() call very > >>early on in execbuffer() rather than as part of the context switch within > >>the batch buffer execution which is much later. > >My request struct doesn't have a batch_obj pointer. Where is that from and > >why do we need it? Atm just chasing Chris' comments, haven't read the full > >series yet. > It should do! It was added way back in June 2013 by Mika in 'drm/i915: add > batch bo to i915_add_request()'. So unless someone has removed it again > since I last fetched a tree, you should definitely have it. I must have been blind. Now I've found both the batch_obj and how it's used in the renderstate. And that usage looks wrong since request->batch_obj is used to assign blame to userspace batches for arb_robustness gpu hang stats. The render state init batch is created by the kernel, per definition userspace can't be responsible for hangs in there. Imo we should replace the batch obj argument in i915_gem_render_state_init with NULL. Would this allow you to resolve the inversion Chris brought up? Or is there something else which would prevent us from putting the deferred render ring init into the same request as the first execbuf? > >>I'm not sure what you mean by i915_request_switch_context(). The existing > >>i915_switch_context() does now take just a request structure rather than a > >>ring/ringbuf/context mixture. However, it is not really a good idea to do > >>the context switch automatically as part of creating the request. The > >>request creation and request execution could be quite separated in time, > >>especially with a scheduler. > >> > >>It should be possible to move the deferred initialisation within the context > >>switch if the object tracking can be resolved. Thus they could share the > >>same request and there would not be effectively two separate execution calls > >>at the hardware level. Again, that's potentially work that could be done as > >>a follow up task of improving the context management independent of the > >>current task of removing the OLR. > >I think the biggest risk with adding a separate request for the lrc > >deferred init is in accidentally nesting request when someone moves around > >the lrc validation. Atm it's at the top of execbuf but we tend to shuffle > >things around a lot. > > > >Is there some simple WARN_ON we could smash into the alloc function to > >make sure this never happens? ring->olr would be it, but since we want to > >kill that that's not great. Or do I see risks which aren't really there? > >-Daniel > > There is a WARN_ON that the batch object in the request structure does not > get overwritten. Although, that could only happ
Re: [Intel-gfx] [PATCH 47/51] drm/i915: Update ironlake_enable_rc6() to do explicit request management
On Fri, Feb 27, 2015 at 03:03:22PM +0200, Ville Syrjälä wrote: > On Wed, Feb 25, 2015 at 10:31:13PM +0100, Daniel Vetter wrote: > > On Wed, Feb 18, 2015 at 02:28:16PM +, John Harrison wrote: > > > On 13/02/2015 17:03, Chris Wilson wrote: > > > >On Fri, Feb 13, 2015 at 04:58:24PM +, John Harrison wrote: > > > >>On 13/02/2015 12:19, Chris Wilson wrote: > > > >>>On Fri, Feb 13, 2015 at 11:48:56AM +, john.c.harri...@intel.com > > > >>>wrote: > > > From: John Harrison > > > > > > Updated ironlake_enable_rc6() to do explicit request creation and > > > submission. > > > >>>If you merged the context here with the common context switching code, > > > >>>we don't even need to touch the ring here. > > > >>>-Chris > > > >>> > > > >>It would certainly be preferable to not have any ring commands > > > >>written from deep within the power management code. However, I > > > >>didn't want to change anything I didn't really need to, especially > > > >>in code that I'm not at all sure about. Plus I don't have an > > > >>ironlake to test any significant change on. > > > >I did and tested extensively. > > > >-Chris > > > > > > Do you have a patch that just does the move of this from PM code to > > > context > > > switch code? Something that I can drop into this series would be great. If > > > not, exactly where about in the context switch code should it go? Should > > > it > > > be in the start of day initialisation, in the per context intialisation, > > > every context switch, only the first switch after a resume, ...? > > > > > > Tracing back to where/when this code is currently executed seems to be > > > quite > > > complicated. The _enable_rc6() function is called during ring reset but > > > only > > > for Gen6+ because Ironlake is broken according to the comment. It is also > > > called by a system power management callback but it is unclear when that > > > would occur. Finally, it is also called from the display code in > > > intel_modeset_init_hw(). > > > > ilk rc6 is disabled by default because it crashes machines hard and > > doesn't seem to be all that useful really. Compared to gen6+ rc6 which has > > a massive impact on idle power consumption, more with each generation. > > > > I've also never heard of anyone managing to make this work reliably. We > > could also just rip the entire code out I think, at least I wouldn't be > > surprised if it has bitrot completely by now. > > I was running with it when Ben had those ILK context+rc6 patches flying > around. But I admit that was some time ago. Iirc we've enabled it for a bit with those, it fell to pieces too. And it seems to be rare enough that testing on a developers machine doesn't cut it (tried myself to enable it a few times and had to revert again). -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 47/51] drm/i915: Update ironlake_enable_rc6() to do explicit request management
On Fri, Feb 27, 2015 at 12:49:11PM +, John Harrison wrote: > On 25/02/2015 21:31, Daniel Vetter wrote: > >On Wed, Feb 18, 2015 at 02:28:16PM +, John Harrison wrote: > >>On 13/02/2015 17:03, Chris Wilson wrote: > >>>On Fri, Feb 13, 2015 at 04:58:24PM +, John Harrison wrote: > On 13/02/2015 12:19, Chris Wilson wrote: > >On Fri, Feb 13, 2015 at 11:48:56AM +, john.c.harri...@intel.com > >wrote: > >>From: John Harrison > >> > >>Updated ironlake_enable_rc6() to do explicit request creation and > >>submission. > >If you merged the context here with the common context switching code, > >we don't even need to touch the ring here. > >-Chris > > > It would certainly be preferable to not have any ring commands > written from deep within the power management code. However, I > didn't want to change anything I didn't really need to, especially > in code that I'm not at all sure about. Plus I don't have an > ironlake to test any significant change on. > >>>I did and tested extensively. > >>>-Chris > >>Do you have a patch that just does the move of this from PM code to context > >>switch code? Something that I can drop into this series would be great. If > >>not, exactly where about in the context switch code should it go? Should it > >>be in the start of day initialisation, in the per context intialisation, > >>every context switch, only the first switch after a resume, ...? > >> > >>Tracing back to where/when this code is currently executed seems to be quite > >>complicated. The _enable_rc6() function is called during ring reset but only > >>for Gen6+ because Ironlake is broken according to the comment. It is also > >>called by a system power management callback but it is unclear when that > >>would occur. Finally, it is also called from the display code in > >>intel_modeset_init_hw(). > >ilk rc6 is disabled by default because it crashes machines hard and > >doesn't seem to be all that useful really. Compared to gen6+ rc6 which has > >a massive impact on idle power consumption, more with each generation. > > > >I've also never heard of anyone managing to make this work reliably. We > >could also just rip the entire code out I think, at least I wouldn't be > >surprised if it has bitrot completely by now. > >-Daniel > > So just remove the ironlake_enable_rc6() function completely? Or keep it as > a stub that just says '/* this has never worked so has been removed */'. Just remove it entirely, together with all the other ironlake rc6 stuff plus functions only called by it. All the ironlake_*_rc6 stuff essentially. ironlake_*_drps is the turbo support, that part needs to stay. -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
[Intel-gfx] [PATCH] drm/i915: Tighten obj->map_and_fenceable
For an object right on the boundary of mappable space, as the fenceable size is stricly greater than the actual size, its fence region may extend out of mappable space. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_gem.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c index df27234b5942..aa0d9e2c91f5 100644 --- a/drivers/gpu/drm/i915/i915_gem.c +++ b/drivers/gpu/drm/i915/i915_gem.c @@ -4231,7 +4231,7 @@ i915_gem_object_pin_view(struct drm_i915_gem_object *obj, fenceable = (vma->node.size >= fence_size && (vma->node.start & (fence_alignment - 1)) == 0); - mappable = (vma->node.start + obj->base.size <= + mappable = (vma->node.start + fence_size <= dev_priv->gtt.mappable_end); obj->map_and_fenceable = mappable && fenceable; -- 2.1.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/7] drm/i915: Remove irq-related FIXME in reset code
On Thu, Feb 26, 2015 at 05:11:16PM -0800, Rodrigo Vivi wrote: > I believe this patch is on the wrong series, right? It's in here since I've spotted the FIXME while removing ums crap. > I'm afraid I don't know what was this race neither the two-step reset > to be able to review this comment remove. > Please give me some pointers to check that. Let me explain the history a bit. git blame on the various parts and this fixme should be able to dig out the details (it's a fun story): Originally we've had an unconditional drm_irq_install/unistall in the reset code. Which is not cool since it meant we'd kill all the interrutps that have been going on, so pageflips, vblank waits, crc checksums, gem waits all stopped working. This is the bug the FIXME is about. With fixed most of these issues by no longer disabling/enabling interrupts driver-wide, but only restoring the interrupt bits on the gt (they get lost in the reset). That takes care of all the modeset interrupts. The gem waits have been fixed differently and much earlier with the 2-stage reset code: - before reset we set a flag RESET_IN_PROGRESS and wake up all waiters. - after reset we clear that flag by incrementing the reset counter and again wake all waiters Waiters always check this flag and the reset counter every time they are woken and bail out with -EINTR (to restart the entire ioctl) if that's the case. That means they'll never miss a reset and so won't be affected by interrupts suddenly being cleared. I've simply forgotten to remove the FIXME ;-) Cheers, Daniel > > > On Mon, Feb 23, 2015 at 3:03 AM, Daniel Vetter wrote: > > With the two-step reset counter increments which braket the actual > > reset code and the subsequent wake-up we're guaranteeing that all the > > lockless waiters _will_ be woken up. And since we unconditionally bail > > out of waits with -EAGAIN (or -EIO) in that case there is not risk of > > lost interrupt enabling bits when the lockless wait code races against > > a gpu reset. > > > > Let's remove this FIXME as resolved then. > > > > Signed-off-by: Daniel Vetter > > --- > > drivers/gpu/drm/i915/i915_drv.c | 6 -- > > 1 file changed, 6 deletions(-) > > > > diff --git a/drivers/gpu/drm/i915/i915_drv.c > > b/drivers/gpu/drm/i915/i915_drv.c > > index cc6c51107047..89741e6e2d08 100644 > > --- a/drivers/gpu/drm/i915/i915_drv.c > > +++ b/drivers/gpu/drm/i915/i915_drv.c > > @@ -878,12 +878,6 @@ int i915_reset(struct drm_device *dev) > > } > > > > /* > > -* FIXME: This races pretty badly against concurrent holders of > > -* ring interrupts. This is possible since we've started to drop > > -* dev->struct_mutex in select places when waiting for the gpu. > > -*/ > > - > > - /* > > * rps/rc6 re-init is necessary to restore state lost after the > > * reset and the re-install of gt irqs. Skip for ironlake per > > * previous concerns that it doesn't respond well to some forms > > -- > > 2.1.4 > > > > ___ > > 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 -- 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: Add debugfs entry for DRRS
On Tuesday 24 February 2015 06:09 AM, Daniel Vetter wrote:
On Mon, Feb 23, 2015 at 05:35:54PM +0530, Ramalingam C wrote:
From: Vandana Kannan
Adding a debugfs entry to determine if DRRS is supported or not
V2: [By Ram]: Following details about the active crtc will be filled
in seq-file of the debugfs
1. Encoder output type
2. DRRS Support on this CRTC
3. DRRS current state
4. Current Vrefresh
Format is as follows:
CRTC 1: Output: eDP, DRRS Supported: Yes (Seamless), DRRS_State: DRRS_HIGH_RR,
Vrefresh: 60
CRTC 2: Output: HDMI, DRRS Supported : No, VBT DRRS_type: Seamless
CRTC 1: Output: eDP, DRRS Supported: Yes (Seamless), DRRS_State: DRRS_LOW_RR,
Vrefresh: 40
CRTC 2: Output: HDMI, DRRS Supported : No, VBT DRRS_type: Seamless
V3: [By Ram]: Readability is improved.
Another error case is covered [Daniel]
V4: [By Ram]: Current status of the Idleness DRRS along with
the Front buffer bits are added to the debugfs. [Rodrigo]
V5: [By Ram]: Rephrased to make it easy to understand.
And format is modified. [Rodrigo]
Signed-off-by: Vandana Kannan
Signed-off-by: Ramalingam C
Total absence of locking while walking modesetting structures is a bit
uncool.
---
drivers/gpu/drm/i915/i915_debugfs.c | 113 +++
1 file changed, 113 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 164fa82..e51001c 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2869,6 +2869,118 @@ static int i915_ddb_info(struct seq_file *m, void
*unused)
return 0;
}
+static void drrs_status_per_crtc(struct seq_file *m,
+ struct drm_device *dev, struct intel_crtc *intel_crtc)
+{
+ struct intel_encoder *intel_encoder;
+ struct drm_i915_private *dev_priv = dev->dev_private;
+ struct i915_drrs *drrs = &dev_priv->drrs;
+ int vrefresh = 0;
+ u32 work_status;
+
+ for_each_encoder_on_crtc(dev, &intel_crtc->base, intel_encoder) {
+ /* Encoder connected on this CRTC */
+ switch (intel_encoder->type) {
+ case INTEL_OUTPUT_EDP:
+ seq_puts(m, "eDP:\n");
+ break;
+ case INTEL_OUTPUT_DSI:
+ seq_puts(m, "DSI:\n");
+ break;
+ case INTEL_OUTPUT_HDMI:
+ seq_puts(m, "HDMI:\n");
+ break;
+ case INTEL_OUTPUT_DISPLAYPORT:
+ seq_puts(m, "DP:\n");
+ break;
+ default:
+ seq_printf(m, "Other encoder (id=%d).\n",
+ intel_encoder->type);
+ return;
+ }
+ }
+
+ if (dev_priv->vbt.drrs_type == STATIC_DRRS_SUPPORT)
+ seq_puts(m, "\tVBT: DRRS_type: Static");
+ else if (dev_priv->vbt.drrs_type == SEAMLESS_DRRS_SUPPORT)
+ seq_puts(m, "\tVBT: DRRS_type: Seamless");
+ else if (dev_priv->vbt.drrs_type == DRRS_NOT_SUPPORTED)
+ seq_puts(m, "\tVBT: DRRS_type: None");
+ else
+ seq_puts(m, "\tVBT: DRRS_type: FIXME: Unrecognized Value");
+
+ seq_puts(m, "\n\n");
+
+ if (intel_crtc->config->has_drrs) {
+ struct intel_panel *panel;
+
+ panel = &drrs->dp->attached_connector->panel;
Same here, chasing drrs pointers without grabbing the right locks isn't
awesome either. I've merged all the other patches in this series to dinq.
-Daniel
+ /* DRRS Supported */
+ seq_puts(m, "\tDRRS Supported: Yes\n");
+ seq_printf(m, "\t\tBusy_frontbuffer_bits: 0x%X",
+ drrs->busy_frontbuffer_bits);
+
+ seq_puts(m, "\n\t\t");
+ work_status = work_busy(&drrs->work.work);
+ if (drrs->busy_frontbuffer_bits) {
+ seq_puts(m, "Front buffer: Busy.\n");
+ seq_puts(m, "\t\tIdleness DRRS: Disabled");
+ } else {
+ seq_puts(m, "Front buffer: Idle");
+ seq_puts(m, "\n\t\t");
+ if (drrs->refresh_rate_type == DRRS_HIGH_RR) {
+ if (work_status)
+ seq_puts(m, "Idleness DRRS: Enabled");
+ else
+ seq_puts(m, "Idleness DRRS: Disabled");
+ } else if (drrs->refresh_rate_type == DRRS_LOW_RR) {
+ seq_puts(m, "Idleness DRRS: Enabled");
+ }
+ }
+
+ seq_puts(m, "\n\t\t");
+ if (drrs->refresh_rate_type == DRRS_HIGH_RR) {
+ seq_puts(m, "DRRS_State: DRRS_HIGH_RR\n")
Re: [Intel-gfx] [PATCH 7/7] drm/i915: Remove DRIVER_MODESET checks from modeset code
On Thu, Feb 26, 2015 at 05:17:36PM -0800, Rodrigo Vivi wrote:
> Reviewed-by: Rodrigo Vivi
All merged to dinq, thanks for your review.
-Daniel
>
> On Mon, Feb 23, 2015 at 3:03 AM, Daniel Vetter wrote:
> > Mostly just checks in i915-private modeset ioctls.
> >
> > Signed-off-by: Daniel Vetter
> > ---
> > drivers/gpu/drm/i915/intel_display.c | 3 ---
> > drivers/gpu/drm/i915/intel_opregion.c | 6 ++
> > drivers/gpu/drm/i915/intel_overlay.c | 2 --
> > drivers/gpu/drm/i915/intel_sprite.c | 6 --
> > 4 files changed, 2 insertions(+), 15 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index 3b0fe9f1f3c9..253a201e20dd 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -12372,9 +12372,6 @@ int intel_get_pipe_from_crtc_id(struct drm_device
> > *dev, void *data,
> > struct drm_crtc *drmmode_crtc;
> > struct intel_crtc *crtc;
> >
> > - if (!drm_core_check_feature(dev, DRIVER_MODESET))
> > - return -ENODEV;
> > -
> > drmmode_crtc = drm_crtc_find(dev, pipe_from_crtc_id->crtc_id);
> >
> > if (!drmmode_crtc) {
> > diff --git a/drivers/gpu/drm/i915/intel_opregion.c
> > b/drivers/gpu/drm/i915/intel_opregion.c
> > index d8de1d5140a7..71e87abdcae7 100644
> > --- a/drivers/gpu/drm/i915/intel_opregion.c
> > +++ b/drivers/gpu/drm/i915/intel_opregion.c
> > @@ -744,10 +744,8 @@ void intel_opregion_init(struct drm_device *dev)
> > return;
> >
> > if (opregion->acpi) {
> > - if (drm_core_check_feature(dev, DRIVER_MODESET)) {
> > - intel_didl_outputs(dev);
> > - intel_setup_cadls(dev);
> > - }
> > + intel_didl_outputs(dev);
> > + intel_setup_cadls(dev);
> >
> > /* Notify BIOS we are ready to handle ACPI video ext notifs.
> > * Right now, all the events are handled by the ACPI video
> > module.
> > diff --git a/drivers/gpu/drm/i915/intel_overlay.c
> > b/drivers/gpu/drm/i915/intel_overlay.c
> > index f93dfc174495..823d1d97a000 100644
> > --- a/drivers/gpu/drm/i915/intel_overlay.c
> > +++ b/drivers/gpu/drm/i915/intel_overlay.c
> > @@ -1065,7 +1065,6 @@ int intel_overlay_put_image(struct drm_device *dev,
> > void *data,
> > struct put_image_params *params;
> > int ret;
> >
> > - /* No need to check for DRIVER_MODESET - we don't set it up then. */
> > overlay = dev_priv->overlay;
> > if (!overlay) {
> > DRM_DEBUG("userspace bug: no overlay\n");
> > @@ -1261,7 +1260,6 @@ int intel_overlay_attrs(struct drm_device *dev, void
> > *data,
> > struct overlay_registers __iomem *regs;
> > int ret;
> >
> > - /* No need to check for DRIVER_MODESET - we don't set it up then. */
> > overlay = dev_priv->overlay;
> > if (!overlay) {
> > DRM_DEBUG("userspace bug: no overlay\n");
> > diff --git a/drivers/gpu/drm/i915/intel_sprite.c
> > b/drivers/gpu/drm/i915/intel_sprite.c
> > index f2d408dd7c15..4f8fa0534954 100644
> > --- a/drivers/gpu/drm/i915/intel_sprite.c
> > +++ b/drivers/gpu/drm/i915/intel_sprite.c
> > @@ -1301,9 +1301,6 @@ int intel_sprite_set_colorkey(struct drm_device *dev,
> > void *data,
> > struct intel_plane *intel_plane;
> > int ret = 0;
> >
> > - if (!drm_core_check_feature(dev, DRIVER_MODESET))
> > - return -ENODEV;
> > -
> > /* Make sure we don't try to enable both src & dest simultaneously
> > */
> > if ((set->flags & (I915_SET_COLORKEY_DESTINATION |
> > I915_SET_COLORKEY_SOURCE)) == (I915_SET_COLORKEY_DESTINATION |
> > I915_SET_COLORKEY_SOURCE))
> > return -EINVAL;
> > @@ -1332,9 +1329,6 @@ int intel_sprite_get_colorkey(struct drm_device *dev,
> > void *data,
> > struct intel_plane *intel_plane;
> > int ret = 0;
> >
> > - if (!drm_core_check_feature(dev, DRIVER_MODESET))
> > - return -ENODEV;
> > -
> > drm_modeset_lock_all(dev);
> >
> > plane = drm_plane_find(dev, get->plane_id);
> > --
> > 2.1.4
> >
> > ___
> > 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
--
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 8/8] drm/i915/skl: Allow Y (and Yf) frame buffer creation
On Fri, Feb 27, 2015 at 09:45:27AM +, Tvrtko Ursulin wrote:
>
> On 02/26/2015 04:44 PM, Daniel Vetter wrote:
> >On Wed, Feb 25, 2015 at 04:47:24PM +, Tvrtko Ursulin wrote:
> >>From: Tvrtko Ursulin
> >>
> >>By this patch all underlying bits have been implemented and this
> >>patch actually enables the feature.
> >>
> >>v2: Validate passed in fb modifiers to reject garbage. (Daniel Vetter)
> >>
> >>Signed-off-by: Tvrtko Ursulin
> >>Reviewed-by: Damien Lespiau (v1)
> >>---
> >> drivers/gpu/drm/i915/intel_display.c | 26 +-
> >> 1 file changed, 21 insertions(+), 5 deletions(-)
> >>
> >>diff --git a/drivers/gpu/drm/i915/intel_display.c
> >>b/drivers/gpu/drm/i915/intel_display.c
> >>index 1d50934..3232ddd 100644
> >>--- a/drivers/gpu/drm/i915/intel_display.c
> >>+++ b/drivers/gpu/drm/i915/intel_display.c
> >>@@ -12783,6 +12783,19 @@ static int intel_framebuffer_init(struct
> >>drm_device *dev,
> >>WARN_ON(!mutex_is_locked(&dev->struct_mutex));
> >>
> >>if (mode_cmd->flags & DRM_MODE_FB_MODIFIERS) {
> >>+ /* Passed in modifier sanity checking. */
> >>+ switch (mode_cmd->modifier[0]) {
> >>+ case DRM_FORMAT_MOD_NONE:
> >>+ case I915_FORMAT_MOD_X_TILED:
> >>+ case I915_FORMAT_MOD_Y_TILED:
> >>+ case I915_FORMAT_MOD_Yf_TILED:
> >>+ break;
> >>+ default:
> >>+ DRM_ERROR("Unsupported fb modifier 0x%llx!\n",
> >>+ mode_cmd->modifier[0]);
> >>+ return -EINVAL;
> >>+ }
> >>+
> >>/* Enforce that fb modifier and tiling mode match, but only for
> >> * X-tiled. This is needed for FBC. */
> >>if (!!(obj->tiling_mode == I915_TILING_X) !=
> >>@@ -12790,6 +12803,14 @@ static int intel_framebuffer_init(struct
> >>drm_device *dev,
> >>DRM_DEBUG("tiling_mode doesn't match fb modifier\n");
> >>return -EINVAL;
> >>}
> >>+
> >>+ if (INTEL_INFO(dev)->gen < 9 &&
> >>+ (mode_cmd->modifier[0] == I915_FORMAT_MOD_Y_TILED ||
> >>+mode_cmd->modifier[0] == I915_FORMAT_MOD_Yf_TILED)) {
> >>+ DRM_DEBUG("Unsupported tiling 0x%llx!\n",
> >>+ mode_cmd->modifier[0]);
> >>+ return -EINVAL;
> >>+ }
> >>} else {
> >>if (obj->tiling_mode == I915_TILING_X)
> >>mode_cmd->modifier[0] = I915_FORMAT_MOD_X_TILED;
> >>@@ -12799,11 +12820,6 @@ static int intel_framebuffer_init(struct
> >>drm_device *dev,
> >>}
> >>}
> >>
> >>- if (mode_cmd->modifier[0] == I915_FORMAT_MOD_Y_TILED) {
> >>- DRM_DEBUG("hardware does not support tiling Y\n");
> >>- return -EINVAL;
> >>- }
> >
> >My idea was actually to put the switch here (reduces one indent level) and
> >put the per-gen stuff into the switch statement too. I.e.
> >
> > /* Passed in modifier sanity checking. */
> > switch (mode_cmd->modifier[0]) {
> > case I915_FORMAT_MOD_Y_TILED:
> > case I915_FORMAT_MOD_Yf_TILED:
> > if (INTEL_INFO(dev)->gen < 9) {
> > DRM_DEBUG("Unsupported tiling 0x%llx!\n",
> > mode_cmd->modifier[0]);
> > return -EINVAL;
> >
> > }
> > case DRM_FORMAT_MOD_NONE:
> > case I915_FORMAT_MOD_X_TILED:
> > break;
> > default:
> > DRM_ERROR("Unsupported fb modifier 0x%llx!\n",
> > mode_cmd->modifier[0]);
> > return -EINVAL;
> > }
> >
> >That gives us a natural place for extensions later on if we need to add
> >more special cases.
>
> Yes I agree this patch being only on v2 was way disproportionate compared to
> some others from this series. ;)
Well I've obviously failed to explain properly in my review to v1 to avoid
a v3 ;-)
-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: Check for driver readyness before handling an underrun interrupt
On Fri, Feb 27, 2015 at 09:27:04AM +, Chris Wilson wrote: > On Fri, Feb 27, 2015 at 10:20:05AM +0200, Jani Nikula wrote: > > On Fri, 27 Feb 2015, Jani Nikula wrote: > > > On Thu, 26 Feb 2015, Chris Wilson wrote: > > >> When we takeover from the BIOS and install our interrupt handler, the > > >> BIOS may have left us a few surprises in the form of spontaneous > > >> interrupts. (This is especially likely on hardware like 965gm where > > >> display fifo underruns are continuous and the GMCH cannot filter that > > >> interrupt souce.) As we enable our IRQ early so that we can use it > > >> during hardware probing, our interrupt handler must be prepared to > > >> handle a few sources prior to being fully configured. As such, we need > > >> to add a simple is-ready check prior to dereferencing our KMS state for > > >> reporting underruns. > > >> > > >> Reported-by: Rob Clark > > >> Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1193972 > > > > > > "You are not authorized to access bug #1193972. To see this bug, you > > > must first log in to an account with the appropriate permissions." > > > > > > Meh. > > > > Pushed to drm-intel-fixes, thanks for the patch and review. If someone > > both cares and has access to the bugzilla, please update it. > > Jani, I goofed... > > > >> /* GMCH can't disable fifo underruns, filter them. */ > > >> if (HAS_GMCH_DISPLAY(dev_priv->dev) && > > >> -!__cpu_fifo_underrun_reporting_enabled(dev_priv, pipe)) > > >> +!to_intel_crtc(crtc)->cpu_fifo_underrun_disabled) > > Should be without the '!': > if (HAS_GMCH_DISPLAY(dev_priv->dev) && > to_intel_crtc(crtc)->cpu_fifo_underrun_disabled) Somewhere on my todo is to invert the sense of our underrun reporting. I've screwed this up countless times, but I fear the patch to switch will be buggy as well ;-) /me is chicken Cheers, 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 7/8] drm/i915/skl: Update watermarks for Y tiling
On Fri, Feb 27, 2015 at 09:39:47AM +, Tvrtko Ursulin wrote: > >Hum, does this compile? I'm seeing an extra argument to skl_wm_method2() > >but no update at the calling site? > > Not only that, but it even works! :) (Extra argument is there, you must have > missed it!) Ooops, I see it now: 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 0/6] eDP DRRS based on frontbuffer tracking
On Tuesday 24 February 2015 06:21 AM, Daniel Vetter wrote: On Fri, Feb 13, 2015 at 03:32:58PM +0530, Ramalingam C wrote: This series includes a preparation patch for drrs support across differnt platforms in intel_dp_set_m_n along with last 5 pending patches of V3 eDP DRRS patch series. New series is submitted to make the review more comfortable and to display the dependancy of the patches explicitly. Durgadoss R (1): drm/i915: Enable eDP DRRS for CHV Ramalingam C (1): drm/i915: Add support for DRRS in intel_dp_set_m_n Vandana Kannan (4): drm/i915/bdw: Add support for DRRS to switch RR drm/i915: Support for RR switching on VLV Documentation/drm: DocBook integration for DRRS drm/i915: Add debugfs entry for DRRS Ok I've reviewed the locking for DRRS quickly now that it's all merged and it's deadlock-y: intel_edp_drrs_downclock_work grabs the drrs mutex. But in the disable function we cancel that work and wait for that to complete (cancel_sync) while holding the lock. Which means if the async work is running this will deadlock. The work cancel must be moved out of the critical section, and the work must double-check (after taking the lock) that drrs hasn't been disabled meanwhile (by checking drrs.dp, which we already do). intel_psr.c contains all that logic as an example. While you do that follow-up patch could we extract the drrs code into a new intel_drrs.c file? That would also simplify the kerneldoc includes a bit. Cheers, Daniel Missed the possible deadlock window. I will upload a patch moving the cancellation of the deferred work out of the mutex protection asap. As a heads up, in VPG we have implemented MIPI DRRS and also content based DRRS. MIPI DRRS: We have extended the DRRS to DSI encoder also on android codelines for BYT and CHV. Content based DRRS: We have implemented the interfaces to expose the DRRS capability and and the vrefresh supported to receive the request for the new vrefresh. So based on required FPS for the display content to be rendered userspace, will place a request for the new vrefresh. We have verified the functionality of this implementation on android devices for almost an year now. I will rework on the implementation to adapt to the DRM-intel and submit a RFC to explain the complete design. This RFC will have the generalized DRRS state machine for all encoders like eDP and DSI along with encoder support for DSI and eDP. So as a result we will have the generic code for drrs state machine in intel_drrs.c totally separated from the encoder related code. Can we wait till then? --Ram Documentation/DocBook/drm.tmpl | 11 drivers/gpu/drm/i915/i915_debugfs.c | 99 drivers/gpu/drm/i915/i915_reg.h |1 + drivers/gpu/drm/i915/intel_display.c | 32 ++--- drivers/gpu/drm/i915/intel_dp.c | 121 -- drivers/gpu/drm/i915/intel_drv.h | 22 ++- 6 files changed, 273 insertions(+), 13 deletions(-) -- 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] drm/i915: Redo WMs when cursor size changes
On Thu, Feb 26, 2015 at 05:47:35PM -0800, Matt Roper wrote:
> On Thu, Feb 26, 2015 at 02:48:44PM -0800, Joe Konno wrote:
> > From: Joe Konno
> >
> > In instances where cursor sizes change, as in Chromium Ozone/Freon,
> > watermarks should be recomputed. There should be no hard-coded
> > assumptions about cursor widths. This was corrected originally here:
> >
> > commit 64f962e3e38bf6f40bbd2462f8380dee0369e1bf
> > Author: Chris Wilson
> > Date: Wed Mar 26 12:38:15 2014 +
> >
> > drm/i915: Recompute WM when the cursor size changes
> >
> > However, it seems the recompute logic got lost in refactoring.
> > Re-introduce the relevant WM re-compute code from the original patch.
>
> I don't believe the recompute logic got lost, it just got moved around a
> bit so that it wouldn't happen during our time-sensitive vblank evasion
> while interrupts are disabled. The old_width != intel_crtc->cursor_width
> check that you're re-adding below already happens in
> intel_check_cursor_plane():
>
>finish:
>if (intel_crtc->active) {
>if (intel_crtc->cursor_width != state->base.crtc_w)
>intel_crtc->atomic.update_wm = true;
>
> We just set a flag so that we know whether we'll need to update
> watermarks later or not. Then when we get to the commit phase, in
> intel_begin_crtc_commit(), we do the following before entering vblank
> evasion:
>
> if (intel_crtc->atomic.update_wm)
> intel_update_watermarks(crtc);
>
> Some of the watermark code we have today sleeps, so we can't call it
> under vblank evasion (i.e., during the commit phase while interrupts are
> disabled).
>
> Our high-level atomic workflow (which legacy plane ioctls also flow
> through internally) looks something like this:
>
> - Some userspace ioctl (SetCursor, SetPlane, etc.)
> - intel_check_TYPE_plane()
> - check validity of request, bail if invalid
> - set flags in intel_crtc->atomic for various stuff we will
> need to do before/after vblank evasion (e.g., wm's)
> - intel_begin_crtc_commit()
> - Perform sleepable operations noted in intel_crtc->atomic
> - intel_pipe_update_start (interrupts are now disabled!)
> - intel_commit_TYPE_plane()
> - intel_finish_crtc_commit()
> - intel_pipe_update_end (interrupts are now reenabled)
> - Perform sleepable operations noted in intel_crtc->atomic
>
> So your patch below could result in sleeps happening while vblanks are
> disabled, which is bad (IIRC, most of those sleeps are in the SKL
> codepath right now, but I think there's a workaround-related wait for
> IVB as well).
>
> Our watermark code needs a lot of work to beat it into proper shape for
> atomic and that's what I'm working on at the moment.
Alternative issue is that wm recompute happens before we update all the
legacy state. Tvrkto just stumbled over that for some of his skl watermark
code, he had to switch a few places in the wm code from looking at
plane->fb to look at plane->state->fb.
Similar changes might be needed for the cursor wm code -
cursor_width/height is kinda redundant since universal planes support.
-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 i-g-t] lib/igt_kms.c: igt_require -> igt_require_f("two displays required\n")
On Thu, Feb 26, 2015 at 06:43:43PM -0800, Marc Herbert wrote: > The bare "Test requirement: modes" message is too cryptic, I had to go and > read the source code to understand the missing requirement. > > Signed-off-by: Marc Herbert Nice one, applied. Thanks, Daniel > --- > > If there is a different message that you would like to push yourself > then please don't mind me - I think ANY message would do. > > tests/kms_flip.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/tests/kms_flip.c b/tests/kms_flip.c > index b843478..cae02e9 100644 > --- a/tests/kms_flip.c > +++ b/tests/kms_flip.c > @@ -1544,7 +1544,7 @@ static int run_pair(int duration, int flags) > > /* If we have fewer than 2 connected outputs then we won't have any >* configuration at all. So skip in that case. */ > - igt_require(modes); > + igt_require_f(modes, "At least two displays required\n"); > duration = duration * 1000 / modes; > duration = max(duration, 500); > > -- > 1.9.3 > > ___ > 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: Fixup racy refcounting in plane_force_disable
On Fri, Feb 27, 2015 at 01:03:37PM +0100, Daniel Vetter wrote:
> Originally it was impossible to be dropping the last refcount in this
> function since there was always one around still from the idr. But in
>
> commit 83f45fc360c8e16a330474860ebda872d1384c8c
> Author: Daniel Vetter
> Date: Wed Aug 6 09:10:18 2014 +0200
>
> drm: Don't grab an fb reference for the idr
>
> we've switched to weak references, broke that assumption but forgot to
> fix it up.
>
> Since we still force-disable planes it's only possible to hit this
> when racing multiple rmfb with fbdev restoring or similar evil things.
> As long as userspace is nice it's impossible to hit the BUG_ON.
>
> But the BUG_ON would most likely be hit from fbdev code, which usually
> invovles the console_lock besides all modeset locks. So very likely
> we'd never get the bug reports if this was hit in the wild, hence
> better be safe than sorry and backport.
>
> Spotted by Matt Roper while reviewing other patches.
>
> Cc: sta...@vger.kernel.org
> Cc: Matt Roper
> Signed-off-by: Daniel Vetter
Reviewed-by: Matt Roper
> ---
> drivers/gpu/drm/drm_crtc.c | 13 +
> 1 file changed, 1 insertion(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index cc548ecd3634..897f51beaadd 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -524,17 +524,6 @@ void drm_framebuffer_reference(struct drm_framebuffer
> *fb)
> }
> EXPORT_SYMBOL(drm_framebuffer_reference);
>
> -static void drm_framebuffer_free_bug(struct kref *kref)
> -{
> - BUG();
> -}
> -
> -static void __drm_framebuffer_unreference(struct drm_framebuffer *fb)
> -{
> - DRM_DEBUG("%p: FB ID: %d (%d)\n", fb, fb->base.id,
> atomic_read(&fb->refcount.refcount));
> - kref_put(&fb->refcount, drm_framebuffer_free_bug);
> -}
> -
> /**
> * drm_framebuffer_unregister_private - unregister a private fb from the
> lookup idr
> * @fb: fb to unregister
> @@ -1319,7 +1308,7 @@ void drm_plane_force_disable(struct drm_plane *plane)
> return;
> }
> /* disconnect the plane from the fb and crtc: */
> - __drm_framebuffer_unreference(plane->old_fb);
> + drm_framebuffer_unreference(plane->old_fb);
> plane->old_fb = NULL;
> plane->fb = NULL;
> plane->crtc = NULL;
> --
> 2.1.4
>
--
Matt Roper
Graphics Software Engineer
IoTG Platform Enabling & Development
Intel Corporation
(916) 356-2795
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 7/8] drm/i915/skl: Update watermarks for Y tiling
From: Tvrtko Ursulin
Display watermarks need different programming for different tiling
modes.
Set the relevant flag so this happens during the plane commit and
add relevant data into a structure made available to the watermark
computation code.
v2: Pass in tiling info to sprite plane updates as well.
v3: Rebased for plane handling changes.
v4: Handle fb == NULL when plane is disabled.
v5: Refactored for addfb2 interface.
v6: Refactored for fb modifier changes.
v7: Updated for atomic commit by only updating watermarks when tiling changes.
v8: BSpec watermark calculation updates.
v9: Restrict scope of y_tile_minimum variable. (Damien Lespiau)
v10: Get fb from plane state otherwise we are working on old state.
Signed-off-by: Tvrtko Ursulin
Acked-by: Ander Conselvan de Oliveira
Acked-by: Matt Roper
Reviewed-by: Damien Lespiau (v9)
---
drivers/gpu/drm/i915/intel_display.c | 6
drivers/gpu/drm/i915/intel_drv.h | 1 +
drivers/gpu/drm/i915/intel_pm.c | 55 ++--
drivers/gpu/drm/i915/intel_sprite.c | 6
4 files changed, 59 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 753894d..4056fad 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -12022,6 +12022,12 @@ intel_check_primary_plane(struct drm_plane *plane,
INTEL_FRONTBUFFER_PRIMARY(intel_crtc->pipe);
intel_crtc->atomic.update_fbc = true;
+
+ /* Update watermarks on tiling changes. */
+ if (!plane->state->fb || !state->base.fb ||
+ plane->state->fb->modifier[0] !=
+ state->base.fb->modifier[0])
+ intel_crtc->atomic.update_wm = true;
}
return 0;
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index e21d26c..c6db290 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -501,6 +501,7 @@ struct intel_plane_wm_parameters {
uint8_t bytes_per_pixel;
bool enabled;
bool scaled;
+ u64 tiling;
};
struct intel_plane {
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 0b18e5d..542cf68 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -2617,7 +2617,7 @@ static uint32_t skl_wm_method1(uint32_t pixel_rate,
uint8_t bytes_per_pixel,
static uint32_t skl_wm_method2(uint32_t pixel_rate, uint32_t pipe_htotal,
uint32_t horiz_pixels, uint8_t bytes_per_pixel,
- uint32_t latency)
+ uint64_t tiling, uint32_t latency)
{
uint32_t ret;
uint32_t plane_bytes_per_line, plane_blocks_per_line;
@@ -2627,7 +2627,16 @@ static uint32_t skl_wm_method2(uint32_t pixel_rate,
uint32_t pipe_htotal,
return UINT_MAX;
plane_bytes_per_line = horiz_pixels * bytes_per_pixel;
- plane_blocks_per_line = DIV_ROUND_UP(plane_bytes_per_line, 512);
+
+ if (tiling == I915_FORMAT_MOD_Y_TILED ||
+ tiling == I915_FORMAT_MOD_Yf_TILED) {
+ plane_bytes_per_line *= 4;
+ plane_blocks_per_line = DIV_ROUND_UP(plane_bytes_per_line, 512);
+ plane_blocks_per_line /= 4;
+ } else {
+ plane_blocks_per_line = DIV_ROUND_UP(plane_bytes_per_line, 512);
+ }
+
wm_intermediate_val = latency * pixel_rate;
ret = DIV_ROUND_UP(wm_intermediate_val, pipe_htotal * 1000) *
plane_blocks_per_line;
@@ -2679,6 +2688,7 @@ static void skl_compute_wm_pipe_parameters(struct
drm_crtc *crtc,
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
enum pipe pipe = intel_crtc->pipe;
struct drm_plane *plane;
+ struct drm_framebuffer *fb;
int i = 1; /* Index for sprite planes start */
p->active = intel_crtc_active(crtc);
@@ -2694,6 +2704,14 @@ static void skl_compute_wm_pipe_parameters(struct
drm_crtc *crtc,
crtc->primary->fb->bits_per_pixel / 8;
p->plane[0].horiz_pixels = intel_crtc->config->pipe_src_w;
p->plane[0].vert_pixels = intel_crtc->config->pipe_src_h;
+ p->plane[0].tiling = DRM_FORMAT_MOD_NONE;
+ fb = crtc->primary->state->fb;
+ /*
+* Framebuffer can be NULL on plane disable, but it does not
+* matter for watermarks if we assume no tiling in that case.
+*/
+ if (fb)
+ p->plane[0].tiling = fb->modifier[0];
p->cursor.enabled = true;
p->cursor.bytes_per_pixel = 4;
@@ -2734,23 +2752,34 @@ static bool skl_compute_plane_wm(const struct
drm_i915_private *dev_priv,
p->pipe_htotal,
[Intel-gfx] [PATCH i-g-t] tests/kms_universal_planes: Inline igt_assert(ret == 0) checks
This way the debug output in case of failures is nicer since we dump
the entire test condition.
Also replace one open-coded igt_assert_eq.
Signed-off-by: Daniel Vetter
---
tests/kms_universal_plane.c | 112
1 file changed, 50 insertions(+), 62 deletions(-)
diff --git a/tests/kms_universal_plane.c b/tests/kms_universal_plane.c
index 789874470a4b..077a948773f4 100644
--- a/tests/kms_universal_plane.c
+++ b/tests/kms_universal_plane.c
@@ -125,7 +125,6 @@ functional_test_pipe(data_t *data, enum pipe pipe,
igt_output_t *output)
functional_test_t test = { .data = data };
igt_display_t *display = &data->display;
igt_plane_t *primary, *sprite;
- int ret;
int num_primary = 0, num_cursor = 0;
int i;
@@ -217,10 +216,9 @@ functional_test_pipe(data_t *data, enum pipe pipe,
igt_output_t *output)
igt_display_commit2(display, COMMIT_UNIVERSAL);
/* Step 10: Enable crtc (fb = -1), take CRC (CRC 7) */
- ret = drmModeSetCrtc(data->drm_fd, output->config.crtc->crtc_id, -1,
-0, 0, &output->config.connector->connector_id,
-1, test.mode);
- igt_assert(ret == 0);
+ igt_assert(drmModeSetCrtc(data->drm_fd, output->config.crtc->crtc_id,
-1,
+ 0, 0, &output->config.connector->connector_id,
+ 1, test.mode) == 0);
igt_pipe_crc_collect_crc(test.pipe_crc, &test.crc_7);
/* Step 11: Disable primary plane */
@@ -238,16 +236,15 @@ functional_test_pipe(data_t *data, enum pipe pipe,
igt_output_t *output)
igt_display_commit2(display, COMMIT_LEGACY);
/* Step 14: Universal API, set primary completely offscreen (CRC 9) */
- ret = drmModeSetPlane(data->drm_fd, primary->drm_plane->plane_id,
- output->config.crtc->crtc_id,
- test.blue_fb.fb_id, 0,
- 9000, 9000,
- test.mode->hdisplay,
- test.mode->vdisplay,
- IGT_FIXED(0,0), IGT_FIXED(0,0),
- IGT_FIXED(test.mode->hdisplay,0),
- IGT_FIXED(test.mode->vdisplay,0));
- igt_assert(ret == 0);
+ igt_assert(drmModeSetPlane(data->drm_fd, primary->drm_plane->plane_id,
+ output->config.crtc->crtc_id,
+ test.blue_fb.fb_id, 0,
+ 9000, 9000,
+ test.mode->hdisplay,
+ test.mode->vdisplay,
+ IGT_FIXED(0,0), IGT_FIXED(0,0),
+ IGT_FIXED(test.mode->hdisplay,0),
+ IGT_FIXED(test.mode->vdisplay,0)) == 0);
igt_pipe_crc_collect_crc(test.pipe_crc, &test.crc_9);
/*
@@ -357,7 +354,7 @@ sanity_test_pipe(data_t *data, enum pipe pipe, igt_output_t
*output)
sanity_test_t test = { .data = data };
igt_plane_t *primary;
drmModeModeInfo *mode;
- int i, ret = 0;
+ int i;
igt_skip_on(pipe >= data->display.n_pipes);
@@ -377,54 +374,49 @@ sanity_test_pipe(data_t *data, enum pipe pipe,
igt_output_t *output)
* doesn't cover CRTC (should fail).
*/
igt_plane_set_fb(primary, &test.undersized_fb);
- ret = igt_display_try_commit2(&data->display, COMMIT_UNIVERSAL);
- igt_assert(ret == -EINVAL);
+ igt_assert(igt_display_try_commit2(&data->display, COMMIT_UNIVERSAL) ==
-EINVAL);
/* Same as above, but different plane positioning. */
igt_plane_set_position(primary, 100, 100);
- ret = igt_display_try_commit2(&data->display, COMMIT_UNIVERSAL);
- igt_assert(ret == -EINVAL);
+ igt_assert(igt_display_try_commit2(&data->display, COMMIT_UNIVERSAL) ==
-EINVAL);
igt_plane_set_position(primary, 0, 0);
/* Try to use universal plane API to scale down (should fail) */
- ret = drmModeSetPlane(data->drm_fd, primary->drm_plane->plane_id,
- output->config.crtc->crtc_id,
- test.oversized_fb.fb_id, 0,
- 0, 0,
- mode->hdisplay + 100,
- mode->vdisplay + 100,
- IGT_FIXED(0,0), IGT_FIXED(0,0),
- IGT_FIXED(mode->hdisplay,0),
- IGT_FIXED(mode->vdisplay,0));
- igt_assert(ret == -ERANGE);
+ igt_assert(drmModeSetPlane(data->drm_fd, primary->drm_plane->plane_id,
+ output->config.crtc->crtc_id,
+ test.oversized_fb.fb_id, 0,
+ 0, 0,
+ mode->hdisplay + 100,
+
Re: [Intel-gfx] [PATCH i-g-t] kms_universal_plane: Check for cursor fb leaks
On Thu, Feb 26, 2015 at 07:00:19PM -0800, Matt Roper wrote:
> We've been leaking the framebuffers that get created inside the
> legacy -> universal cursor compatibility layer and nobody noticed. Add
> an i-g-t test to check debugfs and ensure we end up the same number of
> framebuffers we started with after performing cursor operations.
>
> Cc: Chris Wilson
> Signed-off-by: Matt Roper
> ---
> tests/kms_universal_plane.c | 119
>
> 1 file changed, 119 insertions(+)
>
> diff --git a/tests/kms_universal_plane.c b/tests/kms_universal_plane.c
> index 6a05584..7898744 100644
> --- a/tests/kms_universal_plane.c
> +++ b/tests/kms_universal_plane.c
> @@ -532,6 +532,120 @@ pageflip_test_pipe(data_t *data, enum pipe pipe,
> igt_output_t *output)
> }
>
> static void
> +cursor_leak_test_fini(data_t *data,
> + igt_output_t *output,
> + struct igt_fb *bg,
> + struct igt_fb *curs)
> +{
> + int i;
> +
> + igt_remove_fb(data->drm_fd, bg);
> + for (i = 0; i < 10; i++)
> + igt_remove_fb(data->drm_fd, &curs[i]);
> +
> + igt_output_set_pipe(output, PIPE_ANY);
> +}
> +
> +static int
> +i915_gem_fb_count(void)
> +{
> + char buf[1024];
> + FILE *fp;
> + int count = 0;
> +
> + fp = igt_debugfs_fopen("i915_gem_framebuffer", "r");
> + igt_require(fp);
> + while (fgets(buf, sizeof(buf), fp) != NULL)
> + count++;
> + fclose(fp);
> +
> + return count;
> +}
> +
> +static void
> +cursor_leak_test_pipe(data_t *data, enum pipe pipe, igt_output_t *output)
> +{
> + igt_display_t *display = &data->display;
> + igt_plane_t *primary, *cursor;
> + drmModeModeInfo *mode;
> + struct igt_fb background_fb;
> + struct igt_fb cursor_fb[10];
> + int i;
> + int r, g, b;
> + int count1, count2;
> +
> + igt_assert(data->display.has_universal_planes);
> + igt_skip_on(pipe >= display->n_pipes);
> +
> + igt_output_set_pipe(output, pipe);
> + mode = igt_output_get_mode(output);
> +
> + /* Count GEM framebuffers before creating our cursor FB's */
> + count1 = i915_gem_fb_count();
> +
> + /* Black background FB */
> + igt_create_color_fb(data->drm_fd, mode->hdisplay, mode->vdisplay,
> + DRM_FORMAT_XRGB,
> + false,
> + 0.0, 0.0, 0.0,
> + &background_fb);
> +
> + /* Random color cursors */
> + for (i = 0; i < 10; i++) {
> + r = rand() % 0xFF;
> + g = rand() % 0xFF;
> + b = rand() % 0xFF;
> + igt_create_color_fb(data->drm_fd, 64, 64,
> + DRM_FORMAT_ARGB,
> + false,
> + (double)r / 0xFF,
> + (double)g / 0xFF,
> + (double)b / 0xFF,
> + &cursor_fb[i]);
> + }
> +
> + primary = igt_output_get_plane(output, IGT_PLANE_PRIMARY);
> + cursor = igt_output_get_plane(output, IGT_PLANE_CURSOR);
> + if (!primary || !cursor) {
> + cursor_leak_test_fini(data, output, &background_fb, cursor_fb);
> + igt_skip("Primary and/or cursor are unavailable\n");
> + }
> +
> +
> + igt_plane_set_fb(primary, &background_fb);
> + igt_display_commit2(display, COMMIT_LEGACY);
> +
> + igt_plane_set_position(cursor, 100, 100);
> +
> + /*
> + * Exercise both legacy and universal code paths. Note that legacy
> + * handling in the kernel redirects through universal codepaths
> + * internally, so that redirection is where we're most worried about
> + * leaking.
> + */
> + for (i = 0; i < 10; i++) {
> + igt_plane_set_fb(cursor, &cursor_fb[i]);
> + igt_display_commit2(display, COMMIT_UNIVERSAL);
> + }
> + for (i = 0; i < 10; i++) {
> + igt_plane_set_fb(cursor, &cursor_fb[i]);
> + igt_display_commit2(display, COMMIT_LEGACY);
> + }
> +
> + /* Release our framebuffer handles before we take a second count */
> + igt_plane_set_fb(primary, NULL);
> + igt_plane_set_fb(cursor, NULL);
> + igt_display_commit2(display, COMMIT_LEGACY);
> + cursor_leak_test_fini(data, output, &background_fb, cursor_fb);
> +
> + /* We should be back to the same framebuffer count as when we started */
> + count2 = i915_gem_fb_count();
> +
> + igt_assert_f(count1 == count2, "Cursor framebuffer leak detected. "
> + "Initial fb count=%d, final count=%d\n", count1, count2);
igt_assert_cmpint allows you to save some typing next time around. I've
bikeshedded that while applying.
-Daniel
> +}
> +
> +static void
> run_tests_for_pipe(data_t *data, enum pipe pipe)
> {
> igt_output_t *output;
> @@ -550,6 +664,11 @@ run_tests_for_pipe(data_t *data, enum pi
[Intel-gfx] [PATCH i-g-t] lib: add igt_assert_lt
Found one user in gem_wait.c
Signed-off-by: Daniel Vetter
---
lib/igt_core.h | 13 +
tests/gem_wait.c | 2 +-
2 files changed, 14 insertions(+), 1 deletion(-)
diff --git a/lib/igt_core.h b/lib/igt_core.h
index cc73a712bb7b..c2c820d14c9f 100644
--- a/lib/igt_core.h
+++ b/lib/igt_core.h
@@ -382,6 +382,19 @@ void igt_exit(void) __attribute__((noreturn));
#define igt_assert_lte(n1, n2) igt_assert_cmpint(n1, <=, >, n2)
/**
+ * igt_assert_lt:
+ * @n1: first integer
+ * @n2: second integer
+ *
+ * Fails (sub-)test if the second integers is strictly smaller than the first.
+ * Beware that for now this only works on integers.
+ *
+ * Like igt_assert(), but displays the values being compared on failure instead
+ * of simply printing the stringified expression.
+ */
+#define igt_assert_lt(n1, n2) igt_assert_cmpint(n1, <, >=, n2)
+
+/**
* igt_require:
* @expr: condition to test
*
diff --git a/tests/gem_wait.c b/tests/gem_wait.c
index 39d20b01080c..46b381b9419e 100644
--- a/tests/gem_wait.c
+++ b/tests/gem_wait.c
@@ -157,7 +157,7 @@ static void render_timeout(int fd)
iter <<= 1;
} while (!done && iter < 100);
- igt_assert_cmpint(iter, <, >=, 100);
+ igt_assert_lt(iter, 100);
igt_info("%d iters is enough work\n", iter);
gem_quiescent_gpu(fd);
--
2.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5 0/8] Skylake Y tiled scanout
On Fri, Feb 27, 2015 at 11:15:16AM +, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > Starting with Skylake the display engine can scan out Y tiled objects. (Both > legacy Y tiled, and the new Yf format.) > > This series takes the original work by Damien Lespiau and converts it to use > the > new frame buffer modifiers instead of object set/get tiling. Some patches > needed > to be dropped, some added and some refactored. > > Lightly tested with "testdisplay -m -y" and "testdisplay -m --yf". > > v2: Rebased on v2 of "i915 fb modifier support, respun". > > v3: >* Part which allows Y tiled fb creation extracted out and moved to the end > of series. >* Dropped redundant "drm/i915/skl: Allow Y tiling for sprites". >* Also see individual change logs. > > v4: >* New to the series - watermark programming updates per BSpec. >* Addressed review comments in individual patches. > > v5: >* Addressed review comments in individual patches. Merged entire series, thanks. -Daniel > > Damien Lespiau (4): > drm/i915/skl: Allow scanning out Y and Yf fbs > drm/i915/skl: Adjust intel_fb_align_height() for Yb/Yf tiling > drm/i915/skl: Teach pin_and_fence_fb_obj() about Y tiling constraints > drm/i915/skl: Adjust get_plane_config() to support Yb/Yf tiling > > Tvrtko Ursulin (4): > drm/i915/skl: Add new displayable tiling formats > drm/i915/skl: Updated watermark programming > drm/i915/skl: Update watermarks for Y tiling > drm/i915/skl: Allow Y (and Yf) frame buffer creation > > drivers/gpu/drm/i915/intel_display.c | 231 > ++- > drivers/gpu/drm/i915/intel_drv.h | 3 + > drivers/gpu/drm/i915/intel_pm.c | 97 +++ > drivers/gpu/drm/i915/intel_sprite.c | 24 +++- > include/uapi/drm/drm_fourcc.h| 15 +++ > 5 files changed, 283 insertions(+), 87 deletions(-) > > -- > 2.3.0 > > ___ > 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: add i915 specific connector debugfs file for DPCD
Tested-By: PRC QA PRTS (Patch Regression Test System Contact: shuang...@intel.com) Task id: 5824 -Summary- Platform Delta drm-intel-nightly Series Applied PNV 282/282 282/282 ILK -1 308/308 307/308 SNB 326/326 326/326 IVB 379/379 379/379 BYT 294/294 294/294 HSW -2 387/387 385/387 BDW -1 316/316 315/316 -Detailed- Platform Testdrm-intel-nightly Series Applied *ILK igt_drv_suspend_debugfs-reader PASS(1) DMESG_WARN(2) *HSW igt_gem_storedw_loop_blt PASS(1) DMESG_WARN(1)PASS(1) *HSW igt_pm_rpm_debugfs-read PASS(1) DMESG_WARN(2) *BDW igt_gem_gtt_hog PASS(1) DMESG_WARN(1)PASS(1) Note: You need to pay more attention to line start with '*' ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Tighten obj->map_and_fenceable
On Fri, Feb 27, 2015 at 01:58:43PM +, Chris Wilson wrote: > For an object right on the boundary of mappable space, as the fenceable > size is stricly greater than the actual size, its fence region may extend > out of mappable space. > > Signed-off-by: Chris Wilson Do you have a scenario where this could blow up? Given the pot alignment and fence_size constraints these two should still be equivalent. Ack if I do an s/tighten/clarify/ and amend your commit message? -Daniel > --- > drivers/gpu/drm/i915/i915_gem.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c > index df27234b5942..aa0d9e2c91f5 100644 > --- a/drivers/gpu/drm/i915/i915_gem.c > +++ b/drivers/gpu/drm/i915/i915_gem.c > @@ -4231,7 +4231,7 @@ i915_gem_object_pin_view(struct drm_i915_gem_object > *obj, > fenceable = (vma->node.size >= fence_size && >(vma->node.start & (fence_alignment - 1)) == 0); > > - mappable = (vma->node.start + obj->base.size <= > + mappable = (vma->node.start + fence_size <= > dev_priv->gtt.mappable_end); > > obj->map_and_fenceable = mappable && fenceable; > -- > 2.1.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 0/6] eDP DRRS based on frontbuffer tracking
On Fri, Feb 27, 2015 at 07:59:43PM +0530, Ramalingam C wrote: > > On Tuesday 24 February 2015 06:21 AM, Daniel Vetter wrote: > >On Fri, Feb 13, 2015 at 03:32:58PM +0530, Ramalingam C wrote: > >>This series includes a preparation patch for drrs support across differnt > >>platforms in intel_dp_set_m_n along with last 5 pending patches of V3 eDP > >>DRRS patch series. > >> > >>New series is submitted to make the review more comfortable and > >>to display the dependancy of the patches explicitly. > >> > >>Durgadoss R (1): > >> drm/i915: Enable eDP DRRS for CHV > >> > >>Ramalingam C (1): > >> drm/i915: Add support for DRRS in intel_dp_set_m_n > >> > >>Vandana Kannan (4): > >> drm/i915/bdw: Add support for DRRS to switch RR > >> drm/i915: Support for RR switching on VLV > >> Documentation/drm: DocBook integration for DRRS > >> drm/i915: Add debugfs entry for DRRS > >Ok I've reviewed the locking for DRRS quickly now that it's all merged and > >it's deadlock-y: > > > >intel_edp_drrs_downclock_work grabs the drrs mutex. But in the disable > >function we cancel that work and wait for that to complete (cancel_sync) > >while holding the lock. > > > >Which means if the async work is running this will deadlock. The work > >cancel must be moved out of the critical section, and the work must > >double-check (after taking the lock) that drrs hasn't been disabled > >meanwhile (by checking drrs.dp, which we already do). intel_psr.c contains > >all that logic as an example. > > > >While you do that follow-up patch could we extract the drrs code into a > >new intel_drrs.c file? That would also simplify the kerneldoc includes a > >bit. > > > >Cheers, Daniel > Missed the possible deadlock window. I will upload a patch moving the > cancellation of the deferred work out of the mutex protection asap. > > As a heads up, in VPG we have implemented MIPI DRRS and also content based > DRRS. > > MIPI DRRS: > We have extended the DRRS to DSI encoder also on android codelines for BYT > and CHV. > > > Content based DRRS: > We have implemented the interfaces What kind of interface? Imo we should do this by adjusting the frequecy of the mode, with a suitable modeset fastpath. -Daniel > to expose the DRRS capability and and the vrefresh supported > to receive the request for the new vrefresh. > > So based on required FPS for the display content to be rendered userspace, > will place a request for the new vrefresh. > > We have verified the functionality of this implementation on android devices > for almost an year now. > I will rework on the implementation to adapt to the DRM-intel and submit a > RFC to explain the complete design. > > This RFC will have the generalized DRRS state machine for all encoders like > eDP and DSI along with encoder support for DSI and eDP. > So as a result we will have the generic code for drrs state machine in > intel_drrs.c totally separated from the encoder related code. Can we wait > till then? The deadlock fix should land asap. Or do you mean something else? -Daniel > > > --Ram > >> Documentation/DocBook/drm.tmpl | 11 > >> drivers/gpu/drm/i915/i915_debugfs.c | 99 > >> drivers/gpu/drm/i915/i915_reg.h |1 + > >> drivers/gpu/drm/i915/intel_display.c | 32 ++--- > >> drivers/gpu/drm/i915/intel_dp.c | 121 > >> -- > >> drivers/gpu/drm/i915/intel_drv.h | 22 ++- > >> 6 files changed, 273 insertions(+), 13 deletions(-) > >> > >>-- > >>1.7.9.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
[Intel-gfx] [PATCH] drm/i915: Do both mt and gen6 style forcewake reset on ivb probe
commit 05a2fb157e44 ("drm/i915: Consolidate forcewake code")
failed to take into account that we have used to reset both
the gen6 style and the multithreaded style forcewake registers.
This is due to fact that ivb can use either, depending on how the
bios has set up the machine.
Mimic the old semantics before we have determined the correct variety
and reset both before the ecobus probe.
Cc: Chris Wilson
Cc: Huang Ying
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/intel_uncore.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_uncore.c
b/drivers/gpu/drm/i915/intel_uncore.c
index 8879f17..4eb3cb2 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -1082,8 +1082,14 @@ static void intel_uncore_fw_domains_init(struct
drm_device *dev)
/* We need to init first for ECOBUS access and then
* determine later if we want to reinit, in case of MT access is
-* not working
+* not working. In this stage we don't know which flavour this
+* ivb is, so it is better to reset also the gen6 fw registers
+* before the ecobus check.
*/
+
+ __raw_i915_write32(dev_priv, FORCEWAKE, 0);
+ __raw_posting_read(dev_priv, ECOBUS);
+
fw_domain_init(dev_priv, FW_DOMAIN_ID_RENDER,
FORCEWAKE_MT, FORCEWAKE_MT_ACK);
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Redo WMs when cursor size changes
On 02/27/2015 06:53 AM, Daniel Vetter wrote: > On Thu, Feb 26, 2015 at 05:47:35PM -0800, Matt Roper wrote: >> So your patch below could result in sleeps happening while vblanks are >> disabled, which is bad (IIRC, most of those sleeps are in the SKL >> codepath right now, but I think there's a workaround-related wait for >> IVB as well). >> >> Our watermark code needs a lot of work to beat it into proper shape for >> atomic and that's what I'm working on at the moment. > > Alternative issue is that wm recompute happens before we update all the > legacy state. Tvrkto just stumbled over that for some of his skl watermark > code, he had to switch a few places in the wm code from looking at > plane->fb to look at plane->state->fb. > > Similar changes might be needed for the cursor wm code - > cursor_width/height is kinda redundant since universal planes support. Thanks for the insights, Matt and Dan. It's clear to me from Matt's analysis that my patch is a hack at best and nowhere near a proper fix. This patch was submitted in the hopes of fixing a substantial graphical regression. Shall my patch be retooled as a "better" work-around, or will the regression stand until the watermark code is beat into proper shape? ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Redo WMs when cursor size changes
On Fri, Feb 27, 2015 at 08:21:34AM -0800, Joe Konno wrote: > On 02/27/2015 06:53 AM, Daniel Vetter wrote: > > On Thu, Feb 26, 2015 at 05:47:35PM -0800, Matt Roper wrote: > >> So your patch below could result in sleeps happening while vblanks are > >> disabled, which is bad (IIRC, most of those sleeps are in the SKL > >> codepath right now, but I think there's a workaround-related wait for > >> IVB as well). > >> > >> Our watermark code needs a lot of work to beat it into proper shape for > >> atomic and that's what I'm working on at the moment. > > > > Alternative issue is that wm recompute happens before we update all the > > legacy state. Tvrkto just stumbled over that for some of his skl watermark > > code, he had to switch a few places in the wm code from looking at > > plane->fb to look at plane->state->fb. > > > > Similar changes might be needed for the cursor wm code - > > cursor_width/height is kinda redundant since universal planes support. > > Thanks for the insights, Matt and Dan. It's clear to me from Matt's analysis > that my patch is a hack at best and nowhere near a proper fix. > > This patch was submitted in the hopes of fixing a substantial graphical > regression. Shall my patch be retooled as a "better" work-around, or will the > regression stand until the watermark code is beat into proper shape? I have a couple patches already written that I think might solve your problem. I'll extract those from my in-progress tree and post them shortly for you to try. Matt -- Matt Roper Graphics Software Engineer IoTG Platform Enabling & Development Intel Corporation (916) 356-2795 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Tighten obj->map_and_fenceable
On Fri, Feb 27, 2015 at 04:32:26PM +0100, Daniel Vetter wrote: > On Fri, Feb 27, 2015 at 01:58:43PM +, Chris Wilson wrote: > > For an object right on the boundary of mappable space, as the fenceable > > size is stricly greater than the actual size, its fence region may extend > > out of mappable space. > > > > Signed-off-by: Chris Wilson > > Do you have a scenario where this could blow up? Given the pot alignment > and fence_size constraints these two should still be equivalent. It could only concievably impact PNV (the only system where we have non-mappable and fence_size > obj.base.size), and the alignment there is always the fence size as well which would prevent the overlap. > Ack if I do an s/tighten/clarify/ and amend your commit message? Ok. -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: Do both mt and gen6 style forcewake reset on ivb probe
On Fri, Feb 27, 2015 at 06:11:09PM +0200, Mika Kuoppala wrote:
> commit 05a2fb157e44 ("drm/i915: Consolidate forcewake code")
> failed to take into account that we have used to reset both
> the gen6 style and the multithreaded style forcewake registers.
> This is due to fact that ivb can use either, depending on how the
> bios has set up the machine.
>
> Mimic the old semantics before we have determined the correct variety
> and reset both before the ecobus probe.
>
> Cc: Chris Wilson
> Cc: Huang Ying
> Signed-off-by: Mika Kuoppala
Lgtm, do we have a reference for the testing scenario that blew up?
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 0/3] Watermark atomic fixes
I'm in the process of reworking watermarks to play more nicely with atomic
driver design. It sounds like a few people are already running into
watermark-related problems caused by the atomic changes, so I've extracted a
few early patches here that might solve those immediate issues.
Note that the first patch here moves all of the watermark code out of
intel_pm.c and into intel_wm.c. Watermarks are already very complicated and
the move to atomic is just adding to the complexity, so it's probably a good
idea to give them their own file before we start making a lot of other changes.
--
1.8.5.1
Matt Roper (3):
drm/i915: Move watermark handling to intel_wm.c
drm/i915: Kill intel_crtc->cursor_{width,height}
drm/i915: Use plane->state->fb in watermark code
drivers/gpu/drm/i915/Makefile|3 +-
drivers/gpu/drm/i915/i915_debugfs.c |3 +-
drivers/gpu/drm/i915/intel_display.c | 21 +-
drivers/gpu/drm/i915/intel_drv.h |4 +-
drivers/gpu/drm/i915/intel_pm.c | 3450 -
drivers/gpu/drm/i915/intel_wm.c | 3525 ++
6 files changed, 3542 insertions(+), 3464 deletions(-)
create mode 100644 drivers/gpu/drm/i915/intel_wm.c
--
1.8.5.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/3] drm/i915: Kill intel_crtc->cursor_{width, height}
The cursor size fields in intel_crtc just duplicate the data from
cursor->state.crtc_{w,h} so we don't need them any more. Worse, their
use in the watermark code actually introduces a subtle bug since they
don't get updated to mirror the state values until the plane commit
stage, which is *after* we've already used them to calculate new
watermark values. This happens because we had to move watermark updates
slightly earlier (outside vblank evasion) in commit
commit 32b7eeec4d1e861230b09d437e95d76c86ff4a68
Author: Matt Roper
Date: Wed Dec 24 07:59:06 2014 -0800
drm/i915: Refactor work that can sleep out of commit (v7)
Dropping the intel_crtc fields and just using the state values (which
are properly updated by the time watermark updates happen) should solve
the problem.
Aside from the actual removal of the struct fields (which are formatted
in a way that I couldn't figure out how to match in Coccinelle), the
rest of this patch was generated via the following semantic patch:
// Drop assignment
@@
struct intel_crtc *C;
struct drm_plane_state S;
@@
(
- C->cursor_width = S.crtc_w;
|
- C->cursor_height = S.crtc_h;
)
// Replace usage
@@
struct intel_crtc *C;
expression E;
@@
(
- C->cursor_width
+ C->base.cursor->state->crtc_w
|
- C->cursor_height
+ C->base.cursor->state->crtc_h
|
- to_intel_crtc(E)->cursor_width
+ E->cursor->state->crtc_w
|
- to_intel_crtc(E)->cursor_height
+ E->cursor->state->crtc_h
)
Cc: Ville Syrjälä
Cc: Joe Konno
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89346
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/i915_debugfs.c | 3 ++-
drivers/gpu/drm/i915/intel_display.c | 20 +---
drivers/gpu/drm/i915/intel_drv.h | 1 -
drivers/gpu/drm/i915/intel_wm.c | 12 ++--
4 files changed, 17 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 39091e2..788663a 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2677,7 +2677,8 @@ static int i915_display_info(struct seq_file *m, void
*unused)
active = cursor_position(dev, crtc->pipe, &x, &y);
seq_printf(m, "\tcursor visible? %s, position (%d, %d),
size %dx%d, addr 0x%08x, active? %s\n",
yesno(crtc->cursor_base),
- x, y, crtc->cursor_width,
crtc->cursor_height,
+ x, y, crtc->base.cursor->state->crtc_w,
+ crtc->base.cursor->state->crtc_h,
crtc->cursor_addr, yesno(active));
}
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 370c173..4433b13 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -8330,8 +8330,8 @@ static void i845_update_cursor(struct drm_crtc *crtc, u32
base)
uint32_t cntl = 0, size = 0;
if (base) {
- unsigned int width = intel_crtc->cursor_width;
- unsigned int height = intel_crtc->cursor_height;
+ unsigned int width = intel_crtc->base.cursor->state->crtc_w;
+ unsigned int height = intel_crtc->base.cursor->state->crtc_h;
unsigned int stride = roundup_pow_of_two(width) * 4;
switch (stride) {
@@ -8395,7 +8395,7 @@ static void i9xx_update_cursor(struct drm_crtc *crtc, u32
base)
cntl = 0;
if (base) {
cntl = MCURSOR_GAMMA_ENABLE;
- switch (intel_crtc->cursor_width) {
+ switch (intel_crtc->base.cursor->state->crtc_w) {
case 64:
cntl |= CURSOR_MODE_64_ARGB_AX;
break;
@@ -8406,7 +8406,7 @@ static void i9xx_update_cursor(struct drm_crtc *crtc, u32
base)
cntl |= CURSOR_MODE_256_ARGB_AX;
break;
default:
- MISSING_CASE(intel_crtc->cursor_width);
+
MISSING_CASE(intel_crtc->base.cursor->state->crtc_w);
return;
}
cntl |= pipe << 28; /* Connect to correct pipe */
@@ -8453,7 +8453,7 @@ static void intel_crtc_update_cursor(struct drm_crtc
*crtc,
base = 0;
if (x < 0) {
- if (x + intel_crtc->cursor_width <= 0)
+ if (x + intel_crtc->base.cursor->state->crtc_w <= 0)
base = 0;
pos |= CURSOR_POS_SIGN << CURSOR_X_SHIFT;
@@ -8462,7 +8462,7 @@ static void
[Intel-gfx] [PATCH 3/3] drm/i915: Use plane->state->fb in watermark code
plane->fb is a legacy pointer that not always be up-to-date (or updated
early enough). Make sure the watermark code uses plane->state->fb so
that we're always doing our calculations based on the correct
framebuffers.
This patch was generated by Coccinelle with the following semantic
patch:
@@
struct drm_plane *P;
@@
- P->fb
+ P->state->fb
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/intel_wm.c | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_wm.c b/drivers/gpu/drm/i915/intel_wm.c
index dcc6a05..86ad8b4 100644
--- a/drivers/gpu/drm/i915/intel_wm.c
+++ b/drivers/gpu/drm/i915/intel_wm.c
@@ -496,7 +496,7 @@ static void pineview_update_wm(struct drm_crtc *unused_crtc)
crtc = single_enabled_crtc(dev);
if (crtc) {
const struct drm_display_mode *adjusted_mode;
- int pixel_size = crtc->primary->fb->bits_per_pixel / 8;
+ int pixel_size = crtc->primary->state->fb->bits_per_pixel / 8;
int clock;
adjusted_mode =
&to_intel_crtc(crtc)->config->base.adjusted_mode;
@@ -572,7 +572,7 @@ static bool g4x_compute_wm0(struct drm_device *dev,
clock = adjusted_mode->crtc_clock;
htotal = adjusted_mode->crtc_htotal;
hdisplay = to_intel_crtc(crtc)->config->pipe_src_w;
- pixel_size = crtc->primary->fb->bits_per_pixel / 8;
+ pixel_size = crtc->primary->state->fb->bits_per_pixel / 8;
/* Use the small buffer method to calculate plane watermark */
entries = ((clock * pixel_size / 1000) * display_latency_ns) / 1000;
@@ -659,7 +659,7 @@ static bool g4x_compute_srwm(struct drm_device *dev,
clock = adjusted_mode->crtc_clock;
htotal = adjusted_mode->crtc_htotal;
hdisplay = to_intel_crtc(crtc)->config->pipe_src_w;
- pixel_size = crtc->primary->fb->bits_per_pixel / 8;
+ pixel_size = crtc->primary->state->fb->bits_per_pixel / 8;
line_time_us = max(htotal * 1000 / clock, 1);
line_count = (latency_ns / line_time_us + 1000) / 1000;
@@ -742,7 +742,7 @@ static void vlv_update_drain_latency(struct drm_crtc *crtc)
}
/* Primary plane Drain Latency */
- pixel_size = crtc->primary->fb->bits_per_pixel / 8; /* BPP */
+ pixel_size = crtc->primary->state->fb->bits_per_pixel / 8; /* BPP
*/
if (vlv_compute_drain_latency(crtc, pixel_size, &prec_mult,
&drain_latency)) {
plane_prec = (prec_mult == high_precision) ?
DDL_PLANE_PRECISION_HIGH :
@@ -1023,7 +1023,7 @@ static void i965_update_wm(struct drm_crtc *unused_crtc)
int clock = adjusted_mode->crtc_clock;
int htotal = adjusted_mode->crtc_htotal;
int hdisplay = to_intel_crtc(crtc)->config->pipe_src_w;
- int pixel_size = crtc->primary->fb->bits_per_pixel / 8;
+ int pixel_size = crtc->primary->state->fb->bits_per_pixel / 8;
unsigned long line_time_us;
int entries;
@@ -1100,7 +1100,7 @@ static void i9xx_update_wm(struct drm_crtc *unused_crtc)
crtc = intel_get_crtc_for_plane(dev, 0);
if (intel_crtc_active(crtc)) {
const struct drm_display_mode *adjusted_mode;
- int cpp = crtc->primary->fb->bits_per_pixel / 8;
+ int cpp = crtc->primary->state->fb->bits_per_pixel / 8;
if (IS_GEN2(dev))
cpp = 4;
@@ -1122,7 +1122,7 @@ static void i9xx_update_wm(struct drm_crtc *unused_crtc)
crtc = intel_get_crtc_for_plane(dev, 1);
if (intel_crtc_active(crtc)) {
const struct drm_display_mode *adjusted_mode;
- int cpp = crtc->primary->fb->bits_per_pixel / 8;
+ int cpp = crtc->primary->state->fb->bits_per_pixel / 8;
if (IS_GEN2(dev))
cpp = 4;
@@ -1145,7 +1145,7 @@ static void i9xx_update_wm(struct drm_crtc *unused_crtc)
if (IS_I915GM(dev) && enabled) {
struct drm_i915_gem_object *obj;
- obj = intel_fb_obj(enabled->primary->fb);
+ obj = intel_fb_obj(enabled->primary->state->fb);
/* self-refresh seems busted with untiled */
if (obj->tiling_mode == I915_TILING_NONE)
@@ -1169,7 +1169,7 @@ static void i9xx_update_wm(struct drm_crtc *unused_crtc)
int clock = adjusted_mode->crtc_clock;
int htotal = adjusted_mode->crtc_htotal;
int hdisplay = to_intel_crtc(enabled)->config->pipe_src_w;
- int pixel_size = enabled->primary->fb->bits_per_pixel / 8;
+ int pixel_size = enabled->primary->state->fb->bits_per_pixel /
8;
unsigned long line_time_us;
int entries;
@@ -1874,7 +1874,7 @@ static void ilk_compute_wm_parameters(struct drm
Re: [Intel-gfx] Suspend/resume problems on Broadwell
On Fri, 27 Feb 2015 00:07:41 +0100, pho...@quasiparticle.net wrote: > Hi, > > I'm having a few problems with i915 on my Broadwell Thinkpad > (T450s, i7-5600U) with kernel 3.19, apparently suspend/resume related. […] > Also, it seems that running or having run a GL application has some > impact on this. With an instance of glxgears running during > suspend/resume, this doesn't seem to happen. Moreover, running a GL > app seems to fix the problem. Correction: running a GL app during suspend/resume prevents bad things (and the "timed out trying to stop ring" error, apparently). Running GL after resume only partly restores original state, sometimes font rendering is broken for random characters - they just don't display anymore. It also seems that only one font and only one size of that one font is affected. I'm guessing that's a problem in X, perhaps? > Is this known already, or can I somehow help to fix this? > > > Greetings, > Phoebe ___ 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/gen8: The WA BB framework is enabled.
On 25/02/15 17:54, Arun Siluvery wrote:
From: Namrta
This can be used to enable WA BB infrastructure for features like
RC6, SSEU and in between context save/restore etc.
The patch which would need WA BB will have to declare the wa_bb obj
utilizing the function here. Update the WA BB with required commands
and update the address of the WA BB at appropriate place.
Change-Id: I9cc49ae7426560215e7b6a6d10ba411caeb9321b
Signed-off-by: Namrta
Signed-off-by: Arun Siluvery
---
drivers/gpu/drm/i915/intel_lrc.c | 32
1 file changed, 32 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 9c851d8..47473e5 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1337,6 +1337,38 @@ static int gen8_emit_request(struct intel_ringbuffer
*ringbuf,
return 0;
}
+static struct intel_ringbuffer *
+create_wa_bb(struct intel_engine_cs *ring, uint32_t bb_size)
+{
+ struct drm_device *dev = ring->dev;
+ struct intel_ringbuffer *ringbuf;
+ int ret;
+
+ ringbuf = kzalloc(sizeof(*ringbuf), GFP_KERNEL);
+ if (!ringbuf)
+ return NULL;
+
+ ringbuf->ring = ring;
+
+ ringbuf->size = roundup(bb_size, PAGE_SIZE);
+ ringbuf->effective_size = ringbuf->size;
+ ringbuf->head = 0;
+ ringbuf->tail = 0;
+ ringbuf->space = ringbuf->size;
+ ringbuf->last_retired_head = -1;
+
+ ret = intel_alloc_ringbuffer_obj(dev, ringbuf);
+ if (ret) {
+ DRM_DEBUG_DRIVER(
+ "Failed to allocate ringbuf obj for wa_bb%s: %d\n",
+ ring->name, ret);
+ kfree(ringbuf);
+ return NULL;
+ }
+
+ return ringbuf;
+}
+
static int intel_lr_context_render_state_init(struct intel_engine_cs *ring,
struct intel_context *ctx)
{
Maybe add an extra line between the 2 paragraphs in the commit message.
Reviewed-by: Michel Thierry
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Look at staged config when fixing pipe_src_w for LVDS
Tested-By: PRC QA PRTS (Patch Regression Test System Contact: shuang...@intel.com) Task id: 5831 -Summary- Platform Delta drm-intel-nightly Series Applied PNV 282/282 282/282 ILK 308/308 308/308 SNB -1 326/326 325/326 IVB 379/379 379/379 BYT 294/294 294/294 HSW 387/387 387/387 BDW -1 316/316 315/316 -Detailed- Platform Testdrm-intel-nightly Series Applied *SNB igt_kms_pipe_crc_basic_read-crc-pipe-A-frame-sequence PASS(3) DMESG_WARN(1)PASS(1) *BDW igt_gem_gtt_hog PASS(2) DMESG_WARN(1)PASS(1) Note: You need to pay more attention to line start with '*' ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 01/12] drm/i915: Reduce CHV DDL multiplier to 16/8
On 02/10/2015 05:28 AM, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Apparently we must yet halve the DDL drain latency from what we're
> using currently. This little nugget is not in any spec, but came
> down through the grapevine.
>
> This makes the displays a bit more stable. Not quite fully stable but at
> least they don't fall over immediately on driver load.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/i915_reg.h | 1 +
> drivers/gpu/drm/i915/intel_pm.c | 6 +++---
> 2 files changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 4ee1964..d8a0205 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -4166,6 +4166,7 @@ enum skl_disp_power_wells {
> #define DSPFW_PLANEA_WM1_HI_MASK (1<<0)
>
> /* drain latency register values*/
> +#define DRAIN_LATENCY_PRECISION_88
> #define DRAIN_LATENCY_PRECISION_16 16
> #define DRAIN_LATENCY_PRECISION_32 32
> #define DRAIN_LATENCY_PRECISION_64 64
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 3c64810..a70bce4 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -728,8 +728,8 @@ static bool vlv_compute_drain_latency(struct drm_crtc
> *crtc,
>
> entries = DIV_ROUND_UP(clock, 1000) * pixel_size;
> if (IS_CHERRYVIEW(dev))
> - *prec_mult = (entries > 128) ? DRAIN_LATENCY_PRECISION_32 :
> -DRAIN_LATENCY_PRECISION_16;
> + *prec_mult = (entries > 32) ? DRAIN_LATENCY_PRECISION_16 :
> + DRAIN_LATENCY_PRECISION_8;
> else
> *prec_mult = (entries > 128) ? DRAIN_LATENCY_PRECISION_64 :
> DRAIN_LATENCY_PRECISION_32;
> @@ -759,7 +759,7 @@ static void vlv_update_drain_latency(struct drm_crtc
> *crtc)
> enum pipe pipe = intel_crtc->pipe;
> int plane_prec, prec_mult, plane_dl;
> const int high_precision = IS_CHERRYVIEW(dev) ?
> - DRAIN_LATENCY_PRECISION_32 : DRAIN_LATENCY_PRECISION_64;
> + DRAIN_LATENCY_PRECISION_16 : DRAIN_LATENCY_PRECISION_64;
>
> plane_dl = I915_READ(VLV_DDL(pipe)) & ~(DDL_PLANE_PRECISION_HIGH |
> DRAIN_LATENCY_MASK | DDL_CURSOR_PRECISION_HIGH |
>
You're also changing the entries threshold; is that due to the reduced
drain latency precsion also?
Would be good to file a bspec bug on this so we don't lose it.
Reviewed-by: Jesse Barnes
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 02/12] drm/i915: Kill DRAIN_LATENCY_PRECISION_* defines
On 02/10/2015 05:28 AM, ville.syrj...@linux.intel.com wrote: > @@ -957,8 +954,7 @@ static void valleyview_update_sprite_wm(struct drm_plane *plane, > int plane_prec; > int sprite_dl; > int prec_mult; > - const int high_precision = IS_CHERRYVIEW(dev) ? > - DRAIN_LATENCY_PRECISION_32 : DRAIN_LATENCY_PRECISION_64; > + const int high_precision = IS_CHERRYVIEW(dev) ? 16 : 64; > > sprite_dl = I915_READ(VLV_DDL(pipe)) & > ~(DDL_SPRITE_PRECISION_HIGH(sprite) | > (DRAIN_LATENCY_MASK << DDL_SPRITE_SHIFT(sprite))); > This hunk changes things; did it belong in the earlier patch? With that explained: Reviewed-by: Jesse Barnes ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 03/12] drm/i915: Simplify VLV drain latency computation
On 02/10/2015 05:28 AM, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> The current drain lantency computation relies on hardcoded limits to
> determine when the to use the low vs. high precision multiplier.
> Rewrite the code to use a more straightforward approach.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/intel_pm.c | 11 +++
> 1 file changed, 7 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 0f0281a..d6c6c1b 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -727,12 +727,15 @@ static bool vlv_compute_drain_latency(struct drm_crtc
> *crtc,
> return false;
>
> entries = DIV_ROUND_UP(clock, 1000) * pixel_size;
> - if (IS_CHERRYVIEW(dev))
> - *prec_mult = (entries > 32) ? 16 : 8;
> - else
> - *prec_mult = (entries > 128) ? 64 : 32;
> +
> + *prec_mult = IS_CHERRYVIEW(dev) ? 16 : 64;
> *drain_latency = (64 * (*prec_mult) * 4) / entries;
>
> + if (*drain_latency > DRAIN_LATENCY_MASK) {
> + *prec_mult /= 2;
> + *drain_latency = (64 * (*prec_mult) * 4) / entries;
> + }
> +
> if (*drain_latency > DRAIN_LATENCY_MASK)
> *drain_latency = DRAIN_LATENCY_MASK;
>
>
Reviewed-by: Jesse Barnes
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 04/12] drm/i915: Hide VLV DDL precision handling
On 02/10/2015 05:28 AM, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Move the DDL precision handling into vlv_compute_drain_latency() so the > callers don't have to duplicate the same code to deal with it. A little painful due to the addition of the #define changes, but I think it's right, and will actually be easier to fix if wrong anyway due to the removal of duplication. Reviewed-by: Jesse Barnes ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 05/12] drm/i915: Reorganize VLV DDL setup
On 02/10/2015 05:28 AM, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Introduce struct vlv_wm_values to house VLV watermark/drain latency
> values. We start by using it when computing the drain latency values.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/i915_drv.h | 9
> drivers/gpu/drm/i915/intel_pm.c | 46
> +++--
> 2 files changed, 40 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 26ffe8b..5de69a0 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1514,6 +1514,14 @@ struct ilk_wm_values {
> enum intel_ddb_partitioning partitioning;
> };
>
> +struct vlv_wm_values {
> + struct {
> + uint8_t cursor;
> + uint8_t sprite[2];
> + uint8_t primary;
> + } ddl[3];
> +};
> +
> struct skl_ddb_entry {
> uint16_t start, end;/* in number of blocks, 'end' is exclusive */
> };
> @@ -1870,6 +1878,7 @@ struct drm_i915_private {
> union {
> struct ilk_wm_values hw;
> struct skl_wm_values skl_hw;
> + struct vlv_wm_values vlv;
> };
> } wm;
>
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index c4c2317..5515d10 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -711,6 +711,21 @@ static bool g4x_compute_srwm(struct drm_device *dev,
> display, cursor);
> }
>
> +static void vlv_write_wm_values(struct intel_crtc *crtc,
> + const struct vlv_wm_values *wm)
> +{
> + struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> + enum pipe pipe = crtc->pipe;
> +
> + I915_WRITE(VLV_DDL(pipe),
> +(wm->ddl[pipe].cursor << DDL_CURSOR_SHIFT) |
> +(wm->ddl[pipe].sprite[1] << DDL_SPRITE_SHIFT(1)) |
> +(wm->ddl[pipe].sprite[0] << DDL_SPRITE_SHIFT(0)) |
> +(wm->ddl[pipe].primary << DDL_PLANE_SHIFT));
> +
> + dev_priv->wm.vlv = *wm;
> +}
> +
> static uint8_t vlv_compute_drain_latency(struct drm_crtc *crtc,
>int pixel_size)
> {
> @@ -757,20 +772,19 @@ static void vlv_update_drain_latency(struct drm_crtc
> *crtc)
> struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
> int pixel_size;
> enum pipe pipe = intel_crtc->pipe;
> - int plane_dl;
> + struct vlv_wm_values wm = dev_priv->wm.vlv;
>
> - plane_dl = I915_READ(VLV_DDL(pipe)) &
> - ~(((DDL_PRECISION_HIGH | DRAIN_LATENCY_MASK) <<
> DDL_CURSOR_SHIFT) |
> - ((DDL_PRECISION_HIGH | DRAIN_LATENCY_MASK) <<
> DDL_PLANE_SHIFT));
> + wm.ddl[pipe].primary = 0;
> + wm.ddl[pipe].cursor = 0;
>
> if (!intel_crtc_active(crtc)) {
> - I915_WRITE(VLV_DDL(pipe), plane_dl);
> + vlv_write_wm_values(intel_crtc, &wm);
> return;
> }
>
> /* Primary plane Drain Latency */
> pixel_size = crtc->primary->fb->bits_per_pixel / 8; /* BPP */
> - plane_dl = vlv_compute_drain_latency(crtc, pixel_size) <<
> DDL_PLANE_SHIFT;
> + wm.ddl[pipe].primary = vlv_compute_drain_latency(crtc, pixel_size);
>
> /* Cursor Drain Latency
>* BPP is always 4 for cursor
> @@ -779,9 +793,10 @@ static void vlv_update_drain_latency(struct drm_crtc
> *crtc)
>
> /* Program cursor DL only if it is enabled */
> if (intel_crtc->cursor_base)
> - plane_dl |= vlv_compute_drain_latency(crtc, pixel_size) <<
> DDL_CURSOR_SHIFT;
> + wm.ddl[pipe].cursor =
> + vlv_compute_drain_latency(crtc, pixel_size);
>
> - I915_WRITE(VLV_DDL(pipe), plane_dl);
> + vlv_write_wm_values(intel_crtc, &wm);
> }
>
> #define single_plane_enabled(mask) is_power_of_2(mask)
> @@ -939,17 +954,18 @@ static void valleyview_update_sprite_wm(struct
> drm_plane *plane,
> {
> struct drm_device *dev = crtc->dev;
> struct drm_i915_private *dev_priv = dev->dev_private;
> - int pipe = to_intel_plane(plane)->pipe;
> + struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
> + enum pipe pipe = intel_crtc->pipe;
> int sprite = to_intel_plane(plane)->plane;
> - int sprite_dl;
> -
> - sprite_dl = I915_READ(VLV_DDL(pipe)) &
> - ~((DDL_PRECISION_HIGH | DRAIN_LATENCY_MASK) <<
> DDL_SPRITE_SHIFT(sprite));
> + struct vlv_wm_values wm = dev_priv->wm.vlv;
>
> if (enabled)
> - sprite_dl |= vlv_compute_drain_latency(crtc, pixel_size) <<
> DDL_SPRITE_SHIFT(sprite);
> + wm.ddl[pipe].sprite[sprite] =
> + vlv_compute_drain_latency(crtc, pixel_size);
> + else
> + wm.ddl[pipe].sprite[sprite] = 0;
>
> - I915_WRITE(VLV_DDL(pipe), sprite_dl);
> +
Re: [Intel-gfx] Suspend/resume problems on Broadwell
Smells like something is wrong in bdw-land. Can you please retest with latest drm-intel-nightly from http://cgit.freedesktop.org/drm-intel or alternatively 4.0-rc kernels? Starting with 4.0 we're using the execlist cmd submission support, which might help. Thanks, Daniel On Fri, Feb 27, 2015 at 6:27 PM, wrote: > On Fri, 27 Feb 2015 00:07:41 +0100, pho...@quasiparticle.net wrote: >> Hi, >> >> I'm having a few problems with i915 on my Broadwell Thinkpad >> (T450s, i7-5600U) with kernel 3.19, apparently suspend/resume related. > […] >> Also, it seems that running or having run a GL application has some >> impact on this. With an instance of glxgears running during >> suspend/resume, this doesn't seem to happen. Moreover, running a GL >> app seems to fix the problem. > > Correction: running a GL app during suspend/resume prevents bad things > (and the "timed out trying to stop ring" error, apparently). Running GL > after resume only partly restores original state, sometimes font > rendering is broken for random characters - they just don't display > anymore. It also seems that only one font and only one size of that one > font is affected. I'm guessing that's a problem in X, perhaps? > >> Is this known already, or can I somehow help to fix this? >> >> >> Greetings, >> Phoebe > ___ > 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: Tighten obj->map_and_fenceable
On Fri, Feb 27, 2015 at 04:37:29PM +, Chris Wilson wrote: > On Fri, Feb 27, 2015 at 04:32:26PM +0100, Daniel Vetter wrote: > > On Fri, Feb 27, 2015 at 01:58:43PM +, Chris Wilson wrote: > > > For an object right on the boundary of mappable space, as the fenceable > > > size is stricly greater than the actual size, its fence region may extend > > > out of mappable space. > > > > > > Signed-off-by: Chris Wilson > > > > Do you have a scenario where this could blow up? Given the pot alignment > > and fence_size constraints these two should still be equivalent. > > It could only concievably impact PNV (the only system where we have > non-mappable > and fence_size > obj.base.size), and the alignment there is always the > fence size as well which would prevent the overlap. > > > Ack if I do an s/tighten/clarify/ and amend your commit message? > Ok. 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
[Intel-gfx] [PULL] drm-intel-next
Hi Dave, -rc1 is out, time for the first i915 pull request ;-) drm-intel-next-2015-02-14: - use the atomic helpers for plane_upate/disable hooks (Matt Roper) - refactor the initial plane config code (Damien) - ppgtt prep patches for dynamic pagetable alloc (Ben Widawsky, reworked and rebased by a lot of other people) - framebuffer modifier support from Tvrtko Ursulin, drm core code from Rob Clark - piles of workaround patches for skl from Damien and Nick Hoath - vGPU support for xengt on the client side (Yu Zhang) - and the usual smaller things all over Cheers, Daniel The following changes since commit b838cbee0d6f0234406e435032b2304f3d05515d: drm/i915: Remove bogus locking check in the hangcheck code (2015-02-03 17:13:04 +0100) are available in the git repository at: git://anongit.freedesktop.org/drm-intel tags/drm-intel-next-2015-02-14 for you to fetch changes up to d4495cbaa5869d2ce8f4b1c9331d3a19b24eb98b: drm/i915: Update DRIVER_DATE to 20150214 (2015-02-14 00:41:35 +0100) - use the atomic helpers for plane_upate/disable hooks (Matt Roper) - refactor the initial plane config code (Damien) - ppgtt prep patches for dynamic pagetable alloc (Ben Widawsky, reworked and rebased by a lot of other people) - framebuffer modifier support from Tvrtko Ursulin, drm core code from Rob Clark - piles of workaround patches for skl from Damien and Nick Hoath - vGPU support for xengt on the client side (Yu Zhang) - and the usual smaller things all over Andreas Ruprecht (1): drm/i915: Remove references to previously removed UMS config option Ben Widawsky (4): drm/i915/trace: Fix offsets for 64b drm/i915: Rename to GEN8_LEGACY_PDPES drm/i915: Setup less PPGTT on failed page_directory drm/i915/gen8: Un-hardcode number of page directories Damien Lespiau (38): drm/i915/skl: Remove the check enforcing VCS2 to be gen8 only drm/i915/skl: Split the SKL PCI ids by GT drm/i915/skl: Declare that GT3 has a second VCS drm/i915: Put update_state_fb() next to the fb update drm/i915: Use an intermediate variable to avoid repeating ourselves drm/i915: Don't try to reference the fb in get_initial_plane_config() drm/i915: Store the initial framebuffer in initial_plane_config drm/i915: Fix atomic state when reusing the firmware fb drm/i915: Make sure the primary plane is enabled before reading out the fb state drm/i915: Support not having an init clock gating function defined drm/i915/bdw: Implement WaForceContextSaveRestoreNonCoherent drm/i915: Garbage collect orphaned prototypes drm/i915: Make intel_ring_setup_status_page() static drm/i915: Remove intel_dsi_cmd.h drm/i915: Make intel_lr_context_render_state_init() static drm/i915: Make intel_logical_ring_advance_and_submit() static drm/i915: Make intel_dp_check_link_status() static drm/i915: Make intel_dp_unpack_aux() static drm/i915: Make intel_unpin_fb_obj() static drm/i915: Remove the IS_SNB_GT1 define drm/i915: Detect eDRAM with the enabled bit only drm/i915/skl: Also detect eDRAM on SKL drm/i915/skl: Document the WM read latency W/A with its name drm/i915/skl: Provide a gen9 specific init_render_ring() drm/i915/skl: Make the init clock gating function skylake specific drm/i915/skl: Implement WaSetGAPSunitClckGateDisable drm/i915/skl: Document that we implement WaRsClearFWBitsAtReset drm/i915/skl: Introduce a SKL specific init_workarounds() drm/i915/skl: Implement WaDisablePartialResolveInVc drm/i915/skl: Implement WaDisableLSQCROPERFforOCL drm/i915/skl: Implement WaDisableHDCInvalidation drm/i915/skl: Implement WaDisableChickenBitTSGBarrierAckForFFSliceCS drm/i915/skl: Implement WaCcsTlbPrefetchDisable:skl drm/i915/skl: Implement WaBarrierPerformanceFixDisable drm/i915/skl: Implement WaSetDisablePixMaskCammingAndRhwoInCommonSliceChicken drm/i915/skl: Implement WaEnableLbsSlaRetryTimerDecrement drm/i915/skl: Fix always true comparison in a revision id check drm/i915/skl: Use a LRI for WaDisableDgMirrorFixInHalfSliceChicken5 Daniel Vetter (5): drm/i915: Add fb format modifier support drm/i915: Set up fb format modifier for initial plane config drm/i915: Switch intel_fb_align_height to fb format modifiers drm/i915: Use fb format modifiers in skylake_update_primary_plane drm/i915: Update DRIVER_DATE to 20150214 Hoath, Nicholas (6): drm/i915: ring w/a initialisation for gen 9 drm/i915: ring w/a gen 9 revision definitions drm/i915/gen9: Implement WaDisablePartialInstShootdown drm/i915/gen9: Implement WaDisableSDEUnitClockGating drm/i915/gen9: Implement Wa4x4STCOptimizationDisable drm/i915/gen9: Implement WaForceEnabl
Re: [Intel-gfx] [PATCH 01/12] drm/i915: Reduce CHV DDL multiplier to 16/8
On Fri, Feb 27, 2015 at 09:36:58AM -0800, Jesse Barnes wrote:
> On 02/10/2015 05:28 AM, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > Apparently we must yet halve the DDL drain latency from what we're
> > using currently. This little nugget is not in any spec, but came
> > down through the grapevine.
> >
> > This makes the displays a bit more stable. Not quite fully stable but at
> > least they don't fall over immediately on driver load.
> >
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/i915/i915_reg.h | 1 +
> > drivers/gpu/drm/i915/intel_pm.c | 6 +++---
> > 2 files changed, 4 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > b/drivers/gpu/drm/i915/i915_reg.h
> > index 4ee1964..d8a0205 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -4166,6 +4166,7 @@ enum skl_disp_power_wells {
> > #define DSPFW_PLANEA_WM1_HI_MASK (1<<0)
> >
> > /* drain latency register values*/
> > +#define DRAIN_LATENCY_PRECISION_8 8
> > #define DRAIN_LATENCY_PRECISION_16 16
> > #define DRAIN_LATENCY_PRECISION_32 32
> > #define DRAIN_LATENCY_PRECISION_64 64
> > diff --git a/drivers/gpu/drm/i915/intel_pm.c
> > b/drivers/gpu/drm/i915/intel_pm.c
> > index 3c64810..a70bce4 100644
> > --- a/drivers/gpu/drm/i915/intel_pm.c
> > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > @@ -728,8 +728,8 @@ static bool vlv_compute_drain_latency(struct drm_crtc
> > *crtc,
> >
> > entries = DIV_ROUND_UP(clock, 1000) * pixel_size;
> > if (IS_CHERRYVIEW(dev))
> > - *prec_mult = (entries > 128) ? DRAIN_LATENCY_PRECISION_32 :
> > - DRAIN_LATENCY_PRECISION_16;
> > + *prec_mult = (entries > 32) ? DRAIN_LATENCY_PRECISION_16 :
> > + DRAIN_LATENCY_PRECISION_8;
> > else
> > *prec_mult = (entries > 128) ? DRAIN_LATENCY_PRECISION_64 :
> >DRAIN_LATENCY_PRECISION_32;
> > @@ -759,7 +759,7 @@ static void vlv_update_drain_latency(struct drm_crtc
> > *crtc)
> > enum pipe pipe = intel_crtc->pipe;
> > int plane_prec, prec_mult, plane_dl;
> > const int high_precision = IS_CHERRYVIEW(dev) ?
> > - DRAIN_LATENCY_PRECISION_32 : DRAIN_LATENCY_PRECISION_64;
> > + DRAIN_LATENCY_PRECISION_16 : DRAIN_LATENCY_PRECISION_64;
> >
> > plane_dl = I915_READ(VLV_DDL(pipe)) & ~(DDL_PLANE_PRECISION_HIGH |
> >DRAIN_LATENCY_MASK | DDL_CURSOR_PRECISION_HIGH |
> >
>
> You're also changing the entries threshold; is that due to the reduced
> drain latency precsion also?
>
> Would be good to file a bspec bug on this so we don't lose it.
The spec just says we should choose the precision so that we don't exceed
7bits in the final value. So the 128 was just needleslly large and we
were just throwing away a useful bit by choosing to use the smaller precision
factor when we didn't have to. But I'm killing off these constants anyway
in a later patch to make the code less confusing.
>
> Reviewed-by: Jesse Barnes
--
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 06/12] drm/i915: Pass plane to vlv_compute_drain_latency()
On 02/10/2015 05:28 AM, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Now that we have drm_planes for the cursor and primary we can move the
> pixel_size handling into vlv_compute_drain_latency() and just pass the
> appropriate plane to it.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/intel_pm.c | 42
> -
> 1 file changed, 16 insertions(+), 26 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 5515d10..fffcf64 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -727,16 +727,26 @@ static void vlv_write_wm_values(struct intel_crtc *crtc,
> }
>
> static uint8_t vlv_compute_drain_latency(struct drm_crtc *crtc,
> - int pixel_size)
> + struct drm_plane *plane)
> {
> struct drm_device *dev = crtc->dev;
> - int entries, prec_mult, drain_latency;
> - int clock = to_intel_crtc(crtc)->config->base.adjusted_mode.crtc_clock;
> + struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
> + int entries, prec_mult, drain_latency, pixel_size;
> + int clock = intel_crtc->config->base.adjusted_mode.crtc_clock;
> const int high_precision = IS_CHERRYVIEW(dev) ? 16 : 64;
>
> + /*
> + * FIXME the plane might have an fb
> + * but be invisible (eg. due to clipping)
> + */
> + if (!intel_crtc->active || !plane->fb)
> + return 0;
> +
> if (WARN(clock == 0, "Pixel clock is zero!\n"))
> return 0;
>
> + pixel_size = drm_format_plane_cpp(plane->fb->pixel_format, 0);
> +
> if (WARN(pixel_size == 0, "Pixel size is zero!\n"))
> return 0;
>
> @@ -770,31 +780,11 @@ static void vlv_update_drain_latency(struct drm_crtc
> *crtc)
> struct drm_device *dev = crtc->dev;
> struct drm_i915_private *dev_priv = dev->dev_private;
> struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
> - int pixel_size;
> enum pipe pipe = intel_crtc->pipe;
> struct vlv_wm_values wm = dev_priv->wm.vlv;
>
> - wm.ddl[pipe].primary = 0;
> - wm.ddl[pipe].cursor = 0;
> -
> - if (!intel_crtc_active(crtc)) {
> - vlv_write_wm_values(intel_crtc, &wm);
> - return;
> - }
> -
> - /* Primary plane Drain Latency */
> - pixel_size = crtc->primary->fb->bits_per_pixel / 8; /* BPP */
> - wm.ddl[pipe].primary = vlv_compute_drain_latency(crtc, pixel_size);
> -
> - /* Cursor Drain Latency
> - * BPP is always 4 for cursor
> - */
> - pixel_size = 4;
> -
> - /* Program cursor DL only if it is enabled */
> - if (intel_crtc->cursor_base)
> - wm.ddl[pipe].cursor =
> - vlv_compute_drain_latency(crtc, pixel_size);
> + wm.ddl[pipe].primary = vlv_compute_drain_latency(crtc, crtc->primary);
> + wm.ddl[pipe].cursor = vlv_compute_drain_latency(crtc, crtc->cursor);
>
> vlv_write_wm_values(intel_crtc, &wm);
> }
> @@ -961,7 +951,7 @@ static void valleyview_update_sprite_wm(struct drm_plane
> *plane,
>
> if (enabled)
> wm.ddl[pipe].sprite[sprite] =
> - vlv_compute_drain_latency(crtc, pixel_size);
> + vlv_compute_drain_latency(crtc, plane);
> else
> wm.ddl[pipe].sprite[sprite] = 0;
>
>
Nice.
Reviewed-by: Jesse Barnes
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] drm/i915/chv: Determine CHV slice/subslice/EU info
From: Jeff McGee
Total EU was already being detected on CHV, so we just add the
additional info parameters. The detection method is changed to
be more robust in the case of subslice fusing - we don't want
to trust the EU fuse bits corresponding to subslices which are
fused-off.
Signed-off-by: Jeff McGee
---
drivers/gpu/drm/i915/i915_dma.c | 40 ++--
drivers/gpu/drm/i915/i915_reg.h | 2 ++
2 files changed, 36 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 053e178..04e5b55e 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -608,14 +608,42 @@ static void intel_device_info_runtime_init(struct
drm_device *dev)
/* Initialize slice/subslice/EU info */
if (IS_CHERRYVIEW(dev)) {
- u32 fuse, mask_eu;
+ u32 fuse, eu_dis;
fuse = I915_READ(CHV_FUSE_GT);
- mask_eu = fuse & (CHV_FGT_EU_DIS_SS0_R0_MASK |
- CHV_FGT_EU_DIS_SS0_R1_MASK |
- CHV_FGT_EU_DIS_SS1_R0_MASK |
- CHV_FGT_EU_DIS_SS1_R1_MASK);
- info->eu_total = 16 - hweight32(mask_eu);
+
+ info->slice_total = 1;
+
+ if (!(fuse & CHV_FGT_DISABLE_SS0)) {
+ info->subslice_per_slice++;
+ eu_dis = fuse & (CHV_FGT_EU_DIS_SS0_R0_MASK |
+CHV_FGT_EU_DIS_SS0_R1_MASK);
+ info->eu_total += 8 - hweight32(eu_dis);
+ }
+
+ if (!(fuse & CHV_FGT_DISABLE_SS1)) {
+ info->subslice_per_slice++;
+ eu_dis = fuse & (CHV_FGT_EU_DIS_SS1_R0_MASK |
+ CHV_FGT_EU_DIS_SS1_R1_MASK);
+ info->eu_total += 8 - hweight32(eu_dis);
+ }
+
+ info->subslice_total = info->subslice_per_slice;
+ /*
+* CHV expected to always have a uniform distribution of EU
+* across subslices.
+ */
+ info->eu_per_subslice = info->subslice_total ?
+ info->eu_total / info->subslice_total :
+ 0;
+ /*
+* CHV supports subslice power gating on devices with more than
+* one subslice, and supports EU power gating on devices with
+* more than one EU pair per subslice.
+ */
+ info->has_slice_pg = 0;
+ info->has_subslice_pg = (info->subslice_total > 1) ? 1 : 0;
+ info->has_eu_pg = (info->eu_per_subslice > 2) ? 1 : 0;
} else if (IS_SKYLAKE(dev)) {
const int s_max = 3, ss_max = 4, eu_max = 8;
int s, ss;
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 55143cb..a8b205d 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -1522,6 +1522,8 @@ enum skl_disp_power_wells {
/* Fuse readout registers for GT */
#define CHV_FUSE_GT(VLV_DISPLAY_BASE + 0x2168)
+#define CHV_FGT_DISABLE_SS0 10
+#define CHV_FGT_DISABLE_SS1 11
#define CHV_FGT_EU_DIS_SS0_R0_SHIFT 16
#define CHV_FGT_EU_DIS_SS0_R0_MASK (0xf << CHV_FGT_EU_DIS_SS0_R0_SHIFT)
#define CHV_FGT_EU_DIS_SS0_R1_SHIFT 20
--
2.3.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/i915/chv: Add CHV HW status to SSEU status
From: Jeff McGee
Collect the currently enabled counts of slice, subslice, and
execution units using the power gate control ack message
registers specific to Cherryview.
Slice/subslice/EU info and hardware status can now be
determined for CHV, so allow the debugfs SSEU status dump
to proceed for CHV devices.
Signed-off-by: Jeff McGee
---
drivers/gpu/drm/i915/i915_debugfs.c | 31 +--
drivers/gpu/drm/i915/i915_reg.h | 11 +++
2 files changed, 40 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 94b3984..e42e79a 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -4362,7 +4362,7 @@ static int i915_sseu_status(struct seq_file *m, void
*unused)
struct drm_i915_private *dev_priv = dev->dev_private;
unsigned int s_tot = 0, ss_tot = 0, ss_per = 0, eu_tot = 0, eu_per = 0;
- if (INTEL_INFO(dev)->gen < 9)
+ if ((INTEL_INFO(dev)->gen < 8) || IS_BROADWELL(dev))
return -ENODEV;
seq_puts(m, "SSEU Device Info\n");
@@ -4384,7 +4384,34 @@ static int i915_sseu_status(struct seq_file *m, void
*unused)
yesno(INTEL_INFO(dev)->has_eu_pg));
seq_puts(m, "SSEU Device Status\n");
- if (IS_SKYLAKE(dev)) {
+ if (IS_CHERRYVIEW(dev)) {
+ const int ss_max = 2;
+ int ss;
+ u32 sig1[ss_max], sig2[ss_max];
+
+ sig1[0] = I915_READ(CHV_POWER_SS0_SIG1);
+ sig1[1] = I915_READ(CHV_POWER_SS1_SIG1);
+ sig2[0] = I915_READ(CHV_POWER_SS0_SIG2);
+ sig2[1] = I915_READ(CHV_POWER_SS1_SIG2);
+
+ for (ss = 0; ss < ss_max; ss++) {
+ unsigned int eu_cnt;
+
+ if (sig1[ss] & CHV_SS_PG_ENABLE)
+ /* skip disabled subslice */
+ continue;
+
+ s_tot = 1;
+ ss_per++;
+ eu_cnt = ((sig1[ss] & CHV_EU08_PG_ENABLE) ? 0 : 2) +
+((sig1[ss] & CHV_EU19_PG_ENABLE) ? 0 : 2) +
+((sig1[ss] & CHV_EU210_PG_ENABLE) ? 0 : 2) +
+((sig2[ss] & CHV_EU311_PG_ENABLE) ? 0 : 2);
+ eu_tot += eu_cnt;
+ eu_per = max(eu_per, eu_cnt);
+ }
+ ss_tot = ss_per;
+ } else if (IS_SKYLAKE(dev)) {
const int s_max = 3, ss_max = 4;
int s, ss;
u32 s_reg[s_max], eu_reg[2*s_max], eu_mask[2];
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index a8b205d..659aefc 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6227,6 +6227,17 @@ enum skl_disp_power_wells {
#define GEN6_RC6 3
#define GEN6_RC7 4
+#define CHV_POWER_SS0_SIG1 0xa720
+#define CHV_POWER_SS1_SIG1 0xa728
+#define CHV_SS_PG_ENABLE (1<<1)
+#define CHV_EU08_PG_ENABLE (1<<9)
+#define CHV_EU19_PG_ENABLE (1<<17)
+#define CHV_EU210_PG_ENABLE (1<<25)
+
+#define CHV_POWER_SS0_SIG2 0xa724
+#define CHV_POWER_SS1_SIG2 0xa72c
+#define CHV_EU311_PG_ENABLE (1<<1)
+
#define GEN9_SLICE0_PGCTL_ACK 0x804c
#define GEN9_SLICE1_PGCTL_ACK 0x8050
#define GEN9_SLICE2_PGCTL_ACK 0x8054
--
2.3.0
___
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/gen8: The WA BB framework is enabled.
On 27/02/15 17:32, Michel Thierry wrote: On 25/02/15 17:54, Arun Siluvery wrote: From: Namrta This can be used to enable WA BB infrastructure for features like RC6, SSEU and in between context save/restore etc. The patch which would need WA BB will have to declare the wa_bb obj utilizing the function here. Update the WA BB with required commands and update the address of the WA BB at appropriate place. Change-Id: I9cc49ae7426560215e7b6a6d10ba411caeb9321b Signed-off-by: Namrta Signed-off-by: Arun Siluvery --- drivers/gpu/drm/i915/intel_lrc.c | 32 1 file changed, 32 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c index 9c851d8..47473e5 100644 Maybe add an extra line between the 2 paragraphs in the commit message. Reviewed-by: Michel Thierry Also, your next patch moves the function around, it'd be nice to add it in the right place since here, so the diffs are clearer. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 0/2] SSEU detection for CHV
From: Jeff McGee These two patches add detection of available and enabled slice/subslice/EU on CHV following the implementation recently merged for SKL. They have been requested to help CHV users determine their configuration through the debugfs interface. Jeff McGee (2): drm/i915/chv: Determine CHV slice/subslice/EU info drm/i915/chv: Add CHV HW status to SSEU status drivers/gpu/drm/i915/i915_debugfs.c | 31 ++-- drivers/gpu/drm/i915/i915_dma.c | 40 +++-- drivers/gpu/drm/i915/i915_reg.h | 13 3 files changed, 76 insertions(+), 8 deletions(-) -- 2.3.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 07/12] drm/i915: Read out display FIFO size on VLV/CHV
On 02/12/2015 10:59 AM, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> VLV/CHV have similar DSPARB registers as older platforms, just more of
> them due to more planes. Add a bit of code to read out the current FIFO
> split from the registers. Will be useful later when we improve the WM
> calculations.
>
> v2: Add display_mmio_offset to DSPARB
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/i915_reg.h | 5 +++-
> drivers/gpu/drm/i915/intel_pm.c | 55
> +
> 2 files changed, 59 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index b35aaf3..3b48f4b 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -4026,7 +4026,7 @@ enum skl_disp_power_wells {
> #define DPINVGTT_STATUS_MASK 0xff
> #define DPINVGTT_STATUS_MASK_CHV 0xfff
>
> -#define DSPARB 0x70030
> +#define DSPARB (dev_priv->info.display_mmio_offset +
> 0x70030)
> #define DSPARB_CSTART_MASK (0x7f << 7)
> #define DSPARB_CSTART_SHIFT7
> #define DSPARB_BSTART_MASK (0x7f)
> @@ -4034,6 +4034,9 @@ enum skl_disp_power_wells {
> #define DSPARB_BEND_SHIFT 9 /* on 855 */
> #define DSPARB_AEND_SHIFT 0
>
> +#define DSPARB2 (VLV_DISPLAY_BASE + 0x70060) /* vlv/chv
> */
> +#define DSPARB3 (VLV_DISPLAY_BASE + 0x7006c) /* chv */
> +
> /* pnv/gen4/g4x/vlv/chv */
> #define DSPFW1 (dev_priv->info.display_mmio_offset +
> 0x70034)
> #define DSPFW_SR_SHIFT 23
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index fffcf64..e53038e 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -280,6 +280,61 @@ void intel_set_memory_cxsr(struct drm_i915_private
> *dev_priv, bool enable)
> */
> static const int pessimal_latency_ns = 5000;
>
> +#define VLV_FIFO_START(dsparb, dsparb2, lo_shift, hi_shift) \
> + dsparb) >> (lo_shift)) & 0xff) | dsparb2) >> (hi_shift)) & 0x1)
> << 8))
> +
> +static int vlv_get_fifo_size(struct drm_device *dev,
> + enum pipe pipe, int plane)
> +{
> + struct drm_i915_private *dev_priv = dev->dev_private;
> + int sprite0_start, sprite1_start, size;
> +
> + switch (pipe) {
> + uint32_t dsparb, dsparb2, dsparb3;
> + case PIPE_A:
> + dsparb = I915_READ(DSPARB);
> + dsparb2 = I915_READ(DSPARB2);
> + sprite0_start = VLV_FIFO_START(dsparb, dsparb2, 0, 0);
> + sprite1_start = VLV_FIFO_START(dsparb, dsparb2, 8, 4);
> + break;
> + case PIPE_B:
> + dsparb = I915_READ(DSPARB);
> + dsparb2 = I915_READ(DSPARB2);
> + sprite0_start = VLV_FIFO_START(dsparb, dsparb2, 16, 8);
> + sprite1_start = VLV_FIFO_START(dsparb, dsparb2, 24, 12);
> + break;
> + case PIPE_C:
> + dsparb2 = I915_READ(DSPARB2);
> + dsparb3 = I915_READ(DSPARB3);
> + sprite0_start = VLV_FIFO_START(dsparb3, dsparb2, 0, 16);
> + sprite1_start = VLV_FIFO_START(dsparb3, dsparb2, 8, 20);
> + break;
> + default:
> + return 0;
> + }
> +
> + switch (plane) {
> + case 0:
> + size = sprite0_start;
> + break;
> + case 1:
> + size = sprite1_start - sprite0_start;
> + break;
> + case 2:
> + size = 512 - 1 - sprite1_start;
> + break;
> + default:
> + return 0;
> + }
> +
> + DRM_DEBUG_KMS("Pipe %c %s %c FIFO size: %d\n",
> + pipe_name(pipe), plane == 0 ? "primary" : "sprite",
> + plane == 0 ? plane_name(pipe) : sprite_name(pipe, plane -
> 1),
> + size);
> +
> + return size;
> +}
> +
> static int i9xx_get_fifo_size(struct drm_device *dev, int plane)
> {
> struct drm_i915_private *dev_priv = dev->dev_private;
>
Reviewed-by: Jesse Barnes
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 02/12] drm/i915: Kill DRAIN_LATENCY_PRECISION_* defines
On Fri, Feb 27, 2015 at 09:38:10AM -0800, Jesse Barnes wrote: > On 02/10/2015 05:28 AM, ville.syrj...@linux.intel.com wrote: > > @@ -957,8 +954,7 @@ static void valleyview_update_sprite_wm(struct > drm_plane *plane, > > int plane_prec; > > int sprite_dl; > > int prec_mult; > > - const int high_precision = IS_CHERRYVIEW(dev) ? > > - DRAIN_LATENCY_PRECISION_32 : DRAIN_LATENCY_PRECISION_64; > > + const int high_precision = IS_CHERRYVIEW(dev) ? 16 : 64; > > > > sprite_dl = I915_READ(VLV_DDL(pipe)) & > > ~(DDL_SPRITE_PRECISION_HIGH(sprite) | > > (DRAIN_LATENCY_MASK << DDL_SPRITE_SHIFT(sprite))); > > > > This hunk changes things; did it belong in the earlier patch? Yeah that should have been part of patch 1 already. I'll respin. > > With that explained: > Reviewed-by: Jesse Barnes -- 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 06/12] drm/i915: Pass plane to vlv_compute_drain_latency()
On Fri, Feb 27, 2015 at 09:57:20AM -0800, Jesse Barnes wrote:
> On 02/10/2015 05:28 AM, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > Now that we have drm_planes for the cursor and primary we can move the
> > pixel_size handling into vlv_compute_drain_latency() and just pass the
> > appropriate plane to it.
> >
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/i915/intel_pm.c | 42
> > -
> > 1 file changed, 16 insertions(+), 26 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_pm.c
> > b/drivers/gpu/drm/i915/intel_pm.c
> > index 5515d10..fffcf64 100644
> > --- a/drivers/gpu/drm/i915/intel_pm.c
> > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > @@ -727,16 +727,26 @@ static void vlv_write_wm_values(struct intel_crtc
> > *crtc,
> > }
> >
> > static uint8_t vlv_compute_drain_latency(struct drm_crtc *crtc,
> > -int pixel_size)
> > +struct drm_plane *plane)
> > {
> > struct drm_device *dev = crtc->dev;
> > - int entries, prec_mult, drain_latency;
> > - int clock = to_intel_crtc(crtc)->config->base.adjusted_mode.crtc_clock;
> > + struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
> > + int entries, prec_mult, drain_latency, pixel_size;
> > + int clock = intel_crtc->config->base.adjusted_mode.crtc_clock;
> > const int high_precision = IS_CHERRYVIEW(dev) ? 16 : 64;
> >
> > + /*
> > +* FIXME the plane might have an fb
> > +* but be invisible (eg. due to clipping)
> > +*/
> > + if (!intel_crtc->active || !plane->fb)
> > + return 0;
> > +
> > if (WARN(clock == 0, "Pixel clock is zero!\n"))
> > return 0;
> >
> > + pixel_size = drm_format_plane_cpp(plane->fb->pixel_format, 0);
> > +
> > if (WARN(pixel_size == 0, "Pixel size is zero!\n"))
> > return 0;
> >
> > @@ -770,31 +780,11 @@ static void vlv_update_drain_latency(struct drm_crtc
> > *crtc)
> > struct drm_device *dev = crtc->dev;
> > struct drm_i915_private *dev_priv = dev->dev_private;
> > struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
> > - int pixel_size;
> > enum pipe pipe = intel_crtc->pipe;
> > struct vlv_wm_values wm = dev_priv->wm.vlv;
> >
> > - wm.ddl[pipe].primary = 0;
> > - wm.ddl[pipe].cursor = 0;
> > -
> > - if (!intel_crtc_active(crtc)) {
> > - vlv_write_wm_values(intel_crtc, &wm);
> > - return;
> > - }
> > -
> > - /* Primary plane Drain Latency */
> > - pixel_size = crtc->primary->fb->bits_per_pixel / 8; /* BPP */
> > - wm.ddl[pipe].primary = vlv_compute_drain_latency(crtc, pixel_size);
> > -
> > - /* Cursor Drain Latency
> > -* BPP is always 4 for cursor
> > -*/
> > - pixel_size = 4;
> > -
> > - /* Program cursor DL only if it is enabled */
> > - if (intel_crtc->cursor_base)
> > - wm.ddl[pipe].cursor =
> > - vlv_compute_drain_latency(crtc, pixel_size);
> > + wm.ddl[pipe].primary = vlv_compute_drain_latency(crtc, crtc->primary);
> > + wm.ddl[pipe].cursor = vlv_compute_drain_latency(crtc, crtc->cursor);
> >
> > vlv_write_wm_values(intel_crtc, &wm);
> > }
> > @@ -961,7 +951,7 @@ static void valleyview_update_sprite_wm(struct
> > drm_plane *plane,
> >
> > if (enabled)
> > wm.ddl[pipe].sprite[sprite] =
> > - vlv_compute_drain_latency(crtc, pixel_size);
> > + vlv_compute_drain_latency(crtc, plane);
> > else
> > wm.ddl[pipe].sprite[sprite] = 0;
> >
> >
>
> Nice.
Actually this is going to have issues now that atomic is partially in.
We'd need to look at plane->state->fb now, but that steps on the same
turf as Matt's latest patches.
>
> Reviewed-by: Jesse Barnes
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/3] drm/i915: Kill intel_crtc->cursor_{width, height} (v2)
The cursor size fields in intel_crtc just duplicate the data from
cursor->state.crtc_{w,h} so we don't need them any more. Worse, their
use in the watermark code actually introduces a subtle bug since they
don't get updated to mirror the state values until the plane commit
stage, which is *after* we've already used them to calculate new
watermark values. This happens because we had to move watermark updates
slightly earlier (outside vblank evasion) in commit
commit 32b7eeec4d1e861230b09d437e95d76c86ff4a68
Author: Matt Roper
Date: Wed Dec 24 07:59:06 2014 -0800
drm/i915: Refactor work that can sleep out of commit (v7)
Dropping the intel_crtc fields and just using the state values (which
are properly updated by the time watermark updates happen) should solve
the problem.
Aside from the actual removal of the struct fields (which are formatted
in a way that I couldn't figure out how to match in Coccinelle), the
rest of this patch was generated via the following semantic patch:
// Drop assignment
@@
struct intel_crtc *C;
struct drm_plane_state S;
@@
(
- C->cursor_width = S.crtc_w;
|
- C->cursor_height = S.crtc_h;
)
// Replace usage
@@
struct intel_crtc *C;
expression E;
@@
(
- C->cursor_width
+ C->base.cursor->state->crtc_w
|
- C->cursor_height
+ C->base.cursor->state->crtc_h
|
- to_intel_crtc(E)->cursor_width
+ E->cursor->state->crtc_w
|
- to_intel_crtc(E)->cursor_height
+ E->cursor->state->crtc_h
)
v2: Rebase
Cc: Ville Syrjälä
Cc: Joe Konno
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89346
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/i915_debugfs.c | 3 ++-
drivers/gpu/drm/i915/intel_display.c | 20 +---
drivers/gpu/drm/i915/intel_drv.h | 1 -
drivers/gpu/drm/i915/intel_wm.c | 12 ++--
4 files changed, 17 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 94b3984..e4d5f41 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2677,7 +2677,8 @@ static int i915_display_info(struct seq_file *m, void
*unused)
active = cursor_position(dev, crtc->pipe, &x, &y);
seq_printf(m, "\tcursor visible? %s, position (%d, %d),
size %dx%d, addr 0x%08x, active? %s\n",
yesno(crtc->cursor_base),
- x, y, crtc->cursor_width,
crtc->cursor_height,
+ x, y, crtc->base.cursor->state->crtc_w,
+ crtc->base.cursor->state->crtc_h,
crtc->cursor_addr, yesno(active));
}
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 5a02f8c9..91ae012 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -8409,8 +8409,8 @@ static void i845_update_cursor(struct drm_crtc *crtc, u32
base)
uint32_t cntl = 0, size = 0;
if (base) {
- unsigned int width = intel_crtc->cursor_width;
- unsigned int height = intel_crtc->cursor_height;
+ unsigned int width = intel_crtc->base.cursor->state->crtc_w;
+ unsigned int height = intel_crtc->base.cursor->state->crtc_h;
unsigned int stride = roundup_pow_of_two(width) * 4;
switch (stride) {
@@ -8474,7 +8474,7 @@ static void i9xx_update_cursor(struct drm_crtc *crtc, u32
base)
cntl = 0;
if (base) {
cntl = MCURSOR_GAMMA_ENABLE;
- switch (intel_crtc->cursor_width) {
+ switch (intel_crtc->base.cursor->state->crtc_w) {
case 64:
cntl |= CURSOR_MODE_64_ARGB_AX;
break;
@@ -8485,7 +8485,7 @@ static void i9xx_update_cursor(struct drm_crtc *crtc, u32
base)
cntl |= CURSOR_MODE_256_ARGB_AX;
break;
default:
- MISSING_CASE(intel_crtc->cursor_width);
+
MISSING_CASE(intel_crtc->base.cursor->state->crtc_w);
return;
}
cntl |= pipe << 28; /* Connect to correct pipe */
@@ -8532,7 +8532,7 @@ static void intel_crtc_update_cursor(struct drm_crtc
*crtc,
base = 0;
if (x < 0) {
- if (x + intel_crtc->cursor_width <= 0)
+ if (x + intel_crtc->base.cursor->state->crtc_w <= 0)
base = 0;
pos |= CURSOR_POS_SIGN << CURSOR_X_SHIFT;
@@ -8541,7 +8541,7 @@
[Intel-gfx] [PATCH 3/3] drm/i915: Use plane->state->fb in watermark code (v2)
plane->fb is a legacy pointer that not always be up-to-date (or updated
early enough). Make sure the watermark code uses plane->state->fb so
that we're always doing our calculations based on the correct
framebuffers.
This patch was generated by Coccinelle with the following semantic
patch:
@@
struct drm_plane *P;
@@
- P->fb
+ P->state->fb
v2: Rebase
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/intel_wm.c | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_wm.c b/drivers/gpu/drm/i915/intel_wm.c
index 47a5175..e877e02 100644
--- a/drivers/gpu/drm/i915/intel_wm.c
+++ b/drivers/gpu/drm/i915/intel_wm.c
@@ -496,7 +496,7 @@ static void pineview_update_wm(struct drm_crtc *unused_crtc)
crtc = single_enabled_crtc(dev);
if (crtc) {
const struct drm_display_mode *adjusted_mode;
- int pixel_size = crtc->primary->fb->bits_per_pixel / 8;
+ int pixel_size = crtc->primary->state->fb->bits_per_pixel / 8;
int clock;
adjusted_mode =
&to_intel_crtc(crtc)->config->base.adjusted_mode;
@@ -572,7 +572,7 @@ static bool g4x_compute_wm0(struct drm_device *dev,
clock = adjusted_mode->crtc_clock;
htotal = adjusted_mode->crtc_htotal;
hdisplay = to_intel_crtc(crtc)->config->pipe_src_w;
- pixel_size = crtc->primary->fb->bits_per_pixel / 8;
+ pixel_size = crtc->primary->state->fb->bits_per_pixel / 8;
/* Use the small buffer method to calculate plane watermark */
entries = ((clock * pixel_size / 1000) * display_latency_ns) / 1000;
@@ -659,7 +659,7 @@ static bool g4x_compute_srwm(struct drm_device *dev,
clock = adjusted_mode->crtc_clock;
htotal = adjusted_mode->crtc_htotal;
hdisplay = to_intel_crtc(crtc)->config->pipe_src_w;
- pixel_size = crtc->primary->fb->bits_per_pixel / 8;
+ pixel_size = crtc->primary->state->fb->bits_per_pixel / 8;
line_time_us = max(htotal * 1000 / clock, 1);
line_count = (latency_ns / line_time_us + 1000) / 1000;
@@ -742,7 +742,7 @@ static void vlv_update_drain_latency(struct drm_crtc *crtc)
}
/* Primary plane Drain Latency */
- pixel_size = crtc->primary->fb->bits_per_pixel / 8; /* BPP */
+ pixel_size = crtc->primary->state->fb->bits_per_pixel / 8; /* BPP
*/
if (vlv_compute_drain_latency(crtc, pixel_size, &prec_mult,
&drain_latency)) {
plane_prec = (prec_mult == high_precision) ?
DDL_PLANE_PRECISION_HIGH :
@@ -1023,7 +1023,7 @@ static void i965_update_wm(struct drm_crtc *unused_crtc)
int clock = adjusted_mode->crtc_clock;
int htotal = adjusted_mode->crtc_htotal;
int hdisplay = to_intel_crtc(crtc)->config->pipe_src_w;
- int pixel_size = crtc->primary->fb->bits_per_pixel / 8;
+ int pixel_size = crtc->primary->state->fb->bits_per_pixel / 8;
unsigned long line_time_us;
int entries;
@@ -1100,7 +1100,7 @@ static void i9xx_update_wm(struct drm_crtc *unused_crtc)
crtc = intel_get_crtc_for_plane(dev, 0);
if (intel_crtc_active(crtc)) {
const struct drm_display_mode *adjusted_mode;
- int cpp = crtc->primary->fb->bits_per_pixel / 8;
+ int cpp = crtc->primary->state->fb->bits_per_pixel / 8;
if (IS_GEN2(dev))
cpp = 4;
@@ -1122,7 +1122,7 @@ static void i9xx_update_wm(struct drm_crtc *unused_crtc)
crtc = intel_get_crtc_for_plane(dev, 1);
if (intel_crtc_active(crtc)) {
const struct drm_display_mode *adjusted_mode;
- int cpp = crtc->primary->fb->bits_per_pixel / 8;
+ int cpp = crtc->primary->state->fb->bits_per_pixel / 8;
if (IS_GEN2(dev))
cpp = 4;
@@ -1145,7 +1145,7 @@ static void i9xx_update_wm(struct drm_crtc *unused_crtc)
if (IS_I915GM(dev) && enabled) {
struct drm_i915_gem_object *obj;
- obj = intel_fb_obj(enabled->primary->fb);
+ obj = intel_fb_obj(enabled->primary->state->fb);
/* self-refresh seems busted with untiled */
if (obj->tiling_mode == I915_TILING_NONE)
@@ -1169,7 +1169,7 @@ static void i9xx_update_wm(struct drm_crtc *unused_crtc)
int clock = adjusted_mode->crtc_clock;
int htotal = adjusted_mode->crtc_htotal;
int hdisplay = to_intel_crtc(enabled)->config->pipe_src_w;
- int pixel_size = enabled->primary->fb->bits_per_pixel / 8;
+ int pixel_size = enabled->primary->state->fb->bits_per_pixel /
8;
unsigned long line_time_us;
int entries;
@@ -1874,7 +1874,7 @@ static void ilk_compute_wm_parameter
[Intel-gfx] [PATCH 0/3] Watermark atomic fixes (v2)
I'm in the process of reworking watermarks to play more nicely with atomic
driver design. It sounds like a few people are already running into
watermark-related problems caused by the atomic changes, so I've extracted a
few early patches here that might solve those immediate issues.
Note that the first patch here moves all of the watermark code out of
intel_pm.c and into intel_wm.c. Watermarks are already very complicated and
the move to atomic is just adding to the complexity, so it's probably a good
idea to give them their own file before we start making a lot of other changes.
v2: Rebased against latest di-nightly. A few watermark changes had landed
since I last rebased my watermark branch, so the original patch series no
longer applied cleanly.
Matt Roper (3):
drm/i915: Move watermark handling to intel_wm.c (v2)
drm/i915: Kill intel_crtc->cursor_{width,height} (v2)
drm/i915: Use plane->state->fb in watermark code (v2)
drivers/gpu/drm/i915/Makefile|3 +-
drivers/gpu/drm/i915/i915_debugfs.c |3 +-
drivers/gpu/drm/i915/intel_display.c | 21 +-
drivers/gpu/drm/i915/intel_drv.h |4 +-
drivers/gpu/drm/i915/intel_pm.c | 3499 -
drivers/gpu/drm/i915/intel_wm.c | 3588 ++
6 files changed, 3605 insertions(+), 3513 deletions(-)
create mode 100644 drivers/gpu/drm/i915/intel_wm.c
--
1.8.5.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] Updated drm-intel-testing
Hi all, New -testing cycle with cool stuff: - Y tiling support for scanout from Tvrtko&Damien - Remove more UMS support - some small prep patches for OLR removal from John Harrison - first few patches for dynamic pagetable allocation from Ben Widawsky, rebased by tons of other people - DRRS support patches (Sonika&Vandana) - fbc patches from Paulo - make sure our vblank callbacks aren't called when the pipes are off - various patches all over Happy testing! Cheers, 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/3] drm/i915: Move watermark handling to intel_wm.c
On Fri, Feb 27, 2015 at 08:54:19AM -0800, Matt Roper wrote:
> Move watermark handling from intel_pm.c to intel_wm.c and add a little
> bit of kerneldoc to exported functions. We also add a new
> intel_init_wm() function to setup memory timing information and
> initialize the relevant watermark vfuncs.
How about delaying gratious code movement until a bunch of the in flight
WM stuff has landed? This is just going to cause rebase pains all over.
>
> Jira: VIZ-4612
> Signed-off-by: Matt Roper
> ---
> drivers/gpu/drm/i915/Makefile|3 +-
> drivers/gpu/drm/i915/intel_display.c |1 +
> drivers/gpu/drm/i915/intel_drv.h |3 +
> drivers/gpu/drm/i915/intel_pm.c | 3450 -
> drivers/gpu/drm/i915/intel_wm.c | 3525
> ++
> 5 files changed, 3531 insertions(+), 3451 deletions(-)
> create mode 100644 drivers/gpu/drm/i915/intel_wm.c
>
> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> index f025e7f..5fd2257 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -55,7 +55,8 @@ i915-y += intel_audio.o \
> intel_overlay.o \
> intel_psr.o \
> intel_sideband.o \
> - intel_sprite.o
> + intel_sprite.o \
> + intel_wm.o
> i915-$(CONFIG_ACPI) += intel_acpi.o intel_opregion.o
> i915-$(CONFIG_DRM_I915_FBDEV)+= intel_fbdev.o
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index fad5f76..370c173 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -13213,6 +13213,7 @@ void intel_modeset_init(struct drm_device *dev)
> intel_init_quirks(dev);
>
> intel_init_pm(dev);
> + intel_init_wm(dev);
>
> if (INTEL_INFO(dev)->num_pipes == 0)
> return;
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index 1fb1529..995d030 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -1258,6 +1258,9 @@ void intel_pre_disable_primary(struct drm_crtc *crtc);
> /* intel_tv.c */
> void intel_tv_init(struct drm_device *dev);
>
> +/* intel_wm.c */
> +void intel_init_wm(struct drm_device *dev);
> +
> /* intel_atomic.c */
> int intel_atomic_check(struct drm_device *dev,
> struct drm_atomic_state *state);
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 7dcb5b6..f906b05 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -94,3402 +94,6 @@ static void skl_init_clock_gating(struct drm_device *dev)
> GEN8_LQSC_RO_PERF_DIS);
> }
>
> -static void i915_pineview_get_mem_freq(struct drm_device *dev)
> -{
> - struct drm_i915_private *dev_priv = dev->dev_private;
> - u32 tmp;
> -
> - tmp = I915_READ(CLKCFG);
> -
> - switch (tmp & CLKCFG_FSB_MASK) {
> - case CLKCFG_FSB_533:
> - dev_priv->fsb_freq = 533; /* 133*4 */
> - break;
> - case CLKCFG_FSB_800:
> - dev_priv->fsb_freq = 800; /* 200*4 */
> - break;
> - case CLKCFG_FSB_667:
> - dev_priv->fsb_freq = 667; /* 167*4 */
> - break;
> - case CLKCFG_FSB_400:
> - dev_priv->fsb_freq = 400; /* 100*4 */
> - break;
> - }
> -
> - switch (tmp & CLKCFG_MEM_MASK) {
> - case CLKCFG_MEM_533:
> - dev_priv->mem_freq = 533;
> - break;
> - case CLKCFG_MEM_667:
> - dev_priv->mem_freq = 667;
> - break;
> - case CLKCFG_MEM_800:
> - dev_priv->mem_freq = 800;
> - break;
> - }
> -
> - /* detect pineview DDR3 setting */
> - tmp = I915_READ(CSHRDDR3CTL);
> - dev_priv->is_ddr3 = (tmp & CSHRDDR3CTL_DDR3) ? 1 : 0;
> -}
> -
> -static void i915_ironlake_get_mem_freq(struct drm_device *dev)
> -{
> - struct drm_i915_private *dev_priv = dev->dev_private;
> - u16 ddrpll, csipll;
> -
> - ddrpll = I915_READ16(DDRMPLL1);
> - csipll = I915_READ16(CSIPLL0);
> -
> - switch (ddrpll & 0xff) {
> - case 0xc:
> - dev_priv->mem_freq = 800;
> - break;
> - case 0x10:
> - dev_priv->mem_freq = 1066;
> - break;
> - case 0x14:
> - dev_priv->mem_freq = 1333;
> - break;
> - case 0x18:
> - dev_priv->mem_freq = 1600;
> - break;
> - default:
> - DRM_DEBUG_DRIVER("unknown memory frequency 0x%02x\n",
> - ddrpll & 0xff);
> - dev_priv->mem_freq = 0;
> - break;
> - }
> -
> - dev_priv->ips.r_t = dev_priv->mem_freq;
> -
> - switch (csipll & 0x3ff) {
> - case 0x00c:
> - dev_priv->fsb_freq = 3200;
> - break;
> - case 0x00e:
> - dev_priv->fsb
Re: [Intel-gfx] [PATCH 04/51] drm/i915: Merged the many do_execbuf() parameters into a structure
On 27/02/2015 13:35, Daniel Vetter wrote:
On Fri, Feb 27, 2015 at 12:22:42PM +, John Harrison wrote:
On 25/02/2015 21:52, Daniel Vetter wrote:
On Fri, Feb 13, 2015 at 11:48:13AM +, john.c.harri...@intel.com wrote:
From: John Harrison
The do_execbuf() function takes quite a few parameters. The actual set of
parameters is going to change with the conversion to passing requests around.
Further, it is due to grow massively with the arrival of the GPU scheduler.
This patch simplies the prototype by passing a parameter structure instead.
Changing the parameter set in the future is then simply a matter of
adding/removing items to the structure.
Note that the structure does not contain absolutely everything that is passed
in. This is because the intention is to use this structure more extensively
later in this patch series and more especially in the GPU scheduler that is
coming soon. The latter requires hanging on to the structure as the final
hardware submission can be delayed until long after the execbuf IOCTL has
returned to user land. Thus it is unsafe to put anything in the structure that
is local to the IOCTL call itself - such as the 'args' parameter. All entries
must be copies of data or pointers to structures that are reference counted in
someway and guaranteed to exist for the duration of the batch buffer's life.
For: VIZ-5115
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/i915_drv.h| 27 +++---
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 56 ++--
drivers/gpu/drm/i915/intel_lrc.c | 26 +++--
drivers/gpu/drm/i915/intel_lrc.h |9 ++---
4 files changed, 67 insertions(+), 51 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index e90b786..e6d616b 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1640,6 +1640,16 @@ struct i915_workarounds {
u32 count;
};
+struct i915_execbuffer_params {
+ struct drm_device *dev;
+ struct drm_file *file;
+ uint32_tdispatch_flags;
+ uint32_tbatch_obj_vm_offset;
+ struct intel_engine_cs *ring;
+ struct drm_i915_gem_object *batch_obj;
+ struct intel_context*ctx;
+};
tbh I'm not a fan of parameter objects in C. C is verbose and explicit.
If we add the request then we can remove ring and ctx, which already
improves things. We also have the eb structure we use to pass around a
pile of things, which we could somewhat reuse here. What else do you plan
to add? Just want to figure out whether this is really required ...
-Daniel
The major advantage of this is when the GPU scheduler arrives. It splits the
execbuffer code path in half - front half is all the software state
verification and management, back half is the actual hardware writes to post
the buffer. This structure is used to bridge the two. It contains all the
state created by the front half that is later used by the back half. It is
saved away with the request/scheduler node until such a time as the back
half is called. Hence some kind of structure is required and it does not
really make sense to add all this information to the generic request
structure. Also, with the full pre-emptive scheduler, the structure grows to
about twenty entries and passing that quantity of individual parameters to a
function is just unwieldly!
Well we already have an execbuf tracking structure with eb_vmas. And then
there's requests. So if this is more than just a parameter object I wonder
whether we shouldn't reuse either of these. Adding them all to requests is
imo totally ok.
Oh and a bikeshed aside: imo the ->do_exebuf name is really confusing,
since it clashes with the the various do_execbuf functions we have which
are at a higher level. Also the implementations all have a _submission
postfix. Imo better names would be do_submission or engine_submit or
something simlar. The only caveat is that we need to make sure the
lifetime rules for any pointers are ok. E.g. before we return from the
ioctl we need to clear out drm_i915_gem_execbuffer2 *args pointers if we
store them in the request structure.
The lifetime issues is part of the reason for having a dedicated execbuf
params structure. Some of the contents of the args block are copied out
and saved away for future reference and they are only relevant to the
execbuf code. IMHO, keeping all of these things in one place is much
more neat and tidy (and thus easier to read and easier to maintain) than
overloading other structures with large amounts of stuff that isn't
relevant. The eb_vma structure is freed at the end of the front half and
not kept around for that back half. Requests are used for stuff that
isn't an execbuffer call.
Can you please pick a name and insert that rename patch somewhere
convenient (for you) in your series?
Ca
Re: [Intel-gfx] [PATCH] drm/i915: fix failure to power off after hibernate
On Fri, 2015-02-27 at 14:15 +0200, David Weinehall wrote: > On Thu, Feb 26, 2015 at 09:01:27PM +0100, Daniel Vetter wrote: > > On Thu, Feb 26, 2015 at 08:50:48PM +0200, Imre Deak wrote: > > [snip] > > > > > > The problem seems to be that after the kernel puts the device into D3 > > > the BIOS still tries to access it, or otherwise assumes that it's in D0. > > > This is clearly bogus, since ACPI mandates that devices are put into D3 > > > by the OSPM if they are not wake-up sources. In the future we want to > > > unify more of the driver's runtime and system suspend paths, for example > > > by skipping all the system suspend/hibernation hooks if the device is > > > runtime suspended already. Accordingly for all other platforms the goal > > > is still to properly power down the device during hibernation. > > [snip] > > > > If we see more of these troublesome machines we might need to apply an > > even bigger hammer like gen < 5 or so. But as long as there's just 1 > > report I think this is the right approach. > > > > Bjorn, as soon as we have your tested-by that this work we can apply this > > and shovel it through the backporting machinery. > > Isn't there a risk that this will negatively impact machines using gen4 > that *don't* have a buggy BIOS? Wouldn't a quirk tied to the laptop > or BIOS version be better suited -- or possibly a parameter that can be > passed to the driver, which would make it easier to test if others > suffering from similar symptoms on other systems suffer from the same > issue or not? > > Just my 2¢. We've checked today with Ville a few machines we've found from GEN2 to GEN5+. There was one Thinkpad x61s (GEN4) where I could reproduce the exact same problem and get rid of it using the same workaround. All the others were non-Lenovo (including GEN4) mobile and desktop platforms and none of these had the problem. I also tried it on a Lenovo IVB ultrabook, which also works fine. So the current theory is that it's related to GEN4 Thinkpad BIOSes, and so we need to change the condition to match that at least. --Imre ___ 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/chv: Determine CHV slice/subslice/EU info
On Fri, Feb 27, 2015 at 10:22:31AM -0800, jeff.mc...@intel.com wrote:
> From: Jeff McGee
>
> Total EU was already being detected on CHV, so we just add the
> additional info parameters. The detection method is changed to
> be more robust in the case of subslice fusing - we don't want
> to trust the EU fuse bits corresponding to subslices which are
> fused-off.
>
> Signed-off-by: Jeff McGee
> ---
> drivers/gpu/drm/i915/i915_dma.c | 40 ++--
> drivers/gpu/drm/i915/i915_reg.h | 2 ++
> 2 files changed, 36 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
> index 053e178..04e5b55e 100644
> --- a/drivers/gpu/drm/i915/i915_dma.c
> +++ b/drivers/gpu/drm/i915/i915_dma.c
> @@ -608,14 +608,42 @@ static void intel_device_info_runtime_init(struct
> drm_device *dev)
>
> /* Initialize slice/subslice/EU info */
> if (IS_CHERRYVIEW(dev)) {
> - u32 fuse, mask_eu;
> + u32 fuse, eu_dis;
>
> fuse = I915_READ(CHV_FUSE_GT);
> - mask_eu = fuse & (CHV_FGT_EU_DIS_SS0_R0_MASK |
> - CHV_FGT_EU_DIS_SS0_R1_MASK |
> - CHV_FGT_EU_DIS_SS1_R0_MASK |
> - CHV_FGT_EU_DIS_SS1_R1_MASK);
> - info->eu_total = 16 - hweight32(mask_eu);
> +
> + info->slice_total = 1;
> +
> + if (!(fuse & CHV_FGT_DISABLE_SS0)) {
^^^
That's your shift value. Masking with it probably won't work :P
> + info->subslice_per_slice++;
> + eu_dis = fuse & (CHV_FGT_EU_DIS_SS0_R0_MASK |
> + CHV_FGT_EU_DIS_SS0_R1_MASK);
> + info->eu_total += 8 - hweight32(eu_dis);
> + }
> +
> + if (!(fuse & CHV_FGT_DISABLE_SS1)) {
ditto
> + info->subslice_per_slice++;
> + eu_dis = fuse & (CHV_FGT_EU_DIS_SS1_R0_MASK |
> + CHV_FGT_EU_DIS_SS1_R1_MASK);
> + info->eu_total += 8 - hweight32(eu_dis);
> + }
> +
> + info->subslice_total = info->subslice_per_slice;
> + /*
> + * CHV expected to always have a uniform distribution of EU
> + * across subslices.
> + */
> + info->eu_per_subslice = info->subslice_total ?
> + info->eu_total / info->subslice_total :
> + 0;
> + /*
> + * CHV supports subslice power gating on devices with more than
> + * one subslice, and supports EU power gating on devices with
> + * more than one EU pair per subslice.
> + */
> + info->has_slice_pg = 0;
> + info->has_subslice_pg = (info->subslice_total > 1) ? 1 : 0;
> + info->has_eu_pg = (info->eu_per_subslice > 2) ? 1 : 0;
Nit: use of ?: seems pointless in these.
> } else if (IS_SKYLAKE(dev)) {
> const int s_max = 3, ss_max = 4, eu_max = 8;
> int s, ss;
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 55143cb..a8b205d 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -1522,6 +1522,8 @@ enum skl_disp_power_wells {
>
> /* Fuse readout registers for GT */
> #define CHV_FUSE_GT (VLV_DISPLAY_BASE + 0x2168)
> +#define CHV_FGT_DISABLE_SS010
> +#define CHV_FGT_DISABLE_SS111
> #define CHV_FGT_EU_DIS_SS0_R0_SHIFT16
> #define CHV_FGT_EU_DIS_SS0_R0_MASK (0xf << CHV_FGT_EU_DIS_SS0_R0_SHIFT)
> #define CHV_FGT_EU_DIS_SS0_R1_SHIFT20
> --
> 2.3.0
--
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] Suspend/resume problems on Broadwell
On Fri, 27 Feb 2015 18:59:07 +0100, Daniel Vetter wrote: > Smells like something is wrong in bdw-land. > > Can you please retest with latest drm-intel-nightly from > http://cgit.freedesktop.org/drm-intel or alternatively 4.0-rc kernels? > Starting with 4.0 we're using the execlist cmd submission support, > which might help. I've just tested with 4cf8e7747f184a0616b547b307d63b65298c88a7, drm-intel-nightly. I could not reproduce the suspend/resume problems with that kernel, and the "timed out trying to stop ring" error is also gone. I still see loads of unclaimed register warnings while running GL programs, though. > Thanks, Daniel > > > On Fri, Feb 27, 2015 at 6:27 PM, wrote: > > On Fri, 27 Feb 2015 00:07:41 +0100, pho...@quasiparticle.net wrote: > >> Hi, > >> > >> I'm having a few problems with i915 on my Broadwell Thinkpad > >> (T450s, i7-5600U) with kernel 3.19, apparently suspend/resume > >> related. > > […] > >> Also, it seems that running or having run a GL application has some > >> impact on this. With an instance of glxgears running during > >> suspend/resume, this doesn't seem to happen. Moreover, running a GL > >> app seems to fix the problem. > > > > Correction: running a GL app during suspend/resume prevents bad > > things (and the "timed out trying to stop ring" error, apparently). > > Running GL after resume only partly restores original state, > > sometimes font rendering is broken for random characters - they > > just don't display anymore. It also seems that only one font and > > only one size of that one font is affected. I'm guessing that's a > > problem in X, perhaps? > > > >> Is this known already, or can I somehow help to fix this? > >> > >> > >> Greetings, > >> Phoebe > > ___ > > 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
