On 30 November 2017 at 23:49, Sudip Mukherjee sudipm.mukherjee@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