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=-7.4 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED,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 80864C2D0A3 for ; Tue, 27 Oct 2020 00:17:40 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 4A3BC20727 for ; Tue, 27 Oct 2020 00:17:40 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2440809AbgJ0ARi (ORCPT ); Mon, 26 Oct 2020 20:17:38 -0400 Received: from mail.kernel.org ([198.145.29.99]:40408 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2440744AbgJ0ARf (ORCPT ); Mon, 26 Oct 2020 20:17:35 -0400 Received: from [192.168.0.244] (118-211-2-196.tpgi.com.au [118.211.2.196]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 1229520708; Tue, 27 Oct 2020 00:17:32 +0000 (UTC) Subject: Re: [EXT] Re: [PATCH] net: ethernet: fec: Replace interrupt driven MDIO with polled IO To: Andy Duan , Andrew Lunn , Dave Karr , Clemens Gruber Cc: Chris Heally , "netdev@vger.kernel.org" References: <20201020024000.GV456889@lunn.ch> <9fa61ea8-11b4-ef3c-c04e-cb124490c9ae@linux-m68k.org> <20201021133758.GL139700@lunn.ch> <16e85e61-ed25-c6be-ed4a-4c4708e724ea@linux-m68k.org> From: Greg Ungerer Message-ID: Date: Tue, 27 Oct 2020 10:17:30 +1000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org Hi Andy, On 22/10/20 7:04 pm, Andy Duan wrote: > From: Greg Ungerer Sent: Thursday, October 22, 2020 9:14 AM >> Hi Andrew, >> >> On 21/10/20 11:37 pm, Andrew Lunn wrote: >>>> + if (fep->quirks & FEC_QUIRK_CLEAR_SETUP_MII) { >>>> + /* Clear MMFR to avoid to generate MII event by writing >> MSCR. >>>> + * MII event generation condition: >>>> + * - writing MSCR: >>>> + * - mmfr[31:0]_not_zero & mscr[7:0]_is_zero & >>>> + * mscr_reg_data_in[7:0] != 0 >>>> + * - writing MMFR: >>>> + * - mscr[7:0]_not_zero >>>> + */ >>>> + writel(0, fep->hwp + FEC_MII_DATA); >>>> + } >>> >>> Hi Greg >>> >>> The last time we discussed this, we decided that if you cannot do the >>> quirk, you need to wait around for an MDIO interrupt, e.g. call >>> fec_enet_mdio_wait() after setting FEC_MII_SPEED register. >>> >>>> >>>> writel(fep->phy_speed, fep->hwp + FEC_MII_SPEED); >> >> The code following this is: >> >> writel(fep->phy_speed, fep->hwp + FEC_MII_SPEED); >> >> /* Clear any pending transaction complete indication */ >> writel(FEC_ENET_MII, fep->hwp + FEC_IEVENT); >> >> >> So this is forcing a clear of the event here. Is that not good enough? >> >> For me on my ColdFire test target I always get a timeout if I wait for a >> FEC_IEVENT after the FEC_MII_SPEED write. >> >> Regards >> Greg > > Dave Karr's last patch can fix the issue, but it may introduce 30ms delay during boot. > Greg's patch is to add quirk flag to distinguish platform before clearing mmfr operation, > which also can fix the issue. Do you mean that we can use either fix - and that is ok for all hardware types? Regards Greg