<JIaxyga[m]>
btw konradybcio:, a630 gmu looks completely suitable. Squashed zap_fw didnt cause any problems either
<robclark>
JIaxyga[m]: drop the `revn` for newly added gpus
<konradybcio>
robclark: wdyt about adding the "minimum gmu fw" thing upstream
<JIaxyga[m]>
robclark: Okay, thanks 👍️
<robclark>
and yeah, I'd expect a630 gmu fw
<konradybcio>
so that we can just version the gmu firmwares
<robclark>
hmm
<robclark>
we read out the sqe version.. mainly for security reasons (we want to disallow older version with bug and/or missing feature).. I guess we could do similar for gmu fw if we needed to. But do we need to?
<konradybcio>
we don't, but as i've mentioned, we could potentially reduce the number of GMU binaries
<konradybcio>
just store like gmu_4_1.bin
<robclark>
oh, you mean use a single gmu across subgen's.. when I experimented with that it didn't work. At any rate, it isn't cool for new l-f to break old kernel so we can't exactly get rid of gmu fw's
<konradybcio>
right that could probably only be a thing for new submissions
<konradybcio>
i think versions like 4.1 etc are like branches and then there's hw support added in some subreleases
<konradybcio>
worst of all, the thing will accept anything you give it and if it doesn't support adreno XYZ, it will just not work
<robclark>
I'm not really sure it is a good idea... I don't have a whole lot of trust in qc's fw team to have tested new fw with older gpu's.. and would rather stick to what they've validated with android
<konradybcio>
perhaps there's some LUT for getting init sequences with rpmh etc
<konradybcio>
okay fair, I can give up on this idea..