Dave Airlie wrote: > On 23 October 2017 at 17:54, Marek Szyprowski <m.szyprowski@xxxxxxxxxxx> wrote: >> This patch adds Exynos IPP v2 subsystem and userspace API. >> >> New userspace API is focused ONLY on memory-to-memory image processing. >> The two remainging IPP operation modes (framebuffer writeback and >> local-path output with image processing) can be implemented using >> standard DRM features: writeback connectors and additional DRM planes with >> scaling features. >> >> V2 IPP userspace API is not compatible with old IPP ioctls. This is a >> significant change, but the old IPP subsystem in mainline Linux kernel was >> partially disfunctional anyway and not used in any open-source project. >> >> V2 IPP userspace API is based on stateless approach, which much better fits >> to memory-to-memory image processing model. It also provides support for >> all image formats, which are both already defined in DRM API and supported >> by the existing IPP hardware modules. >> >> The API consists of the following ioctls: >> - DRM_IOCTL_EXYNOS_IPP_GET_RESOURCES: to enumerate all available image >> processing modules, >> - DRM_IOCTL_EXYNOS_IPP_GET_CAPS: to query capabilities and supported image >> formats of given IPP module, >> - DRM_IOCTL_EXYNOS_IPP_GET_LIMITS: to query hardware limitiations for >> selected image format of given IPP module, >> - DRM_IOCTL_EXYNOS_IPP_COMMIT: to perform operation described by the >> provided structures (source and destination buffers, operation rectangle, >> transformation, etc). >> >> The proposed userspace API is extensible. In the future more advanced image >> processing operations can be defined to support for example blending. >> >> Userspace API is fully functional also on DRM render nodes, so it is not >> limited to the root/privileged client. >> >> Internal driver API also has been completely rewritten. New IPP core >> performs all possible input validation, checks and object life-time >> control. The drivers can focus only on writing configuration to hardware >> registers. Stateless nature of DRM_IOCTL_EXYNOS_IPP_COMMIT ioctl simplifies >> the driver API. Minimal driver needs to provide a single callback for >> starting processing and an array with supported image formats. > > Is there userspace user for this? This is pretty significant > driver-specific API addition. > > The commit should contain pointers to a userspace project using this, > or patches to one. The pointers are in the cover letter of the series. - Tobias > Dave. > _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel