On 30 November 2017 at 23:49, Sudip Mukherjee <sudipm.mukherjee@xxxxxxxxx> 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 _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/virtualization
