On Thu, Dec 14, 2017 at 09:11:01PM -0500, Alex Deucher wrote: > On Thu, Dec 14, 2017 at 3:30 PM, Daniel Vetter <daniel.vetter@xxxxxxxx> wrote: > > diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst > > index 420025bd6a9b..cbba93483aec 100644 > > --- a/Documentation/gpu/drm-kms.rst > > +++ b/Documentation/gpu/drm-kms.rst > > @@ -263,10 +263,10 @@ Taken all together there's two consequences for the atomic design: > > > > - An atomic update is assembled and validated as an entirely free-standing pile > > of structures within the :c:type:`drm_atomic_state <drm_atomic_state>` > > - container. Again drivers can subclass that container for their own state > > - structure tracking needs. Only when a state is committed is it applied to the > > - driver and modeset objects. This way rolling back an update boils down to > > - releasing memory and unreferencing objects like framebuffers. > > + container. Driver private state structures are also tracked in the same > > + structure, see the next chapter. Only when a state is committed is it applied > > I think it would be clearer as: > structure (see the next chapter). > or > structure; see the next chapter. > > Either way: > Reviewed-by: Alex Deucher <alexander.deucher@xxxxxxx> Thanks for all the review from you and DK, all taken into account and merged. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
