Since we rely on hangcheck to wait up and kick us out of an indefinite
wait should the GPU ever stop functioning, it appears sensible that we
should check that hangcheck is indeed active before starting that wait.
This just prevents a driver error in the processing of hangcheck from
appearing to
This reverts commit 02f6bcccf7c324115747aae2f0addd6af5d321cd.
The OA buffer can contain global data (in particular, not linked to a
context or a single batch execution) about GPU events (eg. hw context
switches, rc6 transitions, frequency changes, ...) and needs to be
mapped to GGTT. The pin
On Wed, Jul 02, 2014 at 02:19:42PM +0100, Rutkowski, Adam J wrote:
Having said all this, how about restoring the pin_ioctl? At least for
some time? We do have a use case and moving to other - better -
solution would take time. I think backward compatibility is something
that you take into
On Wed, Jul 02, 2014 at 12:23:37PM -0400, Konrad Rzeszutek Wilk wrote:
On Wed, Jul 02, 2014 at 04:50:15PM +0200, Paolo Bonzini wrote:
Il 02/07/2014 16:00, Konrad Rzeszutek Wilk ha scritto:
With this long thread I lost a bit context about the challenges
that exists. But let me try
On Thu, Jun 26, 2014 at 02:24:19PM +0100, oscar.ma...@intel.com wrote:
+ i915_gem_execbuffer_move_to_active(vmas, ring);
+ i915_gem_execbuffer_retire_commands(dev, file, ring, batch_obj);
This is where I start freaking out over the mix of global vs logical
state and the implications of
On Thu, 03 Jul 2014, mengdong@intel.com wrote:
From: Jani Nikula jani.nik...@intel.com
I wrote this as a quick hack patch to try as an alternative to [1] which
ended up not working on Haswell. Please reassure me that this is going
to be a temporary solution until we get a more generic
On Thu, Jul 03, 2014 at 08:12:35AM +0100, Damien Lespiau wrote:
This reverts commit 02f6bcccf7c324115747aae2f0addd6af5d321cd.
The OA buffer can contain global data (in particular, not linked to a
context or a single batch execution) about GPU events (eg. hw context
switches, rc6 transitions,
Hi Dave -
Fixes for 3.16-rc3; most importantly Jesse brings back VGA he took away
on a bunch of machines. Also a vblank fix for BDW and a power workaround
fix for VLV.
BR,
Jani.
The following changes since commit 8525a235c96a548873c6c5644f50df32b31f04c6:
drm/i915: vlv_prepare_pll is only
-Original Message-
From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
Sent: Thursday, July 03, 2014 8:32 AM
To: Mateo Lozano, Oscar
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH 8/8] drm/i915: Extract the actual workload
submission mechanism from execbuffer
On Thu, Jul 03, 2014 at 09:07:41AM +, Mateo Lozano, Oscar wrote:
-Original Message-
From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
Sent: Thursday, July 03, 2014 8:32 AM
To: Mateo Lozano, Oscar
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH 8/8]
On Thu, Jun 26, 2014 at 02:24:15PM +0100, oscar.ma...@intel.com wrote:
From: Oscar Mateo oscar.ma...@intel.com
This is an Execlists preparatory patch, since they make context ID become an
overloaded term:
- In the software, it was used to distinguish which context userspace was
trying
Hi Jani,
-Original Message-
From: Nikula, Jani
Sent: Thursday, July 03, 2014 3:33 PM
I wrote this as a quick hack patch to try as an alternative to [1] which
ended up not working on Haswell. Please reassure me that this is going to
be a temporary solution until we get a more
On Thu, Jun 26, 2014 at 02:24:13PM +0100, oscar.ma...@intel.com wrote:
From: Oscar Mateo oscar.ma...@intel.com
This is Execlists preparatory work.
We have already advanced that Logical Ring Contexts have their own kind
ob backing objects, but everything will be better explained in the
We should keep DEVICE_READY bit set in the ULPS enter sequence. In
exit sequence also we should set DEVICE_READY, but thats causing
blankout for me. Also exit sequence is simplified as per hw team
recommendation.
This should fix -
[drm:intel_dsi_clear_device_ready] *ERROR* DSI LP not going Low
While sending DPI SHUTDOWN command, we cannot wait for FIFO empty as
pipes are not disabled at that time. In case of MIPI we disable port
first and send SHUTDOWN command while pipe is still running and FIFOs
will not be empty, causing spurious error log
Signed-off-by: Shobhit Kumar
On Thu, Jul 03, 2014 at 10:32:38AM +0300, Jani Nikula wrote:
On Thu, 03 Jul 2014, mengdong@intel.com wrote:
From: Jani Nikula jani.nik...@intel.com
I wrote this as a quick hack patch to try as an alternative to [1] which
ended up not working on Haswell. Please reassure me that this is
On Tue, 01 Jul 2014, Rodrigo Vivi rodrigo.v...@gmail.com wrote:
Jani, please ignore the 4th patch on this series and merge the 3 I've
reviewed and tested already.
Patches 1-3 pushed to dinq. Thanks for the patches and review.
BR,
Jani.
They are essential to allow FBC work on BDW without
-Original Message-
From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
Sent: Thursday, July 03, 2014 10:53 AM
To: Mateo Lozano, Oscar; intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH 4/8] drm/i915: Rename ctx-id to ctx-handle
On Thu, Jul 03, 2014 at 10:30:52AM
-Original Message-
From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
Sent: Thursday, July 03, 2014 10:47 AM
To: Mateo Lozano, Oscar
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH 2/8] drm/i915: Rename ctx-obj to ctx-
rcs_state
On Thu, Jun 26, 2014 at
-Original Message-
From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
Sent: Thursday, July 03, 2014 10:49 AM
To: Mateo Lozano, Oscar
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH 3/8] drm/i915: Rename ctx-is_initialized to
ctx-rcs_is_initialized
On Thu,
On Thu, Jul 03, 2014 at 12:08:42PM +, Mateo Lozano, Oscar wrote:
-Original Message-
From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
Sent: Thursday, July 03, 2014 10:47 AM
To: Mateo Lozano, Oscar
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH 2/8]
On Thu, Jul 03, 2014 at 04:35:41PM +0530, Shobhit Kumar wrote:
We should keep DEVICE_READY bit set in the ULPS enter sequence. In
exit sequence also we should set DEVICE_READY, but thats causing
blankout for me. Also exit sequence is simplified as per hw team
recommendation.
This should fix
-Original Message-
From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
Sent: Thursday, July 03, 2014 1:28 PM
To: Mateo Lozano, Oscar
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH 2/8] drm/i915: Rename ctx-obj to ctx-
rcs_state
On Thu, Jul 03, 2014 at
Baytrail uses the RPS wait-boosting mechanism of Sandybridge+ but also has
a very lax downclocking strategy (upclock if more than 90% busy over 76ms,
downclock if less than 70% busy over 450ms). This causes Baytrail to use
maximum clocks, and for them to stay high, when doing simple tasks such as
-Original Message-
From: Lespiau, Damien
Sent: Thursday, July 03, 2014 7:19 PM
To: Nikula, Jani
Cc: Lin, Mengdong; alsa-de...@alsa-project.org; ti...@suse.de;
intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH v2 1/2] drm/i915: provide interface for audio
driver to
From: Oscar Mateo oscar.ma...@intel.com
Again, it's low-level enough to simply take a ringbuf and nothing
else.
Trivial change.
Reviewed-by: Jesse Barnes jbar...@virtuousgeek.org
Signed-off-by: Oscar Mateo oscar.ma...@intel.com
---
drivers/gpu/drm/i915/i915_gem.c | 4 ++--
From: Oscar Mateo oscar.ma...@intel.com
It's simple enough that it doesn't need to know anything about the
engine.
Trivial change.
Reviewed-by: Jesse Barnes jbar...@virtuousgeek.org
Signed-off-by: Oscar Mateo oscar.ma...@intel.com
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 13 ++---
From: Oscar Mateo oscar.ma...@intel.com
More prep work: with Execlists, we are going to start creating a lot
of extra ringbuffers soon, so these functions are handy.
No functional changes.
v2: rename allocate/destroy_ring_buffer to alloc/destroy_ringbuffer_obj
because the name is more
From: Oscar Mateo oscar.ma...@intel.com
This is preparatory work for Execlists: we plan to use it later to
allocate our own context objects (since Logical Ring Contexts do
not have the same kind of backing objects).
No functional changes.
Reviewed-by: Jesse Barnes jbar...@virtuousgeek.org
From: Oscar Mateo oscar.ma...@intel.com
This is an Execlists preparatory patch, since they make context ID become an
overloaded term:
- In the software, it was used to distinguish which context userspace was
trying to use.
- In the BSpec, the term is used to describe the 20-bits long field the
From: Oscar Mateo oscar.ma...@intel.com
A bit of background on the context elements.
Cc: Jesse Barnes jbar...@virtuousgeek.org
Signed-off-by: Oscar Mateo oscar.ma...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h | 15 +++
1 file changed, 15 insertions(+)
diff --git
From: Oscar Mateo oscar.ma...@intel.com
So that we isolate the legacy ringbuffer submission mechanism, which becomes
a good candidate to be abstracted away. This is prep-work for Execlists (which
will its own workload submission mechanism).
No functional changes.
Reviewed-by: Jesse Barnes
-Original Message-
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf
Of oscar.ma...@intel.com
Sent: Thursday, July 03, 2014 4:28 PM
To: intel-gfx@lists.freedesktop.org
Subject: [Intel-gfx] [PATCH 4/8] drm/i915: Add kerneldoc comments to the
intel_context
On Thu, 3 Jul 2014 08:09:01 +0100
Chris Wilson ch...@chris-wilson.co.uk wrote:
Since we rely on hangcheck to wait up and kick us out of an indefinite
wait should the GPU ever stop functioning, it appears sensible that we
should check that hangcheck is indeed active before starting that wait.
On Thu, 3 Jul 2014 15:29:26 +0100
Chris Wilson ch...@chris-wilson.co.uk wrote:
Baytrail uses the RPS wait-boosting mechanism of Sandybridge+ but also has
a very lax downclocking strategy (upclock if more than 90% busy over 76ms,
downclock if less than 70% busy over 450ms). This causes
On Thu, Jul 03, 2014 at 08:44:20AM -0700, Jesse Barnes wrote:
On Thu, 3 Jul 2014 08:09:01 +0100
Chris Wilson ch...@chris-wilson.co.uk wrote:
Since we rely on hangcheck to wait up and kick us out of an indefinite
wait should the GPU ever stop functioning, it appears sensible that we
On Thu, Jul 03, 2014 at 08:49:22AM -0700, Jesse Barnes wrote:
On Thu, 3 Jul 2014 15:29:26 +0100
Chris Wilson ch...@chris-wilson.co.uk wrote:
Baytrail uses the RPS wait-boosting mechanism of Sandybridge+ but also has
a very lax downclocking strategy (upclock if more than 90% busy over
On Thu, 3 Jul 2014 16:51:11 +0100
Chris Wilson ch...@chris-wilson.co.uk wrote:
On Thu, Jul 03, 2014 at 08:44:20AM -0700, Jesse Barnes wrote:
On Thu, 3 Jul 2014 08:09:01 +0100
Chris Wilson ch...@chris-wilson.co.uk wrote:
Since we rely on hangcheck to wait up and kick us out of an
On Thu, 3 Jul 2014 16:59:17 +0100
Chris Wilson ch...@chris-wilson.co.uk wrote:
On Thu, Jul 03, 2014 at 08:49:22AM -0700, Jesse Barnes wrote:
On Thu, 3 Jul 2014 15:29:26 +0100
Chris Wilson ch...@chris-wilson.co.uk wrote:
Baytrail uses the RPS wait-boosting mechanism of Sandybridge+ but
On Thu, Jul 03, 2014 at 08:17:32AM +0100, Damien Lespiau wrote:
On Wed, Jul 02, 2014 at 02:19:42PM +0100, Rutkowski, Adam J wrote:
Having said all this, how about restoring the pin_ioctl? At least for
some time? We do have a use case and moving to other - better -
solution would take time.
On 07/02/2014 01:35 AM, Jani Nikula wrote:
From: Clint Taylor clinton.a.tay...@intel.com
The panel power sequencer on vlv doesn't appear to accept changes to its
T12 power down duration during warm reboots. This change forces a delay
for warm reboots to the T12 panel timing as defined in the
On Thu, Jul 03, 2014 at 10:32:12AM +0300, Michael S. Tsirkin wrote:
On Wed, Jul 02, 2014 at 12:23:37PM -0400, Konrad Rzeszutek Wilk wrote:
On Wed, Jul 02, 2014 at 04:50:15PM +0200, Paolo Bonzini wrote:
Il 02/07/2014 16:00, Konrad Rzeszutek Wilk ha scritto:
With this long thread I lost a
On Thu, 3 Jul 2014 14:26:12 -0400
Konrad Rzeszutek Wilk konrad.w...@oracle.com wrote:
On Thu, Jul 03, 2014 at 10:32:12AM +0300, Michael S. Tsirkin wrote:
On Wed, Jul 02, 2014 at 12:23:37PM -0400, Konrad Rzeszutek Wilk wrote:
On Wed, Jul 02, 2014 at 04:50:15PM +0200, Paolo Bonzini wrote:
On Thu, Jul 03, 2014 at 12:09:28PM -0700, Jesse Barnes wrote:
On Thu, 3 Jul 2014 14:26:12 -0400
Konrad Rzeszutek Wilk konrad.w...@oracle.com wrote:
On Thu, Jul 03, 2014 at 10:32:12AM +0300, Michael S. Tsirkin wrote:
On Wed, Jul 02, 2014 at 12:23:37PM -0400, Konrad Rzeszutek Wilk wrote:
On Thu, 03 Jul 2014, Clint Taylor clinton.a.tay...@intel.com wrote:
On 07/02/2014 01:35 AM, Jani Nikula wrote:
From: Clint Taylor clinton.a.tay...@intel.com
The panel power sequencer on vlv doesn't appear to accept changes to its
T12 power down duration during warm reboots. This change forces
On Thu, Jul 03, 2014 at 10:10:48AM -0700, Ben Widawsky wrote:
On Thu, Jul 03, 2014 at 08:17:32AM +0100, Damien Lespiau wrote:
On Wed, Jul 02, 2014 at 02:19:42PM +0100, Rutkowski, Adam J wrote:
Having said all this, how about restoring the pin_ioctl? At least for
some time? We do have a
This is another drm-intel-collector updated notice:
http://cgit.freedesktop.org/~vivijim/drm-intel/log/?h=drm-intel-collector
It was 4 rounds out of date what made it hard to get old patches. However
Daniel and Jani didn't leave
many patches behind.
0 on Apr 4 - Apr 16
1 on Apr 16 - May 6
2 on
From: Deepak S deepa...@intel.com
We need do forcewake before Disabling RC6, This is what the BIOS
expects while going into suspend.
v2: updated commit message. (Daniel)
Reviewer: Paulo Zanoni paulo.r.zan...@intel.com
Cc: Paulo Zanoni paulo.r.zan...@intel.com
Signed-off-by: Deepak S
From: Ben Widawsky benjamin.widaw...@intel.com
Cc: Kenneth Graunke kenn...@whitecape.org
Signed-off-by: Ben Widawsky b...@bwidawsk.net
Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com
---
drivers/gpu/drm/i915/i915_gem_context.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
This is another drm-intel-collector updated notice:
http://cgit.freedesktop.org/~vivijim/drm-intel/log/?h=drm-intel-collector
It was 4 rounds out of date what made it hard to get old patches. However
Daniel and Jani didn't leave
many patches behind.
0 on Apr 4 - Apr 16
1 on Apr 16 - May 6
2 on
From: Chris Wilson ch...@chris-wilson.co.uk
If we try to execute on a known ring, but it has failed to be
initialised correctly, report that the GPU is hung rather than the
command invalid. This leaves us reporting EINVAL only if the user
requests execution on a ring that is not supported by the
From: Vandana Kannan vandana.kan...@intel.com
Added a property to enable user space to set aspect ratio for HDMI displays.
If there is no user specified value, then PAR_NONE/Automatic option is set
by default. User can select aspect ratio 4:3 or 16:9. The aspect ratio
selected by user would come
From: Clint Taylor clinton.a.tay...@intel.com
The panel power sequencer on vlv doesn't appear to accept changes to its
T12 power down duration during warm reboots. This change forces a delay
for warm reboots to the T12 panel timing as defined in the VBT table for
the connected panel.
Ver2:
From: Ben Widawsky benjamin.widaw...@intel.com
The PDPs seem to get screwed up otherwise, specifically PDP0. I am not
really clear why this is required, it just works with full PPGTT.
v2: Only do it for gen8, to limit regression potential
v3: Fix the bugzilla links
Bugzilla:
From: Chris Wilson ch...@chris-wilson.co.uk
In the move over to use BIOS connector configs, we lost the ability to
force a specific set of connectors on or off. Try to remedy that by
dropping back to the old behavior if we detect a hard coded connector
config that tries to enable a connector
On Thu, Jul 03, 2014 at 05:33:05PM -0400, Rodrigo Vivi wrote:
From: Ben Widawsky benjamin.widaw...@intel.com
The PDPs seem to get screwed up otherwise, specifically PDP0. I am not
really clear why this is required, it just works with full PPGTT.
v2: Only do it for gen8, to limit regression
Thanks
Please just ignore this one for now. It will be removed on next round.
On Thu, Jul 3, 2014 at 5:38 PM, Ben Widawsky benjamin.widaw...@intel.com
wrote:
On Thu, Jul 03, 2014 at 05:33:05PM -0400, Rodrigo Vivi wrote:
From: Ben Widawsky benjamin.widaw...@intel.com
The PDPs seem to get
Damien,
We run intel-gpu-tool in VMware esx console. We didn't port display part of
intel gpu driver to esx, so we don't need any display tests at all.
If you could provide us a solution to run intel gpu tools without cairo, that
would be great.
Thanks
Ying
This is a spec requirement for all rings.
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
drivers/gpu/drm/i915/i915_gem_context.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index 5b4a9a0..1ac648f
Originally the thought for the assertion was that if there are no real
VMAs (died during execbuf), or there is only 1 VMA, but the VMA is on
the active list, it's a bug. The former case is pretty obvious. The
later case simply meant to assert the context unref/object retire
interactions were
On 07/02/2014 07:40 AM, Paulo Zanoni wrote:
2014-07-02 5:35 GMT-03:00 Jani Nikula jani.nik...@intel.com:
From: Clint Taylor clinton.a.tay...@intel.com
The panel power sequencer on vlv doesn't appear to accept changes to its
T12 power down duration during warm reboots. This change forces a
Submitted with git to correct whitespace problems.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
commit c675949ec58ca50d5a3ae3c757892f1560f6e896
drm/i915: do not setup backlight if not available according to VBT
caused a regression on machines with a misconfigured VBT. Add a quirk to
assert the presence of a controllable backlight. Use it to ignore the VBT
backlight presence check
The Toshiba CB35 Chromebook (with Celeron 2955U CPU) has a controllable
backlight although its VBT reports otherwise. Apply quirk to ignore the
backlight presence check during backlight setup.
Patch tested by author on Toshiba CB35.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=79813
The Acer C720 and C720P Chromebooks (with Celeron 2955U CPU) have a
controllable backlight although their VBT reports otherwise. Apply quirk
to ignore the backlight presence check during backlight setup.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=79813
Tested-by: James Duley
From: Jani Nikula jani.nik...@intel.com
For Haswell and Broadwell, if the display power well has been disabled,
the display audio controller divider values EM4 M VALUE and EM5 N VALUE
will have been lost. The CDCLK frequency is required for reprogramming them
to generate 24MHz HD-A link BCLK. So
66 matches
Mail list logo
