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.6 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS, USER_AGENT_MUTT autolearn=ham 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 C4CAEC65BAE for ; Thu, 13 Dec 2018 12:34:16 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 83AAF20645 for ; Thu, 13 Dec 2018 12:34:16 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="H0Pt1cJQ"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="IGmM+31k"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=lunn.ch header.i=@lunn.ch header.b="pkOwiKnl" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 83AAF20645 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=lunn.ch Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=N+pVrYMH/JfpkeGA0FQV1um2ASPbicpPHmjaPmy5hVM=; b=H0Pt1cJQ6luSvT JPe25aLXA6QK98Lj0gEGC4UPikOQHfhSL7ruXaU6WEprZ4ZMKSowZXVRfJV7ObCKI0ad8c11g08qL LUxJIOTC03TW06rGgCT9sitzQg0puzJ8YA/5T3fSol90Xlm9v8pst2I3FYh8Wv2HGqOne+jN4stzK fsE3aJIAs7Gk1lrjZACtrBenVFMWNhiKvXNUt1USCEHsFkKmrQ7quzAfvy1jxS5Xi2AzZoHj1d0es O+w2RuVnUDarebwX+a4LkDpIZL7WW+4kszT/XzVU5pmhNQ0E2uOZh1kVqftXhdDvcGZ9kK/QTKU2f u+v48Sb4SvmCBP2pMAPg==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux)) id 1gXQBw-00014E-B7; Thu, 13 Dec 2018 12:34:12 +0000 Received: from casper.infradead.org ([2001:8b0:10b:1236::1]) by bombadil.infradead.org with esmtps (Exim 4.90_1 #2 (Red Hat Linux)) id 1gXQBu-000143-ST; Thu, 13 Dec 2018 12:34:10 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; 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=UrmuoJqKFGKpV/RldOB6vPOUSOJxY3/IhP0qkRWMASc=; b=IGmM+31kgitMt/v6yLfmFYnv+ HcgMbCxUFmEVGw/RJU0y8Y1smTeIHpdjVuU1KY6ZoaaAKzhzfbFB52OTfWncOy4l1p4Q988D5ydMM ZTZtkxaExXMTYmkWK3x/UFWrv8OVoQqroOOp6wD7Prgfn29UOKMN2WWOoGvf9by+3ZQW8np2gjosg Q+oaQPUxDCO6MP2bh+nIZGc5oJYq4dMe2EhpPhamsw7mewYmpPTmnAH3ivaVFA/2MOsXKGCCswUNW q5MTSput537iYP32AuLSU3yXHldHVrbjGMjimZIxQnD4pE3OhGJIjUFxbEZwDsf8UwJZCxB8fU6wD Mf+Lfyy0w==; Received: from vps0.lunn.ch ([185.16.172.187]) by casper.infradead.org with esmtps (Exim 4.90_1 #2 (Red Hat Linux)) id 1gXQBr-0007cD-NW; Thu, 13 Dec 2018 12:34:09 +0000 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; bh=UrmuoJqKFGKpV/RldOB6vPOUSOJxY3/IhP0qkRWMASc=; b=pkOwiKnl+wQK1hdyss1GUSqWvWEohA7LOnbMBxofBEJFY3c4MK35Om2k18keCGEASgHeENVy5bgewY54tx44jng0t16v9lzdDuxHyWVFKqDsbQ4XczNlw/qvStOo54UzFoxfv/h9IN5i9hNWBgSII4e7xHwAIb8Ghdsx2359lIE=; Received: from andrew by vps0.lunn.ch with local (Exim 4.84_2) (envelope-from ) id 1gXQBW-0002ps-G0; Thu, 13 Dec 2018 13:33:46 +0100 Date: Thu, 13 Dec 2018 13:33:46 +0100 From: Andrew Lunn To: Biao Huang Subject: Re: [v7, PATCH 1/2] net:stmmac: dwmac-mediatek: add support for mt2712 Message-ID: <20181213123346.GF1605@lunn.ch> References: <1544666173-5121-1-git-send-email-biao.huang@mediatek.com> <1544666173-5121-2-git-send-email-biao.huang@mediatek.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1544666173-5121-2-git-send-email-biao.huang@mediatek.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20181213_123407_812850_EB933894 X-CRM114-Status: GOOD ( 14.08 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: mark.rutland@arm.com, devicetree@vger.kernel.org, nelson.chang@mediatek.com, netdev@vger.kernel.org, liguo.zhang@mediatek.com, joabreu@synopsys.com, linux-kernel@vger.kernel.org, matthias.bgg@gmail.com, robh+dt@kernel.org, linux-mediatek@lists.infradead.org, honghui.zhang@mediatek.com, yt.shen@mediatek.com, davem@davemloft.net, linux-arm-kernel@lists.infradead.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi Biao > + case PHY_INTERFACE_MODE_RGMII: > + /* the PHY is not responsible for inserting any internal > + * delay by itself in PHY_INTERFACE_MODE_RGMII case, > + * so Ethernet MAC will insert delays for both transmit > + * and receive path here. > + */ What if the PCB designed has decided to do a kink in the clock to add the delays? I don't think any of these delays should depend on the PHY interface mode. It is up to the device tree writer to set both the PHY delay and the MAC delay, based on knowledge of the board, including any kicks in the tracks. The driver should then do what it is told. > + if (!of_property_read_u32(plat->np, "mediatek,tx-delay-ps", &tx_delay_ps)) { > + if (tx_delay_ps < plat->variant->tx_delay_max) { > + mac_delay->tx_delay = tx_delay_ps; > + } else { > + dev_err(plat->dev, "Invalid TX clock delay: %dps\n", tx_delay_ps); > + return -EINVAL; > + } > + } > + > + if (!of_property_read_u32(plat->np, "mediatek,rx-delay-ps", &rx_delay_ps)) { > + if (rx_delay_ps < plat->variant->rx_delay_max) { > + mac_delay->rx_delay = rx_delay_ps; > + } else { > + dev_err(plat->dev, "Invalid RX clock delay: %dps\n", rx_delay_ps); > + return -EINVAL; > + } > + } > + > + mac_delay->tx_inv = of_property_read_bool(plat->np, "mediatek,txc-inverse"); > + mac_delay->rx_inv = of_property_read_bool(plat->np, "mediatek,rxc-inverse"); > + mac_delay->fine_tune = of_property_read_bool(plat->np, "mediatek,fine-tune"); Why is fine tune needed? If the requested delay can be done using fine tune, it should use fine tune. If not, it should use rough tune. The driver can work this out itself. Thanks Andrew _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel