date:20170205

Re: [PATCH 3/6] drm/amdgpu: IOCTL interface for PRT support v3

2017-02-05 Thread Christian König


Am 04.02.2017 um 20:14 schrieb Bas Nieuwenhuizen:

I get an error when trying to map a PRT region:

[   41.588224] BUG: unable to handle kernel NULL pointer dereference at
01e8
[   41.589899] IP: []
ttm_eu_reserve_buffers+0x136/0x370 [ttm]


Oh, yeah the bug is rather obvious when I look into the code, sorry for 
that.


I'm still on sick leave for the next week as well, but going to look 
into this as soon as I can.


Regards,
Christian.


[   41.590424] PGD 0

[   41.590943] Oops:  [#1] PREEMPT SMP
[   41.591468] Modules linked in: uvcvideo videobuf2_vmalloc
videobuf2_memops videobuf2_v4l2 videobuf2_core snd_usb_audio videodev
snd_usbmidi_lib snd_rawmidi media snd_seq_device nct6775 hwmon_vid
cdc_acm ext4 crc16 jbd2 fscrypto mbcache nls_iso8859_1 intel_rapl
x86_pkg_temp_thermal nls_cp437 intel_powerclamp vfat coretemp fat
kvm_intel kvm irqbypass iTCO_wdt crct10dif_pclmul amdkfd crc32_pclmul
ghash_clmulni_intel amd_iommu_v2 iTCO_vendor_support amdgpu radeon
mei_wdt aesni_intel aes_x86_64 lrw gf128mul glue_helper ablk_helper
cryptd ttm drm_kms_helper intel_cstate intel_rapl_perf psmouse pcspkr
drm syscopyarea sysfillrect input_leds sysimgblt i2c_i801 evdev alx
joydev led_class mousedev fb_sys_fops lpc_ich i2c_smbus mac_hid mdio
i2c_algo_bit snd_hda_codec_realtek snd_hda_codec_generic
snd_hda_codec_hdmi
[   41.593415]  battery snd_hda_intel fjes nuvoton_cir snd_hda_codec
rc_core video soc_button_array snd_hda_core snd_hwdep mei_me button
snd_pcm mei snd_timer snd tpm_tis shpchp tpm_tis_core soundcore tpm
sch_fq_codel fuse ip_tables x_tables btrfs xor raid6_pq hid_generic
usbhid hid sd_mod serio_raw atkbd libps2 xhci_pci ahci libahci ehci_pci
xhci_hcd ehci_hcd libata crc32c_intel scsi_mod usbcore usb_common i8042
serio
[   41.595473] CPU: 1 PID: 469 Comm: deqp-vk Not tainted 4.9.0-amdgpu+
#2
[   41.596148] Hardware name: To Be Filled By O.E.M. To Be Filled By
O.E.M./B85 Killer, BIOS P1.50 07/11/2014
[   41.596829] task: 88042928 task.stack: c9000a5cc000
[   41.597517] RIP: 0010:[]  []
ttm_eu_reserve_buffers+0x136/0x370 [ttm]
[   41.598220] RSP: 0018:c9000a5cfb00  EFLAGS: 00010286
[   41.598978] RAX:  RBX: c9000a5cfb68 RCX:
c9000a5cfb78
[   41.599760] RDX: 88040c415d00 RSI: c9000a5cfb88 RDI:

[   41.600558] RBP: c9000a5cfb50 R08: 0004 R09:
001000a0
[   41.601348] R10: fff2 R11: 88042928 R12:

[   41.602154] R13: 0058 R14: 880410ee76c0 R15:
c9000a5cfba0
[   41.602926] FS:  7f75deecb780() GS:88043dc8()
knlGS:
[   41.603690] CS:  0010 DS:  ES:  CR0: 80050033
[   41.604447] CR2: 01e8 CR3: 00040e64a000 CR4:
001406e0
[   41.605205] Stack:
[   41.605972]  88042982a600 c9000a5cfb78 0100fe00
c9000a5cfba0
[   41.606766]  c9000a5cfb88 88041d1f 0001
c9000a5cfb68
[   41.607582]  880410ee76c0 c9000a5cfb78 c9000a5cfc40
a0808e38
[   41.608408] Call Trace:
[   41.609248]  [] amdgpu_gem_va_update_vm+0xb8/0x1c0
[amdgpu]
[   41.610091]  [] ? interval_tree_iter_next+0x21/0x70
[   41.610946]  [] amdgpu_gem_va_ioctl+0x2b7/0x350
[amdgpu]
[   41.611773]  [] ?
__percpu_counter_compare+0x3b/0x90
[   41.612578]  [] ?
__btrfs_btree_balance_dirty+0x41/0x80 [btrfs]
[   41.613409]  [] drm_ioctl+0x227/0x4c0 [drm]
[   41.614342]  [] ?
amdgpu_gem_metadata_ioctl+0x1e0/0x1e0 [amdgpu]
[   41.615166]  [] ? btrfs_file_write_iter+0x1df/0x560
[btrfs]
[   41.615989]  [] ? tty_write+0x1df/0x300
[   41.616862]  [] amdgpu_drm_ioctl+0x62/0xa0 [amdgpu]
[   41.617738]  [] do_vfs_ioctl+0xb2/0x600
[   41.618601]  [] ? vfs_write+0x14b/0x1b0
[   41.619448]  [] SyS_ioctl+0x88/0xa0
[   41.620311]  [] entry_SYSCALL_64_fastpath+0x1a/0xa9
[   41.621212] Code: 0a 48 89 71 08 49 89 0f 49 89 57 08 48 89 32 49 89
c7 4d 8b 3f 4c 39 fb 4c 89 7d c8 0f 84 67 01 00 00 48 83 7d d0 00 4d 8b
6f 10 <49> 8b bd 90 01 00 00 0f 84 a7 00 00 00 80 7d c7 00 48 8b 75 d0
[   41.622165] RIP  []
ttm_eu_reserve_buffers+0x136/0x370 [ttm]
[   41.623138]  RSP 
[   41.624017] CR2: 01e8
[   41.630632] ---[ end trace f1fc48bc614df131 ]---

However, when I specify AMDGPU_VM_DELAY_UPDATE too, it is gone, and
seems to work.

(side note: when is that flag useful and when not? I was under the
impression that map/unmap operations always waited until the last CS
submitted before the op was complete. In what case would it be useful to
map/unmap earlier than next CS?)

- Bas

On Thu, Feb 2, 2017, at 11:25, Christian König wrote:

From: Junwei Zhang 

Till GFX8 we can only enable PRT support globally, but with the next
hardware
generation we can do this on a per page basis.

Keep the interface consistent by adding PRT mappings and enable
support globally on current hardware when the first mapping is made.

v2: disable PRT support delayed and on all error paths
v3: PRT and other permissions are m

Re: [RFC]: More robust build sys for UMR

2017-02-05 Thread StDenis, Tom

Hi Edward,


Well the patches apply and work but I'm not really sure what problem it's meant 
to solve [😊] .  Building previously was actually simpler with "make" as opposed 
to "mkdir build && cd build && cmake .. && make".


On a BSD system (where this wouldn't really work without the corresponding 
debugfs entries) gmake could be used to build it provided ncurses/pciaccess 
were around.

If this legitimately makes it more stable to build on Linux systems then I'm 
all for it.  Can anyone elaborate on where the simple make system would fail?

(I'm not saying NAK I'm simply asking for my own edification).

Thanks,
Tom


From: Edward O'Callaghan 
Sent: Saturday, February 4, 2017 23:59
To: amd-gfx@lists.freedesktop.org
Cc: StDenis, Tom
Subject: [RFC]: More robust build sys for UMR

Keeping with the tradition of changing the build system on initial
release, here we go again.. This follow series introduces the cmake
build system that is intended to be a little more robust across
various distros and presumably the BSD's also. The installation
prefix is configurable in the usual cmake way:
 `cmake -DCMAKE_INSTALL_PREFIX:PATH=/usr ..`

Please kindly review,

Edward O'Callaghan (4):
 [PATCH 1/4] cmake_modules: Add libpciaccess finder
 [PATCH 2/4] cmake: Initial build system
 [PATCH 3/4] README: minor update for cmake buildsys
 [PATCH 4/4] drop orginal Makefile && stub bin/ directory
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [RFC]: More robust build sys for UMR

2017-02-05 Thread Bas Nieuwenhuizen

Hi,

I think the current build system is a bit too naive though. On my distro
archlinux the libdrm headers are installed in /usr/include/libdrm, which
causes the include to drm/drm.h in src/lib/query_drm.c to fail.

So if it is in /usr/include/drm on Ubuntu, we are going to need some
autodetection to find the right include path. Autotools definitely
sounds like overkill to me, and the current build system is pretty
simple indeed, but needing to change the source isn't ideal.

By the way, I don't think the current make system handles dependencies
on headers correctly? e.g. if I modify umrapp.h, make rebuilds nothing.
This is one of the things cmake gives you for free, though with a bit of
work make can do it too.

Yours sincerely,

Bas Nieuwenhuizen

On Sun, Feb 5, 2017, at 12:42, StDenis, Tom wrote:

> Hi Edward,

> 

> Well the patches apply and work but I'm not really sure what problem
> it's meant to solve 😊.  Building previously was actually simpler with
> "make" as opposed to "mkdir build && cd build && cmake .. && make".
> 

> On a BSD system (where this wouldn't really work without the
> corresponding debugfs entries) gmake could be used to build it
> provided ncurses/pciaccess were around.
> 

> If this legitimately makes it more stable to build on Linux systems
> then I'm all for it.  Can anyone elaborate on where the simple make
> system would fail?
> 

> (I'm not saying NAK I'm simply asking for my own edification).

> 

> 

> Thanks,

> Tom

> 

> 

> 

> *From:* Edward O'Callaghan  *Sent:*
> Saturday, February 4, 2017 23:59 *To:* amd-gfx@lists.freedesktop.org
> *Cc:* StDenis, Tom *Subject:* [RFC]: More robust build sys for UMR
>  

> 

> Keeping with the tradition of changing the build system on initial
> release, here we go again.. This follow series introduces the cmake
> build system that is intended to be a little more robust across
> various distros and presumably the BSD's also. The installation prefix
> is configurable in the usual cmake way:  `cmake -
> DCMAKE_INSTALL_PREFIX:PATH=/usr ..`
>
>  Please kindly review,
>
>  Edward O'Callaghan (4): [PATCH 1/4] cmake_modules: Add libpciaccess
>  finder [PATCH 2/4] cmake: Initial build system [PATCH 3/4] README:
>  minor update for cmake buildsys [PATCH 4/4] drop orginal Makefile &&
>  stub bin/ directory
> 

> _

> 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: [RFC]: More robust build sys for UMR

2017-02-05 Thread Edward O'Callaghan

On 02/05/2017 10:42 PM, StDenis, Tom wrote:
> Hi Edward,

Hey Tom,

> 
> 
> Well the patches apply and work but I'm not really sure what problem
> it's meant to solve 😊.  Building previously was actually simpler with

So the idea here was to implement something a little more robust and
extensible. For example with a couple of extra lines cmake can produce
rpm's, deb's and tar's too as build by-products. I can add this
functionality if you wish? Additionally another couple of lines a unit
tests could be hooked in if that is useful?

Fundamentally the idea was to have a "proper" build system that can
be extensible enough not to get in the way while the community
elaborates on UMR some more with additional features. I was thinking
about looking at unifying other peoples radeon debug/re tooling together
into UMR to be the one-stop tool as my Sunday afternoon weekend project
you see :) .

> "make" as opposed to "mkdir build && cd build && cmake .. && make".
>

I just added that step because its nice to build out of tree, you don't
have to.

> 
> On a BSD system (where this wouldn't really work without the
> corresponding debugfs entries) gmake could be used to build it provided
> ncurses/pciaccess were around.

Well in truth I didn't test on the BSD's yet, however it helps give some
a good foundation so they could port it should they wish. I am assuming
so since they seem to be updating their graphics stack these days.

> 
> 
> If this legitimately makes it more stable to build on Linux systems then
> I'm all for it.  Can anyone elaborate on where the simple make system
> would fail?

Well I hope so, that's why I RFC it. I expect this to work out the box
on all distributions right off the bat and I would be interested in
feedback for that.

> 
> (I'm not saying NAK I'm simply asking for my own edification).

