linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: linux@arm.linux.org.uk (Russell King - ARM Linux)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC v1 01/16] lib: devres: don't enclose pcim_*() functions in CONFIG_HAS_IOPORT
Date: Tue, 11 Dec 2012 16:50:50 +0000	[thread overview]
Message-ID: <20121211165050.GU14363@n2100.arm.linux.org.uk> (raw)
In-Reply-To: <20121211173819.6f2cf32b@skate>

On Tue, Dec 11, 2012 at 05:38:19PM +0100, Thomas Petazzoni wrote:
> Russell,
> 
> On Tue, 11 Dec 2012 16:23:25 +0000, Russell King - ARM Linux wrote:
> 
> > > * ARCH_VEXPRESS should not select NO_IOPORT. It's generally wrong
> > >   to select this in combination with ARCH_MULTIPLATFORM, when some
> > >   of the other platforms you may enable actually have IOPORT mapping
> > >   support.
> > 
> > No.  ARCH_VEXPRESS selects NO_IOPORT because it _does_ _not_ support
> > PCI/ISA IO space.  That in itself is reasonable, but what isn't
> > reasonable is the _negative_ logic being used.  Negative logic in
> > the config system always tends to provoke this kind of sillyness
> > because you're selecting something to be excluded which another
> > platform may require.
> 
> Could you enlighten my very naive understanding of things about PCI/ISA
> IO space? On x86, I seem to understand this is the separate address
> space accessed by the special in/out CPU instructions. Are there ARM
> platforms with the same sort of things?
> 
> As far as I understand, on my ARM Marvell system, everything is
> memory-mapped, so there isn't such a separate PCI/ISA IO space.
> 
> Therefore, why would I need to "select HAVE_IOPORT" simply to be able
> to build libata-sff.c, that is used for PCI drivers that work fine with
> purely memory-mapped registers?

- PCI buses make the distinction between memory accesses and IO accesses.
- ARM doesn't have IO access instructions; everything is memory mapped.
- In order to make the two work together, whatever PCI interface provides
  a way to issue IO accesses via a contiguous memory mapped region.
- The PCI layer and drivers are written to keep these two spaces separate
  so that they remain portable across multiple different platforms.

Therefore, if you have PCI/ISA drivers that make use of IO space, you need
to provide the IO space accessors and mapping functions so that these
drivers can access the IO space on their devices in a platform independent
manner.

  reply	other threads:[~2012-12-11 16:50 UTC|newest]

Thread overview: 107+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-12-07 22:04 [RFC v1] PCIe support for the Armada 370 and Armada XP SoCs Thomas Petazzoni
2012-12-07 22:04 ` [RFC v1 01/16] lib: devres: don't enclose pcim_*() functions in CONFIG_HAS_IOPORT Thomas Petazzoni
2012-12-11 10:43   ` Arnd Bergmann
2012-12-11 16:03     ` Thomas Petazzoni
2012-12-11 16:15       ` Arnd Bergmann
2012-12-11 16:23         ` Russell King - ARM Linux
2012-12-11 16:38           ` Thomas Petazzoni
2012-12-11 16:50             ` Russell King - ARM Linux [this message]
2012-12-11 17:29             ` Alan Cox
2012-12-11 22:20               ` Arnd Bergmann
2012-12-11 22:34           ` Arnd Bergmann
2012-12-11 16:30         ` Thomas Petazzoni
2012-12-11 16:46           ` Russell King - ARM Linux
2012-12-11 17:32             ` Alan Cox
2012-12-11 22:28               ` Arnd Bergmann
2012-12-11 16:55           ` Russell King - ARM Linux
2012-12-11 16:26     ` Russell King - ARM Linux
2012-12-11 17:16       ` Alan Cox
2012-12-11 17:34         ` Russell King - ARM Linux
2012-12-11 17:45           ` Alan Cox
2012-12-11 17:51             ` Russell King - ARM Linux
2012-12-07 22:04 ` [RFC v1 02/16] clk: mvebu: create parent-child relation for PCIe clocks on Armada 370 Thomas Petazzoni
2012-12-07 22:04 ` [RFC v1 03/16] arm: plat-orion: introduce WIN_CTRL_ENABLE in address mapping code Thomas Petazzoni
2012-12-07 22:04 ` [RFC v1 04/16] arm: plat-orion: refactor the orion_disable_wins() function Thomas Petazzoni
2012-12-07 22:04 ` [RFC v1 05/16] arm: plat-orion: introduce orion_{alloc, free}_cpu_win() functions Thomas Petazzoni
2012-12-08 11:53   ` [RFC v1 05/16] arm: plat-orion: introduce orion_{alloc,free}_cpu_win() functions Andrew Lunn
2012-12-08 12:15     ` Thomas Petazzoni
2012-12-07 22:04 ` [RFC v1 06/16] arm: mvebu: add functions to alloc/free PCIe decoding windows Thomas Petazzoni
2012-12-07 22:04 ` [RFC v1 07/16] arm: plat-orion: make common PCIe code usable on mvebu Thomas Petazzoni
2012-12-07 22:04 ` [RFC v1 08/16] arm: mvebu: the core PCIe driver Thomas Petazzoni
2012-12-10  8:28   ` Andrew Lunn
2012-12-10  8:45     ` Thomas Petazzoni
2012-12-10 19:08   ` Jason Gunthorpe
2012-12-11 10:56   ` Arnd Bergmann
2012-12-12 15:58     ` Thomas Petazzoni
2012-12-12 21:51       ` Jason Gunthorpe
2012-12-13 14:58         ` Arnd Bergmann
2012-12-13 17:40           ` Jason Gunthorpe
2012-12-13 19:09             ` Thomas Petazzoni
2012-12-14 19:34         ` Rob Herring
2012-12-13 12:19       ` Arnd Bergmann
2012-12-13 17:54         ` Jason Gunthorpe
2012-12-13 19:12           ` Thomas Petazzoni
2012-12-13 21:46             ` Arnd Bergmann
2012-12-13 22:27               ` Jason Gunthorpe
2012-12-07 22:04 ` [RFC v1 09/16] arm: mvebu: PCIe support is now available on mvebu Thomas Petazzoni
2012-12-07 22:04 ` [RFC v1 10/16] arm: mvebu: add PCIe Device Tree informations for Armada 370 Thomas Petazzoni
2012-12-07 22:04 ` [RFC v1 11/16] arm: mvebu: add PCIe Device Tree informations for Armada XP Thomas Petazzoni
2012-12-07 22:04 ` [RFC v1 12/16] arm: mvebu: PCIe Device Tree informations for OpenBlocks AX3-4 Thomas Petazzoni
2012-12-07 22:04 ` [RFC v1 13/16] arm: mvebu: PCIe Device Tree informations for Armada XP DB Thomas Petazzoni
2012-12-07 22:04 ` [RFC v1 14/16] arm: mvebu: PCIe Device Tree informations for Armada 370 Mirabox Thomas Petazzoni
2012-12-07 22:04 ` [RFC v1 15/16] arm: mvebu: PCIe Device Tree informations for Armada 370 DB Thomas Petazzoni
2012-12-07 22:04 ` [RFC v1 16/16] arm: mvebu: update defconfig with PCI and USB support Thomas Petazzoni
2012-12-07 23:33 ` [RFC v1] PCIe support for the Armada 370 and Armada XP SoCs Jason Gunthorpe
2012-12-10 17:52   ` Stephen Warren
2012-12-10 18:05     ` Thomas Petazzoni
2012-12-10 18:16       ` Stephen Warren
2012-12-10 18:59         ` Thomas Petazzoni
2012-12-10 19:07           ` Jason Gunthorpe
2012-12-10 20:08           ` Stephen Warren
2012-12-10 18:44     ` Jason Gunthorpe
2012-12-10 19:03       ` Thomas Petazzoni
2012-12-10 19:18         ` Jason Gunthorpe
2012-12-12 16:04           ` Thomas Petazzoni
2012-12-12 20:09             ` Jason Gunthorpe
2012-12-16 13:02               ` Thierry Reding
2012-12-11  7:52     ` Thierry Reding
2012-12-11 21:21       ` Stephen Warren
2012-12-12 20:34         ` Thierry Reding
2012-12-12 22:30           ` Stephen Warren
2012-12-13  7:03             ` Thierry Reding
2012-12-13  8:04               ` Jason Gunthorpe
2012-12-13  8:23                 ` Thierry Reding
2012-12-13 18:12                   ` Stephen Warren
2012-12-13 20:42                     ` Thierry Reding
2012-12-13 20:47                       ` Jason Gunthorpe
2012-12-13 21:16                         ` Thierry Reding
2012-12-14 10:05                         ` Thierry Reding
2012-12-14 15:10                       ` Thierry Reding
2012-12-14 17:27                         ` Jason Gunthorpe
2012-12-16 12:33                           ` Thierry Reding
2012-12-17 18:29                             ` Jason Gunthorpe
2012-12-17 19:41                               ` Thierry Reding
2012-12-18  2:10                                 ` Stephen Warren
2012-12-18  2:51                                   ` Jason Gunthorpe
2012-12-18 17:03                                     ` Stephen Warren
2012-12-20 15:32                                       ` Thierry Reding
2012-12-21 13:38                                         ` Jay Agarwal
2012-12-21 14:03                                           ` Thierry Reding
2012-12-22 14:50                                         ` Thomas Petazzoni
2012-12-28 21:06                                           ` Thierry Reding
2012-12-28 21:16                                             ` Thomas Petazzoni
2012-12-28 23:49                                               ` Stephen Warren
2012-12-29  8:09                                                 ` Thomas Petazzoni
2012-12-31 16:40                                                   ` Stephen Warren
2012-12-29  9:33                                                 ` Thierry Reding
2012-12-31 16:44                                                   ` Stephen Warren
2013-01-02 20:09                                                   ` Jason Gunthorpe
2013-01-03 14:20                                                     ` Thierry Reding
2012-12-28 23:51                                         ` Stephen Warren
2012-12-18  7:32                                   ` Thierry Reding
2013-01-03 14:39 ` Thierry Reding
2013-01-03 15:00   ` Bjorn Helgaas
2013-01-03 15:11     ` Thierry Reding
2013-01-03 15:09   ` Thomas Petazzoni
2013-01-03 15:56   ` Arnd Bergmann
2013-01-03 16:01     ` Thierry Reding

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=20121211165050.GU14363@n2100.arm.linux.org.uk \
    --to=linux@arm.linux.org.uk \
    --cc=linux-arm-kernel@lists.infradead.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).