== Series Details ==
Series: Add gamma/degamma LUT validation helper
URL : https://patchwork.freedesktop.org/series/54023/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5315_full -> Patchwork_11092_full
Summary
---
== Series Details ==
Series: MST refcounting/atomic helpers cleanup
URL : https://patchwork.freedesktop.org/series/54030/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5316 -> Patchwork_11093
Summary
---
**FAILURE**
== Series Details ==
Series: MST refcounting/atomic helpers cleanup
URL : https://patchwork.freedesktop.org/series/54030/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/dp_mst: Remove bogus conditional in drm_dp_update_payload_part1()
Okay!
== Series Details ==
Series: MST refcounting/atomic helpers cleanup
URL : https://patchwork.freedesktop.org/series/54030/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
69cf74524440 drm/dp_mst: Remove bogus conditional in
drm_dp_update_payload_part1()
6b4005731a4b drm/dp_mst:
Currently, nouveau uses the yolo method of setting up MST displays: it
uses the old VCPI helpers (drm_dp_find_vcpi_slots()) for computing the
display configuration. These helpers don't take care to make sure they
take a reference to the mstb port that they're checking, and
additionally don't
Same as we did for i915, but for nouveau this time. Additionally, we
grab a malloc reference to the port that lasts for the entire lifetime
of nv50_mstc, which gives us the guarantee that mstc->port will always
point to valid memory for as long as the mstc stays around.
Signed-off-by: Lyude Paul
Changes since v6:
- Move EXPORT_SYMBOL() for drm_dp_mst_topology_state_funcs to this
commit
- Document __drm_dp_mst_state_iter_get() and note that it shouldn't be
called directly
Signed-off-by: Lyude Paul
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/drm_dp_mst_topology.c | 5 +-
Now that we finally have a sane way to keep port allocations around, use
it to fix the potential unchecked ->port accesses that nouveau makes by
making sure we keep the mst port allocated for as long as it's
drm_connector is accessible.
Additionally, now that we've guaranteed that mstc->port is
This has never actually worked, and isn't needed anyway: the driver's
always going to try to deallocate VCPI when it tears down the display
that the VCPI belongs to.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/drm_dp_mst_topology.c | 8
1 file changed, 8 deletions(-)
diff --git
Up until now, freeing payloads on remote MST hubs that just had ports
removed has almost never worked because we've been relying on port
validation in order to stop us from accessing ports that have already
been freed from memory, but ports which need their payloads released due
to being removed
Going through the currently programmed payloads isn't safe without
holding mgr->payload_lock, so actually do that and warn if anyone tries
calling nv50_msto_payload() in the future without grabbing the right
locks.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/nouveau/dispnv50/disp.c | 6 ++
It occurred to me that we never actually check this! So let's start
doing that.
Signed-off-by: Lyude Paul
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/drm_dp_mst_topology.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
There has been a TODO waiting for quite a long time in
drm_dp_mst_topology.c:
/* We cannot rely on port->vcpi.num_slots to update
* topology_state->avail_slots as the port may not exist if the parent
* branch device was unplugged. This should be fixed by tracking
This is a WIP version of the series I've been working on for a while now
to get all of the atomic DRM drivers in the tree to use the atomic MST
helpers, and to make the atomic MST helpers actually idempotent. Turns
out it's a lot more difficult to do that without also fixing how port
and branch
The current way of handling refcounting in the DP MST helpers is really
confusing and probably just plain wrong because it's been hacked up many
times over the years without anyone actually going over the code and
seeing if things could be simplified.
To the best of my understanding, the current
So that the ports stay around until we've destroyed the connectors, in
order to ensure that we don't pass an invalid pointer to any MST helpers
once we introduce the new MST VCPI helpers.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/i915/intel_connector.c | 4
Trying to destroy the connector using mstc->connector.funcs->destroy()
if connector initialization fails is wrong: there is no possible
codepath in nv50_mstc_new where nv50_mstm_add_connector() would return
<0 and mstc would be non-NULL.
Signed-off-by: Lyude Paul
---
There's no reason we need this, it's just confusing looking.
Signed-off-by: Lyude Paul
Cc: Juston Li
---
drivers/gpu/drm/drm_dp_mst_topology.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_topology.c
There is no need to look at the port's VCPI allocation before calling
drm_dp_mst_deallocate_vcpi(), as we already have msto->disabled to let
us avoid cleaning up an msto more then once. The DP MST core will never
call drm_dp_mst_deallocate_vcpi() on it's own, which is presumably what
these checks
There should be no functional changes here
Signed-off-by: Lyude Paul
Cc: Juston Li
---
drivers/gpu/drm/drm_dp_mst_topology.c | 71 ---
1 file changed, 42 insertions(+), 29 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
On Thu, Dec 13, 2018 at 01:06:51PM -0800, Rodrigo Vivi wrote:
> On Thu, Dec 13, 2018 at 09:48:49PM +0200, Imre Deak wrote:
> > Atm HPD disconnect events on TypeC ports will break things, since we'll
> > switch the TypeC mode (between Legacy and disconnected modes as well as
> > among USB DP
On Thu, 2018-12-13 at 07:18 +0200, Ville Syrjälä wrote:
> On Wed, Dec 12, 2018 at 04:32:02PM -0800, Dhinakaran Pandiyan wrote:
> > On Tue, 2018-11-20 at 18:13 +0200, Ville Syrjala wrote:
> > > From: Ville Syrjälä
> > >
> > > Fill out the AVI infoframe quantization range bits using
> > >
== Series Details ==
Series: Add gamma/degamma LUT validation helper
URL : https://patchwork.freedesktop.org/series/54023/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5315 -> Patchwork_11092
Summary
---
== Series Details ==
Series: Add gamma/degamma LUT validation helper
URL : https://patchwork.freedesktop.org/series/54023/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
e8602a936ce9 drm: Add color management LUT validation helper (v2)
-:57: CHECK:PARENTHESIS_ALIGNMENT:
Some hardware may place additional restrictions on the gamma/degamma
curves described by our LUT properties. E.g., that a gamma curve never
decreases or that the red/green/blue channels of a LUT's entries must be
equal. Let's add a helper function that drivers can use to test that a
We currently program userspace-provided gamma and degamma LUT's into our
hardware without really checking to see whether they satisfy our
hardware's rules. We should try to catch tables that are invalid for
our hardware early and reject the atomic transaction.
All of our platforms that accept a
Previous version of this series was here:
https://lists.freedesktop.org/archives/dri-devel/2018-December/200178.html
Gamma and degamma LUT's uploaded by userspace need to be checked to
ensure they're valid tables and that they meet any additional
constraints of a given platform's hardware.
On Thu, Dec 13, 2018 at 09:48:50PM +0200, Imre Deak wrote:
> TypeC legacy DP ports can't be implied the same way we implied TypeC
> legacy HDMI ports in the previous patch. So that we still have
> functioning DP legacy ports, mark them as legacy at the first connect
> event. After that we treat
On Thu, Dec 13, 2018 at 09:48:49PM +0200, Imre Deak wrote:
> Atm HPD disconnect events on TypeC ports will break things, since we'll
> switch the TypeC mode (between Legacy and disconnected modes as well as
> among USB DP alternate, Thunderbolt alternate and disconnected modes) on
> the fly from
On Thu, Dec 13, 2018 at 09:48:48PM +0200, Imre Deak wrote:
> It's useful to see at which point a TypeC port gets disconnected, so add
> add a debug print for it.
>
> Cc: Paulo Zanoni
> Cc: Ville Syrjälä
> Cc: José Roberto de Souza
> Cc: Rodrigo Vivi
> Signed-off-by: Imre Deak
Reviewed-by:
== Series Details ==
Series: drm/i915/icl: Fix TypeC legacy HPD handling
URL : https://patchwork.freedesktop.org/series/54017/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5313 -> Patchwork_11091
Summary
---
== Series Details ==
Series: drm/i915/icl: Fix TypeC legacy HPD handling
URL : https://patchwork.freedesktop.org/series/54017/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
865ff59f3e7d drm/i915/icl: Add a debug print for TypeC port disconnection
-:28:
TypeC legacy DP ports can't be implied the same way we implied TypeC
legacy HDMI ports in the previous patch. So that we still have
functioning DP legacy ports, mark them as legacy at the first connect
event. After that we treat the port the same way as in the HDMI case,
that is keep it in legacy
Atm HPD disconnect events on TypeC ports will break things, since we'll
switch the TypeC mode (between Legacy and disconnected modes as well as
among USB DP alternate, Thunderbolt alternate and disconnected modes) on
the fly from the HPD disconnect interrupt work while the port may be
still
It's useful to see at which point a TypeC port gets disconnected, so add
add a debug print for it.
Cc: Paulo Zanoni
Cc: Ville Syrjälä
Cc: José Roberto de Souza
Cc: Rodrigo Vivi
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/intel_dp.c | 34 --
1 file
This patchset fixes the HPD handling for TypeC legacy ports. It depends
on an indirect detection method described in patch 2 and 3, which will
be replaced by a direct method once the BIOS/HW/FW team delivers a
promised SW/HW flag for this purpose.
There is no issue with the indirect method I know
On Thu, Dec 13, 2018 at 5:46 AM Joonas Lahtinen
wrote:
>
> Quoting Tvrtko Ursulin (2018-12-10 17:17:29)
> >
> > On 07/11/2018 15:16, Tomasz Lis wrote:
> > > The table has been unified across OSes to minimize virtualization
> > > overhead.
> > >
> > > The MOCS table is now published as part of
Hi Mika,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on next-20181213]
[cannot apply to v4.20-rc6]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https
Am 13.12.18 um 18:26 schrieb Daniel Vetter:
>>> Code sharing just because the code looks similar is imo a really
>>> bad idea, when the semantics are entirely different (that was also the
>>> reason behind not reusing all the cpu event stuff for dma_fence, they're
>>> not normal cpu events).
>>
== Series Details ==
Series: drm/i915: Apply missed interrupt after reset w/a to all ringbuffer gen
(rev6)
URL : https://patchwork.freedesktop.org/series/53979/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5311_full -> Patchwork_11087_full
On Tue, 2018-12-11 at 14:20 -0800, Dhinakaran Pandiyan wrote:
> On Tue, 2018-12-04 at 15:00 -0800, José Roberto de Souza wrote:
> > The value of this registers will be used to test if PSR2 is doing
> > selective update and if the number of blocks match with the
> > expected.
> >
> > Cc: Rodrigo
On Thu, Dec 13, 2018 at 5:27 PM Winkler, Tomas wrote:
>
> > On Thu, Dec 13, 2018 at 1:36 PM C, Ramalingam
> > wrote:
> > >
> > > Tomas and Daniel,
> > >
> > > We got an issue here.
> > >
> > > The relationship that we try to build between I915 and mei_hdcp is as
> > > follows:
> > >
> > > We
On Thu, Dec 13, 2018 at 5:47 PM Koenig, Christian
wrote:
>
> Am 13.12.18 um 17:01 schrieb Daniel Vetter:
> > On Thu, Dec 13, 2018 at 12:24:57PM +, Koenig, Christian wrote:
> >> Am 13.12.18 um 13:21 schrieb Chris Wilson:
> >>> Quoting Koenig, Christian (2018-12-13 12:11:10)
> Am 13.12.18
Am 13.12.18 um 17:01 schrieb Daniel Vetter:
> On Thu, Dec 13, 2018 at 12:24:57PM +, Koenig, Christian wrote:
>> Am 13.12.18 um 13:21 schrieb Chris Wilson:
>>> Quoting Koenig, Christian (2018-12-13 12:11:10)
Am 13.12.18 um 12:37 schrieb Chris Wilson:
> Quoting Chunming Zhou (2018-12-11
== Series Details ==
Series: drm/i915: Fix Cherryview oops on boot
URL : https://patchwork.freedesktop.org/series/54007/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5311 -> Patchwork_11090
Summary
---
**FAILURE**
> On Thu, Dec 13, 2018 at 1:36 PM C, Ramalingam
> wrote:
> >
> > Tomas and Daniel,
> >
> > We got an issue here.
> >
> > The relationship that we try to build between I915 and mei_hdcp is as
> > follows:
> >
> > We are using the components to establish the relationship.
> > I915 is component
Hi,
On 13-12-18 17:05, Patchwork wrote:
== Series Details ==
Series: series starting with [v4,1/3] ACPI / PMIC: Add support for executing
PMIC MIPI sequence elements
URL : https://patchwork.freedesktop.org/series/54003/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5311
== Series Details ==
Series: drm/i915: Fix Cherryview oops on boot
URL : https://patchwork.freedesktop.org/series/54007/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915: Fix Cherryview oops on boot
+drivers/gpu/drm/i915/intel_color.c:101:33:
== Series Details ==
Series: drm/i915: Fix Cherryview oops on boot
URL : https://patchwork.freedesktop.org/series/54007/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
efebc101c12c drm/i915: Fix Cherryview oops on boot
-:12: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped
On Thu, Dec 13, 2018 at 04:12:41PM +, Chris Wilson wrote:
> Do not dereference the LUT blob before checking whether that blob
> exists. Or else,
>
> <1>[ 13.978684] BUG: unable to handle kernel NULL pointer dereference at
> 0048
> <6>[ 13.978718] PGD 0 P4D 0
> <4>[
Do not dereference the LUT blob before checking whether that blob
exists. Or else,
<1>[ 13.978684] BUG: unable to handle kernel NULL pointer dereference at
0048
<6>[ 13.978718] PGD 0 P4D 0
<4>[ 13.978733] Oops: [#1] PREEMPT SMP PTI
<4>[ 13.978750] CPU: 0 PID: 282 Comm:
On Thu, Dec 13, 2018 at 1:36 PM C, Ramalingam wrote:
>
> Tomas and Daniel,
>
> We got an issue here.
>
> The relationship that we try to build between I915 and mei_hdcp is as follows:
>
> We are using the components to establish the relationship.
> I915 is component master where as mei_hdcp is
== Series Details ==
Series: series starting with [v4,1/3] ACPI / PMIC: Add support for executing
PMIC MIPI sequence elements
URL : https://patchwork.freedesktop.org/series/54003/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5311 -> Patchwork_11089
On Thu, Dec 13, 2018 at 12:24:57PM +, Koenig, Christian wrote:
> Am 13.12.18 um 13:21 schrieb Chris Wilson:
> > Quoting Koenig, Christian (2018-12-13 12:11:10)
> >> Am 13.12.18 um 12:37 schrieb Chris Wilson:
> >>> Quoting Chunming Zhou (2018-12-11 10:34:45)
> From: Christian König
>
Quoting Chris Wilson (2018-12-13 15:36:43)
> Quoting Antonio Argenziano (2018-12-13 15:28:00)
> >
> >
> > On 13/12/18 03:57, Chris Wilson wrote:
> > > amdgpu has started to report out of space after creating a few contexts.
> > > This is not the scope of this test as here we just verifying that
On Thu, Dec 13, 2018 at 6:57 AM Chris Wilson wrote:
>
> amdgpu has started to report out of space after creating a few contexts.
> This is not the scope of this test as here we just verifying that fences
> created in amd can be imported and used for synchronisation by i915 and
> for that we just
Quoting Antonio Argenziano (2018-12-13 15:28:00)
>
>
> On 13/12/18 03:57, Chris Wilson wrote:
> > amdgpu has started to report out of space after creating a few contexts.
> > This is not the scope of this test as here we just verifying that fences
> > created in amd can be imported and used for
Add support for PMIC MIPI sequences using the new
intel_soc_pmic_exec_mipi_pmic_seq_element function.
This fixes the DSI LCD panel not lighting up when not initialized by the
GOP (because an external monitor was connected) on GPD win and GPD pocket
devices.
Specifically the LCD panel seems to
DSI LCD panels describe an initialization sequence in the Video BIOS
Tables using so called MIPI sequences. One possible element in these
sequences is a PMIC specific element of 15 bytes.
Although this is not really an ACPI opregion, the ACPI opregion code is the
closest thing we have. We need to
Implement the exec_mipi_pmic_seq_element callback for the CHT Whiskey Cove
PMIC.
On some CHT devices this fixes the LCD panel not lighting up when it was
not initialized by the GOP, because an external monitor was plugged in and
the GOP initialized only the external monitor.
Signed-off-by: Hans
On 13/12/18 03:57, Chris Wilson wrote:
amdgpu has started to report out of space after creating a few contexts.
This is not the scope of this test as here we just verifying that fences
created in amd can be imported and used for synchronisation by i915 and
for that we just need at least one
Quoting Ville Syrjälä (2018-12-13 12:45:00)
> On Thu, Dec 13, 2018 at 12:34:02PM +, Chris Wilson wrote:
> > Quoting Ville Syrjälä (2018-12-13 12:29:15)
> > > On Thu, Dec 13, 2018 at 12:07:35PM +, Chris Wilson wrote:
> > > > Quoting Ville Syrjälä (2018-12-13 11:59:28)
> > > > > On Thu, Dec
== Series Details ==
Series: drm/i915/opregion: rvda is relative from opregion base, not absolute
URL : https://patchwork.freedesktop.org/series/53996/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5311 -> Patchwork_11088
On Wed, 2018-12-12 at 17:11 -0800, Dhinakaran Pandiyan wrote:
> On Wed, 2018-12-12 at 05:02 -0800, Souza, Jose wrote:
> > On Tue, 2018-12-11 at 14:02 -0800, Dhinakaran Pandiyan wrote:
> > > On Mon, 2018-11-12 at 11:17 +0100, Maarten Lankhorst wrote:
> > > > Op 09-11-18 om 21:20 schreef José
== Series Details ==
Series: drm/i915: Apply missed interrupt after reset w/a to all ringbuffer gen
(rev6)
URL : https://patchwork.freedesktop.org/series/53979/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5311 -> Patchwork_11087
Hi,
On 13-12-18 14:08, Ville Syrjälä wrote:
On Thu, Dec 13, 2018 at 01:40:27PM +0100, Hans de Goede wrote:
Hi,
On 13-12-18 13:14, Ville Syrjälä wrote:
+static int intel_cht_wc_exec_mipi_pmic_seq_element(struct regmap *regmap,
+ const u8
== Series Details ==
Series: series starting with [v3,1/3] ACPI / PMIC: Add support for executing
PMIC MIPI sequence elements
URL : https://patchwork.freedesktop.org/series/53986/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5311_full -> Patchwork_11085_full
HI,
On 13-12-18 14:45, Jani Nikula wrote:
On Thu, 13 Dec 2018, Hans de Goede wrote:
DSI LCD panels describe an initialization sequence in the Video BIOS
Tables using so called MIPI sequences. One possible element in these
sequences is a PMIC specific element of 15 bytes.
Although this is not
On Thu, 13 Dec 2018, Jani Nikula wrote:
> We've supported the opregion RVDA/RVDS fields for VBT size >= 6 KB since
> commit 04ebaadb9f2d ("drm/i915/opregion: handle VBT sizes bigger than 6
> KB"). That's three years, almost to the date.
>
> The implementation was based on spec only, in
On Thu, 13 Dec 2018, Hans de Goede wrote:
> Add support for PMIC MIPI sequences using the new
> intel_soc_pmic_exec_mipi_pmic_seq_element function.
>
> This fixes the DSI LCD panel not lighting up when not initialized by the
> GOP (because an external monitor was connected) on GPD win and GPD
We've supported the opregion RVDA/RVDS fields for VBT size >= 6 KB since
commit 04ebaadb9f2d ("drm/i915/opregion: handle VBT sizes bigger than 6
KB"). That's three years, almost to the date.
The implementation was based on spec only, in anticipation of systems
with big VBT. Now, the spec has been
Quoting Tvrtko Ursulin (2018-12-10 17:17:29)
>
> On 07/11/2018 15:16, Tomasz Lis wrote:
> > The table has been unified across OSes to minimize virtualization overhead.
> >
> > The MOCS table is now published as part of bspec, and versioned. Entries
> > are supposed to never be modified, but new
On Thu, 13 Dec 2018, Ville Syrjälä wrote:
> On Thu, Dec 13, 2018 at 01:40:27PM +0100, Hans de Goede wrote:
>> Hi,
>>
>> On 13-12-18 13:14, Ville Syrjälä wrote:
>> > On Thu, Dec 13, 2018 at 12:21:35PM +0100, Hans de Goede wrote:
>> >> Implement the exec_mipi_pmic_seq_element callback for the CHT
On Thu, 13 Dec 2018, Hans de Goede wrote:
> DSI LCD panels describe an initialization sequence in the Video BIOS
> Tables using so called MIPI sequences. One possible element in these
> sequences is a PMIC specific element of 15 bytes.
>
> Although this is not really an ACPI opregion, the ACPI
== Series Details ==
Series: drm/i915: Apply missed interrupt after reset w/a to all ringbuffer gen
(rev5)
URL : https://patchwork.freedesktop.org/series/53979/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5311 -> Patchwork_11086
On Thu, Dec 13, 2018 at 01:40:27PM +0100, Hans de Goede wrote:
> Hi,
>
> On 13-12-18 13:14, Ville Syrjälä wrote:
> > On Thu, Dec 13, 2018 at 12:21:35PM +0100, Hans de Goede wrote:
> >> Implement the exec_mipi_pmic_seq_element callback for the CHT Whiskey Cove
> >> PMIC.
> >>
> >> On some CHT
Having completed a test run of gem_eio across all machines in CI we also
observe the phenomenon (of lost interrupts after resetting the GPU) on
gen3 machines as well as the previously sighted gen6/gen7. Let's apply
the same HWSTAM workaround that was effective for gen6+ for all, as
although we
On Thu, Dec 13, 2018 at 12:34:02PM +, Chris Wilson wrote:
> Quoting Ville Syrjälä (2018-12-13 12:29:15)
> > On Thu, Dec 13, 2018 at 12:07:35PM +, Chris Wilson wrote:
> > > Quoting Ville Syrjälä (2018-12-13 11:59:28)
> > > > On Thu, Dec 13, 2018 at 11:01:05AM +, Chris Wilson wrote:
> >
Hi,
On 13-12-18 13:14, Ville Syrjälä wrote:
On Thu, Dec 13, 2018 at 12:21:35PM +0100, Hans de Goede wrote:
Implement the exec_mipi_pmic_seq_element callback for the CHT Whiskey Cove
PMIC.
On some CHT devices this fixes the LCD panel not lighting up when it was
not initialized by the GOP,
Having completed a test run of gem_eio across all machines in CI we also
observe the phenomenon (of lost interrupts after resetting the GPU) on
gen3 machines as well as the previously sighted gen6/gen7. Let's apply
the same HWSTAM workaround that was effective for gen6+ for all, as
although we
Tomas and Daniel,
We got an issue here.
The relationship that we try to build between I915 and mei_hdcp is as follows:
* We are using the components to establish the relationship.
* I915 is component master where as mei_hdcp is component.
* I915 adds the component master during the module
Quoting Ville Syrjälä (2018-12-13 12:29:15)
> On Thu, Dec 13, 2018 at 12:07:35PM +, Chris Wilson wrote:
> > Quoting Ville Syrjälä (2018-12-13 11:59:28)
> > > On Thu, Dec 13, 2018 at 11:01:05AM +, Chris Wilson wrote:
> > > > Having completed a test run of gem_eio across all machines in CI
Quoting Tvrtko Ursulin (2018-12-13 12:06:36)
> +static void shut_non_vme_subslices(int drm_fd, uint32_t ctx)
> +{
> + struct drm_i915_gem_context_param_sseu sseu = { };
> + struct drm_i915_gem_context_param arg = {
> + .param = I915_CONTEXT_PARAM_SSEU,
> +
== Series Details ==
Series: series starting with [v3,1/3] ACPI / PMIC: Add support for executing
PMIC MIPI sequence elements
URL : https://patchwork.freedesktop.org/series/53986/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5311 -> Patchwork_11085
On Thu, Dec 13, 2018 at 12:07:35PM +, Chris Wilson wrote:
> Quoting Ville Syrjälä (2018-12-13 11:59:28)
> > On Thu, Dec 13, 2018 at 11:01:05AM +, Chris Wilson wrote:
> > > Having completed a test run of gem_eio across all machines in CI we also
> > > observe the phenomenon (of lost
Am 13.12.18 um 13:21 schrieb Chris Wilson:
> Quoting Koenig, Christian (2018-12-13 12:11:10)
>> Am 13.12.18 um 12:37 schrieb Chris Wilson:
>>> Quoting Chunming Zhou (2018-12-11 10:34:45)
From: Christian König
Implement finding the right timeline point in drm_syncobj_find_fence.
Quoting Koenig, Christian (2018-12-13 12:11:10)
> Am 13.12.18 um 12:37 schrieb Chris Wilson:
> > Quoting Chunming Zhou (2018-12-11 10:34:45)
> >> From: Christian König
> >>
> >> Implement finding the right timeline point in drm_syncobj_find_fence.
> >>
> >> v2: return -EINVAL when the point is
Having completed a test run of gem_eio across all machines in CI we also
observe the phenomenon (of lost interrupts after resetting the GPU) on
gen3 machines as well as the previously sighted gen6/gen7. Let's apply
the same HWSTAM workaround that was effective for gen6+ for all, as
although we
Quoting Chris Wilson (2018-12-13 12:07:35)
> Quoting Ville Syrjälä (2018-12-13 11:59:28)
> > On Thu, Dec 13, 2018 at 11:01:05AM +, Chris Wilson wrote:
> > > Having completed a test run of gem_eio across all machines in CI we also
> > > observe the phenomenon (of lost interrupts after resetting
On Thu, Dec 13, 2018 at 12:21:35PM +0100, Hans de Goede wrote:
> Implement the exec_mipi_pmic_seq_element callback for the CHT Whiskey Cove
> PMIC.
>
> On some CHT devices this fixes the LCD panel not lighting up when it was
> not initialized by the GOP, because an external monitor was plugged in
Am 13.12.18 um 12:37 schrieb Chris Wilson:
> Quoting Chunming Zhou (2018-12-11 10:34:45)
>> From: Christian König
>>
>> Implement finding the right timeline point in drm_syncobj_find_fence.
>>
>> v2: return -EINVAL when the point is not submitted yet.
>> v3: fix reference counting bug, add flags
Quoting Ville Syrjälä (2018-12-13 11:59:28)
> On Thu, Dec 13, 2018 at 11:01:05AM +, Chris Wilson wrote:
> > Having completed a test run of gem_eio across all machines in CI we also
> > observe the phenomenon (of lost interrupts after resetting the GPU) on
> > gen3 machines as well as the
From: Lionel Landwerlin
Verify that the per-context dynamic SSEU uAPI works as expected.
v2: Add subslice tests (Lionel)
Use MI_SET_PREDICATE for further verification when available (Lionel)
v3: Rename to gem_ctx_rpcs (Lionel)
v4: Update kernel API (Lionel)
Add 0 value test (Lionel)
From: Tvrtko Ursulin
Tests to accompany the respective i915 series.
Contributed by Tony Ye is a new test, gem_media_vme, which exercises the media
VME block to demonstrate the effectiveness of the uAPI for this particular
issue.
New in this version is the source code for the VME kernel and
From: Tony Ye
On Icelake we need to turn off subslices not containing the VME block or
the VME kernel will hang.
v2: (Tvrtko Ursulin)
* Remove libdrm usage for setting context param.
* Cleanup bitmask operation.
* Only apply the workaround for ICL.
v3: (Tvrtko Ursulin)
* Added hang
From: Tvrtko Ursulin
---
include/drm-uapi/drm_mode.h | 19
include/drm-uapi/i915_drm.h | 43 +
include/drm-uapi/msm_drm.h | 25 +++--
include/drm-uapi/v3d_drm.h | 33
4 files changed, 114
From: Tony Ye
Simple test which exercises the VME fixed function block.
v2: (Tvrtko Ursulin)
* Small cleanups like copyright date, tabs, remove unused bits.
v3: (Tony Ye)
* Added curbe data entry for dst surface.
* Read the dst surface after the VME kernel being executed.
v4: (Tony Ye)
*
On Thu, Dec 13, 2018 at 11:01:05AM +, Chris Wilson wrote:
> Having completed a test run of gem_eio across all machines in CI we also
> observe the phenomenon (of lost interrupts after resetting the GPU) on
> gen3 machines as well as the previously sighted gen6/gen7. Let's apply
> the same
amdgpu has started to report out of space after creating a few contexts.
This is not the scope of this test as here we just verifying that fences
created in amd can be imported and used for synchronisation by i915 and
for that we just need at least one context created!
References:
== Series Details ==
Series: drm/i915: Apply missed interrupt after reset w/a to all ringbuffer gen
(rev2)
URL : https://patchwork.freedesktop.org/series/53979/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5311 -> Patchwork_11084
1 - 100 of 131 matches
Mail list logo
