Messages in this thread | | | From | Shenwei Wang <> | Subject | RE: [EXT] Re: [PATCH v2 net 2/2] net: stmmac: dwmac-imx: pause the TXC clock in fixed-link | Date | Fri, 28 Jul 2023 16:09:29 +0000 |
| |
> -----Original Message----- > From: Will Deacon <will@kernel.org> > Sent: Friday, July 28, 2023 10:36 AM > To: Russell King (Oracle) <linux@armlinux.org.uk> > Cc: Andrew Halaney <ahalaney@redhat.com>; Shenwei Wang > <shenwei.wang@nxp.com>; David S. Miller <davem@davemloft.net>; Eric > Dumazet <edumazet@google.com>; Jakub Kicinski <kuba@kernel.org>; Paolo > Abeni <pabeni@redhat.com>; Maxime Coquelin > <mcoquelin.stm32@gmail.com>; Shawn Guo <shawnguo@kernel.org>; Sascha > Hauer <s.hauer@pengutronix.de>; Neil Armstrong <neil.armstrong@linaro.org>; > Kevin Hilman <khilman@baylibre.com>; Vinod Koul <vkoul@kernel.org>; Chen- > Yu Tsai <wens@csie.org>; Jernej Skrabec <jernej.skrabec@gmail.com>; Samuel > Holland <samuel@sholland.org>; Giuseppe Cavallaro > <peppe.cavallaro@st.com>; Alexandre Torgue <alexandre.torgue@foss.st.com>; > Jose Abreu <joabreu@synopsys.com>; Pengutronix Kernel Team > <kernel@pengutronix.de>; Fabio Estevam <festevam@gmail.com>; dl-linux-imx > <linux-imx@nxp.com>; Jerome Brunet <jbrunet@baylibre.com>; Martin > Blumenstingl <martin.blumenstingl@googlemail.com>; Bhupesh Sharma > <bhupesh.sharma@linaro.org>; Nobuhiro Iwamatsu > <nobuhiro1.iwamatsu@toshiba.co.jp>; Simon Horman > <simon.horman@corigine.com>; Bartosz Golaszewski > <bartosz.golaszewski@linaro.org>; Wong Vee Khee <veekhee@apple.com>; > Revanth Kumar Uppala <ruppala@nvidia.com>; Jochen Henneberg > <jh@henneberg-systemdesign.com>; netdev@vger.kernel.org; linux-stm32@st- > md-mailman.stormreply.com; linux-arm-kernel@lists.infradead.org; linux- > kernel@vger.kernel.org; linux-amlogic@lists.infradead.org; imx@lists.linux.dev; > Frank Li <frank.li@nxp.com> > Subject: [EXT] Re: [PATCH v2 net 2/2] net: stmmac: dwmac-imx: pause the TXC > clock in fixed-link > > Caution: This is an external email. Please take care when clicking links or > opening attachments. When in doubt, report the message using the 'Report this > email' button > > > On Fri, Jul 28, 2023 at 04:22:19PM +0100, Russell King (Oracle) wrote: > > On Thu, Jul 27, 2023 at 01:36:45PM -0500, Andrew Halaney wrote: > > > I don't have any documentation for the registers here, and as you > > > can see I'm an amateur with respect to memory ordering based on my > > > prior comment. > > > > > > But you: > > > > > > 1. Read intf_reg_off into variable iface > > > 2. Write the RESET_SPEED for the appropriate mode to MAC_CTRL_REG > > > 3. wmb() to ensure that write goes through > > > > I wonder about whether that wmb() is required. If the mapping is > > device-like rather than memory-like, the write should be committed > > before the read that regmap_update_bits() does according to the ARM > > memory model. Maybe a bit of information about where this barrier has > > come from would be good, and maybe getting it reviewed by the > > arm64 barrier specialist, Will Deacon. :) > > > > wmb() is normally required to be paired with a rmb(), but we're not > > talking about system memory here, so I also wonder whether wmb() is > > the correct barrier to use. > > Yes, I don't think wmb() is the right thing here. If you need to ensure that the > write to MAC_CTRL_REG has taken effect, then you'll need to go through some > device-specific sequence which probably involves reading something back. If you > just need things to arrive in order eventually, the memory type already gives you > that. > > It's also worth pointing out that udelay() isn't necessarily ordered wrt MMIO > writes, so that usleep_range() might need some help as well. > Non-relaxed MMIO reads, however, _are_ ordered against a subsequent > udelay(), so if you add the readback then this might all work out. >
1. Write RESET_SPEED 2. Write 0 to MX93_GPR_ENET_QOS_INTF_MODE_MASK 3. usleep_range() 4. Restore MX93_GPR_ENET_QOS_CLK_GEN_EN | iface
In the above example, if a readback after step #2 could ensure sufficient time has passed before step #4, the wmb() here should be abandoned.
Thanks, Shenwei
> I gave a (slightly dated) talk about some of this at ELC a while back: > > https://www.yo/ > utube.com%2Fwatch%3Fv%3Di6DayghhA8Q&data=05%7C01%7Cshenwei.wang > %40nxp.com%7C32396fd0396e4e46975f08db8f806680%7C686ea1d3bc2b4c6fa > 92cd99c5c301635%7C0%7C0%7C638261553857503588%7CUnknown%7CTWFp > bGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6 > Mn0%3D%7C3000%7C%7C%7C&sdata=X5CQrQEVmUjYafYJ%2BzcnGXI9mhDT% > 2BMzDazGHOcoomas%3D&reserved=0 > > which might help. > > Will
| |