I know. That is orthogonal to the tweaks I was suggesting. Also if you
feel you need to add details to your rationale, then your changelog is
incomplete.
-Chris
Thanks Chris,
Please find my comments inline to your previous mail, with suggestions.
On 8/12/2014 6:17 PM, Chris Wilson wrote:
On Wed, Aug 13, 2014 at 11:34:02AM +0530, Sharma, Shashank wrote:
I know. That is orthogonal to the tweaks I was suggesting. Also if you
feel you need to add details to your rationale, then your changelog is
incomplete.
-Chris
Thanks Chris,
Please find my comments inline to your
On Tue, Aug 12, 2014 at 07:39:55PM +0300, ville.syrj...@linux.intel.com wrote:
/* Check for which cursor types we support */
- if (!((width == 64 height == 64) ||
- (width == 128 height == 128 !IS_GEN2(dev)) ||
- (width == 256 height == 256
On Tue, Aug 12, 2014 at 07:39:55PM +0300, ville.syrj...@linux.intel.com wrote:
/* Check for which cursor types we support */
- if (!((width == 64 height == 64) ||
- (width == 128 height == 128 !IS_GEN2(dev)) ||
- (width == 256 height == 256
On Tue, Aug 12, 2014 at 07:39:55PM +0300, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
845/865 support different cursor sizes as well, albeit a bit differently
than later platforms. Add the necessary code to make them work.
Untested due to lack of
On 8/13/2014 11:46 AM, Chris Wilson wrote:
On Wed, Aug 13, 2014 at 11:34:02AM +0530, Sharma, Shashank wrote:
I know. That is orthogonal to the tweaks I was suggesting. Also if you
feel you need to add details to your rationale, then your changelog is
incomplete.
-Chris
Thanks Chris,
Please
On Tue, Aug 12, 2014 at 09:51:13PM +0100, Chris Wilson wrote:
On Tue, Aug 12, 2014 at 10:37:21PM +0200, Daniel Vetter wrote:
On Tue, Aug 12, 2014 at 10:30 PM, Chris Wilson ch...@chris-wilson.co.uk
wrote:
On Tue, Aug 12, 2014 at 10:19:20PM +0200, Daniel Vetter wrote:
On Tue, Aug 12,
From: Ville Syrjälä ville.syrj...@linux.intel.com
845/865 support different cursor sizes as well, albeit a bit differently
than later platforms. Add the necessary code to make them work.
Untested due to lack of hardware.
v2: Warn but accept invalid stride (Chris)
Rewrite the cursor size
Make backlight class sysfs bl_power a sub-state of backlight enabled, if
a backlight power connector callback is defined. It's up to the
connector callback to handle the sub-state, typically in a way that
respects panel power sequencing.
v2: Post the version that does not oops. *facepalm*.
If the VT we are using is already in KD_GRAPHICS mode, calling SETACTIVE
will silently fail. This leads to an indefinite hang as WAITACTIVE never
returns causing lockups on boot. This issue becomes apparent when the
kernel driver does not install a fbdev for kernel to use for consoles
and plymouth
As we use WC updates of the PTE, we are responsible for notifying the
hardware when to flush its TLBs. Do so after we zap all the PTEs before
suspend (and the BIOS tries to read our GTT).
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/i915_drv.h | 2 +-
From: Daniel Vetter daniel.vet...@ffwll.ch
That's right, back to where it was!
This effectively reverts
commit 9aa2062bb850e665b3b673b53bd90127d1215490
Author: Daniel Vetter daniel.vet...@ffwll.ch
Date: Wed Aug 6 15:04:46 2014 +0200
drm/i915: Move i915_gem_chipset_flush to where it
On Tue, Aug 12, 2014 at 03:15:17PM +0100, Chris Wilson wrote:
Rather than take and release the console_lock() around a non-existent
DRM_I915_FBDEV, move the lock acquisation into the callee where it will
be compiled out by the config option entirely. This includes moving the
deferred
On Wed, Aug 13, 2014 at 11:51:54AM +0100, Chris Wilson wrote:
As we use WC updates of the PTE, we are responsible for notifying the
hardware when to flush its TLBs. Do so after we zap all the PTEs before
suspend (and the BIOS tries to read our GTT).
Signed-off-by: Chris Wilson
On Wed, Aug 13, 2014 at 01:26:40PM +0200, Daniel Vetter wrote:
On Tue, Aug 12, 2014 at 03:15:17PM +0100, Chris Wilson wrote:
Rather than take and release the console_lock() around a non-existent
DRM_I915_FBDEV, move the lock acquisation into the callee where it will
be compiled out by the
On Wed, Aug 13, 2014 at 11:51:55AM +0100, Chris Wilson wrote:
From: Daniel Vetter daniel.vet...@ffwll.ch
That's right, back to where it was!
This effectively reverts
Hm, why?
-Daniel
commit 9aa2062bb850e665b3b673b53bd90127d1215490
Author: Daniel Vetter daniel.vet...@ffwll.ch
Date:
On Wed, Aug 13, 2014 at 11:57:05AM +0300, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
845/865 support different cursor sizes as well, albeit a bit differently
than later platforms. Add the necessary code to make them work.
Untested due to lack of
On Wed, Aug 13, 2014 at 12:32:33PM +0100, Chris Wilson wrote:
On Wed, Aug 13, 2014 at 01:26:40PM +0200, Daniel Vetter wrote:
On Tue, Aug 12, 2014 at 03:15:17PM +0100, Chris Wilson wrote:
Rather than take and release the console_lock() around a non-existent
DRM_I915_FBDEV, move the lock
On Wed, Aug 13, 2014 at 12:14:12PM +0100, Chris Wilson wrote:
Ville pointed out the GCCism __builtin_types_compatible_p() that we
could use to replace our heavily casted presumption __I915__ macro that
was based on comparing struct sizes.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
On Wed, Aug 13, 2014 at 01:32:31PM +0200, Daniel Vetter wrote:
On Wed, Aug 13, 2014 at 11:51:55AM +0100, Chris Wilson wrote:
From: Daniel Vetter daniel.vet...@ffwll.ch
That's right, back to where it was!
This effectively reverts
Hm, why?
Becuase it doesn't belong in i915_gem_gtt.c
On Wed, Aug 13, 2014 at 01:32:08PM +0200, Daniel Vetter wrote:
On Wed, Aug 13, 2014 at 11:51:54AM +0100, Chris Wilson wrote:
As we use WC updates of the PTE, we are responsible for notifying the
hardware when to flush its TLBs. Do so after we zap all the PTEs before
suspend (and the BIOS
On Wed, Aug 13, 2014 at 01:39:22PM +0200, Daniel Vetter wrote:
On Wed, Aug 13, 2014 at 12:32:33PM +0100, Chris Wilson wrote:
On Wed, Aug 13, 2014 at 01:26:40PM +0200, Daniel Vetter wrote:
This one here must be synchronous.
Right, but notice that we synchronize the work afterwards. I
On Wed, Aug 13, 2014 at 01:39:22PM +0200, Daniel Vetter wrote:
On Wed, Aug 13, 2014 at 12:32:33PM +0100, Chris Wilson wrote:
On Wed, Aug 13, 2014 at 01:26:40PM +0200, Daniel Vetter wrote:
On Tue, Aug 12, 2014 at 03:15:17PM +0100, Chris Wilson wrote:
+static void
Rather than take and release the console_lock() around a non-existent
DRM_I915_FBDEV, move the lock acquisation into the callee where it will
be compiled out by the config option entirely. This includes moving the
deferred fb_set_suspend() dance and encapsulating it entirely within
intel_fbdev.c.
On Wed, Aug 13, 2014 at 01:12:12PM +0530, Sharma, Shashank wrote:
On 8/13/2014 11:46 AM, Chris Wilson wrote:
On Wed, Aug 13, 2014 at 11:34:02AM +0530, Sharma, Shashank wrote:
5. We want this code routine only to be executed for commercial (like
android) platforms, whereas others get the
On Tue, Aug 12, 2014 at 06:08:20PM +0530, shashank.sha...@intel.com wrote:
From: Shashank Sharma shashank.sha...@intel.com
The current hdmi_detect() function is getting called from
many places, few of these are:
1. HDMI hot plug interrupt bottom half
2. get_resources() IOCTL family
3.
On Wed, Aug 13, 2014 at 12:45:11PM +0100, Chris Wilson wrote:
On Wed, Aug 13, 2014 at 01:32:31PM +0200, Daniel Vetter wrote:
On Wed, Aug 13, 2014 at 11:51:55AM +0100, Chris Wilson wrote:
From: Daniel Vetter daniel.vet...@ffwll.ch
That's right, back to where it was!
This
On Wed, Aug 13, 2014 at 01:09:46PM +0100, Chris Wilson wrote:
Rather than take and release the console_lock() around a non-existent
DRM_I915_FBDEV, move the lock acquisation into the callee where it will
be compiled out by the config option entirely. This includes moving the
deferred
On Wed, Aug 13, 2014 at 02:46:53PM +0200, Daniel Vetter wrote:
On Wed, Aug 13, 2014 at 01:09:46PM +0100, Chris Wilson wrote:
Rather than take and release the console_lock() around a non-existent
DRM_I915_FBDEV, move the lock acquisation into the callee where it will
be compiled out by the
On Wed, Aug 13, 2014 at 01:58:30PM +0100, Chris Wilson wrote:
On Wed, Aug 13, 2014 at 02:46:53PM +0200, Daniel Vetter wrote:
On Wed, Aug 13, 2014 at 01:09:46PM +0100, Chris Wilson wrote:
Rather than take and release the console_lock() around a non-existent
DRM_I915_FBDEV, move the lock
On Wed, Aug 13, 2014 at 03:04:02PM +0200, Daniel Vetter wrote:
On Wed, Aug 13, 2014 at 01:58:30PM +0100, Chris Wilson wrote:
On Wed, Aug 13, 2014 at 02:46:53PM +0200, Daniel Vetter wrote:
On Wed, Aug 13, 2014 at 01:09:46PM +0100, Chris Wilson wrote:
Rather than take and release the
-Original Message-
From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel
Vetter
Sent: Monday, August 11, 2014 9:57 PM
To: Daniel, Thomas
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH 21/43] drm/i915/bdw: Emission of requests
with logical
-Original Message-
From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel
Vetter
Sent: Monday, August 11, 2014 3:21 PM
To: Daniel, Thomas
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH 08/43] drm/i915/bdw: Add a context and an
engine pointers
On Wed, Aug 13, 2014 at 02:09:22PM +0100, Chris Wilson wrote:
On Wed, Aug 13, 2014 at 03:04:02PM +0200, Daniel Vetter wrote:
On Wed, Aug 13, 2014 at 01:58:30PM +0100, Chris Wilson wrote:
On Wed, Aug 13, 2014 at 02:46:53PM +0200, Daniel Vetter wrote:
On Wed, Aug 13, 2014 at 01:09:46PM
On Wed, 23 Jul 2014, Hans de Goede hdego...@redhat.com wrote:
Hi,
On 07/22/2014 08:52 AM, Daniel Vetter wrote:
On Tue, Jul 22, 2014 at 8:42 AM, Hans de Goede hdego...@redhat.com wrote:
Hi Jani et al,
A friend of mine Bertrik Sikken (in the Cc) his backlight control
stopped working for him
On Tue, 2014-08-12 at 16:21 +0530, sagar.a.kam...@intel.com wrote:
From: Sagar Kamble sagar.a.kamble at intel.com
The change is substantial enough that you should add a commit message
explaining what it fixes and how. There are further useful guidelines on
this topic in
Chris Wilson ch...@chris-wilson.co.uk writes:
The current error state harks back to the era of just a single VM. For
full-ppgtt, we capture every bo on every VM. It behoves us to then print
every bo for every VM, which we currently fail to do and so miss vital
information in the error state.
On Wed, 2014-08-13 at 16:47 +0300, Imre Deak wrote:
On Tue, 2014-08-12 at 16:21 +0530, sagar.a.kam...@intel.com wrote:
From: Sagar Kamble sagar.a.kamble at intel.com
The change is substantial enough that you should add a commit message
explaining what it fixes and how. There are further
On Fri, 8 Aug 2014 15:14:15 +0200
Daniel Vetter daniel.vet...@ffwll.ch wrote:
Adding relevant mailing lists.
On Fri, Aug 8, 2014 at 1:23 PM, Juergen Gross jgr...@suse.com wrote:
I'm just about to create a patch for full PAT support in the Linux
kernel, including Xen. For this purpose I
Ville noticed that we can call ibx_digital_port_connected() which accesses
the HW without holding any power well/runtime pm reference. Fix this by
holding a display port power domain reference around the whole hpd_pulse
handler.
Signed-off-by: Imre Deak imre.d...@intel.com
---
Atm, the HPD IRQ reenable timer can get rearmed right after it's
canceled. Also to access the HPD IRQ mask registers we need to wake up
the HW.
Solve both issues by converting the reenable timer to a delayed work and
grabbing a runtime PM reference in the work. By this we can also forgo
canceling
Atm we may leave eDP VDD enabled during system suspend after the CRTCs
are disabled through an HPD-DPCD read event. So disable VDD during
suspend at a point when no HPDs can occur.
Note that runtime suspend doesn't have the same problem, since there the
RPM ref held by VDD provides already the
Atm we may retrain the DP link even if the CRTC is inactive through
HPD work-intel_dp_check_link_status(). This in turn can lock up the PHY
(at least on BYT), since the DP port is disabled.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=81948
Signed-off-by: Imre Deak imre.d...@intel.com
On Wed, Aug 13, 2014 at 01:34:15PM +, Daniel, Thomas wrote:
-Original Message-
From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel
Vetter
Sent: Monday, August 11, 2014 3:21 PM
To: Daniel, Thomas
Cc: intel-gfx@lists.freedesktop.org
Subject: Re:
Make sure these work handlers don't run after we system suspend or
unload the driver. Note that we don't cancel the handlers during runtime
suspend. That could lead to a lockup, since we take a runtime PM ref
from the handlers themselves. Fortunaltely canceling there is not needed
since the RPM
-Original Message-
From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel
Vetter
Sent: Monday, August 11, 2014 10:25 PM
To: Daniel, Thomas
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH 27/43] drm/i915/bdw: Render state init for
Execlists
On Wed, Aug 13, 2014 at 01:34:28PM +, Daniel, Thomas wrote:
-Original Message-
From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel
Vetter
Sent: Monday, August 11, 2014 9:57 PM
To: Daniel, Thomas
Cc: intel-gfx@lists.freedesktop.org
Subject: Re:
On Wed, Aug 13, 2014 at 03:07:29PM +, Daniel, Thomas wrote:
-Original Message-
From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel
Vetter
Sent: Monday, August 11, 2014 10:25 PM
To: Daniel, Thomas
Cc: intel-gfx@lists.freedesktop.org
Subject: Re:
The series seems fine to me.
Reviewed-by: Ville Syrjälä ville.syrj...@linux.intel.com
for the rest as well.
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
From: Sagar Kamble sagar.a.kam...@intel.com
On VLV, post S0i3 during i915_drm_thaw following issue is observed during ring
initialization.
[ 335.604039] [drm:stop_ring] ERROR render ring :timed out trying to stop ring
[ 336.607340] [drm:stop_ring] ERROR render ring :timed out trying to stop ring
From: Sagar Kamble sagar.a.kam...@intel.com
With this change, intel_runtime_suspend and intel_runtime_resume functions
become completely platform agnostic. Platform specific suspend/resume
changes are moved to intel_suspend_complete and intel_resume_prepare.
Cc: Imre Deak imre.d...@intel.com
Cc:
Jani Nikula jani.nik...@intel.com writes:
This is a generic version of Daniel's patch [1] letting us have unsafe
module parameters (experimental, debugging, testing, etc.) that taint
the kernel when set. Quoting Daniel,
OK, I think the idea is fine, but we'll probably only want this for
a few
Ville noticed that we can call ibx_digital_port_connected() which accesses
the HW without holding any power well/runtime pm reference. Fix this by
holding a display port power domain reference around the whole hpd_pulse
handler.
Signed-off-by: Imre Deak imre.d...@intel.com
Makes sense to
Hi Everyone,
I am an Operating system developer and I'm working on a project for
which I wanted to understand the working of Intel Graphics Driver.
Being somewhat new in this field, Can I ask anyone to point me where
should I start digging in the code? I mean where the graphic driver
initializes
On 08/12/2014 07:11 AM, Jani Nikula wrote:
This series adds support for backlight class sysfs bl_power attribute
for eDP panels, which allows switching the backlight on/off. This is
done using the eDP panel power control as a sub-state of everything else
being enabled. Patch 4 also makes 0
On Wed, Aug 13, 2014 at 10:25 PM, Rusty Russell ru...@rustcorp.com.au wrote:
Jani Nikula jani.nik...@intel.com writes:
This is a generic version of Daniel's patch [1] letting us have unsafe
module parameters (experimental, debugging, testing, etc.) that taint
the kernel when set. Quoting
56 matches
Mail list logo
