Le mercredi 18 août 2021 à 19:40 +0530, sidraya.bj@xxxxxxxxxxxxxxxxxxx a écrit :
> From: Sidraya <sidraya.bj@xxxxxxxxxxxxxxxxxxx>
>
> The default color formats support only 8bit color depth. This patch
> adds 10bit definitions for NV12 and NV16.
>
> Signed-off-by: Sunita Nadampalli <sunitan@xxxxxx>
> Signed-off-by: Sidraya <sidraya.bj@xxxxxxxxxxxxxxxxxxx>
> ---
> drivers/media/v4l2-core/v4l2-ioctl.c | 2 ++
> include/uapi/linux/videodev2.h | 2 ++
> 2 files changed, 4 insertions(+)
>
> diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c b/drivers/media/v4l2-core/v4l2-ioctl.c
> index 05d5db3d85e5..445458c15168 100644
> --- a/drivers/media/v4l2-core/v4l2-ioctl.c
> +++ b/drivers/media/v4l2-core/v4l2-ioctl.c
> @@ -1367,6 +1367,8 @@ static void v4l_fill_fmtdesc(struct v4l2_fmtdesc *fmt)
> case V4L2_META_FMT_VIVID: descr = "Vivid Metadata"; break;
> case V4L2_META_FMT_RK_ISP1_PARAMS: descr = "Rockchip ISP1 3A Parameters"; break;
> case V4L2_META_FMT_RK_ISP1_STAT_3A: descr = "Rockchip ISP1 3A Statistics"; break;
> + case V4L2_PIX_FMT_TI1210: descr = "10-bit YUV 4:2:0 (NV12)"; break;
> + case V4L2_PIX_FMT_TI1610: descr = "10-bit YUV 4:2:2 (NV16)"; break;
>
> default:
> /* Compressed formats */
> diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
> index 9260791b8438..a71ffd686050 100644
> --- a/include/uapi/linux/videodev2.h
> +++ b/include/uapi/linux/videodev2.h
> @@ -737,6 +737,8 @@ struct v4l2_pix_format {
> #define V4L2_PIX_FMT_SUNXI_TILED_NV12 v4l2_fourcc('S', 'T', '1', '2') /* Sunxi Tiled NV12 Format */
> #define V4L2_PIX_FMT_CNF4 v4l2_fourcc('C', 'N', 'F', '4') /* Intel 4-bit packed depth confidence information */
> #define V4L2_PIX_FMT_HI240 v4l2_fourcc('H', 'I', '2', '4') /* BTTV 8-bit dithered RGB */
> +#define V4L2_PIX_FMT_TI1210 v4l2_fourcc('T', 'I', '1', '2') /* TI NV12 10-bit, two bytes per channel */
> +#define V4L2_PIX_FMT_TI1610 v4l2_fourcc('T', 'I', '1', '6') /* TI NV16 10-bit, two bytes per channel */
As we try and avoid past mistakes (consider HM12 and Sunxi Tiled format as an
example), what makes your pixel format 100% TI specific ? The only valid answer
is usually compression or a very odd pixel arrangement that only makes sense for
a specific HW, in any case, please provide all the information you can about
this format (tiling pattern, block size, compression is any). This way we can
judge if allocating a vendor format actually make sense. It would be sad if
this turns out to be just another 16x16 tiled format (yes, we have multiple
already).
>From past experience with OMAP, TI CODECs uses linear tiling very similar to all
other platforms, if that is the case, it should be added a generic format with
with enough documentation for a third party to understand it. Of course, if any
of the HW specification in this regard is public, please share or link to the
related documents.
>
> /* 10bit raw bayer packed, 32 bytes for every 25 pixels, last LSB 6 bits unused */
> #define V4L2_PIX_FMT_IPU3_SBGGR10 v4l2_fourcc('i', 'p', '3', 'b') /* IPU3 packed 10-bit BGGR bayer */
> --
> 2.17.1
>
>
