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

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

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 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?
I'll always take patches that delete code from staging :)

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

Hi Daniel,

On Wed, Nov 29, 2017 at 10:56:34AM +0100, Daniel Vetter
wrote:
> 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().
> > > > > > > 
<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. :)

--
Regards
Sudip