Daniel Vetter [Tue, 11 Apr 2023 10:28:09 +0000 (12:28 +0200)]
Merge tag 'mediatek-drm-next-6.4' of https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux into drm-next
Mediatek DRM Next for Linux 6.4
1. Add support for 10-bit overlays
2. Add MediaTek SoC DRM (vdosys1) support for mt8195
3. Change mmsys compatible for mt8195 mediatek-drm
4. Only trigger DRM HPD events if bridge is attached
5. Change the aux retries times when receiving AUX_DEFER
Daniel Vetter [Tue, 11 Apr 2023 10:11:32 +0000 (12:11 +0200)]
Merge tag 'drm-msm-next-2023-04-10' of https://gitlab.freedesktop.org/drm/msm into drm-next
main pull request for v6.4
Core Display:
============
* Bugfixes for error handling during probe
* rework UBWC decoder programming
* prepare_commit cleanup
* bindings for SM8550 (MDSS, DPU), SM8450 (DP)
* timeout calculation fixup
* atomic: use drm_crtc_next_vblank_start() instead of our own
custom thing to calculate the start of next vblank
DP:
==
* interrupts cleanup
DPU:
===
* DSPP sub-block flush on sc7280
* support AR30 in addition to XR30 format
* Allow using REC_0 and REC_1 to handle wide (4k) RGB planes
* Split the HW catalog into individual per-SoC files
DSI:
===
* rework DSI instance ID detection on obscure platforms
GPU:
===
* uapi C++ compatibility fix
* a6xx: More robust gdsc reset
* a3xx and a4xx devfreq support
* update generated headers
* various cleanups and fixes
* GPU and GEM updates to avoid allocations which could trigger
reclaim (shrinker) in fence signaling path
* dma-fence deadline hint support and wait-boost
* a640 speedbin support
* a650 speedbin support
Conflicts in drivers/gpu/drm/msm/adreno/adreno_gpu.c:
Conflict between the 7fa5047a436b ("drm: Use of_property_present() for
testing DT property presence") and 9f251f934012 ("drm/msm/adreno: Use
OPP for every GPU generation"). The latter removed the of_ function
call outright, so I went with what's in the PR unchanged.
Daniel Vetter [Tue, 11 Apr 2023 10:02:38 +0000 (12:02 +0200)]
Merge tag 'drm-habanalabs-next-2023-04-10' of https://git.kernel.org/pub/scm/linux/kernel/git/ogabbay/linux into drm-next
This tag contains additional habanalabs driver changes for v6.4:
- uAPI changes:
- Add a definition of a new Gaudi2 server type. This is used by userspace
to know what is the connectivity between the accelerators inside the
server
- New features and improvements:
- speedup h/w queues test in Gaudi2 to reduce device initialization times.
- Firmware related fixes:
- Fixes to the handshake protocol during f/w initialization.
- Sync f/w events interrupt in hard reset to avoid warning message.
- Improvements to extraction of the firmware version.
- Misc bug fixes and code cleanups. Notable fixes are:
- Multiple fixes for interrupt handling in Gaudi2.
- Unmap mapped memory in case TLB invalidation fails.
accel/habanalabs: add missing error flow in hl_sysfs_init()
hl_sysfs_fini() is called only if hl_sysfs_init() completes
successfully. Therefore if hl_sysfs_init() fails, need to remove any
sysfs group that was added until that point.
Moti Haimovski [Mon, 20 Mar 2023 20:59:11 +0000 (22:59 +0200)]
accel/habanalabs: speedup h/w queues test in Gaudi2
HW queues testing at driver load and after reset takes a substantial
amount of time.
This commit reduces the queues test time in Gaudi2 devices by running
all the tests in parallel instead of one after the other.
Time measurements on tests duration shows that the new method is almost
x100 faster than the serial approach.
Dani Liberman [Tue, 28 Mar 2023 17:41:35 +0000 (20:41 +0300)]
accel/habanalabs: fix handling of arc farm sei event
There is only single eq entry for arc farm sei event which aggregates
events from the four arc farms.
Fix the code to handle this event according to this behavior.
Ofir Bitton [Mon, 27 Mar 2023 10:40:56 +0000 (13:40 +0300)]
accel/habanalabs: remove Gaudi1 multi MSI code
Multi MSI interrupts aren't working in Gaudi1 and because of that,
we are only using a single MSI interrupt. Therefore, let's remove this
dead code in order to avoid confusion.
Koby Elbaz [Sun, 26 Mar 2023 15:22:57 +0000 (18:22 +0300)]
accel/habanalabs: don't wait for STS_OK after sending COMMS WFE
Sending COMMS_GOTO_WFE instructs the FW's CPU to halt (WFE state).
Once sent, FW's CPU isn't expected to continue communicating with LKD.
Therefore, the stage of waiting for COMMS_STS_OK should be skipped or
else waiting for COMMS_STS_OK will simply timeout, which will trigger
unexpected behavior.
Tal Cohen [Tue, 21 Mar 2023 08:59:28 +0000 (10:59 +0200)]
accel/habanalabs: sync f/w events interrupt in hard reset
Receiving events from FW, while the device is in hard reset, causes
a warning message in Driver log. The message may point to a
problem in the Driver or FW. But It also can appear as a result
of events that have been sent from FW just before the hard reset.
In order to avoid receiving events from FW while the device is in reset
and is already in 'disabled' mode, sync the f/w events interrupt right
before setting the device to 'disabled'.
Tomer Tayar [Sun, 26 Mar 2023 21:08:45 +0000 (00:08 +0300)]
accel/habanalabs: fix events mask of decoder abnormal interrupts
The decoder IRQ status register may have several set bits upon an
abnormal interrupt. Therefore, when setting the events mask, need to
check all bits and not using if-else.
Ofir Bitton [Wed, 15 Mar 2023 08:36:41 +0000 (10:36 +0200)]
accel/habanalabs: fix HBM MMU interrupt handling
Current mapping between HMMU event and HMMU block is wrong.
In addition the captured address in case of a page fault or
an access error is scrambled, Hence we must call the descramble
function.
Tal Cohen [Wed, 22 Mar 2023 09:20:05 +0000 (11:20 +0200)]
accel/habanalabs: send disable pci when compute ctx is active
Fix an issue in hard reset flow in which the driver didn't send a
disable pci message if there was an active compute context.
In hard reset, disable pci message should be sent no matter if
a compute context exists or not.
The disable pci message is sent in reset device. It informs the FW not
to raise more EQs. The Driver may ignore received EQs, when the device
is in disabled mode.
The duplication happens when hard reset is scheduled during compute
reset and also performs 'escalate_reset_flow'.
Koby Elbaz [Tue, 21 Mar 2023 14:03:07 +0000 (16:03 +0200)]
accel/habanalabs: change COMMS warning messages to error level
COMMS protocol is used for LKD <--> FW communication, and any
communication failure between the two might turn out to be
destructive, hence, it should be well emphasized.
Tal Cohen [Thu, 16 Mar 2023 15:30:46 +0000 (17:30 +0200)]
accel/habanalabs: print event type when device is disabled
When the device is in disabled state, the driver isn't suppose to
receive any events from FW. Printing the event type, as part of the
message that was already printed, shall help to get more info if this
unexpected message is received.
Koby Elbaz [Wed, 8 Mar 2023 15:53:39 +0000 (17:53 +0200)]
accel/habanalabs: unmap mapped memory when TLB inv fails
Once a memory mapping is added to the page tables, it's followed by
a TLB invalidation request which could potentially fail (HW failure).
Removing the mapping is simply a part of this failure handling routine.
TLB invalidation failure prints were updated to be more accurate.
Remove pci_clear_master to simplify the code,
the bus-mastering is also cleared in do_pci_disable_device,
like this:
./drivers/pci/pci.c:2197
static void do_pci_disable_device(struct pci_dev *dev)
{
u16 pci_command;
drm/i915: disable sampler indirect state in bindless heap
By default the indirect state sampler data (border colors) are stored
in the same heap as the SAMPLER_STATE structure. For userspace drivers
that can be 2 different heaps (dynamic state heap & bindless sampler
state heap). This means that border colors have to copied in 2
different places so that the same SAMPLER_STATE structure find the
right data.
This change is forcing the indirect state sampler data to only be in
the dynamic state pool (more convenient for userspace drivers, they
only have to have one copy of the border colors). This is reproducing
the behavior of the Windows drivers.
drm/msm/dpu: fetch DPU configuration from match data
In email discussion it was noted that there can be different SoC device
having slightly different SoC features, but sharing the same DPU hw
revision. Stop fetching catalog data using core_rev and use platform's
match data instead.
For sm8150+ the DPU_CTL_SPLIT_DISPLAY should be replaced with
DPU_CTL_ACTIVE_CFG support (which supports having a single CTL for both
interfaces in a split). Add comments where this conversion is required.
drm/msm/dpu: move UBWC/memory configuration to separate struct
UBWC and highest bank settings differ slightly between different DPU
units of the same generation, while the dpu_caps and dpu_mdp_cfg are
much more stable. To ease configuration reuse move ubwc_swizzle and
highest_bank_bit data to separate structure.
Konrad Dybcio [Tue, 4 Apr 2023 13:05:43 +0000 (16:05 +0300)]
drm/msm/dpu: Allow variable INTF_BLK size
These blocks are of variable length on different SoCs. Set the
correct values where I was able to retrieve it from downstream
DTs and leave the old defaults (0x280) otherwise.
Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
[DB: fixed some lengths, split the INTF changes away] Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
Patchwork: https://patchwork.freedesktop.org/patch/530816/ Link: https://lore.kernel.org/r/20230404130622.509628-4-dmitry.baryshkov@linaro.org Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Konrad Dybcio [Tue, 4 Apr 2023 13:05:42 +0000 (16:05 +0300)]
drm/msm/dpu: Allow variable SSPP_BLK size
These blocks are of variable length on different SoCs. Set the
correct values where I was able to retrieve it from downstream
DTs and leave the old defaults (0x1c8) otherwise.
Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
[DB: fixed some of lengths, split the INTF changes away] Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/530814/ Link: https://lore.kernel.org/r/20230404130622.509628-3-dmitry.baryshkov@linaro.org Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Konrad Dybcio [Sat, 18 Mar 2023 13:42:52 +0000 (14:42 +0100)]
drm/msm/dsi: Switch the QCM2290-specific compatible to index autodetection
Now that the logic can handle multiple sets of registers, move
the QCM2290 to the common logic and mark it deprecated. This allows us
to remove a couple of structs, saving some memory.
Konrad Dybcio [Sat, 18 Mar 2023 13:42:51 +0000 (14:42 +0100)]
drm/msm/dsi: dsi_cfg: Merge SC7180 config into SDM845
The configs are identical, other than the number of *maximum* DSI
hosts allowed. This isn't an issue, unless somebody deliberately
tries to access the inexistent host by adding a dt node for it.
Remove the SC7180 struct and point the hw revision match to the
SDM845's one. On a note, this could have been done back when
7180 support was introduced.
Douglas Anderson [Fri, 27 Jan 2023 01:09:13 +0000 (17:09 -0800)]
drm/msm/dp: Return IRQ_NONE for unhandled interrupts
If our interrupt handler gets called and we don't really handle the
interrupt then we should return IRQ_NONE. The current interrupt
handler didn't do this, so let's fix it.
NOTE: for some of the cases it's clear that we should return IRQ_NONE
and some cases it's clear that we should return IRQ_HANDLED. However,
there are a few that fall somewhere in between. Specifically, the
documentation for when to return IRQ_NONE vs. IRQ_HANDLED is probably
best spelled out in the commit message of commit d9e4ad5badf4 ("Document
that IRQ_NONE should be returned when IRQ not actually handled"). That
commit makes it clear that we should return IRQ_HANDLED if we've done
something to make the interrupt stop happening.
The case where it's unclear is, for instance, in dp_aux_isr() after
we've read the interrupt using dp_catalog_aux_get_irq() and confirmed
that "isr" is non-zero. The function dp_catalog_aux_get_irq() not only
reads the interrupts but it also "ack"s all the interrupts that are
returned. For an "unknown" interrupt this has a very good chance of
actually stopping the interrupt from happening. That would mean we've
identified that it's our device and done something to stop them from
happening and should return IRQ_HANDLED. Specifically, it should be
noted that most interrupts that need "ack"ing are ones that are
one-time events and doing an "ack" is enough to clear them. However,
since these interrupts are unknown then, by definition, it's unknown
if "ack"ing them is truly enough to clear them. It's possible that we
also need to remove the original source of the interrupt. In this
case, IRQ_NONE would be a better choice.
Given that returning an occasional IRQ_NONE isn't the absolute end of
the world, however, let's choose that course of action. The IRQ
framework will forgive a few IRQ_NONE returns now and again (and it
won't even log them, which is why we have to log them ourselves). This
means that if we _do_ end hitting an interrupt where "ack"ing isn't
enough the kernel will eventually detect the problem and shut our
device down.
Signed-off-by: Douglas Anderson <dianders@chromium.org> Tested-by: Kuogee Hsieh <quic_khsieh@quicinc.com> Reviewed-by: Kuogee Hsieh <quic_khsieh@quicinc.com>
Patchwork: https://patchwork.freedesktop.org/patch/520660/ Link: https://lore.kernel.org/r/20230126170745.v2.2.I2d7aec2fadb9c237cd0090a47d6a8ba2054bf0f8@changeid
[DB: reformatted commit message to make checkpatch happy] Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Konrad Dybcio [Sat, 18 Mar 2023 13:42:49 +0000 (14:42 +0100)]
drm/msm/dsi: Fix DSI index detection when version clash occurs
Currently, we allow for MAX_DSI entries in io_start to facilitate for
MAX_DSI number of DSI hosts at different addresses. The configuration
is matched against the DSI CTRL hardware revision read back from the
component. We need a way to resolve situations where multiple SoCs
with different register maps may use the same version of DSI CTRL. In
preparation to do so, make msm_dsi_config a 2d array where each entry
represents a set of configurations adequate for a given SoC.
This is totally fine to do, as the only differentiating factors
between same-version-different-SoCs configurations are the number of
DSI hosts (1 or 2, at least as of today) and the set of base registers.
The regulator setup is the same, because the DSI hardware is the same,
regardless of the SoC it was implemented in.
In addition to that, update the matching logic such that it will loop
over VARIANTS_MAX variants, making sure they are all taken into account.
Douglas Anderson [Fri, 27 Jan 2023 01:09:12 +0000 (17:09 -0800)]
drm/msm/dp: Clean up handling of DP AUX interrupts
The DP AUX interrupt handling was a bit of a mess.
* There were two functions (one for "native" transfers and one for
"i2c" transfers) that were quite similar. It was hard to say how
many of the differences between the two functions were on purpose
and how many of them were just an accident of how they were coded.
* Each function sometimes used "else if" to test for error bits and
sometimes didn't and again it was hard to say if this was on purpose
or just an accident.
* The two functions wouldn't notice whether "unknown" bits were
set. For instance, there seems to be a bit "DP_INTR_PLL_UNLOCKED"
and if it was set there would be no indication.
* The two functions wouldn't notice if more than one error was set.
Let's fix this by being more consistent / explicit about what we're
doing.
By design this could cause different handling for AUX transfers,
though I'm not actually aware of any bug fixed as a result of
this patch (this patch was created because we simply noticed how odd
the old code was by code inspection). Specific notes here:
1. In the old native transfer case if we got "done + wrong address"
we'd ignore the "wrong address" (because of the "else if"). Now we
won't.
2. In the old native transfer case if we got "done + timeout" we'd
ignore the "timeout" (because of the "else if"). Now we won't.
3. In the old native transfer case we'd see "nack_defer" and translate
it to the error number for "nack". This differed from the i2c
transfer case where "nack_defer" was given the error number for
"nack_defer". This 100% can't matter because the only user of this
error number treats "nack defer" the same as "nack", so it's clear
that the difference between the "native" and "i2c" was pointless
here.
4. In the old i2c transfer case if we got "done" plus any error
besides "nack" or "defer" then we'd ignore the error. Now we don't.
5. If there is more than one error signaled by the hardware it's
possible that we'll report a different one than we used to. I don't
know if this matters. If someone is aware of a case this matters we
should document it and change the code to make it explicit.
6. One quirk we keep (I don't know if this is important) is that in
the i2c transfer case if we see "done + defer" we report that as a
"nack". That seemed too intentional in the old code to just drop.
After this change we will add extra logging, including:
* A warning if we see more than one error bit set.
* A warning if we see an unexpected interrupt.
* A warning if we get an AUX transfer interrupt when shouldn't.
It actually turns out that as a result of this change then at boot we
sometimes see an error:
[drm:dp_aux_isr] *ERROR* Unexpected DP AUX IRQ 0x01000000 when not busy
That means that, during init, we are seeing DP_INTR_PLL_UNLOCKED. For
now I'm going to say that leaving this error reported in the logs is
OK-ish and hopefully it will encourage someone to track down what's
going on at init time.
One last note here is that this change renames one of the interrupt
bits. The bit named "i2c done" clearly was used for native transfers
being done too, so I renamed it to indicate this.
Konrad Dybcio [Sat, 18 Mar 2023 13:42:48 +0000 (14:42 +0100)]
drm/msm/dsi: Get rid of msm_dsi_config::num_dsi
In preparation for supporting multiple sets of possible base registers,
remove the num_dsi variable. We're comparing the io_start array contents
with the reg value from the DTS, so it will either match one of the
expected values or don't match against a zero (which we get from partial
array initialization).
The point of the previous cleanup was to disallow "qcom,mdss-dsi-ctrl"
alone. This however didn't quite work out and the property became
undocumented instead of deprecated. Fix that.
Additionally, the "qcom," prefix was missed previously. Fix it.
Fixes: 0c0f65c6dd44 ("dt-bindings: msm: dsi-controller-main: Add compatible strings for every current SoC") Acked-by: Rob Herring <robh@kernel.org> Reviewed-by: Marijn Suijten <marijn.suijten@somainline.org> Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/527651/ Link: https://lore.kernel.org/r/20230307-topic-dsi_qcm-v6-1-70e13b1214fa@linaro.org Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Vinod Polimera [Fri, 31 Mar 2023 13:58:32 +0000 (19:28 +0530)]
drm/msm/dpu: set dirty_fb flag while in self refresh mode
While in virtual terminal mode with PSR enabled, there will be
no atomic commits triggered without dirty_fb being set. This
will create a notion of no screen update. Allow atomic commit
when dirty_fb ioctl is issued, so that it can trigger a PSR exit
and shows update on the screen.
Kalyan Thota [Mon, 13 Feb 2023 11:11:44 +0000 (03:11 -0800)]
drm/msm/dpu: manage DPU resources if CTM is requested
Allow modeset to be triggered during CTM enable/disable.
In the modeset callbacks, DPU resources required for the
CTM feature are managed appropriately.
drm/msm/dpu: Fix bit-shifting UB in DPU_HW_VER() macro
With gcc-5 and CONFIG_UBSAN_SHIFT=y:
drivers/gpu/drm/msm/msm_mdss.c: In function 'msm_mdss_enable':
drivers/gpu/drm/msm/msm_mdss.c:296:2: error: case label does not reduce to an integer constant
case DPU_HW_VER_800:
^
drivers/gpu/drm/msm/msm_mdss.c:299:2: error: case label does not reduce to an integer constant
case DPU_HW_VER_810:
^
drivers/gpu/drm/msm/msm_mdss.c:300:2: error: case label does not reduce to an integer constant
case DPU_HW_VER_900:
^
This happens because for major revisions 8 or greather, the non-sign bit
of the major revision number is shifted into bit 31 of a signed integer,
which is undefined behavior.
Fix this by casting the major revision number to unsigned int.
Fixes: efcd0107727c4f04 ("drm/msm/dpu: add support for SM8550") Fixes: 4a352c2fc15aec1e ("drm/msm/dpu: Introduce SC8280XP") Fixes: 100d7ef6995d1f86 ("drm/msm/dpu: add support for SM8450") Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Randy Dunlap <rdunlap@infradead.org> Reviewed-by: Rob Clark <robdclark@gmail.com>
Patchwork: https://patchwork.freedesktop.org/patch/525152/ Link: https://lore.kernel.org/r/20230306090633.65918-1-geert+renesas@glider.be Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Dmitry Baryshkov [Thu, 16 Mar 2023 16:16:51 +0000 (19:16 +0300)]
drm/msm/dpu: drop smart_dma_rev from dpu_caps
The code doesn't use dpu_caps::smart_dma_rev field. It checks if the
corresponding feature is enabled in the SSPP features. Drop the
smart_dma_rev field completely.
Dmitry Baryshkov [Thu, 16 Mar 2023 16:16:49 +0000 (19:16 +0300)]
drm/msm/dpu: populate SmartDMA features in hw catalog
Downstream driver uses dpu->caps->smart_dma_rev to update
sspp->cap->features with the bit corresponding to the supported SmartDMA
version. Upstream driver does not do this, resulting in SSPP subdriver
not enabling setup_multirect callback. Add corresponding SmartDMA SSPP
feature bits to dpu hw catalog.
Per Abhinav's request enable the SmartDMA features only on the platforms
where the multirect was actually verified visually (sdm845 and sm8250).
An (untested) enablement on the rest of the platforms comes in the next
patch.
Dmitry Baryshkov [Thu, 16 Mar 2023 16:16:48 +0000 (19:16 +0300)]
drm/msm/dpu: add support for wide planes
It is possible to use multirect feature and split source to use the SSPP
to output two consecutive rectangles. This commit brings in this
capability to support wider screen resolutions.
Dmitry Baryshkov [Thu, 16 Mar 2023 16:16:44 +0000 (19:16 +0300)]
drm/msm/dpu: rework dpu_plane_atomic_check()
Split pipe-dependent code from dpu_plane_atomic_check() into the
separate function dpu_plane_atomic_check_pipe(). This is one of
preparational steps to add r_pipe support.
Split pipe-dependent code from dpu_plane_sspp_atomic_update() into the
separate function dpu_plane_sspp_update_pipe(). This is one of
preparational steps to add r_pipe support.
Dmitry Baryshkov [Thu, 16 Mar 2023 16:16:42 +0000 (19:16 +0300)]
drm/msm/dpu: simplify dpu_plane_validate_src()
The plane's clipped coordinates has already been validated against FB
size in the drm_atomic_plane_check(). There is no need to check them
again. Remove corresponding checks and inline dpu_plane_validate_src().
Dmitry Baryshkov [Thu, 16 Mar 2023 16:16:41 +0000 (19:16 +0300)]
drm/msm/dpu: add dpu_hw_sspp_cfg to dpu_plane_state
Now as all accesses to pipe_cfg and pstate have been cleaned, add
struct dpu_hw_sspp_cfg to struct dpu_plane_state, so that
dpu_plane_atomic_check() and dpu_plane_atomic_update() do not have a
chance to disagree about src/dst rectangles (currently
dpu_plane_atomic_check() uses unclipped rectangles, while
dpu_plane_atomic_update() uses clipped rectangles calculated by
drm_atomic_helper_check_plane_state()).
Dmitry Baryshkov [Thu, 16 Mar 2023 16:16:39 +0000 (19:16 +0300)]
drm/msm/dpu: rewrite plane's QoS-related functions to take dpu_sw_pipe and dpu_format
Rewrite dpu_plane's QoS related functions to take struct dpu_sw_pipe and
struct dpu_format as arguments rather than fetching them from the
pstate or drm_framebuffer.
Dmitry Baryshkov [Thu, 16 Mar 2023 16:16:38 +0000 (19:16 +0300)]
drm/msm/dpu: drop redundant plane dst check from dpu_crtc_atomic_check()
The helper drm_atomic_helper_check_plane_state() already checks whether
the scaled and clipped plane falls into the CRTC visible region (and
clears plane_state->visible if it doesn't). Drop the redundant check
from dpu_crtc_atomic_check().
Dmitry Baryshkov [Thu, 16 Mar 2023 16:16:36 +0000 (19:16 +0300)]
drm/msm/dpu: don't use unsupported blend stages
The dpu_crtc_atomic_check() compares blending stage with DPU_STAGE_MAX
(maximum amount of blending stages supported by the driver), however we
should compare it against .max_mixer_blendstages, the maximum blend
stage supported by the mixer.
Dmitry Baryshkov [Thu, 16 Mar 2023 16:16:35 +0000 (19:16 +0300)]
drm/msm/dpu: drop src_split and multirect check from dpu_crtc_atomic_check
Neither source split nor multirect are properly supported at this
moment. Both of these checks depend on normalized_zpos being equal for
several planes (which is never the case for normalized zpos).
Drop these checks to simplify dpu_crtc_atomic_check(). The actual
support for either of these features is not removed from the backend
code (sspp, ctl, etc).
projects / thirdparty / linux.git / log
