On Fri, Dec 01, 2017 at 08:19:16AM +0100, Daniel Vetter wrote: > On Thu, Nov 30, 2017 at 11:49:53PM +0000, Sudip Mukherjee wrote: > > Hi Daniel, > > > > <snip> > > > > > > > > > > > > > > Greg? > > > > > > > > > > Yes, if no one is working to get it out of staging, that means no one > > > > > cares about it, and it needs to be removed from the tree. > > > > > > > > Agreed. I was not working on getting it out of staging as there is no > > > > place for it to go. > > > > But, Teddy Wang told me that they have a working drm driver for it, but > > > > it is not atomic like Daniel was asking for. If it is ok, then I can send > > > > in a patch to remove the existing sm750 from staging and add the new sm750 > > > > drm driver to staging. And after it is ready, we can go ahead with moving > > > > it out of staging to drm. > > > > > > Please keep the todo item that it needs to be converted to atomic. And > > > tbh, it's probably faster if you just submit it to dri-devel, assuming you > > > have time to work on it. For small drivers we tend to be fairly quick in > > > getting them into good enough shape. > > > > I have received the driver from Teddy and pushed it to > > https://github.com/sudipm-mukherjee/parport/tree/drm_smi for your first > > look into it. It is not even building with next-20171130 and has lots of > > build warnings. I will have to do a lot of work on it before I can even > > submit it to dri-devel. > > > > Time will be the problem, as this is not part of my day job. > > > > > > > > Staging is also a major pain for drm subsystem refactorings, I really, > > > really, really prefer we don't add more than the vbox pain we have > > > already. > > > > I am hoping that after seeing it, you will agree to have it in staging. :) > > So I know Greg is willing to take anything into staging, but I'm no fan. > We refactor and improve drm a lot, with a lot of cross-driver changes > necessary to move things forward. We can do that since we have a generally > rather active development community, and we try hard to keep most drivers > in reasonable good shape and so easy to maintain. > > If you know throw a pile of unmaintainable stuff into staging, but without > working on it, then that's just cost, no benefit to the dri-devel > community. On top, staging tree is separate from drm trees, so more pain > to synchronize trees (and we have to do that a few times per release cycle > or drivers simply stop compiling). Where's the upside of taking this > driver into staging? > > One is users, but ime for soc display drivers usually everything else is > in worse shape (e.g. even great drivers like the one for qualcom must be > tested on some vendor tree because critical core bits are missing in > upstream), so "more users" is not the good reason. And it's clearly not > "more developers", because no time to clean things up. So what exactly is > the good reason to put this into staging instead of just waiting until > someone has the time to clean it up quickly? Ok, I will not try to give any more reasons now. :) I will cleanup the basic things I can and then submit it to dri-devel. Greg - Please keep the SM750 driver in staging for now. I will send a patch later to add in TODO the git location where the drm driver is being developed. And when that drm driver is ready, I will send a patch to remove the sm750fb driver from staging. -- Regards Sudip _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
