Patchwork [U-Boot] ppc460: read get_sys_info from CPR registers instead of STRP registers

login
register
mail settings
Submitter Mike Williams
Date July 21, 2011, 3:06 p.m.
Message ID <1311260763-15422-1-git-send-email-mike@mikebwilliams.com>
Download mbox | patch
Permalink /patch/106080/
State Under Review
Delegated to: Stefan Roese
Headers show

Comments

Mike Williams - July 21, 2011, 3:06 p.m.
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.

Signed-off-by: Mike Williams <mike@mikebwilliams.com>
---
 arch/powerpc/cpu/ppc4xx/speed.c        |   33 +++++++++++++------------------
 arch/powerpc/include/asm/ppc460ex_gt.h |   15 +++++++++++++-
 2 files changed, 28 insertions(+), 20 deletions(-)
Stefan Roese - July 25, 2011, 11:55 a.m.
Hi Mike,

On Thursday 21 July 2011 17:06:03 Mike Williams wrote:
> 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.

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

[stefan@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@denx.de
Mike Williams - July 25, 2011, 2:42 p.m.
Stefan,

On Mon, Jul 25, 2011 at 7:55 AM, Stefan Roese <sr@denx.de> wrote:
> Hi Mike,
>
> On Thursday 21 July 2011 17:06:03 Mike Williams wrote:
>> 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.
>
> Thanks. Unfortunately this patch introduces compile errors for 460SX boards
> (e.g. redwood):
>
> [stefan@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?

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
Stefan Roese - July 25, 2011, 3:11 p.m.
Mike,

[Added Marri from APM to CC]

On Monday 25 July 2011 16:42:14 Mike Williams wrote:
> > (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?
> 
> 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.

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@denx.de
Wolfgang Denk - July 25, 2011, 6:05 p.m.
Dear Stefan,

In message <201107251711.21381.sr@denx.de> you wrote:
> 
> 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?

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
Mike Williams - July 25, 2011, 6:14 p.m.
Wolfgang,

On Mon, Jul 25, 2011 at 2:05 PM, Wolfgang Denk <wd@denx.de> wrote:
> Dear Stefan,
>
> In message <201107251711.21381.sr@denx.de> you wrote:
>>
>> 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?
>
> 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

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
Wolfgang Denk - July 25, 2011, 6:39 p.m.
Dear Mike,

In message <CANPyyuPoBcNkT-8jyGu2oGQeLYE1k8aP4V7+YpXyMiNU8LXR7A@mail.gmail.com> you wrote:
> 
> On Mon, Jul 25, 2011 at 2:05 PM, Wolfgang Denk <wd@denx.de> wrote:
...
> > It appears the Redwood board is unmaintained. =A0No 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.
...
> 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.

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
Stefan Roese - July 26, 2011, 8 a.m.
Hi Wolfgang,

[Added Dave and Marri from APM to CC]

On Monday 25 July 2011 20:39:14 Wolfgang Denk wrote:
> > > It appears the Redwood board is unmaintained. =A0No 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.
> 
> ...
> 
> > 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.
> 
> If there is anybody interested in keeping the 460SX code in mainline,
> he can (and should) speak now or forever hold your peace.

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@denx.de
Wolfgang Denk - July 26, 2011, 9:31 a.m.
Dear Stefan,

In message <201107261000.04609.sr@denx.de> you wrote:
> 
> On Monday 25 July 2011 20:39:14 Wolfgang Denk wrote:
> > > > 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.
...
> > If there is anybody interested in keeping the 460SX code in mainline,
> > he can (and should) speak now or forever hold your peace.
> 
> 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

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.

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

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

Thanks.

Best regards,

Wolfgang Denk
Tirumala Marri - Aug. 5, 2011, 5:45 p.m.
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.

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

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
Stefan Roese - Aug. 19, 2011, 3:30 p.m.
Marri,

On Friday 05 August 2011 19:45:05 Tirumala Marri wrote:
> 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.

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@denx.de
Wolfgang Denk - Aug. 24, 2011, 10:16 p.m.
Dear Tirumala Marri,

In message <c7e65d5ac78ea9dea60d6533795daf06@mail.gmail.com> you wrote:
> 
> 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.

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
Tirumala Marri - Aug. 25, 2011, 5:09 p.m.
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
Tirumala Marri - Aug. 25, 2011, 6:05 p.m.
Mike and Stefan,



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

>[stefan@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?

[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
Stefan Roese - Aug. 26, 2011, 6:01 a.m.
Marri, Mike

On Thursday 25 August 2011 20:05:15 Tirumala Marri wrote:
> >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?
> 
> [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.

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@denx.de
Tirumala Marri - Aug. 26, 2011, 3:32 p.m.
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*
Mike Williams - Aug. 29, 2011, 1:27 p.m.
All,

On Fri, Aug 26, 2011 at 11:32 AM, Tirumala Marri <tmarri@apm.com> wrote:
> 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

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
Tirumala Marri - Aug. 29, 2011, 10:12 p.m.
<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
Tirumala Marri - Sept. 14, 2011, 9:37 p.m.
<
<Any idea roughly, when we might expect such patches?
<
[Tirumala Marri] Hi Stefan,
   Probably around middle of the October.

Regards,
Marri
Tirumala Marri - Sept. 14, 2011, 9:46 p.m.
<
<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

Patch

diff --git a/arch/powerpc/cpu/ppc4xx/speed.c b/arch/powerpc/cpu/ppc4xx/speed.c
index 09d6671..2643fc0 100644
--- a/arch/powerpc/cpu/ppc4xx/speed.c
+++ b/arch/powerpc/cpu/ppc4xx/speed.c
@@ -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 {
diff --git a/arch/powerpc/include/asm/ppc460ex_gt.h b/arch/powerpc/include/asm/ppc460ex_gt.h
index 732fcac..cff22ad 100644
--- a/arch/powerpc/include/asm/ppc460ex_gt.h
+++ b/arch/powerpc/include/asm/ppc460ex_gt.h
@@ -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)