It is possible to slightly bend the limitations of the HW blender. If
two rectangles are contiguous (like two rectangles of a single plane)
they can be blended using a single LM blending stage, allowing one to
blend more planes via a single LM.
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Since we have enabled sharing of SSPP blocks between two planes, it is
now possible to use twice as much planes as there are hardware SSPP
blocks. Create additional overlay planes.
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Since SmartDMA planes provide two rectangles, it is possible to use them
to drive two different DRM planes, first plane getting the rect_0,
another one using rect_1 of the same SSPP. The sharing algorithm is
pretty simple, it requires that each of the planes can be driven by the
single rectangle and only consequetive planes are considered.
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Virtual wide planes give high amount of flexibility, but it is not
always enough:
In parallel multirect case only the half of the usual width is supported
for tiled formats. Thus the whole width of two tiled multirect
rectangles can not be greater than max_linewidth, which is not enough
for some platforms/compositors.
Another example is as simple as wide YUV plane. YUV planes can not use
multirect, so currently they are limited to max_linewidth too.
Now that the planes are fully virtualized, add support for allocating
two SSPP blocks to drive a single DRM plane. This fixes both mentioned
cases and allows all planes to go up to 2*max_linewidth (at the cost of
making some of the planes unavailable to the user).
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Only several SSPP blocks support such features as YUV output or scaling,
thus different DRM planes have different features. Properly utilizing
all planes requires the attention of the compositor, who should
prefer simpler planes to YUV-supporting ones. Otherwise it is very easy
to end up in a situation when all featureful planes are already
allocated for simple windows, leaving no spare plane for YUV playback.
To solve this problem make all planes virtual. Each plane is registered
as if it supports all possible features, but then at the runtime during
the atomic_check phase the driver selects backing SSPP block for each
plane.
Note, this does not provide support for using two different SSPP blocks
for a single plane or using two rectangles of an SSPP to drive two
planes. Each plane still gets its own SSPP and can utilize either a solo
rectangle or both multirect rectangles depending on the resolution.
Note #2: By default support for virtual planes is turned off and the
driver still uses old code path with preallocated SSPP block for each
plane. To enable virtual planes, pass 'msm.dpu_use_virtual_planes=1'
kernel parameter.
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Move a call to dpu_plane_check_inline_rotation() to the
dpu_plane_atomic_check_pipe() function, so that the rot90 constraints
are checked for both pipes. Also move rotation field from struct
dpu_plane_state to struct dpu_sw_pipe_cfg.
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Split dpu_plane_atomic_check() function into two pieces:
dpu_plane_atomic_check_nopipe() performing generic checks on the pstate,
without touching the associated pipe,
and
dpu_plane_atomic_check_pipes(), which takes into account used pipes.
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Max upscale / downscale factors are constant between platforms. In
preparation to adding support for virtual planes and allocating SSPP
blocks on demand move max scaling factors out of the HW catalog and
handle them in the dpu_plane directly. If any of the scaling blocks gets
different limitations, this will have to be handled separately, after
the plane refactoring.
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
The virt_formats / virt_num_formats are not used by the current driver
and are not going to be used in future since formats for virtual planes
are handled in a different way, by forbidding unsupported combinations
during atomic_check. Drop those fields now.
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
In preparation for virtualized planes support, move pstate->pipe
initialization from dpu_plane_reset() to dpu_plane_atomic_check(). In
case of virtual planes the plane's pipe will not be known up to the
point of atomic_check() callback.
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Take into account the plane rotation and flipping when calculating src
positions for the wide plane parts.
This is not an issue yet, because rotation is only supported for the
UBWC planes and wide UBWC planes are rejected anyway because in parallel
multirect case only the half of the usual width is supported for tiled
formats. However it's better to fix this now rather than stumbling upon
it later.
Fixes: 80e8ae3b38 ("drm/msm/dpu: add support for wide planes")
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Starting with Qualcomm SM8350 SoC, so Low Power Audio SubSystem (LPASS)
block version v9.2, the register responsible for TX SMIC MUXn muxes is
different. In earlier LPASS versions this mux had bit fields for
analogue (ADCn) and digital (SWR_DMICn) MICs. Choice of ADCn was
selecting the analogue path in CDC_TX_TOP_CSR_SWR_DMICn_CTL register.
With LPASS v9.2 and newer, the bit fields are integrated into just
SWR_MICn and there is no distinction for analogue or digital MIC in the
register.
Fix support for LPASS v9.2+:
1. Add new set of widgets and audio routes for LPASS v9.2.
2. Do not choose analogue or digital in CDC_TX_TOP_CSR_SWR_DMICn_CTL
based on value of the mux.
3. Replace all the input widgets (TX SWR_ADCn, TX SWR_DMICn) with TX
SWR_INPUTn ones.
The change is not backwards compatible with older DTBs and existing
mixer settings, therefore it does not change handling of older platforms
with working micrphones (SC8280xp) but only the ones with issues
(SM8450, SM8550) which need the fix.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
---
Changes in v3:
1. Do not change driver match data for SC8280xp, because of
compatibility reasons. Unlike on other newer platforms like SM8450
and SM8550, microphones are working fine on SC8280xp so apparently
the fix is not necessary on SC8280xp.
Changes in v2:
1. Keep all the MSM_DMIC/TX DMIC MUX audio routes in the shared
tx_audio_map, because it does not differ between v9 and v9.2.
2. Drop backwards compatible widgets because they create issues with
routes in existing DTS.
(cherry picked from commit 5ef64853515dcaaaf7095e739392ffa2c8921901)
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Check for SPF readiness in prm driver probe to avoid race conditions
during ADSP pil loading.
This patch is to avoid, sending requests to ADSP before it's PD's is
up and ready.
Signed-off-by: Srinivasa Rao Mandadapu <quic_srivasam@quicinc.com>
Tested-by: Ratna Deepthi Kudaravalli <rkudarav@qti.qualcomm.com>
(cherry picked from commit b8d605823adfcb71fe3b3fa110dcf2fc2f53cb21)
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
DSP expects the buffers to be aligned to 64bytes, so fix
the current sizes where there is a possiblity of getting an
unaligned buffers.
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
(cherry picked from commit 910a758d0340cff90ddb997a94ea269e30180beb)
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
(cherry picked from commit 86575bf4ea5ba0372ff72ef52f8a93bd1a70816f)
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
For some reason on wsa883x we see Port Collision during bank swith,
adding a delay seems provide a good workaround for this.
Needs more investigation.
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
(cherry picked from commit 32d454e57c2996099cb3a1920db5319f1eef6fa2)
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Registering controller even before pm runtime is enabled will result
in pm runtime underflow warnings. Fix this by properly moving
the runtime pm enable before registering controller.
Fixes: 74e79da9fd ("soundwire: qcom: add runtime pm support")
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Link: https://lore.kernel.org/r/20230209131336.18252-3-srinivas.kandagatla@linaro.org
Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
(cherry picked from commit 7578d5a6e7e7f0e2457f330c5c10c5c0b09c900d)
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
This config fragment was converted from the previous defconfig using
the following command:
ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- make -j12 defconfig
ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- make -j12 odin2_defconfig
./scripts/diffconfig -m .config.old .config > arch/arm64/configs/odin2.config
Signed-off-by: Xilin Wu <wuxilin123@gmail.com>
All of the thermal zone suppliers are interrupt-driven, remove the
bogus and unnecessary polling that only wastes CPU time.
Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
While adding the GIC ITS MSI support, it was found that the msi-map entries
needed to be swapped to receive MSIs from the endpoint.
But later it was identified that the swapping was needed due to a bug in
the Qualcomm PCIe controller driver. And since the bug is now fixed with
commit bf79e33cdd ("PCI: qcom: Enable BDF to SID translation properly"),
let's fix the msi-map entries also to reflect the actual mapping in the
hardware.
Fixes: 114990ce3e ("arm64: dts: qcom: sm8550: Use GIC-ITS for PCIe0 and PCIe1")
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Acked-by: Neil Armstrong <neil.armstrong@linaro.org>
Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # on SM8550-QRD
Add a schema description for the iris video encoder/decoder on sm8550.
Signed-off-by: Dikshita Agarwal <quic_dikshita@quicinc.com>
Signed-off-by: Vikash Garodia <quic_vgarodia@quicinc.com>
This adds iris driver Makefile and Kconfig, also changes
v4l2 platform/qcom Makefile/Kconfig in order to
enable compilation of the driver.
Signed-off-by: Dikshita Agarwal <quic_dikshita@quicinc.com>
Signed-off-by: Vikash Garodia <quic_vgarodia@quicinc.com>
This implements the logic to computer the required clock frequency
by encoder or decoder for a specific usecase. It considers the input
as various parameters configured by client for that usecase.
Signed-off-by: Dikshita Agarwal <quic_dikshita@quicinc.com>
Signed-off-by: Vikash Garodia <quic_vgarodia@quicinc.com>
This implements the logic to compute bus bandwidth required by encoder
or decoder for a specific usecase. It takes input as various video
usecase parameters as configured by clients.
Signed-off-by: Dikshita Agarwal <quic_dikshita@quicinc.com>
Signed-off-by: Vikash Garodia <quic_vgarodia@quicinc.com>
This adds the helper function to calculate the required bus
bandwidth and clock frequency for the given video usecase/s.
Signed-off-by: Dikshita Agarwal <quic_dikshita@quicinc.com>
Signed-off-by: Vikash Garodia <quic_vgarodia@quicinc.com>
This implements iris3 specific buffer size calculation for
firmware internal buffers, input and output buffers for
encoder and decoder.
Signed-off-by: Dikshita Agarwal <quic_dikshita@quicinc.com>
Signed-off-by: Vikash Garodia <quic_vgarodia@quicinc.com>
This implements iris3 specific ops for power on, power off,
boot firmware, power collapse etc.
Signed-off-by: Dikshita Agarwal <quic_dikshita@quicinc.com>
Signed-off-by: Vikash Garodia <quic_vgarodia@quicinc.com>
This implements the functions to read and write different regsiters.
Signed-off-by: Dikshita Agarwal <quic_dikshita@quicinc.com>
Signed-off-by: Vikash Garodia <quic_vgarodia@quicinc.com>
This implements all the capabilities supported by sm8550.
Signed-off-by: Dikshita Agarwal <quic_dikshita@quicinc.com>
Signed-off-by: Vikash Garodia <quic_vgarodia@quicinc.com>
