From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp28.bhosted.nl (smtp28.bhosted.nl [94.124.121.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A955B2D4B68 for ; Fri, 19 Sep 2025 07:32:31 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=94.124.121.40 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1758267153; cv=none; b=OJ/IUam4unEHZ4uPCYsLSwHgHccWCsQJVh2inIOg1dFpb7XVQL5W6kIVTn2PBrJ0SMIZNuYb+DVH762K5II1+6c/j90SzaGqzsQwMNNXsjbUiDEFtOj+Z1HJREmu/V+B9hm032MwH1Q5FS/oCSLdrzkr8gP+eC10dc/GJi0wF0A= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1758267153; c=relaxed/simple; bh=QDBKRYM86Xj8SvcY0SO2armSTunx77RSYXQE6GhjxRQ=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=X7c2ew2kElnYums1WQcjrJkWpSUrwuGUxJwhChITy2akXoKFV+JPHFpBUTAc9mMXd8TUkW/gOgLNDQcyp8FD4BycvulmOQ8SKF8/7QcN8F2FMtkQMJrb+1DN1w2FdyKLClyLnvPnS8VT1Z7qfwMsAVdKGC1zO8V3ZNS0x6Zi8X4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=protonic.nl; spf=pass smtp.mailfrom=protonic.nl; dkim=pass (2048-bit key) header.d=protonic.nl header.i=@protonic.nl header.b=pZW+VN/z; arc=none smtp.client-ip=94.124.121.40 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=protonic.nl Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=protonic.nl Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=protonic.nl header.i=@protonic.nl header.b="pZW+VN/z" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonic.nl; s=202111; h=content-transfer-encoding:content-type:mime-version:references:in-reply-to: message-id:subject:cc:to:from:date:from; bh=hb4JA4fTwI5S97+qQFy6E++mwXzjCgpI2x6Kz7sl75c=; b=pZW+VN/zunUr8uqIHPr8ZaMHKz5+wpBS9g8mkldWI1GlhOZ01lslSu5UYQzFFEQjJGU6szmDdCNKa ySq3Dw2xuCzKeSw0pwSskYbqCuz5OEfnY7UVSvHFYKJCvZo6jQszXDWFPZ9S0lHA5mO4bq7UxDJs1q xBBj42CcHzqdnv8cwgal4DV4B9DJtas2zLBBc+SXtplp2DWYC4MvM8ZMDPG+mJQw0QhmfFYwq5zgRO jhAfBFwCAQrZ41fpzXDmJErIh4nugZek44vJMRmcedZPGs7MtWD1uwQ/GB2R2Bj0uLtVXBoG70fM67 tPnUN4xs3iJtqwqVRpwzZVXsJ+2N6Yg== X-MSG-ID: a2929316-952a-11f0-8678-0050568164d1 Date: Fri, 19 Sep 2025 09:31:19 +0200 From: David Jander To: Oleksij Rempel Cc: Andrew Lunn , Jonas Rebmann , Vladimir Oltean , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Liam Girdwood , Mark Brown , Shengjiu Wang , Shawn Guo , Sascha Hauer , Fabio Estevam , Pengutronix Kernel Team , Vladimir Oltean , netdev@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-sound@vger.kernel.org, imx@lists.linux.dev, linux-arm-kernel@lists.infradead.org, Lucas Stach Subject: Re: [PATCH v2 3/3] arm64: dts: add Protonic PRT8ML board Message-ID: <20250919093119.24d2711a@erd003.prtnl> In-Reply-To: References: <20250918-imx8mp-prt8ml-v2-0-3d84b4fe53de@pengutronix.de> <20250918-imx8mp-prt8ml-v2-3-3d84b4fe53de@pengutronix.de> <20250918165156.10e55b85@erd003.prtnl> <7f1d9289-4102-4db9-a2bb-ff270e8871b7@lunn.ch> <20250918173347.28db5569@erd003.prtnl> Organization: Protonic Holland X-Mailer: Claws Mail 4.3.1 (GTK 3.24.49; x86_64-pc-linux-gnu) Precedence: bulk X-Mailing-List: devicetree@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Fri, 19 Sep 2025 07:08:45 +0200 Oleksij Rempel wrote: > On Thu, Sep 18, 2025 at 05:33:47PM +0200, David Jander wrote: > > On Thu, 18 Sep 2025 17:04:55 +0200 > > Andrew Lunn wrote: > > > > > > Yes, unfortunately the SJA1105Q does not support PAUSE frames, and the i.MX8MP > > > > FEC isn't able to sustain 1000Mbps (only about 400ish) due to insufficient > > > > internal bus bandwidth. It will generate PAUSE frames, but the SJA1105Q > > > > ignores these, leading to packet loss, which is obviously worse than > > > > restricting this link to 100Mbps. Ironically both chips are from the same > > > > manufacturer, yet are incompatible in this regard. > > > > > > Thanks for the explanation. Maybe add a comment that the bandwidth is > > > limited due to the lack of flow control resulting in packet loss in > > > the FEC. > > > > > > Anything which looks odd deserves a comment, otherwise somebody will > > > question it.... > > > > Yes! This is a golden tip. Ironically what I said above is incorrect. Sorry > > for the noise. > > > > Ftr: I wrote this DT about 4 years ago, so my memory failed me, and a comment > > in the code would have saved me this embarrassment ;-) > > > > The comment above applies to the i.MX6 SoC's which had this limitation. On the > > i.MX8MP we had a different problem that also caused the SJA1105Q not to work > > reliably at 1000Mbps either. We haven't been able to find the issue, but so far > > this switch hasn't been able to work at 1000Mbps reliable on any platform, > > possibly for different reasons in each case. > > May be it is doe to RGMII clock switching issue and the requirement to > have specific silence time for proper clock frequency detection on the > switch side? I doubt it is that, because it works well at 100Mbps still in RGMII mode, and according to the documentation the delay line is active for all rates. OTOH, this switch probably has some other issues related to the RXC delay line. It is always the RX path (RX at the switch, TX at the MAC) that randomly does not work. OT (but still posting in case someone here knows something): Coincidentally I am currently working on a different design with a SJA1105Q switch connected to a LAN743X MAC. The complication is that this MAC cannot disable the TXC (RXC at the switch) at all. Still working on this, but right now it looks like not even with the RX delay line deactivated (doing the delay at the MAC) is the switch working reliably (at 1000Mbps). Investigation still on-going so take with grain of salt. > Or it is just artifact from iMX6 platform and it should be retested? I remember having tested it and it not working reliably, but that was 4 years ago or so. Drivers have evolved since, so maybe it is worth testing again? Best regards, -- David Jander