[GIT PULL] Raspberry Pi KMS driver

[Dave Airlie]

On 23 October 2015 at 05:58, Daniel Vetter <daniel at ffwll.ch> wrote:
> On Thu, Oct 22, 2015 at 12:40:23PM -0500, Rob Herring wrote:
>> On Wed, Oct 21, 2015 at 4:53 AM, Eric Anholt <eric at anholt.net> wrote:
>> > Dave suggested it was time to just send a pull request on the driver, so
>> > here goes:
>>
>> Why is that when the binding is still under discussion[1]? Even the
>> agreed changes never got reposted.
>
> Bit a longer story, so here we go: I don't really like drivers/staging
> since it's a cage where drivers get forgotten about, and even if there is
> activity it's completely separate from all the other drm drivers. Which
> doesn't help with collaboration, which is the entire point really of
> upstreaming.
>
> Otoh I really like how drivers/staging allows not-quite-ready drivers to
> get in and get more visibility. So for drm I think the right approach is
> to just merge drivers which are reasonable close to good enough, and fix
> up anything erregrious once merged. This might be special for drm, since
> gpus change ridiculously fast, resulting in anyone contributing for more
> than 2-3 years to be constantly busy cleaning up past code that turned out
> a mistake in light of todays hardware. I think that means overall drm has
> a lower bar to entry and much higher acceptance for crap. And there's lots
> of it. Could very well be that most of the drm subsystem should be in
> drivers/staging by everyone else's standard.
>
> For this specific case here of the rpi driver the only ongoing thing was
> the dt binding discussion, and it didn't look like it would reach closure
> anytime soon. On top of that this driver is for rpi specifically (vc5 will
> require a completely new driver for a bunch of reasons), and on those
> boards the boot loader will never ship a dt file, it will always come from
> the kernel. Which means it's really just an internal interface and there's
> zero concerns about compatibility.

Yes besides the binding everything was ready, the drm API was more likely
to go stale and cause regressions/problems than fixing up what is at least
in this case going to be an in-tree interface, since there are thousands
of these boards in existance. I'm also travelling next week and I'd rather
not be pulling trees into drm-next too much.

The dt discussion can still go on, and we can merge the changes, before,
during after the merge window.

Dave.