✓ Fi.CI.BAT: success for Revert "drm/i915/mtl: Update workaround 14018778641"

== Series Details == Series: Revert "drm/i915/mtl: Update workaround 14018778641" URL : https://patchwork.freedesktop.org/series/128860/ State : success == Summary == CI Bug Log - changes from CI_DRM_14129 -> Patchwork_128860v1 Summary

[PATCH] drm/i915/lnl: Block pkgC entry for performance improvemnt

For High refresh rates usages, Vblank is required to be really small. It cannot accommodate PKGC exit delay after framestart. Block PKGC till next framestart which will be set by software and later will be cleared by HW at framestart. Cc: Mitul Golani Signed-off-by: Animesh Manna --- drivers/gp

[PATCH] Revert "drm/i915/mtl: Update workaround 14018778641"

Applying WA 14018778641 only on Compute engine has impact on Chrome related apps. Reverting this patch and applying WA to all engines is helping with performance on Chrome related apps. Signed-off-by: Tejas Upadhyay --- drivers/gpu/drm/i915/gt/intel_workarounds.c | 3 +++ 1 file changed, 3 inser

Re: Rework TTMs busy handling

On Tue, Jan 16, 2024 at 4:57 AM Christian König wrote: > > Am 12.01.24 um 13:51 schrieb Christian König: > > Hi guys, > > just a gentle ping on this. > > Zack any more comments for the VMWGFX parts? The new vmwgfx code looks great, thanks a lot for implementing it! In fact the entire series looks

Re: [Intel-gfx] [PATCH] drm/i915: Fix bigjoiner case for DP2.0

Hi Stan, Ville, After Stan's refactor series for bigjoiner, along with Vidya's patch that assigns master/slave for MST as well, do you anticipate more MST specific bigjoiner modeset sequence changes to properly call crtc enable sequence for MST master slave? Stan, when you send the next revision

Re: [PATCH 1/3] drm/i915: Add bigjoiner force enable option to debugfs

Thanks Stan for the patch. I agree that since by forcing big joiner enable we are simulating a higher mode/pixel clock on a connector, this should be a per connector debugfs except for edp that can be exposed. Manasi On Mon, Jan 15, 2024 at 12:57 AM Lisovskiy, Stanislav wrote: > > On Fri, Jan 12

✗ Fi.CI.BAT: failure for Enable Wa_14019159160 and Wa_16019325821 for MTL (rev4)

== Series Details == Series: Enable Wa_14019159160 and Wa_16019325821 for MTL (rev4) URL : https://patchwork.freedesktop.org/series/123813/ State : failure == Summary == CI Bug Log - changes from CI_DRM_14129 -> Patchwork_123813v4 Summary -

✗ Fi.CI.SPARSE: warning for Enable Wa_14019159160 and Wa_16019325821 for MTL (rev4)

== Series Details == Series: Enable Wa_14019159160 and Wa_16019325821 for MTL (rev4) URL : https://patchwork.freedesktop.org/series/123813/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.

✗ Fi.CI.CHECKPATCH: warning for Enable Wa_14019159160 and Wa_16019325821 for MTL (rev4)

== Series Details == Series: Enable Wa_14019159160 and Wa_16019325821 for MTL (rev4) URL : https://patchwork.freedesktop.org/series/123813/ State : warning == Summary == Error: dim checkpatch failed ec3446feff7a drm/i915: Enable Wa_16019325821 bf6a08a364a0 drm/i915/guc: Add support for w/a KLV

✓ Fi.CI.BAT: success for Revert "drm/i915/dsi: Do display on sequence later on icl+"

== Series Details == Series: Revert "drm/i915/dsi: Do display on sequence later on icl+" URL : https://patchwork.freedesktop.org/series/128847/ State : success == Summary == CI Bug Log - changes from CI_DRM_14129 -> Patchwork_128847v1 Summa

✗ Fi.CI.BAT: failure for drm/i915: Cursor vblank evasion (rev3)

== Series Details == Series: drm/i915: Cursor vblank evasion (rev3) URL : https://patchwork.freedesktop.org/series/127744/ State : failure == Summary == CI Bug Log - changes from CI_DRM_14129 -> Patchwork_127744v3 Summary --- **FAILU

✗ Fi.CI.SPARSE: warning for drm/i915: Cursor vblank evasion (rev3)

== Series Details == Series: drm/i915: Cursor vblank evasion (rev3) URL : https://patchwork.freedesktop.org/series/127744/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately. +./arch/x86/include/asm/bitops.h:116

[PATCH] Revert "drm/i915/dsi: Do display on sequence later on icl+"

From: Ville Syrjälä This reverts commit 88b065943cb583e890324d618e8d4b23460d51a3. Lenovo 82TQ is unhappy if we do the display on sequence this late. The display output shows severe corruption. It's unclear if this is a failure on our part (perhaps something to do with sending commands in LP mod

[PATCH v2 8/9] drm/i915: Perform vblank evasion around legacy cursor updates

From: Ville Syrjälä Our legacy cursor updates are actually mailbox updates. Ie. the hardware latches things once per frame on start of vblank, but we issue an number of updates per frame, withough any attempt to synchronize against the vblank in software. So in theory only the last update issued

✗ Fi.CI.BAT: failure for drm/i915/gt: Reflect the true and current status of rc6_enable

== Series Details == Series: drm/i915/gt: Reflect the true and current status of rc6_enable URL : https://patchwork.freedesktop.org/series/128839/ State : failure == Summary == CI Bug Log - changes from CI_DRM_14128 -> Patchwork_128839v1 Su

✗ Fi.CI.BUILD: failure for drm/xe/guc: Extract GuC error capture lists on G2H notification

== Series Details == Series: drm/xe/guc: Extract GuC error capture lists on G2H notification URL : https://patchwork.freedesktop.org/series/128837/ State : failure == Summary == Error: patch https://patchwork.freedesktop.org/api/1.0/series/128837/revisions/1/mbox/ not applied Applying: drm/x

[PATCH] drm/i915/gt: Reflect the true and current status of rc6_enable

The sysfs file is named 'enabled', thus users might want to know the true state of the RC6 instead of only the indication if the RC6 should be enabled. Let's use rc6.enable directly instead of rc6.supported. Signed-off-by: Juan Escamilla --- drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c | 4 ++--

Re: [PATCH v2] drm/xe/guc: Add GuC based register capture for error capture

Please ignore this patch The patch is for Xe upstream, sent to wrong ML. Regards, Zhanjun On 2024-01-16 12:12 p.m., Zhanjun Dong wrote: Port GuC based register capture for error capture from i915 to Xe. There are 3 parts in this commit: . Prepare for capture registers There is a bo creat

[PATCH] drm/xe/guc: Extract GuC error capture lists on G2H notification

Upon the G2H Notify-Err-Capture event, parse through the GuC Log Buffer (error-capture-subregion) and generate one or more capture-nodes. A single node represents a single "engine- instance-capture-dump" and contains at least 3 register lists: global, engine-class and engine-instance. An internal l

[PATCH] drm/xe/guc: Add capture size check in GuC log buffer

The capture-nodes is included in GuC log buffer, add the size check for capture region in the whole GuC log buffer. Signed-off-by: Zhanjun Dong --- drivers/gpu/drm/xe/xe_gt_printk.h | 3 + drivers/gpu/drm/xe/xe_guc_fwif.h | 48 +++ drivers/gpu/drm/xe/xe_guc_log.c | 179

[PATCH] drm/xe/guc: Pre-allocate output nodes for extraction

Pre-allocate a fixed number of empty nodes up front (at the time of ADS registration) that we can consume from or return to an internal cached list of nodes. Signed-off-by: Zhanjun Dong --- drivers/gpu/drm/xe/xe_guc_capture.c | 83 + 1 file changed, 83 insertions(+)

[PATCH] drm/xe/guc: Add register defines for GuC based register capture

Add registers defines and list of registers for GuC based error state capture. Signed-off-by: Zhanjun Dong --- drivers/gpu/drm/xe/Kconfig | 11 +++ drivers/gpu/drm/xe/Makefile | 1 + drivers/gpu/drm/xe/regs/xe_engine_regs.h | 12 +++ drivers/gpu/drm/xe/regs/xe_gt_r

[PATCH] drm/xe/guc: Plumb GuC-capture into dev coredump

Add xe_hw_engine_snapshot_from_capture to take snapshot from capture node list. Add data struct to map register to a snapshot field, although all field is mapped now, which means the offset could be optimized, while in the future, depends on system configuration, the field might not be consecutive.

[PATCH] drm/xe/guc: Check sizing of guc_capture output

Add capture output size check function to provide a reasonable minimum size for error capture region before allocating the shared buffer. Signed-off-by: Zhanjun Dong --- drivers/gpu/drm/xe/xe_guc_capture.c | 76 + 1 file changed, 76 insertions(+) diff --git a/drivers

[PATCH] drm/xe/guc: Add XE_LP steered register lists

Add the ability for runtime allocation and freeing of steered register list extentions that depend on the detected HW config fuses. Signed-off-by: Zhanjun Dong --- drivers/gpu/drm/xe/xe_guc_capture.c | 187 +++- 1 file changed, 185 insertions(+), 2 deletions(-) diff --gi

[PATCH] drm/xe/guc: Expose dss per group for GuC error capture

Expose helper for dss per group of mcr, GuC error capture feature need this info to prepare buffer required. Signed-off-by: Zhanjun Dong --- drivers/gpu/drm/xe/xe_gt_mcr.c | 4 ++-- drivers/gpu/drm/xe/xe_gt_mcr.h | 1 + drivers/gpu/drm/xe/xe_gt_topology.c | 3 --- driver

[PATCH] drm/xe/guc: Update GuC ADS size for error capture

Update GuC ADS size allocation to include space for the lists of error state capture register descriptors. Then, populate GuC ADS with the lists of registers we want GuC to report back to host on engine reset events. This list should include global, engine-class and engine-instance registers for e

[PATCH v2] drm/xe/guc: Add GuC based register capture for error capture

Port GuC based register capture for error capture from i915 to Xe. There are 3 parts in this commit: . Prepare for capture registers There is a bo create at guc ads init time, that is very early and engine map is not ready, make it hard to calculate the capture buffer size, new functio

Re: [3/3] ASoC: hdmi-codec: drop drm/drm_edid.h include

On Fri, 12 Jan 2024, "Sarha, Jyri" wrote: > Reviewed-by: > > Thanks, > The including of drm_edid.h in hdmi-codec.h is a relic from my pre > upstreaming version of hdmi-codec. I don't think it was ever needed > in any upsteam version. Thanks for the reviews and acks, pushed to drm-misc-next, even

✗ Fi.CI.IGT: failure for drm: drm debug and error logging improvements (rev2)

== Series Details == Series: drm: drm debug and error logging improvements (rev2) URL : https://patchwork.freedesktop.org/series/126873/ State : failure == Summary == CI Bug Log - changes from CI_DRM_14127_full -> Patchwork_126873v2_full Su

✓ Fi.CI.BAT: success for drm: drm debug and error logging improvements (rev2)

== Series Details == Series: drm: drm debug and error logging improvements (rev2) URL : https://patchwork.freedesktop.org/series/126873/ State : success == Summary == CI Bug Log - changes from CI_DRM_14127 -> Patchwork_126873v2 Summary

✗ Fi.CI.SPARSE: warning for drm: drm debug and error logging improvements (rev2)

== Series Details == Series: drm: drm debug and error logging improvements (rev2) URL : https://patchwork.freedesktop.org/series/126873/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.

✗ Fi.CI.CHECKPATCH: warning for drm: drm debug and error logging improvements (rev2)

== Series Details == Series: drm: drm debug and error logging improvements (rev2) URL : https://patchwork.freedesktop.org/series/126873/ State : warning == Summary == Error: dim checkpatch failed 1fed5ec2cd6e drm/print: make drm_err_printer() device specific by using drm_err() 0131234c9f75 dr

Re: [PATCH v2 2/4] drm/uAPI: Add "force color format" drm property as setting for userspace

þri., 16. jan. 2024 kl. 13:29 skrifaði Sebastian Wick : > > On Tue, Jan 16, 2024 at 01:13:13PM +, Andri Yngvason wrote: [...] > > şri., 16. jan. 2024 kl. 11:42 skrifaği Sebastian Wick > > : > > > > > > On Mon, Jan 15, 2024 at 04:05:52PM +, Andri Yngvason wrote: > > > > From: Werner Sembach

✗ Fi.CI.BUILD: failure for New DRM properties for output color format (rev2)

== Series Details == Series: New DRM properties for output color format (rev2) URL : https://patchwork.freedesktop.org/series/128825/ State : failure == Summary == Error: patch https://patchwork.freedesktop.org/api/1.0/series/128825/revisions/2/mbox/ not applied Applying: drm/amd/display: Re

Re: [PATCH v2 2/4] drm/uAPI: Add "force color format" drm property as setting for userspace

On Tue, Jan 16, 2024 at 01:13:13PM +, Andri Yngvason wrote: > Hi Sebastian, > > þri., 16. jan. 2024 kl. 11:42 skrifaði Sebastian Wick > : > > > > On Mon, Jan 15, 2024 at 04:05:52PM +, Andri Yngvason wrote: > > > From: Werner Sembach > > > > > > Add a new general drm property "force color

