答复: Regression with kernel 4.18 - AMD RX 550 fails IB ring test on power-up

[Qu, Jim]

Hi Luis,

1. May you also test earlier kernel? v4.17 or v4.16.
2. May you test the issue only with amdgpu?

Thanks
JimQu


发件人: amd-gfx  代表 Luís Mendes 

发送时间: 2018年7月11日 6:04:00
收件人: Michel Dänzer; Koenig, Christian; amd-gfx list
主题: Re: Regression with kernel 4.18 - AMD RX 550 fails IB ring test on power-up

Hi,

Issue remains in kernel 4.18-rc4 using SAPPHIRE RX 550 4GB.

Logs follow attached.

Regards,
Luis

On Tue, Jun 26, 2018 at 10:08 AM, Luís Mendes 
mailto:luis.p.men...@gmail.com>> wrote:
Hi,

I've tried kernel 4.18-rc2 on a system with a NVIDIA GTX 1050 Ti and an AMD RX 
550 4GB and the RX 550 card is failing the IB ring test.

[5.033217] [drm:gfx_v8_0_ring_test_ib [amdgpu]] *ERROR* amdgpu: ib test 
failed (scratch(0xC040)=0x)
[5.033264] [drm:amdgpu_ib_ring_tests [amdgpu]] *ERROR* amdgpu: failed 
testing IB on ring 6 (-22).

Please see the attached log.

Regards,
Luís

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

Re: GPU hang trying to run OpenCL kernels on x86_64

[Luís Mendes]

Hi,

Issue remains in kernel 4.17.5, tested with SAPPHIRE RX 550 4GB running
same OpenCL kernel.

[  227.443025] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring sdma0
timeout, last signaled seq=22, last emitted seq=25
[  227.443112] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring sdma1
timeout, last signaled seq=22, last emitted seq=24
[  227.443117] [drm] IP block:gmc_v8_0 is hung!
[  227.443120] [drm] IP block:tonga_ih is hung!
[  227.443123] [drm] IP block:gfx_v8_0 is hung!
[  227.443124] [drm] IP block:gmc_v8_0 is hung!
[  227.443126] [drm] IP block:tonga_ih is hung!
[  227.443127] [drm] IP block:sdma_v3_0 is hung!
[  227.443128] [drm] IP block:uvd_v6_0 is hung!
[  227.443130] [drm] IP block:gfx_v8_0 is hung!
[  227.443132] [drm] IP block:sdma_v3_0 is hung!
[  227.443133] [drm] IP block:vce_v3_0 is hung!
[  227.443134] [drm] GPU recovery disabled.
[  227.443137] [drm] IP block:uvd_v6_0 is hung!
[  227.443140] [drm] IP block:vce_v3_0 is hung!
[  227.443141] [drm] GPU recovery disabled.

Regards,
Luís

On Tue, Jun 26, 2018 at 10:03 AM, Luís Mendes 
wrote:

>
> I've tested Ubuntu 18.04 with kernel 4.17.2 using libdrm-2.4.92 and
> mesa-18.1.0 and AMD RX 550 4GB is still hanging when running the identified
> OpenCL kernels.
>
> [  548.704916] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring sdma0
> timeout, last signaled seq=30, last emitted seq=33
> [  548.704988] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring sdma1
> timeout, last signaled seq=29, last emitted seq=31
> [  548.704992] [drm] IP block:gmc_v8_0 is hung!
> [  548.704994] [drm] IP block:tonga_ih is hung!
> [  548.704996] [drm] IP block:gmc_v8_0 is hung!
> [  548.704997] [drm] IP block:gfx_v8_0 is hung!
> [  548.704998] [drm] IP block:sdma_v3_0 is hung!
> [  548.704999] [drm] IP block:tonga_ih is hung!
> [  548.705000] [drm] IP block:uvd_v6_0 is hung!
> [  548.705001] [drm] IP block:gfx_v8_0 is hung!
> [  548.705002] [drm] IP block:sdma_v3_0 is hung!
> [  548.705003] [drm] IP block:uvd_v6_0 is hung!
> [  548.705004] [drm] IP block:vce_v3_0 is hung!
> [  548.705005] [drm] GPU recovery disabled.
> [  548.705006] [drm] IP block:vce_v3_0 is hung!
> [  548.705007] [drm] GPU recovery disabled.
>
> Are there any new regarding this issue?
>
> Regards,
> Luís
>
> On Fri, May 25, 2018 at 11:23 AM, Luís Mendes 
> wrote:
>
>> I've just tested Ubuntu 18.04 with kernel 4.17-rc6 using libdrm-2.4.92
>> and mesa-18.1.0.
>> Now both sdma0 and sdma1 timeout as can be seen in the attached logs.
>>
>> ~agd5f -b drm-next-4.18 doesn't improve also.
>>
>> I have also tried amdgpu-pro 18.20 both on Ubuntu 18.04 and 16.04, but no
>> improvements.
>> I have tried amdgpu-pro 18.10 and 17.50 and also no improvements.
>>
>> ./amdgpu-pro-install -opencl=legacy,pal --headless
>>
>> On Thu, May 24, 2018 at 11:18 AM, Luís Mendes 
>> wrote:
>>
>>> Additional update...
>>>
>>> I was able to boot and enter X by installing an NVIDIA GTX 1050 Ti as
>>> the primary display card and using an AMD RX 550 as the secondary card on
>>> the Tyan S7025 with the same Ubuntu 18.04 and the same Linux kernel
>>> 4.17-rc6.
>>> However once I try to run an OpenCL kernel on RX 550 I get a sdma1
>>> timeout and the GPU hangs, which likely what is happening when I boot with
>>> RX 550 as the single GPU card on the system.
>>>
>>> This means it is not an issue introduced in 4.17-rc6, it just means that
>>> I didn't notice the effect of the system with the two GPUs vs system with
>>> single AMD GPU.
>>>
>>> The dmesg log follows attached.
>>>
>>> Luís
>>>
>>> On Thu, May 24, 2018 at 10:13 AM, Luís Mendes 
>>> wrote:
>>>
 Hi Michel,

 I also work as a researcher at a university and we are considering
 buying AMD cards to do OpenCL computations for numerical modelling, but
 currently I am unable to give a try at the AMD cards I have at home.
 I couldn't find any working driver for them... also amdgpu-pro drivers
 don't work, or at least I have been unable to make them work.

 Regards,
 Luís

 On Thu, May 24, 2018 at 10:01 AM, Luís Mendes 
 wrote:

> Hi Michel,
>
> So summarizing with Linux kernel 4.17-rc6 on Ubuntu 18.04 using AMD RX
> 460/RX 550 I am not able to enter X.
> The same system with AMD Radeon R7 240 not only enters X as also runs
> the OpenCL kernel that RX 460 / RX 550 are unable to run for all the
> kernels that I have tested.
> Could this also be a Mesa issue, regarding OpenCL on RX 460?
>
> Regards,
> Luís
>
> On Thu, May 24, 2018 at 9:55 AM, Luís Mendes 
> wrote:
>
>> Hi Michel,
>>
>> I will have to check previous rc releases of 4.17 to see if it wasn't
>> already happening, before trying any possible git bisect.
>> As an update I can say that an AMD Radeon R7 240 works fine on the
>> same system with the same kernel and I am able to run the OpenCL kernels,
>> that I couldn't with RX 460/RX 550.
>>
>> Regards,
>> Luís
>>
>> 

Re: Regression with kernel 4.18 - AMD RX 550 fails IB ring test on power-up

[Luís Mendes]

Hi,

Issue remains in kernel 4.18-rc4 using SAPPHIRE RX 550 4GB.

Logs follow attached.

Regards,
Luis

On Tue, Jun 26, 2018 at 10:08 AM, Luís Mendes 
wrote:

> Hi,
>
> I've tried kernel 4.18-rc2 on a system with a NVIDIA GTX 1050 Ti and an
> AMD RX 550 4GB and the RX 550 card is failing the IB ring test.
>
> [5.033217] [drm:gfx_v8_0_ring_test_ib [amdgpu]] *ERROR* amdgpu: ib
> test failed (scratch(0xC040)=0x)
> [5.033264] [drm:amdgpu_ib_ring_tests [amdgpu]] *ERROR* amdgpu: failed
> testing IB on ring 6 (-22).
>
> Please see the attached log.
>
> Regards,
> Luís
>
[2.375197] [drm] amdgpu kernel modesetting enabled.
[2.384476] AMD IOMMUv2 driver by Joerg Roedel 
[2.384477] AMD IOMMUv2 functionality not available on this system
[2.394625] checking generic (cf00 50) vs hw (d000 1000)
[2.394626] checking generic (cf00 50) vs hw (ce00 200)
[2.394627] fb: switching to nouveaufb from VESA VGA
[2.394650] Console: switching to colour dummy device 80x25
[2.394909] nouveau :08:00.0: NVIDIA GP107 (137000a1)
[2.402493] CRAT table not found
[2.402497] Virtual CRAT table created for CPU
[2.402498] Parsing CRAT table with 2 nodes
[2.402500] Creating topology SYSFS entries
[2.402533] Topology: Add CPU node
[2.402534] Finished initializing topology
[2.402622] kfd kfd: Initialized module
[2.404317] amdgpu :06:00.0: enabling device ( -> 0003)
[2.404713] [drm] initializing kernel modesetting (POLARIS11 0x1002:0x67FF 
0x1DA2:0xE367 0xFF).
[2.404724] [drm] register mmio base: 0xF7E8
[2.404725] [drm] register mmio size: 262144
[2.404735] [drm] probing gen 2 caps for device 8086:340e = 393042/0
[2.404737] [drm] probing mlw for device 8086:340e = 393042
[2.404739] [drm] add ip block number 0 
[2.404740] [drm] add ip block number 1 
[2.404741] [drm] add ip block number 2 
[2.404742] [drm] add ip block number 3 
[2.404743] [drm] add ip block number 4 
[2.404744] [drm] add ip block number 5 
[2.404745] [drm] add ip block number 6 
[2.404746] [drm] add ip block number 7 
[2.404747] [drm] add ip block number 8 
[2.404752] kfd kfd: skipped device 1002:67ff, PCI rejects atomics
[2.404763] [drm] UVD is enabled in VM mode
[2.404764] [drm] UVD ENC is enabled in VM mode
[2.404767] [drm] VCE enabled in VM mode
[2.437011] e1000e :02:00.0 eth1: (PCI Express:2.5GT/s:Width x1) 
00:e0:81:d6:04:64
[2.437013] e1000e :02:00.0 eth1: Intel(R) PRO/1000 Network Connection
[2.437097] e1000e :02:00.0 eth1: MAC: 3, PHY: 8, PBA No: FF-0FF
[2.440226] e1000e :02:00.0 enp2s0: renamed from eth1
[2.509369] nouveau :08:00.0: bios: version 86.07.39.00.bb
[2.583267] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[2.584186] usb 2-2: new high-speed USB device number 3 using ehci-pci
[2.584979] ata1.00: supports DRM functions and may not be fully accessible
[2.585576] ata1.00: NCQ Send/Recv Log not supported
[2.585578] ata1.00: ATA-9: Samsung SSD 850 EVO 120GB, EMT01B6Q, max UDMA/133
[2.585579] ata1.00: 234441648 sectors, multi 1: LBA48 NCQ (depth 32), AA
[2.587286] ata1.00: supports DRM functions and may not be fully accessible
[2.587795] ata1.00: NCQ Send/Recv Log not supported
[2.589006] ata1.00: configured for UDMA/133
[2.591303] scsi 0:0:0:0: Direct-Access ATA  Samsung SSD 850  1B6Q 
PQ: 0 ANSI: 5
[2.592018] sd 0:0:0:0: Attached scsi generic sg0 type 0
[2.592428] sd 0:0:0:0: [sda] 234441648 512-byte logical blocks: (120 GB/112 
GiB)
[2.592498] sd 0:0:0:0: [sda] Write Protect is off
[2.592500] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
[2.592551] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, 
doesn't support DPO or FUA
[2.593401]  sda: sda1 sda2 < sda5 >
[2.594192] sd 0:0:0:0: [sda] supports TCG Opal
[2.594194] sd 0:0:0:0: [sda] Attached SCSI disk
[2.626528] ATOM BIOS: 113-367BF-U41
[2.626541] [drm] GPU posting now...
[2.740034] [drm] vm size is 64 GB, 2 levels, block size is 10-bit, fragment 
size is 9-bit
[2.740075] amdgpu :06:00.0: VRAM: 4096M 0x00F4 - 
0x00F4 (4096M used)
[2.740077] amdgpu :06:00.0: GTT: 256M 0x - 
0x0FFF
[2.740083] [drm] Detected VRAM RAM=4096M, BAR=256M
[2.740084] [drm] RAM width 128bits GDDR5
[2.740234] [TTM] Zone  kernel: Available graphics memory: 24721696 kiB
[2.740235] [TTM] Zone   dma32: Available graphics memory: 2097152 kiB
[2.740236] [TTM] Initializing pool allocator
[2.740240] [TTM] Initializing DMA pool allocator
[2.740251] e1000e :03:00.0 enp3s0: renamed from eth0
[2.740679] [drm] amdgpu: 4096M of VRAM memory ready
[2.740680] [drm] amdgpu: 4096M of GTT memory ready.
[2.740697] [drm] GART: num cpu pages 65536, num gpu pages 65536
[2.740759] [drm] PCIE GART of 256M 

[PATCH] drm/amdgpu/vi: fix mixed up state in smu clockgating setup

[Alex Deucher]

Use the PP_STATE_SUPPORT_* rather than AMD_CG_SUPPORT_*
when communicating with the SMU.

Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/amd/amdgpu/vi.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/vi.c b/drivers/gpu/drm/amd/amdgpu/vi.c
index 4ac1288ab7df..42c8ad105b05 100644
--- a/drivers/gpu/drm/amd/amdgpu/vi.c
+++ b/drivers/gpu/drm/amd/amdgpu/vi.c
@@ -1363,11 +1363,11 @@ static int vi_common_set_clockgating_state_by_smu(void 
*handle,
 
if (adev->cg_flags & (AMD_CG_SUPPORT_MC_LS | AMD_CG_SUPPORT_MC_MGCG)) {
if (adev->cg_flags & AMD_CG_SUPPORT_MC_LS) {
-   pp_support_state = AMD_CG_SUPPORT_MC_LS;
+   pp_support_state = PP_STATE_SUPPORT_LS;
pp_state = PP_STATE_LS;
}
if (adev->cg_flags & AMD_CG_SUPPORT_MC_MGCG) {
-   pp_support_state |= AMD_CG_SUPPORT_MC_MGCG;
+   pp_support_state |= PP_STATE_SUPPORT_CG;
pp_state |= PP_STATE_CG;
}
if (state == AMD_CG_STATE_UNGATE)
@@ -1382,11 +1382,11 @@ static int vi_common_set_clockgating_state_by_smu(void 
*handle,
 
if (adev->cg_flags & (AMD_CG_SUPPORT_SDMA_LS | 
AMD_CG_SUPPORT_SDMA_MGCG)) {
if (adev->cg_flags & AMD_CG_SUPPORT_SDMA_LS) {
-   pp_support_state = AMD_CG_SUPPORT_SDMA_LS;
+   pp_support_state = PP_STATE_SUPPORT_LS;
pp_state = PP_STATE_LS;
}
if (adev->cg_flags & AMD_CG_SUPPORT_SDMA_MGCG) {
-   pp_support_state |= AMD_CG_SUPPORT_SDMA_MGCG;
+   pp_support_state |= PP_STATE_SUPPORT_CG;
pp_state |= PP_STATE_CG;
}
if (state == AMD_CG_STATE_UNGATE)
@@ -1401,11 +1401,11 @@ static int vi_common_set_clockgating_state_by_smu(void 
*handle,
 
if (adev->cg_flags & (AMD_CG_SUPPORT_HDP_LS | AMD_CG_SUPPORT_HDP_MGCG)) 
{
if (adev->cg_flags & AMD_CG_SUPPORT_HDP_LS) {
-   pp_support_state = AMD_CG_SUPPORT_HDP_LS;
+   pp_support_state = PP_STATE_SUPPORT_LS;
pp_state = PP_STATE_LS;
}
if (adev->cg_flags & AMD_CG_SUPPORT_HDP_MGCG) {
-   pp_support_state |= AMD_CG_SUPPORT_HDP_MGCG;
+   pp_support_state |= PP_STATE_SUPPORT_CG;
pp_state |= PP_STATE_CG;
}
if (state == AMD_CG_STATE_UNGATE)
-- 
2.13.6

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

Re: BUG: *ERROR* No EDID read

[Alex Deucher]

On Fri, Jul 6, 2018 at 12:44 PM, Daniel Andersson  wrote:
> Alright, I redid the bisect and this time ended up on
> 018d82e5f02ef3583411bcaa4e00c69786f46f19 . If I revert it, it fixes my
> issue. Reverting it on 4.18-rc2 also works.

I've gone ahead and reverted the patch.

Thanks,

Alex

>
> // Daniel
>
> On 5 July 2018 at 21:47, Daniel Andersson  wrote:
>> [0.00] Command line: BOOT_IMAGE=/vmlinuz-linuxtest
>> root=UUID=27247597-a354-42f3-8040-caff9592a297 drm.debug=0x4 rw quiet
>> [0.00] Kernel command line: BOOT_IMAGE=/vmlinuz-linuxtest
>> root=UUID=27247597-a354-42f3-8040-caff9592a297 drm.debug=0x4 rw quiet
>> [5.674793] [drm:bios_parser_get_firmware_info [amdgpu]] At
>> bios_parser_get_firmware_info switch, got major 3 minor 1
>> [5.674833] [drm:bios_parser_get_firmware_info [amdgpu]] *ERROR* At
>> bios_parser_get_firmware_info switch, got major 3 minor 1
>> [5.674887] [drm:bios_parser_get_firmware_info [amdgpu]] At
>> bios_parser_get_firmware_info switch, got major 3 minor 1
>> [5.674930] [drm:bios_parser_get_firmware_info [amdgpu]] *ERROR* At
>> bios_parser_get_firmware_info switch, got major 3 minor 1
>> [5.674974] [drm:bios_parser_get_firmware_info [amdgpu]] At
>> bios_parser_get_firmware_info switch, got major 3 minor 1
>> [5.675014] [drm:bios_parser_get_firmware_info [amdgpu]] *ERROR* At
>> bios_parser_get_firmware_info switch, got major 3 minor 1
>> [5.675056] [drm:bios_parser_get_firmware_info [amdgpu]] At
>> bios_parser_get_firmware_info switch, got major 3 minor 1
>> [5.675095] [drm:bios_parser_get_firmware_info [amdgpu]] *ERROR* At
>> bios_parser_get_firmware_info switch, got major 3 minor 1
>> [5.675138] [drm:bios_parser_get_firmware_info [amdgpu]] At
>> bios_parser_get_firmware_info switch, got major 3 minor 1
>> [5.675178] [drm:bios_parser_get_firmware_info [amdgpu]] *ERROR* At
>> bios_parser_get_firmware_info switch, got major 3 minor 1
>> [5.675221] [drm:bios_parser_get_firmware_info [amdgpu]] At
>> bios_parser_get_firmware_info switch, got major 3 minor 1
>> [5.675260] [drm:bios_parser_get_firmware_info [amdgpu]] *ERROR* At
>> bios_parser_get_firmware_info switch, got major 3 minor 1
>> [5.675304] [drm:bios_parser_get_firmware_info [amdgpu]] At
>> bios_parser_get_firmware_info switch, got major 3 minor 1
>> [5.675342] [drm:bios_parser_get_firmware_info [amdgpu]] *ERROR* At
>> bios_parser_get_firmware_info switch, got major 3 minor 1
>> [5.675384] [drm:bios_parser_get_firmware_info [amdgpu]] At
>> bios_parser_get_firmware_info switch, got major 3 minor 1
>> [5.675422] [drm:bios_parser_get_firmware_info [amdgpu]] *ERROR* At
>> bios_parser_get_firmware_info switch, got major 3 minor 1
>> [5.675465] [drm:bios_parser_get_firmware_info [amdgpu]] At
>> bios_parser_get_firmware_info switch, got major 3 minor 1
>> [5.675503] [drm:bios_parser_get_firmware_info [amdgpu]] *ERROR* At
>> bios_parser_get_firmware_info switch, got major 3 minor 1
>> [5.675587] [drm:bios_parser_get_firmware_info [amdgpu]] At
>> bios_parser_get_firmware_info switch, got major 3 minor 1
>> [5.675626] [drm:bios_parser_get_firmware_info [amdgpu]] *ERROR* At
>> bios_parser_get_firmware_info switch, got major 3 minor 1
>>
>> I don't really know what is going on. If I go back to 4.17 and apply
>> my "fix". It doesn't work. I suppose my bisect didn't get me the right
>> commit. I probably never tested that the commit, from the bisect, was
>> actually bad. I was also a little lazy and did "bisect start
>> 29dcea88779c856c7dc92040a0c01233263101d4
>> 6da6c0db5316275015e8cc2959f12a17584aeb64 -- drivers/gpu/drm/amd".
>>
>> I guess I'll try another bisect tomorrow on the entire tree, sorry for
>> the extra work.
>>
>> // Daniel
>>
>> On 5 July 2018 at 20:22, Harry Wentland  wrote:
>>> On 2018-07-05 01:43 PM, Daniel Andersson wrote:
 Well, this workaround:

 diff --git a/drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c
 b/drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c
 index 10a5807a7e8b..d0f5910c906c 100644
 --- a/drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c
 +++ b/drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c
 @@ -1321,6 +1321,8 @@ static enum bp_result bios_parser_get_firmware_info(
   header = GET_IMAGE(struct atom_common_table_header,
   DATA_TABLES(firmwareinfo));
   get_atom_data_table_revision(header, );
 +dm_output_to_console("At bios_parser_get_firmware_info switch,
 got major %d minor %d", revision.major, revision.minor);
 +dm_error("At bios_parser_get_firmware_info switch, got major %d
 minor %d", revision.major, revision.minor);
   switch (revision.major) {
   case 3:
   switch (revision.minor) {
 @@ -1328,7 +1330,7 @@ static enum bp_result bios_parser_get_firmware_info(
   result = get_firmware_info_v3_1(bp, info);
   break;
   case 2:
 - result = get_firmware_info_v3_2(bp, info);
 + result = 

Re: [PATCH] Revert "drm/amd/display: Don't return ddc result and read_bytes in same return value"

[Harry Wentland]

On 2018-07-10 02:06 PM, Alex Deucher wrote:
> This reverts commit 018d82e5f02ef3583411bcaa4e00c69786f46f19.
> 
> This breaks DDC in certain cases.  Revert for 4.18 and previous kernels.
> For 4.19, this is fixed with the following more extensive patches:
> drm/amd/display: Serialize is_dp_sink_present
> drm/amd/display: Break out function to simply read aux reply
> drm/amd/display: Return aux replies directly to DRM
> drm/amd/display: Right shift AUX reply value sooner than later
> drm/amd/display: Read AUX channel even if only status byte is returned
> 
> Link: https://lists.freedesktop.org/archives/amd-gfx/2018-July/023788.html
> Signed-off-by: Alex Deucher 
> Cc: sta...@vger.kernel.org

Acked-by: Harry Wentland 

Harry

> ---
>  .../drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c  | 20 
> 
>  drivers/gpu/drm/amd/display/dc/core/dc_link_ddc.c| 10 +++---
>  drivers/gpu/drm/amd/display/dc/inc/dc_link_ddc.h |  5 ++---
>  3 files changed, 13 insertions(+), 22 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c 
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> index 4304d9e408b8..ace9ad578ca0 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> @@ -83,22 +83,21 @@ static ssize_t dm_dp_aux_transfer(struct drm_dp_aux *aux,
>   enum i2c_mot_mode mot = (msg->request & DP_AUX_I2C_MOT) ?
>   I2C_MOT_TRUE : I2C_MOT_FALSE;
>   enum ddc_result res;
> - uint32_t read_bytes = msg->size;
> + ssize_t read_bytes;
>  
>   if (WARN_ON(msg->size > 16))
>   return -E2BIG;
>  
>   switch (msg->request & ~DP_AUX_I2C_MOT) {
>   case DP_AUX_NATIVE_READ:
> - res = dal_ddc_service_read_dpcd_data(
> + read_bytes = dal_ddc_service_read_dpcd_data(
>   TO_DM_AUX(aux)->ddc_service,
>   false,
>   I2C_MOT_UNDEF,
>   msg->address,
>   msg->buffer,
> - msg->size,
> - _bytes);
> - break;
> + msg->size);
> + return read_bytes;
>   case DP_AUX_NATIVE_WRITE:
>   res = dal_ddc_service_write_dpcd_data(
>   TO_DM_AUX(aux)->ddc_service,
> @@ -109,15 +108,14 @@ static ssize_t dm_dp_aux_transfer(struct drm_dp_aux 
> *aux,
>   msg->size);
>   break;
>   case DP_AUX_I2C_READ:
> - res = dal_ddc_service_read_dpcd_data(
> + read_bytes = dal_ddc_service_read_dpcd_data(
>   TO_DM_AUX(aux)->ddc_service,
>   true,
>   mot,
>   msg->address,
>   msg->buffer,
> - msg->size,
> - _bytes);
> - break;
> + msg->size);
> + return read_bytes;
>   case DP_AUX_I2C_WRITE:
>   res = dal_ddc_service_write_dpcd_data(
>   TO_DM_AUX(aux)->ddc_service,
> @@ -139,9 +137,7 @@ static ssize_t dm_dp_aux_transfer(struct drm_dp_aux *aux,
>r == DDC_RESULT_SUCESSFULL);
>  #endif
>  
> - if (res != DDC_RESULT_SUCESSFULL)
> - return -EIO;
> - return read_bytes;
> + return msg->size;
>  }
>  
>  static enum drm_connector_status
> diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link_ddc.c 
> b/drivers/gpu/drm/amd/display/dc/core/dc_link_ddc.c
> index ae48d603ebd6..49c2face1e7a 100644
> --- a/drivers/gpu/drm/amd/display/dc/core/dc_link_ddc.c
> +++ b/drivers/gpu/drm/amd/display/dc/core/dc_link_ddc.c
> @@ -629,14 +629,13 @@ bool dal_ddc_service_query_ddc_data(
>   return ret;
>  }
>  
> -enum ddc_result dal_ddc_service_read_dpcd_data(
> +ssize_t dal_ddc_service_read_dpcd_data(
>   struct ddc_service *ddc,
>   bool i2c,
>   enum i2c_mot_mode mot,
>   uint32_t address,
>   uint8_t *data,
> - uint32_t len,
> - uint32_t *read)
> + uint32_t len)
>  {
>   struct aux_payload read_payload = {
>   .i2c_over_aux = i2c,
> @@ -653,8 +652,6 @@ enum ddc_result dal_ddc_service_read_dpcd_data(
>   .mot = mot
>   };
>  
> - *read = 0;
> -
>   if (len > DEFAULT_AUX_MAX_DATA_SIZE) {
>   BREAK_TO_DEBUGGER();
>   return DDC_RESULT_FAILED_INVALID_OPERATION;
> @@ -664,8 +661,7 @@ enum ddc_result dal_ddc_service_read_dpcd_data(
>   ddc->ctx->i2caux,
>   ddc->ddc_pin,
>   )) {
> - *read = command.payloads->length;
> - return DDC_RESULT_SUCESSFULL;
> + return (ssize_t)command.payloads->length;
>   }
>  
>   

Re: [PATCH] drm/amd/pp: fix semicolon.cocci warnings

[Alex Deucher]

On Tue, Jul 10, 2018 at 1:11 PM, kbuild test robot
 wrote:
> From: kbuild test robot 
>
> drivers/gpu/drm/amd/amdgpu/../powerplay/amd_powerplay.c:1209:17-18: Unneeded 
> semicolon
>
>
>  Remove unneeded semicolon.
>
> Generated by: scripts/coccinelle/misc/semicolon.cocci
>
> Fixes: ea870e44415a ("drm/amd/pp: Export notify_smu_enable_pwe to display")
> CC: Rex Zhu 
> Signed-off-by: kbuild test robot 

Applied.  thanks!

Alex

> ---
>
>  amd_powerplay.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> --- a/drivers/gpu/drm/amd/amdgpu/../powerplay/amd_powerplay.c
> +++ b/drivers/gpu/drm/amd/amdgpu/../powerplay/amd_powerplay.c
> @@ -1206,7 +1206,7 @@ static int pp_notify_smu_enable_pwe(void
> struct pp_hwmgr *hwmgr = handle;
>
> if (!hwmgr || !hwmgr->pm_en)
> -   return -EINVAL;;
> +   return -EINVAL;
>
> if (hwmgr->hwmgr_func->smus_notify_pwe == NULL) {
> pr_info("%s was not implemented.\n", __func__);
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[PATCH] Revert "drm/amd/display: Don't return ddc result and read_bytes in same return value"

[Alex Deucher]

This reverts commit 018d82e5f02ef3583411bcaa4e00c69786f46f19.

This breaks DDC in certain cases.  Revert for 4.18 and previous kernels.
For 4.19, this is fixed with the following more extensive patches:
drm/amd/display: Serialize is_dp_sink_present
drm/amd/display: Break out function to simply read aux reply
drm/amd/display: Return aux replies directly to DRM
drm/amd/display: Right shift AUX reply value sooner than later
drm/amd/display: Read AUX channel even if only status byte is returned

Link: https://lists.freedesktop.org/archives/amd-gfx/2018-July/023788.html
Signed-off-by: Alex Deucher 
Cc: sta...@vger.kernel.org
---
 .../drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c  | 20 
 drivers/gpu/drm/amd/display/dc/core/dc_link_ddc.c| 10 +++---
 drivers/gpu/drm/amd/display/dc/inc/dc_link_ddc.h |  5 ++---
 3 files changed, 13 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
index 4304d9e408b8..ace9ad578ca0 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
@@ -83,22 +83,21 @@ static ssize_t dm_dp_aux_transfer(struct drm_dp_aux *aux,
enum i2c_mot_mode mot = (msg->request & DP_AUX_I2C_MOT) ?
I2C_MOT_TRUE : I2C_MOT_FALSE;
enum ddc_result res;
-   uint32_t read_bytes = msg->size;
+   ssize_t read_bytes;
 
if (WARN_ON(msg->size > 16))
return -E2BIG;
 
switch (msg->request & ~DP_AUX_I2C_MOT) {
case DP_AUX_NATIVE_READ:
-   res = dal_ddc_service_read_dpcd_data(
+   read_bytes = dal_ddc_service_read_dpcd_data(
TO_DM_AUX(aux)->ddc_service,
false,
I2C_MOT_UNDEF,
msg->address,
msg->buffer,
-   msg->size,
-   _bytes);
-   break;
+   msg->size);
+   return read_bytes;
case DP_AUX_NATIVE_WRITE:
res = dal_ddc_service_write_dpcd_data(
TO_DM_AUX(aux)->ddc_service,
@@ -109,15 +108,14 @@ static ssize_t dm_dp_aux_transfer(struct drm_dp_aux *aux,
msg->size);
break;
case DP_AUX_I2C_READ:
-   res = dal_ddc_service_read_dpcd_data(
+   read_bytes = dal_ddc_service_read_dpcd_data(
TO_DM_AUX(aux)->ddc_service,
true,
mot,
msg->address,
msg->buffer,
-   msg->size,
-   _bytes);
-   break;
+   msg->size);
+   return read_bytes;
case DP_AUX_I2C_WRITE:
res = dal_ddc_service_write_dpcd_data(
TO_DM_AUX(aux)->ddc_service,
@@ -139,9 +137,7 @@ static ssize_t dm_dp_aux_transfer(struct drm_dp_aux *aux,
 r == DDC_RESULT_SUCESSFULL);
 #endif
 
-   if (res != DDC_RESULT_SUCESSFULL)
-   return -EIO;
-   return read_bytes;
+   return msg->size;
 }
 
 static enum drm_connector_status
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link_ddc.c 
b/drivers/gpu/drm/amd/display/dc/core/dc_link_ddc.c
index ae48d603ebd6..49c2face1e7a 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_link_ddc.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_link_ddc.c
@@ -629,14 +629,13 @@ bool dal_ddc_service_query_ddc_data(
return ret;
 }
 
-enum ddc_result dal_ddc_service_read_dpcd_data(
+ssize_t dal_ddc_service_read_dpcd_data(
struct ddc_service *ddc,
bool i2c,
enum i2c_mot_mode mot,
uint32_t address,
uint8_t *data,
-   uint32_t len,
-   uint32_t *read)
+   uint32_t len)
 {
struct aux_payload read_payload = {
.i2c_over_aux = i2c,
@@ -653,8 +652,6 @@ enum ddc_result dal_ddc_service_read_dpcd_data(
.mot = mot
};
 
-   *read = 0;
-
if (len > DEFAULT_AUX_MAX_DATA_SIZE) {
BREAK_TO_DEBUGGER();
return DDC_RESULT_FAILED_INVALID_OPERATION;
@@ -664,8 +661,7 @@ enum ddc_result dal_ddc_service_read_dpcd_data(
ddc->ctx->i2caux,
ddc->ddc_pin,
)) {
-   *read = command.payloads->length;
-   return DDC_RESULT_SUCESSFULL;
+   return (ssize_t)command.payloads->length;
}
 
return DDC_RESULT_FAILED_OPERATION;
diff --git a/drivers/gpu/drm/amd/display/dc/inc/dc_link_ddc.h 
b/drivers/gpu/drm/amd/display/dc/inc/dc_link_ddc.h
index 30b3a08b91be..090b7a8dd67b 

Re: [PATCH 10/10] drm/amd/powerplay: no need to mask workable gfxoff feature for vega12

[Alex Deucher]

On Mon, Jul 9, 2018 at 12:36 AM, Quan, Evan  wrote:
> Ping..
>
>> -Original Message-
>> From: Evan Quan [mailto:evan.q...@amd.com]
>> Sent: Thursday, July 05, 2018 5:10 PM
>> To: amd-gfx@lists.freedesktop.org
>> Cc: Quan, Evan 
>> Subject: [PATCH 10/10] drm/amd/powerplay: no need to mask workable
>> gfxoff feature for vega12
>>
>> Gfxoff feature for vega12 is workable. So, there is no need to mask it any
>> more.
>>
>> Change-Id: I7e4d05c5c0acc2aa2b077eaaaf6f13589c87114b
>> Signed-off-by: Evan Quan 

Acked-by: Alex Deucher 

>> ---
>>  drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c
>> b/drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c
>> index 9b675d9bd162..8994aa5c8cf8 100644
>> --- a/drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c
>> +++ b/drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c
>> @@ -147,10 +147,10 @@ int hwmgr_early_init(struct pp_hwmgr *hwmgr)
>>   smu7_init_function_pointers(hwmgr);
>>   break;
>>   case AMDGPU_FAMILY_AI:
>> - hwmgr->feature_mask &= ~PP_GFXOFF_MASK;
>>   switch (hwmgr->chip_id) {
>>   case CHIP_VEGA10:
>>   case CHIP_VEGA20:
>> + hwmgr->feature_mask &= ~PP_GFXOFF_MASK;
>>   hwmgr->smumgr_funcs = _smu_funcs;
>>   vega10_hwmgr_init(hwmgr);
>>   break;
>> --
>> 2.18.0
>
> ___
> 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 08/10] drm/amdgpu: use the accessible target rlc safe mode Apis directly

[Alex Deucher]

On Mon, Jul 9, 2018 at 12:08 AM, Quan, Evan  wrote:
> Ping..
>
>> -Original Message-
>> From: Evan Quan [mailto:evan.q...@amd.com]
>> Sent: Thursday, July 05, 2018 5:10 PM
>> To: amd-gfx@lists.freedesktop.org
>> Cc: Quan, Evan 
>> Subject: [PATCH 08/10] drm/amdgpu: use the accessible target rlc safe mode
>> Apis directly
>>
>> No need to do double dereference to reach the Apis. They are accessible
>> directly.
>>

One advantage of using the callback is that you may end up having
different callbacks for different asics within the gfx9 family.  I
don't know if this will be the case or not.  IIRC, there were
differences between chips on older gfx versions.

Alex

>> Change-Id: I4b810c5e1981e0810df36a701b20edaf1f6af207
>> Signed-off-by: Evan Quan 
>> ---
>>  drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 8 
>>  1 file changed, 4 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
>> b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
>> index cb7f2efa9882..9679bdc0ea2e 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
>> @@ -3618,7 +3618,7 @@ static void
>> gfx_v9_0_update_3d_clock_gating(struct amdgpu_device *adev,  {
>>   uint32_t data, def;
>>
>> - adev->gfx.rlc.funcs->enter_safe_mode(adev);
>> + gfx_v9_0_enter_rlc_safe_mode(adev);
>>
>>   /* Enable 3D CGCG/CGLS */
>>   if (enable && (adev->cg_flags &
>> AMD_CG_SUPPORT_GFX_3D_CGCG)) { @@ -3658,7 +3658,7 @@ static void
>> gfx_v9_0_update_3d_clock_gating(struct amdgpu_device *adev,
>>   WREG32_SOC15(GC, 0,
>> mmRLC_CGCG_CGLS_CTRL_3D, data);
>>   }
>>
>> - adev->gfx.rlc.funcs->exit_safe_mode(adev);
>> + gfx_v9_0_exit_rlc_safe_mode(adev);
>>  }
>>
>>  static void gfx_v9_0_update_coarse_grain_clock_gating(struct
>> amdgpu_device *adev, @@ -3666,7 +3666,7 @@ static void
>> gfx_v9_0_update_coarse_grain_clock_gating(struct amdgpu_device *adev  {
>>   uint32_t def, data;
>>
>> - adev->gfx.rlc.funcs->enter_safe_mode(adev);
>> + gfx_v9_0_enter_rlc_safe_mode(adev);
>>
>>   if (enable && (adev->cg_flags & AMD_CG_SUPPORT_GFX_CGCG)) {
>>   def = data = RREG32_SOC15(GC, 0,
>> mmRLC_CGTT_MGCG_OVERRIDE); @@ -3706,7 +3706,7 @@ static void
>> gfx_v9_0_update_coarse_grain_clock_gating(struct amdgpu_device *adev
>>   WREG32_SOC15(GC, 0, mmRLC_CGCG_CGLS_CTRL,
>> data);
>>   }
>>
>> - adev->gfx.rlc.funcs->exit_safe_mode(adev);
>> + gfx_v9_0_exit_rlc_safe_mode(adev);
>>  }
>>
>>  static int gfx_v9_0_update_gfx_clock_gating(struct amdgpu_device *adev,
>> --
>> 2.18.0
>
> ___
> 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 07/10] drm/amdgpu: reduce the idle period that RLC has to wait before request CGCG

[Alex Deucher]

On Mon, Jul 9, 2018 at 12:06 AM, Quan, Evan  wrote:
> Ping..
>
>> -Original Message-
>> From: Evan Quan [mailto:evan.q...@amd.com]
>> Sent: Thursday, July 05, 2018 5:10 PM
>> To: amd-gfx@lists.freedesktop.org
>> Cc: Quan, Evan 
>> Subject: [PATCH 07/10] drm/amdgpu: reduce the idle period that RLC has to
>> wait before request CGCG
>>
>> Gfxoff feature may depends on the CGCG(on vega12, that's the case). This
>> change will help to enable gfxoff feature more frequently.


I assume this is ok for RV gfxoff as well?  if so:
Acked-by: Alex Deucher 



>>
>> Change-Id: I021577e331b7beb19796bd6f5465b867f6038974
>> Signed-off-by: Evan Quan 
>> ---
>>  drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 11 +++
>>  1 file changed, 7 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
>> b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
>> index ee537423af11..cb7f2efa9882 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
>> @@ -3629,9 +3629,11 @@ static void
>> gfx_v9_0_update_3d_clock_gating(struct amdgpu_device *adev,
>>   /* update CGCG and CGLS override bits */
>>   if (def != data)
>>   WREG32_SOC15(GC, 0,
>> mmRLC_CGTT_MGCG_OVERRIDE, data);
>> - /* enable 3Dcgcg FSM(0x0020003f) */
>> +
>> + /* enable 3Dcgcg FSM(0x363f) */
>>   def = RREG32_SOC15(GC, 0, mmRLC_CGCG_CGLS_CTRL_3D);
>> - data = (0x2000 <<
>> RLC_CGCG_CGLS_CTRL_3D__CGCG_GFX_IDLE_THRESHOLD__SHIFT) |
>> +
>> + data = (0x36 <<
>> +RLC_CGCG_CGLS_CTRL_3D__CGCG_GFX_IDLE_THRESHOLD__SHIFT) |
>>   RLC_CGCG_CGLS_CTRL_3D__CGCG_EN_MASK;
>>   if (adev->cg_flags & AMD_CG_SUPPORT_GFX_3D_CGLS)
>>   data |= (0x000F <<
>> RLC_CGCG_CGLS_CTRL_3D__CGLS_REP_COMPANSAT_DELAY__SHIFT) |
>> @@ -3678,9 +3680,10 @@ static void
>> gfx_v9_0_update_coarse_grain_clock_gating(struct amdgpu_device *adev
>>   if (def != data)
>>   WREG32_SOC15(GC, 0,
>> mmRLC_CGTT_MGCG_OVERRIDE, data);
>>
>> - /* enable cgcg FSM(0x0020003F) */
>> + /* enable cgcg FSM(0x363F) */
>>   def = RREG32_SOC15(GC, 0, mmRLC_CGCG_CGLS_CTRL);
>> - data = (0x2000 <<
>> RLC_CGCG_CGLS_CTRL__CGCG_GFX_IDLE_THRESHOLD__SHIFT) |
>> +
>> + data = (0x36 <<
>> RLC_CGCG_CGLS_CTRL__CGCG_GFX_IDLE_THRESHOLD__SHIFT) |
>>   RLC_CGCG_CGLS_CTRL__CGCG_EN_MASK;
>>   if (adev->cg_flags & AMD_CG_SUPPORT_GFX_CGLS)
>>   data |= (0x000F <<
>> RLC_CGCG_CGLS_CTRL__CGLS_REP_COMPANSAT_DELAY__SHIFT) |
>> --
>> 2.18.0
>
> ___
> 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 06/10] drm/amdgpu: no touch for the reserved bit of RLC_CGTT_MGCG_OVERRIDE

[Alex Deucher]

On Mon, Jul 9, 2018 at 12:06 AM, Quan, Evan  wrote:
> Ping..
>
>> -Original Message-
>> From: Evan Quan [mailto:evan.q...@amd.com]
>> Sent: Thursday, July 05, 2018 5:10 PM
>> To: amd-gfx@lists.freedesktop.org
>> Cc: Quan, Evan 
>> Subject: [PATCH 06/10] drm/amdgpu: no touch for the reserved bit of
>> RLC_CGTT_MGCG_OVERRIDE
>>
>> On vega12, the bit0 of RLC_CGTT_MGCG_OVERRIDE is reserved.
>>
>> Change-Id: I9042a8c89db16f220da5a589264937b51870c187
>> Signed-off-by: Evan Quan 

Acked-by: Alex Deucher 

>> ---
>>  drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 15 +++
>>  1 file changed, 11 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
>> b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
>> index 3a75641a071d..ee537423af11 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
>> @@ -3551,8 +3551,11 @@ static void
>> gfx_v9_0_update_medium_grain_clock_gating(struct amdgpu_device *adev
>>   if (enable && (adev->cg_flags & AMD_CG_SUPPORT_GFX_MGCG)) {
>>   /* 1 - RLC_CGTT_MGCG_OVERRIDE */
>>   def = data = RREG32_SOC15(GC, 0,
>> mmRLC_CGTT_MGCG_OVERRIDE);
>> - data &=
>> ~(RLC_CGTT_MGCG_OVERRIDE__CPF_CGTT_SCLK_OVERRIDE_MASK |
>> -
>> RLC_CGTT_MGCG_OVERRIDE__GRBM_CGTT_SCLK_OVERRIDE_MASK |
>> +
>> + if (adev->asic_type != CHIP_VEGA12)
>> + data &=
>> ~RLC_CGTT_MGCG_OVERRIDE__CPF_CGTT_SCLK_OVERRIDE_MASK;
>> +
>> + data &=
>> ~(RLC_CGTT_MGCG_OVERRIDE__GRBM_CGTT_SCLK_OVERRIDE_MASK |
>>
>> RLC_CGTT_MGCG_OVERRIDE__GFXIP_MGCG_OVERRIDE_MASK |
>>
>> RLC_CGTT_MGCG_OVERRIDE__GFXIP_MGLS_OVERRIDE_MASK);
>>
>> @@ -3582,11 +3585,15 @@ static void
>> gfx_v9_0_update_medium_grain_clock_gating(struct amdgpu_device *adev
>>   } else {
>>   /* 1 - MGCG_OVERRIDE */
>>   def = data = RREG32_SOC15(GC, 0,
>> mmRLC_CGTT_MGCG_OVERRIDE);
>> - data |=
>> (RLC_CGTT_MGCG_OVERRIDE__CPF_CGTT_SCLK_OVERRIDE_MASK |
>> -
>> RLC_CGTT_MGCG_OVERRIDE__RLC_CGTT_SCLK_OVERRIDE_MASK |
>> +
>> + if (adev->asic_type != CHIP_VEGA12)
>> + data |=
>> RLC_CGTT_MGCG_OVERRIDE__CPF_CGTT_SCLK_OVERRIDE_MASK;
>> +
>> + data |=
>> (RLC_CGTT_MGCG_OVERRIDE__RLC_CGTT_SCLK_OVERRIDE_MASK |
>>
>> RLC_CGTT_MGCG_OVERRIDE__GRBM_CGTT_SCLK_OVERRIDE_MASK |
>>
>> RLC_CGTT_MGCG_OVERRIDE__GFXIP_MGCG_OVERRIDE_MASK |
>>
>> RLC_CGTT_MGCG_OVERRIDE__GFXIP_MGLS_OVERRIDE_MASK);
>> +
>>   if (def != data)
>>   WREG32_SOC15(GC, 0,
>> mmRLC_CGTT_MGCG_OVERRIDE, data);
>>
>> --
>> 2.18.0
>
> ___
> 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 02/10] drm/amdgpu: init CSIB regardless of rlc version and pg status

[Alex Deucher]

On Sun, Jul 8, 2018 at 11:56 PM, Quan, Evan  wrote:
> Ping..
>
>> -Original Message-
>> From: Evan Quan [mailto:evan.q...@amd.com]
>> Sent: Thursday, July 05, 2018 5:09 PM
>> To: amd-gfx@lists.freedesktop.org
>> Cc: Quan, Evan 
>> Subject: [PATCH 02/10] drm/amdgpu: init CSIB regardless of rlc version and
>> pg status
>>
>> CSIB init has no relation with rlc version and pg status. It should be needed
>> regardless of them.
>>
>> Change-Id: Iccd12e1015f41c7e2bc3fe02472dc979015514d4
>> Signed-off-by: Evan Quan 

Acked-by: Alex Deucher 

>> ---
>>  drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 3 ++-
>>  1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
>> b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
>> index 65cc30766658..2f6ac255203f 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
>> @@ -2182,6 +2182,8 @@ static void
>> gfx_v9_0_enable_gfx_dynamic_mg_power_gating(struct amdgpu_device
>> *ad
>>
>>  static void gfx_v9_0_init_pg(struct amdgpu_device *adev)  {
>> + gfx_v9_0_init_csb(adev);
>> +
>>   if (!adev->gfx.rlc.is_rlc_v2_1)
>>   return;
>>
>> @@ -2191,7 +2193,6 @@ static void gfx_v9_0_init_pg(struct amdgpu_device
>> *adev)
>> AMD_PG_SUPPORT_CP |
>> AMD_PG_SUPPORT_GDS |
>> AMD_PG_SUPPORT_RLC_SMU_HS)) {
>> - gfx_v9_0_init_csb(adev);
>>   gfx_v9_1_init_rlc_save_restore_list(adev);
>>   gfx_v9_0_enable_save_restore_machine(adev);
>>
>> --
>> 2.18.0
>
> ___
> 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 xf86-video-amdgpu 3/3] Move flush from radeon_scanout_do_update to its callers

[Alex Deucher]

On Tue, Jul 10, 2018 at 12:34 PM, Michel Dänzer  wrote:
> From: Michel Dänzer 
>
> No functional change intended.
>
> Reviewed-by: Alex Deucher 
> (Ported from radeon commit 90b94d40449f665f2d12874598062a5e5e5b64cd)

Series is:
Reviewed-by: Alex Deucher 

>
> Signed-off-by: Michel Dänzer 
> ---
>  src/amdgpu_kms.c  | 8 +---
>  src/drmmode_display.c | 1 +
>  2 files changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/src/amdgpu_kms.c b/src/amdgpu_kms.c
> index c357ab6b7..39e047e29 100644
> --- a/src/amdgpu_kms.c
> +++ b/src/amdgpu_kms.c
> @@ -882,8 +882,6 @@ amdgpu_scanout_do_update(xf86CrtcPtr xf86_crtc, int 
> scanout_id,
> FreeScratchGC(gc);
> }
>
> -   amdgpu_glamor_flush(xf86_crtc->scrn);
> -
> return TRUE;
>  }
>
> @@ -908,8 +906,10 @@ amdgpu_scanout_update_handler(xf86CrtcPtr crtc, uint32_t 
> frame, uint64_t usec,
> drmmode_crtc->dpms_mode == DPMSModeOn) {
> if (amdgpu_scanout_do_update(crtc, drmmode_crtc->scanout_id,
>  
> screen->GetWindowPixmap(screen->root),
> -region->extents))
> +region->extents)) {
> +   amdgpu_glamor_flush(crtc->scrn);
> RegionEmpty(region);
> +   }
> }
>
> amdgpu_scanout_update_abort(crtc, event_data);
> @@ -991,6 +991,8 @@ amdgpu_scanout_flip(ScreenPtr pScreen, AMDGPUInfoPtr info,
>   pScreen->GetWindowPixmap(pScreen->root),
>   region->extents))
> return;
> +
> +   amdgpu_glamor_flush(scrn);
> RegionEmpty(region);
>
> drm_queue_seq = amdgpu_drm_queue_alloc(xf86_crtc,
> diff --git a/src/drmmode_display.c b/src/drmmode_display.c
> index fee6fedfb..f6cafccdc 100644
> --- a/src/drmmode_display.c
> +++ b/src/drmmode_display.c
> @@ -3978,6 +3978,7 @@ Bool amdgpu_do_pageflip(ScrnInfoPtr scrn, ClientPtr 
> client,
>
> amdgpu_scanout_do_update(crtc, scanout_id, new_front,
>  extents);
> +   amdgpu_glamor_flush(crtc->scrn);
>
> if (drmmode_crtc->scanout_update_pending) {
> drmmode_crtc_wait_pending_event(drmmode_crtc, 
> pAMDGPUEnt->fd,
> --
> 2.18.0
>
> ___
> 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 xf86-video-ati] Swap pixmap privates in radeon_dri2_exchange_buffers

[Alex Deucher]

On Tue, Jul 10, 2018 at 11:24 AM, Michel Dänzer  wrote:
> From: Michel Dänzer 
>
> Instead of only the BOs.
>
> This matches what amdgpu does, and fixes issues with DRI2 page flipping.
>
> Signed-off-by: Michel Dänzer 

Reviewed-by: Alex Deucher 

> ---
>  src/radeon_dri2.c | 42 +++---
>  1 file changed, 23 insertions(+), 19 deletions(-)
>
> diff --git a/src/radeon_dri2.c b/src/radeon_dri2.c
> index ab3db6c5e..70ad1d92a 100644
> --- a/src/radeon_dri2.c
> +++ b/src/radeon_dri2.c
> @@ -720,9 +720,8 @@ radeon_dri2_exchange_buffers(DrawablePtr draw, 
> DRI2BufferPtr front, DRI2BufferPt
>  {
>  struct dri2_buffer_priv *front_priv = front->driverPrivate;
>  struct dri2_buffer_priv *back_priv = back->driverPrivate;
> -struct radeon_buffer *front_buffer, *back_buffer;
> -ScreenPtr screen;
> -RADEONInfoPtr info;
> +ScreenPtr screen = draw->pScreen;
> +RADEONInfoPtr info = RADEONPTR(xf86ScreenToScrn(screen));
>  RegionRec region;
>  int tmp;
>
> @@ -737,23 +736,28 @@ radeon_dri2_exchange_buffers(DrawablePtr draw, 
> DRI2BufferPtr front, DRI2BufferPt
>  front->name = back->name;
>  back->name = tmp;
>
> -/* Swap pixmap bos */
> -front_buffer = radeon_get_pixmap_bo(front_priv->pixmap);
> -back_buffer = radeon_get_pixmap_bo(back_priv->pixmap);
> -radeon_set_pixmap_bo(front_priv->pixmap, back_buffer);
> -radeon_set_pixmap_bo(back_priv->pixmap, front_buffer);
> -
> -/* Do we need to update the Screen? */
> -screen = draw->pScreen;
> -info = RADEONPTR(xf86ScreenToScrn(screen));
> -if (front_buffer == info->front_buffer) {
> -   radeon_buffer_ref(back_buffer);
> -   radeon_buffer_unref(>front_buffer);
> -   info->front_buffer = back_buffer;
> -   radeon_set_pixmap_bo(screen->GetScreenPixmap(screen), back_buffer);
> -}
> +/* Swap pixmap privates */
> +#ifdef USE_GLAMOR
> +if (info->use_glamor) {
> +   struct radeon_pixmap *front_pix, *back_pix;
> +
> +   front_pix = radeon_get_pixmap_private(front_priv->pixmap);
> +   back_pix = radeon_get_pixmap_private(back_priv->pixmap);
> +   radeon_set_pixmap_private(front_priv->pixmap, back_pix);
> +   radeon_set_pixmap_private(back_priv->pixmap, front_pix);
>
> -radeon_glamor_exchange_buffers(front_priv->pixmap, back_priv->pixmap);
> +   radeon_glamor_exchange_buffers(front_priv->pixmap, back_priv->pixmap);
> +} else
> +#endif
> +{
> +   struct radeon_exa_pixmap_priv driver_priv = *(struct 
> radeon_exa_pixmap_priv*)
> +   exaGetPixmapDriverPrivate(front_priv->pixmap);
> +
> +   *(struct 
> radeon_exa_pixmap_priv*)exaGetPixmapDriverPrivate(front_priv->pixmap) =
> +   *(struct 
> radeon_exa_pixmap_priv*)exaGetPixmapDriverPrivate(back_priv->pixmap);
> +   *(struct 
> radeon_exa_pixmap_priv*)exaGetPixmapDriverPrivate(back_priv->pixmap) =
> +   driver_priv;
> +}
>
>  DamageRegionProcessPending(_priv->pixmap->drawable);
>  }
> --
> 2.18.0
>
> ___
> 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] drm/amd/pp: fix semicolon.cocci warnings

[kbuild test robot]

From: kbuild test robot 

drivers/gpu/drm/amd/amdgpu/../powerplay/amd_powerplay.c:1209:17-18: Unneeded 
semicolon


 Remove unneeded semicolon.

Generated by: scripts/coccinelle/misc/semicolon.cocci

Fixes: ea870e44415a ("drm/amd/pp: Export notify_smu_enable_pwe to display")
CC: Rex Zhu 
Signed-off-by: kbuild test robot 
---

 amd_powerplay.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/gpu/drm/amd/amdgpu/../powerplay/amd_powerplay.c
+++ b/drivers/gpu/drm/amd/amdgpu/../powerplay/amd_powerplay.c
@@ -1206,7 +1206,7 @@ static int pp_notify_smu_enable_pwe(void
struct pp_hwmgr *hwmgr = handle;
 
if (!hwmgr || !hwmgr->pm_en)
-   return -EINVAL;;
+   return -EINVAL;
 
if (hwmgr->hwmgr_func->smus_notify_pwe == NULL) {
pr_info("%s was not implemented.\n", __func__);
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[PATCH xf86-video-amdgpu 1/3] Bail from dri2_create_buffer2 if we can't get a pixmap

[Michel Dänzer]

From: Michel Dänzer 

We would store the NULL pointer and continue, which would lead to a
crash down the road.

Bugzilla: https://bugs.freedesktop.org/106293
(Ported from radeon commit 3dcfce8d0f495d09d7836caf98ef30d625b78a13)

Signed-off-by: Michel Dänzer 
---
 src/amdgpu_dri2.c | 26 --
 1 file changed, 12 insertions(+), 14 deletions(-)

diff --git a/src/amdgpu_dri2.c b/src/amdgpu_dri2.c
index a9e2819ae..a9238e536 100644
--- a/src/amdgpu_dri2.c
+++ b/src/amdgpu_dri2.c
@@ -161,29 +161,28 @@ amdgpu_dri2_create_buffer2(ScreenPtr pScreen,
   AMDGPU_CREATE_PIXMAP_DRI2);
}
 
+   if (!pixmap)
+   return NULL;
+
buffers = calloc(1, sizeof *buffers);
if (!buffers)
goto error;
 
-   if (pixmap) {
-   if (is_glamor_pixmap) {
-   pixmap = amdgpu_glamor_set_pixmap_bo(drawable, pixmap);
-   pixmap->refcnt++;
-   }
-
-   if (!amdgpu_get_flink_name(pAMDGPUEnt, pixmap, >name))
-   goto error;
+   if (is_glamor_pixmap) {
+   pixmap = amdgpu_glamor_set_pixmap_bo(drawable, pixmap);
+   pixmap->refcnt++;
}
 
+   if (!amdgpu_get_flink_name(pAMDGPUEnt, pixmap, >name))
+   goto error;
+
privates = calloc(1, sizeof(struct dri2_buffer_priv));
if (!privates)
goto error;
 
buffers->attachment = attachment;
-   if (pixmap) {
-   buffers->pitch = pixmap->devKind;
-   buffers->cpp = cpp;
-   }
+   buffers->pitch = pixmap->devKind;
+   buffers->cpp = cpp;
buffers->driverPrivate = privates;
buffers->format = format;
buffers->flags = 0; /* not tiled */
@@ -195,8 +194,7 @@ amdgpu_dri2_create_buffer2(ScreenPtr pScreen,
 
 error:
free(buffers);
-   if (pixmap)
-   (*pScreen->DestroyPixmap) (pixmap);
+   (*pScreen->DestroyPixmap) (pixmap);
return NULL;
 }
 
-- 
2.18.0

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

[PATCH xf86-video-amdgpu 2/3] glamor: Bail CreatePixmap on unsupported pixmap depth

[Michel Dänzer]

From: Michel Dänzer 

Fixes crash in that case.

Bugzilla: https://bugs.freedesktop.org/106293
(Ported from radeon commit 65c9dfea4e841b7d6f795c7489fede58c5e9631f)

Signed-off-by: Michel Dänzer 
---
 src/amdgpu_glamor.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/src/amdgpu_glamor.c b/src/amdgpu_glamor.c
index 44cdbcff7..8b839105e 100644
--- a/src/amdgpu_glamor.c
+++ b/src/amdgpu_glamor.c
@@ -185,6 +185,9 @@ amdgpu_glamor_create_pixmap(ScreenPtr screen, int w, int h, 
int depth,
struct amdgpu_pixmap *priv;
PixmapPtr pixmap, new_pixmap = NULL;
 
+   if (!xf86GetPixFormat(scrn, depth))
+   return NULL;
+
if (!AMDGPU_CREATE_PIXMAP_SHARED(usage)) {
if (info->shadow_primary) {
if (usage != CREATE_PIXMAP_USAGE_BACKING_PIXMAP)
-- 
2.18.0

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

[PATCH xf86-video-amdgpu 3/3] Move flush from radeon_scanout_do_update to its callers

[Michel Dänzer]

From: Michel Dänzer 

No functional change intended.

Reviewed-by: Alex Deucher 
(Ported from radeon commit 90b94d40449f665f2d12874598062a5e5e5b64cd)

Signed-off-by: Michel Dänzer 
---
 src/amdgpu_kms.c  | 8 +---
 src/drmmode_display.c | 1 +
 2 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/src/amdgpu_kms.c b/src/amdgpu_kms.c
index c357ab6b7..39e047e29 100644
--- a/src/amdgpu_kms.c
+++ b/src/amdgpu_kms.c
@@ -882,8 +882,6 @@ amdgpu_scanout_do_update(xf86CrtcPtr xf86_crtc, int 
scanout_id,
FreeScratchGC(gc);
}
 
-   amdgpu_glamor_flush(xf86_crtc->scrn);
-
return TRUE;
 }
 
@@ -908,8 +906,10 @@ amdgpu_scanout_update_handler(xf86CrtcPtr crtc, uint32_t 
frame, uint64_t usec,
drmmode_crtc->dpms_mode == DPMSModeOn) {
if (amdgpu_scanout_do_update(crtc, drmmode_crtc->scanout_id,
 
screen->GetWindowPixmap(screen->root),
-region->extents))
+region->extents)) {
+   amdgpu_glamor_flush(crtc->scrn);
RegionEmpty(region);
+   }
}
 
amdgpu_scanout_update_abort(crtc, event_data);
@@ -991,6 +991,8 @@ amdgpu_scanout_flip(ScreenPtr pScreen, AMDGPUInfoPtr info,
  pScreen->GetWindowPixmap(pScreen->root),
  region->extents))
return;
+
+   amdgpu_glamor_flush(scrn);
RegionEmpty(region);
 
drm_queue_seq = amdgpu_drm_queue_alloc(xf86_crtc,
diff --git a/src/drmmode_display.c b/src/drmmode_display.c
index fee6fedfb..f6cafccdc 100644
--- a/src/drmmode_display.c
+++ b/src/drmmode_display.c
@@ -3978,6 +3978,7 @@ Bool amdgpu_do_pageflip(ScrnInfoPtr scrn, ClientPtr 
client,
 
amdgpu_scanout_do_update(crtc, scanout_id, new_front,
 extents);
+   amdgpu_glamor_flush(crtc->scrn);
 
if (drmmode_crtc->scanout_update_pending) {
drmmode_crtc_wait_pending_event(drmmode_crtc, 
pAMDGPUEnt->fd,
-- 
2.18.0

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

Re: [RFC PATCH] mm, oom: distinguish blockable mode for mmu notifiers

[Leon Romanovsky]

On Tue, Jul 10, 2018 at 04:14:10PM +0200, Michal Hocko wrote:
> On Tue 10-07-18 16:40:40, Leon Romanovsky wrote:
> > On Mon, Jul 09, 2018 at 02:29:08PM +0200, Michal Hocko wrote:
> > > On Wed 27-06-18 09:44:21, Michal Hocko wrote:
> > > > This is the v2 of RFC based on the feedback I've received so far. The
> > > > code even compiles as a bonus ;) I haven't runtime tested it yet, mostly
> > > > because I have no idea how.
> > > >
> > > > Any further feedback is highly appreciated of course.
> > >
> > > Any other feedback before I post this as non-RFC?
> >
> > From mlx5 perspective, who is primary user of umem_odp.c your change looks 
> > ok.
>
> Can I assume your Acked-by?

I didn't have a chance to test it because it applies on our rdma-next, but
fails to compile.

Thanks

>
> Thanks for your review!
> --
> Michal Hocko
> SUSE Labs
>


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

[PATCH xf86-video-ati] Swap pixmap privates in radeon_dri2_exchange_buffers

[Michel Dänzer]

From: Michel Dänzer 

Instead of only the BOs.

This matches what amdgpu does, and fixes issues with DRI2 page flipping.

Signed-off-by: Michel Dänzer 
---
 src/radeon_dri2.c | 42 +++---
 1 file changed, 23 insertions(+), 19 deletions(-)

diff --git a/src/radeon_dri2.c b/src/radeon_dri2.c
index ab3db6c5e..70ad1d92a 100644
--- a/src/radeon_dri2.c
+++ b/src/radeon_dri2.c
@@ -720,9 +720,8 @@ radeon_dri2_exchange_buffers(DrawablePtr draw, 
DRI2BufferPtr front, DRI2BufferPt
 {
 struct dri2_buffer_priv *front_priv = front->driverPrivate;
 struct dri2_buffer_priv *back_priv = back->driverPrivate;
-struct radeon_buffer *front_buffer, *back_buffer;
-ScreenPtr screen;
-RADEONInfoPtr info;
+ScreenPtr screen = draw->pScreen;
+RADEONInfoPtr info = RADEONPTR(xf86ScreenToScrn(screen));
 RegionRec region;
 int tmp;
 
@@ -737,23 +736,28 @@ radeon_dri2_exchange_buffers(DrawablePtr draw, 
DRI2BufferPtr front, DRI2BufferPt
 front->name = back->name;
 back->name = tmp;
 
-/* Swap pixmap bos */
-front_buffer = radeon_get_pixmap_bo(front_priv->pixmap);
-back_buffer = radeon_get_pixmap_bo(back_priv->pixmap);
-radeon_set_pixmap_bo(front_priv->pixmap, back_buffer);
-radeon_set_pixmap_bo(back_priv->pixmap, front_buffer);
-
-/* Do we need to update the Screen? */
-screen = draw->pScreen;
-info = RADEONPTR(xf86ScreenToScrn(screen));
-if (front_buffer == info->front_buffer) {
-   radeon_buffer_ref(back_buffer);
-   radeon_buffer_unref(>front_buffer);
-   info->front_buffer = back_buffer;
-   radeon_set_pixmap_bo(screen->GetScreenPixmap(screen), back_buffer);
-}
+/* Swap pixmap privates */
+#ifdef USE_GLAMOR
+if (info->use_glamor) {
+   struct radeon_pixmap *front_pix, *back_pix;
+
+   front_pix = radeon_get_pixmap_private(front_priv->pixmap);
+   back_pix = radeon_get_pixmap_private(back_priv->pixmap);
+   radeon_set_pixmap_private(front_priv->pixmap, back_pix);
+   radeon_set_pixmap_private(back_priv->pixmap, front_pix);
 
-radeon_glamor_exchange_buffers(front_priv->pixmap, back_priv->pixmap);
+   radeon_glamor_exchange_buffers(front_priv->pixmap, back_priv->pixmap);
+} else
+#endif
+{
+   struct radeon_exa_pixmap_priv driver_priv = *(struct 
radeon_exa_pixmap_priv*)
+   exaGetPixmapDriverPrivate(front_priv->pixmap);
+
+   *(struct 
radeon_exa_pixmap_priv*)exaGetPixmapDriverPrivate(front_priv->pixmap) =
+   *(struct 
radeon_exa_pixmap_priv*)exaGetPixmapDriverPrivate(back_priv->pixmap);
+   *(struct 
radeon_exa_pixmap_priv*)exaGetPixmapDriverPrivate(back_priv->pixmap) =
+   driver_priv;
+}
 
 DamageRegionProcessPending(_priv->pixmap->drawable);
 }
-- 
2.18.0

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

[PATCH v2] drm/amd/display: dp debugfs allow link rate lane count greater than dp rx reported caps

[Harry Wentland]

From: Hersen Wu 

[Why]
when hw team does phy parameters tuning, there is need to force dp
link rate or lane count grater than the values from dp receiver to
check dp tx. current debufs limit link rate, lane count no more
than rx caps.

[How] remove force settings less than rx caps check

v2: Fix typo in title

Signed-off-by: Hersen Wu 
Reviewed-by: Charlene Liu 
Acked-by: Harry Wentland 
---
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
index 0276e09d0b82..0d9e410ca01e 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
@@ -214,8 +214,7 @@ static ssize_t dp_link_settings_write(struct file *f, const 
char __user *buf,
break;
}
 
-   if (!valid_input || (param[0] > link->reported_link_cap.lane_count) ||
-   (param[1] > link->reported_link_cap.link_rate)) {
+   if (!valid_input) {
kfree(wr_buf);
DRM_DEBUG_DRIVER("Invalid Input value No HW will be 
programmed\n");
return bytes_from_user;
-- 
2.17.1

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

[PATCH v2] drm/amd/display: Expose bunch of functions from dcn10_hw_sequencer

[Harry Wentland]

From: Eric Bernstein 

v2: Remove spurious newline changes

Signed-off-by: Eric Bernstein 
Reviewed-by: Dmytro Laktyushkin 
Acked-by: Harry Wentland 
---
 .../amd/display/dc/dcn10/dcn10_hw_sequencer.c | 59 +++
 .../amd/display/dc/dcn10/dcn10_hw_sequencer.h |  7 +++
 .../gpu/drm/amd/display/dc/inc/hw_sequencer.h |  8 +++
 3 files changed, 49 insertions(+), 25 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c 
b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c
index 28dba6a324c1..06cf967b2431 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c
@@ -849,7 +849,7 @@ static bool dcn10_hw_wa_force_recovery(struct dc *dc)
 }
 
 
-static void dcn10_verify_allow_pstate_change_high(struct dc *dc)
+void dcn10_verify_allow_pstate_change_high(struct dc *dc)
 {
static bool should_log_hw_state; /* prevent hw state log by default */
 
@@ -1863,8 +1863,7 @@ static void update_dpp(struct dpp *dpp, struct 
dc_plane_state *plane_state)
dpp->funcs->dpp_program_bias_and_scale(dpp, _params);
 }
 
-
-static void update_mpcc(struct dc *dc, struct pipe_ctx *pipe_ctx)
+static void dcn10_update_mpcc(struct dc *dc, struct pipe_ctx *pipe_ctx)
 {
struct hubp *hubp = pipe_ctx->plane_res.hubp;
struct mpcc_blnd_cfg blnd_cfg;
@@ -2009,7 +2008,7 @@ static void update_dchubp_dpp(
 
if (plane_state->update_flags.bits.full_update ||
plane_state->update_flags.bits.per_pixel_alpha_change)
-   update_mpcc(dc, pipe_ctx);
+   dc->hwss.update_mpcc(dc, pipe_ctx);
 
if (plane_state->update_flags.bits.full_update ||
plane_state->update_flags.bits.per_pixel_alpha_change ||
@@ -2119,6 +2118,33 @@ static void set_hdr_multiplier(struct pipe_ctx *pipe_ctx)
pipe_ctx->plane_res.dpp, hw_mult);
 }
 
+void dcn10_program_pipe(
+   struct dc *dc,
+   struct pipe_ctx *pipe_ctx,
+   struct dc_state *context)
+{
+   if (pipe_ctx->plane_state->update_flags.bits.full_update)
+   dcn10_enable_plane(dc, pipe_ctx, context);
+
+   update_dchubp_dpp(dc, pipe_ctx, context);
+
+   set_hdr_multiplier(pipe_ctx);
+
+   if (pipe_ctx->plane_state->update_flags.bits.full_update ||
+   
pipe_ctx->plane_state->update_flags.bits.in_transfer_func_change ||
+   pipe_ctx->plane_state->update_flags.bits.gamma_change)
+   dc->hwss.set_input_transfer_func(pipe_ctx, 
pipe_ctx->plane_state);
+
+   /* dcn10_translate_regamma_to_hw_format takes 750us to finish
+* only do gamma programming for full update.
+* TODO: This can be further optimized/cleaned up
+* Always call this for now since it does memcmp inside before
+* doing heavy calculation and programming
+*/
+   if (pipe_ctx->plane_state->update_flags.bits.full_update)
+   dc->hwss.set_output_transfer_func(pipe_ctx, pipe_ctx->stream);
+}
+
 static void program_all_pipe_in_tree(
struct dc *dc,
struct pipe_ctx *pipe_ctx,
@@ -2140,26 +2166,7 @@ static void program_all_pipe_in_tree(
}
 
if (pipe_ctx->plane_state != NULL) {
-   if (pipe_ctx->plane_state->update_flags.bits.full_update)
-   dcn10_enable_plane(dc, pipe_ctx, context);
-
-   update_dchubp_dpp(dc, pipe_ctx, context);
-
-   set_hdr_multiplier(pipe_ctx);
-
-   if (pipe_ctx->plane_state->update_flags.bits.full_update ||
-   
pipe_ctx->plane_state->update_flags.bits.in_transfer_func_change ||
-   
pipe_ctx->plane_state->update_flags.bits.gamma_change)
-   dc->hwss.set_input_transfer_func(pipe_ctx, 
pipe_ctx->plane_state);
-
-   /* dcn10_translate_regamma_to_hw_format takes 750us to finish
-* only do gamma programming for full update.
-* TODO: This can be further optimized/cleaned up
-* Always call this for now since it does memcmp inside before
-* doing heavy calculation and programming
-*/
-   if (pipe_ctx->plane_state->update_flags.bits.full_update)
-   dc->hwss.set_output_transfer_func(pipe_ctx, 
pipe_ctx->stream);
+   dcn10_program_pipe(dc, pipe_ctx, context);
}
 
if (pipe_ctx->bottom_pipe != NULL && pipe_ctx->bottom_pipe != pipe_ctx) 
{
@@ -2284,7 +2291,7 @@ static void dcn10_apply_ctx_for_surface(
old_pipe_ctx->plane_state &&
old_pipe_ctx->stream_res.tg == tg) {
 
-   hwss1_plane_atomic_disconnect(dc, old_pipe_ctx);
+   dc->hwss.plane_atomic_disconnect(dc, old_pipe_ctx);
removed_pipe[i] = 

[PATCH v2] Revert "drm/amd/display: make dm_dp_aux_transfer return payload bytes instead of size"

[Harry Wentland]

This reverts commit cc195141133ac3e767d930bedd8294ceebf1f10b.

This commit was problematic on other OSes. The real solution is to
leave all the error checking to DRM and don't do it in DC, which is
addressed by "Return aux replies directly to DRM" later in this patchset.

v2: Add reason for revert.

Signed-off-by: Harry Wentland 
---
 .../amd/display/amdgpu_dm/amdgpu_dm_mst_types.c   |  9 -
 drivers/gpu/drm/amd/display/dc/core/dc_link_ddc.c |  7 +++
 .../gpu/drm/amd/display/dc/i2caux/aux_engine.c| 15 +--
 drivers/gpu/drm/amd/display/dc/i2caux/i2caux.c|  1 -
 drivers/gpu/drm/amd/display/dc/inc/dc_link_ddc.h  |  2 +-
 5 files changed, 21 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
index d43a65c6ced8..db669c427dab 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
@@ -83,21 +83,20 @@ static ssize_t dm_dp_aux_transfer(struct drm_dp_aux *aux,
enum i2c_mot_mode mot = (msg->request & DP_AUX_I2C_MOT) ?
I2C_MOT_TRUE : I2C_MOT_FALSE;
enum ddc_result res;
-   ssize_t read_bytes;
 
if (WARN_ON(msg->size > 16))
return -E2BIG;
 
switch (msg->request & ~DP_AUX_I2C_MOT) {
case DP_AUX_NATIVE_READ:
-   read_bytes = dal_ddc_service_read_dpcd_data(
+   res = dal_ddc_service_read_dpcd_data(
TO_DM_AUX(aux)->ddc_service,
false,
I2C_MOT_UNDEF,
msg->address,
msg->buffer,
msg->size);
-   return read_bytes;
+   break;
case DP_AUX_NATIVE_WRITE:
res = dal_ddc_service_write_dpcd_data(
TO_DM_AUX(aux)->ddc_service,
@@ -108,14 +107,14 @@ static ssize_t dm_dp_aux_transfer(struct drm_dp_aux *aux,
msg->size);
break;
case DP_AUX_I2C_READ:
-   read_bytes = dal_ddc_service_read_dpcd_data(
+   res = dal_ddc_service_read_dpcd_data(
TO_DM_AUX(aux)->ddc_service,
true,
mot,
msg->address,
msg->buffer,
msg->size);
-   return read_bytes;
+   break;
case DP_AUX_I2C_WRITE:
res = dal_ddc_service_write_dpcd_data(
TO_DM_AUX(aux)->ddc_service,
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link_ddc.c 
b/drivers/gpu/drm/amd/display/dc/core/dc_link_ddc.c
index 49c2face1e7a..d5294798b0a5 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_link_ddc.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_link_ddc.c
@@ -629,7 +629,7 @@ bool dal_ddc_service_query_ddc_data(
return ret;
 }
 
-ssize_t dal_ddc_service_read_dpcd_data(
+enum ddc_result dal_ddc_service_read_dpcd_data(
struct ddc_service *ddc,
bool i2c,
enum i2c_mot_mode mot,
@@ -660,9 +660,8 @@ ssize_t dal_ddc_service_read_dpcd_data(
if (dal_i2caux_submit_aux_command(
ddc->ctx->i2caux,
ddc->ddc_pin,
-   )) {
-   return (ssize_t)command.payloads->length;
-   }
+   ))
+   return DDC_RESULT_SUCESSFULL;
 
return DDC_RESULT_FAILED_OPERATION;
 }
diff --git a/drivers/gpu/drm/amd/display/dc/i2caux/aux_engine.c 
b/drivers/gpu/drm/amd/display/dc/i2caux/aux_engine.c
index 1d7309611978..0afd2fa57bbe 100644
--- a/drivers/gpu/drm/amd/display/dc/i2caux/aux_engine.c
+++ b/drivers/gpu/drm/amd/display/dc/i2caux/aux_engine.c
@@ -128,8 +128,20 @@ static void process_read_reply(
ctx->status =
I2CAUX_TRANSACTION_STATUS_FAILED_PROTOCOL_ERROR;
ctx->operation_succeeded = false;
+   } else if (ctx->returned_byte < ctx->current_read_length) {
+   ctx->current_read_length -= ctx->returned_byte;
+
+   ctx->offset += ctx->returned_byte;
+
+   ++ctx->invalid_reply_retry_aux_on_ack;
+
+   if (ctx->invalid_reply_retry_aux_on_ack >
+   AUX_INVALID_REPLY_RETRY_COUNTER) {
+   ctx->status =
+   I2CAUX_TRANSACTION_STATUS_FAILED_PROTOCOL_ERROR;
+   ctx->operation_succeeded = false;
+   }
} else {
-   ctx->current_read_length = ctx->returned_byte;
ctx->status = I2CAUX_TRANSACTION_STATUS_SUCCEEDED;
   

[PATCH v2] Revert "drm/amd/display: Don't return ddc result and read_bytes in same return value"

[Harry Wentland]

This reverts commit 8a61bc085ffab3071c59efcbeff4044c034e7490.

Need to revert "make dm_dp_aux_transfer return payload bytes instead of
size", which this commit is based on. That commit was problematic on
other OSes. The real solution is to leave all the error checking to DRM
and don't do it in DC, which is addressed by "Return aux replies
directly to DRM" later in this patchset.

v2: Add reason for revert.

Signed-off-by: Harry Wentland 
---
 .../display/amdgpu_dm/amdgpu_dm_mst_types.c   | 20 ---
 .../gpu/drm/amd/display/dc/core/dc_link_ddc.c | 10 +++---
 .../gpu/drm/amd/display/dc/inc/dc_link_ddc.h  |  5 ++---
 3 files changed, 13 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
index 8f42e5616390..d43a65c6ced8 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
@@ -83,22 +83,21 @@ static ssize_t dm_dp_aux_transfer(struct drm_dp_aux *aux,
enum i2c_mot_mode mot = (msg->request & DP_AUX_I2C_MOT) ?
I2C_MOT_TRUE : I2C_MOT_FALSE;
enum ddc_result res;
-   uint32_t read_bytes = msg->size;
+   ssize_t read_bytes;
 
if (WARN_ON(msg->size > 16))
return -E2BIG;
 
switch (msg->request & ~DP_AUX_I2C_MOT) {
case DP_AUX_NATIVE_READ:
-   res = dal_ddc_service_read_dpcd_data(
+   read_bytes = dal_ddc_service_read_dpcd_data(
TO_DM_AUX(aux)->ddc_service,
false,
I2C_MOT_UNDEF,
msg->address,
msg->buffer,
-   msg->size,
-   _bytes);
-   break;
+   msg->size);
+   return read_bytes;
case DP_AUX_NATIVE_WRITE:
res = dal_ddc_service_write_dpcd_data(
TO_DM_AUX(aux)->ddc_service,
@@ -109,15 +108,14 @@ static ssize_t dm_dp_aux_transfer(struct drm_dp_aux *aux,
msg->size);
break;
case DP_AUX_I2C_READ:
-   res = dal_ddc_service_read_dpcd_data(
+   read_bytes = dal_ddc_service_read_dpcd_data(
TO_DM_AUX(aux)->ddc_service,
true,
mot,
msg->address,
msg->buffer,
-   msg->size,
-   _bytes);
-   break;
+   msg->size);
+   return read_bytes;
case DP_AUX_I2C_WRITE:
res = dal_ddc_service_write_dpcd_data(
TO_DM_AUX(aux)->ddc_service,
@@ -139,9 +137,7 @@ static ssize_t dm_dp_aux_transfer(struct drm_dp_aux *aux,
 r == DDC_RESULT_SUCESSFULL);
 #endif
 
-   if (res != DDC_RESULT_SUCESSFULL)
-   return -EIO;
-   return read_bytes;
+   return msg->size;
 }
 
 static enum drm_connector_status
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link_ddc.c 
b/drivers/gpu/drm/amd/display/dc/core/dc_link_ddc.c
index ae48d603ebd6..49c2face1e7a 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_link_ddc.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_link_ddc.c
@@ -629,14 +629,13 @@ bool dal_ddc_service_query_ddc_data(
return ret;
 }
 
-enum ddc_result dal_ddc_service_read_dpcd_data(
+ssize_t dal_ddc_service_read_dpcd_data(
struct ddc_service *ddc,
bool i2c,
enum i2c_mot_mode mot,
uint32_t address,
uint8_t *data,
-   uint32_t len,
-   uint32_t *read)
+   uint32_t len)
 {
struct aux_payload read_payload = {
.i2c_over_aux = i2c,
@@ -653,8 +652,6 @@ enum ddc_result dal_ddc_service_read_dpcd_data(
.mot = mot
};
 
-   *read = 0;
-
if (len > DEFAULT_AUX_MAX_DATA_SIZE) {
BREAK_TO_DEBUGGER();
return DDC_RESULT_FAILED_INVALID_OPERATION;
@@ -664,8 +661,7 @@ enum ddc_result dal_ddc_service_read_dpcd_data(
ddc->ctx->i2caux,
ddc->ddc_pin,
)) {
-   *read = command.payloads->length;
-   return DDC_RESULT_SUCESSFULL;
+   return (ssize_t)command.payloads->length;
}
 
return DDC_RESULT_FAILED_OPERATION;
diff --git a/drivers/gpu/drm/amd/display/dc/inc/dc_link_ddc.h 
b/drivers/gpu/drm/amd/display/dc/inc/dc_link_ddc.h
index 30b3a08b91be..090b7a8dd67b 100644
--- a/drivers/gpu/drm/amd/display/dc/inc/dc_link_ddc.h
+++ b/drivers/gpu/drm/amd/display/dc/inc/dc_link_ddc.h
@@ -102,14 +102,13 @@ bool dal_ddc_service_query_ddc_data(
uint8_t 

Re: [RFC PATCH] mm, oom: distinguish blockable mode for mmu notifiers

[Michal Hocko]

On Tue 10-07-18 16:40:40, Leon Romanovsky wrote:
> On Mon, Jul 09, 2018 at 02:29:08PM +0200, Michal Hocko wrote:
> > On Wed 27-06-18 09:44:21, Michal Hocko wrote:
> > > This is the v2 of RFC based on the feedback I've received so far. The
> > > code even compiles as a bonus ;) I haven't runtime tested it yet, mostly
> > > because I have no idea how.
> > >
> > > Any further feedback is highly appreciated of course.
> >
> > Any other feedback before I post this as non-RFC?
> 
> From mlx5 perspective, who is primary user of umem_odp.c your change looks ok.

Can I assume your Acked-by?

Thanks for your review!
-- 
Michal Hocko
SUSE Labs
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [RFC PATCH] mm, oom: distinguish blockable mode for mmu notifiers

[Leon Romanovsky]

On Mon, Jul 09, 2018 at 02:29:08PM +0200, Michal Hocko wrote:
> On Wed 27-06-18 09:44:21, Michal Hocko wrote:
> > This is the v2 of RFC based on the feedback I've received so far. The
> > code even compiles as a bonus ;) I haven't runtime tested it yet, mostly
> > because I have no idea how.
> >
> > Any further feedback is highly appreciated of course.
>
> Any other feedback before I post this as non-RFC?

From mlx5 perspective, who is primary user of umem_odp.c your change looks ok.

Thanks


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

Re: [PATCH 38/54] drm/amd/display: Expose bunch of functions from dcn10_hw_sequencer

[Harry Wentland]

On 2018-07-10 12:56 AM, Dave Airlie wrote:
> This has some whitespace changes that don't seem to be related, please
> get people to be a bit more careful.
> 
> (though I do realise this could be magic ifdef stuff that got ripped out :-)
> 

It's the latter. I'm running "unifdef -B" which should compress blank lines 
around deleted sections, but it doesn't do a great job.

Could clean it up manually but that's a bit painful.

Harry

> Dave.
> 
> 
> On 10 July 2018 at 10:37, Harry Wentland  wrote:
>> From: Eric Bernstein 
>>
>> Signed-off-by: Eric Bernstein 
>> Reviewed-by: Dmytro Laktyushkin 
>> Acked-by: Harry Wentland 
>> ---
>>  .../gpu/drm/amd/display/dc/core/dc_resource.c |  1 -
>>  drivers/gpu/drm/amd/display/dc/dc_stream.h|  1 +
>>  .../amd/display/dc/dcn10/dcn10_hw_sequencer.c | 59 +++
>>  .../amd/display/dc/dcn10/dcn10_hw_sequencer.h |  7 +++
>>  .../gpu/drm/amd/display/dc/inc/hw_sequencer.h |  8 +++
>>  5 files changed, 50 insertions(+), 26 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_resource.c 
>> b/drivers/gpu/drm/amd/display/dc/core/dc_resource.c
>> index 41562ffa1c62..cacf59d0a1d6 100644
>> --- a/drivers/gpu/drm/amd/display/dc/core/dc_resource.c
>> +++ b/drivers/gpu/drm/amd/display/dc/core/dc_resource.c
>> @@ -1473,7 +1473,6 @@ bool dc_add_all_planes_for_stream(
>> return add_all_planes_for_stream(dc, stream, , 1, context);
>>  }
>>
>> -
>>  static bool is_hdr_static_meta_changed(struct dc_stream_state *cur_stream,
>> struct dc_stream_state *new_stream)
>>  {
>> diff --git a/drivers/gpu/drm/amd/display/dc/dc_stream.h 
>> b/drivers/gpu/drm/amd/display/dc/dc_stream.h
>> index 532b2aff2227..65d08d594628 100644
>> --- a/drivers/gpu/drm/amd/display/dc/dc_stream.h
>> +++ b/drivers/gpu/drm/amd/display/dc/dc_stream.h
>> @@ -131,6 +131,7 @@ struct dc_stream_update {
>> struct dc_info_packet *vsc_infopacket;
>>
>> bool *dpms_off;
>> +
>>  };
>>
>>  bool dc_is_stream_unchanged(
>> diff --git a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c 
>> b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c
>> index 28dba6a324c1..06cf967b2431 100644
>> --- a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c
>> +++ b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c
>> @@ -849,7 +849,7 @@ static bool dcn10_hw_wa_force_recovery(struct dc *dc)
>>  }
>>
>>
>> -static void dcn10_verify_allow_pstate_change_high(struct dc *dc)
>> +void dcn10_verify_allow_pstate_change_high(struct dc *dc)
>>  {
>> static bool should_log_hw_state; /* prevent hw state log by default 
>> */
>>
>> @@ -1863,8 +1863,7 @@ static void update_dpp(struct dpp *dpp, struct 
>> dc_plane_state *plane_state)
>> dpp->funcs->dpp_program_bias_and_scale(dpp, _params);
>>  }
>>
>> -
>> -static void update_mpcc(struct dc *dc, struct pipe_ctx *pipe_ctx)
>> +static void dcn10_update_mpcc(struct dc *dc, struct pipe_ctx *pipe_ctx)
>>  {
>> struct hubp *hubp = pipe_ctx->plane_res.hubp;
>> struct mpcc_blnd_cfg blnd_cfg;
>> @@ -2009,7 +2008,7 @@ static void update_dchubp_dpp(
>>
>> if (plane_state->update_flags.bits.full_update ||
>> plane_state->update_flags.bits.per_pixel_alpha_change)
>> -   update_mpcc(dc, pipe_ctx);
>> +   dc->hwss.update_mpcc(dc, pipe_ctx);
>>
>> if (plane_state->update_flags.bits.full_update ||
>> plane_state->update_flags.bits.per_pixel_alpha_change ||
>> @@ -2119,6 +2118,33 @@ static void set_hdr_multiplier(struct pipe_ctx 
>> *pipe_ctx)
>> pipe_ctx->plane_res.dpp, hw_mult);
>>  }
>>
>> +void dcn10_program_pipe(
>> +   struct dc *dc,
>> +   struct pipe_ctx *pipe_ctx,
>> +   struct dc_state *context)
>> +{
>> +   if (pipe_ctx->plane_state->update_flags.bits.full_update)
>> +   dcn10_enable_plane(dc, pipe_ctx, context);
>> +
>> +   update_dchubp_dpp(dc, pipe_ctx, context);
>> +
>> +   set_hdr_multiplier(pipe_ctx);
>> +
>> +   if (pipe_ctx->plane_state->update_flags.bits.full_update ||
>> +   
>> pipe_ctx->plane_state->update_flags.bits.in_transfer_func_change ||
>> +   
>> pipe_ctx->plane_state->update_flags.bits.gamma_change)
>> +   dc->hwss.set_input_transfer_func(pipe_ctx, 
>> pipe_ctx->plane_state);
>> +
>> +   /* dcn10_translate_regamma_to_hw_format takes 750us to finish
>> +* only do gamma programming for full update.
>> +* TODO: This can be further optimized/cleaned up
>> +* Always call this for now since it does memcmp inside before
>> +* doing heavy calculation and programming
>> +*/
>> +   if (pipe_ctx->plane_state->update_flags.bits.full_update)
>> +   dc->hwss.set_output_transfer_func(pipe_ctx, 
>> pipe_ctx->stream);
>> +}
>> +
>>  static void program_all_pipe_in_tree(
>> struct dc *dc,
>>   

Re: 答复: 答复: [alsa-devel] 答复: [PATCH] vgaswitchroo: set audio client id according to bound gpu client id

[Takashi Iwai]

On Tue, 10 Jul 2018 13:11:20 +0200,
jimqu wrote:
> 
> 
> 
> On 2018年07月10日 17:50, Takashi Iwai wrote:
> > On Tue, 10 Jul 2018 11:13:27 +0200,
> > jimqu wrote:
> >>
> >>
> >> On 2018年07月10日 16:01, Takashi Iwai wrote:
> >>> On Tue, 10 Jul 2018 09:44:42 +0200,
> >>> Qu, Jim wrote:
>  Hi Takashi,
> 
>  I am not expert in audio driver, so I just update some test result, 
>  please help triage the issue.
> 
>  With audio runtime pm:
> >>> What does this mean?  Is it the stock 4.17.x (or 4.18-rc)?
> >>> Please clarify your test environment at first: which kernel, which
> >>> hardware setup.
> >>>
> >> This is v4.15 which backport Lukas' patches and also one bug fix
> >> https://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git/commit/?id=57cb54e53bdd.
> >> The platform is AMDAPU(with audio) + AMD dGPU , it is a hybird GFX
> >> platform. In generic, dGPU will always be suspended.
> > Ah, so it's AMD+AMD, not Intel+AMD combo.  Now I understand the
> > situation better, thanks.
> >
>  1. ubuntu audio setting use pactl to query audio card/output sink. 
>  Attachment is pactl output with audio runtime pm.
>  2. cat /proc/asound/card0/eld* can get nothing.
> 
>  Without audio runtime pm:
>  1. pactl can get available audio output/sink
>  2. can get eld info from eld#0.1
> 
>  IMO, the issue should be:
> 
>  Current operations like HDMI hotplug in/out, pactl command, they do
>  not access audio HW, so the audio could not resume back at this
>  period.
> >>> Sorry, not understood.  Why they don't access the audio hardware?
> >> This is my guess, since I do not get azx_runtime_resume() print info
> >> which I added. it maybe access HW during this period, but do not
> >> trigger audio resume progress.
> >> 
>  Therefore, upper software could not get HDMI ELD info, can select a 
>  available card/output sink.
>  I am also confuse that if there is no ELD info, how driver to steam 
>  audio device to wake up itself? It's sort of a chicken-or-egg question.
> >>> As long as it's i915 and HD-audio, the hotplug and ELD info transfer
> >>> doesn't trigger the runtime PM since it's done via the direct
> >>> callback.  And ELD value is cached in HD-audio side.
> >> Yeah, I have reviewed these code, it constructs ELD after reading
> >> EDID, and write them into HW buffer when set display mode.
> > If the controller chip supports "wake-enable" feature (HD-audio WAKEEN
> > register), it could be woken up at unsolicited event even during the
> > link power down.  But, your report implies that AMD controller doesn't
> > do this, or something missing there.  That's the likely cause of the
> > missing hotplug event.
> 
> Is there any method to confirm it?

The driver always sets WAKEEN bit, see azx_runtime_suspend() in
hda_intel.c.  If it still doesn't behave as expected, it means that
the feature isn't supported on that chip :)

> > So, if my understanding is right, the situation won't be different
> > even if you have a single AMD GPU.  And possibly a side-effect of the
> > latest fix to force link-down for AMD GPU.  Need to check it...
> 
> Before Lukas' patches, it is relative with dGPU, because audio power
> is controlled by vgaswitchreroo and GFX driver, but now it won't.

Right, and this is the correct behavior.

> revert the fix of amdgpu suspend issue, audio issue also can be observed.

Did you check the behavior with the single AMD GPU hardware?
If confirmed, we can forget about vga_switcheroo.


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

Re: 答复: 答复: [alsa-devel] 答复: [PATCH] vgaswitchroo: set audio client id according to bound gpu client id

[jimqu]

On 2018年07月10日 17:50, Takashi Iwai wrote:

On Tue, 10 Jul 2018 11:13:27 +0200,
jimqu wrote:



On 2018年07月10日 16:01, Takashi Iwai wrote:

On Tue, 10 Jul 2018 09:44:42 +0200,
Qu, Jim wrote:

Hi Takashi,

I am not expert in audio driver, so I just update some test result, please help 
triage the issue.

With audio runtime pm:

What does this mean?  Is it the stock 4.17.x (or 4.18-rc)?
Please clarify your test environment at first: which kernel, which
hardware setup.


This is v4.15 which backport Lukas' patches and also one bug fix
https://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git/commit/?id=57cb54e53bdd.
The platform is AMDAPU(with audio) + AMD dGPU , it is a hybird GFX
platform. In generic, dGPU will always be suspended.

Ah, so it's AMD+AMD, not Intel+AMD combo.  Now I understand the
situation better, thanks.


1. ubuntu audio setting use pactl to query audio card/output sink. Attachment 
is pactl output with audio runtime pm.
2. cat /proc/asound/card0/eld* can get nothing.

Without audio runtime pm:
1. pactl can get available audio output/sink
2. can get eld info from eld#0.1

IMO, the issue should be:

Current operations like HDMI hotplug in/out, pactl command, they do
not access audio HW, so the audio could not resume back at this
period.

Sorry, not understood.  Why they don't access the audio hardware?

This is my guess, since I do not get azx_runtime_resume() print info
which I added. it maybe access HW during this period, but do not
trigger audio resume progress.


Therefore, upper software could not get HDMI ELD info, can select a available 
card/output sink.
I am also confuse that if there is no ELD info, how driver to steam audio 
device to wake up itself? It's sort of a chicken-or-egg question.

As long as it's i915 and HD-audio, the hotplug and ELD info transfer
doesn't trigger the runtime PM since it's done via the direct
callback.  And ELD value is cached in HD-audio side.

Yeah, I have reviewed these code, it constructs ELD after reading
EDID, and write them into HW buffer when set display mode.

If the controller chip supports "wake-enable" feature (HD-audio WAKEEN
register), it could be woken up at unsolicited event even during the
link power down.  But, your report implies that AMD controller doesn't
do this, or something missing there.  That's the likely cause of the
missing hotplug event.


Is there any method to confirm it?

So, if my understanding is right, the situation won't be different
even if you have a single AMD GPU.  And possibly a side-effect of the
latest fix to force link-down for AMD GPU.  Need to check it...


Before Lukas' patches, it is relative with dGPU, because audio power is 
controlled by vgaswitchreroo and GFX driver, but now it won't.

revert the fix of amdgpu suspend issue, audio issue also can be observed.


Takashi


The exception is that if the notification is done during the PM
operation.  But, the connection and ELD query is performed at the end
of codec resume, hence it'll be covered there.

So in theory, ELD information should be passed from the GPU to
HD-audio no matter whether runtime PM is enabled or not.


BTW, please stop top-posting.  It makes the thread readability awfully
worse.


Sorry, I justed used outlook client.

thanks,

Takashi


Thanks
JimQu


发件人: Takashi Iwai 
发送时间: 2018年7月10日 1:09
收件人: Qu, Jim
抄送: Daniel Vetter; Alex Deucher; alsa-de...@alsa-project.org; 
amd-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org; Deucher, 
Alexander
主题: Re: 答复: [alsa-devel]答复: [PATCH] vgaswitchroo: set audio client id 
according to bound gpu client id

On Mon, 09 Jul 2018 18:05:09 +0200,
Qu, Jim wrote:

Hi Takashi,

Not intel, but it is AMD APU+ AMD GFX, the APU has a local HDMI port for 
extension. And dGPU is only for offloading render via PRIME.

Originally, the HDA driver before v4.17, there is a bug, that all the audio is 
set to CLIENT_DIS, so the when the dGPU suspend, the audio which is bound to 
iGPU will also be suspend.

Now, after Lukas' patches. The audio will auto suspend. It make ubuntu audio 
setting could not detect HDMI audio, even if HDMI has light up.

OK, and it has all necessary patches including the one Lukas
suggested, right?

If so, figure out what you're actually seeing as "PA could not detect
HDMI audio".  For example, is it the HDMI (jack) detection (giving
false even if it's connected)?  Or is it an error at opening the given
device? Does the driver give the proper ELD bytes as well as the jack
state?


Takashi


Thanks
JimQu

-邮件原件-
发件人: Takashi Iwai 
发送时间: 2018年7月9日 23:58
收件人: Daniel Vetter 
抄送: Alex Deucher ; alsa-de...@alsa-project.org; 
amd-gfx@lists.freedesktop.org; Qu, Jim ; dri-de...@lists.freedesktop.org; 
Deucher, Alexander 
主题: Re: [alsa-devel] 答复: [PATCH] vgaswitchroo: set audio client id according to 
bound gpu client id

On Mon, 09 Jul 2018 17:56:43 +0200,
Daniel 

Re: 答复: 答复: [alsa-devel] 答复: [PATCH] vgaswitchroo: set audio client id according to bound gpu client id

[Takashi Iwai]

On Tue, 10 Jul 2018 11:13:27 +0200,
jimqu wrote:
> 
> 
> 
> On 2018年07月10日 16:01, Takashi Iwai wrote:
> > On Tue, 10 Jul 2018 09:44:42 +0200,
> > Qu, Jim wrote:
> >> Hi Takashi,
> >>
> >> I am not expert in audio driver, so I just update some test result, please 
> >> help triage the issue.
> >>
> >> With audio runtime pm:
> > What does this mean?  Is it the stock 4.17.x (or 4.18-rc)?
> > Please clarify your test environment at first: which kernel, which
> > hardware setup.
> >
> This is v4.15 which backport Lukas' patches and also one bug fix
> https://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git/commit/?id=57cb54e53bdd.
> The platform is AMDAPU(with audio) + AMD dGPU , it is a hybird GFX
> platform. In generic, dGPU will always be suspended.

Ah, so it's AMD+AMD, not Intel+AMD combo.  Now I understand the
situation better, thanks.

> >> 1. ubuntu audio setting use pactl to query audio card/output sink. 
> >> Attachment is pactl output with audio runtime pm.
> >> 2. cat /proc/asound/card0/eld* can get nothing.
> >>
> >> Without audio runtime pm:
> >> 1. pactl can get available audio output/sink
> >> 2. can get eld info from eld#0.1
> >>
> >> IMO, the issue should be:
> >>
> >> Current operations like HDMI hotplug in/out, pactl command, they do
> >> not access audio HW, so the audio could not resume back at this
> >> period.
> > Sorry, not understood.  Why they don't access the audio hardware?
> This is my guess, since I do not get azx_runtime_resume() print info
> which I added. it maybe access HW during this period, but do not
> trigger audio resume progress.
> 
> >> Therefore, upper software could not get HDMI ELD info, can select a 
> >> available card/output sink.
> >> I am also confuse that if there is no ELD info, how driver to steam audio 
> >> device to wake up itself? It's sort of a chicken-or-egg question.
> > As long as it's i915 and HD-audio, the hotplug and ELD info transfer
> > doesn't trigger the runtime PM since it's done via the direct
> > callback.  And ELD value is cached in HD-audio side.
> Yeah, I have reviewed these code, it constructs ELD after reading
> EDID, and write them into HW buffer when set display mode.

If the controller chip supports "wake-enable" feature (HD-audio WAKEEN
register), it could be woken up at unsolicited event even during the
link power down.  But, your report implies that AMD controller doesn't
do this, or something missing there.  That's the likely cause of the
missing hotplug event.

So, if my understanding is right, the situation won't be different
even if you have a single AMD GPU.  And possibly a side-effect of the
latest fix to force link-down for AMD GPU.  Need to check it...


Takashi

> > The exception is that if the notification is done during the PM
> > operation.  But, the connection and ELD query is performed at the end
> > of codec resume, hence it'll be covered there.
> >
> > So in theory, ELD information should be passed from the GPU to
> > HD-audio no matter whether runtime PM is enabled or not.
> >
> >
> > BTW, please stop top-posting.  It makes the thread readability awfully
> > worse.
> >
> Sorry, I justed used outlook client.
> > thanks,
> >
> > Takashi
> >
> >> Thanks
> >> JimQu
> >>
> >> 
> >> 发件人: Takashi Iwai 
> >> 发送时间: 2018年7月10日 1:09
> >> 收件人: Qu, Jim
> >> 抄送: Daniel Vetter; Alex Deucher; alsa-de...@alsa-project.org; 
> >> amd-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org; Deucher, 
> >> Alexander
> >> 主题: Re: 答复: [alsa-devel]答复: [PATCH] vgaswitchroo: set audio client 
> >> id according to bound gpu client id
> >>
> >> On Mon, 09 Jul 2018 18:05:09 +0200,
> >> Qu, Jim wrote:
> >>> Hi Takashi,
> >>>
> >>> Not intel, but it is AMD APU+ AMD GFX, the APU has a local HDMI port for 
> >>> extension. And dGPU is only for offloading render via PRIME.
> >>>
> >>> Originally, the HDA driver before v4.17, there is a bug, that all the 
> >>> audio is set to CLIENT_DIS, so the when the dGPU suspend, the audio which 
> >>> is bound to iGPU will also be suspend.
> >>>
> >>> Now, after Lukas' patches. The audio will auto suspend. It make ubuntu 
> >>> audio setting could not detect HDMI audio, even if HDMI has light up.
> >> OK, and it has all necessary patches including the one Lukas
> >> suggested, right?
> >>
> >> If so, figure out what you're actually seeing as "PA could not detect
> >> HDMI audio".  For example, is it the HDMI (jack) detection (giving
> >> false even if it's connected)?  Or is it an error at opening the given
> >> device? Does the driver give the proper ELD bytes as well as the jack
> >> state?
> >>
> >>
> >> Takashi
> >>
> >>> Thanks
> >>> JimQu
> >>>
> >>> -邮件原件-
> >>> 发件人: Takashi Iwai 
> >>> 发送时间: 2018年7月9日 23:58
> >>> 收件人: Daniel Vetter 
> >>> 抄送: Alex Deucher ; alsa-de...@alsa-project.org; 
> >>> amd-gfx@lists.freedesktop.org; Qu, Jim ; 
> >>> 

Re: 答复: 答复: [alsa-devel] 答复: [PATCH] vgaswitchroo: set audio client id according to bound gpu client id

[jimqu]

On 2018年07月10日 16:01, Takashi Iwai wrote:

On Tue, 10 Jul 2018 09:44:42 +0200,
Qu, Jim wrote:

Hi Takashi,

I am not expert in audio driver, so I just update some test result, please help 
triage the issue.

With audio runtime pm:

What does this mean?  Is it the stock 4.17.x (or 4.18-rc)?
Please clarify your test environment at first: which kernel, which
hardware setup.

This is v4.15 which backport Lukas' patches and also one bug fix 
https://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git/commit/?id=57cb54e53bdd.
The platform is AMDAPU(with audio) + AMD dGPU , it is a hybird GFX 
platform. In generic, dGPU will always be suspended.

1. ubuntu audio setting use pactl to query audio card/output sink. Attachment 
is pactl output with audio runtime pm.
2. cat /proc/asound/card0/eld* can get nothing.

Without audio runtime pm:
1. pactl can get available audio output/sink
2. can get eld info from eld#0.1

IMO, the issue should be:

Current operations like HDMI hotplug in/out, pactl command, they do
not access audio HW, so the audio could not resume back at this
period.

Sorry, not understood.  Why they don't access the audio hardware?
This is my guess, since I do not get azx_runtime_resume() print info 
which I added. it maybe access HW during this period, but do not trigger 
audio resume progress.



Therefore, upper software could not get HDMI ELD info, can select a available 
card/output sink.
I am also confuse that if there is no ELD info, how driver to steam audio 
device to wake up itself? It's sort of a chicken-or-egg question.

As long as it's i915 and HD-audio, the hotplug and ELD info transfer
doesn't trigger the runtime PM since it's done via the direct
callback.  And ELD value is cached in HD-audio side.
Yeah, I have reviewed these code, it constructs ELD after reading EDID, 
and write them into HW buffer when set display mode.

The exception is that if the notification is done during the PM
operation.  But, the connection and ELD query is performed at the end
of codec resume, hence it'll be covered there.

So in theory, ELD information should be passed from the GPU to
HD-audio no matter whether runtime PM is enabled or not.


BTW, please stop top-posting.  It makes the thread readability awfully
worse.


Sorry, I justed used outlook client.

thanks,

Takashi


Thanks
JimQu


发件人: Takashi Iwai 
发送时间: 2018年7月10日 1:09
收件人: Qu, Jim
抄送: Daniel Vetter; Alex Deucher; alsa-de...@alsa-project.org; 
amd-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org; Deucher, 
Alexander
主题: Re: 答复: [alsa-devel]答复: [PATCH] vgaswitchroo: set audio client id 
according to bound gpu client id

On Mon, 09 Jul 2018 18:05:09 +0200,
Qu, Jim wrote:

Hi Takashi,

Not intel, but it is AMD APU+ AMD GFX, the APU has a local HDMI port for 
extension. And dGPU is only for offloading render via PRIME.

Originally, the HDA driver before v4.17, there is a bug, that all the audio is 
set to CLIENT_DIS, so the when the dGPU suspend, the audio which is bound to 
iGPU will also be suspend.

Now, after Lukas' patches. The audio will auto suspend. It make ubuntu audio 
setting could not detect HDMI audio, even if HDMI has light up.

OK, and it has all necessary patches including the one Lukas
suggested, right?

If so, figure out what you're actually seeing as "PA could not detect
HDMI audio".  For example, is it the HDMI (jack) detection (giving
false even if it's connected)?  Or is it an error at opening the given
device? Does the driver give the proper ELD bytes as well as the jack
state?


Takashi


Thanks
JimQu

-邮件原件-
发件人: Takashi Iwai 
发送时间: 2018年7月9日 23:58
收件人: Daniel Vetter 
抄送: Alex Deucher ; alsa-de...@alsa-project.org; 
amd-gfx@lists.freedesktop.org; Qu, Jim ; dri-de...@lists.freedesktop.org; 
Deucher, Alexander 
主题: Re: [alsa-devel] 答复: [PATCH] vgaswitchroo: set audio client id according to 
bound gpu client id

On Mon, 09 Jul 2018 17:56:43 +0200,
Daniel Vetter wrote:

On Mon, Jul 09, 2018 at 05:04:22PM +0200, Takashi Iwai wrote:

On Mon, 09 Jul 2018 15:58:51 +0200,
Alex Deucher wrote:

On Mon, Jul 9, 2018 at 6:16 AM, Qu, Jim  wrote:

Hi Lukas,

Thanks to your explanation, and see comments in line.


Do you need to runtime resume the HDA controller even if user
space isn't streaming audio?  Why, and in which situation exactly?

Jim: OEM system uses pactl to queiry audio card and audio output sink, since 
the audio has power down by runtime pm, so the audio card and output sink are 
all unavailable. they could not select the available HDMI audio for audio 
playing.

You're saying above that the HDA controller isn't runtime
resumed on hotplug of a display.  Is that necessary to retrieve ELD or 
something?
I'm not sure if there's code in the HDA driver to acquire a
runtime PM ref on HPD, but maybe it's necessary.  Or maybe the
code is there but somehow no HPD interrupt is received by the HDA 

Re: 答复: 答复: [alsa-devel] 答复: [PATCH] vgaswitchroo: set audio client id according to bound gpu client id

[Takashi Iwai]

On Tue, 10 Jul 2018 09:44:42 +0200,
Qu, Jim wrote:
> 
> Hi Takashi,
> 
> I am not expert in audio driver, so I just update some test result, please 
> help triage the issue.
> 
> With audio runtime pm:

What does this mean?  Is it the stock 4.17.x (or 4.18-rc)?
Please clarify your test environment at first: which kernel, which
hardware setup.

> 1. ubuntu audio setting use pactl to query audio card/output sink. Attachment 
> is pactl output with audio runtime pm.
> 2. cat /proc/asound/card0/eld* can get nothing.
> 
> Without audio runtime pm:
> 1. pactl can get available audio output/sink
> 2. can get eld info from eld#0.1
> 
> IMO, the issue should be:
> 
> Current operations like HDMI hotplug in/out, pactl command, they do
> not access audio HW, so the audio could not resume back at this
> period.

Sorry, not understood.  Why they don't access the audio hardware?

> Therefore, upper software could not get HDMI ELD info, can select a available 
> card/output sink.
> I am also confuse that if there is no ELD info, how driver to steam audio 
> device to wake up itself? It's sort of a chicken-or-egg question.

As long as it's i915 and HD-audio, the hotplug and ELD info transfer
doesn't trigger the runtime PM since it's done via the direct
callback.  And ELD value is cached in HD-audio side.

The exception is that if the notification is done during the PM
operation.  But, the connection and ELD query is performed at the end
of codec resume, hence it'll be covered there.

So in theory, ELD information should be passed from the GPU to
HD-audio no matter whether runtime PM is enabled or not.


BTW, please stop top-posting.  It makes the thread readability awfully
worse.


thanks,

Takashi

> 
> Thanks
> JimQu
> 
> 
> 发件人: Takashi Iwai 
> 发送时间: 2018年7月10日 1:09
> 收件人: Qu, Jim
> 抄送: Daniel Vetter; Alex Deucher; alsa-de...@alsa-project.org; 
> amd-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org; Deucher, 
> Alexander
> 主题: Re: 答复: [alsa-devel]答复: [PATCH] vgaswitchroo: set audio client id 
> according to bound gpu client id
> 
> On Mon, 09 Jul 2018 18:05:09 +0200,
> Qu, Jim wrote:
> >
> > Hi Takashi,
> >
> > Not intel, but it is AMD APU+ AMD GFX, the APU has a local HDMI port for 
> > extension. And dGPU is only for offloading render via PRIME.
> >
> > Originally, the HDA driver before v4.17, there is a bug, that all the audio 
> > is set to CLIENT_DIS, so the when the dGPU suspend, the audio which is 
> > bound to iGPU will also be suspend.
> >
> > Now, after Lukas' patches. The audio will auto suspend. It make ubuntu 
> > audio setting could not detect HDMI audio, even if HDMI has light up.
> 
> OK, and it has all necessary patches including the one Lukas
> suggested, right?
> 
> If so, figure out what you're actually seeing as "PA could not detect
> HDMI audio".  For example, is it the HDMI (jack) detection (giving
> false even if it's connected)?  Or is it an error at opening the given
> device? Does the driver give the proper ELD bytes as well as the jack
> state?
> 
> 
> Takashi
> 
> >
> > Thanks
> > JimQu
> >
> > -邮件原件-
> > 发件人: Takashi Iwai 
> > 发送时间: 2018年7月9日 23:58
> > 收件人: Daniel Vetter 
> > 抄送: Alex Deucher ; alsa-de...@alsa-project.org; 
> > amd-gfx@lists.freedesktop.org; Qu, Jim ; 
> > dri-de...@lists.freedesktop.org; Deucher, Alexander 
> > 
> > 主题: Re: [alsa-devel] 答复: [PATCH] vgaswitchroo: set audio client id 
> > according to bound gpu client id
> >
> > On Mon, 09 Jul 2018 17:56:43 +0200,
> > Daniel Vetter wrote:
> > >
> > > On Mon, Jul 09, 2018 at 05:04:22PM +0200, Takashi Iwai wrote:
> > > > On Mon, 09 Jul 2018 15:58:51 +0200,
> > > > Alex Deucher wrote:
> > > > >
> > > > > On Mon, Jul 9, 2018 at 6:16 AM, Qu, Jim  wrote:
> > > > > > Hi Lukas,
> > > > > >
> > > > > > Thanks to your explanation, and see comments in line.
> > > > > >
> > > > > >
> > > > > > Do you need to runtime resume the HDA controller even if user
> > > > > > space isn't streaming audio?  Why, and in which situation exactly?
> > > > > >
> > > > > > Jim: OEM system uses pactl to queiry audio card and audio output 
> > > > > > sink, since the audio has power down by runtime pm, so the audio 
> > > > > > card and output sink are all unavailable. they could not select the 
> > > > > > available HDMI audio for audio playing.
> > > > > >
> > > > > > You're saying above that the HDA controller isn't runtime
> > > > > > resumed on hotplug of a display.  Is that necessary to retrieve ELD 
> > > > > > or something?
> > > > > > I'm not sure if there's code in the HDA driver to acquire a
> > > > > > runtime PM ref on HPD, but maybe it's necessary.  Or maybe the
> > > > > > code is there but somehow no HPD interrupt is received by the HDA 
> > > > > > driver?
> > > > > >
> > > > > > Jim: So far, I do not find any code about audio response HPD in 
> > > > > > kernel. the HPD interrupt will sent to user mode via uevent, not 
> > > > > > sure whether audio user mode driver can 

答复: 答复: [alsa-devel] 答复: [PATCH] vgaswitchroo: set audio client id according to bound gpu client id

[Qu, Jim]

Sorry, correct the typo.

IMO, the issue should be:

Current operations like HDMI hotplug in/out, pactl command, they do not access 
audio HW, so the audio could not resume back at this period. Therefore, upper 
software could not get HDMI ELD info, it can not select an available 
card/output sink.
I am also confuse that if there is no ELD info, how driver to steam audio 
device to wake up itself? It's sort of a chicken-or-egg question.

Thanks
JimQu


发件人: Qu, Jim
发送时间: 2018年7月10日 15:44:42
收件人: Takashi Iwai
抄送: Daniel Vetter; Alex Deucher; alsa-de...@alsa-project.org; 
amd-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org; Deucher, 
Alexander
主题: 答复: 答复: [alsa-devel]答复: [PATCH] vgaswitchroo: set audio client id 
according to bound gpu client id

Hi Takashi,

I am not expert in audio driver, so I just update some test result, please help 
triage the issue.

With audio runtime pm:

1. ubuntu audio setting use pactl to query audio card/output sink. Attachment 
is pactl output with audio runtime pm.
2. cat /proc/asound/card0/eld* can get nothing.

Without audio runtime pm:
1. pactl can get available audio output/sink
2. can get eld info from eld#0.1

IMO, the issue should be:

Current operations like HDMI hotplug in/out, pactl command, they do not access 
audio HW, so the audio could not resume back at this period. Therefore, upper 
software could not get HDMI ELD info, can select a available card/output sink.
I am also confuse that if there is no ELD info, how driver to steam audio 
device to wake up itself? It's sort of a chicken-or-egg question.

Thanks
JimQu


发件人: Takashi Iwai 
发送时间: 2018年7月10日 1:09
收件人: Qu, Jim
抄送: Daniel Vetter; Alex Deucher; alsa-de...@alsa-project.org; 
amd-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org; Deucher, 
Alexander
主题: Re: 答复: [alsa-devel]答复: [PATCH] vgaswitchroo: set audio client id 
according to bound gpu client id

On Mon, 09 Jul 2018 18:05:09 +0200,
Qu, Jim wrote:
>
> Hi Takashi,
>
> Not intel, but it is AMD APU+ AMD GFX, the APU has a local HDMI port for 
> extension. And dGPU is only for offloading render via PRIME.
>
> Originally, the HDA driver before v4.17, there is a bug, that all the audio 
> is set to CLIENT_DIS, so the when the dGPU suspend, the audio which is bound 
> to iGPU will also be suspend.
>
> Now, after Lukas' patches. The audio will auto suspend. It make ubuntu audio 
> setting could not detect HDMI audio, even if HDMI has light up.

OK, and it has all necessary patches including the one Lukas
suggested, right?

If so, figure out what you're actually seeing as "PA could not detect
HDMI audio".  For example, is it the HDMI (jack) detection (giving
false even if it's connected)?  Or is it an error at opening the given
device? Does the driver give the proper ELD bytes as well as the jack
state?


Takashi

>
> Thanks
> JimQu
>
> -邮件原件-
> 发件人: Takashi Iwai 
> 发送时间: 2018年7月9日 23:58
> 收件人: Daniel Vetter 
> 抄送: Alex Deucher ; alsa-de...@alsa-project.org; 
> amd-gfx@lists.freedesktop.org; Qu, Jim ; 
> dri-de...@lists.freedesktop.org; Deucher, Alexander 
> 
> 主题: Re: [alsa-devel] 答复: [PATCH] vgaswitchroo: set audio client id according 
> to bound gpu client id
>
> On Mon, 09 Jul 2018 17:56:43 +0200,
> Daniel Vetter wrote:
> >
> > On Mon, Jul 09, 2018 at 05:04:22PM +0200, Takashi Iwai wrote:
> > > On Mon, 09 Jul 2018 15:58:51 +0200,
> > > Alex Deucher wrote:
> > > >
> > > > On Mon, Jul 9, 2018 at 6:16 AM, Qu, Jim  wrote:
> > > > > Hi Lukas,
> > > > >
> > > > > Thanks to your explanation, and see comments in line.
> > > > >
> > > > >
> > > > > Do you need to runtime resume the HDA controller even if user
> > > > > space isn't streaming audio?  Why, and in which situation exactly?
> > > > >
> > > > > Jim: OEM system uses pactl to queiry audio card and audio output 
> > > > > sink, since the audio has power down by runtime pm, so the audio card 
> > > > > and output sink are all unavailable. they could not select the 
> > > > > available HDMI audio for audio playing.
> > > > >
> > > > > You're saying above that the HDA controller isn't runtime
> > > > > resumed on hotplug of a display.  Is that necessary to retrieve ELD 
> > > > > or something?
> > > > > I'm not sure if there's code in the HDA driver to acquire a
> > > > > runtime PM ref on HPD, but maybe it's necessary.  Or maybe the
> > > > > code is there but somehow no HPD interrupt is received by the HDA 
> > > > > driver?
> > > > >
> > > > > Jim: So far, I do not find any code about audio response HPD in 
> > > > > kernel. the HPD interrupt will sent to user mode via uevent, not sure 
> > > > > whether audio user mode driver can receive the event or not.
> > > >
> > > > On the gfx side at least, we can get a hotplug event via ACPI
> > > > (depending on the OEM design) if displays are attached/detached
> > > > while the dGPU is powered down.  I suppose the gfx driver could
> > > > call 

答复: 答复: [alsa-devel] 答复: [PATCH] vgaswitchroo: set audio client id according to bound gpu client id

[Qu, Jim]

Hi Takashi,

I am not expert in audio driver, so I just update some test result, please help 
triage the issue.

With audio runtime pm:

1. ubuntu audio setting use pactl to query audio card/output sink. Attachment 
is pactl output with audio runtime pm.
2. cat /proc/asound/card0/eld* can get nothing.

Without audio runtime pm:
1. pactl can get available audio output/sink
2. can get eld info from eld#0.1

IMO, the issue should be:

Current operations like HDMI hotplug in/out, pactl command, they do not access 
audio HW, so the audio could not resume back at this period. Therefore, upper 
software could not get HDMI ELD info, can select a available card/output sink.
I am also confuse that if there is no ELD info, how driver to steam audio 
device to wake up itself? It's sort of a chicken-or-egg question.

Thanks
JimQu


发件人: Takashi Iwai 
发送时间: 2018年7月10日 1:09
收件人: Qu, Jim
抄送: Daniel Vetter; Alex Deucher; alsa-de...@alsa-project.org; 
amd-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org; Deucher, 
Alexander
主题: Re: 答复: [alsa-devel]答复: [PATCH] vgaswitchroo: set audio client id 
according to bound gpu client id

On Mon, 09 Jul 2018 18:05:09 +0200,
Qu, Jim wrote:
>
> Hi Takashi,
>
> Not intel, but it is AMD APU+ AMD GFX, the APU has a local HDMI port for 
> extension. And dGPU is only for offloading render via PRIME.
>
> Originally, the HDA driver before v4.17, there is a bug, that all the audio 
> is set to CLIENT_DIS, so the when the dGPU suspend, the audio which is bound 
> to iGPU will also be suspend.
>
> Now, after Lukas' patches. The audio will auto suspend. It make ubuntu audio 
> setting could not detect HDMI audio, even if HDMI has light up.

OK, and it has all necessary patches including the one Lukas
suggested, right?

If so, figure out what you're actually seeing as "PA could not detect
HDMI audio".  For example, is it the HDMI (jack) detection (giving
false even if it's connected)?  Or is it an error at opening the given
device? Does the driver give the proper ELD bytes as well as the jack
state?


Takashi

>
> Thanks
> JimQu
>
> -邮件原件-
> 发件人: Takashi Iwai 
> 发送时间: 2018年7月9日 23:58
> 收件人: Daniel Vetter 
> 抄送: Alex Deucher ; alsa-de...@alsa-project.org; 
> amd-gfx@lists.freedesktop.org; Qu, Jim ; 
> dri-de...@lists.freedesktop.org; Deucher, Alexander 
> 
> 主题: Re: [alsa-devel] 答复: [PATCH] vgaswitchroo: set audio client id according 
> to bound gpu client id
>
> On Mon, 09 Jul 2018 17:56:43 +0200,
> Daniel Vetter wrote:
> >
> > On Mon, Jul 09, 2018 at 05:04:22PM +0200, Takashi Iwai wrote:
> > > On Mon, 09 Jul 2018 15:58:51 +0200,
> > > Alex Deucher wrote:
> > > >
> > > > On Mon, Jul 9, 2018 at 6:16 AM, Qu, Jim  wrote:
> > > > > Hi Lukas,
> > > > >
> > > > > Thanks to your explanation, and see comments in line.
> > > > >
> > > > >
> > > > > Do you need to runtime resume the HDA controller even if user
> > > > > space isn't streaming audio?  Why, and in which situation exactly?
> > > > >
> > > > > Jim: OEM system uses pactl to queiry audio card and audio output 
> > > > > sink, since the audio has power down by runtime pm, so the audio card 
> > > > > and output sink are all unavailable. they could not select the 
> > > > > available HDMI audio for audio playing.
> > > > >
> > > > > You're saying above that the HDA controller isn't runtime
> > > > > resumed on hotplug of a display.  Is that necessary to retrieve ELD 
> > > > > or something?
> > > > > I'm not sure if there's code in the HDA driver to acquire a
> > > > > runtime PM ref on HPD, but maybe it's necessary.  Or maybe the
> > > > > code is there but somehow no HPD interrupt is received by the HDA 
> > > > > driver?
> > > > >
> > > > > Jim: So far, I do not find any code about audio response HPD in 
> > > > > kernel. the HPD interrupt will sent to user mode via uevent, not sure 
> > > > > whether audio user mode driver can receive the event or not.
> > > >
> > > > On the gfx side at least, we can get a hotplug event via ACPI
> > > > (depending on the OEM design) if displays are attached/detached
> > > > while the dGPU is powered down.  I suppose the gfx driver could
> > > > call into the audio driver during one of those events.  On the gfx
> > > > side at least we just generate the gfx hotplug event and let userspace 
> > > > deal with it.
> > >
> > > IMO, a more proper way would be to have the direct communication
> > > between the graphics driver and the audio driver like i915 driver
> > > does.  Then the audio driver can get plug/unplug event at more
> > > accurate timing without races.
> > >
> > > (Though, it will cause another mess wrt the weak module dependency,
> > > but it's another story :)
> >
> > Just don't do what snd-hda-intel did and instead implement the
> > component stuff properly :-)
>
> A patch is welcome :)
>
>
> thanks,
>
> Takashi
>
> > -Daniel
> >
> > >
> > >
> > > thanks,
> > >
> > > Takashi
> > >
> > >
> > > >
> > > > Alex
> > > >
> > > > >
> > > > > 

Re: [PATCH 01/54] Revert "drm/amd/display: Don't return ddc result and read_bytes in same return value"

[Michel Dänzer]

On 2018-07-10 02:36 AM, Harry Wentland wrote:
> This reverts commit 8a61bc085ffab3071c59efcbeff4044c034e7490.

A revert commit needs a rationale (why did the commit need to be
reverted?) in the commit log.


Since this same change went into 4.17 as commit
018d82e5f02ef3583411bcaa4e00c69786f46f19, please add

Cc: sta...@vger.kernel.org


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

Re: [PATCH 3/3] drm/amdgpu: move cache window setup after power and clock resume

[Christian König]

Looks like the patches should be reordered, e.g. patch #2 should be the 
last.


Apart from that Reviewed-by: Christian König .

Regards,
Christian.

Am 09.07.2018 um 18:54 schrieb Deucher, Alexander:


Series is:

Reviewed-by: Alex Deucher 


*From:* amd-gfx  on behalf of 
Leo Liu 

*Sent:* Monday, July 9, 2018 12:11:38 PM
*To:* amd-gfx@lists.freedesktop.org
*Cc:* Liu, Leo
*Subject:* [PATCH 3/3] drm/amdgpu: move cache window setup after power 
and clock resume

To make register read/write reliable. Along with the previous patch,
VCN will work with dpm disabled case.

Signed-off-by: Leo Liu 
---
 drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c 
b/drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c

index b82c92084b6f..ca4265bc10b9 100644
--- a/drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c
@@ -600,12 +600,12 @@ static int vcn_v1_0_start(struct amdgpu_device 
*adev)

 /* disable byte swapping */
 lmi_swap_cntl = 0;

-   vcn_v1_0_mc_resume(adev);
-
 vcn_1_0_disable_static_power_gating(adev);
 /* disable clock gating */
 vcn_v1_0_disable_clock_gating(adev);

+   vcn_v1_0_mc_resume(adev);
+
 /* disable interupt */
 WREG32_P(SOC15_REG_OFFSET(UVD, 0, mmUVD_MASTINT_EN), 0,
 ~UVD_MASTINT_EN__VCPU_EN_MASK);
--
2.17.1

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


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


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