The shifts for VSC_SELECT bits are wrong, fix it. Good thing is the
definitions are unused.

v2: Moves definitions in another patch (Manasi)
Cc: Manasi Navare <manasi.d.navare@intel.com>
Cc: Anusha Srivatsa <anusha.srivatsa@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Fixes: 7af2be6d ("drm/i915/icl: Add VIDEO_DIP registers")
Signed-off-by: NDhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Reviewed-by: NManasi Navare <manasi.d.navare@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181005185643.31660-1-dhinakaran.pandiyan@intel.com
(cherry picked from commit 09209662)
Signed-off-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>

DDI/TC clock-off bits are not equally distanced. TC1-3 bits are
from offset 12 & TC4 is at offset 21.
Create a function to choose correct clk-off bit.

v2: Add fixes tag (Lucas)

Fixes: c27e917e ("drm/i915/icl: add basic support for the ICL clocks")
Signed-off-by: NMahesh Kumar <mahesh1.kumar@intel.com>
Signed-off-by: NVandita Kulkarni <vandita.kulkarni@intel.com>
Reviewed-by: NLucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181016023752.9285-1-lucas.demarchi@intel.com
(cherry picked from commit bb1c7edc)
Signed-off-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>

This patch adds support to decode system memory bandwidth and other
parameters for skylake and Gen9+ platforms, which will be used for
arbitrated display memory bandwidth calculation in GEN9 based
platforms and WM latency level-0 Work-around calculation on GEN9+.

Changes Since V1:
 - s/memdev_info/dram_info
 - create a struct to hold channel info
Changes Since V2:
 - rewrite code to adhere i915 coding style
 - not valid for GLK
Signed-off-by: NMahesh Kumar <mahesh1.kumar@intel.com>
Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180824093225.12598-3-mahesh1.kumar@intel.com

This patch adds support to decode system memory bandwidth and other
parameters for broxton platform, which will be used for arbitrated
display memory bandwidth calculation in GEN9 based platforms and
WM latency level-0 Work-around calculation on GEN9+ platforms.

Changes since V1:
 - s/memdev_info/dram_info
Changes since V2:
 - Adhere to i915 coding style (Rodrigo)
Signed-off-by: NMahesh Kumar <mahesh1.kumar@intel.com>
Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180824093225.12598-2-mahesh1.kumar@intel.com

This patch defines DSI_T_INIT_MASTER register for DSI ports
0/1 which will be used in dphy programming.
Signed-off-by: NMadhav Chauhan <madhav.chauhan@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1531215614-6828-5-git-send-email-madhav.chauhan@intel.com

There are two issues with the current RPCS programming for Icelake:

Expansion of the slice count bitfield has been missed, as well as the
required programming workaround for the subslice count bitfield size
limitation.

1)

Bitfield width for configuring the active slice count has grown so we need
to program the GEN8_R_PWR_CLK_STATE accordingly.

Current code was always requesting eight times the number of slices (due
writing to a bitfield starting three bits higher than it should). These
requests were luckily a) capped by the hardware to the available number of
slices, and b) we haven't yet exported the code to ask for reduced slice
configurations.

Due both of the above there was no impact from this incorrect programming
but we should still fix it.

2)

Due subslice count bitfield being only three bits wide and furthermore
capped to a maximum documented value of four, special programming
workaround is needed to enable more than four subslices.

With this programming driver has to consider the GT configuration as
2x4x8, while the hardware internally translates this to 1x8x8.

A limitation stemming from this is that either a subslice count between
one and four can be selected, or a subslice count equaling the total
number of subslices in all selected slices. In other words, odd subslice
counts greater than four are impossible, as are odd subslice counts
greater than a single slice subslice count.

This also had no impact in the current code base due breakage from 1)
always reqesting more than one slice.

While fixing this we also add some asserts to flag up any future bitfield
overflows.

v2:
 * Use a local in all branches for clarity. (Lionel)
Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Bspec: 12247
Reported-by: tony.ye@intel.com
Suggested-by: NLionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: tony.ye@intel.com
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: NLionel Landwerlin <lionel.g.landwerlin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180903113007.2643-1-tvrtko.ursulin@linux.intel.com

This patch fixes the PPS4 and PPS5 register definition macros that were
resulting into an incorect MMIO address.

Fixes: 2efbb2f0 ("i915/dp/dsc: Add DSC PPS register definitions")
Cc: Anusha Srivatsa <anusha.srivatsa@intel.com>
Signed-off-by: NManasi Navare <manasi.d.navare@intel.com>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: NAnusha Srivatsa <anusha.srivatsa@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180824014807.14681-1-manasi.d.navare@intel.com
(cherry picked from commit 5df52391)
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>

This patch fixes the PPS4 and PPS5 register definition macros that were
resulting into an incorect MMIO address.

Fixes: 2efbb2f0 ("i915/dp/dsc: Add DSC PPS register definitions")
Cc: Anusha Srivatsa <anusha.srivatsa@intel.com>
Signed-off-by: NManasi Navare <manasi.d.navare@intel.com>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: NAnusha Srivatsa <anusha.srivatsa@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180824014807.14681-1-manasi.d.navare@intel.com

Unlike the other ports, TC ports are not available to use as soon as
we get a hotplug. The TC PHYs can be shared between multiple
controllers: display, USB, etc. As a result, handshaking through FIA
is required around connect and disconnect to cleanly transfer
ownership with the controller and set the type-C power state.

This patch implements the flow sequences described by our
specification. We opt to grab ownership of the ports as soon as we get
the hotplugs in order to simplify the interactions and avoid surprises
in the user space side. We may consider changing this in the future,
once we improve our testing capabilities on this area.

v2:
 * This unifies the DP and HDMI patches so we can discuss everything
   at once so people looking at random single patches can actually
   understand the direction.
 * I found out the spec was updated a while ago. There's a small
   difference in the connect flow and the patch was updated for that.
 * Our spec also now gives a good explanation on what is really
   happening. As a result, comments were added.
 * Add some more comments as requested by Rodrigo (Rodrigo).
v3:
 * Downgrade a DRM_ERROR that shouldn't ever happen but we can't act
   on in case it does (Chris).

BSpec: 21750, 4250.
Cc: Animesh Manna <animesh.manna@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180801173441.9789-1-paulo.r.zanoni@intel.com

Rename PLANE_CTL_DECOMPRESSION_ENABLE to resemble the bpsec name -
PLANE_CTL_RENDER_DECOMPRESSION_ENABLE
Suggested-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NDhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180822015053.1420-2-dhinakaran.pandiyan@intel.com

PLLs are the source clocks for the DDIs so in order to determine the
ddi clock we need to check the PLL configuration.

For MG PHy Ports (C - F), depending on whether it is a TBT PLL or MG
PLL the link lock can be obtained from the the PLL divisors based on
the specification.

v2 (from Paulo):
 * Make the algorithm look more like what's in the spec, also document
   where we differ form the spec and why.
 * Make the code a little more consistent with our coding style.
Reviewed-by: NJosé Roberto de Souza <jose.souza@intel.com>
Signed-off-by: NManasi Navare <manasi.d.navare@intel.com>
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180817215209.29133-2-paulo.r.zanoni@intel.com

drm/i915/icl: Implement HSDIV_RATIO of MG_CLKTOP2_HSCLKCTL_PORT reg as separate divider value defines

The register value of Divider Ratio for high speed divider
(hsdiv_ratio) in MG_CLKTOP2_HSCLKCTL_PORT register is not same as the
actual numerical value of the divider. So this patch implements
separate divider value defines for that field.
icl_mg_pll_find_divisors() can use these defines instead of magic
register values.

The new defines are going to be used in the next patch.

v2 (from Paulo):
 * Rebase.
 * Make it look a little more like the rest of our code.
v3 (from Paulo):
 * Make hsdiv u32 now that it's a bit field (José).
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: NJosé Roberto de Souza <jose.souza@intel.com>
Suggested-by: NJames Ausmus <james.ausmus@intel.com>
Signed-off-by: NManasi Navare <manasi.d.navare@intel.com>
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180817215209.29133-1-paulo.r.zanoni@intel.com

Instead of defining all registers twice, define just a PCH_GPIO_BASE
that has the same address as PCH_GPIO_A and use that to calculate all
the others. This also brings VLV and !HAS_GMCH_DISPLAY in line, doing
the same thing.

v2: Fix GMBUS registers to be relative to gpio base; create GPIO()
    macro to return a particular gpio address and move the enum out of
    i915_reg.h (suggested by Jani)

v3: Move base offset inside the GPIO() macro so the GMBUS defines don't
    actually need to be changed (suggested by Daniel/Ville)

v4: Move definition of i915_gpio to intel_display.h and remove
    GMBUS/GPIO handling from gvt since now they have their own
    defines.
Signed-off-by: NLucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180727193647.8639-3-lucas.demarchi@intel.com

This is the only place that they are being used - the others use the
GMBUS* macros that rely on dev_priv being already properly initialized.

Cc: intel-gvt-dev@lists.freedesktop.org
Cc: Zhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: NLucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: NZhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180727193647.8639-1-lucas.demarchi@intel.com

Since Haswell we have no color range indication either in the pipe or
port registers for DP. Instead, there's a separate register for setting
the DP Main Stream Attributes (MSA) directly. The MSA register
definition makes no references to colorimetry, just a vague reference to
the DP spec. The connection to the color range was lost.

Apparently we've failed to set the proper MSA bit for limited, or CEA,
range ever since the first DDI platforms. We've started setting other
MSA parameters since commit dae84799 ("drm/i915: add
intel_ddi_set_pipe_settings").

Without the crucial bit of information, the DP sink has no way of
knowing the source is actually transmitting limited range RGB, leading
to "washed out" colors. With the colorimetry information, compliant
sinks should be able to handle the limited range properly. Native
(i.e. non-LSPCON) HDMI was not affected because we do pass the color
range via AVI infoframes.

Though not the root cause, the problem was made worse for DDI platforms
with commit 55bc60db ("drm/i915: Add "Automatic" mode for the
"Broadcast RGB" property"), which selects limited range RGB
automatically based on the mode, as per the DP, HDMI and CEA specs.

After all these years, the fix boils down to flipping one bit.

[Per testing reports, this fixes DP sinks, but not the LSPCON. My
 educated guess is that the LSPCON fails to turn the CEA range MSA into
 AVI infoframes for HDMI.]
Reported-by: NMichał Kopeć <mkopec12@gmail.com>
Reported-by: NN. W. <nw9165-3201@yahoo.com>
Reported-by: NNicholas Stommel <nicholas.stommel@gmail.com>
Reported-by: NTom Yan <tom.ty89@gmail.com>
Tested-by: NNicholas Stommel <nicholas.stommel@gmail.com>
References: https://bugs.freedesktop.org/show_bug.cgi?id=100023
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107476
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=94921
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: <stable@vger.kernel.org> # v3.9+
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180814060001.18224-1-jani.nikula@intel.com
(cherry picked from commit dc5977da)
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>

Since Haswell we have no color range indication either in the pipe or
port registers for DP. Instead, there's a separate register for setting
the DP Main Stream Attributes (MSA) directly. The MSA register
definition makes no references to colorimetry, just a vague reference to
the DP spec. The connection to the color range was lost.

Apparently we've failed to set the proper MSA bit for limited, or CEA,
range ever since the first DDI platforms. We've started setting other
MSA parameters since commit dae84799 ("drm/i915: add
intel_ddi_set_pipe_settings").

Without the crucial bit of information, the DP sink has no way of
knowing the source is actually transmitting limited range RGB, leading
to "washed out" colors. With the colorimetry information, compliant
sinks should be able to handle the limited range properly. Native
(i.e. non-LSPCON) HDMI was not affected because we do pass the color
range via AVI infoframes.

Though not the root cause, the problem was made worse for DDI platforms
with commit 55bc60db ("drm/i915: Add "Automatic" mode for the
"Broadcast RGB" property"), which selects limited range RGB
automatically based on the mode, as per the DP, HDMI and CEA specs.

After all these years, the fix boils down to flipping one bit.

[Per testing reports, this fixes DP sinks, but not the LSPCON. My
 educated guess is that the LSPCON fails to turn the CEA range MSA into
 AVI infoframes for HDMI.]
Reported-by: NMichał Kopeć <mkopec12@gmail.com>
Reported-by: NN. W. <nw9165-3201@yahoo.com>
Reported-by: NNicholas Stommel <nicholas.stommel@gmail.com>
Reported-by: NTom Yan <tom.ty89@gmail.com>
Tested-by: NNicholas Stommel <nicholas.stommel@gmail.com>
References: https://bugs.freedesktop.org/show_bug.cgi?id=100023
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107476
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=94921
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: <stable@vger.kernel.org> # v3.9+
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180814060001.18224-1-jani.nikula@intel.com

On ICL there are 5 fused power gates, so add the two missing ones for
clarity.

Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180806095843.13294-11-imre.deak@intel.com

There is no need for separate IDs for power wells on a new platform with
the same functionality as an other power well on a previous platform, we
can just reuse the ID from the previous platform. This is only possible
after the previous patches where we removed dependence on the actual
enum values.

This also fixes a problem on ICL where in assert_can_enable_dc5/9() we
would've failed to look up the PW#2 power well.

v2:
- Keep an ID assigned for the ICL PW#2 power well too. (Paulo)

Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: NImre Deak <imre.deak@intel.com>
[Added comment about the ICL PW#2 fix to the commit log]
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180806095843.13294-10-imre.deak@intel.com

The format for the ID names is <platform>_DISP_PW_* so rename the IDs
not following this accordingly. Leave BXT_DPIO_CMN_BC as-is since we'll
change that to use another existing ID in the next patch.

v2:
- Fix line over 80 chars checkpatch warning.

Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180806095843.13294-9-imre.deak@intel.com

Now that we removed dependence on the power well IDs to determine the
control register and request/status flag offsets the only purpose of
power well IDs is to look up power wells directly bypassing the power
domains framework. However this direct lookup isn't needed for most of
the exisiting power wells and hopefully won't be needed for any new
power wells in the future. To make maintenance of the power well ID enum
easier, don't require a unique ID for each power well, only if it's
necessary. Remove the IDs becoming redundant this way and assign to all
the corresponding power wells a new DISP_PW_ID_NONE ID.

After the previous two patches the IDs don't need to have a fixed value,
so remove the explicit initializers and adjust the enum's code comment
accordingly.

v2:
- Keep required ID assignments for HSW_DISP_PW_GLOBAL and ICL_DISP_PW_2.
  (Paulo)

Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180806095843.13294-8-imre.deak@intel.com

Similarly to the previous patch use a separate request/status HW flag
index defined right after the corresponding control registers instead of
depending for this on the power well IDs. Since the set of
control/status registers varies among the different power wells (on a
single platform), also add a new i915_power_well_registers struct that
we populate and assign to each DDI power well as needed.

Also clarify a bit the code comment describing the function and layout
of the control registers.

This also fixes a problem on ICL, where we incorrectly read the KVMR
control register in hsw_power_well_requesters() even for DDI and AUX
power wells.

v2:
- Clarify platform range tags in code comments. (Paulo)
- Fix line over 80 chars checkpatch warning.

Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180806095843.13294-7-imre.deak@intel.com

Atm, we determine the control/status flag offsets within the PUNIT
control/status registers based on the power well's ID. Since the power
well ID enum is global across all platforms, the associated macros to
get the flag offsets involves some magic. This makes checking the
register/bit definitions against the specification more difficult than
necessary. Also the values in the power well ID enum must stay fixed,
making code maintenance of the enum cumbersome.

To solve the above define the control/status flag indices right after
the corresponding registers and use these to derive the control/status
flag values by storing the indices in the i915_power_well_desc struct.

Initializing anonymous union fields require the preceding field in the
struct to be explicitly initialized - even when using named
initializers - and the initialization to be done right before the union
initialization, hence the reordering of the .id fields.

v2:
- Clarify commit log message about anonymous union initializers. (Paulo)

Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180806095843.13294-6-imre.deak@intel.com

The register for 0xe420 is unable to hold any value, including
this bit. The documentation is also mixed between having a
register bit for toggle and having a state command setup
for it. Apparently the register toggle is deprecated.

Remove the register toggle as evidence shows it's futile.

The thing remaining is an apology and humble request for
Mesa folks to resurrect their state setup for this as they
were on right track from start.

This reverts commit 0bf059f3.

Fixes: 0bf059f3 ("drm/i915/icl: WaEnableFloatBlendOptimization")
References: HSDES#1406393558
Cc: Oscar Mateo <oscar.mateo@intel.com>
Cc: Anuj Phogat <anuj.phogat@gmail.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Signed-off-by: NMika Kuoppala <mika.kuoppala@linux.intel.com>
Acked-by: NChris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20180730120636.26958-1-mika.kuoppala@linux.intel.com
(cherry picked from commit c358514b)
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>

Make sure that the RPS IIR is completely clear on disabling so we should
not get any more interrupts after idling. Since the IIR is shared with
the guc, we have to be careful to only clobber RPS events.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: NMika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180802100631.31305-3-chris@chris-wilson.co.uk

The register for 0xe420 is unable to hold any value, including
this bit. The documentation is also mixed between having a
register bit for toggle and having a state command setup
for it. Apparently the register toggle is deprecated.

Remove the register toggle as evidence shows it's futile.

The thing remaining is an apology and humble request for
Mesa folks to resurrect their state setup for this as they
were on right track from start.

This reverts commit 0bf059f3.

Fixes: 0bf059f3 ("drm/i915/icl: WaEnableFloatBlendOptimization")
References: HSDES#1406393558
Cc: Oscar Mateo <oscar.mateo@intel.com>
Cc: Anuj Phogat <anuj.phogat@gmail.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Signed-off-by: NMika Kuoppala <mika.kuoppala@linux.intel.com>
Acked-by: NChris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20180730120636.26958-1-mika.kuoppala@linux.intel.com

For a TBT sequence, we need to set the IO type to TBT
in  DDI_AUX_CTL.

v2: Avoid duplications.(Paulo)

Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NAnusha Srivatsa <anusha.srivatsa@intel.com>
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1532648115-29795-2-git-send-email-anusha.srivatsa@intel.com

The Gen11 TypeC PHY DDI Buffer chapter, PHY Clock Gating Programming
section says that PHY clock gating should be disabled before starting
voltage swing programming, then enabled after any link training is
complete.

v2: Simple rebase.

Cc: Animesh Manna <animesh.manna@intel.com>
Cc: Manasi Navare <manasi.d.navare@intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> (v1)
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180725002813.6938-6-paulo.r.zanoni@intel.com

Programming this register is part of the Enable Sequence for
DisplayPort on ICL. Do as the spec says.

v2: Simple rebase.

Cc: Animesh Manna <animesh.manna@intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> (v1)
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180725002813.6938-5-paulo.r.zanoni@intel.com

In ICL, Flexible IO Adapter (FIA) muxes data and clocks of USB 3.1,
tbt and display controller. In DP alt mode FIA configure the
number of lanes and will be used apart from DPCD read to calculate max
available lanes for DP enablement.

v2 (from Paulo): Simple rebase.

Reviewed-by: Anusha Srivatsa <anusha.srivatsa@intel.com> (v1).
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NAnimesh Manna <animesh.manna@intel.com>
[Paulo: significant rewrite of the patch.]
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180725002813.6938-4-paulo.r.zanoni@intel.com

Do like the other functions and check for the status bits. The "Hot
Plug Detection" page from our documentation says we can't just use the
ISR bits on the CPU side (North Display, which has the TC and TBT
modes), so use the correct register: DFLEXDPSP, TC Live State field.

v2: Rebase.
v3:
  - Simplify true/false assignment (Rodrigo).
  - Reorganize is_gen if ladder (Rodrigo).
  - Don't use the ISR for TC/TBT CPU bits.
v4:
  - Improve commit message wording (Lucas).
v5:
  - COMMIT_LOG_LONG_LINE (Checkpatch).

Cc: Animesh Manna <animesh.manna@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> (v3).
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180725195927.12059-1-paulo.r.zanoni@intel.com

This patch adds the remaining register definitions and bit fields
required for MG PHy DDI buffer initializations and voltage
swing programming for MG PHy DDI ports.

While at it this patch also fixes the naming for previously defined
MG PHY registers in original commit id (c92f47b5 "drm/i915/icl:
Add register defs for voltage swing sequences for MG PHY DDI").
Since the MG PHY registers are first defined in ICL platform, there
is no need for _ICL prefix.

v4 (from Paulo): add two white spaces to CRI_CALCINIT too.

v3:
* Fix register names, add spaces for MASK defines, correct the order
of #defines (Paulo)

v2:
* Change the MG_TX_DRVCTL registers names to match the spec (Anusha)

Cc: James Ausmus <james.ausmus@intel.com>
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NManasi Navare <manasi.d.navare@intel.com>
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1531510993-6606-1-git-send-email-manasi.d.navare@intel.com

This patch fixes the commit -
<2efbb2f0> ("i915/dp/dsc: Add DSC PPS register definitions"),
which did not have _MMIO() for DSCA and DSCC.

v2: Fix typos. (manasi)

v3: Change the commit message (Rodrigo)

Cc: Rodrigi Vivi <rodrigo.vivi@intel.com>
Cc: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: NAnusha Srivatsa <anusha.srivatsa@intel.com>
Reviewed-by: NManasi Navare <manasi.d.navare@intel.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1532122962-9068-1-git-send-email-anusha.srivatsa@intel.com

RC model has these parameters that correspond with each of
15 ranges of RC buffer threshold value in the RC model.
The three elements are range_min_qp, range_max_qp and
range_bpg_offset.

Add the Rate Control range values for eDP/MIPI and DP case.
The actual values are calculated usung a helper function.
This patch adds the shifts to registers where the value will
be written during atomic commit.

v2:
- Use _MMIO_PIPE() instead of _MMIO(_PICK()) (Manasi)
- Combine shifts (Manasi)

Cc: Jose Souza <jose.souza@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: NAnusha Srivatsa <anusha.srivatsa@intel.com>
Reviewed-by: NManasi Navare <manasi.d.navare@intel.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1531861861-10950-4-git-send-email-anusha.srivatsa@intel.com

Add register defines and  shifts that control the RC buffer threshold
between encoder and decoder for eDP/MIPI and DP cases.

The actual values are calculated usung a helper function.
This patch adds the shifts to registers where the value will
be written during atomic commit.

v2:
- Use _MMIO_PIPE() instead of _MMIO_(_PICK()) (Manasi)
- Combine shifts (Manasi)

Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: NAnusha Srivatsa <anusha.srivatsa@intel.com>
Reviewed-by: NManasi Navare <manasi.d.navare@intel.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1531861861-10950-3-git-send-email-anusha.srivatsa@intel.com

Display Stream Compression(DSC) has a set of Picture
Parameter Set(PPS) components that the encoder must
communicate to the decoder.

This patch adds register definitions to
the PPS parameters for eDP/MIPI case and Display Port.

v2:
- Use _MMIO_PIPE instead of _MMIO(_PICK()). (Manasi)
- Use DSC constants as arguments. (Manasi)

Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: NAnusha Srivatsa <anusha.srivatsa@intel.com>
Reviewed-by: NManasi Navare <manasi.d.navare@intel.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1531861861-10950-2-git-send-email-anusha.srivatsa@intel.com

The Picture Parameter Set metadata for DSC has to be sent
to the panel through secondary data packets. Add the error
correction registers, data registers and control registers
for the same.

The control registers for  transcoders A and B are already
defined and will be reused for Icelake purpose. This patch adds
Control register for EDP and transcoder C apart from adding the
PPS data and error registers.

v2: reuse MMIO_TRANS2 for _PPS_DATA and _PPS_ECC.
The  _MMIO_TRANS2(pipe, reg) macro definition takes care of the eDp case

Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: NAnusha Srivatsa <anusha.srivatsa@intel.com>
Reviewed-by: NManasi Navare <manasi.d.navare@intel.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1531861861-10950-1-git-send-email-anusha.srivatsa@intel.com

Support for Burst read in HW is added for HDCP2.2 compliance
requirement.

This patch enables the burst read for all the gmbus read of more than
511Bytes, on capable platforms.

v2:
  Extra line is removed.
v3:
  Macro is added for detecting the BURST_READ Support [Jani]
  Runtime detection of the need for burst_read [Jani]
  Calculation enhancement.
v4:
  GMBUS0 reg val is passed from caller [ville]
  Removed a extra var [ville]
  Extra brackets are removed [ville]
  Implemented the handling of 512Bytes Burst Read.
v5:
  Burst read max length is fixed at 767Bytes [Ville]
v6:
  Collecting the received reviewed-by.
Signed-off-by: NRamalingam C <ramalingam.c@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/1530192889-5789-3-git-send-email-ramalingam.c@intel.com

GMBUS HW supports 511Bytes as Max Bytes per single RD/WR op. Instead of
enabling the 511Bytes per RD/WR cycle on legacy platforms for no
absolute ROIs, this change allows the max bytes per op upto 511Bytes
from Gen9 onwards.

v2:
  No Change.
v3:
  Inline function for max_xfer_size and renaming of the macro.[Jani]
v4:
  Extra brackets removed [ville]
  Commit msg is modified.
v5:
  Collecting the Reviewed-By received.

Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NRamalingam C <ramalingam.c@intel.com>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/1530192889-5789-2-git-send-email-ramalingam.c@intel.com

Now that our stolen memory is already reserved by the x86 subsystem
(since commit "x86/gpu: reserve ICL's graphics stolen memory"), make
use of it.

Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: x86@kernel.org
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180504203252.28048-2-paulo.r.zanoni@intel.com

This patch defines AUX lane registers for PORT_PCS_DW1,
PORT_TX_DW2, PORT_TX_DW4, PORT_TX_DW5 used during
dsi enabling.

v2: Review comments from Jani N:
    - Define _ICL_PORT_PCS_DW1_AUX_A for consistency
    - Three spaces for bitfield definition.
Signed-off-by: NMadhav Chauhan <madhav.chauhan@intel.com>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1530798591-2077-8-git-send-email-madhav.chauhan@intel.com