== Series Details ==
Series: drm/i915/gvt: declare gvt as i915's soft dependency
URL : https://patchwork.freedesktop.org/series/45875/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4424_full -> Patchwork_9517_full =
== Summary - WARNING ==
Minor unknown changes coming wi
On 07/03/2018 08:12 PM, Paulo Zanoni wrote:
Em Seg, 2018-07-02 às 16:57 +0300, Imre Deak escreveu:
Work around the following boot time crash:
I worked around a very similar boot time crash by disabling
CONFIG_SLAB_FREELIST_HARDENED. Can you please verify if this helps?
From the CI kernel con
On Fri, 01 Jun 2018, Neil Armstrong wrote:
> The EC can expose a CEC bus, thus add the cros-ec-cec MFD sub-device
> when the CEC feature bit is present.
>
> Signed-off-by: Neil Armstrong
> Reviewed-by: Enric Balletbo i Serra
> Acked-by: Hans Verkuil
> ---
> drivers/mfd/cros_ec_dev.c | 16
On Tue, 03 Jul 2018, Ville Syrjälä wrote:
> On Tue, Jul 03, 2018 at 04:53:28PM +0300, Jani Nikula wrote:
>> Starting from ICL or gen 11 we have a new DSI block which requires
>> completely different programming from the current implementation. Having
>> them in the same file would be confusing. Re
On Tue, Jul 03, 2018 at 06:03:46PM +0200, Noralf Trønnes wrote:
> This patchset adds generic fbdev emulation for drivers that supports GEM
> based dumb buffers which support .gem_prime_vmap and gem_prime_mmap. An
> API is begun to support in-kernel clients in general.
>
> I've squashed the client
Using a VMA on more than one timeline concurrently is the exception
rather than the rule (using it concurrently on multiple engines). As we
expect to only use one active tracker, store the most recently used
tracker inside the i915_vma itself and only fallback to the rbtree if
we need a second or m
== Series Details ==
Series: series starting with [1/6] drm/i915: Refactor export_fence() after
i915_vma_move_to_active() (rev2)
URL : https://patchwork.freedesktop.org/series/45689/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
0f2a81bb4d94 drm/i915: Refactor export_fence() a
== Series Details ==
Series: series starting with [1/6] drm/i915: Refactor export_fence() after
i915_vma_move_to_active() (rev2)
URL : https://patchwork.freedesktop.org/series/45689/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Commit: drm/i915: Refactor export_fence() after i915
== Series Details ==
Series: series starting with [1/6] drm/i915: Refactor export_fence() after
i915_vma_move_to_active() (rev2)
URL : https://patchwork.freedesktop.org/series/45689/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4425 -> Patchwork_9518 =
== Summary - SUCCES
In the next patch, we will want to be able to use more flexible request
timelines that can hop between engines. From the vma pov, we can then
not rely on the binding of this request to an engine and so can not
ensure that different requests are ordered through a per-engine
timeline, and so we must
Quoting hang.y...@linux.intel.com (2018-07-04 04:07:45)
> From: Hang Yuan
>
> This helps initramfs builder and other tools to know the full dependencies
> of i915 and have gvt module loaded with i915.
>
> v2: add condition and change to pre-dependency (Chris)
> v3: move declaration to gvt.c. (Ch
dma_fence_default_wait is the default now, same for the trivial
enable_signaling implementation.
v2: Also remove the relase hook, dma_fence_free is the default.
Signed-off-by: Daniel Vetter
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
Cc: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Colin Ia
Hi all,
This is a resend of my dma-buf cleanup with the patches that didn't yet
get and ack/r-b. Feedback very much welcome.
Thanks, Daniel
Daniel Vetter (5):
drm/i915: Remove unecessary dma_fence_ops
drm/msm: Remove unecessary dma_fence_ops
drm/nouveau: Remove unecessary dma_fence_ops
d
dma_fence_default_wait is the default now, same for the trivial
enable_signaling implementation.
v2: Also remove the relase hook, dma_fence_free is the default.
Signed-off-by: Daniel Vetter
Cc: Rob Clark
Cc: linux-arm-...@vger.kernel.org
Cc: freedr...@lists.freedesktop.org
---
drivers/gpu/drm/
dma_fence_default_wait is the default now.
Signed-off-by: Daniel Vetter
Cc: Ben Skeggs
Cc: nouv...@lists.freedesktop.org
---
drivers/gpu/drm/nouveau/nouveau_fence.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_fence.c
b/drivers/gpu/drm/nouveau/nouveau_fenc
dma_fence_default_wait is the default now, same for the trivial
enable_signaling implementation.
Also remove the ->signaled callback, vgem can't peek ahead with a
fastpath, returning false is the default implementation.
Signed-off-by: Daniel Vetter
Cc: Kees Cook
Cc: Cihangir Akturk
Cc: Sean Pa
- Intro section that links to how this is exposed to userspace.
- Lots more hyperlinks.
- Minor clarifications and style polish
v2: Add misplaced hunk of kerneldoc from a different patch.
Signed-off-by: Daniel Vetter
Cc: Sumit Semwal
Cc: Gustavo Padovan
Cc: linux-me...@vger.kernel.org
Cc: lina
Thank you for the help to improve the patch! - Henry
On 07/04/2018 05:21 PM, Chris Wilson wrote:
Quoting hang.y...@linux.intel.com (2018-07-04 04:07:45)
From: Hang Yuan
This helps initramfs builder and other tools to know the full dependencies
of i915 and have gvt module loaded with i915.
v2
== Series Details ==
Series: series starting with [1/6] drm/i915: Refactor export_fence() after
i915_vma_move_to_active() (rev3)
URL : https://patchwork.freedesktop.org/series/45689/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
dd7709cafcb7 drm/i915: Refactor export_fence() a
On Mon, Jul 02, 2018 at 01:24:40PM +0300, Ville Syrjälä wrote:
> On Mon, Jul 02, 2018 at 10:12:21AM +0200, Daniel Vetter wrote:
> > This interface allows pretty much unlimited kernel memory allocations,
> > which isn't all that great. But we allow that anyway for any drm
> > master client (through
Am 04.07.2018 um 11:29 schrieb Daniel Vetter:
- Intro section that links to how this is exposed to userspace.
- Lots more hyperlinks.
- Minor clarifications and style polish
v2: Add misplaced hunk of kerneldoc from a different patch.
Signed-off-by: Daniel Vetter
Cc: Sumit Semwal
Cc: Gustavo P
== Series Details ==
Series: series starting with [1/6] drm/i915: Refactor export_fence() after
i915_vma_move_to_active() (rev3)
URL : https://patchwork.freedesktop.org/series/45689/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Commit: drm/i915: Refactor export_fence() after i915
On 04/07/2018 09:34, Chris Wilson wrote:
Using a VMA on more than one timeline concurrently is the exception
rather than the rule (using it concurrently on multiple engines). As we
expect to only use one active tracker, store the most recently used
tracker inside the i915_vma itself and only fal
Quoting Zhao, Yakui (2018-07-04 03:09:03)
> >-Original Message-
> >From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
> >Sent: Tuesday, July 3, 2018 10:08 PM
> >To: Zhao, Yakui ; Daniel Vetter
> >Cc: intel-gfx@lists.freedesktop.org
> >Subject: RE: [Intel-gfx] [PATCH v2 2/2] drm/i915: wri
From: Stanislav Lisovskiy
PLANE_CTL_FORMAT_AYUV is already supported, according to hardware
specification.
v2: Edited commit message, removed redundant whitespaces.
v3: Fixed fallthrough logic for the format switch cases.
v4: Yet again fixed fallthrough logic, to reuse code from other case
On 03/07/2018 21:29, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-07-03 18:28:31)
On 29/06/2018 23:54, Chris Wilson wrote:
In the next patch, we will want to be able to use more flexible request
timelines that can hop between engines. From the vma pov, we can then
not rely on the binding
== Series Details ==
Series: series starting with [1/6] drm/i915: Refactor export_fence() after
i915_vma_move_to_active() (rev3)
URL : https://patchwork.freedesktop.org/series/45689/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4425 -> Patchwork_9519 =
== Summary - SUCCES
== Series Details ==
Series: RESEND: dma-buf cleanup
URL : https://patchwork.freedesktop.org/series/45890/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
80713ee8fc35 drm/i915: Remove unecessary dma_fence_ops
-:4: WARNING:TYPO_SPELLING: 'unecessary' may be misspelled - perhaps
Quoting Tvrtko Ursulin (2018-07-04 10:43:07)
>
> On 03/07/2018 21:29, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2018-07-03 18:28:31)
> >>
> >> On 29/06/2018 23:54, Chris Wilson wrote:
> >>>/*
> >>> * Add a reference if we're newly entering the active list.
> >>> * The
On Tue, Jul 03, 2018 at 01:16:40PM -0700, clinton.a.tay...@intel.com wrote:
> From: Clint Taylor
>
> On GLK NUC platforms the HDMI retiming buffer needs additional disabled
> time to correctly sync to a faster incoming signal.
>
> When measured on a scope the highspeed lines of the HDMI clock tu
== Series Details ==
Series: RESEND: dma-buf cleanup
URL : https://patchwork.freedesktop.org/series/45890/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4425 -> Patchwork_9520 =
== Summary - SUCCESS ==
No regressions found.
External URL:
https://patchwork.freedesktop
== Series Details ==
Series: drm/i915: Adding YUV444 packed format(DRM_FORMAT_AYUV) support. (rev4)
URL : https://patchwork.freedesktop.org/series/45774/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
e74c7fdd30c5 drm/i915: Adding YUV444 packed format(DRM_FORMAT_AYUV) support.
-
== Series Details ==
Series: drm/i915: Adding YUV444 packed format(DRM_FORMAT_AYUV) support. (rev4)
URL : https://patchwork.freedesktop.org/series/45774/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4425 -> Patchwork_9521 =
== Summary - SUCCESS ==
No regressions found.
== Series Details ==
Series: series starting with [1/6] drm/i915: Refactor export_fence() after
i915_vma_move_to_active() (rev3)
URL : https://patchwork.freedesktop.org/series/45689/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4425_full -> Patchwork_9519_full =
== Summar
On Wed, Jul 04, 2018 at 11:10:06AM +0300, Jani Nikula wrote:
> On Tue, 03 Jul 2018, Ville Syrjälä wrote:
> > On Tue, Jul 03, 2018 at 04:53:28PM +0300, Jani Nikula wrote:
> >> Starting from ICL or gen 11 we have a new DSI block which requires
> >> completely different programming from the current i
On 04/07/2018 10:13, Chris Wilson wrote:
In the next patch, we will want to be able to use more flexible request
timelines that can hop between engines. From the vma pov, we can then
not rely on the binding of this request to an engine and so can not
ensure that different requests are ordered th
== Series Details ==
Series: RESEND: dma-buf cleanup
URL : https://patchwork.freedesktop.org/series/45890/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4425_full -> Patchwork_9520_full =
== Summary - WARNING ==
Minor unknown changes coming with Patchwork_9520_full need
On 04/07/2018 10:39, Tvrtko Ursulin wrote:
On 04/07/2018 09:34, Chris Wilson wrote:
Using a VMA on more than one timeline concurrently is the exception
rather than the rule (using it concurrently on multiple engines). As we
expect to only use one active tracker, store the most recently used
tr
Currently, the wc-stash used for providing flushed WC pages ready for
constructing the page directories is assumed to be protected by the
struct_mutex. However, we want to remove this global lock and so must
install a replacement global lock for accessing the global wc-stash (the
per-vm stash conti
Quoting Tvrtko Ursulin (2018-07-04 12:34:04)
>
> On 04/07/2018 10:39, Tvrtko Ursulin wrote:
> >
> > On 04/07/2018 09:34, Chris Wilson wrote:
> >> Using a VMA on more than one timeline concurrently is the exception
> >> rather than the rule (using it concurrently on multiple engines). As we
> >> e
== Series Details ==
Series: drm/i915/gtt: Pull global wc page stash under its own locking
URL : https://patchwork.freedesktop.org/series/45909/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Commit: drm/i915/gtt: Pull global wc page stash under its own locking
-O:drivers/gpu/drm/i9
Hi Daniel,
On 4 July 2018 at 10:29, Daniel Vetter wrote:
> dma_fence_default_wait is the default now, same for the trivial
> enable_signaling implementation.
>
> v2: Also remove the relase hook, dma_fence_free is the default.
>
> Signed-off-by: Daniel Vetter
> Cc: Jani Nikula
> Cc: Joonas Lahti
== Series Details ==
Series: drm/i915: Adding YUV444 packed format(DRM_FORMAT_AYUV) support. (rev4)
URL : https://patchwork.freedesktop.org/series/45774/
State : failure
== Summary ==
= CI Bug Log - changes from CI_DRM_4425_full -> Patchwork_9521_full =
== Summary - FAILURE ==
Serious unkn
== Series Details ==
Series: drm/i915/gtt: Pull global wc page stash under its own locking
URL : https://patchwork.freedesktop.org/series/45909/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4425 -> Patchwork_9522 =
== Summary - SUCCESS ==
No regressions found.
Extern
On 04/07/2018 12:47, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-07-04 12:34:04)
On 04/07/2018 10:39, Tvrtko Ursulin wrote:
On 04/07/2018 09:34, Chris Wilson wrote:
Using a VMA on more than one timeline concurrently is the exception
rather than the rule (using it concurrently on multip
On Wed, Jul 04, 2018 at 01:03:18PM +0100, Emil Velikov wrote:
> Hi Daniel,
>
> On 4 July 2018 at 10:29, Daniel Vetter wrote:
> > dma_fence_default_wait is the default now, same for the trivial
> > enable_signaling implementation.
> >
> > v2: Also remove the relase hook, dma_fence_free is the defa
If we allow 5s (+20% systematic error) to construct the fences, we may
reasonably assume that it will take equally as long to consume them. As
we only have 10s before the vgem fence times out, there is no margin of
safety.
Signed-off-by: Chris Wilson
---
tests/amdgpu/amd_prime.c | 2 +-
1 file c
Hi Lee,
On 04/07/2018 09:47, Lee Jones wrote:
> On Fri, 01 Jun 2018, Neil Armstrong wrote:
>
>> The EC can expose a CEC bus, thus add the cros-ec-cec MFD sub-device
>> when the CEC feature bit is present.
>>
>> Signed-off-by: Neil Armstrong
>> Reviewed-by: Enric Balletbo i Serra
>> Acked-by: Ha
On 04/07/2018 12:39, Chris Wilson wrote:
Currently, the wc-stash used for providing flushed WC pages ready for
constructing the page directories is assumed to be protected by the
struct_mutex. However, we want to remove this global lock and so must
install a replacement global lock for accessing
Quoting Tvrtko Ursulin (2018-07-04 13:48:18)
>
> On 04/07/2018 12:39, Chris Wilson wrote:
> > Currently, the wc-stash used for providing flushed WC pages ready for
> > constructing the page directories is assumed to be protected by the
> > struct_mutex. However, we want to remove this global lock
Quoting Chris Wilson (2018-07-04 13:53:54)
> Quoting Tvrtko Ursulin (2018-07-04 13:48:18)
> > >
> > > - if (stash.nr) {
> > > - int nr = min_t(int, stash.nr, pagevec_space(pvec));
> > > - struct page **pages = stash.pages + stash.nr - nr;
> > > + if (stash->nr &&
On Wed, 04 Jul 2018, Neil Armstrong wrote:
> Hi Lee,
>
> On 04/07/2018 09:47, Lee Jones wrote:
> > On Fri, 01 Jun 2018, Neil Armstrong wrote:
> >
> >> The EC can expose a CEC bus, thus add the cros-ec-cec MFD sub-device
> >> when the CEC feature bit is present.
> >>
> >> Signed-off-by: Neil Arms
Quoting Chris Wilson (2018-07-04 13:55:13)
> Quoting Chris Wilson (2018-07-04 13:53:54)
> > Quoting Tvrtko Ursulin (2018-07-04 13:48:18)
> > > >
> > > > - if (stash.nr) {
> > > > - int nr = min_t(int, stash.nr, pagevec_space(pvec));
> > > > - struct page **pages = sta
On Wed, Jul 04, 2018 at 12:41:52PM +0300, StanLis wrote:
> From: Stanislav Lisovskiy
>
> PLANE_CTL_FORMAT_AYUV is already supported, according to hardware
> specification.
>
> v2: Edited commit message, removed redundant whitespaces.
>
> v3: Fixed fallthrough logic for the format switch cases.
On Wed, Jul 04, 2018 at 01:38:23PM +0100, Chris Wilson wrote:
> If we allow 5s (+20% systematic error) to construct the fences, we may
> reasonably assume that it will take equally as long to consume them. As
> we only have 10s before the vgem fence times out, there is no margin of
> safety.
>
> S
On 04/07/2018 14:15, Chris Wilson wrote:
Quoting Chris Wilson (2018-07-04 13:55:13)
Quoting Chris Wilson (2018-07-04 13:53:54)
Quoting Tvrtko Ursulin (2018-07-04 13:48:18)
- if (stash.nr) {
- int nr = min_t(int, stash.nr, pagevec_space(pvec));
- struct page **p
Quoting Daniel Vetter (2018-07-04 14:57:33)
> On Wed, Jul 04, 2018 at 01:38:23PM +0100, Chris Wilson wrote:
> > If we allow 5s (+20% systematic error) to construct the fences, we may
> > reasonably assume that it will take equally as long to consume them. As
> > we only have 10s before the vgem fen
Like benchmarks/gem_syslatency, but to investigate/compare the impact
with amdgpu.
Signed-off-by: Chris Wilson
---
lib/igt_aux.h | 1 +
tests/Makefile.am | 2 +
tests/Makefile.sources| 1 +
tests/amdgpu/amd_syslatency.c | 404
Quoting Tvrtko Ursulin (2018-07-04 14:59:31)
>
> On 04/07/2018 14:15, Chris Wilson wrote:
> > Quoting Chris Wilson (2018-07-04 13:55:13)
> >> Quoting Chris Wilson (2018-07-04 13:53:54)
> >>> Quoting Tvrtko Ursulin (2018-07-04 13:48:18)
> >
> > - if (stash.nr) {
> > -
Currently, the wc-stash used for providing flushed WC pages ready for
constructing the page directories is assumed to be protected by the
struct_mutex. However, we want to remove this global lock and so must
install a replacement global lock for accessing the global wc-stash (the
per-vm stash conti
== Series Details ==
Series: drm/i915/gtt: Pull global wc page stash under its own locking (rev2)
URL : https://patchwork.freedesktop.org/series/45909/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
de6f8e0dd262 drm/i915/gtt: Pull global wc page stash under its own locking
-:289
== Series Details ==
Series: drm/i915/gtt: Pull global wc page stash under its own locking (rev2)
URL : https://patchwork.freedesktop.org/series/45909/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Commit: drm/i915/gtt: Pull global wc page stash under its own locking
-O:drivers/gpu
Mark up gem_pwrite_pread's dependence on a functioning GPU, by calling
igt_require_gem in its setup fixture.
Signed-off-by: Chris Wilson
---
tests/gem_pwrite_pread.c | 1 +
tests/gem_tiled_partial_pwrite_pread.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/tests/gem_pwrite
On Tue, 03 Jul 2018, Madhav Chauhan wrote:
> This register used to power down individual lanes for
> DDI/DSI ports. Bitfields to power up/down various
> combinations of lanes are also added in this patch.
>
> v2: Review comments from Jani N
> - Use override instead of "override" for bitfields
The draw-method-blt subtests require a working GPU, so create a subtest
group for the draw-methods, and skip the BLT group using
igt_require_gem() in its fixture.
Signed-off-by: Chris Wilson
---
tests/kms_draw_crc.c | 26 ++
1 file changed, 18 insertions(+), 8 deletions(
== Series Details ==
Series: drm/i915/gtt: Pull global wc page stash under its own locking (rev2)
URL : https://patchwork.freedesktop.org/series/45909/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4425 -> Patchwork_9523 =
== Summary - SUCCESS ==
No regressions found.
If the GPU is not usable, we will not be able to submit workloads to be
measured and so observing them will fail.
Signed-off-by: Chris Wilson
Cc: Lionel Landwerlin
---
tests/perf.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/tests/perf.c b/tests/perf.c
index 95048bfa5..2736918f7 1006
== Series Details ==
Series: drm/i915/gtt: Pull global wc page stash under its own locking
URL : https://patchwork.freedesktop.org/series/45909/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4425_full -> Patchwork_9522_full =
== Summary - WARNING ==
Minor unknown changes
On Tue, 03 Jul 2018, Madhav Chauhan wrote:
> This patch defines AUX lane registers for PORT_PCS_DW1,
> PORT_TX_DW2, PORT_TX_DW4, PORT_TX_DW5 used during
> dsi enabling.
>
> Signed-off-by: Madhav Chauhan
> ---
> drivers/gpu/drm/i915/i915_reg.h | 22 ++
> 1 file changed, 22 ins
Hi All,
The new Google "Fizz" Intel-based ChromeOS device is gaining CEC support
through it's Embedded Controller, to enable the Linux CEC Core to communicate
with it and get the CEC Physical Address from the correct HDMI Connector, the
following must be added/changed:
- Add the CEC sub-device reg
Having a 16 byte mkbp event size makes it possible to send CEC
messages from the EC to the AP directly inside the mkbp event
instead of first doing a notification and then a read.
Signed-off-by: Stefan Adolfsson
Signed-off-by: Neil Armstrong
Tested-by: Enric Balletbo i Serra
Acked-by: Hans Verk
This patchs adds the cec_notifier feature to the intel_hdmi part
of the i915 DRM driver. It uses the HDMI DRM connector name to differentiate
between each HDMI ports.
The changes will allow the i915 HDMI code to notify EDID and HPD changes
to an eventual CEC adapter.
Signed-off-by: Neil Armstrong
In non device-tree world, we can need to get the notifier by the driver
name directly and eventually defer probe if not yet created.
This patch adds a variant of the get function by using the device name
instead and will not create a notifier if not yet created.
But the i915 driver exposes at lea
The ChromeOS Embedded Controller can expose a CEC bus, this patch add the
driver for such feature of the Embedded Controller.
This driver is part of the cros-ec MFD and will be add as a sub-device when
the feature bit is exposed by the EC.
The controller will only handle a single logical address
The EC can expose a CEC bus, this patch adds the CEC related definitions
needed by the cros-ec-cec driver.
Signed-off-by: Neil Armstrong
Tested-by: Enric Balletbo i Serra
Reviewed-by: Hans Verkuil
Acked-for-MFD-by: Lee Jones
---
include/linux/mfd/cros_ec_commands.h | 81 ++
The EC can expose a CEC bus, thus add the cros-ec-cec MFD sub-device
when the CEC feature bit is present.
Signed-off-by: Neil Armstrong
Reviewed-by: Enric Balletbo i Serra
Acked-by: Hans Verkuil
Acked-for-MFD-by: Lee Jones
---
drivers/mfd/cros_ec_dev.c | 16
1 file changed, 1
== Series Details ==
Series: Add ChromeOS EC CEC Support (rev9)
URL : https://patchwork.freedesktop.org/series/43162/
State : failure
== Summary ==
Applying: media: cec-notifier: Get notifier by device and connector name
Applying: drm/i915: hdmi: add CEC notifier to intel_hdmi
Using index info
On 04/07/2018 15:25, Chris Wilson wrote:
Currently, the wc-stash used for providing flushed WC pages ready for
constructing the page directories is assumed to be protected by the
struct_mutex. However, we want to remove this global lock and so must
install a replacement global lock for accessing
> -Original Message-
> From: Nikula, Jani
> Sent: Wednesday, July 4, 2018 8:08 PM
> To: Chauhan, Madhav ; intel-
> g...@lists.freedesktop.org
> Cc: Vivi, Rodrigo ; Zanoni, Paulo R
> ; Shankar, Uma ;
> Chauhan, Madhav
> Subject: Re: [PATCH v2 05/20] drm/i915/icl: Define PORT_CL_DW_10 regist
Currently, the wc-stash used for providing flushed WC pages ready for
constructing the page directories is assumed to be protected by the
struct_mutex. However, we want to remove this global lock and so must
install a replacement global lock for accessing the global wc-stash (the
per-vm stash conti
On 04/07/2018 16:32, Chris Wilson wrote:
Currently, the wc-stash used for providing flushed WC pages ready for
constructing the page directories is assumed to be protected by the
struct_mutex. However, we want to remove this global lock and so must
install a replacement global lock for accessing
Hi,
The atomic API being super-explicit about how userspace sequences its
calls is great and all, but having shared global state implicitly
dragged in is kind of ruining my day.
Currently on Intel, Weston sometimes fails on hotplug, because a
commit which only enables CRTC B (not touching CRTC A o
== Series Details ==
Series: drm/i915/gtt: Pull global wc page stash under its own locking (rev3)
URL : https://patchwork.freedesktop.org/series/45909/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
6ed625b4dadd drm/i915/gtt: Pull global wc page stash under its own locking
-:290
== Series Details ==
Series: drm/i915/gtt: Pull global wc page stash under its own locking (rev3)
URL : https://patchwork.freedesktop.org/series/45909/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Commit: drm/i915/gtt: Pull global wc page stash under its own locking
-O:drivers/gpu
== Series Details ==
Series: drm/i915/gtt: Pull global wc page stash under its own locking (rev3)
URL : https://patchwork.freedesktop.org/series/45909/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4426 -> Patchwork_9525 =
== Summary - SUCCESS ==
No regressions found.
On 4 July 2018 at 13:34, Daniel Vetter wrote:
> On Wed, Jul 04, 2018 at 01:03:18PM +0100, Emil Velikov wrote:
>> Hi Daniel,
>>
>> On 4 July 2018 at 10:29, Daniel Vetter wrote:
>> > dma_fence_default_wait is the default now, same for the trivial
>> > enable_signaling implementation.
>> >
>> > v2:
Currently, the wc-stash used for providing flushed WC pages ready for
constructing the page directories is assumed to be protected by the
struct_mutex. However, we want to remove this global lock and so must
install a replacement global lock for accessing the global wc-stash (the
per-vm stash conti
== Series Details ==
Series: drm/i915/gtt: Pull global wc page stash under its own locking (rev4)
URL : https://patchwork.freedesktop.org/series/45909/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
00ed7b01f9ff drm/i915/gtt: Pull global wc page stash under its own locking
-:413
== Series Details ==
Series: drm/i915/gtt: Pull global wc page stash under its own locking (rev4)
URL : https://patchwork.freedesktop.org/series/45909/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Commit: drm/i915/gtt: Pull global wc page stash under its own locking
-O:drivers/gpu
== Series Details ==
Series: drm/i915/gtt: Pull global wc page stash under its own locking (rev4)
URL : https://patchwork.freedesktop.org/series/45909/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4426 -> Patchwork_9526 =
== Summary - SUCCESS ==
No regressions found.
Currently, the wc-stash used for providing flushed WC pages ready for
constructing the page directories is assumed to be protected by the
struct_mutex. However, we want to remove this global lock and so must
install a replacement global lock for accessing the global wc-stash (the
per-vm stash conti
From: Ville Syrjälä
gen8/9 has some compile time asserts to verify the SAMPLER_OFFSET() bits
don't exceed their quota of the flags. Add similar asserts for gen6/7.
Signed-off-by: Ville Syrjälä
---
src/sna/gen6_render.c | 1 +
src/sna/gen7_render.c | 1 +
2 files changed, 2 insertions(+)
diff
From: Ville Syrjälä
Rename the current yuv->rgb shaders in anticipation of variants that
will deal with full range yuv data.
Signed-off-by: Ville Syrjälä
---
src/render_program/Makefile.am | 44 ++--
src/render_program/exa_wm_yuv_rgb_bt601.g5a| 1 -
From: Ville Syrjälä
Add a new Xv port attribute XV_COLOR_RANGE to select the incoming YUV
quantization range. 0 means limited range (Y: 16-235, Cb/Cr: 16-240),
1 means full range (0-255).
Cc: xorg-de...@lists.x.org
Signed-off-by: Ville Syrjälä
---
src/sna/sna_video_textured.c | 12 +++-
From: Ville Syrjälä
Add new yuv->rgb shader variants that deal with full range yuv data
instead of limited range data. Until we expose the full range capability
via an Xv port attribute we'll always pick the limited range variant.
Signed-off-by: Ville Syrjälä
---
src/render_program/Makefile.am
From: Ville Syrjälä
With the extra video kernels we already ran out of bits in
the flags. To tackle that let's just split out the
wm_kernel to its own thing.
Fixes: e4f2b5d5af95 ("sna/video: Add XV_COLORSPACE attribute for the textured
Xv adaptor")
Signed-off-by: Ville Syrjälä
---
src/sna/gen
From: Ville Syrjälä
Add a new Xv port attribute XV_COLOR_RANGE to select the incoming YUV
quantization range. 0 means limited range (Y: 16-235, Cb/Cr: 16-240),
1 means full range (0-255).
We'll forward the quantization range information to the kernel via
the COLOR_RANGE kms property.
Cc: xorg-d
Quoting Ville Syrjala (2018-07-04 19:59:15)
> From: Ville Syrjälä
>
> With the extra video kernels we already ran out of bits in
> the flags. To tackle that let's just split out the
> wm_kernel to its own thing.
Does make one wish we had used push constants or loading them from a
constant surfac
== Series Details ==
Series: drm/i915/gtt: Pull global wc page stash under its own locking (rev5)
URL : https://patchwork.freedesktop.org/series/45909/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
4713fba8cdad drm/i915/gtt: Pull global wc page stash under its own locking
-:413
== Series Details ==
Series: drm/i915/gtt: Pull global wc page stash under its own locking (rev5)
URL : https://patchwork.freedesktop.org/series/45909/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Commit: drm/i915/gtt: Pull global wc page stash under its own locking
-O:drivers/gpu
1 - 100 of 127 matches
Mail list logo
