On 07/08/2019 06:41 PM, Chris Wilson wrote:
> Quoting Xiaolin Zhang (2019-07-08 02:35:18)
>> +static void pv_submit(struct intel_engine_cs *engine,
>> + struct i915_request **out,
>> + struct i915_request **end)
>> +{
>> + struct intel_engine_execlists * const execli
On Sat, 20 Jul 2019 13:33:37 +0200,
Chris Wilson wrote:
>
> I was looking at
>
> <4> [241.835158] general protection fault: [#1] PREEMPT SMP PTI
> <4> [241.835181] CPU: 1 PID: 214 Comm: kworker/1:3 Tainted: G U
> 5.2.0-CI-CI_DRM_6509+ #1
> <4> [241.835199] Hardware name: Dell
On 2019-07-19 at 11:39:54 -0700, Lucas De Marchi wrote:
> On Thu, Jul 18, 2019 at 11:17:03AM +0530, Anshuman Gupta wrote:
> >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.
> >
Quoting Robin Murphy (2019-07-22 11:13:49)
> Hi Chris,
>
> On 20/07/2019 19:08, Chris Wilson wrote:
> > Since the cached32_node is allowed to be advanced above dma_32bit_pfn
> > (to provide a shortcut into the limited range), we need to be careful to
> > remove the to be freed node if it is the ca
== Series Details ==
Series: Send a hotplug when edid changes (rev3)
URL : https://patchwork.freedesktop.org/series/62816/
State : failure
== Summary ==
Applying: drm: Add helper to compare edids.
Applying: drm: Introduce change counter to drm_connector
Applying: drm/i915: Send hotplug event i
On 19/07/2019 16.07, Chris Wilson wrote:
> The top-level page directory for 36b is a single entry, not multiple
> like 32b. Fix up the rounding on the calculation of the size of the top
> level so that we populate the 4th level correctly for 36b.
>
Reviewed-by: Abdiel Janulgue
> Reported-by:
On 20/07/2019 15:31, Chris Wilson wrote:
Enabling atomic operations in L3 leads to unrecoverable GPU hangs, as
the machine stops responding milliseconds after receipt of the reset
request [GDRT]. By disabling the cached atomics, the hang do not occur
and we presume the GPU would reset normally f
On 19/07/2019 18:21, Chris Wilson wrote:
The shrinker cannot touch objects used by the contexts (logical state
and ring). Currently we mark those as "pin_global" to let the shrinker
skip over them, however, if we remove them from the shrinker lists
entirely, we don't event have to include them i
On 18/07/2019 13:42, Chris Wilson wrote:
As our global unpark/park keep track of the number of active users, we
can simply move the accounting from the GEM layer to the base GT layer.
It was placed originally inside GEM to benefit from the 100ms extra
delay on idleness, but that has been elimina
On 18/07/2019 08:00, Chris Wilson wrote:
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/
On 18/07/2019 08:00, Chris Wilson wrote:
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
On 18/07/2019 08:00, Chris Wilson wrote:
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 s
On 18/07/2019 08:00, Chris Wilson wrote:
Use the same mechanism to determine if a backend engine exists for a
uabi mapping as used internally.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.c | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/dr
On 18/07/2019 08:00, Chris Wilson wrote:
This giant switch has tendrils over other the struct and does not fit
into the rest of the driver bring up and control of i915_drv.c. Push it
to one side so that it can grow in peace.
No complaints on this one so acked.
Regards,
Tvrtko
Signed-off-b
As a w/a for data corruption, we are told to set the preemption vertex
count to 0x20 on boot. As it is a counter, once contexts are active we
do not expect the value to be retained, so hide it from the wa-list
verification.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915
On 18/07/2019 08:00, Chris Wilson wrote:
Trust that we now have adequate protection over the low level structures
via the engine->active.lock to allow ourselves to capture the GPU error
state without the heavy hammer of stop_machine(). Sadly this does mean
that we have to forgo some of the lesse
== Series Details ==
Series: drm/i915/gt: WaSetVfGuardbandPreemptionVertexCount (bdw/chv)
URL : https://patchwork.freedesktop.org/series/64014/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6524 -> Patchwork_13714
Summary
-
Hi Chris,
On 20/07/2019 19:08, Chris Wilson wrote:
Since the cached32_node is allowed to be advanced above dma_32bit_pfn
(to provide a shortcut into the limited range), we need to be careful to
remove the to be freed node if it is the cached32_node.
Thanks for digging in - just to confirm my u
On 11/07/2019 12:46, Lionel Landwerlin wrote:
+
+ syncobj = drm_syncobj_find(eb->file, user_fence.handle);
+ if (!syncobj) {
+ DRM_DEBUG("Invalid syncobj handle provided\n");
+ err = -EINVAL;
+ goto err;
On 22/07/2019 14:18, Chris Wilson wrote:
As a w/a for data corruption, we are told to set the preemption vertex
count to 0x20 on boot. As it is a counter, once contexts are active we
do not expect the value to be retained, so hide it from the wa-list
verification.
Signed-off-by: Chris Wilson
On Sat, Jul 20, 2019 at 07:08:48PM +0100, Chris Wilson wrote:
> ---
> drivers/iommu/iova.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
Applied to iommu/fixes.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.fre
On 18/07/2019 08:00, Chris Wilson wrote:
In the next patch, we would like to couple into the engine wakeref to
free the batch pool on idling. The caveat here is that we therefore want
to track the engine wakeref more precisely and to hold it instead of the
broader GT wakeref as we process the io
Quoting Tvrtko Ursulin (2019-07-22 16:55:39)
>
>
> On 22/07/2019 14:18, Chris Wilson wrote:
> > As a w/a for data corruption, we are told to set the preemption vertex
> > count to 0x20 on boot. As it is a counter, once contexts are active we
> > do not expect the value to be retained, so hide it
Forgot to say...
On 18/07/2019 08:00, Chris Wilson wrote:
This giant switch has tendrils over other the struct and does not fit
... "over the struct"? Over something else I think, just can't guess
what you wanted to say. :)
Regards,
Tvrtko
into the rest of the driver bring up and control
On 18/07/2019 08:00, Chris Wilson wrote:
Lift moving the timeline to/from the active_list on enter/exit in order
to shorten the active tracking span in comparison to the existing
pin/unpin.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gem/i915_gem_pm.c| 1 -
drivers/gpu/drm
Quoting Tvrtko Ursulin (2019-07-22 17:04:54)
> Forgot to say...
>
> On 18/07/2019 08:00, Chris Wilson wrote:
> > This giant switch has tendrils over other the struct and does not fit
>
> ... "over the struct"? Over something else I think, just can't guess
> what you wanted to say. :)
All over.
Quoting Tvrtko Ursulin (2019-07-22 13:33:14)
>
> On 18/07/2019 08:00, Chris Wilson wrote:
> > @@ -1113,9 +1121,8 @@ static int set_ppgtt(struct drm_i915_file_private
> > *file_priv,
> > set_ppgtt_barrier,
> > old);
> > if (er
Quoting Tvrtko Ursulin (2019-07-22 13:46:06)
>
> On 18/07/2019 08:00, Chris Wilson wrote:
> > static void i915_driver_mmio_release(struct drm_i915_private *dev_priv)
> > {
> > + intel_engines_cleanup(dev_priv);
> > intel_teardown_mchbar(dev_priv);
> > intel_uncore_fini_mmio(&de
Quoting Tvrtko Ursulin (2019-07-22 13:49:54)
>
> On 18/07/2019 08:00, Chris Wilson wrote:
> > Use the same mechanism to determine if a backend engine exists for a
> > uabi mapping as used internally.
> >
> > Signed-off-by: Chris Wilson
> > ---
> > drivers/gpu/drm/i915/i915_drv.c | 13 +
Quoting Tvrtko Ursulin (2019-07-22 17:14:23)
>
> On 18/07/2019 08:00, Chris Wilson wrote:
> > diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
> > b/drivers/gpu/drm/i915/gt/intel_lrc.c
> > index 884dfc1cb033..aceb990ae3b9 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_lrc.c
> > +++ b/drivers/gpu/
== Series Details ==
Series: drm/i915/gt: WaSetVfGuardbandPreemptionVertexCount (bdw/chv)
URL : https://patchwork.freedesktop.org/series/64014/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6524_full -> Patchwork_13714_full
On Mon, Jul 22, 2019 at 01:11:40PM +0530, Anshuman Gupta wrote:
On 2019-07-19 at 11:39:54 -0700, Lucas De Marchi wrote:
On Thu, Jul 18, 2019 at 11:17:03AM +0530, Anshuman Gupta wrote:
>On 2019-07-12 at 18:09:39 -0700, Lucas De Marchi wrote:
>>From: José Roberto de Souza
>>
>>Tiger Lask has a ne
On Mon, Jul 22, 2019 at 01:12:44PM -0500, Gustavo A. R. Silva wrote:
> In preparation to enabling -Wimplicit-fallthrough, mark switch
> cases where we are expecting to fall through.
>
> This patch fixes the following warnings:
>
> drivers/gpu/drm/i915/gem/i915_gem_mman.c: In function ‘i915_gem_fa
In preparation to enabling -Wimplicit-fallthrough, mark switch
cases where we are expecting to fall through.
This patch fixes the following warnings:
drivers/gpu/drm/i915/gem/i915_gem_mman.c: In function ‘i915_gem_fault’:
drivers/gpu/drm/i915/gem/i915_gem_mman.c:342:6: warning: this statement may
== Series Details ==
Series: drm/i915: Mark expected switch fall-throughs (rev3)
URL : https://patchwork.freedesktop.org/series/34495/
State : failure
== Summary ==
Applying: drm/i915: Mark expected switch fall-throughs
Using index info to reconstruct a base tree...
M drivers/gpu/drm/i91
Maxime didn't really compile-test this :-/
We need to re-apply
commit e4fa8457b2197118538a1400b75c898f9faaf164
Author: Daniel Vetter
Date: Fri Jun 14 22:35:25 2019 +0200
drm/prime: Align gem_prime_export with obj_funcs.export
plus make sure i915_gem_dma_buf.c doesn't get zombie-resurrect
Quoting Daniel Vetter (2019-07-22 22:21:01)
> Maxime didn't really compile-test this :-/
>
> We need to re-apply
>
> commit e4fa8457b2197118538a1400b75c898f9faaf164
> Author: Daniel Vetter
> Date: Fri Jun 14 22:35:25 2019 +0200
>
> drm/prime: Align gem_prime_export with obj_funcs.export
>
Maxime didn't really compile-test this :-/
We need to re-apply
commit e4fa8457b2197118538a1400b75c898f9faaf164
Author: Daniel Vetter
Date: Fri Jun 14 22:35:25 2019 +0200
drm/prime: Align gem_prime_export with obj_funcs.export
plus make sure i915_gem_dma_buf.c doesn't get zombie-resurrect
Quoting Daniel Vetter (2019-07-22 22:37:59)
> Maxime didn't really compile-test this :-/
>
> We need to re-apply
>
> commit e4fa8457b2197118538a1400b75c898f9faaf164
> Author: Daniel Vetter
> Date: Fri Jun 14 22:35:25 2019 +0200
>
> drm/prime: Align gem_prime_export with obj_funcs.export
>
Quoting Tvrtko Ursulin (2019-07-22 13:16:38)
>
> On 18/07/2019 13:42, Chris Wilson wrote:
> > As our global unpark/park keep track of the number of active users, we
> > can simply move the accounting from the GEM layer to the base GT layer.
> > It was placed originally inside GEM to benefit from t
On Mon, Jul 22, 2019 at 11:41 PM Chris Wilson wrote:
>
> Quoting Daniel Vetter (2019-07-22 22:37:59)
> > Maxime didn't really compile-test this :-/
> >
> > We need to re-apply
> >
> > commit e4fa8457b2197118538a1400b75c898f9faaf164
> > Author: Daniel Vetter
> > Date: Fri Jun 14 22:35:25 2019 +0
Quoting Tvrtko Ursulin (2019-07-22 13:08:42)
>
> On 19/07/2019 18:21, Chris Wilson wrote:
> > The shrinker cannot touch objects used by the contexts (logical state
> > and ring). Currently we mark those as "pin_global" to let the shrinker
> > skip over them, however, if we remove them from the shr
Trust that we now have adequate protection over the low level structures
via the engine->active.lock to allow ourselves to capture the GPU error
state without the heavy hammer of stop_machine(). Sadly this does mean
that we have to forgo some of the lesser used information (not derived
from the act
On Fri, 2019-07-12 at 18:09 -0700, Lucas De Marchi wrote:
> The final save operation into pll_state of the calculations done will
> be different for DKL PHY. Prepare for that by reindenting code so
> it's
> easier to check for correctness. This one has no change in behavior.
>
Reviewed-by: Matt At
== Series Details ==
Series: drm/i915: Rely on spinlock protection for GPU error capture
URL : https://patchwork.freedesktop.org/series/64037/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915: Rely on spinlock protection for GPU error capture
-O
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. Secon
The main aim of this patch series is unify the guc_fw and huc_fw
handling paths and improve the related state tracking. Ultimately, I'd
like to reach the point where we can kill the intel_guc_fw and
intel_huc_fw files and just keep the few differences in other files. Not
yet going that far in this
This was the last place in gt/uc that was still using I915_READ
with the global dev_priv.
Signed-off-by: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/gt/uc/intel_uc.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
b/drivers/gpu
We have several HAS_* checks for GuC and HuC but we mostly use HAS_GUC
and HAS_HUC, with only 1 exception. Since our HW always has either
both uC or neither of them, just replace all the checks with a unified
HAS_UC.
Signed-off-by: Daniele Ceraolo Spurio
Cc: Michal Wajdeczko
---
drivers/gpu/drm
The microcontrollers are part of GT so it makes logical sense to have
them sanitized at the same time. This also fixed an issue with our
status tracking where the FW load status is not reset around
hibernation.
Signed-off-by: Daniele Ceraolo Spurio
Cc: Michal Wajdeczko
Cc: Chris Wilson
---
dri
The binary is perma-pinned and the rsa is not going to change, so copy
it only once and not on every load.
Signed-off-by: Daniele Ceraolo Spurio
Cc: Fernando Pacheco
---
drivers/gpu/drm/i915/gt/uc/intel_huc.c| 21 +
drivers/gpu/drm/i915/gt/uc/intel_huc.h| 1 -
drive
Instead of having 2 identical functions for GuC and HuC firmware
selection, we can unify the selection logic and just use different lists
based on FW type.
Note that the revid is not relevant for current blobs, but the upcoming
CML will be identified as CFL rev 5, so by considering the revid we're
The way we load the firmwares is the same for both GuC and HuC, the only
difference is in the wopcm destination address and the dma flags, so we
easily can move the logic to a common function and pass in offset and
flags. The only other difference in the uplaod path are some the extra
steps that gu
We currently track fetch and load status separately, but the 2 are
actually sequential in the uc lifetime (fetch must complete before we
can attempt the load!). Unifying the 2 variables we can better follow
the sequential states and improve our trackng of the uC state.
Also, sprinkle some GEM_BUG_
The gt is our new central structure for uc-related code, so we can use
that instead of jumping back to i915 via the fw object. Since we have it
in the upload function it is easy to pass it through the lower levels of
the xfer process instead of continuosly jumping via uc_fw->uc->gt, which
will also
The way we copy the RSA is the same for GuC and HuC, so we can move the
logic in a common function. this will also make any update needed for
local memory easier.
Signed-off-by: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/gt/uc/intel_guc_fw.c | 5 +
drivers/gpu/drm/i915/gt/uc/intel_huc_f
== Series Details ==
Series: drm/i915: Rely on spinlock protection for GPU error capture
URL : https://patchwork.freedesktop.org/series/64037/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6534 -> Patchwork_13716
Summary
--
Hi Gustavo,
could you please rebase on top of drm-tip and resend it please?
Thanks,
Rodrigo.
On Mon, Jul 22, 2019 at 01:12:44PM -0500, Gustavo A. R. Silva wrote:
> In preparation to enabling -Wimplicit-fallthrough, mark switch
> cases where we are expecting to fall through.
>
> This patch fixes
== Series Details ==
Series: uC fw path unification + misc clean-up
URL : https://patchwork.freedesktop.org/series/64039/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
1defc4182153 drm/i915/uc: Gt-fy uc reset
ad3b67774d80 drm/i915/uc: Unify uC platform check
5917a7b6440c drm/i9
== Series Details ==
Series: uC fw path unification + misc clean-up
URL : https://patchwork.freedesktop.org/series/64039/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915/uc: Gt-fy uc reset
Okay!
Commit: drm/i915/uc: Unify uC platform check
Oka
Hi all,
Today's linux-next merge of the drm-intel tree got a conflict in:
drivers/gpu/drm/i915/display/intel_dp.c
between commit:
b6ac32eac063 ("drm/i915: Mark expected switch fall-throughs")
from the kspp-gustavo tree and commit:
bc85328ff431 ("drm/i915: Move the TypeC port handling co
== Series Details ==
Series: uC fw path unification + misc clean-up
URL : https://patchwork.freedesktop.org/series/64039/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6535 -> Patchwork_13717
Summary
---
**SUCCESS**
To improve vgpu performance, it could implement some PV optimization
such as to reduce the mmio access trap numbers or eliminate certain piece
of HW emulation within guest driver to reduce vm exit/vm enter cost.
the solutions in this patch set are implemented two PV optimizations based
on the shar
pv capability for vgpu was introduced by pv_caps in struct
i915_virtual_gpu and a new pv_caps register for host GVT
was defined in struct vgt_if for vgpu pv optimization.
both of them are used to control different feature pv optimization
supported and implemented by both guest and host.
These fie
To enable vgpu pv features, we need to setup a shared memory page
which will be used for data exchange directly accessed between both
guest and backend i915 driver to avoid emulation trap cost.
guest i915 will allocate this page memory and then pass it's physical
address to backend i915 driver thr
implemented context submission pv optimizaiton within GVTg.
GVTg to read context submission data (elsp_data) from the shared_page
directly without trap cost and eliminate execlist HW behavior emulation
without injecting context switch interrupt to guest under PV
submisison mechanism.
v0: RFC.
v1:
based on the shared memory setup between guest and GVT, the simple
pv command buffer ring was introduced by this patch used to perform
guest-2-gvt single direction communication.
v1: initial support, added to address i915 PV v6 patch set comment.
Signed-off-by: Xiaolin Zhang
---
drivers/gpu/drm
It is performance optimization to override the actual submisison backend
in order to eliminate execlists csb process and reduce mmio trap numbers
for workload submission without context switch interrupt by talking with
GVT via PV submisison notification mechanism between guest and GVT.
Use PV_SUBM
GVTg implemented shared_page setup operation and read_shared_page
functionality based on hypervisor_read_gpa().
the shared_page_gpa was passed from guest driver through PVINFO
shared_page_gpa register.
v0: RFC.
v1: rebase.
v2: rebase.
v3: added shared_page_gpa check and if read_gpa failure, retur
This patch extends vgpu ppgtt g2v notification to notify host
GVT-g of ppgtt update from guest including alloc_4lvl, clear_4lv4
and insert_4lvl.
These updates use the shared memory page to pass struct pv_ppgtt_update
from guest to GVT which is used for pv optimiation implemeation within
host GVT s
implement pv_caps PVINFO register handler in GVTg to
control different level pv optimization within guest.
report VGT_CAPS_PV capability in pvinfo page for guest.
v0: RFC.
v1: rebase.
v2: rebase.
v3: renamed enable_pvmmio to pvmmio_caps which is used for host
pv caps.
v4: renamed pvmmio_caps to p
This patch handles ppgtt update from g2v notification.
It read out ppgtt pte entries from guest pte tables page and
convert them to host pfns.
It creates local ppgtt tables and insert the content pages
into the local ppgtt tables directly, which does not track
the usage of guest page table and re
== Series Details ==
Series: drm/i915: Rely on spinlock protection for GPU error capture
URL : https://patchwork.freedesktop.org/series/64037/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6534_full -> Patchwork_13716_full
== Series Details ==
Series: i915 vgpu PV to improve vgpu performance
URL : https://patchwork.freedesktop.org/series/64041/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
966d9464feed drm/i915: introduced vgpu pv capability
-:91: CHECK:PARENTHESIS_ALIGNMENT: Alignment should mat
== Series Details ==
Series: i915 vgpu PV to improve vgpu performance
URL : https://patchwork.freedesktop.org/series/64041/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915: introduced vgpu pv capability
Okay!
Commit: drm/i915: vgpu shared memo
== Series Details ==
Series: i915 vgpu PV to improve vgpu performance
URL : https://patchwork.freedesktop.org/series/64041/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6535 -> Patchwork_13718
Summary
---
**SUCCESS*
== Series Details ==
Series: uC fw path unification + misc clean-up
URL : https://patchwork.freedesktop.org/series/64039/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6535_full -> Patchwork_13717_full
Summary
---
**
== Series Details ==
Series: i915 vgpu PV to improve vgpu performance
URL : https://patchwork.freedesktop.org/series/64041/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6535_full -> Patchwork_13718_full
Summary
---
On Thu, Jul 11, 2019 at 01:26:39PM +0200, Andrzej Pietrasiewicz wrote:
> Use the ddc pointer provided by the generic connector.
>
> Signed-off-by: Andrzej Pietrasiewicz
Acked-by: Shawn Guo
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
htt
On Thu, Jul 11, 2019 at 01:26:40PM +0200, Andrzej Pietrasiewicz wrote:
> Use the ddc pointer provided by the generic connector.
>
> Signed-off-by: Andrzej Pietrasiewicz
Acked-by: Shawn Guo
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
htt
80 matches
Mail list logo
