[U-Boot] [PATCH 1/3] x86: gpio: Add GPIO driver for Intel ICH6 and later.

[U-Boot] [PATCH 1/3] x86: gpio: Add GPIO driver for Intel ICH6 and later.

[Simon Glass]

From: Bill Richardson <wfrichar@chromium.org>

Implement <asm-generic/gpio.h> functions for Intel ICH6 and later.
Only GPIOs 0-31 are handled by this code.

Signed-off-by: Bill Richardson <wfrichar@chromium.org>

Signed-off-by: Simon Glass <sjg@chromium.org>
---
 arch/x86/include/asm/gpio.h    |   27 +++++
 drivers/gpio/Makefile          |    1 +
 drivers/gpio/intel_ich6_gpio.c |  242 ++++++++++++++++++++++++++++++++++++++++
 include/pci.h                  |  123 ++++++++++++++++++++
 4 files changed, 393 insertions(+), 0 deletions(-)
 create mode 100644 arch/x86/include/asm/gpio.h
 create mode 100644 drivers/gpio/intel_ich6_gpio.c

diff --git a/arch/x86/include/asm/gpio.h b/arch/x86/include/asm/gpio.h
new file mode 100644
index 0000000..0a37a85
--- /dev/null
+++ b/arch/x86/include/asm/gpio.h
@@ -0,0 +1,27 @@
+/*
+ * Copyright (c) 2012, Google Inc. All rights reserved.
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * 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
+ */
+
+#ifndef _X86_GPIO_H_
+#define _X86_GPIO_H_
+
+#include <asm-generic/gpio.h>
+
+#endif /* _X86_GPIO_H_ */
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index d50ac3b..2d97b4f 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -26,6 +26,7 @@ include $(TOPDIR)/config.mk
 LIB 	:= $(obj)libgpio.o
 
 COBJS-$(CONFIG_AT91_GPIO)	+= at91_gpio.o
+COBJS-$(CONFIG_INTEL_ICH6_GPIO)	+= intel_ich6_gpio.o
 COBJS-$(CONFIG_KIRKWOOD_GPIO)	+= kw_gpio.o
 COBJS-$(CONFIG_MARVELL_GPIO)	+= mvgpio.o
 COBJS-$(CONFIG_MARVELL_MFP)	+= mvmfp.o
diff --git a/drivers/gpio/intel_ich6_gpio.c b/drivers/gpio/intel_ich6_gpio.c
new file mode 100644
index 0000000..1ccb641
--- /dev/null
+++ b/drivers/gpio/intel_ich6_gpio.c
@@ -0,0 +1,242 @@
+/*
+ * Copyright (c) 2012 The Chromium OS Authors.
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * 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
+ */
+
+/*
+ * This is a GPIO driver for Intel ICH6 and later. The x86 GPIOs are accessed
+ * through the PCI bus. Each PCI device has 256 bytes of configuration space,
+ * consisting of a standard header and a device-specific set of registers. PCI
+ * bus 0, device 31, function 0 gives us access to the chipset GPIOs (among
+ * other things). Within the PCI configuration space, the GPIOBASE register
+ * tells us where in the device's I/O region we can find more registers to
+ * actually access the GPIOs.
+ *
+ * PCI bus/device/function 0:1f:0  => PCI config registers
+ *   PCI config register "GPIOBASE"
+ *     PCI I/O space + [GPIOBASE]  => start of GPIO registers
+ *       GPIO registers => gpio pin function, direction, value
+ */
+
+#include <common.h>
+#include <pci.h>
+#include <asm/gpio.h>
+#include <asm/io.h>
+
+/* Where in config space is the register that points to the GPIO registers? */
+#define PCI_CFG_GPIOBASE 0x48
+
+/*
+ * There are often more than 32 GPIOs, depending on the ICH version.
+ * For now, we just support bank 0 because it's the same for all.
+ */
+#define GPIO_MAX 31
+
+/* Within the I/O space, where are the registers to control the GPIOs? */
+#define OFS_GPIO_USE_SEL 0x00
+#define OFS_GPIO_IO_SEL  0x04
+#define OFS_GP_LVL       0x0C
+
+static pci_dev_t dev;				/* handle for 0:1f:0 */
+static u32 gpiobase;				/* offset into I/O space */
+static int found_it_once;			/* valid GPIO device? */
+static int in_use[GPIO_MAX];			/* "lock" for access to pins */
+
+static int gpio_init(void)
+{
+	u8 tmpbyte;
+	u16 tmpword;
+	u32 tmplong;
+
+	/* Have we already done this? */
+	if (found_it_once)
+		return 0;
+
+	/* Where should it be? */
+	dev = PCI_BDF(0, 0x1f, 0);
+
+	/* Is the device present? */
+	pci_read_config_word(dev, PCI_VENDOR_ID, &tmpword);
+	if (tmpword != PCI_VENDOR_ID_INTEL) {
+		debug("%s: wrong VendorID\n", __func__);
+		return -1;
+	}
+	/*
+	 * We'd like to check the Device ID too, but pretty much any
+	 * value is either a) correct with slight differences, or b)
+	 * correct but undocumented. We'll have to check other things
+	 * instead...
+	 */
+
+	/* I/O should already be enabled (it's a RO bit). */
+	pci_read_config_word(dev, PCI_COMMAND, &tmpword);
+	if (!(tmpword & PCI_COMMAND_IO)) {
+		debug("%s: device IO not enabled\n", __func__);
+		return -1;
+	}
+
+	/* Header Type must be normal (bits 6-0 only; see spec.) */
+	pci_read_config_byte(dev, PCI_HEADER_TYPE, &tmpbyte);
+	if ((tmpbyte & 0x7f) != PCI_HEADER_TYPE_NORMAL) {
+		debug("%s: invalid Header type\n", __func__);
+		return -1;
+	}
+
+	/* Base Class must be a bridge device */
+	pci_read_config_byte(dev, PCI_CLASS_CODE, &tmpbyte);
+	if (tmpbyte != PCI_CLASS_CODE_BRIDGE) {
+		debug("%s: invalid class\n", __func__);
+		return -1;
+	}
+	/* Sub Class must be ISA */
+	pci_read_config_byte(dev, PCI_CLASS_SUB_CODE, &tmpbyte);
+	if (tmpbyte != PCI_CLASS_SUB_CODE_BRIDGE_ISA) {
+		debug("%s: invalid subclass\n", __func__);
+		return -1;
+	}
+
+	/* Programming Interface must be 0x00 (no others exist) */
+	pci_read_config_byte(dev, PCI_CLASS_PROG, &tmpbyte);
+	if (tmpbyte != 0x00) {
+		debug("%s: invalid interface type\n", __func__);
+		return -1;
+	}
+
+	/*
+	 * GPIOBASE moved to its current offset with ICH6, but prior to
+	 * that it was unused (or undocumented). Check that it looks
+	 * okay: not all ones or zeros, and mapped to I/O space (bit 0).
+	 */
+	pci_read_config_dword(dev, PCI_CFG_GPIOBASE, &tmplong);
+	if (tmplong == 0x00000000 || tmplong == 0xffffffff ||
+	    !(tmplong & 0x00000001)) {
+		debug("%s: unexpected GPIOBASE value\n", __func__);
+		return -1;
+	}
+
+	/*
+	 * Okay, I guess we're looking at the right device. The actual
+	 * GPIO registers are in the PCI device's I/O space, starting
+	 * at the offset that we just read. Bit 0 indicates that it's
+	 * an I/O address, not a memory address, so mask that off.
+	 */
+	gpiobase = tmplong & 0xfffffffe;
+
+	/* Finally. These are the droids we're looking for. */
+	found_it_once = 1;
+	return 0;
+}
+
+int gpio_request(unsigned gpio, const char *label /* UNUSED */)
+{
+	u32 tmplong;
+
+	/* Are we doing it wrong? */
+	if (gpio > GPIO_MAX || in_use[gpio]) {
+		debug("%s: gpio unavailable\n", __func__);
+		return -1;
+	}
+
+	/* Is the hardware ready? */
+	if (gpio_init()) {
+		debug("%s: gpio_init failed\n", __func__);
+		return -1;
+	}
+
+	/*
+	 * Make sure that the GPIO pin we want isn't already in use for some
+	 * built-in hardware function. We have to check this for every
+	 * requested pin.
+	 */
+	tmplong = inl(gpiobase + OFS_GPIO_USE_SEL);
+	if (!(tmplong & (1UL << gpio))) {
+		debug("%s: reserved for internal use\n", __func__);
+		return -1;
+	}
+
+	in_use[gpio] = 1;
+	return 0;
+}
+
+int gpio_free(unsigned gpio)
+{
+	if (gpio > GPIO_MAX || !in_use[gpio]) {
+		debug("%s: gpio unavailable\n", __func__);
+		return -1;
+	}
+	in_use[gpio] = 0;
+	return 0;
+}
+
+int gpio_direction_input(unsigned gpio)
+{
+	u32 tmplong;
+
+	if (gpio > GPIO_MAX || !in_use[gpio]) {
+		debug("%s: gpio unavailable\n", __func__);
+		return -1;
+	}
+	tmplong = inl(gpiobase + OFS_GPIO_IO_SEL);
+	tmplong |= (1UL << gpio);
+	outl(gpiobase + OFS_GPIO_IO_SEL, tmplong);
+	return 0;
+}
+
+int gpio_direction_output(unsigned gpio, int value)
+{
+	u32 tmplong;
+
+	if (gpio > GPIO_MAX || !in_use[gpio]) {
+		debug("%s: gpio unavailable\n", __func__);
+		return -1;
+	}
+	tmplong = inl(gpiobase + OFS_GPIO_IO_SEL);
+	tmplong &= ~(1UL << gpio);
+	outl(gpiobase + OFS_GPIO_IO_SEL, tmplong);
+	return 0;
+}
+
+int gpio_get_value(unsigned gpio)
+{
+	u32 tmplong;
+
+	if (gpio > GPIO_MAX || !in_use[gpio]) {
+		debug("%s: gpio unavailable\n", __func__);
+		return -1;
+	}
+	tmplong = inl(gpiobase + OFS_GP_LVL);
+	return (tmplong & (1UL << gpio)) ? 1 : 0;
+}
+
+int gpio_set_value(unsigned gpio, int value)
+{
+	u32 tmplong;
+
+	if (gpio > GPIO_MAX || !in_use[gpio]) {
+		debug("%s: gpio unavailable\n", __func__);
+		return -1;
+	}
+	tmplong = inl(gpiobase + OFS_GP_LVL);
+	if (value)
+		tmplong |= (1UL << gpio);
+	else
+		tmplong &= ~(1UL << gpio);
+	outl(gpiobase + OFS_GP_LVL, tmplong);
+	return 0;
+}
diff --git a/include/pci.h b/include/pci.h
index eba122f..15f583f 100644
--- a/include/pci.h
+++ b/include/pci.h
@@ -67,7 +67,130 @@
 #define PCI_CLASS_PROG		0x09	/* Reg. Level Programming Interface */
 #define PCI_CLASS_DEVICE	0x0a	/* Device class */
 #define PCI_CLASS_CODE		0x0b	/* Device class code */
