Re: [PATCH V15 6/9] mfd: pm8008: Use i2c_new_dummy_device() API

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Quoting Lee Jones (2022-09-29 11:01:41)
> On Wed, 28 Sep 2022, Stephen Boyd wrote:
>
> > Quoting Lee Jones (2022-09-28 03:20:30)
> > > Wouldn't it make more sense to simply separate the instantiation of
> > > the 2 I2C devices?  Similar to what you suggested [0] in v9.  That way
> > > they can handle their own resources and we can avoid all of the I2C
> > > dummy / shared Regmap passing faff.
> > >
> > > [0] https://lore.kernel.org/all/CAE-0n53G-atsuwqcgNvi3nvWyiO3P=pSj5zDUMYj0ELVYJE54Q@xxxxxxxxxxxxxx/
> > >
> >
> > You can continue reading the thread[1]. My understanding is it's one
> > chip that responds on two i2c addresses, thus we don't describe that as
> > two i2c device nodes in DT. Instead we describe one node and use the
> > dummy API to make the second i2c device.
> >
> > [1] https://lore.kernel.org/all/Yk3NkNK3e+fgj4eG@xxxxxxxxxxxxx/
>
> As Mark says, it's probably 2 separate dies that have been encased in
> the same IC and are otherwise unconnected.  Not sure I understand the
> comment about not requiring another 'struct device'.  It will still
> require that whether it's a platform device or an I2C device, right?
>

Yes a 'struct device' will be required for each i2c address no matter
what happens.

It is also useful to describe the hardware as one device node in case
there is a shared reset signal or power supply. That allows us to have
one driver probe the DT node and deassert the reset/power the chip on. I
think this device has one reset signal, so we really need to do this and
not treat them as completely independent i2c devices (the 0x8 and 0x9
addresses).

Can we move forward with my plan to have another i2c device made for
'pm8008-regulators' and have that driver be an i2c driver that probes an
i2c device manually created in the pm8008 driver? I think that would
handle the reset ordering problem because the pm8008 driver can deassert
the reset and also handle the regmap passing stuff by letting the i2c
device at 0x9 make its own regmap.



[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux