Since radeon support about 18 years of asics and 8 generations of display hardwares, the conversion will be a huge amout of work and there is a huge potential regressions, so I choose two drivers used by kvm/qeum, which are a lot simpler than mordern GPUs.
The following specified what needs to be done to support atomic modeset updates using Daniel's new helper libraries.
Phase 1 - Reworking the Driver Backend Functions for Planes
There are two big mismatches between the new atomic semantics and the legacy ioctl interfaces:
1) The primary plane is no longer tied to CRTC.
2) Atomic updates of multiple planes isn't supported at all.
Both issuse are addressed by adding new driver backend callbacks. So we should implement legacy entry points in term of new atomic callbacks.
The first step is to rework the ->disable/update_plane hooks using the transitional helper implementations drm_plane_helper_update/disable. The following new driver callbacks are needed:
- CRTCs
->atomic_check() - validate state
->atomic_begin() - prepare for updates
->atomic_flush() - apply updates atomically
->atomic_set_nofb - apply CRTC timings, this callback must be implement
- planes
->prepare_fb() - setup the framebuffers, e.g. pin backing storage into memory and setup any needed hardware resources
->cleanup_fb() - e.g. unpi backing storage
->atomic_check() - validate state
->atomic_update() - per-plane update, like setting up the new viewport or the new base address of the framebuffer for each plane
->atomic_disable() - disable plane
The provided helpers functions drm_helper_crtc_mode_set and drm_helper_crtc_mode_set_base then implement the callbacks required by the CRTC helpers in terms of new ->mode_set_nofb callback and the the above newly implmented plane helper callbacks.
Phase 2 - Wire up the Atomic State Object Scaffolding
The goal of this phase is to get all the state object handing needed for atomic updates into place.
wire up state callbacks for planes, CRTCs and connectors:
patching up the state objects in legacy code paths
- make sure that we can partially transition to atomic updates.
- drm_atomic_set_fb_for_plane
- usually the only place this is need to be manually added is the ->page_flip callback.
- all ->mode_fixup callbacks need to be audited
- not depend upon any state which is only set in the various CRTC helpers.
- not tracked by the atomic state objects.
Phase 3 - Rolling out Atomic Support
Replace all the legacy entry pointers with the corresponding functions from the atomic helper library to implement them in terms of atomic.
Rip out Cruft
There is quite a bit of cleanup work possible afterwards.
- ->mode_set() and ->mode_set_base() are no longer used, ->mode_set_nofb() does what is necessary to set a mode.
- atomic DPMS, DPMS standby and suspend are no more, ->disable() and ->enable() callbacks are used now, atomic DPMS is a full off or on cycle
References
(now - 15 April)
- get familiar with the Atomic Modeset Support for KMS Drivers
- take a look at the ongoing atomic mode-setting conversations and those already committed to drm-next
- discuss with the mentor about some confusing details on the code
(16 April - 27 April )
- get to know more about the DRM_BOCHS and DRM_CIRRUS_QEMU subsystem driver code
- setup the kvm/qemu environment for further test
- code: write my first version of the atomic mode-setting conversion for DRM_BOCHS driver
- discuss with the mentor about the conversion if the patches meet the demand
(19 May - 15 June)
- code: write my second version of the atomic mode-setting conversion for DRM_BOCHS driver
- test: test the new converted Bochs driver on qemu, using the '-vga std' option
(16 June - 25 June)
- get to know more about the DRM_CIRRUS_QEMU subsystem
(26 June - 30 June)
- arrange documentations for mid-term evaluations
(1 July - 3 July)
- submit mid-term evaluations
(4 July - 17 August)
- code: write the atomic mode-setting conversion for DRM_CIRRUS_QEMU (same schedule with DRM_BOCHS)
- do more test to assure the correctness and check the code.
(18 August - 21 August)
- arrange documets for reports, scub code, write tests, improve documentation, etc.
(22 August - 27 August)
- submit final evaluations.
(28 August - 30 August)
- submit required code samples to Google.
(after GSoC)
- as Alex Deucher suggest, in additon to the two virtual drivers I am going to convert, udl (KMS driver
for the USB displaylink video adapters) is another choice for me, as I am still not that skilled in
Atomic Modeset Support for KMS Drivers, I will give it a shot after GSoC.
- as for the Radeon, since Alex said the community have no immediate plans to convert it to atomic, I
hope when it is on the agenda in the future, I can do something helpful.