Message ID | 1420817231-8346-4-git-send-email-bob.mottram@codethink.co.uk |
---|---|
State | Deferred |
Headers | show |
09.01.2015 18:27, Bob Mottram пишет: > Config changes to enable big-endian support. Tested on Jetson TK1. > > Signed-off-by: Bob Mottram <bob.mottram@codethink.co.uk> > --- > arch/arm/mach-tegra/Kconfig | 1 + > arch/arm/mach-tegra/headsmp.S | 3 ++- > 2 files changed, 3 insertions(+), 1 deletion(-) > > diff --git a/arch/arm/mach-tegra/Kconfig b/arch/arm/mach-tegra/Kconfig > index d0be9a1..d8cb963 100644 > --- a/arch/arm/mach-tegra/Kconfig > +++ b/arch/arm/mach-tegra/Kconfig > @@ -2,6 +2,7 @@ menuconfig ARCH_TEGRA > bool "NVIDIA Tegra" if ARCH_MULTI_V7 > select ARCH_REQUIRE_GPIOLIB > select ARCH_SUPPORTS_TRUSTED_FOUNDATIONS > + select ARCH_SUPPORTS_BIG_ENDIAN > select ARM_AMBA > select ARM_GIC > select CLKSRC_MMIO > diff --git a/arch/arm/mach-tegra/headsmp.S b/arch/arm/mach-tegra/headsmp.S > index 2072e73..9896981 100644 > --- a/arch/arm/mach-tegra/headsmp.S > +++ b/arch/arm/mach-tegra/headsmp.S > @@ -1,11 +1,12 @@ > #include <linux/linkage.h> > #include <linux/init.h> > - > +#include <asm/assembler.h> > #include "sleep.h" > > .section ".text.head", "ax" > > ENTRY(tegra_secondary_startup) > + ARM_BE8(setend be) > check_cpu_part_num 0xc09, r8, r9 > bleq v7_invalidate_l1 > b secondary_startup > -- > 2.1.0 > -- > To unsubscribe from this list: send the line "unsubscribe linux-tegra" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Hi, Bob. What about suspend/cpuidle? Won't it make sense to set BE mode in reset handler?
On 09/01/15 15:46, Dmitry Osipenko wrote:
> What about suspend/cpuidle? Won't it make sense to set BE mode in reset handler?
I did try adding:
ARM_BE8(setend be)
to the entry point within reset-handler.S, but to no avail. There are
definitely problems with suspend, which currently I can work around by
turning off ARCH_SUSPEND_POSSIBLE. More investigation is going to be
needed to get the sleep/suspend working.
09.01.2015 19:27, Bob Mottram пишет: > On 09/01/15 15:46, Dmitry Osipenko wrote: >> What about suspend/cpuidle? Won't it make sense to set BE mode in reset handler? > > I did try adding: > > ARM_BE8(setend be) > > to the entry point within reset-handler.S, but to no avail. There are > definitely problems with suspend, which currently I can work around by > turning off ARCH_SUSPEND_POSSIBLE. More investigation is going to be > needed to get the sleep/suspend working. > Yeah, just noticed that it mentioned in cover letter.
On 09/01/15 16:32, Dmitry Osipenko wrote: > 09.01.2015 19:27, Bob Mottram пишет: >> On 09/01/15 15:46, Dmitry Osipenko wrote: >>> What about suspend/cpuidle? Won't it make sense to set BE mode in reset handler? >> >> I did try adding: >> >> ARM_BE8(setend be) >> >> to the entry point within reset-handler.S, but to no avail. There are >> definitely problems with suspend, which currently I can work around by >> turning off ARCH_SUSPEND_POSSIBLE. More investigation is going to be >> needed to get the sleep/suspend working. >> > > Yeah, just noticed that it mentioned in cover letter. I had a look through the code and it was not easy to work out what was going on so skipped over it. We decided to leave it out of the initial submission as we can get a workable system without suspend. The suspend/resume code does make accesses to registers, and all these will need to be found and have the correct endian conversion done (stores will be in big-endian but the hardware registers stay little endian)
09.01.2015 20:14, Ben Dooks пишет: > On 09/01/15 16:32, Dmitry Osipenko wrote: >> 09.01.2015 19:27, Bob Mottram пишет: >>> On 09/01/15 15:46, Dmitry Osipenko wrote: >>>> What about suspend/cpuidle? Won't it make sense to set BE mode in reset handler? >>> >>> I did try adding: >>> >>> ARM_BE8(setend be) >>> >>> to the entry point within reset-handler.S, but to no avail. There are >>> definitely problems with suspend, which currently I can work around by >>> turning off ARCH_SUSPEND_POSSIBLE. More investigation is going to be >>> needed to get the sleep/suspend working. >>> >> >> Yeah, just noticed that it mentioned in cover letter. > > I had a look through the code and it was not easy to work out what > was going on so skipped over it. We decided to leave it out of the > initial submission as we can get a workable system without suspend. > > The suspend/resume code does make accesses to registers, and all > these will need to be found and have the correct endian conversion > done (stores will be in big-endian but the hardware registers stay > little endian) > I fixed cpuidle and suspend for tegra2, it involved fixing reset handler, sleep and l2 cache resume asm code. Also fixed tegra timer and i2c drivers in order to get booting. Unfortunately I don't have tegra3 hw nor support for it in QEMU, however cpuidle should work I suppose. I'll post patches later. https://dl.dropboxusercontent.com/u/3913472/IMG_20150112_202034.jpg
On 12/01/15 18:04, Dmitry Osipenko wrote: > 09.01.2015 20:14, Ben Dooks пишет: >> On 09/01/15 16:32, Dmitry Osipenko wrote: >>> 09.01.2015 19:27, Bob Mottram пишет: >>>> On 09/01/15 15:46, Dmitry Osipenko wrote: >>>>> What about suspend/cpuidle? Won't it make sense to set BE mode in >>>>> reset handler? >>>> >>>> I did try adding: >>>> >>>> ARM_BE8(setend be) >>>> >>>> to the entry point within reset-handler.S, but to no avail. There are >>>> definitely problems with suspend, which currently I can work around by >>>> turning off ARCH_SUSPEND_POSSIBLE. More investigation is going to be >>>> needed to get the sleep/suspend working. >>>> >>> >>> Yeah, just noticed that it mentioned in cover letter. >> >> I had a look through the code and it was not easy to work out what >> was going on so skipped over it. We decided to leave it out of the >> initial submission as we can get a workable system without suspend. >> >> The suspend/resume code does make accesses to registers, and all >> these will need to be found and have the correct endian conversion >> done (stores will be in big-endian but the hardware registers stay >> little endian) >> > I fixed cpuidle and suspend for tegra2, it involved fixing reset > handler, sleep and l2 cache resume asm code. Also fixed tegra timer and > i2c drivers in order to get booting. Unfortunately I don't have tegra3 > hw nor support for it in QEMU, however cpuidle should work I suppose. > I'll post patches later. Thank for this. I suggest submitting directly as there is no need to make a coherent series of these.
On 12/01/15 18:04, Dmitry Osipenko wrote: > I fixed cpuidle and suspend for tegra2, it involved fixing reset > handler, sleep and l2 cache resume asm code. Also fixed tegra timer and > i2c drivers in order to get booting. Unfortunately I don't have tegra3 > hw nor support for it in QEMU, however cpuidle should work I suppose. > I'll post patches later. > > https://dl.dropboxusercontent.com/u/3913472/IMG_20150112_202034.jpg Well done.
On 12/01/15 18:04, Dmitry Osipenko wrote: > 09.01.2015 20:14, Ben Dooks пишет: >> On 09/01/15 16:32, Dmitry Osipenko wrote: >>> 09.01.2015 19:27, Bob Mottram пишет: >>>> On 09/01/15 15:46, Dmitry Osipenko wrote: >>>>> What about suspend/cpuidle? Won't it make sense to set BE mode in >>>>> reset handler? >>>> >>>> I did try adding: >>>> >>>> ARM_BE8(setend be) >>>> >>>> to the entry point within reset-handler.S, but to no avail. There are >>>> definitely problems with suspend, which currently I can work around by >>>> turning off ARCH_SUSPEND_POSSIBLE. More investigation is going to be >>>> needed to get the sleep/suspend working. >>>> >>> >>> Yeah, just noticed that it mentioned in cover letter. >> >> I had a look through the code and it was not easy to work out what >> was going on so skipped over it. We decided to leave it out of the >> initial submission as we can get a workable system without suspend. >> >> The suspend/resume code does make accesses to registers, and all >> these will need to be found and have the correct endian conversion >> done (stores will be in big-endian but the hardware registers stay >> little endian) >> > I fixed cpuidle and suspend for tegra2, it involved fixing reset > handler, sleep and l2 cache resume asm code. Also fixed tegra timer and > i2c drivers in order to get booting. Unfortunately I don't have tegra3 > hw nor support for it in QEMU, however cpuidle should work I suppose. > I'll post patches later. > > https://dl.dropboxusercontent.com/u/3913472/IMG_20150112_202034.jpg Nice. Do you have a patch for those fixes?
19.01.2015 17:26, Bob Mottram пишет: > On 12/01/15 18:04, Dmitry Osipenko wrote: >> 09.01.2015 20:14, Ben Dooks пишет: >>> On 09/01/15 16:32, Dmitry Osipenko wrote: >>>> 09.01.2015 19:27, Bob Mottram пишет: >>>>> On 09/01/15 15:46, Dmitry Osipenko wrote: >>>>>> What about suspend/cpuidle? Won't it make sense to set BE mode in >>>>>> reset handler? >>>>> >>>>> I did try adding: >>>>> >>>>> ARM_BE8(setend be) >>>>> >>>>> to the entry point within reset-handler.S, but to no avail. There are >>>>> definitely problems with suspend, which currently I can work around by >>>>> turning off ARCH_SUSPEND_POSSIBLE. More investigation is going to be >>>>> needed to get the sleep/suspend working. >>>>> >>>> >>>> Yeah, just noticed that it mentioned in cover letter. >>> >>> I had a look through the code and it was not easy to work out what >>> was going on so skipped over it. We decided to leave it out of the >>> initial submission as we can get a workable system without suspend. >>> >>> The suspend/resume code does make accesses to registers, and all >>> these will need to be found and have the correct endian conversion >>> done (stores will be in big-endian but the hardware registers stay >>> little endian) >>> >> I fixed cpuidle and suspend for tegra2, it involved fixing reset >> handler, sleep and l2 cache resume asm code. Also fixed tegra timer and >> i2c drivers in order to get booting. Unfortunately I don't have tegra3 >> hw nor support for it in QEMU, however cpuidle should work I suppose. >> I'll post patches later. >> >> https://dl.dropboxusercontent.com/u/3913472/IMG_20150112_202034.jpg > > Nice. Do you have a patch for those fixes? > Sorry for delay. I have patches locally, need to prepare them. I think some arch code needs to be cleaned first, so it might be some more work. Planning to send this week.
diff --git a/arch/arm/mach-tegra/Kconfig b/arch/arm/mach-tegra/Kconfig index d0be9a1..d8cb963 100644 --- a/arch/arm/mach-tegra/Kconfig +++ b/arch/arm/mach-tegra/Kconfig @@ -2,6 +2,7 @@ menuconfig ARCH_TEGRA bool "NVIDIA Tegra" if ARCH_MULTI_V7 select ARCH_REQUIRE_GPIOLIB select ARCH_SUPPORTS_TRUSTED_FOUNDATIONS + select ARCH_SUPPORTS_BIG_ENDIAN select ARM_AMBA select ARM_GIC select CLKSRC_MMIO diff --git a/arch/arm/mach-tegra/headsmp.S b/arch/arm/mach-tegra/headsmp.S index 2072e73..9896981 100644 --- a/arch/arm/mach-tegra/headsmp.S +++ b/arch/arm/mach-tegra/headsmp.S @@ -1,11 +1,12 @@ #include <linux/linkage.h> #include <linux/init.h> - +#include <asm/assembler.h> #include "sleep.h" .section ".text.head", "ax" ENTRY(tegra_secondary_startup) + ARM_BE8(setend be) check_cpu_part_num 0xc09, r8, r9 bleq v7_invalidate_l1 b secondary_startup
Config changes to enable big-endian support. Tested on Jetson TK1. Signed-off-by: Bob Mottram <bob.mottram@codethink.co.uk> --- arch/arm/mach-tegra/Kconfig | 1 + arch/arm/mach-tegra/headsmp.S | 3 ++- 2 files changed, 3 insertions(+), 1 deletion(-) -- 2.1.0 -- To unsubscribe from this list: send the line "unsubscribe linux-tegra" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html