The function can be made static there. No functional changes.
Reviewed-by: Durgadoss R
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_display.c | 45 --
drivers/gpu/drm/i915/intel_dp.c | 61 +++-
drivers/gpu/drm/i915/intel_
v2 with missing cases handled and intel_digital_port_connected return
value changed to bool. Mostly it's just the addition of patches 2 and 3,
and rebase of the rest.
BR,
Jani.
Jani Nikula (7):
drm/i915: move ibx_digital_port_connected to intel_dp.c
drm/i915: make g4x_digital_port_connected
We should not be hitting any of the default cases in
g4x_digital_port_connected, so add MISSING_CASE annotation and return
boolean status. The current behaviour is just cargo culting from the
days of yonder when the display port support was added to i915.
Signed-off-by: Jani Nikula
---
drivers/g
With the case added for eDP on port A (always connected from this
function's point of view), we should not be hitting any of the default
cases in ibx_digital_port_connected, so add MISSING_CASE annotation.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_dp.c | 10 --
1 file cha
BXT platform uses live status bits from 0x0 register to obtain DP
status on hotplug. The existing g4x_digital_port_connected() uses a
different register and hence misses DP hotplug events on BXT
platform. This patch fixes it by using the appropriate register(0x0)
and live status bits(3:5).
Choose the right function at the intel_digital_port_connected level.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_dp.c | 70 +++--
1 file changed, 39 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i9
Choose the right function at the intel_digital_port_connected level.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_dp.c | 78 +++--
1 file changed, 43 insertions(+), 35 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i9
Add a common intel_digital_port_connected() that splits out to functions
for different platforms. No functional changes.
v2: make the function return a boolean
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_dp.c | 41 ++---
1 file changed, 22 inser
I've been experiencing system hangs with 4.2 release candidate kernels
on Asus X553MA laptop. 4.1.0 seems stable. I've set serial console
via ttyUSB0 so that I might be able to get some clue what might cause
the hangs.
With 4.2-rc7 (SHA 1b647a166f07dcf08709c8606470f4b17a4aa11d)
I got the following
The full ppgtt is supported in Intel GVT-g device model. So the
restriction can be removed.
Signed-off-by: Zhiyuan Lv
Signed-off-by: Zhi Wang
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915
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
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
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.
Signed-off-by: Zhiyuan Lv
Signed-off-by: Zhi Wang
---
drivers/gpu/drm/i915/i915_vgpu.h | 34 --
1 fi
Intel GVT-g will perform EXECLIST context shadowing and ring buffer
shadowing. The shadow copy is created when guest creates a context.
If a context changes its LRCA address, the hypervisor is hard to know
whether it is a new context or not. We always pin context objects to
global GTT to make life
I915 Broadwell guest driver is now supported to run inside a VM with
Intel GVT-g
Signed-off-by: Zhiyuan Lv
Signed-off-by: Zhi Wang
---
drivers/gpu/drm/i915/i915_vgpu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_vgpu.c b/drivers/gpu/drm/i915/i91
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 reason is that GVT-g does not support the dynamic mode
switch between ring buffer mode and execlist mode when running
multiple virtual machines. Conside
When i915 drivers run inside a VM with Intel-GVTg, some explicit
notifications are needed from guest to host device model through PV
INFO page write. The notifications include:
PPGTT create/destroy
EXECLIST create/destroy
They are used for the shadow implementation of PPGTT and EX
Hi Jani,
On Thu, Aug 20, 2015 at 09:44:08AM +0300, Jani Nikula wrote:
> On Thu, 20 Aug 2015, Zhiyuan Lv wrote:
> > 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
>-Original Message-
>From: Nikula, Jani
>Sent: Thursday, August 20, 2015 1:18 PM
>To: intel-gfx@lists.freedesktop.org
>Cc: R, Durgadoss; Ville Syrjälä; Nikula, Jani
>Subject: [PATCH v2 2/7] drm/i915: make g4x_digital_port_connected return
>boolean status
>
>We should not be hitting any o
Hi Dave, one more batch of i915 fixes for v4.2.
Revert of a VBT parsing commit that should've been queued for drm-next,
not v4.2. The revert unbreaks Braswell among other things.
Also on Braswell removal of DP HBR2/TP3 and intermediate eDP frequency
support. The code was optimistically added bas
On Thu, Aug 20, 2015 at 03:45:20PM +0800, Zhiyuan Lv wrote:
> 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 reason is that GVT-g does not support the dynamic mode
> switch between ring buffer mo
On Thu, Aug 20, 2015 at 03:45:21PM +0800, Zhiyuan Lv wrote:
> Intel GVT-g will perform EXECLIST context shadowing and ring buffer
> shadowing. The shadow copy is created when guest creates a context.
> If a context changes its LRCA address, the hypervisor is hard to know
> whether it is a new conte
Hi Chris,
On Thu, Aug 20, 2015 at 09:34:05AM +0100, Chris Wilson wrote:
> On Thu, Aug 20, 2015 at 03:45:20PM +0800, Zhiyuan Lv wrote:
> > 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 reaso
On Thu, Aug 20, 2015 at 04:55:08PM +0800, Zhiyuan Lv wrote:
> Hi Chris,
>
> On Thu, Aug 20, 2015 at 09:34:05AM +0100, Chris Wilson wrote:
> > On Thu, Aug 20, 2015 at 03:45:20PM +0800, Zhiyuan Lv wrote:
> > > Broadwell hardware supports both ring buffer mode and execlist mode.
> > > When i915 runs
Hi Chris,
On Thu, Aug 20, 2015 at 09:36:00AM +0100, Chris Wilson wrote:
> On Thu, Aug 20, 2015 at 03:45:21PM +0800, Zhiyuan Lv wrote:
> > Intel GVT-g will perform EXECLIST context shadowing and ring buffer
> > shadowing. The shadow copy is created when guest creates a context.
> > If a context cha
On Wed, 19 Aug 2015 10:48:58 +0200,
David Henningsson wrote:
>
> 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 kno
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 the codec
and recheck plug/unplug + ELD status.
This fixes the issue with lost unsol events in power save mode,
the codec and controller
This test commit YUV framebuffer in primay plane. I'm using empty FB,
because this fulfills the purpose of testing YUV.
V2: Revert chnages for MAX_PLANE count as per nabendu's comment. These
changes are already floating for review.
Signed-off-by: Kumar, Mahesh
---
lib/igt_fb.c|
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 the codec
> >> and recheck plug/unplug + ELD status.
On Thu, Aug 20, 2015 at 10:22:37AM +0100, Chris Wilson wrote:
> On Thu, Aug 20, 2015 at 04:55:08PM +0800, Zhiyuan Lv wrote:
> > Hi Chris,
> >
> > On Thu, Aug 20, 2015 at 09:34:05AM +0100, Chris Wilson wrote:
> > > On Thu, Aug 20, 2015 at 03:45:20PM +0800, Zhiyuan Lv wrote:
> > > > Broadwell hardwa
Hi,
Added Michel and Dave as CC too, to notice this, as they are specified
in the patch as CC.
On to, 2015-08-20 at 15:45 +0800, Zhiyuan Lv wrote:
> This is based on Mika Kuoppala's patch below:
> http://article.gmane.org/gmane.comp.freedesktop.xorg.drivers.intel/61
> 104/match=workaround+hw+prel
On to, 2015-08-20 at 15:45 +0800, Zhiyuan Lv wrote:
> The full ppgtt is supported in Intel GVT-g device model. So the
> restriction can be removed.
>
> Signed-off-by: Zhiyuan Lv
> Signed-off-by: Zhi Wang
Reviewed-by: Joonas Lahtinen
> ---
> drivers/gpu/drm/i915/i915_gem_gtt.c | 3 ---
> 1 fi
Hi,
On to, 2015-08-20 at 17:40 +0800, Zhiyuan Lv wrote:
> On Thu, Aug 20, 2015 at 10:22:37AM +0100, Chris Wilson wrote:
> > On Thu, Aug 20, 2015 at 04:55:08PM +0800, Zhiyuan Lv wrote:
> > > Hi Chris,
> > >
> > > On Thu, Aug 20, 2015 at 09:34:05AM +0100, Chris Wilson wrote:
> > > > On Thu, Aug 20,
On to, 2015-08-20 at 15:45 +0800, Zhiyuan Lv wrote:
> 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.
>
> Signed-off-by: Zhiyuan Lv
> Signed-off-by: Zhi Wang
>
Reviewed-by: Jo
Hi,
Notes below.
On to, 2015-08-20 at 15:45 +0800, Zhiyuan Lv wrote:
> When i915 drivers run inside a VM with Intel-GVTg, some explicit
> notifications are needed from guest to host device model through PV
> INFO page write. The notifications include:
>
> PPGTT create/destroy
> EXECL
On to, 2015-08-20 at 15:45 +0800, Zhiyuan Lv wrote:
> I915 Broadwell guest driver is now supported to run inside a VM with
> Intel GVT-g
>
> Signed-off-by: Zhiyuan Lv
> Signed-off-by: Zhi Wang
After the other relevant patches are settled;
Reviewed-by: Joonas Lahtinen
> ---
> drivers/gpu/drm
2015-08-19 9:06 GMT-03:00 Ville Syrjälä :
> On Fri, Aug 14, 2015 at 06:34:12PM -0300, Paulo Zanoni wrote:
>> If we want to try to enable FBC by default on any platform we need to
>> be on the safe side and disable it in case we get an underrun while
>> FBC is enabled on the corresponding pipe. We c
On Thu, Aug 20, 2015 at 10:30:17AM -0300, Paulo Zanoni wrote:
> 2015-08-19 9:06 GMT-03:00 Ville Syrjälä :
> > On Fri, Aug 14, 2015 at 06:34:12PM -0300, Paulo Zanoni wrote:
> >> If we want to try to enable FBC by default on any platform we need to
> >> be on the safe side and disable it in case we g
>-Original Message-
>From: Nikula, Jani
>Sent: Thursday, August 20, 2015 1:18 PM
>To: intel-gfx@lists.freedesktop.org
>Cc: R, Durgadoss; Ville Syrjälä; Nikula, Jani
>Subject: [PATCH v2 3/7] drm/i915: add MISSING_CASE annotation to
>ibx_digital_port_connected
>
>With the case added for eDP
2015-08-20 10:58 GMT-03:00 Ville Syrjälä :
> On Thu, Aug 20, 2015 at 10:30:17AM -0300, Paulo Zanoni wrote:
>> 2015-08-19 9:06 GMT-03:00 Ville Syrjälä :
>> > On Fri, Aug 14, 2015 at 06:34:12PM -0300, Paulo Zanoni wrote:
>> >> If we want to try to enable FBC by default on any platform we need to
>> >
If we leave the last_retired_head to pre-reset value, we might
end up in a situation where intel_ring_space() returns wrong
value on next hardware init.
The recent GuC changes made ringbuffer size much smaller. Thus
the odds grew that we got pre-reset last_retired_head in
a value so that intel_rin
The drm core doesn't check unused fields of ADDFB2 for pre-FB_MODIFIERS
userspace, so require that and use the local version of the defines.
Signed-off-by: Ander Conselvan de Oliveira
---
tests/kms_addfb_basic.c | 19 ++-
1 file changed, 14 insertions(+), 5 deletions(-)
diff --
On Thu, Aug 20, 2015 at 11:29:29AM -0300, Paulo Zanoni wrote:
> 2015-08-20 10:58 GMT-03:00 Ville Syrjälä :
> > On Thu, Aug 20, 2015 at 10:30:17AM -0300, Paulo Zanoni wrote:
> >> 2015-08-19 9:06 GMT-03:00 Ville Syrjälä :
> >> > On Fri, Aug 14, 2015 at 06:34:12PM -0300, Paulo Zanoni wrote:
> >> >> If
On Thu, Aug 20, 2015 at 05:34:59PM +0300, Mika Kuoppala wrote:
> If we leave the last_retired_head to pre-reset value, we might
> end up in a situation where intel_ring_space() returns wrong
> value on next hardware init.
http://patchwork.freedesktop.org/patch/46612/
and earlier
-Chris
--
Chris
Hi,
Please consider pulling i915 updates to linux-firmware.git.
The following changes since commit
38358cfcf50436bf4462b3e45f5b30ab66bb63a6:
firmware: tegra: Update XHCI firmware to v50.10 for T210 (2015-08-12
14:39:31 -0400)
are available in the git repository at:
git://people.freedesktop
From: Ville Syrjälä
We are no longer checkling the DP link status on long hpd. We used to do
that from the .hot_plug() handler, but it was removed when MST got
introduced.
If there's no userspace we now fail to retrain the link if the sink
power is toggled (or cable yanked and replugged), meanin
From: Rodrigo Vivi
Let's use a native read with retry as suggested per spec to
fix Sink CRC on SKL when PSR is enabled.
With PSR enabled panel is probably taking more time to wake
and dpcd read is faling.
Cc: Sonika Jindal
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/intel_dp.c | 15
Let's use a native read with retry as suggested per spec to
fix Sink CRC on SKL when PSR is enabled.
With PSR enabled panel is probably taking more time to wake
and dpcd read is faling.
v2: Fix my email domain on commit message. Thanks Rafael.
Cc: Rafael Antognolli
Cc: Sonika Jindal
Signed-off
Many reasons here:
- Hardware tracking also has hidden corner cases
- Frontbuffer tracking is mature and reliable now
- Our sw exit by unseting bit 31 is really fast and reliable.
Also frontbuffer tracking flush means invalidate and flush.
So, let's rely more and do the proper meaning of flush f
According to spec the disable sequence is:
Driver will do the following on PSR Disable.
1. Disable PSR in PSR control register, SRD_CTL[bit 31].
2. Poll on PSR idle
3. Wait for VBlank
4. Disable VSC DIP.
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/intel_psr.c | 10 ++
1 file cha
This affects PSR on VLV, CHV, HSW and BDW.
When debuging the frozen screen caused by HW tracking with low
power state I noticed that if we keep moving the mouse non stop
you will miss the screen updates for a while. At least
until we stop moving the mouse for a small time and move again.
The actu
With commit 30886c5a ("drm/i915: VLV/CHV PSR: Increase wait delay
time before active PSR.") we fixed a blank screen when first
activation was happening immediatelly after PSR being enabled.
There we gave more time for idleness by increasing the delay
between re-activating sequences.
However, commi
This is wrong since my commit (89251b17). The intention of that
commit was to remove this one here that is also wrong anyway,
but it was forgotten.
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/intel_psr.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ps
At the beginning it was masked to allow PSR at all.
Than it got removed later by my
commit 09108b90f040 ("drm/i915: PSR: Remove Low Power HW tracking mask.")
in order to trying fixing one case reported at intel-gfx mailing list
where we were missing screen updates when runtime_pm was enabled.
Howe
commit 97173eaf5f3 ("drm/i915: PSR: Increase idle_frames")
incresed the number of idle frames making PSR entry more
reliable on many panels. Also commit
"drm/i915: Delay first PSR activation." move add the
delay workaround to the right place since all errors that
made us to introduce this delay her
This patch series brings stability to PSR on VLV, CHV, HSW and BDW.
It fixes issues Matthew Garrett without causing the blank and frozen
screens Ivan Mitev was facing.
It also move the VLV/CHV workaround of that big delay from re-enable
to the first enable after modeset that was the real issue.
W
Just pull the info out of the plane state structure rather than staging
it in an additional structure.
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/intel_pm.c | 133 +---
1 file changed, 70 insertions(+), 63 deletions(-)
diff --git a/drivers/gpu/drm/i91
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 | 66 +++-
4 files changed, 71
Although we calculate watermark values in the atomic state, we still
have both 'pending' and 'hardware' values that ultimately wind up in
dev_priv due to the somewhat complicated watermark flushing process.
Re-arranging how these are stored/named in the dev_priv substructure may
add a little bit of
In addition to calculating final watermarks, let's also pre-calculate a
set of intermediate watermark values at atomic check time. These
intermediate watermarks are a combination of the watermarks for the old
state and the new state; they should satisfy the requirements of both
states which means
Atomic watermark programming involves pre-computing the watermark
results during the 'check' phase of an atomic transaction. Although
watermark updates are triggered by the change to a specific CRTC, the
results themselves are global, so they're stored in the
intel_atomic_state. If/when the state
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.
While this patch isn't too exciting by itself, it paves the w
From: Ville Syrjälä
Split ilk_update_wm() into two parts; one doing the programming
and the other the calculations.
v2: Fix typo in commit message
v3 (by Matt): Heavily rebased for current codebase.
Reviewed-by(v2): Paulo Zanoni
Signed-off-by: Ville Syrjälä
Signed-off-by: Matt Roper
---
dr
Just pull the info out of the CRTC state structure rather than staging
it in an additional structure.
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/intel_pm.c | 84 ++---
1 file changed, 28 insertions(+), 56 deletions(-)
diff --git a/drivers/gpu/drm/i915
Just pull the info out of the state structures rather than staging
it in an additional set of structures.
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/intel_pm.c | 304 ++--
1 file changed, 135 insertions(+), 169 deletions(-)
diff --git a/drivers/gpu/dr
The only platform that still has an update_sprite_wm entrypoint is SKL;
on SKL, intel_update_sprite_watermarks just updates intel_plane->wm and
then performs a regular watermark update. However intel_plane->wm is
only used to update a couple fields in intel_wm_config, and those fields
are never us
Since we allocate a few CRTC states on the stack, also switch the 'wm'
struct here to be a union so that we're not wasting stack space with
other platforms' watermark values.
v2: Don't move cxsr_allowed to state (Maarten)
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/intel_drv.h | 45 +
Determine whether we need to apply this workaround at atomic check time
and just set a flag that will be used by the main watermark update
routine.
Moving this workaround into the atomic framework reduces
ilk_update_sprite_wm() to just a standard watermark update, so drop it
completely and just en
A bunch of SKL watermark-related structures have the cursor plane as a
separate entry from the rest of the planes. If we just extend the
relevant plane arrays by one entry and use the top-most array element as
the cursor, it will simplify future patches.
There shouldn't be any functional change h
Previous atomic watermark patches were posted here:
http://lists.freedesktop.org/archives/intel-gfx/2015-July/070465.html
Key changes since the last series:
* Quite a bit of rebasing; I got pulled away from working on this for a while,
so parts of the upstream code evolved a bit before I was
Hi Joonas,
Thanks for the review! And my reply inline.
Regards,
-Zhiyuan
On Thu, Aug 20, 2015 at 02:23:11PM +0300, Joonas Lahtinen wrote:
> Hi,
>
> On to, 2015-08-20 at 17:40 +0800, Zhiyuan Lv wrote:
> > On Thu, Aug 20, 2015 at 10:22:37AM +0100, Chris Wilson wrote:
> > > On Thu, Aug 20, 2015 at
On Thu, Aug 20, 2015 at 03:58:43PM +0300, Joonas Lahtinen wrote:
> On to, 2015-08-20 at 15:45 +0800, Zhiyuan Lv wrote:
> > 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.
> >
On Thu, Aug 20, 2015 at 04:11:57PM +0300, Joonas Lahtinen wrote:
> Hi,
>
> Notes below.
>
> On to, 2015-08-20 at 15:45 +0800, Zhiyuan Lv wrote:
> > When i915 drivers run inside a VM with Intel-GVTg, some explicit
> > notifications are needed from guest to host device model through PV
> > INFO pag
> From: iGVT-g [mailto:igvt-g-boun...@lists.01.org] On Behalf Of Zhiyuan Lv
> Sent: Thursday, August 20, 2015 5:40 PM
>
> On Thu, Aug 20, 2015 at 10:22:37AM +0100, Chris Wilson wrote:
> > On Thu, Aug 20, 2015 at 04:55:08PM +0800, Zhiyuan Lv wrote:
> > > Hi Chris,
> > >
> > > On Thu, Aug 20, 2015 a
Hi Chris,
If we cannot always pin lr context into GGTT, the LRCA cannot be used
as a context identifier for us. Then we have to consider a proper
interface for i915 in VM to notify GVT-g device model.
The context creation might be OK. We can pin context first, then
notify the context creation, af
On Thu, 20 Aug 2015, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> We are no longer checkling the DP link status on long hpd. We used to do
> that from the .hot_plug() handler, but it was removed when MST got
> introduced.
>
> If there's no userspace we now fail to retrain the lin
76 matches
Mail list logo