On Mon, Jul 29, 2024 at 02:40:30PM +0200, Konrad Dybcio wrote: > > > 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.dyb...@linaro.org> > >>>> --- > >> [...] > >> > >>>> > >>>> - 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?
Sorry, "8 bits" was a typo. You are right, 12 bits for Fcode and 4 bits for PCODE. -Akhil > > Konrad