[GIT PULL] at91: soc for 3.18 #2

[GIT PULL] at91: soc for 3.18 #2

[Nicolas Ferre]

Arnd, Olof, Kevin,

This is the second SoC pull-request for AT91 and it's dedicated to the addition
of our new SAMA5D4: C-A5+neon+L2CC+vdec (in sort). The AT91 SoC support is now
pretty simple in relation with the enhancements done recently.
The patches go on top of the previous tag at91-soc and has no dependency.

The merge with other AT91 branches can lead to little conflicts that I resolved
for you in the at91-3.18-resolved2 branch that you can take as an example.

Thanks, best regards,

The following changes since commit 5db722eeba0051c68e638114f6720e715b03cd2c:

  ARM: at91: Remove the support for the RSI EWS board (2014-09-19 13:13:23 +0200)

are available in the git repository at:

  git://github.com/at91linux/linux-at91.git tags/at91-soc2

for you to fetch changes up to 02037a9719fa89b7e5dc25cb22afc06c4eae406e:

  ARM: at91: document Atmel SMART compatibles (2014-09-22 14:42:40 +0200)

----------------------------------------------------------------
Second SoC batch for 3.18:
- introduction of the new SAMA5D4 SoC and associated Evaluation Kit
- low level soc detection and early printk code
- taking advantage of this, documentation of all AT91 SoC DT strings

----------------------------------------------------------------
Alexandre Belloni (3):
      clk: at91: add a driver for the h32mx clock
      ARM: at91: add sama5d4 support to sama5_defconfig
      ARM: at91: document Atmel SMART compatibles

Nicolas Ferre (4):
      ARM: at91: introduce basic SAMA5D4 support
      ARM: at91: SAMA5D4 SoC detection code and low level routines
      ARM: at91: dt: add device tree file for SAMA5D4 SoC
      ARM: at91: dt: add device tree file for SAMA5D4ek board

 .../devicetree/bindings/arm/atmel-at91.txt         |   37 +
 .../devicetree/bindings/clock/at91-clock.txt       |   14 +
 arch/arm/Kconfig.debug                             |    4 +
 arch/arm/boot/dts/Makefile                         |    2 +
 arch/arm/boot/dts/at91-sama5d4ek.dts               |  260 ++++
 arch/arm/boot/dts/sama5d4.dtsi                     | 1240 ++++++++++++++++++++
 arch/arm/configs/sama5_defconfig                   |    1 +
 arch/arm/mach-at91/Kconfig                         |   21 +
 arch/arm/mach-at91/Makefile                        |    1 +
 arch/arm/mach-at91/board-dt-sama5.c                |   16 +-
 arch/arm/mach-at91/generic.h                       |    1 +
 arch/arm/mach-at91/include/mach/cpu.h              |   22 +-
 arch/arm/mach-at91/include/mach/debug-macro.S      |    5 +-
 arch/arm/mach-at91/include/mach/hardware.h         |   19 +-
 arch/arm/mach-at91/include/mach/sama5d4.h          |   33 +
 arch/arm/mach-at91/include/mach/uncompress.h       |   21 +-
 arch/arm/mach-at91/sama5d4.c                       |   64 +
 arch/arm/mach-at91/setup.c                         |   97 +-
 arch/arm/mach-at91/soc.h                           |    5 +
 drivers/clk/at91/Makefile                          |    1 +
 drivers/clk/at91/clk-h32mx.c                       |  123 ++
 drivers/clk/at91/pmc.c                             |    6 +
 drivers/clk/at91/pmc.h                             |    5 +
 include/linux/clk/at91_pmc.h                       |    1 +
 24 files changed, 1987 insertions(+), 12 deletions(-)
 create mode 100644 arch/arm/boot/dts/at91-sama5d4ek.dts
 create mode 100644 arch/arm/boot/dts/sama5d4.dtsi
 create mode 100644 arch/arm/mach-at91/include/mach/sama5d4.h
 create mode 100644 arch/arm/mach-at91/sama5d4.c
 create mode 100644 drivers/clk/at91/clk-h32mx.c

-- 
Nicolas Ferre

[GIT PULL] at91: soc for 3.18 #2

[Arnd Bergmann]

On Monday 22 September 2014, Nicolas Ferre wrote:
> Arnd, Olof, Kevin,
> 
> This is the second SoC pull-request for AT91 and it's dedicated to the addition
> of our new SAMA5D4: C-A5+neon+L2CC+vdec (in sort). The AT91 SoC support is now
> pretty simple in relation with the enhancements done recently.
> The patches go on top of the previous tag at91-soc and has no dependency.
> 
> The merge with other AT91 branches can lead to little conflicts that I resolved
> for you in the at91-3.18-resolved2 branch that you can take as an example.
> 
> Thanks, best regards,
> 
> The following changes since commit 5db722eeba0051c68e638114f6720e715b03cd2c:
> 
>   ARM: at91: Remove the support for the RSI EWS board (2014-09-19 13:13:23 +0200)
> 
> are available in the git repository at:
> 
>   git://github.com/at91linux/linux-at91.git tags/at91-soc2
> 
> for you to fetch changes up to 02037a9719fa89b7e5dc25cb22afc06c4eae406e:
> 
>   ARM: at91: document Atmel SMART compatibles (2014-09-22 14:42:40 +0200)
> 
> ----------------------------------------------------------------
> Second SoC batch for 3.18:
> - introduction of the new SAMA5D4 SoC and associated Evaluation Kit
> - low level soc detection and early printk code
> - taking advantage of this, documentation of all AT91 SoC DT strings

Pulled into next/soc, thanks!

	Arnd

[GIT PULL] at91: soc for 3.18 #2

[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.

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.

	Arnd
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)

[GIT PULL] at91: soc for 3.18 #2

[Alexandre Belloni]

Hi,

On 26/09/2014 at 12:50:02 +0200, Arnd Bergmann wrote :
> 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.
> 
> 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.
> 

Yeah, there are upcoming patches that add more differences between
sama5d3 and sama5d4. Also, a huge cleanup is planned after all the
boards files have been removed and all the boards have been either
migrated to DT and CCF or dropped.

I'll owe you the drink of your choice if that is not done by 3.20 ;)

-- 
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[GIT PULL] at91: soc for 3.18 #2

[Nicolas Ferre]

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

[GIT PULL] at91: soc for 3.18 #2

[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.

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.

> > 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

[GIT PULL] at91: soc for 3.18 #2

[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