Re: [PATCH] powerpc/5200: add LocalPlus bus FIFO device driver

["Albrecht Dreß" <albrecht.dress@arcor.de>]

[-- Attachment #1: Type: text/plain, Size: 2527 bytes --]

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.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]