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=-4.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 609C8C4727C for ; Tue, 29 Sep 2020 13:23:45 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (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 CFE78208FE for ; Tue, 29 Sep 2020 13:23:44 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="JiiocWwg" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org CFE78208FE Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arndb.de Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+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=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:To:Subject:Message-ID:Date:From:In-Reply-To: References:MIME-Version:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=yxrAKj9XnJuA2LpMwTfq/bLl8mWku/hLS+YSGPxd+Nc=; b=JiiocWwgYOrgM4R+PW+Ivb2tU 1FvQQbNEFa4l2JR0BFACqkuFiWMjPDqJqy1uGMPEDGsiLqbQGGxeViRijcw2CbMnd5jMezCrSuvf1 OdNFdcw2RYZOkW3qTBWKFlfQ1gWJCLPOTpOouqWVWrB6qnlSrbmXOuIImD8w26nXNNya5Y8yIwv9p wDbglnlQFP4F+acZZAdj/do7PX3NPBU8DRuAhuYFPVnumUCg2pZOiDjHmssMZjnOTZZyQKmEMNlbb BIZj0moX0eT/GpJe66JXk9aNNyGbveXRfbKcJF3C8+RlkJhZm5R8E230NMXWSweeqYlCifA2aXnrA ywIHVF63A==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kNFa5-0007fB-Ev; Tue, 29 Sep 2020 13:22:09 +0000 Received: from mout.kundenserver.de ([212.227.126.134]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kNFa2-0007ek-7D for linux-arm-kernel@lists.infradead.org; Tue, 29 Sep 2020 13:22:07 +0000 Received: from mail-lj1-f171.google.com ([209.85.208.171]) by mrelayeu.kundenserver.de (mreue011 [212.227.15.129]) with ESMTPSA (Nemesis) id 1MBll6-1kHij73Lzg-00CB48 for ; Tue, 29 Sep 2020 15:22:01 +0200 Received: by mail-lj1-f171.google.com with SMTP id u4so3991723ljd.10 for ; Tue, 29 Sep 2020 06:22:00 -0700 (PDT) X-Gm-Message-State: AOAM532a/uavA+08ZfxsDfOhf9aeUbn0Mn7olgO/f0szNI+1nqtxRPQC DwVigVW7u75tzvDPgJXeEZcuOe1gNMLc/2Q426Y= X-Google-Smtp-Source: ABdhPJxLDPVUxd0aXaCPeRpOmmLvwT6Csx9GZ1srIqFN3IlsuPuY4jdRCVZ87RKQuey+cGFNX+mnZIWCUhepSTwvcbk= X-Received: by 2002:a2e:9655:: with SMTP id z21mr1166026ljh.410.1601385719868; Tue, 29 Sep 2020 06:21:59 -0700 (PDT) MIME-Version: 1.0 References: <20200916205522.8783-1-festevam@gmail.com> <20200916205522.8783-10-festevam@gmail.com> In-Reply-To: From: Arnd Bergmann Date: Tue, 29 Sep 2020 15:21:43 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 09/13] ARM: imx: Remove unused IO_ADDRESS() macros To: Linus Walleij X-Provags-ID: V03:K1:Cnorwo8hLPuHxDYfc/ktp3N+1gCWKU6fkoNFirtvRVZz1O5/Iqs NEoFK/rYa9ZoTqQut09xSsAXwC7MtGGgoSeKXj//4vqDPb2FMKM76WsqY15clFXDBzqaF5+ 2hzBReDEx/rVnEbF2Levttm6kN+kf+ze047lk2lDE7djO7LhzAu93WBRp6xp/szuwrQu3F4 UnTJeSCI4Aj9ykhdXoyqw== X-UI-Out-Filterresults: notjunk:1;V03:K0:svrKbGsM4Xg=:iaFkamp8h73fzHavbAfMEB m1KaIZLoXUY2lZFfCwC0HU9SvxZdoCDymD2DIZpXudNR6Vi5ikBmYl+Q2M9puzdi2yNW7ladQ MfYWug4+VIa6VG+Qwi93TqTMwVmTls/nwq1qqzaqPn/7nLGTYUkN5ts3qwOqUMPdpOaV/KE1k KtT6oYu8UNhINwa6S4tyNhEzWIF1ViktoitmEwusFMd4kQclYxY39deDseGel6rRO7z+PRfVQ h8P5laP3uQZYoBHtwnMX674hx8jotiy14Hdzar79FcWgpFySGr+gHJau+lAnsYeQSRZDzPY8v 9TwNXaB/62WFd3c1LojHEtPdy7lYR0l5fkHwOVIhcBLHbJkdM5nMB0u3Qe0YhzFSxv2TtJwRM xx947PJ83ko3xHaOOm4RE2YeG0ntOmZtWFMfI+lFChTBv/TyOPAiPKElp05VBch6lNtYH3W9v e2WfwUOcNXO+SyIdh/SSEq0qqgOQ/ihEEwnRJwgwAOo3hyz5S2+a7b6RBII8NaSwLpyXI3qUG VkHHY+gtQedyeotEk4qfeChzbQxDfsw39JO9bclbrusGJHhiIdfmgdWRDMMd+3xloO2bbwFu9 KkeeJl4u+8e74vHBakNcLqC0D9cLeJqRQeQpngaW/rfC5sGbDYlBH/eUPZBvrieRcKHgT7Rxc L1H6YzZYLtLu8ptQyf6oXD5lWxJHZG3OL0BP7GZJFDyyNgopoPR2vthdRfIuw3c6QIvMOv89r IojlKmfn0e1v+cyoAlJdHgXxHJMe185fVRFzLLQ/FICKzYKIa8dY5olTQF9dJtUdgkq8YTurQ C57LXXlPZvCsoy+sNUTXh6GHaEo7imL+Et0c1BIFNzsT6Msh2Rk1+sa8mT16nI7n8jCcSlmsU Ir/Qo1PwbMKzBVwK+GUKS0EN5Jzi9rkKn6ivkqrdSUQGIPKgm1DxtZEVeX6sF/lvCpcOSgDNZ kiY5i5UOGyb2aON3Si0qJZfxBYl72mCE7EMt5i2cTNJut7rEBRjTW X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200929_092206_508811_EB11187B X-CRM114-Status: GOOD ( 22.56 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Linux ARM , Shawn Guo , Fabio Estevam , NXP Linux Team , Sascha Hauer Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Tue, Sep 29, 2020 at 3:11 PM Linus Walleij wrote: > On Thu, Sep 17, 2020 at 9:16 AM Arnd Bergmann wrote: > > > If all of the devices in here are now also mapped using of_iomap() or > > ioremap(), then the iotables are not strictly needed any more, but most > > of them are 1MB section sized, which helps slightly reduce TLB usage > > compared to non-section ioremap() mappings, so we might want to > > keep them anyway, possibly with the constants moved from the header > > into the mm-imx??.c files. > > > > Adding Linus to Cc for further thoughts, as he was looking at the early > > io mappings recently. > > There is early fixmap which I think should replace the iotables > completely if we can, since it is generic kernel code. I was meaning > to look into this "at some point". > > The early fixmap seems to be page (0x1000) based so the iotables > might be more efficient if using 1MB sections but I doubt that it is > worth it. As far as I can tell, the 1MB section maps are the only reason this exists, as all of them are actually ioremap()ed later on before use. I don't know if it makes a difference to real-world performance. Note that there are only 64 TLB entries on ARM926, or 128 on ARM1136, so avoiding the lookup/eviction at least theoretically should be measurably faster. Arnd _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel