[GIT PULL] at91: soc for 3.18 #2

[nicolas.ferre@atmel.com (Nicolas Ferre)]

On 26/09/2014 20:55, Arnd Bergmann :
> On Friday 26 September 2014 16:47:12 Nicolas Ferre wrote:
>> On 26/09/2014 12:50, Arnd Bergmann :
>>> On Monday 22 September 2014, Nicolas Ferre wrote:
>>>
>>>> Nicolas Ferre (4):
>>>>       ARM: at91: introduce basic SAMA5D4 support
>>>>       ARM: at91: SAMA5D4 SoC detection code and low level routines
>>>
>>> This resulted in build failures both in at91x40_defconfig and some
>>> randconfigs with MMU disabled. I've applied the patch below on top
>>> to fix it.
>>
>> Ok, I see: sorry for the inconvenience.
>> What about taking the patch that I sent about removing completely the
>> at91x40 as it is "Acked" by everybody now? The would prevent from adding
>> these unneeded values.
> 
> I thought about that, but it would still be broken in randconfig builds
> that turn off the MMU on any of the other at91 variants, as I wrote above.

Okay, sorry, I overlooked this part.

> at91 is actually one of the platforms that I'd assume would even work in
> that configuration. We should at one point in the future discuss more
> widely whether we try to fix more of the bugs one hits with this or
> we just outright prevent users from turning off the MMU on platforms
> that have one.

Well, for the moment, it still makes sense to keep this possibility. So
your patch is perfectly fine for me, if needed:

Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>

Bye,

>>> I'm not exactly happy about the soc detection code anyway after I
>>> had to look at that. Why do you even hardcode the physical register
>>> location rather than getting it from DT?
>>>
>>> Also, why do you care about which SoC version you have for the
>>> modern SAMA5 chips? All I see is a sama5d4_map_io() callback
>>> that maps a lot of completely unused registers along with
>>> the uart that you normally get from the implicit debug_ll_io_init,
>>> and the SRAM that should probably be turned into a normal driver.
>>
>> Yes, as said by Alexandre, we are aware of the flaws of AT91 SoC
>> initialization, but last time I tried, our code was called too early.
>> Now with the work from Maxime with the timer (in 3.18) it might be
>> possible to reorder all this.
>> But please, I would really like to remove all !DT *and* !CCF material
>> before starting this work, otherwise we will again have a double path
>> for sam9's and I'd like to avoid this.
> 
> I'm not complaining about the use of the early registers on sam9, I know
> you are working hard on cleaning that up. I still don't see why you
> duplicate it for sama5, but it's ok as long as you have a plan.
> 
> 	Arnd
> 


-- 
Nicolas Ferre