ppc460: read get_sys_info from CPR registers instead of STRP registers

This code has been changed to read the CPU speed information from the CPR registers rather than the bootstrap registers. This is useful when changing the clock speed to something other than the default on boot.

---
 arch/powerpc/cpu/ppc4xx/speed.c        |   33 +++++++++++++------------------
 arch/powerpc/include/asm/ppc460ex_gt.h |   15 +++++++++++++-
 2 files changed, 28 insertions(+), 20 deletions(-)

index 09d6671..2643fc0 100644
@@ -328,38 +328,33 @@ void get_sys_info(sys_info_t *sysInfo)
  */
 void get_sys_info (sys_info_t * sysInfo)
 {
-	unsigned long strp0;
-	unsigned long strp1;
+	unsigned long pllc, plld, plbed, opbd, perd;
 	unsigned long temp;
 	unsigned long m;
 	unsigned long plbedv0;
 
 	/* Extract configured divisors */
-	mfsdr(SDR0_SDSTP0, strp0);
-	mfsdr(SDR0_SDSTP1, strp1);
-
-	temp = ((strp0 & PLLSYS0_FWD_DIV_A_MASK) >> 4);
-	sysInfo->pllFwdDivA = get_cpr0_fwdv(temp);
-
-	temp = (strp0 & PLLSYS0_FWD_DIV_B_MASK);
-	sysInfo->pllFwdDivB = get_cpr0_fwdv(temp);
 
-	temp = (strp0 & PLLSYS0_FB_DIV_MASK) >> 8;
-	sysInfo->pllFbkDiv = get_cpr0_fbdv(temp);
+	mfcpr(CPR0_PLLD, plld);
+	sysInfo->pllFwdDivA = get_cpr0_fwdv((plld & PLLD_FWDVA_MASK) >> 16);
+	sysInfo->pllFwdDivB = get_cpr0_fwdv((plld & PLLD_FWDVB_MASK) >> 8);
+	sysInfo->pllFbkDiv = get_cpr0_fbdv((plld & PLLD_FBDV_MASK) >> 24);
 
-	temp = (strp1 & PLLSYS0_OPB_DIV_MASK) >> 26;
+	mfcpr(CPR0_OPBD0, opbd);
+	temp = ((opbd & OPBDV_MASK) >> 24);
 	sysInfo->pllOpbDiv = temp ? temp : 4;
 
-	/* AMCC_TODO: verify the SDR0_SDSTP1.PERDV0 value sysInfo->pllExtBusDiv */
-	temp = (strp1 & PLLSYS0_PERCLK_DIV_MASK) >> 24;
+	mfcpr(CPR0_PERD, perd);
+	temp = ((perd & PERDV_MASK) >> 24);
 	sysInfo->pllExtBusDiv = temp ? temp : 4;
 
-	temp = (strp1 & PLLSYS0_PLBEDV0_DIV_MASK) >> 29;
-	plbedv0 = temp ? temp: 8;
+	mfcpr(CPR0_PLBED, plbed);
+	temp = ((plbed & PLBEDDV_MASK) >> 24);
+	plbedv0 = temp ? temp : 8;
 
 	/* Calculate 'M' based on feedback source */
-	temp = (strp0 & PLLSYS0_SEL_MASK) >> 27;
-	if (temp == 0) {
+	mfcpr(CPR0_PLLC, pllc);
+	if (((pllc & PLLC_FBSEL_MASK) >> 24) == 0) {
 		/* PLL internal feedback */
 		m = sysInfo->pllFbkDiv;
 	} else {

index 732fcac..cff22ad 100644
@@ -211,11 +211,24 @@
 #define PLLSYS0_PERCLK_DIV_MASK 0x03000000	/* Peripheral Clk Divisor */
 #define PLLSYS0_SEL_MASK	0x18000000	/* 0 = PLL, 1 = PerClk */
 
-#define CPR0_ICFG_RLI_MASK	0x80000000
+#define CPR0_PLBED		0x00000080 /* PLL PLB Early Clock Divider */
+
+#define CPR0_ICFG_RLI_MASK	0x80000000 /* CPR Reset Load Inhibit */
 
 #define CPR0_PLLC_RST		0x80000000
 #define CPR0_PLLC_ENG		0x40000000
 
+#define PLLC_FBSEL_MASK		0x03000000 /* PLLC Feedback Selection */
+
+#define PLLD_FBDV_MASK		0xff000000 /* PLL Feedback Divisor  */
+#define PLLD_FWDVA_MASK		0x000f0000 /* PLL Forward Divisor A */
+#define PLLD_FWDVB_MASK		0x00000700 /* PLL Forward Divisor B */
+
+#define PLBEDDV_MASK		0x07000000 /* PLB Early Divisor */
+#define OPBDV_MASK		0x03000000 /* OPB Clock Divisor */
+#define PERDV_MASK		0x03000000 /* Peripheral Clock Divisor */
+#define SPCID_MASK		0x03000000 /* Sync PCI Divisor  */
+
 #define PCIL0_BRDGOPT1		(PCIL0_CFGBASE + 0x0040)
 #define PCIL0_BRDGOPT2		(PCIL0_CFGBASE + 0x0044)
 

1.7.3.4

Hi Mike,

Thanks. Unfortunately this patch introduces compile errors for 460SX boards (e.g. redwood):

[stefan at kubuntu u-boot-ppc4xx (master)]$ ./MAKEALL redwood Configuring for redwood board...
speed.c: In function 'get_sys_info':
speed.c:339: error: 'PLLD_FWDVA_MASK' undeclared (first use in this function) speed.c:339: error: (Each undeclared identifier is reported only once speed.c:339: error: for each function it appears in.) speed.c:340: error: 'PLLD_FWDVB_MASK' undeclared (first use in this function) speed.c:341: error: 'PLLD_FBDV_MASK' undeclared (first use in this function) speed.c:344: error: 'OPBDV_MASK' undeclared (first use in this function) speed.c:348: error: 'PERDV_MASK' undeclared (first use in this function) speed.c:351: error: 'CPR0_PLBED' undeclared (first use in this function) speed.c:352: error: 'PLBEDDV_MASK' undeclared (first use in this function) speed.c:357: error: 'PLLC_FBSEL_MASK' undeclared (first use in this function) make[1]: *** [speed.o] Error 1
make[1]: *** Waiting for unfinished jobs....
make: *** [arch/powerpc/cpu/ppc4xx/libppc4xx.o] Error 2
make: *** Waiting for unfinished jobs....

Could you please check, if the 460SX has the same registers and bits as 460EX/GT and extend its header as well?

Thanks.

Best regards,
Stefan

--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-0 Fax: (+49)-8142-66989-80 Email: office at denx.de

Stefan,

I forgot about the SX. Unfortunately, it looks like the SX has a significantly different clocking system than the EX/GT. For instance, it has two PLLs, different available dividers, etc. Additionally, I don't have an SX board to test with. Perhaps I should save the old code path for that board?

Let me know what you think.

Mike

Mike,

[Added Marri from APM to CC]

I also don't have access to an 460SX board. And yes, perhaps its best to split the code now (460EX/GT vs. 460SX).

Marri, what do you think? Perhaps you could test the resulting code on an SX board?

Thanks,
Stefan

--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-0 Fax: (+49)-8142-66989-80 Email: office at denx.de

Dear Stefan,

It appears the Redwood board is unmaintained. No updates for this board have ever been posted since the initial addition more than 3 years ago, nor is there any board maintainer registered.

I suggest we simply drop support for the unmaintained processor and remove the respective board code from the tree.

Best regards,

Wolfgang Denk

DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Generally speaking, there are other ways to accomplish whatever it is
that you think you need ...                               - Doug Gwyn

Wolfgang,

I know that the SX variant is actively maintained on the Linux PPC mailing list, perhaps we just need to find a maintainer for the SX in u-boot? If the old code path was working for them, it wouldn't be any real work for me to keep it.

Thanks,
Mike

Dear Mike,

...

...

If there is anybody interested in keeping the 460SX code in mainline, he can (and should) speak now or forever hold your peace.

Best regards,

Wolfgang Denk

DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Bei genauerem Hinsehen ist die  Arbeit  weniger  langweilig  als  das
Vergn?gen.                                      -- Charles Baudelaire

Hi Wolfgang,

[Added Dave and Marri from APM to CC]

I just checked the archives and found that Marri posted patches for another 460SX board (Eiger) support in December 2010:

http://lists.denx.de/pipermail/u-boot/2010-December/083373.html

He didn't reply upon the requested changes though:

http://lists.denx.de/pipermail/u-boot/2010-December/083400.html
http://lists.denx.de/pipermail/u-boot/2010-December/083417.html

Marri (or somebody else from APM): Do you plan to support the 460SX boards? Then please let us know.

Thanks.

Best regards,
Stefan

--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-0 Fax: (+49)-8142-66989-80 Email: office at denx.de

Dear Stefan,

...

Yes, that's what I mean: the code get's dropped, and then nobody ever cares about it again. Such unmaintained code is basicly useless to everyone, and just adds efforts that coul better be used for other work.

As mentioned before, we might otherwise remove the dead code.

Thanks.

Best regards,

Wolfgang Denk

DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
It seems intuitively obvious to me, which  means  that  it  might  be
wrong.                                                 -- Chris Torek

Yes, that's what I mean: the code get's dropped, and then nobody ever cares about it again. Such unmaintained code is basicly useless to everyone, and just adds efforts that coul better be used for other work.

boards?

As mentioned before, we might otherwise remove the dead code.

[marri] Sorry I was on vacation last month. We do still need this code as PPC460 is still used by many companies. We are working in submitting the New patch set to fix most of the issues.

Regards,
Marri

Marri,

Any idea roughly, when we might expect such patches?

Thanks.

Best regards,
Stefan

--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-0 Fax: (+49)-8142-66989-80 Email: office at denx.de

<
<Any idea roughly, when we might expect such patches? <
[Tirumala Marri] Hi Stefan,
Probably around middle of the October.

Regards,
Marri

Dear Tirumala Marri,

Stefan asked before, but you did not reply yet, so here I ask again:
What exactly are your plans? You did not respond to the Eiger patches for the last 9 months, so I somewhat doubt you are going to submit usable patches within the next couple of days, or are you?

Best regards,

Wolfgang Denk

DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
There is a biblical analogy I'd like to draw here.   Casts are to C++
Programmers what the apple was to Eve.         - Scott Douglas Meyers

Hi Wolfgang,

Stefan asked before, but you did not reply yet, so here I ask again:
What exactly are your plans? You did not respond to the Eiger patches for the last 9 months, so I somewhat doubt you are going to submit usable patches within the next couple of days, or are you? [marri] I will have the patches submitted by Aug29. Sorry for the inconvenience.

Thanks and regards,
Marri

<
<Stefan asked before, but you did not reply yet, so here I ask again:
<What exactly are your plans? You did not respond to the Eiger patches <for the last 9 months, so I somewhat doubt you are going to submit <usable patches within the next couple of days, or are you? [Tirumala Marri] Dear Wolfgang,
We are working on patches for new SoC and got busy with that.
We will be submitting this change by middle of Oct15.

Regards,
Marri

Mike and Stefan,

boards

function)

function)

function)

function)

function)

[marri] 460Ex/Gt and 460Sx has different clocking subsystems. This code will
Have to split to support to read the speed settings from CPU registers.

If you can include the change to split this function we will submit our
patch
Based on yours. Please suggest.

Thanks,
Marri

Marri, Mike

Yes. Mike, could you please re-send your patch with this suggested split?

Marri, could you please test this result on an 460SX board? And perhaps send send a patch to fix potentially remaining 460SX issues?

Thanks.

Best regards,
Stefan

--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-0 Fax: (+49)-8142-66989-80 Email: office at denx.de

Hi Stefan,

Yes. Mike, could you please re-send your patch with this suggested split?

Marri, could you please test this result on an 460SX board? And perhaps send send a patch to fix potentially remaining 460SX issues?

*[Tirumala Marri] *Sure we will test Mike?s fix on our 460Sx board. Once
Mike?s patch accepted we will post follow-up patch for 460Sx changes.

* *

*Regards,*

*Marri*

All,

Unfortunately, our internal project ended and I've been moved to another one with no access to the original hardware, which is out indefinitely for demos. It should be as simple as adding an additional #ifdef check with the new code for the 460GT/EX and the old code for the 460SX, but I wouldn't be able to test anything past compilation.

Sorry for being unhelpful,
Mike

<Unfortunately, our internal project ended and I've been moved to <another one with no access to the original hardware, which is out <indefinitely for demos. It should be as simple as adding an additional <#ifdef check with the new code for the 460GT/EX and the old code for <the 460SX, but I wouldn't be able to test anything past compilation. <
<Sorry for being unhelpful,
[Tirumala Marri] I can understand. If no volunteers then I will add this to my to do list of patches and complete
The task in near future.

Regards,
Marri