Re: [PATCH v2 0/4] drm/atomic: Add accessor macros for all atomic state.

From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: dri-devel@lists.freedesktop.org
Subject: Re: [PATCH v2 0/4] drm/atomic: Add accessor macros for all atomic state.
Date: Thu, 15 Dec 2016 10:19:55 +0100	[thread overview]
Message-ID: <f212cd8e-d044-850e-4228-02e0e74e4170@linux.intel.com> (raw)
In-Reply-To: <20161214131748.uimc7lfix727ojxv@phenom.ffwll.local>

Op 14-12-16 om 14:17 schreef Daniel Vetter:
> On Wed, Nov 16, 2016 at 02:58:04PM +0100, Maarten Lankhorst wrote:
>> Second approach. Instead of trying to convert all drivers straight away,
>> implement all macros that are required to get state working.
>>
>> Current situation:
>> Use obj->state, which can refer to old or new state.
>> Use drm_atomic_get_(existing_)obj_state, which can refer to new or old state.
>> Use for_each_obj_in_state, which refers to new or old state.
>>
>> New situation:
>> When doing some dereferencing outside atomic_state, use
>> drm_atomic_get_current_obj_state which has locking checks, instead of
>> obj->state.
>>
>> During atomic check:
>> - Use drm_atomic_get_obj_state to add a object to the atomic state,
>>   or get the new state.
>> - Use drm_atomic_get_(old/new)_obj_state to peek at the new/old state,
>>   without adding the object if it's not part of the state. For planes
>>   and connectors the relevant crtc_state is added, so this will work to
>>   get the crtc_state from foo_state->crtc too, saves some error handling. :)
>>
>> During atomic commit:
>> - Do not use drm_atomic_get_obj_state, obj->state or drm_atomic_get_(existing_)obj_state
>>   any more, replace with drm_atomic_get_old/new_obj_state calls as required.
>>
>> During both:
>> - Use for_each_(new,old,oldnew)_obj_in_state to get the old or new state as needed.
>>   oldnew will be renamed to for_each_obj_in_state after all callers are converted
>>   to the new api.
>>
>> This will give the correct state regardless of swapping.
> So this is all nice, but fundamentally it's pile of new code with 0 users.
> Where are those patches? I think at least converting all the core+helpers
> to use it consistently would be needed to justify this.
I deliberately didn't send those patches this time because the drivers and atomic core change all the time. I would have had to respin this whole series at least 4 times. :)
I have the patches for conversion in my tree based on -tip.

https://cgit.freedesktop.org/~mlankhorst/linux/log/?h=nightly
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel