>
> Implements the HDCP2.2 repeaters authentication steps such as verifying the
> downstream topology and sending stream management information.
>
> v2: Rebased.
> v3:
> -EINVAL is returned for topology error and rollover scenario.
> Endianness conversion func from drm_hdcp.h is used [Uma]
>
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 Pavel Machek (2018-12-12 20:29:02)
> Hi!
>
> > > > > > > > There's one similar for nouveau in Bugzilla, but it seems like
> > > > > > > > a genuine
> > > > > > > > memory corruption (1 bit flipped):
> > > > > > > >
> > > > > > > > https://bugs.freedesktop.org/show_bug.cgi?id=84880
> > >
== Series Details ==
Series: drm/i915: Apply missed interrupt after reset w/a to all ringbuffer gen
URL : https://patchwork.freedesktop.org/series/53979/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5310 -> Patchwork_11082
On 13/12/2018 08:53, 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 HWSTAM workaround that was
Quoting Daniel Vetter (2018-12-09 17:20:02)
> Drivers might want to remove some sysfs files, which needs the same
> locks and ends up angering lockdep. Relevant snippet of the stack
> trace:
>
> kernfs_remove_by_name_ns+0x3b/0x80
> bus_remove_driver+0x92/0xa0
>
Quoting Tvrtko Ursulin (2018-12-13 08:20:58)
>
> On 12/12/2018 14:36, Tvrtko Ursulin wrote:
> >
> > On 12/12/2018 13:41, Chris Wilson wrote:
> >> From: Oscar Mateo
> >>
> >> SFC (Scaler & Format Converter) units are shared between VD and VEBoxes.
> >> They also happen to have separate reset
Quoting Tvrtko Ursulin (2018-12-12 14:36:27)
>
> On 12/12/2018 13:41, Chris Wilson wrote:
> > diff --git a/drivers/gpu/drm/i915/intel_uncore.c
> > b/drivers/gpu/drm/i915/intel_uncore.c
> > index 9289515108c3..408692b88c98 100644
> > --- a/drivers/gpu/drm/i915/intel_uncore.c
> > +++
>
> All HDCP1.4 routines are gathered together, followed by the generic functions
> those can be extended for HDCP2.2 too.
>
> Signed-off-by: Ramalingam C
> ---
> drivers/gpu/drm/i915/intel_hdcp.c | 118 +++--
> -
> 1 file changed, 59 insertions(+), 59
Quoting Tvrtko Ursulin (2018-12-13 08:28:54)
>
> On 12/12/2018 13:41, Chris Wilson wrote:
> > After declaring a terminally wedged device, we allow ourselves to
> > recover on the next GPU reset (manually triggered), or resume. Check
> > that resetting a wedged device does work.
> >
> >
On 12/12/2018 14:36, Tvrtko Ursulin wrote:
On 12/12/2018 13:41, Chris Wilson wrote:
From: Oscar Mateo
SFC (Scaler & Format Converter) units are shared between VD and VEBoxes.
They also happen to have separate reset bits. So, whenever we want to
reset
one or more of the media engines, we
On 12/12/2018 13:41, Chris Wilson wrote:
After declaring a terminally wedged device, we allow ourselves to
recover on the next GPU reset (manually triggered), or resume. Check
that resetting a wedged device does work.
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
---
On 13/12/2018 08:47, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-12-13 08:20:58)
On 12/12/2018 14:36, Tvrtko Ursulin wrote:
On 12/12/2018 13:41, Chris Wilson wrote:
From: Oscar Mateo
SFC (Scaler & Format Converter) units are shared between VD and VEBoxes.
They also happen to have
On 12/12/2018 13:41, Chris Wilson wrote:
After declaring a terminally wedged device, we allow ourselves to
recover on the next GPU reset (manually triggered), or resume. Check
that resetting a wedged device does work.
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
---
On 12/12/2018 13:41, Chris Wilson wrote:
We currently require that our per-engine reset can be called from any
context, even hardirq, and in the future wish to perform the device
reset without holding struct_mutex (which requires some lockless
shenanigans that demand the lowlevel
Quoting Tvrtko Ursulin (2018-12-13 08:28:00)
>
> On 12/12/2018 13:41, Chris Wilson wrote:
> > +static int igt_atomic_reset(void *arg)
> > +{
> > + static const struct atomic_section phases[] = {
> > + { "preempt", __preempt_begin, __preempt_end },
> > + { "softirq",
We currently require that our per-engine reset can be called from any
context, even hardirq, and in the future wish to perform the device
reset without holding struct_mutex (which requires some lockless
shenanigans that demand the lowlevel intel_reset_gpu() be able to be
used in atomic context).
After declaring a terminally wedged device, we allow ourselves to
recover on the next GPU reset (manually triggered), or resume. Check
that resetting a wedged device does work.
v2: Add rpm (taken explicitly in the subtest in case we remove the outer
wakeref) and early warning to i915_reset() for
From: Oscar Mateo
SFC (Scaler & Format Converter) units are shared between VD and VEBoxes.
They also happen to have separate reset bits. So, whenever we want to reset
one or more of the media engines, we have to make sure the SFCs do not
change owner in the process and, if this owner happens to
From: Oscar Mateo
In Gen11, only even numbered "logical" VDBoxes are hooked up to an SFC
(Scaler & Format Converter) unit. We will use this information to decide
when the SFC units need to be reset.
BSpec: 20189
Signed-off-by: Tomasz Lis
Signed-off-by: Oscar Mateo
Signed-off-by: Michel
Quoting Tvrtko Ursulin (2018-11-13 14:36:28)
> +igt_vme_func_t igt_get_media_vme_func(int devid)
> +{
> + igt_vme_func_t fill = NULL;
> +
> + if (IS_GEN9(devid) || IS_GEN10(devid) || IS_GEN11(devid))
> + fill = gen11_media_vme_func;
gen11_media_vme_func implies that this
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
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
== Series Details ==
Series: series starting with [CI,1/4] drm/i915/selftests: Check we can recover
a wedged device
URL : https://patchwork.freedesktop.org/series/53980/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5310 -> Patchwork_11083
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 12/13/2018 1:52 PM, Winkler, Tomas wrote:
Implements the HDCP2.2 repeaters authentication steps such as verifying the
downstream topology and sending stream management information.
v2: Rebased.
v3:
-EINVAL is returned for topology error and rollover scenario.
Endianness conversion
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
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:
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
== Series Details ==
Series: drm/i915: Apply missed interrupt after reset w/a to all ringbuffer gen
URL : https://patchwork.freedesktop.org/series/53979/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5310_full -> Patchwork_11082_full
On 12/13/2018 1:47 PM, Winkler, Tomas wrote:
All HDCP1.4 routines are gathered together, followed by the generic functions
those can be extended for HDCP2.2 too.
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/intel_hdcp.c | 118 +++--
-
1 file
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
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
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 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
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)
*
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: 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
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
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
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 Chunming Zhou (2018-12-11 10:34:40)
> From: Christian König
>
> Lockless container implementation similar to a dma_fence_array, but with
> only two elements per node and automatic garbage collection.
>
> v2: properly document dma_fence_chain_for_each, add
> dma_fence_chain_find_seqno,
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 handling as well
>
> Signed-off-by: Christian
== 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
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 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
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
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
== 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
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
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
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
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 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
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
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,
== 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
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é
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
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, 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
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, 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
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: 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
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
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 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
>
== 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 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 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
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
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
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: 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
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 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>[
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
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.
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
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
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 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, 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
== 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:
== 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: 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:
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
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 +-
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
1 - 100 of 131 matches
Mail list logo
