From 18ce0906d96234d7932afc90ed7ce4a338de989e Mon Sep 17 00:00:00 2001 From: Shayenne da Luz Moura Date: Thu, 13 Dec 2018 20:55:37 -0200 Subject: drm: Remove complete task from TODO documentation This patch remove the follow complete task from TODO documentation: drm_mode_config.crtc_idr is misnamed, since it contains all KMS object. Should be renamed to drm_mode_config.object_idr. Signed-off-by: Shayenne da Luz Moura Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20181213225537.nq4dwidn6tma33iv@smtp.gmail.com --- Documentation/gpu/todo.rst | 3 --- 1 file changed, 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst index 14191b64446d..41da7b06195c 100644 --- a/Documentation/gpu/todo.rst +++ b/Documentation/gpu/todo.rst @@ -354,9 +354,6 @@ KMS cleanups Some of these date from the very introduction of KMS in 2008 ... -- drm_mode_config.crtc_idr is misnamed, since it contains all KMS object. Should - be renamed to drm_mode_config.object_idr. - - drm_display_mode doesn't need to be derived from drm_mode_object. That's leftovers from older (never merged into upstream) KMS designs where modes where set using their ID, including support to add/remove modes. -- cgit From be5cadc7e7b4cee83cdd19e58a9dc0eca9e23b69 Mon Sep 17 00:00:00 2001 From: Daniel Vetter Date: Mon, 7 Jan 2019 11:22:38 +0100 Subject: drm/todo: Better defio support in the generic fbdev emulation MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The current one essentially means you need CMA or a vmalloc backed object, which makes fbdev emulation a special case. Since implementing this will be quite a bit of work, capture the idea in a TODO. Cc: Noralf Trønnes Acked-by: Noralf Trønnes Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20190107102238.7789-1-daniel.vetter@ffwll.ch --- Documentation/gpu/todo.rst | 30 ++++++++++++++++++++++++++++++ 1 file changed, 30 insertions(+) (limited to 'Documentation') diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst index 41da7b06195c..0a85dad876ae 100644 --- a/Documentation/gpu/todo.rst +++ b/Documentation/gpu/todo.rst @@ -209,6 +209,36 @@ Would be great to refactor this all into a set of small common helpers. Contact: Daniel Vetter +Generic fbdev defio support +--------------------------- + +The defio support code in the fbdev core has some very specific requirements, +which means drivers need to have a special framebuffer for fbdev. Which prevents +us from using the generic fbdev emulation code everywhere. The main issue is +that it uses some fields in struct page itself, which breaks shmem gem objects +(and other things). + +Possible solution would be to write our own defio mmap code in the drm fbdev +emulation. It would need to fully wrap the existing mmap ops, forwarding +everything after it has done the write-protect/mkwrite trickery: + +- In the drm_fbdev_fb_mmap helper, if we need defio, change the + default page prots to write-protected with something like this:: + + vma->vm_page_prot = pgprot_wrprotect(vma->vm_page_prot); + +- Set the mkwrite and fsync callbacks with similar implementions to the core + fbdev defio stuff. These should all work on plain ptes, they don't actually + require a struct page. uff. These should all work on plain ptes, they don't + actually require a struct page. + +- Track the dirty pages in a separate structure (bitfield with one bit per page + should work) to avoid clobbering struct page. + +Might be good to also have some igt testcases for this. + +Contact: Daniel Vetter, Noralf Tronnes + Put a reservation_object into drm_gem_object -------------------------------------------- -- cgit From ebcc0e6b509108b4a67daa4c55809a05ab7f4b77 Mon Sep 17 00:00:00 2001 From: Lyude Paul Date: Thu, 10 Jan 2019 19:53:29 -0500 Subject: drm/dp_mst: Introduce new refcounting scheme for mstbs and ports The current way of handling refcounting in the DP MST helpers is really confusing and probably just plain wrong because it's been hacked up many times over the years without anyone actually going over the code and seeing if things could be simplified. To the best of my understanding, the current scheme works like this: drm_dp_mst_port and drm_dp_mst_branch both have a single refcount. When this refcount hits 0 for either of the two, they're removed from the topology state, but not immediately freed. Both ports and branch devices will reinitialize their kref once it's hit 0 before actually destroying themselves. The intended purpose behind this is so that we can avoid problems like not being able to free a remote payload that might still be active, due to us having removed all of the port/branch device structures in memory, as per: commit 91a25e463130 ("drm/dp/mst: deallocate payload on port destruction") Which may have worked, but then it caused use-after-free errors. Being new to MST at the time, I tried fixing it; commit 263efde31f97 ("drm/dp/mst: Get validated port ref in drm_dp_update_payload_part1()") But, that was broken: both drm_dp_mst_port and drm_dp_mst_branch structs are validated in almost every DP MST helper function. Simply put, this means we go through the topology and try to see if the given drm_dp_mst_branch or drm_dp_mst_port is still attached to something before trying to use it in order to avoid dereferencing freed memory (something that has happened a LOT in the past with this library). Because of this it doesn't actually matter whether or not we keep keep the ports and branches around in memory as that's not enough, because any function that validates the branches and ports passed to it will still reject them anyway since they're no longer in the topology structure. So, use-after-free errors were fixed but payload deallocation was completely broken. Two years later, AMD informed me about this issue and I attempted to come up with a temporary fix, pending a long-overdue cleanup of this library: commit c54c7374ff44 ("drm/dp_mst: Skip validating ports during destruction, just ref") But then that introduced use-after-free errors, so I quickly reverted it: commit 9765635b3075 ("Revert "drm/dp_mst: Skip validating ports during destruction, just ref"") And in the process, learned that there is just no simple fix for this: the design is just broken. Unfortunately, the usage of these helpers are quite broken as well. Some drivers like i915 have been smart enough to avoid accessing any kind of information from MST port structures, but others like nouveau have assumed, understandably so, that drm_dp_mst_port structures are normal and can just be accessed at any time without worrying about use-after-free errors. After a lot of discussion, me and Daniel Vetter came up with a better idea to replace all of this. To summarize, since this is documented far more indepth in the documentation this patch introduces, we make it so that drm_dp_mst_port and drm_dp_mst_branch structures have two different classes of refcounts: topology_kref, and malloc_kref. topology_kref corresponds to the lifetime of the given drm_dp_mst_port or drm_dp_mst_branch in it's given topology. Once it hits zero, any associated connectors are removed and the branch or port can no longer be validated. malloc_kref corresponds to the lifetime of the memory allocation for the actual structure, and will always be non-zero so long as the topology_kref is non-zero. This gives us a way to allow callers to hold onto port and branch device structures past their topology lifetime, and dramatically simplifies the lifetimes of both structures. This also finally fixes the port deallocation problem, properly. Additionally: since this now means that we can keep ports and branch devices allocated in memory for however long we need, we no longer need a significant amount of the port validation that we currently do. Additionally, there is one last scenario that this fixes, which couldn't have been fixed properly beforehand: - CPU1 unrefs port from topology (refcount 1->0) - CPU2 refs port in topology(refcount 0->1) Since we now can guarantee memory safety for ports and branches as-needed, we also can make our main reference counting functions fix this problem by using kref_get_unless_zero() internally so that topology refcounts can only ever reach 0 once. Changes since v4: * Change the kernel-figure summary for dp-mst/topology-figure-1.dot a bit - danvet * Remove figure numbers - danvet Changes since v3: * Remove rebase detritus - danvet * Split out purely style changes into separate patches - hwentlan Changes since v2: * Fix commit message - checkpatch * s/)-1/) - 1/g - checkpatch Changes since v1: * Remove forward declarations - danvet * Move "Branch device and port refcounting" section from documentation into kernel-doc comments - danvet * Export internal topology lifetime functions into their own section in the kernel-docs - danvet * s/@/&/g for struct references in kernel-docs - danvet * Drop the "when they are no longer being used" bits from the kernel docs - danvet * Modify diagrams to show how the DRM driver interacts with the topology and payloads - danvet * Make suggested documentation changes for drm_dp_mst_topology_get_mstb() and drm_dp_mst_topology_get_port() - danvet * Better explain the relationship between malloc refs and topology krefs in the documentation for drm_dp_mst_topology_get_port() and drm_dp_mst_topology_get_mstb() - danvet * Fix "See also" in drm_dp_mst_topology_get_mstb() - danvet * Rename drm_dp_mst_topology_get_(port|mstb)() -> drm_dp_mst_topology_try_get_(port|mstb)() and drm_dp_mst_topology_ref_(port|mstb)() -> drm_dp_mst_topology_get_(port|mstb)() - danvet * s/should/must in docs - danvet * WARN_ON(refcount == 0) in topology_get_(mstb|port) - danvet * Move kdocs for mstb/port structs inline - danvet * Split drm_dp_get_last_connected_port_and_mstb() changes into their own commit - danvet Signed-off-by: Lyude Paul Reviewed-by: Harry Wentland Reviewed-by: Daniel Vetter Cc: David Airlie Cc: Jerry Zuo Cc: Juston Li Link: https://patchwork.freedesktop.org/patch/msgid/20190111005343.17443-7-lyude@redhat.com --- Documentation/gpu/dp-mst/topology-figure-1.dot | 52 +++++++++++++++++++++++ Documentation/gpu/dp-mst/topology-figure-2.dot | 56 ++++++++++++++++++++++++ Documentation/gpu/dp-mst/topology-figure-3.dot | 59 ++++++++++++++++++++++++++ Documentation/gpu/drm-kms-helpers.rst | 26 +++++++++++- 4 files changed, 191 insertions(+), 2 deletions(-) create mode 100644 Documentation/gpu/dp-mst/topology-figure-1.dot create mode 100644 Documentation/gpu/dp-mst/topology-figure-2.dot create mode 100644 Documentation/gpu/dp-mst/topology-figure-3.dot (limited to 'Documentation') diff --git a/Documentation/gpu/dp-mst/topology-figure-1.dot b/Documentation/gpu/dp-mst/topology-figure-1.dot new file mode 100644 index 000000000000..157e17c7e0b0 --- /dev/null +++ b/Documentation/gpu/dp-mst/topology-figure-1.dot @@ -0,0 +1,52 @@ +digraph T { + /* Make sure our payloads are always drawn below the driver node */ + subgraph cluster_driver { + fillcolor = grey; + style = filled; + driver -> {payload1, payload2} [dir=none]; + } + + /* Driver malloc references */ + edge [style=dashed]; + driver -> port1; + driver -> port2; + driver -> port3:e; + driver -> port4; + + payload1:s -> port1:e; + payload2:s -> port3:e; + edge [style=""]; + + subgraph cluster_topology { + label="Topology Manager"; + labelloc=bottom; + + /* Topology references */ + mstb1 -> {port1, port2}; + port1 -> mstb2; + port2 -> mstb3 -> {port3, port4}; + port3 -> mstb4; + + /* Malloc references */ + edge [style=dashed;dir=back]; + mstb1 -> {port1, port2}; + port1 -> mstb2; + port2 -> mstb3 -> {port3, port4}; + port3 -> mstb4; + } + + driver [label="DRM driver";style=filled;shape=box;fillcolor=lightblue]; + + payload1 [label="Payload #1";style=filled;shape=box;fillcolor=lightblue]; + payload2 [label="Payload #2";style=filled;shape=box;fillcolor=lightblue]; + + mstb1 [label="MSTB #1";style=filled;fillcolor=palegreen;shape=oval]; + mstb2 [label="MSTB #2";style=filled;fillcolor=palegreen;shape=oval]; + mstb3 [label="MSTB #3";style=filled;fillcolor=palegreen;shape=oval]; + mstb4 [label="MSTB #4";style=filled;fillcolor=palegreen;shape=oval]; + + port1 [label="Port #1";shape=oval]; + port2 [label="Port #2";shape=oval]; + port3 [label="Port #3";shape=oval]; + port4 [label="Port #4";shape=oval]; +} diff --git a/Documentation/gpu/dp-mst/topology-figure-2.dot b/Documentation/gpu/dp-mst/topology-figure-2.dot new file mode 100644 index 000000000000..4243dd1737cb --- /dev/null +++ b/Documentation/gpu/dp-mst/topology-figure-2.dot @@ -0,0 +1,56 @@ +digraph T { + /* Make sure our payloads are always drawn below the driver node */ + subgraph cluster_driver { + fillcolor = grey; + style = filled; + driver -> {payload1, payload2} [dir=none]; + } + + /* Driver malloc references */ + edge [style=dashed]; + driver -> port1; + driver -> port2; + driver -> port3:e; + driver -> port4 [color=red]; + + payload1:s -> port1:e; + payload2:s -> port3:e; + edge [style=""]; + + subgraph cluster_topology { + label="Topology Manager"; + labelloc=bottom; + + /* Topology references */ + mstb1 -> {port1, port2}; + port1 -> mstb2; + edge [color=red]; + port2 -> mstb3 -> {port3, port4}; + port3 -> mstb4; + edge [color=""]; + + /* Malloc references */ + edge [style=dashed;dir=back]; + mstb1 -> {port1, port2}; + port1 -> mstb2; + port2 -> mstb3 -> port3; + edge [color=red]; + mstb3 -> port4; + port3 -> mstb4; + } + + mstb1 [label="MSTB #1";style=filled;fillcolor=palegreen]; + mstb2 [label="MSTB #2";style=filled;fillcolor=palegreen]; + mstb3 [label="MSTB #3";style=filled;fillcolor=palegreen]; + mstb4 [label="MSTB #4";style=filled;fillcolor=grey]; + + port1 [label="Port #1"]; + port2 [label="Port #2"]; + port3 [label="Port #3"]; + port4 [label="Port #4";style=filled;fillcolor=grey]; + + driver [label="DRM driver";style=filled;shape=box;fillcolor=lightblue]; + + payload1 [label="Payload #1";style=filled;shape=box;fillcolor=lightblue]; + payload2 [label="Payload #2";style=filled;shape=box;fillcolor=lightblue]; +} diff --git a/Documentation/gpu/dp-mst/topology-figure-3.dot b/Documentation/gpu/dp-mst/topology-figure-3.dot new file mode 100644 index 000000000000..6cd78d06778b --- /dev/null +++ b/Documentation/gpu/dp-mst/topology-figure-3.dot @@ -0,0 +1,59 @@ +digraph T { + /* Make sure our payloads are always drawn below the driver node */ + subgraph cluster_driver { + fillcolor = grey; + style = filled; + edge [dir=none]; + driver -> payload1; + driver -> payload2 [penwidth=3]; + edge [dir=""]; + } + + /* Driver malloc references */ + edge [style=dashed]; + driver -> port1; + driver -> port2; + driver -> port3:e; + driver -> port4 [color=grey]; + payload1:s -> port1:e; + payload2:s -> port3:e [penwidth=3]; + edge [style=""]; + + subgraph cluster_topology { + label="Topology Manager"; + labelloc=bottom; + + /* Topology references */ + mstb1 -> {port1, port2}; + port1 -> mstb2; + edge [color=grey]; + port2 -> mstb3 -> {port3, port4}; + port3 -> mstb4; + edge [color=""]; + + /* Malloc references */ + edge [style=dashed;dir=back]; + mstb1 -> {port1, port2}; + port1 -> mstb2; + port2 -> mstb3 [penwidth=3]; + mstb3 -> port3 [penwidth=3]; + edge [color=grey]; + mstb3 -> port4; + port3 -> mstb4; + } + + mstb1 [label="MSTB #1";style=filled;fillcolor=palegreen]; + mstb2 [label="MSTB #2";style=filled;fillcolor=palegreen]; + mstb3 [label="MSTB #3";style=filled;fillcolor=palegreen;penwidth=3]; + mstb4 [label="MSTB #4";style=filled;fillcolor=grey]; + + port1 [label="Port #1"]; + port2 [label="Port #2";penwidth=5]; + port3 [label="Port #3";penwidth=3]; + port4 [label="Port #4";style=filled;fillcolor=grey]; + + driver [label="DRM driver";style=filled;shape=box;fillcolor=lightblue]; + + payload1 [label="Payload #1";style=filled;shape=box;fillcolor=lightblue]; + payload2 [label="Payload #2";style=filled;shape=box;fillcolor=lightblue;penwidth=3]; +} diff --git a/Documentation/gpu/drm-kms-helpers.rst b/Documentation/gpu/drm-kms-helpers.rst index 4b4dc236ef6f..27001ae5d370 100644 --- a/Documentation/gpu/drm-kms-helpers.rst +++ b/Documentation/gpu/drm-kms-helpers.rst @@ -208,18 +208,40 @@ Display Port Dual Mode Adaptor Helper Functions Reference .. kernel-doc:: drivers/gpu/drm/drm_dp_dual_mode_helper.c :export: -Display Port MST Helper Functions Reference -=========================================== +Display Port MST Helpers +======================== + +Overview +-------- .. kernel-doc:: drivers/gpu/drm/drm_dp_mst_topology.c :doc: dp mst helper +.. kernel-doc:: drivers/gpu/drm/drm_dp_mst_topology.c + :doc: Branch device and port refcounting + +Functions Reference +------------------- + .. kernel-doc:: include/drm/drm_dp_mst_helper.h :internal: .. kernel-doc:: drivers/gpu/drm/drm_dp_mst_topology.c :export: +Topology Lifetime Internals +--------------------------- + +These functions aren't exported to drivers, but are documented here to help make +the MST topology helpers easier to understand + +.. kernel-doc:: drivers/gpu/drm/drm_dp_mst_topology.c + :functions: drm_dp_mst_topology_try_get_mstb drm_dp_mst_topology_get_mstb + drm_dp_mst_topology_put_mstb + drm_dp_mst_topology_try_get_port drm_dp_mst_topology_get_port + drm_dp_mst_topology_put_port + drm_dp_mst_get_mstb_malloc drm_dp_mst_put_mstb_malloc + MIPI DSI Helper Functions Reference =================================== -- cgit From 3affaa5a7ca3ca114e01049bc45e3ed4a3955505 Mon Sep 17 00:00:00 2001 From: Brian Starkey Date: Mon, 3 Dec 2018 11:31:57 +0000 Subject: drm/afbc: Add AFBC modifier usage documentation AFBC is a flexible, proprietary, lossless compression protocol and format, with a number of defined DRM format modifiers. To facilitate consistency and compatibility between different AFBC producers and consumers, document the expectations for usage of the AFBC DRM format modifiers in a new .rst chapter. Signed-off-by: Brian Starkey Reviewed-by: Liviu Dudau [Updated MAINTAINERS entry to show that "Mali DP Maintainers" is actually a mailing list and added an SPDX-License-Identifier to the documentation] Signed-off-by: Liviu Dudau --- Documentation/gpu/afbc.rst | 235 ++++++++++++++++++++++++++++++++++++++++++ Documentation/gpu/drivers.rst | 1 + 2 files changed, 236 insertions(+) create mode 100644 Documentation/gpu/afbc.rst (limited to 'Documentation') diff --git a/Documentation/gpu/afbc.rst b/Documentation/gpu/afbc.rst new file mode 100644 index 000000000000..4d38dc49d105 --- /dev/null +++ b/Documentation/gpu/afbc.rst @@ -0,0 +1,235 @@ +.. SPDX-License-Identifier: GPL-2.0+ + +=================================== + Arm Framebuffer Compression (AFBC) +=================================== + +AFBC is a proprietary lossless image compression protocol and format. +It provides fine-grained random access and minimizes the amount of +data transferred between IP blocks. + +AFBC can be enabled on drivers which support it via use of the AFBC +format modifiers defined in drm_fourcc.h. See DRM_FORMAT_MOD_ARM_AFBC(*). + +All users of the AFBC modifiers must follow the usage guidelines laid +out in this document, to ensure compatibility across different AFBC +producers and consumers. + +Components and Ordering +======================= + +AFBC streams can contain several components - where a component +corresponds to a color channel (i.e. R, G, B, X, A, Y, Cb, Cr). +The assignment of input/output color channels must be consistent +between the encoder and the decoder for correct operation, otherwise +the consumer will interpret the decoded data incorrectly. + +Furthermore, when the lossless colorspace transform is used +(AFBC_FORMAT_MOD_YTR, which should be enabled for RGB buffers for +maximum compression efficiency), the component order must be: + + * Component 0: R + * Component 1: G + * Component 2: B + +The component ordering is communicated via the fourcc code in the +fourcc:modifier pair. In general, component '0' is considered to +reside in the least-significant bits of the corresponding linear +format. For example, COMP(bits): + + * DRM_FORMAT_ABGR8888 + + * Component 0: R(8) + * Component 1: G(8) + * Component 2: B(8) + * Component 3: A(8) + + * DRM_FORMAT_BGR888 + + * Component 0: R(8) + * Component 1: G(8) + * Component 2: B(8) + + * DRM_FORMAT_YUYV + + * Component 0: Y(8) + * Component 1: Cb(8, 2x1 subsampled) + * Component 2: Cr(8, 2x1 subsampled) + +In AFBC, 'X' components are not treated any differently from any other +component. Therefore, an AFBC buffer with fourcc DRM_FORMAT_XBGR8888 +encodes with 4 components, like so: + + * DRM_FORMAT_XBGR8888 + + * Component 0: R(8) + * Component 1: G(8) + * Component 2: B(8) + * Component 3: X(8) + +Please note, however, that the inclusion of a "wasted" 'X' channel is +bad for compression efficiency, and so it's recommended to avoid +formats containing 'X' bits. If a fourth component is +required/expected by the encoder/decoder, then it is recommended to +instead use an equivalent format with alpha, setting all alpha bits to +'1'. If there is no requirement for a fourth component, then a format +which doesn't include alpha can be used, e.g. DRM_FORMAT_BGR888. + +Number of Planes +================ + +Formats which are typically multi-planar in linear layouts (e.g. YUV +420), can be encoded into one, or multiple, AFBC planes. As with +component order, the encoder and decoder must agree about the number +of planes in order to correctly decode the buffer. The fourcc code is +used to determine the number of encoded planes in an AFBC buffer, +matching the number of planes for the linear (unmodified) format. +Within each plane, the component ordering also follows the fourcc +code: + +For example: + + * DRM_FORMAT_YUYV: nplanes = 1 + + * Plane 0: + + * Component 0: Y(8) + * Component 1: Cb(8, 2x1 subsampled) + * Component 2: Cr(8, 2x1 subsampled) + + * DRM_FORMAT_NV12: nplanes = 2 + + * Plane 0: + + * Component 0: Y(8) + + * Plane 1: + + * Component 0: Cb(8, 2x1 subsampled) + * Component 1: Cr(8, 2x1 subsampled) + +Cross-device interoperability +============================= + +For maximum compatibility across devices, the table below defines +canonical formats for use between AFBC-enabled devices. Formats which +are listed here must be used exactly as specified when using the AFBC +modifiers. Formats which are not listed should be avoided. + +.. flat-table:: AFBC formats + + * - Fourcc code + - Description + - Planes/Components + + * - DRM_FORMAT_ABGR2101010 + - 10-bit per component RGB, with 2-bit alpha + - Plane 0: 4 components + * Component 0: R(10) + * Component 1: G(10) + * Component 2: B(10) + * Component 3: A(2) + + * - DRM_FORMAT_ABGR8888 + - 8-bit per component RGB, with 8-bit alpha + - Plane 0: 4 components + * Component 0: R(8) + * Component 1: G(8) + * Component 2: B(8) + * Component 3: A(8) + + * - DRM_FORMAT_BGR888 + - 8-bit per component RGB + - Plane 0: 3 components + * Component 0: R(8) + * Component 1: G(8) + * Component 2: B(8) + + * - DRM_FORMAT_BGR565 + - 5/6-bit per component RGB + - Plane 0: 3 components + * Component 0: R(5) + * Component 1: G(6) + * Component 2: B(5) + + * - DRM_FORMAT_ABGR1555 + - 5-bit per component RGB, with 1-bit alpha + - Plane 0: 4 components + * Component 0: R(5) + * Component 1: G(5) + * Component 2: B(5) + * Component 3: A(1) + + * - DRM_FORMAT_VUY888 + - 8-bit per component YCbCr 444, single plane + - Plane 0: 3 components + * Component 0: Y(8) + * Component 1: Cb(8) + * Component 2: Cr(8) + + * - DRM_FORMAT_VUY101010 + - 10-bit per component YCbCr 444, single plane + - Plane 0: 3 components + * Component 0: Y(10) + * Component 1: Cb(10) + * Component 2: Cr(10) + + * - DRM_FORMAT_YUYV + - 8-bit per component YCbCr 422, single plane + - Plane 0: 3 components + * Component 0: Y(8) + * Component 1: Cb(8, 2x1 subsampled) + * Component 2: Cr(8, 2x1 subsampled) + + * - DRM_FORMAT_NV16 + - 8-bit per component YCbCr 422, two plane + - Plane 0: 1 component + * Component 0: Y(8) + Plane 1: 2 components + * Component 0: Cb(8, 2x1 subsampled) + * Component 1: Cr(8, 2x1 subsampled) + + * - DRM_FORMAT_Y210 + - 10-bit per component YCbCr 422, single plane + - Plane 0: 3 components + * Component 0: Y(10) + * Component 1: Cb(10, 2x1 subsampled) + * Component 2: Cr(10, 2x1 subsampled) + + * - DRM_FORMAT_P210 + - 10-bit per component YCbCr 422, two plane + - Plane 0: 1 component + * Component 0: Y(10) + Plane 1: 2 components + * Component 0: Cb(10, 2x1 subsampled) + * Component 1: Cr(10, 2x1 subsampled) + + * - DRM_FORMAT_YUV420_8BIT + - 8-bit per component YCbCr 420, single plane + - Plane 0: 3 components + * Component 0: Y(8) + * Component 1: Cb(8, 2x2 subsampled) + * Component 2: Cr(8, 2x2 subsampled) + + * - DRM_FORMAT_YUV420_10BIT + - 10-bit per component YCbCr 420, single plane + - Plane 0: 3 components + * Component 0: Y(10) + * Component 1: Cb(10, 2x2 subsampled) + * Component 2: Cr(10, 2x2 subsampled) + + * - DRM_FORMAT_NV12 + - 8-bit per component YCbCr 420, two plane + - Plane 0: 1 component + * Component 0: Y(8) + Plane 1: 2 components + * Component 0: Cb(8, 2x2 subsampled) + * Component 1: Cr(8, 2x2 subsampled) + + * - DRM_FORMAT_P010 + - 10-bit per component YCbCr 420, two plane + - Plane 0: 1 component + * Component 0: Y(10) + Plane 1: 2 components + * Component 0: Cb(10, 2x2 subsampled) + * Component 1: Cr(10, 2x2 subsampled) diff --git a/Documentation/gpu/drivers.rst b/Documentation/gpu/drivers.rst index 7c1672118a73..c176b34ae9c8 100644 --- a/Documentation/gpu/drivers.rst +++ b/Documentation/gpu/drivers.rst @@ -17,6 +17,7 @@ GPU Driver Documentation vkms bridge/dw-hdmi xen-front + afbc .. only:: subproject and html -- cgit From 3214a16684468f5429469c3b59dc25b312b9d6cc Mon Sep 17 00:00:00 2001 From: Daniel Vetter Date: Fri, 11 Jan 2019 17:40:48 +0100 Subject: drm/doc: Polish kerneldoc for drm_device.h - Move all the legacy gunk at the bottom, and exclude it from kerneldoc. - Documentation for the remaining bits. v2: Fix typo (Sam). Cc: Sam Ravnborg Acked-by: Sam Ravnborg Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20190111164048.29067-5-daniel.vetter@ffwll.ch --- Documentation/gpu/drm-internals.rst | 3 +++ 1 file changed, 3 insertions(+) (limited to 'Documentation') diff --git a/Documentation/gpu/drm-internals.rst b/Documentation/gpu/drm-internals.rst index 5ee9674fb9e9..9090fabf3f7a 100644 --- a/Documentation/gpu/drm-internals.rst +++ b/Documentation/gpu/drm-internals.rst @@ -143,6 +143,9 @@ Device Instance and Driver Handling .. kernel-doc:: drivers/gpu/drm/drm_drv.c :doc: driver instance overview +.. kernel-doc:: include/drm/drm_device.h + :internal: + .. kernel-doc:: include/drm/drm_drv.h :internal: -- cgit From b981a6863e9be995c53cd74f545d3729fcf517f8 Mon Sep 17 00:00:00 2001 From: Daniel Vetter Date: Fri, 11 Jan 2019 17:40:47 +0100 Subject: drm/doc: Move bridge link target to the right place I screwed up a rebase somehow. v2: Drop bogus hunk. v3: Really drop bogus hunk (Lubomir). Cc: Lubomir Rintel Reviewed-by: Sam Ravnborg Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20190111164048.29067-4-daniel.vetter@ffwll.ch --- Documentation/gpu/drm-kms-helpers.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/gpu/drm-kms-helpers.rst b/Documentation/gpu/drm-kms-helpers.rst index 7a3fc569bc68..fbd11b2fe5b5 100644 --- a/Documentation/gpu/drm-kms-helpers.rst +++ b/Documentation/gpu/drm-kms-helpers.rst @@ -116,8 +116,6 @@ Framebuffer CMA Helper Functions Reference .. kernel-doc:: drivers/gpu/drm/drm_fb_cma_helper.c :export: -.. _drm_bridges: - Framebuffer GEM Helper Reference ================================ @@ -127,6 +125,8 @@ Framebuffer GEM Helper Reference .. kernel-doc:: drivers/gpu/drm/drm_gem_framebuffer_helper.c :export: +.. _drm_bridges: + Bridges ======= -- cgit From f4a6de855eae10bba725c6dae65fa1e351c9cd25 Mon Sep 17 00:00:00 2001 From: Mark Yao Date: Sat, 29 Dec 2018 14:33:14 +0100 Subject: drm: rockchip: vop: add rk3066 vop definitions This patch adds the rk3066 VOP definitions. The VOP or LCD Controller serves as interface between framebuffer memory and a display device (LCD panel or TV set). This SOC has two symmetrical LCDC's for a dual panel application. A LCDC has 5 display layers. Only 3 are used here. - Video layer 0 (Win0) - Video layer 1 (Win1) - OSD layer (Win2) Win0 and Win1 are exchangeable. Maximum resolution is 1920x1080. The LCDC0 output is connected to: - LCDC0 IO (without IOMUX) - HDMI TX video input The LCDC1 output is connected to: - LCDC1 IO (with IOMUX) - HDMI TX video input The HDMI TX input can switch between LCDC0 and LCDC1. Signed-off-by: Mark Yao Signed-off-by: Johan Jonker Acked-by: Rob Herring Signed-off-by: Heiko Stuebner Link: https://patchwork.freedesktop.org/patch/msgid/20181229133318.18128-4-jbx6244@gmail.com --- Documentation/devicetree/bindings/display/rockchip/rockchip-vop.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/rockchip/rockchip-vop.txt b/Documentation/devicetree/bindings/display/rockchip/rockchip-vop.txt index b79e5769f0ae..4f58c5a2d195 100644 --- a/Documentation/devicetree/bindings/display/rockchip/rockchip-vop.txt +++ b/Documentation/devicetree/bindings/display/rockchip/rockchip-vop.txt @@ -10,6 +10,7 @@ Required properties: "rockchip,rk3126-vop"; "rockchip,px30-vop-lit"; "rockchip,px30-vop-big"; + "rockchip,rk3066-vop"; "rockchip,rk3188-vop"; "rockchip,rk3288-vop"; "rockchip,rk3368-vop"; -- cgit From 8c9fde42c5d386165d96593d8cc16fca48813589 Mon Sep 17 00:00:00 2001 From: Fabrizio Castro Date: Thu, 13 Dec 2018 20:20:45 +0000 Subject: dt-bindings: display: renesas: du: Document r8a774c0 bindings Document the RZ/G2E (a.k.a. r8a774c0) SoC in the R-Car DU bindings. Signed-off-by: Fabrizio Castro Reviewed-by: Laurent Pinchart Signed-off-by: Laurent Pinchart Reviewed-by: Simon Horman --- Documentation/devicetree/bindings/display/renesas,du.txt | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/renesas,du.txt b/Documentation/devicetree/bindings/display/renesas,du.txt index 3c855d9f2719..aedb22b4d161 100644 --- a/Documentation/devicetree/bindings/display/renesas,du.txt +++ b/Documentation/devicetree/bindings/display/renesas,du.txt @@ -7,6 +7,7 @@ Required Properties: - "renesas,du-r8a7744" for R8A7744 (RZ/G1N) compatible DU - "renesas,du-r8a7745" for R8A7745 (RZ/G1E) compatible DU - "renesas,du-r8a77470" for R8A77470 (RZ/G1C) compatible DU + - "renesas,du-r8a774c0" for R8A774C0 (RZ/G2E) compatible DU - "renesas,du-r8a7779" for R8A7779 (R-Car H1) compatible DU - "renesas,du-r8a7790" for R8A7790 (R-Car H2) compatible DU - "renesas,du-r8a7791" for R8A7791 (R-Car M2-W) compatible DU @@ -57,6 +58,7 @@ corresponding to each DU output. R8A7744 (RZ/G1N) DPAD 0 LVDS 0 - - R8A7745 (RZ/G1E) DPAD 0 DPAD 1 - - R8A77470 (RZ/G1C) DPAD 0 DPAD 1 LVDS 0 - + R8A774C0 (RZ/G2E) DPAD 0 LVDS 0 LVDS 1 - R8A7779 (R-Car H1) DPAD 0 DPAD 1 - - R8A7790 (R-Car H2) DPAD 0 LVDS 0 LVDS 1 - R8A7791 (R-Car M2-W) DPAD 0 LVDS 0 - - -- cgit From 1cac4f267b60ae9c8ce17a85c4bd9a8c6d760f83 Mon Sep 17 00:00:00 2001 From: Fabrizio Castro Date: Thu, 13 Dec 2018 20:20:54 +0000 Subject: dt-bindings: display: renesas: lvds: Document r8a774c0 bindings The RZ/G2E (r8a774c0) supports two LVDS channels. Extend the binding to support them. Signed-off-by: Fabrizio Castro Reviewed-by: Laurent Pinchart Signed-off-by: Laurent Pinchart Reviewed-by: Simon Horman --- Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt b/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt index ba5469dd09f3..27a054e1bb5f 100644 --- a/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt +++ b/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt @@ -8,6 +8,7 @@ Required properties: - compatible : Shall contain one of - "renesas,r8a7743-lvds" for R8A7743 (RZ/G1M) compatible LVDS encoders + - "renesas,r8a774c0-lvds" for R8A774C0 (RZ/G2E) compatible LVDS encoders - "renesas,r8a7790-lvds" for R8A7790 (R-Car H2) compatible LVDS encoders - "renesas,r8a7791-lvds" for R8A7791 (R-Car M2-W) compatible LVDS encoders - "renesas,r8a7793-lvds" for R8A7793 (R-Car M2-N) compatible LVDS encoders @@ -25,7 +26,7 @@ Required properties: - clock-names: Name of the clocks. This property is model-dependent. - The functional clock, which mandatory for all models, shall be listed first, and shall be named "fck". - - On R8A77990 and R8A77995, the LVDS encoder can use the EXTAL or + - On R8A77990, R8A77995 and R8A774C0, the LVDS encoder can use the EXTAL or DU_DOTCLKINx clocks. Those clocks are optional. When supplied they must be named "extal" and "dclkin.x" respectively, with "x" being the DU_DOTCLKIN numerical index. -- cgit From e9eafcb589213395232084a2378e2e90f67feb29 Mon Sep 17 00:00:00 2001 From: Sam Ravnborg Date: Sat, 12 Jan 2019 20:32:44 +0100 Subject: drm: move drm_can_sleep() to drm_util.h MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Move drm_can_sleep() out of drmP.h to allow users to get rid of the drmP.h include. There was no header file that was a good match for this helper function. So add this to drm_util with the relevant includes. Add include of drm_util.h to all users. v2: - Update comments to use kernel-doc style (Daniel) - Add FIXME to drm_can_sleep and add note that this function should not be used in new code (Daniel) v3: - Fix kernel-doc syntax (Daniel) - Plug drm_util.h into drm-internels.rst (Daniel) Signed-off-by: Sam Ravnborg Cc: Maarten Lankhorst Cc: Maxime Ripard Cc: Sean Paul Cc: David Airlie Cc: Daniel Vetter Cc: Alex Deucher Cc: "Christian König" Cc: "David (ChunMing) Zhou" Cc: Gerd Hoffmann Cc: Rob Clark Cc: Tomi Valkeinen Cc: Eric Anholt Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20190112193251.20450-2-sam@ravnborg.org --- Documentation/gpu/drm-internals.rst | 9 +++++++++ 1 file changed, 9 insertions(+) (limited to 'Documentation') diff --git a/Documentation/gpu/drm-internals.rst b/Documentation/gpu/drm-internals.rst index 9090fabf3f7a..2caf21effd28 100644 --- a/Documentation/gpu/drm-internals.rst +++ b/Documentation/gpu/drm-internals.rst @@ -233,6 +233,15 @@ Printer .. kernel-doc:: drivers/gpu/drm/drm_print.c :export: +Utilities +--------- + +.. kernel-doc:: include/drm/drm_util.h + :doc: drm utils + +.. kernel-doc:: include/drm/drm_util.h + :internal: + Legacy Support Code =================== -- cgit From df766e4a419c77283485931070e0692f64aebf8a Mon Sep 17 00:00:00 2001 From: "james qian wang (Arm Technology China)" Date: Thu, 3 Jan 2019 11:40:04 +0000 Subject: dt/bindings: drm/komeda: Add DT bindings for ARM display processor D71 Add DT bindings documentation for the ARM display processor D71 and later IPs. Changes in v4: - Deleted unnecessary address-cells, size-cells [Liviu Dudau] Changes in v3: - Deleted unnecessary property: interrupt-names. - Dropped 'ports' and moving 'port' up a level. Signed-off-by: James Qian Wang (Arm Technology China) Reviewed-by: Liviu Dudau Reviewed-by: Rob Herring [moved in the same directory as the other Arm display bindings] Signed-off-by: Liviu Dudau --- .../devicetree/bindings/display/arm,komeda.txt | 73 ++++++++++++++++++++++ 1 file changed, 73 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/arm,komeda.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/arm,komeda.txt b/Documentation/devicetree/bindings/display/arm,komeda.txt new file mode 100644 index 000000000000..02b226532ebd --- /dev/null +++ b/Documentation/devicetree/bindings/display/arm,komeda.txt @@ -0,0 +1,73 @@ +Device Tree bindings for Arm Komeda display driver + +Required properties: +- compatible: Should be "arm,mali-d71" +- reg: Physical base address and length of the registers in the system +- interrupts: the interrupt line number of the device in the system +- clocks: A list of phandle + clock-specifier pairs, one for each entry + in 'clock-names' +- clock-names: A list of clock names. It should contain: + - "mclk": for the main processor clock + - "pclk": for the APB interface clock +- #address-cells: Must be 1 +- #size-cells: Must be 0 + +Required properties for sub-node: pipeline@nq +Each device contains one or two pipeline sub-nodes (at least one), each +pipeline node should provide properties: +- reg: Zero-indexed identifier for the pipeline +- clocks: A list of phandle + clock-specifier pairs, one for each entry + in 'clock-names' +- clock-names: should contain: + - "pxclk": pixel clock + - "aclk": AXI interface clock + +- port: each pipeline connect to an encoder input port. The connection is + modeled using the OF graph bindings specified in + Documentation/devicetree/bindings/graph.txt + +Optional properties: + - memory-region: phandle to a node describing memory (see + Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt) + to be used for the framebuffer; if not present, the framebuffer may + be located anywhere in memory. + +Example: +/ { + ... + + dp0: display@c00000 { + #address-cells = <1>; + #size-cells = <0>; + compatible = "arm,mali-d71"; + reg = <0xc00000 0x20000>; + interrupts = <0 168 4>; + clocks = <&dpu_mclk>, <&dpu_aclk>; + clock-names = "mclk", "pclk"; + + dp0_pipe0: pipeline@0 { + clocks = <&fpgaosc2>, <&dpu_aclk>; + clock-names = "pxclk", "aclk"; + reg = <0>; + + port { + dp0_pipe0_out: endpoint { + remote-endpoint = <&db_dvi0_in>; + }; + }; + }; + + dp0_pipe1: pipeline@1 { + clocks = <&fpgaosc2>, <&dpu_aclk>; + clock-names = "pxclk", "aclk"; + reg = <1>; + + port { + dp0_pipe1_out: endpoint { + remote-endpoint = <&db_dvi1_in>; + }; + }; + }; + }; + ... +}; -- cgit From 557c37360eca864eba692be7b7b72ec937b330af Mon Sep 17 00:00:00 2001 From: "james qian wang (Arm Technology China)" Date: Thu, 3 Jan 2019 11:41:48 +0000 Subject: drm/doc: Add initial komeda driver documentation v2: Some editing changes according to Randy Dunlap's comments Signed-off-by: James Qian Wang (Arm Technology China) Signed-off-by: Liviu Dudau --- Documentation/gpu/drivers.rst | 1 + Documentation/gpu/komeda-kms.rst | 488 +++++++++++++++++++++++++++++++++++++++ 2 files changed, 489 insertions(+) create mode 100644 Documentation/gpu/komeda-kms.rst (limited to 'Documentation') diff --git a/Documentation/gpu/drivers.rst b/Documentation/gpu/drivers.rst index c176b34ae9c8..044a7025477c 100644 --- a/Documentation/gpu/drivers.rst +++ b/Documentation/gpu/drivers.rst @@ -18,6 +18,7 @@ GPU Driver Documentation bridge/dw-hdmi xen-front afbc + komeda-kms .. only:: subproject and html diff --git a/Documentation/gpu/komeda-kms.rst b/Documentation/gpu/komeda-kms.rst new file mode 100644 index 000000000000..b08da1cffecc --- /dev/null +++ b/Documentation/gpu/komeda-kms.rst @@ -0,0 +1,488 @@ +.. SPDX-License-Identifier: GPL-2.0 + +============================== + drm/komeda Arm display driver +============================== + +The drm/komeda driver supports the Arm display processor D71 and later products, +this document gives a brief overview of driver design: how it works and why +design it like that. + +Overview of D71 like display IPs +================================ + +From D71, Arm display IP begins to adopt a flexible and modularized +architecture. A display pipeline is made up of multiple individual and +functional pipeline stages called components, and every component has some +specific capabilities that can give the flowed pipeline pixel data a +particular processing. + +Typical D71 components: + +Layer +----- +Layer is the first pipeline stage, which prepares the pixel data for the next +stage. It fetches the pixel from memory, decodes it if it's AFBC, rotates the +source image, unpacks or converts YUV pixels to the device internal RGB pixels, +then adjusts the color_space of pixels if needed. + +Scaler +------ +As its name suggests, scaler takes responsibility for scaling, and D71 also +supports image enhancements by scaler. +The usage of scaler is very flexible and can be connected to layer output +for layer scaling, or connected to compositor and scale the whole display +frame and then feed the output data into wb_layer which will then write it +into memory. + +Compositor (compiz) +------------------- +Compositor blends multiple layers or pixel data flows into one single display +frame. its output frame can be fed into post image processor for showing it on +the monitor or fed into wb_layer and written to memory at the same time. +user can also insert a scaler between compositor and wb_layer to down scale +the display frame first and and then write to memory. + +Writeback Layer (wb_layer) +-------------------------- +Writeback layer does the opposite things of Layer, which connects to compiz +and writes the composition result to memory. + +Post image processor (improc) +----------------------------- +Post image processor adjusts frame data like gamma and color space to fit the +requirements of the monitor. + +Timing controller (timing_ctrlr) +-------------------------------- +Final stage of display pipeline, Timing controller is not for the pixel +handling, but only for controlling the display timing. + +Merger +------ +D71 scaler mostly only has the half horizontal input/output capabilities +compared with Layer, like if Layer supports 4K input size, the scaler only can +support 2K input/output in the same time. To achieve the ful frame scaling, D71 +introduces Layer Split, which splits the whole image to two half parts and feeds +them to two Layers A and B, and does the scaling independently. After scaling +the result need to be fed to merger to merge two part images together, and then +output merged result to compiz. + +Splitter +-------- +Similar to Layer Split, but Splitter is used for writeback, which splits the +compiz result to two parts and then feed them to two scalers. + +Possible D71 Pipeline usage +=========================== + +Benefitting from the modularized architecture, D71 pipelines can be easily +adjusted to fit different usages. And D71 has two pipelines, which support two +types of working mode: + +- Dual display mode + Two pipelines work independently and separately to drive two display outputs. + +- Single display mode + Two pipelines work together to drive only one display output. + + On this mode, pipeline_B doesn't work indenpendently, but outputs its + composition result into pipeline_A, and its pixel timing also derived from + pipeline_A.timing_ctrlr. The pipeline_B works just like a "slave" of + pipeline_A(master) + +Single pipeline data flow +------------------------- + +.. kernel-render:: DOT + :alt: Single pipeline digraph + :caption: Single pipeline data flow + + digraph single_ppl { + rankdir=LR; + + subgraph { + "Memory"; + "Monitor"; + } + + subgraph cluster_pipeline { + style=dashed + node [shape=box] + { + node [bgcolor=grey style=dashed] + "Scaler-0"; + "Scaler-1"; + "Scaler-0/1" + } + + node [bgcolor=grey style=filled] + "Layer-0" -> "Scaler-0" + "Layer-1" -> "Scaler-0" + "Layer-2" -> "Scaler-1" + "Layer-3" -> "Scaler-1" + + "Layer-0" -> "Compiz" + "Layer-1" -> "Compiz" + "Layer-2" -> "Compiz" + "Layer-3" -> "Compiz" + "Scaler-0" -> "Compiz" + "Scaler-1" -> "Compiz" + + "Compiz" -> "Scaler-0/1" -> "Wb_layer" + "Compiz" -> "Improc" -> "Timing Controller" + } + + "Wb_layer" -> "Memory" + "Timing Controller" -> "Monitor" + } + +Dual pipeline with Slave enabled +-------------------------------- + +.. kernel-render:: DOT + :alt: Slave pipeline digraph + :caption: Slave pipeline enabled data flow + + digraph slave_ppl { + rankdir=LR; + + subgraph { + "Memory"; + "Monitor"; + } + node [shape=box] + subgraph cluster_pipeline_slave { + style=dashed + label="Slave Pipeline_B" + node [shape=box] + { + node [bgcolor=grey style=dashed] + "Slave.Scaler-0"; + "Slave.Scaler-1"; + } + + node [bgcolor=grey style=filled] + "Slave.Layer-0" -> "Slave.Scaler-0" + "Slave.Layer-1" -> "Slave.Scaler-0" + "Slave.Layer-2" -> "Slave.Scaler-1" + "Slave.Layer-3" -> "Slave.Scaler-1" + + "Slave.Layer-0" -> "Slave.Compiz" + "Slave.Layer-1" -> "Slave.Compiz" + "Slave.Layer-2" -> "Slave.Compiz" + "Slave.Layer-3" -> "Slave.Compiz" + "Slave.Scaler-0" -> "Slave.Compiz" + "Slave.Scaler-1" -> "Slave.Compiz" + } + + subgraph cluster_pipeline_master { + style=dashed + label="Master Pipeline_A" + node [shape=box] + { + node [bgcolor=grey style=dashed] + "Scaler-0"; + "Scaler-1"; + "Scaler-0/1" + } + + node [bgcolor=grey style=filled] + "Layer-0" -> "Scaler-0" + "Layer-1" -> "Scaler-0" + "Layer-2" -> "Scaler-1" + "Layer-3" -> "Scaler-1" + + "Slave.Compiz" -> "Compiz" + "Layer-0" -> "Compiz" + "Layer-1" -> "Compiz" + "Layer-2" -> "Compiz" + "Layer-3" -> "Compiz" + "Scaler-0" -> "Compiz" + "Scaler-1" -> "Compiz" + + "Compiz" -> "Scaler-0/1" -> "Wb_layer" + "Compiz" -> "Improc" -> "Timing Controller" + } + + "Wb_layer" -> "Memory" + "Timing Controller" -> "Monitor" + } + +Sub-pipelines for input and output +---------------------------------- + +A complete display pipeline can be easily divided into three sub-pipelines +according to the in/out usage. + +Layer(input) pipeline +~~~~~~~~~~~~~~~~~~~~~ + +.. kernel-render:: DOT + :alt: Layer data digraph + :caption: Layer (input) data flow + + digraph layer_data_flow { + rankdir=LR; + node [shape=box] + + { + node [bgcolor=grey style=dashed] + "Scaler-n"; + } + + "Layer-n" -> "Scaler-n" -> "Compiz" + } + +.. kernel-render:: DOT + :alt: Layer Split digraph + :caption: Layer Split pipeline + + digraph layer_data_flow { + rankdir=LR; + node [shape=box] + + "Layer-0/1" -> "Scaler-0" -> "Merger" + "Layer-2/3" -> "Scaler-1" -> "Merger" + "Merger" -> "Compiz" + } + +Writeback(output) pipeline +~~~~~~~~~~~~~~~~~~~~~~~~~~ +.. kernel-render:: DOT + :alt: writeback digraph + :caption: Writeback(output) data flow + + digraph writeback_data_flow { + rankdir=LR; + node [shape=box] + + { + node [bgcolor=grey style=dashed] + "Scaler-n"; + } + + "Compiz" -> "Scaler-n" -> "Wb_layer" + } + +.. kernel-render:: DOT + :alt: split writeback digraph + :caption: Writeback(output) Split data flow + + digraph writeback_data_flow { + rankdir=LR; + node [shape=box] + + "Compiz" -> "Splitter" + "Splitter" -> "Scaler-0" -> "Merger" + "Splitter" -> "Scaler-1" -> "Merger" + "Merger" -> "Wb_layer" + } + +Display output pipeline +~~~~~~~~~~~~~~~~~~~~~~~ +.. kernel-render:: DOT + :alt: display digraph + :caption: display output data flow + + digraph single_ppl { + rankdir=LR; + node [shape=box] + + "Compiz" -> "Improc" -> "Timing Controller" + } + +In the following section we'll see these three sub-pipelines will be handled +by KMS-plane/wb_conn/crtc respectively. + +Komeda Resource abstraction +=========================== + +struct komeda_pipeline/component +-------------------------------- + +To fully utilize and easily access/configure the HW, the driver side also uses +a similar architecture: Pipeline/Component to describe the HW features and +capabilities, and a specific component includes two parts: + +- Data flow controlling. +- Specific component capabilities and features. + +So the driver defines a common header struct komeda_component to describe the +data flow control and all specific components are a subclass of this base +structure. + +.. kernel-doc:: drivers/gpu/drm/arm/display/komeda/komeda_pipeline.h + :internal: + +Resource discovery and initialization +===================================== + +Pipeline and component are used to describe how to handle the pixel data. We +still need a @struct komeda_dev to describe the whole view of the device, and +the control-abilites of device. + +We have &komeda_dev, &komeda_pipeline, &komeda_component. Now fill devices with +pipelines. Since komeda is not for D71 only but also intended for later products, +of course we’d better share as much as possible between different products. To +achieve this, split the komeda device into two layers: CORE and CHIP. + +- CORE: for common features and capabilities handling. +- CHIP: for register programing and HW specific feature (limitation) handling. + +CORE can access CHIP by three chip function structures: + +- struct komeda_dev_funcs +- struct komeda_pipeline_funcs +- struct komeda_component_funcs + +.. kernel-doc:: drivers/gpu/drm/arm/display/komeda/komeda_dev.h + :internal: + +Format handling +=============== + +.. kernel-doc:: drivers/gpu/drm/arm/display/komeda/komeda_format_caps.h + :internal: +.. kernel-doc:: drivers/gpu/drm/arm/display/komeda/komeda_framebuffer.h + :internal: + +Attach komeda_dev to DRM-KMS +============================ + +Komeda abstracts resources by pipeline/component, but DRM-KMS uses +crtc/plane/connector. One KMS-obj cannot represent only one single component, +since the requirements of a single KMS object cannot simply be achieved by a +single component, usually that needs multiple components to fit the requirement. +Like set mode, gamma, ctm for KMS all target on CRTC-obj, but komeda needs +compiz, improc and timing_ctrlr to work together to fit these requirements. +And a KMS-Plane may require multiple komeda resources: layer/scaler/compiz. + +So, one KMS-Obj represents a sub-pipeline of komeda resources. + +- Plane: `Layer(input) pipeline`_ +- Wb_connector: `Writeback(output) pipeline`_ +- Crtc: `Display output pipeline`_ + +So, for komeda, we treat KMS crtc/plane/connector as users of pipeline and +component, and at any one time a pipeline/component only can be used by one +user. And pipeline/component will be treated as private object of DRM-KMS; the +state will be managed by drm_atomic_state as well. + +How to map plane to Layer(input) pipeline +----------------------------------------- + +Komeda has multiple Layer input pipelines, see: +- `Single pipeline data flow`_ +- `Dual pipeline with Slave enabled`_ + +The easiest way is binding a plane to a fixed Layer pipeline, but consider the +komeda capabilities: + +- Layer Split, See `Layer(input) pipeline`_ + + Layer_Split is quite complicated feature, which splits a big image into two + parts and handles it by two layers and two scalers individually. But it + imports an edge problem or effect in the middle of the image after the split. + To avoid such a problem, it needs a complicated Split calculation and some + special configurations to the layer and scaler. We'd better hide such HW + related complexity to user mode. + +- Slave pipeline, See `Dual pipeline with Slave enabled`_ + + Since the compiz component doesn't output alpha value, the slave pipeline + only can be used for bottom layers composition. The komeda driver wants to + hide this limitation to the user. The way to do this is to pick a suitable + Layer according to plane_state->zpos. + +So for komeda, the KMS-plane doesn't represent a fixed komeda layer pipeline, +but multiple Layers with same capabilities. Komeda will select one or more +Layers to fit the requirement of one KMS-plane. + +Make component/pipeline to be drm_private_obj +--------------------------------------------- + +Add :c:type:`drm_private_obj` to :c:type:`komeda_component`, :c:type:`komeda_pipeline` + +.. code-block:: c + + struct komeda_component { + struct drm_private_obj obj; + ... + } + + struct komeda_pipeline { + struct drm_private_obj obj; + ... + } + +Tracking component_state/pipeline_state by drm_atomic_state +----------------------------------------------------------- + +Add :c:type:`drm_private_state` and user to :c:type:`komeda_component_state`, +:c:type:`komeda_pipeline_state` + +.. code-block:: c + + struct komeda_component_state { + struct drm_private_state obj; + void *binding_user; + ... + } + + struct komeda_pipeline_state { + struct drm_private_state obj; + struct drm_crtc *crtc; + ... + } + +komeda component validation +--------------------------- + +Komeda has multiple types of components, but the process of validation are +similar, usually including the following steps: + +.. code-block:: c + + int komeda_xxxx_validate(struct komeda_component_xxx xxx_comp, + struct komeda_component_output *input_dflow, + struct drm_plane/crtc/connector *user, + struct drm_plane/crtc/connector_state, *user_state) + { + setup 1: check if component is needed, like the scaler is optional depending + on the user_state; if unneeded, just return, and the caller will + put the data flow into next stage. + Setup 2: check user_state with component features and capabilities to see + if requirements can be met; if not, return fail. + Setup 3: get component_state from drm_atomic_state, and try set to set + user to component; fail if component has been assigned to another + user already. + Setup 3: configure the component_state, like set its input component, + convert user_state to component specific state. + Setup 4: adjust the input_dflow and prepare it for the next stage. + } + +komeda_kms Abstraction +---------------------- + +.. kernel-doc:: drivers/gpu/drm/arm/display/komeda/komeda_kms.h + :internal: + +komde_kms Functions +------------------- +.. kernel-doc:: drivers/gpu/drm/arm/display/komeda/komeda_crtc.c + :internal: +.. kernel-doc:: drivers/gpu/drm/arm/display/komeda/komeda_plane.c + :internal: + +Build komeda to be a Linux module driver +======================================== + +Now we have two level devices: + +- komeda_dev: describes the real display hardware. +- komeda_kms_dev: attachs or connects komeda_dev to DRM-KMS. + +All komeda operations are supplied or operated by komeda_dev or komeda_kms_dev, +the module driver is only a simple wrapper to pass the Linux command +(probe/remove/pm) into komeda_dev or komeda_kms_dev. -- cgit From 993a815dcbb2d13c2a2fe6b89612361dd7f0a4df Mon Sep 17 00:00:00 2001 From: Thierry Reding Date: Mon, 3 Dec 2018 17:13:10 +0100 Subject: dt-bindings: panel: Add missing .txt suffix All other files in that directory have a .txt suffix, so add one for consistency. Signed-off-by: Thierry Reding Reviewed-by: Rob Herring Link: https://patchwork.freedesktop.org/patch/msgid/20181203161310.15438-1-thierry.reding@gmail.com --- .../devicetree/bindings/display/panel/auo,g101evn010 | 12 ------------ .../devicetree/bindings/display/panel/auo,g101evn010.txt | 12 ++++++++++++ 2 files changed, 12 insertions(+), 12 deletions(-) delete mode 100644 Documentation/devicetree/bindings/display/panel/auo,g101evn010 create mode 100644 Documentation/devicetree/bindings/display/panel/auo,g101evn010.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/panel/auo,g101evn010 b/Documentation/devicetree/bindings/display/panel/auo,g101evn010 deleted file mode 100644 index bc6a0c858e23..000000000000 --- a/Documentation/devicetree/bindings/display/panel/auo,g101evn010 +++ /dev/null @@ -1,12 +0,0 @@ -AU Optronics Corporation 10.1" (1280x800) color TFT LCD panel - -Required properties: -- compatible: should be "auo,g101evn010" -- power-supply: as specified in the base binding - -Optional properties: -- backlight: as specified in the base binding -- enable-gpios: as specified in the base binding - -This binding is compatible with the simple-panel binding, which is specified -in simple-panel.txt in this directory. diff --git a/Documentation/devicetree/bindings/display/panel/auo,g101evn010.txt b/Documentation/devicetree/bindings/display/panel/auo,g101evn010.txt new file mode 100644 index 000000000000..bc6a0c858e23 --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/auo,g101evn010.txt @@ -0,0 +1,12 @@ +AU Optronics Corporation 10.1" (1280x800) color TFT LCD panel + +Required properties: +- compatible: should be "auo,g101evn010" +- power-supply: as specified in the base binding + +Optional properties: +- backlight: as specified in the base binding +- enable-gpios: as specified in the base binding + +This binding is compatible with the simple-panel binding, which is specified +in simple-panel.txt in this directory. -- cgit From bd59f2b153af8f387b8fee5cfa5c3084b40b57a0 Mon Sep 17 00:00:00 2001 From: Noralf Trønnes Date: Tue, 15 Jan 2019 05:36:43 +0100 Subject: drm/todo: Tick off some tinydrm entries MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - Better manual-upload support for atomic The new damage helper has the necessary pieces to make this work. - tinydrm_gem_cma_prime_import_sg_table This is now moved to the CMA helper and can be set using the DRM_GEM_CMA_VMAP_DRIVER_OPS macro. - tinydrm_fb_create This is now covered by drm_gem_fb_create_with_dirty() Cc: Sam Ravnborg Signed-off-by: Noralf Trønnes Reviewed-by: Sam Ravnborg Link: https://patchwork.freedesktop.org/patch/msgid/20190115043643.2364-6-noralf@tronnes.org --- Documentation/gpu/todo.rst | 35 ----------------------------------- 1 file changed, 35 deletions(-) (limited to 'Documentation') diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst index 0a85dad876ae..38360ede1221 100644 --- a/Documentation/gpu/todo.rst +++ b/Documentation/gpu/todo.rst @@ -82,30 +82,6 @@ events for atomic commits correctly. But fixing these bugs is good anyway. Contact: Daniel Vetter, respective driver maintainers -Better manual-upload support for atomic ---------------------------------------- - -This would be especially useful for tinydrm: - -- Add a struct drm_rect dirty_clip to drm_crtc_state. When duplicating the - crtc state, clear that to the max values, x/y = 0 and w/h = MAX_INT, in - __drm_atomic_helper_crtc_duplicate_state(). - -- Move tinydrm_merge_clips into drm_framebuffer.c, dropping the tinydrm\_ - prefix ofc and using drm_fb\_. drm_framebuffer.c makes sense since this - is a function useful to implement the fb->dirty function. - -- Create a new drm_fb_dirty function which does essentially what e.g. - mipi_dbi_fb_dirty does. You can use e.g. drm_atomic_helper_update_plane as the - template. But instead of doing a simple full-screen plane update, this new - helper also sets crtc_state->dirty_clip to the right coordinates. And of - course it needs to check whether the fb is actually active (and maybe where), - so there's some book-keeping involved. There's also some good fun involved in - scaling things appropriately. For that case we might simply give up and - declare the entire area covered by the plane as dirty. - -Contact: Noralf Trønnes, Daniel Vetter - Fallout from atomic KMS ----------------------- @@ -459,21 +435,10 @@ those drivers as simple as possible, so lots of room for refactoring: one of the ideas for having a shared dsi/dbi helper, abstracting away the transport details more. -- tinydrm_gem_cma_prime_import_sg_table should probably go into the cma - helpers, as a _vmapped variant (since not every driver needs the vmap). - And tinydrm_gem_cma_free_object could the be merged into - drm_gem_cma_free_object(). - -- tinydrm_fb_create we could move into drm_simple_pipe, only need to add - the fb_create hook to drm_simple_pipe_funcs, which would again simplify a - bunch of things (since it gives you a one-stop vfunc for simple drivers). - - Quick aside: The unregister devm stuff is kinda getting the lifetimes of a drm_device wrong. Doesn't matter, since everyone else gets it wrong too :-) -- also rework the drm_framebuffer_funcs->dirty hook wire-up, see above. - Contact: Noralf Trønnes, Daniel Vetter AMD DC Display Driver -- cgit From 2c6467d29583cba33da6e4265be09968e3d10b3c Mon Sep 17 00:00:00 2001 From: Peter Rosin Date: Fri, 11 Jan 2019 15:18:55 +0000 Subject: dt-bindings: display: bridge: fork out ti, ds90c185 from lvds-transmitter DS90C185 has a shutdown pin which does not fit in the lvds-transmitter binding, which is meant to be generic. The sister chip DS90C187 is similar to DS90C185, describe it here as well. Signed-off-by: Peter Rosin Reviewed-by: Rob Herring Signed-off-by: Andrzej Hajda Link: https://patchwork.freedesktop.org/patch/msgid/20190111151843.11114-2-peda@axentia.se --- .../bindings/display/bridge/lvds-transmitter.txt | 10 ++-- .../bindings/display/bridge/ti,ds90c185.txt | 55 ++++++++++++++++++++++ 2 files changed, 59 insertions(+), 6 deletions(-) create mode 100644 Documentation/devicetree/bindings/display/bridge/ti,ds90c185.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt b/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt index 50220190c203..bc6960741cb5 100644 --- a/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt +++ b/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt @@ -22,13 +22,11 @@ among others. Required properties: -- compatible: Must be one or more of the following - - "ti,ds90c185" for the TI DS90C185 FPD-Link Serializer - - "lvds-encoder" for a generic LVDS encoder device +- compatible: Must be "lvds-encoder" - When compatible with the generic version, nodes must list the - device-specific version corresponding to the device first - followed by the generic version. + Any encoder compatible with this generic binding, but with additional + properties not listed here, must list a device specific compatible first + followed by this generic compatible. Required nodes: diff --git a/Documentation/devicetree/bindings/display/bridge/ti,ds90c185.txt b/Documentation/devicetree/bindings/display/bridge/ti,ds90c185.txt new file mode 100644 index 000000000000..e575f996959a --- /dev/null +++ b/Documentation/devicetree/bindings/display/bridge/ti,ds90c185.txt @@ -0,0 +1,55 @@ +Texas Instruments FPD-Link (LVDS) Serializer +-------------------------------------------- + +The DS90C185 and DS90C187 are low-power serializers for portable +battery-powered applications that reduces the size of the RGB +interface between the host GPU and the display. + +Required properties: + +- compatible: Should be + "ti,ds90c185", "lvds-encoder" for the TI DS90C185 FPD-Link Serializer + "ti,ds90c187", "lvds-encoder" for the TI DS90C187 FPD-Link Serializer + +Optional properties: + +- powerdown-gpios: Power down control GPIO (the PDB pin, active-low) + +Required nodes: + +The devices have two video ports. Their connections are modeled using the OF +graph bindings specified in Documentation/devicetree/bindings/graph.txt. + +- Video port 0 for parallel input +- Video port 1 for LVDS output + + +Example +------- + +lvds-encoder { + compatible = "ti,ds90c185", "lvds-encoder"; + + powerdown-gpios = <&gpio 17 GPIO_ACTIVE_LOW>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + + lvds_enc_in: endpoint { + remote-endpoint = <&lcdc_out_rgb>; + }; + }; + + port@1 { + reg = <1>; + + lvds_enc_out: endpoint { + remote-endpoint = <&lvds_panel_in>; + }; + }; + }; +}; -- cgit From ad223fe3a6fdc18de696d1a39ff62a43700f93ec Mon Sep 17 00:00:00 2001 From: Peter Rosin Date: Fri, 11 Jan 2019 15:19:00 +0000 Subject: dt-bindings: display: bridge: lvds-transmitter: cleanup example Drop #address-cells and #size-cells from the root node in the example, they are unused. Reviewed-by: Rob Herring Signed-off-by: Peter Rosin Signed-off-by: Andrzej Hajda Link: https://patchwork.freedesktop.org/patch/msgid/20190111151843.11114-3-peda@axentia.se --- Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt | 2 -- 1 file changed, 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt b/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt index bc6960741cb5..60091db5dfa5 100644 --- a/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt +++ b/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt @@ -42,8 +42,6 @@ Example lvds-encoder { compatible = "lvds-encoder"; - #address-cells = <1>; - #size-cells = <0>; ports { #address-cells = <1>; -- cgit From c572c95c42bf4d6768d7ec0969bb603bb3738f0e Mon Sep 17 00:00:00 2001 From: Peter Rosin Date: Fri, 11 Jan 2019 15:19:05 +0000 Subject: dt-bindings: display: bridge: thc63lvdm83d: use standard powerdown-gpios The name powerdown-gpios is the standard property name for the functionality covered by the previous pwdn-gpios name. This rename should be safe to do since the linux driver supporting the binding (lvds-encoder.c) never implemented the property, and no dts file names it. At least not upstream. Reviewed-by: Rob Herring Signed-off-by: Peter Rosin Signed-off-by: Andrzej Hajda Link: https://patchwork.freedesktop.org/patch/msgid/20190111151843.11114-4-peda@axentia.se --- Documentation/devicetree/bindings/display/bridge/thine,thc63lvdm83d.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/bridge/thine,thc63lvdm83d.txt b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvdm83d.txt index 527e236e9a2a..fee3c88e1a17 100644 --- a/Documentation/devicetree/bindings/display/bridge/thine,thc63lvdm83d.txt +++ b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvdm83d.txt @@ -10,7 +10,7 @@ Required properties: Optional properties: -- pwdn-gpios: Power down control GPIO +- powerdown-gpios: Power down control GPIO (the /PWDN pin, active low). Required nodes: -- cgit From d62cd1b802d0842275ddafd8ba4ed82832968cd0 Mon Sep 17 00:00:00 2001 From: Chen-Yu Tsai Date: Fri, 25 Jan 2019 11:23:05 +0800 Subject: dt-bindings: display: sun4i-drm: Add compatible strings for A23 display The A23's display pipeline is similar to the A33. Differences include: - Display backend supports larger layers, 8192x8192 instead of 2048x2048 - TCON has DMA input - There is no SAT module packed in the display backend Add compatible strings for the display pipeline and its components. As the MIPI DSI output device is not officially documented, and there are no A23 reference devices to test it, it is not covered by this patch. Signed-off-by: Chen-Yu Tsai Signed-off-by: Maxime Ripard Link: https://patchwork.freedesktop.org/patch/msgid/20190125032314.20915-3-wens@csie.org --- Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt | 5 +++++ 1 file changed, 5 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt index f426bdb42f18..31ab72cba3d4 100644 --- a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt +++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt @@ -156,6 +156,7 @@ Required properties: * allwinner,sun6i-a31-tcon * allwinner,sun6i-a31s-tcon * allwinner,sun7i-a20-tcon + * allwinner,sun8i-a23-tcon * allwinner,sun8i-a33-tcon * allwinner,sun8i-a83t-tcon-lcd * allwinner,sun8i-a83t-tcon-tv @@ -276,6 +277,7 @@ Required properties: - compatible: value must be one of: * allwinner,sun6i-a31-drc * allwinner,sun6i-a31s-drc + * allwinner,sun8i-a23-drc * allwinner,sun8i-a33-drc * allwinner,sun9i-a80-drc - reg: base address and size of the memory-mapped region. @@ -303,6 +305,7 @@ Required properties: * allwinner,sun5i-a13-display-backend * allwinner,sun6i-a31-display-backend * allwinner,sun7i-a20-display-backend + * allwinner,sun8i-a23-display-backend * allwinner,sun8i-a33-display-backend * allwinner,sun9i-a80-display-backend - reg: base address and size of the memory-mapped region. @@ -360,6 +363,7 @@ Required properties: * allwinner,sun5i-a13-display-frontend * allwinner,sun6i-a31-display-frontend * allwinner,sun7i-a20-display-frontend + * allwinner,sun8i-a23-display-frontend * allwinner,sun8i-a33-display-frontend * allwinner,sun9i-a80-display-frontend - reg: base address and size of the memory-mapped region. @@ -419,6 +423,7 @@ Required properties: * allwinner,sun6i-a31-display-engine * allwinner,sun6i-a31s-display-engine * allwinner,sun7i-a20-display-engine + * allwinner,sun8i-a23-display-engine * allwinner,sun8i-a33-display-engine * allwinner,sun8i-a83t-display-engine * allwinner,sun8i-h3-display-engine -- cgit From 24de022b8171fb84f87c22ad1714018fd982c834 Mon Sep 17 00:00:00 2001 From: Jagan Teki Date: Fri, 25 Jan 2019 03:21:30 +0530 Subject: dt-bindings: display: Add Sitronix ST7701 panel documentation Techstar TS8550B MIPI DSI panel is 480x854, 2-lane MIPI DSI LCD panel with inbuilt ST7701 chip. The default regulator names in ST7701 chip is renamed in Techstar TS8550B so, add specific binding names for them. Signed-off-by: Jagan Teki Reviewed-by: Rob Herring Signed-off-by: Thierry Reding Link: https://patchwork.freedesktop.org/patch/msgid/20190124215131.17452-1-jagan@amarulasolutions.com --- .../bindings/display/panel/sitronix,st7701.txt | 30 ++++++++++++++++++++++ 1 file changed, 30 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/panel/sitronix,st7701.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/panel/sitronix,st7701.txt b/Documentation/devicetree/bindings/display/panel/sitronix,st7701.txt new file mode 100644 index 000000000000..ccd17597f1f6 --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/sitronix,st7701.txt @@ -0,0 +1,30 @@ +Sitronix ST7701 based LCD panels + +ST7701 designed for small and medium sizes of TFT LCD display, is +capable of supporting up to 480RGBX864 in resolution. It provides +several system interfaces like MIPI/RGB/SPI. + +Techstar TS8550B is 480x854, 2-lane MIPI DSI LCD panel which has +inbuilt ST7701 chip. + +Required properties: +- compatible: must be "sitronix,st7701" and one of + * "techstar,ts8550b" +- reset-gpios: a GPIO phandle for the reset pin + +Required properties for techstar,ts8550b: +- reg: DSI virtual channel used by that screen +- VCC-supply: analog regulator for MIPI circuit +- IOVCC-supply: I/O system regulator + +Optional properties: +- backlight: phandle for the backlight control. + +panel@0 { + compatible = "techstar,ts8550b", "sitronix,st7701"; + reg = <0>; + VCC-supply = <®_dldo2>; + IOVCC-supply = <®_dldo2>; + reset-gpios = <&pio 3 24 GPIO_ACTIVE_HIGH>; /* LCD-RST: PD24 */ + backlight = <&backlight>; +}; -- cgit From 6f4fcfe0297c3b5d71157d2898a706025cc83c2b Mon Sep 17 00:00:00 2001 From: Paul Kocialkowski Date: Wed, 7 Nov 2018 19:18:39 +0100 Subject: dt-bindings: Add vendor prefix for LeMaker This introduces a new device-tree binding vendor prefix for Shenzhen LeMaker Technology Co., Ltd. This vendor was already in use but it was not documented until now. Signed-off-by: Paul Kocialkowski Reviewed-by: Rob Hering Reviewed-by: Rob Herring Signed-off-by: Thierry Reding Link: https://patchwork.freedesktop.org/patch/msgid/20181107181843.27628-5-contact@paulk.fr --- Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index 389508584f48..1d168ed55f8e 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -211,6 +211,7 @@ laird Laird PLC lantiq Lantiq Semiconductor lattice Lattice Semiconductor lego LEGO Systems A/S +lemaker Shenzhen LeMaker Technology Co., Ltd. lenovo Lenovo Group Ltd. lg LG Corporation libretech Shenzhen Libre Technology Co., Ltd -- cgit From 78d1773f8eb59a03d5e34176cdb3776638bf3403 Mon Sep 17 00:00:00 2001 From: Paul Kocialkowski Date: Wed, 7 Nov 2018 19:18:40 +0100 Subject: dt-bindings: display: Add bindings for the LeMaker BL035-RGB-002 LCD panel This adds the device-tree bindings for the LeMaker BL035-RGB-002 3.5" QVGA TFT LCD panel, compatible with simple-panel. Signed-off-by: Paul Kocialkowski Reviewed-by: Rob Herring Signed-off-by: Thierry Reding Link: https://patchwork.freedesktop.org/patch/msgid/20181107181843.27628-6-contact@paulk.fr --- .../bindings/display/panel/lemaker,bl035-rgb-002.txt | 12 ++++++++++++ 1 file changed, 12 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/panel/lemaker,bl035-rgb-002.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/panel/lemaker,bl035-rgb-002.txt b/Documentation/devicetree/bindings/display/panel/lemaker,bl035-rgb-002.txt new file mode 100644 index 000000000000..74ee7ea6b493 --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/lemaker,bl035-rgb-002.txt @@ -0,0 +1,12 @@ +LeMaker BL035-RGB-002 3.5" QVGA TFT LCD panel + +Required properties: +- compatible: should be "lemaker,bl035-rgb-002" +- power-supply: as specified in the base binding + +Optional properties: +- backlight: as specified in the base binding +- enable-gpios: as specified in the base binding + +This binding is compatible with the simple-panel binding, which is specified +in simple-panel.txt in this directory. -- cgit From 20e3412b0db2928d91c7540940080c42afbd8c84 Mon Sep 17 00:00:00 2001 From: Eugen Hristev Date: Mon, 14 Jan 2019 09:43:26 +0000 Subject: dt-bindings: Add vendor prefix for PDA Precision Design Associates, Inc. Precision Design Associates, Inc. (PDA) manufactures standard and custom capacitive touch screens, LCD's embedded controllers and custom embedded software. They specialize in industrial, rugged and outdoor applications. Website: http://www.pdaatl.com/ Signed-off-by: Eugen Hristev Reviewed-by: Rob Herring Signed-off-by: Thierry Reding Link: https://patchwork.freedesktop.org/patch/msgid/1547458584-29548-2-git-send-email-eugen.hristev@microchip.com --- Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index 1d168ed55f8e..4f225ce815d8 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -298,6 +298,7 @@ ovti OmniVision Technologies oxsemi Oxford Semiconductor, Ltd. panasonic Panasonic Corporation parade Parade Technologies Inc. +pda Precision Design Associates, Inc. pericom Pericom Technology Inc. pervasive Pervasive Displays, Inc. phicomm PHICOMM Co., Ltd. -- cgit From b3b54ed1731cfd809c5d02b3334977619cece3bf Mon Sep 17 00:00:00 2001 From: Cristian Birsan Date: Mon, 14 Jan 2019 09:43:28 +0000 Subject: dt-bindings: display: Add support for PDA 91-00156-A0 panel PDA 91-00156-A0 5.0 is a 5.0" WVGA TFT LCD panel. This panel with backlight is found in PDA 5" LCD screen (TM5000 series or AC320005-5). Adding device tree bindings for this panel. Signed-off-by: Cristian Birsan [eugen.hristev@microchip.com]: specified backlight and supply bindings Signed-off-by: Eugen Hristev Reviewed-by: Rob Herring Signed-off-by: Thierry Reding Link: https://patchwork.freedesktop.org/patch/msgid/1547458584-29548-3-git-send-email-eugen.hristev@microchip.com --- .../devicetree/bindings/display/panel/pda,91-00156-a0.txt | 14 ++++++++++++++ 1 file changed, 14 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/panel/pda,91-00156-a0.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/panel/pda,91-00156-a0.txt b/Documentation/devicetree/bindings/display/panel/pda,91-00156-a0.txt new file mode 100644 index 000000000000..1639fb17a9f0 --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/pda,91-00156-a0.txt @@ -0,0 +1,14 @@ +PDA 91-00156-A0 5.0" WVGA TFT LCD panel + +Required properties: +- compatible: should be "pda,91-00156-a0" +- power-supply: this panel requires a single power supply. A phandle to a +regulator needs to be specified here. Compatible with panel-common binding which +is specified in the panel-common.txt in this directory. +- backlight: this panel's backlight is controlled by an external backlight +controller. A phandle to this controller needs to be specified here. +Compatible with panel-common binding which is specified in the panel-common.txt +in this directory. + +This binding is compatible with the simple-panel binding, which is specified +in simple-panel.txt in this directory. -- cgit From 0e2a933b02c972919f7478364177eb76cd4ae00d Mon Sep 17 00:00:00 2001 From: Daniel Vetter Date: Tue, 29 Jan 2019 11:42:47 +0100 Subject: drm: Switch DRIVER_ flags to an enum And move the documenation we alreay have into kerneldoc, plus a bit of polish while at it. v2: - Ditch FIXME from commit message, I've resolved that already before sending out the first version. - Put the legacy DRIVER_ flags at the end (Sam). Cc: Sam Ravnborg Reviewed-by: Emil Velikov Reviewed-by: Sam Ravnborg Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20190129104248.26607-2-daniel.vetter@ffwll.ch --- Documentation/gpu/drm-internals.rst | 62 ------------------------------------- 1 file changed, 62 deletions(-) (limited to 'Documentation') diff --git a/Documentation/gpu/drm-internals.rst b/Documentation/gpu/drm-internals.rst index 2caf21effd28..3ae23a5454ac 100644 --- a/Documentation/gpu/drm-internals.rst +++ b/Documentation/gpu/drm-internals.rst @@ -39,68 +39,6 @@ sections. Driver Information ------------------ -Driver Features -~~~~~~~~~~~~~~~ - -Drivers inform the DRM core about their requirements and supported -features by setting appropriate flags in the driver_features field. -Since those flags influence the DRM core behaviour since registration -time, most of them must be set to registering the :c:type:`struct -drm_driver ` instance. - -u32 driver_features; - -DRIVER_USE_AGP - Driver uses AGP interface, the DRM core will manage AGP resources. - -DRIVER_LEGACY - Denote a legacy driver using shadow attach. Don't use. - -DRIVER_KMS_LEGACY_CONTEXT - Used only by nouveau for backwards compatibility with existing userspace. - Don't use. - -DRIVER_PCI_DMA - Driver is capable of PCI DMA, mapping of PCI DMA buffers to - userspace will be enabled. Deprecated. - -DRIVER_SG - Driver can perform scatter/gather DMA, allocation and mapping of - scatter/gather buffers will be enabled. Deprecated. - -DRIVER_HAVE_DMA - Driver supports DMA, the userspace DMA API will be supported. - Deprecated. - -DRIVER_HAVE_IRQ; DRIVER_IRQ_SHARED - DRIVER_HAVE_IRQ indicates whether the driver has an IRQ handler - managed by the DRM Core. The core will support simple IRQ handler - installation when the flag is set. The installation process is - described in ?. - - DRIVER_IRQ_SHARED indicates whether the device & handler support - shared IRQs (note that this is required of PCI drivers). - -DRIVER_GEM - Driver use the GEM memory manager. - -DRIVER_MODESET - Driver supports mode setting interfaces (KMS). - -DRIVER_PRIME - Driver implements DRM PRIME buffer sharing. - -DRIVER_RENDER - Driver supports dedicated render nodes. - -DRIVER_ATOMIC - Driver supports atomic properties. In this case the driver must - implement appropriate obj->atomic_get_property() vfuncs for any - modeset objects with driver specific properties. - -DRIVER_SYNCOBJ - Driver support drm sync objects. - Major, Minor and Patchlevel ~~~~~~~~~~~~~~~~~~~~~~~~~~~ -- cgit From b8be1cd9b010da726907a38b7a43d7259db51081 Mon Sep 17 00:00:00 2001 From: Jordan Crouse Date: Tue, 18 Dec 2018 11:32:37 -0700 Subject: drm/msm: drop interrupt-names Each GPU core only uses one interrupt so we don't to look up an interrupt by name and thereby we don't need interrupt-names. Signed-off-by: Jordan Crouse Reviewed-by: Rob Herring Signed-off-by: Rob Clark --- Documentation/devicetree/bindings/display/msm/gpu.txt | 1 - 1 file changed, 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/msm/gpu.txt b/Documentation/devicetree/bindings/display/msm/gpu.txt index ac8df3b871f9..f8759145ce1a 100644 --- a/Documentation/devicetree/bindings/display/msm/gpu.txt +++ b/Documentation/devicetree/bindings/display/msm/gpu.txt @@ -27,7 +27,6 @@ Example: reg = <0x04300000 0x20000>; reg-names = "kgsl_3d0_reg_memory"; interrupts = ; - interrupt-names = "kgsl_3d0_irq"; clock-names = "core", "iface", -- cgit From 740f9433a85408039aac33eb7f62a6a8d552d983 Mon Sep 17 00:00:00 2001 From: Jordan Crouse Date: Tue, 18 Dec 2018 11:32:40 -0700 Subject: dt-bindings: drm/msm/a6xx: Document GMU and update GPU bindings Update the GPU bindings and document the new bindings for the GMU device found with Adreno a6xx targets. Signed-off-by: Jordan Crouse Reviewed-by: Rob Herring Signed-off-by: Rob Clark --- .../devicetree/bindings/display/msm/gpu.txt | 42 ++++++++++++++++++++-- 1 file changed, 39 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/msm/gpu.txt b/Documentation/devicetree/bindings/display/msm/gpu.txt index f8759145ce1a..aad1aef682f7 100644 --- a/Documentation/devicetree/bindings/display/msm/gpu.txt +++ b/Documentation/devicetree/bindings/display/msm/gpu.txt @@ -10,14 +10,23 @@ Required properties: If "amd,imageon" is used, there should be no top level msm device. - reg: Physical base address and length of the controller's registers. - interrupts: The interrupt signal from the gpu. -- clocks: device clocks +- clocks: device clocks (if applicable) See ../clocks/clock-bindings.txt for details. -- clock-names: the following clocks are required: +- clock-names: the following clocks are required by a3xx, a4xx and a5xx + cores: * "core" * "iface" * "mem_iface" + For GMU attached devices the GPU clocks are not used and are not required. The + following devices should not list clocks: + - qcom,adreno-630.2 +- iommus: optional phandle to an adreno iommu instance +- operating-points-v2: optional phandle to the OPP operating points +- qcom,gmu: For GMU attached devices a phandle to the GMU device that will + control the power for the GPU. Applicable targets: + - qcom,adreno-630.2 -Example: +Example 3xx/4xx/a5xx: / { ... @@ -37,3 +46,30 @@ Example: <&mmcc MMSS_IMEM_AHB_CLK>; }; }; + +Example a6xx (with GMU): + +/ { + ... + + gpu@5000000 { + compatible = "qcom,adreno-630.2", "qcom,adreno"; + #stream-id-cells = <16>; + + reg = <0x5000000 0x40000>, <0x509e000 0x10>; + reg-names = "kgsl_3d0_reg_memory", "cx_mem"; + + /* + * Look ma, no clocks! The GPU clocks and power are + * controlled entirely by the GMU + */ + + interrupts = ; + + iommus = <&adreno_smmu 0>; + + operating-points-v2 = <&gpu_opp_table>; + + qcom,gmu = <&gmu>; + }; +}; -- cgit From 8aa82766de12d11a7e00d02b6d74349f57a8219e Mon Sep 17 00:00:00 2001 From: Jordan Crouse Date: Wed, 16 Jan 2019 14:09:51 -0700 Subject: dt-bindings: drm/msm/a6xx: Document GMU bindings Commit 24937c540917 ("dt-bindings: drm/msm/a6xx: Document GMU and update GPU bindings") mistakenly omitted the GMU bindings as seen in [1]. Return them to their rightful place. [1] https://patchwork.freedesktop.org/patch/268679/ Signed-off-by: Jordan Crouse Reviewed-by: Rob Herring Signed-off-by: Rob Clark --- .../devicetree/bindings/display/msm/gmu.txt | 59 ++++++++++++++++++++++ 1 file changed, 59 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/msm/gmu.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/msm/gmu.txt b/Documentation/devicetree/bindings/display/msm/gmu.txt new file mode 100644 index 000000000000..3439b38e60f2 --- /dev/null +++ b/Documentation/devicetree/bindings/display/msm/gmu.txt @@ -0,0 +1,59 @@ +Qualcomm adreno/snapdragon GMU (Graphics management unit) + +The GMU is a programmable power controller for the GPU. the CPU controls the +GMU which in turn handles power controls for the GPU. + +Required properties: +- compatible: "qcom,adreno-gmu-XYZ.W", "qcom,adreno-gmu" + for example: "qcom,adreno-gmu-630.2", "qcom,adreno-gmu" + Note that you need to list the less specific "qcom,adreno-gmu" + for generic matches and the more specific identifier to identify + the specific device. +- reg: Physical base address and length of the GMU registers. +- reg-names: Matching names for the register regions + * "gmu" + * "gmu_pdc" + * "gmu_pdc_seg" +- interrupts: The interrupt signals from the GMU. +- interrupt-names: Matching names for the interrupts + * "hfi" + * "gmu" +- clocks: phandles to the device clocks +- clock-names: Matching names for the clocks + * "gmu" + * "cxo" + * "axi" + * "mnoc" +- power-domains: should be <&clock_gpucc GPU_CX_GDSC> +- iommus: phandle to the adreno iommu +- operating-points-v2: phandle to the OPP operating points + +Example: + +/ { + ... + + gmu: gmu@506a000 { + compatible="qcom,adreno-gmu-630.2", "qcom,adreno-gmu"; + + reg = <0x506a000 0x30000>, + <0xb280000 0x10000>, + <0xb480000 0x10000>; + reg-names = "gmu", "gmu_pdc", "gmu_pdc_seq"; + + interrupts = , + ; + interrupt-names = "hfi", "gmu"; + + clocks = <&gpucc GPU_CC_CX_GMU_CLK>, + <&gpucc GPU_CC_CXO_CLK>, + <&gcc GCC_DDRSS_GPU_AXI_CLK>, + <&gcc GCC_GPU_MEMNOC_GFX_CLK>; + clock-names = "gmu", "cxo", "axi", "memnoc"; + + power-domains = <&gpucc GPU_CX_GDSC>; + iommus = <&adreno_smmu 5>; + + operating-points-v2 = <&gmu_opp_table>; + }; +}; -- cgit From e57924d4ae80f8e076d3597c1f1f23d624c555af Mon Sep 17 00:00:00 2001 From: Daniel Vetter Date: Tue, 29 Jan 2019 14:21:53 +0100 Subject: drm/doc: Task to rename CMA helpers MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit I'm kinda fed up explaining why the have a confusing name :-) v2: Fix typo that Eric Engestrom spotted. Cc: Noralf Trønnes Cc: Laurent Pinchart Acked-by: Noralf Trønnes Acked-by: Laurent Pinchart Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20190129132153.28844-1-daniel.vetter@ffwll.ch --- Documentation/gpu/todo.rst | 10 ++++++++++ 1 file changed, 10 insertions(+) (limited to 'Documentation') diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst index 38360ede1221..a1d91ca7f65c 100644 --- a/Documentation/gpu/todo.rst +++ b/Documentation/gpu/todo.rst @@ -262,6 +262,16 @@ As a reference, take a look at the conversions already completed in drm core. Contact: Sean Paul, respective driver maintainers +Rename CMA helpers to DMA helpers +--------------------------------- + +CMA (standing for contiguous memory allocator) is really a bit an accident of +what these were used for first, a much better name would be DMA helpers. In the +text these should even be called coherent DMA memory helpers (so maybe CDM, but +no one knows what that means) since underneath they just use dma_alloc_coherent. + +Contact: Laurent Pinchart, Daniel Vetter + Core refactorings ================= -- cgit From 5d0aa37855635ac99bcebcaf559e6d9d867e72f9 Mon Sep 17 00:00:00 2001 From: Daniel Vetter Date: Wed, 30 Jan 2019 17:30:04 +0100 Subject: drm/doc: Move hdmi infoframe docs .. next to all the other sink helpers. The rect library is more used for handling plane clipping, so belongs to those imo. Reviewed-by: Nicholas Kazlauskas Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20190130163006.28945-1-daniel.vetter@ffwll.ch --- Documentation/gpu/drm-kms-helpers.rst | 24 ++++++++++++------------ 1 file changed, 12 insertions(+), 12 deletions(-) (limited to 'Documentation') diff --git a/Documentation/gpu/drm-kms-helpers.rst b/Documentation/gpu/drm-kms-helpers.rst index fbd11b2fe5b5..17ca7f8bf3d3 100644 --- a/Documentation/gpu/drm-kms-helpers.rst +++ b/Documentation/gpu/drm-kms-helpers.rst @@ -296,18 +296,6 @@ SCDC Helper Functions Reference .. kernel-doc:: drivers/gpu/drm/drm_scdc_helper.c :export: -Rectangle Utilities Reference -============================= - -.. kernel-doc:: include/drm/drm_rect.h - :doc: rect utils - -.. kernel-doc:: include/drm/drm_rect.h - :internal: - -.. kernel-doc:: drivers/gpu/drm/drm_rect.c - :export: - HDMI Infoframes Helper Reference ================================ @@ -322,6 +310,18 @@ libraries and hence is also included here. .. kernel-doc:: drivers/video/hdmi.c :export: +Rectangle Utilities Reference +============================= + +.. kernel-doc:: include/drm/drm_rect.h + :doc: rect utils + +.. kernel-doc:: include/drm/drm_rect.h + :internal: + +.. kernel-doc:: drivers/gpu/drm/drm_rect.c + :export: + Flip-work Helper Reference ========================== -- cgit From d9f7bb56c2925ea0641fe5121b954acc6a873605 Mon Sep 17 00:00:00 2001 From: Daniel Vetter Date: Wed, 30 Jan 2019 17:30:05 +0100 Subject: drm/doc: Drop chapter "KMS Initialization and Cleanup" It only talks about crtc, brings up intel as an example and I think is more misleading than useful really. Plus we have lots of discussion about how your standard kms driver should be initialized/cleaned up, so maybe better to document this when we have a better idea. v2: Fix typo in commit message (Nicholas). Reviewed-by: Nicholas Kazlauskas Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20190130163006.28945-2-daniel.vetter@ffwll.ch --- Documentation/gpu/drm-kms.rst | 96 ------------------------------------------- 1 file changed, 96 deletions(-) (limited to 'Documentation') diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst index 75c882e09fee..23a3c986ef6d 100644 --- a/Documentation/gpu/drm-kms.rst +++ b/Documentation/gpu/drm-kms.rst @@ -410,102 +410,6 @@ Encoder Functions Reference .. kernel-doc:: drivers/gpu/drm/drm_encoder.c :export: -KMS Initialization and Cleanup -============================== - -A KMS device is abstracted and exposed as a set of planes, CRTCs, -encoders and connectors. KMS drivers must thus create and initialize all -those objects at load time after initializing mode setting. - -CRTCs (:c:type:`struct drm_crtc `) --------------------------------------------- - -A CRTC is an abstraction representing a part of the chip that contains a -pointer to a scanout buffer. Therefore, the number of CRTCs available -determines how many independent scanout buffers can be active at any -given time. The CRTC structure contains several fields to support this: -a pointer to some video memory (abstracted as a frame buffer object), a -display mode, and an (x, y) offset into the video memory to support -panning or configurations where one piece of video memory spans multiple -CRTCs. - -CRTC Initialization -~~~~~~~~~~~~~~~~~~~ - -A KMS device must create and register at least one struct -:c:type:`struct drm_crtc ` instance. The instance is -allocated and zeroed by the driver, possibly as part of a larger -structure, and registered with a call to :c:func:`drm_crtc_init()` -with a pointer to CRTC functions. - - -Cleanup -------- - -The DRM core manages its objects' lifetime. When an object is not needed -anymore the core calls its destroy function, which must clean up and -free every resource allocated for the object. Every -:c:func:`drm_\*_init()` call must be matched with a corresponding -:c:func:`drm_\*_cleanup()` call to cleanup CRTCs -(:c:func:`drm_crtc_cleanup()`), planes -(:c:func:`drm_plane_cleanup()`), encoders -(:c:func:`drm_encoder_cleanup()`) and connectors -(:c:func:`drm_connector_cleanup()`). Furthermore, connectors that -have been added to sysfs must be removed by a call to -:c:func:`drm_connector_unregister()` before calling -:c:func:`drm_connector_cleanup()`. - -Connectors state change detection must be cleanup up with a call to -:c:func:`drm_kms_helper_poll_fini()`. - -Output discovery and initialization example -------------------------------------------- - -.. code-block:: c - - void intel_crt_init(struct drm_device *dev) - { - struct drm_connector *connector; - struct intel_output *intel_output; - - intel_output = kzalloc(sizeof(struct intel_output), GFP_KERNEL); - if (!intel_output) - return; - - connector = &intel_output->base; - drm_connector_init(dev, &intel_output->base, - &intel_crt_connector_funcs, DRM_MODE_CONNECTOR_VGA); - - drm_encoder_init(dev, &intel_output->enc, &intel_crt_enc_funcs, - DRM_MODE_ENCODER_DAC); - - drm_connector_attach_encoder(&intel_output->base, - &intel_output->enc); - - /* Set up the DDC bus. */ - intel_output->ddc_bus = intel_i2c_create(dev, GPIOA, "CRTDDC_A"); - if (!intel_output->ddc_bus) { - dev_printk(KERN_ERR, &dev->pdev->dev, "DDC bus registration " - "failed.\n"); - return; - } - - intel_output->type = INTEL_OUTPUT_ANALOG; - connector->interlace_allowed = 0; - connector->doublescan_allowed = 0; - - drm_encoder_helper_add(&intel_output->enc, &intel_crt_helper_funcs); - drm_connector_helper_add(connector, &intel_crt_connector_helper_funcs); - - drm_connector_register(connector); - } - -In the example above (taken from the i915 driver), a CRTC, connector and -encoder combination is created. A device-specific i2c bus is also -created for fetching EDID data and performing monitor detection. Once -the process is complete, the new connector is registered with sysfs to -make its properties available to applications. - KMS Locking =========== -- cgit From d60ea31a87314eb7bea0b2dcbd36cf12bdf9ac0d Mon Sep 17 00:00:00 2001 From: Sean Paul Date: Tue, 29 Jan 2019 14:26:29 -0500 Subject: drm/TODO: Add drm_display_mode.hsync/vrefresh removal MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Drivers shouldn't be using these values, add a TODO so someone removes them. Changes in v2: - Add drm_display_mode.vrefresh removal (Ville) - Add Sam's R-b and bonus points Changes in v3: - Add hsync removal todo item (Daniel) - Change vrefresh wording to make removal less optional Cc: Ville Syrjälä Suggested-by: Daniel Vetter Reviewed-by: Daniel Vetter Reviewed-by: Sam Ravnborg Bonus-points-awarded-by: Sam Ravnborg Signed-off-by: Sean Paul Link: https://patchwork.freedesktop.org/patch/msgid/20190129192637.73296-1-sean@poorly.run --- Documentation/gpu/todo.rst | 28 ++++++++++++++++++++++++++++ 1 file changed, 28 insertions(+) (limited to 'Documentation') diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst index a1d91ca7f65c..cda4a37a02f0 100644 --- a/Documentation/gpu/todo.rst +++ b/Documentation/gpu/todo.rst @@ -272,6 +272,34 @@ no one knows what that means) since underneath they just use dma_alloc_coherent. Contact: Laurent Pinchart, Daniel Vetter +Convert direct mode.vrefresh accesses to use drm_mode_vrefresh() +---------------------------------------------------------------- + +drm_display_mode.vrefresh isn't guaranteed to be populated. As such, using it +is risky and has been known to cause div-by-zero bugs. Fortunately, drm core +has helper which will use mode.vrefresh if it's !0 and will calculate it from +the timings when it's 0. + +Use simple search/replace, or (more fun) cocci to replace instances of direct +vrefresh access with a call to the helper. Check out +https://lists.freedesktop.org/archives/dri-devel/2019-January/205186.html for +inspiration. + +Once all instances of vrefresh have been converted, remove vrefresh from +drm_display_mode to avoid future use. + +Contact: Sean Paul + +Remove drm_display_mode.hsync +----------------------------- + +We have drm_mode_hsync() to calculate this from hsync_start/end, since drivers +shouldn't/don't use this, remove this member to avoid any temptations to use it +in the future. If there is any debug code using drm_display_mode.hsync, convert +it to use drm_mode_hsync() instead. + +Contact: Sean Paul + Core refactorings ================= -- cgit From 24332d0d06a25d9fe4e7fd0275b9586cc65aea68 Mon Sep 17 00:00:00 2001 From: Heiko Stuebner Date: Tue, 13 Nov 2018 13:42:05 +0100 Subject: dt-bindings: display: add binding for Innolux ee101ia-01d panel This is a panel handled through the generic lvds-panel binding, so only needs its additional compatible specified. Signed-off-by: Heiko Stuebner Reviewed-by: Rob Herring Link: https://patchwork.freedesktop.org/patch/msgid/20181113124205.29319-1-heiko@sntech.de --- .../devicetree/bindings/display/panel/innolux,ee101ia-01d.txt | 7 +++++++ 1 file changed, 7 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/panel/innolux,ee101ia-01d.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/panel/innolux,ee101ia-01d.txt b/Documentation/devicetree/bindings/display/panel/innolux,ee101ia-01d.txt new file mode 100644 index 000000000000..e5ca4ccd55ed --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/innolux,ee101ia-01d.txt @@ -0,0 +1,7 @@ +Innolux Corporation 10.1" EE101IA-01D WXGA (1280x800) LVDS panel + +Required properties: +- compatible: should be "innolux,ee101ia-01d" + +This binding is compatible with the lvds-panel binding, which is specified +in panel-lvds.txt in this directory. -- cgit From 8c77b2224306c06443a9270ff640faf143ed0183 Mon Sep 17 00:00:00 2001 From: Shayenne Moura Date: Wed, 6 Feb 2019 17:31:57 -0200 Subject: drm/doc: Remove solved "VBlank issues" Remove the list of broken tests on VKMS solved by patchset https://patchwork.freedesktop.org/series/55994/ Signed-off-by: Shayenne Moura Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20190206193157.3b53ipdxtcqc4hv4@smtp.gmail.com --- Documentation/gpu/vkms.rst | 11 ----------- 1 file changed, 11 deletions(-) (limited to 'Documentation') diff --git a/Documentation/gpu/vkms.rst b/Documentation/gpu/vkms.rst index 7dfc349a4508..61586fc861bb 100644 --- a/Documentation/gpu/vkms.rst +++ b/Documentation/gpu/vkms.rst @@ -23,17 +23,6 @@ CRC API Improvements - Add igt test to check extreme alpha values i.e. fully opaque and fully transparent (intermediate values are affected by hw-specific rounding modes). -Vblank issues -------------- - -Some IGT test cases are failing. Need to analyze why and fix the issues: - -- plain-flip-fb-recreate -- plain-flip-ts-check -- flip-vs-blocking-wf-vblank -- plain-flip-fb-recreate-interruptible -- flip-vs-wf_vblank-interruptible - Runtime Configuration --------------------- -- cgit From badfa5be854d52956eb32aa3b8d29db3fd2b05a7 Mon Sep 17 00:00:00 2001 From: Daniel Vetter Date: Mon, 28 Jan 2019 18:22:58 +0100 Subject: drm/doc: Make igts for cross-driver stuff strongly suggested Compared to the RFC[1] no changes to the patch itself, but igt moved forward a lot: - gitlab CI builds with: reduced configs/libraries, arm cross build and a sysroot build (should address all the build/cross platform concerns raised in the RFC discussions). - tests reorganized into subdirectories so that the i915-gem tests don't clog the main/shared tests directory anymore - quite a few more non-intel people contributing/reviewing/committing igt tests patches. I think this addresses all the concerns raised in the RFC discussions, and assuming there's enough Acks and no new issues that pop up, we can go ahead with this. v2: - Use "should" (in the usual RFC sense) to make it clear that in the end this is all up to reviewer's discretion, as usual (Jani). - Also in the title s/mandatory/strongly suggested/ (me) - Make it clear we're not going to block features if a testcase is not feasible, given hw and state of igt, both having some good gaps in what can be tested (Harry, Eric, Sean, ...). 1: https://patchwork.kernel.org/patch/10648851/ Cc: Petri Latvala Cc: Arkadiusz Hiler Cc: Liviu Dudau Cc: Sean Paul Cc: Eric Anholt Cc: Alex Deucher Cc: Dave Airlie Cc: Daniel Stone Cc: "Wentland, Harry" Cc: Brian Starkey Reviewed-by: Eric Anholt (v1) Acked-by: Petri Latvala Acked-by: Arkadiusz Hiler Acked-by: Sean Paul Acked-by: "Wentland, Harry" Signed-off-by: Daniel Vetter Acked-by: Liviu Dudau Acked-by: Jani Nikula Acked-by: Brian Starkey Acked-by: Tomi Valkeinen Acked-by: Boris Brezillon Acked-by: Alex Deucher Acked-by: Dave Airlie Link: https://patchwork.freedesktop.org/patch/msgid/20190128172258.9585-1-daniel.vetter@ffwll.ch --- Documentation/gpu/drm-uapi.rst | 8 ++++++++ 1 file changed, 8 insertions(+) (limited to 'Documentation') diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst index a752aa561ea4..c9fd23efd957 100644 --- a/Documentation/gpu/drm-uapi.rst +++ b/Documentation/gpu/drm-uapi.rst @@ -238,6 +238,14 @@ DRM specific patterns. Note that ENOTTY has the slightly unintuitive meaning of Testing and validation ====================== +Testing Requirements for userspace API +-------------------------------------- + +New cross-driver userspace interface extensions, like new IOCTL, new KMS +properties, new files in sysfs or anything else that constitutes an API change +should have driver-agnostic testcases in IGT for that feature, if such a test +can be reasonably made using IGT for the target hardware. + Validating changes with IGT --------------------------- -- cgit From 684c1b1457a2d83bd3138e244af220f943caef9e Mon Sep 17 00:00:00 2001 From: Paweł Chmiel Date: Fri, 28 Dec 2018 16:19:03 +0100 Subject: dt-bindings: gpu: samsung-rotator: Document s5pv210 support MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit This commit documents new compatible for s5pv210 soc, which will be also supported by this driver. Signed-off-by: Paweł Chmiel Reviewed-by: Rob Herring Acked-by: Krzysztof Kozlowski Signed-off-by: Inki Dae --- Documentation/devicetree/bindings/gpu/samsung-rotator.txt | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/gpu/samsung-rotator.txt b/Documentation/devicetree/bindings/gpu/samsung-rotator.txt index 82cd1ed0be93..3aca2578da0b 100644 --- a/Documentation/devicetree/bindings/gpu/samsung-rotator.txt +++ b/Documentation/devicetree/bindings/gpu/samsung-rotator.txt @@ -2,9 +2,10 @@ Required properties: - compatible : value should be one of the following: - (a) "samsung,exynos4210-rotator" for Rotator IP in Exynos4210 - (b) "samsung,exynos4212-rotator" for Rotator IP in Exynos4212/4412 - (c) "samsung,exynos5250-rotator" for Rotator IP in Exynos5250 + * "samsung,s5pv210-rotator" for Rotator IP in S5PV210 + * "samsung,exynos4210-rotator" for Rotator IP in Exynos4210 + * "samsung,exynos4212-rotator" for Rotator IP in Exynos4212/4412 + * "samsung,exynos5250-rotator" for Rotator IP in Exynos5250 - reg : Physical base address of the IP registers and length of memory mapped region. -- cgit From 6c2b3881d0df85fed7e3f43dcc9cbc3e5124bc12 Mon Sep 17 00:00:00 2001 From: Thierry Reding Date: Fri, 25 Jan 2019 11:00:57 +0100 Subject: dt-bindings: display: tegra: Support SOR crossbar configuration The SOR has a crossbar that can map each lane of the SOR to each of the SOR pads. The mapping is usually the same across designs for a specific SoC generation, but every now and then there's a design that doesn't. Allow the crossbar configuration to be specified in device tree to make it possible to support these designs. Signed-off-by: Thierry Reding --- .../devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt | 3 +++ 1 file changed, 3 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt index 593be44a53c9..9999255ac5b6 100644 --- a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt +++ b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt @@ -238,6 +238,9 @@ of the following host1x client modules: - nvidia,hpd-gpio: specifies a GPIO used for hotplug detection - nvidia,edid: supplies a binary EDID blob - nvidia,panel: phandle of a display panel + - nvidia,xbar-cfg: 5 cells containing the crossbar configuration. Each lane + of the SOR, identified by the cell's index, is mapped via the crossbar to + the pad specified by the cell's value. Optional properties when driving an eDP output: - nvidia,dpaux: phandle to a DispayPort AUX interface -- cgit From 8a2fe6c09f2ac17c7605982bc6810ea2b2c2a0d0 Mon Sep 17 00:00:00 2001 From: Biju Das Date: Tue, 22 Jan 2019 15:25:46 +0000 Subject: dt-bindings: display: renesas: lvds: Document r8a7744 bindings Document the RZ/G1N (R8A7744) LVDS bindings. Signed-off-by: Biju Das Reviewed-by: Laurent Pinchart Signed-off-by: Laurent Pinchart Reviewed-by: Simon Horman Reviewed-by: Rob Herring --- Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt b/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt index 27a054e1bb5f..900a884ad9f5 100644 --- a/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt +++ b/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt @@ -8,6 +8,7 @@ Required properties: - compatible : Shall contain one of - "renesas,r8a7743-lvds" for R8A7743 (RZ/G1M) compatible LVDS encoders + - "renesas,r8a7744-lvds" for R8A7744 (RZ/G1N) compatible LVDS encoders - "renesas,r8a774c0-lvds" for R8A774C0 (RZ/G2E) compatible LVDS encoders - "renesas,r8a7790-lvds" for R8A7790 (R-Car H2) compatible LVDS encoders - "renesas,r8a7791-lvds" for R8A7791 (R-Car M2-W) compatible LVDS encoders -- cgit From 7bd0a3271e239d34bae5fa51e4f44ed9ee861a59 Mon Sep 17 00:00:00 2001 From: Shayenne Moura Date: Fri, 8 Feb 2019 17:53:12 -0200 Subject: drm/doc: Remove solved KMS cleanup task Remove KMS cleanup task from documentation solved by patchset https://patchwork.freedesktop.org/series/54310/ Signed-off-by: Shayenne Moura Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20190208195312.aqv7acr3hgion5yz@smtp.gmail.com --- Documentation/gpu/todo.rst | 4 ---- 1 file changed, 4 deletions(-) (limited to 'Documentation') diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst index cda4a37a02f0..159a4aba49e6 100644 --- a/Documentation/gpu/todo.rst +++ b/Documentation/gpu/todo.rst @@ -398,10 +398,6 @@ KMS cleanups Some of these date from the very introduction of KMS in 2008 ... -- drm_display_mode doesn't need to be derived from drm_mode_object. That's - leftovers from older (never merged into upstream) KMS designs where modes - where set using their ID, including support to add/remove modes. - - Make ->funcs and ->helper_private vtables optional. There's a bunch of empty function tables in drivers, but before we can remove them we need to make sure that all the users in helpers and drivers do correctly check for a NULL -- cgit