On 6/26/26 1:20 PM, George Moussalem wrote: > On 6/26/26 14:53, Krzysztof Kozlowski wrote: >> On Thu, Jun 25, 2026 at 06:10:08PM +0400, George Moussalem wrote: >>> Document the Qualcomm IPQ5018 Bluetooth controller. >>> >>> Signed-off-by: George Moussalem <[email protected]> >>> ---
[...] >>> + 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 > >> >> 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
