Re: [PATCH 02/13] fbdev: add remove_conflicting_pci_framebuffers()

From: Daniel Vetter <daniel-/w4YWyX8dFk@public.gmane.org>
To: Sudip Mukherjee
	<sudipm.mukherjee-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: "Teddy Wang"
	<teddy.wang-S9cbI//bT0v8C245oKUbwQC/G2K4zDHf@public.gmane.org>,
	"David Airlie" <airlied-cv59FeDIM0c@public.gmane.org>,
	"Greg KH"
	<gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org>,
	dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org,
	"Michał Mirosław"
	<mirq-linux-CoA6ZxLDdyEEUmgCuDUIdw@public.gmane.org>,
	amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org,
	"Daniel Vetter" <daniel-/w4YWyX8dFk@public.gmane.org>,
	"Alex Deucher" <alexander.deucher-5C7GfCeVMHo@public.gmane.org>,
	virtualization-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org,
	"Christian König" <christian.koenig-5C7GfCeVMHo@public.gmane.org>,
	"Gerd Hoffmann" <kraxel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Subject: Re: [PATCH 02/13] fbdev: add remove_conflicting_pci_framebuffers()
Date: Wed, 29 Nov 2017 10:56:34 +0100	[thread overview]
Message-ID: <20171129095634.ymeld4l7zaehbuvn@phenom.ffwll.local> (raw)
In-Reply-To: <20171128123008.GA12986@sudip-tp>

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.

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
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx