Re: [PATCH] drm/amd/powerplay: fix a signedness bugs

2017-05-22 Thread Zhu, Rex 
Patches has been applied.


Thanks.


Best Regards

Rex


From: Huang, JinHuiEric
Sent: Friday, May 19, 2017 12:28:09 AM
To: Dan Carpenter; Deucher, Alexander; Zhu, Rex
Cc: Koenig, Christian; David Airlie; Wang, Ken; Huang, Ray; 
amd-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org; 
kernel-janit...@vger.kernel.org
Subject: Re: [PATCH] drm/amd/powerplay: fix a signedness bugs

Reviewed-by: Eric Huang 


On 2017-05-16 10:42 AM, Dan Carpenter wrote:
> Smatch complains about a signedness bug here:
>
>vega10_hwmgr.c:4202 vega10_force_clock_level()
>warn: always true condition '(i >= 0) => (0-u32max >= 0)'
>
> Fixes: 7b52db39a4c2 ("drm/amd/powerplay: fix bug sclk/mclk level can't be set 
> on vega10.")
> Signed-off-by: Dan Carpenter 
>
> diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c 
> b/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c
> index ad30f5d3a10d..2614af2f553f 100644
> --- a/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c
> +++ b/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c
> @@ -4186,7 +4186,7 @@ static int vega10_force_clock_level(struct pp_hwmgr 
> *hwmgr,
>enum pp_clock_type type, uint32_t mask)
>   {
>struct vega10_hwmgr *data = (struct vega10_hwmgr *)(hwmgr->backend);
> - uint32_t i;
> + int i;
>
>if (hwmgr->dpm_level != AMD_DPM_FORCED_LEVEL_MANUAL)
>return -EINVAL;

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH] drm/radeon: Fix oops upon driver load on PowerXpress laptops

2017-05-22 Thread Michel Dänzer 
On 23/05/17 12:50 PM, Lukas Wunner wrote:
> On Tue, May 23, 2017 at 12:09:49PM +0900, Michel Dänzer wrote:
>> On 22/05/17 11:04 PM, Lukas Wunner wrote:
>>> On Sun, May 21, 2017 at 09:31:09AM +0200, Nicolai Stange wrote:
 On Thu, May 18 2017, Lukas Wunner wrote:
>>> [snip]
> Reported-by: Nicolai Stange 
> Fixes: 7ffb0ce31cf9 ("drm/radeon: Don't register Thunderbolt eGPU with 
> vga_switcheroo")
> Signed-off-by: Lukas Wunner 
> ---
>
> Awaiting a Tested-by: from Nicolai, but it's clear this is a bug and
> needs to be fixed, so sending out with a proper commit message now.
> The bug was only introduced to radeon, not amdgpu.

 Tested-by: Nicolai Stange 

 Thanks for the quick fix!

> @Alex Deucher: I could push this to drm-misc-fixes but then it wouldn't
> land before -rc3 because Sean Paul has already sent out the -rc2 pull.
> I notice you haven't sent out a pull for -rc2 yet, so maybe you want to
> take it yourself?  Whichever you prefer.  Thanks & sorry for the breakage!
>>>
>>> I've learned this morning that Alex is on vacation.
>>
>> Christian König is standing in for Alex.
> 
> By his own account, he already has "all hands full replacing him [Alex]",
> explicitly asked Daniel to merge an amdgpu patch through drm-misc-next for
> this reason and lacks permission to update branches in Alex' repo on fdo:
> 
> "One lesson learned from the past week is that Alex needs to stop using
> his personal repository on fdo.
> We were asked a couple of times if I couldn't update a branch there from 
> different directions, which we obviously can't do."
> 
> https://lists.freedesktop.org/archives/dri-devel/2017-May/142376.html
> https://lists.freedesktop.org/archives/dri-devel/2017-May/142380.html

The important point being that Christian reviewed that patch and
explicitly asked Daniel to pick it up.


>>> I've pushed the patch to drm-misc-fixes so that the issue is fixed in
>>> 4.12-rc3.
>>
>> I don't think there was any particular need to bypass the normal radeon
>> tree for this. There was plenty of time for the fix to get into 4.12
>> final, even after Alex is back.
> 
> Well, it wouldn't be nice towards users affected by the same issue
> who may waste time with bisecting to just sit on a fix twiddling thumbs.

We all tend to think our latest fix is the most important one. :) But I
really don't see this one being special.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH] drm/radeon: Fix oops upon driver load on PowerXpress laptops

2017-05-22 Thread Lukas Wunner 
On Tue, May 23, 2017 at 12:09:49PM +0900, Michel Dänzer wrote:
> On 22/05/17 11:04 PM, Lukas Wunner wrote:
> > On Sun, May 21, 2017 at 09:31:09AM +0200, Nicolai Stange wrote:
> >> On Thu, May 18 2017, Lukas Wunner wrote:
> > [snip]
> >>> Reported-by: Nicolai Stange 
> >>> Fixes: 7ffb0ce31cf9 ("drm/radeon: Don't register Thunderbolt eGPU with 
> >>> vga_switcheroo")
> >>> Signed-off-by: Lukas Wunner 
> >>> ---
> >>>
> >>> Awaiting a Tested-by: from Nicolai, but it's clear this is a bug and
> >>> needs to be fixed, so sending out with a proper commit message now.
> >>> The bug was only introduced to radeon, not amdgpu.
> >>
> >> Tested-by: Nicolai Stange 
> >>
> >> Thanks for the quick fix!
> >>
> >>> @Alex Deucher: I could push this to drm-misc-fixes but then it wouldn't
> >>> land before -rc3 because Sean Paul has already sent out the -rc2 pull.
> >>> I notice you haven't sent out a pull for -rc2 yet, so maybe you want to
> >>> take it yourself?  Whichever you prefer.  Thanks & sorry for the breakage!
> > 
> > I've learned this morning that Alex is on vacation.
> 
> Christian König is standing in for Alex.

By his own account, he already has "all hands full replacing him [Alex]",
explicitly asked Daniel to merge an amdgpu patch through drm-misc-next for
this reason and lacks permission to update branches in Alex' repo on fdo:

"One lesson learned from the past week is that Alex needs to stop using
his personal repository on fdo.
We were asked a couple of times if I couldn't update a branch there from 
different directions, which we obviously can't do."

https://lists.freedesktop.org/archives/dri-devel/2017-May/142376.html
https://lists.freedesktop.org/archives/dri-devel/2017-May/142380.html


> > I've pushed the patch to drm-misc-fixes so that the issue is fixed in
> > 4.12-rc3.
> 
> I don't think there was any particular need to bypass the normal radeon
> tree for this. There was plenty of time for the fix to get into 4.12
> final, even after Alex is back.

Well, it wouldn't be nice towards users affected by the same issue
who may waste time with bisecting to just sit on a fix twiddling thumbs.

Thanks,

Lukas
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH] drm/radeon: Fix oops upon driver load on PowerXpress laptops

2017-05-22 Thread Michel Dänzer 
On 22/05/17 11:04 PM, Lukas Wunner wrote:
> On Sun, May 21, 2017 at 09:31:09AM +0200, Nicolai Stange wrote:
>> On Thu, May 18 2017, Lukas Wunner wrote:
> [snip]
>>> Reported-by: Nicolai Stange 
>>> Fixes: 7ffb0ce31cf9 ("drm/radeon: Don't register Thunderbolt eGPU with 
>>> vga_switcheroo")
>>> Signed-off-by: Lukas Wunner 
>>> ---
>>>
>>> Awaiting a Tested-by: from Nicolai, but it's clear this is a bug and
>>> needs to be fixed, so sending out with a proper commit message now.
>>> The bug was only introduced to radeon, not amdgpu.
>>
>> Tested-by: Nicolai Stange 
>>
>> Thanks for the quick fix!
>>
>>> @Alex Deucher: I could push this to drm-misc-fixes but then it wouldn't
>>> land before -rc3 because Sean Paul has already sent out the -rc2 pull.
>>> I notice you haven't sent out a pull for -rc2 yet, so maybe you want to
>>> take it yourself?  Whichever you prefer.  Thanks & sorry for the breakage!
> 
> I've learned this morning that Alex is on vacation.

Christian König is standing in for Alex.

> I've pushed the patch to drm-misc-fixes so that the issue is fixed in
> 4.12-rc3.

I don't think there was any particular need to bypass the normal radeon
tree for this. There was plenty of time for the fix to get into 4.12
final, even after Alex is back.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH 0/3] drm/amdgpu: Tweaks for high pressure on CPU visible VRAM

2017-05-22 Thread Michel Dänzer 
On 22/05/17 07:09 PM, Marek Olšák wrote:
> On Mon, May 22, 2017 at 12:00 PM, Michel Dänzer  wrote:
>> On 20/05/17 06:26 PM, Marek Olšák wrote:
>>> On May 20, 2017 3:26 AM, "Michel Dänzer" >> > wrote:
>>>
>>> On 20/05/17 01:14 AM, Marek Olšák wrote:
>>> > Hi Michel,
>>> >
>>> > I've applied your series
>>>
>>> Thanks for testing it.
>>>
>>> > and it doesn't help with low Dirt Rally performance on Fiji. I see TTM
>>> > buffer moves at 800MB/s and many VRAM page faults.
>>>
>>> Did you see this:
>>>
>>> >> Note that there's only little if any improvement of the average
>>> framerate
>>> >> reported, but the minimum framerate as seen on the HUD goes from
>>> ~10 fps
>>> >> to ~17.
>>>
>>> I.e. it mostly affects the minimum framerate and smoothness for me
>>> as well.
>>>
>>>
>>> Without the series, I get 70 average fps. With the series, I get 30
>>> average fps. That might just be random bad luck. I don't know.
>>
>> Hmm, yeah, maybe that was just one of the random slowdowns you've been
>> talking about in other threads and on IRC?
>>
>> I can't reproduce any slowdown with these patches, even leaving visible
>> VRAM size at 256 MB.
> 
> The random slowdowns with Dirt Rally are only caused by the pressure
> on visible VRAM. This whole thread is about those random slowdowns.

No, this thread is about the scenario described in the cover letter of
this patch series.


> If you're saying "maybe it was just one of the random slowdowns", you're
> saying "maybe it was just the visible VRAM pressure". It's only
> random with Dirt Rally, which makes it difficult to believe statements
> such as "I can't reproduce any slowdown".

I could say the same thing about you seeing random slowdowns... I've
never seen that, I had to artificially limit the size of visible VRAM to
64 MB to make it significantly affect the benchmark result.

How many times do you need to run the benchmark on average to hit a
random slowdown? Which desktop environment and other X clients are
running during the benchmark? Which tab is active in the Steam window
while the benchmark runs?

In my case, it's only xfwm4, xterm and steam on the Dirt Rally page in
the library.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH] drm/radeon: Fix oops upon driver load on PowerXpress laptops

