[U-Boot] Disabling CONFIG_DM_I2C_COMPAT in twl4030 PMIC

[Tom Rini]

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!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20180819/4d2000c9/attachment.sig>