+#define  PCI_CLASS_CODE_TOO_OLD	0x00
+#define  PCI_CLASS_CODE_STORAGE 0x01
+#define  PCI_CLASS_CODE_NETWORK 0x02
+#define  PCI_CLASS_CODE_DISPLAY	0x03
+#define  PCI_CLASS_CODE_MULTIMEDIA 0x04
+#define  PCI_CLASS_CODE_MEMORY	0x05
+#define  PCI_CLASS_CODE_BRIDGE	0x06
+#define  PCI_CLASS_CODE_COMM	0x07
+#define  PCI_CLASS_CODE_PERIPHERAL 0x08
+#define  PCI_CLASS_CODE_INPUT	0x09
+#define  PCI_CLASS_CODE_DOCKING	0x0A
+#define  PCI_CLASS_CODE_PROCESSOR 0x0B
+#define  PCI_CLASS_CODE_SERIAL	0x0C
+#define  PCI_CLASS_CODE_WIRELESS 0x0D
+#define  PCI_CLASS_CODE_I2O	0x0E
+#define  PCI_CLASS_CODE_SATELLITE 0x0F
+#define  PCI_CLASS_CODE_CRYPTO	0x10
+#define  PCI_CLASS_CODE_DATA	0x11
+/* Base Class 0x12 - 0xFE is reserved */
+#define  PCI_CLASS_CODE_OTHER	0xFF
+
 #define PCI_CLASS_SUB_CODE	0x0a	/* Device sub-class code */
+#define  PCI_CLASS_SUB_CODE_TOO_OLD_NOTVGA	0x00
+#define  PCI_CLASS_SUB_CODE_TOO_OLD_VGA		0x01
+#define  PCI_CLASS_SUB_CODE_STORAGE_SCSI	0x00
+#define  PCI_CLASS_SUB_CODE_STORAGE_IDE		0x01
+#define  PCI_CLASS_SUB_CODE_STORAGE_FLOPPY	0x02
+#define  PCI_CLASS_SUB_CODE_STORAGE_IPIBUS	0x03
+#define  PCI_CLASS_SUB_CODE_STORAGE_RAID	0x04
+#define  PCI_CLASS_SUB_CODE_STORAGE_ATA		0x05
+#define  PCI_CLASS_SUB_CODE_STORAGE_SATA	0x06
+#define  PCI_CLASS_SUB_CODE_STORAGE_SAS		0x07
+#define  PCI_CLASS_SUB_CODE_STORAGE_OTHER	0x80
+#define  PCI_CLASS_SUB_CODE_NETWORK_ETHERNET	0x00
+#define  PCI_CLASS_SUB_CODE_NETWORK_TOKENRING	0x01
+#define  PCI_CLASS_SUB_CODE_NETWORK_FDDI	0x02
+#define  PCI_CLASS_SUB_CODE_NETWORK_ATM		0x03
+#define  PCI_CLASS_SUB_CODE_NETWORK_ISDN	0x04
+#define  PCI_CLASS_SUB_CODE_NETWORK_WORLDFIP	0x05
+#define  PCI_CLASS_SUB_CODE_NETWORK_PICMG	0x06
+#define  PCI_CLASS_SUB_CODE_NETWORK_OTHER	0x80
+#define  PCI_CLASS_SUB_CODE_DISPLAY_VGA		0x00
+#define  PCI_CLASS_SUB_CODE_DISPLAY_XGA		0x01
+#define  PCI_CLASS_SUB_CODE_DISPLAY_3D		0x02
+#define  PCI_CLASS_SUB_CODE_DISPLAY_OTHER	0x80
+#define  PCI_CLASS_SUB_CODE_MULTIMEDIA_VIDEO	0x00
+#define  PCI_CLASS_SUB_CODE_MULTIMEDIA_AUDIO	0x01
+#define  PCI_CLASS_SUB_CODE_MULTIMEDIA_PHONE	0x02
+#define  PCI_CLASS_SUB_CODE_MULTIMEDIA_OTHER	0x80
+#define  PCI_CLASS_SUB_CODE_MEMORY_RAM		0x00
+#define  PCI_CLASS_SUB_CODE_MEMORY_FLASH	0x01
+#define  PCI_CLASS_SUB_CODE_MEMORY_OTHER	0x80
+#define  PCI_CLASS_SUB_CODE_BRIDGE_HOST		0x00
+#define  PCI_CLASS_SUB_CODE_BRIDGE_ISA		0x01
+#define  PCI_CLASS_SUB_CODE_BRIDGE_EISA		0x02
+#define  PCI_CLASS_SUB_CODE_BRIDGE_MCA		0x03
+#define  PCI_CLASS_SUB_CODE_BRIDGE_PCI		0x04
+#define  PCI_CLASS_SUB_CODE_BRIDGE_PCMCIA	0x05
+#define  PCI_CLASS_SUB_CODE_BRIDGE_NUBUS	0x06
+#define  PCI_CLASS_SUB_CODE_BRIDGE_CARDBUS	0x07
+#define  PCI_CLASS_SUB_CODE_BRIDGE_RACEWAY	0x08
+#define  PCI_CLASS_SUB_CODE_BRIDGE_SEMI_PCI	0x09
+#define  PCI_CLASS_SUB_CODE_BRIDGE_INFINIBAND	0x0A
+#define  PCI_CLASS_SUB_CODE_BRIDGE_OTHER	0x80
+#define  PCI_CLASS_SUB_CODE_COMM_SERIAL		0x00
+#define  PCI_CLASS_SUB_CODE_COMM_PARALLEL	0x01
+#define  PCI_CLASS_SUB_CODE_COMM_MULTIPORT	0x02
+#define  PCI_CLASS_SUB_CODE_COMM_MODEM		0x03
+#define  PCI_CLASS_SUB_CODE_COMM_GPIB		0x04
+#define  PCI_CLASS_SUB_CODE_COMM_SMARTCARD	0x05
+#define  PCI_CLASS_SUB_CODE_COMM_OTHER		0x80
+#define  PCI_CLASS_SUB_CODE_PERIPHERAL_PIC	0x00
+#define  PCI_CLASS_SUB_CODE_PERIPHERAL_DMA	0x01
+#define  PCI_CLASS_SUB_CODE_PERIPHERAL_TIMER	0x02
+#define  PCI_CLASS_SUB_CODE_PERIPHERAL_RTC	0x03
+#define  PCI_CLASS_SUB_CODE_PERIPHERAL_HOTPLUG	0x04
+#define  PCI_CLASS_SUB_CODE_PERIPHERAL_SD	0x05
+#define  PCI_CLASS_SUB_CODE_PERIPHERAL_OTHER	0x80
+#define  PCI_CLASS_SUB_CODE_INPUT_KEYBOARD	0x00
+#define  PCI_CLASS_SUB_CODE_INPUT_DIGITIZER	0x01
+#define  PCI_CLASS_SUB_CODE_INPUT_MOUSE		0x02
+#define  PCI_CLASS_SUB_CODE_INPUT_SCANNER	0x03
+#define  PCI_CLASS_SUB_CODE_INPUT_GAMEPORT	0x04
+#define  PCI_CLASS_SUB_CODE_INPUT_OTHER		0x80
+#define  PCI_CLASS_SUB_CODE_DOCKING_GENERIC	0x00
+#define  PCI_CLASS_SUB_CODE_DOCKING_OTHER	0x80
+#define  PCI_CLASS_SUB_CODE_PROCESSOR_386	0x00
+#define  PCI_CLASS_SUB_CODE_PROCESSOR_486	0x01
+#define  PCI_CLASS_SUB_CODE_PROCESSOR_PENTIUM	0x02
+#define  PCI_CLASS_SUB_CODE_PROCESSOR_ALPHA	0x10
+#define  PCI_CLASS_SUB_CODE_PROCESSOR_POWERPC	0x20
+#define  PCI_CLASS_SUB_CODE_PROCESSOR_MIPS	0x30
+#define  PCI_CLASS_SUB_CODE_PROCESSOR_COPROC	0x40
+#define  PCI_CLASS_SUB_CODE_SERIAL_1394		0x00
+#define  PCI_CLASS_SUB_CODE_SERIAL_ACCESSBUS	0x01
+#define  PCI_CLASS_SUB_CODE_SERIAL_SSA		0x02
+#define  PCI_CLASS_SUB_CODE_SERIAL_USB		0x03
+#define  PCI_CLASS_SUB_CODE_SERIAL_FIBRECHAN	0x04
+#define  PCI_CLASS_SUB_CODE_SERIAL_SMBUS	0x05
+#define  PCI_CLASS_SUB_CODE_SERIAL_INFINIBAND	0x06
+#define  PCI_CLASS_SUB_CODE_SERIAL_IPMI		0x07
+#define  PCI_CLASS_SUB_CODE_SERIAL_SERCOS	0x08
+#define  PCI_CLASS_SUB_CODE_SERIAL_CANBUS	0x09
+#define  PCI_CLASS_SUB_CODE_WIRELESS_IRDA	0x00
+#define  PCI_CLASS_SUB_CODE_WIRELESS_IR		0x01
+#define  PCI_CLASS_SUB_CODE_WIRELESS_RF		0x10
+#define  PCI_CLASS_SUB_CODE_WIRELESS_BLUETOOTH	0x11
+#define  PCI_CLASS_SUB_CODE_WIRELESS_BROADBAND	0x12
+#define  PCI_CLASS_SUB_CODE_WIRELESS_80211A	0x20
+#define  PCI_CLASS_SUB_CODE_WIRELESS_80211B	0x21
+#define  PCI_CLASS_SUB_CODE_WIRELESS_OTHER	0x80
+#define  PCI_CLASS_SUB_CODE_I2O_V1_0		0x00
+#define  PCI_CLASS_SUB_CODE_SATELLITE_TV	0x01
+#define  PCI_CLASS_SUB_CODE_SATELLITE_AUDIO	0x02
+#define  PCI_CLASS_SUB_CODE_SATELLITE_VOICE	0x03
+#define  PCI_CLASS_SUB_CODE_SATELLITE_DATA	0x04
+#define  PCI_CLASS_SUB_CODE_CRYPTO_NETWORK	0x00
+#define  PCI_CLASS_SUB_CODE_CRYPTO_ENTERTAINMENT 0x10
+#define  PCI_CLASS_SUB_CODE_CRYPTO_OTHER	0x80
+#define  PCI_CLASS_SUB_CODE_DATA_DPIO		0x00
+#define  PCI_CLASS_SUB_CODE_DATA_PERFCNTR	0x01
+#define  PCI_CLASS_SUB_CODE_DATA_COMMSYNC	0x10
+#define  PCI_CLASS_SUB_CODE_DATA_MGMT		0x20
+#define  PCI_CLASS_SUB_CODE_DATA_OTHER		0x80
 
 #define PCI_CACHE_LINE_SIZE	0x0c	/* 8 bits */
 #define PCI_LATENCY_TIMER	0x0d	/* 8 bits */
-- 
1.7.7.3

[U-Boot] [PATCH 2/3] x86: Enable ICH6 GPIO controller for coreboot

[Simon Glass]

Coreboot uses this controller to implement GPIO access.

Signed-off-by: Simon Glass <sjg@chromium.org>
---
 include/configs/coreboot.h |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/include/configs/coreboot.h b/include/configs/coreboot.h
index 0e89242..2e084ee 100644
--- a/include/configs/coreboot.h
+++ b/include/configs/coreboot.h
@@ -99,6 +99,9 @@
 #undef CONFIG_VIDEO
 #undef CONFIG_CFB_CONSOLE
 
+/* x86 GPIOs are accessed through a PCI device */
+#define CONFIG_INTEL_ICH6_GPIO
+
 /*-----------------------------------------------------------------------
  * Command line configuration.
  */
-- 
1.7.7.3

[U-Boot] [PATCH 3/3] x86: gpio: Add additional GPIO banks to the ICH6 driver

[Simon Glass]

From: Bill Richardson <wfrichar@chromium.org>

We can generally trust the ICH to have GPIO Bank 0 (the first 32 pins) in the
same place across all versions. This change adds two more banks, for up to
96 GPIOS.

BUT:
- Not all chipsets have the same number of GPIOs
- Not all chipsets have the same number of GPIO banks
- Not all chipsets put the additional banks at the same offset from GPIOBASE
- There so many chipset variants that it's pretty much impossible to support
  them all, or even keep track of the new ones.

So, although this adds suppport for the additional banks that seem to work
for the particular variants of CougarPoint Mobile chipsets that we've tried,
there's no chance it will support everything Intel produces. Good luck.

Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Signed-off-by: Simon Glass <sjg@chromium.org>
---
 drivers/gpio/intel_ich6_gpio.c |  172 +++++++++++++++++++++++++--------------
 1 files changed, 110 insertions(+), 62 deletions(-)

diff --git a/drivers/gpio/intel_ich6_gpio.c b/drivers/gpio/intel_ich6_gpio.c
index 1ccb641..6fed01f 100644
--- a/drivers/gpio/intel_ich6_gpio.c
+++ b/drivers/gpio/intel_ich6_gpio.c
@@ -32,6 +32,14 @@
  *   PCI config register "GPIOBASE"
  *     PCI I/O space + [GPIOBASE]  => start of GPIO registers
  *       GPIO registers => gpio pin function, direction, value
+ *
+ *
+ * Danger Will Robinson! Bank 0 (GPIOs 0-31) seems to be fairly stable. Most
+ * ICH versions have more, but the decoding the matrix that describes them is
+ * absurdly complex and constantly changing. We'll provide Bank 1 and Bank 2,
+ * but they will ONLY work for certain unspecified chipsets because the offset
+ * from GPIOBASE changes randomly. Even then, many GPIOs are unimplemented or
+ * reserved or subject to arcane restrictions.
  */
 
 #include <common.h>
@@ -42,21 +50,59 @@
 /* Where in config space is the register that points to the GPIO registers? */
 #define PCI_CFG_GPIOBASE 0x48
 
-/*
- * There are often more than 32 GPIOs, depending on the ICH version.
- * For now, we just support bank 0 because it's the same for all.
- */
-#define GPIO_MAX 31
+#define NUM_BANKS 3
 
 /* Within the I/O space, where are the registers to control the GPIOs? */
-#define OFS_GPIO_USE_SEL 0x00
-#define OFS_GPIO_IO_SEL  0x04
-#define OFS_GP_LVL       0x0C
+static struct {
+	u8 use_sel;
+	u8 io_sel;
+	u8 lvl;
+} gpio_bank[NUM_BANKS] = {
+	{ 0x00, 0x04, 0x0c },		/* Bank 0 */
+	{ 0x30, 0x34, 0x38 },		/* Bank 1 */
+	{ 0x40, 0x44, 0x48 }		/* Bank 2 */
+};
+
+static pci_dev_t dev;			/* handle for 0:1f:0 */
+static u32 gpiobase;			/* offset into I/O space */
+static int found_it_once;		/* valid GPIO device? */
+static u32 lock[NUM_BANKS];		/* "lock" for access to pins */
 
-static pci_dev_t dev;				/* handle for 0:1f:0 */
-static u32 gpiobase;				/* offset into I/O space */
-static int found_it_once;			/* valid GPIO device? */
-static int in_use[GPIO_MAX];			/* "lock" for access to pins */
+static int bad_arg(int num, int *bank, int *bitnum)
+{
+	int i = num / 32;
+	int j = num % 32;
+
+	if (num < 0 || i > NUM_BANKS) {
+		debug("%s: bogus gpio num: %d\n", __func__, num);
+		return -1;
+	}
+	*bank = i;
+	*bitnum = j;
+	return 0;
+}
+
+static int mark_gpio(int bank, int bitnum)
+{
+	if (lock[bank] & (1UL << bitnum)) {
+		debug("%s: %d.%d already marked\n", __func__, bank, bitnum);
+		return -1;
+	}
+	lock[bank] |= (1 << bitnum);
+	return 0;
+}
+
+static void clear_gpio(int bank, int bitnum)
+{
+	lock[bank] &= ~(1 << bitnum);
+}
+
+static int notmine(int num, int *bank, int *bitnum)
+{
+	if (bad_arg(num, bank, bitnum))
+		return -1;
+	return !(lock[*bank] & (1UL << *bitnum));
+}
 
 static int gpio_init(void)
 {
@@ -77,11 +123,14 @@ static int gpio_init(void)
 		debug("%s: wrong VendorID\n", __func__);
 		return -1;
 	}
+
+	pci_read_config_word(dev, PCI_DEVICE_ID, &tmpword);
+	debug("Found %04x:%04x\n", PCI_VENDOR_ID_INTEL, tmpword);
 	/*
-	 * We'd like to check the Device ID too, but pretty much any
+	 * We'd like to validate the Device ID too, but pretty much any
 	 * value is either a) correct with slight differences, or b)
-	 * correct but undocumented. We'll have to check other things
-	 * instead...
+	 * correct but undocumented. We'll have to check a bunch of other
+	 * things instead...
 	 */
 
 	/* I/O should already be enabled (it's a RO bit). */
@@ -143,100 +192,99 @@ static int gpio_init(void)
 	return 0;
 }
 
