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

[Albrecht Dreß]

Hi John:

Cool stuff - Grant's original one also helped me a lot to get Bestcomm  
running for me (I use it only for read dma)!

Am 29.09.09 22:43 schrieb(en) John Bonesio:
[snip]
> +		 * It may be worth experimenting with the ALARM value  
> to see if
> +		 * there is a performance impacit.  However, if it is  
> wrong there
> +		 * is a risk of DMA not transferring the last chunk of  
> data
> +		 */
> +		if (write) {
> +			out_be32(lpbfifo.regs + LPBFIFO_REG_FIFO_ALARM,  
> 0x1e4);
> +			out_8(lpbfifo.regs + LPBFIFO_REG_FIFO_CONTROL,  
> 7);
> +			lpbfifo.bcom_cur_task = lpbfifo.bcom_tx_task;
> +		} else {
> +			out_be32(lpbfifo.regs + LPBFIFO_REG_FIFO_ALARM,  
> 0x1ff);
> +			out_8(lpbfifo.regs + LPBFIFO_REG_FIFO_CONTROL,  
> 0);
> +			lpbfifo.bcom_cur_task = lpbfifo.bcom_rx_task;

Hmmm, the MPC5200B User's manual, sect. 9.7.3.3 LPC Rx/Tx FIFO Control  
Register (pg. 323) seems to imply that only 0 or 1 are valid settings  
here.  Where does the 7 come from?

[snip]
> +			 * In the DMA read case, the DMA doesn't  
> complete,
> +			 * possibly due to incorrect watermarks in the  
> ALARM
> +			 * and CONTROL regs. For now instead of trying  
> to
> +			 * determine the right watermarks that will  
> make this
> +			 * work, just increase the number of bytes the  
> FIFO is
> +			 * expecting.

My experience is that for reads I have to set a granularity of 0 (as  
you already do) *and* set the 'flush' bit in the SCLPC Control  
Register.  See the remarks for that bit in the MPC5200B User's manual,  
pg. 318.  With these settings and my driver, I made several tests  
reading blocks (in one Bestcomm operation) between 16 bytes and 2  
MBytes, and *never* had any problem, so your remark here makes me  
somewhat nervous!

In my dma read tests, the watermark (LPC Rx/Tx FIFO Alarm Register)  
seems to have only a (small) performance impact.  If I set the  
watermark to 0 (i.e. fill the fifo completely), I *never* saw any  
under- or overruns.  My assumption is that the fifo would stop reading  
the peripheral when it is full, and only resume when Bestcomm emptied  
it at least partly.  You you know if that is really the case?

[snip]
> +
> +	bit_fields = req->cs << 24 | 0x000008;
> +	if (!write)
> +		bit_fields |= 0x010000; /* read mode */

See above - should be "bit_fields |= 0x030000" IMHO...

[snip]
> +	/* Request the Bestcomm receive (fifo --> memory) task and IRQ  
> */
> +	lpbfifo.bcom_rx_task =
> +		bcom_gen_bd_rx_init(2, res.start +  
> LPBFIFO_REG_FIFO_DATA,
> +				    BCOM_INITIATOR_SCLPC,  
> BCOM_IPR_SCLPC,
> +				    16*1024*1024);

Is the limit really correct?  The manual (sect. 9.7.2.1 SCLPC Packet  
Size Register, pg. 316) says the maximum packet size is 16 M - 1 byte.

Cheers,
Albrecht.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/linuxppc-dev/attachments/20090930/b8abc9be/attachment.pgp>