On Fri, Apr 3, 2020 at 5:02 PM Russell, Kent <Kent.Russell@xxxxxxx> wrote: > > [AMD Official Use Only - Internal Distribution Only] > > > -----Original Message----- > > From: Alex Deucher <alexdeucher@xxxxxxxxx> > > Sent: Friday, April 3, 2020 4:51 PM > > To: Russell, Kent <Kent.Russell@xxxxxxx> > > Cc: amd-gfx list <amd-gfx@xxxxxxxxxxxxxxxxxxxxx> > > Subject: Re: [PATCH] drm/amdgpu: Re-enable FRU check for most models v3 > > > > On Fri, Apr 3, 2020 at 1:09 PM Kent Russell <kent.russell@xxxxxxx> 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 <kent.russell@xxxxxxx> > > > --- > > > .../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@xxxxxxxxxxxxxxxxxxxxx > > > > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.fr > > eedesktop.org%2Fmailman%2Flistinfo%2Famd- > > gfx&data=02%7C01%7Ckent.russell%40amd.com%7Cd1d72c89825549c6f > > 06e08d7d810c83e%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C6 > > 37215438899199940&sdata=BnHE%2BT8D0j%2BHKD7s9J%2BXePsSYcXLG > > bEYkmawDv3GNbw%3D&reserved=0 _______________________________________________ amd-gfx mailing list amd-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/amd-gfx