Child min_brightness is obsolete from VBT 234+, instead the new
min_brightness field in the main structure should be used.

This new field is 16 bits wide, so backlight_precision_bits is needed
to check if value needs to be scaled down but it is only available in
VBT 236+ so working around it by using the also new backlight_level
in the main struct.

v2:
- missed that backlight_data->level is also obsolete

v3:
- s/backlight/brightness to better match specification
- using u16 to specify brightness level instead of a u32 : 16

BSpec: 20149
Reviewed-by: NMatt Roper <matthew.d.roper@intel.com>
Signed-off-by: NJosé Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201008211932.24989-1-jose.souza@intel.com

ggtt offsets/alignments are u32 everywhere else. Don't use
a signed int for them here.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201008101608.8652-3-ville.syrjala@linux.intel.comReviewed-by: NImre Deak <imre.deak@intel.com>

when the hardware isn't going to use the aux plane there's no
real point in dealing with the relevant hardware restrictions.
So let's just skip all that when not necessary.

We can now also remove the offset=~0xfff behaviour for unused
color planes. Let's just zero out everyting so as to not leave
stale garbage behind to confuse people debugging the code.

v2: Explicitly set AUX_DIST to zero when there is no aux plane

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

When the number of potential color planes grew to 4 we stopped
setting all unused color plane offsets to ~0xfff. The code
still tries to do this, but actually does nothing since the
loop limits are bogus.

skl_check_main_surface() actually depends on this ~0xfff
behaviour as it will make sure to move the main surface
offset below the aux surface offset because the hardware
AUX_DIST must be a non-negative value [1], and for simplicity
it doesn't bother checking if the AUX plane is actually
needed or not. So currently it may end up shuffling the
main surface around based on some stale leftover AUX offset.

The skl+ plane code also just blindly calculates the AUX_DIST
whether or not the AUX plane is actually needed by the hw or
not, and that too will now potentially use some stale AUX
surface offset in the calculation. Would seem nicer to
guarantee a consistent non-negative AUX_DIST always.

So bring back the original ~0xfff offset behaviour for
unused color planes. Though it doesn't seem super likely
that this inconsistency would cause any real issues.

Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Fixes: 2dfbf9d2 ("drm/i915/tgl: Gen-12 display can decompress surfaces compressed by the media engine")
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201008101608.8652-1-ville.syrjala@linux.intel.comReviewed-by: NImre Deak <imre.deak@intel.com>

As with eDP and LVDS we should also respect the power cycle
delay on DSI panels. We are not using the power sequencer
for these, and we have no optimizations around the sleep
duration, so we just msleep() the whole thing away.

Note that the ICL+ DSI code doesn't seem to have any power
off/power cycle delay handling whatsoever. The only thing it
handles is the power on delay. As that looks pretty busted
in general I won't bother dealing with it for the time being.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201001151640.14590-6-ville.syrjala@linux.intel.comReviewed-by: NJani Nikula <jani.nikula@intel.com>

Just like with eDP let's wait for the power sequencer power
cycle delay before we reboot the machine, as otherwise we
can't guarantee the panel's minimum power cycle delay will
be respected.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201001151640.14590-5-ville.syrjala@linux.intel.comReviewed-by: NJani Nikula <jani.nikula@intel.com>

Extend the eDP panel power cycle delay wait on reboot handling
to cover all platforms. No reason to think that VLV/CHV are
in any way special since the documentation states that the
hardware power cycle delay goes back to its default value on
reset, and that may not be enough for all panels.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201001151640.14590-4-ville.syrjala@linux.intel.comReviewed-by: NJani Nikula <jani.nikula@intel.com>

Currently VLV/CHV use a reboot notifier to make sure the panel
power cycle delay isn't violated across a system reboot. Replace
that with the new encoder .shutdown() hook.

And let's also stop overriding the power cycle delay with the
max value. No idea why the current code does that. The already
programmed delay should be correct.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201001151640.14590-3-ville.syrjala@linux.intel.comReviewed-by: NJani Nikula <jani.nikula@intel.com>

Add a new encoder hook .shutdown() which will get called at the end
of the pci .shutdown() hook. We shall use this to deal with the
panel power cycle delay issues.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201001151640.14590-2-ville.syrjala@linux.intel.comReviewed-by: NJani Nikula <jani.nikula@intel.com>

As with RKL, DG1's VBT outputs are indexed according to PHY rather than
DDI.
Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
Reviewed-by: NLucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: NLucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201007002210.3678024-8-lucas.demarchi@intel.com

As with RKL, DG1's PHY C acts as a comp master for PHY D.

Bspec: 49291
Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
Signed-off-by: NLucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: NAnusha Srivatsa <anusha.srivatsa@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201007002210.3678024-7-lucas.demarchi@intel.com

