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

On Mon, Dec 12, 2016 at 09:05:15PM -0500, Harry Wentland wrote: > > 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: > > > > > > * > > >

Re: [PATCH 2/2] drm/amdgpu: fix cursor setting of dce6/dce8

On 14/12/16 03:45 PM, Flora Cui wrote: > Change-Id: Ic900051ece1bf7aaf01b3811dde4cbe426be8b42 > Signed-off-by: Flora Cui > --- > drivers/gpu/drm/amd/amdgpu/dce_v6_0.c | 6 +- > drivers/gpu/drm/amd/amdgpu/dce_v8_0.c | 2 -- > 2 files changed, 1 insertion(+), 7 deletions(-)

[PATCH 2/2] drm/amdgpu: fix cursor setting of dce6/dce8

Change-Id: Ic900051ece1bf7aaf01b3811dde4cbe426be8b42 Signed-off-by: Flora Cui --- drivers/gpu/drm/amd/amdgpu/dce_v6_0.c | 6 +- drivers/gpu/drm/amd/amdgpu/dce_v8_0.c | 2 -- 2 files changed, 1 insertion(+), 7 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c

Re: [PATCH] udev_monitor_receive_device() will block when hotplug monitor

On 13/12/16 05:33 PM, jimqu wrote: > udev_monitor_receive_device() will block and wait for the event of udev > use select() to ensure that this will not block. > > Change-Id: I4e8f4629580222e94f55a4c03070741bf5f4024c > Signed-off-by: JimQu Reviewed and pushed, thanks! P.S.

答复: [PATCH] udev_monitor_receive_device() will block when hotplug monitor

Got it! Thanks JimQu 发件人: Michel Dänzer 发送时间: 2016年12月14日 11:03 收件人: Qu, Jim 抄送: amd-gfx@lists.freedesktop.org 主题: Re: [PATCH] udev_monitor_receive_device() will block when hotplug monitor On 13/12/16 05:33 PM, jimqu wrote: >

Re: Raciness with page table shadows being swapped out

Am 13.12.2016 um 00:35 schrieb Nicolai Hähnle: On 12.12.2016 19:22, Christian König wrote: 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

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

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. With DC

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

Hi Harry, I've been loathe to jump in here, not least because both cop roles seem to be taken, but ... On 13 December 2016 at 01:49, Harry Wentland wrote: > On 2016-12-11 09:57 PM, Dave Airlie wrote: >> On 8 December 2016 at 12:02, Harry Wentland

[PATCH] udev_monitor_receive_device() will block when hotplug monitor

udev_monitor_receive_device() will block and wait for the event of udev use select() to ensure that this will not block. Change-Id: I4e8f4629580222e94f55a4c03070741bf5f4024c Signed-off-by: JimQu --- src/drmmode_display.c | 22 +++--- 1 file changed, 19

Re: Raciness with page table shadows being swapped out

On 13.12.2016 10:48, Christian König wrote: The attached patch has fixed these crashes for me so far, but it's very heavy-handed: it collects all page table shadows and the page directory shadow and adds them all to the reservations for the callers of amdgpu_vm_update_page_directory. That is

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

On Tue, Dec 13, 2016 at 10:03:58AM -0500, Cheng, Tony wrote: > On 12/13/2016 4:40 AM, Lukas Wunner wrote: > > If the Linux community contributes to DC, I guess those contributions > > can generally be assumed to be GPLv2 licensed. Yet a future version > > of the macOS driver would incorporate

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

Only DM that’s open source is amdgpu_dm.the rest will remain closed source.I remember we had discussion around legal issues with our grand plan of unifying everything, and I remember maybe it was John who assured us that it's okay.John can you chime in how it would work with GPLv2 licsense?

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

On Tue, Dec 13, 2016 at 12:22:59PM +, Daniel Stone wrote: > Hi Harry, > I've been loathe to jump in here, not least because both cop roles > seem to be taken, but ... > > On 13 December 2016 at 01:49, Harry Wentland wrote: > > On 2016-12-11 09:57 PM, Dave Airlie

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

On Mon, Dec 12, 2016 at 11:10 PM, Cheng, Tony wrote: > We need to treat most of resource that don't map well as global. One example > is pixel pll. We have 6 display pipes but only 2 or 3 plls in CI/VI, as a > result we are limited in number of HDMI or DVI we can drive at the

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

>>If the Linux community contributes to DC, I guess those contributions can generally be assumed to be GPLv2 licensed. Yet a future version of the macOS driver would incorporate those contributions in the same binary as their closed source OS-specific portion. My understanding of the "general