2017-05-22 Thread Sean Paul 
On Mon, May 22, 2017 at 04:04:07PM +0200, Lukas Wunner wrote:
> On Sun, May 21, 2017 at 09:31:09AM +0200, Nicolai Stange wrote:
> > On Thu, May 18 2017, Lukas Wunner wrote:
> [snip]
> > > Reported-by: Nicolai Stange 
> > > Fixes: 7ffb0ce31cf9 ("drm/radeon: Don't register Thunderbolt eGPU with 
> > > vga_switcheroo")
> > > Signed-off-by: Lukas Wunner 
> > > ---
> > >
> > > Awaiting a Tested-by: from Nicolai, but it's clear this is a bug and
> > > needs to be fixed, so sending out with a proper commit message now.
> > > The bug was only introduced to radeon, not amdgpu.
> > 
> > Tested-by: Nicolai Stange 
> > 
> > Thanks for the quick fix!
> >
> > > @Alex Deucher: I could push this to drm-misc-fixes but then it wouldn't
> > > land before -rc3 because Sean Paul has already sent out the -rc2 pull.
> > > I notice you haven't sent out a pull for -rc2 yet, so maybe you want to
> > > take it yourself?  Whichever you prefer.  Thanks & sorry for the breakage!
> 
> I've learned this morning that Alex is on vacation.  I've pushed
> the patch to drm-misc-fixes so that the issue is fixed in 4.12-rc3.
> 
> @Sean Paul: I've fast-forwarded to 4.12-rc2 before pushing, please
> shout if I've done anything wrong.  First time I'm doing this.

No shouting, but a heads-up on IRC is probably warranted for both pushing a
patch without R-b and fast-forwarding one of the branches.

Sean

> 
> Thanks,
> 
> Lukas
> 
> > >
> > >  drivers/gpu/drm/radeon/radeon_kms.c | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/radeon/radeon_kms.c 
> > > b/drivers/gpu/drm/radeon/radeon_kms.c
> > > index 6a68d440bc44..d0ad03674250 100644
> > > --- a/drivers/gpu/drm/radeon/radeon_kms.c
> > > +++ b/drivers/gpu/drm/radeon/radeon_kms.c
> > > @@ -116,7 +116,7 @@ int radeon_driver_load_kms(struct drm_device *dev, 
> > > unsigned long flags)
> > >   if ((radeon_runtime_pm != 0) &&
> > >   radeon_has_atpx() &&
> > >   ((flags & RADEON_IS_IGP) == 0) &&
> > > - !pci_is_thunderbolt_attached(rdev->pdev))
> > > + !pci_is_thunderbolt_attached(dev->pdev))
> > >   flags |= RADEON_IS_PX;
> > >  
> > >   /* radeon_device_init should report only fatal error

-- 
Sean Paul, Software Engineer, Google / Chromium OS
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH] drm/radeon: Fix oops upon driver load on PowerXpress laptops

2017-05-22 Thread Daniel Vetter 
On Thu, May 18, 2017 at 09:33:44PM +0200, Lukas Wunner wrote:
> Nicolai Stange reports the following oops which is caused by
> dereferencing rdev->pdev before it's subsequently set by
> radeon_device_init().  Fix it.
> 
>   BUG: unable to handle kernel NULL pointer dereference at 07cb
>   IP: radeon_driver_load_kms+0xeb/0x230 [radeon]
>   PGD 0
>   P4D 0
> 
>   Oops:  [#1] SMP
>   Modules linked in: amdkfd amd_iommu_v2 i915(+) radeon(+) i2c_algo_bit 
> drm_kms_helper ttm e1000e drm sdhci_pci sdhci_acpi ptp sdhci crc32c_intel 
> serio_raw mmc_core pps_core video i2c_hid hid_plantronics
>   CPU: 4 PID: 389 Comm: systemd-udevd Not tainted 4.12.0-rc1-next-20170515+ #1
>   Hardware name: Dell Inc. Latitude E6540/0725FP, BIOS A10 06/26/2014
>   task: 97d62c8f task.stack: b96f01478000
>   RIP: 0010:radeon_driver_load_kms+0xeb/0x230 [radeon]
>   RSP: 0018:b96f0147b9d0 EFLAGS: 00010246
>   RAX:  RBX: 97d620085000 RCX: 00610037
>   RDX:  RSI: 002b RDI: 
>   RBP: b96f0147b9e8 R08: 0002 R09: b96f0147b924
>   R10:  R11: 97d62edd2ec0 R12: 97d628d5c000
>   R13: 00610037 R14: c0698280 R15: 
>   FS:  7f496363d8c0() GS:97d62eb0() knlGS:
>   CS:  0010 DS:  ES:  CR0: 80050033
>   CR2: 07cb CR3: 00022c14c000 CR4: 001406e0
>   Call Trace:
>drm_dev_register+0x146/0x1d0 [drm]
>drm_get_pci_dev+0x9a/0x180 [drm]
>radeon_pci_probe+0xb8/0xe0 [radeon]
>local_pci_probe+0x45/0xa0
>pci_device_probe+0x14f/0x1a0
>driver_probe_device+0x29c/0x450
>__driver_attach+0xdf/0xf0
>? driver_probe_device+0x450/0x450
>bus_for_each_dev+0x6c/0xc0
>driver_attach+0x1e/0x20
>bus_add_driver+0x170/0x270
>driver_register+0x60/0xe0
>? 0xc0508000
>__pci_register_driver+0x4c/0x50
>drm_pci_init+0xeb/0x100 [drm]
>? vga_switcheroo_register_handler+0x6a/0x90
>? 0xc0508000
>radeon_init+0x98/0xb6 [radeon]
>do_one_initcall+0x52/0x1a0
>? __vunmap+0x81/0xb0
>? kmem_cache_alloc_trace+0x159/0x1b0
>? do_init_module+0x27/0x1f8
>do_init_module+0x5f/0x1f8
>load_module+0x27ce/0x2be0
>SYSC_finit_module+0xdf/0x110
>? SYSC_finit_module+0xdf/0x110
>SyS_finit_module+0xe/0x10
>do_syscall_64+0x67/0x150
>entry_SYSCALL64_slow_path+0x25/0x25
>   RIP: 0033:0x7f4962295679
>   RSP: 002b:7ffdd8c4f878 EFLAGS: 0246 ORIG_RAX: 0139
>   RAX: ffda RBX: 55c014ed8200 RCX: 7f4962295679
>   RDX:  RSI: 7f4962dd19c5 RDI: 0010
>   RBP: 7f4962dd19c5 R08:  R09: 7ffdd8c4f990
>   R10: 0010 R11: 0246 R12: 
>   R13: 55c014ed81a0 R14: 0002 R15: 55c0149d1fca
>   Code: 5d 5d c3 8b 05 a7 05 14 00 49 81 cd 00 00 08 00 85 c0 74 a3 e8 e7 c0 
> 0e 00 84 c0 74 9a 41 f7 c5 00 00 02 00 75 91 49 8b 44 24 10 <0f> b6 90 cb 07 
> 00 00 f6 c2 20 74 1e e9 7b ff ff ff 48 8b 40 38
>   RIP: radeon_driver_load_kms+0xeb/0x230 [radeon] RSP: b96f0147b9d0
>   CR2: 07cb
>   ---[ end trace 89cc4ba7e569c65c ]---
> 
> Reported-by: Nicolai Stange 
> Fixes: 7ffb0ce31cf9 ("drm/radeon: Don't register Thunderbolt eGPU with 
> vga_switcheroo")
> Signed-off-by: Lukas Wunner 
> ---
> 
> Awaiting a Tested-by: from Nicolai, but it's clear this is a bug and
> needs to be fixed, so sending out with a proper commit message now.
> The bug was only introduced to radeon, not amdgpu.
> 
> @Alex Deucher: I could push this to drm-misc-fixes but then it wouldn't
> land before -rc3 because Sean Paul has already sent out the -rc2 pull.
> I notice you haven't sent out a pull for -rc2 yet, so maybe you want to
> take it yourself?  Whichever you prefer.  Thanks & sorry for the breakage!

Just noticed that this has landed already in drm-misc-fixes, without any
r-b or at least an ack from radeon driver folks. That's breaking the
drm-misc rules, we need at least an ack for small drivers (which radeon
really isn't) and a full reviewed-by tag on everything else.

Patch doesn't look wrong, so not much harm, but please follow the ground
rules and especially don't ever push your own patches without any peer
feedback.

Thanks, Daniel

> 
>  drivers/gpu/drm/radeon/radeon_kms.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/radeon/radeon_kms.c 
> b/drivers/gpu/drm/radeon/radeon_kms.c
> index 6a68d440bc44..d0ad03674250 100644
> --- a/drivers/gpu/drm/radeon/radeon_kms.c
> +++ b/drivers/gpu/drm/radeon/radeon_kms.c
> @@ -116,7 +116,7 @@ int radeon_driver_load_kms(struct drm_device *dev, 
> unsigned long flags)
>   if ((radeon_runtime_pm != 0) &&
>   radeon_has_atpx() &&
>   ((flags & RADEON_IS_IGP) == 0) &&
> -

RE: [PATCH] drm/amdgpu: fix merge of vcn_v1_0.c

2017-05-22 Thread Zhang, Hawking 
I think vcn_v1_0_enc_ring_emit_vm_flush also requires this line. With that 
fixed the patch is 
Reviewed-by: Hawking Zhang 

Regards,
Hawking 

-Original Message-
From: Christian König [mailto:deathsim...@vodafone.de] 
Sent: Monday, May 22, 2017 19:23
To: amd-gfx@lists.freedesktop.org
Cc: Zhang, Hawking 
Subject: [PATCH] drm/amdgpu: fix merge of vcn_v1_0.c

From: Christian König 

That line got missed during the merge.

Signed-off-by: Christian König 
---
 drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c 
b/drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c
index ad1862f..6fcf770 100644
--- a/drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c
@@ -882,6 +882,7 @@ static void vcn_v1_0_dec_ring_emit_vm_flush(struct 
amdgpu_ring *ring,
uint32_t data0, data1, mask;
unsigned eng = ring->vm_inv_eng;
 
+   pd_addr = ring->adev->gart.gart_funcs->adjust_mc_addr(ring->adev, 
pd_addr);
pd_addr = pd_addr | 0x1; /* valid bit */
/* now only use physical base address of PDE and valid */
BUG_ON(pd_addr & 0x003EULL);
-- 
2.7.4

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH 0/3] drm/amdgpu: Tweaks for high pressure on CPU visible VRAM

