Messages in this thread | | | Date | Mon, 29 Sep 2014 10:52:50 +0200 | From | Nicolas Ferre <> | Subject | Re: [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
| |