Re: [RFC] Using DC in amdgpu for upcoming GPU

2016-12-12 Thread Daniel Vetter
On Mon, Dec 12, 2016 at 11:10:30PM -0500, Cheng, Tony wrote: > Thanks for the write up for the guide. We can definitely re-do atomic > according to guideline provided as I am not satified with how our code look > today. To me it seems more like we need to shuffle stuff around and rename > a few

Re: [RFC] Using DC in amdgpu for upcoming GPU

2016-12-12 Thread Dave Airlie
(hit send too early) > We would love to upstream DC for all supported asic! We made enough change > to make Sea Island work but it's really not validate to the extend we > validate Polaris on linux and no where close to what we do for 2017 ASICs. > With DC the display hardware programming,

Re: [RFC] Using DC in amdgpu for upcoming GPU

2016-12-12 Thread Dave Airlie
> We would love to upstream DC for all supported asic! We made enough change > to make Sea Island work but it's really not validate to the extend we > validate Polaris on linux and no where close to what we do for 2017 ASICs. > With DC the display hardware programming, resource optimization,

Re: some minor dal cleanups and example of future patches

2016-12-12 Thread Dave Airlie
On 13 December 2016 at 16:41, Dave Airlie wrote: > So whenever I look at DAL I find myself trying to figure out what > all of it does, and this leads me to deleting things, so I'm just > sending out some stuff that I cleaned today. > > One thing I noticed in passing is the

[PATCH 6/8] drm/dp-helper: add missing defines needed by AMD display core.

2016-12-12 Thread Dave Airlie
From: Dave Airlie These are all the ones required by the AMD display core. Signed-off-by: Dave Airlie --- include/drm/drm_dp_helper.h | 20 1 file changed, 20 insertions(+) diff --git a/include/drm/drm_dp_helper.h

some minor dal cleanups and example of future patches

2016-12-12 Thread Dave Airlie
So whenever I look at DAL I find myself trying to figure out what all of it does, and this leads me to deleting things, so I'm just sending out some stuff that I cleaned today. One thing I noticed in passing is the displayport code seems possibly endian unsafe, it casts bytes read from hardware

[PATCH 1/8] dc: remove dc hub - this seems unused.

2016-12-12 Thread Dave Airlie
From: Dave Airlie Signed-off-by: Dave Airlie --- drivers/gpu/drm/amd/display/dc/core/dc.c | 27 -- drivers/gpu/drm/amd/display/dc/dc.h| 17 -- .../drm/amd/display/dc/dce110/dce110_mem_input.c |

[PATCH 7/8] dal: port to using drm dpcd defines

2016-12-12 Thread Dave Airlie
From: Dave Airlie We only keep one list of these defines in the kernel, so we should use it. Signed-off-by: Dave Airlie --- drivers/gpu/drm/amd/display/dc/core/dc_link.c | 8 +- drivers/gpu/drm/amd/display/dc/core/dc_link_ddc.c | 2 +-

[PATCH 8/8] dal: assign correct enum for edp revision

2016-12-12 Thread Dave Airlie
From: Dave Airlie There are 2 edp enum revisions, no idea why, drop one, and just assign 1.1 to the default value. Signed-off-by: Dave Airlie --- drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c | 2 +- drivers/gpu/drm/amd/display/include/dpcd_defs.h

[PATCH 2/8] dal: remove some unused wrappers

2016-12-12 Thread Dave Airlie
From: Dave Airlie Signed-off-by: Dave Airlie --- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_services.c | 4 1 file changed, 4 deletions(-) diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_services.c

[PATCH 4/8] dal: drop get platform info

2016-12-12 Thread Dave Airlie
From: Dave Airlie Signed-off-by: Dave Airlie --- .../drm/amd/display/amdgpu_dm/amdgpu_dm_services.c | 7 - drivers/gpu/drm/amd/display/dc/dm_services.h | 32 -- 2 files changed, 39 deletions(-) diff --git

[PATCH 3/8] dal: drop register logger and pid/tgid getters

2016-12-12 Thread Dave Airlie
From: Dave Airlie While I'm sure this is useful I think we should bring it back later. It's usage of pid/tgid is incorrect, you have to get/put pid/tgids not store them away. Signed-off-by: Dave Airlie ---

[PATCH 5/8] dal: drop setmode complete notifier

2016-12-12 Thread Dave Airlie
From: Dave Airlie Signed-off-by: Dave Airlie --- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_services.c | 13 - 1 file changed, 13 deletions(-) diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_services.c

Re: [RFC] Using DC in amdgpu for upcoming GPU

2016-12-12 Thread Harry Wentland
On 2016-12-11 03:28 PM, Daniel Vetter wrote: On Wed, Dec 07, 2016 at 09:02:13PM -0500, Harry Wentland wrote: We propose to use the Display Core (DC) driver for display support on AMD's upcoming GPU (referred to by uGPU in the rest of the doc). In order to avoid a flag day the plan is to only

Re: [RFC] Using DC in amdgpu for upcoming GPU

2016-12-12 Thread Harry Wentland
On 2016-12-12 02:22 AM, Daniel Vetter wrote: On Wed, Dec 07, 2016 at 09:02:13PM -0500, Harry Wentland wrote: Current version of DC: * https://cgit.freedesktop.org/~agd5f/linux/tree/drivers/gpu/drm/amd/display?h=amd-staging-4.7 Once Alex pulls in the latest patches: *

[PATCH] amdgpu: get maximum and used UVD handles

2016-12-12 Thread arindam . nath
From: Arindam Nath User might want to query the maximum number of UVD instances supported by firmware. In addition to that, if there are multiple applications using UVD handles at the same time, he might also want to query the currently used number of handles. For this we

[PATCH 1/1] drm/amd/amdgpu: get maximum and used UVD handles (v3)

2016-12-12 Thread arindam . nath
From: Arindam Nath Change History -- v3: changes suggested by Christian - Add a check for UVD IP block using AMDGPU_HW_IP_UVD query type. - Add a check for asic_type to be less than CHIP_POLARIS10 since starting Polaris, we support unlimited UVD

Re: Raciness with page table shadows being swapped out

2016-12-12 Thread Christian König
Am 12.12.2016 um 16:20 schrieb Nicolai Hähnle: Hi all, I just sent out two patches that hopefully make the kernel module more robust in the face of page table shadows being swapped out. However, even with those patches, I can still fairly reliably reproduce crashes with a backtrace of the

RE: [RFC] Using DC in amdgpu for upcoming GPU

2016-12-12 Thread Deucher, Alexander
> -Original Message- > From: Luke A. Guest [mailto:lagu...@archeia.com] > Sent: Monday, December 12, 2016 11:17 AM > To: Deucher, Alexander; 'Daniel Vetter'; Bridgman, John > Cc: Grodzovsky, Andrey; Cheng, Tony; amd-gfx@lists.freedesktop.org; dri- > de...@lists.freedesktop.org > Subject:

Re: [RFC] Using DC in amdgpu for upcoming GPU

2016-12-12 Thread Luke A. Guest
On 12/12/16 15:28, Deucher, Alexander wrote: >> -Original Message- >> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf >> Of Daniel Vetter >> Sent: Monday, December 12, 2016 4:27 AM >> To: Bridgman, John >> Cc: Grodzovsky, Andrey; Cheng, Tony;

Re: [RFC] Using DC in amdgpu for upcoming GPU

2016-12-12 Thread Luke A. Guest
On 12/12/16 15:28, Deucher, Alexander wrote: >> -Original Message- >> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf >> Of Daniel Vetter >> Sent: Monday, December 12, 2016 4:27 AM >> To: Bridgman, John >> Cc: Grodzovsky, Andrey; Cheng, Tony;

Raciness with page table shadows being swapped out

2016-12-12 Thread Nicolai Hähnle
Hi all, I just sent out two patches that hopefully make the kernel module more robust in the face of page table shadows being swapped out. However, even with those patches, I can still fairly reliably reproduce crashes with a backtrace of the shape amdgpu_cs_ioctl ->

Re: [RFC] Using DC in amdgpu for upcoming GPU

2016-12-12 Thread Daniel Vetter
On Wed, Dec 07, 2016 at 09:02:13PM -0500, Harry Wentland wrote: > Current version of DC: > > * > https://cgit.freedesktop.org/~agd5f/linux/tree/drivers/gpu/drm/amd/display?h=amd-staging-4.7 > > Once Alex pulls in the latest patches: > > * >