drm/i915: remove unused DDC PIN macros

Their user has vanished in the course of history. Remove.

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

drm/i915/bios: rename intel_aux_ch() to intel_bios_port_aux_ch()

Conform to function naming in intel_bios.c.

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/20181115105237.1237-1-jani.nikula@intel.com

drm/i915/hdmi: Reorder structure to match specification

reorder structure of 297, 594 N values to group Audio Sample Frequencies
together to make updating from HDMI specification easier.

V2: Match patch 1/2 version
V3: Arrange by sample freq, then pixel clock.

Cc: Jani Nikula <jani.nikula@linux.intel.com>
Signed-off-by: Clint Taylor <clinton.a.taylor@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1541019295-20016-1-git-send-email-clinton.a.taylor@intel.com

drm/i915: remove excess line continuation backslashes

While removing .palette_offsets, I removed the commas after
.trans_offsets in the macros, but failed to remove the line continuation
backslashes.

While at it, also remove another extra comma to be in line with the
other related macros.

Fixes: 74c1e826427a ("drm/i915: remove palette_offsets from device info in favor of _PICK()")
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181114112130.22264-1-jani.nikula@intel.com

drm/i915: Fix plane allocation/free functions

Use intel_plane_destroy_state in intel_plane_free to free the state.
Also fix intel_plane_alloc() to use __drm_atomic_helper_plane_reset(),
to get sane defaults from the atomic core.

This is needed to get the correct alpha value and blend mode from the
core, and any new default values added from new properties.

Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reported-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Fixes: b20815255693 ("drm/i915: Add plane alpha blending support, v2.")
[mlankhorst: Update commit description to mention alpha blend support]
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181113092804.13304-1-maarten.lankhorst@linux.intel.com

drm/i915: Remove special case for power well 1/MISC_IO state verification

Even though PW#1 and the MISC_IO power wells are managed by the
DMC firmware (toggled dynamically if conditions allow it) from the
driver's POV they are always on if the display core is initialized
(always restored by DMC to the enabled state after exiting from DC5/6
for instance b/c of MMIO access). Accordingly we can just mark them as
always-on and remove the special casing for them during state
verification (thus enabling verification for these power wells too).

Cc: Ramalingam C <ramalingam.c@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181109145822.15446-3-imre.deak@intel.com

drm/i915: Use proper bool bitfield initializer in power well descs

We can just use a proper true/false initializer even for bitfields,
which is more descriptive.

Cc: Ramalingam C <ramalingam.c@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181109145822.15446-2-imre.deak@intel.com

drm/i915/gen9_bc: Work around DMC bug zeroing power well requests

A DMC bug on GEN9 big core machines fails to restore the driver's
request bits for the PW1 and MISC_IO power wells after a DC5/6
entry->exit sequence. As a consequence the driver's subsequent check for
the enabled status of these power wells will fail, as the check
considers the power wells being enabled only if both the status and
request bits are set. To work around this borrow the request bits from
BIOS's own request register in which DMC forces on the request bits when
exiting from DC5/6.

This fixes a problem reported by Ramalingam, where HDCP init failed,
since PW1 reported itself as being disabled, while in reality it was
enabled.

Reported-by: Ramalingam C <ramalingam.c@intel.com>
Cc: Ramalingam C <ramalingam.c@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181109145822.15446-1-imre.deak@intel.com

drm/i915: Fix icl workarounds whitespaces

Align icl workarounds whitespace with the rest of the file

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20181109145333.10570-2-mika.kuoppala@linux.intel.com

drm/i915: Deduplicate register definition for GAMW_ECO_DEV_RW_IA

This got duplicated on introducing icl workarounds.
Fix by using the older definition and moving the wa bit
definition there. No functional changes.

v3: avoid fixes tag, whitespace (Chris)

References: 908ae0517363 ("drm/i915/icl: WaDisCtxReload")
Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20181109145333.10570-1-mika.kuoppala@linux.intel.com

drm/i915/icl: Drop spurious register read from icl_dbuf_slices_update

Register DBUF_CTL_S2 is read and it's value is not used. As
there is no explanation why we should prime the hardware with
read, remove it as spurious.

Fixes: aa9664ffe863 ("drm/i915/icl: Enable 2nd DBuf slice only when needed")
Cc: Mahesh Kumar <mahesh1.kumar@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181109140924.2663-1-mika.kuoppala@linux.intel.com

drm/i915: add ICP support to cnp_rawclk() and kill icp_rawclk()

I think I'm probably the one who argued in favor of having separate
implementations for both PCHs, but the calculations are actually the
same, the clocks are the same and the only difference is that on ICP
we write the numerator to the register.

I have previously suggested to kill cnp_rawclk() and keep the
icp_rawclk() style, but Ville gave some good arguments that what's in
this patch may be the better choice.

v2: Switch numerator to 1 from 1000 and adjust calculations
    accordingly (Ville).

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181112232313.26373-3-paulo.r.zanoni@intel.com

drm/i915: rename CNP_RAWCLK_FRAC to CNP_RAWCLK_DEN

Although CNP names this field "Counter Fraction", what we write to the
register is really the denominator for the fractional part of the
divider, not the fractional part (and the field description even says
that). The ICP spec renamed the field to "Counter Fraction
Denominator", which makes a lot more sense. Use the more complete ICL
naming because we will merge the CNP and ICP functions into a single
one, which will introduce the concept of the numerator. That will make
a lot more sense when you read the "num/frac = den" calculation.

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181112232313.26373-2-paulo.r.zanoni@intel.com

drm/i915/cnp+: update to the new RAWCLK_FREQ recommendations

BSpec was updated and now there's no more "subtract 1" to the
Microsecond Counter Divider field.

It seems this should help fixing some GMBUS issues. I'm not aware of
any specific open bug that could be solved by this patch.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181112232313.26373-1-paulo.r.zanoni@intel.com

drm/i915: Determine DSI panel orientation from VBT

VBT appears to have two (or possibly three) ways to indicate the panel
rotation. The first is in the MIPI config block, but that apparenly
usually (maybe always?) indicates 0 degrees despite the actual panel
orientation. The second way to indicate this is in the general features
block, which can just indicate whether 180 degress rotation is used.
The third might be a separate rotation data block, but that is not
at all documented so who knows what it may contain.

Let's try the first two. We first try the DSI specicic VBT
information, and it it doesn't look trustworthy (ie. indicates
0 degrees) we fall back to the 180 degree thing. Just to avoid too
many changes in one go we shall also keep the hardware readout path
for now.

If this works for more than just my VLV FFRD the question becomes
how many of the panel orientation quirks are now redundant?

v2: Move the code into intel_dsi.c (Jani)

Cc: Hans de Goede <hdegoede@redhat.com>
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/20181022142015.4026-1-ville.syrjala@linux.intel.com
Tested-by: Hans de Goede <hdegoede@redhat.com>

drm/i915: Fix the VLV/CHV DSI panel orientation hw readout

Let's make sure the DSI port is actually on before we go
poking at the plane register to determine which way
it's rotated. Otherwise we could be looking at a plane
that is feeding a HDMI port for instance.

And in order to read the plane register we need the power
well to be on. Make sure that is indeed the case. We'll
also make sure the plane is actually enabled before we
trust the rotation bit to tell us the truth.

v2: s/intel_dsi/vlv_dsi/

Cc: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181022141953.3889-1-ville.syrjala@linux.intel.com
Tested-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> #irc

drm/i915: Move skip_intermediate_wm handling into ilk_compute_intermediate_wm()

No point in cluttering the common codepaths with the
skip_intermediate_wm handling. Just move it into
ilk_compute_intermediate_wm() as those are the only
platforms using this.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181108151013.24064-1-ville.syrjala@linux.intel.com
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> #irc

drm/i915: Account for scale factor when calculating initial phase

To get the initial phase correct we need to account for the scale
factor as well. I forgot this initially and was mostly looking at
heavily upscaled content where the minor difference between -0.5
and the proper initial phase was not readily apparent.

And let's toss in a comment that tries to explain the formula
a little bit.

v2: The initial phase upper limit is 1.5, not 24.0!

Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Fixes: 0a59952b24e2 ("drm/i915: Configure SKL+ scaler initial phase correctly")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181029181820.21956-1-ville.syrjala@linux.intel.com
Tested-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
Tested-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> #irc
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> #irc

drm/i915: Always write both TILEOFF and LINOFF plane registers

Reduce the clutter in the sprite update functions by writing
both TILEOFF and LINOFF registers unconditionally. We already
did this for primary planes so might as well do it for the
sprites too.

There is no harm in writing both registers. Which one gets
used depends on the tilimg mode selected in the plane control
registers.

It might even make sense to clear the register that won't
get used. That could make register dumps a little easier to
parse. But I'm not sure it's worth the extra hassle.

Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181108150955.23948-1-ville.syrjala@linux.intel.com
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> #irc

drm/i915: Switch LSPCON to PCON mode if it's in LS mode

We no longer change LSPCON into PCON mode if it boots up in
LS mode. This was broken by some code shuffling in
commit 96e35598cead ("drm/i915: Check LSPCON vendor OUI").

I actually can't see a reason why that code shuffling had
to be done. The commit msg notes it but doesn't justify it
in any way. But I guess we'll keep the code in its current
place anyway and just make the "switch to PCON mode" part
effective once again.

Cc: Shashank Sharma <shashank.sharma@intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Tested-by: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Fixes: 96e35598cead ("drm/i915: Check LSPCON vendor OUI")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181107171821.27862-1-ville.syrjala@linux.intel.com
Reviewed-by: Shashank Sharma <shashank.sharma@intel.com>

drm/i915: fix broadwell EU computation

subslice_mask is an array indexed by slice, not subslice.

Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Fixes: 8cc7669355136f ("drm/i915: store all subslice masks")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108712
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181112123931.2815-1-lionel.g.landwerlin@intel.com

drm/i915: Clean up the baseline bpp computation

Pass on the errno all the way from connected_sink_max_bpp(),
and make the base_bpp handling in intel_modeset_pipe_config()
a bit less ugly. We'll also rename connected_sink_max_bpp()
to not give the impression that it return the bpp value,
and we'll pimp up the debug message within to include the
connector name/id.

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

drm/i915: Remove pointless goto fail

We just 'return ret' immediately after jumping to the label. Let's
return directly instead.

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

drm/i915: Handle -EDEADLK from ironlake_check_fdi_lanes()

ironlake_check_fdi_lanes() may try to grab some extra crtc locks.
If that fails we need to propagate the -EDEADLK all the way up,
and we shouldn't dump out the crtc state or other debug messages
either since it wasn't the crtc state that caused the failure.

Just hit this on my IVB:
[drm:intel_atomic_check [i915]] checking fdi config on pipe C, lanes 3
[drm:intel_atomic_check [i915]] only 2 lanes on pipe C: required 3 lanes
[drm:intel_atomic_check [i915]] fdi link bw constraint, reducing pipe bpp to 18
[drm:intel_atomic_check [i915]] checking fdi config on pipe C, lanes 2
[drm:intel_atomic_check [i915]] CRTC bw constrained, retrying
[drm:intel_dp_compute_config [i915]] DP link computation with max lane count 4 max rate 270000 max bpp 18 pixel clock 185580KHz
[drm:intel_dp_compute_config [i915]] DP lane count 4 clock 162000 bpp 18
[drm:intel_dp_compute_config [i915]] DP link rate required 417555 available 648000
[drm:intel_atomic_check [i915]] checking fdi config on pipe C, lanes 2
WARNING: CPU: 4 PID: 25115 at ../drivers/gpu/drm/drm_modeset_lock.c:241 drm_modeset_lock+0xbc/0xd0 [drm]
...
WARNING: CPU: 4 PID: 25115 at ../drivers/gpu/drm/drm_modeset_lock.c:223 drm_modeset_drop_locks+0x4a/0x50 [drm]

The warnings are from 'WARN_ON(ctx->contended)'.

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

drm/i915/query: fix subslice length

We dump the info as an array of u8, so we want to know the length
in number of bytes. Current code is still safe because the
variable we use BITS_PER_TYPE on is a u8.

Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181109004013.34394-1-daniele.ceraolospurio@intel.com

drm/i915: fix subslice mask array size

We have a subslice mask per slice, not per subslice.
MAX_SUBSLICES > MAX_SLICES, so the wrong size didn't cause any issue
apart from using extra memory.

Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181106182918.5748-1-daniele.ceraolospurio@intel.com

drm/i915/psr: Move intel_psr_disable_source() code to intel_psr_disable_locked()

In the past we had hooks to configure HW for VLV/CHV too, in the drop
of VLV/CHV support the intel_psr_disable_source() code was not moved
to the caller, so doing it here.

Suggested-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181106190843.18009-4-jose.souza@intel.com

drm/i915/icl: Reset PSR interruptions

All other interruptions gen11 interruptions are reset in
gen11_irq_reset() also it is done for other gens that supports PSR.

Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181106190843.18009-3-jose.souza@intel.com

drm/i915/psr: Always wait for idle state when disabling PSR

It should always wait for idle state when disabling PSR because PSR
could be inactive due a call to intel_psr_exit() and while PSR is
still being disabled asynchronously userspace could change the
modeset causing a call to psr_disable() that will not wait for PSR
idle and then PSR will be enabled again while PSR is still not idle.

v2: rebased on top of the patch reusing psr_exit()

Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181106190843.18009-2-jose.souza@intel.com

drm/i915/psr: Use intel_psr_exit() in intel_psr_disable_source()

Both functions have the same code to disable PSR, so let's reuse that
code instead of duplicate.

Suggested-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181106190843.18009-1-jose.souza@intel.com

drm/i915: Generalize skl_ddb_allocation_overlaps()

Make skl_ddb_allocation_overlaps() useful for other callers
besides skl_update_crtcs(). We'll need it to do plane updates
as well.

And while we're here we can reduce the stack utilization a
bit by noting that each struct skl_ddb_entry is 4 bytes whereas
a pointer to one is 8 bytes (on 64bit). So we'll switch to an
array of structs from the array of pointers we used before.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181101150605.18235-9-ville.syrjala@linux.intel.com
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>

drm/i915: Clean up skl+ PLANE_POS vs. scaler handling

On skl+ the scaler (when enabled) will take care of the plane output
position. Make the code less ugly by just setting crtc_x/y to 0
when the scaler is enabled.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181101150605.18235-6-ville.syrjala@linux.intel.com
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>

drm/i915: Polish the skl+ plane keyval/msk/max register setup

Due to the constant alpha we're going to have to program two of
the the tree keying registers anyway, so might as well always
program all three.

And parametrize the plane constant alpha define while at it.

v2: Rebase due to input CSC

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181107184138.31359-1-ville.syrjala@linux.intel.com
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>

drm/i915: Remove the PS_PWR_GATE write from skl_program_scaler()

If we don't need the PS_PWR_GATE write when programming the
pipe scaler I don't see why we'd need it for plane scalers either.
Just remove it.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181101150605.18235-4-ville.syrjala@linux.intel.com
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>

drm/i915/mst: Drop pre_pll_enable null check

