On Sat, Feb 20, 2021 at 3:56 PM Irui Wang [off-list ref] wrote:

On Wed, 2021-02-03 at 19:44 +0900, Alexandre Courbot wrote:

quoted

Hi Irui,

Thanks for pushing this forward. I had two small conflicts when
applying this patch to the media tree, so you may want to rebase
before sending the next version. Please see the comments inline.

On Thu, Jan 21, 2021 at 3:18 PM Irui Wang [off-list ref] wrote:

quoted

MTK H264 Encoder(VENC_SYS) and VP8 Encoder(VENC_LT_SYS) are two
independent hardware instance. They have their owner interrupt,
register mapping, and special clocks.

This patch seperates them into two drivers:

seperates -> separates

Also the patch does not result in two drivers, but two devices.

quoted

User Call "VIDIOC_QUERYCAP":
H264 Encoder return driver name "mtk-vcodec-enc";
VP8 Encoder return driver name "mtk-venc-vp8.

I wonder if we need to use two different names? The driver is the
same, so it makes sense to me that both devices return
"mtk-vcodec-enc". Userspace can then list the formats on the CAPTURE
queue in order to query the supported codecs.

I'm afraid we can't, there is a symlink when chrome use the
encoder(50-media.rules):
ATTR{name} == "mtk-vcodec-enc", SYMLINK+="video-enc"
ATTR{name} == "mtk-venc-vp8", SYMLINK+="video-enc0"
if we use the same name,how userspace access the encoder? maybe there
will be some modifications are needed in VEA(for example)?

Chrome OS can use a different udev rule to differentiate the two
nodes. Actually I already have a CL to support this:

https://chromium-review.googlesource.com/c/chromiumos/overlays/board-overlays/+/2673592

So both nodes being named the same won't be a problem for Chrome OS,
and makes more sense for an upstream merge anyway.

Cheers,
Alex.