ChanServ changed the topic of #etnaviv to: #etnaviv - the home of the reverse-engineered Vivante GPU driver - Logs https://oftc.irclog.whitequark.org/etnaviv
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
T_UNIX has joined #etnaviv
sravn has joined #etnaviv
lynxeye has quit [Quit: Leaving.]
otavio__ has quit [Ping timeout: 480 seconds]
sknebel_ has joined #etnaviv
sknebel has quit [Ping timeout: 480 seconds]
sknebel_ has quit []
sknebel has joined #etnaviv
CoLa[m] has joined #etnaviv