phytec-som-imx6: DCD setup: PLL reduction and video core settings

phytec-som-imx6: DCD setup: PLL reduction and video core settings

[Andreas Pretzsch]

While looking into a maybe boarderline RAM setup on one specific piece
of hardware, I took a closer look at the i.MX6 DDR setup of the Phytec
i.MX6 modules in barebox.
And came across two things that look ... somewhat questionable, maybe
worth a look.

In the very first setup (the DCD) in
    arch/arm/boards/phytec-som-imx6/flash-header-phytec-pfla02.h
there is a block
    wm 32 0x020e0010 0xf00000ff
    wm 32 0x020e0018 0x007F007F
    wm 32 0x020e001c 0x007F007F
    wm 32 0x020c8000 0x80002021
at the end.


The first three (comments about complete register meanings added by me)
    // IOMUX_GPR4 : VDOA, PCIe, VPU, IPU cache setup ; stop acknowledge
    wm 32 0x020e0010 0xf00000ff
    // IOMUX_GPR6 : IPU1 QoS setup
    wm 32 0x020e0018 0x007F007F
    // IOMUX_GPR7 : IPU2 QoS setup
    wm 32 0x020e001c 0x007F007F
do setup some cache attributes of VDOA, IPU, VPU (some of the video
cores) and IPU QoS. Beside accessing two reserved bits in GPR4, they
maybe do not harm, and can be found also in various other board files.
Might be some case of copy-from-copy, no idea.
Not sure if these really should be part of lowest-level memory setup...
Maybe - if at all - in some board-specific setup, given barebox drives a
display.
Also, a quick google search shows the possible origin, and that it has
been removed in some U-Boot branch, leaving it to the Linux kernel:
https://github.com/linksprite/u-boot-acadia1.0-beta/blob/master/u-boot-acadia1.0-beta/patches/0546-ENGR00215515-MX6-Move-IPU-QoS-and-VDOA-IPU-VPU-AXI-C.patch
So maybe more of a cleanup issue.
Not only in the Phytec DCDs, but maybe also the other ones.


What concerns me more is the CPU core clock reduction:
    // CCM_ANALOG_PLL_ARM0 : PLL setup => PLL locked, PLL on,
    //                       bypass off, 396MHz
    // reset default: 0x00013042 => PLL not locked, PLL off, bypass on,
    //                              bypass 24MHz osc as src, pll divider
    //                              for 792MHz
    // 0x80002021 => PLL locked, PLL on, bypass off, pll divider for
    //               396MHz ; Attn.: PLL locked is w/o ; divider for
    //               396MHz is below valid range
    wm 32 0x020c8000 0x80002021
Comments again added by me.

Two things here look questionable to me:
1.) Datasheet says valid divider values are 54-108, so the
    default 0x42=66 is in range, whereas the 0x21=33 is not.
2.) Even if the divider value is legit, the change flow might be not.
    A PLL normally takes some time to lock.

Now, I have not looked yet at the PLL setup and/or scaling code of the
kernel, both wrt PLL change flow as well as dividers. So this might be
ok, and even if only implicitly (like due to some implicit delay after
DCD got parsed).
And obviously it works. "Only" misses a comment whats it does. And only
present in some of the Phytec DCDs, as far as I can see.

But what I like to understand is why ?
I mean, scaling down the i.MX6 to its minimum frequency (half of
default) in the bootloader, to get a maximum stable state, ok. Even if
it extends the bootup time.

But why after all the IOMUX, MMDC and DDR setup is through ?
Probably too late if it is about some PMIC-reset-voltage-scaling issue.
Or some thermal precaution ?

By the way, the above setups goes back through long history, as in
    a540c30 boards: Add phytec-som-imx6
    c5b4f09 ARM:phyFLEX-iMX6 New Ram Timings for Q/DL
    30f29e3 ARM: Add Phytec phyFLEX-i.MX6 board support
and applies to other Phytec i.MX6 boards as well, beside the DL ones.


Any comments on this, maybe also from Phytec ?

Best regards,
  Andreas Pretzsch

-- 

carpe noctem engineering
Ingenieurbuero fuer Hard- & Software-Entwicklung Andreas Pretzsch
Dipl.-Ing. (FH) Andreas Pretzsch        Tel. +49-(0)7307-936088-1
Lange Strasse 28a                       Fax: +49-(0)7307-936088-9
89250 Senden, Germany                   email: apr@cn-eng.de


_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: phytec-som-imx6: DCD setup: PLL reduction and video core settings

[Stefan Christ]

Hi Andreas,

thanks a lot for your detailed write-up. Indeed these register settings are
confusing. 

> What concerns me more is the CPU core clock reduction:
>     // CCM_ANALOG_PLL_ARM0 : PLL setup => PLL locked, PLL on,
>     //                       bypass off, 396MHz
>     // reset default: 0x00013042 => PLL not locked, PLL off, bypass on,
>     //                              bypass 24MHz osc as src, pll divider
>     //                              for 792MHz
>     // 0x80002021 => PLL locked, PLL on, bypass off, pll divider for
>     //               396MHz ; Attn.: PLL locked is w/o ; divider for
>     //               396MHz is below valid range
>     wm 32 0x020c8000 0x80002021
> Comments again added by me.
> 
> Two things here look questionable to me:
> 1.) Datasheet says valid divider values are 54-108, so the
>     default 0x42=66 is in range, whereas the 0x21=33 is not.
> 2.) Even if the divider value is legit, the change flow might be not.
>     A PLL normally takes some time to lock.

We have tracked down the origin of this DCD entry internally. It originated
from a PMIC workaround for the phyFLEX-i.MX6 in an older barebox version which
isn't mainline. It had a comment attached to it, but that was dropped while
bringing the phyFLEX-i.MX6 mainline. We will take a closer look to that issue
next week, whether the fix is still needed or can be resolved differently.

Mit freundlichen Grüßen / Kind regards,
	Stefan Christ

On Fri, Feb 19, 2016 at 08:28:25PM +0100, Andreas Pretzsch wrote:
> While looking into a maybe boarderline RAM setup on one specific piece
> of hardware, I took a closer look at the i.MX6 DDR setup of the Phytec
> i.MX6 modules in barebox.
> And came across two things that look ... somewhat questionable, maybe
> worth a look.
> 
> In the very first setup (the DCD) in
>     arch/arm/boards/phytec-som-imx6/flash-header-phytec-pfla02.h
> there is a block
>     wm 32 0x020e0010 0xf00000ff
>     wm 32 0x020e0018 0x007F007F
>     wm 32 0x020e001c 0x007F007F
>     wm 32 0x020c8000 0x80002021
> at the end.
> 
> 
> The first three (comments about complete register meanings added by me)
>     // IOMUX_GPR4 : VDOA, PCIe, VPU, IPU cache setup ; stop acknowledge
>     wm 32 0x020e0010 0xf00000ff
>     // IOMUX_GPR6 : IPU1 QoS setup
>     wm 32 0x020e0018 0x007F007F
>     // IOMUX_GPR7 : IPU2 QoS setup
>     wm 32 0x020e001c 0x007F007F
> do setup some cache attributes of VDOA, IPU, VPU (some of the video
> cores) and IPU QoS. Beside accessing two reserved bits in GPR4, they
> maybe do not harm, and can be found also in various other board files.
> Might be some case of copy-from-copy, no idea.
> Not sure if these really should be part of lowest-level memory setup...
> Maybe - if at all - in some board-specific setup, given barebox drives a
> display.
> Also, a quick google search shows the possible origin, and that it has
> been removed in some U-Boot branch, leaving it to the Linux kernel:
> https://github.com/linksprite/u-boot-acadia1.0-beta/blob/master/u-boot-acadia1.0-beta/patches/0546-ENGR00215515-MX6-Move-IPU-QoS-and-VDOA-IPU-VPU-AXI-C.patch
> So maybe more of a cleanup issue.
> Not only in the Phytec DCDs, but maybe also the other ones.
> 
> 
> What concerns me more is the CPU core clock reduction:
>     // CCM_ANALOG_PLL_ARM0 : PLL setup => PLL locked, PLL on,
>     //                       bypass off, 396MHz
>     // reset default: 0x00013042 => PLL not locked, PLL off, bypass on,
>     //                              bypass 24MHz osc as src, pll divider
>     //                              for 792MHz
>     // 0x80002021 => PLL locked, PLL on, bypass off, pll divider for
>     //               396MHz ; Attn.: PLL locked is w/o ; divider for
>     //               396MHz is below valid range
>     wm 32 0x020c8000 0x80002021
> Comments again added by me.
> 
> Two things here look questionable to me:
> 1.) Datasheet says valid divider values are 54-108, so the
>     default 0x42=66 is in range, whereas the 0x21=33 is not.
> 2.) Even if the divider value is legit, the change flow might be not.
>     A PLL normally takes some time to lock.
> 
> Now, I have not looked yet at the PLL setup and/or scaling code of the
> kernel, both wrt PLL change flow as well as dividers. So this might be
> ok, and even if only implicitly (like due to some implicit delay after
> DCD got parsed).
> And obviously it works. "Only" misses a comment whats it does. And only
> present in some of the Phytec DCDs, as far as I can see.
> 
> But what I like to understand is why ?
> I mean, scaling down the i.MX6 to its minimum frequency (half of
> default) in the bootloader, to get a maximum stable state, ok. Even if
> it extends the bootup time.
> 
> But why after all the IOMUX, MMDC and DDR setup is through ?
> Probably too late if it is about some PMIC-reset-voltage-scaling issue.
> Or some thermal precaution ?
> 
> By the way, the above setups goes back through long history, as in
>     a540c30 boards: Add phytec-som-imx6
>     c5b4f09 ARM:phyFLEX-iMX6 New Ram Timings for Q/DL
>     30f29e3 ARM: Add Phytec phyFLEX-i.MX6 board support
> and applies to other Phytec i.MX6 boards as well, beside the DL ones.
> 
> 
> Any comments on this, maybe also from Phytec ?
> 
> Best regards,
>   Andreas Pretzsch
> 
> -- 
> 
> carpe noctem engineering
> Ingenieurbuero fuer Hard- & Software-Entwicklung Andreas Pretzsch
> Dipl.-Ing. (FH) Andreas Pretzsch        Tel. +49-(0)7307-936088-1
> Lange Strasse 28a                       Fax: +49-(0)7307-936088-9
> 89250 Senden, Germany                   email: apr@cn-eng.de
> 

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: phytec-som-imx6: DCD setup: PLL reduction and video core settings

