From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752720AbcKRKTY (ORCPT ); Fri, 18 Nov 2016 05:19:24 -0500 Received: from mout.kundenserver.de ([212.227.17.13]:50177 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751685AbcKRKTV (ORCPT ); Fri, 18 Nov 2016 05:19:21 -0500 From: Arnd Bergmann To: "liviu.dudau@arm.com" Cc: Gabriele Paoloni , "linux-arm-kernel@lists.infradead.org" , Yuanzhichang , "mark.rutland@arm.com" , "devicetree@vger.kernel.org" , "lorenzo.pieralisi@arm.com" , "minyard@acm.org" , "linux-pci@vger.kernel.org" , "benh@kernel.crashing.org" , John Garry , "will.deacon@arm.com" , "linux-kernel@vger.kernel.org" , "xuwei (O)" , Linuxarm , "zourongrong@gmail.com" , "robh+dt@kernel.org" , "kantyzc@163.com" , "linux-serial@vger.kernel.org" , "catalin.marinas@arm.com" , "olof@lixom.net" , "bhelgaas@google.com" , "zhichang.yuan02@gmail.com" , Jason Gunthorpe , Thomas Petazzoni Subject: Re: [PATCH V5 3/3] ARM64 LPC: LPC driver implementation on Hip06 Date: Fri, 18 Nov 2016 11:17:57 +0100 Message-ID: <2281986.miqFuFkAbO@wuerfel> User-Agent: KMail/5.1.3 (Linux/4.4.0-34-generic; KDE/5.18.0; x86_64; ; ) In-Reply-To: <20161114112625.GO10219@e106497-lin.cambridge.arm.com> References: <1478576829-112707-1-git-send-email-yuanzhichang@hisilicon.com> <20161114112625.GO10219@e106497-lin.cambridge.arm.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:EApRc4s/TaPu5yCLir9LLWsq1vxfoxu+ceJviJGc8Weu8rlY4B1 xX9pyoug1TyyOFdQH6dabIxAWWVP0Sx6P2LUqkAqcpJPDMiFdS8QbO+SfloWVnwA5CrTSxq po5cyoInlR849DJsdhNMTFgPDaVt3feartTt6uQ9GAjyFcliFuCLbixHlqox9wieu4d4Izr U2OC+p5bSqpP8B+dPJbsA== X-UI-Out-Filterresults: notjunk:1;V01:K0:bWt2urixH/s=:Ed0cpyz8xSYMxsUACzBxtQ Ik3xEHuBbY/54xAuqPjnUdN5ZMa4QJ7NwS+mUM+P6oNJK5+afL02GRs3k5iJHQ/DCTicgfEUy VZBIuCCNVCcfBzkGntDjnKCY66xZmA+xP3L60jLWZeM6WLgCKtfEq1L0Xfozshn6Kqb7c+OAn sPg6IMubXD1qbgU4RNMILE3iJwbRv1EQeKugYQ8If9wTjuBtv6KlhDiB/4gGMW1eKhNO8fHFu 7MBJvDWevbkH3jyi3ZME9Vj1ZWdllCxDM7n03FsGwuLz3WI1ZPbB5HUfj1rPkrzJRrJCSfSXX mgLUwDhFD8Yyxg9P1n9HPFOaM1zPq4qsIVswUZSzn/SpPwuyyPTfBiGtDqAuuloin9M7n6tDr pl8V3RaKE9hDNJzLa4gb/momMwtYCgYBLbUE+q5YBo7cj9xL9Kp61bxhlJVJNRiLsMpUvfb6j 6v0tyrxi/2qGDmYNBL2SzDtcSaedTXz09kNHqAO9SWCDQU4niAJs7BjWeaDIdZ6IquO8QdGDo ZXWavHc+vb3LNrZ06Z7pTntmteR4dUlaOl50cj/JM8jVQD10YJID4kmF6D+63qBfEnZ7G04Uo wVZ0k2Kcb6L7vq3K+hVxpWCBqZYLcHkzbctsupOXwsI69EBXDu5JqaxLXzVJcW+hFx8Yz057Q aixvaM9TurNs26B65i5IOunG220XNFbes5m3RE14GnLtx8J9bPUJTRlWvbNbBHVcdnBsVdaTp G1Mke1y0rlKdUG5O Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Monday, November 14, 2016 11:26:25 AM CET liviu.dudau@arm.com wrote: > On Mon, Nov 14, 2016 at 08:26:42AM +0000, Gabriele Paoloni wrote: > > > Nope, that is not what it means. It means that PCI devices can see I/O > > > addresses > > > on the bus that start from 0. There never was any usage for non-PCI > > > controllers > > > > So I am a bit confused... > > From http://www.firmware.org/1275/bindings/isa/isa0_4d.ps > > It seems that ISA buses operate on cpu I/O address range [0, 0xFFF]. > > I thought that was the reason why for most architectures we have > > PCIBIOS_MIN_IO equal to 0x1000 (so I thought that ISA controllers > > usually use [0, PCIBIOS_MIN_IO - 1] ) > > First of all, cpu I/O addresses is an x86-ism. ARM architectures and others > have no separate address space for I/O, it is all merged into one unified > address space. So, on arm/arm64 for example, PCIBIOS_MIN_IO = 0 could mean > that we don't care about ISA I/O because the platform does not support having > an ISA bus (e.g.). I think to be more specific, PCIBIOS_MIN_IO=0 would indicate that you cannot have a PCI-to-ISA or PCI-to-LPC bridge in any PCI domain. This is different from having an LPC master outside of PCI, as that lives in its own domain and has a separately addressable I/O space. > > As said before this series forbid IO tokens to be in [0, PCIBIOS_MIN_IO) > > to allow special ISA controllers to use that range with special > > accessors. > > Having a variable threshold would make life much more difficult > > as there would be a probe dependency between the PCI controller and > > the special ISA one (PCI to wait for the special ISA device to be > > probed and set the right threshold value from DT or ACPI table). > > > > Instead using PCIBIOS_MIN_IO is easier and should not impose much > > constraint as [PCIBIOS_MIN_IO, IO_SPACE_LIMIT] is available to > > the PCI controller for I/O tokens... > > What I am suggesting is to leave PCIBIOS_MIN_IO alone which still reserves > space for ISA controller and add a PCIBIOS_MIN_DIRECT_IO that will reserve > space for your direct address I/O on top of PCIBIOS_MIN_IO. The PCIBIOS_MIN_DIRECT_IO name still suggests having something related to PCIBIOS_MIN_IO, but it really isn't. We are talking about multiple concepts here that are not the same but that are somewhat related: a) keeping PCI devices from allocating low I/O ports on the PCI bus that would conflict with ISA devices behind a bridge of the same bus. b) reserving the low 0x0-0xfff range of the Linux-internal I/O space abstraction to a particular LPC or PCI domain to make legacy device drivers work that hardcode a particular port number. c) Redirecting inb/outb to call a domain-specific accessor function rather than doing the normal MMIO window for an LPC master or more generally any arbitrary LPC or PCI domain that has a nonstandard I/O space. [side note: actually if we generalized this, we could avoid assigning an MMIO range for the I/O space on the pci-mvebu driver, and that would help free up some other remapping windows] I think there is no need to change a) here, we have PCIBIOS_MIN_IO today and even if we don't need it, there is no obvious downside. I would also argue that we can ignore b) for the discussion of the HiSilicon LPC driver, we just need to assign some range of logical addresses to each domain. That means solving c) is the important problem here, and it shouldn't be so hard. We can do this either with a single special domain as in the v5 patch series, or by generalizing it so that any I/O space mapping gets looked up through the device pointer of the bus master. Arnd From mboxrd@z Thu Jan 1 00:00:00 1970 From: Arnd Bergmann Subject: Re: [PATCH V5 3/3] ARM64 LPC: LPC driver implementation on Hip06 Date: Fri, 18 Nov 2016 11:17:57 +0100 Message-ID: <2281986.miqFuFkAbO@wuerfel> References: <1478576829-112707-1-git-send-email-yuanzhichang@hisilicon.com> <20161114112625.GO10219@e106497-lin.cambridge.arm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7Bit Return-path: In-Reply-To: <20161114112625.GO10219-2JSQmVVBSi7ZROr8t4l/smS4ubULX0JqMm0uRHvK7Nw@public.gmane.org> Sender: devicetree-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: "liviu.dudau-5wv7dgnIgG8@public.gmane.org" Cc: Gabriele Paoloni , "linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org" , Yuanzhichang , "mark.rutland-5wv7dgnIgG8@public.gmane.org" , "devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , "lorenzo.pieralisi-5wv7dgnIgG8@public.gmane.org" , "minyard-HInyCGIudOg@public.gmane.org" , "linux-pci-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , "benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org" , John Garry , "will.deacon-5wv7dgnIgG8@public.gmane.org" , "linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , "xuwei (O)" , Linuxarm , "zourongrong-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org" , "robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org" List-Id: devicetree@vger.kernel.org On Monday, November 14, 2016 11:26:25 AM CET liviu.dudau-5wv7dgnIgG8@public.gmane.org wrote: > On Mon, Nov 14, 2016 at 08:26:42AM +0000, Gabriele Paoloni wrote: > > > Nope, that is not what it means. It means that PCI devices can see I/O > > > addresses > > > on the bus that start from 0. There never was any usage for non-PCI > > > controllers > > > > So I am a bit confused... > > From http://www.firmware.org/1275/bindings/isa/isa0_4d.ps > > It seems that ISA buses operate on cpu I/O address range [0, 0xFFF]. > > I thought that was the reason why for most architectures we have > > PCIBIOS_MIN_IO equal to 0x1000 (so I thought that ISA controllers > > usually use [0, PCIBIOS_MIN_IO - 1] ) > > First of all, cpu I/O addresses is an x86-ism. ARM architectures and others > have no separate address space for I/O, it is all merged into one unified > address space. So, on arm/arm64 for example, PCIBIOS_MIN_IO = 0 could mean > that we don't care about ISA I/O because the platform does not support having > an ISA bus (e.g.). I think to be more specific, PCIBIOS_MIN_IO=0 would indicate that you cannot have a PCI-to-ISA or PCI-to-LPC bridge in any PCI domain. This is different from having an LPC master outside of PCI, as that lives in its own domain and has a separately addressable I/O space. > > As said before this series forbid IO tokens to be in [0, PCIBIOS_MIN_IO) > > to allow special ISA controllers to use that range with special > > accessors. > > Having a variable threshold would make life much more difficult > > as there would be a probe dependency between the PCI controller and > > the special ISA one (PCI to wait for the special ISA device to be > > probed and set the right threshold value from DT or ACPI table). > > > > Instead using PCIBIOS_MIN_IO is easier and should not impose much > > constraint as [PCIBIOS_MIN_IO, IO_SPACE_LIMIT] is available to > > the PCI controller for I/O tokens... > > What I am suggesting is to leave PCIBIOS_MIN_IO alone which still reserves > space for ISA controller and add a PCIBIOS_MIN_DIRECT_IO that will reserve > space for your direct address I/O on top of PCIBIOS_MIN_IO. The PCIBIOS_MIN_DIRECT_IO name still suggests having something related to PCIBIOS_MIN_IO, but it really isn't. We are talking about multiple concepts here that are not the same but that are somewhat related: a) keeping PCI devices from allocating low I/O ports on the PCI bus that would conflict with ISA devices behind a bridge of the same bus. b) reserving the low 0x0-0xfff range of the Linux-internal I/O space abstraction to a particular LPC or PCI domain to make legacy device drivers work that hardcode a particular port number. c) Redirecting inb/outb to call a domain-specific accessor function rather than doing the normal MMIO window for an LPC master or more generally any arbitrary LPC or PCI domain that has a nonstandard I/O space. [side note: actually if we generalized this, we could avoid assigning an MMIO range for the I/O space on the pci-mvebu driver, and that would help free up some other remapping windows] I think there is no need to change a) here, we have PCIBIOS_MIN_IO today and even if we don't need it, there is no obvious downside. I would also argue that we can ignore b) for the discussion of the HiSilicon LPC driver, we just need to assign some range of logical addresses to each domain. That means solving c) is the important problem here, and it shouldn't be so hard. We can do this either with a single special domain as in the v5 patch series, or by generalizing it so that any I/O space mapping gets looked up through the device pointer of the bus master. Arnd -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.kundenserver.de ([212.227.17.13]:50177 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751685AbcKRKTV (ORCPT ); Fri, 18 Nov 2016 05:19:21 -0500 From: Arnd Bergmann To: "liviu.dudau@arm.com" Cc: Gabriele Paoloni , "linux-arm-kernel@lists.infradead.org" , Yuanzhichang , "mark.rutland@arm.com" , "devicetree@vger.kernel.org" , "lorenzo.pieralisi@arm.com" , "minyard@acm.org" , "linux-pci@vger.kernel.org" , "benh@kernel.crashing.org" , John Garry , "will.deacon@arm.com" , "linux-kernel@vger.kernel.org" , "xuwei (O)" , Linuxarm , "zourongrong@gmail.com" , "robh+dt@kernel.org" , "kantyzc@163.com" , "linux-serial@vger.kernel.org" , "catalin.marinas@arm.com" , "olof@lixom.net" , "bhelgaas@google.com" , "zhichang.yuan02@gmail.com" , Jason Gunthorpe , Thomas Petazzoni Subject: Re: [PATCH V5 3/3] ARM64 LPC: LPC driver implementation on Hip06 Date: Fri, 18 Nov 2016 11:17:57 +0100 Message-ID: <2281986.miqFuFkAbO@wuerfel> In-Reply-To: <20161114112625.GO10219@e106497-lin.cambridge.arm.com> References: <1478576829-112707-1-git-send-email-yuanzhichang@hisilicon.com> <20161114112625.GO10219@e106497-lin.cambridge.arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: linux-pci-owner@vger.kernel.org List-ID: On Monday, November 14, 2016 11:26:25 AM CET liviu.dudau@arm.com wrote: > On Mon, Nov 14, 2016 at 08:26:42AM +0000, Gabriele Paoloni wrote: > > > Nope, that is not what it means. It means that PCI devices can see I/O > > > addresses > > > on the bus that start from 0. There never was any usage for non-PCI > > > controllers > > > > So I am a bit confused... > > From http://www.firmware.org/1275/bindings/isa/isa0_4d.ps > > It seems that ISA buses operate on cpu I/O address range [0, 0xFFF]. > > I thought that was the reason why for most architectures we have > > PCIBIOS_MIN_IO equal to 0x1000 (so I thought that ISA controllers > > usually use [0, PCIBIOS_MIN_IO - 1] ) > > First of all, cpu I/O addresses is an x86-ism. ARM architectures and others > have no separate address space for I/O, it is all merged into one unified > address space. So, on arm/arm64 for example, PCIBIOS_MIN_IO = 0 could mean > that we don't care about ISA I/O because the platform does not support having > an ISA bus (e.g.). I think to be more specific, PCIBIOS_MIN_IO=0 would indicate that you cannot have a PCI-to-ISA or PCI-to-LPC bridge in any PCI domain. This is different from having an LPC master outside of PCI, as that lives in its own domain and has a separately addressable I/O space. > > As said before this series forbid IO tokens to be in [0, PCIBIOS_MIN_IO) > > to allow special ISA controllers to use that range with special > > accessors. > > Having a variable threshold would make life much more difficult > > as there would be a probe dependency between the PCI controller and > > the special ISA one (PCI to wait for the special ISA device to be > > probed and set the right threshold value from DT or ACPI table). > > > > Instead using PCIBIOS_MIN_IO is easier and should not impose much > > constraint as [PCIBIOS_MIN_IO, IO_SPACE_LIMIT] is available to > > the PCI controller for I/O tokens... > > What I am suggesting is to leave PCIBIOS_MIN_IO alone which still reserves > space for ISA controller and add a PCIBIOS_MIN_DIRECT_IO that will reserve > space for your direct address I/O on top of PCIBIOS_MIN_IO. The PCIBIOS_MIN_DIRECT_IO name still suggests having something related to PCIBIOS_MIN_IO, but it really isn't. We are talking about multiple concepts here that are not the same but that are somewhat related: a) keeping PCI devices from allocating low I/O ports on the PCI bus that would conflict with ISA devices behind a bridge of the same bus. b) reserving the low 0x0-0xfff range of the Linux-internal I/O space abstraction to a particular LPC or PCI domain to make legacy device drivers work that hardcode a particular port number. c) Redirecting inb/outb to call a domain-specific accessor function rather than doing the normal MMIO window for an LPC master or more generally any arbitrary LPC or PCI domain that has a nonstandard I/O space. [side note: actually if we generalized this, we could avoid assigning an MMIO range for the I/O space on the pci-mvebu driver, and that would help free up some other remapping windows] I think there is no need to change a) here, we have PCIBIOS_MIN_IO today and even if we don't need it, there is no obvious downside. I would also argue that we can ignore b) for the discussion of the HiSilicon LPC driver, we just need to assign some range of logical addresses to each domain. That means solving c) is the important problem here, and it shouldn't be so hard. We can do this either with a single special domain as in the v5 patch series, or by generalizing it so that any I/O space mapping gets looked up through the device pointer of the bus master. Arnd From mboxrd@z Thu Jan 1 00:00:00 1970 From: arnd@arndb.de (Arnd Bergmann) Date: Fri, 18 Nov 2016 11:17:57 +0100 Subject: [PATCH V5 3/3] ARM64 LPC: LPC driver implementation on Hip06 In-Reply-To: <20161114112625.GO10219@e106497-lin.cambridge.arm.com> References: <1478576829-112707-1-git-send-email-yuanzhichang@hisilicon.com> <20161114112625.GO10219@e106497-lin.cambridge.arm.com> Message-ID: <2281986.miqFuFkAbO@wuerfel> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Monday, November 14, 2016 11:26:25 AM CET liviu.dudau at arm.com wrote: > On Mon, Nov 14, 2016 at 08:26:42AM +0000, Gabriele Paoloni wrote: > > > Nope, that is not what it means. It means that PCI devices can see I/O > > > addresses > > > on the bus that start from 0. There never was any usage for non-PCI > > > controllers > > > > So I am a bit confused... > > From http://www.firmware.org/1275/bindings/isa/isa0_4d.ps > > It seems that ISA buses operate on cpu I/O address range [0, 0xFFF]. > > I thought that was the reason why for most architectures we have > > PCIBIOS_MIN_IO equal to 0x1000 (so I thought that ISA controllers > > usually use [0, PCIBIOS_MIN_IO - 1] ) > > First of all, cpu I/O addresses is an x86-ism. ARM architectures and others > have no separate address space for I/O, it is all merged into one unified > address space. So, on arm/arm64 for example, PCIBIOS_MIN_IO = 0 could mean > that we don't care about ISA I/O because the platform does not support having > an ISA bus (e.g.). I think to be more specific, PCIBIOS_MIN_IO=0 would indicate that you cannot have a PCI-to-ISA or PCI-to-LPC bridge in any PCI domain. This is different from having an LPC master outside of PCI, as that lives in its own domain and has a separately addressable I/O space. > > As said before this series forbid IO tokens to be in [0, PCIBIOS_MIN_IO) > > to allow special ISA controllers to use that range with special > > accessors. > > Having a variable threshold would make life much more difficult > > as there would be a probe dependency between the PCI controller and > > the special ISA one (PCI to wait for the special ISA device to be > > probed and set the right threshold value from DT or ACPI table). > > > > Instead using PCIBIOS_MIN_IO is easier and should not impose much > > constraint as [PCIBIOS_MIN_IO, IO_SPACE_LIMIT] is available to > > the PCI controller for I/O tokens... > > What I am suggesting is to leave PCIBIOS_MIN_IO alone which still reserves > space for ISA controller and add a PCIBIOS_MIN_DIRECT_IO that will reserve > space for your direct address I/O on top of PCIBIOS_MIN_IO. The PCIBIOS_MIN_DIRECT_IO name still suggests having something related to PCIBIOS_MIN_IO, but it really isn't. We are talking about multiple concepts here that are not the same but that are somewhat related: a) keeping PCI devices from allocating low I/O ports on the PCI bus that would conflict with ISA devices behind a bridge of the same bus. b) reserving the low 0x0-0xfff range of the Linux-internal I/O space abstraction to a particular LPC or PCI domain to make legacy device drivers work that hardcode a particular port number. c) Redirecting inb/outb to call a domain-specific accessor function rather than doing the normal MMIO window for an LPC master or more generally any arbitrary LPC or PCI domain that has a nonstandard I/O space. [side note: actually if we generalized this, we could avoid assigning an MMIO range for the I/O space on the pci-mvebu driver, and that would help free up some other remapping windows] I think there is no need to change a) here, we have PCIBIOS_MIN_IO today and even if we don't need it, there is no obvious downside. I would also argue that we can ignore b) for the discussion of the HiSilicon LPC driver, we just need to assign some range of logical addresses to each domain. That means solving c) is the important problem here, and it shouldn't be so hard. We can do this either with a single special domain as in the v5 patch series, or by generalizing it so that any I/O space mapping gets looked up through the device pointer of the bus master. Arnd