aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/gpu/drm/i915/display/intel_dpll_mgr.h (follow)
AgeCommit message (Collapse)AuthorFilesLines
2022-06-17drm/i915/dpll: move shared dpll state verification to intel_dpll_mgr.cJani Nikula1-0/+5
Keep the shared dpll implementation details together by moving the dpll state verification to intel_dpll_mgr.c. Also declutter intel_display.c. v2: intel_shared_dpll_verify_state -> intel_shared_dpll_state_verify (Ville) Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/85b02186f1269dd374d11db35900130547a5f2c6.1655372759.git.jani.nikula@intel.com
2022-05-31drm/i915: Split shared dpll .get_dplls() into compute and get phasesVille Syrjälä1-0/+3
Split the DPLL state computation into a separate function from the current .get_dplls() which currently serves a dual duty by also reserving the shared DPLLs. v2: s/false/-EINVAL/ (Jani) Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220503182242.18797-2-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2022-04-25drm/i915: Pass dev_priv to intel_shared_dpll_init()Ville Syrjälä1-2/+1
Stop passing around the drm_device and just pass the dev_priv instead. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220325123205.22140-3-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2022-04-25drm/i915: Make .get_dplls() return intVille Syrjälä1-3/+3
Get rid of the confusing back and forth between bools and ints in the .get_dplls() stuff. Just make everything return an int. Initial conversion done with cocci, with some manual fixups on top: @find@ identifier func !~ "get_hw_state|_is_|needed"; typedef bool; parameter list[N] P; @@ - bool + int func(P) { <... ( - return true; + return 0; | - return false; + return -EINVAL; ) ...> } @@ identifier find.func; expression list[find.N] E; expression X; @@ - if (!func(E)) + ret = func(E); + if (ret) { ... - return X; + return ret; } @@ identifier find.func; expression X; expression list[find.N] E; @@ - if (!func(E)) + ret = func(E); + if (ret) - return X; + return ret; @@ identifier find.func; expression list[find.N] E; expression O, X; typedef bool; bool B; @@ - B = func(E); - if (O && !B) + if (O) { + ret = func(E); + if (ret) - return X; + return ret; + } @@ identifier find.func; expression list[find.N] E; expression O, X; @@ - if (O && !func(E)) + if (O) { + ret = func(E); + if (ret) - return X; + return ret; + } @@ identifier find.func; expression list[find.N] E; expression X; typedef bool; bool B; @@ - B = func(E); - if (!B) + ret = func(E); + if (ret) { ... - return X; + return ret; } Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220325123205.22140-2-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2022-02-18drm/i915/display/tgl+: Implement new PLL programming stepJosé Roberto de Souza1-0/+3
A new programming step was added to combo and TC PLL sequences. If override_AFC_startup is set in VBT, driver should overwrite AFC_startup value to 0x0 or 0x7 in PLL's div0 register. The current understating is that only TGL needs this and all other display 12 and newer platforms will have a older VBT or a newer VBT with override_AFC_startup set to 0 but in any case there is a drm_warn_on_once() to let us know if this is not true. v2: - specification updated, now AFC can be override to 0x0 or 0x7 - not using a union for div0 (Imre) - following previous wrong vbt naming: bits instead of bytes (Imre) BSpec: 49204 BSpec: 20122 BSpec: 49968 BSpec: 71360 Cc: Imre Deak <imre.deak@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> 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/20220216134059.25348-1-jose.souza@intel.com
2022-01-19drm/i915/dpll: make intel_shared_dpll_funcs internal to intel_dpll_mgr.cJani Nikula1-45/+1
Move struct intel_shared_dpll_funcs to intel_dpll_mgr.c, as no other place needs to have access to it. We also don't need to have kernel-doc documentation for file internal structures, so drop them while at it. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220119110528.2377899-1-jani.nikula@intel.com
2021-11-19drm/i915: drop intel_display.h include from intel_dpll_mgr.hJani Nikula1-1/+1
Use forward declarations instead. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211116171434.20516-2-jani.nikula@intel.com
2021-08-25drm/i915: Nuke intel_prepare_shared_dpll()Ville Syrjälä1-11/+0
intel_prepare_shared_dpll() is now useless, so get rid of it. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210715093530.31711-14-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2021-07-30drm/i915: replace random CNL commentsLucas De Marchi1-2/+1
Cleanup remaining cases that we find CNL in the codebase. Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210728215946.1573015-22-lucas.demarchi@intel.com
2021-03-08drm/i915: Use pipes instead crtc indices in PLL state trackingVille Syrjälä1-4/+4
All the other places we have use pipes instead of crtc indices when tracking resource usage. Life is easier when we do it the same way always, so switch the dpll mgr to using pipes as well. Looks like it was actually mixing these up in some cases so it would not even have worked correctly except when the device has a contiguous set of pipes starting from pipe A. Granted, that is the typical case but supposedly it may not always hold on modern hw. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210224144214.24803-4-ville.syrjala@linux.intel.com Reviewed-by: Mika Kahola <mika.kahola@intel.com>
2021-03-08drm/i915: Do intel_dpll_readout_hw_state() after encoder readoutVille Syrjälä1-0/+1
The clock readout for DDI encoders needs to moved into the encoders. To that end intel_dpll_readout_hw_state() needs to happen after the encoder readout as otherwise it can't correctly populate the PLL crtc_mask/active_mask bitmasks. v2: Populate DPLL ref clocks before the encoder->get_config() Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210225161225.30746-1-ville.syrjala@linux.intel.com Reviewed-by: Mika Kahola <mika.kahola@intel.com>
2020-11-16drm/i915: Use actual readout results for .get_freq()Ville Syrjälä1-3/+5
Currently the DPLL .get_freq() uses pll->state.hw_state which is not the thing we actually read out (except during driver load/resume). Outside of that pll->state.hw_state is just the thing we committed last time around. During state check we just read the thing into crtc_state->dpll_hw_state, so that is what we should use for calculating the DPLL output frequency. I think we used to do this so that the results of the readout were actually used, but somehow it got changed when the .get_freq() refactoring happened. Cc: Imre Deak <imre.deak@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201109231239.17002-3-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
2020-11-16drm/i915: Introduce intel_dpll_get_hw_state()Ville Syrjälä1-0/+3
Add a wrapper for the pll .get_hw_state() vfunc. Makes life a bit less miserable when you don't have to worry where the function pointer is stored. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201109231239.17002-1-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
2020-10-15drm/i915/dg1: Add DPLL macros for DG1Aditya Swarup1-0/+17
DG1 has 4 DPLLs where DPLL0 and DPLL1 drive DDIA/B and DPLL2 and DPLL3 drive DDI-TC1/DDI-TC2. Introduce DG1_DPLL_CFCRx() helper macros to configure DPLL registers. Bspec: 50288, 50299 Cc: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Aditya Swarup <aditya.swarup@intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201014191937.1266226-4-lucas.demarchi@intel.com
2020-03-09drm/i915: Fix documentation for intel_dpll_get_freq()Imre Deak1-0/+6
Fix the following kerneldoc warning and while at it also the doc for the corresponding vfunc hook. $ make htmldocs 2>&1 > /dev/null | grep i915 ./drivers/gpu/drm/i915/display/intel_dpll_mgr.h:285: warning: Function parameter or member 'get_freq' not described in 'intel_shared_dpll_funcs' 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/20200304150918.25473-1-imre.deak@intel.com
2020-03-02drm/i915/skl, cnl: Split out the WRPLL/LCPLL frequency calculationImre Deak1-3/+5
Split out the PLL parameter->frequency conversion logic for each type of PLL for symmetry with their corresponding inverse conversion functions. 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/20200226203455.23032-12-imre.deak@intel.com
2020-03-02drm/i915: Move DPLL frequency calculation to intel_dpll_mgr.cImre Deak1-0/+2
Move all the DPLL params->DPLL frequency conversion functions to intel_dpll_mgr.c where the corresponding inverse conversions are. The GEN11+ TBT PLL outputs multiple frequencies and for selecting the one in use we need to check the DDI CLK mux. As part of the DDI clock logic this selection is kept in intel_ddi.c. 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/20200226203455.23032-7-imre.deak@intel.com
2020-03-02drm/i915: Move DPLL HW readout/sanitize fns to intel_dpll_mgr.cImre Deak1-0/+2
Move the HW readout/sanitize functions to intel_dpll_mgr.c which contains the rest of shared DPLL functionality. 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/20200226203455.23032-3-imre.deak@intel.com
2019-10-25drm/i915/tgl: Fix doc not corresponding to codeAnna Karas1-2/+2
Replace PLLs names used in documentation to that used in the code. Cc: Vandita Kulkarni <vandita.kulkarni@intel.com> Fixes: 68ff39c3f8c0 ("drm/i915/tgl: Add new pll ids") Signed-off-by: Anna Karas <anna.karas@intel.com> Reviewed-by: Vandita Kulkarni <vandita.kulkarni@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190926123559.15717-1-anna.karas@intel.com
2019-10-25drm/i915: Describe structure member in documentationAnna Karas1-0/+5
Add description of wakeref member of intel_shared_dpll structure to documentation. Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Vivek Kasireddy <vivek.kasireddy@intel.com> Signed-off-by: Anna Karas <anna.karas@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20191008092849.6511-1-anna.karas@intel.com
2019-07-11drm/i915/tgl: Add new pll idsVandita Kulkarni1-5/+18
Add 2 new PLLs for additional TC ports. The names for the PLLs on TGL changed, but most registers remained the same, like MGPLL5_ENABLE, MGPLL6_ENABLE. So continue to use the name from ICL. Cc: Madhav Chauhan <madhav.chauhan@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Vandita Kulkarni <vandita.kulkarni@intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Anusha Srivatsa <anusha.srivatsa@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190711173115.28296-11-lucas.demarchi@intel.com
2019-07-11drm/i915: Polish intel_shared_dpll_swap_state()Ville Syrjälä1-2/+1
Use swap() instead of hand rolling it in intel_shared_dpll_swap_state(), and pass in the intel_atomic_state instead of drm_atomic_state. Makes the code less convoluted. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190701160550.24205-3-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
2019-07-05drm/i915/ehl: Add support for DPLL4 (v10)Vivek Kasireddy1-0/+6
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
2019-07-01drm/i915: Keep the TypeC port mode fixed when the port is activeImre Deak1-0/+3
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
2019-07-01drm/i915/icl: Reserve all required PLLs for TypeC portsImre Deak1-0/+9
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
2019-07-01drm/i915: Sanitize the shared DPLL reserve/release interfaceImre Deak1-6/+7
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
2019-06-17drm/i915: move modesetting core code under display/Jani Nikula1-0/+351
Now that we have a new subdirectory for display code, continue by moving modesetting core code. display/intel_frontbuffer.h sticks out like a sore thumb, otherwise this is, again, a surprisingly clean operation. v2: - don't move intel_sideband.[ch] (Ville) - use tabs for Makefile file lists and sort them Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Acked-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Acked-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/20190613084416.6794-3-jani.nikula@intel.com
Copyright © 1996 – 2023 Jason A. Donenfeld. All Rights Reverse Engineered.