All platforms using the shared DPLL framework use 3 reference clocks for
their DPLLs: SSC, non-SSC and DSI. For a more unified way across
platforms store the frequency of these ref clocks as part of the DPLL
global state. This also allows us to keep the HW access reading out the
ref clock value separate from the DPLL frequency calculation that
depends on the ref clock.
For now add only the SSC and non-SSC ref clocks, as the pre-ICL DSI code
has its own logic for calculating DPLL parameters instead of the shared
DPLL framework.
v2:
- Apply the ICL combo PHY PLL ref_clock/2 adjustment during the
frequency->PLL param conversion direction as well. (CI shards)
- s/kHZ/kHz/ (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/20200228153328.17842-1-imre.deak@intel.com
Link training is failling when running link at 2.7GHz and 1.62GHz and
following BSpec pll algorithm.
Comparing the values calculated and the ones from the reference table
it looks like MG_CLKTOP2_CORECLKCTL1_A_DIVRATIO should not always set
to 5. For DP ports ICL mg pll algorithm sets it to 10 or 5 based on
div2 value, that matches with dkl hardcoded table.
So implementing this way as it proved to work in HW and leaving a
comment so we know why it do not match BSpec.
v4:
Using the same is_dp check as ICL, need testing on HDMI over tc port
Issue reported on BSpec 49204.
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190926210659.56317-3-jose.souza@intel.com
enum port is a mess now because it no longer matches the spec
at all. Let's start to dig ourselves out of this hole by
reducing our reliance on port_name(). This should at least make
a bunch of debug messages a bit more sensible while we think how
to fill the the hole properly.
Based on the following cocci script with a lot of manual cleanup
(all the format strings etc.):
@@
expression E;
@@
(
- port_name(E->port)
+ E->base.base.id, E->base.name
|
- port_name(E.port)
+ E.base.base.id, E.base.name
)
@@
enum port P;
expression E;
@@
P = E->port
<...
- port_name(P)
+ E->base.base.id, E->base.name
...>
@@
enum port P;
expression E;
@@
P = E.port
<...
- port_name(P)
+ E.base.base.id, E.base.name
...>
@@
expression E;
@@
{
- enum port P = E;
... when != P
}
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190830182719.32608-1-ville.syrjala@linux.intel.com
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
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
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
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 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
