Having issues setting up prefetch and resolve engine on i.MX6QP

キャンセル
次の結果を表示 
表示  限定  | 次の代わりに検索 
もしかして: 

Having issues setting up prefetch and resolve engine on i.MX6QP

ソリューションへジャンプ
932件の閲覧回数
tommalnar
Contributor III

We have our own drivers for the IPU and currently we support video using channel 23 on i.MX6Q and i.MXQP.  

We recently tried to add the pre/prg initialization similar to the mxc drivers in Linux.  

After correctly setting up the IPU, pre and prg blocks we end up with garbage being read and shown through the display interface.   It never changes, and no matter what address we point the PRE to, the garbage looks the same.  

We do however notice one bit is not being cleared in the pre engine.  Note we are just trying single buffer mode for now.

In register HW_PRE_CTRL bit 4 SDW_UPDATE we notice after setting it the hardware store engine never seems to clear the bit.  

RM states:

"Indicates that the shadow register should be updated. If have any control register bits are changed,
Software have to set this bit, and then all register bits will be updated to shadow register end of current
frame in store engine. And then it will be cleared automatically by hardware."

Can you point us in the right direction as to what might be happening, that the bit is not being cleared?  We are using IPU 1 so PRE0 and PRG0.   We know the IDMAC and IPU configuration works without using PRE just fine.  The only thing that we had to change for IDMAC setup was the address of the buffer to read.  It needs to point to OCRAM2 address. 

Also note we would like this to run without interrupts.  For single buffer mode we want to setup pre/prg once and simply update data within the buffer.  In double buffer mode we would like to set the next buffer in pre to be taken on v-sync.  But for now single buffer is a start.

Here is a dump of our setup registers:

PRE 0
0x00000000 0x30000915
0x00000010 0x00000000
0x00000020 0x00000000
0x00000030 0x30300000
0x00000040 0x30300000
0x00000050 0x00000000
0x00000060 0x00000000
0x00000070 0x00000400
0x00000080 0x00008829
0x00000090 0x000800A0
0x000000A0 0x01E00280
0x000000B0 0x00000000
0x000000D0 0x00000A00
0x000000E0 0x18100800
0x000000F0 0x00008888
0x00000100 0x00000000
0x00000110 0x00000027
0x00000120 0x40080000
0x00000130 0x01E00280
0x00000140 0x00000A00
0x00000150 0x00940000
0x00000160 0x00000000
0x00000170 0x00000000

PRG 0
0x00 0x82090006
0x04 0x00000003
0x08 0x00000000
0x0C 0x00000000
0x10 0x000009FF
0x14 0x00000000
0x18 0x00000000
0x1C 0x00000000
0x20 0x10000000
0x24 0x00940000
0x28 0x00000000
0x2C 0x00000000
0x30 0x00000000
0x34 0x00000000
0x38 0x00000000
0x3C 0x00000000
0x40 0x00000000
0x44 0x00000000
0x48 0x01DF01DF
0x4C 0x00000000
0x50 0x00000000

We appreciate any help to indicate why that shadow update bit is not getting ingested.  We suspect something wrong in the store or prg setup, but its not clear.  We also supect this is why the engines aren't starting up and reading data and placing it in OCRAM.

Tom

0 件の賞賛
返信
1 解決策
727件の閲覧回数
tommalnar
Contributor III

Turns out it may be related to me incorrectly setting VFLIP.   I was setting it to 1, but it should be 0 for GPU buffers.  I see some of my data now, but I think I have the wrong resolve type selected as its smeared.    

Channel 0 Vertical Flip Enable
0 Enable vertical flip
1 Disable vertical flip

Anyway, I think we can manage from here if you would like to delete the post.

Tom

元の投稿で解決策を見る

0 件の賞賛
返信
1 返信
728件の閲覧回数
tommalnar
Contributor III

Turns out it may be related to me incorrectly setting VFLIP.   I was setting it to 1, but it should be 0 for GPU buffers.  I see some of my data now, but I think I have the wrong resolve type selected as its smeared.    

Channel 0 Vertical Flip Enable
0 Enable vertical flip
1 Disable vertical flip

Anyway, I think we can manage from here if you would like to delete the post.

Tom

0 件の賞賛
返信