From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932644AbcKKKHe (ORCPT ); Fri, 11 Nov 2016 05:07:34 -0500 Received: from szxga02-in.huawei.com ([119.145.14.65]:7773 "EHLO szxga02-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932511AbcKKKHa (ORCPT ); Fri, 11 Nov 2016 05:07:30 -0500 Subject: Re: [PATCH V5 1/3] ARM64 LPC: Indirect ISA port IO introduced To: Benjamin Herrenschmidt , Mark Rutland References: <1478576829-112707-1-git-send-email-yuanzhichang@hisilicon.com> <1478576829-112707-2-git-send-email-yuanzhichang@hisilicon.com> <20161108120323.GC15297@leverpostej> <1478647002.7430.69.camel@kernel.crashing.org> <20161110112224.GB4418@leverpostej> <1478806353.7430.137.camel@kernel.crashing.org> CC: , , , , , , , , , , , , , , , , , , , , , From: "zhichang.yuan" Message-ID: <5825984B.3030303@hisilicon.com> Date: Fri, 11 Nov 2016 18:07:07 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <1478806353.7430.137.camel@kernel.crashing.org> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.57.79.81] X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, Ben, Mark, Thanks for your comments! These are helpful! On 2016/11/11 3:32, Benjamin Herrenschmidt wrote: > On Thu, 2016-11-10 at 11:22 +0000, Mark Rutland wrote: >> On POWER8, our PCIe doesn't do IO at all, but we have an LPC bus behind >>> firmware calls ;-) We use that infrastructure to plumb in the LPC bus. >> >> Just to check, do you hook that in your inb/outb/etc? > > Yes. > >> Generally, it would seem nicer if we could have higher-level >> isa_{inb,outb,whatever} accessors that we could hook separately from >> other IO. > > Maybe but generally speaking, we don't discriminate accessors per bus, > ie, readl etc... work on all memory mapped busses, inb... works on all > busses with an "IO space", at least that's been the idea. It probably > all comes from the fact that PCI IO and ISA are the same space on > x86 and most other platforms (not all). > >> We don't necessarily have to move all ISA drivers over to that if we had >> a separate symbol for that interface. > > What I do on ppc today is that I have a chunk of virtual address space > that is reserved for "IO space". The first 64k are "reserved" in that > they route to "the primary" ISA bus (for legacy crap that uses hard > coded addresses, though I use that for my LPC bus too). I "allocate" > space for the PCI IO spaces higher in that space. Was I to support more > LPC busses I could allocate them up there too. > I have similar idea as your PPC MMIO. We notice the prototype of {in/out()} is something like that: static inline u8 inb(unsigned long addr) static inline void outb(u8 value, unsigned long addr) The type of parameter 'addr' is unsigned long. For I/O space, it is big enough. So, could you divide this 'addr' into several bit segments? The top 8 bits is defined as bus index. For normal direct IO, the bus index is 0. For those bus device which need indirectIO or some special I/O accessors, when these devices are initializing, can request to allocate an unique ID to them, and register their own accessors to the entry which is corresponding to the ID. In this way, we can support multiple domains, I think. But I am not sure whether it is feasible, for example, are there some architectures/platforms had populated the top 8 bits? Do we need to request IO region from ioport_resource for those devices? etc... Thanks, Zhichang > The IO resource of a given device thus becomes the actual IO port plus > the offset of the base of the segment it's in. > > For memory mapped IO, inb/outb will just add the virtual address of > the base of all IO space to that. The hooking mechanism will pickup > the stuff that isn't memory mapped. > > It's a bit messy but then IO space performance has never been a huge > worry since IO cycles tend to be very slow to begin with. > > Note: We also have the ISA memory and ISA FW spaces that we don't have > good accessors for. They somewhat exist (I think the fbdev layer uses > some for vga) but it's messy. > > Cheers, > Ben. > > > . >