The G2 core decoder engine produces NV12_4L4 format,
which is a simple NV12 4x4 tiled format. The driver currently
hides this format by always enabling the post-processor engine,
and therefore offering NV12 directly.
This is done without using the logic in hantro_postproc.c
and therefore makes it difficult to add VP9 cleanly.
Since fixing this is not easy, add a small quirk to force
NV12 if HEVC was configured, but otherwise declare NV12_4L4
as the pixel format in imx8mq_vpu_g2_variant.dec_fmts.
This will be used by the VP9 decoder which will be added soon.
Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
Signed-off-by: Andrzej Pietrasiewicz <andrzej.p@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Add a 'postprocessed' boolean property to struct hantro_fmt
to signal that a format is produced by the post-processor.
This will allow to introduce the G2 post-processor in a simple way.
Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
Signed-off-by: Andrzej Pietrasiewicz <andrzej.p@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Turns out the post-processor block on the G2 core is substantially
different from the one on the G1 core. Introduce hantro_postproc_ops
with .enable and .disable methods, which will allow to support
the G2 post-processor cleanly.
Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
Signed-off-by: Andrzej Pietrasiewicz <andrzej.p@collabora.com>
Reviewed-by: Benjamin Gaignard <benjamin.gaignard@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
When the post-processor hardware block is enabled, the driver
allocates an internal queue of buffers for the decoder enginer,
and uses the vb2 queue for the post-processor engine.
For instance, on a G1 core, the decoder engine produces NV12 buffers
and the post-processor engine can produce YUY2 buffers. The decoder
engine expects motion vectors to be appended to the NV12 buffers,
but this is only required for CODECs that need motion vectors,
such as H.264.
Fix the post-processor logic accordingly.
Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
Signed-off-by: Andrzej Pietrasiewicz <andrzej.p@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
The logic there is meant to be used by newer firmwares.
clean it up, in order to make compatible with the chosen
firmware version.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
It doesn't make sense to have a control for that. Besides that,
the Intel Aero implementation doesn't have, which means that
even the custom control is not used in practice, at least
outside Android.
So, get rid of it.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Change some recovery logic at the driver, in order to make it
more compatible with ISP2401 Intel Aero firmware.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
As we're using Intel Aero firmware, make the code closer to the
driver for such device.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
The comments are not following Kernel coding style.
Also, there are two missing comments that are found at the Intel Aero
device driver code. Add them.
No functional changes.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Those seem to be used only on certain ISP2401 firmwares that
aren't supported by the driver. So, get rid of them.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
This is meant to select a platform-dependent factor between
Linux and Windows. It makes no sense to keep it on Kernel.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Now that the tests for the new ISP2401 input system were
dropped, simplify the code, making it closer to the Intel
Aero device driver.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Those tests are related to the input system, which is the same
for the chosen firmware, so both ISP2400 and ISP2401 will be
identical with that regards.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
With the ISP2401 firmware we're using, the code differences
are not that much from ISP2400. Cleanup the code in order
to make it closer to Intel Aero driver.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
There are two #ifdefs there which aren't defined anywhere.
So, just drop the dead code.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
There are several unused macros. Simplify the logic there, making
it closer to the Intel Aero driver and the corresponding firmware,
as this is what we have widely available for this device.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
This is defined as 64 for the devices/firmware that were chosen.
So, evaluate the macros accordingly.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
As we're using the firmware from Intel Aero, ensure that the
logic inside sh_css as similar as possible to such driver.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
There's a note at the uninit function that warns about issues
with mipi frames de-allocation. print a warning if the problem
ever happens.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Such function doesn't exist on Intel Aero driver. As we're using
its firmware, it may mean that this is not compatible with the
current file. So, drop it.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
There are some dead code meant to suppress "C_RUN" warnings.
Drop it from sh_css.c, as it doesn't make much sense.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
There's a commented dead code related to some future thing
to be implemented. As this won't happen, as it would require
a newer firmware, just drop the code.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
There are two versions of those functions. It turns that the
choosen firmware use the old version. So, drop the unused
ones and ensure that all devices will use the right functions.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
The Yocto Aero driver for ISP2401 sets my_css_save.loaded_fw.
As we're using the same firmware, remove the ifdef there.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Those two vars are meaningful only with some ISP2401 firmwares.
The one we chose to support doesn't use, so simply drop the
extra code.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
There are a couple of places where {} are used just to
define a new var. Just move the var to the top of the function
and get rid of that ugly blocks.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Use the coding style for the comments at this file.
While here, drop a do-nothing if logic.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Now that the input system always declare rx_cfg_t, we can
remove the ifdef ISP2401 from this header.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
There are several stucts under ISP2400 that could be moved
to the global file without causing any build issues.
Move those to the common header, in order to reduce the number
of things that are #ifdef dependent.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
