[U-Boot] [PATCH 04/11 v1] ARM: OMAP3: Add assembly startup and sys_info common files

[Wolfgang Denk]

Dear Dirk,

In message <48D523E1.8060508 at googlemail.com> you wrote:
> 
> Wolfgang Denk wrote:
> > Dear Dirk Behme,
> 
> Just Dirk ;)

Sorry, my MUA is not that clever (yet). And in  many  cases  I  don't
have  time  enough  to  manually  edit  this.  [If  you have a clever
replcomps setup (i. e. more clever than "Dear  %(friendly  {from}),")
that would be definitely welcome.]

> > Instead, we might probably have just a "cpu/arm_cortexa8/" with common
> > code for "omap3" and "xxx" ?
> 
> Hmm, sorry, I'm not sure I completely understood.
> 
> Do you want to say that you want a directory "cpu/arm_cortexa8/" where 
> the common files for Corex-A8 CPUs are located and then a directory 
> "cpu/arm_cortexa8/omap3" where the OMAP3 common stuff is stored?

Yes.

> If this is correct, from theory I completely agree. *But*: From 
> practical point of view regarding the patch we are talking about here, 
> we just don't know what Corex-A8 CPU common code might be. As I know 
> there is no "xxx" (with xxx != OMAP3) yet, so it's hard to know what 
> will be common. So we moved all OMAP3 common code for all three buards 
> we currently support to omap3 directory.

You are a pessimist. You think everything is OMAP3 specific.

I am an optimist. I think everything is common code. At least that's
the way it should be :-)

So my suggestion is to put all code  into  cpu/arm_cortexa8/,  unless
you   are   not   absolutely   sure   that   some  file  is  strictly
cpu/arm_cortexa8/omap3 only.

If this assessment later turns out to be wrong, it is much easier  to
split  the file into SoC specific parts that to factor out the common
parts from N different SoC implementations.

> So for the time being, I propose to create /cpu/arm_cortexa8/omap3 
> with all files in this directory and no files in /cpu/arm_cortexa8 
> yet. This can change later, files from omap3/ can move to 
> /cpu/arm_cortexa8/ when we get more Cortex-A8 SoCs/chips and get an 
> idea what might be common.

Nope. I disagree. Thjsi way will cause much more maitnenance effort
and result in lots of duplicated code.

> But my question here was if we can do directory moves/renames in git 
> after/while patch is applied or if new patches with directory changes 
> are needed on mailing list? Directory move/rename is easy in git, 
> while doing this with patches to mailing list may result in 
> unnecessary traffic.

It makes no difference. Just make sure to tell git to create  patches
that   contain   renames.   See   options   like  '-M'  and  '-C'  to
git-format-patch.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
We're all sorry for the other guy when he loses his job to a machine.
But when it comes to your job -- that's different. And it always will
be different.
	-- McCoy, "The Ultimate Computer", stardate 4729.4