Hi John: Am 01.10.09 20:45 schrieb(en) John Bonesio:
Nowhere in the text does it say 0 and 1 are the only possible values. And since GR is a 3 bit field instead of a 1 bit field, that implied that to me that other values are allowed.I can see how one could read the text as saying 0 and 1 are the only values allowed. However, empirical the testing I've done, seems to indicate that the '7' is a valid value, as it produced different behavior than 1.
Thanks for the clarification!
I've put in the suggested change to set the 'flush' bit. It didn't seem to help. I'm not sure what else might be different between my system and yours.
My board is a self-designed one, roughly Icecube-based, with a 5200B. The peripheral (actually a second processor) is attached in 16-bit mode to the LPB. The main data flow goes to the 5200, so I have only a task for reading data. As the block transfer is only one part (but with a huge block size) in a transaction, I allocate only one block for the task, i.e. I call bcom_gen_bd_rx_init(1, ...).
The transaction size is always a multiple of 4 bytes, and I use the same value for the FIFO packet size and struct bcom_bd::status. In the Control reg, I set CS, BPT=4, DAI, RWb and Flush. I can isolate the code launching Bestcomm if you're interested.
I ran some further tests today, which are a little confusing...When a Bestcomm IRQ arrives, the call to bcom_buffer_done() (in the isr) will always return 0. If I just ignore that, and call bcom_retrieve_buffer() anyway, the status value will also be 0. However, the data block is transferred completely, and it is correct (I separately transmit a crc32, which matches, and the data block itself looks fine). Actually, I'm not really sure what this means...
BTW, I noticed that the Bestcomm IRQ arrives *before* the FIFO IRQ, which IMHO is a little unlogical. It may be a result of setting the granularity to 0 and the FIFO Alarm level to 4 (which should trigger Bestcomm only if one u32 is free in the FIFO - is that correct? At least the drawing on Pg. 11 in Freescale's AN2604 implies that.).
We were testing using the Bestcomm on a framebuffer to refresh the display. Without the watermarks, the DMA was getting clogged.
I see. In my case, only the /overall/ time and cpu load for the transaction are critical, and there I didn't notice significant differences.
Cheers, Albrecht.
pgplZeWfIy57b.pgp
Description: PGP signature
_______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
