RE: MDIO clock speed computation

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/

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/

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/

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:

quoted

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/

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. :-)

quoted

quoted

  (((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/