[PATCH v2 5/5] arm: omap2plus_defconfig: Enable TPS65219 regulator

[Andrew Davis]

On 6/12/25 1:12 AM, Andreas Kemnade wrote:
> Am Wed, 11 Jun 2025 16:13:05 -0500
> schrieb Andrew Davis <afd at ti.com>:
> 
>> On 6/9/25 10:43 AM, Kory Maincent wrote:
>>> Enable the TPS65219 regulator in the defconfig, as the TPS65214
>>> variant is used by the newly introduced BeagleBoard Green Eco board.
>>>
>>> Reviewed-by: Andreas Kemnade <andreas at kemnade.info>
>>> Signed-off-by: Kory Maincent <kory.maincent at bootlin.com>
>>> ---
>>>    arch/arm/configs/omap2plus_defconfig | 3 +++
>>>    1 file changed, 3 insertions(+)
>>>
>>> diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig
>>> index 9f9780c8e62a..2ad669f7b202 100644
>>> --- a/arch/arm/configs/omap2plus_defconfig
>>> +++ b/arch/arm/configs/omap2plus_defconfig
>>
>> Why omap2plus_defconfig? OMAP3 and newer are all ARMv7 and
>> boards with those can/should use multi_v7_defconfig.
>>
> if there are enough drivers enabled there, it would work, but it is not.
> So there need to be a bunch of patches to add the missing stuff.
> omap2plus_defconfig is there and support for boards are added.
> 

Yes multi_v7 is still missing stuff for some boards we want to
support, and we are working on adding those needed modules now.

We won't get feature parity in multi_v7 if we keep adding new
boards to the old omap2plus_defconfig. For this patch series
how about we add support to both defconfigs?

> So I think until multi_v7_defconfig is really usable for OMAP3+, we
> should stick with the name omap2plus_defconfig and add stuff.
> If we rename omap2plus_defconfig to omap2_defconfig, we should imho
> disable OMAP3/4/5 there to avoid confusion.
> 

Yes, that was part of the plan, right now these SoCs are enabled
in both configs, so new boards often get enabled in one or the other
but rarely both.

Andrew

> Regards,
> Andreas