>
> 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 deletion
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 ha
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
---
.../gpu/drm/i915/selfte
>
> 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]
>
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 intel_reset_gpu
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
---
.../gpu/drm/i915/selfte
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
> > >
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.
> >
> > Signed-off
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", __s
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 bits
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 have
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
> > +++ b/drivers/gpu/
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 Thierr
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). Te
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 m
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 b
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 sep
== 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 effe
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
> acpi_video_unregister+0x24/0x4
== 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
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
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 have
== 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: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 func
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 nee
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 d
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 changed
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
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 Kön
== 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
=
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: https://bugs.fre
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 HWSTA
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 insertio
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)
* A
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 detector
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 some
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)
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 previo
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 h
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
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
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 have
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 not
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.
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 interrup
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,
> + .c
== 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
==
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 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 lo
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 have
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, becau
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:
> > >
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 have
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 devic
== 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, 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 opr
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 W
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 o
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 pock
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 anticipatio
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
== 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: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 *da
== 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
=
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é Roberto
== 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
S
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 1
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 con
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 d
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 nee
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
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 s
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 n
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 f
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: 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 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 com
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: mo
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>[ 13.978733
== 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 commi
== 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: wa
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 ->
> 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 mast
== 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**
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
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 u
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 are
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 Vi
== 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
===
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).
>> Ok,
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
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 bsp
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 change
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
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 active.
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 m
== 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: WARNING:STATIC_CONST_CHAR
1 - 100 of 131 matches
Mail list logo
