xiaomi-sm8450/android_kernel_xiaomi_sm8450
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Merge tag 'drm-misc-next-2019-08-08' of git://anongit.freedesktop.org/drm/drm-misc into drm-next

Browse Source 
drm-misc-next for 5.4:

UAPI Changes:
 - HDCP: Add a Content protection type property

Cross-subsystem Changes:

Core Changes:
 - Continue to rework the include dependencies
 - fb: Remove the unused drm_gem_fbdev_fb_create function
 - drm-dp-helper: Make the link rate calculation more tolerant to
                  non-explicitly defined, yet supported, rates
 - fb-helper: Map DRM client buffer only when required, and instanciate a
              shadow buffer when the device has a dirty function or says so
 - connector: Add a helper to link the DDC adapter used by that connector to
              the userspace
 - vblank: Switch from DRM_WAIT_ON to wait_event_interruptible_timeout
 - dma-buf: Fix a stack corruption
 - ttm: Embed a drm_gem_object struct to make ttm_buffer_object a
        superclass of GEM, and convert drivers to use it.
 - hdcp: Improvements to report the content protection type to the
         userspace

Driver Changes:
 - Remove drm_gem_prime_import/export from being defined in the drivers
 - Drop DRM_AUTH usage from drivers
 - Continue to drop drmP.h
 - Convert drivers to the connector ddc helper

 - ingenic: Add support for more panel-related cases
 - komeda: Support for dual-link
 - lima: Reduce logging
 - mpag200: Fix the cursor support
 - panfrost: Export GPU features register to userspace through an ioctl
 - pl111: Remove the CLD pads wiring support from the DT
 - rockchip: Rework to use DRM PSR helpers, fix a bug in the VOP_WIN_GET
             macro
 - sun4i: Improve support for color encoding and range
 - tinydrm: Rework SPI support, improve MIPI-DBI support, move to drm/tiny
 - vkms: Rework of the CRC tracking

 - bridges:
   - sii902x: Add support for audio graph card
   - tc358767: Rework AUX data handling code
   - ti-sn65dsi86: Add Debugfs and proper DSI mode flags support

 - panels
   - Support for GiantPlus GPM940B0, Sharp LQ070Y3DG3B, Ortustech
     COM37H3M, Novatek NT39016, Sharp LS020B1DD01D, Raydium RM67191,
     Boe Himax8279d, Sharp LD-D5116Z01B
   - Conversion of the device tree bindings to the YAML description
   - jh057n00900: Rework the enable / disable path

 - fbdev:
   - ssd1307fb: Support more devices based on that controller

Signed-off-by: Dave Airlie <airlied@redhat.com>

From: Maxime Ripard <maxime.ripard@bootlin.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190808121423.xzpedzkpyecvsiy4@flea
This commit is contained in:
Dave Airlie
2019-08-09 16:04:15 +10:00
parent dce14e36ae cc8f12996e
commit b0383c0653
552 changed files with 9606 additions and 7077 deletions
Download Patch File Download Diff File Expand all files Collapse all files

1
Documentation/gpu/drivers.rst
View File

@@ -11,7 +11,6 @@ GPU Driver Documentation
meson
pl111
tegra
tinydrm
tve200
v3d
vc4

12
Documentation/gpu/drm-kms-helpers.rst
View File

@@ -263,6 +263,18 @@ the MST topology helpers easier to understand
drm_dp_mst_topology_put_port
drm_dp_mst_get_mstb_malloc drm_dp_mst_put_mstb_malloc
MIPI DBI Helper Functions Reference
===================================
.. kernel-doc:: drivers/gpu/drm/drm_mipi_dbi.c
:doc: overview
.. kernel-doc:: include/drm/drm_mipi_dbi.h
:internal:
.. kernel-doc:: drivers/gpu/drm/drm_mipi_dbi.c
:export:
MIPI DSI Helper Functions Reference
===================================

40
Documentation/gpu/drm-mm.rst
View File

@@ -433,43 +433,11 @@ PRIME is the cross device buffer sharing framework in drm, originally
created for the OPTIMUS range of multi-gpu platforms. To userspace PRIME
buffers are dma-buf based file descriptors.
Overview and Driver Interface
-----------------------------
Overview and Lifetime Rules
---------------------------
Similar to GEM global names, PRIME file descriptors are also used to
share buffer objects across processes. They offer additional security:
as file descriptors must be explicitly sent over UNIX domain sockets to
be shared between applications, they can't be guessed like the globally
unique GEM names.
Drivers that support the PRIME API must set the DRIVER_PRIME bit in the
struct :c:type:`struct drm_driver <drm_driver>`
driver_features field, and implement the prime_handle_to_fd and
prime_fd_to_handle operations.
int (\*prime_handle_to_fd)(struct drm_device \*dev, struct drm_file
\*file_priv, uint32_t handle, uint32_t flags, int \*prime_fd); int
(\*prime_fd_to_handle)(struct drm_device \*dev, struct drm_file
\*file_priv, int prime_fd, uint32_t \*handle); Those two operations
convert a handle to a PRIME file descriptor and vice versa. Drivers must
use the kernel dma-buf buffer sharing framework to manage the PRIME file
descriptors. Similar to the mode setting API PRIME is agnostic to the
underlying buffer object manager, as long as handles are 32bit unsigned
integers.
While non-GEM drivers must implement the operations themselves, GEM
drivers must use the :c:func:`drm_gem_prime_handle_to_fd()` and
:c:func:`drm_gem_prime_fd_to_handle()` helper functions. Those
helpers rely on the driver gem_prime_export and gem_prime_import
operations to create a dma-buf instance from a GEM object (dma-buf
exporter role) and to create a GEM object from a dma-buf instance
(dma-buf importer role).
struct dma_buf \* (\*gem_prime_export)(struct drm_device \*dev,
struct drm_gem_object \*obj, int flags); struct drm_gem_object \*
(\*gem_prime_import)(struct drm_device \*dev, struct dma_buf
\*dma_buf); These two operations are mandatory for GEM drivers that
support PRIME.
.. kernel-doc:: drivers/gpu/drm/drm_prime.c
:doc: overview and lifetime rules
PRIME Helper Functions
----------------------

16
Documentation/gpu/introduction.rst
View File

@@ -51,6 +51,22 @@ and "FIXME" where the interface could be cleaned up.
Also read the :ref:`guidelines for the kernel documentation at large <doc_guide>`.
Documentation Requirements for kAPI
-----------------------------------
All kernel APIs exported to other modules must be documented, including their
datastructures and at least a short introductory section explaining the overall
concepts. Documentation should be put into the code itself as kerneldoc comments
as much as reasonable.
Do not blindly document everything, but document only what's relevant for driver
authors: Internal functions of drm.ko and definitely static functions should not
have formal kerneldoc comments. Use normal C comments if you feel like a comment
is warranted. You may use kerneldoc syntax in the comment, but it shall not
start with a /** kerneldoc marker. Similar for data structures, annotate
anything entirely private with ``/* private: */`` comments as per the
documentation guide.
Getting Started
===============

30
Documentation/gpu/tinydrm.rst
View File

@@ -1,30 +0,0 @@
============================
drm/tinydrm Tiny DRM drivers
============================
tinydrm is a collection of DRM drivers that are so small they can fit in a
single source file.
Helpers
=======
.. kernel-doc:: include/drm/tinydrm/tinydrm-helpers.h
:internal:
.. kernel-doc:: drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
:export:
.. kernel-doc:: drivers/gpu/drm/tinydrm/core/tinydrm-pipe.c
:export:
MIPI DBI Compatible Controllers
===============================
.. kernel-doc:: drivers/gpu/drm/tinydrm/mipi-dbi.c
:doc: overview
.. kernel-doc:: include/drm/tinydrm/mipi-dbi.h
:internal:
.. kernel-doc:: drivers/gpu/drm/tinydrm/mipi-dbi.c
:export:

81
Documentation/gpu/todo.rst
View File

@@ -162,7 +162,7 @@ Clean up mmap forwarding
A lot of drivers forward gem mmap calls to dma-buf mmap for imported buffers.
And also a lot of them forward dma-buf mmap to the gem mmap implementations.
Would be great to refactor this all into a set of small common helpers.
There's drm_gem_prime_mmap() for this now, but still needs to be rolled out.
Contact: Daniel Vetter
@@ -196,15 +196,6 @@ Might be good to also have some igt testcases for this.
Contact: Daniel Vetter, Noralf Tronnes
Remove the ->gem_prime_res_obj callback
--------------------------------------------
The ->gem_prime_res_obj callback can be removed from drivers by using the
reservation_object in the drm_gem_object. It may also be possible to use the
generic drm_gem_reservation_object_wait helper for waiting for a bo.
Contact: Daniel Vetter
idr_init_base()
---------------
@@ -215,22 +206,13 @@ efficient.
Contact: Daniel Vetter
Defaults for .gem_prime_import and export
-----------------------------------------
Most drivers don't need to set drm_driver->gem_prime_import and
->gem_prime_export now that drm_gem_prime_import() and drm_gem_prime_export()
are the default.
struct drm_gem_object_funcs
---------------------------
GEM objects can now have a function table instead of having the callbacks on the
DRM driver struct. This is now the preferred way and drivers can be moved over.
DRM_GEM_CMA_VMAP_DRIVER_OPS, DRM_GEM_SHMEM_DRIVER_OPS already support this, but
DRM_GEM_VRAM_DRIVER_PRIME does not yet and needs to be aligned with the previous
two. We also need a 2nd version of the CMA define that doesn't require the
We also need a 2nd version of the CMA define that doesn't require the
vmapping to be present (different hook for prime importing). Plus this needs to
be rolled out to all drivers using their own implementations, too.
@@ -317,19 +299,6 @@ In the end no .c file should need to include ``drmP.h`` anymore.
Contact: Daniel Vetter
Add missing kerneldoc for exported functions
--------------------------------------------
The DRM reference documentation is still lacking kerneldoc in a few areas. The
task would be to clean up interfaces like moving functions around between
files to better group them and improving the interfaces like dropping return
values for functions that never fail. Then write kerneldoc for all exported
functions and an overview section and integrate it all into the drm book.
See https://dri.freedesktop.org/docs/drm/ for what's there already.
Contact: Daniel Vetter
Make panic handling work
------------------------
@@ -393,6 +362,9 @@ There's a bunch of issues with it:
this (together with the drm_minor->drm_device move) would allow us to remove
debugfs_init.
- Drop the return code and error checking from all debugfs functions. Greg KH is
working on this already.
Contact: Daniel Vetter
KMS cleanups
@@ -440,39 +412,22 @@ fit the available time.
Contact: Daniel Vetter
Backlight Refactoring
---------------------
Backlight drivers have a triple enable/disable state, which is a bit overkill.
Plan to fix this:
1. Roll out backlight_enable() and backlight_disable() helpers everywhere. This
has started already.
2. In all, only look at one of the three status bits set by the above helpers.
3. Remove the other two status bits.
Contact: Daniel Vetter
Driver Specific
===============
tinydrm
-------
Tinydrm is the helper driver for really simple fb drivers. The goal is to make
those drivers as simple as possible, so lots of room for refactoring:
- backlight helpers, probably best to put them into a new drm_backlight.c.
This is because drivers/video is de-facto unmaintained. We could also
move drivers/video/backlight to drivers/gpu/backlight and take it all
over within drm-misc, but that's more work. Backlight helpers require a fair
bit of reworking and refactoring. A simple example is the enabling of a backlight.
Tinydrm has helpers for this. It would be good if other drivers can also use the
helper. However, there are various cases we need to consider i.e different
drivers seem to have different ways of enabling/disabling a backlight.
We also need to consider the backlight drivers (like gpio_backlight). The situation
is further complicated by the fact that the backlight is tied to fbdev
via fb_notifier_callback() which has complicated logic. For further details, refer
to the following discussion thread:
https://groups.google.com/forum/#!topic/outreachy-kernel/8rBe30lwtdA
- spi helpers, probably best put into spi core/helper code. Thierry said
the spi maintainer is fast&reactive, so shouldn't be a big issue.
- extract the mipi-dbi helper (well, the non-tinydrm specific parts at
least) into a separate helper, like we have for mipi-dsi already. Or follow
one of the ideas for having a shared dsi/dbi helper, abstracting away the
transport details more.
Contact: Noralf Trønnes, Daniel Vetter
AMD DC Display Driver
---------------------