| /openbmc/linux/drivers/media/platform/ |
| H A D | Makefile | 2c42cdba Wed Jul 22 06:23:03 CDT 2015 Mikhail Ulyanov <mikhail.ulyanov@cogentembedded.com> [media] V4L2: platform: Add Renesas R-Car JPEG codec driver
Here's the driver for the Renesas R-Car JPEG processing unit.
The driver is implemented within the V4L2 framework as a memory-to-memory
device. It presents two video nodes to userspace, one for the encoding part,
and one for the decoding part.
It was found that the only working mode for encoding is no markers output, so we
generate markers with software. In the current version of driver we also use
software JPEG header parsing because with hardware parsing performance is lower
than desired.
>From a userspace point of view the process is typical (S_FMT, REQBUF,
optionally QUERYBUF, QBUF, STREAMON, DQBUF) for both the source and destination
queues. STREAMON can return -EINVAL in case of mismatch of output and capture
queues format. Also during decoding driver can return buffers if queued
buffer with JPEG image contains image with inappropriate subsampling (e.g.
4:2:0 in JPEG and 4:2:2 in capture). If JPEG image and queue format dimensions
differ driver will return buffer on QBUF with VB2_BUF_STATE_ERROR flag.
During encoding the available formats are: V4L2_PIX_FMT_NV12M,
V4L2_PIX_FMT_NV12, V4L2_PIX_FMT_NV16, V4L2_PIX_FMT_NV16M for source and
V4L2_PIX_FMT_JPEG for destination.
During decoding the available formats are: V4L2_PIX_FMT_JPEG for source and
V4L2_PIX_FMT_NV12M, V4L2_PIX_FMT_NV16M, V4L2_PIX_FMT_NV12, V4L2_PIX_FMT_NV16
for destination.
Performance of current version:
1280x800 NV12 image encoding/decoding
decoding ~122 FPS
encoding ~191 FPS
Signed-off-by: Mikhail Ulyanov <mikhail.ulyanov@cogentembedded.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
2c42cdba Wed Jul 22 06:23:03 CDT 2015 Mikhail Ulyanov <mikhail.ulyanov@cogentembedded.com> [media] V4L2: platform: Add Renesas R-Car JPEG codec driver
Here's the driver for the Renesas R-Car JPEG processing unit.
The driver is implemented within the V4L2 framework as a memory-to-memory
device. It presents two video nodes to userspace, one for the encoding part,
and one for the decoding part.
It was found that the only working mode for encoding is no markers output, so we
generate markers with software. In the current version of driver we also use
software JPEG header parsing because with hardware parsing performance is lower
than desired.
>From a userspace point of view the process is typical (S_FMT, REQBUF,
optionally QUERYBUF, QBUF, STREAMON, DQBUF) for both the source and destination
queues. STREAMON can return -EINVAL in case of mismatch of output and capture
queues format. Also during decoding driver can return buffers if queued
buffer with JPEG image contains image with inappropriate subsampling (e.g.
4:2:0 in JPEG and 4:2:2 in capture). If JPEG image and queue format dimensions
differ driver will return buffer on QBUF with VB2_BUF_STATE_ERROR flag.
During encoding the available formats are: V4L2_PIX_FMT_NV12M,
V4L2_PIX_FMT_NV12, V4L2_PIX_FMT_NV16, V4L2_PIX_FMT_NV16M for source and
V4L2_PIX_FMT_JPEG for destination.
During decoding the available formats are: V4L2_PIX_FMT_JPEG for source and
V4L2_PIX_FMT_NV12M, V4L2_PIX_FMT_NV16M, V4L2_PIX_FMT_NV12, V4L2_PIX_FMT_NV16
for destination.
Performance of current version:
1280x800 NV12 image encoding/decoding
decoding ~122 FPS
encoding ~191 FPS
Signed-off-by: Mikhail Ulyanov <mikhail.ulyanov@cogentembedded.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
|
| H A D | Kconfig | 2c42cdba Wed Jul 22 06:23:03 CDT 2015 Mikhail Ulyanov <mikhail.ulyanov@cogentembedded.com> [media] V4L2: platform: Add Renesas R-Car JPEG codec driver
Here's the driver for the Renesas R-Car JPEG processing unit.
The driver is implemented within the V4L2 framework as a memory-to-memory
device. It presents two video nodes to userspace, one for the encoding part,
and one for the decoding part.
It was found that the only working mode for encoding is no markers output, so we
generate markers with software. In the current version of driver we also use
software JPEG header parsing because with hardware parsing performance is lower
than desired.
>From a userspace point of view the process is typical (S_FMT, REQBUF,
optionally QUERYBUF, QBUF, STREAMON, DQBUF) for both the source and destination
queues. STREAMON can return -EINVAL in case of mismatch of output and capture
queues format. Also during decoding driver can return buffers if queued
buffer with JPEG image contains image with inappropriate subsampling (e.g.
4:2:0 in JPEG and 4:2:2 in capture). If JPEG image and queue format dimensions
differ driver will return buffer on QBUF with VB2_BUF_STATE_ERROR flag.
During encoding the available formats are: V4L2_PIX_FMT_NV12M,
V4L2_PIX_FMT_NV12, V4L2_PIX_FMT_NV16, V4L2_PIX_FMT_NV16M for source and
V4L2_PIX_FMT_JPEG for destination.
During decoding the available formats are: V4L2_PIX_FMT_JPEG for source and
V4L2_PIX_FMT_NV12M, V4L2_PIX_FMT_NV16M, V4L2_PIX_FMT_NV12, V4L2_PIX_FMT_NV16
for destination.
Performance of current version:
1280x800 NV12 image encoding/decoding
decoding ~122 FPS
encoding ~191 FPS
Signed-off-by: Mikhail Ulyanov <mikhail.ulyanov@cogentembedded.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
2c42cdba Wed Jul 22 06:23:03 CDT 2015 Mikhail Ulyanov <mikhail.ulyanov@cogentembedded.com> [media] V4L2: platform: Add Renesas R-Car JPEG codec driver
Here's the driver for the Renesas R-Car JPEG processing unit.
The driver is implemented within the V4L2 framework as a memory-to-memory
device. It presents two video nodes to userspace, one for the encoding part,
and one for the decoding part.
It was found that the only working mode for encoding is no markers output, so we
generate markers with software. In the current version of driver we also use
software JPEG header parsing because with hardware parsing performance is lower
than desired.
>From a userspace point of view the process is typical (S_FMT, REQBUF,
optionally QUERYBUF, QBUF, STREAMON, DQBUF) for both the source and destination
queues. STREAMON can return -EINVAL in case of mismatch of output and capture
queues format. Also during decoding driver can return buffers if queued
buffer with JPEG image contains image with inappropriate subsampling (e.g.
4:2:0 in JPEG and 4:2:2 in capture). If JPEG image and queue format dimensions
differ driver will return buffer on QBUF with VB2_BUF_STATE_ERROR flag.
During encoding the available formats are: V4L2_PIX_FMT_NV12M,
V4L2_PIX_FMT_NV12, V4L2_PIX_FMT_NV16, V4L2_PIX_FMT_NV16M for source and
V4L2_PIX_FMT_JPEG for destination.
During decoding the available formats are: V4L2_PIX_FMT_JPEG for source and
V4L2_PIX_FMT_NV12M, V4L2_PIX_FMT_NV16M, V4L2_PIX_FMT_NV12, V4L2_PIX_FMT_NV16
for destination.
Performance of current version:
1280x800 NV12 image encoding/decoding
decoding ~122 FPS
encoding ~191 FPS
Signed-off-by: Mikhail Ulyanov <mikhail.ulyanov@cogentembedded.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
|