[U-Boot] [PATCH] Revert "sunxi: dram: Use divisor P=1 for PLL5"

[U-Boot] [PATCH] Revert "sunxi: dram: Use divisor P=1 for PLL5"

[Hans de Goede]

This change breaks various hardcoded assumptions in the linux-sunxi-3.4
kernels, causing a divide by 0 error in the linux-sunxi-3.4 nand driver,
rendering 3.4 kernels unbootable. Besides this problem, it also breaks LCD
output (on devices without nand).

Fixes for these issues are being added to the linux-sunxi-3.4 kernel, but for
now it seems better to revert this.

This reverts commit 013f2d746955147439215a4939655c9ed6bdd866.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
 arch/arm/cpu/armv7/sunxi/dram.c | 28 +++++++++++++++++-----------
 1 file changed, 17 insertions(+), 11 deletions(-)

diff --git a/arch/arm/cpu/armv7/sunxi/dram.c b/arch/arm/cpu/armv7/sunxi/dram.c
index 584f742..8c4dd51 100644
--- a/arch/arm/cpu/armv7/sunxi/dram.c
+++ b/arch/arm/cpu/armv7/sunxi/dram.c
@@ -256,7 +256,7 @@ static void mctl_setup_dram_clock(u32 clk, u32 mbus_clk)
 	/* PLL5P and PLL6 are the potential clock sources for MBUS */
 	u32 pll6x_div, pll5p_div;
 	u32 pll6x_clk = clock_get_pll6() / 1000000;
-	u32 pll5p_clk = clk / 24 * 48;
+	u32 pll5p_clk = clk / 24 * 24;
 	u32 pll5p_rate, pll6x_rate;
 #ifdef CONFIG_SUN7I
 	pll6x_clk *= 2; /* sun7i uses PLL6*2, sun5i uses just PLL6 */
@@ -269,40 +269,46 @@ static void mctl_setup_dram_clock(u32 clk, u32 mbus_clk)
 	reg_val &= ~CCM_PLL5_CTRL_N_MASK;		/* set N to 0 (x0) */
 	reg_val &= ~CCM_PLL5_CTRL_P_MASK;		/* set P to 0 (x1) */
 	if (clk >= 540 && clk < 552) {
-		/* dram = 540MHz, pll5p = 1080MHz */
-		pll5p_clk = 1080;
+		/* dram = 540MHz, pll5p = 540MHz */
+		pll5p_clk = 540;
 		reg_val |= CCM_PLL5_CTRL_M(CCM_PLL5_CTRL_M_X(2));
 		reg_val |= CCM_PLL5_CTRL_K(CCM_PLL5_CTRL_K_X(3));
 		reg_val |= CCM_PLL5_CTRL_N(CCM_PLL5_CTRL_N_X(15));
+		reg_val |= CCM_PLL5_CTRL_P(1);
 	} else if (clk >= 512 && clk < 528) {
-		/* dram = 512MHz, pll5p = 1536MHz */
-		pll5p_clk = 1536;
+		/* dram = 512MHz, pll5p = 384MHz */
+		pll5p_clk = 384;
 		reg_val |= CCM_PLL5_CTRL_M(CCM_PLL5_CTRL_M_X(3));
 		reg_val |= CCM_PLL5_CTRL_K(CCM_PLL5_CTRL_K_X(4));
 		reg_val |= CCM_PLL5_CTRL_N(CCM_PLL5_CTRL_N_X(16));
+		reg_val |= CCM_PLL5_CTRL_P(2);
 	} else if (clk >= 496 && clk < 504) {
-		/* dram = 496MHz, pll5p = 1488MHz */
-		pll5p_clk = 1488;
+		/* dram = 496MHz, pll5p = 372MHz */
+		pll5p_clk = 372;
 		reg_val |= CCM_PLL5_CTRL_M(CCM_PLL5_CTRL_M_X(3));
 		reg_val |= CCM_PLL5_CTRL_K(CCM_PLL5_CTRL_K_X(2));
 		reg_val |= CCM_PLL5_CTRL_N(CCM_PLL5_CTRL_N_X(31));
+		reg_val |= CCM_PLL5_CTRL_P(2);
 	} else if (clk >= 468 && clk < 480) {
-		/* dram = 468MHz, pll5p = 936MHz */
-		pll5p_clk = 936;
+		/* dram = 468MHz, pll5p = 468MHz */
+		pll5p_clk = 468;
 		reg_val |= CCM_PLL5_CTRL_M(CCM_PLL5_CTRL_M_X(2));
 		reg_val |= CCM_PLL5_CTRL_K(CCM_PLL5_CTRL_K_X(3));
 		reg_val |= CCM_PLL5_CTRL_N(CCM_PLL5_CTRL_N_X(13));
+		reg_val |= CCM_PLL5_CTRL_P(1);
 	} else if (clk >= 396 && clk < 408) {
-		/* dram = 396MHz, pll5p = 792MHz */
-		pll5p_clk = 792;
+		/* dram = 396MHz, pll5p = 396MHz */
+		pll5p_clk = 396;
 		reg_val |= CCM_PLL5_CTRL_M(CCM_PLL5_CTRL_M_X(2));
 		reg_val |= CCM_PLL5_CTRL_K(CCM_PLL5_CTRL_K_X(3));
 		reg_val |= CCM_PLL5_CTRL_N(CCM_PLL5_CTRL_N_X(11));
+		reg_val |= CCM_PLL5_CTRL_P(1);
 	} else 	{
 		/* any other frequency that is a multiple of 24 */
 		reg_val |= CCM_PLL5_CTRL_M(CCM_PLL5_CTRL_M_X(2));
 		reg_val |= CCM_PLL5_CTRL_K(CCM_PLL5_CTRL_K_X(2));
 		reg_val |= CCM_PLL5_CTRL_N(CCM_PLL5_CTRL_N_X(clk / 24));
+		reg_val |= CCM_PLL5_CTRL_P(CCM_PLL5_CTRL_P_X(2));
 	}
 	reg_val &= ~CCM_PLL5_CTRL_VCO_GAIN;		/* PLL VCO Gain off */
 	reg_val |= CCM_PLL5_CTRL_EN;			/* PLL On */
-- 
2.1.0

[U-Boot] [PATCH] Revert "sunxi: dram: Use divisor P=1 for PLL5"

[Siarhei Siamashka]

On Wed, 15 Oct 2014 12:12:11 +0200
Hans de Goede <hdegoede@redhat.com> wrote:

> This change breaks various hardcoded assumptions in the linux-sunxi-3.4
> kernels, causing a divide by 0 error in the linux-sunxi-3.4 nand driver,
> rendering 3.4 kernels unbootable. Besides this problem, it also breaks LCD
> output (on devices without nand).
> 
> Fixes for these issues are being added to the linux-sunxi-3.4 kernel, but for
> now it seems better to revert this.
> 
> This reverts commit 013f2d746955147439215a4939655c9ed6bdd866.

As mentioned in the commit message
    https://www.mail-archive.com/linux-sunxi at googlegroups.com/msg07884.html
the hardcoded assumptions in the sunxi-3.4 kernel are still bad
with or without this revert if somebody tries to use higher DRAM
clock speeds.

The patch in question just smokes out bugs, which are otherwise still
there.

Going forward, the mainline kernel needs the G2D driver and it needs
to run at a decent clock speed to be provide reasonable performance.
Low PLL5P clock speed is limiting our options.

This revert does not do anyone any favour and only postpones the
resolution of the problem.

-- 
Best regards,
Siarhei Siamashka

[U-Boot] [PATCH] Revert "sunxi: dram: Use divisor P=1 for PLL5"

[Hans de Goede]

Hi,

On 10/15/2014 12:34 PM, Siarhei Siamashka wrote:
> On Wed, 15 Oct 2014 12:12:11 +0200
> Hans de Goede <hdegoede@redhat.com> wrote:
> 
>> This change breaks various hardcoded assumptions in the linux-sunxi-3.4
>> kernels, causing a divide by 0 error in the linux-sunxi-3.4 nand driver,
>> rendering 3.4 kernels unbootable. Besides this problem, it also breaks LCD
>> output (on devices without nand).
>>
>> Fixes for these issues are being added to the linux-sunxi-3.4 kernel, but for
>> now it seems better to revert this.
>>
>> This reverts commit 013f2d746955147439215a4939655c9ed6bdd866.
> 
> As mentioned in the commit message
>     https://www.mail-archive.com/linux-sunxi at googlegroups.com/msg07884.html
> the hardcoded assumptions in the sunxi-3.4 kernel are still bad
> with or without this revert if somebody tries to use higher DRAM
> clock speeds.
> 
> The patch in question just smokes out bugs, which are otherwise still
> there.
> 
> Going forward, the mainline kernel needs the G2D driver and it needs
> to run at a decent clock speed to be provide reasonable performance.
> Low PLL5P clock speed is limiting our options.
> 
> This revert does not do anyone any favour and only postpones the
> resolution of the problem.

I agree that we need to fix the linux-sunxi-3.4 kernels to work properly with
different pll5 settings, which is why I've actually send a fix for some pll5
issues to the linux-sunxi list and acked your patches which fix other bits.

I can understand you want to have optimal settings for the G2D stuff, and I'm
not against that. But getting the G2D stuff upstream is something which
is still far in the future. I really want people to be able to start using
upstream u-boot, starting today. And it will take some time for the sunxi-3.4
fixes to trickle down to users.

So for now I believe we really should revert the PLL5 u-boot changes as they
break some kernels from booting.

Then once getting G2D support upstream really comes into the picture
(e.g. upstream kernel patches are posted and being reviewed), then we can talk
about re-applying the PLL5 changes, but for now I believe that reverting them
is best.

Regards,

Hans

[U-Boot] [PATCH] Revert "sunxi: dram: Use divisor P=1 for PLL5"

[Ian Campbell]

On Thu, 2014-10-16 at 10:48 +0200, Hans de Goede wrote:

> So for now I believe we really should revert the PLL5 u-boot changes as they
> break some kernels from booting.

This seems reasonable to me.

Acked-by: Ian Campbell <ijc@hellion.org.uk>

> 
> Then once getting G2D support upstream really comes into the picture
> (e.g. upstream kernel patches are posted and being reviewed), then we can talk
> about re-applying the PLL5 changes, but for now I believe that reverting them
> is best.
> 
> Regards,
> 
> Hans
> 
> 
> 
> 
> 
> 
> 

[U-Boot] [PATCH] Revert "sunxi: dram: Use divisor P=1 for PLL5"

[Siarhei Siamashka]

On Thu, 16 Oct 2014 10:48:34 +0200
Hans de Goede <hdegoede@redhat.com> wrote:

> Hi,
> 
> On 10/15/2014 12:34 PM, Siarhei Siamashka wrote:
> > On Wed, 15 Oct 2014 12:12:11 +0200
> > Hans de Goede <hdegoede@redhat.com> wrote:
> > 
> >> This change breaks various hardcoded assumptions in the linux-sunxi-3.4
> >> kernels, causing a divide by 0 error in the linux-sunxi-3.4 nand driver,
> >> rendering 3.4 kernels unbootable. Besides this problem, it also breaks LCD
> >> output (on devices without nand).
> >>
> >> Fixes for these issues are being added to the linux-sunxi-3.4 kernel, but for
> >> now it seems better to revert this.
> >>
> >> This reverts commit 013f2d746955147439215a4939655c9ed6bdd866.
> > 
> > As mentioned in the commit message
> >     https://www.mail-archive.com/linux-sunxi at googlegroups.com/msg07884.html
> > the hardcoded assumptions in the sunxi-3.4 kernel are still bad
> > with or without this revert if somebody tries to use higher DRAM
> > clock speeds.
> > 
> > The patch in question just smokes out bugs, which are otherwise still
> > there.
> > 
> > Going forward, the mainline kernel needs the G2D driver and it needs
> > to run at a decent clock speed to be provide reasonable performance.
> > Low PLL5P clock speed is limiting our options.
> > 
> > This revert does not do anyone any favour and only postpones the
> > resolution of the problem.
> 
> I agree that we need to fix the linux-sunxi-3.4 kernels to work properly with
> different pll5 settings, which is why I've actually send a fix for some pll5
> issues to the linux-sunxi list and acked your patches which fix other bits.
> 
> I can understand you want to have optimal settings for the G2D stuff, and I'm
> not against that. But getting the G2D stuff upstream is something which
> is still far in the future.

The future is happening right now ;-)

Luc has implemented the HDMI support in u-boot and ensured that it
works with the simplefb driver, providing framebuffer in the mainline
kernel. This has code has been available for several months for any
geeks, willing to fish out and cherry pick the patches. But right now
this needs to be more easily available for the users and developers.

The mainline kernel got all the basic essentials and has been ready
for the graphics and multimedia since around version 3.16

As anyone can see, the sunxi-3.4 kernel provides a rather rotten
foundation. And even though we have a reasonably good support for
both proprietary and free reverse engineered drivers with sunxi-3.4,
it still makes a lot of sense to get the graphics drivers in the
mainline kernel ASAP.

> I really want people to be able to start using upstream u-boot, starting
> today. And it will take some time for the sunxi-3.4 fixes to trickle down to
> users.
> 
> So for now I believe we really should revert the PLL5 u-boot changes as they
> break some kernels from booting.
> 
> Then once getting G2D support upstream really comes into the picture
> (e.g. upstream kernel patches are posted and being reviewed), then we can talk
> about re-applying the PLL5 changes, but for now I believe that reverting them
> is best.

You are the boss. We are all free to have our own private branches
anyway.

-- 
Best regards,
Siarhei Siamashka

[U-Boot] [PATCH] Revert "sunxi: dram: Use divisor P=1 for PLL5"

[Jeroen Hofstee]

Hi Hans,

On 16-10-14 10:48, Hans de Goede wrote:
> [snip]
>
> So for now I believe we really should revert the PLL5 u-boot changes as they
> break some kernels from booting.
>

U-boot and the kernel should be independent. Hence u-boot cannot
break kernels from booting or the kernel is bugged and should be fixed.

Regards,
Jeroen

[U-Boot] [PATCH] Revert "sunxi: dram: Use divisor P=1 for PLL5"

[Tom Rini]

On Thu, Oct 16, 2014 at 10:48:34AM +0200, Hans de Goede wrote:
> Hi,
> 
> On 10/15/2014 12:34 PM, Siarhei Siamashka wrote:
> > On Wed, 15 Oct 2014 12:12:11 +0200
> > Hans de Goede <hdegoede@redhat.com> wrote:
> > 
> >> This change breaks various hardcoded assumptions in the linux-sunxi-3.4
> >> kernels, causing a divide by 0 error in the linux-sunxi-3.4 nand driver,
> >> rendering 3.4 kernels unbootable. Besides this problem, it also breaks LCD
> >> output (on devices without nand).
> >>
> >> Fixes for these issues are being added to the linux-sunxi-3.4 kernel, but for
> >> now it seems better to revert this.
> >>
> >> This reverts commit 013f2d746955147439215a4939655c9ed6bdd866.
> > 
> > As mentioned in the commit message
> >     https://www.mail-archive.com/linux-sunxi at googlegroups.com/msg07884.html
> > the hardcoded assumptions in the sunxi-3.4 kernel are still bad
> > with or without this revert if somebody tries to use higher DRAM
> > clock speeds.
> > 
> > The patch in question just smokes out bugs, which are otherwise still
> > there.
> > 
> > Going forward, the mainline kernel needs the G2D driver and it needs
> > to run at a decent clock speed to be provide reasonable performance.
> > Low PLL5P clock speed is limiting our options.
> > 
> > This revert does not do anyone any favour and only postpones the
> > resolution of the problem.
> 
> I agree that we need to fix the linux-sunxi-3.4 kernels to work properly with
> different pll5 settings, which is why I've actually send a fix for some pll5
> issues to the linux-sunxi list and acked your patches which fix other bits.
> 
> I can understand you want to have optimal settings for the G2D stuff, and I'm
> not against that. But getting the G2D stuff upstream is something which
> is still far in the future. I really want people to be able to start using
> upstream u-boot, starting today. And it will take some time for the sunxi-3.4
> fixes to trickle down to users.

We should be doing things right, in mainline.  To bring up a different
example, on TI OMAP4 parts at least for a long time in order to use
mainline U-Boot on older kernels you had to manually add
CONFIG_SOMETHING_OR_ANOTHER to enable additional clocks/mux that the old
kernels had incorrectly relied on U-Boot to set.  If we must do strange
things to support old and incorrect but in the wild kernels we need to
(a) make it opt-in (easier now with Kconfig!) and (b) schedule a removal
of the hack all the same.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20141021/e8b8ad48/attachment.pgp>

[U-Boot] [PATCH] Revert "sunxi: dram: Use divisor P=1 for PLL5"

[Ian Campbell]

On Tue, 2014-10-21 at 16:58 -0400, Tom Rini wrote:
> We should be doing things right, in mainline.  To bring up a different
> example, on TI OMAP4 parts at least for a long time in order to use
> mainline U-Boot on older kernels you had to manually add
> CONFIG_SOMETHING_OR_ANOTHER to enable additional clocks/mux that the old
> kernels had incorrectly relied on U-Boot to set.  If we must do strange
> things to support old and incorrect but in the wild kernels we need to
> (a) make it opt-in (easier now with Kconfig!) and (b) schedule a removal
> of the hack all the same.

A Kconfig option does sound like a reasonable compromise.

Ian.

[U-Boot] [PATCH] Revert "sunxi: dram: Use divisor P=1 for PLL5"

[Hans de Goede]

Hi,

On 10/22/2014 10:14 AM, Ian Campbell wrote:
> On Tue, 2014-10-21 at 16:58 -0400, Tom Rini wrote:
>> We should be doing things right, in mainline.  To bring up a different
>> example, on TI OMAP4 parts at least for a long time in order to use
>> mainline U-Boot on older kernels you had to manually add
>> CONFIG_SOMETHING_OR_ANOTHER to enable additional clocks/mux that the old
>> kernels had incorrectly relied on U-Boot to set.  If we must do strange
>> things to support old and incorrect but in the wild kernels we need to
>> (a) make it opt-in (easier now with Kconfig!) and (b) schedule a removal
>> of the hack all the same.
> 
> A Kconfig option does sound like a reasonable compromise.

Ok, I will look into this, my plan for now is to call it OLD_KERNEL_COMPAT,
so that if we come across more cases like this we've one config option for
them, rather then a ton of small isolated config options.

Regards,

Hans

[U-Boot] [PATCH] Revert "sunxi: dram: Use divisor P=1 for PLL5"

[Ian Campbell]

On Wed, 2014-10-22 at 10:35 +0200, Hans de Goede wrote:
> Hi,
> 
> On 10/22/2014 10:14 AM, Ian Campbell wrote:
> > On Tue, 2014-10-21 at 16:58 -0400, Tom Rini wrote:
> >> We should be doing things right, in mainline.  To bring up a different
> >> example, on TI OMAP4 parts at least for a long time in order to use
> >> mainline U-Boot on older kernels you had to manually add
> >> CONFIG_SOMETHING_OR_ANOTHER to enable additional clocks/mux that the old
> >> kernels had incorrectly relied on U-Boot to set.  If we must do strange
> >> things to support old and incorrect but in the wild kernels we need to
> >> (a) make it opt-in (easier now with Kconfig!) and (b) schedule a removal
> >> of the hack all the same.
> > 
> > A Kconfig option does sound like a reasonable compromise.
> 
> Ok, I will look into this, my plan for now is to call it OLD_KERNEL_COMPAT,
> so that if we come across more cases like this we've one config option for
> them, rather then a ton of small isolated config options.

