drivers/gpio/gpio-tps65219.c | 123 +++++++++++++++++++++++++++++------ 1 file changed, 104 insertions(+), 19 deletions(-)
The related MFD series was integrated in mainline during 6.15 cycle [0]. TPS65214 is a Power Management Integrated Circuit (PMIC) that has significant register map overlap with TPS65219. The series introduces TPS65214 and restructures the existing driver to support multiple devices. TPS65215's GPIO specs are the same as TPS65219, so the "tps65219-gpio" compatible string is assigned to two devices in the TPS65219 MFD driver. No additional support is required in the GPIO driver for TPS65215. - TPS65214 has 1 GPIO & 1 GPO, whereas TPS65219/TPS65215 both have 1 GPIO & 2 GPOs. - TPS65214' GPIO direction can be changed with register GENERAL_CONFIG and bit GPIO_CONFIG during device operation. - TPS65219's MULTI_DEVICE_ENABLE bit in register MFP_1_CFG maps to TPS65214's GPIO_VSEL_CONFIG bit. TPS65214 Datasheet: https://www.ti.com/lit/gpn/TPS65214 TPS65214 TRM: https://www.ti.com/lit/pdf/slvud30 TPS65215 TRM: https://www.ti.com/lit/pdf/slvucw5/ Tested on Jon Cormier's AM62x platform with TPS65219. GPIO offsets remained consistent and functional. Signed-off-by: Shree Ramamoorthy <s-ramamoorthy@ti.com> Tested-by: Jonathan Cormier <jcormier@criticallink.com> --- Change Log: v6 -> v7: - Update _set() to return an int because of set_rv() variant - Fix comment format - Consolidate dev_err call to one line - Remove unused variable (dev) from tps65219_gpio_set v5 -> v6: - Add Jon Cormier Reviewed-by and Tested-by tags - Add test info from Jon C. to cover letter - Change copyright to include 2022 & 2025 - Use set_rv() variant instead of deprecated set() v4 -> v5: - Consolidate from 3 to 2 patches - Add specific TPS65215 info to Patch 1 comments + commit message - Remove chip_data struct - Add separate dev-specific template_chip structs - Add dev-specific change_direction functions + assignment in probe - Add PMIC GPIO mapping explanation in comments for future users - Add TPS65214 GPIO0 direction mask macro - Rename _GPIO0_OFFSET in patch 1, in addition to _IDX macro - Update cover letter + add TPS65214 datasheet link v3 -> v4: - Update cover letter - Rebase for 6.16 cycle v2 -> v3: - Correct gpio_chip.ngpio line to use .offset field - Remove unnecessary newlines v1 -> v2: - have any PMIC lists be in alpha-numeric order: TPS65215, then TPS65219 - remove comma after terminator - Add driver prefix to chip_data struct --- [0]: https://lore.kernel.org/all/173928615760.2233464.12306998726512431222.b4-ty@kernel.org/ Shree Ramamoorthy (2): gpio: tps65219: Update _IDX & _OFFSET macro prefix gpio: tps65219: Add support for TI TPS65214 PMIC drivers/gpio/gpio-tps65219.c | 123 +++++++++++++++++++++++++++++------ 1 file changed, 104 insertions(+), 19 deletions(-) -- 2.43.0
On Tue, Jul 22, 2025 at 1:32 AM Shree Ramamoorthy <s-ramamoorthy@ti.com> wrote: > > The related MFD series was integrated in mainline during 6.15 cycle [0]. > > TPS65214 is a Power Management Integrated Circuit (PMIC) that has > significant register map overlap with TPS65219. The series introduces > TPS65214 and restructures the existing driver to support multiple devices. > > TPS65215's GPIO specs are the same as TPS65219, so the "tps65219-gpio" > compatible string is assigned to two devices in the TPS65219 MFD driver. > No additional support is required in the GPIO driver for TPS65215. > > - TPS65214 has 1 GPIO & 1 GPO, whereas TPS65219/TPS65215 both have 1 GPIO & > 2 GPOs. > - TPS65214' GPIO direction can be changed with register GENERAL_CONFIG and > bit GPIO_CONFIG during device operation. > - TPS65219's MULTI_DEVICE_ENABLE bit in register MFP_1_CFG maps to > TPS65214's GPIO_VSEL_CONFIG bit. > > TPS65214 Datasheet: https://www.ti.com/lit/gpn/TPS65214 > TPS65214 TRM: https://www.ti.com/lit/pdf/slvud30 > TPS65215 TRM: https://www.ti.com/lit/pdf/slvucw5/ > > Tested on Jon Cormier's AM62x platform with TPS65219. > GPIO offsets remained consistent and functional. > > Signed-off-by: Shree Ramamoorthy <s-ramamoorthy@ti.com> > Tested-by: Jonathan Cormier <jcormier@criticallink.com> > --- This doesn't apply on top of my gpio/for-next branch. Do you think you can quickly submit another iteration rebased on top of it? Bartosz
On 7/22/2025 7:33 AM, Bartosz Golaszewski wrote: > On Tue, Jul 22, 2025 at 1:32 AM Shree Ramamoorthy <s-ramamoorthy@ti.com> wrote: >> The related MFD series was integrated in mainline during 6.15 cycle [0]. >> >> TPS65214 is a Power Management Integrated Circuit (PMIC) that has >> significant register map overlap with TPS65219. The series introduces >> TPS65214 and restructures the existing driver to support multiple devices. >> >> TPS65215's GPIO specs are the same as TPS65219, so the "tps65219-gpio" >> compatible string is assigned to two devices in the TPS65219 MFD driver. >> No additional support is required in the GPIO driver for TPS65215. >> >> - TPS65214 has 1 GPIO & 1 GPO, whereas TPS65219/TPS65215 both have 1 GPIO & >> 2 GPOs. >> - TPS65214' GPIO direction can be changed with register GENERAL_CONFIG and >> bit GPIO_CONFIG during device operation. >> - TPS65219's MULTI_DEVICE_ENABLE bit in register MFP_1_CFG maps to >> TPS65214's GPIO_VSEL_CONFIG bit. >> >> TPS65214 Datasheet: https://www.ti.com/lit/gpn/TPS65214 >> TPS65214 TRM: https://www.ti.com/lit/pdf/slvud30 >> TPS65215 TRM: https://www.ti.com/lit/pdf/slvucw5/ >> >> Tested on Jon Cormier's AM62x platform with TPS65219. >> GPIO offsets remained consistent and functional. >> >> Signed-off-by: Shree Ramamoorthy <s-ramamoorthy@ti.com> >> Tested-by: Jonathan Cormier <jcormier@criticallink.com> >> --- > This doesn't apply on top of my gpio/for-next branch. Do you think you > can quickly submit another iteration rebased on top of it? Will rebase and re-submit! Would I send it as v7 RESUBMIT or v8? > > Bartosz
On Tue, Jul 22, 2025 at 8:33 AM Bartosz Golaszewski <brgl@bgdev.pl> wrote: > > On Tue, Jul 22, 2025 at 1:32 AM Shree Ramamoorthy <s-ramamoorthy@ti.com> wrote: > > > > The related MFD series was integrated in mainline during 6.15 cycle [0]. > > > > TPS65214 is a Power Management Integrated Circuit (PMIC) that has > > significant register map overlap with TPS65219. The series introduces > > TPS65214 and restructures the existing driver to support multiple devices. > > > > TPS65215's GPIO specs are the same as TPS65219, so the "tps65219-gpio" > > compatible string is assigned to two devices in the TPS65219 MFD driver. > > No additional support is required in the GPIO driver for TPS65215. > > > > - TPS65214 has 1 GPIO & 1 GPO, whereas TPS65219/TPS65215 both have 1 GPIO & > > 2 GPOs. > > - TPS65214' GPIO direction can be changed with register GENERAL_CONFIG and > > bit GPIO_CONFIG during device operation. > > - TPS65219's MULTI_DEVICE_ENABLE bit in register MFP_1_CFG maps to > > TPS65214's GPIO_VSEL_CONFIG bit. > > > > TPS65214 Datasheet: https://www.ti.com/lit/gpn/TPS65214 > > TPS65214 TRM: https://www.ti.com/lit/pdf/slvud30 > > TPS65215 TRM: https://www.ti.com/lit/pdf/slvucw5/ > > > > Tested on Jon Cormier's AM62x platform with TPS65219. > > GPIO offsets remained consistent and functional. > > > > Signed-off-by: Shree Ramamoorthy <s-ramamoorthy@ti.com> > > Tested-by: Jonathan Cormier <jcormier@criticallink.com> > > --- > > This doesn't apply on top of my gpio/for-next branch. Do you think you > can quickly submit another iteration rebased on top of it? Maybe this is a basic question but is there a rule of thumb for where to base patches to be submitted to the mailing lists? I've generally been basing them off the latest tag in linux-stable/master. I suppose this might be one of those it depends on the subsystem things? > > Bartosz -- Jonathan Cormier Senior Software Engineer Voice: 315.425.4045 x222 http://www.CriticalLink.com 6712 Brooklawn Parkway, Syracuse, NY 13211
On Tue, Jul 22, 2025 at 4:16 PM Jon Cormier <jcormier@criticallink.com> wrote: > > > > This doesn't apply on top of my gpio/for-next branch. Do you think you > > can quickly submit another iteration rebased on top of it? > Maybe this is a basic question but is there a rule of thumb for where > to base patches to be submitted to the mailing lists? I've generally > been basing them off the latest tag in linux-stable/master. I suppose > this might be one of those it depends on the subsystem things? > > I feed my tree into linux next, so generally using linux-next/master would be your best bet. The rule of thumb typically is checking the subsystem's git tree in MAINTAINERS and using whatever branch goes into the next release. Bartosz
On Tue, Jul 22, 2025 at 10:31 AM Bartosz Golaszewski <brgl@bgdev.pl> wrote: > > On Tue, Jul 22, 2025 at 4:16 PM Jon Cormier <jcormier@criticallink.com> wrote: > > > > > > This doesn't apply on top of my gpio/for-next branch. Do you think you > > > can quickly submit another iteration rebased on top of it? > > Maybe this is a basic question but is there a rule of thumb for where > > to base patches to be submitted to the mailing lists? I've generally > > been basing them off the latest tag in linux-stable/master. I suppose > > this might be one of those it depends on the subsystem things? > > > > > I feed my tree into linux next, so generally using linux-next/master > would be your best bet. The rule of thumb typically is checking the > subsystem's git tree in MAINTAINERS and using whatever branch goes > into the next release. Awesome, thanks for the info! > > Bartosz -- Jonathan Cormier Senior Software Engineer Voice: 315.425.4045 x222 http://www.CriticalLink.com 6712 Brooklawn Parkway, Syracuse, NY 13211
© 2016 - 2025 Red Hat, Inc.