x86/platform: sta2x11: add platform code

This adds platform code for the STA2X11 (aka ConneXt) I/O Hub, including support for the Intel NorthVille evaluation board and the ST-Eval PCIe carrier.

The boards differ for the amount of peripherals actually wired out, GPIO configuration and some accessory pins. At this point, platform data for peripherals other tha GPIO is not instantiated because the drivers are not yet upstream.

The array of supported boards is built using a local ELF section to avoid ifdef; the section is folded in the .data section by a local linker script.

---
 arch/x86/Kconfig                       |   18 +++
 arch/x86/include/asm/sta2x11.h         |    6 +
 arch/x86/pci/sta2x11-fixup.c           |   14 ++
 arch/x86/platform/sta2x11/Makefile     |    5 +
 arch/x86/platform/sta2x11/boards.lds   |    9 ++
 arch/x86/platform/sta2x11/northville.c |  140 ++++++++++++++++++++
 arch/x86/platform/sta2x11/sta2x11.c    |  224 ++++++++++++++++++++++++++++++++
 arch/x86/platform/sta2x11/sta2x11.h    |   79 +++++++++++
 arch/x86/platform/sta2x11/steval.c     |  150 +++++++++++++++++++++
 9 files changed, 645 insertions(+), 0 deletions(-)
 create mode 100644 arch/x86/platform/sta2x11/Makefile
 create mode 100644 arch/x86/platform/sta2x11/boards.lds
 create mode 100644 arch/x86/platform/sta2x11/northville.c
 create mode 100644 arch/x86/platform/sta2x11/sta2x11.c
 create mode 100644 arch/x86/platform/sta2x11/sta2x11.h
 create mode 100644 arch/x86/platform/sta2x11/steval.c

index 4732997..23548ca 100644
@@ -507,6 +507,24 @@ config STA2X11
 	  option is selected the kernel will still be able to boot on
 	  standard PC machines.
 
+menu "STA2X11 boards"
+	depends on STA2X11
+
+config STA2X11_NORTHVILLE
+	bool "Support for Intel Northville board"
+	---help---
+	  Compile platform data for the Intel NorthVille board.
+	  If present, this board is selected by default at boot.
+
+config STA2X11_STEVAL
+	bool "Support for ST Evaluation board"
+	---help---
+	  Compile platform data for the PCIe carrier called "ST-Eval".
+	  Support for the boards can be selected using the command line
+	  option "sta2x11.board_name=steval" .
+
+endmenu
+
 config X86_SUMMIT
 	bool "Summit/EXA (IBM x440)"
 	depends on X86_32_NON_STANDARD

index e9d32df..6b6e5c1 100644
@@ -9,4 +9,10 @@
 /* This needs to be called from the MFD to configure its sub-devices */
 struct sta2x11_instance *sta2x11_get_instance(struct pci_dev *pdev);
 
+/*
+ * This function is called at PCI enable time to obtain platform/board
+ * specific data and make sure that all dependencies are met.
+ */
+void *sta2x11_get_platform_data(struct pci_dev *pdev);
+
 #endif /* __ASM_STA2X11_H */

index 5aaa434..7a3d146 100644
@@ -26,6 +26,7 @@
 #include <linux/pci_ids.h>
 #include <linux/export.h>
 #include <linux/list.h>
+#include <asm/sta2x11.h>
 
 #define STA2X11_SWIOTLB_SIZE (4*1024*1024)
 extern int swiotlb_late_init_with_default_size(size_t default_size);

