[U-Boot] [PATCH 0/8] x86: baytrail: Various fixes to pinctrl driver to enable SD in Linux

[U-Boot] [PATCH 0/8] x86: baytrail: Various fixes to pinctrl driver to enable SD in Linux

[Bin Meng]

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(-)

-- 
2.7.4

[U-Boot] [PATCH 1/8] x86: ich6_gpio: Output return value of syscon_get_by_driver_data()

[Bin Meng]

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

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
---

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

diff --git a/drivers/gpio/intel_ich6_gpio.c b/drivers/gpio/intel_ich6_gpio.c
index b7e379a..2d66d04 100644
--- a/drivers/gpio/intel_ich6_gpio.c
+++ b/drivers/gpio/intel_ich6_gpio.c
@@ -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;
-- 
2.7.4

[U-Boot] [PATCH 1/8] x86: ich6_gpio: Output return value of syscon_get_by_driver_data()

[Stefan Roese]

On 08.06.2016 14:07, Bin Meng wrote:
> The call to syscon_get_by_driver_data() does not save its return value.
> Print it out to aid debugging.
>
> Signed-off-by: Bin Meng <bmeng.cn@gmail.com>

Reviewed-by: Stefan Roese <sr@denx.de>

Thanks,
Stefan

[U-Boot] [PATCH 1/8] x86: ich6_gpio: Output return value of syscon_get_by_driver_data()

[Simon Glass]

On 8 June 2016 at 06:07, Bin Meng <bmeng.cn@gmail.com> wrote:
> The call to syscon_get_by_driver_data() does not save its return value.
> Print it out to aid debugging.
>
> Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
> ---
>
>  drivers/gpio/intel_ich6_gpio.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)

Reviewed-by: Simon Glass <sjg@chromium.org>

[U-Boot] [PATCH 1/8] x86: ich6_gpio: Output return value of syscon_get_by_driver_data()

[Bin Meng]

On Fri, Jun 10, 2016 at 8:35 AM, Simon Glass <sjg@chromium.org> wrote:
> On 8 June 2016 at 06:07, Bin Meng <bmeng.cn@gmail.com> wrote:
>> The call to syscon_get_by_driver_data() does not save its return value.
>> Print it out to aid debugging.
>>
>> Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
>> ---
>>
>>  drivers/gpio/intel_ich6_gpio.c | 4 +++-
>>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> Reviewed-by: Simon Glass <sjg@chromium.org>

applied to u-boot-x86, thanks!

[U-Boot] [PATCH 2/8] x86: baytrail: Add 'reg' property in the pinctrl node

[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.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
---

 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(+)

diff --git a/arch/x86/dts/bayleybay.dts b/arch/x86/dts/bayleybay.dts
index 4a50d86..536049b 100644
--- a/arch/x86/dts/bayleybay.dts
+++ b/arch/x86/dts/bayleybay.dts
@@ -65,6 +65,11 @@
 		};
 	};
 
+	pch_pinctrl {
+		compatible = "intel,x86-pinctrl";
+		reg = <0 0>;
+	};
+
 	pci {
 		compatible = "pci-x86";
 		#address-cells = <3>;
diff --git a/arch/x86/dts/conga-qeval20-qa3-e3845.dts b/arch/x86/dts/conga-qeval20-qa3-e3845.dts
index 1a4ecaa..7e69ba4 100644
--- a/arch/x86/dts/conga-qeval20-qa3-e3845.dts
+++ b/arch/x86/dts/conga-qeval20-qa3-e3845.dts
@@ -30,6 +30,7 @@
 
 	pch_pinctrl {
 		compatible = "intel,x86-pinctrl";
+		reg = <0 0>;
 	};
 
 	chosen {
diff --git a/arch/x86/dts/minnowmax.dts b/arch/x86/dts/minnowmax.dts
index 936455b..fda170c 100644
--- a/arch/x86/dts/minnowmax.dts
+++ b/arch/x86/dts/minnowmax.dts
@@ -29,6 +29,7 @@
 
 	pch_pinctrl {
 		compatible = "intel,x86-pinctrl";
+		reg = <0 0>;
 
 		/* GPIO E0 */
 		soc_gpio_s5_0 at 0 {
-- 
2.7.4

[U-Boot] [PATCH 2/8] x86: baytrail: Add 'reg' property in the pinctrl node

[Stefan Roese]

On 08.06.2016 14:07, Bin Meng wrote:
> 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.
>
> Signed-off-by: Bin Meng <bmeng.cn@gmail.com>

Reviewed-by: Stefan Roese <sr@denx.de>

Thanks,
Stefan

[U-Boot] [PATCH 2/8] x86: baytrail: Add 'reg' property in the pinctrl node

[Simon Glass]

On 8 June 2016 at 06:07, Bin Meng <bmeng.cn@gmail.com> wrote:
> 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.
>
> Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
> ---
>
>  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(+)

Reviewed-by: Simon Glass <sjg@chromium.org>

[U-Boot] [PATCH 2/8] x86: baytrail: Add 'reg' property in the pinctrl node

[Bin Meng]

On Fri, Jun 10, 2016 at 8:35 AM, Simon Glass <sjg@chromium.org> wrote:
> On 8 June 2016 at 06:07, Bin Meng <bmeng.cn@gmail.com> wrote:
>> 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.
>>
>> Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
>> ---
>>
>>  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(+)
>
> Reviewed-by: Simon Glass <sjg@chromium.org>

applied to u-boot-x86, thanks!

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

[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.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
---

 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(-)

diff --git a/arch/x86/dts/bayleybay.dts b/arch/x86/dts/bayleybay.dts
index 536049b..1c2f671 100644
--- a/arch/x86/dts/bayleybay.dts
+++ b/arch/x86/dts/bayleybay.dts
@@ -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;
diff --git a/arch/x86/dts/conga-qeval20-qa3-e3845.dts b/arch/x86/dts/conga-qeval20-qa3-e3845.dts
index 7e69ba4..1e14c8b 100644
--- a/arch/x86/dts/conga-qeval20-qa3-e3845.dts
+++ b/arch/x86/dts/conga-qeval20-qa3-e3845.dts
@@ -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;
diff --git a/arch/x86/dts/minnowmax.dts b/arch/x86/dts/minnowmax.dts
index fda170c..ba96e36 100644
--- a/arch/x86/dts/minnowmax.dts
+++ b/arch/x86/dts/minnowmax.dts
@@ -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;
-- 
2.7.4

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

[Stefan Roese]

On 08.06.2016 14:07, Bin Meng wrote:
> 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.
>
> Signed-off-by: Bin Meng <bmeng.cn@gmail.com>

Reviewed-by: Stefan Roese <sr@denx.de>

Thanks,
Stefan

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

[Simon Glass]

On 8 June 2016 at 06:07, Bin Meng <bmeng.cn@gmail.com> wrote:
> 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.
>
> Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
> ---
>
>  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(-)

Reviewed-by: Simon Glass <sjg@chromium.org>

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

[Bin Meng]

On Fri, Jun 10, 2016 at 8:35 AM, Simon Glass <sjg@chromium.org> wrote:
> On 8 June 2016 at 06:07, Bin Meng <bmeng.cn@gmail.com> wrote:
>> 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.
>>
>> Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
>> ---
>>
>>  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(-)
>
> Reviewed-by: Simon Glass <sjg@chromium.org>

applied to u-boot-x86, thanks!

[U-Boot] [PATCH 4/8] x86: baytrail: Configure card detect pin of the SD controller

[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.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
---

 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(+)

diff --git a/arch/x86/dts/bayleybay.dts b/arch/x86/dts/bayleybay.dts
index 1c2f671..c8907ce 100644
--- a/arch/x86/dts/bayleybay.dts
+++ b/arch/x86/dts/bayleybay.dts
@@ -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 {
diff --git a/arch/x86/dts/conga-qeval20-qa3-e3845.dts b/arch/x86/dts/conga-qeval20-qa3-e3845.dts
index 1e14c8b..fba089d 100644
--- a/arch/x86/dts/conga-qeval20-qa3-e3845.dts
+++ b/arch/x86/dts/conga-qeval20-qa3-e3845.dts
@@ -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 {
diff --git a/arch/x86/dts/minnowmax.dts b/arch/x86/dts/minnowmax.dts
index ba96e36..1a8a8cc 100644
--- a/arch/x86/dts/minnowmax.dts
+++ b/arch/x86/dts/minnowmax.dts
@@ -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 {
-- 
2.7.4

[U-Boot] [PATCH 4/8] x86: baytrail: Configure card detect pin of the SD controller

[Stefan Roese]

On 08.06.2016 14:07, Bin Meng wrote:
> 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.
>
> Signed-off-by: Bin Meng <bmeng.cn@gmail.com>

Reviewed-by: Stefan Roese <sr@denx.de>

Thanks,
Stefan

[U-Boot] [PATCH 4/8] x86: baytrail: Configure card detect pin of the SD controller

[Simon Glass]

On 8 June 2016 at 06:07, Bin Meng <bmeng.cn@gmail.com> wrote:
> 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.
>
> Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
> ---
>
>  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(+)

Reviewed-by: Simon Glass <sjg@chromium.org>

[U-Boot] [PATCH 4/8] x86: baytrail: Configure card detect pin of the SD controller

[Bin Meng]

On Fri, Jun 10, 2016 at 8:35 AM, Simon Glass <sjg@chromium.org> wrote:
> On 8 June 2016 at 06:07, Bin Meng <bmeng.cn@gmail.com> wrote:
>> 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.
>>
>> Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
>> ---
>>
>>  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(+)
>
> Reviewed-by: Simon Glass <sjg@chromium.org>

applied to u-boot-x86, thanks!

[U-Boot] [PATCH 5/8] x86: Update x86-pinctrl driver device-tree-bindings doc

[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

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
---

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

diff --git a/doc/device-tree-bindings/gpio/intel,x86-pinctrl.txt b/doc/device-tree-bindings/gpio/intel,x86-pinctrl.txt
index 22d3bec..8c3a84c 100644
--- a/doc/device-tree-bindings/gpio/intel,x86-pinctrl.txt
+++ b/doc/device-tree-bindings/gpio/intel,x86-pinctrl.txt
@@ -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>;
 };
-- 
2.7.4

[U-Boot] [PATCH 5/8] x86: Update x86-pinctrl driver device-tree-bindings doc

[Stefan Roese]

On 08.06.2016 14:07, Bin Meng wrote:
> 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
>
> Signed-off-by: Bin Meng <bmeng.cn@gmail.com>

Reviewed-by: Stefan Roese <sr@denx.de>

Thanks,
Stefan

[U-Boot] [PATCH 5/8] x86: Update x86-pinctrl driver device-tree-bindings doc

[Simon Glass]

On 8 June 2016 at 06:07, Bin Meng <bmeng.cn@gmail.com> wrote:
> 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
>
> Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
> ---
>
>  doc/device-tree-bindings/gpio/intel,x86-pinctrl.txt | 16 ++++++++--------
>  1 file changed, 8 insertions(+), 8 deletions(-)

Reviewed-by: Simon Glass <sjg@chromium.org>

[U-Boot] [PATCH 5/8] x86: Update x86-pinctrl driver device-tree-bindings doc

[Bin Meng]

On Fri, Jun 10, 2016 at 8:35 AM, Simon Glass <sjg@chromium.org> wrote:
> On 8 June 2016 at 06:07, Bin Meng <bmeng.cn@gmail.com> wrote:
>> 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
>>
>> Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
>> ---
>>
>>  doc/device-tree-bindings/gpio/intel,x86-pinctrl.txt | 16 ++++++++--------
>>  1 file changed, 8 insertions(+), 8 deletions(-)
>
> Reviewed-by: Simon Glass <sjg@chromium.org>

applied to u-boot-x86, thanks!

[U-Boot] [PATCH 6/8] x86: Enable regmap and syscon for coreboot and qemu-x86

[Bin Meng]

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

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
---

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

diff --git a/configs/coreboot-x86_defconfig b/configs/coreboot-x86_defconfig
index 2fa11fd..b18d80d 100644
--- a/configs/coreboot-x86_defconfig
+++ b/configs/coreboot-x86_defconfig
@@ -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
diff --git a/configs/qemu-x86_defconfig b/configs/qemu-x86_defconfig
index 45bb3ec..a03cff8 100644
--- a/configs/qemu-x86_defconfig
+++ b/configs/qemu-x86_defconfig
@@ -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
-- 
2.7.4

[U-Boot] [PATCH 6/8] x86: Enable regmap and syscon for coreboot and qemu-x86

[Stefan Roese]

On 08.06.2016 14:07, Bin Meng wrote:
> These are generic and should be turned on on coreboot and qemu-x86.
>
> Signed-off-by: Bin Meng <bmeng.cn@gmail.com>

Reviewed-by: Stefan Roese <sr@denx.de>

Thanks,
Stefan

[U-Boot] [PATCH 6/8] x86: Enable regmap and syscon for coreboot and qemu-x86

[Simon Glass]

On 8 June 2016 at 06:07, Bin Meng <bmeng.cn@gmail.com> wrote:
> These are generic and should be turned on on coreboot and qemu-x86.
>
> Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
> ---
>
>  configs/coreboot-x86_defconfig | 2 ++
>  configs/qemu-x86_defconfig     | 2 ++
>  2 files changed, 4 insertions(+)

Reviewed-by: Simon Glass <sjg@chromium.org>

[U-Boot] [PATCH 6/8] x86: Enable regmap and syscon for coreboot and qemu-x86

[Bin Meng]

On Fri, Jun 10, 2016 at 8:35 AM, Simon Glass <sjg@chromium.org> wrote:
> On 8 June 2016 at 06:07, Bin Meng <bmeng.cn@gmail.com> wrote:
>> These are generic and should be turned on on coreboot and qemu-x86.
>>
>> Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
>> ---
>>
>>  configs/coreboot-x86_defconfig | 2 ++
>>  configs/qemu-x86_defconfig     | 2 ++
>>  2 files changed, 4 insertions(+)
>
> Reviewed-by: Simon Glass <sjg@chromium.org>

applied to u-boot-x86, thanks!

[U-Boot] [PATCH 7/8] x86: Probe pinctrl driver in cpu_init_r()

[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().

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>

---

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

diff --git a/arch/x86/cpu/cpu.c b/arch/x86/cpu/cpu.c
index e522ff3..269043d 100644
--- a/arch/x86/cpu/cpu.c
+++ b/arch/x86/cpu/cpu.c
@@ -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;
 }
 
diff --git a/drivers/gpio/intel_ich6_gpio.c b/drivers/gpio/intel_ich6_gpio.c
index 2d66d04..fd6181f 100644
--- a/drivers/gpio/intel_ich6_gpio.c
+++ b/drivers/gpio/intel_ich6_gpio.c
@@ -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;
-- 
2.7.4

[U-Boot] [PATCH 7/8] x86: Probe pinctrl driver in cpu_init_r()

[Stefan Roese]

On 08.06.2016 14:07, Bin Meng wrote:
> 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().
>
> Signed-off-by: Bin Meng <bmeng.cn@gmail.com>

Reviewed-by: Stefan Roese <sr@denx.de>

Thanks,
Stefan

[U-Boot] [PATCH 7/8] x86: Probe pinctrl driver in cpu_init_r()

[Simon Glass]

On 8 June 2016 at 06:07, Bin Meng <bmeng.cn@gmail.com> wrote:
> 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().
>
> Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
>
> ---
>
>  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?

Reviewed-by: Simon Glass <sjg@chromium.org>

[U-Boot] [PATCH 7/8] x86: Probe pinctrl driver in cpu_init_r()

[Bin Meng]

Hi Simon,

On Fri, Jun 10, 2016 at 8:35 AM, Simon Glass <sjg@chromium.org> wrote:
> On 8 June 2016 at 06:07, Bin Meng <bmeng.cn@gmail.com> wrote:
>> 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().
>>
>> Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
>>
>> ---
>>
>>  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.

> Reviewed-by: Simon Glass <sjg@chromium.org>

Regards,
Bin

[U-Boot] [PATCH 7/8] x86: Probe pinctrl driver in cpu_init_r()

[George McCollister]

On Wed, Jun 8, 2016 at 7:07 AM, Bin Meng <bmeng.cn@gmail.com> wrote:
> 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().
>
> Signed-off-by: Bin Meng <bmeng.cn@gmail.com>

Reviewed-by: George McCollister <george.mccollister@gmail.com>
Tested-by: George McCollister <george.mccollister@gmail.com>

[U-Boot] [PATCH 7/8] x86: Probe pinctrl driver in cpu_init_r()

[Bin Meng]

On Sat, Jun 11, 2016 at 2:33 AM, George McCollister
<george.mccollister@gmail.com> wrote:
> On Wed, Jun 8, 2016 at 7:07 AM, Bin Meng <bmeng.cn@gmail.com> wrote:
>> 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().
>>
>> Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
>
> Reviewed-by: George McCollister <george.mccollister@gmail.com>
> Tested-by: George McCollister <george.mccollister@gmail.com>

applied to u-boot-x86, thanks!

[U-Boot] [PATCH 8/8] x86: broadwell: gpio: Remove the codes to set up pin control

[Bin Meng]

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

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
---

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

diff --git a/drivers/gpio/intel_broadwell_gpio.c b/drivers/gpio/intel_broadwell_gpio.c
index 81ce446..8b50900 100644
--- a/drivers/gpio/intel_broadwell_gpio.c
+++ b/drivers/gpio/intel_broadwell_gpio.c
@@ -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;
-- 
2.7.4

[U-Boot] [PATCH 8/8] x86: broadwell: gpio: Remove the codes to set up pin control

[Stefan Roese]

On 08.06.2016 14:07, Bin Meng wrote:
> Now that we have set up pin control in cpu_init_r(), remove the
> duplicated codes in the broadwell gpio driver.
>
> Signed-off-by: Bin Meng <bmeng.cn@gmail.com>

Reviewed-by: Stefan Roese <sr@denx.de>

Thanks,
Stefan

[U-Boot] [PATCH 8/8] x86: broadwell: gpio: Remove the codes to set up pin control

[Simon Glass]

On 8 June 2016 at 06:07, Bin Meng <bmeng.cn@gmail.com> wrote:
> Now that we have set up pin control in cpu_init_r(), remove the
> duplicated codes in the broadwell gpio driver.
>
> Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
> ---
>
>  drivers/gpio/intel_broadwell_gpio.c | 7 -------
>  1 file changed, 7 deletions(-)

Reviewed-by: Simon Glass <sjg@chromium.org>

[U-Boot] [PATCH 8/8] x86: broadwell: gpio: Remove the codes to set up pin control

[Bin Meng]

On Fri, Jun 10, 2016 at 8:36 AM, Simon Glass <sjg@chromium.org> wrote:
> On 8 June 2016 at 06:07, Bin Meng <bmeng.cn@gmail.com> wrote:
>> Now that we have set up pin control in cpu_init_r(), remove the
>> duplicated codes in the broadwell gpio driver.
>>
>> Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
>> ---
>>
>>  drivers/gpio/intel_broadwell_gpio.c | 7 -------
>>  1 file changed, 7 deletions(-)
>
> Reviewed-by: Simon Glass <sjg@chromium.org>

applied to u-boot-x86, thanks!