Translate queue priority into pipe priority and write to MQDs.
The priority values are used to perform queue and pipe arbitration.
Signed-off-by: NOak Zeng <Oak.Zeng@amd.com>
Reviewed-by: NFelix Kuehling <Felix.Kuehling@amd.com>
Signed-off-by: NFelix Kuehling <Felix.Kuehling@amd.com>
Acked-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Always mark evicted queues with q->properties.is_evicted = true, even
queues that are inactive for other reason. This simplifies maintaining
the eviction state as it doesn't require updating is_evicted when other
queue activation conditions change.

On the other hand, we now need to check those other queue activation
conditions whenever an evicted queues is restored. To minimize code
duplication, move the queue activation check into a macro so it can be
maintained in one central place.
Signed-off-by: NFelix Kuehling <Felix.Kuehling@amd.com>
Reviewed-by: NPhilip Cox <Philip.Cox@amd.com>
Acked-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

EDC counts are related to instance and se. They are not the same
for different type of EDC. EDC clearing are changed to base on
individual EDC's instance and SE number.
Signed-off-by: NJames Zhu <James.Zhu@amd.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

[Why]
DCN_VERSION_1_01 is no longer handled in the dal_hw_translate_init
switch since it was inadvertently dropped in the patch that removed the
unnecessary DCN1_01 guards.

This caused numerous regressions on DCN1_01 when loading the driver.

[How]
Add it back.

Fixes: 97df424f ("drm/amd/display: Drop DCN1_01 guards")
Signed-off-by: NNicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Acked-by: NAlex Deucher <alexander.deucher@amd.com>
Reviewed-by: NHarry Wentland <harry.wentland@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

[Why]
When switching from vt to desktop with EDID emulation we can receive
an atomic commit such that we have a crtc where mode_changed = true.

During the dm_update_crtc_state disable pass we remove the stream from
the context and free it on the dm_new_crtc_state.

During the enable pass we compare the new provisional stream to the
dm_old_crtc_state->stream and determine that the stream is unchanged
and no scaling has been changed.

Following this, new_crtc_state->mode_changed is then set to false.
The connectors haven't changed and the CRTC active state hasn't changed
so drm_atomic_crtc_needs_modeset returns false, so we jump to
skip_modeset and we hit:

BUG_ON(dm_new_crtc_state->stream == NULL);

...since the old stream is gone from the context and the new stream is
also still NULL.

[How]
Ensure that we still a stream to reuse before checking if we can reuse
the old stream without a full modeset.
Signed-off-by: NNicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Reviewed-by: NHarry Wentland <harry.wentland@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

This avoids OOM situations when we have lots of threads
submitting at the same time.

v3: apply this to the whole driver, not just CS
Signed-off-by: NChristian König <christian.koenig@amd.com>
Reviewed-by: NChunming Zhou <david1.zhou@amd.com>
Tested-by: NPierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

And only move them in on validation. This allows for better control
when multiple processes are fighting over those resources.
Signed-off-by: NChristian König <christian.koenig@amd.com>
Reviewed-by: NChunming Zhou <david1.zhou@amd.com>
Tested-by: NPierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

The messages about amdgpu_cs_list_validate are duplicated because the
caller will complain into the logs as well and we can also get
interrupted by a signal here.

Also fix the the caller to not report -EAGAIN from validation.
Signed-off-by: NChristian König <christian.koenig@amd.com>
Reviewed-by: NChunming Zhou <david1.zhou@amd.com>
Tested-by: NPierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

ras ta interface header need to be updated to match with latest ta fw updates
Signed-off-by: NHawking Zhang <Hawking.Zhang@amd.com>
Reviewed-by: NJames Zhu <James.Zhu@amd.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

omapdrm changes for 5.3

- Add support for DSI command mode displays
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
From: Tomi Valkeinen <tomi.valkeinen@ti.com>
Link: https://patchwork.freedesktop.org/patch/msgid/a709f57d-6909-8550-3932-d84e0b5bc3ef@ti.com

R-Car DU changes for v5.3:

- R8A774A1 SoC support
- LVDS dual-link mode support
- Support for additional formats
- Misc fixes
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190608134652.GE4786@pendragon.ideasonboard.com

This adds the required infrastructure for manually updated displays,
such as DSI command mode panels. While those panels often support
partial updates we currently always do a full refresh.

The display will be refreshed when something calls the dirty callback,
such as libdrm's drmModeDirtyFB(). This is currently being done at least
by the kernel console and Xorg (with modesetting driver) in their
default configuration. Weston does not implement this and the fbdev
backend does not work (display will not update). Weston's DRM backend
uses double buffering and the page flip will also trigger a display
refresh.
Signed-off-by: NSebastian Reichel <sebastian.reichel@collabora.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

This prepares framedone interrupt handling for
manual display update support.
Acked-by: NPavel Machek <pavel@ucw.cz>
Tested-by: NTony Lindgren <tony@atomide.com>
Tested-by: NPavel Machek <pavel@ucw.cz>
Signed-off-by: NSebastian Reichel <sebastian.reichel@collabora.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

While most display types only forward their VM to the DISPC, this
is not true for DSI. DSI calculates the VM for DISPC based on its
own, but it's not identical. Actually the DSI VM is not even a valid
DISPC VM making this check fail. Let's restore the old behaviour
and avoid checking the DISPC VM for DSI here.

Fixes: 7c27fa57 ("drm/omap: Call dispc timings check operation directly")
Acked-by: NPavel Machek <pavel@ucw.cz>
Tested-by: NTony Lindgren <tony@atomide.com>
Tested-by: NPavel Machek <pavel@ucw.cz>
Signed-off-by: NSebastian Reichel <sebastian.reichel@collabora.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

This macro is only used by omapdrm, which should print
debug messages using the DRIVER category instead of the
default CORE category.
Acked-by: NPavel Machek <pavel@ucw.cz>
Tested-by: NTony Lindgren <tony@atomide.com>
Tested-by: NPavel Machek <pavel@ucw.cz>
Signed-off-by: NSebastian Reichel <sebastian.reichel@collabora.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Using dev_get_drvdata directly.

Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: David Airlie <airlied@linux.ie>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: NKefeng Wang <wangkefeng.wang@huawei.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: NEmil Velikov <emil.velikov@collabora.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Make sure (of/i2c/platform)_device_id tables are NULL terminated.
Signed-off-by: NThomas Meyer <thomas@m3y3r.de>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Add support for the DRM_FORMAT_RGBA5551, DRM_FORMAT_RGBX5551,
DRM_FORMAT_ABGR1555, DRM_FORMAT_XBGR1555, DRM_FORMAT_BGRA5551 and
DRM_FORMAT_BGRX5551 formats to the DU driver. Those formats are only
available on Gen3.
Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Acked-by: NSakari Ailus <sakari.ailus@linux.intel.com>
Reviewed-by: NJacopo Mondi <jacopo@jmondi.org>
Acked-by: NDaniel Vetter <daniel@ffwll.ch>

Add support for the DRM_FORMAT_RGBA4444, DRM_FORMAT_RGBX4444,
DRM_FORMAT_ABGR4444, DRM_FORMAT_XBGR4444, DRM_FORMAT_BGRA4444 and
DRM_FORMAT_BGRX4444 formats to the DU driver. Those formats are only
available on Gen3.
Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Acked-by: NSakari Ailus <sakari.ailus@linux.intel.com>
Reviewed-by: NJacopo Mondi <jacopo@jmondi.org>
Acked-by: NDaniel Vetter <daniel@ffwll.ch>

Add support for the DRM_FORMAT_RGBA8888, DRM_FORMAT_RGBX8888,
DRM_FORMAT_ABGR8888 and DRM_FORMAT_XBGR8888 formats to the DU driver.
Those formats are only available on Gen3.
Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Acked-by: NSakari Ailus <sakari.ailus@linux.intel.com>
Reviewed-by: NJacopo Mondi <jacopo@jmondi.org>
Acked-by: NDaniel Vetter <daniel@ffwll.ch>

