All of lore.kernel.org
 help / color / mirror / Atom feed
From: Conor Dooley <conor.dooley@microchip.com>
To: Julien Panis <jpanis@baylibre.com>
Cc: Conor Dooley <conor@kernel.org>,
	Kevin Hilman <khilman@kernel.org>,
	Bhargav Raviprakash <bhargav.r@ltts.com>, <arnd@arndb.de>,
	<broonie@kernel.org>, <conor+dt@kernel.org>,
	<devicetree@vger.kernel.org>, <gregkh@linuxfoundation.org>,
	<kristo@kernel.org>, <krzysztof.kozlowski+dt@linaro.org>,
	<lee@kernel.org>, <lgirdwood@gmail.com>,
	<linus.walleij@linaro.org>,
	<linux-arm-kernel@lists.infradead.org>,
	<linux-gpio@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
	<m.nirmaladevi@ltts.com>, <nm@ti.com>, <robh+dt@kernel.org>,
	<vigneshr@ti.com>
Subject: Re: [RESEND PATCH v1 03/13] dt-bindings: mfd: ti,tps6594: Add TI TPS65224 PMIC
Date: Fri, 16 Feb 2024 11:47:03 +0000	[thread overview]
Message-ID: <20240216-chimp-endowment-e4c241e8e466@wendy> (raw)
In-Reply-To: <e13627e2-9d8f-437d-afe4-d8bfcade2f6a@baylibre.com>

[-- Attachment #1: Type: text/plain, Size: 3096 bytes --]

On Fri, Feb 16, 2024 at 10:08:03AM +0100, Julien Panis wrote:
> On 2/14/24 18:45, Conor Dooley wrote:
> > On Wed, Feb 14, 2024 at 09:26:13AM -0800, Kevin Hilman wrote:
> > > Conor Dooley <conor@kernel.org> writes:
> > > > On Wed, Feb 14, 2024 at 03:01:06PM +0530, Bhargav Raviprakash wrote:
> > > > > On Fri 2/9/2024 10:41 PM, Conor Dooley wrote:
> > > > > > On Thu, Feb 08, 2024 at 04:23:33PM +0530, Bhargav Raviprakash wrote:
> > > > > > > TPS65224 is a Power Management IC with 4 Buck regulators and 3 LDO
> > > > > > > regulators, it includes additional features like GPIOs, watchdog, ESMs
> > > > > > > (Error Signal Monitor), and PFSM (Pre-configurable Finite State Machine)
> > > > > > > managing the state of the device.
> > > > > > > TPS6594 and TPS65224 have significant functional overlap.
> > > > > > What does "significant functional overlap" mean? Does one implement a
> > > > > > compatible subset of the other? I assume the answer is no, given there
> > > > > > seems to be some core looking registers at different addresses.
> > > > > The intention behind “significant functional overlap” was meant to
> > > > > indicate a lot of the features between TPS6594 and TPS65224 overlap,
> > > > > while there are some features specific to TPS65224.
> > > > > There is compatibility between the PMIC register maps, I2C, PFSM,
> > > > > and other drivers even though there are some core registers at
> > > > > different addresses.
> > > > > 
> > > > > Would it be more appropriate to say the 2 devices are compatible and have
> > > > > sufficient feature overlap rather than significant functional overlap?
> > > > If core registers are at different addresses, then it is unlikely that
> > > > these devices are compatible.
> > > That's not necessarily true.  Hardware designers can sometimes be
> > > creative. :)
> > Hence "unlikely" in my mail :)
> 
> For tps6594 and tps65224, some core registers are at different adresses
> indeed, but the code is the same for both MFD I2C/SPI entry points. As an
> example, the way CRC is enabled is exactly the same, even if the bit that
> must be set belongs to different registers. tps65224 has more resources and
> it's as if HW designers had had to re-organize the way bits are distributed
> among the registers (due to a lack of space, so to speak).
> 
> That said, if we consider that these devices are not compatible, what does it
> imply concretely for the next version ? Does that mean that:
> 1) Only a new binding must be created, even if MFD drivers and most of child
> drivers will be re-used ? (then the binding would simply be duplicated, but
> the drivers would not)
> 2) A new binding and new MFD drivers must be created, even if most of child
> drivers will be re-used ? (then the binding and MFD drivers would simply be
> duplicated, but the child drivers would not)
> 3) A new binding and new drivers (MFD and child devices) must be created ?
> 4) Anything else ?

If they're not compatible the next version of this patch does not need
to change, so option 4 I guess.



[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: Conor Dooley <conor.dooley@microchip.com>
To: Julien Panis <jpanis@baylibre.com>
Cc: Conor Dooley <conor@kernel.org>,
	Kevin Hilman <khilman@kernel.org>,
	Bhargav Raviprakash <bhargav.r@ltts.com>, <arnd@arndb.de>,
	<broonie@kernel.org>, <conor+dt@kernel.org>,
	<devicetree@vger.kernel.org>, <gregkh@linuxfoundation.org>,
	<kristo@kernel.org>, <krzysztof.kozlowski+dt@linaro.org>,
	<lee@kernel.org>, <lgirdwood@gmail.com>,
	<linus.walleij@linaro.org>,
	<linux-arm-kernel@lists.infradead.org>,
	<linux-gpio@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
	<m.nirmaladevi@ltts.com>, <nm@ti.com>, <robh+dt@kernel.org>,
	<vigneshr@ti.com>
Subject: Re: [RESEND PATCH v1 03/13] dt-bindings: mfd: ti,tps6594: Add TI TPS65224 PMIC
Date: Fri, 16 Feb 2024 11:47:03 +0000	[thread overview]
Message-ID: <20240216-chimp-endowment-e4c241e8e466@wendy> (raw)
In-Reply-To: <e13627e2-9d8f-437d-afe4-d8bfcade2f6a@baylibre.com>


[-- Attachment #1.1: Type: text/plain, Size: 3096 bytes --]

On Fri, Feb 16, 2024 at 10:08:03AM +0100, Julien Panis wrote:
> On 2/14/24 18:45, Conor Dooley wrote:
> > On Wed, Feb 14, 2024 at 09:26:13AM -0800, Kevin Hilman wrote:
> > > Conor Dooley <conor@kernel.org> writes:
> > > > On Wed, Feb 14, 2024 at 03:01:06PM +0530, Bhargav Raviprakash wrote:
> > > > > On Fri 2/9/2024 10:41 PM, Conor Dooley wrote:
> > > > > > On Thu, Feb 08, 2024 at 04:23:33PM +0530, Bhargav Raviprakash wrote:
> > > > > > > TPS65224 is a Power Management IC with 4 Buck regulators and 3 LDO
> > > > > > > regulators, it includes additional features like GPIOs, watchdog, ESMs
> > > > > > > (Error Signal Monitor), and PFSM (Pre-configurable Finite State Machine)
> > > > > > > managing the state of the device.
> > > > > > > TPS6594 and TPS65224 have significant functional overlap.
> > > > > > What does "significant functional overlap" mean? Does one implement a
> > > > > > compatible subset of the other? I assume the answer is no, given there
> > > > > > seems to be some core looking registers at different addresses.
> > > > > The intention behind “significant functional overlap” was meant to
> > > > > indicate a lot of the features between TPS6594 and TPS65224 overlap,
> > > > > while there are some features specific to TPS65224.
> > > > > There is compatibility between the PMIC register maps, I2C, PFSM,
> > > > > and other drivers even though there are some core registers at
> > > > > different addresses.
> > > > > 
> > > > > Would it be more appropriate to say the 2 devices are compatible and have
> > > > > sufficient feature overlap rather than significant functional overlap?
> > > > If core registers are at different addresses, then it is unlikely that
> > > > these devices are compatible.
> > > That's not necessarily true.  Hardware designers can sometimes be
> > > creative. :)
> > Hence "unlikely" in my mail :)
> 
> For tps6594 and tps65224, some core registers are at different adresses
> indeed, but the code is the same for both MFD I2C/SPI entry points. As an
> example, the way CRC is enabled is exactly the same, even if the bit that
> must be set belongs to different registers. tps65224 has more resources and
> it's as if HW designers had had to re-organize the way bits are distributed
> among the registers (due to a lack of space, so to speak).
> 
> That said, if we consider that these devices are not compatible, what does it
> imply concretely for the next version ? Does that mean that:
> 1) Only a new binding must be created, even if MFD drivers and most of child
> drivers will be re-used ? (then the binding would simply be duplicated, but
> the drivers would not)
> 2) A new binding and new MFD drivers must be created, even if most of child
> drivers will be re-used ? (then the binding and MFD drivers would simply be
> duplicated, but the child drivers would not)
> 3) A new binding and new drivers (MFD and child devices) must be created ?
> 4) Anything else ?

If they're not compatible the next version of this patch does not need
to change, so option 4 I guess.



[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2024-02-16 11:48 UTC|newest]

Thread overview: 58+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-08 10:53 [RESEND PATCH v1 00/13] Add support for TI TPS65224 PMIC Bhargav Raviprakash
2024-02-08 10:53 ` Bhargav Raviprakash
2024-02-08 10:53 ` [RESEND PATCH v1 01/13] mfd: tps6594: Add register definitions " Bhargav Raviprakash
2024-02-08 10:53   ` Bhargav Raviprakash
2024-02-09 17:35   ` Nishanth Menon
2024-02-09 17:35     ` Nishanth Menon
2024-02-14 12:02     ` Bhargav Raviprakash
2024-02-14 12:02       ` Bhargav Raviprakash
2024-02-08 10:53 ` [RESEND PATCH v1 02/13] mfd: tps6594: use volatile_table instead of volatile_reg Bhargav Raviprakash
2024-02-08 10:53   ` Bhargav Raviprakash
2024-02-08 10:53 ` [RESEND PATCH v1 03/13] dt-bindings: mfd: ti,tps6594: Add TI TPS65224 PMIC Bhargav Raviprakash
2024-02-08 10:53   ` Bhargav Raviprakash
2024-02-09 17:11   ` Conor Dooley
2024-02-09 17:11     ` Conor Dooley
2024-02-14  9:31     ` Bhargav Raviprakash
2024-02-14  9:31       ` Bhargav Raviprakash
2024-02-14  9:38       ` Conor Dooley
2024-02-14  9:38         ` Conor Dooley
2024-02-14 17:26         ` Kevin Hilman
2024-02-14 17:26           ` Kevin Hilman
2024-02-14 17:45           ` Conor Dooley
2024-02-14 17:45             ` Conor Dooley
2024-02-14 18:02             ` Kevin Hilman
2024-02-14 18:02               ` Kevin Hilman
2024-02-14 18:10               ` Conor Dooley
2024-02-14 18:10                 ` Conor Dooley
2024-02-16  9:08             ` Julien Panis
2024-02-16  9:08               ` Julien Panis
2024-02-16 11:47               ` Conor Dooley [this message]
2024-02-16 11:47                 ` Conor Dooley
2024-02-16 11:47   ` Conor Dooley
2024-02-16 11:47     ` Conor Dooley
2024-02-08 10:53 ` [RESEND PATCH v1 04/13] mfd: tps6594-i2c: Add TI TPS65224 PMIC I2C Bhargav Raviprakash
2024-02-08 10:53   ` Bhargav Raviprakash
2024-02-14 17:04   ` Kevin Hilman
2024-02-14 17:04     ` Kevin Hilman
2024-02-08 10:53 ` [RESEND PATCH v1 05/13] mfd: tps6594-spi: Add TI TPS65224 PMIC SPI Bhargav Raviprakash
2024-02-08 10:53   ` Bhargav Raviprakash
2024-02-14 18:10   ` Kevin Hilman
2024-02-14 18:10     ` Kevin Hilman
2024-02-22  8:43     ` Bhargav Raviprakash
2024-02-22  8:43       ` Bhargav Raviprakash
2024-02-08 10:53 ` [RESEND PATCH v1 06/13] mfd: tps6594-core: Add TI TPS65224 PMIC core Bhargav Raviprakash
2024-02-08 10:53   ` Bhargav Raviprakash
2024-02-08 10:53 ` [RESEND PATCH v1 07/13] misc: tps6594-pfsm: Add TI TPS65224 PMIC PFSM Bhargav Raviprakash
2024-02-08 10:53   ` Bhargav Raviprakash
2024-02-08 10:53 ` [RESEND PATCH v1 08/13] misc: tps6594-esm: reversion check limited to TPS6594 family Bhargav Raviprakash
2024-02-08 10:53   ` Bhargav Raviprakash
2024-02-08 10:53 ` [RESEND PATCH v1 09/13] misc: tps6594-esm: use regmap_field Bhargav Raviprakash
2024-02-08 10:53   ` Bhargav Raviprakash
2024-02-08 10:53 ` [RESEND PATCH v1 10/13] misc: tps6594-esm: Add TI TPS65224 PMIC ESM Bhargav Raviprakash
2024-02-08 10:53   ` Bhargav Raviprakash
2024-02-08 10:53 ` [RESEND PATCH v1 11/13] regulator: tps6594-regulator: Add TI TPS65224 PMIC regulators Bhargav Raviprakash
2024-02-08 10:53   ` Bhargav Raviprakash
2024-02-08 10:53 ` [RESEND PATCH v1 12/13] pinctrl: pinctrl-tps6594: Add TPS65224 PMIC pinctrl and GPIO Bhargav Raviprakash
2024-02-08 10:53   ` Bhargav Raviprakash
2024-02-08 10:53 ` [RESEND PATCH v1 13/13] arch: arm64: dts: ti: k3-am62p5-sk: Add TPS65224 PMIC support in AM62P dts Bhargav Raviprakash
2024-02-08 10:53   ` Bhargav Raviprakash

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=20240216-chimp-endowment-e4c241e8e466@wendy \
    --to=conor.dooley@microchip.com \
    --cc=arnd@arndb.de \
    --cc=bhargav.r@ltts.com \
    --cc=broonie@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=conor@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=jpanis@baylibre.com \
    --cc=khilman@kernel.org \
    --cc=kristo@kernel.org \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=lee@kernel.org \
    --cc=lgirdwood@gmail.com \
    --cc=linus.walleij@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=m.nirmaladevi@ltts.com \
    --cc=nm@ti.com \
    --cc=robh+dt@kernel.org \
    --cc=vigneshr@ti.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.