From: Lee Jones <lee@kernel.org>
To: Stephen Boyd <swboyd@chromium.org>
Cc: Lee Jones <lee.jones@linaro.org>,
Satya Priya Kakitapalli <quic_c_skakit@quicinc.com>,
Mark Brown <broonie@kernel.org>,
Bjorn Andersson <bjorn.andersson@linaro.org>,
Rob Herring <robh+dt@kernel.org>,
Liam Girdwood <lgirdwood@gmail.com>,
linux-arm-msm@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, quic_collinsd@quicinc.com,
quic_subbaram@quicinc.com, quic_jprakash@quicinc.com
Subject: Re: [PATCH V15 6/9] mfd: pm8008: Use i2c_new_dummy_device() API
Date: Tue, 4 Oct 2022 12:41:13 +0100 [thread overview]
Message-ID: <Yzwb2e0/CK9QbV0n@google.com> (raw)
In-Reply-To: <CAE-0n53q-8u16_7KGZ0jbm9ES=dsSJL7rbGdz6hzLWf3xvm=bQ@mail.gmail.com>
On Mon, 03 Oct 2022, Stephen Boyd wrote:
> 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@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?
> >
>
> 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.
Sure, why not. I'm pretty done talking about this now. :)
Please work with Satya to cobble something together.
--
Lee Jones [李琼斯]
next prev parent reply other threads:[~2022-10-04 11:41 UTC|newest]
Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-14 9:48 [PATCH V15 0/9] Add Qualcomm Technologies, Inc. PM8008 regulator driver Satya Priya
2022-06-14 9:48 ` [PATCH V15 1/9] dt-bindings: mfd: pm8008: Add reset-gpios Satya Priya
2022-06-16 20:58 ` Lee Jones
2022-06-14 9:48 ` [PATCH V15 2/9] dt-bindings: mfd: pm8008: Change the address cells Satya Priya
2022-06-16 20:59 ` Lee Jones
2022-06-17 16:34 ` Lee Jones
2022-06-14 9:48 ` [PATCH V15 3/9] dt-bindings: mfd: pm8008: Add regulators for pm8008 Satya Priya
2022-06-16 20:58 ` Lee Jones
2022-06-14 9:48 ` [PATCH V15 4/9] mfd: pm8008: Add reset-gpios Satya Priya
2022-06-16 20:58 ` Lee Jones
2022-06-17 16:34 ` Lee Jones
2022-06-29 18:36 ` Guru Das Srinagesh
2022-06-14 9:48 ` [PATCH V15 5/9] mfd: pm8008: Remove the regmap member from pm8008_data struct Satya Priya
2022-06-16 20:58 ` Lee Jones
2022-06-29 18:35 ` Guru Das Srinagesh
2022-06-14 9:48 ` [PATCH V15 6/9] mfd: pm8008: Use i2c_new_dummy_device() API Satya Priya
2022-06-16 20:57 ` Lee Jones
2022-06-20 5:28 ` Satya Priya Kakitapalli (Temp)
2022-06-20 8:20 ` Lee Jones
2022-06-20 11:07 ` Satya Priya Kakitapalli (Temp)
2022-06-27 5:07 ` Satya Priya Kakitapalli (Temp)
2022-06-27 7:41 ` Lee Jones
2022-06-28 4:53 ` Satya Priya Kakitapalli (Temp)
2022-06-28 7:42 ` Lee Jones
2022-06-29 10:36 ` Satya Priya Kakitapalli (Temp)
2022-06-29 15:18 ` Lee Jones
2022-06-30 9:37 ` Satya Priya Kakitapalli (Temp)
2022-06-30 10:34 ` Lee Jones
2022-07-01 6:46 ` Satya Priya Kakitapalli (Temp)
2022-07-01 7:54 ` Lee Jones
2022-07-01 8:47 ` Satya Priya Kakitapalli (Temp)
2022-07-01 9:12 ` Lee Jones
[not found] ` <0481d3cc-4bb9-4969-0232-76ba57ff260d@quicinc.com>
2022-07-04 12:49 ` Lee Jones
2022-07-04 12:59 ` Satya Priya Kakitapalli (Temp)
2022-07-11 10:31 ` Satya Priya Kakitapalli (Temp)
2022-07-12 12:47 ` Lee Jones
2022-07-13 5:50 ` Satya Priya Kakitapalli (Temp)
2022-07-13 13:14 ` Mark Brown
2022-07-22 6:31 ` Satya Priya Kakitapalli (Temp)
2022-07-27 1:19 ` Stephen Boyd
[not found] ` <52039cd1-4390-7abb-d296-0eb7ac0c3b15@quicinc.com>
2022-08-05 10:51 ` Lee Jones
2022-08-08 19:09 ` Stephen Boyd
2022-08-16 3:41 ` Satya Priya Kakitapalli (Temp)
2022-09-28 10:20 ` Lee Jones
2022-09-29 1:20 ` Stephen Boyd
2022-09-29 18:01 ` Lee Jones
2022-10-03 18:47 ` Stephen Boyd
2022-10-04 11:41 ` Lee Jones [this message]
2022-06-14 9:48 ` [PATCH V15 7/9] regulator: Add a regulator driver for the PM8008 PMIC Satya Priya
2022-06-14 20:36 ` Stephen Boyd
2022-06-14 9:48 ` [PATCH V15 8/9] arm64: dts: qcom: pm8008: Add base dts file Satya Priya
2022-06-14 9:48 ` [PATCH V15 9/9] arm64: dts: qcom: sc7280: Add pm8008 support for sc7280-idp Satya Priya
2023-03-17 8:06 ` [PATCH V15 0/9] Add Qualcomm Technologies, Inc. PM8008 regulator driver Luca Weiss
2023-07-07 8:54 ` Luca Weiss
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Yzwb2e0/CK9QbV0n@google.com \
--to=lee@kernel.org \
--cc=bjorn.andersson@linaro.org \
--cc=broonie@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=lee.jones@linaro.org \
--cc=lgirdwood@gmail.com \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=quic_c_skakit@quicinc.com \
--cc=quic_collinsd@quicinc.com \
--cc=quic_jprakash@quicinc.com \
--cc=quic_subbaram@quicinc.com \
--cc=robh+dt@kernel.org \
--cc=swboyd@chromium.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).