[U-Boot] [PATCH 0/8] 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(-)
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;
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
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
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!
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@0 {
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
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
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!
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;
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
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
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!
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@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@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@0 { + pad-offset = <0x3a0>; + mode-func = <1>; + }; };
chosen {
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
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
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!
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@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>; };
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
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
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!
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
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
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
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!
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;
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
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
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
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
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!
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;
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
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
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!
participants (4)
-
Bin Meng -
George McCollister -
Simon Glass -
Stefan Roese