On 16.07.2024 1:56 PM, Konrad Dybcio wrote: > On 15.07.2024 10:04 PM, Akhil P Oommen wrote: >> On Tue, Jul 09, 2024 at 12:45:29PM +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> >>> --- > > [...] > >>> >>> - if (adreno_read_speedbin(dev, &speedbin) || !speedbin) >>> + if (adreno_read_speedbin(adreno_gpu, dev, &speedbin) || !speedbin) >>> speedbin = 0xffff; >>> - adreno_gpu->speedbin = (uint16_t) (0xffff & speedbin); >>> + adreno_gpu->speedbin = speedbin; >> >> There are some chipsets which uses both Speedbin and Socinfo data for >> SKU detection [1]. > > 0_0 > > >> We don't need to worry about that logic for now. But >> I am worried about mixing Speedbin and SKU_ID in the UABI with this patch. >> It will be difficult when we have to expose both to userspace. >> >> I think we can use a separate bitfield to expose FCODE/PCODE. Currently, >> the lower 32 bit is reserved for chipid and 33-48 is reserved for speedbin, >> so I think we can use the rest of the 16 bits for SKU_ID. And within that >> 16bits, 12 bits should be sufficient for FCODE and the rest 8 bits >> reserved for future PCODE. > > Right, sounds reasonable. Hopefully nothing overflows.. +CC Elliot Would you know whether these sizes ^ are going to be sufficient for the foreseeable future? Konrad
