Qcom next staging 7.2 rc5 20260730 optee - #927
Open
Salendarsingh Gaud (sgaud-quic) wants to merge 1469 commits into
Open
Qcom next staging 7.2 rc5 20260730 optee#927Salendarsingh Gaud (sgaud-quic) wants to merge 1469 commits into
Salendarsingh Gaud (sgaud-quic) wants to merge 1469 commits into
Conversation
This reverts commit a05911a. Signed-off-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
This reverts commit 432464b. Signed-off-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
…i platform" This reverts commit 207c29a. Signed-off-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
… AR50LT" This reverts commit 936dbb1. Signed-off-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
…orm" This reverts commit 74b9e15. Signed-off-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
…ceived info" This reverts commit 4ec08f9. Signed-off-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
This reverts commit f9c9295. Signed-off-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
…deo core" This reverts commit 3e378a1. Signed-off-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
…e platform" This reverts commit ac939cb. Signed-off-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
…ndwidth voting" This reverts commit 476f19f. Signed-off-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
…nterrupt mask" This reverts commit 6705400. Signed-off-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
This reverts commit 9b6aa5d. Signed-off-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
This reverts commit 14b2a6c. Signed-off-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
…_op" This reverts commit d4c2c8c. Signed-off-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
…are capabilities" This reverts commit e4c043f. Signed-off-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
…rted" This reverts commit 8f986e3. Signed-off-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
…ack" This reverts commit ee2b755. Signed-off-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
Some Iris platforms support both Gen1 and Gen2 HFI firmware images. Update the firmware loading logic to handle this generically by preferring Gen2 when available, while safely falling back to Gen1 when required. The firmware loading logic is updated with the following priority: 1. Device Tree (`firmware-name`): If specified, load unconditionally. 2. Gen2 default : If no DT override exists, select the Gen2 firmware descriptor when present and attempt to load the corresponding firmware image. 3. Gen1 Fallback: If loading the Gen2 firmware fails and a Gen1 descriptor is available, retry with the Gen1 firmware image. When a platform provides both Gen1 and Gen2 firmware descriptors and the firmware is loaded via a DT override, the driver detects the firmware generation at runtime before authentication by inspecting the firmware data. The firmware is classified as Gen2 if the QC_IMAGE_VERSION_STRING starts with "vfw" or matches the "video-firmware.N.M" format with N >= 2. If a Gen1 firmware image is detected in this case, the driver switches to the Gen1 firmware descriptor and associated platform data so that the correct HFI implementation is used. This change makes firmware generation detection platform‑agnostic, preserves DT overrides, prefers newer Gen2 firmware when available, and maintains compatibility with platforms that only support Gen1. Link: https://lore.kernel.org/all/20260709-iris-ar50lt-v7-1-76af9dd4d1f6@oss.qualcomm.com/ Signed-off-by: Dikshita Agarwal <dikshita.agarwal@oss.qualcomm.com> Co-developed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
UBWC configuration is not applicable to all SoCs. Add a check to avoid configuring UBWC during sys init on unsupported platforms. Link: https://lore.kernel.org/all/20260709-iris-ar50lt-v7-2-76af9dd4d1f6@oss.qualcomm.com/ Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Dikshita Agarwal <dikshita.agarwal@oss.qualcomm.com> Reviewed-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com> Reviewed-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
The IRIS_FMT_foo defines are only used for indexing values in the format enumeration arrays. However this kind of enumeration doesn't follow the V4L2 logic (which expects an array with consequtive indexing rather than a sparse array) and complicates adding support for platforms which support different sets of formats. Drop this enumeration and use flat lists of supported formats. Link: https://lore.kernel.org/all/20260709-iris-ar50lt-v7-3-76af9dd4d1f6@oss.qualcomm.com/ Reviewed-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
…bilities The raw formats supported by Iris were previously advertised unconditionally, assuming UBWC support on all platforms. However, some platforms do not support UBWC which results in incorrect format capability exposure. Use the UBWC configuration provided by the platform to dynamically filter raw formats at runtime. If UBWC is not supported, UBWC-based formats are omitted from the advertised capability list, while linear formats remain available. Link: https://lore.kernel.org/all/20260709-iris-ar50lt-v7-4-76af9dd4d1f6@oss.qualcomm.com/ Signed-off-by: Dikshita Agarwal <dikshita.agarwal@oss.qualcomm.com> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
The set_preset_registers sequence is currently shared across all supported devices. Starting with Qualcomm QCM2290 (AR50LT), the register programming would differ. Move set_preset_register into a vpu_op to allow per-device customization. This change prepares the driver for upcoming hardware variants. No functional change so far for existing devices. Link: https://lore.kernel.org/all/20260709-iris-ar50lt-v7-5-76af9dd4d1f6@oss.qualcomm.com/ Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Dikshita Agarwal <dikshita.agarwal@oss.qualcomm.com> Reviewed-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com> Reviewed-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
The interrupt_init sequence is currently shared across all supported devices. Starting with Qualcomm QCM2290 (AR50LT), the register programming would differ. Move interrupt_init into a vpu_op to allow per-device customization. This change prepares the driver for upcoming hardware variants. No functional change so far for existing devices. Link: https://lore.kernel.org/all/20260709-iris-ar50lt-v7-6-76af9dd4d1f6@oss.qualcomm.com/ Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Dikshita Agarwal <dikshita.agarwal@oss.qualcomm.com> Reviewed-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com> Reviewed-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
On AR50LT platforms AbsolutelyPerfectRouting (ARP) needs to be disabled so firmware can configure the ARP internal buffer as non-secure for encoder usage. In preparation of adding support for AR50LT platforms, add an optional disable_arp callback to the VPU ops and invoke it from core init and resume paths. No functional change for existing platforms. Link: https://lore.kernel.org/all/20260709-iris-ar50lt-v7-7-76af9dd4d1f6@oss.qualcomm.com/ Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Dikshita Agarwal <dikshita.agarwal@oss.qualcomm.com> Reviewed-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com> Reviewed-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
… mask For AR50LT core, the value of WRAPPER_INTR_STATUS_A2HWD_BMASK differs from the currently supported VPUs. In preparation for adding AR50LT support in subsequent patches, introduce a platform data field, wd_intr_mask, to capture the watchdog interrupt bitmask per platform. Link: https://lore.kernel.org/all/20260709-iris-ar50lt-v7-8-76af9dd4d1f6@oss.qualcomm.com/ Signed-off-by: Dikshita Agarwal <dikshita.agarwal@oss.qualcomm.com> Reviewed-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com> Reviewed-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
…voting AR50LT require explicit instantaneous bandwidth (IB) voting in addition to average bandwidth (AB) when configuring interconnect QoS. This requirement is due to QSB (Qualcomm System Bus) 128b to QNS ( Qualcomm Network Switch) 256b conversion at video noc in AR50LT which is not needed for other IRIS cores. In preparation of adding support for AR50LT core, introduce platform-configurable IB multiplier and enable IB voting for all SoCs. Existing platforms default to IB == AB, while AR50LT requires 2x peak bandwidth. Link: https://lore.kernel.org/all/20260709-iris-ar50lt-v7-9-76af9dd4d1f6@oss.qualcomm.com/ Signed-off-by: Dikshita Agarwal <dikshita.agarwal@oss.qualcomm.com> Reviewed-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com> Reviewed-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
AR50Lt doesn't support HFI_PROPERTY_PARAM_WORK_ROUTE. Tables for AR50LT won't have corresponding entry in the capability tables. Let iris_set_pipe() silently skip propgramming the property if there is no corresponding capability. Link: https://lore.kernel.org/all/20260709-iris-ar50lt-v7-10-76af9dd4d1f6@oss.qualcomm.com/ Reviewed-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com> Reviewed-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Add power sequence for ar5lt core. Add register handling for ar50lt by hooking up vpu op with ar50lt specific implemtation or resue from earlier generation wherever feasible. Link: https://lore.kernel.org/all/20260709-iris-ar50lt-v7-11-76af9dd4d1f6@oss.qualcomm.com/ Signed-off-by: Dikshita Agarwal <dikshita.agarwal@oss.qualcomm.com> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
AR50Lt with the Gen1 firmware requires host to read HFI_PROPERTY_CONFIG_BUFFER_REQUIREMENTS property, otherwise it doesn't update internal data and fails the HFI_CMD_SESSION_LOAD_RESOURCES command. Implement minimal support for querying the properties from the firmware. It is used by one of the following patches, adding support for Agatti. Link: https://lore.kernel.org/all/20260709-iris-ar50lt-v7-12-76af9dd4d1f6@oss.qualcomm.com/ Reviewed-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com> Reviewed-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Upon receiving data for HFI_PROPERTY_CONFIG_BUFFER_REQUIREMENTS the driver should update buffer sizes and counts from the received data. Implement corresponding functionality updating buffers data. This will be used for upcoming support of AR50Lt platforms with Gen1 firmware. Link: https://lore.kernel.org/all/20260709-iris-ar50lt-v7-13-76af9dd4d1f6@oss.qualcomm.com/ Reviewed-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
# Conflicts: # arch/arm64/boot/dts/qcom/Makefile # arch/arm64/boot/dts/qcom/talos.dtsi
# Conflicts: # arch/arm64/boot/dts/qcom/qcs8300-ride.dts # drivers/bluetooth/hci_qca.c # drivers/phy/qualcomm/phy-qcom-qmp-pcie.c
# Conflicts: # drivers/firmware/qcom/Kconfig # drivers/firmware/qcom/Makefile
# Conflicts: # drivers/dma/qcom/bam_dma.c # drivers/misc/fastrpc.c # sound/soc/qcom/qdsp6/q6prm.h # sound/soc/qcom/sc8280xp.c
# Conflicts: # Documentation/devicetree/bindings/sound/qcom,q6apm-dai.yaml
…emory and SMMU mappings" This change have introduced an issue on multimedia builds where AudioRecord is broken on monaco-evk board. [ 153.325884] q6apm-lpass-dais 3000000.remoteproc:glink-edge:gpr:service@1:bedais: Failed to start APM port 19 [ 153.335982] q6apm-lpass-dais 3000000.remoteproc:glink-edge:gpr:service@1:bedais: ASoC error (-110): at soc_dai_trigger() on SEC_MI2S_TX [ 153.348489] MultiMedia2 Capture: ASoC error (-110): at dpcm_be_dai_trigger() on MultiMedia2 Capture [ 153.357875] MultiMedia2 Capture: ASoC error (-110): trigger FE cmd: 1 failed Revert the change for now, to fix the issue. This reverts commit cd0f5c6. Signed-off-by: Salendarsingh Gaud <sgaud@qti.qualcomm.com>
This is causing bootup crash on hamoa-iot-evk as the dependency firmware is still not present. [ 8.804602][ T243] pstate: 41400005 (nZcv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) [ 8.804603][ T243] pc : spi_geni_init+0x44/0x858 [spi_geni_qcom] [ 8.804609][ T243] lr : spi_geni_init+0x38/0x858 [spi_geni_qcom] [ 8.804611][ T243] sp : ffff8000821eb7f0 [ 8.804612][ T243] x29: ffff8000821eb7f0 x28: 0000000000000000 x27: 000000000000000c [ 8.804614][ T243] x26: ffffd1d854b495f8 x25: ffff0008129508e0 x24: ffffd1d854b49638 [ 8.804616][ T243] x23: ffff800082d54068 x22: ffff0008124a1000 x21: ffff000802ed2010 [ 8.804618][ T243] x20: a89ad1d854b41a5c x19: ffff0008124a16c0 x18: ffffd1d874482008 [ 8.804620][ T243] x17: ffffd1d874481ff0 x16: ffffd1d872769b48 x15: 0000000000802c80 [ 8.804622][ T243] x14: ffff8000821eb130 x13: 0000000160000008 x12: 0000000000000010 [ 8.804624][ T243] x11: 0000000000000000 x10: ffff00080d8ee868 x9 : ffffd1d872b9c9c4 [ 8.804626][ T243] x8 : ffff8000821eb698 x7 : 0000000000000000 x6 : 0000000000000001 [ 8.804628][ T243] x5 : ffffd1d87402b000 x4 : ffffd1d87402b460 x3 : 0000000000000000 [ 8.804630][ T243] x2 : ffff00080fc94d40 x1 : ffff00080fc94d40 x0 : 0000000000000000 [ 8.804632][ T243] Call trace: [ 8.804633][ T243] spi_geni_init+0x44/0x858 [spi_geni_qcom] (P) [ 8.804636][ T243] spi_geni_probe+0x30c/0x3f0 [spi_geni_qcom] [ 8.804638][ T243] platform_probe+0x64/0xa8 [ 8.804642][ T243] really_probe+0xc8/0x3f0 [ 8.804645][ T243] __driver_probe_device+0x1b4/0x1f0 [ 8.804647][ T243] driver_probe_device+0x44/0x128 Revert the commit for now, to resolve bootup issue. This reverts commit 181bef7. Signed-off-by: Salendarsingh Gaud <sgaud@qti.qualcomm.com>
…emory and SMMU mappings" This change have introduced an issue on multimedia builds where AudioRecord is broken on lemans-evk board. [ 840.168044] q6apm-lpass-dais 30000000.remoteproc:glink-edge:gpr:service@1:bedais: Failed to start APM port 21 [ 840.178229] q6apm-lpass-dais 30000000.remoteproc:glink-edge:gpr:service@1:bedais: ASoC error (-110): at soc_dai_trigger() on TERT_MI2S_TX [ 840.190901] MultiMedia2 Capture: ASoC error (-110): at dpcm_be_dai_trigger() on MultiMedia2 Capture [ 840.200277] MultiMedia2 Capture: ASoC error (-110): trigger FE cmd: 1 failed Revert the change for now, to fix the issue. This reverts commit f75b90a.
Adding merge log file and topic_SHA1 file Signed-off-by: Salendarsingh Gaud <sgaud@qti.qualcomm.com>
Qcom platforms has the legacy of using non-standard SCM calls splintered over the various kernel drivers. These SCM calls aren't compliant with the standard SMC calling conventions which is a prerequisite to enable migration to the FF-A specifications from Arm. OP-TEE as an alternative trusted OS to Qualcomm TEE (QTEE) can't support these non-standard SCM calls. And even for newer architectures using S-EL2 with Hafnium support, QTEE won't be able to support SCM calls either with FF-A requirements coming in. And with both OP-TEE and QTEE drivers well integrated in the TEE subsystem, it makes further sense to reuse the TEE bus client drivers infrastructure. The added benefit of TEE bus infrastructure is that there is support for discoverable/enumerable services. With that client drivers don't have to manually invoke a special SCM call to know the service status. So enable the generic Peripheral Authentication Service (PAS) provided by the firmware. It acts as the common layer with different TZ backends plugged in whether it's an SCM implementation or a proper TEE bus based PAS service implementation. Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com> Link: https://lore.kernel.org/all/20260427095603.1157963-5-sumit.garg@kernel.org/
With the availability of generic PAS service, let's add SCM calls as a backend to keep supporting legacy QTEE interfaces. The exported qcom_scm* wrappers will get dropped once all the client drivers get migrated as part of future patches. Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com> Link: https://lore.kernel.org/all/20260427095603.1157963-5-sumit.garg@kernel.org/
Add support for Peripheral Authentication Service (PAS) driver based on TEE bus with OP-TEE providing the backend PAS service implementation. The TEE PAS service ABI is designed to be extensible with additional API as PTA_QCOM_PAS_CAPABILITIES. This allows to accommodate any future extensions of the PAS service needed while still maintaining backwards compatibility. Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com> Link: https://lore.kernel.org/all/20260427095603.1157963-5-sumit.garg@kernel.org/
Switch qcom_q6v5_pas client driver over to generic PAS TZ APIs. Generic PAS TZ service allows to support multiple TZ implementation backends like QTEE based SCM PAS service, OP-TEE based PAS service and any further future TZ backend service. Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com> Link: https://lore.kernel.org/all/20260427095603.1157963-5-sumit.garg@kernel.org/
Switch qcom_q6v5_mss client driver over to generic PAS TZ APIs. Generic PAS TZ service allows to support multiple TZ implementation backends like QTEE based SCM PAS service, OP-TEE based PAS service and any further future TZ backend service. Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com> Link: https://lore.kernel.org/all/20260427095603.1157963-5-sumit.garg@kernel.org/
Switch mdtloader client driver over to generic PAS TZ APIs. Generic PAS TZ service allows to support multiple TZ implementation backends like QTEE based SCM PAS service, OP-TEE based PAS service and any further future TZ backend service. Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com> Link: https://lore.kernel.org/all/20260427095603.1157963-5-sumit.garg@kernel.org/
Switch qcom_wcnss client driver over to generic PAS TZ APIs. Generic PAS TZ service allows to support multiple TZ implementation backends like QTEE based SCM PAS service, OP-TEE based PAS service and any further future TZ backend service. Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com> Link: https://lore.kernel.org/all/20260427095603.1157963-5-sumit.garg@kernel.org/
Select PAS generic service driver to enable support for multiple PAS backends like OP-TEE in addition to SCM. Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com> Link: https://lore.kernel.org/all/20260427095603.1157963-5-sumit.garg@kernel.org/
Switch drm/msm client drivers over to generic PAS TZ APIs. Generic PAS TZ service allows to support multiple TZ implementation backends like QTEE based SCM PAS service, OP-TEE based PAS service and any further future TZ backend service. Acked-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com> Link: https://lore.kernel.org/all/20260427095603.1157963-5-sumit.garg@kernel.org/
Switch qcom media client drivers over to generic PAS TZ APIs. Generic PAS TZ service allows to support multiple TZ implementation backends like QTEE based SCM PAS service, OP-TEE based PAS service and any further future TZ backend service. Along with that pass proper PAS ID to set_remote_state API. As per testing the SCM backend just ignores it while OP-TEE makes use of it to for proper book keeping purpose. Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com> Link: https://lore.kernel.org/all/20260427095603.1157963-5-sumit.garg@kernel.org/
Switch ipa client driver over to generic PAS TZ APIs. Generic PAS TZ service allows to support multiple TZ implementation backends like QTEE based SCM PAS service, OP-TEE based PAS service and any further future TZ backend service. Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com> Link: https://lore.kernel.org/all/20260427095603.1157963-5-sumit.garg@kernel.org/
Switch ath12k client driver over to generic PAS TZ APIs. Generic PAS TZ service allows to support multiple TZ implementation backends like QTEE based SCM PAS service, OP-TEE based PAS service and any further future TZ backend service. Acked-by: Jeff Johnson <jjohnson@kernel.org> Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com> Link: https://lore.kernel.org/all/20260427095603.1157963-5-sumit.garg@kernel.org/
Now since all the Qcom SCM client drivers have been migrated over to generic PAS TZ service, let's drop the exported SCM PAS wrappers. Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com> Link: https://lore.kernel.org/all/20260427095603.1157963-5-sumit.garg@kernel.org/
Add Sumit Garg as the maintainer for the Qualcomm generic Peripheral Authentication Service (PAS) as well as the PAS TEE backend driver. Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com> Link: https://lore.kernel.org/all/20260427095603.1157963-5-sumit.garg@kernel.org/
qcom_scm_mem_protect_video_var() is not serviced when PAS is backed by OP-TEE (the TEE owns secure memory protection), so its failure there is expected. Add qcom_pas_is_tee_backed() to report when the active PAS backend is the OP-TEE one, and in iris only treat the SCM failure as fatal when OP-TEE is not on the bus. Signed-off-by: Jorge Ramirez-Ortiz <jorge.ramirez.ortiz@gmail.com>
This reverts commit 6a36c4b.
…lator error spam pm8150_l2 regulator has regulator-max-microvolt set to 3300000 uV, but the underlying pm660_pldo660 hardware uses 8000 uV steps starting from 1504000 uV. Since 3300000 uV is not a valid hardware step, the regulator framework's machine_constraints_voltage() silently rounds it down to the nearest valid step: 3296000 uV (step 224 = 1504000 + 224 * 8000). During MMC/SD card detection cycles, mmc_set_initial_signal_voltage() attempts to set 3.3V signaling by calling mmc_regulator_set_vqmmc(), which uses regulator_set_voltage_triplet() to first try the target voltage (3500000 uV) before falling back to the minimum. Since 3500000 > 3296000, regulator_check_voltage() logs an error: l2: unsupportable voltage range: 3500000-3296000uV The fallback to 3200000 uV succeeds, but if card detection is continuously retrying (e.g., no card present, card detect failure, or initialization errors), this error is logged every ~200ms, spamming the kernel log. Fix this by raising regulator-max-microvolt to 3504000 uV, which is a valid hardware step (step 250 = 1504000 + 250 * 8000). This allows the 3.5V target voltage request to succeed on the first attempt, eliminating the error log. The value is within the SD specification (vqmmc up to 3.6V for 3.3V signaling) and within the hardware range (max 3544000 uV). Fixes: fa7b0cd ("arm64: dts: qcom: Add regulator for Retail and Industrial SOM variants") Signed-off-by: Komal Bajaj <komal.bajaj@oss.qualcomm.com>
Test Matrix
|
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.
No description provided.