> -Original Message-
> From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf
> Of Daniel Vetter
> Sent: Monday, January 23, 2017 3:55 AM
> To: Grodzovsky, Andrey
> Cc: Deucher, Alexander ;
> nouv...@lists.freedesktop.org; amd-...@lists.freedesktop.org; dri-
> de...@l
Thanks Alex my reply was a little off topic :)
-Original Message-
From: Alex Deucher [mailto:alexdeuc...@gmail.com]
Sent: Wednesday, December 14, 2016 1:02 PM
To: Cheng, Tony
Cc: Jani Nikula ; Lukas Wunner ; Bridgman, John ; Deucher, Alexander
; Grodzovsky, Andrey ; amd-gfx mailing
On 12/14/2016 4:57 AM, Jani Nikula wrote:
> On Tue, 13 Dec 2016, "Cheng, Tony" wrote:
>> I am struggling with that these comminty contributions to DC would be.
>>
>> Us AMD developer has access to HW docs and designer and we are still
>> spending 50% of our
sense?
On 12/13/2016 4:40 AM, Lukas Wunner wrote:
> On Mon, Dec 12, 2016 at 09:52:08PM -0500, Cheng, Tony wrote:
>> With DC the display hardware programming, resource optimization, power
>> management and interaction with rest of system will be fully validated
>> across multi
On 12/13/2016 2:30 AM, Dave Airlie wrote:
> (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.
>>
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 things than rewrite much of anything.
I hope to get an answer on t
On 12/11/2016 9:57 PM, Dave Airlie wrote:
> On 8 December 2016 at 12:02, 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 support
> Merging this code as well as maintaining a trust relationship with
> Linus, also maintains a trust relationship with the Linux graphics
> community and other drm contributors. There have been countless
> requests from various companies and contributors to merge unsavoury
> things over the yea
> Merging this code as well as maintaining a trust relationship with
> Linus, also maintains a trust relationship with the Linux graphics
> community and other drm contributors. There have been countless
> requests from various companies and contributors to merge unsavoury
> things over the yea
Acked-by: Tony Cheng
-Original Message-
From: Manasi Navare [mailto:manasi.d.nav...@intel.com]
Sent: Monday, November 14, 2016 12:52 PM
To: Cheng, Tony
Cc: Daniel Vetter ; intel-gfx at lists.freedesktop.org;
Peres, Martin ; dri-devel at lists.freedesktop.org;
Deucher, Alexander
...@ffwll.ch] On Behalf Of Daniel Vetter
Sent: Monday, November 14, 2016 3:04 AM
To: Manasi Navare
Cc: Cheng, Tony ; intel-gfx at lists.freedesktop.org;
Peres, Martin ; dri-devel at lists.freedesktop.org;
Deucher, Alexander ; Wentland, Harry
Subject: Re: [Intel-gfx] [PATCH 0/5] Handle Link Training
:44 AM
To: Cheng, Tony
Cc: Deucher, Alexander ; 'Jani Nikula'
; Manasi Navare ;
dri-devel at lists.freedesktop.org; intel-gfx at lists.freedesktop.org;
Wentland, Harry ; Peres, Martin
Subject: Re: [Intel-gfx] [PATCH 0/5] Handle Link Training Failure during modeset
On Fri, Nov 11, 201
on them.
windows does not know link state and all link management is hidden behind
kernel driver.
-Original Message-
From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
Sent: Friday, November 11, 2016 9:05 AM
To: Cheng, Tony
Cc: Deucher, Alexander ; 'Jani Nikula'
:43 PM
To: 'Jani Nikula' ; Manasi Navare
; dri-devel at lists.freedesktop.org; intel-gfx
at lists.freedesktop.org; Wentland, Harry ; Cheng,
Tony
Cc: Dave Airlie ; Peres, Martin
Subject: RE: [Intel-gfx] [PATCH 0/5] Handle Link Training Failure during modeset
Adding Harry and Tony from o
14 matches
Mail list logo
