From 16d98b31f807756269106f9a71b1a3dc0d19c629 Mon Sep 17 00:00:00 2001 From: Robert Bragg Date: Wed, 7 Dec 2016 21:40:33 +0000 Subject: drm/i915/perf: More documentation hooked to i915.rst This adds a 'Perf' section to i915.rst with the following sub sections: - Overview - Comparison with Core Perf - i915 Driver Entry Points - i915 Perf Stream - i915 Perf Observation Architecture Stream - All i915 Perf Internals v2: section headers in i915.rst (Daniel Vetter) missing symbol docs + other fixups (Matthew Auld) Signed-off-by: Robert Bragg Reviewed-by: Matthew Auld Cc: Daniel Vetter Signed-off-by: Daniel Vetter Link: http://patchwork.freedesktop.org/patch/msgid/20161207214033.3581-1-robert@sixbynine.org --- Documentation/gpu/i915.rst | 91 ++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 91 insertions(+) (limited to 'Documentation') diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst index 117d2ab7a5f7..3843ef688341 100644 --- a/Documentation/gpu/i915.rst +++ b/Documentation/gpu/i915.rst @@ -356,4 +356,95 @@ switch_mm .. kernel-doc:: drivers/gpu/drm/i915/i915_trace.h :doc: switch_mm tracepoint +Perf +==== + +Overview +-------- +.. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c + :doc: i915 Perf Overview + +Comparison with Core Perf +------------------------- +.. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c + :doc: i915 Perf History and Comparison with Core Perf + +i915 Driver Entry Points +------------------------ + +This section covers the entrypoints exported outside of i915_perf.c to +integrate with drm/i915 and to handle the `DRM_I915_PERF_OPEN` ioctl. + +.. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c + :functions: i915_perf_init +.. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c + :functions: i915_perf_fini +.. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c + :functions: i915_perf_register +.. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c + :functions: i915_perf_unregister +.. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c + :functions: i915_perf_open_ioctl +.. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c + :functions: i915_perf_release + +i915 Perf Stream +---------------- + +This section covers the stream-semantics-agnostic structures and functions +for representing an i915 perf stream FD and associated file operations. + +.. kernel-doc:: drivers/gpu/drm/i915/i915_drv.h + :functions: i915_perf_stream +.. kernel-doc:: drivers/gpu/drm/i915/i915_drv.h + :functions: i915_perf_stream_ops + +.. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c + :functions: read_properties_unlocked +.. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c + :functions: i915_perf_open_ioctl_locked +.. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c + :functions: i915_perf_destroy_locked +.. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c + :functions: i915_perf_read +.. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c + :functions: i915_perf_ioctl +.. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c + :functions: i915_perf_enable_locked +.. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c + :functions: i915_perf_disable_locked +.. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c + :functions: i915_perf_poll +.. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c + :functions: i915_perf_poll_locked + +i915 Perf Observation Architecture Stream +----------------------------------------- + +.. kernel-doc:: drivers/gpu/drm/i915/i915_drv.h + :functions: i915_oa_ops + +.. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c + :functions: i915_oa_stream_init +.. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c + :functions: i915_oa_read +.. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c + :functions: i915_oa_stream_enable +.. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c + :functions: i915_oa_stream_disable +.. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c + :functions: i915_oa_wait_unlocked +.. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c + :functions: i915_oa_poll_wait + +All i915 Perf Internals +----------------------- + +This section simply includes all currently documented i915 perf internals, in +no particular order, but may include some more minor utilities or platform +specific details than found in the more high-level sections. + +.. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c + :internal: + .. WARNING: DOCPROC directive not supported: !Cdrivers/gpu/drm/i915/i915_irq.c -- cgit v1.2.3 From 2904a8c1311f02896635fd35744262413a0b2726 Mon Sep 17 00:00:00 2001 From: Daniel Vetter Date: Fri, 9 Dec 2016 19:53:07 +0100 Subject: dma-buf: Reorganize device dma access docs - Put the initial overview for dma-buf into dma-buf.rst. - Put all the comments about detailed semantics into the right kernel-doc comment for functions or ops structure member. - To allow that detail, switch the reworked kerneldoc to inline style for dma_buf_ops. - Tie everything together into a much more streamlined overview comment, relying on the hyperlinks for all the details. - Also sprinkle some links into the kerneldoc for dma_buf and dma_buf_attachment to tie it all together. Cc: linux-doc@vger.kernel.org Cc: Jonathan Corbet Cc: Sumit Semwal Signed-off-by: Daniel Vetter Signed-off-by: Sumit Semwal Link: http://patchwork.freedesktop.org/patch/msgid/20161209185309.1682-4-daniel.vetter@ffwll.ch --- Documentation/dma-buf-sharing.txt | 222 ----------------------------------- Documentation/driver-api/dma-buf.rst | 38 ++++++ 2 files changed, 38 insertions(+), 222 deletions(-) (limited to 'Documentation') diff --git a/Documentation/dma-buf-sharing.txt b/Documentation/dma-buf-sharing.txt index ca44c5820585..dca2fb7ac3b4 100644 --- a/Documentation/dma-buf-sharing.txt +++ b/Documentation/dma-buf-sharing.txt @@ -5,228 +5,6 @@ -This document serves as a guide to device-driver writers on what is the dma-buf -buffer sharing API, how to use it for exporting and using shared buffers. - -Any device driver which wishes to be a part of DMA buffer sharing, can do so as -either the 'exporter' of buffers, or the 'user' of buffers. - -Say a driver A wants to use buffers created by driver B, then we call B as the -exporter, and A as buffer-user. - -The exporter -- implements and manages operations[1] for the buffer -- allows other users to share the buffer by using dma_buf sharing APIs, -- manages the details of buffer allocation, -- decides about the actual backing storage where this allocation happens, -- takes care of any migration of scatterlist - for all (shared) users of this - buffer, - -The buffer-user -- is one of (many) sharing users of the buffer. -- doesn't need to worry about how the buffer is allocated, or where. -- needs a mechanism to get access to the scatterlist that makes up this buffer - in memory, mapped into its own address space, so it can access the same area - of memory. - -dma-buf operations for device dma only --------------------------------------- - -The dma_buf buffer sharing API usage contains the following steps: - -1. Exporter announces that it wishes to export a buffer -2. Userspace gets the file descriptor associated with the exported buffer, and - passes it around to potential buffer-users based on use case -3. Each buffer-user 'connects' itself to the buffer -4. When needed, buffer-user requests access to the buffer from exporter -5. When finished with its use, the buffer-user notifies end-of-DMA to exporter -6. when buffer-user is done using this buffer completely, it 'disconnects' - itself from the buffer. - - -1. Exporter's announcement of buffer export - - The buffer exporter announces its wish to export a buffer. In this, it - connects its own private buffer data, provides implementation for operations - that can be performed on the exported dma_buf, and flags for the file - associated with this buffer. All these fields are filled in struct - dma_buf_export_info, defined via the DEFINE_DMA_BUF_EXPORT_INFO macro. - - Interface: - DEFINE_DMA_BUF_EXPORT_INFO(exp_info) - struct dma_buf *dma_buf_export(struct dma_buf_export_info *exp_info) - - If this succeeds, dma_buf_export allocates a dma_buf structure, and - returns a pointer to the same. It also associates an anonymous file with this - buffer, so it can be exported. On failure to allocate the dma_buf object, - it returns NULL. - - 'exp_name' in struct dma_buf_export_info is the name of exporter - to - facilitate information while debugging. It is set to KBUILD_MODNAME by - default, so exporters don't have to provide a specific name, if they don't - wish to. - - DEFINE_DMA_BUF_EXPORT_INFO macro defines the struct dma_buf_export_info, - zeroes it out and pre-populates exp_name in it. - - -2. Userspace gets a handle to pass around to potential buffer-users - - Userspace entity requests for a file-descriptor (fd) which is a handle to the - anonymous file associated with the buffer. It can then share the fd with other - drivers and/or processes. - - Interface: - int dma_buf_fd(struct dma_buf *dmabuf, int flags) - - This API installs an fd for the anonymous file associated with this buffer; - returns either 'fd', or error. - -3. Each buffer-user 'connects' itself to the buffer - - Each buffer-user now gets a reference to the buffer, using the fd passed to - it. - - Interface: - struct dma_buf *dma_buf_get(int fd) - - This API will return a reference to the dma_buf, and increment refcount for - it. - - After this, the buffer-user needs to attach its device with the buffer, which - helps the exporter to know of device buffer constraints. - - Interface: - struct dma_buf_attachment *dma_buf_attach(struct dma_buf *dmabuf, - struct device *dev) - - This API returns reference to an attachment structure, which is then used - for scatterlist operations. It will optionally call the 'attach' dma_buf - operation, if provided by the exporter. - - The dma-buf sharing framework does the bookkeeping bits related to managing - the list of all attachments to a buffer. - -Until this stage, the buffer-exporter has the option to choose not to actually -allocate the backing storage for this buffer, but wait for the first buffer-user -to request use of buffer for allocation. - - -4. When needed, buffer-user requests access to the buffer - - Whenever a buffer-user wants to use the buffer for any DMA, it asks for - access to the buffer using dma_buf_map_attachment API. At least one attach to - the buffer must have happened before map_dma_buf can be called. - - Interface: - struct sg_table * dma_buf_map_attachment(struct dma_buf_attachment *, - enum dma_data_direction); - - This is a wrapper to dma_buf->ops->map_dma_buf operation, which hides the - "dma_buf->ops->" indirection from the users of this interface. - - In struct dma_buf_ops, map_dma_buf is defined as - struct sg_table * (*map_dma_buf)(struct dma_buf_attachment *, - enum dma_data_direction); - - It is one of the buffer operations that must be implemented by the exporter. - It should return the sg_table containing scatterlist for this buffer, mapped - into caller's address space. - - If this is being called for the first time, the exporter can now choose to - scan through the list of attachments for this buffer, collate the requirements - of the attached devices, and choose an appropriate backing storage for the - buffer. - - Based on enum dma_data_direction, it might be possible to have multiple users - accessing at the same time (for reading, maybe), or any other kind of sharing - that the exporter might wish to make available to buffer-users. - - map_dma_buf() operation can return -EINTR if it is interrupted by a signal. - - -5. When finished, the buffer-user notifies end-of-DMA to exporter - - Once the DMA for the current buffer-user is over, it signals 'end-of-DMA' to - the exporter using the dma_buf_unmap_attachment API. - - Interface: - void dma_buf_unmap_attachment(struct dma_buf_attachment *, - struct sg_table *); - - This is a wrapper to dma_buf->ops->unmap_dma_buf() operation, which hides the - "dma_buf->ops->" indirection from the users of this interface. - - In struct dma_buf_ops, unmap_dma_buf is defined as - void (*unmap_dma_buf)(struct dma_buf_attachment *, - struct sg_table *, - enum dma_data_direction); - - unmap_dma_buf signifies the end-of-DMA for the attachment provided. Like - map_dma_buf, this API also must be implemented by the exporter. - - -6. when buffer-user is done using this buffer, it 'disconnects' itself from the - buffer. - - After the buffer-user has no more interest in using this buffer, it should - disconnect itself from the buffer: - - - it first detaches itself from the buffer. - - Interface: - void dma_buf_detach(struct dma_buf *dmabuf, - struct dma_buf_attachment *dmabuf_attach); - - This API removes the attachment from the list in dmabuf, and optionally calls - dma_buf->ops->detach(), if provided by exporter, for any housekeeping bits. - - - Then, the buffer-user returns the buffer reference to exporter. - - Interface: - void dma_buf_put(struct dma_buf *dmabuf); - - This API then reduces the refcount for this buffer. - - If, as a result of this call, the refcount becomes 0, the 'release' file - operation related to this fd is called. It calls the dmabuf->ops->release() - operation in turn, and frees the memory allocated for dmabuf when exported. - -NOTES: -- Importance of attach-detach and {map,unmap}_dma_buf operation pairs - The attach-detach calls allow the exporter to figure out backing-storage - constraints for the currently-interested devices. This allows preferential - allocation, and/or migration of pages across different types of storage - available, if possible. - - Bracketing of DMA access with {map,unmap}_dma_buf operations is essential - to allow just-in-time backing of storage, and migration mid-way through a - use-case. - -- Migration of backing storage if needed - If after - - at least one map_dma_buf has happened, - - and the backing storage has been allocated for this buffer, - another new buffer-user intends to attach itself to this buffer, it might - be allowed, if possible for the exporter. - - In case it is allowed by the exporter: - if the new buffer-user has stricter 'backing-storage constraints', and the - exporter can handle these constraints, the exporter can just stall on the - map_dma_buf until all outstanding access is completed (as signalled by - unmap_dma_buf). - Once all users have finished accessing and have unmapped this buffer, the - exporter could potentially move the buffer to the stricter backing-storage, - and then allow further {map,unmap}_dma_buf operations from any buffer-user - from the migrated backing-storage. - - If the exporter cannot fulfill the backing-storage constraints of the new - buffer-user device as requested, dma_buf_attach() would return an error to - denote non-compatibility of the new buffer-sharing request with the current - buffer. - - If the exporter chooses not to allow an attach() operation once a - map_dma_buf() API has been called, it simply returns an error. Kernel cpu access to a dma-buf buffer object -------------------------------------------- diff --git a/Documentation/driver-api/dma-buf.rst b/Documentation/driver-api/dma-buf.rst index a9b457a4b949..906d1532efad 100644 --- a/Documentation/driver-api/dma-buf.rst +++ b/Documentation/driver-api/dma-buf.rst @@ -17,6 +17,44 @@ shared or exclusive fence(s) associated with the buffer. Shared DMA Buffers ------------------ +This document serves as a guide to device-driver writers on what is the dma-buf +buffer sharing API, how to use it for exporting and using shared buffers. + +Any device driver which wishes to be a part of DMA buffer sharing, can do so as +either the 'exporter' of buffers, or the 'user' or 'importer' of buffers. + +Say a driver A wants to use buffers created by driver B, then we call B as the +exporter, and A as buffer-user/importer. + +The exporter + + - implements and manages operations in :c:type:`struct dma_buf_ops + ` for the buffer, + - allows other users to share the buffer by using dma_buf sharing APIs, + - manages the details of buffer allocation, wrapped int a :c:type:`struct + dma_buf `, + - decides about the actual backing storage where this allocation happens, + - and takes care of any migration of scatterlist - for all (shared) users of + this buffer. + +The buffer-user + + - is one of (many) sharing users of the buffer. + - doesn't need to worry about how the buffer is allocated, or where. + - and needs a mechanism to get access to the scatterlist that makes up this + buffer in memory, mapped into its own address space, so it can access the + same area of memory. This interface is provided by :c:type:`struct + dma_buf_attachment `. + +Basic Operation and Device DMA Access +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +.. kernel-doc:: drivers/dma-buf/dma-buf.c + :doc: dma buf device access + +Kernel Functions and Structures Reference +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + .. kernel-doc:: drivers/dma-buf/dma-buf.c :export: -- cgit v1.2.3 From 0959a1683d78270bab6381d498707fb8655ae11c Mon Sep 17 00:00:00 2001 From: Daniel Vetter Date: Fri, 9 Dec 2016 19:53:08 +0100 Subject: dma-buf: Update cpu access documentation - Again move the information relevant for driver writers next to the callbacks. - Put the overview and userspace interface documentation into a DOC: section within the code. - Remove the text that mmap needs to be coherent - since the DMA_BUF_IOCTL_SYNC landed that's no longer the case. But keep the text that for pte zapping exporters need to adjust the address space. - Add a FIXME that kmap and the new begin/end stuff used by the SYNC ioctl don't really mix correctly. That's something I just realized while doing this doc rework. - Augment function and structure docs like usual. Cc: linux-doc@vger.kernel.org Cc: Jonathan Corbet Cc: Sumit Semwal Signed-off-by: Daniel Vetter Signed-off-by: Sumit Semwal [sumits: fix cosmetic issues] Link: http://patchwork.freedesktop.org/patch/msgid/20161209185309.1682-5-daniel.vetter@ffwll.ch --- Documentation/dma-buf-sharing.txt | 213 ----------------------------------- Documentation/driver-api/dma-buf.rst | 6 + 2 files changed, 6 insertions(+), 213 deletions(-) (limited to 'Documentation') diff --git a/Documentation/dma-buf-sharing.txt b/Documentation/dma-buf-sharing.txt index dca2fb7ac3b4..74c99edb7976 100644 --- a/Documentation/dma-buf-sharing.txt +++ b/Documentation/dma-buf-sharing.txt @@ -6,205 +6,6 @@ -Kernel cpu access to a dma-buf buffer object --------------------------------------------- - -The motivation to allow cpu access from the kernel to a dma-buf object from the -importers side are: -- fallback operations, e.g. if the devices is connected to a usb bus and the - kernel needs to shuffle the data around first before sending it away. -- full transparency for existing users on the importer side, i.e. userspace - should not notice the difference between a normal object from that subsystem - and an imported one backed by a dma-buf. This is really important for drm - opengl drivers that expect to still use all the existing upload/download - paths. - -Access to a dma_buf from the kernel context involves three steps: - -1. Prepare access, which invalidate any necessary caches and make the object - available for cpu access. -2. Access the object page-by-page with the dma_buf map apis -3. Finish access, which will flush any necessary cpu caches and free reserved - resources. - -1. Prepare access - - Before an importer can access a dma_buf object with the cpu from the kernel - context, it needs to notify the exporter of the access that is about to - happen. - - Interface: - int dma_buf_begin_cpu_access(struct dma_buf *dmabuf, - enum dma_data_direction direction) - - This allows the exporter to ensure that the memory is actually available for - cpu access - the exporter might need to allocate or swap-in and pin the - backing storage. The exporter also needs to ensure that cpu access is - coherent for the access direction. The direction can be used by the exporter - to optimize the cache flushing, i.e. access with a different direction (read - instead of write) might return stale or even bogus data (e.g. when the - exporter needs to copy the data to temporary storage). - - This step might fail, e.g. in oom conditions. - -2. Accessing the buffer - - To support dma_buf objects residing in highmem cpu access is page-based using - an api similar to kmap. Accessing a dma_buf is done in aligned chunks of - PAGE_SIZE size. Before accessing a chunk it needs to be mapped, which returns - a pointer in kernel virtual address space. Afterwards the chunk needs to be - unmapped again. There is no limit on how often a given chunk can be mapped - and unmapped, i.e. the importer does not need to call begin_cpu_access again - before mapping the same chunk again. - - Interfaces: - void *dma_buf_kmap(struct dma_buf *, unsigned long); - void dma_buf_kunmap(struct dma_buf *, unsigned long, void *); - - There are also atomic variants of these interfaces. Like for kmap they - facilitate non-blocking fast-paths. Neither the importer nor the exporter (in - the callback) is allowed to block when using these. - - Interfaces: - void *dma_buf_kmap_atomic(struct dma_buf *, unsigned long); - void dma_buf_kunmap_atomic(struct dma_buf *, unsigned long, void *); - - For importers all the restrictions of using kmap apply, like the limited - supply of kmap_atomic slots. Hence an importer shall only hold onto at most 2 - atomic dma_buf kmaps at the same time (in any given process context). - - dma_buf kmap calls outside of the range specified in begin_cpu_access are - undefined. If the range is not PAGE_SIZE aligned, kmap needs to succeed on - the partial chunks at the beginning and end but may return stale or bogus - data outside of the range (in these partial chunks). - - Note that these calls need to always succeed. The exporter needs to complete - any preparations that might fail in begin_cpu_access. - - For some cases the overhead of kmap can be too high, a vmap interface - is introduced. This interface should be used very carefully, as vmalloc - space is a limited resources on many architectures. - - Interfaces: - void *dma_buf_vmap(struct dma_buf *dmabuf) - void dma_buf_vunmap(struct dma_buf *dmabuf, void *vaddr) - - The vmap call can fail if there is no vmap support in the exporter, or if it - runs out of vmalloc space. Fallback to kmap should be implemented. Note that - the dma-buf layer keeps a reference count for all vmap access and calls down - into the exporter's vmap function only when no vmapping exists, and only - unmaps it once. Protection against concurrent vmap/vunmap calls is provided - by taking the dma_buf->lock mutex. - -3. Finish access - - When the importer is done accessing the CPU, it needs to announce this to - the exporter (to facilitate cache flushing and unpinning of any pinned - resources). The result of any dma_buf kmap calls after end_cpu_access is - undefined. - - Interface: - void dma_buf_end_cpu_access(struct dma_buf *dma_buf, - enum dma_data_direction dir); - - -Direct Userspace Access/mmap Support ------------------------------------- - -Being able to mmap an export dma-buf buffer object has 2 main use-cases: -- CPU fallback processing in a pipeline and -- supporting existing mmap interfaces in importers. - -1. CPU fallback processing in a pipeline - - In many processing pipelines it is sometimes required that the cpu can access - the data in a dma-buf (e.g. for thumbnail creation, snapshots, ...). To avoid - the need to handle this specially in userspace frameworks for buffer sharing - it's ideal if the dma_buf fd itself can be used to access the backing storage - from userspace using mmap. - - Furthermore Android's ION framework already supports this (and is otherwise - rather similar to dma-buf from a userspace consumer side with using fds as - handles, too). So it's beneficial to support this in a similar fashion on - dma-buf to have a good transition path for existing Android userspace. - - No special interfaces, userspace simply calls mmap on the dma-buf fd, making - sure that the cache synchronization ioctl (DMA_BUF_IOCTL_SYNC) is *always* - used when the access happens. Note that DMA_BUF_IOCTL_SYNC can fail with - -EAGAIN or -EINTR, in which case it must be restarted. - - Some systems might need some sort of cache coherency management e.g. when - CPU and GPU domains are being accessed through dma-buf at the same time. To - circumvent this problem there are begin/end coherency markers, that forward - directly to existing dma-buf device drivers vfunc hooks. Userspace can make - use of those markers through the DMA_BUF_IOCTL_SYNC ioctl. The sequence - would be used like following: - - mmap dma-buf fd - - for each drawing/upload cycle in CPU 1. SYNC_START ioctl, 2. read/write - to mmap area 3. SYNC_END ioctl. This can be repeated as often as you - want (with the new data being consumed by the GPU or say scanout device) - - munmap once you don't need the buffer any more - - For correctness and optimal performance, it is always required to use - SYNC_START and SYNC_END before and after, respectively, when accessing the - mapped address. Userspace cannot rely on coherent access, even when there - are systems where it just works without calling these ioctls. - -2. Supporting existing mmap interfaces in importers - - Similar to the motivation for kernel cpu access it is again important that - the userspace code of a given importing subsystem can use the same interfaces - with a imported dma-buf buffer object as with a native buffer object. This is - especially important for drm where the userspace part of contemporary OpenGL, - X, and other drivers is huge, and reworking them to use a different way to - mmap a buffer rather invasive. - - The assumption in the current dma-buf interfaces is that redirecting the - initial mmap is all that's needed. A survey of some of the existing - subsystems shows that no driver seems to do any nefarious thing like syncing - up with outstanding asynchronous processing on the device or allocating - special resources at fault time. So hopefully this is good enough, since - adding interfaces to intercept pagefaults and allow pte shootdowns would - increase the complexity quite a bit. - - Interface: - int dma_buf_mmap(struct dma_buf *, struct vm_area_struct *, - unsigned long); - - If the importing subsystem simply provides a special-purpose mmap call to set - up a mapping in userspace, calling do_mmap with dma_buf->file will equally - achieve that for a dma-buf object. - -3. Implementation notes for exporters - - Because dma-buf buffers have invariant size over their lifetime, the dma-buf - core checks whether a vma is too large and rejects such mappings. The - exporter hence does not need to duplicate this check. - - Because existing importing subsystems might presume coherent mappings for - userspace, the exporter needs to set up a coherent mapping. If that's not - possible, it needs to fake coherency by manually shooting down ptes when - leaving the cpu domain and flushing caches at fault time. Note that all the - dma_buf files share the same anon inode, hence the exporter needs to replace - the dma_buf file stored in vma->vm_file with it's own if pte shootdown is - required. This is because the kernel uses the underlying inode's address_space - for vma tracking (and hence pte tracking at shootdown time with - unmap_mapping_range). - - If the above shootdown dance turns out to be too expensive in certain - scenarios, we can extend dma-buf with a more explicit cache tracking scheme - for userspace mappings. But the current assumption is that using mmap is - always a slower path, so some inefficiencies should be acceptable. - - Exporters that shoot down mappings (for any reasons) shall not do any - synchronization at fault time with outstanding device operations. - Synchronization is an orthogonal issue to sharing the backing storage of a - buffer and hence should not be handled by dma-buf itself. This is explicitly - mentioned here because many people seem to want something like this, but if - different exporters handle this differently, buffer sharing can fail in - interesting ways depending upong the exporter (if userspace starts depending - upon this implicit synchronization). - Other Interfaces Exposed to Userspace on the dma-buf FD ------------------------------------------------------ @@ -240,20 +41,6 @@ Miscellaneous notes the exporting driver to create a dmabuf fd must provide a way to let userspace control setting of O_CLOEXEC flag passed in to dma_buf_fd(). -- If an exporter needs to manually flush caches and hence needs to fake - coherency for mmap support, it needs to be able to zap all the ptes pointing - at the backing storage. Now linux mm needs a struct address_space associated - with the struct file stored in vma->vm_file to do that with the function - unmap_mapping_range. But the dma_buf framework only backs every dma_buf fd - with the anon_file struct file, i.e. all dma_bufs share the same file. - - Hence exporters need to setup their own file (and address_space) association - by setting vma->vm_file and adjusting vma->vm_pgoff in the dma_buf mmap - callback. In the specific case of a gem driver the exporter could use the - shmem file already provided by gem (and set vm_pgoff = 0). Exporters can then - zap ptes by unmapping the corresponding range of the struct address_space - associated with their own file. - References: [1] struct dma_buf_ops in include/linux/dma-buf.h [2] All interfaces mentioned above defined in include/linux/dma-buf.h diff --git a/Documentation/driver-api/dma-buf.rst b/Documentation/driver-api/dma-buf.rst index 906d1532efad..92e417035e16 100644 --- a/Documentation/driver-api/dma-buf.rst +++ b/Documentation/driver-api/dma-buf.rst @@ -52,6 +52,12 @@ Basic Operation and Device DMA Access .. kernel-doc:: drivers/dma-buf/dma-buf.c :doc: dma buf device access +CPU Access to DMA Buffer Objects +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +.. kernel-doc:: drivers/dma-buf/dma-buf.c + :doc: cpu access + Kernel Functions and Structures Reference ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -- cgit v1.2.3 From e7e21c72b178e963f3c990cb839d86f568999916 Mon Sep 17 00:00:00 2001 From: Daniel Vetter Date: Fri, 9 Dec 2016 22:50:55 +0100 Subject: dma-buf: Final bits of doc polish - Put all the remaing bits of the old doc into suitable places in the new sphinx world. - Also document the poll support, we forgot to do that. - Delete dma-buf-sharing.txt. v2: Don't forget to update MAINTAINERS. Cc: linux-doc@vger.kernel.org Cc: Jonathan Corbet Cc: Sumit Semwal Signed-off-by: Daniel Vetter Signed-off-by: Sumit Semwal Link: http://patchwork.freedesktop.org/patch/msgid/20161209215055.3492-1-daniel.vetter@ffwll.ch --- Documentation/dma-buf-sharing.txt | 47 ----------------------------------- Documentation/driver-api/dma-buf.rst | 48 ++++++++++++++++++++++++++++++++++++ 2 files changed, 48 insertions(+), 47 deletions(-) delete mode 100644 Documentation/dma-buf-sharing.txt (limited to 'Documentation') diff --git a/Documentation/dma-buf-sharing.txt b/Documentation/dma-buf-sharing.txt deleted file mode 100644 index 74c99edb7976..000000000000 --- a/Documentation/dma-buf-sharing.txt +++ /dev/null @@ -1,47 +0,0 @@ - DMA Buffer Sharing API Guide - ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - - Sumit Semwal - - - - -Other Interfaces Exposed to Userspace on the dma-buf FD ------------------------------------------------------- - -- Since kernel 3.12 the dma-buf FD supports the llseek system call, but only - with offset=0 and whence=SEEK_END|SEEK_SET. SEEK_SET is supported to allow - the usual size discover pattern size = SEEK_END(0); SEEK_SET(0). Every other - llseek operation will report -EINVAL. - - If llseek on dma-buf FDs isn't support the kernel will report -ESPIPE for all - cases. Userspace can use this to detect support for discovering the dma-buf - size using llseek. - -Miscellaneous notes -------------------- - -- Any exporters or users of the dma-buf buffer sharing framework must have - a 'select DMA_SHARED_BUFFER' in their respective Kconfigs. - -- In order to avoid fd leaks on exec, the FD_CLOEXEC flag must be set - on the file descriptor. This is not just a resource leak, but a - potential security hole. It could give the newly exec'd application - access to buffers, via the leaked fd, to which it should otherwise - not be permitted access. - - The problem with doing this via a separate fcntl() call, versus doing it - atomically when the fd is created, is that this is inherently racy in a - multi-threaded app[3]. The issue is made worse when it is library code - opening/creating the file descriptor, as the application may not even be - aware of the fd's. - - To avoid this problem, userspace must have a way to request O_CLOEXEC - flag be set when the dma-buf fd is created. So any API provided by - the exporting driver to create a dmabuf fd must provide a way to let - userspace control setting of O_CLOEXEC flag passed in to dma_buf_fd(). - -References: -[1] struct dma_buf_ops in include/linux/dma-buf.h -[2] All interfaces mentioned above defined in include/linux/dma-buf.h -[3] https://lwn.net/Articles/236486/ diff --git a/Documentation/driver-api/dma-buf.rst b/Documentation/driver-api/dma-buf.rst index 92e417035e16..31671b469627 100644 --- a/Documentation/driver-api/dma-buf.rst +++ b/Documentation/driver-api/dma-buf.rst @@ -46,6 +46,48 @@ The buffer-user same area of memory. This interface is provided by :c:type:`struct dma_buf_attachment `. +Any exporters or users of the dma-buf buffer sharing framework must have a +'select DMA_SHARED_BUFFER' in their respective Kconfigs. + +Userspace Interface Notes +~~~~~~~~~~~~~~~~~~~~~~~~~ + +Mostly a DMA buffer file descriptor is simply an opaque object for userspace, +and hence the generic interface exposed is very minimal. There's a few things to +consider though: + +- Since kernel 3.12 the dma-buf FD supports the llseek system call, but only + with offset=0 and whence=SEEK_END|SEEK_SET. SEEK_SET is supported to allow + the usual size discover pattern size = SEEK_END(0); SEEK_SET(0). Every other + llseek operation will report -EINVAL. + + If llseek on dma-buf FDs isn't support the kernel will report -ESPIPE for all + cases. Userspace can use this to detect support for discovering the dma-buf + size using llseek. + +- In order to avoid fd leaks on exec, the FD_CLOEXEC flag must be set + on the file descriptor. This is not just a resource leak, but a + potential security hole. It could give the newly exec'd application + access to buffers, via the leaked fd, to which it should otherwise + not be permitted access. + + The problem with doing this via a separate fcntl() call, versus doing it + atomically when the fd is created, is that this is inherently racy in a + multi-threaded app[3]. The issue is made worse when it is library code + opening/creating the file descriptor, as the application may not even be + aware of the fd's. + + To avoid this problem, userspace must have a way to request O_CLOEXEC + flag be set when the dma-buf fd is created. So any API provided by + the exporting driver to create a dmabuf fd must provide a way to let + userspace control setting of O_CLOEXEC flag passed in to dma_buf_fd(). + +- Memory mapping the contents of the DMA buffer is also supported. See the + discussion below on `CPU Access to DMA Buffer Objects`_ for the full details. + +- The DMA buffer FD is also pollable, see `Fence Poll Support`_ below for + details. + Basic Operation and Device DMA Access ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -58,6 +100,12 @@ CPU Access to DMA Buffer Objects .. kernel-doc:: drivers/dma-buf/dma-buf.c :doc: cpu access +Fence Poll Support +~~~~~~~~~~~~~~~~~~ + +.. kernel-doc:: drivers/dma-buf/dma-buf.c + :doc: fence polling + Kernel Functions and Structures Reference ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -- cgit v1.2.3 From 2e644be30fcc08c736f66b60f4898d274d4873ab Mon Sep 17 00:00:00 2001 From: Bartosz Golaszewski Date: Tue, 13 Dec 2016 11:09:16 +0100 Subject: drm: bridge: add DT bindings for TI ths8135 THS8135 is a configurable video DAC. Add DT bindings for this chip. Signed-off-by: Bartosz Golaszewski Reviewed-by: Laurent Pinchart Acked-by: Rob Herring Signed-off-by: Archit Taneja Link: http://patchwork.freedesktop.org/patch/msgid/1481623759-12786-3-git-send-email-bgolaszewski@baylibre.com --- .../bindings/display/bridge/ti,ths8135.txt | 46 ++++++++++++++++++++++ 1 file changed, 46 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/bridge/ti,ths8135.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/bridge/ti,ths8135.txt b/Documentation/devicetree/bindings/display/bridge/ti,ths8135.txt new file mode 100644 index 000000000000..6ec1a880ac18 --- /dev/null +++ b/Documentation/devicetree/bindings/display/bridge/ti,ths8135.txt @@ -0,0 +1,46 @@ +THS8135 Video DAC +----------------- + +This is the binding for Texas Instruments THS8135 Video DAC bridge. + +Required properties: + +- compatible: Must be "ti,ths8135" + +Required nodes: + +This device has two video ports. Their connections are modelled using the OF +graph bindings specified in Documentation/devicetree/bindings/graph.txt. + +- Video port 0 for RGB input +- Video port 1 for VGA output + +Example +------- + +vga-bridge { + compatible = "ti,ths8135"; + #address-cells = <1>; + #size-cells = <0>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + + vga_bridge_in: endpoint { + remote-endpoint = <&lcdc_out_vga>; + }; + }; + + port@1 { + reg = <1>; + + vga_bridge_out: endpoint { + remote-endpoint = <&vga_con_in>; + }; + }; + }; +}; -- cgit v1.2.3 From 9118c0b7a6d451004753bf529bfa505e3207f9bc Mon Sep 17 00:00:00 2001 From: Peter Meerwald-Stadler Date: Fri, 16 Dec 2016 14:25:01 +0100 Subject: drm/hisilicon: Fix spelling of clock in hisi-ade.txt Signed-off-by: Peter Meerwald-Stadler Cc: Xinliang Liu Cc: Xinwei Kong Cc: trivial@kernel.org Signed-off-by: Daniel Vetter Link: http://patchwork.freedesktop.org/patch/msgid/1481894701-4613-1-git-send-email-pmeerw@pmeerw.net --- Documentation/devicetree/bindings/display/hisilicon/hisi-ade.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/hisilicon/hisi-ade.txt b/Documentation/devicetree/bindings/display/hisilicon/hisi-ade.txt index 38dc9d60eef8..305a0e72a900 100644 --- a/Documentation/devicetree/bindings/display/hisilicon/hisi-ade.txt +++ b/Documentation/devicetree/bindings/display/hisilicon/hisi-ade.txt @@ -16,7 +16,7 @@ Required properties: "clk_ade_core" for the ADE core clock. "clk_codec_jpeg" for the media NOC QoS clock, which use the same clock with jpeg codec. - "clk_ade_pix" for the ADE pixel clok. + "clk_ade_pix" for the ADE pixel clock. - assigned-clocks: Should contain "clk_ade_core" and "clk_codec_jpeg" clocks' phandle + clock-specifier pairs. - assigned-clock-rates: clock rates, one for each entry in assigned-clocks. -- cgit v1.2.3 From ae774e2c68d19da7a8e982889a5a1684cac93c78 Mon Sep 17 00:00:00 2001 From: Daniel Vetter Date: Thu, 29 Dec 2016 11:44:35 +0100 Subject: drm/doc: link style-guide to doc-guide Our style guide should only be the delta compared to the overall one. Cc: Chris Wilson Reviewed-by: Chris Wilson Signed-off-by: Daniel Vetter Link: http://patchwork.freedesktop.org/patch/msgid/1483008275-29383-1-git-send-email-daniel.vetter@ffwll.ch --- Documentation/gpu/introduction.rst | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/gpu/introduction.rst b/Documentation/gpu/introduction.rst index 1903595b5310..6960e31f71e1 100644 --- a/Documentation/gpu/introduction.rst +++ b/Documentation/gpu/introduction.rst @@ -49,3 +49,5 @@ section name should be all upper-case or not, and whether it should end in a colon or not. Go with the file-local style. Other common section names are "Notes" with information for dangerous or tricky corner cases, and "FIXME" where the interface could be cleaned up. + +Also read the :ref:`guidelines for the kernel documentation at large `. -- cgit v1.2.3 From 294591cfbd2b185ac51fa2b1768a333fa6782011 Mon Sep 17 00:00:00 2001 From: Ander Conselvan de Oliveira Date: Thu, 29 Dec 2016 17:22:11 +0200 Subject: drm/i915: Update kerneldoc for intel_dpll_mgr.c The documentation for most of the non-static members and structs were missing. Fix that. v2: Fix typos (Durga) v3: Rebase. Fix make docs warnings. Document more. v4: capitilize CRTC; say that the prepare hook is a nop if the DPLL is already enabled; link to struct intel_dpll_hw_state from @hw_state field in struct intel_shared_dpll_state; reorganize DPLL flags; link intel_shared_dpll_state to other structs and functions. (Daniel) Signed-off-by: Ander Conselvan de Oliveira Reviewed-by: Daniel Vetter Link: http://patchwork.freedesktop.org/patch/msgid/1483024933-3726-6-git-send-email-ander.conselvan.de.oliveira@intel.com --- Documentation/gpu/i915.rst | 12 ++++++++++++ 1 file changed, 12 insertions(+) (limited to 'Documentation') diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst index 3843ef688341..104296dffad1 100644 --- a/Documentation/gpu/i915.rst +++ b/Documentation/gpu/i915.rst @@ -213,6 +213,18 @@ Video BIOS Table (VBT) .. kernel-doc:: drivers/gpu/drm/i915/intel_vbt_defs.h :internal: +Display PLLs +------------ + +.. kernel-doc:: drivers/gpu/drm/i915/intel_dpll_mgr.c + :doc: Display PLLs + +.. kernel-doc:: drivers/gpu/drm/i915/intel_dpll_mgr.c + :internal: + +.. kernel-doc:: drivers/gpu/drm/i915/intel_dpll_mgr.h + :internal: + Memory Management and Command Submission ======================================== -- cgit v1.2.3 From b834ff86a61c236282e68890c17316f6928eebad Mon Sep 17 00:00:00 2001 From: Gabriel Krisman Bertazi Date: Fri, 30 Dec 2016 12:50:49 +0100 Subject: drm: Update TTM initialization documentation ttm_global_reference was renamed to drm_global_reference. This updates the documentation to reflect that. While we are there, document the drm_global_reference API and update the initialization interface documentation. Signed-off-by: Gabriel Krisman Bertazi [danvet: Keep the warning, ttm docs are still massively inadequate.] Signed-off-by: Daniel Vetter Link: http://patchwork.freedesktop.org/patch/msgid/20161228143216.26821-7-krisman@collabora.co.uk --- Documentation/gpu/drm-mm.rst | 27 +++++++++++++++++---------- 1 file changed, 17 insertions(+), 10 deletions(-) (limited to 'Documentation') diff --git a/Documentation/gpu/drm-mm.rst b/Documentation/gpu/drm-mm.rst index cb5daffcd6be..0285b68f6201 100644 --- a/Documentation/gpu/drm-mm.rst +++ b/Documentation/gpu/drm-mm.rst @@ -34,25 +34,26 @@ TTM initialization ------------------ **Warning** - This section is outdated. -Drivers wishing to support TTM must fill out a drm_bo_driver -structure. The structure contains several fields with function pointers -for initializing the TTM, allocating and freeing memory, waiting for -command completion and fence synchronization, and memory migration. See -the radeon_ttm.c file for an example of usage. +Drivers wishing to support TTM must pass a filled :c:type:`ttm_bo_driver +` structure to ttm_bo_device_init, together with an +initialized global reference to the memory manager. The ttm_bo_driver +structure contains several fields with function pointers for +initializing the TTM, allocating and freeing memory, waiting for command +completion and fence synchronization, and memory migration. -The ttm_global_reference structure is made up of several fields: +The :c:type:`struct drm_global_reference ` is made +up of several fields: .. code-block:: c - struct ttm_global_reference { + struct drm_global_reference { enum ttm_global_types global_type; size_t size; void *object; - int (*init) (struct ttm_global_reference *); - void (*release) (struct ttm_global_reference *); + int (*init) (struct drm_global_reference *); + void (*release) (struct drm_global_reference *); }; @@ -76,6 +77,12 @@ ttm_bo_global_release(), respectively. Also, like the previous object, ttm_global_item_ref() is used to create an initial reference count for the TTM, which will call your initialization function. +See the radeon_ttm.c file for an example of usage. + +.. kernel-doc:: drivers/gpu/drm/drm_global.c + :export: + + The Graphics Execution Manager (GEM) ==================================== -- cgit v1.2.3 From a8182863438232dce79f76cc511d752a219ff33a Mon Sep 17 00:00:00 2001 From: Daniel Vetter Date: Thu, 29 Dec 2016 21:48:21 +0100 Subject: drm/docs: Small cleanup in drm-uapi.rst - Remove the outdated hunk about driver documentation which somehow got misplaced here in the split-up. - Collect all the testing&validation stuff together and give the CRC section a heading for prettier output. Cc: Tomeu Vizoso Cc: Jani Nikula Reviewed-by: David Herrmann Signed-off-by: Daniel Vetter Link: http://patchwork.freedesktop.org/patch/msgid/1483044517-5770-1-git-send-email-daniel.vetter@ffwll.ch --- Documentation/gpu/drm-uapi.rst | 25 +++++++++++-------------- 1 file changed, 11 insertions(+), 14 deletions(-) (limited to 'Documentation') diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst index de3ac9f90f8f..fcc228ef5bc4 100644 --- a/Documentation/gpu/drm-uapi.rst +++ b/Documentation/gpu/drm-uapi.rst @@ -156,8 +156,12 @@ other hand, a driver requires shared state between clients which is visible to user-space and accessible beyond open-file boundaries, they cannot support render nodes. + +Testing and validation +====================== + Validating changes with IGT -=========================== +--------------------------- There's a collection of tests that aims to cover the whole functionality of DRM drivers and that can be used to check that changes to DRM drivers or the @@ -193,6 +197,12 @@ run-tests.sh is a wrapper around piglit that will execute the tests matching the -t options. A report in HTML format will be available in ./results/html/index.html. Results can be compared with piglit. +Display CRC Support +------------------- + +.. kernel-doc:: drivers/gpu/drm/drm_debugfs_crc.c + :doc: CRC ABI + VBlank event handling ===================== @@ -209,16 +219,3 @@ DRM_IOCTL_MODESET_CTL mode setting, since on many devices the vertical blank counter is reset to 0 at some point during modeset. Modern drivers should not call this any more since with kernel mode setting it is a no-op. - -This second part of the GPU Driver Developer's Guide documents driver -code, implementation details and also all the driver-specific userspace -interfaces. Especially since all hardware-acceleration interfaces to -userspace are driver specific for efficiency and other reasons these -interfaces can be rather substantial. Hence every driver has its own -chapter. - -Testing and validation -====================== - -.. kernel-doc:: drivers/gpu/drm/drm_debugfs_crc.c - :doc: CRC ABI -- cgit v1.2.3 From 05fc03217e08b90bff1ff22792d5f86dd32f15a6 Mon Sep 17 00:00:00 2001 From: Daniel Vetter Date: Thu, 29 Dec 2016 21:48:23 +0100 Subject: drm/mm: Some doc polish Added some boilerplate for the structs, documented members where they are relevant and plenty of markup for hyperlinks all over. And a few small wording polish. Note that the intro needs some more love after the DRM_MM_INSERT_* patch from Chris has landed. v2: Spelling fixes (Chris). v3: Use &struct foo instead of &foo structure (Chris). Cc: Chris Wilson Cc: Joonas Lahtinen Reviewed-by: David Herrmann Signed-off-by: Daniel Vetter Link: http://patchwork.freedesktop.org/patch/msgid/1483044517-5770-3-git-send-email-daniel.vetter@ffwll.ch --- Documentation/gpu/drm-mm.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/gpu/drm-mm.rst b/Documentation/gpu/drm-mm.rst index 0285b68f6201..d3c6d77246cd 100644 --- a/Documentation/gpu/drm-mm.rst +++ b/Documentation/gpu/drm-mm.rst @@ -449,7 +449,7 @@ LRU Scan/Eviction Support ------------------------- .. kernel-doc:: drivers/gpu/drm/drm_mm.c - :doc: lru scan roaster + :doc: lru scan roster DRM MM Range Allocator Function References ------------------------------------------ -- cgit v1.2.3 From f5a8d8774bbb81c64073c1e29ce29cfa3d044f83 Mon Sep 17 00:00:00 2001 From: Daniel Vetter Date: Thu, 29 Dec 2016 21:48:28 +0100 Subject: drm/doc: Update styleguide The new cool is &struct foo (kernel-doc now copes with linebreaks), and structure members should be referenced using &foo.bar. Cc: Jani Nikula Cc: Chris Wilson Reviewed-by: David Herrmann Signed-off-by: Daniel Vetter Link: http://patchwork.freedesktop.org/patch/msgid/1483044517-5770-8-git-send-email-daniel.vetter@ffwll.ch --- Documentation/gpu/introduction.rst | 13 ++++++------- 1 file changed, 6 insertions(+), 7 deletions(-) (limited to 'Documentation') diff --git a/Documentation/gpu/introduction.rst b/Documentation/gpu/introduction.rst index 6960e31f71e1..eb284eb748ba 100644 --- a/Documentation/gpu/introduction.rst +++ b/Documentation/gpu/introduction.rst @@ -23,13 +23,12 @@ For consistency this documentation uses American English. Abbreviations are written as all-uppercase, for example: DRM, KMS, IOCTL, CRTC, and so on. To aid in reading, documentations make full use of the markup characters kerneldoc provides: @parameter for function parameters, -@member for structure members, &structure to reference structures and -function() for functions. These all get automatically hyperlinked if -kerneldoc for the referenced objects exists. When referencing entries in -function vtables please use ->vfunc(). Note that kerneldoc does not -support referencing struct members directly, so please add a reference -to the vtable struct somewhere in the same paragraph or at least -section. +@member for structure members (within the same structure), &struct structure to +reference structures and function() for functions. These all get automatically +hyperlinked if kerneldoc for the referenced objects exists. When referencing +entries in function vtables (and structure members in general) please use +&vtable_name.vfunc. Unfortunately this does not yet yield a direct link to the +member, only the structure. Except in special situations (to separate locked from unlocked variants) locking requirements for functions aren't documented in the kerneldoc. -- cgit v1.2.3 From 62a0d98a188cc4ebd8ea54b37d274ec20465e464 Mon Sep 17 00:00:00 2001 From: Benjamin Gaignard Date: Wed, 4 Jan 2017 10:12:57 +0100 Subject: drm: allow to use mmuless SoC Some SoC without MMU have display driver where a drm/kms driver could be implemented. Before doing such kind of thing drm/kms must allow to use mmuless devices. This patch propose to remove MMU configuration flag and add a cma helper function to help implementing mmuless display driver version 4: - add documentation about drm_gem_cma_get_unmapped_area() - stub it MMU case Signed-off-by: Benjamin Gaignard [danvet: Use recommended struct member references in kernel-doc.] Signed-off-by: Daniel Vetter Link: http://patchwork.freedesktop.org/patch/msgid/1483521177-21794-4-git-send-email-benjamin.gaignard@linaro.org --- Documentation/gpu/drm-mm.rst | 11 +++++++++++ 1 file changed, 11 insertions(+) (limited to 'Documentation') diff --git a/Documentation/gpu/drm-mm.rst b/Documentation/gpu/drm-mm.rst index d3c6d77246cd..1ea94fc86caa 100644 --- a/Documentation/gpu/drm-mm.rst +++ b/Documentation/gpu/drm-mm.rst @@ -310,6 +310,17 @@ created. Drivers that want to map the GEM object upfront instead of handling page faults can implement their own mmap file operation handler. +For platforms without MMU the GEM core provides a helper method +:c:func:`drm_gem_cma_get_unmapped_area`. The mmap() routines will call +this to get a proposed address for the mapping. + +To use :c:func:`drm_gem_cma_get_unmapped_area`, drivers must fill the +struct :c:type:`struct file_operations ` get_unmapped_area +field with a pointer on :c:func:`drm_gem_cma_get_unmapped_area`. + +More detailed information about get_unmapped_area can be found in +Documentation/nommu-mmap.txt + Memory Coherency ---------------- -- cgit v1.2.3 From f0e36723a68dfd959168c73bfa7ca6fa426eadf5 Mon Sep 17 00:00:00 2001 From: Gabriel Krisman Bertazi Date: Mon, 9 Jan 2017 19:56:48 -0200 Subject: drm: Document drm_cache interface Notice that this uncovers an issue with the kernel-doc handling of array arguments, causing the first parameter of drm_clflush_pages() to not show up in the rst-generated page. A proposed fix is under review in linux-doc: Changes since v1: - Add section to drm-mm.rst. - Fix kernel-doc style issues. - s/memory/kernel memory/. Signed-off-by: Gabriel Krisman Bertazi Reviewed-by: Alex Deucher Signed-off-by: Daniel Vetter Link: http://patchwork.freedesktop.org/patch/msgid/20170109215649.6860-1-krisman@collabora.co.uk --- Documentation/gpu/drm-mm.rst | 6 ++++++ 1 file changed, 6 insertions(+) (limited to 'Documentation') diff --git a/Documentation/gpu/drm-mm.rst b/Documentation/gpu/drm-mm.rst index 1ea94fc86caa..91d82f39fbf4 100644 --- a/Documentation/gpu/drm-mm.rst +++ b/Documentation/gpu/drm-mm.rst @@ -470,3 +470,9 @@ DRM MM Range Allocator Function References .. kernel-doc:: include/drm/drm_mm.h :internal: + +DRM Cache Handling +================== + +.. kernel-doc:: drivers/gpu/drm/drm_cache.c + :export: -- cgit v1.2.3 From dd48e8ed3bfdee879ce60508230bed7fb2ca5fa8 Mon Sep 17 00:00:00 2001 From: Libin Yang Date: Thu, 12 Jan 2017 16:04:54 +0800 Subject: ALSA: Documentation about HDA DP MST pin init and connection Add the documentation about HD-audio DP MST: 1. pin initialization 2. device entry connection list Reviewed-by: Takashi Iwai Signed-off-by: Libin Yang Signed-off-by: Daniel Vetter Link: http://patchwork.freedesktop.org/patch/msgid/1484208294-8637-4-git-send-email-libin.yang@intel.com --- Documentation/sound/hd-audio/dp-mst.rst | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) (limited to 'Documentation') diff --git a/Documentation/sound/hd-audio/dp-mst.rst b/Documentation/sound/hd-audio/dp-mst.rst index 58b72437e6c3..1617459e332f 100644 --- a/Documentation/sound/hd-audio/dp-mst.rst +++ b/Documentation/sound/hd-audio/dp-mst.rst @@ -19,6 +19,23 @@ PCM === To be added +Pin Initialization +================== +Each pin may have several device entries (virtual pins). On Intel platform, +the device entries number is dynamically changed. If DP MST hub is connected, +it is in DP MST mode, and the device entries number is 3. Otherwise, the +device entries number is 1. + +To simplify the implementation, all the device entries will be initialized +when bootup no matter whether it is in DP MST mode or not. + +Connection list +=============== +DP MST reuses connection list code. The code can be reused because +device entries on the same pin have the same connection list. + +This means DP MST gets the device entry connection list without the +device entry setting. Jack ==== -- cgit v1.2.3 From e9a7c0beb2361a44dbdb852f3cff99e08ddbe029 Mon Sep 17 00:00:00 2001 From: Archit Taneja Date: Wed, 11 Jan 2017 12:22:26 +0530 Subject: dt-bindings: drm/bridge: adv7511: Add regulator bindings Add the regulator supply properties needed by ADV7511 and ADV7533. Acked-by: Laurent Pinchart Acked-by: Rob Herring Signed-off-by: Archit Taneja Link: http://patchwork.freedesktop.org/patch/msgid/1484117547-26417-2-git-send-email-architt@codeaurora.org --- .../devicetree/bindings/display/bridge/adi,adv7511.txt | 12 ++++++++++++ 1 file changed, 12 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt index 6532a59c9b43..00ea670b8c4d 100644 --- a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt +++ b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt @@ -38,10 +38,22 @@ The following input format properties are required except in "rgb 1x" and - adi,input-justification: The input bit justification ("left", "evenly", "right"). +- avdd-supply: A 1.8V supply that powers up the AVDD pin on the chip. +- dvdd-supply: A 1.8V supply that powers up the DVDD pin on the chip. +- pvdd-supply: A 1.8V supply that powers up the PVDD pin on the chip. +- dvdd-3v-supply: A 3.3V supply that powers up the pin called DVDD_3V + on the chip. +- bgvdd-supply: A 1.8V supply that powers up the BGVDD pin. This is + needed only for ADV7511. + The following properties are required for ADV7533: - adi,dsi-lanes: Number of DSI data lanes connected to the DSI host. It should be one of 1, 2, 3 or 4. +- a2vdd-supply: 1.8V supply that powers up the A2VDD pin on the chip. +- v3p3-supply: A 3.3V supply that powers up the V3P3 pin on the chip. +- v1p2-supply: A supply that powers up the V1P2 pin on the chip. It can be + either 1.2V or 1.8V. Optional properties: -- cgit v1.2.3 From 01f8c951c25f9a87f2e9dbc09ceca274e80fff4e Mon Sep 17 00:00:00 2001 From: Laurent Pinchart Date: Tue, 17 Jan 2017 10:29:10 +0200 Subject: dt-bindings: display: dw-hdmi: Clean up DT bindings documentation Make it clear that the core bridge/dw_hdmi.txt document isn't a device tree binding by itself but is meant to be referenced by platform device tree bindings, and update the Rockchip and Freescale DWC HDMI TX bindings to reference it. Signed-off-by: Laurent Pinchart Acked-by: Rob Herring Signed-off-by: Archit Taneja Link: http://patchwork.freedesktop.org/patch/msgid/20170117082910.27023-21-laurent.pinchart+renesas@ideasonboard.com --- .../devicetree/bindings/display/bridge/dw_hdmi.txt | 85 +++++++++------------- .../devicetree/bindings/display/imx/hdmi.txt | 51 +++++++------ .../bindings/display/rockchip/dw_hdmi-rockchip.txt | 43 +++++++---- 3 files changed, 91 insertions(+), 88 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/bridge/dw_hdmi.txt b/Documentation/devicetree/bindings/display/bridge/dw_hdmi.txt index 5e9a84d6e5f1..33bf981fbe33 100644 --- a/Documentation/devicetree/bindings/display/bridge/dw_hdmi.txt +++ b/Documentation/devicetree/bindings/display/bridge/dw_hdmi.txt @@ -1,52 +1,33 @@ -DesignWare HDMI bridge bindings - -Required properties: -- compatible: platform specific such as: - * "snps,dw-hdmi-tx" - * "fsl,imx6q-hdmi" - * "fsl,imx6dl-hdmi" - * "rockchip,rk3288-dw-hdmi" -- reg: Physical base address and length of the controller's registers. -- interrupts: The HDMI interrupt number -- clocks, clock-names : must have the phandles to the HDMI iahb and isfr clocks, - as described in Documentation/devicetree/bindings/clock/clock-bindings.txt, - the clocks are soc specific, the clock-names should be "iahb", "isfr" --port@[X]: SoC specific port nodes with endpoint definitions as defined - in Documentation/devicetree/bindings/media/video-interfaces.txt, - please refer to the SoC specific binding document: - * Documentation/devicetree/bindings/display/imx/hdmi.txt - * Documentation/devicetree/bindings/display/rockchip/dw_hdmi-rockchip.txt - -Optional properties -- reg-io-width: the width of the reg:1,4, default set to 1 if not present -- ddc-i2c-bus: phandle of an I2C controller used for DDC EDID probing, - if the property is omitted, a functionally reduced I2C bus - controller on DW HDMI is probed -- clocks, clock-names: phandle to the HDMI CEC clock, name should be "cec" - -Example: - hdmi: hdmi@0120000 { - compatible = "fsl,imx6q-hdmi"; - reg = <0x00120000 0x9000>; - interrupts = <0 115 0x04>; - gpr = <&gpr>; - clocks = <&clks 123>, <&clks 124>; - clock-names = "iahb", "isfr"; - ddc-i2c-bus = <&i2c2>; - - port@0 { - reg = <0>; - - hdmi_mux_0: endpoint { - remote-endpoint = <&ipu1_di0_hdmi>; - }; - }; - - port@1 { - reg = <1>; - - hdmi_mux_1: endpoint { - remote-endpoint = <&ipu1_di1_hdmi>; - }; - }; - }; +Synopsys DesignWare HDMI TX Encoder +=================================== + +This document defines device tree properties for the Synopsys DesignWare HDMI +TX Encoder (DWC HDMI TX). It doesn't constitue a device tree binding +specification by itself but is meant to be referenced by platform-specific +device tree bindings. + +When referenced from platform device tree bindings the properties defined in +this document are defined as follows. The platform device tree bindings are +responsible for defining whether each property is required or optional. + +- reg: Memory mapped base address and length of the DWC HDMI TX registers. + +- reg-io-width: Width of the registers specified by the reg property. The + value is expressed in bytes and must be equal to 1 or 4 if specified. The + register width defaults to 1 if the property is not present. + +- interrupts: Reference to the DWC HDMI TX interrupt. + +- clocks: References to all the clocks specified in the clock-names property + as specified in Documentation/devicetree/bindings/clock/clock-bindings.txt. + +- clock-names: The DWC HDMI TX uses the following clocks. + + - "iahb" is the bus clock for either AHB and APB (mandatory). + - "isfr" is the internal register configuration clock (mandatory). + - "cec" is the HDMI CEC controller main clock (optional). + +- ports: The connectivity of the DWC HDMI TX with the rest of the system is + expressed in using ports as specified in the device graph bindings defined + in Documentation/devicetree/bindings/graph.txt. The numbering of the ports + is platform-specific. diff --git a/Documentation/devicetree/bindings/display/imx/hdmi.txt b/Documentation/devicetree/bindings/display/imx/hdmi.txt index 1b756cf9afb0..66a8f86e5d12 100644 --- a/Documentation/devicetree/bindings/display/imx/hdmi.txt +++ b/Documentation/devicetree/bindings/display/imx/hdmi.txt @@ -1,29 +1,36 @@ -Device-Tree bindings for HDMI Transmitter +Freescale i.MX6 DWC HDMI TX Encoder +=================================== -HDMI Transmitter -================ +The HDMI transmitter is a Synopsys DesignWare HDMI 1.4 TX controller IP +with a companion PHY IP. + +These DT bindings follow the Synopsys DWC HDMI TX bindings defined in +Documentation/devicetree/bindings/display/bridge/dw_hdmi.txt with the +following device-specific properties. -The HDMI Transmitter is a Synopsys DesignWare HDMI 1.4 TX controller IP -with accompanying PHY IP. Required properties: - - #address-cells : should be <1> - - #size-cells : should be <0> - - compatible : should be "fsl,imx6q-hdmi" or "fsl,imx6dl-hdmi". - - gpr : should be <&gpr>. - The phandle points to the iomuxc-gpr region containing the HDMI - multiplexer control register. - - clocks, clock-names : phandles to the HDMI iahb and isrf clocks, as described - in Documentation/devicetree/bindings/clock/clock-bindings.txt and - Documentation/devicetree/bindings/clock/imx6q-clock.txt. - - port@[0-4]: Up to four port nodes with endpoint definitions as defined in - Documentation/devicetree/bindings/media/video-interfaces.txt, - corresponding to the four inputs to the HDMI multiplexer. - -Optional properties: - - ddc-i2c-bus: phandle of an I2C controller used for DDC EDID probing - -example: + +- compatible : Shall be one of "fsl,imx6q-hdmi" or "fsl,imx6dl-hdmi". +- reg: See dw_hdmi.txt. +- interrupts: HDMI interrupt number +- clocks: See dw_hdmi.txt. +- clock-names: Shall contain "iahb" and "isfr" as defined in dw_hdmi.txt. +- ports: See dw_hdmi.txt. The DWC HDMI shall have between one and four ports, + numbered 0 to 3, corresponding to the four inputs of the HDMI multiplexer. + Each port shall have a single endpoint. +- gpr : Shall contain a phandle to the iomuxc-gpr region containing the HDMI + multiplexer control register. + +Optional properties + +- ddc-i2c-bus: The HDMI DDC bus can be connected to either a system I2C master + or the functionally-reduced I2C master contained in the DWC HDMI. When + connected to a system I2C master this property contains a phandle to that + I2C master controller. + + +Example: gpr: iomuxc-gpr@020e0000 { /* ... */ diff --git a/Documentation/devicetree/bindings/display/rockchip/dw_hdmi-rockchip.txt b/Documentation/devicetree/bindings/display/rockchip/dw_hdmi-rockchip.txt index 668091f27674..046076c6b277 100644 --- a/Documentation/devicetree/bindings/display/rockchip/dw_hdmi-rockchip.txt +++ b/Documentation/devicetree/bindings/display/rockchip/dw_hdmi-rockchip.txt @@ -1,24 +1,39 @@ -Rockchip specific extensions to the Synopsys Designware HDMI -================================ +Rockchip DWC HDMI TX Encoder +============================ + +The HDMI transmitter is a Synopsys DesignWare HDMI 1.4 TX controller IP +with a companion PHY IP. + +These DT bindings follow the Synopsys DWC HDMI TX bindings defined in +Documentation/devicetree/bindings/display/bridge/dw_hdmi.txt with the +following device-specific properties. + Required properties: -- compatible: "rockchip,rk3288-dw-hdmi"; -- reg: Physical base address and length of the controller's registers. -- clocks: phandle to hdmi iahb and isfr clocks. -- clock-names: should be "iahb" "isfr" -- rockchip,grf: this soc should set GRF regs to mux vopl/vopb. + +- compatible: Shall contain "rockchip,rk3288-dw-hdmi". +- reg: See dw_hdmi.txt. +- reg-io-width: See dw_hdmi.txt. Shall be 4. - interrupts: HDMI interrupt number -- ports: contain a port node with endpoint definitions as defined in - Documentation/devicetree/bindings/media/video-interfaces.txt. For - vopb,set the reg = <0> and set the reg = <1> for vopl. -- reg-io-width: the width of the reg:1,4, the value should be 4 on - rk3288 platform +- clocks: See dw_hdmi.txt. +- clock-names: Shall contain "iahb" and "isfr" as defined in dw_hdmi.txt. +- ports: See dw_hdmi.txt. The DWC HDMI shall have a single port numbered 0 + corresponding to the video input of the controller. The port shall have two + endpoints, numbered 0 and 1, connected respectively to the vopb and vopl. +- rockchip,grf: Shall reference the GRF to mux vopl/vopb. Optional properties -- ddc-i2c-bus: phandle of an I2C controller used for DDC EDID probing -- clocks, clock-names: phandle to the HDMI CEC clock, name should be "cec" + +- ddc-i2c-bus: The HDMI DDC bus can be connected to either a system I2C master + or the functionally-reduced I2C master contained in the DWC HDMI. When + connected to a system I2C master this property contains a phandle to that + I2C master controller. +- clock-names: See dw_hdmi.txt. The "cec" clock is optional. +- clock-names: May contain "cec" as defined in dw_hdmi.txt. + Example: + hdmi: hdmi@ff980000 { compatible = "rockchip,rk3288-dw-hdmi"; reg = <0xff980000 0x20000>; -- cgit v1.2.3 From d5d487eb07c3e4652cde70651373d6a85173f685 Mon Sep 17 00:00:00 2001 From: Daniel Vetter Date: Wed, 25 Jan 2017 07:26:57 +0100 Subject: drm: Update kerneldoc for drm_crtc.[hc] After going through all the trouble of splitting out parts from drm_crtc.[hc] and then properly documenting each I've entirely forgotten to show the same TLC for CRTCs themselves! Let's make amends asap. v2: Review from Eric. Reviewed-by: Eric Engestrom Signed-off-by: Daniel Vetter --- Documentation/gpu/drm-kms.rst | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst index 0c9abdc0ee31..4d4068855ec4 100644 --- a/Documentation/gpu/drm-kms.rst +++ b/Documentation/gpu/drm-kms.rst @@ -48,11 +48,17 @@ CRTC Abstraction ================ .. kernel-doc:: drivers/gpu/drm/drm_crtc.c - :export: + :doc: overview + +CRTC Functions Reference +-------------------------------- .. kernel-doc:: include/drm/drm_crtc.h :internal: +.. kernel-doc:: drivers/gpu/drm/drm_crtc.c + :export: + Frame Buffer Abstraction ======================== -- cgit v1.2.3 From 095790b750686190410e83d1bb4bf496e99f56cf Mon Sep 17 00:00:00 2001 From: Caesar Wang Date: Wed, 14 Dec 2016 11:19:55 +0800 Subject: dt-bindings: display: Add BOE NV101WXMN51 panel binding The BOE 10.1" NV101WXMN51 panel is an WXGA TFT LCD panel. Signed-off-by: Caesar Wang Acked-by: Rob Herring Signed-off-by: Thierry Reding --- .../devicetree/bindings/display/panel/boe,nv101wxmn51.txt | 7 +++++++ 1 file changed, 7 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/panel/boe,nv101wxmn51.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/panel/boe,nv101wxmn51.txt b/Documentation/devicetree/bindings/display/panel/boe,nv101wxmn51.txt new file mode 100644 index 000000000000..b258d6a91ec6 --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/boe,nv101wxmn51.txt @@ -0,0 +1,7 @@ +BOE OPTOELECTRONICS TECHNOLOGY 10.1" WXGA TFT LCD panel + +Required properties: +- compatible: should be "boe,nv101wxmn51" + +This binding is compatible with the simple-panel binding, which is specified +in simple-panel.txt in this directory. -- cgit v1.2.3 From c81cbc2e33accb0c99c9411b338b124b7dae4a7a Mon Sep 17 00:00:00 2001 From: Gary Bisson Date: Fri, 2 Dec 2016 09:52:07 +0100 Subject: of: Add vendor prefix for Tianma Micro-electronics Tianma Micro-electronics Co., Ltd. (Tianma) specializes in providing display solutions and efficient support services worldwide. More info: http://en.tianma.com/about.shtml Signed-off-by: Gary Bisson Acked-by: Rob Herring Signed-off-by: Thierry Reding --- 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 16d3b5e7f5d1..62233d1e1d6e 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -296,6 +296,7 @@ technologic Technologic Systems terasic Terasic Inc. thine THine Electronics, Inc. ti Texas Instruments +tianma Tianma Micro-electronics Co., Ltd. tlm Trusted Logic Mobility topeet Topeet toradex Toradex AG -- cgit v1.2.3 From adb973ef53a711524d44cf92b6e039e91c82d987 Mon Sep 17 00:00:00 2001 From: Gary Bisson Date: Fri, 2 Dec 2016 09:52:08 +0100 Subject: drm/panel: simple: Add support for Tianma TM070JDHG30 The Tianma TM070JDHG30 is a 7" LVDS display with a resolution of 1280x800. http://usa.tianma.com/products-technology/product/tm070jdhg30-00 You can also find this product along with a FT5x06 touch controller from Boundary Devices: https://boundarydevices.com/product/bd070lic2/ Signed-off-by: Gary Bisson Acked-by: Rob Herring Signed-off-by: Thierry Reding --- .../devicetree/bindings/display/panel/tianma,tm070jdhg30.txt | 7 +++++++ 1 file changed, 7 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/panel/tianma,tm070jdhg30.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/panel/tianma,tm070jdhg30.txt b/Documentation/devicetree/bindings/display/panel/tianma,tm070jdhg30.txt new file mode 100644 index 000000000000..eb9501a82e25 --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/tianma,tm070jdhg30.txt @@ -0,0 +1,7 @@ +Tianma Micro-electronics TM070JDHG30 7.0" WXGA TFT LCD panel + +Required properties: +- compatible: should be "tianma,tm070jdhg30" + +This binding is compatible with the simple-panel binding, which is specified +in simple-panel.txt in this directory. -- cgit v1.2.3 From 505c9d41057455f1947cadf93a7961f3786b089b Mon Sep 17 00:00:00 2001 From: Maxime Ripard Date: Tue, 6 Sep 2016 16:46:16 +0200 Subject: of: Add vendor prefix for Netron DY Netron DY is a brand of LCD panels found on SBCs and tablets. Signed-off-by: Maxime Ripard Acked-by: Rob Herring Signed-off-by: Thierry Reding --- 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 62233d1e1d6e..3e1de203a821 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -196,6 +196,7 @@ nec NEC LCD Technologies, Ltd. neonode Neonode Inc. netgear NETGEAR netlogic Broadcom Corporation (formerly NetLogic Microsystems) +netron-dy Netron DY netxeon Shenzhen Netxeon Technology CO., LTD nexbox Nexbox newhaven Newhaven Display International -- cgit v1.2.3 From e6c2f066d5ed5ba61d48d54b603698bad1c6a270 Mon Sep 17 00:00:00 2001 From: Maxime Ripard Date: Tue, 6 Sep 2016 16:46:17 +0200 Subject: drm/panel: simple: Add Netron DY E231732 The E231732 is a 7" panel with a resolution of 1024x600. Signed-off-by: Maxime Ripard [treding@nvidia.com: add missing device tree binding] Signed-off-by: Thierry Reding --- .../devicetree/bindings/display/panel/netron-dy,e231732.txt | 7 +++++++ 1 file changed, 7 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/panel/netron-dy,e231732.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/panel/netron-dy,e231732.txt b/Documentation/devicetree/bindings/display/panel/netron-dy,e231732.txt new file mode 100644 index 000000000000..c6d06b5eab51 --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/netron-dy,e231732.txt @@ -0,0 +1,7 @@ +Netron-DY E231732 7.0" WSVGA TFT LCD panel + +Required properties: +- compatible: should be "netron-dy,e231732" + +This binding is compatible with the simple-panel binding, which is specified +in simple-panel.txt in this directory. -- cgit v1.2.3 From 9f17d740432cfcc76b538808b3724ed90905fe91 Mon Sep 17 00:00:00 2001 From: Shawn Guo Date: Thu, 19 Jan 2017 23:34:25 +0800 Subject: dt: add bindings for ZTE tvenc device It adds bindings doc for ZTE VOU TV Encoder device. Signed-off-by: Shawn Guo Acked-by: Rob Herring --- Documentation/devicetree/bindings/display/zte,vou.txt | 15 +++++++++++++++ 1 file changed, 15 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/zte,vou.txt b/Documentation/devicetree/bindings/display/zte,vou.txt index 740e5bd2e4f7..9c356284232b 100644 --- a/Documentation/devicetree/bindings/display/zte,vou.txt +++ b/Documentation/devicetree/bindings/display/zte,vou.txt @@ -49,6 +49,15 @@ Required properties: "osc_clk" "xclk" +* TV Encoder output device + +Required properties: + - compatible: should be "zte,zx296718-tvenc" + - reg: Physical base address and length of the TVENC device IO region + - zte,tvenc-power-control: the phandle to SYSCTRL block followed by two + integer cells. The first cell is the offset of SYSCTRL register used + to control TV Encoder DAC power, and the second cell is the bit mask. + Example: vou: vou@1440000 { @@ -81,4 +90,10 @@ vou: vou@1440000 { <&topcrm HDMI_XCLK>; clock-names = "osc_cec", "osc_clk", "xclk"; }; + + tvenc: tvenc@2000 { + compatible = "zte,zx296718-tvenc"; + reg = <0x2000 0x1000>; + zte,tvenc-power-control = <&sysctrl 0x170 0x10>; + }; }; -- cgit v1.2.3 From 059c7a5a748d4e7481d8b1b4cf0e182cb81496ad Mon Sep 17 00:00:00 2001 From: Liviu Dudau Date: Tue, 31 Jan 2017 17:41:09 +0000 Subject: Documentation/gpu: drm-mm.rst: fix formatting for struct vm_operations_struct drm-mm.rst contains some unformatted dump of the vm_operations_struct structure. Add some C formatting around it and some context for the dump. While there, update the structure to resemble the new signature for the fault handler after commit 25d3db7600b8 (mm, fs: reduce fault, page_mkwrite, and pfn_mkwrite to take only vmf). Signed-off-by: Liviu Dudau Signed-off-by: Daniel Vetter Link: http://patchwork.freedesktop.org/patch/msgid/20170131174109.13690-1-Liviu.Dudau@arm.com --- Documentation/gpu/drm-mm.rst | 15 +++++++++++---- 1 file changed, 11 insertions(+), 4 deletions(-) (limited to 'Documentation') diff --git a/Documentation/gpu/drm-mm.rst b/Documentation/gpu/drm-mm.rst index 91d82f39fbf4..f5760b140f13 100644 --- a/Documentation/gpu/drm-mm.rst +++ b/Documentation/gpu/drm-mm.rst @@ -291,10 +291,17 @@ To use :c:func:`drm_gem_mmap()`, drivers must fill the struct :c:type:`struct drm_driver ` gem_vm_ops field with a pointer to VM operations. -struct vm_operations_struct \*gem_vm_ops struct -vm_operations_struct { void (\*open)(struct vm_area_struct \* area); -void (\*close)(struct vm_area_struct \* area); int (\*fault)(struct -vm_area_struct \*vma, struct vm_fault \*vmf); }; +The VM operations is a :c:type:`struct vm_operations_struct ` +made up of several fields, the more interesting ones being: + +.. code-block:: c + + struct vm_operations_struct { + void (*open)(struct vm_area_struct * area); + void (*close)(struct vm_area_struct * area); + int (*fault)(struct vm_fault *vmf); + }; + The open and close operations must update the GEM object reference count. Drivers can use the :c:func:`drm_gem_vm_open()` and -- cgit v1.2.3 From 302cee3648ba1a7322b77511de9112e61a1bfff8 Mon Sep 17 00:00:00 2001 From: Eric Anholt Date: Wed, 14 Dec 2016 11:46:16 -0800 Subject: dt-bindings: Document the VC4 DSI module nodes. These are part of the vc4 display pipeline. Signed-off-by: Eric Anholt Acked-by: Rob Herring Link: http://patchwork.freedesktop.org/patch/msgid/20161214194621.16499-7-eric@anholt.net --- .../devicetree/bindings/display/brcm,bcm-vc4.txt | 35 ++++++++++++++++++++++ 1 file changed, 35 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/brcm,bcm-vc4.txt b/Documentation/devicetree/bindings/display/brcm,bcm-vc4.txt index e2768703ac2b..34c7fddcea39 100644 --- a/Documentation/devicetree/bindings/display/brcm,bcm-vc4.txt +++ b/Documentation/devicetree/bindings/display/brcm,bcm-vc4.txt @@ -56,6 +56,18 @@ Required properties for V3D: - interrupts: The interrupt number See bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.txt +Required properties for DSI: +- compatible: Should be "brcm,bcm2835-dsi0" or "brcm,bcm2835-dsi1" +- reg: Physical base address and length of the DSI block's registers +- interrupts: The interrupt number + See bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.txt +- clocks: a) phy: The DSI PLL clock feeding the DSI analog PHY + b) escape: The DSI ESC clock from CPRMAN + c) pixel: The DSI pixel clock from CPRMAN +- clock-output-names: + The 3 clocks output from the DSI analog PHY: dsi[01]_byte, + dsi[01]_ddr2, and dsi[01]_ddr + [1] Documentation/devicetree/bindings/media/video-interfaces.txt Example: @@ -99,6 +111,29 @@ dpi: dpi@7e208000 { }; }; +dsi1: dsi@7e700000 { + compatible = "brcm,bcm2835-dsi1"; + reg = <0x7e700000 0x8c>; + interrupts = <2 12>; + #address-cells = <1>; + #size-cells = <0>; + #clock-cells = <1>; + + clocks = <&clocks BCM2835_PLLD_DSI1>, + <&clocks BCM2835_CLOCK_DSI1E>, + <&clocks BCM2835_CLOCK_DSI1P>; + clock-names = "phy", "escape", "pixel"; + + clock-output-names = "dsi1_byte", "dsi1_ddr2", "dsi1_ddr"; + + pitouchscreen: panel@0 { + compatible = "raspberrypi,touchscreen"; + reg = <0>; + + <...> + }; +}; + vec: vec@7e806000 { compatible = "brcm,bcm2835-vec"; reg = <0x7e806000 0x1000>; -- cgit v1.2.3 From 1a4a66ddc7b290ea2fd492c9c922ee7205d44724 Mon Sep 17 00:00:00 2001 From: Rob Clark Date: Mon, 30 Jan 2017 10:46:35 -0500 Subject: drm/msm: remove qcom,gpu-pwrlevels bindings The plan is to use the OPP bindings. For now, remove the documentation for qcom,gpu-pwrlevels, and make the driver fall back to a safe low clock if the node is not present. Note that no upstream dtb use this node. For now we keep compatibility with this node to avoid breaking compatibility with downstream android dt files. Signed-off-by: Rob Clark Reviewed-by: Eric Anholt Acked-by: Rob Herring --- Documentation/devicetree/bindings/display/msm/gpu.txt | 15 --------------- 1 file changed, 15 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/msm/gpu.txt b/Documentation/devicetree/bindings/display/msm/gpu.txt index 67d0a58dbb77..747b984c7210 100644 --- a/Documentation/devicetree/bindings/display/msm/gpu.txt +++ b/Documentation/devicetree/bindings/display/msm/gpu.txt @@ -12,12 +12,6 @@ Required properties: * "mem_iface_clk" - qcom,chipid: gpu chip-id. Note this may become optional for future devices if we can reliably read the chipid from hw -- qcom,gpu-pwrlevels: list of operating points - - compatible: "qcom,gpu-pwrlevels" - - for each qcom,gpu-pwrlevel: - - qcom,gpu-freq: requested gpu clock speed - - NOTE: downstream android driver defines additional parameters to - configure memory bandwidth scaling per OPP. Example: @@ -39,14 +33,5 @@ Example: <&mmcc GFX3D_AHB_CLK>, <&mmcc MMSS_IMEM_AHB_CLK>; qcom,chipid = <0x03020100>; - qcom,gpu-pwrlevels { - compatible = "qcom,gpu-pwrlevels"; - qcom,gpu-pwrlevel@0 { - qcom,gpu-freq = <450000000>; - }; - qcom,gpu-pwrlevel@1 { - qcom,gpu-freq = <27000000>; - }; - }; }; }; -- cgit v1.2.3 From 1db7afa4914642146637f891c9d369948bb026c7 Mon Sep 17 00:00:00 2001 From: Rob Clark Date: Mon, 30 Jan 2017 11:02:27 -0500 Subject: drm/msm: drop qcom,chipid The original way we determined the gpu version was based on downstream bindings from android kernel. A cleaner way is to get the version from the compatible string. Note that no upstream dtb uses these bindings. But the code still supports falling back to the legacy bindings (with a warning), so that we are still compatible with the gpu dt node from android device kernels. Signed-off-by: Rob Clark Reviewed-by: Eric Anholt Acked-by: Rob Herring --- Documentation/devicetree/bindings/display/msm/gpu.txt | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/msm/gpu.txt b/Documentation/devicetree/bindings/display/msm/gpu.txt index 747b984c7210..7ac3052ca7b5 100644 --- a/Documentation/devicetree/bindings/display/msm/gpu.txt +++ b/Documentation/devicetree/bindings/display/msm/gpu.txt @@ -1,7 +1,11 @@ Qualcomm adreno/snapdragon GPU Required properties: -- compatible: "qcom,adreno-3xx" +- compatible: "qcom,adreno-XYZ.W", "qcom,adreno" + for example: "qcom,adreno-306.0", "qcom,adreno" + Note that you need to list the less specific "qcom,adreno" (since this + is what the device is matched on), in addition to the more specific + with the chip-id. - reg: Physical base address and length of the controller's registers. - interrupts: The interrupt signal from the gpu. - clocks: device clocks @@ -10,8 +14,6 @@ Required properties: * "core_clk" * "iface_clk" * "mem_iface_clk" -- qcom,chipid: gpu chip-id. Note this may become optional for future - devices if we can reliably read the chipid from hw Example: @@ -19,7 +21,7 @@ Example: ... gpu: qcom,kgsl-3d0@4300000 { - compatible = "qcom,adreno-3xx"; + compatible = "qcom,adreno-320.2", "qcom,adreno"; reg = <0x04300000 0x20000>; reg-names = "kgsl_3d0_reg_memory"; interrupts = ; @@ -32,6 +34,5 @@ Example: <&mmcc GFX3D_CLK>, <&mmcc GFX3D_AHB_CLK>, <&mmcc MMSS_IMEM_AHB_CLK>; - qcom,chipid = <0x03020100>; }; }; -- cgit v1.2.3 From 720c3bb80235ffb10129ee930bb394871afbd235 Mon Sep 17 00:00:00 2001 From: Rob Clark Date: Mon, 30 Jan 2017 11:30:58 -0500 Subject: drm/msm: drop _clk suffix from clk names Suggested by Rob Herring. We still support the old names for compatibility with downstream android dt files. Cc: Rob Herring Signed-off-by: Rob Clark Reviewed-by: Eric Anholt Acked-by: Rob Herring --- Documentation/devicetree/bindings/display/msm/gpu.txt | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/msm/gpu.txt b/Documentation/devicetree/bindings/display/msm/gpu.txt index 7ac3052ca7b5..43fac0fe09bb 100644 --- a/Documentation/devicetree/bindings/display/msm/gpu.txt +++ b/Documentation/devicetree/bindings/display/msm/gpu.txt @@ -11,9 +11,9 @@ Required properties: - clocks: device clocks See ../clocks/clock-bindings.txt for details. - clock-names: the following clocks are required: - * "core_clk" - * "iface_clk" - * "mem_iface_clk" + * "core" + * "iface" + * "mem_iface" Example: @@ -27,9 +27,9 @@ Example: interrupts = ; interrupt-names = "kgsl_3d0_irq"; clock-names = - "core_clk", - "iface_clk", - "mem_iface_clk"; + "core", + "iface", + "mem_iface"; clocks = <&mmcc GFX3D_CLK>, <&mmcc GFX3D_AHB_CLK>, -- cgit v1.2.3 From fa201ac2c61f51d9abdaffdf994d5780dcb51703 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Noralf=20Tr=C3=B8nnes?= Date: Sun, 22 Jan 2017 00:15:00 +0100 Subject: drm: Add DRM support for tiny LCD displays MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit tinydrm provides helpers for very simple displays that can use CMA backed framebuffers and need flushing on changes. Signed-off-by: Noralf Trønnes Acked-by: Daniel Vetter Acked-by: Thierry Reding --- Documentation/gpu/index.rst | 1 + Documentation/gpu/tinydrm.rst | 21 +++++++++++++++++++++ 2 files changed, 22 insertions(+) create mode 100644 Documentation/gpu/tinydrm.rst (limited to 'Documentation') diff --git a/Documentation/gpu/index.rst b/Documentation/gpu/index.rst index 367d7c36b8e9..f81278a7c2cc 100644 --- a/Documentation/gpu/index.rst +++ b/Documentation/gpu/index.rst @@ -11,6 +11,7 @@ Linux GPU Driver Developer's Guide drm-kms-helpers drm-uapi i915 + tinydrm vga-switcheroo vgaarbiter diff --git a/Documentation/gpu/tinydrm.rst b/Documentation/gpu/tinydrm.rst new file mode 100644 index 000000000000..ec4a20d7496b --- /dev/null +++ b/Documentation/gpu/tinydrm.rst @@ -0,0 +1,21 @@ +========================== +drm/tinydrm Driver library +========================== + +.. kernel-doc:: drivers/gpu/drm/tinydrm/core/tinydrm-core.c + :doc: overview + +Core functionality +================== + +.. kernel-doc:: drivers/gpu/drm/tinydrm/core/tinydrm-core.c + :doc: core + +.. kernel-doc:: include/drm/tinydrm/tinydrm.h + :internal: + +.. kernel-doc:: drivers/gpu/drm/tinydrm/core/tinydrm-core.c + :export: + +.. kernel-doc:: drivers/gpu/drm/tinydrm/core/tinydrm-pipe.c + :export: -- cgit v1.2.3 From 9f69eb5c36a644571cca6b2f8dc5f6a7cba04a8b Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Noralf=20Tr=C3=B8nnes?= Date: Sun, 22 Jan 2017 00:19:51 +0100 Subject: drm/tinydrm: Add helper functions MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Add common functionality needed by many tinydrm drivers. Signed-off-by: Noralf Trønnes Acked-by: Daniel Vetter Acked-by: Thierry Reding --- Documentation/gpu/tinydrm.rst | 9 +++++++++ 1 file changed, 9 insertions(+) (limited to 'Documentation') diff --git a/Documentation/gpu/tinydrm.rst b/Documentation/gpu/tinydrm.rst index ec4a20d7496b..fb256d2178f5 100644 --- a/Documentation/gpu/tinydrm.rst +++ b/Documentation/gpu/tinydrm.rst @@ -19,3 +19,12 @@ Core functionality .. kernel-doc:: drivers/gpu/drm/tinydrm/core/tinydrm-pipe.c :export: + +Additional helpers +================== + +.. kernel-doc:: include/drm/tinydrm/tinydrm-helpers.h + :internal: + +.. kernel-doc:: drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c + :export: -- cgit v1.2.3 From 02dd95fe316936269a52d6ccb971bb956412b40a Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Noralf=20Tr=C3=B8nnes?= Date: Sun, 22 Jan 2017 00:30:47 +0100 Subject: drm/tinydrm: Add MIPI DBI support MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Add support for MIPI DBI compatible controllers. Interface type C option 1 and 3 are supported (SPI). Signed-off-by: Noralf Trønnes Acked-by: Thierry Reding --- Documentation/gpu/tinydrm.rst | 12 ++++++++++++ 1 file changed, 12 insertions(+) (limited to 'Documentation') diff --git a/Documentation/gpu/tinydrm.rst b/Documentation/gpu/tinydrm.rst index fb256d2178f5..a913644bfc19 100644 --- a/Documentation/gpu/tinydrm.rst +++ b/Documentation/gpu/tinydrm.rst @@ -28,3 +28,15 @@ Additional helpers .. kernel-doc:: drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c :export: + +MIPI DBI Compatible Controllers +=============================== + +.. kernel-doc:: drivers/gpu/drm/tinydrm/mipi-dbi.c + :doc: overview + +.. kernel-doc:: include/drm/tinydrm/mipi-dbi.h + :internal: + +.. kernel-doc:: drivers/gpu/drm/tinydrm/mipi-dbi.c + :export: -- cgit v1.2.3 From fbaa326df32c68dc46fb91d909ff736364910484 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Noralf=20Tr=C3=B8nnes?= Date: Sun, 22 Jan 2017 14:58:49 +0100 Subject: of: Add vendor prefix for Multi-Inno MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Multi-Inno Technology Co.,Ltd is a Hong Kong based company offering LCD, LCD module products and complete panel solutions. Signed-off-by: Noralf Trønnes Acked-by: Rob Herring --- 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 16d3b5e7f5d1..915f4fa4bcd7 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -187,6 +187,7 @@ mpl MPL AG mqmaker mqmaker Inc. msi Micro-Star International Co. Ltd. mti Imagination Technologies Ltd. (formerly MIPS Technologies Inc.) +multi-inno Multi-Inno Technology Co.,Ltd mundoreader Mundo Reader S.L. murata Murata Manufacturing Co., Ltd. mxicy Macronix International Co., Ltd. -- cgit v1.2.3 From b60c1be747418a07fbe04f8533394a64b27b6181 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Noralf=20Tr=C3=B8nnes?= Date: Tue, 31 Jan 2017 16:05:57 +0100 Subject: dt-bindings: display/panel: Add common rotation property MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Display panels can be oriented many ways, especially in the embedded world. The rotation property is a way to describe this orientation. The counter clockwise direction is chosen because that's what fbdev and drm use. Signed-off-by: Noralf Trønnes Acked-by: Thierry Reding Acked-by: Rob Herring --- Documentation/devicetree/bindings/display/panel/panel.txt | 4 ++++ 1 file changed, 4 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/panel/panel.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/panel/panel.txt b/Documentation/devicetree/bindings/display/panel/panel.txt new file mode 100644 index 000000000000..e2e6867852b8 --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/panel.txt @@ -0,0 +1,4 @@ +Common display properties +------------------------- + +- rotation: Display rotation in degrees counter clockwise (0,90,180,270) -- cgit v1.2.3 From 6b4e48b5a99c7fdc6886c4296798922f2545b7cb Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Noralf=20Tr=C3=B8nnes?= Date: Sun, 22 Jan 2017 15:02:26 +0100 Subject: dt-bindings: Add Multi-Inno MI0283QT binding MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Add device-tree binding documentation for the MI0283QT display panel. Signed-off-by: Noralf Trønnes Acked-by: Rob Herring --- .../bindings/display/multi-inno,mi0283qt.txt | 27 ++++++++++++++++++++++ 1 file changed, 27 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/multi-inno,mi0283qt.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/multi-inno,mi0283qt.txt b/Documentation/devicetree/bindings/display/multi-inno,mi0283qt.txt new file mode 100644 index 000000000000..eed48c3d4875 --- /dev/null +++ b/Documentation/devicetree/bindings/display/multi-inno,mi0283qt.txt @@ -0,0 +1,27 @@ +Multi-Inno MI0283QT display panel + +Required properties: +- compatible: "multi-inno,mi0283qt". + +The node for this driver must be a child node of a SPI controller, hence +all mandatory properties described in ../spi/spi-bus.txt must be specified. + +Optional properties: +- dc-gpios: D/C pin. The presence/absence of this GPIO determines + the panel interface mode (IM[3:0] pins): + - present: IM=x110 4-wire 8-bit data serial interface + - absent: IM=x101 3-wire 9-bit data serial interface +- reset-gpios: Reset pin +- power-supply: A regulator node for the supply voltage. +- backlight: phandle of the backlight device attached to the panel +- rotation: panel rotation in degrees counter clockwise (0,90,180,270) + +Example: + mi0283qt@0{ + compatible = "multi-inno,mi0283qt"; + reg = <0>; + spi-max-frequency = <32000000>; + rotation = <90>; + dc-gpios = <&gpio 25 0>; + backlight = <&backlight>; + }; -- cgit v1.2.3