02:40 <qzed> uhmm silly question: is there any way to verify the actual gpu/hardware id via some registers?

02:41 <qzed> I'm not sure what I did wrong the first time I tried... but I don't hang on the GMU any more if I use what I believe should be the a680 firmware and a640 hwcfg

02:47 <bamse> qzed: i was under the impression that it will tell you during initialization (in particular if you don't have support for the given version in the driver)

02:48 <qzed> I thought it got that from the dt compatible string?

02:49 <bamse> hmm, perhaps i'm confusing it with the mdp, where you do have it in a register...

02:51 <qzed> there's at least https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/msm/adreno/adreno_device.c#L447, but there might be something else

02:57 <bamse> i believe you're right...i don't find anything else either

02:57 <bamse> but if it can load the a680 zap and the a640 gmu/sqe, then it quacks like a a680 in my ears...

02:58 <bamse> unfortunatley the documentation is quite unclear wrt these details...

03:31 <qzed> I wonder if "Microsoft SQ2 Adreno 690" != "Qualcomm Adreno 690"...

03:51 <qzed> okay wtf... I have two identical sections in the gpulist, one with id 690 and one with 680

03:52 <qzed> both pointing to the same firmware and hwcg of the a680

03:52 <qzed> I use the same adreno_is_a640_family check for both

03:53 <qzed> but still the a690 entry won't work while the a680 does

03:53 <qzed> can the firmware read what the kernel thinks the chip is?

04:16 <qzed> actually... yes, sort of... turns out the chip id is written to GMU_HFI_SFR_ADDR

04:16 <qzed> if you write 690.1 to that, things don't work

04:16 <qzed> if you write 680.1 to that, things do work

04:16 <qzed> so I guess that confirms things

04:21 <qzed> but then why is it named named 690 on every spec page that I can find and even in the device manager? urgh... marketing people...

04:53 <HdkR> Overclocking is magic

13:31 <robclark> bamse, qzed, could you dump the regs at dword offsets 0, 1, 2 for the 680 and "690" things? I think at least the first two contain some sort of hw revision/config id although haven't figured out the format.. somewhere around here I have some notes with those values collected from a few different a6xx, I guess if I get enough examples I might be able to figure it out

13:32 <robclark> if 680 and "690" match then it is a pretty good bet the latter is just a speed-bump

13:34 <robclark> (then the question is where is the speed-bin efuse)

15:00 <qzed> robclark: you mean gmu->mmio + offset?

15:01 <robclark> no, gpu

15:01 <robclark> (offset in dwords, ie. u32)

15:15 <qzed> okay, so right at the start of a6xx_gpu.c:hw_init() (after the call to a6xx_gmu_set_oob()) via gpu_read():

15:16 <qzed> 0: 00010043

15:16 <qzed> 1: 0ab00000

15:16 <qzed> 2: 044b48a4

15:16 <qzed> 3 .. 15: deafbead

15:17 <qzed> robclark: let me know if you need anything else

15:18 <robclark> thx.. the values should be constant so any time you can read 'em that doesn't insta-reboot is fine

21:31 <qzed> okay, so as far as I can tell everything should work now... but the panel still stays black

21:32 <qzed> there's a framebuffer device allocated by fbcon and that seems to check out (at least resolution wise)

21:32 <qzed> any ideas what could be going wrong?

23:29 <qzed> bamse: what's supposed to happen if I blacklist `msm`? should the basic framebuffer still be in use until the GPU driver loads? if so that's not what's happening...

23:58 <robclark> qzed: you should be able to use modparam msm.modeset=0 to prevent the driver from probing and leave you with efifb (at least until clks / pds get disabled unless you have clk_ignore_unused/pd_ignore_unused)