Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753754AbcKRMZe (ORCPT ); Fri, 18 Nov 2016 07:25:34 -0500 Received: from mout.kundenserver.de ([212.227.17.13]:61472 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752439AbcKRMZb (ORCPT ); Fri, 18 Nov 2016 07:25:31 -0500 From: Arnd Bergmann To: Gabriele Paoloni Cc: "liviu.dudau@arm.com" , "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@go ogle.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 13:24:28 +0100 Message-ID: <2822893.F0LqNAm9bT@wuerfel> User-Agent: KMail/5.1.3 (Linux/4.4.0-34-generic; KDE/5.18.0; x86_64; ; ) In-Reply-To: References: <1478576829-112707-1-git-send-email-yuanzhichang@hisilicon.com> <2281986.miqFuFkAbO@wuerfel> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:anqhbA2cBSHKbwV855Rm/8pD4mU/mHIdhY9gSgpRFYfoNqBbAgc ZxFljtMxYQFyB382VsYftPjtTKhI86Ok0YPtEcJxLNZSEC+MeD/7F8/+fEDYIvgbO/KaRf1 WQYW2+Su8gcqSMNH7sqy9+n6HpVkd0xPl2SATQ9CMeFh4fUTNwQvbsy5Fgteln1omDtxz3Z ZCub+YHw9JNqGxj8TnsjQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:AJY40oMvV14=:EnlQb1MrcjiP1Cpbmy+sG3 03VLJTDX/eivA6Gxac9f8pbxHauPxnadXyclJnKBbwAKQONS9gNpuq8B8tH4aU33I6HCQcY6x s/hzk1mtVxUKgN3f/s3eO8jlb4w8jSDzOriAlHHGCPbDx50GocONgBePfyL6BXA98bPB20hlk PbwV0fwNO9LKCvpoRAWI866YoOgiTkT3m5iYWFcv/Y4PPEVPceCfqRdxINK1R1sEOGNu+bPzI bmzlmvyhZHy67oDtIdxp4uUqimabxyIcwIB7od6KuVAz+GL9IQIMk+JVtr5T2HjfIDzKBkhmb PatO93SrGdYFrcVkoJLTqmrcNvWSaAtFHKSOSTc2zLCgsuVgd9A4xFRZ6aqAmtxbkHDRS5znh 2JPtS/LHuSESbtRvZuWCpv/8c2TMTuZYjxA0/aiCnZZNV+Gli656pBI5VlJl/dSdaxngHIEaq LjIcRV9/E4zXmkT3HP5PgPhy2rospmcY5NLw7I7v/Mev8nPxsz5WqdRhknjC4CZTTJHkDjhh4 AIA/feUx2o83mUgTjdva9oLK0V7w2uOtmG/4Hfxp7ARljqWjf628xaEaLEhtQE1YJi7fA0VO9 nhhNHs6uEf7mOSKbSIS0tX8am3mqtz0XfTH7KxNhFHg+5wxhXaaqSTQzlVAW9e+g/6c7CrE5Q ZthyEC8qI4ivkWj1Wk0k6Ck4eP6wqY6x8bO+kr0GF9PgJSEMcFYgwN3OBeZa/sN/fAkWmwXeG 4zAtXn4yQREGrQbb Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4618 Lines: 103 On Friday, November 18, 2016 12:07:28 PM CET Gabriele Paoloni wrote: > > From: Arnd Bergmann [mailto:arnd@arndb.de] > > 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. > > Yes correct so if we go for the single domain solution arch that > have PCIBIOS_MIN_IO=0 cannot support special devices such as LPC > unless we also redefine PCIBIOS_MIN_IO, right? This is what I was referring to below as the difference between a) and b): Setting PCIBIOS_MIN_IO=0 means you cannot have LPC behind PCI, but it shouldn't stop you from having a separate LPC bridge. > > 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. > > I am not very on the "generalized" multi-domain solution... > Currently the IO accessors prototypes have an unsigned long addr > as input parameter. If we live in a multi-domain IO system > how can we distinguish inside the accessor which domain addr > belongs to? The easiest change compared to the v5 code would be to walk a linked list of 'struct extio_ops' structures rather than assuming there is only ever one of them. I think one of the earlier versions actually did this. Another option the IA64 approach mentioned in another subthread today, looking up the operations based on an index from the upper bits of the port number. If we do this, we probably want to do that for all PIO access and replace the entire virtual address remapping logic with that. I think Bjorn in the past argued in favor of such an approach, while I advocated the current scheme for simplicity based on how every I/O space these days is just memory mapped (which now turned out to be false, both on powerpc and arm64). Arnd