From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from parcelfarce.linux.theplanet.co.uk ([195.92.249.252]:62431 "EHLO www.linux.org.uk") by vger.kernel.org with ESMTP id S267333AbUIOTkD (ORCPT ); Wed, 15 Sep 2004 15:40:03 -0400 Date: Wed, 15 Sep 2004 20:40:01 +0100 From: Matthew Wilcox Subject: Re: RFC: being more anal about iospace accesses.. Message-ID: <20040915194001.GH642@parcelfarce.linux.theplanet.co.uk> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: To: Linus Torvalds Cc: Geert Uytterhoeven , Linux Arch list , Al Viro , Andrew Morton , Alan Cox , "David S. Miller" , Jeff Garzik List-ID: On Wed, Sep 15, 2004 at 12:16:35PM -0700, Linus Torvalds wrote: > On Wed, 15 Sep 2004, Geert Uytterhoeven wrote: > > Before people really start using this: what's the advantage of this scheme > > compared to e.g. dev->busops->in8(), which some of us have been waiting for > > since a long time? > > Ehh, exactly why would you wait for that? I'm no fan of bus->ops->in8, but the ioread8() interface is basically impossible for some architectures. There's just not enough information in a single void * cookie to make this work; not without screwing the speed of readb() down the the speed of inb(). For example, on some of the older PA machines, we can have an EISA controller and multiple PCI controllers. readb() is great, it's all mapped into a flat memory space, and there are no problems. But inb() is a royal PITA. First, we have to decode the port number to figure out which controller it's under, then (if it's EISA) swizzle the bits in the port number to get to an address, but if it's PCI, we have to take a spinlock, write the port number into a register of the right controller, read the data back from a different register (which is what triggers the io port cycle to be generated on the PCI bus) and unlock the spinlock. ioport_map() looks great for the EISA controller because it lets us pre-map the port number to an address. But it'd actually be deadly if the device has more than 8 consecutive IO ports [1]. For the PCI controllers, it's a complete misery. We could do something horrid like assuming no IO is less than 2GB and returning a cookie from ioport_map() that then gets decoded into somethign similar to the current dance, but that's really not pleasant. I'm told SH is in even worse state than PA, but I haven't looked at that code. Could we have a 'dev' parameter to ioread8()? Please? [1] The implementation is: if (port & 0x300) { return 0xfc000000 | ((port & 0xfc00) >> 6) | ((port & 0x3f8) << 9) | (port & 7); } else { return 0xfc000000 | port; } -- "Next the statesmen will invent cheap lies, putting the blame upon the nation that is attacked, and every man will be glad of those conscience-soothing falsities, and will diligently study them, and refuse to examine any refutations of them; and thus he will by and by convince himself that the war is just, and will thank God for the better sleep he enjoys after this process of grotesque self-deception." -- Mark Twain