abuse of dumb ioctls in exynos

[Dave Airlie]

>> Except in the cases where it doesn't do what you want, and possibly in
>> the future where it does less of what you want. You've started on a
>> slippery slope, and I'm stopping you before you make things worse.
>>
>> You are going to have to get SoC kernel drivers to add an ioctl that
>> you can use, if you insist on trying to mangle all the different code
>> paths into a single userspace driver, then you are going to take a lot
>> of pain. Its the old helper library vs midlayer, you are inventing a
>> DDX midlayer when you should be inventing a DDX helper library.
>
> No argue there, but it would make sense to have a common set of ioctls for
> buffer management. The dumb buffer interface is for generic userspace but for
> non-generic cases there is still a need for something to prevent code
> duplication for the SoC people.

No it means SoC people need to duplicate more code in userspace.

Adding restrictive interfaces to do dumb buffer allocation is never
going to end well,
someone will always come up with a new buffer type that is slightly
different than
the previous ones you came up with for their special SoC. The old TTM
APIs we had
tried to do this generically, and it was too messy. I'm not sure if I
can say this plainer:
THIS IS NOT A GOOD IDEA AND I WON'T MERGE IT.

You also defeated any hope of me taking you seriously when you suggested adding
generic accel interfaces for 2D, because acceleration doesn't belong
in the kernel,
Lets get this straight, drm isn't fbdev, it isn't an unmaintained free
for all fastest hack
wins. If I catch this sort of bullshit happening in drm drivers I'll
be pulling maintainer
plugs out.

Dave.