lkml.org 
[lkml]   [2014]   [Sep]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [GIT PULL] at91: soc for 3.18 #2
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


\
 
 \ /
  Last update: 2014-09-29 11:01    [W:0.037 / U:0.036 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site