On 29.07.2024 2:13 PM, Konrad Dybcio wrote: > 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? Also Akhil, 12 + 8 > 16.. did you mean 8 bits for both P and FCODE? Or 12 for FCODE and 4 for PCODE? Konrad
