drm/i915/dpio: s/port/ch/

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ä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240422083457.23815-8-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/dpio: Rename some variables

Use a consistent '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ä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240422083457.23815-7-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/dpio: Remove pointless variables from vlv/chv DPLL code

Drop all the local variables for the DPLL dividers for vlv/chv
and just consult the state directly.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240422083457.23815-6-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/dpio: Fix VLV DPIO PLL register dword numbering

The spreadsheet defines the PLL register block as having
the dwords in the following order:

block   dwords    offsets
PLL1    0x0-0x7   0x00-0x1f
PLL2    0x0-0x7   0x20-0x3f
PLL1ext 0x10-0x1f 0x40-0x5f
PLL2ext 0x10-0x1f 0x60-0x7f

So dword indexes 0x8-0xf don't even exist. Renumber
our register defines to match.

Note that the spreadsheet used hex numbering whereas our
defiens are in decimal. Perhaps we should change that?

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240422083457.23815-5-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/dpio: s/VLV_PLL_DW9_BCAST/VLV_PCS_DW17_BCAST/

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
IMO since we're now blasting the register to all PCS splines
across the whole PHY. So the PCS registers in the other channel
(ie. other pipe/port) will also be written. But I guess the
fact that we always write the same value should make this a nop
even if the other channel is already enabled (assuming the VBIOS/GOP
didn't screw up and use some other value...).

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240422083457.23815-4-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/dpio: s/VLV_REF_DW13/VLV_REF_DW11/

Our VLV_REF_DW13 is actually VLV_REF_DW11. Rename it.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240422083457.23815-3-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/dpio: Remove pointless VLV_PCS01_DW8 read

We don't use the result of the VLV_PCS01_DW8 read at all,
so don't read.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240422083457.23815-2-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: pass dev_priv explicitly to PIPE_WGC_C22

Avoid the implicit dev_priv local variable use, and pass dev_priv
explicitly to the PIPE_WGC_C22 register macro.

Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/0a07f615c574040094b37c861078e41daf53c706.1714399071.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: pass dev_priv explicitly to PIPE_WGC_C21_C20

Avoid the implicit dev_priv local variable use, and pass dev_priv
explicitly to the PIPE_WGC_C21_C20 register macro.

Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/af39047d304f8a5c3c7a643f702f66c06ea5d638.1714399071.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: pass dev_priv explicitly to PIPE_WGC_C12

Avoid the implicit dev_priv local variable use, and pass dev_priv
explicitly to the PIPE_WGC_C12 register macro.

Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/62a748b685f253151b17c101dec75351577f30c0.1714399071.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: pass dev_priv explicitly to PIPE_WGC_C11_C10

Avoid the implicit dev_priv local variable use, and pass dev_priv
explicitly to the PIPE_WGC_C11_C10 register macro.

Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/3f7aae89cf63760bca43b54102c76b3ed2cf8735.1714399071.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: pass dev_priv explicitly to PIPE_WGC_C02

Avoid the implicit dev_priv local variable use, and pass dev_priv
explicitly to the PIPE_WGC_C02 register macro.

Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/550d4e787445802236f0bf89e4d2f4f32cbd6d75.1714399071.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: pass dev_priv explicitly to PIPE_WGC_C01_C00

Avoid the implicit dev_priv local variable use, and pass dev_priv
explicitly to the PIPE_WGC_C01_C00 register macro.

Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/85b3db6e666a7a629b10b482b7e7043d52d30511.1714399071.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: pass dev_priv explicitly to PALETTE

Avoid the implicit dev_priv local variable use, and pass dev_priv
explicitly to the PALETTE register macro.

Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/bf07d29cefef23ebd5d54fbb0d3bf7e41d132d93.1714399071.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/display: split out intel_sprite_regs.h from i915_reg.h

Clean up i915_reg.h.

v2: Drop a redundant comment (Ville)

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/679b7395a78c53006ac07448706f1809b74810de.1714128645.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/display: split out intel_fbc_regs.h from i915_reg.h

Clean up i915_reg.h.

v2: Drop chicken regs and comments (Ville)

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/aa9b5d8adefbe97e1e37c9cfada3ab1581b0e8d5.1714128645.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/color: move palette registers to intel_color_regs.h

For some reason the paletter registers were missed when adding
intel_color_regs.h. Finish the job. Adjust some comments while at it.

v2: Fix comments (Ville)

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1322f577b113b8fc1a6c2ef35340fc3c599b4bcb.1714128645.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/audio: move LPE audio regs to intel_audio_regs.h

There are too few registers to warrant a dedicated file for LPE audio
regs, but the audio reg file is better than i915_reg.h.

v2: Rebase

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/b5ee35309b2e0905aaa12d944b3d379c45a8a0bd.1714128645.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/{i915, xe}: Implement fbdev emulation as in-kernel client

Replace all code that initializes or releases fbdev emulation
throughout the driver. Instead initialize the fbdev client by a
single call to intel_fbdev_setup() after i915 has registered its
DRM device. Just like similar code in other drivers, i915 fbdev
emulation now acts like a regular DRM client. Do the same for xe.

The fbdev client setup consists of the initial preparation and the
hot-plugging of the display. The latter creates the fbdev device
and sets up the fbdev framebuffer. The setup performs display
hot-plugging once. If no display can be detected, DRM probe helpers
re-run the detection on each hotplug event.

A call to drm_client_dev_unregister() releases all in-kernel clients
automatically. No further action is required within i915. If the fbdev
framebuffer has been fully set up, struct fb_ops.fb_destroy implements
the release. For partially initialized emulation, the fbdev client
reverts the initial setup. Do the same for xe and remove its call to
intel_fbdev_fini().

v8:
- setup client in intel_display_driver_register (Jouni)
- mention xe in commit message

v7:
- update xe driver
- reword commit message

v6:
- use 'i915' for i915 device (Jouni)
- remove unnecessary code for non-atomic mode setting (Jouni, Ville)
- fix function name in commit message (Jouni)

v3:
-  as before, silently ignore devices without displays

v2:
-  let drm_client_register() handle initial hotplug
-  fix driver name in error message (Jani)
-  fix non-fbdev build (kernel test robot)

Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Acked-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240409081029.17843-7-tzimmermann@suse.de
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/{i915,xe}: Implement fbdev client callbacks

Move code from ad-hoc fbdev callbacks into DRM client functions
and remove the old callbacks. The functions instruct the client
to poll for changed output or restore the display.

The DRM core calls both, the old callbacks and the new client
helpers, from the same places. The new functions perform the same
operation as before, so there's no change in functionality.

Fox xe, remove xe_display_last_close(), which restored the fbdev
display. As with i915, the DRM core's drm_lastclose() performs
this operation automatically.

v8:
- mention xe in commit message

v7:
- update xe driver

v6:
- return errors from client callbacks (Jouni)

Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Acked-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240409081029.17843-6-tzimmermann@suse.de
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/{i915,xe}: Unregister in-kernel clients

Unregister all in-kernel clients before unloading the i915 driver. For
other drivers, drm_dev_unregister() does this automatically. As i915 and
xe do not use this helper, they have to perform the call by themselves.

Note that there are currently no in-kernel clients in i915 or xe. The
patch prepares the drivers for a related update of their fbdev support.

v8:
- unregister clients in intel_display_driver_unregister() (Jani)
- mention xe in commit message (Rodrigo, Jani)

v7:
- update xe driver

Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Acked-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240409081029.17843-5-tzimmermann@suse.de
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: Initialize fbdev DRM client with callback functions

Initialize i915's fbdev client by giving an instance of struct
drm_client_funcs to drm_client_init(). Also clean up with
drm_client_release().

Doing this in i915 prevents fbdev helpers from initializing and
releasing the client internally (see drm_fb_helper_init()). No
functional change yet; the client callbacks will be filled later.

v6:
- rename client to "intel-fbdev" (Jouni)

v2:
- call drm_fb_helper_unprepare() in error handling (Jani)
- fix typo in commit message (Sam)

Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Acked-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240409081029.17843-4-tzimmermann@suse.de
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: Move fbdev functions

Move functions within intel_fbdev.c to simplify later updates. Minor
style fixes to make checkpatch happy, but no functional changes.

v5:
- style fixes (checkpatch)

Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Acked-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240409081029.17843-3-tzimmermann@suse.de
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/client: Export drm_client_dev_unregister()

Export drm_client_dev_unregister() for use by the i915 driver. The
driver does not use drm_dev_unregister(), so it has to clean up the
in-kernel DRM clients by itself.

Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Acked-by: Lucas De Marchi <lucas.demarchi@intel.com>
Acked-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20240409081029.17843-2-tzimmermann@suse.de
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: pass dev_priv to _MMIO_PIPE2, _MMIO_TRANS2, _MMIO_CURSOR2

Pass the dev_priv parameter to the low-level helpers, and move the
implicit dev_priv usage one level higher.

sed -i "s/\(_MMIO_PIPE2(\|_MMIO_TRANS2(\|_MMIO_CURSOR2(\)/\1dev_priv, /" \
$(git ls-files drivers/gpu/drm/i915)

Name the parameter "display", as the generics allow it to be display
already.

Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/3a865664898586ff6cb8e74eab3d1f36eafc0557.1713890614.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: convert _MMIO_PIPE3()/_MMIO_PORT3() to accept base

Most users of _MMIO_PIPE3() and _MMIO_PORT3() need to add the MMIO base
to the registers. Convert the macros to _MMIO_BASE_PIPE3() and
_MMIO_BASE_PORT3() to move the base addition until after the register
selection. If the register address depends on DISPLAY_MMIO_BASE(), this
removes the need to figure the base out for each register, and it only
needs to be added once.

Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/4b95f125f5021abc00b5fc661b2728f1b583c01e.1713890614.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/dsi: pass display to register macros instead of implicit variable

Stop relying on the dev_priv local variable in the DSI register
macros. Pass struct intel_display pointer to the macros. Move the MIPI
DSI MMIO base selection to a different level, passing it to _MMIO_MIPI()
and doing the addition there.

Start using the local display variable for all intel_de_* usage, and
opportunistically use it for other things than display registers as
well.

Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/6dd52f3fce3527242479aadc276d05de74ceae5d.1713520813.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/dsi: unify connector/encoder type and name usage

Stop using struct drm_* local variables and parameters where
possible. Drop the intel_ prefix from struct intel_encoder and
intel_connector local variable and parameter names. Drop useless
intermediate variables.

Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/7aa8fbaa2ecbe2400255964d49aba40cfe0479c5.1713520813.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/dsi: add VLV_ prefix to VLV only register macros

All the BXT specific macros have BXT_ prefix, do the same for VLV for
consistency. This is helpful because the platform specific macros can
use the static MIPI MMIO base rather than dynamic.

Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/7e101167c52746748dbff739bc9247a664ca2840.1713520813.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/dsi: remove unused _MIPIA_AUTOPWG register definition

There are other unused registers, but this is also unusable and
inadequate. Remove.

Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/57afda02856a68f78fe4d30384d4f7b352b9a812.1713520813.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/display: move dmc_firmware_path to display params

The dmc_firmware_path parameter is clearly a display parameter. Move it
there so it's available to both i915 and xe modules. This also cleans up
the ugly member in struct xe_device.

v2:
- New try with the NULL/"" param value issue resolved

Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com>
Acked-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/7c8223b68fdafbc72bee0bf5afdb2ab15261cf00.1713519628.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/dmc: change how to disable DMC firmware using module param

The distinction between the dmc_firmware_path module param being NULL
and the empty string "" is problematic. It's not possible to set the
parameter back to NULL via sysfs or debugfs. Remove the distinction, and
consider NULL and the empty string to be the same thing, and use the
platform default for them.

This removes the possibility to disable DMC (and runtime PM) via
i915.dmc_firmware_path="". Instead, use "/dev/null" as the magic
firmware path to skip DMC firmware loading and disable runtime PM.

v2: Add support for i915.dmc_firmware_path="/dev/null" (Gustavo)

Cc: Gustavo Sousa <gustavo.sousa@intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com>
Acked-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/8695aca8a6643e36bb680bc2dcab97c637e70b00.1713519628.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/dmc: split out per-platform firmware path selection

The big if ladder clutters intel_dmc_init(). Split it out to a separate
function.

Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com>
Acked-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/fe3d7b2b18c317a2f924f2023271d38afee3b18a.1713519628.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/dmc: improve firmware parse failure propagation

Return failures from parse_dmc_fw() instead of relying on
intel_dmc_has_payload(). Handle and error report them slightly better,
including a new error message for when the firmware does not contain the
main program.

v2: Print specific error message for payload not found (Gustavo)

Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com>
Acked-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/18833681978ec3ac779cce943221cc5b532c7c45.1713519628.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/dmc: handle request_firmware() errors separately

Clarify request_firmware() error handling. Don't proceed to trying to
parse non-existent firmware or check for payload when request_firmware()
failed to begin with. There's no reason to release_firmware() either
when request_firmware() failed.

Also move the message about DMC firmware homepage here, as in other
cases the user probably has some firmware, although its parsing fails
for some reason.

Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com>
Acked-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/0654bb3480f8d2103225d26f665badead5495532.1713519628.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: Enable per-lane DP drive settings for bxt/glk

Now the bxt/glk PHY code is ready for per-lane drive settings
so enable it.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240412175818.29217-9-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/dpio: Program bxt/glk PHY TX registers per-lane

Program each bxt/glk PHY TX lane with its own settings
instead of blasting them all with the same stuff via
group access.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240412175818.29217-8-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/dpio: s/ddi/dpio/ for bxt/glk PHY stuff

Since all of this lives in intel_dpio_phy.c let's rename the
bxt/glk functions to have bxt_dpio_phy_ namespace.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240412175818.29217-7-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/dpio: Use intel_de_rmw() for BXT DPIO latency optim setup

Replace the hand rolled intel_de_rmw() with the real thing.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240412175818.29217-6-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/dpio: Introdude bxt_ddi_phy_rmw_grp()

Add a helper to do the "read from one per-lane register
and write to the group register" rmw cycle.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240412175818.29217-5-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/dpio: Extract bxt_dpio_phy_regs.h

Extract the BXT/GLK DPIO PHY register definitions into their own file.

v2: Adjust gvt accordingly

Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240417151232.32175-1-ville.syrjala@linux.intel.com

drm/i915/dpio: Add per-lane PHY TX register definitons for bxt/glk

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 <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240417151211.32135-1-ville.syrjala@linux.intel.com

drm/i915/dpio: Clean up bxt/glk PHY registers

Use REG_BIT() & co. for the bxt/glk PHY register definitons.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240412175818.29217-2-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/dp_mst: Enable HBLANK expansion quirk for UHBR rates

Enabling the 5k@60Hz uncompressed mode on the MediaTek/Dell U3224KBA
monitor results in a blank screen, at least on MTL platforms on UHBR
link rates with some (<30) uncompressed bpp values. Enabling compression
fixes the problem, so do that for now. Windows enables DSC always if the
sink supports it and forcing it to enable the mode without compression
leads to the same problem above (which suggests a panel issue with
uncompressed mode).

The same 5k mode on non-UHBR link rates is not affected and lower
resolution modes are not affected either. The problem is similar to the
one fixed by the HBLANK expansion quirk on Synaptics hubs, with the
difference that the problematic mode has a longer HBLANK duration. Also
the monitor doesn't report supporting HBLANK expansion; either its
internal MST hub does the expansion internally - similarly to the
Synaptics hub - or the issue has another root cause, but still related
to the mode's short HBLANK duration. Enable the quirk for the monitor
adjusting the detection for the above differences.

v2: Rebase on drm_dp_128132b_supported() change.

Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Tested-by: Khaled Almahallawy <khaled.almahallawy@intel.com>
Acked-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240417142217.457902-1-imre.deak@intel.com

drm/i915/dp_mst: Make HBLANK expansion quirk work for logical ports

The DPCD OUI of the logical port on a Dell UHBR monitor - on which the
AUX device is used to enable DSC - is all 0. To detect if the HBLANK
expansion quirk is required for this monitor use the OUI of the port's
parent instead.

Since in the above case the DPCD of both the logical port and the parent
port reports being a sink device (vs. branch device) type, read the
proper sink/branch OUI based on the DPCD device type.

This is required by a follow-up patch enabling the quirk for the above
Dell monitor.

Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240416221010.376865-11-imre.deak@intel.com

drm/dp_mst: Add drm_dp_mst_aux_for_parent()

Add a function to get the AUX device of the parent of an MST port, used
by a follow-up i915 patch in the patchset.

v2: Move drm_dp_mst_aux_for_parent() forward declaration to this patch
    (Ankit)

Cc: Lyude Paul <lyude@redhat.com>
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Acked-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240416221010.376865-10-imre.deak@intel.com

drm/dp_mst: Factor out drm_dp_mst_port_is_logical()

Factor out a function to check if an MST port is logical, used by a
follow-up i915 patch in the patchset.

v2: Move drm_dp_mst_aux_for_parent() forward declaration to the next
    patch. (Ankit)

Cc: Lyude Paul <lyude@redhat.com>
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Acked-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240416221010.376865-9-imre.deak@intel.com

drm/dp: Add drm_dp_128b132b_supported()

Factor out a function to check for 128b/132b channel coding support used
by a follow-up patch in the patchset.

v2: s/drm_dp_uhbr_channel_coding_supported()/drm_dp128b132b_supported()
    (Jani)

Cc: dri-devel@lists.freedesktop.org
Cc: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Manasi Navare <navaremanasi@chromium.org>
Acked-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240417141936.457796-1-imre.deak@intel.com

drm/i915/dp_mst: Sanitize calculating the DSC DPT bpp limit

Instead of checking each compressed bpp value against the maximum
DSC/DPT bpp, simplify things by calculating the maximum bpp upfront and
limiting the range of bpps looped over using this maximum.

While at it add a comment about the origin of the DSC/DPT bpp limit.

Bspec: 49259, 68912

Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240416221010.376865-7-imre.deak@intel.com

drm/i915/dp_mst: Account with the DSC DPT bpp limit on MTL

The DPT/DSC bpp limit should be accounted for on MTL platforms as well,
do so.

Bspec: 49259

Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240416221010.376865-6-imre.deak@intel.com

drm/i915/dp_mst: Account for channel coding efficiency in the DSC DPT bpp limit

The DSC DPT interface BW limit check should take into account the link
clock's (aka DDI clock in bspec) channel coding efficiency overhead.
Bspec suggests that the FEC overhead needs to be applied, however HW
people claim this isn't the case, nor is any overhead applicable.

However based on testing various 5k/6k modes both on the DELL U3224KBA
monitor and the Unigraf UCD-500 CTS test device, both the channel coding
efficiency (which includes the FEC overhead) and an additional 3%
overhead must be accounted for to get these modes working.

Bspec: 49259

v2:
- Apply an additional 3% overhead, add a commit log and code comment
  about these overheads and the relation to the Bspec BW limit formula.

Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240416221010.376865-5-imre.deak@intel.com

drm/i915/dp_mst: Fix BW limit check when calculating DSC DPT bpp

The DSC DPT bpp limit check should only fail if the available DPT BW is
less than the required BW, fix the check accordingly.

Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240416221010.376865-4-imre.deak@intel.com

drm/i915/dp_mst: Fix symbol clock when calculating the DSC DPT bpp limit

The expected link symbol clock unit when calculating the DSC DPT bpp
limit is kSymbols/sec, aligning with the dotclock's kPixels/sec unit
based on the crtc clock. As opposed to this port_clock is used - which
has a 10 kbits/sec unit - with the resulting symbol clock in 10
kSymbols/sec units (disregarding the rounding error for the 13.5Gbps
rate). Fix the calculation using the expected 10x factor.

Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240416221010.376865-3-imre.deak@intel.com

drm/i915/dp: Fix DSC line buffer depth programming

Fix the calculation of the DSC line buffer depth. This is limited both
by the source's and sink's maximum line buffer depth, but the former one
was not taken into account. On all Intel platform's the source's maximum
buffer depth is 13, so the overall limit is simply the minimum of the
source/sink's limit, regardless of the DSC version.

This leaves the DSI DSC line buffer depth calculation as-is, trusting
VBT.

On DSC version 1.2 for sinks reporting a maximum line buffer depth of 16
the line buffer depth was incorrectly programmed as 0, leading to a
corruption in color gradients / lines on the decompressed screen image.

Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Manasi Navare <navaremanasi@chromium.org>
Acked-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240416221010.376865-2-imre.deak@intel.com

drm/i915/display: force qgv check after the hw state readout

The current intel_bw_atomic_check do not check the possbility
of a sagv configuration change after the hw state readout.
Hence cannot update the sagv configuration until some other
relevant changes like data rates, number of planes etc. happen.
Introduce a flag to force qgv check in such cases.

Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Signed-off-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240405113533.338553-7-vinod.govindapillai@intel.com

drm/i915/display: handle systems with duplicate psf gv points

There could be multiple qgv and psf gv points with similar values.
Apparently pcode's handling of psf and qgv points are different. For
qgv case, pcode sets whatever is asked by the driver. But in case
of psf gv points, it compares the bw from points before setting the
mask. This can cause problems in scenarios where we have to disable
sagv by setting the highest bw point and there could be multiple
points with highest bw. So to set the maximum psf gv point, find
out all the points with the highest bw and set all together.

v1: - use the same treatment to qgv points as well (Vinod)

v2: - pcode confirms that for qgv points, it sets whatever the
      driver sets (Vinod)

Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Signed-off-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240405113533.338553-6-vinod.govindapillai@intel.com

drm/i915/display: Disable SAGV on bw init, to force QGV point recalculation

Problem is that on some platforms, we do get QGV point mask in wrong
state on boot. However driver assumes it is set to 0
(i.e all points allowed), however in reality we might get them all
restricted, causing issues.
Lets disable SAGV initially to force proper QGV point state.
If more QGV points are available, driver will recalculate and update
those then after next commit.

v2: - Added trace to see which QGV/PSF GV point is used when SAGV is
      disabled.
v3: - Move force disable function to intel_bw_init in order to initialize
      bw state as well, so that hw/sw are immediately in sync after init.
v4: - Don't try sending PCode request, seems like it is not possible at
      intel_bw_init, however assigning bw->state to be restricted as if
      SAGV is off, still forces driveer to send PCode request anyway on
      next modeset, so the solution still works.
      However we still need to address the case, when no display is
      connected, which anyway requires much more changes.

v5: - Put PCode request back and apply temporary hack to make the
      request succeed(in case if there 2 PSF GV points with same BW, PCode
      accepts only if both points are restricted/unrestricted same time)
    - Fix argument sequence for adl_qgv_bw(Ville Syrjälä)

v6: - Fix wrong platform checks, not to break everything else.

v7: - Split the handling of quplicate QGV/PSF GV points (Vinod)
      Restrict force disable to display version below 14 (Vinod)

v8: - Simplify icl_force_disable_sagv (Vinod)

Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Signed-off-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240405113533.338553-5-vinod.govindapillai@intel.com

drm/i915/display: extract code to prepare qgv points mask

Extract the code to prepare the QGV points mask as per the
format expected by the pcode as this could be utlized from
multiple points.

Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Signed-off-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240405113533.338553-4-vinod.govindapillai@intel.com

drm/i915/display: Extract code required to calculate max qgv/psf gv point

We need that in order to force disable SAGV in next patch.
Also it is beneficial to separate that code, as in majority cases,
when SAGV is enabled, we don't even need those calculations.
Also we probably need to determine max PSF GV point as well, however
currently we don't do that when we disable SAGV, which might be
actually causing some issues in that case.

v2: - Introduce helper adl_qgv_bw(counterpart to adl_psf_bw)
      (Ville Syrjälä)
    - Don't restrict psf gv points for SAGV disable case
      (Ville Syrjälä)
v3: - Update icl_max_bw_qgv_point_mask to return max qgv point
      mask (Vinod)
v4: - Minor changes in icl_find_qgv_points (Vinod)
v5: - use max_bw_point instead of max_bw_point_mask (stan)

Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Signed-off-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240405113533.338553-3-vinod.govindapillai@intel.com

drm/i915/display: Add meaningful traces for QGV point info error handling

For debug purposes we need those - error path won't flood the log,
however there has been already numerous cases, when due to lack
of debugs, we couldn't immediately tell what was the problem on
customer machine, which slowed down the investigation, requiring
to get access to target device and adding those traces manually.

v2: - Make the debug more generic and move it to intel_dram_detect
      (Gustavo Sousa)
v3: - Use %u for unsigned variable in debug prints (Gustavo)

Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com>
Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Signed-off-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240405113533.338553-2-vinod.govindapillai@intel.com

drm/i915/dmc: use struct intel_display more

Now that the intel_de_ functions and DISPLAY_VER() accept struct
intel_display *, use it more.

Cc: Luca Coelho <luciano.coelho@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/06bc9fd9d0472e899bd9d50f3b10a6066c1a0238.1713358679.git.jani.nikula@intel.com

drm/i915/de: allow intel_display and drm_i915_private for de functions

It would be too much noise to convert the intel_de_* functions from
using struct drm_i915_private to struct intel_display all at once. Add
generic wrappers using __to_intel_display() to accept both.

v2: Take the intel_dmc_wl_* changes into account

Cc: Luca Coelho <luciano.coelho@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1b0e8e7c732535e18c8498a2e18fe1e4c123e2f5.1713358679.git.jani.nikula@intel.com

drm/i915/dmc: convert dmc wakelock interface to struct intel_display

Convert the dmc wakelock interface to struct intel_display instead of
struct drm_i915_private. We'll want to convert the intel_de interfaces,
and there's a bit of coupling between the two, so start here.

Cc: Luca Coelho <luciano.coelho@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/3c260bbbce0af8714b07157dc032b038efa3bf1c.1713358679.git.jani.nikula@intel.com

drm/i915/display: rename __intel_wait_for_register_nowl() to indicate intel_de_

Rename __intel_wait_for_register_nowl() to
__intel_de_wait_for_register_nowl() to be in line with the rest of
intel_de.h.

Cc: Luca Coelho <luciano.coelho@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/967d3fc67a9053f7d5f9c03010fd5f94dc8d547d.1713358679.git.jani.nikula@intel.com

drm/i915/quirks: convert struct drm_i915_private to struct intel_display

Use struct intel_display instead of struct drm_i915_private for
quirks. Also do drive-by conversions in call sites of intel_has_quirk().

Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/d90e9d8e91e59d04d38f2743c02c74a8f0e13133.1713358679.git.jani.nikula@intel.com

drm/i915/display: accept either i915 or display for feature tests

Use the generic __to_intel_display() to allow passing either struct
drm_i915_private * or struct intel_display * to the feature test macros.

Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/bed78da39e6bd1587db4dab820602c55c63cdd6a.1713358679.git.jani.nikula@intel.com

drm/i915: add generic __to_intel_display()

Add generic __to_intel_display() macro that accepts either struct
drm_i915_private * or struct intel_display *. This is to be used for
transitional stuff that eventually needs to be converted to use struct
intel_display *, and therefore is not part of to_intel_display().

Add new intel_display_conversion.h to host the helper to avoid
duplication between xe and i915 drivers.

v2: put it in the new header (Rodrigo)

Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/a999ff8183659a4df68d439ebd31c19b5c56852a.1713358679.git.jani.nikula@intel.com

drm/i915/display: add generic to_intel_display() macro

Convert various pointers to struct intel_display * using _Generic().

Add some macro magic to make adding new conversions easier, and somewhat
abstract the need to cast each generic association. The cast is required
because all associations needs to compile, regardless of the type and
the generic selection.

The use of *p in the generic selection assignment expression removes the
need to add separate associations for const pointers.

Note: This intentionally does *not* cover struct drm_i915_private or
struct xe_device. They are not to be used in the long run, so avoid
using this macro for them.

Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/02cf407961200db4379370856c779ea62b3eaa90.1713358679.git.jani.nikula@intel.com

drm/i915/display: add intel_display -> drm_device backpointer

As a baby step towards making struct intel_display the main data
structure for display, add a backpointer to struct drm_device that can
be used instead of &i915->drm.

Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/47dd7bc4aae3c10b18097824e37617c072c66c0b.1713358679.git.jani.nikula@intel.com

drm/i915: use system include for drm headers

Use <> instead of "" for including headers from include/, even if the
file is in the same directory.

Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com>
Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Acked-by: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/ed02b81fcbbc0d27be4af460c521aefbfdc76375.1712743191.git.jani.nikula@intel.com

drm/i915: limit eDP MSO pipe only for display version 20 and below

The pipes that can be used for eDP MSO are limited to pipe A (and
sometimes also pipe B) only for display version 20 and below.

Modify the function that returns the pipe mask for eDP MSO so that
these limitations only apply to version 20 and below, enabling all
pipes otherwise.

Bspec: 68923
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: James Ausmus <james.ausmus@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240404091646.165309-1-luciano.coelho@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: Suck snps/cx0 PLL states into dpll_hw_state

For some reason the snps/cx0 PLL states were added into
a union alongside dpll_hw_state. Just suck them into
dpll_hw_state so that we don't have so many levels of
unions/etc.

TODO: Get rid of 'clock' from the snps/cx0 PLL states
      as it is not a register values and thus doesn't
      belong there

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240412182703.19916-19-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: Unionize dpll_hw_state

intel_dpll_hw_state contains space for all possible PLL
register values across all platforms. That is rather wasteful
as each machine only needs to store the registers values
that are appropriate for the platform.

Turn intel_dpll_hw_state into a union so that we don't
waste memory for the register values of other platforms.

And let's use an anonymous union so that we don't have
to do tons of s/struct/union/ all over the place.

pahole:
 struct intel_dpll_hw_state {
-       struct i9xx_dpll_hw_state  i9xx;                 /*     0    16 */
-       struct hsw_dpll_hw_state   hsw;                  /*    16     8 */
-       struct skl_dpll_hw_state   skl;                  /*    24    12 */
-       struct bxt_dpll_hw_state   bxt;                  /*    36    44 */
-       /* --- cacheline 1 boundary (64 bytes) was 16 bytes ago --- */
-       struct icl_dpll_hw_state   icl;                  /*    80    60 */
+       union {
+               struct i9xx_dpll_hw_state i9xx;          /*     0    16 */
+               struct hsw_dpll_hw_state hsw;            /*     0     8 */
+               struct skl_dpll_hw_state skl;            /*     0    12 */
+               struct bxt_dpll_hw_state bxt;            /*     0    44 */
+               struct icl_dpll_hw_state icl;            /*     0    60 */
+       };                                               /*     0    60 */

-       /* size: 140, cachelines: 3, members: 5 */
-       /* last cacheline: 12 bytes */
+       /* size: 60, cachelines: 1, members: 1 */
+       /* last cacheline: 60 bytes */

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240412182703.19916-18-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: Carve up struct intel_dpll_hw_state

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 specific
sub-structures. For now this will actually increase the size
a little bit as we have to duplicate a few members from
skl to icl, but that will be remedied soon when we turn
the thing into a union.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240412182703.19916-17-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: Add local DPLL 'hw_state' variables

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ä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240412182703.19916-16-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: s/pipe_config/crtc_state/ in legacy PLL code

Rename all the ye olde 'pipe_config's to the modern
'crtc_state' name in the legacy DPLL code.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240412182703.19916-15-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: Drop pointless 'crtc' argument from *_crtc_clock_get()

We are alreayd passing the crtc_state to *_crtc_clock_get().
Passing the crtc as well is 100% redundant, so don't do it.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240412182703.19916-14-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: Modernize i9xx_pll_refclk()

Drop the redundant 'dev' argument from i9xx_pll_refclk()
and rename its variables to conform to modern standards.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240412182703.19916-13-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: Inline {i9xx,ilk}_update_pll_dividers()

Now that *_compute_dpll() are no longer a mess
{i9xx,ilk}_update_pll_dividers() don't serve any real
purpose anymore. Just inline them into the callers.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240412182703.19916-12-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: Extract {i9xx,i8xx,ilk,vlv,chv}_dpll()

The *_compute_dpll() functions generally contain
two things:
- huge pile of inline code to calculate the DPLL
  register value
- a few calls to helpers to calculate the
  DPLL_MD and FP register values

Pull the DPLL register value calculations into a helpers
as well, so that *_compute_dpll() can focus on higher
level tasks.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240412182703.19916-11-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: Extract i965_dpll_md()

We have three copies of the DPLL_MD value computation.
Share it.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240412182703.19916-10-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: Pass the PLL hw_state to pll->enable()

Stop rummaging around inside pll->state directly in the low
level pll->enable() functions, and instead let the higher level
code figure out where the correct state is stored and pass it in.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240412182703.19916-9-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: Extract i9xx_dpll_get_hw_state()

Start making the GMCH DPLL code a bit more like the more modern
platforms by separating out the DPLL hw state readout from the
rest of the pipe readout.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240412182703.19916-8-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: Extract ilk_dpll_compute_fp()

Let's not repeat ourselves so much and pull the entire
PCH DPLL FP register value calculation into its own
function.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240412182703.19916-7-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: Extract ilk_fb_cb_factor()

Pull the code to calculate PCH DPLL tuning factor
into its own function. Helps declutter ilk_update_pll_dividers().

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240412182703.19916-6-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: Introduce some local PLL state variables

Spinkle local PLL hw_state variables into various low
level PLL functions. Will make subsequent changes cleaner
when we don't have to touch so many places when renaming
struct members and whatnot.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240412182703.19916-5-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: Rename PLL hw_state variables/arguments

We have zero consistency in out PLL state naming scheme. Try
to unify things a bit by using 'dpll_hw_state' for high level
stuff and just 'hw_state' for low level stuff. Currently both
are the same, but I want to unionize intel_dpll_hw_state at
which point using different names can make it more clear whether
we're talking about the whole union or just the embedded platform
specific struct.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240412182703.19916-4-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: Use printer for the rest of PLL debugfs dump

Since we now have the printer around for intel_dpll_dump_hw_state()
use it for all the other PLL prints as well. Just to make the thing
looks less crazy.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240412182703.19916-3-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: Replace hand rolled PLL state dump with intel_dpll_dump_hw_state()

Just use intel_dpll_dump_hw_state() instead of hand rolling it.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240412182703.19916-2-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/display: tie DMC wakelock to DC5/6 state transitions

We only need DMC wakelocks when we allow DC5 and DC6 states.  Add the
calls to enable and disable DMC wakelock accordingly.

Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240412094148.808179-5-luciano.coelho@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/display: add module parameter to enable DMC wakelock

This feature should be disabled by default until properly tested and
mature.  Add a module parameter to enable the feature for testing,
while keeping it disabled by default for now.

Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240412094148.808179-4-luciano.coelho@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/display: don't allow DMC wakelock on older hardware

Only allow running DMC wakelock code if the display version is 20 or
greater.  Also check if DMC is loaded before enabling.

Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240412094148.808179-3-luciano.coelho@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/display: add support for DMC wakelocks

In order to reduce the DC5->DC2 restore time, wakelocks have been
introduced in DMC so the driver can tell it when registers and other
memory areas are going to be accessed and keep their respective blocks
awake.

Implement this in the driver by adding the concept of DMC wakelocks.
When the driver needs to access memory which lies inside pre-defined
ranges, it will tell DMC to set the wakelock, access the memory, then
wait for a while and clear the wakelock.

The wakelock state is protected in the driver with spinlocks to
prevent concurrency issues.

BSpec: 71583
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240412094148.808179-2-luciano.coelho@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: Allow bigjoiner for MST

We need bigjoiner support with MST functionality
for MST monitor resolutions > 5K to work.
Adding support for the same.

v2: Addressed review comments from Jani.
Revert rejection of MST bigjoiner modes and add
functionality

v3: Fixed pipe_mismatch WARN for mst_master_transcoder
Credits-to: Manasi Navare <navaremanasi@chromium.org>

v4: Utilize intel_crtc_joined_pipe_mask() also for handling
    bigjoiner slave pipes for MST case(Stan)
[v5: vsyrjala: chunked the modeset squence stuff out,
               removed bogus mst master transcoder hack,
       keep mgr_lock near the full_pbn check]
[v6: vsyrjala: Calculate DSC slices correctly for bigjoiner (Imre)]

Reviewed-by: Manasi Navare <navaremanasi@chromium.org>
Reviewed-by: Arun R Murthy <arun.r.murthy@intel.com>
Signed-off-by: Vidya Srinivas <vidya.srinivas@intel.com>
Co-developed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240409163502.29633-7-ville.syrjala@linux.intel.com

drm/i915/mst: Add bigjoiner handling to MST modeset sequence

Loop over all joined pipes at relevant points in the MST
modeset sequence.

Carved out from Vidya's earlier big patch, with naming/etc.
changed to match the earlier hsw_crtc_enable() stuff.

Reviewed-by: Arun R Murthy <arun.r.murthy@intel.com>
Co-developed-by: Vidya Srinivas <vidya.srinivas@intel.com>
Signed-off-by: Vidya Srinivas <vidya.srinivas@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240409163502.29633-6-ville.syrjala@linux.intel.com

drm/i915: Handle joined pipes inside hsw_crtc_enable()

Handle only bigjoiner masters in skl_commit_modeset_enables/disables,
slave crtcs should be handled by master hooks. Same for encoders.
That way we can also remove a bunch of checks like intel_crtc_is_bigjoiner_slave.

v2: - Moved skl_pfit_enable, intel_dsc_enable, intel_crtc_vblank_on to intel_enable_ddi,
      so that it is now finally symmetrical with the disable case, because currently
      for some weird reason we are calling those from skl_commit_modeset_enables, while
      for the disable case those are called from the ddi disable hooks.
v3: - Create intel_ddi_enable_hdmi_or_sst symmetrical to
      intel_ddi_post_disable_hdmi_or_sst and move it also under non-mst check.
v4: - Fix intel_enable_ddi sequence
    - Call intel_crtc_update_active_timings for slave pipes as well
[v5: vsyrjala: Use the name 'pipe_crtc' for the per-pipe crtc pointer
               Use consistent style and naming
       Protect macro arguments properly
               Drop superfluous changes to the modeset sequence,
       this now follows the old non-joiner sequence 100%
       apart from just looping in places]

Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Tested-by: Vidya Srinivas <vidya.srinivas@intel.com>
Reviewed-by: Manasi Navare <navaremanasi@chromium.org> #v4?
Co-developed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240409163502.29633-5-ville.syrjala@linux.intel.com

drm/i915: Handle joined pipes inside hsw_crtc_disable()

Reorganize the crtc disable path to only deal with the
master pipes/transcoders in intel_old_crtc_state_disables()
and offload the handling of joined pipes to hsw_crtc_disable().
This makes the whole thing much more sensible since we can
actually control the order in which we do the per-pipe vs.
per-transcoder modeset steps.

v2: Use the name 'pipe_crtc' for the per-pipe crtc pointer

Tested-by: Vidya Srinivas <vidya.srinivas@intel.com>
Reviewed-by: Arun R Murthy <arun.r.murthy@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240409163502.29633-4-ville.syrjala@linux.intel.com

drm/i915: Utilize intel_crtc_joined_pipe_mask() more

Unify the master vs. slave handling in
intel_ddi_post_disable_hdmi_or_sst() by looping over all the
pipes in one go.

This also lets us move the intel_crtc_vblank_off() calls to
happen in a consistent place vs. the transcoder disable.
Previously we did the master vs. slaves on different sides
of that.

v2: Use the name 'pipe_crtc' for the per-pipe crtc pointer

Tested-by: Vidya Srinivas <vidya.srinivas@intel.com>
Reviewed-by: Arun R Murthy <arun.r.murthy@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240409163502.29633-3-ville.syrjala@linux.intel.com

drm/i915: Extract intel_ddi_post_disable_hdmi_or_sst()

Extract the "not-MST" stuff from intel_ddi_post_disable() so that
the whole thing isn't so cluttered.

The bigjoiner slave handling was outside of the !MST check,
but it really should have been inside it as its the counterpart
to the master handling inside the check. So we pull that
in as well. There is no functional change here as we don't
currently support bigjoiner+MST anyway.

v2: Rebase
v3: Actually extract the slave code as claimed in
    the commit message (presumably a rebase fail in v2)

Tested-by: Vidya Srinivas <vidya.srinivas@intel.com>
Reviewed-by: Arun R Murthy <arun.r.murthy@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240409163502.29633-2-ville.syrjala@linux.intel.com

drm/i915/psr: Use crtc_state->port_clock instead of intel_dp->link_rate

Intel_dp->link_rate is not yet set at this point. Instead use
crtc_state->port_clock.

Fixes: 0dd21f836983 ("drm/i915/psr: Silence period and lfps half cycle")
Signed-off-by: Jouni Högander <jouni.hogander@intel.com>
Reviewed-by: Animesh Manna <animesh.manna@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240409085759.178235-1-jouni.hogander@intel.com