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