Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 7248
-Summary-
Platform Delta drm-intel-nightly Series Applied
ILK -2
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 7243
-Summary-
Platform Delta drm-intel-nightly Series Applied
ILK
As suggested by Ville, the general flow should now roughly follow:
// whatever the user wanted
compute_final_atomic_state()
// include all crtcs in the intermediate state which are
// getting disabled (even temporarily to perform a modeset)
compute_intermed
To simplify the modeset process for atomic, start calculating an
"intermediate" state for any CRTC's which undergo a modeset (or get
permanently disabled). This state represents the status of the CRTC and
planes at the point in which the CRTC's have been disabled; i.e.,
intermediate_state->active
Way back at the beginning of i915's atomic conversion I added
intel_crtc->atomic as a temporary dumping ground for "stuff to do
outside vblank evasion" flags since CRTC states weren't properly wired
up and tracked at that time. We've had proper CRTC state tracking for a
while now, so there's reall
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 7240
-Summary-
Platform Delta drm-intel-nightly Series Applied
ILK
2015-08-28 16:59 GMT-03:00 :
> From: Ville Syrjälä
>
> On GMCH plaforms we are now getting the following spew on aux
> interrupts:
> [drm:intel_get_hpd_pins] hotplug event received, stat 0x, dig
> 0x, pins 0x
> [drm:intel_get_hpd_pins] hotplug event received, stat 0x0
2015-08-27 17:56 GMT-03:00 :
> From: Ville Syrjälä
>
> Pass the correct hpd[] array to intel_get_hpd_pins() on pre-g4x
> platforms.
>
> This got broken in the following commit:
> commit fd63e2a972c670887e5e8a08440111d3812c0996
> Author: Imre Deak
> Date: Tue Jul 21 15:32:44 2015 -0700
>
>
2015-08-27 17:56 GMT-03:00 :
> From: Ville Syrjälä
>
> Rewrite the BXT hpd setup to match the way we do it on other platforms:
> - Throw out BXT_HOTPLUG_CTL since it's the same as PCH_PORT_HOTPLUG
> - Enable the HPD bits in the DE port IER in gen8_de_irq_postinstall()
> - Update DE port IMR using
2015-08-27 17:56 GMT-03:00 :
> From: Ville Syrjälä
>
> A lot of the hpd irq handling is duplicated code, so refactor it a bit
> by observing that in several places the only difference is the hpd[]
> array. So pull the code to a few functions and pass in the hpd[] array
> from the caller. Another
On Fri, 28 Aug 2015 17:12:12 +0100
Daniel Stone wrote:
> Hi,
>
> On 28 August 2015 at 16:55, Bob Paauwe wrote:
> > On Fri, 28 Aug 2015 15:19:04 +0100
> > Daniel Stone wrote:
> >> For both this and the previous patch, cf. the corresponding patch for
> >> HSW/BDW[0], have you ensured these value
2015-08-27 17:56 GMT-03:00 :
> From: Ville Syrjälä
>
> bxt_hpd_handler() looks different to everyone else for no good reason.
> Rewrite it to use the standard variable namees etc.
Reviewed-by: Paulo Zanoni
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/i915_irq.c | 37
2015-08-27 17:56 GMT-03:00 :
> From: Ville Syrjälä
>
> Wire up the port A HPD for BDW. Compared to earlier platforms the
> interrupt setup is a bit different, but basically everything else
> looks the same.
>
> v2: 0 initialize pin_mask/long_mask due to intel_get_hpd_pins() changes
> Check fo
From: Ville Syrjälä
On GMCH plaforms we are now getting the following spew on aux
interrupts:
[drm:intel_get_hpd_pins] hotplug event received, stat 0x, dig
0x, pins 0x
[drm:intel_get_hpd_pins] hotplug event received, stat 0x, dig
0x, pins 0x
[drm:
On Fri, Aug 28, 2015 at 03:20:33PM -0300, Paulo Zanoni wrote:
> 2015-08-27 17:56 GMT-03:00 :
> > From: Ville Syrjälä
> >
> > Starting from SPT the only interrupts living in the south are GMBUS and
> > HPD. What's worse some of the SPT specific new bits conflict with some
> > other bits on earlier
From: Ville Syrjälä
Move the 0 initialization of pin_mask and long_mask from
intel_get_hpd_pins() into each caller. This we we can call
intel_get_hpd_pins() multiple times to accumulate more pins from several
sources.
v2: Add a comment explaining the dangers of intel_get_hpd_pins() (Paulo)
Revi
On Fri, Aug 28, 2015 at 03:01:50PM -0300, Paulo Zanoni wrote:
> 2015-08-27 17:56 GMT-03:00 :
> > From: Ville Syrjälä
> >
> > Move the 0 initialization of pin_mask and long_mask from
> > intel_get_hpd_pins() into each caller. This we we can call
> > intel_get_hpd_pins() multiple times to accumulat
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 7238
-Summary-
Platform Delta drm-intel-nightly Series Applied
ILK -3
2015-08-27 17:56 GMT-03:00 :
> From: Ville Syrjälä
>
> Starting from SPT the only interrupts living in the south are GMBUS and
> HPD. What's worse some of the SPT specific new bits conflict with some
> other bits on earlier PCH generations. So better not use the
> cpt_irq_handler() for SPT+ anymo
2015-08-27 17:56 GMT-03:00 :
> From: Ville Syrjälä
>
> Move the 0 initialization of pin_mask and long_mask from
> intel_get_hpd_pins() into each caller. This we we can call
> intel_get_hpd_pins() multiple times to accumulate more pins from several
> sources.
Hmm... I'm not a big fan of this appr
On Fri, Aug 14, 2015 at 06:34:21PM -0300, Paulo Zanoni wrote:
> This commit is essentially a rewrite of "drm/i915: Check pixel format
> for fbc" from Ville Syrjälä. The idea is the same, but the code is
> different due to all the changes that happened since his original
> patch. So any bugs are due
On Fri, Aug 14, 2015 at 06:34:19PM -0300, Paulo Zanoni wrote:
> This WA is only for HSW/BDW.
w/a db says it was needed for early SKL, but we can ignore it. w/a db
still has it for BXT. I guess we can hope BXT would be fixed too if SKL
is.
Reviewed-by: Ville Syrjälä
>
> Signed-off-by: Paulo Zan
On Fri, Aug 14, 2015 at 06:34:17PM -0300, Paulo Zanoni wrote:
> The spec says the register should have that value for the entire time
> that FBC is enabled, so apply the WA before we enable FBC.
>
> Notice that we also have this WA for ILK/SNB, but it is implemented at
> init_clock_gating(). I cou
On Fri, Aug 14, 2015 at 06:34:16PM -0300, Paulo Zanoni wrote:
> BSpec says we shouldn't enable FBC on BDW when the pipe pixel rate
> exceeds 95% of the core display clock.
w/a db says HSW has the same issue, apparently it was found on HSW
originally. Actually it says BDW G0 would have it fixed. Bs
On Fri, 28 Aug 2015, Gary Wang wrote:
> Since BIOS RC 1.4 it would enable CDCLK PLL during BIOS S3 resume, then
> driver needs to set CDCLK to avoid display corruption if DPLL0 enabled.
>
> References: https://bugs.freedesktop.org/show_bug.cgi?id=91697
> Reviewed-by: Rodrigo Vivi
> Reviewed-by: D
On Fri, Aug 14, 2015 at 06:34:15PM -0300, Paulo Zanoni wrote:
> We were considering the whole framebuffer height, but the spec clearly
> says that we should only consider the active display height size.
>
> On my current testing machine, this moves us from 124 successes and
> 502 skips to 209 succ
On Fri, 28 Aug 2015, David Henningsson wrote:
> Hopefully last version? :-)
>
> * Added commit text about duplicate events (patch 4/4)
> * Added locks in bind/unbind on i915 side (patch 2/4)
> * Fixed docbook comments in i915 struct (patch 1/4)
> * Removed port_mst_streaming parameter (patch 1
On Fri, Aug 14, 2015 at 06:34:14PM -0300, Paulo Zanoni wrote:
> And also print the threshold. I was surprised to see a log message
> claiming the CFB size was 32mb when there was less than 24mb available
> for it.
>
> Signed-off-by: Paulo Zanoni
> ---
> drivers/gpu/drm/i915/intel_fbc.c | 5 +++--
This lets the interested codec be notified when an i915 pin/ELD
event happens.
Reviewed-by: Takashi Iwai
Signed-off-by: David Henningsson
---
include/sound/hda_i915.h | 7 +++
sound/hda/hdac_i915.c| 10 ++
2 files changed, 17 insertions(+)
diff --git a/include/sound/hda_i915.h
When the audio codec is enabled or disabled, notify the audio driver.
This will enable the audio driver to get the notification at all times
(even when audio is in different powersave states).
Reviewed-by: Jani Nikula
Signed-off-by: David Henningsson
---
drivers/gpu/drm/i915/i915_drv.h| 1
Hopefully last version? :-)
* Added commit text about duplicate events (patch 4/4)
* Added locks in bind/unbind on i915 side (patch 2/4)
* Fixed docbook comments in i915 struct (patch 1/4)
* Removed port_mst_streaming parameter (patch 1/4)
* Added Reviewed-by - 1 & 2 by Jani, 3 & 4 by Takashi
This callback will be called by the i915 driver to notify the hda
driver that its HDMI information needs to be refreshed, i e,
that audio output is now available (or unavailable) - usually as a
result of a monitor being plugged in (or unplugged).
Reviewed-by: Jani Nikula
Signed-off-by: David Henn
Whenever there is an event from the i915 driver, wake the codec
and recheck plug/unplug + ELD status.
This fixes the issue with lost unsol events in power save mode,
the codec and controller can now sleep in D3 and still know when
the HDMI monitor has been connected.
Right now, this might mean we
On Fri, Aug 14, 2015 at 06:34:11PM -0300, Paulo Zanoni wrote:
> Keep searching in case the candidate has a NULL primary fb. This is
> only relevant for the platforms that don't have the pipe_a_only
> restriction.
>
> Signed-off-by: Paulo Zanoni
> ---
> drivers/gpu/drm/i915/intel_fbc.c | 6 ++
Hi,
On 28 August 2015 at 16:55, Bob Paauwe wrote:
> On Fri, 28 Aug 2015 15:19:04 +0100
> Daniel Stone wrote:
>> For both this and the previous patch, cf. the corresponding patch for
>> HSW/BDW[0], have you ensured these values are sanitised at startup,
>> even if UEFI hasn't set something clever
Hi all,
New -testing cycle with cool stuff:
Somehow I've forgotten to do a new dinq tag 2 weeks ago, so this covers 4 weeks.
Still not all that much due to vacation:
- PML4 pagetable support for 48b from Michel Thierry
- more fixes for sink crc from Rodrigo
- DP link settings cleanup from Ville
-
On Fri, 28 Aug 2015 15:19:04 +0100
Daniel Stone wrote:
> Hi Bob,
>
> On 27 August 2015 at 21:46, Bob Paauwe wrote:
> > Extend this to SKL and BXT as it's needed for these platforms as well.
> >
> > Signed-off-by: Bob Paauwe
> > ---
> > drivers/gpu/drm/i915/intel_display.c | 3 ++-
> > 1 file
On Fri, Aug 28, 2015 at 05:51:46PM +0300, Mika Kuoppala wrote:
> Sometimes it is beneficial to debug the forcewake registers
> themselves or registers that don't need or are interfered by
> forcewake. Add parameter to intel_register_access_init()
> to optionally avoid forcewake dance around registe
On Fri, Aug 28, 2015 at 6:12 AM Damien Lespiau
wrote:
> On Fri, Aug 28, 2015 at 04:40:34PM +0800, Gary Wang wrote:
> > Since BIOS RC 1.4 it would enable CDCLK PLL during BIOS S3 resume, then
> > driver needs to set CDCLK to avoid display corruption if DPLL0 enabled.
> >
> > References: https://bu
On Fri, Aug 28, 2015 at 11:50:08AM -0300, Paulo Zanoni wrote:
> 2015-08-28 11:20 GMT-03:00 Ville Syrjälä :
> > On Fri, Aug 14, 2015 at 06:34:07PM -0300, Paulo Zanoni wrote:
> >> Always update the currrent crtc, fb and vertical offset after calling
> >> enable_fbc. We were forgetting to do so along
This appears to make all the cursor tests really slow because of the many calls
to skl_update_wm
when the cursor plane visibility is changed. It performs does 3 vblanks each
time it's called, and
it's probably called more than once on each update.
Smarter watermark updates will hopefully fix thi
On Fri, Aug 14, 2015 at 06:34:10PM -0300, Paulo Zanoni wrote:
> I could only find the restrictions for HSW+, but I think it's safe to
> assume that the older platforms also can't support the configurations
> HSW can't support. The older platforms probably have additional
> restrictions, so we need
On Fri, 28 Aug 2015, Mika Kuoppala wrote:
> Use the pre configured pci device from config also
> in write path.
>
> Cc: Jani Nikula
> Signed-off-by: Mika Kuoppala
> ---
> tools/intel_reg.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/tools/intel_reg.c b/tools/intel_r
On Fri, 28 Aug 2015, Mika Kuoppala wrote:
> Sometimes we want to inspect the hardware as it is,
> without doing the forcewake before access. Add option to skip
> the forcewake dance.
This needs a manual page update.
Some trivial comments below, otherwise lgtm.
>
> Cc: Jani Nikula
> Signed-off-
On Fri, 28 Aug 2015, Mika Kuoppala wrote:
> Sometimes it is beneficial to debug the forcewake registers
> themselves or registers that don't need or are interfered by
> forcewake. Add parameter to intel_register_access_init()
> to optionally avoid forcewake dance around register access.
>
> Signed
Sometimes we want to inspect the hardware as it is,
without doing the forcewake before access. Add option to skip
the forcewake dance.
Cc: Jani Nikula
Signed-off-by: Mika Kuoppala
---
tools/intel_reg.c | 17 ++---
1 file changed, 14 insertions(+), 3 deletions(-)
diff --git a/tools/
Use the pre configured pci device from config also
in write path.
Cc: Jani Nikula
Signed-off-by: Mika Kuoppala
---
tools/intel_reg.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/intel_reg.c b/tools/intel_reg.c
index 190aa5b..2b60a83 100644
--- a/tools/intel_reg.c
++
Sometimes it is beneficial to debug the forcewake registers
themselves or registers that don't need or are interfered by
forcewake. Add parameter to intel_register_access_init()
to optionally avoid forcewake dance around register access.
Signed-off-by: Mika Kuoppala
---
debugger/debug_rdata.c
2015-08-28 11:20 GMT-03:00 Ville Syrjälä :
> On Fri, Aug 14, 2015 at 06:34:07PM -0300, Paulo Zanoni wrote:
>> Always update the currrent crtc, fb and vertical offset after calling
>> enable_fbc. We were forgetting to do so along the failure paths when
>> enabling fbc synchronously. Fix this with a
On Fri, Aug 14, 2015 at 06:34:09PM -0300, Paulo Zanoni wrote:
> The doc is pretty clear that this register should be set to 0 on SNB.
> We already write y_offset to DPFC_CPU_FENCE_OFFSET a few lines below.
Bspec says:
"Restriction : The CPU fence is always programmed to match the Display
Buffer b
Thomas Wood writes:
> Add the debug and warning flags to cflags and fix the resulting issues.
>
> Signed-off-by: Thomas Wood
Much better now,
Reviewed-by: Mika Kuoppala
> ---
> tools/null_state_gen/Makefile.am | 2 ++
> tools/null_state_gen/intel_batchbuffer.c | 7 +++--
On Fri, Aug 14, 2015 at 06:34:08PM -0300, Paulo Zanoni wrote:
> I only tested this on BDW, but since the register description is the
> same ever since gen4, let's assume that all gens take the same
> register format. If that's not true, then hopefully someone will
> bisect a bug to this patch and w
On Fri, Aug 14, 2015 at 06:34:07PM -0300, Paulo Zanoni wrote:
> Always update the currrent crtc, fb and vertical offset after calling
> enable_fbc. We were forgetting to do so along the failure paths when
> enabling fbc synchronously. Fix this with a new helper to enable_fbc()
> and update the stat
Add the debug and warning flags to cflags and fix the resulting issues.
Signed-off-by: Thomas Wood
---
tools/null_state_gen/Makefile.am | 2 ++
tools/null_state_gen/intel_batchbuffer.c | 7 +++---
tools/null_state_gen/intel_batchbuffer.h | 4 +++-
tools/null_state_gen/i
Hi Bob,
On 27 August 2015 at 21:46, Bob Paauwe wrote:
> Extend this to SKL and BXT as it's needed for these platforms as well.
>
> Signed-off-by: Bob Paauwe
> ---
> drivers/gpu/drm/i915/intel_display.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i9
On Fri, Aug 14, 2015 at 06:34:06PM -0300, Paulo Zanoni wrote:
> We used to have this bug in the past, but now that we properly track
> the size of the CFB, we don't have it anymore. Still, add the WARN
> just to make sure we don't go back to the bad state.
>
> Signed-off-by: Paulo Zanoni
> ---
>
On Thu, 2015-08-20 at 18:12 -0700, Matt Roper wrote:
> Signed-off-by: Matt Roper
> ---
> drivers/gpu/drm/i915/i915_drv.h | 10 ++
> drivers/gpu/drm/i915/intel_display.c | 51 ++--
> drivers/gpu/drm/i915/intel_drv.h | 1 +
> drivers/gpu/drm/i915/intel_pm.c
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 7233
-Summary-
Platform Delta drm-intel-nightly Series Applied
ILK -1
On 2015-08-28 15:07, Jani Nikula wrote:
On Wed, 19 Aug 2015, David Henningsson wrote:
When the audio codec is enabled or disabled, notify the audio driver.
This will enable the audio driver to get the notification at all times
(even when audio is in different powersave states).
Signed-off-by
On Fri, Aug 28, 2015 at 04:40:34PM +0800, Gary Wang wrote:
> Since BIOS RC 1.4 it would enable CDCLK PLL during BIOS S3 resume, then
> driver needs to set CDCLK to avoid display corruption if DPLL0 enabled.
>
> References: https://bugs.freedesktop.org/show_bug.cgi?id=91697
> Reviewed-by: Rodrigo V
On Thu, 20 Aug 2015, Takashi Iwai wrote:
> On Thu, 20 Aug 2015 11:41:42 +0200,
> David Henningsson wrote:
>>
>>
>>
>> On 2015-08-20 11:28, Takashi Iwai wrote:
>> > On Wed, 19 Aug 2015 10:48:58 +0200,
>> > David Henningsson wrote:
>> >>
>> >> Whenever there is an event from the i915 driver, wake
On Wed, 19 Aug 2015, David Henningsson wrote:
> When the audio codec is enabled or disabled, notify the audio driver.
> This will enable the audio driver to get the notification at all times
> (even when audio is in different powersave states).
>
> Signed-off-by: David Henningsson
> ---
> driver
On Thu, 2015-08-20 at 18:12 -0700, Matt Roper wrote:
> Calculate pipe watermarks during atomic calculation phase, based on the
> contents of the atomic transaction's state structure. We still program
> the watermarks at the same time we did before, but the computation now
> happens much earlier.
>
On Thu, 2015-08-20 at 18:12 -0700, Matt Roper wrote:
> Calculate pipe watermarks during atomic calculation phase, based on the
> contents of the atomic transaction's state structure. We still program
> the watermarks at the same time we did before, but the computation now
> happens much earlier.
>
On Wed, 19 Aug 2015, David Henningsson wrote:
> This callback will be called by the i915 driver to notify the hda
> driver that its HDMI information needs to be refreshed, i e,
> that audio output is now available (or unavailable) - usually as a
> result of a monitor being plugged in (or unplugged
Hi Dave -
Some i915 fixes headed for v4.3. SKL DDI-E is a wip, but here's the
first in a series.
BR,
Jani.
The following changes since commit 3732ce72b45a2a145803558758821bf198751276:
Merge tag 'v4.2-rc8' into drm-next (2015-08-24 16:36:42 +1000)
are available in the git repository at:
From: Robert Beckett
Virtualized systems often use a virtual P2X4 south bridge.
Detect this in intel_detect_pch and make a best guess as to which PCH
we should be using.
This was seen on vmware esxi hypervisor. When passing the graphics device
through to a guest, it can not pass through the PCH.
On Thu, Aug 27, 2015 at 11:55:55PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Second posting of the HPD port A series, with some new added goodies
> at the end ;)
>
> I tried to accomodate Paulo's review comments on v1 of the series [1]
> and noticed a few other warts
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 7232
-Summary-
Platform Delta drm-intel-nightly Series Applied
ILK -1
Add --as-needed to the linker flags to reduce the number of shared
library dependencies, since not all the tests and tools use all the
libraries required by the helper library (for example, many tests do not
use cairo). This helps portability of the binaries and also makes a
very small improvement
Since BIOS RC 1.4 it would enable CDCLK PLL during BIOS S3 resume, then
driver needs to set CDCLK to avoid display corruption if DPLL0 enabled.
References: https://bugs.freedesktop.org/show_bug.cgi?id=91697
Reviewed-by: Rodrigo Vivi
Reviewed-by: Damien Lespiau
Reviewed-by: Cooper Chiou
Reviewed
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 7229
-Summary-
Platform Delta drm-intel-nightly Series Applied
ILK -1
I915 kernel driver can now work inside a virtual machine on Haswell
with Intel GVT-g. In order to do the same thing on Broadwell, there
are some extra changes needed. The two main things are to support the
more complicated PPGTT page table structure and EXECLIST contexts.
GVT-g will perform shadow
I915 Broadwell guest driver is now supported to run inside a VM with
Intel GVT-g
v2:
- Introduce HAS_VGPU macro (Zhenyu Wang)
Signed-off-by: Zhiyuan Lv
Signed-off-by: Zhi Wang
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_vgpu.c | 2 +-
drivers/gpu/drm/i915/i915_vgpu.h | 2 ++
2
This is based on Mika Kuoppala's patch below:
http://article.gmane.org/gmane.comp.freedesktop.xorg.drivers.intel/61104/match=workaround+hw+preload
The patch will preallocate the page directories for 32-bit PPGTT when
i915 runs inside a virtual machine with Intel GVT-g. With this change,
the root p
When i915 drivers run inside a VM with Intel GVT-g, some explicit
notifications are needed from guest to host device model through PV
INFO page write. The notifications include:
PPGTT create
PPGTT destroy
They are used for the shadow implementation of PPGTT. Intel GVT-g
needs to w
The full ppgtt is supported now in Intel GVT-g device model. Broadwell
is allowed to use it in virtual machines.
v2:
- Keep backward compatibility on HSW with old device model (daniel)
Signed-off-by: Zhiyuan Lv
Signed-off-by: Zhi Wang
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915
Broadwell hardware supports both ring buffer mode and execlist mode.
When i915 runs inside a VM with Intel GVT-g, we allow execlist mode
only.
The main reason of EXECLIST only is that GVT-g does not support the
dynamic mode switch between ring buffer mode and execlist mode when
running multiple vi
Some more definitions in the PV info page are added. They are mainly
for the guest notification to Intel GVT-g device model. They are used
for Broadwell enabling.
The notification of PPGTT page table creation/destroy is to notify
GVT-g device model the life cycle of guest page tables. Then device
79 matches
Mail list logo
