Re: [Intel-gfx] [RFC 14/44] drm/i915: Added getparam for GPU scheduler

2014-07-02 Thread Jesse Barnes
ef struct drm_i915_getparam { > int param; I guess we have plenty of getparam space available. But another option would be for tests to check for a debugfs file that dumps scheduler info instead, and save the get params for non-debug applications. Either way though: Reviewed-by: Je

Re: [Intel-gfx] [RFC 13/44] drm/i915: Added scheduler hook when closing DRM file handles

2014-07-02 Thread Jesse Barnes
h I guess the client could have passed a ref to some other process for tracking the outstanding work, so we need to complete it. But shouldn't that happen as part of the clearing of the outstanding requests in i915_gem_suspend() which is called from lastclose()? We do a gpu_idle() and retire_requests() in there already... -- Jesse Barnes, 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] [RFC 12/44] drm/i915: Disable hardware semaphores when GPU scheduler is enabled

2014-07-02 Thread Jesse Barnes
heduler.c > @@ -26,6 +26,15 @@ > #include "intel_drv.h" > #include "i915_scheduler.h" > > +bool i915_scheduler_is_enabled(struct drm_device *dev) > +{ > +#ifdef CONFIG_DRM_I915_SCHEDULER > + return true; > +#else > + return false; > +#en

Re: [Intel-gfx] [RFC 11/44] drm/i915: Added scheduler hook into i915_seqno_passed()

2014-07-02 Thread Jesse Barnes
I'll see in a later patch... Same comment about the ifdef applies here; looks like you have some runtime checking in place too, which seems sufficient to me. -- Jesse Barnes, Intel Open Source Technology Center ___ Intel-gfx mailing

Re: [Intel-gfx] [RFC 10/44] drm/i915: Prepare retire_requests to handle out-of-order seqnos

2014-07-02 Thread Jesse Barnes
list); > + > + i915_gem_free_request(req); > + } > + > WARN_ON(i915_verify_lists(ring->dev)); > } > I think this looks ok, but I don't look at this code much... Seems like it should be fine to go

Re: [Intel-gfx] [RFC 09/44] drm/i915: Start of GPU scheduler

2014-07-02 Thread Jesse Barnes
t; + > + scheduler = kzalloc(sizeof(*scheduler), GFP_KERNEL); > + if (!scheduler) > + return -ENOMEM; > + > + spin_lock_init(&scheduler->lock); > + > + scheduler->index = 1; > + > + dev_priv->scheduler = scheduler; > + > + return 0; > +} &

Re: [Intel-gfx] [RFC 07/44] drm/i915: Disable 'get seqno' workaround for VLV

2014-07-02 Thread Jesse Barnes
ring->set_seqno = ring_set_seqno; > ring->semaphore.sync_to = gen6_ring_sync; > ring->semaphore.signal = gen6_signal; Assuming this has been well tested: Reviewed-by: Jesse Barnes -- Jesse Barnes, Intel Open Source Technology Center ___

Re: [Intel-gfx] [RFC 06/44] drm/i915: Fixes for FIFO space queries

2014-07-02 Thread Jesse Barnes
mp; fw_engine) > @@ -355,8 +391,7 @@ static void intel_uncore_forcewake_reset(struct > drm_device *dev, bool restore) > > if (IS_GEN6(dev) || IS_GEN7(dev)) > dev_priv->uncore.fifo_count = > -

Re: [Intel-gfx] [RFC 05/44] drm/i915: Updating assorted register and status page definitions

2014-07-02 Thread Jesse Barnes
ht? So you might not need that one. But overall looks fine. Reviewed-by: Jesse Barnes -- Jesse Barnes, 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 4/8] drm/i915: Rename ctx->id to ctx->handle

2014-07-01 Thread Jesse Barnes
On Tue, 1 Jul 2014 15:46:51 + "Mateo Lozano, Oscar" wrote: > > -Original Message- > > From: Jesse Barnes [mailto:jbar...@virtuousgeek.org] > > Sent: Monday, June 30, 2014 9:54 PM > > To: Mateo Lozano, Oscar > > Cc: intel-gfx@lists.freedesktop.o

Re: [Intel-gfx] [PATCH 37/40] drm/i915: Fix eDP link training when switching pipes

2014-06-30 Thread Jesse Barnes
intel_edp_panel_vdd_on(intel_dp); > + intel_edp_init_train(intel_dp); > intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON); > intel_dp_start_link_train(intel_dp); > - intel_edp_panel_on(intel_dp); > - edp_panel_vdd_off(intel_dp, true); > intel_dp_complete_link_train(intel_dp

Re: [Intel-gfx] [RFC 04/44] drm/i915: Fix null pointer dereference in error capture

2014-06-30 Thread Jesse Barnes
request->ctx ? > + > request->ctx->vm : > + > &dev_priv->gtt.base); > > if (HAS_BROKEN_CS_TLB(dev_priv->dev) && > ring->s

Re: [Intel-gfx] [RFC 03/44] drm/i915: Add extra add_request calls

2014-06-30 Thread Jesse Barnes
, > intel_ring_emit(ring, pf | pipesrc); > > intel_mark_page_flip_active(intel_crtc); > - __intel_ring_advance(ring); > + i915_add_request_wo_flush(ring); > return 0; > } > > @@ -9182,7 +9182,7 @@ static int intel_gen7_queue_flip(struct d

Re: [Intel-gfx] [RFC 01/44] drm/i915: Corrected 'file_priv' to 'file' in 'i915_driver_preclose()'

2014-06-30 Thread Jesse Barnes
struct drm_file *file_priv); > + struct drm_file *file); > extern int i915_driver_device_is_agp(struct drm_device * dev); > #ifdef CONFIG_COMPAT > extern long i915_compat_ioctl(struct file *filp, unsigned int cmd, Reviewed-by: Jesse Barnes -- Jesse Barnes, 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 8/8] drm/i915: Extract the actual workload submission mechanism from execbuffer

2014-06-30 Thread Jesse Barnes
ssion mechanism). "will have" ? > > No functional changes. Reviewed-by: Jesse Barnes -- Jesse Barnes, 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 7/8] drm/i915: Generalize intel_ring_get_tail to take a ringbuf

2014-06-30 Thread Jesse Barnes
tel_ringbuffer *ringbuf) > { > - return ring->buffer->tail; > + return ringbuf->tail; > } > > static inline u32 intel_ring_get_seqno(struct intel_engine_cs *ring) Reviewed-by: Jesse Barnes -- Jesse Barnes, 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 6/8] drm/i915: Generalize ring_space to take a ringbuf

2014-06-30 Thread Jesse Barnes
uf->space >= n) { > ret = 0; > break; > @@ -1641,7 +1640,7 @@ static int intel_wrap_ring_buffer(struct > intel_engine_cs *ring) > iowrite32(MI_NOOP, virt++); > > ringbuf->tail = 0; > - ringbuf->space

Re: [Intel-gfx] [PATCH 5/8] drm/i915: Extract ringbuffer destroy & generalize alloc to take a ringbuf

2014-06-30 Thread Jesse Barnes
MODE_IDLE) == 0); > > - iounmap(ringbuf->virtual_start); > - > - i915_gem_object_ggtt_unpin(ringbuf->obj); > - drm_gem_object_unreference(&ringbuf->obj->base); > - ringbuf->obj = NULL; > + intel_destroy_ringbuffer_obj(ringbuf); > ri

Re: [Intel-gfx] [PATCH 4/8] drm/i915: Rename ctx->id to ctx->handle

2014-06-30 Thread Jesse Barnes
/drm/i915/intel_uncore.c > index 29145df..e0f0843 100644 > --- a/drivers/gpu/drm/i915/intel_uncore.c > +++ b/drivers/gpu/drm/i915/intel_uncore.c > @@ -1010,7 +1010,7 @@ int i915_get_reset_stats_ioctl(struct drm_device *dev, > if (args->flags || args->pad) > return -EINVAL; > > - if (args->ctx_id == DEFAULT_CONTEXT_ID && !capable(CAP_SYS_ADMIN)) > + if (args->ctx_id == DEFAULT_CONTEXT_HANDLE && !capable(CAP_SYS_ADMIN)) > return -EPERM; > > ret = mutex_lock_interruptible(&dev->struct_mutex); So this handle is just the sw tracking ID right? Would be nice to have a patch on top commenting that in the context struct (well commenting the whole struct really). Reviewed-by: Jesse Barnes -- Jesse Barnes, 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 3/8] drm/i915: Rename ctx->is_initialized to ctx->rcs_is_initialized

2014-06-30 Thread Jesse Barnes
@ -716,13 +716,13 @@ done: > i915_gem_context_reference(to); > ring->last_context = to; > > - if (ring->id == RCS && !to->is_initialized && from == NULL) { > + if (ring->id == RCS && !to->r

Re: [Intel-gfx] [PATCH 2/8] drm/i915: Rename ctx->obj to ctx->rcs_state

2014-06-30 Thread Jesse Barnes
* swapped, but there is no way to do that yet. >*/ > - from->obj->dirty = 1; > - BUG_ON(from->obj->ring != ring); > + from->rcs_state->dirty = 1; > + BUG_ON(from->rcs_state->ring != ring); > > /* obj is kept alive until the next request by its active ref */ > - i915_gem_object_ggtt_unpin(from->obj); > + i915_gem_object_ggtt_unpin(from->rcs_state); > i915_gem_context_unreference(from); > } > > @@ -728,7 +728,7 @@ done: > > unpin_out: > if (ring->id == RCS) > - i915_gem_object_ggtt_unpin(to->obj); > + i915_gem_object_ggtt_unpin(to->rcs_state); > return ret; > } > > @@ -749,7 +749,7 @@ int i915_switch_context(struct intel_engine_cs *ring, > > WARN_ON(!mutex_is_locked(&dev_priv->dev->struct_mutex)); > > - if (to->obj == NULL) { /* We have the fake context */ > + if (to->rcs_state == NULL) { /* We have the fake context */ > if (to != ring->last_context) { > i915_gem_context_reference(to); > if (ring->last_context) Reviewed-by: Jesse Barnes -- Jesse Barnes, 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 1/8] drm/i915: Extract context backing object allocation

2014-06-30 Thread Jesse Barnes
NTEL_INFO(dev)->gen >= 7 && !IS_VALLEYVIEW(dev)) { > - ret = i915_gem_object_set_cache_level(ctx->obj, > - > I915_CACHE_L3_LLC); > - /* Failure shouldn't ever happen this early *

Re: [Intel-gfx] [PATCH 2/2] drm/i915: respect the VBT minimum backlight brightness

2014-06-30 Thread Jesse Barnes
On Sat, 28 Jun 2014 16:45:03 +0300 Jani Nikula wrote: > >> +/* Scale user_level in range [0..user_max] to [0..hw_max], clamping the > >> result > >> + * to [hw_min..hw_max]. */ > >> +static inline u32 clamp_user_to_hw(struct intel_connector *connector, > >> + u32 user_

Re: [Intel-gfx] [PATCH 2/2] drm/i915: respect the VBT minimum backlight brightness

2014-06-27 Thread Jesse Barnes
On Tue, 24 Jun 2014 18:27:40 +0300 Jani Nikula wrote: > Historically we've exposed the full backlight PWM duty cycle range to > the userspace, in the name of "mechanism, not policy". However, it turns > out there are both panels and board designs where there is a minimum > duty cycle that is requ

Re: [Intel-gfx] [PATCH] drm/i915/bdw: BDW Software Turbo

2014-06-26 Thread Jesse Barnes
On Thu, 26 Jun 2014 09:42:45 -0700 Jesse Barnes wrote: > On Mon, 16 Jun 2014 13:13:38 -0700 > Daisy Sun wrote: > > > BDW supports GT C0 residency reporting in constant time unit. Driver > > calculates > > GT utilization based on C0 residency and adjusts RP frequen

Re: [Intel-gfx] [PATCH] drm/i915/bdw: BDW Software Turbo

2014-06-26 Thread Jesse Barnes
915_WRITE(GEN6_RP_IDLE_HYSTERSIS, 10); > + } > > - gen6_enable_rps_interrupts(dev); > + /* 5: Enable RPS */ > + rp_ctl_flag = GEN6_RP_MEDIA_TURBO | > + GEN6_RP_MEDIA_HW_NORMAL_MODE

Re: [Intel-gfx] [PATCH 0/9] drm: More vblank on/off work

2014-06-26 Thread Jesse Barnes
enabled while disabling crtcs during > suspend Here's one that may be fixed by this series, needs testing though: https://bugs.freedesktop.org/show_bug.cgi?id=79054 -- Jesse Barnes, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] gem_exec_parse: require PPGTT as well

2014-06-26 Thread Jesse Barnes
The command parser may be present, but not active, so check for PPGTT before allowing this test to run. Signed-off-by: Jesse Barnes --- tests/gem_exec_parse.c | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/tests/gem_exec_parse.c b/tests/gem_exec_parse.c index e78a192

Re: [Intel-gfx] [PATCH] drm/i915: fix sanitize_enable_ppgtt for full PPGTT

2014-06-26 Thread Jesse Barnes
On Thu, 26 Jun 2014 17:59:48 +0300 Ville Syrjälä wrote: > On Wed, Jun 25, 2014 at 03:45:33PM -0700, Jesse Barnes wrote: > > Apparently trinary logic is hard. We were falling through all the forced > > cases and simply enabling aliasing PPGTT or not based on hardware, > > r

[Intel-gfx] [PATCH] drm/i915: fix sanitize_enable_ppgtt for full PPGTT

2014-06-25 Thread Jesse Barnes
Apparently trinary logic is hard. We were falling through all the forced cases and simply enabling aliasing PPGTT or not based on hardware, rather than full PPGTT if available. References: https://bugs.freedesktop.org/show_bug.cgi?id=80083 Signed-off-by: Jesse Barnes --- drivers/gpu/drm/i915

Re: [Intel-gfx] [WIP][PATCH 11/11] drm/i915: Turn off clocks when disp2d is powered down

2014-06-25 Thread Jesse Barnes
FIXME maybe move to cmnlane? > + */ > + vlv_ccu_write(dev_priv, CCU_ICLK_5, > + vlv_ccu_read(dev_priv, CCU_ICLK_5) & > + ~(DISPBEND_CLKREQ | DISPSS_CLKREQ)); > + mutex_unlock(&dev_priv->dpio_lock); > } >

Re: [Intel-gfx] [PATCH 10/11] drm/i915: Move VLV cmnlane workaround to intel_power_domains_init_hw()

2014-06-25 Thread Jesse Barnes
IEW(dev)) { > + mutex_lock(&power_domains->lock); > + vlv_cmnlane_wa(dev_priv); > + mutex_unlock(&power_domains->lock); > + } > + > /* For now, we need the power well to be always enabled. */ > intel_display_set_init_power(dev_priv, true); > intel_power_domains_resume(dev_priv); I kind of preferred the low level function that just took a well ID directly since the idea of looking something we already know seems silly (and it should probably be a separate patch anyway). Also I'm not sure I would describe this as a W/A; the phy needs to get reset somehow... But with or without those changes, we need this. Reviewed-by: Jesse Barnes -- Jesse Barnes, 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 09/11] drm/i915: Pull the cmnlane tricks into its own power well ops

2014-06-25 Thread Jesse Barnes
ower_well_ops = { > + .sync_hw = vlv_power_well_sync_hw, > + .enable = vlv_dpio_cmn_power_well_enable, > + .disable = vlv_dpio_cmn_power_well_disable, > + .is_enabled = vlv_power_well_enabled, > +}; > + > static const struct i915_power_well_ops vlv_dpio_power_well_ops

Re: [Intel-gfx] [PATCH 08/11] drm/i915: Kill duplicated cdclk readout code from i2c

2014-06-25 Thread Jesse Barnes
; - if (IS_VALLEYVIEW(dev)) > - gmbus_set_freq(dev_priv); > - > I915_WRITE(dev_priv->gpio_mmio_base + GMBUS0, 0); > I915_WRITE(dev_priv->gpio_mmio_base + GMBUS4, 0); > } > diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_p

Re: [Intel-gfx] [PATCH 07/11] drm/i915: Warn if there's a cdclk change in progess

2014-06-25 Thread Jesse Barnes
e, so rather than warn maybe we should try a wait instead, and only warn if it times out? Even then there's not much we can do aside from poking the PUnit folks. -- Jesse Barnes, 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 06/11] drm/i915: Wait for cdclk change to occure when going for 400MHz

2014-06-25 Thread Jesse Barnes
_STATUS) == (divider << > DISPLAY_FREQUENCY_STATUS_SHIFT), > + 50)) > + DRM_ERROR("timed out waiting for CDclk change\n"); > mutex_unlock(&dev_priv->dpio_lock); > } > Seems rea

Re: [Intel-gfx] [PATCH 05/11] drm/i915: Use 200MHz cdclk on vlv when all pipes are off

2014-06-25 Thread Jesse Barnes
7; > - /* Looks like the 200MHz CDclk freq doesn't work on some configs */ > + else > + return 20; > } > > /* compute the max pixel clock for new configuration */ I guess this is safe, but optional (won't we be shutting off the clocks anyway?). Reviewed-by:

Re: [Intel-gfx] [PATCH 04/11] drm/i915: Handle 320 vs. 333 MHz cdclk on vlv

2014-06-25 Thread Jesse Barnes
> - return 32; > + return freq_320; > else > return 27; > /* Looks like the 200MHz CDclk freq doesn't work on some configs */ Looks good. This doc searching has been fun. Reviewed-by: Jesse Barnes -- Jesse Barnes, Intel O

Re: [Intel-gfx] [PATCH 03/11] drm/i915: Move vlv cdclk code to .get_display_clock_speed()

2014-06-25 Thread Jesse Barnes
id valleyview_init_clock_gating(struct > drm_device *dev) > } > DRM_DEBUG_DRIVER("DDR speed: %d MHz", dev_priv->mem_freq); > > - dev_priv->vlv_cdclk_freq = valleyview_cur_cdclk(dev_priv); > + dev_priv->vlv_cdclk_freq = > dev_priv->display.get_displa

Re: [Intel-gfx] [PATCH 02/11] drm/i915: Give names to the CCK_DISPLAY_CLOCK_CONTROL bits

2014-06-25 Thread Jesse Barnes
17,7 @@ int valleyview_cur_cdclk(struct drm_i915_private > *dev_priv) > divider = vlv_cck_read(dev_priv, CCK_DISPLAY_CLOCK_CONTROL); > mutex_unlock(&dev_priv->dpio_lock); > > - divider &= 0xf; > + divider &= DISPLAY_FREQUENCY_VALUES; > > cur_cdclk = DIV_ROUND_CLOSEST(vco << 1, divider + 1); > You snuck in a fix for the mask here, but it looks correct. Reviewed-by: Jesse Barnes http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 01/11] drm/i915: Change vlv cdclk to use kHz units

2014-06-25 Thread Jesse Barnes
a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c > index 5024bc8..a9ddf74 100644 > --- a/drivers/gpu/drm/i915/intel_pm.c > +++ b/drivers/gpu/drm/i915/intel_pm.c > @@ -5536,7 +5536,7 @@ static void valleyview_init_clock_gating(struct >

[Intel-gfx] [PATCH] drm/i915: only apply crt_present check on VLV

2014-06-25 Thread Jesse Barnes
Apparently we can't trust this field on other platforms and need to find some other way. Signed-off-by: Jesse Barnes --- drivers/gpu/drm/i915/intel_display.c | 18 +- 1 file changed, 17 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_display.c b/dr

Re: [Intel-gfx] [PATCH 2/3] drm/i915: correct BLC vs PWM enable/disable ordering

2014-06-25 Thread Jesse Barnes
On Wed, 25 Jun 2014 15:21:12 +0300 Jani Nikula wrote: > On Mon, 31 Mar 2014, Jesse Barnes wrote: > > With the new checks in place, we can see we're doing things backwards, > > so fix them up per the spec. > > > > Signed-off-by: Jesse Barnes > > --- >

Re: [Intel-gfx] [PATCH 26/53] drm/i915/bdw: New logical ring submission mechanism

2014-06-24 Thread Jesse Barnes
On Mon, 23 Jun 2014 14:13:55 +0100 Chris Wilson wrote: > On Mon, Jun 23, 2014 at 01:09:37PM +, Mateo Lozano, Oscar wrote: > > So far, yes, but that´s only because I artificially made > > intel_lrc.c self-contained, as Daniel requested. What if we need to > > execute commands from somewhere el

[Intel-gfx] [PATCH] drm/i915: mark IRQs as disabled on unload

2014-06-20 Thread Jesse Barnes
To avoid more spew with the new warnings. Signed-off-by: Jesse Barnes --- drivers/gpu/drm/i915/intel_display.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index d993b69..7288d1d 100644 --- a/drivers/gpu/drm

[Intel-gfx] [PATCH] drm/i915: clear pm._irqs_disabled field after installing IRQs

2014-06-20 Thread Jesse Barnes
After this point, we'll modify it with the runtime routines. Signed-off-by: Jesse Barnes --- drivers/gpu/drm/i915/i915_dma.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c index 5e583a1..f9b3f63 100644 --- a/driver

[Intel-gfx] [PATCH 4/4] drm/i915: set pm._irqs_disabled at IRQ init time

2014-06-20 Thread Jesse Barnes
Before we've installed the handler, we can set this and avoid confusing init code that then thinks IRQs are enabled and spews complaints everywhere. Signed-off-by: Jesse Barnes --- drivers/gpu/drm/i915/i915_irq.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm

[Intel-gfx] [PATCH 2/4] drm/i915: add helper for checking whether IRQs are enabled

2014-06-20 Thread Jesse Barnes
Now that we use the runtime IRQ enable/disable functions in our suspend path, we can simply check the pm._irqs_disabled flag everywhere. So rename it to catch the users, and add an inline for it to make the checks clear everywhere. Signed-off-by: Jesse Barnes --- drivers/gpu/drm/i915

[Intel-gfx] [PATCH 1/4] drm/i915: don't warn if IRQs are disabled when shutting down display IRQs

2014-06-20 Thread Jesse Barnes
This was always the case on our suspend path, but it was recently exposed by the change to use our runtime IRQ disable routine rather than the full DRM IRQ disable. Keep the warning on the enable side, as that really would indicate a bug. Signed-off-by: Jesse Barnes --- drivers/gpu/drm/i915

[Intel-gfx] [PATCH 3/4] drm/i915: drop runtime PM get/put pair around DP detect

2014-06-20 Thread Jesse Barnes
We're taking the right power well refs now, so this shouldn't be needed. Reported-by: Imre Deak Signed-off-by: Jesse Barnes --- drivers/gpu/drm/i915/intel_dp.c | 4 1 file changed, 4 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c ind

Re: [Intel-gfx] [PATCH 2/3] drm/i915: correct BLC vs PWM enable/disable ordering

2014-06-19 Thread Jesse Barnes
Jani, can you review this one? It's still needed for us to conform to the eDP timing spec. Thanks, Jesse On Mon, 31 Mar 2014 11:13:56 -0700 Jesse Barnes wrote: > With the new checks in place, we can see we're doing things backwards, > so fix them up per the spec. > >

[Intel-gfx] [PATCH 1/2] drm/i915: use runtime irq suspend/resume in freeze/thaw

2014-06-18 Thread Jesse Barnes
We don't need to uninstall the full handler, simply disabling interrupts ought to be enough. Signed-off-by: Jesse Barnes --- drivers/gpu/drm/i915/i915_drv.c | 5 ++--- drivers/gpu/drm/i915/intel_pm.c | 4 ++-- 2 files changed, 4 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm

[Intel-gfx] [PATCH 2/2] drm/i915: don't take runtime PM reference around freeze/thaw

2014-06-18 Thread Jesse Barnes
We should be taking the right power well refs these days, so this shouldn't be necessary. It also gets in the way of re-using these routines for S0iX states, as those need all the power saving features enabled. Signed-off-by: Jesse Barnes --- drivers/gpu/drm/i915/i915_drv.c | 3 --- 1

Re: [Intel-gfx] [PATCH] Fixed the review issues for pm_rc6_residency IGT case

2014-06-16 Thread Jesse Barnes
On Mon, 16 Jun 2014 23:55:24 +0200 Daniel Vetter wrote: > On Mon, Jun 16, 2014 at 10:38 PM, Jesse Barnes > wrote: > > On Mon, 16 Jun 2014 11:43:30 -0700 > > Ben Widawsky wrote: > > > >> Hi Wendy. Daniel has reverted your

Re: [Intel-gfx] [PATCH] Fixed the review issues for pm_rc6_residency IGT case

2014-06-16 Thread Jesse Barnes
est intel-gpu-tools? I also made that clear when Daniel and I discussed it. I simply don't understand why a revert was necessary, especially given that we had an incremental patch to address many of the comments. Was the test breaking i-g-t runs (i.e. preventing tests from running)? Was it

Re: [Intel-gfx] [PATCH] drm/i915/vlv: disable PPGTT on early revs

2014-06-13 Thread Jesse Barnes
On Fri, 13 Jun 2014 17:02:10 +0100 Chris Wilson wrote: > On Fri, Jun 13, 2014 at 06:54:02PM +0300, Ville Syrjälä wrote: > > On Fri, Jun 13, 2014 at 08:32:38AM -0700, Jesse Barnes wrote: > > > Early revs didn't have PPGTT support, so disable there. > &g

[Intel-gfx] [PATCH] drm/i915/vlv: disable PPGTT on early revs v3

2014-06-13 Thread Jesse Barnes
79670 Signed-off-by: Jesse Barnes --- drivers/gpu/drm/i915/i915_gem_gtt.c |6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c b/drivers/gpu/drm/i915/i915_gem_gtt.c index 8b3cde7..7f226fa 100644 --- a/drivers/gpu/drm/i915/i915_gem_gtt.c +++ b/drivers/gpu/drm

[Intel-gfx] [PATCH] drm/i915/vlv: disable PPGTT on early revs v2

2014-06-13 Thread Jesse Barnes
Early revs didn't have PPGTT support, so disable there. v2: add debug msg when disabling on early stepping References: https://bugs.freedesktop.org/show_bug.cgi?id=79669 References: https://bugs.freedesktop.org/show_bug.cgi?id=79670 Signed-off-by: Jesse Barnes --- drivers/gpu/drm

Re: [Intel-gfx] [PATCH] drm/i915/vlv: disable PPGTT on early revs

2014-06-13 Thread Jesse Barnes
On Fri, 13 Jun 2014 18:54:02 +0300 Ville Syrjälä wrote: > On Fri, Jun 13, 2014 at 08:32:38AM -0700, Jesse Barnes wrote: > > Early revs didn't have PPGTT support, so disable there. > > > > References: https://bugs.freedesktop.org/show_bug.cgi?id=79669 > > Referenc

[Intel-gfx] [PATCH] drm/i915: re-order ppgtt sanitize logic v2

2014-06-13 Thread Jesse Barnes
he no PPGTT case early on (Jesse) Signed-off-by: Jesse Barnes --- drivers/gpu/drm/i915/i915_gem_gtt.c | 25 + 1 file changed, 13 insertions(+), 12 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c b/drivers/gpu/drm/i915/i915_gem_gtt.c index d45303d..26

[Intel-gfx] [PATCH 2/2] drm/i915: re-order ppgtt sanitize logic

2014-06-13 Thread Jesse Barnes
Put hw limitations first, disabling ppgtt if necessary right away. After that, check user passed args or auto-detect and do the right thing, falling back to aliasing PPGTT if the user tries to enable full PPGTT but it isn't available. Signed-off-by: Jesse Barnes --- drivers/gpu/drm

[Intel-gfx] [PATCH 1/2] drm/i915: clean up PPGTT checking logic

2014-06-13 Thread Jesse Barnes
sanitize_enable_ppgtt is the function that checks all the conditions, honoring a forced ppgtt status or doing auto-detect as necessary. Just make sure it returns the right value in all cases and use that in the macros instead of the confusing intel_enable_ppgtt() function. Signed-off-by: Jesse

[Intel-gfx] [PATCH] drm/i915/vlv: disable PPGTT on early revs

2014-06-13 Thread Jesse Barnes
Early revs didn't have PPGTT support, so disable there. References: https://bugs.freedesktop.org/show_bug.cgi?id=79669 References: https://bugs.freedesktop.org/show_bug.cgi?id=79670 Signed-off-by: Jesse Barnes --- drivers/gpu/drm/i915/i915_gem_gtt.c |4 1 file changed, 4 inser

Re: [Intel-gfx] [PATCH] drm/i915: Unifiy GT powersave suspend logic

2014-06-12 Thread Jesse Barnes
h_delayed_work while (since we want to make sure rps is set up) > while Imre's used a cancel+manuel refcount adjustment. > > Unify them again by simply reusing intel_suspend_gt_powersave in > intel_disable_gt_powersave. > > Cc: Imre Deak > Cc: Jesse Barnes > Sig

[Intel-gfx] [PATCH 4/5] drm/i915: send proper opregion notifications on suspend/resume

2014-06-12 Thread Jesse Barnes
This indicates to the firmware that it can power down various other components or bring them back up, depending on the target system state. Reviewed-by: Imre Deak Signed-off-by: Kristen Carlson Accardi Signed-off-by: Jesse Barnes --- drivers/gpu/drm/i915/i915_drv.c | 10 ++ 1 file

[Intel-gfx] [PATCH 3/5] ACPI: export target system state for use by drivers

2014-06-12 Thread Jesse Barnes
From: Kristen Carlson Accardi Needed in ->freeze routines to figure out the target system state and take appropriate action. v2: split out ACPI patch Reviewed-by: Imre Deak Signed-off-by: Kristen Carlson Accardi Signed-off-by: Jesse Barnes --- drivers/acpi/sleep.c | 1 + 1 file changed

[Intel-gfx] [PATCH 2/5] drm/i915: leave rc6 enabled at suspend time v4

2014-06-12 Thread Jesse Barnes
This allows the system to enter the lowest power mode during system freeze. v2: delete force wake timer at suspend (Imre) v3: add GT work suspend function (Imre) v4: use uncore forcewake reset (Daniel) Reviewed-by: Imre Deak Signed-off-by: Kristen Carlson Accardi Signed-off-by: Jesse Barnes

[Intel-gfx] [PATCH 1/5] drm/i915: disable power wells on suspend

2014-06-12 Thread Jesse Barnes
From: Kristen Carlson Accardi We want to make sure everything is disabled and at its lowest power when freezing. Reviewed-by: Imre Deak Signed-off-by: Kristen Carlson Accardi Signed-off-by: Jesse Barnes --- drivers/gpu/drm/i915/i915_drv.c | 2 ++ 1 file changed, 2 insertions(+) diff --git

[Intel-gfx] [PATCH 5/5] drm/i915: make sure PC8 is enabled on suspend and disabled on resume v4

2014-06-12 Thread Jesse Barnes
freeze_late (Jesse) v4: move back to suspend_late (Imre was right) Reviewed-by: Imre Deak Signed-off-by: Kristen Carlson Accardi Signed-off-by: Jesse Barnes --- drivers/gpu/drm/i915/i915_drv.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm

Re: [Intel-gfx] [PATCH] drm/i915: leave rc6 enabled at suspend time v4

2014-06-11 Thread Jesse Barnes
On Wed, 11 Jun 2014 15:21:16 -0700 Jesse Barnes wrote: > On Tue, 10 Jun 2014 17:26:45 +0200 > Daniel Vetter wrote: > > > On Tue, Jun 10, 2014 at 05:41:49PM +0300, Imre Deak wrote: > > > On Tue, 2014-06-10 at 15:57 +0200, Daniel Vetter wrote: > > > > On T

Re: [Intel-gfx] [PATCH] drm/i915: leave rc6 enabled at suspend time v4

2014-06-11 Thread Jesse Barnes
ork suspend function (Imre) > > > > > v4: use uncore forcewake reset (Daniel) > > > > > > > > > > Signed-off-by: Kristen Carlson Accardi > > > > > Signed-off-by: Jesse Barnes > > > > > --- > > > > > d

Re: [Intel-gfx] drm/i915/bdw: Enable resource streamer on Broadwell

2014-06-11 Thread Jesse Barnes
, 18 insertions(+), 2 deletions(-) These seem trivial enough... have you seen cases where you'd like to enable it in Mesa? If so, it probably makes sense to merge this patch so you can do your tuning and enabling on the Mesa side... -- Jesse Barnes, Intel Open Source Technology Cent

Re: [Intel-gfx] [PATCH 2/5] drm/i915: preserve swizzle settings if necessary v3

2014-06-11 Thread Jesse Barnes
On Wed, 11 Jun 2014 17:39:29 +0200 Daniel Vetter wrote: > On Wed, Jun 11, 2014 at 5:13 PM, Jesse Barnes > wrote: > >> - If you have a machine which uses tiled framebuffers and enables > >> swizzling in the BIOS your code will a) drop the swizzle setup in > >>

Re: [Intel-gfx] [PATCH 2/5] drm/i915: preserve swizzle settings if necessary v3

2014-06-11 Thread Jesse Barnes
On Wed, 11 Jun 2014 11:23:26 +0200 Daniel Vetter wrote: > On Tue, Jun 10, 2014 at 12:45:38PM -0700, Jesse Barnes wrote: > > On Tue, 10 Jun 2014 21:33:27 +0200 > > Daniel Vetter wrote: > > > > > On Tue, Jun 10, 2014 at 7:27 PM, Jesse Barnes > > > wrote: &

Re: [Intel-gfx] [PATCH 2/5] drm/i915: preserve swizzle settings if necessary v3

2014-06-10 Thread Jesse Barnes
On Tue, 10 Jun 2014 21:33:27 +0200 Daniel Vetter wrote: > On Tue, Jun 10, 2014 at 7:27 PM, Jesse Barnes > wrote: > > Yes, that's what I do below... I even added it to the changelog: > > http://patchwork.freedesktop.org/patch/27223/ > > > > Did you mis

Re: [Intel-gfx] [PATCH 5/5] drm/i915: enable fastboot by default

2014-06-10 Thread Jesse Barnes
On Tue, 10 Jun 2014 11:01:06 -0700 Stéphane Marchesin wrote: > On Tue, Jun 10, 2014 at 10:31 AM, Jesse Barnes > wrote: > > On Tue, 10 Jun 2014 16:07:44 +0200 > > Daniel Vetter wrote: > > > >> On Thu, Jun 05, 2014 at 11:24:31AM -0700, Jesse Barnes wrote:

Re: [Intel-gfx] [PATCH 5/5] drm/i915: enable fastboot by default

2014-06-10 Thread Jesse Barnes
On Tue, 10 Jun 2014 16:07:44 +0200 Daniel Vetter wrote: > On Thu, Jun 05, 2014 at 11:24:31AM -0700, Jesse Barnes wrote: > > Let them eat mincemeat pie. > > > > Signed-off-by: Jesse Barnes > > --- > > drivers/gpu/drm/i915/i915_params.c | 4 ++-- > > 1 fil

Re: [Intel-gfx] [PATCH 4/5] drm/i915: use current mode if the size matches the preferred mode

2014-06-10 Thread Jesse Barnes
On Tue, 10 Jun 2014 16:05:36 +0200 Daniel Vetter wrote: > On Thu, Jun 05, 2014 at 11:24:30AM -0700, Jesse Barnes wrote: > > From: Kristian Høgsberg > > > > The BIOS may set a native mode that doesn't quite match the preferred > > mode timings. It should be

Re: [Intel-gfx] [PATCH 2/5] drm/i915: preserve swizzle settings if necessary v3

2014-06-10 Thread Jesse Barnes
On Tue, 10 Jun 2014 16:02:51 +0200 Daniel Vetter wrote: > On Thu, Jun 05, 2014 at 11:24:28AM -0700, Jesse Barnes wrote: > > Some machines (like MBAs) might use a tiled framebuffer but not enable > > display swizzling at boot time. We want to preserve that configuration >

Re: [Intel-gfx] [PATCH v2 09/15] drm/i915: Ignore VBT int_crt_support on 830M

2014-06-06 Thread Jesse Barnes
has changed over time, I'm trying to get the info from ancient times. -- Jesse Barnes, 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] New async patch for resume

2014-06-06 Thread Jesse Barnes
On Fri, 6 Jun 2014 18:36:46 +0200 Daniel Vetter wrote: > On Thu, Jun 05, 2014 at 08:48:37AM -0700, Jesse Barnes wrote: > > In digging into the async crtc stuff, I found it was going to be really > > difficult to prevent other functions from getting clobbered by a delayed >

Re: [Intel-gfx] [PATCH] drm/i915/vlv: drop punit freq staus read after setting idle

2014-06-06 Thread Jesse Barnes
On Fri, 6 Jun 2014 11:29:24 +0300 Ville Syrjälä wrote: > On Thu, Jun 05, 2014 at 01:49:34PM -0700, Jesse Barnes wrote: > > This may take awhile (~10ms), and we don't need to make noise about it. > > > > References: https://bugs.freedesktop.org/show_bug.cgi?id

[Intel-gfx] [PATCH] drm/i915/vlv: drop punit freq staus read after setting idle

2014-06-05 Thread Jesse Barnes
This may take awhile (~10ms), and we don't need to make noise about it. References: https://bugs.freedesktop.org/show_bug.cgi?id=75244 Tested-by: huax...@intel.com Signed-off-by: Jesse Barnes --- drivers/gpu/drm/i915/intel_pm.c | 4 1 file changed, 4 deletions(-) diff --git a/driver

[Intel-gfx] [PATCH 2/5] drm/i915: preserve swizzle settings if necessary v3

2014-06-05 Thread Jesse Barnes
framebuffer (Daniel) check display swizzle setting in detect_bit_6_swizzle (Daniel) use gen6 as cutoff point (Daniel) Reported-by: Kristian Høgsberg Signed-off-by: Jesse Barnes --- drivers/gpu/drm/i915/i915_drv.h| 1 + drivers/gpu/drm/i915/i915_gem.c| 3 +++ drivers/gpu/drm/i9

[Intel-gfx] [PATCH 3/5] drm: add drm_mode_same_size function

2014-06-05 Thread Jesse Barnes
From: Kristian Høgsberg Like mode_equal but w/o the clock checks. Useful for checking if modes are close enough to re-use to avoid a boot time mode set for example. Signed-off-by: Kristian Høgsberg Signed-off-by: Jesse Barnes --- drivers/gpu/drm/drm_modes.c | 8 include/drm

[Intel-gfx] [PATCH 4/5] drm/i915: use current mode if the size matches the preferred mode

2014-06-05 Thread Jesse Barnes
From: Kristian Høgsberg The BIOS may set a native mode that doesn't quite match the preferred mode timings. It should be ok to use however if it uses the same size, so try to avoid a mode set in that case. Signed-off-by: Kristian Høgsberg Signed-off-by: Jesse Barnes --- drivers/gpu/drm

[Intel-gfx] [PATCH 1/5] drm/i915: preserve SSC if previously set v2

2014-06-05 Thread Jesse Barnes
) Reported-by: Kristian Høgsberg Signed-off-by: Jesse Barnes --- drivers/gpu/drm/i915/i915_drv.h | 2 ++ drivers/gpu/drm/i915/intel_display.c | 11 ++- 2 files changed, 12 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h

[Intel-gfx] [PATCH 5/5] drm/i915: enable fastboot by default

2014-06-05 Thread Jesse Barnes
Let them eat mincemeat pie. Signed-off-by: Jesse Barnes --- drivers/gpu/drm/i915/i915_params.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_params.c b/drivers/gpu/drm/i915/i915_params.c index d05a2af..081ab2f 100644 --- a/drivers/gpu/drm

Re: [Intel-gfx] [PATCH] drm/i915: cache hw power well enabled state

2014-06-05 Thread Jesse Barnes
HW state to get rid of this delay. > > This fixes at least one reported regression where boot time increased by > ~4 seconds due to frequent power well state queries on VLV during eDP > EDID read. > > Reported-by: Jesse Barnes > Signed-off-by: Imre Deak > --- > dr

Re: [Intel-gfx] [RFC PATCH 2/2] drm/i915: respect the VBT minimum backlight brightness

2014-06-05 Thread Jesse Barnes
ack on (PWM first, delay, then backlight on). IIRC the issue on BYT was that we saw the panel power line go down when we disabled the backlight and PWM which would obviously cause all sorts of problems. But that could have been user error on the scope, so we shoul

[Intel-gfx] New async patch for resume

2014-06-05 Thread Jesse Barnes
In digging into the async crtc stuff, I found it was going to be really difficult to prevent other functions from getting clobbered by a delayed crtc enable or disable. Daniel's work to remove a bunch of the ->mode_set callbacks is a good start, but we still end up doing some reg reads and writes

Re: [Intel-gfx] [PATCH] drm/i915: Update bits to check in device class from VBT to detect eDP

2014-06-05 Thread Jesse Barnes
On Thu, 5 Jun 2014 16:09:29 +0300 Ville Syrjälä wrote: > On Thu, Jun 05, 2014 at 06:25:13PM +0530, Shobhit Kumar wrote: > > The DEVICE_TYPE_eDP has been changed to 0x1806 in case of BYT which > > can causes wrong detection failures for eDP. Reduce the number of bits > > of interest in DEVICE_TYPE

Re: [Intel-gfx] [PATCH] drm/i915: leave rc6 enabled at suspend time v4

2014-06-05 Thread Jesse Barnes
On Thu, 5 Jun 2014 11:21:02 +0200 Daniel Vetter wrote: > On Wed, Jun 04, 2014 at 01:45:22PM -0700, Jesse Barnes wrote: > > This allows the system to enter the lowest power mode during system freeze. > > > > v2: delete force wake timer at suspend (Imre) > > v3: add GT

[Intel-gfx] [PATCH] resume timings

2014-06-05 Thread Jesse Barnes
--- drivers/gpu/drm/i915/i915_drv.c | 6 ++ drivers/gpu/drm/i915/intel_display.c | 9 + 2 files changed, 15 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c index 0f9e836..a2036b2 100644 --- a/drivers/gpu/drm/i915/i915_drv.c +++ b/drive

[Intel-gfx] [PATCH] drm/i915: leave rc6 enabled at suspend time v4

2014-06-04 Thread Jesse Barnes
This allows the system to enter the lowest power mode during system freeze. v2: delete force wake timer at suspend (Imre) v3: add GT work suspend function (Imre) v4: use uncore forcewake reset (Daniel) Signed-off-by: Kristen Carlson Accardi Signed-off-by: Jesse Barnes --- drivers/gpu/drm/i915

[Intel-gfx] [PATCH] drm/i915: leave rc6 enabled at suspend time v3

2014-06-04 Thread Jesse Barnes
This allows the system to enter the lowest power mode during system freeze. v2: delete force wake timer at suspend (Imre) v3: add GT work suspend function (Imre) Signed-off-by: Kristen Carlson Accardi Signed-off-by: Jesse Barnes --- drivers/gpu/drm/i915/i915_drv.c | 4 ++-- drivers/gpu/drm

Re: [Intel-gfx] [PATCH] drm/i915: make CRTC enable/disable asynchronous v3

2014-05-30 Thread Jesse Barnes
On Fri, 30 May 2014 23:02:18 +0100 Chris Wilson wrote: > On Fri, May 30, 2014 at 02:28:52PM -0700, Jesse Barnes wrote: > > @@ -10326,7 +10466,7 @@ static int __intel_set_mode(struct drm_crtc *crtc, > > > > for_each_intel_crtc_masked(dev, prepare_pipes, intel_crtc)

[Intel-gfx] [PATCH] drm/i915: make CRTC enable/disable asynchronous v3

2014-05-30 Thread Jesse Barnes
ameters (Jesse) Signed-off-by: Jesse Barnes fix order of list add take mutex around sync in cursor_set --- drivers/gpu/drm/i915/i915_drv.c | 3 +- drivers/gpu/drm/i915/i915_drv.h | 12 ++- drivers/gpu/drm/i915/intel_display.c | 177 +++ drivers/gpu/d

Re: [Intel-gfx] [PATCH 4/4] drm/i915: make sure PC8 is enabled on suspend and disabled on resume

2014-05-30 Thread Jesse Barnes
On Fri, 30 May 2014 23:12:45 +0200 "Rafael J. Wysocki" wrote: > On Friday, May 30, 2014 11:29:15 AM Jesse Barnes wrote: > > On Fri, 30 May 2014 16:37:53 +0300 > > Imre Deak wrote: > > > > > On Thu, 2014-05-29 at 14:11 -0700, Jesse Barnes wrot

Re: [Intel-gfx] [PATCH 1/2] drm/i915: make CRTC enable/disable asynchronous v2

2014-05-30 Thread Jesse Barnes
On Fri, 30 May 2014 19:56:22 +0100 Chris Wilson wrote: > On Fri, May 30, 2014 at 11:05:21AM -0700, Jesse Barnes wrote: > > +static void intel_queue_crtc_enable(struct drm_crtc *crtc) > > +{ > > + struct drm_device *dev = crtc->dev; > > + struct drm_i915_privat

<    1   2   3   4   5   6   7   8   9   10   >