Virtualization - Nov 2017 - [PATCH 02/13] fbdev: add remove_conflicting_pci_framebuffers()

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 at 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?
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

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 at
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.

thanks,

greg k-h

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 at
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?

--
Regards
Sudip