linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Scott Wood <scottwood@freescale.com>
To: Emil Medve <Emilian.Medve@Freescale.com>
Cc: "devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>,
	Xie Shaohui-B21989 <Shaohui.Xie@Freescale.com>
Subject: Re: [PATCH] [v3] power/fsl: add MDIO dt binding for FMan
Date: Wed, 7 Jan 2015 19:12:38 -0600	[thread overview]
Message-ID: <1420679558.4961.64.camel@freescale.com> (raw)
In-Reply-To: <54AD8C8A.8070100@Freescale.com>

On Wed, 2015-01-07 at 13:44 -0600, Emil Medve wrote:
> Hello Scott,
> 
> 
> On 01/07/2015 12:05 PM, Scott Wood wrote:
> > On Tue, 2015-01-06 at 23:29 -0600, Xie Shaohui-B21989 wrote:
> >>>>> +- interrupts
> >>>>> +		Usage: optional
> >>>>> +		Value type: <prop-encoded-array>
> >>>>> +		Definition: Event interrupt of external MDIO controller.
> >>>>> +		1 Gb/s MDIO and 10 Gb/s MDIO has one interrupt respectively.
> >>>
> >>> I'm confused by "respectively" here.  Does fsl,fman-memac-mdio have two
> >>> interrupts (one for 1 Gb/s and one for 10 Gb/s)?
> >> [S.H] We use two MDIO controllers for external PHY management. One for 1 Gb/s,
> >> One for 10 Gb/s, and two MDIO interrupts connected to MPIC.
> > 
> > If there can be two interrupts you need to make that clear and specify
> > the order.
> > 
> > Is it possible for one MDIO controller to have an interrupt connected
> > but not the other, on the same system?  How would you represent that in
> > the device tree?  If there are two MDIO controllers why are they in the
> > same node?
> 
> Historically (FMan v2 and even before/legacy) we've had each MAC include
> an MDIO controller, but only one MDIO controller per MAC type/speed (1
> Gb/s vs 10 Gb/s) is pinned out and all the same speed PHY(s) are
> connected to the respective MDIO controllers. As such the first 1 Gb/s
> MAC/MDIO controller is used to manage all the 1 Gb/s PHY(s) and the
> first 10 Gb/s MAC/MDIO controller is used to manage all the 10 Gb/s
> PHY(s). Each MDIO controller has the ability to generate interrupts but
> only pinned out MDIO controllers are hooked up to the MPIC (as such the
> talk about two interrupts)
> 
> (Each MAC has also integrated a SERDES/TBI/"internal" PHY that is
> connected to the "local" MDIO controller)
> 
> As you can imagine this creates a number of problems in a partitioning
> scenario (and not just, imagine RCWs where the first MAC is not
> used/enabled). In order to help a bit (but not quite enough), in FMan
> v3, two additional MDIO controllers (one for 1 the Gb/s PHY(s) and one
> for 1 the 10 Gb/s PHY(s)) have been integrated that are not associated
> with any MAC and these are the pinned out MDIO controllers on such
> SoC(s) (chassis v2)

I'm happy to hear that.  Is that what is meant by "external" here?  I
thought it meant external to the SoC.  Is this the term used by hardware
documentation?  I'd have called it "independent" or similar.

> >>   Does "optional" mean it's used if and
> >>> only if external MDIO is used, or is it optional even with external MDIO?  I see
> >>> it's not present in the example -- do we not have a real example that has the
> >>> interrupt?
> >> [S.H] "optional" means it's available on hardware, but MDIO driver does not use interrupt. 
> >> So we don't have a real example.
> > 
> > <record type="broken">The device tree describes the hardware, not the
> > driver</record>
> 
> Anyway, only two MDIO nodes (out of 4 to 14) would have an interrupt
> property describing exactly one interrupt. What language should we use
> to convey this situation

So the answer is that there will not be more than one MDIO controller
per MDIO node, or more than one interrupt per MDIO node?  In that case
just get rid of the confusing "respectively" sentence -- and always
describe the interrupt if it exists in hardware.

-Scott

  reply	other threads:[~2015-01-08  1:12 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-23  7:57 [PATCH] [v3] power/fsl: add MDIO dt binding for FMan shh.xie
2015-01-05 11:21 ` Shaohui Xie
2015-01-07  0:28   ` Scott Wood
2015-01-07  5:29     ` Shaohui Xie
2015-01-07 18:05       ` Scott Wood
2015-01-07 19:44         ` Emil Medve
2015-01-08  1:12           ` Scott Wood [this message]
2015-01-08  3:58             ` Shaohui Xie
2015-01-08  9:31             ` Emil Medve

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=1420679558.4961.64.camel@freescale.com \
    --to=scottwood@freescale.com \
    --cc=Emilian.Medve@Freescale.com \
    --cc=Shaohui.Xie@Freescale.com \
    --cc=devicetree@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.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).