linux-kernel - Re: [RFC 0/5] arm64: imx8mm: Enable Hantro VPUs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <8438070708d16c34c0f79aba19e67fa343adb169.camel@ndufresne.ca>
Date:   Fri, 17 Dec 2021 12:13:37 -0500
From:   Nicolas Dufresne <nicolas@...fresne.ca>
To:     Adam Ford <aford173@...il.com>,
        Ezequiel Garcia <ezequiel@...guardiasur.com.ar>
Cc:     Tim Harvey <tharvey@...eworks.com>,
        linux-media <linux-media@...r.kernel.org>,
        Schrempf Frieder <frieder.schrempf@...tron.de>,
        Marek Vasut <marek.vasut@...il.com>,
        Jagan Teki <jagan@...rulasolutions.com>,
        Adam Ford-BE <aford@...conembedded.com>,
        cstevens@...conembedded.com,
        Philipp Zabel <p.zabel@...gutronix.de>,
        Mauro Carvalho Chehab <mchehab@...nel.org>,
        Rob Herring <robh+dt@...nel.org>,
        Shawn Guo <shawnguo@...nel.org>,
        Sascha Hauer <s.hauer@...gutronix.de>,
        Pengutronix Kernel Team <kernel@...gutronix.de>,
        Fabio Estevam <festevam@...il.com>,
        NXP Linux Team <linux-imx@....com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Heiko Stuebner <heiko@...ech.de>,
        Lucas Stach <l.stach@...gutronix.de>,
        Joakim Zhang <qiangqing.zhang@....com>,
        Alice Guo <alice.guo@....com>, Peng Fan <peng.fan@....com>,
        "open list:HANTRO VPU CODEC DRIVER" 
        <linux-rockchip@...ts.infradead.org>,
        "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
        <devicetree@...r.kernel.org>,
        "moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE" 
        <linux-arm-kernel@...ts.infradead.org>,
        open list <linux-kernel@...r.kernel.org>,
        "open list:STAGING SUBSYSTEM" <linux-staging@...ts.linux.dev>
Subject: Re: [RFC 0/5] arm64: imx8mm: Enable Hantro VPUs

Le vendredi 17 décembre 2021 à 07:15 -0600, Adam Ford a écrit :
> On Thu, Dec 16, 2021 at 10:49 PM Ezequiel Garcia
> <ezequiel@...guardiasur.com.ar> wrote:
> > 
> > Hi Adam,
> > 
> > > 
> > > I will post a V2 last today with the Mini's post-processing removed.
> > > Someone, I apologize that I forget who, mentioned it was fused out of
> > > the Mini, so the testing I've been doing was with that removed and I
> > > removed the H1 encoder since the Mini doesn't support JPEG encoding.
> > > 
> > [...]
> > 
> > Resurrecting this thread here. IMX8MMRM Rev. 0, 02/2019 mentions
> > post-processor features for G1 and G2.
> > 
> > Have you checked the fuse and synth registers to see if they throw
> > any useful information about the hardware? For instance,
> > comparing PP fuse register (SWREG99) and
> > Synthesis configuration register post-processor (SWREG100)
> > in both 8MQ and 8MM could be useful.
> > 
> > As I mentioned on my previous mail, even if G1 PP is disabled
> > on the Mini, I would imagine the G2 can do linear NV12 (aka raster-scan)
> > which in our hantro driver jargon is a  "post-processed" format :-)
> 
> You're likely right.  I was going on memory from an e-mail from
> Nicloas Defresne who wrote:
> 
> "I will check the patchset, but you need in the mini-variant to disable the G1
> post processor, because this block was fused out. We didn't make it optional
> from the start as according to the V1 of the TRM it was there, but that error
> was corrected in V3."
> 
> In my head I assumed the G2 was affected as well, but when I double
> checked his email, and based on the above statement, the G2
> post-processing is probably there, so I'll run some tests with the G2
> post-processing enabled.  I'll also double check those registers on
> both to confirm what they read. I am not sure when I'll have time
> because I leave for London next week, and I won't return until early
> January, but I'll do what I can.

Sorry if this was a bit ambiguous, indeed I meant the G1 only. I've learned
later that the design of the Mini is that there is a good pre-processor in the
H1 block (encoder), so for the targeted use-cases this shall be sufficient for
most users (the output of the G1 is suitable for GPU and Display already, so the
post processor is not strictly needed).

regards,
Nicolas

> 
> adam
> > 
> > Thanks,
> > Ezequiel