[U-Boot] [PATCH 08/12] OMAP3 SPL: Add identify_pop_memory function

[Tom Rini <trini@ti.com>]

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 ;)

-- 
Tom