[Philipp Zabel]

Am Freitag, den 19.02.2016, 20:28 +0100 schrieb Andreas Pretzsch:
> While looking into a maybe boarderline RAM setup on one specific piece
> of hardware, I took a closer look at the i.MX6 DDR setup of the Phytec
> i.MX6 modules in barebox.
> And came across two things that look ... somewhat questionable, maybe
> worth a look.
> 
> In the very first setup (the DCD) in
>     arch/arm/boards/phytec-som-imx6/flash-header-phytec-pfla02.h
> there is a block
>     wm 32 0x020e0010 0xf00000ff
>     wm 32 0x020e0018 0x007F007F
>     wm 32 0x020e001c 0x007F007F
>     wm 32 0x020c8000 0x80002021
> at the end.
> 
> 
> The first three (comments about complete register meanings added by me)
>     // IOMUX_GPR4 : VDOA, PCIe, VPU, IPU cache setup ; stop acknowledge
>     wm 32 0x020e0010 0xf00000ff
>     // IOMUX_GPR6 : IPU1 QoS setup
>     wm 32 0x020e0018 0x007F007F
>     // IOMUX_GPR7 : IPU2 QoS setup
>     wm 32 0x020e001c 0x007F007F
> do setup some cache attributes of VDOA, IPU, VPU (some of the video
> cores) and IPU QoS. Beside accessing two reserved bits in GPR4, they
> maybe do not harm, and can be found also in various other board files.
> Might be some case of copy-from-copy, no idea.
> Not sure if these really should be part of lowest-level memory setup...
> Maybe - if at all - in some board-specific setup, given barebox drives a
> display.
> Also, a quick google search shows the possible origin, and that it has
> been removed in some U-Boot branch, leaving it to the Linux kernel:
> https://github.com/linksprite/u-boot-acadia1.0-beta/blob/master/u-boot-acadia1.0-beta/patches/0546-ENGR00215515-MX6-Move-IPU-QoS-and-VDOA-IPU-VPU-AXI-C.patch
> So maybe more of a cleanup issue.
> Not only in the Phytec DCDs, but maybe also the other ones.

Also imx6_init_lowlevel() already contains the code to enable the caches
and set the IPU QoS priorities. There is no need to set these up in the
DCD already, so I'd say these should just be dropped.

regards
Philipp


_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox