New DMC releases in linux-firmware will stop using version number in
blob filenames. This new convention provides the following benefits:
1. It simplifies code maintenance, as new DMC releases for a platform
using the new convention will always use the same filename for the
blob.
2. It allows DMC to be loaded even if the target system does not have
the most recent firmware installed.
Prepare the driver by:
- Using the new convention for DMC_PATH() and renaming the currently
used one to make it clear it is for the legacy scheme.
- Implementing a fallback mechanism for future transitions from
versioned to unversioned paths so that we do not cause a regression
for systems not having the most up-to-date linux-firmware files.
v2:
- Keep using request_firmware() instead of firmware_request_nowarn().
(Jani)
v3:
- Keep current DMC paths instead of directly using unversioned ones,
so that we do not disturb initrd generation.
(Lucas, Rodrigo)
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230123182021.31239-2-gustavo.sousa@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
Make sure that PIPEDMCs are enabled whenever the corresponding pipe is
enabled.
This is required at least by the latest ADLP v2.18 firmware, which adds
a new handler enabled by default and running whenever the pipe is
enabled at the vertical referesh rate.
Bspec: 50344, 67620
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Tested-by: Gustavo Sousa <gustavo.sousa@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230102183324.862279-1-imre.deak@intel.com
Declutter i915_drv.h. If there's ever a need to use this in more than
one place, we can figure out a better spot then. For now, this seems
easiest.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Acked-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Acked-by: Nirmoy Das <nirmoy.das@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230118131538.3558599-2-jani.nikula@intel.com
Convert function i9xx_pipe_crc_auto_source() to return void instead
of int since the current implementation always returns 0 to the caller.
Issue identified using returnvar Coccinelle semantic patch.
$ make coccicheck COCCI=scripts/coccinelle/misc/returnvar.cocci \
M=drivers/gpu/drm/i915/
Signed-off-by: Deepak R Varma <drv@mailo.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/Y8K2SS/zNiPAmLsS@ubun2204.myguest.virtualbox.org
Move the display related members to the struct drm_i915_private display
sub-struct. Put them under "state", as they are related to storing
values that aren't readable from the hardware, to appease the state
checker.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230117143946.2426043-3-jani.nikula@intel.com
Since commit 52c4d11f1d ("resource: Convert DEFINE_RES_NAMED() to be
compound literal") it's no longer necessary to cast DEFINE_RES_MEM() to
struct resource.
This also fixes sparse warnings "cast from non-scalar" and "cast to
non-scalar".
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230116173422.1858527-2-jani.nikula@intel.com
Add intel_de_read64_2x32() wrapper for the uncore version of the same,
and use it to read the high and low frame registers. Avoid duplicating
code for existing helpers.
The slight functional difference is checking that the entire high
register remains the same across two reads, instead of just the part
we're interested in. This should be of no consequence. (Unless those
bits function as a PRNG.)
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
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/33853549adff82045b95af527e14cfdff5712470.1673873708.git.jani.nikula@intel.com
Add 4th pipe and extend TGL Wa_16013835468 to support ADLP, MTL and
DG2 and all TGL steppings.
BSpec: 54369, 55378, 66624
v3:
- commit message modified
v2:
- apply for PSR1 as well
- remove stepping information from comments
Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: José Roberto de Souza <jose.souza@intel.com>
Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Signed-off-by: Mika Kahola <mika.kahola@intel.com>
Signed-off-by: Jouni Högander <jouni.hogander@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230105065637.2063311-1-jouni.hogander@intel.com
Using DEFINE_SIMPLE_ATTRIBUTE macro with the debugfs_create_file()
function adds the overhead of introducing a proxy file operation
functions to wrap the original read/write inside file removal protection
functions. This adds significant overhead in terms of introducing and
managing the proxy factory file operations structure and function
wrapping at runtime.
As a replacement, a combination of DEFINE_DEBUGFS_ATTRIBUTE macro paired
with debugfs_create_file_unsafe() is suggested to be used instead. The
DEFINE_DEBUGFS_ATTRIBUTE utilises debugfs_file_get() and
debugfs_file_put() wrappers to protect the original read and write
function calls for the debug attributes. There is no need for any
runtime proxy file operations to be managed by the debugfs core.
Following coccicheck make command helped identify this change:
make coccicheck M=drivers/gpu/drm/i915/ MODE=patch COCCI=./scripts/coccinelle/api/debugfs/debugfs_simple_attr.cocci
Signed-off-by: Deepak R Varma <drv@mailo.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/5d26e924ec8dea21925c77fa79a2bf2a34cef705.1673451705.git.drv@mailo.com
Using DEFINE_SIMPLE_ATTRIBUTE macro with the debugfs_create_file()
function adds the overhead of introducing a proxy file operation
functions to wrap the original read/write inside file removal protection
functions. This adds significant overhead in terms of introducing and
managing the proxy factory file operations structure and function
wrapping at runtime.
As a replacement, a combination of DEFINE_DEBUGFS_ATTRIBUTE macro paired
with debugfs_create_file_unsafe() is suggested to be used instead. The
DEFINE_DEBUGFS_ATTRIBUTE utilises debugfs_file_get() and
debugfs_file_put() wrappers to protect the original read and write
function calls for the debug attributes. There is no need for any
runtime proxy file operations to be managed by the debugfs core.
Following coccicheck make command helped identify this change:
make coccicheck M=drivers/gpu/drm/i915/ MODE=patch COCCI=./scripts/coccinelle/api/debugfs/debugfs_simple_attr.cocci
Signed-off-by: Deepak R Varma <drv@mailo.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/9e08dd1b5fabf3e4f54dda27dd1d6ea1dbe6c542.1673451705.git.drv@mailo.com
The caller should more or less know how many DSB commands it
wants to emit into the command buffer, so allow it to specify
the size of the command buffer rather than having the low level
DSB code guess it.
Technically we can emit as many as 134+1033 (for adl+ degamma +
10bit gamma) register writes but thanks to the DSB indexed register
write command we get significant space savings so the current size
estimate of 8KiB (~1024 DSB commands) is sufficient for now.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221216003810.13338-11-ville.syrjala@linux.intel.com
Reviewed-by: Animesh Manna <animesh.manna@intel.com>
The DSB indexed register write insturction is purely an internal
DSB implementation detail, no reason why the caller should have to
know about it. So let's just have the caller emit blind register
writes let the DSB code convert things to an indexed write if/when
multiple writes occur to the same register offset in a row.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221216003810.13338-9-ville.syrjala@linux.intel.com
Reviewed-by: Animesh Manna <animesh.manna@intel.com>
Currently intel_dsb_indexed_reg_write() just assumes the previous
instructions is also an indexed register write, and thus only
checks the register offset. Make the check more robust by
actually checking the instruction opcode as well.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221216003810.13338-8-ville.syrjala@linux.intel.com
Reviewed-by: Animesh Manna <animesh.manna@intel.com>
free_pos is in dwords, DSB_BUF_SIZE in bytes. Directly
comparing the two is nonsense. Fix it up, and make sure
we also account for the 8byte alignment requirement for
each instruction, and also assume that each instruction
normally eats two dwords.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221216003810.13338-5-ville.syrjala@linux.intel.com
Reviewed-by: Animesh Manna <animesh.manna@intel.com>
Every DSB instruction has to be 8byte aligned. Make sure
that is the case for the non-indexed register writes as well.
The way this could end up unaligned is we emitted an odd
number of indexed register writes beforehand.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221216003810.13338-4-ville.syrjala@linux.intel.com
Reviewed-by: Animesh Manna <animesh.manna@intel.com>
Defeature Display Interlace support.
Support for interlace modes is removed from Gen 12 onwards.
Pruning the interlace modes for HDMI for Display >=12.
Bspec: 50490
v2: Add check for both DP and HDMI. (Ville)
Get rid of redundant check for interlace mode in modevalid. (Ville)
v3: Simplify the condition to avoid interlace modes. (Jani)
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Uma Shankar <uma.shankar@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230105124125.1129653-1-ankit.k.nautiyal@intel.com
Since the DP/HDMI connector do not set connector->doublescan_allowed,
the doublescan modes will get automatically filtered during
drm_helper_probe_single_connector_modes().
Therefore check for double scan modes is not required and is dropped
from modevalid functions for both DP and HDMI.
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Uma Shankar <uma.shankar@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221017143038.1748319-2-ankit.k.nautiyal@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
In newer hardware versions (i.e. display version >= 14), the second
scaler doesn't support vertical scaling.
The current implementation of the scaling limits is simplified and
only occurs when the planes are created, so we don't know which scaler
is being used.
In order to handle separate scaling limits for horizontal and vertical
scaling, and different limits per scaler, split the checks in two
phases. We first do a simple check during plane creation and use the
best-case scenario (because we don't know the scaler that may be used
at a later point) and then do a more specific check when the scalers
are actually being set up.
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-2-luciano.coelho@intel.com
There are new cases where we want to block i915 probe, such
as when experimenting or developing the new Xe driver.
But also, with the new hybrid cards, users or developers might
want to use i915 only on integrated and fully block the probe
of the i915 for the discrete. Or vice versa.
There are even older development and validation reasons,
like when you use some distro where the modprobe.blacklist is
not present.
But in any case, let's introduce a more granular control, but without
introducing yet another parameter, but using the existent force_probe
one.
Just by adding a ! in the begin of the id in the force_probe, like
in this case where we would block the probe for Alder Lake:
$ insmod i915.ko force_probe='!46a6'
v2: Take care of '*' and '!*' cases as pointed out by
Gustavo and Jani.
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Gustavo Sousa <gustavo.sousa@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Acked-by: Gustavo Sousa <gustavo.sousa@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230103194701.1492984-1-rodrigo.vivi@intel.com
The busy timeout logic checks for the AUX BUSY, then waits for the
timeout period and then after timeout reads the register for BUSY or
Success.
Instead replace interrupt with polling so as to read the AUX CTL
register often before the timeout period. Looks like there might be some
issue with interrupt-on-read. Hence changing the logic to polling read.
v2: replace interrupt with polling read
v3: use usleep_rang instead of msleep, updated commit msg
v4: use intel_wait_for_regiter internal function
v5: use __intel_de_wait_for_register with 500us slow and 10ms fast timeout
v6: check return value of __intel_de_wait_for_register
v7: using default 2us for intel_de_wait_for_register
Signed-off-by: Arun R Murthy <arun.r.murthy@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221221033209.1284435-1-arun.r.murthy@intel.com
Currently, i915 interacts with the Hardware and not with any DMC
ABI/API, so the API is fixed within the platform, hence no need to get
this so-tied version requirement.
v2:
- Use link to firmware guide from kernel documentation for
"References:" instead of mailing list thread. (Rodrigo)
- Provide a more elaborate justification in the commit message.
(Rodrigo)
References: https://www.kernel.org/doc/html/v6.1/driver-api/firmware/firmware-usage-guidelines.html
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221230182422.29680-2-gustavo.sousa@intel.com
