1153ae532SHarry Wentland=============================================================================== 2153ae532SHarry WentlandTODOs 3153ae532SHarry Wentland=============================================================================== 4153ae532SHarry Wentland 5153ae532SHarry Wentland1. Base this on drm-next - WIP 6153ae532SHarry Wentland 7153ae532SHarry Wentland 8153ae532SHarry Wentland2. Cleanup commit history 9153ae532SHarry Wentland 10153ae532SHarry Wentland 11153ae532SHarry Wentland3. WIP - Drop page flip helper and use DRM's version 12153ae532SHarry Wentland 13153ae532SHarry Wentland 14153ae532SHarry Wentland4. DONE - Flatten all DC objects 15153ae532SHarry Wentland * dc_stream/core_stream/stream should just be dc_stream 16153ae532SHarry Wentland * Same for other DC objects 17153ae532SHarry Wentland 18153ae532SHarry Wentland "Is there any major reason to keep all those abstractions? 19153ae532SHarry Wentland 20153ae532SHarry Wentland Could you collapse everything into struct dc_stream? 21153ae532SHarry Wentland 22153ae532SHarry Wentland I haven't looked recently but I didn't get the impression there was a 23153ae532SHarry Wentland lot of design around what was public/protected, more whatever needed 24153ae532SHarry Wentland to be used by someone else was in public." 25153ae532SHarry Wentland ~ Dave Airlie 26153ae532SHarry Wentland 27153ae532SHarry Wentland 28153ae532SHarry Wentland5. DONE - Rename DC objects to align more with DRM 29153ae532SHarry Wentland * dc_surface -> dc_plane_state 30153ae532SHarry Wentland * dc_stream -> dc_stream_state 31153ae532SHarry Wentland 32153ae532SHarry Wentland 33153ae532SHarry Wentland6. DONE - Per-plane and per-stream validation 34153ae532SHarry Wentland 35153ae532SHarry Wentland 36153ae532SHarry Wentland7. WIP - Per-plane and per-stream commit 37153ae532SHarry Wentland 38153ae532SHarry Wentland 39153ae532SHarry Wentland8. WIP - Split pipe_ctx into plane and stream resource structs 40153ae532SHarry Wentland 41153ae532SHarry Wentland 42153ae532SHarry Wentland9. Attach plane and stream reources to state object instead of validate_context 43153ae532SHarry Wentland 44153ae532SHarry Wentland 45153ae532SHarry Wentland10. Remove dc_edid_caps and drm_helpers_parse_edid_caps 46153ae532SHarry Wentland * Use drm_display_info instead 47153ae532SHarry Wentland * Remove DC's edid quirks and rely on DRM's quirks (add quirks if needed) 48153ae532SHarry Wentland 49153ae532SHarry Wentland "Making sure you use the sink-specific helper libraries and kernel 50153ae532SHarry Wentland subsystems, since there's really no good reason to have 2nd 51153ae532SHarry Wentland implementation of those in the kernel. Looks likes that's done for mst 52153ae532SHarry Wentland and edid parsing. There's still a bit a midlayer feeling to the edid 53153ae532SHarry Wentland parsing side (e.g. dc_edid_caps and dm_helpers_parse_edid_caps, I 54153ae532SHarry Wentland think it'd be much better if you convert that over to reading stuff 55153ae532SHarry Wentland from drm_display_info and if needed, push stuff into the core). Also, 56153ae532SHarry Wentland I can't come up with a good reason why DC needs all this (except to 57153ae532SHarry Wentland reimplement half of our edid quirk table, which really isn't a good 58153ae532SHarry Wentland idea). Might be good if you put this onto the list of things to fix 59153ae532SHarry Wentland long-term, but imo not a blocker. Definitely make sure new stuff 60153ae532SHarry Wentland doesn't slip in (i.e. if you start adding edid quirks to DC instead of 61153ae532SHarry Wentland the drm core, refactoring to use the core edid stuff was pointless)." 62153ae532SHarry Wentland ~ Daniel Vetter 63153ae532SHarry Wentland 64153ae532SHarry Wentland 652e12d9b7SHarry Wentland11. Remove dc/i2caux. This folder can be somewhat misleading. It's basically an 662e12d9b7SHarry Wentlandovery complicated HW programming function for sendind and receiving i2c/aux 672e12d9b7SHarry Wentlandcommands. We can greatly simplify that and move it into dc/dceXYZ like other 682e12d9b7SHarry WentlandHW blocks. 69153ae532SHarry Wentland 70153ae532SHarry Wentland12. drm_modeset_lock in MST should no longer be needed in recent kernels 71153ae532SHarry Wentland * Adopt appropriate locking scheme 7282b400a6SDaniel Vetter 7382b400a6SDaniel Vetter13. get_modes and best_encoder callbacks look a bit funny. Can probably rip out 7482b400a6SDaniel Vettera few indirections, and consider removing entirely and using the 7582b400a6SDaniel Vetterdrm_atomic_helper_best_encoder default behaviour. 7682b400a6SDaniel Vetter 7782b400a6SDaniel Vetter14. core/dc_debug.c, consider switching to the atomic state debug helpers and 7882b400a6SDaniel Vettermoving all your driver state printing into the various atomic_print_state 7982b400a6SDaniel Vettercallbacks. There's also plans to expose this stuff in a standard way across all 8082b400a6SDaniel Vetterdrivers, to make debugging userspace compositors easier across different hw. 8182b400a6SDaniel Vetter 822e12d9b7SHarry Wentland15. Move DP/HDMI dual mode adaptors to drm_dp_dual_mode_helper.c. See 832e12d9b7SHarry Wentlanddal_ddc_service_i2c_query_dp_dual_mode_adaptor. 8482b400a6SDaniel Vetter 8582b400a6SDaniel Vetter16. Move to core SCDC helpers (I think those are new since initial DC review). 8682b400a6SDaniel Vetter 8782b400a6SDaniel Vetter17. There's still a pretty massive layer cake around dp aux and DPCD handling, 8882b400a6SDaniel Vetterwith like 3 levels of abstraction and using your own structures instead of the 8982b400a6SDaniel Vetterstuff in drm_dp_helper.h. drm_dp_helper.h isn't really great and already has 2 9082b400a6SDaniel Vetterincompatible styles, just means more reasons not to add a third (or well third 9182b400a6SDaniel Vetterone gets to do the cleanup refactor). 9282b400a6SDaniel Vetter 9382b400a6SDaniel Vetter18. There's a pile of sink handling code, both for DP and HDMI where I didn't 9482b400a6SDaniel Vetterimmediately recognize the standard. I think long term it'd be best for the drm 9582b400a6SDaniel Vettersubsystem if we try to move as much of that into helpers/core as possible, and 9682b400a6SDaniel Vettershare it with drivers. But that's a very long term goal, and by far not just an 9782b400a6SDaniel Vetterissue with DC - other drivers, especially around DP sink handling, are equally 9882b400a6SDaniel Vetterguilty. 9982b400a6SDaniel Vetter 100*e1cb3e48SNicholas Kazlauskas19. DONE - The DC logger is still a rather sore thing, but I know that the 101*e1cb3e48SNicholas KazlauskasDRM_DEBUG stuff just isn't up to the challenges either. We need to figure out 102*e1cb3e48SNicholas Kazlauskassomething that integrates better with DRM and linux debug printing, while not 103*e1cb3e48SNicholas Kazlauskasbeing useless with filtering output. dynamic debug printing might be an option. 1042e12d9b7SHarry Wentland 1052e12d9b7SHarry Wentland20. Use kernel i2c device to program HDMI retimer. Some boards have an HDMI 1062e12d9b7SHarry Wentlandretimer that we need to program to pass PHY compliance. Currently that's 1072e12d9b7SHarry Wentlandbypassing the i2c device and goes directly to HW. This should be changed. 108cf3d1a8cSHarry Wentland 109cf3d1a8cSHarry Wentland21. Remove vector.c from dc/basics. It's used in DDC code which can probably 110cf3d1a8cSHarry Wentlandbe simplified enough to no longer need a vector implementation. 111