lkml.org 
[lkml]   [2014]   [Sep]   [26]   [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 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'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.

Your thoughts?

Bye,

> 8<-------
>>From 45aeea29c360551519edd8e041b36d8a4d5f6a23 Mon Sep 17 00:00:00 2001
> From: Arnd Bergmann <arnd@arndb.de>
> Date: Fri, 26 Sep 2014 12:27:00 +0200
> Subject: [PATCH] ARM: at91: fix nommu build regression
>
> The newly introduced support for SAMA5D4 added access to the
> 'AT91_ALT_BASE_SYS' register area, but failed to define the
> symbols in the case when CONFIG_MMU is disabled.
>
> We really should not hardwire addresses like this any more,
> but as a small fixup, this patch just adds the missing
> definitions for the nommu case, which gets at91x40_defconfig
> and any configuration of sam9 and sama5 with MMU disabled
> back to work.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Fixes: 726d32bf79ef4 ("ARM: at91: SAMA5D4 SoC detection code and low ...")
>
> diff --git a/arch/arm/mach-at91/include/mach/hardware.h b/arch/arm/mach-at91/include/mach/hardware.h
> index d84776f6b8ac..c13797352688 100644
> --- a/arch/arm/mach-at91/include/mach/hardware.h
> +++ b/arch/arm/mach-at91/include/mach/hardware.h
> @@ -51,11 +51,12 @@
> */
> #define AT91_BASE_SYS 0xffffc000
>
> +#endif
> +
> /*
> * On sama5d4 there is no system controller, we map some needed peripherals
> */
> #define AT91_ALT_BASE_SYS 0xfc069000
> -#endif
>
> /*
> * On all at91 have the Advanced Interrupt Controller starts at address
> @@ -90,6 +91,9 @@
> */
> #define AT91_IO_PHYS_BASE AT91_BASE_SYS
> #define AT91_IO_VIRT_BASE IOMEM(AT91_IO_PHYS_BASE)
> +
> +#define AT91_ALT_IO_PHYS_BASE AT91_ALT_BASE_SYS
> +#define AT91_ALT_IO_VIRT_BASE IOMEM(AT91_ALT_BASE_SYS)
> #endif
>
> #define AT91_IO_SIZE (0xFFFFFFFF - AT91_IO_PHYS_BASE + 1)
>
>


--
Nicolas Ferre


\
 
 \ /
  Last update: 2014-09-26 17:21    [W:0.195 / U:0.008 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site