On 17/07/2019 22:25, Summers, Stuart wrote:
On Wed, 2019-07-17 at 19:06 +0100, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Not opposed to this exactly, but do we really need this patch if we're
just getting rid of this routine later in the series?
It just happens this fix alone is enough
== Series Details ==
Series: drm/i915/vbt: Fix VBT parsing for the PSR section (rev3)
URL : https://patchwork.freedesktop.org/series/63774/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6502_full -> Patchwork_13678_full
On 2019-07-12 at 18:09:39 -0700, Lucas De Marchi wrote:
> From: José Roberto de Souza
>
> Tiger Lask has a new register offset for DC5 and DC6 residency counters.
>
> Signed-off-by: José Roberto de Souza
> Signed-off-by: Lucas De Marchi
> ---
> drivers/gpu/drm/i915/i915_debugfs.c | 21
== Series Details ==
Series: series starting with [v10,1/2] drm/i915: Introduce async plane update
to i915
URL : https://patchwork.freedesktop.org/series/63835/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_6502_full -> Patchwork_13677_full
On 2019-07-17 at 19:50:18 +0530, Anshuman Gupta wrote:
> To identify the HDCP capability of the display connected to CI
> systems, we need to add the hdcp capability probing in i915_display_info.
>
> This will also help to populate the HDCP capability of the CI systems
> to CI H/W logs maintained
== Series Details ==
Series: MCR fixes and more
URL : https://patchwork.freedesktop.org/series/63831/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6502_full -> Patchwork_13676_full
Summary
---
**SUCCESS**
No
Finally! For a very long time, our MST helpers have had one very
annoying issue: They don't know how to reprobe the topology state when
coming out of suspend. This means that if a user has a machine connected
to an MST topology and decides to suspend their machine, we lose all
topology changes
This is the large series for adding MST suspend/resume reprobing that
I've been working on for quite a while now. In addition, I:
- Refactored and cleaned up any code I ended up digging through in the
process of understanding how some parts of these helpers worked.
- Added some debugging tools
On Wed, 2019-07-17 at 14:35 +0300, Ville Syrjälä wrote:
> On Tue, Jul 16, 2019 at 03:03:21PM -0700, Dhinakaran Pandiyan wrote:
> > A single 32-bit PSR2 training pattern field follows the sixteen element
> > array of PSR table entries in the VBT spec. But, we incorrectly define
> > this PSR2 field
== Series Details ==
Series: drm/i915/vbt: Fix VBT parsing for the PSR section (rev3)
URL : https://patchwork.freedesktop.org/series/63774/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6502 -> Patchwork_13678
Summary
A single 32-bit PSR2 training pattern field follows the sixteen element
array of PSR table entries in the VBT spec. But, we incorrectly define
this PSR2 field for each of the PSR table entries. As a result, the PSR1
training pattern duration for any panel_type != 0 will be parsed
incorrectly.
On Wed, 2019-07-17 at 23:27 +0200, Paul Bolle wrote:
> Hi Jose,
>
> Souza, Jose schreef op di 16-07-2019 om 16:32 [+]:
> > Paul and James could you test this final solution(at least for
> > 5.2)? Please revert the hack patch and apply this one.
>
> I've just reached a day of uptime with your
Hi Jose,
Souza, Jose schreef op di 16-07-2019 om 16:32 [+]:
> Paul and James could you test this final solution(at least for 5.2)?
> Please revert the hack patch and apply this one.
I've just reached a day of uptime with your revert. (The proper uptime is just
a fraction of a day, this being
On Wed, 2019-07-17 at 19:06 +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
Not opposed to this exactly, but do we really need this patch if we're
just getting rid of this routine later in the series?
Thanks,
Stuart
>
> fls returns bit positions starting from one for the lsb and the MCR
>
On Wed, 2019-07-17 at 19:06 +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> A couple issues were present in this code:
>
> 1.
> fls() usage was incorrect causing off by one in subslice mask lookup,
> which in other words means subslice mask of all zeroes is always used
> (subslice mask
On Wed, 2019-07-17 at 20:47 +, Summers, Stuart wrote:
> On Wed, 2019-07-17 at 19:06 +0100, Tvrtko Ursulin wrote:
> > From: Tvrtko Ursulin
> >
> > Instead of re-calculating the MCR selector in read_subslice_reg do
> > the
> > rwm on its existing value and restore it when done.
> >
> > This
On Wed, 2019-07-17 at 19:06 +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Instead of re-calculating the MCR selector in read_subslice_reg do
> the
> rwm on its existing value and restore it when done.
>
> This consolidates MCR programming to one place for cnl+, and avoids
>
== Series Details ==
Series: drm/i915: Add HDCP capability info to i915_display_info.
URL : https://patchwork.freedesktop.org/series/63819/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6498_full -> Patchwork_13675_full
== Series Details ==
Series: series starting with [v10,1/2] drm/i915: Introduce async plane update
to i915
URL : https://patchwork.freedesktop.org/series/63835/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6502 -> Patchwork_13677
Tested-by: François Guerraz
On Dell XPS 9350
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Quoting Tvrtko Ursulin (2019-07-17 19:06:24)
> From: Tvrtko Ursulin
>
> We were missing this workaround which can cause hangs if fine grained
> coherency was used.
>
> Signed-off-by: Tvrtko Ursulin
> ---
> drivers/gpu/drm/i915/gt/intel_workarounds.c | 6 ++
>
Quoting Tvrtko Ursulin (2019-07-17 19:06:22)
> From: Tvrtko Ursulin
>
> Access to 0xb100 - 0xb3ff mmio range is controlled by the MCR selector
> which only affects CPU MMIO. Therefore these registers cannot be realiably
> read with MI_SRM from the command streamer so skip their verification.
>
Quoting Tvrtko Ursulin (2019-07-17 19:06:21)
> From: Tvrtko Ursulin
>
> A couple issues were present in this code:
>
> 1.
> fls() usage was incorrect causing off by one in subslice mask lookup,
> which in other words means subslice mask of all zeroes is always used
> (subslice mask of a slice
Quoting Tvrtko Ursulin (2019-07-17 19:06:20)
> From: Tvrtko Ursulin
>
> Instead of re-calculating the MCR selector in read_subslice_reg do the
> rwm on its existing value and restore it when done.
I successfully worked back from implementation to changelog.
>
> This consolidates MCR
From: Gustavo Padovan
Replace the legacy cursor implementation by the async callbacks
Signed-off-by: Gustavo Padovan
Signed-off-by: Enric Balletbo i Serra
Signed-off-by: Helen Koike
---
Changes in v10: None
Changes in v9:
- v8: https://patchwork.kernel.org/patch/10843397/
- rebased and
From: Gustavo Padovan
Add implementation for async plane update callbacks
Signed-off-by: Gustavo Padovan
Signed-off-by: Enric Balletbo i Serra
Signed-off-by: Tina Zhang
Signed-off-by: Helen Koike
Tested-by: Tina Zhang
---
Hi,
This is v10, I just fixed the order in how the commit_ready
== Series Details ==
Series: MCR fixes and more
URL : https://patchwork.freedesktop.org/series/63831/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6502 -> Patchwork_13676
Summary
---
**SUCCESS**
No regressions
== Series Details ==
Series: MCR fixes and more
URL : https://patchwork.freedesktop.org/series/63831/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
53048f39ddd0 drm/i915: Fix GEN8_MCR_SELECTOR programming
9874e34931ae drm/i915: Trust programmed MCR in read_subslice_reg
-:59:
== Series Details ==
Series: drm/i915: Remove obsolete engine clenaup (rev2)
URL : https://patchwork.freedesktop.org/series/63791/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6498_full -> Patchwork_13673_full
Summary
On 17/07/2019 15:06, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-07-17 14:46:15)
On 17/07/2019 14:35, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-07-17 14:23:55)
On 17/07/2019 14:17, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-07-17 14:09:00)
On 16/07/2019 16:37, Chris
From: Tvrtko Ursulin
We were missing this workaround which can cause hangs if fine grained
coherency was used.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_workarounds.c | 6 ++
drivers/gpu/drm/i915/i915_reg.h | 3 +++
2 files changed, 9 insertions(+)
diff
From: Tvrtko Ursulin
Access to 0xb100 - 0xb3ff mmio range is controlled by the MCR selector
which only affects CPU MMIO. Therefore these registers cannot be realiably
read with MI_SRM from the command streamer so skip their verification.
Signed-off-by: Tvrtko Ursulin
---
From: Tvrtko Ursulin
Having fixed the incorect MCR programming in an earlier patch, we can now
stop ignoring read back of GEN8_L3SQCREG4 during engine workaround
verification.
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_workarounds.c | 27
From: Tvrtko Ursulin
A couple issues were present in this code:
1.
fls() usage was incorrect causing off by one in subslice mask lookup,
which in other words means subslice mask of all zeroes is always used
(subslice mask of a slice which is not present, or even out of bounds
array access),
From: Tvrtko Ursulin
Instead of re-calculating the MCR selector in read_subslice_reg do the
rwm on its existing value and restore it when done.
This consolidates MCR programming to one place for cnl+, and avoids
re-calculating its default value on older platforms during hangcheck.
From: Tvrtko Ursulin
A few bugs in programming the MCR register sneaked in past code review.
First of all fls() usage is wrong and suffers from off-by-one problem.
Secondly the assert in WaProgramMgsrForL3BankSpecificMmioReads is also wrong
due inverted logic.
With MCR programming fixed we
From: Tvrtko Ursulin
fls returns bit positions starting from one for the lsb and the MCR
register expects zero based (sub)slice addressing.
Incorrent MCR programming can have the effect of directing MMIO reads of
registers in the 0xb100-0xb3ff range to invalid subslice returning zeroes
instead
On 17/07/2019 14:56, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-07-17 14:42:15)
On 17/07/2019 14:30, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-07-17 14:21:50)
On 17/07/2019 14:08, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-07-17 14:04:34)
On 16/07/2019 13:49, Chris
On Wed, Jul 17, 2019 at 09:41:13AM -0700, Souza, Jose wrote:
> On Tue, 2019-07-16 at 15:10 -0700, Pandiyan, Dhinakaran wrote:
> > On Tue, 2019-07-16 at 15:03 -0700, Dhinakaran Pandiyan wrote:
> > > A single 32-bit PSR2 training pattern field follows the sixteen
> > > element
> > > array of PSR
== Series Details ==
Series: series starting with [1/3] drm/i915: Move aliasing_ppgtt underneath its
i915_ggtt (rev2)
URL : https://patchwork.freedesktop.org/series/63809/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6498_full -> Patchwork_13672_full
On Tue, 2019-07-16 at 15:10 -0700, Pandiyan, Dhinakaran wrote:
> On Tue, 2019-07-16 at 15:03 -0700, Dhinakaran Pandiyan wrote:
> > A single 32-bit PSR2 training pattern field follows the sixteen
> > element
> > array of PSR table entries in the VBT spec. But, we incorrectly
> > define
> > this
== Series Details ==
Series: drm/i915: Make sure cdclk is high enough for DP audio on VLV/CHV
URL : https://patchwork.freedesktop.org/series/63808/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6498_full -> Patchwork_13671_full
Hi,
[This is an automated email]
This commit has been processed because it contains a -stable tag.
The stable tag indicates that it's relevant for the following trees: all
The bot has tested the following trees: v5.2.1, v5.1.18, v4.19.59, v4.14.133,
v4.9.185, v4.4.185.
v5.2.1: Failed to
== Series Details ==
Series: drm/i915: Move aliasing_ppgtt underneath its i915_ggtt
URL : https://patchwork.freedesktop.org/series/63806/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6498_full -> Patchwork_13670_full
== Series Details ==
Series: drm/i915: Add HDCP capability info to i915_display_info.
URL : https://patchwork.freedesktop.org/series/63819/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6498 -> Patchwork_13675
Summary
== Series Details ==
Series: drm/i915: Add HDCP capability info to i915_display_info.
URL : https://patchwork.freedesktop.org/series/63819/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
84154a9a0135 drm/i915: Add HDCP capability info to i915_display_info.
-:35:
== Series Details ==
Series: DC3CO Support for TGL.
URL : https://patchwork.freedesktop.org/series/63817/
State : failure
== Summary ==
Applying: drm/i915/tgl:Added DC3CO required register and bits.
Applying: i915:Added DC3CO mask to allowed_dc_mask and gen9_dc_mask.
Applying: i915:Added
To identify the HDCP capability of the display connected to CI
systems, we need to add the hdcp capability probing in i915_display_info.
This will also help to populate the HDCP capability of the CI systems
to CI H/W logs maintained at https://intel-gfx-ci.01.org/hardware/.
It will facilitate to
TGL onwards we have new DC5 and DC6 counter
DMC_DEBUG1 and DMC_DEBUG2, these counter will retain
there values upon DMC reset.
Cc: jani.nik...@intel.com
Cc: imre.d...@intel.com
Cc: animesh.ma...@intel.com
Signed-off-by: Anshuman Gupta
---
drivers/gpu/drm/i915/i915_debugfs.c | 8 +---
This patch adds dc3co helper function to enable/disable
psr2 deep sleep.
This patch make sure DC3CO disallowed before PSR2 exit,
it does that essentially by putting a reference to
POWER_DOMAIN_VIDEO before PSR2 exit.
Cc: jani.nik...@intel.com
Cc: imre.d...@intel.com
Cc: jose.so...@intel.com
Cc:
This patch exposes DC3CO counter in i915_dmc_info debugfs.
Which will be useful for DC3CO validation.
DMC firmware is using DMC_DEBUG3 register as DC3CO counter
register on TGL, but as per B.Specs DMC_DEBUG3 is general
purpose register.
Cc: jani.nik...@intel.com
Cc: imre.d...@intel.com
Cc:
DC5 and DC6 not allowed when DC3CO feature is enabled.
DC5 and DC6 saves more power, but cannot be entered during video
playback because there are not enough idle frames in a row to meet.
Most PSR2 panel deep sleep entry requirements typically 4 frames.
This patch switch to DC3CO when there is
Added POWER_DOMAIN_VIDEO power domain and added its helper stuff.
POWER_DOMAIN_VIDEO is a hook to "DC5 Off" power well.
which can disallow DC5/6 in order to allow dc3co.
Cc: jani.nik...@intel.com
Cc: imre.d...@intel.com
Cc: animesh.ma...@intel.com
Signed-off-by: Anshuman Gupta
---
This patch check if it is only edp display connected and
crtc has psr2 capability, then it sets the prefer_dc3co flag to
true. It also enable DC3CO PSR2 transcoder early exitline event
in haswell_crtc_enable() function.
TODO: B. Specs says dc3co should be allow only in video playback
case,
As per B.Spces DC5 and DC6 not allowed when DC3CO is enabled.
and DC3CO should be enabled only during VIDEO playback.
Which essentially means both can DC5 and DC3CO can not be
enabled at same time.
This patch makes DC3CO and DC5 mutual exclusive.
Cc: jani.nik...@intel.com
Cc: imre.d...@intel.com
Resending this series as earlier submission has missed last patch of
series, my sincere apology for spamming.
This update is a rebased and has addressed few review comment provided by
Imre on IRC.
DMC f/w DC3CO entry/exit sequence can be found at DC3CO HAS.
I am able to validate that DC3CO
This patch adds following definition to i915_reg.h
1. DC_STATE_EN register DC3CO bit fields and masks.
2. Transcoder EXITLINE register and its bit fields and mask.
v2: Commit log typo fixing.
Cc: jani.nik...@intel.com
Cc: imre.d...@intel.com
Cc: animesh.ma...@intel.com
Signed-off-by: Anshuman
This patch enables dc3co state in enable_dc module param
and adds dc3co enable mask to allowed_dc_mask and gen9_dc_mask.
Cc: jani.nik...@intel.com
Cc: imre.d...@intel.com
Cc: animesh.ma...@intel.com
Signed-off-by: Anshuman Gupta
---
drivers/gpu/drm/i915/display/intel_display_power.c | 13
This patch adds a new "DC3CO Off" power well and adds
its power domain which are inherits from "DC Off" power well.
These power domains will disallow DC3CO when any external
display are connected and at time of modeset and aux
programming.
This patch also changes "DC Off" power well to "DC5 Off"
Quoting Tvrtko Ursulin (2019-07-17 14:46:15)
>
> On 17/07/2019 14:35, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2019-07-17 14:23:55)
> >>
> >> On 17/07/2019 14:17, Chris Wilson wrote:
> >>> Quoting Tvrtko Ursulin (2019-07-17 14:09:00)
>
> On 16/07/2019 16:37, Chris Wilson wrote:
>
== Series Details ==
Series: drm/i915: Remove obsolete engine clenaup (rev2)
URL : https://patchwork.freedesktop.org/series/63791/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6498 -> Patchwork_13673
Summary
---
Quoting Tvrtko Ursulin (2019-07-17 14:42:15)
>
> On 17/07/2019 14:30, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2019-07-17 14:21:50)
> >>
> >> On 17/07/2019 14:08, Chris Wilson wrote:
> >>> Quoting Tvrtko Ursulin (2019-07-17 14:04:34)
>
> On 16/07/2019 13:49, Chris Wilson wrote:
>
On 17/07/2019 14:35, Chris Wilson wrote:
> Quoting Tvrtko Ursulin (2019-07-17 14:23:55)
>>
>> On 17/07/2019 14:17, Chris Wilson wrote:
>>> Quoting Tvrtko Ursulin (2019-07-17 14:09:00)
On 16/07/2019 16:37, Chris Wilson wrote:
> Quoting Tvrtko Ursulin (2019-07-16 16:25:22)
>>
Quoting Chris Wilson (2019-07-17 14:40:26)
> Quoting Tvrtko Ursulin (2019-07-17 14:31:00)
> >
> > On 16/07/2019 13:49, Chris Wilson wrote:
> > > By stopping the rings, we may trigger an arbitration point resulting in
> > > a premature context-switch (i.e. a completion event before the request
> >
On 17/07/2019 14:30, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-07-17 14:21:50)
On 17/07/2019 14:08, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-07-17 14:04:34)
On 16/07/2019 13:49, Chris Wilson wrote:
Push the engine stop into the back reset_prepare (where it already was!)
On 16/07/2019 13:49, Chris Wilson wrote:
As we unwind the requests for a preemption event, we return a virtual
request back to its original virtual engine (so that it is available for
execution on any of its siblings). In the process, this means that its
breadcrumb should no longer be
Quoting Tvrtko Ursulin (2019-07-17 14:31:00)
>
> On 16/07/2019 13:49, Chris Wilson wrote:
> > By stopping the rings, we may trigger an arbitration point resulting in
> > a premature context-switch (i.e. a completion event before the request
> > is actually complete). This clears the active
Quoting Tvrtko Ursulin (2019-07-17 14:23:55)
>
> On 17/07/2019 14:17, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2019-07-17 14:09:00)
> >>
> >> On 16/07/2019 16:37, Chris Wilson wrote:
> >>> Quoting Tvrtko Ursulin (2019-07-16 16:25:22)
>
> On 16/07/2019 13:49, Chris Wilson wrote:
>
On 16/07/2019 13:49, Chris Wilson wrote:
By stopping the rings, we may trigger an arbitration point resulting in
a premature context-switch (i.e. a completion event before the request
is actually complete). This clears the active context before the reset,
but we must remember to rewind the
Quoting Tvrtko Ursulin (2019-07-17 14:21:50)
>
> On 17/07/2019 14:08, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2019-07-17 14:04:34)
> >>
> >> On 16/07/2019 13:49, Chris Wilson wrote:
> >>> Push the engine stop into the back reset_prepare (where it already was!)
> >>> This allows us to
On 17/07/2019 14:24, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-07-17 14:18:56)
On 17/07/2019 08:46, Chris Wilson wrote:
Remove the outer layer cleanup of engine stubs; it no longer tries to
Who is "it"?
i915_drv.c
preallocate and so is not responsible for either the allocation
Remove the outer layer cleanup of engine stubs; as i915_drv itself no
longer tries to preallocate and so is not responsible for either the
allocation or free. By the time we call the cleanup function, we already
have cleaned up the engines.
v2: Lack of symmetry between mmio_probe and mmio_release
Quoting Tvrtko Ursulin (2019-07-17 14:18:56)
>
> On 17/07/2019 08:46, Chris Wilson wrote:
> > Remove the outer layer cleanup of engine stubs; it no longer tries to
>
> Who is "it"?
i915_drv.c
> > preallocate and so is not responsible for either the allocation or free.
> > By the time we call
On 17/07/2019 14:17, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-07-17 14:09:00)
On 16/07/2019 16:37, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-07-16 16:25:22)
On 16/07/2019 13:49, Chris Wilson wrote:
Following a try_to_unmap() we may want to remove the userptr and so call
On 17/07/2019 14:08, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-07-17 14:04:34)
On 16/07/2019 13:49, Chris Wilson wrote:
Push the engine stop into the back reset_prepare (where it already was!)
This allows us to avoid dangerously setting the RING registers to 0 for
logical contexts. If
On 17/07/2019 08:46, Chris Wilson wrote:
> Remove the outer layer cleanup of engine stubs; it no longer tries to
Who is "it"?
> preallocate and so is not responsible for either the allocation or free.
> By the time we call the cleanup function, we already have cleaned up the
> engines.
I see:
Quoting Tvrtko Ursulin (2019-07-17 14:09:00)
>
> On 16/07/2019 16:37, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2019-07-16 16:25:22)
> >>
> >> On 16/07/2019 13:49, Chris Wilson wrote:
> >>> Following a try_to_unmap() we may want to remove the userptr and so call
> >>> put_pages(). However,
== Series Details ==
Series: series starting with [1/3] drm/i915: Move aliasing_ppgtt underneath its
i915_ggtt (rev2)
URL : https://patchwork.freedesktop.org/series/63809/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6498 -> Patchwork_13672
On Tue, 2019-07-16 at 22:47 -0300, Rodrigo Siqueira wrote:
> On 07/12, Ser, Simon wrote:
> > So, to test these last two patches we'd need specific hardware right?
> > Because VKMS doesn't support cloning yet (does it?).
>
> hmmm... actually, VKMS successfully pass in this test. However, if you
>
On 16/07/2019 16:37, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-07-16 16:25:22)
On 16/07/2019 13:49, Chris Wilson wrote:
Following a try_to_unmap() we may want to remove the userptr and so call
put_pages(). However, try_to_unmap() acquires the page lock and so we
must avoid recursively
Quoting Tvrtko Ursulin (2019-07-17 14:04:34)
>
> On 16/07/2019 13:49, Chris Wilson wrote:
> > Push the engine stop into the back reset_prepare (where it already was!)
> > This allows us to avoid dangerously setting the RING registers to 0 for
> > logical contexts. If we clear the register on a
On Mon, Jul 8, 2019 at 5:53 PM Srivatsa, Anusha
wrote:
>
> Hi,
>
> Can these i915 changes be merged to the linux-firmware.git?
>
> The following changes since commit 70e43940b05e8d6e0c5f15b5e2d67760f1581ece:
>
> linux-firmware: rsi: add firmware image for redpine 9116 chipset
> (2019-06-28
On 16/07/2019 13:49, Chris Wilson wrote:
Push the engine stop into the back reset_prepare (where it already was!)
This allows us to avoid dangerously setting the RING registers to 0 for
logical contexts. If we clear the register on a live context, those
invalid register values are recorded in
On Tue, 2019-07-16 at 22:21 -0300, Rodrigo Siqueira wrote:
> On 07/12, Ser, Simon wrote:
> > On Thu, 2019-07-11 at 23:44 -0300, Rodrigo Siqueira wrote:
> > > On 07/10, Ser, Simon wrote:
> > > > Hi,
> > > >
> > > > Thanks for the patch! Here are a few comments.
> > > >
> > > > For bonus points,
== Series Details ==
Series: drm/i915: Make sure cdclk is high enough for DP audio on VLV/CHV
URL : https://patchwork.freedesktop.org/series/63808/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6498 -> Patchwork_13671
== Series Details ==
Series: drm/i915: Update description of i915.enable_guc modparam
URL : https://patchwork.freedesktop.org/series/63804/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6496_full -> Patchwork_13669_full
== Series Details ==
Series: drm/i915: Make sure cdclk is high enough for DP audio on VLV/CHV
URL : https://patchwork.freedesktop.org/series/63808/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915: Make sure cdclk is high enough for DP audio on
== Series Details ==
Series: drm/i915: Move aliasing_ppgtt underneath its i915_ggtt
URL : https://patchwork.freedesktop.org/series/63806/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6498 -> Patchwork_13670
Summary
Quoting Chris Wilson (2019-07-15 13:02:14)
> As we unwind the requests for a preemption event, we return a virtual
> request back to its original virtual engine (so that it is available for
> execution on any of its siblings). In the process, this means that its
> breadcrumb should no longer be
Track the currently bound address space used by the HW context. Minor
conversions to use the local intel_context.vm are made, leaving behind
some more surgery required to make intel_context the primary through the
selftests.
Signed-off-by: Chris Wilson
---
Track the currently bound address space used by the HW context. Minor
conversions to use the local intel_context.vm are made, leaving behind
some more surgery required to make intel_context the primary through the
selftests.
Signed-off-by: Chris Wilson
---
The aliasing_ppgtt provides a PIN_USER alias for the global gtt, so move
it under the i915_ggtt to simplify later transformations to enable
intel_context.vm.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 7 +-
.../drm/i915/gem/selftests/i915_gem_context.c | 2
Thanks for the clarification!
On Tue, 2019-07-16 at 16:22 +0100, liviu.du...@arm.com wrote:
> > > > +static void invalid_out_fence(igt_output_t *output, igt_fb_t
> > > > *valid_fb, igt_fb_t *invalid_fb)
> > > > +{
> > > > + int i, ret;
> > > > + int32_t out_fence;
> > > > +
Prior to freeing the struct, call the fini function to cleanup the
common members. Currently this only calls the debug functions to mark
the structs as destroyed, but may be extended to real work in future.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_context.c| 6 ++
From: Ville Syrjälä
On VLV/CHV there is some kind of linkage between the cdclk frequency
and the DP link frequency. The spec says:
"For DP audio configuration, cdclk frequency shall be set to
meet the following requirements:
DP Link Frequency(MHz) | Cdclk frequency(MHz)
270
On Tue, Jul 16, 2019 at 03:03:21PM -0700, Dhinakaran Pandiyan wrote:
> A single 32-bit PSR2 training pattern field follows the sixteen element
> array of PSR table entries in the VBT spec. But, we incorrectly define
> this PSR2 field for each of the PSR table entries. As a result, the PSR1
>
Quoting Michal Wajdeczko (2019-07-17 11:47:51)
> On Wed, 17 Jul 2019 12:44:18 +0200, Tvrtko Ursulin
> wrote:
>
> > From: Tvrtko Ursulin
> >
> > Commit f774f0964919 ("drm/i915/guc: Turn on GuC/HuC auto mode") changed
> > the default from 0 to -1 but forgot to update the description.
> >
> >
== Series Details ==
Series: drm/i915: Update description of i915.enable_guc modparam
URL : https://patchwork.freedesktop.org/series/63804/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6496 -> Patchwork_13669
Summary
The aliasing_ppgtt provides a PIN_USER alias for the global gtt, so move
it under the i915_ggtt to simplify later transformations to enable
intel_context.vm.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 7 +-
.../drm/i915/gem/selftests/i915_gem_context.c | 2
On Wed, 17 Jul 2019 12:44:18 +0200, Tvrtko Ursulin
wrote:
From: Tvrtko Ursulin
Commit f774f0964919 ("drm/i915/guc: Turn on GuC/HuC auto mode") changed
the default from 0 to -1 but forgot to update the description.
Signed-off-by: Tvrtko Ursulin
Fixes: f774f0964919 ("drm/i915/guc: Turn on
1 - 100 of 116 matches
Mail list logo
