09:54 <MoeIcenowy> I am trying to utilize GC620 2D core on TH1520 SoC with etnaviv, what should I take care?

09:55 <MoeIcenowy> ( now modded the DT to let etnaviv probe the device

09:55 <MoeIcenowy> and compiled xf86-video-armada

09:56 <MoeIcenowy> then when I got X running, some error appears: timed out waiting for idle: idle=0x7ffffffe

09:58 <MoeIcenowy> ( 0x1 seems to be FE, which looks like some DMA?

10:00 <lynxeye> MoeIcenowy: I don't think anyone tried etnaviv on GC620 yet. The FE is the DMA frontend, but that one will also stall eventually when other parts of the GPU are hanging.

10:01 <lynxeye> MoeIcenowy: Can you try to run the etnaviv 2d test from libdrm as a sanity check, before moving to the more complex xf86-video-armada?

10:39 <MoeIcenowy> sounds reasonable

10:39 <MoeIcenowy> will try'

10:40 <MoeIcenowy> Offset 0: expected: 0xff40ff40, got: 0x00000000

10:40 <MoeIcenowy> oops

10:40 <MoeIcenowy> and also got FE timeout

10:49 <lynxeye> MoeIcenowy: If even this simple test doesn't work, then either the programming model for the new 2D GPU changed completely, which I think is quite unlikely. Or the kernel driver isn't properly initializing the GPU. Can you try to extract the feature bits from the downstream driver and add a matching entry to the etnaviv hwdb?

10:52 <MoeIcenowy> lynxeye: I got https://github.com/revyos/thead-kernel/blob/lpi4a/drivers/gpu-viv/hal/kernel/inc/gc_feature_database.h#L809, something weird to read...

10:54 <MoeIcenowy> BTW the galcore seems to declare some hack when reseting GPU, maybe I need to try to port it to etnaviv

10:54 <MoeIcenowy> https://github.com/revyos/thead-kernel/blob/lpi4a/drivers/gpu-viv/hal/kernel/arch/gc_hal_kernel_hardware.c#L12284

10:55 <lynxeye> MoeIcenowy: This might help to get it into the format expected by etnaviv: https://github.com/gizmo98/hwdb-converter/

10:55 <MoeIcenowy> maybe I need to apply the HWDB item in the galcore driver

10:56 <MoeIcenowy> btw to add a new model to common.xml.h, should I add it to rnn db in etna_viv repo first?

11:01 <austriancoder> MoeIcenowy: yes please

11:03 <MoeIcenowy> BTW is the hwdb kind of override for the hardware-provided values?

11:04 <austriancoder> MoeIcenowy: yes .. the theory is that they messed up the feature bits provided by the hw and went to a hwdb approach

11:13 <lynxeye> My theory is that they got fed up with the cycle of adding feature bits for "we implemented the feature", then finding some issues with the feature and then needing to add another feature bit for "feature now actually works as advertised". Much easier to disable a feature when you find it broken by editing information in the hwdb. Once they started using the hwdb in the driver, they stopped updating the feature registers in HW, so

11:13 <lynxeye> ores have mostly bogus information in those registers.

11:17 <austriancoder> lynxeye: as you are reachable now .. have you looked at tomeu's kernel patch?

11:19 <MoeIcenowy> okay I now have hwdb item injected, and debugfs file says the new values, but it still does not work

11:20 <lynxeye> austriancoder: Yes, looks good to me. I'll pick it up this week. However, this is clearly not a bugfix, so I don't see it going into the 6.7 release.

11:21 <austriancoder> lynxeye: fine for me .. at least we have some feedback from you