MST is only supported in DDI ports that have this hook, so the null
check can be dropped.

Suggested-by: Imre Deak <imre.deak@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181107235449.32264-3-jose.souza@intel.com

drm/i915: Release DDI power well references in MST ports

MST ports did not had the post_pll_disable() hook causing the
references get in pre_pll_enable() never being released causing
DDI and AUX CH being enabled all the times.

v2: renamed intel_mst_post_pll_disable_dp() parameters

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181107235449.32264-2-jose.souza@intel.com

drm/i915: Reuse the aux_domain cached

intel_dp_detect() caches the aux_domain in the beginning of the
function as it is used twice, so lets also use it as the aux_domain
don't change in runtime.

v3: returning intel_dp_retrain_link() error insted of
connector_status_disconnected

Cc: Imre Deak <imre.deak@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181107235449.32264-1-jose.souza@intel.com

drm/i915: Sanitize PCH port transcoder select on IBX

IBX has a documented workaround which states that when we disable the
port we must change its transcoder select to A, otherwise it will
prevent the other port (DP vs. HDMI/SDVO) from using transcoder A.
We implement the workaround during encoder disable, but looks like
some BIOSen leave transcoder B selected even when the port wasn't
actually enabled by the BIOS. That will trip up our asserts
that attempt to make sure we never forget this w/a.

Sanitize the transcoder select to A for all disabled PCH
DP/HDMI/SDVO ports. We assume that the port was never enabled
by the BIOS on transcoder B, because if it had we'd actually have
to toggle the port on and back off to properly switch it back to
transcoder A. That would cause some display flicker if transcoder A
is already enabled on some other port, so it's better not to do it
unless absolutely necessary. Since we have no indication that the
transcoder select is misbehaving on the affected machines we can
assume the port was never actually enabled by the BIOS.

This cures warning like this during driver load:
IBX PCH DP C still using transcoder B
WARNING: CPU: 2 PID: 172 at drivers/gpu/drm/i915/intel_display.c:1279 assert_pch_dp_disabled+0x9e/0xb0 [i915]

v2: Add comments to remind the reader that SDVOB==HDMIB (Chris)

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181108143635.9556-1-ville.syrjala@linux.intel.com
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>

drm/i915: Fix hpd handling for pins with two encoders

In my haste to remove irq_port[] I accidentally changed the
way we deal with hpd pins that are shared by multiple encoders
(DP and HDMI for pre-DDI platforms). Previously we would only
handle such pins via ->hpd_pulse(), but now we queue up the
hotplug work for the HDMI encoder directly. Worse yet, we now
count each hpd twice and this increment the hpd storm count
twice as fast. This can lead to spurious storms being detected.

Go back to the old way of doing things, ie. delegate to
->hpd_pulse() for any pin which has an encoder with that hook
implemented. I don't really like the idea of adding irq_port[]
back so let's loop through the encoders first to check if we
have an encoder with ->hpd_pulse() for the pin, and then go
through all the pins and decided on the correct course of action
based on the earlier findings.

I have occasionally toyed with the idea of unifying the pre-DDI
HDMI and DP encoders into a single encoder as well. Besides the
hotplug processing it would have the other benefit of preventing
userspace from trying to enable both encoders at the same time.
That is simply illegal as they share the same clock/data pins.
We have some testcases that will attempt that and thus fail on
many older machines. But for now let's stick to fixing just the
hotplug code.

Cc: stable@vger.kernel.org # 4.19+
Cc: Lyude Paul <lyude@redhat.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Fixes: b6ca3eee18ba ("drm/i915: Nuke dev_priv->irq_port[]")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181108200424.28371-1-ville.syrjala@linux.intel.com
Reviewed-by: Lyude Paul <lyude@redhat.com>

drm/i915/icl: Fix PLL mapping sanitization for DP ports

We shouldn't consider an encoder inactive if it doesn't have a CRTC
linked, but has virtual MST encoders with a crtc linked. Fix this.

Also we should not sanitize the mapping for MST encoders, as it's always
their primary encoder (which could be even in SST mode) whose active
state determines if we need the clock being enabled for the
corresponding physical port. Fix this too.

This fixes at least an existing breakage where we incorrectly disabled
the clock for an active DP encoder when sanitizing its MST virtual
encoders. Not sure if there are BIOSes that enable an output in MST
mode, but our HW readout is mostly missing for it anyway, so just warn
for that case.

Fixes: 70332ac539c5 ("drm/i915/icl+: Sanitize port to PLL mapping")
Cc: Antonio Argenziano <antonio.argenziano@intel.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: José Roberto de Souza <jose.souza@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reported-by: Antonio Argenziano <antonio.argenziano@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Tested-by: Clint Taylor <Clinton.A.Taylor@intel.com>
Reviewed-by: Clint Taylor <Clinton.A.Taylor@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181107200836.10191-2-imre.deak@intel.com

drm/i915/ddi: Add more sanity check to the encoder HW readout

Check for reserved register field values and conflicting
transcoder->port mappings (both MST and non-MST mappings or multiple SST
mappings).

This is also needed for the next patch to determine if a port is in MST
mode during sanitization after HW readout.

Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: José Roberto de Souza <jose.souza@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Antonio Argenziano <antonio.argenziano@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Clint Taylor <Clinton.A.Taylor@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181107200836.10191-1-imre.deak@intel.com

drm/i915: Track rcu_head for our idle worker

While our little rcu worker might be able to be replaced now by the
dedicated rcu_work, in the meantime we should mark up the rcu_head for
correct debugobjects tracking.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181108092101.27598-2-chris@chris-wilson.co.uk

drm/i915: Initialise the obj->rcu head

Make the rcu_head known to the system, in particular for debugobjects.
And having declared it for debugobjects, we need to tidy up afterwards.

v2: mark the obj->rcu as being destroyed when we reuse its location for
the freed list.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108691
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181109090311.15321-1-chris@chris-wilson.co.uk

drm/i915: Keep overlay functions naming consistent

All other overlay functions(almost all other functions in i915)
follow intel_overlay_verb, so renaming overlay ones that do not match
that.

Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181108001647.11276-4-jose.souza@intel.com

drm/i915: Move intel_init_ipc() call to i915_load_modeset_init()

IPC is a display feature, so i915_load_modeset_init() is the right
place to initialize it.

Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181108001647.11276-3-jose.souza@intel.com

drm/i915: Move FBC init and cleanup calls to modeset functions

Although FBC helps save power it do not belongs to power management
also the cleanup was placed in i915_driver_unload() also not a good
place. intel_modeset_init()/intel_modeset_cleanup() are better places
also this will help make easy disable features that depends in
display being enabled in driver.

Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181108001647.11276-2-jose.souza@intel.com

drm/i915: Move drm_vblank_init() to i915_load_modeset_init()

i915_load_modeset_init() is a more suitable place than
i915_driver_load() as vblank is part of modeset.

Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181108001647.11276-1-jose.souza@intel.com

drm/i915: remove padding from struct skl_wm_level

This reduces the size of struct skl_wm_level from 6 to 4, which
reduces the size of struct skl_plane_wm from 104 to 70, which reduces
the size of struct skl_pipe_wm from 524 to 356. A reduction of 168
padding bytes per pipe. This will increase even more the next time we
bump I915_MAX_PLANES.

v2: Paste the pahole output provided by Lucas:

$ pahole -s -C skl_wm_level drivers/gpu/drm/i915/i915.o
struct skl_wm_level {
        bool                       plane_en;             /*     0     1 */

        /* XXX 1 byte hole, try to pack */

        uint16_t                   plane_res_b;          /*     2     2 */
        uint8_t                    plane_res_l;          /*     4     1 */

        /* size: 6, cachelines: 1, members: 3 */
        /* sum members: 4, holes: 1, sum holes: 1 */
        /* padding: 1 */
        /* last cacheline: 6 bytes */
};

Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181016220133.26991-3-paulo.r.zanoni@intel.com

drm/i915: Set MI_INVALIDATE_BSD for all video-decode engines

We have multiple instances of VCS but only remember to invalidate the
BSD caches on the first, ignoring the stale caches of any other engine.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181108140039.12254-1-chris@chris-wilson.co.uk

drm/i915/icl: Fix port B combo PHY context loss after DC transitions

On ICL DMC/PCODE retains the HW context only for port A across DC
transitions, for the other port B combo PHY, it doesn't. So we need to
do this manually after exiting from DC6. Do the reinit even after
exiting from DC5, it won't hurt since we only reinit the PHY in case
it's needed (in case it was disabled to begin with).

As can be guessed from the bugzilla report leaving the PHY uninited will
lead to a later timeout during the port B specific AUX and DDI_IO power
well enabling.

v2:
- Apply the fix on all GEN>=11 platforms. (Rodrigo)

Bspec: 21257
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108070
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: José Roberto de Souza <jose.souza@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181106160621.23057-6-imre.deak@intel.com

drm/i915/icl: Skip init for an already enabled combo PHY

Bspec says we should skip the initialization of combo PHYs that are
already initialized. We'll need to reinit the PHYs more frequently
when exiting from DC6 (after the next patch), so let's make sure the
uninit sequence complies with the spec. For safety skip the init only if
all the PHY register fields have their expected values.

v2:
- Print 'Port X' as we do elsewhere instead of 'Port-X'. (Jose)

Bspec: 21257
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: José Roberto de Souza <jose.souza@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181106160621.23057-5-imre.deak@intel.com

drm/i915/cnl+: Verify combo PHY HW state during PHY uninit

Verify on CNL, ICL that the combo PHY HW state stayed intact after PHY
initialization.

v2:
- Print 'Port X' as we do elsewhere instead of 'Port-X'. (Jose)

Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: José Roberto de Souza <jose.souza@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181106160621.23057-4-imre.deak@intel.com

drm/i915/cnl+: Move the combo PHY init/uninit code to a new file

Similarly to the GEN9_LP DPIO PHY code keep the CNL+ combo PHY code in a
separate file.

No functional change.

v2:
- Use SPDX license tag instead of boilerplate. (Rodrigo)
v3:
- Use MIT instead of GPL-2.0 license. (Ville)

Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: José Roberto de Souza <jose.souza@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181106160621.23057-3-imre.deak@intel.com

drm/i915/icl: Fix combo PHY uninit

BSpec says to clear the comp init HW flag too during combo PHY uninit,
so do that. The lack of this could badly interact with the PHY reinit
after a DC6/9 transition at least, where (after a follow-up patch fixing
the init code) we'd skip the initialization incorrectly due to this flag
being set.

BSpec: 21257
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: José Roberto de Souza <jose.souza@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181106160621.23057-2-imre.deak@intel.com

drm/i915/execlists: Force write serialisation into context image vs execution

Ensure that the writes into the context image are completed prior to the
register mmio to trigger execution. Although previously we were assured
by the SDM that all writes are flushed before an uncached memory
transaction (our mmio write to submit the context to HW for execution),
we have empirical evidence to believe that this is not actually the
case.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108656
References: https://bugs.freedesktop.org/show_bug.cgi?id=108315
References: https://bugs.freedesktop.org/show_bug.cgi?id=106887
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Acked-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181108081740.25615-1-chris@chris-wilson.co.uk
Cc: stable@vger.kernel.org

drm/i915/icl: Fix power well 2 wrt. DC-off toggling order

To enable DC5/6 power well 2 has to be disabled as for previous
platforms, so fix things up.

Bspec: 4234
Fixes: 67ca07e7ac10 ("drm/i915/icl: Add power well support")
Cc: Animesh Manna <animesh.manna@intel.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181102182200.17219-1-imre.deak@intel.com

drm/i915: Add short HPD IRQ storm detection for non-MST systems

Unfortunately, it seems that the HPD IRQ storm problem from the early
days of Intel GPUs was never entirely solved, only mostly. Within the
last couple of days, I got a bug report from one of our customers who
had been having issues with their machine suddenly booting up very
slowly after having updated. The amount of time it took to boot went
from around 30 seconds, to over 6 minutes consistently.

After some investigation, I discovered that i915 was reporting massive
amounts of short HPD IRQ spam on this system from the DisplayPort port,
despite there not being anything actually connected. The symptoms would
start with one "long" HPD IRQ being detected at boot:

[    1.891398] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat 0x00440000, dig 0x00440000, pins 0x000000a0
[    1.891436] [drm:intel_hpd_irq_handler [i915]] digital hpd port B - long
[    1.891472] [drm:intel_hpd_irq_handler [i915]] Received HPD interrupt on PIN 5 - cnt: 0
[    1.891508] [drm:intel_hpd_irq_handler [i915]] digital hpd port D - long
[    1.891544] [drm:intel_hpd_irq_handler [i915]] Received HPD interrupt on PIN 7 - cnt: 0
[    1.891592] [drm:intel_dp_hpd_pulse [i915]] got hpd irq on port B - long
[    1.891628] [drm:intel_dp_hpd_pulse [i915]] got hpd irq on port D - long
…

followed by constant short IRQs afterwards:

[    1.895091] [drm:intel_encoder_hotplug [i915]] [CONNECTOR:66:DP-1] status updated from unknown to disconnected
[    1.895129] [drm:i915_hotplug_work_func [i915]] Connector DP-3 (pin 7) received hotplug event.
[    1.895165] [drm:intel_dp_detect [i915]] [CONNECTOR:72:DP-3]
[    1.895275] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat 0x00200000, dig 0x00200000, pins 0x00000080
[    1.895312] [drm:intel_hpd_irq_handler [i915]] digital hpd port D - short
[    1.895762] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat 0x00200000, dig 0x00200000, pins 0x00000080
[    1.895799] [drm:intel_hpd_irq_handler [i915]] digital hpd port D - short
[    1.896239] [drm:intel_dp_aux_xfer [i915]] dp_aux_ch timeout status 0x71450085
[    1.896293] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat 0x00200000, dig 0x00200000, pins 0x00000080
[    1.896330] [drm:intel_hpd_irq_handler [i915]] digital hpd port D - short
[    1.896781] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat 0x00200000, dig 0x00200000, pins 0x00000080
[    1.896817] [drm:intel_hpd_irq_handler [i915]] digital hpd port D - short
[    1.897275] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat 0x00200000, dig 0x00200000, pins 0x00000080

The customer's system in question has a GM45 GPU, which is apparently
well known for hotplugging storms.

So, workaround this impressively broken hardware by changing the default
HPD storm threshold from 5 to 50. Then, make long IRQs count for 10, and
short IRQs count for 1. This makes it so that 5 long IRQs will trigger
an HPD storm, and on systems with short HPD storm detection 50 short
IRQs will trigger an HPD storm. 50 short IRQs amounts to 100ms of
constant pulsing, which seems like a good middleground between being too
sensitive and not being sensitive enough (which would cause visible
stutters in userspace every time a storm occurs).

And just to be extra safe: we don't enable this by default on systems
with MST support. There's too high of a chance of MST support triggering
storm detection, and systems that are new enough to support MST are a
lot less likely to have issues with IRQ storms anyway.

As a note: this patch was tested using a ThinkPad T450s and a Chamelium
to simulate the short IRQ storms.

Changes since v1:
- Don't use two separate thresholds, just make long IRQs count for 10
  each and short IRQs count for 1. This simplifies the code a bit
  - Ville Syrjälä
Changes since v2:
- Document @long_hpd in intel_hpd_irq_storm_detect, no functional
  changes
Changes since v4:
- Remove !! in long_hpd assignment - Ville Syrjälä
- queue_hp = true - Ville Syrjälä

Signed-off-by: Lyude Paul <lyude@redhat.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181106213017.14563-6-lyude@redhat.com

drm/i915: Clarify flow for disabling IRQs on storms

This is rather confusing to look at as-is:
dev_priv->display.hpd_irq_setup(dev_priv); in intel_hpd_irq_handler()
handles disabling the actual HPD IRQ, while
intel_hpd_irq_storm_disable() handles moving the HPD pin state over from
MARK_DISABLED to DISABLED along with enabling polling for it.

Changes since v3:
- Rename i915_hpd_irq_storm_disable() to
  i915_hpd_irq_storm_switch_to_polling() - Rodrigo Vivi

Signed-off-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181106213017.14563-5-lyude@redhat.com

drm/i915: Fix threshold check in intel_hpd_irq_storm_detect()

Currently in intel_hpd_irq_storm_detect() when we detect that the last
recorded hotplug wasn't within the period defined by
HPD_STORM_DETECT_DELAY, we make the mistake of resetting the HPD count
to 0 without incrementing it. This results in us only enabling storm
detection when we go +2 above the threshold, e.g. an HPD threshold of 5
would not trigger a storm until we reach a total of 7 hotplugs.

So: rework the code a bit so we reset the HPD count when
HPD_STORM_DETECT_DELAY has passed, then increment the count afterwards.
Also, clean things up a bit to make it easier to undertand.

Signed-off-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181106213017.14563-4-lyude@redhat.com

drm/i915: Fix NULL deref when re-enabling HPD IRQs on systems with MST

Turns out that if you trigger an HPD storm on a system that has an MST
topology connected to it, you'll end up causing the kernel to eventually
hit a NULL deref:

[  332.339041] BUG: unable to handle kernel NULL pointer dereference at 00000000000000ec
[  332.340906] PGD 0 P4D 0
[  332.342750] Oops: 0000 [#1] SMP PTI
[  332.344579] CPU: 2 PID: 25 Comm: kworker/2:0 Kdump: loaded Tainted: G           O      4.18.0-rc3short-hpd-storm+ #2
[  332.346453] Hardware name: LENOVO 20BWS1KY00/20BWS1KY00, BIOS JBET71WW (1.35 ) 09/14/2018
[  332.348361] Workqueue: events intel_hpd_irq_storm_reenable_work [i915]
[  332.350301] RIP: 0010:intel_hpd_irq_storm_reenable_work.cold.3+0x2f/0x86 [i915]
[  332.352213] Code: 00 00 ba e8 00 00 00 48 c7 c6 c0 aa 5f a0 48 c7 c7 d0 73 62 a0 4c 89 c1 4c 89 04 24 e8 7f f5 af e0 4c 8b 04 24 44 89 f8 29 e8 <41> 39 80 ec 00 00 00 0f 85 43 13 fc ff 41 0f b6 86 b8 04 00 00 41
[  332.354286] RSP: 0018:ffffc90000147e48 EFLAGS: 00010006
[  332.356344] RAX: 0000000000000005 RBX: ffff8802c226c9d4 RCX: 0000000000000006
[  332.358404] RDX: 0000000000000000 RSI: 0000000000000082 RDI: ffff88032dc95570
[  332.360466] RBP: 0000000000000005 R08: 0000000000000000 R09: ffff88031b3dc840
[  332.362528] R10: 0000000000000000 R11: 000000031a069602 R12: ffff8802c226ca20
[  332.364575] R13: ffff8802c2268000 R14: ffff880310661000 R15: 000000000000000a
[  332.366615] FS:  0000000000000000(0000) GS:ffff88032dc80000(0000) knlGS:0000000000000000
[  332.368658] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  332.370690] CR2: 00000000000000ec CR3: 000000000200a003 CR4: 00000000003606e0
[  332.372724] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[  332.374773] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[  332.376798] Call Trace:
[  332.378809]  process_one_work+0x1a1/0x350
[  332.380806]  worker_thread+0x30/0x380
[  332.382777]  ? wq_update_unbound_numa+0x10/0x10
[  332.384772]  kthread+0x112/0x130
[  332.386740]  ? kthread_create_worker_on_cpu+0x70/0x70
[  332.388706]  ret_from_fork+0x35/0x40
[  332.390651] Modules linked in: i915(O) vfat fat joydev btusb btrtl btbcm btintel bluetooth ecdh_generic iTCO_wdt wmi_bmof i2c_algo_bit drm_kms_helper intel_rapl syscopyarea sysfillrect x86_pkg_temp_thermal sysimgblt coretemp fb_sys_fops crc32_pclmul drm psmouse pcspkr mei_me mei i2c_i801 lpc_ich mfd_core i2c_core tpm_tis tpm_tis_core thinkpad_acpi wmi tpm rfkill video crc32c_intel serio_raw ehci_pci xhci_pci ehci_hcd xhci_hcd [last unloaded: i915]
[  332.394963] CR2: 00000000000000ec

This appears to be due to the fact that with an MST topology, not all
intel_connector structs will have ->encoder set. So, fix this by
skipping connectors without encoders in
intel_hpd_irq_storm_reenable_work().

For those wondering, this bug was found on accident while simulating HPD
storms using a Chamelium connected to a ThinkPad T450s (Broadwell).

Changes since v1:
- Check intel_connector->mst_port instead of intel_connector->encoder

Signed-off-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: stable@vger.kernel.org
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181106213017.14563-3-lyude@redhat.com

drm/i915: Fix possible race in intel_dp_add_mst_connector()

This hasn't caused any issues yet that I'm aware of, but as Ville
Syrjälä pointed out - we need to make sure that
intel_connector->mst_port is set before initializing MST connectors,
since in theory we could potentially check intel_connector->mst_port in
i915_hpd_poll_init_work() after registering the connector but before
having written it's value.

Signed-off-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: stable@vger.kernel.org
Link: https://patchwork.freedesktop.org/patch/msgid/20181106213017.14563-2-lyude@redhat.com

drm/i915: Clean up skl_program_scaler()

Remove the "sizes are 0 based" stuff that is not even true for the
scaler.

v2: Rebase

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181101151736.20522-1-ville.syrjala@linux.intel.com
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>

drm/i915: Nuke posting reads from plane update/disable funcs

No need for the posting reads in the plane update/disable hooks.
If we need a posting read for something then a single one at the
very end would be sufficient. We have that anyway in the form
of eg. scanline/frame counter reads.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181101150605.18235-2-ville.syrjala@linux.intel.com
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>

drm/i915/csr: fix spelling mistake "firmare" -> "firmware"

Trivial fix to spelling mistake in DRM_INFO message

Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20181107102211.19758-1-colin.king@canonical.com

drm/i915/ringbuffer: Delay after EMIT_INVALIDATE for gen4/gen5

Exercising the gpu reloc path strenuously revealed an issue where the
updated relocations (from MI_STORE_DWORD_IMM) were not being observed
upon execution. After some experiments with adding pipecontrols (a lot
of pipecontrols (32) as gen4/5 do not have a bit to wait on earlier pipe
controls or even the current on), it was discovered that we merely
needed to delay the EMIT_INVALIDATE by several flushes. It is important
to note that it is the EMIT_INVALIDATE as opposed to the EMIT_FLUSH that
needs the delay as opposed to what one might first expect -- that the
delay is required for the TLB invalidation to take effect (one presumes
to purge any CS buffers) as opposed to a delay after flushing to ensure
the writes have landed before triggering invalidation.

