On 2020/3/20 14:30, Tom Murphy wrote:
Could we merge patch 1-3 from this series? it just cleans up weird
code and merging these patches will cover some of the work needed to
move the intel iommu driver to the dma-iommu api in the future.
Can you please take a look at this patch series?
From: Andi Shyti
The following interfaces:
i915_wedged
i915_forcewake_user
i915_gem_interrupt
i915_sseu_status
are dependent on gt values. Put them inside gt/ and drop the
"i915_" prefix name. This would be the new structure:
gt
|
+-- forcewake_user
|
+-- interrupt_info_show
|
== Series Details ==
Series: drm/i915/gt: move files more files into debugfs (rev2)
URL : https://patchwork.freedesktop.org/series/74834/
State : failure
== Summary ==
Applying: drm/i915/gt: move files more files into debugfs
error: sha1 information is lacking or useless
> -Original Message-
> From: Souza, Jose
> Sent: Friday, March 20, 2020 12:36 AM
> To: Shankar, Uma ; intel-gfx@lists.freedesktop.org
> Cc: Khor, Swee Aun
> Subject: Re: [Intel-gfx] [PATCH] drm/i915/display: Trigger Modeset at boot
> for audio
> codec init
>
> On Wed, 2020-03-18 at
Quoting Francisco Jerez (2020-03-20 02:46:19)
> Francisco Jerez writes:
>
> > Francisco Jerez writes:
> >
> >> Chris Wilson writes:
> >>
> >>> Quoting Francisco Jerez (2020-03-10 21:41:55)
> diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
> b/drivers/gpu/drm/i915/gt/intel_lrc.c
>
== Series Details ==
Series: drm/i915/gt: Report context-is-closed prior to pinning
URL : https://patchwork.freedesktop.org/series/74916/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8163 -> Patchwork_17034
Summary
Hi "José,
Thank you for the patch! Perhaps something to improve:
url:
https://github.com/0day-ci/linux/commits/Jos-Roberto-de-Souza/drm-i915-tc-tgl-Implement-TCCOLD-sequences/20200319-080253
base: git://anongit.freedesktop.org/drm-intel for-linux-next
If you fix the issue, kindly add
Quoting Tvrtko Ursulin (2020-03-20 12:01:14)
>
>
> On 20/03/2020 11:45, Andi Shyti wrote:
> > Hi Chris,
> >
> > On Fri, Mar 20, 2020 at 11:11:46AM +, Chris Wilson wrote:
> >> Quoting Andi Shyti (2020-03-20 03:49:01)
> >>> From: Andi Shyti
> >>>
> >>> The following interfaces:
> >>>
> >>>
We dropped calling process_csb prior to handling direct submission in
order to avoid the nesting of spinlocks and lift process_csb() and the
majority of the tasklet out of irq-off. However, we do want to avoid
ksoftirqd latency in the fast path, so try and pull the interrupt-bh
local to direct
On Wed, Mar 11, 2020 at 06:31:30PM +0200, Ville Syrjälä wrote:
> On Mon, Mar 09, 2020 at 06:12:00PM +0200, Stanislav Lisovskiy wrote:
> > Currently intel_can_enable_sagv function contains
> > a mix of workarounds for different platforms
> > some of them are not valid for gens >= 11 already,
> > so
Chris Wilson writes:
> Use the restored ability to check if a context is closed to decide
> whether or not to immediately ban the context from further execution
> after a hang.
>
> Fixes: be90e344836a ("drm/i915/gt: Cancel banned contexts after GT reset")
> Signed-off-by: Chris Wilson
> Cc:
Hi Chris,
On Fri, Mar 20, 2020 at 11:11:46AM +, Chris Wilson wrote:
> Quoting Andi Shyti (2020-03-20 03:49:01)
> > From: Andi Shyti
> >
> > The following interfaces:
> >
> > i915_wedged
> > i915_forcewake_user
> > i915_gem_interrupt
> > i915_sseu_status
> >
> > are dependent on gt values.
On 20/03/2020 11:45, Andi Shyti wrote:
Hi Chris,
On Fri, Mar 20, 2020 at 11:11:46AM +, Chris Wilson wrote:
Quoting Andi Shyti (2020-03-20 03:49:01)
From: Andi Shyti
The following interfaces:
i915_wedged
i915_forcewake_user
i915_gem_interrupt
i915_sseu_status
are dependent on gt
If the caller allows and we do not have to wait for any signals,
immediately execute the work within the caller's process. By doing so we
avoid the overhead of scheduling a new task, and the latency in
executing it, at the cost of pulling that work back into the immediate
context. (Sometimes we
== Series Details ==
Series: drm/i915/execlists: Pull tasklet interrupt-bh local to direct submission
URL : https://patchwork.freedesktop.org/series/74914/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8163_full -> Patchwork_17032_full
As we store the handle lookup inside a radix tree, we do not need the
gem_context->mutex except until we need to insert our lookup into the
common radix tree. This takes a small bit of rearranging to ensure that
the lut we insert into the tree is ready prior to actually inserting it
(as soon as it
Our assertion caught that we do try to pin a closed context if userspace
is viciously racing context-closure with execbuf, so make it fail
gracefully.
Closes: https://gitlab.freedesktop.org/drm/intel/issues/1492
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Mika Kuoppala
---
We dropped calling process_csb prior to handling direct submission in
order to avoid the nesting of spinlocks and lift process_csb() and the
majority of the tasklet out of irq-off. However, we do want to avoid
ksoftirqd latency in the fast path, so try and pull the interrupt-bh
local to direct
If the caller allows and we do not have to wait for any signals,
immediately execute the work within the caller's process. By doing so we
avoid the overhead of scheduling a new task, and the latency in
executing it, at the cost of pulling that work back into the immediate
context. (Sometimes we
Quoting Tvrtko Ursulin (2020-03-20 13:47:39)
>
> On 20/03/2020 13:01, Chris Wilson wrote:
> > As we store the handle lookup inside a radix tree, we do not need the
> > gem_context->mutex except until we need to insert our lookup into the
> > common radix tree. This takes a small bit of
Quoting Andi Shyti (2020-03-20 03:49:01)
> From: Andi Shyti
>
> The following interfaces:
>
> i915_wedged
> i915_forcewake_user
> i915_gem_interrupt
> i915_sseu_status
>
> are dependent on gt values. Put them inside gt/ and drop the
> "i915_" prefix name. This would be the new structure:
>
>
== Series Details ==
Series: drm/i915/execlists: Pull tasklet interrupt-bh local to direct submission
URL : https://patchwork.freedesktop.org/series/74914/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8163 -> Patchwork_17032
On Fri, 20 Mar 2020, Jani Nikula wrote:
> On Tue, 11 Feb 2020, Gwan-gyeong Mun wrote:
>> It adds an unpack only function for DRM infoframe for dynamic range and
>> mastering infoframe readout.
>> It unpacks the information data block contained in the binary buffer into
>> a structured frame of
Hi Jani,
On Fri, Mar 20, 2020 at 01:32:17PM +0200, Jani Nikula wrote:
> On Fri, 20 Mar 2020, Jani Nikula wrote:
> > On Tue, 11 Feb 2020, Gwan-gyeong Mun wrote:
> >> It adds an unpack only function for DRM infoframe for dynamic range and
> >> mastering infoframe readout.
> >> It unpacks the
If the caller allows and we do not have to wait for any signals,
immediately execute the work within the caller's process. By doing so we
avoid the overhead of scheduling a new task, and the latency in
executing it, at the cost of pulling that work back into the immediate
context. (Sometimes we
Could we merge patch 1-3 from this series? it just cleans up weird
code and merging these patches will cover some of the work needed to
move the intel iommu driver to the dma-iommu api in the future.
On Sat, 21 Dec 2019 at 07:04, Tom Murphy wrote:
>
> Remove all IOVA handling code from the
Any news on this? Is there anyone who wants to try and fix this possible bug?
On Mon, 23 Dec 2019 at 03:41, Jani Nikula wrote:
>
> On Mon, 23 Dec 2019, Robin Murphy wrote:
> > On 2019-12-23 10:37 am, Jani Nikula wrote:
> >> On Sat, 21 Dec 2019, Tom Murphy wrote:
> >>> This patchset converts
Because period and duty cycle are defined in the PWM framework structs as ints
with units of nanoseconds, the maximum time duration that can be set is limited
to ~2.147 seconds. Consequently, applications desiring to set greater time
periods via the PWM framework are not be able to do so - like,
Because period and duty cycle are defined in the PWM framework structs as ints
with units of nanoseconds, the maximum time duration that can be set is limited
to ~2.147 seconds. Consequently, applications desiring to set greater time
periods via the PWM framework are not be able to do so - like,
Since the PWM framework is switching struct pwm_state.duty_cycle's
datatype to u64, prepare for this transition by using DIV_ROUND_UP_ULL
to handle a 64-bit dividend.
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: David Airlie
Cc: Daniel Vetter
Cc: Chris Wilson
Cc: "Ville Syrjälä"
Cc:
Since the PWM framework is switching struct pwm_state.duty_cycle's
datatype to u64, prepare for this transition by using DIV_ROUND_UP_ULL
to handle a 64-bit dividend.
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: David Airlie
Cc: Daniel Vetter
Cc: Chris Wilson
Cc: "Ville Syrjälä"
Cc:
On Tue, 11 Feb 2020, Gwan-gyeong Mun wrote:
> It adds an unpack only function for DRM infoframe for dynamic range and
> mastering infoframe readout.
> It unpacks the information data block contained in the binary buffer into
> a structured frame of the HDMI Dynamic Range and Mastering (DRM)
>
On 20/03/2020 13:01, Chris Wilson wrote:
Our assertion caught that we do try to pin a closed context if userspace
is viciously racing context-closure with execbuf, so make it fail
gracefully.
Closes: https://gitlab.freedesktop.org/drm/intel/issues/1492
Signed-off-by: Chris Wilson
Cc: Tvrtko
== Series Details ==
Series: drm/i915/selftests: Check for has-reset before testing hostile contexts
URL : https://patchwork.freedesktop.org/series/74915/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8163_full -> Patchwork_17033_full
On 20/03/2020 13:01, Chris Wilson wrote:
As we store the handle lookup inside a radix tree, we do not need the
gem_context->mutex except until we need to insert our lookup into the
common radix tree. This takes a small bit of rearranging to ensure that
the lut we insert into the tree is ready
We dropped calling process_csb prior to handling direct submission in
order to avoid the nesting of spinlocks and lift process_csb() and the
majority of the tasklet out of irq-off. However, we do want to avoid
ksoftirqd latency in the fast path, so try and pull the interrupt-bh
local to direct
In order to kill off a hostile context, we need to be able to reset the
GPU. So check that is supported prior to beginning the test.
Reported-by: Tvrtko Ursulin
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/selftest_lrc.c | 3 +++
1 file changed, 3 insertions(+)
Our assertion caught that we do try to pin a closed context if userspace
is viciously racing context-closure with execbuf, so make it fail
gracefully.
Closes: https://gitlab.freedesktop.org/drm/intel/issues/1492
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Mika Kuoppala
---
== Series Details ==
Series: drm/i915/selftests: Check for has-reset before testing hostile contexts
URL : https://patchwork.freedesktop.org/series/74915/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8163 -> Patchwork_17033
On Mon, 16 Mar 2020, "Shankar, Uma" wrote:
>> -Original Message-
>> From: dri-devel On Behalf Of Gwan-
>> gyeong Mun
>> Sent: Tuesday, February 11, 2020 1:17 PM
>> To: intel-gfx@lists.freedesktop.org
>> Cc: linux-fb...@vger.kernel.org; dri-de...@lists.freedesktop.org
>> Subject: [PATCH
Prefer drm_dbg() over DRM_DEV_DEBUG_DRIVER() and drm_err() over
dev_err().
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_wopcm.c | 22 ++
1 file changed, 10 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_wopcm.c
Convert all the DRM_* logging macros to the struct drm_device based
macros to provide device specific logging.
No functional changes.
Generated using the following semantic patch, originally written by
Wambui Karuga , with manual fixups on top:
@@
identifier fn, T;
@@
fn(...,struct
Convert all the DRM_* logging macros to the struct drm_device based
macros to provide device specific logging.
No functional changes.
Generated using the following semantic patch, originally written by
Wambui Karuga , with manual fixups on top:
@@
identifier fn, T;
@@
fn(...,struct
Convert all the DRM_* logging macros to the struct drm_device based
macros to provide device specific logging.
No functional changes.
Generated using the following semantic patch, originally written by
Wambui Karuga , with manual fixups on top:
@@
identifier fn, T;
@@
fn(...,struct
Convert all the DRM_* logging macros to the struct drm_device based
macros to provide device specific logging.
No functional changes.
Generated using the following semantic patch, originally written by
Wambui Karuga , with manual fixups on top:
@@
identifier fn, T;
@@
fn(...,struct
Convert all the DRM_* logging macros to the struct drm_device based
macros to provide device specific logging.
No functional changes.
Generated using the following semantic patch, originally written by
Wambui Karuga , with manual fixups on top:
@@
identifier fn, T;
@@
fn(...,struct
Convert all the DRM_* logging macros to the struct drm_device based
macros to provide device specific logging.
No functional changes.
Generated using the following semantic patch, originally written by
Wambui Karuga , with manual fixups on top:
@@
identifier fn, T;
@@
fn(...,struct
Here's a batch of logging conversion.
BR,
Jani.
Jani Nikula (13):
drm/i915/ddi: use struct drm_device based logging
drm/i915/display_power: use struct drm_device based logging
drm/i915/dp_aux_backlight: use struct drm_device based logging
drm/i915/dp_mst: use struct drm_device based
On 20/03/2020 03:49, Andi Shyti wrote:
From: Andi Shyti
The following interfaces:
i915_wedged
i915_forcewake_user
i915_gem_interrupt
i915_sseu_status
are dependent on gt values. Put them inside gt/ and drop the
"i915_" prefix name. This would be the new structure:
gt
|
+--
Convert all the DRM_* logging macros to the struct drm_device based
macros to provide device specific logging.
No functional changes.
Generated using the following semantic patch, originally written by
Wambui Karuga , with manual fixups on top:
@@
identifier fn, T;
@@
fn(...,struct
Drop useless macro hiding the return. Fix superfluous whitespace. Rename
function to all lowercase.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_display.c | 40 ++--
1 file changed, 19 insertions(+), 21 deletions(-)
diff --git
Convert all the DRM_* logging macros to the struct drm_device based
macros to provide device specific logging.
No functional changes.
Generated using the following semantic patch, originally written by
Wambui Karuga , with manual fixups on top:
@@
identifier fn, T;
@@
fn(...,struct
Convert all the DRM_* logging macros to the struct drm_device based
macros to provide device specific logging.
No functional changes.
Generated using the following semantic patch, originally written by
Wambui Karuga , with manual fixups on top:
@@
identifier fn, T;
@@
fn(...,struct
Convert all the DRM_* logging macros to the struct drm_device based
macros to provide device specific logging.
No functional changes.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/icl_dsi.c | 10 +++---
drivers/gpu/drm/i915/display/intel_dsi_vbt.c | 11 +--
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_connector.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_connector.c
b/drivers/gpu/drm/i915/display/intel_connector.c
index 903e49659f56..98ec2ea86c7c 100644
---
== Series Details ==
Series: drm/i915/gt: Report context-is-closed prior to pinning
URL : https://patchwork.freedesktop.org/series/74916/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8163_full -> Patchwork_17034_full
On Fri, Mar 20, 2020 at 06:19:37AM +, Shankar, Uma wrote:
>
>
> > -Original Message-
> > From: Souza, Jose
> > Sent: Friday, March 20, 2020 12:36 AM
> > To: Shankar, Uma ; intel-gfx@lists.freedesktop.org
> > Cc: Khor, Swee Aun
> > Subject: Re: [Intel-gfx] [PATCH] drm/i915/display:
== Series Details ==
Series: series starting with [1/4] drm/i915/gt: Report context-is-closed prior
to pinning
URL : https://patchwork.freedesktop.org/series/74918/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8167 -> Patchwork_17037
== Series Details ==
Series: drm/i915/execlists: Pull tasklet interrupt-bh local to direct
submission (rev2)
URL : https://patchwork.freedesktop.org/series/74914/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8167 -> Patchwork_17035
Quoting Patchwork (2020-03-20 17:02:49)
> * igt@i915_selftest@live@execlists:
> - fi-kbl-r: [PASS][3] -> [DMESG-FAIL][4]
>[3]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8167/fi-kbl-r/igt@i915_selftest@l...@execlists.html
>[4]:
>
== Series Details ==
Series: drm/i915: Immediately execute the fenced work (rev2)
URL : https://patchwork.freedesktop.org/series/74917/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8167 -> Patchwork_17036
Summary
---
Hi Ville,
You means this change right? Sure. Will try your suggestion as well.
By the way, what is different between hw.mode and uapi.mode and how we know
which to be used? It used to only base.mode before hw/uapi split patches.
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++
We dropped calling process_csb prior to handling direct submission in
order to avoid the nesting of spinlocks and lift process_csb() and the
majority of the tasklet out of irq-off. However, we do want to avoid
ksoftirqd latency in the fast path, so try and pull the interrupt-bh
local to direct
== Series Details ==
Series: drm/i915: Get rid of silly void* from MST code (rev2)
URL : https://patchwork.freedesktop.org/series/74539/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8167 -> Patchwork_17039
Summary
---
On Thu, Mar 19, 2020 at 03:20:50PM -0700, Manasi Navare wrote:
> On Thu, Mar 19, 2020 at 06:38:42PM +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Some new eDP panels don't like to operate at the max parameters, and
> > instead we need to go for an optimal confiugration. That
On Fri, 2020-03-20 at 16:11 +0300, Dan Carpenter wrote:
> Hi "José,
>
> Thank you for the patch! Perhaps something to improve:
>
> url:
> https://github.com/0day-ci/linux/commits/Jos-Roberto-de-Souza/drm-i915-tc-tgl-Implement-TCCOLD-sequences/20200319-080253
> base:
== Series Details ==
Series: series starting with [1/4] drm/i915/gt: Report context-is-closed prior
to pinning (rev2)
URL : https://patchwork.freedesktop.org/series/74918/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8167 -> Patchwork_17041
On Fri, 2020-03-20 at 00:20 +, Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915/display/fbc: Make fences a nice-to-have for GEN9+
> URL : https://patchwork.freedesktop.org/series/74890/
> State : failure
>
> == Summary ==
>
> CI Bug Log - changes from CI_DRM_8160_full ->
== Series Details ==
Series: drm/i915: Hotplug cleanups (rev6)
URL : https://patchwork.freedesktop.org/series/72348/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8167 -> Patchwork_17038
Summary
---
**SUCCESS**
== Series Details ==
Series: drm/i915: drm device based logging changes
URL : https://patchwork.freedesktop.org/series/74927/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
ddb4a444dd75 drm/i915/ddi: use struct drm_device based logging
07dd9ea10f43 drm/i915/display_power: use
== Series Details ==
Series: drm/i915: drm device based logging changes
URL : https://patchwork.freedesktop.org/series/74927/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8167 -> Patchwork_17040
Summary
---
Chris Wilson writes:
> We dropped calling process_csb prior to handling direct submission in
> order to avoid the nesting of spinlocks and lift process_csb() and the
> majority of the tasklet out of irq-off. However, we do want to avoid
> ksoftirqd latency in the fast path, so try and pull the
On Thu, Mar 19, 2020 at 06:38:44PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> The DP link computation functions shouldn't modify the
> adjusted_mode so make it const.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Manasi Navare
Manasi
> ---
>
On Thu, Mar 19, 2020 at 03:20:56PM +0200, Ville Syrjälä wrote:
> On Wed, Mar 18, 2020 at 03:34:38PM -0700, Manasi Navare wrote:
> > On Fri, Mar 13, 2020 at 06:48:20PM +0200, Ville Syrjala wrote:
> > > From: Ville Syrjälä
> > >
> > > This port sync enable/disable stuff is misplaced. It's just
Francisco Jerez writes:
> Chris Wilson writes:
>
>> We dropped calling process_csb prior to handling direct submission in
>> order to avoid the nesting of spinlocks and lift process_csb() and the
>> majority of the tasklet out of irq-off. However, we do want to avoid
>> ksoftirqd latency in the
On Fri, 2020-03-20 at 20:07 +, Souza, Jose wrote:
> On Fri, 2020-03-20 at 00:20 +, Patchwork wrote:
> > == Series Details ==
> >
> > Series: drm/i915/display/fbc: Make fences a nice-to-have for GEN9+
> > URL : https://patchwork.freedesktop.org/series/74890/
> > State : failure
> >
> >
On Thu, Mar 19, 2020 at 03:22:06PM +0200, Ville Syrjälä wrote:
> On Wed, Mar 18, 2020 at 03:37:32PM -0700, Manasi Navare wrote:
> > On Fri, Mar 13, 2020 at 06:48:21PM +0200, Ville Syrjala wrote:
> > > From: Ville Syrjälä
> > >
> > > The entire crtc state has been reset before readout so
> > >
On Fri, Mar 20, 2020 at 09:08:31PM +0200, Ville Syrjälä wrote:
> On Thu, Mar 19, 2020 at 03:20:50PM -0700, Manasi Navare wrote:
> > On Thu, Mar 19, 2020 at 06:38:42PM +0200, Ville Syrjala wrote:
> > > From: Ville Syrjälä
> > >
> > > Some new eDP panels don't like to operate at the max
== Series Details ==
Series: drm/i915: Immediately execute the fenced work (rev2)
URL : https://patchwork.freedesktop.org/series/74917/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8167_full -> Patchwork_17036_full
This will not work for MST, here a example
Previous state:
MST master pipe A
MST slave pipe B
New state:
Pipe A being disabled
On drm_atomic_helper_check_modeset() both intel_crtc_states will be
added to the state with crtc_state->uapi.mode_changed=true.
Then on the regular
== Series Details ==
Series: drm/i915: Get rid of silly void* from MST code (rev2)
URL : https://patchwork.freedesktop.org/series/74539/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8167_full -> Patchwork_17039_full
== Series Details ==
Series: series starting with [1/4] drm/i915/gt: Report context-is-closed prior
to pinning (rev2)
URL : https://patchwork.freedesktop.org/series/74918/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8167_full -> Patchwork_17041_full
== Series Details ==
Series: drm/i915: Hotplug cleanups (rev6)
URL : https://patchwork.freedesktop.org/series/72348/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8167_full -> Patchwork_17038_full
Summary
---
Never mind, read the code again it will work.
Reviewed-by: José Roberto de Souza
On Fri, 2020-03-20 at 23:37 +, Souza, Jose wrote:
> This will not work for MST, here a example
>
> Previous state:
> MST master pipe A
> MST slave pipe B
>
> New state:
> Pipe A being disabled
>
> On
== Series Details ==
Series: drm/i915: drm device based logging changes
URL : https://patchwork.freedesktop.org/series/74927/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8167_full -> Patchwork_17040_full
Summary
---
85 matches
Mail list logo
