* [U-Boot] [PATCH 1/2] RFC: arm: add call to cleanup things before jumping into kernel @ 2013-10-03 9:04 Ajay Kumar 2013-10-03 8:58 ` Albert ARIBAUD 2013-10-03 9:04 ` [U-Boot] [PATCH 2/2] RFC: exynos: Disable the display controller when starting Linux Ajay Kumar 0 siblings, 2 replies; 11+ messages in thread From: Ajay Kumar @ 2013-10-03 9:04 UTC (permalink / raw) To: u-boot 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 -- 1.7.12.4 ^ permalink raw reply related [flat|nested] 11+ messages in thread
* [U-Boot] [PATCH 1/2] RFC: arm: add call to cleanup things before jumping into kernel 2013-10-03 9:04 [U-Boot] [PATCH 1/2] RFC: arm: add call to cleanup things before jumping into kernel Ajay Kumar @ 2013-10-03 8:58 ` Albert ARIBAUD 2013-10-03 9:19 ` Ajay kumar 2013-10-03 14:23 ` Simon Glass 2013-10-03 9:04 ` [U-Boot] [PATCH 2/2] RFC: exynos: Disable the display controller when starting Linux Ajay Kumar 1 sibling, 2 replies; 11+ messages in thread From: Albert ARIBAUD @ 2013-10-03 8:58 UTC (permalink / raw) To: u-boot 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, -- Albert. ^ permalink raw reply [flat|nested] 11+ messages in thread
* [U-Boot] [PATCH 1/2] RFC: arm: add call to cleanup things before jumping into kernel 2013-10-03 8:58 ` Albert ARIBAUD @ 2013-10-03 9:19 ` Ajay kumar 2013-10-03 15:44 ` Albert ARIBAUD 2013-10-03 14:23 ` Simon Glass 1 sibling, 1 reply; 11+ messages in thread From: Ajay kumar @ 2013-10-03 9:19 UTC (permalink / raw) To: u-boot 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? > > 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 at lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot > ^ permalink raw reply [flat|nested] 11+ messages in thread
* [U-Boot] [PATCH 1/2] RFC: arm: add call to cleanup things before jumping into kernel 2013-10-03 9:19 ` Ajay kumar @ 2013-10-03 15:44 ` Albert ARIBAUD 2013-10-04 5:56 ` Ajay kumar 0 siblings, 1 reply; 11+ messages in thread From: Albert ARIBAUD @ 2013-10-03 15:44 UTC (permalink / raw) To: 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.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. Amicalement, -- Albert. ^ permalink raw reply [flat|nested] 11+ messages in thread
* [U-Boot] [PATCH 1/2] RFC: arm: add call to cleanup things before jumping into kernel 2013-10-03 15:44 ` Albert ARIBAUD @ 2013-10-04 5:56 ` Ajay kumar 0 siblings, 0 replies; 11+ messages in thread From: Ajay kumar @ 2013-10-04 5:56 UTC (permalink / raw) To: u-boot On Thu, Oct 3, 2013 at 9:14 PM, Albert ARIBAUD <albert.u.boot@aribaud.net>wrote: > 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 at 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* [U-Boot] [PATCH 1/2] RFC: arm: add call to cleanup things before jumping into kernel 2013-10-03 8:58 ` Albert ARIBAUD 2013-10-03 9:19 ` Ajay kumar @ 2013-10-03 14:23 ` Simon Glass 1 sibling, 0 replies; 11+ messages in thread From: Simon Glass @ 2013-10-03 14:23 UTC (permalink / raw) To: u-boot 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* [U-Boot] [PATCH 2/2] RFC: exynos: Disable the display controller when starting Linux 2013-10-03 9:04 [U-Boot] [PATCH 1/2] RFC: arm: add call to cleanup things before jumping into kernel Ajay Kumar 2013-10-03 8:58 ` Albert ARIBAUD @ 2013-10-03 9:04 ` Ajay Kumar 2013-10-03 8:55 ` Albert ARIBAUD 1 sibling, 1 reply; 11+ messages in thread From: Ajay Kumar @ 2013-10-03 9:04 UTC (permalink / raw) To: u-boot 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); +} -- 1.7.12.4 ^ permalink raw reply related [flat|nested] 11+ messages in thread
* [U-Boot] [PATCH 2/2] RFC: exynos: Disable the display controller when starting Linux 2013-10-03 9:04 ` [U-Boot] [PATCH 2/2] RFC: exynos: Disable the display controller when starting Linux Ajay Kumar @ 2013-10-03 8:55 ` Albert ARIBAUD 2013-10-03 9:24 ` Ajay kumar 0 siblings, 1 reply; 11+ messages in thread From: Albert ARIBAUD @ 2013-10-03 8:55 UTC (permalink / raw) To: u-boot 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. ^ permalink raw reply [flat|nested] 11+ messages in thread
* [U-Boot] [PATCH 2/2] RFC: exynos: Disable the display controller when starting Linux 2013-10-03 8:55 ` Albert ARIBAUD @ 2013-10-03 9:24 ` Ajay kumar 2013-10-03 14:21 ` Simon Glass 0 siblings, 1 reply; 11+ messages in thread From: Ajay kumar @ 2013-10-03 9:24 UTC (permalink / raw) To: u-boot +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. > > Amicalement, > -- > Albert. > _______________________________________________ > U-Boot mailing list > U-Boot at lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot > ^ permalink raw reply [flat|nested] 11+ messages in thread
* [U-Boot] [PATCH 2/2] RFC: exynos: Disable the display controller when starting Linux 2013-10-03 9:24 ` Ajay kumar @ 2013-10-03 14:21 ` Simon Glass 2013-10-04 5:52 ` Ajay kumar 0 siblings, 1 reply; 11+ messages in thread From: Simon Glass @ 2013-10-03 14:21 UTC (permalink / raw) To: 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 at lists.denx.de >> http://lists.denx.de/mailman/listinfo/u-boot > > ^ permalink raw reply [flat|nested] 11+ messages in thread
* [U-Boot] [PATCH 2/2] RFC: exynos: Disable the display controller when starting Linux 2013-10-03 14:21 ` Simon Glass @ 2013-10-04 5:52 ` Ajay kumar 0 siblings, 0 replies; 11+ messages in thread From: Ajay kumar @ 2013-10-04 5:52 UTC (permalink / raw) To: 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 at 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 at lists.denx.de > >> http://lists.denx.de/mailman/listinfo/u-boot > > > > > Thanks and regards, Ajay Kumar ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2013-10-04 5:56 UTC | newest] Thread overview: 11+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2013-10-03 9:04 [U-Boot] [PATCH 1/2] RFC: arm: add call to cleanup things before jumping into kernel Ajay Kumar 2013-10-03 8:58 ` Albert ARIBAUD 2013-10-03 9:19 ` Ajay kumar 2013-10-03 15:44 ` Albert ARIBAUD 2013-10-04 5:56 ` Ajay kumar 2013-10-03 14:23 ` Simon Glass 2013-10-03 9:04 ` [U-Boot] [PATCH 2/2] RFC: exynos: Disable the display controller when starting Linux Ajay Kumar 2013-10-03 8:55 ` Albert ARIBAUD 2013-10-03 9:24 ` Ajay kumar 2013-10-03 14:21 ` Simon Glass 2013-10-04 5:52 ` Ajay kumar
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.