All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matthew Wilcox <willy@debian.org>
To: James Bottomley <James.Bottomley@steeleye.com>
Cc: Linus Torvalds <torvalds@osdl.org>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	Linux Arch list <linux-arch@vger.kernel.org>,
	Al Viro <viro@parcelfarce.linux.theplanet.co.uk>,
	Andrew Morton <akpm@osdl.org>,
	Alan Cox <alan@lxorguk.ukuu.org.uk>,
	"David S. Miller" <davem@redhat.com>,
	Jeff Garzik <jgarzik@pobox.com>
Subject: Re: RFC: being more anal about iospace accesses..
Date: Thu, 16 Sep 2004 03:33:25 +0100	[thread overview]
Message-ID: <20040916023325.GJ642@parcelfarce.linux.theplanet.co.uk> (raw)
In-Reply-To: <1095287935.1688.4.camel@mulgrave>

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

  reply	other threads:[~2004-09-16  2:33 UTC|newest]

Thread overview: 97+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-09-08 22:57 RFC: being more anal about iospace accesses Linus Torvalds
2004-09-08 23:07 ` David S. Miller
2004-09-08 23:25   ` Linus Torvalds
2004-09-09  1:19   ` Linus Torvalds
2004-09-09  4:36     ` David S. Miller
2004-09-09  5:56       ` Richard Henderson
2004-09-09  5:04     ` viro
2004-09-09  5:05       ` David S. Miller
2004-09-09  5:13       ` Linus Torvalds
2004-09-09  6:08         ` viro
2004-09-09  8:27   ` Geert Uytterhoeven
2004-09-09  6:23 ` David Woodhouse
2004-09-09 13:14   ` Alan Cox
2004-09-11  6:09 ` Linus Torvalds
2004-09-11  6:42   ` Anton Blanchard
2004-09-11  7:26     ` Benjamin Herrenschmidt
2004-09-11  7:29     ` Geert Uytterhoeven
2004-09-11  7:23   ` Benjamin Herrenschmidt
2004-09-11 14:42   ` Alan Cox
2004-09-15 15:03 ` Linus Torvalds
2004-09-15 16:30   ` Being " Linus Torvalds
2004-09-15 16:54     ` Jörn Engel
2004-09-15 17:07       ` Linus Torvalds
2004-09-15 17:32         ` Jörn Engel
2004-09-15 17:57           ` Linus Torvalds
2004-09-15 18:06             ` Linus Torvalds
2004-09-15 19:34             ` Greg KH
2004-09-15 19:53               ` Linus Torvalds
2004-09-15 20:06                 ` Greg KH
2004-09-16 14:58             ` Horst von Brand
2004-09-15 17:45         ` Nikita Danilov
2004-09-15 18:09           ` Linus Torvalds
2004-09-15 18:40         ` Chris Wedgwood
2004-09-15 17:07       ` Jeff Garzik
2004-09-15 17:16       ` Roland Dreier
2004-09-15 17:39         ` Linus Torvalds
2004-09-15 20:07           ` Russell King
2004-09-15 17:36       ` Horst von Brand
2004-09-15 17:40       ` Brian Gerst
2004-09-15 16:56     ` Dave Jones
2004-09-15 17:19     ` Roger Luethi
2004-09-15 17:23     ` Richard B. Johnson
2004-09-15 22:21     ` Deepak Saxena
2004-09-15 22:46       ` Linus Torvalds
2004-09-15 23:09         ` Deepak Saxena
2004-09-16 12:51           ` Geert Uytterhoeven
2004-09-16 22:10             ` Deepak Saxena
2004-09-15 22:29     ` Roland Dreier
2004-09-15 23:26       ` Being more careful " Linus Torvalds
2004-09-16  0:10         ` viro
2004-09-16 11:40           ` David Woodhouse
2004-09-16 12:25         ` David Woodhouse
2004-09-16 14:01           ` Linus Torvalds
2004-09-18  9:46             ` Kai Henningsen
2004-09-15 19:02   ` RFC: being more anal " Geert Uytterhoeven
2004-09-15 19:16     ` Linus Torvalds
2004-09-15 19:40       ` Matthew Wilcox
2004-09-15 20:10         ` Linus Torvalds
2004-09-15 20:17           ` Linus Torvalds
2004-09-16 12:17           ` David Woodhouse
2004-09-16 13:52             ` Linus Torvalds
2004-09-15 20:20       ` Russell King
2004-09-15 20:34         ` Linus Torvalds
2004-09-15 20:51           ` Linus Torvalds
2004-09-15 22:38       ` James Bottomley
2004-09-16  2:33         ` Matthew Wilcox [this message]
2004-09-16  4:28           ` Linus Torvalds
2004-09-16  4:57             ` Benjamin Herrenschmidt
2004-09-16  4:58               ` Benjamin Herrenschmidt
2004-09-16 13:41             ` Matthew Wilcox
2004-09-16 18:21               ` Linus Torvalds
2004-09-16 18:52                 ` Jesse Barnes
2004-09-16 19:09                   ` Linus Torvalds
2004-09-16 20:02                     ` Jesse Barnes
2004-09-16 20:37                       ` James Bottomley
2004-09-16 20:42                         ` Jesse Barnes
2004-09-16 21:37                           ` Grant Grundler
2004-09-16 20:04                   ` David S. Miller
2004-09-16 20:13                     ` Jeff Garzik
2004-09-16 20:45                       ` David S. Miller
2004-09-16 20:20                     ` Jesse Barnes
2004-09-17  5:17                   ` Benjamin Herrenschmidt
2004-09-17 15:30                     ` Jesse Barnes
2004-09-16 19:01                 ` Linus Torvalds
2004-09-16 19:13                   ` Jeff Garzik
2004-09-16 19:50                     ` Linus Torvalds
2004-09-16 20:07                       ` Alan Cox
2004-09-17  5:44                       ` Benjamin Herrenschmidt
2004-09-17  5:20                   ` Benjamin Herrenschmidt
2004-09-17 15:03                     ` Linus Torvalds
2004-09-16 22:30             ` Matthew Wilcox
2004-09-16 22:42               ` Linus Torvalds
2004-09-16 22:46                 ` Jeff Garzik
2004-09-16 23:15                   ` Linus Torvalds
2004-09-16 23:30                     ` Jeff Garzik
2004-09-16 23:43                       ` Linus Torvalds
2004-09-17 12:44                 ` Matthew Wilcox

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20040916023325.GJ642@parcelfarce.linux.theplanet.co.uk \
    --to=willy@debian.org \
    --cc=James.Bottomley@steeleye.com \
    --cc=akpm@osdl.org \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=davem@redhat.com \
    --cc=geert@linux-m68k.org \
    --cc=jgarzik@pobox.com \
    --cc=linux-arch@vger.kernel.org \
    --cc=torvalds@osdl.org \
    --cc=viro@parcelfarce.linux.theplanet.co.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.