drm/i915/psr: switch PSR debugfs to struct intel_connector

Prefer struct intel_connector over struct drm_connector.

Cc: Jouni Högander <jouni.hogander@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230317134144.223936-2-jani.nikula@intel.com

drm/i915/psr: move PSR debugfs to intel_psr.c

Move the debugfs next to the implementation.

Cc: Jouni Högander <jouni.hogander@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230317134144.223936-1-jani.nikula@intel.com

drm/i915: Extract intel_crtc_scanline_offset()

Pull the scanline_offset calculation into its own function. Might
have further use for this later with DSB scanline waits.

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

drm/i915: Relocate intel_crtc_update_active_timings()

Move intel_crtc_update_active_timings() into intel_vblank.c
where it more properly belongs.

Also do the s/dev_priv/i915/ modernization rename while at it.

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

drm/i915: Add belts and suspenders locking for seamless M/N changes

Add some (probably overkill) locking to protect the vblank
timestamping constants updates during seamless M/N fastsets.

As everything should be naturally aligned I think the individual
pieces should probably end up updating atomically enough. So this
is only really meant to guarantee everyone sees a consistent whole.

All the drm_vblank.c usage is covered by vblank_time_lock,
and uncore.lock will take care of __intel_get_crtc_scanline()
that can also be called from outside the core vblank functionality.

Currently only crtc_clock and framedur_ns can change, but in
the future might fastset also across eg. vtotal/vblank_end
changes, so let's just grab the locks across the whole thing.

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/20230310235828.17439-2-ville.syrjala@linux.intel.com

drm/i915: Update vblank timestamping stuff on seamless M/N change

When we change the M/N values seamlessly during a fastset we should
also update the vblank timestamping stuff to make sure the vblank
timestamp corrections/guesstimations come out exact.

Note that only crtc_clock and framedur_ns can actually end up
changing here during fastsets. Everything else we touch can
only change during full modesets.

Technically we should try to do this exactly at the start of
vblank, but that would require some kind of double buffering
scheme. Let's skip that for now and just update things right
after the commit has been submitted to the hardware. This
means the information will be properly up to date when the
vblank irq handler goes to work. Only if someone ends up
querying some vblanky stuff in between the commit and start
of vblank may we see a slight discrepancy.

Also this same problem really exists for the DRRS downclocking
stuff. But as that is supposed to be more or less transparent
to the user, and it only drops to low gear after a long delay
(1 sec currently) we probably don't have to worry about it.
Any time something is actively submitting updates DRRS will
remain in high gear and so the timestamping constants will
match the hardware state.

Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Mitul Golani <mitulkumar.ajitkumar.golani@intel.com>
Fixes: e6f29923c048 ("drm/i915: Allow M/N change during fastset on bdw+")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230310235828.17439-1-ville.syrjala@linux.intel.com

drm/i915: Extract intel_sprite_uapi.c

Move the sprite colorkey ioctl handler to its own file
so that intel_sprite.c becomes all about the low level
details of pre-skl sprite planes.

And drop a bunch of unnecessary includes while at it.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230314130255.23273-10-ville.syrjala@linux.intel.com
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>

drm/i915: Relocate intel_plane_check_src_coordinates()

Move intel_plane_check_src_coordinates() from the pre-skl sprite
plane specific code to a more suitable place for common plane code.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230314130255.23273-9-ville.syrjala@linux.intel.com
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>

drm/i915: Clean up skl+ plane alpha bits

Convert a few more skl+ plane registers to REG_BIT() & co.
Somehow thse were missed during the earlier cleanup.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230314130255.23273-8-ville.syrjala@linux.intel.com
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>

drm/i915: Define vlv/chv sprite plane SURFLIVE registers

Might as well complete the SURFLIVE register definitions
for all platforms/plane types. We are only missing the
VLV/CHV sprite planes.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230314130255.23273-7-ville.syrjala@linux.intel.com
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>

drm/i915: Define skl+ universal plane SURFLIVE registers

Add the definitions for the skl+ univerals plane SURFLIVE
registers. Despite not being used for anything real
these came in suprisingly handy during some DSB debugging
recently, so having the defines around can be useful.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230314130255.23273-6-ville.syrjala@linux.intel.com
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>

drm/i915: Program VLV/CHV PIPE_MSA_MISC register

