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=-6.3 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS 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 F22E2C433E0 for ; Tue, 9 Mar 2021 22:07:21 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id C97BA6504F for ; Tue, 9 Mar 2021 22:07:21 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231995AbhCIWGu (ORCPT ); Tue, 9 Mar 2021 17:06:50 -0500 Received: from mail.kernel.org ([198.145.29.99]:44584 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230173AbhCIWG0 (ORCPT ); Tue, 9 Mar 2021 17:06:26 -0500 Received: by mail.kernel.org (Postfix) with ESMTPSA id BD71165092; Tue, 9 Mar 2021 22:06:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1615327585; bh=Yv8N+lvXzeDwu/BV9QWlF/ECq72HLpbo3iSHF+ZDqfA=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=b9PbhBz+g4RuhQnFFoZGqEnaAdoqx/n8ibHQd9UksEzDN3OCX8g8VaguKgjXoL8J9 aK9u69eyvc/BWTuwS8lIYuYCkHy59HLZXXgXNYp9FjDiau6yjAt2HeUm+013Kw5Je2 fOmbG/pfsOiHIO87xqtO5925x7LNyMkFRL8jPM+CqOD5WKNM8wZsVtU+E/xPq3BAgh yD6Xj9V9NiRiYM65qk/6iUIk20/73ihjOCansOlQuZAZb99W+QpfrcANFglpfGkGoK O/oUo6ct+GlE7wJQiPrS/ZXY9h2uDPHBVRRnlHVtGMPgVJlSGmB+yRs1lzMXstoZju IJg8ssOyCZa/A== Received: by mail-qv1-f54.google.com with SMTP id x13so7242173qvj.7; Tue, 09 Mar 2021 14:06:25 -0800 (PST) X-Gm-Message-State: AOAM532qu2xyOXoypO2VVCZQqxMgebdhYqG4qhMXKNL4yOgMSpEUqAyY 1Iu+rWriPgAtHc2G/20/myanriqS9kdq89tdVw== X-Google-Smtp-Source: ABdhPJy1C6AzP09b9wus1ZVT5E/CtXLEugZNjwqSvxHP9P4lOiRLRzFWXQ3jpvPXSnSw2MikeoWzpKJ2j9KJLzk621o= X-Received: by 2002:a0c:f092:: with SMTP id g18mr201509qvk.11.1615327584670; Tue, 09 Mar 2021 14:06:24 -0800 (PST) MIME-Version: 1.0 References: <20210304213902.83903-1-marcan@marcan.st> <20210304213902.83903-13-marcan@marcan.st> <6e4880b3-1fb6-0cbf-c1a5-7a46fd9ccf62@marcan.st> <20210308211306.GA2920998@robh.at.kernel.org> In-Reply-To: From: Rob Herring Date: Tue, 9 Mar 2021 15:06:13 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFT PATCH v3 12/27] of/address: Add infrastructure to declare MMIO as non-posted To: Hector Martin Cc: Arnd Bergmann , linux-arm-kernel , Marc Zyngier , Olof Johansson , Krzysztof Kozlowski , Mark Kettenis , Tony Lindgren , Mohamed Mediouni , Stan Skowronek , Alexander Graf , Will Deacon , Linus Walleij , Mark Rutland , Andy Shevchenko , Greg Kroah-Hartman , Jonathan Corbet , Catalin Marinas , Christoph Hellwig , "David S. Miller" , DTML , "open list:SERIAL DRIVERS" , Linux Doc Mailing List , linux-samsung-soc , "open list:GENERIC INCLUDE/ASM HEADER FILES" , "linux-kernel@vger.kernel.org" Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Mar 9, 2021 at 1:24 PM Hector Martin wrote: > > On 10/03/2021 00.48, Rob Herring wrote: > > On Mon, Mar 8, 2021 at 2:56 PM Arnd Bergmann wrote: > >> > >> On Mon, Mar 8, 2021 at 10:14 PM Rob Herring wrote: > >>> On Mon, Mar 08, 2021 at 09:29:54PM +0100, Arnd Bergmann wrote: > >>>> On Mon, Mar 8, 2021 at 4:56 PM Rob Herring wrote: > >>> > >>> Let's just stick with 'nonposted-mmio', but drop 'posted-mmio'. I'd > >>> rather know if and when we need 'posted-mmio'. It does need to be added > >>> to the DT spec[1] and schema[2] though (GH PRs are fine for both). > >> > >> I think the reason for having "posted-mmio" is that you cannot properly > >> define the PCI host controller nodes on the M1 without that: Since > >> nonposted-mmio applies to all child nodes, this would mean the PCI > >> memory space gets declared as nonposted by the DT, but the hardware > >> requires it to be mapped as posted. > > > > I don't think so. PCI devices wouldn't use any of the code paths in > > this patch. They would map their memory space with plain ioremap() > > which is posted. > > My main concern here is that this creates an inconsistency in the device > tree representation that only works because PCI drivers happen not to > use these code paths. Logically, having "nonposted-mmio" above the PCI > controller would imply that it applies to that bus too. Sure, it doesn't > matter for Linux since it is ignored, but this creates an implicit > exception that PCI buses always use posted modes. We could be stricter that "nonposted-mmio" must be in the immediate parent. That's kind of in line with how addressing already works. Every level has to have 'ranges' to be an MMIO address, and the address cell size is set by the immediate parent. > Then if a device comes along that due to some twisted fabric logic needs > nonposted nGnRnE mappings for PCIe (even though the actual PCIe ops will > end up posted at the bus anyway)... how do we represent that? Declare > that another "nonposted-mmio" on the PCIe bus means "no, really, use > nonposted mmio for this"? If we're strict, yes. The PCI host bridge would have to have "nonposted-mmio". Rob 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.3 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 9AA48C433DB for ; Tue, 9 Mar 2021 22:08:14 +0000 (UTC) Received: from desiato.infradead.org (desiato.infradead.org [90.155.92.199]) (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 01C4765022 for ; Tue, 9 Mar 2021 22:08:13 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 01C4765022 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org 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=desiato.20200630; h=Sender:Content-Transfer-Encoding :Content-Type:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:Cc: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=IqEdk6+W/EzennFLaJlM1PhOz+gNjgdWi+q8QHZABQo=; b=mErECtuzbIwzvCqAEUwD3kDWH X3RXOPS8tSPGi7n+8GUPKtkbIc6ZjeQu9QBP2OxgF08rMhEV29wPj2bOQDvvpAQzRvaFyeEZ+5Y/e pKO9IPgI7j7JUG3pAz2JDeibO7sr/jNu5iGEsgansOEpY90z91gEhmeMP8aGDMzKEaNp8NRMNwYla bx9T+uTaUS9i3A56p7sRrStHdiZDd4jPgen4r5nIk4w2+LQY2+SNrXgKFSgCappsYUEBD667n4uWB dgfody+pihPjMKGcthFS8p5/fHnMuTmE2CRuApHHNAz3MS8/+m6BOd/fpSbo+UxDOASb0GbRz/FKE UxCSLQA1w==; Received: from localhost ([::1] helo=desiato.infradead.org) by desiato.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1lJkUs-005XG4-1N; Tue, 09 Mar 2021 22:06:34 +0000 Received: from mail.kernel.org ([198.145.29.99]) by desiato.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1lJkUl-005XEd-He for linux-arm-kernel@lists.infradead.org; Tue, 09 Mar 2021 22:06:30 +0000 Received: by mail.kernel.org (Postfix) with ESMTPSA id 90D4965022 for ; Tue, 9 Mar 2021 22:06:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1615327585; bh=Yv8N+lvXzeDwu/BV9QWlF/ECq72HLpbo3iSHF+ZDqfA=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=b9PbhBz+g4RuhQnFFoZGqEnaAdoqx/n8ibHQd9UksEzDN3OCX8g8VaguKgjXoL8J9 aK9u69eyvc/BWTuwS8lIYuYCkHy59HLZXXgXNYp9FjDiau6yjAt2HeUm+013Kw5Je2 fOmbG/pfsOiHIO87xqtO5925x7LNyMkFRL8jPM+CqOD5WKNM8wZsVtU+E/xPq3BAgh yD6Xj9V9NiRiYM65qk/6iUIk20/73ihjOCansOlQuZAZb99W+QpfrcANFglpfGkGoK O/oUo6ct+GlE7wJQiPrS/ZXY9h2uDPHBVRRnlHVtGMPgVJlSGmB+yRs1lzMXstoZju IJg8ssOyCZa/A== Received: by mail-qv1-f47.google.com with SMTP id d9so7249600qvo.3 for ; Tue, 09 Mar 2021 14:06:25 -0800 (PST) X-Gm-Message-State: AOAM530GPQpYz7YeFocYDbbTntYGmPUTjBv/qxzk7U2aMUtHmDz8ea7k p8UjXGpKJZKMlZDn/fVynCQC5pN+fUnRvQ9Zyw== X-Google-Smtp-Source: ABdhPJy1C6AzP09b9wus1ZVT5E/CtXLEugZNjwqSvxHP9P4lOiRLRzFWXQ3jpvPXSnSw2MikeoWzpKJ2j9KJLzk621o= X-Received: by 2002:a0c:f092:: with SMTP id g18mr201509qvk.11.1615327584670; Tue, 09 Mar 2021 14:06:24 -0800 (PST) MIME-Version: 1.0 References: <20210304213902.83903-1-marcan@marcan.st> <20210304213902.83903-13-marcan@marcan.st> <6e4880b3-1fb6-0cbf-c1a5-7a46fd9ccf62@marcan.st> <20210308211306.GA2920998@robh.at.kernel.org> In-Reply-To: From: Rob Herring Date: Tue, 9 Mar 2021 15:06:13 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFT PATCH v3 12/27] of/address: Add infrastructure to declare MMIO as non-posted To: Hector Martin Cc: Arnd Bergmann , linux-arm-kernel , Marc Zyngier , Olof Johansson , Krzysztof Kozlowski , Mark Kettenis , Tony Lindgren , Mohamed Mediouni , Stan Skowronek , Alexander Graf , Will Deacon , Linus Walleij , Mark Rutland , Andy Shevchenko , Greg Kroah-Hartman , Jonathan Corbet , Catalin Marinas , Christoph Hellwig , "David S. Miller" , DTML , "open list:SERIAL DRIVERS" , Linux Doc Mailing List , linux-samsung-soc , "open list:GENERIC INCLUDE/ASM HEADER FILES" , "linux-kernel@vger.kernel.org" X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210309_220628_294412_621DDFDD X-CRM114-Status: GOOD ( 27.93 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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, Mar 9, 2021 at 1:24 PM Hector Martin wrote: > > On 10/03/2021 00.48, Rob Herring wrote: > > On Mon, Mar 8, 2021 at 2:56 PM Arnd Bergmann wrote: > >> > >> On Mon, Mar 8, 2021 at 10:14 PM Rob Herring wrote: > >>> On Mon, Mar 08, 2021 at 09:29:54PM +0100, Arnd Bergmann wrote: > >>>> On Mon, Mar 8, 2021 at 4:56 PM Rob Herring wrote: > >>> > >>> Let's just stick with 'nonposted-mmio', but drop 'posted-mmio'. I'd > >>> rather know if and when we need 'posted-mmio'. It does need to be added > >>> to the DT spec[1] and schema[2] though (GH PRs are fine for both). > >> > >> I think the reason for having "posted-mmio" is that you cannot properly > >> define the PCI host controller nodes on the M1 without that: Since > >> nonposted-mmio applies to all child nodes, this would mean the PCI > >> memory space gets declared as nonposted by the DT, but the hardware > >> requires it to be mapped as posted. > > > > I don't think so. PCI devices wouldn't use any of the code paths in > > this patch. They would map their memory space with plain ioremap() > > which is posted. > > My main concern here is that this creates an inconsistency in the device > tree representation that only works because PCI drivers happen not to > use these code paths. Logically, having "nonposted-mmio" above the PCI > controller would imply that it applies to that bus too. Sure, it doesn't > matter for Linux since it is ignored, but this creates an implicit > exception that PCI buses always use posted modes. We could be stricter that "nonposted-mmio" must be in the immediate parent. That's kind of in line with how addressing already works. Every level has to have 'ranges' to be an MMIO address, and the address cell size is set by the immediate parent. > Then if a device comes along that due to some twisted fabric logic needs > nonposted nGnRnE mappings for PCIe (even though the actual PCIe ops will > end up posted at the bus anyway)... how do we represent that? Declare > that another "nonposted-mmio" on the PCIe bus means "no, really, use > nonposted mmio for this"? If we're strict, yes. The PCI host bridge would have to have "nonposted-mmio". Rob _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel