== Series Details ==
Series: Revert "drm/i915/edp: Allow alternate fixed mode for eDP if available."
URL : https://patchwork.freedesktop.org/series/43239/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4202 -> Patchwork_9041 =
== Summary - SUCCESS ==
No regressions found.
Quoting Chris Wilson (2018-05-17 16:47:26)
> Inside the live_hangcheck (reset) selftests, we occasionally see
> failures like
>
> <7>[ 239.094840] i915_gem_set_wedged rcs0
> <7>[ 239.094843] i915_gem_set_wedged current seqno 19a98, last 19a9a,
> hangcheck 0 [5158 ms]
> <7>[ 239.094846] i915_
On 18/05/2018 04:21, Zhenyu Wang wrote:
On 2018.05.17 22:26:32 +0100, Chris Wilson wrote:
To ease the frequent and ugly pointer dance of
&request->gem_context->engine[request->engine->id] during request
submission, store that pointer as request->hw_context. One major
advantage that we will expl
Delay registering ourselves with the acpi lid notification mechansim
until we are registering the connectors after initialisation is
complete. This prevents a possibilty of trying to handle the lid
notification before we are ready with the danger of chasing
uninitialised function pointers.
BUG: u
On 17/05/2018 18:07, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-05-17 14:13:00)
On 17/05/2018 08:40, Chris Wilson wrote:
Back in commit 27af5eea54d1 ("drm/i915: Move execlists irq handler to a
bottom half"), we came to the conclusion that running our CSB processing
and ELSP submission f
== Series Details ==
Series: Revert "drm/i915/edp: Allow alternate fixed mode for eDP if available."
URL : https://patchwork.freedesktop.org/series/43239/
State : failure
== Summary ==
= CI Bug Log - changes from CI_DRM_4202_full -> Patchwork_9041_full =
== Summary - FAILURE ==
Serious unk
Quoting Tvrtko Ursulin (2018-05-18 09:06:03)
>
> On 17/05/2018 18:07, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2018-05-17 14:13:00)
> >>
> >> On 17/05/2018 08:40, Chris Wilson wrote:
> >>> Back in commit 27af5eea54d1 ("drm/i915: Move execlists irq handler to a
> >>> bottom half"), we came t
== Series Details ==
Series: drm/i915/lvds: Move acpi lid notification registration to registration
phase
URL : https://patchwork.freedesktop.org/series/43390/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4203 -> Patchwork_9042 =
== Summary - WARNING ==
Minor unknown c
Quoting Tvrtko Ursulin (2018-05-18 08:43:33)
>
> On 18/05/2018 04:21, Zhenyu Wang wrote:
> > On 2018.05.17 22:26:32 +0100, Chris Wilson wrote:
> >> To ease the frequent and ugly pointer dance of
> >> &request->gem_context->engine[request->engine->id] during request
> >> submission, store that poin
To be useful later, enable intel_engine_dump() to be called from irq
context (i.e. using saving and restoring irq start rather than assuming
we enter with irqs enabled).
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/intel_engine_cs.c | 11 +++
1 file c
We want to be able to reset the GPU from inside a timer callback
(hardirq context). One step requires us to copy the default context
state over to the guilty context, which means we need to plan in advance
to have that object accessible from within an atomic context. The atomic
context prevents us
In order to support engine reset from irq (timer) context, we need to be
able to re-initialise the breadcrumbs. So we need to promote the plain
spin_lock_irq to a safe spin_lock_irqsave.
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/intel_breadcrumbs.c | 5 +++
From: Vathsala Nagaraju
For psr block #9, the vbt description has moved to options [0-3] for
TP1,TP2,TP3 Wakeup time from decimal value without any change to vbt
structure. Since spec does not mention from which VBT version this
change was added to vbt.bsf file, we cannot depend on bdb->version
== Series Details ==
Series: series starting with [CI,1/3] drm/i915: Make intel_engine_dump irqsafe
URL : https://patchwork.freedesktop.org/series/43396/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
0bb804040e08 drm/i915: Make intel_engine_dump irqsafe
55bb946fc4b5 drm/i915/ex
On 17/05/2018 15:24, Chris Wilson wrote:
When testing reset, we wait for 1s on the main thread for the hang to
start. Meanwhile, we continue submitting requests on all the background
threads, and we may have more threads than cores and so potentially
starve the waiter from being woken within the
On Fri, 18 May 2018, vathsala nagaraju wrote:
> From: Vathsala Nagaraju
>
> For psr block #9, the vbt description has moved to options [0-3] for
> TP1,TP2,TP3 Wakeup time from decimal value without any change to vbt
> structure. Since spec does not mention from which VBT version this
> change wa
== Series Details ==
Series: series starting with [CI,1/3] drm/i915: Make intel_engine_dump irqsafe
URL : https://patchwork.freedesktop.org/series/43396/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4204 -> Patchwork_9043 =
== Summary - SUCCESS ==
No regressions found.
Support for Burst read in HW is added for HDCP2.2 compliance
requirement.
This patch enables the burst read for all the gmbus read of more than
511Bytes, on capable platforms.
v2:
Extra line is removed.
v3:
Macro is added for detecting the BURST_READ Support [Jani]
Runtime detection of the
On 17/05/2018 15:24, Chris Wilson wrote:
Inside the live_hangcheck (reset) selftests, we occasionally see
failures like
<7>[ 239.094840] i915_gem_set_wedged rcs0
<7>[ 239.094843] i915_gem_set_wedged current seqno 19a98, last 19a9a,
hangcheck 0 [5158 ms]
<7>[ 239.094846] i915_gem_set_wed
== Series Details ==
Series: drm/i915/psr: vbt change for psr (rev8)
URL : https://patchwork.freedesktop.org/series/41289/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
46adf06c3a05 drm/i915/psr: vbt change for psr
-:79: CHECK:SPACING: spaces preferred around that '<<' (ctx:VxV
As per the discussion at #intel-gfx IRC, I have submitted v5 with the
max burst read length fixed to 767Bytes. Gist of the discussion: As per
HW spec HW supports burst for all the msg length above 511Bytes. But for
512 there is a special handling. Reasoning for this special handling is
not clea
Quoting Tvrtko Ursulin (2018-05-18 10:33:44)
>
> On 17/05/2018 15:24, Chris Wilson wrote:
> > Inside the live_hangcheck (reset) selftests, we occasionally see
> > failures like
> >
> > <7>[ 239.094840] i915_gem_set_wedged rcs0
> > <7>[ 239.094843] i915_gem_set_wedged current seqno 19a98
On Thu, 17 May 2018, John Sledge wrote:
> I’ve been doing some PTN3460 programming under Linux using C/C++ and I
> have some questions regarding on setting the brightness level to my
> display device.
>
> The display device with PTN3460 is connected in DP (display port) to
> my computer. Only need
== Series Details ==
Series: drm/i915/psr: vbt change for psr (rev8)
URL : https://patchwork.freedesktop.org/series/41289/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4204 -> Patchwork_9044 =
== Summary - SUCCESS ==
No regressions found.
External URL:
https://patch
On 18/05/2018 10:47, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-05-18 10:33:44)
On 17/05/2018 15:24, Chris Wilson wrote:
Inside the live_hangcheck (reset) selftests, we occasionally see
failures like
<7>[ 239.094840] i915_gem_set_wedged rcs0
<7>[ 239.094843] i915_gem_set_wedged
== Series Details ==
Series: GMBUS changes (rev5)
URL : https://patchwork.freedesktop.org/series/41632/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
cc8aaf86e7e8 drm/i915/gmbus: Increase the Bytes per Rd/Wr Op
f91237f2fdac drm/i915/gmbus: Enable burst read
-:36: CHECK:MACRO_AR
On Fri, 18 May 2018, Chris Wilson wrote:
> Delay registering ourselves with the acpi lid notification mechansim
> until we are registering the connectors after initialisation is
> complete. This prevents a possibilty of trying to handle the lid
> notification before we are ready with the danger of
Quoting Chris Wilson (2018-05-13 10:50:07)
> As we keep an rbtree of available holes sorted by their size, we can
> very easily determine if there is any hole large enough that might
> satisfy the allocation request. This helps when dealing with a highly
> fragmented address space and a request for
== Series Details ==
Series: GMBUS changes (rev5)
URL : https://patchwork.freedesktop.org/series/41632/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Commit: drm/i915/gmbus: Increase the Bytes per Rd/Wr Op
-O:drivers/gpu/drm/i915/intel_i2c.c:403:23: warning: expression using
sizeo
Planes with an odd width will appear to have an incorrect
stride. When the start position is odd the controller
can lock up.
Signed-off-by: Fritz Koenig
---
Hi,
This appears to be a limitation of the hardware that is not being
checked. Is this supported and am I not enabling it correctly?
dr
On 18/05/2018 10:47, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-05-18 10:33:44)
On 17/05/2018 15:24, Chris Wilson wrote:
Inside the live_hangcheck (reset) selftests, we occasionally see
failures like
<7>[ 239.094840] i915_gem_set_wedged rcs0
<7>[ 239.094843] i915_gem_set_wedged
Quoting Chris Wilson (2018-05-13 10:50:08)
> Searching for an available hole by address is slow, as there no
> guarantee that a hole will be available and so we must walk over all
> nodes in the rbtree before we determine the search was futile. In many
> cases, the caller doesn't strictly care for
Quoting Chris Wilson (2018-05-13 10:50:09)
> To no surprise (since we've flip-flopped over the use of PIN_HIGH a few
> times), doing a search by address over a pathologically fragmented
> address space is exceeding slow. To protect ourselves from nearly
> unbounded latency (think searching a millio
Quoting Chris Wilson (2018-05-13 10:50:10)
> If we can use an unmappable ring, try to pin it out of the mappable
> aperture. This simple layout preference is to try and keep the mappable
> aperture reserved and available to handle GGTT mmapping requests from
> userspace without causing evictions an
Quoting Joonas Lahtinen (2018-05-18 11:05:36)
> Quoting Chris Wilson (2018-05-13 10:50:09)
> > To no surprise (since we've flip-flopped over the use of PIN_HIGH a few
> > times), doing a search by address over a pathologically fragmented
> > address space is exceeding slow. To protect ourselves fro
Inside the live_hangcheck (reset) selftests, we occasionally see
failures like
<7>[ 239.094840] i915_gem_set_wedged rcs0
<7>[ 239.094843] i915_gem_set_wedged current seqno 19a98, last 19a9a,
hangcheck 0 [5158 ms]
<7>[ 239.094846] i915_gem_set_wedged Reset count: 6239 (global 1)
<7>[ 239.0
== Series Details ==
Series: GMBUS changes (rev5)
URL : https://patchwork.freedesktop.org/series/41632/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4204 -> Patchwork_9045 =
== Summary - WARNING ==
Minor unknown changes coming with Patchwork_9045 need to be verified
m
On 2018.05.18 09:42:47 +0100, Chris Wilson wrote:
> Quoting Tvrtko Ursulin (2018-05-18 08:43:33)
> >
> > On 18/05/2018 04:21, Zhenyu Wang wrote:
> > > On 2018.05.17 22:26:32 +0100, Chris Wilson wrote:
> > >> To ease the frequent and ugly pointer dance of
> > >> &request->gem_context->engine[reques
When we do shadowing, workload's request might not be allocated yet,
so we still require shadow context's object. And when complete workload,
delay to zero workload's request pointer after used for update guest context.
Fixes: 1fc44d9b1afb ("drm/i915: Store a pointer to intel_context in
i915_requ
Quoting Jani Nikula (2018-05-18 10:59:02)
> On Fri, 18 May 2018, Chris Wilson wrote:
> > Delay registering ourselves with the acpi lid notification mechansim
> > until we are registering the connectors after initialisation is
> > complete. This prevents a possibilty of trying to handle the lid
> >
Quoting Zhenyu Wang (2018-05-18 11:13:05)
> When we do shadowing, workload's request might not be allocated yet,
> so we still require shadow context's object. And when complete workload,
> delay to zero workload's request pointer after used for update guest context.
Please allocate the context ea
== Series Details ==
Series: drm/i915/lvds: Move acpi lid notification registration to registration
phase
URL : https://patchwork.freedesktop.org/series/43390/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4203_full -> Patchwork_9042_full =
== Summary - WARNING ==
Minor
== Series Details ==
Series: drm/i915: Reject NV12 planes with odd width/start position
URL : https://patchwork.freedesktop.org/series/43403/
State : failure
== Summary ==
Applying: drm/i915: Reject NV12 planes with odd width/start position
error: Failed to merge in the changes.
Using index in
Quoting Chris Wilson (2018-05-18 13:07:16)
> Quoting Joonas Lahtinen (2018-05-18 11:05:36)
> > Quoting Chris Wilson (2018-05-13 10:50:09)
> > > To no surprise (since we've flip-flopped over the use of PIN_HIGH a few
> > > times), doing a search by address over a pathologically fragmented
> > > addr
== Series Details ==
Series: drm/i915: Flush the ring stop bit after clearing RING_HEAD in reset
URL : https://patchwork.freedesktop.org/series/43404/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
e01c159ce05b drm/i915: Flush the ring stop bit after clearing RING_HEAD in reset
== Series Details ==
Series: drm/i915/gvt: Fix crash after request->hw_context change
URL : https://patchwork.freedesktop.org/series/43406/
State : failure
== Summary ==
Applying: drm/i915/gvt: Fix crash after request->hw_context change
error: sha1 information is lacking or useless
(drivers/g
== Series Details ==
Series: drm/i915: Flush the ring stop bit after clearing RING_HEAD in reset
URL : https://patchwork.freedesktop.org/series/43404/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4205 -> Patchwork_9047 =
== Summary - WARNING ==
Minor unknown changes com
Quoting Patchwork (2018-05-18 11:55:01)
> == Series Details ==
>
> Series: drm/i915/gvt: Fix crash after request->hw_context change
> URL : https://patchwork.freedesktop.org/series/43406/
> State : failure
>
> == Summary ==
>
> Applying: drm/i915/gvt: Fix crash after request->hw_context change
On 18/05/2018 11:09, Chris Wilson wrote:
Inside the live_hangcheck (reset) selftests, we occasionally see
failures like
<7>[ 239.094840] i915_gem_set_wedged rcs0
<7>[ 239.094843] i915_gem_set_wedged current seqno 19a98, last 19a9a,
hangcheck 0 [5158 ms]
<7>[ 239.094846] i915_gem_set_wed
Quoting Tvrtko Ursulin (2018-05-18 12:05:17)
>
> On 18/05/2018 11:09, Chris Wilson wrote:
> > Inside the live_hangcheck (reset) selftests, we occasionally see
> > failures like
> >
> > <7>[ 239.094840] i915_gem_set_wedged rcs0
> > <7>[ 239.094843] i915_gem_set_wedged current seqno 19a98
On 17 May 2018 at 07:03, Chris Wilson wrote:
> Currently the purgeable objects, I915_MADV_DONTNEED, as mixed in the
> normal bound/unbound lists. Every shrinker pass starts with an attempt
> to purge from this set of unneeded objects, which entails us doing a
> walk over both lists looking for any
== Series Details ==
Series: series starting with [CI,1/3] drm/i915: Make intel_engine_dump irqsafe
URL : https://patchwork.freedesktop.org/series/43396/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4204_full -> Patchwork_9043_full =
== Summary - WARNING ==
Minor unknow
On 18/05/2018 12:10, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-05-18 12:05:17)
On 18/05/2018 11:09, Chris Wilson wrote:
Inside the live_hangcheck (reset) selftests, we occasionally see
failures like
<7>[ 239.094840] i915_gem_set_wedged rcs0
<7>[ 239.094843] i915_gem_set_wedged
Quoting Matthew Auld (2018-05-18 12:36:30)
> On 17 May 2018 at 07:03, Chris Wilson wrote:
> > diff --git a/drivers/gpu/drm/i915/i915_vma.c
> > b/drivers/gpu/drm/i915/i915_vma.c
> > index 9324d476e0a7..96039c4ef434 100644
> > --- a/drivers/gpu/drm/i915/i915_vma.c
> > +++ b/drivers/gpu/drm/i915/i91
>-Original Message-
>From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
>Ramalingam C
>Sent: Tuesday, April 3, 2018 7:28 PM
>To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
>seanp...@chromium.org; dan...@ffwll.ch; ch...@chris-wilson.co.uk;
On Wed, 16 May 2018, Lucas De Marchi wrote:
> This reverts commit c0cfb10d9e1de490e36d3b9d4228c0ea0ca30677.
>
> This fails on a Dell XPS13 9350 machine giving me just a black screen.
> [drm:intel_dp_start_link_train [i915]] [CONNECTOR:59:eDP-1] Link Training
> Passed at Link Rate = 54, Lane
On Thu, May 17, 2018 at 12:07:14PM -0700, Fritz Koenig wrote:
> Planes with an odd width will appear to have an incorrect
> stride. When the start position is odd the controller
> can lock up.
Just remove the strange NV12 check from the %2 checks in
intel_check_sprite_plane()?
>
> Signed-off-by:
Quoting Tvrtko Ursulin (2018-05-18 12:50:41)
>
> On 18/05/2018 12:10, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2018-05-18 12:05:17)
> >>
> >> On 18/05/2018 11:09, Chris Wilson wrote:
> >>> Inside the live_hangcheck (reset) selftests, we occasionally see
> >>> failures like
> >>>
> >>> <7>[
== Series Details ==
Series: Revert "drm/i915/edp: Do not do link training fallback or prune modes
on EDP" (rev2)
URL : https://patchwork.freedesktop.org/series/43278/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
4217d2e38954 Revert "drm/i915/edp: Do not do link training fall
== Series Details ==
Series: drm/i915/psr: vbt change for psr (rev8)
URL : https://patchwork.freedesktop.org/series/41289/
State : failure
== Summary ==
= CI Bug Log - changes from CI_DRM_4204_full -> Patchwork_9044_full =
== Summary - FAILURE ==
Serious unknown changes coming with Patchwo
>-Original Message-
>From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
>Ramalingam C
>Sent: Tuesday, April 3, 2018 7:28 PM
>To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
>seanp...@chromium.org; dan...@ffwll.ch; ch...@chris-wilson.co.uk;
On 18/05/2018 13:28, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-05-18 12:50:41)
On 18/05/2018 12:10, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-05-18 12:05:17)
On 18/05/2018 11:09, Chris Wilson wrote:
Inside the live_hangcheck (reset) selftests, we occasionally see
failures lik
>-Original Message-
>From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
>Ramalingam C
>Sent: Tuesday, April 3, 2018 7:28 PM
>To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
>seanp...@chromium.org; dan...@ffwll.ch; ch...@chris-wilson.co.uk;
>-Original Message-
>From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
>Ramalingam C
>Sent: Tuesday, April 3, 2018 7:28 PM
>To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
>seanp...@chromium.org; dan...@ffwll.ch; ch...@chris-wilson.co.uk;
== Series Details ==
Series: Revert "drm/i915/edp: Do not do link training fallback or prune modes
on EDP" (rev2)
URL : https://patchwork.freedesktop.org/series/43278/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4206 -> Patchwork_9049 =
== Summary - WARNING ==
Minor u
>-Original Message-
>From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
>Ramalingam C
>Sent: Tuesday, April 3, 2018 7:28 PM
>To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
>seanp...@chromium.org; dan...@ffwll.ch; ch...@chris-wilson.co.uk;
>-Original Message-
>From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
>Ramalingam C
>Sent: Tuesday, April 3, 2018 7:28 PM
>To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
>seanp...@chromium.org; dan...@ffwll.ch; ch...@chris-wilson.co.uk;
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
The EC can expose a CEC bus, this patch adds the CEC related definitions
needed by the cros-ec-cec driver.
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-
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
The Chrome OS 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, thus add the cros-ec-cec MFD sub-device
when the CEC feature bit is present.
Signed-off-by: Neil Armstrong
---
drivers/mfd/cros_ec_dev.c | 16
1 file changed, 16 insertions(+)
diff --git a/drivers/mfd/cros_ec_dev.c b/drivers/mfd/cros_ec_dev.c
index
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
== Series Details ==
Series: Add ChromeOS EC CEC Support (rev4)
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
Applying: mfd: c
== Series Details ==
Series: GMBUS changes (rev5)
URL : https://patchwork.freedesktop.org/series/41632/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4204_full -> Patchwork_9045_full =
== Summary - WARNING ==
Minor unknown changes coming with Patchwork_9045_full need to
On Fri, May 18, 2018 at 03:05:01PM +0200, Neil Armstrong wrote:
> 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
On 17 May 2018 at 07:03, Chris Wilson wrote:
> As i915_gem_object_phys_attach() wants to play dirty and mess around
> with obj->mm.pages itself (replacing the shmemfs with a DMA allocation),
> refactor the gubbins so into i915_gem_object_unset_pages() that we don't
> have to duplicate all the secr
2018-05-18 15:05 GMT+02:00 Neil Armstrong :
> 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
> ---
> drivers/mfd/cros_ec_dev.c | 16
> 1 file changed, 16 insertions(+)
>
> diff --git a/
We already have a macro to pull the GEM object from a FB, so use it
everywhere. We'll make use of this later to move the object storage.
Signed-off-by: Daniel Stone
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
Cc: Ville Syrjälä
Cc: intel-gfx@lists.freedesktop.org
---
drivers/gpu/drm/
Since drm_framebuffer can now store GEM objects directly, place them
there rather than in our own subclass.
v2: Only hold a single reference per framebuffer, not per plane. (Ville)
Signed-off-by: Daniel Stone
Cc: Ville Syrjälä
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
Cc: intel-gf
== Series Details ==
Series: series starting with [v2,1/2] drm/i915: Use intel_fb_obj() everywhere
URL : https://patchwork.freedesktop.org/series/43418/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
a498ec6deeb8 drm/i915: Use intel_fb_obj() everywhere
a7a2fce7f362 drm/i915: Mov
== Series Details ==
Series: series starting with [v2,1/2] drm/i915: Use intel_fb_obj() everywhere
URL : https://patchwork.freedesktop.org/series/43418/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Commit: drm/i915: Use intel_fb_obj() everywhere
-O:drivers/gpu/drm/i915/intel_displ
Hi Neil,
2018-05-18 15:04 GMT+02:00 Neil Armstrong :
> 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, th
== Series Details ==
Series: series starting with [v2,1/2] drm/i915: Use intel_fb_obj() everywhere
URL : https://patchwork.freedesktop.org/series/43418/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4206 -> Patchwork_9051 =
== Summary - SUCCESS ==
No regressions found.
On Fri, May 18, 2018 at 02:48:44PM +0100, Daniel Stone wrote:
> Since drm_framebuffer can now store GEM objects directly, place them
> there rather than in our own subclass.
>
> v2: Only hold a single reference per framebuffer, not per plane. (Ville)
>
> Signed-off-by: Daniel Stone
> Cc: Ville S
Quoting Tvrtko Ursulin (2018-05-18 13:36:52)
>
> On 18/05/2018 13:28, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2018-05-18 12:50:41)
> >>
> >> On 18/05/2018 12:10, Chris Wilson wrote:
> >>> Quoting Tvrtko Ursulin (2018-05-18 12:05:17)
>
> On 18/05/2018 11:09, Chris Wilson wrote:
>
On Fri, May 18, 2018 at 03:25:26PM +0300, Ville Syrjälä wrote:
> On Thu, May 17, 2018 at 12:07:14PM -0700, Fritz Koenig wrote:
> > Planes with an odd width will appear to have an incorrect
> > stride. When the start position is odd the controller
> > can lock up.
>
> Just remove the strange NV12 c
Quoting Fritz Koenig (2018-05-17 20:07:14)
> Planes with an odd width will appear to have an incorrect
> stride. When the start position is odd the controller
> can lock up.
>
> Signed-off-by: Fritz Koenig
> ---
>
> Hi,
>
> This appears to be a limitation of the hardware that is not being
> che
On Gen8+ this register is not priviledged and we want to use it in
Mesa to implement a feature required by GPA called Null Hardware. The
idea is to have the command parser turn 3DPRIMITIVE/GPGPU_WALKER into
NOOPs.
This patch just whitelists the bits that we need and that are
currently not used by
On Thu, May 17, 2018 at 08:49:27PM +0300, Jani Nikula wrote:
> On Thu, 17 May 2018, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > i965 does not have native DP. Let's rename the remaining gen4 references
> > in the DP code to g4x.
> >
> > Signed-off-by: Ville Syrjälä
>
> Reviewed-by: Jani
On Fri, Mar 09, 2018 at 11:22:04PM +0100, Ondrej Zary wrote:
> Radiant P845 does not have LVDS, only VGA.
>
> Signed-off-by: Ondrej Zary
Since we failed with the VBT approach I've gone and pushed this
as is to dinq (with cc:stable and the bugzilla link added).
Thanks for the patch.
> ---
> dr
On 18/05/18 15:26, Lionel Landwerlin wrote:
On Gen8+ this register is not priviledged and we want to use it in
Mesa to implement a feature required by GPA called Null Hardware. The
idea is to have the command parser turn 3DPRIMITIVE/GPGPU_WALKER into
NOOPs.
This patch just whitelists the bits th
We already have a macro to pull the GEM object from a FB, so use it
everywhere. We'll make use of this later to move the object storage.
Signed-off-by: Daniel Stone
Reviewed-by: Ville Syrjälä
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
Cc: intel-gfx@lists.freedesktop.org
---
drivers
Since drm_framebuffer can now store GEM objects directly, place them
there rather than in our own subclass.
v2: Only hold a single reference per framebuffer, not per plane. (Ville)
v3: Drop NULL check in intel_fb_obj. (Ville)
Signed-off-by: Daniel Stone
Reviewed-by: Ville Syrjälä
Cc: Jani Nikul
Quoting Lionel Landwerlin (2018-05-18 15:29:21)
> On 18/05/18 15:26, Lionel Landwerlin wrote:
> > On Gen8+ this register is not priviledged and we want to use it in
> > Mesa to implement a feature required by GPA called Null Hardware. The
> > idea is to have the command parser turn 3DPRIMITIVE/GPGP
On 18/05/2018 15:13, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-05-18 13:36:52)
On 18/05/2018 13:28, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-05-18 12:50:41)
On 18/05/2018 12:10, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-05-18 12:05:17)
On 18/05/2018 11:09, Chris Wil
== Series Details ==
Series: drm/i915: Flush the ring stop bit after clearing RING_HEAD in reset
URL : https://patchwork.freedesktop.org/series/43404/
State : failure
== Summary ==
= CI Bug Log - changes from CI_DRM_4205_full -> Patchwork_9047_full =
== Summary - FAILURE ==
Serious unknown
== Series Details ==
Series: drm/i915/cmdparser: Whitelist INSTPM instruction parsing disable bits
URL : https://patchwork.freedesktop.org/series/43420/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
2fac9bc00108 drm/i915/cmdparser: Whitelist INSTPM instruction parsing disable
From: Ville Syrjälä
VBT seems to have some bits to tell us whether the internal LVDS port
has something hooked up. In theory one might expect the VBT to not have
a child device for the LVDS port if there's no panel hooked up, but
in practice many VBTs still add the child device. The "LVDS config"
Hi Neil,
2018-05-18 15:05 GMT+02:00 Neil Armstrong :
> The Chrome OS Embedded Controller can expose a CEC bus, this patch add the
A minor nit, there is a "consensus" on tell cros-ec as "ChromeOS
Embedded Controller" or "ChromeOS EC". Yes, I know that you can see in
the kernel many other ways to r
1 - 100 of 172 matches
Mail list logo
