On 20 April 2017 at 19:13, Marek Szyprowski <m.szyprowski@xxxxxxxxxxx> wrote: > Dear all, > > This is an updated proposal for extending EXYNOS DRM API with generic support > for hardware modules, which can be used for processing image data from the > one memory buffer to another. Typical memory-to-memory operations are: > rotation, scaling, colour space conversion or mix of them. This is > a follow-up of my previous proposal "[RFC 0/2] New feature: Framebuffer > processors", which has been rejected as "not really needed in the DRM core": > http://www.mail-archive.com/dri-devel@xxxxxxxxxxxxxxxxxxxxx/msg146286.html > > In this proposal I moved all the code to Exynos DRM driver, so now this > will be specific only to Exynos DRM. I've also changed the name from > framebuffer processor (fbproc) to picture processor (pp) to avoid confusion > with fbdev API. > > Here is a bit more information what picture processors are: > > Embedded SoCs are known to have a number of hardware blocks, which perform > such operations. They can be used in paralel to the main GPU module to > offload CPU from processing grapics or video data. One of example use of > such modules is implementing video overlay, which usually requires color > space conversion from NV12 (or similar) to RGB32 color space and scaling to > target window size. > > The proposed API is heavily inspired by atomic KMS approach - it is also > based on DRM objects and their properties. A new DRM object is introduced: > picture processor (called pp for convenience). Such objects have a set of > standard DRM properties, which describes the operation to be performed by > respective hardware module. In typical case those properties are a source > fb id and rectangle (x, y, width, height) and destination fb id and > rectangle. Optionally a rotation property can be also specified if > supported by the given hardware. To perform an operation on image data, > userspace provides a set of properties and their values for given fbproc > object in a similar way as object and properties are provided for > performing atomic page flip / mode setting. > > The proposed API consists of the 3 new ioctls: > - DRM_IOCTL_EXYNOS_PP_GET_RESOURCES: to enumerate all available picture > processors, > - DRM_IOCTL_EXYNOS_PP_GET: to query capabilities of given picture > processor, > - DRM_IOCTL_EXYNOS_PP_COMMIT: to perform operation described by given > property set. > > The proposed API is extensible. Drivers can attach their own, custom > properties to add support for more advanced picture processing (for example > blending). So this looks more like a command submission API like we have for other drivers. Is there an overarching reason why it needs to reuse the core drm object tracking and properties, or was that just a nice to have, vs something like amdgpu chunks. My worry about exposing objects and properties to the drivers is I'm sure someone could get quite inventive and end up with a forked atomic API that we don't see, or undocumented things. Dave. -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
 |