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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox