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@rere.qmqm.pl
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.
Greg? Daniel?
I'll always take patches that delete code from staging :)