From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934461AbcKJPhr convert rfc822-to-8bit (ORCPT ); Thu, 10 Nov 2016 10:37:47 -0500 Received: from lhrrgout.huawei.com ([194.213.3.17]:4133 "EHLO lhrrgout.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934425AbcKJPhm (ORCPT ); Thu, 10 Nov 2016 10:37:42 -0500 From: Gabriele Paoloni To: Arnd Bergmann , "linux-arm-kernel@lists.infradead.org" CC: 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" , "liviu.dudau@arm.com" , "bhelgaas@google.com" , "zhichang.yuan02@gmail.com" Subject: RE: [PATCH V5 3/3] ARM64 LPC: LPC driver implementation on Hip06 Thread-Topic: [PATCH V5 3/3] ARM64 LPC: LPC driver implementation on Hip06 Thread-Index: AQHSOW8K5aTV4LQ1M0O6BqeWVWJhSaDPRlGAgAFKX+CAAJ6WAIAAmH8AgAAqcoCAAGmLEA== Date: Thu, 10 Nov 2016 15:36:49 +0000 Message-ID: References: <1478576829-112707-1-git-send-email-yuanzhichang@hisilicon.com> <2825537.ADCNsGqGxn@wuerfel> <5824165A.4040303@hisilicon.com> <17821285.aIcTyCGn5n@wuerfel> In-Reply-To: <17821285.aIcTyCGn5n@wuerfel> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.81.106] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090203.5824941D.002C,ss=1,re=0.000,recu=0.000,reip=0.000,cl=1,cld=1,fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: bc6b87b81db1a65b898e94f609b08fb7 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Arnd > -----Original Message----- > From: Arnd Bergmann [mailto:arnd@arndb.de] > Sent: 10 November 2016 09:12 > To: linux-arm-kernel@lists.infradead.org > Cc: Yuanzhichang; 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 > > On Thursday, November 10, 2016 2:40:26 PM CET zhichang.yuan wrote: > > On 2016/11/10 5:34, Arnd Bergmann wrote: > > > On Wednesday, November 9, 2016 12:10:43 PM CET Gabriele Paoloni > wrote: > > >>> On Tuesday, November 8, 2016 11:47:09 AM CET zhichang.yuan wrote: > > >>>> + /* > > >>>> + * The first PCIBIOS_MIN_IO is reserved specifically for > > >>> indirectIO. > > >>>> + * It will separate indirectIO range from pci host > bridge to > > >>>> + * avoid the possible PIO conflict. > > >>>> + * Set the indirectIO range directly here. > > >>>> + */ > > >>>> + lpcdev->io_ops.start = 0; > > >>>> + lpcdev->io_ops.end = PCIBIOS_MIN_IO - 1; > > >>>> + lpcdev->io_ops.devpara = lpcdev; > > >>>> + lpcdev->io_ops.pfin = hisilpc_comm_in; > > >>>> + lpcdev->io_ops.pfout = hisilpc_comm_out; > > >>>> + lpcdev->io_ops.pfins = hisilpc_comm_ins; > > >>>> + lpcdev->io_ops.pfouts = hisilpc_comm_outs; > > >>> > > >>> I have to look at patch 2 in more detail again, after missing a > few > > >>> review > > >>> rounds. I'm still a bit skeptical about hardcoding a logical I/O > port > > >>> range here, and would hope that we can just go through the same > > >>> assignment of logical port ranges that we have for PCI buses, > > >>> decoupling > > >>> the bus addresses from the linux-internal ones. > > >> > > >> The point here is that we want to avoid any conflict/overlap > between > > >> the LPC I/O space and the PCI I/O space. With the assignment above > > >> we make sure that LPC never interfere with PCI I/O space. > > > > > > But we already abstract the PCI I/O space using dynamic > registration. > > > There is no need to hardcode the logical address for ISA, though > > > I think we can hardcode the bus address to start at zero here. > > > > Do you means that we can pick up the maximal I/O address from all > children's > > device resources?? > > The driver should not look at the resources of its children, just > register a range of addresses dynamically, as I suggested in an > earlier review. Where should we get the range from? For LPC we know that it is going Work on anything that is not used by PCI I/O space, and this is why we use [0, PCIBIOS_MIN_IO] > > > 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: These accessors do not operate on IO tokens: If (arm64_extio_ops->start > addr || arm64_extio_ops->end < addr) addr is not going to be an I/O token; in fact patch 2/3 imposes that the I/O tokens will start at PCIBIOS_MIN_IO. So from 0 to PCIBIOS_MIN_IO we have free physical addresses that the accessors can operate on. Thanks Gab > > if (arm64_extio_ops->pfout) \ > arm64_extio_ops->pfout(arm64_extio_ops->devpara,\ > addr - arm64_extio_ops->start, value, > sizeof(type)); \ > > We know that the ISA/LPC bus can only have up to 65536 ports, > so you can register all of those, or possibly limit it further to > 1024 or 4096 ports, whichever matches the bus implementation. > > Arnd