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.
