| Message ID | 20250130043508.1885026-2-quic_rajkbhag@quicinc.com |
|---|---|
| State | New |
| Headers | show |
| Series | wifi: ath12k: add Ath12k AHB driver support for IPQ5332 | expand |
On 1/30/2025 2:10 PM, Krzysztof Kozlowski wrote: > On 30/01/2025 09:28, Krzysztof Kozlowski wrote: >> On Thu, Jan 30, 2025 at 10:04:56AM +0530, Raj Kumar Bhagat wrote: >>> Add device-tree bindings for the ATH12K module found in the IPQ5332 >>> device. >>> >>> Signed-off-by: Raj Kumar Bhagat <quic_rajkbhag@quicinc.com> >>> --- >>> .../net/wireless/qcom,ath12k-ahb.yaml | 319 ++++++++++++++++++ >>> 1 file changed, 319 insertions(+) >>> create mode 100644 Documentation/devicetree/bindings/net/wireless/qcom,ath12k-ahb.yaml >>> >>> diff --git a/Documentation/devicetree/bindings/net/wireless/qcom,ath12k-ahb.yaml b/Documentation/devicetree/bindings/net/wireless/qcom,ath12k-ahb.yaml >>> new file mode 100644 >>> index 000000000000..bd953a028dc3 >>> --- /dev/null >>> +++ b/Documentation/devicetree/bindings/net/wireless/qcom,ath12k-ahb.yaml >> >> Filename should match compatible. This binding does not look like >> supporting more devices, so there is no much benefit calling it by generic name. > > > I saw now your other patchset, so you have here two devices, but I still > do not understand why this cannot follow standard naming practice like > most bindings supporting one or more devices. Like every review we give. > Sure, we can rename the filename to match the compatibles - "qcom,ipq5x-wifi.yaml".
On 1/30/2025 1:58 PM, Krzysztof Kozlowski wrote: >> + memory-region: >> + description: >> + phandle to a node describing reserved memory (System RAM memory) >> + used by ath12k firmware (see bindings/reserved-memory/reserved-memory.txt) > Do not say what DT syntax is, so "phandle to a node" is redundant, > reserved-memory.txt is redundant. The only useful part here is "used by > ath12k firmware", so based on this none of below are used by the driver > and driver just passes them to the firmware? > Sure, will rephrase the description. These reserved memory-regions are utilized by the ath12k firmware. The ath12k driver stores these memory addresses solely for the purpose of collecting crash dumps (RAM dumps) when the firmware encounters a crash. >> + items: >> + - description: Q6 memory region >> + - description: m3 dump memory region >> + - description: Q6 caldata memory region >> + - description: Multi Link Operation (MLO) Global memory region >> + >> + memory-region-names: >> + description: >> + Name of the reserved memory region used by ath12k firmware > Drop description. > Sure. >> + items: >> + - const: q6-region >> + - const: m3-dump >> + - const: q6-caldb >> + - const: mlo-global-mem >> + >> + qcom,ath12k-calibration-variant: >> + $ref: /schemas/types.yaml#/definitions/string > Why this is named after ath12k? Why this is just not > "qcom,calibration-variant"? None of the other properties have ath12k in > their names, so why this one in the WSI schema was named like that? > This property is added after the below comment. https://lore.kernel.org/all/qzjgpwemwaknwbs3dwils6kaa5c3inabfvkaryvc32kblzfhy3@6yduooj4dk63/ This `ath12k` in the name of this property is inherited from the 'qcom,ath10k.yaml' and 'qcom,ath11k.yaml'. Same was followed for WSI schema as well. >> + description: >> + String to uniquely identify variant of the calibration data for designs >> + with colliding bus and device ids > I don't think this property is here possible. How could you have on the > same SoC different devices? The WiFi controller in the SoC includes an internal or external Front-End Module (FEM). These FEMs can vary and require different calibration data. This property uniquely identify the variant of calibration data required by a FEM.
On 1/31/2025 12:37 AM, Jeff Johnson wrote: > On 1/29/2025 8:34 PM, Raj Kumar Bhagat wrote: >> Add device-tree bindings for the ATH12K module found in the IPQ5332 >> device. >> >> Signed-off-by: Raj Kumar Bhagat <quic_rajkbhag@quicinc.com> >> --- >> .../net/wireless/qcom,ath12k-ahb.yaml | 319 ++++++++++++++++++ >> 1 file changed, 319 insertions(+) >> create mode 100644 Documentation/devicetree/bindings/net/wireless/qcom,ath12k-ahb.yaml >> >> diff --git a/Documentation/devicetree/bindings/net/wireless/qcom,ath12k-ahb.yaml b/Documentation/devicetree/bindings/net/wireless/qcom,ath12k-ahb.yaml >> new file mode 100644 >> index 000000000000..bd953a028dc3 >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/net/wireless/qcom,ath12k-ahb.yaml >> @@ -0,0 +1,319 @@ >> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) >> +# Copyright (c) 2024-2025 Qualcomm Innovation Center, Inc. All rights reserved. >> +%YAML 1.2 >> +--- >> +$id: http://devicetree.org/schemas/net/wireless/qcom,ath12k-ahb.yaml# >> +$schema: http://devicetree.org/meta-schemas/core.yaml# >> + >> +title: Qualcomm Technologies ath12k wireless devices (AHB) >> + >> +maintainers: >> + - Kalle Valo <kvalo@kernel.org> > > sadly, you should remove Kalle since he resigned as a maintainer this week > Will update.
On 03/02/2025 09:43, Raj Kumar Bhagat wrote: > On 1/30/2025 2:10 PM, Krzysztof Kozlowski wrote: >> On 30/01/2025 09:28, Krzysztof Kozlowski wrote: >>> On Thu, Jan 30, 2025 at 10:04:56AM +0530, Raj Kumar Bhagat wrote: >>>> Add device-tree bindings for the ATH12K module found in the IPQ5332 >>>> device. >>>> >>>> Signed-off-by: Raj Kumar Bhagat <quic_rajkbhag@quicinc.com> >>>> --- >>>> .../net/wireless/qcom,ath12k-ahb.yaml | 319 ++++++++++++++++++ >>>> 1 file changed, 319 insertions(+) >>>> create mode 100644 Documentation/devicetree/bindings/net/wireless/qcom,ath12k-ahb.yaml >>>> >>>> diff --git a/Documentation/devicetree/bindings/net/wireless/qcom,ath12k-ahb.yaml b/Documentation/devicetree/bindings/net/wireless/qcom,ath12k-ahb.yaml >>>> new file mode 100644 >>>> index 000000000000..bd953a028dc3 >>>> --- /dev/null >>>> +++ b/Documentation/devicetree/bindings/net/wireless/qcom,ath12k-ahb.yaml >>> >>> Filename should match compatible. This binding does not look like >>> supporting more devices, so there is no much benefit calling it by generic name. >> >> >> I saw now your other patchset, so you have here two devices, but I still >> do not understand why this cannot follow standard naming practice like >> most bindings supporting one or more devices. Like every review we give. >> > > Sure, we can rename the filename to match the compatibles - "qcom,ipq5x-wifi.yaml". No: >>> Filename should match compatible. Best regards, Krzysztof
On 03/02/2025 10:05, Raj Kumar Bhagat wrote: > >>> + items: >>> + - const: q6-region >>> + - const: m3-dump >>> + - const: q6-caldb >>> + - const: mlo-global-mem >>> + >>> + qcom,ath12k-calibration-variant: >>> + $ref: /schemas/types.yaml#/definitions/string >> Why this is named after ath12k? Why this is just not >> "qcom,calibration-variant"? None of the other properties have ath12k in >> their names, so why this one in the WSI schema was named like that? >> > > This property is added after the below comment. > https://lore.kernel.org/all/qzjgpwemwaknwbs3dwils6kaa5c3inabfvkaryvc32kblzfhy3@6yduooj4dk63/ > > This `ath12k` in the name of this property is inherited from the 'qcom,ath10k.yaml' and > 'qcom,ath11k.yaml'. Same was followed for WSI schema as well. They do not have ath12k prefix in the name, so I don't understand. People, start re-using properties, not creating one per each binding. > >>> + description: >>> + String to uniquely identify variant of the calibration data for designs >>> + with colliding bus and device ids >> I don't think this property is here possible. How could you have on the >> same SoC different devices? > > The WiFi controller in the SoC includes an internal or external Front-End Module (FEM). > These FEMs can vary and require different calibration data. This property uniquely 1. So exactly the same SoC package has different FEMs? 2. How does it exactly work? Different bins? Different revisions? 3. How is it supposed to work in practice - you have one board, but might have different SoCs inside? Which calibration data would you use in such case? > identify the variant of calibration data required by a FEM. > Best regards, Krzysztof
On 2/3/2025 3:35 PM, Krzysztof Kozlowski wrote: > On 03/02/2025 09:43, Raj Kumar Bhagat wrote: >> On 1/30/2025 2:10 PM, Krzysztof Kozlowski wrote: >>> On 30/01/2025 09:28, Krzysztof Kozlowski wrote: >>>> On Thu, Jan 30, 2025 at 10:04:56AM +0530, Raj Kumar Bhagat wrote: >>>>> Add device-tree bindings for the ATH12K module found in the IPQ5332 >>>>> device. >>>>> >>>>> Signed-off-by: Raj Kumar Bhagat <quic_rajkbhag@quicinc.com> >>>>> --- >>>>> .../net/wireless/qcom,ath12k-ahb.yaml | 319 ++++++++++++++++++ >>>>> 1 file changed, 319 insertions(+) >>>>> create mode 100644 Documentation/devicetree/bindings/net/wireless/qcom,ath12k-ahb.yaml >>>>> >>>>> diff --git a/Documentation/devicetree/bindings/net/wireless/qcom,ath12k-ahb.yaml b/Documentation/devicetree/bindings/net/wireless/qcom,ath12k-ahb.yaml >>>>> new file mode 100644 >>>>> index 000000000000..bd953a028dc3 >>>>> --- /dev/null >>>>> +++ b/Documentation/devicetree/bindings/net/wireless/qcom,ath12k-ahb.yaml >>>> >>>> Filename should match compatible. This binding does not look like >>>> supporting more devices, so there is no much benefit calling it by generic name. >>> >>> >>> I saw now your other patchset, so you have here two devices, but I still >>> do not understand why this cannot follow standard naming practice like >>> most bindings supporting one or more devices. Like every review we give. >>> >> >> Sure, we can rename the filename to match the compatibles - "qcom,ipq5x-wifi.yaml". > > No: > >>>> Filename should match compatible. > > Ok, will rename to - "qcom,ipq5332-wifi.yaml"
On 2/3/2025 3:39 PM, Krzysztof Kozlowski wrote: > On 03/02/2025 10:05, Raj Kumar Bhagat wrote: >> >>>> + items: >>>> + - const: q6-region >>>> + - const: m3-dump >>>> + - const: q6-caldb >>>> + - const: mlo-global-mem >>>> + >>>> + qcom,ath12k-calibration-variant: >>>> + $ref: /schemas/types.yaml#/definitions/string >>> Why this is named after ath12k? Why this is just not >>> "qcom,calibration-variant"? None of the other properties have ath12k in >>> their names, so why this one in the WSI schema was named like that? >>> >> >> This property is added after the below comment. >> https://lore.kernel.org/all/qzjgpwemwaknwbs3dwils6kaa5c3inabfvkaryvc32kblzfhy3@6yduooj4dk63/ >> >> This `ath12k` in the name of this property is inherited from the 'qcom,ath10k.yaml' and >> 'qcom,ath11k.yaml'. Same was followed for WSI schema as well. > > They do not have ath12k prefix in the name, so I don't understand. > I meant that, 'qcom,ath10k.yaml' has qcom,ath10k-calibration-variant and 'qcom,ath11k.yaml' has qcom,ath11k-calibration-variant. The same name pattern has been inherited. > People, start re-using properties, not creating one per each binding. > >> >>>> + description: >>>> + String to uniquely identify variant of the calibration data for designs >>>> + with colliding bus and device ids >>> I don't think this property is here possible. How could you have on the >>> same SoC different devices? >> >> The WiFi controller in the SoC includes an internal or external Front-End Module (FEM). >> These FEMs can vary and require different calibration data. This property uniquely > > 1. So exactly the same SoC package has different FEMs? > Yes, the WiFi component of the same SoC package can have different FEMs. > 2. How does it exactly work? Different bins? Different revisions? > The calibration board data for different variant are packed into firmware binary 'board-2.bin'. Thus, board-2.bin can contain multiple board data for various variants. Ath12k driver selects the correct board data based on the variant. The "qcom,ath12k-calibration-variant" is used as one of the parameter to select the correct board data from board-2.bin. > 3. How is it supposed to work in practice - you have one board, but > might have different SoCs inside? Which calibration data would you use > in such case? > The SoC in the following statement 'you have one board, but might have different SoCs inside' , I am assuming SoC to be WiFi controller/component. Consider, if we have two WiFi (qcom,ipq5332-wifi) controller with different FEM in IPQ5332 board. Then in the DTS we have two wifi node. Each wifi node in DTS will have different value for 'qcom,ath12k-calibration-variant'. With the help of this property driver will be able to download the correct calibration board data from board-2.bin.
On 04/02/2025 06:57, Raj Kumar Bhagat wrote: > > The calibration board data for different variant are packed into firmware binary 'board-2.bin'. > Thus, board-2.bin can contain multiple board data for various variants. Ath12k driver selects > the correct board data based on the variant. The "qcom,ath12k-calibration-variant" is used > as one of the parameter to select the correct board data from board-2.bin. > >> 3. How is it supposed to work in practice - you have one board, but >> might have different SoCs inside? Which calibration data would you use >> in such case? >> > > The SoC in the following statement 'you have one board, but might have different SoCs inside' > , I am assuming SoC to be WiFi controller/component. > > Consider, if we have two WiFi (qcom,ipq5332-wifi) controller with different FEM in IPQ5332 board. > Then in the DTS we have two wifi node. Each wifi node in DTS will have different value for > 'qcom,ath12k-calibration-variant'. With the help of this property driver will be able to > download the correct calibration board data from board-2.bin. Indeed, that makes sense. Thanks for explanation. Best regards, Krzysztof
diff --git a/Documentation/devicetree/bindings/net/wireless/qcom,ath12k-ahb.yaml b/Documentation/devicetree/bindings/net/wireless/qcom,ath12k-ahb.yaml new file mode 100644 index 000000000000..bd953a028dc3 --- /dev/null +++ b/Documentation/devicetree/bindings/net/wireless/qcom,ath12k-ahb.yaml @@ -0,0 +1,319 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +# Copyright (c) 2024-2025 Qualcomm Innovation Center, Inc. All rights reserved. +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/wireless/qcom,ath12k-ahb.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Technologies ath12k wireless devices (AHB) + +maintainers: + - Kalle Valo <kvalo@kernel.org> + - Jeff Johnson <jjohnson@kernel.org> + +description: + Qualcomm Technologies IEEE 802.11be AHB devices. + +properties: + compatible: + enum: + - qcom,ipq5332-wifi + + reg: + maxItems: 1 + + clocks: + items: + - description: XO clock used for copy engine + + clock-names: + items: + - const: xo + + interrupts: + items: + - description: Fatal interrupt + - description: Ready interrupt + - description: Spawn acknowledge interrupt + - description: Stop acknowledge interrupt + - description: misc-pulse1 interrupt events + - description: misc-latch interrupt events + - description: sw exception interrupt events + - description: interrupt event for ring CE0 + - description: interrupt event for ring CE1 + - description: interrupt event for ring CE2 + - description: interrupt event for ring CE3 + - description: interrupt event for ring CE4 + - description: interrupt event for ring CE5 + - description: interrupt event for ring CE6 + - description: interrupt event for ring CE7 + - description: interrupt event for ring CE8 + - description: interrupt event for ring CE9 + - description: interrupt event for ring CE10 + - description: interrupt event for ring CE11 + - description: interrupt event for ring host2wbm-desc-feed + - description: interrupt event for ring host2reo-re-injection + - description: interrupt event for ring host2reo-command + - description: interrupt event for ring host2rxdma-monitor-ring1 + - description: interrupt event for ring reo2ost-exception + - description: interrupt event for ring wbm2host-rx-release + - description: interrupt event for ring reo2host-status + - description: interrupt event for ring reo2host-destination-ring4 + - description: interrupt event for ring reo2host-destination-ring3 + - description: interrupt event for ring reo2host-destination-ring2 + - description: interrupt event for ring reo2host-destination-ring1 + - description: interrupt event for ring rxdma2host-monitor-destination-mac3 + - description: interrupt event for ring rxdma2host-monitor-destination-mac2 + - description: interrupt event for ring rxdma2host-monitor-destination-mac1 + - description: interrupt event for ring host2rxdma-host-buf-ring-mac3 + - description: interrupt event for ring host2rxdma-host-buf-ring-mac2 + - description: interrupt event for ring host2rxdma-host-buf-ring-mac1 + - description: interrupt event for ring host2tcl-input-ring4 + - description: interrupt event for ring host2tcl-input-ring3 + - description: interrupt event for ring host2tcl-input-ring2 + - description: interrupt event for ring host2tcl-input-ring1 + - description: interrupt event for ring wbm2host-tx-completions-ring4 + - description: interrupt event for ring wbm2host-tx-completions-ring3 + - description: interrupt event for ring wbm2host-tx-completions-ring2 + - description: interrupt event for ring wbm2host-tx-completions-ring1 + - description: interrupt event for ring host2tx-monitor-ring1 + - description: interrupt event for ring txmon2host-monitor-destination-mac3 + - description: interrupt event for ring txmon2host-monitor-destination-mac2 + - description: interrupt event for ring txmon2host-monitor-destination-mac1 + - description: interrupt event for umac-reset + + interrupt-names: + items: + - const: fatal + - const: ready + - const: spawn + - const: stop-ack + - const: misc-pulse1 + - const: misc-latch + - const: sw-exception + - const: ce0 + - const: ce1 + - const: ce2 + - const: ce3 + - const: ce4 + - const: ce5 + - const: ce6 + - const: ce7 + - const: ce8 + - const: ce9 + - const: ce10 + - const: ce11 + - const: host2wbm-desc-feed + - const: host2reo-re-injection + - const: host2reo-command + - const: host2rxdma-monitor-ring1 + - const: reo2ost-exception + - const: wbm2host-rx-release + - const: reo2host-status + - const: reo2host-destination-ring4 + - const: reo2host-destination-ring3 + - const: reo2host-destination-ring2 + - const: reo2host-destination-ring1 + - const: rxdma2host-monitor-destination-mac3 + - const: rxdma2host-monitor-destination-mac2 + - const: rxdma2host-monitor-destination-mac1 + - const: host2rxdma-host-buf-ring-mac3 + - const: host2rxdma-host-buf-ring-mac2 + - const: host2rxdma-host-buf-ring-mac1 + - const: host2tcl-input-ring4 + - const: host2tcl-input-ring3 + - const: host2tcl-input-ring2 + - const: host2tcl-input-ring1 + - const: wbm2host-tx-completions-ring4 + - const: wbm2host-tx-completions-ring3 + - const: wbm2host-tx-completions-ring2 + - const: wbm2host-tx-completions-ring1 + - const: host2tx-monitor-ring1 + - const: txmon2host-monitor-destination-mac3 + - const: txmon2host-monitor-destination-mac2 + - const: txmon2host-monitor-destination-mac1 + - const: umac-reset + + memory-region: + description: + phandle to a node describing reserved memory (System RAM memory) + used by ath12k firmware (see bindings/reserved-memory/reserved-memory.txt) + items: + - description: Q6 memory region + - description: m3 dump memory region + - description: Q6 caldata memory region + - description: Multi Link Operation (MLO) Global memory region + + memory-region-names: + description: + Name of the reserved memory region used by ath12k firmware + items: + - const: q6-region + - const: m3-dump + - const: q6-caldb + - const: mlo-global-mem + + qcom,ath12k-calibration-variant: + $ref: /schemas/types.yaml#/definitions/string + description: + String to uniquely identify variant of the calibration data for designs + with colliding bus and device ids + + qcom,rproc: + $ref: /schemas/types.yaml#/definitions/phandle + description: + Phandle to the Qualcomm Hexagon DSP(q6 remote processor), which is utilized + for offloading WiFi processing tasks, this q6 remote processor operates in + conjunction with WiFi. + + qcom,smem-states: + $ref: /schemas/types.yaml#/definitions/phandle-array + description: States used by the AP to signal the remote processor + items: + - description: Shutdown WCSS pd + - description: Stop WCSS pd + - description: Spawn WCSS pd + + qcom,smem-state-names: + description: + Names of the states used by the AP to signal the remote processor + items: + - const: shutdown + - const: stop + - const: spawn + +required: + - compatible + - reg + - clocks + - clock-names + - interrupts + - interrupt-names + - memory-region + - memory-region-names + - qcom,rproc + - qcom,smem-states + - qcom,smem-state-names + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/clock/qcom,ipq5332-gcc.h> + + wifi0: wifi@c000000 { + compatible = "qcom,ipq5332-wifi"; + reg = <0x0c000000 0x1000000>; + clocks = <&gcc GCC_XO_CLK>; + clock-names = "xo"; + interrupts-extended = <&wcss_smp2p_in 8 IRQ_TYPE_NONE>, + <&wcss_smp2p_in 9 IRQ_TYPE_NONE>, + <&wcss_smp2p_in 12 IRQ_TYPE_NONE>, + <&wcss_smp2p_in 11 IRQ_TYPE_NONE>, + <&intc GIC_SPI 559 IRQ_TYPE_EDGE_RISING>, + <&intc GIC_SPI 560 IRQ_TYPE_EDGE_RISING>, + <&intc GIC_SPI 561 IRQ_TYPE_EDGE_RISING>, + <&intc GIC_SPI 422 IRQ_TYPE_EDGE_RISING>, + <&intc GIC_SPI 423 IRQ_TYPE_EDGE_RISING>, + <&intc GIC_SPI 424 IRQ_TYPE_EDGE_RISING>, + <&intc GIC_SPI 425 IRQ_TYPE_EDGE_RISING>, + <&intc GIC_SPI 426 IRQ_TYPE_EDGE_RISING>, + <&intc GIC_SPI 427 IRQ_TYPE_EDGE_RISING>, + <&intc GIC_SPI 428 IRQ_TYPE_EDGE_RISING>, + <&intc GIC_SPI 429 IRQ_TYPE_EDGE_RISING>, + <&intc GIC_SPI 430 IRQ_TYPE_EDGE_RISING>, + <&intc GIC_SPI 431 IRQ_TYPE_EDGE_RISING>, + <&intc GIC_SPI 432 IRQ_TYPE_EDGE_RISING>, + <&intc GIC_SPI 433 IRQ_TYPE_EDGE_RISING>, + <&intc GIC_SPI 491 IRQ_TYPE_EDGE_RISING>, + <&intc GIC_SPI 495 IRQ_TYPE_EDGE_RISING>, + <&intc GIC_SPI 493 IRQ_TYPE_EDGE_RISING>, + <&intc GIC_SPI 544 IRQ_TYPE_EDGE_RISING>, + <&intc GIC_SPI 457 IRQ_TYPE_EDGE_RISING>, + <&intc GIC_SPI 466 IRQ_TYPE_EDGE_RISING>, + <&intc GIC_SPI 497 IRQ_TYPE_EDGE_RISING>, + <&intc GIC_SPI 454 IRQ_TYPE_EDGE_RISING>, + <&intc GIC_SPI 453 IRQ_TYPE_EDGE_RISING>, + <&intc GIC_SPI 452 IRQ_TYPE_EDGE_RISING>, + <&intc GIC_SPI 451 IRQ_TYPE_EDGE_RISING>, + <&intc GIC_SPI 488 IRQ_TYPE_EDGE_RISING>, + <&intc GIC_SPI 488 IRQ_TYPE_EDGE_RISING>, + <&intc GIC_SPI 484 IRQ_TYPE_EDGE_RISING>, + <&intc GIC_SPI 554 IRQ_TYPE_EDGE_RISING>, + <&intc GIC_SPI 554 IRQ_TYPE_EDGE_RISING>, + <&intc GIC_SPI 549 IRQ_TYPE_EDGE_RISING>, + <&intc GIC_SPI 507 IRQ_TYPE_EDGE_RISING>, + <&intc GIC_SPI 500 IRQ_TYPE_EDGE_RISING>, + <&intc GIC_SPI 499 IRQ_TYPE_EDGE_RISING>, + <&intc GIC_SPI 498 IRQ_TYPE_EDGE_RISING>, + <&intc GIC_SPI 450 IRQ_TYPE_EDGE_RISING>, + <&intc GIC_SPI 449 IRQ_TYPE_EDGE_RISING>, + <&intc GIC_SPI 448 IRQ_TYPE_EDGE_RISING>, + <&intc GIC_SPI 447 IRQ_TYPE_EDGE_RISING>, + <&intc GIC_SPI 543 IRQ_TYPE_EDGE_RISING>, + <&intc GIC_SPI 486 IRQ_TYPE_EDGE_RISING>, + <&intc GIC_SPI 486 IRQ_TYPE_EDGE_RISING>, + <&intc GIC_SPI 482 IRQ_TYPE_EDGE_RISING>, + <&intc GIC_SPI 419 IRQ_TYPE_EDGE_RISING>; + interrupt-names = "fatal", + "ready", + "spawn", + "stop-ack", + "misc-pulse1", + "misc-latch", + "sw-exception", + "ce0", + "ce1", + "ce2", + "ce3", + "ce4", + "ce5", + "ce6", + "ce7", + "ce8", + "ce9", + "ce10", + "ce11", + "host2wbm-desc-feed", + "host2reo-re-injection", + "host2reo-command", + "host2rxdma-monitor-ring1", + "reo2ost-exception", + "wbm2host-rx-release", + "reo2host-status", + "reo2host-destination-ring4", + "reo2host-destination-ring3", + "reo2host-destination-ring2", + "reo2host-destination-ring1", + "rxdma2host-monitor-destination-mac3", + "rxdma2host-monitor-destination-mac2", + "rxdma2host-monitor-destination-mac1", + "host2rxdma-host-buf-ring-mac3", + "host2rxdma-host-buf-ring-mac2", + "host2rxdma-host-buf-ring-mac1", + "host2tcl-input-ring4", + "host2tcl-input-ring3", + "host2tcl-input-ring2", + "host2tcl-input-ring1", + "wbm2host-tx-completions-ring4", + "wbm2host-tx-completions-ring3", + "wbm2host-tx-completions-ring2", + "wbm2host-tx-completions-ring1", + "host2tx-monitor-ring1", + "txmon2host-monitor-destination-mac3", + "txmon2host-monitor-destination-mac2", + "txmon2host-monitor-destination-mac1", + "umac-reset"; + + memory-region = <&q6_region>, <&m3_dump>, <&q6_caldb>, <&mlo_mem>; + memory-region-names = "q6-region", "m3-dump", "q6-caldb", "mlo-global-mem"; + qcom,ath12k-calibration-variant = "RDP441_1"; + qcom,rproc = <&q6v5_wcss>; + qcom,smem-states = <&wcss_smp2p_out 8>, + <&wcss_smp2p_out 9>, + <&wcss_smp2p_out 10>; + qcom,smem-state-names = "shutdown", + "stop", + "spawn"; + };
Add device-tree bindings for the ATH12K module found in the IPQ5332 device. Signed-off-by: Raj Kumar Bhagat <quic_rajkbhag@quicinc.com> --- .../net/wireless/qcom,ath12k-ahb.yaml | 319 ++++++++++++++++++ 1 file changed, 319 insertions(+) create mode 100644 Documentation/devicetree/bindings/net/wireless/qcom,ath12k-ahb.yaml