@@ -214,6 +215,19 @@ static void sta2x11_setup_pdev(struct pci_dev *pdev)
 DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_STMICRO, PCI_ANY_ID, sta2x11_setup_pdev);
 
 /*
+ * Set platform data for pci device, to use sta2x11-specifics in the drivers
+ */
+static void set_platform_data(struct pci_dev *pdev)
+{
+	void *data = sta2x11_get_platform_data(pdev);
+	if (data)
+		dev_info(&pdev->dev, "setting platform data for device "
+		       "%04x:%04x\n", pdev->vendor, pdev->device);
+	pdev->dev.platform_data = data;
+}
+DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_STMICRO, PCI_ANY_ID, set_platform_data);
+
+/*
  * The following three functions are exported (used in swiotlb: FIXME)
  */
 /**

new file mode 100644
index 0000000..c54aba4
@@ -0,0 +1,5 @@
+obj-$(CONFIG_STA2X11) +=  sta2x11.o
+obj-$(CONFIG_STA2X11_NORTHVILLE) +=  northville.o
+obj-$(CONFIG_STA2X11_STEVAL) +=  steval.o
+
+ldflags-y = -T $(srctree)/$(obj)/boards.lds

new file mode 100644
index 0000000..36e80a5
@@ -0,0 +1,9 @@
+SECTIONS
+{
+	.data : {
+		sta2x11_board_first = .;
+		*(.board);
+		sta2x11_board_last = .;
+	}
+}
+

1.7.7.2

There is absolutely NO WAY this kind of ARM-like sh*t is going into the x86 kernel.

-hpa

H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

Ok. Then, how do you suggest to provide platform data to the various drivers? It really depends on how the board is wired.

BTW: it's not uncommon for pci cards to differ in the same way, see drivers/media/video/bt8xx/bttv-cards.c for example. I can have all board configurations without config choices or whatever is acceptable. Just tell me how to proceed.

thanks
/alessandro

We have two mechanisms for parameterizing this kind of information: ACPI 5 (which can be considered the "native" method on x86) or flattened device tree (as already used by the CE4100 platform.) Keep in mind that an explicit goal for Linux/x86 is that the same kernel should boot on all platforms, and backsliding on that is not acceptable.

The best is for the firmware on your platforms to provide the ACPI or DTB information, as it should. If it doesn't, it gets nastier, but there is absolutely no way we are going into the ARM swamp of having different kernels for different boards.

-hpa

H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

Yes, it indeed does (the original code I received did not, but mine doesn't break stuff for other systems). What I posted uses a kernel command-line argument to tell what board it is: the sta2x11 is the computer's chipset in most cases, so it should know the wiring soon.

It doesn't. I'm currently developing using an add-on pci card running on a more conventional computer (and there you may object it is not even x86-specific, actually I'd love to see it sold as a separate card for industrial use).

In short, the whole thing is about passing different platform data according to which card it is (which includes the DMA configuration for uart ports, the card-detect pin for mmci etc). Most such drivers are already in the kernel and we are reusing them -- whereas original code I got rewrote them all from scratch. But for this we need to pass the platform data.

I'm pretty sure we don't have ACPI, and I'd avoid device tree if possible (especially thinking of add-on cards). If you think it makes more sense, I can offer the code to drivers/pci or other more generic places.

thanks
/alessandro

I am not going to accept into the kernel a bunch of board-specific files. PCI cards are different: they have PCI IDs, and they can be loaded, as modules, at runtime. Furthermore, they tend to be very limited in the amount of variation: a single chip (represented PCI ID) may be slightly differently wired on different boards (represented by subsystem ID), but the variation tends to be limited; in the rare case it is not, there is usually some form of discovery mechanism.

Those are the *only* kinds conditions under which that kind of things, in drivers, is acceptable. A list of mainboards and their wirings in C code? No way in hell.

What does "offer the code" mean here? Just put the same sh*t in a different place? No, no, no, no.

We have the device tree mechanism as an escape valve for the systems built without any sane consideration for the platform, and that is the last resort. I am generally not happy with that in the x86 space, even, because it means yet another failed platform, but it is still better than ad hoc hacks.

-hpa

H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

Ok.

Well, please check drivers/media/video/bt8xx: the "bttv-cards" file is the biggest one. But I see your point.

Here the thing is 4 uart, 4 mmc, 3 spi, 128 gpio, 2 dma engines, usb, sata, audio, .... So some differences in wiring are there between boards. And no, no autodiscovery unfortunately (but we can use the command line, so the driver knows who the installation is when it runs its probe methods).

Ok. Although you can think of them as plug in boards.

Yes, that was the suggestion :)

Unfortunately most vendors don't deal with autodetection, so the number of "failed platforms" will increase, I fear. Especially with increasing use of x86 in embedded contexts.

So, it seems I must go device-tree for the chipset-like mounting. And what about plug in boards? I may arrange a firmware-loader mechanism as an alternative, so the vendor of each board can provide the the platform data for all the sub devices. Actually, if firmware loader is acceptable, I'd try it first, to avoid changing the boot procedure; maybe I can save myself from the device tree.

thanks
/alessandro

If you're going to use a binary blob for the loader, use either ACPI 5 SSDT or device tree format. This is *not* something where (re)invention is encouraged.

-hpa

H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

ack.

Right, a device-tree blob could easily be passed an x86 has the infrastructure to use it already afaik.

It then becomes a matter of the bootloader to carry it over to the kernel a way or another. If the "vendor" boards don't do the right thing, you can always do like powerpc for those cases and "package" the device-tree blob in the zImage wrapper.

That way, distribution install tools etc.... can stick the right device-tree before doing whatever "flashing" of the image is needed for booting etc... and the main kernel image remains agnostic.

That or the ACPI way but I know nothing about it and thus naturally assume it's harder :-)

Cheers,
Ben.

Yes, that's the direction I'm aiming at. I hope it's possibly to also load a device sub-tree later (which is needed when the pci device is a plug-in board instead of the main chipset in the motherboard.

I'm studying this first, hoping to confirm my bad feeling about it and be happier when working with fdt. Also, I'd better remain portable, in case vendors will package the sta2x11 as a pci board -- the one I have is just the development system and it's not largely marketed.

Thanks
/alessandro

If it's an add-on card, can't you put a flash on it ? Then you can stick discovery/configuration information there or even a device-tree blob accessed via a BAR (or even the ROM BAR).

Cheers,
Ben.