| Message ID | 1431769465-26867-9-git-send-email-stefan@agner.ch (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Sat, May 16, 2015 at 11:44:20AM +0200, Stefan Agner wrote: > Remove the needless differences between MMU/!MMU addruart calls. > This allows to use the same addruart macro on SoC level. Useful > for SoC consisting of multiple CPUs with and without MMU such as > Freescale Vybrid. > > Signed-off-by: Stefan Agner <stefan@agner.ch> Depending on the merge plan for the remainder (has tglx reviewed the IRQ changes yet? I think he needs to before this can be merged)... if it's not going to go in for the next merge window, this should find its way into the patch system so it can be applied anyway. > --- > arch/arm/include/debug/efm32.S | 2 +- > arch/arm/kernel/debug.S | 2 +- > 2 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/arch/arm/include/debug/efm32.S b/arch/arm/include/debug/efm32.S > index 2265a19..660fa1e 100644 > --- a/arch/arm/include/debug/efm32.S > +++ b/arch/arm/include/debug/efm32.S > @@ -16,7 +16,7 @@ > > #define UARTn_TXDATA 0x0034 > > - .macro addruart, rx, tmp > + .macro addruart, rx, tmp, tmp2 > ldr \rx, =(CONFIG_DEBUG_UART_PHYS) > > /* > diff --git a/arch/arm/kernel/debug.S b/arch/arm/kernel/debug.S > index 78c91b5..ea9646c 100644 > --- a/arch/arm/kernel/debug.S > +++ b/arch/arm/kernel/debug.S > @@ -35,7 +35,7 @@ > > #else /* !CONFIG_MMU */ > .macro addruart_current, rx, tmp1, tmp2 > - addruart \rx, \tmp1 > + addruart \rx, \tmp1, \tmp2 > .endm > > #endif /* CONFIG_MMU */ > -- > 2.4.1 >
On Sat, 16 May 2015, Russell King - ARM Linux wrote: > On Sat, May 16, 2015 at 11:44:20AM +0200, Stefan Agner wrote: > > Remove the needless differences between MMU/!MMU addruart calls. > > This allows to use the same addruart macro on SoC level. Useful > > for SoC consisting of multiple CPUs with and without MMU such as > > Freescale Vybrid. > > > > Signed-off-by: Stefan Agner <stefan@agner.ch> > > Depending on the merge plan for the remainder (has tglx reviewed the IRQ > changes yet? I think he needs to before this can be merged)... if it's > not going to go in for the next merge window, this should find its way > into the patch system so it can be applied anyway. I'm going to apply the irq core and chip driver modifications to a separate branch later today, so you or ARM-SOC folks can pull that in. Will send you a mail where it can be found. Thanks, tglx
On Sun, 17 May 2015, Thomas Gleixner wrote: > On Sat, 16 May 2015, Russell King - ARM Linux wrote: > > > On Sat, May 16, 2015 at 11:44:20AM +0200, Stefan Agner wrote: > > > Remove the needless differences between MMU/!MMU addruart calls. > > > This allows to use the same addruart macro on SoC level. Useful > > > for SoC consisting of multiple CPUs with and without MMU such as > > > Freescale Vybrid. > > > > > > Signed-off-by: Stefan Agner <stefan@agner.ch> > > > > Depending on the merge plan for the remainder (has tglx reviewed the IRQ > > changes yet? I think he needs to before this can be merged)... if it's > > not going to go in for the next merge window, this should find its way > > into the patch system so it can be applied anyway. > > I'm going to apply the irq core and chip driver modifications to a > separate branch later today, so you or ARM-SOC folks can pull that > in. Will send you a mail where it can be found. git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git irq/for-arm That contains the first 5 patches which touch kernel/irq/ and drivers/irqchip/ Thanks, tglx
On Mon, May 18, 2015 at 05:36:43PM +0200, Thomas Gleixner wrote: > > > On Sun, 17 May 2015, Thomas Gleixner wrote: > > > On Sat, 16 May 2015, Russell King - ARM Linux wrote: > > > > > On Sat, May 16, 2015 at 11:44:20AM +0200, Stefan Agner wrote: > > > > Remove the needless differences between MMU/!MMU addruart calls. > > > > This allows to use the same addruart macro on SoC level. Useful > > > > for SoC consisting of multiple CPUs with and without MMU such as > > > > Freescale Vybrid. > > > > > > > > Signed-off-by: Stefan Agner <stefan@agner.ch> > > > > > > Depending on the merge plan for the remainder (has tglx reviewed the IRQ > > > changes yet? I think he needs to before this can be merged)... if it's > > > not going to go in for the next merge window, this should find its way > > > into the patch system so it can be applied anyway. > > > > I'm going to apply the irq core and chip driver modifications to a > > separate branch later today, so you or ARM-SOC folks can pull that > > in. Will send you a mail where it can be found. > > git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git irq/for-arm > > That contains the first 5 patches which touch kernel/irq/ and > drivers/irqchip/ Russell, Arnd, I guess the easiest way to merge rest of the series is to have them go via i.MX tree with your nods? Shawn
On Tue, 19 May 2015, Shawn Guo wrote: > On Mon, May 18, 2015 at 05:36:43PM +0200, Thomas Gleixner wrote: > > > > > > On Sun, 17 May 2015, Thomas Gleixner wrote: > > > > > On Sat, 16 May 2015, Russell King - ARM Linux wrote: > > > > > > > On Sat, May 16, 2015 at 11:44:20AM +0200, Stefan Agner wrote: > > > > > Remove the needless differences between MMU/!MMU addruart calls. > > > > > This allows to use the same addruart macro on SoC level. Useful > > > > > for SoC consisting of multiple CPUs with and without MMU such as > > > > > Freescale Vybrid. > > > > > > > > > > Signed-off-by: Stefan Agner <stefan@agner.ch> > > > > > > > > Depending on the merge plan for the remainder (has tglx reviewed the IRQ > > > > changes yet? I think he needs to before this can be merged)... if it's > > > > not going to go in for the next merge window, this should find its way > > > > into the patch system so it can be applied anyway. > > > > > > I'm going to apply the irq core and chip driver modifications to a > > > separate branch later today, so you or ARM-SOC folks can pull that > > > in. Will send you a mail where it can be found. > > > > git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git irq/for-arm > > > > That contains the first 5 patches which touch kernel/irq/ and > > drivers/irqchip/ > > Russell, Arnd, > > I guess the easiest way to merge rest of the series is to have them go > via i.MX tree with your nods? If you pull the irq stuff. Make sure that the HEAD is b5cc5cbc11697. I pushed out a broken version earlier. Thanks, tglx
On Tue, May 19, 2015 at 10:11:40AM +0200, Thomas Gleixner wrote: > If you pull the irq stuff. Make sure that the HEAD is b5cc5cbc11697. I > pushed out a broken version earlier. Okay, thanks for the info, Thomas. I will take care of it if rmk and Arnd agree with the approach. Shawn
On Tue, May 19, 2015 at 01:35:03PM +0800, Shawn Guo wrote: > On Mon, May 18, 2015 at 05:36:43PM +0200, Thomas Gleixner wrote: > > On Sun, 17 May 2015, Thomas Gleixner wrote: > > > On Sat, 16 May 2015, Russell King - ARM Linux wrote: > > > > On Sat, May 16, 2015 at 11:44:20AM +0200, Stefan Agner wrote: > > > > > Remove the needless differences between MMU/!MMU addruart calls. > > > > > This allows to use the same addruart macro on SoC level. Useful > > > > > for SoC consisting of multiple CPUs with and without MMU such as > > > > > Freescale Vybrid. > > > > > > > > > > Signed-off-by: Stefan Agner <stefan@agner.ch> > > > > > > > > Depending on the merge plan for the remainder (has tglx reviewed the IRQ > > > > changes yet? I think he needs to before this can be merged)... if it's > > > > not going to go in for the next merge window, this should find its way > > > > into the patch system so it can be applied anyway. > > > > > > I'm going to apply the irq core and chip driver modifications to a > > > separate branch later today, so you or ARM-SOC folks can pull that > > > in. Will send you a mail where it can be found. > > > > git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git irq/for-arm > > > > That contains the first 5 patches which touch kernel/irq/ and > > drivers/irqchip/ > > Russell, Arnd, > > I guess the easiest way to merge rest of the series is to have them go > via i.MX tree with your nods? I don't know, I've not looked at the remainder of the patches. Having looked briefly at them, it looks like they touch EFM32 as well, so I'm not sure having them all go through iMX is the right approach either. Looking at the EFM32 patch, it looks like we've adopted my suggestion (discussed with Arnd in the previous month) wrt noMMU, so I'll post a couple of patches in a moment which fix Integrator for this as well. Integrator is independent of this series, and it fixes real problems caused by the single zImage stuff for noMMU there. It makes sense for these to all go through arm-soc - but the question is how do we get them all into arm-soc...
On 2015-05-19 12:16, Russell King - ARM Linux wrote: > On Tue, May 19, 2015 at 01:35:03PM +0800, Shawn Guo wrote: >> On Mon, May 18, 2015 at 05:36:43PM +0200, Thomas Gleixner wrote: >> > On Sun, 17 May 2015, Thomas Gleixner wrote: >> > > On Sat, 16 May 2015, Russell King - ARM Linux wrote: >> > > > On Sat, May 16, 2015 at 11:44:20AM +0200, Stefan Agner wrote: >> > > > > Remove the needless differences between MMU/!MMU addruart calls. >> > > > > This allows to use the same addruart macro on SoC level. Useful >> > > > > for SoC consisting of multiple CPUs with and without MMU such as >> > > > > Freescale Vybrid. >> > > > > >> > > > > Signed-off-by: Stefan Agner <stefan@agner.ch> >> > > > >> > > > Depending on the merge plan for the remainder (has tglx reviewed the IRQ >> > > > changes yet? I think he needs to before this can be merged)... if it's >> > > > not going to go in for the next merge window, this should find its way >> > > > into the patch system so it can be applied anyway. >> > > >> > > I'm going to apply the irq core and chip driver modifications to a >> > > separate branch later today, so you or ARM-SOC folks can pull that >> > > in. Will send you a mail where it can be found. >> > >> > git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git irq/for-arm >> > >> > That contains the first 5 patches which touch kernel/irq/ and >> > drivers/irqchip/ >> >> Russell, Arnd, >> >> I guess the easiest way to merge rest of the series is to have them go >> via i.MX tree with your nods? > > I don't know, I've not looked at the remainder of the patches. Having > looked briefly at them, it looks like they touch EFM32 as well, so I'm > not sure having them all go through iMX is the right approach either. > > Looking at the EFM32 patch, it looks like we've adopted my suggestion > (discussed with Arnd in the previous month) wrt noMMU, so I'll post a > couple of patches in a moment which fix Integrator for this as well. > Integrator is independent of this series, and it fixes real problems > caused by the single zImage stuff for noMMU there. > > It makes sense for these to all go through arm-soc - but the question > is how do we get them all into arm-soc... Sorry for the mess, I see, I should have tried split it in pieces which match the subsystems. Patch 06 defines a smaller vector table size, which is by default too large. Hence this patch is quite independent, the rest of the patch set works flawless without that patch. However, that patch relies on 8340/1 being applied ("ARM: ARMv7-M: Enlarge vector table up to 256 entries"). If this is ok for you Russel, I would submit that to your patch system. Patch 07 defines dependencies a bit more explicitly, however, with the current Kconfig symbol setup, both should be selected by other config symbols (CLKSRC_OF by ARM_SINGLE_ARMV7M and CLKSRC_MMIO by ARCH_MXC). Hence this can go independently through clocksource trees (Daniel/Thomas?) Not sure how we can deal with the EFM32 vs. IMX changes... Patches 08-10 has no dependencies on the clock changes which Thomas merged. They could go through whatever EFM32 is merged normally (last time Arnd directly merged from Uwe), and then Shawn could base the rest of the changes on that too? -- Stefan
On Tuesday 19 May 2015 13:23:22 Stefan Agner wrote: > On 2015-05-19 12:16, Russell King - ARM Linux wrote: > > On Tue, May 19, 2015 at 01:35:03PM +0800, Shawn Guo wrote: > >> On Mon, May 18, 2015 at 05:36:43PM +0200, Thomas Gleixner wrote: > >> > On Sun, 17 May 2015, Thomas Gleixner wrote: > >> > > I'm going to apply the irq core and chip driver modifications to a > >> > > separate branch later today, so you or ARM-SOC folks can pull that > >> > > in. Will send you a mail where it can be found. > >> > > >> > git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git irq/for-arm > >> > > >> > That contains the first 5 patches which touch kernel/irq/ and > >> > drivers/irqchip/ > >> > >> Russell, Arnd, > >> > >> I guess the easiest way to merge rest of the series is to have them go > >> via i.MX tree with your nods? Yes, that would be good. > > I don't know, I've not looked at the remainder of the patches. Having > > looked briefly at them, it looks like they touch EFM32 as well, so I'm > > not sure having them all go through iMX is the right approach either. > > > > Looking at the EFM32 patch, it looks like we've adopted my suggestion > > (discussed with Arnd in the previous month) wrt noMMU, so I'll post a > > couple of patches in a moment which fix Integrator for this as well. > > Integrator is independent of this series, and it fixes real problems > > caused by the single zImage stuff for noMMU there. > > > > It makes sense for these to all go through arm-soc - but the question > > is how do we get them all into arm-soc... > > Sorry for the mess, I see, I should have tried split it in pieces which > match the subsystems. > > Patch 06 defines a smaller vector table size, which is by default too > large. Hence this patch is quite independent, the rest of the patch set > works flawless without that patch. However, that patch relies on 8340/1 > being applied ("ARM: ARMv7-M: Enlarge vector table up to 256 entries"). > If this is ok for you Russel, I would submit that to your patch system. > > Patch 07 defines dependencies a bit more explicitly, however, with the > current Kconfig symbol setup, both should be selected by other config > symbols (CLKSRC_OF by ARM_SINGLE_ARMV7M and CLKSRC_MMIO by ARCH_MXC). > Hence this can go independently through clocksource trees > (Daniel/Thomas?) > > Not sure how we can deal with the EFM32 vs. IMX changes... Patches 08-10 > has no dependencies on the clock changes which Thomas merged. They could > go through whatever EFM32 is merged normally (last time Arnd directly > merged from Uwe), and then Shawn could base the rest of the changes on > that too? Do you have a dependency on patch 10 (the one for EFM32) in your later patches? If not, you can send the other ones to Shawn, so I pull them as a branch, and then I apply that on top of the merges. I have also merged two other ARMv7M platforms for 4.2 now (both in next/soc), so we should do the same change for those as well, and I'd rather apply a patch for that, than merge a branch that is based on next/soc. Arnd
On 2015-05-19 13:50, Arnd Bergmann wrote: > On Tuesday 19 May 2015 13:23:22 Stefan Agner wrote: >> On 2015-05-19 12:16, Russell King - ARM Linux wrote: <snip> >> Not sure how we can deal with the EFM32 vs. IMX changes... Patches 08-10 >> has no dependencies on the clock changes which Thomas merged. They could >> go through whatever EFM32 is merged normally (last time Arnd directly >> merged from Uwe), and then Shawn could base the rest of the changes on >> that too? > > Do you have a dependency on patch 10 (the one for EFM32) in your later > patches? Unfortunately, there is a dependency on that patch: I change the default of UNCOMPRESS_INCLUDE to debug/uncompress.h for all ARM_SINGLE_ARMV7M platforms. Without that patch, it would default to mach/uncompress.h, which does not exist for MACH_MXC/SOC_VF610. > > If not, you can send the other ones to Shawn, so I pull them as > a branch, and then I apply that on top of the merges. I have also > merged two other ARMv7M platforms for 4.2 now (both in next/soc), > so we should do the same change for those as well, and I'd rather > apply a patch for that, than merge a branch that is based on > next/soc. I guess, in that case, you need to take the others too? (08/09?) -- Stefan
On Tuesday 19 May 2015 18:06:53 Stefan Agner wrote: > On 2015-05-19 13:50, Arnd Bergmann wrote: > > On Tuesday 19 May 2015 13:23:22 Stefan Agner wrote: > >> On 2015-05-19 12:16, Russell King - ARM Linux wrote: > <snip> > >> Not sure how we can deal with the EFM32 vs. IMX changes... Patches 08-10 > >> has no dependencies on the clock changes which Thomas merged. They could > >> go through whatever EFM32 is merged normally (last time Arnd directly > >> merged from Uwe), and then Shawn could base the rest of the changes on > >> that too? > > > > Do you have a dependency on patch 10 (the one for EFM32) in your later > > patches? > > Unfortunately, there is a dependency on that patch: I change the default > of UNCOMPRESS_INCLUDE to debug/uncompress.h for all ARM_SINGLE_ARMV7M > platforms. Without that patch, it would default to mach/uncompress.h, > which does not exist for MACH_MXC/SOC_VF610. An easy approach would be to list both ARM_SINGLE_ARMV7M and EFM32 in the UNCOMPRESS_INCLUDE option initially, and then follow-up with a patch that converts the three other platforms (efm32, stm32 and lpc18xx) to ARM_SINGLE_ARMV7M and also change the UNCOMPRESS_INCLUDE statement. Note that I've already added both stm32 and lpc18xx to the UNCOMPRESS_INCLUDE list in the next/soc branch. > > If not, you can send the other ones to Shawn, so I pull them as > > a branch, and then I apply that on top of the merges. I have also > > merged two other ARMv7M platforms for 4.2 now (both in next/soc), > > so we should do the same change for those as well, and I'd rather > > apply a patch for that, than merge a branch that is based on > > next/soc. > > I guess, in that case, you need to take the others too? (08/09?) I'm fine with that, too. If Shawn thinks the patches are ok, you can just send all patches you want me to apply in arm-soc based on the appropriate branches (next/soc, next/dt and next/defconfig, I presume), and I'll apply them this time. In the future, you should send all patches to Shawn though. Arnd
On 2015-05-19 20:24, Arnd Bergmann wrote: > On Tuesday 19 May 2015 18:06:53 Stefan Agner wrote: >> On 2015-05-19 13:50, Arnd Bergmann wrote: >> > Do you have a dependency on patch 10 (the one for EFM32) in your later >> > patches? >> >> Unfortunately, there is a dependency on that patch: I change the default >> of UNCOMPRESS_INCLUDE to debug/uncompress.h for all ARM_SINGLE_ARMV7M >> platforms. Without that patch, it would default to mach/uncompress.h, >> which does not exist for MACH_MXC/SOC_VF610. > > An easy approach would be to list both ARM_SINGLE_ARMV7M and > EFM32 in the UNCOMPRESS_INCLUDE option initially, and then > follow-up with a patch that converts the three other platforms > (efm32, stm32 and lpc18xx) to ARM_SINGLE_ARMV7M and also > change the UNCOMPRESS_INCLUDE statement. > > Note that I've already added both stm32 and lpc18xx to the > UNCOMPRESS_INCLUDE list in the next/soc branch. Afaiks, only ARCH_LPC18XX is in UNCOMPRESS_INCLUDE, probably STM32 doesn't support compressed image/earlyprintk? >> > If not, you can send the other ones to Shawn, so I pull them as >> > a branch, and then I apply that on top of the merges. I have also >> > merged two other ARMv7M platforms for 4.2 now (both in next/soc), >> > so we should do the same change for those as well, and I'd rather >> > apply a patch for that, than merge a branch that is based on >> > next/soc. >> >> I guess, in that case, you need to take the others too? (08/09?) > > I'm fine with that, too. If Shawn thinks the patches are ok, you can > just send all patches you want me to apply in arm-soc based on > the appropriate branches (next/soc, next/dt and next/defconfig, I > presume), and I'll apply them this time. In the future, you should > send all patches to Shawn though. Ok, I will rebase this patchset (06-13) then, send the clocksource patch (07) as a single patch and send the EFM32 convertion patch (10) together with a conversion patch of the other two platforms as a follow-up. -- Stefan
On Tue, 19 May 2015, Stefan Agner wrote: > Ok, I will rebase this patchset (06-13) then, send the clocksource patch > (07) as a single patch and send the EFM32 convertion patch (10) together > with a conversion patch of the other two platforms as a follow-up. Is the clocksource one independent? Then I can just pick it up now and route it through tip. Thanks, tglx
On 2015-05-19 23:32, Thomas Gleixner wrote: > On Tue, 19 May 2015, Stefan Agner wrote: >> Ok, I will rebase this patchset (06-13) then, send the clocksource patch >> (07) as a single patch and send the EFM32 convertion patch (10) together >> with a conversion patch of the other two platforms as a follow-up. > > Is the clocksource one independent? Then I can just pick it up now and > route it through tip. With the current Kconfig symbol setup, both should be selected by other config symbols (CLKSRC_OF by ARM_SINGLE_ARMV7M and CLKSRC_MMIO by ARCH_MXC). Hence yes, this can go independently through tip. -- Stefan
On Tuesday 19 May 2015 23:26:53 Stefan Agner wrote: > On 2015-05-19 20:24, Arnd Bergmann wrote: > > On Tuesday 19 May 2015 18:06:53 Stefan Agner wrote: > >> On 2015-05-19 13:50, Arnd Bergmann wrote: > >> > Do you have a dependency on patch 10 (the one for EFM32) in your later > >> > patches? > >> > >> Unfortunately, there is a dependency on that patch: I change the default > >> of UNCOMPRESS_INCLUDE to debug/uncompress.h for all ARM_SINGLE_ARMV7M > >> platforms. Without that patch, it would default to mach/uncompress.h, > >> which does not exist for MACH_MXC/SOC_VF610. > > > > An easy approach would be to list both ARM_SINGLE_ARMV7M and > > EFM32 in the UNCOMPRESS_INCLUDE option initially, and then > > follow-up with a patch that converts the three other platforms > > (efm32, stm32 and lpc18xx) to ARM_SINGLE_ARMV7M and also > > change the UNCOMPRESS_INCLUDE statement. > > > > Note that I've already added both stm32 and lpc18xx to the > > UNCOMPRESS_INCLUDE list in the next/soc branch. > > Afaiks, only ARCH_LPC18XX is in UNCOMPRESS_INCLUDE, probably STM32 > doesn't support compressed image/earlyprintk? It's actually a bug, and I have sent a patch to add the entry (and was looking at my local tree), but haven't applied the fix to the next/soc branch yet. > >> > If not, you can send the other ones to Shawn, so I pull them as > >> > a branch, and then I apply that on top of the merges. I have also > >> > merged two other ARMv7M platforms for 4.2 now (both in next/soc), > >> > so we should do the same change for those as well, and I'd rather > >> > apply a patch for that, than merge a branch that is based on > >> > next/soc. > >> > >> I guess, in that case, you need to take the others too? (08/09?) > > > > I'm fine with that, too. If Shawn thinks the patches are ok, you can > > just send all patches you want me to apply in arm-soc based on > > the appropriate branches (next/soc, next/dt and next/defconfig, I > > presume), and I'll apply them this time. In the future, you should > > send all patches to Shawn though. > > Ok, I will rebase this patchset (06-13) then, send the clocksource patch > (07) as a single patch and send the EFM32 convertion patch (10) together > with a conversion patch of the other two platforms as a follow-up. Ok, sounds good. Arnd
Hi Stefan, On 19 May 2015 at 23:26, Stefan Agner <stefan@agner.ch> wrote: > On 2015-05-19 20:24, Arnd Bergmann wrote: >> On Tuesday 19 May 2015 18:06:53 Stefan Agner wrote: >>> On 2015-05-19 13:50, Arnd Bergmann wrote: >>> > Do you have a dependency on patch 10 (the one for EFM32) in your later >>> > patches? >>> >>> Unfortunately, there is a dependency on that patch: I change the default >>> of UNCOMPRESS_INCLUDE to debug/uncompress.h for all ARM_SINGLE_ARMV7M >>> platforms. Without that patch, it would default to mach/uncompress.h, >>> which does not exist for MACH_MXC/SOC_VF610. >> >> An easy approach would be to list both ARM_SINGLE_ARMV7M and >> EFM32 in the UNCOMPRESS_INCLUDE option initially, and then >> follow-up with a patch that converts the three other platforms >> (efm32, stm32 and lpc18xx) to ARM_SINGLE_ARMV7M and also >> change the UNCOMPRESS_INCLUDE statement. >> >> Note that I've already added both stm32 and lpc18xx to the >> UNCOMPRESS_INCLUDE list in the next/soc branch. > > Afaiks, only ARCH_LPC18XX is in UNCOMPRESS_INCLUDE, probably STM32 > doesn't support compressed image/earlyprintk? See: http://marc.info/?l=linux-arm-kernel&m=143196230014437&w=2 Seems like Arnd hasn't pushed it to the repo yet, though. >>> > If not, you can send the other ones to Shawn, so I pull them as >>> > a branch, and then I apply that on top of the merges. I have also >>> > merged two other ARMv7M platforms for 4.2 now (both in next/soc), >>> > so we should do the same change for those as well, and I'd rather >>> > apply a patch for that, than merge a branch that is based on >>> > next/soc. >>> >>> I guess, in that case, you need to take the others too? (08/09?) >> >> I'm fine with that, too. If Shawn thinks the patches are ok, you can >> just send all patches you want me to apply in arm-soc based on >> the appropriate branches (next/soc, next/dt and next/defconfig, I >> presume), and I'll apply them this time. In the future, you should >> send all patches to Shawn though. > > Ok, I will rebase this patchset (06-13) then, send the clocksource patch > (07) as a single patch and send the EFM32 convertion patch (10) together > with a conversion patch of the other two platforms as a follow-up. Thanks for fixing up LPC18xx as well. regards, Joachim Eastwood
diff --git a/arch/arm/include/debug/efm32.S b/arch/arm/include/debug/efm32.S index 2265a19..660fa1e 100644 --- a/arch/arm/include/debug/efm32.S +++ b/arch/arm/include/debug/efm32.S @@ -16,7 +16,7 @@ #define UARTn_TXDATA 0x0034 - .macro addruart, rx, tmp + .macro addruart, rx, tmp, tmp2 ldr \rx, =(CONFIG_DEBUG_UART_PHYS) /* diff --git a/arch/arm/kernel/debug.S b/arch/arm/kernel/debug.S index 78c91b5..ea9646c 100644 --- a/arch/arm/kernel/debug.S +++ b/arch/arm/kernel/debug.S @@ -35,7 +35,7 @@ #else /* !CONFIG_MMU */ .macro addruart_current, rx, tmp1, tmp2 - addruart \rx, \tmp1 + addruart \rx, \tmp1, \tmp2 .endm #endif /* CONFIG_MMU */
Remove the needless differences between MMU/!MMU addruart calls. This allows to use the same addruart macro on SoC level. Useful for SoC consisting of multiple CPUs with and without MMU such as Freescale Vybrid. Signed-off-by: Stefan Agner <stefan@agner.ch> --- arch/arm/include/debug/efm32.S | 2 +- arch/arm/kernel/debug.S | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-)