[Freedreno] Freedreno on i.MX53

[Martin Fuzzey]

On 25/06/15 18:56, Rob Clark wrote:

Thanks for the pointers.

I have made a little progress, not out of the woods yet though.

I finally went back to the kgsl kernel driver for the moment to be able 
to compare with the blob generated command streams.
This is not the same as the msm-kgsl one, there is no GEM and some of 
the ioctls are a little different.

I instrumented the kernel side to dump the command stream, vertex 
buffers and GMEM.

And then started with something even simpler - just a clear of a single 
tile, even removing gmem2mem (and just looking directly at gmem)

Nothing was being drawn at all...

Finally comparing the command streams showed that

1) In CP_DRAW_INDX,  NUM_INDICES needs to be stored in the upper half of 
the second parameter rather being as a parameter by itself
2) REG_A2XX_CLEAR_COLOR doesn't work, CP_SET_CONSTANT(0x00000480) needs 
to be used instead (with the colour components as 4 floats)

Changing that was enough to get the GMEM filled by a clear but the 
gmem2mem draw still hung.

Adding this to the initialisation (taken from the blob command stream):
t0              write RB_BC_CONTROL
                         RB_BC_CONTROL: { ACCUM_TIMEOUT_SELECT = 3 | 
DISABLE_LZ_NULL_ZCMD_DROP | AZ_THROTTLE_COUNT = 0 | ENABLE_CRC_UPDATE | 
ACCUM_ALLOC_MASK = 0 | ACCUM_DATA_FIFO_LIMIT = 8 | 
MEM_EXPORT_TIMEOUT_SELECT = 3 }
00000000:               00000f01 1c004046


Fixed that (the important part seems to be ACCUM_DATA_FIFO_LIMIT = 8)

With that a full clear of all 6 tiles worked.

However clear + draw triangle does not work. It hangs on the DRAW_INDX 
for the first gmem2mem.

Doing write scratch, wait idle, write scratch after the hanging 
DRAW_INDX shows that it is indeed the DRAW_INDX hanging (the final 
register value is the one written before the WFI)

Strange thing is that dumping the render buffer (destination for 
gmem2mem) after the hang shows that gmem2mem has worked - the buffer 
contains a single tile of background and triangle as expected.

The RBBM_STATUS register in the hang case is 0x91410310, versus 
0x00000110 when all is well.
This translates to the following busy bits being set
     GUI_ACTIVE = 1
     SQ_CNTX0_BUSY = 1
     SC_CNTX_BUSY = 1
     TPC_BUSY = 1
     CP_NRT_BUSY = 1
     CFRQ_PENDING = 1

I tried comparing the registers for the gmem2mem draw in the clear only 
and clear + triangle cases, there were a couple of differences but 
setting those registers to be the same makes no difference. I fail to 
see why a gmem2mem draw that works when preceeded by just a clear hangs 
when preceeded by clear + draw, given that the registers are the same...

Comparing with the command stream from the blob driver is complicated by 
the blob driver using the hardware binning commands.


Regards,

Martin