Re: v2022.05.0
ср, 18 мая 2022 г. в 16:00, Sascha Hauer :
> Hi All,
> barebox-2022.05.0 is out.
Hello.
After updating to the new version, I found errors...
This is probably the result of the "gpio: allocate dynamic gpio
numbers top down" patch.
In the gpiochip_find_base function, it seems to me that we should
change the algorithm
if the chip exists, such as:
if (!chip) {
...
} else {
spare = 0;
i+= chip->ngpio - 1; // Should be: i -= chip->ngpio - 1; ???
}
Thanks!
barebox 2022.05.0-00506-g1ed17b742ede #59 Thu May 19 09:03:27 MSK 2022
Board: Mega-Milas Informer/Spider AM335x
cpsw-mdio 4a101000.m...@1000.of: detected phy mask 0x10
mdio_bus: miibus0: probed
eth0: got preset MAC address: d0:03:eb:ef:c2:a6
i2c-omap 44e0b000@0.of: bus 0 rev0.11 at 400 kHz
omap-hsmmc 4806@0.of: registered as mmc0
omap_wdt 44e35000@0.of: OMAP Watchdog Timer Rev 0x01
unable to handle paging request at address 0x3e0d0008
pc : [<8fe2b208>]lr : [<8fe2bf3f>]
sp : 8ffeff40 ip : fp : 0003f4f4
r10: 0017a4d8 r9 : 8fe7d628 r8 :
r7 : 87f59cd0 r6 : r5 : 87f5afbc r4 : 3e0d
r3 : 010c r2 : 0001 r1 : 87eff048 r0 : 0008
Flags: nzcv IRQs off FIQs on Mode SVC_32
WARNING: [<8fe2b208>] (gpiochip_add+0x80/0x294) from [<8fe2bf3f>]
(pca953x_probe+0x11b/0x158)
WARNING: [<8fe2bf3f>] (pca953x_probe+0x11b/0x158) from [<8fe0a901>]
(device_probe+0x2d/0xac)
WARNING: [<8fe0a901>] (device_probe+0x2d/0xac) from [<8fe0a9a7>]
(match+0x27/0x2c)
WARNING: [<8fe0a9a7>] (match+0x27/0x2c) from [<8fe0acf3>]
(register_driver+0x6b/0x88)
WARNING: [<8fe0acf3>] (register_driver+0x6b/0x88) from [<8fe00f09>]
(start_barebox+0x35/0x6c)
WARNING: [<8fe00f09>] (start_barebox+0x35/0x6c) from [<8fe46aa7>]
(barebox_non_pbl_start+0x127/0x16c)
WARNING: [<8fe46aa7>] (barebox_non_pbl_start+0x127/0x16c) from
[<8fe5>] (__bare_init_start+0x1/0xc)
WARNING: [<8fe482dd>] (unwind_backtrace+0x1/0x78) from [<8fe01235>]
(panic+0x1d/0x20)
WARNING: [<8fe01235>] (panic+0x1d/0x20) from [<8fe46323>]
(do_exception+0xf/0x14)
WARNING: [<8fe46323>] (do_exception+0xf/0x14) from [<8fe46391>]
(do_data_abort+0x21/0x34)
WARNING: [<8fe46391>] (do_data_abort+0x21/0x34) from [<8fe460d4>]
(do_abort_6+0x48/0x54)
### ERROR ### Please RESET the board ###
___
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
Re: [PATCH] clk: fix clk_round_rate() behaviour
Hi, On Mon, 16 May 2022 at 12:07, Sascha Hauer wrote: > I smell problems with this patch. Which clocks do you have that do not > have a round_rate hook but still allow to set its rate? Well, the reason for making this patch was actually the lack of any output from the clk_set_rate command if there was no set_rate (together with round_rate) hook set for a given clock. In this case set_rate() would check round_rate() to be equal to the current rate and leave without returning an error. But I would like to actually receive some response about the fact that this clock does not support setting its rate. However, I agree with you that this solution may lead to problems. Maybe instead we should explicitly check in a command whether the given clock has an appropriate hook set and output some message if this is not the case. What do you think? Regards, Denis ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
Re: One barebox image for multiple boards
Hi, I was pleasantly surprised to get so many comments on this topic. Thank you everyone for your input! Since I want to avoid duplicating the i2c bus driver in a PBL capable version, I decided to have a common barebox device tree for all boards. This means that the detection takes place in the board init code and then prepends the compatible with the matching board-specific entry. If at some point the hardware no longer allows this approach, I still can switch to the i2c-early solution. Thanks ~Matthias Am 16.05.2022 um 10:07 schrieb Sascha Hauer: On Fri, May 13, 2022 at 02:10:32PM +0200, Matthias Fend wrote: Hi Sascha, Am 13.05.2022 um 13:00 schrieb Sascha Hauer: Hi Matthias, On Fri, May 13, 2022 at 10:55:02AM +0200, Matthias Fend wrote: Hi, I'm looking for a solution to support multiple boards with just one barebox image. The few core components that are relevant for barebox are the same on all boards, so that the same barebox image runs on all boards. It is possible to dynamically detect the board type inside barebox, but as this requires some infrastructure it is not possible during lowlevel init. So basically Barebox should boot with a minimal core device tree, detect the board type and then use the corresponding device tree of the detected board. Something similar to arch/arm/boards/stm32mp15xx-dkx/lowlevel.c but not at low level. Do you even need the full device tree in barebox? The minimal core device tree might be enough for barebox and only the kernel is then booted with the full device tree. If there is no trick to changing the used device tree at boardlevel init, then this might be a possibility. Replacing the live tree after it has been partly probed already is dangerous and barebox is not really prepared for that. The core device tree might not be as minimal then and in exceptional cases minor fixups in the board code will be needed, but I think it could work. In such a case, how should one ensure that the appropriate blspec entry is booted? Maybe by simply replacing/updating the compatible string in the live device tree after the board was detected? As it happens Oleksij has just introduced of_prepend_machine_compatible() exactly for this usecase. You can find it in current next branch. Sascha ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
[PATCH] gpiolib: fix allocating dynamic gpio numbers.
Since f349b66267 the loop in gpiochip_find_base() counts downwards,
hence we must decrease i by the number of GPIOs in the current chip,
not increase them.
Fixes: f349b66267 ("gpio: allocate dynamic gpio numbers top down")
Reported-by: Alexander Shiyan
Signed-off-by: Sascha Hauer
---
drivers/gpio/gpiolib.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index 10cb7b3895..f845a57394 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -431,7 +431,7 @@ static int gpiochip_find_base(int ngpio)
}
} else {
spare = 0;
- i += chip->ngpio - 1;
+ i -= chip->ngpio - 1;
}
}
--
2.30.2
___
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
Driver load order
Hi, I try to create a basic driver for rk808 pmic/iodomains. I've noticed that first the iodomain driver is probed and then the rk808 on,but i need it reversed as rk808 registers regulators linked in iodomain via devicetree. How can i defer iodomain probing till rk808 is ready (regulators available defined as phandles in iodomain dt node)? Currently i get always ENODEV (property does not exist or regulator is not ready yet) This is my current (dirty) source: https://github.com/frank-w/barebox-r2pro/commits/r2pro-iodomain regards Frank ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
Re: Driver load order
Hello Frank, On 19.05.22 12:59, Frank Wunderlich wrote: > Hi, > > I try to create a basic driver for rk808 pmic/iodomains. I've noticed that > first the iodomain driver is probed and then the rk808 on,but i need it > reversed as rk808 registers regulators linked in iodomain via devicetree. > > How can i defer iodomain probing till rk808 is ready (regulators available > defined as phandles in iodomain dt node)? Currently i get always ENODEV > (property does not exist or regulator is not ready yet) > > This is my current (dirty) source: > https://github.com/frank-w/barebox-r2pro/commits/r2pro-iodomain While I don't know what iodomains are, I had ported the rk808 driver to barebox for use with the Rock Pi N10. I haven't come around to upstream it, because I haven't figured out why I can't use the existing regmap helpers like Linux does. I have sent you the patches as a reply to your mail. Perhaps they'll save you some effort. Cheers, Ahmad > regards Frank > > ___ > barebox mailing list > barebox@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/barebox > -- Pengutronix e.K. | | Steuerwalder Str. 21 | http://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
Re: Driver load order
Hi Frank, On Thu, May 19, 2022 at 12:59:35PM +0200, Frank Wunderlich wrote: > Hi, > > I try to create a basic driver for rk808 pmic/iodomains. I've noticed > that first the iodomain driver is probed and then the rk808 on,but i > need it reversed as rk808 registers regulators linked in iodomain via > devicetree. > > How can i defer iodomain probing till rk808 is ready (regulators > available defined as phandles in iodomain dt node)? Currently i get > always ENODEV (property does not exist or regulator is not ready > yet) Your board has deep probe enabled. The idea with deep probe is that the devices for a specific device node are registered on demand instead of any particular order. Basically this means that once you do a regulator_get() the regulator will be registered automatically for you without having to mess with the probe order. That said I'm not sure if that works properly with regulators yet. For deep probe to work there must be a device registered for the device node representing the regulator. Currently this is not the case, there will only be a device for the "rockchip,rk808" device node, but not for the regulator child nodes. I haven't found a suitable test setup to have a deeper look. If you could bring your rk808 driver up to a point where it actually registers the regulators then I could add the missing pieces in the regulator core for you. Sascha -- Pengutronix e.K. | | Steuerwalder Str. 21 | http://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
[PATCH 2/2] regulator: add Rockchip rk808 support
From: Ahmad Fatoum
Signed-off-by: Ahmad Fatoum
---
drivers/mfd/rk808.c | 395
drivers/regulator/Kconfig | 10 +
drivers/regulator/Makefile | 1 +
drivers/regulator/rk808-regulator.c | 897
include/linux/mfd/rk808.h | 721 ++
5 files changed, 2024 insertions(+)
create mode 100644 drivers/mfd/rk808.c
create mode 100644 drivers/regulator/rk808-regulator.c
create mode 100644 include/linux/mfd/rk808.h
diff --git a/drivers/mfd/rk808.c b/drivers/mfd/rk808.c
new file mode 100644
index ..1b5b9d3a1787
--- /dev/null
+++ b/drivers/mfd/rk808.c
@@ -0,0 +1,395 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * MFD core driver for Rockchip RK808/RK818
+ *
+ * Copyright (c) 2014, Fuzhou Rockchip Electronics Co., Ltd
+ *
+ * Author: Chris Zhong
+ * Author: Zhang Qing
+ *
+ * Copyright (C) 2016 PHYTEC Messtechnik GmbH
+ *
+ * Author: Wadim Egorov
+ */
+
+#define pr_fmt(fmt) "rk808: " fmt
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+struct rk808_reg_data {
+ int addr;
+ int mask;
+ int value;
+};
+
+static const struct regmap_config rk818_regmap_config = {
+ .reg_bits = 8,
+ .val_bits = 8,
+ .max_register = RK818_USB_CTRL_REG,
+};
+
+static const struct regmap_config rk805_regmap_config = {
+ .reg_bits = 8,
+ .val_bits = 8,
+ .max_register = RK805_OFF_SOURCE_REG,
+};
+
+static const struct regmap_config rk808_regmap_config = {
+ .reg_bits = 8,
+ .val_bits = 8,
+ .max_register = RK808_IO_POL_REG,
+};
+
+static const struct regmap_config rk817_regmap_config = {
+ .reg_bits = 8,
+ .val_bits = 8,
+ .max_register = RK817_GPIO_INT_CFG,
+};
+
+static const struct mfd_cell rk805s[] = {
+ { .name = "rk808-clkout", },
+ { .name = "rk808-regulator", },
+ { .name = "rk805-pinctrl", },
+ { .name = "rk808-rtc", },
+ { .name = "rk805-pwrkey", },
+};
+
+static const struct mfd_cell rk808s[] = {
+ { .name = "rk808-clkout", },
+ { .name = "rk808-regulator", },
+ { .name = "rk808-rtc", },
+};
+
+static const struct mfd_cell rk817s[] = {
+ { .name = "rk808-clkout", },
+ { .name = "rk808-regulator", },
+ { .name = "rk805-pwrkey", },
+ { .name = "rk808-rtc", },
+ { .name = "rk817-codec", },
+};
+
+static const struct mfd_cell rk818s[] = {
+ { .name = "rk808-clkout", },
+ { .name = "rk808-regulator", },
+ { .name = "rk808-rtc", },
+};
+
+static const struct rk808_reg_data rk805_pre_init_reg[] = {
+ {RK805_BUCK1_CONFIG_REG, RK805_BUCK1_2_ILMAX_MASK,
+RK805_BUCK1_2_ILMAX_4000MA},
+ {RK805_BUCK2_CONFIG_REG, RK805_BUCK1_2_ILMAX_MASK,
+RK805_BUCK1_2_ILMAX_4000MA},
+ {RK805_BUCK3_CONFIG_REG, RK805_BUCK3_4_ILMAX_MASK,
+RK805_BUCK3_ILMAX_3000MA},
+ {RK805_BUCK4_CONFIG_REG, RK805_BUCK3_4_ILMAX_MASK,
+RK805_BUCK4_ILMAX_3500MA},
+ {RK805_BUCK4_CONFIG_REG, BUCK_ILMIN_MASK, BUCK_ILMIN_400MA},
+ {RK805_THERMAL_REG, TEMP_HOTDIE_MSK, TEMP115C},
+};
+
+static const struct rk808_reg_data rk808_pre_init_reg[] = {
+ { RK808_BUCK3_CONFIG_REG, BUCK_ILMIN_MASK, BUCK_ILMIN_150MA },
+ { RK808_BUCK4_CONFIG_REG, BUCK_ILMIN_MASK, BUCK_ILMIN_200MA },
+ { RK808_BOOST_CONFIG_REG, BOOST_ILMIN_MASK, BOOST_ILMIN_100MA },
+ { RK808_BUCK1_CONFIG_REG, BUCK1_RATE_MASK, BUCK_ILMIN_200MA },
+ { RK808_BUCK2_CONFIG_REG, BUCK2_RATE_MASK, BUCK_ILMIN_200MA },
+ { RK808_DCDC_UV_ACT_REG, BUCK_UV_ACT_MASK, BUCK_UV_ACT_DISABLE},
+ { RK808_VB_MON_REG, MASK_ALL, VB_LO_ACT |
+ VB_LO_SEL_3500MV },
+};
+
+static const struct rk808_reg_data rk817_pre_init_reg[] = {
+ {RK817_RTC_CTRL_REG, RTC_STOP, RTC_STOP},
+ /* Codec specific registers */
+ { RK817_CODEC_DTOP_VUCTL, MASK_ALL, 0x03 },
+ { RK817_CODEC_DTOP_VUCTIME, MASK_ALL, 0x00 },
+ { RK817_CODEC_DTOP_LPT_SRST, MASK_ALL, 0x00 },
+ { RK817_CODEC_DTOP_DIGEN_CLKE, MASK_ALL, 0x00 },
+ /* from vendor driver, CODEC_AREF_RTCFG0 not defined in data sheet */
+ { RK817_CODEC_AREF_RTCFG0, MASK_ALL, 0x00 },
+ { RK817_CODEC_AREF_RTCFG1, MASK_ALL, 0x06 },
+ { RK817_CODEC_AADC_CFG0, MASK_ALL, 0xc8 },
+ /* from vendor driver, CODEC_AADC_CFG1 not defined in data sheet */
+ { RK817_CODEC_AADC_CFG1, MASK_ALL, 0x00 },
+ { RK817_CODEC_DADC_VOLL, MASK_ALL, 0x00 },
+ { RK817_CODEC_DADC_VOLR, MASK_ALL, 0x00 },
+ { RK817_CODEC_DADC_SR_ACL0, MASK_ALL, 0x00 },
+ { RK817_CODEC_DADC_ALC1, MASK_ALL, 0x00 },
+ { RK817_CODEC_DADC_ALC2, MASK_ALL, 0x00 },
+ { RK817_CODEC_DADC_NG, MASK_ALL, 0x00 },
+ { RK817_CODEC_DADC_HPF, MASK_ALL, 0x00
[PATCH 1/2] regmap: implement regmap_init_i2c_smbus
From: Ahmad Fatoum
Signed-off-by: Ahmad Fatoum
---
Works good enough to toggle Ethernet PHY regulator on a rk3399-based
Rock Pi N10.
---
drivers/base/regmap/regmap-i2c.c | 37
include/regmap.h | 3 +++
2 files changed, 40 insertions(+)
diff --git a/drivers/base/regmap/regmap-i2c.c b/drivers/base/regmap/regmap-i2c.c
index 5e3705162c92..756bc224cc3b 100644
--- a/drivers/base/regmap/regmap-i2c.c
+++ b/drivers/base/regmap/regmap-i2c.c
@@ -42,3 +42,40 @@ struct regmap *regmap_init_i2c(struct i2c_client *client,
{
return regmap_init(>dev, _regmap_i2c_bus, client,
config);
}
+
+static int regmap_smbus_byte_reg_read(void *client, unsigned int reg, unsigned
int *val)
+{
+ int ret;
+
+ if (reg > 0xff)
+ return -EINVAL;
+
+ ret = i2c_smbus_read_byte_data(client, reg);
+ if (ret < 0)
+ return ret;
+
+ *val = ret;
+
+ return 0;
+}
+
+static int regmap_smbus_byte_reg_write(void *client, unsigned int reg,
unsigned int val)
+{
+ if (val > 0xff || reg > 0xff)
+ return -EINVAL;
+
+ return i2c_smbus_write_byte_data(client, reg, val);
+}
+
+static const struct regmap_bus regmap_smbus_byte = {
+ .reg_write = regmap_smbus_byte_reg_write,
+ .reg_read = regmap_smbus_byte_reg_read,
+};
+
+struct regmap *regmap_init_i2c_smbus(struct i2c_client *client,
+ const struct regmap_config *config)
+{
+ if (config->val_bits != 8 || config->reg_bits != 8)
+ return ERR_PTR(-ENOSYS);
+ return regmap_init(>dev, _smbus_byte, client, config);
+}
diff --git a/include/regmap.h b/include/regmap.h
index 4b30c2177629..5bedb30d8a78 100644
--- a/include/regmap.h
+++ b/include/regmap.h
@@ -89,6 +89,9 @@ struct i2c_client;
struct regmap *regmap_init_i2c(struct i2c_client *i2c,
const struct regmap_config *config);
+struct regmap *regmap_init_i2c_smbus(struct i2c_client *client,
+ const struct regmap_config *config);
+
/**
* regmap_init_mmio() - Initialise register map
*
--
2.30.2
___
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
Re: Aw: Re: Driver load order
On Thu, May 19, 2022 at 02:50:13PM +0200, Ahmad Fatoum wrote: > On 19.05.22 14:43, Frank Wunderlich wrote: > > @ahmad: thanks for your driver. Take a quick look into it... > > > > it seems nearly complete, is there anything not working or was the only > > problem the missing regmap-handling added in part1? > > IIRC, Linux just has regmap_i2c_init which does the correct thing for all > callers. While in barebox this doesn't work and I had to add a smbus specific > regmap_init. We can always consolidate this later though, so feel free to > add whatever you find missing, test it and send it out for upstream > inclusion. You have my Signed-off-by. > > > My current approach is only register the regulators without doing a real > > pmic init. IO-Domain driver only needs to read out regulator voltage, i'm > > not sure if it's enough to get the value from the DT or if it needs to be > > really measured (to depend on complete probe/init of the pmic). > > > > but the problem is that iodomain is probed before the pmic due to > > deep-probing > > if i understand Sascha the right way. So i need a way to defer the iodomain > > driver > > probe till rk808 is ready. > > The right way with deep probe enabled is to just use regulator functions > normally and on first access, barebox will take care to probe the regulator > if not done yet. I am not sure if all this works as expected yet, but Sascha > already offered to help with that. I gave it a test with your rk808 driver. It just works \o/ regulator_get() triggers probing of the rk808 regulator driver and returns a valid regulator. Sascha -- Pengutronix e.K. | | Steuerwalder Str. 21 | http://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
Re: v2022.05.0
On Thu, May 19, 2022 at 11:11:06AM +0300, Alexander Shiyan wrote:
> ср, 18 мая 2022 г. в 16:00, Sascha Hauer :
> > Hi All,
> > barebox-2022.05.0 is out.
>
> Hello.
> After updating to the new version, I found errors...
> This is probably the result of the "gpio: allocate dynamic gpio
> numbers top down" patch.
> In the gpiochip_find_base function, it seems to me that we should
> change the algorithm
> if the chip exists, such as:
> if (!chip) {
> ...
> } else {
> spare = 0;
> i+= chip->ngpio - 1; // Should be: i -= chip->ngpio - 1; ???
> }
Yes, indeed :(
I just sent a fix.
Sascha
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
___
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
Re: [PATCH] of: address: treat absent dma-ranges as 1:1 translation
On Wed, May 18, 2022 at 07:57:45PM +0200, Lucas Stach wrote:
> Some DTs use dma-ranges in child busses without this property being present
> in the parent bus. To avoid failing the address translation, do the same as
> the Linux kernel and treat absence of this property as a 1:1 translation.
>
> Signed-off-by: Lucas Stach
> ---
> drivers/of/address.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
Applied, thanks
Sascha
>
> diff --git a/drivers/of/address.c b/drivers/of/address.c
> index 67e8062f5d17..4eafce376d36 100644
> --- a/drivers/of/address.c
> +++ b/drivers/of/address.c
> @@ -301,10 +301,13 @@ static int of_translate_one(struct device_node *parent,
> struct of_bus *bus,
>*
>* As far as we know, this damage only exists on Apple machines, so
>* This code is only enabled on powerpc. --gcl
> + *
> + * This quirk also applies for 'dma-ranges' which frequently exist in
> + * child nodes without 'dma-ranges' in the parent nodes. --RobH
>*/
> ranges = of_get_property(parent, rprop, );
> #if !defined(CONFIG_PPC)
> - if (ranges == NULL) {
> + if (ranges == NULL && strcmp(rprop, "dma-ranges")) {
> pr_vdebug("OF: no ranges; cannot translate\n");
> return 1;
> }
> --
> 2.35.3
>
>
> ___
> barebox mailing list
> barebox@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/barebox
>
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
___
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
Aw: Re: Driver load order
Hi,
> Gesendet: Donnerstag, 19. Mai 2022 um 13:54 Uhr
> Von: "Sascha Hauer"
> An: "Frank Wunderlich"
> Cc: barebox@lists.infradead.org
> Betreff: Re: Driver load order
>
> Hi Frank,
>
> On Thu, May 19, 2022 at 12:59:35PM +0200, Frank Wunderlich wrote:
> > Hi,
> >
> > I try to create a basic driver for rk808 pmic/iodomains. I've noticed
> > that first the iodomain driver is probed and then the rk808 on,but i
> > need it reversed as rk808 registers regulators linked in iodomain via
> > devicetree.
> >
> > How can i defer iodomain probing till rk808 is ready (regulators
> > available defined as phandles in iodomain dt node)? Currently i get
> > always ENODEV (property does not exist or regulator is not ready
> > yet)
>
> Your board has deep probe enabled. The idea with deep probe is that the
> devices for a specific device node are registered on demand instead of
> any particular order. Basically this means that once you do a
> regulator_get() the regulator will be registered automatically for you
> without having to mess with the probe order.
regulator_get returns Null in my case. So imho i need to register
the regulators from the rk808, right?
currently i probe the rk808 and do a double child-loop (first subnodes,
second subnode "regulators"). Then i have the regulator node itself and
i can do something like this:
struct regulator_dev *rd;
ret=of_regulator_register(rd,regchild);
including the loops to have the context:
struct device_node *child,*regchild;
for_each_child_of_node(dev->device_node, child) {
if (!strcmp(child->name,"regulators"))
{
dev_info(dev, "DEBUG %s:%d regulators
found\n",__FUNCTION__,__LINE__);
for_each_child_of_node(child, regchild) {
struct regulator_dev *rd;
ret=of_regulator_register(rd,regchild);
}
}
}
> That said I'm not sure if that works properly with regulators yet. For
> deep probe to work there must be a device registered for the device node
> representing the regulator. Currently this is not the case, there will
> only be a device for the "rockchip,rk808" device node, but not for the
> regulator child nodes.
as an idea i would do something like this in the iodomain-drivers probe:
if (!pmic_probed())
return -EPROBE_DEFER
but how can i check the pmic is probed? to delay the probing of the
iodomain driver. I check if the linked phandles are there and
not registered...here i get -ENODEV (-19), but if the proeprty does
not exist i get Null from of_regulator_get(). Basicly i can defer the
probe there (kernel and my current code do a continue here), but i
think it's better to do it before looping over the properties of iodomain.
> I haven't found a suitable test setup to have a deeper look. If you
> could bring your rk808 driver up to a point where it actually registers
> the regulators then I could add the missing pieces in the regulator core
> for you.
>
> Sascha
@ahmad: thanks for your driver. Take a quick look into it...
it seems nearly complete, is there anything not working or was the only
problem the missing regmap-handling added in part1?
My current approach is only register the regulators without doing a real
pmic init. IO-Domain driver only needs to read out regulator voltage, i'm
not sure if it's enough to get the value from the DT or if it needs to be
really measured (to depend on complete probe/init of the pmic).
but the problem is that iodomain is probed before the pmic due to deep-probing
if i understand Sascha the right way. So i need a way to defer the iodomain
driver
probe till rk808 is ready.
regards Frank
___
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
Re: Driver load order
On 19.05.22 14:17, Ahmad Fatoum wrote: > Hello Frank, > > On 19.05.22 12:59, Frank Wunderlich wrote: >> Hi, >> >> I try to create a basic driver for rk808 pmic/iodomains. I've noticed that >> first the iodomain driver is probed and then the rk808 on,but i need it >> reversed as rk808 registers regulators linked in iodomain via devicetree. >> >> How can i defer iodomain probing till rk808 is ready (regulators available >> defined as phandles in iodomain dt node)? Currently i get always ENODEV >> (property does not exist or regulator is not ready yet) >> >> This is my current (dirty) source: >> https://github.com/frank-w/barebox-r2pro/commits/r2pro-iodomain > > While I don't know what iodomains are, I had ported the rk808 driver to > barebox for > use with the Rock Pi N10. I haven't come around to upstream it, because I > haven't > figured out why I can't use the existing regmap helpers like Linux does. > > I have sent you the patches as a reply to your mail. Perhaps they'll > save you some effort. I see now that Kconfig/Makefile parts are missing, but I trust you can easily add those. Also, you'll need this patch: https://lore.barebox.org/barebox/20220114084728.311277-1-a.fat...@pengutronix.de/ (preferably after incorporating Sascha's feedback). Cheers, Ahmad > > Cheers, > Ahmad > > >> regards Frank >> >> ___ >> barebox mailing list >> barebox@lists.infradead.org >> http://lists.infradead.org/mailman/listinfo/barebox >> > > -- Pengutronix e.K. | | Steuerwalder Str. 21 | http://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
Re: Aw: Re: Driver load order
On 19.05.22 14:43, Frank Wunderlich wrote: > @ahmad: thanks for your driver. Take a quick look into it... > > it seems nearly complete, is there anything not working or was the only > problem the missing regmap-handling added in part1? IIRC, Linux just has regmap_i2c_init which does the correct thing for all callers. While in barebox this doesn't work and I had to add a smbus specific regmap_init. We can always consolidate this later though, so feel free to add whatever you find missing, test it and send it out for upstream inclusion. You have my Signed-off-by. > My current approach is only register the regulators without doing a real > pmic init. IO-Domain driver only needs to read out regulator voltage, i'm > not sure if it's enough to get the value from the DT or if it needs to be > really measured (to depend on complete probe/init of the pmic). > > but the problem is that iodomain is probed before the pmic due to deep-probing > if i understand Sascha the right way. So i need a way to defer the iodomain > driver > probe till rk808 is ready. The right way with deep probe enabled is to just use regulator functions normally and on first access, barebox will take care to probe the regulator if not done yet. I am not sure if all this works as expected yet, but Sascha already offered to help with that. Cheers, Ahmad > > regards Frank > > ___ > barebox mailing list > barebox@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/barebox > -- Pengutronix e.K. | | Steuerwalder Str. 21 | http://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
Aw: Re: Re: Driver load order
Hi
> Gesendet: Donnerstag, 19. Mai 2022 um 15:10 Uhr
> Von: "Sascha Hauer"
>
> I gave it a test with your rk808 driver. It just works \o/
>
> regulator_get() triggers probing of the rk808 regulator driver and
> returns a valid regulator.
Added rk808 drivers to my and added basic Kconfig/Makefile entry for mfd driver.
chip-id of my pmic is read:
rk808 rk8090: chip id: 0x8090
looks like regulators are enabled during access from my iodomain driver :)
except vccio4/5
rk_iodomain fdc2.syscon@fdc2:io-domains.of: DEBUG reg:pmuio1
(404b0450) uV:330
rk_iodomain fdc2.syscon@fdc2:io-domains.of: DEBUG reg:pmuio2
(404b0980) uV:330
rk_iodomain fdc2.syscon@fdc2:io-domains.of: DEBUG reg:vccio1
(404b0eb0) uV:90
rk_iodomain fdc2.syscon@fdc2:io-domains.of: DEBUG reg:vccio3
(4049c720) uV:330
rk_iodomain fdc2.syscon@fdc2:io-domains.of: DEBUG reg:vccio4
(4049cc50) uV:-22
rk_iodomain fdc2.syscon@fdc2:io-domains.of: DEBUG reg:vccio5
(4049a180) uV:-22
rk_iodomain fdc2.syscon@fdc2:io-domains.of: DEBUG reg:vccio6
(4049a6a8) uV:180
rk_iodomain fdc2.syscon@fdc2:io-domains.of: DEBUG reg:vccio7
(4049abd8) uV:-22
vccio 4/5 using regulator with name SWITCH_REG1, maybe this is not registered?
_io_domains {
pmuio1-supply = <_pmu>;
pmuio2-supply = <_pmu>;
vccio1-supply = <_acodec>;
vccio3-supply = <_sd>;
vccio4-supply = <_3v3>;
vccio5-supply = <_3v3>;
vccio6-supply = <_1v8>;
vccio7-supply = <_3v3>;
status = "okay";
};
regards Frank
___
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
Re: [PATCH] mci: core: add device parameter for eMMC boot ack
Hello Sascha,
On 18.05.20 09:08, Sascha Hauer wrote:
> On Wed, May 13, 2020 at 01:46:36PM +0200, Lucas Stach wrote:
>> This adds an easy way to enable the boot acknowledge function of
>> a eMMC device, without the need to frob the EXT_CSD setting via
>> the mmc_extcsd command.
>> A boot ack is required whenever the boot partitions are read via
>> the fast initialization boot protocol.
>>
>> Signed-off-by: Lucas Stach
>> ---
>> drivers/mci/mci-core.c | 33 +++--
>> include/mci.h | 2 ++
>> 2 files changed, 29 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/mci/mci-core.c b/drivers/mci/mci-core.c
>> index f3718327f18d..d33bc0c1a41e 100644
>> --- a/drivers/mci/mci-core.c
>> +++ b/drivers/mci/mci-core.c
>> @@ -516,6 +516,7 @@ static int mmc_change_freq(struct mci *mci)
>>
>> mci->ext_csd_part_config =
>> mci->ext_csd[EXT_CSD_PARTITION_CONFIG];
>> mci->bootpart = (mci->ext_csd_part_config >> 3) & 0x7;
>> +mci->boot_ack_enable = (mci->ext_csd_part_config >> 6) & 0x1;
>> }
>>
>> return 0;
>> @@ -1592,6 +1593,17 @@ static int mci_set_boot(struct param_d *param, void
>> *priv)
>>EXT_CSD_PARTITION_CONFIG, mci->ext_csd_part_config);
>> }
>>
>> +static int mci_set_boot_ack(struct param_d *param, void *priv)
>> +{
>> +struct mci *mci = priv;
>> +
>> +mci->ext_csd_part_config &= ~(0x1 << 6);
>> +mci->ext_csd_part_config |= mci->boot_ack_enable << 6;
>> +
>> +return mci_switch(mci,
>> + EXT_CSD_PARTITION_CONFIG, mci->ext_csd_part_config);
>> +}
>
> There's only one correct setting for each board or SoC. Instead of
> letting the user choose between right and wrong, can't we add a hook to
> be called from the board/SoC code? A device tree property might be an
> option as well, something like barebox,enable-boot-ack.
>
> There are also bits to change the bus width after power up which might
> need adjustments which would mean another parameter with the current
> approach.
There hasn't been any progress here for 2 years. Sascha, can we just
take this patch? Even if we add code in future to have this happen as
part of eMMC/SoC init, a device parameter to easily check
the current configuration would still be useful.
Cheers,
Ahmad
>
> Sascha
>
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
___
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
