From: Dirk Behme <dirk.behme@googlemail.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] OMAP3EVM: net_chip uses CS5 not CS6
Date: Fri, 08 May 2009 17:10:56 +0200 [thread overview]
Message-ID: <4A044B80.9050107@googlemail.com> (raw)
In-Reply-To: <m27i0r4w3o.fsf@ohwell.denx.de>
Hi,
Detlev Zundel wrote:
> 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.
I tend to agree with Scott and Detlev, too. At least from practical
point of view
http://www.ti.com/litv/pdf/spruf98b
(attention: ~40MB) ;)
Best regards
Dirk
next prev parent reply other threads:[~2009-05-08 15:10 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
2009-05-08 15:10 ` Dirk Behme [this message]
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=4A044B80.9050107@googlemail.com \
--to=dirk.behme@googlemail.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.