We need to start parsing stuff from the tail end of the LFP data block.
This is made awkward by the fact that the fp_timing table has variable
size. So we must use a bit more finesse to get the tail end, and to
make sure we allocate enough memory for it to make sure our struct
representation fits.

v2: Rebase due to the preallocation of BDB blocks
v3: Rebase due to min_size WARN relocation
v4: Document BDB_LVDS_LFP_DATA vs. BDB_LVDS_LFP_DATA_PTRS order (Jani)
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220504150440.13748-4-ville.syrjala@linux.intel.com

Modern VBTs no longer contain the LFP data table pointers
block (41). We are expecting to have one in order to be able
to parse the LFP data block (42), so let's make one up.

Since the fp_timing table has variable size we must somehow
determine its size. Rather than just hardcode it we look for
the terminator bytes (0xffff) to figure out where each table
entry starts. dvo_timing, panel_pnp_id, and panel_name are
expected to have fixed size.

This has been observed on various machines, eg. TGL with BDB
version 240, CML with BDB version 231, etc. The most recent
VBT I've observed that still had block 41 had BDB version
228. So presumably the cutoff (if an exact cutoff even exists)
is somewhere around BDB version 229-231.

v2: kfree the thing we allocated, not the thing+3 bytes
v3: Do the debugprint only if we found the LFP data block
v4: Fix t0 null check (Jani)
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220504150440.13748-3-ville.syrjala@linux.intel.com

Reorder things so that we can parse the entier LFP data block
in one go. For now we just stick to parsing the DTD from it.

Also fix the misleading comment about block 42 being deprecated.
Only the DTD part is deprecated, the rest is still very much needed.

v2: Move the version check+comment into parse_generic_dtd() (Jani)
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220504150440.13748-2-ville.syrjala@linux.intel.com

Initialize on-stack modes with drm_mode_init() to guarantee
no stack garbage in the list head, or that we aren't copying
over another mode's list head.

Based on the following cocci script, with manual fixups:
@decl@
identifier M;
expression E;
@@
- struct drm_display_mode M = E;
+ struct drm_display_mode M;

@@
identifier decl.M;
expression decl.E;
statement S, S1;
@@
struct drm_display_mode M;
... when != S
+ drm_mode_init(&M, &E);
+
S1

@@
expression decl.E;
@@
- &*E
+ E
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220218100403.7028-19-ville.syrjala@linux.intel.comReviewed-by: NJani Nikula <jani.nikula@intel.com>

Make sure each DDI platform has sane ->get_buf_trans initialized.
Suggested-by: NMatt Roper <matthew.d.roper@intel.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Reviewed-by: NArun R Murthy <arun.r.murthy@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220503082134.4128355-1-jani.nikula@intel.com

Using compound literals for initialization can be tricky. Lacking a
const qualifier, they won't end up in rodata, which is probably not
expected or intended. Add const to move a whopping 136 initializers to
rodata.

Compare:

$ objdump --syms drivers/gpu/drm/i915/display/intel_display_power_map.o | grep "\.rodata.*__compound_literal"
$ objdump --syms drivers/gpu/drm/i915/display/intel_display_power_map.o | grep "\.data.*__compound_literal"

Before and after the change.

Fixes: c32ffce4 ("drm/i915: Convert the power well descriptor domain mask to an array of domains")
Fixes: 4a845ff0 ("drm/i915: Simplify power well definitions by adding power well instances")
Cc: Imre Deak <imre.deak@intel.com>
Cc: Jouni Högander <jouni.hogander@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Reviewed-by: NImre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220429142140.2671828-1-jani.nikula@intel.com

To avoid AUX timeouts and subsequent spurious hotplug interrupts, make
sure that the first DPCD access during detection is a read from an LTTPR
register.

Some ADLP DP link configuration at least with multiple LTTPRs expects
the first DPCD access during the LTTPR/DPCD detection after hotplug to
be a read from the LTTPR range starting with
DP_LT_TUNABLE_PHY_REPEATER_FIELD_DATA_STRUCTURE_REV. The side effect of
this read is to put each LTTPR into the LTTPR transparent or LTTPR
non-transparent mode.

The lack of the above read may leave some of the LTTPRs in non-LTTPR
mode, while other LTTPRs in LTTPR transparent or LTTPR non-transparent
mode (for instance LTTPRs after system suspend/resume that kept their
mode from before suspend). Due to the different AUX timeouts the
different modes imply, the DPCD access from a non-LTTPR range will
timeout and lead to an LTTPR generated hotplug towards the source (which
the LTTPR firmware uses to account for buggy TypeC adapters with a long
wake-up delay).

SYSCROS: 72939

v2: Keep DPCD read-out working on non-LTTPR platforms.
v3: Summarize what and why the patch does at the beginning of the commit
    log. (Jani)
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220408224629.845887-1-imre.deak@intel.com

Start splitting the .compute_crtc_clock() into two parts; one
part does the computation, the second part does the shared dpll
assignment. I want to move the actual computation part much earlier
into the compute_config() phase.

v2: dg2_crtc_get_shared_dpll() not needed (Jani)
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220325123205.22140-10-ville.syrjala@linux.intel.comReviewed-by: NJani Nikula <jani.nikula@intel.com>

DG2 doesn't currently used the shared_dpll stuff so let's just
split it out from hsw_crtc_compute_clock() entirely.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220325123205.22140-9-ville.syrjala@linux.intel.comReviewed-by: NJani Nikula <jani.nikula@intel.com>

Clear the dpll_hw_state when we're about disable the pipe.
Previously it looks like we just left the old junk in there.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220325123205.22140-8-ville.syrjala@linux.intel.comReviewed-by: NJani Nikula <jani.nikula@intel.com>

All .crtc_compute_clock() implementations do the same memset() to
clear the dpll_hw_state (since we preserve it across
intel_crtc_prepare_cleared_state()). Move the memset() to the common
wrapper.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220325123205.22140-7-ville.syrjala@linux.intel.comReviewed-by: NJani Nikula <jani.nikula@intel.com>

Move some checks into intel_dpll_crtc_compute_clock() from the
caller. Avoids the caller from having to worry about all this
crap.

We'll also reorder the hw.enable vs. shared_dpll checks since
it makes sense to sanity check that we've cleared out the
old shared_dpll even if the pipe is getting disabled.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220325123205.22140-6-ville.syrjala@linux.intel.comReviewed-by: NJani Nikula <jani.nikula@intel.com>

Pass the full atomic state+crtc rather than the redundant
crtc+crtc_state pair. We already need the full atomic state
in the hsw+ codepath anyway.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220325123205.22140-5-ville.syrjala@linux.intel.comReviewed-by: NJani Nikula <jani.nikula@intel.com>

All platforms have dpll_funcs. Remove the pointless NULL checks.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220325123205.22140-4-ville.syrjala@linux.intel.comReviewed-by: NJani Nikula <jani.nikula@intel.com>

Stop passing around the drm_device and just pass the
dev_priv instead.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220325123205.22140-3-ville.syrjala@linux.intel.comReviewed-by: NJani Nikula <jani.nikula@intel.com>

Get rid of the confusing back and forth between bools and ints
in the .get_dplls() stuff. Just make everything return an int.

Initial conversion done with cocci, with some manual fixups on top:
@find@
identifier func !~ "get_hw_state|_is_|needed";
typedef bool;
parameter list[N] P;
@@
- bool
+ int
 func(P)
{
<...
(
- return true;
+ return 0;
|
- return false;
+ return -EINVAL;
)
...>
}

@@
identifier find.func;
expression list[find.N] E;
expression X;
@@
- if (!func(E))
+ ret = func(E);
+ if (ret)
  {
  ...
- return X;
+ return ret;
  }

@@
identifier find.func;
expression X;
expression list[find.N] E;
@@
- if (!func(E))
+ ret = func(E);
+ if (ret)
- return X;
+ return ret;

@@
identifier find.func;
expression list[find.N] E;
expression O, X;
typedef bool;
bool B;
@@
- B = func(E);
- if (O && !B)
+ if (O) {
+ ret = func(E);
+ if (ret)
- return X;
+ return ret;
+ }

@@
identifier find.func;
expression list[find.N] E;
expression O, X;
@@
- if (O && !func(E))
+ if (O) {
+ ret = func(E);
+ if (ret)
- return X;
+ return ret;
+ }

@@
identifier find.func;
expression list[find.N] E;
expression X;
typedef bool;
bool B;
@@
- B = func(E);
- if (!B)
+ ret = func(E);
+ if (ret)
  {
  ...
- return X;
+ return ret;
  }
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220325123205.22140-2-ville.syrjala@linux.intel.comReviewed-by: NJani Nikula <jani.nikula@intel.com>

intel_fbc_check_plane() is supposed to an int, not a boolean.
So replace the bogus 'return false's with the correct 'return 0's.
These were accidental copy-paste mistakes when the code got moved
into intel_fbc_check_plane() from somewhere else tht did return
a boolean.

No functional issue here since false==0.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220413152852.7336-2-ville.syrjala@linux.intel.comReviewed-by: NManasi Navare <manasi.d.navare@intel.com>

plane_state->uapi.crtc is not what we want to be looking at.
If bigjoiner is used hw.crtc is what tells us what crtc the plane
is supposedly using.

Not an actual problem on current hardware as the only FBC capable
pipe (A) can't be a bigjoiner slave and thus uapi.crtc==hw.crtc
always here. But when we get more FBC instances this will become
actually important.

Fixes: 2e6c99f8 ("drm/i915/fbc: Nuke lots of crap from intel_fbc_state_cache")
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220413152852.7336-1-ville.syrjala@linux.intel.comReviewed-by: NManasi Navare <manasi.d.navare@intel.com>

We have now seen panel (XMG Core 15 e21 laptop) advertizing support
for Intel proprietary eDP backlight control via DPCD registers, but
actually working only with legacy pwm control.

This patch adds panel EDID check for possible HDR static metadata and
Intel proprietary eDP backlight control is used only if that exists.
Missing HDR static metadata is ignored if user specifically asks for
Intel proprietary eDP backlight control via enable_dpcd_backlight
parameter.

v2 :
- Ignore missing HDR static metadata if Intel proprietary eDP
  backlight control is forced via i915.enable_dpcd_backlight
- Printout info message if panel is missing HDR static metadata and
  support for Intel proprietary eDP backlight control is detected

Fixes: 4a8d7990 ("drm/i915/dp: Enable Intel's HDR backlight interface (only SDR for now)")
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5284
Cc: Lyude Paul <lyude@redhat.com>
Cc: Mika Kahola <mika.kahola@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Filippo Falezza <filippo.falezza@outlook.it>
Cc: stable@vger.kernel.org
Signed-off-by: NJouni Högander <jouni.hogander@intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220413082826.120634-1-jouni.hogander@intel.comReviewed-by: NLyude Paul <lyude@redhat.com>

The wrong v2 version of
drm/i915: Move per-platform power well hooks to intel_display_power_well.c

patch was pushed to drm-intel-next branch instead of v3, fix this up
applying the difference between v2 and v3.
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NJouni Högander <jouni.hogander@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220415082524.1826924-1-imre.deak@intel.com

The spec calls the XELPD_D/E ports just D/E, the platform prefix in the
domain names was only needed by the port->domain mapping relying on
matching enum values for the whole port/domain range (and the
corresponding aliasing between the platform specific domain enums).
Since a previous patch we can define the port->domain mapping explicitly
so do this by reusing the already existing D/E power domain names.
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NJouni Högander <jouni.hogander@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220414210657.1785773-18-imre.deak@intel.com

The DDI and AUX domain -> power well mappings are identical for a few
platforms/power well instances, reuse the mappings of earlier platforms
for these removing the duplicate mapping of new platforms.
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NJouni Högander <jouni.hogander@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220414210657.1785773-17-imre.deak@intel.com

The spec calls the ICL TBT AUX power well instances TBT1-4 (similarly to
all later platforms), align the power domain names with the spec.
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NJouni Högander <jouni.hogander@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220414210657.1785773-16-imre.deak@intel.com

Aliasing the intel_display_power_domain enum values was required because
of the u64 power domain mask size limit. This makes the dmesg/debugfs
printouts of the domain names somewhat unclear, for instance domain
names for port D are shown on D12+ platforms where the corresponding
port is called TC1. Make this clearer by removing the aliasing which is
possible after a previous patch converting the mask to a bitmap.
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NJouni Högander <jouni.hogander@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220414210657.1785773-15-imre.deak@intel.com

Atm the port -> DDI and AUX power domain mapping is specified by relying
on the aliasing of the platform specific intel_display_power_domain enum
values. For instance D12+ platforms refer to the 'D' port and power
domain instances, which doesn't match the bspec terminology, on these
platforms the corresponding port is TC1. To make it clear what
port/domain the code refers to add a mapping between them which matches
the bspec terms on different display versions.

This also allows for removing the aliasing in enum values in a follow-up
patch.

v2: Add the functions to intel_display_power.c, use
    intel_display_power_ prefix.
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NJouni Högander <jouni.hogander@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220414210657.1785773-14-imre.deak@intel.com

Instead of the skip_mask special casing of the ADL-S power well
descriptors, add a power well descriptor list for ADL-S as well reusing
the TGL descriptors, w/o the TC-cold power well. ADL-S doesn't have
TypeC PHYs, so a better way would be having ADL-S specific AUX
descriptors, but I left changing this for a follow-up.

This changes the ordering of the AUX and TC-cold vs. PW_4/5 power wells
on TGL and ADL-S, but this shouldn't make a difference (PW_4/5 don't
depend on the AUX/TC-cold power wells).
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NJouni Högander <jouni.hogander@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220414210657.1785773-13-imre.deak@intel.com

Simplify the definition of DG1 power wells by reusing the identical
RKL DDI/AUX descriptors.

