From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755891AbbIWVaE (ORCPT ); Wed, 23 Sep 2015 17:30:04 -0400 Received: from mout.kundenserver.de ([212.227.126.187]:62431 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755544AbbIWVaB (ORCPT ); Wed, 23 Sep 2015 17:30:01 -0400 From: Arnd Bergmann To: Ray Jui Cc: linux-arm-kernel@lists.infradead.org, Florian Fainelli , Rob Herring , Mark Rutland , devicetree@vger.kernel.org, Pawel Moll , Ian Campbell , linux-kernel@vger.kernel.org, bcm-kernel-feedback-list@broadcom.com, Kumar Gala Subject: Re: [PATCH v2 5/9] ARM: dts: Move all Cygnus peripherals into soc bus Date: Wed, 23 Sep 2015 23:29:30 +0200 Message-ID: <1969821.ZhaOpCV2D1@wuerfel> User-Agent: KMail/4.11.5 (Linux/3.16.0-10-generic; KDE/4.11.5; x86_64; ; ) In-Reply-To: <55FC8C0F.9020308@broadcom.com> References: <1442611454-16331-1-git-send-email-rjui@broadcom.com> <1929872.EmD9YkfFuv@wuerfel> <55FC8C0F.9020308@broadcom.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:J9VQY5EgNvnq4gTKMSYMyl05pU1SN0tgiTLyg4AzCFshGVreb7n tHM7mSacSOdO+nb+6uJQSgq4MtHXSbG2CYUCWgrQOKe/mPpxLgX2A7e7mCLDe/tnAMY1oYc X5VGMxvcz1XaJho7g74ZJ8mu8R4RlV37cGpc6Rme0Wicyx0IZoSVAPS9OqHtJWqyoFaaCBD uS6jejUlBakAICzhz1LGg== X-UI-Out-Filterresults: notjunk:1;V01:K0:yK29r2xtEsk=:UN0BA7jFzBbPpw8hikehBK +2v6P4j8ML+zyFUlfkXo3US7MczGsO5sVhwxe2p2c4wp4nLAAWn0QwdhtS7pi8erm0y3B7VBK vsrLdH8d8DgN4OJXMsB1WUPObTyXoB89JzEyKJZUNQWyAAr7mudTPya4F5+Lr0K7j4NQ0/bX1 j3MrW5zz4fmeuH0uLYvaDCcI9eh3OJ7JXc14JOSvLVefzpgj5IKRG/Mt07Pxlq15T80pr2K+N sOxVfEdNaw8bhYlif+QzzABMnYN2sl+5xHEBQNRgAO4LWHiYxO8WCKcq4KILUnmK/ygBjRsdS d8rzlQEb4RDCh6p1bJ5Arej7zmk+wjVqoll1Jg8+BPQqJEt39ec+srxbO+SnFAn4syPXzVHfQ CO2LR9qJDs/5771MIz/yUn9gM0zSEEFF4b198q/xSXJHt4RW9dGzUh7L5+LFMpZyTyYFF7u58 GUKpz4kuopb3O9X4inroXxCmm/3UjAgyORZexNLOD7GECR3SzFg2cec4LnNpjL8MGmPAEr/Yo klG/4ID0+P07Mg9yLq6KmxTtTp3VeZMeAmlDzCK3yZmDufmnV5jTTecF18HwJaDdFGY3WBk0Y rJOuLbgRrOLTt57db1oedeFDrF2TzLzLTM2A+4vYtoFEEWGKLIsVICT/jg5p5YSIl9tvB2JUD A690OJz0FNU5pz/O6axjp0HjVt0oo8wKWEsVncG31dd/3ksgYB8ErtLyetdxudgQk+MZa++QX f7ZD9UwG303gfcJm Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Friday 18 September 2015 15:11:27 Ray Jui wrote: > On 9/18/2015 2:34 PM, Arnd Bergmann wrote: > > On Friday 18 September 2015 14:24:10 Ray Jui wrote: > >> + soc { > >> + compatible = "simple-bus"; > >> + ranges; > >> + #address-cells = <1>; > >> + #size-cells = <1>; > > > >> + pinctrl: pinctrl@0301d0c8 { > >> > > > > Similarly to the core bus, this seems to have address ranges 0x03xxxxxx and > > 0x18xxxxxx on it, so put those into the ranges. > > > > Okay we have an issue here. For whatever reason, the Cygnus ASIC team > decided to put registers for the same block in random locations. We see > similar issues in all of our other iProc based SoCs. We have > communicated this to our ASIC team, and hopefully they can revert the > trend for the next SoC. > > For example, the gpio_ccm has registers in the following regions: > > gpio_ccm: gpio@1800a000 { > compatible = "brcm,cygnus-ccm-gpio"; > reg = <0x1800a000 0x50>, > <0x0301d164 0x20>; > > NAND is worse, it has registers in 3 different separate regions: > > nand: nand@18046000 { > compatible = "brcm,nand-iproc", "brcm,brcmnand-v6.1", > "brcm,brcmnand"; > reg = <0x18046000 0x600>, <0xf8105408 0x600>, > <0x18046f00 0x20>; > > As you can see, this makes it impossible to define a proper address > range for the bus; therefore, I'll have to keep the ranges undefined and > a simple 1:1 mapping under this bus. Hmm, you could still try to list them as non-overlapping with other buses on the root node like ranges = <0x03000000 0x03000000 0x01000000>, <0x18000000 0x18000000 0x01000000>, <0xf8000000 0xf8000000 0x01000000>; which clarifies how the bus is wired up in hardware. Alternatively, you could make a more elaborate mapping, if there are in fact multiple hardware ranges, like #address-cells = <2>; # space:offset ranges = <1 0 0x03000000 0x01000000>, <2 0 0x18000000 0x01000000>, <3 0 0xf8000000 0x01000000>; It really depends on what the hardware designers were thinking. If the AXI bus actually decodes the entire 32-bit address range and devices are just located at random addresses in there, your current scheme is probably closest to reality. > > It probably also makes sense to name the bus according to what kind of > > bus (axi, ahb, plb, ...) is used here. If the soc has nested buses > > (e.g. an ahb connected to an axi bus,) then model both of them in the DT. > > Based on the block diagram from the ASIC team, it looks like all of them > are connected to one major AXI fabric. I can rename the bus to AXI. Ok. Arnd