On 11/09/2011 04:04 AM, Igor Grinberg wrote:
Hi Tom,
On 11/08/11 17:21, Tom Rini wrote:
On 11/08/2011 12:45 AM, Igor Grinberg wrote:
On 11/07/11 22:05, Tom Rini wrote:
A number of boards are populated with a PoP chip for both DDR and NAND memory. So to determine DDR timings the NAND chip needs to be probed and mfr/id returned to the board to make decisions with. All of this code is put into spl_pop_probe.c and controlled via CONFIG_SPL_OMAP3_POP_PROBE.
I don't see how POP is different from other types of packages in terms of DRAM. The same thing can be true also for non-POP packages. What I'm saying here is, I understand the necessity of that code, but why call it POP specific? If it is not POP specific, then please call it some other way (e.g. ...DRAM_NAND_PROBE). Also, hypothetically, some other means can be used for DRAM type identification, so it will be a good thing to split it, but again it is only hypothetically and it is only my thoughts, so you don't have to...
Well, that gets at why I called it spl_pop_probe. If you have a POP package, this is how you would do the probe. I can see in theory wanting to probe NAND as a way to see board rev on a non-POP package, but I'd like to see a real example first.
That's the problem we see in Linux OMAP... some guys don't think forward and submit stuff on a per case basis, then when it comes to a bit different case, they are trying to reuse (which is fine) and end up renaming stuff all around - generating huge diff stat. Why not just do the generic stuff from the start of it? Why wait for a new case? It is pretty simple, just don't name it POP, so it can serve w/o any confusion for more cases.
I'll do the rename for a v3. I just don't see renaming once another use comes up as a problem, we aren't using CVS anymore ;)