This reorders the DG1 DDI/AUX vs. PW4/5 power wells, but this shouldn't
make a difference (it is the order on RKL and the DDI/AUX power wells
don't have a dependency on PW4/5).
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NJouni Högander <jouni.hogander@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220414210657.1785773-12-imre.deak@intel.com

Some power wells - like always-on and skl+/icl+ PW_1 - with the same
name, domain list, flags, ops are used by multiple platforms, so allow
platforms to reuse the descriptors of such power wells.

This change also lets the follow up patches to simplify the DG1/RKL
power well definitions, and remove the ADL-S skip_mask special casing.
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NJouni Högander <jouni.hogander@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220414210657.1785773-11-imre.deak@intel.com

All the port specific AUX/DDI_IO power wells share the same power well
ops struct and flags, so we can save some space and simplify the
definition of these by listing for all such power wells only the params
specific to them (name, domains, power well register index, id). Move
these params to a new i915_power_well_instance struct and convert the
per-platform power well definitions accordingly.

For all power well instance the name and power domain list params must
be specified, while the register index and id are optional, add the
I915_PW() macro that both simplifies the definitions and ensures that
the required params are set.
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NJouni Högander <jouni.hogander@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220414210657.1785773-10-imre.deak@intel.com

To remove the aliasing of the power domain enum values in a follow-up
patch in this patchset (requiring a bigger mask) and allow for defining
additional power domains in the future (at least some upcoming TypeC
changes requires this) convert the u64 i915_power_well_desc::domains
mask to a bitmap.

For simplicity I changed the for_each_power_domain_well() macros to
accept one domain only instead of a mask, as there isn't any current
user passing multiple domains.

v2: Don't add a typedef for the bitmap struct. (Jani)

Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NJouni Högander <jouni.hogander@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220414210657.1785773-9-imre.deak@intel.com

The next patch converts the i915_power_well_desc::domain mask from a u64
mask to a bitmap. I didn't find a reasonably simple way to initialize
bitmaps statically, so prepare for the next patch here by converting the
masks to an array of domain enums and initing the masks from these
arrays during module loading.

v2: Clarify list vs. array in the commit message. (Jani)

Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NJouni Högander <jouni.hogander@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220414210657.1785773-8-imre.deak@intel.com

Use the shortest descriptive name for all power wells for simplicity and
to use the same name for the same type of power wells on multiple
platforms.
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NJouni Högander <jouni.hogander@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220414210657.1785773-7-imre.deak@intel.com

Make all power domain names end with the pipe/port instance for
consistency.

No functional changes.
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NJouni Högander <jouni.hogander@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220414210657.1785773-6-imre.deak@intel.com

Save some space by grouping the HSW power well descriptor flags along
with other flags in one bitfield.

This change also lets simplifying the definition of power well
descriptors sharing the same flags in an upcoming patch.
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NJouni Högander <jouni.hogander@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220414210657.1785773-5-imre.deak@intel.com

The DG2 fixed delay duration is always 600usec, so save some space in
the power well descriptors by converting the parameter to a flag. While
at it also use a bitfield for both the always_on and fixed_enable_delay
flag.

This change also lets simplifying the definiton of power wells sharing
the same flags in an upcoming patch.
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NJouni Högander <jouni.hogander@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220414210657.1785773-4-imre.deak@intel.com

Move the list of platform specific power domain -> power well
definitions to intel_display_power_map.c. While at it group the
platforms' power domain macros with the corresponding power well lists
and keep all the power domain lists in the same order (matching the enum
order).

No functional changes.

v2:
- s/intel_display_power_internal.h/intel_display_power_map.h/ (Jani)
- Simplify intel_cleanup_power_wells().
- Don't move intel_display_power_domain_str().
v3:
- Rename intel_init/cleanup_power_wells() to
  intel_display_power_map_init/cleanup().
- Add documentation to intel_display_power_map_init/cleanup().

Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NJouni Högander <jouni.hogander@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220414210657.1785773-3-imre.deak@intel.com

The for_each_power_well() macros are only used in intel_display_power.c
and intel_display_power_well.c, so unexport them.
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NJouni Högander <jouni.hogander@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220414210657.1785773-2-imre.deak@intel.com

Move the implementation of platform specific power well hooks to
intel_display_power_well.c, to reduce the clutter in
intel_display_power.c.

The locking of all the power domain/power well state is handled in the
power domain functions in intel_display_power.c using
i915_power_domains::lock. This patch also moves the
chy_phy_powergate_ch/lanes() functions to intel_display_power_well.c
which borrow the same lock to protect the DISPLAY_PHY_CONTROL register
state, which the HW uses both for toggling power wells and power gating
PHY lanes.

No functional change.

v2:
- Clarify in the commit log why CHV functions using the
  i915_power_domains::lock were moved, while others locking the power
  domain/well state were kept in intel_display_power.c . (Jouni)
- Move forward declaration of chv_phy_powergate_ch/lanes() to
  intel_display_power_well.h .
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NJouni Högander <jouni.hogander@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220414210657.1785773-1-imre.deak@intel.com

This workaround fixes screen flickers with FBC.

BSpec: 33450
BSpec: 52890
BSpec: 54369
BSpec: 66624
Reviewed-by: NMatt Roper <matthew.d.roper@intel.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: NJosé Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220419182753.364237-1-jose.souza@intel.com

Follow the new i9xx DPLL FP register programming sequence
introduced in commit 62d66b21 ("drm/i915: Fold
i9xx_set_pll_dividers() into i9xx_enable_pll()") in the
i830 "power well" code as well. Just for consistency.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220321195006.775-2-ville.syrjala@linux.intel.comReviewed-by: NJani Nikula <jani.nikula@intel.com>