Input CSC Co-efficients for BT601 and BT709 YCbCR to RGB
conversion were slightly off. Fixed the same.
v2: Fixed the co-eficients as there was issue with reference
matrix, spotted by Ville.
v3: Rebase
Signed-off-by: Uma Shankar <uma.shankar@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190628080230.27492-4-uma.shankar@intel.com
Fixed Y Pre-offset in case of Full Range YCbCr.
v2: Rebase
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Uma Shankar <uma.shankar@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190628080230.27492-3-uma.shankar@intel.com
Currently input csc for YCbCR to RGB conversion handles only
BT601 and Bt709. Extending it to support BT2020 as well.
v2: Fixed the co-efficients for LR to FR conversion,
as suggested by Ville.
v3: Fixed Y Pre-offset in case of Full Range YCbCr as suggested
by Ville.
v4: Split the v2 and v3 changes.
v5: Rebase
v6: Fix a rebase fumble.
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Uma Shankar <uma.shankar@intel.com>
Signed-off-by: Shashank Sharma <shashank.sharma@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190628080230.27492-2-uma.shankar@intel.com
For consistency clear the icl_port_dplls from the new crtc state, when
releasing the DPLLs from the old crtc state. Leaving them set could
result in releasing the same PLLs multiple times from the same CRTC
state incorrectly (if the same CRTC was first used for a TypeC port then
for a combo PHY port).
Leaving the stale pointers behind happens not to cause a problem atm
(since the incorrect releasing will be a NOP), but we need to fix that
for consistency.
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/20190708140735.20198-2-imre.deak@intel.com
For symmetry with the get_dplls() hook which sets the shared_dpll
pointer clear the same pointer from the put_dplls() hook.
While at it also constify the old crtc state.
v2:
- Constify the old crtc state. (Ville)
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/20190708140735.20198-1-imre.deak@intel.com
Drop the redundant "SDVO_CMD_" prefix from the command name
strings in sdvo_cmd_names[].
While at it throw away the unused struct name, and undef
SDVO_CMD_NAME_ENTRY() when we're done.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190619180312.31817-4-ville.syrjala@linux.intel.com
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Use named initializers to make it easier to associate the SDVO debug
prints with the SDVO command defines. Also switch to using ARRAY_SIZE()
instead of assuming that SDVO_CMD_STATUS_SCALING_NOT_SUPP is the last
command type.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190619180312.31817-2-ville.syrjala@linux.intel.com
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/gpu/drm/i915/display/intel_ddi.c: In function 'intel_ddi_get_config':
drivers/gpu/drm/i915/display/intel_ddi.c:3774:29: warning:
variable 'intel_dig_port' set but not used [-Wunused-but-set-variable]
struct intel_digital_port *intel_dig_port;
It is never used, so can be removed.
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190705113138.65880-1-yuehaibing@huawei.com
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/gpu/drm/i915/display/intel_dp.c: In function 'intel_dp_set_drrs_state':
drivers/gpu/drm/i915/display/intel_dp.c:6623:24: warning:
variable 'encoder' set but not used [-Wunused-but-set-variable]
It's never used, so can be removed.Also remove related
variable 'dig_port'
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190705113112.64715-1-yuehaibing@huawei.com
This patch adds support for DPLL4 on EHL that include the
following restrictions:
- DPLL4 cannot be used with DDIA (combo port A internal eDP usage).
DPLL4 can be used with other DDIs, including DDID
(combo port A external usage).
- DPLL4 cannot be enabled when DC5 or DC6 are enabled.
- The DPLL4 enable, lock, power enabled, and power state are connected
to the MGPLL1_ENABLE register.
v2: (suggestions from Bob Paauwe)
- Rework ehl_get_dpll() function to call intel_find_shared_dpll() and
iterate twice: once for Combo plls and once for MG plls.
- Use MG pll funcs for DPLL4 instead of creating new ones and modify
mg_pll_enable to include the restrictions for EHL.
v3: Fix compilation error
v4: (suggestions from Lucas and Ville)
- Treat DPLL4 as a combo phy PLL and not as MG PLL
- Disable DC states when this DPLL is being enabled
- Reuse icl_get_dpll instead of creating a separate one for EHL
v5: (suggestion from Ville)
- Refcount the DC OFF power domains during the enabling and disabling
of this DPLL.
v6: rebase
v7: (suggestion from Imre)
- Add a new power domain instead of iterating over the domains
assoicated with DC OFF power well.
v8: (Ville and Imre)
- Rename POWER_DOMAIN_DPLL4 TO POWER_DOMAIN_DPLL_DC_OFF
- Grab a reference in intel_modeset_setup_hw_state() if this
DPLL was already enabled perhaps by BIOS.
- Check for the port type instead of the encoder
v9: (Ville)
- Move the block of code that grabs a reference to the power domain
POWER_DOMAIN_DPLL_DC_OFF to intel_modeset_readout_hw_state() to ensure
that there is a reference present before this DPLL might get disabled.
v10: rebase
Cc: José Roberto de Souza <jose.souza@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Signed-off-by: Vivek Kasireddy <vivek.kasireddy@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190703230353.24059-1-vivek.kasireddy@intel.com
Split the format lists for different planes on skl/icl more cleanly.
On skl+ we have just two types of planes: those can do planar and
those that can't.
On icl we have three types of planes: hdr planes, sdr planes that
can do planar, and sdr planes that can't do planar. Those latter two
are the same set of planes we must when choose from when picking the
UV vs. Y plane for planar scanout. So we shall just designate
them sdr uv planes and sdr y planes.
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190703200824.5971-7-ville.syrjala@linux.intel.com
All sprite planes have a progammable gamma ramp. Set it up with
a linear ramp on all platforms. This actually matches the reset
value but soon we'll want to reprogram this ramp on some machines,
so let's just set it up across the board.
Note that on pre-IVB the hardware bypasses the gamma unit
unless a YCbCr pixel format is used.
v2: Add parens around << in ilk_linear_gamma()
Skip gamma programming for RGB on pre-IVB
s/DVSGAMC/DVSGAMC_G4X/
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190703200824.5971-4-ville.syrjala@linux.intel.com
We don't currently have any use for the sprite gamma on ivb-bdw.
Let's disable it. We already do that on skl+.
On pre-ivb there is no way to disable the sprite gamma, and it
only affects YCbCr pixel formats, whereas on ivb+ it also
affects RGB formats.
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190703200824.5971-3-ville.syrjala@linux.intel.com
Plane B and C (note that we don't actually expose plane C currently)
on gen2/3 have a window generator, as does the primary plane on CHV
pipe B. So let's allow positioning of these planes freely within the
pipe source area.
Plane A on gen2/3 seems to have some kind of partial window generator
which would allow you to cut the plane off midway through the scanout,
but it would still have to start at the top-left corner of the pipe,
and it would have to be full width. That's doesn't sound all that
useful, so for simplicity let's just keep to the idea that plane A
has to be fullscreen.
Gen4 removed the plane A/B windowing support entirely, and it wasn't
reintroduced until SKL (apart from the CHV pipe B special case).
v2: s/plane/i9xx_plane/ etc. (James)
v3: Make it less confusing
v4: Deal with IS_GEN()
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190703200824.5971-2-ville.syrjala@linux.intel.com
Adding N & CTS values for 10/12 bit deep color from Appendix C
table in HDMI 2.0 spec. The correct values for N is not chosen
automatically by hardware for deep color modes.
v2: Remove unnecessary initialization of size
Signed-off-by: Aditya Swarup <aditya.swarup@intel.com>
Cc: Clint Taylor <Clinton.A.Taylor@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190627220708.31700-2-aditya.swarup@intel.com
Use port_clock to check the clock values in n/cts lookup table instead
of crtc_clock. As port_clock is already adjusted based on color mode set
(8 bit or deep color), this will help in checking clock values for deep
color modes from n/cts lookup table.
Signed-off-by: Aditya Swarup <aditya.swarup@intel.com>
Cc: Clint Taylor <Clinton.A.Taylor@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190627220708.31700-1-aditya.swarup@intel.com
When SAGV is forced to disabled/min/med/max in the BIOS pcode will
only hand us a single QGV point instead of the normal three. Fix
the code to deal with that instead declaring the bandwidth limit
to be 0 MB/s (and thus preventing any planes from being enabled).
Also shrink the max_bw sturct a bit while at it, and change the
deratedbw type to unsigned since the code returns the bw as
an unsigned int.
Since we now keep track of how many qgv points we got from pcode
we can drop the earlier check added for the "pcode doesn't
support the memory subsystem query" case.
Cc: felix.j.degrood@intel.com
Cc: Mark Janes <mark.a.janes@intel.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: Clint Taylor <Clinton.A.Taylor@intel.com>
Fixes: c457d9cf25 ("drm/i915: Make sure we have enough memory bandwidth on ICL")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110838
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190606124210.3482-1-ville.syrjala@linux.intel.com
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
icl-dsi is dying on suspend/resume at
RIP: 0010:icl_update_active_dpll+0x2c/0xa0 [i915]
which appears due to the loss of the time primary_port across suspend.
Protect against the potential NULL dereference by assuming
ICL_PORT_DPLL_DEFAULT unless the port is actively specified otherwise.
Fixes: 24a7bfe0c2 ("drm/i915: Keep the TypeC port mode fixed when the port is active")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190702140950.7069-1-chris@chris-wilson.co.uk
When eliminating our use of drm_irq_install() I failed to convert
all our synchronize_irq() calls to consult pdev->irq instead of
dev_priv->drm.irq. As we no longer populate dev_priv->drm.irq
we're no longer synchronizing against anything.
v2: Add intel_syncrhonize_irq() (Chris)
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reported-by: Imre Deak <imre.deak@intel.com>
Fixes: b318b82455 ("drm/i915: Nuke drm_driver irq vfuncs")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111012
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20190702151723.29739-1-ville.syrjala@linux.intel.com
Although EHL added a third combo PHY, no PHY_MISC register was added for
PHY C. The bspec indicates that there's no need to program the "DE to
IO Comp Pwr Down" setting for this PHY that we usually need to set in
PHY_MISC.
v2:
- Add IS_ELKHARTLAKE() guards since future platforms that have a PHY C
are likely to reinstate the PHY_MISC register. (Jose)
- Use goto's to skip PHY_MISC programming & minimize code deltas. (Jose)
Bspec: 33148
Cc: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190626000352.31926-4-matthew.d.roper@intel.com
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
The port parameter hasn't been used since the last bspec phy programming
update. Drop it to make some upcoming changes simpler.
References: 9659c1af45 ("drm/i915/icl: combo port vswing programming changes per BSPEC")
Cc: Clint Taylor <clinton.a.taylor@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Clint Taylor <Clinton.A.Taylor@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190626000352.31926-2-matthew.d.roper@intel.com
Lane reversal happens only in the FIA module for TBT-alt/DP-alt mode, so
WARN if lane reversal is attempted at a different level. See the
BSpec DDI_BUF_CTL register description.
Cc: Manasi Navare <manasi.d.navare@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/20190628143635.22066-24-imre.deak@intel.com
Disconnecting the TypeC PHY when the port is in legacy mode is not
necessary:
- BSpec doesn't specify a disconnect sequence for legacy mode.
- The use of the PHY is dedicated for the display in legacy mode.
- We keep the PHY always connected during runtime as well in legacy
mode.
We disconnect the PHY when needed during a disabling modeset for the
port, so we can also remove the disconnect call from the destroy hook.
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/20190628143635.22066-23-imre.deak@intel.com
Add state verification for the TypeC port mode wrt. the port's AUX power
well enabling/disabling. Also check the correctness of changing the port
mode:
- When enabling/disabling the AUX power well for a TypeC port we must hold
the TypeC port lock - the case for AUX transfers - or hold a Type C
port link reference - the case for modeset enabling/disabling.
- When changing the TypeC port mode the port's AUX power domain must be
disabled.
v2: (Ville)
- Simplify power_well_async_ref_count().
- Fix the commit log, clarifying what are the valid conditions to
enable/disable the AUX power wells.
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: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190628143635.22066-22-imre.deak@intel.com
The TypeC port mode needs to stay fixed whenever the port is active. Do
that by introducing a tc_link_refcount to account for active ports,
avoiding changing the port mode if a reference is held.
During the modeset commit phase we also have to reset the port mode and
update the active PLL reflecting the new port mode. We can do this only
once the port and its old PLL has been already disabled. Add the new
encoder update_prepare/complete hooks that are called around the whole
enabling sequence. The TypeC specific hooks of these will reset the port
mode, update the active PLL if the port will be active and ensure that
the port mode will stay fixed for the duration of the whole enabling
sequence by holding a tc_link_refcount.
During the port enabling, the pre_pll_enable/post_pll_disable hooks will
take/release a tc_link_refcount to ensure the port mode stays fixed
while the port is active.
Changing the port mode should also be avoided during connector detection
and AUX transfers if the port is active, we'll do that by checking the
port's tc_link_refcount.
When resetting the port mode we also have to take into account the
maximum lanes provided by the FIA. It's guaranteed to be 4 in TBT-alt
and legacy modes, but there may be less lanes available in DP-alt mode,
in which case we have to fall back to TBT-alt mode.
While at it also update icl_tc_phy_connect()'s code comment, reflecting
the current way of switching the port mode.
v2:
- Add the update_prepare/complete hooks to the encoder instead of the
connector. (Ville)
- Simplify intel_connector_needs_modeset() by removing redundant if.
(Ville)
v3:
- Fix sparse warning, marking static functions as such.
v4:
- Rebase on drm-tip.
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Maarten Lankhorst <maarten.lankhorst@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/20190628143635.22066-21-imre.deak@intel.com
When enabling a TypeC port we need to reserve all the required PLLs for
it, the TBT PLL for TBT-alt and the MG PHY PLL for DP-alt/legacy sinks.
We can select the proper PLL for the current port mode from the reserved
PLLs only once we selected and locked down the port mode for the whole
duration of the port's active state. Resetting and locking down the port
mode can in turn happen only during the modeset commit phase once we
disabled the given port and the PLL it used.
To support the above reserve-and-select PLL semantic we store the
reserved PLLs along with their HW state in the CRTC state and provide a
way to select the active PLL from these. The selected PLL along with its
HW state will be pointed at by crtc_state->shared_dpll/dpll_hw_state as
in the case of other port types.
Besides reserving all required PLLs no functional changes.
v2:
- Fix releasing the ICL PLLs, not clearing the PLLs from the old
crtc_state.
- Init port_dpll to ICL_PORT_DPLL_DEFAULT closer to where port_dpll is
used for symmetry with the corresponding ICL_PORT_DPLL_MG_PHY init.
(Ville)
v3:
- Add FIXME: for clearing the ICL port PLLs from the new crtc state.
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Maarten Lankhorst <maarten.lankhorst@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/20190628143635.22066-20-imre.deak@intel.com
For clarity factor out the combo PHY and TypeC PHY specific code from
icl_get_dplls() into their own functions.
No functional changes.
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Maarten Lankhorst <maarten.lankhorst@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/20190628143635.22066-19-imre.deak@intel.com
Pass the PLL HW state to the PLL find/reference functions making it
clearer what is their input. Also pass to these the atomic state and the
CRTC object instead of the CRTC state, since they don't require the
latter.
Move setting the PLL in the crtc_state to the get_dpll() hook, which
is the more logical place for this, where the related PLL HW state was also
set.
This refactoring is also a preparation for a follow-up patch that will
have to find/reference multiple PLLs.
No functional changes.
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Maarten Lankhorst <maarten.lankhorst@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/20190628143635.22066-18-imre.deak@intel.com
For consistency s/intel_get_shared_dpll()/intel_reserve_shared_dplls()/
to better match intel_release_shared_dplls(). Also, pass to the
reserve/release and get_dplls/put_dplls hooks the intel_atomic_state and
CRTC object, that way these functions can look up the old or new state
as needed.
Also release the PLLs from the atomic state via a new
put_dplls->intel_unreference_shared_dpll() call chain for better
symmetry with the reservation via the
get_dplls->intel_reference_shared_dpll() call chain.
Since nothing uses the PLL returned by intel_reserve_shared_dplls(),
make it return only a bool.
While at it also clarify the reserve/release function docbook headers
making it clear that multiple DPLLs will be reserved/released and
whether the new or old atomic CRTC state is affected.
This refactoring is also a preparation for a follow-up change that needs
to reserve multiple DPLLs.
Kudos to Ville for the idea to pass intel_atomic_state around, to make
things clearer locally where an object's old/new atomic state is
required.
No functional changes.
v2:
- Fix checkpatch issue: typo in code comment.
v3:
- Rebase on drm-tip.
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Maarten Lankhorst <maarten.lankhorst@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/20190628143635.22066-17-imre.deak@intel.com
Use hex numbers, since that makes more sense when decoding a bit pattern.
No functional change.
Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Animesh Manna <animesh.manna@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.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/20190628143635.22066-16-imre.deak@intel.com
We must keep the TypeC port mode fixed for the duration of the connector
detection and each AUX transfers. Add a new TypeC lock holding it around
these two sequences. For consistency also hold the lock during the port
mode sanitization.
Whenever resetting the port mode (only during the detection for now) the
port's AUX power domain must be disabled already. Flush the async power
domain disabling work to ensure this.
A follow-up patch will make the port mode changing more robust by
postponing the change for active ports.
v2:
- Fix checkpatch issue: missing annotation for tc_lock.
Cc: José Roberto de Souza <jose.souza@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@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/20190628143635.22066-15-imre.deak@intel.com
For using the correct AUX power domains we have to sanitize the TypeC
port mode early, so move that before encoder sanitization. To do this
properly read out the actual port mode instead of just relying on the
VBT legacy port flag (which can be incorrect).
We also verify that the PHY is connected as expected if the port is
active. In case the port is inactive we connect the PHY in case of a
legacy port - as we did so far. The PHY will be connected during
detection for DP-alt mode - as it was done so far. For TBT-alt mode
nothing needs to be done to connect the PHY.
v2:
- Use DRM_DEBUG_KMS instead of DRM_DEBUG_DRIVER. (José)
v3:
- Detect TCCOLD any time PORT_TX_DFLEXDPCSSS is read. (Ville)
Cc: José Roberto de Souza <jose.souza@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@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: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190628143635.22066-14-imre.deak@intel.com
Make the order during detection more consistent: first reset the TypeC
port mode if needed (adding new helpers for this), then detect any
connected sink.
To check if a port mode reset is needed determine first the target port
mode based on the live status if a sink is already connected or the
PHY status complete flag otherwise.
Add a WARN in legacy mode if unexpectedly we can't set the unsafe mode
or if the FIA doesn't provide the 4 lanes required.
Cc: José Roberto de Souza <jose.souza@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@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>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190628143635.22066-13-imre.deak@intel.com
Based on a recent BSpec update (Index/21750) we must handle the TCCOLD
event associated with the DP-alt mode. We can detect this event by
reading an invalid all-1s value from FIA registers.
After detecting TCCOLD we will:
- fall back to TBT-alt mode when attempting to switch to DP-alt mode
- conclude that nothing is connected during live status detection
- WARN when already in unsafe mode, since then TCCOLD is unexpected
v2:
- Use DRM_DEBUG_KMS instead of DRM_DEBUG_DRIVER. (José)
v3:
- Use 0xffffffff instead of -1 as invalid FIA reg value.
(José, Ville)
- Check for TCCOLD in icl_tc_phy_status_complete() too. (Ville)
Cc: José Roberto de Souza <jose.souza@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.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/20190628143635.22066-12-imre.deak@intel.com
The PHY status complete flag normally clears when disconnecting the PHY
in DP-alt mode (achieved by switching to safe mode), so wait for the
flag to clear.
v2:
- Use DRM_DEBUG_KMS instead of DRM_DEBUG_DRIVER. (José)
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/20190628143635.22066-11-imre.deak@intel.com
Factor out helpers reading/parsing the TypeC specific registers, making
current users of them clearer and letting us use them later.
While at it also:
- Simplify icl_tc_phy_connect() with an early return in legacy mode.
- Simplify the live status check using one bitmask for all HPD bits.
- Remove a micro-optimisation of the repeated safe-mode clearing.
- Make sure we fix the legacy port flag in all cases.
Except for the last two, no functional changes.
v2:
- Don't do reg reads at variable declarations. (Jani)
- Prevent constant truncated compiler warning when assigning the
valid_hpd_mask. (Nick)
- s/intel_tc_port_get_lane_info/intel_tc_port_get_lane_mask/ (Ville)
v3:
- Make valid_hpd_mask init clear. (Ville)
Cc: José Roberto de Souza <jose.souza@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Nick Desaulniers <ndesaulniers@google.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/20190628143635.22066-10-imre.deak@intel.com
Unify the TypeC port notation in log messages, so that it matches the
spec. For instance the first ICL TypeC port will read as 'Port C/TC#1'.
v2:
- Format print the name only once. (José)
Cc: José Roberto de Souza <jose.souza@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Paulo Zanoni <paulo.r.zanoni@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/20190628143635.22066-9-imre.deak@intel.com
In the TypeC TBT-alt port mode we must use the TBT AUX power domain,
fix that.
Cc: Manasi Navare <manasi.d.navare@intel.com>
Cc: Anusha Srivatsa <anusha.srivatsa@intel.com>
Cc: José Roberto de Souza <jose.souza@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/20190628143635.22066-8-imre.deak@intel.com
Fix the mapping from a TBT AUX power well index to the DP_AUX_CH_CTL
register.
Fixes: c7375d9542 ("drm/i915: Configure AUX_CH_CTL when enabling the AUX power domain")
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/20190628143635.22066-7-imre.deak@intel.com
According to the spec we should not enable the DDI-IO power domain if
the TypeC port is in the TBT-alt mode, so do that only in the other
TypeC modes or for non-TypeC ports. See the internal BSpec Index/22243.
v2:
- Add the internal BSpec reference to the log message. (José)
Cc: Manasi Navare <manasi.d.navare@intel.com>
Cc: Anusha Srivatsa <anusha.srivatsa@intel.com>
Cc: José Roberto de Souza <jose.souza@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/20190628143635.22066-6-imre.deak@intel.com
The TypeC port mode can switch dynamically, to reflect that better call
the port's mode as 'mode' rather than 'type'.
While at it:
- s/TC_PORT_TBT/TC_PORT_TBT_ALT/ and s/TC_PORT_TYPEC/TC_PORT_DP_ALT/.
'TYPEC' is ambiguous, TBT_ALT and DP_ALT better match the reality.
- Remove the 'unknown' TypeC port mode. The mode is always known, it's
the TBT-alt/safe mode after HW reset and after disconnecting the PHY.
Simplify the tc_port/tc_type checks accordingly.
- Don't WARN if the port mode changes, that can happen normally.
No functional changes.
Cc: Animesh Manna <animesh.manna@intel.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Anusha Srivatsa <anusha.srivatsa@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: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190628143635.22066-5-imre.deak@intel.com
Move the TypeC port handling functions to a new file for clarity.
While at it:
- s/icl_tc_port_connected()/intel_tc_port_connected()/
icl_tc_phy_disconnect(), will be unexported later.
- s/intel_dp_get_fia_supported_lane_count()/
intel_tc_port_fia_max_lane_count()/
It's used for HDMI legacy mode too.
- Simplify function interfaces by passing only dig_port to them.
No functional changes.
v2:
- Fix checkpatch issues: +1/-1 empty lines in intel_tc.c and add
missing SPDX to intel_tc.h. (Jani)
Cc: Animesh Manna <animesh.manna@intel.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: José Roberto de Souza <jose.souza@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190628143635.22066-4-imre.deak@intel.com
The HW completion flag for the TBT AUX power well enabling/disabling
gets stuck if the firmware tears down the TBT DP tunnel before the
completion.
We shouldn't complain about the timeout, since it's expected to happen
and doesn't cause further issues. We suppress the disabling timeout
already, do the same for enabling.
v2:
- Make the debug message more precise. (José)
Cc: José Roberto de Souza <jose.souza@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.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/20190628143635.22066-3-imre.deak@intel.com
