Revert "qcs6490-rb3gen2: Adjust tsens thermal zone configuration"#371
Closed
aastpand wants to merge 3301 commits intoqualcomm-linux:mainfrom
Closed
Revert "qcs6490-rb3gen2: Adjust tsens thermal zone configuration"#371aastpand wants to merge 3301 commits intoqualcomm-linux:mainfrom
aastpand wants to merge 3301 commits intoqualcomm-linux:mainfrom
Conversation
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> Tested-by: Val Packett <val@packett.cool> Signed-off-by: Bryan O'Donoghue <bod@kernel.org> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org> (cherry picked from commit 819fcf0)
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> Tested-by: Val Packett <val@packett.cool> Signed-off-by: Bryan O'Donoghue <bod@kernel.org> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org> (cherry picked from commit 10ac84a)
…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> Tested-by: Val Packett <val@packett.cool> Signed-off-by: Bryan O'Donoghue <bod@kernel.org> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org> (cherry picked from commit 2af481a)
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>
Signed-off-by: Bryan O'Donoghue <bod@kernel.org>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
(cherry picked from commit 63c072e)
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> Tested-by: Val Packett <val@packett.cool> Signed-off-by: Bryan O'Donoghue <bod@kernel.org> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org> (cherry picked from commit 406fc2e)
…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> Tested-by: Val Packett <val@packett.cool> Signed-off-by: Bryan O'Donoghue <bod@kernel.org> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org> (cherry picked from commit 1510965)
Add support for SYSTEM_RESET2 vendor-specific resets as reboot-modes in the psci node. Describe the resets: "bootloader" will cause device to reboot and stop in the bootloader's fastboot mode. "edl" will cause device to reboot into "emergency download mode", which permits loading images via the Firehose protocol. Signed-off-by: Xin Liu <xin.liu@oss.qualcomm.com> Link: https://lore.kernel.org/all/20260226054113.4156874-1-xin.liu@oss.qualcomm.com/
… HPD The base device tree configures the edp_hot_plug_det pin using the "edp_hot" function on GPIO 60. However, on qcs6490-rb3gen2 this external HPD GPIO does not generate a connect event when a display is already connected at boot, causing the DP/eDP display to remain disabled. The DP controller’s native HPD correctly detects the connected sink in this scenario, so continue using the DP controller native HPD on the qcs6490-rb3gen2 platform instead of the external HPD GPIO. Link: https://lore.kernel.org/all/20260228-edp_hpd_rb3_gen2_for_next-v1-1-aebc047eddc1@oss.qualcomm.com/ Signed-off-by: Vishnu Saini <vishnu.saini@oss.qualcomm.com>
Add a base schema initially compatible with x1e80100 to describe MIPI CSI2 PHY devices. The hardware can support both C-PHY and D-PHY modes. The CSIPHY devices have their own pinouts on the SoC as well as their own individual voltage rails. The need to model voltage rails on a per-PHY basis leads us to define CSIPHY devices as individual nodes. Two nice outcomes in terms of schema and DT arise from this change. 1. The ability to define on a per-PHY basis voltage rails. 2. The ability to require those voltage. We have had a complete bodge upstream for this where a single set of voltage rail for all CSIPHYs has been buried inside of CAMSS. Much like the I2C bus which is dedicated to Camera sensors - the CCI bus in CAMSS parlance, the CSIPHY devices should be individually modelled. Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Reviewed-by: Christopher Obbard <christopher.obbard@linaro.org> Link: https://lore.kernel.org/all/20260226-x1e-csi2-phy-v3-1-11e608759410@linaro.org/
Add a new MIPI CSI2 driver in DPHY mode initially. The entire set of existing CAMSS CSI PHY init sequences are imported in order to save time and effort in later patches. The following devices are supported in this drop: "qcom,x1e80100-csi2-phy" In-line with other PHY drivers the process node is included in the name. At the moment we follow the assignment of lane positions - the bitmap of physical input lanes to logical lane numbers as a linear list per the existing DPHY @lanes data-member. This is fine for us in upstream at the moment since we also map the lanes contiguously but, our hardware can support different lane mappings so we should in the future extend out the DPHY structure to capture the mapping. The Qualcomm 3PH class of PHYs can do both DPHY and CPHY mode. For now only DPHY is supported. In porting some of the logic over from camss-csiphy*.c to here its also possible to rationalise some of the code. In particular use of regulator_bulk and clk_bulk as well as dropping the seemingly useless and unused interrupt handler. The PHY sequences and a lot of the logic that goes with them are well proven in CAMSS and mature so the main thing to watch out for here is how to get the right sequencing of regulators, clocks and register-writes. Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Reviewed-by: Christopher Obbard <christopher.obbard@linaro.org> Tested-by: Christopher Obbard <christopher.obbard@linaro.org> Link: https://lore.kernel.org/all/20260226-x1e-csi2-phy-v3-2-11e608759410@linaro.org/
…andle definitions Add optional PHY handle definitions. This will allow for supporting both legacy PHY definitions as well as supporting the optional new handle based approach. Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Link: https://lore.kernel.org/all/20260226-b4-linux-next-25-03-13-dtsi-x1e80100-camss-v9-1-a59c3f037d0b@linaro.org/
…mbo-mode endpoints Qualcomm CSI2 PHYs support a mode where two sensors may be attached to the one CSIPHY. When we have one endpoint we may have - DPHY 1, 2 or 4 data lanes + 1 clock lane - CPHY 3 wire data lane When we have two endpoints this indicates the special fixed combo-mode. - DPHY endpoint0 => 2+1 and endpoint1 => 1+1 data-lane/clock-lane combination. Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Reviewed-by: Christopher Obbard <christopher.obbard@linaro.org> Link: https://lore.kernel.org/all/20260226-b4-linux-next-25-03-13-dtsi-x1e80100-camss-v9-2-a59c3f037d0b@linaro.org/
…s: 5 Specify a minimum number of iommus entries. Currently the schema requires exactly eight. Add minItems to allow fewer entries while retaining the existing maximum. Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Link: https://lore.kernel.org/all/20260226-b4-linux-next-25-03-13-dtsi-x1e80100-camss-v9-3-a59c3f037d0b@linaro.org/
…ies to be optional When CSIPHY devices are modelled as standalone PHY nodes the voltage rails are defined per-PHY. Allow the CAMSS-level supply properties to be omitted in this case. Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Link: https://lore.kernel.org/all/20260226-b4-linux-next-25-03-13-dtsi-x1e80100-camss-v9-4-a59c3f037d0b@linaro.org/
…tructures Flag which SoCs have legacy - builtin PHY code. This will be useful in subsequent patches to inform PHY bringup logic if legacy bindings are available. Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Reviewed-by: Christopher Obbard <christopher.obbard@linaro.org> Tested-by: Christopher Obbard <christopher.obbard@linaro.org> Link: https://lore.kernel.org/all/20260226-b4-linux-next-25-03-13-dtsi-x1e80100-camss-v9-5-a59c3f037d0b@linaro.org/
Add the ability to use a PHY pointer which interacts with the standard PHY API. In the first instance the code will try to use the new PHY interface. If no PHYs are present in the DT then the legacy method will be attempted. Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Link: https://lore.kernel.org/all/20260226-b4-linux-next-25-03-13-dtsi-x1e80100-camss-v9-6-a59c3f037d0b@linaro.org/
x1e is the first CAMSS SoC to use the new PHY interface. Drop the redundant legacy CSIPHY descriptions. Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Reviewed-by: Christopher Obbard <christopher.obbard@linaro.org> Tested-by: Christopher Obbard <christopher.obbard@linaro.org> Link: https://lore.kernel.org/all/20260226-b4-linux-next-25-03-13-dtsi-x1e80100-camss-v9-7-a59c3f037d0b@linaro.org/
Add the CAMCC block for x1e80100. The x1e80100 CAMCC block is an iteration of previous CAMCC blocks with the exception of having two required power-domains not just one. Reviewed-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Reviewed-by: Christopher Obbard <christopher.obbard@linaro.org> Tested-by: Christopher Obbard <christopher.obbard@linaro.org> Link: https://lore.kernel.org/all/20260226-x1e-camss-csi2-phy-dtsi-v1-1-f3f7ddfbf849@linaro.org/
Add in two CCI buses. One bus has two CCI bus master pinouts: cci_i2c_sda0 = gpio101 cci_i2c_scl0 = gpio102 cci_i2c_sda1 = gpio103 cci_i2c_scl1 = gpio104 The second bus has two CCI bus master pinouts: cci_i2c_sda2 = gpio105 cci_i2c_scl2 = gpio106 aon_cci_i2c_sda3 = gpio235 aon_cci_i2c_scl3 = gpio236 Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org> Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Reviewed-by: Christopher Obbard <christopher.obbard@linaro.org> Tested-by: Christopher Obbard <christopher.obbard@linaro.org> Link: https://lore.kernel.org/all/20260226-x1e-camss-csi2-phy-dtsi-v1-2-f3f7ddfbf849@linaro.org/
Add csiphy nodes for - csiphy0 - csiphy1 - csiphy2 - csiphy4 The irregular naming of the PHYs comes directly from the hardware which for whatever reason skipped csiphy3. Separating the nodes from CAMSS as we have done with the sensor I2C bus aka the CCI interface is justified since the CSIPHYs have their own pinouts and voltage rails. Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Reviewed-by: Christopher Obbard <christopher.obbard@linaro.org> Tested-by: Christopher Obbard <christopher.obbard@linaro.org> Link: https://lore.kernel.org/all/20260226-x1e-camss-csi2-phy-dtsi-v1-3-f3f7ddfbf849@linaro.org/
Add dtsi to describe the xe180100 CAMSS block 4 x CSIPHY 3 x TPG 2 x CSID 2 x CSID Lite 2 x IFE 2 x IFE Lite Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Link: https://lore.kernel.org/all/20260226-x1e-camss-csi2-phy-dtsi-v1-4-f3f7ddfbf849@linaro.org/
…gulators Add pmic,id = m rpmh to regulator definitions. This regulator set provides vreg_l3m_1p8 the regulator for the ov08x40 RGB sensor on the CRD. Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Reviewed-by: Christopher Obbard <christopher.obbard@linaro.org> Link: https://lore.kernel.org/all/20260226-x1e-camss-csi2-phy-dtsi-v1-5-f3f7ddfbf849@linaro.org/
…SIPHY4 Define ov08x40 on cci1_i2c1. The RGB sensor appears on the AON CCI pins connected to CSIPHY4 in four lane mode. Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Reviewed-by: Christopher Obbard <christopher.obbard@linaro.org> Link: https://lore.kernel.org/all/20260226-x1e-camss-csi2-phy-dtsi-v1-6-f3f7ddfbf849@linaro.org/
…h voltage levels for IR and RGB camera Add the PM8010 PMIC providing the following voltage rails: vreg_l1m_r @ 1v2 IR sensor vreg_l2m_r @ 1v2 RGB sensor vreg_l3m_r @ 1v8 IR sensor vreg_l4m_r @ 1v8 RGB sensor vreg_l5m_r @ 2v8 IR sensor vreg_l7m_r @ 2v8 RGB sensor Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Link: https://lore.kernel.org/all/20260226-x1e-camss-csi2-phy-dtsi-v1-7-f3f7ddfbf849@linaro.org/
…on CSIPHY4 Switch on the ov02c10 RGB sensor on CSIPHY4. Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Reviewed-by: Christopher Obbard <christopher.obbard@linaro.org> Tested-by: Christopher Obbard <christopher.obbard@linaro.org> Link: https://lore.kernel.org/all/20260226-x1e-camss-csi2-phy-dtsi-v1-8-f3f7ddfbf849@linaro.org/
…amera PMIC with voltage levels for IR and RGB camera Add voltage regulators-8 for Camera on slim7x including: - vreg_l7m_2p8 - vreg_l2m_1p2 - vreg_l4m_1p8 Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Reviewed-by: Christopher Obbard <christopher.obbard@linaro.or> Link: https://lore.kernel.org/all/20260226-x1e-camss-csi2-phy-dtsi-v1-9-f3f7ddfbf849@linaro.org/
Add pm8010 L4M regulator which is used by Camera I2C pull-up. Signed-off-by: Tingguo Cheng <tingguo.cheng@oss.qualcomm.com> Signed-off-by: Wenmeng Liu <wenmeng.liu@oss.qualcomm.com> Link: https://lore.kernel.org/all/20260227-hamoa_evk-v1-1-36f895a24d8f@oss.qualcomm.com/
Enable IMX577 via CCI on Hamoa EVK Core Kit. The Hamoa EVK board does not include a camera sensor by default, this DTSO has enabled the Arducam 12.3MP IMX577 Mini Camera Module on the CSI-1 interface. Signed-off-by: Wenmeng Liu <wenmeng.liu@oss.qualcomm.com> Link: https://lore.kernel.org/all/20260227-hamoa_evk-v1-2-36f895a24d8f@oss.qualcomm.com/
…cture Add reference counting using kref to the fastrpc_user structure to prevent use-after-free issues when contexts are freed from workqueue after device release. The issue occurs when fastrpc_device_release() frees the user structure while invoke contexts are still pending in the workqueue. When the workqueue later calls fastrpc_context_free(), it attempts to access buf->fl->cctx in fastrpc_buf_free(), leading to a use-after-free: pc : fastrpc_buf_free+0x38/0x80 [fastrpc] lr : fastrpc_context_free+0xa8/0x1b0 [fastrpc] ... fastrpc_context_free+0xa8/0x1b0 [fastrpc] fastrpc_context_put_wq+0x78/0xa0 [fastrpc] process_one_work+0x180/0x450 worker_thread+0x26c/0x388 Implement proper reference counting to fix this: - Initialize kref in fastrpc_device_open() - Take a reference in fastrpc_context_alloc() for each context - Release the reference in fastrpc_context_free() when context is freed - Release the initial reference in fastrpc_device_release() This ensures the user structure remains valid as long as there are contexts holding references to it, preventing the race condition. Link: https://lore.kernel.org/all/20260226151121.818852-1-anandu.e@oss.qualcomm.com/ Signed-off-by: Anandu Krishnan E <anandu.e@oss.qualcomm.com>
Enable passive cooling for CPUs in the X1E80100 SoC by adding the '#cooling-cells' property. This will allow the OS to mitigate the CPU power dissipation with the help of SCMI DVFS. Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Tested-by: Gaurav Kohli <gaurav.kohli@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260210070321.17033-1-manivannan.sadhasivam@oss.qualcomm.com
wifi: ath: sync to ath-next
…ling support The Qualcomm Crypto Engine (QCE) driver currently lacks support for runtime power management (PM) and interconnect bandwidth control. As a result, the hardware remains fully powered and clocks stay enabled even when the device is idle. Additionally, static interconnect bandwidth votes are held indefinitely, preventing the system from reclaiming unused bandwidth. Address this by enabling runtime PM and dynamic interconnect bandwidth scaling to allow the system to suspend the device when idle and scale interconnect usage based on actual demand. Improve overall system efficiency by reducing power usage and optimizing interconnect resource allocation. Make the following changes as part of this integration: - Add support for pm_runtime APIs to manage device power state transitions. - Implement runtime_suspend() and runtime_resume() callbacks to gate clocks and vote for interconnect bandwidth only when needed. - Replace devm_clk_get_optional_enabled() with devm_pm_clk_create() + pm_clk_add() and let the PM core manage device clocks during runtime PM and system sleep. - Register dev_pm_ops with the platform driver to hook into the PM framework. Tested: - Verify that ICC votes drop to zero after probe and upon request completion. - Confirm that runtime PM usage count increments during active requests and decrements afterward. - Observe that the device correctly enters the suspended state when idle. Link: https://lore.kernel.org/all/20251120062443.2016084-1-quic_utiwari@quicinc.com/ Signed-off-by: Udit Tiwari <quic_utiwari@quicinc.com> Signed-off-by: Abhinaba Rakshit <abhinaba.rakshit@oss.qualcomm.com>
Fix a typo in the camx EL2 device tree by removing comments all together. The mistake was masked by a later comment terminator. Signed-off-by: Vikram Sharma <vikramsa@qti.qualcomm.com>
…ce for CFR module Channel Frequency Response (CFR) module will be initialized only when the following criteria passes: * Enabled CFR support for the hardware through the hardware param 'cfr_support' * WMI service enabled for the CFR support 'WMI_TLV_SERVICE_CFR_CAPTURE_SUPPORT' Also, provide a configuration option CONFIG_ATH11K_CFR to enable CFR feature support during the compilation time. CFR module initialization includes Direct Buffer(DB) ring initialization where hardware uses the DB ring buffers to copy CFR data to host. Number of buffers and buffer size of the ring is based on the DB ring capabilities advertised by the firmware through WMI service ready. Also ring configurations are sent to firmware through ath11k_dbring_wmi_cfg_setup(). Predefine ath11k_cfr_dma_hdr, ath11k_look_up_table, and ath11k_cfr structs and fields for subsequent patches. Tested-on: IPQ8074 hw2.0 PCI IPQ8074 WLAN.HK.2.5.0.1-00991-QCAHKSWPL_SILICONZ-1 Tested-on: WCN6855 hw2.1 PCI WLAN.HSP.1.1-04685-QCAHSPSWPL_V1_V2_SILICONZ_IOE-1 Signed-off-by: Venkateswara Naralasetty <quic_vnaralas@quicinc.com> Co-developed-by: Yu Zhang (Yuriy) <yu.zhang@oss.qualcomm.com> Signed-off-by: Yu Zhang (Yuriy) <yu.zhang@oss.qualcomm.com> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Signed-off-by: Qian Zhang <qian.zhang@oss.qualcomm.com> Link: https://patch.msgid.link/20251230082520.3401007-2-qian.zhang@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
Provide debugfs interfaces support to config CFR from the user space.
To enable/disable cfr feature use command,
echo <val> > /sys/kernel/debug/ieee80211/phyX/ath11k/enable_cfr
where, val: 0 to disable CFR and 1 to enable CFR.
To enable CFR capture for associated peers,
echo "<val> <bw> <periodicity> <method>"
>
/sys/kernel/debug/ieee80211/phyX/netdev\:wlanx/stations/<mac>/cfr_capture
val: 0 - stop CFR capture
1 - start CFR capture
bw: CFR capture bandwidth
0 - 20MHZ
1 - 40MHZ
2 - 80MHZ
Periodicity: Periodicity at which hardware is expected to collect CFR
dump.
0 - single shot capture.
non zero - for Periodic captures (value must be multiple of 10 ms)
method: Method used by hardware to collect the CFR dump.
0 - from the ACKs of QOS NULL packets.
Also, send the required WMI commands to the firmware based on the CFR
configurations.
Tested-on: IPQ8074 hw2.0 PCI IPQ8074 WLAN.HK.2.5.0.1-00991-QCAHKSWPL_SILICONZ-1
Tested-on: WCN6855 hw2.1 PCI WLAN.HSP.1.1-04685-QCAHSPSWPL_V1_V2_SILICONZ_IOE-1
Signed-off-by: Venkateswara Naralasetty <quic_vnaralas@quicinc.com>
Co-developed-by: Yu Zhang (Yuriy) <yu.zhang@oss.qualcomm.com>
Signed-off-by: Yu Zhang (Yuriy) <yu.zhang@oss.qualcomm.com>
Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com>
Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
Signed-off-by: Qian Zhang <qian.zhang@oss.qualcomm.com>
Link: https://patch.msgid.link/20251230082520.3401007-3-qian.zhang@oss.qualcomm.com
Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
Provide debugfs interfaces support to config unassociated client CFR
from the user space.
To enable CFR capture for unassociated clients,
echo "<mac address> <val> <periodicity>"
> /sys/kernel/debug/ieee80211/phyX/ath11k/cfr_unassoc
Mac address: mac address of the client.
Val: 0 - start CFR capture
1 - stop CFR capture
Periodicity: Periodicity at which hardware is expected to collect CFR
dump.
0 - single shot capture.
non zero - for Periodic captures (value must be multiple of 10 ms)
Tested-on: IPQ8074 hw2.0 PCI IPQ8074 WLAN.HK.2.5.0.1-00991-QCAHKSWPL_SILICONZ-1
Tested-on: WCN6855 hw2.1 PCI WLAN.HSP.1.1-04685-QCAHSPSWPL_V1_V2_SILICONZ_IOE-1
Signed-off-by: Venkateswara Naralasetty <quic_vnaralas@quicinc.com>
Co-developed-by: Yu Zhang (Yuriy) <yu.zhang@oss.qualcomm.com>
Signed-off-by: Yu Zhang (Yuriy) <yu.zhang@oss.qualcomm.com>
Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com>
Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
Signed-off-by: Qian Zhang <qian.zhang@oss.qualcomm.com>
Link: https://patch.msgid.link/20251230082520.3401007-3-qian.zhang@oss.qualcomm.com
Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
Provide a relayfs interface to collect the CFR dump from the user space.
'/sys/kernel/debug/ieee80211/phyX/ath11k/cfr_capture' is exposed to user
space to get CFR data.
CFR format to user space:
___________________________________________
| CFR header | CFR payload | CFR tail data |
|____________|_____________|_______________|
CFR header contains the following fields,
* Start magic number 0xDEADBEAF - 4 bytes
* vendor id - 4 bytes
* cfr metadata version - 1 byte
* cfr data version - 1 byte
* device type - 1 byte
* platform type - 1 byte
* CFR metadata length - 4 bytes
* metadata - 92 bytes
peer mac - 6 bytes
capture status - 1 byte (1 for success 0 for failure)
capture_bw - 1 byte
channel_bw - 1 byte
phy_mode - 1 byte
prim20_chan - 2 bytes
center_freq1 - 2 bytes
center_freq2 - 2 bytes
capture_mode - 1 byte
capture_type - 1 byte
sts_count - 1 byte
num_rx_chain - 1 byte
timestamp - 4 bytes
length - 4 bytes
chain_rssi - 32 bytes (4 bytes for each chain)
chain_phase - 16 bytes (2 bytes for each chain)
cfo_measurement - 4 bytes
agc_gain - 8 bytes (1 bytes for each chain)
rx_start_ts - 4 bytes
CFR payload:
CFR payload contains 8bytes of ucode header followed by the tone
information. Tone order is positive tones, followed by PHY memory
garbage, followed by negative tones. Dummy tones are uploaded to make
number of tones always integer number of 64. Number of tones is not
preamble type dependent.
Each CFR tone has 14-bit I component and 14-bit Q component and is sign
extended to 16-bit I/Q. Two tones are packed into one 64-bit unit as:
[63:0] = [Tone1_Q(63:48) Tone1_I(47:32) Tone0_Q(31:16) Tone0_I(15:0)]
CFR tail: end magic number 0xBEAFDEAD
Tested-on: IPQ8074 hw2.0 PCI IPQ8074 WLAN.HK.2.5.0.1-00991-QCAHKSWPL_SILICONZ-1
Tested-on: WCN6855 hw2.1 PCI WLAN.HSP.1.1-04685-QCAHSPSWPL_V1_V2_SILICONZ_IOE-1
Signed-off-by: Venkateswara Naralasetty <quic_vnaralas@quicinc.com>
Co-developed-by: Yu Zhang (Yuriy) <yu.zhang@oss.qualcomm.com>
Signed-off-by: Yu Zhang (Yuriy) <yu.zhang@oss.qualcomm.com>
Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com>
Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
Signed-off-by: Qian Zhang <qian.zhang@oss.qualcomm.com>
Link: https://patch.msgid.link/20251230082520.3401007-3-qian.zhang@oss.qualcomm.com
Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
Add handler for WMI_PDEV_DMA_RING_BUF_RELEASE_EVENT which indicates CFR data availability in the DB ring. Add CFR data processing from DB ring buffers. Use correlate_and_relay API to match CFR data with metadata from WMI_PEER_CFR_CAPTURE_EVENT. Release buffer to userspace through relayfs on successful correlation, otherwise hold buffer waiting for matching WMI event from firmware. Add new debug masks: - ATH11K_DBG_CFR: Enables CFR-related debug logs. - ATH11K_DBG_CFR_DUMP: Enables detailed CFR data dump for analysis. Tested-on: IPQ8074 hw2.0 PCI IPQ8074 WLAN.HK.2.5.0.1-00991-QCAHKSWPL_SILICONZ-1 Tested-on: WCN6855 hw2.1 PCI WLAN.HSP.1.1-04685-QCAHSPSWPL_V1_V2_SILICONZ_IOE-1 Signed-off-by: Venkateswara Naralasetty <quic_vnaralas@quicinc.com> Co-developed-by: Yu Zhang (Yuriy) <yu.zhang@oss.qualcomm.com> Signed-off-by: Yu Zhang (Yuriy) <yu.zhang@oss.qualcomm.com> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Signed-off-by: Qian Zhang <qian.zhang@oss.qualcomm.com> Link: https://patch.msgid.link/20251230082520.3401007-3-qian.zhang@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
Firmware sends CFR meta data through the WMI event WMI_PEER_CFR_CAPTURE_EVENT. Parse the meta data coming from the firmware and invoke correlate_and_relay function to correlate the CFR meta data with the CFR payload coming from the other WMI event WMI_PDEV_DMA_RING_BUF_RELEASE_EVENT. Release the buffer to user space once correlate and relay return success. Tested-on: IPQ8074 hw2.0 PCI IPQ8074 WLAN.HK.2.5.0.1-00991-QCAHKSWPL_SILICONZ-1 Tested-on: WCN6855 hw2.1 PCI WLAN.HSP.1.1-04685-QCAHSPSWPL_V1_V2_SILICONZ_IOE-1 Signed-off-by: Venkateswara Naralasetty <quic_vnaralas@quicinc.com> Co-developed-by: Yu Zhang (Yuriy) <yu.zhang@oss.qualcomm.com> Signed-off-by: Yu Zhang (Yuriy) <yu.zhang@oss.qualcomm.com> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Signed-off-by: Qian Zhang <qian.zhang@oss.qualcomm.com> Link: https://patch.msgid.link/20251230082520.3401007-3-qian.zhang@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
Enable RELAY and ATH11K_CFR for channel Frequency Response (CFR) module. Signed-off-by: Qian Zhang <qian.zhang@oss.qualcomm.com>
FROMLIST: crypto: qce - Add runtime PM and interconnect bandwidth sca…
Add Camera Support for Hamoa EVK
FROMLIST: move WCN7850 workaround to the caller and Add WCN6855 firmware priority selection feature
Enable cpufreq cooling devices
Fix BUF_DONE_IRQ_STATUS_RDI_OFFSET calculation for csid lite on sa8775p platform. The offset should be 0 for csid lite on sa8775p, Link: https://lore.kernel.org/linux-arm-msm/20260313-vfelite_fix-v2-1-7014429c8345@oss.qualcomm.com/ Fixes: ed03e99 ("media: qcom: camss: Add support for CSID 690") Signed-off-by: Wenmeng Liu <wenmeng.liu@oss.qualcomm.com>
Fix the mismatch between clock list and clock rate table for CSID lite instances. The current implementation has 5 clocks defined but only 2 are actually needed (vfe_lite_csid and vfe_lite_cphy_rx), while the clock rate table doesn't match this configuration. Update both clock list and rate table to maintain consistency: - Remove unused clocks: cpas_vfe_lite, vfe_lite_ahb, vfe_lite - Update clock rate table to match the remaining two clocks Link: https://lore.kernel.org/linux-arm-msm/20260313-vfelite_fix-v2-2-7014429c8345@oss.qualcomm.com/ Fixes: ed03e99 ("media: qcom: camss: Add support for CSID 690") Signed-off-by: Wenmeng Liu <wenmeng.liu@oss.qualcomm.com>
Add missing required clocks (cpas_ahb and camnoc_axi) for VFE lite instances on sa8775p platform. These clocks are necessary for proper VFE lite operation: Link: https://lore.kernel.org/linux-arm-msm/20260313-vfelite_fix-v2-3-7014429c8345@oss.qualcomm.com/ Fixes: e7b59e1 ("media: qcom: camss: Add support for VFE 690") Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Signed-off-by: Wenmeng Liu <wenmeng.liu@oss.qualcomm.com>
Update TSENS thermal zone for Hamoa
Required vco rate is set by programming decimal and fraction from 64 bit calculation. This programmed rate is not exactly matching the requested rate and corresponding recalc_rate is having rounding error due to this delta. When setting byte_clk and byte_intf_clk from this pll, set_rate on byte_intf_clk resulting in dividers getting reprogrammed, which are already set from byte_clk. Convert this recalc_rate to KHz and back to Hz to round up this delta in calculation. Signed-off-by: Prahlad Valluru <venkata.valluru@oss.qualcomm.com> Link: https://lore.kernel.org/all/20251125-msm-dsi-phy-7nm-clk-rate-v1-1-17141806e3a0@oss.qualcomm.com/
Adding config options for Docker/Kubernetes support in qcom.config Signed-off-by: Gangabhavani Yenugula <gyenugul@qti.qualcomm.com>
Fix comment typo in camx EL2 dtso.
A race condition is occasionally observed on the RB8 platform where the APPS processor removes its turbo vote from the LCX and LMX rails immediately after receiving the handover interrupt from firmware. At that moment, the ADSP firmware vote has not yet been applied to these rails, causing the PMIC shut down and leading the device to hang. Keep the vote of lcx and lmx rails to SVS_L1 from APPS side instead of completely removing it as a WA until actual fix is available. Signed-off-by: Umang Chheda <umang.chheda@oss.qualcomm.com>
WORKAROUND: remoteproc: qcom: Fix RB8 device hung issue
QCLINUX: arm64: configs: Added Docker/Kubernetes support in qcom.config
QCLINUX: debug: Enable ATH11K CFR
Fix Lemans Vfe lite can`t work issue
FROMLIST: drm/msm/dsi/phy: fix rounding error in recalc_rate
FROMGIT: wifi: ath11k: Add single shot/periodic CFR capture support
…rmal zone configuration" This reverts commit d7fab2f.
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
20 participants
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.
This PR reverts commit d7fab2f
("FROMLIST: arm64: dts: qcom: qcs6490-rb3gen2: Adjust tsens thermal zone configuration").
The reverted change updated TSENS thermal trip thresholds on qcs6490-rb3gen2
and removed CPU cooling maps.
This revert restores the previous thermal zone configuration.