This patch parses HFVSDB fields for VRR capabilities of an
HDMI2.1 sink and stores the VRR caps in a new structure in
drm_hdmi_info.
Signed-off-by: Ankit Nautiyal
---
drivers/gpu/drm/drm_edid.c | 26 --
include/drm/drm_connector.h | 27 +++
2
== Series Details ==
Series: Move all drivers to a common dma-buf locking convention
URL : https://patchwork.freedesktop.org/series/109786/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_12251_full -> Patchwork_109786v1_full
On Mon, Oct 17, 2022 at 10:29:56AM -0700, Lucas De Marchi wrote:
On Tue, Oct 11, 2022 at 08:38:50AM -0700, Radhakrishna Sripada wrote:
Rename struct ip_version to intel_ip_version to comply with the
naming conventions for structures.
Suggested-by: Jani Nikula
Signed-off-by: Radhakrishna
On Mon, Oct 17, 2022 at 10:22:08AM -0700, Lucas De Marchi wrote:
On Mon, Oct 17, 2022 at 10:55:25AM +0200, Andrzej Hajda wrote:
GEN7_DOP_CLOCK_GATE_ENABLE bit should be cleared, not inverse.
The bug was introduced during conversion to intel_uncore_rmw helper.
Suggested-by: Matt Roper
Fixes:
On 10/17/2022 16:36, Teres Alexis, Alan Previn wrote:
Agreed on all the others (as per my other reply to Tvrtko), but on that 2nd
last one:
On Mon, 2022-10-17 at 12:33 -0700, Harrison, John C wrote:
On 10/14/2022 20:59, Alan Previn wrote:
If GuC is being used and we initialized
On 10/6/2022 2:38 PM, john.c.harri...@intel.com wrote:
From: John Harrison
A workaround was added to the driver to allow compute workloads to run
'forever' by disabling pre-emption on the RCS engine for Gen12.
It is not totally unbound as the heartbeat will kick in eventually
and cause a
== Series Details ==
Series: Enable YCbCr420 for VDSC (rev3)
URL : https://patchwork.freedesktop.org/series/109723/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_12251_full -> Patchwork_109723v3_full
Summary
---
On 10/6/2022 2:38 PM, john.c.harri...@intel.com wrote:
From: John Harrison
GuC converts the pre-emption timeout and timeslice quantum values into
clock ticks internally. That significantly reduces the point of 32bit
overflow. On current platforms, worst case scenario is approximately
110
On 10/12/2022 17:03, Daniele Ceraolo Spurio wrote:
Our current FW loading process is the same for all FWs:
- Pin FW to GGTT at the start of the ggtt->uc_fw node
- Load the FW
- Unpin
This worked because we didn't have a case where 2 FWs would be loaded on
the same GGTT at the same time. On
Agreed on all the others (as per my other reply to Tvrtko), but on that 2nd
last one:
On Mon, 2022-10-17 at 12:33 -0700, Harrison, John C wrote:
> On 10/14/2022 20:59, Alan Previn wrote:
> > If GuC is being used and we initialized GuC-error-capture,
> > we need to be warning if we don't provide
On 10/17/22 20:22, Dmitry Osipenko wrote:
> Hello,
>
> This series moves all drivers to a dynamic dma-buf locking specification.
> From now on all dma-buf importers are made responsible for holding
> dma-buf's reservation lock around all operations performed over dma-bufs
> in accordance to the
Hi all,
Today's linux-next merge of the drm-intel tree got a conflict in:
drivers/gpu/drm/i915/i915_driver.c
between commit:
1c66a12ab431 ("drm/i915: Handle each GT on init/release and suspend/resume")
from Linus' tree and commit:
3703060d17b0 ("drm/i915/display: remove drm_device
== Series Details ==
Series: Add DG2 OA support (rev7)
URL : https://patchwork.freedesktop.org/series/107584/
State : failure
== Summary ==
Error: make failed
CALLscripts/checksyscalls.sh
DESCEND objtool
CC [M] drivers/gpu/drm/i915/i915_perf.o
In file included from
== Series Details ==
Series: drm: Analog TV Improvements (rev5)
URL : https://patchwork.freedesktop.org/series/107892/
State : failure
== Summary ==
Error: patch
https://patchwork.freedesktop.org/api/1.0/series/107892/revisions/5/mbox/ not
applied
Applying: drm/tests: Add Kunit Helpers
== Series Details ==
Series: Defeature Interlace modes for Display >= 12
URL : https://patchwork.freedesktop.org/series/109773/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_12251_full -> Patchwork_109773v1_full
Summary
== Series Details ==
Series: drm/i915: Replace kmap() with kmap_local_page() (rev2)
URL : https://patchwork.freedesktop.org/series/107277/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12252 -> Patchwork_107277v2
Summary
== Series Details ==
Series: drm/i915: Replace kmap() with kmap_local_page() (rev2)
URL : https://patchwork.freedesktop.org/series/107277/
State : warning
== Summary ==
Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
On Fri, 14 Oct 2022 20:26:18 -0700, Ashutosh Dixit wrote:
>
> From: Badal Nilawar
Hi Badal,
One question below.
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c
> b/drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c
> index 1fb053cbf52db..3a9bb4387248e 100644
> ---
== Series Details ==
Series: drm/i915: Extend Wa_1607297627 to Alderlake-P
URL : https://patchwork.freedesktop.org/series/109772/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_12251_full -> Patchwork_109772v1_full
Summary
By crash, I mean that an error is returned here:
https://kernel.googlesource.com/pub/scm/linux/kernel/git/torvalds/linux.git/+/refs/heads/master/drivers/gpu/drm/drm_edid_load.c#195
I don't really know what happens next, but on my machine the built-in
screen and the external remains dark. Also
Hi Maxime,
Sorry about the mess that happened to the previous message. I hope this one
will be delivered more cleanly.
W dniu 13.10.2022 o 15:19, Maxime Ripard pisze:
> From: Mateusz Kwiatkowski
>
> The VEC can accept pretty much any relatively reasonable mode, but still
> has a bunch of
Add support for the PAL-60 mode. Because there is no separate TV mode
property value for PAL-60, this requires matching the settings based on
the modeline in addition to just that property alone.
Signed-off-by: Mateusz Kwiatkowski
---
This patch depends on patch
'[PATCH v5 21/22] drm/vc4: vec:
Hi Maxime,
W dniu 13.10.2022 o 15:19, Maxime Ripard pisze:
> From: Mateusz Kwiatkowski
>
> Add support for the following composite output modes (all of them are
> somewhat more obscure than the previously defined ones):
>
> - NTSC_443 - NTSC-style signal with the chroma subcarrier shifted to
>
Hi Maxime,
Urgh. I cannot send e-mails apparently today, as I removed the second half of
the previous message. Here goes:
> @@ -454,13 +563,6 @@ static int vc4_vec_encoder_atomic_check(struct
> drm_encoder *encoder,
> struct drm_connector_state *conn_state)
kmap() is being deprecated in favor of kmap_local_page().
There are two main problems with kmap(): (1) It comes with an overhead as
mapping space is restricted and protected by a global lock for
synchronization and (2) it also requires global TLB invalidation when the
kmap’s pool wraps and it
It should fix the issue. Meanwhile, the system will still crash if a
new monitor is plugged while the machine is suspended. We might need to
precache the EDID to prevent that.
Matthieu
On Fri, Oct 7 2022 at 01:21:46 AM +0300, Jani Nikula
wrote:
We've used a temporary platform device for
Hi Maxime, Noralf & everyone,
I'd like to address Noralf here in particular, and refer to these discussions
from the past:
-
https://lore.kernel.org/linux-arm-kernel/2f607c7d-6da1-c8df-1c02-8dd344a92...@gmail.com/
-
Hi Maxime,
W dniu 13.10.2022 o 15:19, Maxime Ripard pisze:
> From: Mateusz Kwiatkowski > > The VEC can accept pretty much any relatively
> reasonable mode, but still > has a bunch of constraints to meet. > > Let's
> create an atomic_check() implementation that will make sure we > don't end up
Dne petek, 14. oktober 2022 ob 09:38:10 CEST je Maxime Ripard napisal(a):
> Hi Jernej,
>
> On Thu, Oct 13, 2022 at 08:23:51PM +0200, Jernej Škrabec wrote:
> > Dne četrtek, 13. oktober 2022 ob 15:19:06 CEST je Maxime Ripard
napisal(a):
> > > Now that the core can deal fine with analog TV modes,
Hi Maxime & everyone,
Sorry for being inactive in the discussions about this patchset for the last
couple of weeks.
> +const static struct analog_parameters tv_modes_parameters[] = {
> + TV_MODE_PARAMETER(DRM_MODE_ANALOG_NTSC,
> + NTSC_LINES_NUMBER,
> +
Hi Maxime,
Dne četrtek, 13. oktober 2022 ob 15:19:06 CEST je Maxime Ripard napisal(a):
> Now that the core can deal fine with analog TV modes, let's convert the
> sun4i TV driver to leverage those new features.
>
> Acked-by: Noralf Trønnes
> Signed-off-by: Maxime Ripard
>
> ---
> Changes in
kmap() is being deprecated in favor of kmap_local_page().
There are two main problems with kmap(): (1) It comes with an overhead as
mapping space is restricted and protected by a global lock for
synchronization and (2) it also requires global TLB invalidation when the
kmap’s pool wraps and it
kmap() is being deprecated in favor of kmap_local_page().
There are two main problems with kmap(): (1) It comes with an overhead as
mapping space is restricted and protected by a global lock for
synchronization and (2) it also requires global TLB invalidation when the
kmap’s pool wraps and it
kmap() is being deprecated in favor of kmap_local_page().
There are two main problems with kmap(): (1) It comes with an overhead as
mapping space is restricted and protected by a global lock for
synchronization and (2) it also requires global TLB invalidation when the
kmap’s pool wraps and it
Currently the EDID is requested during the resume. But since it's
requested too early, this means before the filesystem is mounted, the
firmware request fails. This make the DRM driver crash when resuming.
This kind of issue should be prevented by the firmware caching process
which cache every
Hi Maxime,
> static int vc4_vec_connector_get_modes(struct drm_connector *connector)
> {
> - struct drm_connector_state *state = connector->state;
> struct drm_display_mode *mode;
>
> - mode = drm_mode_duplicate(connector->dev,
> -
On 10/14/2022 20:59, Alan Previn wrote:
If GuC is being used and we initialized GuC-error-capture,
we need to be warning if we don't provide an error-capture
register list in the firmware ADS, for valid GT engines.
A warning makes sense as this would impact debugability
without realizing why a
Filed a new issue and re-reported.
https://gitlab.freedesktop.org/drm/intel/-/issues/7230
igt@kms_async_flips@async-flip-with-page-flip-events@.* - fail - Failed
assertion: (fps / 1000) > (data->refresh_rate * MIN_FLIPS_PER_FRAME), FPS
should be significantly higher than the refresh rate
== Series Details ==
Series: Move all drivers to a common dma-buf locking convention
URL : https://patchwork.freedesktop.org/series/109786/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12251 -> Patchwork_109786v1
Summary
== Series Details ==
Series: Move all drivers to a common dma-buf locking convention
URL : https://patchwork.freedesktop.org/series/109786/
State : warning
== Summary ==
Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
On Mon, 2022-10-17 at 09:42 +0100, Tvrtko Ursulin wrote:
> On 15/10/2022 04:59, Alan Previn wrote:
> > If GuC is being used and we initialized GuC-error-capture,
> > we need to be warning if we don't provide an error-capture
> > register list in the firmware ADS, for valid GT engines.
> > A
On Mon, Oct 17, 2022 at 09:17:51AM -0700, Matt Roper wrote:
> On Sat, Oct 15, 2022 at 01:03:31AM +, Patchwork wrote:
> > == Series Details ==
> >
> > Series: Explicit MCR handling and MTL steering (rev4)
> > URL : https://patchwork.freedesktop.org/series/108755/
> > State : failure
> >
> >
ADL-P doesnt support CCS and DG2 is stll force-probe (so hoping to get this
before DG2 goes live).
...alan
On Mon, 2022-10-17 at 09:43 +0100, Tvrtko Ursulin wrote:
> On 15/10/2022 04:59, Alan Previn wrote:
> > Add compute reglist for GuC error capture.
> >
> > Signed-off-by: Alan Previn
> >
On Tue, Oct 11, 2022 at 08:38:50AM -0700, Radhakrishna Sripada wrote:
Rename struct ip_version to intel_ip_version to comply with the
naming conventions for structures.
Suggested-by: Jani Nikula
Signed-off-by: Radhakrishna Sripada
Reviewed-by: Lucas De Marchi
Lucas De Marchi
The internal dma-buf lock isn't needed anymore because the updated
locking specification claims that dma-buf reservation must be locked
by importers, and thus, the internal data is already protected by the
reservation lock. Remove the obsoleted internal lock.
Acked-by: Sumit Semwal
Acked-by:
All drivers that use dma-bufs have been moved to the updated locking
specification and now dma-buf reservation is guaranteed to be locked
by importers during the mapping operations. There is no need to take
the internal dma-buf lock anymore. Remove locking from the videobuf2
memory allocators.
Add documentation for the dynamic locking convention. The documentation
tells dma-buf API users when they should take the reservation lock and
when not.
Acked-by: Sumit Semwal
Reviewed-by: Christian König
Signed-off-by: Dmitry Osipenko
---
Documentation/driver-api/dma-buf.rst | 6 +++
Move dma-buf attachment API functions to the dynamic locking specification
by taking the reservation lock around the mapping operations. The strict
locking convention prevents deadlock situations for dma-buf importers and
exporters.
Acked-by: Sumit Semwal
Reviewed-by: Christian König
Move dma_buf_mmap() function to the dynamic locking specification by
taking the reservation lock. Neither of the today's drivers take the
reservation lock within the mmap() callback, hence it's safe to enforce
the locking.
Acked-by: Sumit Semwal
Acked-by: Christian König
Signed-off-by: Dmitry
Move dma-buf attachment mapping functions to the dynamic locking
specification by asserting that the reservation lock is held.
Acked-by: Sumit Semwal
Reviewed-by: Christian König
Signed-off-by: Dmitry Osipenko
---
drivers/dma-buf/dma-buf.c | 10 ++
1 file changed, 2 insertions(+), 8
Prepare fastrpc to the common dynamic dma-buf locking convention by
starting to use the unlocked versions of dma-buf API functions.
Acked-by: Christian König
Acked-by: Srinivas Kandagatla
Signed-off-by: Dmitry Osipenko
---
drivers/misc/fastrpc.c | 6 +++---
1 file changed, 3 insertions(+), 3
Prepare gntdev driver to the common dynamic dma-buf locking convention
by starting to use the unlocked versions of dma-buf API functions.
Acked-by: Juergen Gross
Acked-by: Christian König
Signed-off-by: Dmitry Osipenko
---
drivers/xen/gntdev-dmabuf.c | 8
1 file changed, 4
Move dma_buf_vmap/vunmap() functions to the dynamic locking
specification by asserting that the reservation lock is held.
Acked-by: Sumit Semwal
Acked-by: Christian König
Signed-off-by: Dmitry Osipenko
---
drivers/dma-buf/dma-buf.c | 4
1 file changed, 4 insertions(+)
diff --git
Prepare Etnaviv driver to the common dynamic dma-buf locking convention
by starting to use the unlocked versions of dma-buf API functions.
Acked-by: Christian König
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c | 2 +-
1 file changed, 1 insertion(+), 1
Prepare Tegra video decoder driver to the common dynamic dma-buf
locking convention by starting to use the unlocked versions of dma-buf
API functions.
Acked-by: Christian König
Signed-off-by: Dmitry Osipenko
---
drivers/media/platform/nvidia/tegra-vde/dmabuf-cache.c | 6 +++---
1 file changed,
Prepare V4L2 memory allocators to the common dynamic dma-buf locking
convention by starting to use the unlocked versions of dma-buf API
functions.
Acked-by: Tomasz Figa
Acked-by: Christian König
Signed-off-by: Dmitry Osipenko
---
drivers/media/common/videobuf2/videobuf2-dma-contig.c | 11
Prepare InfiniBand drivers to the common dynamic dma-buf locking
convention by starting to use the unlocked versions of dma-buf API
functions.
Acked-by: Jason Gunthorpe
Acked-by: Christian König
Signed-off-by: Dmitry Osipenko
---
drivers/infiniband/core/umem_dmabuf.c | 7 ---
1 file
Prepare Tegra DRM driver to the common dynamic dma-buf locking convention
by starting to use the unlocked versions of dma-buf API functions.
Acked-by: Christian König
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/tegra/gem.c | 17 +
1 file changed, 9 insertions(+), 8
Prepare OMAP DRM driver to the common dynamic dma-buf locking convention
by starting to use the unlocked versions of dma-buf API functions.
Acked-by: Christian König
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c | 4 ++--
1 file changed, 2 insertions(+), 2
Prepare i915 driver to the common dynamic dma-buf locking convention
by starting to use the unlocked versions of dma-buf API functions
and handling cases where importer now holds the reservation lock.
Acked-by: Christian König
Reviewed-by: Michael J. Ruhl
Signed-off-by: Dmitry Osipenko
---
Prepare Armada driver to the common dynamic dma-buf locking convention
by starting to use the unlocked versions of dma-buf API functions.
Acked-by: Christian König
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/armada/armada_gem.c | 8
1 file changed, 4 insertions(+), 4
Prepare DRM prime core to the common dynamic dma-buf locking convention
by starting to use the unlocked versions of dma-buf API functions.
Reviewed-by: Christian König
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/drm_prime.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
Add unlocked variant of dma_buf_map/unmap_attachment() that will
be used by drivers that don't take the reservation lock explicitly.
Acked-by: Sumit Semwal
Acked-by: Christian König
Signed-off-by: Dmitry Osipenko
---
drivers/dma-buf/dma-buf.c | 53 +++
The new common dma-buf locking convention will require buffer importers
to hold the reservation lock around mapping operations. Make DRM GEM core
to take the lock around the vmapping operations and update DRM drivers to
use the locked functions for the case where DRM core now holds the lock.
This
Add unlocked variant of dma_buf_vmap/vunmap() that will be utilized
by drivers that don't take the reservation lock explicitly.
Acked-by: Sumit Semwal
Acked-by: Christian König
Signed-off-by: Dmitry Osipenko
---
drivers/dma-buf/dma-buf.c | 43 +++
Hello,
This series moves all drivers to a dynamic dma-buf locking specification.
>From now on all dma-buf importers are made responsible for holding
dma-buf's reservation lock around all operations performed over dma-bufs
in accordance to the locking specification. This allows us to utilize
On Mon, Oct 17, 2022 at 10:55:25AM +0200, Andrzej Hajda wrote:
GEN7_DOP_CLOCK_GATE_ENABLE bit should be cleared, not inverse.
The bug was introduced during conversion to intel_uncore_rmw helper.
Suggested-by: Matt Roper
Fixes: 8cee664d3eb6f8 ("drm/i915: use proper helper for register updates")
On Thu, 2022-10-13 at 14:10 -0700, Ceraolo Spurio, Daniele wrote:
>
> On 10/5/2022 9:38 PM, Alan Previn wrote:
> > Make intel_pxp_is_enabled implicitly find the PXP-owning-GT.
> > PXP feature support is a device-config flag. In preparation for MTL
> > PXP control-context shall reside on of the
On 14.10.2022 16:02, Matt Roper wrote:
> MTL's media IP (Xe_LPM+) only has a single type of steering ("OAADDRM")
> which selects between media slice 0 and media slice 1. We'll always
> steer to media slice 0 unless it is fused off (which is the case when
> VD0, VE0, and SFC0 are all reported as
On 14.10.2022 16:02, Matt Roper wrote:
> MTL's graphics IP (Xe_LPG) once again changes the multicast register
> types and steering details. Key changes from past platforms:
> * The number of instances of some MCR types (NODE, OAAL2, and GAM) vary
>according to the MTL subplatform and cannot
On Thu, 2022-10-13 at 13:48 -0700, Ceraolo Spurio, Daniele wrote:
>
> On 10/5/2022 9:38 PM, Alan Previn wrote:
> > In preparation for future MTL-PXP feature support, PXP control
> > context should only valid on the correct gt tile. Depending on the
> > device-info this mat not necessarily be
On 14.10.2022 16:02, Matt Roper wrote:
> Rather than treating multicast registers as 'i915_reg_t' let's define
> them as a completely new type. This will allow the compiler to help us
> make sure we're using multicast-aware functions to operate on multicast
> registers.
>
> This plan does break
On 14.10.2022 16:02, Matt Roper wrote:
> Let's be more explicit about which of our workarounds are updating MCR
> registers.
>
> Signed-off-by: Matt Roper
> ---
> drivers/gpu/drm/i915/gt/intel_workarounds.c | 433 +++---
> .../gpu/drm/i915/gt/intel_workarounds_types.h | 4 +-
>
On 14.10.2022 16:02, Matt Roper wrote:
> MCR registers can be placed on the GuC's save/restore list, but at the
> moment they are always handled in a multicast manner (i.e., the GuC
> reads one instance to save the value and then does a multicast write to
> restore that single value to all
On 14.10.2022 16:02, Matt Roper wrote:
> Rather than relying on the implicit behavior of intel_uncore_*()
> functions, let's always use the intel_gt_mcr_*() functions to operate on
> multicast/replicated registers.
>
> v2:
> - Add TLB invalidation registers
>
> v3:
> - Switch more uncore
On 14.10.2022 16:02, Matt Roper wrote:
> Rather than using the same _MMIO() macro to define MCR registers as
> singleton registers, let's use a new MCR_REG() macro to make it clear
> that these registers are special and should be handled accordingly. For
> now MCR_REG() will still generate an
On 14.10.2022 16:02, Matt Roper wrote:
> Xe_HP has some MCR registers that need to be polled for completion of
> operations like TLB invalidation. Those registers are in the GAM range,
> which rolls up the status from each unit into the 'primary' instance's
> value. This makes it useful to have
On 14.10.2022 16:02, Matt Roper wrote:
> On Xe_HP the fault registers are now in a multicast register range.
> However as part of the GAM these registers follow special rules and we
> need only read from the "primary" GAM's instance to get the information
> we need. So a single
On 14.10.2022 16:02, Matt Roper wrote:
> There are cases where we wish to read from any non-terminated MCR
> register instance (or the primary instance in the case of GAM ranges),
> clear/set some bits, and then write the value back out to the register
> in a multicast manner. Adding a "multicast
On 14.10.2022 16:02, Matt Roper wrote:
> We have a few registers that have existed for several hardware
> generations, but are only used by the driver on Xe_HP and beyond. In
> cases where the Xe_HP version of the register is now replicated and uses
> multicast behavior, but earlier generations
On 14.10.2022 16:02, Matt Roper wrote:
> Let's drop a few register definitions that are unused anywhere in the
> driver today. Since the referenced offsets are part of what is now
> considered a multicast register region, the current definitions would
> not be correct for use on any future
On 14.10.2022 16:02, Matt Roper wrote:
> Starting in Xe_HP, several registers our driver works with have been
> converted from singleton registers into replicated registers with
> multicast behavior. Although the registers are still located at the
> same MMIO offsets as on previous platforms,
On 14.10.2022 16:02, Matt Roper wrote:
> Gen8 was the first time our hardware had multicast registers (or at
> least the first time the multicast nature was exposed and MMIO accesses
> could be steered). There are some registers that transitioned from
> singleton behavior to multicast during the
== Series Details ==
Series: x86/hyperv: Replace kmap() with kmap_local_page()
URL : https://patchwork.freedesktop.org/series/109762/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_12251_full -> Patchwork_109762v1_full
On Sat, Oct 15, 2022 at 01:03:31AM +, Patchwork wrote:
> == Series Details ==
>
> Series: Explicit MCR handling and MTL steering (rev4)
> URL : https://patchwork.freedesktop.org/series/108755/
> State : failure
>
> == Summary ==
>
> CI Bug Log - changes from CI_DRM_12242_full ->
== Series Details ==
Series: Enable YCbCr420 for VDSC (rev3)
URL : https://patchwork.freedesktop.org/series/109723/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12251 -> Patchwork_109723v3
Summary
---
**SUCCESS**
== Series Details ==
Series: drm/i915: fix clear mask in GEN7_MISCCPCTL update
URL : https://patchwork.freedesktop.org/series/109757/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_12251_full -> Patchwork_109757v1_full
== Series Details ==
Series: Defeature Interlace modes for Display >= 12
URL : https://patchwork.freedesktop.org/series/109773/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12251 -> Patchwork_109773v1
Summary
---
Hi,
On 10/17/22 15:35, Jani Nikula wrote:
> On Mon, 17 Oct 2022, Hans de Goede wrote:
>> Hi,
>>
>> On 10/17/22 13:19, Thorsten Leemhuis wrote:
>>> CCing the regression mailing list, as it should be in the loop for all
>>> regressions, as explained here:
>>>
Since the DP/HDMI connector do not set connector->doublescan_allowed,
the doublescan modes will get automatically filtered during
drm_helper_probe_single_connector_modes().
Therefore check for double scan modes is not required and is dropped
from modevalid functions for both DP and HDMI.
Defeature Display Interlace support.
Support for interlace modes is removed from Gen 12 onwards.
Pruning the interlace modes for HDMI for Display >=12.
Bspec: 50490
v2: Add check for both DP and HDMI. (Ville)
Get rid of redundant check for interlace mode in modevalid. (Ville)
Signed-off-by:
This patch series is a contination of patch:
https://patchwork.freedesktop.org/patch/506835/?series=109646=1
Added change for DP as well as HDMI in the patch series.
Also added a clean up patch to remove check for doublescan modes
as that is no longer required.
Ankit Nautiyal (2):
== Series Details ==
Series: drm/i915: Extend Wa_1607297627 to Alderlake-P
URL : https://patchwork.freedesktop.org/series/109772/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12251 -> Patchwork_109772v1
Summary
---
On 17/10/2022 14:24, José Roberto de Souza wrote:
Workaround 1607297627 was missed for Alderlake-P, so here extending it
to it and adding the fixes tag so this WA is backported to all
stable kernels.
v2:
- fixed subject
- added Fixes tag
BSpec: 54369
Fixes: dfb924e33927 ("drm/i915/adlp:
On Mon, 17 Oct 2022, Hans de Goede wrote:
> Hi,
>
> On 10/17/22 13:19, Thorsten Leemhuis wrote:
>> CCing the regression mailing list, as it should be in the loop for all
>> regressions, as explained here:
>> https://www.kernel.org/doc/html/latest/admin-guide/reporting-issues.html
>
> Yes sorry
Workaround 1607297627 was missed for Alderlake-P, so here extending it
to it and adding the fixes tag so this WA is backported to all
stable kernels.
v2:
- fixed subject
- added Fixes tag
BSpec: 54369
Fixes: dfb924e33927 ("drm/i915/adlp: Remove require_force_probe protection")
Reviewed-by: Lucas
== Series Details ==
Series: Enable YCbCr420 for VDSC (rev3)
URL : https://patchwork.freedesktop.org/series/109723/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_12251 -> Patchwork_109723v3
Summary
---
**FAILURE**
Hi,
On 10/17/22 13:19, Thorsten Leemhuis wrote:
> CCing the regression mailing list, as it should be in the loop for all
> regressions, as explained here:
> https://www.kernel.org/doc/html/latest/admin-guide/reporting-issues.html
Yes sorry about that I meant to Cc the regressions list, not you
== Series Details ==
Series: Enable YCbCr420 for VDSC (rev3)
URL : https://patchwork.freedesktop.org/series/109723/
State : warning
== Summary ==
Error: dim checkpatch failed
55621de03fe4 drm/i915/dp: Check if DSC supports the given output_format
4f0091385d61 drm/i915: Adding the new
On Mon, 10 Oct 2022, Animesh Manna wrote:
> From display gen12 onwards to support dual EDP two instances of pps added.
> Currently backlight controller and pps instance can be mapped together
> for a specific panel. Currently dual PPS support is broken. This patch fixes
> it and enables for
1 - 100 of 144 matches
Mail list logo
