* [PATCH 1/1] add mali r6p2 dt node
@ 2017-11-07 12:59 ` Giulio Benetti
0 siblings, 0 replies; 47+ messages in thread
From: Giulio Benetti @ 2017-11-07 12:59 UTC (permalink / raw)
To: robh+dt
Cc: mark.rutland, linux, maxime.ripard, wens, devicetree,
linux-arm-kernel, linux-kernel, linux-sunxi, 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@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@1c50000 {
compatible = "allwinner,sun7i-a20-gmac";
reg = <0x01c50000 0x10000>;
--
2.7.4
^ permalink raw reply related [flat|nested] 47+ messages in thread* [PATCH 1/1] add mali r6p2 dt node @ 2017-11-07 12:59 ` Giulio Benetti 0 siblings, 0 replies; 47+ messages in thread From: Giulio Benetti @ 2017-11-07 12:59 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply related [flat|nested] 47+ messages in thread
* [PATCH 1/1] add mali r6p2 dt node @ 2017-11-07 12:59 ` Giulio Benetti 0 siblings, 0 replies; 47+ messages in thread From: Giulio Benetti @ 2017-11-07 12:59 UTC (permalink / raw) To: robh+dt-DgEjT+Ai2ygdnm+yROfE0A Cc: mark.rutland-5wv7dgnIgG8, linux-I+IVW8TIWO2tmTQ+vhA3Yw, maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8, wens-jdAy2FN1RRM, devicetree-u79uwXL29TY76Z2rM5mHXA, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, linux-kernel-u79uwXL29TY76Z2rM5mHXA, linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, 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-W14uJ/fiAyBY2hyreNRi6g@public.gmane.org> --- 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@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@1c50000 { compatible = "allwinner,sun7i-a20-gmac"; reg = <0x01c50000 0x10000>; -- 2.7.4 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply related [flat|nested] 47+ messages in thread
* Re: [PATCH 1/1] add mali r6p2 dt node 2017-11-07 12:59 ` Giulio Benetti @ 2017-11-07 13:02 ` Maxime Ripard -1 siblings, 0 replies; 47+ messages in thread From: Maxime Ripard @ 2017-11-07 13:02 UTC (permalink / raw) To: Giulio Benetti Cc: robh+dt, mark.rutland, linux, wens, devicetree, linux-arm-kernel, linux-kernel, linux-sunxi [-- Attachment #1: Type: text/plain, Size: 659 bytes --] 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 [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 801 bytes --] ^ permalink raw reply [flat|nested] 47+ messages in thread
* [PATCH 1/1] add mali r6p2 dt node @ 2017-11-07 13:02 ` Maxime Ripard 0 siblings, 0 replies; 47+ messages in thread From: Maxime Ripard @ 2017-11-07 13:02 UTC (permalink / raw) To: linux-arm-kernel 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> ^ permalink raw reply [flat|nested] 47+ messages in thread
* Cedrus driver @ 2017-11-16 10:13 ` Giulio Benetti 0 siblings, 0 replies; 47+ messages in thread From: Giulio Benetti @ 2017-11-16 10:13 UTC (permalink / raw) To: robh+dt Cc: mark.rutland, linux, maxime.ripard, wens, devicetree, linux-arm-kernel, linux-kernel, linux-sunxi Hello, I'm wondering why cedrus https://github.com/FlorentRevest/linux-sunxi-cedrus has never been merged with linux-sunxi sunxi-next. I see it seems to be dead, no commit in 1 year. I would like to respawn it and contribute to sunxi-next, since we need video acceleration on A20 and A33. 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 ^ permalink raw reply [flat|nested] 47+ messages in thread
* Cedrus driver @ 2017-11-16 10:13 ` Giulio Benetti 0 siblings, 0 replies; 47+ messages in thread From: Giulio Benetti @ 2017-11-16 10:13 UTC (permalink / raw) To: robh+dt-DgEjT+Ai2ygdnm+yROfE0A Cc: mark.rutland-5wv7dgnIgG8, linux-I+IVW8TIWO2tmTQ+vhA3Yw, maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8, wens-jdAy2FN1RRM, devicetree-u79uwXL29TY76Z2rM5mHXA, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, linux-kernel-u79uwXL29TY76Z2rM5mHXA, linux-sunxi-/JYPxA39Uh5TLH3MbocFFw Hello, I'm wondering why cedrus https://github.com/FlorentRevest/linux-sunxi-cedrus has never been merged with linux-sunxi sunxi-next. I see it seems to be dead, no commit in 1 year. I would like to respawn it and contribute to sunxi-next, since we need video acceleration on A20 and A33. 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 -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit https://groups.google.com/d/optout. ^ permalink raw reply [flat|nested] 47+ messages in thread
[parent not found: <6fcdc0d9-d0f8-785a-bb00-b1b41c684e59@imkreisrum.de>]
* Re: [linux-sunxi] Cedrus driver @ 2017-11-16 10:37 ` Giulio Benetti 0 siblings, 0 replies; 47+ messages in thread From: Giulio Benetti @ 2017-11-16 10:37 UTC (permalink / raw) To: Andreas Baierl, linux-sunxi Cc: robh+dt, mark.rutland, linux, maxime.ripard, wens, devicetree, linux-arm-kernel, linux-kernel 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 ^ permalink raw reply [flat|nested] 47+ messages in thread
* [linux-sunxi] Cedrus driver @ 2017-11-16 10:37 ` Giulio Benetti 0 siblings, 0 replies; 47+ messages in thread From: Giulio Benetti @ 2017-11-16 10:37 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: Cedrus driver @ 2017-11-16 10:37 ` Giulio Benetti 0 siblings, 0 replies; 47+ messages in thread From: Giulio Benetti @ 2017-11-16 10:37 UTC (permalink / raw) To: Andreas Baierl, linux-sunxi-/JYPxA39Uh5TLH3MbocFFw Cc: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8, linux-I+IVW8TIWO2tmTQ+vhA3Yw, maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8, wens-jdAy2FN1RRM, devicetree-u79uwXL29TY76Z2rM5mHXA, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, linux-kernel-u79uwXL29TY76Z2rM5mHXA 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 -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit https://groups.google.com/d/optout. ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [linux-sunxi] Cedrus driver @ 2017-11-16 11:02 ` Maxime Ripard 0 siblings, 0 replies; 47+ messages in thread From: Maxime Ripard @ 2017-11-16 11:02 UTC (permalink / raw) To: Giulio Benetti Cc: Andreas Baierl, linux-sunxi, robh+dt, mark.rutland, linux, wens, devicetree, linux-arm-kernel, linux-kernel, thomas, linux-media [-- Attachment #1: Type: text/plain, Size: 2125 bytes --] 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 [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 801 bytes --] ^ permalink raw reply [flat|nested] 47+ messages in thread
* [linux-sunxi] Cedrus driver @ 2017-11-16 11:02 ` Maxime Ripard 0 siblings, 0 replies; 47+ messages in thread From: Maxime Ripard @ 2017-11-16 11:02 UTC (permalink / raw) To: linux-arm-kernel 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> ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [linux-sunxi] Cedrus driver @ 2017-11-16 11:02 ` Maxime Ripard 0 siblings, 0 replies; 47+ messages in thread From: Maxime Ripard @ 2017-11-16 11:02 UTC (permalink / raw) To: Giulio Benetti Cc: Andreas Baierl, linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8, linux-I+IVW8TIWO2tmTQ+vhA3Yw, wens-jdAy2FN1RRM, devicetree-u79uwXL29TY76Z2rM5mHXA, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, linux-kernel-u79uwXL29TY76Z2rM5mHXA, thomas-XCRq7eEM0/pmR6Xm/wNWPw, linux-media-u79uwXL29TY76Z2rM5mHXA [-- Attachment #1: Type: text/plain, Size: 2125 bytes --] 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 [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 801 bytes --] ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [linux-sunxi] Cedrus driver 2017-11-16 11:02 ` Maxime Ripard (?) (?) @ 2017-11-16 12:30 ` Giulio Benetti 2017-11-16 12:53 ` Maxime Ripard -1 siblings, 1 reply; 47+ messages in thread From: Giulio Benetti @ 2017-11-16 12:30 UTC (permalink / raw) To: Maxime Ripard Cc: Andreas Baierl, linux-sunxi, linux, wens, linux-kernel, thomas, linux-media Hi, Il 16/11/2017 12:02, Maxime Ripard ha scritto: > 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). added in cc linux-media mailing list that appears to be the right one for v4l2 and removed Russell, Rob and Mark > > 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. Lot of work to do > >>>> 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. Is it possible a preview on a separate Reporitory to start working on now? Expecially to start porting everything done by FlorentRevest to mainline, admitted you've not already done. > >>>> 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... Who can I ask to modify it? Most of all, is it possible? > > Maxime > -- 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 ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [linux-sunxi] Cedrus driver 2017-11-16 12:30 ` Giulio Benetti @ 2017-11-16 12:53 ` Maxime Ripard 2017-11-16 12:57 ` Giulio Benetti 0 siblings, 1 reply; 47+ messages in thread From: Maxime Ripard @ 2017-11-16 12:53 UTC (permalink / raw) To: Giulio Benetti Cc: Andreas Baierl, linux-sunxi, linux, wens, linux-kernel, thomas, linux-media [-- Attachment #1: Type: text/plain, Size: 2192 bytes --] On Thu, Nov 16, 2017 at 01:30:52PM +0100, Giulio Benetti wrote: > > 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. > > Lot of work to do Well... If it was fast and easy it would have been done already :) > > > > > 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. > > Is it possible a preview on a separate Reporitory to start working on now? > Expecially to start porting everything done by FlorentRevest to mainline, > admitted you've not already done. I'm not sure what you're asking for. Florent's work *was* on mainline. Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 801 bytes --] ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [linux-sunxi] Cedrus driver 2017-11-16 12:53 ` Maxime Ripard @ 2017-11-16 12:57 ` Giulio Benetti 2017-11-16 13:12 ` Hans Verkuil 0 siblings, 1 reply; 47+ messages in thread From: Giulio Benetti @ 2017-11-16 12:57 UTC (permalink / raw) To: Maxime Ripard Cc: Andreas Baierl, linux-sunxi, linux, wens, linux-kernel, thomas, linux-media Il 16/11/2017 13:53, Maxime Ripard ha scritto: > On Thu, Nov 16, 2017 at 01:30:52PM +0100, Giulio Benetti wrote: >>> 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. >> >> Lot of work to do > > Well... If it was fast and easy it would have been done already :) :)) > >>>>>> 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. >> >> Is it possible a preview on a separate Reporitory to start working on now? >> Expecially to start porting everything done by FlorentRevest to mainline, >> admitted you've not already done. > > I'm not sure what you're asking for. Florent's work *was* on mainline. and then they took it off because it was unmantained? You've spoken about Thomas(in CC) not ready, maybe I could help on that if it's public to accelerate. If I'm able to of course, this is my primary concern. Otherwise, in which way can I help improving it to make it accept to linux-sunxi? Starting from Florent's work and porting it to sunxi-next to begin? And after that adding all features you've listed? Tell me what I can do(I repeat, if I'm able to). > > Maxime > Thank you -- 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 ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [linux-sunxi] Cedrus driver 2017-11-16 12:57 ` Giulio Benetti @ 2017-11-16 13:12 ` Hans Verkuil 2017-11-16 13:17 ` Giulio Benetti 0 siblings, 1 reply; 47+ messages in thread From: Hans Verkuil @ 2017-11-16 13:12 UTC (permalink / raw) To: Giulio Benetti, Maxime Ripard Cc: Andreas Baierl, linux-sunxi, linux, wens, linux-kernel, thomas, linux-media On 16/11/17 13:57, Giulio Benetti wrote: > Il 16/11/2017 13:53, Maxime Ripard ha scritto: >> On Thu, Nov 16, 2017 at 01:30:52PM +0100, Giulio Benetti wrote: >>>> 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. >>> >>> Lot of work to do >> >> Well... If it was fast and easy it would have been done already :) > > :)) > >> >>>>>>> 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. >>> >>> Is it possible a preview on a separate Reporitory to start working on now? >>> Expecially to start porting everything done by FlorentRevest to mainline, >>> admitted you've not already done. >> >> I'm not sure what you're asking for. Florent's work *was* on mainline. > > and then they took it off because it was unmantained? > You've spoken about Thomas(in CC) not ready, > maybe I could help on that if it's public to accelerate. > If I'm able to of course, this is my primary concern. > > Otherwise, in which way can I help improving it to make it accept to linux-sunxi? > Starting from Florent's work and porting it to sunxi-next to begin? > And after that adding all features you've listed? > Tell me what I can do(I repeat, if I'm able to). The bottleneck is that the Request API is not mainlined. We restarted work on it after a meeting a few weeks back where we all agreed on the roadmap so hopefully it will go into mainline Q1 or Q2 next year. That said, you can use Florent's patch series for further development. It should be relatively easy to convert it to the final version of the Request API. Just note that the public API of the final Request API will be somewhat different from the old version Florent's patch series is using. Regards, Hans > >> >> Maxime >> > > Thank you > ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [linux-sunxi] Cedrus driver 2017-11-16 13:12 ` Hans Verkuil @ 2017-11-16 13:17 ` Giulio Benetti 2017-11-16 13:39 ` Maxime Ripard 2017-11-16 13:39 ` Hans Verkuil 0 siblings, 2 replies; 47+ messages in thread From: Giulio Benetti @ 2017-11-16 13:17 UTC (permalink / raw) To: Hans Verkuil, Maxime Ripard Cc: Andreas Baierl, linux-sunxi, linux, wens, linux-kernel, thomas, linux-media Hi Hans, Il 16/11/2017 14:12, Hans Verkuil ha scritto: > On 16/11/17 13:57, Giulio Benetti wrote: >> Il 16/11/2017 13:53, Maxime Ripard ha scritto: >>> On Thu, Nov 16, 2017 at 01:30:52PM +0100, Giulio Benetti wrote: >>>>> 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. >>>> >>>> Lot of work to do >>> >>> Well... If it was fast and easy it would have been done already :) >> >> :)) >> >>> >>>>>>>> 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. >>>> >>>> Is it possible a preview on a separate Reporitory to start working on now? >>>> Expecially to start porting everything done by FlorentRevest to mainline, >>>> admitted you've not already done. >>> >>> I'm not sure what you're asking for. Florent's work *was* on mainline. >> >> and then they took it off because it was unmantained? >> You've spoken about Thomas(in CC) not ready, >> maybe I could help on that if it's public to accelerate. >> If I'm able to of course, this is my primary concern. >> >> Otherwise, in which way can I help improving it to make it accept to linux-sunxi? >> Starting from Florent's work and porting it to sunxi-next to begin? >> And after that adding all features you've listed? >> Tell me what I can do(I repeat, if I'm able to). > > The bottleneck is that the Request API is not mainlined. We restarted work > on it after a meeting a few weeks back where we all agreed on the roadmap > so hopefully it will go into mainline Q1 or Q2 next year. > > That said, you can use Florent's patch series for further development. > It should be relatively easy to convert it to the final version of the > Request API. Just note that the public API of the final Request API will > be somewhat different from the old version Florent's patch series is using. So I'm going to try soon to : 1) adapt that patchset to sunxi-next 2) add A20 support 3) add A33 support 4) after mainlined APIs, merge Alright? Regards > > Regards, > > Hans > >> >>> >>> Maxime >>> >> >> Thank you >> > -- 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 ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [linux-sunxi] Cedrus driver 2017-11-16 13:17 ` Giulio Benetti @ 2017-11-16 13:39 ` Maxime Ripard 2017-11-16 13:42 ` Giulio Benetti 2017-11-16 13:39 ` Hans Verkuil 1 sibling, 1 reply; 47+ messages in thread From: Maxime Ripard @ 2017-11-16 13:39 UTC (permalink / raw) To: Giulio Benetti Cc: Hans Verkuil, Andreas Baierl, linux-sunxi, linux, wens, linux-kernel, thomas, linux-media [-- Attachment #1: Type: text/plain, Size: 4348 bytes --] On Thu, Nov 16, 2017 at 02:17:08PM +0100, Giulio Benetti wrote: > Hi Hans, > > Il 16/11/2017 14:12, Hans Verkuil ha scritto: > > On 16/11/17 13:57, Giulio Benetti wrote: > > > Il 16/11/2017 13:53, Maxime Ripard ha scritto: > > > > On Thu, Nov 16, 2017 at 01:30:52PM +0100, Giulio Benetti wrote: > > > > > > 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. > > > > > > > > > > Lot of work to do > > > > > > > > Well... If it was fast and easy it would have been done already :) > > > > > > :)) > > > > > > > > > > > > > > > > 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. > > > > > > > > > > Is it possible a preview on a separate Reporitory to start working on now? > > > > > Expecially to start porting everything done by FlorentRevest to mainline, > > > > > admitted you've not already done. > > > > > > > > I'm not sure what you're asking for. Florent's work *was* on mainline. > > > > > > and then they took it off because it was unmantained? > > > You've spoken about Thomas(in CC) not ready, > > > maybe I could help on that if it's public to accelerate. > > > If I'm able to of course, this is my primary concern. > > > > > > Otherwise, in which way can I help improving it to make it accept to linux-sunxi? > > > Starting from Florent's work and porting it to sunxi-next to begin? > > > And after that adding all features you've listed? > > > Tell me what I can do(I repeat, if I'm able to). > > > > The bottleneck is that the Request API is not mainlined. We restarted work > > on it after a meeting a few weeks back where we all agreed on the roadmap > > so hopefully it will go into mainline Q1 or Q2 next year. > > > > That said, you can use Florent's patch series for further development. > > It should be relatively easy to convert it to the final version of the > > Request API. Just note that the public API of the final Request API will > > be somewhat different from the old version Florent's patch series is using. > > So I'm going to try soon to : > 1) adapt that patchset to sunxi-next > 2) add A20 support > 3) add A33 support > 4) after mainlined APIs, merge That sounds good. Thomas already has the support for the A20, and as I was saying, there is someone that is going to work full time on this in a couple monthes on our side. I'll set up a git repo on github so that we can collaborate until the request API is ready. Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 801 bytes --] ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [linux-sunxi] Cedrus driver 2017-11-16 13:39 ` Maxime Ripard @ 2017-11-16 13:42 ` Giulio Benetti 2017-11-28 0:03 ` Giulio Benetti 0 siblings, 1 reply; 47+ messages in thread From: Giulio Benetti @ 2017-11-16 13:42 UTC (permalink / raw) To: Maxime Ripard Cc: Hans Verkuil, Andreas Baierl, linux-sunxi, linux, wens, linux-kernel, thomas, linux-media Hi, Il 16/11/2017 14:39, Maxime Ripard ha scritto: > On Thu, Nov 16, 2017 at 02:17:08PM +0100, Giulio Benetti wrote: >> Hi Hans, >> >> Il 16/11/2017 14:12, Hans Verkuil ha scritto: >>> On 16/11/17 13:57, Giulio Benetti wrote: >>>> Il 16/11/2017 13:53, Maxime Ripard ha scritto: >>>>> On Thu, Nov 16, 2017 at 01:30:52PM +0100, Giulio Benetti wrote: >>>>>>> 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. >>>>>> >>>>>> Lot of work to do >>>>> >>>>> Well... If it was fast and easy it would have been done already :) >>>> >>>> :)) >>>> >>>>> >>>>>>>>>> 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. >>>>>> >>>>>> Is it possible a preview on a separate Reporitory to start working on now? >>>>>> Expecially to start porting everything done by FlorentRevest to mainline, >>>>>> admitted you've not already done. >>>>> >>>>> I'm not sure what you're asking for. Florent's work *was* on mainline. >>>> >>>> and then they took it off because it was unmantained? >>>> You've spoken about Thomas(in CC) not ready, >>>> maybe I could help on that if it's public to accelerate. >>>> If I'm able to of course, this is my primary concern. >>>> >>>> Otherwise, in which way can I help improving it to make it accept to linux-sunxi? >>>> Starting from Florent's work and porting it to sunxi-next to begin? >>>> And after that adding all features you've listed? >>>> Tell me what I can do(I repeat, if I'm able to). >>> >>> The bottleneck is that the Request API is not mainlined. We restarted work >>> on it after a meeting a few weeks back where we all agreed on the roadmap >>> so hopefully it will go into mainline Q1 or Q2 next year. >>> >>> That said, you can use Florent's patch series for further development. >>> It should be relatively easy to convert it to the final version of the >>> Request API. Just note that the public API of the final Request API will >>> be somewhat different from the old version Florent's patch series is using. >> >> So I'm going to try soon to : >> 1) adapt that patchset to sunxi-next >> 2) add A20 support >> 3) add A33 support >> 4) after mainlined APIs, merge > > That sounds good. Thomas already has the support for the A20, and as I > was saying, there is someone that is going to work full time on this > in a couple monthes on our side. > > I'll set up a git repo on github so that we can collaborate until the > request API is ready. Great! Write me when you've got news. Thank you very much! > > Maxime > -- 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 ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [linux-sunxi] Cedrus driver 2017-11-16 13:42 ` Giulio Benetti @ 2017-11-28 0:03 ` Giulio Benetti 2017-11-28 8:35 ` Maxime Ripard 0 siblings, 1 reply; 47+ messages in thread From: Giulio Benetti @ 2017-11-28 0:03 UTC (permalink / raw) To: Maxime Ripard Cc: Hans Verkuil, Andreas Baierl, linux-sunxi, linux, wens, linux-kernel, thomas, linux-media Hi Maxime, Il 16/11/2017 14:42, Giulio Benetti ha scritto: > Hi, > > Il 16/11/2017 14:39, Maxime Ripard ha scritto: >> On Thu, Nov 16, 2017 at 02:17:08PM +0100, Giulio Benetti wrote: >>> Hi Hans, >>> >>> Il 16/11/2017 14:12, Hans Verkuil ha scritto: >>>> On 16/11/17 13:57, Giulio Benetti wrote: >>>>> Il 16/11/2017 13:53, Maxime Ripard ha scritto: >>>>>> On Thu, Nov 16, 2017 at 01:30:52PM +0100, Giulio Benetti wrote: >>>>>>>> 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. >>>>>>> >>>>>>> Lot of work to do >>>>>> >>>>>> Well... If it was fast and easy it would have been done already :) >>>>> >>>>> :)) >>>>> >>>>>> >>>>>>>>>>> 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. >>>>>>> >>>>>>> Is it possible a preview on a separate Reporitory to start >>>>>>> working on now? >>>>>>> Expecially to start porting everything done by FlorentRevest to >>>>>>> mainline, >>>>>>> admitted you've not already done. >>>>>> >>>>>> I'm not sure what you're asking for. Florent's work *was* on >>>>>> mainline. >>>>> >>>>> and then they took it off because it was unmantained? >>>>> You've spoken about Thomas(in CC) not ready, >>>>> maybe I could help on that if it's public to accelerate. >>>>> If I'm able to of course, this is my primary concern. >>>>> >>>>> Otherwise, in which way can I help improving it to make it accept >>>>> to linux-sunxi? >>>>> Starting from Florent's work and porting it to sunxi-next to begin? >>>>> And after that adding all features you've listed? >>>>> Tell me what I can do(I repeat, if I'm able to). >>>> >>>> The bottleneck is that the Request API is not mainlined. We >>>> restarted work >>>> on it after a meeting a few weeks back where we all agreed on the >>>> roadmap >>>> so hopefully it will go into mainline Q1 or Q2 next year. >>>> >>>> That said, you can use Florent's patch series for further development. >>>> It should be relatively easy to convert it to the final version of the >>>> Request API. Just note that the public API of the final Request API >>>> will >>>> be somewhat different from the old version Florent's patch series is >>>> using. >>> >>> So I'm going to try soon to : >>> 1) adapt that patchset to sunxi-next >>> 2) add A20 support >>> 3) add A33 support >>> 4) after mainlined APIs, merge >> >> That sounds good. Thomas already has the support for the A20, and as I >> was saying, there is someone that is going to work full time on this >> in a couple monthes on our side. >> >> I'll set up a git repo on github so that we can collaborate until the >> request API is ready. Any news about git repo? When do you plan to do it more or less? > > Great! > Write me when you've got news. > > Thank you very much! > >> >> Maxime >> > > -- 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 ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [linux-sunxi] Cedrus driver 2017-11-28 0:03 ` Giulio Benetti @ 2017-11-28 8:35 ` Maxime Ripard 2017-11-28 9:50 ` Giulio Benetti 0 siblings, 1 reply; 47+ messages in thread From: Maxime Ripard @ 2017-11-28 8:35 UTC (permalink / raw) To: Giulio Benetti Cc: Hans Verkuil, Andreas Baierl, linux-sunxi, linux, wens, linux-kernel, thomas, linux-media [-- Attachment #1: Type: text/plain, Size: 5578 bytes --] On Tue, Nov 28, 2017 at 01:03:59AM +0100, Giulio Benetti wrote: > Hi Maxime, > > Il 16/11/2017 14:42, Giulio Benetti ha scritto: > > Hi, > > > > Il 16/11/2017 14:39, Maxime Ripard ha scritto: > > > On Thu, Nov 16, 2017 at 02:17:08PM +0100, Giulio Benetti wrote: > > > > Hi Hans, > > > > > > > > Il 16/11/2017 14:12, Hans Verkuil ha scritto: > > > > > On 16/11/17 13:57, Giulio Benetti wrote: > > > > > > Il 16/11/2017 13:53, Maxime Ripard ha scritto: > > > > > > > On Thu, Nov 16, 2017 at 01:30:52PM +0100, Giulio Benetti wrote: > > > > > > > > > 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. > > > > > > > > > > > > > > > > Lot of work to do > > > > > > > > > > > > > > Well... If it was fast and easy it would have been done already :) > > > > > > > > > > > > :)) > > > > > > > > > > > > > > > > > > > > > > > > > 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. > > > > > > > > > > > > > > > > Is it possible a preview on a separate > > > > > > > > Reporitory to start working on now? > > > > > > > > Expecially to start porting everything done by > > > > > > > > FlorentRevest to mainline, > > > > > > > > admitted you've not already done. > > > > > > > > > > > > > > I'm not sure what you're asking for. Florent's work > > > > > > > *was* on mainline. > > > > > > > > > > > > and then they took it off because it was unmantained? > > > > > > You've spoken about Thomas(in CC) not ready, > > > > > > maybe I could help on that if it's public to accelerate. > > > > > > If I'm able to of course, this is my primary concern. > > > > > > > > > > > > Otherwise, in which way can I help improving it to make > > > > > > it accept to linux-sunxi? > > > > > > Starting from Florent's work and porting it to sunxi-next to begin? > > > > > > And after that adding all features you've listed? > > > > > > Tell me what I can do(I repeat, if I'm able to). > > > > > > > > > > The bottleneck is that the Request API is not mainlined. We > > > > > restarted work > > > > > on it after a meeting a few weeks back where we all agreed > > > > > on the roadmap > > > > > so hopefully it will go into mainline Q1 or Q2 next year. > > > > > > > > > > That said, you can use Florent's patch series for further development. > > > > > It should be relatively easy to convert it to the final version of the > > > > > Request API. Just note that the public API of the final > > > > > Request API will > > > > > be somewhat different from the old version Florent's patch > > > > > series is using. > > > > > > > > So I'm going to try soon to : > > > > 1) adapt that patchset to sunxi-next > > > > 2) add A20 support > > > > 3) add A33 support > > > > 4) after mainlined APIs, merge > > > > > > That sounds good. Thomas already has the support for the A20, and as I > > > was saying, there is someone that is going to work full time on this > > > in a couple monthes on our side. > > > > > > I'll set up a git repo on github so that we can collaborate until the > > > request API is ready. > > Any news about git repo? > When do you plan to do it more or less? I started to do it yesterday. https://github.com/free-electrons/linux-cedrus https://github.com/free-electrons/libva-cedrus Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [linux-sunxi] Cedrus driver 2017-11-28 8:35 ` Maxime Ripard @ 2017-11-28 9:50 ` Giulio Benetti 2017-11-28 11:20 ` Thomas van Kleef 0 siblings, 1 reply; 47+ messages in thread From: Giulio Benetti @ 2017-11-28 9:50 UTC (permalink / raw) To: Maxime Ripard Cc: Hans Verkuil, Andreas Baierl, linux-sunxi, linux, wens, linux-kernel, thomas, linux-media Hi Maxime, Il 28/11/2017 09:35, Maxime Ripard ha scritto: > On Tue, Nov 28, 2017 at 01:03:59AM +0100, Giulio Benetti wrote: >> Hi Maxime, >> >> Il 16/11/2017 14:42, Giulio Benetti ha scritto: >>> Hi, >>> >>> Il 16/11/2017 14:39, Maxime Ripard ha scritto: >>>> On Thu, Nov 16, 2017 at 02:17:08PM +0100, Giulio Benetti wrote: >>>>> Hi Hans, >>>>> >>>>> Il 16/11/2017 14:12, Hans Verkuil ha scritto: >>>>>> On 16/11/17 13:57, Giulio Benetti wrote: >>>>>>> Il 16/11/2017 13:53, Maxime Ripard ha scritto: >>>>>>>> On Thu, Nov 16, 2017 at 01:30:52PM +0100, Giulio Benetti wrote: >>>>>>>>>> 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. >>>>>>>>> >>>>>>>>> Lot of work to do >>>>>>>> >>>>>>>> Well... If it was fast and easy it would have been done already :) >>>>>>> >>>>>>> :)) >>>>>>> >>>>>>>> >>>>>>>>>>>>> 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. >>>>>>>>> >>>>>>>>> Is it possible a preview on a separate >>>>>>>>> Reporitory to start working on now? >>>>>>>>> Expecially to start porting everything done by >>>>>>>>> FlorentRevest to mainline, >>>>>>>>> admitted you've not already done. >>>>>>>> >>>>>>>> I'm not sure what you're asking for. Florent's work >>>>>>>> *was* on mainline. >>>>>>> >>>>>>> and then they took it off because it was unmantained? >>>>>>> You've spoken about Thomas(in CC) not ready, >>>>>>> maybe I could help on that if it's public to accelerate. >>>>>>> If I'm able to of course, this is my primary concern. >>>>>>> >>>>>>> Otherwise, in which way can I help improving it to make >>>>>>> it accept to linux-sunxi? >>>>>>> Starting from Florent's work and porting it to sunxi-next to begin? >>>>>>> And after that adding all features you've listed? >>>>>>> Tell me what I can do(I repeat, if I'm able to). >>>>>> >>>>>> The bottleneck is that the Request API is not mainlined. We >>>>>> restarted work >>>>>> on it after a meeting a few weeks back where we all agreed >>>>>> on the roadmap >>>>>> so hopefully it will go into mainline Q1 or Q2 next year. >>>>>> >>>>>> That said, you can use Florent's patch series for further development. >>>>>> It should be relatively easy to convert it to the final version of the >>>>>> Request API. Just note that the public API of the final >>>>>> Request API will >>>>>> be somewhat different from the old version Florent's patch >>>>>> series is using. >>>>> >>>>> So I'm going to try soon to : >>>>> 1) adapt that patchset to sunxi-next >>>>> 2) add A20 support >>>>> 3) add A33 support >>>>> 4) after mainlined APIs, merge >>>> >>>> That sounds good. Thomas already has the support for the A20, and as I >>>> was saying, there is someone that is going to work full time on this >>>> in a couple monthes on our side. >>>> >>>> I'll set up a git repo on github so that we can collaborate until the >>>> request API is ready. >> >> Any news about git repo? >> When do you plan to do it more or less? > > I started to do it yesterday. > > https://github.com/free-electrons/linux-cedrus > https://github.com/free-electrons/libva-cedrus Great, I'm cloning. 1st: have it working with A20 with kernel as is and libva as buildroot package 2nd: porting to sunxi-next branch of linux-sunxi and check libva if can work as is Thank you > > Maxime > -- 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 ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [linux-sunxi] Cedrus driver 2017-11-28 9:50 ` Giulio Benetti @ 2017-11-28 11:20 ` Thomas van Kleef 2017-11-28 11:26 ` Giulio Benetti 2017-11-28 12:26 ` Maxime Ripard 0 siblings, 2 replies; 47+ messages in thread From: Thomas van Kleef @ 2017-11-28 11:20 UTC (permalink / raw) To: Giulio Benetti, Maxime Ripard Cc: Hans Verkuil, Andreas Baierl, linux-sunxi, linux, wens, linux-kernel, linux-media On 28-11-17 10:50, Giulio Benetti wrote: > Hi Maxime, > > Il 28/11/2017 09:35, Maxime Ripard ha scritto: >> On Tue, Nov 28, 2017 at 01:03:59AM +0100, Giulio Benetti wrote: >>> Hi Maxime, >>> >>> Il 16/11/2017 14:42, Giulio Benetti ha scritto: >>>> Hi, >>>> >>>> Il 16/11/2017 14:39, Maxime Ripard ha scritto: >>>>> On Thu, Nov 16, 2017 at 02:17:08PM +0100, Giulio Benetti wrote: >>>>>> Hi Hans, >>>>>> >>>>>> Il 16/11/2017 14:12, Hans Verkuil ha scritto: >>>>>>> On 16/11/17 13:57, Giulio Benetti wrote: >>>>>>>> Il 16/11/2017 13:53, Maxime Ripard ha scritto: >>>>>>>>> On Thu, Nov 16, 2017 at 01:30:52PM +0100, Giulio Benetti wrote: >>>>>>>>>>> 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. >>>>>>>>>> >>>>>>>>>> Lot of work to do >>>>>>>>> >>>>>>>>> Well... If it was fast and easy it would have been done already :) >>>>>>>> >>>>>>>> :)) >>>>>>>> >>>>>>>>> >>>>>>>>>>>>>> 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. >>>>>>>>>> >>>>>>>>>> Is it possible a preview on a separate >>>>>>>>>> Reporitory to start working on now? >>>>>>>>>> Expecially to start porting everything done by >>>>>>>>>> FlorentRevest to mainline, >>>>>>>>>> admitted you've not already done. >>>>>>>>> >>>>>>>>> I'm not sure what you're asking for. Florent's work >>>>>>>>> *was* on mainline. >>>>>>>> >>>>>>>> and then they took it off because it was unmantained? >>>>>>>> You've spoken about Thomas(in CC) not ready, >>>>>>>> maybe I could help on that if it's public to accelerate. >>>>>>>> If I'm able to of course, this is my primary concern. >>>>>>>> >>>>>>>> Otherwise, in which way can I help improving it to make >>>>>>>> it accept to linux-sunxi? >>>>>>>> Starting from Florent's work and porting it to sunxi-next to begin? >>>>>>>> And after that adding all features you've listed? >>>>>>>> Tell me what I can do(I repeat, if I'm able to). >>>>>>> >>>>>>> The bottleneck is that the Request API is not mainlined. We >>>>>>> restarted work >>>>>>> on it after a meeting a few weeks back where we all agreed >>>>>>> on the roadmap >>>>>>> so hopefully it will go into mainline Q1 or Q2 next year. >>>>>>> >>>>>>> That said, you can use Florent's patch series for further development. >>>>>>> It should be relatively easy to convert it to the final version of the >>>>>>> Request API. Just note that the public API of the final >>>>>>> Request API will >>>>>>> be somewhat different from the old version Florent's patch >>>>>>> series is using. >>>>>> >>>>>> So I'm going to try soon to : >>>>>> 1) adapt that patchset to sunxi-next >>>>>> 2) add A20 support >>>>>> 3) add A33 support >>>>>> 4) after mainlined APIs, merge >>>>> >>>>> That sounds good. Thomas already has the support for the A20, and as I >>>>> was saying, there is someone that is going to work full time on this >>>>> in a couple monthes on our side. >>>>> >>>>> I'll set up a git repo on github so that we can collaborate until the >>>>> request API is ready. >>> >>> Any news about git repo? >>> When do you plan to do it more or less? >> >> I started to do it yesterday. >> >> https://github.com/free-electrons/linux-cedrus >> https://github.com/free-electrons/libva-cedrus > > Great, I'm cloning. > 1st: have it working with A20 with kernel as is and libva as buildroot package > 2nd: porting to sunxi-next branch of linux-sunxi and check libva if can work as is > > Thank you > So, I have been rebasing to 4.14.0 and have the cedrus driver working. I have pulled linux-mainline 4.14.0. Then pulled the requests2 branch from Hans Verkuil's media_tree. I have a patch available of the merge between these 2 branches. After this I pulled the sunxi-cedrus repository from Florent Revests github. I believe this one is the same as the ones you are cloning right now. I have merged this and have a patch available for this as well. So to summarize: o pulled linux 4.14 from: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git o pulled requests2 from: https://git.linuxtv.org/hverkuil/media_tree.git?h=requests2 will be replaced with the work, when it is done, in: https://git.linuxtv.org/hverkuil/media_tree.git?h=ctrl-req-v2 o pulled linux-sunxi-cedrus from: https://github.com/FlorentRevest/linux-sunxi-cedrus o merged and made patch between linux4.14 and requests2 o merged and made patch with linux-sunxi-cedrus o Verified that the video-engine is decofing mpeg-2 on the Allwinner A20. So maybe if someone is interested in this, I could place the patches somewhere? Just let me know. It would be nice to be able to play a file, so I would have to prepare our custom player and make a patch between the current sunxi-cedrus-drv-video and the one on https://github.com/FlorentRevest/sunxi-cedrus-drv-video. So I will start with this if there is any interest. Should I be working in sunxi-next I wonder? >> >> Maxime >> > > ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [linux-sunxi] Cedrus driver 2017-11-28 11:20 ` Thomas van Kleef @ 2017-11-28 11:26 ` Giulio Benetti 2017-11-28 11:29 ` Thomas van Kleef 2017-11-28 12:26 ` Maxime Ripard 1 sibling, 1 reply; 47+ messages in thread From: Giulio Benetti @ 2017-11-28 11:26 UTC (permalink / raw) To: Thomas van Kleef, Maxime Ripard Cc: Hans Verkuil, Andreas Baierl, linux-sunxi, linux, wens, linux-kernel, linux-media Hi Thomas, Il 28/11/2017 12:20, Thomas van Kleef ha scritto: > On 28-11-17 10:50, Giulio Benetti wrote: >> Hi Maxime, >> >> Il 28/11/2017 09:35, Maxime Ripard ha scritto: >>> On Tue, Nov 28, 2017 at 01:03:59AM +0100, Giulio Benetti wrote: >>>> Hi Maxime, >>>> >>>> Il 16/11/2017 14:42, Giulio Benetti ha scritto: >>>>> Hi, >>>>> >>>>> Il 16/11/2017 14:39, Maxime Ripard ha scritto: >>>>>> On Thu, Nov 16, 2017 at 02:17:08PM +0100, Giulio Benetti wrote: >>>>>>> Hi Hans, >>>>>>> >>>>>>> Il 16/11/2017 14:12, Hans Verkuil ha scritto: >>>>>>>> On 16/11/17 13:57, Giulio Benetti wrote: >>>>>>>>> Il 16/11/2017 13:53, Maxime Ripard ha scritto: >>>>>>>>>> On Thu, Nov 16, 2017 at 01:30:52PM +0100, Giulio Benetti wrote: >>>>>>>>>>>> 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. >>>>>>>>>>> >>>>>>>>>>> Lot of work to do >>>>>>>>>> >>>>>>>>>> Well... If it was fast and easy it would have been done already :) >>>>>>>>> >>>>>>>>> :)) >>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>>> 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. >>>>>>>>>>> >>>>>>>>>>> Is it possible a preview on a separate >>>>>>>>>>> Reporitory to start working on now? >>>>>>>>>>> Expecially to start porting everything done by >>>>>>>>>>> FlorentRevest to mainline, >>>>>>>>>>> admitted you've not already done. >>>>>>>>>> >>>>>>>>>> I'm not sure what you're asking for. Florent's work >>>>>>>>>> *was* on mainline. >>>>>>>>> >>>>>>>>> and then they took it off because it was unmantained? >>>>>>>>> You've spoken about Thomas(in CC) not ready, >>>>>>>>> maybe I could help on that if it's public to accelerate. >>>>>>>>> If I'm able to of course, this is my primary concern. >>>>>>>>> >>>>>>>>> Otherwise, in which way can I help improving it to make >>>>>>>>> it accept to linux-sunxi? >>>>>>>>> Starting from Florent's work and porting it to sunxi-next to begin? >>>>>>>>> And after that adding all features you've listed? >>>>>>>>> Tell me what I can do(I repeat, if I'm able to). >>>>>>>> >>>>>>>> The bottleneck is that the Request API is not mainlined. We >>>>>>>> restarted work >>>>>>>> on it after a meeting a few weeks back where we all agreed >>>>>>>> on the roadmap >>>>>>>> so hopefully it will go into mainline Q1 or Q2 next year. >>>>>>>> >>>>>>>> That said, you can use Florent's patch series for further development. >>>>>>>> It should be relatively easy to convert it to the final version of the >>>>>>>> Request API. Just note that the public API of the final >>>>>>>> Request API will >>>>>>>> be somewhat different from the old version Florent's patch >>>>>>>> series is using. >>>>>>> >>>>>>> So I'm going to try soon to : >>>>>>> 1) adapt that patchset to sunxi-next >>>>>>> 2) add A20 support >>>>>>> 3) add A33 support >>>>>>> 4) after mainlined APIs, merge >>>>>> >>>>>> That sounds good. Thomas already has the support for the A20, and as I >>>>>> was saying, there is someone that is going to work full time on this >>>>>> in a couple monthes on our side. >>>>>> >>>>>> I'll set up a git repo on github so that we can collaborate until the >>>>>> request API is ready. >>>> >>>> Any news about git repo? >>>> When do you plan to do it more or less? >>> >>> I started to do it yesterday. >>> >>> https://github.com/free-electrons/linux-cedrus >>> https://github.com/free-electrons/libva-cedrus >> >> Great, I'm cloning. >> 1st: have it working with A20 with kernel as is and libva as buildroot package >> 2nd: porting to sunxi-next branch of linux-sunxi and check libva if can work as is >> >> Thank you >> So, I have been rebasing to 4.14.0 and have the cedrus driver working. > I have pulled linux-mainline 4.14.0. Then pulled the requests2 branch from Hans > Verkuil's media_tree. I have a patch available of the merge between these 2 > branches. > After this I pulled the sunxi-cedrus repository from Florent Revests github. I > believe this one is the same as the ones you are cloning right now. > I have merged this and have a patch available for this as well. > > So to summarize: > o pulled linux 4.14 from: > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git > o pulled requests2 from: > https://git.linuxtv.org/hverkuil/media_tree.git?h=requests2 > will be replaced with the work, when it is done, in: > https://git.linuxtv.org/hverkuil/media_tree.git?h=ctrl-req-v2 > o pulled linux-sunxi-cedrus from: > https://github.com/FlorentRevest/linux-sunxi-cedrus > > o merged and made patch between linux4.14 and requests2 > o merged and made patch with linux-sunxi-cedrus > o Verified that the video-engine is decofing mpeg-2 on the Allwinner A20. > > So maybe if someone is interested in this, I could place the patches somewhere? > Just let me know. Sure it's interesting! You could setup your github repo with all you patches applied as commits, but I think you should work against linux-sunxi sunxi-next branch. > > It would be nice to be able to play a file, so I would have to prepare our > custom player and make a patch between the current sunxi-cedrus-drv-video and > the one on https://github.com/FlorentRevest/sunxi-cedrus-drv-video. > So I will start with this if there is any interest. I am interested for sure. > > Should I be working in sunxi-next I wonder? Yes, this is the best way, cedrus is very specific to sunxi. So before working on mainline, I think the best is to work un sunxi-next branch. Is it right Maxime? >>> >>> Maxime >>> >> >> -- 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 ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [linux-sunxi] Cedrus driver 2017-11-28 11:26 ` Giulio Benetti @ 2017-11-28 11:29 ` Thomas van Kleef 2017-11-28 11:54 ` Giulio Benetti 0 siblings, 1 reply; 47+ messages in thread From: Thomas van Kleef @ 2017-11-28 11:29 UTC (permalink / raw) To: Giulio Benetti, Maxime Ripard Cc: Hans Verkuil, Andreas Baierl, linux-sunxi, linux, wens, linux-kernel, linux-media Hi, On 28-11-17 12:26, Giulio Benetti wrote: > Hi Thomas, > > Il 28/11/2017 12:20, Thomas van Kleef ha scritto: >> On 28-11-17 10:50, Giulio Benetti wrote: >>> Hi Maxime, >>> >>> Il 28/11/2017 09:35, Maxime Ripard ha scritto: >>>> On Tue, Nov 28, 2017 at 01:03:59AM +0100, Giulio Benetti wrote: >>>>> Hi Maxime, >>>>> >>>>> Il 16/11/2017 14:42, Giulio Benetti ha scritto: >>>>>> Hi, >>>>>> >>>>>> Il 16/11/2017 14:39, Maxime Ripard ha scritto: >>>>>>> On Thu, Nov 16, 2017 at 02:17:08PM +0100, Giulio Benetti wrote: >>>>>>>> Hi Hans, >>>>>>>> >>>>>>>> Il 16/11/2017 14:12, Hans Verkuil ha scritto: >>>>>>>>> On 16/11/17 13:57, Giulio Benetti wrote: >>>>>>>>>> Il 16/11/2017 13:53, Maxime Ripard ha scritto: >>>>>>>>>>> On Thu, Nov 16, 2017 at 01:30:52PM +0100, Giulio Benetti wrote: >>>>>>>>>>>>> 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. >>>>>>>>>>>> >>>>>>>>>>>> Lot of work to do >>>>>>>>>>> >>>>>>>>>>> Well... If it was fast and easy it would have been done already :) >>>>>>>>>> >>>>>>>>>> :)) >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>>>>> 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. >>>>>>>>>>>> >>>>>>>>>>>> Is it possible a preview on a separate >>>>>>>>>>>> Reporitory to start working on now? >>>>>>>>>>>> Expecially to start porting everything done by >>>>>>>>>>>> FlorentRevest to mainline, >>>>>>>>>>>> admitted you've not already done. >>>>>>>>>>> >>>>>>>>>>> I'm not sure what you're asking for. Florent's work >>>>>>>>>>> *was* on mainline. >>>>>>>>>> >>>>>>>>>> and then they took it off because it was unmantained? >>>>>>>>>> You've spoken about Thomas(in CC) not ready, >>>>>>>>>> maybe I could help on that if it's public to accelerate. >>>>>>>>>> If I'm able to of course, this is my primary concern. >>>>>>>>>> >>>>>>>>>> Otherwise, in which way can I help improving it to make >>>>>>>>>> it accept to linux-sunxi? >>>>>>>>>> Starting from Florent's work and porting it to sunxi-next to begin? >>>>>>>>>> And after that adding all features you've listed? >>>>>>>>>> Tell me what I can do(I repeat, if I'm able to). >>>>>>>>> >>>>>>>>> The bottleneck is that the Request API is not mainlined. We >>>>>>>>> restarted work >>>>>>>>> on it after a meeting a few weeks back where we all agreed >>>>>>>>> on the roadmap >>>>>>>>> so hopefully it will go into mainline Q1 or Q2 next year. >>>>>>>>> >>>>>>>>> That said, you can use Florent's patch series for further development. >>>>>>>>> It should be relatively easy to convert it to the final version of the >>>>>>>>> Request API. Just note that the public API of the final >>>>>>>>> Request API will >>>>>>>>> be somewhat different from the old version Florent's patch >>>>>>>>> series is using. >>>>>>>> >>>>>>>> So I'm going to try soon to : >>>>>>>> 1) adapt that patchset to sunxi-next >>>>>>>> 2) add A20 support >>>>>>>> 3) add A33 support >>>>>>>> 4) after mainlined APIs, merge >>>>>>> >>>>>>> That sounds good. Thomas already has the support for the A20, and as I >>>>>>> was saying, there is someone that is going to work full time on this >>>>>>> in a couple monthes on our side. >>>>>>> >>>>>>> I'll set up a git repo on github so that we can collaborate until the >>>>>>> request API is ready. >>>>> >>>>> Any news about git repo? >>>>> When do you plan to do it more or less? >>>> >>>> I started to do it yesterday. >>>> >>>> https://github.com/free-electrons/linux-cedrus >>>> https://github.com/free-electrons/libva-cedrus >>> >>> Great, I'm cloning. >>> 1st: have it working with A20 with kernel as is and libva as buildroot package >>> 2nd: porting to sunxi-next branch of linux-sunxi and check libva if can work as is >>> >>> Thank you >>> So, I have been rebasing to 4.14.0 and have the cedrus driver working. >> I have pulled linux-mainline 4.14.0. Then pulled the requests2 branch from Hans >> Verkuil's media_tree. I have a patch available of the merge between these 2 >> branches. >> After this I pulled the sunxi-cedrus repository from Florent Revests github. I >> believe this one is the same as the ones you are cloning right now. >> I have merged this and have a patch available for this as well. >> >> So to summarize: >> o pulled linux 4.14 from: >> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git >> o pulled requests2 from: >> https://git.linuxtv.org/hverkuil/media_tree.git?h=requests2 >> will be replaced with the work, when it is done, in: >> https://git.linuxtv.org/hverkuil/media_tree.git?h=ctrl-req-v2 >> o pulled linux-sunxi-cedrus from: >> https://github.com/FlorentRevest/linux-sunxi-cedrus >> >> o merged and made patch between linux4.14 and requests2 >> o merged and made patch with linux-sunxi-cedrus >> o Verified that the video-engine is decofing mpeg-2 on the Allwinner A20. >> >> So maybe if someone is interested in this, I could place the patches somewhere? >> Just let me know. > > Sure it's interesting! > You could setup your github repo with all you patches applied as commits, but I think you should work against linux-sunxi sunxi-next branch. > >> >> It would be nice to be able to play a file, so I would have to prepare our >> custom player and make a patch between the current sunxi-cedrus-drv-video and >> the one on https://github.com/FlorentRevest/sunxi-cedrus-drv-video. >> So I will start with this if there is any interest. > > I am interested for sure. > >> >> Should I be working in sunxi-next I wonder? > > Yes, this is the best way, cedrus is very specific to sunxi. > So before working on mainline, I think the best is to work un sunxi-next branch. Is the requests2 api in sunxi-next? > > Is it right Maxime? > >>>> >>>> Maxime >>>> >>> >>> > > Thomas ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [linux-sunxi] Cedrus driver 2017-11-28 11:29 ` Thomas van Kleef @ 2017-11-28 11:54 ` Giulio Benetti 2017-11-28 12:31 ` Thomas van Kleef 2017-11-28 12:52 ` Maxime Ripard 0 siblings, 2 replies; 47+ messages in thread From: Giulio Benetti @ 2017-11-28 11:54 UTC (permalink / raw) To: Thomas van Kleef, Maxime Ripard Cc: Hans Verkuil, Andreas Baierl, linux-sunxi, linux, wens, linux-kernel, linux-media Hi Thomas, Il 28/11/2017 12:29, Thomas van Kleef ha scritto: > Hi, > > On 28-11-17 12:26, Giulio Benetti wrote: >> Hi Thomas, >> >> Il 28/11/2017 12:20, Thomas van Kleef ha scritto: >>> On 28-11-17 10:50, Giulio Benetti wrote: >>>> Hi Maxime, >>>> >>>> Il 28/11/2017 09:35, Maxime Ripard ha scritto: >>>>> On Tue, Nov 28, 2017 at 01:03:59AM +0100, Giulio Benetti wrote: >>>>>> Hi Maxime, >>>>>> >>>>>> Il 16/11/2017 14:42, Giulio Benetti ha scritto: >>>>>>> Hi, >>>>>>> >>>>>>> Il 16/11/2017 14:39, Maxime Ripard ha scritto: >>>>>>>> On Thu, Nov 16, 2017 at 02:17:08PM +0100, Giulio Benetti wrote: >>>>>>>>> Hi Hans, >>>>>>>>> >>>>>>>>> Il 16/11/2017 14:12, Hans Verkuil ha scritto: >>>>>>>>>> On 16/11/17 13:57, Giulio Benetti wrote: >>>>>>>>>>> Il 16/11/2017 13:53, Maxime Ripard ha scritto: >>>>>>>>>>>> On Thu, Nov 16, 2017 at 01:30:52PM +0100, Giulio Benetti wrote: >>>>>>>>>>>>>> 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. >>>>>>>>>>>>> >>>>>>>>>>>>> Lot of work to do >>>>>>>>>>>> >>>>>>>>>>>> Well... If it was fast and easy it would have been done already :) >>>>>>>>>>> >>>>>>>>>>> :)) >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>>>>> 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. >>>>>>>>>>>>> >>>>>>>>>>>>> Is it possible a preview on a separate >>>>>>>>>>>>> Reporitory to start working on now? >>>>>>>>>>>>> Expecially to start porting everything done by >>>>>>>>>>>>> FlorentRevest to mainline, >>>>>>>>>>>>> admitted you've not already done. >>>>>>>>>>>> >>>>>>>>>>>> I'm not sure what you're asking for. Florent's work >>>>>>>>>>>> *was* on mainline. >>>>>>>>>>> >>>>>>>>>>> and then they took it off because it was unmantained? >>>>>>>>>>> You've spoken about Thomas(in CC) not ready, >>>>>>>>>>> maybe I could help on that if it's public to accelerate. >>>>>>>>>>> If I'm able to of course, this is my primary concern. >>>>>>>>>>> >>>>>>>>>>> Otherwise, in which way can I help improving it to make >>>>>>>>>>> it accept to linux-sunxi? >>>>>>>>>>> Starting from Florent's work and porting it to sunxi-next to begin? >>>>>>>>>>> And after that adding all features you've listed? >>>>>>>>>>> Tell me what I can do(I repeat, if I'm able to). >>>>>>>>>> >>>>>>>>>> The bottleneck is that the Request API is not mainlined. We >>>>>>>>>> restarted work >>>>>>>>>> on it after a meeting a few weeks back where we all agreed >>>>>>>>>> on the roadmap >>>>>>>>>> so hopefully it will go into mainline Q1 or Q2 next year. >>>>>>>>>> >>>>>>>>>> That said, you can use Florent's patch series for further development. >>>>>>>>>> It should be relatively easy to convert it to the final version of the >>>>>>>>>> Request API. Just note that the public API of the final >>>>>>>>>> Request API will >>>>>>>>>> be somewhat different from the old version Florent's patch >>>>>>>>>> series is using. >>>>>>>>> >>>>>>>>> So I'm going to try soon to : >>>>>>>>> 1) adapt that patchset to sunxi-next >>>>>>>>> 2) add A20 support >>>>>>>>> 3) add A33 support >>>>>>>>> 4) after mainlined APIs, merge >>>>>>>> >>>>>>>> That sounds good. Thomas already has the support for the A20, and as I >>>>>>>> was saying, there is someone that is going to work full time on this >>>>>>>> in a couple monthes on our side. >>>>>>>> >>>>>>>> I'll set up a git repo on github so that we can collaborate until the >>>>>>>> request API is ready. >>>>>> >>>>>> Any news about git repo? >>>>>> When do you plan to do it more or less? >>>>> >>>>> I started to do it yesterday. >>>>> >>>>> https://github.com/free-electrons/linux-cedrus >>>>> https://github.com/free-electrons/libva-cedrus >>>> >>>> Great, I'm cloning. >>>> 1st: have it working with A20 with kernel as is and libva as buildroot package >>>> 2nd: porting to sunxi-next branch of linux-sunxi and check libva if can work as is >>>> >>>> Thank you >>>> So, I have been rebasing to 4.14.0 and have the cedrus driver working. >>> I have pulled linux-mainline 4.14.0. Then pulled the requests2 branch from Hans >>> Verkuil's media_tree. I have a patch available of the merge between these 2 >>> branches. >>> After this I pulled the sunxi-cedrus repository from Florent Revests github. I >>> believe this one is the same as the ones you are cloning right now. >>> I have merged this and have a patch available for this as well. >>> >>> So to summarize: >>> o pulled linux 4.14 from: >>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git >>> o pulled requests2 from: >>> https://git.linuxtv.org/hverkuil/media_tree.git?h=requests2 >>> will be replaced with the work, when it is done, in: >>> https://git.linuxtv.org/hverkuil/media_tree.git?h=ctrl-req-v2 >>> o pulled linux-sunxi-cedrus from: >>> https://github.com/FlorentRevest/linux-sunxi-cedrus >>> >>> o merged and made patch between linux4.14 and requests2 >>> o merged and made patch with linux-sunxi-cedrus >>> o Verified that the video-engine is decofing mpeg-2 on the Allwinner A20. >>> >>> So maybe if someone is interested in this, I could place the patches somewhere? >>> Just let me know. >> >> Sure it's interesting! >> You could setup your github repo with all you patches applied as commits, but I think you should work against linux-sunxi sunxi-next branch. >> >>> >>> It would be nice to be able to play a file, so I would have to prepare our >>> custom player and make a patch between the current sunxi-cedrus-drv-video and >>> the one on https://github.com/FlorentRevest/sunxi-cedrus-drv-video. >>> So I will start with this if there is any interest. >> >> I am interested for sure. >> >>> >>> Should I be working in sunxi-next I wonder? >> >> Yes, this is the best way, cedrus is very specific to sunxi. >> So before working on mainline, I think the best is to work un sunxi-next branch. > Is the requests2 api in sunxi-next? It should be there, take a look at latest commit of yesterday: https://github.com/linux-sunxi/linux-sunxi/commit/df7cacd062cd84c551d7e72f15b1af6d71abc198 >> >> Is it right Maxime? >> >>>>> >>>>> Maxime >>>>> >>>> >>>> >> >> > Thomas > -- 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 ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [linux-sunxi] Cedrus driver 2017-11-28 11:54 ` Giulio Benetti @ 2017-11-28 12:31 ` Thomas van Kleef 2017-11-28 12:52 ` Maxime Ripard 1 sibling, 0 replies; 47+ messages in thread From: Thomas van Kleef @ 2017-11-28 12:31 UTC (permalink / raw) To: Giulio Benetti, Maxime Ripard Cc: Hans Verkuil, Andreas Baierl, linux-sunxi, linux, wens, linux-kernel, linux-media Hi Giulio On 28-11-17 12:54, Giulio Benetti wrote: > Hi Thomas, > > Il 28/11/2017 12:29, Thomas van Kleef ha scritto: >> Hi, >> >> On 28-11-17 12:26, Giulio Benetti wrote: >>> Hi Thomas, >>> >>> Il 28/11/2017 12:20, Thomas van Kleef ha scritto: >>>> On 28-11-17 10:50, Giulio Benetti wrote: >>>>> Hi Maxime, >>>>> >>>>> Il 28/11/2017 09:35, Maxime Ripard ha scritto: >>>>>> On Tue, Nov 28, 2017 at 01:03:59AM +0100, Giulio Benetti wrote: >>>>>>> Hi Maxime, >>>>>>> >>>>>>> Il 16/11/2017 14:42, Giulio Benetti ha scritto: >>>>>>>> Hi, >>>>>>>> >>>>>>>> Il 16/11/2017 14:39, Maxime Ripard ha scritto: >>>>>>>>> On Thu, Nov 16, 2017 at 02:17:08PM +0100, Giulio Benetti wrote: >>>>>>>>>> Hi Hans, >>>>>>>>>> >>>>>>>>>> Il 16/11/2017 14:12, Hans Verkuil ha scritto: >>>>>>>>>>> On 16/11/17 13:57, Giulio Benetti wrote: >>>>>>>>>>>> Il 16/11/2017 13:53, Maxime Ripard ha scritto: >>>>>>>>>>>>> On Thu, Nov 16, 2017 at 01:30:52PM +0100, Giulio Benetti wrote: >>>>>>>>>>>>>>> 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. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Lot of work to do >>>>>>>>>>>>> >>>>>>>>>>>>> Well... If it was fast and easy it would have been done already :) >>>>>>>>>>>> >>>>>>>>>>>> :)) >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> 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. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Is it possible a preview on a separate >>>>>>>>>>>>>> Reporitory to start working on now? >>>>>>>>>>>>>> Expecially to start porting everything done by >>>>>>>>>>>>>> FlorentRevest to mainline, >>>>>>>>>>>>>> admitted you've not already done. >>>>>>>>>>>>> >>>>>>>>>>>>> I'm not sure what you're asking for. Florent's work >>>>>>>>>>>>> *was* on mainline. >>>>>>>>>>>> >>>>>>>>>>>> and then they took it off because it was unmantained? >>>>>>>>>>>> You've spoken about Thomas(in CC) not ready, >>>>>>>>>>>> maybe I could help on that if it's public to accelerate. >>>>>>>>>>>> If I'm able to of course, this is my primary concern. >>>>>>>>>>>> >>>>>>>>>>>> Otherwise, in which way can I help improving it to make >>>>>>>>>>>> it accept to linux-sunxi? >>>>>>>>>>>> Starting from Florent's work and porting it to sunxi-next to begin? >>>>>>>>>>>> And after that adding all features you've listed? >>>>>>>>>>>> Tell me what I can do(I repeat, if I'm able to). >>>>>>>>>>> >>>>>>>>>>> The bottleneck is that the Request API is not mainlined. We >>>>>>>>>>> restarted work >>>>>>>>>>> on it after a meeting a few weeks back where we all agreed >>>>>>>>>>> on the roadmap >>>>>>>>>>> so hopefully it will go into mainline Q1 or Q2 next year. >>>>>>>>>>> >>>>>>>>>>> That said, you can use Florent's patch series for further development. >>>>>>>>>>> It should be relatively easy to convert it to the final version of the >>>>>>>>>>> Request API. Just note that the public API of the final >>>>>>>>>>> Request API will >>>>>>>>>>> be somewhat different from the old version Florent's patch >>>>>>>>>>> series is using. >>>>>>>>>> >>>>>>>>>> So I'm going to try soon to : >>>>>>>>>> 1) adapt that patchset to sunxi-next >>>>>>>>>> 2) add A20 support >>>>>>>>>> 3) add A33 support >>>>>>>>>> 4) after mainlined APIs, merge >>>>>>>>> >>>>>>>>> That sounds good. Thomas already has the support for the A20, and as I >>>>>>>>> was saying, there is someone that is going to work full time on this >>>>>>>>> in a couple monthes on our side. >>>>>>>>> >>>>>>>>> I'll set up a git repo on github so that we can collaborate until the >>>>>>>>> request API is ready. >>>>>>> >>>>>>> Any news about git repo? >>>>>>> When do you plan to do it more or less? >>>>>> >>>>>> I started to do it yesterday. >>>>>> >>>>>> https://github.com/free-electrons/linux-cedrus >>>>>> https://github.com/free-electrons/libva-cedrus >>>>> >>>>> Great, I'm cloning. >>>>> 1st: have it working with A20 with kernel as is and libva as buildroot package >>>>> 2nd: porting to sunxi-next branch of linux-sunxi and check libva if can work as is >>>>> >>>>> Thank you >>>>> So, I have been rebasing to 4.14.0 and have the cedrus driver working. >>>> I have pulled linux-mainline 4.14.0. Then pulled the requests2 branch from Hans >>>> Verkuil's media_tree. I have a patch available of the merge between these 2 >>>> branches. >>>> After this I pulled the sunxi-cedrus repository from Florent Revests github. I >>>> believe this one is the same as the ones you are cloning right now. >>>> I have merged this and have a patch available for this as well. >>>> >>>> So to summarize: >>>> o pulled linux 4.14 from: >>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git >>>> o pulled requests2 from: >>>> https://git.linuxtv.org/hverkuil/media_tree.git?h=requests2 >>>> will be replaced with the work, when it is done, in: >>>> https://git.linuxtv.org/hverkuil/media_tree.git?h=ctrl-req-v2 >>>> o pulled linux-sunxi-cedrus from: >>>> https://github.com/FlorentRevest/linux-sunxi-cedrus >>>> >>>> o merged and made patch between linux4.14 and requests2 >>>> o merged and made patch with linux-sunxi-cedrus >>>> o Verified that the video-engine is decofing mpeg-2 on the Allwinner A20. >>>> >>>> So maybe if someone is interested in this, I could place the patches somewhere? >>>> Just let me know. >>> >>> Sure it's interesting! >>> You could setup your github repo with all you patches applied as commits, but I think you should work against linux-sunxi sunxi-next branch. >>> Hope this helps. https://github.com/thomas-vitsch/linux-a20-cedrus >>>> >>>> It would be nice to be able to play a file, so I would have to prepare our >>>> custom player and make a patch between the current sunxi-cedrus-drv-video and >>>> the one on https://github.com/FlorentRevest/sunxi-cedrus-drv-video. >>>> So I will start with this if there is any interest. >>> >>> I am interested for sure. >>> >>>> >>>> Should I be working in sunxi-next I wonder? >>> >>> Yes, this is the best way, cedrus is very specific to sunxi. >>> So before working on mainline, I think the best is to work un sunxi-next branch. >> Is the requests2 api in sunxi-next? > > It should be there, > take a look at latest commit of yesterday: > https://github.com/linux-sunxi/linux-sunxi/commit/df7cacd062cd84c551d7e72f15b1af6d71abc198 > Thank you for the info. I will start working in the sunxi-next branch soon then. >>> >>> Is it right Maxime? >>> >>>>>> >>>>>> Maxime >>>>>> >>>>> >>>>> >>> >>> >> Thomas >> > > Thomas van Kleef Vitsch Electronics http://Vitsch.nl/ http://VitschVPN.nl/ tel: +31-(0)40-7113051 KvK nr: 17174380 BTW nr: NL142748201B01 -- Machines en netwerken op afstand beheren? Vitsch VPN oplossing! Kijk voor meer informatie op: http://www.VitschVPN.nl/ ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [linux-sunxi] Cedrus driver 2017-11-28 11:54 ` Giulio Benetti 2017-11-28 12:31 ` Thomas van Kleef @ 2017-11-28 12:52 ` Maxime Ripard 2017-11-28 13:03 ` Giulio Benetti 1 sibling, 1 reply; 47+ messages in thread From: Maxime Ripard @ 2017-11-28 12:52 UTC (permalink / raw) To: Giulio Benetti Cc: Thomas van Kleef, Hans Verkuil, Andreas Baierl, linux-sunxi, linux, wens, linux-kernel, linux-media [-- Attachment #1: Type: text/plain, Size: 958 bytes --] On Tue, Nov 28, 2017 at 12:54:08PM +0100, Giulio Benetti wrote: > > > > Should I be working in sunxi-next I wonder? > > > > > > Yes, this is the best way, cedrus is very specific to sunxi. > > > So before working on mainline, I think the best is to work un sunxi-next branch. > > > > Is the requests2 api in sunxi-next? > > It should be there, > take a look at latest commit of yesterday: > https://github.com/linux-sunxi/linux-sunxi/commit/df7cacd062cd84c551d7e72f15b1af6d71abc198 No, it shouldn't. sunxi-next is about patches that are related to sunxi that have been accepted in their respective maintainers' branches. While we could argue about the first criteria, the second one is not respected. And really, just develop against 4.14. sunxi-next is rebased, and it's just not something you can base some work on. Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [linux-sunxi] Cedrus driver 2017-11-28 12:52 ` Maxime Ripard @ 2017-11-28 13:03 ` Giulio Benetti 2017-11-28 13:07 ` Maxime Ripard 0 siblings, 1 reply; 47+ messages in thread From: Giulio Benetti @ 2017-11-28 13:03 UTC (permalink / raw) To: Maxime Ripard Cc: Thomas van Kleef, Hans Verkuil, Andreas Baierl, linux-sunxi, linux, wens, linux-kernel, linux-media Hi, > Il giorno 28 nov 2017, alle ore 13:52, Maxime Ripard <maxime.ripard@free-electrons.com> ha scritto: > > On Tue, Nov 28, 2017 at 12:54:08PM +0100, Giulio Benetti wrote: >>>>> Should I be working in sunxi-next I wonder? >>>> >>>> Yes, this is the best way, cedrus is very specific to sunxi. >>>> So before working on mainline, I think the best is to work un sunxi-next branch. >>> >>> Is the requests2 api in sunxi-next? >> >> It should be there, >> take a look at latest commit of yesterday: >> https://github.com/linux-sunxi/linux-sunxi/commit/df7cacd062cd84c551d7e72f15b1af6d71abc198 > > No, it shouldn't. sunxi-next is about patches that are related to > sunxi that have been accepted in their respective maintainers' > branches. > > While we could argue about the first criteria, the second one is not > respected. > > And really, just develop against 4.14. sunxi-next is rebased, and it's > just not something you can base some work on. Where do we can work on then? Should Thomas setup his own github repo? What about the one you’ve set up @free-electrons? > > Maxime > > -- > Maxime Ripard, Free Electrons > Embedded Linux and Kernel engineering > http://free-electrons.com ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [linux-sunxi] Cedrus driver 2017-11-28 13:03 ` Giulio Benetti @ 2017-11-28 13:07 ` Maxime Ripard 2017-11-28 13:12 ` Giulio Benetti 0 siblings, 1 reply; 47+ messages in thread From: Maxime Ripard @ 2017-11-28 13:07 UTC (permalink / raw) To: Giulio Benetti Cc: Thomas van Kleef, Hans Verkuil, Andreas Baierl, linux-sunxi, linux, wens, linux-kernel, linux-media [-- Attachment #1: Type: text/plain, Size: 1409 bytes --] On Tue, Nov 28, 2017 at 02:03:43PM +0100, Giulio Benetti wrote: > Hi, > > > Il giorno 28 nov 2017, alle ore 13:52, Maxime Ripard <maxime.ripard@free-electrons.com> ha scritto: > > > > On Tue, Nov 28, 2017 at 12:54:08PM +0100, Giulio Benetti wrote: > >>>>> Should I be working in sunxi-next I wonder? > >>>> > >>>> Yes, this is the best way, cedrus is very specific to sunxi. > >>>> So before working on mainline, I think the best is to work un sunxi-next branch. > >>> > >>> Is the requests2 api in sunxi-next? > >> > >> It should be there, > >> take a look at latest commit of yesterday: > >> https://github.com/linux-sunxi/linux-sunxi/commit/df7cacd062cd84c551d7e72f15b1af6d71abc198 > > > > No, it shouldn't. sunxi-next is about patches that are related to > > sunxi that have been accepted in their respective maintainers' > > branches. > > > > While we could argue about the first criteria, the second one is not > > respected. > > > > And really, just develop against 4.14. sunxi-next is rebased, and it's > > just not something you can base some work on. > > Where do we can work on then? > Should Thomas setup his own github repo? > What about the one you’ve set up @free-electrons? I already said that, please make pull requests to that repo. Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [linux-sunxi] Cedrus driver 2017-11-28 13:07 ` Maxime Ripard @ 2017-11-28 13:12 ` Giulio Benetti 2017-11-28 15:17 ` Maxime Ripard 0 siblings, 1 reply; 47+ messages in thread From: Giulio Benetti @ 2017-11-28 13:12 UTC (permalink / raw) To: Maxime Ripard Cc: Thomas van Kleef, Hans Verkuil, Andreas Baierl, linux-sunxi, linux, wens, linux-kernel, linux-media Il 28/11/2017 14:07, Maxime Ripard ha scritto: > On Tue, Nov 28, 2017 at 02:03:43PM +0100, Giulio Benetti wrote: >> Hi, >> >>> Il giorno 28 nov 2017, alle ore 13:52, Maxime Ripard <maxime.ripard@free-electrons.com> ha scritto: >>> >>> On Tue, Nov 28, 2017 at 12:54:08PM +0100, Giulio Benetti wrote: >>>>>>> Should I be working in sunxi-next I wonder? >>>>>> >>>>>> Yes, this is the best way, cedrus is very specific to sunxi. >>>>>> So before working on mainline, I think the best is to work un sunxi-next branch. >>>>> >>>>> Is the requests2 api in sunxi-next? >>>> >>>> It should be there, >>>> take a look at latest commit of yesterday: >>>> https://github.com/linux-sunxi/linux-sunxi/commit/df7cacd062cd84c551d7e72f15b1af6d71abc198 >>> >>> No, it shouldn't. sunxi-next is about patches that are related to >>> sunxi that have been accepted in their respective maintainers' >>> branches. >>> >>> While we could argue about the first criteria, the second one is not >>> respected. >>> >>> And really, just develop against 4.14. sunxi-next is rebased, and it's >>> just not something you can base some work on. >> >> Where do we can work on then? >> Should Thomas setup his own github repo? >> What about the one you’ve set up @free-electrons? > > I already said that, please make pull requests to that repo. Sorry I can't understand which repo, do you mean https://github.com/free-electrons/linux-cedrus? And sorry for dumb question, but which branch do I have to use if I want to develop a project with sunxi? Directly mainline patched with sunxi-next branch, or another branch @linux-sunxi? Thank you for you patience. > > Maxime > -- 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 ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [linux-sunxi] Cedrus driver 2017-11-28 13:12 ` Giulio Benetti @ 2017-11-28 15:17 ` Maxime Ripard 2017-11-28 15:19 ` Giulio Benetti 0 siblings, 1 reply; 47+ messages in thread From: Maxime Ripard @ 2017-11-28 15:17 UTC (permalink / raw) To: Giulio Benetti Cc: Thomas van Kleef, Hans Verkuil, Andreas Baierl, linux-sunxi, linux, wens, linux-kernel, linux-media [-- Attachment #1: Type: text/plain, Size: 868 bytes --] On Tue, Nov 28, 2017 at 02:12:31PM +0100, Giulio Benetti wrote: > > > > And really, just develop against 4.14. sunxi-next is rebased, and it's > > > > just not something you can base some work on. > > > > > > Where do we can work on then? > > > Should Thomas setup his own github repo? > > > What about the one you’ve set up @free-electrons? > > > > I already said that, please make pull requests to that repo. > > Sorry I can't understand which repo, > do you mean https://github.com/free-electrons/linux-cedrus? Yes. > And sorry for dumb question, > but which branch do I have to use if I want to develop a project with sunxi? > Directly mainline patched with sunxi-next branch, > or another branch @linux-sunxi? Use 4.14. Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [linux-sunxi] Cedrus driver 2017-11-28 15:17 ` Maxime Ripard @ 2017-11-28 15:19 ` Giulio Benetti 0 siblings, 0 replies; 47+ messages in thread From: Giulio Benetti @ 2017-11-28 15:19 UTC (permalink / raw) To: Maxime Ripard Cc: Thomas van Kleef, Hans Verkuil, Andreas Baierl, linux-sunxi, linux, wens, linux-kernel, linux-media Il 28/11/2017 16:17, Maxime Ripard ha scritto: > On Tue, Nov 28, 2017 at 02:12:31PM +0100, Giulio Benetti wrote: >>>>> And really, just develop against 4.14. sunxi-next is rebased, and it's >>>>> just not something you can base some work on. >>>> >>>> Where do we can work on then? >>>> Should Thomas setup his own github repo? >>>> What about the one you’ve set up @free-electrons? >>> >>> I already said that, please make pull requests to that repo. >> >> Sorry I can't understand which repo, >> do you mean https://github.com/free-electrons/linux-cedrus? > > Yes. Ok > >> And sorry for dumb question, >> but which branch do I have to use if I want to develop a project with sunxi? >> Directly mainline patched with sunxi-next branch, >> or another branch @linux-sunxi? > > Use 4.14. Ok, thanks again. Best regards > > Maxime > -- 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 ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [linux-sunxi] Cedrus driver 2017-11-28 11:20 ` Thomas van Kleef 2017-11-28 11:26 ` Giulio Benetti @ 2017-11-28 12:26 ` Maxime Ripard 2017-11-28 14:51 ` Thomas van Kleef 1 sibling, 1 reply; 47+ messages in thread From: Maxime Ripard @ 2017-11-28 12:26 UTC (permalink / raw) To: Thomas van Kleef Cc: Giulio Benetti, Hans Verkuil, Andreas Baierl, linux-sunxi, linux, wens, linux-kernel, linux-media [-- Attachment #1: Type: text/plain, Size: 2075 bytes --] On Tue, Nov 28, 2017 at 12:20:59PM +0100, Thomas van Kleef wrote: > > So, I have been rebasing to 4.14.0 and have the cedrus driver working. > I have pulled linux-mainline 4.14.0. Then pulled the requests2 branch from Hans > Verkuil's media_tree. I have a patch available of the merge between these 2 > branches. > After this I pulled the sunxi-cedrus repository from Florent Revests github. I > believe this one is the same as the ones you are cloning right now. > I have merged this and have a patch available for this as well. > > So to summarize: > o pulled linux 4.14 from: > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git > o pulled requests2 from: > https://git.linuxtv.org/hverkuil/media_tree.git?h=requests2 > will be replaced with the work, when it is done, in: > https://git.linuxtv.org/hverkuil/media_tree.git?h=ctrl-req-v2 > o pulled linux-sunxi-cedrus from: > https://github.com/FlorentRevest/linux-sunxi-cedrus > > o merged and made patch between linux4.14 and requests2 > o merged and made patch with linux-sunxi-cedrus > o Verified that the video-engine is decofing mpeg-2 on the Allwinner A20. > > So maybe if someone is interested in this, I could place the patches somewhere? > Just let me know. Please create a pull request on the github repo. The point we set it up was to share code. Forking repos and so on is kind of pointless. > It would be nice to be able to play a file, so I would have to prepare our > custom player and make a patch between the current sunxi-cedrus-drv-video and > the one on https://github.com/FlorentRevest/sunxi-cedrus-drv-video. > So I will start with this if there is any interest. > > Should I be working in sunxi-next I wonder? I'd rather stick on 4.14. sunxi-next wouldn't bring any benefit, and we want to provide something that works first, and always merging next will always distract us from the actual code. Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [linux-sunxi] Cedrus driver 2017-11-28 12:26 ` Maxime Ripard @ 2017-11-28 14:51 ` Thomas van Kleef 2017-11-28 15:35 ` Maxime Ripard 0 siblings, 1 reply; 47+ messages in thread From: Thomas van Kleef @ 2017-11-28 14:51 UTC (permalink / raw) To: Maxime Ripard Cc: Giulio Benetti, Hans Verkuil, Andreas Baierl, linux-sunxi, linux, wens, linux-kernel, linux-media On 28-11-17 13:26, Maxime Ripard wrote: > On Tue, Nov 28, 2017 at 12:20:59PM +0100, Thomas van Kleef wrote: >>> So, I have been rebasing to 4.14.0 and have the cedrus driver working. >> I have pulled linux-mainline 4.14.0. Then pulled the requests2 branch from Hans >> Verkuil's media_tree. I have a patch available of the merge between these 2 >> branches. >> After this I pulled the sunxi-cedrus repository from Florent Revests github. I >> believe this one is the same as the ones you are cloning right now. >> I have merged this and have a patch available for this as well. >> >> So to summarize: >> o pulled linux 4.14 from: >> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git >> o pulled requests2 from: >> https://git.linuxtv.org/hverkuil/media_tree.git?h=requests2 >> will be replaced with the work, when it is done, in: >> https://git.linuxtv.org/hverkuil/media_tree.git?h=ctrl-req-v2 >> o pulled linux-sunxi-cedrus from: >> https://github.com/FlorentRevest/linux-sunxi-cedrus >> >> o merged and made patch between linux4.14 and requests2 >> o merged and made patch with linux-sunxi-cedrus >> o Verified that the video-engine is decofing mpeg-2 on the Allwinner A20. >> >> So maybe if someone is interested in this, I could place the patches somewhere? >> Just let me know. > > Please create a pull request on the github repo. The point we set it > up was to share code. Forking repos and so on is kind of pointless. > So, I started with linux-mainline 4.14 and created a pull request with that commit. Never made one before so if I did something wrong tell me. The following changes since commit e1d1ea549b57790a3d8cf6300e6ef86118d692a3: Merge tag 'fbdev-v4.15' of git://github.com/bzolnier/linux (2017-11-20 21:50:24 -1000) are available in the git repository at: https://github.com/thomas-vitsch/linux-a20-cedrus.git for you to fetch changes up to 508ad12eb737fde07f4a25446ed941a01480d6dc: Merge branch 'master' of https://github.com/thomas-vitsch/linux-a20-cedrus into linux-sunxi-cedrus-a20 (2017-11-28 15:28:18 +0100) ---------------------------------------------------------------- Bob Ham (1): sunxi-cedrus: Fix compilation errors from bad types under GCC 6.2 Florent Revest (8): cherry-pick sunxi_cedrus cherry-pick sunxi_cedrus v4l: Add MPEG4 low-level decoder API control media: platform: Add Sunxi Cedrus decoder driver sunxi-cedrus: Add a MPEG 2 codec sunxi-cedrus: Add a MPEG 4 codec sunxi-cedrus: Add device tree binding document cherry-pick sunxi_cedrus Hans Verkuil (15): videodev2.h: add max_reqs to struct v4l2_query_ext_ctrl videodev2.h: add request to v4l2_ext_controls videodev2.h: add request field to v4l2_buffer. vb2: add allow_requests flag v4l2-ctrls: add request support v4l2-ctrls: add function to apply a request. v4l2-ctrls: implement delete request(s) v4l2-ctrls: add VIDIOC_REQUEST_CMD v4l2: add initial V4L2_REQ_CMD_QUEUE support vb2: add helper function to queue request-specific buffer. v4l2-device: keep track of registered video_devices v4l2-device: add v4l2_device_req_queue vivid: add request support for video capture. v4l2-ctrls: add REQ_KEEP flag Documentation: add v4l2-requests.txt Icenowy Zheng (2): sunxi-cedrus: add syscon support cherry-pick sunxi_cedrus Thomas van Kleef (11): Appears that the requests2 API is currently based on linux 3.9 :(. Made some changes that needed to be merged manually, let's hope I did not make to many errors Fixed last missing calls for a buildable kernel with the requests2 API. Tested with a mock mem2mem device which selects the VIDEOBUF2_CORE. Kconfig option used to enable the VIDEOBUF2_CORE Fix sun5i-a13 merge errors. Mainline has moved some device nodes which resulted in nodes existing multiple times in device trees. o Added reserved memory region for the video-engine. o Added device node for the video engine. style commit Apply patch which adds requests2 branch from media-tree: https://git.linuxtv.org/hverkuil/media_tree.git?h=requests2 Apply patch which adds linux-sunxi-cedrus from: https://github.com/FlorentRevest/sunxi-cedrus-drv-video Add reserved region and video-engine node to sun7i.dtsi Merge branch 'master' of https://github.com/thomas-vitsch/linux-a20-cedrus into linux-a20-cedrus Merge branch 'master' of https://github.com/thomas-vitsch/linux-a20-cedrus into linux-sunxi-cedrus-a20 Vitsch Electronics (1): Update README .../devicetree/bindings/media/sunxi-cedrus.txt | 44 + Documentation/video4linux/v4l2-requests.txt | 233 ++ README | 18 +- arch/arm/boot/dts/sun5i-a13-difrnce-dit4350.dts | 50 - arch/arm/boot/dts/sun5i-a13.dtsi | 30 + arch/arm/boot/dts/sun7i-a20.dtsi | 44 + arch/arm/boot/dts/sun8i-a33.dtsi | 45 +- arch/arm/configs/xpo_player_v1_defconfig | 3507 ++++++++++++++++++++ drivers/media/platform/Kconfig | 13 + drivers/media/platform/Makefile | 1 + drivers/media/platform/sunxi-cedrus/Makefile | 4 + drivers/media/platform/sunxi-cedrus/sunxi_cedrus.c | 285 ++ .../platform/sunxi-cedrus/sunxi_cedrus_common.h | 104 + .../media/platform/sunxi-cedrus/sunxi_cedrus_dec.c | 588 ++++ .../media/platform/sunxi-cedrus/sunxi_cedrus_dec.h | 33 + .../media/platform/sunxi-cedrus/sunxi_cedrus_hw.c | 180 + .../media/platform/sunxi-cedrus/sunxi_cedrus_hw.h | 39 + .../platform/sunxi-cedrus/sunxi_cedrus_mpeg2.c | 152 + .../platform/sunxi-cedrus/sunxi_cedrus_mpeg4.c | 140 + .../platform/sunxi-cedrus/sunxi_cedrus_regs.h | 170 + drivers/media/platform/vivid/vivid-core.c | 2 + drivers/media/platform/vivid/vivid-ctrls.c | 4 + drivers/media/platform/vivid/vivid-kthread-cap.c | 2 + drivers/media/usb/cpia2/cpia2_v4l.c | 1 + drivers/media/v4l2-core/v4l2-compat-ioctl32.c | 4 +- drivers/media/v4l2-core/v4l2-ctrls.c | 460 ++- drivers/media/v4l2-core/v4l2-dev.c | 9 + drivers/media/v4l2-core/v4l2-device.c | 26 + drivers/media/v4l2-core/v4l2-ioctl.c | 121 +- drivers/media/v4l2-core/v4l2-subdev.c | 78 +- drivers/media/v4l2-core/videobuf2-v4l2.c | 28 + include/media/v4l2-ctrls.h | 35 +- include/media/v4l2-dev.h | 3 + include/media/v4l2-device.h | 6 + include/media/v4l2-fh.h | 4 + include/media/videobuf2-core.h | 3 + include/media/videobuf2-v4l2.h | 4 + include/uapi/linux/v4l2-controls.h | 68 + include/uapi/linux/videodev2.h | 43 +- 39 files changed, 6438 insertions(+), 143 deletions(-) create mode 100644 Documentation/devicetree/bindings/media/sunxi-cedrus.txt create mode 100644 Documentation/video4linux/v4l2-requests.txt delete mode 100644 arch/arm/boot/dts/sun5i-a13-difrnce-dit4350.dts create mode 100644 arch/arm/configs/xpo_player_v1_defconfig create mode 100644 drivers/media/platform/sunxi-cedrus/Makefile create mode 100644 drivers/media/platform/sunxi-cedrus/sunxi_cedrus.c create mode 100644 drivers/media/platform/sunxi-cedrus/sunxi_cedrus_common.h create mode 100644 drivers/media/platform/sunxi-cedrus/sunxi_cedrus_dec.c create mode 100644 drivers/media/platform/sunxi-cedrus/sunxi_cedrus_dec.h create mode 100644 drivers/media/platform/sunxi-cedrus/sunxi_cedrus_hw.c create mode 100644 drivers/media/platform/sunxi-cedrus/sunxi_cedrus_hw.h create mode 100644 drivers/media/platform/sunxi-cedrus/sunxi_cedrus_mpeg2.c create mode 100644 drivers/media/platform/sunxi-cedrus/sunxi_cedrus_mpeg4.c create mode 100644 drivers/media/platform/sunxi-cedrus/sunxi_cedrus_regs.h >> It would be nice to be able to play a file, so I would have to prepare our >> custom player and make a patch between the current sunxi-cedrus-drv-video and >> the one on https://github.com/FlorentRevest/sunxi-cedrus-drv-video. >> So I will start with this if there is any interest. >> >> Should I be working in sunxi-next I wonder? > > I'd rather stick on 4.14. sunxi-next wouldn't bring any benefit, and > we want to provide something that works first, and always merging next > will always distract us from the actual code. > > Maxime > Thomas van Kleef Vitsch Electronics http://Vitsch.nl/ http://VitschVPN.nl/ tel: +31-(0)40-7113051 KvK nr: 17174380 BTW nr: NL142748201B01 -- Machines en netwerken op afstand beheren? Vitsch VPN oplossing! Kijk voor meer informatie op: http://www.VitschVPN.nl/ ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [linux-sunxi] Cedrus driver 2017-11-28 14:51 ` Thomas van Kleef @ 2017-11-28 15:35 ` Maxime Ripard 2017-11-29 15:36 ` Thomas van Kleef 0 siblings, 1 reply; 47+ messages in thread From: Maxime Ripard @ 2017-11-28 15:35 UTC (permalink / raw) To: Thomas van Kleef Cc: Giulio Benetti, Hans Verkuil, Andreas Baierl, linux-sunxi, linux, wens, linux-kernel, linux-media [-- Attachment #1: Type: text/plain, Size: 6510 bytes --] Hi, On Tue, Nov 28, 2017 at 03:51:14PM +0100, Thomas van Kleef wrote: > On 28-11-17 13:26, Maxime Ripard wrote: > > On Tue, Nov 28, 2017 at 12:20:59PM +0100, Thomas van Kleef wrote: > >>> So, I have been rebasing to 4.14.0 and have the cedrus driver working. > >> I have pulled linux-mainline 4.14.0. Then pulled the requests2 branch from Hans > >> Verkuil's media_tree. I have a patch available of the merge between these 2 > >> branches. > >> After this I pulled the sunxi-cedrus repository from Florent Revests github. I > >> believe this one is the same as the ones you are cloning right now. > >> I have merged this and have a patch available for this as well. > >> > >> So to summarize: > >> o pulled linux 4.14 from: > >> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git > >> o pulled requests2 from: > >> https://git.linuxtv.org/hverkuil/media_tree.git?h=requests2 > >> will be replaced with the work, when it is done, in: > >> https://git.linuxtv.org/hverkuil/media_tree.git?h=ctrl-req-v2 > >> o pulled linux-sunxi-cedrus from: > >> https://github.com/FlorentRevest/linux-sunxi-cedrus > >> > >> o merged and made patch between linux4.14 and requests2 > >> o merged and made patch with linux-sunxi-cedrus > >> o Verified that the video-engine is decofing mpeg-2 on the Allwinner A20. > >> > >> So maybe if someone is interested in this, I could place the patches somewhere? > >> Just let me know. > > > > Please create a pull request on the github repo. The point we set it > > up was to share code. Forking repos and so on is kind of pointless. > > > So, I started with linux-mainline 4.14 and created a pull request with that commit. > Never made one before so if I did something wrong tell me. > > The following changes since commit e1d1ea549b57790a3d8cf6300e6ef86118d692a3: > > Merge tag 'fbdev-v4.15' of git://github.com/bzolnier/linux (2017-11-20 21:50:24 -1000) > > are available in the git repository at: > > https://github.com/thomas-vitsch/linux-a20-cedrus.git > > for you to fetch changes up to 508ad12eb737fde07f4a25446ed941a01480d6dc: > > Merge branch 'master' of https://github.com/thomas-vitsch/linux-a20-cedrus into linux-sunxi-cedrus-a20 (2017-11-28 15:28:18 +0100) > > ---------------------------------------------------------------- > Bob Ham (1): > sunxi-cedrus: Fix compilation errors from bad types under GCC 6.2 > > Florent Revest (8): > cherry-pick sunxi_cedrus > cherry-pick sunxi_cedrus > v4l: Add MPEG4 low-level decoder API control > media: platform: Add Sunxi Cedrus decoder driver > sunxi-cedrus: Add a MPEG 2 codec > sunxi-cedrus: Add a MPEG 4 codec > sunxi-cedrus: Add device tree binding document > cherry-pick sunxi_cedrus > > Hans Verkuil (15): > videodev2.h: add max_reqs to struct v4l2_query_ext_ctrl > videodev2.h: add request to v4l2_ext_controls > videodev2.h: add request field to v4l2_buffer. > vb2: add allow_requests flag > v4l2-ctrls: add request support > v4l2-ctrls: add function to apply a request. > v4l2-ctrls: implement delete request(s) > v4l2-ctrls: add VIDIOC_REQUEST_CMD > v4l2: add initial V4L2_REQ_CMD_QUEUE support > vb2: add helper function to queue request-specific buffer. > v4l2-device: keep track of registered video_devices > v4l2-device: add v4l2_device_req_queue > vivid: add request support for video capture. > v4l2-ctrls: add REQ_KEEP flag > Documentation: add v4l2-requests.txt > > Icenowy Zheng (2): > sunxi-cedrus: add syscon support > cherry-pick sunxi_cedrus > > Thomas van Kleef (11): > Appears that the requests2 API is currently based on linux 3.9 :(. Made some changes that needed to be merged manually, let's hope I did not make to many errors > Fixed last missing calls for a buildable kernel with the requests2 API. Tested with a mock mem2mem device which selects the VIDEOBUF2_CORE. > Kconfig option used to enable the VIDEOBUF2_CORE > Fix sun5i-a13 merge errors. Mainline has moved some device nodes which resulted in nodes existing multiple times in device trees. > o Added reserved memory region for the video-engine. o Added device node for the video engine. > style commit > Apply patch which adds requests2 branch from media-tree: https://git.linuxtv.org/hverkuil/media_tree.git?h=requests2 > Apply patch which adds linux-sunxi-cedrus from: https://github.com/FlorentRevest/sunxi-cedrus-drv-video > Add reserved region and video-engine node to sun7i.dtsi > Merge branch 'master' of https://github.com/thomas-vitsch/linux-a20-cedrus into linux-a20-cedrus > Merge branch 'master' of https://github.com/thomas-vitsch/linux-a20-cedrus into linux-sunxi-cedrus-a20 > > Vitsch Electronics (1): > Update README So there's a couple of issues with those patches (the pull request itself is fine though :)) I'll try to break them down as much as possible. A) If you want to have proper commit logs, you will usually do two things: first create a commit title, which is what appears in the above summary. That commit title should not be longer than 72 characters, and it should explain roughly what you're trying to do. The actual description should be in the commit log itself, and you should document what is the issue you're trying to fix / improve, how you're doing it and why you've done it that way. The final line of that commit log shoud be your Signed-off-by, which is your agreement to the Developer Certificate of Origin (DCO), that you'll find documented here: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst#n429 B) Please base your work on a known release (4.14) and not the middle of Linus' branch. C) I'm not sure what you tried to do with the application of the request API patches (such as e1ca861c168f) but we want to have the whole commits in there, and not a patch adding all of them. This will make the work so much easier to rebase to a later version when some patches wouldn't have been merged and some would have. D) Rebase :) Thanks! Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [linux-sunxi] Cedrus driver 2017-11-28 15:35 ` Maxime Ripard @ 2017-11-29 15:36 ` Thomas van Kleef 2017-11-30 15:24 ` Maxime Ripard 0 siblings, 1 reply; 47+ messages in thread From: Thomas van Kleef @ 2017-11-29 15:36 UTC (permalink / raw) To: Maxime Ripard Cc: Giulio Benetti, Hans Verkuil, Andreas Baierl, linux-sunxi, linux, wens, linux-kernel, linux-media Hi Maxime, > > So there's a couple of issues with those patches (the pull request > itself is fine though :)) > > I'll try to break them down as much as possible. > > A) If you want to have proper commit logs, you will usually do two > things: first create a commit title, which is what appears in the > above summary. That commit title should not be longer than 72 > characters, and it should explain roughly what you're trying to > do. The actual description should be in the commit log itself, and > you should document what is the issue you're trying to fix / > improve, how you're doing it and why you've done it that way. Ah, so the pull-request commits are not proper, I will try do that from now on. these last ones are quite bad. > > The final line of that commit log shoud be your Signed-off-by, > which is your agreement to the Developer Certificate of Origin > (DCO), that you'll find documented here: > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst#n429 > > B) Please base your work on a known release (4.14) and not the middle > of Linus' branch. Should be fixed now. > > C) I'm not sure what you tried to do with the application of the > request API patches (such as e1ca861c168f) but we want to have the > whole commits in there, and not a patch adding all of them. This > will make the work so much easier to rebase to a later version when > some patches wouldn't have been merged and some would have. > > D) Rebase :) Thank you. Giulio asked before if I could add a repo and commit the patches so that is what I did. I will push a different code where the full history is present in commits. So, I got it setup. As I did test it before on the slightly newer branch, I did not verify, again, if the video-decoder worked on this specific state of the linux kernel, 4.14. But it should x: If you rather wait for me to tell if it work let me know, but we could do a pull request then again anyway. So here is the new pull-request The following changes since commit bebc6082da0a9f5d47a1ea2edc099bf671058bd4: Linux 4.14 (2017-11-12 10:46:13 -0800) are available in the git repository at: https://github.com/thomas-vitsch/linux-a20-cedrus.git linux-sunxi-cedrus for you to fetch changes up to 26701eca67a07ab002c7fd18038fa299b9589939: Fix the sun5i and sun8i dts files (2017-11-29 15:18:05 +0100) ---------------------------------------------------------------- Bob Ham (1): sunxi-cedrus: Fix compilation errors from bad types under GCC 6.2 Florent Revest (8): Both mainline and cedrus had added their own formats with both are added. v4l: Add MPEG2 low-level decoder API control v4l: Add MPEG4 low-level decoder API control media: platform: Add Sunxi Cedrus decoder driver sunxi-cedrus: Add a MPEG 2 codec sunxi-cedrus: Add a MPEG 4 codec sunxi-cedrus: Add device tree binding document ARM: dts: sun5i: Use video-engine node Hans Verkuil (15): videodev2.h: add max_reqs to struct v4l2_query_ext_ctrl videodev2.h: add request to v4l2_ext_controls videodev2.h: add request field to v4l2_buffer. vb2: add allow_requests flag v4l2-ctrls: add request support v4l2-ctrls: add function to apply a request. v4l2-ctrls: implement delete request(s) v4l2-ctrls: add VIDIOC_REQUEST_CMD v4l2: add initial V4L2_REQ_CMD_QUEUE support vb2: add helper function to queue request-specific buffer. v4l2-device: keep track of registered video_devices v4l2-device: add v4l2_device_req_queue vivid: add request support for video capture. v4l2-ctrls: add REQ_KEEP flag Documentation: add v4l2-requests.txt Icenowy Zheng (2): sunxi-cedrus: add syscon support ARM: dts: sun8i: add video engine support for A33 Thomas van Kleef (4): Merged requests2 into linux 4.14 Fix merge error Remove reject file from merge Fix the sun5i and sun8i dts files .../devicetree/bindings/media/sunxi-cedrus.txt | 44 ++ Documentation/video4linux/v4l2-requests.txt | 233 ++++++++ arch/arm/boot/dts/sun5i-a13-difrnce-dit4350.dts | 50 -- arch/arm/boot/dts/sun5i-a13.dtsi | 30 ++ arch/arm/boot/dts/sun8i-a33.dtsi | 39 ++ drivers/media/platform/Kconfig | 13 + drivers/media/platform/Makefile | 1 + drivers/media/platform/sunxi-cedrus/Makefile | 4 + drivers/media/platform/sunxi-cedrus/sunxi_cedrus.c | 285 ++++++++++ .../platform/sunxi-cedrus/sunxi_cedrus_common.h | 104 ++++ .../media/platform/sunxi-cedrus/sunxi_cedrus_dec.c | 588 +++++++++++++++++++++ .../media/platform/sunxi-cedrus/sunxi_cedrus_dec.h | 33 ++ .../media/platform/sunxi-cedrus/sunxi_cedrus_hw.c | 180 +++++++ .../media/platform/sunxi-cedrus/sunxi_cedrus_hw.h | 39 ++ .../platform/sunxi-cedrus/sunxi_cedrus_mpeg2.c | 152 ++++++ .../platform/sunxi-cedrus/sunxi_cedrus_mpeg4.c | 140 +++++ .../platform/sunxi-cedrus/sunxi_cedrus_regs.h | 170 ++++++ drivers/media/platform/vivid/vivid-core.c | 2 + drivers/media/platform/vivid/vivid-ctrls.c | 4 + drivers/media/platform/vivid/vivid-kthread-cap.c | 2 + drivers/media/usb/cpia2/cpia2_v4l.c | 1 + drivers/media/v4l2-core/v4l2-compat-ioctl32.c | 4 +- drivers/media/v4l2-core/v4l2-ctrls.c | 460 ++++++++++++++-- drivers/media/v4l2-core/v4l2-dev.c | 9 + drivers/media/v4l2-core/v4l2-device.c | 28 + drivers/media/v4l2-core/v4l2-ioctl.c | 121 ++++- drivers/media/v4l2-core/v4l2-subdev.c | 78 ++- drivers/media/v4l2-core/videobuf2-v4l2.c | 28 + include/media/v4l2-ctrls.h | 45 +- include/media/v4l2-dev.h | 3 + include/media/v4l2-device.h | 6 + include/media/v4l2-fh.h | 4 + include/media/videobuf2-core.h | 3 + include/media/videobuf2-v4l2.h | 3 + include/uapi/linux/v4l2-controls.h | 68 +++ include/uapi/linux/videodev2.h | 41 +- 36 files changed, 2883 insertions(+), 132 deletions(-) create mode 100644 Documentation/devicetree/bindings/media/sunxi-cedrus.txt create mode 100644 Documentation/video4linux/v4l2-requests.txt delete mode 100644 arch/arm/boot/dts/sun5i-a13-difrnce-dit4350.dts create mode 100644 drivers/media/platform/sunxi-cedrus/Makefile create mode 100644 drivers/media/platform/sunxi-cedrus/sunxi_cedrus.c create mode 100644 drivers/media/platform/sunxi-cedrus/sunxi_cedrus_common.h create mode 100644 drivers/media/platform/sunxi-cedrus/sunxi_cedrus_dec.c create mode 100644 drivers/media/platform/sunxi-cedrus/sunxi_cedrus_dec.h create mode 100644 drivers/media/platform/sunxi-cedrus/sunxi_cedrus_hw.c create mode 100644 drivers/media/platform/sunxi-cedrus/sunxi_cedrus_hw.h create mode 100644 drivers/media/platform/sunxi-cedrus/sunxi_cedrus_mpeg2.c create mode 100644 drivers/media/platform/sunxi-cedrus/sunxi_cedrus_mpeg4.c create mode 100644 drivers/media/platform/sunxi-cedrus/sunxi_cedrus_regs.h > > Thanks! > Maxime > Thomas van Kleef Vitsch Electronics http://Vitsch.nl/ http://VitschVPN.nl/ tel: +31-(0)40-7113051 KvK nr: 17174380 BTW nr: NL142748201B01 -- Machines en netwerken op afstand beheren? Vitsch VPN oplossing! Kijk voor meer informatie op: http://www.VitschVPN.nl/ ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [linux-sunxi] Cedrus driver 2017-11-29 15:36 ` Thomas van Kleef @ 2017-11-30 15:24 ` Maxime Ripard 0 siblings, 0 replies; 47+ messages in thread From: Maxime Ripard @ 2017-11-30 15:24 UTC (permalink / raw) To: Thomas van Kleef Cc: Giulio Benetti, Hans Verkuil, Andreas Baierl, linux-sunxi, linux, wens, linux-kernel, linux-media [-- Attachment #1: Type: text/plain, Size: 3766 bytes --] Hi Thomas, On Wed, Nov 29, 2017 at 04:36:01PM +0100, Thomas van Kleef wrote: > > C) I'm not sure what you tried to do with the application of the > > request API patches (such as e1ca861c168f) but we want to have the > > whole commits in there, and not a patch adding all of them. This > > will make the work so much easier to rebase to a later version when > > some patches wouldn't have been merged and some would have. > > > > D) Rebase :) > > Thank you. Giulio asked before if I could add a repo and commit the > patches so that is what I did. I will push a different code where the > full history is present in commits. > > So, I got it setup. As I did test it before on the slightly newer branch, > I did not verify, again, if the video-decoder worked on this specific > state of the linux kernel, 4.14. But it should x: > If you rather wait for me to tell if it work let me know, but we could do > a pull request then again anyway. Yeah, I'd rather wait for at least small test that the general case is working. > So here is the new pull-request > The following changes since commit bebc6082da0a9f5d47a1ea2edc099bf671058bd4: > > Linux 4.14 (2017-11-12 10:46:13 -0800) > > are available in the git repository at: > > https://github.com/thomas-vitsch/linux-a20-cedrus.git linux-sunxi-cedrus > > for you to fetch changes up to 26701eca67a07ab002c7fd18038fa299b9589939: > > Fix the sun5i and sun8i dts files (2017-11-29 15:18:05 +0100) > > ---------------------------------------------------------------- > Bob Ham (1): > sunxi-cedrus: Fix compilation errors from bad types under GCC 6.2 > > Florent Revest (8): > Both mainline and cedrus had added their own formats with both are added. > v4l: Add MPEG2 low-level decoder API control > v4l: Add MPEG4 low-level decoder API control > media: platform: Add Sunxi Cedrus decoder driver > sunxi-cedrus: Add a MPEG 2 codec > sunxi-cedrus: Add a MPEG 4 codec > sunxi-cedrus: Add device tree binding document > ARM: dts: sun5i: Use video-engine node > > Hans Verkuil (15): > videodev2.h: add max_reqs to struct v4l2_query_ext_ctrl > videodev2.h: add request to v4l2_ext_controls > videodev2.h: add request field to v4l2_buffer. > vb2: add allow_requests flag > v4l2-ctrls: add request support > v4l2-ctrls: add function to apply a request. > v4l2-ctrls: implement delete request(s) > v4l2-ctrls: add VIDIOC_REQUEST_CMD > v4l2: add initial V4L2_REQ_CMD_QUEUE support > vb2: add helper function to queue request-specific buffer. > v4l2-device: keep track of registered video_devices > v4l2-device: add v4l2_device_req_queue > vivid: add request support for video capture. > v4l2-ctrls: add REQ_KEEP flag > Documentation: add v4l2-requests.txt > > Icenowy Zheng (2): > sunxi-cedrus: add syscon support > ARM: dts: sun8i: add video engine support for A33 > > Thomas van Kleef (4): > Merged requests2 into linux 4.14 > Fix merge error > Remove reject file from merge > Fix the sun5i and sun8i dts files There's still two minor issues with your patches here. Your SoB should contain your name only, so you should drop the Vitsch Electronics part. And the patches that are fixing compilation issues should be squashed in the patches that introduced the breakage in the first place. So a01b8665802145f1180680b67e5e1d04f2050fe3 should be merged with 1c735c83c68d54616503481b2796005f02930b85 for example. Thanks! Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [linux-sunxi] Cedrus driver 2017-11-16 13:17 ` Giulio Benetti 2017-11-16 13:39 ` Maxime Ripard @ 2017-11-16 13:39 ` Hans Verkuil 1 sibling, 0 replies; 47+ messages in thread From: Hans Verkuil @ 2017-11-16 13:39 UTC (permalink / raw) To: Giulio Benetti, Maxime Ripard Cc: Andreas Baierl, linux-sunxi, linux, wens, linux-kernel, thomas, linux-media On 16/11/17 14:17, Giulio Benetti wrote: > Hi Hans, > > Il 16/11/2017 14:12, Hans Verkuil ha scritto: >> On 16/11/17 13:57, Giulio Benetti wrote: >>> Il 16/11/2017 13:53, Maxime Ripard ha scritto: >>>> On Thu, Nov 16, 2017 at 01:30:52PM +0100, Giulio Benetti wrote: >>>>>> 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. >>>>> >>>>> Lot of work to do >>>> >>>> Well... If it was fast and easy it would have been done already :) >>> >>> :)) >>> >>>> >>>>>>>>> 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. >>>>> >>>>> Is it possible a preview on a separate Reporitory to start working on now? >>>>> Expecially to start porting everything done by FlorentRevest to mainline, >>>>> admitted you've not already done. >>>> >>>> I'm not sure what you're asking for. Florent's work *was* on mainline. >>> >>> and then they took it off because it was unmantained? >>> You've spoken about Thomas(in CC) not ready, >>> maybe I could help on that if it's public to accelerate. >>> If I'm able to of course, this is my primary concern. >>> >>> Otherwise, in which way can I help improving it to make it accept to linux-sunxi? >>> Starting from Florent's work and porting it to sunxi-next to begin? >>> And after that adding all features you've listed? >>> Tell me what I can do(I repeat, if I'm able to). >> >> The bottleneck is that the Request API is not mainlined. We restarted work >> on it after a meeting a few weeks back where we all agreed on the roadmap >> so hopefully it will go into mainline Q1 or Q2 next year. >> >> That said, you can use Florent's patch series for further development. >> It should be relatively easy to convert it to the final version of the >> Request API. Just note that the public API of the final Request API will >> be somewhat different from the old version Florent's patch series is using. > > So I'm going to try soon to : > 1) adapt that patchset to sunxi-next > 2) add A20 support > 3) add A33 support > 4) after mainlined APIs, merge > > Alright? Sounds reasonable. Regards, Hans > > Regards > >> >> Regards, >> >> Hans >> >>> >>>> >>>> Maxime >>>> >>> >>> Thank you >>> >> > > ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [linux-sunxi] Cedrus driver 2017-11-16 11:02 ` Maxime Ripard ` (2 preceding siblings ...) (?) @ 2017-11-16 13:11 ` Stefan Monnier -1 siblings, 0 replies; 47+ messages in thread From: Stefan Monnier @ 2017-11-16 13:11 UTC (permalink / raw) To: devicetree-u79uwXL29TY76Z2rM5mHXA Cc: linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, linux-kernel-u79uwXL29TY76Z2rM5mHXA, linux-media-u79uwXL29TY76Z2rM5mHXA >> 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 Are all these really needed before it can be merged? Stefan -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [linux-sunxi] Cedrus driver 2017-11-16 11:02 ` Maxime Ripard (?) @ 2017-11-16 19:59 ` Nicolas Dufresne -1 siblings, 0 replies; 47+ messages in thread From: Nicolas Dufresne @ 2017-11-16 19:59 UTC (permalink / raw) To: Maxime Ripard, Giulio Benetti Cc: Andreas Baierl, linux-sunxi, robh+dt, mark.rutland, linux, wens, devicetree, linux-arm-kernel, linux-kernel, thomas, linux-media [-- Attachment #1: Type: text/plain, Size: 1440 bytes --] 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 [-- Attachment #2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 195 bytes --] ^ permalink raw reply [flat|nested] 47+ messages in thread
* [linux-sunxi] Cedrus driver @ 2017-11-16 19:59 ` Nicolas Dufresne 0 siblings, 0 replies; 47+ messages in thread From: Nicolas Dufresne @ 2017-11-16 19:59 UTC (permalink / raw) To: linux-arm-kernel 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> ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [linux-sunxi] Cedrus driver @ 2017-11-16 19:59 ` Nicolas Dufresne 0 siblings, 0 replies; 47+ messages in thread From: Nicolas Dufresne @ 2017-11-16 19:59 UTC (permalink / raw) To: Maxime Ripard, Giulio Benetti Cc: Andreas Baierl, linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8, linux-I+IVW8TIWO2tmTQ+vhA3Yw, wens-jdAy2FN1RRM, devicetree-u79uwXL29TY76Z2rM5mHXA, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, linux-kernel-u79uwXL29TY76Z2rM5mHXA, thomas-XCRq7eEM0/pmR6Xm/wNWPw, linux-media-u79uwXL29TY76Z2rM5mHXA [-- Attachment #1: Type: text/plain, Size: 1440 bytes --] 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 [-- Attachment #2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 195 bytes --] ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [linux-sunxi] Cedrus driver @ 2017-11-17 8:01 ` Maxime Ripard 0 siblings, 0 replies; 47+ messages in thread From: Maxime Ripard @ 2017-11-17 8:01 UTC (permalink / raw) To: Nicolas Dufresne Cc: Giulio Benetti, Andreas Baierl, linux-sunxi, robh+dt, mark.rutland, linux, wens, devicetree, linux-arm-kernel, linux-kernel, thomas, linux-media [-- Attachment #1: Type: text/plain, Size: 1873 bytes --] 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 [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 801 bytes --] ^ permalink raw reply [flat|nested] 47+ messages in thread
* [linux-sunxi] Cedrus driver @ 2017-11-17 8:01 ` Maxime Ripard 0 siblings, 0 replies; 47+ messages in thread From: Maxime Ripard @ 2017-11-17 8:01 UTC (permalink / raw) To: linux-arm-kernel 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> ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: Cedrus driver @ 2017-11-17 8:01 ` Maxime Ripard 0 siblings, 0 replies; 47+ messages in thread From: Maxime Ripard @ 2017-11-17 8:01 UTC (permalink / raw) To: Nicolas Dufresne Cc: Giulio Benetti, Andreas Baierl, linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8, linux-I+IVW8TIWO2tmTQ+vhA3Yw, wens-jdAy2FN1RRM, devicetree-u79uwXL29TY76Z2rM5mHXA, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, linux-kernel-u79uwXL29TY76Z2rM5mHXA, thomas-XCRq7eEM0/pmR6Xm/wNWPw, linux-media-u79uwXL29TY76Z2rM5mHXA [-- Attachment #1: Type: text/plain, Size: 2197 bytes --] 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 -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit https://groups.google.com/d/optout. [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 801 bytes --] ^ permalink raw reply [flat|nested] 47+ messages in thread
end of thread, other threads:[~2017-11-30 15:24 UTC | newest]
Thread overview: 47+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-11-07 12:59 [PATCH 1/1] add mali r6p2 dt node Giulio Benetti
2017-11-07 12:59 ` Giulio Benetti
2017-11-07 12:59 ` Giulio Benetti
2017-11-07 13:02 ` Maxime Ripard
2017-11-07 13:02 ` Maxime Ripard
2017-11-16 10:13 ` Cedrus driver Giulio Benetti
2017-11-16 10:13 ` Giulio Benetti
[not found] ` <6fcdc0d9-d0f8-785a-bb00-b1b41c684e59@imkreisrum.de>
2017-11-16 10:37 ` [linux-sunxi] " Giulio Benetti
2017-11-16 10:37 ` Giulio Benetti
2017-11-16 10:37 ` Giulio Benetti
2017-11-16 11:02 ` [linux-sunxi] " Maxime Ripard
2017-11-16 11:02 ` Maxime Ripard
2017-11-16 11:02 ` Maxime Ripard
2017-11-16 12:30 ` Giulio Benetti
2017-11-16 12:53 ` Maxime Ripard
2017-11-16 12:57 ` Giulio Benetti
2017-11-16 13:12 ` Hans Verkuil
2017-11-16 13:17 ` Giulio Benetti
2017-11-16 13:39 ` Maxime Ripard
2017-11-16 13:42 ` Giulio Benetti
2017-11-28 0:03 ` Giulio Benetti
2017-11-28 8:35 ` Maxime Ripard
2017-11-28 9:50 ` Giulio Benetti
2017-11-28 11:20 ` Thomas van Kleef
2017-11-28 11:26 ` Giulio Benetti
2017-11-28 11:29 ` Thomas van Kleef
2017-11-28 11:54 ` Giulio Benetti
2017-11-28 12:31 ` Thomas van Kleef
2017-11-28 12:52 ` Maxime Ripard
2017-11-28 13:03 ` Giulio Benetti
2017-11-28 13:07 ` Maxime Ripard
2017-11-28 13:12 ` Giulio Benetti
2017-11-28 15:17 ` Maxime Ripard
2017-11-28 15:19 ` Giulio Benetti
2017-11-28 12:26 ` Maxime Ripard
2017-11-28 14:51 ` Thomas van Kleef
2017-11-28 15:35 ` Maxime Ripard
2017-11-29 15:36 ` Thomas van Kleef
2017-11-30 15:24 ` Maxime Ripard
2017-11-16 13:39 ` Hans Verkuil
2017-11-16 13:11 ` Stefan Monnier
2017-11-16 19:59 ` Nicolas Dufresne
2017-11-16 19:59 ` Nicolas Dufresne
2017-11-16 19:59 ` Nicolas Dufresne
2017-11-17 8:01 ` Maxime Ripard
2017-11-17 8:01 ` Maxime Ripard
2017-11-17 8:01 ` Maxime Ripard
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.