HACK: UAPI: Increasing VIDEO_MAX_FRAME/VB2_MAX_FRAME to 128
This is required because on TI SoC, the IVA_HD can consume as many as 32
buffers for some H.264 streams. And each buffer can contain plane/field
data as Y-top, Y-bottom, UV-top and UV-bottom. Each field will be
treated as a separate FRAME.
This is a hack because it is not upstream able as is. The
VIDEO_MAX_FRAME constant is also used for the older videobuf based
driver and we do not have any idea of the impact there. VB2_MAX_FRAME
was introduce earlier as a step but for now its value must match
VIDEO_MAX_FRAME, hence we are keeping them in-sync.
Please note that the buffer related internal structure in videobuf2 uses
array to keep track of buffers so this change increase their size
accordingly regardless of the fact that a specific driver/application
only needs 8 buffers for example. There was a discussion in the upstream
mailing list but nothing concrete so far: (see provided link)
http://www.spinics.net/lists/linux-media/msg81859.html
So this change is tentative until a better solution is available.
In addition increasing VIDEO_MAX_FRAME above 64 cause the zoran driver
to complain at compile time with the following messages:
In file included from drivers/media/pci/zoran/zoran_procfs.c:45:0:
>> drivers/media/pci/zoran/zoran.h:64:5: error: #error "Too many video
frame buffers to handle"
# error "Too many video frame buffers to handle"
^~~~~
In file included from drivers/media/pci/zoran/zoran_procfs.c:45:0:
>> drivers/media/pci/zoran/zoran.h:326:15: error: 'V4L_MAX_FRAME'
undeclared here (not in a function); did you mean 'V4L_MASK_FRAME'?
int v4l_pend[V4L_MAX_FRAME];
^~~~~~~~~~~~~
V4L_MASK_FRAME
We also need to HACK this driver to make the synthetic build succeed on
an architecture we don't normally support.
Based on Somnath's original patch.
Signed-off-by: Somnath Mukherjee <somnath@ti.com>
Signed-off-by: Nikhil Devshatwar <nikhil.nd@ti.com>
Signed-off-by: Benoit Parrot <bparrot@ti.com>
Benoit Parrot