✗ Fi.CI.BAT: failure for New DRM properties for output color format

== Series Details == Series: New DRM properties for output color format URL : https://patchwork.freedesktop.org/series/128826/ State : failure == Summary == CI Bug Log - changes from CI_DRM_14127 -> Patchwork_128826v1 Summary --- **F

Re: [PATCH v2 2/4] drm/uAPI: Add "force color format" drm property as setting for userspace

Hi Sebastian, þri., 16. jan. 2024 kl. 11:42 skrifaði Sebastian Wick : > > On Mon, Jan 15, 2024 at 04:05:52PM +, Andri Yngvason wrote: > > From: Werner Sembach > > > > Add a new general drm property "force color format" which can be used > > by userspace to tell the graphics driver which color

[PATCH 10/10] drm: remove drm_debug_printer in favor of drm_dbg_printer

Convert the remaining drm_debug_printer users over to drm_dbg_printer, as it can handle the cases without struct drm_device pointer, and also provides drm debug category and prefix support. Remove drm_debug_printer altogether. Signed-off-by: Jani Nikula --- drivers/gpu/drm/drm_modeset_lock.c |

[PATCH 08/10] drm/i915: use drm_printf() with the drm_err_printer intead of pr_err()

There's already a related drm_printer. Use it to preserve the context instead of a separate pr_err(). Signed-off-by: Jani Nikula --- drivers/gpu/drm/i915/gt/selftest_engine_heartbeat.c | 6 +++--- drivers/gpu/drm/i915/selftests/i915_active.c| 4 ++-- 2 files changed, 5 insertions(+), 5 d

[PATCH 07/10] drm/i915: switch from drm_debug_printer() to device specific drm_dbg_printer()

Prefer the device specific debug printer. Signed-off-by: Jani Nikula --- drivers/gpu/drm/i915/display/intel_display_driver.c | 3 ++- drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c| 3 ++- drivers/gpu/drm/i915/gt/intel_reset.c | 3 ++- drivers/gpu/drm/i915/gt/intel_workaround

[PATCH 06/10] drm/dp: switch drm_dp_vsc_sdp_log() to struct drm_printer

Use the existing drm printer infrastructure instead of local macros. Signed-off-by: Jani Nikula --- drivers/gpu/drm/display/drm_dp_helper.c | 17 +--- .../drm/i915/display/intel_crtc_state_dump.c | 5 ++-- drivers/gpu/drm/i915/display/intel_display.c | 27 +-- in

[PATCH 09/10] drm/xe: switch from drm_debug_printer() to device specific drm_dbg_printer()

Prefer the device specific debug printer. Signed-off-by: Jani Nikula --- drivers/gpu/drm/xe/xe_gt.c | 2 +- drivers/gpu/drm/xe/xe_gt_topology.c | 4 +++- drivers/gpu/drm/xe/xe_reg_sr.c | 2 +- 3 files changed, 5 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/xe/xe_gt.c

✗ Fi.CI.SPARSE: warning for New DRM properties for output color format

== Series Details == Series: New DRM properties for output color format URL : https://patchwork.freedesktop.org/series/128826/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.

[PATCH 05/10] drm/mode: switch from drm_debug_printer() to device specific drm_dbg_printer()

Prefer the device specific debug printer. Signed-off-by: Jani Nikula --- drivers/gpu/drm/drm_mode_config.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_mode_config.c b/drivers/gpu/drm/drm_mode_config.c index 8525ef851540..48fd2d67f352 100644 --- a/driv

✗ Fi.CI.CHECKPATCH: warning for New DRM properties for output color format

== Series Details == Series: New DRM properties for output color format URL : https://patchwork.freedesktop.org/series/128826/ State : warning == Summary == Error: dim checkpatch failed 73e5d5241200 drm/amd/display: Remove unnecessary SIGNAL_TYPE_HDMI_TYPE_A check -:35: CHECK:LOGICAL_CONTINUAT

[PATCH 04/10] drm/dp_mst: switch from drm_debug_printer() to device specific drm_dbg_printer()

Prefer the device specific debug printer. Signed-off-by: Jani Nikula --- drivers/gpu/drm/display/drm_dp_mst_topology.c | 23 +++ 1 file changed, 14 insertions(+), 9 deletions(-) diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c b/drivers/gpu/drm/display/drm_dp_mst_topo

[PATCH 03/10] drm/print: add drm_dbg_printer() for drm device specific printer

We've lacked a device specific debug printer. Add one. Take category into account too. __builtin_return_address(0) is inaccurate here, so don't use it. If necessary, we can later pass __func__ to drm_dbg_printer() by wrapping it inside a macro. Signed-off-by: Jani Nikula --- drivers/gpu/drm/drm

[PATCH 02/10] drm/print: move enum drm_debug_category etc. earlier in drm_print.h

Avoid forward declarations in subsequent changes, but separate this movement to an independent change. Signed-off-by: Jani Nikula --- include/drm/drm_print.h | 190 1 file changed, 95 insertions(+), 95 deletions(-) diff --git a/include/drm/drm_print.h b/

[PATCH 01/10] drm/print: make drm_err_printer() device specific by using drm_err()

With few users for drm_err_printer(), it's still feasible to convert it to be device specific. Use drm_err() under the hood. While at it, make the prefix optional. Signed-off-by: Jani Nikula --- drivers/gpu/drm/drm_print.c | 7 ++- drivers/gpu/drm/i915/gt/selftest_e

[PATCH 00/10] drm: drm debug and error logging improvements

This is resend and more patches on top of [1]. I don't think I've changed anything since then. BR, Jani. [1] https://patchwork.freedesktop.org/series/126873/ Jani Nikula (10): drm/print: make drm_err_printer() device specific by using drm_err() drm/print: move enum drm_debug_category etc. e

Re: disable large folios for shmem file used by xfs xfile

On Wed, Jan 10, 2024 at 4:35 PM Matthew Wilcox wrote: > > On Wed, Jan 10, 2024 at 05:28:22PM +0200, Joonas Lahtinen wrote: > > Quoting Joonas Lahtinen (2024-01-10 17:20:24) > > > However we specifically pass "huge=within_size" to vfs_kern_mount when > > > creating a private mount of tmpfs for the

[PATCH v2 0/4] New DRM properties for output color format

After some discussion, we decided to drop the "active color format" property and rename the "preferred color format" property to "force color format". The user can probe available color formats in combination with other properties using TEST_ONLY commits. v1: https://lore.kernel.org/dri-devel/2

Re: [PATCH 5/7] drm/uAPI: Add "preferred color format" drm property as setting for userspace

mið., 10. jan. 2024 kl. 13:09 skrifaði Werner Sembach : > > Hi, > > Am 10.01.24 um 11:11 schrieb Andri Yngvason: > > Hi, > > > > mið., 10. jan. 2024 kl. 09:27 skrifaði Maxime Ripard : > >> On Tue, Jan 09, 2024 at 06:11:02PM +, Andri Yngvason wrote: > >>> From: Werner Sembach > >>> > >>> Add a

Re: [PATCH 2/2] xfs: disable large folio support in xfile_create

On Wed, Jan 10, 2024 at 10:21:09AM +0100, Christoph Hellwig wrote: > The xfarray code will crash if large folios are force enabled using: > >echo force > /sys/kernel/mm/transparent_hugepage/shmem_enabled > > Fixing this will require a bit of an API change, and prefeably sorting out > the hwpo

Re: [PATCH 3/7] drm/amd/display: Add handling for new "active color format" property

Hi Werner, mið., 10. jan. 2024 kl. 13:14 skrifaði Werner Sembach : > > Hi, > > Am 10.01.24 um 14:09 schrieb Daniel Vetter: > > On Wed, 10 Jan 2024 at 13:53, Andri Yngvason wrote: > >> mið., 10. jan. 2024 kl. 11:10 skrifaði Daniel Vetter : > >>> On Tue, Jan 09, 2024 at 06:11:00PM +, Andri Yng

[PATCH 6/7] drm/amd/display: Add handling for new "preferred color format" property

From: Werner Sembach This commit implements the "preferred color format" drm property for the AMD GPU driver. Signed-off-by: Werner Sembach Signed-off-by: Andri Yngvason Tested-by: Andri Yngvason --- .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 30 +++ .../display/amdgpu_d

[PATCH v2 3/4] drm/amd/display: Add handling for new "force color format" property

From: Werner Sembach This commit implements the "force color format" drm property for the AMD GPU driver. Signed-off-by: Werner Sembach Co-Developed-by: Andri Yngvason Signed-off-by: Andri Yngvason Tested-by: Andri Yngvason --- Changes in v2: - Renamed to "force color format" from "preferr

[PATCH 3/7] drm/amd/display: Add handling for new "active color format" property