In dual-link LVDS mode, the LVDS1 encoder is used as a companion for
LVDS0, and both encoders transmit data from DU0. The LVDS1 output of DU1
can't be used in that case, don't create an encoder and connector for
it.
Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Reviewed-by: NJacopo Mondi <jacopo+renesas@jmondi.org>
Tested-by: NJacopo Mondi <jacopo+renesas@jmondi.org>
Acked-by: NSam Ravnborg <sam@ravnborg.org>
Reviewed-by: NKieran Bingham <kieran.bingham+renesas@ideasonboard.com>

In dual-link mode the LVDS0 encoder transmits even-numbered pixels, and
sends odd-numbered pixels to the LVDS1 encoder for transmission on a
separate link.

To implement support for this mode of operation, determine if the LVDS
connection operates in dual-link mode by querying the next device in the
pipeline, locate the companion encoder, and control it directly through
its bridge operations.
Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Reviewed-by: NJacopo Mondi <jacopo+renesas@jmondi.org>
Tested-by: NJacopo Mondi <jacopo+renesas@jmondi.org>
Acked-by: NSam Ravnborg <sam@ravnborg.org>
Reviewed-by: NKieran Bingham <kieran.bingham+renesas@ideasonboard.com>

The DRM core and DU driver guarantee that the LVDS bridge will not be
double-enabled or double-disabled. Remove the corresponding unnecessary
checks.
Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Reviewed-by: NJacopo Mondi <jacopo@jmondi.org>
Tested-by: NJacopo Mondi <jacopo+renesas@jmondi.org>
Acked-by: NSam Ravnborg <sam@ravnborg.org>
Reviewed-by: NKieran Bingham <kieran.bingham+renesas@ideasonboard.com>

Add a new optional renesas,companion property to point to the companion
LVDS encoder. This is used to support dual-link operation where the main
LVDS encoder splits even-numbered and odd-numbered pixels between the
two LVDS encoders.

The new property doesn't control the mode of operation, it only
describes the relationship between the master and companion LVDS
encoders.
Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Reviewed-by: NJacopo Mondi <jacopo@jmondi.org>
Tested-by: NJacopo Mondi <jacopo+renesas@jmondi.org>
Acked-by: NSam Ravnborg <sam@ravnborg.org>
Reviewed-by: NKieran Bingham <kieran.bingham+renesas@ideasonboard.com>

Set a drm_bridge_timings in the drm_bridge, and use it to report the
input bus mode (single-link or dual-link). The other fields of the
timings structure are kept to 0 as they do not apply to LVDS buses.
Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Reviewed-by: NJacopo Mondi <jacopo@jmondi.org>
Tested-by: NJacopo Mondi <jacopo+renesas@jmondi.org>
Acked-by: NSam Ravnborg <sam@ravnborg.org>
Reviewed-by: NKieran Bingham <kieran.bingham+renesas@ideasonboard.com>

The THC63LVD1024 LVDS decoder can operate in two modes, single-link or
dual-link. In dual-link mode both input ports are used to carry even-
and odd-numbered pixels separately. Document this in the DT bindings,
along with the related rules governing port and usage.
Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Reviewed-by: NJacopo Mondi <jacopo+renesas@jmondi.org>
Reviewed-by: NRob Herring <robh@kernel.org>
Tested-by: NJacopo Mondi <jacopo+renesas@jmondi.org>
Acked-by: NSam Ravnborg <sam@ravnborg.org>
Reviewed-by: NKieran Bingham <kieran.bingham+renesas@ideasonboard.com>

Extend the drm_bridge_timings structure with a new dual_link field to
indicate that the bridge's input bus carries data on two separate
physical links. The first use case is LVDS dual-link mode where even-
and odd-numbered pixels are transferred on separate LVDS links.
Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Reviewed-by: NKieran Bingham <kieran.bingham+renesas@ideasonboard.com>
Tested-by: NJacopo Mondi <jacopo+renesas@jmondi.org>
Acked-by: NSam Ravnborg <sam@ravnborg.org>

The new writeback feature exports functions so that they can integrate
into the rcar_du_kms module.

The interface functions are defined in the rcar_du_writeback header, but
it is not included in the object file itself leading to compiler
warnings for missing prototypes.

Include the header as appropriate.
Signed-off-by: NKieran Bingham <kieran.bingham+renesas@ideasonboard.com>
Reviewed-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>

The LVDS encoders on RZ/G2M SoC is similar to R-Car M3-W. Add support for
RZ/G2M (R8A774A1) SoC to the LVDS encoder driver.
Signed-off-by: NBiju Das <biju.das@bp.renesas.com>
Reviewed-by: NKieran Bingham <kieran.bingham+renesas@ideasonboard.com>
Reviewed-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>

Add support for the R8A774A1 DU (which is very similar to the R8A7796 DU
except that it lacks TCON and CMM); it has one RGB output, one LVDS output
and one HDMI output.
Signed-off-by: NBiju Das <biju.das@bp.renesas.com>
Reviewed-by: NKieran Bingham <kieran.bingham+renesas@ideasonboard.com>
Reviewed-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>

Document the RZ/G2M (R8A774A1) LVDS bindings.
Signed-off-by: NBiju Das <biju.das@bp.renesas.com>
Reviewed-by: NKieran Bingham <kieran.bingham+renesas@ideasonboard.com>
Reviewed-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>

Document the RZ/G2M (R8A774A1) SoC in the R-Car DU bindings.
Signed-off-by: NBiju Das <biju.das@bp.renesas.com>
Reviewed-by: NKieran Bingham <kieran.bingham+renesas@ideasonboard.com>
Reviewed-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>

amdgpu:
- Revert timeline support until KHR is ready
- Various driver reload fixes
- Refactor clock handling in DC
- Aux fixes for DC
- Bandwidth calculation updates for DC
- Fix documentation due to file rename
- RAS fix
- Fix race in late_init

ttm:
- Allow for better forward progress when there is heavy memory contention
Signed-off-by: NDave Airlie <airlied@redhat.com>
From: Alex Deucher <alexdeucher@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190606032537.6939-1-alexander.deucher@amd.com

This reverts commit 8d8a5a64.

Wait until KHR exposes the VLK support.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Since we now keep BOs on the LRU we need to explicitely remove
them from the LRU now after they are pinned.
Signed-off-by: NChristian König <christian.koenig@amd.com>
Reviewed-by: NFelix Kuehling <Felix.Kuehling@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

These got added back by subsequent merges accidently.
Reviewed-by: NHarry Wentland <harry.wentland@amd.com>
Reviewed-by: NNicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Acked-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Split late_init into two functions, one (do_late_init) which
just does the hw init, and late_init which calls do_late_init
and schedules the IB test work.  Call do_late_init in
the GPU reset code to run the init code, but not schedule
the IB test code.  The IB test code is called directly
in the gpu reset code so no need to run the IB tests
in a separate work thread.  If we do, we end up racing.

v2: Rework late_init.  Pull out the mgpu fan boost and xgmi
pstate code into late_init so they get called in all cases.
rename the late_init worker thread to delayed work since it's
just the IB tests now which can happen later.  Schedule the
work at init and resume time.  It's not needed at reset time
because the IB tests are called directly.
Reviewed-by: NChristian König <christian.koenig@amd.com>
Cc: Xinhui Pan <xinhui.pan@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

gpu reset will run late_init and schedule the late_init_work.  if we
keep triggering gpu reset in a short time, there are potenial races.
Signed-off-by: Nxinhui pan <xinhui.pan@amd.com>
Reviewed-by: NFeifei Xu <Feifei.Xu@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

This file was renamed, but docs weren't updated accordingly.

	WARNING: kernel-doc './scripts/kernel-doc -rst -enable-lineno -function PRIME Buffer Sharing ./drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c' failed with return code 1
	WARNING: kernel-doc './scripts/kernel-doc -rst -enable-lineno -internal ./drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c' failed with return code 2

Fixes: 2fbd6f94 ("drm/amdgpu: rename amdgpu_prime.[ch] into amdgpu_dma_buf.[ch]")
Reviewed-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab+samsung@kernel.org>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>