linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: "Albrecht Dreß" <albrecht.dress@arcor.de>
To: John Bonesio <bones@secretlab.ca>
Cc: linuxppc-dev@ozlabs.org
Subject: Re: [PATCH] powerpc/5200: add LocalPlus bus FIFO device driver
Date: Wed, 30 Sep 2009 20:34:15 +0200	[thread overview]
Message-ID: <1254335663.3681.0@antares> (raw)
In-Reply-To: <20090929204248.16225.22818.stgit@riker> (from bones@secretlab.ca on Tue Sep 29 22:43:42 2009)

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

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.

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

  parent reply	other threads:[~2009-09-30 18:40 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-09-29 20:43 [PATCH] powerpc/5200: add LocalPlus bus FIFO device driver John Bonesio
2009-09-30  2:25 ` Grant Likely
2009-09-30 18:34 ` Albrecht Dreß [this message]
2009-10-01 18:45   ` John Bonesio
2009-10-01 19:31     ` Albrecht Dreß

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1254335663.3681.0@antares \
    --to=albrecht.dress@arcor.de \
    --cc=bones@secretlab.ca \
    --cc=linuxppc-dev@ozlabs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).