[RFC 0/4] Add NVIDIA Tegra DRM support

[Jon Mayo]

On 04/19/2012 11:05 PM, Lucas Stach wrote:
> Am Freitag, den 20.04.2012, 07:02 +0200 schrieb Thierry Reding:
*cut*
>
> Yes, I think we should go the route that Jerome Glisse pointed out: get
> in a basic KMS driver first and hide any accel ioctl under a staging
> config option.

Everyone seems happy with that, I have no objections.

*cut*
>
> I'm really interested how this turns out in the end. I hope we can get a
> somewhat stable cooperation between NVIDIA and the community, like AMD
> has established at the moment.

Well, we always strive to be better than AMD ;-)
But seriously, I don't think GPU technology would be where it is today 
if NVIDIA and AMD didn't compete aggressively.

But our mobile division is more like TI, Qualcomm, Freescale and other 
SoC vendors. Upstreaming changes for arch/arm has so far been a 
different challenge than only updating drivers/gpu for x86. Mostly 
because there are so many aspects to SoCs compared to a driver for a 
graphics card or PC chipset. And it doesn't help that arch/arm is a real 
mess of wildly different SoCs, and it lacks the stability and maturity 
of the x86 code base. The state of ARM is every vendor's fault, every 
chip generation can be a complete resign of one or more subsystems. x86 
tends to be layers of extensions and enhancements from 1-3 vendors.

But even if Mobile doesn't consider AMD or Intel to be among the 
competition, we certainly watch and listen to good open source 
contributors and try to learn from their successes and mistakes. (and 
our own mistakes, we're not perfect!)

What I'm trying to say is that Tegra's business needs are different, so 
you should not be surprised to see different behavior from us. There are 
a lot of difficult issues with open sourcing the work done by my desktop 
colleagues. But those barriers don't apply to Tegra. Different product, 
different market, different rules.

>>
>>> (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.
>
> One thing I would like to have is upstream first. We have seen much
> Tegra development in both the nv-linux and chromium trees, but those
> things are going upstream extremely slowly. I can understand that this
> strategy was beneficial for a fast bring up of the new Tegra hardware,
> but the DRM driver shouldn't be time critical and so everything should
> be done to meet upstream quality from the start.
>
> -- Lucas
>
>

We have a team of interested engineers assigned to just that problem.
Fractured trees are not efficient for us internally either. We want 
upstream to be our common repository for most changes. And internally we 
have been stricter about conforming to Linux kernel coding conventions 
in attempt to give ourselves less work when we get to upstreaming a 
change. I'll be happy when I can tell my customers they can just grab 
the latest Tegra updates from git.kernel.org

Hopefully our efforts will begin to convince you.

- Jon