From: Randy Li <randy.li@rock-chips.com>
To: dri-devel@lists.freedesktop.org
Cc: airlied@linux.ie,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
linux-media@vger.kernel.org
Subject: Plan to support Rockchip VPU in DRM, is it a good idea
Date: Fri, 26 Aug 2016 10:13:58 +0800 [thread overview]
Message-ID: <a56a7da9-154b-c889-67f6-81bd7e4c7a7d@rock-chips.com> (raw)
Hello,
We always use some kind of hack work to make our Video Process
Unit(Multi-format Video Encoder/Decoder) work in kernel. From a
customize driver(vpu service) to the customize V4L2 driver. The V4L2
subsystem is really not suitable for the stateless Video process or it
could make driver too fat.
After talking to some kindness Intel guys and moving our userspace
library to VA-API driver, I find the DRM may the good choice for us.
But I don't know whether it is welcome to to submit a video driver in
DRM subsystem?
Also our VPU(Video process unit) is not just like the Intel's, we
don't have VCS, we based on registers to set the encoder/decoder. I
think we may need a lots of IOCTL then. Also we do have a IOMMU in VPU
but also not a isolated memory for VPU, I don't know I should use TT
memory or GEM memory.
I am actually not a member of the department in charge of VPU, and I
am just beginning to learning DRM(thank the help from Intel again), I am
not so good at memory part as well(I am more familiar with CMA not the
IOMMU way), I may need know guide about the implementations when I am
going to submit driver, I hope I could get help from someone.
--
Randy Li
The third produce department
next reply other threads:[~2016-08-26 2:22 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-26 2:13 Randy Li [this message]
2016-08-26 9:34 ` Hans Verkuil
2016-08-26 10:05 ` Randy Li
2016-08-26 10:56 ` Hans Verkuil
2016-08-26 12:08 ` Randy Li
2016-08-27 23:06 ` Theodore Kilgore
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=a56a7da9-154b-c889-67f6-81bd7e4c7a7d@rock-chips.com \
--to=randy.li@rock-chips.com \
--cc=airlied@linux.ie \
--cc=dri-devel@lists.freedesktop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®