Testcase: igt/gem_tiled_fence_blits
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@vger.kernel.org
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181105094305.5767-1-chris@chris-wilson.co.uk

mm, drm/i915: mark pinned shmemfs pages as unevictable

The i915 driver uses shmemfs to allocate backing storage for gem
objects. These shmemfs pages can be pinned (increased ref count) by
shmem_read_mapping_page_gfp(). When a lot of pages are pinned, vmscan
wastes a lot of time scanning these pinned pages. In some extreme case,
all pages in the inactive anon lru are pinned, and only the inactive
anon lru is scanned due to inactive_ratio, the system cannot swap and
invokes the oom-killer. Mark these pinned pages as unevictable to speed
up vmscan.

Export pagevec API check_move_unevictable_pages().

This patch was inspired by Chris Wilson's change [1].

[1]: https://patchwork.kernel.org/patch/9768741/

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Dave Hansen <dave.hansen@intel.com>
Signed-off-by: Kuo-Hsin Yang <vovoy@chromium.org>
Acked-by: Michal Hocko <mhocko@suse.com> # mm part
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Dave Hansen <dave.hansen@intel.com>
Acked-by: Andrew Morton <akpm@linux-foundation.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20181106132324.17390-1-chris@chris-wilson.co.uk
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

drm/i915: Don't oops during modeset shutdown after lpe audio deinit

We deinit the lpe audio device before we call
drm_atomic_helper_shutdown(), which means the platform device
may already be gone when it comes time to shut down the crtc.
As we don't know when the last reference to the platform
device gets dropped by the audio driver we can't assume that
the device and its data are still around when turning off the
crtc. Mark the platform device as gone as soon as we do the
audio deinit.

Cc: stable@vger.kernel.org
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181105194604.6994-1-ville.syrjala@linux.intel.com
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>

drm/i915: Break long iterations for get/put shmemfs pages

As we may have to iterate a few thousand elements to acquire and release
the shmemfs backing storage for a GPU object, we need to break up the
long loop with cond_resched() to retain a modicum of low latency for
other processes.

Testcase: igt/benchmarks/gem_syslatency
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Kuo-Hsin Yang <vovoy@chromium.org>
Cc: Matthew Auld <matthew.auld@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181105170640.26905-1-chris@chris-wilson.co.uk

drm/i915/icl: Enable Plane Input CSC for YUV to RGB Conversion

Plane input CSC needs to be enabled to convert frambuffers from
YUV to RGB. This is needed for bottom 3 planes on ICL, rest of
the planes have hardcoded conversion and taken care by the legacy
code.

This patch defines the co-efficient values for YUV to RGB conversion
in BT709 and BT601 formats. It programs the coefficients and enables
the plane input csc unit in hardware.

This has been verified and tested by Maarten and the change is working
as expecpted.

v2: Addressed Maarten's and Ville's review comments and added the
coefficients in a 2D array instead of independent Macros.

v3: Added individual coefficient matrix (9 values) instead of 6
register values as per Maarten's comment. Also addresed a shift
issue with B channel coefficient.

v4: Added support for Limited Range Color Handling

v5: Fixed Matt and Maarten's review comments.

v6: Added human readable matrix values for YUV to RGB Conversion along
with just the bspec register values, as per Matt's suggestion.

v7: Refactored the code, move csc coefficient programming function to
intel_sprite.c and made it static as per Ville's review comment.

v8: Addressed Ville's review comment. Called the coefficient programming
from within the skl_program_plane and used I915_WRITE_FW instead of
I915_WRITE.

v9: Fixed Ville's review comments.

Signed-off-by: Uma Shankar <uma.shankar@intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1541099420-12419-3-git-send-email-uma.shankar@intel.com

drm/i915/icl: Define Plane Input CSC Coefficient Registers

Defined the plane input csc coefficient registers and macros.
6 registers are used to program a total of 9 coefficients,
added macros to define each of them for all the planes
supporting the feature on pipes. On ICL, bottom 3 planes
have this capability.

v2: Segregated the register macro definition as separate patch
as per Maarten's suggestion.

v3: Removed a redundant 3rd Pipe register definition and
simplified the equally spaced register definition by adding an
offset as per Matt's comment.

v4: No Change

v5: Renamed the register Macro as per Matt's suggestion.

v6: No Change

v7: No Change

v8: No Change

v9: No Change

Signed-off-by: Uma Shankar <uma.shankar@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1541099420-12419-2-git-send-email-uma.shankar@intel.com

drm/i915: Fix ilk+ watermarks when disabling pipes

We're no longer programming any watermarks when we're disabling
a pipe. That means ilk_wm_merge() & co. will keep considering
the any pipe that is getting disabled as still enabled. Thus we
either get no LP1+ watermakrs (ilk-ivb), or we get suboptimal
ones (hsw-bdw).

This seems to have been broken by commit b6b178a77210 ("drm/i915:
Calculate ironlake intermediate watermarks correctly, v2."). Before
that we apparently had some difference between the intermediate
and optimal watermarks and so we would program the optiomal ones.
Now intermediate and optimal are identical for disabled pipes
and so we don't program either.

Fix this by programming the intermediate watermarks even for
disabled pipes. We were already doing that for skl+. We'll
leave out gmch platforms for now since those do the merging
in a different manner and should work as is. We'll want to
unify this eventually, but play it safe for now and just put
in a FIXME.

Cc: stable@vger.kernel.org
Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Fixes: b6b178a77210 ("drm/i915: Calculate ironlake intermediate watermarks correctly, v2.")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181025130536.29024-1-ville.syrjala@linux.intel.com
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> #irc

drm/i915/gen9_lp: Fix DMC DC counter debugfs output

On GEN9 LP (BXT/GLK) DC6 is not supported, so don't print the counter
on those platforms. So far we did this on GLK too.

While at it warn if we forgot to adjust the printout properly for a
new platform. (Rodrigo)

Testcase: igt/pm_dc/dc6-dpms
Cc: Jyoti Yadav <jyoti.r.yadav@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181031200220.11608-1-imre.deak@intel.com

drm/i915/icl: Configure MG DP mode for HDMI ports too

The MG DP mode needs to be configured for Type C static/fixed/legacy
HDMI ports too, the same way as it's configured for Type C
static/fixed/legacy, fix this.

Bspec: 4232, 21735
Cc: Vandita Kulkarni <vandita.kulkarni@intel.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Tested-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181102192656.4472-3-imre.deak@intel.com

drm/i915/icl: Configure MG PHY gating for HDMI ports too

The MG PHY clock gating needs to be configured for Type C
static/fixed/legacy HDMI ports the same way it's configured for Type C
static/fixed/legacy and aternate mode DP ports, fix this.

Bspec: 4232, 21735
Cc: Vandita Kulkarni <vandita.kulkarni@intel.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Tested-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181102192656.4472-2-imre.deak@intel.com

drm/dp/fec: DRM helper for Forward Error Correction

DP 1.4 has Forward Error Correction Support(FEC).
Add helper function to check if the sink device
supports FEC.

v2: Separate the helper and the code that uses the helper into
two separate patches. (Manasi)

v3:
- Move the code to drm_dp_helper.c (Manasi)
- change the return type, code style changes (Gaurav)
- Use drm_dp_dpcd_readb instead of drm_dp_dpcd_read. (Jani)

v4:
- Avoid aux reads everytime, instead read cached
values of dpcd register (jani)
- Move helper to drm_dp_helper.h like other dsc
helpers.(Anusha)

v5: rebased. Change the helper parameter suitably.

Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Manasi Navare <manasi.d.navare@intel.com>
Acked-by: Sean Paul <seanpaul@chromium.org> (For merging through
drm-intel)
Signed-off-by: Anusha Srivatsa <anusha.srivatsa@intel.com>
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181102041455.15818-2-anusha.srivatsa@intel.com

i915/dp/fec: Cache the FEC_CAPABLE DPCD register

Similar to DSC DPCD registers, let us cache
FEC_CAPABLE register to avoid using stale
values. With this we can avoid aux reads
everytime and instead read the cached values.

v2: Avoid using memset and array for a single
field. (Manasi,Jani)

v3: Print FEC CAPABILITY value. (Manasi)

Suggested-by: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: Anusha Srivatsa <anusha.srivatsa@intel.com>
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181102041455.15818-1-anusha.srivatsa@intel.com

drm/i915: Mark pin flags as u64

Since the flags are being used to operate on a u64 variable, they too
need to be marked as such so that the inverses are full width (and not
zero extended on 32b kernels and bdw+).

Reported-by: Sergii Romantsov <sergii.romantsov@globallogic.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@vger.kernel.org
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181102161232.17742-2-chris@chris-wilson.co.uk

drm/i915/fia: FIA registers offset implementation.

The registers DPCSSS,DPSP,DPMLE1 and DPPMS are all at an offset
from the base - which is the FLexi IO Adaptor. Lets follow the
offset calculation while accessing these registers.

v2:
- Follow spec for numbering - s/0/1(Lucas)
- s/FIA_1/FIA1_BASE (Anusha)

v3:
- Remove register offset defines. (Jani)
- Update comment. (Anusha)

v4: rebase. Remove comment.(Lucas)

Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Anusha Srivatsa <anusha.srivatsa@intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181101185557.29585-1-anusha.srivatsa@intel.com

ALSA: x86: Rip out the lpe audio runtime suspend/resume hooks

Ever since commit 46e831abe864 ("drm/i915/lpe: Mark LPE audio runtime
pm as "no callbacks"") the runtime suspend/resume hooks are no longer
used. Inline them into the system suspend hooks.

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Takashi Iwai <tiwai@suse.de>
Cc: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181024154825.18185-2-ville.syrjala@linux.intel.com
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Takashi Iwai <tiwai@suse.de>

ALSA: x86: Fix runtime PM for hdmi-lpe-audio

Commit 46e831abe864 ("drm/i915/lpe: Mark LPE audio runtime pm as
"no callbacks"") broke runtime PM with lpe audio. We can no longer
runtime suspend the GPU since the sysfs  power/control for the
lpe-audio device no longer exists and the device is considered
always active. We can fix this by not marking the device as
active.

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Takashi Iwai <tiwai@suse.de>
Cc: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Fixes: 46e831abe864 ("drm/i915/lpe: Mark LPE audio runtime pm as "no callbacks"")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181024154825.18185-1-ville.syrjala@linux.intel.com
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Takashi Iwai <tiwai@suse.de>

drm/i915: Allow "max bpc" property to limit pipe_bpp

Use the newly added "max bpc" connector property to limit pipe bpp.

V3: Use drm_connector_state to access the "max bpc" property
V4: Initialize the drm property, add suuport to DP(Ville)
V5: Use the property in the connector and fix CI failure(Ville)
V6: Use the core function to attach max_bpc property, remove the redundant
    clamping of pipe bpp based on connector info
V7: Fix Checkpatch warnings
V9: Cleanup connected_sink_max_bpp and fix initial value in DP(Ville)
V12: Fix debug message(Ville)
V13: Remove the redundant check and simplify the check logic(Stan)
V14: Fix the check in connected_sink_max_bpp(Stan)
v15 (From Manasi): Add missing break (Stan)

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Kishore Kadiyala <kishore.kadiyala@intel.com>
Cc: Manasi Navare <manasi.d.navare@intel.com>
Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181023014400.16055-1-manasi.d.navare@intel.com

drm: Add connector property to limit max bpc

At times 12bpc HDMI cannot be driven due to faulty cables, dongles
level shifters etc. To workaround them we may need to drive the output
at a lower bpc. Currently the user space does not have a way to limit
the bpc. The default bpc to be programmed is decided by the driver and
is run against connector limitations.

Creating a new connector property "max bpc" in order to limit the bpc.
xrandr can make use of this connector property to make sure that bpc does
not exceed the configured value. This property can be used by userspace to
set the bpc.

V2: Initialize max_bpc to satisfy kms_properties
V3: Move the property to drm_connector
V4: Split drm and i915 components(Ville)
V5: Make the property per connector(Ville)
V6: Compare the requested bpc to connector bpc(Daniel)
    Move the attach_property function to core(Ville)
V7: Fix checkpatch warnings
V8: Simplify the connector check code(Ville)
V9: Const display_info(Ville)
V10,V11: Fix CI issues.
V12: Add the Kernel documentation(Daniel)
V14: Crossreference the function name in the doc(Daniel)

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Kishore Kadiyala <kishore.kadiyala@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Manasi Navare <manasi.d.navare@intel.com>
Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Cc: Sunpeng Li <sunpeng.li@amd.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@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/20181012184233.29250-1-radhakrishna.sripada@intel.com

drm/i915: Update DRIVER_DATE to 20181102

Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: also group device info array helper macros with others

Keep the register choosing macros together. No functional changes.

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

drm/i915: reorder and reindent the register choosing helper wrappers

Try to make it slightly less of an eye sore. No functional changes.

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

drm/i915: define _MMIO_PLANE() in terms of _PLANE() not _MMIO_PIPE()

Minor semantic nit, no functional changes.

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

drm/i915: remove palette_offsets from device info in favor of _PICK()

The device info offset arrays for unevenly spaced register offsets is
great for widely used registers. However, the palette registers are only
used in one function, i9xx_load_luts_internal(), and only for GMCH
platforms, wasting device info. Replace palette_offsets with _PICK() in
palette register definition.

While the use of _PICK() does not check for pipe C existence, neither
does the current offset array usage, and leads to bogus address when
pipe C is passed to PALETTE() on non-CHV. Using _PICK() at least leads
to a sensible register offset, just non-existing on non-CHV. Either way,
this shouldn't happen anyway.

Remove unused old palette macros while at it.

Bloat-o-meter results below for completeness.

add/remove: 0/0 grow/shrink: 3/6 up/down: 94/-278 (-184)
Function                                     old     new   delta
i9xx_load_luts_internal                      394     483     +89
i915_driver_load                            5103    5107      +4
g4x_pre_enable_dp                            378     379      +1
intel_engines_init_mmio                     1117    1116      -1
intel_engine_lookup_user                      47      46      -1
hdmi_port_clock_valid                        310     309      -1
gen11_irq_handler                            707     706      -1
intel_device_info_dump_runtime               329     311     -18
intel_device_info_runtime_init              5166    4910    -256
Total: Before=918650, After=918466, chg -0.02%

add/remove: 0/0 grow/shrink: 0/48 up/down: 0/-576 (-576)
Data                                         old     new   delta
intel_valleyview_info                        200     188     -12
intel_skylake_gt4_info                       200     188     -12
intel_skylake_gt3_info                       200     188     -12
intel_skylake_gt2_info                       200     188     -12
intel_skylake_gt1_info                       200     188     -12
intel_sandybridge_m_gt2_info                 200     188     -12
intel_sandybridge_m_gt1_info                 200     188     -12
intel_sandybridge_d_gt2_info                 200     188     -12
intel_sandybridge_d_gt1_info                 200     188     -12
intel_pineview_info                          200     188     -12
intel_kabylake_gt3_info                      200     188     -12
intel_kabylake_gt2_info                      200     188     -12
intel_kabylake_gt1_info                      200     188     -12
intel_ivybridge_q_info                       200     188     -12
intel_ivybridge_m_gt2_info                   200     188     -12
intel_ivybridge_m_gt1_info                   200     188     -12
intel_ivybridge_d_gt2_info                   200     188     -12
intel_ivybridge_d_gt1_info                   200     188     -12
intel_ironlake_m_info                        200     188     -12
intel_ironlake_d_info                        200     188     -12
intel_icelake_11_info                        200     188     -12
intel_i965gm_info                            200     188     -12
intel_i965g_info                             200     188     -12
intel_i945gm_info                            200     188     -12
intel_i945g_info                             200     188     -12
intel_i915gm_info                            200     188     -12
intel_i915g_info                             200     188     -12
intel_i865g_info                             200     188     -12
intel_i85x_info                              200     188     -12
intel_i845g_info                             200     188     -12
intel_i830_info                              200     188     -12
intel_haswell_gt3_info                       200     188     -12
intel_haswell_gt2_info                       200     188     -12
intel_haswell_gt1_info                       200     188     -12
intel_gm45_info                              200     188     -12
intel_geminilake_info                        200     188     -12
intel_g45_info                               200     188     -12
intel_g33_info                               200     188     -12
intel_coffeelake_gt3_info                    200     188     -12
intel_coffeelake_gt2_info                    200     188     -12
intel_coffeelake_gt1_info                    200     188     -12
intel_cherryview_info                        200     188     -12
intel_cannonlake_info                        200     188     -12
intel_broxton_info                           200     188     -12
intel_broadwell_rsvd_info                    200     188     -12
intel_broadwell_gt3_info                     200     188     -12
intel_broadwell_gt2_info                     200     188     -12
intel_broadwell_gt1_info                     200     188     -12
Total: Before=195529, After=194953, chg -0.29%

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

Merge drm/drm-next into drm-intel-next-queued

Although there's nothing crucial missing, it's been a long time since
the last backmerge. Catch up with drm-next.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>

Merge tag 'drm-intel-next-fixes-2018-10-25' of git://anongit.freedesktop.org/drm/drm-intel into drm-next

- Fix to avoid link retraining workaround on eDP (the other is a comment change)

Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181025131836.GA2296@jlahtine-desk.ger.corp.intel.com

drm/i915/icl: Fix DSS_CTL register names

This patch fixes the naming of the registers:

s/PIPE_DSS_CTL/ICL_PIPE_DSS_CTL

And also fix the hex values to lower case, to match
rest of the definitions.

Manasi noticed this with the patch that was merged.

v2: fix "Fixes" tag.

Fixes: 8b1b558d690a ("drm/i915/icl: Add DSS_CTL Registers")
Suggested-by: Manasi Navare <manasi.d.navare@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: Anusha Srivatsa <anusha.srivatsa@intel.com>
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181101214216.8958-1-anusha.srivatsa@intel.com

Merge branch 'drm-next-4.20' of git://people.freedesktop.org/~agd5f/linux into drm-next

- Fix flickering at low backlight levels on some systems
- Fix some overclocking regressions
- Vega20 updates for
- GPU recovery fixes
- Disable gfxoff on RV as some sbios/fw combinations are not stable yet

Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Alex Deucher <alexdeucher@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181101151939.2828-1-alexander.deucher@amd.com

Merge tag 'drm-misc-next-fixes-2018-10-31' of git://anongit.freedesktop.org/drm/drm-misc into drm-next

- Properly label Innolux TV123WAM as P120ZDG-BF1 (Doug)
- Add optional delay for panels without hpd hooked up (which solves the
  mystery delay for TI SN65DSI86 bridge) (Doug)
- Another 6bpc quirk for BOE panel 0x0771 (Shawn)

Cc: Doug Anderson <dianders@chromium.org>
Cc: Lee, Shawn C <shawn.c.lee@intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Sean Paul <sean@poorly.run>
Link: https://patchwork.freedesktop.org/patch/msgid/20181031201944.GA262020@art_vandelay

drm/i915/icl+: Sanitize port to PLL mapping

BIOS can leave the PLL to port mapping enabled, even if the
corresponding encoder is disabled. Disable the port mapping in this
case.

Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: José Roberto de Souza <jose.souza@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181101140427.31026-9-imre.deak@intel.com

drm/i915: Configure AUX_CH_CTL when enabling the AUX power domain

Most of the AUX_CH_CTL flags are concerned with DP AUX transfer
parameters. As opposed to this the flag specifying the thunderbolt vs.
non-thunderbolt mode of the port is not related to AUX transfers at all
(rather it's repurposed to enable either TBT or non-TBT PHY HW blocks).
The programming has to be done before enabling the corresponding AUX
power well, so make it part of the power well code.

v3:
- Use existing enable/disable helpers instead of opencoding. (Jose)
- Fix type of is_tc_tbt to remain a bitfield. (Lucas)
- Add comment describing the is_tc_tbt power well flag. (Lucas)

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108548
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: José Roberto de Souza <jose.souza@intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181101140427.31026-8-imre.deak@intel.com

drm/i915: Enable AUX power for HDMI DDI/TypeC main link too

DDI/TypeC ports need the AUX power domain for main link functionality
even when they operate in HDMI static mode, so enable the power domain
for these ports too.

v4:
- Rebase on the upstream ICL pre_pll_enable change.

Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: José Roberto de Souza <jose.souza@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181101140427.31026-7-imre.deak@intel.com

drm/i915: Enable AUX power earlier

For DDI/TypeC ports the AUX power domain needs to be enabled before the
port's PLL is enabled, so move the enabling earlier accordingly.

v2:
- Preserve the pre_pll hook for GEN9_LP. (Ville)
v3:
- Add related BSpec entries to commit log. (Jose)
v4:
- Rebase on the upstream ICL pre_pll_enable change.

BSpec: 21750, 22243
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: José Roberto de Souza <jose.souza@intel.com>
Cc: Manasi Navare <manasi.d.navare@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181101140427.31026-6-imre.deak@intel.com

drm/i915: Use a helper to get the aux power domain

From ICL onwards the AUX power domain may change dynamically based on
whether a DDI/TypeC port is in thunderbolt or non-thunderbolt mode, so
use a helper function instead of a static field to get the current
domain.

Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: José Roberto de Souza <jose.souza@intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181101140427.31026-5-imre.deak@intel.com

drm/i915: Init aux_ch for HDMI ports too

From ICL onwards DDI/TypeC ports - even in HDMI static mode - need to know
which AUX CH belongs to them, so initialize aux_ch for those ports too.
For consistency do this for all HDMI ports, not only for DDI/TypeC ones.

Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: José Roberto de Souza <jose.souza@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181101140427.31026-4-imre.deak@intel.com

drm/i915: Move aux_ch to intel_digital_port

From ICL onwards all DDI/TypeC ports - even working in HDMI mode - need
to know their corresponding AUX CH, so move the field to a common
struct.

No functional change.

v3:
- Add code comment about which ports aux_ch is used for. (Jose)

Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: José Roberto de Souza <jose.souza@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181101140427.31026-3-imre.deak@intel.com

drm/i915: Move intel_aux_ch() to intel_bios.c

From ICL onwards all the DDI/TypeC ports - even working in HDMI mode -
need to know their corresponding AUX channel, so move the corresponding
helper to a common place.

No functional change.

v4:
- Fix 'no space is necessary after a cast' checkpatch warn.

Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: José Roberto de Souza <jose.souza@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181101140427.31026-2-imre.deak@intel.com