On 28.06.2024 7:31 PM, Elliot Berman wrote: > On Fri, Jun 28, 2024 at 10:24:52AM -0700, Elliot Berman wrote: >> On Tue, Jun 25, 2024 at 08:28:06PM +0200, Konrad Dybcio wrote: >>> On recent (SM8550+) Snapdragon platforms, the GPU speed bin data is >>> abstracted through SMEM, instead of being directly available in a fuse. >>> >>> Add support for SMEM-based speed binning, which includes getting >>> "feature code" and "product code" from said source and parsing them >>> to form something that lets us match OPPs against. >>> >>> Due to the product code being ignored in the context of Adreno on >>> production parts (as of SM8650), hardcode it to SOCINFO_PC_UNKNOWN. >>> >>> Signed-off-by: Konrad Dybcio <konrad.dybcio@xxxxxxxxxx> >>> --- [...] >>> + ret = qcom_smem_get_feature_code(&fcode); >>> + if (!ret) >>> + *fuse = ADRENO_SKU_ID(fcode); >>> + else if (ret != -EOPNOTSUPP) >>> + return dev_err_probe(dev, ret, "Couldn't get feature code from SMEM\n"); >> >> Probably want to update a6xx_set_supported_hw() error handling to ignore >> -EOPNOTSUPP or do: >> >> else /* ret == -EOPNOTSUPP */ >> return -ENOENT; >> >> >> >>> +#endif >>> + >>> + return 0; >> >> I noticed that if SMEM isn't enabled and nvmem returns -ENOENT, we still >> return 0. That could lead to uninitialized access of speedbin in both >> users of adreno_read_speedbin(). Maybe: >> >> return ret; >> > > Ah, I see patch 4 in the series now, but I wonder if we can do something > better so that this patch works without relying on later patch in > series? Looks like rebase mess on my side :/ Rob already picked this up for next.. Guess we could ask really nicely for a forcepush there? Konrad
