Messages in this thread | | | Date | Fri, 19 Aug 2022 07:28:54 +0800 | Subject | Re: [PATCH 0/2] Add pixel formats used in Synatpics SoC | From | 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@synaptics.com> >> >> 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
| |