On Saturday 08 November 2014 01:03 AM, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä
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 67c3bf6f55a97a0915a0f9ea07278a3073cc9601
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: pass/total=323/328->325
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: pass/total=323/328->326
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 mult
Use the new pipe config values to calculate the updated pll dividers.
This regression was introduced in
commit 0dbdf89f27b17ae1eceed6782c2917f74cbb5d59
Author: Ander Conselvan de Oliveira
Date: Wed Oct 29 11:32:33 2014 +0200
drm/i915: Add infrastructure for choosing DPLLs before disabling
On Mon, 10 Nov 2014 12:40:47 +0200
Ville Syrjälä 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. Initializing
> > the new_config stru
From: Ville Syrjälä
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 the spreadsheet I used was fairl
Adding relevant mailing lists.
On Sat, Nov 8, 2014 at 7:34 PM, Emmanuel Benisty 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 for the idr
>
From: Ville Syrjälä
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ä
---
drivers/gpu/drm/i915/intel_pm.c | 3 ++-
1 file cha
From: Ville Syrjälä
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ä
---
drivers/gpu/drm/i915/intel_pm.c | 4 ++--
From: Ville Syrjälä
Signed-off-by: Ville Syrjälä
---
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 74e4293..0f5c391 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++
From: Ville Syrjälä
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ä
---
drivers/gpu/drm/i915/intel_pm.c | 104 ++--
1 file changed, 35 insertion
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: pass/total=323/328->324
On Thu, 6 Nov 2014 19:35:51 -0500
Rob Clark wrote:
> On Thu, Nov 6, 2014 at 6:29 PM, Daniel Vetter 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 == false and crtc->enabl
From: Chris Wilson
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 parameter here is to enable mult
From: Chris Wilson
This will allow us to set per-file, or even per-context, periods in the
future.
Signed-off-by: Chris Wilson
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/i915_drv.h | 5 +
drivers/gpu/drm/i915/i915_gem.c | 3 ++-
drivers/gpu/drm/i915/i915_gem_cont
From: Zhipeng Gong
This will let userland only try to use the new ring
when the appropriate kernel is present
Signed-off-by: Zhipeng Gong
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/i915_dma.c | 3 +++
include/uapi/drm/i915_drm.h | 1 +
2 files changed, 4 insertions(+)
diff --gi
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 drm/i91
From: Mika Kuoppala
As per latest pm guide, we need to do this also on
past hsw.
Cc: Ville Syrjälä
Cc: Chris Wilson
Cc: Damien Lespiau
Signed-off-by: Mika Kuoppala
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/intel_uncore.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
d
From: Zhipeng Gong
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 (Rodrigo)
Signed-off-by:
To be used for a Workaroud. Similar to:
commit 884ceacee308f0e4616d0c933518af2639f7b1d8
Author: Kenneth Graunke
Date: Sat Jun 28 02:04:20 2014 +0300
drm/i915: Refactor Broadwell PIPE_CONTROL emission into a helper.
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/intel_lrc.c | 35 ++
Similar to:
commit 02c9f7e3cfe76a7f54ef03438c36aade86cc1c8b
Author: Kenneth Graunke
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
must be preceded
From: Chris Wilson
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 accesses via the GPU, GTT and C
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);
> > > intel_displ
On Mon, Nov 10, 2014 at 10:01:56AM -0800, Jesse Barnes wrote:
> On Mon, 3 Nov 2014 11:39:24 +0100
> Daniel Vetter 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
On Mon, 10 Nov 2014 19:24:37 +0200
Ville Syrjälä 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 wrote:
> >
> > > On Thu, Nov 06, 2014 at 02:49:12PM +0200,
> > > ville.syrj...@linux.intel.com wrote:
> > > > From: Vil
On Fri, 7 Nov 2014 18:41:16 +0100
Daniel Vetter 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. Unfortunately that's
On Mon, 3 Nov 2014 11:39:24 +0100
Daniel Vetter 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, since just stopping
On Fri, Nov 07 2014, David Airlie 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 device
i915
On Mon, Nov 10, 2014 at 09:14:11AM -0800, Jesse Barnes wrote:
> On Thu, 6 Nov 2014 14:10:49 +0100
> Daniel Vetter wrote:
>
> > On Thu, Nov 06, 2014 at 02:49:12PM +0200,
> > ville.syrj...@linux.intel.com wrote:
> > > From: Ville Syrjälä
> > >
> > > We may need to access various hardware bits in
On Thu, 6 Nov 2014 14:10:49 +0100
Daniel Vetter wrote:
> On Thu, Nov 06, 2014 at 02:49:12PM +0200,
> ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > We may need to access various hardware bits in
> > the .global_resources() hook, so move the call to occur after
> > enabling
On Mon, Nov 10, 2014 at 02:47:30PM -0200, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> 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/i
On Mon, 10 Nov 2014 16:15:57 +0200
Jani Nikula wrote:
> On Mon, 10 Nov 2014, Jani Nikula wrote:
> > On Sat, 08 Nov 2014, "Eoff, Ullysses A"
> > wrote:
> >> On 09/24/2014 10:42 AM, Eoff, Ullysses A wrote:
> -Original Message-
> From: Intel-gfx [mailto:intel-gfx-boun...@lists.fr
From: Paulo Zanoni
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" introduced
the same
Arun Siluvery writes:
> From: Michel Thierry
>
> 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.
> This takes care of both bdw and chv workaround
On Mon, 10 Nov 2014 18:20:56 +0200
Ander Conselvan de Oliveira 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
> > ---
>
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
---
drivers/gpu/drm/i915/intel_display.c | 61 +---
1 file changed, 50 in
Reviewed-by: Ander Conselvan de Oliveira
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)
>
> Signed-off-by: Jesse Barnes
Reviewed-by: Ander Conselvan de Oliveira
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 we decide to flip (if indeed we do
Reviewed-by: Ander Conselvan de Oliveira
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
> ---
> drivers/gpu/drm/i915/intel_drv.h | 4 +++
> drivers/gpu/drm/i915/
Reviewed-by: Ander Conselvan de Oliveira
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 unnecessary pipe_config = NULL
Reviewed-by: Ander Conselvan de Oliveira
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
> failure path (Ander)
> v3:
>
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
---
drivers/gpu/drm/i915/Makefile
To support pmu drivers in loadable modules, such as the i915 driver
Signed-off-by: Robert Bragg
---
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
+++ b/kernel/events/co
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 similari
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
---
drivers/gpu/drm/i915/i915_drv.h | 4
drivers/gpu/drm/i915/i915_gem_con
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
---
i
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: pass/total=323/328->325
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 clea
On Mon, 10 Nov 2014, Jani Nikula wrote:
> On Sat, 08 Nov 2014, "Eoff, Ullysses A" 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, Se
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 ar
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 c
From: Daniele Ceraolo Spurio
- 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 doesn't stay alive for too
long af
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 th
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
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 a
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?
Cheer
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 Deak
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
---
drivers/gpu/drm/i915/i915_irq.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
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 +, daniele.cer
On Mon, Nov 10, 2014 at 12:58 PM, Jani Nikula
wrote:
> On Mon, 10 Nov 2014, Catalin Hritcu wrote:
>> On Mon, Nov 10, 2014 at 11:47 AM, Jani Nikula
>> wrote:
>>> On Mon, 10 Nov 2014, Catalin Hritcu wrote:
Dear Intel graphics driver community,
I'm a user experiencing display proble
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, 10 Nov 2014, Catalin Hritcu wrote:
> On Mon, Nov 10, 2014 at 11:47 AM, Jani Nikula
> wrote:
>> On Mon, 10 Nov 2014, Catalin Hritcu wrote:
>>> Dear Intel graphics driver community,
>>>
>>> I'm a user experiencing display problems and joined this mailing list
>>> to get some help with fili
On Mon, Nov 10, 2014 at 11:47 AM, Jani Nikula
wrote:
> On Mon, 10 Nov 2014, Catalin Hritcu 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 proper bug report. In particular,
>> I'm unsure
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
sub
On Sat, 08 Nov 2014, "Eoff, Ullysses A" 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 de Goede;
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
---
drivers/gpu/drm/i915/intel_dp.c | 15 +--
1 file changed, 5 insertions(
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
pps_loc
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
---
drivers/gpu/drm/i9
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 t
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
---
drivers/gpu/drm/
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 s
On Mon, Nov 10, 2014 at 7:41 AM, Dave Airlie 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 +882,10 @@ sta
74 matches
Mail list logo
