Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753113AbcKRLrg (ORCPT ); Fri, 18 Nov 2016 06:47:36 -0500 Received: from mout.kundenserver.de ([217.72.192.73]:51982 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751180AbcKRLrd (ORCPT ); Fri, 18 Nov 2016 06:47:33 -0500 From: Arnd Bergmann To: "zhichang.yuan" Cc: linux-arm-kernel@lists.infradead.org, "mark.rutland@arm.com" , "devicetree@vger.kernel.org" , "lorenzo.pieralisi@arm.com" , Gabriele Paoloni , "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" , "liviu.dudau@arm.com" , "bhelgaas@google.com" , "zhichang.yuan02@gmail.com" Subject: Re: [PATCH V5 3/3] ARM64 LPC: LPC driver implementation on Hip06 Date: Fri, 18 Nov 2016 12:46:21 +0100 Message-ID: <2565107.vdSUAxpRt4@wuerfel> User-Agent: KMail/5.1.3 (Linux/4.4.0-34-generic; KDE/5.18.0; x86_64; ; ) In-Reply-To: <582469C8.9090609@hisilicon.com> References: <1478576829-112707-1-git-send-email-yuanzhichang@hisilicon.com> <17821285.aIcTyCGn5n@wuerfel> <582469C8.9090609@hisilicon.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:dS2mJ1AMIMKqVDjf3ewJZeJMFJ6sq3XrOIOj7cd4pKZW8yoKl2O 4Xw/yb2M7sT+dNYHAtniGUIpUUfu1ZRqduQoYtxXzO8LpMw+Lz7HqdgKsFOih4/m4gIVpJm cZiTBBJqhdk+R94YyEkOEIA/ZZzgWIDl1wYK92jhhjQp4t9gLS/PNfEUxj7wFm4bWmuJTSW yia6I2FJNyMeAS48osvqw== X-UI-Out-Filterresults: notjunk:1;V01:K0:SEOHuQITKA8=:S56gFBESvlnkKgMRY1CKiX 1QUYxni6fDhszoQ2v2eOogJCerG8PCDj2iR7uSR3poDRC0y9iMlTC9F7YGlDd4Sj9yhyXcwNi tuWWM7LUNNIBjfLUIwGA6UsUwWcq8w5AZp9PfmbbATw8mVvZFgmxyAXvgyc5lZwAZlEGBO1qS gtQqJnLorkcgPH8Ee1W68bG4pG+JvmU+FX/xcbx3rBNy8dLCYxMdD3/9dsx3TnkPLwOKXHPhy tvUeSzAMQLatRoj61yzgoPYtsWjt2tcL6ksiPmH9pDi/jOD56012uC0iF+ZQ1DFvIjUeCKXSl cz0YDl3M8XdSPOIIsOANIL3XBTeaqts3jxufXrIMzfw8T7YAIGFLgC2m43DwMpHagtHQ0M4E8 BUTGprTAa4O6r1bvdByAjzBIjm5HRaw7MG8X6DKeDRpPSrZULUOuEIpznYGytpw8s3YWpkgjh E4Jd7UYPgZrMC4NVHBDkaWDWHHW5FijC/2YALnuz15nBZbNnDhdGIWF4mDHD/x8ax4cXrAz/t sCjuA4WlYN9UAplQ67kQvKSuzjc9j8UT3hdEGH7UGKE0zJSpAOJ5f9To2LQdaXYLARlZtyF4o I6gxKYcGp0D8LFJJPGJvq/bi5eBlc44RZzlyplxeSSkVAAiqS4+idn99y756CsVb/zBNjxRwT nQRMUtXFP8CGz7O/RqvWty0JOuGbbqgSytEYcvUU6stEMCAcPDT/V4/yzFLw3+xMLG9y4tlzb luAlaNpuPty/jm7s Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2451 Lines: 51 [found this old mail in my drafts folder, might as well send it now] On Thursday, November 10, 2016 8:36:24 PM CET zhichang.yuan wrote: > Sorry! I can't catch your idea yet:( > > When to register the I/O range? Is it done just after the successfully > of_translate_address() during the children scanning? No, you do it when first finding the bus itself, just like we do for PCI host bridges. > If yes, when a child is scanning, there is no range data in arm64_extio_ops. The > addr_is_indirect_io() calling in of_get_isa_indirect_io() don't need. All we can > check is just whether the address to be translated is IO and is under a parent > device which has no 'ranges' property. The children should only be scanned after the I/O range has been registered for the parent. > > Your current version has > > > > if (arm64_extio_ops->pfout) \ > > arm64_extio_ops->pfout(arm64_extio_ops->devpara,\ > > addr, value, sizeof(type)); \ > > > > Instead, just subtract the start of the range from the logical > > port number to transform it back into a bus-local port number: > > > > if (arm64_extio_ops->pfout) \ > > arm64_extio_ops->pfout(arm64_extio_ops->devpara,\ > > addr - arm64_extio_ops->start, value, sizeof(type)); \ > > > I think there is some information needed sync. > In the old patch-set, we don't bypass the pci_address_to_pio() after > successfully of_translate_address(). In this way, we don't need to reserve any > PIO space for our LPC since the logical port are from the same mapping > algorithm. Based on this way, the port number in the device resource is logical > one, then we need to subtract the start of the resource to get back the > bus-local port. > > From V3, we don't apply the mapping based on pci_address_to_pio(), the > of_translate_address() return the bus-local port directly and store into > relevant device resource. So, in the current arm64_extio_ops->pfout(), the > reverse translation don't need anymore. The input "addr" is bus-local port now. Ok, so this would have to be changed again: If we want to support multiple bus domains, of_translate_address() must translate between the bus specific address and the general Linux I/O port number. Even without doing that, it seems nicer to not overlap the range of the first PCI host bridge. Arnd