From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753340AbcGSJri (ORCPT ); Tue, 19 Jul 2016 05:47:38 -0400 Received: from mout.kundenserver.de ([212.227.17.10]:57049 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752698AbcGSJrf (ORCPT ); Tue, 19 Jul 2016 05:47:35 -0400 From: Arnd Bergmann To: linux-arm-kernel@lists.infradead.org Cc: Jamie Lentin , Thomas Petazzoni , Andrew Lunn , Florian Fainelli , Jason Cooper , devicetree@vger.kernel.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, Gregory Clement , Imre Kaloz , Sebastian Hesselbarth Subject: Re: [PATCH v0 06/10] arm: orion5x: Add DT-based support for Netgear WNR854T Date: Tue, 19 Jul 2016 11:46:44 +0200 Message-ID: <4018990.2Ivz6MntMW@wuerfel> User-Agent: KMail/5.1.3 (Linux/4.4.0-28-generic; KDE/5.18.0; x86_64; ; ) In-Reply-To: References: <1468679348-10522-1-git-send-email-jm@lentin.co.uk> <1792384.6N9lHjmBFc@wuerfel> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:7kwwEBs8b1sIINeev4XTseNqCrku14DZFGNL9D1bUhcIbbhPGvT pURj/27g9WlHNsWYVhriuUZdXQ9JVj0hmD9cLYros5EvYf2oSF9q/S/QaoBIYweL5fUtK6V 9QPRLGKYG03dqqINfMQ6p3Gu8KMZJfMJo+8ELOiK5Yyev5AnE2Zg9wk7y35q/RaPmpYnL0O /F1T0zRGYTH3p2oSwt9pQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:jRjEgTXLZeQ=:8TxKbXrQzDH8brdadf9L9N tP44zeqv12pC1eb92QjVQYimoQdBqZPm8HTgr0FvFD1Qj9f+eiaW1J/219NJpgRo9L1M7HbiM 3XvzG7Gq90DLptihaaJRVXLWDLmpeRmfzt798aGfJdQQ1Ms7/QxPMtWhsfFzKCq3aMUhkPLST MHWq4GblaFd/6DA1xrRkrz/jKwyVcRK0kT195J+ebgVnK9uNamiTeFOssMA7kD/yDKK3Nv3Gb bPnxYPz+cs6fQVgyGch/UbSfB5z/GCChzRvpx2h5FtgUQZgUwHrLjGpWSWz35aAPRTh2XwUBb oT+2hbwC/FhQUGLyXI98H1/f7tl85lxNu4kTn4GQMTEnf2CCygu1NxSR1pBEAKu5Fz7A0S/0a dj6VIdyf/4LbVHm5yjvBb9V3OoF4MtIe3+nYuCB2eVVzjuJ6w2+PAa42zT52QUeM2sJZdvk0S nvGa3Qb7PIByhqARLffTlD1moyZC01ydxeb460sMRpGmnGgG7+z0YCXFU4D1qfxZRz9csIKaw PUrwbmLXBR40+uXa2PNptHjbubFDB/ZHuHnpgGomwrapcfRXVZ8Z1YCWd5B4trg8lI3zlWKHl mVgLOOOKqS7VICZLD1YkFyfeoVkG3N/oTki0Vlkk+2EbSjViUoSnserg+sHfsEle7tqirT7Fi SSPTglCRUkTlYZDei/GFtq1fghua4YA4X8l+YpRabgaHXwXOg6MuvwGROG5LmGHsy9Fn1k6D3 w1LXy9yNfKdqg7gp Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tuesday, July 19, 2016 10:40:16 AM CEST Jamie Lentin wrote: > On Mon, 18 Jul 2016, Arnd Bergmann wrote: > > > On Monday, July 18, 2016 11:44:24 AM CEST Thomas Petazzoni wrote: > >> > >> On Sun, 17 Jul 2016 22:41:35 +0200, Arnd Bergmann wrote: > >> > >>> I would assume that the PCIe port should work out of the box with the driver > >> > >> Unfortunately, no. The PCIe on Orion5x requires a workaround for > >> reading/writing the PCI configuration space. Instead of doing MMIO > >> accesses to PCIE_CONF_ADDR_OFF / PCIE_CONF_DATA_OFF, you must map a > >> MBus window, which provides a memory-mapped view of the PCI > >> configuration space. > >> > >> Definitely not impossible to implement, but the driver doesn't work > >> as-is. > > > > Ok. > > Unfortunately this isn't something I can test as the PCIe port on the SoC > doesn't go anywhere in my case. As I said, this wouldn't be a problem: we should consider the PCI and PCIe ports on this chip as completely separate anyway, so we can work on the drivers independently. > >>> We also don't seem to need any MBUS window setup for the I/O and > >>> memory spaces, which greatly simplifies the driver compared to the > >>> pci-mvebu one, it would be a fairly straightforward implementation > >>> based on pci-host-generic.c (which unfortunately just got way > >>> more complicated and might need to go on a diet). > >> > >> MBus windows are needed. See: > >> > >> mvebu_mbus_add_window_remap_by_id(ORION_MBUS_PCI_IO_TARGET, > >> ORION_MBUS_PCI_IO_ATTR, > >> ORION5X_PCI_IO_PHYS_BASE, > >> ORION5X_PCI_IO_SIZE, > >> ORION5X_PCI_IO_BUS_BASE); > >> mvebu_mbus_add_window_by_id(ORION_MBUS_PCI_MEM_TARGET, > >> ORION_MBUS_PCI_MEM_ATTR, > >> ORION5X_PCI_MEM_PHYS_BASE, > >> ORION5X_PCI_MEM_SIZE); > >> > >> in orion5x_setup_wins(). > > > > Ok, I was just looking at the wrong file, as they are set up from > > common.c, not pci.c. > > > >> Note that we already have some Orion5x converted to DT, and that use > >> PCI: board-rd88f5182.c is an example. So we could very well take Jamie > >> patches as-is, and move later to a DT-representation for PCI/PCIe. > > > > Ah, I thought all the DT users were moved to mach-mvebu. I agree > > this new patch isn't introducing anything we don't already have then, > > so we can just take it, but the conversion will not be nice when > > we do that. > > Yes, board-wnr854t.c is a clone of the existing board-rd88f5182.c. > Although I'd presume that it too would need late_initcall() or somesuch > mechanism to probe PCI once the GPIO controller is available. Deferred probing should be fine once the driver is migrated from pci_common_init() to registering the host bridge directly. Arnd From mboxrd@z Thu Jan 1 00:00:00 1970 From: arnd@arndb.de (Arnd Bergmann) Date: Tue, 19 Jul 2016 11:46:44 +0200 Subject: [PATCH v0 06/10] arm: orion5x: Add DT-based support for Netgear WNR854T In-Reply-To: References: <1468679348-10522-1-git-send-email-jm@lentin.co.uk> <1792384.6N9lHjmBFc@wuerfel> Message-ID: <4018990.2Ivz6MntMW@wuerfel> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Tuesday, July 19, 2016 10:40:16 AM CEST Jamie Lentin wrote: > On Mon, 18 Jul 2016, Arnd Bergmann wrote: > > > On Monday, July 18, 2016 11:44:24 AM CEST Thomas Petazzoni wrote: > >> > >> On Sun, 17 Jul 2016 22:41:35 +0200, Arnd Bergmann wrote: > >> > >>> I would assume that the PCIe port should work out of the box with the driver > >> > >> Unfortunately, no. The PCIe on Orion5x requires a workaround for > >> reading/writing the PCI configuration space. Instead of doing MMIO > >> accesses to PCIE_CONF_ADDR_OFF / PCIE_CONF_DATA_OFF, you must map a > >> MBus window, which provides a memory-mapped view of the PCI > >> configuration space. > >> > >> Definitely not impossible to implement, but the driver doesn't work > >> as-is. > > > > Ok. > > Unfortunately this isn't something I can test as the PCIe port on the SoC > doesn't go anywhere in my case. As I said, this wouldn't be a problem: we should consider the PCI and PCIe ports on this chip as completely separate anyway, so we can work on the drivers independently. > >>> We also don't seem to need any MBUS window setup for the I/O and > >>> memory spaces, which greatly simplifies the driver compared to the > >>> pci-mvebu one, it would be a fairly straightforward implementation > >>> based on pci-host-generic.c (which unfortunately just got way > >>> more complicated and might need to go on a diet). > >> > >> MBus windows are needed. See: > >> > >> mvebu_mbus_add_window_remap_by_id(ORION_MBUS_PCI_IO_TARGET, > >> ORION_MBUS_PCI_IO_ATTR, > >> ORION5X_PCI_IO_PHYS_BASE, > >> ORION5X_PCI_IO_SIZE, > >> ORION5X_PCI_IO_BUS_BASE); > >> mvebu_mbus_add_window_by_id(ORION_MBUS_PCI_MEM_TARGET, > >> ORION_MBUS_PCI_MEM_ATTR, > >> ORION5X_PCI_MEM_PHYS_BASE, > >> ORION5X_PCI_MEM_SIZE); > >> > >> in orion5x_setup_wins(). > > > > Ok, I was just looking at the wrong file, as they are set up from > > common.c, not pci.c. > > > >> Note that we already have some Orion5x converted to DT, and that use > >> PCI: board-rd88f5182.c is an example. So we could very well take Jamie > >> patches as-is, and move later to a DT-representation for PCI/PCIe. > > > > Ah, I thought all the DT users were moved to mach-mvebu. I agree > > this new patch isn't introducing anything we don't already have then, > > so we can just take it, but the conversion will not be nice when > > we do that. > > Yes, board-wnr854t.c is a clone of the existing board-rd88f5182.c. > Although I'd presume that it too would need late_initcall() or somesuch > mechanism to probe PCI once the GPIO controller is available. Deferred probing should be fine once the driver is migrated from pci_common_init() to registering the host bridge directly. Arnd