Re: [PATCH 1/2] dt-bindings: media: add axiado,ax3000-video

On 2026/8/3 2:28 PM, Krzysztof Kozlowski wrote:
> On 03/08/2026 07:29, Tzu-Hao Wei wrote:
>> On 7/30/2026 4:12 PM, Krzysztof Kozlowski wrote:
>>> On 30/07/2026 09:26, Tzu-Hao Wei wrote:
>>>> Add a Device Tree binding for the Axiado AX3000 and AX3005 video
>>>> capture path. There is no local register interface to describe: frames
>>>> arrive asynchronously into a reserved memory region written by the
>>>> host's display engine over PCIe, and this node only identifies that
>>>> region.
>>>>
>>>> memory-region accepts an optional second entry for a host-written
>>>> control mailbox, letting the driver detect the mode the host is
>>>> actually driving instead of only echoing back the configured capture
>>>> format.
>>>>
>>>> Signed-off-by: Tzu-Hao Wei <[email protected]>
>>>> ---
>>>>   .../bindings/media/axiado,ax3000-video.yaml        | 44 ++++++++++++++++++++++
>>>>   MAINTAINERS                                        |  8 ++++
>>>>   2 files changed, 52 insertions(+)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/media/axiado,ax3000-video.yaml b/Documentation/devicetree/bindings/media/axiado,ax3000-video.yaml
>>>> new file mode 100644
>>>> index 0000000000000000000000000000000000000000..c6d8d1843aac9f42869ff90a550b92d0bed7c16f
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/media/axiado,ax3000-video.yaml
>>>> @@ -0,0 +1,44 @@
>>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>>>> +%YAML 1.2
>>>> +---
>>>> +$id: http://devicetree.org/schemas/media/axiado,ax3000-video.yaml#
>>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>>>> +
>>>> +title: Axiado AX3000 Video Controller
>>>> +
>>>> +maintainers:
>>>> +  - Shubhangini G <[email protected]>
>>>> +  - Tzu-Hao Wei <[email protected]>
>>>> +  - Prasad Bolisetty <[email protected]>
>>>> +
>>>> +description:
>>>> +  Axiado AX3000 video capture controller. Reads frames written by the
>>>> +  display engine into a shared reserved memory region and exposes them
>>>> +  as a V4L2 capture device.
>>>
>>> This is really incomplete. You need at least way to power things on,
>>> reset them, provide clocks, sensors, data paths. Or at the very minimal:
>>> START capturing the frames after configuring the resolution.
>>>
>>> It seems you described driver or just a piece of entire video pipeline.
>>>
>>
>> Thanks for your feedback.
>>
>> The Axiado AX3000 and AX3005 SoCs expose a display capture path that
>> delivers frames into a shared reserved memory region and exposes them
>> as a standard V4L2 capture device via the videobuf2 framework.
>>
>> There is no local register interface for this driver to program: frame
>> delivery is controlled entirely by the host-side display engine and
>> the PCIe endpoint mapping that feeds the shared region, both external
>> to this driver. A software polling timer schedules a workqueue item at
>> the configured framerate, which copies frames from the WC-mapped
>> shared region into vmalloc-backed vb2 buffers. Running the copy in a
>> work item rather than directly in the timer callback keeps potentially
>> multi-megabyte memcpy and per-pixel conversion work out of softirq
>> context.
> 
> Then this is not a separate device. You just described a Linux driver.
> 
> I still wait for answers of my question above. You described getting
> buffers only.
> 

Thank you for the continued review.

To correctly represent this in device tree without describing a
software driver as a hardware device, would moving the schema into
/reserved-memory be the preferred approach for v2?

Specifically, we are considering moving it to:
Documentation/devicetree/bindings/reserved-memory/axiado,ax3000-video-mem.yaml

This would follow the same Devicetree architectural pattern as
qcom,rmtfs-mem:
Documentation/devicetree/bindings/reserved-memory/qcom,rmtfs-mem.yaml

Just as qcom,rmtfs-mem describes a reserved memory buffer used by
remote processors and exports /dev/rmtfs_mem%d without hardware MMIO
registers, clocks, or resets, axiado,ax3000-video describes the
reserved memory buffer used by the AX3000 display pipeline and exports
/dev/video0.

Does representing axiado,ax3000-video as a reserved-memory node look
like the appropriate way to model this in v2?

Best regards,
TH 

>>
>> To provide more context, this hardware path is designed for BMC iKVM
>> applications. The physical data flow is:
>> Host Display Engine -> PCIe -> BMC Shared Memory -> v4l2 (video0).
> 
> Great, not a device. Linux driver.
> 
>>
>>>> +
>>>> +properties:
>>>> +  compatible:
>>>> +    oneOf:
>>>> +      - const: axiado,ax3000-video
>>>> +      - items:
>>>> +          - const: axiado,ax3005-video
>>>> +          - const: axiado,ax3000-video
>>>> +
>>>> +  memory-region:
>>>> +    minItems: 1
>>>> +    items:
>>>> +      - description: video frame buffer, shared with the display engine
>>>> +      - description: optional control mailbox, shared with the host
>>>
>>> Why is it optional?
>>>
>>
>> The second memory region is optional because it is not available on all
>> supported hardware configurations or use cases.
>>
>> For instance, another supported use case has the following data flow:
>> vtconsole -> framebuffer -> Shared Memory -> v4l2 (video0).
> 
> Use case is irrelevant to actual hardware.
> 
> 
> Best regards,
> Krzysztof