On Wed, Apr 09, 2014 at 11:39:10PM +0200, Wolfgang Denk wrote:
Dear Tom,
In message 20140409182426.GV23803@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.