The only bit we use in PHY_MISC is DE_IO_COMP_PWR_DOWN, and the bspec
details for that bit tell us that it need only be set for PHY-A and
PHY-B.  It also turns out that there isn't even an instance of the
PHY_MISC register for PHY-D on this platform.  Let's extend the EHL/RKL
logic that conditionally skips PHY_MISC usage to DG1 as well.

Bspec: 50107
Cc: Aditya Swarup <aditya.swarup@intel.com>
Cc: Clinton Taylor <Clinton.A.Taylor@intel.com>
Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
Signed-off-by: NLucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: NAnusha Srivatsa <anusha.srivatsa@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201007002210.3678024-6-lucas.demarchi@intel.com

Add tables to map the GMBUS pin pairs to GPIO registers and port to DDC.
From spec we have registers GPIO_CTL[1-4], so we should not do the 4->9
mapping as in ICL/TGL.

The values for VBT seem wrong in BSpec. For the current boards we
actually have a 1:1 mapping.

BSpec: 49311, 49945, 20124

Cc: Aditya Swarup <aditya.swarup@intel.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: NLucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: NMatt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201007002210.3678024-5-lucas.demarchi@intel.com

DG1 always uses a 38.4 MHz rawclk rather than the 19.2/24 MHz
frequencies on CNP+.  Note that register bits associated with this
frequency confusingly use 37 for the divider field rather than 38 as you
might expect.

For simplicity, let's just assume that this 38.4 MHz frequency will hold
true for other future platforms with "fake" PCH south displays and that
the CNP-style behavior will remain for other platforms with a real PCH.

Bspec: 49950
Bspec: 49309
Cc: Aditya Swarup <aditya.swarup@intel.com>
Cc: Clinton Taylor <Clinton.A.Taylor@intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
Signed-off-by: NLucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: NJosé Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201007002210.3678024-2-lucas.demarchi@intel.com

Recent update in documentation defeatured eDP HBR3 for EHL and JSL.

v2:
- Remove dead code in ehl_get_combo_buf_trans()

v3:
- Rebase

BSpec: 32247
Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: Vidya Srinivas <vidya.srinivas@intel.com>
Reviewed-by: NMatt Roper <matthew.d.roper@intel.com>
Signed-off-by: NJosé Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201005175447.93430-1-jose.souza@intel.com

Apply Display WA #22010492432 for combo PHY PLLs too. This should fix a
problem where the PLL output frequency is slightly off with the current
PLL fractional divider value.

I haven't seen an actual case where this causes a problem, but let's
follow the spec. It's also needed on some EHL platforms, but for that we
also need a way to distinguish the affected EHL SKUs, so I leave that
for a follow-up.

v2:
- Apply the WA at one place when calculating the PLL dividers from the
  frequency and the frequency from the dividers for all the combo PLL
  use cases (DP, HDMI, TBT). (Ville)

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NImre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201003001846.1271151-6-imre.deak@intel.com

Atm, if a full modeset is performed during the initial modeset the link
training will happen with uninitialized max DP rate and lane count. Make
sure the corresponding encoder state is initialized by adding an encoder
hook called during driver init and system resume.

A better alternative would be to store all states in the CRTC state and
make this state available for the link re-training code. Also instead of
the DPCD read in the hook there should be really a proper sink HW
readout in place. Both of these require a bigger rework, so for now opting
for this minimal fix to make at least full initial modesets work.

The patch is based on
https://patchwork.freedesktop.org/patch/101473/?series=10354&rev=3

v2: (Ville)
- s/sanitize_state/sync_state/
- No point in calling the hook when CRTC is disabled, remove the call.
- No point in calling the hook for MST, remove it.

v3: Check only DPCD_REV to avoid clobbering intel_dp->dpcd. (Ville)

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NImre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201005230154.1477653-1-imre.deak@intel.com

Some BIOSes set an unsupported/imprecise DP link rate (for instance on
TGL A stepping). Make sure that we do an encoder recompute and a modeset
in this case.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NImre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201003001846.1271151-4-imre.deak@intel.com

Move the checks to decide whether a fastset is possible during the
initial commit to an encoder hook. This check is really encoder specific
and the next patch will also require this adding a DP encoder specific
check.

v2: Fix negated condition in gen11_dsi_initial_fastset_check().
v3: Make sure to call the hook for all encoders on the crtc. (Ville)

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NImre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201005215311.1475666-1-imre.deak@intel.com

The BIOS of at least one ASUS-Z170M system with an SKL I have programs
the 101b WRPLL PDIV divider value, which is the encoding for PDIV=7 with
bit#0 incorrectly set.

This happens with the

"3840x2160": 30 262750 3840 3888 3920 4000 2160 2163 2168 2191 0x48 0x9

