lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZrPYOWA3FESx197L@lizhi-Precision-Tower-5810>
Date: Wed, 7 Aug 2024 16:25:29 -0400
From: Frank Li <Frank.li@....com>
To: Rafael Beims <rafael@...ms.me>
Cc: Francesco Dolcini <francesco@...cini.it>, Rob Herring <robh@...nel.org>,
	Krzysztof Kozlowski <krzk+dt@...nel.org>,
	Conor Dooley <conor+dt@...nel.org>, Shawn Guo <shawnguo@...nel.org>,
	Sascha Hauer <s.hauer@...gutronix.de>,
	Pengutronix Kernel Team <kernel@...gutronix.de>,
	Fabio Estevam <festevam@...il.com>,
	Francesco Dolcini <francesco.dolcini@...adex.com>,
	devicetree@...r.kernel.org, imx@...ts.linux.dev,
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
	rafael.beims@...adex.com
Subject: Re: [PATCH v1 4/4] arm64: dts: imx8-ss-conn: add PPS channel to the
 FEC nodes

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@...adex.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
>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