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

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.

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

>> +
>> +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).

The first region handles the raw video frame data (which is sufficient
for capture if configured by userspace). The second region provides
host control info for automatic resolution detection.

In the vtconsole scenario, this second control region is not present.
Making it required would incorrectly exclude systems that can capture
frames but lack auto-detection. I will clarify this variance in v2.

Best regards,
TH

> Best regards,
> Krzysztof