From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from parcelfarce.linux.theplanet.co.uk ([195.92.249.252]:14512 "EHLO www.linux.org.uk") by vger.kernel.org with ESMTP id S266555AbUIPCd1 (ORCPT ); Wed, 15 Sep 2004 22:33:27 -0400 Date: Thu, 16 Sep 2004 03:33:25 +0100 From: Matthew Wilcox Subject: Re: RFC: being more anal about iospace accesses.. Message-ID: <20040916023325.GJ642@parcelfarce.linux.theplanet.co.uk> References: <1095287935.1688.4.camel@mulgrave> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1095287935.1688.4.camel@mulgrave> Sender: To: James Bottomley Cc: Linus Torvalds , Geert Uytterhoeven , Linux Arch list , Al Viro , Andrew Morton , Alan Cox , "David S. Miller" , Jeff Garzik List-ID: On Wed, Sep 15, 2004 at 06:38:50PM -0400, James Bottomley wrote: > Please can we not do it this way, that was the old pci_map_single et al > which we've just spent quite a bit of time converting to > dma_map_single. It might not matter to the PCI centric people, but the > generic DMA API was a wonderful simplification to the rest of us. > > Can we start iomap off on the right foot and simply do dma_iomap (or > dev_iomap since dma_ may end up to be confusing), taking a struct device > as an argument and let the platform, which knows where the buses are, > map this to the correct operations? Actually, I think we're OK with the current interface here. The routines we have that give us an iomem pointer are: /* Create a virtual mapping cookie for an IO port range */ extern void __iomem *ioport_map(unsigned long port, unsigned int nr); extern void ioport_unmap(void __iomem *); /* Create a virtual mapping cookie for a PCI BAR (memory or IO) */ struct pci_dev; extern void __iomem *pci_iomap(struct pci_dev *dev, int bar, unsigned long max); extern void pci_iounmap(struct pci_dev *dev, void __iomem *); So rather than pass the struct device in, we've got a special function for each bus type. What we haven't dealt with in this interface are: - relaxed reads - byte ordering The relaxed attribute is, I think, not a property of the space we're looking at. It's a property of any given transaction. So I think we really do want a set of ioreadXX_relaxed() functions. Byte ordering I'm less clear on. Is this a property of the area "this area is little endian on the bus, but the host cpu is big endian", or is it a property of an individual transaction? -- "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