162306a36Sopenharmony_ci===============================================================================
262306a36Sopenharmony_ciTODOs
362306a36Sopenharmony_ci===============================================================================
462306a36Sopenharmony_ci
562306a36Sopenharmony_ci1. Base this on drm-next - WIP
662306a36Sopenharmony_ci
762306a36Sopenharmony_ci
862306a36Sopenharmony_ci2. Cleanup commit history
962306a36Sopenharmony_ci
1062306a36Sopenharmony_ci
1162306a36Sopenharmony_ci3. WIP - Drop page flip helper and use DRM's version
1262306a36Sopenharmony_ci
1362306a36Sopenharmony_ci
1462306a36Sopenharmony_ci4. DONE - Flatten all DC objects
1562306a36Sopenharmony_ci    * dc_stream/core_stream/stream should just be dc_stream
1662306a36Sopenharmony_ci    * Same for other DC objects
1762306a36Sopenharmony_ci
1862306a36Sopenharmony_ci    "Is there any major reason to keep all those abstractions?
1962306a36Sopenharmony_ci
2062306a36Sopenharmony_ci    Could you collapse everything into struct dc_stream?
2162306a36Sopenharmony_ci
2262306a36Sopenharmony_ci    I haven't looked recently but I didn't get the impression there was a
2362306a36Sopenharmony_ci    lot of design around what was public/protected, more whatever needed
2462306a36Sopenharmony_ci    to be used by someone else was in public."
2562306a36Sopenharmony_ci    ~ Dave Airlie
2662306a36Sopenharmony_ci
2762306a36Sopenharmony_ci
2862306a36Sopenharmony_ci5. DONE - Rename DC objects to align more with DRM
2962306a36Sopenharmony_ci    * dc_surface -> dc_plane_state
3062306a36Sopenharmony_ci    * dc_stream -> dc_stream_state
3162306a36Sopenharmony_ci
3262306a36Sopenharmony_ci
3362306a36Sopenharmony_ci6. DONE - Per-plane and per-stream validation
3462306a36Sopenharmony_ci
3562306a36Sopenharmony_ci
3662306a36Sopenharmony_ci7. WIP - Per-plane and per-stream commit
3762306a36Sopenharmony_ci
3862306a36Sopenharmony_ci
3962306a36Sopenharmony_ci8. WIP - Split pipe_ctx into plane and stream resource structs
4062306a36Sopenharmony_ci
4162306a36Sopenharmony_ci
4262306a36Sopenharmony_ci9. Attach plane and stream reources to state object instead of validate_context
4362306a36Sopenharmony_ci
4462306a36Sopenharmony_ci
4562306a36Sopenharmony_ci10. Remove dc_edid_caps and drm_helpers_parse_edid_caps
4662306a36Sopenharmony_ci    * Use drm_display_info instead
4762306a36Sopenharmony_ci    * Remove DC's edid quirks and rely on DRM's quirks (add quirks if needed)
4862306a36Sopenharmony_ci
4962306a36Sopenharmony_ci    "Making sure you use the sink-specific helper libraries and kernel
5062306a36Sopenharmony_ci    subsystems, since there's really no good reason to have 2nd
5162306a36Sopenharmony_ci    implementation of those in the kernel. Looks likes that's done for mst
5262306a36Sopenharmony_ci    and edid parsing. There's still a bit a midlayer feeling to the edid
5362306a36Sopenharmony_ci    parsing side (e.g. dc_edid_caps and dm_helpers_parse_edid_caps, I
5462306a36Sopenharmony_ci    think it'd be much better if you convert that over to reading stuff
5562306a36Sopenharmony_ci    from drm_display_info and if needed, push stuff into the core). Also,
5662306a36Sopenharmony_ci    I can't come up with a good reason why DC needs all this (except to
5762306a36Sopenharmony_ci    reimplement half of our edid quirk table, which really isn't a good
5862306a36Sopenharmony_ci    idea). Might be good if you put this onto the list of things to fix
5962306a36Sopenharmony_ci    long-term, but imo not a blocker. Definitely make sure new stuff
6062306a36Sopenharmony_ci    doesn't slip in (i.e. if you start adding edid quirks to DC instead of
6162306a36Sopenharmony_ci    the drm core, refactoring to use the core edid stuff was pointless)."
6262306a36Sopenharmony_ci    ~ Daniel Vetter
6362306a36Sopenharmony_ci
6462306a36Sopenharmony_ci
6562306a36Sopenharmony_ci11. Remove dc/i2caux. This folder can be somewhat misleading. It's basically an
6662306a36Sopenharmony_ciovery complicated HW programming function for sendind and receiving i2c/aux
6762306a36Sopenharmony_cicommands. We can greatly simplify that and move it into dc/dceXYZ like other
6862306a36Sopenharmony_ciHW blocks.
6962306a36Sopenharmony_ci
7062306a36Sopenharmony_ci12. drm_modeset_lock in MST should no longer be needed in recent kernels
7162306a36Sopenharmony_ci    * Adopt appropriate locking scheme
7262306a36Sopenharmony_ci
7362306a36Sopenharmony_ci13. get_modes and best_encoder callbacks look a bit funny. Can probably rip out
7462306a36Sopenharmony_cia few indirections, and consider removing entirely and using the
7562306a36Sopenharmony_cidrm_atomic_helper_best_encoder default behaviour.
7662306a36Sopenharmony_ci
7762306a36Sopenharmony_ci14. core/dc_debug.c, consider switching to the atomic state debug helpers and
7862306a36Sopenharmony_cimoving all your driver state printing into the various atomic_print_state
7962306a36Sopenharmony_cicallbacks. There's also plans to expose this stuff in a standard way across all
8062306a36Sopenharmony_cidrivers, to make debugging userspace compositors easier across different hw.
8162306a36Sopenharmony_ci
8262306a36Sopenharmony_ci15. Move DP/HDMI dual mode adaptors to drm_dp_dual_mode_helper.c. See
8362306a36Sopenharmony_cidal_ddc_service_i2c_query_dp_dual_mode_adaptor.
8462306a36Sopenharmony_ci
8562306a36Sopenharmony_ci16. Move to core SCDC helpers (I think those are new since initial DC review).
8662306a36Sopenharmony_ci
8762306a36Sopenharmony_ci17. There's still a pretty massive layer cake around dp aux and DPCD handling,
8862306a36Sopenharmony_ciwith like 3 levels of abstraction and using your own structures instead of the
8962306a36Sopenharmony_cistuff in drm_dp_helper.h. drm_dp_helper.h isn't really great and already has 2
9062306a36Sopenharmony_ciincompatible styles, just means more reasons not to add a third (or well third
9162306a36Sopenharmony_cione gets to do the cleanup refactor).
9262306a36Sopenharmony_ci
9362306a36Sopenharmony_ci18. There's a pile of sink handling code, both for DP and HDMI where I didn't
9462306a36Sopenharmony_ciimmediately recognize the standard. I think long term it'd be best for the drm
9562306a36Sopenharmony_cisubsystem if we try to move as much of that into helpers/core as possible, and
9662306a36Sopenharmony_cishare it with drivers. But that's a very long term goal, and by far not just an
9762306a36Sopenharmony_ciissue with DC - other drivers, especially around DP sink handling, are equally
9862306a36Sopenharmony_ciguilty.
9962306a36Sopenharmony_ci
10062306a36Sopenharmony_ci19. DONE - The DC logger is still a rather sore thing, but I know that the
10162306a36Sopenharmony_ciDRM_DEBUG stuff just isn't up to the challenges either. We need to figure out
10262306a36Sopenharmony_cisomething that integrates better with DRM and linux debug printing, while not
10362306a36Sopenharmony_cibeing useless with filtering output. dynamic debug printing might be an option.
10462306a36Sopenharmony_ci
10562306a36Sopenharmony_ci20. Use kernel i2c device to program HDMI retimer. Some boards have an HDMI
10662306a36Sopenharmony_ciretimer that we need to program to pass PHY compliance. Currently that's
10762306a36Sopenharmony_cibypassing the i2c device and goes directly to HW. This should be changed.
10862306a36Sopenharmony_ci
10962306a36Sopenharmony_ci21. Remove vector.c from dc/basics. It's used in DDC code which can probably
11062306a36Sopenharmony_cibe simplified enough to no longer need a vector implementation.
111