abuse of dumb ioctls in exynos

[Patrik Jakobsson]

On Tue, Apr 30, 2013 at 10:19 PM, Dave Airlie <airlied at gmail.com> wrote:
>>> 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.

I certainly don't have the big picture of this and I trust you in your decision.

My idea was not to have a restrictive interface but to have something thin for
the most common parts and allow it to be extended for every use case. But if it
didn't work before there is little point in doing the same mistake again. And
ofc there is no such thing as a non restrictive generic interface.

> 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.

Don't worry, there are no such patches coming your way.

Thanks
Patrik