| Message ID | 20220808162750.828001-1-randy.li@synaptics.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Add pixel formats used in Synatpics SoC | expand |
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 ? > 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. [1] https://lore.kernel.org/linux-media/20170821155203.GB38943@e107564-lin.cambridge.arm.com/ [2] https://lore.kernel.org/linux-media/20200804192939.2251988-1-helen.koike@collabora.com/ > 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(+)
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
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. 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 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. 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(+)