Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.32 as permitted sender) client-ip=23.128.96.32;
Content-Type: text/plain;
        charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.4\))
Subject: Re: [PATCH] ARM: dts: omap3-gta04: Drop superfluous omap36xx
 compatible
From:   "H. Nikolaus Schaller" <hns@goldelico.com>
In-Reply-To: <20231004135449.591b3f6c@aktux>
Date:   Wed, 4 Oct 2023 14:42:47 +0200
Cc:     bcousson@baylibre.com, Tony Lindgren <tony@atomide.com>,
        robh+dt@kernel.org, krzysztof.kozlowski+dt@linaro.org,
        conor+dt@kernel.org, linux-omap@vger.kernel.org,
        devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <42806B60-E48B-4AA9-B375-E9F65F59AB87@goldelico.com>
References: <20231004065323.2408615-1-andreas@kemnade.info>
 <12323F42-3611-4685-8981-F6A18C4A5862@goldelico.com>
 <20231004130353.01228376@aktux>
 <FF3A3F35-E264-4D28-AFAC-EFA2ADB69F40@goldelico.com>
 <20231004135449.591b3f6c@aktux>
To:     Andreas Kemnade <andreas@kemnade.info>
Precedence: bulk


> Am 04.10.2023 um 13:54 schrieb Andreas Kemnade <andreas@kemnade.info>:
>=20
> On Wed, 4 Oct 2023 13:39:03 +0200
> "H. Nikolaus Schaller" <hns@goldelico.com> wrote:
>=20
>>> Am 04.10.2023 um 13:03 schrieb Andreas Kemnade =
<andreas@kemnade.info>:
>>>=20
>>> On Wed, 4 Oct 2023 12:50:16 +0200
>>> "H. Nikolaus Schaller" <hns@goldelico.com> wrote:
>>>=20
>>>> Hi Andreas,
>>>>=20
>>>>> Am 04.10.2023 um 08:53 schrieb Andreas Kemnade =
<andreas@kemnade.info>:
>>>>>=20
>>>>> Drop omap36xx compatible as done in other omap3630 devices.
>>>>> This has apparently fallen through the lattice.
>>>>>=20
>>>>> Signed-off-by: Andreas Kemnade <andreas@kemnade.info>
>>>>> ---
>>>>> arch/arm/boot/dts/ti/omap/omap3-gta04.dtsi | 2 +-
>>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>>>=20
>>>>> diff --git a/arch/arm/boot/dts/ti/omap/omap3-gta04.dtsi =
b/arch/arm/boot/dts/ti/omap/omap3-gta04.dtsi
>>>>> index b6b27e93857f..3661340009e7 100644
>>>>> --- a/arch/arm/boot/dts/ti/omap/omap3-gta04.dtsi
>>>>> +++ b/arch/arm/boot/dts/ti/omap/omap3-gta04.dtsi
>>>>> @@ -11,7 +11,7 @@
>>>>>=20
>>>>> / {
>>>>> 	model =3D "OMAP3 GTA04";
>>>>> -	compatible =3D "goldelico,gta04", "ti,omap3630", "ti,omap36xx", =
"ti,omap3";   =20
>>>>=20
>>>> there seem to be some more references to ti,omap36xx:
>>>>=20
>>>> arch/arm/boot/dts/ti/omap/omap3-lilly-a83x.dtsi:	compatible =3D =
"incostartec,omap3-lilly-a83x", "ti,omap3630", "ti,omap36xx", =
"ti,omap3"; =20
>>>=20
>>> apperently all the dtsi are fallen through the lattice when handling =
the dts.
>>>=20
>>>=20
>>>> arch/arm/mach-omap2/board-generic.c:	"ti,omap36xx",
>>>> drivers/clk/ti/dpll.c:	     =
of_machine_is_compatible("ti,omap36xx")) &&
>>>> drivers/cpufreq/ti-cpufreq.c:	{ .compatible =3D "ti,omap36xx", =
.data =3D &omap36xx_soc_data, },
>>>>=20
>>>> So are you sure that we can remove it without replacement or code =
fixes in dpll and cpufreq (board-generic is probably no issue)?
>>>>=20
>>> see discussion of:
>>>=20
>>> commit e341f338180c84cd98af3016cf5bcfde45a041fb
>>> Author: Andrew Davis <afd@ti.com>
>>> Date:   Thu Feb 16 09:33:38 2023 -0600
>>>=20
>>>   ARM: dts: omap: Drop ti,omap36xx compatible =20
>>=20
>> Ah, I wasn't aware of this.
>>=20
>>>=20
>>> all the places also basically check for omap36xx || omap3630. =20
>>=20
>>=20
>> Yes, I have checked but drivers/cpufreq/ti-cpufreq.c seems to be an
>> exception (unless I am missing some other patch).
>>=20
> No:
>        { .compatible =3D "ti,omap36xx", .data =3D &omap36xx_soc_data, =
},
>        { .compatible =3D "ti,omap3630", .data =3D &omap36xx_soc_data, =
},

Well, in v6.6-rc4 I see:

static const struct of_device_id ti_cpufreq_of_match[] =3D {
	{ .compatible =3D "ti,am33xx", .data =3D &am3x_soc_data, },
	{ .compatible =3D "ti,am3517", .data =3D &am3517_soc_data, },
	{ .compatible =3D "ti,am43", .data =3D &am4x_soc_data, },
	{ .compatible =3D "ti,dra7", .data =3D &dra7_soc_data },
	{ .compatible =3D "ti,omap34xx", .data =3D &omap34xx_soc_data, =
},
	{ .compatible =3D "ti,omap36xx", .data =3D &omap36xx_soc_data, =
},
	{ .compatible =3D "ti,am625", .data =3D &am625_soc_data, },
	{ .compatible =3D "ti,am62a7", .data =3D &am625_soc_data, },
	/* legacy */
	{ .compatible =3D "ti,omap3430", .data =3D &omap34xx_soc_data, =
},
	{ .compatible =3D "ti,omap3630", .data =3D &omap36xx_soc_data, =
},
	{},
};

Either the "/* legacy */" or the "ti,omap36xx" seems as if it should be =
removed.
But it seems to break the systematic approach of this table.

> The bindings also only specify omap3630.

What I think is that the background was (before bindings documentation
was invented) that there are drivers covering all variants of omap36xx
(incl. am37xx and dm37xx) and some parts specific to a single version.

So maybe it could have been missing in the bindings?

Anyways it seems to need some cleanup to remove all references to=20
omap36xx before it is forgotten...

BR,
Nikolaus=