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