Message ID | 1363171688.3137.196.camel@x61.thuisdomein (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
On 03/13/2013 11:48 AM, Paul Bolle : > 0) Commit 1e3ce2b8545390a2aee8dbfcd49ca4161b636000 > ("AR[M]: at91: introduce SOC_AT91xxx define to allow to compile SoC core > support") dropped the Kconfig symbol ARCH_AT91SAM9X5. It seems it missed > something like this: > > diff --git a/arch/arm/mach-at91/Kconfig b/arch/arm/mach-at91/Kconfig > index 6071f4c..2db5370 100644 > --- a/arch/arm/mach-at91/Kconfig > +++ b/arch/arm/mach-at91/Kconfig > @@ -131,6 +131,10 @@ config ARCH_AT91SAM9G45 > bool "AT91SAM9G45" > select SOC_AT91SAM9G45 > > +config ARCH_AT91SAM9X5 > + bool "AT91SAM9X5" > + select SOC_AT91SAM9X5 > + > config ARCH_AT91X40 > bool "AT91x40" > depends on !MMU > > 1) But before I submit something along those lines: ARCH_AT91* variants > are still used quite a bit around the tree (both as Kconfig symbols and > as Kconfig macros). How are the current SOC_AT91* symbols wired back to > the old ARCH_AT91* symbols? Or are those old symbols and macros _only_ > needed for backwards compatibility? These ARCH_AT91xxx variables are not used anymore for pure Device Tree SoCs (I mean: at91sam9x5, at91sam9n12, sama5d3 families). They are used for non-DT SoCs and for chips that support both legacy board files and DT. The old ARCH_AT91xxx symbols are selecting the corresponding SOC_AT91xxx symbol. ARCH_AT91xxx in Kconfig that are specific to a particular SoC are going to disappear as we tend to allow the compilation of a particular driver for a wider range of configurations. Hope that it helps. Best regards,
On Wed, 2013-03-13 at 12:12 +0100, Nicolas Ferre wrote: > These ARCH_AT91xxx variables are not used anymore for pure Device Tree > SoCs (I mean: at91sam9x5, at91sam9n12, sama5d3 families). They are used > for non-DT SoCs and for chips that support both legacy board files and DT. > The old ARCH_AT91xxx symbols are selecting the corresponding SOC_AT91xxx > symbol. > > ARCH_AT91xxx in Kconfig that are specific to a particular SoC are going > to disappear as we tend to allow the compilation of a particular driver > for a wider range of configurations. So setting one of the SOC_* symbols will not generate the corresponding ARCH_* symbol, will it? To be specific, for the people entering the configuration from the new SOC_* side none of this is relevant anymore (this is all the stuff outside of arch/arm): drivers/misc/Kconfig:87: prompt "TC Block" if ARCH_AT91RM9200 || ARCH_AT91SAM9260 || CPU_AT32AP700X drivers/pcmcia/Kconfig:291: depends on PCMCIA && ARCH_AT91RM9200 drivers/rtc/Kconfig:977: depends on ARCH_AT91 && !(ARCH_AT91RM9200 || ARCH_AT91X40) drivers/tty/serial/atmel_serial.c:268:#ifdef CONFIG_ARCH_AT91RM9200 drivers/watchdog/Kconfig:127: depends on ARCH_AT91 && !ARCH_AT91RM9200 drivers/misc/Kconfig:87: prompt "TC Block" if ARCH_AT91RM9200 || ARCH_AT91SAM9260 || CPU_AT32AP700X drivers/video/Kconfig:1026: depends on FB_ATMEL && ARCH_AT91SAM9261 drivers/net/can/Kconfig:68: depends on ARCH_AT91SAM9263 || ARCH_AT91SAM9X5 drivers/rtc/Kconfig:991: prompt "RTT module Number" if ARCH_AT91SAM9263 drivers/rtc/Kconfig:1000: range 0 3 if !ARCH_AT91SAM9263 drivers/rtc/Kconfig:1001: range 0 15 if ARCH_AT91SAM9263 drivers/usb/gadget/Kconfig:157: depends on AVR32 || ARCH_AT91SAM9RL || ARCH_AT91SAM9G45 drivers/usb/gadget/atmel_usba_udc.c:329:#if defined(CONFIG_ARCH_AT91SAM9RL) drivers/usb/gadget/atmel_usba_udc.c:349:#endif /* CONFIG_ARCH_AT91SAM9RL */ drivers/mmc/host/Kconfig:305: depends on MMC_ATMELMCI && (AVR32 || ARCH_AT91SAM9G45) && DMA_ENGINE drivers/usb/gadget/Kconfig:157: depends on AVR32 || ARCH_AT91SAM9RL || ARCH_AT91SAM9G45 drivers/net/can/Kconfig:68: depends on ARCH_AT91SAM9263 || ARCH_AT91SAM9X5 Paul Bolle
On 12:22 Wed 13 Mar , Paul Bolle wrote: > On Wed, 2013-03-13 at 12:12 +0100, Nicolas Ferre wrote: > > These ARCH_AT91xxx variables are not used anymore for pure Device Tree > > SoCs (I mean: at91sam9x5, at91sam9n12, sama5d3 families). They are used > > for non-DT SoCs and for chips that support both legacy board files and DT. > > The old ARCH_AT91xxx symbols are selecting the corresponding SOC_AT91xxx > > symbol. > > > > ARCH_AT91xxx in Kconfig that are specific to a particular SoC are going > > to disappear as we tend to allow the compilation of a particular driver > > for a wider range of configurations. > > So setting one of the SOC_* symbols will not generate the corresponding > ARCH_* symbol, will it? To be specific, for the people entering the > configuration from the new SOC_* side none of this is relevant anymore > (this is all the stuff outside of arch/arm): yes it's as when I prepare the at91 for dt support I split the code in two world. The old style (one soc at a time) and the st multi soc the ARCH_AT91xxx are still here as part of the code are still depending on old style platform data and not converted to DT but the ARCH_AT91SAM9x5 never exist at the mainline and all the old style as now mark as deprecated and for removal Best Regards, J. > > drivers/misc/Kconfig:87: prompt "TC Block" if ARCH_AT91RM9200 || ARCH_AT91SAM9260 || CPU_AT32AP700X > drivers/pcmcia/Kconfig:291: depends on PCMCIA && ARCH_AT91RM9200 > drivers/rtc/Kconfig:977: depends on ARCH_AT91 && !(ARCH_AT91RM9200 || ARCH_AT91X40) > drivers/tty/serial/atmel_serial.c:268:#ifdef CONFIG_ARCH_AT91RM9200 > drivers/watchdog/Kconfig:127: depends on ARCH_AT91 && !ARCH_AT91RM9200 > drivers/misc/Kconfig:87: prompt "TC Block" if ARCH_AT91RM9200 || ARCH_AT91SAM9260 || CPU_AT32AP700X > drivers/video/Kconfig:1026: depends on FB_ATMEL && ARCH_AT91SAM9261 > drivers/net/can/Kconfig:68: depends on ARCH_AT91SAM9263 || ARCH_AT91SAM9X5 > drivers/rtc/Kconfig:991: prompt "RTT module Number" if ARCH_AT91SAM9263 > drivers/rtc/Kconfig:1000: range 0 3 if !ARCH_AT91SAM9263 > drivers/rtc/Kconfig:1001: range 0 15 if ARCH_AT91SAM9263 > drivers/usb/gadget/Kconfig:157: depends on AVR32 || ARCH_AT91SAM9RL || ARCH_AT91SAM9G45 > drivers/usb/gadget/atmel_usba_udc.c:329:#if defined(CONFIG_ARCH_AT91SAM9RL) > drivers/usb/gadget/atmel_usba_udc.c:349:#endif /* CONFIG_ARCH_AT91SAM9RL */ > drivers/mmc/host/Kconfig:305: depends on MMC_ATMELMCI && (AVR32 || ARCH_AT91SAM9G45) && DMA_ENGINE > drivers/usb/gadget/Kconfig:157: depends on AVR32 || ARCH_AT91SAM9RL || ARCH_AT91SAM9G45 > drivers/net/can/Kconfig:68: depends on ARCH_AT91SAM9263 || ARCH_AT91SAM9X5 > > > Paul Bolle >
On 03/13/2013 12:22 PM, Paul Bolle : > On Wed, 2013-03-13 at 12:12 +0100, Nicolas Ferre wrote: >> These ARCH_AT91xxx variables are not used anymore for pure Device Tree >> SoCs (I mean: at91sam9x5, at91sam9n12, sama5d3 families). They are used >> for non-DT SoCs and for chips that support both legacy board files and DT. >> The old ARCH_AT91xxx symbols are selecting the corresponding SOC_AT91xxx >> symbol. >> >> ARCH_AT91xxx in Kconfig that are specific to a particular SoC are going >> to disappear as we tend to allow the compilation of a particular driver >> for a wider range of configurations. > > So setting one of the SOC_* symbols will not generate the corresponding > ARCH_* symbol, will it? To be specific, for the people entering the > configuration from the new SOC_* side none of this is relevant anymore > (this is all the stuff outside of arch/arm): > > drivers/misc/Kconfig:87: prompt "TC Block" if ARCH_AT91RM9200 || ARCH_AT91SAM9260 || CPU_AT32AP700X > drivers/pcmcia/Kconfig:291: depends on PCMCIA && ARCH_AT91RM9200 > drivers/rtc/Kconfig:977: depends on ARCH_AT91 && !(ARCH_AT91RM9200 || ARCH_AT91X40) > drivers/tty/serial/atmel_serial.c:268:#ifdef CONFIG_ARCH_AT91RM9200 > drivers/watchdog/Kconfig:127: depends on ARCH_AT91 && !ARCH_AT91RM9200 > drivers/misc/Kconfig:87: prompt "TC Block" if ARCH_AT91RM9200 || ARCH_AT91SAM9260 || CPU_AT32AP700X > drivers/video/Kconfig:1026: depends on FB_ATMEL && ARCH_AT91SAM9261 > drivers/net/can/Kconfig:68: depends on ARCH_AT91SAM9263 || ARCH_AT91SAM9X5 > drivers/rtc/Kconfig:991: prompt "RTT module Number" if ARCH_AT91SAM9263 > drivers/rtc/Kconfig:1000: range 0 3 if !ARCH_AT91SAM9263 > drivers/rtc/Kconfig:1001: range 0 15 if ARCH_AT91SAM9263 > drivers/usb/gadget/Kconfig:157: depends on AVR32 || ARCH_AT91SAM9RL || ARCH_AT91SAM9G45 > drivers/usb/gadget/atmel_usba_udc.c:329:#if defined(CONFIG_ARCH_AT91SAM9RL) > drivers/usb/gadget/atmel_usba_udc.c:349:#endif /* CONFIG_ARCH_AT91SAM9RL */ > drivers/mmc/host/Kconfig:305: depends on MMC_ATMELMCI && (AVR32 || ARCH_AT91SAM9G45) && DMA_ENGINE > drivers/usb/gadget/Kconfig:157: depends on AVR32 || ARCH_AT91SAM9RL || ARCH_AT91SAM9G45 > drivers/net/can/Kconfig:68: depends on ARCH_AT91SAM9263 || ARCH_AT91SAM9X5 They are being removed one by one and replaced by ARCH_AT91, ARM or even simply HAVE_CLK... Have a look at recent patch "[PATCH v2 2/2] can: Kconfig: CAN_AT91 depends on ARM". But it is true that if you find good patches to remove them, I am in favor for this move. Best regards,
On Wed, 2013-03-13 at 13:26 +0100, Jean-Christophe PLAGNIOL-VILLARD
wrote:
> but the ARCH_AT91SAM9x5 never exist at the mainline
I'm not sure I understand this.
We're discussing the effects of commit
1e3ce2b8545390a2aee8dbfcd49ca4161b636000 ("AR[M]: at91: introduce
SOC_AT91xxx define to allow to compile SoC core support") here. It did
remove ARCH_AT91SAM9X5:
$ git show 1e3ce2b8545390a2aee8dbfcd49ca4161b636000 | grep ARCH_AT91SAM9X5
-config ARCH_AT91SAM9X5
@@ -93,8 +91,47 @@ config ARCH_AT91SAM9X5
-obj-$(CONFIG_ARCH_AT91SAM9X5) += at91sam9x5.o
-#ifdef CONFIG_ARCH_AT91SAM9X5
-#if !defined(CONFIG_ARCH_AT91SAM9X5)
It also added SOC_AT91SAM9X5, and that symbol even triggers the
compilation of a file named at91sam9x5.c:
$ git show 1e3ce2b8545390a2aee8dbfcd49ca4161b636000 | grep SOC_AT91SAM9X5
+config SOC_AT91SAM9X5
+obj-$(CONFIG_SOC_AT91SAM9X5) += at91sam9x5.o
+#ifdef CONFIG_SOC_AT91SAM9X5
+#if !defined(CONFIG_SOC_AT91SAM9X5)
And also note that ARCH_AT91SAM9X5 still is used as an (optional) dependency:
$ git grep -n ARCH_AT91SAM9X5 v3.9-rc2
v3.9-rc2:drivers/net/can/Kconfig:68: depends on ARCH_AT91SAM9263 || ARCH_AT91SAM9X5
Paul Bolle
On 03/14/2013 09:17 AM, Paul Bolle : > On Wed, 2013-03-13 at 13:26 +0100, Jean-Christophe PLAGNIOL-VILLARD > wrote: >> but the ARCH_AT91SAM9x5 never exist at the mainline > > I'm not sure I understand this. > > We're discussing the effects of commit > 1e3ce2b8545390a2aee8dbfcd49ca4161b636000 ("AR[M]: at91: introduce > SOC_AT91xxx define to allow to compile SoC core support") here. It did > remove ARCH_AT91SAM9X5: > $ git show 1e3ce2b8545390a2aee8dbfcd49ca4161b636000 | grep ARCH_AT91SAM9X5 > -config ARCH_AT91SAM9X5 > @@ -93,8 +91,47 @@ config ARCH_AT91SAM9X5 > -obj-$(CONFIG_ARCH_AT91SAM9X5) += at91sam9x5.o > -#ifdef CONFIG_ARCH_AT91SAM9X5 > -#if !defined(CONFIG_ARCH_AT91SAM9X5) > > It also added SOC_AT91SAM9X5, and that symbol even triggers the > compilation of a file named at91sam9x5.c: > $ git show 1e3ce2b8545390a2aee8dbfcd49ca4161b636000 | grep SOC_AT91SAM9X5 > +config SOC_AT91SAM9X5 > +obj-$(CONFIG_SOC_AT91SAM9X5) += at91sam9x5.o > +#ifdef CONFIG_SOC_AT91SAM9X5 > +#if !defined(CONFIG_SOC_AT91SAM9X5) > > And also note that ARCH_AT91SAM9X5 still is used as an (optional) dependency: > $ git grep -n ARCH_AT91SAM9X5 v3.9-rc2 > v3.9-rc2:drivers/net/can/Kconfig:68: depends on ARCH_AT91SAM9263 || ARCH_AT91SAM9X5 Which is removed by patch: "[PATCH v2 2/2] can: Kconfig: CAN_AT91 depends on ARM" It should appear in CAN git tree soon. Best regards,
On Thu, 2013-03-14 at 09:30 +0100, Nicolas Ferre wrote: > On 03/14/2013 09:17 AM, Paul Bolle : > > And also note that ARCH_AT91SAM9X5 still is used as an (optional) dependency: > > $ git grep -n ARCH_AT91SAM9X5 v3.9-rc2 > > v3.9-rc2:drivers/net/can/Kconfig:68: depends on ARCH_AT91SAM9263 || ARCH_AT91SAM9X5 > > Which is removed by patch: > "[PATCH v2 2/2] can: Kconfig: CAN_AT91 depends on ARM" > > It should appear in CAN git tree soon. Nice. Thanks for the clearing things up. Paul Bolle
diff --git a/arch/arm/mach-at91/Kconfig b/arch/arm/mach-at91/Kconfig index 6071f4c..2db5370 100644 --- a/arch/arm/mach-at91/Kconfig +++ b/arch/arm/mach-at91/Kconfig @@ -131,6 +131,10 @@ config ARCH_AT91SAM9G45 bool "AT91SAM9G45" select SOC_AT91SAM9G45 +config ARCH_AT91SAM9X5 + bool "AT91SAM9X5" + select SOC_AT91SAM9X5 + config ARCH_AT91X40 bool "AT91x40" depends on !MMU