From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.1 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D8305C0650F for ; Sun, 11 Aug 2019 16:03:07 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id A62DB2085A for ; Sun, 11 Aug 2019 16:03:07 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=lunn.ch header.i=@lunn.ch header.b="he7g9m19" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726469AbfHKQDG (ORCPT ); Sun, 11 Aug 2019 12:03:06 -0400 Received: from vps0.lunn.ch ([185.16.172.187]:51272 "EHLO vps0.lunn.ch" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726014AbfHKQDG (ORCPT ); Sun, 11 Aug 2019 12:03:06 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lunn.ch; s=20171124; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID: Subject:Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=X8vY8SU32ylGHmsaMJSxRXMQ4AplM5ck8Z9fOiI/VVU=; b=he7g9m19SQBkXvaTUxHONOAJB9 SgctLxfkW1E3PRFxDIdwX02eIxoJHJygoovruMY/dLF6ZD3Aj7hWCzT4lm1NNQ1dO6IShokyz+3bp 82gI7kyReD7cZ5tdwPAljDzP41MQf+L0CF8mIetKufw2zYO66rGvxRzfHr8MaccsQHZY=; Received: from andrew by vps0.lunn.ch with local (Exim 4.89) (envelope-from ) id 1hwqJE-00046n-BI; Sun, 11 Aug 2019 18:03:04 +0200 Date: Sun, 11 Aug 2019 18:03:04 +0200 From: Andrew Lunn To: Vladimir Oltean Cc: Russell King - ARM Linux admin , Florian Fainelli , netdev , Hubert Feurstein , Fabio Estevam , linux-arm-kernel@lists.infradead.org, Heiner Kallweit Subject: Re: [BUG] fec mdio times out under system stress Message-ID: <20190811160304.GD14290@lunn.ch> References: <20190811133707.GC13294@shell.armlinux.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org > I think a better question is why is the FEC MDIO controller configured > to emit interrupts anyway (especially since the API built on top does > not benefit in any way from this)? Hubert (copied) sent an interesting > email very recently where he pointed out that this is one of the main > sources of jitter when reading the PTP clock on a Marvell switch > attached over MDIO. Hi Vladimir One reason is runtime power management. For a write operation, you could set it going and return immediately. Many drivers do, and then when the next read/write operation comes along, they poll in a loop waiting for the device to go idle, if it was still busy from the last operation. However, FEC supports runtime PM. When an MDIO read/write call is made, it calls runtime PM functions to indicate the device is active. Once it has completed the MDIO transaction, it calls runtime PM functions to indicate the device is inactive. These transitions can cause clocks to be enabled/disabled. If we don't wait around for the operation to complete, the clock could be disabled too early, and bad things would happen. You could replace the interrupt with a sleeping poll, but my guess would be, that has more jitter than using an interrupt. Andrew