| Message ID | 1510059543-7064-1-git-send-email-giulio.benetti@micronovasrl.com (mailing list archive) |
|---|---|
| State | Rejected, archived |
| Headers | show |
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
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 >> >
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
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
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
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>;
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(+)