mbox series

[v1,00/18] Add HANTRO G2/HEVC decoder support for IMX8MQ

Message ID 20210217080306.157876-1-benjamin.gaignard@collabora.com (mailing list archive)
Headers show
Series Add HANTRO G2/HEVC decoder support for IMX8MQ | expand

Message

Benjamin Gaignard Feb. 17, 2021, 8:02 a.m. UTC
The IMX8MQ got two VPUs but until now only G1 has been enabled.
This series aim to add the second VPU (aka G2) and provide basic 
HEVC decoding support.

To be able to decode HEVC it is needed to add/update some of the
structures in the uapi. In addition of them one HANTRO dedicated
control is required to inform the driver of the numbre of bits to skip
at the beginning of the slice header.
The hardware require to allocate few auxiliary buffers to store the
references frame, scaling list or tile size data.

The driver has been tested with fluster test suite stream.
For example with this command: ./fluster.py run -ts JCT-VC-HEVC_V1 -d GStreamer-H.265-V4L2SL-Gst1.0
 
This series depends of the reset rework posted here: https://www.spinics.net/lists/arm-kernel/msg875766.html

Finally the both VPUs will have a node the device-tree and be
independent from v4l2 point of view.

./v4l2-compliance -m 1 
v4l2-compliance 1.21.0-4705, 64 bits, 64-bit time_t
v4l2-compliance SHA: 733f7a54f79d 2021-02-03 08:25:49

Compliance test for hantro-vpu device /dev/media1:

Media Driver Info:
	Driver name      : hantro-vpu
	Model            : hantro-vpu
	Serial           : 
	Bus info         : platform: hantro-vpu
	Media version    : 5.11.0
	Hardware revision: 0x00000000 (0)
	Driver version   : 5.11.0

Required ioctls:
	test MEDIA_IOC_DEVICE_INFO: OK
	test invalid ioctls: OK

Allow for multiple opens:
	test second /dev/media1 open: OK
	test MEDIA_IOC_DEVICE_INFO: OK
	test for unlimited opens: OK

Media Controller ioctls:
	test MEDIA_IOC_G_TOPOLOGY: OK
	Entities: 3 Interfaces: 1 Pads: 4 Links: 4
	test MEDIA_IOC_ENUM_ENTITIES/LINKS: OK
	test MEDIA_IOC_SETUP_LINK: OK

Total for hantro-vpu device /dev/media1: 8, Succeeded: 8, Failed: 0, Warnings: 0
--------------------------------------------------------------------------------
Compliance test for hantro-vpu device /dev/video1:

Driver Info:
	Driver name      : hantro-vpu
	Card type        : nxp,imx8mq-vpu-g2-dec
	Bus info         : platform: hantro-vpu
	Driver version   : 5.11.0
	Capabilities     : 0x84204000
		Video Memory-to-Memory Multiplanar
		Streaming
		Extended Pix Format
		Device Capabilities
	Device Caps      : 0x04204000
		Video Memory-to-Memory Multiplanar
		Streaming
		Extended Pix Format
Media Driver Info:
	Driver name      : hantro-vpu
	Model            : hantro-vpu
	Serial           : 
	Bus info         : platform: hantro-vpu
	Media version    : 5.11.0
	Hardware revision: 0x00000000 (0)
	Driver version   : 5.11.0
Interface Info:
	ID               : 0x0300000c
	Type             : V4L Video
Entity Info:
	ID               : 0x00000001 (1)
	Name             : nxp,imx8mq-vpu-g2-dec-source
	Function         : V4L2 I/O
	Pad 0x01000002   : 0: Source
	  Link 0x02000008: to remote pad 0x1000004 of entity 'nxp,imx8mq-vpu-g2-dec-proc': Data, Enabled, Immutable

Required ioctls:
	test MC information (see 'Media Driver Info' above): OK
	test VIDIOC_QUERYCAP: OK
	test invalid ioctls: OK

Allow for multiple opens:
	test second /dev/video1 open: OK
	test VIDIOC_QUERYCAP: OK
	test VIDIOC_G/S_PRIORITY: OK
	test for unlimited opens: OK

Debug ioctls:
	test VIDIOC_DBG_G/S_REGISTER: OK (Not Supported)
	test VIDIOC_LOG_STATUS: OK (Not Supported)

