[PATCH] drm/amdgpu: add parameter to allocate high priority contexts v9

Add a new context creation parameter to express a global context priority. The priority ranking in descending order is as follows: * AMDGPU_CTX_PRIORITY_HIGH * AMDGPU_CTX_PRIORITY_NORMAL * AMDGPU_CTX_PRIORITY_LOW The driver will attempt to schedule work to the hardware according to the

[RFC] drm/amdgpu: avoid scheduling on fence status query

When amdgpu_cs_wait_ioctl is called with a timeout of zero, the caller is just interested in the current status of the fence. The default implementation of dma_fence_wait_timeout on an unsignaled fence will always call schedule_timeout(), even if the timeout is zero. This may result in

Re: [PATCH] drm/amdgpu: add parameter to allocate high priority contexts v8

On Tue, Apr 25, 2017 at 4:28 PM, Andres Rodriguez wrote: > > > On 2017-04-25 02:01 PM, Nicolai Hähnle wrote: >> >> On 24.04.2017 18:20, Andres Rodriguez wrote: >>> >>> Add a new context creation parameter to express a global context >>> priority. >>> >>> The priority ranking

Re: [PATCH 2/2] drm/amdgpu: Fix use of interruptible waiting

On 26/04/17 06:25 AM, Alex Xie wrote: > 1. The wait is short. There is not much benefit by > interruptible waiting. > 2. In this function and caller functions, the error > handling for such interrupt is complicated and risky. > > Change-Id: I289674ecd3f5ef20c93fe63e33df6d668b3c2edc >

Re: [RFC] drm/amdgpu: avoid scheduling on fence status query

On 26/04/17 09:28 AM, Andres Rodriguez wrote: > When amdgpu_cs_wait_ioctl is called with a timeout of zero, the caller > is just interested in the current status of the fence. > > The default implementation of dma_fence_wait_timeout on an unsignaled > fence will always call schedule_timeout(),

[PATCH 5/5] amdgpu: use drm sync objects for shared semaphores (v4)

From: Dave Airlie This creates a new command submission chunk for amdgpu to add in and out sync objects around the submission. Sync objects are managed via the drm syncobj ioctls. The command submission interface is enhanced with two new chunks, one for syncobj pre

[PATCH 3/5] drm/syncobj: add sync_file interaction.

From: Dave Airlie This interface allows importing the fence from a sync_file into an existing drm sync object, or exporting the fence attached to an existing drm sync object into a new sync file object. This should only be used to interact with sync files where necessary.

[rfc] drm sync objects (search for spock)

Okay I've gone around the sun with these a few times, and pretty much implemented what I said last week. This is pretty much a complete revamp. 1. sync objects are self contained drm objects, they have a file reference so can be passed between processes. 2. Added a sync object wait interface

[PATCH 1/5] drm: introduce sync objects

From: Dave Airlie Sync objects are new toplevel drm object, that contain a pointer to a fence. This fence can be updated via command submission ioctls via drivers. There is also a generic wait obj API modelled on the vulkan wait API (with code modelled on some amdgpu code).

[PATCH 2/5] drm/syncobj: add sync obj wait interface.

From: Dave Airlie This interface will allow sync object to be used to back Vulkan fences. This API is pretty much the vulkan fence waiting API, and I've ported the code from amdgpu. Signed-off-by: Dave Airlie --- drivers/gpu/drm/drm_internal.h | 2 +

