18c2ecf20Sopenharmony_ci===============================================================================
28c2ecf20Sopenharmony_ciTODOs
38c2ecf20Sopenharmony_ci===============================================================================
48c2ecf20Sopenharmony_ci
58c2ecf20Sopenharmony_ci1. Base this on drm-next - WIP
68c2ecf20Sopenharmony_ci
78c2ecf20Sopenharmony_ci
88c2ecf20Sopenharmony_ci2. Cleanup commit history
98c2ecf20Sopenharmony_ci
108c2ecf20Sopenharmony_ci
118c2ecf20Sopenharmony_ci3. WIP - Drop page flip helper and use DRM's version
128c2ecf20Sopenharmony_ci
138c2ecf20Sopenharmony_ci
148c2ecf20Sopenharmony_ci4. DONE - Flatten all DC objects
158c2ecf20Sopenharmony_ci    * dc_stream/core_stream/stream should just be dc_stream
168c2ecf20Sopenharmony_ci    * Same for other DC objects
178c2ecf20Sopenharmony_ci
188c2ecf20Sopenharmony_ci    "Is there any major reason to keep all those abstractions?
198c2ecf20Sopenharmony_ci
208c2ecf20Sopenharmony_ci    Could you collapse everything into struct dc_stream?
218c2ecf20Sopenharmony_ci
228c2ecf20Sopenharmony_ci    I haven't looked recently but I didn't get the impression there was a
238c2ecf20Sopenharmony_ci    lot of design around what was public/protected, more whatever needed
248c2ecf20Sopenharmony_ci    to be used by someone else was in public."
258c2ecf20Sopenharmony_ci    ~ Dave Airlie
268c2ecf20Sopenharmony_ci
278c2ecf20Sopenharmony_ci
288c2ecf20Sopenharmony_ci5. DONE - Rename DC objects to align more with DRM
298c2ecf20Sopenharmony_ci    * dc_surface -> dc_plane_state
308c2ecf20Sopenharmony_ci    * dc_stream -> dc_stream_state
318c2ecf20Sopenharmony_ci
328c2ecf20Sopenharmony_ci
338c2ecf20Sopenharmony_ci6. DONE - Per-plane and per-stream validation
348c2ecf20Sopenharmony_ci
358c2ecf20Sopenharmony_ci
368c2ecf20Sopenharmony_ci7. WIP - Per-plane and per-stream commit
378c2ecf20Sopenharmony_ci
388c2ecf20Sopenharmony_ci
398c2ecf20Sopenharmony_ci8. WIP - Split pipe_ctx into plane and stream resource structs
408c2ecf20Sopenharmony_ci
418c2ecf20Sopenharmony_ci
428c2ecf20Sopenharmony_ci9. Attach plane and stream reources to state object instead of validate_context
438c2ecf20Sopenharmony_ci
448c2ecf20Sopenharmony_ci
458c2ecf20Sopenharmony_ci10. Remove dc_edid_caps and drm_helpers_parse_edid_caps
468c2ecf20Sopenharmony_ci    * Use drm_display_info instead
478c2ecf20Sopenharmony_ci    * Remove DC's edid quirks and rely on DRM's quirks (add quirks if needed)
488c2ecf20Sopenharmony_ci
498c2ecf20Sopenharmony_ci    "Making sure you use the sink-specific helper libraries and kernel
508c2ecf20Sopenharmony_ci    subsystems, since there's really no good reason to have 2nd
518c2ecf20Sopenharmony_ci    implementation of those in the kernel. Looks likes that's done for mst
528c2ecf20Sopenharmony_ci    and edid parsing. There's still a bit a midlayer feeling to the edid
538c2ecf20Sopenharmony_ci    parsing side (e.g. dc_edid_caps and dm_helpers_parse_edid_caps, I
548c2ecf20Sopenharmony_ci    think it'd be much better if you convert that over to reading stuff
558c2ecf20Sopenharmony_ci    from drm_display_info and if needed, push stuff into the core). Also,
568c2ecf20Sopenharmony_ci    I can't come up with a good reason why DC needs all this (except to
578c2ecf20Sopenharmony_ci    reimplement half of our edid quirk table, which really isn't a good
588c2ecf20Sopenharmony_ci    idea). Might be good if you put this onto the list of things to fix
598c2ecf20Sopenharmony_ci    long-term, but imo not a blocker. Definitely make sure new stuff
608c2ecf20Sopenharmony_ci    doesn't slip in (i.e. if you start adding edid quirks to DC instead of
618c2ecf20Sopenharmony_ci    the drm core, refactoring to use the core edid stuff was pointless)."
628c2ecf20Sopenharmony_ci    ~ Daniel Vetter
638c2ecf20Sopenharmony_ci
648c2ecf20Sopenharmony_ci
658c2ecf20Sopenharmony_ci11. Remove dc/i2caux. This folder can be somewhat misleading. It's basically an
668c2ecf20Sopenharmony_ciovery complicated HW programming function for sendind and receiving i2c/aux
678c2ecf20Sopenharmony_cicommands. We can greatly simplify that and move it into dc/dceXYZ like other
688c2ecf20Sopenharmony_ciHW blocks.
698c2ecf20Sopenharmony_ci
708c2ecf20Sopenharmony_ci12. drm_modeset_lock in MST should no longer be needed in recent kernels
718c2ecf20Sopenharmony_ci    * Adopt appropriate locking scheme
728c2ecf20Sopenharmony_ci
738c2ecf20Sopenharmony_ci13. get_modes and best_encoder callbacks look a bit funny. Can probably rip out
748c2ecf20Sopenharmony_cia few indirections, and consider removing entirely and using the
758c2ecf20Sopenharmony_cidrm_atomic_helper_best_encoder default behaviour.
768c2ecf20Sopenharmony_ci
778c2ecf20Sopenharmony_ci14. core/dc_debug.c, consider switching to the atomic state debug helpers and
788c2ecf20Sopenharmony_cimoving all your driver state printing into the various atomic_print_state
798c2ecf20Sopenharmony_cicallbacks. There's also plans to expose this stuff in a standard way across all
808c2ecf20Sopenharmony_cidrivers, to make debugging userspace compositors easier across different hw.
818c2ecf20Sopenharmony_ci
828c2ecf20Sopenharmony_ci15. Move DP/HDMI dual mode adaptors to drm_dp_dual_mode_helper.c. See
838c2ecf20Sopenharmony_cidal_ddc_service_i2c_query_dp_dual_mode_adaptor.
848c2ecf20Sopenharmony_ci
858c2ecf20Sopenharmony_ci16. Move to core SCDC helpers (I think those are new since initial DC review).
868c2ecf20Sopenharmony_ci
878c2ecf20Sopenharmony_ci17. There's still a pretty massive layer cake around dp aux and DPCD handling,
888c2ecf20Sopenharmony_ciwith like 3 levels of abstraction and using your own structures instead of the
898c2ecf20Sopenharmony_cistuff in drm_dp_helper.h. drm_dp_helper.h isn't really great and already has 2
908c2ecf20Sopenharmony_ciincompatible styles, just means more reasons not to add a third (or well third
918c2ecf20Sopenharmony_cione gets to do the cleanup refactor).
928c2ecf20Sopenharmony_ci
938c2ecf20Sopenharmony_ci18. There's a pile of sink handling code, both for DP and HDMI where I didn't
948c2ecf20Sopenharmony_ciimmediately recognize the standard. I think long term it'd be best for the drm
958c2ecf20Sopenharmony_cisubsystem if we try to move as much of that into helpers/core as possible, and
968c2ecf20Sopenharmony_cishare it with drivers. But that's a very long term goal, and by far not just an
978c2ecf20Sopenharmony_ciissue with DC - other drivers, especially around DP sink handling, are equally
988c2ecf20Sopenharmony_ciguilty.
998c2ecf20Sopenharmony_ci
1008c2ecf20Sopenharmony_ci19. DONE - The DC logger is still a rather sore thing, but I know that the
1018c2ecf20Sopenharmony_ciDRM_DEBUG stuff just isn't up to the challenges either. We need to figure out
1028c2ecf20Sopenharmony_cisomething that integrates better with DRM and linux debug printing, while not
1038c2ecf20Sopenharmony_cibeing useless with filtering output. dynamic debug printing might be an option.
1048c2ecf20Sopenharmony_ci
1058c2ecf20Sopenharmony_ci20. Use kernel i2c device to program HDMI retimer. Some boards have an HDMI
1068c2ecf20Sopenharmony_ciretimer that we need to program to pass PHY compliance. Currently that's
1078c2ecf20Sopenharmony_cibypassing the i2c device and goes directly to HW. This should be changed.
1088c2ecf20Sopenharmony_ci
1098c2ecf20Sopenharmony_ci21. Remove vector.c from dc/basics. It's used in DDC code which can probably
1108c2ecf20Sopenharmony_cibe simplified enough to no longer need a vector implementation.
111