All of lore.kernel.org
 help / color / mirror / Atom feed
From: Wolfgang Denk <wd@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot-Users] API for serial functions
Date: Mon, 01 Oct 2007 12:37:57 +0200	[thread overview]
Message-ID: <20071001103757.535BC2408A@gemini.denx.de> (raw)
In-Reply-To: Your message of "Mon, 01 Oct 2007 05:41:28 EDT." <200710010541.29574.vapier@gentoo.org>

In message <200710010541.29574.vapier@gentoo.org> you wrote:
>
> > 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 

Maybe. But in reality, you won;t be able to see a differecne in
performance.

But the code will be more complicated and have a higher footprint,
which both is a con.

> then in the serial_setbrg() function (what does "brg" stand for anyways?),

Baud Rate Generator. This origins from the initial implementation on
MPC8xx systems...

> 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 

I like this implementation. It's simple and straightforward, and you
can rely on that the user has seen the caratcer on the line before the
function returns. That's a good thing for initial debugging (board
bring up).

> 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 

Please don't.

> speed and lose a few bytes in code size :)

Reduce code size? To me it seems the changes you described above would
take more code.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
The games have always  strengthened  us.  Death  becomes  a  familiar
pattern. We don't fear it as you do.
	-- Proconsul Marcus Claudius, "Bread and Circuses",
	   stardate 4041.2

  parent reply	other threads:[~2007-10-01 10:37 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
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 [this message]
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=20071001103757.535BC2408A@gemini.denx.de \
    --to=wd@denx.de \
    --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.