[U-Boot] [PATCH 0/3] power: Add a driver to handle the PBIAS cell of the TI SOCs
In the TI SOCs a PBIAS cell exists to provide a bias voltage to the MMC1 IO cells. Without this bias voltage these I/O cells can not function properly. This bias voltage is either 1.8v or 3.0v.
The first patch implements the support for this PBIAS cell as a regulator driver. The sencond patch enables it in the default config for am57x and dra7x. The last patch is here to allow the binding of the driver. In the DTS of the dra7x and am57x platforms, the pbias entry is a child of a syscon.
Jean-Jacques Hiblot (3): regulator: pbias: Add PBIAS regulator for proper voltage switching on MMC1 configs: dra7xx_evm: am57xx_evm: Enable DM_REGULATOR_PBIAS dm: syscon: scan sub-nodes of the syscon node
configs/am57xx_evm_defconfig | 3 + configs/dra7xx_evm_defconfig | 1 + drivers/core/syscon-uclass.c | 1 + drivers/power/regulator/Kconfig | 10 + drivers/power/regulator/Makefile | 1 + drivers/power/regulator/pbias_regulator.c | 305 ++++++++++++++++++++++++++++++ 6 files changed, 321 insertions(+) create mode 100644 drivers/power/regulator/pbias_regulator.c
In the TI SOCs a PBIAS cell exists to provide a bias voltage to the MMC1 IO cells. Without this bias voltage these I/O cells can not function properly. The PBIAS cell is controlled by software.
Signed-off-by: Jean-Jacques Hiblot jjhiblot@ti.com --- drivers/power/regulator/Kconfig | 10 + drivers/power/regulator/Makefile | 1 + drivers/power/regulator/pbias_regulator.c | 305 ++++++++++++++++++++++++++++++ 3 files changed, 316 insertions(+) create mode 100644 drivers/power/regulator/pbias_regulator.c
diff --git a/drivers/power/regulator/Kconfig b/drivers/power/regulator/Kconfig index f213487..f4ed3cc 100644 --- a/drivers/power/regulator/Kconfig +++ b/drivers/power/regulator/Kconfig @@ -142,6 +142,16 @@ config DM_REGULATOR_PALMAS features for REGULATOR PALMAS and the family of PALMAS PMICs. The driver implements get/set api for: value and enable.
+config DM_REGULATOR_PBIAS + bool "Enable driver for PBIAS regulator" + ---help--- + This enables implementation of driver-model regulator uclass + features for pseudo-regulator PBIAS found in the OMAP SOCs. + This pseudo-regulator is used to provide a BIAS voltage to MMC1 + signal pads and must be configured properly during a voltage switch. + Voltage switching is required by some operating modes of SDcards and + eMMC. + config DM_REGULATOR_LP873X bool "Enable driver for LP873X PMIC regulators" depends on PMIC_LP873X diff --git a/drivers/power/regulator/Makefile b/drivers/power/regulator/Makefile index ce14d08..75d611a 100644 --- a/drivers/power/regulator/Makefile +++ b/drivers/power/regulator/Makefile @@ -17,5 +17,6 @@ obj-$(CONFIG_REGULATOR_S5M8767) += s5m8767.o obj-$(CONFIG_DM_REGULATOR_SANDBOX) += sandbox.o obj-$(CONFIG_REGULATOR_TPS65090) += tps65090_regulator.o obj-$(CONFIG_$(SPL_)DM_REGULATOR_PALMAS) += palmas_regulator.o +obj-$(CONFIG_$(SPL_)DM_REGULATOR_PBIAS) += pbias_regulator.o obj-$(CONFIG_$(SPL_)DM_REGULATOR_LP873X) += lp873x_regulator.o obj-$(CONFIG_$(SPL_)DM_REGULATOR_LP87565) += lp87565_regulator.o diff --git a/drivers/power/regulator/pbias_regulator.c b/drivers/power/regulator/pbias_regulator.c new file mode 100644 index 0000000..4d7a8ed --- /dev/null +++ b/drivers/power/regulator/pbias_regulator.c @@ -0,0 +1,305 @@ +/* + * (C) Copyright 2016 Texas Instruments Incorporated, <www.ti.com> + * Jean-Jacques Hiblot jjhiblot@ti.com + * + * SPDX-License-Identifier: GPL-2.0+ + */ + +#include <common.h> +#include <errno.h> +#include <dm.h> +#include <power/pmic.h> +#include <power/regulator.h> +#include <regmap.h> +#include <syscon.h> +#include <linux/bitops.h> + +DECLARE_GLOBAL_DATA_PTR; + +struct pbias_reg_info { + u32 enable; + u32 enable_mask; + u32 disable_val; + u32 vmode; + unsigned int enable_time; + char *name; +}; + +struct pbias_priv { + struct regmap *regmap; + int offset; +}; + +static const struct pmic_child_info pmic_children_info[] = { + { .prefix = "pbias", .driver = "pbias_regulator"}, + { }, +}; + +static int pbias_write(struct udevice *dev, uint reg, const uint8_t *buff, + int len) +{ + struct pbias_priv *priv = dev_get_priv(dev); + uint32_t val = *(uint32_t *)buff; + + if (len != 4) + return -EINVAL; + + return regmap_write(priv->regmap, priv->offset, val); +} + +static int pbias_read(struct udevice *dev, uint reg, uint8_t *buff, int len) +{ + struct pbias_priv *priv = dev_get_priv(dev); + + if (len != 4) + return -EINVAL; + + return regmap_read(priv->regmap, priv->offset, (uint32_t *)buff); +} + +static int pbias_ofdata_to_platdata(struct udevice *dev) +{ + struct pbias_priv *priv = dev_get_priv(dev); + struct udevice *syscon; + struct regmap *regmap; + struct fdt_resource res; + int err; + + err = uclass_get_device_by_phandle(UCLASS_SYSCON, dev, + "syscon", &syscon); + if (err) { + error("%s: unable to find syscon device (%d)\n", __func__, + err); + return err; + } + + regmap = syscon_get_regmap(syscon); + if (IS_ERR(regmap)) { + error("%s: unable to find regmap (%ld)\n", __func__, + PTR_ERR(regmap)); + return PTR_ERR(regmap); + } + priv->regmap = regmap; + + err = fdt_get_resource(gd->fdt_blob, dev_of_offset(dev), "reg", 0, + &res); + if (err) { + error("%s: unable to find offset (%d)\n", __func__, err); + return err; + } + priv->offset = res.start; + + return 0; +} + +static int pbias_bind(struct udevice *dev) +{ + int children; + + children = pmic_bind_children(dev, dev->node, pmic_children_info); + if (!children) + debug("%s: %s - no child found\n", __func__, dev->name); + + return 0; +} + +static struct dm_pmic_ops pbias_ops = { + .read = pbias_read, + .write = pbias_write, +}; + +static const struct udevice_id pbias_ids[] = { + { .compatible = "ti,pbias-dra7" }, + { } +}; + +U_BOOT_DRIVER(pbias_pmic) = { + .name = "pbias_pmic", + .id = UCLASS_PMIC, + .of_match = pbias_ids, + .bind = pbias_bind, + .ops = &pbias_ops, + .ofdata_to_platdata = pbias_ofdata_to_platdata, + .priv_auto_alloc_size = sizeof(struct pbias_priv), +}; + +static const struct pbias_reg_info pbias_mmc_omap2430 = { + .enable = BIT(1), + .enable_mask = BIT(1), + .vmode = BIT(0), + .disable_val = 0, + .enable_time = 100, + .name = "pbias_mmc_omap2430" +}; + +static const struct pbias_reg_info pbias_sim_omap3 = { + .enable = BIT(9), + .enable_mask = BIT(9), + .vmode = BIT(8), + .enable_time = 100, + .name = "pbias_sim_omap3" +}; + +static const struct pbias_reg_info pbias_mmc_omap4 = { + .enable = BIT(26) | BIT(22), + .enable_mask = BIT(26) | BIT(25) | BIT(22), + .disable_val = BIT(25), + .vmode = BIT(21), + .enable_time = 100, + .name = "pbias_mmc_omap4" +}; + +static const struct pbias_reg_info pbias_mmc_omap5 = { + .enable = BIT(27) | BIT(26), + .enable_mask = BIT(27) | BIT(25) | BIT(26), + .disable_val = BIT(25), + .vmode = BIT(21), + .enable_time = 100, + .name = "pbias_mmc_omap5" +}; + +static const struct pbias_reg_info *pbias_reg_infos[] = { + &pbias_mmc_omap5, + &pbias_mmc_omap4, + &pbias_sim_omap3, + &pbias_mmc_omap2430, + NULL +}; + + +static int pbias_regulator_probe(struct udevice *dev) +{ + const void *prop; + int len; + const struct pbias_reg_info **p = pbias_reg_infos; + struct dm_regulator_uclass_platdata *uc_pdata; + + uc_pdata = dev_get_uclass_platdata(dev); + + prop = fdt_getprop(gd->fdt_blob, dev_of_offset(dev), "regulator-name", + &len); + if (!prop) + return len; + + while (*p) { + if (fdt_stringlist_contains(prop, len, (*p)->name)) { + debug("found regulator %s\n", (*p)->name); + break; + } + p++; + } + if (!*p) { +#ifdef DEBUG + int i = 0; + const char *s; + + debug("regulator "); + while ((s = fdt_stringlist_get(gd->fdt_blob, dev_of_offset(dev), + "regulator-name", i++, NULL))) + debug("%s'%s' ", (i > 1) ? ", " : "", s); + debug("%s not supported\n", (i > 2) ? "are" : "is"); +#endif + return -EINVAL; + } + + uc_pdata->type = REGULATOR_TYPE_OTHER; + dev->priv = (void *)*p; + + return 0; +} + +static int pbias_regulator_get_value(struct udevice *dev) +{ + const struct pbias_reg_info *p = dev_get_priv(dev); + int rc; + uint32_t reg; + + rc = pmic_read(dev->parent, 0, (uint8_t *)®, sizeof(reg)); + if (rc) + return rc; + + debug("%s voltage id %s\n", p->name, + (reg & p->vmode) ? "3.0v" : "1.8v"); + return (reg & p->vmode) ? 3000000 : 1800000; +} + +static int pbias_regulator_set_value(struct udevice *dev, int uV) +{ + const struct pbias_reg_info *p = dev_get_priv(dev); + int rc; + uint32_t reg; + + debug("Setting %s voltage to %s\n", p->name, + (reg & p->vmode) ? "3.0v" : "1.8v"); + + rc = pmic_read(dev->parent, 0, (uint8_t *)®, sizeof(reg)); + if (rc) + return rc; + + if (uV == 3000000) + reg |= p->vmode; + else if (uV == 1800000) + reg &= ~p->vmode; + else + return -EINVAL; + + return pmic_write(dev->parent, 0, (uint8_t *)®, sizeof(reg)); +} + +static int pbias_regulator_get_enable(struct udevice *dev) +{ + const struct pbias_reg_info *p = dev_get_priv(dev); + int rc; + uint32_t reg; + + rc = pmic_read(dev->parent, 0, (uint8_t *)®, sizeof(reg)); + if (rc) + return rc; + + debug("%s id %s\n", p->name, + (reg & p->enable_mask) == (p->disable_val) ? "on" : "off"); + + return (reg & p->enable_mask) == (p->disable_val); +} + +static int pbias_regulator_set_enable(struct udevice *dev, bool enable) +{ + const struct pbias_reg_info *p = dev_get_priv(dev); + int rc; + uint32_t reg; + + debug("Turning %s %s\n", enable ? "on" : "off", p->name); + + rc = pmic_read(dev->parent, 0, (uint8_t *)®, sizeof(reg)); + if (rc) + return rc; + + reg &= ~p->enable_mask; + if (enable) + reg |= p->enable; + else + reg |= p->disable_val; + + rc = pmic_write(dev->parent, 0, (uint8_t *)®, sizeof(reg)); + if (rc) + return rc; + + if (enable) + udelay(p->enable_time); + + return 0; +} + +static const struct dm_regulator_ops pbias_regulator_ops = { + .get_value = pbias_regulator_get_value, + .set_value = pbias_regulator_set_value, + .get_enable = pbias_regulator_get_enable, + .set_enable = pbias_regulator_set_enable, +}; + +U_BOOT_DRIVER(pbias_regulator) = { + .name = "pbias_regulator", + .id = UCLASS_REGULATOR, + .ops = &pbias_regulator_ops, + .probe = pbias_regulator_probe, +};
On Wed, Jul 12, 2017 at 11:55:53AM +0200, Jean-Jacques Hiblot wrote:
In the TI SOCs a PBIAS cell exists to provide a bias voltage to the MMC1 IO cells. Without this bias voltage these I/O cells can not function properly. The PBIAS cell is controlled by software.
Signed-off-by: Jean-Jacques Hiblot jjhiblot@ti.com
Reviewed-by: Tom Rini trini@konsulko.com
But a minor thing:
- if (!*p) {
+#ifdef DEBUG
int i = 0;const char *s;debug("regulator ");while ((s = fdt_stringlist_get(gd->fdt_blob, dev_of_offset(dev),"regulator-name", i++, NULL)))debug("%s'%s' ", (i > 1) ? ", " : "", s);debug("%s not supported\n", (i > 2) ? "are" : "is");+#endif
return -EINVAL;- }
We should not need the DEBUG guard here as the string constants will get discarded with gcc-6.x (default min requirement starting in v2018.01) and a while(...) do nothing should get optimized away, and even if not, it's just the error case. I think we can stand clearer reading code here compared with a few extra bytes.
Hi,
On 12 July 2017 at 03:55, Jean-Jacques Hiblot jjhiblot@ti.com wrote:
In the TI SOCs a PBIAS cell exists to provide a bias voltage to the MMC1 IO cells. Without this bias voltage these I/O cells can not function properly. The PBIAS cell is controlled by software.
Signed-off-by: Jean-Jacques Hiblot jjhiblot@ti.com
drivers/power/regulator/Kconfig | 10 + drivers/power/regulator/Makefile | 1 + drivers/power/regulator/pbias_regulator.c | 305 ++++++++++++++++++++++++++++++ 3 files changed, 316 insertions(+) create mode 100644 drivers/power/regulator/pbias_regulator.c
Reviewed-by: Simon Glass sjg@chromium.org
But do I suggest using the dev_read() API instead of fdtdec for new code.
Regards, Simon
This regulator is used for voltage switching on MMC1 IO lines.
Signed-off-by: Jean-Jacques Hiblot jjhiblot@ti.com --- configs/am57xx_evm_defconfig | 3 +++ configs/dra7xx_evm_defconfig | 1 + 2 files changed, 4 insertions(+)
diff --git a/configs/am57xx_evm_defconfig b/configs/am57xx_evm_defconfig index 658ab92..214fcc5 100644 --- a/configs/am57xx_evm_defconfig +++ b/configs/am57xx_evm_defconfig @@ -40,6 +40,8 @@ CONFIG_SPL_OF_CONTROL=y CONFIG_OF_LIST="am57xx-beagle-x15 am57xx-beagle-x15-revb1 am572x-idk am571x-idk" CONFIG_DM=y CONFIG_SPL_DM=y +CONFIG_REGMAP=y +CONFIG_SYSCON=y # CONFIG_BLK is not set CONFIG_DFU_MMC=y CONFIG_DFU_RAM=y @@ -55,6 +57,7 @@ CONFIG_DM_PMIC=y CONFIG_PMIC_PALMAS=y CONFIG_DM_REGULATOR=y CONFIG_DM_REGULATOR_PALMAS=y +CONFIG_DM_REGULATOR_PBIAS=y CONFIG_DM_SERIAL=y CONFIG_SYS_NS16550=y CONFIG_DM_SPI=y diff --git a/configs/dra7xx_evm_defconfig b/configs/dra7xx_evm_defconfig index 6dd1baf..ac80231 100644 --- a/configs/dra7xx_evm_defconfig +++ b/configs/dra7xx_evm_defconfig @@ -67,6 +67,7 @@ CONFIG_DM_REGULATOR=y CONFIG_DM_REGULATOR_FIXED=y CONFIG_DM_REGULATOR_GPIO=y CONFIG_DM_REGULATOR_PALMAS=y +CONFIG_DM_REGULATOR_PBIAS=y CONFIG_DM_REGULATOR_LP873X=y CONFIG_DM_SERIAL=y CONFIG_SYS_NS16550=y
+ Andrew
On 7/12/2017 3:25 PM, Jean-Jacques Hiblot wrote:
This regulator is used for voltage switching on MMC1 IO lines.
Can you enable on HS platforms as well.
Thanks and regards, Lokesh
Signed-off-by: Jean-Jacques Hiblot jjhiblot@ti.com
configs/am57xx_evm_defconfig | 3 +++ configs/dra7xx_evm_defconfig | 1 + 2 files changed, 4 insertions(+)
diff --git a/configs/am57xx_evm_defconfig b/configs/am57xx_evm_defconfig index 658ab92..214fcc5 100644 --- a/configs/am57xx_evm_defconfig +++ b/configs/am57xx_evm_defconfig @@ -40,6 +40,8 @@ CONFIG_SPL_OF_CONTROL=y CONFIG_OF_LIST="am57xx-beagle-x15 am57xx-beagle-x15-revb1 am572x-idk am571x-idk" CONFIG_DM=y CONFIG_SPL_DM=y +CONFIG_REGMAP=y +CONFIG_SYSCON=y # CONFIG_BLK is not set CONFIG_DFU_MMC=y CONFIG_DFU_RAM=y @@ -55,6 +57,7 @@ CONFIG_DM_PMIC=y CONFIG_PMIC_PALMAS=y CONFIG_DM_REGULATOR=y CONFIG_DM_REGULATOR_PALMAS=y +CONFIG_DM_REGULATOR_PBIAS=y CONFIG_DM_SERIAL=y CONFIG_SYS_NS16550=y CONFIG_DM_SPI=y diff --git a/configs/dra7xx_evm_defconfig b/configs/dra7xx_evm_defconfig index 6dd1baf..ac80231 100644 --- a/configs/dra7xx_evm_defconfig +++ b/configs/dra7xx_evm_defconfig @@ -67,6 +67,7 @@ CONFIG_DM_REGULATOR=y CONFIG_DM_REGULATOR_FIXED=y CONFIG_DM_REGULATOR_GPIO=y CONFIG_DM_REGULATOR_PALMAS=y +CONFIG_DM_REGULATOR_PBIAS=y CONFIG_DM_REGULATOR_LP873X=y CONFIG_DM_SERIAL=y CONFIG_SYS_NS16550=y
On Wed, Jul 12, 2017 at 07:16:27PM +0530, Lokesh Vutla wrote:
- Andrew
On 7/12/2017 3:25 PM, Jean-Jacques Hiblot wrote:
This regulator is used for voltage switching on MMC1 IO lines.
Can you enable on HS platforms as well.
Is this a SoC thing (which includes a strongly encouraged to use in designs) or a board choice (you really can expect to find custom boards that wouldn't want this) ? I'm asking because it sounds like perhaps we should be imply'ing somewhere instead so that HS and EVM and custom boards are in sync. Thanks!
On 7/12/2017 11:01 PM, Tom Rini wrote:
On Wed, Jul 12, 2017 at 07:16:27PM +0530, Lokesh Vutla wrote:
- Andrew
On 7/12/2017 3:25 PM, Jean-Jacques Hiblot wrote:
This regulator is used for voltage switching on MMC1 IO lines.
Can you enable on HS platforms as well.
Is this a SoC thing (which includes a strongly encouraged to use in designs) or a board choice (you really can expect to find custom boards that wouldn't want this) ? I'm asking because it sounds like perhaps we should be imply'ing somewhere instead so that HS and EVM and custom boards are in sync. Thanks!
Regulators are a board choice. Yes, that makes sense. These can be implied for TARGET_DRA7XX_EVM.
Andrew do you have any objections with this?
Thanks and regards, Lokesh
On 07/12/2017 01:48 PM, Lokesh Vutla wrote:
On 7/12/2017 11:01 PM, Tom Rini wrote:
On Wed, Jul 12, 2017 at 07:16:27PM +0530, Lokesh Vutla wrote:
- Andrew
On 7/12/2017 3:25 PM, Jean-Jacques Hiblot wrote:
This regulator is used for voltage switching on MMC1 IO lines.
Can you enable on HS platforms as well.
Is this a SoC thing (which includes a strongly encouraged to use in designs) or a board choice (you really can expect to find custom boards that wouldn't want this) ? I'm asking because it sounds like perhaps we should be imply'ing somewhere instead so that HS and EVM and custom boards are in sync. Thanks!
Regulators are a board choice. Yes, that makes sense. These can be implied for TARGET_DRA7XX_EVM.
Andrew do you have any objections with this?
No objection. The more common stuff we can factor out of these defconfigs the better.
Andrew
Thanks and regards, Lokesh
On Thu, Jul 13, 2017 at 12:18:43AM +0530, Lokesh Vutla wrote:
On 7/12/2017 11:01 PM, Tom Rini wrote:
On Wed, Jul 12, 2017 at 07:16:27PM +0530, Lokesh Vutla wrote:
- Andrew
On 7/12/2017 3:25 PM, Jean-Jacques Hiblot wrote:
This regulator is used for voltage switching on MMC1 IO lines.
Can you enable on HS platforms as well.
Is this a SoC thing (which includes a strongly encouraged to use in designs) or a board choice (you really can expect to find custom boards that wouldn't want this) ? I'm asking because it sounds like perhaps we should be imply'ing somewhere instead so that HS and EVM and custom boards are in sync. Thanks!
Regulators are a board choice. Yes, that makes sense. These can be implied for TARGET_DRA7XX_EVM.
And that's really true? I ask since I recall there's some SoCs where it's a lot more theoretical than practical to have a PMIC other than the one the EVM uses. But, yes, board level imply is the way to go then. The rule of thumb should be that if it's not really optional, the board or SoC should imply it if there's a reason to not have it, or select it if it's required.
On 7/13/2017 5:15 AM, Tom Rini wrote:
On Thu, Jul 13, 2017 at 12:18:43AM +0530, Lokesh Vutla wrote:
On 7/12/2017 11:01 PM, Tom Rini wrote:
On Wed, Jul 12, 2017 at 07:16:27PM +0530, Lokesh Vutla wrote:
- Andrew
On 7/12/2017 3:25 PM, Jean-Jacques Hiblot wrote:
This regulator is used for voltage switching on MMC1 IO lines.
Can you enable on HS platforms as well.
Is this a SoC thing (which includes a strongly encouraged to use in designs) or a board choice (you really can expect to find custom boards that wouldn't want this) ? I'm asking because it sounds like perhaps we should be imply'ing somewhere instead so that HS and EVM and custom boards are in sync. Thanks!
Regulators are a board choice. Yes, that makes sense. These can be implied for TARGET_DRA7XX_EVM.
And that's really true? I ask since I recall there's some SoCs where it's a lot more theoretical than practical to have a PMIC other than the
Well, it is still possible to use a different PMIC and I guess it is better to stick it that way.
one the EVM uses. But, yes, board level imply is the way to go then. The rule of thumb should be that if it's not really optional, the board or SoC should imply it if there's a reason to not have it, or select it if it's required.
Jean, Can you repost the patch as Tom suggested?
Thanks and regards, Lokesh
On 13/07/2017 15:45, Lokesh Vutla wrote:
On 7/13/2017 5:15 AM, Tom Rini wrote:
On Thu, Jul 13, 2017 at 12:18:43AM +0530, Lokesh Vutla wrote:
On 7/12/2017 11:01 PM, Tom Rini wrote:
On Wed, Jul 12, 2017 at 07:16:27PM +0530, Lokesh Vutla wrote:
- Andrew
On 7/12/2017 3:25 PM, Jean-Jacques Hiblot wrote:
This regulator is used for voltage switching on MMC1 IO lines.
Can you enable on HS platforms as well.
Is this a SoC thing (which includes a strongly encouraged to use in designs) or a board choice (you really can expect to find custom boards that wouldn't want this) ? I'm asking because it sounds like perhaps we should be imply'ing somewhere instead so that HS and EVM and custom boards are in sync. Thanks!
Regulators are a board choice. Yes, that makes sense. These can be implied for TARGET_DRA7XX_EVM.
And that's really true? I ask since I recall there's some SoCs where it's a lot more theoretical than practical to have a PMIC other than the
Well, it is still possible to use a different PMIC and I guess it is better to stick it that way.
PBIAS is not board specific, it's in the SOC. I should probably make the hsmmc select it automatically when using DM_MMC and DM_REGULATOR.
one the EVM uses. But, yes, board level imply is the way to go then. The rule of thumb should be that if it's not really optional, the board or SoC should imply it if there's a reason to not have it, or select it if it's required.
Jean, Can you repost the patch as Tom suggested?
Thanks and regards, Lokesh
This allow to probe devices that are defined under a syscon node
Signed-off-by: Jean-Jacques Hiblot jjhiblot@ti.com --- drivers/core/syscon-uclass.c | 1 + 1 file changed, 1 insertion(+)
diff --git a/drivers/core/syscon-uclass.c b/drivers/core/syscon-uclass.c index 2148469..b06ca6a 100644 --- a/drivers/core/syscon-uclass.c +++ b/drivers/core/syscon-uclass.c @@ -104,5 +104,6 @@ static const struct udevice_id generic_syscon_ids[] = { U_BOOT_DRIVER(generic_syscon) = { .name = "syscon", .id = UCLASS_SYSCON, + .bind = dm_scan_fdt_dev, .of_match = generic_syscon_ids, };
On 12 July 2017 at 03:55, Jean-Jacques Hiblot jjhiblot@ti.com wrote:
This allow to probe devices that are defined under a syscon node
Signed-off-by: Jean-Jacques Hiblot jjhiblot@ti.com
drivers/core/syscon-uclass.c | 1 + 1 file changed, 1 insertion(+)
Reviewed-by: Simon Glass sjg@chromium.org
participants (5)
-
Andrew F. Davis -
Jean-Jacques Hiblot -
Lokesh Vutla -
Simon Glass -
Tom Rini