Sure sure, this only took me a hour to put together because of _my_ itch
so don't stress.

> 
> Thanks,
> Tom

Kind Regards,
Edward.

> 
> 
> *From:* Edward O'Callaghan 
> *Sent:* Saturday, February 4, 2017 23:59
> *To:* amd-gfx@lists.freedesktop.org
> *Cc:* StDenis, Tom
> *Subject:* [RFC]: More robust build sys for UMR
>  
> Keeping with the tradition of changing the build system on initial
> release, here we go again.. This follow series introduces the cmake
> build system that is intended to be a little more robust across
> various distros and presumably the BSD's also. The installation
> prefix is configurable in the usual cmake way:
>  `cmake -DCMAKE_INSTALL_PREFIX:PATH=/usr ..`
> 
> Please kindly review,
> 
> Edward O'Callaghan (4):
>  [PATCH 1/4] cmake_modules: Add libpciaccess finder
>  [PATCH 2/4] cmake: Initial build system
>  [PATCH 3/4] README: minor update for cmake buildsys
>  [PATCH 4/4] drop orginal Makefile && stub bin/ directory

signature.asc
Description: OpenPGP digital signature
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [RFC]: More robust build sys for UMR

2017-02-05 Thread StDenis, Tom

Hi Edward,

Sounds good to me.  I'm sure our build-team folks would actually be in favour 
of something that could help make deb/rpm packages.

I typically only run Fedora and Ubuntu so if others who run 
Arch/Gentoo/SUSE/etc want to weigh in that'd be appreciated.  If nobody raises 
any objections I'll RB your series and push them to master sometime tomorrow.

By all means if you want to add other debug features go for it.  Keep in mind 
it already captures features from things like radeontop and setreg type tools 
[😊]

One of the open issues right now is the VM decoding in the read_vram() 
functionality (specifically when using follow_ib).  It's hard to instrument a 
test of that since VM addresses are live and ever chaotic but I've yet to see a 
successful IB read back.

Tom

From: Edward O'Callaghan 
Sent: Sunday, February 5, 2017 08:29
To: StDenis, Tom; amd-gfx@lists.freedesktop.org
Subject: Re: [RFC]: More robust build sys for UMR

On 02/05/2017 10:42 PM, StDenis, Tom wrote:
> Hi Edward,

Hey Tom,

>
>
> Well the patches apply and work but I'm not really sure what problem
> it's meant to solve 😊.  Building previously was actually simpler with

So the idea here was to implement something a little more robust and
extensible. For example with a couple of extra lines cmake can produce
rpm's, deb's and tar's too as build by-products. I can add this
functionality if you wish? Additionally another couple of lines a unit
tests could be hooked in if that is useful?

Fundamentally the idea was to have a "proper" build system that can
be extensible enough not to get in the way while the community
elaborates on UMR some more with additional features. I was thinking
about looking at unifying other peoples radeon debug/re tooling together
into UMR to be the one-stop tool as my Sunday afternoon weekend project
you see :) .

> "make" as opposed to "mkdir build && cd build && cmake .. && make".
>

I just added that step because its nice to build out of tree, you don't
have to.

>
> On a BSD system (where this wouldn't really work without the
> corresponding debugfs entries) gmake could be used to build it provided
> ncurses/pciaccess were around.

Well in truth I didn't test on the BSD's yet, however it helps give some
a good foundation so they could port it should they wish. I am assuming
so since they seem to be updating their graphics stack these days.

>
>
> If this legitimately makes it more stable to build on Linux systems then
> I'm all for it.  Can anyone elaborate on where the simple make system
> would fail?

Well I hope so, that's why I RFC it. I expect this to work out the box
on all distributions right off the bat and I would be interested in
feedback for that.

>
> (I'm not saying NAK I'm simply asking for my own edification).

Sure sure, this only took me a hour to put together because of _my_ itch
so don't stress.

>
> Thanks,
> Tom

Kind Regards,
Edward.

>
> 
> *From:* Edward O'Callaghan 
> *Sent:* Saturday, February 4, 2017 23:59
> *To:* amd-gfx@lists.freedesktop.org
> *Cc:* StDenis, Tom
> *Subject:* [RFC]: More robust build sys for UMR
>
> Keeping with the tradition of changing the build system on initial
> release, here we go again.. This follow series introduces the cmake
> build system that is intended to be a little more robust across
> various distros and presumably the BSD's also. The installation
> prefix is configurable in the usual cmake way:
>  `cmake -DCMAKE_INSTALL_PREFIX:PATH=/usr ..`
>
> Please kindly review,
>
> Edward O'Callaghan (4):
>  [PATCH 1/4] cmake_modules: Add libpciaccess finder
>  [PATCH 2/4] cmake: Initial build system
>  [PATCH 3/4] README: minor update for cmake buildsys
>  [PATCH 4/4] drop orginal Makefile && stub bin/ directory

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

Re: [RFC]: More robust build sys for UMR

2017-02-05 Thread StDenis, Tom

Hi Bas,


What would be a good way to work around the paths though? Is there a pkg config 
for libdrm?

Thanks,
Tom

From: amd-gfx  on behalf of Bas 
Nieuwenhuizen 
Sent: Sunday, February 5, 2017 08:12
To: amd-gfx@lists.freedesktop.org
Subject: Re: [RFC]: More robust build sys for UMR

Hi,

I think the current build system is a bit too naive though. On my distro 
archlinux the libdrm headers are installed in /usr/include/libdrm, which causes 
the include to drm/drm.h in src/lib/query_drm.c to fail.

So if it is in /usr/include/drm on Ubuntu, we are going to need some 
autodetection to find the right include path. Autotools definitely sounds like 
overkill to me, and the current build system is pretty simple indeed, but 
needing to change the source isn't ideal.

By the way, I don't think the current make system handles dependencies on 
headers correctly? e.g. if I modify umrapp.h, make rebuilds nothing.  This is 
one of the things cmake gives you for free, though with a bit of work make can 
do it too.

Yours sincerely,
Bas Nieuwenhuizen


On Sun, Feb 5, 2017, at 12:42, StDenis, Tom wrote:

Hi Edward,


Well the patches apply and work but I'm not really sure what problem it's meant 
to solve [😊] .  Building previously was actually simpler with "make" as opposed 
to "mkdir build && cd build && cmake .. && make".


On a BSD system (where this wouldn't really work without the corresponding 
debugfs entries) gmake could be used to build it provided ncurses/pciaccess 
were around.

If this legitimately makes it more stable to build on Linux systems then I'm 
all for it.  Can anyone elaborate on where the simple make system would fail?

(I'm not saying NAK I'm simply asking for my own edification).


Thanks,
Tom




From: Edward O'Callaghan 
Sent: Saturday, February 4, 2017 23:59
To: amd-gfx@lists.freedesktop.org
Cc: StDenis, Tom
Subject: [RFC]: More robust build sys for UMR


Keeping with the tradition of changing the build system on initial
release, here we go again.. This follow series introduces the cmake
build system that is intended to be a little more robust across
various distros and presumably the BSD's also. The installation
prefix is configurable in the usual cmake way:
 `cmake -DCMAKE_INSTALL_PREFIX:PATH=/usr ..`

Please kindly review,

Edward O'Callaghan (4):
 [PATCH 1/4] cmake_modules: Add libpciaccess finder
 [PATCH 2/4] cmake: Initial build system
 [PATCH 3/4] README: minor update for cmake buildsys
 [PATCH 4/4] drop orginal Makefile && stub bin/ directory

___
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: [RFC]: More robust build sys for UMR

2017-02-05 Thread StDenis, Tom

Hi all,


Never mind answered my own question:


$ pkg-config libdrm --cflags
-I/usr/include/libdrm

So we could in theory include "drm.h" and then just add that to the head of our 
CFLAGS.

Tom




From: amd-gfx  on behalf of StDenis, Tom 

Sent: Sunday, February 5, 2017 09:55
To: Bas Nieuwenhuizen; amd-gfx@lists.freedesktop.org
Subject: Re: [RFC]: More robust build sys for UMR


Hi Bas,


What would be a good way to work around the paths though? Is there a pkg config 
for libdrm?

Thanks,
Tom

From: amd-gfx  on behalf of Bas 
Nieuwenhuizen 
Sent: Sunday, February 5, 2017 08:12
To: amd-gfx@lists.freedesktop.org
Subject: Re: [RFC]: More robust build sys for UMR

Hi,

I think the current build system is a bit too naive though. On my distro 
archlinux the libdrm headers are installed in /usr/include/libdrm, which causes 
the include to drm/drm.h in src/lib/query_drm.c to fail.

So if it is in /usr/include/drm on Ubuntu, we are going to need some 
autodetection to find the right include path. Autotools definitely sounds like 
overkill to me, and the current build system is pretty simple indeed, but 
needing to change the source isn't ideal.

By the way, I don't think the current make system handles dependencies on 
headers correctly? e.g. if I modify umrapp.h, make rebuilds nothing.  This is 
one of the things cmake gives you for free, though with a bit of work make can 
do it too.

Yours sincerely,
Bas Nieuwenhuizen


On Sun, Feb 5, 2017, at 12:42, StDenis, Tom wrote:

Hi Edward,


Well the patches apply and work but I'm not really sure what problem it's meant 
to solve [😊] .  Building previously was actually simpler with "make" as opposed 
to "mkdir build && cd build && cmake .. && make".


On a BSD system (where this wouldn't really work without the corresponding 
debugfs entries) gmake could be used to build it provided ncurses/pciaccess 
were around.

If this legitimately makes it more stable to build on Linux systems then I'm 
all for it.  Can anyone elaborate on where the simple make system would fail?

(I'm not saying NAK I'm simply asking for my own edification).


Thanks,
Tom




From: Edward O'Callaghan 
Sent: Saturday, February 4, 2017 23:59
To: amd-gfx@lists.freedesktop.org
Cc: StDenis, Tom
Subject: [RFC]: More robust build sys for UMR


Keeping with the tradition of changing the build system on initial
release, here we go again.. This follow series introduces the cmake
build system that is intended to be a little more robust across
various distros and presumably the BSD's also. The installation
prefix is configurable in the usual cmake way:
 `cmake -DCMAKE_INSTALL_PREFIX:PATH=/usr ..`

Please kindly review,

Edward O'Callaghan (4):
 [PATCH 1/4] cmake_modules: Add libpciaccess finder
 [PATCH 2/4] cmake: Initial build system
 [PATCH 3/4] README: minor update for cmake buildsys
 [PATCH 4/4] drop orginal Makefile && stub bin/ directory

___
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

Add autodetect for libdrm to umr

2017-02-05 Thread Tom St Denis

While the cmake commits haven't been pushed yet I'd like to get feedback
on this patch which helps find the libdrm headers.

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

[PATCH] autodetect path to libdrm

2017-02-05 Thread Tom St Denis

Signed-off-by: Tom St Denis 
---
 CMakeLists.txt  | 4 +++-
 src/lib/query_drm.c | 4 ++--
 2 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/CMakeLists.txt b/CMakeLists.txt
index bef94fdba788..d2f393f0fa9b 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -25,6 +25,8 @@ include_directories(${CURSES_INCLUDE_DIRS})
 find_package(PCIAccess REQUIRED)
 include_directories(${PCIACCESS_INCLUDE_DIR})
 
+pkg_check_modules(DRM REQUIRED libdrm)
+
 set(REQUIRED_EXTERNAL_LIBS
   ${CURSES_LIBRARIES}
   ${PCIACCESS_LIBRARIES}
@@ -34,7 +36,7 @@ set(REQUIRED_EXTERNAL_LIBS
 set(CMAKE_POSITION_INDEPENDENT_CODE ON)
 
 # CFLAGS += -Wall -W -O2 -g3 -Isrc/ -DPIC -fPIC
-set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -Wall -W -O2 -g3")
+set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} ${DRM_CFLAGS} -Wall -W -O2 -g3")
 
 add_subdirectory(src)
 add_subdirectory(doc)
diff --git a/src/lib/query_drm.c b/src/lib/query_drm.c
index b9d80a8fc0c8..755c65fbc662 100644
--- a/src/lib/query_drm.c
+++ b/src/lib/query_drm.c
@@ -25,8 +25,8 @@
 #include "umr.h"
 #include 
 #include 
-#include 
-#include 
+#include 
+#include 
 
 #define DRM_IOC(dir, group, nr, size) _IOC(dir, group, nr, size)
 #define DRM_IOC_WRITE   _IOC_WRITE
-- 
2.11.0

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

Re: [RFC]: More robust build sys for UMR

2017-02-05 Thread Andres Rodriguez


Hey Tom,

It's great to see umr make it to the public. I've given it a quick spin 
and it is pretty awesome, although I don't have much time this weekend 
to play with it.


Wanted to weigh in my 2c regarding cmake.

Some of the things I like about cmake:

 * Compatible with out of tree builds by default
- Super simple *guaranteed* make clean equivalent with rm -f build/
- Simple gitignore files
- Both of these reasons result in sidestepping some common and very
  annoying bugs in makefiles
 * Easy packaging for release with cpack
 * Removes a lot of the boilerplate (specially for libraries)
 * Good compatibility across distros
   - Without a lot of the "horrible" things from automake
 * There is a good community around cmake that has some cool modules
   available for it

Some of the things I don't like about cmake:

 * The syntax is horrible
 * I think ctest is overly complicated compared to other frameworks like
   gtest.
   - Doing basic things like attaching a debugger are not
 straightforward

Weighing the above I tend to side on pro-cmake.

Again, thanks for the work on the great tool. I might have a bit more
feedback once I start using it more heavily next week.

Regards,
Andres


On 2/5/2017 9:52 AM, StDenis, Tom wrote:

Hi Edward,


Sounds good to me.  I'm sure our build-team folks would actually be in
favour of something that could help make deb/rpm packages.


I typically only run Fedora and Ubuntu so if others who run
Arch/Gentoo/SUSE/etc want to weigh in that'd be appreciated.  If nobody
raises any objections I'll RB your series and push them to master
sometime tomorrow.


By all means if you want to add other debug features go for it.  Keep in
mind it already captures features from things like radeontop and setreg
type tools 😊


One of the open issues right now is the VM decoding in the read_vram()
functionality (specifically when using follow_ib).  It's hard to
instrument a test of that since VM addresses are live and ever chaotic
but I've yet to see a successful IB read back.


Tom




*From:* Edward O'Callaghan 
*Sent:* Sunday, February 5, 2017 08:29
*To:* StDenis, Tom; amd-gfx@lists.freedesktop.org
*Subject:* Re: [RFC]: More robust build sys for UMR



On 02/05/2017 10:42 PM, StDenis, Tom wrote:

Hi Edward,


Hey Tom,




Well the patches apply and work but I'm not really sure what problem
it's meant to solve 😊.  Building previously was actually simpler with


So the idea here was to implement something a little more robust and
extensible. For example with a couple of extra lines cmake can produce
rpm's, deb's and tar's too as build by-products. I can add this
functionality if you wish? Additionally another couple of lines a unit
tests could be hooked in if that is useful?

Fundamentally the idea was to have a "proper" build system that can
be extensible enough not to get in the way while the community
elaborates on UMR some more with additional features. I was thinking
about looking at unifying other peoples radeon debug/re tooling together
into UMR to be the one-stop tool as my Sunday afternoon weekend project
you see :) .


"make" as opposed to "mkdir build && cd build && cmake .. && make".



I just added that step because its nice to build out of tree, you don't
have to.



On a BSD system (where this wouldn't really work without the
corresponding debugfs entries) gmake could be used to build it provided
ncurses/pciaccess were around.


Well in truth I didn't test on the BSD's yet, however it helps give some
a good foundation so they could port it should they wish. I am assuming
so since they seem to be updating their graphics stack these days.




If this legitimately makes it more stable to build on Linux systems then
I'm all for it.  Can anyone elaborate on where the simple make system
would fail?


Well I hope so, that's why I RFC it. I expect this to work out the box
on all distributions right off the bat and I would be interested in
feedback for that.



(I'm not saying NAK I'm simply asking for my own edification).


Sure sure, this only took me a hour to put together because of _my_ itch
so don't stress.



Thanks,
Tom


Kind Regards,
Edward.




*From:* Edward O'Callaghan 
*Sent:* Saturday, February 4, 2017 23:59
*To:* amd-gfx@lists.freedesktop.org
*Cc:* StDenis, Tom
*Subject:* [RFC]: More robust build sys for UMR

Keeping with the tradition of changing the build system on initial
release, here we go again.. This follow series introduces the cmake
build system that is intended to be a little more robust across
various distros and presumably the BSD's also. The installation
prefix is configurable in the usual cmake way:
 `cmake -DCMAKE_INSTALL_PREFIX:PATH=/usr ..`

Please kindly review,

Edward O'Callaghan (4):
 [PATCH 1/4] cmake_modules: Add libpciaccess finder
 [PATCH 2/4] cmake: Initial build system
 [PATCH 3/

Re: [RFC]: More robust build sys for UMR

2017-02-05 Thread StDenis, Tom

Hi Andres,


Thanks for the feedback.  I've decided to push Edward's patches to master since 
it's in the projects best interest to minimize build/package friction going 
forward.


Of course now I have to rebase our NPI branches internally since they're based 
on the older makefile ...  That's more of an AMD problem though.


If someone could review my patch that detects the libdrm path I'd like to get 
that in sooner than later so the package is more buildable by time people get 
to work on Monday :-)


Tom



From: Andres Rodriguez 
Sent: Sunday, February 5, 2017 11:11
To: StDenis, Tom; Edward O'Callaghan; amd-gfx@lists.freedesktop.org
Subject: Re: [RFC]: More robust build sys for UMR

Hey Tom,

It's great to see umr make it to the public. I've given it a quick spin
and it is pretty awesome, although I don't have much time this weekend
to play with it.

Wanted to weigh in my 2c regarding cmake.

Some of the things I like about cmake:

  * Compatible with out of tree builds by default
 - Super simple *guaranteed* make clean equivalent with rm -f build/
 - Simple gitignore files
 - Both of these reasons result in sidestepping some common and very
   annoying bugs in makefiles
  * Easy packaging for release with cpack
  * Removes a lot of the boilerplate (specially for libraries)
  * Good compatibility across distros
- Without a lot of the "horrible" things from automake
  * There is a good community around cmake that has some cool modules
available for it

Some of the things I don't like about cmake:

  * The syntax is horrible
  * I think ctest is overly complicated compared to other frameworks like
gtest.
- Doing basic things like attaching a debugger are not
  straightforward

Weighing the above I tend to side on pro-cmake.

Again, thanks for the work on the great tool. I might have a bit more
feedback once I start using it more heavily next week.

Regards,
Andres


On 2/5/2017 9:52 AM, StDenis, Tom wrote:
> Hi Edward,
>
>
> Sounds good to me.  I'm sure our build-team folks would actually be in
> favour of something that could help make deb/rpm packages.
>
>
> I typically only run Fedora and Ubuntu so if others who run
> Arch/Gentoo/SUSE/etc want to weigh in that'd be appreciated.  If nobody
> raises any objections I'll RB your series and push them to master
> sometime tomorrow.
>
>
> By all means if you want to add other debug features go for it.  Keep in
> mind it already captures features from things like radeontop and setreg
> type tools 😊
>
>
> One of the open issues right now is the VM decoding in the read_vram()
> functionality (specifically when using follow_ib).  It's hard to
> instrument a test of that since VM addresses are live and ever chaotic
> but I've yet to see a successful IB read back.
>
>
> Tom
>
>
>
> 
> *From:* Edward O'Callaghan 
> *Sent:* Sunday, February 5, 2017 08:29
> *To:* StDenis, Tom; amd-gfx@lists.freedesktop.org
> *Subject:* Re: [RFC]: More robust build sys for UMR
>
>
>
> On 02/05/2017 10:42 PM, StDenis, Tom wrote:
>> Hi Edward,
>
> Hey Tom,
>
>>
>>
>> Well the patches apply and work but I'm not really sure what problem
>> it's meant to solve 😊.  Building previously was actually simpler with
>
> So the idea here was to implement something a little more robust and
> extensible. For example with a couple of extra lines cmake can produce
> rpm's, deb's and tar's too as build by-products. I can add this
> functionality if you wish? Additionally another couple of lines a unit
> tests could be hooked in if that is useful?
>
> Fundamentally the idea was to have a "proper" build system that can
> be extensible enough not to get in the way while the community
> elaborates on UMR some more with additional features. I was thinking
> about looking at unifying other peoples radeon debug/re tooling together
> into UMR to be the one-stop tool as my Sunday afternoon weekend project
> you see :) .
>
>> "make" as opposed to "mkdir build && cd build && cmake .. && make".
>>
>
> I just added that step because its nice to build out of tree, you don't
> have to.
>
>>
>> On a BSD system (where this wouldn't really work without the
>> corresponding debugfs entries) gmake could be used to build it provided
>> ncurses/pciaccess were around.
>
> Well in truth I didn't test on the BSD's yet, however it helps give some
> a good foundation so they could port it should they wish. I am assuming
> so since they seem to be updating their graphics stack these days.
>
>>
>>
>> If this legitimately makes it more stable to build on Linux systems then
>> I'm all for it.  Can anyone elaborate on where the simple make system
>> would fail?
>
> Well I hope so, that's why I RFC it. I expect this to work out the box
> on all distributions right off the bat and I would be interested in
> feedback for that.
>
>>
>> (I'm not saying NAK I'm simply asking for my own edification).

Re: [PATCH] autodetect path to libdrm

2017-02-05 Thread Andres Rodriguez


Hey Tom,

Overall in cmake calling pkg_check_modules() directly is usually not a
good practice. The common approach is to have a file in
cmake/modules/Find$(name).cmake that takes care of everything.

For example, you could use this FindLibdrm.cmake from the KDE project:
https://github.com/KDE/kwin/blob/master/cmake/modules/FindLibdrm.cmake

Alternatively a simple modification of the FindPCIAccess.cmake file that
Edward sent out could also work.

Sorry for the late feedback on a Sunday.

Regards,
Andres

On 2/5/2017 10:34 AM, Tom St Denis wrote:

Signed-off-by: Tom St Denis 
---
 CMakeLists.txt  | 4 +++-
 src/lib/query_drm.c | 4 ++--
 2 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/CMakeLists.txt b/CMakeLists.txt
index bef94fdba788..d2f393f0fa9b 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -25,6 +25,8 @@ include_directories(${CURSES_INCLUDE_DIRS})
 find_package(PCIAccess REQUIRED)
 include_directories(${PCIACCESS_INCLUDE_DIR})

+pkg_check_modules(DRM REQUIRED libdrm)
+
 set(REQUIRED_EXTERNAL_LIBS
   ${CURSES_LIBRARIES}
   ${PCIACCESS_LIBRARIES}
@@ -34,7 +36,7 @@ set(REQUIRED_EXTERNAL_LIBS
 set(CMAKE_POSITION_INDEPENDENT_CODE ON)

 # CFLAGS += -Wall -W -O2 -g3 -Isrc/ -DPIC -fPIC
-set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -Wall -W -O2 -g3")
+set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} ${DRM_CFLAGS} -Wall -W -O2 -g3")

 add_subdirectory(src)
 add_subdirectory(doc)
diff --git a/src/lib/query_drm.c b/src/lib/query_drm.c
index b9d80a8fc0c8..755c65fbc662 100644
--- a/src/lib/query_drm.c
+++ b/src/lib/query_drm.c
@@ -25,8 +25,8 @@
 #include "umr.h"
 #include 
 #include 
-#include 
-#include 
+#include 
+#include 

 #define DRM_IOC(dir, group, nr, size) _IOC(dir, group, nr, size)
 #define DRM_IOC_WRITE   _IOC_WRITE


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

Re: [PATCH] autodetect path to libdrm

2017-02-05 Thread StDenis, Tom

Hi Andres,


Oh I can see how that's much simpler than a Makefile [😊]  (100 lines of "find 
libdrm" later...).


I'd rather not wholesale rip off KDE since their license (appears to be BSDish) 
is different.


I may just clone the one Edward provided as you suggested instead.


Tom



From: Andres Rodriguez 
Sent: Sunday, February 5, 2017 16:26
To: Tom St Denis; amd-gfx@lists.freedesktop.org
Cc: StDenis, Tom
Subject: Re: [PATCH] autodetect path to libdrm

Hey Tom,

Overall in cmake calling pkg_check_modules() directly is usually not a
good practice. The common approach is to have a file in
cmake/modules/Find$(name).cmake that takes care of everything.

For example, you could use this FindLibdrm.cmake from the KDE project:
https://github.com/KDE/kwin/blob/master/cmake/modules/FindLibdrm.cmake
[https://avatars1.githubusercontent.com/u/14312869?v=3&s=400]

KDE/kwin
github.com
kwin - This repository has no description




Alternatively a simple modification of the FindPCIAccess.cmake file that
Edward sent out could also work.

Sorry for the late feedback on a Sunday.

Regards,
Andres

On 2/5/2017 10:34 AM, Tom St Denis wrote:
> Signed-off-by: Tom St Denis 
> ---
>  CMakeLists.txt  | 4 +++-
>  src/lib/query_drm.c | 4 ++--
>  2 files changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/CMakeLists.txt b/CMakeLists.txt
> index bef94fdba788..d2f393f0fa9b 100644
> --- a/CMakeLists.txt
> +++ b/CMakeLists.txt
> @@ -25,6 +25,8 @@ include_directories(${CURSES_INCLUDE_DIRS})
>  find_package(PCIAccess REQUIRED)
>  include_directories(${PCIACCESS_INCLUDE_DIR})
>
> +pkg_check_modules(DRM REQUIRED libdrm)
> +
>  set(REQUIRED_EXTERNAL_LIBS
>${CURSES_LIBRARIES}
>${PCIACCESS_LIBRARIES}
> @@ -34,7 +36,7 @@ set(REQUIRED_EXTERNAL_LIBS
>  set(CMAKE_POSITION_INDEPENDENT_CODE ON)
>
>  # CFLAGS += -Wall -W -O2 -g3 -Isrc/ -DPIC -fPIC
> -set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -Wall -W -O2 -g3")
> +set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} ${DRM_CFLAGS} -Wall -W -O2 -g3")
>
>  add_subdirectory(src)
>  add_subdirectory(doc)
> diff --git a/src/lib/query_drm.c b/src/lib/query_drm.c
> index b9d80a8fc0c8..755c65fbc662 100644
> --- a/src/lib/query_drm.c
> +++ b/src/lib/query_drm.c
> @@ -25,8 +25,8 @@
>  #include "umr.h"
>  #include 
>  #include 
> -#include 
> -#include 
> +#include 
> +#include 
>
>  #define DRM_IOC(dir, group, nr, size) _IOC(dir, group, nr, size)
>  #define DRM_IOC_WRITE   _IOC_WRITE
>
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH] autodetect path to libdrm

2017-02-05 Thread Andres Rodriguez


Yeah that approach should be perfectly fine.

I don't think libdrm needs anything fancier than that.

Regards,
Andres

On 2/5/2017 4:53 PM, StDenis, Tom wrote:

Hi Andres,


Oh I can see how that's much simpler than a Makefile 😊 (100 lines of
"find libdrm" later...).


I'd rather not wholesale rip off KDE since their license (appears to be
BSDish) is different.


I may just clone the one Edward provided as you suggested instead.


Tom




*From:* Andres Rodriguez 
*Sent:* Sunday, February 5, 2017 16:26
*To:* Tom St Denis; amd-gfx@lists.freedesktop.org
*Cc:* StDenis, Tom
*Subject:* Re: [PATCH] autodetect path to libdrm

Hey Tom,

Overall in cmake calling pkg_check_modules() directly is usually not a
good practice. The common approach is to have a file in
cmake/modules/Find$(name).cmake that takes care of everything.

For example, you could use this FindLibdrm.cmake from the KDE project:
https://github.com/KDE/kwin/blob/master/cmake/modules/FindLibdrm.cmake


KDE/kwin

github.com
kwin - This repository has no description




Alternatively a simple modification of the FindPCIAccess.cmake file that
Edward sent out could also work.

Sorry for the late feedback on a Sunday.

Regards,
Andres

On 2/5/2017 10:34 AM, Tom St Denis wrote:

Signed-off-by: Tom St Denis 
---
 CMakeLists.txt  | 4 +++-
 src/lib/query_drm.c | 4 ++--
 2 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/CMakeLists.txt b/CMakeLists.txt
index bef94fdba788..d2f393f0fa9b 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -25,6 +25,8 @@ include_directories(${CURSES_INCLUDE_DIRS})
 find_package(PCIAccess REQUIRED)
 include_directories(${PCIACCESS_INCLUDE_DIR})

+pkg_check_modules(DRM REQUIRED libdrm)
+
 set(REQUIRED_EXTERNAL_LIBS
   ${CURSES_LIBRARIES}
   ${PCIACCESS_LIBRARIES}
@@ -34,7 +36,7 @@ set(REQUIRED_EXTERNAL_LIBS
 set(CMAKE_POSITION_INDEPENDENT_CODE ON)

 # CFLAGS += -Wall -W -O2 -g3 -Isrc/ -DPIC -fPIC
-set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -Wall -W -O2 -g3")
+set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} ${DRM_CFLAGS} -Wall -W -O2 -g3")

 add_subdirectory(src)
 add_subdirectory(doc)
diff --git a/src/lib/query_drm.c b/src/lib/query_drm.c
index b9d80a8fc0c8..755c65fbc662 100644
--- a/src/lib/query_drm.c
+++ b/src/lib/query_drm.c
@@ -25,8 +25,8 @@
 #include "umr.h"
 #include 
 #include 
-#include 
-#include 
+#include 
+#include 

 #define DRM_IOC(dir, group, nr, size) _IOC(dir, group, nr, size)
 #define DRM_IOC_WRITE   _IOC_WRITE


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

[PATCH] Autodetect libdrm path (v2)

2017-02-05 Thread Tom St Denis

(v2):  Use findLibDRM script instead of directly finding path

Signed-off-by: Tom St Denis 
---
 CMakeLists.txt |  3 +++
 cmake_modules/FindLibDRM.cmake | 35 +++
 src/lib/query_drm.c|  4 ++--
 3 files changed, 40 insertions(+), 2 deletions(-)
 create mode 100644 cmake_modules/FindLibDRM.cmake

diff --git a/CMakeLists.txt b/CMakeLists.txt
index bef94fdba788..ef78c97ad763 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -25,6 +25,9 @@ include_directories(${CURSES_INCLUDE_DIRS})
 find_package(PCIAccess REQUIRED)
 include_directories(${PCIACCESS_INCLUDE_DIR})
 
+find_package(LibDRM REQUIRED)
+include_directories(${LIBDRM_INCLUDE_DIR})
+
 set(REQUIRED_EXTERNAL_LIBS
   ${CURSES_LIBRARIES}
   ${PCIACCESS_LIBRARIES}
diff --git a/cmake_modules/FindLibDRM.cmake b/cmake_modules/FindLibDRM.cmake
new file mode 100644
index ..e840c4d1bfd0
--- /dev/null
+++ b/cmake_modules/FindLibDRM.cmake
@@ -0,0 +1,35 @@
+# Try to find libdrm
+#
+# Once done, this will define
+#
+# LIBDRM_FOUND
+# LIBDRM_INCLUDE_DIR
+# LIBDRM_LIBRARIES
+
+find_package(PkgConfig)
+
+pkg_check_modules(PC_LIBDRM QUIET libdrm)
+
+find_path(LIBDRM_INCLUDE_DIR NAMES amdgpu_drm.h
+HINTS
+${PC_LIBDRM_INCLUDEDIR}
+${PC_LIBDRM_INCLUDE_DIRS}
+/usr/include
+)
+
+find_library(LIBDRM_LIBRARY NAMES libdrm_amdgpu.so.1
+HINTS
+${PC_LIBDRM_LIBDIR}
+${PC_LIBDRM_LIBRARY_DIRS}
+/usr/lib64
+/usr/lib
+)
+
+SET(LIBDRM_LIBRARIES optimized ${LIBDRM_LIBRARY})
+
+include(FindPackageHandleStandardArgs)
+find_package_handle_standard_args(LIBDRM DEFAULT_MSG
+   LIBDRM_LIBRARIES LIBDRM_INCLUDE_DIR
+)
+
+mark_as_advanced(LIBDRM_INCLUDE_DIR LIBDRM_LIBRARIES)
diff --git a/src/lib/query_drm.c b/src/lib/query_drm.c
index b9d80a8fc0c8..755c65fbc662 100644
--- a/src/lib/query_drm.c
+++ b/src/lib/query_drm.c
@@ -25,8 +25,8 @@
 #include "umr.h"
 #include 
 #include 
-#include 
-#include 
+#include 
+#include 
 
 #define DRM_IOC(dir, group, nr, size) _IOC(dir, group, nr, size)
 #define DRM_IOC_WRITE   _IOC_WRITE
-- 
2.11.0

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

Re: [PATCH] Autodetect libdrm path (v2)

2017-02-05 Thread Andres Rodriguez


Reviewed-by: Andres Rodriguez

On 2/5/2017 5:24 PM, Tom St Denis wrote:

(v2):  Use findLibDRM script instead of directly finding path

Signed-off-by: Tom St Denis 
---
 CMakeLists.txt |  3 +++
 cmake_modules/FindLibDRM.cmake | 35 +++
 src/lib/query_drm.c|  4 ++--
 3 files changed, 40 insertions(+), 2 deletions(-)
 create mode 100644 cmake_modules/FindLibDRM.cmake

diff --git a/CMakeLists.txt b/CMakeLists.txt
index bef94fdba788..ef78c97ad763 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -25,6 +25,9 @@ include_directories(${CURSES_INCLUDE_DIRS})
 find_package(PCIAccess REQUIRED)
 include_directories(${PCIACCESS_INCLUDE_DIR})

+find_package(LibDRM REQUIRED)
+include_directories(${LIBDRM_INCLUDE_DIR})
+
 set(REQUIRED_EXTERNAL_LIBS
   ${CURSES_LIBRARIES}
   ${PCIACCESS_LIBRARIES}
diff --git a/cmake_modules/FindLibDRM.cmake b/cmake_modules/FindLibDRM.cmake
new file mode 100644
index ..e840c4d1bfd0
--- /dev/null
+++ b/cmake_modules/FindLibDRM.cmake
@@ -0,0 +1,35 @@
+# Try to find libdrm
+#
+# Once done, this will define
+#
+# LIBDRM_FOUND
+# LIBDRM_INCLUDE_DIR
+# LIBDRM_LIBRARIES
+
+find_package(PkgConfig)
+
+pkg_check_modules(PC_LIBDRM QUIET libdrm)
+
+find_path(LIBDRM_INCLUDE_DIR NAMES amdgpu_drm.h
+HINTS
+${PC_LIBDRM_INCLUDEDIR}
+${PC_LIBDRM_INCLUDE_DIRS}
+/usr/include
+)
+
+find_library(LIBDRM_LIBRARY NAMES libdrm_amdgpu.so.1
+HINTS
+${PC_LIBDRM_LIBDIR}
+${PC_LIBDRM_LIBRARY_DIRS}
+/usr/lib64
+/usr/lib
+)
+
+SET(LIBDRM_LIBRARIES optimized ${LIBDRM_LIBRARY})
+
+include(FindPackageHandleStandardArgs)
+find_package_handle_standard_args(LIBDRM DEFAULT_MSG
+   LIBDRM_LIBRARIES LIBDRM_INCLUDE_DIR
+)
+
+mark_as_advanced(LIBDRM_INCLUDE_DIR LIBDRM_LIBRARIES)
diff --git a/src/lib/query_drm.c b/src/lib/query_drm.c
index b9d80a8fc0c8..755c65fbc662 100644
--- a/src/lib/query_drm.c
+++ b/src/lib/query_drm.c
@@ -25,8 +25,8 @@
 #include "umr.h"
 #include 
 #include 
-#include 
-#include 
+#include 
+#include 

 #define DRM_IOC(dir, group, nr, size) _IOC(dir, group, nr, size)
 #define DRM_IOC_WRITE   _IOC_WRITE


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

Re: [PATCH] Autodetect libdrm path (v2)

2017-02-05 Thread StDenis, Tom

Thanks.  Pushed it.


Tom



From: Andres Rodriguez 
Sent: Sunday, February 5, 2017 17:28
To: Tom St Denis; amd-gfx@lists.freedesktop.org
Cc: StDenis, Tom
Subject: Re: [PATCH] Autodetect libdrm path (v2)

Reviewed-by: Andres Rodriguez

On 2/5/2017 5:24 PM, Tom St Denis wrote:
> (v2):  Use findLibDRM script instead of directly finding path
>
> Signed-off-by: Tom St Denis 
> ---
>  CMakeLists.txt |  3 +++
>  cmake_modules/FindLibDRM.cmake | 35 +++
>  src/lib/query_drm.c|  4 ++--
>  3 files changed, 40 insertions(+), 2 deletions(-)
>  create mode 100644 cmake_modules/FindLibDRM.cmake
>
> diff --git a/CMakeLists.txt b/CMakeLists.txt
> index bef94fdba788..ef78c97ad763 100644
> --- a/CMakeLists.txt
> +++ b/CMakeLists.txt
> @@ -25,6 +25,9 @@ include_directories(${CURSES_INCLUDE_DIRS})
>  find_package(PCIAccess REQUIRED)
>  include_directories(${PCIACCESS_INCLUDE_DIR})
>
> +find_package(LibDRM REQUIRED)
> +include_directories(${LIBDRM_INCLUDE_DIR})
> +
>  set(REQUIRED_EXTERNAL_LIBS
>${CURSES_LIBRARIES}
>${PCIACCESS_LIBRARIES}
> diff --git a/cmake_modules/FindLibDRM.cmake b/cmake_modules/FindLibDRM.cmake
> new file mode 100644
> index ..e840c4d1bfd0
> --- /dev/null
> +++ b/cmake_modules/FindLibDRM.cmake
> @@ -0,0 +1,35 @@
> +# Try to find libdrm
> +#
> +# Once done, this will define
> +#
> +# LIBDRM_FOUND
> +# LIBDRM_INCLUDE_DIR
> +# LIBDRM_LIBRARIES
> +
> +find_package(PkgConfig)
> +
> +pkg_check_modules(PC_LIBDRM QUIET libdrm)
> +
> +find_path(LIBDRM_INCLUDE_DIR NAMES amdgpu_drm.h
> +HINTS
> +${PC_LIBDRM_INCLUDEDIR}
> +${PC_LIBDRM_INCLUDE_DIRS}
> +/usr/include
> +)
> +
> +find_library(LIBDRM_LIBRARY NAMES libdrm_amdgpu.so.1
> +HINTS
> +${PC_LIBDRM_LIBDIR}
> +${PC_LIBDRM_LIBRARY_DIRS}
> +/usr/lib64
> +/usr/lib
> +)
> +
> +SET(LIBDRM_LIBRARIES optimized ${LIBDRM_LIBRARY})
> +
> +include(FindPackageHandleStandardArgs)
> +find_package_handle_standard_args(LIBDRM DEFAULT_MSG
> + LIBDRM_LIBRARIES LIBDRM_INCLUDE_DIR
> +)
> +
> +mark_as_advanced(LIBDRM_INCLUDE_DIR LIBDRM_LIBRARIES)
> diff --git a/src/lib/query_drm.c b/src/lib/query_drm.c
> index b9d80a8fc0c8..755c65fbc662 100644
> --- a/src/lib/query_drm.c
> +++ b/src/lib/query_drm.c
> @@ -25,8 +25,8 @@
>  #include "umr.h"
>  #include 
>  #include 
> -#include 
> -#include 
> +#include 
> +#include 
>
>  #define DRM_IOC(dir, group, nr, size) _IOC(dir, group, nr, size)
>  #define DRM_IOC_WRITE   _IOC_WRITE
>
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [RFC]: More robust build sys for UMR

2017-02-05 Thread Michel Dänzer

On 06/02/17 12:16 AM, StDenis, Tom wrote:
> 
> $ pkg-config libdrm --cflags
> -I/usr/include/libdrm
> 
> So we could in theory include "drm.h" and then just add that to the head
> of our CFLAGS.

Make that , but yes, that's the correct way, not just in theory. :)


-- 
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

答复: [PATCH 07/21] drm/amdgpu:fix gart table vram pin

2017-02-05 Thread Liu, Monk

anyone to review those patches ?

they are for SRIOV case mainly, and they are prepare for later TDR feature 
(GPU-reset on SR-IOV)



发件人: Monk Liu 
发送时间: 2017年2月4日 18:34:59
收件人: amd-gfx@lists.freedesktop.org
抄送: Liu, Monk
主题: [PATCH 07/21] drm/amdgpu:fix gart table vram pin

if this call is from resume, shouldn't enter pin logic at all

Change-Id: I40a5cdc2a716c4c20d2812fd74ece4ea284b6765
Signed-off-by: Monk Liu 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c
index 964d2a9..5e907f7 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c
@@ -151,6 +151,11 @@ int amdgpu_gart_table_vram_pin(struct amdgpu_device *adev)
 uint64_t gpu_addr;
 int r;

+   if (adev->gart.table_addr) {
+   /* it's a resume call, gart already pin */
+   return 0;
+   }
+
 r = amdgpu_bo_reserve(adev->gart.robj, false);
 if (unlikely(r != 0))
 return r;
--
2.7.4

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

RE: [PATCH 02/21] drm/amdgpu:fix golden init for sriov

2017-02-05 Thread Yu, Xiangliang

Does FIJI need the golden init?


Thanks!
Xiangliang Yu

> -Original Message-
> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Monk Liu
> Sent: Saturday, February 04, 2017 6:22 PM
> To: amd-gfx@lists.freedesktop.org
> Cc: Liu, Monk 
> Subject: [PATCH 02/21] drm/amdgpu:fix golden init for sriov
> 
> although only vi supports SRIOV now,but we shouldn't make code has such
> assumption.
> 
> Change-Id: Ie73c185dc2e7f64756253045b32cabe70d618d19
> Signed-off-by: Monk Liu 
> ---
>  drivers/gpu/drm/amd/amdgpu/vi.c | 11 ---
>  1 file changed, 4 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/vi.c
> b/drivers/gpu/drm/amd/amdgpu/vi.c index 89b0dfe..7810030 100644
> --- a/drivers/gpu/drm/amd/amdgpu/vi.c
> +++ b/drivers/gpu/drm/amd/amdgpu/vi.c
> @@ -274,12 +274,6 @@ static void vi_init_golden_registers(struct
> amdgpu_device *adev)
>   /* Some of the registers might be dependent on GRBM_GFX_INDEX
> */
>   mutex_lock(&adev->grbm_idx_mutex);
> 
> - if (amdgpu_sriov_vf(adev)) {
> - xgpu_vi_init_golden_registers(adev);
> - mutex_unlock(&adev->grbm_idx_mutex);
> - return;
> - }
> -
>   switch (adev->asic_type) {
>   case CHIP_TOPAZ:
>   amdgpu_program_register_sequence(adev,
> @@ -292,7 +286,10 @@ static void vi_init_golden_registers(struct
> amdgpu_device *adev)
>(const
> u32)ARRAY_SIZE(fiji_mgcg_cgcg_init));
>   break;
>   case CHIP_TONGA:
> - amdgpu_program_register_sequence(adev,
> + if (amdgpu_sriov_vf(adev))
> + xgpu_vi_init_golden_registers(adev);
> + else
> + amdgpu_program_register_sequence(adev,
>tonga_mgcg_cgcg_init,
>(const
> u32)ARRAY_SIZE(tonga_mgcg_cgcg_init));
>   break;
> --
> 2.7.4
> 
> ___
> 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 05/21] drm/amdgpu:BUG if gpu_reste and asic_reset from VF

2017-02-05 Thread Yu, Xiangliang

Have you tried the patch for unloading driver?

Ps:  the index of patch make people confused, I think there are 21 patches in 
the series.


Thanks!
Xiangliang Yu


> -Original Message-
> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Monk Liu
> Sent: Saturday, February 04, 2017 6:35 PM
> To: amd-gfx@lists.freedesktop.org
> Cc: Liu, Monk 
> Subject: [PATCH 05/21] drm/amdgpu:BUG if gpu_reste and asic_reset from
> VF
> 
> for SRIOV vf, Guest couldn't really access PCI registers so
> gpu_reset() and asic_reset should be avoided.
> 
> for suspend it could run for SRIOV because cg/pg routine already modified
> for SRIOV vf case, besides we should remove the req/rel gpu access around
> it because the req/rel should be used by invoker.
> 
> Change-Id: I678d3f2ce202458c1d1d404970fa47421766b666
> Signed-off-by: Monk Liu 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 9 +
>  drivers/gpu/drm/amd/amdgpu/vi.c| 2 ++
>  2 files changed, 3 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> index 6106cd6..173df73 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> @@ -1566,9 +1566,6 @@ int amdgpu_suspend(struct amdgpu_device *adev)
> {
>   int i, r;
> 
> - if (amdgpu_sriov_vf(adev))
> - amdgpu_virt_request_full_gpu(adev, false);
> -
>   /* ungate SMC block first */
>   r = amdgpu_set_clockgating_state(adev,
> AMD_IP_BLOCK_TYPE_SMC,
>AMD_CG_STATE_UNGATE);
> @@ -1597,9 +1594,6 @@ int amdgpu_suspend(struct amdgpu_device *adev)
>   }
>   }
> 
> - if (amdgpu_sriov_vf(adev))
> - amdgpu_virt_release_full_gpu(adev, false);
> -
>   return 0;
>  }
> 
> @@ -2356,8 +2350,7 @@ int amdgpu_gpu_reset(struct amdgpu_device
> *adev)
>   int resched;
>   bool need_full_reset;
> 
> - if (amdgpu_sriov_vf(adev))
> - return 0;
> + BUG_ON(amdgpu_sriov_vf(adev));
> 
>   if (!amdgpu_check_soft_reset(adev)) {
>   DRM_INFO("No hardware hang detected. Did some blocks
> stall?\n"); diff --git a/drivers/gpu/drm/amd/amdgpu/vi.c
> b/drivers/gpu/drm/amd/amdgpu/vi.c index 7810030..557994c 100644
> --- a/drivers/gpu/drm/amd/amdgpu/vi.c
> +++ b/drivers/gpu/drm/amd/amdgpu/vi.c
> @@ -739,6 +739,8 @@ static int vi_asic_reset(struct amdgpu_device *adev)
> {
>   int r;
> 
> + BUG_ON(amdgpu_sriov_vf(adev));
> +
>   amdgpu_atombios_scratch_regs_engine_hung(adev, true);
> 
>   r = vi_gpu_pci_config_reset(adev);
> --
> 2.7.4
> 
> ___
> 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

答复: [PATCH 02/21] drm/amdgpu:fix golden init for sriov

2017-02-05 Thread Liu, Monk

FIJI is not supported in current stack


发件人: Yu, Xiangliang
发送时间: 2017年2月6日 10:35:34
收件人: Liu, Monk; amd-gfx@lists.freedesktop.org
抄送: Liu, Monk
主题: RE: [PATCH 02/21] drm/amdgpu:fix golden init for sriov

Does FIJI need the golden init?


Thanks!
Xiangliang Yu

> -Original Message-
> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Monk Liu
> Sent: Saturday, February 04, 2017 6:22 PM
> To: amd-gfx@lists.freedesktop.org
> Cc: Liu, Monk 
> Subject: [PATCH 02/21] drm/amdgpu:fix golden init for sriov
>
> although only vi supports SRIOV now,but we shouldn't make code has such
> assumption.
>
> Change-Id: Ie73c185dc2e7f64756253045b32cabe70d618d19
> Signed-off-by: Monk Liu 
> ---
>  drivers/gpu/drm/amd/amdgpu/vi.c | 11 ---
>  1 file changed, 4 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/vi.c
> b/drivers/gpu/drm/amd/amdgpu/vi.c index 89b0dfe..7810030 100644
> --- a/drivers/gpu/drm/amd/amdgpu/vi.c
> +++ b/drivers/gpu/drm/amd/amdgpu/vi.c
> @@ -274,12 +274,6 @@ static void vi_init_golden_registers(struct
> amdgpu_device *adev)
>/* Some of the registers might be dependent on GRBM_GFX_INDEX
> */
>mutex_lock(&adev->grbm_idx_mutex);
>
> - if (amdgpu_sriov_vf(adev)) {
> - xgpu_vi_init_golden_registers(adev);
> - mutex_unlock(&adev->grbm_idx_mutex);
> - return;
> - }
> -
>switch (adev->asic_type) {
>case CHIP_TOPAZ:
>amdgpu_program_register_sequence(adev,
> @@ -292,7 +286,10 @@ static void vi_init_golden_registers(struct
> amdgpu_device *adev)
> (const
> u32)ARRAY_SIZE(fiji_mgcg_cgcg_init));
>break;
>case CHIP_TONGA:
> - amdgpu_program_register_sequence(adev,
> + if (amdgpu_sriov_vf(adev))
> + xgpu_vi_init_golden_registers(adev);
> + else
> + amdgpu_program_register_sequence(adev,
> tonga_mgcg_cgcg_init,
> (const
> u32)ARRAY_SIZE(tonga_mgcg_cgcg_init));
>break;
> --
> 2.7.4
>
> ___
> 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

答复: [PATCH 05/21] drm/amdgpu:BUG if gpu_reste and asic_reset from VF

2017-02-05 Thread Liu, Monk

yeah, there are 21 patches totally, but no need to expose all in one time


发件人: Yu, Xiangliang
发送时间: 2017年2月6日 10:38:23
收件人: Liu, Monk; amd-gfx@lists.freedesktop.org
抄送: Liu, Monk
主题: RE: [PATCH 05/21] drm/amdgpu:BUG if gpu_reste and asic_reset from VF

Have you tried the patch for unloading driver?

Ps:  the index of patch make people confused, I think there are 21 patches in 
the series.


Thanks!
Xiangliang Yu


> -Original Message-
> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Monk Liu
> Sent: Saturday, February 04, 2017 6:35 PM
> To: amd-gfx@lists.freedesktop.org
> Cc: Liu, Monk 
> Subject: [PATCH 05/21] drm/amdgpu:BUG if gpu_reste and asic_reset from
> VF
>
> for SRIOV vf, Guest couldn't really access PCI registers so
> gpu_reset() and asic_reset should be avoided.
>
> for suspend it could run for SRIOV because cg/pg routine already modified
> for SRIOV vf case, besides we should remove the req/rel gpu access around
> it because the req/rel should be used by invoker.
>
> Change-Id: I678d3f2ce202458c1d1d404970fa47421766b666
> Signed-off-by: Monk Liu 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 9 +
>  drivers/gpu/drm/amd/amdgpu/vi.c| 2 ++
>  2 files changed, 3 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> index 6106cd6..173df73 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> @@ -1566,9 +1566,6 @@ int amdgpu_suspend(struct amdgpu_device *adev)
> {
>int i, r;
>
> - if (amdgpu_sriov_vf(adev))
> - amdgpu_virt_request_full_gpu(adev, false);
> -
>/* ungate SMC block first */
>r = amdgpu_set_clockgating_state(adev,
> AMD_IP_BLOCK_TYPE_SMC,
> AMD_CG_STATE_UNGATE);
> @@ -1597,9 +1594,6 @@ int amdgpu_suspend(struct amdgpu_device *adev)
>}
>}
>
> - if (amdgpu_sriov_vf(adev))
> - amdgpu_virt_release_full_gpu(adev, false);
> -
>return 0;
>  }
>
> @@ -2356,8 +2350,7 @@ int amdgpu_gpu_reset(struct amdgpu_device
> *adev)
>int resched;
>bool need_full_reset;
>
> - if (amdgpu_sriov_vf(adev))
> - return 0;
> + BUG_ON(amdgpu_sriov_vf(adev));
>
>if (!amdgpu_check_soft_reset(adev)) {
>DRM_INFO("No hardware hang detected. Did some blocks
> stall?\n"); diff --git a/drivers/gpu/drm/amd/amdgpu/vi.c
> b/drivers/gpu/drm/amd/amdgpu/vi.c index 7810030..557994c 100644
> --- a/drivers/gpu/drm/amd/amdgpu/vi.c
> +++ b/drivers/gpu/drm/amd/amdgpu/vi.c
> @@ -739,6 +739,8 @@ static int vi_asic_reset(struct amdgpu_device *adev)
> {
>int r;
>
> + BUG_ON(amdgpu_sriov_vf(adev));
> +
>amdgpu_atombios_scratch_regs_engine_hung(adev, true);
>
>r = vi_gpu_pci_config_reset(adev);
> --
> 2.7.4
>
> ___
> 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

答复: [PATCH 02/21] drm/amdgpu:fix golden init for sriov

2017-02-05 Thread Liu, Monk

this patch is not needed,  xgpu_vi_init_golden_registers(adev) will further 
process each VI asic accordingly.



发件人: amd-gfx  代表 Liu, Monk 

发送时间: 2017年2月6日 10:37:55
收件人: Yu, Xiangliang; amd-gfx@lists.freedesktop.org
主题: 答复: [PATCH 02/21] drm/amdgpu:fix golden init for sriov


FIJI is not supported in current stack


发件人: Yu, Xiangliang
发送时间: 2017年2月6日 10:35:34
收件人: Liu, Monk; amd-gfx@lists.freedesktop.org
抄送: Liu, Monk
主题: RE: [PATCH 02/21] drm/amdgpu:fix golden init for sriov

Does FIJI need the golden init?


Thanks!
Xiangliang Yu

> -Original Message-
> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Monk Liu
> Sent: Saturday, February 04, 2017 6:22 PM
> To: amd-gfx@lists.freedesktop.org
> Cc: Liu, Monk 
> Subject: [PATCH 02/21] drm/amdgpu:fix golden init for sriov
>
> although only vi supports SRIOV now,but we shouldn't make code has such
> assumption.
>
> Change-Id: Ie73c185dc2e7f64756253045b32cabe70d618d19
> Signed-off-by: Monk Liu 
> ---
>  drivers/gpu/drm/amd/amdgpu/vi.c | 11 ---
>  1 file changed, 4 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/vi.c
> b/drivers/gpu/drm/amd/amdgpu/vi.c index 89b0dfe..7810030 100644
> --- a/drivers/gpu/drm/amd/amdgpu/vi.c
> +++ b/drivers/gpu/drm/amd/amdgpu/vi.c
> @@ -274,12 +274,6 @@ static void vi_init_golden_registers(struct
> amdgpu_device *adev)
>/* Some of the registers might be dependent on GRBM_GFX_INDEX
> */
>mutex_lock(&adev->grbm_idx_mutex);
>
> - if (amdgpu_sriov_vf(adev)) {
> - xgpu_vi_init_golden_registers(adev);
> - mutex_unlock(&adev->grbm_idx_mutex);
> - return;
> - }
> -
>switch (adev->asic_type) {
>case CHIP_TOPAZ:
>amdgpu_program_register_sequence(adev,
> @@ -292,7 +286,10 @@ static void vi_init_golden_registers(struct
> amdgpu_device *adev)
> (const
> u32)ARRAY_SIZE(fiji_mgcg_cgcg_init));
>break;
>case CHIP_TONGA:
> - amdgpu_program_register_sequence(adev,
> + if (amdgpu_sriov_vf(adev))
> + xgpu_vi_init_golden_registers(adev);
> + else
> + amdgpu_program_register_sequence(adev,
> tonga_mgcg_cgcg_init,
> (const
> u32)ARRAY_SIZE(tonga_mgcg_cgcg_init));
>break;
> --
> 2.7.4
>
> ___
> 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

答复: [PATCH 05/21] drm/amdgpu:BUG if gpu_reste and asic_reset from VF

2017-02-05 Thread Liu, Monk

thanks for the catch, without those full access protection reboot is failed, 
I'll remove it and adjust later patches for TDR


BR Monk


发件人: Liu, Monk
发送时间: 2017年2月6日 10:39:08
收件人: Yu, Xiangliang; amd-gfx@lists.freedesktop.org
主题: 答复: [PATCH 05/21] drm/amdgpu:BUG if gpu_reste and asic_reset from VF


yeah, there are 21 patches totally, but no need to expose all in one time


发件人: Yu, Xiangliang
发送时间: 2017年2月6日 10:38:23
收件人: Liu, Monk; amd-gfx@lists.freedesktop.org
抄送: Liu, Monk
主题: RE: [PATCH 05/21] drm/amdgpu:BUG if gpu_reste and asic_reset from VF

Have you tried the patch for unloading driver?

Ps:  the index of patch make people confused, I think there are 21 patches in 
the series.


Thanks!
Xiangliang Yu


> -Original Message-
> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Monk Liu
> Sent: Saturday, February 04, 2017 6:35 PM
> To: amd-gfx@lists.freedesktop.org
> Cc: Liu, Monk 
> Subject: [PATCH 05/21] drm/amdgpu:BUG if gpu_reste and asic_reset from
> VF
>
> for SRIOV vf, Guest couldn't really access PCI registers so
> gpu_reset() and asic_reset should be avoided.
>
> for suspend it could run for SRIOV because cg/pg routine already modified
> for SRIOV vf case, besides we should remove the req/rel gpu access around
> it because the req/rel should be used by invoker.
>
> Change-Id: I678d3f2ce202458c1d1d404970fa47421766b666
> Signed-off-by: Monk Liu 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 9 +
>  drivers/gpu/drm/amd/amdgpu/vi.c| 2 ++
>  2 files changed, 3 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> index 6106cd6..173df73 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> @@ -1566,9 +1566,6 @@ int amdgpu_suspend(struct amdgpu_device *adev)
> {
>int i, r;
>
> - if (amdgpu_sriov_vf(adev))
> - amdgpu_virt_request_full_gpu(adev, false);
> -
>/* ungate SMC block first */
>r = amdgpu_set_clockgating_state(adev,
> AMD_IP_BLOCK_TYPE_SMC,
> AMD_CG_STATE_UNGATE);
> @@ -1597,9 +1594,6 @@ int amdgpu_suspend(struct amdgpu_device *adev)
>}
>}
>
> - if (amdgpu_sriov_vf(adev))
> - amdgpu_virt_release_full_gpu(adev, false);
> -
>return 0;
>  }
>
> @@ -2356,8 +2350,7 @@ int amdgpu_gpu_reset(struct amdgpu_device
> *adev)
>int resched;
>bool need_full_reset;
>
> - if (amdgpu_sriov_vf(adev))
> - return 0;
> + BUG_ON(amdgpu_sriov_vf(adev));
>
>if (!amdgpu_check_soft_reset(adev)) {
>DRM_INFO("No hardware hang detected. Did some blocks
> stall?\n"); diff --git a/drivers/gpu/drm/amd/amdgpu/vi.c
> b/drivers/gpu/drm/amd/amdgpu/vi.c index 7810030..557994c 100644
> --- a/drivers/gpu/drm/amd/amdgpu/vi.c
> +++ b/drivers/gpu/drm/amd/amdgpu/vi.c
> @@ -739,6 +739,8 @@ static int vi_asic_reset(struct amdgpu_device *adev)
> {
>int r;
>
> + BUG_ON(amdgpu_sriov_vf(adev));
> +
>amdgpu_atombios_scratch_regs_engine_hung(adev, true);
>
>r = vi_gpu_pci_config_reset(adev);
> --
> 2.7.4
>
> ___
> 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 05/21] drm/amdgpu:BUG if gpu_reste and asic_reset from VF

2017-02-05 Thread Michel Dänzer

On 06/02/17 11:39 AM, Liu, Monk wrote:
> yeah, there are 21 patches totally, but no need to expose all in one time

Then please edit the numbers in the mail subjects accordingly in the
future. :)


-- 
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

答复: 答复: [PATCH 05/21] drm/amdgpu:BUG if gpu_reste and asic_reset from VF

2017-02-05 Thread Liu, Monk

I'll re-send the patch serials later, couple patches once


BR Monk


发件人: amd-gfx  代表 Michel Dänzer 

发送时间: 2017年2月6日 11:07:08
收件人: Liu, Monk; Yu, Xiangliang
抄送: amd-gfx@lists.freedesktop.org
主题: Re: 答复: [PATCH 05/21] drm/amdgpu:BUG if gpu_reste and asic_reset from VF

On 06/02/17 11:39 AM, Liu, Monk wrote:
> yeah, there are 21 patches totally, but no need to expose all in one time

Then please edit the numbers in the mail subjects accordingly in the
future. :)


--
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
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[PATCH 1/2] drm/amd/display: fix array lenth error.

2017-02-05 Thread Rex Zhu

Change-Id: I09011c5e6d5493db7e3d9a7ff7ab8c871a8db862
Signed-off-by: Rex Zhu 
---
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_services.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_services.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_services.c
index 5af27aa..50576c6 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_services.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_services.c
@@ -358,7 +358,7 @@ bool dm_pp_get_clock_levels_by_type(
 * non-boosted one. */
DRM_INFO("DM_PPLIB: reducing engine clock level 
from %d to %d\n",
dc_clks->num_levels, i + 1);
-   dc_clks->num_levels = i;
+   dc_clks->num_levels = i + 1;
break;
}
}
@@ -367,7 +367,7 @@ bool dm_pp_get_clock_levels_by_type(
if (dc_clks->clocks_in_khz[i] > 
validation_clks.memory_max_clock) {
DRM_INFO("DM_PPLIB: reducing memory clock level 
from %d to %d\n",
dc_clks->num_levels, i + 1);
-   dc_clks->num_levels = i;
+   dc_clks->num_levels = i + 1;
break;
}
}
-- 
1.9.1

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

[PATCH 2/2] drm/amd/powerplay: refine code to avoid potential bug that the memory not cleared.

2017-02-05 Thread Rex Zhu

Change-Id: If286d163cbabd8e9921a9d3cfcb71bb2b99aaceb
Signed-off-by: Rex Zhu 
---
 drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c | 17 +++--
 1 file changed, 7 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c 
b/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
index 0a6c833..18f8ee7 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
@@ -4397,16 +4397,14 @@ static int smu7_get_sclks(struct pp_hwmgr *hwmgr, 
struct amd_pp_clocks *clocks)
if (table_info == NULL || table_info->vdd_dep_on_sclk == NULL)
return -EINVAL;
dep_sclk_table = table_info->vdd_dep_on_sclk;
-   for (i = 0; i < dep_sclk_table->count; i++) {
+   for (i = 0; i < dep_sclk_table->count; i++)
clocks->clock[i] = dep_sclk_table->entries[i].clk;
-   clocks->count++;
-   }
+   clocks->count = dep_sclk_table->count;
} else if (hwmgr->pp_table_version == PP_TABLE_V0) {
sclk_table = hwmgr->dyn_state.vddc_dependency_on_sclk;
-   for (i = 0; i < sclk_table->count; i++) {
+   for (i = 0; i < sclk_table->count; i++)
clocks->clock[i] = sclk_table->entries[i].clk;
-   clocks->count++;
-   }
+   clocks->count = sclk_table->count;
}
 
return 0;
@@ -4440,14 +4438,13 @@ static int smu7_get_mclks(struct pp_hwmgr *hwmgr, 
struct amd_pp_clocks *clocks)
clocks->clock[i] = dep_mclk_table->entries[i].clk;
clocks->latency[i] = smu7_get_mem_latency(hwmgr,
dep_mclk_table->entries[i].clk);
-   clocks->count++;
}
+   clocks->count = dep_mclk_table->count;
} else if (hwmgr->pp_table_version == PP_TABLE_V0) {
mclk_table = hwmgr->dyn_state.vddc_dependency_on_mclk;
-   for (i = 0; i < mclk_table->count; i++) {
+   for (i = 0; i < mclk_table->count; i++)
clocks->clock[i] = mclk_table->entries[i].clk;
-   clocks->count++;
-   }
+   clocks->count = mclk_table->count
}
return 0;
 }
-- 
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: don't clean the framebuffer for VF

2017-02-05 Thread Pixel Ding

The SRIOV host driver cleans framebuffer for each VF, guest driver
needn't this action which costs much time on some virtualization
platform, otherwise it might get timeout to initialize.

Signed-off-by: Pixel Ding 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
index 1e735c4..f1eb4f5 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
@@ -242,7 +242,9 @@ static int amdgpufb_create(struct drm_fb_helper *helper,
/* setup helper */
rfbdev->helper.fb = fb;
 
-   memset_io(abo->kptr, 0x0, amdgpu_bo_size(abo));
+   if (!amdgpu_sriov_vf(adev)) {
+   memset_io(abo->kptr, 0x0, amdgpu_bo_size(abo));
+   }
 
strcpy(info->fix.id, "amdgpudrmfb");
 
-- 
2.7.4

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

amd-gfx@lists.freedesktop.org

2017-02-05 Thread Zhou, David(ChunMing)

I'm curious what problem this patch fix? Any crash?

My impression list_for will check if the list is empty, am I wrong?

Regards,
David Zhou

-Original Message-
From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf Of Monk 
Liu
Sent: Saturday, February 04, 2017 6:22 PM
To: amd-gfx@lists.freedesktop.org
Cc: Liu, Monk 
Subject: [PATCH 03/21] drm/amdgpu:fix scheduler hw reset&recovery

Change-Id: I39e0b77029d22dc3fb37e2f19da699647ae96aad
Signed-off-by: Monk Liu 
---
 drivers/gpu/drm/amd/scheduler/gpu_scheduler.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/drivers/gpu/drm/amd/scheduler/gpu_scheduler.c 
b/drivers/gpu/drm/amd/scheduler/gpu_scheduler.c
index ffe1f85..73dd5a7 100644
--- a/drivers/gpu/drm/amd/scheduler/gpu_scheduler.c
+++ b/drivers/gpu/drm/amd/scheduler/gpu_scheduler.c
@@ -384,6 +384,13 @@ void amd_sched_hw_job_reset(struct amd_gpu_scheduler 
*sched)
struct amd_sched_job *s_job;
 
spin_lock(&sched->job_list_lock);
+   s_job = list_first_entry_or_null(&sched->ring_mirror_list,
+struct amd_sched_job, node);
+   if (!s_job) {
+   spin_unlock(&sched->job_list_lock);
+   return;
+   }
+
list_for_each_entry_reverse(s_job, &sched->ring_mirror_list, node) {
if (fence_remove_callback(s_job->s_fence->parent, 
&s_job->s_fence->cb)) {
fence_put(s_job->s_fence->parent);
@@ -405,6 +412,11 @@ void amd_sched_job_recovery(struct amd_gpu_scheduler 
*sched)
if (s_job && sched->timeout != MAX_SCHEDULE_TIMEOUT)
schedule_delayed_work(&s_job->work_tdr, sched->timeout);
 
+   if (!s_job) {
+   spin_unlock(&sched->job_list_lock);
+   return;
+   }
+
list_for_each_entry_safe(s_job, tmp, &sched->ring_mirror_list, node) {
struct amd_sched_fence *s_fence = s_job->s_fence;
struct fence *fence;
-- 
2.7.4

___
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

[PATCH 2/2] drm/amdgpu: increase mailbox timeout to 5000ms

2017-02-05 Thread Pixel Ding

When mutiple VFs try to enter exclusive mode at the same time, the
looping mechansim doesn't help to ensure each can get it because it
only loops active VFs, then the last one has to wait for a long
interval.

Signed-off-by: Pixel Ding 
---
 drivers/gpu/drm/amd/amdgpu/mxgpu_vi.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/mxgpu_vi.h 
b/drivers/gpu/drm/amd/amdgpu/mxgpu_vi.h
index fd6216e..2db7411 100644
--- a/drivers/gpu/drm/amd/amdgpu/mxgpu_vi.h
+++ b/drivers/gpu/drm/amd/amdgpu/mxgpu_vi.h
@@ -23,7 +23,7 @@
 #ifndef __MXGPU_VI_H__
 #define __MXGPU_VI_H__
 
-#define VI_MAILBOX_TIMEDOUT150
+#define VI_MAILBOX_TIMEDOUT5000
 #define VI_MAILBOX_RESET_TIME  12
 
 /* VI mailbox messages request */
-- 
2.7.4

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

[PATCH 1/2] drm/amdgpu/virt: refine handshake between guest and host by mailbox

2017-02-05 Thread Pixel Ding

From: Ken Xue 

The previous handshake doesn't check the VALID flag for mailbox. A bug
occurs that the driver believes it's in exclusive mode but actually
it's not, then the subsequent initliaztion fails.

The right protocol should be that guest driver checks VALID flag and
makes sure the host driver has already recieved the ACK message and
handle it like:

A: send MSG->  clear VALID->
B:   send ACK-> check VALID

Signed-off-by: Ken Xue 
Acked-by: Pixel Ding 
---
 drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c | 26 +-
 1 file changed, 25 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c 
b/drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c
index d2622b6..5fe4aad 100644
--- a/drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c
+++ b/drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c
@@ -318,10 +318,25 @@ void xgpu_vi_init_golden_registers(struct amdgpu_device 
*adev)
 static void xgpu_vi_mailbox_send_ack(struct amdgpu_device *adev)
 {
u32 reg;
+   int timeout = VI_MAILBOX_TIMEDOUT;
+   u32 mask = REG_FIELD_MASK(MAILBOX_CONTROL, RCV_MSG_VALID);
 
reg = RREG32(mmMAILBOX_CONTROL);
reg = REG_SET_FIELD(reg, MAILBOX_CONTROL, RCV_MSG_ACK, 1);
WREG32(mmMAILBOX_CONTROL, reg);
+
+   /*Wait for RCV_MSG_VALID to be 0*/
+   reg = RREG32(mmMAILBOX_CONTROL);
+   while (reg & mask) {
+   if (timeout <= 0) {
+   pr_err("RCV_MSG_VALID is not cleared\n");
+   break;
+   }
+   mdelay(1);
+   timeout -=1;
+
+   reg = RREG32(mmMAILBOX_CONTROL);
+   }
 }
 
 static void xgpu_vi_mailbox_set_valid(struct amdgpu_device *adev, bool val)
@@ -339,6 +354,8 @@ static void xgpu_vi_mailbox_trans_msg(struct amdgpu_device 
*adev,
 {
u32 reg;
 
+   xgpu_vi_mailbox_send_ack(adev);
+
reg = RREG32(mmMAILBOX_MSGBUF_TRN_DW0);
reg = REG_SET_FIELD(reg, MAILBOX_MSGBUF_TRN_DW0,
MSGBUF_DATA, event);
@@ -351,6 +368,11 @@ static int xgpu_vi_mailbox_rcv_msg(struct amdgpu_device 
*adev,
   enum idh_event event)
 {
u32 reg;
+   u32 mask = REG_FIELD_MASK(MAILBOX_CONTROL, RCV_MSG_VALID);
+
+   reg = RREG32(mmMAILBOX_CONTROL);
+   if (!(reg & mask))
+   return -ENOENT;
 
reg = RREG32(mmMAILBOX_MSGBUF_RCV_DW0);
if (reg != event)
@@ -419,7 +441,9 @@ static int xgpu_vi_send_access_requests(struct 
amdgpu_device *adev,
xgpu_vi_mailbox_set_valid(adev, false);
 
/* start to check msg if request is idh_req_gpu_init_access */
-   if (request == IDH_REQ_GPU_INIT_ACCESS) {
+   if (request == IDH_REQ_GPU_INIT_ACCESS ||
+   request == IDH_REQ_GPU_FINI_ACCESS ||
+   request == IDH_REQ_GPU_RESET_ACCESS) {
r = xgpu_vi_poll_msg(adev, IDH_READY_TO_ACCESS_GPU);
if (r)
return r;
-- 
2.7.4

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

[PATCH 1/2] drm/amdgpu/virt: refine handshake between guest and host by mailbox

2017-02-05 Thread Pixel Ding

From: Ken Xue 

The previous handshake doesn't check the VALID flag for mailbox. A bug
occurs that the driver believes it's in exclusive mode but actually
it's not, then the subsequent initliaztion fails.

The right protocol should be that guest driver checks VALID flag and
makes sure the host driver has already recieved the ACK message and
handle it like:

A: send MSG->  clear VALID->
B:   send ACK-> check VALID

Signed-off-by: Ken Xue 
Acked-by: Pixel Ding 
---
 drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c | 26 +-
 1 file changed, 25 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c 
b/drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c
index d2622b6..5fe4aad 100644
--- a/drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c
+++ b/drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c
@@ -318,10 +318,25 @@ void xgpu_vi_init_golden_registers(struct amdgpu_device 
*adev)
 static void xgpu_vi_mailbox_send_ack(struct amdgpu_device *adev)
 {
u32 reg;
+   int timeout = VI_MAILBOX_TIMEDOUT;
+   u32 mask = REG_FIELD_MASK(MAILBOX_CONTROL, RCV_MSG_VALID);
 
reg = RREG32(mmMAILBOX_CONTROL);
reg = REG_SET_FIELD(reg, MAILBOX_CONTROL, RCV_MSG_ACK, 1);
WREG32(mmMAILBOX_CONTROL, reg);
+
+   /*Wait for RCV_MSG_VALID to be 0*/
+   reg = RREG32(mmMAILBOX_CONTROL);
+   while (reg & mask) {
+   if (timeout <= 0) {
+   pr_err("RCV_MSG_VALID is not cleared\n");
+   break;
+   }
+   mdelay(1);
+   timeout -=1;
+
+   reg = RREG32(mmMAILBOX_CONTROL);
+   }
 }
 
 static void xgpu_vi_mailbox_set_valid(struct amdgpu_device *adev, bool val)
@@ -339,6 +354,8 @@ static void xgpu_vi_mailbox_trans_msg(struct amdgpu_device 
*adev,
 {
u32 reg;
 
+   xgpu_vi_mailbox_send_ack(adev);
+
reg = RREG32(mmMAILBOX_MSGBUF_TRN_DW0);
reg = REG_SET_FIELD(reg, MAILBOX_MSGBUF_TRN_DW0,
MSGBUF_DATA, event);
@@ -351,6 +368,11 @@ static int xgpu_vi_mailbox_rcv_msg(struct amdgpu_device 
*adev,
   enum idh_event event)
 {
u32 reg;
+   u32 mask = REG_FIELD_MASK(MAILBOX_CONTROL, RCV_MSG_VALID);
+
+   reg = RREG32(mmMAILBOX_CONTROL);
+   if (!(reg & mask))
+   return -ENOENT;
 
reg = RREG32(mmMAILBOX_MSGBUF_RCV_DW0);
if (reg != event)
@@ -419,7 +441,9 @@ static int xgpu_vi_send_access_requests(struct 
amdgpu_device *adev,
xgpu_vi_mailbox_set_valid(adev, false);
 
/* start to check msg if request is idh_req_gpu_init_access */
-   if (request == IDH_REQ_GPU_INIT_ACCESS) {
+   if (request == IDH_REQ_GPU_INIT_ACCESS ||
+   request == IDH_REQ_GPU_FINI_ACCESS ||
+   request == IDH_REQ_GPU_RESET_ACCESS) {
r = xgpu_vi_poll_msg(adev, IDH_READY_TO_ACCESS_GPU);
if (r)
return r;
-- 
2.7.4

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

RE: [PATCH 2/2] drm/amdgpu: increase mailbox timeout to 5000ms

2017-02-05 Thread Yu, Xiangliang

Reviewed-by: Xiangliang Yu 


Thanks!
Xiangliang Yu


> -Original Message-
> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Pixel Ding
> Sent: Monday, February 06, 2017 2:25 PM
> To: amd-gfx@lists.freedesktop.org
> Cc: Ding, Pixel ; ding.pi...@amd.com
> Subject: [PATCH 2/2] drm/amdgpu: increase mailbox timeout to 5000ms
> 
> When mutiple VFs try to enter exclusive mode at the same time, the looping
> mechansim doesn't help to ensure each can get it because it only loops active
> VFs, then the last one has to wait for a long interval.
> 
> Signed-off-by: Pixel Ding 
> ---
>  drivers/gpu/drm/amd/amdgpu/mxgpu_vi.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/mxgpu_vi.h
> b/drivers/gpu/drm/amd/amdgpu/mxgpu_vi.h
> index fd6216e..2db7411 100644
> --- a/drivers/gpu/drm/amd/amdgpu/mxgpu_vi.h
> +++ b/drivers/gpu/drm/amd/amdgpu/mxgpu_vi.h
> @@ -23,7 +23,7 @@
>  #ifndef __MXGPU_VI_H__
>  #define __MXGPU_VI_H__
> 
> -#define VI_MAILBOX_TIMEDOUT  150
> +#define VI_MAILBOX_TIMEDOUT  5000
>  #define VI_MAILBOX_RESET_TIME12
> 
>  /* VI mailbox messages request */
> --
> 2.7.4
> 
> ___
> 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

[PATCH 2/2] drm/amdgpu/virt: schedule work to handle vm fault for VF

2017-02-05 Thread Pixel Ding

VF uses KIQ to access registers that invoking fence_wait to get the
accessing completed. When VM fault occurs, the driver can't sleep in
interrupt context.

For some test cases, VM fault is 'legal' and shouldn't cause driver soft
lockup.

Signed-off-by: Pixel Ding 
---
 drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c | 46 ---
 1 file changed, 43 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c 
b/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
index 7669b32..75c913f 100644
--- a/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
@@ -1231,9 +1231,9 @@ static int gmc_v8_0_vm_fault_interrupt_state(struct 
amdgpu_device *adev,
return 0;
 }
 
-static int gmc_v8_0_process_interrupt(struct amdgpu_device *adev,
- struct amdgpu_irq_src *source,
- struct amdgpu_iv_entry *entry)
+static int gmc_v8_0_process_vm_fault(struct amdgpu_device *adev,
+struct amdgpu_irq_src *source,
+struct amdgpu_iv_entry *entry)
 {
u32 addr, status, mc_client;
 
@@ -1262,6 +1262,46 @@ static int gmc_v8_0_process_interrupt(struct 
amdgpu_device *adev,
return 0;
 }
 
+struct gmc_vm_fault_work {
+   struct work_struct  base;
+   struct amdgpu_device*adev;
+   struct amdgpu_irq_src   *source;
+   struct amdgpu_iv_entry  *entry;
+};
+
+static void gmc_v8_0_vm_fault_sched(struct work_struct *work)
+{
+   struct gmc_vm_fault_work *vm_work =
+   container_of(work, struct gmc_vm_fault_work, base);
+   struct amdgpu_device *adev = vm_work->adev;
+   struct amdgpu_irq_src *source = vm_work->source;
+   struct amdgpu_iv_entry *entry = vm_work->entry;
+
+   gmc_v8_0_process_vm_fault(adev, source, entry);
+
+   kfree(vm_work);
+}
+
+static int gmc_v8_0_process_interrupt(struct amdgpu_device *adev,
+ struct amdgpu_irq_src *source,
+ struct amdgpu_iv_entry *entry)
+{
+   struct gmc_vm_fault_work *work = NULL;
+
+   if (amdgpu_sriov_vf(adev)) {
+   work = kmalloc(sizeof(struct gmc_vm_fault_work), GFP_ATOMIC);
+   if (!work)
+   return -ENOMEM;
+   INIT_WORK(&work->base, gmc_v8_0_vm_fault_sched);
+   work->adev = adev;
+   work->source = source;
+   work->entry = entry;
+   return schedule_work(&work->base);
+   }
+
+   return gmc_v8_0_process_vm_fault(adev, source, entry);
+}
+
 static void fiji_update_mc_medium_grain_clock_gating(struct amdgpu_device 
*adev,
 bool enable)
 {
-- 
2.7.4

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

RE: [PATCH 1/2] drm/amdgpu/virt: refine handshake between guest and host by mailbox

2017-02-05 Thread Yu, Xiangliang

Reviewed-by: Xiangliang.Yu 


Thanks!
Xiangliang Yu


> -Original Message-
> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Pixel Ding
> Sent: Monday, February 06, 2017 3:00 PM
> To: amd-gfx@lists.freedesktop.org
> Cc: Xue, Ken 
> Subject: [PATCH 1/2] drm/amdgpu/virt: refine handshake between guest
> and host by mailbox
> 
> From: Ken Xue 
> 
> The previous handshake doesn't check the VALID flag for mailbox. A bug
> occurs that the driver believes it's in exclusive mode but actually it's not, 
> then
> the subsequent initliaztion fails.
> 
> The right protocol should be that guest driver checks VALID flag and makes
> sure the host driver has already recieved the ACK message and handle it like:
> 
> A: send MSG->  clear VALID->
> B:   send ACK-> check VALID
> 
> Signed-off-by: Ken Xue 
> Acked-by: Pixel Ding 
> ---
>  drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c | 26
> +-
>  1 file changed, 25 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c
> b/drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c
> index d2622b6..5fe4aad 100644
> --- a/drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c
> +++ b/drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c
> @@ -318,10 +318,25 @@ void xgpu_vi_init_golden_registers(struct
> amdgpu_device *adev)  static void xgpu_vi_mailbox_send_ack(struct
> amdgpu_device *adev)  {
>   u32 reg;
> + int timeout = VI_MAILBOX_TIMEDOUT;
> + u32 mask = REG_FIELD_MASK(MAILBOX_CONTROL,
> RCV_MSG_VALID);
> 
>   reg = RREG32(mmMAILBOX_CONTROL);
>   reg = REG_SET_FIELD(reg, MAILBOX_CONTROL, RCV_MSG_ACK, 1);
>   WREG32(mmMAILBOX_CONTROL, reg);
> +
> + /*Wait for RCV_MSG_VALID to be 0*/
> + reg = RREG32(mmMAILBOX_CONTROL);
> + while (reg & mask) {
> + if (timeout <= 0) {
> + pr_err("RCV_MSG_VALID is not cleared\n");
> + break;
> + }
> + mdelay(1);
> + timeout -=1;
> +
> + reg = RREG32(mmMAILBOX_CONTROL);
> + }
>  }
> 
>  static void xgpu_vi_mailbox_set_valid(struct amdgpu_device *adev, bool val)
> @@ -339,6 +354,8 @@ static void xgpu_vi_mailbox_trans_msg(struct
> amdgpu_device *adev,  {
>   u32 reg;
> 
> + xgpu_vi_mailbox_send_ack(adev);
> +
>   reg = RREG32(mmMAILBOX_MSGBUF_TRN_DW0);
>   reg = REG_SET_FIELD(reg, MAILBOX_MSGBUF_TRN_DW0,
>   MSGBUF_DATA, event);
> @@ -351,6 +368,11 @@ static int xgpu_vi_mailbox_rcv_msg(struct
> amdgpu_device *adev,
>  enum idh_event event)
>  {
>   u32 reg;
> + u32 mask = REG_FIELD_MASK(MAILBOX_CONTROL,
> RCV_MSG_VALID);
> +
> + reg = RREG32(mmMAILBOX_CONTROL);
> + if (!(reg & mask))
> + return -ENOENT;
> 
>   reg = RREG32(mmMAILBOX_MSGBUF_RCV_DW0);
>   if (reg != event)
> @@ -419,7 +441,9 @@ static int xgpu_vi_send_access_requests(struct
> amdgpu_device *adev,
>   xgpu_vi_mailbox_set_valid(adev, false);
> 
>   /* start to check msg if request is idh_req_gpu_init_access */
> - if (request == IDH_REQ_GPU_INIT_ACCESS) {
> + if (request == IDH_REQ_GPU_INIT_ACCESS ||
> + request == IDH_REQ_GPU_FINI_ACCESS ||
> + request == IDH_REQ_GPU_RESET_ACCESS) {
>   r = xgpu_vi_poll_msg(adev, IDH_READY_TO_ACCESS_GPU);
>   if (r)
>   return r;
> --
> 2.7.4
> 
> ___
> 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 1/2] drm/amdgpu: don't clean the framebuffer for VF

2017-02-05 Thread Yu, Xiangliang

Acked-by: Xiangliang.Yu 


Thanks!
Xiangliang Yu


> -Original Message-
> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Pixel Ding
> Sent: Monday, February 06, 2017 2:25 PM
> To: amd-gfx@lists.freedesktop.org
> Cc: Ding, Pixel ; ding.pi...@amd.com
> Subject: [PATCH 1/2] drm/amdgpu: don't clean the framebuffer for VF
> 
> The SRIOV host driver cleans framebuffer for each VF, guest driver needn't
> this action which costs much time on some virtualization platform, otherwise
> it might get timeout to initialize.
> 
> Signed-off-by: Pixel Ding 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
> index 1e735c4..f1eb4f5 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
> @@ -242,7 +242,9 @@ static int amdgpufb_create(struct drm_fb_helper
> *helper,
>   /* setup helper */
>   rfbdev->helper.fb = fb;
> 
> - memset_io(abo->kptr, 0x0, amdgpu_bo_size(abo));
> + if (!amdgpu_sriov_vf(adev)) {
> + memset_io(abo->kptr, 0x0, amdgpu_bo_size(abo));
> + }
> 
>   strcpy(info->fix.id, "amdgpudrmfb");
> 
> --
> 2.7.4
> 
> ___
> 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

38 matches

Mail list logo