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 --]
next prev 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).