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
(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,
> 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,
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
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
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
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 |
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 +-
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
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
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
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
---
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
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
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:
*
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
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
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
> -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:
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;
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;
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
->
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:
>
> *
>
23 matches
Mail list logo