path: root/drivers/gpu/drm/amd/display/TODO
AgeCommit message (Collapse)AuthorFilesLines
2018-07-13drm/amd/display: Convert remaining loggers off dc_loggerNicholas Kazlauskas1-4/+4
- Removed dal/dm/dc loggers from linux, switched to kernel prints - Modified functions that used these directly to use macros - dc_logger support is completely dropped from Linux Signed-off-by: Nicholas Kazlauskas <> Reviewed-by: Harry Wentland <> Signed-off-by: Alex Deucher <>
2017-12-14drm/amd/display: Add TODO item to remove vector.cHarry Wentland1-0/+3
Signed-off-by: Harry Wentland <> Reviewed-by: Jordan Lazare <> Acked-by: Harry Wentland <> Signed-off-by: Alex Deucher <>
2017-09-28drm/amd/display: DC I2C reviewHarry Wentland1-15/+10
While reviewing I2C in DC identified a few places. Added a couple to the TODO list. 1) Connector info read See get_ext_display_connection_info On some boards the connector information has to be read through a special I2C channel. This line is only used for this purpose and only on driver init. 2) SCDC stuff This should all be reworked to go through DRM's SCDC code. When this is done some unnecessary I2C code can be retired as well. 3) Max TMDS clock read See dal_ddc_service_i2c_query_dp_dual_mode_adaptor This should happen in DRM as well. I haven't checked if there's currently functionality in DRM. If not we can propose something. 4) HDMI retimer programming Some boards have an HDMI retimer that we need to program to pass PHY compliance. 1 & 3 might be a good exercise if someone is looking for things to do. v2: Merge dp_dual_mode_adaptor TODO Acked-by: Alex Deucher <> Signed-off-by: Harry Wentland <> Acked-by: Daniel Vetter <> Signed-off-by: Alex Deucher <>
2017-09-28drm/amd: DC pull request reviewDaniel Vetter1-0/+31
Ok, here's one more attempt at scrolling through 130k diff. Overall verdict from me is that DC is big project, and like any big project it's never done. So at least for me the goal isn't to make things perfect, becaue if that's the hoop to jump through we wouldn't have any gpu drivers at all. More important is whether merging a new driver base will benefit the overall subsystem, and here this primarily means whether the DC team understands how upstream works and is designed, and whether the code is largely aligned with upstream (especially the atomic modeset) architecture. Looking back over the last two years I think that's the case now, so Acked-by: Daniel Vetter <> for merging this pull. While scrolling through the pull I spotted a bunch more things that should be refactored, but most of these will be a real pain with DC is out of tree, and much easier in tree since in many of these areas the in-tree helpers aren't up to snuff yet for what DC needs. That kind of work is best done when there's one tree with everything integrated. That's also why I think we should merge DC into drm-next directly, so we can get started on the integration polish right away. That has a bit higher risk of Linus having a spazz, so here's my recommendation for merging: - There's a few additions to drm_dp_helper.h sprinkled all over the pull. I think those should be put into a patch of it's own, and merged first. No need to rebase DC, git merge will dtrt and not end up with duplicates. - dm_alloc/realloc/free is something Dave Airlie noticed, and I agree it's an easy red flag that might upset Linus. cocci can fix this easy, so no real problem I think to patch up in one big patch (I thought we've had a "remove malloc wrappers" todo item in the very first review, apparently there was more than one such wrapper). - The history is huge, but AMD folks want to keep it if possible, and I see the value in that. Would be good to get an ack from Linus for that (but shouldn't be an issue, not the first time we've merged the full history of out-of-tree work). Short&longer term TODO items are still tracked, might be a good idea to integrate those the overall drm todo in our gpu documentation, for more visibility. So in a way this is kinda like staging, except not with the horribly broken process of having an entirely separate tree for staging drivers which just makes refactoring needlessly painful (which defeats the point of staging really). So staging-within-the-subsystem. We've had that before, with early nouveau. And yes some of the files are utterly horrible to read and not anything close to kernel coding style standards. But that's the point, they're essentially gospel from hw engineers that happens to be parseable by gcc. Signed-off-by: Daniel Vetter <> Reviewed-by: Harry Wentland <> Signed-off-by: Alex Deucher <>
2017-09-26drm/amd/display: Add a TODO listHarry Wentland1-0/+81
Signed-off-by: Harry Wentland <> Reviewed-by: Jordan Lazare <> Signed-off-by: Alex Deucher <>