mbox series

[v6,0/7] LoongArch: Add built-in dtb support

Message ID cover.1703229766.git.zhoubinbin@loongson.cn
Headers show
Series LoongArch: Add built-in dtb support | expand

Message

Binbin Zhou Dec. 22, 2023, 8 a.m. UTC 
Hi all:

This patchset introduces LoongArch's built-in dtb support.

During the upstream progress of those DT-based drivers, DT properties
are changed a lot so very different from those in existing bootloaders.
It is inevitably that some existing systems do not provide a standard,
canonical device tree to the kernel at boot time. So let's provide a
device tree table in the kernel, keyed by the dts filename, containing
the relevant DTBs.

We can use the built-in dts files as references. Each SoC has only one
built-in dts file which describes all possible device information of
that SoC, so the dts files are good examples during development.

And as a reference, our built-in dts file only enables the most basic
bootable combinations (so it is generic enough), acts as an alternative
in case the dts in the bootloader is unexpected.

In the past while, we resolved the DTC_CHK warning for the v4 patchset,
and the relevant patchset has either been applied or had the
Reviewed-by tag added. 

Now, we need to rely on the following patch sets:
1. liointc
https://lore.kernel.org/all/cover.1701933946.git.zhoubinbin@loongson.cn/
Reviewed-by tag has been added.
2. pmc
https://lore.kernel.org/all/cover.1700817227.git.zhoubinbin@loongson.cn/
has been applied by Daniel.
3. dmac
https://lore.kernel.org/all/cover.1702365725.git.zhoubinbin@loongson.cn/
has been applied by Vinod.

Thanks.

-----
V6:
patch(3/7):
  - Update cmdline handling;
patch(5/7):
  - Drop bootargs;
  - Drop cpu-map;
  - Add dma-controller node;
patch(4/7)(6/7):
  - Drop bootargs;
  - Drop cpu-map;
patch(7/7):
  - Initialize loongson_sysconf.cores_per_package.

Link to V5:
https://lore.kernel.org/all/cover.1702862778.git.zhoubinbin@loongson.cn/

V5:
patch(1/7):
  - Add reviewed-by tag.
patch(3/7):
  - Rewrite commit message to describe the reason for needing the
    build-in DTB.
patch(4/7):
  - Add Power-Manager node.
patch(5/7):
  - Add Power-Manager node.
  - Add spi node.
  - Add pmc node.
patch(6/7):
  - Add Power-Manager node.

Link to V4:
https://lore.kernel.org/all/cover.1692783907.git.zhoubinbin@loongson.cn/

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/Kbuild                         |   1 +
 arch/loongarch/Kconfig                        |  18 +
 arch/loongarch/Makefile                       |   3 +-
 arch/loongarch/boot/dts/Makefile              |   5 +-
 .../boot/dts/loongson-2k0500-ref.dts          |  88 ++++
 arch/loongarch/boot/dts/loongson-2k0500.dtsi  | 266 ++++++++++
 .../boot/dts/loongson-2k1000-ref.dts          | 183 +++++++
 arch/loongarch/boot/dts/loongson-2k1000.dtsi  | 492 ++++++++++++++++++
 .../boot/dts/loongson-2k2000-ref.dts          |  72 +++
 arch/loongarch/boot/dts/loongson-2k2000.dtsi  | 300 +++++++++++
 arch/loongarch/kernel/env.c                   |  34 +-
 arch/loongarch/kernel/setup.c                 |  12 +-
 arch/loongarch/kernel/smp.c                   |   3 +
 15 files changed, 1565 insertions(+), 7 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

Comments

Binbin Zhou Dec. 27, 2023, 6:04 a.m. UTC | #1 
Hi Conor:

Sorry for the late reply.

On Fri, Dec 22, 2023 at 9:39 PM Conor Dooley <conor@kernel.org> wrote:
>
> Hey Binbin,
>
> On Fri, Dec 22, 2023 at 04:00:43PM +0800, Binbin Zhou wrote:
> > Hi all:
> >
> > This patchset introduces LoongArch's built-in dtb support.
> >
> > During the upstream progress of those DT-based drivers, DT properties
> > are changed a lot so very different from those in existing bootloaders.
> > It is inevitably that some existing systems do not provide a standard,
> > canonical device tree to the kernel at boot time. So let's provide a
> > device tree table in the kernel, keyed by the dts filename, containing
> > the relevant DTBs.
> >
> > We can use the built-in dts files as references. Each SoC has only one
> > built-in dts file which describes all possible device information of
> > that SoC, so the dts files are good examples during development.
> >
> > And as a reference, our built-in dts file only enables the most basic
> > bootable combinations (so it is generic enough), acts as an alternative
> > in case the dts in the bootloader is unexpected.
> >
> > In the past while, we resolved the DTC_CHK warning for the v4 patchset,
> > and the relevant patchset has either been applied or had the
> > Reviewed-by tag added.
>
> I notice you dropped the topology information from all patches in the
> series, not only the 2k0500 patch that only has one CPU. I didn't see a
> response to my comments the kernel being able to assemble the topology
> based on the second level caches using the generic topology code for the
> systems that have more than one cpu. With the cpu-map information
> dropped, do the multi-cpu systems have their topologies assembled
> correctly by the kernel?

As we saw previously, our DT-based system only supports single cluster
cpu{s}, and multi-cluster cpu is not going to be in our plans.

> You mentioned that there is an instruction that allows you to get
> information about i and d caches etc, so adding them to the DT is not
> required, but does it also cover the next level caches?

Firstly, sorry for my previous mistake about the cache reads.
`cpucfg` is actually a set of registers that describes the features of
the cpu, including the CPU cache [1].
`populate_cache_properties()` reads all levels of cache information
[2], including of course `next cache` if it exists.

[1]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/loongarch/include/asm/loongarch.h#n765
[2]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/loongarch/mm/cache.c#n94

> The program that I am familiar with for displaying this information
> is hwloc: https://github.com/open-mpi/hwloc
>

Ah, yes, I tried looking at the `hwloc-ls` output before committing,
and it's below(LS2K1000):

[root@fedora ~]# hwloc-ls
Machine (7730MB total)
  Package L#0
    NUMANode L#0 (P#0 7730MB)
    L2 L#0 (1024KB)
      L1d L#0 (32KB) + L1i L#0 (32KB) + Core L#0 + PU L#0 (P#0)
      L1d L#1 (32KB) + L1i L#1 (32KB) + Core L#1 + PU L#1 (P#1)

It's the same as what we actually have.

Thanks.
Binbin
> Cheers,
> Conor.
>
Conor Dooley Dec. 28, 2023, 2:09 p.m. UTC | #2 
On Wed, Dec 27, 2023 at 12:04:59PM +0600, Binbin Zhou wrote:
> 
> Ah, yes, I tried looking at the `hwloc-ls` output before committing,
> and it's below(LS2K1000):
> 
> [root@fedora ~]# hwloc-ls
> Machine (7730MB total)
>   Package L#0
>     NUMANode L#0 (P#0 7730MB)
>     L2 L#0 (1024KB)
>       L1d L#0 (32KB) + L1i L#0 (32KB) + Core L#0 + PU L#0 (P#0)
>       L1d L#1 (32KB) + L1i L#1 (32KB) + Core L#1 + PU L#1 (P#1)
> 
> It's the same as what we actually have.


Yeah, that looks to be about what I would expect, thanks.
Huacai Chen Dec. 29, 2023, 3:10 p.m. UTC | #3 
This series is good enough for me, I will apply it to the loongarch
tree after [1] is merged.

[1] https://lore.kernel.org/loongarch/cover.1701933946.git.zhoubinbin@loongson.cn/T/#t

Huacai

On Thu, Dec 28, 2023 at 10:09 PM Conor Dooley <conor@kernel.org> wrote:
>
> On Wed, Dec 27, 2023 at 12:04:59PM +0600, Binbin Zhou wrote:
> >
> > Ah, yes, I tried looking at the `hwloc-ls` output before committing,
> > and it's below(LS2K1000):
> >
> > [root@fedora ~]# hwloc-ls
> > Machine (7730MB total)
> >   Package L#0
> >     NUMANode L#0 (P#0 7730MB)
> >     L2 L#0 (1024KB)
> >       L1d L#0 (32KB) + L1i L#0 (32KB) + Core L#0 + PU L#0 (P#0)
> >       L1d L#1 (32KB) + L1i L#1 (32KB) + Core L#1 + PU L#1 (P#1)
> >
> > It's the same as what we actually have.
>
>
> Yeah, that looks to be about what I would expect, thanks.
Huacai Chen Jan. 9, 2024, 9:57 a.m. UTC | #4 
Applied to loongarch-next, thanks.

Huacai

On Fri, Dec 29, 2023 at 11:10 PM Huacai Chen <chenhuacai@kernel.org> wrote:
>
> This series is good enough for me, I will apply it to the loongarch
> tree after [1] is merged.
>
> [1] https://lore.kernel.org/loongarch/cover.1701933946.git.zhoubinbin@loongson.cn/T/#t
>
> Huacai
>
> On Thu, Dec 28, 2023 at 10:09 PM Conor Dooley <conor@kernel.org> wrote:
> >
> > On Wed, Dec 27, 2023 at 12:04:59PM +0600, Binbin Zhou wrote:
> > >
> > > Ah, yes, I tried looking at the `hwloc-ls` output before committing,
> > > and it's below(LS2K1000):
> > >
> > > [root@fedora ~]# hwloc-ls
> > > Machine (7730MB total)
> > >   Package L#0
> > >     NUMANode L#0 (P#0 7730MB)
> > >     L2 L#0 (1024KB)
> > >       L1d L#0 (32KB) + L1i L#0 (32KB) + Core L#0 + PU L#0 (P#0)
> > >       L1d L#1 (32KB) + L1i L#1 (32KB) + Core L#1 + PU L#1 (P#1)
> > >
> > > It's the same as what we actually have.
> >
> >
> > Yeah, that looks to be about what I would expect, thanks.
Huacai Chen Jan. 9, 2024, 12:13 p.m. UTC | #5 
Hi,  Krzysztof,

On Tue, Jan 9, 2024 at 7:14 PM Krzysztof Kozlowski
<krzysztof.kozlowski@linaro.org> wrote:
>
> On 09/01/2024 10:57, Huacai Chen wrote:
> > Applied to loongarch-next, thanks.
> >
>
> It's merge window, why do you apply patches? For which cycle?
I'm sorry I forgot to reply to the email when I applied patches, the
patches have already been pulled in linux-next some days before.

Huacai

>
> Best regards,
> Krzysztof
>
Krzysztof Kozlowski Jan. 9, 2024, 1:33 p.m. UTC | #6 
On 09/01/2024 13:13, Huacai Chen wrote:
> Hi,  Krzysztof,
> 
> On Tue, Jan 9, 2024 at 7:14 PM Krzysztof Kozlowski
> <krzysztof.kozlowski@linaro.org> wrote:
>>
>> On 09/01/2024 10:57, Huacai Chen wrote:
>>> Applied to loongarch-next, thanks.
>>>
>>
>> It's merge window, why do you apply patches? For which cycle?
> I'm sorry I forgot to reply to the email when I applied patches, the
> patches have already been pulled in linux-next some days before.

Really? I cannot find them on next-20240108, so what happened?

Are you aware that patches should be in next for "few next cycles"
minimum (which means few days or even a week)?

Best regards,
Krzysztof
Huacai Chen Jan. 9, 2024, 3:02 p.m. UTC | #7 
Hi, Krzysztof,

On Tue, Jan 9, 2024 at 9:33 PM Krzysztof Kozlowski
<krzysztof.kozlowski@linaro.org> wrote:
>
> On 09/01/2024 13:13, Huacai Chen wrote:
> > Hi,  Krzysztof,
> >
> > On Tue, Jan 9, 2024 at 7:14 PM Krzysztof Kozlowski
> > <krzysztof.kozlowski@linaro.org> wrote:
> >>
> >> On 09/01/2024 10:57, Huacai Chen wrote:
> >>> Applied to loongarch-next, thanks.
> >>>
> >>
> >> It's merge window, why do you apply patches? For which cycle?
> > I'm sorry I forgot to reply to the email when I applied patches, the
> > patches have already been pulled in linux-next some days before.
>
> Really? I cannot find them on next-20240108, so what happened?
Hmm, I applied patches two days ago, and they were only pulled in next-20240109.

>
> Are you aware that patches should be in next for "few next cycles"
> minimum (which means few days or even a week)?
Thank you for your reminder, when I sent my first PR, my mentor had
already told me this. So I will wait until next week to send PR for
this series.

Huacai

>
> Best regards,
> Krzysztof
>
>