user/sven/linux.git/drivers/gpu/host1x, branch v5.5

gpu: host1x: Unconditionally select IOMMU_IOVA

2019-11-01T09:49:17Z

Currently configurations can be generated where IOMMU_SUPPORT is disabled but IOMMU_IOVA is built as a module and HOST1X as built-in. In such a case, the symbols guarded by IOMMU_IOVA will not be available when linking the host1x driver and cause a linking failure. Simplify this by unconditionally selecting IOMMU_IOVA, which makes sure that it will be forced to =y if HOST1X=y. Technically we can now get IOMMU_IOVA code built-in even if we don't use it (host1x only uses it when IOMMU_SUPPORT is also enabled), but such configuration are of a mostly academic nature. In all practical configurations we want IOMMU support anyway. Signed-off-by: Thierry Reding

gpu: host1x: Set DMA mask based on IOMMU setup

2019-10-29T14:04:35Z

If the Tegra DRM clients are backed by an IOMMU, push buffers are likely to be allocated beyond the 32-bit boundary if sufficient system memory is available. This is problematic on earlier generations of Tegra where host1x supports a maximum of 32 address bits for the GATHER opcode. More recent versions of Tegra (Tegra186 and later) have a wide variant of the GATHER opcode, which allows addressing up to 64 bits of memory. If host1x itself is behind an IOMMU as well this doesn't matter because the IOMMU's input address space is restricted to 32 bits on generations without support for wide GATHER opcodes. However, if host1x is not behind an IOMMU, it won't be able to process push buffers beyond the 32-bit boundary on Tegra generations that don't support wide GATHER opcodes. Restrict the DMA mask to 32 bits on these generations prevents buffers from being allocated from beyond the 32-bit boundary. Signed-off-by: Thierry Reding

gpu: host1x: Support DMA mapping of buffers

2019-10-29T14:04:35Z

If host1x_bo_pin() returns an SG table, create a DMA mapping for the buffer. For buffers that the host1x client has already mapped itself, host1x_bo_pin() returns NULL and the existing DMA address is used. Signed-off-by: Thierry Reding

gpu: host1x: Allocate gather copy for host1x

2019-10-29T14:04:35Z

Currently when the gather buffers are copied, they are copied to a buffer that is allocated for the host1x client that wants to execute the command streams in the buffers. However, the gather buffers will be read by the host1x device, which causes SMMU faults if the DMA API is backed by an IOMMU. Fix this by allocating the gather buffer copy for the host1x device, which makes sure that it will be mapped into the host1x's IOVA space if the DMA API is backed by an IOMMU. Signed-off-by: Thierry Reding

gpu: host1x: Clean up debugfs on removal

2019-10-29T14:04:34Z

The debugfs files created for host1x are never removed, causing these files to be left dangling in debugfs. This results in a crash when any of these files are accessed after the host1x driver has been removed, as well as a failure to create the debugfs entries when they are added again on driver probe. Signed-off-by: Thierry Reding

gpu: host1x: Overhaul host1x_bo_{pin,unpin}() API

2019-10-29T14:04:34Z

The host1x_bo_pin() and host1x_bo_unpin() APIs are used to pin and unpin buffers during host1x job submission. Pinning currently returns the SG table and the DMA address (an IOVA if an IOMMU is used or a physical address if no IOMMU is used) of the buffer. The DMA address is only used for buffers that are relocated, whereas the host1x driver will map gather buffers into its own IOVA space so that they can be processed by the CDMA engine. This approach has a couple of issues. On one hand it's not very useful to return a DMA address for the buffer if host1x doesn't need it. On the other hand, returning the SG table of the buffer is suboptimal because a single SG table cannot be shared for multiple mappings, because the DMA address is stored within the SG table, and the DMA address may be different for different devices. Subsequent patches will move the host1x driver over to the DMA API which doesn't work with a single shared SG table. Fix this by returning a new SG table each time a buffer is pinned. This allows the buffer to be referenced by multiple jobs for different engines. Change the prototypes of host1x_bo_pin() and host1x_bo_unpin() to take a struct device *, specifying the device for which the buffer should be pinned. This is required in order to be able to properly construct the SG table. While at it, make host1x_bo_pin() return the SG table because that allows us to return an ERR_PTR()-encoded error code if we need to, or return NULL to signal that we don't need the SG table to be remapped and can simply use the DMA address as-is. At the same time, returning the DMA address is made optional because in the example of command buffers, host1x doesn't need to know the DMA address since it will have to create its own mapping anyway. Signed-off-by: Thierry Reding

gpu: host1x: Make host1x_cdma_wait_pushbuffer_space() static

2019-10-28T10:18:34Z

The host1x_cdma_wait_pushbuffer_space() function is not declared or directly called from outside the file it is in, so make it static. Fixes the following sparse warning: drivers/gpu/host1x/cdma.c:235:5: warning: symbol 'host1x_cdma_wait_pushbuffer_space' was not declared. Should it be static? Signed-off-by: Ben Dooks Signed-off-by: Thierry Reding

gpu: host1x: Request channels for clients, not devices

2019-10-28T10:18:33Z

A struct device doesn't carry much information that a channel might be interested in, but the client very much does. Request channels for the clients rather than their parent devices and store a pointer to them in order to have that information available when needed. Signed-off-by: Thierry Reding

gpu: host1x: Explicitly initialize host1x_info structures

2019-10-28T10:18:33Z

It's technically not required to explicitly initialize the fields that will be zero by default, but it's easier to read these structures if they are all initialized uniformly. Signed-off-by: Thierry Reding

gpu: host1x: Remove gratuitous blank line

2019-10-28T10:18:33Z

Signed-off-by: Thierry Reding