Le vendredi 17 décembre 2021 à 09:26 -0800, Tim Harvey a écrit :

On Fri, Dec 17, 2021 at 9:13 AM Nicolas Dufresne [off-list ref] wrote:

quoted

Le vendredi 17 décembre 2021 à 07:15 -0600, Adam Ford a écrit :

quoted

On Thu, Dec 16, 2021 at 10:49 PM Ezequiel Garcia
[off-list ref] wrote:

quoted

Hi Adam,

quoted

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).

Nicolas,

Does this mean that if the IMX8MM G2 may be able to output a wider
array of pixel formats and that the H1 encoder may be able to accept a
wider array of pixel formats? Is this code already in place in the

No since the G2 post processor does not have a color converter (it is very
limited). In term of format, this is pretty much identical, produces linear or
tiled. The difference is that G1 supports the two layout natively, not the G2.

hantro driver and it just needs to be enabled if the IMX8MM can handle
it or is there code to be written?

I'm not clear if anyone is working on IMX8MM VPU H1 support. You had
mentioned that some support [1] and [2] can be derived from the RK3288
using the Google ChromeOS method (a v4l2 plugin that simulates in
userspace a stateful encoder). I'm not sure if this is worth pursuing
if others are working on stateless encode support in kernel and
gstreamer.

My colleagues started last week the project of crafting mainline stateless
encoder uAPI. This is too early. In older project, we have had good success with
the emulated stateful encoder. It is of course quite limited, but works in
gstreamer, ffmpeg and chromium. It is also likely safer compared to the vendor
provided driver.

p.s. From my knowledge, there is virtually no difference between the H1 on
RK3288 and IMX8MM/P, but we've learn from G1 that there could effectively have
more of less features.

Best Regards,

Tim
[1] libv4l plugins /
https://chromium.googlesource.com/chromiumos/third_party/libv4lplugins/+/refs/heads/master
[2] Kernel Driver /
https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-4.4/drivers/media/platform/rockchip-vpu/

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel