From: Hsia-Jun Li <Randy.Li@synaptics.com>
To: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Tomasz Figa <tfiga@chromium.org>,
dri-devel@lists.freedesktop.org,
maarten.lankhorst@linux.intel.com, mripard@kernel.org,
tzimmermann@suse.de, airlied@linux.ie, daniel@ffwll.ch,
mchehab@kernel.org, hverkuil-cisco@xs4all.nl,
ezequiel@vanguardiasur.com.ar, sakari.ailus@linux.intel.com,
ribalda@chromium.org, linux-media@vger.kernel.org,
linux-kernel@vger.kernel.org, sebastian.hesselbarth@gmail.com,
jszhang@kernel.org, linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 2/2] [WIP]: media: Add Synaptics compressed tiled format
Date: Fri, 19 Aug 2022 07:51:03 +0800 [thread overview]
Message-ID: <871126cc-a3ca-2009-8f1d-a8eb5852e033@synaptics.com> (raw)
In-Reply-To: <Yv7HnHE7bLmgq5D0@pendragon.ideasonboard.com>
On 8/19/22 07:13, Laurent Pinchart wrote:
> CAUTION: Email originated externally, do not click links or open attachments unless you recognize the sender and know the content is safe.
>
>
> On Thu, Aug 18, 2022 at 02:33:42PM +0800, Hsia-Jun Li wrote:
>> On 8/18/22 14:06, Tomasz Figa wrote:
>>> On Tue, Aug 9, 2022 at 1:28 AM Hsia-Jun Li <randy.li@synaptics.com> wrote:
>>>>
>>>> From: "Hsia-Jun(Randy) Li" <randy.li@synaptics.com>
>>>>
>>>> The most of detail has been written in the drm.
>
> This patch still needs a description of the format, which should go to
> Documentation/userspace-api/media/v4l/.
I just want t tell people we need an extra plane for MVTP and I don't
have enough space here to place all the pixel formats.
Besides, I was thinking a modifer in v4l2_ext_pix_format is not enough.
Let's take a compression NV12 tile format as an example, we need
1. luma planes
2. chroma planes
3. compression meta data for luma
4. compression meta data for chroma
5. mvtp
and a single data planer version would be
1. luma and chroma data
2. compression meta data
3. mvtp
You see, we actually have 3 kind of data here(not including the
compression options that I am thinking of storing them somewhere else).
>
>>>> Please notice that the tiled formats here request
>>>> one more plane for storing the motion vector metadata.
>>>> This buffer won't be compressed, so you can't append
>>>> it to luma or chroma plane.
>>>
>>> Does the motion vector buffer need to be exposed to userspace? Is the
>>> decoder stateless (requires userspace to specify the reference frames)
>>> or stateful (manages the entire decoding process internally)?
>>
>> No, users don't need to access them at all. Just they need a different
>> dma-heap.
>>
>> You would only get the stateful version of both encoder and decoder.
>
> Shouldn't the motion vectors be stored in a separate V4L2 buffer,
> submitted through a different queue then ?
Yes, I like that.
Proposal: A third buffer type for the reconstruction buffers in V4L2 M2M
encoder
https://www.spinics.net/lists/linux-media/msg214565.html
Although the major usage for the decoder here is producing the non-tile
buffers, the decoder of us could product the NV12 or the pixel formats
that GPU likes, but it must happen at the same time a frame is decoded.
Still the reference buffer or we call them the real decoded frame would
stay in a tiled format. More than one queue would be need here.
>
>>>> Signed-off-by: Hsia-Jun(Randy) Li <randy.li@synaptics.com>
>>>> ---
>>>> drivers/media/v4l2-core/v4l2-common.c | 1 +
>>>> drivers/media/v4l2-core/v4l2-ioctl.c | 2 ++
>>>> include/uapi/linux/videodev2.h | 2 ++
>>>> 3 files changed, 5 insertions(+)
>>>>
>>>> diff --git a/drivers/media/v4l2-core/v4l2-common.c b/drivers/media/v4l2-core/v4l2-common.c
>>>> index e0fbe6ba4b6c..f645278b3055 100644
>>>> --- a/drivers/media/v4l2-core/v4l2-common.c
>>>> +++ b/drivers/media/v4l2-core/v4l2-common.c
>>>> @@ -314,6 +314,7 @@ const struct v4l2_format_info *v4l2_format_info(u32 format)
>>>> { .format = V4L2_PIX_FMT_SGBRG12, .pixel_enc = V4L2_PIXEL_ENC_BAYER, .mem_planes = 1, .comp_planes = 1, .bpp = { 2, 0, 0, 0 }, .hdiv = 1, .vdiv = 1 },
>>>> { .format = V4L2_PIX_FMT_SGRBG12, .pixel_enc = V4L2_PIXEL_ENC_BAYER, .mem_planes = 1, .comp_planes = 1, .bpp = { 2, 0, 0, 0 }, .hdiv = 1, .vdiv = 1 },
>>>> { .format = V4L2_PIX_FMT_SRGGB12, .pixel_enc = V4L2_PIXEL_ENC_BAYER, .mem_planes = 1, .comp_planes = 1, .bpp = { 2, 0, 0, 0 }, .hdiv = 1, .vdiv = 1 },
>>>> + { .format = V4L2_PIX_FMT_NV12M_V4H1C, .pixel_enc = V4L2_PIXEL_ENC_YUV, .mem_planes = 5, .comp_planes = 2, .bpp = { 1, 2, 0, 0 }, .hdiv = 2, .vdiv = 2, .block_w = { 128, 128 }, .block_h = { 128, 128 } },
>>>> };
>>>> unsigned int i;
>>>>
>>>> diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c b/drivers/media/v4l2-core/v4l2-ioctl.c
>>>> index e6fd355a2e92..8f65964aff08 100644
>>>> --- a/drivers/media/v4l2-core/v4l2-ioctl.c
>>>> +++ b/drivers/media/v4l2-core/v4l2-ioctl.c
>>>> @@ -1497,6 +1497,8 @@ static void v4l_fill_fmtdesc(struct v4l2_fmtdesc *fmt)
>>>> case V4L2_PIX_FMT_MT21C: descr = "Mediatek Compressed Format"; break;
>>>> case V4L2_PIX_FMT_QC08C: descr = "QCOM Compressed 8-bit Format"; break;
>>>> case V4L2_PIX_FMT_QC10C: descr = "QCOM Compressed 10-bit Format"; break;
>>>> + case V4L2_PIX_FMT_NV12M_V4H1C: descr = "Synaptics Compressed 8-bit tiled Format";break;
>>>> + case V4L2_PIX_FMT_NV12M_10_V4H3P8C: descr = "Synaptics Compressed 10-bit tiled Format";break;
>>>> default:
>>>> if (fmt->description[0])
>>>> return;
>>>> diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
>>>> index 01e630f2ec78..7e928cb69e7c 100644
>>>> --- a/include/uapi/linux/videodev2.h
>>>> +++ b/include/uapi/linux/videodev2.h
>>>> @@ -661,6 +661,8 @@ struct v4l2_pix_format {
>>>> #define V4L2_PIX_FMT_NV12MT_16X16 v4l2_fourcc('V', 'M', '1', '2') /* 12 Y/CbCr 4:2:0 16x16 tiles */
>>>> #define V4L2_PIX_FMT_NV12M_8L128 v4l2_fourcc('N', 'A', '1', '2') /* Y/CbCr 4:2:0 8x128 tiles */
>>>> #define V4L2_PIX_FMT_NV12M_10BE_8L128 v4l2_fourcc_be('N', 'T', '1', '2') /* Y/CbCr 4:2:0 10-bit 8x128 tiles */
>>>> +#define V4L2_PIX_FMT_NV12M_V4H1C v4l2_fourcc('S', 'Y', '1', '2') /* 12 Y/CbCr 4:2:0 tiles */
>>>> +#define V4L2_PIX_FMT_NV12M_10_V4H3P8C v4l2_fourcc('S', 'Y', '1', '0') /* 12 Y/CbCr 4:2:0 10-bits tiles */
>>>>
>>>> /* Bayer formats - see https://urldefense.proofpoint.com/v2/url?u=http-3A__www.siliconimaging.com_RGB-2520Bayer.htm&d=DwIBaQ&c=7dfBJ8cXbWjhc0BhImu8wVIoUFmBzj1s88r8EGyM0UY&r=P4xb2_7biqBxD4LGGPrSV6j-jf3C3xlR7PXU-mLTeZE&m=87M5Aa5fG3kdTTjlJrLIgv0E7O10QAj_4RqDlVsCAFdbfJzJ_P0s8wkBqaR0VBUO&s=8AsoiLPt9hQnn4ta51tT-RUXRLoKKYrePdAwtdvxuDo&e= */
>>>> #define V4L2_PIX_FMT_SBGGR8 v4l2_fourcc('B', 'A', '8', '1') /* 8 BGBG.. GRGR.. */
>
> --
> Regards,
>
> Laurent Pinchart
--
Hsia-Jun(Randy) Li
next prev parent reply other threads:[~2022-08-18 23:51 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-08 16:27 [PATCH 0/2] Add pixel formats used in Synatpics SoC Hsia-Jun Li
2022-08-08 16:27 ` [PATCH 1/2] drm/fourcc: Add Synaptics VideoSmart tiled modifiers Hsia-Jun Li
2022-08-18 6:07 ` Tomasz Figa
2022-08-18 6:49 ` Hsia-Jun Li
2022-08-18 23:16 ` Laurent Pinchart
2022-08-18 23:37 ` Hsia-Jun Li
2022-08-08 16:27 ` [PATCH 2/2] [WIP]: media: Add Synaptics compressed tiled format Hsia-Jun Li
2022-08-18 6:06 ` Tomasz Figa
2022-08-18 6:33 ` Hsia-Jun Li
2022-08-18 23:13 ` Laurent Pinchart
2022-08-18 23:51 ` Hsia-Jun Li [this message]
2022-08-19 15:28 ` Nicolas Dufresne
2022-08-19 15:44 ` Hsia-Jun Li
2022-08-19 19:17 ` Nicolas Dufresne
2022-08-20 0:10 ` Hsia-Jun Li
2022-08-22 14:15 ` Nicolas Dufresne
2022-08-23 7:40 ` Hsia-Jun Li
2022-08-23 13:44 ` Nicolas Dufresne
2022-08-23 6:05 ` Tomasz Figa
2022-08-23 7:03 ` Hsia-Jun Li
2022-08-23 14:02 ` Nicolas Dufresne
2022-08-19 15:26 ` Nicolas Dufresne
2022-08-18 23:08 ` [PATCH 0/2] Add pixel formats used in Synatpics SoC Laurent Pinchart
2022-08-18 23:28 ` Hsia-Jun Li
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=871126cc-a3ca-2009-8f1d-a8eb5852e033@synaptics.com \
--to=randy.li@synaptics.com \
--cc=airlied@linux.ie \
--cc=daniel@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=ezequiel@vanguardiasur.com.ar \
--cc=hverkuil-cisco@xs4all.nl \
--cc=jszhang@kernel.org \
--cc=laurent.pinchart@ideasonboard.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=maarten.lankhorst@linux.intel.com \
--cc=mchehab@kernel.org \
--cc=mripard@kernel.org \
--cc=ribalda@chromium.org \
--cc=sakari.ailus@linux.intel.com \
--cc=sebastian.hesselbarth@gmail.com \
--cc=tfiga@chromium.org \
--cc=tzimmermann@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox