Re: [PATCH 1/2] drm/amdgpu: Enable scatter gather display support

On Wed, Mar 7, 2018 at 1:18 PM, Samuel Li wrote: > I think it's not useful though. Think about that, SG display feature is > intended to use as less VRAM as possible. Will someone want a display buffer > sometimes VRAM, sometimes GTT? > Hardly a case to me, and I think it's a

Re: Modesetting (amdgpudrmfb) artifacts on RAVEN APU

It's an old patch but does drm-fixes-4.16 have this patch commit e92b44fdee3ec0b679bacdb9c7e95e55699167f0 Refs: v4.14-rc3-1871-ge92b44fdee3e Author: Tony Cheng AuthorDate: Thu Oct 5 14:38:46 2017 -0400 Commit: Alex Deucher

Re: [PATCH 1/2] drm/amdgpu: Enable scatter gather display support

> You might also want to prefer VRAM, but also allow buffers to fall back to > GTT if > necessary. For display buffer, this case seems not really attractive. When display buffer changes between GTT and VRAM dynamically, our driver needs to adpat too, which is hard to see the benefits and not

RE: [PATCH 1/2] drm/amdgpu: Enable scatter gather display support

How about that, in my previous patches, it actually allows three scenarios, 1) VRAM as display buffer 2) GTT as display buffer 3) Mixed GTT/display buffer, as you have asked. I think the first step is to make the 2nd scenario work at optimal level. After that, if anyone wants to work the 3rd

Re: [PATCH 1/2] drm/amdgpu: Enable scatter gather display support

I think it's not useful though. Think about that, SG display feature is intended to use as less VRAM as possible. Will someone want a display buffer sometimes VRAM, sometimes GTT? Hardly a case to me, and I think it's a waste of effort. That also might explain no driver does that now. Sam

Re: Modesetting (amdgpudrmfb) artifacts on RAVEN APU

On 2018-03-07 12:38 PM, KARBOWSKI Piotr wrote: > On 2018-03-07 17:48, KARBOWSKI Piotr wrote: >> On 2018-03-07 17:14, Harry Wentland wrote: >>> Pushed a drm-fixes-4.16 branch (based on Alex's) to my FDO repo >>> athttps://cgit.freedesktop.org/~hwentland/linux/  but I don't have a Raven >>> system

Re: Modesetting (amdgpudrmfb) artifacts on RAVEN APU

Yup, that's there as commit e92b44fdee3ec0b679bacdb9c7e95e55699167f0 Author: Tony Cheng Date: Thu Oct 5 14:38:46 2017 -0400 drm/amd/display: default force_single_disp_pipe_split = 1 on RV ... Harry On 2018-03-07 02:16 PM, Tom St Denis wrote: > It's an old patch but

Re: New KFD ioctls: taking the skeletons out of the closet

On Wed, Mar 7, 2018 at 11:38 AM, Daniel Vetter wrote: > On Wed, Mar 07, 2018 at 09:38:03AM +0100, Christian K??nig wrote: >> Am 07.03.2018 um 00:09 schrieb Dave Airlie: >> > On 7 March 2018 at 08:44, Felix Kuehling wrote: >> > > Hi all, >> > > >> > >

Re: Modesetting (amdgpudrmfb) artifacts on RAVEN APU

On 2018-03-07 20:12, Harry Wentland wrote: Thanks for testing. What do you mean with broken video? I tried going back in the email thread but I'm not 100% clear what you mean by this. BTW, drm-fixes-4.16 are fixes we intend to get into the 4.16 upstream kernel. amd-staging-drm-next is our

Re: Modesetting (amdgpudrmfb) artifacts on RAVEN APU

On 2018-03-07 20:31, KARBOWSKI Piotr wrote: On 2018-03-07 20:12, Harry Wentland wrote: Thanks for testing. What do you mean with broken video? I tried going back in the email thread but I'm not 100% clear what you mean by this. BTW, drm-fixes-4.16 are fixes we intend to get into the 4.16

Re: New KFD ioctls: taking the skeletons out of the closet

Thanks for the feedback. I'm answering some of your questions inline. On 2018-03-06 06:09 PM, Dave Airlie wrote: > On 7 March 2018 at 08:44, Felix Kuehling wrote: >> Hi all, >> >> Christian raised two potential issues in a recent KFD upstreaming code >> review that are

Re: [PATCH] drm/atomic: Add new reverse iterator over all plane state (V2)

On 2018-03-06 10:10 PM, Shirish S wrote: > Add reverse iterator for_each_oldnew_plane_in_state_reverse to > compliment the for_each_oldnew_plane_in_state way or reading plane > states. > > The plane states are required to be read in reverse order for > amd drivers, cause the z order convention

Re: Modesetting (amdgpudrmfb) artifacts on RAVEN APU

On 2018-03-07 02:54 PM, KARBOWSKI Piotr wrote: > On 2018-03-07 20:31, KARBOWSKI Piotr wrote: >> On 2018-03-07 20:12, Harry Wentland wrote: >>> Thanks for testing. >>> >>> What do you mean with broken video? I tried going back in the email thread >>> but I'm not 100% clear what you mean by this.

Re: [PATCH 1/2] drm/amdgpu: Enable scatter gather display support

On Wed, Mar 7, 2018 at 2:02 PM, Li, Samuel wrote: > How about that, in my previous patches, it actually allows three scenarios, > 1) VRAM as display buffer > 2) GTT as display buffer > 3) Mixed GTT/display buffer, as you have asked. > > I think the first step is to make the 2nd

[pull] radeon and amdgpu drm-fixes-4.16

Hi Dave, Fixes for 4.16. A bit bigger than I would have liked, but most of that is DC fixes which Harry helped me pull together from the past few weeks. Highlights: - Fix DL DVI with DC - Various RV fixes for DC - Overlay fixes for DC - Fix HDMI2 handling on boards without HBR tables in the

Re: Modesetting (amdgpudrmfb) artifacts on RAVEN APU

On 2018-03-07 22:15, Harry Wentland wrote: amd-stg has some other patches relating to DCN pipe-split that I don't fully understand. We might need one or more of those. As a workaround you can probably set 'force_single_disp_pipe_split' to 'false' in 'debug_defaults_drv' in

[pull] radeon, amdgpu, ttm drm-next-4.17

Hi Dave, More stuff for 4.17. Highlights: - More fixes for "wattman" like functionality (fine grained clk/voltage control) - Add more power profile infrastucture (context based dpm) - SR-IOV fixes - Add iomem debugging interface for use with umr - Powerplay and cgs cleanups - DC fixes and

RE: [PATCH 1/6] drm/ttm: add ttm_bo_pipeline_gutting

Patch 1,4,5: Acked-by: Roger He Patch 2,3,6: Reviewed-by: Roger He -Original Message- From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of Christian K?nig Sent: Tuesday, March 06, 2018 10:44 PM To:

RE: [PATCH 4/8] drm/amd/pp: Clean up the code for RV in powerplay

>Is this consistent with our other smu implementations? If we never use the >errors, I'm ok with removing them, but I don't want to have to add them again >later if we decide we >actually need them. Rex: until vega10/raven, we do not handle the errors in windows/linux, just print out the

Re: [PATCH] drm/amdgpu: Correct the amdgpu_ucode_fini_bo place for Tonga

Reviewed-by: Alex Deucher From: amd-gfx on behalf of Emily Deng Sent: Wednesday, March 7, 2018 9:55:02 PM To: amd-gfx@lists.freedesktop.org Cc: Deng, Emily Subject: [PATCH]

[PATCH] drm/amdgpu: Correct the amdgpu_ucode_fini_bo place for Tonga

The amdgpu_ucode_fini_bo should be called after gfx_v8_0_hw_fini, or it will have KCQ disable failed issue. For Tonga, as it firstly finishes SMC block, and the SMC hw fini will call amdgpu_ucode_fini, which will lead the amdgpu_ucode_fini_bo called before gfx_v8_0_hw_fini, this is incorrect.

RE: deprecated register issues

Hi guys According to Christian’s found, reading this register would make vm hub failed to finish the vm flush request , e.g.: sdma is doing vm flush which first write data to vm_invalidat_req and read result from vm_invalidate_ack, but found driver will forever failed to get the correct value

Re: deprecated register issues

I think there are more than just CC_RB_BACKEND_DISABLE that could cause this problem. IIRC, some entire class of gfx registers could cause it, it just happened that this was one of the only ones we readback via mmio. Also for the save and restore list, I think the RLC uses a different

RE: deprecated register issues

Hi Alex While we can avoid such vm flush failure by stitch together of the sending REQ and reading ACK part, at least for compute ring this is confirmed. And I believe for SDMA ring (even UVD/VCE ring) it could also be achieved. But @Koenig, Christian insist

Re: [PATCH 1/8] drm/amd/pp: Refine code for smu7 in powerplay

On Wed, Mar 7, 2018 at 5:46 AM, Rex Zhu wrote: > 1. Add avfs_support in hwmgr to avoid to visit smu backend struct in >hwmgr.so do not need to include smu7_smumgr.h under hwmgr folder. > 2. simplify the list of enum AVFS_BTC_STATUS > > Change-Id:

Re: [PATCH 2/8] drm/amd/pp: Clean up header file include

On Wed, Mar 7, 2018 at 5:46 AM, Rex Zhu wrote: > smu7_smumgr.h should not be included in rv and vega, The common functions > for all smu7 asics are put in smu_smumgr.c. > > Not include cgs interface in smumgr.c. the code used cgs interface has been > deleted. > > Not include

Re: [PATCH 3/8] drm/amd/pp: Delete is_smc_ram_running function on RV

On Wed, Mar 7, 2018 at 5:46 AM, Rex Zhu wrote: > 1. There is a race condition when another ip also use same register pairs > 2. check once at boot up by GetDriverIfVersion message is sufficient >to check SMU health. so delete is_smc_ram_running check. > > Change-Id:

Re: [PATCH 4/8] drm/amd/pp: Clean up the code for RV in powerplay

On Wed, Mar 7, 2018 at 5:46 AM, Rex Zhu wrote: > In send_message_to_smu helper functions, > Print out the error code for debug if smu failed to response. > > and the helper functions always return true, so no need to > check their return value. > > Signed-off-by: Rex Zhu

Re: [PATCH 5/8] drm/amd/pp: Clean up code for RV in powerplay.

On Wed, Mar 7, 2018 at 5:46 AM, Rex Zhu wrote: > 1. make functions static > 2. add rv_read_arg_from_smc to smu backend function table. Please make this two patches since there are two logical changes here. Also see my additional comment below. > > Change-Id:

Re: [PATCH 6/8] drm/amd/pp: Add new smu backend function smc_table_manager

On Wed, Mar 7, 2018 at 5:46 AM, Rex Zhu wrote: > Change-Id: I4c68f7627387c4ae67612e09651318f5ae90162a > Signed-off-by: Rex Zhu Patches 6-8: Reviewed-by: Alex Deucher > --- > drivers/gpu/drm/amd/powerplay/inc/hwmgr.h | 1 + >

Re: [PATCH 1/2] drm/amdgpu: Enable scatter gather display support

Why so complicated? If old user space compatibility is required, just use sg_display=0. Sam On 2018-03-07 05:12 AM, Michel Dänzer wrote: > On 2018-03-07 11:04 AM, Christian König wrote: >> Am 07.03.2018 um 10:53 schrieb Michel Dänzer: >>> On 2018-03-07 10:47 AM, Christian König wrote:

Re: [PATCH 1/2] drm/amdgpu: Enable scatter gather display support

On Wed, Mar 7, 2018 at 12:29 PM, Samuel Li wrote: > > Why so complicated? If old user space compatibility is required, just use > sg_display=0. It will always just work in that case and we can adjust for the optimal scenario by default in all cases without requiring the user

[PATCH xf86-video-ati] Wrap the whole miPointerScreenFuncRec, instead of only Set/MoveCursor

From: Michel Dänzer We were clobbering entries in mi's global miSpritePointerFuncs struct, which cannot work correctly with multiple primary screens. Instead, assign a pointer to our own wrapper struct to PointPriv->spriteFuncs. Fixes crashes with multiple primary

[PATCH xf86-video-amdgpu] Wrap the whole miPointerScreenFuncRec, instead of only Set/MoveCursor

From: Michel Dänzer We were clobbering entries in mi's global miSpritePointerFuncs struct, which cannot work correctly with multiple primary screens. Instead, assign a pointer to our own wrapper struct to PointPriv->spriteFuncs. Fixes crashes with multiple primary

Re: Modesetting (amdgpudrmfb) artifacts on RAVEN APU

On 2018-03-07 17:48, KARBOWSKI Piotr wrote: On 2018-03-07 17:14, Harry Wentland wrote: Pushed a drm-fixes-4.16 branch (based on Alex's) to my FDO repo athttps://cgit.freedesktop.org/~hwentland/linux/  but I don't have a Raven system setup to test this at the moment. Tom, or Piotr, would you

Re: [PATCH 1/2] drm/amdgpu: Enable scatter gather display support

On 2018-03-07 06:38 PM, Alex Deucher wrote: > On Wed, Mar 7, 2018 at 12:29 PM, Samuel Li wrote: >> >> Why so complicated? If old user space compatibility is required, just use >> sg_display=0. > > It will always just work in that case and we can adjust for the > optimal

Re: [PATCH xf86-video-ati] Only change Set/MoveCursor hooks from what we expect

On 2018-03-07 04:45 AM, Mario Kleiner wrote: > On 03/05/2018 10:56 PM, Alex Deucher wrote: >> On Mon, Mar 5, 2018 at 12:44 PM, Michel Dänzer >> wrote: >>> From: Michel Dänzer >>> >>> Since xf86CursorCloseScreen runs after RADEONCloseScreen_KMS, >>>

Re: [PATCH 2/4] drm/amdgpu: refactoring mailbox to fix TDR handshake bugs

Hi Monk, See comments inline. — Sincerely Yours, Pixel On 07/03/2018, 4:58 PM, "Liu, Monk" wrote: HI Pixel The patch better not to be split, otherwise the stress TDR test still fail since there are couple issues and some of them mixed together For

RE: [PATCH 2/4] drm/amdgpu: refactoring mailbox to fix TDR handshake bugs

>Can you do that ? looks to me the MACRO in amdgpu only works for DW > aligned register names, so I'm afraid we cannot do that gracefully [Pixel] some readable macros can help us easily understand which register field is accessed. [ml] I can try it >[Pixel]generally, CMPL is

Re: New KFD ioctls: taking the skeletons out of the closet

Am 07.03.2018 um 00:34 schrieb Jerome Glisse: On Tue, Mar 06, 2018 at 05:44:41PM -0500, Felix Kuehling wrote: Hi all, Christian raised two potential issues in a recent KFD upstreaming code review that are related to the KFD ioctl APIs: 1. behaviour of -ERESTARTSYS 2. transactional nature

Re: [PATCH 1/2] drm/amdgpu: Enable scatter gather display support

On 2018-03-07 10:47 AM, Christian König wrote: > > See when I tested this the DDX and Mesa where unmodified, so both still > assumed VRAM as placement for scanout BOs, but the kernel forced scanout > BOs into GTT for testing. > > So what happened was that on scanout we moved the VRAM BO to GTT

Re: [PATCH 1/2] drm/amdgpu: Enable scatter gather display support

On 2018-03-07 11:04 AM, Christian König wrote: > Am 07.03.2018 um 10:53 schrieb Michel Dänzer: >> On 2018-03-07 10:47 AM, Christian König wrote: >>> See when I tested this the DDX and Mesa where unmodified, so both still >>> assumed VRAM as placement for scanout BOs, but the kernel forced scanout

RE: [PATCH 2/4] drm/amdgpu: refactoring mailbox to fix TDR handshake bugs

HI Pixel The patch better not to be split, otherwise the stress TDR test still fail since there are couple issues and some of them mixed together For your concerns: > Any VF ACK could lead missing msg if timing is bad while hypervisor send msg > quite frequently and guest send ack frequently

Re: [PATCH xf86-video-ati] Only change Set/MoveCursor hooks from what we expect

On 03/07/2018 09:50 AM, Michel Dänzer wrote: On 2018-03-07 04:45 AM, Mario Kleiner wrote: On 03/05/2018 10:56 PM, Alex Deucher wrote: On Mon, Mar 5, 2018 at 12:44 PM, Michel Dänzer wrote: From: Michel Dänzer Since xf86CursorCloseScreen runs after

Re: New KFD ioctls: taking the skeletons out of the closet

Am 07.03.2018 um 00:09 schrieb Dave Airlie: On 7 March 2018 at 08:44, Felix Kuehling wrote: Hi all, Christian raised two potential issues in a recent KFD upstreaming code review that are related to the KFD ioctl APIs: 1. behaviour of -ERESTARTSYS 2. transactional

Re: amdgpu with 8+ cards for GPU mining?

Well that is very interesting use case you got there. Just out of curiosity, can we get a dmesg and the content of /proc/iomem from that working system? Thanks, Christian. Am 07.03.2018 um 02:02 schrieb Joseph Wang: Thanks for all of the help.  I've purchased a Gigabyte GA-B250-Fintech

Re: [PATCH 2/2] drm/amdgpu:Always save uvd vcpu_bo in VM Mode

Am 06.03.2018 um 21:14 schrieb James Zhu: When UVD is in VM mode, there is not uvd handle exchanged, uvd.handles are always 0. So vcpu_bo always need save, Otherwise amdgpu driver will fail during suspend/resume. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105021 Signed-off-by: James

Re: [PATCH v2] drm/amdgpu: Clean sdma wptr register when only enable wptr polling

Reviewed-by: Christian König . Am 07.03.2018 um 07:17 schrieb Yu, Xiangliang: Reviewed-by: Xiangliang Yu -Original Message- From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf Of Emily Deng Sent: Wednesday, March

Re: [PATCH 1/2] drm/amdgpu: Enable scatter gather display support

Am 07.03.2018 um 09:42 schrieb Michel Dänzer: On 2018-03-06 07:23 PM, Christian König wrote: Am 06.03.2018 um 19:15 schrieb Michel Dänzer: On 2018-03-06 07:02 PM, Christian König wrote: Am 06.03.2018 um 18:51 schrieb Michel Dänzer: On 2018-03-06 06:44 PM, Christian König wrote: Am

Re: [PATCH 1/2] drm/amdgpu: Enable scatter gather display support

Am 07.03.2018 um 10:53 schrieb Michel Dänzer: On 2018-03-07 10:47 AM, Christian König wrote: See when I tested this the DDX and Mesa where unmodified, so both still assumed VRAM as placement for scanout BOs, but the kernel forced scanout BOs into GTT for testing. So what happened was that on

[PATCH] drm/amdgpu: Correct the place of amdgpu_pm_sysfs_fini

The amdgpu_pm_sysfs_fini should call before amdgpu_device_ip_fini, or the adev->pm.dpm_enabled would be set to 0, then the device files related to pp won't be removed by amdgpu_pm_sysfs_fini when unload driver. Signed-off-by: Emily Deng ---

[PATCH v2 2/2] drm/amdgpu:Always save uvd vcpu_bo in VM Mode

When UVD is in VM mode, there is not uvd handle exchanged, uvd.handles are always 0. So vcpu_bo always need save, Otherwise amdgpu driver will fail during suspend/resume. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105021 Signed-off-by: James Zhu Reviewed-by: Leo

[PATCH v2 2/2] drm/amdgpu:Always save uvd vcpu_bo in VM Mode

When UVD is in VM mode, there is not uvd handle exchanged, uvd.handles are always 0. So vcpu_bo always need save, Otherwise amdgpu driver will fail during suspend/resume. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105021 Signed-off-by: James Zhu Reviewed-by: Leo

RE: deprecated register issues

+ UMD guys Hi David Do you know if GC_USER_RB_BACKEND_DISABLE is still exist for gfx9/vega10 ? We found CC_RB_BACKEND_DISABLE was deprecated but looks it is still in use in kmd, so I want to check with you both of above registers Thanks /Monk From: amd-gfx

Re: [PATCH] drm/amdgpu: Correct the place of amdgpu_pm_sysfs_fini

On Wed, Mar 7, 2018 at 5:17 AM, Emily Deng wrote: > The amdgpu_pm_sysfs_fini should call before amdgpu_device_ip_fini, > or the adev->pm.dpm_enabled would be set to 0, then the device files > related to pp won't be removed by amdgpu_pm_sysfs_fini when unload > driver. > >

Re: deprecated register issues

We requires base driver to provide the mask of disabled RB. This is why kernel read the CC_RB_BACKEND_DISABLE to collect the harvest configuration. Where did you get to know that the register is deprecated? I think it should still be there. Best Regards, David On Mar 7, 2018, at 9:49 PM, Liu,

Re: deprecated register issues

Hi David, well I just figured that this is a misunderstanding. Accessing this register and some other deprecated registers can cause problem when invalidating VMHUBs. This register itself isn't deprecated, the wording in a patch fixing things is just a bit unclear. Question is is that

Re: Modesetting (amdgpudrmfb) artifacts on RAVEN APU

It's in the next set of display patches for drm-next but I don't think it'll be in 4.16 at this point unless it gets cherry picked out. Alex would know for sure since he co-ordinates that with Dave. Tom On 03/06/2018 12:38 PM, KARBOWSKI Piotr wrote: On 2018-03-06 18:28, Tom St Denis wrote: I

Re: deprecated register issues

Hi Monk, I honestly don't have the slightest idea why we are still accessing CC_RB_BACKEND_DISABLE. Maybe it still contains some useful values? Key point was that we needed to stop accessing it all the time to avoid triggering problems. Regards, Christian. Am 07.03.2018 um 13:11 schrieb

[PATCH 2/8] drm/amd/pp: Clean up header file include

smu7_smumgr.h should not be included in rv and vega, The common functions for all smu7 asics are put in smu_smumgr.c. Not include cgs interface in smumgr.c. the code used cgs interface has been deleted. Not include smu_ucode_xfer_vi.h in rv/vega Change-Id:

[PATCH 1/8] drm/amd/pp: Refine code for smu7 in powerplay

1. Add avfs_support in hwmgr to avoid to visit smu backend struct in hwmgr.so do not need to include smu7_smumgr.h under hwmgr folder. 2. simplify the list of enum AVFS_BTC_STATUS Change-Id: I04c769972deff797229339f3ccb1c442b35768a2 Signed-off-by: Rex Zhu ---

[PATCH 3/8] drm/amd/pp: Delete is_smc_ram_running function on RV

1. There is a race condition when another ip also use same register pairs 2. check once at boot up by GetDriverIfVersion message is sufficient to check SMU health. so delete is_smc_ram_running check. Change-Id: I3c5f5ebac36c1ae4a7dd72f482fc27a4f362975e Signed-off-by: Rex Zhu

deprecated register issues

Hi Christian I remember you and AlexD mentioned that a handful registers are deprecated for greenland (gfx9) e.g. CC_RB_BACKEND_DISABLE do you know why we still have this routine ? static u32 gfx_v9_0_get_rb_active_bitmap(struct amdgpu_device *adev) { u32 data, mask; data =

[PATCH 4/8] drm/amd/pp: Clean up the code for RV in powerplay

In send_message_to_smu helper functions, Print out the error code for debug if smu failed to response. and the helper functions always return true, so no need to check their return value. Signed-off-by: Rex Zhu Change-Id: I27da8bf22d3cea0df968df7b0809dc727461762f ---

[PATCH 5/8] drm/amd/pp: Clean up code for RV in powerplay.

1. make functions static 2. add rv_read_arg_from_smc to smu backend function table. Change-Id: I9baecaec95553923e59d1a4cf92a67551769b755 Signed-off-by: Rex Zhu --- drivers/gpu/drm/amd/powerplay/hwmgr/rv_hwmgr.c | 12 ++--

[PATCH 6/8] drm/amd/pp: Add new smu backend function smc_table_manager

Change-Id: I4c68f7627387c4ae67612e09651318f5ae90162a Signed-off-by: Rex Zhu --- drivers/gpu/drm/amd/powerplay/inc/hwmgr.h | 1 + drivers/gpu/drm/amd/powerplay/inc/smumgr.h| 2 ++ drivers/gpu/drm/amd/powerplay/smumgr/smumgr.c | 8 3 files changed, 11

[PATCH 7/8] drm/amd/pp: Add rv_copy_table_from/to_smc to smu backend function table

Change-Id: I67597a70008a93381e9bbe2439851e50f012d5ff Signed-off-by: Rex Zhu --- drivers/gpu/drm/amd/powerplay/hwmgr/rv_hwmgr.c | 3 +- drivers/gpu/drm/amd/powerplay/inc/smumgr.h | 5 ++ drivers/gpu/drm/amd/powerplay/smumgr/rv_smumgr.c | 60 +++-

RE: [PATCH 1/4] drm/amd/pp: Replace files name rv_* with smu10_*

>For patch 4, I think we should stick with the asic names. The smu7 variants >are too confusing. I can't remember if CI was 7.0.1 or 7.0.2, etc. I'd >prefer to align the file names to the >smu interface headers (e.g., smu7, smu71, smu72, smu73, smu74). Rex: For patch4, I am ok with the

[PATCH] drm/amdgpu: refactoring mailbox to fix TDR handshake bugs(v2)

this patch actually refactor mailbox implmentations, and all below changes are needed together to fix all those mailbox handshake issues exposured by heavey TDR test. 1)refactor all mailbox functions based on byte accessing for mb_control reason is to avoid touching non-related bits when writing

Re: Modesetting (amdgpudrmfb) artifacts on RAVEN APU

I'm prepping some cherry-picks for drm-fixes-4.16, including this. Should've done that a while ago, but shouldn't be too late yet. Harry On 2018-03-07 07:55 AM, Tom St Denis wrote: > It's in the next set of display patches for drm-next but I don't think it'll > be in 4.16 at this point unless

Re: deprecated register issues

Right. We ran into issues with reading back that register at runtime when UMDs queried it when other stuff was in flight, so we just read it once at startup and cache the results. Now when UMDs request it, we return the cached value. Alex From: Koenig,

Re: [PATCH 6/6] drm/amdgpu: explicit give BO type to amdgpu_bo_create

On 2018-03-07 04:16 AM, Christian König wrote: > Am 06.03.2018 um 22:29 schrieb Felix Kuehling: >> NAK. >> >> For KFD we need the ability to create a BO from an SG list that doesn't >> come from another BO. We use this for mapping pages from the doorbell >> aperture into GPUVM for GPU

Re: [PATCH 2/4] drm/amdgpu: refactoring mailbox to fix TDR handshake bugs

Hi Monk, It’s a long patch which could split into 6 pieces at most… anyway I got some questions inline to have a better understanding. — Sincerely Yours, Pixel On 06/03/2018, 11:29 AM, "amd-gfx on behalf of Monk Liu"

Re: [PATCH 1/2] drm/amdgpu: Enable scatter gather display support

On 2018-03-06 07:23 PM, Christian König wrote: > Am 06.03.2018 um 19:15 schrieb Michel Dänzer: >> On 2018-03-06 07:02 PM, Christian König wrote: >>> Am 06.03.2018 um 18:51 schrieb Michel Dänzer: On 2018-03-06 06:44 PM, Christian König wrote: > Am 06.03.2018 um 18:22 schrieb Li, Samuel:

Re: [PATCH 6/6] drm/amdgpu: explicit give BO type to amdgpu_bo_create

Am 06.03.2018 um 22:29 schrieb Felix Kuehling: NAK. For KFD we need the ability to create a BO from an SG list that doesn't come from another BO. We use this for mapping pages from the doorbell aperture into GPUVM for GPU self-dispatch. You can still do this, see

Re: Modesetting (amdgpudrmfb) artifacts on RAVEN APU

On 2018-03-07 17:14, Harry Wentland wrote: Pushed a drm-fixes-4.16 branch (based on Alex's) to my FDO repo athttps://cgit.freedesktop.org/~hwentland/linux/ but I don't have a Raven system setup to test this at the moment. Tom, or Piotr, would you be able to check that the fix works as

Re: Modesetting (amdgpudrmfb) artifacts on RAVEN APU

Cloning/building will take a bit. I'll let you know later this afternoon. Cheers, Tom On 03/07/2018 11:14 AM, Harry Wentland wrote: On 2018-03-07 09:55 AM, Harry Wentland wrote: I'm prepping some cherry-picks for drm-fixes-4.16, including this. Should've done that a while ago, but shouldn't

Re: New KFD ioctls: taking the skeletons out of the closet

On Wed, Mar 07, 2018 at 09:38:03AM +0100, Christian K??nig wrote: > Am 07.03.2018 um 00:09 schrieb Dave Airlie: > > On 7 March 2018 at 08:44, Felix Kuehling wrote: > > > Hi all, > > > > > > Christian raised two potential issues in a recent KFD upstreaming code > > >

Re: Modesetting (amdgpudrmfb) artifacts on RAVEN APU

On 2018-03-07 09:55 AM, Harry Wentland wrote: > I'm prepping some cherry-picks for drm-fixes-4.16, including this. Should've > done that a while ago, but shouldn't be too late yet. > Pushed a drm-fixes-4.16 branch (based on Alex's) to my FDO repo at