DavidHeidelberg has quit [Remote host closed the connection]
pcercuei has quit [Quit: dodo]
jwillikers[m] has quit [Ping timeout: 480 seconds]
T_UNIX has quit [Ping timeout: 480 seconds]
cmeissl[m] has quit [Ping timeout: 480 seconds]
CoLa[m] has quit [Ping timeout: 480 seconds]
DPA has quit [Read error: Connection reset by peer]
DPA2 has joined #etnaviv
DPA2 has quit []
DavidHeidelberg has joined #etnaviv
DPA has joined #etnaviv
JohnnyonFlame has quit [Read error: Connection reset by peer]
cmeissl[m] has joined #etnaviv
<MoeIcenowy>
oh by grepping in the galcode code of thead, I found 0x00800 register seems to be related to "AHBDEC400" (in comment) or DEC400EX_COMPRESSION (in feature flag)
<MoeIcenowy>
0x800 and 0x808 are written with some values if the GPU supports DEC400EX_COMPRESSION
<MoeIcenowy>
oops DEC400EX_COMPRESSION, corresponding to BSP feature db item G2D_DEC400EX, is in minor features 12
<MoeIcenowy>
by write these values to 0x800 and 0x808, the MMU of GC620 starts to work properly
<MoeIcenowy>
(in secure mode)
<MoeIcenowy>
but the MMU fault when etnaviv_2d_test is run for the second time still exist
<MoeIcenowy>
oops G2D_DEC400EX is just not documented by rnndb yet
<MoeIcenowy>
the position in minor features 12 is given by hwdb-converter
lynxeye has joined #etnaviv
<MoeIcenowy>
lynxeye: fyi I got the way to let the MMU of GC620 work, see irc log; but it now behaves improperly at the second run, the context flush part is to be investigated
pcercuei has joined #etnaviv
<MoeIcenowy>
oops I doubt the handle of MMU contexts are broken in 5.10.113
mvlad has quit [Remote host closed the connection]
jwillikers[m] has joined #etnaviv
<MoeIcenowy>
strange, nothing seems to be able to fault recovery gc620 ...
<MoeIcenowy>
neither the old soft reset bit nor the ahb control reset bit
<MoeIcenowy>
after a reset the MMU is still on ... strange
<MoeIcenowy>
well the FE seems to be able to idle, but the MMU cannot be disabled via soft reset
<MoeIcenowy>
weird...
dri-logger has quit [Ping timeout: 480 seconds]
<MoeIcenowy>
okay writing 0x10 to 0x800 is for it to properly reset MMU
dri-logger has joined #etnaviv
<MoeIcenowy>
oooooops
<MoeIcenowy>
on GC620 only PTA ID 0 is okay
<MoeIcenowy>
other PTA ID seems to be not working
<MoeIcenowy>
:-(
<MoeIcenowy>
maybe we should just kill the idea of having pta id ...
<MoeIcenowy>
because the downstream kernel uses only 0 too, at least in the source of th1520
JohnnyonFlame has joined #etnaviv
<MoeIcenowy>
okay the vivante kernel utilizes only index 0 too
<MoeIcenowy>
s/vivante/imx/
<MoeIcenowy>
the stm32 kernel really utilizes pta id
<MoeIcenowy>
it has a function to write arbitary pta id to 0x001AC
<MoeIcenowy>
maybe we need a method to tag "there's a broken PTA" ...
<MoeIcenowy>
btw I checked the sources referred in hwdb-converter, there's none that declares a G2D_DEC400EX feature bit set
<MoeIcenowy>
(I mean it's set as 1
<MoeIcenowy>
seems that TH1520's GC620 is its first wild show
<MoeIcenowy>
switch back to the topic of PTA, only STM32MP uses a non-zero PTA ID in all sources reffered in hwdb-converter
<MoeIcenowy>
most source codes have some code to setup 0x001AC, but only STM32MP driver contains code to set it to non-zero