From: Detlev Zundel <dzu@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] OMAP3EVM: net_chip uses CS5 not CS6
Date: Fri, 08 May 2009 14:28:43 +0200 [thread overview]
Message-ID: <m27i0r4w3o.fsf@ohwell.denx.de> (raw)
In-Reply-To: <4A034E49.8040704@freescale.com> (Scott Wood's message of "Thu, 07 May 2009 16:10:33 -0500")
Hi,
> Wolfgang Denk wrote:
>> Dear Scott Wood,
>>
>> In message <4A034B09.7030105@freescale.com> you wrote:
>>>> Or what replaced the "immr" structs?
>>> The device tree, mainly...
>>
>> Right, of course.
>>
>>> ... But #defines can work for u-boot.
>>
>> Of course they _can_ work. But they can easily fail (as we just see
>> in this patch), and we don't have typechecking. So until DT's are
>> omnipresent, let's use structs in U-Boot, please.
>
> You *do* have typechecking as long as the individual blocks are
> described with structs.
>
> We could take immap to extremes by defining one big 4GiB struct that
> shows where memory, immr, flash, desired PCI bars, FPGAs, etc. are --
> but that would be silly. IMHO, so is doing it at the immr level. :-)
>
> How would you deal with blocks being at different locations in different
> chips? It's a lot easier to ifdef (or have the config file specify) a
> couple addresses than to ifdef the locations of fields in a struct,
> especially when you have more than a couple variations.
For what its worth, I'm with Scott here. Structures for register blocks
is very nice and should be mandated and it seems they are maintainable.
Locations of individual blocks (or number of incarnations thereof) seem
to change frequently and thus tend to be less friendly to "whole
internal address space" structures. So the latter may better be mapped
by single defines. The correctness of them is easily validated and an
incorrect value will immediatley be discovered.
Cheers
Detlev
--
config LGUEST
If unsure, say N. If curious, say M. If masochistic, say Y.
-- linux/drivers/lguest/Kconfig
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu at denx.de
next prev parent reply other threads:[~2009-05-08 12:28 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
2009-05-07 21:04 ` Wolfgang Denk
2009-05-07 21:10 ` Scott Wood
2009-05-08 12:28 ` Detlev Zundel [this message]
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=m27i0r4w3o.fsf@ohwell.denx.de \
--to=dzu@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