[U-Boot] [PATCH 2/2] RFC: exynos: Disable the display controller when starting Linux

[U-Boot] [PATCH 2/2] RFC: exynos: Disable the display controller when starting Linux

[Albert ARIBAUD]

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] [PATCH 1/2] RFC: arm: add call to cleanup things before jumping into kernel

[Albert ARIBAUD]

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.

[U-Boot] [PATCH 1/2] RFC: arm: add call to cleanup things before jumping into kernel

[Ajay Kumar]

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

[U-Boot] [PATCH 2/2] RFC: exynos: Disable the display controller when starting Linux

[Ajay Kumar]

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

[U-Boot] [PATCH 1/2] RFC: arm: add call to cleanup things before jumping into kernel

[Ajay kumar]

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
>

[U-Boot] [PATCH 2/2] RFC: exynos: Disable the display controller when starting Linux

[Ajay kumar]

+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
>

[U-Boot] [PATCH 2/2] RFC: exynos: Disable the display controller when starting Linux

[Simon Glass]

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
>
>

[U-Boot] [PATCH 1/2] RFC: arm: add call to cleanup things before jumping into kernel

[Simon Glass]

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

[U-Boot] [PATCH 1/2] RFC: arm: add call to cleanup things before jumping into kernel

[Albert ARIBAUD]

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.

[U-Boot] [PATCH 2/2] RFC: exynos: Disable the display controller when starting Linux

[Ajay kumar]

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

[U-Boot] [PATCH 1/2] RFC: arm: add call to cleanup things before jumping into kernel

[Ajay kumar]

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