> memleak is also not an English word. Memory leak is only a few more
> characters, and doesn't require the reader to make the small extra effort
> to figure out what you mean.
Would you like to achieve similar adjustments at any more places?
How do you think about effects from a corresponding j
On Sat, 20 Jun 2020, Markus Elfring wrote:
> > The function kobject_init_and_add alloc memory like:
> > kobject_init_and_add->kobject_add_varg->kobject_set_name_vargs
> > ->kvasprintf_const->kstrdup_const->kstrdup->kmalloc_track_caller
> > ->kmalloc_slab, in err branch this memory not free. If u
On Sun, Jun 21, 2020 at 07:28:40PM +0200, Daniel Vetter wrote:
> On Sun, Jun 21, 2020 at 7:01 PM Qian Cai wrote:
> >
> > On Thu, Jun 04, 2020 at 10:12:07AM +0200, Daniel Vetter wrote:
> > > fs_reclaim_acquire/release nicely catch recursion issues when
> > > allocating GFP_KERNEL memory against shr
On Sun, Jun 21, 2020 at 10:01:03PM +0200, Daniel Vetter wrote:
> On Sun, Jun 21, 2020 at 08:07:08PM +0200, Daniel Vetter wrote:
> > On Sun, Jun 21, 2020 at 7:42 PM Qian Cai wrote:
> > >
> > > On Wed, Jun 10, 2020 at 09:41:01PM +0200, Daniel Vetter wrote:
> > > > fs_reclaim_acquire/release nicely c
On Wed, Jun 10, 2020 at 09:41:01PM +0200, Daniel Vetter wrote:
> fs_reclaim_acquire/release nicely catch recursion issues when
> allocating GFP_KERNEL memory against shrinkers (which gpu drivers tend
> to use to keep the excessive caches in check). For mmu notifier
> recursions we do have lockdep a
On Thu, Jun 04, 2020 at 10:12:07AM +0200, Daniel Vetter wrote:
> fs_reclaim_acquire/release nicely catch recursion issues when
> allocating GFP_KERNEL memory against shrinkers (which gpu drivers tend
> to use to keep the excessive caches in check). For mmu notifier
> recursions we do have lockdep a
> The function kobject_init_and_add alloc memory like:
> kobject_init_and_add->kobject_add_varg->kobject_set_name_vargs
> ->kvasprintf_const->kstrdup_const->kstrdup->kmalloc_track_caller
> ->kmalloc_slab, in err branch this memory not free. If use
> kmemleak, this path maybe catched.
> These change
As both VRR min and max are already part of drm_display_info,
drm can expose this VRR range for each connector.
Hence this logic should move to core DRM.
This reverts commit 727962f030c23422a01e8b22d0f463815fb15ec4.
Signed-off-by: Bhanuprakash Modem
Cc: Nicholas Kazlauskas
Cc: Harry Wentland
From: Julia Lawall
Date: 2020-06-20 17:37:19
To: Markus Elfring
Cc: Bernard Zhao
,opensource.ker...@vivo.com,amd-gfx@lists.freedesktop.org,dri-de...@lists.freedesktop.org,kernel-janit...@vger.kernel.org,linux-ker...@vger.kernel.org,Alex
Deucher ,"Christian König"
,"Felix Kühling" ,Daniel
On Sat, 20 Jun 2020, Markus Elfring wrote:
> > The function kobject_init_and_add alloc memory like:
> > kobject_init_and_add->kobject_add_varg->kobject_set_name_vargs
> > ->kvasprintf_const->kstrdup_const->kstrdup->kmalloc_track_caller
> > ->kmalloc_slab, in err branch this memory not free. If u
> The function kobject_init_and_add alloc memory like:
> kobject_init_and_add->kobject_add_varg->kobject_set_name_vargs
> ->kvasprintf_const->kstrdup_const->kstrdup->kmalloc_track_caller
> ->kmalloc_slab, in err branch this memory not free. If use
> kmemleak, this path maybe catched.
> These change
The function kobject_init_and_add alloc memory like:
kobject_init_and_add->kobject_add_varg->kobject_set_name_vargs
->kvasprintf_const->kstrdup_const->kstrdup->kmalloc_track_caller
->kmalloc_slab, in err branch this memory not free. If use
kmemleak, this path maybe catched.
These changes are to add
>> I suggest to improve this change description.
>>
>> * Can an other wording variant be nicer?
>
> Markus's suggestion is as usual extremely imprecise.
I pointed a general possibility out. I did not propose an exact wording
alternative as it happened for other patches.
> However, I also find th
The function kobject_init_and_add alloc memory like:
kobject_init_and_add->kobject_add_varg->kobject_set_name_vargs
->kvasprintf_const->kstrdup_const->kstrdup->kmalloc_track_caller
->kmalloc_slab, in err branch this memory not free. If use
kmemleak, this path maybe catched.
These changes are to add
On Sat, 20 Jun 2020, Bernard wrote:
>
>
> From: Julia Lawall
> Date: 2020-06-20 17:37:19
> To: Markus Elfring
> Cc: Bernard Zhao
> ,opensource.ker...@vivo.com,amd-gfx@lists.freedesktop.org,dri-de...@lists.freedesktop.org,kernel-janit...@vger.kernel.org,linux-ker...@vger.kernel.org,Alex
> D
On Fri, Jun 19, 2020 at 3:12 PM Chris Wilson wrote:
>
> Quoting Daniel Vetter (2020-06-19 10:43:09)
> > On Fri, Jun 19, 2020 at 10:13:35AM +0100, Chris Wilson wrote:
> > > Quoting Daniel Vetter (2020-06-19 09:51:59)
> > > > On Fri, Jun 19, 2020 at 10:25 AM Chris Wilson
> > > > wrote:
> > > > > F
On Sun, Jun 21, 2020 at 02:03:01AM -0400, Andrey Grodzovsky wrote:
> Will be used to reroute CPU mapped BO's page faults once
> device is removed.
>
> Signed-off-by: Andrey Grodzovsky
> ---
> drivers/gpu/drm/drm_file.c | 8
> drivers/gpu/drm/drm_prime.c | 10 ++
> include/drm/
On Sun, Jun 21, 2020 at 02:03:02AM -0400, Andrey Grodzovsky wrote:
> On device removal reroute all CPU mappings to dummy page per drm_file
> instance or imported GEM object.
>
> Signed-off-by: Andrey Grodzovsky
> ---
> drivers/gpu/drm/ttm/ttm_bo_vm.c | 65
> -
On Sun, Jun 21, 2020 at 02:03:03AM -0400, Andrey Grodzovsky wrote:
> Helper function to be used to invalidate all BOs CPU mappings
> once device is removed.
>
> Signed-off-by: Andrey Grodzovsky
This seems to be missing the code to invalidate all the dma-buf mmaps?
Probably needs more testcases
On Sun, Jun 21, 2020 at 02:03:00AM -0400, Andrey Grodzovsky wrote:
> This RFC is more of a proof of concept then a fully working solution as there
> are a few unresolved issues we are hoping to get advise on from people on the
> mailing list.
> Until now extracting a card either by physical extra
On Sun, Jun 21, 2020 at 02:03:04AM -0400, Andrey Grodzovsky wrote:
> Some of the stuff in amdgpu_device_fini such as HW interrupts
> disable and pending fences finilization must be done right away on
> pci_remove while most of the stuff which relates to finilizing and releasing
> driver data struct
On Sun, Jun 21, 2020 at 02:03:05AM -0400, Andrey Grodzovsky wrote:
> Track sysfs files in a list so they all can be removed during pci remove
> since otherwise their removal after that causes crash because parent
> folder was already removed during pci remove.
>
> Signed-off-by: Andrey Grodzovsky
On Sun, Jun 21, 2020 at 02:03:08AM -0400, Andrey Grodzovsky wrote:
> No point to try recovery if device is gone, just messes up things.
>
> Signed-off-by: Andrey Grodzovsky
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 16
> drivers/gpu/drm/amd/amdgpu/amdgpu_job.c | 8 +
On Sun, Jun 21, 2020 at 02:03:07AM -0400, Andrey Grodzovsky wrote:
> entity->rq becomes null aftre device unplugged so just return early
> in that case.
>
> Signed-off-by: Andrey Grodzovsky
That looks very deep in amdgpu internals ... how do you even get in here
after the device is fully unplugg
On Sun, Jun 21, 2020 at 02:03:06AM -0400, Andrey Grodzovsky wrote:
> Use the new TTM interface to invalidate all exsisting BO CPU mappings
> form all user proccesses.
>
> Signed-off-by: Andrey Grodzovsky
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 1 +
> 1 file changed, 1 insertion(+)
>
>
Am 21.06.20 um 08:03 schrieb Andrey Grodzovsky:
Will be used to reroute CPU mapped BO's page faults once
device is removed.
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/drm_file.c | 8
drivers/gpu/drm/drm_prime.c | 10 ++
include/drm/drm_file.h | 2 ++
incl
Am 21.06.20 um 08:03 schrieb Andrey Grodzovsky:
Track sysfs files in a list so they all can be removed during pci remove
since otherwise their removal after that causes crash because parent
folder was already removed during pci remove.
That looks extremely fishy to me.
It sounds like we just d
Am 22.06.20 um 16:42 schrieb Bhanuprakash Modem:
As both VRR min and max are already part of drm_display_info,
drm can expose this VRR range for each connector.
Hence this logic should move to core DRM.
This reverts commit 727962f030c23422a01e8b22d0f463815fb15ec4.
Signed-off-by: Bhanuprakash M
Am 19.06.20 um 12:36 schrieb Marek Szyprowski:
The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function
returns the number of the created entries in the DMA address space.
However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and
dma_unmap_sg must be called with the
On Fri, Jun 19, 2020 at 04:31:47PM -0400, Jerome Glisse wrote:
> Not doable as page refcount can change for things unrelated to GUP, with
> John changes we can identify GUP and we could potentialy copy GUPed page
> instead of COW but this can potentialy slow down fork() and i am not sure
> how acce
On Mon, Jun 22, 2020 at 11:51:24AM +0200, Daniel Vetter wrote:
> On Sun, Jun 21, 2020 at 02:03:05AM -0400, Andrey Grodzovsky wrote:
> > Track sysfs files in a list so they all can be removed during pci remove
> > since otherwise their removal after that causes crash because parent
> > folder was al
Am 19.06.20 um 20:50 schrieb Paul Menzel:
Currently, besides there is no explicit message, that DPM is disabled.
The user would need to know, that the missing success line indicates
that.
[drm] amdgpu: dpm initialized
So, add an explicit message, and make it log level warning, as disabling
On Mon, 22 Jun 2020 11:35:01 +0200
Daniel Vetter wrote:
> On Sun, Jun 21, 2020 at 02:03:01AM -0400, Andrey Grodzovsky wrote:
> > Will be used to reroute CPU mapped BO's page faults once
> > device is removed.
> >
> > Signed-off-by: Andrey Grodzovsky
> > ---
> > drivers/gpu/drm/drm_file.c | 8
On Mon, Jun 22, 2020 at 3:18 PM Christian König
wrote:
>
> Am 21.06.20 um 08:03 schrieb Andrey Grodzovsky:
> > Will be used to reroute CPU mapped BO's page faults once
> > device is removed.
> >
> > Signed-off-by: Andrey Grodzovsky
> > ---
> > drivers/gpu/drm/drm_file.c | 8
> > dri
On Mon, Jun 22, 2020 at 4:22 PM Pekka Paalanen wrote:
>
> On Mon, 22 Jun 2020 11:35:01 +0200
> Daniel Vetter wrote:
>
> > On Sun, Jun 21, 2020 at 02:03:01AM -0400, Andrey Grodzovsky wrote:
> > > Will be used to reroute CPU mapped BO's page faults once
> > > device is removed.
> > >
> > > Signed-o
On Mon, 22 Jun 2020 16:24:38 +0200
Daniel Vetter wrote:
> On Mon, Jun 22, 2020 at 4:22 PM Pekka Paalanen wrote:
> >
> > On Mon, 22 Jun 2020 11:35:01 +0200
> > Daniel Vetter wrote:
> >
> > > On Sun, Jun 21, 2020 at 02:03:01AM -0400, Andrey Grodzovsky wrote:
> > > > Will be used to reroute CP
On 6/22/20 9:18 AM, Christian König wrote:
Am 21.06.20 um 08:03 schrieb Andrey Grodzovsky:
Will be used to reroute CPU mapped BO's page faults once
device is removed.
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/drm_file.c | 8
drivers/gpu/drm/drm_prime.c | 10 ++
Some basic nit-picks inline.
On 6/22/2020 7:34 AM, Chauhan, Ikshwaku wrote:
[AMD Official Use Only - Internal Distribution Only]
Hello All,
Could you please provide your feedback for this patch?
Regards,
Ikshwaku
-Original Message-
From: Chauhan, Ikshwaku
Sent: Wednesday, June 17, 2
On 6/22/20 7:21 AM, Greg KH wrote:
On Mon, Jun 22, 2020 at 11:51:24AM +0200, Daniel Vetter wrote:
On Sun, Jun 21, 2020 at 02:03:05AM -0400, Andrey Grodzovsky wrote:
Track sysfs files in a list so they all can be removed during pci remove
since otherwise their removal after that causes crash be
On Mon, Jun 22, 2020 at 12:07:25PM -0400, Andrey Grodzovsky wrote:
>
> On 6/22/20 7:21 AM, Greg KH wrote:
> > On Mon, Jun 22, 2020 at 11:51:24AM +0200, Daniel Vetter wrote:
> > > On Sun, Jun 21, 2020 at 02:03:05AM -0400, Andrey Grodzovsky wrote:
> > > > Track sysfs files in a list so they all can
Dear Christian,
Am 22.06.20 um 15:39 schrieb Christian König:
Am 19.06.20 um 20:50 schrieb Paul Menzel:
Currently, besides there is no explicit message, that DPM is disabled.
The user would need to know, that the missing success line indicates
that.
[drm] amdgpu: dpm initialized
So, add
Am 22.06.20 um 19:25 schrieb Paul Menzel:
Dear Christian,
Am 22.06.20 um 15:39 schrieb Christian König:
Am 19.06.20 um 20:50 schrieb Paul Menzel:
Currently, besides there is no explicit message, that DPM is disabled.
The user would need to know, that the missing success line indicates
that.
Am 22.06.20 um 16:32 schrieb Andrey Grodzovsky:
On 6/22/20 9:18 AM, Christian König wrote:
Am 21.06.20 um 08:03 schrieb Andrey Grodzovsky:
Will be used to reroute CPU mapped BO's page faults once
device is removed.
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/drm_file.c | 8 +
On Mon, Jun 22, 2020 at 7:45 PM Christian König
wrote:
>
> Am 22.06.20 um 16:32 schrieb Andrey Grodzovsky:
> >
> > On 6/22/20 9:18 AM, Christian König wrote:
> >> Am 21.06.20 um 08:03 schrieb Andrey Grodzovsky:
> >>> Will be used to reroute CPU mapped BO's page faults once
> >>> device is removed.
Your Signed-of-by line is missing and a one liner commit message would
be nice to have. Something like "Cleaning up radeon leftovers."
With that fixed the patch is Reviewed-by: Christian König
.
Am 18.06.20 um 00:00 schrieb Sonny Jiang:
---
drivers/gpu/drm/amd/amdgpu/sid.h | 7 ---
1
Am 18.06.20 um 09:53 schrieb Wenhui Sheng:
sdma v5_0 fw isn't released when module exit
Signed-off-by: Wenhui Sheng
---
drivers/gpu/drm/amd/amdgpu/sdma_v5_0.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/sdma_v5_0.c
b/drivers/gpu/drm/am
Am 21.06.20 um 08:03 schrieb Andrey Grodzovsky:
On device removal reroute all CPU mappings to dummy page per drm_file
instance or imported GEM object.
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/ttm/ttm_bo_vm.c | 65 -
1 file changed, 57 inser
Am 21.06.20 um 08:03 schrieb Andrey Grodzovsky:
Helper function to be used to invalidate all BOs CPU mappings
once device is removed.
Signed-off-by: Andrey Grodzovsky
Reviewed-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c| 8 ++--
include/drm/ttm/ttm_bo_driver.h | 7 +
Am 21.06.20 um 08:03 schrieb Andrey Grodzovsky:
Use the new TTM interface to invalidate all exsisting BO CPU mappings
form all user proccesses.
Signed-off-by: Andrey Grodzovsky
Reviewed-by: Christian König
I think those two patches could already land in amd-staging-drm-next
since they are
Am 21.06.20 um 08:03 schrieb Andrey Grodzovsky:
entity->rq becomes null aftre device unplugged so just return early
in that case.
Mhm, do you have a backtrace for this?
This should only be called by an IOCTL and IOCTLs should already call
drm_dev_enter()/exit() on their own...
Christian.
On Sun, Jun 21, 2020 at 2:05 AM Andrey Grodzovsky
wrote:
>
> Helper function to be used to invalidate all BOs CPU mappings
> once device is removed.
>
> Signed-off-by: Andrey Grodzovsky
Typo in the subject:
unampping -> unmapping
Alex
> ---
> drivers/gpu/drm/ttm/ttm_bo.c| 8 ++--
> i
On Mon, Jun 22, 2020 at 3:38 PM Christian König
wrote:
>
> Am 21.06.20 um 08:03 schrieb Andrey Grodzovsky:
> > Use the new TTM interface to invalidate all exsisting BO CPU mappings
> > form all user proccesses.
> >
> > Signed-off-by: Andrey Grodzovsky
>
> Reviewed-by: Christian König
>
> I think
If (smu)->ppt_funcs->intf is not initialized then
smu_send_smc_msg(smu, SMU_MSG_ReadSerialNumBottom32, &bottom32) and
smu_send_smc_msg(smu, SMU_MSG_ReadSerialNumTop32, &top32) will not
touch bottom32 and top32.
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/amd/powerplay/arcturus_ppt.c | 2 +-
1
On Mon, Jun 22, 2020 at 3:55 PM Nirmoy Das wrote:
>
> If (smu)->ppt_funcs->intf is not initialized then
> smu_send_smc_msg(smu, SMU_MSG_ReadSerialNumBottom32, &bottom32) and
> smu_send_smc_msg(smu, SMU_MSG_ReadSerialNumTop32, &top32) will not
> touch bottom32 and top32.
>
> Signed-off-by: Nirmoy D
On Mon, Jun 22, 2020 at 08:46:17AM -0300, Jason Gunthorpe wrote:
> On Fri, Jun 19, 2020 at 04:31:47PM -0400, Jerome Glisse wrote:
> > Not doable as page refcount can change for things unrelated to GUP, with
> > John changes we can identify GUP and we could potentialy copy GUPed page
> > instead of
This includes older APUs like renoir.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index f1855a8323b2..7d51768684dd 10
Dear Christian,
Am 22.06.20 um 19:41 schrieb Christian König:
Am 22.06.20 um 19:25 schrieb Paul Menzel:
Am 22.06.20 um 15:39 schrieb Christian König:
Am 19.06.20 um 20:50 schrieb Paul Menzel:
Currently, besides there is no explicit message, that DPM is disabled.
The user would need to know,
clk_s is checked twice in a row in ni_init_smc_spll_table().
fb_div should be checked instead.
Fixes: 69e0b57a91ad ("drm/radeon/kms: add dpm support for cayman (v5)")
Cc: sta...@vger.kernel.org
Signed-off-by: Denis Efremov
---
drivers/gpu/drm/radeon/ni_dpm.c | 2 +-
1 file changed, 1 insertion(+
drop the duplicate register macros from sid.h and use the
standard ones in the oss register headers.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/si.c| 1 +
drivers/gpu/drm/amd/amdgpu/si_ih.c | 2 ++
drivers/gpu/drm/amd/amdgpu/sid.h | 19 ---
3 files changed
On 6/22/20 12:45 PM, Greg KH wrote:
On Mon, Jun 22, 2020 at 12:07:25PM -0400, Andrey Grodzovsky wrote:
On 6/22/20 7:21 AM, Greg KH wrote:
On Mon, Jun 22, 2020 at 11:51:24AM +0200, Daniel Vetter wrote:
On Sun, Jun 21, 2020 at 02:03:05AM -0400, Andrey Grodzovsky wrote:
Track sysfs files in a l
On 6/22/20 5:45 AM, Daniel Vetter wrote:
On Sun, Jun 21, 2020 at 02:03:03AM -0400, Andrey Grodzovsky wrote:
Helper function to be used to invalidate all BOs CPU mappings
once device is removed.
Signed-off-by: Andrey Grodzovsky
This seems to be missing the code to invalidate all the dma-buf m
On 6/22/20 3:40 PM, Christian König wrote:
Am 21.06.20 um 08:03 schrieb Andrey Grodzovsky:
entity->rq becomes null aftre device unplugged so just return early
in that case.
Mhm, do you have a backtrace for this?
This should only be called by an IOCTL and IOCTLs should already call
drm_dev_e
I am fighting with Thunderbird to make limit a line to 80 chars but nothing
helps. Any suggestions please.
Andrey
On 6/22/20 5:46 AM, Daniel Vetter wrote:
Also a nit: Please tell your mailer to break long lines, it looks funny
and inconsistent otherwise, at least in some of the mailers I use h
63 matches
Mail list logo
