[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YzXdhVN/Zp7DDIzB@google.com>
Date: Thu, 29 Sep 2022 19:01:41 +0100
From: Lee Jones <lee@...nel.org>
To: Stephen Boyd <swboyd@...omium.org>
Cc: Lee Jones <lee.jones@...aro.org>,
Satya Priya Kakitapalli <quic_c_skakit@...cinc.com>,
Mark Brown <broonie@...nel.org>,
Bjorn Andersson <bjorn.andersson@...aro.org>,
Rob Herring <robh+dt@...nel.org>,
Liam Girdwood <lgirdwood@...il.com>,
linux-arm-msm@...r.kernel.org, devicetree@...r.kernel.org,
linux-kernel@...r.kernel.org, quic_collinsd@...cinc.com,
quic_subbaram@...cinc.com, quic_jprakash@...cinc.com
Subject: Re: [PATCH V15 6/9] mfd: pm8008: Use i2c_new_dummy_device() API
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@mail.gmail.com/
> >
>
> 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@sirena.org.uk/
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?
--
Lee Jones [李琼斯]
Powered by blists - more mailing lists