VLV/CHV have an extra register to configure some stereo3d
signalling details via DP MSA. Make sure we reset that
register to zero (since we don't do any stereo3d stuff).

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230314130255.23273-5-ville.syrjala@linux.intel.com
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>

drm/i915: Define more pipe timestamp registers

Add definitions for various pipe timestamp registers:
- frame timestamp (last start of vblank) (g4x+), already had this defined
- flip timestamp (when SURF was last written) (g4x+)
- flipdone timestamp (when last flipdone was signalled) (tgl+)

Note that on pre-tgl the flip related timestamps are only updated
for primary plane flips, but on tgl+ we can select which plane
updates them (via PIPE_MISC2). Let's define those related bits
as well.

Curiously VLV/CHV do not have the frame/flip timestamp registers,
despite all the other related registers being inherited from g4x.
This means we can get rid of the pipe_offsets[] usage for these,
and thus the implicit dev_priv is gone as well.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230314130255.23273-4-ville.syrjala@linux.intel.com
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>

drm/i915: s/PIPEMISC/PIPE_MISC/

This PIPEMISC vs. PIPE_MISC inconsitency is ugly. Unify
the naming (PIPE_MISC is also what bspec has always called it).

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230314130255.23273-3-ville.syrjala@linux.intel.com
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>

drm/i915: Stop using pipe_offsets[] for PIPE_MISC*

The PIPE_MISC registers don't exist on pre-bdw hardware,
so there is no point in using pipe_offsets[] for them.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230314130255.23273-2-ville.syrjala@linux.intel.com
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>

drm/i915/display: ignore link training failures in CI

If the ignore long HPD flag is set, ignore the link training
failures as well. Because of spurious HPDs, some unexpected link
training failures are happening while executing IGT test cases.
Ignore the link training failures for the time being if the long
HPDs are also ignored in the environments like CI.

Signed-off-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230215083832.287519-3-vinod.govindapillai@intel.com

drm/i915/display: ignore long HPDs based on a flag

Some panels generate long HPD events even while connected to
the port. This cause some unexpected CI execution issues. A
new flag is added to track if such spurious long HPDs can be
ignored and are not processed further if the flag is set.
Debugfs entry is added to control the ignore long hpd flag.

v2: Address patch styling comments (Jani Nikula)

v3: Ignoring the HPD moved to hotplug handler and now applies
    to all types of outputs (Imre Deak)

v4: use debugfs_create_bool and squash patches (Jani Nikula)

Signed-off-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230215083832.287519-2-vinod.govindapillai@intel.com

drm/i915/opregion: Fix CONFIG_ACPI=n builds adding missing intel_opregion_cleanup() prototype

Add the missing intel_opregion_cleanup() prototype fixing CONFIG_ACPI=n
builds.

Fixes: 3e226e4a2180 ("drm/i915/opregion: Cleanup opregion after errors during driver loading")
Cc: Jani Nikula <jani.nikula@intel.com>
Reported-by: kernel test robot <lkp@intel.com>
Reviewed-by: Nirmoy Das <nirmoy.das@intel.com>
Link: https://lore.kernel.org/oe-kbuild-all/202303141610.6L1VO7Gw-lkp@intel.com/
Signed-off-by: Imre Deak <imre.deak@intel.com>

drm/i915: Don't send idle pattern after DP2.0 link training

Bspec calls us to select pattern 2 after link training for
DP 2.0. Let's do that... by doing nothing because we will
be transmitting pattern 2 at the end of the link training
already.

Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230308212627.7601-2-ville.syrjala@linux.intel.com

drm/i915: Don't switch to TPS1 when disabling DP_TP_CTL

AFAICS Bspec has never asked us to switch to TPS1 when *disabling*
DP_TP_CTL. Let's stop doing that in case it confuses something.
We do have to switch before we *enable* DP_TP_CTL, but that
is already being handled correctly.

v2: Do the same for FDI
v3: Rebase

Reviewed-by: Imre Deak <imre.deak@intel.com> #v1
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230308212627.7601-1-ville.syrjala@linux.intel.com

drm/i915/dp: Don't roundup max bpp, while computing compressed bpp

While computing compressed bpp, maximum value of bits_per_pixel is
calculated that can be supported with the given link configuration
for a given mode. Avoid rounding up of this max bits_per_pixel.
Also improve documentation for computing max bits_per_pixel.

Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230223115509.3980226-1-ankit.k.nautiyal@intel.com

drm/i915/debugfs: move IPS debugfs to hsw_ips.c

Follow the style of placing debugfs next to the implementation.

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

drm/i915: Reject wm levels that exceed vblank time

The pipe needs a certain amount of time during vblank to prefill
sufficiently. If the vblank is too short the relevant watermark
level must be disabled.

Start implementing the necessary calculations to check this.
Scaler and DSC prefill are left out for now as handling those
is not entirely trivial.

Also the PSR latency reporting override chicken bits would
need to be correctly configured based on the results of these
calculations. Just add some FIXMEs for now.

TODO: bspec isn't exactly crystal clear in its explanations
      so quite a few open questions remain...

v2: Skip inacive pipes
    Handle SAGV latency
v3: Rebase
v4: Fix handling of disabled wm levels (latency == 0)

Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230306164854.25928-1-ville.syrjala@linux.intel.com

drm/i915: Extract skl_wm_latency()

Extract the skl+ wm latency determination into a small helper
so that everyone has the same idea what the latency should be.

This introduces a slight functional change in that
skl_cursor_allocation() will now start to account for the
extra 4 usec that the kbk/cfl/cml IPC w/a adds.

v2: Rebase

Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230301162449.26672-2-ville.syrjala@linux.intel.com

drm/i915/opregion: Register display debugfs later, after initialization steps

Move the display debugfs registration later, after initializing steps
for opregion/acpi/audio. These latter ones don't depend on the debugfs
entries, OTOH some debugfs entries may depend on the initialized state.

Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230308162503.3219200-3-imre.deak@intel.com

drm/i915/opregion: Cleanup opregion after errors during driver loading

Clean up the opregion state if something fails after
intel_opregion_setup() is called.

Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230308162503.3219200-2-imre.deak@intel.com

drm/i915/opregion: Fix opregion setup during system resume on platforms without display

Atm, during system resume, the driver updates the display connector
information required by the opregion video extensions during system
resume, on platforms both with and without display being present. On
!HAS_DISPLAY platforms this will result in the crash with the stack
trace below, since the driver's connector state is not initialized on
those.

Bspec doesn't specify when each of the opregion functionality is
supported (depending on the presence of display), however we can presume
that none of the video extensions, nor the ACPI _DSM functions are
supported on !HAS_DISPLAY platforms; accordingly skip the corresponding
opregion/ACPI setup on those (also matching the Windows driver in this).

Keep sending the opregion notification about suspending/resuming the
whole adapter (vs. the display only which is a separate power state
notification) on all platforms, similarly to runtime suspend/resume.

This fixes the following:
Oops: 0000 [#1] PREEMPT SMP NOPTI
CPU: 4 PID: 1443 Comm: kworker/u40:55 Tainted: G U 6.2.0-rc8+ #58
Hardware name: LENOVO 82VB/LNVNB161216, BIOS KMCN09WW 04/26/2022
Workqueue: events_unbound async_run_entry_fn
RIP: 0010:drm_connector_list_iter_next+0x4f/0xb0

Call Trace:
 <TASK>
 intel_acpi_device_id_update+0x80/0x160 [i915]
 intel_opregion_resume+0x2f/0x1e0 [i915]
 ? dg2_init_clock_gating+0x49/0xf0 [i915]
 i915_drm_resume+0x137/0x190 [i915]
 ? __pfx_pci_pm_resume+0x10/0x10
 dpm_run_callback+0x47/0x150

Cc: iczero <iczero@hellomouse.net>
Reported-and-tested-by: iczero <iczero@hellomouse.net>
References: https://gitlab.freedesktop.org/drm/intel/-/issues/8015
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230308162503.3219200-1-imre.deak@intel.com

drm/i915: Preserve crtc_state->inherited during state clearing

intel_crtc_prepare_cleared_state() is unintentionally losing
the "inherited" flag. This will happen if intel_initial_commit()
is forced to go through the full modeset calculations for
whatever reason.

Afterwards the first real commit from userspace will not get
forced to the full modeset path, and thus eg. audio state may
not get recomputed properly. So if the monitor was already
enabled during boot audio will not work until userspace itself
does an explicit full modeset.

Cc: stable@vger.kernel.org
Tested-by: Lee Shawn C <shawn.c.lee@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230223152048.20878-1-ville.syrjala@linux.intel.com
Reviewed-by: Uma Shankar <uma.shankar@intel.com>

drm/i915: Ensure DSC has enough BW and stays within HW limits

We currently have an issue with some BPPs when using DSC.
According to the HW team, the reason is that a single VDSC engine
instance has some BW limitations that must be accounted for.
So, whenever we approach around 90% of the CDCLK, a second VDSC engine
has to be used.
This always means using two slices. However, in our current code,
the amount of slices is calculated independently of whether
we need to enable the second VDSC engine or not.
This leads to some logical issues when, according to the pixel clock needs,
we need to enable the second VDSC engine.
But as we calculated previously that we can only use a single slice,
we can't do that and fail.
So, we need to fix that so that the number of VDSC engines enabled
should depend on the number of slices, and the number of slices
should also depend on BW requirements.
Lastly, we didn't have BPP limitation for ADLP/MTL/DG2 implemented,
which says that DSC output BPPs can only be chosen within the range of 8 to 27
(BSpec 49259).
All of this applied together allows us to fix existing FIFO underruns,
which we have in many DSC tests.

v2: - Replace min with clamp_t(Jani Nikula)
    - Fix commit message(Swati Sharma)
    - Added "Closes"(Swati Sharma)

BSpec: 49259
HSDES: 18027167222

Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/8231
Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230306080401.22552-1-stanislav.lisovskiy@intel.com

drm/i915/dmc: Load DMC on MTL

Add support to load DMC on MTL.

According to the spec and based on tests done on real hardware, 0x7000
is a reasonable size limit that covers each possible payload.

v2:
  - Tighten payload size limit. (Matt, Rodrigo)
  - Use a better name for the defined payload limit. (Rodrigo)

Signed-off-by: Madhumitha Tolakanahalli Pradeep <madhumitha.tolakanahalli.pradeep@intel.com>
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: Anusha Srivatsa <anusha.srivatsa@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230307195111.90767-1-gustavo.sousa@intel.com

drm/i915/display/mtl: Program latch to phy reset

Latch reset of phys during DC9 and when driver is unloaded to avoid
phy reset.

Specification ask us to program it closer to the step that enables
DC9 in DC_STATE_EN but doing this way allow us to sanitize the phy
latch during driver load.

BSpec: 49197
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230301201053.928709-6-radhakrishna.sripada@intel.com

drm/i915/fbdev: lock the fbdev obj before vma pin

lock the fbdev obj before calling into
i915_vma_pin_iomap(). This helps to solve below :

<7>[   93.563308] i915 0000:00:02.0: [drm:intelfb_create [i915]] no BIOS fb, allocating a new one
<4>[   93.581844] ------------[ cut here ]------------
<4>[   93.581855] WARNING: CPU: 12 PID: 625 at drivers/gpu/drm/i915/gem/i915_gem_pages.c:424 i915_gem_object_pin_map+0x152/0x1c0 [i915]

Fixes: f0b6b01b3efe ("drm/i915: Add ww context to intel_dpt_pin, v2.")
Cc: Chris Wilson <chris.p.wilson@intel.com>
Cc: Matthew Auld <matthew.auld@intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Tejas Upadhyay <tejas.upadhyay@intel.com>
Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230301201053.928709-5-radhakrishna.sripada@intel.com

drm/i915/mtl: Fix Wa_16015201720 implementation

The commit 2357f2b271ad ("drm/i915/mtl: Initial display workarounds")
extended the workaround Wa_16015201720 to MTL. However the registers
that the original WA implemented moved for MTL.

Implement the workaround with the correct register.

v3: Skip clock gating for pipe C, D DMC's and fix the title

Fixes: 2357f2b271ad ("drm/i915/mtl: Initial display workarounds")
Cc: Matt Atwood <matthew.s.atwood@intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230301201053.928709-2-radhakrishna.sripada@intel.com

drm/i915: Get rid of the gm45 HPD live state nonsense

The idea that ctg uses different HPD live state bits is
total nonsense, at least on my machine (Dell Latitude
E5400).

The only reason DP-B even works on my ctg is that DP-D
live state is stuck high, even though there is no physical
DP-D port. So when the detect checks DP-B live state it
sees the stuck live state of DP-D instead. If I hack
the driver to not register DP-D at all, and thus we never
enabe DP-D HPD, DP-B stops working as well.

Just to put some conclusive evidence into this mess,
here are the actual hotplug register values for each port:
 Everything disconnected:
                    PORT_HOTPLUG_EN (0x00061110): 0x00000000
                  PORT_HOTPLUG_STAT (0x00061114): 0x00000000
                    PORT_HOTPLUG_EN (0x00061110): 0x08000000
                  PORT_HOTPLUG_STAT (0x00061114): 0x08000000
                    PORT_HOTPLUG_EN (0x00061110): 0x10000000
                  PORT_HOTPLUG_STAT (0x00061114): 0x00000000
                    PORT_HOTPLUG_EN (0x00061110): 0x20000000
                  PORT_HOTPLUG_STAT (0x00061114): 0x00000000
 Only port B connected:
                    PORT_HOTPLUG_EN (0x00061110): 0x00000000
                  PORT_HOTPLUG_STAT (0x00061114): 0x00000000
                    PORT_HOTPLUG_EN (0x00061110): 0x08000000
                  PORT_HOTPLUG_STAT (0x00061114): 0x08000000
                    PORT_HOTPLUG_EN (0x00061110): 0x10000000
                  PORT_HOTPLUG_STAT (0x00061114): 0x00000000
                    PORT_HOTPLUG_EN (0x00061110): 0x20000000
                  PORT_HOTPLUG_STAT (0x00061114): 0x20000000
 Only port C connected:
                    PORT_HOTPLUG_EN (0x00061110): 0x00000000
                  PORT_HOTPLUG_STAT (0x00061114): 0x00000000
                    PORT_HOTPLUG_EN (0x00061110): 0x08000000
                  PORT_HOTPLUG_STAT (0x00061114): 0x08000000
                    PORT_HOTPLUG_EN (0x00061110): 0x10000000
                  PORT_HOTPLUG_STAT (0x00061114): 0x10000000
                    PORT_HOTPLUG_EN (0x00061110): 0x20000000
                  PORT_HOTPLUG_STAT (0x00061114): 0x00000000

So the enable bit and live state bit always match 1:1.

Acked-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/20230302161013.29213-4-ville.syrjala@linux.intel.com

drm/i915: Fix SKL DDI A digital port .connected()

SKL doesn't have any north DE hotplug stuff. Currently we're
trying to read DDI A live state from the BDW north DE bit,
instead of the approproate south DE bit. Fix it.

And for good measure clear the pointer to the north hpd
pin array, so that we'll actually notice if some other
place is also using the wrong thing.

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/20230302161013.29213-3-ville.syrjala@linux.intel.com

drm/i915: Populate dig_port->connected() before connector init

We'll need dig_port->connected() to be there for a HPD live
state check during eDP connector probing. Reorder intel_ddi_init()
accordingly. g4x_dp_init() is already fine.

v2: Fix comment style while at it

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/20230302161013.29213-2-ville.syrjala@linux.intel.com

drm/i915: Bump VBT version for expected child dev size check

The most modern VBT I've observed in the wild is version 250.
The child dev size hasn't changed since version 216, so bump
the version number in the expected child dev size check.

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

drm/i915/rps: split out display rps parts to a separate file

Split out the RPS parts so they can be conditionally compiled out later.

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

drm/i915/dmc: mass rename dev_priv to i915

Follow the contemporary convention for struct drm_i915_private * naming.

Cc: Imre Deak <imre.deak@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230301122944.1298929-5-jani.nikula@intel.com

drm/i915/dmc: allocate dmc structure dynamically

sizeof(struct intel_dmc) > 1024 bytes, allocated on all platforms as
part of struct drm_i915_private, whether they have DMC or not.

Allocate struct intel_dmc dynamically, and hide all the dmc details
behind an opaque pointer in intel_dmc.c.

Care must be taken to take into account all cases: DMC not supported on
the platform, DMC supported but not initialized, and DMC initialized but
not loaded. For the second case, we need to move the wakeref out of
struct intel_dmc.

v2:
- Rebase to kzalloc dmc after runtime pm get (Imre)

Cc: Imre Deak <imre.deak@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230301122944.1298929-4-jani.nikula@intel.com

drm/i915/dmc: add i915_to_dmc() and dmc->i915 and use them

Start preparing for dynamically allocated struct intel_dmc by adding
i915_to_dmc() and dmc->i915, and using them. Take the future NULL dmc
pointer into account already now, and add separate logging for
initialization in the DMC debugfs.

v3:
- Obtain runtime pm reference first (Imre)

v2:
- Don't reduce debugfs output (Imre)

Cc: Imre Deak <imre.deak@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230301122944.1298929-3-jani.nikula@intel.com

drm/i915/dmc: use has_dmc_id_fw() instead of poking dmc->dmc_info directly

This will help in follow-up changes.

Cc: Imre Deak <imre.deak@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230301122944.1298929-2-jani.nikula@intel.com

drm/i915/power: move dc state members to struct i915_power_domains

There's only one reference to the struct intel_dmc members dc_state,
target_dc_state, and allowed_dc_mask within intel_dmc.c, begging the
question why they are under struct intel_dmc to begin with.

Moreover, the only references to i915->display.dmc outside of
intel_dmc.c are to these members.

They don't belong. Move them from struct intel_dmc to struct
i915_power_domains, which seems like a more suitable place.

Cc: Imre Deak <imre.deak@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230301122944.1298929-1-jani.nikula@intel.com

drm/i915: remove unnecessary intel_pm.h includes

As intel_pm.[ch] used to contain much more, intel_pm.h was included in a
lot of places. Many of them are now unnecessary. Remove.

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

drm/i915/pm: drop intel_suspend_hw()

All intel_suspend_hw() does is clear PCH_LP_PARTITION_LEVEL_DISABLE bit
in SOUTH_DSPCLK_GATE_D for LPT LP. intel_suspend_hw() gets called from
i915_drm_suspend().

However, i915_drm_suspend_late() calls
intel_display_power_suspend_late(), which in turn calls hsw_enable_pc8()
on HSW and BDW. The first thing that does is clear
PCH_LP_PARTITION_LEVEL_DISABLE bit in SOUTH_DSPCLK_GATE_D.

Remove the duplicated clearing of the bit, effectively delaying it from
i915_drm_suspend() to i915_drm_suspend_late(), and remove the
unnecessary intel_suspend_hw() function altogether.

Cc: Imre Deak <imre.deak@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/f732a7922c2450b41169c9b79a80fba97ab00592.1677678803.git.jani.nikula@intel.com

drm/i915/pm: drop intel_pm_setup()

All the init in intel_pm_setup() is related to runtime pm. Move them to
intel_runtime_pm_init_early(), and remove intel_pm_setup().

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

drm/i915/wm: remove display/ prefix from include

Remove the leftover from moving and renaming the file from driver top
level.

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

drm/i915/display: split out DSC and DSS registers

Relatively few places need the DSC and DSS register definitions. Move
them to intel_vdsc_regs.h.

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

drm/i915/dsi: fix DSS CTL register offsets for TGL+

On TGL+ the DSS control registers are at different offsets, and there's
one per pipe. Fix the offsets to fix dual link DSI for TGL+.

There would be helpers for this in the DSC code, but just do the quick
fix now for DSI. Long term, we should probably move all the DSS handling
into intel_vdsc.c, so exporting the helpers seems counter-productive.

Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/8232
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: stable@vger.kernel.org
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230301151409.1581574-1-jani.nikula@intel.com

drm/i915/hwmon: Accept writes of value 0 to power1_max_interval

The value shown by power1_max_interval in millisec is essentially:
((1.x * power(2,y)) * 1000) >> 10
Where x and y are read from a HW register. On ATSM, x and y are 0 on
power-up so the value shown is 0.

Writes of 0 to power1_max_interval had previously been disallowed to avoid
computing ilog2(0) but this resulted in the corner-case bug
below. Therefore allow writes of 0 now but special case that write to
x = y = 0.

Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/7754
Signed-off-by: Ashutosh Dixit <ashutosh.dixit@intel.com>
Reviewed-by: Badal Nilawar <badal.nilawar@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230228044334.3630391-1-ashutosh.dixit@intel.com

drm/i915/psr: Fix the delayed vblank w/a

Fix the code to correctly determine whether delayed vblank
is used or not.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230127173044.24108-3-ville.syrjala@linux.intel.com
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>

drm/i915/vrr: Fix "window2" handling

The "window2" delay is just the difference of vactive
(undelayed vblank) vs. vblank_start (delayed vblank).
Just use vblank_start during the VRR calculations so
that things work correctly regardless of whether delayed
vblank is used or not.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230127173044.24108-2-ville.syrjala@linux.intel.com
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>

drm/i915: Get HDR DPCD refresh timeout from VBT

Grab the HDR DPCD refresh timeout (time we need to wait after
writing the sourc OUI before the HDR DPCD registers are ready)
from the VBT.

Windows doesn't even seem to have any default value for this,
which is perhaps a bit weird since the VBT value is documented
as TGL+ and I thought the HDR backlight stuff might already be
used on earlier platforms. To play it safe I left the old
hardcoded 30ms default in place. Digging through some internal
stuff that seems to have been a number given by the vendor for
one particularly slow TCON. Although I did see 50ms mentioned
somewhere as well.

Let's also include the value in the debug print to ease
debugging, and toss in the customary connector id+name as well.

The TGL Thinkpad T14 I have sets this to 0 btw. So the delay
is now gone on this machine:
 [CONNECTOR:308:eDP-1] Detected Intel HDR backlight interface version 1
 [CONNECTOR:308:eDP-1] Using Intel proprietary eDP backlight controls
 [CONNECTOR:308:eDP-1] SDR backlight is controlled through PWM
 [CONNECTOR:308:eDP-1] Using native PCH PWM for backlight control (controller=0)
 [CONNECTOR:308:eDP-1] Using AUX HDR interface for backlight control (range 0..496)
 [CONNECTOR:308:eDP-1] Performing OUI wait (0 ms)

Cc: Lyude Paul <lyude@redhat.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230220164718.23117-1-ville.syrjala@linux.intel.com
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>

drm/i915/gen12: Update combo PHY init sequence

The bspec was updated with a minor change to the 'DCC mode select'
setting to be programmed during combo PHY initialization.

v2:
 - Keep the opencoded rmw behavior instead of switching to
   intel_de_rmw().  We need to read from a _LN register, but write to
   the _GRP register to update all lanes.

Bspec: 49291
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Matt Atwood <matthew.s.atwood@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230221201836.2886794-1-matthew.d.roper@intel.com

drm/i915: Move MCR_REG define to i915_reg_defs.h

Define MCR_REG() in the same header where i915_mcr_reg_t is defined,
like i915_reg_t and _MMIO(). It's a more natural place for such a
definition so it's not mixed with the registers for the platforms.

Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230224211221.1557268-1-lucas.demarchi@intel.com

drm/i915: Remove unused tmp assignment.

These are left overs from the conversion towards intel_de_rmw.

Fixes: aa80b2b12b89 ("drm/i915/display/panel: use intel_de_rmw if possible in panel related code")
Cc: Andrzej Hajda <andrzej.hajda@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230224153707.813953-1-rodrigo.vivi@intel.com

drm/i915/dg2: Add HDMI pixel clock frequencies 267.30 and 319.89 MHz

Add snps phy table values for HDMI pixel clocks 267.30 MHz and
319.89 MHz. Values are based on the Bspec algorithm for
PLL programming for HDMI.

Cc: stable@vger.kernel.org
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/8008
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Signed-off-by: Uma Shankar <uma.shankar@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230223043619.3941382-1-ankit.k.nautiyal@intel.com

drm/i915/psr: Use calculated io and fast wake lines

Currently we are using hardcoded 7 for io and fast wake lines.

According to Bspec io and fast wake times are both 42us for
DISPLAY_VER >= 12 and 50us and 32us for older platforms.

Calculate line counts for these and configure them into PSR2_CTL
accordingly

Use 45 us for the fast wake calculation as 42 seems to be too
tight based on testing.

Bspec: 49274, 4289

Cc: Mika Kahola <mika.kahola@intel.com>
Cc: José Roberto de Souza <jose.souza@intel.com>
Fixes: 64cf40a125ff ("drm/i915/psr: Program default IO buffer Wake and Fast Wake")
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/7725
Signed-off-by: Jouni Högander <jouni.hogander@intel.com>
Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230221085304.3382297-1-jouni.hogander@intel.com

drm/i915: Drop useless intel_dp_has_audio() argument

intel_dp_has_audio() has no need for the crtc_state, so don't
pass it in.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230220151731.6852-2-ville.syrjala@linux.intel.com
Reviewed-by: Uma Shankar <uma.shankar@intel.com>

drm/i915: Fix audio ELD handling for DP MST

I forgot to call intel_audio_compute_config() on DP MST, which
means ELD doesn't get populated and passed to the audio driver.

References: https://gitlab.freedesktop.org/drm/intel/-/issues/8097
Fixes: 5d986635e296 ("drm/i915/audio: Precompute the ELD")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230220151731.6852-1-ville.syrjala@linux.intel.com
Reviewed-by: Uma Shankar <uma.shankar@intel.com>

drm/i915: Mask page table errors on gen2/3 with FBC

FBC on gen2/3 seems to trigger page table errors. No visual
artifacts are visible, and essentially the same FBC
code works on gen4 so these seem entirely spurious. There
are also hints in gen3 bspec indicating that certain bits
in PGTBL_ER are just not wired up correctly in the
hardware.

Ideally we'd want to mask out only the bogus bits, but
sadly there is no mask for PGTBL_ER, and instead we are
forced to mask out all page table errors via EMR :(

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230125185234.21599-6-ville.syrjala@linux.intel.com
Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com>

drm/i915: Extract {i9xx,i965)_error_mask()

Pull the EMR calculation into small helpers.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230125185234.21599-5-ville.syrjala@linux.intel.com
Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com>

drm/i915: Dump PGTBL_ER on gen2/3/4 error interrupt

PGTBL_ER contains the individual reasons for the page table
error interrupt. Dump it out.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230125185234.21599-4-ville.syrjala@linux.intel.com
Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com>

drm/i915: Undo rmw damage to gen3 error interrupt handler

The gen2/gen3 irq code is supposed to be identical apart
from the 32bit vs. 16bit access width. The recent change
to intel_de_rmw() ruined that symmetry. Restore it to avoid
needless mental gymnastics when comparing the two codepaths.

And while at it remove the extra eir!=0 check that somehow
ended up in the gen2 codepath only.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230125185234.21599-3-ville.syrjala@linux.intel.com
Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com>

drm/i915: Mark FIFO underrun disabled earlier

At least on some platforms (tested on ctg) the way
vgacon does screen blanking seems to flag constant
FIFO underruns, which means we have to be prepared
for them while the driver is loading. Currently
there is a time window between drm_crtc_init() and
intel_sanitize_fifo_underrun_reporting() during
which FIFO underrun reporting is in fact marked as
enabled. Thus we may end up mistakenly detecting
these bogus underruns during driver init.

Close the race by marking FIFO underrun reporting
as disabled prior to even registering the crtc.
intel_sanitize_fifo_underrun_reporting()/etc. will
re-enable it later if needed.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230125185234.21599-2-ville.syrjala@linux.intel.com
Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com>

drm/i915/audio: Track audio state per-transcoder

The audio logic lives in the transcoder rather than the pipe,
so start tracking it like that.

This is only really important for bigjoiner cases where tracking
by pipe doesn't work at all since intel_audio_codec_{enable,disable}()
won't even be called for the slave pipe. This means the state
checker won't find the ELD for the slave pipe and gets upset.
The PD->has_audio readout does currently work since that gets
read out from the same transcoder for both pipes.

For other cases this doesn't actually matter since it's only
the normal pipe transcoders that are audio capable, whereas
the more special transcoders (EDP/DSI) are not.

v2: Fix kernel docs

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230222151454.24888-1-ville.syrjala@linux.intel.com
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/8222

drm/i915/display/power: use intel_de_rmw if possible

The helper makes the code more compact and readable.

Signed-off-by: Andrzej Hajda <andrzej.hajda@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230217111836.864959-1-andrzej.hajda@intel.com

drm/i915: Remove pointless register read

We just wrote the EDP transcoder's VTOTAL register a few lines
earlier, so instead of reading it back out again let's just
generate the same value for the transocder B/C register.

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

drm/i915: Sprinkle some FIXMEs about TGL+ DSI transcoder timing mess

The DSI code has some local hacks to program TRANS_VBLANK on
TGL+ (ICL DSI transcoders didn't have this register). That
will not work when we need to start using the delayed vblank
(for DSB purposes). Too lazy to figure out what the is going
on there, so just sprinkle FIXMEs in the hopes someone else
will spot them eventually.

v2: Only TRANS_{HBLANK,SET_CONTEXT_LATENCY} still no not
    exist for DSI transcoders, only TRANS_VBLANK

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

drm/i915: Configure TRANS_SET_CONTEXT_LATENCY correctly on ADL+

On TGL VBLANK.VBLANK_START was the mechanism by which we can
delay the pipe's internal vblank in relation to the transcoder's
vblank. On ADL+ that no longer does anything. Instead we must
now use the new TRANS_SET_CONTEXT_LATENCY register. Program it
accordingly.

And since VBLANK.VBLANK_START is no longer used by the hardware
on ADL+ let's just zero it out to make it stand out in register
dumps. Seeing the zeroed value should hopefully remind people
to check the other register instead.

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

drm/i915/dsb: Skip DSB command buffer setup if we have no LUTs

If we have no LUTs to load there is no point in setting up
the DSB command buffer.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230118163040.29808-9-ville.syrjala@linux.intel.com
Reviewed-by: Animesh Manna <animesh.manna@intel.com>

drm/i915/dsb: Nuke the DSB debug

We'll be wanting to start the DSB from the vblank evasion critical
section so printk()s are a big nono. Get rid of the debug print.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230118163040.29808-8-ville.syrjala@linux.intel.com
Reviewed-by: Animesh Manna <animesh.manna@intel.com>

drm/i915/dsb: Allow vblank synchronized DSB execution

Allow the caller to ask for the DSB commands to execute
during vblank.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230118163040.29808-7-ville.syrjala@linux.intel.com
Reviewed-by: Animesh Manna <animesh.manna@intel.com>

drm/i915/dsb: Define more DSB registers

Add definitions for more DSB registers. Less annoying spec
trawling when working on the DSB code.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230118163040.29808-2-ville.syrjala@linux.intel.com
Reviewed-by: Animesh Manna <animesh.manna@intel.com>

drm/i915/psr: Stop clobbering TRANS_SET_CONTEXT_LATENCY

The PSR code has no business mucking around with the
vblank delay. Currently nothing that depends on knowing
the exact vblank start scanline (eg. vblank evasion)
is aware of this and so will not work correctly.

The w/a seems to be for pre-production hw only, so let's
just nuke it.

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

drm/i915: Define transcoder timing register bitmasks

Define the contents of the transcoder timing registers using
REG_GENMASK() & co. For ease of maintenance let's just define
the bitmasks with the full 16bit width (also used by the
current hand rolled stuff) even though not all bits are actually
used. None of the unsued bits have ever contained anything.

Jani spotted that the CRT load detection code did use narrower
bitmasks, so that is now going to change. But that is fine
since any garbage in the high bits would have been caught by
the state checker that always used the full 16bit masks.

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

drm/i915: Add local adjusted_mode variable

Clean up the eyesore in intel_get_transcoder_timings() a
bit by adding a local 'adjusted_mode' variable.

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

drm/i915: Define the "unmodified vblank" interrupt bit

On TGL+ the normal "start of vblank" interrupt is the pipe's
(potentially delayed) version. Add the new bit for the
transcoder's "unmodified" vblank so I don't have to dig it
out from bspec every time.

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

drm/i915: Dump blanking start/end

With the delayed vblank we need to start knowing where
the blanking periods start. So let's start dumping
out also the blanking start/end timings.

And while at it let's try to make that huge list of
numbers somewhat legible by indicating what each value
means. Also drop the 'type' since that doesn't really
mean anything for the crtc_ timings.

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

drm/i915: s/PIPECONF/TRANSCONF/

Rename PIPECONF to TRANSCONF to make it clear what it actually
applies to.

While the usual convention is to pick the earliers name I think
in this case it's more clear to use the later name. Especially
as even the register offset is in the wrong range (0x70000 vs.
0x60000) and thus makes it look like this is per-pipe.

There is one place in gvt that's doing something with TRANSCONF
while iterating with for_each_pipe(). So that might not be doing
the right thing for TRANSCODER_EDP, dunno. Not knowing what it
does I left it as is to avoid breakage.

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

drm/i915: Give CPU transcoder timing registers TRANS_ prefix

Name the CPU transcoder timing registers TRANS_FOO rather than
just FOO. This is the modern name, after the pipe/transcoder split
happened. Makes it a bit more obvious whether you pass in a pipe or
a transcoder.

PIPESRC is a bit special as it's a pipe register, even though it
lives in the transcoder registers range (0x60000 instead of 0x70000).

And BCLRPAT I suppose is a transcoder register (since it has something
to do with the timing generator), but it doesn't even exist after gen4
so I left it to use the only name it ever had in bspec.

And while at it let's pass in the correct enum in few more
places why don't we. Although in all those places the distinction
doesn't matter.

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

drm/i915: Flatten intel_ddi_{enable,disable}_transcoder_clock()

Use an early return to get rid of the extra indentation level
in intel_ddi_{enable,disable}_transcoder_clock().

Also unify the platform handling in between the two while at
it.

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

drm/i915: Rename intel_ddi_{enable,disable}_pipe_clock()

What intel_ddi_{enable,disable}_pipe_clock() actually do is
enable the clock to the transcoder, not the pipe. Rename
accordingly.

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

drm/i915: Fix platform default aux ch for skl

SKL/derivatives have DDI E but no AUX E, so we need to pick
another aux ch as the platform default. DDI E is more or less
the other half of DDI A, so we pick AUX A.

In all other cases we should have a corresponding aux ch for
each DDI.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230216231312.32664-3-ville.syrjala@linux.intel.com
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>

drm/i915: Pimp encoder ddc_pin/aux_ch debug messages

Use encoder->name rather than port_name() in the debug messages
so that they actually make more sense.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230216231312.32664-2-ville.syrjala@linux.intel.com
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>

drm/i915: Restructure intel_bios_port_aux_ch()

Restructure intel_bios_port_aux_ch() to resemble the ddc_pin
counterpart, where the intel_bios.c stuff only deals with the
child device definition, and the platform default will come from
elsewhere.

This requires the introduction of AUX_CH_NONE as the value 0
is already taken to mean AUX_CH_A.

v2: Sort includes alphabetically (Ankit)
vCould we ask them to do a BIOS fix for all of them so that
we wouldn't keep getting these bug reports for each model
separately?

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230216231312.32664-1-ville.syrjala@linux.intel.com
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>

drm/i915/hwmon: Enable PL1 limit when writing limit value to HW

Previous documentation suggested that the PL1 power limit is always enabled
in HW. However we now find this not to be the case on some platforms (such
as ATSM). Therefore enable the PL1 power limit (by setting the enable bit)
when writing the PL1 limit value to HW.

Bspec: 51864

Signed-off-by: Ashutosh Dixit <ashutosh.dixit@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230216164944.2366150-3-ashutosh.dixit@intel.com

drm/i915/hwmon: Replace hwm_field_scale_and_write with hwm_power_max_write

hwm_field_scale_and_write has a single caller hwm_power_write and is
specific to hwm_power_write but makes it appear that it is a general
function which can have multiple callers. Replace the function with
hwm_power_max_write which is specific to hwm_power_write and use that in
future patches where the function needs to be extended.

Signed-off-by: Ashutosh Dixit <ashutosh.dixit@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230216164944.2366150-2-ashutosh.dixit@intel.com

drm/i915: Use encoder->devdata more

Switch a lot of the intel_bios_foo() stuff to just accept the
devdata (VBT child device info) directly, instead of taking
detours via vbt.ports[].

Also unify the function naming scheme.

v2: Drop the redundant "encoder" from the dp/hdmi specific functions

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

drm/i915: Add a few more debugs for failed framebuffer creation

Most of the .fb_create() failure paths are annotated but there
are a few that seem capable of failing silently (well, higher
level code should print something, just not anything actually
useful). Drop a few more hints into the log to aid in debugging.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230215222426.26085-2-ville.syrjala@linux.intel.com
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>

drm/i915: Don't leak the DPT if drm_framebuffer_init() fails

We are failing to free the already allocated DPT if the final
drm_framebuffer_init() fails. That would require idr_alloc() to
fail, so not very likely, but let's add the cleanup code anyway.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230215222426.26085-1-ville.syrjala@linux.intel.com
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>

drm/i915: Reduce ELD hex dumps a bit

Do the ELD hexdumps only up to the last differing byte.
The rest is typically all zeroes anyway so not much point
in dumping it.

Couldn't find anything for memcmp_diff_len() so
rolled my own.

v2: Use semantics and function name suggested by Jani

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

drm/i915: Include connector id+name in all backlight debugs/errors

With multi panel machines becoming more prominent it's also
important to know which connector's backlight we're talking
about. Include that information in all the backlight debug/error
messages.

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

drm/i915/quirks: Add inverted backlight quirk for HP 14-r206nv

This laptop uses inverted backlight PWM. Thus, without this quirk,
backlight brightness decreases as the brightness value increases and
vice versa.

Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/8013
Cc: stable@vger.kernel.org
Signed-off-by: Mavroudis Chatzilaridis <mavchatz@protonmail.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230201184947.8835-1-mavchatz@protonmail.com

drm/i915/display/misc: use intel_de_rmw if possible

The helper makes the code more compact and readable.

Signed-off-by: Andrzej Hajda <andrzej.hajda@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/20230110113656.4050491-1-andrzej.hajda@intel.com

drm/i915/display/interfaces: use intel_de_rmw if possible

The helper makes the code more compact and readable.

Signed-off-by: Andrzej Hajda <andrzej.hajda@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/20230105131046.2173431-8-andrzej.hajda@intel.com

drm/i915/display/panel: use intel_de_rmw if possible in panel related code

The helper makes the code more compact and readable.

Signed-off-by: Andrzej Hajda <andrzej.hajda@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/20230105131046.2173431-7-andrzej.hajda@intel.com

drm/i915/display/hdmi: use intel_de_rmw if possible

The helper makes the code more compact and readable.

Signed-off-by: Andrzej Hajda <andrzej.hajda@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/20230105131046.2173431-6-andrzej.hajda@intel.com

drm/i915/display/pch: use intel_de_rmw if possible

The helper makes the code more compact and readable.

Signed-off-by: Andrzej Hajda <andrzej.hajda@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/20230105131046.2173431-5-andrzej.hajda@intel.com

drm/i915/display/phys: use intel_de_rmw if possible

The helper makes the code more compact and readable.

Signed-off-by: Andrzej Hajda <andrzej.hajda@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/20230105131046.2173431-4-andrzej.hajda@intel.com