> Am 04.10.2023 um 14:42 schrieb H. Nikolaus Schaller <hns@xxxxxxxxxxxxx>:
>
>
>
>> Am 04.10.2023 um 13:54 schrieb Andreas Kemnade <andreas@xxxxxxxxxxxx>:
>>
>> On Wed, 4 Oct 2023 13:39:03 +0200
>> "H. Nikolaus Schaller" <hns@xxxxxxxxxxxxx> wrote:
>>
>>>> Am 04.10.2023 um 13:03 schrieb Andreas Kemnade <andreas@xxxxxxxxxxxx>:
>>>>
>>>> On Wed, 4 Oct 2023 12:50:16 +0200
>>>> "H. Nikolaus Schaller" <hns@xxxxxxxxxxxxx> wrote:
>>>>
>>>>> Hi Andreas,
>>>>>
>>>>>> Am 04.10.2023 um 08:53 schrieb Andreas Kemnade <andreas@xxxxxxxxxxxx>:
>>>>>>
>>>>>> Drop omap36xx compatible as done in other omap3630 devices.
>>>>>> This has apparently fallen through the lattice.
>>>>>>
>>>>>> Signed-off-by: Andreas Kemnade <andreas@xxxxxxxxxxxx>
>>>>>> ---
>>>>>> arch/arm/boot/dts/ti/omap/omap3-gta04.dtsi | 2 +-
>>>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>>>>
>>>>>> 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 @@
>>>>>>
>>>>>> / {
>>>>>> model = "OMAP3 GTA04";
>>>>>> - compatible = "goldelico,gta04", "ti,omap3630", "ti,omap36xx", "ti,omap3";
>>>>>
>>>>> there seem to be some more references to ti,omap36xx:
>>>>>
>>>>> arch/arm/boot/dts/ti/omap/omap3-lilly-a83x.dtsi: compatible = "incostartec,omap3-lilly-a83x", "ti,omap3630", "ti,omap36xx", "ti,omap3";
>>>>
>>>> apperently all the dtsi are fallen through the lattice when handling the dts.
>>>>
>>>>
>>>>> 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 = "ti,omap36xx", .data = &omap36xx_soc_data, },
>>>>>
>>>>> So are you sure that we can remove it without replacement or code fixes in dpll and cpufreq (board-generic is probably no issue)?
>>>>>
>>>> see discussion of:
>>>>
>>>> commit e341f338180c84cd98af3016cf5bcfde45a041fb
>>>> Author: Andrew Davis <afd@xxxxxx>
>>>> Date: Thu Feb 16 09:33:38 2023 -0600
>>>>
>>>> ARM: dts: omap: Drop ti,omap36xx compatible
>>>
>>> Ah, I wasn't aware of this.
>>>
>>>>
>>>> all the places also basically check for omap36xx || omap3630.
>>>
>>>
>>> Yes, I have checked but drivers/cpufreq/ti-cpufreq.c seems to be an
>>> exception (unless I am missing some other patch).
>>>
>> No:
>> { .compatible = "ti,omap36xx", .data = &omap36xx_soc_data, },
>> { .compatible = "ti,omap3630", .data = &omap36xx_soc_data, },
>
> Well, in v6.6-rc4 I see:
>
> static const struct of_device_id ti_cpufreq_of_match[] = {
> { .compatible = "ti,am33xx", .data = &am3x_soc_data, },
> { .compatible = "ti,am3517", .data = &am3517_soc_data, },
> { .compatible = "ti,am43", .data = &am4x_soc_data, },
> { .compatible = "ti,dra7", .data = &dra7_soc_data },
> { .compatible = "ti,omap34xx", .data = &omap34xx_soc_data, },
> { .compatible = "ti,omap36xx", .data = &omap36xx_soc_data, },
> { .compatible = "ti,am625", .data = &am625_soc_data, },
> { .compatible = "ti,am62a7", .data = &am625_soc_data, },
> /* legacy */
> { .compatible = "ti,omap3430", .data = &omap34xx_soc_data, },
> { .compatible = "ti,omap3630", .data = &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.
Ah, there is indeed an issue with removing omap36xx and replacing by
omap3630.
What about the PVR/SGX driver. This needs a compatible that can distinguish
between the DM3725 and DM3730. The first is w/o SGX and the second one
with. Having all summarized as omap3630 does not allow to load the
PVR/SGX driver based on the board specific compatible entry.
AFAIR this was the original idea behind
compatible = "goldelico,gta04", "ti,omap3630", "ti,omap36xx", "ti,omap3";
Only with this we can make the SGX driver depend on "ti,omap3630" and all
other general omap36xx stuff on "ti,omap36xx".
So it seems as if there was a reason to have both, and the omap36xx is not
completely superflous to be dropped.
BR,
Nikolaus