Input ioctls:
	test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported)
	test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
	test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported)
	test VIDIOC_ENUMAUDIO: OK (Not Supported)
	test VIDIOC_G/S/ENUMINPUT: OK (Not Supported)
	test VIDIOC_G/S_AUDIO: OK (Not Supported)
	Inputs: 0 Audio Inputs: 0 Tuners: 0

Output ioctls:
	test VIDIOC_G/S_MODULATOR: OK (Not Supported)
	test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
	test VIDIOC_ENUMAUDOUT: OK (Not Supported)
	test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported)
	test VIDIOC_G/S_AUDOUT: OK (Not Supported)
	Outputs: 0 Audio Outputs: 0 Modulators: 0

Input/Output configuration ioctls:
	test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported)
	test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported)
	test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported)
	test VIDIOC_G/S_EDID: OK (Not Supported)

Control ioctls:
	test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK
	test VIDIOC_QUERYCTRL: OK
	test VIDIOC_G/S_CTRL: OK
	test VIDIOC_G/S/TRY_EXT_CTRLS: OK
	test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK
	test VIDIOC_G/S_JPEGCOMP: OK (Not Supported)
	Standard Controls: 10 Private Controls: 1

Format ioctls:
	test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK
	test VIDIOC_G/S_PARM: OK (Not Supported)
	test VIDIOC_G_FBUF: OK (Not Supported)
	test VIDIOC_G_FMT: OK
	test VIDIOC_TRY_FMT: OK
	test VIDIOC_S_FMT: OK
	test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported)
	test Cropping: OK (Not Supported)
	test Composing: OK (Not Supported)
	test Scaling: OK (Not Supported)

Codec ioctls:
	test VIDIOC_(TRY_)ENCODER_CMD: OK (Not Supported)
	test VIDIOC_G_ENC_INDEX: OK (Not Supported)
	test VIDIOC_(TRY_)DECODER_CMD: OK (Not Supported)

Buffer ioctls:
	test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: OK
	test VIDIOC_EXPBUF: OK
	test Requests: OK

Total for hantro-vpu device /dev/video1: 46, Succeeded: 46, Failed: 0, Warnings: 0

Grand Total for hantro-vpu device /dev/media1: 54, Succeeded: 54, Failed: 0, Warnings: 0

Benjamin
 
Benjamin Gaignard (18):
  include: media: hevc: Add scaling and decode params controls
  media: hantro: Define HEVC codec profiles and supported features
  arm64: dts: imx8mq-evk: add reserve memory node for CMA region
  media: hevc: add structures for hevc codec
  media: controls: Add control for HEVC codec
  media: hantro: Make sure that ctx->codex_ops is set
  media: hantro: Add a field to distinguish the hardware versions
  media: hantro: Add HEVC structures
  media: hantro: move hantro_needs_postproc function
  media: hantro: Add helper functions for buffer information
  media: hantro: Add helper function for auxiliary buffers allocation
  media: uapi: Add a control for HANTRO driver
  media: hantro: Introduce G2/HEVC decoder
  media: hantro: add G2 support to postproc
  media: hantro: handle V4L2_PIX_FMT_HEVC_SLICE control
  media: hantro: IMX8M: add variant for G2/HEVC codec
  dt-bindings: media: nxp,imx8mq-vpu: Update bindings
  arm64: dts: imx8mq: Add node to G2 hardware

 .../bindings/media/nxp,imx8mq-vpu.yaml        |  54 +-
 arch/arm64/boot/dts/freescale/imx8mq-evk.dts  |  15 +
 arch/arm64/boot/dts/freescale/imx8mq.dtsi     |  43 +-
 drivers/media/v4l2-core/v4l2-ctrls.c          |  36 +-
 drivers/staging/media/hantro/Makefile         |   2 +
 drivers/staging/media/hantro/hantro.h         |  58 +-
 drivers/staging/media/hantro/hantro_drv.c     | 110 ++-
 .../staging/media/hantro/hantro_g2_hevc_dec.c | 637 ++++++++++++++++++
 drivers/staging/media/hantro/hantro_g2_regs.h | 198 ++++++
 drivers/staging/media/hantro/hantro_hevc.c    | 274 ++++++++
 drivers/staging/media/hantro/hantro_hw.h      |  50 ++
 .../staging/media/hantro/hantro_postproc.c    |  52 +-
 drivers/staging/media/hantro/hantro_v4l2.c    |   3 +-
 drivers/staging/media/hantro/imx8m_vpu_hw.c   |  95 ++-
 drivers/staging/media/sunxi/cedrus/cedrus.c   |   6 +
 drivers/staging/media/sunxi/cedrus/cedrus.h   |   1 +
 .../staging/media/sunxi/cedrus/cedrus_dec.c   |   2 +
 .../staging/media/sunxi/cedrus/cedrus_h265.c  |   6 +-
 include/media/hevc-ctrls.h                    |  56 +-
 include/uapi/linux/hantro-v4l2-controls.h     |  20 +
 include/uapi/linux/v4l2-controls.h            |   5 +
 21 files changed, 1654 insertions(+), 69 deletions(-)
 create mode 100644 drivers/staging/media/hantro/hantro_g2_hevc_dec.c
 create mode 100644 drivers/staging/media/hantro/hantro_g2_regs.h
 create mode 100644 drivers/staging/media/hantro/hantro_hevc.c
 create mode 100644 include/uapi/linux/hantro-v4l2-controls.h

Comments

Greg Kroah-Hartman Feb. 17, 2021, 8:08 a.m. UTC | #1
On Wed, Feb 17, 2021 at 09:02:48AM +0100, Benjamin Gaignard wrote:
> The IMX8MQ got two VPUs but until now only G1 has been enabled.
> This series aim to add the second VPU (aka G2) and provide basic 
> HEVC decoding support.

Why are you adding this directly to drivers/staging/media/ and not
drivers/media/?  Why can't this just go to the main location and not
live in staging?

thanks,

greg k-h
Benjamin Gaignard Feb. 17, 2021, 8:28 a.m. UTC | #2
Le 17/02/2021 à 09:08, Greg KH a écrit :
> On Wed, Feb 17, 2021 at 09:02:48AM +0100, Benjamin Gaignard wrote:
>> The IMX8MQ got two VPUs but until now only G1 has been enabled.
>> This series aim to add the second VPU (aka G2) and provide basic
>> HEVC decoding support.
> Why are you adding this directly to drivers/staging/media/ and not
> drivers/media/?  Why can't this just go to the main location and not
> live in staging?

G2/HEVC is added inside the already exiting Hantro driver, it is "just"
an other codec from Hantro driver point of view.
In addition of that v4l2-hevc uAPI is still unstable.
One goal of this series is to have one more consumer of this v4l2-hevc
uAPI so maybe we can claim it to be stable enough to move away from staging
and then do the same for Hantro driver. That would be a great achievement !

Benjamin

> thanks,
>
> greg k-h
>
Greg Kroah-Hartman Feb. 17, 2021, 8:36 a.m. UTC | #3
On Wed, Feb 17, 2021 at 09:28:09AM +0100, Benjamin Gaignard wrote:
> 
> Le 17/02/2021 à 09:08, Greg KH a écrit :
> > On Wed, Feb 17, 2021 at 09:02:48AM +0100, Benjamin Gaignard wrote:
> > > The IMX8MQ got two VPUs but until now only G1 has been enabled.
> > > This series aim to add the second VPU (aka G2) and provide basic
> > > HEVC decoding support.
> > Why are you adding this directly to drivers/staging/media/ and not
> > drivers/media/?  Why can't this just go to the main location and not
> > live in staging?
> 
> G2/HEVC is added inside the already exiting Hantro driver, it is "just"
> an other codec from Hantro driver point of view.
> In addition of that v4l2-hevc uAPI is still unstable.
> One goal of this series is to have one more consumer of this v4l2-hevc
> uAPI so maybe we can claim it to be stable enough to move away from staging
> and then do the same for Hantro driver. That would be a great achievement !

I know I do not like seeing new additions/features/whatever being added
to staging drivers as that encourages people to do new stuff on them
without doing the real work needed to get them out of staging.

So what is preventing the existing driver from getting out of staging
now?

And how are you all creating new userspace apis for staging drivers to
the v4l layer?  What happens when you export something new and then
userspace starts to rely on it and then you change it?

Anyway, the media staging drivers are on their own, I don't touch them,
it just feels odd to me...

thanks,

greg k-h
Paul Kocialkowski Feb. 17, 2021, 8:38 a.m. UTC | #4
Hi Benjamin,

On Wed 17 Feb 21, 09:28, Benjamin Gaignard wrote:
> Le 17/02/2021 à 09:08, Greg KH a écrit :
> > On Wed, Feb 17, 2021 at 09:02:48AM +0100, Benjamin Gaignard wrote:
> > > The IMX8MQ got two VPUs but until now only G1 has been enabled.
> > > This series aim to add the second VPU (aka G2) and provide basic
> > > HEVC decoding support.
> > Why are you adding this directly to drivers/staging/media/ and not
> > drivers/media/?  Why can't this just go to the main location and not
> > live in staging?
> 
> G2/HEVC is added inside the already exiting Hantro driver, it is "just"
> an other codec from Hantro driver point of view.
> In addition of that v4l2-hevc uAPI is still unstable.
> One goal of this series is to have one more consumer of this v4l2-hevc
> uAPI so maybe we can claim it to be stable enough to move away from staging
> and then do the same for Hantro driver. That would be a great achievement !

Thanks for working on Hantro G2 support!

As the initial author of the HEVC API, it definitely does not feel ready to
be destaged. The API has lots of issues and limitation and I think significant
work is still needed.

This initial implementation was kind of a proof of concept for simple cases.

Cheers,

Paul
Hans Verkuil Feb. 17, 2021, 9:10 a.m. UTC | #5
On 17/02/2021 09:36, Greg KH wrote:
> On Wed, Feb 17, 2021 at 09:28:09AM +0100, Benjamin Gaignard wrote:
>>
>> Le 17/02/2021 à 09:08, Greg KH a écrit :
>>> On Wed, Feb 17, 2021 at 09:02:48AM +0100, Benjamin Gaignard wrote:
>>>> The IMX8MQ got two VPUs but until now only G1 has been enabled.
>>>> This series aim to add the second VPU (aka G2) and provide basic
>>>> HEVC decoding support.
>>> Why are you adding this directly to drivers/staging/media/ and not
>>> drivers/media/?  Why can't this just go to the main location and not
>>> live in staging?
>>
>> G2/HEVC is added inside the already exiting Hantro driver, it is "just"
>> an other codec from Hantro driver point of view.
>> In addition of that v4l2-hevc uAPI is still unstable.
>> One goal of this series is to have one more consumer of this v4l2-hevc
>> uAPI so maybe we can claim it to be stable enough to move away from staging
>> and then do the same for Hantro driver. That would be a great achievement !
> 
> I know I do not like seeing new additions/features/whatever being added
> to staging drivers as that encourages people to do new stuff on them
> without doing the real work needed to get them out of staging.

In order to support a specific codec (MPEG-2, H.264, HEVC, VP8, etc.) for
stateless codec hardware like the hantro, V4L2 controls need to be defined.
The contents of these controls is derived directly from the underlying codec
standards, but it is quite difficult to get this right with the first attempt,
since these standards are very complex.

So we went for the strategy of keeping these drivers in staging to make it
easy to work on, while keeping the APIs for each codec private (i.e., they are
not exposed in include/uapi/linux).

Once we have sufficient confidence in the API for a specific codec we move
it to uapi and thus fix the API. We also renumber the control IDs at that
time to avoid any confusion between the staging version and the final version.

We did that for H.264 and I hope we can soon do the same for MPEG-2 and VP8.

HEVC is definitely not ready for that yet.

The key phrase is 'sufficient confidence': one requirement is that it is supported
by at least two drivers to be reasonably certain the API doesn't contain any HW
specific stuff, and it passes test suites and review by codec experts.

All this is actively being worked on, so this is very much alive, but it is
complex and time consuming.

> So what is preventing the existing driver from getting out of staging
> now?

Once MPEG-2 and VP8 are finalized it is probably time to move these drivers
out of staging, while still keeping the HEVC API part private.

> 
> And how are you all creating new userspace apis for staging drivers to
> the v4l layer?  What happens when you export something new and then
> userspace starts to rely on it and then you change it?

Nothing is exported. So if userspace want to use it they have to manually
copy headers from include/media to their application.

> 
> Anyway, the media staging drivers are on their own, I don't touch them,
> it just feels odd to me...

It's an unusual situation. But putting the drivers in staging and keeping
the codec API headers private turns out to be the most effective way to
develop this.

Regards,

	Hans

PS: stateful vs stateless decoders: stateful decoders are fully supported
today: you just feed the decoder the compressed stream and the decoded frames
are produced by the firmware/hardware. I.e. the HW takes care of the decoder
state. Stateless decoders require you to pass the compressed frame + decoder
state to the hardware, so they do not keep track of the decoder state, that
needs to be done in software. And that requires structures to be created that
store the state, which luckily can be derived from the codec standards.
Greg Kroah-Hartman Feb. 17, 2021, 9:23 a.m. UTC | #6
On Wed, Feb 17, 2021 at 10:10:35AM +0100, Hans Verkuil wrote:
> On 17/02/2021 09:36, Greg KH wrote:
> > On Wed, Feb 17, 2021 at 09:28:09AM +0100, Benjamin Gaignard wrote:
> >>
> >> Le 17/02/2021 à 09:08, Greg KH a écrit :
> >>> On Wed, Feb 17, 2021 at 09:02:48AM +0100, Benjamin Gaignard wrote:
> >>>> The IMX8MQ got two VPUs but until now only G1 has been enabled.
> >>>> This series aim to add the second VPU (aka G2) and provide basic
> >>>> HEVC decoding support.
> >>> Why are you adding this directly to drivers/staging/media/ and not
> >>> drivers/media/?  Why can't this just go to the main location and not
> >>> live in staging?
> >>
> >> G2/HEVC is added inside the already exiting Hantro driver, it is "just"
> >> an other codec from Hantro driver point of view.
> >> In addition of that v4l2-hevc uAPI is still unstable.
> >> One goal of this series is to have one more consumer of this v4l2-hevc
> >> uAPI so maybe we can claim it to be stable enough to move away from staging
> >> and then do the same for Hantro driver. That would be a great achievement !
> > 
> > I know I do not like seeing new additions/features/whatever being added
> > to staging drivers as that encourages people to do new stuff on them
> > without doing the real work needed to get them out of staging.
> 
> In order to support a specific codec (MPEG-2, H.264, HEVC, VP8, etc.) for
> stateless codec hardware like the hantro, V4L2 controls need to be defined.
> The contents of these controls is derived directly from the underlying codec
> standards, but it is quite difficult to get this right with the first attempt,
> since these standards are very complex.
> 
> So we went for the strategy of keeping these drivers in staging to make it
> easy to work on, while keeping the APIs for each codec private (i.e., they are
> not exposed in include/uapi/linux).
> 
> Once we have sufficient confidence in the API for a specific codec we move
> it to uapi and thus fix the API. We also renumber the control IDs at that
> time to avoid any confusion between the staging version and the final version.
> 
> We did that for H.264 and I hope we can soon do the same for MPEG-2 and VP8.
> 
> HEVC is definitely not ready for that yet.
> 
> The key phrase is 'sufficient confidence': one requirement is that it is supported
> by at least two drivers to be reasonably certain the API doesn't contain any HW
> specific stuff, and it passes test suites and review by codec experts.
> 
> All this is actively being worked on, so this is very much alive, but it is
> complex and time consuming.
> 
> > So what is preventing the existing driver from getting out of staging
> > now?
> 
> Once MPEG-2 and VP8 are finalized it is probably time to move these drivers
> out of staging, while still keeping the HEVC API part private.
> 
> > 
> > And how are you all creating new userspace apis for staging drivers to
> > the v4l layer?  What happens when you export something new and then
> > userspace starts to rely on it and then you change it?
> 
> Nothing is exported. So if userspace want to use it they have to manually
> copy headers from include/media to their application.
> 
> > 
> > Anyway, the media staging drivers are on their own, I don't touch them,
> > it just feels odd to me...
> 
> It's an unusual situation. But putting the drivers in staging and keeping
> the codec API headers private turns out to be the most effective way to
> develop this.

Ah, ok, thanks for the explaination, makes sense.

good luck!

greg k-h