From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933058AbcAMJ14 (ORCPT ); Wed, 13 Jan 2016 04:27:56 -0500 Received: from mout.kundenserver.de ([212.227.126.134]:60349 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932571AbcAMJ1v (ORCPT ); Wed, 13 Jan 2016 04:27:51 -0500 From: Arnd Bergmann To: Rongrong Zou Cc: Benjamin Herrenschmidt , liviu.dudau@arm.com, Rongrong Zou , devicetree@vger.kernel.org, Catalin Marinas , Corey Minyard , gregkh@linuxfoundation.org, Will Deacon , linux-kernel@vger.kernel.org, linuxarm@huawei.com, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH v1 3/3] ARM64 LPC: update binding doc Date: Wed, 13 Jan 2016 10:26:54 +0100 Message-ID: <4302652.ztAKMKjFNQ@wuerfel> User-Agent: KMail/4.11.5 (Linux/3.16.0-10-generic; KDE/4.11.5; x86_64; ; ) In-Reply-To: <5695F007.3070005@gmail.com> References: <568912EE.9030009@huawei.com> <1452664413.2403.20.camel@kernel.crashing.org> <5695F007.3070005@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:hqNnLvOgqrCZGNpkFs6ImQCnTGeQAlrBmUR68Xy+3HYU8m1RULa S5E5hWnjTu9E40rjr1gRyw9XzlNIDuvJoQK8KvoP9A0YHXjGNGkFZu8wF2sFzdYz+/pqNON RTzOAwdKAlt2qTmrvA2ivbRbtaceU5bKAROq24WqdKeJ41VUX3ppgkOz5mWNSDvtqCKM5B/ kbq3yWw30jFI7NnkOAsDw== X-UI-Out-Filterresults: notjunk:1;V01:K0:DSsXZ+80HpQ=:m4FW9Iw4t4MxuFj9NBXaZ2 Ajvn0CHvA8oJn6Qs8BzlMvIrYaKEPPm4fFAWPSbB8FPb+DPq0H8VwWGiTSwCcZSYGrrTO29AS Oh/ymaZVbE5gGVd6DcPsVbT5qdMaB+eQzGixFN06mUCj5BTQblF2Ea6IXc4jZ4NEJfj4BgMah YQO6ltfajF9RM3BCJl7PprwsNcRP2b99jJUvmqkRCCTLRGHJvJXJWS4gRTPndViHnD7xQbr/Q 09aSr4Ks7WWhCrarvFauI2g68M9fHGazey8yF9W5dT4fFUlsL0P6jZlZ+rHSH3ogI1f6lWEXz ZsqkWHnXq/JFruBKJOMwxFr6MHRaB9Ggw6a+bWcz6IHcxDIhs113xRl0qUUhj0gzF06zp33CW cXkN1BEo3GQmZOobj9XRFZICi0APKMUINSOvT6f7bd/Yt1y141HU5bg+4b9zX0W49DSWoV71U YaEvqjUh/w3NTJVPEMAxsapEInjqeIvgbrh6YjCkqsjDhzUbMzL39DplU3/GoTgMe3D1XoiXX ewZk3DPkr0bEgQKvUjqzct5lmMu0DKSNTjsfLn/d/rrWqzYxfYJ10pAHLD4un//xEUJ0+imqP dfEIJf0EyFFRVByAw4TZkEVfKArFy6GnUGUgtszqopwQ8Pow0R1JdW3j9Fi+5T2Iz22Ne1qCY MLah5mQwQsDvrzKnfV8YHjPk8KLa8CBLY+YY9/VSD0SzPROSIQLXF7/fXPLqFj9UbrpT5mE5C 3vLzLv3e8tAu1ggO Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wednesday 13 January 2016 14:34:47 Rongrong Zou wrote: > On 2016/1/13 13:53, Benjamin Herrenschmidt wrote: > > On Tue, 2016-01-12 at 23:52 +0100, Arnd Bergmann wrote: > >> On Tuesday 12 January 2016 15:13:35 liviu.dudau@arm.com wrote: > >>>> int of_address_to_resource(struct device_node *dev, int index, > >>>> struct resource *r) > >>>> { > >>>> ... > >>>> /* flags can be get here, without ranges property reqired. > >>>> * if the reg = <0x0 0xe4 4>, I can get flag of > >> IORESOURCE_MEM, > >>>> * if the reg = <0x1 0xe4 4>, I can get flag of > >> IORESOURCE_IO, > >>> > >>> That is strange, the parent node has #address-cells = <2> so the > >> first two numbers should be part > >>> of the address and not influence the flags. Can you add some > >> debugging in of_get_address() and > >>> try to figure out what bus is used in *flags = bus- > >>> get_flags(prop) ? > >>> > >>> > >> > >> This is the standard ISA binding. The first cell is the address space > >> (IO or MEM), the second cell is the address within that space. This > >> is similar to how PCI works. > > > > Picking up that mid-way, I have LPC busses on power and am using a > > similar binding. I'll try to grab some examples and review the > > document tomorrow (only just noticed it while unpiling emails post- > > vacation). I really should have thought of that, as you mentioned already that there is an ast2400 on those machines, and no I/O space on the PCI bus. Too bad we have to keep the I/O workarounds alive on PowerPC now, I was already hoping they could go away after spider-pci gets phased out. > Thanks for reviewing this, I found a similar implementation at arch/powerpc/ > platform/powernv/opal-lpc.c and I had get some ideas from your work. It is > nice to me. I'm expecting your suggestion.Thanks in advance. Unfortunately, the way that PCI host bridges on PowerPC are handled is a bit different from what we do on ARM64, otherwise the obvious solution would be to move the I/O workarounds to an architecture independent location. Maybe it's still possible, but that also requires some refactoring then. Arnd