Is it particular to "old" kernels as such, or is it more to do with
Allwinner SDK (and derived) kernels? Is it worth trying to keep
workarounds for such kernels separated from workarounds for old mainline
kernels?

Ian.

[U-Boot] [PATCH] Revert "sunxi: dram: Use divisor P=1 for PLL5"

[Hans de Goede]

Hi,

On 10/22/2014 11:19 AM, Ian Campbell wrote:
> On Wed, 2014-10-22 at 10:35 +0200, Hans de Goede wrote:
>> Hi,
>>
>> On 10/22/2014 10:14 AM, Ian Campbell wrote:
>>> On Tue, 2014-10-21 at 16:58 -0400, Tom Rini wrote:
>>>> We should be doing things right, in mainline.  To bring up a different
>>>> example, on TI OMAP4 parts at least for a long time in order to use
>>>> mainline U-Boot on older kernels you had to manually add
>>>> CONFIG_SOMETHING_OR_ANOTHER to enable additional clocks/mux that the old
>>>> kernels had incorrectly relied on U-Boot to set.  If we must do strange
>>>> things to support old and incorrect but in the wild kernels we need to
>>>> (a) make it opt-in (easier now with Kconfig!) and (b) schedule a removal
>>>> of the hack all the same.
>>>
>>> A Kconfig option does sound like a reasonable compromise.
>>
>> Ok, I will look into this, my plan for now is to call it OLD_KERNEL_COMPAT,
>> so that if we come across more cases like this we've one config option for
>> them, rather then a ton of small isolated config options.
> 
> Is it particular to "old" kernels as such, or is it more to do with
> Allwinner SDK (and derived) kernels? Is it worth trying to keep
> workarounds for such kernels separated from workarounds for old mainline
> kernels?

AFAIK the first mainline kernels with sunxi support are recent enough that they
don't need any workarounds. TBH I don't think differentiating between the 2
brings us anything.

Regards,

Hans

[U-Boot] [PATCH] Revert "sunxi: dram: Use divisor P=1 for PLL5"

[Ian Campbell]

On Wed, 2014-10-22 at 11:26 +0200, Hans de Goede wrote:
> Hi,
> 
> On 10/22/2014 11:19 AM, Ian Campbell wrote:
> > On Wed, 2014-10-22 at 10:35 +0200, Hans de Goede wrote:
> >> Hi,
> >>
> >> On 10/22/2014 10:14 AM, Ian Campbell wrote:
> >>> On Tue, 2014-10-21 at 16:58 -0400, Tom Rini wrote:
> >>>> We should be doing things right, in mainline.  To bring up a different
> >>>> example, on TI OMAP4 parts at least for a long time in order to use
> >>>> mainline U-Boot on older kernels you had to manually add
> >>>> CONFIG_SOMETHING_OR_ANOTHER to enable additional clocks/mux that the old
> >>>> kernels had incorrectly relied on U-Boot to set.  If we must do strange
> >>>> things to support old and incorrect but in the wild kernels we need to
> >>>> (a) make it opt-in (easier now with Kconfig!) and (b) schedule a removal
> >>>> of the hack all the same.
> >>>
> >>> A Kconfig option does sound like a reasonable compromise.
> >>
> >> Ok, I will look into this, my plan for now is to call it OLD_KERNEL_COMPAT,
> >> so that if we come across more cases like this we've one config option for
> >> them, rather then a ton of small isolated config options.
> > 
> > Is it particular to "old" kernels as such, or is it more to do with
> > Allwinner SDK (and derived) kernels? Is it worth trying to keep
> > workarounds for such kernels separated from workarounds for old mainline
> > kernels?
> 
> AFAIK the first mainline kernels with sunxi support are recent enough that they
> don't need any workarounds. TBH I don't think differentiating between the 2
> brings us anything.

OK.

Ian.