All of lore.kernel.org
 help / color / mirror / Atom feed
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 

  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.