This is a scripted split of the display related register macros from
i915_reg.h to display/intel_display_regs.h. As a starting point, move
all the macros that are only used in display code (or GVT). If there are
users in core i915 code or soc/, or no users anywhere, keep the macros
in i915_reg.h. This is done in groups of macros separated by blank
lines, moving the comments along with the groups.
Some manually picked macro groups are kept/moved regardless of the
heuristics above.
This is obviously a very crude approach. It's not perfect. But there are
4.2k lines in i915_reg.h, and its refactoring has ground to a halt. This
is the big hammer that splits the file to two, and enables further
cleanup.
Cc: Suraj Kandpal <suraj.kandpal@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> # v2
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://lore.kernel.org/r/20250606102256.2080073-1-jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Rename intel_shared_dpll to intel_dpll to represent both
shared and individual dplls. Since from MTL each PHY has it's
own PLL making the shared PLL naming a little outdated. In an
effort to make this framework accepting of future changes this
needs to be done.
--v2
-Use intel_dpll_global to make sure names start with the filename
[Jani/Ville]
-Explain the need of this rename [Jani]
--v3
-Just keep it intel_dpll [Jani]
--v4
-Fix comment [Jani]
-Use just num_dpll and dplls [Jani]
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://lore.kernel.org/r/20250515071801.2221120-7-suraj.kandpal@intel.com
Rename the macro for_each_shared_dpll to for_each_dpll since
this loop will not necessarily be used for only shared
dpll in future.
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://lore.kernel.org/r/20250515071801.2221120-5-suraj.kandpal@intel.com
Now that INTEL_PCH_TYPE() and HAS_PCH_*() macros are under display, and
accept a struct intel_display pointer, use that instead of struct
drm_i915_private pointer in display code.
This is done naively by running:
$ sed -i 's/\(INTEL_PCH_TYPE\|HAS_PCH_[A-Z0-9_-]*\)([^)]*)/\1(display)/g' \
$(find drivers/gpu/drm/i915/display -name "*.c")
and fixing the fallout, i.e. removing unused local i915 variables and
adding display variables where needed.
v2: Rebase
Reviewed-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com>
Link: https://lore.kernel.org/r/999f4d7b8ed11739b1c5ec8d6408fc39d5e3776b.1744880985.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Change the argument of for_each_shared_dpll to take intel_display which
helps move as an ongoing effort to get rid off the dependency on
drm_i915_private. Some opportunistic changes in intel_pch_refclk done
too.
--v2
-Prefer using &i915->display [Jani]
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250212074542.3569452-3-suraj.kandpal@intel.com
Add to_intel_uncore() function to avoid the inclusion of i915_drv.h from
intel_de.h. This reveals a number of implicit dependencies on i915_drv.h
that need to be added.
For now, to_intel_uncore() can be an inline function, with all the
includes in compat intel_uncore.h, as long as i915_drv.h isn't
included. The implicit dependencies on i915_drv.h is a problem in
display code, but the same is not true for xe_device.h etc.
Reviewed-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/377e2b400d126776224fc49874ed9cb03ac3123c.1732104170.git.jani.nikula@intel.com
No one really cares how we store the shared_dplls. Currently
it happens to be an array, but we could change that to a more
flexible scheme at some point. Hide the implementation details
behind an iterator macro.
The slight downside is the pll variable moving out of the
loop scope, but maybe someday soon we'll start to convert
everything over to having declarations within for-statements...
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20231003200620.11633-4-ville.syrjala@linux.intel.com
There's no good reason to keep around this PLL index == PLL ID
footgun. Get rid of it.
Both i915->shared_dplls[] and state->shared_dpll[] are indexed
by the same thing now, which is just the index we get at
initialization from dpll_mgr->dpll_info[]. The rest is all about
PLL IDs now.
v2: Add pll->index to mimic drm_crtc & co.
Remove the comment saying ID should match the index
v3: s/i/pll->index/ in debugfs loop (Jani)
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20231003200620.11633-2-ville.syrjala@linux.intel.com
Turns out many of the files that need i915_reg.h get it implicitly via
{display/intel_de.h, gt/intel_context.h} -> i915_trace.h -> i915_irq.h
-> i915_reg.h. Since i915_trace.h doesn't actually need i915_irq.h,
makes sense to drop it, but that requires adding quite a few new
includes all over the place.
Prefer including i915_reg.h where needed instead of adding another
implicit include, because eventually we'll want to split up i915_reg.h
and only include the specific registers at each place.
Also some places actually needed i915_irq.h too.
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/6e78a2e0ac1bffaf5af3b5ccc21dff05e6518cef.1668008071.git.jani.nikula@intel.com
Fill port_clock and hw.adjusted_mode.crtc_clock with the actual
frequency we're going to be getting from the hardware. This will
let us accurately compute all derived state that depends on those.
v2: Reintroduce iCLKIP WARN
v3: Try to deal with VLV/BXT DSI PLL as well
Reviewed-by: Jani Nikula <jani.nikula@intel.com> #v1
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220907091057.11572-8-ville.syrjala@linux.intel.com
The WARN shouldn't have been added yet. For the moment the
clock that gets passed here is just what the user has requested
(via the modeline) and may not be exactly what iCLKIP can
generate.
Later on the plan is to change things so that we already get
passed the exact clock here, at which point the WARN should
be reintroduced.
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6246
Fixes: 97708335b0 ("drm/i915: Introduce struct iclkip_params")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220616095530.15024-1-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Pull the various iCLKIP parameters into a struct. Later on
we'll reuse this during the state computation to determine
the exact dotclock the hardware will be generating for us.
v2: Don't lose the phaseinc calculation
v3: Drop the misplaced '#include <intel_pch_refclk.h>' from intel_crt.c (Jani)
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220504212109.26369-1-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Move the PCH refclk stuff (including all the LPT/WPT
iCLKIP/CLKOUT_DP things) to its own file.
We also suck in the mPHY programming from intel_fdi.c
since we're the only caller.
Cc: Dave Airlie <airlied@redhat.com>
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/20211015071625.593-2-ville.syrjala@linux.intel.com
Reviewed-by: Dave Airlie <airlied@redhat.com>
