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>
We always pass 0 in the set argument of skl_scaler_get_filter_select()
calls, so the argument is unnecessary. Remove it.
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com>
Signed-off-by: Mika Kahola <mika.kahola@intel.com>
Link: https://lore.kernel.org/r/20250520082917.1302665-3-luciano.coelho@intel.com
With the PCH macros switched to use struct intel_display, we have a
number of files that no longer need struct drm_i915_private or anything
else from i915_drv.h anymore. Remove the #include, and add the missing
includes that were previously implicit.
v2: Drop even more of the includes
Reviewed-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com>
Link: https://lore.kernel.org/r/5dc9e6a98461c344febac4c645875d8688eba906.1744880985.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
struct intel_display will replace struct drm_i915_private as
the main thing for display code. Convert the skl+ universal plane
code to use it.
Note that we still have two straggles in the form on
HAS_FLAT_CCS() and the pxp stuff.
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-11-ville.syrjala@linux.intel.com
Limit downscaling to less than 1.5 (source/destination) in
the horizontal direction and 1.0 in the vertical direction,
When configured for Pipe YUV 420 encoding for port output.
Bspec: 50441, 7490, 69901
Signed-off-by: Mitul Golani <mitulkumar.ajitkumar.golani@intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250120172209.188488-6-mitulkumar.ajitkumar.golani@intel.com
Compute scaling factors and scaler user for pipe scaler if
particular scaler user is pipe scaler.
--v2:
- Fix typos. [Ankit]
- Remove FIXME tag. [Ankit]
- Should be common hscale, vscale instead of local one to
avoid garbage overwritten.
--v3:
- Separate out max_scaling information. [Ankit]
- Use max_hscale and max_vscale info instead of INT_MAX. [Ankit]
--v4:
- Add Suggested changes reported by Dan Carpenter.
Signed-off-by: Mitul Golani <mitulkumar.ajitkumar.golani@intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250121175856.447245-1-mitulkumar.ajitkumar.golani@intel.com
Pass crtc_state to intel_atomic_setup_scaler, this will help to
check if pch_pfit enabled or not and also will be useful to pass
scaler_state with the same which will be used later to store
hscale and vscale values.
-- v2:
- Fix typos. (Ankit)
Signed-off-by: Mitul Golani <mitulkumar.ajitkumar.golani@intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250120172209.188488-3-mitulkumar.ajitkumar.golani@intel.com
Add scaling factors to scaler_state for a particular scaler user.
These factors will be used later to compute scaler prefill latency.
Currently, only plane scaling factors are stored, but the same members
can later be extended to store pipe scaling factors as well.
--v2:
- Rephrase commit message. [Ankit]
- Corrects typos. [Ankit]
Signed-off-by: Mitul Golani <mitulkumar.ajitkumar.golani@intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250120172209.188488-2-mitulkumar.ajitkumar.golani@intel.com
Fix all typos in files under drm/i915/display reported by codespell tool.
v2:
- Include british and american spelling, as those are
not typos.
- Fix commenting style. <Jani>
v3: Fix "In case" wrongly capitalized and
also fix comment style. <Krzysztof Niemiec>
Signed-off-by: Nitin Gote <nitin.r.gote@intel.com>
Reviewed-by: Krzysztof Niemiec <krzysztof.niemiec@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250120081517.3237326-8-nitin.r.gote@intel.com
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@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
intel_atomic_setup_scalers() is currently messing around with
the internals of the atomic states. Stop doing that and instead
use the regular interfaces so that we don't need to know any ugly
implementation details.
Reviewed-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241107122658.21901-5-ville.syrjala@linux.intel.com
intel_atomic_setup_scalers() currently digs out the full atomic
state from the crtc state. Flip that on its head so that we instead
pass in the full atomic state and dig out the crtc state (and whatever
else we need). This is generallte the better approach as it works
in all phases of the atomic commit, whereas the other apporoach only
really works during .atomic_check().
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/20241107122658.21901-4-ville.syrjala@linux.intel.com
For Earlier platforms, the Pipe source size is 12-bits so
max pipe source width and height is 4096. For newer platforms it is
13-bits so theoretically max width/height is 8192. For few of the
earlier platforms the scaler did not use all bits of the PIPESRC,
so max scaler source size was used to make that the pipe source
size is programmed within limits, before using scaler.
This creates a problem, for MTL where scaler source size is 4096, but
max pipe source width can theroretically be 8192.
Switch the check to use the max scaler destination size, which closely
match the limits.
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/20240313143825.3461208-1-ankit.k.nautiyal@intel.com
Since the plane_state variable is declared outside the scaler_users
loop in intel_atomic_setup_scalers(), and it's never reset back to
NULL inside the loop we may end up calling intel_atomic_setup_scaler()
with a non-NULL plane state for the pipe scaling case. That is bad
because intel_atomic_setup_scaler() determines whether we are doing
plane scaling or pipe scaling based on plane_state!=NULL. The end
result is that we may miscalculate the scaler mode for pipe scaling.
The hardware becomes somewhat upset if we end up in this situation
when scanning out a planar format on a SDR plane. We end up
programming the pipe scaler into planar mode as well, and the
result is a screenfull of garbage.
Fix the situation by making sure we pass the correct plane_state==NULL
when calculating the scaler mode for pipe scaling.
Cc: stable@vger.kernel.org
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20231207193441.20206-2-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Define and use the bitmasks for the x/y components
of the skl+ scaler window pos/size registers.
We stick to the full 16 bits mask here even though the
hardware limits are actually lower. The current (ADL)
hardware maximums are in fact: 14 bits for X size, 13 bits
for X pos, 13 bits for Y size/pos. Yes, that is correct,
X pos has less bits than the X size for some reason. But
that doesn't actually matter for now as we don't currently
even support such wide displays without the use of bigjoiner
(due to max plane width limit).
v2: Switch back to full 16bit masks since that's what
we use transcoder timign regs and PIPESRC 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/20230426135019.7603-6-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
The bspec has been updated and now display versions 12 and 13 support
source width up to 5120 pixels, source height up to 8192 lines,
destination width up to 8192 and destination height up to 8192.
Update the code accordingly.
BSpec: 50441
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230113113905.130405-1-luciano.coelho@intel.com
The max source and destination limits for scalers in MTL have changed.
Use the new values accordingly.
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Animesh Manna <animesh.manna@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221223130509.43245-3-luciano.coelho@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
All the skl+ scaler registers are suitably confined to their own
cachelines so we don't need the uncore.lock to globally serialize
access to these registers. We actually already dropped some of this
in commit 14ad15296d ("drm/i915: Make skl+ universal plane
registers unlocked") as the plane scaler enabling/reconfiguration
became lockless. So let's complete that and remove the rest of
the locks from the scaler programming as well.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220224165103.15682-2-ville.syrjala@linux.intel.com
Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Instead of just having the pipe_src_{w,h} let's use a full
drm_rect for it. This will be particularly useful to astract
away some bigjoiner details.
v2: No hweight() stuff yet
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220223131315.18016-11-ville.syrjala@linux.intel.com
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
Add a table describing all the framebuffer modifiers used by i915 at one
place. This has the benefit of deduplicating the listing of supported
modifiers for each platform and checking the support of these modifiers
on a given plane. This also simplifies in a similar way getting some
attribute for a modifier, for instance checking if the modifier is a
CCS modifier type.
While at it drop the cursor plane filtering from skl_plane_has_rc_ccs(),
as the cursor plane is registered with DRM core elsewhere.
v1: Unchanged.
v2:
- Keep the plane caps calculation in the plane code and pass an enum
with these caps to intel_fb_get_modifiers(). (Ville)
- Get the modifiers calling intel_fb_get_modifiers() in i9xx_plane.c as
well.
v3:
- s/.id/.modifier/ (Ville)
- Keep modifier_desc vs. plane_cap filter conditions consistent. (Ville)
- Drop redundant cursor plane check from skl_plane_has_rc_ccs(). (Ville)
- Use from, until display version fields in modifier_desc instead of a mask. (Jani)
- Unexport struct intel_modifier_desc, separate its decl and init. (Jani)
- Remove enum pipe, plane_id forward decls from intel_fb.h, which are
not needed after v2.
v4:
- Reuse IS_DISPLAY_VER() instead of open-coding it. (Jani)
- Preserve the current modifier order exposed to user space. (Ville)
v5: Use }, { on one line to seperate the descriptor array elements. (Jani)
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> (v3)
Link: https://patchwork.freedesktop.org/patch/msgid/20211020195138.1841242-2-imre.deak@intel.com
Hoist the intel_de.h include from intel_display_types.h one
level up. I need this in order to untangle the include order
so that I can add tracepoints into intel_de.h.
This little cocci script did most of the work for me:
@find@
@@
(
intel_de_read(...)
|
intel_de_read_fw(...)
|
intel_de_write(...)
|
intel_de_write_fw(...)
)
@has_include@
@@
(
#include "intel_de.h"
|
#include "display/intel_de.h"
)
@depends on find && !has_include@
@@
+ #include "intel_de.h"
#include "intel_display_types.h"
@depends on find && !has_include@
@@
+ #include "display/intel_de.h"
#include "display/intel_display_types.h"
Cc: Cooper Chiou <cooper.chiou@intel.com>
Reviewed-by: Anshuman Gupta <anshuman.gupta@intel.com>
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/20210430143945.6776-1-ville.syrjala@linux.intel.com
Use Coccinelle to convert most of the usage of INTEL_GEN() and IS_GEN()
in the display code to use DISPLAY_VER() comparisons instead. The
following semantic patch was used:
@@ expression dev_priv, E; @@
- INTEL_GEN(dev_priv) == E
+ IS_DISPLAY_VER(dev_priv, E)
@@ expression dev_priv; @@
- INTEL_GEN(dev_priv)
+ DISPLAY_VER(dev_priv)
@@ expression dev_priv; expression E; @@
- IS_GEN(dev_priv, E)
+ IS_DISPLAY_VER(dev_priv, E)
@@
expression dev_priv;
expression from, until;
@@
- IS_GEN_RANGE(dev_priv, from, until)
+ IS_DISPLAY_RANGE(dev_priv, from, until)
There are still some display-related uses of INTEL_GEN() in intel_pm.c
(watermark code) and i915_irq.c. Those will be updated separately.
v2:
- Use new IS_DISPLAY_RANGE and IS_DISPLAY_VER helpers. (Jani)
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210320044245.3920043-4-matthew.d.roper@intel.com
This moves the code from various places and consolidates it
into one new file.
v2:
- rename skl_program_plane -> skl_program_plane_scaler (Ville)
- also move skl_pfit_enable, and consequently make some skl_scaler_*
functions static to skl_scaler.c (Ville)
Signed-off-by: Dave Airlie <airlied@redhat.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/2fa703ffc7b96a41c392fd5ebbd2e6e4ffb6fb05.1612536383.git.jani.nikula@intel.com
