[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <8b77dc76-7c03-45e8-8b40-98e62c468310@solid-run.com>
Date: Wed, 13 Nov 2024 08:32:49 +0000
From: Josua Mayer <josua@...id-run.com>
To: Geert Uytterhoeven <geert@...ux-m68k.org>
CC: Nishanth Menon <nm@...com>, Tero Kristo <kristo@...nel.org>, Rob Herring
<robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley
<conor+dt@...nel.org>, Vignesh Raghavendra <vigneshr@...com>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>, "devicetree@...r.kernel.org"
<devicetree@...r.kernel.org>, "linux-kernel@...r.kernel.org"
<linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] arm64: dts: ti: k3-am642-hummingboard-t: convert overlay
to board dts
Am 12.11.24 um 10:21 schrieb Geert Uytterhoeven:
> Hi Josua,
>
> On Tue, Nov 12, 2024 at 6:05 AM Josua Mayer <josua@...id-run.com> wrote:
>> Am 01.11.24 um 15:16 schrieb Josua Mayer:
>>> SolidRun HummingBoard-T has two options for M.2 connector, supporting
>>> either PCI-E or USB-3.1 Gen 1 - depending on configuration of a mux
>>> on the serdes lane.
>>> The required configurations in device-tree were modeled as overlays.
>>>
>>> The USB-3.1 overlay uses /delete-property/ to unset a boolean property
>>> on the usb controller limiting it to USB-2.0 by default.
>>> Overlays can not delete a property from the base dtb, therefore this
>>> overlay is at this time useless.
>>>
>>> Convert both overlays into full dts by including the base board dts.
>>> While the pcie overlay was functional, both are converted for a
>>> consistent user experience when selecting between the two mutually
>>> exclusive configurations.
>>>
>>> Reported-by: Geert Uytterhoeven <geert@...ux-m68k.org>
>>> Closes: https://lore.kernel.org/linux-devicetree/CAMuHMdXTgpTnJ9U7egC2XjFXXNZ5uiY1O+WxNd6LPJW5Rs5KTw@mail.gmail.com
>>> Fixes: bbef42084cc1 ("arm64: dts: ti: hummingboard-t: add overlays for m.2 pci-e and usb-3")
>>> Signed-off-by: Josua Mayer <josua@...id-run.com>
>>> ---
>>> arch/arm64/boot/dts/ti/Makefile | 4 ----
>>> ...gboard-t-pcie.dtso => k3-am642-hummingboard-t-pcie.dts} | 14 ++++++++------
>>> ...gboard-t-usb3.dtso => k3-am642-hummingboard-t-usb3.dts} | 13 ++++++++-----
>>> 3 files changed, 16 insertions(+), 15 deletions(-)
>>>
>> Please hold off on this patch for the moment,
>> Thanks to some comments from Geert I wish to submit an alternative
>> solution via separate patch-set, for further discussion.
> As you state in the other patch set "I do not consider it ready for
> current merge window", it may be worthwhile to not hold off?
> It can always be reverted whenif the alternative solution is accepted.
From my side it is not a high priority to solve the usb3 function,
I am more worried for the difference in how a user(space) or bootloader will
select the correct file during boot.
Right now even though pcie and usb3 variants are overlays,
"make" generates standalone dtb for each.
Should distros expect to have a .dtb for each combination of overlays
on a particular board? E.g. imagine if there was also an overlay
reassigning ethernet port, then we have 4 combinations.
Alternatively expectation can be that the bootloader collects overlays,
and applies them as needed before boot on top of a base dtb.
This is relevant e.g. as Debian uses the "model" property
to identify the correct dtb file and copy it to /boot.
I added "model" fields in this patch-set to allow differentiation.
But once the boolean issue will be fixed, and the change reverted,
A distro may have already chosen the usb3 or pcie variants as base dtb
I would prefer to hold off on this patch-set until other options have been
explored fully.
.
sincerely
Josua Mayer
Powered by blists - more mailing lists