[PATCH 1/1] add mali r6p2 dt node

[PATCH 1/1] add mali r6p2 dt node

[Giulio Benetti]

It seems there is not mali node in sun7i-a20.dtsi

Add mali node to sun7i-a20.dtsi

This patch adds device tree mali node compatible with r6p2 utgard kernel driver 
provided by ARM and patched by maxime ripard on his github.

It can be easily used in target.dts with:

&mali {
	status = "okay";
}

then loading mali.ko in user space.

Signed-off-by: Giulio Benetti <giulio.benetti@micronovasrl.com>
---
 arch/arm/boot/dts/sun7i-a20.dtsi | 27 +++++++++++++++++++++++++++
 1 file changed, 27 insertions(+)

diff --git a/arch/arm/boot/dts/sun7i-a20.dtsi b/arch/arm/boot/dts/sun7i-a20.dtsi
index 228c368..e402596 100644
--- a/arch/arm/boot/dts/sun7i-a20.dtsi
+++ b/arch/arm/boot/dts/sun7i-a20.dtsi
@@ -1216,6 +1216,33 @@
 			#size-cells = <0>;
 		};
 
+		mali: gpu at 1c40000 {
+			compatible = "allwinner,sun8i-a23-mali",
+				     "allwinner,sun7i-a20-mali", "arm,mali-400";
+			reg = <0x01c40000 0x10000>;
+			interrupts = <GIC_SPI 69 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 70 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 71 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 74 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 75 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 73 IRQ_TYPE_LEVEL_HIGH>;
+			interrupt-names = "gp",
+					  "gpmmu",
+					  "pp0",
+					  "ppmmu0",
+					  "pp1",
+					  "ppmmu1",
+					  "pmu";
+			clocks = <&ccu CLK_AHB_GPU>, <&ccu CLK_GPU>;
+			clock-names = "bus", "core";
+			resets = <&ccu RST_GPU>;
+			#cooling-cells = <2>;
+
+			assigned-clocks = <&ccu CLK_GPU>;
+			assigned-clock-rates = <381000000>;
+		};
+
 		gmac: ethernet at 1c50000 {
 			compatible = "allwinner,sun7i-a20-gmac";
 			reg = <0x01c50000 0x10000>;
-- 
2.7.4

[PATCH 1/1] add mali r6p2 dt node

[Maxime Ripard]

On Tue, Nov 07, 2017 at 01:59:03PM +0100, Giulio Benetti wrote:
> It seems there is not mali node in sun7i-a20.dtsi
> 
> Add mali node to sun7i-a20.dtsi
> 
> This patch adds device tree mali node compatible with r6p2 utgard kernel driver 
> provided by ARM and patched by maxime ripard on his github.
> 
> It can be easily used in target.dts with:
> 
> &mali {
> 	status = "okay";
> }
> 
> then loading mali.ko in user space.

Can you please stop sending the same patch over and over again without
making any changes?

Thanks,
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20171107/69d494e8/attachment.sig>

[linux-sunxi] Cedrus driver

[Giulio Benetti]

Hi,

Il 16/11/2017 11:31, Andreas Baierl ha scritto:
> Am 16.11.2017 um 11:13 schrieb Giulio Benetti:
>> Hello,
>>
> Hello,
>> I'm wondering why cedrus 
>> https://github.com/FlorentRevest/linux-sunxi-cedrus has never been 
>> merged with linux-sunxi sunxi-next.
>>
> Because it is not ready to be merged. It depends on the v4l2 request 
> API, which was not merged and which is re-worked atm.
> Also, sunxi-cedrus itself is not in a finished state and is not as 
> feature-complete to be merged. Anyway it might be something for 
> staging... Has there been a [RFC] on the mailing list at all?

Where can I find a list of TODOs to get it ready to be merged?

>> I see it seems to be dead, no commit in 1 year.
> Yes, because the author did this during an internship, which ended ... 
> Afaik nobody picked up his work yet.
>> I would like to respawn it and contribute to sunxi-next,
> Feel free to work on it...

Hope to be able, but I'm going to try.

>> since we need video acceleration on A20 and A33.
>>
> ack.

By the way, when you answer to google group, is it right that all CC I 
inserted are not inserted too?
Because this causes mess with mailing lists (seems to me).

> 
> Regards
> rellla
>> Best regards
>>
> 


-- 
Giulio Benetti
R&D Manager &
Advanced Research

MICRONOVA SRL
Sede: Via A. Niedda 3 - 35010 Vigonza (PD)
Tel. 049/8931563 - Fax 049/8931346
Cod.Fiscale - P.IVA 02663420285
Capitale Sociale ? 26.000 i.v.
Iscritta al Reg. Imprese di Padova N. 02663420285
Numero R.E.A. 258642

[linux-sunxi] Cedrus driver

[Maxime Ripard]

Hi,

I'm not sure why there's so many recipients (Russell, Rob or Mark have
a limited interest in this I assume), and why you're also missing some
key ones (like the v4l2 list).

On Thu, Nov 16, 2017 at 11:37:30AM +0100, Giulio Benetti wrote:
> Il 16/11/2017 11:31, Andreas Baierl ha scritto:
> > Am 16.11.2017 um 11:13 schrieb Giulio Benetti:
> > > Hello,
> > > 
> > Hello,
> > > I'm wondering why cedrus
> > > https://github.com/FlorentRevest/linux-sunxi-cedrus has never been
> > > merged with linux-sunxi sunxi-next.
> > > 
> > Because it is not ready to be merged. It depends on the v4l2 request
> > API, which was not merged and which is re-worked atm.
> > Also, sunxi-cedrus itself is not in a finished state and is not as
> > feature-complete to be merged. Anyway it might be something for
> > staging... Has there been a [RFC] on the mailing list at all?
> 
> Where can I find a list of TODOs to get it ready to be merged?

Assuming that the request API is in, we'd need to:
  - Finish the MPEG4 support
  - Work on more useful codecs (H264 comes to my mind)
  - Implement the DRM planes support for the custom frame format
  - Implement the DRM planes support for scaling
  - Test it on more SoCs

Or something along those lines.

> > > I see it seems to be dead, no commit in 1 year.
> >
> > Yes, because the author did this during an internship, which ended ...
> > Afaik nobody picked up his work yet.

That's not entirely true. Some work has been done by Thomas (in CC),
especially on the display engine side, but last time we talked his
work was not really upstreamable.

We will also resume that effort starting next march.

> > > since we need video acceleration on A20 and A33.
> > > 
> > ack.
> 
> By the way, when you answer to google group, is it right that all CC I
> inserted are not inserted too?
> Because this causes mess with mailing lists (seems to me).

Yes, that's one of the many brain-damaged thing happening on that
list...

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20171116/fc3ef62c/attachment.sig>

[linux-sunxi] Cedrus driver

[Nicolas Dufresne]

Le jeudi 16 novembre 2017 ? 12:02 +0100, Maxime Ripard a ?crit :
> Assuming that the request API is in, we'd need to:
>   - Finish the MPEG4 support
>   - Work on more useful codecs (H264 comes to my mind)

For which we will have to review the tables and make sure they match
the spec (the easy part). But as an example, that branch uses a table
that merge Mpeg4 VOP and VOP Short Header. We need to make sure it does
not pause problems or split it up. On top of that, ST and Rockchip
teams should give some help and sync with these tables on their side.
We also need to consider decoder like Tegra 2. In H264, they don't need
frame parsing, but just the PPS/SPS data (might just be parsed in the
driver, like CODA ?). There is other mode of operation, specially in
H264/HEVC low latency, where the decoder will be similar, but will
accept and process slices right away, without waiting for the full
frame.

We also need some doc, to be able to tell the GStreamer and FFMPEG team
how to detect and handle these decoder. I doubt the libv4l2 proposed
approach will be used for these two projects since they already have
their own parser and would like to not parse twice. As an example, we
need to document that V4L2_PIX_FMT_MPEG2_FRAME implies using the
Request API and specific CID. We should probably also ping the Chrome
Devs, which probably have couple of pending branches around this.

regards,
Nicolas


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20171116/b9fdd8c2/attachment.sig>

[linux-sunxi] Cedrus driver

[Maxime Ripard]

Hi Nicolas,

On Thu, Nov 16, 2017 at 02:59:55PM -0500, Nicolas Dufresne wrote:
> Le jeudi 16 novembre 2017 ? 12:02 +0100, Maxime Ripard a ?crit :
> > Assuming that the request API is in, we'd need to:
> >   - Finish the MPEG4 support
> >   - Work on more useful codecs (H264 comes to my mind)
> 
> For which we will have to review the tables and make sure they match
> the spec (the easy part). But as an example, that branch uses a table
> that merge Mpeg4 VOP and VOP Short Header. We need to make sure it does
> not pause problems or split it up. On top of that, ST and Rockchip
> teams should give some help and sync with these tables on their side.
> We also need to consider decoder like Tegra 2. In H264, they don't need
> frame parsing, but just the PPS/SPS data (might just be parsed in the
> driver, like CODA ?). There is other mode of operation, specially in
> H264/HEVC low latency, where the decoder will be similar, but will
> accept and process slices right away, without waiting for the full
> frame.

Sorry if it's a dumb question, but what branches and tables are you
talking about here?

> We also need some doc, to be able to tell the GStreamer and FFMPEG team
> how to detect and handle these decoder. I doubt the libv4l2 proposed
> approach will be used for these two projects since they already have
> their own parser and would like to not parse twice. As an example, we
> need to document that V4L2_PIX_FMT_MPEG2_FRAME implies using the
> Request API and specific CID. We should probably also ping the Chrome
> Devs, which probably have couple of pending branches around this.

We've had a prototype that wasn't based on libv4l but was based on the
VA-API, and it's been working great for us so far.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20171117/0525b51f/attachment.sig>