abuse of dumb ioctls in exynos

[Dave Airlie]

>
> 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:
>
> 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?

What part of don't use dumb buffer for acceleration is hard to understand?

Christ I called them DUMB. Lets try this again.

DON'T USE DUMB BUFFERS FOR ALLOCATING BUFFERS USED FOR ACCELERATION.

Now that we've cleared that up, armsoc is a big bag of shit, I've
spent a few hours on it in the last few weeks trying to get anything
to run on my chromebook and really armsoc needs to be put out of its
misery.

The only working long term strategy for ARM I see is to abstract the
common modesetting code into a new library, and write a per-GPU
driver.

What you are doing now is madness and needs to stop.

Dave.