-int gpio_request(unsigned gpio, const char *label /* UNUSED */)
+int gpio_request(unsigned num, const char *label /* UNUSED */)
 {
 	u32 tmplong;
+	int i = 0, j = 0;
 
-	/* Are we doing it wrong? */
-	if (gpio > GPIO_MAX || in_use[gpio]) {
-		debug("%s: gpio unavailable\n", __func__);
+	/* Is the hardware ready? */
+	if (gpio_init())
 		return -1;
-	}
 
-	/* Is the hardware ready? */
-	if (gpio_init()) {
-		debug("%s: gpio_init failed\n", __func__);
+	if (bad_arg(num, &i, &j))
 		return -1;
-	}
 
 	/*
 	 * Make sure that the GPIO pin we want isn't already in use for some
 	 * built-in hardware function. We have to check this for every
 	 * requested pin.
 	 */
-	tmplong = inl(gpiobase + OFS_GPIO_USE_SEL);
-	if (!(tmplong & (1UL << gpio))) {
-		debug("%s: reserved for internal use\n", __func__);
+	tmplong = inl(gpiobase + gpio_bank[i].use_sel);
+	if (!(tmplong & (1UL << j))) {
+		debug("%s: gpio %d is reserved for internal use\n", __func__,
+		      num);
 		return -1;
 	}
 
-	in_use[gpio] = 1;
-	return 0;
+	return mark_gpio(i, j);
 }
 
-int gpio_free(unsigned gpio)
+int gpio_free(unsigned num)
 {
-	if (gpio > GPIO_MAX || !in_use[gpio]) {
-		debug("%s: gpio unavailable\n", __func__);
+	int i = 0, j = 0;
+
+	if (notmine(num, &i, &j))
 		return -1;
-	}
-	in_use[gpio] = 0;
+
+	clear_gpio(i, j);
 	return 0;
 }
 
-int gpio_direction_input(unsigned gpio)
+int gpio_direction_input(unsigned num)
 {
 	u32 tmplong;
+	int i = 0, j = 0;
 
-	if (gpio > GPIO_MAX || !in_use[gpio]) {
-		debug("%s: gpio unavailable\n", __func__);
+	if (notmine(num, &i, &j))
 		return -1;
-	}
-	tmplong = inl(gpiobase + OFS_GPIO_IO_SEL);
-	tmplong |= (1UL << gpio);
-	outl(gpiobase + OFS_GPIO_IO_SEL, tmplong);
+
+	tmplong = inl(gpiobase + gpio_bank[i].io_sel);
+	tmplong |= (1UL << j);
+	outl(gpiobase + gpio_bank[i].io_sel, tmplong);
 	return 0;
 }
 
-int gpio_direction_output(unsigned gpio, int value)
+int gpio_direction_output(unsigned num, int value)
 {
 	u32 tmplong;
+	int i = 0, j = 0;
 
-	if (gpio > GPIO_MAX || !in_use[gpio]) {
-		debug("%s: gpio unavailable\n", __func__);
+	if (notmine(num, &i, &j))
 		return -1;
-	}
-	tmplong = inl(gpiobase + OFS_GPIO_IO_SEL);
-	tmplong &= ~(1UL << gpio);
-	outl(gpiobase + OFS_GPIO_IO_SEL, tmplong);
+
+	tmplong = inl(gpiobase + gpio_bank[i].io_sel);
+	tmplong &= ~(1UL << j);
+	outl(gpiobase + gpio_bank[i].io_sel, tmplong);
 	return 0;
 }
 
-int gpio_get_value(unsigned gpio)
+int gpio_get_value(unsigned num)
 {
 	u32 tmplong;
+	int i = 0, j = 0;
+	int r;
 
-	if (gpio > GPIO_MAX || !in_use[gpio]) {
-		debug("%s: gpio unavailable\n", __func__);
+	if (notmine(num, &i, &j))
 		return -1;
-	}
-	tmplong = inl(gpiobase + OFS_GP_LVL);
-	return (tmplong & (1UL << gpio)) ? 1 : 0;
+
+	tmplong = inl(gpiobase + gpio_bank[i].lvl);
+	r = (tmplong & (1UL << j)) ? 1 : 0;
+	return r;
 }
 
-int gpio_set_value(unsigned gpio, int value)
+int gpio_set_value(unsigned num, int value)
 {
 	u32 tmplong;
+	int i = 0, j = 0;
 
-	if (gpio > GPIO_MAX || !in_use[gpio]) {
-		debug("%s: gpio unavailable\n", __func__);
+	if (notmine(num, &i, &j))
 		return -1;
-	}
-	tmplong = inl(gpiobase + OFS_GP_LVL);
+
+	tmplong = inl(gpiobase + gpio_bank[i].lvl);
 	if (value)
-		tmplong |= (1UL << gpio);
+		tmplong |= (1UL << j);
 	else
-		tmplong &= ~(1UL << gpio);
-	outl(gpiobase + OFS_GP_LVL, tmplong);
+		tmplong &= ~(1UL << j);
+	outl(gpiobase + gpio_bank[i].lvl, tmplong);
 	return 0;
 }
-- 
1.7.7.3

[U-Boot] [PATCH 2/3] x86: Enable ICH6 GPIO controller for coreboot

[Graeme Russ]

Hi Simon,

On Oct 21, 2012 8:45 AM, "Simon Glass" <sjg@chromium.org> wrote:
>
> Coreboot uses this controller to implement GPIO access.

All coreboot supported boards, or just the ones you are dealing with ATM?

To give you some perspective, I'm working on n AMD E350 based board. Does
it have ICH6 GPIO?

I've come to a conclusion that U-Boot as a coreboot payload will be the
norm for the foreseeable futre, so let's make board specific support as
flexible as possible.

Regards,

Graeme

>
> Signed-off-by: Simon Glass <sjg@chromium.org>
> ---
>  include/configs/coreboot.h |    3 +++
>  1 files changed, 3 insertions(+), 0 deletions(-)
>
> diff --git a/include/configs/coreboot.h b/include/configs/coreboot.h
> index 0e89242..2e084ee 100644
> --- a/include/configs/coreboot.h
> +++ b/include/configs/coreboot.h
> @@ -99,6 +99,9 @@
>  #undef CONFIG_VIDEO
>  #undef CONFIG_CFB_CONSOLE
>
> +/* x86 GPIOs are accessed through a PCI device */
> +#define CONFIG_INTEL_ICH6_GPIO
> +
>  /*-----------------------------------------------------------------------
>   * Command line configuration.
>   */
> --
> 1.7.7.3
>

[U-Boot] [PATCH 2/3] x86: Enable ICH6 GPIO controller for coreboot

[Simon Glass]

Hi Graeme,

On Sat, Oct 20, 2012 at 3:22 PM, Graeme Russ <graeme.russ@gmail.com> wrote:
> Hi Simon,
>
> On Oct 21, 2012 8:45 AM, "Simon Glass" <sjg@chromium.org> wrote:
>>
>> Coreboot uses this controller to implement GPIO access.
>
> All coreboot supported boards, or just the ones you are dealing with ATM?
>
> To give you some perspective, I'm working on n AMD E350 based board. Does it
> have ICH6 GPIO?
>
> I've come to a conclusion that U-Boot as a coreboot payload will be the norm
> for the foreseeable futre, so let's make board specific support as flexible
> as possible.

If that's the case then we might need a little rethink. Are you saying
that coreboot might become the only board, or that the coreboot
functions should move into generic x86 code?

I am not sure about your board GPIO, but you could test it I suppose.

On ARM we use the fdt to describe what peripherals are there and what
are not. I suppose we could do the same thing here.

Regards,
Simon

>
> Regards,
>
> Graeme
>
>>
>> Signed-off-by: Simon Glass <sjg@chromium.org>
>> ---
>>  include/configs/coreboot.h |    3 +++
>>  1 files changed, 3 insertions(+), 0 deletions(-)
>>
>> diff --git a/include/configs/coreboot.h b/include/configs/coreboot.h
>> index 0e89242..2e084ee 100644
>> --- a/include/configs/coreboot.h
>> +++ b/include/configs/coreboot.h
>> @@ -99,6 +99,9 @@
>>  #undef CONFIG_VIDEO
>>  #undef CONFIG_CFB_CONSOLE
>>
>> +/* x86 GPIOs are accessed through a PCI device */
>> +#define CONFIG_INTEL_ICH6_GPIO
>> +
>>  /*-----------------------------------------------------------------------
>>   * Command line configuration.
>>   */
>> --
>> 1.7.7.3
>>

[U-Boot] [PATCH 2/3] x86: Enable ICH6 GPIO controller for coreboot

[Graeme Russ]

Hi Simon,

On Oct 21, 2012 9:32 AM, "Simon Glass" <sjg@chromium.org> wrote:
>
> Hi Graeme,
>
> On Sat, Oct 20, 2012 at 3:22 PM, Graeme Russ <graeme.russ@gmail.com>
wrote:
> > Hi Simon,
> >
> > On Oct 21, 2012 8:45 AM, "Simon Glass" <sjg@chromium.org> wrote:
> >>
> >> Coreboot uses this controller to implement GPIO access.
> >
> > All coreboot supported boards, or just the ones you are dealing with
ATM?
> >
> > To give you some perspective, I'm working on n AMD E350 based board.
Does it
> > have ICH6 GPIO?
> >
> > I've come to a conclusion that U-Boot as a coreboot payload will be the
norm
> > for the foreseeable futre, so let's make board specific support as
flexible
> > as possible.
>
> If that's the case then we might need a little rethink. Are you saying
> that coreboot might become the only board, or that the coreboot
> functions should move into generic x86 code?

Make coreboot a SoC and then have individual board configs which use it

>
> I am not sure about your board GPIO, but you could test it I suppose.
>
> On ARM we use the fdt to describe what peripherals are there and what
> are not. I suppose we could do the same thing here.

I was wondering how to pass more info from coreboot to U-Boot, maybe we can
use FDT

Regards,

Graeme

[U-Boot] [PATCH 2/3] x86: Enable ICH6 GPIO controller for coreboot

[Simon Glass]

Hi Graeme,

On Sat, Oct 20, 2012 at 3:57 PM, Graeme Russ <graeme.russ@gmail.com> wrote:
> Hi Simon,
>
> On Oct 21, 2012 9:32 AM, "Simon Glass" <sjg@chromium.org> wrote:
>>
>> Hi Graeme,
>>
>> On Sat, Oct 20, 2012 at 3:22 PM, Graeme Russ <graeme.russ@gmail.com>
>> wrote:
>> > Hi Simon,
>> >
>> > On Oct 21, 2012 8:45 AM, "Simon Glass" <sjg@chromium.org> wrote:
>> >>
>> >> Coreboot uses this controller to implement GPIO access.
>> >
>> > All coreboot supported boards, or just the ones you are dealing with
>> > ATM?
>> >
>> > To give you some perspective, I'm working on n AMD E350 based board.
>> > Does it
>> > have ICH6 GPIO?
>> >
>> > I've come to a conclusion that U-Boot as a coreboot payload will be the
>> > norm
>> > for the foreseeable futre, so let's make board specific support as
>> > flexible
>> > as possible.
>>
>> If that's the case then we might need a little rethink. Are you saying
>> that coreboot might become the only board, or that the coreboot
>> functions should move into generic x86 code?
>
> Make coreboot a SoC and then have individual board configs which use it

Hmmm ok. How is that going to play with real SOCs when x86 gets them?

>
>>
>> I am not sure about your board GPIO, but you could test it I suppose.
>>
>> On ARM we use the fdt to describe what peripherals are there and what
>> are not. I suppose we could do the same thing here.
>
> I was wondering how to pass more info from coreboot to U-Boot, maybe we can
> use FDT

We have been using that, but I think coreboot wants to stop. Coreboot
has its own tag-based data structure.

But what I mean is that you provide an fdt for your board which
describes the GPIO controller. So not something that coreboot deals
with, just something for the U-Boot GPIO drivers to look at.

Regards,
Simon

>
> Regards,
>
> Graeme

[U-Boot] [PATCH 2/3] x86: Enable ICH6 GPIO controller for coreboot

[Graeme Russ]

Hi Simon,

On 10/21/2012 10:51 AM, Simon Glass wrote:
> Hi Graeme,
> 
> On Sat, Oct 20, 2012 at 3:57 PM, Graeme Russ <graeme.russ@gmail.com> wrote:
>> Hi Simon,
>>
>> On Oct 21, 2012 9:32 AM, "Simon Glass" <sjg@chromium.org> wrote:
>>>
>>> Hi Graeme,
>>>
>>> On Sat, Oct 20, 2012 at 3:22 PM, Graeme Russ <graeme.russ@gmail.com>
>>> wrote:
>>>> Hi Simon,
>>>>
>>>> On Oct 21, 2012 8:45 AM, "Simon Glass" <sjg@chromium.org> wrote:
>>>>>
>>>>> Coreboot uses this controller to implement GPIO access.
>>>>
>>>> All coreboot supported boards, or just the ones you are dealing with
>>>> ATM?
>>>>
>>>> To give you some perspective, I'm working on n AMD E350 based board.
>>>> Does it
>>>> have ICH6 GPIO?
>>>>
>>>> I've come to a conclusion that U-Boot as a coreboot payload will be the
>>>> norm
>>>> for the foreseeable futre, so let's make board specific support as
>>>> flexible
>>>> as possible.
>>>
>>> If that's the case then we might need a little rethink. Are you saying
>>> that coreboot might become the only board, or that the coreboot
>>> functions should move into generic x86 code?
>>
>> Make coreboot a SoC and then have individual board configs which use it
> 
> Hmmm ok. How is that going to play with real SOCs when x86 gets them?

True. Could we just have a coreboot library and and board that is
chainloading U-Boot from coreboot simply define CONFIG_X86_COREBOOT?

>>> I am not sure about your board GPIO, but you could test it I suppose.
>>>
>>> On ARM we use the fdt to describe what peripherals are there and what
>>> are not. I suppose we could do the same thing here.
>>
>> I was wondering how to pass more info from coreboot to U-Boot, maybe we can
>> use FDT
> 
> We have been using that, but I think coreboot wants to stop. Coreboot
> has its own tag-based data structure.

Linux supports FDT, U-Boot supports FDT - Why not FDT from all the way through?

> But what I mean is that you provide an fdt for your board which
> describes the GPIO controller. So not something that coreboot deals
> with, just something for the U-Boot GPIO drivers to look at.

Remember, U-Boot will have the hardware support hard-coded - there will not
bee support for arbitrary hardware. Your coreboot and U-Boot images must,
to some extent, be a pigeon pair.

My concern is, who is initialising what hardware? U-Boot should not
re-initialise hardware already initialised by coreboot. I see FDT as a way
of passing the 'I have already initialised xxx' from coreboot to U-Boot.

Regards,

Graeme

[U-Boot] [PATCH 2/3] x86: Enable ICH6 GPIO controller for coreboot

[Simon Glass]

Hi Graeme,

On Sat, Oct 20, 2012 at 10:01 PM, Graeme Russ <graeme.russ@gmail.com> wrote:
> Hi Simon,
>
> On 10/21/2012 10:51 AM, Simon Glass wrote:
>> Hi Graeme,
>>
>> On Sat, Oct 20, 2012 at 3:57 PM, Graeme Russ <graeme.russ@gmail.com> wrote:
>>> Hi Simon,
>>>
>>> On Oct 21, 2012 9:32 AM, "Simon Glass" <sjg@chromium.org> wrote:
>>>>
>>>> Hi Graeme,
>>>>
>>>> On Sat, Oct 20, 2012 at 3:22 PM, Graeme Russ <graeme.russ@gmail.com>
>>>> wrote:
>>>>> Hi Simon,
>>>>>
>>>>> On Oct 21, 2012 8:45 AM, "Simon Glass" <sjg@chromium.org> wrote:
>>>>>>
>>>>>> Coreboot uses this controller to implement GPIO access.
>>>>>
>>>>> All coreboot supported boards, or just the ones you are dealing with
>>>>> ATM?
>>>>>
>>>>> To give you some perspective, I'm working on n AMD E350 based board.
>>>>> Does it
>>>>> have ICH6 GPIO?
>>>>>
>>>>> I've come to a conclusion that U-Boot as a coreboot payload will be the
>>>>> norm
>>>>> for the foreseeable futre, so let's make board specific support as
>>>>> flexible
>>>>> as possible.
>>>>
>>>> If that's the case then we might need a little rethink. Are you saying
>>>> that coreboot might become the only board, or that the coreboot
>>>> functions should move into generic x86 code?
>>>
>>> Make coreboot a SoC and then have individual board configs which use it
>>
>> Hmmm ok. How is that going to play with real SOCs when x86 gets them?
>
> True. Could we just have a coreboot library and and board that is
> chainloading U-Boot from coreboot simply define CONFIG_X86_COREBOOT?

Yes that sounds good, as discussed.

>
>>>> I am not sure about your board GPIO, but you could test it I suppose.
>>>>
>>>> On ARM we use the fdt to describe what peripherals are there and what
>>>> are not. I suppose we could do the same thing here.
>>>
>>> I was wondering how to pass more info from coreboot to U-Boot, maybe we can
>>> use FDT
>>
>> We have been using that, but I think coreboot wants to stop. Coreboot
>> has its own tag-based data structure.
>
> Linux supports FDT, U-Boot supports FDT - Why not FDT from all the way through?

Agreed, except for coreboot, because for now at least they don't want it.

>
>> But what I mean is that you provide an fdt for your board which
>> describes the GPIO controller. So not something that coreboot deals
>> with, just something for the U-Boot GPIO drivers to look at.
>
> Remember, U-Boot will have the hardware support hard-coded - there will not
> bee support for arbitrary hardware. Your coreboot and U-Boot images must,
> to some extent, be a pigeon pair.
>
> My concern is, who is initialising what hardware? U-Boot should not
> re-initialise hardware already initialised by coreboot. I see FDT as a way
> of passing the 'I have already initialised xxx' from coreboot to U-Boot.

The current plan is that coreboot inits the least possible to get the
machine running - e.g. memory, ACPI stuff. U-Boot drivers should do
the rest. With x86 there are complications like display init, and
calls back into coreboot for ACPI things, but U-Boot should be initing
the drivers where this is possible.

Regards,
Simon

>
> Regards,
>
> Graeme