Re: [PATCH v2 08/10] dt-bindings: media: Document bindings for the Sunxi-Cedrus VPU driver

2018-05-04 Thread Maxime Ripard 
On Fri, May 04, 2018 at 09:56:20AM +0200, Paul Kocialkowski wrote:
> > > I agree that the term VPU is more commonly associated with video
> > > decoding, while video engine could mean a number of things.
> > > 
> > > The reason I went with "video-engine" here (while still presenting
> > > the
> > > driver as a VPU driver) is that Video Engine is the term used in
> > > Allwinner's litterature. Other nodes in Allwinner device-trees
> > > generally
> > > stick to these terms (for instance, we have "display-engine" nodes).
> > > This also makes it easier to find the matching parts in the
> > > documentation.
> > 
> > 'video-codec' is what is defined in the DT spec.
> 
> Is that an actively-enforced guideline or a suggestion? I'd like to keep
> video-engine just to stick with the technical documentation wording and
> my personal taste is also to prefer vpu over video-codec (in terms of
> clarity/straightforwardness) as a second choice.
> 
> Still, if the choice isn't up to me, we can go with video-codec (or
> vpu).

The unit-name is supposed to reflect the class of the device, and
nothing else. If there's already a pre-existing class name defined for
these kind of devices, then there's no point in choosing something
else.

Maxime

-- 
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com


signature.asc
Description: PGP signature

Re: [PATCH v2 08/10] dt-bindings: media: Document bindings for the Sunxi-Cedrus VPU driver

2018-05-04 Thread Paul Kocialkowski 
Hi,

On Thu, 2018-04-26 at 22:04 -0500, Rob Herring wrote:
> On Fri, Apr 20, 2018 at 09:22:20AM +0200, Paul Kocialkowski wrote:
> > Hi and thanks for the review,
> > 
> > On Fri, 2018-04-20 at 01:31 +, Tomasz Figa wrote:
> > > Hi Paul, Philipp,
> > > 
> > > On Fri, Apr 20, 2018 at 1:04 AM Philipp Zabel  > > .de>
> > > wrote:
> > > 
> > > > Hi Paul,
> > > > On Thu, 2018-04-19 at 17:45 +0200, Paul Kocialkowski wrote:
> > > > > This adds a device-tree binding document that specifies the
> > > > > properties
> > > > > used by the Sunxi-Cedurs VPU driver, as well as examples.
> > > > > 
> > > > > Signed-off-by: Paul Kocialkowski  > > > > m>
> > > > > ---
> > > > >  .../devicetree/bindings/media/sunxi-cedrus.txt | 50
> > > 
> > > ++
> > > > >  1 file changed, 50 insertions(+)
> > > > >  create mode 100644
> > > 
> > > Documentation/devicetree/bindings/media/sunxi-cedrus.txt
> > > > > 
> > > > > diff --git a/Documentation/devicetree/bindings/media/sunxi-
> > > > > cedrus.txt
> > > 
> > > b/Documentation/devicetree/bindings/media/sunxi-cedrus.txt
> > > > > new file mode 100644
> > > > > index ..71ad3f9c3352
> > > > > --- /dev/null
> > > > > +++ b/Documentation/devicetree/bindings/media/sunxi-cedrus.txt
> > > > > @@ -0,0 +1,50 @@
> > > > > +Device-tree bindings for the VPU found in Allwinner SoCs,
> > > > > referred to
> > > 
> > > as the
> > > > > +Video Engine (VE) in Allwinner literature.
> > > > > +
> > > > > +The VPU can only access the first 256 MiB of DRAM, that are
> > > > > DMA-
> > > > > mapped
> > > 
> > > starting
> > > > > +from the DRAM base. This requires specific memory allocation
> > > > > and
> > > 
> > > handling.
> > > 
> > > And no IOMMU? Brings back memories.
> > 
> > Exactly, no IOMMU so we don't have much choice but cope with that
> > hardware limitation...
> > 
> > > > > +
> > > > > +Required properties:
> > > > > +- compatible : "allwinner,sun4i-a10-video-engine";
> > > > > +- memory-region : DMA pool for buffers allocation;
> > > > > +- clocks : list of clock specifiers,
> > > > > corresponding to
> > > 
> > > entries in
> > > > > +  the clock-names property;
> > > > > +- clock-names: should contain "ahb", "mod"
> > > > > and
> > > > > "ram"
> > > 
> > > entries;
> > > > > +- assigned-clocks   : list of clocks assigned to the VE;
> > > > > +- assigned-clocks-rates : list of clock rates for the clocks
> > > > > assigned
> > > 
> > > to the VE;
> > > > > +- resets : phandle for reset;
> > > > > +- interrupts : should contain VE interrupt number;
> > > > > +- reg: should contain register base
> > > > > and
> > > > > length
> > > 
> > > of VE.
> > > > > +
> > > > > +Example:
> > > > > +
> > > > > +reserved-memory {
> > > > > + #address-cells = <1>;
> > > > > + #size-cells = <1>;
> > > > > + ranges;
> > > > > +
> > > > > + /* Address must be kept in the lower 256 MiBs of DRAM
> > > > > for
> > > > > VE. */
> > > > > + ve_memory: cma@4a00 {
> > > > > + compatible = "shared-dma-pool";
> > > > > + reg = <0x4a00 0x600>;
> > > > > + no-map;
> > > > > + linux,cma-default;
> > > > > + };
> > > > > +};
> > > > > +
> > > > > +video-engine@1c0e000 {
> > > > 
> > > > This is not really required by any specification, and not as
> > > > common
> > > > as
> > > > gpu@..., but could this reasonably be called "vpu@1c0e000" to
> > > > follow
> > > > somewhat-common practice?
> > > 
> > > AFAIR the name is supposed to be somewhat readable for someone
> > > that
> > > doesn't know the hardware. To me, "video-engine" sounds more
> > > obvious
> > > than "vpu", but we actually use "codec" already, in case of MFC
> > > and
> > > JPEG codec on Exynos. If encode/decode is the only functionality
> > > of
> > > this block, I'd personally go with "codec". If it can do other
> > > things,
> > > e.g. scaling/rotation without encode/decode, I'd probably call it
> > > "video-processor".
> > 
> > I agree that the term VPU is more commonly associated with video
> > decoding, while video engine could mean a number of things.
> > 
> > The reason I went with "video-engine" here (while still presenting
> > the
> > driver as a VPU driver) is that Video Engine is the term used in
> > Allwinner's litterature. Other nodes in Allwinner device-trees
> > generally
> > stick to these terms (for instance, we have "display-engine" nodes).
> > This also makes it easier to find the matching parts in the
> > documentation.
> 
> 'video-codec' is what is defined in the DT spec.

Is that an actively-enforced guideline or a suggestion? I'd like to keep
video-engine just to stick with the technical documentation wording and
my personal taste is also to prefer vpu over video-codec (in terms of
clarity/straightforwardness) as a second choice.

Still, if the

Re: [PATCH v2 08/10] dt-bindings: media: Document bindings for the Sunxi-Cedrus VPU driver

2018-04-26 Thread Rob Herring 
On Thu, Apr 19, 2018 at 05:45:34PM +0200, Paul Kocialkowski wrote:
> This adds a device-tree binding document that specifies the properties
> used by the Sunxi-Cedurs VPU driver, as well as examples.
> 
> Signed-off-by: Paul Kocialkowski 
> ---
>  .../devicetree/bindings/media/sunxi-cedrus.txt | 50 
> ++
>  1 file changed, 50 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/media/sunxi-cedrus.txt

Other than the one nit about the node name,

Reviewed-by: Rob Herring

Re: [PATCH v2 08/10] dt-bindings: media: Document bindings for the Sunxi-Cedrus VPU driver

2018-04-26 Thread Rob Herring 
On Fri, Apr 20, 2018 at 09:22:20AM +0200, Paul Kocialkowski wrote:
> Hi and thanks for the review,
> 
> On Fri, 2018-04-20 at 01:31 +, Tomasz Figa wrote:
> > Hi Paul, Philipp,
> > 
> > On Fri, Apr 20, 2018 at 1:04 AM Philipp Zabel 
> > wrote:
> > 
> > > Hi Paul,
> > > On Thu, 2018-04-19 at 17:45 +0200, Paul Kocialkowski wrote:
> > > > This adds a device-tree binding document that specifies the
> > > > properties
> > > > used by the Sunxi-Cedurs VPU driver, as well as examples.
> > > > 
> > > > Signed-off-by: Paul Kocialkowski 
> > > > ---
> > > >  .../devicetree/bindings/media/sunxi-cedrus.txt | 50
> > 
> > ++
> > > >  1 file changed, 50 insertions(+)
> > > >  create mode 100644
> > 
> > Documentation/devicetree/bindings/media/sunxi-cedrus.txt
> > > > 
> > > > diff --git a/Documentation/devicetree/bindings/media/sunxi-
> > > > cedrus.txt
> > 
> > b/Documentation/devicetree/bindings/media/sunxi-cedrus.txt
> > > > new file mode 100644
> > > > index ..71ad3f9c3352
> > > > --- /dev/null
> > > > +++ b/Documentation/devicetree/bindings/media/sunxi-cedrus.txt
> > > > @@ -0,0 +1,50 @@
> > > > +Device-tree bindings for the VPU found in Allwinner SoCs,
> > > > referred to
> > 
> > as the
> > > > +Video Engine (VE) in Allwinner literature.
> > > > +
> > > > +The VPU can only access the first 256 MiB of DRAM, that are DMA-
> > > > mapped
> > 
> > starting
> > > > +from the DRAM base. This requires specific memory allocation and
> > 
> > handling.
> > 
> > And no IOMMU? Brings back memories.
> 
> Exactly, no IOMMU so we don't have much choice but cope with that
> hardware limitation...
> 
> > > > +
> > > > +Required properties:
> > > > +- compatible : "allwinner,sun4i-a10-video-engine";
> > > > +- memory-region : DMA pool for buffers allocation;
> > > > +- clocks : list of clock specifiers, corresponding to
> > 
> > entries in
> > > > +  the clock-names property;
> > > > +- clock-names: should contain "ahb", "mod" and
> > > > "ram"
> > 
> > entries;
> > > > +- assigned-clocks   : list of clocks assigned to the VE;
> > > > +- assigned-clocks-rates : list of clock rates for the clocks
> > > > assigned
> > 
> > to the VE;
> > > > +- resets : phandle for reset;
> > > > +- interrupts : should contain VE interrupt number;
> > > > +- reg: should contain register base and
> > > > length
> > 
> > of VE.
> > > > +
> > > > +Example:
> > > > +
> > > > +reserved-memory {
> > > > + #address-cells = <1>;
> > > > + #size-cells = <1>;
> > > > + ranges;
> > > > +
> > > > + /* Address must be kept in the lower 256 MiBs of DRAM for
> > > > VE. */
> > > > + ve_memory: cma@4a00 {
> > > > + compatible = "shared-dma-pool";
> > > > + reg = <0x4a00 0x600>;
> > > > + no-map;
> > > > + linux,cma-default;
> > > > + };
> > > > +};
> > > > +
> > > > +video-engine@1c0e000 {
> > > This is not really required by any specification, and not as common
> > > as
> > > gpu@..., but could this reasonably be called "vpu@1c0e000" to follow
> > > somewhat-common practice?
> > 
> > AFAIR the name is supposed to be somewhat readable for someone that
> > doesn't know the hardware. To me, "video-engine" sounds more obvious
> > than "vpu", but we actually use "codec" already, in case of MFC and
> > JPEG codec on Exynos. If encode/decode is the only functionality of
> > this block, I'd personally go with "codec". If it can do other things,
> > e.g. scaling/rotation without encode/decode, I'd probably call it
> > "video-processor".
> 
> I agree that the term VPU is more commonly associated with video
> decoding, while video engine could mean a number of things.
> 
> The reason I went with "video-engine" here (while still presenting the
> driver as a VPU driver) is that Video Engine is the term used in
> Allwinner's litterature. Other nodes in Allwinner device-trees generally
> stick to these terms (for instance, we have "display-engine" nodes).
> This also makes it easier to find the matching parts in the
> documentation.

'video-codec' is what is defined in the DT spec.

Rob

Re: [PATCH v2 08/10] dt-bindings: media: Document bindings for the Sunxi-Cedrus VPU driver

2018-04-20 Thread Paul Kocialkowski 
Hi and thanks for the review,

On Fri, 2018-04-20 at 01:31 +, Tomasz Figa wrote:
> Hi Paul, Philipp,
> 
> On Fri, Apr 20, 2018 at 1:04 AM Philipp Zabel 
> wrote:
> 
> > Hi Paul,
> > On Thu, 2018-04-19 at 17:45 +0200, Paul Kocialkowski wrote:
> > > This adds a device-tree binding document that specifies the
> > > properties
> > > used by the Sunxi-Cedurs VPU driver, as well as examples.
> > > 
> > > Signed-off-by: Paul Kocialkowski 
> > > ---
> > >  .../devicetree/bindings/media/sunxi-cedrus.txt | 50
> 
> ++
> > >  1 file changed, 50 insertions(+)
> > >  create mode 100644
> 
> Documentation/devicetree/bindings/media/sunxi-cedrus.txt
> > > 
> > > diff --git a/Documentation/devicetree/bindings/media/sunxi-
> > > cedrus.txt
> 
> b/Documentation/devicetree/bindings/media/sunxi-cedrus.txt
> > > new file mode 100644
> > > index ..71ad3f9c3352
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/media/sunxi-cedrus.txt
> > > @@ -0,0 +1,50 @@
> > > +Device-tree bindings for the VPU found in Allwinner SoCs,
> > > referred to
> 
> as the
> > > +Video Engine (VE) in Allwinner literature.
> > > +
> > > +The VPU can only access the first 256 MiB of DRAM, that are DMA-
> > > mapped
> 
> starting
> > > +from the DRAM base. This requires specific memory allocation and
> 
> handling.
> 
> And no IOMMU? Brings back memories.

Exactly, no IOMMU so we don't have much choice but cope with that
hardware limitation...

> > > +
> > > +Required properties:
> > > +- compatible : "allwinner,sun4i-a10-video-engine";
> > > +- memory-region : DMA pool for buffers allocation;
> > > +- clocks : list of clock specifiers, corresponding to
> 
> entries in
> > > +  the clock-names property;
> > > +- clock-names: should contain "ahb", "mod" and
> > > "ram"
> 
> entries;
> > > +- assigned-clocks   : list of clocks assigned to the VE;
> > > +- assigned-clocks-rates : list of clock rates for the clocks
> > > assigned
> 
> to the VE;
> > > +- resets : phandle for reset;
> > > +- interrupts : should contain VE interrupt number;
> > > +- reg: should contain register base and
> > > length
> 
> of VE.
> > > +
> > > +Example:
> > > +
> > > +reserved-memory {
> > > + #address-cells = <1>;
> > > + #size-cells = <1>;
> > > + ranges;
> > > +
> > > + /* Address must be kept in the lower 256 MiBs of DRAM for
> > > VE. */
> > > + ve_memory: cma@4a00 {
> > > + compatible = "shared-dma-pool";
> > > + reg = <0x4a00 0x600>;
> > > + no-map;
> > > + linux,cma-default;
> > > + };
> > > +};
> > > +
> > > +video-engine@1c0e000 {
> > This is not really required by any specification, and not as common
> > as
> > gpu@..., but could this reasonably be called "vpu@1c0e000" to follow
> > somewhat-common practice?
> 
> AFAIR the name is supposed to be somewhat readable for someone that
> doesn't know the hardware. To me, "video-engine" sounds more obvious
> than "vpu", but we actually use "codec" already, in case of MFC and
> JPEG codec on Exynos. If encode/decode is the only functionality of
> this block, I'd personally go with "codec". If it can do other things,
> e.g. scaling/rotation without encode/decode, I'd probably call it
> "video-processor".

I agree that the term VPU is more commonly associated with video
decoding, while video engine could mean a number of things.

The reason I went with "video-engine" here (while still presenting the
driver as a VPU driver) is that Video Engine is the term used in
Allwinner's litterature. Other nodes in Allwinner device-trees generally
stick to these terms (for instance, we have "display-engine" nodes).
This also makes it easier to find the matching parts in the
documentation.

Cheers,

-- 
Paul Kocialkowski, Bootlin (formerly Free Electrons)
Embedded Linux and kernel engineering
https://bootlin.com

signature.asc
Description: This is a digitally signed message part

Re: [PATCH v2 08/10] dt-bindings: media: Document bindings for the Sunxi-Cedrus VPU driver

2018-04-19 Thread Tomasz Figa 
Hi Paul, Philipp,

On Fri, Apr 20, 2018 at 1:04 AM Philipp Zabel 
wrote:

> Hi Paul,

> On Thu, 2018-04-19 at 17:45 +0200, Paul Kocialkowski wrote:
> > This adds a device-tree binding document that specifies the properties
> > used by the Sunxi-Cedurs VPU driver, as well as examples.
> >
> > Signed-off-by: Paul Kocialkowski 
> > ---
> >  .../devicetree/bindings/media/sunxi-cedrus.txt | 50
++
> >  1 file changed, 50 insertions(+)
> >  create mode 100644
Documentation/devicetree/bindings/media/sunxi-cedrus.txt
> >
> > diff --git a/Documentation/devicetree/bindings/media/sunxi-cedrus.txt
b/Documentation/devicetree/bindings/media/sunxi-cedrus.txt
> > new file mode 100644
> > index ..71ad3f9c3352
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/media/sunxi-cedrus.txt
> > @@ -0,0 +1,50 @@
> > +Device-tree bindings for the VPU found in Allwinner SoCs, referred to
as the
> > +Video Engine (VE) in Allwinner literature.
> > +
> > +The VPU can only access the first 256 MiB of DRAM, that are DMA-mapped
starting
> > +from the DRAM base. This requires specific memory allocation and
handling.

And no IOMMU? Brings back memories.

> > +
> > +Required properties:
> > +- compatible : "allwinner,sun4i-a10-video-engine";
> > +- memory-region : DMA pool for buffers allocation;
> > +- clocks : list of clock specifiers, corresponding to
entries in
> > +  the clock-names property;
> > +- clock-names: should contain "ahb", "mod" and "ram"
entries;
> > +- assigned-clocks   : list of clocks assigned to the VE;
> > +- assigned-clocks-rates : list of clock rates for the clocks assigned
to the VE;
> > +- resets : phandle for reset;
> > +- interrupts : should contain VE interrupt number;
> > +- reg: should contain register base and length
of VE.
> > +
> > +Example:
> > +
> > +reserved-memory {
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > + ranges;
> > +
> > + /* Address must be kept in the lower 256 MiBs of DRAM for VE. */
> > + ve_memory: cma@4a00 {
> > + compatible = "shared-dma-pool";
> > + reg = <0x4a00 0x600>;
> > + no-map;
> > + linux,cma-default;
> > + };
> > +};
> > +
> > +video-engine@1c0e000 {

> This is not really required by any specification, and not as common as
> gpu@..., but could this reasonably be called "vpu@1c0e000" to follow
> somewhat-common practice?

AFAIR the name is supposed to be somewhat readable for someone that doesn't
know the hardware. To me, "video-engine" sounds more obvious than "vpu",
but we actually use "codec" already, in case of MFC and JPEG codec on
Exynos. If encode/decode is the only functionality of this block, I'd
personally go with "codec". If it can do other things, e.g.
scaling/rotation without encode/decode, I'd probably call it
"video-processor".

Best regards,
Tomasz

Re: [PATCH v2 08/10] dt-bindings: media: Document bindings for the Sunxi-Cedrus VPU driver

2018-04-19 Thread Philipp Zabel 
Hi Paul,

On Thu, 2018-04-19 at 17:45 +0200, Paul Kocialkowski wrote:
> This adds a device-tree binding document that specifies the properties
> used by the Sunxi-Cedurs VPU driver, as well as examples.
> 
> Signed-off-by: Paul Kocialkowski 
> ---
>  .../devicetree/bindings/media/sunxi-cedrus.txt | 50 
> ++
>  1 file changed, 50 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/media/sunxi-cedrus.txt
> 
> diff --git a/Documentation/devicetree/bindings/media/sunxi-cedrus.txt 
> b/Documentation/devicetree/bindings/media/sunxi-cedrus.txt
> new file mode 100644
> index ..71ad3f9c3352
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/sunxi-cedrus.txt
> @@ -0,0 +1,50 @@
> +Device-tree bindings for the VPU found in Allwinner SoCs, referred to as the
> +Video Engine (VE) in Allwinner literature.
> +
> +The VPU can only access the first 256 MiB of DRAM, that are DMA-mapped 
> starting
> +from the DRAM base. This requires specific memory allocation and handling.
> +
> +Required properties:
> +- compatible : "allwinner,sun4i-a10-video-engine";
> +- memory-region : DMA pool for buffers allocation;
> +- clocks : list of clock specifiers, corresponding to entries in
> +  the clock-names property;
> +- clock-names: should contain "ahb", "mod" and "ram" entries;
> +- assigned-clocks   : list of clocks assigned to the VE;
> +- assigned-clocks-rates : list of clock rates for the clocks assigned to the 
> VE;
> +- resets : phandle for reset;
> +- interrupts : should contain VE interrupt number;
> +- reg: should contain register base and length of VE.
> +
> +Example:
> +
> +reserved-memory {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> +
> + /* Address must be kept in the lower 256 MiBs of DRAM for VE. */
> + ve_memory: cma@4a00 {
> + compatible = "shared-dma-pool";
> + reg = <0x4a00 0x600>;
> + no-map;
> + linux,cma-default;
> + };
> +};
> +
> +video-engine@1c0e000 {

This is not really required by any specification, and not as common as
gpu@..., but could this reasonably be called "vpu@1c0e000" to follow
somewhat-common practice?

> + compatible = "allwinner,sun4i-a10-video-engine";
> + reg = <0x01c0e000 0x1000>;
> + memory-region = <_memory>;
> +
> + clocks = < CLK_AHB_VE>, < CLK_VE>,
> +  < CLK_DRAM_VE>;
> + clock-names = "ahb", "mod", "ram";
> +
> + assigned-clocks = < CLK_VE>;
> + assigned-clock-rates = <32000>;
> +
> + resets = < RST_VE>;
> +
> + interrupts = ;
> +};

regards
Philipp

[PATCH v2 08/10] dt-bindings: media: Document bindings for the Sunxi-Cedrus VPU driver

2018-04-19 Thread Paul Kocialkowski 
This adds a device-tree binding document that specifies the properties
used by the Sunxi-Cedurs VPU driver, as well as examples.

Signed-off-by: Paul Kocialkowski 
---
 .../devicetree/bindings/media/sunxi-cedrus.txt | 50 ++
 1 file changed, 50 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/sunxi-cedrus.txt

diff --git a/Documentation/devicetree/bindings/media/sunxi-cedrus.txt 
b/Documentation/devicetree/bindings/media/sunxi-cedrus.txt
new file mode 100644
index ..71ad3f9c3352
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/sunxi-cedrus.txt
@@ -0,0 +1,50 @@
+Device-tree bindings for the VPU found in Allwinner SoCs, referred to as the
+Video Engine (VE) in Allwinner literature.
+
+The VPU can only access the first 256 MiB of DRAM, that are DMA-mapped starting
+from the DRAM base. This requires specific memory allocation and handling.
+
+Required properties:
+- compatible   : "allwinner,sun4i-a10-video-engine";
+- memory-region : DMA pool for buffers allocation;
+- clocks   : list of clock specifiers, corresponding to entries in
+  the clock-names property;
+- clock-names  : should contain "ahb", "mod" and "ram" entries;
+- assigned-clocks   : list of clocks assigned to the VE;
+- assigned-clocks-rates : list of clock rates for the clocks assigned to the 
VE;
+- resets   : phandle for reset;
+- interrupts   : should contain VE interrupt number;
+- reg  : should contain register base and length of VE.
+
+Example:
+
+reserved-memory {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges;
+
+   /* Address must be kept in the lower 256 MiBs of DRAM for VE. */
+   ve_memory: cma@4a00 {
+   compatible = "shared-dma-pool";
+   reg = <0x4a00 0x600>;
+   no-map;
+   linux,cma-default;
+   };
+};
+
+video-engine@1c0e000 {
+   compatible = "allwinner,sun4i-a10-video-engine";
+   reg = <0x01c0e000 0x1000>;
+   memory-region = <_memory>;
+
+   clocks = < CLK_AHB_VE>, < CLK_VE>,
+< CLK_DRAM_VE>;
+   clock-names = "ahb", "mod", "ram";
+
+   assigned-clocks = < CLK_VE>;
+   assigned-clock-rates = <32000>;
+
+   resets = < RST_VE>;
+
+   interrupts = ;
+};
-- 
2.16.3