It seems like commits were re-ordered at some point. I think we need "drm: introduce drm_mode_config.atomic_async_page_flip_not_supported" to come before "drm: allow DRM_MODE_PAGE_FLIP_ASYNC for atomic commits" because the latter uses atomic_async_page_flip_not_supported. Similarly, "drm: Refuse to async flip with atomic prop changes" should probably come before that same patch because we don't want to have an intermediary state where we allow user-space to change arbitrary properties. In general, commits should be constructed so that there is no "broken state" in-between: each commit needs to build without errors and not have transient bugs. While reading this again, I think that now that we only allow primary FB_ID to change, we don't need atomic_async_page_flip_not_supported anymore? In other words, allowing async atomic commits on all drivers doesn't require anything more than they support already, because the atomic codepath can't do anything more than the legacy codepath. With that in mind, I also wonder if the new cap is helpful. Since async atomic commits can fail for pretty much any reason, user-space can just try and fallback to something else. The cap could be useful to indicate whether async atomic commits would always fail, but not sure how useful that is? I don't have strong opinions either way.
