Backmerging to get the latest fixes from drm-next; specifically the
build fix from the patchset at [1]. Also fixes the build by removing
an unused variable from rzg2l_du_vsp_atomic_flush().
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://patchwork.freedesktop.org/series/130720/ # 1
The hwdb selection logic as a feature that allows it to mark some fields
as 'don't care'. If we match with such a field we memcpy(..)
the current etnaviv_chip_identity into ident.
This step can overwrite some id values read from the GPU with the
'don't care' value.
Fix this issue by restoring the affected values after the memcpy(..).
As this is crucial for user space to know when this feature works as
expected increment the minor version too.
Fixes: 4078a1186d ("drm/etnaviv: update hwdb selection logic")
Cc: stable@vger.kernel.org
Signed-off-by: Christian Gmeiner <cgmeiner@igalia.com>
Reviewed-by: Tomeu Vizoso <tomeu@tomeuvizoso.net>
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
For a given bridge pipeline if any bridge sets pre_enable_prev_first
flag then the pre_enable for the previous bridge will be called before
pre_enable of this bridge and opposite is done for post_disable.
These are the potential bridge flags to alter bridge init order in order
to satisfy the MIPI DSI host and downstream panel or bridge to function.
However the existing pre_enable_prev_first logic with associated bridge
ordering has broken for both pre_enable and post_disable calls.
[pre_enable]
The altered bridge ordering has failed if two consecutive bridges on a
given pipeline enables the pre_enable_prev_first flag.
Example:
- Panel
- Bridge 1
- Bridge 2 pre_enable_prev_first
- Bridge 3
- Bridge 4 pre_enable_prev_first
- Bridge 5 pre_enable_prev_first
- Bridge 6
- Encoder
In this example, Bridge 4 and Bridge 5 have pre_enable_prev_first.
The logic looks for a bridge which enabled pre_enable_prev_first flag
on each iteration and assigned the previou bridge to limit pointer
if the bridge doesn't enable pre_enable_prev_first flags.
If control found Bridge 2 is pre_enable_prev_first then the iteration
looks for Bridge 3 and found it is not pre_enable_prev_first and assigns
it's previous Bridge 4 to limit pointer and calls pre_enable of Bridge 3
and Bridge 2 and assign iter pointer with limit which is Bridge 4.
Here is the actual problem, for the next iteration control look for
Bridge 5 instead of Bridge 4 has iter pointer in previous iteration
moved to Bridge 4 so this iteration skips the Bridge 4. The iteration
found Bridge 6 doesn't pre_enable_prev_first flags so the limit assigned
to Encoder. From next iteration Encoder skips as it is the last bridge
for reverse order pipeline.
So, the resulting pre_enable bridge order would be,
- Panel, Bridge 1, Bridge 3, Bridge 2, Bridge 6, Bridge 5.
This patch fixes this by assigning limit to next pointer instead of
previous bridge since the iteration always looks for bridge that does
NOT request prev so assigning next makes sure the last bridge on a
given iteration what exactly the limit bridge is.
So, the resulting pre_enable bridge order with fix would be,
- Panel, Bridge 1, Bridge 3, Bridge 2, Bridge 6, Bridge 5, Bridge 4,
Encoder.
[post_disable]
The altered bridge ordering has failed if two consecutive bridges on a
given pipeline enables the pre_enable_prev_first flag.
Example:
- Panel
- Bridge 1
- Bridge 2 pre_enable_prev_first
- Bridge 3
- Bridge 4 pre_enable_prev_first
- Bridge 5 pre_enable_prev_first
- Bridge 6
- Encoder
In this example Bridge 5 and Bridge 4 have pre_enable_prev_first.
The logic looks for a bridge which enabled pre_enable_prev_first flags
on each iteration and assigned the previou bridge to next and next to
limit pointer if the bridge does enable pre_enable_prev_first flag.
If control starts from Bridge 6 then it found next Bridge 5 is
pre_enable_prev_first and immediately the next assigned to previous
Bridge 6 and limit assignments to next Bridge 6 and call post_enable
of Bridge 6 even though the next consecutive Bridge 5 is enabled with
pre_enable_prev_first. This clearly misses the logic to find the state
of next conducive bridge as everytime the next and limit assigns
previous bridge if given bridge enabled pre_enable_prev_first.
So, the resulting post_disable bridge order would be,
- Encoder, Bridge 6, Bridge 5, Bridge 4, Bridge 3, Bridge 2, Bridge 1,
Panel.
This patch fixes this by assigning next with previou bridge only if the
bridge doesn't enable pre_enable_prev_first flag and the next further
assign it to limit. This way we can find the bridge that NOT requested
prev to disable last.
So, the resulting pre_enable bridge order with fix would be,
- Encoder, Bridge 4, Bridge 5, Bridge 6, Bridge 2, Bridge 3, Bridge 1,
Panel.
Validated the bridge init ordering by incorporating dummy bridges in
the sun6i-mipi-dsi pipeline
Fixes: 4fb912e5e1 ("drm/bridge: Introduce pre_enable_prev_first to alter bridge init order")
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
Tested-by: Michael Trimarchi <michael@amarulasolutions.com>
Reviewed-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Signed-off-by: Robert Foss <rfoss@kernel.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20230328170752.1102347-1-jagan@amarulasolutions.com
This function does not build on 32-bit targets when the compiler
fails to reduce DIV_ROUND_UP() into a shift:
ld.lld: error: undefined symbol: __aeabi_uldivmod
>>> referenced by xe_migrate.c
>>> drivers/gpu/drm/xe/xe_migrate.o:(pte_update_size) in archive vmlinux.a
There are two instances in this function. Change the first to
use an open-coded shift with the same behavior, and the second
one to a 32-bit calculation, which is sufficient here as the size
is never more than 2^32 pages (16TB).
Fixes: 237412e453 ("drm/xe: Enable 32bits build")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240226124736.1272949-3-arnd@kernel.org
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
(cherry picked from commit 1408784b59)
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
When the driver is built-in but the tests are in loadable modules,
the helpers don't actually get put into the driver:
ERROR: modpost: "xe_kunit_helper_alloc_xe_device" [drivers/gpu/drm/xe/tests/xe_test.ko] undefined!
Change the Makefile to ensure they are always part of the driver
even when the rest of the kunit tests are in loadable modules.
Fixes: 5095d13d75 ("drm/xe/kunit: Define helper functions to allocate fake xe device")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240226124736.1272949-1-arnd@kernel.org
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
(cherry picked from commit 0e6fec6da2)
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
All the components of YUV420 over DP are added. Therefore, let's mark the
connector property as true for DP connector when the DP type is not eDP
and when there is a CDM block available.
Changes in v3:
- Move setting the connector's ycbcr_420_allowed parameter so
that it is not dependent on if the dp_display is not eDP
Changes in v2:
- Check for if dp_catalog has a CDM block available instead of
checking if VSC SDP is allowed when setting the dp connector's
ycbcr_420_allowed parameter
Signed-off-by: Paloma Arellano <quic_parellan@quicinc.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/579628/
Link: https://lore.kernel.org/r/20240222194025.25329-20-quic_parellan@quicinc.com
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Adjust the encoder format programming in the case of video mode for DP
to accommodate CDM related changes.
Changes in v4:
- Remove hw_cdm check in dpu_encoder_needs_periph_flush()
- Remove hw_cdm check when getting the fmt_fourcc in
dpu_encoder_phys_vid_enable()
Changes in v2:
- Move timing engine programming to a separate patch from this
one
- Move update_pending_flush_periph() invocation completely to
this patch
- Change the logic of dpu_encoder_get_drm_fmt() so that it only
calls drm_mode_is_420_only() instead of doing additional
unnecessary checks
- Create new functions msm_dp_needs_periph_flush() and it's
supporting function dpu_encoder_needs_periph_flush() to check
if the mode is YUV420 and VSC SDP is enabled before doing a
peripheral flush
Signed-off-by: Paloma Arellano <quic_parellan@quicinc.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/579641/
Link: https://lore.kernel.org/r/20240222194025.25329-17-quic_parellan@quicinc.com
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
DP controller can be setup to operate in either SDP update flush mode or
peripheral flush mode based on the DP controller hardware version.
Starting in DP v1.2, the hardware documents require the use of
peripheral flush mode for SDP packets such as PPS OR VSC SDP packets.
In-line with this guidance, lets program the DP controller to use
peripheral flush mode starting DP v1.2
Changes in v4:
- Clear up that DP_MAINLINK_CTRL_FLUSH_MODE register requires
the use of bits [24:23]
- Modify macros DP_MAINLINK_FLUSH_MODE_UPDATE_SDP and
DP_MAINLINK_FLUSH_MODE_SDP_PERIPH_UPDATE to explicitly set
their values in the bits of DP_MAINLINK_CTRL_FLUSH_MODE_MASK
Changes in v3:
- Clear up that the DP_MAINLINK_FLUSH_MODE_SDE_PERIPH_UPDATE
macro is setting bits [24:23] to a value of 3
Changes in v2:
- Use the original dp_catalog_hw_revision() function to
correctly check the DP HW version
Signed-off-by: Paloma Arellano <quic_parellan@quicinc.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/579621/
Link: https://lore.kernel.org/r/20240222194025.25329-16-quic_parellan@quicinc.com
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Add support to pack and send the VSC SDP packet for DP. This therefore
allows the transmision of format information to the sinks which is
needed for YUV420 support over DP.
Changes in v5:
- Slightly modify use of drm_dp_vsc_sdp_pack()
- Remove dp_catalog NULL checks
- Modify dp_utils_pack_sdp_header() to more clearly pack the
header buffer
- Move dp_utils_pack_sdp_header() inside of
dp_catalog_panel_send_vsc_sdp to clearly show the relationship
between the header buffer and the vsc_sdp struct
- Due to the last point, remove the dp_utils_pack_vsc_sdp()
function and only call drm_dp_vsc_sdp_pack() in
dp_panel_setup_vsc_sdp_yuv_420()
Changes in v4:
- Remove struct msm_dp_sdp_with_parity
- Use dp_utils_pack_sdp_header() to pack the SDP header and
parity bytes into a buffer
- Use this buffer when writing the VSC SDP data in
dp_catalog_panel_send_vsc_sdp()
- Write to all of the MMSS_DP_GENERIC0 registers instead of just
the ones with non-zero values
Changes in v3:
- Create a new struct, msm_dp_sdp_with_parity, which holds the
packing information for VSC SDP
- Use drm_dp_vsc_sdp_pack() to pack the data into the new
msm_dp_sdp_with_parity struct instead of specifically packing
for YUV420 format
- Modify dp_catalog_panel_send_vsc_sdp() to send the VSC SDP
data using the new msm_dp_sdp_with_parity struct
Changes in v2:
- Rename GENERIC0_SDPSIZE macro to GENERIC0_SDPSIZE_VALID
- Remove dp_sdp from the dp_catalog struct since this data is
being allocated at the point used
- Create a new function in dp_utils to pack the VSC SDP data
into a buffer
- Create a new function that packs the SDP header bytes into a
buffer. This function is made generic so that it can be
utilized by dp_audio
header bytes into a buffer
- Create a new function in dp_utils that takes the packed buffer
and writes to the DP_GENERIC0_* registers
- Split the dp_catalog_panel_config_vsc_sdp() function into two
to disable/enable sending VSC SDP packets
- Check the DP HW version using the original useage of
dp_catalog_hw_revision() and correct the version checking
logic
- Rename dp_panel_setup_vsc_sdp() to
dp_panel_setup_vsc_sdp_yuv_420() to explicitly state that
currently VSC SDP is only being set up to support YUV420 modes
Signed-off-by: Paloma Arellano <quic_parellan@quicinc.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/579636/
Link: https://lore.kernel.org/r/20240222194025.25329-14-quic_parellan@quicinc.com
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
