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=-1.1 required=3.0 tests=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 0B872C3276D for ; Thu, 2 Jan 2020 22:56:14 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id CCFEB21D7D for ; Thu, 2 Jan 2020 22:56:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1578005773; bh=6Koeg/QpSh6SN7IsDtUD1Yw/jN4FQfOCYYp5OlkQg8k=; h=References:In-Reply-To:From:Date:Subject:To:Cc:List-ID:From; b=o4M2IdWVioW3cg6TVJ5u8kZbC3TtqEY9tZxDFeWZbQjoo0IjkTeuq7dcZ58MKeuuR FlVQzJ0NzXCkdnMxqMVHLxkCIRlUlx6hQ224e4DS+fgVip4HzAhYvPrG6AZdVMZHW8 HJsKG4XpNhbKgrsNZnJmgLeHmfYBNfGHiNsUDkR0= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729045AbgABW4N (ORCPT ); Thu, 2 Jan 2020 17:56:13 -0500 Received: from mail.kernel.org ([198.145.29.99]:39234 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728955AbgABW4I (ORCPT ); Thu, 2 Jan 2020 17:56:08 -0500 Received: from mail-qt1-f173.google.com (mail-qt1-f173.google.com [209.85.160.173]) (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 BA3EE2467C; Thu, 2 Jan 2020 22:56:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1578005766; bh=6Koeg/QpSh6SN7IsDtUD1Yw/jN4FQfOCYYp5OlkQg8k=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=BJyGrgJRAyAcMthsOmMVJk2/d9roLzBD5KeGqfyxfbX3KtZmnnxHXX0pyJ8akcsha K/iFSGYit7euv46SOim83yGJFkSBYf8D90gScmaaJtUv+dQKRJYtoCVXIxkXtGp8sR GDbQ6bO22fdQJ5Wf9rmFtnvZeSvKb4mLF6EU8dZs= Received: by mail-qt1-f173.google.com with SMTP id e5so35708757qtm.6; Thu, 02 Jan 2020 14:56:06 -0800 (PST) X-Gm-Message-State: APjAAAVKxjipXn0TO2rT+3qC8pmu+bnvQkMyWNSBpDwg/Uc+lLB5jr5G CWSio0aYWg3he0dfFCGJa9kYg0hXo9uTWv6Lrw== X-Google-Smtp-Source: APXvYqwAbFfNGIM/JC1KIxuEbN03VDUjC5JsTAOv7Mn+H2Fs2ofR3ekjqd4fT38uPCQz6qNQ3qPQ9Hc0j9LyLmDrH44= X-Received: by 2002:aed:2344:: with SMTP id i4mr63466799qtc.136.1578005765768; Thu, 02 Jan 2020 14:56:05 -0800 (PST) MIME-Version: 1.0 References: <20191213084748.11210-1-prabhakar.mahadev-lad.rj@bp.renesas.com> <20191213084748.11210-4-prabhakar.mahadev-lad.rj@bp.renesas.com> <20191219233129.GA5484@bogus> In-Reply-To: From: Rob Herring Date: Thu, 2 Jan 2020 15:55:53 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [v2 3/6] of: address: add support to parse PCI outbound-ranges To: "Lad, Prabhakar" Cc: Bjorn Helgaas , Mark Rutland , Geert Uytterhoeven , Magnus Damm , Kishon Vijay Abraham I , Marek Vasut , Yoshihiro Shimoda , PCI , Catalin Marinas , Will Deacon , Lorenzo Pieralisi , Arnd Bergmann , Greg Kroah-Hartman , Andrew Murray , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , "linux-kernel@vger.kernel.org" , "moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE" , "open list:MEDIA DRIVERS FOR RENESAS - FCP" , Chris Paterson , Frank Rowand , Gustavo Pimentel , Jingoo Han , Simon Horman , Shawn Lin , Tom Joseph , Heiko Stuebner , "open list:ARM/Rockchip SoC..." , "Lad, Prabhakar" Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jan 2, 2020 at 1:44 AM Lad, Prabhakar wrote: > > Hi Rob, > > On Thu, Dec 19, 2019 at 11:31 PM Rob Herring wrote: > > > > On Mon, Dec 16, 2019 at 08:49:23AM +0000, Lad, Prabhakar wrote: > > > Hi Rob, > > > > > > Thank you for the review. > > > > > > On Fri, Dec 13, 2019 at 8:37 PM Rob Herring wrote: > > > > > > > > On Fri, Dec 13, 2019 at 2:48 AM Lad Prabhakar > > > > wrote: > > > > > > > > > > From: "Lad, Prabhakar" > > > > > > > > > > this patch adds support to parse PCI outbound-ranges, the > > > > > outbound-regions are similar to pci ranges except it doesn't > > > > > have pci address, below is the format for bar-ranges: > > > > > > > > > > outbound-ranges = > > > > upper32_size lower32_size>; > > > > > > > > You can't just make up a new ranges property. Especially one that > > > > doesn't follow how 'ranges' works. We already have 'dma-ranges' to > > > > translate device to memory addresses. > > > > > > > > Explain the problem or feature you need, not the solution you came up > > > > with. Why do you need this and other endpoint bindings haven't? > > > > > > > rcar SoC's supports multiple outbound region for mapping the PCI address > > > locally to the system. This lead to discussion where there exist controllers > > > which support regions for high/low priority transfer and similarly regions > > > for large/small memory allocations, as a result a new ranges property was > > > added, where we can specify the flags which would indicate how the outbound > > > region can be used during requests. > > > > What are the flags? > > below are the flags which were discussed in first version of the > series, but since the driver is > currently using just PCI_EPC_WINDOW_FLAG_NON_MULTI_ALLOC flag I'll be > dropping them in > next version (suggested by Kishon) and rest will be added as and when > required by the driver. > > * @PCI_EPC_WINDOW_FLAG_MULTI_ALLOC: Indicates multiple chunks of memory can be > * allocated from same window > * @PCI_EPC_WINDOW_FLAG_NON_MULTI_ALLOC: Indicates only single memory allocation > * is possible on the window > * @PCI_EPC_WINDOW_FLAG_LARGE_ALLOC: Window is used for large memory allocation > * @PCI_EPC_WINDOW_FLAG_SMALL_ALLOC: Window is used for small memory allocation > * @PCI_EPC_WINDOW_FLAG_HIGH_PRI_ALLOC: Window is used for high priority data > * transfers > * @PCI_EPC_WINDOW_FLAG_LOW_PRI_ALLOC: Window is used for low priority data > * transfers Looks like configuration or policy, not something that belongs in DT. Coupling driver features and DT changes is not good for ABI compatible changes either. I'm hesitant to accept any PCI endpoint binding additions because they don't seem to be completely thought out in terms of supporting different usecases. Rob From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rob Herring Subject: Re: [v2 3/6] of: address: add support to parse PCI outbound-ranges Date: Thu, 2 Jan 2020 15:55:53 -0700 Message-ID: References: <20191213084748.11210-1-prabhakar.mahadev-lad.rj@bp.renesas.com> <20191213084748.11210-4-prabhakar.mahadev-lad.rj@bp.renesas.com> <20191219233129.GA5484@bogus> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=m.gmane.org@lists.infradead.org To: "Lad, Prabhakar" Cc: Mark Rutland , Heiko Stuebner , Geert Uytterhoeven , PCI , Shawn Lin , Frank Rowand , Marek Vasut , Lorenzo Pieralisi , Will Deacon , Magnus Damm , Kishon Vijay Abraham I , "open list:ARM/Rockchip SoC..." , Catalin Marinas , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , Chris Paterson , Arnd Bergmann , "Lad, Prabhakar" , Simon Horman , Bjorn Helgaas , moderated list:ARM/FREESCALE IMX / MXC ARM List-Id: linux-rockchip.vger.kernel.org On Thu, Jan 2, 2020 at 1:44 AM Lad, Prabhakar wrote: > > Hi Rob, > > On Thu, Dec 19, 2019 at 11:31 PM Rob Herring wrote: > > > > On Mon, Dec 16, 2019 at 08:49:23AM +0000, Lad, Prabhakar wrote: > > > Hi Rob, > > > > > > Thank you for the review. > > > > > > On Fri, Dec 13, 2019 at 8:37 PM Rob Herring wrote: > > > > > > > > On Fri, Dec 13, 2019 at 2:48 AM Lad Prabhakar > > > > wrote: > > > > > > > > > > From: "Lad, Prabhakar" > > > > > > > > > > this patch adds support to parse PCI outbound-ranges, the > > > > > outbound-regions are similar to pci ranges except it doesn't > > > > > have pci address, below is the format for bar-ranges: > > > > > > > > > > outbound-ranges = > > > > upper32_size lower32_size>; > > > > > > > > You can't just make up a new ranges property. Especially one that > > > > doesn't follow how 'ranges' works. We already have 'dma-ranges' to > > > > translate device to memory addresses. > > > > > > > > Explain the problem or feature you need, not the solution you came up > > > > with. Why do you need this and other endpoint bindings haven't? > > > > > > > rcar SoC's supports multiple outbound region for mapping the PCI address > > > locally to the system. This lead to discussion where there exist controllers > > > which support regions for high/low priority transfer and similarly regions > > > for large/small memory allocations, as a result a new ranges property was > > > added, where we can specify the flags which would indicate how the outbound > > > region can be used during requests. > > > > What are the flags? > > below are the flags which were discussed in first version of the > series, but since the driver is > currently using just PCI_EPC_WINDOW_FLAG_NON_MULTI_ALLOC flag I'll be > dropping them in > next version (suggested by Kishon) and rest will be added as and when > required by the driver. > > * @PCI_EPC_WINDOW_FLAG_MULTI_ALLOC: Indicates multiple chunks of memory can be > * allocated from same window > * @PCI_EPC_WINDOW_FLAG_NON_MULTI_ALLOC: Indicates only single memory allocation > * is possible on the window > * @PCI_EPC_WINDOW_FLAG_LARGE_ALLOC: Window is used for large memory allocation > * @PCI_EPC_WINDOW_FLAG_SMALL_ALLOC: Window is used for small memory allocation > * @PCI_EPC_WINDOW_FLAG_HIGH_PRI_ALLOC: Window is used for high priority data > * transfers > * @PCI_EPC_WINDOW_FLAG_LOW_PRI_ALLOC: Window is used for low priority data > * transfers Looks like configuration or policy, not something that belongs in DT. Coupling driver features and DT changes is not good for ABI compatible changes either. I'm hesitant to accept any PCI endpoint binding additions because they don't seem to be completely thought out in terms of supporting different usecases. 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=-1.0 required=3.0 tests=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 1D938C3276C for ; Thu, 2 Jan 2020 22:56:23 +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 E710020848 for ; Thu, 2 Jan 2020 22:56:22 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="PU8Z+PFx"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="BJyGrgJR" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E710020848 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+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: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=wqOsFQGVaJzXiB+j5qFVPdWzGbYcpOkmBSGIJqo96Ws=; b=PU8Z+PFxyb2tny HE8TYEdv56U/QkVZquLJjSIJDgml7dQEe8UHJf0qephxUuFDhRzI0eZfGx9wTnK3QY85XuMze/4kP qicGbuR0myM4T5csCA5xOTJzqVV/zk/pHPWPFJt28DtlsnXznMHw1J2UcRSAPHK4BVvzeOyiMW/It 33rTQ8Kh8kUvcmX+ttbeTdkGg2kIZJmSwJfvZ86EhabQRhyqVPM/klH5X0V0cPyi4gBZunMqOsRCj 0g0j5RYN+FMWKKqJGKUawulAbheCfmaptJ54nFAQfpE8gV4sXDGu0h44XE2jP0edNm0sFZ6Y1tGPm aYKhzVffr0Mc+7AgH7RQ==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1in9O0-0001Ly-JB; Thu, 02 Jan 2020 22:56:12 +0000 Received: from mail.kernel.org ([198.145.29.99]) by bombadil.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1in9Nv-0001LC-To; Thu, 02 Jan 2020 22:56:10 +0000 Received: from mail-qt1-f176.google.com (mail-qt1-f176.google.com [209.85.160.176]) (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 B556724679; Thu, 2 Jan 2020 22:56:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1578005766; bh=6Koeg/QpSh6SN7IsDtUD1Yw/jN4FQfOCYYp5OlkQg8k=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=BJyGrgJRAyAcMthsOmMVJk2/d9roLzBD5KeGqfyxfbX3KtZmnnxHXX0pyJ8akcsha K/iFSGYit7euv46SOim83yGJFkSBYf8D90gScmaaJtUv+dQKRJYtoCVXIxkXtGp8sR GDbQ6bO22fdQJ5Wf9rmFtnvZeSvKb4mLF6EU8dZs= Received: by mail-qt1-f176.google.com with SMTP id d5so35742016qto.0; Thu, 02 Jan 2020 14:56:06 -0800 (PST) X-Gm-Message-State: APjAAAWIbq0dYG9a6aSmX1wHCFsI6jEVgCCQ7AHwEa5KYLfXqmMlm+O+ 5i1itmBHkv0xg7nEwvsZRfP5p6tO+BdXRw1dQg== X-Google-Smtp-Source: APXvYqwAbFfNGIM/JC1KIxuEbN03VDUjC5JsTAOv7Mn+H2Fs2ofR3ekjqd4fT38uPCQz6qNQ3qPQ9Hc0j9LyLmDrH44= X-Received: by 2002:aed:2344:: with SMTP id i4mr63466799qtc.136.1578005765768; Thu, 02 Jan 2020 14:56:05 -0800 (PST) MIME-Version: 1.0 References: <20191213084748.11210-1-prabhakar.mahadev-lad.rj@bp.renesas.com> <20191213084748.11210-4-prabhakar.mahadev-lad.rj@bp.renesas.com> <20191219233129.GA5484@bogus> In-Reply-To: From: Rob Herring Date: Thu, 2 Jan 2020 15:55:53 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [v2 3/6] of: address: add support to parse PCI outbound-ranges To: "Lad, Prabhakar" X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200102_145608_003223_7B7D50CD X-CRM114-Status: GOOD ( 24.24 ) 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: Mark Rutland , Heiko Stuebner , Geert Uytterhoeven , PCI , Shawn Lin , Frank Rowand , Marek Vasut , Lorenzo Pieralisi , Will Deacon , Magnus Damm , Kishon Vijay Abraham I , "open list:ARM/Rockchip SoC..." , Catalin Marinas , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , Chris Paterson , Arnd Bergmann , "Lad, Prabhakar" , Simon Horman , Bjorn Helgaas , "moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE" , Greg Kroah-Hartman , Yoshihiro Shimoda , "linux-kernel@vger.kernel.org" , "open list:MEDIA DRIVERS FOR RENESAS - FCP" , Tom Joseph , Jingoo Han , Andrew Murray , Gustavo Pimentel 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 On Thu, Jan 2, 2020 at 1:44 AM Lad, Prabhakar wrote: > > Hi Rob, > > On Thu, Dec 19, 2019 at 11:31 PM Rob Herring wrote: > > > > On Mon, Dec 16, 2019 at 08:49:23AM +0000, Lad, Prabhakar wrote: > > > Hi Rob, > > > > > > Thank you for the review. > > > > > > On Fri, Dec 13, 2019 at 8:37 PM Rob Herring wrote: > > > > > > > > On Fri, Dec 13, 2019 at 2:48 AM Lad Prabhakar > > > > wrote: > > > > > > > > > > From: "Lad, Prabhakar" > > > > > > > > > > this patch adds support to parse PCI outbound-ranges, the > > > > > outbound-regions are similar to pci ranges except it doesn't > > > > > have pci address, below is the format for bar-ranges: > > > > > > > > > > outbound-ranges = > > > > upper32_size lower32_size>; > > > > > > > > You can't just make up a new ranges property. Especially one that > > > > doesn't follow how 'ranges' works. We already have 'dma-ranges' to > > > > translate device to memory addresses. > > > > > > > > Explain the problem or feature you need, not the solution you came up > > > > with. Why do you need this and other endpoint bindings haven't? > > > > > > > rcar SoC's supports multiple outbound region for mapping the PCI address > > > locally to the system. This lead to discussion where there exist controllers > > > which support regions for high/low priority transfer and similarly regions > > > for large/small memory allocations, as a result a new ranges property was > > > added, where we can specify the flags which would indicate how the outbound > > > region can be used during requests. > > > > What are the flags? > > below are the flags which were discussed in first version of the > series, but since the driver is > currently using just PCI_EPC_WINDOW_FLAG_NON_MULTI_ALLOC flag I'll be > dropping them in > next version (suggested by Kishon) and rest will be added as and when > required by the driver. > > * @PCI_EPC_WINDOW_FLAG_MULTI_ALLOC: Indicates multiple chunks of memory can be > * allocated from same window > * @PCI_EPC_WINDOW_FLAG_NON_MULTI_ALLOC: Indicates only single memory allocation > * is possible on the window > * @PCI_EPC_WINDOW_FLAG_LARGE_ALLOC: Window is used for large memory allocation > * @PCI_EPC_WINDOW_FLAG_SMALL_ALLOC: Window is used for small memory allocation > * @PCI_EPC_WINDOW_FLAG_HIGH_PRI_ALLOC: Window is used for high priority data > * transfers > * @PCI_EPC_WINDOW_FLAG_LOW_PRI_ALLOC: Window is used for low priority data > * transfers Looks like configuration or policy, not something that belongs in DT. Coupling driver features and DT changes is not good for ABI compatible changes either. I'm hesitant to accept any PCI endpoint binding additions because they don't seem to be completely thought out in terms of supporting different usecases. Rob _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel