xref: /openbmc/linux/drivers/gpu/drm/amd/display/TODO (revision e1cb3e48)
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
100e1cb3e48SNicholas Kazlauskas19. DONE - The DC logger is still a rather sore thing, but I know that the
101e1cb3e48SNicholas KazlauskasDRM_DEBUG stuff just isn't up to the challenges either. We need to figure out
102e1cb3e48SNicholas Kazlauskassomething that integrates better with DRM and linux debug printing, while not
103e1cb3e48SNicholas 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