Linux kernel stable tree (mirror) https://git.radix-linux.su/kernel/linux.git/atom?h=v5.1.16 2019-06-09T07:16:16+00:00 2019-06-09T07:16:16+00:00 Dmitry Osipenko digetx@gmail.com 2019-03-06T22:55:19+00:00 urn:sha1:37dfbf0ad37b897f15d90f8cecc5e0dc5c5bb0b2 commit 61b51fb51c01a519a249d28ec55c6513a13be5a3 upstream. The allocated pages need to be invalidated in CPU caches. On ARM32 the DMA_BIDIRECTIONAL flag only ensures that data is written-back to DRAM and the data stays in CPU cache lines. While the DMA_FROM_DEVICE flag ensures that the corresponding CPU cache lines are getting invalidated and nothing more, that's exactly what is needed for a newly allocated pages. This fixes randomly failing rendercheck tests on Tegra30 using the Opentegra driver for tests that use small-sized pixmaps (10x10 and less, i.e. 1-2 memory pages) because apparently CPU reads out stale data from caches and/or that data is getting evicted to DRAM at the time of HW job execution. Fixes: bd43c9f0fa1f ("drm/tegra: gem: Map pages via the DMA API") Cc: stable <stable@vger.kernel.org> Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2019-04-17T07:28:43+00:00 Thierry Reding treding@nvidia.com 2019-04-16T12:43:26+00:00 urn:sha1:83f8bf4b837b0e3417f0e5c717a43fcf71ecc992 The audio configuration is only valid if the HDMI codec has been properly set up. Do not attempt to set up audio before that happens because it causes a division by zero. Note that this is only problematic on Tegra20 and Tegra30. Later chips implement the division instructions which return zero when dividing by zero and don't throw an exception. Fixes: db5adf4d6dce ("drm/tegra: hdmi: Fix audio to work with any pixel clock rate") Reported-by: Marcel Ziswiler <marcel.ziswiler@toradex.com> Tested-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Thierry Reding <treding@nvidia.com> 2019-03-22T13:08:55+00:00 Anders Roxell anders.roxell@linaro.org 2019-02-18T11:00:50+00:00 urn:sha1:509869a2fec36ecb2b841180915995f41d5a0219 When CONFIG_IOMMU_API isn't set the following warnings pops up: drivers/gpu/drm/tegra/vic.c: In function ‘vic_boot’: drivers/gpu/drm/tegra/vic.c:110:31: error: implicit declaration of function ‘dev_iommu_fwspec_get’; did you mean ‘iommu_fwspec_free’? [-Werror=implicit-function-declaration] struct iommu_fwspec *spec = dev_iommu_fwspec_get(vic->dev); ^~~~~~~~~~~~~~~~~~~~ iommu_fwspec_free drivers/gpu/drm/tegra/vic.c:110:31: warning: initialization of ‘struct iommu_fwspec *’ from ‘int’ makes pointer from integer without a cast [-Wint-conversion] drivers/gpu/drm/tegra/vic.c:117:19: error: ‘struct iommu_fwspec’ has no member named ‘num_ids’ if (spec && spec->num_ids > 0) { ^~ drivers/gpu/drm/tegra/vic.c:118:16: error: ‘struct iommu_fwspec’ has no member named ‘ids’ value = spec->ids[0] & 0xffff; ^~ Rework so that its inside a '#ifdef CONFIG_IOMMU_API' block. Fixes: f3779cb190a5 ("drm/tegra: vic: Support stream ID register programming") Signed-off-by: Anders Roxell <anders.roxell@linaro.org> Signed-off-by: Thierry Reding <treding@nvidia.com> 2019-03-22T13:08:54+00:00 Thierry Reding treding@nvidia.com 2019-02-11T10:51:20+00:00 urn:sha1:7cf77b273a8fc51e7de622fa6691abd4436a9a6b Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Thierry Reding <treding@nvidia.com> 2019-02-11T03:32:49+00:00 Dave Airlie airlied@redhat.com 2019-02-11T03:32:38+00:00 urn:sha1:38f070eb125a9253ec1acd641e7159555f57132a drm/tegra: Changes for v5.1-rc1 This set of changes starts of with some refactoring of the CEC support to make it reusable on Tegra210 and later. Following are a couple of fixes for HDMI audio support (via HDA). The bulk here is a set of preparatory patches working towards enabling Tegra186 support for host1x and VIC. Additional patches will be needed to fully enable this, but they're not quite ready yet. To round things off, this also adds support for configuring the SOR crossbar using device tree, and fixes a couple of job-related issues in the host1x code. Signed-off-by: Dave Airlie <airlied@redhat.com> From: Thierry Reding <thierry.reding@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190208144721.25830-1-thierry.reding@gmail.com 2019-02-07T17:29:02+00:00 Thierry Reding treding@nvidia.com 2019-01-25T10:00:58+00:00 urn:sha1:6d6c815daad8ec3469135c310ed39849cbe7752c The crossbar configuration is usually the same across all designs for a given SoC generation. But sometimes there are designs that require some other configuration. Implement support for parsing the crossbar configuration from a device tree. If the crossbar configuration is not present in the device tree, fall back to the default crossbar configuration. Signed-off-by: Thierry Reding <treding@nvidia.com> 2019-02-07T17:29:01+00:00 Thierry Reding treding@nvidia.com 2019-02-01T13:28:36+00:00 urn:sha1:f3779cb190a5a12d2e26fd5af724fb1384a9144f The version of VIC found in Tegra186 and later incorporates improvements with regards to context isolation. As part of those improvements, stream ID registers were added that allow to specify separate stream IDs for the Falcon microcontroller and the VIC memory interface. While it is possible to also set the stream ID dynamically at runtime to allow userspace contexts to be completely separated, this commit doesn't implement that yet. Instead, the static VIC stream ID is programmed when the Falcon is booted. This ensures that memory accesses by the Falcon or the VIC are properly translated via the SMMU. Signed-off-by: Thierry Reding <treding@nvidia.com> 2019-02-07T17:29:00+00:00 Thierry Reding treding@nvidia.com 2019-02-01T13:28:35+00:00 urn:sha1:3ff41673d5c6842e6668f95b0a14e5f6a74d043f Upon driver failure, the driver core will take care of clearing the driver data, so there's no need to do so explicitly in the driver. Reviewed-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Thierry Reding <treding@nvidia.com> 2019-02-07T17:29:00+00:00 Thierry Reding treding@nvidia.com 2019-02-01T13:28:34+00:00 urn:sha1:02be8e4fbb1f352f2ed6251db9fddd646d531b6e On Tegra186 and later, the ARM SMMU provides an input address space that is 48 bits wide. However, memory clients can only address up to 40 bits. If the geometry is used as-is, allocations of IOVA space can end up in a region that cannot be addressed by the memory clients. To fix this, restrict the IOVA space to the DMA mask of the host1x device. Note that, technically, the IOVA space needs to be restricted to the intersection of the DMA masks for all clients that are attached to the IOMMU domain. In practice using the DMA mask of the host1x device is sufficient because all host1x clients share the same DMA mask. Signed-off-by: Thierry Reding <treding@nvidia.com> 2019-02-07T17:29:00+00:00 Thierry Reding treding@nvidia.com 2019-02-01T13:28:33+00:00 urn:sha1:b9f8b09ce256e2e197b9a38984dea64e3404728c Move initialization of the shared IOMMU domain after the host1x device has been initialized. At this point all the Tegra DRM clients have been attached to the shared IOMMU domain. This is important because Tegra186 and later use an ARM SMMU, for which the driver defers setting up the geometry for a domain until a device is attached to it. This is to ensure that the domain is properly set up for a specific ARM SMMU instance, which is unknown at allocation time. Reviewed-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Thierry Reding <treding@nvidia.com>