On Fri, Aug 07, 2020 at 10:32:11AM -0400, Kazlauskas, Nicholas wrote:
> On 2020-08-07 4:52 a.m., daniel@xxxxxxxx wrote:
> > On Thu, Jul 30, 2020 at 04:36:42PM -0400, Nicholas Kazlauskas wrote:
> > > @@ -440,7 +431,7 @@ struct dm_crtc_state {
> > > #define to_dm_crtc_state(x) container_of(x, struct dm_crtc_state, base)
> > > struct dm_atomic_state {
> > > - struct drm_private_state base;
> > > + struct drm_atomic_state base;
> > > struct dc_state *context;
> >
> > Also curiosity: Can't we just embed dc_state here, instead of a pointer?
> > Then it would become a lot more obvious that mostly this is a state object
> > container like drm_atomic_state, but for the DC specific state structures.
> > And we could look into moving the actual DC states into drm private states
> > perhaps (if that helps with the code structure and overall flow).
> >
> > Maybe as next steps.
> > -Daniel
> >
>
> It's the refcounting that's the problem with this stuff. I'd like to move DC
> to a model where we have no memory allocation/ownership but that might be a
> bit of a more long term plan at this point.
>
> Same with dc_plane_state and dc_stream_state as well - these could exist on
> the DRM objects as long as they're not refcounted.
Hm what's the refcounting problem you're having? Or is it the lack of
refcounting, and dc having different ideas about lifetimes than atomic?
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
