- 19 Feb, 2019 6 commits
-
-
Jordan Crouse authored
Try to get the interconnect path for the GPU and vote for the maximum bandwidth to support all frequencies. This is needed for performance. Later we will want to scale the bandwidth based on the frequency to also optimize for power but that will require some device tree infrastructure that does not yet exist. v6: use icc_set_bw() instead of icc_set() v5: Remove hardcoded interconnect name and just use the default v4: Don't use a port string at all to skip the need for names in the DT v3: Use macros and change port string per Georgi Djakov Signed-off-by:
Jordan Crouse <jcrouse@codeaurora.org> Acked-by:
Rob Clark <robdclark@gmail.com> Reviewed-by:
Evan Green <evgreen@chromium.org> Signed-off-by:
Georgi Djakov <georgi.djakov@linaro.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Wei Yongjun authored
In case of error, the function dma_buf_get() returns ERR_PTR() and never returns NULL. The NULL test in the return value check should be replaced with IS_ERR(). Signed-off-by:
Wei Yongjun <weiyongjun1@huawei.com> Signed-off-by:
-
Minchan Kim authored
binder has used write-side mmap_sem semaphore to release memory mapped at address space of the process. However, right lock to release pages is down_read, not down_write because page table lock already protects the race for parallel freeing. Please do not use mmap_sem write-side lock which is well known contented lock. Cc: Todd Kjos <tkjos@google.com> Cc: Martijn Coenen <maco@android.com> Cc: Arve Hjønnevåg <arve@android.com> Signed-off-by:
Minchan Kim <minchan@kernel.org> Signed-off-by:
-
Thierry Escande authored
This change fixes fastrpc_device_open() when no session is available and return an error in such case. Signed-off-by:
Thierry Escande <thierry.escande@linaro.org> Signed-off-by:
Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by:
-
Srinivas Kandagatla authored
Fastrpc is a dma buf exporter as well, so select the corresponding DMA_SHARED_BUFFER config to fix below compilation errors on platforms without this config. ld: drivers/misc/fastrpc.o: in function 'fastrpc_free_map': fastrpc.c:(.text+0xbe): undefined reference to 'dma_buf_unmap_attachment' ld: fastrpc.c:(.text+0xcb): undefined reference to 'dma_buf_detach' ld: fastrpc.c:(.text+0xd4): undefined reference to 'dma_buf_put' ld: drivers/misc/fastrpc.o: in function 'fastrpc_map_create': fastrpc.c:(.text+0xb2b): undefined reference to 'dma_buf_get' ld: fastrpc.c:(.text+0xb47): undefined reference to 'dma_buf_attach' ld: fastrpc.c:(.text+0xb61): undefined reference to 'dma_buf_map_attachment' ld: fastrpc.c:(.text+0xc36): undefined reference to 'dma_buf_put' ld: fastrpc.c:(.text+0xc48): undefined reference to 'dma_buf_detach' ld: drivers/misc/fastrpc.o: in function 'fastrpc_device_ioctl': fastrpc.c:(.text+0x1756): undefined reference to 'dma_buf_get' ld: fastrpc.c:(.text+0x1776): undefined reference to 'dma_buf_put' ld: fastrpc.c:(.text+0x1780): undefined reference to 'dma_buf_put' ld: fastrpc.c:(.text+0x1abf): undefined reference to 'dma_buf_export' ld: fastrpc.c:(.text+0x1ae7): undefined reference to 'dma_buf_fd' ld: fastrpc.c:(.text+0x1cb5): undefined reference to 'dma_buf_put' ld: fastrpc.c:(.text+0x1cca): undefined reference to 'dma_buf_put' Reported-by:
Randy Dunlap <rdunlap@infradead.org> Signed-off-by:
-
Bartosz Golaszewski authored
blocking_notifier_call_chain() returns the value returned by the last registered callback. A positive return value doesn't indicate an error and an nvmem device should correctly register irrespective of any notifier callback failures. Drop the retval check. Fixes: bee1138b ("nvmem: add a notifier chain") Cc: stable@vger.kernel.org Signed-off-by:
Bartosz Golaszewski <bgolaszewski@baylibre.com> Acked-by:
-
- 18 Feb, 2019 15 commits
-
-
Oded Gabbay authored
The habanalabs driver was written from scratch from the very first days of Habana and is maintained by Oded Gabbay. Signed-off-by:
Oded Gabbay <oded.gabbay@gmail.com> Signed-off-by:
-
Oded Gabbay authored
This patch adds debugfs support to the driver. It allows the user-space to display information that is contained in the internal structures of the driver, such as: - active command submissions - active user virtual memory mappings - number of allocated command buffers It also enables the user to perform reads and writes through Goya's PCI bars. Reviewed-by:
Mike Rapoport <rppt@linux.ibm.com> Signed-off-by:
-
Oded Gabbay authored
This patch implements the INFO IOCTL. That IOCTL is used by the user to query information that is relevant/needed by the user in order to submit deep learning jobs to Goya. The information is divided into several categories, such as H/W IP, Events that happened, DDR usage and more. Reviewed-by:
-
Omer Shpigelman authored
This patch adds the Virtual Memory and MMU modules. Goya has an internal MMU which provides process isolation on the internal DDR. The internal MMU also performs translations for transactions that go from Goya to the Host. The driver is responsible for allocating and freeing memory on the DDR upon user request. It also provides an interface to map and unmap DDR and Host memory to the device address space. The MMU in Goya supports 3-level and 4-level page tables. With 3-level, the size of each page is 2MB, while with 4-level the size of each page is 4KB. In the DDR, the physical pages are always 2MB. Reviewed-by:
Omer Shpigelman <oshpigelman@habana.ai> Signed-off-by:
-
Oded Gabbay authored
This patch adds the main flow for the user to submit work to the device. Each work is described by a command submission object (CS). The CS contains 3 arrays of command buffers: One for execution, and two for context-switch (store and restore). For each CB, the user specifies on which queue to put that CB. In case of an internal queue, the entry doesn't contain a pointer to the CB but the address in the on-chip memory that the CB resides at. The driver parses some of the CBs to enforce security restrictions. The user receives a sequence number that represents the CS object. The user can then query the driver regarding the status of the CS, using that sequence number. In case the CS doesn't finish before the timeout expires, the driver will perform a soft-reset of the device. Reviewed-by:
-
Oded Gabbay authored
This patch adds support for doing various on-the-fly reset of Goya. The driver supports two types of resets: 1. soft-reset 2. hard-reset Soft-reset is done when the device detects a timeout of a command submission that was given to the device. The soft-reset process only resets the engines that are relevant for the submission of compute jobs, i.e. the DMA channels, the TPCs and the MME. The purpose is to bring the device as fast as possible to a working state. Hard-reset is done in several cases: 1. After soft-reset is done but the device is not responding 2. When fatal errors occur inside the device, e.g. ECC error 3. When the driver is removed Hard-reset performs a reset of the entire chip except for the PCI controller and the PLLs. It is a much longer process then soft-reset but it helps to recover the device without the need to reboot the Host. After hard-reset, the driver will restore the max power attribute and in case of manual power management, the frequencies that were set. This patch also adds two entries to the sysfs, which allows the root user to initiate a soft or hard reset. Reviewed-by:
-
Oded Gabbay authored
This patch add the sysfs and hwmon entries that are exposed by the driver. Goya has several sensors, from various categories such as temperature, voltage, current, etc. The driver exposes those sensors in the standard hwmon mechanism. In addition, the driver exposes a couple of interfaces in sysfs, both for configuration and for providing status of the device or driver. The configuration attributes is for Power Management: - Automatic or manual - Frequency value when moving to high frequency mode - Maximum power the device is allowed to consume The rest of the attributes are read-only and provide the following information: - Versions of the various firmwares running on the device - Contents of the device's EEPROM - The device type (currently only Goya is supported) - PCI address of the device (to allow user-space to connect between /dev/hlX to PCI address) - Status of the device (operational, malfunction, in_reset) - How many processes are open on the device's file Reviewed-by:
-
Oded Gabbay authored
This patch adds support for receiving events from Goya's control CPU and for receiving MSI-X interrupts from Goya's DMA engines and CPU. Goya's PCI controller supports up to 8 MSI-X interrupts, which only 6 of them are currently used. The first 5 interrupts are dedicated for Goya's DMA engine queues. The 6th interrupt is dedicated for Goya's control CPU. The DMA queue will signal its MSI-X entry upon each completion of a command buffer that was placed on its primary queue. The driver will then mark that CB as completed and free the related resources. It will also update the command submission object which that CB belongs to. There is a dedicated event queue (EQ) between the driver and Goya's control CPU. The EQ is located on the Host memory. The control CPU writes a new entry to the EQ for various reasons, such as ECC error, MMU page fault, Hot temperature. After writing the new entry to the EQ, the control CPU will trigger its dedicated MSI-X entry to signal the driver that there is a new entry in the EQ. The driver will then read the entry and act accordingly. Reviewed-by:
-
Oded Gabbay authored
This patch adds the H/W queues module and the code to initialize Goya's various compute and DMA engines and their queues. Goya has 5 DMA channels, 8 TPC engines and a single MME engine. For each channel/engine, there is a H/W queue logic which is used to pass commands from the user to the H/W. That logic is called QMAN. There are two types of QMANs: external and internal. The DMA QMANs are considered external while the TPC and MME QMANs are considered internal. For each external queue there is a completion queue, which is located on the Host memory. The differences between external and internal QMANs are: 1. The location of the queue's memory. External QMANs are located on the Host memory while internal QMANs are located on the on-chip memory. 2. The external QMAN write an entry to a completion queue and sends an MSI-X interrupt upon completion of a command buffer that was given to it. The internal QMAN doesn't do that. Reviewed-by:
-
Oded Gabbay authored
This patch adds the basic part of Goya's H/W initialization. It adds code that initializes Goya's internal CPU, various registers that are related to internal routing, scrambling, workarounds for H/W bugs, etc. It also initializes Goya's security scheme that prevents the user from abusing Goya to steal data from the host, crash the host, change Goya's F/W, etc. Reviewed-by:
-
Oded Gabbay authored
This patch adds the command buffer (CB) module, which allows the user to create and destroy CBs and to map them to the user's process address-space. A command buffer is a memory blocks that reside in DMA-able address-space and is physically contiguous so it can be accessed by the device without MMU translation. The command buffer memory is allocated using the coherent DMA API. When creating a new CB, the IOCTL returns a handle of it, and the user-space process needs to use that handle to mmap the buffer to get a VA in the user's address-space. Before destroying (freeing) a CB, the user must unmap the CB's VA using the CB handle. Each CB has a reference counter, which tracks its usage in command submissions and also its mmaps (only a single mmap is allowed). The driver maintains a pool of pre-allocated CBs in order to reduce latency during command submissions. In case the pool is empty, the driver will go to the slow-path of allocating a new CB, i.e. calling dma_alloc_coherent. Reviewed-by:
-
Oded Gabbay authored
This patch adds two modules - ASID and context. Each user process that opens a device's file must have at least one context before it is able to "work" with the device. Each context has its own device address-space and contains information about its runtime state (its active command submissions). To have address-space separation between contexts, each context is assigned a unique ASID, which stands for "address-space id". Goya supports up to 1024 ASIDs. Currently, the driver doesn't support multiple contexts. Therefore, the user doesn't need to actively create a context. A "primary context" is created automatically when the user opens the device's file. Reviewed-by:
-
Oded Gabbay authored
This patch adds a basic support for the Goya device. The code initializes the device's PCI controller and PCI bars. It also initializes various S/W structures and adds some basic helper functions. Reviewed-by:
-
Oded Gabbay authored
This patch just adds a lot of header files that contain description of Goya's registers. Signed-off-by:
-
Oded Gabbay authored
This patch adds the habanalabs skeleton driver. The driver does nothing at this stage except very basic operations. It contains the minimal code to insmod and rmmod the driver and to create a /dev/hlX file per PCI device. Reviewed-by:
-
- 15 Feb, 2019 1 commit
-
-
Todd Kjos authored
Fixes crash found by syzbot: kernel BUG at drivers/android/binder_alloc.c:LINE! (2) Reported-and-tested-by: syzbot+55de1eb4975dec156d8f@syzkaller.appspotmail.com Signed-off-by:
Todd Kjos <tkjos@google.com> Signed-off-by:
-
- 14 Feb, 2019 1 commit
-
-
Todd Kjos authored
Fixes sparse issues reported by the kbuild test robot running on https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git char-misc-testing: bde4a19f ("binder: use userspace pointer as base of buffer space") Error output (drivers/android/binder_alloc_selftest.c): sparse: warning: incorrect type in assignment (different address spaces) sparse: expected void *page_addr sparse: got void [noderef] <asn:1> *user_data sparse: error: subtraction of different types can't work Fixed by adding necessary "__user" tags. Reported-by:
kbuild test robot <lkp@intel.com> Signed-off-by:
-
- 13 Feb, 2019 2 commits
-
-
Gustavo A. R. Silva authored
In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through. This patch fixes the following warnings: drivers/char/lp.c: In function ‘lp_compat_ioctl’: drivers/char/lp.c:756:6: warning: this statement may fall through [-Wimplicit-fallthrough=] if (!COMPAT_USE_64BIT_TIME) { ^ drivers/char/lp.c:761:2: note: here case LPSETTIMEOUT_NEW: ^~~~ drivers/char/lp.c: In function ‘lp_ioctl’: drivers/char/lp.c:728:6: warning: this statement may fall through [-Wimplicit-fallthrough=] if (BITS_PER_LONG == 32) { ^ drivers/char/lp.c:733:2: note: here case LPSETTIMEOUT_NEW: ^~~~ Warning level 3 was used: -Wimplicit-fallthrough=3 Notice that in some cases, the code comment is modified in accordance with what GCC is expecting to find. This patch is part of the ongoing efforts to enable -Wimplicit-fallthrough. Signed-off-by:Gustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by:
-
Sudip Mukherjee authored
Modify parport daisy driver to use the new parallel port device model. Signed-off-by:
Sudip Mukherjee <sudipm.mukherjee@gmail.com> Signed-off-by:
-
- 12 Feb, 2019 14 commits
-
-
Todd Kjos authored
Now that alloc->buffer points to the userspace vm_area rename buffer->data to buffer->user_data and rename local pointers that hold user addresses. Also use the "__user" tag to annotate all user pointers so sparse can flag cases where user pointer vaues are copied to kernel pointers. Refactor code to use offsets instead of user pointers. Signed-off-by:
-
Todd Kjos authored
Remove user_buffer_offset since there is no kernel buffer pointer anymore. Signed-off-by:
-
Todd Kjos authored
Remove the kernel's vm_area and the code that maps buffer pages into it. Signed-off-by:
-
Todd Kjos authored
Refactor the functions to validate and fixup struct binder_buffer pointer objects to avoid using vm_area pointers. Instead copy to/from kernel space using binder_alloc_copy_to_buffer() and binder_alloc_copy_from_buffer(). The following functions were refactored: refactor binder_validate_ptr() binder_validate_fixup() binder_fixup_parent() Signed-off-by:
-
Todd Kjos authored
When creating or tearing down a transaction, the binder driver examines objects in the buffer and takes appropriate action. To do this without needing to dereference pointers into the buffer, the local copies of the objects are needed. This patch introduces a function to validate and copy binder objects from the buffer to a local structure. Signed-off-by:
-
Todd Kjos authored
Avoid vm_area when copying to or from binder buffers. Instead, new copy functions are added that copy from kernel space to binder buffer space. These use kmap_atomic() and kunmap_atomic() to create temporary mappings and then memcpy() is used to copy within that page. Also, kmap_atomic() / kunmap_atomic() use the appropriate cache flushing to support VIVT cache architectures. Allow binder to build if CPU_CACHE_VIVT is defined. Several uses of the new functions are added here. More to follow in subsequent patches. Signed-off-by:
-
Todd Kjos authored
The binder driver uses a vm_area to map the per-process binder buffer space. For 32-bit android devices, this is now taking too much vmalloc space. This patch removes the use of vm_area when copying the transaction data from the sender to the buffer space. Instead of using copy_from_user() for multi-page copies, it now uses binder_alloc_copy_user_to_buffer() which uses kmap() and kunmap() to map each page, and uses copy_from_user() for copying to that page. Signed-off-by:
-
Srinivas Kandagatla authored
User process can involve dealing with big buffer sizes, and also passing buffers from one compute context bank to other compute context bank for complex dsp algorithms. This patch adds support to fastrpc to make it a proper dmabuf exporter to avoid making copies of buffers. Co-developed-by:
-
Srinivas Kandagatla authored
This patch adds support to create or attach remote shell process. The shell process called fastrpc_shell_0 is usually loaded on the DSP when a user process is spawned. Most of the work is derived from various downstream Qualcomm kernels. Credits to various Qualcomm authors who have contributed to this code. Specially Tharun Kumar Merugu <mtharu@codeaurora.org> Co-developed-by:
-
Srinivas Kandagatla authored
This patch adds support to compute context invoke method on the remote processor (DSP). This involves setting up the functions input and output arguments, input and output handles and mapping the dmabuf fd for the argument/handle buffers. The below diagram depicts invocation of a single method where the client and objects reside on different processors. An object could expose multiple methods which can be grouped together and referred to as an interface. ,--------, ,------, ,-----------, ,------, ,--------, | | method | | | | | | method | | | Client |------->| Stub |->| Transport |->| Skel |------->| Object | | | | | | | | | | | `--------` `------` `-----------` `------` `--------` Client: Linux user mode process that initiates the remote invocation Stub: Auto generated code linked in with the user mode process that takes care of marshaling parameters Transport: Involved in carrying an invocation from a client to an object. This involves two portions: 1) FastRPC Linux kernel driver that receives the remote invocation, queues them up and then waits for the response after signaling the remote side. 2) Service running on the remote side that dequeues the messages from the queue and dispatches them for processing. Skel: Auto generated code that takes care of un-marshaling parameters Object: Method implementation Most of the work is derived from various downstream Qualcomm kernels. Credits to various Qualcomm authors who have contributed to this code. Specially Tharun Kumar Merugu <mtharu@codeaurora.org> Co-developed-by: -
Srinivas Kandagatla authored
This patch adds basic driver model for Qualcomm FastRPC driver which implements an IPC (Inter-Processor Communication) mechanism that allows for clients to transparently make remote method invocations across processor boundaries. Each DSP rpmsg channel is represented as fastrpc channel context and is exposed as a character device for userspace interface. Each compute context bank is represented as fastrpc-session-context, which are dynamically managed by the channel context char device. Co-developed-by:
-
Srinivas Kandagatla authored
The FastRPC driver implements an IPC (Inter-Processor Communication) mechanism that allows for clients to transparently make remote method invocations across DSP and APPS boundaries. This enables developers to offload tasks to the DSP and free up the application processor for other tasks. Co-developed-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Dan Carpenter authored
We added some locking to this function but forgot to drop the lock on these two error paths. This bug would lead to an immediate deadlock. Fixes: c7b3690f ("vmw_balloon: stats rework") Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Cc: stable@vger.kernel.org Reviewed-by:
Nadav Amit <namit@vmware.com> Signed-off-by:
-
Tomas Winkler authored
Export to_mei_cl_device macro, as it is needed also in the mei client drivers. Signed-off-by:
Tomas Winkler <tomas.winkler@intel.com> Signed-off-by:
-
- 11 Feb, 2019 1 commit
-
-
QiaoChong authored
In the original code before 181bf1e8 the loop was continuing until it finds the first matching superios[i].io and p->base. But after 181bf1e8 the logic changed and the loop now returns the pointer to the first mismatched array element which is then used in get_superio_dma() and get_superio_irq() and thus returning the wrong value. Fix the condition so that it now returns the correct pointer. Fixes: 181bf1e8 ("parport_pc: clean up the modified while loops using for") Cc: Alan Cox <alan@linux.intel.com> Cc: stable@vger.kernel.org Signed-off-by:
QiaoChong <qiaochong@loongson.cn> [rewrite the commit message] Signed-off-by:
-
