On Fri, Dec 01, 2017 at 08:19:16AM +0100, Daniel Vetter wrote:

On Thu, Nov 30, 2017 at 11:49:53PM +0000, Sudip Mukherjee wrote:

quoted

Hi Daniel,

<snip>

quoted

quoted

quoted

quoted

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.

quoted

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

So I know Greg is willing to take anything into staging, but I'm no fan.
We refactor and improve drm a lot, with a lot of cross-driver changes
necessary to move things forward. We can do that since we have a generally
rather active development community, and we try hard to keep most drivers
in reasonable good shape and so easy to maintain.

If you know throw a pile of unmaintainable stuff into staging, but without
working on it, then that's just cost, no benefit to the dri-devel
community. On top, staging tree is separate from drm trees, so more pain
to synchronize trees (and we have to do that a few times per release cycle
or drivers simply stop compiling). Where's the upside of taking this
driver into staging?

One is users, but ime for soc display drivers usually everything else is
in worse shape (e.g. even great drivers like the one for qualcom must be
tested on some vendor tree because critical core bits are missing in
upstream), so "more users" is not the good reason. And it's clearly not
"more developers", because no time to clean things up. So what exactly is
the good reason to put this into staging instead of just waiting until
someone has the time to clean it up quickly?

Ok, I will not try to give any more reasons now. :)

I will cleanup the basic things I can and then submit it to dri-devel.

Greg - Please keep the SM750 driver in staging for now. I will send
a patch later to add in TODO the git location where the drm driver is
being developed. And when that drm driver is ready, I will send a patch
to remove the sm750fb driver from staging.

--
Regards
Sudip