Re: [PATCH 00/11] char: qcom_csm_dp: Add data path driver for QDU100 device

[Loic Poulain]

Hi Sivareddy,

On Thu, Dec 11, 2025 at 9:07 AM Sivareddy Surasani
<sivareddy.surasani@xxxxxxxxxxxxxxxx> wrote:
>
> This series introduces a character device driver for the Qualcomm
> Cell Site Modem (CSM) Data Path (DP) interface to support the
> QDU100 5G distributed unit in cellular base station deployments
>
> The driver enables high-performance communication between an x86
> Layer 2 host and the Qualcomm Distributed Unit (QDU100) by

Why specifically a x86 host?

> transmitting and receiving FAPI packets over PCIe using the Modem
> Host Interface (MHI). The design targets low-latency, high-rate
> data movement suitable for real-time 5G workloads.

It most likely belongs in the WWAN subsystem. While WWAN currently
focuses on User‑Equipment/Modem‑type devices, there is nothing
preventing us from extending the framework to support Distributed‑Unit
accelerators, including defining a new device_type or other
abstractions as needed.

>
> Key features
> ------------
>  - Provide a character-based interface to userspace and register as
>    an MHI client.
>  - Implement zero-copy using shared rings and memory pools to avoid
>    data copies between user and kernel space, reducing latency and
>    increasing throughput.

We already have established mechanisms for this like dma‑buf, udmabuf,
io_uring, etc.
Is there a reason we can’t leverage those instead of introducing something new?
Also, AFAIK, MHI is also already using rings internally for transfers,

>  - Expose ioctls for memory pool management and packet transmission.
>  - Support two DMA channels (control and data) with system
>    configuration ensuring correct channel assignment.
>  - Add SR-IOV support so QDU100 can present multiple virtual PCIe
>    functions to the host, scaling to up to 12 devices with up to 4
>    virtual functions per device.
>
> Userspace API(dp-lib)
> -------------
> The character device exposes ioctls to:
>  - create and manage memory pools and shared rings
>  - enqueue and dequeue packet buffers for TX/RX
>  - configure control vs data channel usage
> dp-lib: https://github.com/qualcomm/dp-lib

Since FAPI is a standard, could this be exposed as a new generic FAPI
interface/API?

>
> MHI
> -------
> Add support to read MHI capabilities. Initial post of MHI
> capabilities is referenced here:
> https://lore.kernel.org/all/202508181647.7mZJVOr6-lkp@xxxxxxxxx/
>
> Add data path channels and event rings for QDU100 VFs. Disable
> IRQ moderation for hardware channels to improve latency.
>
> IP_HW1: Control configuration procedures over the L1 FAPI P5
> interface include initialization, termination, restart, reset,
> and error notification. These procedures transition the PHY
> layer through IDLE, CONFIGURED, and RUNNING states.

Why calling this channel IP_HW1, and not FAPI_CTRL...

>
> IP_HW2: Data path configuration procedures control DL and UL
> frame structures and transfer subframe data between L2/L3
> software and PHY. Supported procedures include subframe message
> transmission, SFN/SF synchronization, and various transport
> channel operations.

Could it be a FAPI_DATA channel?

Regards,
Loic