-
Notifications
You must be signed in to change notification settings - Fork 29
Prepare qcom-next based on tag 'Linux 6.19-rc2' of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git #146
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Open
sgaud-quic
wants to merge
401
commits into
qualcomm-linux:qcom-next-staging
Choose a base branch
from
sgaud-quic:qcom-next-staging-6.19-rc2-20251223
base: qcom-next-staging
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The current RPMh VRM clock definitions do not accurately represent the hardware mapping of these clocks. While there is no functional impact, this update aligns the definitions with the hardware convention by adding the appropriate suffix to indicate the clock divider and the E0 variant for the C3A_E0, C4A_E0, C5A_E0, and C8A_E0 resources on Glymur. Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20251209-gcc_kaanapali-v3-v5-1-3af118262289@oss.qualcomm.com Signed-off-by: Taniya Das <taniya.das@oss.qualcomm.com>
Add the RPMH clocks present in Kaanapali SoC. Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20251209-gcc_kaanapali-v3-v5-2-3af118262289@oss.qualcomm.com Signed-off-by: Taniya Das <taniya.das@oss.qualcomm.com>
Add the TCSR clock controller that provides the refclks on Kaanapali platform for PCIe, USB and UFS subsystems. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Abel Vesa <abel.vesa@linaro.org> Link: https://lore.kernel.org/r/20251209-gcc_kaanapali-v3-v5-3-3af118262289@oss.qualcomm.com Signed-off-by: Taniya Das <taniya.das@oss.qualcomm.com>
…pali Add support for Global clock controller for Kaanapali Qualcomm SoC. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20251209-gcc_kaanapali-v3-v5-4-3af118262289@oss.qualcomm.com Signed-off-by: Taniya Das <taniya.das@oss.qualcomm.com>
Recent QCOM PLLs require the CAL_L field to be programmed according to specific hardware recommendations, rather than using the legacy default value of 0x44. Hardcoding this value can lead to suboptimal or incorrect behavior on newer platforms. To address this, introduce a `cal_l` field in the PLL configuration structure, allowing CAL_L to be set explicitly based on platform requirements. This improves flexibility and ensures correct PLL initialization across different hardware variants. Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20251125-kaanapali-mmcc-v2-v2-1-fb44e78f300b@oss.qualcomm.com Signed-off-by: Taniya Das <taniya.das@oss.qualcomm.com>
… EKO_T PLL Add clock ops for Pongo EKO_T PLL, add the pll ops for supporting the PLL. Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20251125-kaanapali-mmcc-v2-v2-2-fb44e78f300b@oss.qualcomm.com Signed-off-by: Taniya Das <taniya.das@oss.qualcomm.com>
…n PLL Add clock ops for Rivian ELU and EKO_T PLLs, add the register offsets for the Rivian ELU PLL. Since ELU and EKO_T shared the same offsets and PLL ops, reuse the Rivian EKO_T enum. Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20251125-kaanapali-mmcc-v2-v2-3-fb44e78f300b@oss.qualcomm.com Signed-off-by: Taniya Das <taniya.das@oss.qualcomm.com>
…ontroller Document device tree bindings for display clock controller for Qualcomm Kaanapali SoC. Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20251125-kaanapali-mmcc-v2-v2-4-fb44e78f300b@oss.qualcomm.com Signed-off-by: Taniya Das <taniya.das@oss.qualcomm.com>
Update the compatible and the bindings for CAMCC support on Kaanapali SoC. Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://lore.kernel.org/r/20251125-kaanapali-mmcc-v2-v2-5-fb44e78f300b@oss.qualcomm.com Signed-off-by: Taniya Das <taniya.das@oss.qualcomm.com>
Add device tree bindings for the video clock controller on Qualcomm Kaanapali SoC. Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Link: https://lore.kernel.org/r/20251125-kaanapali-mmcc-v2-v2-6-fb44e78f300b@oss.qualcomm.com Signed-off-by: Taniya Das <taniya.das@oss.qualcomm.com>
…Controller Add bindings documentation for the Kaanapali Graphics Clock and Graphics power domain Controller. Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com> Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Link: https://lore.kernel.org/r/20251125-kaanapali-mmcc-v2-v2-7-fb44e78f300b@oss.qualcomm.com Signed-off-by: Taniya Das <taniya.das@oss.qualcomm.com>
… Kaanapali Support the clock controller driver for Kaanapali to enable display SW to be able to control the clocks. Link: https://lore.kernel.org/r/20251125-kaanapali-mmcc-v2-v2-8-fb44e78f300b@oss.qualcomm.com Signed-off-by: Taniya Das <taniya.das@oss.qualcomm.com>
…or Kaanapali Add support for the Camera Clock Controller (CAMCC) on the Kaanapali platform. The CAMCC block on Kaanapali includes both the primary camera clock controller and the Camera BIST clock controller, which provides the functional MCLK required for camera operations. Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com> Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Link: https://lore.kernel.org/r/20251125-kaanapali-mmcc-v2-v2-9-fb44e78f300b@oss.qualcomm.com Signed-off-by: Taniya Das <taniya.das@oss.qualcomm.com>
Enable Kaanapali video clock driver for video SW to be able to control the clocks from the Video SW driver. Link: https://lore.kernel.org/r/20251125-kaanapali-mmcc-v2-v2-10-fb44e78f300b@oss.qualcomm.com Signed-off-by: Taniya Das <taniya.das@oss.qualcomm.com>
Support the graphics clock controller for Kaanapali for Graphics SW driver to use the clocks. GXCLKCTL (Graphics GX Clock Controller) is a block dedicated to managing clocks for the GPU subsystem on GX power domain. The GX clock controller driver manages only the GX GDSC and the rest of the resources of the controller are managed by the firmware. Link: https://lore.kernel.org/r/20251125-kaanapali-mmcc-v2-v2-11-fb44e78f300b@oss.qualcomm.com Signed-off-by: Taniya Das <taniya.das@oss.qualcomm.com>
Add the PMU node for talos platforms. Link: https://lore.kernel.org/all/20251217092057.462-1-yuanjie.yang@oss.qualcomm.com/ Signed-off-by: Yuanjie Yang <yuanjie.yang@oss.qualcomm.com>
…ge during STOP handling
Currently v4l2_m2m_ioctl_{de,enc}coder_cmd is being invoked during STOP
command handling. However, this is not required as the iris driver has
its own drain and stop handling mechanism in place.
Using the m2m command API in this context leads to incorrect behavior,
where the LAST flag is prematurely attached to a capture buffer,
when there are no buffers in m2m source queue. But, in this scenario
even though the source buffers are returned to client, hardware might
still need to process the pending capture buffers.
Attaching LAST flag prematurely can result in the capture buffer being
removed from the destination queue before the hardware has finished
processing it, causing issues when the buffer is eventually returned by
the hardware.
To prevent this, remove the m2m API usage in stop handling.
Link: https://lore.kernel.org/linux-media/20251102-iris-drain-fix-v1-1-7f88d187fb48@oss.qualcomm.com/
Fixes: d091007 ("media: iris: add support for drain sequence")
Fixes: 75db90a ("media: iris: Add support for drain sequence in encoder video device")
Reviewed-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
Signed-off-by: Dikshita Agarwal <dikshita.agarwal@oss.qualcomm.com>
On SM8250 (IRIS2) with firmware older than 1.0.087, the firmware could
not handle a dummy device address for EOS buffers, so a NULL device
address is sent instead. The existing check used IS_V6() alongside a
firmware version gate:
if (IS_V6(core) && is_fw_rev_or_older(core, 1, 0, 87))
fdata.device_addr = 0;
else
fdata.device_addr = 0xdeadb000;
However, SC7280 which is also V6, uses a firmware string of the form
"1.0.<commit-hash>", which the version parser translates to 1.0.0. This
unintentionally satisfies the `is_fw_rev_or_older(..., 1, 0, 87)`
condition on SC7280. Combined with IS_V6() matching there as well, the
quirk is incorrectly applied to SC7280, causing VP9 decode failures.
Constrain the check to IRIS2 (SM8250) only, which is the only platform
that needed this quirk, by replacing IS_V6() with IS_IRIS2(). This
restores correct behavior on SC7280 (no forced NULL EOS buffer address).
Link: https://lore.kernel.org/linux-arm-msm/20251125-venus-vp9-fix-v2-1-8bfcea128b95@oss.qualcomm.com/
Fixes: 47f867c ("media: venus: fix EOS handling in decoder stop command")
Cc: stable@vger.kernel.org
Reported-by: Mecid <mecid@mecomediagroup.de>
Closes: qualcomm-linux/kernel-topics#222
Co-developed-by: Renjiang Han <renjiang.han@oss.qualcomm.com>
Signed-off-by: Renjiang Han <renjiang.han@oss.qualcomm.com>
Signed-off-by: Dikshita Agarwal <dikshita.agarwal@oss.qualcomm.com>
Tested-by: Renjiang Han <renjiang.han@oss.qualcomm.com>
Introduce a new pixel format, V4L2_PIX_FMT_AV1, to the Video4Linux2(V4L2) API. This format is intended for AV1 bitstreams in stateful decoding/encoding workflows. The fourcc code 'AV10' is used to distinguish this format from the existing V4L2_PIX_FMT_AV1_FRAME, which is used for stateless AV1 decoder implementation. Link: https://lore.kernel.org/all/20251210-av1d_stateful_v3-v10-1-cf4379a3dcff@oss.qualcomm.com/ Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com> Reviewed-by: Hans Verkuil <hverkuil+cisco@kernel.org> Signed-off-by: Deepa Guthyappa Madivalara <deepa.madivalara@oss.qualcomm.com>
…ll_fmtdesc() Add a descriptive string for the AV1 pixel format to v4l_fill_fmtdesc(), enabling proper reporting of AV1 support via VIDIOC_ENUM_FMT. Link: https://lore.kernel.org/all/20251210-av1d_stateful_v3-v10-2-cf4379a3dcff@oss.qualcomm.com/ Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com> Reviewed-by: Hans Verkuil <hverkuil+cisco@kernel.org> Signed-off-by: Deepa Guthyappa Madivalara <deepa.madivalara@oss.qualcomm.com>
Extend iris decoder driver to support format V4L2_PIX_FMT_AV1. This change updates the format enumeration (VIDIOC_ENUM_FMT) and allows setting AV1 format via VIDIOC_S_FMT for gen2 and beyond. Gen1 iris hardware decoder does not support AV1 format. Link: https://lore.kernel.org/all/20251210-av1d_stateful_v3-v10-3-cf4379a3dcff@oss.qualcomm.com/ Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Reviewed-by: Dikshita Agarwal <dikshita.agarwal@oss.qualcomm.com> Signed-off-by: Deepa Guthyappa Madivalara <deepa.madivalara@oss.qualcomm.com>
…properties Defining platform specific capabilities specific to AV1 decoder. Set and subscribe to manadatory properties to firmware for AV1. Link: https://lore.kernel.org/all/20251210-av1d_stateful_v3-v10-4-cf4379a3dcff@oss.qualcomm.com/ Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Reviewed-by: Dikshita Agarwal <dikshita.agarwal@oss.qualcomm.com> Signed-off-by: Deepa Guthyappa Madivalara <deepa.madivalara@oss.qualcomm.com>
Implement internal buffer count and size calculations for AV1 decoder for all the buffer types required by the AV1 decoder, including BIN, COMV, PERSIST, LINE, and PARTIAL. This ensures the hardware decoder has properly allocated memory for AV1 decoding operations, enabling correct AV1 video playback. Link: https://lore.kernel.org/all/20251210-av1d_stateful_v3-v10-5-cf4379a3dcff@oss.qualcomm.com/ Reviewed-by: Dikshita Agarwal <dikshita.agarwal@oss.qualcomm.com> Signed-off-by: Deepa Guthyappa Madivalara <deepa.madivalara@oss.qualcomm.com>
…o codec binding Kaanapali SOC brings in the new generation of video IP i.e iris4. When compared to previous generation, iris3x, it has, - separate power domains for stream and pixel processing hardware blocks (bse and vpp). - additional power domain for apv codec. - power domains for individual pipes (VPPx). - different clocks and reset lines. Iommus include all the different stream-ids which can be possibly generated by vpu4 video hardware in both secure and non secure execution mode. The vpu have reserved iova, i.e some portion of the addressable range is reserved for IO registers. Iris_resv would describe the acceptable address range. Link: https://lore.kernel.org/linux-media/20251017-knp_video-v2-1-f568ce1a4be3@oss.qualcomm.com/ Signed-off-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
vpu4 depends on more than one clock source. Thus far hardware versions up to vpu3x have been clocked by a single source. This adds support for multiple clocks by, - Adding a lookup table - Configuring OPP table for video device with different video clocks - Setting OPP for multiple clocks during dev_pm_opp_set_opp() This patch extends the support for multiple clocks in driver, which would be used in subsequent patch for kaanapali, when the platform data is prepared. Link: https://lore.kernel.org/linux-media/20251210-knp_video-v4-1-8d11d840358a@oss.qualcomm.com/ Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Co-developed-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com> Signed-off-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com> Signed-off-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
…(CP) configs vpu4 needs an additional configuration with respect to CP regions. Make the CP configuration as array such that the multiple configuration can be managed per platform. Link: https://lore.kernel.org/linux-media/20251210-knp_video-v4-2-8d11d840358a@oss.qualcomm.com/ Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Co-developed-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com> Signed-off-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com> Signed-off-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
Introduces vp4 buffer size calculation for both encoder and decoder. Reuse the buffer size calculation which are common, while adding the vpu4 ones separately. Link: https://lore.kernel.org/linux-media/20251210-knp_video-v4-3-8d11d840358a@oss.qualcomm.com/ Co-developed-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com> Signed-off-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com> Signed-off-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
Some of vpu4 register defines are common with vpu3x. Move those into the common register defines header. This is done to reuse the defines for vpu4 in subsequent patch which enables the power sequence for vpu4. Link: https://lore.kernel.org/linux-media/20251210-knp_video-v4-4-8d11d840358a@oss.qualcomm.com/ Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Co-developed-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com> Signed-off-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com> Signed-off-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com> Co-developed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Some of the sequence and calculations for vpu4 is identical to vpu35, namely power sequence for vpu controller and the clock frequency calculation. Move those to common file that can be shared for both vpu35 and vpu4. This patch prepares for power sequence for vpu4 which is added in subsequent patch. Link: https://lore.kernel.org/linux-media/20251210-knp_video-v4-5-8d11d840358a@oss.qualcomm.com/ Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Co-developed-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com> Signed-off-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com> Signed-off-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
Add power sequence for vpu4 by reusing from previous generation wherever possible. Hook up vpu4 op with vpu4 specific implemtation or resue from earlier generation wherever feasible, like clock calculation in this case. Link: https://lore.kernel.org/linux-media/20251210-knp_video-v4-6-8d11d840358a@oss.qualcomm.com/ Co-developed-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com> Signed-off-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com> Signed-off-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
# Conflicts: # Documentation/devicetree/bindings/i2c/qcom,i2c-cci.yaml
# Conflicts: # arch/arm64/boot/dts/qcom/Makefile
# Conflicts: # include/linux/firmware/qcom/qcom_scm.h
Adding merge log file and topic_SHA1 file Signed-off-by: Salendarsingh Gaud <sgaud@qti.qualcomm.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Name SHA Commits
tech/bsp/clk 567d776 19
tech/security/firmware-smc a50984a 2
tech/bsp/soc-infra 2949741 9
tech/bsp/remoteproc 2637255 14
tech/bus/peripherals 486bcf7 1
tech/bus/pci/all 2fdd372 9
tech/bus/usb/dwc 49ac8e0 2
tech/bus/usb/phy cb24d23 11
tech/debug/hwtracing 88c50d8 27
tech/pmic/misc 91e88b9 16
tech/pmic/regulator 81fc8fb 6
tech/mem/iommu fc1b59c 1
tech/mm/audio/all 6f46252 3
tech/mm/camss d1d2c38 3
tech/mm/drm 8a0d1c0 28
tech/mm/fastrpc 844e24f 4
tech/mm/video b5deb4a 15
tech/mm/gpu 1651b6d 5
tech/net/ath 6ed7ea2 19
tech/net/eth c280d7e 1
tech/net/bluetooth b5902f2 2
tech/pm/power 7b7e779 7
tech/pm/thermal 44a5bf0 1
tech/security/crypto fa6b06a 11
tech/storage/all ba8c93d 6
tech/all/dt/qcs6490 776fe08 6
tech/all/dt/qcs9100 14056f2 13
tech/all/dt/qcs8300 1c15317 26
tech/all/dt/qcs615 af8993b 9
tech/all/dt/hamoa 4c89453 11
tech/all/dt/glymur 6e186f9 20
tech/all/dt/kaanapali 9508158 5
tech/all/dt/pakala 6ac5fb5 3
tech/all/config 88f1458 32
tech/overlay/dt 5124ab1 8
tech/all/workaround 2784b22 3
tech/mproc/all d19a4c1 5