Length of H.264 headers is variable and thus it might not be
aligned for the coda to append the encoded frame. This causes
the first frame to overwrite part of the H.264 PPS.
In order to solve that, a filler NAL must be added between
the headers and the first frame to preserve alignment.
[mchehab@redhat.com: applied only v2 diff here, as v1 ended by mistakenly
being applied]
Signed-off-by: Javier Martin <javier.martin@vista-silicon.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Length of H.264 headers is variable and thus it might not be
aligned for the coda to append the encoded frame. This causes
the first frame to overwrite part of the H.264 PPS.
In order to solve that, a filler NAL must be added between
the headers and the first frame to preserve alignment.
[mchehab@redhat.com: Fix a few CodingStyle issues]
Signed-off-by: Javier Martin <javier.martin@vista-silicon.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
CODA_7541 is the coda_product type for mx53.
The 'driver_data' for mx53 is CODA_IMX53 instead.
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
commit 136b5721d (workqueue: deprecate __cancel_delayed_work()) made
__cancel_delayed_work deprecated. Use cancel_delayed_work instead and get rid of
the following warning:
drivers/media/platform/coda.c:1543: warning: '__cancel_delayed_work' is deprecated (declared at include/linux/workqueue.h:437)
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Acked-by: Tejun Heo <tj@kernel.org>
Acked-by: Javier Martin <javier.martin@vista-silicon.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This fixes a failure in vb2_qbuf in user pointer mode where
__qbuf_userptr checks if the buffer queued by userspace is large
enough. The failure would happen if coda_queue_setup was called
with empty fmt (and thus set the expected buffer size to the maximum
resolution), and userspace queues buffers of smaller size -
corresponding to the negotiated dimensions - were queued.
Explicitly setting sizeimage to the value negotiated via s_fmt
fixes the issue.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Acked-by: Javier Martin <javier.martin@vista-silicon.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Tested-by: Javier Martin <javier.martin@vista-silicon.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The hardware can also rotate in 90° steps, but there is no
corresponding V4L2_CID defined yet.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Tested-by: Javier Martin <javier.martin@vista-silicon.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
While the CODA is running a PIC_RUN command, its registers are
not to be touched.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Tested-by: Javier Martin <javier.martin@vista-silicon.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
USERPTR buffer support is provided by the videobuf2 framework.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Acked-by: Javier Martin <javier.martin@vista-silicon.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Add a 1 second timeout for each PIC_RUN command to the CODA. In
case it locks up, stop all queues and dequeue remaining buffers.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Tested-by: Javier Martin <javier.martin@vista-silicon.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Determining the next free instance just by incrementing and decrementing
an instance counter does not work: if there are two instances opened,
0 and 1, and instance 0 is released, the next call to coda_open will
create a new instance with index 1, but instance 1 is already in use.
Instead, scan a bitfield of active instances to determine the first
free instance index.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Tested-by: Javier Martin <javier.martin@vista-silicon.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
job_ready is supposed to signal whether a context is ready to be
added to the job queue, not whether the CODA is ready to run it
immediately.
Calling v4l2_m2m_job_finish at the end of coda_irq_handler already
guarantees that the coda is ready when v4l2-mem2mem eventually tries
to run the next queued job.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Tested-by: Javier Martin <javier.martin@vista-silicon.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Some codecs running on CODA need internal framebuffers for reference and
reconstructed frames. Allocate them separately, and do not use the input
vb2_buffers: those will be handed off to userspace regularly, and there
is no way to signal to the CODA which of the registered framebuffers are
off limits. As a consequence, userspace is now free to choose the number
of v4l2 buffers.
This patch also includes the code to set up the parameter buffer for
CODA7 and above with 64-bit AXI bus width.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Reviewed-by: Javier Martin <javier.martin@vista-silicon.com>
Tested-by: Javier Martin <javier.martin@vista-silicon.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This uses the ARCH_MXC specific iram_alloc API to allocate a work
buffer in the SoC's on-chip SRAM and sets up the AXI_SRAM_USE
register. In the future, the allocation will be converted to use
the genalloc API.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Tested-by: Javier Martin <javier.martin@vista-silicon.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Tested-by: Javier Martin <javier.martin@vista-silicon.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Add support for loading a raw firmware with 16-bit chars ordered in
little-endian 64-bit words, corresponding to the memory access pattern
of CODA7 and above: When writing the boot code into the code download
register, the chars have to be reordered back.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Tested-by: Javier Martin <javier.martin@vista-silicon.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
New mem-to-mem video drivers should use V4L2_CAP_VIDEO_M2M capability, rather
than ORed V4L2_CAP_VIDEO_CAPTURE and V4L2_CAP_VIDEO_OUTPUT flags, as outlined
in commit a1367f1b26.
Signed-off-by: Sylwester Nawrocki <sylvester.nawrocki@gmail.com>
Acked-by: Javier Martin <javier.martin@vista-silicon.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
queue_init() is always called by v4l2_m2m_ctx_init(), which allocates
a context struct v4l2_m2m_ctx with kzalloc.
Therefore, there is no need to clear vb2_queue src/dst structs.
Signed-off-by: Ezequiel Garcia <elezegarcia@gmail.com>
Acked-by: Javier Martin <javier.martin@vista-silicon.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: Richard Zhao <richard.zhao@freescale.com>
Acked-by: Javier Martin <javier.martin@vista-silicon.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The commit 98d7bbb9 changed *of_device_id.data to const
which introduced warnings in various places that have mostly
been fixed. This patch fixes one such warning by introducing
two const qualifiers.
GCC warning:
drivers/media/platform/coda.c:1785:16: warning:
assignment discards ‘const’ qualifier
from pointer target type [enabled by default]
Signed-off-by: Emil Goode <emilgoode@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The remaining drivers are mostly platform drivers. Name the
dir to reflect it.
It makes sense to latter break it into a few other dirs.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>