- 13 Feb, 2019 5 commits
-
-
Felix Kuehling authored
Use FENCE_OWNER_KFD to synchronize PT/PD initialization and clearing of page table entries. This avoids triggering KFD eviction fences on the PD reservation objects of compute VMs. Signed-off-by:
Felix Kuehling <Felix.Kuehling@amd.com> Reviewed-by:
Christian König <christian.koenig@amd.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com>
-
Felix Kuehling authored
The fence_owner logic in amdgpu_sync_wait will allow waiting without having to temporarily remove eviction fences. Signed-off-by:
-
Felix Kuehling authored
Creates a temporary sync object to wait for the BO reservation. This generalizes amdgpu_vm_wait_pd. Signed-off-by:
-
wentalou authored
sriov's gpu_recover inside xgpu_ai_mailbox_flr_work would cause duplicate recover in TDR. TDR's gpu_recover would be triggered by amdgpu_job_timedout, that could avoid vk-cts failure by unexpected recover. Signed-off-by:
Wentao Lou <Wentao.Lou@amd.com> Acked-by:
Andrey Grodzovsky <andrey.grodzovsky@amd.com> Signed-off-by:
-
Christian König authored
Remove the callback and call the dispatcher directly. Signed-off-by:
-
- 11 Feb, 2019 5 commits
-
-
Gerd Hoffmann authored
Bisected guest kernel changes crashing qemu. Landed at "6c1cd97b drm/virtio: fix resource id handling". Looked again, and noticed we where not only leaking *some* ids, but *all* ids. The old code never ever called virtio_gpu_resource_id_put(). So, commit 6c1cd97b effectively makes the linux kernel starting re-using IDs after releasing them, and apparently virglrenderer can't deal with that. Oops. This patch puts a temporary stopgap into place for the 5.0 release. Signed-off-by:
Gerd Hoffmann <kraxel@redhat.com> Reviewed-by:
Dave Airlie <airlied@redhat.com> Signed-off-by:
-
git://people.freedesktop.org/~agd5f/linuxDave Airlie authored
Updates for 5.1: - GDS fixes - Add AMDGPU_CHUNK_ID_SCHEDULED_DEPENDENCIES interface - GPUVM fixes - PCIE DPM switching fixes for vega20 - Vega10 uclk DPM regression fix - DC Freesync fixes - DC ABM fixes - Various DC cleanups Signed-off-by:
-
git://anongit.freedesktop.org/drm/drm-intelDave Airlie authored
UAPI Changes: - Expose RPCS (SSEU) configuration to userspace for Ice Lake in order to allow userspace to reconfigure the subslice config per context basis. (Tvrtko, Lionel) Driver Changes: - Execbuf and preemption improvements including selftests (Chris) - Rename HAS_GMCH_DISPLAY/HAS_GMCH (Rodrigo) - Debugfs error handling fix for robustness (Greg) - Improve reg_rw traces (Ville) - Push clear_intel_crtc_state onto the heap (Chris) - Watermark fixes for Ice Lake (Ville) - Fix enable count array size and bounds checking (Tvrtko) - MST Fixes (Lyude) - Prevent race and handle error on I915_GEM_MMAP (Joonas) - Initial rework for an full atomic gamma mode (Ville) Signed-off-by:
-
git://anongit.freedesktop.org/tegra/linuxDave Airlie authored
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:
-
git://linuxtv.org/pinchartl/mediaDave Airlie authored
Renesas display drivers changes for v5.1 (2nd part): - R8A7744 LVDS support - DPAD0 output support on D3/E3 Signed-off-by:
-
- 08 Feb, 2019 8 commits
-
-
Dave Airlie authored
Merge tag 'exynos-drm-next-for-v5.1' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into drm-next - Add rotator support for s5pv210 . With this patch series, s5pv210 SoC can use rotator module but only NV12 and XRGB8888 formats are supported. - Modify e-mail address . It changes email address of scaler module author. Signed-off-by:
-
Laurent Pinchart authored
On the D3 and E3 SoCs the LVDS PLL clock output provides the dot clock to the DU channels, even when the LVDS outputs are not in use. Enable and disable the LVDS clock output when enabling or disabling a CRTC connected to the DPAD0 output. Signed-off-by:Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
-
Laurent Pinchart authored
On the D3 and E3 platforms, the LVDS internal PLL supplies the pixel clock to the DU. This works automatically for LVDS outputs as the LVDS encoder is enabled through the bridge API, enabling the internal PLL and clock output. However, when using the DU DPAD output with the LVDS outputs turned off, the LVDS PLL needs to be controlled manually. Add an API to do so, to be called by the DU driver. The drivers/gpu/drm/rcar-du/ directory has to be treated as obj-y unconditionally, as the LVDS driver could be built-in while the DU driver is compiled as a module. Signed-off-by: -
Laurent Pinchart authored
On the D3 and E3 SoCs the LVDS encoder has an extended internal PLL and supplies a clock to the DU. That clock is used not only for the LVDS outputs but also for the DPAD output. The LVDS encoder thus needs to be available to the DU even when its output is disabled. Don't fail probe in that case on D3 and E3. Signed-off-by: -
Laurent Pinchart authored
Before the driver fully moved to drm_bridge and drm_panel, it was necessary to parse DT and locate encoder and connector nodes. The connector node is now unused and can be removed as a parameter to rcar_du_encoder_init(). As a consequence rcar_du_encoders_init_one() can be greatly simplified, removing most of the DT parsing. Signed-off-by: -
Biju Das authored
The LVDS encoders on RZ/G1N SoC is similar to RZ/G1M. Add support for RZ/G1N (R8A7744) SoC to the LVDS encoder driver. Signed-off-by:
Biju Das <biju.das@bp.renesas.com> Reviewed-by:
Simon Horman <horms+renesas@verge.net.au>
-
Biju Das authored
Document the RZ/G1N (R8A7744) LVDS bindings. Signed-off-by:
Rob Herring <robh@kernel.org>
-
Julia Lawall authored
Add an of_node_put when the result of of_graph_get_remote_port_parent is not available. Add a second of_node_put if no encoder is selected (encoder remains NULL). The semantic match that finds the first problem is as follows (http://coccinelle.lip6.fr): // <smpl> @r exists@ local idexpression e; expression x; @@ e = of_graph_get_remote_port_parent(...); ... when != x = e when != true e == NULL when != of_node_put(e) when != of_fwnode_handle(e) ( return e; | *return ...; ) // </smpl> Signed-off-by:
Julia Lawall <Julia.Lawall@lip6.fr> Reviewed-by:
Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Signed-off-by:
-
- 07 Feb, 2019 22 commits
-
-
Harry Wentland authored
dal_gpio_open and dal_gpio_unlock_pin dereference hpd_gpio. Check for NULL before calling those functions. Fixes: ac627caf ("drm/amd/display: add gpio lock/unlock") Reported-by:
Przemek Socha <soprwa@gmail.com> CC: Chiawen Huang <chiawen.huang@amd.com> CC: Tony Cheng <Tony.Cheng@amd.com> Acked-by:
Harry Wentland <harry.wentland@amd.com> Signed-off-by:
-
Rodrigo Vivi authored
Signed-off-by:Rodrigo Vivi <rodrigo.vivi@intel.com>
-
Ville Syrjälä authored
The LUTs are single buffered so we should program them after the double buffered pipe updates have been latched by the hardware. We'll also fix up the IPS vs. split gamma w/a to do the IPS disable like everyone else. Note that this is currently dead code as we don't use the split gamma mode on HSW, but that will be fixed up shortly. Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190205160848.24662-7-ville.syrjala@linux.intel.comReviewed-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
-
Ville Syrjälä authored
Split the color management hooks along the single vs. double buffered registers line. Of the currently programmed registers GAMMA_MODE and the ilk+ pipe CSC are double buffered, the LUTS and CHV CGM block are single buffered. The double buffered register will be programmed during the normal pipe update with evasion, and also during pipe enable so that the settings will already be correct when the pipe starts up before the planes are enabled. The single buffered registers are currently programmed before the vblank evade. Which is totally wrong, but we'll correct that later. v2: Add some docs to explain the two vfuncs (Matt,Uma) Rebase Signed-off-by: -
Ville Syrjälä authored
For bdw+ let's move the GAMMA_MODE write for the legacy LUT mode into the .load_luts() funciton directly, rather than relying on haswell_load_luts(). We'll be getting rid of haswell_load_luts() entirely soon, and it's anyway cleaner to have the GAMMA_MODE write in a single place. Signed-off-by:
Matt Roper <matthew.d.roper@intel.com> Reviewed-by:
Uma Shankar <uma.shankar@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190205160848.24662-5-ville.syrjala@linux.intel.comReviewed-by:
-
Ville Syrjälä authored
Pass the crtc state etc. as const to the color management commit functions. And while at it polish some of the local variables. v2: Rebase Signed-off-by:
-
Ville Syrjälä authored
We shouldn't be computing gamma mode during the commit phase. Move it to the check phase. v2: Reword comments a bit (Matt) Rebase Signed-off-by: -
Ville Syrjälä authored
On g4x+ the pipe gamma enable bit for the primary plane affects the pipe bottom color as well. The same for the pipe csc enable bit on ilk+. Thus we must configure those bits correctly even when the primary plane is disabled. To make the feasible let's split those settings from the plane_ctl() function into a seprate funciton that we can call from the ->disable_plane() hook as well. For consistency we'll do that on all the plane types. While that has no real benefits at this time, it'll become useful when we start to control the pipe gamma/csc enable bits dynamically when we overhaul the color management code. On pre-g4x there doesn't appear to be any way to gamma correct the pipe bottom color, but sticking to the same pattern doesn't hurt. And it'll still help us to do crtc state readout correctly for the pipe gamma enable bit for the color management overhaul. An alternative apporach would be to still precompute these bits into plane_state->ctl, but that would require that we run through the plane check even when the plane isn't logically enabled on any crtc. Currently that condition causes us to short circuit the entire thing and not call ->check_plane(). There would also be some chicken and egg problems with ->check_plane() vs. crtc color state check that would requite splitting certain things into multiple steps. So all in all this seems like the easier route. Signed-off-by:
-
Christian König authored
The exclusive fence is of course perfectly optional here. Signed-off-by:
-
Harish Kasiviswanathan authored
v2: Fix SMU message format Send override message after SMU enable features Signed-off-by:Harish Kasiviswanathan <Harish.Kasiviswanathan@amd.com> Reviewed-by:
Eric Huang <JinhuiEric.Huang@amd.com> Signed-off-by:
-
Harish Kasiviswanathan authored
The new Vega series GPU cards have in-built bridges. To get the pcie speed and width supported by the platform walk the hierarchy and get the slowest link. Signed-off-by:
-
Dmitry Osipenko authored
Currently gathers of a hung job are getting NOP'ed and a restarted CDMA executes the NOP'ed gathers. There shouldn't be a reason to not restart CDMA execution starting with a next job, avoiding the unnecessary churning with gathers NOP'ing. Signed-off-by:
Dmitry Osipenko <digetx@gmail.com> Reviewed-by:
Mikko Perttunen <mperttunen@nvidia.com> Signed-off-by:
Thierry Reding <treding@nvidia.com>
-
Dmitry Osipenko authored
There is a chance that the last job has been completed at the time of CDMA timeout handler invocation. In this case there is no need to complete the completed job. Signed-off-by:
-
Dmitry Osipenko authored
Host1x doesn't have information about jobs inter-dependency, that is something that will become available once host1x will get a proper jobs scheduler implementation. Currently a hang job causes other unrelated jobs to be canceled, that is a relic from downstream driver which is irrelevant to upstream. Let's cancel only the hanging job and not to touch other jobs in queue. Signed-off-by:
-
Thierry Reding authored
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 authored
The SOR has a crossbar that can map each lane of the SOR to each of the SOR pads. The mapping is usually the same across designs for a specific SoC generation, but every now and then there's a design that doesn't. Allow the crossbar configuration to be specified in device tree to make it possible to support these designs. Signed-off-by: -
Thierry Reding authored
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 authored
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:
-
Thierry Reding authored
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 authored
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:
-
Thierry Reding authored
Loading the firmware requires an allocation of IOVA space to make sure that the VIC's Falcon microcontroller can read the firmware if address translation via the SMMU is enabled. However, the allocation currently happens at a time where the geometry of an IOMMU domain may not have been initialized yet. This happens for example on Tegra186 and later where an ARM SMMU is used. Domains which are created by the ARM SMMU driver postpone the geometry setup until a device is attached to the domain. This is because IOMMU domains aren't attached to a specific IOMMU instance at allocation time and hence the input address space, which defines the geometry, is not known yet. Work around this by postponing the firmware load until it is needed at the time where a channel is opened to the VIC. At this time the shared IOMMU domain's geometry has been properly initialized. As a byproduct this allows the Tegra DRM to be created in the absence of VIC firmware, since the VIC initialization no longer fails if the firmware can't be found. Based on an earlier patch by Dmitry Osipenko <digetx@gmail.com>. Signed-off-by:
-
Thierry Reding authored
Tegra DRM clients need access to their parent, so store a pointer to it upon registration. It's technically possible to get at this by going via the host1x client's parent and getting the driver data, but that's quite complicated and not very transparent. It's much more straightforward and natural to let the children know about their parent. Signed-off-by:
-
