[PATCH V4 0/3] *** SUBJECT HERE ***

[PATCH V4 0/3] *** SUBJECT HERE ***

[Alessandro Rubini]

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

[PATCH V4 1/3] x86: introduce CONFIG_X86_DEV_DMA_OPS

[Alessandro Rubini]

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.

Signed-off-by: Alessandro Rubini <rubini@gnudd.com>
Acked-by: Giancarlo Asnaghi <giancarlo.asnaghi@st.com>
Cc: Alan Cox <alan@linux.intel.com>
---
 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(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 03298e4..c06a8a3 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -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"
diff --git a/arch/x86/include/asm/device.h b/arch/x86/include/asm/device.h
index 63a2a03..93e1c55 100644
--- a/arch/x86/include/asm/device.h
+++ b/arch/x86/include/asm/device.h
@@ -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 */
diff --git a/arch/x86/include/asm/dma-mapping.h b/arch/x86/include/asm/dma-mapping.h
index 4b4331d..09aa473 100644
--- a/arch/x86/include/asm/dma-mapping.h
+++ b/arch/x86/include/asm/dma-mapping.h
@@ -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

[PATCH V4 2/3] x86: introduce CONFIG_X86_DMA_REMAP

[Alessandro Rubini]

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)

Signed-off-by: Alessandro Rubini <rubini@gnudd.com>
Acked-by: Giancarlo Asnaghi <giancarlo.asnaghi@st.com>
Cc: Alan Cox <alan@linux.intel.com>
---
 arch/x86/Kconfig                   |    3 +++
 arch/x86/include/asm/dma-mapping.h |    7 +++++++
 2 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index c06a8a3..9f6255b 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -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"
diff --git a/arch/x86/include/asm/dma-mapping.h b/arch/x86/include/asm/dma-mapping.h
index 09aa473..61c0bd2 100644
--- a/arch/x86/include/asm/dma-mapping.h
+++ b/arch/x86/include/asm/dma-mapping.h
@@ -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

[PATCH V4 3/3] x86/PCI: initial support for sta2x11 I/O hub

[Alessandro Rubini]

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 .

Signed-off-by: Alessandro Rubini <rubini@gnudd.com>
Acked-by: Giancarlo Asnaghi <giancarlo.asnaghi@st.com>
Cc: Alan Cox <alan@linux.intel.com>
---
 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

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 9f6255b..ab1f411 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -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"
 
