Currently our crtcs are registered in pipe order, and thus
all the for_intel_crtc*() iterators walk the crtcs in pipe
order. There are a bunch of places that more or less depend
on that. Eg. during plane updates and such we want joined
pipes to be processed back-to-back to give a better chance
of an atomic update across the whole set.
When we start to register crtcs in a different order we don't
want to change the order in which the pipes get handled.
Decouple the for_each_intel_crtc*() iterators from the crtc
registration order by using a separate list which will be
sorted by the pipe rather than the crtc index.
We could probably use a simple array or something, but that
would require some kind of extra iterator variable for the
macros, and thus would require a lot more changes. Using
a linked list keeps the fallout minimal. We can look at
using a more optimal data structure later.
I also added this extra junk to the atomic state iterators:
"(__i) = drm_crtc_index(&(crtc)->base), (void)(__i)"
even though the macro itself no longer needs the "__i" iterator.
This in case the "__i" is used by the caller, and to
avoid compiler warnings if it's completely unused now.
v2: Flip the pipe comparison (Jani)
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260408155744.13326-3-ville.syrjala@linux.intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Add upper limit check for pixel clock for DISPLAY_VER >= 30.
Limits don't apply when DSC is enabled.
The helper returns the upper limit for the platforms, capped to the
max dotclock (khz).
For the currently supported versions of HDMI, pixel clock is already
limited to 600Mhz so nothing needs to be done there as of now.
v2:
- Add this limit to the new helper.
v3:
- Rename helper to intel_max_uncompressed_dotclock(). (Imre)
- Limit only for PTL and cap the limit to max_dotclock. (Imre)
BSpec: 49199, 68912
Signed-off-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com>
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20260202103731.357416-17-ankit.k.nautiyal@intel.com
Move enum aux_ch from intel_display.h to intel_display_limits.h to avoid
having to include the former from gvt. This currently happens via
intel_display_types.h, which we can also drop in favour of
intel_display_limits.h in intel_gvt_mmio_table.c.
Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://patch.msgid.link/86ccc91ee1ca96fa145b750e2f1935918ec288d0.1769612208.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
intel_port_to_tc() returns the PORT_TC1..6 -> TC_PORT_1..6 mapping only
for DDI ports that are connected to a TypeC PHY. In some cases this
mapping is also required for TypeC DDI ports which are not connected to
a TypeC PHY. Such DDI ports are the PORT_TC1..4 ports on RKL/ADLS/BMG.
Add a separate intel_tc_phy_to_tc() helper to return the mapping for
ports connected to a TypeC PHY, and make all the current users - which
expect this semantic - call this helper. A follow-up change will need to
get the same mapping for TypeC DDI ports not connected to a TypeC PHY,
leave intel_port_to_tc() exported for that.
Cc: Suraj Kandpal <suraj.kandpal@intel.com>
Cc: Mika Kahola <mika.kahola@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20251120172358.1282765-2-imre.deak@intel.com
Pass the format info into plane->max_stride() from the
caller instead of doing yet another drm_format_info()
lookup on the spot.
drm_format_info() is both rather expensive, and technically
incorrect since it doesn't return the correct format info
for compressed formats (though that doesn't actually matter
for the current .max_stride() implementations since they
are just interested in the cpp value).
Most callers already have the format info available. The
only exception is intel_dumb_fb_max_stride() where we shall
use the actually correct drm_get_format_info() variant.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20251107181126.5743-3-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Wrap intel_plane_fb_max_stride() in intel_dumb_fb_max_stride()
for the purposes of dumb fb creation. I want to change
intel_plane_fb_max_stride() to take a 'struct drm_format_info'
instead of the 'u32 pixel_format' so we need an excplicit format
info lookup in the dumb fb path and I don't really want to have
that in i915_gem_dumb_create() directly.
This makes intel_plane_fb_max_stride() internal to the display
code again, and thus we can pass in struct intel_display instead
of struct drm_device.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20251107181126.5743-2-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Add intel_calc_enabled_pipes() as the counterpart to
intel_calc_active_pipes(). We have some uses where the set
of logically enabled pipes makes more sense than the set of
active pipes.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250923171943.7319-18-ville.syrjala@linux.intel.com
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
With vlv_clock_get_czclk() caching the result on first use, we no longer
need a separate initializer. Remove intel_update_czclk() as
unnecessary. Log the CZCLK in vlv_clock_get_czclk() instead.
v2: Rebase
Reviewed-by: Michał Grzelak <michal.grzelak@intel.com> # v1
Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://lore.kernel.org/r/3f90b5e67258f485db09b6f48381682cbd96153f.1757688216.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Add vlv_clock_get_cdclk() helper to hide the details from the callers.
For now, this means running vlv_get_hpll_vco() twice in vlv_get_cdclk(),
but this will be improved later.
v2: Rebase
Reviewed-by: Michał Grzelak <michal.grzelak@intel.com>
Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://lore.kernel.org/r/fc93ccf998300048432d18ce7e8690bd54e1e18d.1757688216.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
With users both in i915 core and display, struct drm_device is the
common denominator for the VLV IOSF SB users. Also use drm_device for
the helpers on the display side to keep the static inlines as simple as
possible.
We can drop a number of dependencies on i915_drv.h with this.
v2,v3: Rebase
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://lore.kernel.org/r/c1d013ed88ce2e3e5bdc15ce3bf01a3960b1e817.1747061743.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Factor out helpers that can be used in a follow-up change to query the
minimum and maximum pipe bpp supported by the HW.
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://lore.kernel.org/r/20250509180340.554867-10-imre.deak@intel.com
Move intel_fb_xy_to_linear() and intel_add_fb_offsets()
These are technially sitting somewhere between plane vs. fb code,
but we do have a bunch of code like that in intel_fb.c anyway.
Might need to think about splitting intel_fb.c into pure fb vs.
plane->fb related stuff somehow, but dunno if that's even feasible.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250213150220.13580-12-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Move intel_{rotation,remapped}_info_size() into intel_fb.c as
that seems a slightly better place than intel_display.c. I suppose
these should live somewhere outside the display code as they are
also used by the gem code.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250213150220.13580-11-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
While vlv_wait_port_ready() doens't directly talk to the VLV/CHV
DPIO PHY, the signals it's looking for do come from the PHY. So
it seems appropriate to relocate it into intel_dpio_phy.c.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250213150220.13580-8-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Going forward, struct intel_display is the main display device data
pointer. Convert as much as possible of intel_combo_phy.[ch] to struct
intel_display, along with intel_phy_is_combo() in intel_display.c.
Drive-by convert some drm_dbg() to drm_dbg_kms() while at it.
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/c2e0a6294a8eaa4c16632881edc4f2d23c576101.1739378096.git.jani.nikula@intel.com
Pass the device argument as drm_device to intel_plane_fb_max_stride()
to decouple i915_gem_dumb_create() vs. the display code a bit.
xe currently doesn't even call this, but it probably should...
v2: s/dev/drm/ (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/20250206185533.32306-3-ville.syrjala@linux.intel.com
Now that intel_scanout_needs_vtd_wa() is no longer used from
the gem code we can convert it to take struct intel_display.
which will help with converting the low level plane code over
as well.
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/20250206185533.32306-2-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
struct intel_display will replace struct drm_i915_private as the main
device pointer for display code. Switch vlv_wait_port_ready() over to
it. The main motivation to do just one function is to stop passing i915
to intel_de_wait(), so its generic wrapper can be removed.
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/9505ea49dfc8c7a52cacd2749875a680b01e5bbd.1730146000.git.jani.nikula@intel.com
Convert I915_STATE_WARN() to struct intel_display *, and rename to
INTEL_DISPLAY_STATE_WARN(). Do some minor opportunistic struct
drm_i915_private to struct intel_display conversions while at it.
v2: crtc_state may be NULL in intel_connector_verify_state()
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241024162510.2410128-1-jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Add changes to DSC which are required for Ultrajoiner.
v2:
-Use correct helper for setting bits for bigjoiner secondary. (Ankit)
-Use primary/secondary instead of master/slave. (Suraj)
v3: Add the ultrajoiner helpers and use it for setting ultrajoiner
bits (Ankit)
v4: Use num_vdsc_instances *= num_joined_pipes (Ville)
v5: Align the helper to get ultrajoiner enabled pipes with other helpers
(Ville)
Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240930163549.416410-7-ankit.k.nautiyal@intel.com
Joiners have specific enabling and disabling order dependent on primary
and secondary pipes. This becomes more complex with ultrajoiner where we
have ultrajoiner primary/secondary pipes in addition to bigjoiner
primary/secondary pipes. To unify the approach that works for present
and future joiner cases, use primary and secondary pipe masks to
iterate over pipes.
If joiner is used, derive bigoiner primary and secondary pipe masks
and use following sequences:
Disabling : disable primary pipes followed by secondary pipes,
Enabling: enable secondary pipes followed by primary pipes.
This works well with ultrajoiner too, as ultrajoiner has 2 bigjoiner
primary/secondary pairs (AC, BD).
For non joiner case, enable/disable based on usual pipe order A-D, D-A
respectively.
v2:
-Simplify the iterator macro. (Ville)
-Use struct intel_display. (Ville)
-Add prefix _intel to the helper name. (Ville)
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240918063016.2667721-3-ankit.k.nautiyal@intel.com
In most of the cases we now try to avoid mentioning things like
"bigjoiner" or "ultrajoiner" trying to unify the API and refer
mostly to all this functionality as "joiner".
In majority cases that should be way to go.
However in some cases we still need to distinguish between
bigjoiner primaries and secondaries(such as DSC register programming).
Create correspondent helper functions and start using them,
in order be prepared for adding ultrajoiner functionality.
v2: Fixed checkpatch warnings (Ankit)
v3: Introduce ultrajoiner helpers in next patch.
v4: Streamline the helpers and add few more. (Ville)
v5: Add comment to clarify that helpers apply to both bigjoiner and
uncompressed joiner configurations. (Ville)
Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240918063016.2667721-2-ankit.k.nautiyal@intel.com
In preparation of ultrajoiner, use number of pipes in the
intel_mode_valid_max_plane_size helper, instead of joiner flag.
v2: Use num_joined_pipes 1 where there are no joined pipes (Ville)
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240916102836.2149012-4-ankit.k.nautiyal@intel.com
In preparation of ultrajoiner, use number of joined pipes in the
intel_dp_joiner_needs_dsc helper, instead of joiner flag.
v2: Use intel_crtc_num_joined_pipes. (Ville)
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240916102836.2149012-3-ankit.k.nautiyal@intel.com
