All of lore.kernel.org
 help / color / mirror / Atom feed
From: Randy Li <randy.li@rock-chips.com>
To: linux-media@vger.kernel.org
Cc: Randy Li <randy.li@rock-chips.com>,
	ayaka@soulik.info, hverkuil@xs4all.nl, maxime.ripard@bootlin.com,
	joro@8bytes.org, linux-kernel@vger.kernel.org,
	jernej.skrabec@gmail.com, nicolas@ndufresne.ca,
	paul.kocialkowski@bootlin.com,
	linux-rockchip@lists.infradead.org, thomas.petazzoni@bootlin.com,
	mchehab@kernel.org, ezequiel@collabora.com,
	linux-arm-kernel@lists.infradead.org, posciak@chromium.org,
	groeck@chromium.org
Subject: [PATCH v2 0/6] [WIP]: rockchip mpp for v4l2 video deocder
Date: Thu,  7 Mar 2019 18:03:10 +0800	[thread overview]
Message-ID: <20190307100316.925-1-randy.li@rock-chips.com> (raw)

Although I really want to push those work after I added more codec
supports, but I found it is more urge to do those in v4l2 core framework and
userspace.

I would use this driver to present the current problems, write down a
summary here and I would reply to those threads later to push forward.

1. Slice construction is a bad idea. I think I have said my reason in
the IRC and mail before, vp9 is always good example.

And it would request the driver to update QP table/CABAC table every
slice.

I would make something to describe a buffer with some addtional meta
data.

But the current request API limit a buffer with associated with
an request buffer, which prevent sharing some sequence data, but it 
still can solve some problems.

2. Advantage DMA memory control.
I think I need to do some work at v4l2 core.

2.1 The DMA address of each planes. I have sent a mail before talked
about why multiple planes is necessary for the rockchip platform. And
it maybe required by the other platforms.

2.2 IOMMU resume
The most effective way to restore the decoder from critical error is
doing a restting  by reset controller.
Which would leading its slave IOMMU reset at the same time. Then none of
those v4l2 buffers are mapping in the IOMMU.

3. H.264 and HEVC header
I still think those structure have some not necessary fileds in dpb or
reference part, which I don't think hardware decoder would care about
that or can be predict from the other information.

I would join to talk later.

4. The work flow of V4L2
I need a method to prepare the register set before the device acutally
begin the transaction. Which is necessary for those high frame rate usecase.

Also it is useful for those device would share some hardware resources
with the other device and it can save more power.

I think I need to do some work at v4l2 core.

Randy Li (6):
  arm64: dts: rockchip: add power domain to iommu
  staging: video: rockchip: add v4l2 decoder
  [TEST]: rockchip: mpp: support qptable
  staging: video: rockchip: add video codec
  arm64: dts: rockchip: boost clocks for rk3328
  arm64: dts: rockchip: add video codec for rk3328

 .../arm64/boot/dts/rockchip/rk3328-rock64.dts |   32 +
 arch/arm64/boot/dts/rockchip/rk3328.dtsi      |  116 +-
 arch/arm64/boot/dts/rockchip/rk3399.dtsi      |    2 +
 drivers/staging/Kconfig                       |    2 +
 drivers/staging/Makefile                      |    1 +
 drivers/staging/rockchip-mpp/Kconfig          |   34 +
 drivers/staging/rockchip-mpp/Makefile         |   10 +
 drivers/staging/rockchip-mpp/mpp_debug.h      |   87 ++
 drivers/staging/rockchip-mpp/mpp_dev_common.c | 1367 +++++++++++++++++
 drivers/staging/rockchip-mpp/mpp_dev_common.h |  212 +++
 drivers/staging/rockchip-mpp/mpp_dev_rkvdec.c |  997 ++++++++++++
 drivers/staging/rockchip-mpp/mpp_dev_vdpu2.c  |  619 ++++++++
 drivers/staging/rockchip-mpp/mpp_service.c    |  197 +++
 drivers/staging/rockchip-mpp/mpp_service.h    |   38 +
 drivers/staging/rockchip-mpp/rkvdec/hal.h     |   63 +
 drivers/staging/rockchip-mpp/rkvdec/hevc.c    |  166 ++
 drivers/staging/rockchip-mpp/rkvdec/regs.h    |  608 ++++++++
 drivers/staging/rockchip-mpp/vdpu2/hal.h      |   52 +
 drivers/staging/rockchip-mpp/vdpu2/mpeg2.c    |  277 ++++
 drivers/staging/rockchip-mpp/vdpu2/regs.h     |  699 +++++++++
 20 files changed, 5575 insertions(+), 4 deletions(-)
 create mode 100644 drivers/staging/rockchip-mpp/Kconfig
 create mode 100644 drivers/staging/rockchip-mpp/Makefile
 create mode 100644 drivers/staging/rockchip-mpp/mpp_debug.h
 create mode 100644 drivers/staging/rockchip-mpp/mpp_dev_common.c
 create mode 100644 drivers/staging/rockchip-mpp/mpp_dev_common.h
 create mode 100644 drivers/staging/rockchip-mpp/mpp_dev_rkvdec.c
 create mode 100644 drivers/staging/rockchip-mpp/mpp_dev_vdpu2.c
 create mode 100644 drivers/staging/rockchip-mpp/mpp_service.c
 create mode 100644 drivers/staging/rockchip-mpp/mpp_service.h
 create mode 100644 drivers/staging/rockchip-mpp/rkvdec/hal.h
 create mode 100644 drivers/staging/rockchip-mpp/rkvdec/hevc.c
 create mode 100644 drivers/staging/rockchip-mpp/rkvdec/regs.h
 create mode 100644 drivers/staging/rockchip-mpp/vdpu2/hal.h
 create mode 100644 drivers/staging/rockchip-mpp/vdpu2/mpeg2.c
 create mode 100644 drivers/staging/rockchip-mpp/vdpu2/regs.h

-- 
2.20.1




WARNING: multiple messages have this Message-ID (diff)
From: Randy Li <randy.li@rock-chips.com>
To: linux-media@vger.kernel.org
Cc: paul.kocialkowski@bootlin.com, maxime.ripard@bootlin.com,
	joro@8bytes.org, ayaka@soulik.info,
	Randy Li <randy.li@rock-chips.com>,
	linux-kernel@vger.kernel.org, jernej.skrabec@gmail.com,
	nicolas@ndufresne.ca, hverkuil@xs4all.nl,
	linux-rockchip@lists.infradead.org, posciak@chromium.org,
	thomas.petazzoni@bootlin.com, groeck@chromium.org,
	mchehab@kernel.org, ezequiel@collabora.com,
	linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 0/6] [WIP]: rockchip mpp for v4l2 video deocder
Date: Thu,  7 Mar 2019 18:03:10 +0800	[thread overview]
Message-ID: <20190307100316.925-1-randy.li@rock-chips.com> (raw)

Although I really want to push those work after I added more codec
supports, but I found it is more urge to do those in v4l2 core framework and
userspace.

I would use this driver to present the current problems, write down a
summary here and I would reply to those threads later to push forward.

1. Slice construction is a bad idea. I think I have said my reason in
the IRC and mail before, vp9 is always good example.

And it would request the driver to update QP table/CABAC table every
slice.

I would make something to describe a buffer with some addtional meta
data.

But the current request API limit a buffer with associated with
an request buffer, which prevent sharing some sequence data, but it 
still can solve some problems.

2. Advantage DMA memory control.
I think I need to do some work at v4l2 core.

2.1 The DMA address of each planes. I have sent a mail before talked
about why multiple planes is necessary for the rockchip platform. And
it maybe required by the other platforms.

2.2 IOMMU resume
The most effective way to restore the decoder from critical error is
doing a restting  by reset controller.
Which would leading its slave IOMMU reset at the same time. Then none of
those v4l2 buffers are mapping in the IOMMU.

3. H.264 and HEVC header
I still think those structure have some not necessary fileds in dpb or
reference part, which I don't think hardware decoder would care about
that or can be predict from the other information.

I would join to talk later.

4. The work flow of V4L2
I need a method to prepare the register set before the device acutally
begin the transaction. Which is necessary for those high frame rate usecase.

Also it is useful for those device would share some hardware resources
with the other device and it can save more power.

I think I need to do some work at v4l2 core.

Randy Li (6):
  arm64: dts: rockchip: add power domain to iommu
  staging: video: rockchip: add v4l2 decoder
  [TEST]: rockchip: mpp: support qptable
  staging: video: rockchip: add video codec
  arm64: dts: rockchip: boost clocks for rk3328
  arm64: dts: rockchip: add video codec for rk3328

 .../arm64/boot/dts/rockchip/rk3328-rock64.dts |   32 +
 arch/arm64/boot/dts/rockchip/rk3328.dtsi      |  116 +-
 arch/arm64/boot/dts/rockchip/rk3399.dtsi      |    2 +
 drivers/staging/Kconfig                       |    2 +
 drivers/staging/Makefile                      |    1 +
 drivers/staging/rockchip-mpp/Kconfig          |   34 +
 drivers/staging/rockchip-mpp/Makefile         |   10 +
 drivers/staging/rockchip-mpp/mpp_debug.h      |   87 ++
 drivers/staging/rockchip-mpp/mpp_dev_common.c | 1367 +++++++++++++++++
 drivers/staging/rockchip-mpp/mpp_dev_common.h |  212 +++
 drivers/staging/rockchip-mpp/mpp_dev_rkvdec.c |  997 ++++++++++++
 drivers/staging/rockchip-mpp/mpp_dev_vdpu2.c  |  619 ++++++++
 drivers/staging/rockchip-mpp/mpp_service.c    |  197 +++
 drivers/staging/rockchip-mpp/mpp_service.h    |   38 +
 drivers/staging/rockchip-mpp/rkvdec/hal.h     |   63 +
 drivers/staging/rockchip-mpp/rkvdec/hevc.c    |  166 ++
 drivers/staging/rockchip-mpp/rkvdec/regs.h    |  608 ++++++++
 drivers/staging/rockchip-mpp/vdpu2/hal.h      |   52 +
 drivers/staging/rockchip-mpp/vdpu2/mpeg2.c    |  277 ++++
 drivers/staging/rockchip-mpp/vdpu2/regs.h     |  699 +++++++++
 20 files changed, 5575 insertions(+), 4 deletions(-)
 create mode 100644 drivers/staging/rockchip-mpp/Kconfig
 create mode 100644 drivers/staging/rockchip-mpp/Makefile
 create mode 100644 drivers/staging/rockchip-mpp/mpp_debug.h
 create mode 100644 drivers/staging/rockchip-mpp/mpp_dev_common.c
 create mode 100644 drivers/staging/rockchip-mpp/mpp_dev_common.h
 create mode 100644 drivers/staging/rockchip-mpp/mpp_dev_rkvdec.c
 create mode 100644 drivers/staging/rockchip-mpp/mpp_dev_vdpu2.c
 create mode 100644 drivers/staging/rockchip-mpp/mpp_service.c
 create mode 100644 drivers/staging/rockchip-mpp/mpp_service.h
 create mode 100644 drivers/staging/rockchip-mpp/rkvdec/hal.h
 create mode 100644 drivers/staging/rockchip-mpp/rkvdec/hevc.c
 create mode 100644 drivers/staging/rockchip-mpp/rkvdec/regs.h
 create mode 100644 drivers/staging/rockchip-mpp/vdpu2/hal.h
 create mode 100644 drivers/staging/rockchip-mpp/vdpu2/mpeg2.c
 create mode 100644 drivers/staging/rockchip-mpp/vdpu2/regs.h

-- 
2.20.1

WARNING: multiple messages have this Message-ID (diff)
From: Randy Li <randy.li@rock-chips.com>
To: linux-media@vger.kernel.org
Cc: paul.kocialkowski@bootlin.com, maxime.ripard@bootlin.com,
	joro@8bytes.org, ayaka@soulik.info,
	Randy Li <randy.li@rock-chips.com>,
	linux-kernel@vger.kernel.org, jernej.skrabec@gmail.com,
	nicolas@ndufresne.ca, hverkuil@xs4all.nl,
	linux-rockchip@lists.infradead.org, posciak@chromium.org,
	thomas.petazzoni@bootlin.com, groeck@chromium.org,
	mchehab@kernel.org, ezequiel@collabora.com,
	linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 0/6] [WIP]: rockchip mpp for v4l2 video deocder
Date: Thu,  7 Mar 2019 18:03:10 +0800	[thread overview]
Message-ID: <20190307100316.925-1-randy.li@rock-chips.com> (raw)

Although I really want to push those work after I added more codec
supports, but I found it is more urge to do those in v4l2 core framework and
userspace.

I would use this driver to present the current problems, write down a
summary here and I would reply to those threads later to push forward.

1. Slice construction is a bad idea. I think I have said my reason in
the IRC and mail before, vp9 is always good example.

And it would request the driver to update QP table/CABAC table every
slice.

I would make something to describe a buffer with some addtional meta
data.

But the current request API limit a buffer with associated with
an request buffer, which prevent sharing some sequence data, but it 
still can solve some problems.

2. Advantage DMA memory control.
I think I need to do some work at v4l2 core.

2.1 The DMA address of each planes. I have sent a mail before talked
about why multiple planes is necessary for the rockchip platform. And
it maybe required by the other platforms.

2.2 IOMMU resume
The most effective way to restore the decoder from critical error is
doing a restting  by reset controller.
Which would leading its slave IOMMU reset at the same time. Then none of
those v4l2 buffers are mapping in the IOMMU.

3. H.264 and HEVC header
I still think those structure have some not necessary fileds in dpb or
reference part, which I don't think hardware decoder would care about
that or can be predict from the other information.

I would join to talk later.

4. The work flow of V4L2
I need a method to prepare the register set before the device acutally
begin the transaction. Which is necessary for those high frame rate usecase.

Also it is useful for those device would share some hardware resources
with the other device and it can save more power.

I think I need to do some work at v4l2 core.

Randy Li (6):
  arm64: dts: rockchip: add power domain to iommu
  staging: video: rockchip: add v4l2 decoder
  [TEST]: rockchip: mpp: support qptable
  staging: video: rockchip: add video codec
  arm64: dts: rockchip: boost clocks for rk3328
  arm64: dts: rockchip: add video codec for rk3328

 .../arm64/boot/dts/rockchip/rk3328-rock64.dts |   32 +
 arch/arm64/boot/dts/rockchip/rk3328.dtsi      |  116 +-
 arch/arm64/boot/dts/rockchip/rk3399.dtsi      |    2 +
 drivers/staging/Kconfig                       |    2 +
 drivers/staging/Makefile                      |    1 +
 drivers/staging/rockchip-mpp/Kconfig          |   34 +
 drivers/staging/rockchip-mpp/Makefile         |   10 +
 drivers/staging/rockchip-mpp/mpp_debug.h      |   87 ++
 drivers/staging/rockchip-mpp/mpp_dev_common.c | 1367 +++++++++++++++++
 drivers/staging/rockchip-mpp/mpp_dev_common.h |  212 +++
 drivers/staging/rockchip-mpp/mpp_dev_rkvdec.c |  997 ++++++++++++
 drivers/staging/rockchip-mpp/mpp_dev_vdpu2.c  |  619 ++++++++
 drivers/staging/rockchip-mpp/mpp_service.c    |  197 +++
 drivers/staging/rockchip-mpp/mpp_service.h    |   38 +
 drivers/staging/rockchip-mpp/rkvdec/hal.h     |   63 +
 drivers/staging/rockchip-mpp/rkvdec/hevc.c    |  166 ++
 drivers/staging/rockchip-mpp/rkvdec/regs.h    |  608 ++++++++
 drivers/staging/rockchip-mpp/vdpu2/hal.h      |   52 +
 drivers/staging/rockchip-mpp/vdpu2/mpeg2.c    |  277 ++++
 drivers/staging/rockchip-mpp/vdpu2/regs.h     |  699 +++++++++
 20 files changed, 5575 insertions(+), 4 deletions(-)
 create mode 100644 drivers/staging/rockchip-mpp/Kconfig
 create mode 100644 drivers/staging/rockchip-mpp/Makefile
 create mode 100644 drivers/staging/rockchip-mpp/mpp_debug.h
 create mode 100644 drivers/staging/rockchip-mpp/mpp_dev_common.c
 create mode 100644 drivers/staging/rockchip-mpp/mpp_dev_common.h
 create mode 100644 drivers/staging/rockchip-mpp/mpp_dev_rkvdec.c
 create mode 100644 drivers/staging/rockchip-mpp/mpp_dev_vdpu2.c
 create mode 100644 drivers/staging/rockchip-mpp/mpp_service.c
 create mode 100644 drivers/staging/rockchip-mpp/mpp_service.h
 create mode 100644 drivers/staging/rockchip-mpp/rkvdec/hal.h
 create mode 100644 drivers/staging/rockchip-mpp/rkvdec/hevc.c
 create mode 100644 drivers/staging/rockchip-mpp/rkvdec/regs.h
 create mode 100644 drivers/staging/rockchip-mpp/vdpu2/hal.h
 create mode 100644 drivers/staging/rockchip-mpp/vdpu2/mpeg2.c
 create mode 100644 drivers/staging/rockchip-mpp/vdpu2/regs.h

-- 
2.20.1




_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

             reply	other threads:[~2019-03-07 10:10 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-07 10:03 Randy Li [this message]
2019-03-07 10:03 ` [PATCH v2 0/6] [WIP]: rockchip mpp for v4l2 video deocder Randy Li
2019-03-07 10:03 ` Randy Li
2019-03-07 10:03 ` [PATCH v2 1/6] arm64: dts: rockchip: add power domain to iommu Randy Li
2019-03-07 10:03   ` Randy Li
2019-03-07 10:03   ` Randy Li
2019-03-07 10:03 ` [PATCH v2 2/6] staging: video: rockchip: add v4l2 decoder Randy Li
2019-03-07 10:03   ` Randy Li
2019-03-08  2:33   ` Joe Perches
2019-03-08  2:33     ` Joe Perches
2019-03-07 10:03 ` [PATCH v2 3/6] [TEST]: rockchip: mpp: support qptable Randy Li
2019-03-07 10:03   ` Randy Li
2019-03-07 10:03   ` Randy Li
2019-03-07 10:03 ` [PATCH v2 4/6] staging: video: rockchip: add video codec Randy Li
2019-03-07 10:03   ` Randy Li
2019-03-07 10:03   ` Randy Li
2019-03-07 17:11 ` [PATCH v2 0/6] [WIP]: rockchip mpp for v4l2 video deocder Nicolas Dufresne
2019-03-07 17:11   ` Nicolas Dufresne

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190307100316.925-1-randy.li@rock-chips.com \
    --to=randy.li@rock-chips.com \
    --cc=ayaka@soulik.info \
    --cc=ezequiel@collabora.com \
    --cc=groeck@chromium.org \
    --cc=hverkuil@xs4all.nl \
    --cc=jernej.skrabec@gmail.com \
    --cc=joro@8bytes.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=linux-rockchip@lists.infradead.org \
    --cc=maxime.ripard@bootlin.com \
    --cc=mchehab@kernel.org \
    --cc=nicolas@ndufresne.ca \
    --cc=paul.kocialkowski@bootlin.com \
    --cc=posciak@chromium.org \
    --cc=thomas.petazzoni@bootlin.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.