On Tue, 2018-07-31 at 15:35 +0200, Maarten Lankhorst wrote:
> This will make it easier to test PSR1 on PSR2 capable eDP machines.
Thanks for writing this patch, we can make use of this to fix failures
on PSR2 machines in CI.
>
> Signed-off-by: Maarten Lankhorst
> ---
>
== Series Details ==
Series: series starting with [1/2] drm/i915: Unmask user interrupts writes into
HWSP on snb/ivb/vlv/hsw
URL : https://patchwork.freedesktop.org/series/47845/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4630_full -> Patchwork_9876_full =
== Summary -
On Tue, 2018-07-31 at 15:35 +0200, Maarten Lankhorst wrote:
> Currently tests modify i915.enable_psr and then do a modeset cycle
> to change PSR. We can write a value to i915_edp_psr_debug to force
> a certain PSR mode without a modeset.
>
> To retain compatibility with older userspace, we also
== Series Details ==
Series: drm/amdgpu: Transfer fences to dmabuf importer (rev6)
URL : https://patchwork.freedesktop.org/series/47803/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4630_full -> Patchwork_9875_full =
== Summary - WARNING ==
Minor unknown changes coming
== Series Details ==
Series: Forward Error Correction
URL : https://patchwork.freedesktop.org/series/47848/
State : failure
== Summary ==
Applying: drm/dp/fec: DRM helper for Forward Error Correction
Using index info to reconstruct a base tree...
M drivers/gpu/drm/drm_dp_helper.c
M
Quoting Anusha Srivatsa (2018-08-08 00:05:32)
> +void intel_dp_disable_fec_state(struct intel_dp *intel_dp,
> + const struct intel_crtc_state *crtc_state)
> +{
> + struct drm_i915_private *dev_priv =
> to_i915(intel_dp_to_dev(intel_dp));
> + struct
From: "Srivatsa, Anusha"
If FEC is supported, the corresponding
DP_TP_CTL register bits have to be configured.
The driver has to program the FEC_ENABLE in DP_TP_CTL[30] register
and wait till FEC_STATUS in DP_TP_CTL[28] is 1.
Also add the warn message to make sure that the control
register is
From: "Srivatsa, Anusha"
Set the suitable bits in DP_TP_CTL to stop
bit correction when DSC is disabled.
v2:
- rebased.
- Add additional check for compression state. (Gaurav)
Cc: Gaurav K Singh
Cc: Jani Nikula
Cc: Ville Syrjala
Cc: Manasi Navare
Signed-off-by: Anusha Srivatsa
---
From: "Srivatsa, Anusha"
For DP 1.4 and above, Display Stream compression can be
enabled only if Forward Error Correctin can be performed.
If FEC support exists, write to the FEC_READY bit
in the FEC_CONFIGURATION DPCD register.
v2: Mention External DP where ever FEC is mentioned
in the
With Display Stream Compression, bit error
in pixel stream can turn into a significant
corruption on the screen. DP1.4 adds support for
Forward Eror correction which uses Reed-Solomon
codes with which the sink can detect small
numbers of bit errors in compressed stream.
This series is rebased on
From: "Srivatsa, Anusha"
DP 1.4 has Forward Error Correction Support(FEC).
Add helper function to check if the sink device
supports FEC.
v2: Separate the helper and the code that uses the helper into
two separate patches. (Manasi)
v3:
- Move the code to drm_dp_helper.c (Manasi)
- change the
From: "Srivatsa, Anusha"
If the panel supports FEC, the driver has to
set the FEC_READY bit in the dpcd register:
FEC_CONFIGURATION.
This has to happen before link training.
v2: s/intel_dp_set_fec_ready/intel_dp_sink_set_fec_ready
- change commit message. (Gaurav)
Cc: Gaurav K Singh
Cc:
== Series Details ==
Series: series starting with [1/2] drm/i915: Unmask user interrupts writes into
HWSP on snb/ivb/vlv/hsw
URL : https://patchwork.freedesktop.org/series/47845/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4630 -> Patchwork_9876 =
== Summary - SUCCESS
== Series Details ==
Series: series starting with [1/2] drm/i915: Unmask user interrupts writes into
HWSP on snb/ivb/vlv/hsw
URL : https://patchwork.freedesktop.org/series/47845/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
6fc98f5ea250 drm/i915: Unmask user interrupts
On Tue, 2018-08-07 at 22:26 +, Jan-Marek Glogowski wrote:
> Am August 7, 2018 7:33:12 PM UTC schrieb Lyude Paul :
> > On Mon, 2018-08-06 at 12:25 +0200, Jan-Marek Glogowski wrote:
> > > This re-applies the workaround for "some DP sinks, [which] are a
> > > little nuts" from commit 1a36147bb939
An oddity occurs on Sandybridge, Ivybridge and Haswell (and presumably
Valleyview) in that for the period following the GPU restart after a
reset, there are no GT interrupts received. From Ville's notes, bit 0 in
the HWSTAM corresponds to the render interrupt, and if we unmask it we
do see
Now with a more efficacious workaround for the lost interrupts after
reset, we can remove the hack of kicking the waiters after reset. The
issue was that the kick only worked for the immediate window after the
reset (those seqno that would complete in the time it took for the
waiter thread to
== Series Details ==
Series: drm/amdgpu: Transfer fences to dmabuf importer (rev6)
URL : https://patchwork.freedesktop.org/series/47803/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4630 -> Patchwork_9875 =
== Summary - SUCCESS ==
No regressions found.
External URL:
On Mon, Aug 6, 2018 at 9:14 AM Chris Wilson
wrote:
> Quoting Anuj Phogat (2018-08-03 20:24:09)
> >
> >
> > On Mon, Jul 30, 2018 at 5:07 AM Mika Kuoppala <
> mika.kuopp...@linux.intel.com>
> > wrote:
> >
> > The register for 0xe420 is unable to hold any value, including
> > this bit. The
== Series Details ==
Series: drm/amdgpu: Transfer fences to dmabuf importer (rev6)
URL : https://patchwork.freedesktop.org/series/47803/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
153e529b6e66 drm/amdgpu: Transfer fences to dmabuf importer
-:28:
== Series Details ==
Series: dma-buf: Remove requirement for ops->map() from dma_buf_export
URL : https://patchwork.freedesktop.org/series/47834/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4627_full -> Patchwork_9874_full =
== Summary - SUCCESS ==
No regressions
amdgpu only uses shared-fences internally, but dmabuf importers rely on
implicit write hazard tracking via the reservation_object.fence_excl.
For example, the importer use the write hazard for timing a page flip to
only occur after the exporter has finished flushing its write into the
surface. As
== Series Details ==
Series: series starting with [1/2] drm/i915/selftests: Exercise invalidation of
dmabuf import from shrinker
URL : https://patchwork.freedesktop.org/series/47832/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4627_full -> Patchwork_9872_full =
==
On Mon, 2018-08-06 at 12:25 +0200, Jan-Marek Glogowski wrote:
> This re-applies the workaround for "some DP sinks, [which] are a
> little nuts" from commit 1a36147bb939 ("drm/i915: Perform link
> quality check unconditionally during long pulse").
> It makes the secondary AOC E2460P monitor
== Series Details ==
Series: dma-buf: Remove requirement for ops->map() from dma_buf_export
URL : https://patchwork.freedesktop.org/series/47834/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4627 -> Patchwork_9874 =
== Summary - SUCCESS ==
No regressions found.
== Series Details ==
Series: drm/amdgpu: Transfer fences to dmabuf importer (rev5)
URL : https://patchwork.freedesktop.org/series/47803/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4627 -> Patchwork_9873 =
== Summary - SUCCESS ==
No regressions found.
External URL:
On Tue, Aug 07, 2018 at 07:36:47PM +0100, Chris Wilson wrote:
> Since commit 9ea0dfbf972 ("dma-buf: make map_atomic and map function
> pointers optional"), the core provides the no-op functions when map and
> map_atomic are not provided, so we no longer need assert that are
> supplied by a dma-buf
== Series Details ==
Series: drm/amdgpu: Transfer fences to dmabuf importer (rev5)
URL : https://patchwork.freedesktop.org/series/47803/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
11096db8b2d5 drm/amdgpu: Transfer fences to dmabuf importer
-:27:
Am 07.08.2018 um 20:32 schrieb Chris Wilson:
amdgpu only uses shared-fences internally, but dmabuf importers rely on
implicit write hazard tracking via the reservation_object.fence_excl.
For example, the importer use the write hazard for timing a page flip to
only occur after the exporter has
== Series Details ==
Series: series starting with [1/2] drm/i915/selftests: Exercise invalidation of
dmabuf import from shrinker
URL : https://patchwork.freedesktop.org/series/47832/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4627 -> Patchwork_9872 =
== Summary -
Since commit 9ea0dfbf972 ("dma-buf: make map_atomic and map function
pointers optional"), the core provides the no-op functions when map and
map_atomic are not provided, so we no longer need assert that are
supplied by a dma-buf exporter.
Fixes: 09ea0dfbf972 ("dma-buf: make map_atomic and map
== Series Details ==
Series: series starting with [1/2] drm/i915/selftests: Exercise invalidation of
dmabuf import from shrinker
URL : https://patchwork.freedesktop.org/series/47832/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
05c8facfcb99 drm/i915/selftests: Exercise
amdgpu only uses shared-fences internally, but dmabuf importers rely on
implicit write hazard tracking via the reservation_object.fence_excl.
For example, the importer use the write hazard for timing a page flip to
only occur after the exporter has finished flushing its write into the
surface. As
Quoting Christian König (2018-08-07 19:18:55)
> Am 07.08.2018 um 20:14 schrieb Chris Wilson:
> > Quoting Christian König (2018-08-07 18:57:16)
> >> Am 07.08.2018 um 18:08 schrieb Chris Wilson:
> >>> amdgpu only uses shared-fences internally, but dmabuf importers rely on
> >>> implicit write hazard
Quoting Patchwork (2018-08-07 19:09:06)
> == Series Details ==
>
> Series: drm: Remove defunct dma_buf_kmap stubs
> URL : https://patchwork.freedesktop.org/series/47829/
> State : failure
>
> == Summary ==
>
> = CI Bug Log - changes from CI_DRM_4627 -> Patchwork_9871 =
>
> == Summary -
Am 07.08.2018 um 20:14 schrieb Chris Wilson:
Quoting Christian König (2018-08-07 18:57:16)
Am 07.08.2018 um 18:08 schrieb Chris Wilson:
amdgpu only uses shared-fences internally, but dmabuf importers rely on
implicit write hazard tracking via the reservation_object.fence_excl.
For example, the
Quoting Christian König (2018-08-07 18:57:16)
> Am 07.08.2018 um 18:08 schrieb Chris Wilson:
> > amdgpu only uses shared-fences internally, but dmabuf importers rely on
> > implicit write hazard tracking via the reservation_object.fence_excl.
> > For example, the importer use the write hazard for
We currently assume that if we import a dmabuf, it is not backed by
pages (we assume it exists in video memory on a foriegn device).
However, some dmabuf will be backed by ordinary struct pages (e.g. vgem)
and as such they may be shrinkable from direct reclaim. Since commit
09ea0dfbf972 ("dma-buf:
Check that we can invalidate an object created for an imported dmabuf
(i.e. that we release the obj->mm.pages, and so its associated mapping of
the dmabuf) under memory pressure invoking the shrinker for direct
reclaim.
This is using our mock_dmabuf as the exporter, so while we may miss
intricate
== Series Details ==
Series: drm: Remove defunct dma_buf_kmap stubs
URL : https://patchwork.freedesktop.org/series/47829/
State : failure
== Summary ==
= CI Bug Log - changes from CI_DRM_4627 -> Patchwork_9871 =
== Summary - FAILURE ==
Serious unknown changes coming with Patchwork_9871
Am 07.08.2018 um 18:08 schrieb Chris Wilson:
amdgpu only uses shared-fences internally, but dmabuf importers rely on
implicit write hazard tracking via the reservation_object.fence_excl.
For example, the importer use the write hazard for timing a page flip to
only occur after the exporter has
On Tue, Aug 07, 2018 at 06:47:48PM +0100, Chris Wilson wrote:
> Since commit 09ea0dfbf972 ("dma-buf: make map_atomic and map function
> pointers optional"), we no longer need to provide stub no-op functions
> as the core now provides them directly.
>
> References: 09ea0dfbf972 ("dma-buf: make
Am 07.08.2018 um 19:47 schrieb Chris Wilson:
Since commit 09ea0dfbf972 ("dma-buf: make map_atomic and map function
pointers optional"), we no longer need to provide stub no-op functions
as the core now provides them directly.
References: 09ea0dfbf972 ("dma-buf: make map_atomic and map function
== Series Details ==
Series: drm: Remove defunct dma_buf_kmap stubs
URL : https://patchwork.freedesktop.org/series/47829/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
ee6d380149a7 drm: Remove defunct dma_buf_kmap stubs
-:13: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped
Since commit 09ea0dfbf972 ("dma-buf: make map_atomic and map function
pointers optional"), we no longer need to provide stub no-op functions
as the core now provides them directly.
References: 09ea0dfbf972 ("dma-buf: make map_atomic and map function pointers
optional")
Signed-off-by: Chris
Quoting Patchwork (2018-08-07 18:15:35)
> igt@drv_selftest@live_dmabuf:
> fi-byt-n2820: PASS -> DMESG-FAIL
> fi-hsw-4770r: PASS -> DMESG-FAIL
> fi-kbl-r: PASS -> DMESG-FAIL
...
The lesson here is that objects created around imported dmabuf are not
Hi Zhenyu,
On 8/6/18 9:26 PM, Zhenyu Wang wrote:
> On 2018.08.02 22:40:19 -0500, Gustavo A. R. Silva wrote:
>> info.index can be indirectly controlled by user-space, hence leading
>> to a potential exploitation of the Spectre variant 1 vulnerability.
>>
>> This issue was detected with the help of
== Series Details ==
Series: drm/i915/selftests: Exercise invalidation of dmabuf import from shrinker
URL : https://patchwork.freedesktop.org/series/47825/
State : failure
== Summary ==
= CI Bug Log - changes from CI_DRM_4627 -> Patchwork_9870 =
== Summary - FAILURE ==
Serious unknown
Check that we restore runtime pm around debug suspends and hibernates.
v2: Differentiate between external test setup failure and one of
interest
Signed-off-by: Chris Wilson
---
tests/pm_rpm.c | 18 ++
1 file changed, 14 insertions(+), 4 deletions(-)
diff --git a/tests/pm_rpm.c
Check that we can invalidate an object created for an imported dmabuf
(i.e. that we release the obj->mm.pages, and so its associated mapping of
the dmabuf) under memory pressure invoking the shrinker for direct
reclaim.
This is using our mock_dmabuf as the exporter, so while we may miss
intricate
== Series Details ==
Series: drm/amdgpu: Transfer fences to dmabuf importer (rev4)
URL : https://patchwork.freedesktop.org/series/47803/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Commit: drm/amdgpu: Transfer fences to dmabuf importer
-
+./include/linux/slab.h:631:13: error:
== Series Details ==
Series: drm/amdgpu: Transfer fences to dmabuf importer (rev4)
URL : https://patchwork.freedesktop.org/series/47803/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
2d40cca5a9be drm/amdgpu: Transfer fences to dmabuf importer
-:24:
amdgpu only uses shared-fences internally, but dmabuf importers rely on
implicit write hazard tracking via the reservation_object.fence_excl.
For example, the importer use the write hazard for timing a page flip to
only occur after the exporter has finished flushing its write into the
surface. As
Create and export an amdgpu bo into i915 so that we can try and
invalidate the i915_bo->pages from inside the shrinker, teaching lockdep
about that linkage.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Daniel Vetter
---
tests/amdgpu/amd_prime.c | 32
1
Link a vgem dmabuf into an i915 bo and then ask the i915 shrinker to
purge/invalidate its pages. This should establish the lockdep link from
the fs_reclaim shrinker section to whatever locks are used to
acquire/release dmabuf mappings; if any are required ofc.
Signed-off-by: Chris Wilson
Cc:
On 07/08/2018 14:21, Daniel Vetter wrote:
On Wed, Jul 18, 2018 at 03:24:26PM +0200, Christian König wrote:
Hi Daniel,
Am 18.07.2018 um 14:07 schrieb Patchwork:
== Series Details ==
Series: series starting with [1/4] dma-buf: add caching of sg_table
URL :
Quoting Tvrtko Ursulin (2018-08-07 10:08:28)
>
> On 07/08/2018 08:29, Chris Wilson wrote:
> > + /*
> > + * The active request is now effectively the start of a new client
> > + * stream, so give it the equivalent small priority bump to prevent
> > + * it being gazumped a second
On Tue, Aug 07, 2018 at 09:46:02AM +0300, Dan Carpenter wrote:
> The > should be >= here so that we don't read one element beyond the
> end of the array.
>
> Fixes: 28a60dee2ce6 ("drm/i915/gvt: vGPU HW resource management")
> Signed-off-by: Dan Carpenter
Reviewed-by: Rodrigo Vivi
>
> diff
On Tue, Aug 7, 2018 at 3:54 PM, Christian König
wrote:
> Am 07.08.2018 um 15:37 schrieb Daniel Vetter:
>>
>> On Tue, Aug 07, 2018 at 03:17:06PM +0200, Christian König wrote:
>>>
>>> Am 07.08.2018 um 14:59 schrieb Daniel Vetter:
On Tue, Aug 07, 2018 at 02:51:50PM +0200, Christian König
Am 07.08.2018 um 15:37 schrieb Daniel Vetter:
On Tue, Aug 07, 2018 at 03:17:06PM +0200, Christian König wrote:
Am 07.08.2018 um 14:59 schrieb Daniel Vetter:
On Tue, Aug 07, 2018 at 02:51:50PM +0200, Christian König wrote:
Am 07.08.2018 um 14:43 schrieb Daniel Vetter:
On Tue, Aug 07, 2018 at
On Tue, Aug 07, 2018 at 03:17:06PM +0200, Christian König wrote:
> Am 07.08.2018 um 14:59 schrieb Daniel Vetter:
> > On Tue, Aug 07, 2018 at 02:51:50PM +0200, Christian König wrote:
> > > Am 07.08.2018 um 14:43 schrieb Daniel Vetter:
> > > > On Tue, Aug 07, 2018 at 01:23:19PM +0200, Christian
On Wed, Jul 18, 2018 at 03:24:26PM +0200, Christian König wrote:
> Hi Daniel,
>
> Am 18.07.2018 um 14:07 schrieb Patchwork:
> > == Series Details ==
> >
> > Series: series starting with [1/4] dma-buf: add caching of sg_table
> > URL : https://patchwork.freedesktop.org/series/46778/
> > State :
Am 07.08.2018 um 14:59 schrieb Daniel Vetter:
On Tue, Aug 07, 2018 at 02:51:50PM +0200, Christian König wrote:
Am 07.08.2018 um 14:43 schrieb Daniel Vetter:
On Tue, Aug 07, 2018 at 01:23:19PM +0200, Christian König wrote:
Am 07.08.2018 um 13:05 schrieb Chris Wilson:
amdgpu only uses
On Tue, Aug 07, 2018 at 02:51:50PM +0200, Christian König wrote:
> Am 07.08.2018 um 14:43 schrieb Daniel Vetter:
> > On Tue, Aug 07, 2018 at 01:23:19PM +0200, Christian König wrote:
> > > Am 07.08.2018 um 13:05 schrieb Chris Wilson:
> > > > amdgpu only uses shared-fences internally, but dmabuf
Am 07.08.2018 um 14:43 schrieb Daniel Vetter:
On Tue, Aug 07, 2018 at 01:23:19PM +0200, Christian König wrote:
Am 07.08.2018 um 13:05 schrieb Chris Wilson:
amdgpu only uses shared-fences internally, but dmabuf importers rely on
implicit write hazard tracking via the
On Tue, Aug 07, 2018 at 02:43:22PM +0200, Daniel Vetter wrote:
> On Tue, Aug 07, 2018 at 01:23:19PM +0200, Christian König wrote:
> > Am 07.08.2018 um 13:05 schrieb Chris Wilson:
> > > amdgpu only uses shared-fences internally, but dmabuf importers rely on
> > > implicit write hazard tracking via
On Tue, Aug 07, 2018 at 01:23:19PM +0200, Christian König wrote:
> Am 07.08.2018 um 13:05 schrieb Chris Wilson:
> > amdgpu only uses shared-fences internally, but dmabuf importers rely on
> > implicit write hazard tracking via the reservation_object.fence_excl.
>
> Well I would rather suggest a
== Series Details ==
Series: drm/amdgpu: Transfer fences to dmabuf importer (rev3)
URL : https://patchwork.freedesktop.org/series/47803/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4625_full -> Patchwork_9868_full =
== Summary - SUCCESS ==
No regressions found.
Quoting Mika Kuoppala (2018-08-07 10:09:48)
> Chris Wilson writes:
>
> > We have a few instances of checking seqno-1 to see if the HW has started
> > the request. Pull those together under a helper.
> >
> > v2: Pull the !seqno assertion higher, as we given seqno==1 we may indeed
> > check to see
== Series Details ==
Series: drm/amdgpu: Transfer fences to dmabuf importer (rev3)
URL : https://patchwork.freedesktop.org/series/47803/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4625 -> Patchwork_9868 =
== Summary - SUCCESS ==
No regressions found.
External URL:
Am 07.08.2018 um 13:05 schrieb Chris Wilson:
amdgpu only uses shared-fences internally, but dmabuf importers rely on
implicit write hazard tracking via the reservation_object.fence_excl.
Well I would rather suggest a solution where we stop doing this.
The problem here is that i915 assumes
== Series Details ==
Series: drm/amdgpu: Transfer fences to dmabuf importer (rev3)
URL : https://patchwork.freedesktop.org/series/47803/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Commit: drm/amdgpu: Transfer fences to dmabuf importer
-
+./include/linux/slab.h:631:13: error:
== Series Details ==
Series: drm/amdgpu: Transfer fences to dmabuf importer
URL : https://patchwork.freedesktop.org/series/47803/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4625 -> Patchwork_9867 =
== Summary - SUCCESS ==
No regressions found.
External URL:
amdgpu only uses shared-fences internally, but dmabuf importers rely on
implicit write hazard tracking via the reservation_object.fence_excl.
For example, the importer use the write hazard for timing a page flip to
only occur after the exporter has finished flushing its write into the
surface. As
Quoting Huang Rui (2018-08-07 11:56:24)
> On Tue, Aug 07, 2018 at 11:45:00AM +0100, Chris Wilson wrote:
> > amdgpu only uses shared-fences internally, but dmabuf importers rely on
> > implicit write hazard tracking via the reservation_object.fence_excl.
> > For example, the importer use the write
amdgpu only uses shared-fences internally, but dmabuf importers rely on
implicit write hazard tracking via the reservation_object.fence_excl.
For example, the importer use the write hazard for timing a page flip to
only occur after the exporter has finished flushing its write into the
surface. As
== Series Details ==
Series: drm/amdgpu: Transfer fences to dmabuf importer
URL : https://patchwork.freedesktop.org/series/47803/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Commit: drm/amdgpu: Transfer fences to dmabuf importer
-
+./include/linux/slab.h:631:13: error: undefined
== Series Details ==
Series: drm/amdgpu: Transfer fences to dmabuf importer
URL : https://patchwork.freedesktop.org/series/47803/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
dce1b6e891b2 drm/amdgpu: Transfer fences to dmabuf importer
-:56: WARNING:ALLOC_ARRAY_ARGS:
On Tue, Aug 07, 2018 at 11:45:00AM +0100, Chris Wilson wrote:
> amdgpu only uses shared-fences internally, but dmabuf importers rely on
> implicit write hazard tracking via the reservation_object.fence_excl.
> For example, the importer use the write hazard for timing a page flip to
> only occur
amdgpu only uses shared-fences internally, but dmabuf importers rely on
implicit write hazard tracking via the reservation_object.fence_excl.
For example, the importer use the write hazard for timing a page flip to
only occur after the exporter has finished flushing its write into the
surface. As
Chris Wilson writes:
> We have a few instances of checking seqno-1 to see if the HW has started
> the request. Pull those together under a helper.
>
> v2: Pull the !seqno assertion higher, as we given seqno==1 we may indeed
> check to see if we have started using seqno==0.
>
> Suggested-by:
On 07/08/2018 08:29, Chris Wilson wrote:
Taken from an idea used for FQ_CODEL, we give the first request of a
new request flows a small priority boost. These flows are likely to
correspond with short, interactive tasks and so be more latency sensitive
than the longer free running queues. As
Op 01-08-18 om 17:11 schreef Chris Wilson:
> Quoting Mahesh Kumar (2018-08-01 16:11:13)
>> We distribute DDB equally among all pipes irrespective of display
>> buffer requirement of each pipe. This leads to a situation where high
>> resolution y-tiled display can not be enabled with 2 low
== Series Details ==
Series: drm/i915/gvt: Off by one in intel_vgpu_write_fence()
URL : https://patchwork.freedesktop.org/series/47790/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4624_full -> Patchwork_9865_full =
== Summary - WARNING ==
Minor unknown changes coming
Check that we restore runtime pm around debug suspends and hibernates.
Signed-off-by: Chris Wilson
---
tests/pm_rpm.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/tests/pm_rpm.c b/tests/pm_rpm.c
index 4268bb19a..9bf718d63 100644
--- a/tests/pm_rpm.c
+++
Quoting Chris Wilson (2018-08-06 15:08:17)
> Since amdgpu is synchronous for exporting a dmabuf, exercise both paths
> to highlight the issue.
>
> v2: More action required to trigger the dmabuf-mapping
>
> References: https://bugs.freedesktop.org/show_bug.cgi?id=107341
> Signed-off-by: Chris
== Series Details ==
Series: series starting with [1/6] drm/i915: Limit C-states when waiting for
the active request (rev2)
URL : https://patchwork.freedesktop.org/series/47739/
State : failure
== Summary ==
Applying: drm/i915: Limit C-states when waiting for the active request
Applying:
Taken from an idea used for FQ_CODEL, we give the first request of a
new request flows a small priority boost. These flows are likely to
correspond with short, interactive tasks and so be more latency sensitive
than the longer free running queues. As soon as the client has more than
one request in
== Series Details ==
Series: drm/i915/gvt: Off by one in intel_vgpu_write_fence()
URL : https://patchwork.freedesktop.org/series/47790/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4624 -> Patchwork_9865 =
== Summary - SUCCESS ==
No regressions found.
External URL:
The > should be >= here so that we don't read one element beyond the
end of the array.
Fixes: 28a60dee2ce6 ("drm/i915/gvt: vGPU HW resource management")
Signed-off-by: Dan Carpenter
diff --git a/drivers/gpu/drm/i915/gvt/aperture_gm.c
b/drivers/gpu/drm/i915/gvt/aperture_gm.c
index
90 matches
Mail list logo
