[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Yv7Gc+mSEXBnV0Oc@pendragon.ideasonboard.com>
Date: Fri, 19 Aug 2022 02:08:35 +0300
From: Laurent Pinchart <laurent.pinchart@...asonboard.com>
To: Hsia-Jun Li <randy.li@...aptics.com>
Cc: dri-devel@...ts.freedesktop.org, maarten.lankhorst@...ux.intel.com,
mripard@...nel.org, tzimmermann@...e.de, airlied@...ux.ie,
daniel@...ll.ch, mchehab@...nel.org, hverkuil-cisco@...all.nl,
ezequiel@...guardiasur.com.ar, sakari.ailus@...ux.intel.com,
ribalda@...omium.org, linux-media@...r.kernel.org,
linux-kernel@...r.kernel.org, tfiga@...omium.org,
sebastian.hesselbarth@...il.com, jszhang@...nel.org,
linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH 0/2] Add pixel formats used in Synatpics SoC
Hi Hsia-Jun,
On Tue, Aug 09, 2022 at 12:27:48AM +0800, Hsia-Jun Li wrote:
> From: "Hsia-Jun(Randy) Li" <randy.li@...aptics.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(+)
--
Regards,
Laurent Pinchart
Powered by blists - more mailing lists