*** SUBJECT HERE ***

This is a repost of the patch set I sent on Feb 22nd.

Patch 3 is dependent on patch 1 and 2, which are unordered. The big patch was picked up from V2 but without its dependencies. It seems like the set can be accepted but was probably forgotten.

Other patches (for the sub-devices in this chip) are being worked on, but they all depend on CONFIG_STA2X11, so I'd like these to be merged if there are no serious problem (if there are, I can work to fix them).

thanks
/alessandro

Summary:

Patch 1: no functional effect (it uses an existing "#ifdef CONFIG_X86_64" in the 32-bit world, so it's not CONFIG_X86_64 but a new name)

Patch 2: no functional effect (it allows some inline functions to not be inline where needed, with a new config symbol).

Patch 3: is the good meat, but was already picked up so I think it's good as is.

History:

V4: rebased on next-20120309, no changes.

V3: rebased on next-20120221. Fixed patch 3 to match new DMA prototypes. Renamed patch 3 as Ingo and Jesse merged it. Added both of them to explicit Cc: list in the email set.

V2: rebased, minor and less-minor changes in patch 3/3.

Alessandro Rubini (3):
x86: introduce CONFIG_X86_DEV_DMA_OPS
x86: introduce CONFIG_X86_DMA_REMAP
x86/PCI: initial support for sta2x11 I/O hub

 arch/x86/Kconfig                   |   34 +++-
 arch/x86/include/asm/device.h      |    4 +-
 arch/x86/include/asm/dma-mapping.h |    9 +-
 arch/x86/pci/Makefile              |    2 +
 arch/x86/pci/sta2x11-fixup.c       |  367 ++++++++++++++++++++++++++++++++++++
 5 files changed, 409 insertions(+), 7 deletions(-)
 create mode 100644 arch/x86/pci/sta2x11-fixup.c

1.7.7.2

32-bit x86 systems may need their own DMA operations, so add a new config option, which is turned on for 64-bit systems. This patch has no functional effect but it paves the way for supporting the STA2x11 I/O Hub and possibly other chips.

---
 arch/x86/Kconfig                   |    5 +++++
 arch/x86/include/asm/device.h      |    4 ++--
 arch/x86/include/asm/dma-mapping.h |    2 +-
 3 files changed, 8 insertions(+), 3 deletions(-)

index 03298e4..c06a8a3 100644
@@ -12,6 +12,7 @@ config X86_32
 
 config X86_64
 	def_bool 64BIT
+	select X86_DEV_DMA_OPS
 
 ### Arch settings
 config X86

@@ -2248,6 +2249,10 @@ config HAVE_TEXT_POKE_SMP
 	bool
 	select STOP_MACHINE if SMP
 
+config X86_DEV_DMA_OPS
+	bool
+	depends on X86_64
+
 source "net/Kconfig"
 
 source "drivers/Kconfig"

index 63a2a03..93e1c55 100644
@@ -5,8 +5,8 @@ struct dev_archdata {
 #ifdef CONFIG_ACPI
 	void	*acpi_handle;
 #endif
-#ifdef CONFIG_X86_64
-struct dma_map_ops *dma_ops;
+#ifdef CONFIG_X86_DEV_DMA_OPS
+	struct dma_map_ops *dma_ops;
 #endif
 #if defined(CONFIG_INTEL_IOMMU) || defined(CONFIG_AMD_IOMMU)
 	void *iommu; /* hook for IOMMU specific extension */

index 4b4331d..09aa473 100644
@@ -30,7 +30,7 @@ extern struct dma_map_ops *dma_ops;
 
 static inline struct dma_map_ops *get_dma_ops(struct device *dev)
 {
-#ifdef CONFIG_X86_32
+#ifndef CONFIG_X86_DEV_DMA_OPS
 	return dma_ops;
 #else
 	if (unlikely(!dev) || !dev->archdata.dma_ops)

1.7.7.2

The default functions phys_to_dma, dma_to_phys implement identity mapping as fast inline functions. Some systems, however, may need a custom function to implement its own mapping between CPU addresses and device addresses. This new configuration option allows the functions to be external when needed (such as for the ConneXt device)

---
 arch/x86/Kconfig                   |    3 +++
 arch/x86/include/asm/dma-mapping.h |    7 +++++++
 2 files changed, 10 insertions(+), 0 deletions(-)

index c06a8a3..9f6255b 100644
@@ -2253,6 +2253,9 @@ config X86_DEV_DMA_OPS
 	bool
 	depends on X86_64
 
+config X86_DMA_REMAP
+	bool
+
 source "net/Kconfig"
 
 source "drivers/Kconfig"

index 09aa473..61c0bd2 100644
@@ -62,6 +62,12 @@ extern void *dma_generic_alloc_coherent(struct device *dev, size_t size,
 					dma_addr_t *dma_addr, gfp_t flag,
 					struct dma_attrs *attrs);
 
+#ifdef CONFIG_X86_DMA_REMAP /* Platform code defines bridge-specific code */
+extern bool dma_capable(struct device *dev, dma_addr_t addr, size_t size);
+extern dma_addr_t phys_to_dma(struct device *dev, phys_addr_t paddr);
+extern phys_addr_t dma_to_phys(struct device *dev, dma_addr_t daddr);
+#else
+
 static inline bool dma_capable(struct device *dev, dma_addr_t addr, size_t size)
 {
 	if (!dev->dma_mask)

@@ -79,6 +85,7 @@ static inline phys_addr_t dma_to_phys(struct device *dev, dma_addr_t daddr)
 {
 	return daddr;
 }
+#endif /* CONFIG_X86_DMA_REMAP */
 
 static inline void
 dma_cache_sync(struct device *dev, void *vaddr, size_t size,

1.7.7.2

The "ConneXt" sta2x11 I/O Hub is a bridge from PCIe to AMBA, and is used as main chipset in some Atom boards. The set of peripherals it exports live in an AMBA bus internal to the chip, so a custom remapping of addresses is needed. This is implemented by fixup calls for the PCI deivices, based on CONFIG_X86_DEV_DMA_OPS and CONFIG_X86_DMA_REMAP .

---
 arch/x86/Kconfig             |   28 +++-
 arch/x86/pci/Makefile        |    2 +
 arch/x86/pci/sta2x11-fixup.c |  367 ++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 392 insertions(+), 5 deletions(-)
 create mode 100644 arch/x86/pci/sta2x11-fixup.c

index 9f6255b..ab1f411 100644
@@ -331,6 +331,7 @@ config X86_EXTENDED_PLATFORM
 		NUMAQ (IBM/Sequent)
 		RDC R-321x SoC
 		SGI 320/540 (Visual Workstation)
+		STA2X11-based (e.g. Northville)
 		Summit/EXA (IBM x440)
 		Unisys ES7000 IA32 series
 		Moorestown MID devices

@@ -463,10 +464,10 @@ config X86_32_NON_STANDARD
 	depends on X86_32 && SMP
 	depends on X86_EXTENDED_PLATFORM
 	---help---
-	  This option compiles in the NUMAQ, Summit, bigsmp, ES7000, default
-	  subarchitectures.  It is intended for a generic binary kernel.
-	  if you select them all, kernel will probe it one by one. and will
-	  fallback to default.
+	  This option compiles in the NUMAQ, Summit, bigsmp, ES7000, 
+	  STA2X11, default subarchitectures.  It is intended for a generic
+	  binary kernel. If you select them all, kernel will probe it
+	  one by one and will fallback to default.
 
 # Alphabetically sorted list of Non standard 32 bit platforms
 

@@ -506,6 +507,22 @@ config X86_VISWS
 	  A kernel compiled for the Visual Workstation will run on general
 	  PCs as well. See <file:Documentation/sgi-visws.txt> for details.
 
+config STA2X11
+	bool "STA2X11 Companion Chip Support"
+	depends on X86_32_NON_STANDARD && PCI
+	select X86_DEV_DMA_OPS
+	select X86_DMA_REMAP
+	select SWIOTLB
+	select MFD_STA2X11
+	select ARCH_REQUIRE_GPIOLIB
+	default n
+	---help---
+	  This adds support for boards based on the STA2X11 IO-Hub,
+	  a.k.a. "ConneXt". The chip is used in place of the standard
+	  PC chipset, so all "standard" peripherals are missing. If this
+	  option is selected the kernel will still be able to boot on
+	  standard PC machines.
+
 config X86_SUMMIT
 	bool "Summit/EXA (IBM x440)"
 	depends on X86_32_NON_STANDARD

@@ -2251,10 +2268,11 @@ config HAVE_TEXT_POKE_SMP
 
 config X86_DEV_DMA_OPS
 	bool
-	depends on X86_64
+	depends on X86_64 || STA2X11
 
 config X86_DMA_REMAP
 	bool
+	depends on STA2X11
 
 source "net/Kconfig"
 

index e76e18c..3af5a1e 100644
@@ -11,6 +11,8 @@ obj-$(CONFIG_X86_INTEL_CE)      += ce4100.o
 obj-$(CONFIG_ACPI)		+= acpi.o
 obj-y				+= legacy.o irq.o
 
+obj-$(CONFIG_STA2X11)           += sta2x11-fixup.o
+
 obj-$(CONFIG_X86_VISWS)		+= visws.o
 
 obj-$(CONFIG_X86_NUMAQ)		+= numaq_32.o

1.7.7.2

Ok, the whole series looks pretty clean, modulo a few mostly cosmetic details in the driver itself.

Andrew, you are typically merging dma-mapping.h patches, would you like to do these, or can we do it in tip:x86/platform?

It would also be nice if the gents on Cc: would voice objections or approval, if any.

Thanks,

Ingo

Alessandro Rubini:

Ingo Molnar:

Any news? My next version (V5) I sent on Apr 4th is still working with today's next, but I got no ack nor nack.

thanks
/alessandro

I looked over it, and at least this bit seems okay to me.

Andrew, I guess the question is still open?

I have to express some concern about where this device may be going, though.

-hpa

Peter Anvin:

Thanks.

Well, this CONFIG_X86_DEV_DMA_OPS in particular should not be concerning, as it's just separating out an x86-64 ifdef so it can be used and activated by 32-bit systems as well.

As for "this device", it's an I/O Hub that can be used as main chipset on Atom computers, mainly aimed at the automotive sector. It is a typical ARM SoC with the usual set of internal peripherals, mounted on a bridge between PCIe and AMBA, so the PCIe host can access the SoC peripherals -- and SoC peripherals can DMA to PCIe memory. Actually, some SoC devices work well using the existing amba drivers, with minimal changes that I plan to clean up and submit soon.

The strange DMA requirements here depend on the size limits of the respective windows: SoC devices can only access a 512MB window of the host memory, so we need to take care of this with special options.

The current approach is using swiotlb and it works pretty well, though with a limit of 4MB of swiotlb area. I've been considering use of the DMA zone to this aim: internally I have some half-working thing that resuses the ISA DMA zone for our own aims, raising the DMA limit to 512MB.

Do you think the approach may make sense? I use this basic thing in Kconfig, to rely on GFP_DMA for the rest:

config MAX_DMA_PADDR

          int
          default 536870912 if MAX_DMA_PADDR_512M
          default 16777216

config MAX_DMA_PADDR_512M
bool

(actually, we'd benefit from being able to use hex in defaults)

Is this worth exploring, to possibly submit a patch in this direction?

thanks
/alessandro

Not as a compile-time patch.

-hpa

Why not? CONFIG_ISA is a compile-time choice. I thought that if you compile for non-ISA systems you may reuse the zone mechanism with a different split.

But if not a compile-time thing, would you accept it at run time? I feel it's not a beautiful approach, because it must clearly be masked by #ifndef CONFIG_ISA or such. Worse, you must know the zone split at the beginning, before you scan the PCI bus and find your devices.

thanks
/alessandro

Compile-time is unacceptable, because it breaks the "one kernel image" policy we have on x86. So it should be done at runtime.

-hpa

Agreed. CONFIG_ISA is an old mistake - we try not to repeat old mistakes.

Thanks,

Ingo