[U-Boot] Disabling CONFIG_DM_I2C_COMPAT in twl4030 PMIC

[U-Boot] Disabling CONFIG_DM_I2C_COMPAT in twl4030 PMIC

[Adam Ford]

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

[U-Boot] Disabling CONFIG_DM_I2C_COMPAT in twl4030 PMIC

[Adam Ford]

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

[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@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>

[U-Boot] Disabling CONFIG_DM_I2C_COMPAT in twl4030 PMIC

[Adam Ford]

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

[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@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!

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

[U-Boot] Disabling CONFIG_DM_I2C_COMPAT in twl4030 PMIC

[Simon Glass]

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