cachepc-linux

Fork of AMDESE/linux with modifications for CachePC side-channel attack
git clone https://git.sinitax.com/sinitax/cachepc-linux
Log | Files | Refs | README | LICENSE | sfeed.txt

drm-internals.rst (7869B)


      1=============
      2DRM Internals
      3=============
      4
      5This chapter documents DRM internals relevant to driver authors and
      6developers working to add support for the latest features to existing
      7drivers.
      8
      9First, we go over some typical driver initialization requirements, like
     10setting up command buffers, creating an initial output configuration,
     11and initializing core services. Subsequent sections cover core internals
     12in more detail, providing implementation notes and examples.
     13
     14The DRM layer provides several services to graphics drivers, many of
     15them driven by the application interfaces it provides through libdrm,
     16the library that wraps most of the DRM ioctls. These include vblank
     17event handling, memory management, output management, framebuffer
     18management, command submission & fencing, suspend/resume support, and
     19DMA services.
     20
     21Driver Initialization
     22=====================
     23
     24At the core of every DRM driver is a :c:type:`struct drm_driver
     25<drm_driver>` structure. Drivers typically statically initialize
     26a drm_driver structure, and then pass it to
     27drm_dev_alloc() to allocate a device instance. After the
     28device instance is fully initialized it can be registered (which makes
     29it accessible from userspace) using drm_dev_register().
     30
     31The :c:type:`struct drm_driver <drm_driver>` structure
     32contains static information that describes the driver and features it
     33supports, and pointers to methods that the DRM core will call to
     34implement the DRM API. We will first go through the :c:type:`struct
     35drm_driver <drm_driver>` static information fields, and will
     36then describe individual operations in details as they get used in later
     37sections.
     38
     39Driver Information
     40------------------
     41
     42Major, Minor and Patchlevel
     43~~~~~~~~~~~~~~~~~~~~~~~~~~~
     44
     45int major; int minor; int patchlevel;
     46The DRM core identifies driver versions by a major, minor and patch
     47level triplet. The information is printed to the kernel log at
     48initialization time and passed to userspace through the
     49DRM_IOCTL_VERSION ioctl.
     50
     51The major and minor numbers are also used to verify the requested driver
     52API version passed to DRM_IOCTL_SET_VERSION. When the driver API
     53changes between minor versions, applications can call
     54DRM_IOCTL_SET_VERSION to select a specific version of the API. If the
     55requested major isn't equal to the driver major, or the requested minor
     56is larger than the driver minor, the DRM_IOCTL_SET_VERSION call will
     57return an error. Otherwise the driver's set_version() method will be
     58called with the requested version.
     59
     60Name, Description and Date
     61~~~~~~~~~~~~~~~~~~~~~~~~~~
     62
     63char \*name; char \*desc; char \*date;
     64The driver name is printed to the kernel log at initialization time,
     65used for IRQ registration and passed to userspace through
     66DRM_IOCTL_VERSION.
     67
     68The driver description is a purely informative string passed to
     69userspace through the DRM_IOCTL_VERSION ioctl and otherwise unused by
     70the kernel.
     71
     72The driver date, formatted as YYYYMMDD, is meant to identify the date of
     73the latest modification to the driver. However, as most drivers fail to
     74update it, its value is mostly useless. The DRM core prints it to the
     75kernel log at initialization time and passes it to userspace through the
     76DRM_IOCTL_VERSION ioctl.
     77
     78Module Initialization
     79---------------------
     80
     81.. kernel-doc:: include/drm/drm_module.h
     82   :doc: overview
     83
     84Managing Ownership of the Framebuffer Aperture
     85----------------------------------------------
     86
     87.. kernel-doc:: drivers/gpu/drm/drm_aperture.c
     88   :doc: overview
     89
     90.. kernel-doc:: include/drm/drm_aperture.h
     91   :internal:
     92
     93.. kernel-doc:: drivers/gpu/drm/drm_aperture.c
     94   :export:
     95
     96Device Instance and Driver Handling
     97-----------------------------------
     98
     99.. kernel-doc:: drivers/gpu/drm/drm_drv.c
    100   :doc: driver instance overview
    101
    102.. kernel-doc:: include/drm/drm_device.h
    103   :internal:
    104
    105.. kernel-doc:: include/drm/drm_drv.h
    106   :internal:
    107
    108.. kernel-doc:: drivers/gpu/drm/drm_drv.c
    109   :export:
    110
    111Driver Load
    112-----------
    113
    114Component Helper Usage
    115~~~~~~~~~~~~~~~~~~~~~~
    116
    117.. kernel-doc:: drivers/gpu/drm/drm_drv.c
    118   :doc: component helper usage recommendations
    119
    120Memory Manager Initialization
    121~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    122
    123Every DRM driver requires a memory manager which must be initialized at
    124load time. DRM currently contains two memory managers, the Translation
    125Table Manager (TTM) and the Graphics Execution Manager (GEM). This
    126document describes the use of the GEM memory manager only. See ? for
    127details.
    128
    129Miscellaneous Device Configuration
    130~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    131
    132Another task that may be necessary for PCI devices during configuration
    133is mapping the video BIOS. On many devices, the VBIOS describes device
    134configuration, LCD panel timings (if any), and contains flags indicating
    135device state. Mapping the BIOS can be done using the pci_map_rom()
    136call, a convenience function that takes care of mapping the actual ROM,
    137whether it has been shadowed into memory (typically at address 0xc0000)
    138or exists on the PCI device in the ROM BAR. Note that after the ROM has
    139been mapped and any necessary information has been extracted, it should
    140be unmapped; on many devices, the ROM address decoder is shared with
    141other BARs, so leaving it mapped could cause undesired behaviour like
    142hangs or memory corruption.
    143
    144Managed Resources
    145-----------------
    146
    147.. kernel-doc:: drivers/gpu/drm/drm_managed.c
    148   :doc: managed resources
    149
    150.. kernel-doc:: drivers/gpu/drm/drm_managed.c
    151   :export:
    152
    153.. kernel-doc:: include/drm/drm_managed.h
    154   :internal:
    155
    156Bus-specific Device Registration and PCI Support
    157------------------------------------------------
    158
    159A number of functions are provided to help with device registration. The
    160functions deal with PCI and platform devices respectively and are only
    161provided for historical reasons. These are all deprecated and shouldn't
    162be used in new drivers. Besides that there's a few helpers for pci
    163drivers.
    164
    165.. kernel-doc:: drivers/gpu/drm/drm_pci.c
    166   :export:
    167
    168Open/Close, File Operations and IOCTLs
    169======================================
    170
    171.. _drm_driver_fops:
    172
    173File Operations
    174---------------
    175
    176.. kernel-doc:: drivers/gpu/drm/drm_file.c
    177   :doc: file operations
    178
    179.. kernel-doc:: include/drm/drm_file.h
    180   :internal:
    181
    182.. kernel-doc:: drivers/gpu/drm/drm_file.c
    183   :export:
    184
    185Misc Utilities
    186==============
    187
    188Printer
    189-------
    190
    191.. kernel-doc:: include/drm/drm_print.h
    192   :doc: print
    193
    194.. kernel-doc:: include/drm/drm_print.h
    195   :internal:
    196
    197.. kernel-doc:: drivers/gpu/drm/drm_print.c
    198   :export:
    199
    200Utilities
    201---------
    202
    203.. kernel-doc:: include/drm/drm_util.h
    204   :doc: drm utils
    205
    206.. kernel-doc:: include/drm/drm_util.h
    207   :internal:
    208
    209
    210Legacy Support Code
    211===================
    212
    213The section very briefly covers some of the old legacy support code
    214which is only used by old DRM drivers which have done a so-called
    215shadow-attach to the underlying device instead of registering as a real
    216driver. This also includes some of the old generic buffer management and
    217command submission code. Do not use any of this in new and modern
    218drivers.
    219
    220Legacy Suspend/Resume
    221---------------------
    222
    223The DRM core provides some suspend/resume code, but drivers wanting full
    224suspend/resume support should provide save() and restore() functions.
    225These are called at suspend, hibernate, or resume time, and should
    226perform any state save or restore required by your device across suspend
    227or hibernate states.
    228
    229int (\*suspend) (struct drm_device \*, pm_message_t state); int
    230(\*resume) (struct drm_device \*);
    231Those are legacy suspend and resume methods which *only* work with the
    232legacy shadow-attach driver registration functions. New driver should
    233use the power management interface provided by their bus type (usually
    234through the :c:type:`struct device_driver <device_driver>`
    235dev_pm_ops) and set these methods to NULL.
    236
    237Legacy DMA Services
    238-------------------
    239
    240This should cover how DMA mapping etc. is supported by the core. These
    241functions are deprecated and should not be used.