HDMI mode (scaled from a 1024x768 src fb) set by BIOS and the

ref_clock=24000, dco_integer=383, dco_fraction=5802, pdiv=7, qdiv=1, kdiv=1

WRPLL parameters (assuming PDIV=7 was the intended setting). This
corresponds to 262749 PLL frequency/port clock.

Later the driver sets the same mode for which it calculates the same
dco_int/dco_frac/div WRPLL parameters (with the correct PDIV=7 encoding).

Based on the above, let's assume that PDIV=7 was intended and the HW
just ignores bit#0 in the PDIV register field for this setting, treating
100b and 101b encodings the same way.

While at it add the MISSING_CASE() for the p0,p2 divider decodings.

v2: (Ville)
- Add a define for the incorrect divider value.
- Emit only a debug message when detecting the incorrect divider value.
- Use fallthrough from the incorrect divider value case.
- Add the MISSING_CASE()s.

v3: Return 0 freq for incorrect divider values. (Ville)

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NImre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201006013555.1488262-1-imre.deak@intel.com

Make lspcon_init() static since it's no longer needed outside
the compilation unit. This was correct in Kai-Heng's lspcon
patch, but I fumbled this when applying it.

Cc: Kai-Heng Feng <kai.heng.feng@canonical.com>
Reported-by: Nkernel test robot <lkp@intel.com>
Fixes: f542d671 ("drm/i915: Init lspcon after HPD in intel_dp_detect()")
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201002090446.21104-1-ville.syrjala@linux.intel.comReviewed-by: NChris Wilson <chris@chris-wilson.co.uk>

On HP 800 G4 DM, if HDMI cable isn't plugged before boot, the HDMI port
becomes useless and never responds to cable hotplugging:
[    3.031904] [drm:lspcon_init [i915]] *ERROR* Failed to probe lspcon
[    3.031945] [drm:intel_ddi_init [i915]] *ERROR* LSPCON init failed on port D

Seems like the lspcon chip on the system only gets powered after the
cable is plugged.

Consilidate lspcon_init() into lspcon_resume() to dynamically init
lspcon chip, and make HDMI port work.

v6:
 - Rebase on latest for-linux-next.
v5:
 - Consolidate lspcon_resume() with lspcon_init().
 - Move more logic into lspcon code.
v4:
 - Trust VBT in intel_infoframe_init().
 - Init lspcon in intel_dp_detect().
v3:
 - Make sure it's handled under long HPD case.
v2:
 - Move lspcon_init() inside of intel_dp_hpd_pulse().

Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/203Signed-off-by: NKai-Heng Feng <kai.heng.feng@canonical.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200610075542.12882-1-kai.heng.feng@canonical.com

Now that we've plumbed the crtc state all the way down we can
eliminate the DP_TP_{CTL,STATUS} register offsets from intel_dp,
and instead we derive them directly from the crtc state.

And thus we can get rid of the nasty hack in intel_ddi_get_config()
which mutates intel_dp during the readout.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200929233449.32323-12-ville.syrjala@linux.intel.comReviewed-by: NImre Deak <imre.deak@intel.com>

Get rid of mode crtc->config usage, and some ad-hoc intel_dp state
usage by plumbing the crtc state all the way down to the link training
code.

Unfortunately we do have to keep some cached state in intel_dp so
that we can do the "does the link need retraining?" checks from
the short hpd handler.

v2: Add intel_crtc_state forward declaration
v3: Don't kill the PHY test code totally since it's
    now in the hotplug work where we can get at the states
v4: Don't resurrect the debug scrambling disable bit (Imre)
    Use intel_dp_mst_is_master_trans() (Imre)
Reviewed-by: NImre Deak <imre.deak@intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201001111053.24451-1-ville.syrjala@linux.intel.com

Make the mess inside the buf trans funcs a bit more manageable by
splitting along the lines of output type.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200929233449.32323-10-ville.syrjala@linux.intel.comReviewed-by: NImre Deak <imre.deak@intel.com>

Make the mess inside the buf trans funcs a bit more manageable by
splitting along the lines of output type.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200929233449.32323-9-ville.syrjala@linux.intel.comReviewed-by: NImre Deak <imre.deak@intel.com>

Make the mess inside the buf trans funcs a bit more manageable by
splitting along the lines of output type.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200929233449.32323-8-ville.syrjala@linux.intel.comReviewed-by: NImre Deak <imre.deak@intel.com>

Make the mess inside the buf trans funcs a bit more manageable by
splitting along the lines of output type.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200929233449.32323-7-ville.syrjala@linux.intel.comReviewed-by: NImre Deak <imre.deak@intel.com>

Make the mess inside the buf trans funcs a bit more manageable by
splitting along the lines of output type.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200929233449.32323-6-ville.syrjala@linux.intel.comReviewed-by: NImre Deak <imre.deak@intel.com>

