[RFC 0/4] Add NVIDIA Tegra DRM support

Jon Mayo jmayo at nvidia.com
Thu Apr 19 13:59:39 PDT 2012


On 04/19/2012 01:40 PM, Thierry Reding wrote:
> * PGP Signed by an unknown key
>
> * Dave Airlie wrote:
>> On Thu, Apr 19, 2012 at 6:35 PM, Thierry Reding
>> <thierry.reding at avionic-design.de>  wrote:
>>> Before posting the next round of patches I wanted to clarify whether we need
>>> to take the Tegra driver through staging. Lucas brought this up referring to
>>> previous experience with Nouveau where Linus used to complain that userspace
>>> ABI was broken for non-staging drivers. I don't know how relevant that is
>>> for Tegra. We could also keep it in drivers/gpu/drm and only add userspace
>>> interfaces that we are sure are not going to change. Currently there isn't
>>> isn't anything that could be easily broken as only some of the standard DRM
>>> interfaces are supported anyway.
>>>
>>> Alternatively we could keep the driver in a separate tree until it becomes
>>> mature enough.
>>>
>>> Any thoughts?
>>
>> It's probably okay to avoid staging if it doesn't add any userspace ioctls.
>>
>> A KMS driver that just supports the dumb ioctls so -modesetting works,
>> would be the first thing to aim for I suppose, like how the exynos
>> guys did it.
>>
>> Adding userspace interfaces is where you'll get into ABI guarantees
>> etc, and these are normally required only for the accel engines.
>
> I think this is what Lucas was concerned about. The plan is to look at how
> much can be used from the Nouveau code and make it work on the Tegra. So
> would it be possible to get a basic dumb KMS driver into mainline
> (non-staging) and phase in acceleration later on, with ABI guarantees? I
> guess development can go on in separate trees until the ABI is stable and can
> subsequently be ported to the mainline driver.
>
> Is that an acceptable approach?
>
> Thierry
>

That certainly seems like the most reasonable approach to me. Get KMS 
only in first. It's a useful driver as-is, and has the lowest barrier to 
entry into upstream.

Then later we can phase in enhancements. We certainly have plenty of 
places internally and externally to hash out acceleration interfaces, 
and come to some consensus at at later date (either on linux-tegra or 
direct email).

We have a lot of concerns here. What is best for X11, what is best for 
Android, how do we keep healthy open source implementations, and how 
does NVIDIA move forward with supporting new Tegra on an open source 
implementation. (My vote is NVIDIA starts using this DRM in-house and 
builds new extensions on top of it, sharing patches on LKML when the 
hardware is released)


More information about the dri-devel mailing list