From: Shinya Kuribayashi <skuribay@pobox.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] include/ns16550.h: Unify structure declaration for registers
Date: Thu, 30 Apr 2009 03:51:02 +0900 [thread overview]
Message-ID: <49F8A196.60202@pobox.com> (raw)
In-Reply-To: <m2ljpmqfb2.fsf@ohwell.denx.de>
Detlev Zundel wrote:
> As I said, I understand now why there were different data-types involved
> although this was kind of non-obvious. So I take it, you had a working
> configuration with REG_SIZE = 4, correct?
I might be unclear. I used to use REG_SIZE = -16, as 16550 registers
are located at 0, +0x10, +0x20, ..., .
In this case, I don't think REG_SIZE = 4/-4 works. Let's see:
REG_SIZE = 4
------------
struct NS16550 {
unsigned char prepad_rbr[3];
unsigned char rbr;
unsigned char prepad_ier[3];
unsigned char ier;
:
:
};
REG_SIZE = -4
-------------
struct NS16550 {
unsigned char rbr;
unsigned char postpad_rbr[3];
unsigned char ier;
unsigned char postpad_ier[3];
:
:
};
because 16550 registers can be aligned in 16-bytes-interval.
And make things worse, REG_SIZE = 16/-16 also don't work.
REG_SIZE = 16
-------------
struct NS16550 {
unsigned char prepad_rbr[15];
unsigned char rbr;
unsigned char prepad_ier[15];
unsigned char ier;
:
:
};
REG_SIZE = -16
--------------
struct NS16550 {
unsigned char rbr;
unsigned char postpad_rbr[15];
unsigned char ier;
unsigned char postpad_ier[15];
:
:
};
What I need is something like this:
struct NS16550 {
unsigned char prepad_rbr[3];
unsigned char rbr;
unsigned char postpad_rbr[12];
:
:
};
or this also might work,
struct NS16550 {
unsigned long rbr;
unsigned long pre_padrbr[3];
: ^^^^
:
};
Makes sense?
> Can you enlighten me, why exactly the 8-bit accesses do not work on your
> hardware? Is this because of a "too simplistic" address decoding logic?
> What endianness is your CPU using?
I don't know much about precise hardware logics, but the byte addresses
under 16-bytes-border are ignored. I'm using a big-endian mips machine.
> I see. Actually I was looking a lot at the Linux driver but was hoping
> that we could away without introducing serial_{in,out}...
In my horrible opinion, the combinations of base addres + reg_shift
+ iotype (char, long, or whatever), are simpler, more configurable,
more slid, easy to use, than what we used to have or what you
consolidated this time.
> diff --git a/include/ns16550.h b/include/ns16550.h
> index ce606b5..7924396 100644
> --- a/include/ns16550.h
> +++ b/include/ns16550.h
> @@ -21,16 +21,20 @@
> * will not allocate storage for arrays of size 0
> */
>
> +#if !defined(CONFIG_SYS_NS16550_REG_TYPE)
> +#define UART_REG_TYPE unsigned char
> +#endif
> +
> #if !defined(CONFIG_SYS_NS16550_REG_SIZE) || (CONFIG_SYS_NS16550_REG_SIZE == 0)
> #error "Please define NS16550 registers size."
> #elif (CONFIG_SYS_NS16550_REG_SIZE > 0)
> -#define UART_REG(x) \
> - unsigned char prepad_##x[CONFIG_SYS_NS16550_REG_SIZE - 1]; \
> - unsigned char x;
> +#define UART_REG(x) \
> + UART_REG_TYPE prepad_##x[CONFIG_SYS_NS16550_REG_SIZE - sizeof(UART_REG_TYPE)]; \
> + UART_REG_TYPE x;
> #elif (CONFIG_SYS_NS16550_REG_SIZE < 0)
> #define UART_REG(x) \
> - unsigned char x; \
> - unsigned char postpad_##x[-CONFIG_SYS_NS16550_REG_SIZE - 1];
> + UART_REG_TYPE x; \
> + UART_REG_TYPE postpad_##x[-CONFIG_SYS_NS16550_REG_SIZE - sizeof(UART_REG_TYPE)];
> #endif
>
> struct NS16550 {
>
>
> Then you could do a
>
> #define CONFIG_SYS_NS16550_REG_SIZE 4
> #define CONFIG_SYS_NS16550_REG_TYPE unsigned long
>
> This of course needs to be documented once it works ;)
Looks to me like playing with macros...
Shinya
next prev parent reply other threads:[~2009-04-29 18:51 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-04-03 14:45 [U-Boot] [PATCH] include/ns16550.h: Unify structure declaration for registers Detlev Zundel
2009-04-03 14:55 ` Detlev Zundel
2009-04-03 23:24 ` Wolfgang Denk
2009-04-25 1:21 ` Shinya Kuribayashi
2009-04-27 13:41 ` Detlev Zundel
2009-04-27 14:26 ` Shinya Kuribayashi
2009-04-27 15:36 ` Detlev Zundel
2009-04-27 16:09 ` Detlev Zundel
2009-04-29 18:51 ` Shinya Kuribayashi [this message]
2009-04-29 19:12 ` Shinya Kuribayashi
2009-04-30 13:30 ` Detlev Zundel
2009-04-30 14:10 ` Detlev Zundel
2009-05-01 0:56 ` Shinya Kuribayashi
2009-05-01 5:29 ` Shinya Kuribayashi
2009-04-30 12:26 ` Detlev Zundel
2009-04-30 12:52 ` Jerry Van Baren
2009-04-30 14:08 ` Detlev Zundel
2009-04-30 14:38 ` Detlev Zundel
2009-04-30 17:06 ` Jerry Van Baren
2009-05-01 2:21 ` Shinya Kuribayashi
2009-05-01 1:59 ` Shinya Kuribayashi
2009-05-04 15:40 ` Detlev Zundel
2009-05-04 21:21 ` Scott Wood
2009-05-04 21:57 ` Wolfgang Denk
2009-05-05 1:36 ` Shinya Kuribayashi
2009-05-05 9:09 ` Detlev Zundel
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=49F8A196.60202@pobox.com \
--to=skuribay@pobox.com \
--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.