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

2024-05-13 Thread Ville Syrjala
From: Ville Syrjälä intel_surf_alignment() in particular has devolved into a complete mess. Redesign the code so that we can handle alignment restrictions in a nicer. Also adjust alignment for TGL+ to actually match the hardware requirements. Ville Syrjälä (9): drm: Rename

[PATCH v2 13/16] drm/i915: Refactor skl+ plane register offset calculations

2024-05-13 Thread Ville Syrjala
From: Ville Syrjälä Currentluy every skl+ plane register defines some intermediate macros to calculate the final register offset. Pull all of that into common macros, simplifying the final register offset stuff into just five defines: - raw register offsets for the planes 1 and 2 on pipes A and

[PATCH v2 12/16] drm/i915: Drop a few unwanted tabs from skl+ plane reg defines

2024-05-13 Thread Ville Syrjala
From: Ville Syrjälä A few extra tabs have snuck into the skl+ plane register bit definitions. Remove them. v2: Rebase Reviewed-by: Jani Nikula Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/skl_universal_plane_regs.h | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)

[PATCH v2 11/16] drm/i915: Use REG_BIT for PLANE_WM bits

2024-05-13 Thread Ville Syrjala
From: Ville Syrjälä A couple of PLANE_WM bits were still using the hand rolled (1< Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/skl_universal_plane_regs.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git

[PATCH v2 10/16] drm/i915: Shuffle the skl+ plane register definitions

2024-05-13 Thread Ville Syrjala
From: Ville Syrjälä Rearrange the plane skl+ universal plane register definitions: - keep everything related to the same register in one place - sort based on register offset - unify the whitespace/etc a bit v2: Define register contents after all offsets (Jani) Cc: Jani Nikula Signed-off-by:

[PATCH v2 09/16] drm/i915: Drop useless PLANE_FOO_3 register defines

2024-05-13 Thread Ville Syrjala
From: Ville Syrjälä We only need register defines for the first two planes on the first two pipes. Nuke everything else. v2: Drop a few more that snuck through Reviewed-by: Jani Nikula #v1 Signed-off-by: Ville Syrjälä --- .../i915/display/skl_universal_plane_regs.h | 19

[PATCH 16/16] drm/i915: Handle SKL+ WM/DDB registers next to all other plane registers

2024-05-10 Thread Ville Syrjala
From: Ville Syrjälä Having the plane WM/DDB regitster write functions in skl_watermarks.c is rather annoying when trying to implement DSB based plane updates. Move them into the respective files that handle all other plane register writes. Less places where I need to worry about the DSB vs. MMIO

[PATCH 15/16] drm/i915: Nuke skl_write_wm_level() and skl_ddb_entry_write()

2024-05-10 Thread Ville Syrjala
From: Ville Syrjälä Get rid of skl_ddb_entry_write() and skl_write_wm_level() and just call intel_de_write_fw() directly. This is prep work towards DSB based plane updates where these wrappers are more of a hinderance. Done with cocci mostly: @@ expression D, R, L; @@ - skl_write_wm_level(D,

[PATCH 14/16] drm/i915: Extract skl_plane_{wm,ddb}_reg_val()

2024-05-10 Thread Ville Syrjala
From: Ville Syrjälä Extract helpers to calculate the final wm/ddb register values for skl+. Will allow me to more cleanly remove the register write wrappers for these registers. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/skl_watermark.c | 29 +--- 1 file

[PATCH 13/16] drm/i915: Refactor skl+ plane register offset calculations

2024-05-10 Thread Ville Syrjala
From: Ville Syrjälä Currentluy every skl+ plane register defines some intermediate macros to calculate the final register offset. Pull all of that into common macros, simplifying the final register offset stuff into just five defines: - raw register offsets for the planes 1 and 2 on pipes A and

[PATCH 12/16] drm/i915: Drop a few unwanted tabs from skl+ plane reg defines

2024-05-10 Thread Ville Syrjala
From: Ville Syrjälä A few extra tabs have snuck into the skl+ plane register bit definitions. Remove them. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/skl_universal_plane_regs.h | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git

[PATCH 11/16] drm/i915: Use REG_BIT for PLANE_WM bits

2024-05-10 Thread Ville Syrjala
From: Ville Syrjälä A couple of PLANE_WM bits were still using the hand rolled (1< --- drivers/gpu/drm/i915/display/skl_universal_plane_regs.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/display/skl_universal_plane_regs.h

[PATCH 10/16] drm/i915: Shuffle the skl+ plane register definitions

2024-05-10 Thread Ville Syrjala
From: Ville Syrjälä Rearrange the plane skl+ universal plane register definitions: - keep everything related to the same register in one place - sort based on register offset - unify the whitespace/etc a bit Signed-off-by: Ville Syrjälä --- .../i915/display/skl_universal_plane_regs.h | 502

[PATCH 09/16] drm/i915: Drop useless PLANE_FOO_3 register defines

2024-05-10 Thread Ville Syrjala
From: Ville Syrjälä We only need register defines for the first two planes on the first two pipes. Nuke everything else. Signed-off-by: Ville Syrjälä --- .../gpu/drm/i915/display/skl_universal_plane_regs.h | 12 1 file changed, 12 deletions(-) diff --git

[PATCH 08/16] drm/i915/gvt: Use PLANE_CTL and PLANE_SURF defines

2024-05-10 Thread Ville Syrjala
From: Ville Syrjälä Stop hand rolling PLANE_CTL and PLANE_SURF for the third plane and just use the real thing. Cc: Zhenyu Wang CC: Zhi Wang Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_gvt_mmio_table.c | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff

[PATCH 07/16] drm/i915/gvt: Use the full PLANE_KEY*() defines

2024-05-10 Thread Ville Syrjala
From: Ville Syrjälä Stop hand rolling PLANE_KEY*() register defines and just use the real thing. Cc: Zhenyu Wang CC: Zhi Wang Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_gvt_mmio_table.c | 18 +- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git

[PATCH 06/16] drm/i915/gvt: Use the proper PLANE_AUX_OFFSET() define

2024-05-10 Thread Ville Syrjala
From: Ville Syrjälä Stop hand rolling PLANE_AUX_OFFSET() and just use the real thing. Cc: Zhenyu Wang CC: Zhi Wang Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/gvt/handlers.c | 24 ++--- drivers/gpu/drm/i915/gvt/reg.h | 2 --

[PATCH 05/16] drm/i915/gvt: Use the proper PLANE_AUX_DIST() define

2024-05-10 Thread Ville Syrjala
From: Ville Syrjälä Stop hand rolling PLANE_AUX_DIST() and just use the real thing. Cc: Zhenyu Wang CC: Zhi Wang Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/gvt/handlers.c | 24 ++--- drivers/gpu/drm/i915/gvt/reg.h | 1 -

[PATCH 04/16] drm/i915: Move skl+ wm/ddb registers to proper headers

2024-05-10 Thread Ville Syrjala
From: Ville Syrjälä On SKL+ the watermark/DDB registers are proper per-plane registers. Move the definitons to their respective files. Cc: Zhenyu Wang CC: Zhi Wang Signed-off-by: Ville Syrjälä --- .../gpu/drm/i915/display/intel_cursor_regs.h | 20 +

[PATCH 03/16] drm/i915: Extract intel_cursor_regs.h

2024-05-10 Thread Ville Syrjala
From: Ville Syrjälä Move most cursor register definitions into their own file. Declutters i915_reg.h a bit more. Cc: Zhenyu Wang CC: Zhi Wang Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/intel_cursor.c | 1 + .../gpu/drm/i915/display/intel_cursor_regs.h | 78

[PATCH 02/16] drm/i915: Extract skl_universal_plane_regs.h

2024-05-10 Thread Ville Syrjala
From: Ville Syrjälä Move most of the SKL+ universal plane register definitions into their own file. Declutters i915_reg.h a bit more. Cc: Zhenyu Wang CC: Zhi Wang Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/intel_display.c | 1 +

[PATCH 01/16] drm/i915: Nuke _MMIO_PLANE_GAMC()

2024-05-10 Thread Ville Syrjala
From: Ville Syrjälä _MMIO_PLANE_GAMC() is some leftover macro that is never used. Get rid of it. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/i915_reg.h | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index

[PATCH 00/16] drm/i915: skl+ plane register stuff

2024-05-10 Thread Ville Syrjala
From: Ville Syrjälä Bunch of refactoring around skl+ plane registers. Ville Syrjälä (16): drm/i915: Nuke _MMIO_PLANE_GAMC() drm/i915: Extract skl_universal_plane_regs.h drm/i915: Extract intel_cursor_regs.h drm/i915: Move skl+ wm/ddb registers to proper headers drm/i915/gvt: Use the

[PATCH v2 8/9] drm/i915: Cleanup fbdev fb setup

2024-05-10 Thread Ville Syrjala
From: Ville Syrjälä We use a mix of 'intel_fb' vs. 'ifbdev->fb' in the same function. Both should be pointing at the same thing. Make things less confusing by just getting existing fb from 'ifbdev->fb' at the start and then sticking with the local 'fb' (renamed from the 'intel_fb') until the

[PATCH v2 7/9] drm/i915: Change intel_fbdev_fb_alloc() return type

2024-05-10 Thread Ville Syrjala
From: Ville Syrjälä Change intel_fbdev_fb_alloc() to return struct intel_fb instead of struct drm_framebuffer. Let's us eliminate some annoying aliasing variables in the fbdev setup code. v2: Assing the results to the correct variable (Jani) Fix xe's copy Signed-off-by: Ville Syrjälä ---

[PATCH] drm/xe: Nuke xe's copy of intel_fbdev_fb.h

2024-05-06 Thread Ville Syrjala
From: Ville Syrjälä For some reason xe and i915 each have an identical (fortunately) copy of intel_fbdev_fb.h. The xe copy actually only gets included by xe's intel_fbdev_fb.c, and the i915 copy by everyone else, include intel_fbdev.c which is the actual caller of the functions declared in the

[PATCH 9/9] drm/i915: Rename the fb pinning functions to indicate the address space

2024-05-06 Thread Ville Syrjala
From: Ville Syrjälä Rename the fb pinning functions such that their name directly informs us what gets pinned into which address space. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/intel_dpt.c | 6 +-- drivers/gpu/drm/i915/display/intel_dpt.h | 6 +--

[PATCH 8/9] drm/i915: Cleanup fbdev fb setup

2024-05-06 Thread Ville Syrjala
From: Ville Syrjälä We use a mix of 'fb' vs. 'ifbdev->fb' in the same function. Both should be pointing at the same thing. Make things less confusing by just getting existing fb from 'ifbdev->fb' at the start and then sticking with the local 'fb' until the very end. And we'll also change

[PATCH 7/9] drm/i915: Change intel_fbdev_fb_alloc() reuturn type

2024-05-06 Thread Ville Syrjala
From: Ville Syrjälä Change intel_fbdev_fb_alloc() to return struct intel_fb instead of struct drm_framebuffer. Let's us eliminate some annoying aliasing variables in the fbdev setup code. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/intel_fbdev.c| 10 +-

[PATCH 6/9] drm/i915: Constify 'fb' in during pinning

2024-05-06 Thread Ville Syrjala
From: Ville Syrjälä Make the 'fb' pointers const in the pinning code. We never want to mutate these. Also nuke a few aliasing fb vs. intel_fb cases by just using the more specific type everywhere in the same function. Signed-off-by: Ville Syrjälä ---

[PATCH 5/9] drm/i915: Polish types in fb calculations

2024-05-06 Thread Ville Syrjala
From: Ville Syrjälä Be a bit more consistent in our use of integer types in the fb related calculatiosn. u32 we generally only use for ggtt offsets and such, and everything else can be regular (unsigned) ints. There's also an overabundance of consts for local variables in

[PATCH 4/9] drm/i915: Extract intel_plane_needs_physical()

2024-05-06 Thread Ville Syrjala
From: Ville Syrjälä Pull the "does this plane need a physical address?" check into a small helper. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/intel_atomic_plane.c | 8 drivers/gpu/drm/i915/display/intel_atomic_plane.h | 1 +

[PATCH 3/9] drm/i915: Drop 'uses_fence' parameter from intel_pin_fb_obj_dpt()

2024-05-06 Thread Ville Syrjala
From: Ville Syrjälä Fence regions are only relevant for GGTT, not DPT. Drop the pointless 'uses_fence' argument from intel_pin_fb_obj_dpt(). Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/intel_fb_pin.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git

[PATCH 2/9] drm/i915: Clean up skl+ plane stride limits

2024-05-06 Thread Ville Syrjala
From: Ville Syrjälä skl_plane_max_stride() is pretty messy. Streamline it and split it into clear skl+ vs. adl+ variants. TODO: Deal with icl and tgl strude limits properly Signed-off-by: Ville Syrjälä --- .../drm/i915/display/skl_universal_plane.c| 65 +++ 1 file

[PATCH 1/9] drm/i915: Split gen2 vs. gen3 .max_stride()

2024-05-06 Thread Ville Syrjala
From: Ville Syrjälä Plane .max_stride() is alreayd a vfunc so having one made up of two branches based on the display version is silly. Split i9xx_plane_max_stride() into gen2 vs. gen3 variants so that we get rid of said check. Signed-off-by: Ville Syrjälä ---

[PATCH 0/9] drm/i915: Plane fb refactoring

2024-05-06 Thread Ville Syrjala
From: Ville Syrjälä A bit of cleanup/refactoring around plane fb stuff. This is mainly prep work for a slightly bigger rework of alignment handling. Ville Syrjälä (9): drm/i915: Split gen2 vs. gen3 .max_stride() drm/i915: Clean up skl+ plane stride limits drm/i915: Drop 'uses_fence'

[PATCH 35/35] drm/i915/bios: Define VBT block 253 (PRD Table) contents

2024-05-03 Thread Ville Syrjala
From: Ville Syrjälä Define the contents of VBT block 253 (PRD Table). Unfortunately the block has two definitions, with the cutoff supposedly happening on ICL vs. TGL. Also according to some notes it might be that the VBIOS (if that's still a thing) still uses the old definition even on TGL+.

[PATCH 34/35] drm/i915/bios: Define VBT block 252 (int15 Hook)

2024-05-03 Thread Ville Syrjala
From: Ville Syrjälä Declare that VBT block 252 is the "int15 hook". This is some VBIOS only juju so don't bother with a full definition. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/intel_vbt_defs.h | 1 + 1 file changed, 1 insertion(+) diff --git

[PATCH 33/35] drm/i915/bios: Define VBT block 55 (Compression Parameters)

2024-05-03 Thread Ville Syrjala
From: Ville Syrjälä Define the contents of the obsolete VBT block 55 (Compression Parameters). This was some early attempt at defining the compression parameters. However the spec says: "This block is obsolete and should not be consumed for any compression programming." Block 56 is the

[PATCH 32/35] drm/i915/bios: Define VBT block 50 (MIPI) contents

2024-05-03 Thread Ville Syrjala
From: Ville Syrjälä Define the contents of VBT block 50 (MIPI). This was some easly attempt at a MIPI DSI stuff. I'm not sure this was ever actually used (I certainly don't have any VBTs with this block), but here's some kind of definition for it anyway. Signed-off-by: Ville Syrjälä ---

[PATCH 31/35] drm/i915/bios: Define VBT block 57 (Vswing PreEmphasis Table) contents

2024-05-03 Thread Ville Syrjala
From: Ville Syrjälä Define the contents of VBT block 57 (Vswing PreEmphasis Table). The contents is highly platform specific. The columns of the table corresponding to some set of PHY/etc registers. The rows corresponding to all legal vswing+pre-emphasis combinations (ie. should be 10 rows in

[PATCH 30/35] drm/i915/bios: Define VBT block 55 (RGB Palette Table) contents

2024-05-03 Thread Ville Syrjala
From: Ville Syrjälä Define the contents of VBT block 55 (RGB Palette Table). Note that I've not actually seen any real world VBTs with this block. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/intel_vbt_defs.h | 12 1 file changed, 12 insertions(+) diff --git

[PATCH 29/35] drm/i915/bios: Define VBT block 51 (Fixed Set Mode Table) contents

2024-05-03 Thread Ville Syrjala
From: Ville Syrjälä Define the contents of VBT block 51 (Fixed Set Mode Table). Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/intel_vbt_defs.h | 11 +++ 1 file changed, 11 insertions(+) diff --git a/drivers/gpu/drm/i915/display/intel_vbt_defs.h

[PATCH 28/35] drm/i915/bios: Define VBT block 46 (Chromaticity For Narrow Gamut Panel) contents

2024-05-03 Thread Ville Syrjala
From: Ville Syrjälä Define the contents of VBT block 46 (Chromaticity For Narrow Gamut Panel). One entry per panel. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/intel_vbt_defs.h | 26 +++ 1 file changed, 26 insertions(+) diff --git

[PATCH 27/35] drm/i915/bios: Define VBT block 45 (eDP BFI) contents

2024-05-03 Thread Ville Syrjala
From: Ville Syrjälä Define the contents of VBT block 45 (eDP BFI). Note that I've not actually seen any real world VBTs with this block. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/intel_vbt_defs.h | 17 + 1 file changed, 17 insertions(+) diff --git

[PATCH 26/35] drm/i915/bios: Define VBT block 28 (EFP DTD) contents

2024-05-03 Thread Ville Syrjala
From: Ville Syrjälä Define the contents of VBT block 28 (EFP DTD). Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/intel_vbt_defs.h | 9 + 1 file changed, 9 insertions(+) diff --git a/drivers/gpu/drm/i915/display/intel_vbt_defs.h

[PATCH 25/35] drm/i915/bios: Define VBT block 26 (TV Options) contents

2024-05-03 Thread Ville Syrjala
From: Ville Syrjälä Define the contents of VBT block 26 (TV Options). Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/intel_vbt_defs.h | 12 1 file changed, 12 insertions(+) diff --git a/drivers/gpu/drm/i915/display/intel_vbt_defs.h

[PATCH 24/35] drm/i915/bios: Define VBT block 25 (SDVO LVDS PPS) contents

2024-05-03 Thread Ville Syrjala
From: Ville Syrjälä Define the contents of VBT block 25 (SDVO LVDS PPS). Not 100% sure about the order of the fields as this is not documented in the VBT spec anymore, but this order matches what is included as part of the power sequencing SDVO commands (struct sdvo_panel_power_sequencing).

[PATCH 23/35] drm/i915/bios: Define VBT block 24 (SDVO LVDS PnP ID) contents

2024-05-03 Thread Ville Syrjala
From: Ville Syrjälä Define the contents of VBT block 24 (SDVO LVDS PnP ID). The descriotion is not part of the VBT spec anymore, but the layout is rather obsvious. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/intel_vbt_defs.h | 8 1 file changed, 8 insertions(+)

[PATCH 22/35] drm/i915/bios: Define VBT block 21 (EFP List) contents

2024-05-03 Thread Ville Syrjala
From: Ville Syrjälä Define the contents of VBT block 21 (EFP List). Specs are nowhere to be found, but real world data suggests that each entry is just the first four bytes of the EDID PnP ID structure. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/intel_vbt_defs.h | 15

[PATCH 21/35] drm/i915/bios: Define VBT block 20 (OEM Customizable Modes) contents

2024-05-03 Thread Ville Syrjala
From: Ville Syrjälä Define the contents of VBT block 20 (OEM Customizable Modes). Each entry is either 26 or 28 bytes, depending on the BDB version. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/intel_vbt_defs.h | 24 +++ 1 file changed, 24 insertions(+) diff

[PATCH 20/35] drm/i915/bios: Define VBT blocks 19, 30, 32 (Display Configuration Removal Table) contents

2024-05-03 Thread Ville Syrjala
From: Ville Syrjälä Define the contenst is VBT blocks 19,30,32 (Display Configuration Removal Table) contents. There are three variants of this block: pre-IVB, IVB, HSW+, with each having slightly different entries. Curiously many HSW/BDW machines seem to have both the IVB and HSW+ variants in

[PATCH 19/35] drm/i915/bios: Define VBT blocks 16, 29, 31 (Toggle List) contents

2024-05-03 Thread Ville Syrjala
From: Ville Syrjälä Define the contenst is VBT blocks 16,19,31 (Toggle List). There are three variants of this block: pre-IVB, IVB, HSW+, with each having slightly different entries. Curiously many HSW/BDW machines seem to have both the IVB and HSW+ variants in their VBTs simultanously. No idea

[PATCH 16/35] drm/i915/bios: Define ALM only VBT block 9 contents

2024-05-03 Thread Ville Syrjala
From: Ville Syrjälä For some reason ALM VBT has two dot clock override tables. One as the normal block 15 and a second one as block 9. The table in block 9 has no row_size/num_rows information. On my Fujitsu Lifebook S6010 only the block 9 table has actual data in it. Block 15 is present but

[PATCH 18/35] drm/i915/bios: Define VBT block 18 (Driver Rotation) contents

2024-05-03 Thread Ville Syrjala
From: Ville Syrjälä Define the contents of block 18 (Driver Rotation). Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/intel_vbt_defs.h | 12 1 file changed, 12 insertions(+) diff --git a/drivers/gpu/drm/i915/display/intel_vbt_defs.h

[PATCH 17/35] drm/i915/bios: Define VBT block 17 (SV Test Functions) contents

2024-05-03 Thread Ville Syrjala
From: Ville Syrjälä Define the contents of VBT block 17 (SV Test Functions). Nothing real here for us, but might as well define it for completeness. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/intel_vbt_defs.h | 9 + 1 file changed, 9 insertions(+) diff --git

[PATCH 15/35] drm/i915/bios: Define VBT block 15 (Dot Clock Override Table) contents

2024-05-03 Thread Ville Syrjala
From: Ville Syrjälä Define the contents of VBT block 15 (Dot Clock Override Table) The contents were reverse engineered by intuition. The gen2 stuff seems solid as I can verify that against real world VBT data. The gen3 stuff less so as all the gen3+ VBTs I have just filla the entire block with

[PATCH 14/35] drm/i915/bios: Define VBT block 12 (Driver Persistent Algorithm) contents

2024-05-03 Thread Ville Syrjala
From: Ville Syrjälä Define the contents of VBT block 12 (Driver Persistent Algorithm). Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/intel_vbt_defs.h | 19 +++ 1 file changed, 19 insertions(+) diff --git a/drivers/gpu/drm/i915/display/intel_vbt_defs.h

[PATCH 13/35] drm/i915/bios: Define VBT block 10 (Mode Removal Table) contents

2024-05-03 Thread Ville Syrjala
From: Ville Syrjälä Define the contents of VBT block 10 (Mode Removal Table). There seem to be two variants: - 8 byte entries for desktop systems - 10 byte entries for mobile systems, with the extra panel_flags being a bitmask of LFPs It seems starting from HSW only the mobile variant is

[PATCH 12/35] drm/i915/bios: Define VBT blocks 6, 7, 8 (register tables) contents

2024-05-03 Thread Ville Syrjala
From: Ville Syrjälä Define the contents for VBT blocks: - Block 6 (Extended MMIO Register Table) - Block 7 (IO Software Flag Table) - Block 8 (MMIO SWF Register Table) All of these use the same basic layout, with two known variants: - data_access_size==0xce -> offset,value tuples are u8,u8 -

[PATCH 11/35] drm/i915/bios: Define VBT block 5 (Generic Mode Table)

2024-05-03 Thread Ville Syrjala
From: Ville Syrjälä Define the contents of VBT block 5 (Generic Mode Table). Details were mostly gleaned from some VBIOS sources. There are apparently two variants of the block: ALM only vs. MGM, defined here as bdb_generic_mode_table_alm and bdb_generic_mode_table_mgm. And those are the only

[PATCH 10/35] drm/i915/bios: Define VBT block 4 (Mode Support List) contents

2024-05-03 Thread Ville Syrjala
From: Ville Syrjälä Define the contents of VBT block 4 (Mode Support List). Slightly crazy layout with a variable length list at the start, followed by the length of said list. No real idea what these "Intel mode numbers" really are. What I see in real world VBTs seems to be always the same

[PATCH 09/35] drm/i915/bios: Define VBT block 3 (Display Toggle Option) contents

2024-05-03 Thread Ville Syrjala
From: Ville Syrjälä Define the contents of VBT block 3 (Display Toggle Option). On modern VBTs this is just a single byte, but on ALM there is also some extra to do with toggle lists or something. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/intel_vbt_defs.h | 12

[PATCH 08/35] drm/i915/bios: Add version notes for some blocks

2024-05-03 Thread Ville Syrjala
From: Ville Syrjälä Document which VBT blocks were defined in which BDB version, for the cases where the spec actually states this accurately. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/intel_vbt_defs.h | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff

[PATCH 07/35] drm/i915/bios: Flag "VBIOS only" VBT data blocks

2024-05-03 Thread Ville Syrjala
From: Ville Syrjälä Several data blocks are mean to be consumbed by VBIOS only. Flag them as such. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/intel_vbt_defs.h | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git

[PATCH 06/35] drm/i915/bios: Define "TV" child device handle

2024-05-03 Thread Ville Syrjala
From: Ville Syrjälä Child device 0x2 used to be "TV" until redefined to mean EFP5 in version 215. Add a define for the old meaning as well. Technically it was probably deprecated a lot before version 215 since native TV encoders were last seen on CTG, and SDVO was fully gone by HSW. So

[PATCH 05/35] drm/i915/bios: Rename SDVO DTD blocks a bit

2024-05-03 Thread Ville Syrjala
From: Ville Syrjälä The SDVO LVDS blocks are specifically about LVDS, so stick to naming that reflects that. This also makes the names match the spec. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/intel_bios.c | 23 +--

[PATCH 04/35] drm/i915/bios: Get rid of "LVDS" from all LFP data stuff

2024-05-03 Thread Ville Syrjala
From: Ville Syrjälä The LFP data applies to all kinds of display interfaces, so stop calling things by the "LVDS" name. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/intel_bios.c | 178 +- .../drm/i915/display/intel_display_types.h| 2 +-

[PATCH 03/35] drm/i915/bios: Indicate which VBT structures are based on EDID

2024-05-03 Thread Ville Syrjala
From: Ville Syrjälä VBT reuses a bunch of EDID data structures. Flag those as such for clarity. I chose "bdb_edid_" as the namespace for these. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/intel_bios.c | 28 +++--- drivers/gpu/drm/i915/display/intel_vbt_defs.h | 95

[PATCH 02/35] drm/i915/bios: Remove version number comment from DEVICE_HANDLE_EFP4

2024-05-03 Thread Ville Syrjala
From: Ville Syrjälä DEVICE_HANDLE_EFP4 has actually been in use since the very beginning, or at least something has been occupying that bit because old VBTs actually use it, and it definitely looks to be about external displays given how its used. So let's ignore what the current spec claims and

[PATCH 01/35] drm/i915/bios: Define eDP DSC disable bit

2024-05-03 Thread Ville Syrjala
From: Ville Syrjälä There's a new "DSC disable" bit in the eDP VBT block. Define it. TODO: actually use it? Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/intel_vbt_defs.h | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/i915/display/intel_vbt_defs.h

[PATCH 00/35] drm/i915/bios: Define (almost) all BDB blocks

2024-05-03 Thread Ville Syrjala
From: Ville Syrjälä I got curious about what gems (or turds) might be hiding inside the BDB blocks we aren't parsing. So I undertook the effort to dig up the definition for pretty much all of them. Unfortunately I didn't find anything really interesting, but might as well stick the definitions

[PATCH 3/3] drm/i915: Remove counter productive REGION_* wrappers

2024-05-02 Thread Ville Syrjala
From: Ville Syrjälä This extra macro level between the region IDs and their bitmasks just makes it harder to see what is used where. Get rid of the wrappers. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/i915_pci.c | 6 +++---

[PATCH 1/3] drm/i915: Fix HAS_REGION() usage in intel_gt_probe_lmem()

2024-05-02 Thread Ville Syrjala
From: Ville Syrjälä HAS_REGION() takes a bitmask, not the region ID. This causes the GEM_BUG_ON() to assert that the SMEM region is available rather than the intended LMEM region. No real harm since SMEM is always available, but also not checking what was intended. Signed-off-by: Ville Syrjälä

[PATCH 2/3] drm/i915: Pass the region ID rather than a bitmask to HAS_REGION()

2024-05-02 Thread Ville Syrjala
From: Ville Syrjälä The name 'HAS_REGION()' suggests we are checking for a single region, so seem more sensible to pass in the region ID rather than a bitmask. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/gt/intel_gt.c | 2 +- drivers/gpu/drm/i915/i915_drv.h| 4

[PATCH v2 4/5] drm/i915: Eliminate extra frame from skl-glk sync->async flip change

2024-04-30 Thread Ville Syrjala
From: Ville Syrjälä On bdw-glk the sync->async flip change takes an extra frame due to the double buffering behaviour of the async flip plane control bit. Since on skl+ we are now explicitly converting the first async flip to a sync flip (in order to allow changing the modifier and/or

[PATCH v2 5/5] drm/i915: s/need_async_flip_disable_wa/need_async_flip_toggle_wa/

2024-04-30 Thread Ville Syrjala
From: Ville Syrjälä Rename need_async_flip_disable_wa to need_async_flip_toggle_wa to better reflect the fact that we need to deal with the bad PLANE_CTL_ASYNC_FLIP double buffering behaviour going both ways. Reviewed-by: Arun R Murthy Signed-off-by: Ville Syrjälä ---

[PATCH v2 3/5] drm/i915: Allow the initial async flip to change modifier

2024-04-30 Thread Ville Syrjala
From: Ville Syrjälä With Xorg+modesetting on skl+ we see the following behaviour: 1. root pixmap is X-tiled 2. client submitted buffers can be Y-tiled (w/ 'Option "dmabuf_capable"') 3. we try to switch from the X-tiled buffer to the Y-tiled buffer using an async flip (when vsync is disabled).

[PATCH v2 2/5] drm/i915: Reject async flips if we need to change DDB/watermarks

2024-04-30 Thread Ville Syrjala
From: Ville Syrjälä DDB/watermarks are always double buffered on the vblank, so we can't safely change them during async flips. Currently this never happens, but we'll be making changing between sync and async flips a bit more flexible, in which case we can actually end up here. Reviewed-by:

[PATCH v2 1/5] drm/i915: Align PLANE_SURF to 16k on ADL for async flips

2024-04-30 Thread Ville Syrjala
From: Ville Syrjälä On ADL async flips apparently generate DMAR and GGTT faults (with accompanying visual glitches) unless PLANE_SURF is aligned to at least 16k. Bump up the alignment to 16k. TODO: analyze things better to figure out what is really going on here Reviewed-by: Arun R

[PATCH v2 0/5] drm/i915: Allow the first async flip to change modifier

2024-04-30 Thread Ville Syrjala
From: Ville Syrjälä Xorg/modesetting expects to be able to change the modifier already when submitting the first async flip. Let's convert the first async flip to a sync flip so that we can accommodate it. For now I limit this behaviour to skl+ since earlier platforms don't support async flips

[PATCH 14/14] drm/i915/dpio: Extract vlv_dpio_phy_regs.h

2024-04-22 Thread Ville Syrjala
From: Ville Syrjälä Pull the VLV/CHV DPIO PHY sideband registers to their own file. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/intel_display.c | 1 + .../i915/display/intel_display_power_well.c | 1 + drivers/gpu/drm/i915/display/intel_dpio_phy.c | 1 +

[PATCH 13/14] drm/i915/dpio: Clean up the vlv/chv PHY register bits

2024-04-22 Thread Ville Syrjala
From: Ville Syrjälä Use REG_BIT() & co. for the vlv/chv DPIO PHY registers. Signed-off-by: Ville Syrjälä --- .../i915/display/intel_display_power_well.c | 7 +- drivers/gpu/drm/i915/display/intel_dpio_phy.c | 59 ++-- drivers/gpu/drm/i915/display/intel_dpll.c | 85 +++--

[PATCH 12/14] drm/i915/dpio: Clean up VLV/CHV DPIO PHY register defines

2024-04-22 Thread Ville Syrjala
From: Ville Syrjälä The DPIO PHY registers follow clear numbering rules. Express those in a few macros to get rid of the hand calculated final offsets. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/intel_dpio_phy.c | 2 +- drivers/gpu/drm/i915/i915_reg.h | 271

[PATCH 11/14] drm/i915/dpio: Rename a few CHV DPIO PHY registers

2024-04-22 Thread Ville Syrjala
From: Ville Syrjälä Drop the leading underscore from the CHV PHY common lane register definitons. We use these directly from actual code so the underscore here is misleading as usually it indicates an intermediate define that shouldn't be used directly. Signed-off-by: Ville Syrjälä ---

[PATCH 09/14] drm/i915/dpio: Derive the phy from the port rather than pipe in encoder hooks

2024-04-22 Thread Ville Syrjala
From: Ville Syrjälä In the encoder hooks we are dealing primarily with the encoder, so derive the DPIO PHY from the encoder rather than the pipe. Technically this doesn't matter as we can't cross connect pipes<->port across PHY boundaries, but it does conveny the intention more accurately.

[PATCH 10/14] drm/i915/dpio: Give VLV DPIO group register a clearer name

2024-04-22 Thread Ville Syrjala
From: Ville Syrjälä Include _GRP in VLV DPOP PHY group access register define names. Makes it more obvious where the accesses will land. Also matches the naming used by BXT already. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/intel_dpio_phy.c | 34 +++

[PATCH 06/14] drm/i915/dpio: Rename some variables

2024-04-22 Thread Ville Syrjala
From: Ville Syrjälä Use a constent 'tmp' as the variable name for the register values during rmw when we don't deal with multiple registers in parallel. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/intel_dpll.c | 97 +++ 1 file changed, 48 insertions(+),

[PATCH 08/14] drm/i915/dpio: s/pipe/ch/

2024-04-22 Thread Ville Syrjala
From: Ville Syrjälä Stop using 'pipe' directly as the DPIO PHY channel. This does happen to work on VLV since it just has the one PHY with CH0==pipe A and CH1==pipe B. But explicitly converting the thing to the right enum makes the whole thing less confusing. Signed-off-by: Ville Syrjälä ---

[PATCH 07/14] drm/i915/dpio: s/port/ch/

2024-04-22 Thread Ville Syrjala
From: Ville Syrjälä Stop calling the DPIO PHY channel "port". Just say "ch", which is already used in a bunch of places. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/intel_dpio_phy.c | 44 +++ drivers/gpu/drm/i915/display/intel_dpll.c | 54 +--

[PATCH 05/14] drm/i915/dpio: Remove pointless variables from vlv/chv DPLL code

2024-04-22 Thread Ville Syrjala
From: Ville Syrjälä Drop all the local variables for the DPLL dividers for vlv/chv and just consult the state directly. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/intel_dpll.c | 62 ++- 1 file changed, 27 insertions(+), 35 deletions(-) diff --git

[PATCH 04/14] drm/i915/dpio: Fix VLV DPIO PLL register dword numbering

2024-04-22 Thread Ville Syrjala
From: Ville Syrjälä The spreadsheet defines the PLL register block as having the dwords in the following order: block dwordsoffsets PLL10x0-0x7 0x00-0x1f PLL20x0-0x7 0x20-0x2f PLL1ext 0x10-0x1f 0x40-0x5f PLL2ext 0x10-0x1f 0x60-0x7f So dword indexes 0x8-0xf don't even exist.

[PATCH 03/14] drm/i915/dpio: s/VLV_PLL_DW9_BCAST/VLV_PCS_DW17_BCAST/

2024-04-22 Thread Ville Syrjala
From: Ville Syrjälä VLV_PLL_DW9_BCAST is actually VLV_PCS_DW17_BCAST. The address does kinda look like it goes to the PLL block on a first glance, but broadcast is special and doesn't even exist for the PLL (only PCS and TX have it). The fact that we use a broadcast write here is a bit sketchy

[PATCH 02/14] drm/i915/dpio: s/VLV_REF_DW13/VLV_REF_DW11/

2024-04-22 Thread Ville Syrjala
From: Ville Syrjälä Our VLV_REF_DW13 is actually VLV_REF_DW11. Rename it. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/intel_dpll.c | 8 drivers/gpu/drm/i915/i915_reg.h | 4 ++-- 2 files changed, 6 insertions(+), 6 deletions(-) diff --git

[PATCH 01/14] drm/i915/dpio: Remove pointless VLV_PCS01_DW8 read

2024-04-22 Thread Ville Syrjala
From: Ville Syrjälä We don't use the result of the VLV_PCS01_DW8 read at all, so don't read. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/intel_dpio_phy.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/i915/display/intel_dpio_phy.c

[PATCH 00/14] drm/i915: VLV/CHV DPIO register cleanup

2024-04-22 Thread Ville Syrjala
From: Ville Syrjälä Polish the VLV/CHV DPIO stuff and extract vlv_dpio_phy_regs.h to declutter i915_reg.h a bit. Ville Syrjälä (14): drm/i915/dpio: Remove pointless VLV_PCS01_DW8 read drm/i915/dpio: s/VLV_REF_DW13/VLV_REF_DW11/ drm/i915/dpio: s/VLV_PLL_DW9_BCAST/VLV_PCS_DW17_BCAST/

[PATCH v2 3/8] drm/i915/dpio: Extract bxt_dpio_phy_regs.h

2024-04-17 Thread Ville Syrjala
From: Ville Syrjälä Extract the BXT/GLK DPIO PHY register definitions into their own file. v2: Adjust gvt accordingly Reviewed-by: Jani Nikula Signed-off-by: Ville Syrjälä --- .../gpu/drm/i915/display/bxt_dpio_phy_regs.h | 273 ++

[PATCH v2 2/8] drm/i915/dpio: Add per-lane PHY TX register definitons for bxt/glk

2024-04-17 Thread Ville Syrjala
From: Ville Syrjälä Add consistent definitions for the per-lane PHY TX registers on bxt/glk. The current situation is a slight mess with some registers having a LN0 define, while others have a parametrized per-lane definition. v2: Adjust gvt accordingly Reviewed-by: Jani Nikula Signed-off-by:

[PATCH 16/18] drm/i915: Carve up struct intel_dpll_hw_state

2024-04-12 Thread Ville Syrjala
From: Ville Syrjälä struct intel_dpll_hw_state has a spot for all possible PLL registers across all platforms (well, apart from cx0/snps). This makes it rather confusing when trying to figure out which members belong to which platform(s). Split the struct up into five different platform

[PATCH 15/18] drm/i915: Add local DPLL 'hw_state' variables

2024-04-12 Thread Ville Syrjala
From: Ville Syrjälä Add some local 'hw_state' variables to the old DPLL code. Will help with unionizing the dpll_hw_state later. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/intel_dpll.c | 98 +-- 1 file changed, 54 insertions(+), 44 deletions(-) diff

<    1   2   3   4   5   6   7   8   9   10   >