Message-ID: <20250410225301.orsurkanor52ovmk@native>
Date: Thu, 10 Apr 2025 17:53:01 -0500
From: Nishanth Menon <nm@...com>
To: Jason Kridner <jkridner@...gleboard.org>
CC: Robert Nelson <robertcnelson@...il.com>,
        <linux-arm-kernel@...ts.infradead.org>, <linux-kernel@...r.kernel.org>,
        <devicetree@...r.kernel.org>, Rob Herring <robh@...nel.org>,
        "Krzysztof
 Kozlowski" <krzk+dt@...nel.org>,
        Conor Dooley <conor+dt@...nel.org>,
        "Vignesh
 Raghavendra" <vigneshr@...com>, Andrew Davis <afd@...com>,
        Roger Quadros
	<rogerq@...nel.org>,
        Siddharth Vadapalli <s-vadapalli@...com>, Judith Mendez
	<jm@...com>,
        Andrei Aldea <a-aldea@...com>, Dhruva Gole <d-gole@...com>,
        Deepak Khatri <lorforlinux@...gleboard.org>,
        Ayush Singh
	<ayush@...gleboard.org>,
        <michael.opdenacker@...tcommit.com>
Subject: Re: [PATCH v2 2/2] arm64: dts: ti: Add k3-am62-pocketbeagle2

On 13:26-20250410, Jason Kridner wrote:
[...]
> > > +&usb1 {
> > > +     dr_mode = "host";
> > > +     pinctrl-names = "default";
> > > +     pinctrl-0 = <&usb1_pins_default>;
> > > +};
> >
> > is'nt this over https://www.beagleboard.org/boards/techlab or
> > https://www.beagleboard.org/boards/pocketbeagle-gamepup-cape or
> > https://github.com/mwelling/pocket-bob ?
> >
> > I think it is better as an overlay? Let us not enable something that
> > will add power for no benefit :)
> > Further USB1.ID has options for PRU as well. Let the daughter overlay
> > deal with it.
> >
> > On the flip side, we could work the other way - since majority of
> > daughter cards use USB host, it could be that the other overlays can
> > just disable usbss1 and usb1
> >
> > Thoughts?
> 
> Since you asked, Being the somewhat unique state of PocketBeagle 2 and
> other Beagle
> single-board computers as rapid-prototyping development platforms, my
> personal general
> preference is to see all the stuff turned on by default and then to
> provide some clear direction
> on what is not necessary such that it lives as documentation forhow to
> enable it and simplify
> the development of overlays. Some of the rationale for this was
> discussed a couple
> of years back in a series of blog posts by Michael Opdenacker. [1][2][3]

OK - Let us document that in the device tree then. For the i2c ports and
usb ports that are implemented in the cape, just add a documentation
note saying enabled for cape header or something for that effect. all
these main USB pins are dedicated functions anyways, so it is unlikely
to see capes that can even attempt to reuse the generic USB data pins
for alternate functions.

If folks do not use that header in some specific overlay, they can
disable the node based on at least some guidance from the documentation.

> 
> My perspective is that the interfaces need to be enabled to define the
> header connector to
> the device tree and that the muxes should further be fully described
> to the system, rather than
> leaving those bits of metadata regarding the running system as an
> exercise for the reader.
> 
> The aforementioned approach of removing all the "dead bits" is great
> until someone is left with
> the challenge of figuring out how to turn them on and/or select
> between them. Providing an
> overlay that disables all the unnecessary bits seems reasonable to me.

I understand the rationale, but, we as Linux community came to this
guideline:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/dts-coding-style.rst#n207
"
Hardware components that are present on the board shall be placed in the
board DTS, not in the SoC or SoM DTSI
"

PB2 being an partial "SOM".

It is a trade-off unfortunately.

> 
> Otherwise, I think we can put the entirety of the header description
> into an overlay for
> cape-specific overlays to use, but I find the lack of an upstream
> definition to make it difficult to
> enable cape makers to define overlays that are likely to actually work.

This is not an unknown problem, though not something pleasant to
live with. Linux community is always happy to review options around
this, there has been attempts to help standardize these daughter card
ecosystems in the past, but none have achieved acceptance.

What we have today is the scheme where we have dts and overlays and
ability to generate a dtb that stitches the two together in a specific
order. That is usually requested to be demonstrated to work prior to
acceptance in upstream. That provides folks at least one specific
combination of things that is known to work. (testing is a case of
effort spent by the community to test things - including overlay,
which is no different from the core dtb). But, yes, there is no do what
you want and it will just work option today.

> 
> Just my $0.0000002.
> 
> [1] https://www.beagleboard.org/blog/2022-02-15-using-device-tree-overlays-example-on-beaglebone-cape-add-on-boards
> [2] https://www.beagleboard.org/blog/2022-03-31-device-tree-supporting-similar-boards-the-beaglebone-example
> [3] https://www.beagleboard.org/blog/2022-06-06-using-the-u-boot-extension-board-manager-beaglebone-boards-example


Thank you for sharing your thoughts.

[...]

-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 849D 1736 249D

Powered by blists - more mailing lists