On Mon, Nov 10, 2014 at 7:41 AM, Dave Airlie airl...@gmail.com wrote:
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_topology.c
index ce1113c..f703a5b 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -882,8
Since a8bb6818270c __intel_framebuffer_create() is called
with struct_mutex held, so it should use drm_gem_object_unreference()
instead of drm_gem_object_unreference_unlocked().
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Alexey Khoroshilov khoroshi...@ispras.ru
Hi Dave,
I'm trying to get your drm-i915-mst-v3.16[1] branch applied on top of
Ubuntu[2] kernel[3] to get HP's 840 notebook to handle two DPs port on
the docking station but I'm hitting some problems with your patches. Or
so I think.
If I start and boot with the laptop connected to the docking
On Fri, Nov 07, 2014 at 04:07:50PM -0800, Bob Paauwe wrote:
The pipe config needs to be initialized before calling crtc_compute_clock
since this will update the new_config structure DPLL values. Initializing
the new_config structure after calling crtc_compute_clock can result in
incorrect
Modifying PPS functions in intel_dp.c to avoid using too many conditional
statements based on platform.
Calling vlv_initial_power_sequencer_setup() from vlv specific pps functions
to just initialize vlv specific data and continue with the rest of the generic
code.
Signed-off-by: Vandana Kannan
vlv_power_sequencer_pipe() calls into init PPS functions. Changing this
function to make it only return pipe and not call PPS init.
This is because PPS init calls into this function to get a pipe ID and all
other callers just need the pipe ID.
Signed-off-by: Vandana Kannan
In the earlier RFC patch series, PPS related code was moved to intel_panel.c
to make it usable for all internal panels. In this patch series, the PPS
related functions are split based on platform in intel_dp.c itself.
This avoids having code split across intel_dp.c and intel_panel.c w.r.t
Calls to setup eDP panel power sequencer were there in dp_init_connector()
function. Moving these calls to edp_init_connector() to keep all PPS calls
together and under edp init.
Signed-off-by: Vandana Kannan vandana.kan...@intel.com
---
drivers/gpu/drm/i915/intel_dp.c | 15 +--
1
On Sat, 08 Nov 2014, Eoff, Ullysses A ullysses.a.e...@intel.com wrote:
On 09/24/2014 10:42 AM, Eoff, Ullysses A wrote:
-Original Message-
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf
Of Jani Nikula
Sent: Wednesday, September 24, 2014 10:08 AM
To: Hans
On 11/10/2014 11:40 AM, Ceraolo Spurio, Daniele wrote:
On 11/8/2014 8:44 AM, Chris Wilson wrote:
On Fri, Nov 07, 2014 at 05:45:01PM +,
daniele.ceraolospu...@intel.com wrote:
+/**
+ * DOC: execlist_submit_context tracepoint
+ *
+ * These tracepoint are used to track the contexts that are
On Mon, Nov 10, 2014 at 11:47 AM, Jani Nikula
jani.nik...@linux.intel.com wrote:
On Mon, 10 Nov 2014, Catalin Hritcu catalin.hri...@gmail.com wrote:
Dear Intel graphics driver community,
I'm a user experiencing display problems and joined this mailing list
to get some help with filing a
On Mon, 10 Nov 2014, Catalin Hritcu catalin.hri...@gmail.com wrote:
On Mon, Nov 10, 2014 at 11:47 AM, Jani Nikula
jani.nik...@linux.intel.com wrote:
On Mon, 10 Nov 2014, Catalin Hritcu catalin.hri...@gmail.com wrote:
Dear Intel graphics driver community,
I'm a user experiencing display
On 11/10/2014 11:54 AM, Chris Wilson wrote:
On Mon, Nov 10, 2014 at 11:40:40AM +, Ceraolo Spurio, Daniele wrote:
On 11/8/2014 8:44 AM, Chris Wilson wrote:
On Fri, Nov 07, 2014 at 05:45:01PM +, daniele.ceraolospu...@intel.com wrote:
+/**
+ * DOC: execlist_submit_context tracepoint
+ *
On Mon, Nov 10, 2014 at 12:58 PM, Jani Nikula
jani.nik...@linux.intel.com wrote:
On Mon, 10 Nov 2014, Catalin Hritcu catalin.hri...@gmail.com wrote:
On Mon, Nov 10, 2014 at 11:47 AM, Jani Nikula
jani.nik...@linux.intel.com wrote:
On Mon, 10 Nov 2014, Catalin Hritcu catalin.hri...@gmail.com
On Mon, Nov 10, 2014 at 12:28:11PM +, Ceraolo Spurio, Daniele wrote:
On 11/10/2014 11:54 AM, Chris Wilson wrote:
On Mon, Nov 10, 2014 at 11:40:40AM +, Ceraolo Spurio, Daniele wrote:
On 11/8/2014 8:44 AM, Chris Wilson wrote:
On Fri, Nov 07, 2014 at 05:45:01PM +,
Paulo noticed that we don't support RPS on GEN9 yet, so WARN for and
ignore any RPS interrupts on that platform.
Signed-off-by: Imre Deak imre.d...@intel.com
---
drivers/gpu/drm/i915/i915_irq.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_irq.c
We disable the RPS interrupts for all platforms at the same spot, so
move it one level up in the callstack to simplify things.
No functional change.
v2:
- rebase on the GEN9 patches where RPS isn't supported yet, so we don't
need to disable RPS interrupts on it (Paulo)
Signed-off-by: Imre
Hi Ben,
The below patch from Jani also touches nouveau, can you please take a
look at it an ack? The core part + nouveau apply on top of drm-next,
the i915 part needs stuff from my next queue. So I'd prefer if we can
get this in through drm-intel-next.
Hi Dave,
Ack on that from your side?
Atm we first enable the RPS interrupts then we clear any pending ones.
By this we could lose an interrupt arriving after we unmasked it. This
may not be a problem as the caller should handle such a race, but logic
still calls for the opposite order. Also we can delay enabling the
interrupts until
When disabling the RPS interrupts there is a tricky dependency between
the thread disabling the interrupts, the RPS interrupt handler and the
corresponding RPS work. The RPS work can reenable the interrupts, so
there is no straightforward order in the disabling thread to (1) make
sure that any RPS
From: Daniele Ceraolo Spurio daniele.ceraolospu...@intel.com
- ppgtt init/release: these tracepoints are useful for observing the
creation and destruction of Full PPGTTs.
- ctx create/free: we can use the ctx_free trace in combination with the
ppgtt_release one to be sure that the ppgtt
On Mon, Nov 10, 2014 at 03:41:05PM +0200, Imre Deak wrote:
Atm we first enable the RPS interrupts then we clear any pending ones.
By this we could lose an interrupt arriving after we unmasked it. This
may not be a problem as the caller should handle such a race, but logic
still calls for the
On Mon, 2014-11-10 at 13:45 +, Chris Wilson wrote:
On Mon, Nov 10, 2014 at 03:41:05PM +0200, Imre Deak wrote:
Atm we first enable the RPS interrupts then we clear any pending ones.
By this we could lose an interrupt arriving after we unmasked it. This
may not be a problem as the caller
On Mon, Nov 10, 2014 at 04:13:02PM +0200, Imre Deak wrote:
On Mon, 2014-11-10 at 13:45 +, Chris Wilson wrote:
On Mon, Nov 10, 2014 at 03:41:05PM +0200, Imre Deak wrote:
Atm we first enable the RPS interrupts then we clear any pending ones.
By this we could lose an interrupt arriving
On Mon, 10 Nov 2014, Jani Nikula jani.nik...@linux.intel.com wrote:
On Sat, 08 Nov 2014, Eoff, Ullysses A ullysses.a.e...@intel.com wrote:
On 09/24/2014 10:42 AM, Eoff, Ullysses A wrote:
-Original Message-
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf
Of
On Mon, 2014-11-10 at 14:15 +, Chris Wilson wrote:
On Mon, Nov 10, 2014 at 04:13:02PM +0200, Imre Deak wrote:
On Mon, 2014-11-10 at 13:45 +, Chris Wilson wrote:
On Mon, Nov 10, 2014 at 03:41:05PM +0200, Imre Deak wrote:
Atm we first enable the RPS interrupts then we clear any
Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
-Summary-
Platform: baseline_drm_intel_nightly_pass_rate-patch_applied_pass_rate
BYT: pass/total=249/348-248/348
PNV:
The PERF_PMU_CAP_IS_DEVICE flag provides pmu drivers a way to declare
that they only monitor device specific metrics and since they don't
monitor any cpu metrics then perf should bypass any cpu centric security
checks, as well as disallow cpu centric attributes.
Signed-off-by: Robert Bragg
Gen graphics hardware can be set up to periodically write snapshots of
performance counters into a circular buffer and this patch exposes that
capability to userspace via the perf interface.
Only Haswell is supported currently.
Signed-off-by: Robert Bragg rob...@sixbynine.org
---
To support pmu drivers in loadable modules, such as the i915 driver
Signed-off-by: Robert Bragg rob...@sixbynine.org
---
kernel/events/core.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/kernel/events/core.c b/kernel/events/core.c
index 1425d07..3abb368 100644
--- a/kernel/events/core.c
This is still a work in progress, but as I've started to get some useful
results with some simple igt tools and integration into Mesa too, others
could be interested in this proof-of-concept perf pmu driver to forward
Haswell Observation Architecture counters to userspace...
This has some
This adds i915_gem_context_pin/unpin_state functions so that code
outside i915_gem_context.c can pin/unpin a context without duplicating
knowledge about the alignment constraints.
Signed-off-by: Robert Bragg rob...@sixbynine.org
---
drivers/gpu/drm/i915/i915_drv.h | 4
Reviewed-by: Ander Conselvan de Oliveira ander.conselvan.de.olive...@intel.com
On 11/07/2014 11:11 PM, Jesse Barnes wrote:
This will allow us to consult more info before deciding whether to flip
or do a full mode set.
v2:
- don't use uninitialized or incorrect pipe masks in set_config
Reviewed-by: Ander Conselvan de Oliveira ander.conselvan.de.olive...@intel.com
On 11/06/2014 12:26 AM, Jesse Barnes wrote:
This allows us to calculate the full pipe config before we do any mode
setting work.
v2:
- clarify comments about global vs. per-crtc mode set (Ander)
- clean up
Reviewed-by: Ander Conselvan de Oliveira ander.conselvan.de.olive...@intel.com
On 11/06/2014 12:26 AM, Jesse Barnes wrote:
This is useful for checking things later.
v2:
- fix hsw infoframe enabled check (Ander)
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
Reviewed-by: Ander Conselvan de Oliveira ander.conselvan.de.olive...@intel.com
On 11/06/2014 12:26 AM, Jesse Barnes wrote:
This only affects the fastboot path as-is. In that case, we simply need
to make sure that we update the pipe size at the first mode set. Rather
than putting it off until
Reviewed-by: Ander Conselvan de Oliveira ander.conselvan.de.olive...@intel.com
On 11/06/2014 12:26 AM, Jesse Barnes wrote:
If these change (e.g. after a modeset following a fastboot), we need to
do a full mode set.
v2:
- put under pipe_config check so we don't deref a null state (Jesse)
On 11/06/2014 12:26 AM, Jesse Barnes wrote:
This should allow us to avoid mode sets for some panel fitter config
changes.
v2:
- fixup pfit comment (Ander)
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/intel_display.c | 61
On Mon, 10 Nov 2014 18:20:56 +0200
Ander Conselvan de Oliveira conselv...@gmail.com wrote:
On 11/06/2014 12:26 AM, Jesse Barnes wrote:
This should allow us to avoid mode sets for some panel fitter config
changes.
v2:
- fixup pfit comment (Ander)
Signed-off-by: Jesse Barnes
Arun Siluvery arun.siluv...@linux.intel.com writes:
From: Michel Thierry michel.thie...@intel.com
Following the legacy ring submission example, update the
ring-init_context() hook to support the execlist submission mode.
v2: update to use the new workaround macros and cleanup unused code.
From: Paulo Zanoni paulo.r.zan...@intel.com
Commit drm/i915: create a prepare phase for sprite plane updates
changed the old_obj pointer we use when committing sprite planes,
which caused a WARN() and a BUG() to be triggered. Later, commit
drm/i915: use intel_fb_obj() macros to assign gem objects
On Mon, 10 Nov 2014 16:15:57 +0200
Jani Nikula jani.nik...@linux.intel.com wrote:
On Mon, 10 Nov 2014, Jani Nikula jani.nik...@linux.intel.com wrote:
On Sat, 08 Nov 2014, Eoff, Ullysses A ullysses.a.e...@intel.com
wrote:
On 09/24/2014 10:42 AM, Eoff, Ullysses A wrote:
-Original
On Mon, Nov 10, 2014 at 02:47:30PM -0200, Paulo Zanoni wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
Commit drm/i915: create a prepare phase for sprite plane updates
changed the old_obj pointer we use when committing sprite planes,
which caused a WARN() and a BUG() to be triggered.
On Thu, 6 Nov 2014 14:10:49 +0100
Daniel Vetter dan...@ffwll.ch wrote:
On Thu, Nov 06, 2014 at 02:49:12PM +0200,
ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
We may need to access various hardware bits in
the .global_resources() hook, so move
On Mon, Nov 10, 2014 at 09:14:11AM -0800, Jesse Barnes wrote:
On Thu, 6 Nov 2014 14:10:49 +0100
Daniel Vetter dan...@ffwll.ch wrote:
On Thu, Nov 06, 2014 at 02:49:12PM +0200,
ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
We may need to
On Fri, Nov 07 2014, David Airlie airl...@redhat.com wrote:
Just try a 3.17 based kernel if you can.
I've tried with 3.17.2 and have similar results. I got no BUGs during
boot and even:
Console: switching to colour frame buffer device 240x67
i915 :00:02.0: fb0: inteldrmfb frame buffer
On Mon, 3 Nov 2014 11:39:24 +0100
Daniel Vetter daniel.vet...@ffwll.ch wrote:
On pre-ddi platforms we don't shut down the link when changing link
training parameters. Except when clock recovery fails too hard and we
restart with channel eq training. Which doesn't make a lot of sense
really,
On Fri, 7 Nov 2014 18:41:16 +0100
Daniel Vetter dan...@ffwll.ch wrote:
On Tue, Nov 04, 2014 at 03:29:57PM +0100, Daniel Vetter wrote:
Fastboot in its current incarnation assumes that the pfit isn't
relevatn for the state and that it can be disabled without
restarting the crtc.
On Mon, 10 Nov 2014 19:24:37 +0200
Ville Syrjälä ville.syrj...@linux.intel.com wrote:
On Mon, Nov 10, 2014 at 09:14:11AM -0800, Jesse Barnes wrote:
On Thu, 6 Nov 2014 14:10:49 +0100
Daniel Vetter dan...@ffwll.ch wrote:
On Thu, Nov 06, 2014 at 02:49:12PM +0200,
On Mon, Nov 10, 2014 at 10:01:56AM -0800, Jesse Barnes wrote:
On Mon, 3 Nov 2014 11:39:24 +0100
Daniel Vetter daniel.vet...@ffwll.ch wrote:
On pre-ddi platforms we don't shut down the link when changing link
training parameters. Except when clock recovery fails too hard and we
restart
On Fri, 2014-11-07 at 12:08 +, Damien Lespiau wrote:
On Tue, Sep 16, 2014 at 04:19:07PM +0300, Imre Deak wrote:
@@ -1233,6 +1233,9 @@ static bool edp_panel_vdd_on(struct intel_dp
*intel_dp)
power_domain = intel_display_port_power_domain(intel_encoder);
Similar to:
commit 02c9f7e3cfe76a7f54ef03438c36aade86cc1c8b
Author: Kenneth Graunke kenn...@whitecape.org
Date: Mon Jan 27 14:20:16 2014 -0800
drm/i915: Add the WaCsStallBeforeStateCacheInvalidate:bdw workaround.
On Broadwell, any PIPE_CONTROL with the State Cache Invalidate bit set
From: Chris Wilson ch...@chris-wilson.co.uk
Currently objects for which the hardware needs a contiguous physical
address are allocated a shadow backing storage to satisfy the contraint.
This shadow buffer is not wired into the normal obj-pages and so the
physical object is incoherent with
To be used for a Workaroud. Similar to:
commit 884ceacee308f0e4616d0c933518af2639f7b1d8
Author: Kenneth Graunke kenn...@whitecape.org
Date: Sat Jun 28 02:04:20 2014 +0300
drm/i915: Refactor Broadwell PIPE_CONTROL emission into a helper.
Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com
From: Zhipeng Gong zhipeng.g...@intel.com
This will let userland only try to use the new ring
when the appropriate kernel is present
Signed-off-by: Zhipeng Gong zhipeng.g...@intel.com
Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com
---
drivers/gpu/drm/i915/i915_dma.c | 3 +++
From: Mika Kuoppala mika.kuopp...@linux.intel.com
As per latest pm guide, we need to do this also on
past hsw.
Cc: Ville Syrjälä ville.syrj...@linux.intel.com
Cc: Chris Wilson ch...@chris-wilson.co.uk
Cc: Damien Lespiau damien.lesp...@intel.com
Signed-off-by: Mika Kuoppala
This is another drm-intel-collector updated notice:
http://cgit.freedesktop.org/~vivijim/drm-intel/log/?h=drm-intel-collector
Here goes the update list in order for better reviewers assignment:
Patch drm/i915: Make the physical object coherent with GTT - Reviewed-by:
Ville
Patch
From: Chris Wilson ch...@chris-wilson.co.uk
Sometimes we wish to tweak how an individual context behaves. Since we
always create a context for every filp, this means that individual
processes can fine tune their behaviour even if they do not explicitly
create a context.
The first example
From: Chris Wilson ch...@chris-wilson.co.uk
This will allow us to set per-file, or even per-context, periods in the
future.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h | 5 +
From: Zhipeng Gong zhipeng.g...@intel.com
On Broadwell GT3 we have 2 Video Command Streamers (VCS), but userspace
has no control when using VCS1 or VCS2. This patch introduces a mechanism
to avoid the default ping-pong mode and use one specific ring through
execution flag.
v2: fix whitespace
On Thu, 6 Nov 2014 19:35:51 -0500
Rob Clark robdcl...@gmail.com wrote:
On Thu, Nov 6, 2014 at 6:29 PM, Daniel Vetter dan...@ffwll.ch wrote:
That aside I guess I need to elaborate on what makes dpms special in
i915, and why there's a real difference between crtc-enable == true
-active ==
Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
-Summary-
Platform: baseline_drm_intel_nightly_pass_rate-patch_applied_pass_rate
BYT: pass/total=277/348-276/348
PNV:
From: Ville Syrjälä ville.syrj...@linux.intel.com
The divider used in the GPU frequency calculations is compatible between
vlv and chv. vlv just wants doubled values compared to chv.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/intel_pm.c | 104
From: Ville Syrjälä ville.syrj...@linux.intel.com
Currently we miscalculate the GPU frequency on chv. This causes us to
report the GPU frequency as half of what it really is. Drop the extra
factor of 2 from the calculations to get the correct answer.
Signed-off-by: Ville Syrjälä
From: Ville Syrjälä ville.syrj...@linux.intel.com
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/intel_pm.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index
From: Ville Syrjälä ville.syrj...@linux.intel.com
According to Cherryview_GFXclocks_y14w36d1.xlsx the GPU frequency
divider should be 10 in when the CZ clock is 400 MHz. Change the code
to agree so that we report the correct frequencies.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
Adding relevant mailing lists.
On Sat, Nov 8, 2014 at 7:34 PM, Emmanuel Benisty benist...@gmail.com wrote:
Hi,
The following commit permanently turns my screen off when x server is
started (i3 330M Ironlake):
[83f45fc360c8e16a330474860ebda872d1384c8c] drm: Don't grab an fb
reference
From: Ville Syrjälä ville.syrj...@linux.intel.com
I was staring at the GPU frquencies my BSW reports and they didn't seem
to match the docs exactly, so I set out to fix a few things. Now things
should match what the docs. No idea if the docs are correct anymore
though, but at least the date on
On Mon, 10 Nov 2014 12:40:47 +0200
Ville Syrjälä ville.syrj...@linux.intel.com wrote:
On Fri, Nov 07, 2014 at 04:07:50PM -0800, Bob Paauwe wrote:
The pipe config needs to be initialized before calling crtc_compute_clock
since this will update the new_config structure DPLL values.
Use the new pipe config values to calculate the updated pll dividers.
This regression was introduced in
commit 0dbdf89f27b17ae1eceed6782c2917f74cbb5d59
Author: Ander Conselvan de Oliveira ander.conselvan.de.olive...@intel.com
Date: Wed Oct 29 11:32:33 2014 +0200
drm/i915: Add
On Tue, Oct 28, 2014 at 04:20:48PM +0200, Jani Nikula wrote:
The Baseline_ELD_Len field does not include ELD Header Block size.
From High Definition Audio Specification, Revision 1.0a:
The header block is a fixed size of 4 bytes. The baseline block
is variable size in multiple
Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
-Summary-
Platform: baseline_drm_intel_nightly_pass_rate-patch_applied_pass_rate
BYT: pass/total=277/348-277/348
PNV:
Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
-Summary-
Platform: baseline_drm_intel_nightly_pass_rate-patch_applied_pass_rate
BYT: pass/total=277/348-276/348
PNV:
On Saturday 08 November 2014 01:03 AM, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
When reading a CCK register we should obviously read it from CCK not
Punit. This problem has been present ever since this of code was
introduced in
commit
74 matches
Mail list logo
