05:33 <travmurav[m]> reg addresses for hardware nodes would usually represent the register address base for the hardware block and hardware blocks usually have a fixed place in the address space :) Reserved memory blocks are in ram and it depends on the user if one can relocate them

05:34 <HdkR> Alright, so still need to find the correct addresses for these that don't overlap

05:35 <HdkR> I guess pull up the ACPI dumps and hope for being capable of parsing them

05:35 <travmurav[m]> HdkR: are you trying to define the gpu stuff for the x13s SoC?

05:35 <HdkR> indeed

05:36 <travmurav[m]> I suppose ACPI DSDT would have some register base addresses

05:36 <travmurav[m]> not sure how easy would it be to match acpi uuid <-> what device is there

05:37 <travmurav[m]> would probably be very cool if qcom has downstream linux somewhere with support for that SoC so you could just see the stuff in the downstream DT and adapt that

05:37 <HdkR> Don't think the compute SoCs have any downstream Linux support

05:38 <travmurav[m]> at least 7c has, possibly for the chromebooks

05:38 <HdkR> Might be the only one then

05:40 <travmurav[m]> also possible that the hw blocks are shared with some mobile platform that you can find the dt for (i.e. 7c gen1 is almost equal to snap 720g afaiu) but I suppose 8cx gen3 (iirc) is much more compute oriented and gpu stuff might be "unique"

05:41 <HdkR> No idea there. I'm just flailing

05:44 <clover[m]> Interesting stuff

05:46 <clover[m]> <travmurav[m]> "not sure how easy would it be to..." <- Is it feasible to try each one?

05:47 <HdkR> My main thing would be extracting ACPI while in Linux, if possible

05:48 <clover[m]> Could you take a acpi dump, desolder the gpu, and take a second acpi dump and deduce from the difference?

05:50 <HdkR> lol

05:51 <travmurav[m]> pretty sure acpi is hardcoded

05:54 <travmurav[m]> HdkR: is there no previous dump of the acpi tables?

05:54 <HdkR> I don't think anyone dumped them publicly

05:54 <HdkR> and I already ripped Windows off the device

16:10 <clover[m]> <HdkR> "and I already ripped Windows off..." <- I have some free time I can try to get them

16:27 <clover[m]> HdkR: not sure if this is right but check it: https://github.com/ironrobin/archiso-x13s/wiki/ACPI-dump

16:30 <clover[m]> * it: https://github.com/ironrobin/archiso-x13s/wiki/ACPI-dump-from-Windows

16:35 <HdkR> clover[m]: Looks like that has the information

16:35 <HdkR> Will see if the numbers align

17:25 <HdkR> GMU base address seems wrong, while its rscc and gmu_pdc base addresses look to match

17:25 <HdkR> But I'm not sure how that is described in the ACPI tables

17:26 <HdkR> GFX_REGS describes the base of gpu, GFX_REGS_CONT is close and /might/ describe gmu?

17:27 <travmurav[m]> I wonder if the SoC is described in one of those "codenamed" downstream DTs i.e. here: https://android.googlesource.com/kernel/msm/+/refs/heads/android-msm-coral-4.14-android12L/arch/arm64/boot/dts/qcom

17:27 <travmurav[m]> at least atoll is 7c gen1 afaiu

17:28 <travmurav[m]> but idk how exactly would you match it

17:29 <qzed> HdkR: IIRC some addresses / register offsets are different between the windows and linux driver

17:29 <qzed> so there's some offset between them

17:29 <qzed> let me try to figure out what I did with ghidra some time back...

17:29 <HdkR> Tricky.

17:37 <qzed> ahh right, so part of it is in ACPI, at least for sc8180: GPU0._CRS has the register addresses and GPU0.RESI has the corresponding names for those

17:40 <HdkR> Yea, that's where I've been trying to correlate

17:41 <qzed> right, GFX_REGS_CONT is definitely the base of GMU, or at least what windows uses as base

17:42 <qzed> from that, sc8180x nodes offset 0xa000 for the "gmu" registers

17:44 <HdkR> looks like there is a gmu_pdc and gmu_pdc_seq

17:45 <HdkR> Which might be mixed in this sc8280xp dt?

17:46 <HdkR> Since I'm guessing GPU_PDC_REGS and GPU_PDC_SEQ_MEM relate to gmu_pdc and gmu_pdc_seq respectively

17:47 <qzed> okay so I checked the register addresses between windows and linux drivers and that GFX_REGS_CONT is definitely "gmu" - 0xa000, i.e. in Linux you have addresses relative to GFX_REGS_CONT + 0xa000

17:47 <qzed> or in yet other words: gmu = GFX_REGS_CONT + 0xa00

17:48 <HdkR> Okay, so that offset matches what is in the DT. Confusing

17:50 <qzed> GPU_PDC_SEQ_MEM is "gmu_pdc", at least on the sc8180... seems a bit weird though as you've mentioned this looks kinda swapped

17:50 <qzed> "gmu_pdc_seq" then should be GPU_PDC_REGS

17:50 <HdkR> weird

17:51 <qzed> I do kinda wonder if they're swapped...

17:51 <qzed> but it seems to work, so I'd guess they're correct

17:52 <qzed> also in the spx dsdt are two different sets of definitions for those registers...

17:53 <qzed> seems like some kind of hardware revision thing

18:06 <HdkR> Hm, still timeout waiting for GMU OOB thing

18:08 <HdkR> Wrong interrupt numbers maybe?

18:09 <qzed> i have no clue :/

18:10 <HdkR> I guess the interrupts are described as GFX_INTERRUPT and GFX_LPAC_INTERRUPT?

18:13 <qzed> I can't really match them up to anything on the SPX

18:14 <HdkR> Tricky

18:15 <qzed> on the sc8180x GFX_INTERRUPT is 332, the GPU interrupt in the DT is 300, so maybe some offsetting again?

18:16 <qzed> but I can't find the interrupts used in the gmu node...

18:19 <robclark> HdkR: re: https://gist.github.com/Sonicadvance1/2278e2f37722b51c65eb2efbc144c784 .. is `adreno_is_a660_family()` updated to include a690? The `Unable to find the gmu_pdc_seq registers` error, a690 shouldn't be going down that path which makes me think something fundamental is missing, like realizing that a690 is in the a660 generation

18:20 <HdkR> robclark: I don't think that run had that. I'm now tinkering with 690 included with a660

18:24 <HdkR> Trying to figure out why gmu is timing out

18:31 <robclark> just looking at a680.. looks like it is pretty identical to a640.. so I guess I'd expect a690 to be pretty identical to a660.. but I guess worth checking downstream kgsl. Unfortunately in newer android kernels the dt stuff seems to have moved out of the kernel tree, but I guess at least the kgsl bits should be there

18:49 <HdkR> Oh okay, so timeout happens when reading gmu mmio region, not interrupts

19:01 <clover[m]> what's the implication

19:03 <HdkR> Not the interrupt number being the issue with gmu oob, mmio region being wrong or off

19:27 <HdkR> No more of this, I feel my brain melting

19:33 <steev> HdkR: did you look through the work bamse already did?

19:34 <HdkR> I was just looking at your nonworking-gpu branch