Re: [PATCH 0/2] Add pixel formats used in Synatpics SoC

[Hsia-Jun Li]

On 8/19/22 07:08, 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.
>
>
> Hi Hsia-Jun,
>
> On Tue, Aug 09, 2022 at 12:27:48AM +0800, Hsia-Jun Li wrote:
> > From: "Hsia-Jun(Randy) Li" <randy.li@xxxxxxxxxxxxx>
> >
> > Those pixel formats are used in Synaptics's VideoSmart series SoCs,
> > likes VS640, VS680.  I just disclose the pixel formats used in the video
> > codecs and display pipeline this time. Actually any device with a MTR
> > module could support those tiled and compressed pixel formats. The more
> > detail about MTR module could be found in the first patch of this serial
> > of mail.
> >
> > We may not be able to post any drivers here in a short time, the most of
> > work in this platform is done in the Trusted Execution Environment and
> > we didn't use the optee framework.
>
> Is that so for the display side too, or only for the video decoder ?
These pixel formats are using in both video decoder and display(Not the 
GPU). Besides, ISP and NPU in vs680 support some patterns of them.

Please notice that after I reviewed the compression options of our 
platform, I found using modifies are not enough to store all the 
compression options here. I would post a second version here.

I may use the same way that Intel, I would try to disclose more details 
here, hoping we could find a better way to describe them.
> > Please notice that, the memory planes used for video codecs would be 5
> > when the compression is invoked while it would be 4 for display, the
> > extra planes in the video codecs is for the decoding internally usage,
> > it can't append the luma or chroma buffer as many other drivers do,
> > because this buffer could be only accessed by the video codecs itself,
> > it requests a different memory security attributes. Any other reason is
> > described in the v4l pixel formats's patch. I don't know whether a
> > different numbers of memory planes between drm and v4l2 is acceptable.
>
> I don't think that's a problem as such, as long as both the V4L2 and DRM
> formats make sense on their own.
>
> > I only posted the compression fourcc for the v4l2, because it is really
> > hard to put the uncompression version of pixel formats under the fourcc.
> > I would be better that we could have something likes format modifers in
> > drm here.
>
> Agreed, we need modifiers support in V4L2. This has been discussed
> previously ([1]), and a proposal ([2]) has been submitted two years ago,
> it needs to be revived.
Thank you, I have found those v4l2_ext_pix_format, I would relay my 
comment in the email that posting synaptics v4l2 pixel formats.
> [1] https://urldefense.proofpoint.com/v2/url?u=https-3A__lore.kernel.org_linux-2Dmedia_20170821155203.GB38943-40e107564-2Dlin.cambridge.arm.com_&d=DwIBaQ&c=7dfBJ8cXbWjhc0BhImu8wVIoUFmBzj1s88r8EGyM0UY&r=P4xb2_7biqBxD4LGGPrSV6j-jf3C3xlR7PXU-mLTeZE&m=Ktu-e-R1Mn89Laxioh6RlL6Y2aycZ9NrJTIyONaDdRQvnlv-Nd570KldQ51vmigK&s=_7eMTIYwWUOWkXijcRfotLJlpR7G5yx-ZXuTwh9uZw4&e=
> [2] https://urldefense.proofpoint.com/v2/url?u=https-3A__lore.kernel.org_linux-2Dmedia_20200804192939.2251988-2D1-2Dhelen.koike-40collabora.com_&d=DwIBaQ&c=7dfBJ8cXbWjhc0BhImu8wVIoUFmBzj1s88r8EGyM0UY&r=P4xb2_7biqBxD4LGGPrSV6j-jf3C3xlR7PXU-mLTeZE&m=Ktu-e-R1Mn89Laxioh6RlL6Y2aycZ9NrJTIyONaDdRQvnlv-Nd570KldQ51vmigK&s=f1dbc5ciUeIkO6VMtlRuEvXqJad2NsoaDBFyNUsSdpg&e=
>
> > https://synaptics.com/products/multimedia-solutions
> >
> > Hsia-Jun(Randy) Li (2):
> >    drm/fourcc: Add Synaptics VideoSmart tiled modifiers
> >    [WIP]: media: Add Synaptics compressed tiled format
> >
> >   drivers/media/v4l2-core/v4l2-common.c |  1 +
> >   drivers/media/v4l2-core/v4l2-ioctl.c  |  2 ++
> >   include/uapi/drm/drm_fourcc.h         | 49 +++++++++++++++++++++++++++
> >   include/uapi/linux/videodev2.h        |  2 ++
> >   4 files changed, 54 insertions(+)
>
> --
> Regards,
>
> Laurent Pinchart

--
Hsia-Jun(Randy) Li