linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Kyle Moffett <kyle@moffetthome.net>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: netdev <netdev@vger.kernel.org>,
	"Linux-Kernel@Vger. Kernel. Org" <linux-kernel@vger.kernel.org>,
	linuxppc-dev@ozlabs.org
Subject: Re: Porting the ibm_newemac driver to use phylib (and other PHY/MAC questions)
Date: Sun, 3 May 2009 00:26:05 -0400	[thread overview]
Message-ID: <f73f7ab80905022126ud3225enc6409bd39b5b2eb8@mail.gmail.com> (raw)
In-Reply-To: <f73f7ab80904301521x16effa0ar2d4756daceada122@mail.gmail.com>

On Thu, Apr 30, 2009 at 6:21 PM, Kyle Moffett <kyle@moffetthome.net> wrote:
>>> I'm also curious about the intent of the "mdio_instance" pointer (IE:
>>> the "mdio-device" property). =C2=A0Is that used when all the PHY device=
s
>>> are attached to the MDIO bus of only one of the (multiple) emac
>>> devices?
>>
>> It's common especially on older SoCs using EMAC to have only one of
>> the EMAC instance with an MDIO bus for configuring the PHYs. This is one
>> of the reasons why I have the mutex in the low level MDIO access
>> routines since 2 EMACs can try to talk to the same MDIO, and this is the
>> problem I had with phylib back then which was doing everything in atomic
>> contexts.
>
> Ok, good, the current mdiobus code seems to make handling this a good
> deal easier.

Ok, I've dug through the docs on the 460EPx (the CPU I'm using), and
I'd like some confirmation of the following:

*  The EMAC hardware itself internally has its own dedicated
MDIO/MDClk lines, driven by the STACR register.

*  On many/most cpus, there is only a single set of external
MDIO/MDClk pins, driven either off the ZMII bridge or the RGMII
bridge.

*  Both bridge-types have their own internal register for switching
the external MDIO/MDClk pins between the two sets of internal
EMAC<=3D>bridge links.

*  Some SoCs have both an ZMII and an RGMII bridge, and the external
MDIO/MDClk pins are only connected to one of the two bridges (How do I
know which one?  Alternatively, do I just program both and hope for
the best?).

*  Some older SoCs simply export the MDIO/MDClk pins from one of their
internal EMAC chips and don't bother with running it through the
multiplexing bridge.

Are there any SoCs which actually export the MDIO/MDClk pins from
both/all of their EMACs?

Cheers,
Kyle Moffett

  reply	other threads:[~2009-05-03  4:26 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <f73f7ab80904171732n41832d0hc62978e57bbcc32e@mail.gmail.com>
2009-04-20 12:29 ` Porting the ibm_newemac driver to use phylib (and other PHY/MAC questions) Josh Boyer
2009-04-21  0:10   ` Kyle Moffett
2009-04-22  8:21     ` Benjamin Herrenschmidt
2009-04-30 15:04       ` Kyle Moffett
2009-04-30 15:11         ` Grant Likely
2009-04-30 15:33           ` Kyle Moffett
2009-04-30 21:18         ` Benjamin Herrenschmidt
2009-04-30 22:21           ` Kyle Moffett
2009-05-03  4:26             ` Kyle Moffett [this message]
2009-05-03 22:14               ` Benjamin Herrenschmidt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=f73f7ab80905022126ud3225enc6409bd39b5b2eb8@mail.gmail.com \
    --to=kyle@moffetthome.net \
    --cc=benh@kernel.crashing.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).