Re: [PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

On 25/04/17 07:26 PM, Ville Syrjälä wrote: > On Tue, Apr 25, 2017 at 10:12:37AM +0900, Michel Dänzer wrote: >> On 24/04/17 10:03 PM, Ville Syrjälä wrote: >>> On Mon, Apr 24, 2017 at 03:57:02PM +0900, Michel Dänzer wrote: On 22/04/17 07:05 PM, Ville Syrjälä wrote: > On Fri, Apr 21, 2017 at

Re: [PATCH 1/2] drm/amdgpu: fix gpu reset crash

On 2017年04月25日 21:34, Deucher, Alexander wrote: > -Original Message- > From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf > Of zhoucm1 > Sent: Monday, April 24, 2017 10:20 PM > To: Christian König; amd-gfx@lists.freedesktop.org > Subject: Re: [PATCH 1/2] drm/amdgpu:

Re: [PATCH 3/6] drm: fourcc byteorder: add bigendian support to drm_mode_legacy_fb_format

On Di, 2017-04-25 at 12:18 +0900, Michel Dänzer wrote: > On 24/04/17 03:25 PM, Gerd Hoffmann wrote: > > Return correct fourcc codes on bigendian. Drivers must be adapted to > > this change. > > > > Signed-off-by: Gerd Hoffmann > > Just to reiterate, this won't work for the

Re: [PATCH 3/6] drm: fourcc byteorder: add bigendian support to drm_mode_legacy_fb_format

On 25/04/17 06:52 PM, Ville Syrjälä wrote: > On Tue, Apr 25, 2017 at 12:18:52PM +0900, Michel Dänzer wrote: >> On 24/04/17 03:25 PM, Gerd Hoffmann wrote: >>> +#ifdef __BIG_ENDIAN >>> + switch (bpp) { >>> + case 8: >>> + fmt = DRM_FORMAT_C8; >>> + break; >>> + case 24: >>>

[PATCH 4/5] amdgpu/cs: split out fence dependency checking

From: Dave Airlie This just splits out the fence depenency checking into it's own function to make it easier to add semaphore dependencies. Reviewed-by: Christian König Signed-off-by: Dave Airlie ---

Re: [PATCH] drm/amdgpu: add parameter to allocate high priority contexts v8

On 2017-04-25 06:21 PM, Alex Deucher wrote: On Tue, Apr 25, 2017 at 4:28 PM, Andres Rodriguez wrote: On 2017-04-25 02:01 PM, Nicolai Hähnle wrote: On 24.04.2017 18:20, Andres Rodriguez wrote: Add a new context creation parameter to express a global context priority.

Re: [PATCH] drm/amdgpu: add parameter to allocate high priority contexts v8

On 24.04.2017 18:20, Andres Rodriguez wrote: Add a new context creation parameter to express a global context priority. The priority ranking in descending order is as follows: * AMDGPU_CTX_PRIORITY_HIGH * AMDGPU_CTX_PRIORITY_NORMAL * AMDGPU_CTX_PRIORITY_LOW The driver will attempt to

Re: [PATCH] drm: Harmonize CIK ASIC support in radeon and amdgpu (v2)

On 25.04.2017 08:28, Michel Dänzer wrote: On 22/04/17 02:05 AM, Felix Kuehling wrote: __setup doesn't work in modules. Right. We could build something like drivers/video/fbdev/core/fb_cmdline.c:video_setup() into the kernel to handle this, but it's a bit ugly, which is one reason why I was

[PATCH 00/24] DC Linux Patches Apr 25, 2017

A lot of patches this time around since I haven't gotten around to this for a while. * Clean up contexts in DC in preparation for DC atomic state tracking * Some backports from drm-next tree that won't break on 4.9 * get_atomic_property implementation * Populate YUV plane types in

[PATCH 12/24] drm/amd/display: Parse scanline registers

From: Sylvia Tsai They could differ between ASIC generations Change-Id: Ia352ae206273fe3a025579554cae4e3711a26fcc Signed-off-by: Sylvia Tsai Signed-off-by: Harry Wentland Acked-by: Harry Wentland

[PATCH 16/24] drm/amd/display: Get rid of temp_flip_context

If we need to update our context we can allocate memory. No need to keep temporary memory for this. Change-Id: Ie91d318a1dd2283fe12e5380f015faa866f93230 Signed-off-by: Harry Wentland Acked-by: Harry Wentland Reviewed-by: Tony Cheng

[PATCH 14/24] drm/amd/display: FreeSync LFC MIN/MAX update on current frame

From: Eric Cook - Update BTR/LFC logic so that V_TOTAL_MIN/MAX will take affect on current frame - Add in FreeSync update to MPO code path Change-Id: I12fb498254086fbae8f19b4b3c718104dab62486 Signed-off-by: Eric Cook Acked-by: Harry Wentland

[PATCH 13/24] drm/amd/display: Add support for programming stereo sync

From: Vitaly Prosyak Change-Id: I7e9150b3a2a6aa9c99c84abf2960d3a72f5425ee Signed-off-by: Vitaly Prosyak Acked-by: Harry Wentland Reviewed-by: Charlene Liu ---

[PATCH 09/24] drm/amd/display: Allow planes on all crtcs

4.9 kernel will always add the assigned crtc to possible_crtcs on a plane. This is no longer the case on newer kernels. Make sure we allow any plane on any crtc. Change-Id: I7c6ead102e9c0bb4d98160c344278f76418b1cc6 Signed-off-by: Harry Wentland Acked-by: Harry Wentland

[PATCH 20/24] drm/amd/display: Copy ctx to current_context instead of assign

Change-Id: Iebcdb340c6ff5938886dc69fd6f005c3ab43c6e2 Signed-off-by: Harry Wentland Acked-by: Harry Wentland Reviewed-by: Tony Cheng --- drivers/gpu/drm/amd/display/dc/core/dc.c | 9 - 1 file changed, 4 insertions(+), 5

[PATCH 23/24] drm/amd/display: initialize YUV plane capabilities

From: Shirish S This patch populates the YUV surface configurations. Tests: (On Chromium OS for Stoney Only) builds without any errors. Change-Id: Ie6d6782cfe4b7cc470d27b664fcaf287499c00c6 Signed-off-by: Shirish S Reviewed-by: Tony Cheng

[PATCH 19/24] drm/amd/display: pull commit_surfaces out of atomic_commit into helper function

This should make things simpler when we try to rework this later when we pass validate_context from atomic_check to atomic_commit. Change-Id: Icbf1514abff4b25163f4a54e73f41310e9bc970c Signed-off-by: Harry Wentland Acked-by: Harry Wentland

[PATCH 21/24] drm/amd/display: Move resource_validate_ctx_destruct to dc.h

This will be needed to clean up context once we add it to private atomic state. Change-Id: I8722d0aa9652bf7ea44e7197588f0f8abbaeac58 Signed-off-by: Harry Wentland Acked-by: Harry Wentland Reviewed-by: Tony Cheng ---

[PATCH 17/24] drm/amd/display: update dce8 & 10 bw programming

From: Dmytro Laktyushkin Change-Id: Ie849339294198186c47ce21a26b082edf853762f Signed-off-by: Dmytro Laktyushkin Acked-by: Harry Wentland Reviewed-by: Jordan Lazare ---

[PATCH 11/24] drm/amd/display: use full surface update when stream is NULL

From: Charlene Liu Change-Id: I70cb09ed6bbc3f368aedef36c5a4a4708823606c Signed-off-by: Charlene Liu Acked-by: Harry Wentland Reviewed-by: Tony Cheng --- drivers/gpu/drm/amd/display/dc/core/dc.c

[PATCH 24/24] drm/amd/display: get_atomic_property missing for drm_connector_funcs

From: Pratik Vishwakarma DRM_IOCTL_MODE_GETCONNECTOR fails with EINVAL on enabling DRIVER_ATOMIC With this DRM_IOCTL_MODE_GETCONNECTOR returns all the connector properties. freesync_property and freesync_capable_property return 0 currently. TESTS(On Chromium OS on

[PATCH 22/24] drm/amd/display: Return context from validate_context

This will allow us to carry it from check to commit Change-Id: I367aa586498b2ff1a4bb2527d395a6451054cdf2 Signed-off-by: Harry Wentland Acked-by: Harry Wentland Reviewed-by: Tony Cheng ---

[PATCH 06/24] drm/amd/display: change mpo surface update check condition.

From: Yongqiang Sun Change-Id: If787d1384eae0cdee917effc939464e0abc8453d Signed-off-by: Yongqiang Sun Acked-by: Harry Wentland Reviewed-by: Tony Cheng --- drivers/gpu/drm/amd/display/dc/core/dc.c | 16

[PATCH 05/24] drm/amd/display: Add same check as reset pipes for programing backend regs.

From: Yongqiang Sun Change-Id: I195ba4aa84abbc2cfa3c29fe6b6f98bc65ec72e8 Signed-off-by: Yongqiang Sun Acked-by: Harry Wentland Reviewed-by: Tony Cheng ---

[PATCH 04/24] drm/amd/display: Adding dm controlled signal type in dc_stream

From: Sylvia Tsai - Adding dm controlled signal type in dc_stream - Adding fallback to dvi signal when output signal is hdmi and the connector type is not Change-Id: Iec44e4035f2b9d1fb862a37bbd4e629515a97337 Signed-off-by: Sylvia Tsai Acked-by: Harry

[PATCH 15/24] drm/amd/display: Remove unused scratch_val_ctx

Change-Id: If74542b9c3d69f735147747f4a9bc41b0d70477a Signed-off-by: Harry Wentland Acked-by: Harry Wentland Reviewed-by: Tony Cheng --- drivers/gpu/drm/amd/display/dc/core/dc.c | 3 ---

[PATCH 07/24] drm/amd/display: set NULL value during removal for remoteSink

From: Leon Elazar In MST case during removal of remote sink its descriptor pointer wasn't freed corectly. Change-Id: I1fb201b44cf79d95a02253efe90cf032200c27c3 Signed-off-by: Leon Elazar Acked-by: Harry Wentland Reviewed-by:

[PATCH 10/24] drm/amd/display: Fix missing irq refactor causing potential i2c race

From: Jordan Lazare Change-Id: I3bd022ac9de6a68ba937d4df6396c0c90417eb5c Signed-off-by: Jordan Lazare Reviewed-by: Harry Wentland --- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_types.c | 15 ++- 1 file

[PATCH 08/24] drm/amd/display: Fix for tile MST

From: Ding Wang - Set stream signal type to be SST when setting non-tile timing on MST tiled display. - Disable MST on sink after disabling MST link. - Enable MST on sink before enabling MST link. Change-Id: I809c4fb6b7a83d544c4495230ced16909a7c1bef Signed-off-by: Ding

Re: [PATCH] drm/amdgpu: add parameter to allocate high priority contexts v8

On 2017-04-25 02:01 PM, Nicolai Hähnle wrote: On 24.04.2017 18:20, Andres Rodriguez wrote: Add a new context creation parameter to express a global context priority. The priority ranking in descending order is as follows: * AMDGPU_CTX_PRIORITY_HIGH * AMDGPU_CTX_PRIORITY_NORMAL *

[PATCH] drm/amdgpu: Fix use of interruptible waiting

Either in cgs functions or for callers of cgs functions: 1. The signal interrupt can affect the expected behaviour 2. There is no good mechanism to handle the corresponding error 3. There is no chance of deadlock in these single BO waiting 4. There is no clear benefit for interruptible waiting 5.

[PATCH 1/2] drm/amdgpu: Fix use of interruptible waiting

There is no good mechanism to handle the corresponding error. When signal interrupt happens, unpin is not called. As a result, inside AMDGPU, the statistic of pin size will be wrong. Change-Id: I4a06a227c2757c447cec0058ace4b028553658a2 Signed-off-by: Alex Xie ---

[PATCH 2/2] drm/amdgpu: Fix use of interruptible waiting

1. The wait is short. There is not much benefit by interruptible waiting. 2. In this function and caller functions, the error handling for such interrupt is complicated and risky. Change-Id: I289674ecd3f5ef20c93fe63e33df6d668b3c2edc Signed-off-by: Alex Xie ---

Re: [PATCH] drm: Harmonize CIK ASIC support in radeon and amdgpu (v2)

On 22/04/17 02:05 AM, Felix Kuehling wrote: > __setup doesn't work in modules. Right. We could build something like drivers/video/fbdev/core/fb_cmdline.c:video_setup() into the kernel to handle this, but it's a bit ugly, which is one reason why I was leaning towards: > s8250_options is only

Re: [PATCH 2/2] drm/amd/display: Prevent premature pageflip when comitting in vblank. (v3)

On 25/04/17 01:54 AM, Mario Kleiner wrote: > Make sure we do not program a hw pageflip inside vblank 'n' iff the > atomic flip is comitted while inside the same vblank 'n'. We must > defer such a flip by one refresh cycle to vblank 'n+1', unless this > is a DRM_MODE_PAGE_FLIP_ASYNC async pageflip,

Re: [PATCH 1/2] drm/amdgpu: Real return value can be over-written when clean up

Am 24.04.2017 um 21:34 schrieb Alex Xie: Change-Id: Ib69f035eeb213a1aec5025e0a9f4515065706118 Signed-off-by: Alex Xie Reviewed-by: Christian König --- drivers/gpu/drm/amd/amdgpu/amdgpu_benchmark.c | 9 + 1 file changed, 5

Re: [PATCH 2/2] drm/amdgpu: Fix use of interruptible waiting 1. The signal interrupt can affect the expected behaviour. 2. There is no good mechanism to handle the corresponding error. When signal int

You somehow messed up the commit message. Everything got mangled into the subject line while sending the mails. Apart from that the change looks good to me and with the commit message fixed is Reviewed-by: Christian König Regards, Christian. Am 24.04.2017 um 21:34

Re: [PATCH 1/4] drm/amdgpu: Fix potential issue if reserve function is interrupted If amdgpu_bo_reserve function is interrupted by signal, amdgpu_bo_kunmap function is not called.

All commit messages got mangled into the subject line. You probably forgot the empty line between subject and commit message while creating the commit. With that fixed the whole series is Reviewed-by: Christian König . Regards, Christian. Am 24.04.2017 um 20:29

Re: [PATCH 1/2] drm/amdgpu: fix gpu reset crash

Am 25.04.2017 um 04:20 schrieb zhoucm1: On 2017年04月24日 17:47, Christian König wrote: The root cause is some ring doesn't have scheduler, like KIQ ring Change-Id: I420e84add9cdd9a7fd1f9921b8a5d0afa3dd2058 Signed-off-by: Chunming Zhou Reviewed-by: Christian König

Re: [PATCH] drm/amdgpu: validate shadow before restoring from it

Am 25.04.2017 um 05:16 schrieb zhoucm1: On 2017年04月25日 11:14, Roger.He wrote: Change-Id: Id925f4e241c4192127880d2017fbf2979aa09fc7 Signed-off-by: Roger.He --- drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 33 ++ 1 file changed, 33

Re: amdgpu 0000:84:00.0: gpu post error! \\ Fatal error during GPU init

Hi! I replaced the AMD FirePro S7150X2 card with a AMD Radeon R5 230 (the only other AMD card we had available), to see whether the problem was caused by another hardware component of the system. The kernel boots fine with this card. I see no errors in the log (attached). --Dennis[

RE: [PATCH] drm/amdgpu: validate shadow before restoring from it

-Original Message- From: Christian König [mailto:deathsim...@vodafone.de] Sent: Tuesday, April 25, 2017 4:10 PM To: Zhou, David(ChunMing); He, Hongbo; amd-gfx@lists.freedesktop.org Subject: Re: [PATCH] drm/amdgpu: validate shadow before restoring from it Am 25.04.2017 um 05:16 schrieb

Re: [PATCH 0/6] *** Dedicated vmid per process v2 ***

ping... anyone can give the review? Thanks, David Zhou On 2017年04月24日 13:57, Chunming Zhou wrote: The current kernel implementation, which grabs the idle VMID from pool when emitting the job may: The back-to-back submission from one process could use different VMID. The submission

Re: [PATCH 0/6] drm: tackle byteorder issues, take two

On Tue, Apr 25, 2017 at 09:49:38AM +0900, Michel Dänzer wrote: > On 24/04/17 11:26 PM, Ville Syrjälä wrote: > > On Mon, Apr 24, 2017 at 04:54:25PM +0900, Michel Dänzer wrote: > >> On 24/04/17 04:36 PM, Gerd Hoffmann wrote: > >>> > > drm: fourcc byteorder: add DRM_FORMAT_CPU_* > > drm:

Re: [PATCH 3/6] drm: fourcc byteorder: add bigendian support to drm_mode_legacy_fb_format

On Tue, Apr 25, 2017 at 12:18:52PM +0900, Michel Dänzer wrote: > On 24/04/17 03:25 PM, Gerd Hoffmann wrote: > > Return correct fourcc codes on bigendian. Drivers must be adapted to > > this change. > > > > Signed-off-by: Gerd Hoffmann > > Just to reiterate, this won't work

Re: [PATCH 0/6] *** Dedicated vmid per process v2 ***

On my TODO list, but behind about two or three other items I need to tackle first. Christian. Am 25.04.2017 um 11:07 schrieb zhoucm1: ping... anyone can give the review? Thanks, David Zhou On 2017年04月24日 13:57, Chunming Zhou wrote: The current kernel implementation, which grabs the idle

Re: [PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

On Tue, Apr 25, 2017 at 10:12:37AM +0900, Michel Dänzer wrote: > On 24/04/17 10:03 PM, Ville Syrjälä wrote: > > On Mon, Apr 24, 2017 at 03:57:02PM +0900, Michel Dänzer wrote: > >> On 22/04/17 07:05 PM, Ville Syrjälä wrote: > >>> On Fri, Apr 21, 2017 at 06:14:31PM +0200, Gerd Hoffmann wrote: >

Re: [PATCH 3/4] x86/PCI: Enable a 64bit BAR on AMD Family 15h (Models 30h-3fh) Processors

Am 12.04.2017 um 18:55 schrieb Bjorn Helgaas: [SNIP] I think the specs would envision this being done via an ACPI _SRS method on the PNP0A03 host bridge device. That would be a more generic path that would work on any host bridge. Did you explore that possibility? I would prefer to avoid

RE: [PATCH 1/2] drm/amdgpu: fix gpu reset crash

> -Original Message- > From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf > Of zhoucm1 > Sent: Monday, April 24, 2017 10:20 PM > To: Christian König; amd-gfx@lists.freedesktop.org > Subject: Re: [PATCH 1/2] drm/amdgpu: fix gpu reset crash > > > > On 2017年04月24日

RE: amdgpu 0000:84:00.0: gpu post error! \\ Fatal error during GPU init

> -Original Message- > From: Dennis Schridde [mailto:dennis.schri...@uni-heidelberg.de] > Sent: Tuesday, April 25, 2017 6:31 AM > To: amd-gfx@lists.freedesktop.org > Cc: Deucher, Alexander > Subject: Re: amdgpu :84:00.0: gpu post error! \\ Fatal error during GPU > init > > On