mbox series

[v1,0/4] net: fec: add PPS channel configuration

Message ID 20240807144349.297342-1-francesco@dolcini.it
Headers show
Series net: fec: add PPS channel configuration | expand

Message

Francesco Dolcini Aug. 7, 2024, 2:43 p.m. UTC
From: Francesco Dolcini <francesco.dolcini@toradex.com>

Make the FEC Ethernet PPS channel configurable from device tree.

The current code hard-code the PPS channel to be 0, however on i.MX8 the
channel is 1.

Francesco Dolcini (4):
  dt-bindings: net: fec: add pps channel property
  net: fec: refactor PPS channel configuration
  net: fec: make PPS channel configurable
  arm64: dts: imx8-ss-conn: add PPS channel to the FEC nodes

 Documentation/devicetree/bindings/net/fsl,fec.yaml |  7 +++++++
 arch/arm64/boot/dts/freescale/imx8-ss-conn.dtsi    |  2 ++
 drivers/net/ethernet/freescale/fec_ptp.c           | 11 ++++++-----
 3 files changed, 15 insertions(+), 5 deletions(-)

Comments

Frank Li Aug. 7, 2024, 3:34 p.m. UTC | #1
On Wed, Aug 07, 2024 at 04:43:49PM +0200, Francesco Dolcini wrote:
> From: Francesco Dolcini <francesco.dolcini@toradex.com>
>
> On i.MX8 the FEC PPS channel is routed to the instance 1, not to the
> default 0.

According to my understand, it should be board level configuration. FEC
support output pps to any one. choose which one by board design.

Frank

>
> Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com>
> ---
>  arch/arm64/boot/dts/freescale/imx8-ss-conn.dtsi | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/freescale/imx8-ss-conn.dtsi b/arch/arm64/boot/dts/freescale/imx8-ss-conn.dtsi
> index a4a10ce03bfe..a9fd47041e3a 100644
> --- a/arch/arm64/boot/dts/freescale/imx8-ss-conn.dtsi
> +++ b/arch/arm64/boot/dts/freescale/imx8-ss-conn.dtsi
> @@ -121,6 +121,7 @@ fec1: ethernet@5b040000 {
>  		assigned-clock-rates = <250000000>, <125000000>;
>  		fsl,num-tx-queues = <3>;
>  		fsl,num-rx-queues = <3>;
> +		fsl,pps-channel = <1>;
>  		power-domains = <&pd IMX_SC_R_ENET_0>;
>  		status = "disabled";
>  	};
> @@ -141,6 +142,7 @@ fec2: ethernet@5b050000 {
>  		assigned-clock-rates = <250000000>, <125000000>;
>  		fsl,num-tx-queues = <3>;
>  		fsl,num-rx-queues = <3>;
> +		fsl,pps-channel = <1>;
>  		power-domains = <&pd IMX_SC_R_ENET_1>;
>  		status = "disabled";
>  	};
> --
> 2.39.2
>
Francesco Dolcini Aug. 7, 2024, 5:51 p.m. UTC | #2
Hello Frank,

+Rafael

On Wed, Aug 07, 2024 at 11:34:48AM -0400, Frank Li wrote:
> On Wed, Aug 07, 2024 at 04:43:49PM +0200, Francesco Dolcini wrote:
> > From: Francesco Dolcini <francesco.dolcini@toradex.com>
> >
> > On i.MX8 the FEC PPS channel is routed to the instance 1, not to the
> > default 0.
> 
> According to my understand, it should be board level configuration. FEC
> support output pps to any one. choose which one by board design.

This seems different from the information we got from NXP some time ago,
unfortunately this was happening over some private email exchange and
not documented anywhere public. But the message was about SoC internal
routing, not something at the board level, at least for i.MX8 SoCs that
is what this patch is changing.

For example to use PPS on i.MX8QXP we need to have this

IMX8QM_ENET0_REFCLK_125M_25M_CONN_ENET0_PPS 0x06000020

pinctrl configuration _and_ use PPS channel 1. Same is for i.MX8QP.

Maybe Rafael can provide you some more details and the name of the
person that provided this information.

And maybe you can also try to double check this internally within NXP.

Depending on what we find out we can decide if this patch needs to be
dropped or not.

Francesco
Rafael Beims Aug. 7, 2024, 7:48 p.m. UTC | #3
On 07/08/2024 14:51, Francesco Dolcini wrote:
> Hello Frank,
>
> +Rafael
>
> On Wed, Aug 07, 2024 at 11:34:48AM -0400, Frank Li wrote:
>> On Wed, Aug 07, 2024 at 04:43:49PM +0200, Francesco Dolcini wrote:
>>> From: Francesco Dolcini <francesco.dolcini@toradex.com>
>>>
>>> On i.MX8 the FEC PPS channel is routed to the instance 1, not to the
>>> default 0.
>> According to my understand, it should be board level configuration. FEC
>> support output pps to any one. choose which one by board design.
> This seems different from the information we got from NXP some time ago,
> unfortunately this was happening over some private email exchange and
> not documented anywhere public. But the message was about SoC internal
> routing, not something at the board level, at least for i.MX8 SoCs that
> is what this patch is changing.
>
> For example to use PPS on i.MX8QXP we need to have this
>
> IMX8QM_ENET0_REFCLK_125M_25M_CONN_ENET0_PPS 0x06000020
>
> pinctrl configuration _and_ use PPS channel 1. Same is for i.MX8QP.
>
> Maybe Rafael can provide you some more details and the name of the
> person that provided this information.
>
> And maybe you can also try to double check this internally within NXP.
>
> Depending on what we find out we can decide if this patch needs to be
> dropped or not.
>
> Francesco
>
Hello Frank,

We have received the information from NXP support that the iMX8X only 
supports channel 1. Here's the link of the public question I asked:

https://community.nxp.com/t5/i-MX-Processors/IMX8X-PPS-output-configuration/m-p/1552154

Unfortunately, the response came directly to my e-mail address with no 
public update, but you can probably check the internal support case 
number 00500877.

Here's an excerpt from the response:

> I have checked this issue from soc level, the pps signal is routed to 
the 1588_timer1, not routed to 1588_timer0( being used in code default).

At the time, I asked a followup question:

> Can I assume that  IMX8QM_ENET0_REFCLK_125M_25M_CONN_ENET1_PPS is connected to 
1588_timer3 then?

To which I got the reply:

> No, ENET1_PPS is also routed through timer1. One can't use ENET0_PPS and 
ENET1_PPS at a same time because of same routing path.

I also asked for confirmation if this behavior was the same on the 
iMX8Q, which I didn't get. However, we had another customer also 
reporting problems getting the PPS output to work on our Apalis iMX8QM 
module, and in this case, the change to channel 1 also made it work. 
This leads me to believe that the iMX8X and iMX8Q are behaving the same 
way in this regard.

We would really appreciate some clarification if we got some of the 
details wrong.

Rafael
Frank Li Aug. 7, 2024, 8:25 p.m. UTC | #4
On Wed, Aug 07, 2024 at 04:48:19PM -0300, Rafael Beims wrote:
> On 07/08/2024 14:51, Francesco Dolcini wrote:
> > Hello Frank,
> >
> > +Rafael
> >
> > On Wed, Aug 07, 2024 at 11:34:48AM -0400, Frank Li wrote:
> > > On Wed, Aug 07, 2024 at 04:43:49PM +0200, Francesco Dolcini wrote:
> > > > From: Francesco Dolcini <francesco.dolcini@toradex.com>
> > > >
> > > > On i.MX8 the FEC PPS channel is routed to the instance 1, not to the
> > > > default 0.
> > > According to my understand, it should be board level configuration. FEC
> > > support output pps to any one. choose which one by board design.
> > This seems different from the information we got from NXP some time ago,
> > unfortunately this was happening over some private email exchange and
> > not documented anywhere public. But the message was about SoC internal
> > routing, not something at the board level, at least for i.MX8 SoCs that
> > is what this patch is changing.
> >
> > For example to use PPS on i.MX8QXP we need to have this
> >
> > IMX8QM_ENET0_REFCLK_125M_25M_CONN_ENET0_PPS 0x06000020
> >
> > pinctrl configuration _and_ use PPS channel 1. Same is for i.MX8QP.
> >
> > Maybe Rafael can provide you some more details and the name of the
> > person that provided this information.
> >
> > And maybe you can also try to double check this internally within NXP.
> >
> > Depending on what we find out we can decide if this patch needs to be
> > dropped or not.
> >
> > Francesco
> >
> Hello Frank,
>
> We have received the information from NXP support that the iMX8X only
> supports channel 1. Here's the link of the public question I asked:
>
> https://community.nxp.com/t5/i-MX-Processors/IMX8X-PPS-output-configuration/m-p/1552154
>
> Unfortunately, the response came directly to my e-mail address with no
> public update, but you can probably check the internal support case number
> 00500877.
>
> Here's an excerpt from the response:
>
> > I have checked this issue from soc level, the pps signal is routed to
> the 1588_timer1, not routed to 1588_timer0( being used in code default).
>
> At the time, I asked a followup question:
>
> > Can I assume that  IMX8QM_ENET0_REFCLK_125M_25M_CONN_ENET1_PPS is
> > connected to
> 1588_timer3 then?
>
> To which I got the reply:
>
> > No, ENET1_PPS is also routed through timer1. One can't use ENET0_PPS and
> ENET1_PPS at a same time because of same routing path.
>
> I also asked for confirmation if this behavior was the same on the iMX8Q,
> which I didn't get. However, we had another customer also reporting problems
> getting the PPS output to work on our Apalis iMX8QM module, and in this
> case, the change to channel 1 also made it work. This leads me to believe
> that the iMX8X and iMX8Q are behaving the same way in this regard.
>
> We would really appreciate some clarification if we got some of the details
> wrong.

I checked some documents. channel0 route to internal eDMA as dma-request.
If some boards use it as AVB/MCR. it should be set to 0. If need route
out chip, it should use channel 1 as pps.

So I prefer put it into board level files for difference user case.

Frank

>
> Rafael
>
Francesco Dolcini Aug. 8, 2024, 6:30 a.m. UTC | #5
Hello Frank,

On Wed, Aug 07, 2024 at 04:25:29PM -0400, Frank Li wrote:
> On Wed, Aug 07, 2024 at 04:48:19PM -0300, Rafael Beims wrote:
> > On 07/08/2024 14:51, Francesco Dolcini wrote:
> > > On Wed, Aug 07, 2024 at 11:34:48AM -0400, Frank Li wrote:
> > > > On Wed, Aug 07, 2024 at 04:43:49PM +0200, Francesco Dolcini wrote:
> > > > > From: Francesco Dolcini <francesco.dolcini@toradex.com>
> > > > >
> > > > > On i.MX8 the FEC PPS channel is routed to the instance 1, not to the
> > > > > default 0.
> > > > According to my understand, it should be board level configuration. FEC
> > > > support output pps to any one. choose which one by board design.
> > > This seems different from the information we got from NXP some time ago,
> > > unfortunately this was happening over some private email exchange and
> > > not documented anywhere public. But the message was about SoC internal
> > > routing, not something at the board level, at least for i.MX8 SoCs that
> > > is what this patch is changing.
> > >
> > > For example to use PPS on i.MX8QXP we need to have this
> > >
> > > IMX8QM_ENET0_REFCLK_125M_25M_CONN_ENET0_PPS 0x06000020
> > >
> > > pinctrl configuration _and_ use PPS channel 1. Same is for i.MX8QP.
> > >

...

> > We have received the information from NXP support that the iMX8X only
> > supports channel 1. Here's the link of the public question I asked:
> >
> > https://community.nxp.com/t5/i-MX-Processors/IMX8X-PPS-output-configuration/m-p/1552154
> >
> > Unfortunately, the response came directly to my e-mail address with no
> > public update, but you can probably check the internal support case number
> > 00500877.

...

> 
> I checked some documents. channel0 route to internal eDMA as dma-request.
> If some boards use it as AVB/MCR. it should be set to 0. If need route
> out chip, it should use channel 1 as pps.
> 
> So I prefer put it into board level files for difference user case.

Fine for me and thanks for looking into this topic.

Let's drop this patch, we'll take care of having the property in the
appropriate board file.

Francesco
Francesco Dolcini Aug. 8, 2024, 9:57 p.m. UTC | #6
Hello net people,

On Wed, Aug 07, 2024 at 04:43:45PM +0200, Francesco Dolcini wrote:
> From: Francesco Dolcini <francesco.dolcini@toradex.com>
> 
> Make the FEC Ethernet PPS channel configurable from device tree.

I realized that I forgot the `net-next` subject patch prefix on this series,
let me know if I should re-send it with it added, thanks.

Francesco
Jakub Kicinski Aug. 9, 2024, 2:58 a.m. UTC | #7
On Thu, 8 Aug 2024 23:57:23 +0200 Francesco Dolcini wrote:
> On Wed, Aug 07, 2024 at 04:43:45PM +0200, Francesco Dolcini wrote:
> > From: Francesco Dolcini <francesco.dolcini@toradex.com>
> > 
> > Make the FEC Ethernet PPS channel configurable from device tree.  
> 
> I realized that I forgot the `net-next` subject patch prefix on this series,
> let me know if I should re-send it with it added, thanks.

Hm, normally I'd say no, but we also didn't get patch 4 CCed to us.
We use patchwork for a lot of things (including CI ingest) and if
we don't get all the patches patchwork considers the series incomplete.
Could you either repost and CC netdev@ on all 4 or repost just the 
3 patches meant for netdev as a standalone series?