abuse of dumb ioctls in exynos

[Tom Cooksey]

> It appears exynos is passing the generic flags from the dumb ioctls
> straight into the the GEM creation code.
> 
> The dumb flags are NOT driver specific, and are NOT to be used in this
> fashion. Please remove this use of the flags from your driver.
> 
> I was going to add one new flag to the interface for SCANOUT vs CURSOR
> for some drivers.

Having a flag to indicate a dumb buffer allocation is to be used as a 
scan-out buffer would be useful for xf86-video-armsoc. We're trying to
keep that driver as generic as possible and currently the main device-
specific bits are what flags to pass to DRM_IOCTL_MODE_CREATE_DUMB for
scanout & non-scanout buffer allocations. If a generic scanout flag could
be added, it would simplify armsoc a fair bit and also allow the DRM
drivers we're using armsoc with to comply with the don't pass device-
specific flags to create dumb.

For reference, the device-specific bits of armsoc are currently abstracted
here:

<https://git.linaro.org/gitweb?p=arm/xorg/driver/xf86-video-armsoc.git;a=blob;f=src/drmmode_driver.h
>


Note: We are still using DRM_IOCTL_MODE_CREATE_DUMB to allocate pixmap
and DRI2 buffers and have not come across any issues with doing that.
Certainly both Mali-400 & Mali-T6xx render to linear RGBA buffers and
the display controller's in SoCs shipping Mali also seem to happily
scan-out linear RGB buffers. Getting armsoc to run on OMAP (again) might
need a device-specific allocation function to allocate the tiled format
used on OMAP, but only for efficient 90-degree rotations (if I understood
Rob correctly). So maybe we could also one day add a "this buffer will be
rotated 90 degrees" flag?


Cheers,

Tom

PS: I've stuck in a fd.o bugzilla ticket to move xf86-video-armsoc to
freedesktop.org infrastructure, so hopefully it will live in a more
appropriate place soon, not to mention have a mailing list, etc.!