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
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
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
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
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
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;
> +}
&
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
___
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 =
> -
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
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
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
request->ctx ?
> +
> request->ctx->vm :
> +
> &dev_priv->gtt.base);
>
> if (HAS_BROKEN_CS_TLB(dev_priv->dev) &&
> ring->s
,
> 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
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
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
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
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
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
/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
@ -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
* 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
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 *
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_
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
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
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
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
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
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
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
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);
> }
>
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
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
; - 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
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
_STATUS) == (divider <<
> DISPLAY_FREQUENCY_STATUS_SHIFT),
> + 50))
> + DRM_ERROR("timed out waiting for CDclk change\n");
> mutex_unlock(&dev_priv->dpio_lock);
> }
>
Seems rea
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:
> - 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
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
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
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
>
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
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
> > ---
>
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
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
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
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
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
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
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
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.
>
>
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
ork suspend function (Imre)
> > > > > v4: use uncore forcewake reset (Daniel)
> > > > >
> > > > > Signed-off-by: Kristen Carlson Accardi
> > > > > Signed-off-by: Jesse Barnes
> > > > > ---
> > > > > d
, 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
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
> >>
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:
&
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
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:
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
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
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
>
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
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
>
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
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
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
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
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
)
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
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
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
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
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
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
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
---
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
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
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
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)
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
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
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
501 - 600 of 3350 matches
Mail list logo