01:23 <lumag> Marijn[m], regarding the bitfield vs scaler version. I'd prefer if we read & use scaler version from the hardware.

01:24 <lumag> Given the fact that most of the code doesn't really care about qseed3 vs qseed3lite vs qseed4, I'd prefer to have it as simple as qseed2 vs qseed3 in all the caps and sblk and let the dpu_hw_util cope with the rest

08:39 <Marijn[m]> lumag: Sure, it's already confusing

09:16 <Marijn[m]> 1. qseed_type in dpu_caps is unread (remove?)... (full message at <https://matrix.org/_matrix/media/v3/download/matrix.org/JLDrPIWiiylTIMnawBzdbyBv>)

09:17 <Marijn[m]> lumag: is there any dead-code compiler flag disabled for DPU that allows these things to slip in / be there without warning?

09:58 <aka_[m]> <lumag> "So we have 5ff08a for a530_pfp..." <- i found some a530_pfp with version

09:58 <aka_[m]> 5f f1 12

10:00 <aka_[m]> thats from samsung a20s, m11 ship 5f f1 14

10:00 <aka_[m]> wonder what can come with f02s which got official A12

10:02 <aka_[m]> my 8976 stock comes with 5f f0 87

10:03 <aka_[m]> same like my 8953 🤨

10:04 <aka_[m]> firmware updates are lie it seems

10:06 <lumag> aka_[m], firmware for Pixel 2 (freely available from google) has PFP version 5ff11a

10:07 <aka_[m]> so that might be latest

10:07 <aka_[m]> when pixel had latest update?

10:08 <aka_[m]> what about zap shaders?

10:08 <aka_[m]> are these per-device?

10:10 <lumag> This is a part of monthly release. I did not check the history of updates. The latest update was from October 2020, if I get it right

10:12 <aka_[m]> if these are not per-device why qcom cannot just provide it on their site as free download >_>, not like we want code itself

10:12 <lumag> Marijn[m], I'd say, for now call get_scaler_ver during dpu_hw_sspp_init() (Fixes: first DPU commit). Drop the get_scaler_ver callback.

10:14 <Marijn[m]> lumag: ack, that's pretty much the change I made locally; we already compute the subblk_offset so no need to do it again via `get_scaler_ver`

10:14 <lumag> Then drop dpu_caps.qseed_type and replace all sblk types with just qseed3

10:15 <lumag> With the hope of getting get_scaler_ver in fixes and the rest to go in front of catalog rework

10:16 <Marijn[m]> lumag: so you wan to replace all feature-based tests in `_setup_layer_ops` with a read of that register? Or is the version only available since scaler3?

10:16 <lumag> It is available since scaler3. I do not know if there was such a thing for qseed2. Not that we support qseed2 anyway.

10:17 <Marijn[m]> Ack, I wish we could translate 0x2004 and 0x1002 to something sensible too :)

10:18 <lumag> Sensible in which way?

10:18 <Marijn[m]> Macro with a good name

10:19 <Marijn[m]> Looks like newer downstream defines 0x2004 as 3lite, and 0x3000 as 4... 0x1002 is?

10:20 <lumag> aka_[m], I think, that for them it is device- and software- specific. In the end, both QC and device manufacturers care about the product = a set of hw, fw and sw that gets tested together.

10:21 <lumag> So from device manufacturer one should not update fw only. This might cause regressions in the software

10:23 <lumag> Thus fw comes as a part of the full software release.

10:26 <lumag> Anyway. I think, for our devices we should stick either to the firmware in linux-firmware or, at one's own decision, with the latest fw. I myself use files from linux-firmware.

10:27 <lumag> Marijn[m], yes. 0x2004 for 3lite and 0x3000 for 4. sdm660 has qseed3 and the version register is 0x1002.

10:27 <lumag> Could you (or maybe konradybcio) check scaler version on 8998?

10:30 <Marijn[m]> Hmm I do own an 8998 device...

10:30 <aka_[m]> oh fun, 8953/8974 flats mention QSEED2 in it

10:30 <Marijn[m]> lumag: that only works if the firmware was released with a license that allows it to be uploaded to linux-firmware?

10:31 <lumag> Marijn[m], yes

10:31 <lumag> So we have the 'latest redistributable' firmware in linux-firmware.

10:32 <Marijn[m]> That's a note on my list to check for existing firmware on linux-firmware that might be compatible with my device... There are a bunch that are supposed to be generic (i.e. not signed with odm certificates)

10:32 <Marijn[m]> And Sony relicensed some firmware config files to allow us to upload them... Still haven't done that :)

10:33 <lumag> And note, that e.g. Pixel's firmware license doesn't grant you a license to use the firmware on other devices

10:33 <lumag> Marijn[m], wow

10:34 <lumag> As for the signed firmware, I *think*, that usually devboards come unfused, while end-user devices are usually fused to the ODM certificate

10:34 <Marijn[m]> lumag: well temper your expectations; it's only a config for BRCMFMAC but the firmware itself can't be uploaded... And those already on linux-firmware don't seem to work...

10:35 <lumag> Ugh :-(