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

[Emil Velikov]

On 30 November 2017 at 23:49, Sudip Mukherjee
<sudipm.mukherjee at gmail.com> wrote:
> 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.
>
A crazy idea, mostly towards Tedd and Sudip:

Start small and build gradually. An example split for separate patch series:

 - one HW, basic setup + atomic KMS
 - add second HW
 - more KMS features
 - fancy memory management
 - 2D/3D/other acceleration

The driver as seen above tries to do all of the above (almost, it's not atomic)
at once - 40k loc.

Someone familiar with the code can quickly split it up and while doing
so, feed it through checkpatch.
Current code is _very_ far from kernel coding style, plus the
copyright blurp is very disturbing:

* All rights are reserved. Reproduction or in part is prohibited
* without the written consent of the copyright owner.

HTH
Emil