[Intel-gfx] [RFC PATCH 0/3] drm driver for baytrail's vxd392

[Daniel Vetter]

On Wed, Oct 15, 2014 at 10:13:15AM +0200, Thierry Reding wrote:
> On Tue, Oct 14, 2014 at 08:50:35AM -0700, Sean V Kelley wrote:
> > On Tue, Oct 14, 2014 at 4:53 AM, Thierry Reding
> > <thierry.reding at gmail.com> wrote:
> > > On Mon, Oct 13, 2014 at 08:15:00PM +0800, Yao Cheng wrote:
> > >> drm/ipvr is a new GEM driver for baytrail's vxd392, which accelerates VP8 video decoding.
> > >> The driver name "ipvr" means the PowerVR's IP wrapped by Intel. In the future, ipvr may support other platforms such as Merrifield.
> > >> Code is placed at drivers/gpu/drm/ipvr and the following two new Kconfig are added:
> > >>   CONFIG_DRM_IPVR: Build option for ipvr module
> > >>   CONFIG_DRM_IPVR_EC: Experimental feature of error concealment
> > >>
> > >> User mode drm helper "libdrm_ipvr.so" and simple test are also included.
> > >>
> > >> Yao Cheng (3):
> > >>  [1/3] drm/i915: add vxd392 bridge in i915 on baytrail
> > >>  [2/3] drm/ipvr: ipvr drm driver for vxd392
> > >
> > > If this is Intel-specific, why doesn't it live under the i915 driver?
> > 
> > It is an entirely unrelated HW IP block, VXD392.  Nothing to do with
> > GEN aside from DRM based.
> 
> With GEN you're referring to the Intel integrated GPU? And VXD392 I take
> it is the IP block licensed by Imagination? Baytrail and others then
> wrap some additional logic around this as it is integrated into the SoC?
> 
> How much wrapping actually happens here? I worry that this is going to
> lead to a lot of duplication if we ever want to support another SoC that
> uses the VXD392 IP. Could the code be split into a VXD392 "library" and
> some driver that implements the Intel-specific glue?

Well if someone cares for it the driver ioctl interface should be
portable. But without anyone else chiming in I honestly don't care. We did
try to design the entire beast like that though, and it should pretty much
work with few changes on gma500 (if anyone bothers).

> Finally, if this IP block is a VP8 video decoding engine only, I'm not
> sure DRM is the best subsystem for it. Traditionally video decoding has
> been done primarily in V4L2. I'm not sure that's the best fit given that
> it was originally designed for video capturing, but they've evolved some
> infrastructure to deal with encoding/decoding, whereas we have nothing
> like that at all in DRM.

Shuffling massive piles of state submission code into the kernel is imo
not a sane design. So imo the sane way is to put encode/decode drivers
into drm, and the kernel part just has minimal validation for security (if
required at all if the iommu isn't good enough). The common interface for
applications would then be gstreamer (since we don't even have a
cross-vendor video api with at least libva and vdpau having rather decent
open drivers available).
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch