Re: [PATCH hmm 00/15] Consolidate the mmu notifier interval_tree and locking

2019-10-20 Thread Koenig, Christian
Am 18.10.19 um 22:36 schrieb Jason Gunthorpe: > On Thu, Oct 17, 2019 at 04:47:20PM +, Koenig, Christian wrote: > >>> get_user_pages/hmm_range_fault() and invalidate_range_start() both are >>> called while holding mm->map_sem, so they are always serialized. >> Not even remotely. >> >> For callin

thunderbolt 3 eGPU related bugs under Linux (1. Unable to hot-unplug, 2. initialization not properly)

2019-10-20 Thread Qu Wenruo
Hi, Thanks for all your awesome works for the full open-source graphic stack. But I still find some bugs related to thunderbolt 3 eGPU, which is very annoying. - Unable to hot unplug. Hot unplug can easily crash the kernel, most like due to some BUG_ON(). This is particularly annoying if t

radeon Disabling GPU acceleration (WB disabled?)

2019-10-20 Thread Meelis Roos
I tried 5.2, 5.3 and 5.4-rc4 on my old Fujitsu RX220 with integrated Radeon RV100. Dmesg tells that GPU acceleration is disabled. I do not know if it has been enabled in the past - no old kernels handy at the moment. From dmesg it looks like something with MTRR maybe: WB disabled. Any ideas wh

RE: [PATCH 0/4] Add RAS EEPROM table support for Arcturus.

2019-10-20 Thread Quan, Evan
Patch 1 - 2 are reviewed-by: Evan Quan Patch 3 - 4 are acked-by: Evan Quan -Original Message- From: Andrey Grodzovsky Sent: Saturday, October 19, 2019 4:48 AM To: amd-gfx@lists.freedesktop.org Cc: Chen, Guchun ; Zhou1, Tao ; Deucher, Alexander ; noreply-conflue...@amd.com; Quan, Evan

RE: [PATCH 2/4] drm/amd/powerplay: Add EEPROM I2C read/write support to Arcturus.

2019-10-20 Thread Chen, Guchun
Comment inline. Regards, Guchun -Original Message- From: Andrey Grodzovsky Sent: Saturday, October 19, 2019 4:48 AM To: amd-gfx@lists.freedesktop.org Cc: Chen, Guchun ; Zhou1, Tao ; Deucher, Alexander ; noreply-conflue...@amd.com; Quan, Evan ; Grodzovsky, Andrey Subject: [PATCH 2/4]

RE: [PATCH 2/3] drm/amd/powerplay: split out those internal used swSMU APIs

2019-10-20 Thread Quan, Evan
Thanks, that sounds better. Will send out the V2. Regards, Evan -Original Message- From: Alex Deucher Sent: Friday, October 18, 2019 11:54 PM To: Quan, Evan Cc: amd-gfx@lists.freedesktop.org; Deucher, Alexander ; Grodzovsky, Andrey Subject: Re: [PATCH 2/3] drm/amd/powerplay: split out

RE: [PATCH 4/4] drm/amdgpu: Move amdgpu_ras_recovery_init to after SMU ready.

2019-10-20 Thread Chen, Guchun
I don't think postpone RAS recovery init is not one reasonable proposal. What we do in recovery init is to read the retired page if there is, and retire corresponding memory, this will make sure these pages are reserved well before setting up memory manager and reserving other memory blocks, it

[PATCH 2/3] drm/amd/powerplay: split out those internal used swSMU APIs V2

2019-10-20 Thread Quan, Evan
Those swSMU APIs used internally are moved to smu_internal.h while others are kept in amdgpu_smu.h. V2: give a better name smu_internal.h for the place to hold those internal APIs Change-Id: Ib726ef7f65dee46e47a07680b71e6e043e459f42 Signed-off-by: Evan Quan --- drivers/gpu/drm/amd/powerplay

[PATCH 1/3] drm/amd/powerplay: add lock protection for swSMU APIs V2

2019-10-20 Thread Quan, Evan
This is a quick and low risk fix. Those APIs which are exposed to other IPs or to support sysfs/hwmon interfaces or DAL will have lock protection. Meanwhile no lock protection is enforced for swSMU internal used APIs. Future optimization is needed. V2: strip the lock protection for all swSMU inter

[PATCH 3/3] drm/amd/powerplay: clear the swSMU code layer

2019-10-20 Thread Quan, Evan
With this cleanup, the APIs from amdgpu_smu.c will map to ASIC specific ones directly. Those can be shared around all SMU V11/V12 ASICs will be put in smu_v11_0.c and smu_v12_0.c respectively. Change-Id: I9b98eb5ace5df19896de4b05c37255a38d1079ce Signed-off-by: Evan Quan Acked-by: Alex Deucher --

RE: [PATCH 2/4] drm/amd/powerplay: Add EEPROM I2C read/write support to Arcturus.

2019-10-20 Thread Li, Dennis
To make the function behavior more clear, It's better to change the function declaration from + static void arcturus_fill_eeprom_i2c_req(SwI2cRequest_t *req, bool write, + uint8_t address, uint32_t numbytes, + uint8_t *data) to +