Prepare qcom-next based on tag 'Linux 7.1' of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git#742
Open
sgaud-quic wants to merge 1249 commits into
Conversation
Different stream IDs from VPU would be associated to one of these CB. Multiple CBs are needed to increase the IOVA for the video usecases like higher concurrent sessions. 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>
Depending on the buffer type (input, output and internal), associated context bank is selected, if available. Fallback to parent device for backward compatibility. 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>
…y Linux Most Qualcomm platforms feature a inhouse hypervisor (such as Gunyah or QHEE), which typically handles IOMMU configuration. This includes mapping memory regions and device memory resources for remote processors by intercepting qcom_scm_pas_auth_and_reset() calls. These mappings are later removed during teardown. Additionally, SHM bridge setup is required to enable memory protection for both remoteproc metadata and its memory regions. When the hypervisor is absent, the operating system must perform these configurations instead. Support for handling IOMMU and SHM setup in the absence of a hypervisor is now in place. Extend the Iris driver to enable this functionality on platforms where IOMMU is managed by Linux (i.e., non-Gunyah, non-QHEE). Additionally, the Iris driver must map the firmware and its required resources to the firmware SID, which is now specified via the device tree. Link: https://lore.kernel.org/lkml/20250819165447.4149674-12-mukesh.ojha@oss.qualcomm.com/ Signed-off-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com> Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
The Qualcomm MDT loader changed qcom_mdt_pas_load() to take only four arguments and use the PAS context for relocation and memory handling. Update the iris firmware loading path to match that interface by dropping the temporary memremap/memunmap flow, removing the extra mem_virt argument from qcom_mdt_pas_load(), and simplifying the error path accordingly. This keeps the iris driver aligned with the SCM/PAS loader changes and fixes the build failure caused by the old five-argument call. Signed-off-by: Gourav Kumar <gouravk@qti.qualcomm.com>
EPSS L3 hardware on Shikra SoC is similar to EPSS/OSM L3 hardware on other Qualcomm SoCs. Use the existing qcom,osm-l3 bindings to describe it. Signed-off-by: Murali Krishna <mur@qti.qualcomm.com>
…alcomm Shikra SoC Document the EPSS L3 interconnect provider binding for Qualcomm Shikra SoC. The Shikra EPSS L3 block is similar to existing Qualcomm EPSS/OSM L3 providers, but supports only up to 12 frequency lookup table entries. Co-developed-by: Odelu Kukatla <odelu.kukatla@oss.qualcomm.com> Signed-off-by: Odelu Kukatla <odelu.kukatla@oss.qualcomm.com> Signed-off-by: Raviteja Laggyshetty <raviteja.laggyshetty@oss.qualcomm.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260603-shikra_epss_l3-v3-1-3c2e0b796e78@oss.qualcomm.com
The Qualcomm Shikra RPMCC has the clocks same as Agatti (QCM2290) RPMCC. Hence, add support to use the QCM2290 RPMCC compatible as fallback for Shikra RPMCC. Signed-off-by: Imran Shaik <imran.shaik@oss.qualcomm.com>
Add support for missing RF_CLK1/RF_CLK2 clocks on Qualcomm Agatti (QCM2290) SoC. Drop the Shikra specific clock table since it matches QCM2290 RPMCC and can be handled via DT compatible fallback. Signed-off-by: Imran Shaik <imran.shaik@oss.qualcomm.com>
Update Shikra RPMCC node to use the Agatti (QCM2290) RPMCC as fallback compatible. Signed-off-by: Imran Shaik <imran.shaik@oss.qualcomm.com>
Add video firmware node to enable video kvm on the hamoa. Signed-off-by: Renjiang Han <renjiang@qti.qualcomm.com>
Devres APIs are intended for use in drivers, and they should be avoided in shared subsystem code which is being used by multiple drivers. Avoid using devres based allocations in the reboot-mode subsystem and manually free the resources. Replace devm_kzalloc with kzalloc and handle memory cleanup explicitly. Fixes: 4fcd504 ("power: reset: add reboot mode driver") Signed-off-by: Shivendra Pratap <shivendra.pratap@oss.qualcomm.com> Link: https://lore.kernel.org/r/20251109-arm-psci-system_reset2-vendor-reboots-v17-1-46e085bca4cc@oss.qualcomm.com Signed-off-by: Anurag Pateriya <apateriy@qti.qualcomm.com> Upstream-Status: Submitted [https://lore.kernel.org/r/20251109-arm-psci-system_reset2-vendor-reboots-v17-1-46e085bca4cc@oss.qualcomm.com]
The reboot-mode driver does not have a strict requirement for device-based registration. It primarily uses the device's of_node to read mode-<cmd> properties. Remove the dependency on struct device and introduce support for firmware node (fwnode) based registration. This enables drivers that are not associated with a struct device to leverage the reboot-mode framework. Signed-off-by: Shivendra Pratap <shivendra.pratap@oss.qualcomm.com> Link: https://lore.kernel.org/r/20251109-arm-psci-system_reset2-vendor-reboots-v17-2-46e085bca4cc@oss.qualcomm.com Signed-off-by: Anurag Pateriya <apateriy@qti.qualcomm.com> Upstream-Status: Submitted [https://lore.kernel.org/r/20251109-arm-psci-system_reset2-vendor-reboots-v17-2-46e085bca4cc@oss.qualcomm.com]
Current reboot-mode supports a single 32-bit argument for any supported mode. Some reboot-mode based drivers may require passing two independent 32-bit arguments during a reboot sequence, for uses-cases, where a mode requires an additional argument. Such drivers may not be able to use the reboot-mode driver. For example, ARM PSCI vendor-specific resets, need two arguments for its operation – reset_type and cookie, to complete the reset operation. If a driver wants to implement this firmware-based reset, it cannot use reboot-mode framework. Introduce 64-bit magic values in reboot-mode driver to accommodate dual 32-bit arguments when specified via device tree. In cases, where no second argument is passed from device tree, keep the upper 32-bit of magic un-changed(0) to maintain backward compatibility. Update the current drivers using reboot-mode for a 64-bit magic value. Reviewed-by: Umang Chheda <umang.chheda@oss.qualcomm.com> Reviewed-by: Nirmesh Kumar Singh <nirmesh.singh@oss.qualcomm.com> Signed-off-by: Shivendra Pratap <shivendra.pratap@oss.qualcomm.com> Link: https://lore.kernel.org/r/20251109-arm-psci-system_reset2-vendor-reboots-v17-3-46e085bca4cc@oss.qualcomm.com Signed-off-by: Anurag Pateriya <apateriy@qti.qualcomm.com> Upstream-Status: Submitted [https://lore.kernel.org/r/20251109-arm-psci-system_reset2-vendor-reboots-v17-3-46e085bca4cc@oss.qualcomm.com]
Implement PSCI SYSTEM_RESET2 vendor-specific resets by registering with the reboot-mode framework. A late_initcall registers the PSCI node's reboot-mode child, a reboot-mode write callback sets reset_type/cookie for the subsequent notifier, and a panic notifier clears the vendor reset state to avoid stale values after a kernel panic. Signed-off-by: Shivendra Pratap <shivendra.pratap@oss.qualcomm.com> Link: https://lore.kernel.org/r/20251109-arm-psci-system_reset2-vendor-reboots-v17-7-46e085bca4cc@oss.qualcomm.com Signed-off-by: Anurag Pateriya <apateriy@qti.qualcomm.com> Upstream-Status: Submitted [https://lore.kernel.org/r/20251109-arm-psci-system_reset2-vendor-reboots-v17-7-46e085bca4cc@oss.qualcomm.com]
… set reboot_mode_create_device() and reboot_mode_unregister_device() unconditionally dereference reboot->dev->driver->name to name the sysfs device. psci_init_vendor_reset() allocates a reboot_mode_driver with kzalloc (so reboot->dev == NULL) and never sets reboot->dev, causing a NULL pointer dereference at boot: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000068 pc : reboot_mode_register+0x334/0x3b8 psci_init_vendor_reset+0xdc/0x128 Kernel panic - not syncing: Oops: Fatal exception The offset 0x68 is the 'driver' pointer inside struct device on arm64, confirming that reboot->dev itself is NULL. Fix this by adding a 'name' field to struct reboot_mode_driver. reboot_mode_create_device() and reboot_mode_unregister_device() now prefer reboot->name; they fall back to reboot->dev->driver->name only when reboot->name is NULL, and return -EINVAL / return early if neither source is available. Set reboot->name = "psci" in psci_init_vendor_reset() so the sysfs device is correctly named. Existing device-based callers (nvmem-reboot-mode, syscon-reboot-mode, qcom-pon) are unaffected: they set reboot->dev before calling devm_reboot_mode_register(), so the fallback path is taken as before. Fixes: cfaf0a9 ("power: reset: reboot-mode: Expose sysfs for registered reboot_modes") Fixes: 614b17a ("firmware: psci: Implement vendor-specific resets as reboot-mode") Reported-by: LAVA job 91409 <https://lava-oss.qualcomm.com/scheduler/job/91409> Signed-off-by: Salendarsingh Gaud <sgaud@qti.qualcomm.com> Signed-off-by: Anurag Pateriya <apateriy@qti.qualcomm.com> Upstream-Status: Inappropriate [workaround]
Add lane_positions to the DPHY configuration struct. This data-field represents the physical positions of the data-lanes indexed by lane number. Link: https://lore.kernel.org/all/20260325-dphy-params-extension-v1-1-c6df5599284a@linaro.org/ Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Pass an array of data-lane polarities from controller to PHY. A true value means the lane polarity is inverted. Link: https://lore.kernel.org/all/20260325-dphy-params-extension-v1-2-c6df5599284a@linaro.org/ Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
We need to identify which lane is the clock-lane as many different PHYs allow for a range of lanes, potentially any of the lanes to be the clock input lane on a PHY. Link: https://lore.kernel.org/all/20260325-dphy-params-extension-v1-3-c6df5599284a@linaro.org/ Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Specify the polarity of the clock lane in DPHY mode. When true this bool means the polarity is inverted. Link: https://lore.kernel.org/all/20260325-dphy-params-extension-v1-4-c6df5599284a@linaro.org/ Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Add a base schema initially compatible with x1e80100 to describe MIPI CSI2 PHY devices. The hardware can support both CPHY, DPHY and a special split-mode DPHY. We capture those modes as: - PHY_QCOM_CSI2_MODE_DPHY - PHY_QCOM_CSI2_MODE_CPHY - PHY_QCOM_CSI2_MODE_SPLIT_DPHY 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. Link: https://lore.kernel.org/all/20260326-x1e-csi2-phy-v5-1-0c0fc7f5c01b@linaro.org/ Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@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.
Data-lane and clock lane positioning and polarity selection via newly
amended struct phy_configure_opts_mipi_dphy{} is supported.
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.
The register init sequence table is imported verbatim from the existing
CAMSS csiphy driver. A follow-up series will rework the table to extract
the repetitive per-lane pattern into a loop.
Link: https://lore.kernel.org/all/20260326-x1e-csi2-phy-v5-2-0c0fc7f5c01b@linaro.org/
Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@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. Drop the legacy high-level 0p8 and 1p2 supplies as required, each PHY has its own individual rails. The old binding is still valid but with individual nodes we define the rails in the CSIPHY sub-nodes. Link: https://lore.kernel.org/all/20260326-b4-linux-next-25-03-13-dtsi-x1e80100-camss-v11-1-5b93415be6dd@linaro.org/ Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@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. Link: https://lore.kernel.org/all/20260326-b4-linux-next-25-03-13-dtsi-x1e80100-camss-v11-2-5b93415be6dd@linaro.org/ Reviewed-by: Christopher Obbard <christopher.obbard@linaro.org> Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
…ries The original iommus list included entries for ICP and BPS/IPE S1 contexts. Only the five S1 HLOS stream IDs are required by the CAMSS ISP hardware: IFE/IFE_LITE read and write, SFE read and write, and CDM IFE. The remaining entries serve other hardware blocks which will be described in their own nodes as support is added. Link: https://lore.kernel.org/all/20260326-b4-linux-next-25-03-13-dtsi-x1e80100-camss-v11-3-5b93415be6dd@linaro.org/ Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Use devm_of_platform_populate() to populate subs in the tree. Link: https://lore.kernel.org/all/20260326-b4-linux-next-25-03-13-dtsi-x1e80100-camss-v11-4-5b93415be6dd@linaro.org/ Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Reviewed-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
…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. Link: https://lore.kernel.org/all/20260326-b4-linux-next-25-03-13-dtsi-x1e80100-camss-v11-5-5b93415be6dd@linaro.org/ Reviewed-by: Christopher Obbard <christopher.obbard@linaro.org> Tested-by: Christopher Obbard <christopher.obbard@linaro.org> Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Reviewed-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
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. Link: https://lore.kernel.org/all/20260326-b4-linux-next-25-03-13-dtsi-x1e80100-camss-v11-6-5b93415be6dd@linaro.org/ Reviewed-by: Christopher Obbard <christopher.obbard@linaro.org> Tested-by: Christopher Obbard <christopher.obbard@linaro.org> Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
x1e is the first CAMSS SoC to use the new PHY interface. Drop the redundant legacy CSIPHY descriptions. Link: https://lore.kernel.org/all/20260326-b4-linux-next-25-03-13-dtsi-x1e80100-camss-v11-7-5b93415be6dd@linaro.org/ Reviewed-by: Christopher Obbard <christopher.obbard@linaro.org> Tested-by: Christopher Obbard <christopher.obbard@linaro.org> Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Reviewed-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
Add bindings for Camera Subsystem (CAMSS) on the Qualcomm Kaanapali platform. The Kaanapali platform provides: - 6 x CSIPHY (CSI Physical Layer) - 3 x TPG (Test Pattern Generator) - 3 x CSID (CSI Decoder) - 2 x CSID Lite - 3 x VFE (Video Front End), 5 RDI per VFE - 2 x VFE Lite, 4 RDI per VFE Lite Link: https://lore.kernel.org/all/20260508-kaanapali-camss-v13-1-2541d8e55651@oss.qualcomm.com/ Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by: Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>
Add support for Kaanapali in the camss driver. Add high level resource information along with the bus bandwidth votes. Module level detailed resource information will be enumerated in the following patches of the series. Link: https://lore.kernel.org/all/20260508-kaanapali-camss-v13-2-2541d8e55651@oss.qualcomm.com/ Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Signed-off-by: Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>
# Conflicts: # arch/arm64/boot/dts/qcom/lemans.dtsi
# Conflicts: # arch/arm64/boot/dts/qcom/monaco.dtsi
# Conflicts: # arch/arm64/boot/dts/qcom/kaanapali.dtsi
# Conflicts: # arch/arm64/configs/defconfig
# Conflicts: # arch/arm64/boot/dts/qcom/Makefile
# Conflicts: # arch/arm64/boot/dts/qcom/qcs8300-ride.dts # drivers/bluetooth/hci_qca.c # drivers/phy/qualcomm/phy-qcom-qmp-pcie.c
# Conflicts: # Documentation/devicetree/bindings/crypto/qcom,inline-crypto-engine.yaml # drivers/gpu/drm/bridge/lontium-lt9611c.c # drivers/misc/fastrpc.c # drivers/remoteproc/qcom_q6v5_pas.c # drivers/soc/qcom/smem.c # sound/soc/qcom/qdsp6/q6prm.h
sgaud-quic
force-pushed
the
qcom-next-staging-7.1-20260618
branch
from
dcfeb77 to
4607cd8
Compare
Test Matrix
|
…ault"" This reverts commit 50b4780.
Adding merge log file and topic_SHA1 file Signed-off-by: Salendarsingh Gaud <sgaud@qti.qualcomm.com>
sgaud-quic
force-pushed
the
qcom-next-staging-7.1-20260618
branch
from
4607cd8 to
681dd63
Compare
Test Matrix
|
Test Matrix
|
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.
Name SHA Commits
tech/bsp/clk d278a36 18
tech/bsp/devfreq a0c2f21 6
tech/bsp/ec 643c24b 2
tech/bsp/soc-infra 6aff3e6 25
tech/bsp/pinctrl 3f1acf8 1
tech/bsp/remoteproc a7b9b6d 10
tech/bus/peripherals feb0c22 8
tech/bus/pci/all 7650854 26
tech/bus/pci/phy aaf8ef1 4
tech/bus/usb/dwc e929e6d 3
tech/bus/usb/phy 984aa89 36
tech/debug/hwtracing 25c6a74 30
tech/pmic/misc a2dd2bb 7
tech/mem/iommu 2831e57 7
tech/mm/audio/all cab3357 10
tech/mm/camss fdc4e57 34
tech/mm/drm a26c405 69
tech/mm/fastrpc ca4fac2 10
tech/mm/video 1bc33f6 166
tech/mm/gpu f67b888 6
tech/net/ath 954361e 22
tech/net/phy a3602e9 1
tech/net/bluetooth c8f5ae9 1
tech/pm/power 2d42c35 9
tech/pm/thermal 3f033cb 7
tech/security/crypto 53b86cb 15
tech/security/ice c72a252 18
tech/storage/all 6a34168 4
tech/all/dt/qcs6490 abb8a3a 22
tech/all/dt/qcs9100 fe7da88 23
tech/all/dt/qcs8300 fddb012 24
tech/all/dt/qcs615 277da5d 11
tech/all/dt/agatti c828f10 1
tech/all/dt/hamoa f070434 31
tech/all/dt/glymur 7712b84 35
tech/all/dt/kaanapali f1c20f5 18
tech/all/dt/pakala d7f29fa 9
tech/all/config 71f787f 72
tech/overlay/dt 587d3d5 60
tech/all/workaround d29701b 25
tech/mproc/all 0aa90b7 3
tech/noup/debug/all cbdd4bb 26
tech/hwe/unoq b2ea57b 5
early/hwe/shikra/drivers e9d7c3b 174
early/hwe/shikra/dt 95e145f 107