[U-Boot] [RFC][PATCH] fdt: Remove fdt_fixup_memory function

[Tom Rini]

On Wed, Apr 09, 2014 at 11:39:10PM +0200, Wolfgang Denk wrote:
> Dear Tom,
> 
> In message <20140409182426.GV23803 at bill-the-cat> you wrote:
> > 
> > > I understand what you mean and what you want, but I'm not really
> > > happy about it.
> > 
> > Code or comment wise?
> 
> Both...

OK, concept wise?

> > Right, so we have a mismatch between function name
> > (fdt_fixup_memory_bank) and function of the node
> > (Documentation/devicetree/booting-without-of.txt in the kernel is,
> > sadly, the best description I can find of the memory node bindings).  We
> > itterate over the number of "banks" passed in (1 on PowerPC,
> > CONFIG_NR_DRAM_BANKS on ARM, which is between 1 and 4) and do, as the
> 
> If I u nderstand correctly, CONFIG_NR_DRAM_BANKS gives only the
> maximum possible number of banks.  On the actual system less banks may
> be present.

If I recall correctly, when we have less populated banks than
CONFIG_NR_DRAM_BANKS we set size to 0, but I'll have to double check the
omap3 sdrc and emif code.

> > binding expects, set the reg property correctly (base, size) for each
> > "bank".  It would be more correct to call this "ranges" rather than
> > "banks", or perhaps "nr_ranges".
> 
> Yes, ture.  But then, AFAICT ARM has never made such clear definition
> of terms, and for the tyical ARM memory controllers "range" and "bank"
> are actually synonyms, so this never bothered anybody.

Well, the binding means "range" not "bank".  The usage of
CONFIG_NR_DRAM_BANKS within U-Boot is used to check for actual banks.
I'm not aware off-hand, but it's not impossible that we have
discontiguous DRAM chunks.  I know on omap3 we make sure to map them
contiguously.

The high level point here is to get things to the point of having a
single call we use for setting the /memory node for the kernel so that
we can then easily enough change things so that this depends on
CONFIG_something_or_another so that cases where we know we don't want to
modify the /memory node (it contains more memory than we can probe or
discontiguous ranges that again, we can't probe), we don't.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20140409/1057f3c5/attachment.pgp>