Donate to e Foundation | Murena handsets with /e/OS | Own a part of Murena! Learn more

Commit 282d0a35 authored by Dave Airlie's avatar Dave Airlie
Browse files

Merge tag 'drm-misc-next-2017-01-09' of git://anongit.freedesktop.org/git/drm-misc into drm-next 

Back to regular -misc pulls with reasonable sizes:
- dma_fence error clarification (Chris)
- drm_crtc_from_index helper (Shawn), pile more patches on the m-l to roll
  this out to drivers
- mmu-less support for fbdev helpers from Benjamin
- piles of kerneldoc work
- some polish for crc support from Tomeu and Benjamin
- odd misc stuff all over

* tag 'drm-misc-next-2017-01-09' of git://anongit.freedesktop.org/git/drm-misc: (48 commits)
  dma-fence: Introduce drm_fence_set_error() helper
  dma-fence: Wrap querying the fence->status
  dma-fence: Clear fence->status during dma_fence_init()
  drm: fix compilations issues introduced by "drm: allow to use mmuless SoC"
  drm: Change the return type of the unload hook to void
  drm: add more document for drm_crtc_from_index()
  drm: remove useless parameters from drm_pick_cmdline_mode function
  drm: crc: Call wake_up_interruptible() each time there is a new CRC entry
  drm: allow to use mmuless SoC
  drm: compile drm_vm.c only when needed
  fbmem: add a default get_fb_unmapped_area function
  drm: crc: Wait for a frame before returning from open()
  drm: Move locking into drm_debugfs_crtc_crc_add
  drm/imx: imx-tve: Remove unused variable
  Revert "drm: nouveau: fix build when LEDS_CLASS=m"
  drm: Add kernel-doc for drm_crtc_commit_get/put
  drm/atomic: Fix outdated comment.
  drm: reference count event->completion
  gpu: drm: mgag200: mgag200_main:- Handle error from pci_iomap
  drm: Document deprecated load/unload hook
  ...
parents 5c37daf5 a009e975

Documentation/gpu/drm-mm.rst

+29 −11
Original line number Diff line number Diff line
@@ -34,25 +34,26 @@ TTM initialization 
------------------



    **Warning**



    This section is outdated.



Drivers wishing to support TTM must fill out a drm_bo_driver

structure. The structure contains several fields with function pointers

for initializing the TTM, allocating and freeing memory, waiting for

command completion and fence synchronization, and memory migration. See

the radeon_ttm.c file for an example of usage.

Drivers wishing to support TTM must pass a filled :c:type:`ttm_bo_driver

<ttm_bo_driver>` structure to ttm_bo_device_init, together with an

initialized global reference to the memory manager.  The ttm_bo_driver

structure contains several fields with function pointers for

initializing the TTM, allocating and freeing memory, waiting for command

completion and fence synchronization, and memory migration.



The ttm_global_reference structure is made up of several fields:

The :c:type:`struct drm_global_reference <drm_global_reference>` is made

up of several fields:



.. code-block:: c



              struct ttm_global_reference {

              struct drm_global_reference {

                      enum ttm_global_types global_type;

                      size_t size;

                      void *object;

                      int (*init) (struct ttm_global_reference *);

                      void (*release) (struct ttm_global_reference *);

                      int (*init) (struct drm_global_reference *);

                      void (*release) (struct drm_global_reference *);

              };
@@ -76,6 +77,12 @@ ttm_bo_global_release(), respectively. Also, like the previous 
object, ttm_global_item_ref() is used to create an initial reference

count for the TTM, which will call your initialization function.



See the radeon_ttm.c file for an example of usage.



.. kernel-doc:: drivers/gpu/drm/drm_global.c

   :export:





The Graphics Execution Manager (GEM)

====================================
@@ -303,6 +310,17 @@ created. 
Drivers that want to map the GEM object upfront instead of handling page

faults can implement their own mmap file operation handler.



For platforms without MMU the GEM core provides a helper method

:c:func:`drm_gem_cma_get_unmapped_area`. The mmap() routines will call

this to get a proposed address for the mapping.



To use :c:func:`drm_gem_cma_get_unmapped_area`, drivers must fill the

struct :c:type:`struct file_operations <file_operations>` get_unmapped_area

field with a pointer on :c:func:`drm_gem_cma_get_unmapped_area`.



More detailed information about get_unmapped_area can be found in

Documentation/nommu-mmap.txt



Memory Coherency

----------------
@@ -442,7 +460,7 @@ LRU Scan/Eviction Support 
-------------------------



.. kernel-doc:: drivers/gpu/drm/drm_mm.c

   :doc: lru scan roaster

   :doc: lru scan roster



DRM MM Range Allocator Function References

------------------------------------------

Documentation/gpu/drm-uapi.rst

+11 −14
Original line number Diff line number Diff line
@@ -156,8 +156,12 @@ other hand, a driver requires shared state between clients which is 
visible to user-space and accessible beyond open-file boundaries, they

cannot support render nodes.





Testing and validation

======================



Validating changes with IGT

===========================

---------------------------



There's a collection of tests that aims to cover the whole functionality of

DRM drivers and that can be used to check that changes to DRM drivers or the
@@ -193,6 +197,12 @@ run-tests.sh is a wrapper around piglit that will execute the tests matching 
the -t options. A report in HTML format will be available in

./results/html/index.html. Results can be compared with piglit.



Display CRC Support

-------------------



.. kernel-doc:: drivers/gpu/drm/drm_debugfs_crc.c

   :doc: CRC ABI



VBlank event handling

=====================
@@ -209,16 +219,3 @@ DRM_IOCTL_MODESET_CTL 
    mode setting, since on many devices the vertical blank counter is

    reset to 0 at some point during modeset. Modern drivers should not

    call this any more since with kernel mode setting it is a no-op.
 


This second part of the GPU Driver Developer's Guide documents driver

code, implementation details and also all the driver-specific userspace

interfaces. Especially since all hardware-acceleration interfaces to

userspace are driver specific for efficiency and other reasons these

interfaces can be rather substantial. Hence every driver has its own

chapter.



Testing and validation

======================



.. kernel-doc:: drivers/gpu/drm/drm_debugfs_crc.c

   :doc: CRC ABI

Documentation/gpu/introduction.rst

+8 −7
Original line number Diff line number Diff line
@@ -23,13 +23,12 @@ For consistency this documentation uses American English. Abbreviations 
are written as all-uppercase, for example: DRM, KMS, IOCTL, CRTC, and so

on. To aid in reading, documentations make full use of the markup

characters kerneldoc provides: @parameter for function parameters,

@member for structure members, &structure to reference structures and

function() for functions. These all get automatically hyperlinked if

kerneldoc for the referenced objects exists. When referencing entries in

function vtables please use ->vfunc(). Note that kerneldoc does not

support referencing struct members directly, so please add a reference

to the vtable struct somewhere in the same paragraph or at least

section.

@member for structure members (within the same structure), &struct structure to

reference structures and function() for functions. These all get automatically

hyperlinked if kerneldoc for the referenced objects exists. When referencing

entries in function vtables (and structure members in general) please use

&vtable_name.vfunc. Unfortunately this does not yet yield a direct link to the

member, only the structure.



Except in special situations (to separate locked from unlocked variants)

locking requirements for functions aren't documented in the kerneldoc.
@@ -49,3 +48,5 @@ section name should be all upper-case or not, and whether it should end 
in a colon or not. Go with the file-local style. Other common section

names are "Notes" with information for dangerous or tricky corner cases,

and "FIXME" where the interface could be cleaned up.



Also read the :ref:`guidelines for the kernel documentation at large <doc_guide>`.

arch/blackfin/include/asm/vga.h

0 → 100644
+1 −0
Original line number Diff line number Diff line 
#include <asm-generic/vga.h>

drivers/dma-buf/dma-buf.c

+4 −5
Original line number Diff line number Diff line
@@ -128,7 +128,7 @@ static loff_t dma_buf_llseek(struct file *file, loff_t offset, int whence) 
 * DOC: fence polling

 *

 * To support cross-device and cross-driver synchronization of buffer access

 * implicit fences (represented internally in the kernel with struct &fence) can

 * implicit fences (represented internally in the kernel with &struct fence) can

 * be attached to a &dma_buf. The glue for that and a few related things are

 * provided in the &reservation_object structure.

 *
@@ -373,7 +373,7 @@ static inline int is_dma_buf_file(struct file *file) 
 * Additionally, provide a name string for exporter; useful in debugging.

 *

 * @exp_info:	[in]	holds all the export related information provided

 *			by the exporter. see struct &dma_buf_export_info

 *			by the exporter. see &struct dma_buf_export_info

 *			for further details.

 *

 * Returns, on success, a newly created dma_buf object, which wraps the
@@ -516,9 +516,8 @@ EXPORT_SYMBOL_GPL(dma_buf_get); 
 * Uses file's refcounting done implicitly by fput().

 *

 * If, as a result of this call, the refcount becomes 0, the 'release' file

 * operation related to this fd is called. It calls the release operation of

 * struct &dma_buf_ops in turn, and frees the memory allocated for dmabuf when

 * exported.

 * operation related to this fd is called. It calls &dma_buf_ops.release vfunc

 * in turn, and frees the memory allocated for dmabuf when exported.

 */

void dma_buf_put(struct dma_buf *dmabuf)

{