On Tue, Nov 28, 2017 at 12:30:30PM +0000, Sudip Mukherjee wrote: > On Tue, Nov 28, 2017 at 12:32:38PM +0100, Greg KH wrote: > > On Tue, Nov 28, 2017 at 11:22:17AM +0100, Daniel Vetter wrote: > > > On Mon, Nov 27, 2017 at 08:52:19PM +0000, Sudip Mukherjee wrote: > > > > On Mon, Nov 27, 2017 at 11:27:59AM +0100, Daniel Vetter wrote: > > > > > On Fri, Nov 24, 2017 at 06:53:31PM +0100, Michał Mirosław wrote: > > > > > > Almost all drivers using remove_conflicting_framebuffers() wrap it with > > > > > > the same code. Extract common part from PCI drivers into separate > > > > > > remove_conflicting_pci_framebuffers(). > > > > > > > > > > > > Signed-off-by: Michał Mirosław <mirq-linux@xxxxxxxxxxxx> > > > > > > > > > > Since the only driver that seems to use this is the staging one, which imo > > > > > is a DOA project, not sure it's worth to bother with this here. > > > > > > > > afaik, this device is used in production by few manufacturers and it is > > > > usefull for them to have it in the tree and the only reason it is still > > > > in staging is because Tomi announced he will not take any new drivers in > > > > fbdev. And, so I have not taken the initiative to properly move it out > > > > of staging. I think Bartlomiej will also not accept new drivers in fbdev. > > > > > > Imo, if no one cares about porting it to kms (which will give you an fbdev > > > driver for free), then we should throw it out. At least I thought staging > > > was only for stuff that had a reasonable chance to get mainlined. Not as a > > > dumping ground for drivers that people use, but don't bother to get ready > > > for mainline. > > > > > > 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. 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. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/virtualization