2017-05-22 Thread John Brooks 
On Mon, May 22, 2017 at 12:09:21PM +0200, Marek Olšák wrote:
> On Mon, May 22, 2017 at 12:00 PM, Michel Dänzer  wrote:
> > On 20/05/17 06:26 PM, Marek Olšák wrote:
> >> On May 20, 2017 3:26 AM, "Michel Dänzer"  >> > wrote:
> >>
> >> On 20/05/17 01:14 AM, Marek Olšák wrote:
> >> > Hi Michel,
> >> >
> >> > I've applied your series
> >>
> >> Thanks for testing it.
> >>
> >> > and it doesn't help with low Dirt Rally performance on Fiji. I see 
> >> TTM
> >> > buffer moves at 800MB/s and many VRAM page faults.
> >>
> >> Did you see this:
> >>
> >> >> Note that there's only little if any improvement of the average
> >> framerate
> >> >> reported, but the minimum framerate as seen on the HUD goes from
> >> ~10 fps
> >> >> to ~17.
> >>
> >> I.e. it mostly affects the minimum framerate and smoothness for me
> >> as well.
> >>
> >>
> >> Without the series, I get 70 average fps. With the series, I get 30
> >> average fps. That might just be random bad luck. I don't know.
> >
> > Hmm, yeah, maybe that was just one of the random slowdowns you've been
> > talking about in other threads and on IRC?
> >
> > I can't reproduce any slowdown with these patches, even leaving visible
> > VRAM size at 256 MB.
> 
> The random slowdowns with Dirt Rally are only caused by the pressure
> on visible VRAM. This whole thread is about those random slowdowns. If
> you're saying "maybe it was just one of the random slowdowns", you're
> saying "maybe it was just the visible VRAM pressure". It's only
> random with Dirt Rally, which makes it difficult to believe statements
> such as "I can't reproduce any slowdown". It's not random with Dying
> Light.
> 
> Marek

For what it's worth, the best place to reproduce it in Dying Light is the
courtyard where Zere's trailer is. It's the first place you go after leaving
the Tower for the first time at the start of the game. The Tower lobby is
another good place. Outside of these areas the slowdown may not be apparent at
all.

John

> ___
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

RE: [PATCH] drm/amdgpu: fix merge of vcn_v1_0.c

2017-05-22 Thread Zhang, Hawking 
I think vcn_v1_0_enc_ring_emit_vm_flush also requires this line. With that 
fixed the patch is 
Reviewed-by: Hawking Zhang 

Regards,
Hawking

-Original Message-
From: Christian König [mailto:deathsim...@vodafone.de] 
Sent: Monday, May 22, 2017 19:23
To: amd-gfx@lists.freedesktop.org
Cc: Zhang, Hawking 
Subject: [PATCH] drm/amdgpu: fix merge of vcn_v1_0.c

From: Christian König 

That line got missed during the merge.

Signed-off-by: Christian König 
---
 drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c 
b/drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c
index ad1862f..6fcf770 100644
--- a/drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c
@@ -882,6 +882,7 @@ static void vcn_v1_0_dec_ring_emit_vm_flush(struct 
amdgpu_ring *ring,
uint32_t data0, data1, mask;
unsigned eng = ring->vm_inv_eng;
 
+   pd_addr = ring->adev->gart.gart_funcs->adjust_mc_addr(ring->adev, 
pd_addr);
pd_addr = pd_addr | 0x1; /* valid bit */
/* now only use physical base address of PDE and valid */
BUG_ON(pd_addr & 0x003EULL);
-- 
2.7.4

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH] drm/radeon: Fix oops upon driver load on PowerXpress laptops

2017-05-22 Thread Lukas Wunner 
On Sun, May 21, 2017 at 09:31:09AM +0200, Nicolai Stange wrote:
> On Thu, May 18 2017, Lukas Wunner wrote:
[snip]
> > Reported-by: Nicolai Stange 
> > Fixes: 7ffb0ce31cf9 ("drm/radeon: Don't register Thunderbolt eGPU with 
> > vga_switcheroo")
> > Signed-off-by: Lukas Wunner 
> > ---
> >
> > Awaiting a Tested-by: from Nicolai, but it's clear this is a bug and
> > needs to be fixed, so sending out with a proper commit message now.
> > The bug was only introduced to radeon, not amdgpu.
> 
> Tested-by: Nicolai Stange 
> 
> Thanks for the quick fix!
>
> > @Alex Deucher: I could push this to drm-misc-fixes but then it wouldn't
> > land before -rc3 because Sean Paul has already sent out the -rc2 pull.
> > I notice you haven't sent out a pull for -rc2 yet, so maybe you want to
> > take it yourself?  Whichever you prefer.  Thanks & sorry for the breakage!

I've learned this morning that Alex is on vacation.  I've pushed
the patch to drm-misc-fixes so that the issue is fixed in 4.12-rc3.

@Sean Paul: I've fast-forwarded to 4.12-rc2 before pushing, please
shout if I've done anything wrong.  First time I'm doing this.

Thanks,

Lukas

> >
> >  drivers/gpu/drm/radeon/radeon_kms.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/radeon/radeon_kms.c 
> > b/drivers/gpu/drm/radeon/radeon_kms.c
> > index 6a68d440bc44..d0ad03674250 100644
> > --- a/drivers/gpu/drm/radeon/radeon_kms.c
> > +++ b/drivers/gpu/drm/radeon/radeon_kms.c
> > @@ -116,7 +116,7 @@ int radeon_driver_load_kms(struct drm_device *dev, 
> > unsigned long flags)
> > if ((radeon_runtime_pm != 0) &&
> > radeon_has_atpx() &&
> > ((flags & RADEON_IS_IGP) == 0) &&
> > -   !pci_is_thunderbolt_attached(rdev->pdev))
> > +   !pci_is_thunderbolt_attached(dev->pdev))
> > flags |= RADEON_IS_PX;
> >  
> > /* radeon_device_init should report only fatal error
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH v2 0/3] Cleanup evergreen/si IRQ handling code

2017-05-22 Thread Lyude Paul 
On Sat, 2017-05-20 at 13:39 +0200, Christian König wrote:
> Am 20.05.2017 um 01:48 schrieb Lyude:
> > This is the first part of me going through and cleaning up the IRQ
> > handling
> > code for radeon, since after taking a look at it the other day
> > while trying to
> > debug something I realized basically all of the code was copy
> > pasted
> > everywhere, and quite difficult to actually read through.
> > 
> > Will come up with something for r600 and cik once I've got the
> > chipsets on hand
> > to test with.
> > 
> > Lyude (3):
> >    drm/radeon: Cleanup display interrupt handling for evergreen, si
> >    drm/radeon: Cleanup HDMI audio interrupt handling for evergreen
> >    drm/radeon: Cleanup pageflipping IRQ handling for evergreen, si
> 
> I don't have time to do a line by line review, but what I saw looked 
> very good to me.
> 
> So the whole seres is Acked-by: Christian König  .com>.
> 
> BTW: You don't want to take a look at the other hw generations as
> well?
Oh don't worry, I'm already planning on that! The next chance I have
available I'll be going my coworker's GPUs so I can get the hardware I
need to test refactors I write of the rest of the hw gen's IRQ handling
code. :)
> 
> Regards,
> Christian.
> 
> > 
> >   drivers/gpu/drm/radeon/evergreen.c  | 943 ++-
> > -
> >   drivers/gpu/drm/radeon/radeon.h |  27 +-
> >   drivers/gpu/drm/radeon/radeon_irq_kms.c |  35 ++
> >   drivers/gpu/drm/radeon/si.c | 655 +
> > -
> >   4 files changed, 344 insertions(+), 1316 deletions(-)
> > 
> 
> 
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[PATCH] drm/amdgpu: fix merge of vcn_v1_0.c

2017-05-22 Thread Christian König 
From: Christian König 

That line got missed during the merge.

Signed-off-by: Christian König 
---
 drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c 
b/drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c
index ad1862f..6fcf770 100644
--- a/drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c
@@ -882,6 +882,7 @@ static void vcn_v1_0_dec_ring_emit_vm_flush(struct 
amdgpu_ring *ring,
uint32_t data0, data1, mask;
unsigned eng = ring->vm_inv_eng;
 
+   pd_addr = ring->adev->gart.gart_funcs->adjust_mc_addr(ring->adev, 
pd_addr);
pd_addr = pd_addr | 0x1; /* valid bit */
/* now only use physical base address of PDE and valid */
BUG_ON(pd_addr & 0x003EULL);
-- 
2.7.4

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

回复: [PATCH] drm/amdgpu: fix ocl test performance drop

2017-05-22 Thread Zhou, David(ChunMing) 
Reviewed-by: Chunming Zhou



 原始邮件 
