| TODO (82b400a62f2fd42b87f91a298c5641d0ead99251) | TODO (2e12d9b761212053d0260b6309155c5e8a65948c) |
|---|---|
| 1=============================================================================== 2TODOs 3=============================================================================== 4 51. Base this on drm-next - WIP 6 7 82. Cleanup commit history --- 48 unchanged lines hidden (view full) --- 57 reimplement half of our edid quirk table, which really isn't a good 58 idea). Might be good if you put this onto the list of things to fix 59 long-term, but imo not a blocker. Definitely make sure new stuff 60 doesn't slip in (i.e. if you start adding edid quirks to DC instead of 61 the drm core, refactoring to use the core edid stuff was pointless)." 62 ~ Daniel Vetter 63 64 | 1=============================================================================== 2TODOs 3=============================================================================== 4 51. Base this on drm-next - WIP 6 7 82. Cleanup commit history --- 48 unchanged lines hidden (view full) --- 57 reimplement half of our edid quirk table, which really isn't a good 58 idea). Might be good if you put this onto the list of things to fix 59 long-term, but imo not a blocker. Definitely make sure new stuff 60 doesn't slip in (i.e. if you start adding edid quirks to DC instead of 61 the drm core, refactoring to use the core edid stuff was pointless)." 62 ~ Daniel Vetter 63 64 |
| 6511. Remove existing i2c implementation from DC | 6511. Remove dc/i2caux. This folder can be somewhat misleading. It's basically an 66overy complicated HW programming function for sendind and receiving i2c/aux 67commands. We can greatly simplify that and move it into dc/dceXYZ like other 68HW blocks. |
| 66 | 69 |
| 67 "Similar story for i2c, it uses the kernel's i2c code now, but there's 68 still a full i2c implementation hidden beneath that in 69 display/dc/i2caux. Kinda not cool, but imo ok if you fix that 70 post-merging (perhaps by not including any of this in the linux DC 71 code in the upstream kernel, but as an aux module in your internal 72 codebase since there you probably need that, same applies to the edid 73 parsing DC still does. For both cases I assume that the minimal shim 74 you need on linux (bit banging and edid parsing isn't rocket since) is 75 a lot less than the glue code to interface with the dc-provided 76 abstraction." 77 ~ Daniel Vetter 78 79 | |
| 8012. drm_modeset_lock in MST should no longer be needed in recent kernels 81 * Adopt appropriate locking scheme 82 8313. get_modes and best_encoder callbacks look a bit funny. Can probably rip out 84a few indirections, and consider removing entirely and using the 85drm_atomic_helper_best_encoder default behaviour. 86 8714. core/dc_debug.c, consider switching to the atomic state debug helpers and 88moving all your driver state printing into the various atomic_print_state 89callbacks. There's also plans to expose this stuff in a standard way across all 90drivers, to make debugging userspace compositors easier across different hw. 91 | 7012. drm_modeset_lock in MST should no longer be needed in recent kernels 71 * Adopt appropriate locking scheme 72 7313. get_modes and best_encoder callbacks look a bit funny. Can probably rip out 74a few indirections, and consider removing entirely and using the 75drm_atomic_helper_best_encoder default behaviour. 76 7714. core/dc_debug.c, consider switching to the atomic state debug helpers and 78moving all your driver state printing into the various atomic_print_state 79callbacks. There's also plans to expose this stuff in a standard way across all 80drivers, to make debugging userspace compositors easier across different hw. 81 |
| 9215. Move DP/HDMI dual mode adaptors to drm_dp_dual_mode_helper.c. | 8215. Move DP/HDMI dual mode adaptors to drm_dp_dual_mode_helper.c. See 83dal_ddc_service_i2c_query_dp_dual_mode_adaptor. |
| 93 9416. Move to core SCDC helpers (I think those are new since initial DC review). 95 9617. There's still a pretty massive layer cake around dp aux and DPCD handling, 97with like 3 levels of abstraction and using your own structures instead of the 98stuff in drm_dp_helper.h. drm_dp_helper.h isn't really great and already has 2 99incompatible styles, just means more reasons not to add a third (or well third 100one gets to do the cleanup refactor). --- 4 unchanged lines hidden (view full) --- 105share it with drivers. But that's a very long term goal, and by far not just an 106issue with DC - other drivers, especially around DP sink handling, are equally 107guilty. 108 10919. The DC logger is still a rather sore thing, but I know that the DRM_DEBUG 110stuff just isn't up to the challenges either. We need to figure out something 111that integrates better with DRM and linux debug printing, while not being 112useless with filtering output. dynamic debug printing might be an option. | 84 8516. Move to core SCDC helpers (I think those are new since initial DC review). 86 8717. There's still a pretty massive layer cake around dp aux and DPCD handling, 88with like 3 levels of abstraction and using your own structures instead of the 89stuff in drm_dp_helper.h. drm_dp_helper.h isn't really great and already has 2 90incompatible styles, just means more reasons not to add a third (or well third 91one gets to do the cleanup refactor). --- 4 unchanged lines hidden (view full) --- 96share it with drivers. But that's a very long term goal, and by far not just an 97issue with DC - other drivers, especially around DP sink handling, are equally 98guilty. 99 10019. The DC logger is still a rather sore thing, but I know that the DRM_DEBUG 101stuff just isn't up to the challenges either. We need to figure out something 102that integrates better with DRM and linux debug printing, while not being 103useless with filtering output. dynamic debug printing might be an option. |
| 104 10520. Use kernel i2c device to program HDMI retimer. Some boards have an HDMI 106retimer that we need to program to pass PHY compliance. Currently that's 107bypassing the i2c device and goes directly to HW. This should be changed. |
|