Re: [Intel-gfx] 3.13 i915 brightness settings broken when going from docked - undocked

2014-02-23 Thread Josh Boyer 
On Thu, Feb 20, 2014 at 07:31:41PM -0500, Josh Boyer wrote:
On Wed, Feb 19, 2014 at 9:20 PM, Josh Boyer jwbo...@fedoraproject.org wrote:
 Hi All,

 We've had a rather weird report[1] of the brightness adjustments being
 broken in a specific case with Thinkpad x220 hardware (SandyBridge
 based).  If you boot the machine with it in a dock and then undock,
 the brightness adjustments do not work.  That is with either the FN
 keys or the GNOME brightness slider.

 I can see that the value of
 /sys/class/backlight/acpi_video0/brightness increases/decreases but
 /sys/class/backlight/intel_backlight/brightness doesn't reflect any
 changes.  With 3.12 this works, and oddly with 3.14-rc1 it works
 (specifically, it starts working around v3.13-10231-g53d8ab2 which is
 right after the first DRM merge for 3.14).  With 3.13, if I undock and
 echo a higher value in the intel_backlight_brightness sysfs entry, the
 brightness will actually increase so it can be done manually, but it
 does not work as you'd expect.

 I'm in the middle of trying to do a reverse bisect for which patch
 fixes it in the 3.14-rcX series, but that's taking a while.  I thought
 I'd email and see if anyone already knows about this situation, what
 patch in 3.13 broke this, and which one then fixed it again.  Thus far
 all I've gathered is that backlight handling is confusing.

The reverse bisect between 3.13 and 3.14-rc1 didn't prove fruitful,
either because I messed it up or there's a combination of things that
fix the issue.  So instead I did a regular git bisect between 3.12 and
3.13 to see which commit _broke_ things and caused the above behavior.
 That landed me at:

Author: Jesse Barnes jbar...@virtuousgeek.org
Date:   Thu Oct 31 18:55:49 2013 +0200

drm/i915: make backlight functions take a connector

I have no idea if that makes sense or not, but it's at least something
that seems to be in a relevant area of code.  Does anyone involved in
that know why it would cause the above symptoms on 3.13, and which
commit(s) fix it in 3.14-rc1?

Since nobody is replying I poked around a bit myself.  The one commit
that looks somewhat relevant in 3.14-rc1 seems to be:

commit c91c9f32843a1b433de5a1ead4789a6bc8d3d914
Author: Jani Nikula jani.nik...@intel.com
Date:   Fri Nov 8 16:48:55 2013 +0200

drm/i915: make asle notifications update backlight on all connectors

That doesn't apply cleanly on 3.13 because of the other reworks that
went in first, so I came up with the patch below.  It seems to fix it
for my machine, but I'm waiting for confirmation from the original bug
reporter still.  Maybe this will elicit some comments?

josh

Backport of upstream commit c91c9f328

---
 drivers/gpu/drm/i915/i915_drv.h   |  1 +
 drivers/gpu/drm/i915/intel_opregion.c | 31 ++-
 drivers/gpu/drm/i915/intel_panel.c|  4 
 3 files changed, 11 insertions(+), 25 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 221ac62..d6d4349 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1371,6 +1371,7 @@ typedef struct drm_i915_private {
 
/* backlight */
struct {
+   bool present;
int level;
bool enabled;
spinlock_t lock; /* bl registers and the above bl fields */
diff --git a/drivers/gpu/drm/i915/intel_opregion.c 
b/drivers/gpu/drm/i915/intel_opregion.c
index 6d69a9b..b2a51ae 100644
--- a/drivers/gpu/drm/i915/intel_opregion.c
+++ b/drivers/gpu/drm/i915/intel_opregion.c
@@ -414,38 +414,19 @@ static u32 asle_set_backlight(struct drm_device *dev, u32 
bclp)
return ASLC_BACKLIGHT_FAILED;
 
mutex_lock(dev-mode_config.mutex);
-   /*
-* Could match the OpRegion connector here instead, but we'd also need
-* to verify the connector could handle a backlight call.
-*/
-   list_for_each_entry(encoder, dev-mode_config.encoder_list, head)
-   if (encoder-crtc == crtc) {
-   found = true;
-   break;
-   }
-
-   if (!found) {
-   ret = ASLC_BACKLIGHT_FAILED;
-   goto out;
-   }
 
-   list_for_each_entry(connector, dev-mode_config.connector_list, head)
-   if (connector-encoder == encoder)
-   intel_connector = to_intel_connector(connector);
-
-   if (!intel_connector) {
-   ret = ASLC_BACKLIGHT_FAILED;
-   goto out;
+   DRM_DEBUG_KMS(updating opregion backlight %d/255\n, bclp);
+   list_for_each_entry(connector, dev-mode_config.connector_list, head) {
+   intel_connector = to_intel_connector(connector);
+   if (dev_priv-backlight.present)
+   intel_panel_set_backlight(intel_connector, bclp, 255);
}
 
-   DRM_DEBUG_KMS(updating opregion backlight %d/255\n, bclp);
-   intel_panel_set_backlight(intel_connector,

Re: [Intel-gfx] [PATCH] i965: Use default contexts when possible.

2014-02-23 Thread Ben Widawsky 
On Thu, Jan 02, 2014 at 07:50:35PM -1000, Ben Widawsky wrote:
 Will full PPGTT support it can be assumed that every file descriptor
 gets its own hardware context. As such, there is no need to allocate
 anew context in order to use the features provided by hardware contexts.
 Eliminating this extra context allocation saves both physical memory
 (currently PPGTT pages are pinned forever), GGTT space on IVB, and HSW,
 as well as the associated startup cost of allocating the second context
 - which can include an eviction in pathological cases.
 
 Unfortunately, this requires a libdrm version bump as it requires a new
 interface.
 
 NOTE: I am uncertain if the share context idea is valid. Needs mesa
 eyes.
 
 Cc: Kenneth Graunke kenneth.w.grau...@intel.com
 Signed-off-by: Ben Widawsky b...@bwidawsk.net

Hi Ken/whomever. Everything but the actual exposing of the full PPGTT
param from this series has been merged. If you can give me a pointer on
what needs doing here in mesa, I'll try again now that full PPGTT is
available in dinq.

Thanks.

 ---
  configure.ac| 2 +-
  src/mesa/drivers/dri/i965/brw_context.c | 9 -
  2 files changed, 9 insertions(+), 2 deletions(-)
 
 diff --git a/configure.ac b/configure.ac
 index f75325d..a0ae0b3 100644
 --- a/configure.ac
 +++ b/configure.ac
 @@ -29,7 +29,7 @@ AC_SUBST([OSMESA_VERSION])
  dnl Versions for external dependencies
  LIBDRM_REQUIRED=2.4.24
  LIBDRM_RADEON_REQUIRED=2.4.50
 -LIBDRM_INTEL_REQUIRED=2.4.49
 +LIBDRM_INTEL_REQUIRED=2.4.51
  LIBDRM_NVVIEUX_REQUIRED=2.4.33
  LIBDRM_NOUVEAU_REQUIRED=2.4.33 libdrm = 2.4.41
  LIBDRM_FREEDRENO_REQUIRED=2.4.39
 diff --git a/src/mesa/drivers/dri/i965/brw_context.c 
 b/src/mesa/drivers/dri/i965/brw_context.c
 index 78c06fc..f5a66e1 100644
 --- a/src/mesa/drivers/dri/i965/brw_context.c
 +++ b/src/mesa/drivers/dri/i965/brw_context.c
 @@ -674,7 +674,14 @@ brwCreateContext(gl_api api,
  
 intel_fbo_init(brw);
  
 -   if (brw-gen = 6) {
 +   /* We assume that the hw_ctx is the first created for the file descriptor 
 if
 +* this is not a share context. If that assumption turns false then we'll
 +* end up having hw_ctx for two contexts using the same actual context.
 +*/
 +   if (!shareCtx)
 +  brw-hw_ctx = drm_intel_gem_default_context_get(brw-bufmgr);
 +
 +   if (!brw-hw_ctx  brw-gen = 6) {
/* Create a new hardware context.  Using a hardware context means that
 * our GPU state will be saved/restored on context switch, allowing us
 * to assume that the GPU is in the same state we left it in.
 -- 
 1.8.5.2
 
 ___
 Intel-gfx mailing list
 Intel-gfx@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Ben Widawsky, 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 5/5] drm/i915: Allow vblank interrupts during modeset and eliminate some vblank races

2014-02-23 Thread Michel Dänzer 
On Fre, 2014-02-21 at 21:03 +0200, ville.syrj...@linux.intel.com wrote:
 
 We can kill of the drm_vblank_{pre,post}_modeset() calls since those are
 there simply to make drm_vblank_get() fail during a modeset.

Actually, their original purpose was to keep the DRM vblank counter
consistent across modesets, assuming the modeset resets the hardware
vblank counter.


-- 
Earthling Michel Dänzer|  http://www.amd.com
Libre software enthusiast  |Mesa and X developer

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 0/6] Intel Color Manager Framework

2014-02-23 Thread Stéphane Marchesin 
On Fri, Feb 21, 2014 at 7:49 PM, Sharma, Shashank shashank.sha...@intel.com
 wrote:

On Thu, Feb 20, 2014 at 5:11 AM, Ville Syrjälä 
 ville.syrj...@linux.intel.com wrote:

 On Thu, Feb 20, 2014 at 06:07:21PM +0530, Shashank Sharma wrote:
  Color manager is a new framework in i915 driver, which provides
  a unified interface for various color correction methods supported
  by intel hardwares. The high level overview of this change is:

 Would have been good to discuss this idea before implementing it. The
 plan is to use kms properties for this kind of stuff which allows us
 to hook it up with the upcoming atomic modeset API. Just yesterday there
 was some discussion on #dri-devel about exposing user settable blob
 properties even before the atomic modeset API lands (it was always the
 plan for the atomic modeset API anyway). So based on a cursory glance,
 this looks like it's going in the wrong direction.



 +1. We'e looking into hooking up color correction controls, and if the
 interface isn't standard our user space won't be portable across drivers.
 There are multiple reasons for using drm properties:

 - the KMS interface already provides a way to set the gamma ramp, which
 this code seems to replicate.



 The current KMS interface just initializes the gamma soft LUT palette
 registers, in 8 bit mode corresponding to unit gamma. It's impossible to
 apply accurate values corresponding to gamma=2.2 or 1.5 from KMS

 Because for that we need to program palette registers in 10.6 bit mode of
 hardware.


Then the existing interface should be extended. Otherwise you have two ways
to do the same thing...



   - the KMS interface allows us to name properties independently and
 enumerate them. It seems like right now you can't enumerate properties or
 guess what property 0 is. I'd rather set the Color conversion matrix
 than remember to set property 0 (and even then, I'm not really sure it
 exists).



 All the properties are getting enumerated in color manager register
 function. The framework defines proper identifiers and mapping for each
 property, and every property is having a corresponding soft-lut to be
 loaded with correction values.


Correct me if I'm wrong, but I don't see a way for user space to query the
presence/absence of a given property. KMS allows that.





 - you can reuse the get/set infrastructure which is already in place





 Another thing that came out of the discussion on irc is that we should
 standardize the properties. For example we could use a text file describing
 the name of the controls and the format of the data (something similar to
 the device tree bindings). That way user space can expect color
 conversion matrix to mean the same thing everywhere, to get the same data
 as input, and to work the same way on all platforms.

 If you can please have a look on the header file, we are almost doing the
 same thing, in form of a protocol.


This protocol however is not extensible. With the KMS interface I can
already do the following from user space:
- query the existence of a given property
- set each property in a portable fashion (for example the same gamma ramp
code works on all DRM drivers)
- easily match properties to a given crtc

Stéphane
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RFC 1/6] drm/i915: cover ioctls with runtime_get/put

2014-02-23 Thread Naresh Kumar Kachhi 

On 01/24/2014 09:26 PM, Paulo Zanoni wrote:

2014/1/24 Naresh Kumar Kachhi naresh.kumar.kac...@intel.com:

On 01/22/2014 06:53 PM, Imre Deak wrote:

On Wed, 2014-01-22 at 13:51 +0100, Daniel Vetter wrote:

On Wed, Jan 22, 2014 at 05:34:17PM +0530, naresh.kumar.kac...@intel.com
wrote:

From: Naresh Kumar Kachhi naresh.kumar.kac...@intel.com

With runtime PM enabled, we need to make sure that all HW access
are valid (i.e.  Gfx is in D0). Invalid accesses might end up in
HW hangs. Ex. A hang is seen if display register is accessed on
BYT while display power island is power gated.

This patch is covering all the IOCTLs with get/put.
TODO: limit runtime_get/put to IOCTLs that accesses HW

Signed-off-by: Naresh Kumar Kachhi naresh.kumar.kac...@intel.com

Nack on the concept. We need to have get/put calls for the individual
functional blocks of the hw, which then in turn (if it's not the top-level
power domain) need to grab references to the next up power domain.
Splattering unconditional get/puts over all driver entry points is bad
style and imo also too fragile.

Also, with Paulos final runtime pm/pc8 unification patches and Imre's
display power well patches for byt we should have full coverage already.
Have you looked at the work of these too?

I'm still in debt with the BYT specific power domain patches, I want to
post them (this week) after I sorted out spurious pipe stat IRQs we'd
receive atm with the power well off. Until then there is only the WIP
version at: https://github.com/ideak/linux/commits/powerwells

But in practice, as you point out the plan was to only call
modeset_update_power_wells() during modeset time and that will end up
doing the proper RPM get/put as necessary. Similarly on some other code
paths like connector detect and HW state read-out code, we'd ask only
for the needed power domains which would end up doing the RPM get/put.

--Imre

Hi Imre,
I tried to go through your and Paulo's patches
(http://patchwork.freedesktop.org/patch/16952/).
As per my understanding we are doing disp power well gate/ungate independent
of we are in
runtime_suspend/resume state we might face problem here as on BYT interrupts
are routed through
display power well, so we might have a situation where display power island
is power gated,
but render workload is still active. As we won't be receiving any interrupt
__wait_seq_no will
stall and we might end up in a TDR. We will not see the issue until display
power gating is
enabled. I will try to include a test to cover this test

This can be avoided by adding display_get/put in runtime_resume/suspend.
I am not sure if this scenario will be applicable for HSW.

Need for covering ioclts:
However there is one more problem for LP platforms. Once
display/render/media power
islands are power gated, system will enter into deeper sleep state causing
Gunit to power
gate. We will loose the state once Gunit resumes, so Gunit restore and ring
initialization is
required in runtime_resume. Even after adding these to
runtime_suspend/resume, we will have
to make sure all the ring activities, Gunit register accesses are covered
with runtime_get/put.
There are few places with current implementation where we might hit this
problem.
Example:
i915_batchbuffer(ioctl)-i915_batchbuffer (gpu commands scheduled)
i915_irq_emit(ioctl) - i915_emit_irq (gpu commands scheduled)
i915_cmdbuffer (ioctl) - i915_dispatch_cmdbuffer- i915_emit_cmds(gpu
commands scheduled)
There are few more.
These ioclts not being covered with runtime_get/put will might cause invalid
executions
if we are resuming for deeper power state (gunit was powergated).

If possible, please write pm_pc8.c subtests that reproduce all these
problems you found :)


Above scenarios are only valid for non-KMS mode. I missed it, so looks like
we should be fine with the current implementation and your outstanding patches


solutions:
 From design perspective, we can cover all accesses at low level, but this
means a lot of get/put
and also will have to make sure that we cover future accesses as well. As an
other solution we
can cover these ioctls individually or can have a wrapper function (as
purposed in this patch)
to cover the accesses (TODO: make them conditional to do get/put on few
ioclts only).
I will try to upload refined patch with conditional get/put.

Thanks,
Naresh












___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx






___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RFC 3/6] drm/i915: introduce runtime get/put based on display activity

2014-02-23 Thread Naresh Kumar Kachhi 

On 01/22/2014 07:10 PM, Paulo Zanoni wrote:

Hi

2014/1/22  naresh.kumar.kac...@intel.com:

From: Naresh Kumar Kachhi naresh.kumar.kac...@intel.com

Once the display is disabled, we need to call runtime_put to
make sure Runtime framework triggers runtime_suspend based on
idleness. Similarly when display gets enabled, runtime_get should
be called. We have similiar function for pc8 feature, but some
platform(BYT) might not have pc8 feature, so creating a generic
function for runtime_pm

Does this patch series help you somehow?
http://lists.freedesktop.org/archives/intel-gfx/2013-December/037721.html


Yes, this patch series helps here. Do we know when these patches will
bemerged to nightly build?


Signed-off-by: Naresh Kumar Kachhi naresh.kumar.kac...@intel.com
---
  drivers/gpu/drm/i915/i915_drv.h  |  2 ++
  drivers/gpu/drm/i915/intel_drv.h |  1 +
  drivers/gpu/drm/i915/intel_pm.c  | 50 
  3 files changed, 53 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index d1399f9..6a6f046 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1325,6 +1325,8 @@ struct i915_package_c8 {
  struct i915_runtime_pm {
 bool suspended;
 bool gpu_idle;
+   bool disp_idle;
+   struct mutex lock;
  };

  enum intel_pipe_crc_source {
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 9061aa7..94a6127 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -887,6 +887,7 @@ void intel_init_runtime_pm(struct drm_i915_private 
*dev_priv);
  void intel_fini_runtime_pm(struct drm_i915_private *dev_priv);
  void intel_runtime_pm_gpu_busy(struct drm_i915_private *dev_priv);
  void intel_runtime_pm_gpu_idle(struct drm_i915_private *dev_priv);
+void intel_runtime_update_disp_state(struct drm_i915_private *dev_priv);
  void ilk_wm_get_hw_state(struct drm_device *dev);


diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 991ff62..9d6d0e1 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -5501,6 +5501,54 @@ void intel_runtime_pm_gpu_busy(struct drm_i915_private 
*dev_priv)
 }
  }

+static void intel_runtime_pm_disp_idle(struct drm_i915_private *dev_priv)
+{
+   if (!HAS_RUNTIME_PM(dev_priv-dev))
+   return;
+
+   mutex_lock(dev_priv-pm.lock);
+   if (!dev_priv-pm.disp_idle) {
+   dev_priv-pm.disp_idle = true;
+   intel_runtime_pm_put(dev_priv);
+   }
+   mutex_unlock(dev_priv-pm.lock);
+}
+
+static void intel_runtime_pm_disp_busy(struct drm_i915_private *dev_priv)
+{
+   if (!HAS_RUNTIME_PM(dev_priv-dev))
+   return;
+
+   mutex_lock(dev_priv-pm.lock);
+   if (dev_priv-pm.disp_idle) {
+   dev_priv-pm.disp_idle = false;
+   /* This call is coming from an IOCTL so we have already done a
+* get_sync. get_noresume should suffice here
+*/
+   intel_runtime_pm_get_noresume(dev_priv);
+   }
+   mutex_unlock(dev_priv-pm.lock);
+}
+
+void intel_runtime_update_disp_state(struct drm_i915_private *dev_priv)
+{
+   struct drm_device *dev = dev_priv-dev;
+   struct intel_crtc *crtc;
+   bool enabled = false;
+
+   if (!HAS_RUNTIME_PM(dev_priv-dev))
+   return;
+
+   list_for_each_entry(crtc, dev-mode_config.crtc_list, base.head)
+   enabled |= crtc-base.enabled;
+
+   if (enabled)
+   intel_runtime_pm_disp_busy(dev_priv);
+   else
+   intel_runtime_pm_disp_idle(dev_priv);
+
+}
+
  void intel_runtime_pm_get(struct drm_i915_private *dev_priv)
  {
 struct drm_device *dev = dev_priv-dev;
@@ -5547,6 +5595,8 @@ void intel_init_runtime_pm(struct drm_i915_private 
*dev_priv)

 dev_priv-pm.suspended = false;
 dev_priv-pm.gpu_idle = true;
+   dev_priv-pm.disp_idle = true;
+   mutex_init(dev_priv-pm.lock);

 if (!HAS_RUNTIME_PM(dev))
 return;
--
1.8.1.2

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx





___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RFC 1/6] drm/i915: cover ioctls with runtime_get/put

2014-02-23 Thread Naresh Kumar Kachhi 

On 02/22/2014 01:37 AM, Jesse Barnes wrote:

On Fri, 24 Jan 2014 19:23:54 +0200
Imre Deak imre.d...@intel.com wrote:


On Fri, 2014-01-24 at 20:35 +0530, Naresh Kumar Kachhi wrote:

On 01/22/2014 06:53 PM, Imre Deak wrote:


On Wed, 2014-01-22 at 13:51 +0100, Daniel Vetter wrote:

On Wed, Jan 22, 2014 at 05:34:17PM +0530, naresh.kumar.kac...@intel.com wrote:

From: Naresh Kumar Kachhi naresh.kumar.kac...@intel.com

With runtime PM enabled, we need to make sure that all HW access
are valid (i.e.  Gfx is in D0). Invalid accesses might end up in
HW hangs. Ex. A hang is seen if display register is accessed on
BYT while display power island is power gated.

This patch is covering all the IOCTLs with get/put.
TODO: limit runtime_get/put to IOCTLs that accesses HW

Signed-off-by: Naresh Kumar Kachhi naresh.kumar.kac...@intel.com

Nack on the concept. We need to have get/put calls for the individual
functional blocks of the hw, which then in turn (if it's not the top-level
power domain) need to grab references to the next up power domain.
Splattering unconditional get/puts over all driver entry points is bad
style and imo also too fragile.

Also, with Paulos final runtime pm/pc8 unification patches and Imre's
display power well patches for byt we should have full coverage already.
Have you looked at the work of these too?

I'm still in debt with the BYT specific power domain patches, I want to
post them (this week) after I sorted out spurious pipe stat IRQs we'd
receive atm with the power well off. Until then there is only the WIP
version at: https://github.com/ideak/linux/commits/powerwells

But in practice, as you point out the plan was to only call
modeset_update_power_wells() during modeset time and that will end up
doing the proper RPM get/put as necessary. Similarly on some other code
paths like connector detect and HW state read-out code, we'd ask only
for the needed power domains which would end up doing the RPM get/put.

--Imre


Hi Imre,
I tried to go through your and Paulo's patches 
(http://patchwork.freedesktop.org/patch/16952/).
As per my understanding we are doing disp power well gate/ungate independent of 
we are in
runtime_suspend/resume state we might face problem here as on BYT interrupts 
are routed through
display power well, so we might have a situation where display power island is 
power gated,
but render workload is still active. As we won't be receiving any interrupt 
__wait_seq_no will
stall and we might end up in a TDR. We will not see the issue until display 
power gating is
enabled. I will try to include a test to cover this test

Hm, which exact interrupt routing are you referring to? At least on my
BYT I manage to power off only the display power well and keep the
render well on, while still being able to run for example
igt/tests/gem_render_copy, gem_render_linear_blits. I can see that
through /proc/interrupts that GT interrupts are properly generated. The
display side interrupt routing is of course off, for example the
PIPESTAT registers will read all 0x, but DEIIR, DEIMR, DEISR are
all seem to work ok.

I think Naresh is referring to full D3 state shutdown, where the Gunit
goes away too.  But in that case the GT will be shut down as well, so I
don't think the display vs GT thing by itself is a problem.


Please ignore my previous comment as I confused interrupts being routed through 
display unit on VLV.
But this comment will be valid on some platforms like HSW, where render 
interrupts are routed
through display unit. So, display power gating in such platforms has to be done 
by taking
render/media also into consideration.
-Naresh

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [Xen-devel] [Announcement] Updates to XenGT - a Mediated Graphics Passthrough Solution from Intel

2014-02-23 Thread Pasi Kärkkäinen 
On Thu, Feb 20, 2014 at 07:59:04AM +, Cui, Dexuan wrote:
 Hi all,
 We're pleased to announce an update to XenGT since its first disclosure in 
 last Sep. XenGT is a full GPU virtualization solution with mediated 
 pass-through, on Intel Processor Graphics. A virtual GPU instance is 
 maintained for each VM, with part of performance critical resources directly 
 assigned. The capability of running native graphics driver inside a VM, 
 without hypervisor intervention in performance critical paths, achieves a 
 good balance among performance, feature, and sharing capability. Though we 
 only support Xen on Intel Processor Graphics so far, the core logic can be 
 easily ported to other hypervisors.
 
 The update consists of:
 
 Linux-vgt:
 Rebased to kernel 3.11.6 
 Lots of stability fixes
 Improved sharing quality of render engine and display engine
 Multi-monitors (clone/extended) support for VGA, HDMI, DP and eDP types
 Support VMs with different resolutions
 Improved monitor hotplug handling
 Preliminary support for GPU recovery
 
 Xen-vgt:
 Rebased to Xen 4.3.1
 8 bytes MMIO emulation
 
 Qemu-vgt:
 Included VT-d GPU pass-through logic for comparison
 Grub2 graphics mode works now
 
 Please refer to the attached new setup guide:
 https://github.com/01org/XenGT-Preview-kernel/blob/master/XenGT_Setup_Guide.pdf
 It provides step-to-step details about building/configuring/running XenGT.
 
 The new source codes are available at the updated github repos:
 Linux: https://github.com/01org/XenGT-Preview-kernel.git
 Xen: https://github.com/01org/XenGT-Preview-xen.git
 Qemu: https://github.com/01org/XenGT-Preview-qemu.git
 
 More information about XenGT's background, architecture, etc can be found at:
 http://events.linuxfoundation.org/sites/events/files/slides/XenGT-Xen%20Summit-v7.pdf
 https://01.org/xen/blogs/srclarkx/2013/graphics-virtualization-xengt
 
 Appreciating your comments!
 

First of all: Very nice, thanks a lot for sharing this! 

Are you going to work on upstreaming this stuff? Xen 4.4 will be released 
soon(ish),
so the Xen 4.5 development window starts in the near future and hopefully this 
stuff can be upstreamed then.. 

Also: Haswell (4th generation Intel core CPU) is listed as a requirement in 
the Setup Guide PDF.. 
will there be support for SNB/IVB GPUs aswell? 


Thanks,

-- Pasi

 Thanks,
 -- Dexuan
 
  -Original Message-
  From: xen-devel-boun...@lists.xen.org
  [mailto:xen-devel-boun...@lists.xen.org] On Behalf Of Shan, Haitao
  Sent: Monday, September 09, 2013 8:46 PM
  To: xen-de...@lists.xen.org
  Cc: Tian, Kevin; White, Michael L; Dong, Eddie; Li, Susie; Cowperthwaite,
  David J; Haron, Sandra
  Subject: [Xen-devel] [RFC] XenGT - An Mediated Graphics Passthrough
  Solution from Intel
  
  Hi, Xen Experts,
  
  This email is aimed at a first time disclosure of project XenGT, which is
  a Graphics virtualization solution based on Xen.
  
  
  
  As you can see, requirements for GPU to be sharable among virtual machines
  have been constantly rising. The targeted usage model might be
  accelerating tasks ranging from gaming, video playback, fancy GUIs,
  high-performance computing (GPU-based). This trend is observed on both
  client and cloud. Efficient GPU virtualization is required to address the
  increasing demands.
  
  
  We have developed XenGT - a prototype based on a mediated passthrough
  architecture. We support running a native graphics driver in multiple VMs
  to achieve high performance. A specific mediator owns the scheduling and
  sharing hardware resources among all the virtual machines. By saying
  mediated pass-through, we actually divide graphics resource to two
  categories: performance critical and others. We partition performance
  critical resources for VM's direct access like pass-through, while save
  and restore others.
  
  
  
  XenGT implements the mediator in dom0, called vgt driver. This avoids
  adding complex device knowledge to Xen, and also permits a more flexible
  release model. In the meantime, we want to have a unified architecture to
  mediate all the VMs, including dom0. Thus, We developed a deprivileged
  dom0 mode, which essentially trapped Dom0's access to selected resources
  (graphics resources in XenGT case) and forwarded to vgt driver (which is
  also in Dom0) for processing.
  
  
  Right now, we support 4 accelerated VMs: Dom0 + 3 HVM DomUs. We've
  conducted verifications based on Ubuntu 12.04 and 13.04. Tests conducted
  in VM include but are not limited to 3D gaming, media playbacks, 2D
  accelerations.
  
  We believe the architecture itself can be general so that different GPUs
  can all use this mediated passthrough concept. However, we only developed
  codes based on Intel 4th Core Processor with integrated Graphics.
  
  If you have interests in trying, you can refer to the attached setup
  guide, which provides step-to-step details on building/configuring/running
  XenGT.

Re: [Intel-gfx] [Xen-devel] [Announcement] Updates to XenGT - a Mediated Graphics Passthrough Solution from Intel

2014-02-23 Thread Pasi Kärkkäinen 
On Fri, Feb 21, 2014 at 02:22:11AM +, Cui, Dexuan wrote:
 Pasi Kärkkäinen wrote on 2014-02-21:
  On Thu, Feb 20, 2014 at 07:59:04AM +, Cui, Dexuan wrote:
  Hi all,
  We're pleased to announce an update to XenGT since its first disclosure in
  last Sep.
  
  Are you going to work on upstreaming this stuff? Xen 4.4 will be
  released soon(ish), so the Xen 4.5 development window starts in the near
  future and hopefully this stuff can be upstreamed then..
 Hi Pasi,
 We do plan to upstream but not give a timeframe so far.
 

Ok. Would you like to post an article on the Xen blog about XenGT ?
I think that would be a good thing to do to get more visibility for this 
feature.


  Also: Haswell (4th generation Intel core CPU) is listed as a requirement 
  in
  the Setup Guide PDF..
  will there be support for SNB/IVB GPUs aswell?
 There is no plan for SNB/IVB.
 

Is that because of some hardware limitation on earlier GPU generations,
or just a matter of amount of work needed to support XenGT on earlier GPUs?

Thanks,

-- Pasi

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx