From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756012AbbLAL36 (ORCPT ); Tue, 1 Dec 2015 06:29:58 -0500 Received: from mout.kundenserver.de ([212.227.126.134]:60802 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755200AbbLAL3z (ORCPT ); Tue, 1 Dec 2015 06:29:55 -0500 From: Arnd Bergmann To: linux-arm-kernel@lists.infradead.org Cc: Masahiro Yamada , devicetree@vger.kernel.org, Mark Rutland , Thomas Petazzoni , Pawel Moll , Andrew Lunn , Linux Kernel Mailing List , Rob Herring , Frank Rowand , Gregory CLEMENT Subject: Re: [Question] DT-Bindings for run-time configurable bus? Date: Tue, 01 Dec 2015 12:29:03 +0100 Message-ID: <9491984.N5sK0AKL2L@wuerfel> User-Agent: KMail/4.11.5 (Linux/3.16.0-10-generic; KDE/4.11.5; x86_64; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:y8gFaU5uSo7m7/mrsJNufNm59+ly90rUWkT4tWSIOFztOmxg5kI QAvu9Hm+ftNkJjvUfCf6lW7nzaNnOpcUnJ5ctJixMBgvAxFmrhoiRLuDtfxUMqw8x+0Tbit yQtiVm1Kj6DLONRVTp1vpaXU8IqHGYaAKyac58y0o85mu3Sg9uR1nMAbQkAgobULPFo7i88 4jx903+adLrxKjmfvb+aw== X-UI-Out-Filterresults: notjunk:1;V01:K0:EPc2PxNihxk=:rq6tBfmBHY9lZiuwMwFvBU QyNCMISc5nk5Me1SajIjEZf42gq6SBsAfWqbZm7Z6EGtRqNQ1LXvYkdIkMPpU81GixNzuTdpP 5Hec5AqTN46eegyQ8VEkXb7moqwhsjb0pCA14Hk1NYXF5N+Nsp6yfRv9RC7JgPvVzSdAHZ+c3 7hRIYMwi42NNAghVO13dPEtVAelH7GPMSMZEoUaZzQPumNBvNGBDY1jtS4wKNxhCTaSSl8vFe lpVLizxL5mstIUr8mTWrPYOODMM7FFZh756f0U/0rwBZ4Yn/oKfLNai7Uu2gmTSclOoIn+NG1 P8+6QTRGcHOY0RbonB/1wXe7moVAvuqKhq2kHa3h4yMeftzigC0QEZMjuUv5Pxe25TixAZE2D wlUIEF5Dg5cqZSzJ4NazHx6gR2MfyTLShyLKw3vM3MgKnNH4YyewdpEiErSRgHiuZHNB2rrg1 IgPeqFRsOpn+kAZgLN3IpEgphZVubGaDaDsZoabipPndiIoWK5s8MgOy9BdDZqA6zgVhP13iI iCcIFwLZNbx7yH6eDQBj9xXTHr4RyouIucSIqg3gUBmYfgf2B++UNHkXnD2mDz9nJfT+6B3pw Ekb3PitNlNQBbt02XD7NIdLzeN37FLffVH8WRnmO5iZgWAO8QGv5r+lpFWaveOLzm24Frg2dK 6So1bIQaKvMAQivc2unDA3Q2Z1TUuZdCBaveYKD7wemrvHBJezM8vU3PgB4xxULxXR6PIxjA9 +yinGPoyNB+qsTt/ Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tuesday 01 December 2015 13:30:25 Masahiro Yamada wrote: > Hello experts, > > I am tackling on a new bus driver, but I am worndering > what the DT-binding specification should be. > > Here is my hardware situation: > > My SoC has an external bus (it is called UniPhier System Bus). > This is a simple parallel bus with address, data, > chip-selects, and some other control signals. > It supports up to 8 chip-selects. > > Each CS address space can be mapped onto the CPU view, > and it must be configured run-time via the bus controller registers. > > Let's assume this situation: > > - An ethernet device is connected at the offset address 0x01f00000 of CS1 > - A UART device is connected at the offset address 0x00200000 of CS5 > > > A quick draft of device tree would be as follows: > > > amba { > compatible = "simple-bus"; > #address-cells = <1>; > #size-cells = <1>; > ranges; > > extbus { > compatible = "socionext,uniphier-system-bus"; > reg = <0x58c00000 0x400>; /* registers of bus controller */ > #address-cells = <2>; > #size-cells = <1>; > > ethernet@1,01f00000 { > compatible = "smsc,lan9115"; > reg = <1 0x01f00000 0x1000>; > interrupts = <0 48 4> > phy-mode = "mii"; > }; > > uart@5,00200000 { > compatible = "ns16550a"; > reg = <5 0x00200000 0x20>; > interrupts = <0 49 4> > clock-frequency = <12288000>; > }; > }; > }; > That looks reasonable. > Please note "ranges" property is missing from the extbus node. > > As mentioned above, the address translation from the external bus > to the parent bus is run-time configurable. > > > It is possible to map > CS1 of extbus to 0x40000000-0x41ffffff of CPU view > CS5 of extbus to 0x42000000-0x43ffffff of CPU view > > It is also possible to map > CS1 of extbus to 0x46000000-0x47ffffff of CPU view > CS5 of extbus to 0x44000000-0x45ffffff of CPU view > > There is nothing preventing us from a particular > address mapping. > It is completely up to the software (driver) > to choose one mapping from another. Ok. > And I notice a conflict between the followings. > > [1] Device Tree is a hardware description language. > It should not describe the software configuration. > > So, ranges such as > ranges = <1 0 0x40000000 0x02000000 > 5 0 0x42000000 0x02000000>; > > or > > ranges = <1 0 0x46000000 0x02000000 > 5 0 0x44000000 0x02000000>; > > are configuration information, which should not be > included in the device tree. > > Any address mapping is OK as long as no region overlap occurs. > No point to specify "ranges" from the device tree. > > > [2] of_translate_address() expects "ranges" in every bus node > > When we need to translate the "reg" property into the CPU-viewed address, > we call of_translate_address(). It translates addresses, > parsing "ranges" property when crossing buses. > It potentially means, "ranges" properties are statically defined > in the device tree. > > > I have not been able to find a good way > to solve the conflict between [1] and [2]. > > > To sum up, what I want is: > > - Let the driver to configure the address translation on run-time > - Once the bus is configured, I want the sub nodes to be accessed > from the CPU, like the other statically instantiated devices. > > > Any comment is welcome! > > > BTW, perhaps Marvell Mbus has a similar situation (run-time configurable)? > (Documentation/devicetree/bindings/bus/mvebu-mbus.txt) > I am not familiar with such SoCs, though. Yes, this is the example I was thinking of. For mbus, we decided that doing the full dynamic reassignment of addresses is too bothersome for the OS, so the DT contains a "reasonable" default that the OS can use. This is also what we do for most PCI host controllers on embedded systems. They tend to have programmable translations, and the DT contains the settings that are known to work and that the driver uses to set up the I/O windows even if a lot of other settings would work just as well. A more traditional setup that we use on server-class machines is that the bootloader decides what the windows should be, sets them up and documents them in DT. The OS can still change them if it wants to, but it doesn't actually have to worry about the fact that those are programmable, or what registers are used for programming them. Arnd