The code has become quite hairy. By relocating all the generic registers
it will become more obvious where future ones should go. There is still
admittedly a bit of confusion left for things like per ring registers.
A subsequent patch will clean this function up.
Signed-off-by: Ben Widawsky
Create logical sections in an attempt to clean up, and continue to keep
future additions clean.
v2: Reworded the comments. Added section headers (Chris)
Signed-off-by: Ben Widawsky b...@bwidawsk.net
Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/i915_gpu_error.c |
v2: Rebased upon cleaned up error state
v3: Make sure hangcheck info remains last (Chris)
Cc: Chris Wilson ch...@chris-wilson.co.uk
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
drivers/gpu/drm/i915/i915_drv.h | 9 +
drivers/gpu/drm/i915/i915_gpu_error.c | 37
This helps make an upcoming patch a bit more reviewable
Signed-off-by: Ben Widawsky b...@bwidawsk.net
Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/i915_drv.h | 43 -
1 file changed, 25 insertions(+), 18 deletions(-)
diff
v2: Moved num_requests up (Chris)
Rebased on new hws page capture which required a rename since it made
two members named, 'hws' in the per ring error state. (Ben)
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
drivers/gpu/drm/i915/i915_drv.h | 65
Chris:
Do we also want to capture?
GAC_ECO_BITS /* gen6,7 */
GAM_ECOCHK /* gen6,7 */
GAB_CTL /* gen6 */
GFX_MODE /* gen6 */
Requested-by: Chris Wilson ch...@chris-wilson.co.uk
Signed-off-by: Ben Widawsky b...@bwidawsk.net
Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk
---
On Wed, Jan 29, 2014 at 01:55:02PM -0800, bradley.d.vol...@intel.com wrote:
From: Brad Volkin bradley.d.vol...@intel.com
The command parser is going to need the same synchronization and
setup logic, so factor it out for reuse.
Signed-off-by: Brad Volkin bradley.d.vol...@intel.com
---
On Wed, Jan 29, 2014 at 10:28:36PM +, Chris Wilson wrote:
On Wed, Jan 29, 2014 at 01:55:03PM -0800, bradley.d.vol...@intel.com wrote:
+/*
+ * Returns a pointer to a descriptor for the command specified by
cmd_header.
+ *
+ * The caller must supply space for a default descriptor via
On Wed, Jan 29, 2014 at 03:18:21PM -0800, Volkin, Bradley D wrote:
On Wed, Jan 29, 2014 at 02:37:25PM -0800, Chris Wilson wrote:
On Wed, Jan 29, 2014 at 01:55:08PM -0800, bradley.d.vol...@intel.com wrote:
From: Brad Volkin bradley.d.vol...@intel.com
These are used to implement
On Thu, Jan 30, 2014 at 09:53:28AM +0100, Daniel Vetter wrote:
On Wed, Jan 29, 2014 at 10:28:36PM +, Chris Wilson wrote:
On Wed, Jan 29, 2014 at 01:55:03PM -0800, bradley.d.vol...@intel.com wrote:
+/*
+ * Returns a pointer to a descriptor for the command specified by
cmd_header.
On Wed, Jan 29, 2014 at 01:55:03PM -0800, bradley.d.vol...@intel.com wrote:
From: Brad Volkin bradley.d.vol...@intel.com
The command parser scans batch buffers submitted via execbuffer ioctls before
the driver submits them to hardware. At a high level, it looks for several
things:
1)
On Thu, Jan 30, 2014 at 10:05:28AM +0100, Daniel Vetter wrote:
On Thu, Jan 30, 2014 at 09:53:28AM +0100, Daniel Vetter wrote:
On Wed, Jan 29, 2014 at 10:28:36PM +, Chris Wilson wrote:
On Wed, Jan 29, 2014 at 01:55:03PM -0800, bradley.d.vol...@intel.com
wrote:
+/*
+ * Returns
On Wed, Jan 29, 2014 at 01:55:13PM -0800, bradley.d.vol...@intel.com wrote:
From: Brad Volkin bradley.d.vol...@intel.com
So userspace can query the kernel for command parser support.
OTC-Tracker: AXIA-4631
Change-Id: I58af650db9f6753c2dcac9c54ab432fd31db302f
Signed-off-by: Brad Volkin
Hi,
On 01/29/2014 08:11 PM, Daniel Vetter wrote:
On Wed, Jan 29, 2014 at 01:30:54PM +, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin tvrtko.ursu...@intel.com
A set of userptr test cases to support the new feature.
[snip]
Minor thing on patch style: I'd split this up into 3 parts:
-
On Wed, Jan 29, 2014 at 02:26:12PM -0800, Volkin, Bradley D wrote:
On Wed, Jan 29, 2014 at 02:13:21PM -0800, Chris Wilson wrote:
On Wed, Jan 29, 2014 at 01:57:28PM -0800, bradley.d.vol...@intel.com wrote:
From: Brad Volkin bradley.d.vol...@intel.com
Signed-off-by: Brad Volkin
On Thu, Jan 30, 2014 at 10:20 AM, Tvrtko Ursulin
tvrtko.ursu...@linux.intel.com wrote:
On 01/29/2014 08:11 PM, Daniel Vetter wrote:
On Wed, Jan 29, 2014 at 01:30:54PM +, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin tvrtko.ursu...@intel.com
A set of userptr test cases to support the new
Fix and cleanup the rather confused native aux read return values and
return value checks. Maybe we'll get them right from now on. Just maybe.
Did not have a chance to test this, I'm afraid, but it's pretty
straightforward.
BR,
Jani.
Jani Nikula (4):
drm/i915/dp: make
Just code shuffling to have intel_dp_aux_native_read_retry() next to its
sibling intel_dp_aux_native_read(). No functional changes.
Signed-off-by: Jani Nikula jani.nik...@intel.com
---
drivers/gpu/drm/i915/intel_dp.c | 50 +++
1 file changed, 25
In most cases we only care about success or fail, so make the function
easier to use, and consistent with intel_dp_aux_native_read_retry().
This fixes the intel_dp_aux_native_read() usage in intel_dp_sink_crc()
which has already assumed bool, and would only have caught very specific
failure
intel_dp_aux_native_read_retry() returns a bool, so check for a bool for
consistency. No functional changes.
Signed-off-by: Jani Nikula jani.nik...@intel.com
---
drivers/gpu/drm/i915/intel_dp.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
intel_dp_aux_native_read_retry() is only needed when the sink might be
asleep. Use the regular read without retries otherwise.
Signed-off-by: Jani Nikula jani.nik...@intel.com
---
drivers/gpu/drm/i915/intel_dp.c | 32
1 file changed, 12 insertions(+), 20
On Thu, Jan 30, 2014 at 11:37:00AM +0200, Jani Nikula wrote:
Fix and cleanup the rather confused native aux read return values and
return value checks. Maybe we'll get them right from now on. Just maybe.
Did not have a chance to test this, I'm afraid, but it's pretty
straightforward.
How
On Thu, Jan 30, 2014 at 11:37:01AM +0200, Jani Nikula wrote:
+static inline bool
+intel_dp_aux_native_read(struct intel_dp *intel_dp,
+ uint16_t address, uint8_t *recv, int recv_bytes)
+{
+ return _intel_dp_aux_native_read(intel_dp, address,
+
On Thu, Jan 30, 2014 at 10:07:42AM +0100, Daniel Vetter wrote:
On Wed, Jan 29, 2014 at 01:55:03PM -0800, bradley.d.vol...@intel.com wrote:
From: Brad Volkin bradley.d.vol...@intel.com
The command parser scans batch buffers submitted via execbuffer ioctls
before
the driver submits them
On Wed, Jan 29, 2014 at 10:58:48PM +0100, Daniel Vetter wrote:
On Wed, Jan 29, 2014 at 10:53 PM, Chris Wilson ch...@chris-wilson.co.uk
wrote:
On Wed, Jan 29, 2014 at 09:25:51PM +0100, Daniel Vetter wrote:
So originally I've thought we need this due to the massive overhead of the
mmu
On Thu, Jan 30, 2014 at 10:12:06AM +0100, Daniel Vetter wrote:
On Thu, Jan 30, 2014 at 10:05:28AM +0100, Daniel Vetter wrote:
On Thu, Jan 30, 2014 at 09:53:28AM +0100, Daniel Vetter wrote:
On Wed, Jan 29, 2014 at 10:28:36PM +, Chris Wilson wrote:
On Wed, Jan 29, 2014 at 01:55:03PM
On Wed, Jan 29, 2014 at 11:55:24AM -0800, Ben Widawsky wrote:
With the ring mask we now have an easy way to know the number of rings
in the system, and therefore can accurately predict the number of dwords
to emit for semaphore signalling. This was not possible (easily)
previously.
There
On Thu, Jan 30, 2014 at 12:19:40AM -0800, Ben Widawsky wrote:
v2: Rebased upon cleaned up error state
v3: Make sure hangcheck info remains last (Chris)
Cc: Chris Wilson ch...@chris-wilson.co.uk
Signed-off-by: Ben Widawsky b...@bwidawsk.net
Pulled in entire series with Chris' irc ack on the
On Thu, Jan 30, 2014 at 12:26:49PM +0100, Daniel Vetter wrote:
On Thu, Jan 30, 2014 at 12:19:40AM -0800, Ben Widawsky wrote:
v2: Rebased upon cleaned up error state
v3: Make sure hangcheck info remains last (Chris)
Cc: Chris Wilson ch...@chris-wilson.co.uk
Signed-off-by: Ben Widawsky
On Wed, Jan 29, 2014 at 10:10:47PM +, Chris Wilson wrote:
On Wed, Jan 29, 2014 at 01:58:29PM -0800, bradley.d.vol...@intel.com wrote:
From: Brad Volkin bradley.d.vol...@intel.com
Signed-off-by: Brad Volkin bradley.d.vol...@intel.com
---
tests/gem_exec_parse.c | 9 +
1
In most cases we only care about success or fail, so make the function
easier to use, and consistent with intel_dp_aux_native_read_retry().
This fixes the intel_dp_aux_native_read() usage in intel_dp_sink_crc()
which has already assumed bool, and would only have caught very specific
failure
Just code shuffling to have intel_dp_aux_native_read_retry() next to its
sibling intel_dp_aux_native_read(). No functional changes.
v2: rebase.
Signed-off-by: Jani Nikula jani.nik...@intel.com
---
drivers/gpu/drm/i915/intel_dp.c | 48 +++
1 file changed, 24
On Wed, Jan 29, 2014 at 06:23:40PM -0800, Matt Turner wrote:
On Wed, Jan 29, 2014 at 9:56 AM, Daniel Vetter dan...@ffwll.ch wrote:
On Tue, Jan 28, 2014 at 6:29 AM, Chia-I Wu olva...@gmail.com wrote:
From: Chia-I Wu o...@lunarg.com
The optimization is available on Ivy Bridge and later, and
On Wed, Jan 29, 2014 at 11:55:26AM -0800, Ben Widawsky wrote:
Semaphore signalling works similarly to previous GENs with the exception
that the per ring mailboxes no longer exist. Instead you must define
your own space, somewhere in the GTT.
The comments in the code define the layout I've
On Thu, Jan 30, 2014 at 01:10:07PM +0100, Daniel Vetter wrote:
On Wed, Jan 29, 2014 at 06:23:40PM -0800, Matt Turner wrote:
On Wed, Jan 29, 2014 at 9:56 AM, Daniel Vetter dan...@ffwll.ch wrote:
On Tue, Jan 28, 2014 at 6:29 AM, Chia-I Wu olva...@gmail.com wrote:
From: Chia-I Wu
On Thu, Jan 30, 2014 at 02:38:17PM +0200, Ville Syrjälä wrote:
On Wed, Jan 29, 2014 at 11:55:26AM -0800, Ben Widawsky wrote:
Semaphore signalling works similarly to previous GENs with the exception
that the per ring mailboxes no longer exist. Instead you must define
your own space,
On Wed, Jan 29, 2014 at 11:55:27AM -0800, Ben Widawsky wrote:
Semaphore waits use a new instruction, MI_SEMAPHORE_WAIT. The seqno to
wait on is all well defined by the table in the previous patch. There is
nothing else different from previous GEN's semaphore synchronization
code.
v2: Update
On Wed, Jan 29, 2014 at 01:44:34PM -0800, Ben Widawsky wrote:
Last word: As I've discussed with Chris too, I am overall a bit wary of
removing any use upon hardware for doing a lot of these error triage,
detection and collection functions. I really like that no matter how
bonghits our driver
On Wed, Jan 29, 2014 at 01:50:06PM -0200, Rodrigo Vivi wrote:
@@ -7501,6 +7501,9 @@ static void intel_crtc_update_cursor(struct drm_crtc
*crtc,
u32 base = 0, pos = 0;
bool visible;
+ if (IS_VALLEYVIEW(dev))
+ intel_edp_psr_inactivate(dev);
+
Inactivate means
On Thu, Jan 30, 2014 at 1:46 PM, Chris Wilson ch...@chris-wilson.co.uk wrote:
Oh. So they changed how post-sync writes operated - this should be a
separate fix for stable I believe (so that batches are not run before we
have finished invalidating the TLBs required).
We have an igt to exercise
On Wed, Jan 29, 2014 at 11:55:29AM -0800, Ben Widawsky wrote:
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
On Thu, Jan 30, 2014 at 02:18:32PM +0100, Daniel Vetter wrote:
On Thu, Jan 30, 2014 at 1:46 PM, Chris Wilson ch...@chris-wilson.co.uk
wrote:
Oh. So they changed how post-sync writes operated - this should be a
separate fix for stable I believe (so that batches are not run before we
have
On Thu, Jan 30, 2014 at 02:18:32PM +0100, Daniel Vetter wrote:
On Thu, Jan 30, 2014 at 1:46 PM, Chris Wilson ch...@chris-wilson.co.uk
wrote:
Oh. So they changed how post-sync writes operated - this should be a
separate fix for stable I believe (so that batches are not run before we
have
On Thu, 30 Jan 2014, Daniel Vetter dan...@ffwll.ch wrote:
How does this fit in with Thierry's dp aux helper improvements? I prefer
if we start to converge on that sooner than later ...
Patch 1/4 actually fixes a potential bug in intel_dp_sink_crc(), which
now detects failure only if the read
With full ppgtt support drm_i915_file_private gained knowledge
about the default context. Also reset stats are now inside
i915_hw_context so we can use proper abstraction.
v2: Move BUG_ON and WARN_ON to more proper locations (Ben)
Suggested-by: Ben Widawsky b...@bwidawsk.net
Signed-off-by: Mika
If we have stopped rings then we know that test is running
so no need for spam. In addition, only spam when default
context gets banned.
v2: - make sure default context ban gets shown (Chris)
- use helper for checking for default context, everywhere (Chris)
v3: - dont be quiet when debug is
If we have stopped rings then we know that test is running
so no need for spam. In addition, only spam when default
context gets banned.
v2: - make sure default context ban gets shown (Chris)
- use helper for checking for default context, everywhere (Chris)
v3: - dont be quiet when debug is
We want to use the GTT for reading back objects upon an error so that we
have exactly the information that the GPU saw. However, it is verboten
to access snoopable pages through the GTT and causes my PineView GPU to
throw a page fault instead.
This has not been a problem in the past as we only
Repeating the same information multiple times is just annoying.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/i915_gpu_error.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
On Thu, Jan 30, 2014 at 02:38:16PM +, Chris Wilson wrote:
We want to use the GTT for reading back objects upon an error so that we
have exactly the information that the GPU saw. However, it is verboten
to access snoopable pages through the GTT and causes my PineView GPU to
throw a page
Atm we setup the HW panel power sequencer logic both for eDP and DP
ports. On eDP we then go on and start the power on sequence and commence
with link training when it's ready. On DP we don't do the power on
sequencing but do the link training immediately. At this point the DP
PHY block gets
On Wed, Jan 29, 2014 at 11:55:31AM -0800, Ben Widawsky wrote:
Since the semaphore information is in an object, just dump it, and let
the user parse it later.
NOTE: The page being used for the semaphores are incoherent with the
CPU. No matter what I do, I cannot figure out a way to read
On Thu, Jan 30, 2014 at 04:53:32PM +0200, Ville Syrjälä wrote:
On Wed, Jan 29, 2014 at 11:55:31AM -0800, Ben Widawsky wrote:
+ obj = error-semaphore_obj;
+ if (obj) {
Chris will come along and change this to
if ((obj = error-semaphore_obj))
I was merely keeping in style with the
On Thu, 30 Jan 2014, Daniel Vetter dan...@ffwll.ch wrote:
On Thu, Jan 30, 2014 at 11:37:00AM +0200, Jani Nikula wrote:
Fix and cleanup the rather confused native aux read return values and
return value checks. Maybe we'll get them right from now on. Just maybe.
Did not have a chance to test
On Thu, Jan 30, 2014 at 4:05 PM, Jani Nikula jani.nik...@intel.com wrote:
On Thu, 30 Jan 2014, Daniel Vetter dan...@ffwll.ch wrote:
On Thu, Jan 30, 2014 at 11:37:00AM +0200, Jani Nikula wrote:
Fix and cleanup the rather confused native aux read return values and
return value checks. Maybe
On Thu, Jan 30, 2014 at 02:38:16PM +, Chris Wilson wrote:
We want to use the GTT for reading back objects upon an error so that we
have exactly the information that the GPU saw. However, it is verboten
to access snoopable pages through the GTT and causes my PineView GPU to
throw a page
On Thu, Jan 30, 2014 at 09:53:54AM -0500, Alan Stern wrote:
On Tue, 28 Jan 2014, Daniel Vetter wrote:
I think I need a bit more debug output first. Can you please apply the
below patch to drm-intel-nightly and then grab a drm.debug=0xe dmesg from
boot?
The dmesg output is below. Since
On Thu, Jan 30, 2014 at 04:01:15PM +0200, Mika Kuoppala wrote:
With full ppgtt support drm_i915_file_private gained knowledge
about the default context. Also reset stats are now inside
i915_hw_context so we can use proper abstraction.
v2: Move BUG_ON and WARN_ON to more proper locations
On Thu, Jan 30, 2014 at 04:50:42PM +0200, Imre Deak wrote:
Atm we setup the HW panel power sequencer logic both for eDP and DP
ports. On eDP we then go on and start the power on sequence and commence
with link training when it's ready. On DP we don't do the power on
sequencing but do the link
On Thu, 30 Jan 2014, Daniel Vetter wrote:
Ok, I seem to have been truly blind all the time. This seems to have been
fallout from
commit b6c5164d7bf624f3e1b750787ddb983150c5117c
Author: Daniel Vetter daniel.vet...@ffwll.ch
Date: Fri Apr 12 18:48:43 2013 +0200
drm/i915: Fixup Oops
On Thu, Jan 30, 2014 at 04:52:24PM +0100, Daniel Vetter wrote:
On Thu, Jan 30, 2014 at 04:50:42PM +0200, Imre Deak wrote:
Atm we setup the HW panel power sequencer logic both for eDP and DP
ports. On eDP we then go on and start the power on sequence and commence
with link training when it's
On Thu, 2014-01-30 at 16:52 +0100, Daniel Vetter wrote:
On Thu, Jan 30, 2014 at 04:50:42PM +0200, Imre Deak wrote:
Atm we setup the HW panel power sequencer logic both for eDP and DP
ports. On eDP we then go on and start the power on sequence and commence
with link training when it's ready.
On Thu, Jan 30, 2014 at 03:11:08PM +, Chris Wilson wrote:
On Thu, Jan 30, 2014 at 05:08:09PM +0200, Ville Syrjälä wrote:
On Thu, Jan 30, 2014 at 02:38:16PM +, Chris Wilson wrote:
We want to use the GTT for reading back objects upon an error so that we
have exactly the information
On Thu, Jan 30, 2014 at 05:32:10PM +0200, Ville Syrjälä wrote:
On Thu, Jan 30, 2014 at 03:11:08PM +, Chris Wilson wrote:
On Thu, Jan 30, 2014 at 05:08:09PM +0200, Ville Syrjälä wrote:
On Thu, Jan 30, 2014 at 02:38:16PM +, Chris Wilson wrote:
We want to use the GTT for reading
From: Deepak S deepa...@intel.com
When we enter RC6 and GFX Clocks are off, the voltage remains higher
than Vmin. When we try to set the freq to RPn, it might fail since the
Gfx clocks are down. So to fix this in Gfx idle, Bring the GFX clock up
and set the freq to RPn then move GFx down.
v2:
On Thu, 30 Jan 2014, Daniel Vetter dan...@ffwll.ch wrote:
On Thu, Jan 30, 2014 at 04:50:42PM +0200, Imre Deak wrote:
Atm we setup the HW panel power sequencer logic both for eDP and DP
ports. On eDP we then go on and start the power on sequence and commence
with link training when it's ready.
On Thu, 2014-01-30 at 18:22 +0200, Jani Nikula wrote:
On Thu, 30 Jan 2014, Daniel Vetter dan...@ffwll.ch wrote:
On Thu, Jan 30, 2014 at 04:50:42PM +0200, Imre Deak wrote:
Atm we setup the HW panel power sequencer logic both for eDP and DP
ports. On eDP we then go on and start the power on
This regression has been introduced in
commit b3f2333de8e81b089262b26d52272911523e605f
Author: Daniel Vetter daniel.vet...@ffwll.ch
Date: Wed Dec 11 11:34:31 2013 +0100
drm: restrict the device list for shadow attached drivers
Reported-by: Dave Jones da...@redhat.com
Cc: Dave Jones
On Thu, Jan 30, 2014 at 11:02 AM, Chris Wilson ch...@chris-wilson.co.uk wrote:
On Wed, Jan 29, 2014 at 01:50:06PM -0200, Rodrigo Vivi wrote:
@@ -7501,6 +7501,9 @@ static void intel_crtc_update_cursor(struct drm_crtc
*crtc,
u32 base = 0, pos = 0;
bool visible;
+ if
On Thu, Jan 30, 2014 at 09:54:41PM +0530, deepa...@intel.com wrote:
From: Deepak S deepa...@intel.com
When we enter RC6 and GFX Clocks are off, the voltage remains higher
than Vmin. When we try to set the freq to RPn, it might fail since the
Gfx clocks are down. So to fix this in Gfx idle,
With full ppgtt using acthd is not enough to find guilty
batch buffer. We get multiple false positives as acthd is
per vm.
Instead of scanning which vm was running on a ring,
to find corressponding context, use a different, simpler,
strategy of finding batches that caused gpu hang:
If hangcheck
As we seek the guilty batch using request and hangcheck
score, this code is not needed anymore.
v2: Rebase. Passing dev_priv instead of getting it from last_ring
Signed-off-by: Mika Kuoppala mika.kuopp...@intel.com
Reviewed-by: Ben Widawsky b...@bwidawsk.net (v1)
---
Hi
On Thu, Jan 30, 2014 at 5:58 PM, Daniel Vetter daniel.vet...@ffwll.ch wrote:
This regression has been introduced in
commit b3f2333de8e81b089262b26d52272911523e605f
Author: Daniel Vetter daniel.vet...@ffwll.ch
Date: Wed Dec 11 11:34:31 2013 +0100
drm: restrict the device list for
On Thu, Jan 30, 2014 at 05:58:38PM +0100, Daniel Vetter wrote:
This regression has been introduced in
commit b3f2333de8e81b089262b26d52272911523e605f
Author: Daniel Vetter daniel.vet...@ffwll.ch
Date: Wed Dec 11 11:34:31 2013 +0100
drm: restrict the device list for shadow
On Thu, Jan 30, 2014 at 01:19:15AM -0800, Daniel Vetter wrote:
On Wed, Jan 29, 2014 at 01:55:13PM -0800, bradley.d.vol...@intel.com wrote:
From: Brad Volkin bradley.d.vol...@intel.com
So userspace can query the kernel for command parser support.
OTC-Tracker: AXIA-4631
Change-Id:
On Thu, Jan 30, 2014 at 01:20:57AM -0800, Daniel Vetter wrote:
On Wed, Jan 29, 2014 at 02:26:12PM -0800, Volkin, Bradley D wrote:
On Wed, Jan 29, 2014 at 02:13:21PM -0800, Chris Wilson wrote:
On Wed, Jan 29, 2014 at 01:57:28PM -0800, bradley.d.vol...@intel.com
wrote:
From: Brad
From: Deepak S deepa...@intel.com
When we enter RC6 and GFX Clocks are off, the voltage remains higher
than Vmin. When we try to set the freq to RPn, it might fail since the
Gfx clocks are down. So to fix this in Gfx idle, Bring the GFX clock up
and set the freq to RPn then move GFx down.
v2:
On Thu, Jan 30, 2014 at 01:12:06AM -0800, Daniel Vetter wrote:
On Thu, Jan 30, 2014 at 10:05:28AM +0100, Daniel Vetter wrote:
On Thu, Jan 30, 2014 at 09:53:28AM +0100, Daniel Vetter wrote:
On Wed, Jan 29, 2014 at 10:28:36PM +, Chris Wilson wrote:
On Wed, Jan 29, 2014 at 01:55:03PM
On Thu, Jan 30, 2014 at 03:07:15AM -0800, Daniel Vetter wrote:
On Thu, Jan 30, 2014 at 10:12:06AM +0100, Daniel Vetter wrote:
On Thu, Jan 30, 2014 at 10:05:28AM +0100, Daniel Vetter wrote:
On Thu, Jan 30, 2014 at 09:53:28AM +0100, Daniel Vetter wrote:
On Wed, Jan 29, 2014 at 10:28:36PM
RC6 works a lot like HW contexts in that when the GPU enters RC6 it
saves away the state to a context, and loads it upon wake.
It's to be somewhat expected that BIOS will not set up valid GPU state.
As a result, if loading bad state can cause the GPU to get angry, it
would make sense then that we
Hi All,
I'm seeing the oops below on my MacBookPro 10,2 machine using i915
graphics. It's after the DRM merge for 3.14 ( v3.13-10094-g9b0cd30) ,
but we seem to have one report[1] of this happening well before that,
in v3.13-3260-g03d11a0 as well. Does anyone have a clue what is going
on here?
On Thu, Jan 30, 2014 at 11:00:35AM -0800, Ben Widawsky wrote:
RC6 works a lot like HW contexts in that when the GPU enters RC6 it
saves away the state to a context, and loads it upon wake.
It's to be somewhat expected that BIOS will not set up valid GPU state.
As a result, if loading bad
On Thu, Jan 30, 2014 at 2:05 PM, Tejun Heo t...@kernel.org wrote:
On Thu, Jan 30, 2014 at 02:03:18PM -0500, Josh Boyer wrote:
Hi All,
I'm seeing the oops below on my MacBookPro 10,2 machine using i915
graphics. It's after the DRM merge for 3.14 ( v3.13-10094-g9b0cd30) ,
but we seem to have
Re-adding intel-gfx, this seems generally useful.
On Thu, Jan 30, 2014 at 6:22 PM, Volkin, Bradley D
bradley.d.vol...@intel.com wrote:
Ok. There's still a couple ways I could see doing it.
- one big patch with all the new #defines, up front
- split the #defines from their current patches, all
On Thu, Jan 30, 2014 at 2:20 PM, Josh Boyer jwbo...@fedoraproject.org wrote:
On Thu, Jan 30, 2014 at 2:05 PM, Tejun Heo t...@kernel.org wrote:
On Thu, Jan 30, 2014 at 02:03:18PM -0500, Josh Boyer wrote:
Hi All,
I'm seeing the oops below on my MacBookPro 10,2 machine using i915
graphics.
On Mon, Jan 20, 2014 at 9:55 PM, Jesse Barnes jbar...@virtuousgeek.org wrote:
Can be expanded up on to include all sorts of things (HDMI infoframe
data, more DP status, etc). Should be useful for bug reports to get a
baseline on the display config and info.
Signed-off-by: Jesse Barnes
The idea of printing objects used by each process is to judge how each
process is using them. This means that we need to evaluate whether the
object is bound for that particular process, rather than just whether it
is bound into the global GTT.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
87 matches
Mail list logo