| Message ID | 1411391733-28891-1-git-send-email-nicolas.ferre@atmel.com |
|---|---|
| State | New |
| Headers | show |
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
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 ;)
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) > >
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
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 >
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