主题：Re: [PATCH] drm/amdgpu: fix ocl test performance drop
发件人：Flora Cui
收件人："Zhou, David(ChunMing)"
抄送：amd-gfx@lists.freedesktop.org

partial revert commit <6971d3d> - drm/amdgpu: cleanup logic in
amdgpu_vm_flush

Change-Id: Iadce9d613dfe9a739643a74050cea55854832adb
Signed-off-by: Flora Cui 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
index 4573d8c..5b9a73d 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
@@ -743,8 +743,7 @@ int amdgpu_vm_flush(struct amdgpu_ring *ring, struct 
amdgpu_job *job)
 id->gws_size != job->gws_size ||
 id->oa_base != job->oa_base ||
 id->oa_size != job->oa_size);
-   bool vm_flush_needed = job->vm_needs_flush ||
-   amdgpu_vm_ring_has_compute_vm_bug(ring);
+   bool vm_flush_needed = job->vm_needs_flush;
 unsigned patch_offset = 0;
 int r;

--
2.7.4

On Mon, May 22, 2017 at 04:58:00PM +0800, zhoucm1 wrote:
>
>
> On 2017年05月22日 16:34, Flora Cui wrote:
> >partial revert commit <6971d3d> - drm/amdgpu: cleanup logic in
> >amdgpu_vm_flush
> >
> >Change-Id: Iadce9d613dfe9a739643a74050cea55854832adb
> >Signed-off-by: Flora Cui 
> >---
> >  drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 6 +++---
> >  1 file changed, 3 insertions(+), 3 deletions(-)
> >
> >diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c 
> >b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
> >index 4573d8c..11d58f7 100644
> >--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
> >+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
> >@@ -743,8 +743,7 @@ int amdgpu_vm_flush(struct amdgpu_ring *ring, struct 
> >amdgpu_job *job)
> >  id->gws_size != job->gws_size ||
> >  id->oa_base != job->oa_base ||
> >  id->oa_size != job->oa_size);
> >-bool vm_flush_needed = job->vm_needs_flush ||
> >-amdgpu_vm_ring_has_compute_vm_bug(ring);
> >+bool vm_flush_needed = job->vm_needs_flush;
> >  unsigned patch_offset = 0;
> >  int r;
> >@@ -753,7 +752,8 @@ int amdgpu_vm_flush(struct amdgpu_ring *ring, struct 
> >amdgpu_job *job)
> >  vm_flush_needed = true;
> >  }
> >-if (!vm_flush_needed && !gds_switch_needed)
> >+if (!vm_flush_needed && !gds_switch_needed &&
> >+!amdgpu_vm_ring_has_compute_vm_bug(ring))
> >  return 0;
> here change isn't needed.
>
> Regards,
> David Zhou
> >  if (ring->funcs->init_cond_exec)
>
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH] drm/amdgpu: fix ocl test performance drop

2017-05-22 Thread Christian König 

Am 22.05.2017 um 12:10 schrieb Flora Cui:

partial revert commit <6971d3d> - drm/amdgpu: cleanup logic in
amdgpu_vm_flush

Change-Id: Iadce9d613dfe9a739643a74050cea55854832adb
Signed-off-by: Flora Cui 


Reviewed-by: Christian König 


---
  drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 3 +--
  1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
index 4573d8c..5b9a73d 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
@@ -743,8 +743,7 @@ int amdgpu_vm_flush(struct amdgpu_ring *ring, struct 
amdgpu_job *job)
id->gws_size != job->gws_size ||
id->oa_base != job->oa_base ||
id->oa_size != job->oa_size);
-   bool vm_flush_needed = job->vm_needs_flush ||
-   amdgpu_vm_ring_has_compute_vm_bug(ring);
+   bool vm_flush_needed = job->vm_needs_flush;
unsigned patch_offset = 0;
int r;
  



___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH] drm/amdgpu: fix ocl test performance drop

2017-05-22 Thread Flora Cui 
partial revert commit <6971d3d> - drm/amdgpu: cleanup logic in
amdgpu_vm_flush

Change-Id: Iadce9d613dfe9a739643a74050cea55854832adb
Signed-off-by: Flora Cui 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
index 4573d8c..5b9a73d 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
@@ -743,8 +743,7 @@ int amdgpu_vm_flush(struct amdgpu_ring *ring, struct 
amdgpu_job *job)
id->gws_size != job->gws_size ||
id->oa_base != job->oa_base ||
id->oa_size != job->oa_size);
-   bool vm_flush_needed = job->vm_needs_flush ||
-   amdgpu_vm_ring_has_compute_vm_bug(ring);
+   bool vm_flush_needed = job->vm_needs_flush;
unsigned patch_offset = 0;
int r;
 
-- 
2.7.4

On Mon, May 22, 2017 at 04:58:00PM +0800, zhoucm1 wrote:
> 
> 
> On 2017年05月22日 16:34, Flora Cui wrote:
> >partial revert commit <6971d3d> - drm/amdgpu: cleanup logic in
> >amdgpu_vm_flush
> >
> >Change-Id: Iadce9d613dfe9a739643a74050cea55854832adb
> >Signed-off-by: Flora Cui 
> >---
> >  drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 6 +++---
> >  1 file changed, 3 insertions(+), 3 deletions(-)
> >
> >diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c 
> >b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
> >index 4573d8c..11d58f7 100644
> >--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
> >+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
> >@@ -743,8 +743,7 @@ int amdgpu_vm_flush(struct amdgpu_ring *ring, struct 
> >amdgpu_job *job)
> > id->gws_size != job->gws_size ||
> > id->oa_base != job->oa_base ||
> > id->oa_size != job->oa_size);
> >-bool vm_flush_needed = job->vm_needs_flush ||
> >-amdgpu_vm_ring_has_compute_vm_bug(ring);
> >+bool vm_flush_needed = job->vm_needs_flush;
> > unsigned patch_offset = 0;
> > int r;
> >@@ -753,7 +752,8 @@ int amdgpu_vm_flush(struct amdgpu_ring *ring, struct 
> >amdgpu_job *job)
> > vm_flush_needed = true;
> > }
> >-if (!vm_flush_needed && !gds_switch_needed)
> >+if (!vm_flush_needed && !gds_switch_needed &&
> >+!amdgpu_vm_ring_has_compute_vm_bug(ring))
> > return 0;
> here change isn't needed.
> 
> Regards,
> David Zhou
> > if (ring->funcs->init_cond_exec)
> 
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH 0/3] drm/amdgpu: Tweaks for high pressure on CPU visible VRAM

2017-05-22 Thread Marek Olšák 
On Mon, May 22, 2017 at 12:00 PM, Michel Dänzer  wrote:
> On 20/05/17 06:26 PM, Marek Olšák wrote:
>> On May 20, 2017 3:26 AM, "Michel Dänzer" > > wrote:
>>
>> On 20/05/17 01:14 AM, Marek Olšák wrote:
>> > Hi Michel,
>> >
>> > I've applied your series
>>
>> Thanks for testing it.
>>
>> > and it doesn't help with low Dirt Rally performance on Fiji. I see TTM
>> > buffer moves at 800MB/s and many VRAM page faults.
>>
>> Did you see this:
>>
>> >> Note that there's only little if any improvement of the average
>> framerate
>> >> reported, but the minimum framerate as seen on the HUD goes from
>> ~10 fps
>> >> to ~17.
>>
>> I.e. it mostly affects the minimum framerate and smoothness for me
>> as well.
>>
>>
>> Without the series, I get 70 average fps. With the series, I get 30
>> average fps. That might just be random bad luck. I don't know.
>
> Hmm, yeah, maybe that was just one of the random slowdowns you've been
> talking about in other threads and on IRC?
>
> I can't reproduce any slowdown with these patches, even leaving visible
> VRAM size at 256 MB.

The random slowdowns with Dirt Rally are only caused by the pressure
on visible VRAM. This whole thread is about those random slowdowns. If
you're saying "maybe it was just one of the random slowdowns", you're
saying "maybe it was just the visible VRAM pressure". It's only
random with Dirt Rally, which makes it difficult to believe statements
such as "I can't reproduce any slowdown". It's not random with Dying
Light.

Marek
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[PATCH 2/2] drm/amd/display: call amdgpu_dm_fini whewn sw_fini.

2017-05-22 Thread Rex Zhu 
fix issue: unload amdgpu, can't load amdgpu again.

the error as:
[drm:drm_debugfs_init [drm]] *ERROR* Cannot create /sys/kernel/debug/dri/0
[drm:drm_minor_register [drm]] *ERROR* DRM: Failed to initialize 
/sys/kernel/debug/dri.

Change-Id: If94a24ad5b30e32c3445b554bfd2884e2d27eaf9
Signed-off-by: Rex Zhu 
---
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 7 +--
 drivers/gpu/drm/amd/display/dc/core/dc.c  | 7 ++-
 2 files changed, 11 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 9813688..233d1cf 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -401,9 +401,8 @@ void amdgpu_dm_fini(struct amdgpu_device *adev)
adev->dm.freesync_module = NULL;
}
/* DC Destroy TODO: Replace destroy DAL */
-   {
+   if (adev->dm.dc)
dc_destroy(>dm.dc);
-   }
return;
 }
 