Doing any kind modeset stuff from the short hpd handler is
verboten. The ad-hoc PHY test modeset code violates this. And
by calling various link training related functions it's now
blocking further work to plumb the crtc state down into the
link training code.

Let's hack around that by pushing the PHY test stuff into the
hotplug work where it's less of a problem. Still not great but
at least acceptable. We take a few pages from the link retraining
handbook to handle the locking and whatnot.

v2: Fix the intel_dp_hotplug() return value
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200930100412.9313-1-ville.syrjala@linux.intel.comReviewed-by: NImre Deak <imre.deak@intel.com>

intel_dp_process_phy_request() has no business being externally
visible. Make it static.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200929233449.32323-4-ville.syrjala@linux.intel.comReviewed-by: NImre Deak <imre.deak@intel.com>

intel_dp_enable_port() is called during the enable sequence,
so there is nothing old about the passed in crtc state.
Rename it.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200929233449.32323-3-ville.syrjala@linux.intel.comReviewed-by: NImre Deak <imre.deak@intel.com>

I managed to fumble some functions names. Fix them.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200929233449.32323-2-ville.syrjala@linux.intel.comReviewed-by: NImre Deak <imre.deak@intel.com>

The HDMI vs. not-HDMI check got inverted whem the bogus encoder->type
checks were eliminated. So now we're using 0 as the link rate on DP
and potentially non-zero on HDMI, which is exactly the opposite of
what we want. The original bogus check actually worked more correctly
by accident since if would always evaluate to true. Due to this we
now always use the RBR/HBR1 vswing table and never ever the HBR2+
vswing table. That is probably not a good way to get a high quality
signal at HBR2+ rates. Fix the check so we pick the right table.

Cc: stable@vger.kernel.org
Cc: Vandita Kulkarni <vandita.kulkarni@intel.com>
Cc: Uma Shankar <uma.shankar@intel.com>
Fixes: 94641eb6 ("drm/i915/display: Fix the encoder type check")
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200930223642.28565-1-ville.syrjala@linux.intel.comReviewed-by: NJosé Roberto de Souza <jose.souza@intel.com>
Reviewed-by: NVandita Kulkarni <vandita.kulkarni@intel.com>

Implement display w/a #1142. This supposedly fixes some underruns
with FBC+VTd. Bspec says we should use the same programming regardless
of circumstances. Apparently we should flip the magic bits before
turning on any planes so let's put this into the early w/as.

Cc: Lee Shawn C <shawn.c.lee@intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200924194810.10293-1-ville.syrjala@linux.intel.comReviewed-by: NJosé Roberto de Souza <jose.souza@intel.com>

In case of DSI cmd mode, we get hw vblank counter updated after the TE
comes in, if we try to read the hw vblank counter in te handler we
wouldnt have the udpated vblank counter yet. This will lead to a state
where we would send the vblank event to the user space in the next te,
though the frame update would have completed in the first TE duration
itself. Hence switch to using software timestamp based vblank counter.

v2: Use mode_flags from crtc_state (Ville)
Acked-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NVandita Kulkarni <vandita.kulkarni@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200924124209.17916-6-vandita.kulkarni@intel.com

In TE Gate mode or TE NO_GATE mode on every flip we need to set the
frame update request bit. After this bit is set transcoder hardware will
automatically send the frame data to the panel in case of TE NO_GATE
mode, where it sends after it receives the TE event in case of TE_GATE
mode. Once the frame data is sent to the panel, we see the frame counter
updating.

v2: Use intel_de_read/write

v3: remove the usage of private_flags

v4: Use icl_dsi in func names if non static,
    fix code formatting issues. (Jani)

v5: Send frame update request at the beginning of
    pipe_update_end, use crtc_state mode_flags (Ville)

v6: Add platform and dsi checks (Ville)
Acked-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NVandita Kulkarni <vandita.kulkarni@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200928110834.15077-1-vandita.kulkarni@intel.com

We need details about enabling TE on which port before we enable TE
through vblank enable path. This is based on the configuration that we
receive from the VBT wrt ports, dual_link.
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Acked-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NVandita Kulkarni <vandita.kulkarni@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200924124209.17916-2-vandita.kulkarni@intel.com

Since gamma_mode can have more than two values on ilk+
let's use switch statements when interpreting them.

v2: Fix typo (Uma)
Reviewed-by: NUma Shankar <uma.shankar@intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200925131656.10022-10-ville.syrjala@linux.intel.com

Since bdw_read_lut_10() uses the auto-increment mode we must
have an equal number of entries in the software LUT and the
hardware LUT. WARN if that is not the case.
Reviewed-by: NUma Shankar <uma.shankar@intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200925131656.10022-9-ville.syrjala@linux.intel.com