From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752446AbcEJTwS (ORCPT ); Tue, 10 May 2016 15:52:18 -0400 Received: from mout.kundenserver.de ([217.72.192.73]:56825 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751625AbcEJTwQ (ORCPT ); Tue, 10 May 2016 15:52:16 -0400 From: Arnd Bergmann To: Florian Fainelli Cc: linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org, devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, bcm-kernel-feedback-list@broadcom.com, jim2101024@gmail.com, bhelgaas@google.com Subject: Re: [PATCH v2 1/2] Documentation: DT: bindings: Add Broadcom STB PCIe bindings Date: Tue, 10 May 2016 21:51:47 +0200 Message-ID: <2533093.jsjycoq8tW@wuerfel> User-Agent: KMail/4.11.5 (Linux/3.16.0-10-generic; KDE/4.11.5; x86_64; ; ) In-Reply-To: <5732139C.80101@gmail.com> References: <1462475700-1654-1-git-send-email-f.fainelli@gmail.com> <4513390.VWu0VVAxOl@wuerfel> <5732139C.80101@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:cxz8p3l7VgX1rqqIadffjLXWVTF0ciloxoA3HFHQdncdX4AS8Wk yntldUjTu4M+rUcUqYoavbOgX3kxqAvaqBpzUj6tGEgq5zhGLg+e6tdElq9oMBJ9cQcBeQR D0MKKgxJCpzppGcdHFE4xZ2M4R5xTjxIA5ZBsLxXSIfjmmK8WuW8GJ6feKv1K+ctqN1wibq mBmP3e5kauOkLtu6al1TA== X-UI-Out-Filterresults: notjunk:1;V01:K0:us6z30M9vAI=:fRa2PVVXQk1A3Mjw7kJIBh bx3UQt4lLVO5SxNnihzfnToy+sDUq0oNOhUEluUNeIfAjEzVRZJTD5AfYxZmePS39w7Af8o1K r2EwSPqtdSpzpPIY1g0f4wccJd4iNAGkbOe1wRctM/gvR6mog6B56MrV+SQH4r0lga+j/AgY9 EIZKjgDjn2gr5wEWXa3fyYh0MJWIpgnUMa3Of6JUWqlWbm9mKxzITQrcoxfqfpgCfjIF9ZbAj 2sFTijh1YNsdsYeeJjsP7Tq64RE96Lw7AVZ/kdUuLVPL8EeYtg0su03EdoAfIP7DHxNwBuJhk FH+mhjvWwqs3RseSlq1SlvH4oEFeOlkMPYDlAIAEIRaU+hb2pDxaeT8nxpFYMQMLnU4aqWMlu A3gr84adW0HhwZo+fgMfgyPO4Se44wbMS2KY3O+bXwwCT7E84QpCiU7/FEDxU2t9v1Ggt2Nkq RgtdqjxWb49Pfvb6jggrv49FoRq1PXGx8M+v2hKRjRwI/EdfK6xz5XJdf784fil+iXIYg/tmv cegSjRXmLxTjPUozwCgSi8PzU+nrpgG9YruS4QKLaw5V6iJiRg430MP9w59llsn/tIdRRdsbf Q9R7Sp7rTIx7CbNRrk/ktwGdbmvmx7DY8qX833pz6/J0o8QPDdJLV4PnUdp78Lq443ZnLwo3z vhA8vEjykEsKgCZEgpSPmERYJwicWrvf8thljYlbjbe3Uai1NtRp857inxVoRupNPyv0KzjtV 2h/j0yPu2TSJIxav Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tuesday 10 May 2016 10:00:12 Florian Fainelli wrote: > > The two critical pieces of information that the PCIe RC needs are: > > - number of memory controllers present in the system to avoid > configuring a window to a non-existing or non-populated memory controller > > - size of the memory populated on the memory controller > > You would think that we should somehow be able to derive this > information from the "memory" node, but there are a few caveats: > > - on MIPS platforms, we have discontiguous physical memory ranges (256MB > @ 0x0, then 768MB or 1792MB @ 0x 0x20000000 and 1GB @ 0x90000000), yet > the PCIe RC does not know about the hole(s) That sounds like you need a dma-ranges property anyway to describe how the DMA addresses are mapped. > - on ARM platforms, we have an identiy mapping for the PAs below 4GB, > but when we cross it, we have additional non-linear memory regions > > Both of these memory nodes would imply we know how to identify which > physical address belongs to which memory controller, while this is > actually possible and known, it creates a dependency on another piece of > driver to provide that information. > > We do have memory controller nodes populated in the Device Tree, however > their binding (out of tree for the moment) does only specify their > programmable register interface, and not how how much physical memory > and where they provide to the system. > > It does seem like we should be able to utilize the "dma-ranges" property > to determine both the memory controller number and their respective > populated memory sizes. > > In the case where we have an identiy mapping though, this seems a little > redundant, but less of a stretch than our custom properties and nodes. > > Does that sound reasonable to you? I'd have to look at an example first. Ideally, each line in the dma-ranges property would refer to one memory controller, and that would be very easy to mandate, but it sounds like in the MIPS case you end up with an extra entry for the first 256MB that is on the same memory controller as the second 768MB. Arnd