Repository navigation
Shikra: retire ad-hoc downstream support, re-port from upstream-accepted + kernel-topics patches - #121
Open
Shiraz Hashim (shashim-quic) wants to merge 365 commits into
Conversation
Tingwei Zhang (quic-tingweiz)
force-pushed
the
resolute-qcom-devel
branch
from
September 22, 2026 02:39
76e7f56 to
99880ec
Compare
Shiraz Hashim (shashim-quic)
force-pushed
the
shikra-port
branch
from
October 5, 2026 13:34
204ce3d to
6688023
Compare
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
Komal Bajaj (Komal-Bajaj)
approved these changes
Oct 6, 2026
Tingwei Zhang (quic-tingweiz)
approved these changes
Oct 9, 2026
…Shikra" This reverts commit 8439255. Shikra platform support in this tree is being retired in favor of the latest community Shikra patches; drop this downstream commit to avoid conflicting with the upstream series. Signed-off-by: Shiraz Hashim <shiraz.hashim@oss.qualcomm.com>
…a SoC" This reverts commit c32e12b. Shikra platform support in this tree is being retired in favor of the latest community Shikra patches; drop this downstream commit to avoid conflicting with the upstream series. Signed-off-by: Shiraz Hashim <shiraz.hashim@oss.qualcomm.com>
This reverts commit d256342. Shikra platform support in this tree is being retired in favor of the latest community Shikra patches; drop this downstream commit to avoid conflicting with the upstream series. Signed-off-by: Shiraz Hashim <shiraz.hashim@oss.qualcomm.com>
This reverts commit b41dfa9. Shikra platform support in this tree is being retired in favor of the latest community Shikra patches; drop this downstream commit to avoid conflicting with the upstream series. Signed-off-by: Shiraz Hashim <shiraz.hashim@oss.qualcomm.com>
This reverts commit 3c10d8a. Shikra platform support in this tree is being retired in favor of the latest community Shikra patches; drop this downstream commit to avoid conflicting with the upstream series. Signed-off-by: Shiraz Hashim <shiraz.hashim@oss.qualcomm.com>
This reverts commit 5ec1f8b. Shikra platform support in this tree is being retired in favor of the latest community Shikra patches; drop this downstream commit to avoid conflicting with the upstream series. Signed-off-by: Shiraz Hashim <shiraz.hashim@oss.qualcomm.com>
…AS nodes" This reverts commit 49cd256. Shikra platform support in this tree is being retired in favor of the latest community Shikra patches; drop this downstream commit to avoid conflicting with the upstream series. Signed-off-by: Shiraz Hashim <shiraz.hashim@oss.qualcomm.com>
This reverts commit 47ced1e. Shikra platform support in this tree is being retired in favor of the latest community Shikra patches; drop this downstream commit to avoid conflicting with the upstream series. Signed-off-by: Shiraz Hashim <shiraz.hashim@oss.qualcomm.com>
…ects" This reverts commit 0f86ffe. Shikra platform support in this tree is being retired in favor of the latest community Shikra patches; drop this downstream commit to avoid conflicting with the upstream series. Signed-off-by: Shiraz Hashim <shiraz.hashim@oss.qualcomm.com>
This reverts commit 4b6ac1c. Shikra platform support in this tree is being retired in favor of the latest community Shikra patches; drop this downstream commit to avoid conflicting with the upstream series. Signed-off-by: Shiraz Hashim <shiraz.hashim@oss.qualcomm.com>
This reverts commit 61cd5e0. Shikra platform support in this tree is being retired in favor of the latest community Shikra patches; drop this downstream commit to avoid conflicting with the upstream series. Signed-off-by: Shiraz Hashim <shiraz.hashim@oss.qualcomm.com>
This reverts commit 139b551. Shikra platform support in this tree is being retired in favor of the latest community Shikra patches; drop this downstream commit to avoid conflicting with the upstream series. Signed-off-by: Shiraz Hashim <shiraz.hashim@oss.qualcomm.com>
This reverts commit 2d21e0e. Shikra platform support in this tree is being retired in favor of the latest community Shikra patches; drop this downstream commit to avoid conflicting with the upstream series. Signed-off-by: Shiraz Hashim <shiraz.hashim@oss.qualcomm.com>
This reverts commit d669a2d. Shikra platform support in this tree is being retired in favor of the latest community Shikra patches; drop this downstream commit to avoid conflicting with the upstream series. Signed-off-by: Shiraz Hashim <shiraz.hashim@oss.qualcomm.com>
This reverts commit be74700. Shikra platform support in this tree is being retired in favor of the latest community Shikra patches; drop this downstream commit to avoid conflicting with the upstream series. Signed-off-by: Shiraz Hashim <shiraz.hashim@oss.qualcomm.com>
This reverts commit 244df07. Shikra platform support in this tree is being retired in favor of the latest community Shikra patches; drop this downstream commit to avoid conflicting with the upstream series. Signed-off-by: Shiraz Hashim <shiraz.hashim@oss.qualcomm.com>
This reverts commit 670f4ea. Shikra platform support in this tree is being retired in favor of the latest community Shikra patches; drop this downstream commit to avoid conflicting with the upstream series. Signed-off-by: Shiraz Hashim <shiraz.hashim@oss.qualcomm.com>
This reverts commit dd434e7. Shikra platform support in this tree is being retired in favor of the latest community Shikra patches; drop this downstream commit to avoid conflicting with the upstream series. Signed-off-by: Shiraz Hashim <shiraz.hashim@oss.qualcomm.com>
This reverts commit bb2bbc3. Shikra platform support in this tree is being retired in favor of the latest community Shikra patches; drop this downstream commit to avoid conflicting with the upstream series. Signed-off-by: Shiraz Hashim <shiraz.hashim@oss.qualcomm.com>
This reverts commit 237d777. Shikra platform support in this tree is being retired in favor of the latest community Shikra patches; drop this downstream commit to avoid conflicting with the upstream series. Signed-off-by: Shiraz Hashim <shiraz.hashim@oss.qualcomm.com>
This reverts commit dc575ec. Shikra platform support in this tree is being retired in favor of the latest community Shikra patches; drop this downstream commit to avoid conflicting with the upstream series. Signed-off-by: Shiraz Hashim <shiraz.hashim@oss.qualcomm.com>
This reverts commit 609ed3e. Shikra platform support in this tree is being retired in favor of the latest community Shikra patches; drop this downstream commit to avoid conflicting with the upstream series. Signed-off-by: Shiraz Hashim <shiraz.hashim@oss.qualcomm.com>
This reverts commit ec1c84c. Shikra platform support in this tree is being retired in favor of the latest community Shikra patches; drop this downstream commit to avoid conflicting with the upstream series. Signed-off-by: Shiraz Hashim <shiraz.hashim@oss.qualcomm.com>
This reverts commit 251588e. Shikra platform support in this tree is being retired in favor of the latest community Shikra patches; drop this downstream commit to avoid conflicting with the upstream series. Signed-off-by: Shiraz Hashim <shiraz.hashim@oss.qualcomm.com>
This reverts commit 2250083. Shikra platform support in this tree is being retired in favor of the latest community Shikra patches; drop this downstream commit to avoid conflicting with the upstream series. Signed-off-by: Shiraz Hashim <shiraz.hashim@oss.qualcomm.com>
…tible Shikra's EMAC requires two additional clocks for NOC interconnect access (axi-noc, pcie-tile-axi-noc) beyond the standard four, and an OPP table with required-opps to vote VDD_CX to SVS when the NOC clocks are enabled. Add qcom,shikra-ethqos to the compatible enum and use an if/else block to constrain Shikra to exactly six clocks and require operating-points-v2, while leaving existing compatibles unchanged. Add the relevant compatible to the binding document for snps,dwmac as well. Link: https://lore.kernel.org/netdev/20260908-shikra_ethernet-v2-3-bbe3389d0652@oss.qualcomm.com/ Signed-off-by: Mohd Ayaan Anwar <mohd.anwar@oss.qualcomm.com>
… to void The return value is never checked by its sole caller and the speed validation duplicates a check higher up the call stack. Convert to void and remove the dead code. Link: https://lore.kernel.org/netdev/20260908-shikra_ethernet-v2-4-bbe3389d0652@oss.qualcomm.com/ Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Signed-off-by: Mohd Ayaan Anwar <mohd.anwar@oss.qualcomm.com>
When "rgmii-id" is selected the PHY supplies both TX and RX delays, so the MAC must not add its own. The driver currently falls through to the generic DLL initialisation path which programs it to add a delay. Power down the DLL and set DDR bypass mode for RGMII_ID, then program the IO_MACRO via a new ethqos_rgmii_id_macro_init() helper. Also fix ethqos_set_clk_tx_rate() to not double the clock rate in bypass mode at 100M/10M, and remove RGMII_ID from the phase-shift suppression in ethqos_rgmii_macro_init() since RGMII_ID no longer reaches that path. Link: https://lore.kernel.org/netdev/20260908-shikra_ethernet-v2-5-bbe3389d0652@oss.qualcomm.com/ Signed-off-by: Mohd Ayaan Anwar <mohd.anwar@oss.qualcomm.com>
The qcom-ethqos driver is moving towards using "rgmii-id" together with PHY-provided delays. However, existing DTBs use "rgmii" and "rgmii-txid" and must remain supported for backwards compatibility. Warn when either of these legacy PHY modes is used to encourage users to migrate to updated DTBs using "rgmii-id". Link: https://lore.kernel.org/netdev/20260908-shikra_ethernet-v2-6-bbe3389d0652@oss.qualcomm.com/ Signed-off-by: Mohd Ayaan Anwar <mohd.anwar@oss.qualcomm.com>
…owest speed On probe the RGMII link clock is initialised at SPEED_1000, which translates to a 250 MHz source clock even when no PHY link is present, drawing unnecessary power. Initialise at SPEED_10 instead; fix_mac_speed updates the rate once a link is established. Link: https://lore.kernel.org/netdev/20260908-shikra_ethernet-v2-7-bbe3389d0652@oss.qualcomm.com/ Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Signed-off-by: Mohd Ayaan Anwar <mohd.anwar@oss.qualcomm.com>
Some SoCs gate the EMAC's path to the System NOC behind dedicated clocks that must be enabled before the DMA can reach memory. Add ethqos_noc_clk_cfg and the corresponding fields in the driver-data and runtime structs so each compatible can declare its own set with per-clock rates. The clocks are acquired during probe and enabled/disabled alongside the existing link clock in ethqos_clks_config(). No functional change for existing compatibles. This will help us when we add support for Shikra. Link: https://lore.kernel.org/netdev/20260908-shikra_ethernet-v2-8-bbe3389d0652@oss.qualcomm.com/ Signed-off-by: Mohd Ayaan Anwar <mohd.anwar@oss.qualcomm.com>
Shikra integrates two Qualcomm ETHQOS controllers based on the Synopsys GMAC IP, similar to previous platforms. Register qcom,shikra-ethqos backed by a new shikra_data descriptor that enables the three NOC clocks required for DMA memory access (axi-noc, pcie-tile-axi-noc, stmmaceth) all at 120 MHz, and the 36-bit DMA address width. As part of the NOC clock voting logic, the qcom-ethqos glue driver takes a second enable reference on the "stmmaceth" clock, which is already enabled by the stmmac core. All three clocks in shikra_noc_clks[] must run at 120 MHz for NOC access, and managing "stmmaceth" through the same clk_bulk path keeps the rate-setting and enable/disable together. Link: https://lore.kernel.org/netdev/20260908-shikra_ethernet-v2-9-bbe3389d0652@oss.qualcomm.com/ Signed-off-by: Mohd Ayaan Anwar <mohd.anwar@oss.qualcomm.com>
The GPIO mappings on the IQS variant differ from the CQ variants. GPIO138 is connected to the RGMII1_RX_CTL pin rather than the NFC ESE Secure IO pin; the latter is connected to GPIO49. This incorrect reservation causes the probe of the second Ethernet port to fail: shikra-tlmm 500000.pinctrl: error -EINVAL: pin-138 (5d20000.ethernet) shikra-tlmm 500000.pinctrl: error -EINVAL: could not request pin 138 (GPIO_138) from group gpio138 on device 500000.pinctrl qcom-ethqos 5d20000.ethernet: Error applying setting, reverse things back Replace gpio138 with gpio49 in the reserved list. Link: https://lore.kernel.org/linux-arm-msm/20260908-shikra_ethernet_dts-v1-1-69c0c5c7c124@oss.qualcomm.com/ Fixes: 779aead2dace ("arm64: dts: qcom: shikra: Add gpio-reserved-ranges to tlmm") Signed-off-by: Mohd Ayaan Anwar <mohd.anwar@oss.qualcomm.com>
Add the two Gigabit Ethernet controllers present on Shikra (ethernet0 at 0x5d00000, ethernet1 at 0x5d20000). Both nodes are left disabled; board files supply the PHY details. Link: https://lore.kernel.org/linux-arm-msm/20260908-shikra_ethernet_dts-v1-2-69c0c5c7c124@oss.qualcomm.com/ Signed-off-by: Mohd Ayaan Anwar <mohd.anwar@oss.qualcomm.com>
… port Enable ethernet0 for the Shikra CQM EVK board with its DP83867 RGMII PHY. The PHY is powered on using a GPIO-controlled 2.5V regulator. Link: https://lore.kernel.org/linux-arm-msm/20260908-shikra_ethernet_dts-v1-3-69c0c5c7c124@oss.qualcomm.com/ Signed-off-by: Mohd Ayaan Anwar <mohd.anwar@oss.qualcomm.com>
… port Enable ethernet0 for the Shikra CQS EVK board with its DP83867 RGMII PHY. The PHY is powered on using a GPIO-controlled 2.5V regulator. Link: https://lore.kernel.org/linux-arm-msm/20260908-shikra_ethernet_dts-v1-4-69c0c5c7c124@oss.qualcomm.com/ Signed-off-by: Mohd Ayaan Anwar <mohd.anwar@oss.qualcomm.com>
Enable ethernet0 and ethernet1 on the IQS EVK with their respective TI DP83867 RGMII PHYs. Both PHYs are powered by GPIO-controlled 2.5V regulators. Link: https://lore.kernel.org/linux-arm-msm/20260908-shikra_ethernet_dts-v1-5-69c0c5c7c124@oss.qualcomm.com Signed-off-by: Mohd Ayaan Anwar <mohd.anwar@oss.qualcomm.com>
Shikra reuses the same QCE integration as Agatti and should follow the
corresponding binding requirements too.
Move the Shikra compatible to the appropriate binding hierarchy
(matching qcom,qcm2290-qce) to reflect the underlying hardware
description.
Fixes: 45834ff95a6f ("dt-bindings: crypto: qcom-qce: Document the Shikra crypto engine")
Signed-off-by: Kuldeep Singh <kuldeep.singh@oss.qualcomm.com>
Link: https://lore.kernel.org/linux-arm-msm/CAMRc=MckdJyEvOq73Fi+Q-sr1aoL6QzvHsNq-3k62RSi9sy08A@mail.gmail.com/
Signed-off-by: Roopak Houji <rhouji@qti.qualcomm.com>
Shikra is derived from Agatti and uses the same QCE integration. Update the QCE node to match the underlying hardware implementation by adjusting the fallback compatible and related properties, including clocks and clock-names. Signed-off-by: Kuldeep Singh <kuldeep.singh@oss.qualcomm.com> Link: https://lore.kernel.org/linux-arm-msm/20260907-b4-shikra_crypto_changse-v6-2-0676f61894b3@oss.qualcomm.com/ Signed-off-by: Roopak Houji <rhouji@qti.qualcomm.com>
…for RPM targets Keep "qcom,rpm-stats" as a fallback for RPM targets, so that SoC level stats are still shown even without subsystem level stats support. A plain enum can't express that, since it caps compatible at one item. Add a oneOf branch with items for this pattern. Link: https://lore.kernel.org/all/20260907-shikra_stats-v4-1-3825351f9740@oss.qualcomm.com Signed-off-by: Sneh Mankad <sneh.mankad@oss.qualcomm.com>
clk_smd_rpm_handoff() votes both active and sleep RPM resource states for every clock, keeping them non-zero until a consumer takes over. If there is no consumer, those clocks will remain active in the idle scenario as well, and the sleep vote is never cleared, blocking XO shutdown. Introduce the skip_clks_handoff flag to handle this on QCM2290 clocks, keeping other targets unaffected. Link: https://lore.kernel.org/r/20260910-clk-smd-rpm-skip-proxy-v1-1-1cb5694a99d9@oss.qualcomm.com Fixes: 00f64b5 ("clk: qcom: Add support for SMD-RPM Clocks") Signed-off-by: Imran Shaik <imran.shaik@oss.qualcomm.com>
…ins property Remove #power-domain-cells property and add power-domains property for MPM device. Link: https://lore.kernel.org/lkml/20260713-b4-shikra_lpm_addition-v1-1-3d858df2cbbf@oss.qualcomm.com Signed-off-by: Sneh Mankad <sneh.mankad@oss.qualcomm.com>
…domain
MPM irqchip needs to notify RPM (Resource Power Manager) processor to read
the latest wake up capable interrupts when the CPU cluster is entering the
deepest idle state. This is done by sending IPC interrupt to RPM and is
implemented as .power_off() callback by registering MPM as parent power
domain to CPU cluster.
Such implementation introduces a hard probe dependency between MPM irqchip
and CPU cluster power domains. That is MPM irqchip needs to finish probe
before PSCI power domains are probed. MPM irqchip can be build as module
and can get later inserted where as PSCI power domains is not a module.
For in-built driver cases too PSCI domain gets probed first and later MPM
irqchip leading to failure of CPUidle states.
Detailed flow of the non-working scenario:
psci-cpuidle-domain.c probe
--> dt_idle_pd_init_topology()
--> of_genpd_add_subdomain()
--> genpd_get_from_provider()
--> fails to find parent MPM genPD provider
--> returns -EPROBE_DEFER.
irq-qcom-mpm.c probe
--> of_genpd_add_provider_simple()
--> genpd_add_provider()
--> MPM added as a genPD provider.
Now when psci_cpuidle_probe() is called to probe the CPU idle states, it
tries to map the states to the mentioned power-domains.
But since power domains probe has been deferred, psci_cpuidle_probe() too
will return -EPROBE_DEFER.
commit af5376a ("cpuidle: psci: Transition to the faux device
interface") transitioned cpuidle-psci to a faux device interface.
faux_device_create() calls faux_device_create_with_groups(), which ignores
the probe return value, and destroys the device if dev->driver is not set.
This will lead to psci_cpuidle_probe() not being called again, resulting in
all idle-state devices failing to init in SoCs setting MPM as a parent
power domain to CPU cluster.
cpuidle-psci.c init
--> faux_device_create()
...
--> psci_cpuidle_probe()
--> psci_idle_init_cpu()
...
--> psci_dt_cpu_init_topology()
...
-> dev_pm_domain_attach_by_name()
--> __genpd_dev_pm_attach()
--> genpd_get_from_provider()
--> fails to find CPU genPD provider
--> returns -EPROBE_DEFER
--> return value ignored and device
destroyed
Move the RPM notification handling to the GENPD_NOTIFY_PRE_OFF callback and
register MPM under the CPU cluster power domain. Use runtime PM to report
the default RPM_SUSPENDED state to genPD so that the CPU cluster power
domain can enter low power mode.
If MPM has not registered with CPU cluster power domain, utilize the CPU PM
notifications to manage RPM communication when the last CPU goes to power
collapse.
Fixes: a6199bb ("irqchip: Add Qualcomm MPM controller driver")
Link: https://lore.kernel.org/lkml/20260713-b4-shikra_lpm_addition-v1-2-3d858df2cbbf@oss.qualcomm.com
Signed-off-by: Sneh Mankad <sneh.mankad@oss.qualcomm.com>
…and pin regs The vMPM layout starts with two timer registers followed by pin register banks (ENABLE/FALLING/RISING/POLARITY/STATUS), each with reg_stride number of entries. Use qcom_mpm_offset() as the common addressing helper for both timer and pin register accesses based on that layout. vMPM has MPM_REG_* values represented as contiguous register IDs, hence replace the macros with enum qcom_mpm_reg and modify the accessor helpers accordingly. Link: https://lore.kernel.org/lkml/20260713-b4-shikra_lpm_addition-v1-3-3d858df2cbbf@oss.qualcomm.com Signed-off-by: Sneh Mankad <sneh.mankad@oss.qualcomm.com>
… goes to LPM The next wakeup timer value needs to be set in MPM timer as the arch timer interrupt can not wakeup the SoC if after the deepest CPUidle states the SoC also enters deepest low power state. To wakeup the SoC in such scenarios the earliest wakeup time is set in MPM timer and the Resource Power Manager (RPM processor) takes care of setting the timer in HW. Add MPM timer programming when CPU cluster enters power collapse. Link: https://lore.kernel.org/lkml/20260713-b4-shikra_lpm_addition-v1-4-3d858df2cbbf@oss.qualcomm.com Signed-off-by: Sneh Mankad <sneh.mankad@oss.qualcomm.com>
Add idle states for the CPUs as well as the whole cluster. This enables deeper-than-WFI cpuidle. Add MPM under cluster_pd power domain. Link: https://lore.kernel.org/lkml/20260713-b4-shikra_lpm_addition-v1-7-3d858df2cbbf@oss.qualcomm.com/ Signed-off-by: Sneh Mankad <sneh.mankad@oss.qualcomm.com>
…roller Add the device-tree binding documentation for the Cypress cypd6129 and cypd6229 dual Type-C PD controllers. These are used on Shikra CQM/CQS/IQS platforms to handle usb-role-switch for the USB Type-C ports over an I2C interface, similarly to the existing cypd4226 binding. cypd6229 is a variant of cypd6129 and is described with a "cypress,cypd6129" fallback compatible string. Link: https://lore.kernel.org/all/20260821-shikra-usb-dt-v7-apply-v2-1-030647f06285@oss.qualcomm.com/ Signed-off-by: Akash Kumar <akash.kumar@oss.qualcomm.com> Signed-off-by: Akash Kumar <akakum@qti.qualcomm.com>
Add cypd6129 and cypd6229 compatible strings to the of_device_id match table so the driver binds to boards describing these Cypress PD controllers in their device tree. No other driver changes are needed since the chip is accessed through the same generic UCSI/HPI I2C register protocol as the existing cypd4226 support. Link: https://lore.kernel.org/all/20260820145036.2035641-3-akash.kumar@oss.qualcomm.com/ Signed-off-by: Akash Kumar <akash.kumar@oss.qualcomm.com> Signed-off-by: Akash Kumar <akakum@qti.qualcomm.com>
Add init sequence and phy configuration for the Super Speed port on Shikra SoC. Also since Shikra uses 3 resets, add support for the third reset and configure Shikra platform data to use 3 resets. Link: https://lore.kernel.org/all/20260504170659.282532-5-krishna.kurapati@oss.qualcomm.com/ Signed-off-by: Krishna Kurapati <krishna.kurapati@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Akash Kumar <akakum@qti.qualcomm.com>
…ype-C ports On Shikra CQS/CQM platforms, usb-role-switch is handled by PM4125 on the primary Type-C port and Cypress PD controller CYPD6129 on the second Type-C port. On Shikra IQS platform, usb-role-switch is handled by Cypress PD controller CYPD6129 on both Type-C ports. Add the CYPD6129 typec node under i2c3, wire its connector endpoints to the corresponding DWC3 controller ports via remote-endpoint phandles, and switch the associated USB controllers to OTG mode so role switching can take effect. Link: https://lore.kernel.org/all/20260820145036.2035641-4-akash.kumar@oss.qualcomm.com/ Signed-off-by: Akash Kumar <akash.kumar@oss.qualcomm.com> Signed-off-by: Akash Kumar <akakum@qti.qualcomm.com>
The interconnect drivers for Qualcomm SoC Network-on-Chip are covering a
basic or fundamental SoC feature: bandwidth management between internal
SoC blocks. SoC can boot without these, but power management or
performance will be affected. These drivers do not represent any sort
of buses visible to the board designers/configurators, thus they should
be always enabled, regardless how SoC is used in the final board.
Kernel configuration should not ask users choice of drivers when that
choice is obvious and known to the developers that answer should be
'yes' or 'module'.
Switch all almost Qualcomm interconnect drivers to a default 'yes' for
ARCH_QCOM. This has impact:
1. arm64 defconfig:
a. Enable as built-in INTERCONNECT_QCOM_HAWI, INTERCONNECT_QCOM_NORD,
INTERCONNECT_QCOM_SHIKRA, INTERCONNECT_QCOM_SDM660,
INTERCONNECT_QCOM_SDM670, INTERCONNECT_QCOM_SM7150 and
INTERCONNECT_QCOM_SAR2130P, which were not selected before but
should be, because these platforms need them anyway for proper
functioning.
b. Switch to built-in from a module INTERCONNECT_QCOM_QCS404 and
INTERCONNECT_QCOM_MSM8916, which as modules would not make the
platform bootable in most cases, and INTERCONNECT_QCOM_OSM_L3,
which when module might slow down boot considerably by having
caches running at slow speed.
2. arm qcom_defconfig: Switch to built-in from a module
INTERCONNECT_QCOM_RPMH, INTERCONNECT_QCOM_SMD_RPM,
INTERCONNECT_QCOM_BCM_VOTER, INTERCONNECT_QCOM_MSM8974,
INTERCONNECT_QCOM_SDX55, which as modules would not make the
platform bootable in most cases.
3. arm multi_v7 defconfig: Enable drivers necessary to boot
ARM 32-bit platforms, which are already enabled on qcom_defconfig:
a. Enable as built-in INTERCONNECT_QCOM_MSM8974.
b. Enable as modules (other dependencies prevent from built-in)
INTERCONNECT_QCOM_RPMH, INTERCONNECT_QCOM_BCM_VOTER and
INTERCONNECT_QCOM_SDX55.
4. COMPILE_TEST builds: Enable by default all drivers for arm or arm64
builds, whenever ARCH_QCOM is selected. This has impact on build
time and feels logical, because if one selects ARCH_QCOM then
probably by default wants to build test it entirely. Kernels with
COMPILE_TEST are not supposed to be used for booting.
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Reviewed-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260914-interconnect-qcom-clean-arm64-v4-1-5b2c0e6a929a@oss.qualcomm.com
…d and Shikra
Hawi, Maili, Nord and Shikra were added in parallel or after
commit 5b696f065843 ("interconnect: qcom: Restrict drivers per
ARM/ARM64"), thus they missed the update restricting them per
architecture (with the same rationale).
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Reviewed-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260914-interconnect-qcom-clean-arm64-v4-2-5b2c0e6a929a@oss.qualcomm.com
The GENI_TO_CORE ("qup-core") ICC vote selects the QUP Core 2X clock
rate. The CORE_2X_*_MHZ constants are expressed in Bps, but their
values are several orders of magnitude too small. For example, the
50 MHz threshold is represented by 2500 rather than 25000000 Bps.
As a result, clients using these constants can severely under-vote the
QUP Core clock.
Correct the constants to their intended Bps thresholds so that the ICC
provider selects the corresponding QUP Core 2X clock rate.
Link: https://lore.kernel.org/all/20260909-correct-icc-bandwidth-vote-constants-v1-1-fbebf6b3c341@oss.qualcomm.com/
Fixes: 58ffbba ("soc: qcom: geni: Support for ICC voting")
Signed-off-by: Viken Dadhaniya <viken.dadhaniya@oss.qualcomm.com>
…fter deep idle
At baud rates up to 115200, the serial console uses only a 1 kBps keepalive
vote for the GENI_TO_CORE ("qup-core") ICC path. This vote keeps the path
active but does not request a QUP Core 2X clock rate.
When the CPU enters a deeper idle state, the missing Core clock vote can
leave the console RX path unresponsive.
Use the 19.2 MHz Core 2X vote at low baud rates, while retaining the 50 MHz
vote at higher baud rates, so that console RX remains functional after deep
idle transitions.
Link: https://lore.kernel.org/all/20260909-correct-icc-bandwidth-vote-constants-v1-2-fbebf6b3c341@oss.qualcomm.com/
Fixes: 7cf563b ("tty: serial: qcom_geni_serial: Add interconnect support")
Signed-off-by: Viken Dadhaniya <viken.dadhaniya@oss.qualcomm.com>
Shiraz Hashim (shashim-quic)
force-pushed
the
shikra-port
branch
from
October 10, 2026 15:02
6688023 to
018ede6
Compare
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.
Summary
This branch replaces the Shikra SoC support that had accumulated in this tree as ad-hoc, downstream-only commits with a clean re-port from the actual upstream submission history: commits that have already landed in mainline (linux.git), plus the current, in-flight patch set on the kernel-topics (ktopics) Shikra topic branches (tech/all/shikra, early/hwe/shikra/{drivers,dt}).
Approach
Stats
What's included
Shikra CQ2390M/IQ2390S SoM support across: GCC/AudioCoreCC/DISPCC/GPUCC clocks, pinctrl, LLCC, SMMU, remoteproc (CDSP/LPAICP/MPSS PAS), interconnect/EPSS L3, cpufreq, thermal/TSENS, USB (+Type-C role switch, Cypress cypd6129/6229 UCSI), PCIe, SD card, WiFi/BT, BAM-DMUX, Ethernet (stmmac/ethqos, DP83867 PHY), Adreno A704 GPU + cooling, Iris/Venus video, CAMSS/camera overlays, ILI7807S display panels, and audio (QAIF CPU DAI, SoundWire, LPASS macros, sc8280xp machine driver variants for the three EVK boards).
Explicitly not included
Notes for reviewers