Re: [Intel-gfx] [RFC v4 00/25] drm: Add generic fbdev emulation

[Daniel Vetter <daniel@ffwll.ch>]

On Mon, Apr 16, 2018 at 08:49:23PM +0200, Noralf Trønnes wrote:
> 
> Den 16.04.2018 10.21, skrev Daniel Vetter:
> > On Sat, Apr 14, 2018 at 01:52:53PM +0200, Noralf Trønnes wrote:
> > > This patchset explores the possibility of having generic fbdev emulation
> > > in DRM for drivers that supports dumb buffers which they can export. An
> > > API is added to support in-kernel clients in general.
> > > 
> > > In this version I was able to reuse the modesetting code from
> > > drm_fb_helper in the client API. This avoids code duplication, carries
> > > over lessons learned and the modesetting code is bisectable. The
> > > downside is that it takes +10 patches to rip drm_fb_helper in two, so
> > > maybe it's not worth it wrt possible breakage and a challenging review.
> > So my idea wasn't to rip the fbdev helper in  half first (that's indeed a
> > lot of work). But start out right away with using every piece of the
> > drm_client infrastructure you're adding in the existing fbdev code.
> > 
> > That way there's not a huge patch series which just adds code, with no
> > users, but every step of the way and every addition is tested almost right
> > away. That makes more gradual merging also easier. The things I have in
> > mind here is the generic fb_probe, or the drm_client block/unblock masters
> > and all that stuff.
> > 
> > Then, once we've demonstrated all these auxiliary pieces necessary for
> > drm_client.c work, we can cut the fb-helper in half and move the modeset
> > code into the drm_client library.
> 
> I agree. I wished for a way to cut this patchset in half, but I just
> couldn't see how. I was tired of working on this, so I just put it out
> hoping that you would provide some clarity. Which you did, thanks :-)

Yeah, that's why I'm also ok with things as-is. I think we've reached
agreement on the design and big picture now, which really is the important
part. How exactly we get there (as long as it's gradual steps in
bisectable patches) doesn't matter that much really.

> So, I think I'll strip this down to just the buffer part of the client API
> and use that in the generic fbdev emulation, and start converting some
> drivers.

Yes the buffer stuff is definitely the core parts. I think rolling out the
master_block/unblock stuff after that would be really neat too, since it
would fix a long-standing race in our fbdev emulation.

> I'll pick up the rest of the client API when I'm done with moving tinydrm
> over to vmalloc buffers and have added support for device unplug.

Sounds like a good plan.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel