== Series Details ==
Series: drm/i915: Pin the context as we work on it
URL : https://patchwork.freedesktop.org/series/71700/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7696_full -> Patchwork_16017_full
Summary
---
Quoting Wambui Karuga (2020-01-07 17:13:29)
> Convert the use of the DRM_DEBUG_KMS() logging macro to the new struct
> drm_device based drm_dbg_kms() logging macro in i915/intel_pch.c.
>
> Signed-off-by: Wambui Karuga
> ---
> drivers/gpu/drm/i915/intel_pch.c | 46 +---
Chris Wilson writes:
> It is highly unlikely, but still conceivable, that we submit a context
> with the same GGTT address as last active on the HW. In this case, with
> a matching LRCA, the HW would not restore the new context image causing
> a potential violation of our context isolation.
>
> S
On Wed, 08 Jan 2020, Joonas Lahtinen wrote:
> Quoting Wambui Karuga (2020-01-07 17:13:29)
>> Convert the use of the DRM_DEBUG_KMS() logging macro to the new struct
>> drm_device based drm_dbg_kms() logging macro in i915/intel_pch.c.
>>
>> Signed-off-by: Wambui Karuga
>> ---
>> drivers/gpu/drm/i
== Series Details ==
Series: series starting with [v4,rebased,1/2] drm/i915/display/icl+: Do not
program clockgating
URL : https://patchwork.freedesktop.org/series/71705/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7697_full -> Patchwork_16018_full
=
Quoting Jani Nikula (2020-01-08 09:40:40)
> On Wed, 08 Jan 2020, Joonas Lahtinen wrote:
> > Quoting Wambui Karuga (2020-01-07 17:13:29)
> >> Convert the use of the DRM_DEBUG_KMS() logging macro to the new struct
> >> drm_device based drm_dbg_kms() logging macro in i915/intel_pch.c.
> >>
> >> Sign
If we find ourselves waiting on a MI_SEMAPHORE_WAIT, either within the
user batch or in our own preamble, the engine raises a
GT_WAIT_ON_SEMAPHORE interrupt. We can unmask that interrupt and so
respond to a semaphore wait by yielding the timeslice, if we have
another context to yield to!
The only
We cache the user's vma for a brief period of time after they close them
so that if they are immediately reopened we avoid having to unbind and
rebind them. This happens quite frequently for display servers which
only keep a client's frame open for as long as they are copying from it,
and so they o
Currently, we reset the timer after a pre-eemption event. This has the
side-effect that the timeslice runs into the second context after the
first is completed. To be more fair, we want to reset the clock after
promotion as well.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/dr
Since we now allow the intel_context_unpin() to run unserialised, we
risk our operations under the intel_context_lock_pinned() being run as
the context is unpinned (and thus invalidating our state). We can
atomically acquire the pin, testing to see if it is pinned in the
process, thus ensuring that
== Series Details ==
Series: drm/i915/gt: Always force restore freshly pinned contexts
URL : https://patchwork.freedesktop.org/series/71706/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7697_full -> Patchwork_16019_full
Su
== Series Details ==
Series: series starting with [1/4] drm/i915: Pin the context as we work on it
URL : https://patchwork.freedesktop.org/series/71755/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
5472c92edbce drm/i915: Pin the context as we work on it
0ceabcc14ba7 drm/i915:
On Mon, 06 Jan 2020, "Gustavo A. R. Silva" wrote:
> Fix inconsistent IS_ERR and PTR_ERR in intel_modeset_all_tiles().
>
> The proper pointer to be passed as argument is crtc_state.
>
> This bug was detected with the help of Coccinelle.
Thanks, already fixed by Dan in commit 953cac3ec55f ("drm/i91
On Mon, 06 Jan 2020, Pankaj Bharadiya
wrote:
> dev_WARN does not support conditional warning unlike WARN.
>
> Add condition support to dev_WARN (file: include/linux/device.h)
> to make it work like WARN and modify all existing callers to use it.
>
> This is quite useful where we want to replace e
On Mon, 06 Jan 2020, Pankaj Bharadiya
wrote:
> We will need struct device pointer to pass it to dev_WARN* calls.
>
> Add helper functions to exract device pointer from various structs.
Please focus on using and adding helpers to get the struct
drm_i915_private * pointer, and use that instead.
W
== Series Details ==
Series: series starting with [1/4] drm/i915: Pin the context as we work on it
URL : https://patchwork.freedesktop.org/series/71755/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7702 -> Patchwork_16022
Hi Chris,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on drm-tip/drm-tip]
[cannot apply to v5.5-rc5 next-20200106]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. B
On Mon, 2020-01-06 at 07:21 -0800, José Roberto de Souza wrote:
> Recent improvements in the state tracking in i915 caused PSR to not
> be
> enabled when reusing firmware/BIOS modeset, this is due to all
> initial
> commits returning ealier in intel_atomic_check() as needs_modeset()
> is always fal
While this is encroaching on midlayer territory, having already made the
state allocation a previous step in pinning, we can now pull the common
intel_context_active_acquire() into intel_context_pin() itself. This is
a prelude to make the activation a separate step inside pinning, outside
of the ce
Allow for knowledgeable users to preallocate the context state, and to
separate the allocation step from the pinning step during
intel_context_pin()
Signed-off-by: Chris Wilson
Cc: Maarten Lankhorst
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_context.c | 34 +++--
There seems to be some undocumented bandwidth
bottleneck/dependency which scales with CDCLK,
causing FIFO underruns when CDCLK is too low,
even when it's correct from BSpec point of view.
Currently for TGL platforms we calculate
min_cdclk initially based on pixel_rate divided
by 2, accounting for
I forwarding this to a (sub)set of correct MLs/maintainers. Please,
follow the instructions they give.
-- Forwarded message -
From: Ebrahim Byagowi
Date: Mon, Dec 23, 2019 at 12:17 PM
Subject: [PATCH] drm/i915: Fix enable OA report logic
To:
Clang raises
drivers/gpu/drm/i91
On Mon, 06 Jan 2020, Sam Ravnborg wrote:
> Hi Pankaj.
>
> On Mon, Jan 06, 2020 at 10:53:23PM +0530, Pankaj Bharadiya wrote:
>> Device specific WARN* calls include device information in the
>> backtrace, so we know what device the warnings originate from.
>>
>> Covert all the calls of WARN* with d
On Wed, 08 Jan 2020, Andy Shevchenko wrote:
> I forwarding this to a (sub)set of correct MLs/maintainers. Please,
> follow the instructions they give.
Thanks, already fixed by commit 9278bbb6e43c ("drm/i915/perf: Reverse a
ternary to make sparse happy") in our -next.
BR,
Jani.
>
> -- Fo
Op 08-01-2020 om 13:23 schreef Chris Wilson:
> While this is encroaching on midlayer territory, having already made the
> state allocation a previous step in pinning, we can now pull the common
> intel_context_active_acquire() into intel_context_pin() itself. This is
> a prelude to make the activat
== Series Details ==
Series: series starting with [1/2] drm/i915/gt: Push context state allocation
earlier
URL : https://patchwork.freedesktop.org/series/71759/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7702 -> Patchwork_16023
=
On Wed, 08 Jan 2020, Chen Zhou wrote:
> Fix build error:
> lib/crypto/chacha.c: In function chacha_permute:
> lib/crypto/chacha.c:65:1: warning: the frame size of 3384 bytes is larger
> than 2048 bytes [-Wframe-larger-than=]
> }
> ^
IMO this needs a better explanation of why not having the in
== Series Details ==
Series: drm/i915: Bump up CDCLK to eliminate underruns on TGL
URL : https://patchwork.freedesktop.org/series/71760/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
859795e699e8 drm/i915: Bump up CDCLK to eliminate underruns on TGL
-:34: CHECK:PARENTHESIS_ALIG
The i915 driver can use the backlight subsystem as an option, and usually
selects it when CONFIG_ACPI is set. However it is possible to configure
a kernel with modular backlight classdev support and a built-in i915
driver, which leads to a linker error:
drivers/gpu/drm/i915/display/intel_panel.o:
From: Ville Syrjälä
When moving the pipe disable & co. function calls from
haswell_crtc_disable() into the encoder .post_disable() hooks I
neglected to account for the MST vs. DDI interactions properly.
This now leads us to call these functions two times for the last
MST stream (once from the MST
== Series Details ==
Series: Fwd: [PATCH] drm/i915: Fix enable OA report logic
URL : https://patchwork.freedesktop.org/series/71761/
State : failure
== Summary ==
Applying: Fwd: [PATCH] drm/i915: Fix enable OA report logic
error: corrupt patch at line 19
error: could not build fake ancestor
hi
On Tue, 07 Jan 2020, Chris Wilson wrote:
> Quoting Souza, Jose (2020-01-07 14:01:40)
>> On Tue, 2020-01-07 at 16:03 +0300, Dan Carpenter wrote:
>> > There is a cut and paste bug so we return the wrong error code.
>> >
>> > Fixes: a603f5bd1691 ("drm/i915/dp: Make sure all tiled connectors get
>> >
== Series Details ==
Series: i915: fix backlight configuration issue
URL : https://patchwork.freedesktop.org/series/71766/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
3237c6dfef7c i915: fix backlight configuration issue
-:12: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped c
Quoting Jani Nikula (2020-01-08 14:33:22)
> On Tue, 07 Jan 2020, Chris Wilson wrote:
> > Quoting Souza, Jose (2020-01-07 14:01:40)
> >> On Tue, 2020-01-07 at 16:03 +0300, Dan Carpenter wrote:
> >> > There is a cut and paste bug so we return the wrong error code.
> >> >
> >> > Fixes: a603f5bd1691
On Wed, 08 Jan 2020, Chris Wilson wrote:
> Quoting Jani Nikula (2020-01-08 09:40:40)
>> On Wed, 08 Jan 2020, Joonas Lahtinen wrote:
>> > Quoting Wambui Karuga (2020-01-07 17:13:29)
>> >> Convert the use of the DRM_DEBUG_KMS() logging macro to the new struct
>> >> drm_device based drm_dbg_kms() lo
From: Ville Syrjälä
When moving the pipe disable & co. function calls from
haswell_crtc_disable() into the encoder .post_disable() hooks I
neglected to account for the MST vs. DDI interactions properly.
This now leads us to call these functions two times for the last
MST stream (once from the MST
Quoting Jani Nikula (2019-12-05 15:43:40)
> +static int i915_param_int_open(struct inode *inode, struct file *file)
> +{
> + return single_open(file, i915_param_int_show, inode->i_private);
What I've always wanted with this style of approach was a means that the
parameter is only set while t
Quoting Jani Nikula (2020-01-08 14:44:38)
> On Wed, 08 Jan 2020, Chris Wilson wrote:
> > Quoting Jani Nikula (2020-01-08 09:40:40)
> >> On Wed, 08 Jan 2020, Joonas Lahtinen
> >> wrote:
> >> > Quoting Wambui Karuga (2020-01-07 17:13:29)
> >> >> Convert the use of the DRM_DEBUG_KMS() logging macro
== Series Details ==
Series: drm/i915: Bump up CDCLK to eliminate underruns on TGL
URL : https://patchwork.freedesktop.org/series/71760/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7703 -> Patchwork_16024
Summary
---
From: Ville Syrjälä
I missed a few assert_pipe_disabled() cases when changing it to
take enum transcoder instead of enum pipe, making sparse unhappy.
Convert the leftovers.
Reported-by: kbuild test robot
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_dp.c | 4 ++--
driver
In TE Gate mode, on every flip we need to set the
frame update request bit. After this bit is set
transcoder hardware will automatically send the
frame data to the panel when it receives the TE event.
Signed-off-by: Vandita Kulkarni
---
drivers/gpu/drm/i915/display/icl_dsi.c | 26
Adding TE flags and periodic command mode flags
as part of private flags to indicate what TE interrupts
we would be getting instead of vblanks in case of mipi dsi
command mode.
v2: Add TE flag description (Jani)
Reviewed-by: Jani Nikula
Signed-off-by: Vandita Kulkarni
---
drivers/gpu/drm/i915/
Configure the transcoder to operate in TE GATE command mode
and take TE events from GPIO.
Also disable the periodic command mode, that GOP would have
programmed.
v2: Disable util pin (Jani)
Signed-off-by: Vandita Kulkarni
---
drivers/gpu/drm/i915/display/icl_dsi.c | 52
This series contains basic cmd mode enablemnet patches.
Vandita Kulkarni (9):
drm/i915/dsi: Configure transcoder operation for command mode.
drm/i915/dsi: Add vblank calculation for command mode
drm/i915/dsi: Add cmd mode flags in display mode private flags
drm/i915/dsi: Add check for peri
Clear the DSI IIR as part of interrupt configuration.
Signed-off-by: Vandita Kulkarni
---
drivers/gpu/drm/i915/i915_irq.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 028d4d66da8a..fabba515c274 100644
--- a/drive
In case of dual link, we get the TE on slave.
So clear the TE on slave DSI IIR.
v2: Pass only relevant masked bits to the handler (Jani)
v3: Fix the check for cmd mode in TE handler function.
Signed-off-by: Vandita Kulkarni
---
drivers/gpu/drm/i915/i915_irq.c | 64 +
Transcoder timing calculation differ for command mode.
v2: Use is_vid_mode, and use same I915_WRITE (Jani)
v3: Adjust the calculations to reflect dsc compression ratio
Signed-off-by: Vandita Kulkarni
---
drivers/gpu/drm/i915/display/icl_dsi.c | 52 +-
1 file changed, 35
If the GOP has programmed periodic command mode,
we need to disable that which would need a
deconfigure and configure sequence.
Signed-off-by: Vandita Kulkarni
---
drivers/gpu/drm/i915/display/icl_dsi.c | 23 +++
1 file changed, 23 insertions(+)
diff --git a/drivers/gpu/drm/
On dsi cmd mode we do not receive vblanks instead
we would get TE and these flags indicate TE is expected on
which port.
Signed-off-by: Vandita Kulkarni
---
drivers/gpu/drm/i915/display/icl_dsi.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/drivers/gpu/drm/i915/display
We need to configure TE interrupt in two places.
Port interrupt and DSI interrupt mask registers.
v2: Hide the private flags check inside configure_te (Jani)
v3: Fix the position of masking de_port_masked for DSI_TE.
Signed-off-by: Vandita Kulkarni
---
drivers/gpu/drm/i915/i915_irq.c | 55
== Series Details ==
Series: i915: fix backlight configuration issue
URL : https://patchwork.freedesktop.org/series/71766/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7703 -> Patchwork_16026
Summary
---
**SUCCESS**
On Wed, 08 Jan 2020, Chris Wilson wrote:
> Quoting Jani Nikula (2019-12-05 15:43:40)
>> +static int i915_param_int_open(struct inode *inode, struct file *file)
>> +{
>> + return single_open(file, i915_param_int_show, inode->i_private);
>
> What I've always wanted with this style of approach
On Tue, Jan 07, 2020 at 01:41:56AM +0800, Lee Shawn C wrote:
> Driver report physcial bandwidth for max dot clock rate.
> It would caused compatibility issue sometimes when physical
> bandwidth exceed MST hub output ability.
>
> For example, here is a MST hub with HDMI 1.4 and DP 1.2 output.
> And
On Wed, 08 Jan 2020, Arnd Bergmann wrote:
> The i915 driver can use the backlight subsystem as an option, and usually
> selects it when CONFIG_ACPI is set. However it is possible to configure
> a kernel with modular backlight classdev support and a built-in i915
> driver, which leads to a linker e
Access through the GGTT (iomap) into the vma does require the device to
be awake. However, we often take the i915_vma_pin_iomap() as an early
preparatory step that is long before we use the iomap. Asserting that
the device is awake at pin time does not protect us, and is merely a
nuisance.
Signed-
If we have no fence and desire no fence on the vma, return before we try
and take the vm->mutex.
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_gem_fence_reg.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_gem_fence_reg.c
b/driver
== Series Details ==
Series: drm/i915: Fix MST disable sequence (rev2)
URL : https://patchwork.freedesktop.org/series/71767/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7703 -> Patchwork_16027
Summary
---
**SUCCESS
== Series Details ==
Series: drm/i915: Pass cpu_transcoder to assert_pipe_disabled() always
URL : https://patchwork.freedesktop.org/series/71768/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.6.0
Commit: drm/i915: Pass cpu_transcoder to assert_pipe_disabled() alw
Quoting Ville Syrjala (2020-01-08 14:56:16)
> From: Ville Syrjälä
>
> I missed a few assert_pipe_disabled() cases when changing it to
> take enum transcoder instead of enum pipe, making sparse unhappy.
> Convert the leftovers.
>
> Reported-by: kbuild test robot
> Signed-off-by: Ville Syrjälä
>
On Wed, 2020-01-08 at 16:45 +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> When moving the pipe disable & co. function calls from
> haswell_crtc_disable() into the encoder .post_disable() hooks I
> neglected to account for the MST vs. DDI interactions properly.
> This now leads us to call
== Series Details ==
Series: drm/i915: Pass cpu_transcoder to assert_pipe_disabled() always
URL : https://patchwork.freedesktop.org/series/71768/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7703 -> Patchwork_16028
Summary
From: Tvrtko Ursulin
This reverts commit 08fff7aeddc9dd72161b4c8fc27fbab12b4b9352.
For some yet unexplained reason not having this improves stability of some
media workloads.
Promise is that the media hang will be root caused properly and in the
meantime absence of this workaround is unlikely t
On Wed, Jan 08, 2020 at 04:09:31PM +, Souza, Jose wrote:
> On Wed, 2020-01-08 at 16:45 +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > When moving the pipe disable & co. function calls from
> > haswell_crtc_disable() into the encoder .post_disable() hooks I
> > neglected to accoun
On Tue, 2020-01-07 at 07:13 +, Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915/display: Force the state compute phase once to
> enable PSR (rev4)
> URL : https://patchwork.freedesktop.org/series/7/
> State : success
>
> == Summary ==
>
> CI Bug Log - changes from CI_DRM_76
On Wed, Dec 18, 2019 at 12:25:35PM +0300, Alexey Budankov wrote:
>
> Open access to perf_events monitoring for CAP_SYS_PERFMON privileged
> processes. For backward compatibility reasons access to perf_events
> subsystem remains open for CAP_SYS_ADMIN privileged processes but
> CAP_SYS_ADMIN usage
Quoting Tvrtko Ursulin (2020-01-08 16:19:54)
> From: Tvrtko Ursulin
>
> This reverts commit 08fff7aeddc9dd72161b4c8fc27fbab12b4b9352.
>
> For some yet unexplained reason not having this improves stability of some
> media workloads.
>
> Promise is that the media hang will be root caused properly
On Wed, 2020-01-08 at 08:21 -0800, José Roberto de Souza wrote:
> On Tue, 2020-01-07 at 07:13 +, Patchwork wrote:
> > == Series Details ==
> >
> > Series: drm/i915/display: Force the state compute phase once to
> > enable PSR (rev4)
> > URL : https://patchwork.freedesktop.org/series/7/
>
On Wed, 2020-01-08 at 10:03 +, Patchwork wrote:
> == Series Details ==
>
> Series: series starting with [v4,rebased,1/2] drm/i915/display/icl+:
> Do not program clockgating
> URL : https://patchwork.freedesktop.org/series/71705/
> State : success
>
> == Summary ==
>
> CI Bug Log - changes
On Wed, Jan 08, 2020 at 02:26:50PM +0200, Stanislav Lisovskiy wrote:
> There seems to be some undocumented bandwidth
> bottleneck/dependency which scales with CDCLK,
> causing FIFO underruns when CDCLK is too low,
> even when it's correct from BSpec point of view.
>
> Currently for TGL platforms w
From: Ville Syrjälä
The strings we want to print to the on stack buffers should
be no more than
8 * 3 + strlen("(GET_SCALED_HDTV_RESOLUTION_SUPPORT)") + 1 = 61
bytes. So let's shrink the buffers down to 64 bytes.
Also switch the BUG_ON()s to WARN_ON()s if I made a mistake in
my arithmentic.
Sig
From: Ville Syrjälä
Move the force_dvi check to a single function that can be called from
both mode validation and compute_config(). Note that currently we
don't call it from mode validation, but that will change soon.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_sdvo.c
From: Ville Syrjälä
The code assumes that DRM_MODE_FLAG_DBLCLK means that we enable the
pixel repeat feature. That only works with HDMI since it requires
AVI infoframe to signal the information to the sink. Hence even if
the mode dotclock would be valid we cannot currently assume that
we can just
From: Ville Syrjälä
.get_modes() is supposed to return the number of modes added to the
probed_modes list (not that anyone actually checks for anything
except zero vs. not zero). Let's do that. Also switch over to using
intel_connector_update_modes() instead of hand rolling it.
Signed-off-by: Vi
From: Ville Syrjälä
The SDVO/HDMI port register limited color range bit can only be used
with TMDS encoding and not SDVO encoding, ie. to be used only when
using the port as a HDMI port as opposed to a SDVO port. The SDVO
spec does have a note that some GMCHs might allow that, but gen4
bspec vehe
From: Ville Syrjälä
With SDVO the pipe config pixel_multiplier only concerns itself with the
data on the SDVO bus. Any HDMI specific pixel repeat must be handled by
the SDVO device itself. To do that simply configure the SDVO pixel
replication factor appropriately. We already set up the infoframe
From: Ville Syrjälä
Move the force_dvi check to a single function that can be called from
both mode validation and compute_config().
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_hdmi.c | 49 ---
1 file changed, 26 insertions(+), 23 deletions(-)
diff
From: Ville Syrjälä
Fix up the SDVO colorimetry bits to match the spec.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_sdvo_regs.h | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_sdvo_regs.h
b/drivers/gpu/drm/
From: Ville Syrjälä
.get_modes() is supposed to return the number of modes added to the
probed_modes list (not that anyone actually checks for anything
except zero vs. not zero). Let's do that.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_dvo.c | 14 --
1 fil
On Wed, Jan 08, 2020 at 05:32:26PM +0200, Jani Nikula wrote:
> On Wed, 08 Jan 2020, Arnd Bergmann wrote:
> > The i915 driver can use the backlight subsystem as an option, and usually
> > selects it when CONFIG_ACPI is set. However it is possible to configure
> > a kernel with modular backlight cla
Hi Dave and Daniel,
Either our code is nearly perfect, or things are still slow due to holidays.
I'll choose to believe the former.
Please pull!
drm-misc-fixes-2020-01-08:
-mst: Fix NO_STOP_BIT bit offset (Wayne)
-sun4i: Fix RGB_DIV clock min divider on old hardware (Chen-Yu)
-fb_helper: Fix bi
On 1/7/20 2:32 AM, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2020-01-07 09:53:39)
+Arek, Saurabhg
On 05/01/2020 01:06, Chris Wilson wrote:
Since with multiple devices, we may have multiple different perf_pmu
each with their own type, we want to find the right one for the job.
The tests a
== Series Details ==
Series: linux-next: manual merge of the generic-ioremap tree with the drm-intel
tree
URL : https://patchwork.freedesktop.org/series/71736/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7699_full -> Patchwork_16021_full
The following changes since commit 67d4ff59bf3334895626cf165e508e9eb1846e24:
Mellanox: Add new mlxsw_spectrum firmware xx.2000.2714 (2020-01-07
09:08:25 -0500)
are available in the Git repository at:
git://anongit.freedesktop.org/drm/drm-firmware guc_v40
for you to fetch changes up to a0
On Jan. 8, 2020, 3:15 p.m, Ville Syrjala wrote:
>On Tue, Jan 07, 2020 at 01:41:56AM +0800, Lee Shawn C wrote:
>> Driver report physcial bandwidth for max dot clock rate.
>> It would caused compatibility issue sometimes when physical
>> bandwidth exceed MST hub output ability.
>>
>> For example, he
== Series Details ==
Series: series starting with [1/4] drm/i915: Pin the context as we work on it
URL : https://patchwork.freedesktop.org/series/71755/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7702_full -> Patchwork_16022_full
Link has not been trained during connector initialization
hence reset the variable intel_dp->link_trained. This
avoids accidently calling link training routine before the pipe
is set up.
Issue: https://gitlab.freedesktop.org/drm/intel/issues/585
Signed-off-by: Manasi Navare
Cc: Ville Syrjälä
Cc:
On Wed, 2019-12-04 at 20:05 +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Life is usually easier when we pass around intel_ types instead
> of drm_ types. In this case it might not be, but I think being
> consistent is a good thing anyway. Also some of this might get
> cleaned up a bit mo
87 matches
Mail list logo
