Skip to contentSkip to conversation

x86: baytrail: Various fixes to pinctrl driver to enable SD in Linux

PATCH New Bin Meng 4 participants 35 messages Jun 8, 2016 – Jun 12, 2016

Subsystems (2)
lore
Share & tools
lore

Bin Meng

author
#0 lore raw

cover x86: baytrail: Various fixes to pinctrl driver to enable SD in Linux

This fixes several issues in the pinctrl driver, and add SD controller card detect pin's PADs configuration to the device tree, so that Linux kernel SDHC driver is able to identify an inserted SD card.

Testing was done on MinnowMax board, by booting Linux kernel and check dmesg log to see if SD card was succesfully identified.

This series is available at u-boot-x86/pinctrl-fixes for testing.

Bin Meng (8):
x86: ich6_gpio: Output return value of syscon_get_by_driver_data()
x86: baytrail: Add 'reg' property in the pinctrl node
x86: baytrail: Change fsp,emmc-boot-mode to "auto"
x86: baytrail: Configure card detect pin of the SD controller
x86: Update x86-pinctrl driver device-tree-bindings doc
x86: Enable regmap and syscon for coreboot and qemu-x86
x86: Probe pinctrl driver in cpu_init_r()
x86: broadwell: gpio: Remove the codes to set up pin control

 arch/x86/cpu/cpu.c                                 |  5 +++++
 arch/x86/dts/bayleybay.dts                         | 22 +++++++++++++++++++++-
 arch/x86/dts/conga-qeval20-qa3-e3845.dts           | 18 +++++++++++++++++-
 arch/x86/dts/minnowmax.dts                         | 18 +++++++++++++++++-
 configs/coreboot-x86_defconfig                     |  2 ++
 configs/qemu-x86_defconfig                         |  2 ++
 .../gpio/intel,x86-pinctrl.txt                     | 16 ++++++++--------
 drivers/gpio/intel_broadwell_gpio.c                |  7 -------
 drivers/gpio/intel_ich6_gpio.c                     |  5 -----
 9 files changed, 72 insertions(+), 23 deletions(-)
Signature · 1 line
2.7.4
author
#1 lore raw

PATCH 1/8 x86: ich6_gpio: Output return value of syscon_get_by_driver_data()

The call to syscon_get_by_driver_data() does not save its return value. Print it out to aid debugging.

---

 drivers/gpio/intel_ich6_gpio.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)
drivers/gpio/intel_ich6_gpio.c +3 -1
index b7e379a..2d66d04 100644
@@ -114,9 +114,11 @@ static int ich6_gpio_probe(struct udevice *dev)
 	struct gpio_dev_priv *uc_priv = dev_get_uclass_priv(dev);
 	struct ich6_bank_priv *bank = dev_get_priv(dev);
 	struct udevice *pinctrl;
+	int ret;
 
 	/* Set up pin control if available */
-	syscon_get_by_driver_data(X86_SYSCON_PINCONF, &pinctrl);
+	ret = syscon_get_by_driver_data(X86_SYSCON_PINCONF, &pinctrl);
+	debug("%s, pinctrl=%p, ret=%d\n", __func__, pinctrl, ret);
 
 	uc_priv->gpio_count = GPIO_PER_BANK;
 	uc_priv->bank_name = plat->bank_name;
Signature · 1 line
2.7.4
author
#4 lore raw

PATCH 1/8 x86: ich6_gpio: Output return value of syscon_get_by_driver_data()

Quoted 11 lines · Simon Glass
Quoted 8 lines · Bin Meng

The call to syscon_get_by_driver_data() does not save its return value. Print it out to aid debugging.

---

 drivers/gpio/intel_ich6_gpio.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

applied to u-boot-x86, thanks!

author
#5 lore raw

PATCH 2/8 x86: baytrail: Add 'reg' property in the pinctrl node

In reply to Bin Meng

Without a 'reg' property, pinctrl driver probe routine fails in its pre_probe() with a return value of -EINVAL.

Add 'reg' property for all BayTrail boards. Note for BayleyBay, the pinctrl node is newly added.

---

 arch/x86/dts/bayleybay.dts               | 5 +++++
 arch/x86/dts/conga-qeval20-qa3-e3845.dts | 1 +
 arch/x86/dts/minnowmax.dts               | 1 +
 3 files changed, 7 insertions(+)
arch/x86/dts/bayleybay.dts +5 -0
index 4a50d86..536049b 100644
@@ -65,6 +65,11 @@
 		};
 	};
 
+	pch_pinctrl {
+		compatible = "intel,x86-pinctrl";
+		reg = <0 0>;
+	};
+
 	pci {
 		compatible = "pci-x86";
 		#address-cells = <3>;
arch/x86/dts/conga-qeval20-qa3-e3845.dts +1 -0
index 1a4ecaa..7e69ba4 100644
@@ -30,6 +30,7 @@
 
 	pch_pinctrl {
 		compatible = "intel,x86-pinctrl";
+		reg = <0 0>;
 	};
 
 	chosen {
arch/x86/dts/minnowmax.dts +1 -0
index 936455b..fda170c 100644
@@ -29,6 +29,7 @@
 
 	pch_pinctrl {
 		compatible = "intel,x86-pinctrl";
+		reg = <0 0>;
 
 		/* GPIO E0 */
 		soc_gpio_s5_0 at 0 {
Signature · 1 line
2.7.4
#6 lore raw

PATCH 2/8 x86: baytrail: Add 'reg' property in the pinctrl node

Quoted 7 lines · Bin Meng

Without a 'reg' property, pinctrl driver probe routine fails in its pre_probe() with a return value of -EINVAL.

Add 'reg' property for all BayTrail boards. Note for BayleyBay, the pinctrl node is newly added.

Thanks,
Stefan

#7 lore raw

PATCH 2/8 x86: baytrail: Add 'reg' property in the pinctrl node

In reply to Bin Meng
Quoted 6 lines · Bin Meng

Without a 'reg' property, pinctrl driver probe routine fails in its pre_probe() with a return value of -EINVAL.

Add 'reg' property for all BayTrail boards. Note for BayleyBay, the pinctrl node is newly added.

Quoted 7 lines

---

 arch/x86/dts/bayleybay.dts               | 5 +++++
 arch/x86/dts/conga-qeval20-qa3-e3845.dts | 1 +
 arch/x86/dts/minnowmax.dts               | 1 +
 3 files changed, 7 insertions(+)
author
#8 lore raw

PATCH 2/8 x86: baytrail: Add 'reg' property in the pinctrl node

Quoted 10 lines · Simon Glass
Quoted 9 lines · Bin Meng

Without a 'reg' property, pinctrl driver probe routine fails in its pre_probe() with a return value of -EINVAL.

Add 'reg' property for all BayTrail boards. Note for BayleyBay, the pinctrl node is newly added.

---

Quoted 6 lines
Quoted 4 lines
 arch/x86/dts/bayleybay.dts               | 5 +++++
 arch/x86/dts/conga-qeval20-qa3-e3845.dts | 1 +
 arch/x86/dts/minnowmax.dts               | 1 +
 3 files changed, 7 insertions(+)

applied to u-boot-x86, thanks!

author
#9 lore raw

PATCH 3/8 x86: baytrail: Change fsp, emmc-boot-mode to "auto"

In reply to Bin Meng

At present all BayTrail boards configure fsp,emmc-boot-mode to 2, which means "eMMC 4.1" per FSP documentation. However, eMMC 4.1 only shows up on some early stepping silicon of BayTrail SoC. Newer stepping SoC integrates an eMMC 4.5 controller. Intel FSP provides a config option fsp,emmc-boot-mode which tells FSP which eMMC controller it initializes. Instead of hardcoded to 2, now we change it to 1 which means "auto".

With this change, MinnowMax board (with a D0 stepping BayTrail SoC) can see the eMMC 4.5 controller at PCI address 00.17.00 via U-Boot 'pci' command.

---

 arch/x86/dts/bayleybay.dts               | 2 +-
 arch/x86/dts/conga-qeval20-qa3-e3845.dts | 2 +-
 arch/x86/dts/minnowmax.dts               | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)
arch/x86/dts/bayleybay.dts +1 -1
index 536049b..1c2f671 100644
@@ -218,7 +218,7 @@
 		fsp,mrc-init-mmio-size = <0x800>;
 		fsp,mrc-init-spd-addr1 = <0xa0>;
 		fsp,mrc-init-spd-addr2 = <0xa2>;
-		fsp,emmc-boot-mode = <2>;
+		fsp,emmc-boot-mode = <1>;
 		fsp,enable-sdio;
 		fsp,enable-sdcard;
 		fsp,enable-hsuart1;
arch/x86/dts/conga-qeval20-qa3-e3845.dts +1 -1
index 7e69ba4..1e14c8b 100644
@@ -218,7 +218,7 @@
 		fsp,mrc-init-mmio-size = <0x800>;
 		fsp,mrc-init-spd-addr1 = <0xa0>;
 		fsp,mrc-init-spd-addr2 = <0xa2>;
-		fsp,emmc-boot-mode = <2>;
+		fsp,emmc-boot-mode = <1>;
 		fsp,enable-sdio;
 		fsp,enable-sdcard;
 		fsp,enable-hsuart1;
arch/x86/dts/minnowmax.dts +1 -1
index fda170c..ba96e36 100644
@@ -247,7 +247,7 @@
 		fsp,mrc-init-mmio-size = <0x800>;
 		fsp,mrc-init-spd-addr1 = <0xa0>;
 		fsp,mrc-init-spd-addr2 = <0xa2>;
-		fsp,emmc-boot-mode = <2>;
+		fsp,emmc-boot-mode = <1>;
 		fsp,enable-sdio;
 		fsp,enable-sdcard;
 		fsp,enable-hsuart1;
Signature · 1 line
2.7.4
#10 lore raw

PATCH 3/8 x86: baytrail: Change fsp, emmc-boot-mode to "auto"

Quoted 8 lines · Bin Meng

At present all BayTrail boards configure fsp,emmc-boot-mode to 2, which means "eMMC 4.1" per FSP documentation. However, eMMC 4.1 only shows up on some early stepping silicon of BayTrail SoC. Newer stepping SoC integrates an eMMC 4.5 controller. Intel FSP provides a config option fsp,emmc-boot-mode which tells FSP which eMMC controller it initializes. Instead of hardcoded to 2, now we change it to 1 which means "auto".

Quoted 5 lines

With this change, MinnowMax board (with a D0 stepping BayTrail SoC) can see the eMMC 4.5 controller at PCI address 00.17.00 via U-Boot 'pci' command.

Thanks,
Stefan

#11 lore raw

PATCH 3/8 x86: baytrail: Change fsp, emmc-boot-mode to "auto"

In reply to Bin Meng
Quoted 12 lines · Bin Meng

At present all BayTrail boards configure fsp,emmc-boot-mode to 2, which means "eMMC 4.1" per FSP documentation. However, eMMC 4.1 only shows up on some early stepping silicon of BayTrail SoC. Newer stepping SoC integrates an eMMC 4.5 controller. Intel FSP provides a config option fsp,emmc-boot-mode which tells FSP which eMMC controller it initializes. Instead of hardcoded to 2, now we change it to 1 which means "auto".

With this change, MinnowMax board (with a D0 stepping BayTrail SoC) can see the eMMC 4.5 controller at PCI address 00.17.00 via U-Boot 'pci' command.

Quoted 7 lines

---

 arch/x86/dts/bayleybay.dts               | 2 +-
 arch/x86/dts/conga-qeval20-qa3-e3845.dts | 2 +-
 arch/x86/dts/minnowmax.dts               | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)
author
#12 lore raw

PATCH 3/8 x86: baytrail: Change fsp, emmc-boot-mode to "auto"

Quoted 16 lines · Simon Glass
Quoted 15 lines · Bin Meng

At present all BayTrail boards configure fsp,emmc-boot-mode to 2, which means "eMMC 4.1" per FSP documentation. However, eMMC 4.1 only shows up on some early stepping silicon of BayTrail SoC. Newer stepping SoC integrates an eMMC 4.5 controller. Intel FSP provides a config option fsp,emmc-boot-mode which tells FSP which eMMC controller it initializes. Instead of hardcoded to 2, now we change it to 1 which means "auto".

With this change, MinnowMax board (with a D0 stepping BayTrail SoC) can see the eMMC 4.5 controller at PCI address 00.17.00 via U-Boot 'pci' command.

---

Quoted 6 lines
Quoted 4 lines
 arch/x86/dts/bayleybay.dts               | 2 +-
 arch/x86/dts/conga-qeval20-qa3-e3845.dts | 2 +-
 arch/x86/dts/minnowmax.dts               | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

applied to u-boot-x86, thanks!

author
#13 lore raw

PATCH 4/8 x86: baytrail: Configure card detect pin of the SD controller

In reply to Bin Meng

As of today, the latest version FSP (gold4) for BayTrail misses the PAD configuration of the SD controller's Card Detect signal. The default PAD value for the CD pin sets the pin to work in GPIO mode, which causes card detect status cannot be reflected by the Present State register in the SD controller (bit 16 & bit 18 are always zero).

Add a configuration for this pin in the pinctrl node.

Note I've checked the PAD configuration for all the pins in all the 3 controllers (eMMC/SDIO/SD). Only this SDMMC3_CD_B pin does not get initialized to correct mode by FSP. With fsp,emmc-boot-mode set to 2 (eMMC 4.1), eMMC pins are initialized to func 1, but if we set fsp,emmc-boot-mode to 1 (auto), those pins are initialized to func 3 which is correct according to datasheet.

---

 arch/x86/dts/bayleybay.dts               | 15 +++++++++++++++
 arch/x86/dts/conga-qeval20-qa3-e3845.dts | 15 +++++++++++++++
 arch/x86/dts/minnowmax.dts               | 15 +++++++++++++++
 3 files changed, 45 insertions(+)
arch/x86/dts/bayleybay.dts +15 -0
index 1c2f671..c8907ce 100644
@@ -68,6 +68,21 @@
 	pch_pinctrl {
 		compatible = "intel,x86-pinctrl";
 		reg = <0 0>;
+
+		/*
+		 * As of today, the latest version FSP (gold4) for BayTrail
+		 * misses the PAD configuration of the SD controller's Card
+		 * Detect signal. The default PAD value for the CD pin sets
+		 * the pin to work in GPIO mode, which causes card detect
+		 * status cannot be reflected by the Present State register
+		 * in the SD controller (bit 16 & bit 18 are always zero).
+		 *
+		 * Configure this pin to function 1 (SD controller).
+		 */
+		sdmmc3_cd at 0 {
+			pad-offset = <0x3a0>;
+			mode-func = <1>;
+		};
 	};
 
 	pci {
arch/x86/dts/conga-qeval20-qa3-e3845.dts +15 -0
index 1e14c8b..fba089d 100644
@@ -31,6 +31,21 @@
 	pch_pinctrl {
 		compatible = "intel,x86-pinctrl";
 		reg = <0 0>;
+
+		/*
+		 * As of today, the latest version FSP (gold4) for BayTrail
+		 * misses the PAD configuration of the SD controller's Card
+		 * Detect signal. The default PAD value for the CD pin sets
+		 * the pin to work in GPIO mode, which causes card detect
+		 * status cannot be reflected by the Present State register
+		 * in the SD controller (bit 16 & bit 18 are always zero).
+		 *
+		 * Configure this pin to function 1 (SD controller).
+		 */
+		sdmmc3_cd at 0 {
+			pad-offset = <0x3a0>;
+			mode-func = <1>;
+		};
 	};
 
 	chosen {
arch/x86/dts/minnowmax.dts +15 -0
index ba96e36..1a8a8cc 100644
@@ -73,6 +73,21 @@
 			output-value = <1>;
 			direction = <PIN_OUTPUT>;
 		};
+
+		/*
+		 * As of today, the latest version FSP (gold4) for BayTrail
+		 * misses the PAD configuration of the SD controller's Card
+		 * Detect signal. The default PAD value for the CD pin sets
+		 * the pin to work in GPIO mode, which causes card detect
+		 * status cannot be reflected by the Present State register
+		 * in the SD controller (bit 16 & bit 18 are always zero).
+		 *
+		 * Configure this pin to function 1 (SD controller).
+		 */
+		sdmmc3_cd at 0 {
+			pad-offset = <0x3a0>;
+			mode-func = <1>;
+		};
 	};
 
 	chosen {
Signature · 1 line
2.7.4
#14 lore raw

PATCH 4/8 x86: baytrail: Configure card detect pin of the SD controller

Quoted 8 lines · Bin Meng

As of today, the latest version FSP (gold4) for BayTrail misses the PAD configuration of the SD controller's Card Detect signal. The default PAD value for the CD pin sets the pin to work in GPIO mode, which causes card detect status cannot be reflected by the Present State register in the SD controller (bit 16 & bit 18 are always zero).

Add a configuration for this pin in the pinctrl node.

Quoted 8 lines

Note I've checked the PAD configuration for all the pins in all the 3 controllers (eMMC/SDIO/SD). Only this SDMMC3_CD_B pin does not get initialized to correct mode by FSP. With fsp,emmc-boot-mode set to 2 (eMMC 4.1), eMMC pins are initialized to func 1, but if we set fsp,emmc-boot-mode to 1 (auto), those pins are initialized to func 3 which is correct according to datasheet.

Thanks,
Stefan

#15 lore raw

PATCH 4/8 x86: baytrail: Configure card detect pin of the SD controller

In reply to Bin Meng
Quoted 15 lines · Bin Meng

As of today, the latest version FSP (gold4) for BayTrail misses the PAD configuration of the SD controller's Card Detect signal. The default PAD value for the CD pin sets the pin to work in GPIO mode, which causes card detect status cannot be reflected by the Present State register in the SD controller (bit 16 & bit 18 are always zero).

Add a configuration for this pin in the pinctrl node.

Note I've checked the PAD configuration for all the pins in all the 3 controllers (eMMC/SDIO/SD). Only this SDMMC3_CD_B pin does not get initialized to correct mode by FSP. With fsp,emmc-boot-mode set to 2 (eMMC 4.1), eMMC pins are initialized to func 1, but if we set fsp,emmc-boot-mode to 1 (auto), those pins are initialized to func 3 which is correct according to datasheet.

Quoted 7 lines

---

 arch/x86/dts/bayleybay.dts               | 15 +++++++++++++++
 arch/x86/dts/conga-qeval20-qa3-e3845.dts | 15 +++++++++++++++
 arch/x86/dts/minnowmax.dts               | 15 +++++++++++++++
 3 files changed, 45 insertions(+)
author
#16 lore raw

PATCH 4/8 x86: baytrail: Configure card detect pin of the SD controller

Quoted 19 lines · Simon Glass
Quoted 18 lines · Bin Meng

As of today, the latest version FSP (gold4) for BayTrail misses the PAD configuration of the SD controller's Card Detect signal. The default PAD value for the CD pin sets the pin to work in GPIO mode, which causes card detect status cannot be reflected by the Present State register in the SD controller (bit 16 & bit 18 are always zero).

Add a configuration for this pin in the pinctrl node.

Note I've checked the PAD configuration for all the pins in all the 3 controllers (eMMC/SDIO/SD). Only this SDMMC3_CD_B pin does not get initialized to correct mode by FSP. With fsp,emmc-boot-mode set to 2 (eMMC 4.1), eMMC pins are initialized to func 1, but if we set fsp,emmc-boot-mode to 1 (auto), those pins are initialized to func 3 which is correct according to datasheet.

---

Quoted 6 lines
Quoted 4 lines
 arch/x86/dts/bayleybay.dts               | 15 +++++++++++++++
 arch/x86/dts/conga-qeval20-qa3-e3845.dts | 15 +++++++++++++++
 arch/x86/dts/minnowmax.dts               | 15 +++++++++++++++
 3 files changed, 45 insertions(+)

applied to u-boot-x86, thanks!

author
#17 lore raw

PATCH 5/8 x86: Update x86-pinctrl driver device-tree-bindings doc

In reply to Bin Meng

This updates the device-tree-bindings doc for x86-pinctrl driver:

- clarify "gpio-offset" is required only when "mode-gpio" is set
- correct property name "pull-strength"
- use tab instead of space at several places

---

 doc/device-tree-bindings/gpio/intel,x86-pinctrl.txt | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)
doc/device-tree-bindings/gpio/intel,x86-pinctrl.txt +8 -8
index 22d3bec..8c3a84c 100644
@@ -9,7 +9,7 @@ The PINCTRL master node requires the following properties:
 Pin nodes must be children of the pinctrl master node and can
 contain the following properties:
 - pad-offset	- (required) offset in the IOBASE for the pin to configure
-- gpio-offset	- (required) 2 cells
+- gpio-offset	- (required only when 'mode-gpio' is set) 2 cells
 			- offset in the GPIOBASE for the pin to configure
 			- the bit shift in this register (4 = bit 4)
 - mode-gpio	- (optional) standalone property to force the pin into GPIO mode
@@ -18,16 +18,16 @@ contain the following properties:
 in case of 'mode-gpio' property set:
 - output-value	- (optional) this set the default output value of the GPIO
 - direction	- (optional) this set the direction of the gpio
-- pull-str	- (optional) this set the pull strength of the pin
+- pull-strength	- (optional) this set the pull strength of the pin
 - pull-assign	- (optional) this set the pull assignement (up/down) of the pin
-- invert            - (optional) this input pin is inverted
+- invert	- (optional) this input pin is inverted
 
 Example:
 
 pin_usb_host_en0 at 0 {
-    gpio-offset = <0x80 8>;
-    pad-offset = <0x260>;
-    mode-gpio;
-    output-value = <1>;
-    direction = <PIN_OUTPUT>;
+	gpio-offset = <0x80 8>;
+	pad-offset = <0x260>;
+	mode-gpio;
+	output-value = <1>;
+	direction = <PIN_OUTPUT>;
 };
Signature · 1 line
2.7.4
#18 lore raw

PATCH 5/8 x86: Update x86-pinctrl driver device-tree-bindings doc

Quoted 7 lines · Bin Meng

This updates the device-tree-bindings doc for x86-pinctrl driver:

- clarify "gpio-offset" is required only when "mode-gpio" is set
- correct property name "pull-strength"
- use tab instead of space at several places

Thanks,
Stefan

#19 lore raw

PATCH 5/8 x86: Update x86-pinctrl driver device-tree-bindings doc

In reply to Bin Meng
Quoted 11 lines · Bin Meng

This updates the device-tree-bindings doc for x86-pinctrl driver:

- clarify "gpio-offset" is required only when "mode-gpio" is set
- correct property name "pull-strength"
- use tab instead of space at several places

---

 doc/device-tree-bindings/gpio/intel,x86-pinctrl.txt | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)
author
#20 lore raw

PATCH 5/8 x86: Update x86-pinctrl driver device-tree-bindings doc

Quoted 7 lines · Simon Glass
Quoted 6 lines · Bin Meng

This updates the device-tree-bindings doc for x86-pinctrl driver:

- clarify "gpio-offset" is required only when "mode-gpio" is set
- correct property name "pull-strength"
- use tab instead of space at several places

Quoted 7 lines
Quoted 5 lines

---

 doc/device-tree-bindings/gpio/intel,x86-pinctrl.txt | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

applied to u-boot-x86, thanks!

author
#21 lore raw

PATCH 6/8 x86: Enable regmap and syscon for coreboot and qemu-x86

In reply to Bin Meng

These are generic and should be turned on on coreboot and qemu-x86.

---

 configs/coreboot-x86_defconfig | 2 ++
 configs/qemu-x86_defconfig     | 2 ++
 2 files changed, 4 insertions(+)
configs/coreboot-x86_defconfig +2 -0
index 2fa11fd..b18d80d 100644
@@ -24,6 +24,8 @@ CONFIG_CMD_EXT4_WRITE=y
 CONFIG_CMD_FAT=y
 CONFIG_CMD_FS_GENERIC=y
 CONFIG_OF_CONTROL=y
+CONFIG_REGMAP=y
+CONFIG_SYSCON=y
 CONFIG_SPI_FLASH=y
 CONFIG_SPI_FLASH_GIGADEVICE=y
 CONFIG_SPI_FLASH_MACRONIX=y
configs/qemu-x86_defconfig +2 -0
index 45bb3ec..a03cff8 100644
@@ -28,6 +28,8 @@ CONFIG_CMD_EXT4_WRITE=y
 CONFIG_CMD_FAT=y
 CONFIG_CMD_FS_GENERIC=y
 CONFIG_OF_CONTROL=y
+CONFIG_REGMAP=y
+CONFIG_SYSCON=y
 CONFIG_CPU=y
 CONFIG_SPI_FLASH=y
 CONFIG_SPI_FLASH_GIGADEVICE=y
Signature · 1 line
2.7.4
author
#24 lore raw

PATCH 6/8 x86: Enable regmap and syscon for coreboot and qemu-x86

Quoted 11 lines · Simon Glass
Quoted 8 lines · Bin Meng

These are generic and should be turned on on coreboot and qemu-x86.

---

 configs/coreboot-x86_defconfig | 2 ++
 configs/qemu-x86_defconfig     | 2 ++
 2 files changed, 4 insertions(+)

applied to u-boot-x86, thanks!

author
#25 lore raw

PATCH 7/8 x86: Probe pinctrl driver in cpu_init_r()

In reply to Bin Meng

At present pinctrl driver gets probed in ich6_gpio driver's probe routine, which has two issues:

- Pin's PADs only gets configured when GPIO driver is probed, which is not done by default. This leaves the board in a partially functional state as we must initialize PADs correctly to get perepherals fully working.
- The probe routine of pinctrl driver is called multiple times, as normally there are multiple GPIO controllers. It should really be called just once.

Move the call to syscon_get_by_driver_data() from ich6_gpio driver to cpu_init_r().

---

 arch/x86/cpu/cpu.c             | 5 +++++
 drivers/gpio/intel_ich6_gpio.c | 7 -------
 2 files changed, 5 insertions(+), 7 deletions(-)
arch/x86/cpu/cpu.c +5 -0
index e522ff3..269043d 100644
@@ -24,6 +24,7 @@
 #include <dm.h>
 #include <errno.h>
 #include <malloc.h>
+#include <syscon.h>
 #include <asm/control_regs.h>
 #include <asm/coreboot_tables.h>
 #include <asm/cpu.h>
@@ -751,6 +752,10 @@ int cpu_init_r(void)
 	uclass_first_device(UCLASS_PCH, &dev);
 	uclass_first_device(UCLASS_LPC, &dev);
 
+	/* Set up pin control if available */
+	ret = syscon_get_by_driver_data(X86_SYSCON_PINCONF, &dev);
+	debug("%s, pinctrl=%p, ret=%d\n", __func__, dev, ret);
+
 	return 0;
 }
 
drivers/gpio/intel_ich6_gpio.c +0 -7
index 2d66d04..fd6181f 100644
@@ -32,7 +32,6 @@
 #include <fdtdec.h>
 #include <pch.h>
 #include <pci.h>
-#include <syscon.h>
 #include <asm/cpu.h>
 #include <asm/gpio.h>
 #include <asm/io.h>
@@ -113,12 +112,6 @@ static int ich6_gpio_probe(struct udevice *dev)
 	struct ich6_bank_platdata *plat = dev_get_platdata(dev);
 	struct gpio_dev_priv *uc_priv = dev_get_uclass_priv(dev);
 	struct ich6_bank_priv *bank = dev_get_priv(dev);
-	struct udevice *pinctrl;
-	int ret;
-
-	/* Set up pin control if available */
-	ret = syscon_get_by_driver_data(X86_SYSCON_PINCONF, &pinctrl);
-	debug("%s, pinctrl=%p, ret=%d\n", __func__, pinctrl, ret);
 
 	uc_priv->gpio_count = GPIO_PER_BANK;
 	uc_priv->bank_name = plat->bank_name;
Signature · 1 line
2.7.4
#26 lore raw

PATCH 7/8 x86: Probe pinctrl driver in cpu_init_r()

Quoted 11 lines · Bin Meng

At present pinctrl driver gets probed in ich6_gpio driver's probe routine, which has two issues:

- Pin's PADs only gets configured when GPIO driver is probed, which is not done by default. This leaves the board in a partially functional state as we must initialize PADs correctly to get perepherals fully working.
- The probe routine of pinctrl driver is called multiple times, as normally there are multiple GPIO controllers. It should really be called just once.

Quoted 4 lines

Move the call to syscon_get_by_driver_data() from ich6_gpio driver to cpu_init_r().

Thanks,
Stefan

#27 lore raw

PATCH 7/8 x86: Probe pinctrl driver in cpu_init_r()

In reply to Bin Meng
Quoted 14 lines · Bin Meng

At present pinctrl driver gets probed in ich6_gpio driver's probe routine, which has two issues:

- Pin's PADs only gets configured when GPIO driver is probed, which is not done by default. This leaves the board in a partially functional state as we must initialize PADs correctly to get perepherals fully working.
- The probe routine of pinctrl driver is called multiple times, as normally there are multiple GPIO controllers. It should really be called just once.

Move the call to syscon_get_by_driver_data() from ich6_gpio driver to cpu_init_r().

Quoted 7 lines

---

 arch/x86/cpu/cpu.c             | 5 +++++
 drivers/gpio/intel_ich6_gpio.c | 7 -------
 2 files changed, 5 insertions(+), 7 deletions(-)

I suppose this is better. But will the pins always be set up even if the GPIO driver is not used until later?

author
#28 lore raw

PATCH 7/8 x86: Probe pinctrl driver in cpu_init_r()

Hi Simon,

Quoted 17 lines · Simon Glass
Quoted 16 lines · Bin Meng

At present pinctrl driver gets probed in ich6_gpio driver's probe routine, which has two issues:

- Pin's PADs only gets configured when GPIO driver is probed, which is not done by default. This leaves the board in a partially functional state as we must initialize PADs correctly to get perepherals fully working.
- The probe routine of pinctrl driver is called multiple times, as normally there are multiple GPIO controllers. It should really be called just once.

Move the call to syscon_get_by_driver_data() from ich6_gpio driver to cpu_init_r().

Quoted 9 lines
Quoted 5 lines

---

 arch/x86/cpu/cpu.c             | 5 +++++
 drivers/gpio/intel_ich6_gpio.c | 7 -------
 2 files changed, 5 insertions(+), 7 deletions(-)

I suppose this is better. But will the pins always be set up even if the GPIO driver is not used until later?

I checked ich6_gpio and broadwell_gpio driver. Looks we are OK as the pinctrl driver only needs the GPIO base address.

Quoted 1 line

Regards,
Bin

#29 lore raw

PATCH 7/8 x86: Probe pinctrl driver in cpu_init_r()

In reply to Bin Meng
Quoted 11 lines · Bin Meng

At present pinctrl driver gets probed in ich6_gpio driver's probe routine, which has two issues:

- Pin's PADs only gets configured when GPIO driver is probed, which is not done by default. This leaves the board in a partially functional state as we must initialize PADs correctly to get perepherals fully working.
- The probe routine of pinctrl driver is called multiple times, as normally there are multiple GPIO controllers. It should really be called just once.

Quoted 4 lines

Move the call to syscon_get_by_driver_data() from ich6_gpio driver to cpu_init_r().

author
#30 lore raw

PATCH 7/8 x86: Probe pinctrl driver in cpu_init_r()

Quoted 12 lines · George McCollister
Quoted 11 lines · Bin Meng

At present pinctrl driver gets probed in ich6_gpio driver's probe routine, which has two issues:

- Pin's PADs only gets configured when GPIO driver is probed, which is not done by default. This leaves the board in a partially functional state as we must initialize PADs correctly to get perepherals fully working.
- The probe routine of pinctrl driver is called multiple times, as normally there are multiple GPIO controllers. It should really be called just once.

Quoted 7 lines
Quoted 4 lines

Move the call to syscon_get_by_driver_data() from ich6_gpio driver to cpu_init_r().

applied to u-boot-x86, thanks!

author
#31 lore raw

PATCH 8/8 x86: broadwell: gpio: Remove the codes to set up pin control

In reply to Bin Meng

Now that we have set up pin control in cpu_init_r(), remove the duplicated codes in the broadwell gpio driver.

---

 drivers/gpio/intel_broadwell_gpio.c | 7 -------
 1 file changed, 7 deletions(-)
drivers/gpio/intel_broadwell_gpio.c +0 -7
index 81ce446..8b50900 100644
@@ -9,7 +9,6 @@
 #include <fdtdec.h>
 #include <pch.h>
 #include <pci.h>
-#include <syscon.h>
 #include <asm/cpu.h>
 #include <asm/gpio.h>
 #include <asm/io.h>
@@ -119,12 +118,6 @@ static int broadwell_gpio_probe(struct udevice *dev)
 	struct broadwell_bank_platdata *plat = dev_get_platdata(dev);
 	struct gpio_dev_priv *uc_priv = dev_get_uclass_priv(dev);
 	struct broadwell_bank_priv *priv = dev_get_priv(dev);
-	struct udevice *pinctrl;
-	int ret;
-
-	/* Set up pin control if available */
-	ret = syscon_get_by_driver_data(X86_SYSCON_PINCONF, &pinctrl);
-	debug("%s, pinctrl=%p, ret=%d\n", __func__, pinctrl, ret);
 
 	uc_priv->gpio_count = GPIO_PER_BANK;
 	uc_priv->bank_name = plat->bank_name;
Signature · 1 line
2.7.4
author
#34 lore raw

PATCH 8/8 x86: broadwell: gpio: Remove the codes to set up pin control

Quoted 11 lines · Simon Glass
Quoted 8 lines · Bin Meng

Now that we have set up pin control in cpu_init_r(), remove the duplicated codes in the broadwell gpio driver.

---

 drivers/gpio/intel_broadwell_gpio.c | 7 -------
 1 file changed, 7 deletions(-)

applied to u-boot-x86, thanks!