From: Mike Frysinger <vapier@gentoo.org>
To: u-boot@lists.denx.de
Subject: [U-Boot] serial ifdef mess
Date: Tue, 20 Sep 2011 00:44:30 -0400 [thread overview]
Message-ID: <201109200044.31961.vapier@gentoo.org> (raw)
In-Reply-To: <CAPnjgZ0hSsbvAH_5EEDBn5R92mPJCibOi-iWBz=neL8GVVwXFA@mail.gmail.com>
On Tuesday, September 20, 2011 00:28:30 Simon Glass wrote:
> On Mon, Sep 19, 2011 at 6:07 PM, Graeme Russ wrote:
> > a) Use a particular serial driver directly - perfect if you have only one
> > serial port (or don't care about the others)
>
> Do we really want this? Is the code overhead of SERIAL_MULTI so bad
> that people insist on not defining it? If so, can we reduce that code
> overhead? It doesn't seem like it should be large. Perhaps non-MULTI
> could be implemented by macros and inline functions in the header
> file?
MULTI: serial_puts looks up a struct in a linked list to find the device
before calling the func pointer in that struct to the device-specific
serial_puts
!MULTI: serial_puts writes char to hardware register
the latter sounds a lot more robust to me :). it might not be a recommended
or default setting, but i think we should strive to keep that simplicity
around.
> > b) Use the SERIAL_MULTI 'management layer' and 'register' each relavent
> > serial port on the board. The board will need to define a (probably
> > hard-coded) a default to handle I/O until the environment can be read
> > and the hardware initialised to actually make the serial ports
> > operational.
>
> Prior to relocation there is a single console UART. I wonder whether
> it would be acceptable to buffer all output until after relocation?
> Serial init is the one peripheral still needed prior to reloc. At
> least this could be the default option, with something like
> CONFIG_EARLY_UART defined to revert to current behavior for debugging
> reasons.
as a debugging tool, any buffer is not interesting. after that, it might be.
> But to truly deal with your point, I don't think the environment tells
> the serial ports much. They get their registers address and settings
> from other places (normally hard-coded in the driver, perhaps in
> future through an fdt). It should be possible for any serial driver to
> output things before the env is loaded. To implement an early UART we
> simply need the serial layer to pass serial calls straight onto the
> selected driver without going through the mux or anything else that
> needs state. That bit already works...
!MULTI gives us a working early UART now. i know because the Blackfin port
can output info to the serial port at pretty much power on.
> The main bugbear for me is that there is no handle passed to the
> serial functions. All of the serial devices should have an extra
> parameter at the start which is perhaps struct seral_device *, and
> that structure should have a ->priv member, pointing to a
> driver-specific structure which we can
> use to store things like the port number / register address. So in
> other words make it like most other driver layers in U-Boot.
yes, this would be the first thing i'd fix
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20110920/e0ccf1e3/attachment.pgp
next prev parent reply other threads:[~2011-09-20 4:44 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-18 5:17 [U-Boot] [PATCH] punt unused clean/distclean targets Mike Frysinger
2011-09-18 7:26 ` Wolfgang Denk
2011-09-18 8:22 ` Mike Frysinger
2011-09-18 13:08 ` Graeme Russ
2011-09-19 4:59 ` Mike Frysinger
2011-09-19 5:10 ` Marek Vasut
2011-09-19 5:30 ` Mike Frysinger
2011-09-19 6:57 ` Wolfgang Denk
2011-09-19 5:11 ` Graeme Russ
2011-09-19 5:32 ` Mike Frysinger
2011-09-19 6:54 ` Wolfgang Denk
2011-09-19 14:28 ` Mike Frysinger
2011-09-19 18:29 ` Scott Wood
2011-09-19 20:57 ` [U-Boot] serial ifdef mess Mike Frysinger
2011-09-20 0:41 ` Graeme Russ
2011-09-20 0:52 ` Mike Frysinger
2011-09-20 1:07 ` Graeme Russ
2011-09-20 4:28 ` Simon Glass
2011-09-20 4:44 ` Mike Frysinger [this message]
2011-09-20 5:12 ` Graeme Russ
2011-09-20 7:29 ` Wolfgang Denk
2011-09-20 4:40 ` Mike Frysinger
2011-10-13 16:54 ` [U-Boot] [PATCH v2] punt unused clean/distclean targets Mike Frysinger
2011-10-15 20:20 ` Wolfgang Denk
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=201109200044.31961.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.