Quoting Mark Brown (2022-04-06 10:27:44) > On Wed, Apr 06, 2022 at 10:21:01AM -0700, Stephen Boyd wrote: > > Quoting Mark Brown (2022-04-06 09:36:14) > > > On Wed, Apr 06, 2022 at 08:51:48AM -0700, Stephen Boyd wrote: > > > > > My guess is that this is one IC that responds to multiple i2c addresses. > > > > 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. > > > > So it's like the TI TWL4030 and Palmas - in which case it should > > > probably be handled similarly? > > > How did those work out? I wasn't involved and I don't know what you > > mean. Do they have multiple i2c addresses they respond to? > > Yes, exactly. The main device uses i2c_new_dummy_device() to > instantiate the extras when it probes. See twl-core.c Cool. That approach sounds good to me. Then the regulators can be child 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. > > > > > > Note that the original sumbission was > > > *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. > > > I'm mainly looking at the dts file now. It clearly has two i2c devices > > at 0x8 and 0x9. Maybe the regulator driver followed the mfd design > > because the first driver for this device is an mfd. > > I'm guessing from the naming that they're also externally described as > 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? I think it's regulators only. Pretty sure I asked qcom this a round or two ago on this patch series and they said that. Let's wait for Satya to respond.
