RE: MDIO clock speed computation

RE: MDIO clock speed computation

[Jean-Denis Boyer]

Dan,

> I never expected to see someone run something like 46.5 MHz.

I agree, this might be impossible to achieve, since the PLL gain is an
integer. But the externcal clock does not necessarily have a frequency which
is a multiple of 1MHz.

For example, some of our 860T based boards have an external clock of
4096kHz, which is multiplied by 12, and yields a core clock of 49152MHz.

I don't know much about clock devices, but I guess there are many
possibilities.

> Will this work for all cases? :
>
> ((((bd->bi_intfreq + 4999999) / 2500000) / 2 ) & 0x3F ) << 1;

I hope so ;-)


--------------------------------------------
 Jean-Denis Boyer, B.Eng., System Architect
 Mediatrix Telecom Inc.
 4229 Garlock Street
 Sherbrooke (Québec)
 J1L 2C8  CANADA
 (819)829-8749 x241
--------------------------------------------

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: MDIO clock speed computation

[Pavel Bartusek]

[-- Attachment #1: Type: text/plain, Size: 1165 bytes --]

Jean-Denis Boyer wrote:

>>Will this work for all cases? :
>>
>>((((bd->bi_intfreq + 4999999) / 2500000) / 2 ) & 0x3F ) << 1;
>>
>
>I hope so ;-)
>
Because hoping is not enough, I wrote a little brute force program for testing (see attachment).
The algorithm above is OK :-) It produces MDIO frequencies from 1.875MHz to 2.5 MHz.

BTW: Wolfgang, similar problem is in the PPCboot.

----------------------------------------------------------------------
|                          Pavel Bartusek                            |
|                                                                    |
| Sysgo RTS GmbH,                     phone: +49 (0) 6136 9948-722   |
| Am Pfaffenstein 14                  fax:   +49 (0) 6136 9948-10    |
| D-55270 Klein-Winternheim           email: pba@sysgo.de            |
| Germany                                                            |
|                                                                    |
|       http://www.sysgo.de           http://www.elinos.com          |
|                                                                    |
----------------------------------------------------------------------



[-- Attachment #2: fec_speed.test.c --]
[-- Type: text/plain, Size: 572 bytes --]

#include <stdio.h>
#include <limits.h>

#define ALGORITHM ((((bi_intfreq + 4999999) / 2500000) / 2 ) & 0x3F ) << 1

int main(void)
{
unsigned long bi_intfreq, mdio_clock_min=INT_MAX, mdio_clock_max=0, mii_speed,mii_speed_reg;

for(bi_intfreq=10000000; bi_intfreq<200000000; bi_intfreq++) {
 mii_speed_reg = ALGORITHM;
 mii_speed = bi_intfreq / (mii_speed_reg & ~1);
 if (mii_speed > mdio_clock_max) mdio_clock_max = mii_speed;
 if (mii_speed < mdio_clock_min) mdio_clock_min = mii_speed;
}
 printf("MDIO clocks are from %ldHz to %ldHz\n",mdio_clock_min,mdio_clock_max);
}

RE: MDIO clock speed computation

[Jean-Denis Boyer]

Dan,

> try this (since the problem is the divisor register truncation):
>
> (((((bd->bi_intfreq + 500000) / 2500000) + 1) / 2 ) & 0x3F ) << 1;

This is bad :-(
With a frequency of 46.5MHz, you get a MII clock of 2.58MHz.

Why adding 500000 (0.5MHz) to the internal clock in this computation?
We usually do that to round up (or down) to the nearest integer.
But we do NOT want to round down, or the divisor (MII_SPEED) will be too
low.
We want to round up to the nearest integer when divided by 2*2.5MHz.

--------------------------------------------
 Jean-Denis Boyer, B.Eng., System Architect
 Mediatrix Telecom Inc.
 4229 Garlock Street
 Sherbrooke (Québec)
 J1L 2C8  CANADA
 (819)829-8749 x241
--------------------------------------------

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: MDIO clock speed computation

[Dan Malek]

Jean-Denis Boyer wrote:


> With a frequency of 46.5MHz, you get a MII clock of 2.58MHz.

OK....We'll use something else, then.

> Why adding 500000 (0.5MHz) to the internal clock in this computation?
> We usually do that to round up (or down) to the nearest integer.

I did it to round up so the frequencies I knew about at the time would
generate the proper results.  I have to admit, I never expected to
see someone run something like 46.5 MHz.  I guess when we made the
change to represent the frequency in Hz instead of MHz, the arithmetic
fell apart.  In the past, we couldn't represent 46.5 MHz, it would
have been 47 MHz, so the rounding would have produced a correct result.

> But we do NOT want to round down, or the divisor (MII_SPEED) will be too
> low.

I'm not rounding down, there are two cases where it is rounded up, but
I guess that still isn't enough.


> We want to round up to the nearest integer when divided by 2*2.5MHz.

Will this work for all cases? :

((((bd->bi_intfreq + 4999999) / 2500000) / 2 ) & 0x3F ) << 1;



	-- Dan


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

RE: MDIO clock speed computation

[Jean-Denis Boyer]

Dan,

> The MII clock is not derived from the core speed, but rather the
> system/bus clock speed.

Motorola documentation says the MDIO clock is a fraction of the system clock
frequency. I tought the system clock was the core clock, and the external
bus clock was divided using SCCR[EBDF]. Where is it told the system clock is
the bus clock?

> Up to this point, I don't believe there are
> any 8xx parts that are qualified to run beyond a 50 MHz CPU/bus
> speed, so the software is just fine.

The value of 82.5MHz was only a example to show the
erroneous computation. May be it was badly choosed, I admit.
You can also try with 47.5MHz (more realistic) and
see this yields to a MII clock of 2.64MHz.

> Also, the 2.5 MHz is a suggestion, I think all PHYs run much
> faster, you will have to check the data sheet.

I think this is a bad assumption. A PHY from National,
the DP83846A, specifies a MDIO clock of 2.5MHz (MAX).
A PHY of Intel, the LXT972A, as a maximum speed of 8MHz.

> The only thing that will happen if this speed is out of spec
> for either side is you will have problems configuring
> or detecting the PHY (the exchange of control/status messages).

The funniest thing is that the problem that Pavel reported today
seems to fix a problem that was submitted to me a couple of
weeks ago, and that I just begun to work on this morning!!!

My 860T is clocked at 49.152MHz, and the MII clock (with the
erroneous calculation) was output to 2.73MHz to my DP83846A PHY.

During FEC initialization, I have a couple of MDIO accesses
thightly serialized. Sometimes, the system was hanging, waiting
for an MDIO to complete. The answer was never received by the FEC.
With my BDI2000, I just set the MII_DATA register again to force
the read command to be resent, and the board continued to boot.

Changing the MII clock to 2.46MHz just seemed to fix the problem.
I successfully ran tests for more than an hour now...

Regards,
--------------------------------------------
 Jean-Denis Boyer, B.Eng., System Architect
 Mediatrix Telecom Inc.
 4229 Garlock Street
 Sherbrooke (Québec)
 J1L 2C8  CANADA
 (819)829-8749 x241
--------------------------------------------

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

RE: MDIO clock speed computation

[Jean-Denis Boyer]

Pavel,

You have found a interesting problem in the calculation of the MII_SPEED.
And it seems to be there since a long time!

However, your fix seems incomplete.
If I have a frequency of 82,5MHz, for example,
it yields exactly to the same result before and after your patch,
that is an MDIO clock of 2.58MHz.

Since the divisor is 2 * MDCLOCK,
I would suggest something like:

  (((bd->bi_intfreq + (2 * 2500000 - 1 )) / 2500000 / 2) & 0x3F) << 1;

Regards,

--------------------------------------------
 Jean-Denis Boyer, B.Eng., System Architect
 Mediatrix Telecom Inc.
 4229 Garlock Street
 Sherbrooke (Québec)
 J1L 2C8  CANADA
 (819)829-8749 x241
--------------------------------------------

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: MDIO clock speed computation

[Dan Malek]

Jean-Denis Boyer wrote:

> However, your fix seems incomplete.
> If I have a frequency of 82,5MHz, for example,
> it yields exactly to the same result before and after your patch,
> that is an MDIO clock of 2.58MHz.

The MII clock is not derived from the core speed, but rather the
system/bus clock speed.  Up to this point, I don't believe there are
any 8xx parts that are qualified to run beyond a 50 MHz CPU/bus
speed, so the software is just fine.  If you are running something
faster than a 50 MHz bus, you may want to look into this.


>
> Since the divisor is 2 * MDCLOCK,
> I would suggest something like:
>
>   (((bd->bi_intfreq + (2 * 2500000 - 1 )) / 2500000 / 2) & 0x3F) << 1;

The proper fix would be to change this from 'bi_intfreq' to 'bi_busfreq'.

What is actually happening is you are running much slower than 2.5 MHz
because you are computing on a clock that is running much faster than
the actual supplied clock to the MII (i.e. your divisor is too large).
Also, the 2.5 MHz is a suggestion, I think all PHYs run much faster, you
will have to check the data sheet.  The Motorola manual used to indicate
this as a suggested maximum for their parts, further that it would
run faster than this and maximum was still being qualified.

The only thing that will happen if this speed is out of spec for either
side is you will have problems configuring or detecting the PHY (the exchange
of control/status messages).  It has nothing to do with data transfer.


	-- Dan


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: MDIO clock speed computation

[Dan Malek]

Dan Malek wrote:

 > ..... Up to this point, I don't believe there are
> any 8xx parts that are qualified to run beyond a 50 MHz CPU/bus

Bah.......................................................CPM/bus  :-)


	-- Dan


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: MDIO clock speed computation

[Wolfgang Denk]

In message <3D3C6233.3090007@embeddededge.com> you wrote:
>
> system/bus clock speed.  Up to this point, I don't believe there are
> any 8xx parts that are qualified to run beyond a 50 MHz CPU/bus
> speed, so the software is just fine.  If you are running something
> faster than a 50 MHz bus, you may want to look into this.

There are. I've seen MPC823E, 860T, 860P and 862 qualified for 66 MHz
CPU/bus, and 862 for 100/50 MHz CPU/bus.

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
They weren't that important. They were merely at the top. The  people
who  really  run organizations are usually found several levels down,
where it's still possible to get things done.
                                      - Terry Pratchett, _Small Gods_

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: MDIO clock speed computation

[Pavel Bartusek]

Dan Malek wrote:

> The MII clock is not derived from the core speed, but rather the
> system/bus clock speed.  Up to this point, I don't believe there are
> any 8xx parts that are qualified to run beyond a 50 MHz CPU/bus
> speed, so the software is just fine.  If you are running something
> faster than a 50 MHz bus, you may want to look into this.


I thing that system clock and bus clock can be different (in terminology
of the MPC855T user manual)

MPC855T manual, section Clocks and Power Control:
"
GCLK1C/GCLK2C - Basic clocks supplied to the core, the data and
instruction caches, and MMUs.
GCLK1_50/GCLK2_50 - Optionally divided versions of GCLK1/GCLK2, which
are used to clock the GPCM and UPM in the memory controller and to
provide the CLKOUT output for the external bus.
.
.
.
 - General system clocks GCLK1C, GCLK2C, GCLK1, GCLK2
  - Memory controller and external bus clocks GCLK1_50, GCLK2_50
.
.
The MPC855T provides the capability to run the external bus and memory
controller at a lower frequency than the internal modules. This
capability is provided by the external bus frequency dividers. The
external bus clocks GCLK1_50 and GCLK2_50 are derived from GCLK1 and
GCLK2, as determined by the SCCR[EBDF].
"


MPC855T manual, MII_SPEED register:
"MII_SPEED controls the frequency of the MII management interface clock
(MDC) relative to system clock."

Jean-Denis Boyer wrote:

>> Since the divisor is 2 * MDCLOCK,
>> I would suggest something like:
>>
>>   (((bd->bi_intfreq + (2 * 2500000 - 1 )) / 2500000 / 2) & 0x3F) << 1;
>
OK. It is more correct.


--

----------------------------------------------------------------------
|                          Pavel Bartusek                            |
|                                                                    |
| Sysgo RTS GmbH,                     phone: +49 (0) 6136 9948-722   |
| Am Pfaffenstein 14                  fax:   +49 (0) 6136 9948-10    |
| D-55270 Klein-Winternheim           email: pba@sysgo.de            |
| Germany                                                            |
|                                                                    |
|       http://www.sysgo.de           http://www.elinos.com          |
|                                                                    |
----------------------------------------------------------------------


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: MDIO clock speed computation

[Dan Malek]

Pavel Bartusek wrote:

> I thing that system clock and bus clock can be different (in terminology
> of the MPC855T user manual)
>
> MPC855T manual, section Clocks and Power Control:
> "
> GCLK1C/GCLK2C - Basic clocks supplied to the core, the data and
> instruction caches, and MMUs.
> GCLK1_50/GCLK2_50 - Optionally divided versions of GCLK1/GCLK2, which
> are used to clock the GPCM and UPM in the memory controller and to
> provide the CLKOUT output for the external bus.

Notice in all of the descriptions there is no definition of "system clock."
I carefully read all of the 8xx manuals, and there are a few references
to "system clocks", especially around power management and frequency
control.  There are a couple of references to peripheral clocks being
derived from a "system clock", which from the context appears to be the
same as the core clock, not the CLKOUT that would be supplied to the rest
of the "system."

It appears the MII clock must be derived from the core clock speed, so
my code change suggestion the other day was wrong. :-)



>>>   (((bd->bi_intfreq + (2 * 2500000 - 1 )) / 2500000 / 2) & 0x3F) << 1;
>>
>>
> OK. It is more correct.

try this (since the problem is the divisor register truncation):

(((((bd->bi_intfreq + 500000) / 2500000) + 1) / 2 ) & 0x3F ) << 1;

Thanks.


	-- Dan


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

MDIO clock speed computation

[Pavel Bartusek]

Hi there,

I found a little problem with computation of MDIO clock speed in
linux/arch/ppc/8xx_io/fec.c
The MPC855T users manual: "The MII_SPEED field must be programmed with a
value to provide an MDC frequency of less than or equal to 2.5 MHz to
comply with the IEEE MII specification."
The code produces ie. value 0x18 to the MII Speed Control Register for
64MHz system clock it means 2.67Mhz MDIO clock.

This patch will repair it.


        /* Set MII speed to 2.5 MHz
        */
        fecp->fec_mii_speed = fep->phy_speed =
-               (( (bd->bi_intfreq + 500000) / 2500000 / 2 ) & 0x3F ) << 1;
+               (( (bd->bi_intfreq + (2500000-1)) / 2500000 / 2 ) & 0x3F
) << 1;
 #else
        fecp->fec_mii_speed = 0;        /* turn off MDIO */
 #endif /* CONFIG_USE_MDIO */

--

----------------------------------------------------------------------
|                          Pavel Bartusek                            |
|                                                                    |
| Sysgo RTS GmbH,                     phone: +49 (0) 6136 9948-722   |
| Am Pfaffenstein 14                  fax:   +49 (0) 6136 9948-10    |
| D-55270 Klein-Winternheim           email: pba@sysgo.de            |
| Germany                                                            |
|                                                                    |
|       http://www.sysgo.de           http://www.elinos.com          |
|                                                                    |
----------------------------------------------------------------------


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/