All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Lunn <andrew@lunn.ch>
To: "Machnikowski, Maciej" <maciej.machnikowski@intel.com>
Cc: Jakub Kicinski <kuba@kernel.org>,
	Florian Fainelli <f.fainelli@gmail.com>,
	Ido Schimmel <idosch@idosch.org>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"intel-wired-lan@lists.osuosl.org"
	<intel-wired-lan@lists.osuosl.org>,
	"richardcochran@gmail.com" <richardcochran@gmail.com>,
	"abyagowi@fb.com" <abyagowi@fb.com>,
	"Nguyen, Anthony L" <anthony.l.nguyen@intel.com>,
	"davem@davemloft.net" <davem@davemloft.net>,
	"linux-kselftest@vger.kernel.org"
	<linux-kselftest@vger.kernel.org>,
	Michal Kubecek <mkubecek@suse.cz>,
	Saeed Mahameed <saeed@kernel.org>,
	Michael Chan <michael.chan@broadcom.com>
Subject: Re: [PATCH net-next 1/2] rtnetlink: Add new RTM_GETEECSTATE message to get SyncE status
Date: Wed, 8 Sep 2021 21:34:37 +0200	[thread overview]
Message-ID: <YTkQTQM6Is4Hqmxh@lunn.ch> (raw)
In-Reply-To: <PH0PR11MB4951AA3C65DD8E7612F5F396EAD49@PH0PR11MB4951.namprd11.prod.outlook.com>

> > > The SyncE API considerations starts ~54:00, but basically we need API for:
> > > - Controlling the lane to pin mapping for clock recovery
> > > - Check the EEC/DPLL state and see what's the source of reference
> > frequency
> > > (in more advanced deployments)
> > > - control additional input and output pins (GNSS input, external inputs,
> > recovered
> > >   frequency reference)

Now that you have pointed to a datasheet...

> - Controlling the lane to pin mapping for clock recovery

So this is a PHY property. That could be Linux driving the PHY, via
phylib, drivers/net/phy, or there could be firmware in the MAC driver
which hides the PHY and gives you some sort of API to access it.

> Check the EEC/DPLL state and see what's the source of reference
> frequency

Where is the EEC/DPLL implemented? Is it typically also in the PHY? Or
some other hardware block?

I just want to make sure we have an API which we can easily delegate
to different subsystems, some of it in the PHY driver, maybe some of
it somewhere else.

Also, looking at the Marvell datasheet, it appears these registers are
in the MDIO_MMD_VEND2 range. Has any of this been specified? Can we
expect to be able to write a generic implementation sometime in the
future which PHY drivers can share?

I just looked at a 1G Marvell PHY. It uses RGMII or SGMII towards the
host. But there is no indication you can take the clock from the SGMII
SERDES, it is only the recovered clock from the line. And the
recovered clock always goes out the CLK125 pin, which can either be
125MHz or 25MHz.

So in this case, you have no need to control the lane to pin mapping,
it is fixed, but do we want to be able to control the divider?

Do we need a mechanism to actually enumerate what the hardware can do?

Since we are talking about clocks and dividers, and multiplexors,
should all this be using the common clock framework, which already
supports most of this? Do we actually need something new?

       Andrew

WARNING: multiple messages have this Message-ID (diff)
From: Andrew Lunn <andrew@lunn.ch>
To: intel-wired-lan@osuosl.org
Subject: [Intel-wired-lan] [PATCH net-next 1/2] rtnetlink: Add new RTM_GETEECSTATE message to get SyncE status
Date: Wed, 8 Sep 2021 21:34:37 +0200	[thread overview]
Message-ID: <YTkQTQM6Is4Hqmxh@lunn.ch> (raw)
In-Reply-To: <PH0PR11MB4951AA3C65DD8E7612F5F396EAD49@PH0PR11MB4951.namprd11.prod.outlook.com>

> > > The SyncE API considerations starts ~54:00, but basically we need API for:
> > > - Controlling the lane to pin mapping for clock recovery
> > > - Check the EEC/DPLL state and see what's the source of reference
> > frequency
> > > (in more advanced deployments)
> > > - control additional input and output pins (GNSS input, external inputs,
> > recovered
> > >   frequency reference)

Now that you have pointed to a datasheet...

> - Controlling the lane to pin mapping for clock recovery

So this is a PHY property. That could be Linux driving the PHY, via
phylib, drivers/net/phy, or there could be firmware in the MAC driver
which hides the PHY and gives you some sort of API to access it.

> Check the EEC/DPLL state and see what's the source of reference
> frequency

Where is the EEC/DPLL implemented? Is it typically also in the PHY? Or
some other hardware block?

I just want to make sure we have an API which we can easily delegate
to different subsystems, some of it in the PHY driver, maybe some of
it somewhere else.

Also, looking at the Marvell datasheet, it appears these registers are
in the MDIO_MMD_VEND2 range. Has any of this been specified? Can we
expect to be able to write a generic implementation sometime in the
future which PHY drivers can share?

I just looked at a 1G Marvell PHY. It uses RGMII or SGMII towards the
host. But there is no indication you can take the clock from the SGMII
SERDES, it is only the recovered clock from the line. And the
recovered clock always goes out the CLK125 pin, which can either be
125MHz or 25MHz.

So in this case, you have no need to control the lane to pin mapping,
it is fixed, but do we want to be able to control the divider?

Do we need a mechanism to actually enumerate what the hardware can do?

Since we are talking about clocks and dividers, and multiplexors,
should all this be using the common clock framework, which already
supports most of this? Do we actually need something new?

       Andrew

  reply	other threads:[~2021-09-08 19:35 UTC|newest]

Thread overview: 82+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-03 15:14 [RFC v4 net-next 0/2] Add RTNL interface for SyncE Maciej Machnikowski
2021-09-03 15:14 ` [Intel-wired-lan] " Maciej Machnikowski
2021-09-03 15:14 ` [PATCH net-next 1/2] rtnetlink: Add new RTM_GETEECSTATE message to get SyncE status Maciej Machnikowski
2021-09-03 15:14   ` [Intel-wired-lan] " Maciej Machnikowski
2021-09-03 16:18   ` Stephen Hemminger
2021-09-03 16:18     ` [Intel-wired-lan] " Stephen Hemminger
2021-09-03 22:20     ` Machnikowski, Maciej
2021-09-03 22:20       ` [Intel-wired-lan] " Machnikowski, Maciej
2021-09-03 22:14   ` Jakub Kicinski
2021-09-03 22:14     ` [Intel-wired-lan] " Jakub Kicinski
2021-09-06 18:30     ` Machnikowski, Maciej
2021-09-06 18:30       ` [Intel-wired-lan] " Machnikowski, Maciej
2021-09-06 18:39       ` Jakub Kicinski
2021-09-06 18:39         ` [Intel-wired-lan] " Jakub Kicinski
2021-09-06 19:01         ` Machnikowski, Maciej
2021-09-06 19:01           ` [Intel-wired-lan] " Machnikowski, Maciej
2021-09-07  1:01           ` Jakub Kicinski
2021-09-07  1:01             ` [Intel-wired-lan] " Jakub Kicinski
2021-09-07  8:50             ` Machnikowski, Maciej
2021-09-07  8:50               ` [Intel-wired-lan] " Machnikowski, Maciej
2021-09-07 14:55               ` Jakub Kicinski
2021-09-07 14:55                 ` [Intel-wired-lan] " Jakub Kicinski
2021-09-07 15:47                 ` Machnikowski, Maciej
2021-09-07 15:47                   ` [Intel-wired-lan] " Machnikowski, Maciej
2021-09-07 19:47                   ` Jakub Kicinski
2021-09-07 19:47                     ` [Intel-wired-lan] " Jakub Kicinski
2021-09-08  8:03                     ` Machnikowski, Maciej
2021-09-08  8:03                       ` [Intel-wired-lan] " Machnikowski, Maciej
2021-09-08 16:21                       ` Jakub Kicinski
2021-09-08 16:21                         ` [Intel-wired-lan] " Jakub Kicinski
2021-09-08 17:30                         ` Machnikowski, Maciej
2021-09-08 17:30                           ` [Intel-wired-lan] " Machnikowski, Maciej
2021-09-08 19:34                           ` Andrew Lunn [this message]
2021-09-08 19:34                             ` Andrew Lunn
2021-09-08 20:27                             ` Machnikowski, Maciej
2021-09-08 20:27                               ` [Intel-wired-lan] " Machnikowski, Maciej
2021-09-08 22:20                             ` Jakub Kicinski
2021-09-08 22:20                               ` [Intel-wired-lan] " Jakub Kicinski
2021-09-08 22:59                               ` Andrew Lunn
2021-09-08 22:59                                 ` [Intel-wired-lan] " Andrew Lunn
2021-09-09  2:09                                 ` Richard Cochran
2021-09-09  2:09                                   ` [Intel-wired-lan] " Richard Cochran
2021-09-09  8:18                                   ` Machnikowski, Maciej
2021-09-09  8:18                                     ` [Intel-wired-lan] " Machnikowski, Maciej
2021-09-10 14:14                                     ` Richard Cochran
2021-09-10 14:14                                       ` [Intel-wired-lan] " Richard Cochran
2021-09-08 22:18                           ` Jakub Kicinski
2021-09-08 22:18                             ` [Intel-wired-lan] " Jakub Kicinski
2021-09-08 23:14                             ` Andrew Lunn
2021-09-08 23:14                               ` [Intel-wired-lan] " Andrew Lunn
2021-09-08 23:58                               ` Jakub Kicinski
2021-09-08 23:58                                 ` [Intel-wired-lan] " Jakub Kicinski
2021-09-09  8:26                                 ` Machnikowski, Maciej
2021-09-09  8:26                                   ` [Intel-wired-lan] " Machnikowski, Maciej
2021-09-09  9:24                                   ` Machnikowski, Maciej
2021-09-09  9:24                                     ` [Intel-wired-lan] " Machnikowski, Maciej
2021-09-09 10:15                                     ` David Miller
2021-09-09 10:15                                       ` [Intel-wired-lan] " David Miller
2021-09-09  8:11                             ` Machnikowski, Maciej
2021-09-09  8:11                               ` [Intel-wired-lan] " Machnikowski, Maciej
2021-09-13  8:50                         ` Ido Schimmel
2021-09-13  8:50                           ` [Intel-wired-lan] " Ido Schimmel
2021-09-21 13:36                         ` Ido Schimmel
2021-09-21 13:36                           ` [Intel-wired-lan] " Ido Schimmel
2021-09-21 13:15   ` Ido Schimmel
2021-09-21 13:15     ` [Intel-wired-lan] " Ido Schimmel
2021-09-21 13:37     ` Machnikowski, Maciej
2021-09-21 13:37       ` [Intel-wired-lan] " Machnikowski, Maciej
2021-09-21 14:58       ` Ido Schimmel
2021-09-21 14:58         ` [Intel-wired-lan] " Ido Schimmel
2021-09-21 21:14         ` Jakub Kicinski
2021-09-21 21:14           ` [Intel-wired-lan] " Jakub Kicinski
2021-09-22  6:22           ` Ido Schimmel
2021-09-22  6:22             ` [Intel-wired-lan] " Ido Schimmel
2021-09-03 15:14 ` [PATCH net-next 2/2] ice: add support for reading SyncE DPLL state Maciej Machnikowski
2021-09-03 15:14   ` [Intel-wired-lan] " Maciej Machnikowski
2021-09-03 22:06   ` Jakub Kicinski
2021-09-03 22:06     ` [Intel-wired-lan] " Jakub Kicinski
2021-09-21 13:25   ` Ido Schimmel
2021-09-21 13:25     ` [Intel-wired-lan] " Ido Schimmel
  -- strict thread matches above, loose matches on Subject: below --
2021-08-31 11:52 [PATCH net-next 0/2] Add RTNL interface for SyncE EEC state Maciej Machnikowski
2021-08-31 11:52 ` [PATCH net-next 1/2] rtnetlink: Add new RTM_GETEECSTATE message to get SyncE status Maciej Machnikowski
2021-08-31 13:44   ` Jakub Kicinski

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=YTkQTQM6Is4Hqmxh@lunn.ch \
    --to=andrew@lunn.ch \
    --cc=abyagowi@fb.com \
    --cc=anthony.l.nguyen@intel.com \
    --cc=davem@davemloft.net \
    --cc=f.fainelli@gmail.com \
    --cc=idosch@idosch.org \
    --cc=intel-wired-lan@lists.osuosl.org \
    --cc=kuba@kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=maciej.machnikowski@intel.com \
    --cc=michael.chan@broadcom.com \
    --cc=mkubecek@suse.cz \
    --cc=netdev@vger.kernel.org \
    --cc=richardcochran@gmail.com \
    --cc=saeed@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.