From: Wolfgang Denk <wd@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] ftsmc020: enhance for features and asm support.
Date: Thu, 31 Mar 2011 10:24:28 +0200 [thread overview]
Message-ID: <20110331082428.1816DEDFFD7@gemini.denx.de> (raw)
In-Reply-To: <AANLkTi=umWPj8zK+AvL6H8EarhbqSxN2G=8itXXZG6cS@mail.gmail.com>
Dear Macpaul Lin,
In message <AANLkTi=umWPj8zK+AvL6H8EarhbqSxN2G=8itXXZG6cS@mail.gmail.com> you wrote:
>
> There are lots of register offset is widely been used both in
> lowlevel_init and C environment.
Yes, there is a lot os mess that piled up over the years. It will
take time to clean this up.
> If there is a code wrote as writel(0x1, AT91_ASM_SMC_SETUP0);
> originally must be rewrote as
> writel(0x1, AT91_SMC_BASE + AT91_ASM_SMC_SETUP0);
No, this should be rewritten to acces a C struct instead.
These offesets must ONLY be used in assembler files, but NOT in any C
code.
> I meant, should we make a script that could auto generate asm-offset
> like a translation from
> struct ftsmc020 {
> unsigned bank0_cr;
> unsigned bank0_tpr;
> ...
> }
> into
> #define FTSMC020_BANK0_CR 0x00;
> or
> #define FTSMC020_BANK0_TPR (4);
No. It makes no sense to provide offset fefinitions for allexisting
struct entries. Onle those are needed that are actually being used in
assembler code, and this should be only a handful.
If you find yourself using more of them, you should stop and ask
yourself why you are not writing this code in C.
> without manually reworte the structure in the way as
> OFFSET(FTSMC020_BANK0_CR, ftsmc020, bank0_cr);
> and create a new specific header file for make-asm-offset?
I repeat again: I consider this manual unrolling of the nested structs
a Bad Thing. You should have separate offsets for each of the nested
structs.
> You are right, the comments of FTSMC020_BANK0_TPR (4) is really bad
> for human reading.
Actually not. They explain exactly what's going on there.
> However, when people implementing lowlevel_init or other assembly
> files, they still need such kind of reference
> to write *.S files before the asm-offset has been generated by make.
First of all, people should stop writing assembly code when they
could use C instead. The remaining (small!) parts of aseembler code
will need only a small number of offset definitions. These should be
easy to handle.
Again: if you need larger numbers of such entries you are doing
something fundamentally wrong. Reconsider your coding style. What
exactly enforces you to use assembly?
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
Real computer scientists don't comment their code. The identifiers
are so long they can't afford the disk space.
next prev parent reply other threads:[~2011-03-31 8:24 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-25 8:33 [U-Boot] [PATCH] ftsmc020: enhance for features and asm support macpaul at andestech.com
2011-03-25 9:03 ` Wolfgang Denk
2011-03-31 2:38 ` Macpaul Lin
2011-03-31 6:48 ` Wolfgang Denk
2011-03-31 8:12 ` Macpaul Lin
2011-03-31 8:24 ` Wolfgang Denk [this message]
[not found] ` <AANLkTinYJhoGrA7ZAVUQxwByrkWNqomCBFWiJG_+3+0e@mail.gmail.com>
2011-03-31 9:02 ` Wolfgang Denk
2011-04-01 7:58 ` Macpaul Lin
-- strict thread matches above, loose matches on Subject: below --
2011-03-24 11:25 Macpaul Lin
2011-03-24 13:21 ` 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=20110331082428.1816DEDFFD7@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox