Thread (20 messages) 20 messages, 6 authors, 4d ago

Re: [PATCH 4/6] dt-bindings: net: bluetooth: Document Qualcomm IPQ5018 Bluetooth controller

From: Konrad Dybcio <hidden>
Date: 2026-06-26 11:30:19
Also in: linux-arm-msm, linux-block, linux-bluetooth, linux-devicetree, linux-mmc, linux-remoteproc, linux-wireless, lkml

On 6/26/26 1:20 PM, George Moussalem wrote:
On 6/26/26 14:53, Krzysztof Kozlowski wrote:
quoted
On Thu, Jun 25, 2026 at 06:10:08PM +0400, George Moussalem wrote:
quoted
Document the Qualcomm IPQ5018 Bluetooth controller.

Signed-off-by: George Moussalem <redacted>
---
[...]
quoted
quoted
+      compatible = "qcom,ipq5018-bt";
+
+      qcom,ipc = <&apcs_glb 8 23>;
+      interrupts = <GIC_SPI 162 IRQ_TYPE_EDGE_RISING>;
No firmware to load?
firmware is loaded by the remoteproc in patch 1
quoted
It feels like remoteproc node split is fake. The property qcom,rproc is
even more supporting that case. Shouldn't this be simply one device -
bluetooth? What sort of two devices do you have exactly? How can I
identify them in the hardware?
I wasn't sure how to represent the HW. Should I make this bluetooth node
a childnode of the rproc? Essentially, this is the transport layer
(using shared memory space and IPC/interrupt).

Most QCA BT controllers are also childnodes of a serdev/uart node as
they use serdev for transport.

From what I understand, it's simply BT firmware running on this
dedicated M0 core in the SoC itself connected to an RF.
Seems like this rhymes with the WPSS remoteproc +ATH1xK_AHB situation
- the Q6 core power sequences and manages the wireless controller,
while Linux gets to drive the device as it would if it were connected
over PCIe/ UART respectively, just with MMIO writes instead.

Konrad
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help