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

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.

> 
> 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