Am 08.02.21 um 23:15 schrieb Andrey Grodzovsky:
On 2/8/21 11:23 AM, Daniel Vetter wrote:
On Mon, Feb 8, 2021 at 3:00 PM Christian König
wrote:
Am 08.02.21 um 11:11 schrieb Daniel Vetter:
On Mon, Feb 08, 2021 at 11:03:15AM +0100, Christian König wrote:
Am 08.02.21 um 10:48 schrieb Daniel Ve
The usage of in_interrupt() in gmc_v*_process_interrupt() is intended to
use a different code path if invoked from the interrupt handler vs
invoked from the workqueue.
The usage of in_interrupt() in drivers is phased out and Linus clearly
requested that code which changes behaviour depending on co
Folks,
in the discussion about preempt count consistency across kernel
configurations:
https://lore.kernel.org/r/20200914204209.256266...@linutronix.de/
it was concluded that the usage of in_interrupt() and related context
checks should be removed from non-core code.
In the long run, usage of
gfx_v8_0_parse_sq_irq() is using in_task() to distinguish if it is
invoked from a workqueue worker or directly from the interrupt handler.
The usage of in_interrupt() in drivers is phased out and Linus clearly
requested that code which changes behaviour depending on context should
either be separa
gfx_v9_0_get_gpu_clock_counter() acquires a mutex_t lock and is the only
caller of gfx_v9_0_kiq_read_clock().
If it safe to acquire a mutex_t then gfx_v9_0_get_gpu_clock_counter() is
always invoked from preemptible context.
Remove in_interrupt() because it superfluous as it will always return
fals
вт, 9 февр. 2021 г. в 02:43, Alex Deucher :
>
> On Mon, Feb 8, 2021 at 1:34 AM Alexander E. Patrakov
> wrote:
> >
> > пн, 8 февр. 2021 г. в 08:32, Alexander E. Patrakov :
> > >
> > > чт, 4 февр. 2021 г. в 09:31, Alex Deucher :
> > > >
> > > > On Wed, Feb 3, 2021 at 7:56 PM Eric W. Biederman
> >
The driver is using msleep() if it is safe to use based on in_atomic().
This is not needed this macro is only used from
i2c_algorithm::master_xfer() which is always invoked from preemptible
context.
Remove in_atomic() because it is superfluous. Remove wait_for_atomic()
because it has no users.
Si
The amdgou changes look mostly good to me.
But please send them out as separate patch set than the gma500 changes
and please simplify boolean checks and don't use "x == true" or "x ==
false".
Regards,
Christian.
Am 09.02.21 um 00:31 schrieb Sebastian Andrzej Siewior:
Folks,
in the discussi
Am 08.02.21 um 23:09 schrieb Andrey Grodzovsky:
On 2/8/21 4:37 AM, Christian König wrote:
Am 07.02.21 um 22:50 schrieb Daniel Vetter:
[SNIP]
Clarification - as far as I know there are no page fault handlers
for kernel
mappings. And we are talking about kernel mappings here, right ?
If th
On Tue, Feb 09, 2021 at 09:27:03AM +0100, Christian König wrote:
>
>
> Am 08.02.21 um 23:09 schrieb Andrey Grodzovsky:
> >
> >
> > On 2/8/21 4:37 AM, Christian König wrote:
> > > Am 07.02.21 um 22:50 schrieb Daniel Vetter:
> > > > [SNIP]
> > > > > Clarification - as far as I know there are no p
On Mon, Feb 08, 2021 at 11:01:14PM -0500, Andrey Grodzovsky wrote:
>
> On 2/8/21 2:27 AM, Daniel Vetter wrote:
> > On Mon, Feb 8, 2021 at 6:59 AM Andrey Grodzovsky
> > wrote:
> > >
> > > On 1/20/21 10:59 AM, Daniel Vetter wrote:
> > > > On Wed, Jan 20, 2021 at 3:20 PM Andrey Grodzovsky
> > > >
On Tue, Feb 09, 2021 at 12:31:16AM +0100, Sebastian Andrzej Siewior wrote:
> The driver is using msleep() if it is safe to use based on in_atomic().
> This is not needed this macro is only used from
> i2c_algorithm::master_xfer() which is always invoked from preemptible
> context.
>
> Remove in_at
On Tue, Jan 26, 2021 at 01:46:25PM -0800, Brian Welty wrote:
> This patch adds tracking of which cgroup to make charges against for a
> given GEM object. We associate the current task's cgroup with GEM objects
> as they are created. First user of this is for charging DRM cgroup for
> device memor
Reviewed-by: Christian König for the series.
Am 09.02.21 um 13:44 schrieb Sebastian Andrzej Siewior:
Folks,
in the discussion about preempt count consistency across kernel
configurations:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Fr%2F20200914204209
On 2/9/21 2:58 AM, Christian König wrote:
Am 08.02.21 um 23:15 schrieb Andrey Grodzovsky:
On 2/8/21 11:23 AM, Daniel Vetter wrote:
On Mon, Feb 8, 2021 at 3:00 PM Christian König
wrote:
Am 08.02.21 um 11:11 schrieb Daniel Vetter:
On Mon, Feb 08, 2021 at 11:03:15AM +0100, Christian König wr
Remove NULL checks before vfree() to fix these warnings:
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c:102:2-8: WARNING: NULL
check before some freeing functions is not needed.
Signed-off-by: Tian Tao
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
di
gfx_v8_0_parse_sq_irq() is using in_task() to distinguish if it is
invoked from a workqueue worker or directly from the interrupt handler.
The usage of in_interrupt() in drivers is phased out and Linus clearly
requested that code which changes behaviour depending on context should
either be separa
Folks,
in the discussion about preempt count consistency across kernel
configurations:
https://lore.kernel.org/r/20200914204209.256266...@linutronix.de/
it was concluded that the usage of in_interrupt() and related context
checks should be removed from non-core code.
In the long run, usage of
gfx_v9_0_get_gpu_clock_counter() acquires a mutex_t lock and is the only
caller of gfx_v9_0_kiq_read_clock().
If it safe to acquire a mutex_t then gfx_v9_0_get_gpu_clock_counter() is
always invoked from preemptible context.
Remove in_interrupt() because it superfluous as it will always return
fals
The usage of in_interrupt() in gmc_v*_process_interrupt() is intended to
use a different code path if invoked from the interrupt handler vs
invoked from the workqueue.
The usage of in_interrupt() in drivers is phased out and Linus clearly
requested that code which changes behaviour depending on co
On 2/9/21 4:50 AM, Daniel Vetter wrote:
On Mon, Feb 08, 2021 at 11:01:14PM -0500, Andrey Grodzovsky wrote:
On 2/8/21 2:27 AM, Daniel Vetter wrote:
On Mon, Feb 8, 2021 at 6:59 AM Andrey Grodzovsky
wrote:
On 1/20/21 10:59 AM, Daniel Vetter wrote:
On Wed, Jan 20, 2021 at 3:20 PM Andrey Grodzo
Am 09.02.21 um 15:30 schrieb Andrey Grodzovsky:
[SNIP]
Question - Why can't we just set those PTEs to point to system
memory (another RO dummy page)
filled with 1s ?
Then writes are not discarded. E.g. the 1s would change to something
else.
Christian.
I see but, what about marking the
On 2021-02-09 13:50:31 [+0100], Christian König wrote:
> Reviewed-by: Christian König for the series.
Thank you.
Any chance you could give me a hand with the remaining three users
within the amdgpu driver? I don't know if the in_interrupt() check can
be limited to certain callers.
What I noticed
[AMD Official Use Only - Internal Distribution Only]
We should try and the behavior as consistent as possible.
Thanks!
Alex
From: Wang, Kevin(Yang)
Sent: Tuesday, February 9, 2021 12:27 AM
To: Huang, Ray ; Du, Xiaojian ;
amd-gfx@lists.freedesktop.org ; Deucher
Hi Sebastian,
to be honest I'm thinking about that for quite some time now and I don't
think that this is possible without a severe rewrite of the driver.
The problem is simply that we have a lot of functions which deal with
hardware handling independent of the context. But how registers are
On Mon, 8 Feb 2021 at 14:18, Christian König
wrote:
>
> Are the other problems gone as well?
>
And yes and no.
The issue with monitor turns off was gone after rc6 (git3aaf0a27ffc2)
But both traces
1) BUG: sleeping function called from invalid context at
include/linux/sched/mm.h:196 (kernel 5.11 s
On Tue, Feb 9, 2021 at 3:44 AM Tian Tao wrote:
>
> Remove NULL checks before vfree() to fix these warnings:
> drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c:102:2-8: WARNING: NULL
> check before some freeing functions is not needed.
>
> Signed-off-by: Tian Tao
Applied. Thanks!
Alex
> ---
> drivers/
Applied. Thanks!
Alex
On Mon, Feb 8, 2021 at 5:29 AM Jiapeng Chong
wrote:
>
> Fix the following coccicheck warning:
>
> ./drivers/gpu/drm/amd/display/dc/inc/hw/clk_mgr_internal.h:319:11-23:
> WARNING: Comparison to bool.
>
> Reported-by: Abaci Robot
> Signed-off-by: Jiapeng Chong
> ---
> dri
Applied. Thanks!
Alex
On Mon, Feb 8, 2021 at 5:17 AM Jiapeng Chong
wrote:
>
> Fix the following coccicheck warning:
>
> ./drivers/gpu/drm/radeon/rs690.c:190:6-35: WARNING: Comparison to bool.
>
> Reported-by: Abaci Robot
> Signed-off-by: Jiapeng Chong
> ---
> drivers/gpu/drm/radeon/rs690.c |
Constify a few static vm_operations_struct that are never modified. Their
only usage is to assign their address to the vm_ops field in the
vm_area_struct, which is a pointer to const vm_operations_struct. Make them
const to allow the compiler to put them in read-only memory.
With this series appli
The only usage of nouveau_ttm_vm_ops is to assign its address to the
vm_ops field in the vm_area_struct struct. Make it const to allow the
compiler to put it in read-only memory
Signed-off-by: Rikard Falkeborn
---
drivers/gpu/drm/nouveau/nouveau_ttm.c | 2 +-
1 file changed, 1 insertion(+), 1 de
The only usage of radeon_ttm_vm_ops is to assign its address to the
vm_ops field in the vm_area_struct struct. Make it const to allow the
compiler to put it in read-only memory
Signed-off-by: Rikard Falkeborn
---
drivers/gpu/drm/radeon/radeon_ttm.c | 2 +-
1 file changed, 1 insertion(+), 1 delet
The only usage of amdgpu_ttm_vm_ops is to assign its address to the
vm_ops field in the vm_area_struct struct. Make it const to allow the
compiler to put it in read-only memory.
Signed-off-by: Rikard Falkeborn
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 2 +-
1 file changed, 1 insertion(+), 1
From: youling 257
This patch cause replug hdmi blackscreen,
https://bugzilla.kernel.org/show_bug.cgi?id=211649
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
We should commit the value after restore them back to default as well.
$ echo "r" > pp_od_clk_voltage
$ echo "c" > pp_od_clk_voltage
Signed-off-by: Huang Rui
---
.../drm/amd/pm/powerplay/hwmgr/smu10_hwmgr.c | 14 ---
.../gpu/drm/amd/pm/swsmu/smu11/vangogh_ppt.c | 38 ---
2
On Tue, Feb 9, 2021 at 11:02 PM youling257 wrote:
>
> From: youling 257
>
> This patch cause replug hdmi blackscreen,
> https://bugzilla.kernel.org/show_bug.cgi?id=211649
Can you test with my drm-next branch:
https://gitlab.freedesktop.org/agd5f/linux/-/commits/drm-next
Are you able to repro th
Reviewed-by: Christian König for the series.
Am 10.02.21 um 00:48 schrieb Rikard Falkeborn:
Constify a few static vm_operations_struct that are never modified. Their
only usage is to assign their address to the vm_ops field in the
vm_area_struct, which is a pointer to const vm_operations_struct
Hi
Am 09.02.21 um 11:54 schrieb Daniel Vetter:
*: vmwgfx is the only non-gem driver, but there's plans to move at least
vmwgfx internals (maybe not the uapi, we'll see) over to gem. Once that's
done it's truly all gpu memory.
Do you have a URL to the discussion?
While I recent worked on GEM,
38 matches
Mail list logo