@@ -419,6 +418,10 @@ static int dm_sw_init(void *handle)
 
 static int dm_sw_fini(void *handle)
 {
+   struct amdgpu_device *adev = (struct amdgpu_device *)handle;
+
+   amdgpu_dm_fini(adev);
+
return 0;
 }
 
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc.c 
b/drivers/gpu/drm/amd/display/dc/core/dc.c
index 738acf0..b5c1295 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc.c
@@ -1582,7 +1582,12 @@ enum dc_irq_source dc_interrupt_to_irq_source(
 
 void dc_interrupt_set(const struct dc *dc, enum dc_irq_source src, bool enable)
 {
-   struct core_dc *core_dc = DC_TO_CORE(dc);
+   struct core_dc *core_dc;
+
+   if (dc == NULL)
+   return;
+   core_dc = DC_TO_CORE(dc);
+
dal_irq_service_set(core_dc->res_pool->irqs, src, enable);
 }
 
-- 
1.9.1

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[PATCH 1/2] drm/amdgpu: fix null point error when rmmod amdgpu.

2017-05-22 Thread Rex Zhu 
this bug happened when amdgpu load failed.

[   75.740951] BUG: unable to handle kernel paging request at 31c0
[   75.748167] IP: [] amdgpu_fbdev_restore_mode+0x20/0x60 
[amdgpu]
[   75.755774] PGD 0

[   75.759185] Oops:  [#1] SMP
[   75.762408] Modules linked in: amdgpu(OE-) ttm(OE) drm_kms_helper(OE) 
drm(OE) i2c_algo_bit(E) fb_sys_fops(E) syscopyarea(E) sysfillrect(E) 
sysimgblt(E) rpcsec_gss_krb5(E) nfsv4(E) nfs(E) fscache(E) eeepc_wmi(E) 
asus_wmi(E) sparse_keymap(E) intel_rapl(E) snd_hda_codec_hdmi(E) 
snd_hda_codec_realtek(E) snd_hda_codec_generic(E) snd_hda_intel(E) 
snd_hda_codec(E) snd_hda_core(E) x86_pkg_temp_thermal(E) intel_powerclamp(E) 
snd_hwdep(E) snd_pcm(E) snd_seq_midi(E) coretemp(E) kvm_intel(E) 
snd_seq_midi_event(E) snd_rawmidi(E) kvm(E) snd_seq(E) joydev(E) 
snd_seq_device(E) snd_timer(E) irqbypass(E) crct10dif_pclmul(E) crc32_pclmul(E) 
mei_me(E) ghash_clmulni_intel(E) snd(E) aesni_intel(E) mei(E) soundcore(E) 
aes_x86_64(E) shpchp(E) serio_raw(E) lrw(E) acpi_pad(E) gf128mul(E) 
glue_helper(E) ablk_helper(E) mac_hid(E)
[   75.835574]  cryptd(E) parport_pc(E) ppdev(E) lp(E) nfsd(E) parport(E) 
auth_rpcgss(E) nfs_acl(E) lockd(E) grace(E) sunrpc(E) autofs4(E) hid_generic(E) 
usbhid(E) mxm_wmi(E) psmouse(E) e1000e(E) ptp(E) pps_core(E) ahci(E) libahci(E) 
wmi(E) video(E) i2c_hid(E) hid(E)
[   75.858489] CPU: 5 PID: 1603 Comm: rmmod Tainted: G   OE   
4.9.0-custom #2
[   75.866183] Hardware name: System manufacturer System Product Name/Z170-A, 
BIOS 0901 08/31/2015
[   75.875050] task: 88045d1bbb80 task.stack: c90002de4000
[   75.881094] RIP: 0010:[]  [] 
amdgpu_fbdev_restore_mode+0x20/0x60 [amdgpu]
[   75.891238] RSP: 0018:c90002de7d48  EFLAGS: 00010286
[   75.896648] RAX:  RBX:  RCX: 0001
[   75.903933] RDX:  RSI: 88045d1bbb80 RDI: 0286
[   75.911183] RBP: c90002de7d50 R08: 0502 R09: 0004
[   75.918449] R10:  R11: 0001 R12: 880464bf
[   75.925675] R13: a0853000 R14:  R15: 564e44f88210
[   75.932980] FS:  7f13d5400700() GS:88047654() 
knlGS:
[   75.941238] CS:  0010 DS:  ES:  CR0: 80050033
[   75.947088] CR2: 31c0 CR3: 00045fd0b000 CR4: 003406e0
[   75.954332] DR0:  DR1:  DR2: 
[   75.961566] DR3:  DR6: fffe0ff0 DR7: 0400
[   75.968834] Stack:
[   75.970881]  880464bf c90002de7d60 a0636592 
c90002de7d80
[   75.978454]  a059015f 880464bf 880464bf 
c90002de7da8
[   75.986076]  a0595216 880464bf 880460f4d000 
a0853000
[   75.993692] Call Trace:
[   75.996177]  [] amdgpu_driver_lastclose_kms+0x12/0x20 
[amdgpu]
[   76.003700]  [] drm_lastclose+0x2f/0xd0 [drm]
[   76.009777]  [] drm_dev_unregister+0x16/0xd0 [drm]
[   76.016255]  [] drm_put_dev+0x34/0x70 [drm]
[   76.022139]  [] amdgpu_pci_remove+0x15/0x20 [amdgpu]
[   76.028800]  [] pci_device_remove+0x39/0xc0
[   76.034661]  [] __device_release_driver+0x9a/0x140
[   76.041121]  [] driver_detach+0xb8/0xc0
[   76.046575]  [] bus_remove_driver+0x55/0xd0
[   76.052401]  [] driver_unregister+0x2c/0x50
[   76.058244]  [] pci_unregister_driver+0x29/0x90
[   76.064466]  [] drm_pci_exit+0x9e/0xb0 [drm]
[   76.070507]  [] amdgpu_exit+0x1c/0x32 [amdgpu]
[   76.076609]  [] SyS_delete_module+0x1a0/0x200
[   76.082627]  [] ? rcu_eqs_enter.isra.36+0x4a/0x50
[   76.089001]  [] do_syscall_64+0x6e/0x180
[   76.094583]  [] entry_SYSCALL64_slow_path+0x25/0x25
[   76.101114] Code: 94 c0 c3 31 c0 5d c3 0f 1f 40 00 0f 1f 44 00 00 55 31 c0 
48 89 e5 53 48 89 fb 48 c7 c7 1d 21 84 a0 e8 ab 77 b3 e0 e8 fc 8b d7 e0 <48> 8b 
bb c0 31 00 00 48 85 ff 74 09 e8 ff eb fc ff 85 c0 75 03
[   76.121432] RIP  [] amdgpu_fbdev_restore_mode+0x20/0x60 
[amdgpu]

Change-Id: I8021d72a3381bc68b6724b43b7a12cb6c5acbe9a
Signed-off-by: Rex Zhu 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
index e869e60..667996b 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
@@ -430,10 +430,15 @@ bool amdgpu_fbdev_robj_is_fb(struct amdgpu_device *adev, 
struct amdgpu_bo *robj)
 
 void amdgpu_fbdev_restore_mode(struct amdgpu_device *adev)
 {
-   struct amdgpu_fbdev *afbdev = adev->mode_info.rfbdev;
+   struct amdgpu_fbdev *afbdev;
struct drm_fb_helper *fb_helper;
int ret;
 
+   if (!adev)
+   return;
+
+   afbdev = adev->mode_info.rfbdev;
+
if (!afbdev)
return;
 
-- 
1.9.1

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org

Re: [PATCH] drm/amdgpu: fix ocl test performance drop

2017-05-22 Thread zhoucm1 



On 2017年05月22日 16:34, Flora Cui wrote:

partial revert commit <6971d3d> - drm/amdgpu: cleanup logic in
amdgpu_vm_flush

Change-Id: Iadce9d613dfe9a739643a74050cea55854832adb
Signed-off-by: Flora Cui 
---
  drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
index 4573d8c..11d58f7 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
@@ -743,8 +743,7 @@ int amdgpu_vm_flush(struct amdgpu_ring *ring, struct 
amdgpu_job *job)
id->gws_size != job->gws_size ||
id->oa_base != job->oa_base ||
id->oa_size != job->oa_size);
-   bool vm_flush_needed = job->vm_needs_flush ||
-   amdgpu_vm_ring_has_compute_vm_bug(ring);
+   bool vm_flush_needed = job->vm_needs_flush;
unsigned patch_offset = 0;
int r;
  
@@ -753,7 +752,8 @@ int amdgpu_vm_flush(struct amdgpu_ring *ring, struct amdgpu_job *job)

vm_flush_needed = true;
}
  
-	if (!vm_flush_needed && !gds_switch_needed)

+   if (!vm_flush_needed && !gds_switch_needed &&
+   !amdgpu_vm_ring_has_compute_vm_bug(ring))
return 0;

here change isn't needed.

Regards,
David Zhou
  
  	if (ring->funcs->init_cond_exec)


___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[PATCH] drm/amdgpu: fix ocl test performance drop

2017-05-22 Thread Flora Cui 
partial revert commit <6971d3d> - drm/amdgpu: cleanup logic in
amdgpu_vm_flush

Change-Id: Iadce9d613dfe9a739643a74050cea55854832adb
Signed-off-by: Flora Cui 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
index 4573d8c..11d58f7 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
@@ -743,8 +743,7 @@ int amdgpu_vm_flush(struct amdgpu_ring *ring, struct 
amdgpu_job *job)
id->gws_size != job->gws_size ||
id->oa_base != job->oa_base ||
id->oa_size != job->oa_size);
-   bool vm_flush_needed = job->vm_needs_flush ||
-   amdgpu_vm_ring_has_compute_vm_bug(ring);
+   bool vm_flush_needed = job->vm_needs_flush;
unsigned patch_offset = 0;
int r;
 
@@ -753,7 +752,8 @@ int amdgpu_vm_flush(struct amdgpu_ring *ring, struct 
amdgpu_job *job)
vm_flush_needed = true;
}
 
-   if (!vm_flush_needed && !gds_switch_needed)
+   if (!vm_flush_needed && !gds_switch_needed &&
+   !amdgpu_vm_ring_has_compute_vm_bug(ring))
return 0;
 
if (ring->funcs->init_cond_exec)
-- 
2.7.4

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH] drm/amdgpu: fix ocl test performance drop

2017-05-22 Thread Flora Cui 
Could anyone give me a RB?

On Fri, May 19, 2017 at 01:59:16PM +0200, Christian König wrote:
> I'm pretty sure that bug is fixed in GFX9. So we don't need the check there
> any more.
> 
> Regards,
> Christian.
> 
> Am 19.05.2017 um 07:16 schrieb zhoucm1:
> >I also realized this problem when I did fix for sched fence, I thought if
> >no issue, just left it as current code, it's more safe.
> >As Flora point it out, it results in performance drop, then we need to
> >correct it back.
> >pipeline_sync in vm flush should be inserted only when
> >amdgpu_vm_ring_has_compute_vm_bug() is true, not all time for every vm
> >flush for all engines. The bug has been fixed in mec firmware from version
> >673 in gfx8.
> >About gfx9 for amdgpu_vm_ring_has_compute_vm_bug(), current implementation
> >is thinking gfx9 doesn't have compute vm bug by default. Not sure it's in
> >there. If no vm fault related to this bug, then we can think gfx9 has no
> >compute vm bug, I believe firmware team does that based on previous
> >generation, otherwise we need identify every generation, that's crazy.
> >
> >Regards,
> >David Zhou
> >On 2017年05月19日 11:36, Flora Cui wrote:
> >>btw, what's about gfx9 for amdgpu_vm_ring_has_compute_vm_bug()? Is the
> >>workaround still needed?
> >>
> >>On Fri, May 19, 2017 at 10:25:19AM +0800, Flora Cui wrote:
> >>>On Thu, May 18, 2017 at 01:38:15PM +0200, Christian König wrote:
> Am 18.05.2017 um 09:45 schrieb Flora Cui:
> >partial revert commit <6971d3d> - drm/amdgpu: cleanup logic in
> >amdgpu_vm_flush
> >
> >Change-Id: Iadce9d613dfe9a739643a74050cea55854832adb
> >Signed-off-by: Flora Cui 
> I don't see how the revert should be faster than the original.
> 
> Especially that amdgpu_vm_had_gpu_reset() is now called twice sounds
> like
> more overhead than necessary.
> 
> Please explain further.
> 
> Christian.
> 
> >---
> >  drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 14 +-
> >  1 file changed, 5 insertions(+), 9 deletions(-)
> >
> >diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
> >b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
> >index 88420dc..a96bad6 100644
> >--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
> >+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
> >@@ -743,23 +743,19 @@ int amdgpu_vm_flush(struct amdgpu_ring
> >*ring, struct amdgpu_job *job)
> >  id->gws_size != job->gws_size ||
> >  id->oa_base != job->oa_base ||
> >  id->oa_size != job->oa_size);
> >-bool vm_flush_needed = job->vm_needs_flush ||
> >-amdgpu_vm_ring_has_compute_vm_bug(ring);
> >  unsigned patch_offset = 0;
> >  int r;
> >-if (amdgpu_vm_had_gpu_reset(adev, id)) {
> >-gds_switch_needed = true;
> >-vm_flush_needed = true;
> >-}
> >-
> >-if (!vm_flush_needed && !gds_switch_needed)
> >+if (!job->vm_needs_flush && !gds_switch_needed &&
> >+!amdgpu_vm_had_gpu_reset(adev, id) &&
> >+!amdgpu_vm_ring_has_compute_vm_bug(ring))
> >  return 0;
> >  if (ring->funcs->init_cond_exec)
> >  patch_offset = amdgpu_ring_init_cond_exec(ring);
> >-if (ring->funcs->emit_vm_flush && vm_flush_needed) {
> >>>[flora]: for compute ring & amdgpu_vm_ring_has_compute_vm_bug(), a
> >>>vm_flush is
> >>>inserted. This might cause performance drop.
> >+if (ring->funcs->emit_vm_flush &&
> >+(job->vm_needs_flush || amdgpu_vm_had_gpu_reset(adev,
> >id))) {
> >  struct fence *fence;
> >  trace_amdgpu_vm_flush(ring, job->vm_id, job->vm_pd_addr);
> 
> >>>___
> >>>amd-gfx mailing list
> >>>amd-gfx@lists.freedesktop.org
> >>>https://lists.freedesktop.org/mailman/listinfo/amd-gfx
> >>___
> >>amd-gfx mailing list
> >>amd-gfx@lists.freedesktop.org
> >>https://lists.freedesktop.org/mailman/listinfo/amd-gfx
> >
> >___
> >amd-gfx mailing list
> >amd-gfx@lists.freedesktop.org
> >https://lists.freedesktop.org/mailman/listinfo/amd-gfx
> 
> 
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH] drm/amd: include instead of "linux/delay.h"

2017-05-22 Thread Christian König 

Am 22.05.2017 um 10:06 schrieb Daniel Vetter:

On Mon, May 22, 2017 at 09:55:46AM +0200, Christian König wrote:

Am 22.05.2017 um 09:39 schrieb Daniel Vetter:

On Thu, May 18, 2017 at 08:47:34AM +0200, Christian König wrote:

Am 18.05.2017 um 06:43 schrieb Masahiro Yamada:

Use <...> notation to include headers located in include/linux.
While we are here, tweak the includes order a bit to sort them
alphabetically.

Signed-off-by: Masahiro Yamada 

Reviewed-by: Christian König 

I think I'll leave this one for Alex, but I guess I can pick it up into
drm-misc too if that's simpler ... All the other include patches are in
there already.

Please pick that up for drm-misc. Alex is on vacation this week and I
already have all hands full replacing him.

Done. Aside: Switching to commit rights is a nice way to make maintainer
vacations real smooth :-) I wanted to chat with Alex about that anyway, I
guess I'll ping him when he's back.


Completely agree. One lesson learned from the past week is that Alex 
needs to stop using his personal repository on fdo.


We were asked a couple of times if I couldn't update a branch there from 
different directions, which we obviously can't do.


Christian.



Cheers, Daniel


Christian.


-Daniel

---

drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c| 4 ++--
drivers/gpu/drm/amd/powerplay/hwmgr/pp_acpi.c  | 2 +-
drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c   | 4 ++--
drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c | 5 +++--
drivers/gpu/drm/amd/powerplay/smumgr/cz_smumgr.c   | 8 +---
drivers/gpu/drm/amd/powerplay/smumgr/smumgr.c  | 5 +++--
6 files changed, 16 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c 
b/drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c
index ff4ae3d..963a9e0 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c
@@ -22,10 +22,10 @@
 */
#include "pp_debug.h"
-#include "linux/delay.h"
-#include 
+#include 
#include 
#include 
+#include 
#include 
#include "cgs_common.h"
#include "power_state.h"
diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/pp_acpi.c 
b/drivers/gpu/drm/amd/powerplay/hwmgr/pp_acpi.c
index f5e8fda..f6b4dd9 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/pp_acpi.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/pp_acpi.c
@@ -21,8 +21,8 @@
 *
 */
+#include 
#include 
-#include "linux/delay.h"
#include "hwmgr.h"
#include "amd_acpi.h"
#include "pp_acpi.h"
diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c 
b/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
index 8f663ab..581374d 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
@@ -21,11 +21,11 @@
 *
 */
#include "pp_debug.h"
+#include 
+#include 
#include 
#include 
-#include 
#include 
-#include "linux/delay.h"
#include "pp_acpi.h"
#include "ppatomctrl.h"
#include "atombios.h"
diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c 
b/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c
index 8394955..f4ab81b 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c
@@ -20,10 +20,11 @@
 * OTHER DEALINGS IN THE SOFTWARE.
 *
 */
+
+#include 
+#include 
#include 
#include 
-#include 
-#include "linux/delay.h"
#include "hwmgr.h"
#include "amd_powerplay.h"
diff --git a/drivers/gpu/drm/amd/powerplay/smumgr/cz_smumgr.c 
b/drivers/gpu/drm/amd/powerplay/smumgr/cz_smumgr.c
index 1f6744a..39c7091 100644
--- a/drivers/gpu/drm/amd/powerplay/smumgr/cz_smumgr.c
+++ b/drivers/gpu/drm/amd/powerplay/smumgr/cz_smumgr.c
@@ -20,11 +20,13 @@
 * OTHER DEALINGS IN THE SOFTWARE.
 *
 */
-#include 
+
+#include 
+#include 
#include 
#include 
-#include 
-#include "linux/delay.h"
+#include 
+
#include "cgs_common.h"
#include "smu/smu_8_0_d.h"
#include "smu/smu_8_0_sh_mask.h"
diff --git a/drivers/gpu/drm/amd/powerplay/smumgr/smumgr.c 
b/drivers/gpu/drm/amd/powerplay/smumgr/smumgr.c
index c0d7576..2e954a4 100644
--- a/drivers/gpu/drm/amd/powerplay/smumgr/smumgr.c
+++ b/drivers/gpu/drm/amd/powerplay/smumgr/smumgr.c
@@ -20,15 +20,16 @@
 * OTHER DEALINGS IN THE SOFTWARE.
 *
 */
-#include 
+
+#include 
#include 
#include 
#include 
+#include 
#include 
#include "pp_instance.h"
#include "smumgr.h"
#include "cgs_common.h"
-#include "linux/delay.h"
MODULE_FIRMWARE("amdgpu/topaz_smc.bin");
MODULE_FIRMWARE("amdgpu/topaz_k_smc.bin");

___
dri-devel mailing list
dri-de...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


___
dri-devel mailing list
dri-de...@lists.freedesktop.org

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

2017-05-22 Thread Michel Dänzer 
On 22/05/17 10:54 AM, Michel Dänzer wrote:
> On 20/05/17 03:55 AM, Felix Kuehling wrote:
>> On 17-05-18 09:17 PM, Michel Dänzer wrote:
> 
> The default at this point should possibly still be for CIK GPUs to be
> driven by radeon, even if CONFIG_DRM_AMDGPU_CIK is enabled;
 Alex and Christian seem to think otherwise.
>>> FWIW, on my AMD notebook (HP EliteBook 725 G2, Kaveri), suspend/resume
>>> with amdgpu results in a black screen (can reboot blindly); works fine
>>> with radeon.
>>
>> Has this problem been reported anywhere? Is anyone working on fixing it?
>> If it's not reported, it will never be fixed.
> 
> You're right, I'll file a bug report.

I get the same error lines as described in
https://bugs.freedesktop.org/100949, I'm trying to get clarification if
it's the same bug.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH] drm/amd: include instead of "linux/delay.h"

2017-05-22 Thread Christian König 

Am 22.05.2017 um 09:39 schrieb Daniel Vetter:

On Thu, May 18, 2017 at 08:47:34AM +0200, Christian König wrote:

Am 18.05.2017 um 06:43 schrieb Masahiro Yamada:

Use <...> notation to include headers located in include/linux.
While we are here, tweak the includes order a bit to sort them
alphabetically.

Signed-off-by: Masahiro Yamada 

Reviewed-by: Christian König 

I think I'll leave this one for Alex, but I guess I can pick it up into
drm-misc too if that's simpler ... All the other include patches are in
there already.


Please pick that up for drm-misc. Alex is on vacation this week and I 
already have all hands full replacing him.


Christian.


-Daniel

---

   drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c| 4 ++--
   drivers/gpu/drm/amd/powerplay/hwmgr/pp_acpi.c  | 2 +-
   drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c   | 4 ++--
   drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c | 5 +++--
   drivers/gpu/drm/amd/powerplay/smumgr/cz_smumgr.c   | 8 +---
   drivers/gpu/drm/amd/powerplay/smumgr/smumgr.c  | 5 +++--
   6 files changed, 16 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c 
b/drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c
index ff4ae3d..963a9e0 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c
@@ -22,10 +22,10 @@
*/
   #include "pp_debug.h"
-#include "linux/delay.h"
-#include 
+#include 
   #include 
   #include 
+#include 
   #include 
   #include "cgs_common.h"
   #include "power_state.h"
diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/pp_acpi.c 
b/drivers/gpu/drm/amd/powerplay/hwmgr/pp_acpi.c
index f5e8fda..f6b4dd9 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/pp_acpi.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/pp_acpi.c
@@ -21,8 +21,8 @@
*
*/
+#include 
   #include 
-#include "linux/delay.h"
   #include "hwmgr.h"
   #include "amd_acpi.h"
   #include "pp_acpi.h"
diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c 
b/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
index 8f663ab..581374d 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
@@ -21,11 +21,11 @@
*
*/
   #include "pp_debug.h"
+#include 
+#include 
   #include 
   #include 
-#include 
   #include 
-#include "linux/delay.h"
   #include "pp_acpi.h"
   #include "ppatomctrl.h"
   #include "atombios.h"
diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c 
b/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c
index 8394955..f4ab81b 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c
@@ -20,10 +20,11 @@
* OTHER DEALINGS IN THE SOFTWARE.
*
*/
+
+#include 
+#include 
   #include 
   #include 
-#include 
-#include "linux/delay.h"
   #include "hwmgr.h"
   #include "amd_powerplay.h"
diff --git a/drivers/gpu/drm/amd/powerplay/smumgr/cz_smumgr.c 
b/drivers/gpu/drm/amd/powerplay/smumgr/cz_smumgr.c
index 1f6744a..39c7091 100644
--- a/drivers/gpu/drm/amd/powerplay/smumgr/cz_smumgr.c
+++ b/drivers/gpu/drm/amd/powerplay/smumgr/cz_smumgr.c
@@ -20,11 +20,13 @@
* OTHER DEALINGS IN THE SOFTWARE.
*
*/
-#include 
+
+#include 
+#include 
   #include 
   #include 
-#include 
-#include "linux/delay.h"
+#include 
+
   #include "cgs_common.h"
   #include "smu/smu_8_0_d.h"
   #include "smu/smu_8_0_sh_mask.h"
diff --git a/drivers/gpu/drm/amd/powerplay/smumgr/smumgr.c 
b/drivers/gpu/drm/amd/powerplay/smumgr/smumgr.c
index c0d7576..2e954a4 100644
--- a/drivers/gpu/drm/amd/powerplay/smumgr/smumgr.c
+++ b/drivers/gpu/drm/amd/powerplay/smumgr/smumgr.c
@@ -20,15 +20,16 @@
* OTHER DEALINGS IN THE SOFTWARE.
*
*/
-#include 
+
+#include 
   #include 
   #include 
   #include 
+#include 
   #include 
   #include "pp_instance.h"
   #include "smumgr.h"
   #include "cgs_common.h"
-#include "linux/delay.h"
   MODULE_FIRMWARE("amdgpu/topaz_smc.bin");
   MODULE_FIRMWARE("amdgpu/topaz_k_smc.bin");


___
dri-devel mailing list
dri-de...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel



___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[PATCH] iommu/amd: flush IOTLB for specific domains only (v3)

2017-05-22 Thread arindam . nath 
From: Arindam Nath 

Change History
--

v3:
- add Fixes and CC tags
- add link to Bugzilla

v2: changes suggested by Joerg
- add flush flag to improve efficiency of flush operation

v1:
- The idea behind flush queues is to defer the IOTLB flushing
  for domains for which the mappings are no longer valid. We
  add such domains in queue_add(), and when the queue size
  reaches FLUSH_QUEUE_SIZE, we perform __queue_flush().

  Since we have already taken lock before __queue_flush()
  is called, we need to make sure the IOTLB flushing is
  performed as quickly as possible.

  In the current implementation, we perform IOTLB flushing
  for all domains irrespective of which ones were actually
  added in the flush queue initially. This can be quite
  expensive especially for domains for which unmapping is
  not required at this point of time.

  This patch makes use of domain information in
  'struct flush_queue_entry' to make sure we only flush
  IOTLBs for domains who need it, skipping others.

Bugzilla: https://bugs.freedesktop.org/101029
Fixes: b1516a14657a ("iommu/amd: Implement flush queue")
Cc: sta...@vger.kernel.org
Suggested-by: Joerg Roedel 
Signed-off-by: Arindam Nath 
---
 drivers/iommu/amd_iommu.c   | 27 ---
 drivers/iommu/amd_iommu_types.h |  2 ++
 2 files changed, 22 insertions(+), 7 deletions(-)

diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c
index 63cacf5..1edeebec 100644
--- a/drivers/iommu/amd_iommu.c
+++ b/drivers/iommu/amd_iommu.c
@@ -2227,15 +2227,26 @@ static struct iommu_group 
*amd_iommu_device_group(struct device *dev)
 
 static void __queue_flush(struct flush_queue *queue)
 {
-   struct protection_domain *domain;
-   unsigned long flags;
int idx;
 
-   /* First flush TLB of all known domains */
-   spin_lock_irqsave(_iommu_pd_lock, flags);
-   list_for_each_entry(domain, _iommu_pd_list, list)
-   domain_flush_tlb(domain);
-   spin_unlock_irqrestore(_iommu_pd_lock, flags);
+   /* First flush TLB of all domains which were added to flush queue */
+   for (idx = 0; idx < queue->next; ++idx) {
+   struct flush_queue_entry *entry;
+
+   entry = queue->entries + idx;
+
+   /*
+* There might be cases where multiple IOVA entries for the
+* same domain are queued in the flush queue. To avoid
+* flushing the same domain again, we check whether the
+* flag is set or not. This improves the efficiency of
+* flush operation.
+*/
+   if (!entry->dma_dom->domain.already_flushed) {
+   entry->dma_dom->domain.already_flushed = true;
+   domain_flush_tlb(>dma_dom->domain);
+   }
+   }
 
/* Wait until flushes have completed */
domain_flush_complete(NULL);
@@ -2289,6 +2300,8 @@ static void queue_add(struct dma_ops_domain *dma_dom,
pages = __roundup_pow_of_two(pages);
address >>= PAGE_SHIFT;
 
+   dma_dom->domain.already_flushed = false;
+
queue = get_cpu_ptr(_queue);
spin_lock_irqsave(>lock, flags);
 
diff --git a/drivers/iommu/amd_iommu_types.h b/drivers/iommu/amd_iommu_types.h
index 4de8f41..4f5519d 100644
--- a/drivers/iommu/amd_iommu_types.h
+++ b/drivers/iommu/amd_iommu_types.h
@@ -454,6 +454,8 @@ struct protection_domain {
bool updated;   /* complete domain flush required */
unsigned dev_cnt;   /* devices assigned to this domain */
unsigned dev_iommu[MAX_IOMMUS]; /* per-IOMMU reference count */
+   bool already_flushed;   /* flag to avoid flushing the same domain again
+  in a single invocation of __queue_flush() */
 };
 
 /*
-- 
2.7.4

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH] drm/amd: include instead of "linux/delay.h"

2017-05-22 Thread Daniel Vetter 
On Thu, May 18, 2017 at 08:47:34AM +0200, Christian König wrote:
> Am 18.05.2017 um 06:43 schrieb Masahiro Yamada:
> > Use <...> notation to include headers located in include/linux.
> > While we are here, tweak the includes order a bit to sort them
> > alphabetically.
> > 
> > Signed-off-by: Masahiro Yamada 
> 
> Reviewed-by: Christian König 

I think I'll leave this one for Alex, but I guess I can pick it up into
drm-misc too if that's simpler ... All the other include patches are in
there already.
-Daniel
> 
> > ---
> > 
> >   drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c| 4 ++--
> >   drivers/gpu/drm/amd/powerplay/hwmgr/pp_acpi.c  | 2 +-
> >   drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c   | 4 ++--
> >   drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c | 5 +++--
> >   drivers/gpu/drm/amd/powerplay/smumgr/cz_smumgr.c   | 8 +---
> >   drivers/gpu/drm/amd/powerplay/smumgr/smumgr.c  | 5 +++--
> >   6 files changed, 16 insertions(+), 12 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c 
> > b/drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c
> > index ff4ae3d..963a9e0 100644
> > --- a/drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c
> > +++ b/drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c
> > @@ -22,10 +22,10 @@
> >*/
> >   #include "pp_debug.h"
> > -#include "linux/delay.h"
> > -#include 
> > +#include 
> >   #include 
> >   #include 
> > +#include 
> >   #include 
> >   #include "cgs_common.h"
> >   #include "power_state.h"
> > diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/pp_acpi.c 
> > b/drivers/gpu/drm/amd/powerplay/hwmgr/pp_acpi.c
> > index f5e8fda..f6b4dd9 100644
> > --- a/drivers/gpu/drm/amd/powerplay/hwmgr/pp_acpi.c
> > +++ b/drivers/gpu/drm/amd/powerplay/hwmgr/pp_acpi.c
> > @@ -21,8 +21,8 @@
> >*
> >*/
> > +#include 
> >   #include 
> > -#include "linux/delay.h"
> >   #include "hwmgr.h"
> >   #include "amd_acpi.h"
> >   #include "pp_acpi.h"
> > diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c 
> > b/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
> > index 8f663ab..581374d 100644
> > --- a/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
> > +++ b/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
> > @@ -21,11 +21,11 @@
> >*
> >*/
> >   #include "pp_debug.h"
> > +#include 
> > +#include 
> >   #include 
> >   #include 
> > -#include 
> >   #include 
> > -#include "linux/delay.h"
> >   #include "pp_acpi.h"
> >   #include "ppatomctrl.h"
> >   #include "atombios.h"
> > diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c 
> > b/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c
> > index 8394955..f4ab81b 100644
> > --- a/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c
> > +++ b/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c
> > @@ -20,10 +20,11 @@
> >* OTHER DEALINGS IN THE SOFTWARE.
> >*
> >*/
> > +
> > +#include 
> > +#include 
> >   #include 
> >   #include 
> > -#include 
> > -#include "linux/delay.h"
> >   #include "hwmgr.h"
> >   #include "amd_powerplay.h"
> > diff --git a/drivers/gpu/drm/amd/powerplay/smumgr/cz_smumgr.c 
> > b/drivers/gpu/drm/amd/powerplay/smumgr/cz_smumgr.c
> > index 1f6744a..39c7091 100644
> > --- a/drivers/gpu/drm/amd/powerplay/smumgr/cz_smumgr.c
> > +++ b/drivers/gpu/drm/amd/powerplay/smumgr/cz_smumgr.c
> > @@ -20,11 +20,13 @@
> >* OTHER DEALINGS IN THE SOFTWARE.
> >*
> >*/
> > -#include 
> > +
> > +#include 
> > +#include 
> >   #include 
> >   #include 
> > -#include 
> > -#include "linux/delay.h"
> > +#include 
> > +
> >   #include "cgs_common.h"
> >   #include "smu/smu_8_0_d.h"
> >   #include "smu/smu_8_0_sh_mask.h"
> > diff --git a/drivers/gpu/drm/amd/powerplay/smumgr/smumgr.c 
> > b/drivers/gpu/drm/amd/powerplay/smumgr/smumgr.c
> > index c0d7576..2e954a4 100644
> > --- a/drivers/gpu/drm/amd/powerplay/smumgr/smumgr.c
> > +++ b/drivers/gpu/drm/amd/powerplay/smumgr/smumgr.c
> > @@ -20,15 +20,16 @@
> >* OTHER DEALINGS IN THE SOFTWARE.
> >*
> >*/
> > -#include 
> > +
> > +#include 
> >   #include 
> >   #include 
> >   #include 
> > +#include 
> >   #include 
> >   #include "pp_instance.h"
> >   #include "smumgr.h"
> >   #include "cgs_common.h"
> > -#include "linux/delay.h"
> >   MODULE_FIRMWARE("amdgpu/topaz_smc.bin");
> >   MODULE_FIRMWARE("amdgpu/topaz_k_smc.bin");
> 
> 
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: (radeon?) WARNING: drivers/gpu/drm/drm_irq.c:1195 drm_vblank_put (v4.11-12441-g56868a4)

2017-05-22 Thread Daniel Vetter 
On Thu, May 18, 2017 at 07:43:51PM +0300, Tommi Rantala wrote:
> 2017-05-11 5:51 GMT+03:00 Michel Dänzer :
> > On 11/05/17 04:33 AM, Tommi Rantala wrote:
> >> Complete kernel log:
> >> http://termbin.com/dzy5
> >>
> >> [  249.952546] [ cut here ]
> >> [  249.952593] WARNING: CPU: 5 PID: 0 at
> >> /home/ttrantal/git/linux/drivers/gpu/drm/drm_irq.c:1195
> >> drm_vblank_put+0xc4/0x120 [drm]
> >> [  249.952596] Modules linked in: fuse tun bridge stp llc af_packet
> >> pl2303 usbserial shpchp acpi_cpufreq binfmt_misc amdgpu hid_generic
> >> uhci_hcd radeon 3c59x mii tg3 ehci_pci ehci_hcd i2c_algo_bit
> >> drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ttm drm
> >> agpgart unix autofs4
> >> [  249.952675] CPU: 5 PID: 0 Comm: swapper/5 Tainted: GW
> >> 4.11.0+ #4
> >> [  249.952678] Hardware name: Hewlett-Packard HP xw6600
> >> Workstation/0A9Ch, BIOS 786F4 v01.46 09/20/2012
> >> [  249.952681] task: 88080aea task.stack: c900031b
> >> [  249.952695] RIP: 0010:drm_vblank_put+0xc4/0x120 [drm]
> >> [  249.952698] RSP: 0018:88080f003d70 EFLAGS: 00010046
> >> [  249.952703] RAX:  RBX: 880801d53000 RCX: 
> >> 
> >> [  249.952706] RDX:  RSI:  RDI: 
> >> 88080a4ac000
> >> [  249.952709] RBP: 88080f003d88 R08: 0001 R09: 
> >> 0003
> >> [  249.952711] R10: 88080f003d08 R11: 001da540 R12: 
> >> 88080a4ac000
> >> [  249.952714] R13:  R14: 0086 R15: 
> >> 8808019a
> >> [  249.952717] FS:  () GS:88080f00()
> >> knlGS:
> >> [  249.952720] CS:  0010 DS:  ES:  CR0: 80050033
> >> [  249.952723] CR2: 7f8bcc3a5810 CR3: 000808789000 CR4: 
> >> 06e0
> >> [  249.952726] Call Trace:
> >> [  249.952731]  
> >> [  249.952746]  drm_crtc_vblank_put+0x1b/0x30 [drm]
> >> [  249.952813]  radeon_crtc_handle_flip+0xdc/0x140 [radeon]
> >> [  249.952843]  si_irq_process+0x610/0x1e90 [radeon]
> >> [  249.952872]  radeon_driver_irq_handler_kms+0x39/0xc0 [radeon]
> >> [  249.952881]  __handle_irq_event_percpu+0x60/0x580
> >> [  249.952887]  handle_irq_event_percpu+0x20/0x90
> >> [  249.952892]  handle_irq_event+0x46/0xb0
> >> [  249.952897]  handle_edge_irq+0x13d/0x370
> >> [  249.952903]  handle_irq+0x66/0x210
> >> [  249.952908]  ? __local_bh_enable+0x34/0x50
> >> [  249.952914]  do_IRQ+0x7e/0x1b0
> >> [  249.952920]  common_interrupt+0x95/0x95
> >
> > Weird, not sure how this could happen. Can you bisect?
> 
> Hi,
> 
> Bisection points to this (also manually applied commit 9739e74646
> while testing, got kernel oops otherwise):
> 
> commit 29dc0d1de18239cf3ef8bab578b8321ed340d81c
> Author: Daniel Vetter 
> Date:   Wed Mar 22 22:50:49 2017 +0100
> 
> drm: Roll out acquire context for the page_flip ioctl
> 
> Again just prep work.
> 
> Reviewed-by: Harry Wentland 
> Signed-off-by: Daniel Vetter 
> Link: 
> http://patchwork.freedesktop.org/patch/msgid/20170322215058.8671-11-daniel.vet...@ffwll.ch
> 
> 
> I'm also seeing some more warnings in this version:

Yeah I think the locking stuff we've fixed, at least if you don't see it
in 4.12 it should be all good. And I think I spotted the bug you've
bisected to, patch is on dri-devel, pls test.

Thanks for the bug report.
-Daniel

> 
> 
> May 18 19:21:55 xw6600 kernel: IPv6: ADDRCONF(NETDEV_CHANGE): enp14s0:
> link becomes ready
> May 18 19:21:57 xw6600 kernel: [ cut here ]
> May 18 19:21:57 xw6600 kernel: WARNING: CPU: 5 PID: 4607 at
> /home/ttrantal/git/linux/drivers/gpu/drm/drm_modeset_lock.c:193
> drm_modeset_lock_crtc+0xe5/0x100 [drm]
> May 18 19:21:57 xw6600 kernel: Modules linked in: tun bridge stp llc
> af_packet pl2303 usbserial shpchp acpi_cpufreq binfmt_misc amdgpu
> hid_generic uhci_hcd radeon 3c59x mii i2c_algo_bit drm_kms_helper tg3
> syscopyarea sysfillrect sysimgblt
> May 18 19:21:57 xw6600 kernel: CPU: 5 PID: 4607 Comm: gnome-shell Not
> tainted 4.11.0-rc3-00944-g29dc0d1-dirty #30
> May 18 19:21:57 xw6600 kernel: Hardware name: Hewlett-Packard HP
> xw6600 Workstation/0A9Ch, BIOS 786F4 v01.46 09/20/2012
> May 18 19:21:57 xw6600 kernel: Call Trace:
> May 18 19:21:57 xw6600 kernel:  dump_stack+0x69/0x9b
> May 18 19:21:57 xw6600 kernel:  __warn+0xff/0x140
> May 18 19:21:57 xw6600 kernel:  warn_slowpath_null+0x18/0x20
> May 18 19:21:57 xw6600 kernel:  drm_modeset_lock_crtc+0xe5/0x100 [drm]
> May 18 19:21:57 xw6600 kernel:  drm_mode_cursor_common+0xbd/0x200 [drm]
> May 18 19:21:57 xw6600 kernel:  drm_mode_cursor_ioctl+0x3c/0x40 [drm]
> May 18 19:21:57 xw6600 kernel:  drm_ioctl+0x3ea/0x870 [drm]
> May 18 19:21:57 xw6600 kernel:  ? drm_mode_setplane+0x1a0/0x1a0 [drm]
> May 18 19:21:57 xw6600 kernel:  ? trace_hardirqs_on_caller+0x1ad/0x2c0
> May 18 19:21:57 xw6600