[U-Boot] Disabling CONFIG_DM_I2C_COMPAT in twl4030 PMIC

Simon Glass sjg at chromium.org
Tue Aug 21 17:30:46 UTC 2018


Hi,

On 19 August 2018 at 17:33, Tom Rini <trini at 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 at 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 at 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


More information about the U-Boot mailing list