On Tue, Jun 16, 2020 at 2:07 PM Daniel Vetter wrote:
>
> Hi Jason,
>
> Somehow this got stuck somewhere in the mail queues, only popped up just
> now ...
>
> On Thu, Jun 11, 2020 at 11:15:15AM -0300, Jason Gunthorpe wrote:
> > On Thu, Jun 11, 2020 at 10:34:30AM +0200, Daniel Vetter wrote:
> > > >
To follow conventional style. And this unnecessary "@" confuses
our userspace tool.
Change-Id: Id4cdc611d63e800cf5a93449b6331a1e8323e727
Signed-off-by: Evan Quan
---
drivers/gpu/drm/amd/powerplay/navi10_ppt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd
I updated my system with Radeon VII from kernel 5.6 to kernel 5.7, and
following started to happen on each boot:
...
BUG: kernel NULL pointer dereference, address: 0128
...
CPU: 9 PID: 1940 Comm: modprobe Tainted: GE
5.7.2-200.im0.fc32.x
Hi, Peter,
On Mon, Jun 15, 2020 at 09:09:28PM +0200, Peter Zijlstra wrote:
> On Mon, Jun 15, 2020 at 11:55:29AM -0700, Fenghua Yu wrote:
>
> > Or do you suggest to add a random new flag in struct thread_info instead
> > of a TIF flag?
>
> Why thread_info? What's wrong with something simple like
[why]
The brightness input is in the range 0-255.It is getting scaled between
the requested min and max input signal and also scaled up by 0x101 to
match the DC interface which has a range of 0 to 0x. This scaled
brightness value is not rescaled back to original range(0-255) when
we reads it ba
On Tue, Jun 16, 2020 at 11:26 AM Tom St Denis wrote:
>
> Despite having different IP offsets the computed address of the register(s)
> are the same between gfx7..gfx10. This patch fixes the offset relative
> to the GC block on gfx10.
>
> (v2): SQ_DEBUG_STS_GLOBAL2 is 0x10 higher ...
>
> Signed-of
Despite having different IP offsets the computed address of the register(s)
are the same between gfx7..gfx10. This patch fixes the offset relative
to the GC block on gfx10.
(v2): SQ_DEBUG_STS_GLOBAL2 is 0x10 higher ...
Signed-off-by: Tom St Denis
---
drivers/gpu/drm/amd/include/asic_reg/gc/gc_
On Fri, Jun 12, 2020 at 05:41:29PM -0700, Fenghua Yu wrote:
> diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
> index 64ede5f150dc..5778db3aa42d 100644
> --- a/include/linux/mm_types.h
> +++ b/include/linux/mm_types.h
> @@ -538,6 +538,10 @@ struct mm_struct {
> atomic
Hi, Jean,
On Tue, Jun 16, 2020 at 10:28:19AM +0200, Jean-Philippe Brucker wrote:
> On Fri, Jun 12, 2020 at 05:41:29PM -0700, Fenghua Yu wrote:
> > diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
> > index 64ede5f150dc..5778db3aa42d 100644
> > --- a/include/linux/mm_types.h
> > +++
On Tue, Jun 16, 2020 at 02:07:19PM +0200, Daniel Vetter wrote:
> > > I've pinged a bunch of armsoc gpu driver people and ask them how much this
> > > hurts, so that we have a clear answer. On x86 I don't think we have much
> > > of a choice on this, with userptr in amd and i915 and hmm work in nouv
> -Original Message-
> From: Alex Deucher
> Sent: Tuesday, June 9, 2020 10:24 PM
>
> On Tue, Jun 9, 2020 at 5:18 AM Piotr Stankiewicz
> wrote:
> >
> > Seeing as there is shorthand available to use when asking for any type
> > of interrupt, or any type of message signalled interrupt, leve
> Fix memory leak in amdgpu_debugfs_gpr_read not freeing data when
> pm_runtime_get_sync failed.
* Would you like to improve the exception handling any more for this software
module?
* How do you think about calling the function “pm_runtime_put_noidle”?
Regards,
Markus
_
Ok, i will modify it in v2 patch.
On 2020/6/16 14:50, Christian König wrote:
Probably better to remove the duplication of result and r here and
then use "goto err".
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/m
pci_alloc_irq_vectors() will handle fallback from MSI-X to MSI
internally, if necessary. So remove checks which determine if we are
dealing with MSI or MSI-X and rely on pci_alloc_irq_vectors() to do the
right thing.
Signed-off-by: Piotr Stankiewicz
Reviewed-by: Andy Shevchenko
---
drivers/gpu/
Despite having different IP offsets the computed address of the register(s)
are the same between gfx7..gfx10. This patch fixes the offset relative
to the GC block on gfx10.
Signed-off-by: Tom St Denis
---
drivers/gpu/drm/amd/include/asic_reg/gc/gc_10_1_0_offset.h | 4 ++--
drivers/gpu/drm/amd/i
On Tue, Jun 16, 2020 at 06:29:37PM +0800, Kevin Wang wrote:
> v1: add the new macro "smu_ppt_xxx()" to unify smu callback interfaces
> v2: rename the macro smu_ppt_xxx to smu_ppt_funcs.
>
> Signed-off-by: Kevin Wang
> ---
Series look good for me.
Reviewed-by: Huang Rui
> drivers/gpu/drm/amd/
Hi Jason,
Somehow this got stuck somewhere in the mail queues, only popped up just
now ...
On Thu, Jun 11, 2020 at 11:15:15AM -0300, Jason Gunthorpe wrote:
> On Thu, Jun 11, 2020 at 10:34:30AM +0200, Daniel Vetter wrote:
> > > I still have my doubts about allowing fence waiting from within shrink
v1: add the new macro "smu_ppt_xxx()" to unify smu callback interfaces
v2: rename the macro smu_ppt_xxx to smu_ppt_funcs.
Signed-off-by: Kevin Wang
---
drivers/gpu/drm/amd/powerplay/smu_internal.h | 267 ++-
1 file changed, 82 insertions(+), 185 deletions(-)
diff --git a/drivers
the pptable_func callback sets should be has unify interface,
so use "smu" as the pptable_func interface first parameter.
fix interfaces:
1. i2c_eeprom_init
2. i2c_eeprom_fini
Signed-off-by: Kevin Wang
---
drivers/gpu/drm/amd/powerplay/arcturus_ppt.c | 4 ++--
drivers/gpu/drm/amd/powerplay/in
[AMD Public Use]
yes, i can rename the marco "smu_ppt_xxx" to "smu_ppt_funs".
but in kernel code, we can see the same code style, likes:
path: //include/linux/cred.h
#define task_cred_xxx(task, xxx)\
({ \
__typeof
[AMD Public Use]
The naming style smu_ppt_xxx makes me confusing. at first glance, I thought
you just have some dummy code or the patch is something still working in
progress. It would be better to rename it to smu_ppt_funcs.
Regards,
Hawking
-Original Message-
From: Wang, Kevin(Ya
On Mon, Jun 15, 2020 at 01:17:35PM -0700, Fenghua Yu wrote:
> Hi, Peter,
>
> On Mon, Jun 15, 2020 at 09:09:28PM +0200, Peter Zijlstra wrote:
> > On Mon, Jun 15, 2020 at 11:55:29AM -0700, Fenghua Yu wrote:
> >
> > > Or do you suggest to add a random new flag in struct thread_info instead
> > > of
Hi, Baolu,
On Sat, Jun 13, 2020 at 08:17:40PM +0800, Lu Baolu wrote:
> Hi Fenghua,
>
> On 2020/6/13 8:41, Fenghua Yu wrote:
> >+implement implement fairness or ensure forward progress can be made.
>
> Repeated "implement".
Will fix this.
> >+For example, the Intel Data Streaming Accelerator (D
Fix memory leak in amdgpu_debugfs_gpr_read not freeing data when
amdgpu_virt_enable_access_debugfs failed.
Fixes: 95a2f917387a2 ("drm/amdgpu: restrict debugfs register accessunder
SR-IOV")
Signed-off-by: Chen Tao
---
drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 4 +++-
1 file changed, 3 insert
Fix memory leak in amdgpu_debugfs_gpr_read not freeing data when
pm_runtime_get_sync failed.
Fixes: a9ffe2a983383 ("drm/amdgpu/debugfs: properly handle runtime pm")
Signed-off-by: Chen Tao
---
drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
d
Have you tried a much later kernel btw? I saw you mentioned 4.19.
Den tis 16 juni 2020 kl 02:50 skrev Aaron Chou :
> Yes, I agree.
>
> On Tue, Jun 16, 2020 at 3:08 AM Alex Deucher
> wrote:
> >
> > On Mon, Jun 15, 2020 at 5:30 AM Aaron Chou
> wrote:
> > >
> > > About one month ago, I have asked
the pptable_func callback sets should be has unify interface,
so use "smu" as the pptable_func interface first parameter.
fix interfaces:
1. i2c_eeprom_init
2. i2c_eeprom_fini
Signed-off-by: Kevin Wang
---
drivers/gpu/drm/amd/powerplay/arcturus_ppt.c | 4 ++--
drivers/gpu/drm/amd/powerplay/in
add the new macro "smu_ppt_xxx()" to unify smu callback interfaces
Signed-off-by: Kevin Wang
---
drivers/gpu/drm/amd/powerplay/smu_internal.h | 266 ++-
1 file changed, 82 insertions(+), 184 deletions(-)
diff --git a/drivers/gpu/drm/amd/powerplay/smu_internal.h
b/drivers/gpu/dr
28 matches
Mail list logo
