-
Lyude Paul authored
This commit adds bindings for implementing vblank support for a driver's CRTCs. These bindings are optional, to account for the fact that not all drivers have dedicated hardware vblanks. In order to accomplish this, we introduce the VblankSupport trait which can be implemented on DriverCrtc by drivers which support vblanks. This works in the same way as the main Kms trait - drivers which don't support hardware vblanks can simply pass PhantomData<Self> to the associated type on DriverCrtc. If a driver chooses to implement VblankSupport, VblankImpl will be implemented by DRM automatically - and can be passed to the VblankImpl associated type on DriverCrtc. Additionally, we gate methods which only apply to vblank-supporting drivers by introducing a VblankDriverCrtc trait that is automatically implemented by DRM for CRTC drivers implementing VblankSupport. This works basically in the same way as Kms and KmsDriver, but for CRTCs. Signed-off-by:
Lyude Paul <lyude@redhat.com> --- Notes: * One thing to keep in mind: this trait is implemented on the CRTC as opposed to the KMS driver due to the possibility that a driver may have multiple different types of CRTCs. As a result, it's not impossible that there could potentially be differences in each type's vblank hardware implementation. In theory this could lead to a driver mistakenly only implementing VblankSupport for some CRTCs and not others, which isn't really defined behavior in DRM. As such, one of the dependencies in the branch for this patch series preview is a fix to ensure that DRM disallows registering drivers that make this mistake. V3: * Update to the latest SpinlockIrq changes * Fix typo on get_vblank_timestamp() * Break statements in vblank_crtc() up a bit * Add comments around all uses of ManuallyDrop * Improve SAFETY comments * Make some unsafe scopes smaller
Lyude Paul authoredThis commit adds bindings for implementing vblank support for a driver's CRTCs. These bindings are optional, to account for the fact that not all drivers have dedicated hardware vblanks. In order to accomplish this, we introduce the VblankSupport trait which can be implemented on DriverCrtc by drivers which support vblanks. This works in the same way as the main Kms trait - drivers which don't support hardware vblanks can simply pass PhantomData<Self> to the associated type on DriverCrtc. If a driver chooses to implement VblankSupport, VblankImpl will be implemented by DRM automatically - and can be passed to the VblankImpl associated type on DriverCrtc. Additionally, we gate methods which only apply to vblank-supporting drivers by introducing a VblankDriverCrtc trait that is automatically implemented by DRM for CRTC drivers implementing VblankSupport. This works basically in the same way as Kms and KmsDriver, but for CRTCs. Signed-off-by:
Lyude Paul <lyude@redhat.com> --- Notes: * One thing to keep in mind: this trait is implemented on the CRTC as opposed to the KMS driver due to the possibility that a driver may have multiple different types of CRTCs. As a result, it's not impossible that there could potentially be differences in each type's vblank hardware implementation. In theory this could lead to a driver mistakenly only implementing VblankSupport for some CRTCs and not others, which isn't really defined behavior in DRM. As such, one of the dependencies in the branch for this patch series preview is a fix to ensure that DRM disallows registering drivers that make this mistake. V3: * Update to the latest SpinlockIrq changes * Fix typo on get_vblank_timestamp() * Break statements in vblank_crtc() up a bit * Add comments around all uses of ManuallyDrop * Improve SAFETY comments * Make some unsafe scopes smaller