Skip to content
Snippets Groups Projects
  • Lyude Paul's avatar
    3e275b69
    WIP: rust: drm/kms: Add VblankSupport · 3e275b69
    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's avatarLyude 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.
    
    TODO:
    
    * Technically this patch introduces a soundness issue. We currently allow
      access to a kernel::drm::Device (through UnregisteredKmsDevice's Deref
      implementation) within the kernel::drm::kms::Kms::create_objects trait
      method. A caller could potentially access an uninitialized mutex by
      calling Crtc::vblank_lock() within this context.
      My solution for this is likely going to be adding unregistered variants
      of Crtc and other mode-objects that don't have access to the full set of
      methods on mode objects.
    3e275b69
    History
    WIP: rust: drm/kms: Add VblankSupport
    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's avatarLyude 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.
    
    TODO:
    
    * Technically this patch introduces a soundness issue. We currently allow
      access to a kernel::drm::Device (through UnregisteredKmsDevice's Deref
      implementation) within the kernel::drm::kms::Kms::create_objects trait
      method. A caller could potentially access an uninitialized mutex by
      calling Crtc::vblank_lock() within this context.
      My solution for this is likely going to be adding unregistered variants
      of Crtc and other mode-objects that don't have access to the full set of
      methods on mode objects.
vblank.c 186 B