diff --git a/arch/x86/pci/Makefile b/arch/x86/pci/Makefile
index e76e18c..3af5a1e 100644
--- a/arch/x86/pci/Makefile
+++ b/arch/x86/pci/Makefile
@@ -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
diff --git a/arch/x86/pci/sta2x11-fixup.c b/arch/x86/pci/sta2x11-fixup.c
new file mode 100644
index 0000000..5aaa434
--- /dev/null
+++ b/arch/x86/pci/sta2x11-fixup.c
@@ -0,0 +1,367 @@
+/*
+ * arch/x86/pci/sta2x11-fixup.c
+ * glue code for lib/swiotlb.c and DMA translation between STA2x11
+ * AMBA memory mapping and the X86 memory mapping
+ *
+ * ST Microelectronics ConneXt (STA2X11/STA2X10)
+ *
+ * Copyright (c) 2010-2011 Wind River Systems, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
+ * See the GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ *
+ */
+
+#include <linux/pci.h>
+#include <linux/pci_ids.h>
+#include <linux/export.h>
+#include <linux/list.h>
+
+#define STA2X11_SWIOTLB_SIZE (4*1024*1024)
+extern int swiotlb_late_init_with_default_size(size_t default_size);
+
+/*
+ * We build a list of bus numbers that are under the ConneXt. The
+ * main bridge hosts 4 busses, which are the 4 endpoints, in order.
+ */
+#define STA2X11_NR_EP		4	/* 0..3 included */
+#define STA2X11_NR_FUNCS	8	/* 0..7 included */
+#define STA2X11_AMBA_SIZE	(512 << 20)
+
+struct sta2x11_ahb_regs { /* saved during suspend */
+	u32 base, pexlbase, pexhbase, crw;
+};
+
+struct sta2x11_mapping {
+	u32 amba_base;
+	int is_suspended;
+	struct sta2x11_ahb_regs regs[STA2X11_NR_FUNCS];
+};
+
+struct sta2x11_instance {
+	struct list_head list;
+	int bus0;
+	struct sta2x11_mapping map[STA2X11_NR_EP];
+};
+
+static LIST_HEAD(sta2x11_instance_list);
+
+/* At probe time, record new instances of this bridge (likely one only) */
+static void sta2x11_new_instance(struct pci_dev *pdev)
+{
+	struct sta2x11_instance *instance;
+
+	instance = kzalloc(sizeof(*instance), GFP_ATOMIC);
+	if (!instance)
+		return;
+	/* This has a subordinate bridge, with 4 more-subordinate ones */
+	instance->bus0 = pdev->subordinate->number + 1;
+
+	if (list_empty(&sta2x11_instance_list)) {
+		int size = STA2X11_SWIOTLB_SIZE;
+		/* First instance: register your own swiotlb area */
+		dev_info(&pdev->dev, "Using SWIOTLB (size %i)\n", size);
+		if (swiotlb_late_init_with_default_size(size))
+			dev_emerg(&pdev->dev, "init swiotlb failed\n");
+	}
+	list_add(&instance->list, &sta2x11_instance_list);
+}
+DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_STMICRO, 0xcc17, sta2x11_new_instance);
+
+/*
+ * Utility functions used in this file from below
+ */
+static struct sta2x11_instance *sta2x11_pdev_to_instance(struct pci_dev *pdev)
+{
+	struct sta2x11_instance *instance;
+	int ep;
+
+	list_for_each_entry(instance, &sta2x11_instance_list, list) {
+		ep = pdev->bus->number - instance->bus0;
+		if (ep >= 0 && ep < STA2X11_NR_EP)
+			return instance;
+	}
+	return NULL;
+}
+
+static int sta2x11_pdev_to_ep(struct pci_dev *pdev)
+{
+	struct sta2x11_instance *instance;
+
+	instance = sta2x11_pdev_to_instance(pdev);
+	if (!instance)
+		return -1;
+
+	return pdev->bus->number - instance->bus0;
+}
+
+static struct sta2x11_mapping *sta2x11_pdev_to_mapping(struct pci_dev *pdev)
+{
+	struct sta2x11_instance *instance;
+	int ep;
+
+	instance = sta2x11_pdev_to_instance(pdev);
+	if (!instance)
+		return NULL;
+	ep = sta2x11_pdev_to_ep(pdev);
+	return instance->map + ep;
+}
+
+/* This is exported, as some devices need to access the MFD registers */
+struct sta2x11_instance *sta2x11_get_instance(struct pci_dev *pdev)
+{
+	return sta2x11_pdev_to_instance(pdev);
+}
+EXPORT_SYMBOL(sta2x11_get_instance);
+
+
+/**
+ * p2a - Translate physical address to STA2x11 AMBA address,
+ *       used for DMA transfers to STA2x11
+ * @p: Physical address
+ * @pdev: PCI device (must be hosted within the connext)
+ */
+static dma_addr_t p2a(dma_addr_t p, struct pci_dev *pdev)
+{
+	struct sta2x11_mapping *map;
+	dma_addr_t a;
+
+	map = sta2x11_pdev_to_mapping(pdev);
+	a = p + map->amba_base;
+	return a;
+}
+
+/**
+ * a2p - Translate STA2x11 AMBA address to physical address
+ *       used for DMA transfers from STA2x11
+ * @a: STA2x11 AMBA address
+ * @pdev: PCI device (must be hosted within the connext)
+ */
+static dma_addr_t a2p(dma_addr_t a, struct pci_dev *pdev)
+{
+	struct sta2x11_mapping *map;
+	dma_addr_t p;
+
+	map = sta2x11_pdev_to_mapping(pdev);
+	p = a - map->amba_base;
+	return p;
+}
+
+/**
+ * sta2x11_swiotlb_alloc_coherent - Allocate swiotlb bounce buffers
+ *     returns virtual address. This is the only "special" function here.
+ * @dev: PCI device
+ * @size: Size of the buffer
+ * @dma_handle: DMA address
+ * @flags: memory flags
+ */
+static void *sta2x11_swiotlb_alloc_coherent(struct device *dev,
+					    size_t size,
+					    dma_addr_t *dma_handle,
+					    gfp_t flags,
+					    struct dma_attrs *attrs)
+{
+	void *vaddr;
+
+	vaddr = dma_generic_alloc_coherent(dev, size, dma_handle, flags, attrs);
+	if (!vaddr)
+		vaddr = swiotlb_alloc_coherent(dev, size, dma_handle, flags,
+					       attrs);
+	*dma_handle = p2a(*dma_handle, to_pci_dev(dev));
+	return vaddr;
+}
+
+/* We have our own dma_ops: the same as swiotlb but from alloc (above) */
+static struct dma_map_ops sta2x11_dma_ops = {
+	.alloc = sta2x11_swiotlb_alloc_coherent,
+	.free = swiotlb_free_coherent,
+	.map_page = swiotlb_map_page,
+	.unmap_page = swiotlb_unmap_page,
+	.map_sg = swiotlb_map_sg_attrs,
+	.unmap_sg = swiotlb_unmap_sg_attrs,
+	.sync_single_for_cpu = swiotlb_sync_single_for_cpu,
+	.sync_single_for_device = swiotlb_sync_single_for_device,
+	.sync_sg_for_cpu = swiotlb_sync_sg_for_cpu,
+	.sync_sg_for_device = swiotlb_sync_sg_for_device,
+	.mapping_error = swiotlb_dma_mapping_error,
+	.dma_supported = NULL, /* FIXME: we should use this instead! */
+};
+
+/* At setup time, we use our own ops if the device is a ConneXt one */
+static void sta2x11_setup_pdev(struct pci_dev *pdev)
+{
+	struct sta2x11_instance *instance = sta2x11_pdev_to_instance(pdev);
+
+	if (!instance) /* either a sta2x11 bridge or another ST device */
+		return;
+	pci_set_consistent_dma_mask(pdev, STA2X11_AMBA_SIZE - 1);
+	pci_set_dma_mask(pdev, STA2X11_AMBA_SIZE - 1);
+	pdev->dev.archdata.dma_ops = &sta2x11_dma_ops;
+
+	/* We must enable all devices as master, for audio DMA to work */
+	pci_set_master(pdev);
+}
+DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_STMICRO, PCI_ANY_ID, sta2x11_setup_pdev);
+
+/*
+ * The following three functions are exported (used in swiotlb: FIXME)
+ */
+/**
+ * dma_capable - Check if device can manage DMA transfers (FIXME: kill it)
+ * @dev: device for a PCI device
+ * @addr: DMA address
+ * @size: DMA size
+ */
+bool dma_capable(struct device *dev, dma_addr_t addr, size_t size)
+{
+	struct sta2x11_mapping *map;
+
+	if (dev->archdata.dma_ops != &sta2x11_dma_ops) {
+		if (!dev->dma_mask)
+			return false;
+		return addr + size - 1 <= *dev->dma_mask;
+	}
+
+	map = sta2x11_pdev_to_mapping(to_pci_dev(dev));
+
+	if (!map || (addr < map->amba_base))
+		return false;
+	if (addr + size >= map->amba_base + STA2X11_AMBA_SIZE) {
+		return false;
+	}
+
+	return true;
+}
+
+/**
+ * phys_to_dma - Return the DMA AMBA address used for this STA2x11 device
+ * @dev: device for a PCI device
+ * @paddr: Physical address
+ */
+dma_addr_t phys_to_dma(struct device *dev, phys_addr_t paddr)
+{
+	if (dev->archdata.dma_ops != &sta2x11_dma_ops)
+		return paddr;
+	return p2a(paddr, to_pci_dev(dev));
+}
+
+/**
+ * dma_to_phys - Return the physical address used for this STA2x11 DMA address
+ * @dev: device for a PCI device
+ * @daddr: STA2x11 AMBA DMA address
+ */
+phys_addr_t dma_to_phys(struct device *dev, dma_addr_t daddr)
+{
+	if (dev->archdata.dma_ops != &sta2x11_dma_ops)
+		return daddr;
+	return a2p(daddr, to_pci_dev(dev));
+}
+
+
+/*
+ * At boot we must set up the mappings for the pcie-to-amba bridge.
+ * It involves device access, and the same happens at suspend/resume time
+ */
+
+#define AHB_MAPB		0xCA4
+#define AHB_CRW(i)		(AHB_MAPB + 0  + (i) * 0x10)
+#define AHB_CRW_SZMASK			0xfffffc00UL
+#define AHB_CRW_ENABLE			(1 << 0)
+#define AHB_CRW_WTYPE_MEM		(2 << 1)
+#define AHB_CRW_ROE			(1UL << 3)	/* Relax Order Ena */
+#define AHB_CRW_NSE			(1UL << 4)	/* No Snoop Enable */
+#define AHB_BASE(i)		(AHB_MAPB + 4  + (i) * 0x10)
+#define AHB_PEXLBASE(i)		(AHB_MAPB + 8  + (i) * 0x10)
+#define AHB_PEXHBASE(i)		(AHB_MAPB + 12 + (i) * 0x10)
+
+/* At probe time, enable mapping for each endpoint, using the pdev */
+static void sta2x11_map_ep(struct pci_dev *pdev)
+{
+	struct sta2x11_mapping *map = sta2x11_pdev_to_mapping(pdev);
+	int i;
+
+	if (!map)
+		return;
+	pci_read_config_dword(pdev, AHB_BASE(0), &map->amba_base);
+
+	/* Configure AHB mapping */
+	pci_write_config_dword(pdev, AHB_PEXLBASE(0), 0);
+	pci_write_config_dword(pdev, AHB_PEXHBASE(0), 0);
+	pci_write_config_dword(pdev, AHB_CRW(0), STA2X11_AMBA_SIZE |
+			       AHB_CRW_WTYPE_MEM | AHB_CRW_ENABLE);
+
+	/* Disable all the other windows */
+	for (i = 1; i < STA2X11_NR_FUNCS; i++)
+		pci_write_config_dword(pdev, AHB_CRW(i), 0);
+
+	dev_info(&pdev->dev,
+		 "sta2x11: Map EP %i: AMBA address %#8x-%#8x\n",
+		 sta2x11_pdev_to_ep(pdev),  map->amba_base,
+		 map->amba_base + STA2X11_AMBA_SIZE - 1);
+}
+DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_STMICRO, PCI_ANY_ID, sta2x11_map_ep);
+
+#ifdef CONFIG_PM /* Some register values must be saved and restored */
+
+static void suspend_mapping(struct pci_dev *pdev)
+{
+	struct sta2x11_mapping *map = sta2x11_pdev_to_mapping(pdev);
+	int i;
+
+	if (!map)
+		return;
+
+	if (map->is_suspended)
+		return;
+	map->is_suspended = 1;
+
+	/* Save all window configs */
+	for (i = 0; i < STA2X11_NR_FUNCS; i++) {
+		struct sta2x11_ahb_regs *regs = map->regs + i;
+
+		pci_read_config_dword(pdev, AHB_BASE(i), &regs->base);
+		pci_read_config_dword(pdev, AHB_PEXLBASE(i), &regs->pexlbase);
+		pci_read_config_dword(pdev, AHB_PEXHBASE(i), &regs->pexhbase);
+		pci_read_config_dword(pdev, AHB_CRW(i), &regs->crw);
+	}
+}
+DECLARE_PCI_FIXUP_SUSPEND(PCI_VENDOR_ID_STMICRO, PCI_ANY_ID, suspend_mapping);
+
+static void resume_mapping(struct pci_dev *pdev)
+{
+	struct sta2x11_mapping *map = sta2x11_pdev_to_mapping(pdev);
+	int i;
+
+	if (!map)
+		return;
+
+
+	if (!map->is_suspended)
+		goto out;
+	map->is_suspended = 0;
+
+	/* Restore all window configs */
+	for (i = 0; i < STA2X11_NR_FUNCS; i++) {
+		struct sta2x11_ahb_regs *regs = map->regs + i;
+
+		pci_write_config_dword(pdev, AHB_BASE(i), regs->base);
+		pci_write_config_dword(pdev, AHB_PEXLBASE(i), regs->pexlbase);
+		pci_write_config_dword(pdev, AHB_PEXHBASE(i), regs->pexhbase);
+		pci_write_config_dword(pdev, AHB_CRW(i), regs->crw);
+	}
+out:
+	pci_set_master(pdev); /* Like at boot, enable master on all devices */
+}
+DECLARE_PCI_FIXUP_RESUME(PCI_VENDOR_ID_STMICRO, PCI_ANY_ID, resume_mapping);
+
+#endif /* CONFIG_PM */
-- 
1.7.7.2

Re: [PATCH V4 1/3] x86: introduce CONFIG_X86_DEV_DMA_OPS

[Ingo Molnar]

* Alessandro Rubini <rubini@gnudd.com> wrote:

> 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.
> 
> Signed-off-by: Alessandro Rubini <rubini@gnudd.com>
> Acked-by: Giancarlo Asnaghi <giancarlo.asnaghi@st.com>
> Cc: Alan Cox <alan@linux.intel.com>
> ---
>  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(-)

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

Re: [PATCH V4 1/3] x86: introduce CONFIG_X86_DEV_DMA_OPS

[Alessandro Rubini]

Alessandro Rubini:
>> 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.
>> 
>> Signed-off-by: Alessandro Rubini <rubini@gnudd.com>
>> Acked-by: Giancarlo Asnaghi <giancarlo.asnaghi@st.com>
>> Cc: Alan Cox <alan@linux.intel.com>
>> ---
>>  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(-)

Ingo Molnar:
> 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.

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

Re: [PATCH V4 1/3] x86: introduce CONFIG_X86_DEV_DMA_OPS

[H. Peter Anvin]

On 03/13/2012 11:56 PM, Ingo Molnar wrote:
> 
> * Alessandro Rubini <rubini@gnudd.com> wrote:
> 
>> 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.
>>
>> Signed-off-by: Alessandro Rubini <rubini@gnudd.com>
>> Acked-by: Giancarlo Asnaghi <giancarlo.asnaghi@st.com>
>> Cc: Alan Cox <alan@linux.intel.com>
>> ---
>>  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(-)
> 
> 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.
> 

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

Acked-by: H. Peter Anvin <hpa@zytor.com>

Andrew, I guess the question is still open?

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

	-hpa

Re: [PATCH V4 1/3] x86: introduce CONFIG_X86_DEV_DMA_OPS

[Alessandro Rubini]

Peter Anvin:
> I looked over it, and at least this bit seems okay to me.
> 
> Acked-by: H. Peter Anvin <hpa@zytor.com>

Thanks.

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

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

Re: [PATCH V4 1/3] x86: introduce CONFIG_X86_DEV_DMA_OPS

[H. Peter Anvin]

On 04/12/2012 01:15 PM, Alessandro Rubini wrote:
> 
> 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?
> 

Not as a compile-time patch.

	-hpa

Re: [PATCH V4 1/3] x86: introduce CONFIG_X86_DEV_DMA_OPS

[Alessandro Rubini]

>>   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?
>> 
> 
> Not as a compile-time patch.

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

Re: [PATCH V4 1/3] x86: introduce CONFIG_X86_DEV_DMA_OPS

[H. Peter Anvin]

On 04/12/2012 01:32 PM, Alessandro Rubini wrote:
>>
>> Not as a compile-time patch.
> 
> 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.
> 

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

	-hpa

Re: [PATCH V4 1/3] x86: introduce CONFIG_X86_DEV_DMA_OPS

[Ingo Molnar]

* H. Peter Anvin <hpa@zytor.com> wrote:

> On 04/12/2012 01:32 PM, Alessandro Rubini wrote:
> >>
> >> Not as a compile-time patch.
> > 
> > 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.
> > 
> 
> Compile-time is unacceptable, because it breaks the "one 
> kernel image" policy we have on x86.  So it should be done at 
> runtime.

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

Thanks,

	Ingo