Added support for TPS65224 PMIC in linux.
This patch set includes driver for core, i2c and pfsm.
The driver was tested on TI's custom AM62A EVM.

Gairuboina Sirisha (3):
  drivers: mfd: Add support for TPS65224
  drivers: mfd: Add support for TPS65224 i2c driver
  drivers: misc: Add support for TPS65224 pfsm driver

 drivers/mfd/Kconfig                |  19 +
 drivers/mfd/Makefile               |   2 +
 drivers/mfd/tps65224-core.c        | 291 ++++++++++++
 drivers/mfd/tps65224-i2c.c         | 245 ++++++++++
 drivers/misc/Kconfig               |  12 +
 drivers/misc/Makefile              |   1 +
 drivers/misc/tps65224-pfsm.c       | 290 ++++++++++++
 include/linux/mfd/tps65224.h       | 735 +++++++++++++++++++++++++++++
 include/uapi/linux/tps65224_pfsm.h |  36 ++
 9 files changed, 1631 insertions(+)
 create mode 100644 drivers/mfd/tps65224-core.c
 create mode 100644 drivers/mfd/tps65224-i2c.c
 create mode 100644 drivers/misc/tps65224-pfsm.c
 create mode 100644 include/linux/mfd/tps65224.h
 create mode 100644 include/uapi/linux/tps65224_pfsm.h

-- 
2.34.1

On 10/26/23 15:32, Gairuboina Sirisha wrote:
> Added support for TPS65224 PMIC in linux.
> This patch set includes driver for core, i2c and pfsm.
> The driver was tested on TI's custom AM62A EVM.
>
> Gairuboina Sirisha (3):
>    drivers: mfd: Add support for TPS65224
>    drivers: mfd: Add support for TPS65224 i2c driver
>    drivers: misc: Add support for TPS65224 pfsm driver
>
>   drivers/mfd/Kconfig                |  19 +
>   drivers/mfd/Makefile               |   2 +
>   drivers/mfd/tps65224-core.c        | 291 ++++++++++++
>   drivers/mfd/tps65224-i2c.c         | 245 ++++++++++
>   drivers/misc/Kconfig               |  12 +
>   drivers/misc/Makefile              |   1 +
>   drivers/misc/tps65224-pfsm.c       | 290 ++++++++++++
>   include/linux/mfd/tps65224.h       | 735 +++++++++++++++++++++++++++++
>   include/uapi/linux/tps65224_pfsm.h |  36 ++
>   9 files changed, 1631 insertions(+)
>   create mode 100644 drivers/mfd/tps65224-core.c
>   create mode 100644 drivers/mfd/tps65224-i2c.c
>   create mode 100644 drivers/misc/tps65224-pfsm.c
>   create mode 100644 include/linux/mfd/tps65224.h
>   create mode 100644 include/uapi/linux/tps65224_pfsm.h

Hi Sirisha,

These drivers strongly look like TPS6594 drivers.

Instead of submitting new drivers, you should consider reusing and
modifying the existing ones for TPS6594. You might add your new 'compatible'
entry ("ti,tps65224-q1") in TPS6594 dt-bindings (see 'ti,tps6594.yaml' file)
to identify your TPS65224 PMIC. This new 'compatible' would also be added
in the existing 'tps6594_i2c_of_match_table'. You can have a look at
'tps->chip_id' in 'tps6594-core.c' and see how we use it to deal with slight
differences between different PMIC IDs.

Julien

From: Gairuboina Sirisha <sirisha.gairuboina@ltts.com>

> On 10/26/23 15:32, Gairuboina Sirisha wrote:
> > Added support for TPS65224 PMIC in linux.
> > This patch set includes driver for core, i2c and pfsm.
> > The driver was tested on TI's custom AM62A EVM.
> >
> > Gairuboina Sirisha (3):
> >    drivers: mfd: Add support for TPS65224
> >    drivers: mfd: Add support for TPS65224 i2c driver
> >    drivers: misc: Add support for TPS65224 pfsm driver
> >
> >   drivers/mfd/Kconfig                |  19 +
> >   drivers/mfd/Makefile               |   2 +
> >   drivers/mfd/tps65224-core.c        | 291 ++++++++++++
> >   drivers/mfd/tps65224-i2c.c         | 245 ++++++++++
> >   drivers/misc/Kconfig               |  12 +
> >   drivers/misc/Makefile              |   1 +
> >   drivers/misc/tps65224-pfsm.c       | 290 ++++++++++++
> >   include/linux/mfd/tps65224.h       | 735 +++++++++++++++++++++++++++++
> >   include/uapi/linux/tps65224_pfsm.h |  36 ++
> >   9 files changed, 1631 insertions(+)
> >   create mode 100644 drivers/mfd/tps65224-core.c
> >   create mode 100644 drivers/mfd/tps65224-i2c.c
> >   create mode 100644 drivers/misc/tps65224-pfsm.c
> >   create mode 100644 include/linux/mfd/tps65224.h
> >   create mode 100644 include/uapi/linux/tps65224_pfsm.h
>
> Hi Sirisha,
>
> These drivers strongly look like TPS6594 drivers.
>
> Instead of submitting new drivers, you should consider reusing and
> modifying the existing ones for TPS6594. You might add your new 'compatible'
> entry ("ti,tps65224-q1") in TPS6594 dt-bindings (see 'ti,tps6594.yaml' file)
> to identify your TPS65224 PMIC. This new 'compatible' would also be added
> in the existing 'tps6594_i2c_of_match_table'. You can have a look at
> 'tps->chip_id' in 'tps6594-core.c' and see how we use it to deal with slight
> differences between different PMIC IDs.

Thanks for the response. While the TPS65224 drivers follow the format and
structure of TPS6594, the register maps, masks, and ADC feature differ.
The two PMICs have overlapping features but TPS65224 is not treated as a subset.
TPS65224 is treated as a separate and independent driver instead of adding
compatibility to the existing TPS6594 driver that would then support 3 PMICS.
This separation will better support our differing PMICs.

Thanks & Regards,
Sirisha G.

On 11/7/23 12:37, Gairuboina Sirisha wrote:
> From: Gairuboina Sirisha <sirisha.gairuboina@ltts.com>
>
>> On 10/26/23 15:32, Gairuboina Sirisha wrote:
>>> Added support for TPS65224 PMIC in linux.
>>> This patch set includes driver for core, i2c and pfsm.
>>> The driver was tested on TI's custom AM62A EVM.
>>>
>>> Gairuboina Sirisha (3):
>>>     drivers: mfd: Add support for TPS65224
>>>     drivers: mfd: Add support for TPS65224 i2c driver
>>>     drivers: misc: Add support for TPS65224 pfsm driver
>>>
>>>    drivers/mfd/Kconfig                |  19 +
>>>    drivers/mfd/Makefile               |   2 +
>>>    drivers/mfd/tps65224-core.c        | 291 ++++++++++++
>>>    drivers/mfd/tps65224-i2c.c         | 245 ++++++++++
>>>    drivers/misc/Kconfig               |  12 +
>>>    drivers/misc/Makefile              |   1 +
>>>    drivers/misc/tps65224-pfsm.c       | 290 ++++++++++++
>>>    include/linux/mfd/tps65224.h       | 735 +++++++++++++++++++++++++++++
>>>    include/uapi/linux/tps65224_pfsm.h |  36 ++
>>>    9 files changed, 1631 insertions(+)
>>>    create mode 100644 drivers/mfd/tps65224-core.c
>>>    create mode 100644 drivers/mfd/tps65224-i2c.c
>>>    create mode 100644 drivers/misc/tps65224-pfsm.c
>>>    create mode 100644 include/linux/mfd/tps65224.h
>>>    create mode 100644 include/uapi/linux/tps65224_pfsm.h
>> Hi Sirisha,
>>
>> These drivers strongly look like TPS6594 drivers.
>>
>> Instead of submitting new drivers, you should consider reusing and
>> modifying the existing ones for TPS6594. You might add your new 'compatible'
>> entry ("ti,tps65224-q1") in TPS6594 dt-bindings (see 'ti,tps6594.yaml' file)
>> to identify your TPS65224 PMIC. This new 'compatible' would also be added
>> in the existing 'tps6594_i2c_of_match_table'. You can have a look at
>> 'tps->chip_id' in 'tps6594-core.c' and see how we use it to deal with slight
>> differences between different PMIC IDs.
> Thanks for the response. While the TPS65224 drivers follow the format and
> structure of TPS6594, the register maps, masks, and ADC feature differ.
> The two PMICs have overlapping features but TPS65224 is not treated as a subset.
> TPS65224 is treated as a separate and independent driver instead of adding
> compatibility to the existing TPS6594 driver that would then support 3 PMICS.
> This separation will better support our differing PMICs.
>
> Thanks & Regards,
> Sirisha G.

I compared 'tps65224.h' with 'tps6594.h', especially register mapping.
There are less resources in TPS65224, but I don't see any incompatibility
between both PMIC register mappings. Some registers are not used by
your TPS65224, and some interrupts are not used either (that's not a
problem, they will not trigger, so). Beyond that, I2C and PFSM drivers
perform the same things for both PMICs. That's why according to me,
nothing prevents from re-using TPS6594 drivers. Even for ADC, which is
specific to your TPS65224 indeed, the register range does not overlap
with any of TPS6594 registers. You could conditionally add this driver
(that's what we did in  'tps6594-core.c' for RTC driver, which is not used
for one of the compatibles: you can do something similar for ADC).
You will probably add support for others TPS65224 drivers over the next
weeks: SPI, ESM, RTC, GPIOs, regulators, watchdog, and ADC. Most of them
should be compatible with both TPS6594 and TPS65224, I think (even
watchdog driver, which was not developed for TPS6594). ADC will not,
but as explained above you can easily deal with this one thanks to
the compatible.
For 'tps65224-core.c' only, a little bit of work might be necessary to
handle your TPS65224 specific functionalities. By using a different DT
compatible string, your driver can then select different options (or maybe
even different register ranges) for some features based on the compatible.
But except for 'tps65xx-core.c', there is "sufficient overlap" to justify
sharing as much as possible between TPS65224 and TPS6594, in my
opinion.

Hi Julien,

On 11/8/2023 3:19 AM, Julien Panis wrote:
> On 11/7/23 12:37, Gairuboina Sirisha wrote:
>> From: Gairuboina Sirisha <sirisha.gairuboina@ltts.com>
>>
>>> On 10/26/23 15:32, Gairuboina Sirisha wrote:
>>>> Added support for TPS65224 PMIC in linux.
>>>> This patch set includes driver for core, i2c and pfsm.
>>>> The driver was tested on TI's custom AM62A EVM.
>>>>
>>>> Gairuboina Sirisha (3):
>>>>     drivers: mfd: Add support for TPS65224
>>>>     drivers: mfd: Add support for TPS65224 i2c driver
>>>>     drivers: misc: Add support for TPS65224 pfsm driver
>>>>
>>>>    drivers/mfd/Kconfig                |  19 +
>>>>    drivers/mfd/Makefile               |   2 +
>>>>    drivers/mfd/tps65224-core.c        | 291 ++++++++++++
>>>>    drivers/mfd/tps65224-i2c.c         | 245 ++++++++++
>>>>    drivers/misc/Kconfig               |  12 +
>>>>    drivers/misc/Makefile              |   1 +
>>>>    drivers/misc/tps65224-pfsm.c       | 290 ++++++++++++
>>>>    include/linux/mfd/tps65224.h       | 735 
>>>> +++++++++++++++++++++++++++++
>>>>    include/uapi/linux/tps65224_pfsm.h |  36 ++
>>>>    9 files changed, 1631 insertions(+)
>>>>    create mode 100644 drivers/mfd/tps65224-core.c
>>>>    create mode 100644 drivers/mfd/tps65224-i2c.c
>>>>    create mode 100644 drivers/misc/tps65224-pfsm.c
>>>>    create mode 100644 include/linux/mfd/tps65224.h
>>>>    create mode 100644 include/uapi/linux/tps65224_pfsm.h
>>> Hi Sirisha,
>>>
>>> These drivers strongly look like TPS6594 drivers.
>>>
>>> Instead of submitting new drivers, you should consider reusing and
>>> modifying the existing ones for TPS6594. You might add your new 
>>> 'compatible'
>>> entry ("ti,tps65224-q1") in TPS6594 dt-bindings (see 
>>> 'ti,tps6594.yaml' file)
>>> to identify your TPS65224 PMIC. This new 'compatible' would also be 
>>> added
>>> in the existing 'tps6594_i2c_of_match_table'. You can have a look at
>>> 'tps->chip_id' in 'tps6594-core.c' and see how we use it to deal 
>>> with slight
>>> differences between different PMIC IDs.
>> Thanks for the response. While the TPS65224 drivers follow the format 
>> and
>> structure of TPS6594, the register maps, masks, and ADC feature differ.
>> The two PMICs have overlapping features but TPS65224 is not treated 
>> as a subset.
>> TPS65224 is treated as a separate and independent driver instead of 
>> adding
>> compatibility to the existing TPS6594 driver that would then support 
>> 3 PMICS.
>> This separation will better support our differing PMICs.
>>
>> Thanks & Regards,
>> Sirisha G.
>
> I compared 'tps65224.h' with 'tps6594.h', especially register mapping.
> There are less resources in TPS65224, but I don't see any incompatibility
> between both PMIC register mappings. Some registers are not used by
> your TPS65224, and some interrupts are not used either (that's not a
> problem, they will not trigger, so). Beyond that, I2C and PFSM drivers
> perform the same things for both PMICs. That's why according to me,
> nothing prevents from re-using TPS6594 drivers. Even for ADC, which is
> specific to your TPS65224 indeed, the register range does not overlap
> with any of TPS6594 registers. You could conditionally add this driver
> (that's what we did in  'tps6594-core.c' for RTC driver, which is not 
> used
> for one of the compatibles: you can do something similar for ADC).
> You will probably add support for others TPS65224 drivers over the next
> weeks: SPI, ESM, RTC, GPIOs, regulators, watchdog, and ADC. Most of them
> should be compatible with both TPS6594 and TPS65224, I think (even
> watchdog driver, which was not developed for TPS6594). ADC will not,
> but as explained above you can easily deal with this one thanks to
> the compatible.
> For 'tps65224-core.c' only, a little bit of work might be necessary to
> handle your TPS65224 specific functionalities. By using a different DT
> compatible string, your driver can then select different options (or 
> maybe
> even different register ranges) for some features based on the 
> compatible.
> But except for 'tps65xx-core.c', there is "sufficient overlap" to justify
> sharing as much as possible between TPS65224 and TPS6594, in my
> opinion.


TI is positioning TPS65224 as a separate family from TPS6594, but shared 
software drivers for PMICs that have different use cases would lead to 
confusion. Re-scoping the project to accommodate these suggestions would 
negatively affect the timeline we are trying to meet. We want to include 
the restructure that addresses the compatibility, register maps, and 
functionality similarities, but it would best solved after the upcoming 
deadline has been met. With the growth of PMIC software device drivers, 
we would prefer to have a separate series with the suggested changes and 
proper naming convention to address that while they overlap, the two 
PMICs devices are not a subset.


Best,

Shree Ramamoorthy

On Thu, Nov 09, 2023 at 10:22:00AM -0600, Shree Ramamoorthy wrote:
> > I compared 'tps65224.h' with 'tps6594.h', especially register mapping.
> > There are less resources in TPS65224, but I don't see any incompatibility
> > between both PMIC register mappings. Some registers are not used by
> > your TPS65224, and some interrupts are not used either (that's not a
> > problem, they will not trigger, so). Beyond that, I2C and PFSM drivers
> > perform the same things for both PMICs. That's why according to me,
> > nothing prevents from re-using TPS6594 drivers. Even for ADC, which is
> > specific to your TPS65224 indeed, the register range does not overlap
> > with any of TPS6594 registers. You could conditionally add this driver
> > (that's what we did in  'tps6594-core.c' for RTC driver, which is not
> > used
> > for one of the compatibles: you can do something similar for ADC).
> > You will probably add support for others TPS65224 drivers over the next
> > weeks: SPI, ESM, RTC, GPIOs, regulators, watchdog, and ADC. Most of them
> > should be compatible with both TPS6594 and TPS65224, I think (even
> > watchdog driver, which was not developed for TPS6594). ADC will not,
> > but as explained above you can easily deal with this one thanks to
> > the compatible.
> > For 'tps65224-core.c' only, a little bit of work might be necessary to
> > handle your TPS65224 specific functionalities. By using a different DT
> > compatible string, your driver can then select different options (or
> > maybe
> > even different register ranges) for some features based on the
> > compatible.
> > But except for 'tps65xx-core.c', there is "sufficient overlap" to justify
> > sharing as much as possible between TPS65224 and TPS6594, in my
> > opinion.
> 
> 
> TI is positioning TPS65224 as a separate family from TPS6594, but shared
> software drivers for PMICs that have different use cases would lead to
> confusion.

Why?  No one cares what a driver's name is, only that it works for their
hardware.  What different "use case" would cause problems here?

> Re-scoping the project to accommodate these suggestions would
> negatively affect the timeline we are trying to meet.

There are no timelines/deadlines with kernel development, sorry, that's
not our issue.

> We want to include the
> restructure that addresses the compatibility, register maps, and
> functionality similarities, but it would best solved after the upcoming
> deadline has been met.

Again, no deadline here.  Please do the work properly, that's all we
care about.

> With the growth of PMIC software device drivers, we
> would prefer to have a separate series with the suggested changes and proper
> naming convention to address that while they overlap, the two PMICs devices
> are not a subset.

Why does the name matter?  Again, all that a user cares about is if
their hardware device is supported, the name means nothing here.

Please do the correct thing and add support for this device to the
existing drivers, that's the correct thing to do.  You will save time
and energy and code in the long-run, which is the important thing.

There is a reason that Linux drivers are, on average, 1/3 smaller than
other operating systems.  And that's because they share common code with
other drivers.  You aren't allowed to just copy an existing one and add
a few changes and make a whole new driver, you need to modify the
current one.

thanks,

greg k-h

On Fri, 10 Nov 2023, Greg KH wrote:

> On Thu, Nov 09, 2023 at 10:22:00AM -0600, Shree Ramamoorthy wrote:
> > > I compared 'tps65224.h' with 'tps6594.h', especially register mapping.
> > > There are less resources in TPS65224, but I don't see any incompatibility
> > > between both PMIC register mappings. Some registers are not used by
> > > your TPS65224, and some interrupts are not used either (that's not a
> > > problem, they will not trigger, so). Beyond that, I2C and PFSM drivers
> > > perform the same things for both PMICs. That's why according to me,
> > > nothing prevents from re-using TPS6594 drivers. Even for ADC, which is
> > > specific to your TPS65224 indeed, the register range does not overlap
> > > with any of TPS6594 registers. You could conditionally add this driver
> > > (that's what we did in  'tps6594-core.c' for RTC driver, which is not
> > > used
> > > for one of the compatibles: you can do something similar for ADC).
> > > You will probably add support for others TPS65224 drivers over the next
> > > weeks: SPI, ESM, RTC, GPIOs, regulators, watchdog, and ADC. Most of them
> > > should be compatible with both TPS6594 and TPS65224, I think (even
> > > watchdog driver, which was not developed for TPS6594). ADC will not,
> > > but as explained above you can easily deal with this one thanks to
> > > the compatible.
> > > For 'tps65224-core.c' only, a little bit of work might be necessary to
> > > handle your TPS65224 specific functionalities. By using a different DT
> > > compatible string, your driver can then select different options (or
> > > maybe
> > > even different register ranges) for some features based on the
> > > compatible.
> > > But except for 'tps65xx-core.c', there is "sufficient overlap" to justify
> > > sharing as much as possible between TPS65224 and TPS6594, in my
> > > opinion.
> > 
> > 
> > TI is positioning TPS65224 as a separate family from TPS6594, but shared
> > software drivers for PMICs that have different use cases would lead to
> > confusion.
> 
> Why?  No one cares what a driver's name is, only that it works for their
> hardware.  What different "use case" would cause problems here?
> 
> > Re-scoping the project to accommodate these suggestions would
> > negatively affect the timeline we are trying to meet.
> 
> There are no timelines/deadlines with kernel development, sorry, that's
> not our issue.
> 
> > We want to include the
> > restructure that addresses the compatibility, register maps, and
> > functionality similarities, but it would best solved after the upcoming
> > deadline has been met.
> 
> Again, no deadline here.  Please do the work properly, that's all we
> care about.
> 
> > With the growth of PMIC software device drivers, we
> > would prefer to have a separate series with the suggested changes and proper
> > naming convention to address that while they overlap, the two PMICs devices
> > are not a subset.
> 
> Why does the name matter?  Again, all that a user cares about is if
> their hardware device is supported, the name means nothing here.
> 
> Please do the correct thing and add support for this device to the
> existing drivers, that's the correct thing to do.  You will save time
> and energy and code in the long-run, which is the important thing.
> 
> There is a reason that Linux drivers are, on average, 1/3 smaller than
> other operating systems.  And that's because they share common code with
> other drivers.  You aren't allowed to just copy an existing one and add
> a few changes and make a whole new driver, you need to modify the
> current one.
> 
> thanks,
> 
> greg k-h

Ha!  You took the words right out of my mouth!

Thanks.

-- 
Lee Jones [李琼斯]

Hi Greg,

On 11/9/2023 10:26 PM, Greg KH wrote:
> On Thu, Nov 09, 2023 at 10:22:00AM -0600, Shree Ramamoorthy wrote:
>>> I compared 'tps65224.h' with 'tps6594.h', especially register mapping.
>>> There are less resources in TPS65224, but I don't see any incompatibility
>>> between both PMIC register mappings. Some registers are not used by
>>> your TPS65224, and some interrupts are not used either (that's not a
>>> problem, they will not trigger, so). Beyond that, I2C and PFSM drivers
>>> perform the same things for both PMICs. That's why according to me,
>>> nothing prevents from re-using TPS6594 drivers. Even for ADC, which is
>>> specific to your TPS65224 indeed, the register range does not overlap
>>> with any of TPS6594 registers. You could conditionally add this driver
>>> (that's what we did in  'tps6594-core.c' for RTC driver, which is not
>>> used
>>> for one of the compatibles: you can do something similar for ADC).
>>> You will probably add support for others TPS65224 drivers over the next
>>> weeks: SPI, ESM, RTC, GPIOs, regulators, watchdog, and ADC. Most of them
>>> should be compatible with both TPS6594 and TPS65224, I think (even
>>> watchdog driver, which was not developed for TPS6594). ADC will not,
>>> but as explained above you can easily deal with this one thanks to
>>> the compatible.
>>> For 'tps65224-core.c' only, a little bit of work might be necessary to
>>> handle your TPS65224 specific functionalities. By using a different DT
>>> compatible string, your driver can then select different options (or
>>> maybe
>>> even different register ranges) for some features based on the
>>> compatible.
>>> But except for 'tps65xx-core.c', there is "sufficient overlap" to justify
>>> sharing as much as possible between TPS65224 and TPS6594, in my
>>> opinion.
>>
>> TI is positioning TPS65224 as a separate family from TPS6594, but shared
>> software drivers for PMICs that have different use cases would lead to
>> confusion.
> Why?  No one cares what a driver's name is, only that it works for their
> hardware.  What different "use case" would cause problems here?
>
>> Re-scoping the project to accommodate these suggestions would
>> negatively affect the timeline we are trying to meet.
> There are no timelines/deadlines with kernel development, sorry, that's
> not our issue.
>
>> We want to include the
>> restructure that addresses the compatibility, register maps, and
>> functionality similarities, but it would best solved after the upcoming
>> deadline has been met.
> Again, no deadline here.  Please do the work properly, that's all we
> care about.
>
>> With the growth of PMIC software device drivers, we
>> would prefer to have a separate series with the suggested changes and proper
>> naming convention to address that while they overlap, the two PMICs devices
>> are not a subset.
> Why does the name matter?  Again, all that a user cares about is if
> their hardware device is supported, the name means nothing here.
>
> Please do the correct thing and add support for this device to the
> existing drivers, that's the correct thing to do.  You will save time
> and energy and code in the long-run, which is the important thing.
>
> There is a reason that Linux drivers are, on average, 1/3 smaller than
> other operating systems.  And that's because they share common code with
> other drivers.  You aren't allowed to just copy an existing one and add
> a few changes and make a whole new driver, you need to modify the
> current one.
>
> thanks,
>
> greg k-h


Those are all fair points to ensure minimal code repetition. It’s the right decision
long term, and we’ll do what is necessary to address this. We're working with
the 3rd party to accommodate all suggestions to ensure best software practices.

  

Thank you!

Shree Ramamoorthy