Re: AMD DC graphics display code enables -mhard-float, -msse, -msse2 without any visible FPU state protection

2020-04-03 Thread Masami Hiramatsu
On Fri, 3 Apr 2020 13:21:13 +0200
Peter Zijlstra  wrote:

> On Fri, Apr 03, 2020 at 02:28:37PM +0900, Masami Hiramatsu wrote:
> > On Thu, 2 Apr 2020 16:13:08 +0200
> > Peter Zijlstra  wrote:
> 
> > > Masami, Boris, is there any semi-sane way we can have insn_is_fpu() ?
> > > While digging through various opcode manuals is of course forever fun, I
> > > do feel like it might not be the best way.
> > 
> > Yes, it is possible to add INAT_FPU and insn_is_fpu().
> > But it seems that the below patch needs more classification based on
> > nmemonic or opcodes.
> 
> I went with opcode, and I think I did a fairly decent job, but I did
> find a few problems on a second look at things.
> 
> I don't think nmemonic are going to help, the x86 nmemonics are a mess
> (much like its opcode tables), there's no way to sanely detect what
> registers are effected by an instruction based on name.
> 
> The best I came up with is operand class, see below.

Yeah, so we need another map, current inat map is optimized for
decoding, and lack of some information for reducing size.
E.g. it mixed up the VEX prefix instruction with non-VEX one.

> 
> > IMHO, it is the time to expand gen-insn-attr.awk or clone it to
> > generate another opcode map, so that user will easily extend the
> > insn infrastructure.
> > (e.g. I had made an in-kernel disassembler, which generates a mnemonic
> >  maps from x86-opcode-map.txt)
> >  https://github.com/mhiramat/linux/commits/inkernel-disasm-20130414
> 
> Cute, and I'm thinking we might want that eventually, people have been
> asking for a kernel specific objdump, one that knows about and shows all
> the magical things the kernel does, like alternative, jump-labels and
> soon the static_call stuff, but also things like the exception handling.
> 
> Objtool actually knows about much of that, and pairing it with your
> disassembler could print it.
> 
> > > + if (insn.vex_prefix.nbytes) {
> > > + *type = INSN_FPU;
> > >   return 0;
> > > + }
> 
> So that's the AVX nonsense dealt with; right until they stick an integer
> instruction in the AVX space I suppose :/ Please tell me they didn't
> already do that..

I'm not so sure.
Theoretically, x86 instruction can be encoded with VEX prefix instead of
REX prefix (most compiler may not output such inefficient code.)

> > >   op1 = insn.opcode.bytes[0];
> > >   op2 = insn.opcode.bytes[1];
> > > @@ -357,48 +359,71 @@ int arch_decode_instruction(struct elf *elf, struct 
> > > section *sec,
> > >  
> > >   case 0x0f:
> > >  
> > > + switch (op2) {
> 
> > > + case 0xae:
> > > + /* insane!! */
> > > + if ((modrm_reg >= 0 && modrm_reg <= 3) && modrm_mod != 
> > > 3 && !insn.prefixes.nbytes)
> > > + *type = INSN_FPU;
> > > + break;
> 
> This is crazy, but I was trying to get at the x86 FPU control
> instructions:
> 
>   FXSAVE, FXRSTOR, LDMXCSR and STMXCSR
> 
> Which are in Grp15

Yes, that is a complex part.

> Now arguably, I could skip them, the compiler should never emit those,
> and the newer, fancier, XSAV family isn't marked as FPU either, even
> though it will save/restore the FPU/MMX/SSE/AVX states too.
> 
> So I think I'll remove this part, it'll also make the fpu_safe
> annotations easier.
> 
> > > + case 0x10 ... 0x17:
> > > + case 0x28 ... 0x2f:
> > > + case 0x3a:
> > > + case 0x50 ... 0x77:
> > > + case 0x7a ... 0x7f:
> > > + case 0xc2:
> > > + case 0xc4 ... 0xc6:
> > > + case 0xd0 ... 0xff:
> > > + /* MMX, SSE, VMX */
> 
> So afaict these are the MMX and SSE instruction (clearly the VMX is my
> brain loosing it).
> 
> I went with the coder64 opcode tables, but our x86-opcode-map.txt seems
> to agree, mostly.
> 
> I now see that 0f 3a is not all mmx/sse, it also includes RORX which is
> an integer instruction. Also, may I state that the opcode map is a
> sodding disgrace? Why is an integer instruction stuck in the middle of
> SSE instructions like that ?!?!
> 
> And I should shorten the last range to 0xd0 ... 0xfe, as 0f ff is UD0.
> 
> Other than that I think this is pretty accurate.
> 
> > > + *type = INSN_FPU;
> > > + break;
> > > +
> > > + default:
> > > + break;
> > > + }
> > >   break;
> > >  
> > >   case 0xc9:
> > > @@ -414,6 +439,10 @@ int arch_decode_instruction(struct elf *elf, struct 
> > > section *sec,
> > >  
> > >   break;
> > >  
> > > + case 0xd8 ... 0xdf: /* x87 FPU range */
> > > + *type = INSN_FPU;
> > > + break;
> 
> Our x86-opcode-map.txt lists that as ESC, but doesn't have an escape
> table for it. Per:
> 
>   http://ref.x86asm.net/coder64.html
> 
> these are all the traditional x87 FPU ops.

Yes, for decoding, we don't need those tables.

> > > +
> > >   case 0xe3:
> > >   /* jecxz/jrcxz */
> > >   *type = INSN_JUMP_CONDITIONAL;
> 
> 
> 

Re: [PATCH] drm/amdgpu: Re-enable FRU check for most models v3

2020-04-03 Thread Alex Deucher
On Fri, Apr 3, 2020 at 5:02 PM Russell, Kent  wrote:
>
> [AMD Official Use Only - Internal Distribution Only]
>
> > -Original Message-
> > From: Alex Deucher 
> > Sent: Friday, April 3, 2020 4:51 PM
> > To: Russell, Kent 
> > Cc: amd-gfx list 
> > Subject: Re: [PATCH] drm/amdgpu: Re-enable FRU check for most models v3
> >
> > On Fri, Apr 3, 2020 at 1:09 PM Kent Russell  wrote:
> > >
> > > There are 2 VG20 SKUs that do not have the FRU on there, and trying to
> > > read that will cause a hang. For now, check for the gaming SKU until a
> > > proper fix can be implemented. This re-enables serial number reporting
> > > for server cards
> > >
> > > v2: Add ASIC check
> > > v3: Don't default to true for pre-VG10
> > >
> > > Signed-off-by: Kent Russell 
> > > ---
> > >  .../gpu/drm/amd/amdgpu/amdgpu_fru_eeprom.c| 22
> > +--
> > >  1 file changed, 20 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_fru_eeprom.c
> > > b/drivers/gpu/drm/amd/amdgpu/amdgpu_fru_eeprom.c
> > > index bfe4259f9508..508906177cad 100644
> > > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_fru_eeprom.c
> > > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_fru_eeprom.c
> > > @@ -31,9 +31,27 @@
> > >
> > >  bool is_fru_eeprom_supported(struct amdgpu_device *adev)  {
> > > -   /* TODO: Resolve supported ASIC type */
> > > +   struct atom_context *atom_ctx = adev->mode_info.atom_context;
> > >
> > > -   return false;
> > > +   if (!atom_ctx)
> > > +   return false;
> > > +
> > > +   /* TODO: Gaming SKUs don't have the FRU EEPROM.
> > > +* Use this to address hangs on modprobe on gaming SKUs
> > > +* until a proper solution can be implemented
> > > +*/
> > > +   switch (adev->asic_type) {
> > > +   case CHIP_VEGA20:
> > > +   if (strnstr(atom_ctx->vbios_version, "D360",
> > > +   sizeof(atom_ctx->vbios_version)))
> > > +   return false;
> >
> > Most skus are separated by pci revision ids.  Maybe it would be more
> > reliable to check that than a vbios string?
> I can look into that. This was really meant as a temporary workaround until 
> we found the right way to poll the card altogether. I lifted this from John 
> Clements' patch to isolate the D342 variant of Arcturus due to that whole 
> EEPROM addressing thing. I'll see if I can find the revision IDs for those 
> and see if they can be used instead. Maybe I can use that for John's D342 
> check as well.

In that case, we have two of the same sku, but with different EEPROM
chips, so the vbios version was the only thing we could use to
differentiate.  Really the EEPROM stuff should live in a vbios table
so we can query it.  For the pci revision id, in most cases there are
different revision ids for each sku.  There are generally more client
skus than server skus, so it's probably best to match on the server
sku and return true in that case.  I think the same logic also makes
sense if you end up having to use the vbios version (i.e., reverse the
current logic in this hunk of the patch).  I'd prefer to match the
vbios version of the server skus and return true for them and false
for everything else because I'm not sure what the vbios string will be
on AIB boards.  The DXXX naming is an AMD thing as far I know.

Alex

>
>
> >
> > Alex
> >
> >
> > > +   return true;
> > > +   case CHIP_ARCTURUS:
> > > +   /* There are no gaming Arcturus SKUs */
> > > +   return true;
> > > +   default:
> > > +   return false;
> > > +   }
> > >  }
> > >
> > >  int amdgpu_fru_read_eeprom(struct amdgpu_device *adev, uint32_t
> > addrptr,
> > > --
> > > 2.17.1
> > >
> > > ___
> > > amd-gfx mailing list
> > > amd-gfx@lists.freedesktop.org
> > >
> > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.fr
> > eedesktop.org%2Fmailman%2Flistinfo%2Famd-
> > gfxdata=02%7C01%7Ckent.russell%40amd.com%7Cd1d72c89825549c6f
> > 06e08d7d810c83e%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C6
> > 37215438899199940sdata=BnHE%2BT8D0j%2BHKD7s9J%2BXePsSYcXLG
> > bEYkmawDv3GNbw%3Dreserved=0
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


RE: [PATCH] drm/amdgpu: Re-enable FRU check for most models v3

2020-04-03 Thread Russell, Kent
[AMD Official Use Only - Internal Distribution Only]

> -Original Message-
> From: Alex Deucher 
> Sent: Friday, April 3, 2020 4:51 PM
> To: Russell, Kent 
> Cc: amd-gfx list 
> Subject: Re: [PATCH] drm/amdgpu: Re-enable FRU check for most models v3
> 
> On Fri, Apr 3, 2020 at 1:09 PM Kent Russell  wrote:
> >
> > There are 2 VG20 SKUs that do not have the FRU on there, and trying to
> > read that will cause a hang. For now, check for the gaming SKU until a
> > proper fix can be implemented. This re-enables serial number reporting
> > for server cards
> >
> > v2: Add ASIC check
> > v3: Don't default to true for pre-VG10
> >
> > Signed-off-by: Kent Russell 
> > ---
> >  .../gpu/drm/amd/amdgpu/amdgpu_fru_eeprom.c| 22
> +--
> >  1 file changed, 20 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_fru_eeprom.c
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_fru_eeprom.c
> > index bfe4259f9508..508906177cad 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_fru_eeprom.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_fru_eeprom.c
> > @@ -31,9 +31,27 @@
> >
> >  bool is_fru_eeprom_supported(struct amdgpu_device *adev)  {
> > -   /* TODO: Resolve supported ASIC type */
> > +   struct atom_context *atom_ctx = adev->mode_info.atom_context;
> >
> > -   return false;
> > +   if (!atom_ctx)
> > +   return false;
> > +
> > +   /* TODO: Gaming SKUs don't have the FRU EEPROM.
> > +* Use this to address hangs on modprobe on gaming SKUs
> > +* until a proper solution can be implemented
> > +*/
> > +   switch (adev->asic_type) {
> > +   case CHIP_VEGA20:
> > +   if (strnstr(atom_ctx->vbios_version, "D360",
> > +   sizeof(atom_ctx->vbios_version)))
> > +   return false;
> 
> Most skus are separated by pci revision ids.  Maybe it would be more
> reliable to check that than a vbios string?
I can look into that. This was really meant as a temporary workaround until we 
found the right way to poll the card altogether. I lifted this from John 
Clements' patch to isolate the D342 variant of Arcturus due to that whole 
EEPROM addressing thing. I'll see if I can find the revision IDs for those and 
see if they can be used instead. Maybe I can use that for John's D342 check as 
well.


> 
> Alex
> 
> 
> > +   return true;
> > +   case CHIP_ARCTURUS:
> > +   /* There are no gaming Arcturus SKUs */
> > +   return true;
> > +   default:
> > +   return false;
> > +   }
> >  }
> >
> >  int amdgpu_fru_read_eeprom(struct amdgpu_device *adev, uint32_t
> addrptr,
> > --
> > 2.17.1
> >
> > ___
> > amd-gfx mailing list
> > amd-gfx@lists.freedesktop.org
> >
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.fr
> eedesktop.org%2Fmailman%2Flistinfo%2Famd-
> gfxdata=02%7C01%7Ckent.russell%40amd.com%7Cd1d72c89825549c6f
> 06e08d7d810c83e%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C6
> 37215438899199940sdata=BnHE%2BT8D0j%2BHKD7s9J%2BXePsSYcXLG
> bEYkmawDv3GNbw%3Dreserved=0
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


Re: [PATCH] drm/amdgpu: Re-enable FRU check for most models v3

2020-04-03 Thread Alex Deucher
On Fri, Apr 3, 2020 at 1:09 PM Kent Russell  wrote:
>
> There are 2 VG20 SKUs that do not have the FRU on there, and trying to read
> that will cause a hang. For now, check for the gaming SKU until a proper
> fix can be implemented. This re-enables serial number reporting for
> server cards
>
> v2: Add ASIC check
> v3: Don't default to true for pre-VG10
>
> Signed-off-by: Kent Russell 
> ---
>  .../gpu/drm/amd/amdgpu/amdgpu_fru_eeprom.c| 22 +--
>  1 file changed, 20 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_fru_eeprom.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_fru_eeprom.c
> index bfe4259f9508..508906177cad 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_fru_eeprom.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_fru_eeprom.c
> @@ -31,9 +31,27 @@
>
>  bool is_fru_eeprom_supported(struct amdgpu_device *adev)
>  {
> -   /* TODO: Resolve supported ASIC type */
> +   struct atom_context *atom_ctx = adev->mode_info.atom_context;
>
> -   return false;
> +   if (!atom_ctx)
> +   return false;
> +
> +   /* TODO: Gaming SKUs don't have the FRU EEPROM.
> +* Use this to address hangs on modprobe on gaming SKUs
> +* until a proper solution can be implemented
> +*/
> +   switch (adev->asic_type) {
> +   case CHIP_VEGA20:
> +   if (strnstr(atom_ctx->vbios_version, "D360",
> +   sizeof(atom_ctx->vbios_version)))
> +   return false;

Most skus are separated by pci revision ids.  Maybe it would be more
reliable to check that than a vbios string?

Alex


> +   return true;
> +   case CHIP_ARCTURUS:
> +   /* There are no gaming Arcturus SKUs */
> +   return true;
> +   default:
> +   return false;
> +   }
>  }
>
>  int amdgpu_fru_read_eeprom(struct amdgpu_device *adev, uint32_t addrptr,
> --
> 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


Re: [PATCH] drm/amdgpu: Fix oops when pp_funcs is unset in ACPI event

2020-04-03 Thread Alex Deucher
On Fri, Apr 3, 2020 at 11:18 AM Aaron Ma  wrote:
>
> On ARCTURUS and RENOIR, powerplay is not supported yet.
> When plug in or unplug power jack, ACPI event will issue.
> Then kernel NULL pointer BUG will be triggered.
> Check for NULL pointers before calling.
>
> Signed-off-by: Aaron Ma 

Applied.  Thanks!

Alex


> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
> index f197f1be0969..611de69f9d48 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
> @@ -89,7 +89,8 @@ void amdgpu_pm_acpi_event_handler(struct amdgpu_device 
> *adev)
> adev->pm.ac_power = true;
> else
> adev->pm.ac_power = false;
> -   if (adev->powerplay.pp_funcs->enable_bapm)
> +   if (adev->powerplay.pp_funcs &&
> +   adev->powerplay.pp_funcs->enable_bapm)
> amdgpu_dpm_enable_bapm(adev, adev->pm.ac_power);
> mutex_unlock(>pm.mutex);
>
> --
> 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


Re: [PATCH] drm/amd/display: Fix a compilation warning

2020-04-03 Thread Markus Elfring
> When I compile the code in X86,there is a warning about
> "'PixelPTEReqHeightPTES' may be used uninitialized in this function".

Would you like to add the tag “Fixes” to the commit message?

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


Re: [PATCH] drm/amdgpu/sriov add amdgpu_amdkfd_pre_reset in gpu reset

2020-04-03 Thread Felix Kuehling
Please separate the two fixes into separate commits.

I'd like to see a better explanation for the changes in
kgd_hqd_destroy.  The GFX9 version already has a return -EIO in case
it's in a GPU reset. I would agree with porting that to GFX10. But why
do we need to return 0 only in the SRIOV case?

Regards,
  Felix

Am 2020-04-03 um 1:02 a.m. schrieb Jack Zhang:
> kfd_pre_reset will free mem_objs allocated by kfd_gtt_sa_allocate
>
> Without this change, sriov tdr code path will never free those allocated
> memories and get memory leak.
>
> v2:add a bugfix for kiq ring test fail
>
> Signed-off-by: Jack Zhang 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10.c | 3 +++
>  drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.c  | 3 +++
>  drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 2 ++
>  3 files changed, 8 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10.c
> index 4ec6d0c..bdc1f5a 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10.c
> @@ -543,6 +543,9 @@ static int kgd_hqd_destroy(struct kgd_dev *kgd, void *mqd,
>   uint32_t temp;
>   struct v10_compute_mqd *m = get_mqd(mqd);
>  
> + if (amdgpu_sriov_vf(adev) && adev->in_gpu_reset)
> + return 0;
> +
>  #if 0
>   unsigned long flags;
>   int retry;
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.c
> index df841c2..c2562d6 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.c
> @@ -541,6 +541,9 @@ int kgd_gfx_v9_hqd_destroy(struct kgd_dev *kgd, void *mqd,
>   uint32_t temp;
>   struct v9_mqd *m = get_mqd(mqd);
>  
> + if (amdgpu_sriov_vf(adev) && adev->in_gpu_reset)
> + return 0;
> +
>   if (adev->in_gpu_reset)
>   return -EIO;
>  
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> index 8faaa17..e3f7441 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> @@ -3854,6 +3854,8 @@ static int amdgpu_device_reset_sriov(struct 
> amdgpu_device *adev,
>   if (r)
>   return r;
>  
> + amdgpu_amdkfd_pre_reset(adev);
> +
>   /* Resume IP prior to SMC */
>   r = amdgpu_device_ip_reinit_early_sriov(adev);
>   if (r)
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


[PATCH] PCI/P2PDMA: Add additional AMD ZEN root ports to the whitelist

2020-04-03 Thread Alex Deucher
According to the hw architect, pre-ZEN parts support
p2p writes and ZEN parts support both p2p reads and writes.

Add entries for Zen parts Raven (0x15d0) and Renoir (0x1630).

Cc: Christian König 
Signed-off-by: Alex Deucher 
---
 drivers/pci/p2pdma.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/pci/p2pdma.c b/drivers/pci/p2pdma.c
index 9a8a38384121..91a4c987399d 100644
--- a/drivers/pci/p2pdma.c
+++ b/drivers/pci/p2pdma.c
@@ -282,6 +282,8 @@ static const struct pci_p2pdma_whitelist_entry {
 } pci_p2pdma_whitelist[] = {
/* AMD ZEN */
{PCI_VENDOR_ID_AMD, 0x1450, 0},
+   {PCI_VENDOR_ID_AMD, 0x15d0, 0},
+   {PCI_VENDOR_ID_AMD, 0x1630, 0},
 
/* Intel Xeon E5/Core i7 */
{PCI_VENDOR_ID_INTEL,   0x3c00, REQ_SAME_HOST_BRIDGE},
-- 
2.25.1

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


RE: [PATCH v2] drm/amdkfd: Provide SMI events watch

2020-04-03 Thread Kuehling, Felix
[AMD Official Use Only - Internal Distribution Only]

So are you saying you'll make the event descriptions text rather than binary?

If you switch to a text format, I wouldn't use a binary header. Rather I'd make 
it a text format completely. You could use one line per event, that makes it 
easy to use something like fgets to read a line (event) at a time in user mode.

Each line could still start with an event identifier, but it would be text 
rather than a binary. And you don’t need the size if you define "\n" as 
delimiter between events.

Regards,
  Felix

-Original Message-
From: Lin, Amber  
Sent: Friday, April 3, 2020 11:38
To: Kuehling, Felix ; amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH v2] drm/amdkfd: Provide SMI events watch

Further thinking about it, I'll use struct kfd_smi_msg_header. Instead of using 
struct kfd_smi_msg_vmfault, it's a description about the event. 
This way we make it generic to all events.

On 2020-04-03 9:38 a.m., Amber Lin wrote:
> Thanks Felix. I'll make changes accordingly but please pay attention 
> to my last reply inline.
>
> On 2020-04-02 7:51 p.m., Felix Kuehling wrote:
>> On 2020-04-02 4:46 p.m., Amber Lin wrote:
>>> When the compute is malfunctioning or performance drops, the system 
>>> admin will use SMI (System Management Interface) tool to 
>>> monitor/diagnostic what went wrong. This patch provides an event 
>>> watch interface for the user space to register events they are 
>>> interested. After the event is registered, the user can use 
>>> annoymous file descriptor's poll function with wait-time specified 
>>> to wait for the event to happen. Once the event happens, the user 
>>> can use read() to retrieve information related to the event.
>>>
>>> VM fault event is done in this patch.
>>>
>>> v2: - remove UNREGISTER and add event ENABLE/DISABLE
>>>  - correct kfifo usage
>>>  - move event message API to kfd_ioctl.h
>>>
>>> Signed-off-by: Amber Lin 
>>> ---
>>>   drivers/gpu/drm/amd/amdkfd/Makefile  |   3 +-
>>>   drivers/gpu/drm/amd/amdkfd/cik_event_interrupt.c |   2 +
>>>   drivers/gpu/drm/amd/amdkfd/kfd_chardev.c |  30 
>>>   drivers/gpu/drm/amd/amdkfd/kfd_device.c  |   1 +
>>>   drivers/gpu/drm/amd/amdkfd/kfd_int_process_v9.c  |   2 +
>>>   drivers/gpu/drm/amd/amdkfd/kfd_priv.h    |  12 ++
>>>   drivers/gpu/drm/amd/amdkfd/kfd_smi_events.c  | 177
>>> +++
>>>   drivers/gpu/drm/amd/amdkfd/kfd_smi_events.h  |  31 
>>>   include/uapi/linux/kfd_ioctl.h   |  30 +++-
>>>   9 files changed, 286 insertions(+), 2 deletions(-)
>>>   create mode 100644 drivers/gpu/drm/amd/amdkfd/kfd_smi_events.c
>>>   create mode 100644 drivers/gpu/drm/amd/amdkfd/kfd_smi_events.h
>>>
>>> diff --git a/drivers/gpu/drm/amd/amdkfd/Makefile
>>> b/drivers/gpu/drm/amd/amdkfd/Makefile
>>> index 6147462..cc98b4a 100644
>>> --- a/drivers/gpu/drm/amd/amdkfd/Makefile
>>> +++ b/drivers/gpu/drm/amd/amdkfd/Makefile
>>> @@ -53,7 +53,8 @@ AMDKFD_FILES    := $(AMDKFD_PATH)/kfd_module.o \
>>>   $(AMDKFD_PATH)/kfd_int_process_v9.o \
>>>   $(AMDKFD_PATH)/kfd_dbgdev.o \
>>>   $(AMDKFD_PATH)/kfd_dbgmgr.o \
>>> -    $(AMDKFD_PATH)/kfd_crat.o
>>> +    $(AMDKFD_PATH)/kfd_crat.o \
>>> +    $(AMDKFD_PATH)/kfd_smi_events.o
>>>     ifneq ($(CONFIG_AMD_IOMMU_V2),)
>>>   AMDKFD_FILES += $(AMDKFD_PATH)/kfd_iommu.o diff --git 
>>> a/drivers/gpu/drm/amd/amdkfd/cik_event_interrupt.c
>>> b/drivers/gpu/drm/amd/amdkfd/cik_event_interrupt.c
>>> index 9f59ba9..24b4717 100644
>>> --- a/drivers/gpu/drm/amd/amdkfd/cik_event_interrupt.c
>>> +++ b/drivers/gpu/drm/amd/amdkfd/cik_event_interrupt.c
>>> @@ -24,6 +24,7 @@
>>>   #include "kfd_events.h"
>>>   #include "cik_int.h"
>>>   #include "amdgpu_amdkfd.h"
>>> +#include "kfd_smi_events.h"
>>>     static bool cik_event_interrupt_isr(struct kfd_dev *dev,
>>>   const uint32_t *ih_ring_entry, @@ -107,6 
>>> +108,7 @@ static void cik_event_interrupt_wq(struct kfd_dev *dev,
>>>   ihre->source_id == CIK_INTSRC_GFX_MEM_PROT_FAULT) {
>>>   struct kfd_vm_fault_info info;
>>>   +    kfd_smi_event_update_vmfault(dev, pasid);
>>>   kfd_process_vm_fault(dev->dqm, pasid);
>>>     memset(, 0, sizeof(info)); diff --git 
>>> a/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
>>> b/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
>>> index f8fa03a..591ac28 100644
>>> --- a/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
>>> +++ b/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
>>> @@ -39,6 +39,7 @@
>>>   #include "kfd_device_queue_manager.h"
>>>   #include "kfd_dbgmgr.h"
>>>   #include "amdgpu_amdkfd.h"
>>> +#include "kfd_smi_events.h"
>>>     static long kfd_ioctl(struct file *, unsigned int, unsigned 
>>> long);
>>>   static int kfd_open(struct inode *, struct file *); @@ -1243,6 
>>> +1244,32 @@ static int kfd_ioctl_acquire_vm(struct file *filep, 
>>> struct kfd_process *p,
>>>   return ret;
>>>   }
>>>   +/* Handle 

[PATCH v2] drm/amdgpu/vcn: add shared menory restore after wake up from sleep.

2020-04-03 Thread James Zhu
VCN shared memory needs restore after wake up during S3 test.

v2: Allocate shared memory saved_bo at sw_init and free it in sw_fini.

Signed-off-by: James Zhu 
Reviewed-by: Feifei Xu 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c | 28 +++-
 drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h |  1 +
 2 files changed, 28 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c
index d653a18..dab34f6 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c
@@ -56,7 +56,7 @@ static void amdgpu_vcn_idle_work_handler(struct work_struct 
*work);
 
 int amdgpu_vcn_sw_init(struct amdgpu_device *adev)
 {
-   unsigned long bo_size;
+   unsigned long bo_size, fw_shared_bo_size;
const char *fw_name;
const struct common_firmware_header *hdr;
unsigned char fw_check;
@@ -190,6 +190,9 @@ int amdgpu_vcn_sw_init(struct amdgpu_device *adev)
dev_err(adev->dev, "VCN %d (%d) failed to allocate 
firmware shared bo\n", i, r);
return r;
}
+
+   fw_shared_bo_size = 
amdgpu_bo_size(adev->vcn.inst[i].fw_shared_bo);
+   adev->vcn.inst[i].saved_shm_bo = kvmalloc(fw_shared_bo_size, 
GFP_KERNEL);
}
 
return 0;
@@ -205,6 +208,7 @@ int amdgpu_vcn_sw_fini(struct amdgpu_device *adev)
if (adev->vcn.harvest_config & (1 << j))
continue;
 
+   kvfree(adev->vcn.inst[j].saved_shm_bo);
amdgpu_bo_free_kernel(>vcn.inst[j].fw_shared_bo,
  >vcn.inst[j].fw_shared_gpu_addr,
  (void 
**)>vcn.inst[j].fw_shared_cpu_addr);
@@ -254,6 +258,17 @@ int amdgpu_vcn_suspend(struct amdgpu_device *adev)
return -ENOMEM;
 
memcpy_fromio(adev->vcn.inst[i].saved_bo, ptr, size);
+
+   if (adev->vcn.inst[i].fw_shared_bo == NULL)
+   return 0;
+
+   if (!adev->vcn.inst[i].saved_shm_bo)
+   return -ENOMEM;
+
+   size = amdgpu_bo_size(adev->vcn.inst[i].fw_shared_bo);
+   ptr = adev->vcn.inst[i].fw_shared_cpu_addr;
+
+   memcpy_fromio(adev->vcn.inst[i].saved_shm_bo, ptr, size);
}
return 0;
 }
@@ -291,6 +306,17 @@ int amdgpu_vcn_resume(struct amdgpu_device *adev)
}
memset_io(ptr, 0, size);
}
+
+   if (adev->vcn.inst[i].fw_shared_bo == NULL)
+   return -EINVAL;
+
+   size = amdgpu_bo_size(adev->vcn.inst[i].fw_shared_bo);
+   ptr = adev->vcn.inst[i].fw_shared_cpu_addr;
+
+   if (adev->vcn.inst[i].saved_shm_bo != NULL)
+   memcpy_toio(ptr, adev->vcn.inst[i].saved_shm_bo, size);
+   else
+   memset_io(ptr, 0, size);
}
return 0;
 }
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h
index f739e1a..bd77dae 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h
@@ -194,6 +194,7 @@ struct amdgpu_vcn_inst {
atomic_tdpg_enc_submission_cnt;
void*fw_shared_cpu_addr;
uint64_tfw_shared_gpu_addr;
+   void*saved_shm_bo;
 };
 
 struct amdgpu_vcn {
-- 
2.7.4

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


Re: [PATCH] device_cgroup: Cleanup cgroup eBPF device filter code

2020-04-03 Thread Odin Ugedal
Hi (patch author here),

This is my first "real" patch, so looking forward to some feedback! I am
not sure if this behavior is the "best one", or if we should require
CONFIG_CGROUP_DEVICE to be set to yes. In that case we can just abandon
this patch and replace the original "#if defined(CONFIG_CGROUP_DEVICE) ||
defined(CONFIG_CGROUP_BPF)" with a simple "#ifdef CONFIG_CGROUP_DEVICE" and
update the docs and the config.

It is also another alternative to keep the code in this patch and move some
of it into a separate file in order to avoid all the ifdefs, and to make
the split between cgroup v1 and cgroup v2 code cleaner.

As a reference, only Fedora is currently shipping with cgroup v2 as
default (afaik.) and their kernel is compiled (5.3.7-301.fc31.x86_64)
with CONFIG_CGROUP_DEVICE=y and CONFIG_CGROUP_BPF=y, so this will not
affect them.

Odin Ugedal

fre. 3. apr. 2020 kl. 19:55 skrev Odin Ugedal :

> Original cgroup v2 eBPF code for filtering device access made it
> possible to compile with CONFIG_CGROUP_DEVICE=n and still use the eBPF
> filtering. Change
> commit 4b7d4d453fc4 ("device_cgroup: Export devcgroup_check_permission")
> reverted this, making it required to set it to y.
>
> Since the device filtering (and all the docs) for cgroup v2 is no longer
> a "device controller" like it was in v1, someone might compile their
> kernel with CONFIG_CGROUP_DEVICE=n. Then (for linux 5.5+) the eBPF
> filter will not be invoked, and all processes will be allowed access
> to all devices, no matter what the eBPF filter says.
>
> Signed-off-by: Odin Ugedal 
> ---
>  drivers/gpu/drm/amd/amdkfd/kfd_priv.h |  2 +-
>  include/linux/device_cgroup.h | 14 +-
>  security/Makefile |  2 +-
>  security/device_cgroup.c  | 19 ---
>  4 files changed, 23 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_priv.h
> b/drivers/gpu/drm/amd/amdkfd/kfd_priv.h
> index 4a3049841086..c24cad3c64ed 100644
> --- a/drivers/gpu/drm/amd/amdkfd/kfd_priv.h
> +++ b/drivers/gpu/drm/amd/amdkfd/kfd_priv.h
> @@ -1050,7 +1050,7 @@ void kfd_dec_compute_active(struct kfd_dev *dev);
>  /* Check with device cgroup if @kfd device is accessible */
>  static inline int kfd_devcgroup_check_permission(struct kfd_dev *kfd)
>  {
> -#if defined(CONFIG_CGROUP_DEVICE)
> +#if defined(CONFIG_CGROUP_DEVICE) || defined(CONFIG_CGROUP_BPF)
> struct drm_device *ddev = kfd->ddev;
>
> return devcgroup_check_permission(DEVCG_DEV_CHAR,
> ddev->driver->major,
> diff --git a/include/linux/device_cgroup.h b/include/linux/device_cgroup.h
> index fa35b52e0002..9a72214496e5 100644
> --- a/include/linux/device_cgroup.h
> +++ b/include/linux/device_cgroup.h
> @@ -1,6 +1,5 @@
>  /* SPDX-License-Identifier: GPL-2.0 */
>  #include 
> -#include 
>
>  #define DEVCG_ACC_MKNOD 1
>  #define DEVCG_ACC_READ  2
> @@ -11,16 +10,10 @@
>  #define DEVCG_DEV_CHAR  2
>  #define DEVCG_DEV_ALL   4  /* this represents all devices */
>
> -#ifdef CONFIG_CGROUP_DEVICE
> -int devcgroup_check_permission(short type, u32 major, u32 minor,
> -  short access);
> -#else
> -static inline int devcgroup_check_permission(short type, u32 major, u32
> minor,
> -short access)
> -{ return 0; }
> -#endif
>
>  #if defined(CONFIG_CGROUP_DEVICE) || defined(CONFIG_CGROUP_BPF)
> +int devcgroup_check_permission(short type, u32 major, u32 minor,
> +  short access);
>  static inline int devcgroup_inode_permission(struct inode *inode, int
> mask)
>  {
> short type, access = 0;
> @@ -61,6 +54,9 @@ static inline int devcgroup_inode_mknod(int mode, dev_t
> dev)
>  }
>
>  #else
> +static inline int devcgroup_check_permission(short type, u32 major, u32
> minor,
> +  short access)
> +{ return 0; }
>  static inline int devcgroup_inode_permission(struct inode *inode, int
> mask)
>  { return 0; }
>  static inline int devcgroup_inode_mknod(int mode, dev_t dev)
> diff --git a/security/Makefile b/security/Makefile
> index 22e73a3482bd..3baf435de541 100644
> --- a/security/Makefile
> +++ b/security/Makefile
> @@ -30,7 +30,7 @@ obj-$(CONFIG_SECURITY_YAMA)   += yama/
>  obj-$(CONFIG_SECURITY_LOADPIN) += loadpin/
>  obj-$(CONFIG_SECURITY_SAFESETID)   += safesetid/
>  obj-$(CONFIG_SECURITY_LOCKDOWN_LSM)+= lockdown/
> -obj-$(CONFIG_CGROUP_DEVICE)+= device_cgroup.o
> +obj-$(CONFIG_CGROUPS)  += device_cgroup.o
>  obj-$(CONFIG_BPF_LSM)  += bpf/
>
>  # Object integrity file lists
> diff --git a/security/device_cgroup.c b/security/device_cgroup.c
> index 7d0f8f7431ff..43ab0ad45c1b 100644
> --- a/security/device_cgroup.c
> +++ b/security/device_cgroup.c
> @@ -15,6 +15,8 @@
>  #include 
>  #include 
>
> +#ifdef CONFIG_CGROUP_DEVICE
> +
>  static DEFINE_MUTEX(devcgroup_mutex);
>
>  enum devcg_behavior {
> @@ -792,7 +794,7 @@ struct cgroup_subsys 

Re: [PATCH] device_cgroup: Cleanup cgroup eBPF device filter code

2020-04-03 Thread Odin Ugedal
Hi (patch author here),

This is my first "real" patch, so looking forward to some feedback! I
am not sure if this behavior is the "best one", or if we should
require CONFIG_CGROUP_DEVICE to be set to yes. In that case we can
just abandon this patch and replace the original "#if
defined(CONFIG_CGROUP_DEVICE) || defined(CONFIG_CGROUP_BPF)" with a
simple "#ifdef CONFIG_CGROUP_DEVICE" and update the docs and the
config.

It is also another alternative to keep the code in this patch and move
some of it into a separate file in order to avoid all the ifdefs, and
to make the split between cgroup v1 and cgroup v2 code cleaner.

As a reference, only Fedora is currently shipping with cgroup v2 as
default (afaik.) and their kernel is compiled (5.3.7-301.fc31.x86_64)
with CONFIG_CGROUP_DEVICE=y and CONFIG_CGROUP_BPF=y, so this will not
affect them.

Odin Ugedal


fre. 3. apr. 2020 kl. 19:55 skrev Odin Ugedal :
>
> Original cgroup v2 eBPF code for filtering device access made it
> possible to compile with CONFIG_CGROUP_DEVICE=n and still use the eBPF
> filtering. Change
> commit 4b7d4d453fc4 ("device_cgroup: Export devcgroup_check_permission")
> reverted this, making it required to set it to y.
>
> Since the device filtering (and all the docs) for cgroup v2 is no longer
> a "device controller" like it was in v1, someone might compile their
> kernel with CONFIG_CGROUP_DEVICE=n. Then (for linux 5.5+) the eBPF
> filter will not be invoked, and all processes will be allowed access
> to all devices, no matter what the eBPF filter says.
>
> Signed-off-by: Odin Ugedal 
> ---
>  drivers/gpu/drm/amd/amdkfd/kfd_priv.h |  2 +-
>  include/linux/device_cgroup.h | 14 +-
>  security/Makefile |  2 +-
>  security/device_cgroup.c  | 19 ---
>  4 files changed, 23 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_priv.h 
> b/drivers/gpu/drm/amd/amdkfd/kfd_priv.h
> index 4a3049841086..c24cad3c64ed 100644
> --- a/drivers/gpu/drm/amd/amdkfd/kfd_priv.h
> +++ b/drivers/gpu/drm/amd/amdkfd/kfd_priv.h
> @@ -1050,7 +1050,7 @@ void kfd_dec_compute_active(struct kfd_dev *dev);
>  /* Check with device cgroup if @kfd device is accessible */
>  static inline int kfd_devcgroup_check_permission(struct kfd_dev *kfd)
>  {
> -#if defined(CONFIG_CGROUP_DEVICE)
> +#if defined(CONFIG_CGROUP_DEVICE) || defined(CONFIG_CGROUP_BPF)
> struct drm_device *ddev = kfd->ddev;
>
> return devcgroup_check_permission(DEVCG_DEV_CHAR, ddev->driver->major,
> diff --git a/include/linux/device_cgroup.h b/include/linux/device_cgroup.h
> index fa35b52e0002..9a72214496e5 100644
> --- a/include/linux/device_cgroup.h
> +++ b/include/linux/device_cgroup.h
> @@ -1,6 +1,5 @@
>  /* SPDX-License-Identifier: GPL-2.0 */
>  #include 
> -#include 
>
>  #define DEVCG_ACC_MKNOD 1
>  #define DEVCG_ACC_READ  2
> @@ -11,16 +10,10 @@
>  #define DEVCG_DEV_CHAR  2
>  #define DEVCG_DEV_ALL   4  /* this represents all devices */
>
> -#ifdef CONFIG_CGROUP_DEVICE
> -int devcgroup_check_permission(short type, u32 major, u32 minor,
> -  short access);
> -#else
> -static inline int devcgroup_check_permission(short type, u32 major, u32 
> minor,
> -short access)
> -{ return 0; }
> -#endif
>
>  #if defined(CONFIG_CGROUP_DEVICE) || defined(CONFIG_CGROUP_BPF)
> +int devcgroup_check_permission(short type, u32 major, u32 minor,
> +  short access);
>  static inline int devcgroup_inode_permission(struct inode *inode, int mask)
>  {
> short type, access = 0;
> @@ -61,6 +54,9 @@ static inline int devcgroup_inode_mknod(int mode, dev_t dev)
>  }
>
>  #else
> +static inline int devcgroup_check_permission(short type, u32 major, u32 
> minor,
> +  short access)
> +{ return 0; }
>  static inline int devcgroup_inode_permission(struct inode *inode, int mask)
>  { return 0; }
>  static inline int devcgroup_inode_mknod(int mode, dev_t dev)
> diff --git a/security/Makefile b/security/Makefile
> index 22e73a3482bd..3baf435de541 100644
> --- a/security/Makefile
> +++ b/security/Makefile
> @@ -30,7 +30,7 @@ obj-$(CONFIG_SECURITY_YAMA)   += yama/
>  obj-$(CONFIG_SECURITY_LOADPIN) += loadpin/
>  obj-$(CONFIG_SECURITY_SAFESETID)   += safesetid/
>  obj-$(CONFIG_SECURITY_LOCKDOWN_LSM)+= lockdown/
> -obj-$(CONFIG_CGROUP_DEVICE)+= device_cgroup.o
> +obj-$(CONFIG_CGROUPS)  += device_cgroup.o
>  obj-$(CONFIG_BPF_LSM)  += bpf/
>
>  # Object integrity file lists
> diff --git a/security/device_cgroup.c b/security/device_cgroup.c
> index 7d0f8f7431ff..43ab0ad45c1b 100644
> --- a/security/device_cgroup.c
> +++ b/security/device_cgroup.c
> @@ -15,6 +15,8 @@
>  #include 
>  #include 
>
> +#ifdef CONFIG_CGROUP_DEVICE
> +
>  static DEFINE_MUTEX(devcgroup_mutex);
>
>  enum devcg_behavior {
> @@ -792,7 +794,7 @@ struct cgroup_subsys 

[PATCH] device_cgroup: Cleanup cgroup eBPF device filter code

2020-04-03 Thread Odin Ugedal
Original cgroup v2 eBPF code for filtering device access made it
possible to compile with CONFIG_CGROUP_DEVICE=n and still use the eBPF
filtering. Change 
commit 4b7d4d453fc4 ("device_cgroup: Export devcgroup_check_permission")
reverted this, making it required to set it to y.

Since the device filtering (and all the docs) for cgroup v2 is no longer
a "device controller" like it was in v1, someone might compile their
kernel with CONFIG_CGROUP_DEVICE=n. Then (for linux 5.5+) the eBPF
filter will not be invoked, and all processes will be allowed access
to all devices, no matter what the eBPF filter says.

Signed-off-by: Odin Ugedal 
---
 drivers/gpu/drm/amd/amdkfd/kfd_priv.h |  2 +-
 include/linux/device_cgroup.h | 14 +-
 security/Makefile |  2 +-
 security/device_cgroup.c  | 19 ---
 4 files changed, 23 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_priv.h 
b/drivers/gpu/drm/amd/amdkfd/kfd_priv.h
index 4a3049841086..c24cad3c64ed 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_priv.h
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_priv.h
@@ -1050,7 +1050,7 @@ void kfd_dec_compute_active(struct kfd_dev *dev);
 /* Check with device cgroup if @kfd device is accessible */
 static inline int kfd_devcgroup_check_permission(struct kfd_dev *kfd)
 {
-#if defined(CONFIG_CGROUP_DEVICE)
+#if defined(CONFIG_CGROUP_DEVICE) || defined(CONFIG_CGROUP_BPF)
struct drm_device *ddev = kfd->ddev;
 
return devcgroup_check_permission(DEVCG_DEV_CHAR, ddev->driver->major,
diff --git a/include/linux/device_cgroup.h b/include/linux/device_cgroup.h
index fa35b52e0002..9a72214496e5 100644
--- a/include/linux/device_cgroup.h
+++ b/include/linux/device_cgroup.h
@@ -1,6 +1,5 @@
 /* SPDX-License-Identifier: GPL-2.0 */
 #include 
-#include 
 
 #define DEVCG_ACC_MKNOD 1
 #define DEVCG_ACC_READ  2
@@ -11,16 +10,10 @@
 #define DEVCG_DEV_CHAR  2
 #define DEVCG_DEV_ALL   4  /* this represents all devices */
 
-#ifdef CONFIG_CGROUP_DEVICE
-int devcgroup_check_permission(short type, u32 major, u32 minor,
-  short access);
-#else
-static inline int devcgroup_check_permission(short type, u32 major, u32 minor,
-short access)
-{ return 0; }
-#endif
 
 #if defined(CONFIG_CGROUP_DEVICE) || defined(CONFIG_CGROUP_BPF)
+int devcgroup_check_permission(short type, u32 major, u32 minor,
+  short access);
 static inline int devcgroup_inode_permission(struct inode *inode, int mask)
 {
short type, access = 0;
@@ -61,6 +54,9 @@ static inline int devcgroup_inode_mknod(int mode, dev_t dev)
 }
 
 #else
+static inline int devcgroup_check_permission(short type, u32 major, u32 minor,
+  short access)
+{ return 0; }
 static inline int devcgroup_inode_permission(struct inode *inode, int mask)
 { return 0; }
 static inline int devcgroup_inode_mknod(int mode, dev_t dev)
diff --git a/security/Makefile b/security/Makefile
index 22e73a3482bd..3baf435de541 100644
--- a/security/Makefile
+++ b/security/Makefile
@@ -30,7 +30,7 @@ obj-$(CONFIG_SECURITY_YAMA)   += yama/
 obj-$(CONFIG_SECURITY_LOADPIN) += loadpin/
 obj-$(CONFIG_SECURITY_SAFESETID)   += safesetid/
 obj-$(CONFIG_SECURITY_LOCKDOWN_LSM)+= lockdown/
-obj-$(CONFIG_CGROUP_DEVICE)+= device_cgroup.o
+obj-$(CONFIG_CGROUPS)  += device_cgroup.o
 obj-$(CONFIG_BPF_LSM)  += bpf/
 
 # Object integrity file lists
diff --git a/security/device_cgroup.c b/security/device_cgroup.c
index 7d0f8f7431ff..43ab0ad45c1b 100644
--- a/security/device_cgroup.c
+++ b/security/device_cgroup.c
@@ -15,6 +15,8 @@
 #include 
 #include 
 
+#ifdef CONFIG_CGROUP_DEVICE
+
 static DEFINE_MUTEX(devcgroup_mutex);
 
 enum devcg_behavior {
@@ -792,7 +794,7 @@ struct cgroup_subsys devices_cgrp_subsys = {
 };
 
 /**
- * __devcgroup_check_permission - checks if an inode operation is permitted
+ * devcgroup_legacy_check_permission - checks if an inode operation is 
permitted
  * @dev_cgroup: the dev cgroup to be tested against
  * @type: device type
  * @major: device major number
@@ -801,7 +803,7 @@ struct cgroup_subsys devices_cgrp_subsys = {
  *
  * returns 0 on success, -EPERM case the operation is not permitted
  */
-static int __devcgroup_check_permission(short type, u32 major, u32 minor,
+static int devcgroup_legacy_check_permission(short type, u32 major, u32 minor,
short access)
 {
struct dev_cgroup *dev_cgroup;
@@ -825,6 +827,10 @@ static int __devcgroup_check_permission(short type, u32 
major, u32 minor,
return 0;
 }
 
+#endif /* CONFIG_CGROUP_DEVICE */
+
+#if defined(CONFIG_CGROUP_DEVICE) || defined(CONFIG_CGROUP_BPF)
+
 int devcgroup_check_permission(short type, u32 major, u32 minor, short access)
 {
int rc = BPF_CGROUP_RUN_PROG_DEVICE_CGROUP(type, major, minor, access);
@@ -832,6 +838,13 @@ int 

[PATCH] drm/amdgpu: Re-enable FRU check for most models v3

2020-04-03 Thread Kent Russell
There are 2 VG20 SKUs that do not have the FRU on there, and trying to read
that will cause a hang. For now, check for the gaming SKU until a proper
fix can be implemented. This re-enables serial number reporting for
server cards

v2: Add ASIC check
v3: Don't default to true for pre-VG10

Signed-off-by: Kent Russell 
---
 .../gpu/drm/amd/amdgpu/amdgpu_fru_eeprom.c| 22 +--
 1 file changed, 20 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_fru_eeprom.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_fru_eeprom.c
index bfe4259f9508..508906177cad 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_fru_eeprom.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_fru_eeprom.c
@@ -31,9 +31,27 @@
 
 bool is_fru_eeprom_supported(struct amdgpu_device *adev)
 {
-   /* TODO: Resolve supported ASIC type */
+   struct atom_context *atom_ctx = adev->mode_info.atom_context;
 
-   return false;
+   if (!atom_ctx)
+   return false;
+
+   /* TODO: Gaming SKUs don't have the FRU EEPROM.
+* Use this to address hangs on modprobe on gaming SKUs
+* until a proper solution can be implemented
+*/
+   switch (adev->asic_type) {
+   case CHIP_VEGA20:
+   if (strnstr(atom_ctx->vbios_version, "D360",
+   sizeof(atom_ctx->vbios_version)))
+   return false;
+   return true;
+   case CHIP_ARCTURUS:
+   /* There are no gaming Arcturus SKUs */
+   return true;
+   default:
+   return false;
+   }
 }
 
 int amdgpu_fru_read_eeprom(struct amdgpu_device *adev, uint32_t addrptr,
-- 
2.17.1

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


RE: [PATCH] drm/amdgpu: Re-enable FRU check for most models

2020-04-03 Thread Russell, Kent
[AMD Official Use Only - Internal Distribution Only]



> -Original Message-
> From: Alex Deucher 
> Sent: Friday, April 3, 2020 12:48 PM
> To: Russell, Kent 
> Cc: amd-gfx list 
> Subject: Re: [PATCH] drm/amdgpu: Re-enable FRU check for most models
> 
> On Fri, Apr 3, 2020 at 12:41 PM Russell, Kent  wrote:
> >
> > [AMD Official Use Only - Internal Distribution Only]
> >
> >
> > > -Original Message-
> > > From: Alex Deucher 
> > > Sent: Friday, April 3, 2020 12:36 PM
> > > To: Russell, Kent 
> > > Cc: amd-gfx list 
> > > Subject: Re: [PATCH] drm/amdgpu: Re-enable FRU check for most models
> > >
> > > On Fri, Apr 3, 2020 at 12:30 PM Kent Russell 
> wrote:
> > > >
> > > > There are 2 VG20 SKUs that do not have the FRU on there, and
> > > > trying to read that will cause a hang. For now, check for the
> > > > gaming SKU until a proper fix can be implemented. This re-enables
> > > > serial number reporting for server cards
> > > >
> > > > Signed-off-by: Kent Russell 
> > > > ---
> > > >  drivers/gpu/drm/amd/amdgpu/amdgpu_fru_eeprom.c | 16
> > > ++--
> > > >  1 file changed, 14 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_fru_eeprom.c
> > > > b/drivers/gpu/drm/amd/amdgpu/amdgpu_fru_eeprom.c
> > > > index bfe4259f9508..9582469a70cb 100644
> > > > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_fru_eeprom.c
> > > > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_fru_eeprom.c
> > > > @@ -31,9 +31,21 @@
> > > >
> > > >  bool is_fru_eeprom_supported(struct amdgpu_device *adev)  {
> > > > -   /* TODO: Resolve supported ASIC type */
> > > > +   struct atom_context *atom_ctx =
> > > > + adev->mode_info.atom_context;
> > > >
> > > > -   return false;
> > > > +   if (!atom_ctx)
> > > > +   return false;
> > > > +
> > > > +   /* TODO: Gaming SKUs don't have the FRU EEPROM.
> > > > +* Use this to address hangs on modprobe on gaming SKUs
> > > > +* until a proper solution can be implemented
> > > > +*/
> > > > +   if (adev->asic_type == CHIP_VEGA20)
> > > > +   if (strnstr(atom_ctx->vbios_version, "D360",
> > > > +   sizeof(atom_ctx->vbios_version)))
> > > > +   return false;
> > > > +
> > > > +   return true;
> > >
> > > I think you want to default to false and only return true if it's a
> > > vega20 and it's the right vbios version otherwise we'll try to fetch
> > > the info on all asics.
> >
> > I was trying to go for the smallest list. There are 2 SKUs in all of VG20 
> > that
> don't work, and none in Arcturus (and the FRU check is only for VG20+) , so I
> assumed that I could just cover the 2 bad cases. It's supported on Arcturus, 
> and
> it's supported on server VG20, and we don't touch it at all on VG10-and-older.
> 
> Right, but if you return true by default, then the driver will try and fetch 
> the
> FRU stuff from every asic right?
> 
> I would do something like:
> 
> if ((adev->asic_type == CHIP_VEGA20) ||
>(adev->asic_type == CHIP_ARCTURUS) {
>   /* do whatever logic makes sense here to sort out these asics */
> if (...)
> return false;
> else
> return true;
> }
> 
> /* return false for everything else */
> return false;
> 
Ah good point! I'll do that now. 


> >
> >  Kent
> >
> >
> > >
> > > Alex
> > >
> > > >  }
> > > >
> > > >  int amdgpu_fru_read_eeprom(struct amdgpu_device *adev, uint32_t
> > > addrptr,
> > > > --
> > > > 2.17.1
> > > >
> > > > ___
> > > > amd-gfx mailing list
> > > > amd-gfx@lists.freedesktop.org
> > > >
> > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fli
> > > sts.fr
> > > eedesktop.org%2Fmailman%2Flistinfo%2Famd-
> > >
> gfxdata=02%7C01%7Ckent.russell%40amd.com%7C0f2e5090b21b4807b
> > >
> 66808d7d7ed28f1%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C6
> > >
> 37215285907421019sdata=yBc0%2FrNnnWgRBiJcAvav4JtvmoG0Tyhd6p
> > > X6gfFeW%2FU%3Dreserved=0
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


Re: [PATCH] drm/amdgpu: Re-enable FRU check for most models

2020-04-03 Thread Alex Deucher
On Fri, Apr 3, 2020 at 12:41 PM Russell, Kent  wrote:
>
> [AMD Official Use Only - Internal Distribution Only]
>
>
> > -Original Message-
> > From: Alex Deucher 
> > Sent: Friday, April 3, 2020 12:36 PM
> > To: Russell, Kent 
> > Cc: amd-gfx list 
> > Subject: Re: [PATCH] drm/amdgpu: Re-enable FRU check for most models
> >
> > On Fri, Apr 3, 2020 at 12:30 PM Kent Russell  wrote:
> > >
> > > There are 2 VG20 SKUs that do not have the FRU on there, and trying to
> > > read that will cause a hang. For now, check for the gaming SKU until a
> > > proper fix can be implemented. This re-enables serial number reporting
> > > for server cards
> > >
> > > Signed-off-by: Kent Russell 
> > > ---
> > >  drivers/gpu/drm/amd/amdgpu/amdgpu_fru_eeprom.c | 16
> > ++--
> > >  1 file changed, 14 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_fru_eeprom.c
> > > b/drivers/gpu/drm/amd/amdgpu/amdgpu_fru_eeprom.c
> > > index bfe4259f9508..9582469a70cb 100644
> > > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_fru_eeprom.c
> > > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_fru_eeprom.c
> > > @@ -31,9 +31,21 @@
> > >
> > >  bool is_fru_eeprom_supported(struct amdgpu_device *adev)  {
> > > -   /* TODO: Resolve supported ASIC type */
> > > +   struct atom_context *atom_ctx = adev->mode_info.atom_context;
> > >
> > > -   return false;
> > > +   if (!atom_ctx)
> > > +   return false;
> > > +
> > > +   /* TODO: Gaming SKUs don't have the FRU EEPROM.
> > > +* Use this to address hangs on modprobe on gaming SKUs
> > > +* until a proper solution can be implemented
> > > +*/
> > > +   if (adev->asic_type == CHIP_VEGA20)
> > > +   if (strnstr(atom_ctx->vbios_version, "D360",
> > > +   sizeof(atom_ctx->vbios_version)))
> > > +   return false;
> > > +
> > > +   return true;
> >
> > I think you want to default to false and only return true if it's a
> > vega20 and it's the right vbios version otherwise we'll try to fetch
> > the info on all asics.
>
> I was trying to go for the smallest list. There are 2 SKUs in all of VG20 
> that don't work, and none in Arcturus (and the FRU check is only for VG20+) , 
> so I assumed that I could just cover the 2 bad cases. It's supported on 
> Arcturus, and it's supported on server VG20, and we don't touch it at all on 
> VG10-and-older.

Right, but if you return true by default, then the driver will try and
fetch the FRU stuff from every asic right?

I would do something like:

if ((adev->asic_type == CHIP_VEGA20) ||
   (adev->asic_type == CHIP_ARCTURUS) {
  /* do whatever logic makes sense here to sort out these asics */
if (...)
return false;
else
return true;
}

/* return false for everything else */
return false;

>
>  Kent
>
>
> >
> > Alex
> >
> > >  }
> > >
> > >  int amdgpu_fru_read_eeprom(struct amdgpu_device *adev, uint32_t
> > addrptr,
> > > --
> > > 2.17.1
> > >
> > > ___
> > > amd-gfx mailing list
> > > amd-gfx@lists.freedesktop.org
> > >
> > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.fr
> > eedesktop.org%2Fmailman%2Flistinfo%2Famd-
> > gfxdata=02%7C01%7Ckent.russell%40amd.com%7C0f2e5090b21b4807b
> > 66808d7d7ed28f1%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C6
> > 37215285907421019sdata=yBc0%2FrNnnWgRBiJcAvav4JtvmoG0Tyhd6p
> > X6gfFeW%2FU%3Dreserved=0
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


RE: [PATCH] drm/amdgpu: Re-enable FRU check for most models

2020-04-03 Thread Russell, Kent
[AMD Official Use Only - Internal Distribution Only]


> -Original Message-
> From: Alex Deucher 
> Sent: Friday, April 3, 2020 12:36 PM
> To: Russell, Kent 
> Cc: amd-gfx list 
> Subject: Re: [PATCH] drm/amdgpu: Re-enable FRU check for most models
> 
> On Fri, Apr 3, 2020 at 12:30 PM Kent Russell  wrote:
> >
> > There are 2 VG20 SKUs that do not have the FRU on there, and trying to
> > read that will cause a hang. For now, check for the gaming SKU until a
> > proper fix can be implemented. This re-enables serial number reporting
> > for server cards
> >
> > Signed-off-by: Kent Russell 
> > ---
> >  drivers/gpu/drm/amd/amdgpu/amdgpu_fru_eeprom.c | 16
> ++--
> >  1 file changed, 14 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_fru_eeprom.c
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_fru_eeprom.c
> > index bfe4259f9508..9582469a70cb 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_fru_eeprom.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_fru_eeprom.c
> > @@ -31,9 +31,21 @@
> >
> >  bool is_fru_eeprom_supported(struct amdgpu_device *adev)  {
> > -   /* TODO: Resolve supported ASIC type */
> > +   struct atom_context *atom_ctx = adev->mode_info.atom_context;
> >
> > -   return false;
> > +   if (!atom_ctx)
> > +   return false;
> > +
> > +   /* TODO: Gaming SKUs don't have the FRU EEPROM.
> > +* Use this to address hangs on modprobe on gaming SKUs
> > +* until a proper solution can be implemented
> > +*/
> > +   if (adev->asic_type == CHIP_VEGA20)
> > +   if (strnstr(atom_ctx->vbios_version, "D360",
> > +   sizeof(atom_ctx->vbios_version)))
> > +   return false;
> > +
> > +   return true;
> 
> I think you want to default to false and only return true if it's a
> vega20 and it's the right vbios version otherwise we'll try to fetch
> the info on all asics.

I was trying to go for the smallest list. There are 2 SKUs in all of VG20 that 
don't work, and none in Arcturus (and the FRU check is only for VG20+) , so I 
assumed that I could just cover the 2 bad cases. It's supported on Arcturus, 
and it's supported on server VG20, and we don't touch it at all on 
VG10-and-older.
 
 Kent


> 
> Alex
> 
> >  }
> >
> >  int amdgpu_fru_read_eeprom(struct amdgpu_device *adev, uint32_t
> addrptr,
> > --
> > 2.17.1
> >
> > ___
> > amd-gfx mailing list
> > amd-gfx@lists.freedesktop.org
> >
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.fr
> eedesktop.org%2Fmailman%2Flistinfo%2Famd-
> gfxdata=02%7C01%7Ckent.russell%40amd.com%7C0f2e5090b21b4807b
> 66808d7d7ed28f1%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C6
> 37215285907421019sdata=yBc0%2FrNnnWgRBiJcAvav4JtvmoG0Tyhd6p
> X6gfFeW%2FU%3Dreserved=0
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


Re: amdgpu dropping load callback triggers WARN_ON in __drm_mode_object_add

2020-04-03 Thread Daniel Vetter
5 seconds on irc and I've found the splat ...

drm_properties need to be created at driver load time, upfront. You
can attach them to hotpluggable drm_connector objects later on, but
only before calling drm_connector_register().

The warning exists because i915 had the same bug :-)
-Daniel

On Fri, Apr 3, 2020 at 6:38 PM Daniel Vetter  wrote:
>
> On Fri, Apr 3, 2020 at 6:30 PM Michel Dänzer  wrote:
> >
> >
> > I'm getting the attached WARNING splats since amdgpu dropped its load
> > callback. They're from
> >
> > WARN_ON(!dev->driver->load && dev->registered && !obj_free_cb);
> >
> > in __drm_mode_object_add.
> >
> > I'm not sure how to address this, since obj_free_cb is always NULL here,
> > and I don't think MST connectors getting added after dev->registered is
> > set can be avoided?
>
> I need the full splat, otherwise can't tell you what's going wrong.
> There's 2 cases:
>
> - hotpluggable stuff, which has the obj_free_cb set. Essentially MST 
> connectors.
>
> - not-hotpluggable stuff, which is everything else. They don't have
> obj_free_cb set. It's a driver bug to register those after the overall
> drm_device has already been registered and published to userspace.
> -Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch



-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


Re: amdgpu dropping load callback triggers WARN_ON in __drm_mode_object_add

2020-04-03 Thread Daniel Vetter
On Fri, Apr 3, 2020 at 6:30 PM Michel Dänzer  wrote:
>
>
> I'm getting the attached WARNING splats since amdgpu dropped its load
> callback. They're from
>
> WARN_ON(!dev->driver->load && dev->registered && !obj_free_cb);
>
> in __drm_mode_object_add.
>
> I'm not sure how to address this, since obj_free_cb is always NULL here,
> and I don't think MST connectors getting added after dev->registered is
> set can be avoided?

I need the full splat, otherwise can't tell you what's going wrong.
There's 2 cases:

- hotpluggable stuff, which has the obj_free_cb set. Essentially MST connectors.

- not-hotpluggable stuff, which is everything else. They don't have
obj_free_cb set. It's a driver bug to register those after the overall
drm_device has already been registered and published to userspace.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


Re: [PATCH] drm/amdgpu: Re-enable FRU check for most models

2020-04-03 Thread Alex Deucher
On Fri, Apr 3, 2020 at 12:30 PM Kent Russell  wrote:
>
> There are 2 VG20 SKUs that do not have the FRU on there, and trying to read
> that will cause a hang. For now, check for the gaming SKU until a proper
> fix can be implemented. This re-enables serial number reporting for
> server cards
>
> Signed-off-by: Kent Russell 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_fru_eeprom.c | 16 ++--
>  1 file changed, 14 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_fru_eeprom.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_fru_eeprom.c
> index bfe4259f9508..9582469a70cb 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_fru_eeprom.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_fru_eeprom.c
> @@ -31,9 +31,21 @@
>
>  bool is_fru_eeprom_supported(struct amdgpu_device *adev)
>  {
> -   /* TODO: Resolve supported ASIC type */
> +   struct atom_context *atom_ctx = adev->mode_info.atom_context;
>
> -   return false;
> +   if (!atom_ctx)
> +   return false;
> +
> +   /* TODO: Gaming SKUs don't have the FRU EEPROM.
> +* Use this to address hangs on modprobe on gaming SKUs
> +* until a proper solution can be implemented
> +*/
> +   if (adev->asic_type == CHIP_VEGA20)
> +   if (strnstr(atom_ctx->vbios_version, "D360",
> +   sizeof(atom_ctx->vbios_version)))
> +   return false;
> +
> +   return true;

I think you want to default to false and only return true if it's a
vega20 and it's the right vbios version otherwise we'll try to fetch
the info on all asics.

Alex

>  }
>
>  int amdgpu_fru_read_eeprom(struct amdgpu_device *adev, uint32_t addrptr,
> --
> 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


Re: [PATCH] drm/amdgpu/psp: dont warn on missing optional TA's

2020-04-03 Thread Nirmoy



On 4/3/20 6:32 PM, Alex Deucher wrote:

Replace dev_warn() with dev_info() and note that they are
optional to avoid confusing users.

The RAS TAs only exist on server boards and the HDCP and DTM
TAs only exist on client boards.  They are optional either way.

Signed-off-by: Alex Deucher 



Acked-by: Nirmoy Das 



---
  drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c | 6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
index dbaeffc4431e..5d67b1838951 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
@@ -822,7 +822,7 @@ static int psp_ras_initialize(struct psp_context *psp)
  
  	if (!psp->adev->psp.ta_ras_ucode_size ||

!psp->adev->psp.ta_ras_start_addr) {
-   dev_warn(psp->adev->dev, "RAS: ras ta ucode is not 
available\n");
+   dev_info(psp->adev->dev, "RAS: optional ras ta ucode is not 
available\n");
return 0;
}
  
@@ -906,7 +906,7 @@ static int psp_hdcp_initialize(struct psp_context *psp)
  
  	if (!psp->adev->psp.ta_hdcp_ucode_size ||

!psp->adev->psp.ta_hdcp_start_addr) {
-   dev_warn(psp->adev->dev, "HDCP: hdcp ta ucode is not 
available\n");
+   dev_info(psp->adev->dev, "HDCP: optional hdcp ta ucode is not 
available\n");
return 0;
}
  
@@ -1052,7 +1052,7 @@ static int psp_dtm_initialize(struct psp_context *psp)
  
  	if (!psp->adev->psp.ta_dtm_ucode_size ||

!psp->adev->psp.ta_dtm_start_addr) {
-   dev_warn(psp->adev->dev, "DTM: dtm ta ucode is not 
available\n");
+   dev_info(psp->adev->dev, "DTM: optional dtm ta ucode is not 
available\n");
return 0;
}
  

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


[PATCH] drm/amdgpu/psp: dont warn on missing optional TA's

2020-04-03 Thread Alex Deucher
Replace dev_warn() with dev_info() and note that they are
optional to avoid confusing users.

The RAS TAs only exist on server boards and the HDCP and DTM
TAs only exist on client boards.  They are optional either way.

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

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
index dbaeffc4431e..5d67b1838951 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
@@ -822,7 +822,7 @@ static int psp_ras_initialize(struct psp_context *psp)
 
if (!psp->adev->psp.ta_ras_ucode_size ||
!psp->adev->psp.ta_ras_start_addr) {
-   dev_warn(psp->adev->dev, "RAS: ras ta ucode is not 
available\n");
+   dev_info(psp->adev->dev, "RAS: optional ras ta ucode is not 
available\n");
return 0;
}
 
@@ -906,7 +906,7 @@ static int psp_hdcp_initialize(struct psp_context *psp)
 
if (!psp->adev->psp.ta_hdcp_ucode_size ||
!psp->adev->psp.ta_hdcp_start_addr) {
-   dev_warn(psp->adev->dev, "HDCP: hdcp ta ucode is not 
available\n");
+   dev_info(psp->adev->dev, "HDCP: optional hdcp ta ucode is not 
available\n");
return 0;
}
 
@@ -1052,7 +1052,7 @@ static int psp_dtm_initialize(struct psp_context *psp)
 
if (!psp->adev->psp.ta_dtm_ucode_size ||
!psp->adev->psp.ta_dtm_start_addr) {
-   dev_warn(psp->adev->dev, "DTM: dtm ta ucode is not 
available\n");
+   dev_info(psp->adev->dev, "DTM: optional dtm ta ucode is not 
available\n");
return 0;
}
 
-- 
2.25.1

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


[PATCH] drm/amdgpu: Re-enable FRU check for most models v2

2020-04-03 Thread Kent Russell
There are 2 VG20 SKUs that do not have the FRU on there, and trying to read
that will cause a hang. For now, check for the gaming SKU until a proper
fix can be implemented. This re-enables serial number reporting for
server cards

v2: Add ASIC check

Signed-off-by: Kent Russell 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_fru_eeprom.c | 16 ++--
 1 file changed, 14 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_fru_eeprom.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_fru_eeprom.c
index bfe4259f9508..9582469a70cb 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_fru_eeprom.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_fru_eeprom.c
@@ -31,9 +31,21 @@
 
 bool is_fru_eeprom_supported(struct amdgpu_device *adev)
 {
-   /* TODO: Resolve supported ASIC type */
+   struct atom_context *atom_ctx = adev->mode_info.atom_context;
 
-   return false;
+   if (!atom_ctx)
+   return false;
+
+   /* TODO: Gaming SKUs don't have the FRU EEPROM.
+* Use this to address hangs on modprobe on gaming SKUs
+* until a proper solution can be implemented
+*/
+   if (adev->asic_type == CHIP_VEGA20)
+   if (strnstr(atom_ctx->vbios_version, "D360",
+   sizeof(atom_ctx->vbios_version)))
+   return false;
+
+   return true;
 }
 
 int amdgpu_fru_read_eeprom(struct amdgpu_device *adev, uint32_t addrptr,
-- 
2.17.1

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


[PATCH] drm/amdgpu: Re-enable FRU check for most models

2020-04-03 Thread Kent Russell
There are 2 VG20 SKUs that do not have the FRU on there, and trying to read
that will cause a hang. For now, check for the gaming SKU until a proper
fix can be implemented. This re-enables serial number reporting for
server cards

Signed-off-by: Kent Russell 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_fru_eeprom.c | 16 ++--
 1 file changed, 14 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_fru_eeprom.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_fru_eeprom.c
index bfe4259f9508..9582469a70cb 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_fru_eeprom.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_fru_eeprom.c
@@ -31,9 +31,21 @@
 
 bool is_fru_eeprom_supported(struct amdgpu_device *adev)
 {
-   /* TODO: Resolve supported ASIC type */
+   struct atom_context *atom_ctx = adev->mode_info.atom_context;
 
-   return false;
+   if (!atom_ctx)
+   return false;
+
+   /* TODO: Gaming SKUs don't have the FRU EEPROM.
+* Use this to address hangs on modprobe on gaming SKUs
+* until a proper solution can be implemented
+*/
+   if (adev->asic_type == CHIP_VEGA20)
+   if (strnstr(atom_ctx->vbios_version, "D360",
+   sizeof(atom_ctx->vbios_version)))
+   return false;
+
+   return true;
 }
 
 int amdgpu_fru_read_eeprom(struct amdgpu_device *adev, uint32_t addrptr,
-- 
2.17.1

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


amdgpu dropping load callback triggers WARN_ON in __drm_mode_object_add

2020-04-03 Thread Michel Dänzer

I'm getting the attached WARNING splats since amdgpu dropped its load
callback. They're from

WARN_ON(!dev->driver->load && dev->registered && !obj_free_cb);

in __drm_mode_object_add.

I'm not sure how to address this, since obj_free_cb is always NULL here,
and I don't think MST connectors getting added after dev->registered is
set can be avoided?


-- 
Earthling Michel Dänzer   |   https://redhat.com
Libre software enthusiast | Mesa and X developer
Apr  3 17:32:55 thor kernel: [1.593399][  T129] [ cut here 
]
Apr  3 17:32:55 thor kernel: [1.593409][  T129] WARNING: CPU: 6 PID: 129 at 
drivers/gpu/drm/drm_mode_object.c:45 __drm_mode_object_add+0xa1/0xb0 [drm]
Apr  3 17:32:55 thor kernel: [1.593409][  T129] Modules linked in: 
crc32c_intel(E) amdgpu(E) mfd_core(E) i2c_algo_bit(E) aesni_intel(E) ttm(E) 
glue_helper(E) gpu_sched(E) crypto_simd(E) cryptd(E) drm_kms_helper(E) cec(E) 
xhci_pci(E) evdev(E) psmouse(E) rc_core(E) serio_raw(E) xhci_hcd(E) usbcore(E) 
drm(E) nvme(E) nvme_core(E) t10_pi(E)
Apr  3 17:32:55 thor kernel: [1.593409][  T129] CPU: 6 PID: 129 Comm: 
kworker/6:1 Tainted: GE 5.6.0+ #1
Apr  3 17:32:55 thor kernel: [1.593409][  T129] Hardware name: LENOVO 
20NFGE/20NFGE, BIOS R11ET30W (1.10 ) 10/11/2019
Apr  3 17:32:55 thor kernel: [1.593409][  T129] Workqueue: events_long 
drm_dp_mst_link_probe_work [drm_kms_helper]
Apr  3 17:32:55 thor kernel: [1.593409][  T129] RIP: 
0010:__drm_mode_object_add+0xa1/0xb0 [drm]
Apr  3 17:32:55 thor kernel: [1.593409][  T129] Code: 00 00 4c 89 f7 e8 3f 
e4 46 ca 85 db b8 00 00 00 00 0f 4e c3 5b 5d 41 5c 41 5d 41 5e 41 5f c3 80 7f 
40 00 74 8c 4d 85 c0 75 87 <0f> 0b eb 83 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 
44 00 00 45 31
Apr  3 17:32:55 thor kernel: [1.593409][  T129] RSP: 0018:993f803e7ad8 
EFLAGS: 00010246
Apr  3 17:32:55 thor kernel: [1.593409][  T129] RAX: c0c39120 RBX: 
896166b1d000 RCX: 0001
Apr  3 17:32:55 thor kernel: [1.593409][  T129] RDX: b0b0b0b0 RSI: 
896164a7b590 RDI: 896166b1d000
Apr  3 17:32:55 thor kernel: [1.593409][  T129] RBP: 896164a7b590 R08: 
 R09: 896164a81600
Apr  3 17:32:55 thor kernel: [1.593409][  T129] R10:  R11: 
89626e0bedd7 R12: b0b0b0b0
Apr  3 17:32:55 thor kernel: [1.593409][  T129] R13:  R14: 
c0215091 R15: 0001
Apr  3 17:32:55 thor kernel: [1.593409][  T129] FS:  () 
GS:896170b8() knlGS:
Apr  3 17:32:55 thor kernel: [1.593409][  T129] CS:  0010 DS:  ES:  
CR0: 80050033
Apr  3 17:32:55 thor kernel: [1.593409][  T129] CR2: 7ffc35448de8 CR3: 
0003a6ddc000 CR4: 003406e0
Apr  3 17:32:55 thor kernel: [1.593409][  T129] Call Trace:
Apr  3 17:32:55 thor kernel: [1.593409][  T129]  
drm_property_create+0xcd/0x1a0 [drm]
Apr  3 17:32:55 thor kernel: [1.593409][  T129]  
drm_property_create_range+0x1a/0x40 [drm]
Apr  3 17:32:55 thor kernel: [1.593409][  T129]  
drm_connector_attach_max_bpc_property+0x62/0x80 [drm]
Apr  3 17:32:55 thor kernel: [1.593409][  T129]  
amdgpu_dm_connector_init_helper+0x1cd/0x280 [amdgpu]
Apr  3 17:32:55 thor kernel: [1.593409][  T129]  
dm_dp_add_mst_connector+0xbb/0x1a0 [amdgpu]
Apr  3 17:32:55 thor kernel: [1.593409][  T129]  
drm_dp_mst_port_add_connector+0x108/0x1a0 [drm_kms_helper]
Apr  3 17:32:55 thor kernel: [1.593409][  T129]  ? 
dm_dp_aux_transfer+0x8f/0xf0 [amdgpu]
Apr  3 17:32:55 thor kernel: [1.593409][  T129]  ? 
drm_dp_dpcd_access+0xdf/0x110 [drm_kms_helper]
Apr  3 17:32:55 thor kernel: [1.593409][  T129]  ? 
drm_dp_mst_add_port+0x2f/0xe0 [drm_kms_helper]
Apr  3 17:32:55 thor kernel: [1.593409][  T129]  
drm_dp_send_link_address+0x368/0x990 [drm_kms_helper]
Apr  3 17:32:55 thor kernel: [1.593409][  T129]  ? 
preempt_count_sub+0x9b/0xd0
Apr  3 17:32:55 thor kernel: [1.593409][  T129]  
drm_dp_check_and_send_link_address+0xad/0xd0 [drm_kms_helper]
Apr  3 17:32:55 thor kernel: [1.593409][  T129]  
drm_dp_mst_link_probe_work+0x94/0x180 [drm_kms_helper]
Apr  3 17:32:55 thor kernel: [1.593409][  T129]  
process_one_work+0x1ab/0x3a0
Apr  3 17:32:55 thor kernel: [1.593409][  T129]  worker_thread+0x50/0x3a0
Apr  3 17:32:55 thor kernel: [1.593409][  T129]  kthread+0xf9/0x130
Apr  3 17:32:55 thor kernel: [1.593409][  T129]  ? 
process_one_work+0x3a0/0x3a0
Apr  3 17:32:55 thor kernel: [1.593409][  T129]  ? kthread_park+0x90/0x90
Apr  3 17:32:55 thor kernel: [1.593409][  T129]  ret_from_fork+0x22/0x40
Apr  3 17:32:55 thor kernel: [1.593409][  T129] ---[ end trace 
f1dd3fe3af522768 ]---
Apr  3 17:32:55 thor kernel: [1.593816][  T129] [ cut here 
]
Apr  3 17:32:55 thor kernel: [1.593829][  T129] WARNING: CPU: 6 

Re: [PATCH] drm/amdgpu: fix size calculation in amdgpu_ttm_copy_mem_to_mem

2020-04-03 Thread Felix Kuehling
Am 2020-04-03 um 11:21 a.m. schrieb Christian König:
> When the node is larger than 4GB we overrun the size calculation.
>
> Fix this by correctly limiting the size to the window as well.
>
> Signed-off-by: Christian König 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> index 029b661faef6..1b658e905620 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> @@ -454,9 +454,9 @@ int amdgpu_ttm_copy_mem_to_mem(struct amdgpu_device *adev,
>   /* Copy size cannot exceed GTT_MAX_BYTES. So if src or dst
>* begins at an offset, then adjust the size accordingly
>*/
> - cur_size = min3(src_node_size, dst_node_size, size);
> - cur_size = min(GTT_MAX_BYTES - src_page_offset, cur_size);
> - cur_size = min(GTT_MAX_BYTES - dst_page_offset, cur_size);
> + cur_size = max(src_page_offset, dst_page_offset);
> + cur_size = min(min3(src_node_size, dst_node_size, size),
> +(uint64_t)(GTT_MAX_BYTES - cur_size));

This makes me wish for a min4 macro. I think the most efficient way to
write this would be

cur_size = min(min(src_node_size, dst_node_size),
   min(size, (uint64_t)(GTT_MAX_BYTES - cur_size)));

Either way, this patch is

Reviewed-by: Felix Kuehling 


>  
>   /* Map src to window 0 and dst to window 1. */
>   r = amdgpu_ttm_map_buffer(src->bo, src->mem, src_mm,
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


Re: [PATCH] drm/amdgpu/vcn: add shared menory restore after wake up from sleep.

2020-04-03 Thread James Zhu



On 2020-04-03 11:37 a.m., Alex Deucher wrote:

On Fri, Apr 3, 2020 at 8:52 AM James Zhu  wrote:

VCN shared memory needs restore after wake up during S3 test.

How big is the shared memory?  It might be better to allocate the
memory once at sw_init and then free it in sw_fini rather than
allocating and freeing in every suspend/resume.


Hi Alex,

After alignment, it is only 4k. I can change it as you suggest.

Best Regards!

James



Alex


Signed-off-by: James Zhu 
---
  drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c | 26 ++
  drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h |  1 +
  2 files changed, 27 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c
index d653a18..5891390 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c
@@ -205,6 +205,7 @@ int amdgpu_vcn_sw_fini(struct amdgpu_device *adev)
 if (adev->vcn.harvest_config & (1 << j))
 continue;

+   kvfree(adev->vcn.inst[j].saved_shm_bo);
 amdgpu_bo_free_kernel(>vcn.inst[j].fw_shared_bo,
   
>vcn.inst[j].fw_shared_gpu_addr,
   (void 
**)>vcn.inst[j].fw_shared_cpu_addr);
@@ -254,6 +255,18 @@ int amdgpu_vcn_suspend(struct amdgpu_device *adev)
 return -ENOMEM;

 memcpy_fromio(adev->vcn.inst[i].saved_bo, ptr, size);
+
+   if (adev->vcn.inst[i].fw_shared_bo == NULL)
+   return 0;
+
+   size = amdgpu_bo_size(adev->vcn.inst[i].fw_shared_bo);
+   ptr = adev->vcn.inst[i].fw_shared_cpu_addr;
+
+   adev->vcn.inst[i].saved_shm_bo = kvmalloc(size, GFP_KERNEL);
+   if (!adev->vcn.inst[i].saved_shm_bo)
+   return -ENOMEM;
+
+   memcpy_fromio(adev->vcn.inst[i].saved_shm_bo, ptr, size);
 }
 return 0;
  }
@@ -291,6 +304,19 @@ int amdgpu_vcn_resume(struct amdgpu_device *adev)
 }
 memset_io(ptr, 0, size);
 }
+
+   if (adev->vcn.inst[i].fw_shared_bo == NULL)
+   return -EINVAL;
+
+   size = amdgpu_bo_size(adev->vcn.inst[i].fw_shared_bo);
+   ptr = adev->vcn.inst[i].fw_shared_cpu_addr;
+
+   if (adev->vcn.inst[i].saved_shm_bo != NULL) {
+   memcpy_toio(ptr, adev->vcn.inst[i].saved_shm_bo, size);
+   kvfree(adev->vcn.inst[i].saved_shm_bo);
+   adev->vcn.inst[i].saved_shm_bo = NULL;
+   } else
+   memset_io(ptr, 0, size);
 }
 return 0;
  }
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h
index f739e1a..bd77dae 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h
@@ -194,6 +194,7 @@ struct amdgpu_vcn_inst {
 atomic_tdpg_enc_submission_cnt;
 void*fw_shared_cpu_addr;
 uint64_tfw_shared_gpu_addr;
+   void*saved_shm_bo;
  };

  struct amdgpu_vcn {
--
2.7.4

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfxdata=02%7C01%7CJames.Zhu%40amd.com%7C46c4773164334ec712b708d7d7e4ebd6%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637215250518903143sdata=Mj%2FgeXKkiNVFUUsyKAesC5eaanDg%2FvQQpQe1rhT9uek%3Dreserved=0

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


RE: [PATCH] drm/amdgpu: Re-enable FRU check for most models

2020-04-03 Thread Russell, Kent
[AMD Public Use]

There's always the possibility. I'll add it for sanity and sensibility.

Kent

From: Deucher, Alexander 
Sent: Friday, April 3, 2020 11:53 AM
To: Russell, Kent ; amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/amdgpu: Re-enable FRU check for most models


[AMD Public Use]

Does this need to be protected by a asic_type check as well or is just the 
vbios version enough?  Will we have other asics with D360 in the vbios version?

Alex


From: amd-gfx 
mailto:amd-gfx-boun...@lists.freedesktop.org>>
 on behalf of Kent Russell mailto:kent.russ...@amd.com>>
Sent: Friday, April 3, 2020 10:43 AM
To: amd-gfx@lists.freedesktop.org 
mailto:amd-gfx@lists.freedesktop.org>>
Cc: Russell, Kent mailto:kent.russ...@amd.com>>
Subject: [PATCH] drm/amdgpu: Re-enable FRU check for most models

There are 2 SKUs that do not have the FRU on there, and trying to read
that will cause a hang. For now, check for the gaming SKU until a proper
fix can be implemented. This re-enables serial number reporting for
server cards

Signed-off-by: Kent Russell mailto:kent.russ...@amd.com>>
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_fru_eeprom.c | 15 +--
 1 file changed, 13 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_fru_eeprom.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_fru_eeprom.c
index bfe4259f9508..281bdfd4630a 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_fru_eeprom.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_fru_eeprom.c
@@ -31,9 +31,20 @@

 bool is_fru_eeprom_supported(struct amdgpu_device *adev)
 {
-   /* TODO: Resolve supported ASIC type */
+   struct atom_context *atom_ctx = adev->mode_info.atom_context;

-   return false;
+   if (!atom_ctx)
+   return false;
+
+   /* TODO: Gaming SKUs don't have the FRU EEPROM.
+* Use this to address hangs on modprobe on gaming SKUs
+* until a proper solution can be implemented
+*/
+   if (strnstr(atom_ctx->vbios_version, "D360",
+   sizeof(atom_ctx->vbios_version)))
+   return false;
+
+   return true;
 }

 int amdgpu_fru_read_eeprom(struct amdgpu_device *adev, uint32_t addrptr,
--
2.17.1

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfxdata=02%7C01%7Calexander.deucher%40amd.com%7C97d3aa4c34464592264508d7d7dd69a0%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637215218317453581sdata=ABysYVGVyaYWc2HuebwGNdPbOkvC%2Fmmduk4EMROoDfw%3Dreserved=0
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


Re: [PATCH] drm/amdgpu: Re-enable FRU check for most models

2020-04-03 Thread Deucher, Alexander
[AMD Public Use]

Does this need to be protected by a asic_type check as well or is just the 
vbios version enough?  Will we have other asics with D360 in the vbios version?

Alex


From: amd-gfx  on behalf of Kent Russell 

Sent: Friday, April 3, 2020 10:43 AM
To: amd-gfx@lists.freedesktop.org 
Cc: Russell, Kent 
Subject: [PATCH] drm/amdgpu: Re-enable FRU check for most models

There are 2 SKUs that do not have the FRU on there, and trying to read
that will cause a hang. For now, check for the gaming SKU until a proper
fix can be implemented. This re-enables serial number reporting for
server cards

Signed-off-by: Kent Russell 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_fru_eeprom.c | 15 +--
 1 file changed, 13 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_fru_eeprom.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_fru_eeprom.c
index bfe4259f9508..281bdfd4630a 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_fru_eeprom.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_fru_eeprom.c
@@ -31,9 +31,20 @@

 bool is_fru_eeprom_supported(struct amdgpu_device *adev)
 {
-   /* TODO: Resolve supported ASIC type */
+   struct atom_context *atom_ctx = adev->mode_info.atom_context;

-   return false;
+   if (!atom_ctx)
+   return false;
+
+   /* TODO: Gaming SKUs don't have the FRU EEPROM.
+* Use this to address hangs on modprobe on gaming SKUs
+* until a proper solution can be implemented
+*/
+   if (strnstr(atom_ctx->vbios_version, "D360",
+   sizeof(atom_ctx->vbios_version)))
+   return false;
+
+   return true;
 }

 int amdgpu_fru_read_eeprom(struct amdgpu_device *adev, uint32_t addrptr,
--
2.17.1

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfxdata=02%7C01%7Calexander.deucher%40amd.com%7C97d3aa4c34464592264508d7d7dd69a0%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637215218317453581sdata=ABysYVGVyaYWc2HuebwGNdPbOkvC%2Fmmduk4EMROoDfw%3Dreserved=0
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


Re: [PATCH v2] drm/amdkfd: Provide SMI events watch

2020-04-03 Thread Amber Lin
Further thinking about it, I'll use struct kfd_smi_msg_header. Instead 
of using struct kfd_smi_msg_vmfault, it's a description about the event. 
This way we make it generic to all events.


On 2020-04-03 9:38 a.m., Amber Lin wrote:
Thanks Felix. I'll make changes accordingly but please pay attention 
to my last reply inline.


On 2020-04-02 7:51 p.m., Felix Kuehling wrote:

On 2020-04-02 4:46 p.m., Amber Lin wrote:
When the compute is malfunctioning or performance drops, the system 
admin
will use SMI (System Management Interface) tool to 
monitor/diagnostic what

went wrong. This patch provides an event watch interface for the user
space to register events they are interested. After the event is
registered, the user can use annoymous file descriptor's poll function
with wait-time specified to wait for the event to happen. Once the 
event

happens, the user can use read() to retrieve information related to the
event.

VM fault event is done in this patch.

v2: - remove UNREGISTER and add event ENABLE/DISABLE
 - correct kfifo usage
 - move event message API to kfd_ioctl.h

Signed-off-by: Amber Lin 
---
  drivers/gpu/drm/amd/amdkfd/Makefile  |   3 +-
  drivers/gpu/drm/amd/amdkfd/cik_event_interrupt.c |   2 +
  drivers/gpu/drm/amd/amdkfd/kfd_chardev.c |  30 
  drivers/gpu/drm/amd/amdkfd/kfd_device.c  |   1 +
  drivers/gpu/drm/amd/amdkfd/kfd_int_process_v9.c  |   2 +
  drivers/gpu/drm/amd/amdkfd/kfd_priv.h    |  12 ++
  drivers/gpu/drm/amd/amdkfd/kfd_smi_events.c  | 177 
+++

  drivers/gpu/drm/amd/amdkfd/kfd_smi_events.h  |  31 
  include/uapi/linux/kfd_ioctl.h   |  30 +++-
  9 files changed, 286 insertions(+), 2 deletions(-)
  create mode 100644 drivers/gpu/drm/amd/amdkfd/kfd_smi_events.c
  create mode 100644 drivers/gpu/drm/amd/amdkfd/kfd_smi_events.h

diff --git a/drivers/gpu/drm/amd/amdkfd/Makefile 
b/drivers/gpu/drm/amd/amdkfd/Makefile

index 6147462..cc98b4a 100644
--- a/drivers/gpu/drm/amd/amdkfd/Makefile
+++ b/drivers/gpu/drm/amd/amdkfd/Makefile
@@ -53,7 +53,8 @@ AMDKFD_FILES    := $(AMDKFD_PATH)/kfd_module.o \
  $(AMDKFD_PATH)/kfd_int_process_v9.o \
  $(AMDKFD_PATH)/kfd_dbgdev.o \
  $(AMDKFD_PATH)/kfd_dbgmgr.o \
-    $(AMDKFD_PATH)/kfd_crat.o
+    $(AMDKFD_PATH)/kfd_crat.o \
+    $(AMDKFD_PATH)/kfd_smi_events.o
    ifneq ($(CONFIG_AMD_IOMMU_V2),)
  AMDKFD_FILES += $(AMDKFD_PATH)/kfd_iommu.o
diff --git a/drivers/gpu/drm/amd/amdkfd/cik_event_interrupt.c 
b/drivers/gpu/drm/amd/amdkfd/cik_event_interrupt.c

index 9f59ba9..24b4717 100644
--- a/drivers/gpu/drm/amd/amdkfd/cik_event_interrupt.c
+++ b/drivers/gpu/drm/amd/amdkfd/cik_event_interrupt.c
@@ -24,6 +24,7 @@
  #include "kfd_events.h"
  #include "cik_int.h"
  #include "amdgpu_amdkfd.h"
+#include "kfd_smi_events.h"
    static bool cik_event_interrupt_isr(struct kfd_dev *dev,
  const uint32_t *ih_ring_entry,
@@ -107,6 +108,7 @@ static void cik_event_interrupt_wq(struct 
kfd_dev *dev,

  ihre->source_id == CIK_INTSRC_GFX_MEM_PROT_FAULT) {
  struct kfd_vm_fault_info info;
  +    kfd_smi_event_update_vmfault(dev, pasid);
  kfd_process_vm_fault(dev->dqm, pasid);
    memset(, 0, sizeof(info));
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c 
b/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c

index f8fa03a..591ac28 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
@@ -39,6 +39,7 @@
  #include "kfd_device_queue_manager.h"
  #include "kfd_dbgmgr.h"
  #include "amdgpu_amdkfd.h"
+#include "kfd_smi_events.h"
    static long kfd_ioctl(struct file *, unsigned int, unsigned long);
  static int kfd_open(struct inode *, struct file *);
@@ -1243,6 +1244,32 @@ static int kfd_ioctl_acquire_vm(struct file 
*filep, struct kfd_process *p,

  return ret;
  }
  +/* Handle requests for watching SMI events */
+static int kfd_ioctl_smi_events(struct file *filep,
+    struct kfd_process *p, void *data)
+{
+    struct kfd_ioctl_smi_events_args *args = data;
+    struct kfd_dev *dev;
+
+    dev = kfd_device_by_id(args->gpu_id);
+    if (!dev)
+    return -EINVAL;
+
+    switch (args->op) {
+    case KFD_SMI_EVENTS_REGISTER:
+    /* register the device */
+    return kfd_smi_event_register(dev, >data);
+    case KFD_SMI_EVENTS_ENABLE:
+    /* subscribe events to the device */
+    return kfd_smi_event_enable(dev, args->events);
+    case KFD_SMI_EVENTS_DISABLE:
+    /* unsubscribe events */
+    return kfd_smi_event_disable(dev, args->events);
+    }
+
+    return -EINVAL;
+}
+
  bool kfd_dev_is_large_bar(struct kfd_dev *dev)
  {
  struct kfd_local_mem_info mem_info;
@@ -1827,6 +1854,9 @@ static const struct amdkfd_ioctl_desc 
amdkfd_ioctls[] = {

    AMDKFD_IOCTL_DEF(AMDKFD_IOC_ALLOC_QUEUE_GWS,
  kfd_ioctl_alloc_queue_gws, 0),
+
+    AMDKFD_IOCTL_DEF(AMDKFD_IOC_SMI_EVENTS,
+    

Re: [PATCH] drm/amdgpu/vcn: add shared menory restore after wake up from sleep.

2020-04-03 Thread Alex Deucher
On Fri, Apr 3, 2020 at 8:52 AM James Zhu  wrote:
>
> VCN shared memory needs restore after wake up during S3 test.

How big is the shared memory?  It might be better to allocate the
memory once at sw_init and then free it in sw_fini rather than
allocating and freeing in every suspend/resume.

Alex

>
> Signed-off-by: James Zhu 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c | 26 ++
>  drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h |  1 +
>  2 files changed, 27 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c
> index d653a18..5891390 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c
> @@ -205,6 +205,7 @@ int amdgpu_vcn_sw_fini(struct amdgpu_device *adev)
> if (adev->vcn.harvest_config & (1 << j))
> continue;
>
> +   kvfree(adev->vcn.inst[j].saved_shm_bo);
> amdgpu_bo_free_kernel(>vcn.inst[j].fw_shared_bo,
>   
> >vcn.inst[j].fw_shared_gpu_addr,
>   (void 
> **)>vcn.inst[j].fw_shared_cpu_addr);
> @@ -254,6 +255,18 @@ int amdgpu_vcn_suspend(struct amdgpu_device *adev)
> return -ENOMEM;
>
> memcpy_fromio(adev->vcn.inst[i].saved_bo, ptr, size);
> +
> +   if (adev->vcn.inst[i].fw_shared_bo == NULL)
> +   return 0;
> +
> +   size = amdgpu_bo_size(adev->vcn.inst[i].fw_shared_bo);
> +   ptr = adev->vcn.inst[i].fw_shared_cpu_addr;
> +
> +   adev->vcn.inst[i].saved_shm_bo = kvmalloc(size, GFP_KERNEL);
> +   if (!adev->vcn.inst[i].saved_shm_bo)
> +   return -ENOMEM;
> +
> +   memcpy_fromio(adev->vcn.inst[i].saved_shm_bo, ptr, size);
> }
> return 0;
>  }
> @@ -291,6 +304,19 @@ int amdgpu_vcn_resume(struct amdgpu_device *adev)
> }
> memset_io(ptr, 0, size);
> }
> +
> +   if (adev->vcn.inst[i].fw_shared_bo == NULL)
> +   return -EINVAL;
> +
> +   size = amdgpu_bo_size(adev->vcn.inst[i].fw_shared_bo);
> +   ptr = adev->vcn.inst[i].fw_shared_cpu_addr;
> +
> +   if (adev->vcn.inst[i].saved_shm_bo != NULL) {
> +   memcpy_toio(ptr, adev->vcn.inst[i].saved_shm_bo, 
> size);
> +   kvfree(adev->vcn.inst[i].saved_shm_bo);
> +   adev->vcn.inst[i].saved_shm_bo = NULL;
> +   } else
> +   memset_io(ptr, 0, size);
> }
> return 0;
>  }
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h
> index f739e1a..bd77dae 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h
> @@ -194,6 +194,7 @@ struct amdgpu_vcn_inst {
> atomic_tdpg_enc_submission_cnt;
> void*fw_shared_cpu_addr;
> uint64_tfw_shared_gpu_addr;
> +   void*saved_shm_bo;
>  };
>
>  struct amdgpu_vcn {
> --
> 2.7.4
>
> ___
> 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/amdgpu: fix size calculation in amdgpu_ttm_copy_mem_to_mem

2020-04-03 Thread Christian König
When the node is larger than 4GB we overrun the size calculation.

Fix this by correctly limiting the size to the window as well.

Signed-off-by: Christian König 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index 029b661faef6..1b658e905620 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -454,9 +454,9 @@ int amdgpu_ttm_copy_mem_to_mem(struct amdgpu_device *adev,
/* Copy size cannot exceed GTT_MAX_BYTES. So if src or dst
 * begins at an offset, then adjust the size accordingly
 */
-   cur_size = min3(src_node_size, dst_node_size, size);
-   cur_size = min(GTT_MAX_BYTES - src_page_offset, cur_size);
-   cur_size = min(GTT_MAX_BYTES - dst_page_offset, cur_size);
+   cur_size = max(src_page_offset, dst_page_offset);
+   cur_size = min(min3(src_node_size, dst_node_size, size),
+  (uint64_t)(GTT_MAX_BYTES - cur_size));
 
/* Map src to window 0 and dst to window 1. */
r = amdgpu_ttm_map_buffer(src->bo, src->mem, src_mm,
-- 
2.17.1

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


[PATCH] drm/amdgpu: Fix oops when pp_funcs is unset in ACPI event

2020-04-03 Thread Aaron Ma
On ARCTURUS and RENOIR, powerplay is not supported yet.
When plug in or unplug power jack, ACPI event will issue.
Then kernel NULL pointer BUG will be triggered.
Check for NULL pointers before calling.

Signed-off-by: Aaron Ma 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
index f197f1be0969..611de69f9d48 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
@@ -89,7 +89,8 @@ void amdgpu_pm_acpi_event_handler(struct amdgpu_device *adev)
adev->pm.ac_power = true;
else
adev->pm.ac_power = false;
-   if (adev->powerplay.pp_funcs->enable_bapm)
+   if (adev->powerplay.pp_funcs &&
+   adev->powerplay.pp_funcs->enable_bapm)
amdgpu_dpm_enable_bapm(adev, adev->pm.ac_power);
mutex_unlock(>pm.mutex);
 
-- 
2.17.1

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


Re: AMD DC graphics display code enables -mhard-float, -msse, -msse2 without any visible FPU state protection

2020-04-03 Thread Peter Zijlstra
On Fri, Apr 03, 2020 at 02:28:37PM +0900, Masami Hiramatsu wrote:
> On Thu, 2 Apr 2020 16:13:08 +0200
> Peter Zijlstra  wrote:

> > Masami, Boris, is there any semi-sane way we can have insn_is_fpu() ?
> > While digging through various opcode manuals is of course forever fun, I
> > do feel like it might not be the best way.
> 
> Yes, it is possible to add INAT_FPU and insn_is_fpu().
> But it seems that the below patch needs more classification based on
> nmemonic or opcodes.

I went with opcode, and I think I did a fairly decent job, but I did
find a few problems on a second look at things.

I don't think nmemonic are going to help, the x86 nmemonics are a mess
(much like its opcode tables), there's no way to sanely detect what
registers are effected by an instruction based on name.

The best I came up with is operand class, see below.

> IMHO, it is the time to expand gen-insn-attr.awk or clone it to
> generate another opcode map, so that user will easily extend the
> insn infrastructure.
> (e.g. I had made an in-kernel disassembler, which generates a mnemonic
>  maps from x86-opcode-map.txt)
>  https://github.com/mhiramat/linux/commits/inkernel-disasm-20130414

Cute, and I'm thinking we might want that eventually, people have been
asking for a kernel specific objdump, one that knows about and shows all
the magical things the kernel does, like alternative, jump-labels and
soon the static_call stuff, but also things like the exception handling.

Objtool actually knows about much of that, and pairing it with your
disassembler could print it.

> > +   if (insn.vex_prefix.nbytes) {
> > +   *type = INSN_FPU;
> > return 0;
> > +   }

So that's the AVX nonsense dealt with; right until they stick an integer
instruction in the AVX space I suppose :/ Please tell me they didn't
already do that..

> >  
> > op1 = insn.opcode.bytes[0];
> > op2 = insn.opcode.bytes[1];
> > @@ -357,48 +359,71 @@ int arch_decode_instruction(struct elf *elf, struct 
> > section *sec,
> >  
> > case 0x0f:
> >  
> > +   switch (op2) {

> > +   case 0xae:
> > +   /* insane!! */
> > +   if ((modrm_reg >= 0 && modrm_reg <= 3) && modrm_mod != 
> > 3 && !insn.prefixes.nbytes)
> > +   *type = INSN_FPU;
> > +   break;

This is crazy, but I was trying to get at the x86 FPU control
instructions:

  FXSAVE, FXRSTOR, LDMXCSR and STMXCSR

Which are in Grp15

Now arguably, I could skip them, the compiler should never emit those,
and the newer, fancier, XSAV family isn't marked as FPU either, even
though it will save/restore the FPU/MMX/SSE/AVX states too.

So I think I'll remove this part, it'll also make the fpu_safe
annotations easier.

> > +   case 0x10 ... 0x17:
> > +   case 0x28 ... 0x2f:
> > +   case 0x3a:
> > +   case 0x50 ... 0x77:
> > +   case 0x7a ... 0x7f:
> > +   case 0xc2:
> > +   case 0xc4 ... 0xc6:
> > +   case 0xd0 ... 0xff:
> > +   /* MMX, SSE, VMX */

So afaict these are the MMX and SSE instruction (clearly the VMX is my
brain loosing it).

I went with the coder64 opcode tables, but our x86-opcode-map.txt seems
to agree, mostly.

I now see that 0f 3a is not all mmx/sse, it also includes RORX which is
an integer instruction. Also, may I state that the opcode map is a
sodding disgrace? Why is an integer instruction stuck in the middle of
SSE instructions like that ?!?!

And I should shorten the last range to 0xd0 ... 0xfe, as 0f ff is UD0.

Other than that I think this is pretty accurate.

> > +   *type = INSN_FPU;
> > +   break;
> > +
> > +   default:
> > +   break;
> > +   }
> > break;
> >  
> > case 0xc9:
> > @@ -414,6 +439,10 @@ int arch_decode_instruction(struct elf *elf, struct 
> > section *sec,
> >  
> > break;
> >  
> > +   case 0xd8 ... 0xdf: /* x87 FPU range */
> > +   *type = INSN_FPU;
> > +   break;

Our x86-opcode-map.txt lists that as ESC, but doesn't have an escape
table for it. Per:

  http://ref.x86asm.net/coder64.html

these are all the traditional x87 FPU ops.


> > +
> > case 0xe3:
> > /* jecxz/jrcxz */
> > *type = INSN_JUMP_CONDITIONAL;


Now; I suppose I need our x86-opcode-map.txt extended in at least two
ways:

 - all those x87 FPU instructions need adding
 - a way of detecting the affected register set

Now, I suspect we can do that latter by the instruction operands that
are already there, although I've not managed to untangle them fully
(hint, we really should improve the comments on top). Operands seem to
have one capital that denotes the class:

 - I: immediate
 - G: general purpose
 - E
 - P,Q: MMX
 - V,M,W,H: SSE

So if we can extend the awk magic to provide operand classes for each
decoded instruction, then that would simplify this lots.

New version below...

---
--- 

Re: [PATCH] drm/amdgpu: add SPM golden settings for Navi10

2020-04-03 Thread Alex Deucher
On Fri, Apr 3, 2020 at 1:30 AM Tianci Yin  wrote:
>
> From: "Tianci.Yin" 
>
> Add RLC_SPM golden settings
>
> Change-Id: I616e127171293d915cb3a05dee02f51cec8d8f6f
> Signed-off-by: Tianci.Yin 
> ---
>  drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c|9 +
>  .../gpu/drm/amd/amdgpu/golden_gc_spm_10_1_0.h | 1058 +
>  2 files changed, 1067 insertions(+)
>  create mode 100644 drivers/gpu/drm/amd/amdgpu/golden_gc_spm_10_1_0.h
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c 
> b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
> index 70edbbf84338..7c96a894ad37 100644
> --- a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
> @@ -48,6 +48,7 @@
>  #include "v10_structs.h"
>  #include "gfx_v10_0.h"
>  #include "nbio_v2_3.h"
> +#include "golden_gc_spm_10_1_0.h"

Can we just include the table directly in this file instead of a
separate header?  One more comment below.

>
>  /**
>   * Navi10 has two graphic rings to share each graphic pipe.
> @@ -138,6 +139,11 @@ static const struct soc15_reg_golden 
> golden_settings_gc_10_0_nv10[] =
> /* Pending on emulation bring up */
>  };
>
> +static const struct soc15_reg_golden golden_settings_gc_rlc_spm_10_0_nv10[] =
> +{
> +   GOLDEN_GC_SPM_10_1_0
> +};
> +
>  static const struct soc15_reg_golden golden_settings_gc_10_1_1[] =
>  {
> SOC15_REG_GOLDEN_VALUE(GC, 0, mmCB_HW_CONTROL_4, 0x, 
> 0x003c0014),
> @@ -388,6 +394,9 @@ static void gfx_v10_0_init_golden_registers(struct 
> amdgpu_device *adev)
> soc15_program_register_sequence(adev,
> golden_settings_gc_10_0_nv10,
> (const 
> u32)ARRAY_SIZE(golden_settings_gc_10_0_nv10));
> +   soc15_program_register_sequence(adev,
> +   
> golden_settings_gc_rlc_spm_10_0_nv10,
> +   (const 
> u32)ARRAY_SIZE(golden_settings_gc_rlc_spm_10_0_nv10));
> break;
> case CHIP_NAVI14:
> soc15_program_register_sequence(adev,
> diff --git a/drivers/gpu/drm/amd/amdgpu/golden_gc_spm_10_1_0.h 
> b/drivers/gpu/drm/amd/amdgpu/golden_gc_spm_10_1_0.h
> new file mode 100644
> index ..e65af4a6fcdd
> --- /dev/null
> +++ b/drivers/gpu/drm/amd/amdgpu/golden_gc_spm_10_1_0.h

This file is missing a license.

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


Re: [PATCH] drm/amd/powerplay: error out on forcing clock setting not supported

2020-04-03 Thread Deucher, Alexander
[AMD Public Use]

Reviewed-by: Alex Deucher 

From: Quan, Evan 
Sent: Friday, April 3, 2020 3:03 AM
To: amd-gfx@lists.freedesktop.org 
Cc: Russell, Kent ; Deucher, Alexander 
; Quan, Evan 
Subject: [PATCH] drm/amd/powerplay: error out on forcing clock setting not 
supported

For Arcturus, forcing clock to some specific level is not supported
with 54.18 and onwards SMU firmware. As according to firmware team,
they adopt new gfx dpm tuned parameters which can cover all the use
case in a much smooth way. Thus setting through driver interface
is not needed and maybe do a disservice.

Change-Id: Ibffdb157639809707aa71049a935e53d1b4d06eb
Signed-off-by: Evan Quan 
---
 drivers/gpu/drm/amd/powerplay/arcturus_ppt.c | 47 +++-
 1 file changed, 46 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/powerplay/arcturus_ppt.c 
b/drivers/gpu/drm/amd/powerplay/arcturus_ppt.c
index 5db8c56066ee..1ef0923f7190 100644
--- a/drivers/gpu/drm/amd/powerplay/arcturus_ppt.c
+++ b/drivers/gpu/drm/amd/powerplay/arcturus_ppt.c
@@ -794,8 +794,21 @@ static int arcturus_force_clk_levels(struct smu_context 
*smu,
 struct arcturus_dpm_table *dpm_table;
 struct arcturus_single_dpm_table *single_dpm_table;
 uint32_t soft_min_level, soft_max_level;
+   uint32_t smu_version;
 int ret = 0;

+   ret = smu_get_smc_version(smu, NULL, _version);
+   if (ret) {
+   pr_err("Failed to get smu version!\n");
+   return ret;
+   }
+
+   if (smu_version >= 0x361200) {
+   pr_err("Forcing clock level is not supported with "
+  "54.18 and onwards SMU firmwares\n");
+   return -EOPNOTSUPP;
+   }
+
 soft_min_level = mask ? (ffs(mask) - 1) : 0;
 soft_max_level = mask ? (fls(mask) - 1) : 0;

@@ -1512,6 +1525,38 @@ static int arcturus_set_power_profile_mode(struct 
smu_context *smu,
 return 0;
 }

+static int arcturus_set_performance_level(struct smu_context *smu,
+ enum amd_dpm_forced_level level)
+{
+   uint32_t smu_version;
+   int ret;
+
+   ret = smu_get_smc_version(smu, NULL, _version);
+   if (ret) {
+   pr_err("Failed to get smu version!\n");
+   return ret;
+   }
+
+   switch (level) {
+   case AMD_DPM_FORCED_LEVEL_HIGH:
+   case AMD_DPM_FORCED_LEVEL_LOW:
+   case AMD_DPM_FORCED_LEVEL_PROFILE_STANDARD:
+   case AMD_DPM_FORCED_LEVEL_PROFILE_MIN_SCLK:
+   case AMD_DPM_FORCED_LEVEL_PROFILE_MIN_MCLK:
+   case AMD_DPM_FORCED_LEVEL_PROFILE_PEAK:
+   if (smu_version >= 0x361200) {
+   pr_err("Forcing clock level is not supported with "
+  "54.18 and onwards SMU firmwares\n");
+   return -EOPNOTSUPP;
+   }
+   break;
+   default:
+   break;
+   }
+
+   return smu_v11_0_set_performance_level(smu, level);
+}
+
 static void arcturus_dump_pptable(struct smu_context *smu)
 {
 struct smu_table_context *table_context = >smu_table;
@@ -2285,7 +2330,7 @@ static const struct pptable_funcs arcturus_ppt_funcs = {
 .get_profiling_clk_mask = arcturus_get_profiling_clk_mask,
 .get_power_profile_mode = arcturus_get_power_profile_mode,
 .set_power_profile_mode = arcturus_set_power_profile_mode,
-   .set_performance_level = smu_v11_0_set_performance_level,
+   .set_performance_level = arcturus_set_performance_level,
 /* debug (internal used) */
 .dump_pptable = arcturus_dump_pptable,
 .get_power_limit = arcturus_get_power_limit,
--
2.26.0

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


[PATCH] drm/amdgpu: Re-enable FRU check for most models

2020-04-03 Thread Kent Russell
There are 2 SKUs that do not have the FRU on there, and trying to read
that will cause a hang. For now, check for the gaming SKU until a proper
fix can be implemented. This re-enables serial number reporting for
server cards

Signed-off-by: Kent Russell 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_fru_eeprom.c | 15 +--
 1 file changed, 13 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_fru_eeprom.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_fru_eeprom.c
index bfe4259f9508..281bdfd4630a 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_fru_eeprom.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_fru_eeprom.c
@@ -31,9 +31,20 @@
 
 bool is_fru_eeprom_supported(struct amdgpu_device *adev)
 {
-   /* TODO: Resolve supported ASIC type */
+   struct atom_context *atom_ctx = adev->mode_info.atom_context;
 
-   return false;
+   if (!atom_ctx)
+   return false;
+
+   /* TODO: Gaming SKUs don't have the FRU EEPROM.
+* Use this to address hangs on modprobe on gaming SKUs
+* until a proper solution can be implemented
+*/
+   if (strnstr(atom_ctx->vbios_version, "D360",
+   sizeof(atom_ctx->vbios_version)))
+   return false;
+
+   return true;
 }
 
 int amdgpu_fru_read_eeprom(struct amdgpu_device *adev, uint32_t addrptr,
-- 
2.17.1

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


Re: [Mesa-dev] [Intel-gfx] gitlab.fd.o financial situation and impact on services

2020-04-03 Thread Michel Dänzer
On 2020-03-01 6:46 a.m., Marek Olšák wrote:
> For Mesa, we could run CI only when Marge pushes, so that it's a strictly
> pre-merge CI.

Thanks for the suggestion! I implemented something like this for Mesa:

https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4432


-- 
Earthling Michel Dänzer   |   https://redhat.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 v2] drm/amdkfd: Provide SMI events watch

2020-04-03 Thread Amber Lin
Thanks Felix. I'll make changes accordingly but please pay attention to 
my last reply inline.


On 2020-04-02 7:51 p.m., Felix Kuehling wrote:

On 2020-04-02 4:46 p.m., Amber Lin wrote:
When the compute is malfunctioning or performance drops, the system 
admin
will use SMI (System Management Interface) tool to monitor/diagnostic 
what

went wrong. This patch provides an event watch interface for the user
space to register events they are interested. After the event is
registered, the user can use annoymous file descriptor's poll function
with wait-time specified to wait for the event to happen. Once the event
happens, the user can use read() to retrieve information related to the
event.

VM fault event is done in this patch.

v2: - remove UNREGISTER and add event ENABLE/DISABLE
 - correct kfifo usage
 - move event message API to kfd_ioctl.h

Signed-off-by: Amber Lin 
---
  drivers/gpu/drm/amd/amdkfd/Makefile  |   3 +-
  drivers/gpu/drm/amd/amdkfd/cik_event_interrupt.c |   2 +
  drivers/gpu/drm/amd/amdkfd/kfd_chardev.c |  30 
  drivers/gpu/drm/amd/amdkfd/kfd_device.c  |   1 +
  drivers/gpu/drm/amd/amdkfd/kfd_int_process_v9.c  |   2 +
  drivers/gpu/drm/amd/amdkfd/kfd_priv.h    |  12 ++
  drivers/gpu/drm/amd/amdkfd/kfd_smi_events.c  | 177 
+++

  drivers/gpu/drm/amd/amdkfd/kfd_smi_events.h  |  31 
  include/uapi/linux/kfd_ioctl.h   |  30 +++-
  9 files changed, 286 insertions(+), 2 deletions(-)
  create mode 100644 drivers/gpu/drm/amd/amdkfd/kfd_smi_events.c
  create mode 100644 drivers/gpu/drm/amd/amdkfd/kfd_smi_events.h

diff --git a/drivers/gpu/drm/amd/amdkfd/Makefile 
b/drivers/gpu/drm/amd/amdkfd/Makefile

index 6147462..cc98b4a 100644
--- a/drivers/gpu/drm/amd/amdkfd/Makefile
+++ b/drivers/gpu/drm/amd/amdkfd/Makefile
@@ -53,7 +53,8 @@ AMDKFD_FILES    := $(AMDKFD_PATH)/kfd_module.o \
  $(AMDKFD_PATH)/kfd_int_process_v9.o \
  $(AMDKFD_PATH)/kfd_dbgdev.o \
  $(AMDKFD_PATH)/kfd_dbgmgr.o \
-    $(AMDKFD_PATH)/kfd_crat.o
+    $(AMDKFD_PATH)/kfd_crat.o \
+    $(AMDKFD_PATH)/kfd_smi_events.o
    ifneq ($(CONFIG_AMD_IOMMU_V2),)
  AMDKFD_FILES += $(AMDKFD_PATH)/kfd_iommu.o
diff --git a/drivers/gpu/drm/amd/amdkfd/cik_event_interrupt.c 
b/drivers/gpu/drm/amd/amdkfd/cik_event_interrupt.c

index 9f59ba9..24b4717 100644
--- a/drivers/gpu/drm/amd/amdkfd/cik_event_interrupt.c
+++ b/drivers/gpu/drm/amd/amdkfd/cik_event_interrupt.c
@@ -24,6 +24,7 @@
  #include "kfd_events.h"
  #include "cik_int.h"
  #include "amdgpu_amdkfd.h"
+#include "kfd_smi_events.h"
    static bool cik_event_interrupt_isr(struct kfd_dev *dev,
  const uint32_t *ih_ring_entry,
@@ -107,6 +108,7 @@ static void cik_event_interrupt_wq(struct kfd_dev 
*dev,

  ihre->source_id == CIK_INTSRC_GFX_MEM_PROT_FAULT) {
  struct kfd_vm_fault_info info;
  +    kfd_smi_event_update_vmfault(dev, pasid);
  kfd_process_vm_fault(dev->dqm, pasid);
    memset(, 0, sizeof(info));
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c 
b/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c

index f8fa03a..591ac28 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
@@ -39,6 +39,7 @@
  #include "kfd_device_queue_manager.h"
  #include "kfd_dbgmgr.h"
  #include "amdgpu_amdkfd.h"
+#include "kfd_smi_events.h"
    static long kfd_ioctl(struct file *, unsigned int, unsigned long);
  static int kfd_open(struct inode *, struct file *);
@@ -1243,6 +1244,32 @@ static int kfd_ioctl_acquire_vm(struct file 
*filep, struct kfd_process *p,

  return ret;
  }
  +/* Handle requests for watching SMI events */
+static int kfd_ioctl_smi_events(struct file *filep,
+    struct kfd_process *p, void *data)
+{
+    struct kfd_ioctl_smi_events_args *args = data;
+    struct kfd_dev *dev;
+
+    dev = kfd_device_by_id(args->gpu_id);
+    if (!dev)
+    return -EINVAL;
+
+    switch (args->op) {
+    case KFD_SMI_EVENTS_REGISTER:
+    /* register the device */
+    return kfd_smi_event_register(dev, >data);
+    case KFD_SMI_EVENTS_ENABLE:
+    /* subscribe events to the device */
+    return kfd_smi_event_enable(dev, args->events);
+    case KFD_SMI_EVENTS_DISABLE:
+    /* unsubscribe events */
+    return kfd_smi_event_disable(dev, args->events);
+    }
+
+    return -EINVAL;
+}
+
  bool kfd_dev_is_large_bar(struct kfd_dev *dev)
  {
  struct kfd_local_mem_info mem_info;
@@ -1827,6 +1854,9 @@ static const struct amdkfd_ioctl_desc 
amdkfd_ioctls[] = {

    AMDKFD_IOCTL_DEF(AMDKFD_IOC_ALLOC_QUEUE_GWS,
  kfd_ioctl_alloc_queue_gws, 0),
+
+    AMDKFD_IOCTL_DEF(AMDKFD_IOC_SMI_EVENTS,
+    kfd_ioctl_smi_events, 0),
  };
    #define AMDKFD_CORE_IOCTL_COUNT    ARRAY_SIZE(amdkfd_ioctls)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_device.c 
b/drivers/gpu/drm/amd/amdkfd/kfd_device.c

index 0491ab2..6ac6f31 100644
--- 

Re: [PATCH 0/6] refine register access interfaces

2020-04-03 Thread Christian König

Acked-by: Christian König  for patches #1, #2

Reviewed-by: Christian König  for patches #3 - #6

Regards,
Christian.

Am 03.04.20 um 12:55 schrieb Hawking Zhang:

The series refined register access interfaces including:
1. add indirect access support to registers outside of mmio bar
2. remove the inproper workaround leaving in the low level if
3. retire legacy interface RREG32_IDX/WREG32_IDX
4. retire redundant flags AMDGPU_REGS_KIQ/AMDGPU_REGS_IDX

Hawking Zhang (6):
   drm/amdgpu: remove inproper workaround for vega10
   drm/amdgpu: replace indirect mmio access in non-dc code path
   drm/amdgpu: retire indirect mmio reg support from cgs
   drm/amdgpu: retire RREG32_IDX/WREG32_IDX
   drm/amdgpu: retire AMDGPU_REGS_KIQ flag
   drm/amdgpu: support access regs outside of mmio bar

  drivers/gpu/drm/amd/amdgpu/amdgpu.h| 29 +
  drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c|  8 ++--
  drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 69 +-
  drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h  |  4 +-
  drivers/gpu/drm/amd/amdgpu/dce_v10_0.c |  8 ++--
  drivers/gpu/drm/amd/amdgpu/dce_v11_0.c |  8 ++--
  drivers/gpu/drm/amd/amdgpu/dce_v6_0.c  | 14 +++---
  drivers/gpu/drm/amd/amdgpu/dce_v8_0.c  | 14 +++---
  drivers/gpu/drm/amd/include/cgs_common.h   |  1 -
  9 files changed, 60 insertions(+), 95 deletions(-)



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


RE: [PATCH] drm/amdgpu/vcn: add shared menory restore after wake up from sleep.

2020-04-03 Thread Xu, Feifei
[AMD Official Use Only - Internal Distribution Only]



Reviewed-by: Feifei Xu 

-Original Message-
From: amd-gfx  On Behalf Of James Zhu
Sent: 2020年4月3日 20:52
To: amd-gfx@lists.freedesktop.org
Cc: Li, Pauline ; Zhu, James 
Subject: [PATCH] drm/amdgpu/vcn: add shared menory restore after wake up from 
sleep.

VCN shared memory needs restore after wake up during S3 test.

Signed-off-by: James Zhu 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c | 26 ++  
drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h |  1 +
 2 files changed, 27 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c
index d653a18..5891390 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c
@@ -205,6 +205,7 @@ int amdgpu_vcn_sw_fini(struct amdgpu_device *adev)
if (adev->vcn.harvest_config & (1 << j))
continue;
 
+   kvfree(adev->vcn.inst[j].saved_shm_bo);
amdgpu_bo_free_kernel(>vcn.inst[j].fw_shared_bo,
  >vcn.inst[j].fw_shared_gpu_addr,
  (void 
**)>vcn.inst[j].fw_shared_cpu_addr);
@@ -254,6 +255,18 @@ int amdgpu_vcn_suspend(struct amdgpu_device *adev)
return -ENOMEM;
 
memcpy_fromio(adev->vcn.inst[i].saved_bo, ptr, size);
+
+   if (adev->vcn.inst[i].fw_shared_bo == NULL)
+   return 0;
+
+   size = amdgpu_bo_size(adev->vcn.inst[i].fw_shared_bo);
+   ptr = adev->vcn.inst[i].fw_shared_cpu_addr;
+
+   adev->vcn.inst[i].saved_shm_bo = kvmalloc(size, GFP_KERNEL);
+   if (!adev->vcn.inst[i].saved_shm_bo)
+   return -ENOMEM;
+
+   memcpy_fromio(adev->vcn.inst[i].saved_shm_bo, ptr, size);
}
return 0;
 }
@@ -291,6 +304,19 @@ int amdgpu_vcn_resume(struct amdgpu_device *adev)
}
memset_io(ptr, 0, size);
}
+
+   if (adev->vcn.inst[i].fw_shared_bo == NULL)
+   return -EINVAL;
+
+   size = amdgpu_bo_size(adev->vcn.inst[i].fw_shared_bo);
+   ptr = adev->vcn.inst[i].fw_shared_cpu_addr;
+
+   if (adev->vcn.inst[i].saved_shm_bo != NULL) {
+   memcpy_toio(ptr, adev->vcn.inst[i].saved_shm_bo, size);
+   kvfree(adev->vcn.inst[i].saved_shm_bo);
+   adev->vcn.inst[i].saved_shm_bo = NULL;
+   } else
+   memset_io(ptr, 0, size);
}
return 0;
 }
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h
index f739e1a..bd77dae 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h
@@ -194,6 +194,7 @@ struct amdgpu_vcn_inst {
atomic_tdpg_enc_submission_cnt;
void*fw_shared_cpu_addr;
uint64_tfw_shared_gpu_addr;
+   void*saved_shm_bo;
 };
 
 struct amdgpu_vcn {
--
2.7.4

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfxdata=02%7C01%7CFeifei.Xu%40amd.com%7C6de5512ca8574257613108d7d7cdd780%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637215152681686620sdata=X07gFq7Cf1swi%2FVtOl0ldpaOsbtC3gO5BPUlYwxrano%3Dreserved=0
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


[PATCH] drm/amdgpu/vcn: add shared menory restore after wake up from sleep.

2020-04-03 Thread James Zhu
VCN shared memory needs restore after wake up during S3 test.

Signed-off-by: James Zhu 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c | 26 ++
 drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h |  1 +
 2 files changed, 27 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c
index d653a18..5891390 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c
@@ -205,6 +205,7 @@ int amdgpu_vcn_sw_fini(struct amdgpu_device *adev)
if (adev->vcn.harvest_config & (1 << j))
continue;
 
+   kvfree(adev->vcn.inst[j].saved_shm_bo);
amdgpu_bo_free_kernel(>vcn.inst[j].fw_shared_bo,
  >vcn.inst[j].fw_shared_gpu_addr,
  (void 
**)>vcn.inst[j].fw_shared_cpu_addr);
@@ -254,6 +255,18 @@ int amdgpu_vcn_suspend(struct amdgpu_device *adev)
return -ENOMEM;
 
memcpy_fromio(adev->vcn.inst[i].saved_bo, ptr, size);
+
+   if (adev->vcn.inst[i].fw_shared_bo == NULL)
+   return 0;
+
+   size = amdgpu_bo_size(adev->vcn.inst[i].fw_shared_bo);
+   ptr = adev->vcn.inst[i].fw_shared_cpu_addr;
+
+   adev->vcn.inst[i].saved_shm_bo = kvmalloc(size, GFP_KERNEL);
+   if (!adev->vcn.inst[i].saved_shm_bo)
+   return -ENOMEM;
+
+   memcpy_fromio(adev->vcn.inst[i].saved_shm_bo, ptr, size);
}
return 0;
 }
@@ -291,6 +304,19 @@ int amdgpu_vcn_resume(struct amdgpu_device *adev)
}
memset_io(ptr, 0, size);
}
+
+   if (adev->vcn.inst[i].fw_shared_bo == NULL)
+   return -EINVAL;
+
+   size = amdgpu_bo_size(adev->vcn.inst[i].fw_shared_bo);
+   ptr = adev->vcn.inst[i].fw_shared_cpu_addr;
+
+   if (adev->vcn.inst[i].saved_shm_bo != NULL) {
+   memcpy_toio(ptr, adev->vcn.inst[i].saved_shm_bo, size);
+   kvfree(adev->vcn.inst[i].saved_shm_bo);
+   adev->vcn.inst[i].saved_shm_bo = NULL;
+   } else
+   memset_io(ptr, 0, size);
}
return 0;
 }
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h
index f739e1a..bd77dae 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h
@@ -194,6 +194,7 @@ struct amdgpu_vcn_inst {
atomic_tdpg_enc_submission_cnt;
void*fw_shared_cpu_addr;
uint64_tfw_shared_gpu_addr;
+   void*saved_shm_bo;
 };
 
 struct amdgpu_vcn {
-- 
2.7.4

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


[PATCH 5/6] drm/amdgpu: retire AMDGPU_REGS_KIQ flag

2020-04-03 Thread Hawking Zhang
all the register access through kiq is redirected
to amdgpu_kiq_rreg/amdgpu_kiq_wreg

Change-Id: Ib46637c7095ca0cb9c3200a7ed19347e47cb816d
Signed-off-by: Hawking Zhang 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu.h| 5 ++---
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 4 ++--
 2 files changed, 4 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index e1647625..4466d96 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -1028,13 +1028,12 @@ int emu_soc_asic_init(struct amdgpu_device *adev);
  * Registers read & write functions.
  */
 #define AMDGPU_REGS_NO_KIQ(1<<1)
-#define AMDGPU_REGS_KIQ   (1<<2)
 
 #define RREG32_NO_KIQ(reg) amdgpu_mm_rreg(adev, (reg), AMDGPU_REGS_NO_KIQ)
 #define WREG32_NO_KIQ(reg, v) amdgpu_mm_wreg(adev, (reg), (v), 
AMDGPU_REGS_NO_KIQ)
 
-#define RREG32_KIQ(reg) amdgpu_mm_rreg(adev, (reg), AMDGPU_REGS_KIQ)
-#define WREG32_KIQ(reg, v) amdgpu_mm_wreg(adev, (reg), (v), AMDGPU_REGS_KIQ)
+#define RREG32_KIQ(reg) amdgpu_kiq_rreg(adev, (reg))
+#define WREG32_KIQ(reg, v) amdgpu_kiq_wreg(adev, (reg), (v))
 
 #define RREG8(reg) amdgpu_mm_rreg8(adev, (reg))
 #define WREG8(reg, v) amdgpu_mm_wreg8(adev, (reg), (v))
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index 1b4d338..23d75449 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -314,7 +314,7 @@ uint32_t amdgpu_mm_rreg(struct amdgpu_device *adev, 
uint32_t reg,
 {
uint32_t ret;
 
-   if ((acc_flags & AMDGPU_REGS_KIQ) || (!(acc_flags & AMDGPU_REGS_NO_KIQ) 
&& amdgpu_sriov_runtime(adev)))
+   if (!(acc_flags & AMDGPU_REGS_NO_KIQ) && amdgpu_sriov_runtime(adev))
return amdgpu_kiq_rreg(adev, reg);
 
if ((reg * 4) < adev->rmmio_size)
@@ -402,7 +402,7 @@ void static inline amdgpu_mm_wreg_mmio(struct amdgpu_device 
*adev, uint32_t reg,
 void amdgpu_mm_wreg(struct amdgpu_device *adev, uint32_t reg, uint32_t v,
uint32_t acc_flags)
 {
-   if ((acc_flags & AMDGPU_REGS_KIQ) || (!(acc_flags & AMDGPU_REGS_NO_KIQ) 
&& amdgpu_sriov_runtime(adev)))
+   if (!(acc_flags & AMDGPU_REGS_NO_KIQ) && amdgpu_sriov_runtime(adev))
return amdgpu_kiq_wreg(adev, reg, v);
 
amdgpu_mm_wreg_mmio(adev, reg, v, acc_flags);
-- 
2.7.4

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


[PATCH 4/6] drm/amdgpu: retire RREG32_IDX/WREG32_IDX

2020-04-03 Thread Hawking Zhang
those are not needed anymore

Change-Id: I2c2696eaa82ef6777ad518d9333cda9deced0f94
Signed-off-by: Hawking Zhang 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu.h| 4 
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 4 ++--
 2 files changed, 2 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index 59bd507..e1647625 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -1027,8 +1027,6 @@ int emu_soc_asic_init(struct amdgpu_device *adev);
 /*
  * Registers read & write functions.
  */
-
-#define AMDGPU_REGS_IDX   (1<<0)
 #define AMDGPU_REGS_NO_KIQ(1<<1)
 #define AMDGPU_REGS_KIQ   (1<<2)
 
@@ -1042,10 +1040,8 @@ int emu_soc_asic_init(struct amdgpu_device *adev);
 #define WREG8(reg, v) amdgpu_mm_wreg8(adev, (reg), (v))
 
 #define RREG32(reg) amdgpu_mm_rreg(adev, (reg), 0)
-#define RREG32_IDX(reg) amdgpu_mm_rreg(adev, (reg), AMDGPU_REGS_IDX)
 #define DREG32(reg) printk(KERN_INFO "REGISTER: " #reg " : 0x%08X\n", 
amdgpu_mm_rreg(adev, (reg), 0))
 #define WREG32(reg, v) amdgpu_mm_wreg(adev, (reg), (v), 0)
-#define WREG32_IDX(reg, v) amdgpu_mm_wreg(adev, (reg), (v), AMDGPU_REGS_IDX)
 #define REG_SET(FIELD, v) (((v) << FIELD##_SHIFT) & FIELD##_MASK)
 #define REG_GET(FIELD, v) (((v) << FIELD##_SHIFT) & FIELD##_MASK)
 #define RREG32_PCIE(reg) adev->pcie_rreg(adev, (reg))
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index 1849653..1b4d338 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -317,7 +317,7 @@ uint32_t amdgpu_mm_rreg(struct amdgpu_device *adev, 
uint32_t reg,
if ((acc_flags & AMDGPU_REGS_KIQ) || (!(acc_flags & AMDGPU_REGS_NO_KIQ) 
&& amdgpu_sriov_runtime(adev)))
return amdgpu_kiq_rreg(adev, reg);
 
-   if ((reg * 4) < adev->rmmio_size && !(acc_flags & AMDGPU_REGS_IDX))
+   if ((reg * 4) < adev->rmmio_size)
ret = readl(((void __iomem *)adev->rmmio) + (reg * 4));
else {
unsigned long flags;
@@ -377,7 +377,7 @@ void static inline amdgpu_mm_wreg_mmio(struct amdgpu_device 
*adev, uint32_t reg,
 {
trace_amdgpu_mm_wreg(adev->pdev->device, reg, v);
 
-   if ((reg * 4) < adev->rmmio_size && !(acc_flags & AMDGPU_REGS_IDX))
+   if ((reg * 4) < adev->rmmio_size)
writel(v, ((void __iomem *)adev->rmmio) + (reg * 4));
else {
unsigned long flags;
-- 
2.7.4

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


[PATCH 1/6] drm/amdgpu: remove inproper workaround for vega10

2020-04-03 Thread Hawking Zhang
the workaround is not needed for soc15 ASICs except
for vega10. it is even not needed with latest vega10
vbios.

Change-Id: Ibcf6f32f756f62004944d5543ff475e508b98a09
Signed-off-by: Hawking Zhang 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu.h|  2 --
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 16 
 2 files changed, 18 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index 29f0a41..59bd507 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -960,8 +960,6 @@ struct amdgpu_device {
/* s3/s4 mask */
boolin_suspend;
 
-   /* record last mm index being written through WREG32*/
-   unsigned long last_mm_index;
boolin_gpu_reset;
enum pp_mp1_state   mp1_state;
struct mutex  lock_reset;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index 8faaa17..1849653 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -387,10 +387,6 @@ void static inline amdgpu_mm_wreg_mmio(struct 
amdgpu_device *adev, uint32_t reg,
writel(v, ((void __iomem *)adev->rmmio) + (mmMM_DATA * 4));
spin_unlock_irqrestore(>mmio_idx_lock, flags);
}
-
-   if (adev->asic_type >= CHIP_VEGA10 && reg == 1 && adev->last_mm_index 
== 0x5702C) {
-   udelay(500);
-   }
 }
 
 /**
@@ -406,10 +402,6 @@ void static inline amdgpu_mm_wreg_mmio(struct 
amdgpu_device *adev, uint32_t reg,
 void amdgpu_mm_wreg(struct amdgpu_device *adev, uint32_t reg, uint32_t v,
uint32_t acc_flags)
 {
-   if (adev->asic_type >= CHIP_VEGA10 && reg == 0) {
-   adev->last_mm_index = v;
-   }
-
if ((acc_flags & AMDGPU_REGS_KIQ) || (!(acc_flags & AMDGPU_REGS_NO_KIQ) 
&& amdgpu_sriov_runtime(adev)))
return amdgpu_kiq_wreg(adev, reg, v);
 
@@ -464,20 +456,12 @@ u32 amdgpu_io_rreg(struct amdgpu_device *adev, u32 reg)
  */
 void amdgpu_io_wreg(struct amdgpu_device *adev, u32 reg, u32 v)
 {
-   if (adev->asic_type >= CHIP_VEGA10 && reg == 0) {
-   adev->last_mm_index = v;
-   }
-
if ((reg * 4) < adev->rio_mem_size)
iowrite32(v, adev->rio_mem + (reg * 4));
else {
iowrite32((reg * 4), adev->rio_mem + (mmMM_INDEX * 4));
iowrite32(v, adev->rio_mem + (mmMM_DATA * 4));
}
-
-   if (adev->asic_type >= CHIP_VEGA10 && reg == 1 && adev->last_mm_index 
== 0x5702C) {
-   udelay(500);
-   }
 }
 
 /**
-- 
2.7.4

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


[PATCH 2/6] drm/amdgpu: replace indirect mmio access in non-dc code path

2020-04-03 Thread Hawking Zhang
all the mmCUR_CONTROL instances are in mmr range and
can be accessd directly by using RREG32/WREG32

Change-Id: I156f760276bddf6dec8936952a371c0255ab1b42
Signed-off-by: Hawking Zhang 
---
 drivers/gpu/drm/amd/amdgpu/dce_v10_0.c |  8 
 drivers/gpu/drm/amd/amdgpu/dce_v11_0.c |  8 
 drivers/gpu/drm/amd/amdgpu/dce_v6_0.c  | 14 +++---
 drivers/gpu/drm/amd/amdgpu/dce_v8_0.c  | 14 +++---
 4 files changed, 22 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c 
b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
index 40d2ac7..a777240 100644
--- a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
@@ -2303,9 +2303,9 @@ static void dce_v10_0_hide_cursor(struct drm_crtc *crtc)
struct amdgpu_device *adev = crtc->dev->dev_private;
u32 tmp;
 
-   tmp = RREG32_IDX(mmCUR_CONTROL + amdgpu_crtc->crtc_offset);
+   tmp = RREG32(mmCUR_CONTROL + amdgpu_crtc->crtc_offset);
tmp = REG_SET_FIELD(tmp, CUR_CONTROL, CURSOR_EN, 0);
-   WREG32_IDX(mmCUR_CONTROL + amdgpu_crtc->crtc_offset, tmp);
+   WREG32(mmCUR_CONTROL + amdgpu_crtc->crtc_offset, tmp);
 }
 
 static void dce_v10_0_show_cursor(struct drm_crtc *crtc)
@@ -2319,10 +2319,10 @@ static void dce_v10_0_show_cursor(struct drm_crtc *crtc)
WREG32(mmCUR_SURFACE_ADDRESS + amdgpu_crtc->crtc_offset,
   lower_32_bits(amdgpu_crtc->cursor_addr));
 
-   tmp = RREG32_IDX(mmCUR_CONTROL + amdgpu_crtc->crtc_offset);
+   tmp = RREG32(mmCUR_CONTROL + amdgpu_crtc->crtc_offset);
tmp = REG_SET_FIELD(tmp, CUR_CONTROL, CURSOR_EN, 1);
tmp = REG_SET_FIELD(tmp, CUR_CONTROL, CURSOR_MODE, 2);
-   WREG32_IDX(mmCUR_CONTROL + amdgpu_crtc->crtc_offset, tmp);
+   WREG32(mmCUR_CONTROL + amdgpu_crtc->crtc_offset, tmp);
 }
 
 static int dce_v10_0_cursor_move_locked(struct drm_crtc *crtc,
diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c 
b/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
index 898ef72..fb3961d 100644
--- a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
@@ -2382,9 +2382,9 @@ static void dce_v11_0_hide_cursor(struct drm_crtc *crtc)
struct amdgpu_device *adev = crtc->dev->dev_private;
u32 tmp;
 
-   tmp = RREG32_IDX(mmCUR_CONTROL + amdgpu_crtc->crtc_offset);
+   tmp = RREG32(mmCUR_CONTROL + amdgpu_crtc->crtc_offset);
tmp = REG_SET_FIELD(tmp, CUR_CONTROL, CURSOR_EN, 0);
-   WREG32_IDX(mmCUR_CONTROL + amdgpu_crtc->crtc_offset, tmp);
+   WREG32(mmCUR_CONTROL + amdgpu_crtc->crtc_offset, tmp);
 }
 
 static void dce_v11_0_show_cursor(struct drm_crtc *crtc)
@@ -2398,10 +2398,10 @@ static void dce_v11_0_show_cursor(struct drm_crtc *crtc)
WREG32(mmCUR_SURFACE_ADDRESS + amdgpu_crtc->crtc_offset,
   lower_32_bits(amdgpu_crtc->cursor_addr));
 
-   tmp = RREG32_IDX(mmCUR_CONTROL + amdgpu_crtc->crtc_offset);
+   tmp = RREG32(mmCUR_CONTROL + amdgpu_crtc->crtc_offset);
tmp = REG_SET_FIELD(tmp, CUR_CONTROL, CURSOR_EN, 1);
tmp = REG_SET_FIELD(tmp, CUR_CONTROL, CURSOR_MODE, 2);
-   WREG32_IDX(mmCUR_CONTROL + amdgpu_crtc->crtc_offset, tmp);
+   WREG32(mmCUR_CONTROL + amdgpu_crtc->crtc_offset, tmp);
 }
 
 static int dce_v11_0_cursor_move_locked(struct drm_crtc *crtc,
diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c 
b/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c
index db15a11..36933e4 100644
--- a/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c
@@ -2194,9 +2194,9 @@ static void dce_v6_0_hide_cursor(struct drm_crtc *crtc)
struct amdgpu_crtc *amdgpu_crtc = to_amdgpu_crtc(crtc);
struct amdgpu_device *adev = crtc->dev->dev_private;
 
-   WREG32_IDX(mmCUR_CONTROL + amdgpu_crtc->crtc_offset,
-  (CURSOR_24_8_PRE_MULT << CUR_CONTROL__CURSOR_MODE__SHIFT) |
-  (CURSOR_URGENT_1_2 << 
CUR_CONTROL__CURSOR_URGENT_CONTROL__SHIFT));
+   WREG32(mmCUR_CONTROL + amdgpu_crtc->crtc_offset,
+  (CURSOR_24_8_PRE_MULT << CUR_CONTROL__CURSOR_MODE__SHIFT) |
+  (CURSOR_URGENT_1_2 << 
CUR_CONTROL__CURSOR_URGENT_CONTROL__SHIFT));
 
 
 }
@@ -2211,10 +2211,10 @@ static void dce_v6_0_show_cursor(struct drm_crtc *crtc)
WREG32(mmCUR_SURFACE_ADDRESS + amdgpu_crtc->crtc_offset,
   lower_32_bits(amdgpu_crtc->cursor_addr));
 
-   WREG32_IDX(mmCUR_CONTROL + amdgpu_crtc->crtc_offset,
-  CUR_CONTROL__CURSOR_EN_MASK |
-  (CURSOR_24_8_PRE_MULT << CUR_CONTROL__CURSOR_MODE__SHIFT) |
-  (CURSOR_URGENT_1_2 << 
CUR_CONTROL__CURSOR_URGENT_CONTROL__SHIFT));
+   WREG32(mmCUR_CONTROL + amdgpu_crtc->crtc_offset,
+  CUR_CONTROL__CURSOR_EN_MASK |
+  (CURSOR_24_8_PRE_MULT << CUR_CONTROL__CURSOR_MODE__SHIFT) |
+  (CURSOR_URGENT_1_2 << 
CUR_CONTROL__CURSOR_URGENT_CONTROL__SHIFT));
 
 }
 
diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c 

[PATCH 3/6] drm/amdgpu: retire indirect mmio reg support from cgs

2020-04-03 Thread Hawking Zhang
not needed anymore

Change-Id: I26b4b742acda4387ca25b86db83b8c9376ed4f3b
Signed-off-by: Hawking Zhang 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c  | 8 
 drivers/gpu/drm/amd/include/cgs_common.h | 1 -
 2 files changed, 4 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c
index 031b094..78ac6db 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c
@@ -60,8 +60,6 @@ static uint32_t amdgpu_cgs_read_ind_register(struct 
cgs_device *cgs_device,
 {
CGS_FUNC_ADEV;
switch (space) {
-   case CGS_IND_REG__MMIO:
-   return RREG32_IDX(index);
case CGS_IND_REG__PCIE:
return RREG32_PCIE(index);
case CGS_IND_REG__SMC:
@@ -77,6 +75,8 @@ static uint32_t amdgpu_cgs_read_ind_register(struct 
cgs_device *cgs_device,
case CGS_IND_REG__AUDIO_ENDPT:
DRM_ERROR("audio endpt register access not implemented.\n");
return 0;
+   default:
+   BUG();
}
WARN(1, "Invalid indirect register space");
return 0;
@@ -88,8 +88,6 @@ static void amdgpu_cgs_write_ind_register(struct cgs_device 
*cgs_device,
 {
CGS_FUNC_ADEV;
switch (space) {
-   case CGS_IND_REG__MMIO:
-   return WREG32_IDX(index, value);
case CGS_IND_REG__PCIE:
return WREG32_PCIE(index, value);
case CGS_IND_REG__SMC:
@@ -105,6 +103,8 @@ static void amdgpu_cgs_write_ind_register(struct cgs_device 
*cgs_device,
case CGS_IND_REG__AUDIO_ENDPT:
DRM_ERROR("audio endpt register access not implemented.\n");
return;
+   default:
+   BUG();
}
WARN(1, "Invalid indirect register space");
 }
diff --git a/drivers/gpu/drm/amd/include/cgs_common.h 
b/drivers/gpu/drm/amd/include/cgs_common.h
index a69deb3..60a6536 100644
--- a/drivers/gpu/drm/amd/include/cgs_common.h
+++ b/drivers/gpu/drm/amd/include/cgs_common.h
@@ -32,7 +32,6 @@ struct cgs_device;
  * enum cgs_ind_reg - Indirect register spaces
  */
 enum cgs_ind_reg {
-   CGS_IND_REG__MMIO,
CGS_IND_REG__PCIE,
CGS_IND_REG__SMC,
CGS_IND_REG__UVD_CTX,
-- 
2.7.4

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


[PATCH 6/6] drm/amdgpu: support access regs outside of mmio bar

2020-04-03 Thread Hawking Zhang
add indirect access support to registers outside of
mmio bar.

Change-Id: I825c9c67dce8fa010e3072d65e45eae7bbd3b45a
Signed-off-by: Hawking Zhang 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu.h| 18 ++--
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 45 +++---
 drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h  |  4 +--
 3 files changed, 28 insertions(+), 39 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index 4466d96..21a7307 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -1007,10 +1007,10 @@ int amdgpu_gpu_wait_for_idle(struct amdgpu_device 
*adev);
 
 void amdgpu_device_vram_access(struct amdgpu_device *adev, loff_t pos,
   uint32_t *buf, size_t size, bool write);
-uint32_t amdgpu_mm_rreg(struct amdgpu_device *adev, uint32_t reg,
+uint32_t amdgpu_device_rreg(struct amdgpu_device *adev, uint32_t reg,
+   uint32_t acc_flags);
+void amdgpu_device_wreg(struct amdgpu_device *adev, uint32_t reg, uint32_t v,
uint32_t acc_flags);
-void amdgpu_mm_wreg(struct amdgpu_device *adev, uint32_t reg, uint32_t v,
-   uint32_t acc_flags);
 void amdgpu_mm_wreg_mmio_rlc(struct amdgpu_device *adev, uint32_t reg, 
uint32_t v,
uint32_t acc_flags);
 void amdgpu_mm_wreg8(struct amdgpu_device *adev, uint32_t offset, uint8_t 
value);
@@ -1029,8 +1029,8 @@ int emu_soc_asic_init(struct amdgpu_device *adev);
  */
 #define AMDGPU_REGS_NO_KIQ(1<<1)
 
-#define RREG32_NO_KIQ(reg) amdgpu_mm_rreg(adev, (reg), AMDGPU_REGS_NO_KIQ)
-#define WREG32_NO_KIQ(reg, v) amdgpu_mm_wreg(adev, (reg), (v), 
AMDGPU_REGS_NO_KIQ)
+#define RREG32_NO_KIQ(reg) amdgpu_device_rreg(adev, (reg), AMDGPU_REGS_NO_KIQ)
+#define WREG32_NO_KIQ(reg, v) amdgpu_device_wreg(adev, (reg), (v), 
AMDGPU_REGS_NO_KIQ)
 
 #define RREG32_KIQ(reg) amdgpu_kiq_rreg(adev, (reg))
 #define WREG32_KIQ(reg, v) amdgpu_kiq_wreg(adev, (reg), (v))
@@ -1038,9 +1038,9 @@ int emu_soc_asic_init(struct amdgpu_device *adev);
 #define RREG8(reg) amdgpu_mm_rreg8(adev, (reg))
 #define WREG8(reg, v) amdgpu_mm_wreg8(adev, (reg), (v))
 
-#define RREG32(reg) amdgpu_mm_rreg(adev, (reg), 0)
-#define DREG32(reg) printk(KERN_INFO "REGISTER: " #reg " : 0x%08X\n", 
amdgpu_mm_rreg(adev, (reg), 0))
-#define WREG32(reg, v) amdgpu_mm_wreg(adev, (reg), (v), 0)
+#define RREG32(reg) amdgpu_device_rreg(adev, (reg), 0)
+#define DREG32(reg) printk(KERN_INFO "REGISTER: " #reg " : 0x%08X\n", 
amdgpu_device_rreg(adev, (reg), 0))
+#define WREG32(reg, v) amdgpu_device_wreg(adev, (reg), (v), 0)
 #define REG_SET(FIELD, v) (((v) << FIELD##_SHIFT) & FIELD##_MASK)
 #define REG_GET(FIELD, v) (((v) << FIELD##_SHIFT) & FIELD##_MASK)
 #define RREG32_PCIE(reg) adev->pcie_rreg(adev, (reg))
@@ -1077,7 +1077,7 @@ int emu_soc_asic_init(struct amdgpu_device *adev);
tmp_ |= ((val) & ~(mask));  \
WREG32_PLL(reg, tmp_);  \
} while (0)
-#define DREG32_SYS(sqf, adev, reg) seq_printf((sqf), #reg " : 0x%08X\n", 
amdgpu_mm_rreg((adev), (reg), false))
+#define DREG32_SYS(sqf, adev, reg) seq_printf((sqf), #reg " : 0x%08X\n", 
amdgpu_device_rreg((adev), (reg), false))
 #define RREG32_IO(reg) amdgpu_io_rreg(adev, (reg))
 #define WREG32_IO(reg, v) amdgpu_io_wreg(adev, (reg), (v))
 
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index 23d75449..47ef8a4 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -298,10 +298,10 @@ void amdgpu_device_vram_access(struct amdgpu_device 
*adev, loff_t pos,
 }
 
 /*
- * MMIO register access helper functions.
+ * device register access helper functions.
  */
 /**
- * amdgpu_mm_rreg - read a memory mapped IO register
+ * amdgpu_device_rreg - read a register
  *
  * @adev: amdgpu_device pointer
  * @reg: dword aligned register offset
@@ -309,8 +309,8 @@ void amdgpu_device_vram_access(struct amdgpu_device *adev, 
loff_t pos,
  *
  * Returns the 32 bit value from the offset specified.
  */
-uint32_t amdgpu_mm_rreg(struct amdgpu_device *adev, uint32_t reg,
-   uint32_t acc_flags)
+uint32_t amdgpu_device_rreg(struct amdgpu_device *adev, uint32_t reg,
+   uint32_t acc_flags)
 {
uint32_t ret;
 
@@ -319,15 +319,9 @@ uint32_t amdgpu_mm_rreg(struct amdgpu_device *adev, 
uint32_t reg,
 
if ((reg * 4) < adev->rmmio_size)
ret = readl(((void __iomem *)adev->rmmio) + (reg * 4));
-   else {
-   unsigned long flags;
-
-   spin_lock_irqsave(>mmio_idx_lock, flags);
-   writel((reg * 4), ((void __iomem *)adev->rmmio) + (mmMM_INDEX * 
4));
-   ret = readl(((void __iomem *)adev->rmmio) + (mmMM_DATA * 4));
-   spin_unlock_irqrestore(>mmio_idx_lock, flags);
-   }
-   

[PATCH 0/6] refine register access interfaces

2020-04-03 Thread Hawking Zhang
The series refined register access interfaces including:
1. add indirect access support to registers outside of mmio bar
2. remove the inproper workaround leaving in the low level if
3. retire legacy interface RREG32_IDX/WREG32_IDX
4. retire redundant flags AMDGPU_REGS_KIQ/AMDGPU_REGS_IDX

Hawking Zhang (6):
  drm/amdgpu: remove inproper workaround for vega10
  drm/amdgpu: replace indirect mmio access in non-dc code path
  drm/amdgpu: retire indirect mmio reg support from cgs
  drm/amdgpu: retire RREG32_IDX/WREG32_IDX
  drm/amdgpu: retire AMDGPU_REGS_KIQ flag
  drm/amdgpu: support access regs outside of mmio bar

 drivers/gpu/drm/amd/amdgpu/amdgpu.h| 29 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c|  8 ++--
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 69 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h  |  4 +-
 drivers/gpu/drm/amd/amdgpu/dce_v10_0.c |  8 ++--
 drivers/gpu/drm/amd/amdgpu/dce_v11_0.c |  8 ++--
 drivers/gpu/drm/amd/amdgpu/dce_v6_0.c  | 14 +++---
 drivers/gpu/drm/amd/amdgpu/dce_v8_0.c  | 14 +++---
 drivers/gpu/drm/amd/include/cgs_common.h   |  1 -
 9 files changed, 60 insertions(+), 95 deletions(-)

-- 
2.7.4

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


Re: [PATCH] drm/amdgpu: fix gfx hang during suspend with video playback

2020-04-03 Thread Huang Rui
On Fri, Apr 03, 2020 at 06:05:55PM +0800, Huang Rui wrote:
> On Fri, Apr 03, 2020 at 05:22:28PM +0800, Liang, Prike wrote:
> > 
> > > -Original Message-
> > > From: Huang, Ray 
> > > Sent: Friday, April 3, 2020 2:27 PM
> > > To: Liang, Prike 
> > > Cc: amd-gfx@lists.freedesktop.org; Quan, Evan ;
> > > Deucher, Alexander ; Kuehling, Felix
> > > 
> > > Subject: Re: [PATCH] drm/amdgpu: fix gfx hang during suspend with video
> > > playback
> > > 
> > > (+ Felix)
> > > 
> > > On Fri, Apr 03, 2020 at 12:07:53PM +0800, Liang, Prike wrote:
> > > > The system will be hang up during S3 as SMU is pending at GC not
> > > > respose the register CP_HQD_ACTIVE access request and this issue can
> > > > be fixed by adding RLC safe mode guard before each HQD map/unmap
> > > > retrive opt.
> > > 
> > > We need more information for the issue, does the map/unmap is required
> > > for MAP_QUEUES/UNMAP_QUEUES packets or writing with MMIO or both?
> > > 
> > [Prike]  The issue hang up at MP1 was trying to read register 
> > RSMU_RESIDENCY_COUNTER_GC 
> > but did not get response from GFX, since GFX was busy at reading register 
> > CP_HQD_ACTIVE.
> > Moreover, when disabled GFXOFF this issue also can't see so there is likely 
> > to perform 
> > register accessed at GFXOFF CGPG/CGCG enter stage.  As for only  this 
> > issue, that seems just 
> > MMIO  access failed case which occurred under QUEUE map/unmap status check. 
> > 
> 
> While we start to do S3, we will disable gfxoff at start of suspend. Then
> in this point, the gfx should be always in "on" state. 
> 
> > > From your patch, you just protect the kernel kiq and user queue. What 
> > > about
> > > other kernel compute queues? HIQ?
> > > 
> > [Prike] So far just find the KIQ/CPQ/DIQ map/unmap will inquire the 
> > CP_HQD_ACTIVE status by MMIO accessing,
> > therefore just guard the KIQ  and some type user queue now. Regarding HIQ 
> > map and ummap which used the method of submitting configuration packet.  
> > 
> 
> KIQ itself init/unit should be always under gfx on state. Can you give a
> check the result if not add enter/exit rlc safe mode around it?

Wait... In your case, the system didn't load any user queues because no
ROCm based application is running. So the issue is probably caused by KIQ
itself init/unit, can you confirm?

Thanks,
Ray

> 
> Hi Felix, maybe we need to use packets with kiq to map all user queues.
> 
> Thanks,
> Ray
> 
> > > Thanks,
> > > Ray
> > > 
> > > >
> > > > Signed-off-by: Prike Liang 
> > > > Tested-by: Mengbing Wang 
> > > > ---
> > > >  drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.c | 6 ++
> > > >  drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 4 
> > > >  2 files changed, 10 insertions(+)
> > > >
> > > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.c
> > > > b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.c
> > > > index df841c2..e265063 100644
> > > > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.c
> > > > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.c
> > > > @@ -232,6 +232,7 @@ int kgd_gfx_v9_hqd_load(struct kgd_dev *kgd, void
> > > *mqd, uint32_t pipe_id,
> > > > uint32_t *mqd_hqd;
> > > > uint32_t reg, hqd_base, data;
> > > >
> > > > +   amdgpu_gfx_rlc_enter_safe_mode(adev);
> > > > m = get_mqd(mqd);
> > > >
> > > > acquire_queue(kgd, pipe_id, queue_id); @@ -299,6 +300,7 @@ int
> > > > kgd_gfx_v9_hqd_load(struct kgd_dev *kgd, void *mqd, uint32_t pipe_id,
> > > >
> > > > release_queue(kgd);
> > > >
> > > > +   amdgpu_gfx_rlc_exit_safe_mode(adev);
> > > > return 0;
> > > >  }
> > > >
> > > > @@ -497,6 +499,7 @@ bool kgd_gfx_v9_hqd_is_occupied(struct kgd_dev
> > > *kgd, uint64_t queue_address,
> > > > bool retval = false;
> > > > uint32_t low, high;
> > > >
> > > > +   amdgpu_gfx_rlc_enter_safe_mode(adev);
> > > > acquire_queue(kgd, pipe_id, queue_id);
> > > > act = RREG32(SOC15_REG_OFFSET(GC, 0, mmCP_HQD_ACTIVE));
> > > > if (act) {
> > > > @@ -508,6 +511,7 @@ bool kgd_gfx_v9_hqd_is_occupied(struct kgd_dev
> > > *kgd, uint64_t queue_address,
> > > > retval = true;
> > > > }
> > > > release_queue(kgd);
> > > > +   amdgpu_gfx_rlc_exit_safe_mode(adev);
> > > > return retval;
> > > >  }
> > > >
> > > > @@ -541,6 +545,7 @@ int kgd_gfx_v9_hqd_destroy(struct kgd_dev *kgd,
> > > void *mqd,
> > > > uint32_t temp;
> > > > struct v9_mqd *m = get_mqd(mqd);
> > > >
> > > > +   amdgpu_gfx_rlc_enter_safe_mode(adev);
> > > > if (adev->in_gpu_reset)
> > > > return -EIO;
> > > >
> > > > @@ -577,6 +582,7 @@ int kgd_gfx_v9_hqd_destroy(struct kgd_dev *kgd,
> > > void *mqd,
> > > > }
> > > >
> > > > release_queue(kgd);
> > > > +   amdgpu_gfx_rlc_exit_safe_mode(adev);
> > > > return 0;
> > > >  }
> > > >
> > > > diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
> > > > 

[PATCH] drm/amdgpu: change SH MEM alignment mode for gfx10

2020-04-03 Thread Likun Gao
From: Likun Gao 

Change SH_MEM_CONFIG Alignment mode to Automatic, as:
1)OGL fn_amd_compute_shader will failed with unaligned mode.
2)The default alignment mode was defined to automatic on gfx10
specification.

Signed-off-by: Likun Gao 
---
 drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c 
b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
index 5a67306..d8f0c0d 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
@@ -279,7 +279,7 @@ static const struct soc15_reg_golden 
golden_settings_gc_10_1_2_nv12[] =
 
 #define DEFAULT_SH_MEM_CONFIG \
((SH_MEM_ADDRESS_MODE_64 << SH_MEM_CONFIG__ADDRESS_MODE__SHIFT) | \
-(SH_MEM_ALIGNMENT_MODE_UNALIGNED << 
SH_MEM_CONFIG__ALIGNMENT_MODE__SHIFT) | \
+(SH_MEM_ALIGNMENT_MODE_DWORD << SH_MEM_CONFIG__ALIGNMENT_MODE__SHIFT) 
| \
 (SH_MEM_RETRY_MODE_ALL << SH_MEM_CONFIG__RETRY_MODE__SHIFT) | \
 (3 << SH_MEM_CONFIG__INITIAL_INST_PREFETCH__SHIFT))
 
-- 
2.7.4

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


Re: [PATCH] drm/amdgpu: fix gfx hang during suspend with video playback

2020-04-03 Thread Huang Rui
On Fri, Apr 03, 2020 at 05:22:28PM +0800, Liang, Prike wrote:
> 
> > -Original Message-
> > From: Huang, Ray 
> > Sent: Friday, April 3, 2020 2:27 PM
> > To: Liang, Prike 
> > Cc: amd-gfx@lists.freedesktop.org; Quan, Evan ;
> > Deucher, Alexander ; Kuehling, Felix
> > 
> > Subject: Re: [PATCH] drm/amdgpu: fix gfx hang during suspend with video
> > playback
> > 
> > (+ Felix)
> > 
> > On Fri, Apr 03, 2020 at 12:07:53PM +0800, Liang, Prike wrote:
> > > The system will be hang up during S3 as SMU is pending at GC not
> > > respose the register CP_HQD_ACTIVE access request and this issue can
> > > be fixed by adding RLC safe mode guard before each HQD map/unmap
> > > retrive opt.
> > 
> > We need more information for the issue, does the map/unmap is required
> > for MAP_QUEUES/UNMAP_QUEUES packets or writing with MMIO or both?
> > 
> [Prike]  The issue hang up at MP1 was trying to read register 
> RSMU_RESIDENCY_COUNTER_GC 
> but did not get response from GFX, since GFX was busy at reading register 
> CP_HQD_ACTIVE.
> Moreover, when disabled GFXOFF this issue also can't see so there is likely 
> to perform 
> register accessed at GFXOFF CGPG/CGCG enter stage.  As for only  this issue, 
> that seems just 
> MMIO  access failed case which occurred under QUEUE map/unmap status check. 
> 

While we start to do S3, we will disable gfxoff at start of suspend. Then
in this point, the gfx should be always in "on" state. 

> > From your patch, you just protect the kernel kiq and user queue. What about
> > other kernel compute queues? HIQ?
> > 
> [Prike] So far just find the KIQ/CPQ/DIQ map/unmap will inquire the 
> CP_HQD_ACTIVE status by MMIO accessing,
> therefore just guard the KIQ  and some type user queue now. Regarding HIQ map 
> and ummap which used the method of submitting configuration packet.  
> 

KIQ itself init/unit should be always under gfx on state. Can you give a
check the result if not add enter/exit rlc safe mode around it?

Hi Felix, maybe we need to use packets with kiq to map all user queues.

Thanks,
Ray

> > Thanks,
> > Ray
> > 
> > >
> > > Signed-off-by: Prike Liang 
> > > Tested-by: Mengbing Wang 
> > > ---
> > >  drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.c | 6 ++
> > >  drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 4 
> > >  2 files changed, 10 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.c
> > > b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.c
> > > index df841c2..e265063 100644
> > > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.c
> > > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.c
> > > @@ -232,6 +232,7 @@ int kgd_gfx_v9_hqd_load(struct kgd_dev *kgd, void
> > *mqd, uint32_t pipe_id,
> > >   uint32_t *mqd_hqd;
> > >   uint32_t reg, hqd_base, data;
> > >
> > > + amdgpu_gfx_rlc_enter_safe_mode(adev);
> > >   m = get_mqd(mqd);
> > >
> > >   acquire_queue(kgd, pipe_id, queue_id); @@ -299,6 +300,7 @@ int
> > > kgd_gfx_v9_hqd_load(struct kgd_dev *kgd, void *mqd, uint32_t pipe_id,
> > >
> > >   release_queue(kgd);
> > >
> > > + amdgpu_gfx_rlc_exit_safe_mode(adev);
> > >   return 0;
> > >  }
> > >
> > > @@ -497,6 +499,7 @@ bool kgd_gfx_v9_hqd_is_occupied(struct kgd_dev
> > *kgd, uint64_t queue_address,
> > >   bool retval = false;
> > >   uint32_t low, high;
> > >
> > > + amdgpu_gfx_rlc_enter_safe_mode(adev);
> > >   acquire_queue(kgd, pipe_id, queue_id);
> > >   act = RREG32(SOC15_REG_OFFSET(GC, 0, mmCP_HQD_ACTIVE));
> > >   if (act) {
> > > @@ -508,6 +511,7 @@ bool kgd_gfx_v9_hqd_is_occupied(struct kgd_dev
> > *kgd, uint64_t queue_address,
> > >   retval = true;
> > >   }
> > >   release_queue(kgd);
> > > + amdgpu_gfx_rlc_exit_safe_mode(adev);
> > >   return retval;
> > >  }
> > >
> > > @@ -541,6 +545,7 @@ int kgd_gfx_v9_hqd_destroy(struct kgd_dev *kgd,
> > void *mqd,
> > >   uint32_t temp;
> > >   struct v9_mqd *m = get_mqd(mqd);
> > >
> > > + amdgpu_gfx_rlc_enter_safe_mode(adev);
> > >   if (adev->in_gpu_reset)
> > >   return -EIO;
> > >
> > > @@ -577,6 +582,7 @@ int kgd_gfx_v9_hqd_destroy(struct kgd_dev *kgd,
> > void *mqd,
> > >   }
> > >
> > >   release_queue(kgd);
> > > + amdgpu_gfx_rlc_exit_safe_mode(adev);
> > >   return 0;
> > >  }
> > >
> > > diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
> > > b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
> > > index 1fea077..ee107d9 100644
> > > --- a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
> > > +++ b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
> > > @@ -3533,6 +3533,7 @@ static int gfx_v9_0_kiq_init_register(struct
> > amdgpu_ring *ring)
> > >   struct v9_mqd *mqd = ring->mqd_ptr;
> > >   int j;
> > >
> > > + amdgpu_gfx_rlc_enter_safe_mode(adev);
> > >   /* disable wptr polling */
> > >   WREG32_FIELD15(GC, 0, CP_PQ_WPTR_POLL_CNTL, EN, 0);
> > >
> > > @@ -3629,6 +3630,7 @@ static int gfx_v9_0_kiq_init_register(struct
> > amdgpu_ring *ring)
> > >   if (ring->use_doorbell)
> > >   WREG32_FIELD15(GC, 0, CP_PQ_STATUS, DOORBELL_ENABLE,
> > 

RE: [PATCH] drm/amdgpu: fix gfx hang during suspend with video playback

2020-04-03 Thread Liang, Prike


> -Original Message-
> From: Huang, Ray 
> Sent: Friday, April 3, 2020 2:27 PM
> To: Liang, Prike 
> Cc: amd-gfx@lists.freedesktop.org; Quan, Evan ;
> Deucher, Alexander ; Kuehling, Felix
> 
> Subject: Re: [PATCH] drm/amdgpu: fix gfx hang during suspend with video
> playback
> 
> (+ Felix)
> 
> On Fri, Apr 03, 2020 at 12:07:53PM +0800, Liang, Prike wrote:
> > The system will be hang up during S3 as SMU is pending at GC not
> > respose the register CP_HQD_ACTIVE access request and this issue can
> > be fixed by adding RLC safe mode guard before each HQD map/unmap
> > retrive opt.
> 
> We need more information for the issue, does the map/unmap is required
> for MAP_QUEUES/UNMAP_QUEUES packets or writing with MMIO or both?
> 
[Prike]  The issue hang up at MP1 was trying to read register 
RSMU_RESIDENCY_COUNTER_GC 
but did not get response from GFX, since GFX was busy at reading register 
CP_HQD_ACTIVE.
Moreover, when disabled GFXOFF this issue also can't see so there is likely to 
perform 
register accessed at GFXOFF CGPG/CGCG enter stage.  As for only  this issue, 
that seems just 
MMIO  access failed case which occurred under QUEUE map/unmap status check. 

> From your patch, you just protect the kernel kiq and user queue. What about
> other kernel compute queues? HIQ?
> 
[Prike] So far just find the KIQ/CPQ/DIQ map/unmap will inquire the 
CP_HQD_ACTIVE status by MMIO accessing,
therefore just guard the KIQ  and some type user queue now. Regarding HIQ map 
and ummap which used the method of submitting configuration packet.  

> Thanks,
> Ray
> 
> >
> > Signed-off-by: Prike Liang 
> > Tested-by: Mengbing Wang 
> > ---
> >  drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.c | 6 ++
> >  drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 4 
> >  2 files changed, 10 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.c
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.c
> > index df841c2..e265063 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.c
> > @@ -232,6 +232,7 @@ int kgd_gfx_v9_hqd_load(struct kgd_dev *kgd, void
> *mqd, uint32_t pipe_id,
> > uint32_t *mqd_hqd;
> > uint32_t reg, hqd_base, data;
> >
> > +   amdgpu_gfx_rlc_enter_safe_mode(adev);
> > m = get_mqd(mqd);
> >
> > acquire_queue(kgd, pipe_id, queue_id); @@ -299,6 +300,7 @@ int
> > kgd_gfx_v9_hqd_load(struct kgd_dev *kgd, void *mqd, uint32_t pipe_id,
> >
> > release_queue(kgd);
> >
> > +   amdgpu_gfx_rlc_exit_safe_mode(adev);
> > return 0;
> >  }
> >
> > @@ -497,6 +499,7 @@ bool kgd_gfx_v9_hqd_is_occupied(struct kgd_dev
> *kgd, uint64_t queue_address,
> > bool retval = false;
> > uint32_t low, high;
> >
> > +   amdgpu_gfx_rlc_enter_safe_mode(adev);
> > acquire_queue(kgd, pipe_id, queue_id);
> > act = RREG32(SOC15_REG_OFFSET(GC, 0, mmCP_HQD_ACTIVE));
> > if (act) {
> > @@ -508,6 +511,7 @@ bool kgd_gfx_v9_hqd_is_occupied(struct kgd_dev
> *kgd, uint64_t queue_address,
> > retval = true;
> > }
> > release_queue(kgd);
> > +   amdgpu_gfx_rlc_exit_safe_mode(adev);
> > return retval;
> >  }
> >
> > @@ -541,6 +545,7 @@ int kgd_gfx_v9_hqd_destroy(struct kgd_dev *kgd,
> void *mqd,
> > uint32_t temp;
> > struct v9_mqd *m = get_mqd(mqd);
> >
> > +   amdgpu_gfx_rlc_enter_safe_mode(adev);
> > if (adev->in_gpu_reset)
> > return -EIO;
> >
> > @@ -577,6 +582,7 @@ int kgd_gfx_v9_hqd_destroy(struct kgd_dev *kgd,
> void *mqd,
> > }
> >
> > release_queue(kgd);
> > +   amdgpu_gfx_rlc_exit_safe_mode(adev);
> > return 0;
> >  }
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
> > b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
> > index 1fea077..ee107d9 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
> > @@ -3533,6 +3533,7 @@ static int gfx_v9_0_kiq_init_register(struct
> amdgpu_ring *ring)
> > struct v9_mqd *mqd = ring->mqd_ptr;
> > int j;
> >
> > +   amdgpu_gfx_rlc_enter_safe_mode(adev);
> > /* disable wptr polling */
> > WREG32_FIELD15(GC, 0, CP_PQ_WPTR_POLL_CNTL, EN, 0);
> >
> > @@ -3629,6 +3630,7 @@ static int gfx_v9_0_kiq_init_register(struct
> amdgpu_ring *ring)
> > if (ring->use_doorbell)
> > WREG32_FIELD15(GC, 0, CP_PQ_STATUS, DOORBELL_ENABLE,
> 1);
> >
> > +   amdgpu_gfx_rlc_exit_safe_mode(adev);
> > return 0;
> >  }
> >
> > @@ -3637,6 +3639,7 @@ static int gfx_v9_0_kiq_fini_register(struct
> amdgpu_ring *ring)
> > struct amdgpu_device *adev = ring->adev;
> > int j;
> >
> > +   amdgpu_gfx_rlc_enter_safe_mode(adev);
> > /* disable the queue if it's active */
> > if (RREG32_SOC15(GC, 0, mmCP_HQD_ACTIVE) & 1) {
> >
> > @@ -3668,6 +3671,7 @@ static int gfx_v9_0_kiq_fini_register(struct
> amdgpu_ring *ring)
> > WREG32_SOC15_RLC(GC, 0, mmCP_HQD_PQ_WPTR_HI, 0);
> > WREG32_SOC15_RLC(GC, 0, mmCP_HQD_PQ_WPTR_LO, 0);
> >
> 

Re: [PATCH v5 2/2] drm/amdgpu: rework sched_list generation

2020-04-03 Thread Christian König

Am 03.04.20 um 11:09 schrieb Nirmoy:


On 4/3/20 10:55 AM, Christian König wrote:

Am 31.03.20 um 15:59 schrieb Nirmoy Das:

Generate HW IP's sched_list in amdgpu_ring_init() instead of
amdgpu_ctx.c. This makes amdgpu_ctx_init_compute_sched(),
ring.has_high_prio and amdgpu_ctx_init_sched() unnecessary.
This patch also stores sched_list for all HW IPs in one big
array in struct amdgpu_device which makes amdgpu_ctx_init_entity()
much more leaner.

v2:
fix a coding style issue
do not use drm hw_ip const to populate amdgpu_ring_type enum

v3:
remove ctx reference and move sched array and num_sched to a struct
use num_scheds to detect uninitialized scheduler list

v4:
use array_index_nospec for user space controlled variables
fix possible checkpatch.pl warnings

Signed-off-by: Nirmoy Das 
---
  drivers/gpu/drm/amd/amdgpu/amdgpu.h    |   1 +
  drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c    | 160 
+

  drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.h    |   3 -
  drivers/gpu/drm/amd/amdgpu/amdgpu_device.c |   2 -
  drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c    |   3 +-
  drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.h    |   5 -
  drivers/gpu/drm/amd/amdgpu/amdgpu_jpeg.h   |   2 -
  drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c   |  14 +-
  drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h   |  14 +-
  drivers/gpu/drm/amd/amdgpu/amdgpu_sdma.h   |   2 -
  drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h    |   4 -
  drivers/gpu/drm/amd/amdgpu/cik_sdma.c  |   3 +-
  drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c |  14 +-
  drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c  |   7 +-
  drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c  |   7 +-
  drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c  |  11 +-
  drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c  |  13 +-
  drivers/gpu/drm/amd/amdgpu/jpeg_v1_0.c |   3 +-
  drivers/gpu/drm/amd/amdgpu/jpeg_v2_0.c |   3 +-
  drivers/gpu/drm/amd/amdgpu/jpeg_v2_5.c |   3 +-
  drivers/gpu/drm/amd/amdgpu/sdma_v2_4.c |   3 +-
  drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c |   3 +-
  drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c |   6 +-
  drivers/gpu/drm/amd/amdgpu/sdma_v5_0.c |   3 +-
  drivers/gpu/drm/amd/amdgpu/si_dma.c    |   3 +-
  drivers/gpu/drm/amd/amdgpu/uvd_v4_2.c  |   3 +-
  drivers/gpu/drm/amd/amdgpu/uvd_v5_0.c  |   3 +-
  drivers/gpu/drm/amd/amdgpu/uvd_v6_0.c  |   7 +-
  drivers/gpu/drm/amd/amdgpu/uvd_v7_0.c  |   8 +-
  drivers/gpu/drm/amd/amdgpu/vce_v2_0.c  |   3 +-
  drivers/gpu/drm/amd/amdgpu/vce_v3_0.c  |   3 +-
  drivers/gpu/drm/amd/amdgpu/vce_v4_0.c  |   3 +-
  drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c  |   6 +-
  drivers/gpu/drm/amd/amdgpu/vcn_v2_0.c  |   6 +-
  drivers/gpu/drm/amd/amdgpu/vcn_v2_5.c  |   7 +-
  35 files changed, 144 insertions(+), 197 deletions(-)

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

index 29f0a410091b..32bc2a882fd2 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -858,6 +858,7 @@ struct amdgpu_device {
  struct amdgpu_ring    *rings[AMDGPU_MAX_RINGS];
  bool    ib_pool_ready;
  struct amdgpu_sa_manager ring_tmp_bo[AMDGPU_IB_POOL_MAX];
+    struct amdgpu_sched 
gpu_sched[AMDGPU_HW_IP_NUM][AMDGPU_RING_PRIO_MAX];


  /* interrupts */
  struct amdgpu_irq    irq;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c

index 6ed36a2c5f73..8842c55d4490 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
@@ -26,6 +26,7 @@
  #include "amdgpu.h"
  #include "amdgpu_sched.h"
  #include "amdgpu_ras.h"
+#include 

  #define to_amdgpu_ctx_entity(e)    \
  container_of((e), struct amdgpu_ctx_entity, entity)
@@ -72,13 +73,30 @@ static enum gfx_pipe_priority 
amdgpu_ctx_sched_prio_to_compute_prio(enum drm_sch

  }
  }

-static int amdgpu_ctx_init_entity(struct amdgpu_ctx *ctx, const u32 
hw_ip, const u32 ring)
+static unsigned int amdgpu_ctx_prio_sched_to_hw(struct 
amdgpu_device *adev,

+ enum drm_sched_priority prio,
+ u32 hw_ip)
+{
+    unsigned int hw_prio;
+
+    hw_prio = (hw_ip == AMDGPU_HW_IP_COMPUTE) ?
+    amdgpu_ctx_sched_prio_to_compute_prio(prio) :
+    AMDGPU_RING_PRIO_DEFAULT;
+    hw_ip = array_index_nospec(hw_ip, AMDGPU_HW_IP_NUM);
+    if (adev->gpu_sched[hw_ip][hw_prio].num_scheds == 0)
+    hw_prio = AMDGPU_RING_PRIO_DEFAULT;
+
+    return hw_prio;
+}
+
+static int amdgpu_ctx_init_entity(struct amdgpu_ctx *ctx, u32 hw_ip,
+   const u32 ring)
  {
  struct amdgpu_device *adev = ctx->adev;
  struct amdgpu_ctx_entity *entity;
  struct drm_gpu_scheduler **scheds = NULL, *sched = NULL;
  unsigned num_scheds = 0;
-    enum gfx_pipe_priority hw_prio;
+    unsigned int hw_prio;
  enum drm_sched_priority priority;
  int r;

@@ -90,52 +108,16 @@ static int amdgpu_ctx_init_entity(struct 
amdgpu_ctx *ctx, const u32 

Re: [PATCH v5 2/2] drm/amdgpu: rework sched_list generation

2020-04-03 Thread Nirmoy


On 4/3/20 10:55 AM, Christian König wrote:

Am 31.03.20 um 15:59 schrieb Nirmoy Das:

Generate HW IP's sched_list in amdgpu_ring_init() instead of
amdgpu_ctx.c. This makes amdgpu_ctx_init_compute_sched(),
ring.has_high_prio and amdgpu_ctx_init_sched() unnecessary.
This patch also stores sched_list for all HW IPs in one big
array in struct amdgpu_device which makes amdgpu_ctx_init_entity()
much more leaner.

v2:
fix a coding style issue
do not use drm hw_ip const to populate amdgpu_ring_type enum

v3:
remove ctx reference and move sched array and num_sched to a struct
use num_scheds to detect uninitialized scheduler list

v4:
use array_index_nospec for user space controlled variables
fix possible checkpatch.pl warnings

Signed-off-by: Nirmoy Das 
---
  drivers/gpu/drm/amd/amdgpu/amdgpu.h    |   1 +
  drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c    | 160 +
  drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.h    |   3 -
  drivers/gpu/drm/amd/amdgpu/amdgpu_device.c |   2 -
  drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c    |   3 +-
  drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.h    |   5 -
  drivers/gpu/drm/amd/amdgpu/amdgpu_jpeg.h   |   2 -
  drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c   |  14 +-
  drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h   |  14 +-
  drivers/gpu/drm/amd/amdgpu/amdgpu_sdma.h   |   2 -
  drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h    |   4 -
  drivers/gpu/drm/amd/amdgpu/cik_sdma.c  |   3 +-
  drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c |  14 +-
  drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c  |   7 +-
  drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c  |   7 +-
  drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c  |  11 +-
  drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c  |  13 +-
  drivers/gpu/drm/amd/amdgpu/jpeg_v1_0.c |   3 +-
  drivers/gpu/drm/amd/amdgpu/jpeg_v2_0.c |   3 +-
  drivers/gpu/drm/amd/amdgpu/jpeg_v2_5.c |   3 +-
  drivers/gpu/drm/amd/amdgpu/sdma_v2_4.c |   3 +-
  drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c |   3 +-
  drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c |   6 +-
  drivers/gpu/drm/amd/amdgpu/sdma_v5_0.c |   3 +-
  drivers/gpu/drm/amd/amdgpu/si_dma.c    |   3 +-
  drivers/gpu/drm/amd/amdgpu/uvd_v4_2.c  |   3 +-
  drivers/gpu/drm/amd/amdgpu/uvd_v5_0.c  |   3 +-
  drivers/gpu/drm/amd/amdgpu/uvd_v6_0.c  |   7 +-
  drivers/gpu/drm/amd/amdgpu/uvd_v7_0.c  |   8 +-
  drivers/gpu/drm/amd/amdgpu/vce_v2_0.c  |   3 +-
  drivers/gpu/drm/amd/amdgpu/vce_v3_0.c  |   3 +-
  drivers/gpu/drm/amd/amdgpu/vce_v4_0.c  |   3 +-
  drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c  |   6 +-
  drivers/gpu/drm/amd/amdgpu/vcn_v2_0.c  |   6 +-
  drivers/gpu/drm/amd/amdgpu/vcn_v2_5.c  |   7 +-
  35 files changed, 144 insertions(+), 197 deletions(-)

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

index 29f0a410091b..32bc2a882fd2 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -858,6 +858,7 @@ struct amdgpu_device {
  struct amdgpu_ring    *rings[AMDGPU_MAX_RINGS];
  bool    ib_pool_ready;
  struct amdgpu_sa_manager ring_tmp_bo[AMDGPU_IB_POOL_MAX];
+    struct amdgpu_sched 
gpu_sched[AMDGPU_HW_IP_NUM][AMDGPU_RING_PRIO_MAX];


  /* interrupts */
  struct amdgpu_irq    irq;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c

index 6ed36a2c5f73..8842c55d4490 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
@@ -26,6 +26,7 @@
  #include "amdgpu.h"
  #include "amdgpu_sched.h"
  #include "amdgpu_ras.h"
+#include 

  #define to_amdgpu_ctx_entity(e)    \
  container_of((e), struct amdgpu_ctx_entity, entity)
@@ -72,13 +73,30 @@ static enum gfx_pipe_priority 
amdgpu_ctx_sched_prio_to_compute_prio(enum drm_sch

  }
  }

-static int amdgpu_ctx_init_entity(struct amdgpu_ctx *ctx, const u32 
hw_ip, const u32 ring)
+static unsigned int amdgpu_ctx_prio_sched_to_hw(struct amdgpu_device 
*adev,

+ enum drm_sched_priority prio,
+ u32 hw_ip)
+{
+    unsigned int hw_prio;
+
+    hw_prio = (hw_ip == AMDGPU_HW_IP_COMPUTE) ?
+    amdgpu_ctx_sched_prio_to_compute_prio(prio) :
+    AMDGPU_RING_PRIO_DEFAULT;
+    hw_ip = array_index_nospec(hw_ip, AMDGPU_HW_IP_NUM);
+    if (adev->gpu_sched[hw_ip][hw_prio].num_scheds == 0)
+    hw_prio = AMDGPU_RING_PRIO_DEFAULT;
+
+    return hw_prio;
+}
+
+static int amdgpu_ctx_init_entity(struct amdgpu_ctx *ctx, u32 hw_ip,
+   const u32 ring)
  {
  struct amdgpu_device *adev = ctx->adev;
  struct amdgpu_ctx_entity *entity;
  struct drm_gpu_scheduler **scheds = NULL, *sched = NULL;
  unsigned num_scheds = 0;
-    enum gfx_pipe_priority hw_prio;
+    unsigned int hw_prio;
  enum drm_sched_priority priority;
  int r;

@@ -90,52 +108,16 @@ static int amdgpu_ctx_init_entity(struct 
amdgpu_ctx *ctx, const u32 hw_ip, const

  entity->sequence = 1;

Re: [PATCH v5 2/2] drm/amdgpu: rework sched_list generation

2020-04-03 Thread Christian König

Am 31.03.20 um 15:59 schrieb Nirmoy Das:

Generate HW IP's sched_list in amdgpu_ring_init() instead of
amdgpu_ctx.c. This makes amdgpu_ctx_init_compute_sched(),
ring.has_high_prio and amdgpu_ctx_init_sched() unnecessary.
This patch also stores sched_list for all HW IPs in one big
array in struct amdgpu_device which makes amdgpu_ctx_init_entity()
much more leaner.

v2:
fix a coding style issue
do not use drm hw_ip const to populate amdgpu_ring_type enum

v3:
remove ctx reference and move sched array and num_sched to a struct
use num_scheds to detect uninitialized scheduler list

v4:
use array_index_nospec for user space controlled variables
fix possible checkpatch.pl warnings

Signed-off-by: Nirmoy Das 
---
  drivers/gpu/drm/amd/amdgpu/amdgpu.h|   1 +
  drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c| 160 +
  drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.h|   3 -
  drivers/gpu/drm/amd/amdgpu/amdgpu_device.c |   2 -
  drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c|   3 +-
  drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.h|   5 -
  drivers/gpu/drm/amd/amdgpu/amdgpu_jpeg.h   |   2 -
  drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c   |  14 +-
  drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h   |  14 +-
  drivers/gpu/drm/amd/amdgpu/amdgpu_sdma.h   |   2 -
  drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h|   4 -
  drivers/gpu/drm/amd/amdgpu/cik_sdma.c  |   3 +-
  drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c |  14 +-
  drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c  |   7 +-
  drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c  |   7 +-
  drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c  |  11 +-
  drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c  |  13 +-
  drivers/gpu/drm/amd/amdgpu/jpeg_v1_0.c |   3 +-
  drivers/gpu/drm/amd/amdgpu/jpeg_v2_0.c |   3 +-
  drivers/gpu/drm/amd/amdgpu/jpeg_v2_5.c |   3 +-
  drivers/gpu/drm/amd/amdgpu/sdma_v2_4.c |   3 +-
  drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c |   3 +-
  drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c |   6 +-
  drivers/gpu/drm/amd/amdgpu/sdma_v5_0.c |   3 +-
  drivers/gpu/drm/amd/amdgpu/si_dma.c|   3 +-
  drivers/gpu/drm/amd/amdgpu/uvd_v4_2.c  |   3 +-
  drivers/gpu/drm/amd/amdgpu/uvd_v5_0.c  |   3 +-
  drivers/gpu/drm/amd/amdgpu/uvd_v6_0.c  |   7 +-
  drivers/gpu/drm/amd/amdgpu/uvd_v7_0.c  |   8 +-
  drivers/gpu/drm/amd/amdgpu/vce_v2_0.c  |   3 +-
  drivers/gpu/drm/amd/amdgpu/vce_v3_0.c  |   3 +-
  drivers/gpu/drm/amd/amdgpu/vce_v4_0.c  |   3 +-
  drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c  |   6 +-
  drivers/gpu/drm/amd/amdgpu/vcn_v2_0.c  |   6 +-
  drivers/gpu/drm/amd/amdgpu/vcn_v2_5.c  |   7 +-
  35 files changed, 144 insertions(+), 197 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index 29f0a410091b..32bc2a882fd2 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -858,6 +858,7 @@ struct amdgpu_device {
struct amdgpu_ring  *rings[AMDGPU_MAX_RINGS];
boolib_pool_ready;
struct amdgpu_sa_managerring_tmp_bo[AMDGPU_IB_POOL_MAX];
+   struct amdgpu_sched 
gpu_sched[AMDGPU_HW_IP_NUM][AMDGPU_RING_PRIO_MAX];

/* interrupts */
struct amdgpu_irq   irq;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
index 6ed36a2c5f73..8842c55d4490 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
@@ -26,6 +26,7 @@
  #include "amdgpu.h"
  #include "amdgpu_sched.h"
  #include "amdgpu_ras.h"
+#include 

  #define to_amdgpu_ctx_entity(e)   \
container_of((e), struct amdgpu_ctx_entity, entity)
@@ -72,13 +73,30 @@ static enum gfx_pipe_priority 
amdgpu_ctx_sched_prio_to_compute_prio(enum drm_sch
}
  }

-static int amdgpu_ctx_init_entity(struct amdgpu_ctx *ctx, const u32 hw_ip, 
const u32 ring)
+static unsigned int amdgpu_ctx_prio_sched_to_hw(struct amdgpu_device *adev,
+enum drm_sched_priority prio,
+u32 hw_ip)
+{
+   unsigned int hw_prio;
+
+   hw_prio = (hw_ip == AMDGPU_HW_IP_COMPUTE) ?
+   amdgpu_ctx_sched_prio_to_compute_prio(prio) :
+   AMDGPU_RING_PRIO_DEFAULT;
+   hw_ip = array_index_nospec(hw_ip, AMDGPU_HW_IP_NUM);
+   if (adev->gpu_sched[hw_ip][hw_prio].num_scheds == 0)
+   hw_prio = AMDGPU_RING_PRIO_DEFAULT;
+
+   return hw_prio;
+}
+
+static int amdgpu_ctx_init_entity(struct amdgpu_ctx *ctx, u32 hw_ip,
+  const u32 ring)
  {
struct amdgpu_device *adev = ctx->adev;
struct amdgpu_ctx_entity *entity;
struct drm_gpu_scheduler **scheds = NULL, *sched = NULL;
unsigned num_scheds = 0;
-   enum gfx_pipe_priority hw_prio;
+   unsigned int hw_prio;
enum drm_sched_priority priority;
int 

Re: [PATCH v5 2/2] drm/amdgpu: rework sched_list generation

2020-04-03 Thread Nirmoy

ping!

On 3/31/20 3:59 PM, Nirmoy Das wrote:

Generate HW IP's sched_list in amdgpu_ring_init() instead of
amdgpu_ctx.c. This makes amdgpu_ctx_init_compute_sched(),
ring.has_high_prio and amdgpu_ctx_init_sched() unnecessary.
This patch also stores sched_list for all HW IPs in one big
array in struct amdgpu_device which makes amdgpu_ctx_init_entity()
much more leaner.

v2:
fix a coding style issue
do not use drm hw_ip const to populate amdgpu_ring_type enum

v3:
remove ctx reference and move sched array and num_sched to a struct
use num_scheds to detect uninitialized scheduler list

v4:
use array_index_nospec for user space controlled variables
fix possible checkpatch.pl warnings

Signed-off-by: Nirmoy Das 
---
  drivers/gpu/drm/amd/amdgpu/amdgpu.h|   1 +
  drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c| 160 +
  drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.h|   3 -
  drivers/gpu/drm/amd/amdgpu/amdgpu_device.c |   2 -
  drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c|   3 +-
  drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.h|   5 -
  drivers/gpu/drm/amd/amdgpu/amdgpu_jpeg.h   |   2 -
  drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c   |  14 +-
  drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h   |  14 +-
  drivers/gpu/drm/amd/amdgpu/amdgpu_sdma.h   |   2 -
  drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h|   4 -
  drivers/gpu/drm/amd/amdgpu/cik_sdma.c  |   3 +-
  drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c |  14 +-
  drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c  |   7 +-
  drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c  |   7 +-
  drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c  |  11 +-
  drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c  |  13 +-
  drivers/gpu/drm/amd/amdgpu/jpeg_v1_0.c |   3 +-
  drivers/gpu/drm/amd/amdgpu/jpeg_v2_0.c |   3 +-
  drivers/gpu/drm/amd/amdgpu/jpeg_v2_5.c |   3 +-
  drivers/gpu/drm/amd/amdgpu/sdma_v2_4.c |   3 +-
  drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c |   3 +-
  drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c |   6 +-
  drivers/gpu/drm/amd/amdgpu/sdma_v5_0.c |   3 +-
  drivers/gpu/drm/amd/amdgpu/si_dma.c|   3 +-
  drivers/gpu/drm/amd/amdgpu/uvd_v4_2.c  |   3 +-
  drivers/gpu/drm/amd/amdgpu/uvd_v5_0.c  |   3 +-
  drivers/gpu/drm/amd/amdgpu/uvd_v6_0.c  |   7 +-
  drivers/gpu/drm/amd/amdgpu/uvd_v7_0.c  |   8 +-
  drivers/gpu/drm/amd/amdgpu/vce_v2_0.c  |   3 +-
  drivers/gpu/drm/amd/amdgpu/vce_v3_0.c  |   3 +-
  drivers/gpu/drm/amd/amdgpu/vce_v4_0.c  |   3 +-
  drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c  |   6 +-
  drivers/gpu/drm/amd/amdgpu/vcn_v2_0.c  |   6 +-
  drivers/gpu/drm/amd/amdgpu/vcn_v2_5.c  |   7 +-
  35 files changed, 144 insertions(+), 197 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index 29f0a410091b..32bc2a882fd2 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -858,6 +858,7 @@ struct amdgpu_device {
struct amdgpu_ring  *rings[AMDGPU_MAX_RINGS];
boolib_pool_ready;
struct amdgpu_sa_managerring_tmp_bo[AMDGPU_IB_POOL_MAX];
+   struct amdgpu_sched 
gpu_sched[AMDGPU_HW_IP_NUM][AMDGPU_RING_PRIO_MAX];

/* interrupts */
struct amdgpu_irq   irq;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
index 6ed36a2c5f73..8842c55d4490 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
@@ -26,6 +26,7 @@
  #include "amdgpu.h"
  #include "amdgpu_sched.h"
  #include "amdgpu_ras.h"
+#include 

  #define to_amdgpu_ctx_entity(e)   \
container_of((e), struct amdgpu_ctx_entity, entity)
@@ -72,13 +73,30 @@ static enum gfx_pipe_priority 
amdgpu_ctx_sched_prio_to_compute_prio(enum drm_sch
}
  }

-static int amdgpu_ctx_init_entity(struct amdgpu_ctx *ctx, const u32 hw_ip, 
const u32 ring)
+static unsigned int amdgpu_ctx_prio_sched_to_hw(struct amdgpu_device *adev,
+enum drm_sched_priority prio,
+u32 hw_ip)
+{
+   unsigned int hw_prio;
+
+   hw_prio = (hw_ip == AMDGPU_HW_IP_COMPUTE) ?
+   amdgpu_ctx_sched_prio_to_compute_prio(prio) :
+   AMDGPU_RING_PRIO_DEFAULT;
+   hw_ip = array_index_nospec(hw_ip, AMDGPU_HW_IP_NUM);
+   if (adev->gpu_sched[hw_ip][hw_prio].num_scheds == 0)
+   hw_prio = AMDGPU_RING_PRIO_DEFAULT;
+
+   return hw_prio;
+}
+
+static int amdgpu_ctx_init_entity(struct amdgpu_ctx *ctx, u32 hw_ip,
+  const u32 ring)
  {
struct amdgpu_device *adev = ctx->adev;
struct amdgpu_ctx_entity *entity;
struct drm_gpu_scheduler **scheds = NULL, *sched = NULL;
unsigned num_scheds = 0;
-   enum gfx_pipe_priority hw_prio;
+   unsigned int hw_prio;
enum drm_sched_priority priority;

RE: [PATCH] drm/amdgpu: add SPM golden settings for Navi10

2020-04-03 Thread Xu, Feifei
[AMD Official Use Only - Internal Distribution Only]



Reviewed-by: Feifei Xu 

-Original Message-
From: Tianci Yin  
Sent: 2020年4月3日 13:30
To: amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander ; Hesik, Christopher 
; Zhang, Hawking ; Xu, Feifei 
; Yin, Tianci (Rico) 
Subject: [PATCH] drm/amdgpu: add SPM golden settings for Navi10

From: "Tianci.Yin" 

Add RLC_SPM golden settings

Change-Id: I616e127171293d915cb3a05dee02f51cec8d8f6f
Signed-off-by: Tianci.Yin 
---
 drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c|9 +
 .../gpu/drm/amd/amdgpu/golden_gc_spm_10_1_0.h | 1058 +
 2 files changed, 1067 insertions(+)
 create mode 100644 drivers/gpu/drm/amd/amdgpu/golden_gc_spm_10_1_0.h

diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c 
b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
index 70edbbf84338..7c96a894ad37 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
@@ -48,6 +48,7 @@
 #include "v10_structs.h"
 #include "gfx_v10_0.h"
 #include "nbio_v2_3.h"
+#include "golden_gc_spm_10_1_0.h"
 
 /**
  * Navi10 has two graphic rings to share each graphic pipe.
@@ -138,6 +139,11 @@ static const struct soc15_reg_golden 
golden_settings_gc_10_0_nv10[] =
/* Pending on emulation bring up */
 };
 
+static const struct soc15_reg_golden golden_settings_gc_rlc_spm_10_0_nv10[] =
+{
+   GOLDEN_GC_SPM_10_1_0
+};
+
 static const struct soc15_reg_golden golden_settings_gc_10_1_1[] =
 {
SOC15_REG_GOLDEN_VALUE(GC, 0, mmCB_HW_CONTROL_4, 0x, 
0x003c0014),
@@ -388,6 +394,9 @@ static void gfx_v10_0_init_golden_registers(struct 
amdgpu_device *adev)
soc15_program_register_sequence(adev,
golden_settings_gc_10_0_nv10,
(const 
u32)ARRAY_SIZE(golden_settings_gc_10_0_nv10));
+   soc15_program_register_sequence(adev,
+   
golden_settings_gc_rlc_spm_10_0_nv10,
+   (const 
u32)ARRAY_SIZE(golden_settings_gc_rlc_spm_10_0_nv10));
break;
case CHIP_NAVI14:
soc15_program_register_sequence(adev,
diff --git a/drivers/gpu/drm/amd/amdgpu/golden_gc_spm_10_1_0.h 
b/drivers/gpu/drm/amd/amdgpu/golden_gc_spm_10_1_0.h
new file mode 100644
index ..e65af4a6fcdd
--- /dev/null
+++ b/drivers/gpu/drm/amd/amdgpu/golden_gc_spm_10_1_0.h
@@ -0,0 +1,1058 @@
+#ifndef __GOLDEN_GC_SPM_10_1_0_H__
+#define __GOLDEN_GC_SPM_10_1_0_H__
+
+#define GOLDEN_GC_SPM_10_1_0 \
+SOC15_REG_GOLDEN_VALUE(GC, 0, mmGRBM_GFX_INDEX, 0xe000, 0x0), \
+SOC15_REG_GOLDEN_VALUE(GC, 0, mmGRBM_GFX_INDEX, 0xff, 0x0), \
+SOC15_REG_GOLDEN_VALUE(GC, 0, mmRLC_SPM_GLB_SAMPLEDELAY_IND_ADDR, 0x, 
0x28), \
+SOC15_REG_GOLDEN_VALUE(GC, 0, mmGRBM_GFX_INDEX, 0xff, 0x0), \
+SOC15_REG_GOLDEN_VALUE(GC, 0, mmRLC_SPM_GLB_SAMPLEDELAY_IND_DATA, 0x, 
0x9), \
+SOC15_REG_GOLDEN_VALUE(GC, 0, mmGRBM_GFX_INDEX, 0xff, 0x0), \
+SOC15_REG_GOLDEN_VALUE(GC, 0, mmRLC_SPM_SE_SAMPLEDELAY_IND_ADDR, 0x, 
0x8), \
+SOC15_REG_GOLDEN_VALUE(GC, 0, mmGRBM_GFX_INDEX, 0xff, 0x0), \
+SOC15_REG_GOLDEN_VALUE(GC, 0, mmRLC_SPM_SE_SAMPLEDELAY_IND_DATA, 0x, 
0x1b), \
+SOC15_REG_GOLDEN_VALUE(GC, 0, mmGRBM_GFX_INDEX, 0xff, 0x1), \
+SOC15_REG_GOLDEN_VALUE(GC, 0, mmRLC_SPM_SE_SAMPLEDELAY_IND_ADDR, 0x, 
0x8), \
+SOC15_REG_GOLDEN_VALUE(GC, 0, mmGRBM_GFX_INDEX, 0xff, 0x1), \
+SOC15_REG_GOLDEN_VALUE(GC, 0, mmRLC_SPM_SE_SAMPLEDELAY_IND_DATA, 0x, 
0x1b), \
+SOC15_REG_GOLDEN_VALUE(GC, 0, mmGRBM_GFX_INDEX, 0xff, 0x0), \
+SOC15_REG_GOLDEN_VALUE(GC, 0, mmRLC_SPM_GLB_SAMPLEDELAY_IND_ADDR, 0x, 
0x20), \
+SOC15_REG_GOLDEN_VALUE(GC, 0, mmGRBM_GFX_INDEX, 0xff, 0x0), \
+SOC15_REG_GOLDEN_VALUE(GC, 0, mmRLC_SPM_GLB_SAMPLEDELAY_IND_DATA, 0x, 
0xe), \
+SOC15_REG_GOLDEN_VALUE(GC, 0, mmGRBM_GFX_INDEX, 0xff, 0x0), \
+SOC15_REG_GOLDEN_VALUE(GC, 0, mmRLC_SPM_GLB_SAMPLEDELAY_IND_ADDR, 0x, 
0xc8), \
+SOC15_REG_GOLDEN_VALUE(GC, 0, mmGRBM_GFX_INDEX, 0xff, 0x0), \
+SOC15_REG_GOLDEN_VALUE(GC, 0, mmRLC_SPM_GLB_SAMPLEDELAY_IND_DATA, 0x, 
0xf), \
+SOC15_REG_GOLDEN_VALUE(GC, 0, mmGRBM_GFX_INDEX, 0xff, 0x0), \
+SOC15_REG_GOLDEN_VALUE(GC, 0, mmRLC_SPM_GLB_SAMPLEDELAY_IND_ADDR, 0x, 
0xcc), \
+SOC15_REG_GOLDEN_VALUE(GC, 0, mmGRBM_GFX_INDEX, 0xff, 0x0), \
+SOC15_REG_GOLDEN_VALUE(GC, 0, mmRLC_SPM_GLB_SAMPLEDELAY_IND_DATA, 0x, 
0xf), \
+SOC15_REG_GOLDEN_VALUE(GC, 0, mmGRBM_GFX_INDEX, 0xff, 0x0), \
+SOC15_REG_GOLDEN_VALUE(GC, 0, mmRLC_SPM_GLB_SAMPLEDELAY_IND_ADDR, 0x, 
0xd0), \
+SOC15_REG_GOLDEN_VALUE(GC, 0, mmGRBM_GFX_INDEX, 0xff, 0x0), \
+SOC15_REG_GOLDEN_VALUE(GC, 0, mmRLC_SPM_GLB_SAMPLEDELAY_IND_DATA, 0x, 
0xf), \
+SOC15_REG_GOLDEN_VALUE(GC, 0, mmGRBM_GFX_INDEX, 0xff, 0x0), \
+SOC15_REG_GOLDEN_VALUE(GC, 0, mmRLC_SPM_GLB_SAMPLEDELAY_IND_ADDR, 0x, 

Re: [PATCH 1/6] dma-buf: add peer2peer flag

2020-04-03 Thread Daniel Vetter
On Wed, Apr 01, 2020 at 04:04:14PM +, Ruhl, Michael J wrote:
> >-Original Message-
> >From: dri-devel  On Behalf Of
> >Daniel Vetter
> >Sent: Wednesday, April 1, 2020 7:35 AM
> >To: Christian König 
> >Cc: amd-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org
> >Subject: Re: [PATCH 1/6] dma-buf: add peer2peer flag
> >
> >On Mon, Mar 30, 2020 at 03:55:31PM +0200, Christian König wrote:
> >> Add a peer2peer flag noting that the importer can deal with device
> >> resources which are not backed by pages.
> >>
> >> Signed-off-by: Christian König 
> >> ---
> >>  drivers/dma-buf/dma-buf.c |  2 ++
> >>  include/linux/dma-buf.h   | 10 ++
> >>  2 files changed, 12 insertions(+)
> >>
> >> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> >> index ccc9eda1bc28..570c923023e6 100644
> >> --- a/drivers/dma-buf/dma-buf.c
> >> +++ b/drivers/dma-buf/dma-buf.c
> >> @@ -690,6 +690,8 @@ dma_buf_dynamic_attach(struct dma_buf *dmabuf,
> >struct device *dev,
> >>
> >>attach->dev = dev;
> >>attach->dmabuf = dmabuf;
> >> +  if (importer_ops)
> >> +  attach->peer2peer = importer_ops->allow_peer2peer;
> >
> >So an idea that crossed my mind to validate this, since we need quite some
> >bad amounts of bad luck if someone accidentally introduces and access to
> >struct_page in sg lists in some slowpath.
> >
> >On map_sg, if ->peer2peer is set, we could mangle the struct_page
> >pointers, e.g. swap high bits for low bits (so that NULL stays NULL). On
> >unmap_sg we obviously need to undo that, in case the exporter needs those
> >pointers for its own book-keeping for some reason. I was also pondering
> >just setting them all to NULL, but that might break some exporters. With
> >the pointer mangling trick (especially if we flip high for low bits on 64
> >where this should result in invalid addresses in almost all cases) we
> >should be able to catch buggy p2p importers quite quickly.
> 
> The scatter list usage of the struct page pointer has other information in the
> lower bits for keeping track of linking and other stuff.  Swizzling the page
> pointers will probably make the scatter list unusable.

We'd need to swizzle only the pointers that are actual struct page
pointers. Plus keep the low bits as-is, and maybe only flip the top-most
60 bits or so. Doesn't break the idea fundamentally I think.
-Daniel

> 
> Mike
> 
> >Thoughts? Maybe add as a follow-up patch for testing?
> >-Daniel
> >>attach->importer_ops = importer_ops;
> >>attach->importer_priv = importer_priv;
> >>
> >> diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
> >> index 1ade486fc2bb..82e0a4a64601 100644
> >> --- a/include/linux/dma-buf.h
> >> +++ b/include/linux/dma-buf.h
> >> @@ -334,6 +334,14 @@ struct dma_buf {
> >>   * Attachment operations implemented by the importer.
> >>   */
> >>  struct dma_buf_attach_ops {
> >> +  /**
> >> +   * @allow_peer2peer:
> >> +   *
> >> +   * If this is set to true the importer must be able to handle peer
> >> +   * resources without struct pages.
> >> +   */
> >> +  bool allow_peer2peer;
> >> +
> >>/**
> >> * @move_notify
> >> *
> >> @@ -362,6 +370,7 @@ struct dma_buf_attach_ops {
> >>   * @node: list of dma_buf_attachment, protected by dma_resv lock of the
> >dmabuf.
> >>   * @sgt: cached mapping.
> >>   * @dir: direction of cached mapping.
> >> + * @peer2peer: true if the importer can handle peer resources without
> >pages.
> >>   * @priv: exporter specific attachment data.
> >>   * @importer_ops: importer operations for this attachment, if provided
> >>   * dma_buf_map/unmap_attachment() must be called with the dma_resv
> >lock held.
> >> @@ -382,6 +391,7 @@ struct dma_buf_attachment {
> >>struct list_head node;
> >>struct sg_table *sgt;
> >>enum dma_data_direction dir;
> >> +  bool peer2peer;
> >>const struct dma_buf_attach_ops *importer_ops;
> >>void *importer_priv;
> >>void *priv;
> >> --
> >> 2.17.1
> >>
> >
> >--
> >Daniel Vetter
> >Software Engineer, Intel Corporation
> >http://blog.ffwll.ch
> >___
> >dri-devel mailing list
> >dri-de...@lists.freedesktop.org
> >https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


RE: [PATCH] drm/amdgpu/sriov add amdgpu_amdkfd_pre_reset in gpu reset

2020-04-03 Thread Liu, Monk
Reviewed-by: Monk Liu 

_
Monk Liu|GPU Virtualization Team |AMD


-Original Message-
From: amd-gfx  On Behalf Of Jack Zhang
Sent: Friday, April 3, 2020 1:03 PM
To: amd-gfx@lists.freedesktop.org
Cc: Zhang, Jack (Jian) 
Subject: [PATCH] drm/amdgpu/sriov add amdgpu_amdkfd_pre_reset in gpu reset

kfd_pre_reset will free mem_objs allocated by kfd_gtt_sa_allocate

Without this change, sriov tdr code path will never free those allocated 
memories and get memory leak.

v2:add a bugfix for kiq ring test fail

Signed-off-by: Jack Zhang 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10.c | 3 +++  
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.c  | 3 +++
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 2 ++
 3 files changed, 8 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10.c
index 4ec6d0c..bdc1f5a 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10.c
@@ -543,6 +543,9 @@ static int kgd_hqd_destroy(struct kgd_dev *kgd, void *mqd,
uint32_t temp;
struct v10_compute_mqd *m = get_mqd(mqd);
 
+   if (amdgpu_sriov_vf(adev) && adev->in_gpu_reset)
+   return 0;
+
 #if 0
unsigned long flags;
int retry;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.c
index df841c2..c2562d6 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.c
@@ -541,6 +541,9 @@ int kgd_gfx_v9_hqd_destroy(struct kgd_dev *kgd, void *mqd,
uint32_t temp;
struct v9_mqd *m = get_mqd(mqd);
 
+   if (amdgpu_sriov_vf(adev) && adev->in_gpu_reset)
+   return 0;
+
if (adev->in_gpu_reset)
return -EIO;
 
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index 8faaa17..e3f7441 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -3854,6 +3854,8 @@ static int amdgpu_device_reset_sriov(struct amdgpu_device 
*adev,
if (r)
return r;
 
+   amdgpu_amdkfd_pre_reset(adev);
+
/* Resume IP prior to SMC */
r = amdgpu_device_ip_reinit_early_sriov(adev);
if (r)
--
2.7.4

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfxdata=02%7C01%7Cmonk.liu%40amd.com%7C8506d4a2f5034c8afde008d7d78c4a3d%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637214869899102590sdata=4TK7XVJvnPMtMc8woS8KL0xJvuxs8reDu0%2FQEfOpu9s%3Dreserved=0
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


RE: [PATCH] drm/amd/powerplay: avoid using pm_en before it is initialized

2020-04-03 Thread Deng, Emily
[AMD Official Use Only - Internal Distribution Only]

Reviewed-by: Emily Deng 

>-Original Message-
>From: amd-gfx  On Behalf Of Zhou,
>Tiecheng
>Sent: Friday, April 3, 2020 12:42 PM
>To: Zhou, Tiecheng ; amd-
>g...@lists.freedesktop.org
>Cc: Tao, Yintian 
>Subject: RE: [PATCH] drm/amd/powerplay: avoid using pm_en before it is
>initialized
>
>[AMD Official Use Only - Internal Distribution Only]
>
>Ping...
>
>-Original Message-
>From: Tiecheng Zhou 
>Sent: Thursday, April 2, 2020 5:29 PM
>To: amd-gfx@lists.freedesktop.org
>Cc: Zhou, Tiecheng ; Tao, Yintian
>
>Subject: [PATCH] drm/amd/powerplay: avoid using pm_en before it is
>initialized
>
>hwmgr->pm_en is initialized at hwmgr_hw_init.
>during amdgpu_device_init, there is amdgpu_asic_reset that calls to
>pp_get_asic_baco_capability, while hwmgr->pm_en has not yet been
>initialized.
>
>so avoid using pm_en in pp_get_asic_baco_capability.
>
>Signed-off-by: Tiecheng Zhou 
>Signed-off-by: Yintian Tao 
>---
> drivers/gpu/drm/amd/powerplay/amd_powerplay.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
>diff --git a/drivers/gpu/drm/amd/powerplay/amd_powerplay.c
>b/drivers/gpu/drm/amd/powerplay/amd_powerplay.c
>index 71b843f542d8..fdff3e1c5e95 100644
>--- a/drivers/gpu/drm/amd/powerplay/amd_powerplay.c
>+++ b/drivers/gpu/drm/amd/powerplay/amd_powerplay.c
>@@ -1455,7 +1455,8 @@ static int pp_get_asic_baco_state(void *handle, int
>*state)
>   if (!hwmgr)
>   return -EINVAL;
>
>-  if (!hwmgr->pm_en || !hwmgr->hwmgr_func->get_asic_baco_state)
>+  if (!(hwmgr->not_vf && amdgpu_dpm) ||
>+  !hwmgr->hwmgr_func->get_asic_baco_state)
>   return 0;
>
>   mutex_lock(>smu_lock);
>--
>2.17.1
>___
>amd-gfx mailing list
>amd-gfx@lists.freedesktop.org
>https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.fre
>edesktop.org%2Fmailman%2Flistinfo%2Famd-
>gfxdata=02%7C01%7CEmily.Deng%40amd.com%7Cfc7cc02f1db043b393
>1108d7d7895f4d%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637
>214857946885870sdata=J8iQUQc8phHtblO1gn9TkoI%2BJ%2BehvD4RVfi
>7MybTuCQ%3Dreserved=0
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


RE: [PATCH] drm/amd/amdgpu: Correct gfx10's CG sequence

2020-04-03 Thread Quan, Evan
Acked-by: Evan Quan 

-Original Message-
From: Chengming Gui  
Sent: Friday, April 3, 2020 3:14 PM
To: amd-gfx@lists.freedesktop.org
Cc: Quan, Evan ; Feng, Kenneth ; Yin, 
Tianci (Rico) ; Xu, Feifei ; Zhang, 
Hawking ; Gui, Jack 
Subject: [PATCH] drm/amd/amdgpu: Correct gfx10's CG sequence

Incorrect CG sequence will cause gfx timedout,
if we keep switching power profile mode
(enter profile mod such as PEAK will disable CG,
exit profile mode EXIT will enable CG)
when run Vulkan test case(case used for test: vkexample).

Signed-off-by: Chengming Gui 
---
 drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 23 +++
 1 file changed, 15 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c 
b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
index 51be7aa..1439dd9 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
@@ -4097,6 +4097,12 @@ static void 
gfx_v10_0_update_medium_grain_clock_gating(struct amdgpu_device *ade
 
/* It is disabled by HW by default */
if (enable && (adev->cg_flags & AMD_CG_SUPPORT_GFX_MGCG)) {
+   /* 0 - Disable some blocks' MGCG */
+   WREG32_SOC15(GC, 0, mmGRBM_GFX_INDEX, 0xe000);
+   WREG32_SOC15(GC, 0, mmCGTT_WD_CLK_CTRL, 0xff00);
+   WREG32_SOC15(GC, 0, mmCGTT_VGT_CLK_CTRL, 0xff00);
+   WREG32_SOC15(GC, 0, mmCGTT_IA_CLK_CTRL, 0xff00);
+
/* 1 - RLC_CGTT_MGCG_OVERRIDE */
def = data = RREG32_SOC15(GC, 0, mmRLC_CGTT_MGCG_OVERRIDE);
data &= ~(RLC_CGTT_MGCG_OVERRIDE__GRBM_CGTT_SCLK_OVERRIDE_MASK |
@@ -4136,19 +4142,20 @@ static void 
gfx_v10_0_update_medium_grain_clock_gating(struct amdgpu_device *ade
if (def != data)
WREG32_SOC15(GC, 0, mmRLC_CGTT_MGCG_OVERRIDE, data);
 
-   /* 2 - disable MGLS in RLC */
+   /* 2 - disable MGLS in CP */
+   data = RREG32_SOC15(GC, 0, mmCP_MEM_SLP_CNTL);
+   if (data & CP_MEM_SLP_CNTL__CP_MEM_LS_EN_MASK) {
+   data &= ~CP_MEM_SLP_CNTL__CP_MEM_LS_EN_MASK;
+   WREG32_SOC15(GC, 0, mmCP_MEM_SLP_CNTL, data);
+   }
+
+   /* 3 - disable MGLS in RLC */
data = RREG32_SOC15(GC, 0, mmRLC_MEM_SLP_CNTL);
if (data & RLC_MEM_SLP_CNTL__RLC_MEM_LS_EN_MASK) {
data &= ~RLC_MEM_SLP_CNTL__RLC_MEM_LS_EN_MASK;
WREG32_SOC15(GC, 0, mmRLC_MEM_SLP_CNTL, data);
}
 
-   /* 3 - disable MGLS in CP */
-   data = RREG32_SOC15(GC, 0, mmCP_MEM_SLP_CNTL);
-   if (data & CP_MEM_SLP_CNTL__CP_MEM_LS_EN_MASK) {
-   data &= ~CP_MEM_SLP_CNTL__CP_MEM_LS_EN_MASK;
-   WREG32_SOC15(GC, 0, mmCP_MEM_SLP_CNTL, data);
-   }
}
 }
 
@@ -4259,7 +4266,7 @@ static int gfx_v10_0_update_gfx_clock_gating(struct 
amdgpu_device *adev,
/* ===  CGCG /CGLS for GFX 3D Only === */
gfx_v10_0_update_3d_clock_gating(adev, enable);
/* ===  MGCG + MGLS === */
-   gfx_v10_0_update_medium_grain_clock_gating(adev, enable);
+   /* gfx_v10_0_update_medium_grain_clock_gating(adev, enable); */
}
 
if (adev->cg_flags &
-- 
2.7.4

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


RE: [PATCH] drm/amd/amdgpu: Correct gfx10's CG sequence

2020-04-03 Thread Feng, Kenneth
[AMD Official Use Only - Internal Distribution Only]

This sequence is confirmed in the design document.
Reviewed-by: Kenneth Feng 


-Original Message-
From: Chengming Gui  
Sent: Friday, April 3, 2020 3:14 PM
To: amd-gfx@lists.freedesktop.org
Cc: Quan, Evan ; Feng, Kenneth ; Yin, 
Tianci (Rico) ; Xu, Feifei ; Zhang, 
Hawking ; Gui, Jack 
Subject: [PATCH] drm/amd/amdgpu: Correct gfx10's CG sequence

Incorrect CG sequence will cause gfx timedout, if we keep switching power 
profile mode (enter profile mod such as PEAK will disable CG, exit profile mode 
EXIT will enable CG) when run Vulkan test case(case used for test: vkexample).

Signed-off-by: Chengming Gui 
---
 drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 23 +++
 1 file changed, 15 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c 
b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
index 51be7aa..1439dd9 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
@@ -4097,6 +4097,12 @@ static void 
gfx_v10_0_update_medium_grain_clock_gating(struct amdgpu_device *ade
 
/* It is disabled by HW by default */
if (enable && (adev->cg_flags & AMD_CG_SUPPORT_GFX_MGCG)) {
+   /* 0 - Disable some blocks' MGCG */
+   WREG32_SOC15(GC, 0, mmGRBM_GFX_INDEX, 0xe000);
+   WREG32_SOC15(GC, 0, mmCGTT_WD_CLK_CTRL, 0xff00);
+   WREG32_SOC15(GC, 0, mmCGTT_VGT_CLK_CTRL, 0xff00);
+   WREG32_SOC15(GC, 0, mmCGTT_IA_CLK_CTRL, 0xff00);
+
/* 1 - RLC_CGTT_MGCG_OVERRIDE */
def = data = RREG32_SOC15(GC, 0, mmRLC_CGTT_MGCG_OVERRIDE);
data &= ~(RLC_CGTT_MGCG_OVERRIDE__GRBM_CGTT_SCLK_OVERRIDE_MASK 
| @@ -4136,19 +4142,20 @@ static void 
gfx_v10_0_update_medium_grain_clock_gating(struct amdgpu_device *ade
if (def != data)
WREG32_SOC15(GC, 0, mmRLC_CGTT_MGCG_OVERRIDE, data);
 
-   /* 2 - disable MGLS in RLC */
+   /* 2 - disable MGLS in CP */
+   data = RREG32_SOC15(GC, 0, mmCP_MEM_SLP_CNTL);
+   if (data & CP_MEM_SLP_CNTL__CP_MEM_LS_EN_MASK) {
+   data &= ~CP_MEM_SLP_CNTL__CP_MEM_LS_EN_MASK;
+   WREG32_SOC15(GC, 0, mmCP_MEM_SLP_CNTL, data);
+   }
+
+   /* 3 - disable MGLS in RLC */
data = RREG32_SOC15(GC, 0, mmRLC_MEM_SLP_CNTL);
if (data & RLC_MEM_SLP_CNTL__RLC_MEM_LS_EN_MASK) {
data &= ~RLC_MEM_SLP_CNTL__RLC_MEM_LS_EN_MASK;
WREG32_SOC15(GC, 0, mmRLC_MEM_SLP_CNTL, data);
}
 
-   /* 3 - disable MGLS in CP */
-   data = RREG32_SOC15(GC, 0, mmCP_MEM_SLP_CNTL);
-   if (data & CP_MEM_SLP_CNTL__CP_MEM_LS_EN_MASK) {
-   data &= ~CP_MEM_SLP_CNTL__CP_MEM_LS_EN_MASK;
-   WREG32_SOC15(GC, 0, mmCP_MEM_SLP_CNTL, data);
-   }
}
 }
 
@@ -4259,7 +4266,7 @@ static int gfx_v10_0_update_gfx_clock_gating(struct 
amdgpu_device *adev,
/* ===  CGCG /CGLS for GFX 3D Only === */
gfx_v10_0_update_3d_clock_gating(adev, enable);
/* ===  MGCG + MGLS === */
-   gfx_v10_0_update_medium_grain_clock_gating(adev, enable);
+   /* gfx_v10_0_update_medium_grain_clock_gating(adev, enable); */
}
 
if (adev->cg_flags &
--
2.7.4
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


[PATCH] drm/amd/amdgpu: Correct gfx10's CG sequence

2020-04-03 Thread Chengming Gui
Incorrect CG sequence will cause gfx timedout,
if we keep switching power profile mode
(enter profile mod such as PEAK will disable CG,
exit profile mode EXIT will enable CG)
when run Vulkan test case(case used for test: vkexample).

Signed-off-by: Chengming Gui 
---
 drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 23 +++
 1 file changed, 15 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c 
b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
index 51be7aa..1439dd9 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
@@ -4097,6 +4097,12 @@ static void 
gfx_v10_0_update_medium_grain_clock_gating(struct amdgpu_device *ade
 
/* It is disabled by HW by default */
if (enable && (adev->cg_flags & AMD_CG_SUPPORT_GFX_MGCG)) {
+   /* 0 - Disable some blocks' MGCG */
+   WREG32_SOC15(GC, 0, mmGRBM_GFX_INDEX, 0xe000);
+   WREG32_SOC15(GC, 0, mmCGTT_WD_CLK_CTRL, 0xff00);
+   WREG32_SOC15(GC, 0, mmCGTT_VGT_CLK_CTRL, 0xff00);
+   WREG32_SOC15(GC, 0, mmCGTT_IA_CLK_CTRL, 0xff00);
+
/* 1 - RLC_CGTT_MGCG_OVERRIDE */
def = data = RREG32_SOC15(GC, 0, mmRLC_CGTT_MGCG_OVERRIDE);
data &= ~(RLC_CGTT_MGCG_OVERRIDE__GRBM_CGTT_SCLK_OVERRIDE_MASK |
@@ -4136,19 +4142,20 @@ static void 
gfx_v10_0_update_medium_grain_clock_gating(struct amdgpu_device *ade
if (def != data)
WREG32_SOC15(GC, 0, mmRLC_CGTT_MGCG_OVERRIDE, data);
 
-   /* 2 - disable MGLS in RLC */
+   /* 2 - disable MGLS in CP */
+   data = RREG32_SOC15(GC, 0, mmCP_MEM_SLP_CNTL);
+   if (data & CP_MEM_SLP_CNTL__CP_MEM_LS_EN_MASK) {
+   data &= ~CP_MEM_SLP_CNTL__CP_MEM_LS_EN_MASK;
+   WREG32_SOC15(GC, 0, mmCP_MEM_SLP_CNTL, data);
+   }
+
+   /* 3 - disable MGLS in RLC */
data = RREG32_SOC15(GC, 0, mmRLC_MEM_SLP_CNTL);
if (data & RLC_MEM_SLP_CNTL__RLC_MEM_LS_EN_MASK) {
data &= ~RLC_MEM_SLP_CNTL__RLC_MEM_LS_EN_MASK;
WREG32_SOC15(GC, 0, mmRLC_MEM_SLP_CNTL, data);
}
 
-   /* 3 - disable MGLS in CP */
-   data = RREG32_SOC15(GC, 0, mmCP_MEM_SLP_CNTL);
-   if (data & CP_MEM_SLP_CNTL__CP_MEM_LS_EN_MASK) {
-   data &= ~CP_MEM_SLP_CNTL__CP_MEM_LS_EN_MASK;
-   WREG32_SOC15(GC, 0, mmCP_MEM_SLP_CNTL, data);
-   }
}
 }
 
@@ -4259,7 +4266,7 @@ static int gfx_v10_0_update_gfx_clock_gating(struct 
amdgpu_device *adev,
/* ===  CGCG /CGLS for GFX 3D Only === */
gfx_v10_0_update_3d_clock_gating(adev, enable);
/* ===  MGCG + MGLS === */
-   gfx_v10_0_update_medium_grain_clock_gating(adev, enable);
+   /* gfx_v10_0_update_medium_grain_clock_gating(adev, enable); */
}
 
if (adev->cg_flags &
-- 
2.7.4

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


[PATCH] drm/amd/powerplay: error out on forcing clock setting not supported

2020-04-03 Thread Evan Quan
For Arcturus, forcing clock to some specific level is not supported
with 54.18 and onwards SMU firmware. As according to firmware team,
they adopt new gfx dpm tuned parameters which can cover all the use
case in a much smooth way. Thus setting through driver interface
is not needed and maybe do a disservice.

Change-Id: Ibffdb157639809707aa71049a935e53d1b4d06eb
Signed-off-by: Evan Quan 
---
 drivers/gpu/drm/amd/powerplay/arcturus_ppt.c | 47 +++-
 1 file changed, 46 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/powerplay/arcturus_ppt.c 
b/drivers/gpu/drm/amd/powerplay/arcturus_ppt.c
index 5db8c56066ee..1ef0923f7190 100644
--- a/drivers/gpu/drm/amd/powerplay/arcturus_ppt.c
+++ b/drivers/gpu/drm/amd/powerplay/arcturus_ppt.c
@@ -794,8 +794,21 @@ static int arcturus_force_clk_levels(struct smu_context 
*smu,
struct arcturus_dpm_table *dpm_table;
struct arcturus_single_dpm_table *single_dpm_table;
uint32_t soft_min_level, soft_max_level;
+   uint32_t smu_version;
int ret = 0;
 
+   ret = smu_get_smc_version(smu, NULL, _version);
+   if (ret) {
+   pr_err("Failed to get smu version!\n");
+   return ret;
+   }
+
+   if (smu_version >= 0x361200) {
+   pr_err("Forcing clock level is not supported with "
+  "54.18 and onwards SMU firmwares\n");
+   return -EOPNOTSUPP;
+   }
+
soft_min_level = mask ? (ffs(mask) - 1) : 0;
soft_max_level = mask ? (fls(mask) - 1) : 0;
 
@@ -1512,6 +1525,38 @@ static int arcturus_set_power_profile_mode(struct 
smu_context *smu,
return 0;
 }
 
+static int arcturus_set_performance_level(struct smu_context *smu,
+ enum amd_dpm_forced_level level)
+{
+   uint32_t smu_version;
+   int ret;
+
+   ret = smu_get_smc_version(smu, NULL, _version);
+   if (ret) {
+   pr_err("Failed to get smu version!\n");
+   return ret;
+   }
+
+   switch (level) {
+   case AMD_DPM_FORCED_LEVEL_HIGH:
+   case AMD_DPM_FORCED_LEVEL_LOW:
+   case AMD_DPM_FORCED_LEVEL_PROFILE_STANDARD:
+   case AMD_DPM_FORCED_LEVEL_PROFILE_MIN_SCLK:
+   case AMD_DPM_FORCED_LEVEL_PROFILE_MIN_MCLK:
+   case AMD_DPM_FORCED_LEVEL_PROFILE_PEAK:
+   if (smu_version >= 0x361200) {
+   pr_err("Forcing clock level is not supported with "
+  "54.18 and onwards SMU firmwares\n");
+   return -EOPNOTSUPP;
+   }
+   break;
+   default:
+   break;
+   }
+
+   return smu_v11_0_set_performance_level(smu, level);
+}
+
 static void arcturus_dump_pptable(struct smu_context *smu)
 {
struct smu_table_context *table_context = >smu_table;
@@ -2285,7 +2330,7 @@ static const struct pptable_funcs arcturus_ppt_funcs = {
.get_profiling_clk_mask = arcturus_get_profiling_clk_mask,
.get_power_profile_mode = arcturus_get_power_profile_mode,
.set_power_profile_mode = arcturus_set_power_profile_mode,
-   .set_performance_level = smu_v11_0_set_performance_level,
+   .set_performance_level = arcturus_set_performance_level,
/* debug (internal used) */
.dump_pptable = arcturus_dump_pptable,
.get_power_limit = arcturus_get_power_limit,
-- 
2.26.0

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


[PATCH] drm/amd/powerplay: update smu12_driver_if.h to align with pmfw

2020-04-03 Thread Prike Liang
Update the smu12_driver_if.h header to follow the pmfw release.

Signed-off-by: Prike Liang 
---
 .../gpu/drm/amd/powerplay/inc/smu12_driver_if.h| 42 ++
 1 file changed, 27 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/amd/powerplay/inc/smu12_driver_if.h 
b/drivers/gpu/drm/amd/powerplay/inc/smu12_driver_if.h
index 2f85a34..b4d8f83 100644
--- a/drivers/gpu/drm/amd/powerplay/inc/smu12_driver_if.h
+++ b/drivers/gpu/drm/amd/powerplay/inc/smu12_driver_if.h
@@ -27,7 +27,7 @@
 // *** IMPORTANT ***
 // SMU TEAM: Always increment the interface version if 
 // any structure is changed in this file
-#define SMU12_DRIVER_IF_VERSION 11
+#define SMU12_DRIVER_IF_VERSION 14
 
 typedef struct {
   int32_t value;
@@ -154,15 +154,19 @@ typedef enum {
 } CLOCK_IDs_e;
 
 // Throttler Status Bitmask
-#define THROTTLER_STATUS_BIT_SPL0
-#define THROTTLER_STATUS_BIT_FPPT   1
-#define THROTTLER_STATUS_BIT_SPPT   2
-#define THROTTLER_STATUS_BIT_SPPT_APU   3
-#define THROTTLER_STATUS_BIT_THM_CORE   4
-#define THROTTLER_STATUS_BIT_THM_GFX5
-#define THROTTLER_STATUS_BIT_THM_SOC6
-#define THROTTLER_STATUS_BIT_TDC_VDD7
-#define THROTTLER_STATUS_BIT_TDC_SOC8
+#define THROTTLER_STATUS_BIT_SPL0
+#define THROTTLER_STATUS_BIT_FPPT   1
+#define THROTTLER_STATUS_BIT_SPPT   2
+#define THROTTLER_STATUS_BIT_SPPT_APU   3
+#define THROTTLER_STATUS_BIT_THM_CORE   4
+#define THROTTLER_STATUS_BIT_THM_GFX5
+#define THROTTLER_STATUS_BIT_THM_SOC6
+#define THROTTLER_STATUS_BIT_TDC_VDD7
+#define THROTTLER_STATUS_BIT_TDC_SOC8
+#define THROTTLER_STATUS_BIT_PROCHOT_CPU9
+#define THROTTLER_STATUS_BIT_PROCHOT_GFX   10
+#define THROTTLER_STATUS_BIT_EDC_CPU   11
+#define THROTTLER_STATUS_BIT_EDC_GFX   12
 
 typedef struct {
   uint16_t ClockFrequency[CLOCK_COUNT]; //[MHz]
@@ -180,7 +184,7 @@ typedef struct {
   uint16_t Power[2];//[mW] indices: VDDCR_VDD, VDDCR_SOC
 
   uint16_t FanPwm;  //[milli]
-  uint16_t CurrentSocketPower;  //[mW]
+  uint16_t CurrentSocketPower;  //[W]
 
   uint16_t CoreFrequency[8];//[MHz]
   uint16_t CorePower[8];//[mW]
@@ -193,10 +197,18 @@ typedef struct {
   uint16_t ThrottlerStatus;
   uint16_t spare;
 
-  uint16_t StapmOriginalLimit;  //[mW]
-  uint16_t StapmCurrentLimit;   //[mW]
-  uint16_t ApuPower;  //[mW]
-  uint16_t dGpuPower;   //[mW]
+  uint16_t StapmOriginalLimit;  //[W]
+  uint16_t StapmCurrentLimit;   //[W]
+  uint16_t ApuPower;//[W]
+  uint16_t dGpuPower;   //[W]
+
+  uint16_t VddTdcValue; //[mA]
+  uint16_t SocTdcValue; //[mA]
+  uint16_t VddEdcValue; //[mA]
+  uint16_t SocEdcValue; //[mA]
+
+  uint16_t InfrastructureCpuMaxFreq;//[MHz]
+  uint16_t InfrastructureGfxMaxFreq;//[MHz]
 } SmuMetrics_t;
 
 
-- 
2.7.4

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


Re: [PATCH] drm/amd/powerplay: implement the is_dpm_running()

2020-04-03 Thread Huang Rui
On Fri, Apr 03, 2020 at 02:03:32PM +0800, Liang, Prike wrote:
> As the pmfw hasn't exported the interface of SMU feature
> mask to APU SKU so just force on all the features to driver
> inquired interface at early initial stage.
> 
> Signed-off-by: Prike Liang 

Reviewed-by: Huang Rui 

> ---
>  drivers/gpu/drm/amd/powerplay/renoir_ppt.c | 12 
>  1 file changed, 12 insertions(+)
> 
> diff --git a/drivers/gpu/drm/amd/powerplay/renoir_ppt.c 
> b/drivers/gpu/drm/amd/powerplay/renoir_ppt.c
> index c6b39a7..ff73a73 100644
> --- a/drivers/gpu/drm/amd/powerplay/renoir_ppt.c
> +++ b/drivers/gpu/drm/amd/powerplay/renoir_ppt.c
> @@ -893,6 +893,17 @@ static int renoir_read_sensor(struct smu_context *smu,
>   return ret;
>  }
>  
> +static bool renoir_is_dpm_running(struct smu_context *smu)
> +{
> + /*
> +  * Util now, the pmfw hasn't exported the interface of SMU
> +  * feature mask to APU SKU so just force on all the feature
> +  * at early initial stage.
> +  */
> + return true;
> +
> +}
> +
>  static const struct pptable_funcs renoir_ppt_funcs = {
>   .get_smu_msg_index = renoir_get_smu_msg_index,
>   .get_smu_clk_index = renoir_get_smu_clk_index,
> @@ -933,6 +944,7 @@ static const struct pptable_funcs renoir_ppt_funcs = {
>   .mode2_reset = smu_v12_0_mode2_reset,
>   .set_soft_freq_limited_range = smu_v12_0_set_soft_freq_limited_range,
>   .set_driver_table_location = smu_v12_0_set_driver_table_location,
> + .is_dpm_running = renoir_is_dpm_running,
>  };
>  
>  void renoir_set_ppt_funcs(struct smu_context *smu)
> -- 
> 2.7.4
> 
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


Re: [PATCH] drm/amdgpu: fix gfx hang during suspend with video playback

2020-04-03 Thread Huang Rui
(+ Felix)

On Fri, Apr 03, 2020 at 12:07:53PM +0800, Liang, Prike wrote:
> The system will be hang up during S3 as SMU is pending at GC not
> respose the register CP_HQD_ACTIVE access request and this issue
> can be fixed by adding RLC safe mode guard before each HQD
> map/unmap retrive opt.

We need more information for the issue, does the map/unmap is required for
MAP_QUEUES/UNMAP_QUEUES packets or writing with MMIO or both?

>From your patch, you just protect the kernel kiq and user queue. What about
other kernel compute queues? HIQ?

Thanks,
Ray

> 
> Signed-off-by: Prike Liang 
> Tested-by: Mengbing Wang 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.c | 6 ++
>  drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 4 
>  2 files changed, 10 insertions(+)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.c
> index df841c2..e265063 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.c
> @@ -232,6 +232,7 @@ int kgd_gfx_v9_hqd_load(struct kgd_dev *kgd, void *mqd, 
> uint32_t pipe_id,
>   uint32_t *mqd_hqd;
>   uint32_t reg, hqd_base, data;
>  
> + amdgpu_gfx_rlc_enter_safe_mode(adev);
>   m = get_mqd(mqd);
>  
>   acquire_queue(kgd, pipe_id, queue_id);
> @@ -299,6 +300,7 @@ int kgd_gfx_v9_hqd_load(struct kgd_dev *kgd, void *mqd, 
> uint32_t pipe_id,
>  
>   release_queue(kgd);
>  
> + amdgpu_gfx_rlc_exit_safe_mode(adev);
>   return 0;
>  }
>  
> @@ -497,6 +499,7 @@ bool kgd_gfx_v9_hqd_is_occupied(struct kgd_dev *kgd, 
> uint64_t queue_address,
>   bool retval = false;
>   uint32_t low, high;
>  
> + amdgpu_gfx_rlc_enter_safe_mode(adev);
>   acquire_queue(kgd, pipe_id, queue_id);
>   act = RREG32(SOC15_REG_OFFSET(GC, 0, mmCP_HQD_ACTIVE));
>   if (act) {
> @@ -508,6 +511,7 @@ bool kgd_gfx_v9_hqd_is_occupied(struct kgd_dev *kgd, 
> uint64_t queue_address,
>   retval = true;
>   }
>   release_queue(kgd);
> + amdgpu_gfx_rlc_exit_safe_mode(adev);
>   return retval;
>  }
>  
> @@ -541,6 +545,7 @@ int kgd_gfx_v9_hqd_destroy(struct kgd_dev *kgd, void *mqd,
>   uint32_t temp;
>   struct v9_mqd *m = get_mqd(mqd);
>  
> + amdgpu_gfx_rlc_enter_safe_mode(adev);
>   if (adev->in_gpu_reset)
>   return -EIO;
>  
> @@ -577,6 +582,7 @@ int kgd_gfx_v9_hqd_destroy(struct kgd_dev *kgd, void *mqd,
>   }
>  
>   release_queue(kgd);
> + amdgpu_gfx_rlc_exit_safe_mode(adev);
>   return 0;
>  }
>  
> diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c 
> b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
> index 1fea077..ee107d9 100644
> --- a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
> @@ -3533,6 +3533,7 @@ static int gfx_v9_0_kiq_init_register(struct 
> amdgpu_ring *ring)
>   struct v9_mqd *mqd = ring->mqd_ptr;
>   int j;
>  
> + amdgpu_gfx_rlc_enter_safe_mode(adev);
>   /* disable wptr polling */
>   WREG32_FIELD15(GC, 0, CP_PQ_WPTR_POLL_CNTL, EN, 0);
>  
> @@ -3629,6 +3630,7 @@ static int gfx_v9_0_kiq_init_register(struct 
> amdgpu_ring *ring)
>   if (ring->use_doorbell)
>   WREG32_FIELD15(GC, 0, CP_PQ_STATUS, DOORBELL_ENABLE, 1);
>  
> + amdgpu_gfx_rlc_exit_safe_mode(adev);
>   return 0;
>  }
>  
> @@ -3637,6 +3639,7 @@ static int gfx_v9_0_kiq_fini_register(struct 
> amdgpu_ring *ring)
>   struct amdgpu_device *adev = ring->adev;
>   int j;
>  
> + amdgpu_gfx_rlc_enter_safe_mode(adev);
>   /* disable the queue if it's active */
>   if (RREG32_SOC15(GC, 0, mmCP_HQD_ACTIVE) & 1) {
>  
> @@ -3668,6 +3671,7 @@ static int gfx_v9_0_kiq_fini_register(struct 
> amdgpu_ring *ring)
>   WREG32_SOC15_RLC(GC, 0, mmCP_HQD_PQ_WPTR_HI, 0);
>   WREG32_SOC15_RLC(GC, 0, mmCP_HQD_PQ_WPTR_LO, 0);
>  
> + amdgpu_gfx_rlc_exit_safe_mode(adev);
>   return 0;
>  }
>  
> -- 
> 2.7.4
> 
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


[PATCH] drm/amd/powerplay: implement the is_dpm_running()

2020-04-03 Thread Prike Liang
As the pmfw hasn't exported the interface of SMU feature
mask to APU SKU so just force on all the features to driver
inquired interface at early initial stage.

Signed-off-by: Prike Liang 
---
 drivers/gpu/drm/amd/powerplay/renoir_ppt.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/drivers/gpu/drm/amd/powerplay/renoir_ppt.c 
b/drivers/gpu/drm/amd/powerplay/renoir_ppt.c
index c6b39a7..ff73a73 100644
--- a/drivers/gpu/drm/amd/powerplay/renoir_ppt.c
+++ b/drivers/gpu/drm/amd/powerplay/renoir_ppt.c
@@ -893,6 +893,17 @@ static int renoir_read_sensor(struct smu_context *smu,
return ret;
 }
 
+static bool renoir_is_dpm_running(struct smu_context *smu)
+{
+   /*
+* Util now, the pmfw hasn't exported the interface of SMU
+* feature mask to APU SKU so just force on all the feature
+* at early initial stage.
+*/
+   return true;
+
+}
+
 static const struct pptable_funcs renoir_ppt_funcs = {
.get_smu_msg_index = renoir_get_smu_msg_index,
.get_smu_clk_index = renoir_get_smu_clk_index,
@@ -933,6 +944,7 @@ static const struct pptable_funcs renoir_ppt_funcs = {
.mode2_reset = smu_v12_0_mode2_reset,
.set_soft_freq_limited_range = smu_v12_0_set_soft_freq_limited_range,
.set_driver_table_location = smu_v12_0_set_driver_table_location,
+   .is_dpm_running = renoir_is_dpm_running,
 };
 
 void renoir_set_ppt_funcs(struct smu_context *smu)
-- 
2.7.4

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