The reason why we use DRM interface is mainly we want to use GEM for video memory manager.
Thanks, Fei -----Original Message----- From: Rob Clark [mailto:robdclark@gmail.com] Sent: Friday, October 17, 2014 2:43 AM To: Thierry Reding Cc: Kelley, Sean V; Vetter, Daniel; intel-gfx@lists.freedesktop.org; DRI mailing list; Jiang, Fei Subject: Re: [Intel-gfx] [RFC PATCH 0/3] drm driver for baytrail's vxd392
On Wed, Oct 15, 2014 at 4:13 AM, Thierry Reding thierry.reding@gmail.com wrote:
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.
v4l maybe works for some vid dec/enc hw if the hw does enough for you.. the common ioctl approach might work for some hw, but I think not really all. For the same reason we don't try to standardize the 3d/2d cmd submission ioctls across drivers..
BR, -R