From: Werner Sembach This commit implements the "active color format" drm property for the AMD GPU driver. Signed-off-by: Werner Sembach Signed-off-by: Andri Yngvason Tested-by: Andri Yngvason --- .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 42 ++- .../display/amdgpu_dm/a

Re: [PATCH 3/7] drm/amd/display: Add handling for new "active color format" property

mið., 10. jan. 2024 kl. 11:10 skrifaði Daniel Vetter : > > On Tue, Jan 09, 2024 at 06:11:00PM +, Andri Yngvason wrote: > > + /* Extract information from crtc to communicate it to userspace as > > connector properties */ > > + for_each_new_connector_in_state(state, connector, new_con_st

Re: [PATCH 5/7] drm/uAPI: Add "preferred color format" drm property as setting for userspace

Hi, mið., 10. jan. 2024 kl. 09:27 skrifaði Maxime Ripard : > On Tue, Jan 09, 2024 at 06:11:02PM +, Andri Yngvason wrote: > > From: Werner Sembach > > > > Add a new general drm property "preferred color format" which can be used > > by userspace to tell the graphic drivers to which color forma

Re: [PATCH 2/7] drm/uAPI: Add "active color format" drm property as feedback for userspace

mið., 10. jan. 2024 kl. 13:26 skrifaði Daniel Stone : > > > > This thing here works entirely differently, and I think we need somewhat > > new semantics for this: > > > > - I agree it should be read-only for userspace, so immutable sounds right. > > > > - But I also agree with Daniel Stone that thi

Re: [PATCH 2/2] xfs: disable large folio support in xfile_create

On Wed, Jan 10, 2024 at 09:55:15AM -0800, Darrick J. Wong wrote: > On Wed, Jan 10, 2024 at 10:21:09AM +0100, Christoph Hellwig wrote: > > The xfarray code will crash if large folios are force enabled using: > > > >echo force > /sys/kernel/mm/transparent_hugepage/shmem_enabled > > > > Fixing t

[PATCH 0/7] New DRM properties for output color format

This is a subset of patches, originally submitted by Werner Sembach titled: New uAPI drm properties for color management [1] I've rebased against the current master branch, made modifications where needed, and tested with both HDMI and DP on both Intel and AMD hardware, using modified sway [2] and

[PATCH 5/7] drm/uAPI: Add "preferred color format" drm property as setting for userspace

From: Werner Sembach Add a new general drm property "preferred color format" which can be used by userspace to tell the graphic drivers to which color format to use. Possible options are: - auto (default/current behaviour) - rgb - ycbcr444 - ycbcr422 (not supported by both amdgpu

Re: [PATCH 2/7] drm/uAPI: Add "active color format" drm property as feedback for userspace

Hi Daniel, Please excuse my misconfigured email client. HTML was accidentally enabled in my previous messages, so I'll re-send it for the benefit of mailing lists. þri., 9. jan. 2024 kl. 22:32 skrifaði Daniel Stone : > > On Tue, 9 Jan 2024 at 18:12, Andri Yngvason wrote: > > + * active color for

[PATCH v2 4/4] drm/i915/display: Add handling for new "force color format" property

From: Werner Sembach This commit implements the "force color format" drm property for the Intel GPU driver. Signed-off-by: Werner Sembach Co-Developed-by: Andri Yngvason Signed-off-by: Andri Yngvason Tested-by: Andri Yngvason --- Changes in v2: - Renamed to "force color format" from "prefe

Re: [PATCH 2/7] drm/uAPI: Add "active color format" drm property as feedback for userspace

Hi Daniel, þri., 9. jan. 2024 kl. 22:32 skrifaði Daniel Stone : > On Tue, 9 Jan 2024 at 18:12, Andri Yngvason wrote: > > + * active color format: > > + * This read-only property tells userspace the color format > actually used > > + * by the hardware display engine "on the cable" on a co

[PATCH v2 2/4] drm/uAPI: Add "force color format" drm property as setting for userspace

From: Werner Sembach Add a new general drm property "force color format" which can be used by userspace to tell the graphics driver which color format to use. Possible options are: - auto (default/current behaviour) - rgb - ycbcr444 - ycbcr422 (supported by neither amdgpu or i915

[PATCH 1/7] drm/amd/display: Remove unnecessary SIGNAL_TYPE_HDMI_TYPE_A check

From: Werner Sembach Remove unnecessary SIGNAL_TYPE_HDMI_TYPE_A check that was performed in the drm_mode_is_420_only() case, but not in the drm_mode_is_420_also() && force_yuv420_output case. Without further knowledge if YCbCr 4:2:0 is supported outside of HDMI, there is no reason to use RGB whe

[PATCH 4/7] drm/i915/display: Add handling for new "active color format" property

From: Werner Sembach This commit implements the "active color format" drm property for the Intel GPU driver. Signed-off-by: Werner Sembach Signed-off-by: Andri Yngvason Tested-by: Andri Yngvason --- drivers/gpu/drm/i915/display/intel_display.c | 33 drivers/gpu/drm/i915/

Re: [PATCH 2/2] xfs: disable large folio support in xfile_create

On Thu, Jan 11, 2024 at 10:45:53PM +, Matthew Wilcox wrote: > On Thu, Jan 11, 2024 at 02:00:53PM -0800, Andrew Morton wrote: > > On Wed, 10 Jan 2024 12:04:51 -0800 "Darrick J. Wong" > > wrote: > > > > > > > Fixing this will require a bit of an API change, and prefeably > > > > > sorting out

[PATCH 7/7] drm/i915/display: Add handling for new "preferred color format" property

From: Werner Sembach This commit implements the "preferred color format" drm property for the Intel GPU driver. Signed-off-by: Werner Sembach Co-developed-by: Andri Yngvason Signed-off-by: Andri Yngvason Tested-by: Andri Yngvason --- drivers/gpu/drm/i915/display/intel_dp.c | 16

[PATCH 2/7] drm/uAPI: Add "active color format" drm property as feedback for userspace

From: Werner Sembach Add a new general drm property "active color format" which can be used by graphic drivers to report the used color format back to userspace. There was no way to check which color format got actually used on a given monitor. To surely predict this, one must know the exact cap

[PATCH v2 1/4] drm/amd/display: Remove unnecessary SIGNAL_TYPE_HDMI_TYPE_A check

From: Werner Sembach Remove unnecessary SIGNAL_TYPE_HDMI_TYPE_A check that was performed in the drm_mode_is_420_only() case, but not in the drm_mode_is_420_also() && force_yuv420_output case. Without further knowledge if YCbCr 4:2:0 is supported outside of HDMI, there is no reason to use RGB whe

Re: [PATCH v2 2/4] drm/uAPI: Add "force color format" drm property as setting for userspace

On Mon, Jan 15, 2024 at 04:05:52PM +, Andri Yngvason wrote: > From: Werner Sembach > > Add a new general drm property "force color format" which can be used > by userspace to tell the graphics driver which color format to use. I don't like the "force" in the name. This just selects the color

Re: [PATCH v3 07/16] drm/i915: Fix PTE decode during initial plane readout

On 1/16/2024 8:56 AM, Ville Syrjala wrote: From: Ville Syrjälä When multiple pipes are enabled by the BIOS we try to read out each in turn. But we do the readout for the second only after the inherited vma for the first has been rebound into its original place (and thus the PTEs have been rew

Re: [PATCH v3 06/16] drm/i915: Rename the DSM/GSM registers

On 1/16/2024 8:56 AM, Ville Syrjala wrote: From: Ville Syrjälä 0x108100 and 0x1080c0 have been around since snb. Rename the defines appropriately. Cc: Paz Zcharya Reviewed-by: Andrzej Hajda Signed-off-by: Ville Syrjälä Acked-by: Nirmoy Das --- drivers/gpu/drm/i915/gem/i915_gem_stolen

Re: [PATCH v3 05/16] drm/i915: Disable the "binder"

On 1/16/2024 8:56 AM, Ville Syrjala wrote: From: Ville Syrjälä Now that the GGTT PTE updates go straight to GSMBASE (bypassing GTTMMADR) there should be no more risk of system hangs? So the "binder" (ie. update the PTEs via MI_UPDATE_GTT) is no longer necessary, disable it. My main worry wit

Re: [PATCH v3 04/16] drm/i915: Bypass LMEMBAR/GTTMMADR for MTL stolen memory access

On 1/16/2024 8:56 AM, Ville Syrjala wrote: From: Ville Syrjälä On MTL accessing stolen memory via the BARs is somehow borked, and it can hang the machine. As a workaround let's bypass the BARs and just go straight to DSMBASE/GSMBASE instead. Note that on every other platform this itself would

Re: [PATCH v3 03/16] drm/i915: Remove ad-hoc lmem/stolen debugs

On 1/16/2024 8:56 AM, Ville Syrjala wrote: From: Ville Syrjälä Now that intel_memory_regions_hw_probe() prints out each and every memory region there's no reason to have ad-hoc debugs to do similar things elsewhere. Cc: Paz Zcharya Reviewed-by: Andrzej Hajda Signed-off-by: Ville Syrjälä

Re: [PATCH v3 01/16] drm/i915: Use struct resource for memory region IO as well

On 1/16/2024 8:56 AM, Ville Syrjala wrote: From: Ville Syrjälä mem->region is a struct resource, but mem->io_start and mem->io_size are not for whatever reason. Let's unify this and convert the io stuff into a struct resource as well. Should make life a little less annoying when you don't hav

[PULL] drm-xe-next-fixes

Hi Maintainers, Various fixes for the Xe driver, as described below, for -rc1. Thanks, Thomas The following changes since commit 315acff5196f4e2f84a2a2d093000e0c6b0b4d1c: drm/xe: Fix warning on impossible condition (2023-12-26 12:53:26 -0500) are available in the Git repository at: https

Re: [PATCH v3 02/16] drm/i915: Print memory region info during probe

On 1/16/2024 8:56 AM, Ville Syrjala wrote: From: Ville Syrjälä Dump the details about every memory region into dmesg at probe time. Avoids having to dig those out from random places when debugging stuff. Cc: Paz Zcharya Reviewed-by: Andrzej Hajda Signed-off-by: Ville Syrjälä Reviewed-by:

Re: Rework TTMs busy handling

Am 12.01.24 um 13:51 schrieb Christian König: Hi guys, just a gentle ping on this. Zack any more comments for the VMWGFX parts? Thanks, Christian. same as the last time. Things I've changed: Implemented the requirements from Zack to correctly fill in the busy placements for VMWGFX. Renam

Re: [PATCH 4/6] drm/i915/opregion: abstract ASLE presence check

On Mon, 15 Jan 2024, Jani Nikula wrote: > On Fri, 12 Jan 2024, Radhakrishna Sripada > wrote: >> On Fri, Jan 12, 2024 at 12:17:25PM +0200, Jani Nikula wrote: >>> On Thu, 11 Jan 2024, Radhakrishna Sripada >>> wrote: >>> > On Thu, Jan 11, 2024 at 07:21:17PM +0200, Jani Nikula wrote: >>> >> Add a

✗ Fi.CI.BAT: failure for drm/i915: (stolen) memory region related fixes (rev6)

== Series Details == Series: drm/i915: (stolen) memory region related fixes (rev6) URL : https://patchwork.freedesktop.org/series/127721/ State : failure == Summary == CI Bug Log - changes from CI_DRM_14125 -> Patchwork_127721v6 Summary ---

✗ Fi.CI.CHECKPATCH: warning for drm/i915: (stolen) memory region related fixes (rev6)

== Series Details == Series: drm/i915: (stolen) memory region related fixes (rev6) URL : https://patchwork.freedesktop.org/series/127721/ State : warning == Summary == Error: dim checkpatch failed 72a9e5460135 drm/i915: Use struct resource for memory region IO as well -:387: WARNING:LONG_LINE:

✗ Fi.CI.SPARSE: warning for drm/i915: (stolen) memory region related fixes (rev6)

== Series Details == Series: drm/i915: (stolen) memory region related fixes (rev6) URL : https://patchwork.freedesktop.org/series/127721/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.

Re: [PATCH] drm/xe/display: Disable aux ccs framebuffers

On Mon, 15 Jan 2024, "Hellstrom, Thomas" wrote: > I wonder if, moving forward, we should use a topic/display-for-xe > branch (no force-push) that can be used for display commits that need > to be in Xe during -next cycles. It could then be merged into xe and > i915 as needed? Topic branches have

Re: [PATCH] drm/xe/guc: Enable WA 14018913170

Please post this patch to intel xe mailing list. Regards, Badal On 16-01-2024 13:18, Karthik Poosa wrote: The GuC handles the WA, the KMD just needs to set the flag to enable it on the appropriate platforms. v2: Fixed CI checkpatch warning, alignment should match open parenthesis. Signed-off-

✗ Fi.CI.BAT: failure for drm/xe/guc: Enable WA 14018913170 (rev3)

== Series Details == Series: drm/xe/guc: Enable WA 14018913170 (rev3) URL : https://patchwork.freedesktop.org/series/128781/ State : failure == Summary == CI Bug Log - changes from CI_DRM_14125 -> Patchwork_128781v3 Summary --- **FAI