From: Mike Frysinger <vapier@gentoo.org>
To: u-boot@lists.denx.de
Subject: [U-Boot-Users] API for serial functions
Date: Mon, 1 Oct 2007 05:41:28 -0400 [thread overview]
Message-ID: <200710010541.29574.vapier@gentoo.org> (raw)
In-Reply-To: <20071001092908.3F1B12475A@gemini.denx.de>
On Monday 01 October 2007, Wolfgang Denk wrote:
> Dear Mike,
>
> in message <200710010415.35958.vapier@gentoo.org> you wrote:
> > is there a document that outlines the exact expected behavior of the
> > serial functions ? specifically, i'm looking to see if the serial_putc()
> > function
>
> There is no such document...
oh well :/
> > is supposed to wait until the character it is given has been fully
> > transmitted over the wire, or if it is simply required to queue the
> > character up into the hardware fifo and then return ...
>
> While it's not a strict requirement, I would expect that you wait
> until the charatcer has been sent. You have toi add some wait anway -
> either at the start or at the end of the function, and from the
> debugging point of view it makes more sense to wait for completion
> before continuing. Performancewise there will be no difference, I
> think.
the optimal performance method would be at the start of serial_putc(), spin
until a byte has opened up in the hardware fifo, and then queue it up and
return ... in the normal path, the leading spin would probably not execute
even once as the hardware can go faster than people can type :)
then in the serial_setbrg() function (what does "brg" stand for anyways?),
spin until both the fifo and the transmit register are empty so that you dont
go changing the baud rate while a character is in the middle of
transmission ...
the current Blackfin serial driver posts a character into the fifo and then
spins until both the fifo and the transmit register is empty ... if there is
no higher level API dictacting the requirement (and my quick tests here seem
to back that up), then i'll just scrub the code and gain a little bit of
speed and lose a few bytes in code size :)
thanks !
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20071001/cf11448a/attachment.pgp
next prev parent reply other threads:[~2007-10-01 9:41 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-10-01 8:15 [U-Boot-Users] API for serial functions Mike Frysinger
2007-10-01 9:29 ` Wolfgang Denk
2007-10-01 9:41 ` Mike Frysinger [this message]
2007-10-01 10:03 ` Stefan Roese
2007-10-01 10:20 ` Mike Frysinger
2007-10-01 10:43 ` Wolfgang Denk
2007-10-01 10:57 ` Mike Frysinger
2007-10-01 10:37 ` Wolfgang Denk
2007-10-01 10:54 ` Mike Frysinger
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=200710010541.29574.vapier@gentoo.org \
--to=vapier@gentoo.org \
--cc=u-boot@lists.denx.de \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.