From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Kevin Diggs <kevdig@hypersurf.com>
Cc: linuxppc-dev@ozlabs.org
Subject: Re: pmac_zilog debugging ...
Date: Mon, 17 Nov 2008 20:00:22 +1100 [thread overview]
Message-ID: <1226912422.7178.228.camel@pasglop> (raw)
In-Reply-To: <49212D61.3080305@hypersurf.com>
> > 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.
> >
> "... if the DMA list is appropriately provisioned ..." ???
Well, if you have some descriptors to available buffers :-) If you let
that run out too, then the chip will miss
> > 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).
> >
> Any idea how we might find out?
Nope. Trial and error ? :-)
> I reinstalled the disk with 2.4.31 and reran the tests. With "nortscts" added to
> the pppd options macserial still works fine. Even at 115,200 it seemed fine (I
> expected to see some type of packet errors via pppstats or ifconfig). I did not,
> however, verify that pppd actually does something with this option.
>
> I can't get pmac_zilog to work even at 1200 baud. That is pretty slow.
That's definitely strange. I would expect the kernel to be able to get
interrupts fast enough to service a 1200 bauds serial port. Maybe
there's something else wrong, or an other driver causing undue interrupt
latencies....
Out of curiosity, check that IDE properly unmasks interrupts (hdparm
-u1 /dev/hda).
> Ah! I think I get it. I was thinking that cpu intervention would be required after
> each byte. But the descriptors are more like linked commands for the DMA
> hardware.
Yes.
> So, I'm on board with this approach. Since I don't really know what I am
> doing, how do you recommend I proceed?
Google for a document called MacTech.pdf which contains various
documentations for bits of the ancestor of the IO chip in your machine,
along with a description of the DBDMA engine :-) Something else you can
do is to look at how it's properly used by other drivers such as bmac
and look at some of the darwin source code for reference on how the HW
works.
> Would it be correct to say that DMA would also free the cpu from doing io accesses
> which are MUCH slower than normal memory acdcesses?
To a certain extent yes.
Cheers,
Ben.
next prev parent reply other threads:[~2008-11-17 9: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
2008-11-17 8:37 ` Kevin Diggs
2008-11-17 9:00 ` Benjamin Herrenschmidt [this message]
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=1226912422.7178.228.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).