]> git.sur5r.net Git - u-boot/commitdiff
x86: pch: Implement get_gpio_base op
authorBin Meng <bmeng.cn@gmail.com>
Mon, 1 Feb 2016 09:40:44 +0000 (01:40 -0800)
committerBin Meng <bmeng.cn@gmail.com>
Fri, 5 Feb 2016 04:47:21 +0000 (12:47 +0800)
Implement get_gpio_base op for bd82x6x, pch7 and pch9 drivers.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>
arch/x86/cpu/ivybridge/bd82x6x.c
drivers/pch/pch7.c
drivers/pch/pch9.c

index 66a8414b10b54831aa38fa3a8eca3099f7f3dade..996707b7feeadb833f144562e364277c6ff5491f 100644 (file)
@@ -19,6 +19,7 @@
 #include <asm/arch/pch.h>
 #include <asm/arch/sandybridge.h>
 
+#define GPIO_BASE      0x48
 #define BIOS_CTRL      0xdc
 
 static int pch_revision_id = -1;
@@ -200,9 +201,41 @@ static int bd82x6x_set_spi_protect(struct udevice *dev, bool protect)
        return 0;
 }
 
+static int bd82x6x_get_gpio_base(struct udevice *dev, u32 *gbasep)
+{
+       u32 base;
+
+       /*
+        * GPIO_BASE 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.
+        *
+        * Note we don't need check bit0 here, because the Tunnel Creek
+        * GPIO base address register bit0 is reserved (read returns 0),
+        * while on the Ivybridge the bit0 is used to indicate it is an
+        * I/O space.
+        */
+       dm_pci_read_config32(dev, GPIO_BASE, &base);
+       if (base == 0x00000000 || base == 0xffffffff) {
+               debug("%s: unexpected BASE value\n", __func__);
+               return -ENODEV;
+       }
+
+       /*
+        * 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.
+        */
+       *gbasep = base & 1 ? base & ~3 : base & ~15;
+
+       return 0;
+}
+
 static const struct pch_ops bd82x6x_pch_ops = {
        .get_spi_base   = bd82x6x_pch_get_spi_base,
        .set_spi_protect = bd82x6x_set_spi_protect,
+       .get_gpio_base  = bd82x6x_get_gpio_base,
 };
 
 static const struct udevice_id bd82x6x_ids[] = {
index fe1fb85131e33f545412418e1ccb2a87297a010e..302c9299ee0dfb67de414431ba3683be558b3db8 100644 (file)
@@ -8,6 +8,7 @@
 #include <dm.h>
 #include <pch.h>
 
+#define GPIO_BASE      0x44
 #define BIOS_CTRL      0xd8
 
 static int pch7_get_spi_base(struct udevice *dev, ulong *sbasep)
@@ -37,9 +38,41 @@ static int pch7_set_spi_protect(struct udevice *dev, bool protect)
        return 0;
 }
 
+static int pch7_get_gpio_base(struct udevice *dev, u32 *gbasep)
+{
+       u32 base;
+
+       /*
+        * GPIO_BASE 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.
+        *
+        * Note we don't need check bit0 here, because the Tunnel Creek
+        * GPIO base address register bit0 is reserved (read returns 0),
+        * while on the Ivybridge the bit0 is used to indicate it is an
+        * I/O space.
+        */
+       dm_pci_read_config32(dev, GPIO_BASE, &base);
+       if (base == 0x00000000 || base == 0xffffffff) {
+               debug("%s: unexpected BASE value\n", __func__);
+               return -ENODEV;
+       }
+
+       /*
+        * 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.
+        */
+       *gbasep = base & 1 ? base & ~3 : base & ~15;
+
+       return 0;
+}
+
 static const struct pch_ops pch7_ops = {
        .get_spi_base   = pch7_get_spi_base,
        .set_spi_protect = pch7_set_spi_protect,
+       .get_gpio_base  = pch7_get_gpio_base,
 };
 
 static const struct udevice_id pch7_ids[] = {
index 5ac2e8a91bfc31ae82f554388069f4170e5e37cc..2a212ceff13e9239eb08a1083533ba356da3f1de 100644 (file)
@@ -8,6 +8,7 @@
 #include <dm.h>
 #include <pch.h>
 
+#define GPIO_BASE      0x48
 #define SBASE_ADDR     0x54
 
 static int pch9_get_spi_base(struct udevice *dev, ulong *sbasep)
@@ -20,8 +21,40 @@ static int pch9_get_spi_base(struct udevice *dev, ulong *sbasep)
        return 0;
 }
 
+static int pch9_get_gpio_base(struct udevice *dev, u32 *gbasep)
+{
+       u32 base;
+
+       /*
+        * GPIO_BASE 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.
+        *
+        * Note we don't need check bit0 here, because the Tunnel Creek
+        * GPIO base address register bit0 is reserved (read returns 0),
+        * while on the Ivybridge the bit0 is used to indicate it is an
+        * I/O space.
+        */
+       dm_pci_read_config32(dev, GPIO_BASE, &base);
+       if (base == 0x00000000 || base == 0xffffffff) {
+               debug("%s: unexpected BASE value\n", __func__);
+               return -ENODEV;
+       }
+
+       /*
+        * 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.
+        */
+       *gbasep = base & 1 ? base & ~3 : base & ~15;
+
+       return 0;
+}
+
 static const struct pch_ops pch9_ops = {
        .get_spi_base   = pch9_get_spi_base,
+       .get_gpio_base  = pch9_get_gpio_base,
 };
 
 static const struct udevice_id pch9_ids[] = {