[RFC] Getting OpenChrome DRM mainlined into Linux kernel tree

[Dave Airlie]

On 28 May 2018 at 11:28, Kevin Brace <kevinbrace at gmx.com> wrote:
> Hi,
>
> I work on developing OpenChrome graphics stack for VIA Technologies Chrome integrated graphics.
> I am looking to get OpenChrome DRM pulled into the Linux kernel tree in the near future.
> This is not a pull request.
> The code not quite ready for that, but I will like to start orienting my development activities towards getting OpenChrome DRM mainlined in the next one or two Linux kernel development cycles since OpenChrome DRM has been living outside the mainline kernel tree for 7+ years (at least since Year 2011).
>     If someone reading this post is not too familiar with OpenChrome graphics stack, I did a presentation during XDC2017 that discussed the history of OpenChrome Project and its future plans.

Well done on getting this far. Merging this is definitely going to be
non-trivial. Being out of tree for so long means you've ended up in a
place that will require retracing a bunch of steps to get upstream.

> I declined this since I just got OpenChrome DRM ported to Linux 4.13 one week prior to XDC2017, but furthermore, I needed to stabilize the code itself since it was still pretty buggy compared to OpenChrome DDX UMS.
> The reason OpenChrome DRM still uses "legacy" KMS despite its flaws is the fact that previous developer, James Simmons, started the development back in Year 2011 or so, and I have merely continued the development starting around Year mid-2016.
> My personal wish is to get OpenChrome DRM "grandfathered" from the strong expectation of implementing universal plane and atomic mode setting since the code development started well before those two got incorporated into the DRM.
> I can consider converting the code to support these two features down the road, but just for the initial mainlining, I will like to be exempted from it since it will likely delay the mainlining by 6 months or so.

I'm not going to insist on atomic modesetting, but I think it would
definitely make the driver simpler and easier for someone to review,
and I'm open to Daniel insisting on it. I think you'd be getting close
to clean slating most of this driver at that point, which considering
some bits below might not be the worst idea.

>     Other than the universal plane and atomic mode setting, I have several other concerns.
>
> 1) James left some unfinished acceleration related code inside OpenChrome DRM, but I do not plan to activate it for the initial mainlined version. Do I need to remove the code?

Yes.

> 2) James appears to have implemented custom Libdrm ABI / API calls. I do not plan to activate it for the initial mainlined version. Do I need to remove the code?

Yes.

> 3) Almost all the functions start with "via_" instead of "openchrome_" at this point. Do I need to convert them all to "'openchrome_'?"

It would be nice, but possibly not essential.

> 4) Is the essentially deprecated VIA DRM going to be removed from the Linux kernel tree? VIA DRM is DRI1 based, and OpenChrome DRM supersedes VIA DRM for obvious reasons. Since OpenChrome DRM supersedes VIA DRM, I strongly support deleting VIA DRM from the Linux kernel tree.

No, since it shouldn't cause any problems with this, the current via
drm code is only enabled if userspace DRI1 stuff is around, I'm not
even sure there's a mesa driver that can use it at all.

I'm also not sure how the VIA output bridges are wired up, but we've
grown a lot of code for external bridges now and it might be that the
sil164 stuff could reuse that (or not).

This might be a candidate for a drm staging if we can get an initial
review and a decent TODO list together for it.

Dave.