[RFC 0/4] Add NVIDIA Tegra DRM support
Thierry Reding
thierry.reding at avionic-design.de
Fri Apr 20 15:02:31 EST 2012
* Jon Mayo wrote:
> On 04/19/2012 01:40 PM, Thierry Reding wrote:
[...]
> >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?
>
> 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).
Okay. Let's do that then.
> 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.
I think by supporting the DRM we can get pretty far for X11. Writing a Tegra-
specific driver based off xf86-video-modesetting can be done to use advanced
features if they can't be abstracted away properly. DRM also paves the way
for Wayland support.
What I see as somewhat of a problem is how to get NVIDIA and the community to
work together (and work together well). We'll have to see how this works out,
but I'd hate to see more resources wasted because everybody starts doing
their own thing.
> (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)
That sounds like a good plan. Ideally you should even share the patches as
soon as they're ready. That'll give viewers some head start and you can fix
the code even before the hardware is released.
Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/devicetree-discuss/attachments/20120420/541539e0/attachment.sig>
More information about the devicetree-discuss
mailing list