Documentation/gpu: Introduce a simple contribution list for display code
This commit adds a contribution list for display under the kernel documentation with some first suggestions. It also drops an old TODO list from the display folder. Cc: Mario Limonciello <mario.limonciello@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Harry Wentland <Harry.Wentland@amd.com> Cc: Hamza Mahfooz <hamza.mahfooz@amd.com> Cc: Christian König <christian.koenig@amd.com> Cc: Aurabindo Pillai <aurabindo.pillai@amd.com> Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> Acked-by: Christian König <christian.koenig@amd.com> Acked-by: Hamza Mahfooz <hamza.mahfooz@amd.com> Signed-off-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
This commit is contained in:
Rodrigo Siqueira
Alex Deucher
parent
21dd98b0ef
commit
ba162ae749
168
Documentation/gpu/amdgpu/display/display-contributing.rst
Normal file
168
Documentation/gpu/amdgpu/display/display-contributing.rst
Normal file
@ -0,0 +1,168 @@
|
|||||||
|
.. _display_todos:
|
||||||
|
|
||||||
|
==============================
|
||||||
|
AMDGPU - Display Contributions
|
||||||
|
==============================
|
||||||
|
|
||||||
|
First of all, if you are here, you probably want to give some technical
|
||||||
|
contribution to the display code, and for that, we say thank you :)
|
||||||
|
|
||||||
|
This page summarizes some of the issues you can help with; keep in mind that
|
||||||
|
this is a static page, and it is always a good idea to try to reach developers
|
||||||
|
in the amdgfx or some of the maintainers. Finally, this page follows the DRM
|
||||||
|
way of creating a TODO list; for more information, check
|
||||||
|
'Documentation/gpu/todo.rst'.
|
||||||
|
|
||||||
|
Gitlab issues
|
||||||
|
=============
|
||||||
|
|
||||||
|
Users can report issues associated with AMD GPUs at:
|
||||||
|
|
||||||
|
- https://gitlab.freedesktop.org/drm/amd
|
||||||
|
|
||||||
|
Usually, we try to add a proper label to all new tickets to make it easy to
|
||||||
|
filter issues. If you can reproduce any problem, you could help by adding more
|
||||||
|
information or fixing the issue.
|
||||||
|
|
||||||
|
Level: diverse
|
||||||
|
|
||||||
|
IGT
|
||||||
|
===
|
||||||
|
|
||||||
|
`IGT`_ provides many integration tests that can be run on your GPU. We always
|
||||||
|
want to pass a large set of tests to increase the test coverage in our CI. If
|
||||||
|
you wish to contribute to the display code but are unsure where a good place
|
||||||
|
is, we recommend you run all IGT tests and try to fix any failure you see in
|
||||||
|
your hardware. Keep in mind that this failure can be an IGT problem or a kernel
|
||||||
|
issue; it is necessary to analyze case-by-case.
|
||||||
|
|
||||||
|
Level: diverse
|
||||||
|
|
||||||
|
.. _IGT: https://gitlab.freedesktop.org/drm/igt-gpu-tools
|
||||||
|
|
||||||
|
Compilation
|
||||||
|
===========
|
||||||
|
|
||||||
|
Fix compilation warnings
|
||||||
|
------------------------
|
||||||
|
|
||||||
|
Enable the W1 or W2 warning level in the kernel compilation and try to fix the
|
||||||
|
issues on the display side.
|
||||||
|
|
||||||
|
Level: Starter
|
||||||
|
|
||||||
|
Fix compilation issues when using um architecture
|
||||||
|
-------------------------------------------------
|
||||||
|
|
||||||
|
Linux has a User-mode Linux (UML) feature, and the kernel can be compiled to
|
||||||
|
the **um** architecture. Compiling for **um** can bring multiple advantages
|
||||||
|
from the test perspective. We currently have some compilation issues in this
|
||||||
|
area that we need to fix.
|
||||||
|
|
||||||
|
Level: Intermediate
|
||||||
|
|
||||||
|
Code Refactor
|
||||||
|
=============
|
||||||
|
|
||||||
|
Add prefix to DC functions to improve the debug with ftrace
|
||||||
|
-----------------------------------------------------------
|
||||||
|
|
||||||
|
The Ftrace debug feature (check 'Documentation/trace/ftrace.rst') is a
|
||||||
|
fantastic way to check the code path when developers try to make sense of a
|
||||||
|
bug. Ftrace provides a filter mechanism that can be useful when the developer
|
||||||
|
has some hunch of which part of the code can cause the issue; for this reason,
|
||||||
|
if a set of functions has a proper prefix, it becomes easy to create a good
|
||||||
|
filter. Additionally, prefixes can improve stack trace readability.
|
||||||
|
|
||||||
|
The DC code does not follow some prefix rules, which makes the Ftrace filter
|
||||||
|
more complicated and reduces the readability of the stack trace. If you want
|
||||||
|
something simple to start contributing to the display, you can make patches for
|
||||||
|
adding prefixes to DC functions. To create those prefixes, use part of the file
|
||||||
|
name as a prefix for all functions in the target file. Check the
|
||||||
|
'amdgpu_dm_crtc.c` and `amdgpu_dm_plane.c` for some references. However, we
|
||||||
|
strongly advise not to send huge patches changing these prefixes; otherwise, it
|
||||||
|
will be hard to review and test, which can generate second thoughts from
|
||||||
|
maintainers. Try small steps; in case of double, you can ask before you put in
|
||||||
|
effort. We recommend first looking at folders like dceXYZ, dcnXYZ, basics,
|
||||||
|
bios, core, clk_mgr, hwss, resource, and irq.
|
||||||
|
|
||||||
|
Level: Starter
|
||||||
|
|
||||||
|
Reduce code duplication
|
||||||
|
-----------------------
|
||||||
|
|
||||||
|
AMD has an extensive portfolio with various dGPUs and APUs that amdgpu
|
||||||
|
supports. To maintain the new hardware release cadence, DCE/DCN was designed in
|
||||||
|
a modular design, making the bring-up for new hardware fast. Over the years,
|
||||||
|
amdgpu accumulated some technical debt in the code duplication area. For this
|
||||||
|
task, it would be a good idea to find a tool that can discover code duplication
|
||||||
|
(including patterns) and use it as guidance to reduce duplications.
|
||||||
|
|
||||||
|
Level: Intermediate
|
||||||
|
|
||||||
|
Make atomic_commit_[check|tail] more readable
|
||||||
|
---------------------------------------------
|
||||||
|
|
||||||
|
The functions responsible for atomic commit and tail are intricate and
|
||||||
|
extensive. In particular `amdgpu_dm_atomic_commit_tail` is a long function and
|
||||||
|
could benefit from being split into smaller helpers. Improvements in this area
|
||||||
|
are more than welcome, but keep in mind that changes in this area will affect
|
||||||
|
all ASICs, meaning that refactoring requires a comprehensive verification; in
|
||||||
|
other words, this effort can take some time for validation.
|
||||||
|
|
||||||
|
Level: Advanced
|
||||||
|
|
||||||
|
Documentation
|
||||||
|
=============
|
||||||
|
|
||||||
|
Expand kernel-doc
|
||||||
|
-----------------
|
||||||
|
|
||||||
|
Many DC functions do not have a proper kernel-doc; understanding a function and
|
||||||
|
adding documentation is a great way to learn more about the amdgpu driver and
|
||||||
|
also leave an outstanding contribution to the entire community.
|
||||||
|
|
||||||
|
Level: Starter
|
||||||
|
|
||||||
|
Beyond AMDGPU
|
||||||
|
=============
|
||||||
|
|
||||||
|
AMDGPU provides features that are not yet enabled in the userspace. This
|
||||||
|
section highlights some of the coolest display features, which could be enabled
|
||||||
|
with the userspace developer helper.
|
||||||
|
|
||||||
|
Enable underlay
|
||||||
|
---------------
|
||||||
|
|
||||||
|
AMD display has this feature called underlay (which you can read more about at
|
||||||
|
'Documentation/GPU/amdgpu/display/mpo-overview.rst') which is intended to
|
||||||
|
save power when playing a video. The basic idea is to put a video in the
|
||||||
|
underlay plane at the bottom and the desktop in the plane above it with a hole
|
||||||
|
in the video area. This feature is enabled in ChromeOS, and from our data
|
||||||
|
measurement, it can save power.
|
||||||
|
|
||||||
|
Level: Unknown
|
||||||
|
|
||||||
|
Adaptive Backlight Modulation (ABM)
|
||||||
|
-----------------------------------
|
||||||
|
|
||||||
|
ABM is a feature that adjusts the display panel's backlight level and pixel
|
||||||
|
values depending on the displayed image. This power-saving feature can be very
|
||||||
|
useful when the system starts to run off battery; since this will impact the
|
||||||
|
display output fidelity, it would be good if this option was something that
|
||||||
|
users could turn on or off.
|
||||||
|
|
||||||
|
Level: Unknown
|
||||||
|
|
||||||
|
|
||||||
|
HDR & Color management & VRR
|
||||||
|
----------------------------
|
||||||
|
|
||||||
|
HDR, Color Management, and VRR are huge topics and it's hard to put these into
|
||||||
|
concise ToDos. If you are interested in this topic, we recommend checking some
|
||||||
|
blog posts from the community developers to better understand some of the
|
||||||
|
specific challenges and people working on the subject. If anyone wants to work
|
||||||
|
on some particular part, we can try to help with some basic guidance. Finally,
|
||||||
|
keep in mind that we already have some kernel-doc in place for those areas.
|
||||||
|
|
||||||
|
Level: Unknown
|
||||||
@ -92,4 +92,5 @@ table of content:
|
|||||||
dcn-blocks.rst
|
dcn-blocks.rst
|
||||||
mpo-overview.rst
|
mpo-overview.rst
|
||||||
dc-debug.rst
|
dc-debug.rst
|
||||||
|
display-contributing.rst
|
||||||
dc-glossary.rst
|
dc-glossary.rst
|
||||||
|
|||||||
@ -1,110 +0,0 @@
|
|||||||
===============================================================================
|
|
||||||
TODOs
|
|
||||||
===============================================================================
|
|
||||||
|
|
||||||
1. Base this on drm-next - WIP
|
|
||||||
|
|
||||||
|
|
||||||
2. Cleanup commit history
|
|
||||||
|
|
||||||
|
|
||||||
3. WIP - Drop page flip helper and use DRM's version
|
|
||||||
|
|
||||||
|
|
||||||
4. DONE - Flatten all DC objects
|
|
||||||
* dc_stream/core_stream/stream should just be dc_stream
|
|
||||||
* Same for other DC objects
|
|
||||||
|
|
||||||
"Is there any major reason to keep all those abstractions?
|
|
||||||
|
|
||||||
Could you collapse everything into struct dc_stream?
|
|
||||||
|
|
||||||
I haven't looked recently but I didn't get the impression there was a
|
|
||||||
lot of design around what was public/protected, more whatever needed
|
|
||||||
to be used by someone else was in public."
|
|
||||||
~ Dave Airlie
|
|
||||||
|
|
||||||
|
|
||||||
5. DONE - Rename DC objects to align more with DRM
|
|
||||||
* dc_surface -> dc_plane_state
|
|
||||||
* dc_stream -> dc_stream_state
|
|
||||||
|
|
||||||
|
|
||||||
6. DONE - Per-plane and per-stream validation
|
|
||||||
|
|
||||||
|
|
||||||
7. WIP - Per-plane and per-stream commit
|
|
||||||
|
|
||||||
|
|
||||||
8. WIP - Split pipe_ctx into plane and stream resource structs
|
|
||||||
|
|
||||||
|
|
||||||
9. Attach plane and stream reources to state object instead of validate_context
|
|
||||||
|
|
||||||
|
|
||||||
10. Remove dc_edid_caps and drm_helpers_parse_edid_caps
|
|
||||||
* Use drm_display_info instead
|
|
||||||
* Remove DC's edid quirks and rely on DRM's quirks (add quirks if needed)
|
|
||||||
|
|
||||||
"Making sure you use the sink-specific helper libraries and kernel
|
|
||||||
subsystems, since there's really no good reason to have 2nd
|
|
||||||
implementation of those in the kernel. Looks likes that's done for mst
|
|
||||||
and edid parsing. There's still a bit a midlayer feeling to the edid
|
|
||||||
parsing side (e.g. dc_edid_caps and dm_helpers_parse_edid_caps, I
|
|
||||||
think it'd be much better if you convert that over to reading stuff
|
|
||||||
from drm_display_info and if needed, push stuff into the core). Also,
|
|
||||||
I can't come up with a good reason why DC needs all this (except to
|
|
||||||
reimplement half of our edid quirk table, which really isn't a good
|
|
||||||
idea). Might be good if you put this onto the list of things to fix
|
|
||||||
long-term, but imo not a blocker. Definitely make sure new stuff
|
|
||||||
doesn't slip in (i.e. if you start adding edid quirks to DC instead of
|
|
||||||
the drm core, refactoring to use the core edid stuff was pointless)."
|
|
||||||
~ Daniel Vetter
|
|
||||||
|
|
||||||
|
|
||||||
11. Remove dc/i2caux. This folder can be somewhat misleading. It's basically an
|
|
||||||
overy complicated HW programming function for sendind and receiving i2c/aux
|
|
||||||
commands. We can greatly simplify that and move it into dc/dceXYZ like other
|
|
||||||
HW blocks.
|
|
||||||
|
|
||||||
12. drm_modeset_lock in MST should no longer be needed in recent kernels
|
|
||||||
* Adopt appropriate locking scheme
|
|
||||||
|
|
||||||
13. get_modes and best_encoder callbacks look a bit funny. Can probably rip out
|
|
||||||
a few indirections, and consider removing entirely and using the
|
|
||||||
drm_atomic_helper_best_encoder default behaviour.
|
|
||||||
|
|
||||||
14. core/dc_debug.c, consider switching to the atomic state debug helpers and
|
|
||||||
moving all your driver state printing into the various atomic_print_state
|
|
||||||
callbacks. There's also plans to expose this stuff in a standard way across all
|
|
||||||
drivers, to make debugging userspace compositors easier across different hw.
|
|
||||||
|
|
||||||
15. Move DP/HDMI dual mode adaptors to drm_dp_dual_mode_helper.c. See
|
|
||||||
dal_ddc_service_i2c_query_dp_dual_mode_adaptor.
|
|
||||||
|
|
||||||
16. Move to core SCDC helpers (I think those are new since initial DC review).
|
|
||||||
|
|
||||||
17. There's still a pretty massive layer cake around dp aux and DPCD handling,
|
|
||||||
with like 3 levels of abstraction and using your own structures instead of the
|
|
||||||
stuff in drm_dp_helper.h. drm_dp_helper.h isn't really great and already has 2
|
|
||||||
incompatible styles, just means more reasons not to add a third (or well third
|
|
||||||
one gets to do the cleanup refactor).
|
|
||||||
|
|
||||||
18. There's a pile of sink handling code, both for DP and HDMI where I didn't
|
|
||||||
immediately recognize the standard. I think long term it'd be best for the drm
|
|
||||||
subsystem if we try to move as much of that into helpers/core as possible, and
|
|
||||||
share it with drivers. But that's a very long term goal, and by far not just an
|
|
||||||
issue with DC - other drivers, especially around DP sink handling, are equally
|
|
||||||
guilty.
|
|
||||||
|
|
||||||
19. DONE - The DC logger is still a rather sore thing, but I know that the
|
|
||||||
DRM_DEBUG stuff just isn't up to the challenges either. We need to figure out
|
|
||||||
something that integrates better with DRM and linux debug printing, while not
|
|
||||||
being useless with filtering output. dynamic debug printing might be an option.
|
|
||||||
|
|
||||||
20. Use kernel i2c device to program HDMI retimer. Some boards have an HDMI
|
|
||||||
retimer that we need to program to pass PHY compliance. Currently that's
|
|
||||||
bypassing the i2c device and goes directly to HW. This should be changed.
|
|
||||||
|
|
||||||
21. Remove vector.c from dc/basics. It's used in DDC code which can probably
|
|
||||||
be simplified enough to no longer need a vector implementation.
|
|
||||||
Loading…
Reference in New Issue
Block a user