[U-Boot] Disabling CONFIG_DM_I2C_COMPAT in twl4030 PMIC
I am working to disable CONFIG_DM_I2C_COMPAT for the omap3 boards. Some of these boards use the TWL4030 PMIC which is still using the older i2c_write and i2c_read functions.
I wonder if someone can point me to a good patch that I can use a model one how to appropriately port I2C drivers forward? I'd like to disable this feature so the notice goes away since it seems like DM_I2C should be do-able by now.
thanks
adam
On Fri, Aug 17, 2018 at 10:21 PM Adam Ford aford173@gmail.com wrote:
I am working to disable CONFIG_DM_I2C_COMPAT for the omap3 boards. Some of these boards use the TWL4030 PMIC which is still using the older i2c_write and i2c_read functions.
I wonder if someone can point me to a good patch that I can use a model one how to appropriately port I2C drivers forward? I'd like to disable this feature so the notice goes away since it seems like DM_I2C should be do-able by now.
More specifically, the TWL4030 has multiple I2C addresses, but it's primary address is 0x48 and is assigned in the device tree as such. I have been able to create the primary PMIC on address 0x48, but there are multiple i2c addresses through which it can be addressed. The device tree for the twl4030 lists multuple sub-regulators, but they are not contained within 'regulators' node, and the bind function cannot locate the children because there are no regulator-names associated. The individual regulators are sub-nodes, but their control registers are not necessarily on the same i2c address of the primary. The additional i2c addresses are 0x49, 0x4a, and 0x4b, but none are listed in the device tree.
What I'd like to do is replace the stock initialization sequence with a more generic one that not only initializes the PMIC and all corresponding registers, I'd also like to have it set all the sub-regulators based on the voltage ratings listed by the device tree, I was hoping someone might teach me the 'proper' way to create these 3 additional i2c devices (not shown on the device tree) on the same I2C bus as the original, have them list all sub-regulators of the original PMIC, and be able to address them individually.
thanks
adam
thanks
adam
On Sun, Aug 19, 2018 at 09:45:30AM -0500, Adam Ford wrote:
On Fri, Aug 17, 2018 at 10:21 PM Adam Ford aford173@gmail.com wrote:
I am working to disable CONFIG_DM_I2C_COMPAT for the omap3 boards. Some of these boards use the TWL4030 PMIC which is still using the older i2c_write and i2c_read functions.
I wonder if someone can point me to a good patch that I can use a model one how to appropriately port I2C drivers forward? I'd like to disable this feature so the notice goes away since it seems like DM_I2C should be do-able by now.
More specifically, the TWL4030 has multiple I2C addresses, but it's primary address is 0x48 and is assigned in the device tree as such. I have been able to create the primary PMIC on address 0x48, but there are multiple i2c addresses through which it can be addressed. The device tree for the twl4030 lists multuple sub-regulators, but they are not contained within 'regulators' node, and the bind function cannot locate the children because there are no regulator-names associated. The individual regulators are sub-nodes, but their control registers are not necessarily on the same i2c address of the primary. The additional i2c addresses are 0x49, 0x4a, and 0x4b, but none are listed in the device tree.
What I'd like to do is replace the stock initialization sequence with a more generic one that not only initializes the PMIC and all corresponding registers, I'd also like to have it set all the sub-regulators based on the voltage ratings listed by the device tree, I was hoping someone might teach me the 'proper' way to create these 3 additional i2c devices (not shown on the device tree) on the same I2C bus as the original, have them list all sub-regulators of the original PMIC, and be able to address them individually.
So, when you refer to the device tree I assume you're talking about one that's relatively in sync with the Linux kernel and all of these devices Just Work there. So, in that case, how does Linux go from "the device tree describes $this" to "we need to bind drivers x/y/z" ?
On Sun, Aug 19, 2018 at 11:53 AM Tom Rini trini@konsulko.com wrote:
On Sun, Aug 19, 2018 at 09:45:30AM -0500, Adam Ford wrote:
On Fri, Aug 17, 2018 at 10:21 PM Adam Ford aford173@gmail.com wrote:
I am working to disable CONFIG_DM_I2C_COMPAT for the omap3 boards. Some of these boards use the TWL4030 PMIC which is still using the older i2c_write and i2c_read functions.
I wonder if someone can point me to a good patch that I can use a model one how to appropriately port I2C drivers forward? I'd like to disable this feature so the notice goes away since it seems like DM_I2C should be do-able by now.
More specifically, the TWL4030 has multiple I2C addresses, but it's primary address is 0x48 and is assigned in the device tree as such. I have been able to create the primary PMIC on address 0x48, but there are multiple i2c addresses through which it can be addressed. The device tree for the twl4030 lists multuple sub-regulators, but they are not contained within 'regulators' node, and the bind function cannot locate the children because there are no regulator-names associated. The individual regulators are sub-nodes, but their control registers are not necessarily on the same i2c address of the primary. The additional i2c addresses are 0x49, 0x4a, and 0x4b, but none are listed in the device tree.
What I'd like to do is replace the stock initialization sequence with a more generic one that not only initializes the PMIC and all corresponding registers, I'd also like to have it set all the sub-regulators based on the voltage ratings listed by the device tree, I was hoping someone might teach me the 'proper' way to create these 3 additional i2c devices (not shown on the device tree) on the same I2C bus as the original, have them list all sub-regulators of the original PMIC, and be able to address them individually.
So, when you refer to the device tree I assume you're talking about one that's relatively in sync with the Linux kernel and all of these devices Just Work there. So, in that case, how does Linux go from "the device tree describes $this" to "we need to bind drivers x/y/z" ?
From what I can tell, each regulator in the PMIC is independant to
each other. They're using .compatible = "xxx" for each regulator, and they have a bunch of macros to connect either twl4030 or 6030 to the table. They also have a helper function that associates the various i2c addresses to each regulator.
Currently, we're using CONFIG_DM_I2C_COMPAT to allow the i2c_read and i2c_write funtions to exist where part of the parameter is the pass the i2c address which is then abstracted by the twl driver.
If I create the PMIC type, the address of the PMIC is contained so all read/write functions go to 0x48 instead of 0x4b, where I want it.
I can certainly try to create completely separate regulators using the .compatible flag, but it's not clear to me how to assign the I2C address to a manually generated regulator because each regulator is a sub-node of the PMIC. It's also not clear to how to continue to associate the reulators to the PMIC.
Would it be better to just create a bunch of individual regulators? They would all share the same I2C address, and I am not sure if that's a conflict or not.
adam
-- Tom
On Sun, Aug 19, 2018 at 01:37:29PM -0500, Adam Ford wrote:
On Sun, Aug 19, 2018 at 11:53 AM Tom Rini trini@konsulko.com wrote:
On Sun, Aug 19, 2018 at 09:45:30AM -0500, Adam Ford wrote:
On Fri, Aug 17, 2018 at 10:21 PM Adam Ford aford173@gmail.com wrote:
I am working to disable CONFIG_DM_I2C_COMPAT for the omap3 boards. Some of these boards use the TWL4030 PMIC which is still using the older i2c_write and i2c_read functions.
I wonder if someone can point me to a good patch that I can use a model one how to appropriately port I2C drivers forward? I'd like to disable this feature so the notice goes away since it seems like DM_I2C should be do-able by now.
More specifically, the TWL4030 has multiple I2C addresses, but it's primary address is 0x48 and is assigned in the device tree as such. I have been able to create the primary PMIC on address 0x48, but there are multiple i2c addresses through which it can be addressed. The device tree for the twl4030 lists multuple sub-regulators, but they are not contained within 'regulators' node, and the bind function cannot locate the children because there are no regulator-names associated. The individual regulators are sub-nodes, but their control registers are not necessarily on the same i2c address of the primary. The additional i2c addresses are 0x49, 0x4a, and 0x4b, but none are listed in the device tree.
What I'd like to do is replace the stock initialization sequence with a more generic one that not only initializes the PMIC and all corresponding registers, I'd also like to have it set all the sub-regulators based on the voltage ratings listed by the device tree, I was hoping someone might teach me the 'proper' way to create these 3 additional i2c devices (not shown on the device tree) on the same I2C bus as the original, have them list all sub-regulators of the original PMIC, and be able to address them individually.
So, when you refer to the device tree I assume you're talking about one that's relatively in sync with the Linux kernel and all of these devices Just Work there. So, in that case, how does Linux go from "the device tree describes $this" to "we need to bind drivers x/y/z" ?
From what I can tell, each regulator in the PMIC is independant to each other. They're using .compatible = "xxx" for each regulator, and they have a bunch of macros to connect either twl4030 or 6030 to the table. They also have a helper function that associates the various i2c addresses to each regulator.
Currently, we're using CONFIG_DM_I2C_COMPAT to allow the i2c_read and i2c_write funtions to exist where part of the parameter is the pass the i2c address which is then abstracted by the twl driver.
If I create the PMIC type, the address of the PMIC is contained so all read/write functions go to 0x48 instead of 0x4b, where I want it.
I can certainly try to create completely separate regulators using the .compatible flag, but it's not clear to me how to assign the I2C address to a manually generated regulator because each regulator is a sub-node of the PMIC. It's also not clear to how to continue to associate the reulators to the PMIC.
Would it be better to just create a bunch of individual regulators? They would all share the same I2C address, and I am not sure if that's a conflict or not.
Simon, Jaehoon, any ideas on how to make this setup that works under Linux work here? Thanks!
Hi,
On 19 August 2018 at 17:33, Tom Rini trini@konsulko.com wrote:
On Sun, Aug 19, 2018 at 01:37:29PM -0500, Adam Ford wrote:
On Sun, Aug 19, 2018 at 11:53 AM Tom Rini trini@konsulko.com wrote:
On Sun, Aug 19, 2018 at 09:45:30AM -0500, Adam Ford wrote:
On Fri, Aug 17, 2018 at 10:21 PM Adam Ford aford173@gmail.com wrote:
I am working to disable CONFIG_DM_I2C_COMPAT for the omap3 boards. Some of these boards use the TWL4030 PMIC which is still using the older i2c_write and i2c_read functions.
I wonder if someone can point me to a good patch that I can use a model one how to appropriately port I2C drivers forward? I'd like to disable this feature so the notice goes away since it seems like DM_I2C should be do-able by now.
More specifically, the TWL4030 has multiple I2C addresses, but it's primary address is 0x48 and is assigned in the device tree as such. I have been able to create the primary PMIC on address 0x48, but there are multiple i2c addresses through which it can be addressed. The device tree for the twl4030 lists multuple sub-regulators, but they are not contained within 'regulators' node, and the bind function cannot locate the children because there are no regulator-names associated. The individual regulators are sub-nodes, but their control registers are not necessarily on the same i2c address of the primary. The additional i2c addresses are 0x49, 0x4a, and 0x4b, but none are listed in the device tree.
What I'd like to do is replace the stock initialization sequence with a more generic one that not only initializes the PMIC and all corresponding registers, I'd also like to have it set all the sub-regulators based on the voltage ratings listed by the device tree, I was hoping someone might teach me the 'proper' way to create these 3 additional i2c devices (not shown on the device tree) on the same I2C bus as the original, have them list all sub-regulators of the original PMIC, and be able to address them individually.
So, when you refer to the device tree I assume you're talking about one that's relatively in sync with the Linux kernel and all of these devices Just Work there. So, in that case, how does Linux go from "the device tree describes $this" to "we need to bind drivers x/y/z" ?
From what I can tell, each regulator in the PMIC is independant to each other. They're using .compatible = "xxx" for each regulator, and they have a bunch of macros to connect either twl4030 or 6030 to the table. They also have a helper function that associates the various i2c addresses to each regulator.
Currently, we're using CONFIG_DM_I2C_COMPAT to allow the i2c_read and i2c_write funtions to exist where part of the parameter is the pass the i2c address which is then abstracted by the twl driver.
If I create the PMIC type, the address of the PMIC is contained so all read/write functions go to 0x48 instead of 0x4b, where I want it.
I can certainly try to create completely separate regulators using the .compatible flag, but it's not clear to me how to assign the I2C address to a manually generated regulator because each regulator is a sub-node of the PMIC. It's also not clear to how to continue to associate the reulators to the PMIC.
Would it be better to just create a bunch of individual regulators? They would all share the same I2C address, and I am not sure if that's a conflict or not.
Simon, Jaehoon, any ideas on how to make this setup that works under Linux work here? Thanks!
I was not aware that we could support multiple I2C addresses with a single device. How does Linux handle that? It is particularly strange to me that the DT does not specify the addresses.
Regards, Simon
participants (3)
-
Adam Ford -
Simon Glass -
Tom Rini