[U-Boot] Disabling CONFIG_DM_I2C_COMPAT in twl4030 PMIC

[Tom Rini]

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" ?

-- 
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/37d26c8b/attachment.sig>