[U-Boot] [PATCH 1/2] RFC: arm: add call to cleanup things before jumping into kernel
Add infrasturcture to cleanup any of those architecture related settings done for u-boot, if they can cause problem during kernel boot.
Signed-off-by: Ajay Kumar ajaykumar.rs@samsung.com --- arch/arm/cpu/armv7/cpu.c | 6 ++++++ 1 file changed, 6 insertions(+)
diff --git a/arch/arm/cpu/armv7/cpu.c b/arch/arm/cpu/armv7/cpu.c index 01cdb7e..edf4604 100644 --- a/arch/arm/cpu/armv7/cpu.c +++ b/arch/arm/cpu/armv7/cpu.c @@ -23,6 +23,7 @@ #include <linux/compiler.h>
void __weak cpu_cache_initialization(void){} +void __weak arch_cleanup_before_linux(void){}
int cleanup_before_linux(void) { @@ -35,6 +36,11 @@ int cleanup_before_linux(void) #ifndef CONFIG_SPL_BUILD disable_interrupts(); #endif + /* + * Cleanup any of those architecture related settings done for u-boot, + * if they can cause problem during kernel boot. + */ + arch_cleanup_before_linux();
/* * Turn off I-cache and invalidate it
Hi Ajay,
On Thu, 03 Oct 2013 14:34:19 +0530, Ajay Kumar ajaykumar.rs@samsung.com wrote:
Add infrasturcture to cleanup any of those architecture related settings done for u-boot, if they can cause problem during kernel boot.
Signed-off-by: Ajay Kumar ajaykumar.rs@samsung.com
Regardless to ma question re fixing the issue in U-Boot or Linux: does something prevent using the already existing cleanup_before_linux() function, and if not, what made you choose to create another one instead?
Amicalement,
Hi Albert,
On Thu, Oct 3, 2013 at 2:28 PM, Albert ARIBAUD albert.u.boot@aribaud.netwrote:
Hi Ajay,
On Thu, 03 Oct 2013 14:34:19 +0530, Ajay Kumar ajaykumar.rs@samsung.com wrote:
Add infrasturcture to cleanup any of those architecture related settings done for u-boot, if they can cause problem during kernel boot.
Signed-off-by: Ajay Kumar ajaykumar.rs@samsung.com
Regardless to ma question re fixing the issue in U-Boot or Linux: does something prevent using the already existing cleanup_before_linux() function, and if not, what made you choose to create another one instead?
cleanup_before_linux() generally cleans up things specific to the
processor. I thought of introducing a cleanup function which would allow us to cleanup things which are SOC specific(all SOC under armv7 as per the patch). And, used the same function to cleanup some exynos specific stuff before booting linux. May be, I should have used a different name instead of arch_cleanup_before_linux?
Amicalement,
Albert. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Hi Ajay,
On Thu, 3 Oct 2013 14:49:49 +0530, Ajay kumar ajaynumb@gmail.com wrote:
Hi Albert,
On Thu, Oct 3, 2013 at 2:28 PM, Albert ARIBAUD albert.u.boot@aribaud.netwrote:
Hi Ajay,
On Thu, 03 Oct 2013 14:34:19 +0530, Ajay Kumar ajaykumar.rs@samsung.com wrote:
Add infrasturcture to cleanup any of those architecture related settings done for u-boot, if they can cause problem during kernel boot.
Signed-off-by: Ajay Kumar ajaykumar.rs@samsung.com
Regardless to ma question re fixing the issue in U-Boot or Linux: does something prevent using the already existing cleanup_before_linux() function, and if not, what made you choose to create another one instead?
(fixed quote glitch here that put the start of your reply inside mine.)
cleanup_before_linux() generally cleans up things specific to the processor. I thought of introducing a cleanup function which would allow us to cleanup things which are SOC specific(all SOC under armv7 as per the patch). And, used the same function to cleanup some exynos specific stuff before booting linux. May be, I should have used a different name instead of arch_cleanup_before_linux?
Well, if it is *SoC* specific, then it is not *arch* specific, so yes, the name should be changed. Now, we don't really have a concept of 'SoC-specific' in U-Boot, so board-specific, as suggested by Simon, is the 'next not-too-worst thing'.
Still, don't rush to provide a new patch. According to Simon, the Linux panic was solved and might just not have hit mainline yet; if that is confirmed, then renaming arch_cleanup_before_linux() becomes moot.
Amicalement,
On Thu, Oct 3, 2013 at 9:14 PM, Albert ARIBAUD albert.u.boot@aribaud.netwrote:
Hi Ajay,
On Thu, 3 Oct 2013 14:49:49 +0530, Ajay kumar ajaynumb@gmail.com wrote:
Hi Albert,
On Thu, Oct 3, 2013 at 2:28 PM, Albert ARIBAUD <
albert.u.boot@aribaud.net>wrote:
Hi Ajay,
On Thu, 03 Oct 2013 14:34:19 +0530, Ajay Kumar ajaykumar.rs@samsung.com wrote:
Add infrasturcture to cleanup any of those architecture related
settings
done for u-boot, if they can cause problem during kernel boot.
Signed-off-by: Ajay Kumar ajaykumar.rs@samsung.com
Regardless to ma question re fixing the issue in U-Boot or Linux: does something prevent using the already existing cleanup_before_linux() function, and if not, what made you choose to create another one instead?
(fixed quote glitch here that put the start of your reply inside mine.)
cleanup_before_linux() generally cleans up things specific to the processor. I thought of introducing a cleanup function which would allow us to
cleanup
things which are SOC specific(all SOC under armv7 as per the patch). And, used the same function to cleanup some exynos specific stuff before booting linux. May be, I should have used a different name instead of arch_cleanup_before_linux?
Well, if it is *SoC* specific, then it is not *arch* specific, so yes, the name should be changed. Now, we don't really have a concept of 'SoC-specific' in U-Boot, so board-specific, as suggested by Simon, is the 'next not-too-worst thing'.
Still, don't rush to provide a new patch. According to Simon, the Linux panic was solved and might just not have hit mainline yet; if that is confirmed, then renaming arch_cleanup_before_linux() becomes moot.
Ok. I found the kernel patch:
http://permalink.gmane.org/gmane.comp.video.dri.devel/78840 So, this patch is not needed.
Thanks and Regards, Ajay Kumar
Hi Albert,
On Thu, Oct 3, 2013 at 2:58 AM, Albert ARIBAUD albert.u.boot@aribaud.net wrote:
Hi Ajay,
On Thu, 03 Oct 2013 14:34:19 +0530, Ajay Kumar ajaykumar.rs@samsung.com wrote:
Add infrasturcture to cleanup any of those architecture related settings done for u-boot, if they can cause problem during kernel boot.
Signed-off-by: Ajay Kumar ajaykumar.rs@samsung.com
Regardless to ma question re fixing the issue in U-Boot or Linux: does something prevent using the already existing cleanup_before_linux() function, and if not, what made you choose to create another one instead?
That function is in generic ARM code - I think the intent here is to add something SoC-specific. Perhaps it should be board-specific?
Regards, Simon
If the exynos display controller is still active when Linux starts, then it will result in a kernel panic while FIMD sysmmu driver is getting probed. Calling exynos_fimd_lcd_disable() before jumping into kernel disables the display controller by switching off the windows, hence resolving the kernel panic which arises from sysmmu driver.
Create an Exynos specific definition for the weak function arch_cleanup_before_linux(), and then place the call to exynos_fimd_lcd_disable() inside the overrided definition of arch_cleanup_before_linux().
Signed-off-by: Ajay Kumar ajaykumar.rs@samsung.com Signed-off-by: Simon Glass sjg@chromium.org --- arch/arm/cpu/armv7/exynos/system.c | 9 +++++++++ arch/arm/include/asm/arch-exynos/system.h | 9 +++++++++ drivers/video/exynos_fimd.c | 8 ++++++++ 3 files changed, 26 insertions(+)
diff --git a/arch/arm/cpu/armv7/exynos/system.c b/arch/arm/cpu/armv7/exynos/system.c index ad12445..977169b 100644 --- a/arch/arm/cpu/armv7/exynos/system.c +++ b/arch/arm/cpu/armv7/exynos/system.c @@ -69,3 +69,12 @@ void set_system_display_ctrl(void) else exynos5_set_system_display(); } + +/* + * Cleanup any Exynos specific setting here, + * if they can cause problem during kernel boot. + */ +void arch_cleanup_before_linux(void) +{ + exynos_fimd_lcd_disable(); +} diff --git a/arch/arm/include/asm/arch-exynos/system.h b/arch/arm/include/asm/arch-exynos/system.h index 7e2057c..ed0c984 100644 --- a/arch/arm/include/asm/arch-exynos/system.h +++ b/arch/arm/include/asm/arch-exynos/system.h @@ -40,4 +40,13 @@ struct exynos5_sysreg { void set_usbhost_mode(unsigned int mode); void set_system_display_ctrl(void);
+#ifdef CONFIG_EXYNOS_FB +/* Disable the display */ +void exynos_fimd_lcd_disable(void); +#else +static inline void exynos_fimd_lcd_disable(void) +{ +} +#endif + #endif /* _EXYNOS4_SYSTEM_H */ diff --git a/drivers/video/exynos_fimd.c b/drivers/video/exynos_fimd.c index 8c2de4e..6a13d03 100644 --- a/drivers/video/exynos_fimd.c +++ b/drivers/video/exynos_fimd.c @@ -363,3 +363,11 @@ unsigned long exynos_fimd_calc_fbsize(void) { return pvid->vl_col * pvid->vl_row * (NBITS(pvid->vl_bpix) / 8); } + +void exynos_fimd_lcd_disable(void) +{ + int i; + + for (i = 0; i < 4; i++) + exynos_fimd_window_off(i); +}
Hi Ajay,
On Thu, 03 Oct 2013 14:34:20 +0530, Ajay Kumar ajaykumar.rs@samsung.com wrote:
If the exynos display controller is still active when Linux starts, then it will result in a kernel panic while FIMD sysmmu driver is getting probed. Calling exynos_fimd_lcd_disable() before jumping into kernel disables the display controller by switching off the windows, hence resolving the kernel panic which arises from sysmmu driver.
Create an Exynos specific definition for the weak function arch_cleanup_before_linux(), and then place the call to exynos_fimd_lcd_disable() inside the overrided definition of arch_cleanup_before_linux().
Signed-off-by: Ajay Kumar ajaykumar.rs@samsung.com Signed-off-by: Simon Glass sjg@chromium.org
Why should the fix to this situation be making U-Boot disable the display controller rather than making Linux able to cope with an already active display controller?
Besides, fixing Linux would allow seamless booting displays, without an ugly off-on glitch.
Amicalement,
+Simon Glass
On Thu, Oct 3, 2013 at 2:25 PM, Albert ARIBAUD albert.u.boot@aribaud.netwrote:
Hi Ajay,
On Thu, 03 Oct 2013 14:34:20 +0530, Ajay Kumar ajaykumar.rs@samsung.com wrote:
If the exynos display controller is still active when Linux starts, then it will result in a kernel panic while FIMD sysmmu driver is getting probed. Calling exynos_fimd_lcd_disable() before jumping into kernel disables the display controller by switching off the windows, hence resolving the kernel panic which arises from sysmmu driver.
Create an Exynos specific definition for the weak function arch_cleanup_before_linux(), and then place the call to exynos_fimd_lcd_disable() inside the overrided definition of arch_cleanup_before_linux().
Signed-off-by: Ajay Kumar ajaykumar.rs@samsung.com Signed-off-by: Simon Glass sjg@chromium.org
Why should the fix to this situation be making U-Boot disable the display controller rather than making Linux able to cope with an already active display controller?
Besides, fixing Linux would allow seamless booting displays, without an ugly off-on glitch.
Amicalement,
Albert. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Hi,
On Thu, Oct 3, 2013 at 3:24 AM, Ajay kumar ajaynumb@gmail.com wrote:
+Simon Glass
On Thu, Oct 3, 2013 at 2:25 PM, Albert ARIBAUD albert.u.boot@aribaud.net wrote:
Hi Ajay,
On Thu, 03 Oct 2013 14:34:20 +0530, Ajay Kumar ajaykumar.rs@samsung.com wrote:
If the exynos display controller is still active when Linux starts, then it will result in a kernel panic while FIMD sysmmu driver is getting probed. Calling exynos_fimd_lcd_disable() before jumping into kernel disables the display controller by switching off the windows, hence resolving the kernel panic which arises from sysmmu driver.
Create an Exynos specific definition for the weak function arch_cleanup_before_linux(), and then place the call to exynos_fimd_lcd_disable() inside the overrided definition of arch_cleanup_before_linux().
Signed-off-by: Ajay Kumar ajaykumar.rs@samsung.com Signed-off-by: Simon Glass sjg@chromium.org
Why should the fix to this situation be making U-Boot disable the display controller rather than making Linux able to cope with an already active display controller?
Besides, fixing Linux would allow seamless booting displays, without an ugly off-on glitch.
Yes, I believe this bug was fixed in Linux - Ajay do you know? Perhaps the fix has not been upstreamed yet?
Regards, Simon
Amicalement,
Albert. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Hi Simon,
On Thu, Oct 3, 2013 at 7:51 PM, Simon Glass sjg@chromium.org wrote:
Hi,
On Thu, Oct 3, 2013 at 3:24 AM, Ajay kumar ajaynumb@gmail.com wrote:
+Simon Glass
On Thu, Oct 3, 2013 at 2:25 PM, Albert ARIBAUD <
albert.u.boot@aribaud.net>
wrote:
Hi Ajay,
On Thu, 03 Oct 2013 14:34:20 +0530, Ajay Kumar ajaykumar.rs@samsung.com wrote:
If the exynos display controller is still active when Linux starts, then it will result in a kernel panic while FIMD sysmmu driver is getting probed. Calling exynos_fimd_lcd_disable() before jumping into kernel disables the display controller by switching off the windows, hence resolving the kernel panic which arises from sysmmu driver.
Create an Exynos specific definition for the weak function arch_cleanup_before_linux(), and then place the call to exynos_fimd_lcd_disable() inside the overrided definition of arch_cleanup_before_linux().
Signed-off-by: Ajay Kumar ajaykumar.rs@samsung.com Signed-off-by: Simon Glass sjg@chromium.org
Why should the fix to this situation be making U-Boot disable the display controller rather than making Linux able to cope with an already active display controller?
Besides, fixing Linux would allow seamless booting displays, without an ugly off-on glitch.
Yes, I believe this bug was fixed in Linux - Ajay do you know? Perhaps the fix has not been upstreamed yet?
Regards, Simon
You are right. I found it.
http://permalink.gmane.org/gmane.comp.video.dri.devel/78840 This patch would be resent in next series of iommu patches. So, we would not need the u-boot patch anymore!
Amicalement,
Albert. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Thanks and regards, Ajay Kumar
participants (4)
-
Ajay Kumar -
Ajay kumar -
Albert ARIBAUD -
Simon Glass