x86: baytrail: Various fixes to pinctrl driver to enable SD in Linux
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
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
@@ -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
PATCH 1/8 x86: ich6_gpio: Output return value of syscon_get_by_driver_data()
Quoted 4 lines · 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 <[email protected]>
Thanks,
Stefan
PATCH 1/8 x86: ich6_gpio: Output return value of syscon_get_by_driver_data()
In reply to Bin MengQuoted 8 lines · 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 <[email protected]>---
drivers/gpio/intel_ich6_gpio.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
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.Signed-off-by Bin Meng <[email protected]>---
drivers/gpio/intel_ich6_gpio.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)Reviewed-by Simon Glass <[email protected]>
applied to u-boot-x86, thanks!
PATCH 2/8 x86: baytrail: Add 'reg' property in the pinctrl node
In reply to Bin MengWithout 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
@@ -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
@@ -30,6 +30,7 @@ pch_pinctrl { compatible = "intel,x86-pinctrl"; + reg = <0 0>; }; chosen {
arch/x86/dts/minnowmax.dts +1 -0
@@ -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
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.
Signed-off-by Bin Meng <[email protected]>
Thanks,
Stefan
PATCH 2/8 x86: baytrail: Add 'reg' property in the pinctrl node
In reply to Bin MengQuoted 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
Signed-off-by Bin Meng <[email protected]>---
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(+)
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.
Signed-off-by Bin Meng <[email protected]>---
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(+)Reviewed-by Simon Glass <[email protected]>
applied to u-boot-x86, thanks!
PATCH 3/8 x86: baytrail: Change fsp, emmc-boot-mode to "auto"
In reply to Bin MengAt 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
@@ -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
@@ -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
@@ -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
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.
Signed-off-by Bin Meng <[email protected]>
Thanks,
Stefan
PATCH 3/8 x86: baytrail: Change fsp, emmc-boot-mode to "auto"
In reply to Bin MengQuoted 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
Signed-off-by Bin Meng <[email protected]>---
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(-)
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.
Signed-off-by Bin Meng <[email protected]>---
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(-)Reviewed-by Simon Glass <[email protected]>
applied to u-boot-x86, thanks!
PATCH 4/8 x86: baytrail: Configure card detect pin of the SD controller
In reply to Bin MengAs 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
@@ -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
@@ -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
@@ -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
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_Bpin 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 <[email protected]>
Thanks,
Stefan
PATCH 4/8 x86: baytrail: Configure card detect pin of the SD controller
In reply to Bin MengQuoted 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_Bpin 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
Signed-off-by Bin Meng <[email protected]>---
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(+)
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_Bpin 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 <[email protected]>---
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(+)Reviewed-by Simon Glass <[email protected]>
applied to u-boot-x86, thanks!
PATCH 5/8 x86: Update x86-pinctrl driver device-tree-bindings doc
In reply to Bin MengThis 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
@@ -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
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 placesSigned-off-by Bin Meng <[email protected]>
Thanks,
Stefan
PATCH 5/8 x86: Update x86-pinctrl driver device-tree-bindings doc
In reply to Bin MengQuoted 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 placesSigned-off-by Bin Meng <[email protected]>---
doc/device-tree-bindings/gpio/intel,x86-pinctrl.txt | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-)
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
Signed-off-by Bin Meng <[email protected]>---
doc/device-tree-bindings/gpio/intel,x86-pinctrl.txt | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-)Reviewed-by Simon Glass <[email protected]>
applied to u-boot-x86, thanks!
PATCH 6/8 x86: Enable regmap and syscon for coreboot and qemu-x86
In reply to Bin MengThese 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
@@ -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
@@ -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
PATCH 6/8 x86: Enable regmap and syscon for coreboot and qemu-x86
Quoted 3 lines · Bin Meng
These are generic and should be turned on on coreboot and qemu-x86.
Signed-off-by Bin Meng <[email protected]>
Thanks,
Stefan
PATCH 6/8 x86: Enable regmap and syscon for coreboot and qemu-x86
In reply to Bin MengQuoted 8 lines · Bin Meng
These are generic and should be turned on on coreboot and qemu-x86.
Signed-off-by Bin Meng <[email protected]>---
configs/coreboot-x86_defconfig | 2 ++ configs/qemu-x86_defconfig | 2 ++ 2 files changed, 4 insertions(+)
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.
Signed-off-by Bin Meng <[email protected]>---
configs/coreboot-x86_defconfig | 2 ++ configs/qemu-x86_defconfig | 2 ++ 2 files changed, 4 insertions(+)Reviewed-by Simon Glass <[email protected]>
applied to u-boot-x86, thanks!
PATCH 7/8 x86: Probe pinctrl driver in cpu_init_r()
In reply to Bin MengAt 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
@@ -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
@@ -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
PATCH 7/8 x86: Probe pinctrl driver in cpu_init_r()
Quoted 11 lines · Bin Meng
At present pinctrl driver gets probed in
ich6_gpiodriver'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()fromich6_gpiodriver tocpu_init_r().Signed-off-by Bin Meng <[email protected]>
Thanks,
Stefan
PATCH 7/8 x86: Probe pinctrl driver in cpu_init_r()
In reply to Bin MengQuoted 14 lines · Bin Meng
At present pinctrl driver gets probed in
ich6_gpiodriver'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()fromich6_gpiodriver tocpu_init_r().
Quoted 7 lines
Signed-off-by Bin Meng <[email protected]>---
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?
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_gpiodriver'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()fromich6_gpiodriver tocpu_init_r().Signed-off-by Bin Meng <[email protected]>
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
Reviewed-by Simon Glass <[email protected]>
Regards,
Bin
PATCH 7/8 x86: Probe pinctrl driver in cpu_init_r()
In reply to Bin MengQuoted 11 lines · Bin Meng
At present pinctrl driver gets probed in
ich6_gpiodriver'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()fromich6_gpiodriver tocpu_init_r().Signed-off-by Bin Meng <[email protected]>
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_gpiodriver'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()fromich6_gpiodriver tocpu_init_r().Signed-off-by Bin Meng <[email protected]>Reviewed-by George McCollister <[email protected]>Tested-by George McCollister <[email protected]>
applied to u-boot-x86, thanks!
PATCH 8/8 x86: broadwell: gpio: Remove the codes to set up pin control
In reply to Bin MengNow 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
@@ -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
PATCH 8/8 x86: broadwell: gpio: Remove the codes to set up pin control
Quoted 4 lines · 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 <[email protected]>
Thanks,
Stefan
PATCH 8/8 x86: broadwell: gpio: Remove the codes to set up pin control
In reply to Bin MengQuoted 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.Signed-off-by Bin Meng <[email protected]>---
drivers/gpio/intel_broadwell_gpio.c | 7 ------- 1 file changed, 7 deletions(-)
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.Signed-off-by Bin Meng <[email protected]>---
drivers/gpio/intel_broadwell_gpio.c | 7 ------- 1 file changed, 7 deletions(-)Reviewed-by Simon Glass <[email protected]>
applied to u-boot-x86, thanks!