| Message ID | 20250121200749.4131923-1-trini@konsulko.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | ARM: dts: omap4-panda-a4: Add missing model and compatible properties | expand |
Hi Tom, Tom Rini <trini@konsulko.com> writes: > When moving the model and compatible properties out of the common > Pandaboard files and in to the specific boards, the omap4-panda-a4 > file wasn't updated as well and so has lacked a model and compatible > entry ever since. > > Fixes: a1a57abaaf82 ("ARM: dts: omap4-panda: Fix model and SoC family details") > Signed-off-by: Tom Rini <trini@konsulko.com> > --- Checkpatch tells me: WARNING: DT compatible string "ti,omap4-panda-a4" appears un-documented So I think Documentation/devicetree/bindings/arm/ti/omap.yaml needs an update too. (and note the binding update should be a separate patch[1]) > Given how long this has been broken it's entirely plausible no a4 > hardware even exists anymore and so dropping this file instead makes > sense. I only found this because scripts/make_fit.py crashed on these > properties being missing. If keeping it is just this binding update, then I'd say we keep it, but if it gets any more paninful to maintain, I'm also not going to argue very hard to keep it. Kevin [1] From: Documentation/devicetree/bindings/submitting-patches.rst 1) The Documentation/ and include/dt-bindings/ portion of the patch should be a separate patch. The preferred subject prefix for binding patches is:: "dt-bindings: <binding dir>: ..." > Cc: Nishanth Menon <nm@ti.com> > Cc: Tony Lindgren <tony@atomide.com> > Cc: Rob Herring <robh@kernel.org> > Cc: Krzysztof Kozlowski <krzk+dt@kernel.org> > Cc: Conor Dooley <conor+dt@kernel.org> > Cc: linux-omap@vger.kernel.org > Cc: devicetree@vger.kernel.org > Cc: linux-kernel@vger.kernel.org > --- > arch/arm/boot/dts/ti/omap/omap4-panda-a4.dts | 5 +++++ > 1 file changed, 5 insertions(+) > > diff --git a/arch/arm/boot/dts/ti/omap/omap4-panda-a4.dts b/arch/arm/boot/dts/ti/omap/omap4-panda-a4.dts > index 8fd076e5d1b0..4b8bfd0188ad 100644 > --- a/arch/arm/boot/dts/ti/omap/omap4-panda-a4.dts > +++ b/arch/arm/boot/dts/ti/omap/omap4-panda-a4.dts > @@ -7,6 +7,11 @@ > #include "omap443x.dtsi" > #include "omap4-panda-common.dtsi" > > +/ { > + model = "TI OMAP4 PandaBoard (A4)"; > + compatible = "ti,omap4-panda-a4", "ti,omap4-panda", "ti,omap4430", "ti,omap4"; > +}; > + > /* Pandaboard Rev A4+ have external pullups on SCL & SDA */ > &dss_hdmi_pins { > pinctrl-single,pins = < > -- > 2.43.0
On Tue, Jan 21, 2025 at 02:50:41PM -0800, Kevin Hilman wrote: > Hi Tom, > > Tom Rini <trini@konsulko.com> writes: > > > When moving the model and compatible properties out of the common > > Pandaboard files and in to the specific boards, the omap4-panda-a4 > > file wasn't updated as well and so has lacked a model and compatible > > entry ever since. > > > > Fixes: a1a57abaaf82 ("ARM: dts: omap4-panda: Fix model and SoC family details") > > Signed-off-by: Tom Rini <trini@konsulko.com> > > --- > > Checkpatch tells me: > > WARNING: DT compatible string "ti,omap4-panda-a4" appears un-documented > > So I think Documentation/devicetree/bindings/arm/ti/omap.yaml needs an > update too. (and note the binding update should be a separate patch[1]) Regular panda is there, so yeah, it's easy enough to add the a4 variant. I assume if I post that they'll get merged in the right order? > > Given how long this has been broken it's entirely plausible no a4 > > hardware even exists anymore and so dropping this file instead makes > > sense. I only found this because scripts/make_fit.py crashed on these > > properties being missing. > > If keeping it is just this binding update, then I'd say we keep it, but > if it gets any more paninful to maintain, I'm also not going to argue > very hard to keep it. I'm not in the position to see if any of the Pandaboards work at this point, so I don't know if they're otherwise functional or a huge pile of problems.
Hi, Am Tue, 21 Jan 2025 18:08:24 -0600 schrieb Tom Rini <trini@konsulko.com>: > > If keeping it is just this binding update, then I'd say we keep it, but > > if it gets any more paninful to maintain, I'm also not going to argue > > very hard to keep it. > > I'm not in the position to see if any of the Pandaboards work at this > point, so I don't know if they're otherwise functional or a huge pile of > problems. I am still testing stuff with pandaboards. But I do not have the a4 one. So yes they are functional. Compared with other devices still in use using the same SoC, here you can play around with everything, know the device. so it is a reference for keeping the really interesting devices working. Regarding the a4: I think it is better to keep that one in, just that nobody gets confused if he/she digs out his panda board for some comparison test and uses a wrong board revision. Regards, Andreas
On Wed, Jan 22, 2025 at 2:46 PM Andreas Kemnade <andreas@kemnade.info> wrote: > > Hi, > > Am Tue, 21 Jan 2025 18:08:24 -0600 > schrieb Tom Rini <trini@konsulko.com>: > > > > If keeping it is just this binding update, then I'd say we keep it, but > > > if it gets any more paninful to maintain, I'm also not going to argue > > > very hard to keep it. > > > > I'm not in the position to see if any of the Pandaboards work at this > > point, so I don't know if they're otherwise functional or a huge pile of > > problems. > > I am still testing stuff with pandaboards. But I do not have the a4 > one. So yes they are functional. Compared with other devices still in > use using the same SoC, here you can play around with everything, know > the device. so it is a reference for keeping the really interesting > devices working. > > Regarding the a4: I think it is better to keep that one in, just that > nobody gets confused if he/she digs out his panda board for some > comparison test and uses a wrong board revision. Do you want an a4? I could dig one or two out! ;) Regards,
On Wed, Jan 22, 2025 at 02:56:19PM -0600, Robert Nelson wrote: > On Wed, Jan 22, 2025 at 2:46 PM Andreas Kemnade <andreas@kemnade.info> wrote: > > > > Hi, > > > > Am Tue, 21 Jan 2025 18:08:24 -0600 > > schrieb Tom Rini <trini@konsulko.com>: > > > > > > If keeping it is just this binding update, then I'd say we keep it, but > > > > if it gets any more paninful to maintain, I'm also not going to argue > > > > very hard to keep it. > > > > > > I'm not in the position to see if any of the Pandaboards work at this > > > point, so I don't know if they're otherwise functional or a huge pile of > > > problems. > > > > I am still testing stuff with pandaboards. But I do not have the a4 > > one. So yes they are functional. Compared with other devices still in > > use using the same SoC, here you can play around with everything, know > > the device. so it is a reference for keeping the really interesting > > devices working. > > > > Regarding the a4: I think it is better to keep that one in, just that > > nobody gets confused if he/she digs out his panda board for some > > comparison test and uses a wrong board revision. > > Do you want an a4? I could dig one or two out! ;) Unless I'm missing something, the a4 hasn't been bootable by upstream in about 10 years now... There's no top-level compatible, so there's no match in the generic board code. I can't recall if the A4 versions were available to anyone other than maintainers and beagleboard.org folks themselves as part of bring-up/testing. I know I had one and ewasted it a while ago.
On Wed, Jan 22, 2025 at 3:10 PM Tom Rini <trini@konsulko.com> wrote: > > On Wed, Jan 22, 2025 at 02:56:19PM -0600, Robert Nelson wrote: > > On Wed, Jan 22, 2025 at 2:46 PM Andreas Kemnade <andreas@kemnade.info> wrote: > > > > > > Hi, > > > > > > Am Tue, 21 Jan 2025 18:08:24 -0600 > > > schrieb Tom Rini <trini@konsulko.com>: > > > > > > > > If keeping it is just this binding update, then I'd say we keep it, but > > > > > if it gets any more paninful to maintain, I'm also not going to argue > > > > > very hard to keep it. > > > > > > > > I'm not in the position to see if any of the Pandaboards work at this > > > > point, so I don't know if they're otherwise functional or a huge pile of > > > > problems. > > > > > > I am still testing stuff with pandaboards. But I do not have the a4 > > > one. So yes they are functional. Compared with other devices still in > > > use using the same SoC, here you can play around with everything, know > > > the device. so it is a reference for keeping the really interesting > > > devices working. > > > > > > Regarding the a4: I think it is better to keep that one in, just that > > > nobody gets confused if he/she digs out his panda board for some > > > comparison test and uses a wrong board revision. > > > > Do you want an a4? I could dig one or two out! ;) > > Unless I'm missing something, the a4 hasn't been bootable by upstream in > about 10 years now... There's no top-level compatible, so there's no > match in the generic board code. I can't recall if the A4 versions were > available to anyone other than maintainers and beagleboard.org folks > themselves as part of bring-up/testing. I know I had one and ewasted it > a while ago. PandaBoard EA1->A3 = omap4-panda.dtb PandaBoard A4->+ (non ES) = omap4-panda-a4.dtb A4 was the final production version of the non ES Panda.. Sadly we still have stock! ... From Circuitco before they went out of Business (10 years ago)... https://www.digikey.com/en/products/detail/circuitco-electronics-llc/UEVM4430G-01-00-00/2349866 However there are two versions of the A4, with different memory: ELPIDA and Micron.. ELPIDA works fine (well last i really cared/tested it was u-boot v2019.04).. Where as Micron.. Which has the same bug as PandaBoard ES Rev B3, with a new memory (only one Chip Select vs 2 (or reversed)).. I could get it boot via nuking the CONFIG_SYS_EMIF_PRECALCULATED_TIMING_REGS define in include/configs/ti_omap4_common.h v2019.04 Things we learned from `that` OEM... When you run out of memory chips, don't randomly swap parts without at least changing the ID... Otherwise customers will be pissed, when old software doesn't work.. Regards,
On Wed, Jan 22, 2025 at 03:52:47PM -0600, Robert Nelson wrote: > On Wed, Jan 22, 2025 at 3:10 PM Tom Rini <trini@konsulko.com> wrote: > > > > On Wed, Jan 22, 2025 at 02:56:19PM -0600, Robert Nelson wrote: > > > On Wed, Jan 22, 2025 at 2:46 PM Andreas Kemnade <andreas@kemnade.info> wrote: > > > > > > > > Hi, > > > > > > > > Am Tue, 21 Jan 2025 18:08:24 -0600 > > > > schrieb Tom Rini <trini@konsulko.com>: > > > > > > > > > > If keeping it is just this binding update, then I'd say we keep it, but > > > > > > if it gets any more paninful to maintain, I'm also not going to argue > > > > > > very hard to keep it. > > > > > > > > > > I'm not in the position to see if any of the Pandaboards work at this > > > > > point, so I don't know if they're otherwise functional or a huge pile of > > > > > problems. > > > > > > > > I am still testing stuff with pandaboards. But I do not have the a4 > > > > one. So yes they are functional. Compared with other devices still in > > > > use using the same SoC, here you can play around with everything, know > > > > the device. so it is a reference for keeping the really interesting > > > > devices working. > > > > > > > > Regarding the a4: I think it is better to keep that one in, just that > > > > nobody gets confused if he/she digs out his panda board for some > > > > comparison test and uses a wrong board revision. > > > > > > Do you want an a4? I could dig one or two out! ;) > > > > Unless I'm missing something, the a4 hasn't been bootable by upstream in > > about 10 years now... There's no top-level compatible, so there's no > > match in the generic board code. I can't recall if the A4 versions were > > available to anyone other than maintainers and beagleboard.org folks > > themselves as part of bring-up/testing. I know I had one and ewasted it > > a while ago. > > PandaBoard EA1->A3 = omap4-panda.dtb > PandaBoard A4->+ (non ES) = omap4-panda-a4.dtb > > A4 was the final production version of the non ES Panda.. Oh! My memory sucks here, sorry for the confusion. But it's also still the case that omap4-panda-a4.dtb hasn't had a top-level compatible string, so can it even be functionally used?
Am Wed, 22 Jan 2025 15:10:14 -0600 schrieb Tom Rini <trini@konsulko.com>: > On Wed, Jan 22, 2025 at 02:56:19PM -0600, Robert Nelson wrote: > > On Wed, Jan 22, 2025 at 2:46 PM Andreas Kemnade <andreas@kemnade.info> wrote: > > > > > > Hi, > > > > > > Am Tue, 21 Jan 2025 18:08:24 -0600 > > > schrieb Tom Rini <trini@konsulko.com>: > > > > > > > > If keeping it is just this binding update, then I'd say we keep it, but > > > > > if it gets any more paninful to maintain, I'm also not going to argue > > > > > very hard to keep it. > > > > > > > > I'm not in the position to see if any of the Pandaboards work at this > > > > point, so I don't know if they're otherwise functional or a huge pile of > > > > problems. > > > > > > I am still testing stuff with pandaboards. But I do not have the a4 > > > one. So yes they are functional. Compared with other devices still in > > > use using the same SoC, here you can play around with everything, know > > > the device. so it is a reference for keeping the really interesting > > > devices working. > > > > > > Regarding the a4: I think it is better to keep that one in, just that > > > nobody gets confused if he/she digs out his panda board for some > > > comparison test and uses a wrong board revision. > > > > Do you want an a4? I could dig one or two out! ;) > > Unless I'm missing something, the a4 hasn't been bootable by upstream in > about 10 years now... There's no top-level compatible, so there's no > match in the generic board code. I can't recall if the A4 versions were > available to anyone other than maintainers and beagleboard.org folks > themselves as part of bring-up/testing. I know I had one and ewasted it > a while ago. > So, yes if they are not really officially spread, then removing them and add a comment about them in the common file or the panda.dts is also a way to go. Regards, Andreas
On Wed, Jan 22, 2025 at 4:18 PM Tom Rini <trini@konsulko.com> wrote: > > On Wed, Jan 22, 2025 at 03:52:47PM -0600, Robert Nelson wrote: > > On Wed, Jan 22, 2025 at 3:10 PM Tom Rini <trini@konsulko.com> wrote: > > > > > > On Wed, Jan 22, 2025 at 02:56:19PM -0600, Robert Nelson wrote: > > > > On Wed, Jan 22, 2025 at 2:46 PM Andreas Kemnade <andreas@kemnade.info> wrote: > > > > > > > > > > Hi, > > > > > > > > > > Am Tue, 21 Jan 2025 18:08:24 -0600 > > > > > schrieb Tom Rini <trini@konsulko.com>: > > > > > > > > > > > > If keeping it is just this binding update, then I'd say we keep it, but > > > > > > > if it gets any more paninful to maintain, I'm also not going to argue > > > > > > > very hard to keep it. > > > > > > > > > > > > I'm not in the position to see if any of the Pandaboards work at this > > > > > > point, so I don't know if they're otherwise functional or a huge pile of > > > > > > problems. > > > > > > > > > > I am still testing stuff with pandaboards. But I do not have the a4 > > > > > one. So yes they are functional. Compared with other devices still in > > > > > use using the same SoC, here you can play around with everything, know > > > > > the device. so it is a reference for keeping the really interesting > > > > > devices working. > > > > > > > > > > Regarding the a4: I think it is better to keep that one in, just that > > > > > nobody gets confused if he/she digs out his panda board for some > > > > > comparison test and uses a wrong board revision. > > > > > > > > Do you want an a4? I could dig one or two out! ;) > > > > > > Unless I'm missing something, the a4 hasn't been bootable by upstream in > > > about 10 years now... There's no top-level compatible, so there's no > > > match in the generic board code. I can't recall if the A4 versions were > > > available to anyone other than maintainers and beagleboard.org folks > > > themselves as part of bring-up/testing. I know I had one and ewasted it > > > a while ago. > > > > PandaBoard EA1->A3 = omap4-panda.dtb > > PandaBoard A4->+ (non ES) = omap4-panda-a4.dtb > > > > A4 was the final production version of the non ES Panda.. > > Oh! My memory sucks here, sorry for the confusion. But it's also still > the case that omap4-panda-a4.dtb hasn't had a top-level compatible > string, so can it even be functionally used? Looking back, I moved from PandaBoard -> WandBoard for BeagleBoard.org's build infacature.. Dual A9/USB vs Quad A9/SATA... yeah.. sata was more stable then USB.. I think it was around v5.4 lts I gave up on Panda's... SO 5.4.x would have been the last time I personally used the panda's on mainline.. Digging more, yay for omappedia! ;) https://omappedia.com/wiki/PandaBoard_Revisions I never personally saw the A5 or A6 rev's in my hand.. What's scary, teh A4's changed the hdmi pins: https://git.ti.com/gitweb?p=ti-linux-kernel/ti-linux-kernel.git;a=blob;f=arch/arm/boot/dts/omap4-panda-a4.dts;h=f1a6476af3716489007c12141d06f208ec2ebc94;hb=refs/heads/ti-linux-4.14.y Yet no gpio id change.. Regards, -- Robert Nelson https://rcn-ee.com/
Am Wed, 22 Jan 2025 16:18:43 -0600 schrieb Tom Rini <trini@konsulko.com>: > On Wed, Jan 22, 2025 at 03:52:47PM -0600, Robert Nelson wrote: > > On Wed, Jan 22, 2025 at 3:10 PM Tom Rini <trini@konsulko.com> wrote: > > > > > > On Wed, Jan 22, 2025 at 02:56:19PM -0600, Robert Nelson wrote: > > > > On Wed, Jan 22, 2025 at 2:46 PM Andreas Kemnade <andreas@kemnade.info> wrote: > > > > > > > > > > Hi, > > > > > > > > > > Am Tue, 21 Jan 2025 18:08:24 -0600 > > > > > schrieb Tom Rini <trini@konsulko.com>: > > > > > > > > > > > > If keeping it is just this binding update, then I'd say we keep it, but > > > > > > > if it gets any more paninful to maintain, I'm also not going to argue > > > > > > > very hard to keep it. > > > > > > > > > > > > I'm not in the position to see if any of the Pandaboards work at this > > > > > > point, so I don't know if they're otherwise functional or a huge pile of > > > > > > problems. > > > > > > > > > > I am still testing stuff with pandaboards. But I do not have the a4 > > > > > one. So yes they are functional. Compared with other devices still in > > > > > use using the same SoC, here you can play around with everything, know > > > > > the device. so it is a reference for keeping the really interesting > > > > > devices working. > > > > > > > > > > Regarding the a4: I think it is better to keep that one in, just that > > > > > nobody gets confused if he/she digs out his panda board for some > > > > > comparison test and uses a wrong board revision. > > > > > > > > Do you want an a4? I could dig one or two out! ;) > > > > > > Unless I'm missing something, the a4 hasn't been bootable by upstream in > > > about 10 years now... There's no top-level compatible, so there's no > > > match in the generic board code. I can't recall if the A4 versions were > > > available to anyone other than maintainers and beagleboard.org folks > > > themselves as part of bring-up/testing. I know I had one and ewasted it > > > a while ago. > > > > PandaBoard EA1->A3 = omap4-panda.dtb > > PandaBoard A4->+ (non ES) = omap4-panda-a4.dtb > > > > A4 was the final production version of the non ES Panda.. > > Oh! My memory sucks here, sorry for the confusion. But it's also still > the case that omap4-panda-a4.dtb hasn't had a top-level compatible > string, so can it even be functionally used? > maybe people just revert to omap4-panda.dtb, it should not hurt having internal and external pullups. I have the A2. Regards, Andreas
On Tue, 21 Jan 2025 14:07:49 -0600, Tom Rini wrote: > When moving the model and compatible properties out of the common > Pandaboard files and in to the specific boards, the omap4-panda-a4 > file wasn't updated as well and so has lacked a model and compatible > entry ever since. > > Fixes: a1a57abaaf82 ("ARM: dts: omap4-panda: Fix model and SoC family details") > Signed-off-by: Tom Rini <trini@konsulko.com> > --- > Given how long this has been broken it's entirely plausible no a4 > hardware even exists anymore and so dropping this file instead makes > sense. I only found this because scripts/make_fit.py crashed on these > properties being missing. > > Cc: Nishanth Menon <nm@ti.com> > Cc: Tony Lindgren <tony@atomide.com> > Cc: Rob Herring <robh@kernel.org> > Cc: Krzysztof Kozlowski <krzk+dt@kernel.org> > Cc: Conor Dooley <conor+dt@kernel.org> > Cc: linux-omap@vger.kernel.org > Cc: devicetree@vger.kernel.org > Cc: linux-kernel@vger.kernel.org > --- > arch/arm/boot/dts/ti/omap/omap4-panda-a4.dts | 5 +++++ > 1 file changed, 5 insertions(+) > My bot found new DTB warnings on the .dts files added or changed in this series. Some warnings may be from an existing SoC .dtsi. Or perhaps the warnings are fixed by another series. Ultimately, it is up to the platform maintainer whether these warnings are acceptable or not. No need to reply unless the platform maintainer has comments. If you already ran DT checks and didn't see these error(s), then make sure dt-schema is up to date: pip3 install dtschema --upgrade New warnings running 'make CHECK_DTBS=y for arch/arm/boot/dts/ti/' for 20250121200749.4131923-1-trini@konsulko.com: arch/arm/boot/dts/ti/omap/omap4-panda-a4.dtb: /: failed to match any schema with compatible: ['ti,omap4-panda-a4', 'ti,omap4-panda', 'ti,omap4430', 'ti,omap4']
diff --git a/arch/arm/boot/dts/ti/omap/omap4-panda-a4.dts b/arch/arm/boot/dts/ti/omap/omap4-panda-a4.dts index 8fd076e5d1b0..4b8bfd0188ad 100644 --- a/arch/arm/boot/dts/ti/omap/omap4-panda-a4.dts +++ b/arch/arm/boot/dts/ti/omap/omap4-panda-a4.dts @@ -7,6 +7,11 @@ #include "omap443x.dtsi" #include "omap4-panda-common.dtsi" +/ { + model = "TI OMAP4 PandaBoard (A4)"; + compatible = "ti,omap4-panda-a4", "ti,omap4-panda", "ti,omap4430", "ti,omap4"; +}; + /* Pandaboard Rev A4+ have external pullups on SCL & SDA */ &dss_hdmi_pins { pinctrl-single,pins = <
When moving the model and compatible properties out of the common Pandaboard files and in to the specific boards, the omap4-panda-a4 file wasn't updated as well and so has lacked a model and compatible entry ever since. Fixes: a1a57abaaf82 ("ARM: dts: omap4-panda: Fix model and SoC family details") Signed-off-by: Tom Rini <trini@konsulko.com> --- Given how long this has been broken it's entirely plausible no a4 hardware even exists anymore and so dropping this file instead makes sense. I only found this because scripts/make_fit.py crashed on these properties being missing. Cc: Nishanth Menon <nm@ti.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rob Herring <robh@kernel.org> Cc: Krzysztof Kozlowski <krzk+dt@kernel.org> Cc: Conor Dooley <conor+dt@kernel.org> Cc: linux-omap@vger.kernel.org Cc: devicetree@vger.kernel.org Cc: linux-kernel@vger.kernel.org --- arch/arm/boot/dts/ti/omap/omap4-panda-a4.dts | 5 +++++ 1 file changed, 5 insertions(+)