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@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
