wireguard-linux/drivers/gpu/drm/tegra/dc.c, branch jd/unified-crypt-queue

drm/tegra: dc: Silence RGB output deferred-probe error

2020-03-13T17:03:06Z

Driver fails to probe with -EPROBE_DEFER if display output isn't ready yet. This produces a bit noisy error message in KMSG during kernel's boot up on Tegra20 and Tegra30 because RGB output tends to be probed earlier than a corresponding voltage regulator driver. Signed-off-by: Dmitry Osipenko Signed-off-by: Thierry Reding

drm/tegra: dc: Release PM and RGB output when client's registration fails

2020-03-12T09:26:19Z

Runtime PM and RGB output need to be released when host1x client registration fails. The releasing is missed in the code, let's correct it. Signed-off-by: Dmitry Osipenko Signed-off-by: Thierry Reding

drm/tegra: dc: Use devm_platform_ioremap_resource

2020-03-12T09:26:02Z

The devm_platform_ioremap_resource() helper replaces few lines of a boilerplate code with a single line, making code to look cleaner a tad. Signed-off-by: Dmitry Osipenko Signed-off-by: Thierry Reding

drm/tegra: Do not implement runtime PM

2020-01-10T15:37:43Z

The Tegra DRM driver heavily relies on the implementations for runtime suspend/resume to be called at specific times. Unfortunately, there are some cases where that doesn't work. One example is if the user disables runtime PM for a given subdevice. Another example is that the PM core acquires a reference to runtime PM during system sleep, effectively preventing devices from going into low power modes. This is intentional to avoid nasty race conditions, but it also causes system sleep to not function properly on all Tegra systems. Fix this by not implementing runtime PM at all. Instead, a minimal, reference-counted suspend/resume infrastructure is added to the host1x bus. This has the benefit that it can be used regardless of the system power state (or any transitions we might be in), or whether or not the user allows runtime PM. Atomic modesetting guarantees that these functions will end up being called at the right point in time, so the pitfalls for the more generic runtime PM do not apply here. Signed-off-by: Thierry Reding

gpu: host1x: Rename "parent" to "host"

2020-01-10T15:37:38Z

Rename the host1x clients' parent to "host" because that more closely describes what it is. The parent can be confused with the parent device in terms of the device hierarchy. Subsequent patches will add a new member that refers to the parent in that hierarchy. Signed-off-by: Thierry Reding

drm/tegra: Silence expected errors on IOMMU attach

2019-12-04T12:37:44Z

Subdevices may not be hooked up to an IOMMU via device tree. Detect such situations and avoid confusing users by not emitting an error message. Reviewed-by: Daniel Vetter Signed-off-by: Thierry Reding

drm/tegra: Use proper IOVA address for cursor image

2019-12-04T12:36:52Z

The IOVA address for the cursor is the result of mapping the buffer object for the given display controller. Make sure to use the proper IOVA address as stored in the cursor's plane state. Reviewed-by: Daniel Vetter Signed-off-by: Thierry Reding

drm/tegra: Support DMA API for display controllers

2019-10-29T14:04:36Z

If a display controller is not attached to an explicit IOMMU domain, which usually means that it's connected to an IOMMU domain controlled by the DMA API, make sure to map the framebuffer to the display controller address space. This allows us to transparently handle setups where the display controller is attached to an IOMMU or setups where it isn't. It also allows the driver to work with a DMA API that is backed by an IOMMU. Signed-off-by: Thierry Reding

drm/tegra: Simplify IOMMU group selection

2019-10-29T14:04:34Z

All the devices that make up the DRM device are now part of the same IOMMU group. This simplifies the handling of the IOMMU attachment and also avoids exhausting the number of IOMMUs available on early Tegra SoC generations. Signed-off-by: Thierry Reding

drm/tegra: gem: Rename paddr -> iova

2019-10-28T10:18:38Z

The address can refer to either physical memory or IO virtual memory. If referring to IO virtual memory, there will always be an associated physical memory address. Rename this variable to "iova" to clarify in all cases that this is the IO virtual memory, which in the absence of an IOMMU is identical to the physical address. Signed-off-by: Thierry Reding