For sensors glink lpaicp crash#1408
Open
Vishnu Santhosh (quic-vishsant) wants to merge 183 commits into
Open
Conversation
Document the IDs used by Shikra SoC IoT variants: - CQ2390M: Shikra Retail with modem - CQ2390S: Shikra Retail without modem - IQ2390S: Shikra Industrial without modem Signed-off-by: Komal Bajaj <komal.bajaj@oss.qualcomm.com>
Add SoC ID for Shikra IoT variants: CQ2390M, CQ2390S and IQ2390S. Signed-off-by: Komal Bajaj <komal.bajaj@oss.qualcomm.com>
Qualcomm Shikra SoC implements arm,mmu-500. Document its compatible. Signed-off-by: Komal Bajaj <komal.bajaj@oss.qualcomm.com>
Document the SCM compatible on the Shikra SoC. Signed-off-by: Komal Bajaj <komal.bajaj@oss.qualcomm.com>
Document the device tree binding for the Shikra EVK platform, which is built around a modular System-on-Module (SoM) mounted on a common carrier board. The SoM integrates the Shikra SoC, PMICs, and essential GPIOs, while the EVK carrier board provides additional peripherals such as UART and USB interfaces. Shikra EVK supports three SoM variants: retail with modem, retail without modem, and an industrial non-modem variant. Signed-off-by: Komal Bajaj <komal.bajaj@oss.qualcomm.com>
Add compatible for Shikra SoC IMEM. Signed-off-by: Komal Bajaj <komal.bajaj@oss.qualcomm.com>
Document the Top Level Mode Multiplexer on the Shikra platform. Signed-off-by: Komal Bajaj <komal.bajaj@oss.qualcomm.com>
Add pinctrl driver for TLMM block found in the Shikra SoC. Signed-off-by: Komal Bajaj <komal.bajaj@oss.qualcomm.com>
Document the RPM Power Domains on the Shikra Platform. Signed-off-by: Rakesh Kota <rakesh.kota@oss.qualcomm.com>
Shikra has the same RPM power domains as QCM2290. Add shikra support by reusing QCM2290 power domains. Signed-off-by: Rakesh Kota <rakesh.kota@oss.qualcomm.com>
Document the pm8150 compatible string and available regulators in the QCOM SMD RPM regulator documentation. Signed-off-by: Rakesh Kota <rakesh.kota@oss.qualcomm.com>
The PM8150 is found on boards with shikra SoCs and It provides 10 SMPS and 18 LDO regulators. Signed-off-by: Rakesh Kota <rakesh.kota@oss.qualcomm.com>
Add the rpmpd compatable string for shikra. Signed-off-by: Rakesh Kota <rakesh.kota@oss.qualcomm.com>
Qualcomm Shikra SoC implements qcom,smmu-500 for adreno-smmu. Document its corresponding compatible. Signed-off-by: Bibek Kumar Patro <bibek.patro@oss.qualcomm.com>
Add "qcom,shikra-apcs-hmss-global" compatibility string in qcom_apcs_ipc mailbox driver to match apcs_glb device node. Signed-off-by: Vishnu Santhosh <vishnu.santhosh@oss.qualcomm.com>
Document compatible string for the QFPROM on Shikra platform. Signed-off-by: Komal Bajaj <komal.bajaj@oss.qualcomm.com>
Add the qcom,shikra-rpm-proc compatible string to the Qualcomm RPM remote processor device tree binding. Signed-off-by: Sneh Mankad <sneh.mankad@oss.qualcomm.com> Signed-off-by: Komal Bajaj <komal.bajaj@oss.qualcomm.com>
Add compatible for the Qualcomm Shikra APCS block to the Qualcomm APCS binding. Signed-off-by: Sneh Mankad <sneh.mankad@oss.qualcomm.com> Signed-off-by: Komal Bajaj <komal.bajaj@oss.qualcomm.com>
Document the compatible for Shikra. Signed-off-by: Sneh Mankad <sneh.mankad@oss.qualcomm.com> Signed-off-by: Komal Bajaj <komal.bajaj@oss.qualcomm.com>
Document the qcom,rpmcc-shikra compatible. Signed-off-by: Imran Shaik <imran.shaik@oss.qualcomm.com>
Add support for qcom global clock controller bindings for Shikra platform. Signed-off-by: Imran Shaik <imran.shaik@oss.qualcomm.com>
Add support for RPM-managed clocks on the Shikra platform. Signed-off-by: Imran Shaik <imran.shaik@oss.qualcomm.com>
Add support for Global clock controller for Shikra Qualcomm SoC. Signed-off-by: Imran Shaik <imran.shaik@oss.qualcomm.com>
Enable the GCC driver on the Qualcomm Shikra EVK boards. Signed-off-by: Imran Shaik <imran.shaik@oss.qualcomm.com>
Add devicetree binding for watchdog present on Qualcomm's Shikra SoC. Signed-off-by: Komal Bajaj <komal.bajaj@oss.qualcomm.com>
Document the GPI DMA engine on Shikra platform. Signed-off-by: Xueyao An <xueyao.an@oss.qualcomm.com> Signed-off-by: Komal Bajaj <komal.bajaj@oss.qualcomm.com>
Update dt-bindings to add Shikra to QMP Phy list. Signed-off-by: Krishna Kurapati <krishna.kurapati@oss.qualcomm.com>
Update dt-bindings to add Shikra to QUSB2 Phy list. Signed-off-by: Krishna Kurapati <krishna.kurapati@oss.qualcomm.com>
Introduce the compatible definition for Shikra QCOM SNPS DWC3. Signed-off-by: Krishna Kurapati <krishna.kurapati@oss.qualcomm.com>
Add init sequence and phy configuration for Shikra. Signed-off-by: Krishna Kurapati <krishna.kurapati@oss.qualcomm.com>
Document the qcom,wsa885x-init-table and qcom,battery-config property names while keeping the existing init table and qcom,battery_config properties for compatibility. Mark qcom,battery_config deprecated and make the init table optional so boards can rely on codec register defaults. Signed-off-by: Pratyush Meduri <mpratyus@qti.qualcomm.com>
Accept the qcom,wsa885x-init-table and qcom,battery-config property names used by downstream Shikra audio device trees while keeping compatibility with the existing unprefixed init table and qcom,battery_config properties. Allow the init table to be absent and rely on register defaults, matching the downstream codec-driver behavior. Validate the battery configuration value when provided. Signed-off-by: Pratyush Meduri <mpratyus@qti.qualcomm.com>
Use each GPR domain advertised by the qcom APR/GPR layer when building APM/PRM packets and add explicit dest_domain parameters to all AudioReach alloc helpers. Legacy helpers fall back to ADSP while graphs, media-format, and shared-memory packets reuse gdev->domain_id for modem targets. Signed-off-by: Pratyush Meduri <mpratyus@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>
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 Shikra-specific audio support to the sc8280xp machine driver. Register Shikra board DAPM widgets and pin controls for Headphone, Headset Mic, Int Mic and Speaker endpoints. Add per-board control data to struct snd_soc_common so board-specific controls can be registered with the card during probe. Add MI2S codec clock configuration through board flags instead of relying on the number of codecs in the DAI link. Shikra uses codec_dai_fmt and codec_sysclk_set to request codec DAI format and sysclk programming, while mi2s_bclk_enable controls CPU MCLK programming for boards that need it. Handle TDM setup from hw_params, where slot configuration and BCLK can be computed from stream parameters, rather than programming the TDM format from snd_init. Also add qcom,adsp-bypass-mode handling so boards using CPU-based audio can skip DSP-oriented hw_params programming. Signed-off-by: Ajay Kumar Nandam <ajay.nandam@oss.qualcomm.com> Signed-off-by: Mohammad Rafi Shaik <mohammad.rafi.shaik@oss.qualcomm.com> Signed-off-by: Pratyush Meduri <mpratyus@qti.qualcomm.com>
…ARCH_QCOM Interconnect drivers provide fundamental NoC bandwidth management required for correct system behavior. Although systems can boot without them, power and performance are impacted. These drivers need to enabled irresepective of the board variant, design or configuration. Enable the Shikra interconnect driver by default on ARCH_QCOM by setting "default ARCH_QCOM". Signed-off-by: Raviteja Laggyshetty <raviteja.laggyshetty@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260526-shikra_icc_kconfig-v1-1-c589db2d023c@oss.qualcomm.com
…tible Shikra's EMAC requires three additional clocks beyond the standard four (axi, axi-noc, pcie-tile-axi-noc) for NOC interconnect voting. Add the compatible string and extend clock-names with a oneOf variant for this seven-clock configuration. The AXI clock appears twice (as "stmmaceth" and "axi") because the stmmac core and the driver's NOC bulk-clock array each consume one reference; CCF refcounting makes this safe. Link: https://lore.kernel.org/netdev/20260612-shikra_ethernet-v1-0-f0f4a1d19929@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/20260612-shikra_ethernet-v1-0-f0f4a1d19929@oss.qualcomm.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/20260612-shikra_ethernet-v1-0-f0f4a1d19929@oss.qualcomm.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/20260612-shikra_ethernet-v1-0-f0f4a1d19929@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 and the 36-bit DMA address width. Link: https://lore.kernel.org/netdev/20260612-shikra_ethernet-v1-0-f0f4a1d19929@oss.qualcomm.com/ Signed-off-by: Mohd Ayaan Anwar <mohd.anwar@oss.qualcomm.com>
…y DSF On Shikra, the DDR System Firmware (DSF) configures ECC interrupt routing before the kernel driver probes — it enables Tag/Data RAM interrupts and programs error thresholds in the LLCC interrupt-enable registers. Set irq_configured in shikra_cfg so that qcom_llcc_edac_probe() skips calling qcom_llcc_core_setup(), which would otherwise overwrite the firmware-managed register state with redundant writes. Signed-off-by: Faiyaz Mohammed <faiyazm@qti.qualcomm.com>
Add support for additional GCC EMAC RGMII clock frequencies (2.5MHz and 25MHz) required for the EMAC use-cases on Qualcomm Shikra SoC. While at it, correct the GPLL8/9/10 test_ctl_hi_val configuration. Signed-off-by: Imran Shaik <imran.shaik@oss.qualcomm.com>
Use the result payload returned for APM_CMD_SHARED_MEM_UNMAP_REGIONS instead of forcing a successful completion. Clear the memory map handle only when the DSP reports success, and keep error reporting tied to the returned status so callers can detect failed unmap operations. Signed-off-by: Pratyush Meduri <mpratyus@qti.qualcomm.com>
Add support for q6apm DAI instances that allocate PCM buffers from a reserved memory carveout instead of an IOMMU-mapped DMA allocation. Parse the optional memory-region property, size the ALSA buffer constraints to the carveout, and map the fixed physical region to the DSP graph when the stream is prepared. Support TrustZone VMID reassignment for both normal DMA buffers and reserved memory. Allow platforms to specify the source VMID tracked by SCM, share the buffer with the configured destination VMIDs, and restore ownership during stream teardown. Signed-off-by: Pratyush Meduri <mpratyus@qti.qualcomm.com>
Set auto_boot to true for the Shikra CDSP Peripheral Authentication Service so the CDSP is brought up automatically during boot rather than requiring an explicit start from userspace. Signed-off-by: Anurag Pateriya <apateriy@qti.qualcomm.com>
This reverts commit 45fa97c. Signed-Off-By: Nihal Kumar Gupta <nihal.gupta@oss.qualcomm.com>
The GLINK native driver has no formal channel state machine, making it prone to race conditions during concurrent open/close sequences. Consider a remote subsystem operating in island mode -- a low-power state where the subsystem suspends processing of its IPC message queue while continuing other execution. Incoming GLINK commands accumulate and are dispatched only when the subsystem exits island mode. The host processes GLINK_CMD_OPEN_ACK in interrupt context via qcom_glink_native_rx(), while GLINK_CMD_OPEN, GLINK_CMD_CLOSE, and GLINK_CMD_CLOSE_ACK are deferred to a worker thread. This asymmetry creates a window where two close acknowledgments for the same channel, but carrying different local channel IDs (lcids), are processed together. The first close acknowledgment clears the lcid to 0. Any subsequent close request then goes out with lcid 0, which the remote silently ignores. The host considers the channel closed while the remote keeps it open. On the next open attempt the remote sees a duplicate open and crashes. Introduce an explicit channel state machine to eliminate these races: - enum glink_channel_state covers local state: CLOSED, OPENING, OPENED, CLOSING. - remote_opened flag tracks the remote endpoint's state. - state_lock spinlock protects both state variables. - Helper functions validate and perform state transitions atomically. IDR entries (lcids, rcids) and the reference count are deferred until both local and remote sides are fully closed, preventing stale IDR lookups and use-after-free regardless of which close ordering occurs. Signed-off-by: Vishnu Santhosh <vishnu.santhosh@oss.qualcomm.com>
Debugging channel state issues during open/close sequences currently requires adding temporary instrumentation to the driver. Add two tracepoints that provide persistent, zero-overhead-when-disabled visibility into the state machine: - qcom_glink_channel_state: fires on every local state transition, recording old and new states and an error flag that indicates an invalid transition attempt. - qcom_glink_channel_info: fires on remote endpoint state changes, recording whether the remote side opened or closed. Together these allow a complete channel lifecycle to be reconstructed from a trace log without any driver modification. Signed-off-by: Vishnu Santhosh <vishnu.santhosh@oss.qualcomm.com>
Wire the qcom_glink_channel_state and qcom_glink_channel_info tracepoints into the channel state machine helpers. Signed-off-by: Vishnu Santhosh <vishnu.santhosh@oss.qualcomm.com>
Komal Bajaj (Komal-Bajaj)
force-pushed
the
early/hwe/shikra/drivers
branch
2 times, most recently
from
f84f32e to
f5654fe
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.
GLINK channels can crash a remote subsystem when open close sequences races. This occurred during island mode. Island mode is a low-power state where the remote suspends IPC queue processing while continuing other execution -- queued GLINK commands are dispatched in a burst when the subsystem exits island mode.
The root cause is the absence of a formal channel state machine. The host processes GLINK_CMD_OPEN_ACK in interrupt context while CLOSE and CLOSE_ACK are deferred to a worker thread. When two close acknowledgments for the same channel arrive back-to-back, the first clears lcid to 0; the second close request goes out with lcid 0, which the remote silently ignores. The host believes the channel is closed; the remote keeps it open. On the next open attempt the remote sees a duplicate open and asserts.