✓ Fi.CI.BAT: success for drm/i915/dsb: Use chained DSBs for LUT programming

== Series Details == Series: drm/i915/dsb: Use chained DSBs for LUT programming URL : https://patchwork.freedesktop.org/series/135316/ State : success == Summary == CI Bug Log - changes from CI_DRM_14996 -> Patchwork_135316v1 Summary

✗ Fi.CI.SPARSE: warning for drm/i915/dsb: Use chained DSBs for LUT programming

== Series Details == Series: drm/i915/dsb: Use chained DSBs for LUT programming URL : https://patchwork.freedesktop.org/series/135316/ 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/i915/dsb: Use chained DSBs for LUT programming

== Series Details == Series: drm/i915/dsb: Use chained DSBs for LUT programming URL : https://patchwork.freedesktop.org/series/135316/ State : warning == Summary == Error: dim checkpatch failed 5cc7f6d7e392 drm/i915: Calculate vblank delay more accurately 16f9c292de2d drm/i915: Make

RE: quadbuffer stereo

[Public] Quadbuffer stereo is not supported on Linux. Alex From: amd-gfx On Behalf Of adblover Sent: Monday, June 24, 2024 6:53 AM To: intel-gfx@lists.freedesktop.org; amd-...@lists.freedesktop.org Subject: quadbuffer stereo I have no idea how to enable quadbuffer stereo (hdmi-3d) on linux

[PATCH 14/14] drm/i915/dsb: Use chained DSBs for LUT programming

From: Ville Syrjälä In order to better handle the necessary DSB DEwake tricks let's switch over to using a chained DSB for the actual LUT programming. The CPU will start 'dsb_color_commit', which in turn will start the chained 'dsb_color_vblank'. Signed-off-by: Ville Syrjälä ---

[PATCH 13/14] drm/i915/dsb: s/dsb/dsb_color_vblank/

From: Ville Syrjälä We'll soon utilize several DSBs during the commit. To that end rename the current crtc_state->dsb to crtc_state->dsb_color_vblank to better reflect its role (color managemnent stuff programmed during vblank). Signed-off-by: Ville Syrjälä ---

[PATCH 10/14] drm/i915/dsb: Introduce intel_dsb_chain()

From: Ville Syrjälä In order to handle the DEwake tricks without involving the CPU we need a mechanism by which one DSB can start another one. Add a basic function to do so. We'll extend it later with additional code to actually deal with DEwake. Signed-off-by: Ville Syrjälä ---

[PATCH 12/14] drm/i915/dsb: Clear DSB_ENABLE_DEWAKE once the DSB is done

From: Ville Syrjälä In order to avoid the DSB keeping the DEwake permanently asserted we must clear DSB_PMCTRL_2.DSB_FORCE_DEWAKE once we are done. For good measure do the same for DSB_PMCTRL.DSB_ENABLE_DEWAKE. Experimentally this doens't seem to be actually necessary (unlike with

[PATCH 11/14] drm/i915/dsb: Allow intel_dsb_chain() to use DSB_WAIT_FOR_VBLANK

From: Ville Syrjälä Allow intel_dsb_chain() to start the chained DSB at start of the undelaye vblank. This is slightly more involved than simply setting the bit as we must use the DEwake mechanism to eliminate pkgC latency. And DSB_ENABLE_DEWAKE itself is problematic in that it allows us to

[PATCH 09/14] drm/i915/dsb: Introduce intel_dsb_wait_scanline_{in, out}()

From: Ville Syrjälä Add functions to emit a DSB scanline window wait instructions. We can either wait for the scanline to be IN the window or OUT of the window. The hardware doesn't handle wraparound so we must manually deal with it by swapping the IN range to the inverse OUT range, or vice

[PATCH 06/14] drm/i915/dsb: Fix dewake scanline

From: Ville Syrjälä Currently we calculate the DEwake scanline based on the delayed vblank start, while in reality it should be computed based on the undelayed vblank start (as that is where the DSB actually starts). Currently it doesn't really matter as we don't have any vblank delay

[PATCH 08/14] drm/i915/dsb: Precompute DSB_CHICKEN

From: Ville Syrjälä Adjust the code that determines the correct DSB_CHICKEN value to be usable for use within DSB commands themselves. Ie. precompute it based on our knowledge of what the hardware state (VRR vs. not mainly) will be at the time of the commit. Signed-off-by: Ville Syrjälä ---

[PATCH 07/14] drm/i915/dsb: Account for VRR properly in DSB scanline stuff

From: Ville Syrjälä When determining various scanlines for DSB use we should take into account whether VRR is active at the time when the DSB uses said scanline information. For now all DSB scanline usage occurs prior to the actual commit, so we only need to care about the state of VRR at that

[PATCH 04/14] drm/i915/dsb: Convert dewake_scanline to a hw scanline number earlier

From: Ville Syrjälä Currently we switch from out software idea of a scanline to the hw's idea of a scanline during the commit phase in _intel_dsb_commit(). While that is slightly easier due to fastsets fiddling with the timings, we'll also need to generate proper hw scanline numbers already when

[PATCH 05/14] drm/i915/dsb: Shuffle code around

From: Ville Syrjälä Relocate intel_dsb_dewake_scanline() and dsb_chicken() upwards in the file. I need to reuse these while emitting DSB commands, and I'd like to keep the DSB command emission stuff more or less grouped together in the file. Also drop the intel_ prefix from

[PATCH 03/14] drm/i915/dsb: Hook up DSB error interrupts

From: Ville Syrjälä Enable all DSB error/fault interrupts so that we can see if anything goes terribly wrong. Signed-off-by: Ville Syrjälä --- .../gpu/drm/i915/display/intel_display_irq.c | 17 ++ drivers/gpu/drm/i915/display/intel_dsb.c | 58 +++

[PATCH 02/14] drm/i915: Make vrr_{enabling, disabling}() usable outside intel_display.c

From: Ville Syrjälä Give vrr_enabling() and vrr_disabling() slightly fancier names, and pass in the whole atomic state so that they'll be easier to use. We'll need to call at least the disabling part from the DSB code soon enough (so that we can do vblank evasions/etc. correctly on the DSB).

[PATCH 01/14] drm/i915: Calculate vblank delay more accurately

From: Ville Syrjälä Calculate the vblank delay in the vblank evasion code correctly for interlaced modes. The current code assumes that we won't be using an interlaced mode. That assumption is actually valid since we've defeatured interlaced scanout in commit f71c9b7bc35f ("drm/i915/display:

[PATCH 00/14] drm/i915/dsb: Use chained DSBs for LUT programming

From: Ville Syrjälä Handle the DSB's DEwake shenanigans more elegantly by chaining two DSBs together. Ville Syrjälä (14): drm/i915: Calculate vblank delay more accurately drm/i915: Make vrr_{enabling,disabling}() usable outside intel_display.c drm/i915/dsb: Hook up DSB error

✓ Fi.CI.BAT: success for drm/i915: Enable CCS+10bpc and CCS+async flips

== Series Details == Series: drm/i915: Enable CCS+10bpc and CCS+async flips URL : https://patchwork.freedesktop.org/series/135306/ State : success == Summary == CI Bug Log - changes from CI_DRM_14995 -> Patchwork_135306v1 Summary ---

✗ Fi.CI.SPARSE: warning for drm/i915: Enable CCS+10bpc and CCS+async flips

== Series Details == Series: drm/i915: Enable CCS+10bpc and CCS+async flips URL : https://patchwork.freedesktop.org/series/135306/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.

[PATCH 5/5] drm/i915: Allow async flips with CCS on ICL

From: Ville Syrjälä Apparently ICL can do async flips with CCS. In fact it already seems to work on GLK, but apparently can lead to underruns there so we'll only enable it for ICL. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/intel_display.c | 21 +++- 1 file

[PATCH 4/5] drm/i915: Allow async flips with render compression on TGL+

From: Ville Syrjälä Looks like CCS + async flips has been a thing for a while now. Enable this for TGL+ render compression modifiers. Note that we can't update AUX_DIST during async flips we must check to make sure it remains unchanged. We also can't do clear color. Supposedly there was some

[PATCH 2/5] drm/i915: Expose CCS for 10bpc RGB formats on TGL+

From: Ville Syrjälä CCS + 10bpc formats has been a thing for a while now. Expose it it on TGL+. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/intel_fb.c | 36 +++ .../drm/i915/display/skl_universal_plane.c| 8 ++--- 2 files changed, 40 insertions(+),

[PATCH 3/5] drm/i915: Enable 10bpc + CCS on ICL

From: Ville Syrjälä ICL supports 10bpc compressed scanout. Enable it. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/intel_fb.c | 8 +++ .../drm/i915/display/skl_universal_plane.c| 65 +++ 2 files changed, 73 insertions(+) diff --git

[PATCH 1/5] drm/i915: Disable compression tricks on JSL

From: Ville Syrjälä Bspec asks us to disable some compression trick on JSL. While the bspec description is pretty vague it looks like this is some extra trick for 10bpc+ CCS which presumably the ICL derived display engine doesn't support. Note that we aren't currently exposing 10bpc CCS scanout

[PATCH 0/5] drm/i915: Enable CCS+10bpc and CCS+async flips

From: Ville Syrjälä Add support for compressed 10bpc scanout, and async flips with render compression. Ville Syrjälä (5): drm/i915: Disable compression tricks on JSL drm/i915: Expose CCS for 10bpc RGB formats on TGL+ drm/i915: Enable 10bpc + CCS on ICL drm/i915: Allow async flips with

Re: [PATCH v2 0/9] drm/i915: Polish plane surface alignment handling

On Wed, Jun 19, 2024 at 02:38:16PM +0300, Ville Syrjälä wrote: > On Wed, Jun 12, 2024 at 11:47:03PM +0300, Ville Syrjala wrote: > > From: Ville Syrjälä > > > > intel_surf_alignment() in particular has devolved into > > a complete mess. Redesign the code so that we can handle > > alignment

Re: Linux 6.10-rc1

Hello! Ideas welcome, especially some way to see what graphics is doing. I'm unsure about the distro you are using but try package intel_gpu_top. It displays irqs/s and a bunch of other utilization statistics. Hope this helps. -- BR, Gerhard

Re: [PATCH v7] drm/i915/panelreplay: Panel replay workaround with VRR

On Fri, Jun 21, 2024 at 05:55:13AM +, Manna, Animesh wrote: > > > > -Original Message- > > From: Ville Syrjälä > > Sent: Thursday, June 20, 2024 11:06 PM > > To: Manna, Animesh > > Cc: intel-gfx@lists.freedesktop.org; Nikula, Jani ; > > Hogander, Jouni ; Murthy, Arun R > > ;

quadbuffer stereo

I have no idea how to enable quadbuffer stereo (hdmi-3d) on linux for intel and amdgpu. I tried using Option Stereo 12 with this result (WW) AMDGPU(0): Option "Stereo" is not used Hoping for solutions for both cards (intel arc,renoir) thanks --

RE: [PATCH] drm/i915/display: Consider adjusted_pixel_rate to be u64

> -Original Message- > From: Golani, Mitulkumar Ajitkumar > > Sent: Friday, June 21, 2024 1:05 PM > To: intel-gfx@lists.freedesktop.org > Cc: intel...@lists.freedesktop.org; Vivi, Rodrigo ; > jani.nik...@linux.intel.com; Kandpal, Suraj ; > Nautiyal, Ankit K ; nat...@kernel.org >

Re: [PATCH] drm/i915/display: Consider adjusted_pixel_rate to be u64

On Fri, 21 Jun 2024, Mitul Golani wrote: > Consider adjusted_pixel_rate to be a u64 to match the return > type of mul_u32_u32() and avoid any compiler dependency for > do_div. You should mention this fixes 32-bit builds. Might also want to give a link to the actual build failure, and give credit

✗ Fi.CI.BAT: failure for Use VRR timing generator for fixed refresh rate modes (rev2)

== Series Details == Series: Use VRR timing generator for fixed refresh rate modes (rev2) URL : https://patchwork.freedesktop.org/series/134383/ State : failure == Summary == CI Bug Log - changes from CI_DRM_14990 -> Patchwork_134383v2

✗ Fi.CI.SPARSE: warning for Use VRR timing generator for fixed refresh rate modes (rev2)

== Series Details == Series: Use VRR timing generator for fixed refresh rate modes (rev2) URL : https://patchwork.freedesktop.org/series/134383/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.