From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753000AbcKRJV7 (ORCPT ); Fri, 18 Nov 2016 04:21:59 -0500 Received: from mout.kundenserver.de ([212.227.126.130]:62034 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751788AbcKRJV4 (ORCPT ); Fri, 18 Nov 2016 04:21:56 -0500 From: Arnd Bergmann To: linux-arm-kernel@lists.infradead.org Cc: "zhichang.yuan" , Benjamin Herrenschmidt , Mark Rutland , gabriele.paoloni@huawei.com, catalin.marinas@arm.com, will.deacon@arm.com, linuxarm@huawei.com, lorenzo.pieralisi@arm.com, xuwei5@hisilicon.com, linux-serial@vger.kernel.org, linux-pci@vger.kernel.org, devicetree@vger.kernel.org, minyard@acm.org, marc.zyngier@arm.com, liviu.dudau@arm.com, john.garry@huawei.com, zourongrong@gmail.com, robh+dt@kernel.org, bhelgaas@google.com, kantyzc@163.com, zhichang.yuan02@gmail.com, linux-kernel@vger.kernel.org, olof@lixom.net Subject: Re: [PATCH V5 1/3] ARM64 LPC: Indirect ISA port IO introduced Date: Fri, 18 Nov 2016 10:20:49 +0100 Message-ID: <2436881.9RqUVYxmDf@wuerfel> User-Agent: KMail/5.1.3 (Linux/4.4.0-34-generic; KDE/5.18.0; x86_64; ; ) In-Reply-To: <5825984B.3030303@hisilicon.com> References: <1478576829-112707-1-git-send-email-yuanzhichang@hisilicon.com> <1478806353.7430.137.camel@kernel.crashing.org> <5825984B.3030303@hisilicon.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:cyXG7lraEDSHiU7Dp3W0gkHPFOQyh56HM65J5D+6hq38tHh2fwj sLlJ3uNIynW5hwHhlXYHPI1BngKv8cqB9SLxUFy6pn2MhRjasCNEEwt+nfjUaCtfAsElPSd XMy5zrYYHFbWoL3PWhtIBtjmIzpVAPhJekndo4/xkt+6uqnq7v69T14lTSeSZwn7kQ6V+Sx rc6Y6QFymI8dB/geozweA== X-UI-Out-Filterresults: notjunk:1;V01:K0:NF1qKbnHYI0=:Y7plIfEc9TrAv62bcUviHL 0dSLPaoR+SNbuDEJHYHmKq8sfA6YDMOgPfDNJFqZ2NZxPWCuClvC6gGBzBoqfILt8Gf7FdvVZ FpGSCfhB9TYbZ/ocXKwXVTweJPZ0YwjQuGzV46fgbtWTSzvaD2Wzf9EH1zTTmJDvyWgbECTaR 8wG65OUxupTQ4eVpcoSXBi9qK0NeeGiZdO6igfHT+K6ZneRR/f3zfIwoud2qxK2MxzS+gWgHs HCS/rJ5YaYC+KYXu3bZ8Sjw4LwYwHgEhAcA1zapkgi6sn8xlrq6L3IZ/mW5cOaw9G7vE5tudg ENQTCLJFddW16h9lcu96Ljql7nKoyHpTpMwib3z1yWyVcOXiyX2d3a1VQLVK+gyM9Vgf1g17m uZS/xLH2ov7ZkKot6emiJCY6UXRPbfkvubgQZ1rK26GVo7ZW8yMqFp0/h06/YdS+XhkI5pcEc L+2n6p+qMjUvcEbCOkTLWgIUqycIagScN+wlLxf1N+yuRo9HAOtqH8UAvhPZ6lRHI9TQh/z+8 iiqhdKFuu5cU/a7wDKcN0KWIJN6kSscm8XwrapHEiJfANjFsOmdeOv4htrCtES0/hYqOtpGnC wpCBNNxYNaugSJCEAPk7ckyWF+1hkzTA+6acbrjJ6JZlJ89iyhgAoRtN8uXEZOJuYy/ECAly1 pISDEzZ5eRpt2zUINzu0/G9+jGmIhQu77ZLugwAqIYVQTH5oPKwxjF2N+hQenNS9bCXm/46mk 25NoQxk5Xv8MKyUE Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Friday, November 11, 2016 6:07:07 PM CET zhichang.yuan wrote: > > 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. Ah, have you looked at the IA64 code? It does exactly this. For ARM64 we decided to use the same basic approach as powerpc with a single range of virtual memory for mapping it as that somewhat simplified all cases we knew about at the time. > 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... On a 64-bit architecture, the top 32 bits of the port number are definitely free to use for this, and 8 bits are probably sufficient. Even on 32 bit architectures, I can't see why we'd ever need more than 16 bits worth of addressing within a domain, so using 8 bit domain and 16 bit address leaves 8 or 40 unused bits. Arnd