From: Scott Wood <scottwood@freescale.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] OMAP3EVM: net_chip uses CS5 not CS6
Date: Thu, 07 May 2009 15:56:41 -0500 [thread overview]
Message-ID: <4A034B09.7030105@freescale.com> (raw)
In-Reply-To: <20090507204225.70EAE832C2FB@gemini.denx.de>
Wolfgang Denk wrote:
> Dear Scott,
>
> In message <4A0333FC.6090900@freescale.com> you wrote:
>> Wolfgang Denk wrote:
>>> Finally, and this is what I really compalin about, is that there is no
>>> big structure which includes all the blocks that make up the CPU into
>>> one big structure (as it's done for example for PowerPC systems in the
>>> include/asm-ppc/*immap* files) - you still use code like
>> Those immap structs are a huge pain to maintain (or to verify the
>> correctness of), loaded with ifdeffery and magic numbers describing
>> reserved spans. We should not be emulating them.
>
> Well, #define'ing long lists of register offsets is not easier to
> maintain or verify,
IMHO it is; you can just compare to the manual rather than have offsets
be screwed up if something is missing, out of order, or the wrong size.
That's countered by the typechecking and ease of use of structs, though.
> and you don't have any typechecking by the
> compiler.
It doesn't have to be all one or the other. Use structs to describe
individual blocks (provided they're not too sparsely populated), but
define block addresses rather than huge structs consisting of sub-blocks
and empty space. And let the details be flexible at the
author/maintainer's discretion, rather than a rigid rule.
>> We used to have them in Linux, and got rid of them.
>
> Hm... Seems I have missed this change... What's things like
>
> struct qe_immap __iomem *qe_immr
> or
> cpm2_map_t __iomem *cpm2_immr
> or
> immap_t __iomem *mpc8xx_immr
>
> then?
Legacy stuff that hasn't been fully cleaned up. There used to be immap
structs for 83xx and 85xx back in arch/ppc IIRC.
> Or what replaced the "immr" structs?
The device tree, mainly. But #defines can work for u-boot.
-Scott
next prev parent reply other threads:[~2009-05-07 20:56 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-05-06 13:00 [U-Boot] [PATCH] OMAP3EVM: net_chip uses CS5 not CS6 Matthias Ludwig
2009-05-06 14:55 ` Dirk Behme
2009-05-07 7:04 ` Pillai, Manikandan
2009-05-07 7:11 ` Matthias Ludwig
2009-05-07 7:15 ` Pillai, Manikandan
2009-05-07 8:36 ` Wolfgang Denk
2009-05-07 15:16 ` Dirk Behme
2009-05-07 18:58 ` Wolfgang Denk
2009-05-07 19:18 ` Scott Wood
2009-05-07 20:42 ` Wolfgang Denk
2009-05-07 20:56 ` Scott Wood [this message]
2009-05-07 21:04 ` Wolfgang Denk
2009-05-07 21:10 ` Scott Wood
2009-05-08 12:28 ` Detlev Zundel
2009-05-08 15:10 ` Dirk Behme
2009-05-08 8:42 ` Matthias Ludwig
2009-05-08 9:00 ` Wolfgang Denk
2009-05-08 15:12 ` Dirk Behme
2009-05-07 20:57 ` Jean-Christophe PLAGNIOL-VILLARD
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=4A034B09.7030105@freescale.com \
--to=scottwood@freescale.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