linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Kevin Diggs <kevdig@hypersurf.com>
Cc: linuxppc-dev@ozlabs.org
Subject: Re: pmac_zilog debugging ...
Date: Fri, 14 Nov 2008 12:00:29 +1100	[thread overview]
Message-ID: <1226624429.7178.105.camel@pasglop> (raw)
In-Reply-To: <491CAA32.20307@hypersurf.com>

On Thu, 2008-11-13 at 14:29 -0800, Kevin Diggs wrote:
> Benjamin Herrenschmidt wrote:
> > On Thu, 2008-11-13 at 03:38 -0800, Kevin Diggs wrote:
> > 
> > 
> >>12,206 PowerMac Zilog interrupts
> >>
> >>Interrupt load is higher without the DMA support.
> >>
> >>Is it possible that this hardware was not meant to be used without the
> >>DMA (i.e. it does not work quite right?)?
> > 
> > 
> > Well, the HW Rx buffer is only 3 bytes so if you have high interrupt
> > latencies you are more likely to loose data...
> > 
> These are not real 8530s any more, right? How certain are we of this?
> Is it possible that there is a larger buffer when used with the DMA
> capability ... somehow?

Well, the main thing is that when using DMA, it doesn't need to wait for
the kernel to come fetch the bytes, and thus the only latency that
matters if the DMA list is appropriately provisioned is the bus latency,
which is much less likely to be an issue even with a small buffer.

It's definitely not a "basic" 8530, it's an ESCC but I don't think the
base rx buffer in polled mode is any bigger (I may be wrong).

> I tried to put some debug statements where the flow lines are managed. I
> could have goofed it up. They never produce any output. The latest
> attempt used nortscts which should have disabled flow control. That
> coupled with the fact that a 250 MHz 750GX is talking to a 486dx4 at
> 1200 - 9600 baud I would have thought would reduce the chance the PowerMac
> would fall behind?

Have you disabled flow control both with the old macserial -and-
pmac_zilog and still experiencing the same problems ? (ie one works and
the other one doesn't ?)

> You would need to explain to me the advantage of doing DMA in this case???

Well, if I setup for example 128 DMA descriptors for 1 byte each, then
the chip will be able to DMA up to 128 bytes without CPU intervention,
thus is a -lot- less likely to overflow it's fifo. It's essentially a
way to have the DMA engine operate as an external FIFO. As the CPU
fetches the bytes, it can recycle the descriptors at the end of the list
effectively acting as some kind of ring buffer.

We can more easily do DMA for Tx but while this can improve performances
and lower interrupt usage, it is not a correctness issue in the sense
that Tx isn't -losing- data today, it's Rx that is a potential problem.

Cheers,
Ben.

  reply	other threads:[~2008-11-14  1:00 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-11-07 21:38 pmac_zilog debugging Kevin Diggs
2008-11-07 22:23 ` Benjamin Herrenschmidt
2008-11-13 11:38   ` Kevin Diggs
2008-11-13 21:44     ` Benjamin Herrenschmidt
2008-11-13 22:29       ` Kevin Diggs
2008-11-14  1:00         ` Benjamin Herrenschmidt [this message]
2008-11-17  8:37           ` Kevin Diggs
2008-11-17  9:00             ` Benjamin Herrenschmidt
2008-11-17 10:21               ` Kevin Diggs
2008-11-17 11:40                 ` Benjamin Herrenschmidt
2008-11-08  5:52 ` Paul Mackerras
2008-11-08 10:46   ` Benjamin Herrenschmidt

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=1226624429.7178.105.camel@pasglop \
    --to=benh@kernel.crashing.org \
    --cc=kevdig@hypersurf.com \
    --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).