[U-Boot] Disabling CONFIG_DM_I2C_COMPAT in twl4030 PMIC

[Adam Ford]

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.

adam
>
> --
> Tom