Message ID | cover.1692783907.git.zhoubinbin@loongson.cn |
---|---|
Headers | show |
Series | LoongArch: Add built-in dtb support | expand |
This series looks good enough to me now, if no one has objections, I will queue it to loongarch-next. Huacai On Wed, Aug 23, 2023 at 5:55 PM Binbin Zhou <zhoubinbin@loongson.cn> wrote: > > Hi all: > > This patchset introduces LoongArch's built-in dtb support. > > As we know, the Loongson-2K family supports DT. Inevitably, some systems > do not provide a useful device tree to the kernel at boot time. Chasing > around bootloaders for these systems is a headache, so we just keep a > device tree table in the kernel, keyed by the dts filename, that > contains the relevant DTBs. > > Thanks. > > ----- > V4: > patch(1/7): > - Drop device_type property. > patch(2/7): > - Rename board.yaml to loongson.yaml. > patch(4/7): > - Keep the ranges attribute after compatible; > - Add bootargs = "ttyS0,115200", which is needed for reference board; > patch(5/7): > - Keep the ranges attribute after compatible; > - Add bootargs = "ttyS0,115200", which is needed for reference board; > - Change node name global-utilities to chipid. > patch(6/7): > - Keep the ranges attribute after compatible; > - Add bootargs = "ttyS0,115200", which is needed for reference board. > > Link to V3: > https://lore.kernel.org/all/cover.1692618548.git.zhoubinbin@loongson.cn/ > > V3: > patch(1/7): > - Add reference to the common cpu schema. > patch(2/7): > - Add reviewed-by tag. > patch(4/7): > - Drop bootargs; > - Move the cpus node to dtsi, which is part of the SoC. > patch(5/7): > - Drop bootargs; > - Move the cpus node to dtsi, which is part of the SoC; > - Fix gmac0/1-mdio node: compatible is always the first property; > - Drop i2c-gpio node. > patch(6/7): > - Drop bootargs; > - Move the cpus node to dtsi, which is part of the SoC. > - Changes liointc to liointc-1.0, for Loongson-2K2000 has 32 interrupt > sources. > > Link to V2: > https://lore.kernel.org/all/cover.1692088166.git.zhoubinbin@loongson.cn/ > > V2: > patch(1/7): > - Drop model and clock-frequency properties; > - Add clocks property; > - Rewrite the description. > patch(2/7): > - Add the proper compatibles for boards. > patch(4/7)(5/7)(6/7): > - Format commit message head; > - Drop undocumented compatible, such as pci_bridge compatible; > - Distinguish the attributes, put SoC-related into DTSI and > board-related into DTS; > - Check DTS with 'make dtbs_check W=1'. > patch(7/7) > - New patch; > - Parses Molde name and CPU MHz from the DTS attribute. > > Link to V1: > https://lore.kernel.org/loongarch/cover.1686882123.git.zhoubinbin@loongson.cn/ > > Binbin Zhou (7): > dt-bindings: loongarch: Add CPU bindings for LoongArch > dt-bindings: loongarch: Add Loongson SoC boards compatibles > LoongArch: Allow device trees to be built into the kernel > LoongArch: dts: DeviceTree for Loongson-2K0500 > LoongArch: dts: DeviceTree for Loongson-2K1000 > LoongArch: dts: DeviceTree for Loongson-2K2000 > LoongArch: Parsing CPU-related information from DTS > > .../devicetree/bindings/loongarch/cpus.yaml | 61 +++ > .../bindings/loongarch/loongson.yaml | 34 ++ > arch/loongarch/Kconfig | 16 + > arch/loongarch/Makefile | 10 +- > arch/loongarch/boot/dts/Makefile | 7 +- > .../boot/dts/loongson-2k0500-ref.dts | 89 ++++ > arch/loongarch/boot/dts/loongson-2k0500.dtsi | 254 +++++++++++ > .../boot/dts/loongson-2k1000-ref.dts | 172 ++++++++ > arch/loongarch/boot/dts/loongson-2k1000.dtsi | 397 ++++++++++++++++++ > .../boot/dts/loongson-2k2000-ref.dts | 73 ++++ > arch/loongarch/boot/dts/loongson-2k2000.dtsi | 291 +++++++++++++ > arch/loongarch/kernel/env.c | 33 ++ > arch/loongarch/kernel/setup.c | 9 +- > 13 files changed, 1440 insertions(+), 6 deletions(-) > create mode 100644 Documentation/devicetree/bindings/loongarch/cpus.yaml > create mode 100644 Documentation/devicetree/bindings/loongarch/loongson.yaml > create mode 100644 arch/loongarch/boot/dts/loongson-2k0500-ref.dts > create mode 100644 arch/loongarch/boot/dts/loongson-2k0500.dtsi > create mode 100644 arch/loongarch/boot/dts/loongson-2k1000-ref.dts > create mode 100644 arch/loongarch/boot/dts/loongson-2k1000.dtsi > create mode 100644 arch/loongarch/boot/dts/loongson-2k2000-ref.dts > create mode 100644 arch/loongarch/boot/dts/loongson-2k2000.dtsi > > -- > 2.39.3 >
On Fri, Aug 25, 2023 at 07:38:31PM +0800, Huacai Chen wrote: > This series looks good enough to me now, if no one has objections, I > will queue it to loongarch-next. Have you not read Rob's replies?
On Thu, Aug 24, 2023 at 11:20:34AM +0800, Binbin Zhou wrote: > Hi Rob: > > On Thu, Aug 24, 2023 at 3:42 AM Rob Herring <robh@kernel.org> wrote: > > > > On Wed, Aug 23, 2023 at 05:54:51PM +0800, Binbin Zhou wrote: > > > Some systems do not provide a useful device tree to the kernel at boot > > > time. Let's keep a device tree table in the kernel, keyed by the dts > > > filename, containing the relevant DTBs. > > > > Support for this in other arches was added to support legacy bootloaders > > with no DT support. You should not need this for a new architecture. Fix > > the bootloader to provide a useful DT. > > > Yes, our bootloader already supports DT. > > Our original intention of providing kernel built-in DTS is to describe > all possible device information of that SoC, so that everyone can use > it as a reference during development; we will unlikely to add more > .dts files to the kernel besides the reference ones. > > And as a reference, our built-in DTS provides the most basic bootable > combinations (so it is generic enough) as an alternative in case the > DTS in the bootloader is unexpected. > > Does this make any sense? I don't see how this answers the question - as far as I can tell Rob was asking specifically about the building the dtb into the kernel, whereas your response seems to talk about havint the dts files in the kernel tree.
Hi, Conor, On Fri, Aug 25, 2023 at 7:59 PM Conor Dooley <conor.dooley@microchip.com> wrote: > > On Fri, Aug 25, 2023 at 07:38:31PM +0800, Huacai Chen wrote: > > This series looks good enough to me now, if no one has objections, I > > will queue it to loongarch-next. > > Have you not read Rob's replies? I'm sorry, I have read but I thought Binbin's reply has answered Rob's question. Huacai
On Fri, Aug 25, 2023 at 11:06:40PM +0800, Huacai Chen wrote: > Hi, Conor, > > On Fri, Aug 25, 2023 at 7:59 PM Conor Dooley <conor.dooley@microchip.com> wrote: > > > > On Fri, Aug 25, 2023 at 07:38:31PM +0800, Huacai Chen wrote: > > > This series looks good enough to me now, if no one has objections, I > > > will queue it to loongarch-next. > > > > Have you not read Rob's replies? > I'm sorry, I have read but I thought Binbin's reply has answered Rob's question. As far as I can tell, it didn't - but there were was a reply from Rob about dtbs_check issues too IIRC.
Hi, Conor, On Fri, Aug 25, 2023 at 8:01 PM Conor Dooley <conor.dooley@microchip.com> wrote: > > On Thu, Aug 24, 2023 at 11:20:34AM +0800, Binbin Zhou wrote: > > Hi Rob: > > > > On Thu, Aug 24, 2023 at 3:42 AM Rob Herring <robh@kernel.org> wrote: > > > > > > On Wed, Aug 23, 2023 at 05:54:51PM +0800, Binbin Zhou wrote: > > > > Some systems do not provide a useful device tree to the kernel at boot > > > > time. Let's keep a device tree table in the kernel, keyed by the dts > > > > filename, containing the relevant DTBs. > > > > > > Support for this in other arches was added to support legacy bootloaders > > > with no DT support. You should not need this for a new architecture. Fix > > > the bootloader to provide a useful DT. > > > > > Yes, our bootloader already supports DT. > > > > Our original intention of providing kernel built-in DTS is to describe > > all possible device information of that SoC, so that everyone can use > > it as a reference during development; we will unlikely to add more > > .dts files to the kernel besides the reference ones. > > > > And as a reference, our built-in DTS provides the most basic bootable > > combinations (so it is generic enough) as an alternative in case the > > DTS in the bootloader is unexpected. > > > > Does this make any sense? > > I don't see how this answers the question - as far as I can tell Rob was > asking specifically about the building the dtb into the kernel, whereas > your response seems to talk about havint the dts files in the kernel > tree. I'm sorry, but from my point of view, giving users a chance to build the reference dts file into the kernel is not a bad idea. Of course the commit message can be improved. Huacai
Hi, Conor, On Fri, Aug 25, 2023 at 11:08 PM Conor Dooley <conor@kernel.org> wrote: > > On Fri, Aug 25, 2023 at 11:06:40PM +0800, Huacai Chen wrote: > > Hi, Conor, > > > > On Fri, Aug 25, 2023 at 7:59 PM Conor Dooley <conor.dooley@microchip.com> wrote: > > > > > > On Fri, Aug 25, 2023 at 07:38:31PM +0800, Huacai Chen wrote: > > > > This series looks good enough to me now, if no one has objections, I > > > > will queue it to loongarch-next. > > > > > > Have you not read Rob's replies? > > I'm sorry, I have read but I thought Binbin's reply has answered Rob's question. > > As far as I can tell, it didn't - but there were was a reply from Rob > about dtbs_check issues too IIRC. OK, I see. The dtbs_check warning is being fixed in [1], but it seems that Binbin hasn't got the key point of Krzysztof. https://lore.kernel.org/linux-mips/d11873a1-b552-71f5-1100-7464687f8bb4@linaro.org/T/#t Huacai