Message ID | 20231004065323.2408615-1-andreas@kemnade.info |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:612c:2a8e:b0:403:3b70:6f57 with SMTP id in14csp2568390vqb; Tue, 3 Oct 2023 23:53:56 -0700 (PDT) X-Google-Smtp-Source: AGHT+IHPTI9MYGRtjT1Tzag7PVMX4m03/XwF/QC/2g8hPpwYNxN60UWqQGW555xdv0hXLnIVkKLW X-Received: by 2002:a17:902:eccc:b0:1c4:44a0:5c03 with SMTP id a12-20020a170902eccc00b001c444a05c03mr1962381plh.9.1696402436553; Tue, 03 Oct 2023 23:53:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1696402436; cv=none; d=google.com; s=arc-20160816; b=cEQzoSkTCv2WC/yNUF3ZntoV385hkZDCluMqf+YfF9gXgLbg64k3c+UOufr8gR4l62 35lgahXhaNR+7bl8pwqvF9R5lO/uqoJDZNUuwcMl0bCSRc58gtGZ3Rcn2jOn1baSBthX jZ/KAM3WKosU9acH83bp6rxYeZ3AXyJHzHUe2Hh3/x4oPERHSuTSwE6qXVX/WoUYgHnI rYIsp4Z2qNtrFxNlDxuzIbg6khfWyhS4pZkRGg+znD6B1rxXsRMv8QgxLyDO9V/fD13p h8hGZV0AJ5TmSVVuFz5QvVSWbpPzZrIavsSZfTqCv2ioyzxF6DGtzTLrK+hPtrrkAOZG 17nQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from; bh=dir0l4Glngl0iXTizng64X7vDBsDhqaNrMyIUSKKBPo=; fh=zh3d3x9lQGBBeRDxXJ3u5JvMTgGIgna9QtMBbctOflM=; b=RD9bk+iIRkkwT7KRITExEmwahuUBw6QRDJ4jEUITug5uXoqziGZtuzqD5Gbhs/rg4V vnT3q3oYvbqOEuCpGs2OV9N9LnOQ2aqhOp/Y+37G+FCNntv46Fo2RtBvsR7dFIe1SzrY 1G6kDHLh95Js3xy5PSRSobHc6n2QR8gCG1JYMA8zoR7i2p8AIf34E9daeBzLvabEiqr6 cZxT4GrzyUSjCkBoumZhvWc9S+Qn1I6ce5XlFOhwMjRbseqpBPAzYD93Oopu/+aGxpOv XauCGASJkfEi9q9o3A1ne7qmoBlz6MAFScDCQhuoXoF4PKtr+gSnWgzP0fbVgSOfLqDQ LwCw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.33 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from lipwig.vger.email (lipwig.vger.email. [23.128.96.33]) by mx.google.com with ESMTPS id v2-20020a170902d08200b001c7245a7fe8si2897488plv.524.2023.10.03.23.53.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 03 Oct 2023 23:53:56 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.33 as permitted sender) client-ip=23.128.96.33; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.33 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by lipwig.vger.email (Postfix) with ESMTP id 8F25081A99BA; Tue, 3 Oct 2023 23:53:54 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at lipwig.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S241452AbjJDGxl (ORCPT <rfc822;pusanteemu@gmail.com> + 18 others); Wed, 4 Oct 2023 02:53:41 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56038 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S241456AbjJDGxg (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Wed, 4 Oct 2023 02:53:36 -0400 Received: from mail.andi.de1.cc (mail.andi.de1.cc [IPv6:2a02:c205:3004:2154::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 079A1AC; Tue, 3 Oct 2023 23:53:32 -0700 (PDT) Received: from p200300ccff1732001a3da2fffebfd33a.dip0.t-ipconnect.de ([2003:cc:ff17:3200:1a3d:a2ff:febf:d33a] helo=aktux) by mail.andi.de1.cc with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from <andreas@kemnade.info>) id 1qnvl7-004VAE-Jo; Wed, 04 Oct 2023 08:53:25 +0200 Received: from andi by aktux with local (Exim 4.96) (envelope-from <andreas@kemnade.info>) id 1qnvl6-00A6aq-1y; Wed, 04 Oct 2023 08:53:24 +0200 From: Andreas Kemnade <andreas@kemnade.info> To: bcousson@baylibre.com, 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 Cc: Andreas Kemnade <andreas@kemnade.info> Subject: [PATCH] ARM: dts: omap3-gta04: Drop superfluous omap36xx compatible Date: Wed, 4 Oct 2023 08:53:23 +0200 Message-Id: <20231004065323.2408615-1-andreas@kemnade.info> X-Mailer: git-send-email 2.39.2 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-0.8 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lipwig.vger.email Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (lipwig.vger.email [0.0.0.0]); Tue, 03 Oct 2023 23:53:54 -0700 (PDT) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1778806881085305768 X-GMAIL-MSGID: 1778806881085305768 |
Series |
ARM: dts: omap3-gta04: Drop superfluous omap36xx compatible
|
|
Commit Message
Andreas Kemnade
Oct. 4, 2023, 6:53 a.m. UTC
Drop omap36xx compatible as done in other omap3630 devices.
This has apparently fallen through the lattice.
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(-)
Comments
On Wed, 4 Oct 2023 12:50:16 +0200 "H. Nikolaus Schaller" <hns@goldelico.com> wrote: > Hi Andreas, > > > Am 04.10.2023 um 08:53 schrieb Andreas Kemnade <andreas@kemnade.info>: > > > > Drop omap36xx compatible as done in other omap3630 devices. > > This has apparently fallen through the lattice. > > > > 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(-) > > > > 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@ti.com> Date: Thu Feb 16 09:33:38 2023 -0600 ARM: dts: omap: Drop ti,omap36xx compatible all the places also basically check for omap36xx || omap3630. Regards, Andreas
> Am 04.10.2023 um 13:03 schrieb Andreas Kemnade <andreas@kemnade.info>: > > On Wed, 4 Oct 2023 12:50:16 +0200 > "H. Nikolaus Schaller" <hns@goldelico.com> wrote: > >> Hi Andreas, >> >>> Am 04.10.2023 um 08:53 schrieb Andreas Kemnade <andreas@kemnade.info>: >>> >>> Drop omap36xx compatible as done in other omap3630 devices. >>> This has apparently fallen through the lattice. >>> >>> 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(-) >>> >>> 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@ti.com> > 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). Generally it could be good to remove the double checks for omap36xx || omap3630 in code? Is this planned as well? BR, Nikolaus
On Wed, 4 Oct 2023 13:39:03 +0200 "H. Nikolaus Schaller" <hns@goldelico.com> wrote: > > Am 04.10.2023 um 13:03 schrieb Andreas Kemnade <andreas@kemnade.info>: > > > > On Wed, 4 Oct 2023 12:50:16 +0200 > > "H. Nikolaus Schaller" <hns@goldelico.com> wrote: > > > >> Hi Andreas, > >> > >>> Am 04.10.2023 um 08:53 schrieb Andreas Kemnade <andreas@kemnade.info>: > >>> > >>> Drop omap36xx compatible as done in other omap3630 devices. > >>> This has apparently fallen through the lattice. > >>> > >>> 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(-) > >>> > >>> 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@ti.com> > > 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, }, The bindings also only specify omap3630. Regards, Andreas
> Am 04.10.2023 um 13:54 schrieb Andreas Kemnade <andreas@kemnade.info>: > > On Wed, 4 Oct 2023 13:39:03 +0200 > "H. Nikolaus Schaller" <hns@goldelico.com> wrote: > >>> Am 04.10.2023 um 13:03 schrieb Andreas Kemnade <andreas@kemnade.info>: >>> >>> On Wed, 4 Oct 2023 12:50:16 +0200 >>> "H. Nikolaus Schaller" <hns@goldelico.com> wrote: >>> >>>> Hi Andreas, >>>> >>>>> Am 04.10.2023 um 08:53 schrieb Andreas Kemnade <andreas@kemnade.info>: >>>>> >>>>> Drop omap36xx compatible as done in other omap3630 devices. >>>>> This has apparently fallen through the lattice. >>>>> >>>>> 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(-) >>>>> >>>>> 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@ti.com> >>> 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. So maybe it could have been missing in the bindings? Anyways it seems to need some cleanup to remove all references to omap36xx before it is forgotten... BR, Nikolaus
> Am 04.10.2023 um 14:42 schrieb H. Nikolaus Schaller <hns@goldelico.com>: > > > >> Am 04.10.2023 um 13:54 schrieb Andreas Kemnade <andreas@kemnade.info>: >> >> On Wed, 4 Oct 2023 13:39:03 +0200 >> "H. Nikolaus Schaller" <hns@goldelico.com> wrote: >> >>>> Am 04.10.2023 um 13:03 schrieb Andreas Kemnade <andreas@kemnade.info>: >>>> >>>> On Wed, 4 Oct 2023 12:50:16 +0200 >>>> "H. Nikolaus Schaller" <hns@goldelico.com> wrote: >>>> >>>>> Hi Andreas, >>>>> >>>>>> Am 04.10.2023 um 08:53 schrieb Andreas Kemnade <andreas@kemnade.info>: >>>>>> >>>>>> Drop omap36xx compatible as done in other omap3630 devices. >>>>>> This has apparently fallen through the lattice. >>>>>> >>>>>> 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(-) >>>>>> >>>>>> 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@ti.com> >>>> 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
* H. Nikolaus Schaller <hns@goldelico.com> [231004 12:50]: > 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"; I think we already handle this, see drivers/bus/ti-sysc.c and search for DIS_SGX and similar flags for other accelerators. So I think this patch is safe to apply? Regards, Tony
Hi Tony, > Am 07.10.2023 um 08:44 schrieb Tony Lindgren <tony@atomide.com>: > > * H. Nikolaus Schaller <hns@goldelico.com> [231004 12:50]: >> 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"; > > I think we already handle this, see drivers/bus/ti-sysc.c and search for > DIS_SGX and similar flags for other accelerators. Ah, ok. This means that the kernel module isn't loaded if the flags of the chip are not available. Then we will indeed have no need to describe such variances in the DTS. > So I think this patch is > safe to apply? Looks so (especially as I only have omap3630 based devices with SGX). BR and thanks, Nikolaus
* H. Nikolaus Schaller <hns@goldelico.com> [231007 06:54]: > Hi Tony, > > > Am 07.10.2023 um 08:44 schrieb Tony Lindgren <tony@atomide.com>: > > > > * H. Nikolaus Schaller <hns@goldelico.com> [231004 12:50]: > >> 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"; > > > > I think we already handle this, see drivers/bus/ti-sysc.c and search for > > DIS_SGX and similar flags for other accelerators. > > Ah, ok. This means that the kernel module isn't loaded if the flags of the chip > are not available. Then we will indeed have no need to describe such variances > in the DTS. > > > So I think this patch is > > safe to apply? > > Looks so (especially as I only have omap3630 based devices with SGX). OK applying into omap-for-v6.7/dt then. Thanks, Tony
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"; + compatible = "goldelico,gta04", "ti,omap3630", "ti,omap3"; cpus { cpu@0 { cpu0-supply = <&vcc>;