Message-ID: <CAHStOZ4O=sdHaKrY_DwkhDHVBsa_Dg4xWEBrS77LHG-WbZ6-Cw@mail.gmail.com>
Date:   Mon, 20 May 2019 21:21:43 +0200
From:   Maxime Jourdan <maxi.jourdan@...adoo.fr>
To:     Martin Blumenstingl <martin.blumenstingl@...glemail.com>
Cc:     Maxime Jourdan <maxi.jourdan@...adoo.fr>,
        linux-amlogic <linux-amlogic@...ts.infradead.org>,
        Kevin Hilman <khilman@...libre.com>, mjourdan@...libre.com,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH 0/3] 32-bit Meson: add the canvas module

Hey Martin, so sorry for forgetting about this.

On Thu, Apr 18, 2019 at 9:50 PM Martin Blumenstingl
<martin.blumenstingl@...glemail.com> wrote:
>
> Hi Maxime,
>
> On Sat, Apr 13, 2019 at 8:54 PM Maxime Jourdan <maxi.jourdan@...adoo.fr> wrote:
> >
> > Hi Martin,
> > On Sat, Apr 13, 2019 at 7:15 PM Martin Blumenstingl
> > <martin.blumenstingl@...glemail.com> wrote:
> > >
> > > This adds the canvas module on Meson8, Meson8b and Meson8m2. The canvas
> > > IP is used by the video decoder hardware as well as the VPU (video
> > > output) hardware.
> > >
> > > Neither the VPU nor the video decoder driver support the 32-bit SoCs
> > > yet. However, we can still add the canvas module to have it available
> > > once these drivers gain support for the older SoCs.
> > >
> > > I have tested this on my Meson8m2 board by hacking the VPU driver to
> > > not re-initialize the VPU (and to use the configuration set by u-boot).
> > > With that hack I could get some image out of the CVBS connector. No
> > > changes to the canvas driver were required.
> > >
> > > Due to lack of hardware I could not test Meson8, but I'm following (as
> > > always) what the Amlogic 3.10 vendor kernel uses.
> > > Meson8b is also not tested because u-boot of my EC-100 doesn't have
> > > video output enabled (so I couldn't use the same hack I used on my
> > > Meson8m2 board).
> > >
> > > This series meant to be applied on top of "Meson8b: add support for the
> > > RTC on EC-100 and Odroid-C1" from [0]
> > >
> > >
> >
> > The series looks good to me, however I wonder if we should maybe add a
> > new compatible ?
> >
> > The canvas IP before the GX* generation does not handle what Amlogic
> > calls "endianness", the field that allows doing some byte-switching to
> > get proper NV12/NV21. So the following defines are unusable:
> >
> > #define MESON_CANVAS_ENDIAN_SWAP16 0x1
> > #define MESON_CANVAS_ENDIAN_SWAP32 0x3
> > #define MESON_CANVAS_ENDIAN_SWAP64 0x7
> > #define MESON_CANVAS_ENDIAN_SWAP128 0xf
> I didn't know about this - thank you for pointing this out.
>
> your suggestions to add new compatible strings is a good idea for that case.
> Amlogic uses different defines for Meson8 and Meson8m2 in their vendor
> kernel and they keep Meson8b different.
> I will add three new compatibles, one for each SoC (Meson8, Meson8b,
> Meson8m2) just to be on the safe side if we discover differences in
> the canvas IP on these SoCs.
>
> what do you think?
>

Sure thing. Keep an eye out for any hints regarding the amount of
canvases as well, I *think* I remember some old SoCs having only 192
but I haven't been able to find it again.

> > It wouldn't change much functionally, but we could have e.g a warning
> > if a m8 canvas user tries to set endianness even though it does
> > nothing.
> this is a good idea, that will make it easier to spot why something
> doesn't work.
> we can also return -EINVAL, like you already do for the case where the
> canvas ID is already used.
>

Yes, returning an error is a good idea.

Maxime

>
> Martin

Powered by blists - more mailing lists