Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754103AbbLOOvM (ORCPT ); Tue, 15 Dec 2015 09:51:12 -0500 Received: from mout.kundenserver.de ([217.72.192.75]:51029 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752923AbbLOOvI (ORCPT ); Tue, 15 Dec 2015 09:51:08 -0500 From: Arnd Bergmann To: Christopher Covington Cc: Florian Fainelli , Gilad Avidov , netdev@vger.kernel.org, linux-kernel@vger.kernel.org, devicetree@vger.kernel.org, linux-arm-msm@vger.kernel.org, sdharia@codeaurora.org, shankerd@codeaurora.org, timur@codeaurora.org, gregkh@linuxfoundation.org, vikrams@codeaurora.org Subject: Re: [PATCH] net: emac: emac gigabit ethernet controller driver Date: Tue, 15 Dec 2015 15:50:59 +0100 Message-ID: <1594472.ixZvj6PYdz@wuerfel> User-Agent: KMail/4.11.5 (Linux/3.16.0-10-generic; KDE/4.11.5; x86_64; ; ) In-Reply-To: <567023F8.80302@codeaurora.org> References: <1450138740-32562-1-git-send-email-gavidov@codeaurora.org> <566F6F3D.5050004@gmail.com> <567023F8.80302@codeaurora.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:BPnybHb+4zRjaTjK9uT4IzWiImigzeX/FpoRO1EuXQTIhrC8yAz uioSHA5Tek9g6gVat5ydB1pUIYc/ecsLo1C+ESV52aAx/BEmyFMMBy6NMrVCWU17ZHx5smt V8nU3hKmYMN+xQMdf0Yzs1UUdNDBH1SRl/STZl+KivaApRngZ0T7Qz9G1k5IgGzX7Zly2a8 7cDI0kGFjnXyf/dN83faQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:E4hqMjGDbe8=:3/39reRQlalX5GOch6cqMh XP/2pdvCWgPRua8NsD19LqA0akXoAWVEDpBcucXp8/Wh+kRXXxFa4C9X4+DLVudeicFEbi5mz Qy3N6kKdI/e+qae9eKDG0j9x1ncAXxNlq4pHC189zSOYndux+ek9TLUxJaRLjeVNanbXv62cM sS1uALE/WXbTU557xUQH1BLEBsDcE7VDWrBe0s86anpx+5/+Y/kUU4/3jxRR2Jw9TvK/baK+b uR8CvOpR4BeWwYY0tQMFYQHBCnlNZPrtPFG90GnOEupgihKta0eaepDpKOaN5iBrx7ucpqqGf kLehpe7GinYI7p2uPF2lW1xzxMGka0Hrg7r+3UELa5LHS95V6hm30bT+VfRRWZLcaFx3ufxub oZUcRon4H3owHl/wlJ8x3YOU1zk9izQG/lgCqoADk1/r5T+nEwndiIU1Z0Lef3Worwsry3fO+ CG/HztWOCJWnEWf9MCuxwJ8gQaARw0j/jnwoKDenZWBPdBUj5oK4ysD9FN7oegc9kszPnyjpY jqnPz47xnAQ/3H2XagH9iGnXd1j9HmF9UJR69PzorOTc4DTu8/T6oeNRRkyU7VZpOH7E2NHsC FAN6hGuXGfXDibABa4Nfprw2ZQ6GY8zWs7neQmGPbYg2ZWwA5sQ9z6BmT01cN+hmhS76WMXPN ZxCtoObbYOCHolCavgPoH2Co1SiUuScXOm9N5YC2sHSat/+gyL6EXKPbBbm3Vxmgzb8YkKrwN SEQI/evVZjnHbhg2 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2961 Lines: 68 On Tuesday 15 December 2015 09:30:16 Christopher Covington wrote: > > On 12/14/2015 08:39 PM, Florian Fainelli wrote: > > On 14/12/15 16:19, Gilad Avidov wrote: > > >> +static void emac_mac_irq_enable(struct emac_adapter *adpt) > >> +{ > >> + int i; > >> + > >> + for (i = 0; i < EMAC_NUM_CORE_IRQ; i++) { > >> + struct emac_irq *irq = &adpt->irq[i]; > >> + const struct emac_irq_config *irq_cfg = &emac_irq_cfg_tbl[i]; > >> + > >> + writel_relaxed(~DIS_INT, adpt->base + irq_cfg->status_reg); > >> + writel_relaxed(irq->mask, adpt->base + irq_cfg->mask_reg); > >> + } > >> + > >> + wmb(); /* ensure that irq and ptp setting are flushed to HW */ > > > > Would not using writel() make the appropriate thing here instead of > > using _relaxed which has no barrier? > > It appears to me that the barrier in writel() comes before the access > [1]. The barrier in this code comes after the accesses. In addition to > the ordering, if you're suggesting all writel_relaxed be switched out, > that would seem to add 7 unnecessary barriers, which could adversely > affect performance. > > 1. http://lxr.free-electrons.com/source/arch/arm64/include/asm/io.h#L130 You are right, the writel does not flush the write out to hardware, and generally that is not needed, in particular since most buses do not actually wait for a write to complete when a barrier is issued. I'm missing two explanations here: a) How performance-critical is the emac_mac_irq_enable() function? Is this only called when configuring the device, or each time you call napi_complete()? b) What other code relies on the write being flushed out first? Can you move the barrier to the other side? If emac_mac_irq_enable() is called a lot, you might be able to avoid that barrier altogether if you instead put it whereever you access the device that requires the interrupts to be enabled. > >> + mta = readl_relaxed(adpt->base + EMAC_HASH_TAB_REG0 + (reg << 2)); > >> + mta |= (0x1 << bit); > >> + writel_relaxed(mta, adpt->base + EMAC_HASH_TAB_REG0 + (reg << 2)); > >> + wmb(); /* ensure that the mac address is flushed to HW */ > > > > This is getting too much here, just use the correct I/O accessor for > > your platform, period. > > Based on your previous comment, I'm guessing you're suggesting using > readl() and writel() here instead of *_relaxed and an explicit wmb(). > Again it's not clear to me why swapping the barrier-access ordering and > adding an additional barrier would result in more correct code. We generally want to use readl/writel rather than the relaxed versions, unless it is in performance-critical code. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/