[U-Boot] ATMEL Custodians == /dev/null ??

[Reinhard Meyer]

Mike Frysinger wrote:
> On Friday, August 06, 2010 20:01:45 Reinhard Meyer wrote:
>   
>> Mike Frysinger wrote:
>>     
>>>> If, after considering my comments above, you still think you really need
>>>> a custodian for AT91, I am game for it.
>>>>         
>>> go for it
>>>       
>> considering that both AVR32 and AT91 share most of the peripheral hardware
>> building blocks, and therefore share the drivers, it seems to make sense to
>> have an atmel custodian tree instead of avr32 and at91. Each change to a
>> shared
>> driver must (at least with MAKEALL) be checked for both architectures and
>> adding it to both trees would make life unnecessary complicated...
>>     
>
> yes, but the cores are going to be radically different.  so i imagine you'd be 
> fine with the peripheral drivers, but not the avr32 core.  it's your time 
> though of course.
> -mike
>   
Dear Mike,

So what areas do we have?
1. AVR32 core - avr32 custodian
2. ARMxxx core - ARM custodian
3. AT91 core specifics and drivers - at91 custodian
4. Atmel peripheral hardware drivers - avr32 AND at91 custodians

Area 1. there will be not much new development for AVR32-AP700x, since Atmel
declared the AP700x NRFD. None of the UC3 Variants will be likely
to use u-boot. Only one of them allows significant external ROM and RAM.
Picking up the few commits for AVR32 core, should not be much work.

Area 3. I see nothing specific right now for the ARM core itself. In 
arch/.../at91
are some "drivers" that manage at91 specific stuff like peripheral inits,
clock, (now my at91sam9xe-specific eflash driver), led(!), reset, timer. 
Nothing really
ARM core related. It might even be discussed whether some of the files even
belong in this directory...

Area 4. any commit in this area would need both custodians' work before
it can go mainline. Wolfgang pulling from both trees might sometimes
give him extra work because of conflicts.
Or we postulate that common driver work goes through the at91 custodian 
only.

And yes, taking care of AVR32 as well looks like extra work at first, 
but it seems
to me that the extra work involved for Area 4 is not less if there are 
two trees.

Reinhard