Quoting Mark Brown (2022-04-06 10:27:44)
On Wed, Apr 06, 2022 at 10:21:01AM -0700, Stephen Boyd wrote:Cool. That approach sounds good to me. Then the regulators can be child
Quoting Mark Brown (2022-04-06 09:36:14)Yes, exactly. The main device uses i2c_new_dummy_device() to
On Wed, Apr 06, 2022 at 08:51:48AM -0700, Stephen Boyd wrote:How did those work out? I wasn't involved and I don't know what you
My guess is that this is one IC that responds to multiple i2c addresses.So it's like the TI TWL4030 and Palmas - in which case it should
The "main" qcom,pm8008 address is 0x8 and that supports things like
interrupts. Then there's an address for regulators at 0x9 which controls
the handful of LDOs on the PMIC.
probably be handled similarly?
mean. Do they have multiple i2c addresses they respond to?
instantiate the extras when it probes. See twl-core.c
nodes of the qcom,pm8008 node at i2c address 0x8? It still feels like
making a struct driver for each regulator node is overkill and will
waste memory.
I think it's regulators only. Pretty sure I asked qcom this a round orI'm guessing from the naming that they're also externally described asNote that the original sumbission wasI'm mainly looking at the dts file now. It clearly has two i2c devices
*also* a MFD subfunction, but using a DT compatible to match the
platform device - this is the first I've heard of this being a separate
I2C function.
at 0x8 and 0x9. Maybe the regulator driver followed the mfd design
because the first driver for this device is an mfd.
the same device - presumably it's two dies shoved together in the same
package for some reason without being otherwise joined up. Is the
second device geniunely regulators only or does it have anything else
bundled in there?
two ago on this patch series and they said that. Let's wait for Satya to
respond.