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.. Konrad
