Re: [PATCH 03/15] kbuild: move non-boot builtin DTBs to .init.rodata section
On Thu, Sep 05, 2024 at 08:47:39AM +0900, Masahiro Yamada wrote:
> Some architectures support embedding boot DTB(s) in vmlinux. These
> architectures, except MIPS and MicroBlaze, expect a single DTB in
> the .dtb.init.rodata section. MIPS embeds multiple DTBs in vmlinux.
> MicroBlaze embeds a DTB in its own __fdt_blob section instead of the
> .dtb.init.rodata section.
>
> For example, RISC-V previously allowed embedding multiple DTBs, but
> only the first DTB in the .dtb.init.rodata section was used. Commit
> 2672031b20f6 ("riscv: dts: Move BUILTIN_DTB_SOURCE to common Kconfig")
> ensured only one boot DTB is embedded.
>
> Meanwhile, commit 7b937cc243e5 ("of: Create of_root if no dtb provided
> by firmware") introduced another DTB into the .dtb.init.rodata section.
>
> The symbol dump (sorted by address) for ARCH=riscv nommu_k210_defconfig
> is now as follows:
>
> 801290e0 D __dtb_start
> 801290e0 D __dtb_k210_generic_begin
> 8012b571 D __dtb_k210_generic_end
> 8012b580 D __dtb_empty_root_begin
> 8012b5c8 D __dtb_empty_root_end
> 8012b5e0 D __dtb_end
>
> The .dtb.init.rodata section contains the following two DTB files:
>
> arch/riscv/boot/dts/canaan/k210_generic.dtb
> drivers/of/empty_root.dtb
>
> This is not an immediate problem because the boot code chooses the
> first DTB, k210_generic.dtb. The second one, empty_root.dtb is ignored.
> However, relying on the link order (i.e., the order in Makefiles) is
> fragile.
>
> Only the boot DTB should be placed in the .dtb.init.rodata because the
> arch boot code generally does not know the DT name, thus it uses the
> __dtb_start symbol to find it.
>
> empty_root.dtb is looked up by name, so it can be moved to the generic
> .init.rodata section.
>
> When CONFIG_OF_UNITTEST is enabled, more unittest DTBOs are embedded in
> the .dtb.init.rodata section. These are also looked up by name, so can
> be moved to the .init.rodata section.
>
> I added the __initdata annotation to the overlay_info data array because
> modpost knows the .init.rodata section is discarded, and would otherwise
> warn about it.
>
> The implementation is kind of cheesy; the section is .dtb.init.rodata
> under the arch/ directory, and .init.rodata section otherwise. This will
> be refactored later.
>
> Signed-off-by: Masahiro Yamada
> ---
>
> drivers/of/unittest.c | 2 +-
> scripts/Makefile.dtbs | 4 +++-
> 2 files changed, 4 insertions(+), 2 deletions(-)
Reviewed-by: Rob Herring (Arm)
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 14/15] kbuild: rename CONFIG_GENERIC_BUILTIN_DTB to CONFIG_BUILTIN_DTB
On Thu, Sep 05, 2024 at 08:47:50AM +0900, Masahiro Yamada wrote: > Now that all architectures have migrated to the generic built-in > DTB support, the GENERIC_ prefix is no longer necessary. > > Signed-off-by: Masahiro Yamada > --- > > Makefile | 2 +- > arch/arc/Kconfig | 2 +- > arch/loongarch/Kconfig | 1 - > arch/microblaze/Kconfig | 2 +- > arch/mips/Kconfig| 1 - > arch/nios2/platform/Kconfig.platform | 1 - > arch/openrisc/Kconfig| 2 +- > arch/riscv/Kconfig | 1 - > arch/sh/Kconfig | 1 - > arch/xtensa/Kconfig | 2 +- > drivers/of/Kconfig | 2 +- > scripts/Makefile.vmlinux | 2 +- > scripts/link-vmlinux.sh | 2 +- > 13 files changed, 8 insertions(+), 13 deletions(-) > diff --git a/arch/loongarch/Kconfig b/arch/loongarch/Kconfig > index e1d3e5fb6fd2..70f169210b52 100644 > --- a/arch/loongarch/Kconfig > +++ b/arch/loongarch/Kconfig > @@ -388,7 +388,6 @@ endchoice > config BUILTIN_DTB > bool "Enable built-in dtb in kernel" > depends on OF > - select GENERIC_BUILTIN_DTB > help > Some existing systems do not provide a canonical device tree to > the kernel at boot time. Let's provide a device tree table in the > diff --git a/arch/nios2/platform/Kconfig.platform > b/arch/nios2/platform/Kconfig.platform > index c75cadd92388..5f0cf551b5ca 100644 > --- a/arch/nios2/platform/Kconfig.platform > +++ b/arch/nios2/platform/Kconfig.platform > @@ -38,7 +38,6 @@ config NIOS2_DTB_PHYS_ADDR > config BUILTIN_DTB > bool "Compile and link device tree into kernel image" > depends on !COMPILE_TEST > - select GENERIC_BUILTIN_DTB > --- a/arch/riscv/Kconfig > +++ b/arch/riscv/Kconfig > @@ -1110,7 +1110,6 @@ config RISCV_ISA_FALLBACK > config BUILTIN_DTB > bool "Built-in device tree" > depends on OF && NONPORTABLE Humm, maybe this NONPORTABLE option could be common and used to accomplish what I want here... > - select GENERIC_BUILTIN_DTB > diff --git a/arch/sh/Kconfig b/arch/sh/Kconfig > index 3b772378773f..b09019cd87d4 100644 > --- a/arch/sh/Kconfig > +++ b/arch/sh/Kconfig > @@ -648,7 +648,6 @@ config BUILTIN_DTB > bool "Use builtin DTB" > default n > depends on SH_DEVICE_TREE > - select GENERIC_BUILTIN_DTB > diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig > index 5142e7d7fef8..53a227ca3a3c 100644 > --- a/drivers/of/Kconfig > +++ b/drivers/of/Kconfig > @@ -2,7 +2,7 @@ > config DTC > bool > > -config GENERIC_BUILTIN_DTB > +config BUILTIN_DTB > bool I'm confused. We can't have the same config option twice, can we? Rob ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 04/15] kbuild: add generic support for built-in boot DTBs
On Thu, Sep 05, 2024 at 08:47:40AM +0900, Masahiro Yamada wrote:
> Some architectures embed boot DTBs in vmlinux. A potential issue for
> these architectures is a race condition during parallel builds because
> Kbuild descends into arch/*/boot/dts/ twice.
>
> One build thread is initiated by the 'dtbs' target, which is a
> prerequisite of the 'all' target in the top-level Makefile:
>
> ifdef CONFIG_OF_EARLY_FLATTREE
> all: dtbs
> endif
>
> For architectures that support the embedded boot dtb, arch/*/boot/dts/
> is visited also during the ordinary directory traversal in order to
> build obj-y objects that wrap DTBs.
>
> Since these build threads are unaware of each other, they can run
> simultaneously during parallel builds.
>
> This commit introduces a generic build rule to scripts/Makefile.vmlinux
> to support embedded boot DTBs in a race-free way. Architectures that
> want to use this rule need to select CONFIG_GENERIC_BUILTIN_DTB.
>
> After the migration, Makefiles under arch/*/boot/dts/ will be visited
> only once to build only *.dtb files.
>
> This change also aims to unify the CONFIG options used for embedded DTBs
> support. Currently, different architectures use different CONFIG options
> for the same purposes.
>
> The CONFIG options are unified as follows:
>
> - CONFIG_GENERIC_BUILTIN_DTB
>
>This enables the generic rule for embedded boot DTBs. This will be
>renamed to CONFIG_BUILTIN_DTB after all architectures migrate to the
>generic rule.
>
> - CONFIG_BUILTIN_DTB_NAME
>
>This specifies the path to the embedded DTB.
>(relative to arch/*/boot/dts/)
>
> - CONFIG_BUILTIN_DTB_ALL
>
>If this is enabled, all DTB files compiled under arch/*/boot/dts/ are
>embedded into vmlinux. Only used by MIPS.
I started to do this a long time ago, but then decided we didn't want to
encourage this feature. IMO it should only be for legacy bootloaders or
development/debug. And really, appended DTB is more flexible for the
legacy bootloader case.
In hindsight, a common config would have been easier to limit new
arches...
>
> Signed-off-by: Masahiro Yamada
> ---
>
> Makefile | 7 ++-
> drivers/of/Kconfig | 6 ++
> scripts/Makefile.vmlinux | 44
> scripts/link-vmlinux.sh | 4
> 4 files changed, 60 insertions(+), 1 deletion(-)
>
> diff --git a/Makefile b/Makefile
> index 145112bf281a..1c765c12ab9e 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1417,6 +1417,10 @@ ifdef CONFIG_OF_EARLY_FLATTREE
> all: dtbs
> endif
>
> +ifdef CONFIG_GENERIC_BUILTIN_DTB
> +vmlinux: dtbs
> +endif
> +
> endif
>
> PHONY += scripts_dtc
> @@ -1483,7 +1487,8 @@ endif # CONFIG_MODULES
> CLEAN_FILES += vmlinux.symvers modules-only.symvers \
> modules.builtin modules.builtin.modinfo modules.nsdeps \
> compile_commands.json rust/test \
> -rust-project.json .vmlinux.objs .vmlinux.export.c
> +rust-project.json .vmlinux.objs .vmlinux.export.c \
> + .builtin-dtbs-list .builtin-dtb.S
>
> # Directories & files removed with 'make mrproper'
> MRPROPER_FILES += include/config include/generated \
> diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig
> index dd726c7056bf..5142e7d7fef8 100644
> --- a/drivers/of/Kconfig
> +++ b/drivers/of/Kconfig
> @@ -2,6 +2,12 @@
> config DTC
> bool
>
> +config GENERIC_BUILTIN_DTB
> + bool
So that we don't add new architectures to this, I would like something
like:
# Do not add new architectures to this list
depends on MIPS || RISCV || MICROBLAZE ...
Yes, it's kind of odd since the arch selects the option...
For sure, we don't want this option on arm64. For that, I can rely on
Will and Catalin rejecting a select, but on some new arch I can't.
> +
> +config BUILTIN_DTB_ALL
> + bool
Can this be limited to MIPS?
> +
> menuconfig OF
> bool "Device Tree and Open Firmware support"
> help
> diff --git a/scripts/Makefile.vmlinux b/scripts/Makefile.vmlinux
> index 5ceecbed31eb..4626b472da49 100644
> --- a/scripts/Makefile.vmlinux
> +++ b/scripts/Makefile.vmlinux
> @@ -17,6 +17,50 @@ quiet_cmd_cc_o_c = CC $@
> %.o: %.c FORCE
> $(call if_changed_dep,cc_o_c)
>
> +quiet_cmd_as_o_S = AS $@
> + cmd_as_o_S = $(CC) $(a_flags) -c -o $@ $<
> +
> +%.o: %.S FORCE
> + $(call if_changed_dep,as_o_S)
> +
> +# Built-in dtb
> +# ---
> +
> +quiet_cmd_wrap_dtbs = WRAP$@
> + cmd_wrap_dtbs = {
> \
> + echo '\#include '; \
> + echo '.section .dtb.init.rodata,"a"'; \
> + while read dtb; do \
> + symbase=__dtb_$$(basename -s .dtb "$${dtb}" | tr - _); \
> + echo '.balign STRUCT_ALIGNMENT';\
Is
Re: [PATCH 02/15] kbuild: split device tree build rules into scripts/Makefile.dtbs
On Thu, Sep 05, 2024 at 08:47:38AM +0900, Masahiro Yamada wrote:
> scripts/Makefile.lib is included not only from scripts/Makefile.build
> but also from scripts/Makefile.{modfinal,package,vmlinux,vmlinux_o},
> where DT build rules are not required.
>
> Split the DT build rules out to scripts/Makefile.dtbs, and include it
> only when necessary.
>
> Signed-off-by: Masahiro Yamada
> ---
>
> drivers/of/fdt.c | 2 +-
> drivers/of/unittest.c | 4 +-
> scripts/Makefile.build | 25 +++-
> scripts/Makefile.dtbs | 142 +
> scripts/Makefile.lib | 115 -
> 5 files changed, 153 insertions(+), 135 deletions(-)
> create mode 100644 scripts/Makefile.dtbs
Reviewed-by: Rob Herring (Arm)
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [RFC PATCH] dt-bindings: arc: convert archs-pct.txt to yaml
On Sat, 17 Aug 2024 08:56:29 +0530, Aryabhatta Dey wrote: > Convert dt-binding archs-pct from txt to yaml format. > > Signed-off-by: Aryabhatta Dey > --- > .../devicetree/bindings/arc/archs-pct.txt | 17 -- > .../bindings/arc/snps,archs-pct.yaml | 33 +++ > 2 files changed, 33 insertions(+), 17 deletions(-) > delete mode 100644 Documentation/devicetree/bindings/arc/archs-pct.txt > create mode 100644 Documentation/devicetree/bindings/arc/snps,archs-pct.yaml > Applied, thanks! However, if you are going to do more conversions, please pick ones more widely used first as Krzysztof pointed out. Rob ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH] dt-bindings: pct: Convert to dtschema
On Fri, 08 Mar 2024 02:18:42 +, Dorine Tipo wrote: > convert the PCT Arc Performance Counter bindings to DT schema > > Signed-off-by: Dorine Tipo > --- > .../devicetree/bindings/arc/pct.yaml | 36 +++ > 1 file changed, 36 insertions(+) > create mode 100644 Documentation/devicetree/bindings/arc/pct.yaml > My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check' on your patch (DT_CHECKER_FLAGS is new in v5.13): yamllint warnings/errors: dtschema/dtc warnings/errors: /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/arc/pct.example.dtb: pmu: 'reg' is a required property from schema $id: http://devicetree.org/schemas/pct.yaml# doc reference errors (make refcheckdocs): See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20240308021842.1975-1-dorine.a.t...@gmail.com The base for the series is generally the latest rc1. A different dependency should be noted in *this* patch. If you already ran 'make dt_binding_check' and didn't see the above error(s), then make sure 'yamllint' is installed and dt-schema is up to date: pip3 install dtschema --upgrade Please check and re-submit after running the above command yourself. Note that DT_SCHEMA_FILES can be set to your schema file to speed up checking your schema. However, it must be unset to test all examples with your schema. ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH RFC 01/17] iommu: Remove struct iommu_ops *iommu from arch_setup_dma_ops()
On Fri, Nov 03, 2023 at 01:44:46PM -0300, Jason Gunthorpe wrote: > This is not being used to pass ops, it is just a way to tell if an > iommu driver was probed. These days this can be detected directly via > device_iommu_mapped(). Call device_iommu_mapped() in the two places that > need to check it and remove the iommu parameter everywhere. > > Signed-off-by: Jason Gunthorpe > --- > arch/arc/mm/dma.c | 2 +- > arch/arm/mm/dma-mapping-nommu.c | 2 +- > arch/arm/mm/dma-mapping.c | 10 +- > arch/arm64/mm/dma-mapping.c | 4 ++-- > arch/mips/mm/dma-noncoherent.c | 2 +- > arch/riscv/mm/dma-noncoherent.c | 2 +- > drivers/acpi/scan.c | 3 +-- > drivers/hv/hv_common.c | 2 +- > drivers/of/device.c | 2 +- Acked-by: Rob Herring > include/linux/dma-map-ops.h | 4 ++-- > 10 files changed, 16 insertions(+), 17 deletions(-) ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH RFC 02/17] of: Do not return struct iommu_ops from of_iommu_configure()
On Fri, Nov 03, 2023 at 01:44:47PM -0300, Jason Gunthorpe wrote: > Nothing needs this pointer. Return a normal error code with the usual > IOMMU semantic that ENODEV means 'there is no IOMMU driver'. > > Signed-off-by: Jason Gunthorpe > --- > drivers/iommu/of_iommu.c | 29 ++--- > drivers/of/device.c | 22 +++++++++++--- Acked-by: Rob Herring > include/linux/of_iommu.h | 13 ++--- > 3 files changed, 39 insertions(+), 25 deletions(-) ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH RFC 03/17] of: Use -ENODEV consistently in of_iommu_configure()
On Fri, Nov 03, 2023 at 01:44:48PM -0300, Jason Gunthorpe wrote: > Instead of returning 1 and trying to handle positive error codes just > stick to the convention of returning -ENODEV. Remove references to ops > from of_iommu_configure(), a NULL ops will already generate an error code. nit: "iommu: of: ..." or "iommu/of: " for the subject. "of: ..." is generally drivers/of/. > > There is no reason to check dev->bus, if err=0 at this point then the > called configure functions thought there was an iommu and we should try to > probe it. Remove it. > > Signed-off-by: Jason Gunthorpe > --- > drivers/iommu/of_iommu.c | 42 +--- > 1 file changed, 13 insertions(+), 29 deletions(-) ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH] arc: Explicitly include correct DT includes
On Fri, Jul 14, 2023 at 11:39:49AM -0600, Rob Herring wrote: > The DT of_device.h and of_platform.h date back to the separate > of_platform_bus_type before it as merged into the regular platform bus. > As part of that merge prepping Arm DT support 13 years ago, they > "temporarily" include each other. They also include platform_device.h > and of.h. As a result, there's a pretty much random mix of those include > files used throughout the tree. In order to detangle these headers and > replace the implicit includes with struct declarations, users need to > explicitly include the correct includes. > > Signed-off-by: Rob Herring > --- > arch/arc/plat-axs10x/axs10x.c | 1 - > 1 file changed, 1 deletion(-) Ping! > > diff --git a/arch/arc/plat-axs10x/axs10x.c b/arch/arc/plat-axs10x/axs10x.c > index b821df7b0089..1feb990a56bc 100644 > --- a/arch/arc/plat-axs10x/axs10x.c > +++ b/arch/arc/plat-axs10x/axs10x.c > @@ -6,7 +6,6 @@ > */ > > #include > -#include > #include > > #include > -- > 2.40.1 > ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[PATCH] arc: Explicitly include correct DT includes
The DT of_device.h and of_platform.h date back to the separate of_platform_bus_type before it as merged into the regular platform bus. As part of that merge prepping Arm DT support 13 years ago, they "temporarily" include each other. They also include platform_device.h and of.h. As a result, there's a pretty much random mix of those include files used throughout the tree. In order to detangle these headers and replace the implicit includes with struct declarations, users need to explicitly include the correct includes. Signed-off-by: Rob Herring --- arch/arc/plat-axs10x/axs10x.c | 1 - 1 file changed, 1 deletion(-) diff --git a/arch/arc/plat-axs10x/axs10x.c b/arch/arc/plat-axs10x/axs10x.c index b821df7b0089..1feb990a56bc 100644 --- a/arch/arc/plat-axs10x/axs10x.c +++ b/arch/arc/plat-axs10x/axs10x.c @@ -6,7 +6,6 @@ */ #include -#include #include #include -- 2.40.1 ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH] serial: arc_uart: fix of_iomap leak in `arc_serial_probe`
On Tue, Apr 25, 2023 at 8:27 PM Ke Zhang wrote:
>
> Smatch reports:
>
> drivers/tty/serial/arc_uart.c:631 arc_serial_probe() warn:
> 'port->membase' from of_iomap() not released on lines: 631.
>
> In arc_serial_probe(), if uart_add_one_port() fails,
> port->membase is not released, which would cause a resource leak.
>
> To fix this, I replace of_iomap with devm_of_iomap.
How about use devm_platform_ioremap_resource() instead (or any ioremap
variant) as that is preferred over of_iomap().
Rob
>
> Fixes: 8dbe1d5e09a7 ("serial/arc: inline the probe helper")
> Signed-off-by: Ke Zhang
> Reviewed-by: Dongliang Mu
> ---
> This issue is found by static analysis and remains untested.
> ---
> drivers/tty/serial/arc_uart.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/tty/serial/arc_uart.c b/drivers/tty/serial/arc_uart.c
> index 59e25f2b6632..be1f3c379382 100644
> --- a/drivers/tty/serial/arc_uart.c
> +++ b/drivers/tty/serial/arc_uart.c
> @@ -606,10 +606,11 @@ static int arc_serial_probe(struct platform_device
> *pdev)
> }
> uart->baud = val;
>
> - port->membase = of_iomap(np, 0);
> - if (!port->membase)
> + port->membase = devm_of_iomap(&pdev->dev, np, 0, NULL);
> + if (IS_ERR(port->membase)) {
> /* No point of dev_err since UART itself is hosed here */
> return -ENXIO;
If an errno was returned, you should return that errno and not a different one.
Rob
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v2 0/2] Fix console probe delay when stdout-path isn't set
On Mon, Sep 19, 2022 at 5:56 PM Olof Johansson wrote: > > On Mon, Sep 19, 2022 at 1:44 AM Greg Kroah-Hartman > wrote: > > > > On Sun, Sep 18, 2022 at 08:44:27PM -0700, Olof Johansson wrote: > > > On Tue, Aug 23, 2022 at 8:37 AM Greg Kroah-Hartman > > > wrote: > > > > > > > > On Thu, Jun 30, 2022 at 06:26:38PM -0700, Saravana Kannan wrote: > > > > > These patches are on top of driver-core-next. > > > > > > > > > > Even if stdout-path isn't set in DT, this patch should take console > > > > > probe times back to how they were before the deferred_probe_timeout > > > > > clean up series[1]. > > > > > > > > Now dropped from my queue due to lack of a response to other reviewer's > > > > questions. > > > > > > What happened to this patch? I have a 10 second timeout on console > > > probe on my SiFive Unmatched, and I don't see this flag being set for > > > the serial driver. In fact, I don't see it anywhere in-tree. I can't > > > seem to locate another patchset from Saravana around this though, so > > > I'm not sure where to look for a missing piece for the sifive serial > > > driver. > > > > > > This is the second boot time regression (this one not fatal, unlike > > > the Layerscape PCIe one) from the fw_devlink patchset. > > > > > > Greg, can you revert the whole set for 6.0, please? It's obviously > > > nowhere near tested enough to go in and I expect we'll see a bunch of > > > -stable fixups due to this if we let it remain in. > > > > What exactly is "the whole set"? I have the default option fix queued > > up and will send that to Linus later this week (am traveling back from > > Plumbers still), but have not heard any problems about any other issues > > at all other than your report. > > I stand corrected in this case, the issue on the Hifive Unmatched was > a regression due to a PWM clock change -- I just sent a patch for that > (serial driver fix). > > So it seems like as long as the fw_devlink.strict=1 patch is reverted, > things are back to a working state here. > > I still struggle with how the fw_devlink patchset is expected to work > though, since DT is expected to describe the hardware configuration, > and it has no knowledge of whether there are drivers that will be > bound to any referenced supplier devnodes. It's not going to work well > to assume that they will always be bound, and to add 10 second > timeouts for those cases isn't a good solution. Seems like the number > of special cases will keep adding up. Since the introduction of deferred probe, the kernel has always assumed if there is a device described, then there is or will be a driver for it. The result is you can't use new DTs (if they add providers) with older kernels. We've ended up with a timeout because no one has come up with a better way to handle it. What the kernel needs is userspace saying "I'm done loading modules", but it's debatable whether that's a good solution too. Rob ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 0/2] of: remove reserved regions count restriction
On Sun, Nov 21, 2021 at 08:43:47AM +0200, Mike Rapoport wrote: > On Fri, Nov 19, 2021 at 03:58:17PM +0800, Calvin Zhang wrote: > > The count of reserved regions in /reserved-memory was limited because > > the struct reserved_mem array was defined statically. This series sorts > > out reserved memory code and allocates that array from early allocator. > > > > Note: reserved region with fixed location must be reserved before any > > memory allocation. While struct reserved_mem array should be allocated > > after allocator is activated. We make early_init_fdt_scan_reserved_mem() > > do reservation only and add another call to initialize reserved memory. > > So arch code have to change for it. > > I think much simpler would be to use the same constant for sizing > memblock.reserved and reserved_mem arrays. Do those arrays get shrunk? Or do we waste the memory forever? Maybe we can copy and shrink the initial array? Though I suspect struct reserved_mem pointers have already been given out. > > If there is too much reserved regions in the device tree, reserving them in > memblock will fail anyway because memblock also starts with static array > for memblock.reserved, so doing one pass with memblock_reserve() and > another to set up reserved_mem wouldn't help anyway. > > > I'm only familiar with arm and arm64 architectures. Approvals from arch > > maintainers are required. Thank you all. > > > > Calvin Zhang (2): > > of: Sort reserved_mem related code > > of: reserved_mem: Remove reserved regions count restriction > > > > arch/arc/mm/init.c | 3 + > > arch/arm/kernel/setup.c| 2 + > > arch/arm64/kernel/setup.c | 3 + > > arch/csky/kernel/setup.c | 3 + > > arch/h8300/kernel/setup.c | 2 + > > arch/mips/kernel/setup.c | 3 + > > arch/nds32/kernel/setup.c | 3 + > > arch/nios2/kernel/setup.c | 2 + > > arch/openrisc/kernel/setup.c | 3 + > > arch/powerpc/kernel/setup-common.c | 3 + > > arch/riscv/kernel/setup.c | 2 + > > arch/sh/kernel/setup.c | 3 + > > arch/xtensa/kernel/setup.c | 2 + > > drivers/of/fdt.c | 107 +--- > > drivers/of/of_private.h| 12 +- > > drivers/of/of_reserved_mem.c | 189 - > > include/linux/of_reserved_mem.h| 4 + > > 17 files changed, 207 insertions(+), 139 deletions(-) > > > > -- > > 2.30.2 > > > > -- > Sincerely yours, > Mike. > ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 1/2] of: Sort reserved_mem related code
On Fri, Nov 19, 2021 at 03:58:18PM +0800, Calvin Zhang wrote:
> Move code about parsing /reserved-memory and initializing of
> reserved_mems array to of_reserved_mem.c for better modularity.
>
> Rename array name from reserved_mem to reserved_mems to distinguish
> from type definition.
>
> Signed-off-by: Calvin Zhang
> ---
> drivers/of/fdt.c| 108 +
> drivers/of/of_private.h | 12 ++-
> drivers/of/of_reserved_mem.c| 163 ++--
> include/linux/of_reserved_mem.h | 4 +
> 4 files changed, 149 insertions(+), 138 deletions(-)
>
> diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
> index bdca35284ceb..445af4e69300 100644
> --- a/drivers/of/fdt.c
> +++ b/drivers/of/fdt.c
> @@ -80,7 +80,7 @@ void __init of_fdt_limit_memory(int limit)
> }
> }
>
> -static bool of_fdt_device_is_available(const void *blob, unsigned long node)
> +bool of_fdt_device_is_available(const void *blob, unsigned long node)
> {
> const char *status = fdt_getprop(blob, node, "status", NULL);
>
> @@ -476,7 +476,7 @@ void *initial_boot_params __ro_after_init;
>
> static u32 of_fdt_crc32;
>
> -static int __init early_init_dt_reserve_memory_arch(phys_addr_t base,
> +int __init early_init_dt_reserve_memory_arch(phys_addr_t base,
> phys_addr_t size, bool nomap)
I think you can move this function too if you change the nomap==false
callers to just call memblock_reserve directly.
> {
> if (nomap) {
> @@ -492,108 +492,6 @@ static int __init
> early_init_dt_reserve_memory_arch(phys_addr_t base,
> return memblock_reserve(base, size);
> }
>
> -/*
> - * __reserved_mem_reserve_reg() - reserve all memory described in 'reg'
> property
> - */
> -static int __init __reserved_mem_reserve_reg(unsigned long node,
> - const char *uname)
> -{
> - int t_len = (dt_root_addr_cells + dt_root_size_cells) * sizeof(__be32);
> - phys_addr_t base, size;
> - int len;
> - const __be32 *prop;
> - int first = 1;
> - bool nomap;
> -
> - prop = of_get_flat_dt_prop(node, "reg", &len);
> - if (!prop)
> - return -ENOENT;
> -
> - if (len && len % t_len != 0) {
> - pr_err("Reserved memory: invalid reg property in '%s', skipping
> node.\n",
> -uname);
> - return -EINVAL;
> - }
> -
> - nomap = of_get_flat_dt_prop(node, "no-map", NULL) != NULL;
> -
> - while (len >= t_len) {
> - base = dt_mem_next_cell(dt_root_addr_cells, &prop);
> - size = dt_mem_next_cell(dt_root_size_cells, &prop);
> -
> - if (size &&
> - early_init_dt_reserve_memory_arch(base, size, nomap) == 0)
> - pr_debug("Reserved memory: reserved region for node
> '%s': base %pa, size %lu MiB\n",
> - uname, &base, (unsigned long)(size / SZ_1M));
> - else
> - pr_info("Reserved memory: failed to reserve memory for
> node '%s': base %pa, size %lu MiB\n",
> - uname, &base, (unsigned long)(size / SZ_1M));
> -
> - len -= t_len;
> - if (first) {
> - fdt_reserved_mem_save_node(node, uname, base, size);
> - first = 0;
> - }
> - }
> - return 0;
> -}
> -
> -/*
> - * __reserved_mem_check_root() - check if #size-cells, #address-cells
> provided
> - * in /reserved-memory matches the values supported by the current
> implementation,
> - * also check if ranges property has been provided
> - */
> -static int __init __reserved_mem_check_root(unsigned long node)
> -{
> - const __be32 *prop;
> -
> - prop = of_get_flat_dt_prop(node, "#size-cells", NULL);
> - if (!prop || be32_to_cpup(prop) != dt_root_size_cells)
> - return -EINVAL;
> -
> - prop = of_get_flat_dt_prop(node, "#address-cells", NULL);
> - if (!prop || be32_to_cpup(prop) != dt_root_addr_cells)
> - return -EINVAL;
> -
> - prop = of_get_flat_dt_prop(node, "ranges", NULL);
> - if (!prop)
> - return -EINVAL;
> - return 0;
> -}
> -
> -/*
> - * fdt_scan_reserved_mem() - scan a single FDT node for reserved memory
> - */
> -static int __init fdt_scan_reserved_mem(void)
> -{
> - int node, child;
> - const void *fdt = initial_boot_params;
> -
> - node = fdt_path_offset(fdt, "/reserved-memory");
> - if (node < 0)
> - return -ENODEV;
> -
> - if (__reserved_mem_check_root(node) != 0) {
> - pr_err("Reserved memory: unsupported node format, ignoring\n");
> - return -EINVAL;
> - }
> -
> - fdt_for_each_subnode(child, fdt, node) {
> - const char *uname;
> - int err;
> -
> - if (!of_fdt_device_is_available(fdt, child))
> - continue;
> -
> - uname = fdt_get_name(fdt,
Re: [PATCH v5 12/19] dt-bindings: usb: dwc3: Add synopsys, dwc3 compatible string
On Sat, 05 Dec 2020 18:24:19 +0300, Serge Semin wrote: > The DWC USB3 driver and some DTS files like Exynos 5250, Keystone k2e, etc > expects the DWC USB3 DT node to have the compatible string with the > "synopsys" vendor prefix. Let's add the corresponding compatible string to > the controller DT schema, but mark it as deprecated seeing the Synopsys, > Inc. is presented with just "snps" vendor prefix. > > Signed-off-by: Serge Semin > > --- > > Changelog v2: > - Drop quotes from around the compat string constant. > > Changelog v4: > - Get the patch back, since we can't discard the deprecated prefix from the > driver. > --- > Documentation/devicetree/bindings/usb/snps,dwc3.yaml | 5 - > 1 file changed, 4 insertions(+), 1 deletion(-) > Reviewed-by: Rob Herring ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v5 01/19] dt-bindings: usb: usb-hcd: Detach generic USB controller properties
On Sat, 05 Dec 2020 18:24:08 +0300, Serge Semin wrote: > There can be three distinctive types of the USB controllers: USB hosts, > USB peripherals/gadgets and USB OTG, which can switch from one role to > another. In order to have that hierarchy handled in the DT binding files, > we need to collect common properties in a common DT schema and specific > properties in dedicated schemas. Seeing the usb-hcd.yaml DT schema is > dedicated for the USB host controllers only, let's move some common > properties from there into the usb.yaml schema. So the later would be > available to evaluate all currently supported types of the USB > controllers. > > While at it add an explicit "additionalProperties: true" into the > usb-hcd.yaml as setting the additionalProperties/unevaluateProperties > properties is going to be get mandatory soon. > > Signed-off-by: Serge Semin > > --- > > Changelog v4: > - This is a new patch created as a result of the comment left > by Chunfeng Yun in v3 > > Changelog v5: > - Discard duplicated additionalProperties property definition. > --- > .../devicetree/bindings/usb/usb-hcd.yaml | 14 ++--- > .../devicetree/bindings/usb/usb.yaml | 29 +++ > 2 files changed, 31 insertions(+), 12 deletions(-) > create mode 100644 Documentation/devicetree/bindings/usb/usb.yaml > Reviewed-by: Rob Herring ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v5 10/19] dt-bindings: usb: Convert DWC USB3 bindings to DT schema
On Sat, 05 Dec 2020 18:24:17 +0300, Serge Semin wrote: > DWC USB3 DT node is supposed to be compliant with the Generic xHCI > Controller schema, but with additional vendor-specific properties, the > controller-specific reference clocks and PHYs. So let's convert the > currently available legacy text-based DWC USB3 bindings to the DT schema > and make sure the DWC USB3 nodes are also validated against the > usb-xhci.yaml schema. > > Note 1. we have to discard the nodename restriction of being prefixed with > "dwc3@" string, since in accordance with the usb-hcd.yaml schema USB nodes > are supposed to be named as "^usb(@.*)". > > Note 2. The clock-related properties are marked as optional to match the > DWC USB3 driver expectation and to improve the bindings mainainability > so in case if there is a glue-node it would the responsible for the > clocks initialization. > > Signed-off-by: Serge Semin > > --- > > Changelog v2: > - Discard '|' from the descriptions, since we don't need to preserve > the text formatting in any of them. > - Drop quotes from around the string constants. > - Fix the "clock-names" prop description to be referring the enumerated > clock-names instead of the ones from the Databook. > > Changelog v3: > - Apply usb-xhci.yaml# schema only if the controller is supposed to work > as either host or otg. > > Changelog v4: > - Apply usb-drd.yaml schema first. If the controller is configured > to work in a gadget mode only, then apply the usb.yaml schema too, > otherwise apply the usb-xhci.yaml schema. > - Discard the Rob'es Reviewed-by tag. Please review the patch one more > time. > > Changelog v5: > - Add "snps,dis-split-quirk" property to the DWC USB3 DT schema. > - Add a commit log text about the clock-related property changes. > - Make sure dr_mode exist to apply the USB-gadget-only schema. > --- > .../devicetree/bindings/usb/dwc3.txt | 128 --- > .../devicetree/bindings/usb/snps,dwc3.yaml| 312 ++ > 2 files changed, 312 insertions(+), 128 deletions(-) > delete mode 100644 Documentation/devicetree/bindings/usb/dwc3.txt > create mode 100644 Documentation/devicetree/bindings/usb/snps,dwc3.yaml > Reviewed-by: Rob Herring ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v5 19/19] dt-bindings: usb: intel, keembay-dwc3: Validate DWC3 sub-node
On Sat, 05 Dec 2020 18:24:26 +0300, Serge Semin wrote:
> Intel Keem Bay DWC3 compatible DT nodes are supposed to have a DWC USB3
> compatible sub-node to describe a fully functioning USB interface. Let's
> use the available DWC USB3 DT schema to validate the Qualcomm DWC3
> sub-nodes.
>
> Note since the generic DWC USB3 DT node is supposed to be named as generic
> USB HCD ("^usb(@.*)?") one we have to accordingly fix the sub-nodes name
> regexp and fix the DT node example.
>
> Signed-off-by: Serge Semin
>
> ---
>
> Changelog v5:
> - This is a new patch created for the new Intel Keem Bay bindings file,
> which has been added just recently.
> ---
> .../devicetree/bindings/usb/intel,keembay-dwc3.yaml | 9 +++--
> 1 file changed, 3 insertions(+), 6 deletions(-)
>
Reviewed-by: Rob Herring
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v5 01/19] dt-bindings: usb: usb-hcd: Detach generic USB controller properties
On Sat, 05 Dec 2020 18:24:08 +0300, Serge Semin wrote: > There can be three distinctive types of the USB controllers: USB hosts, > USB peripherals/gadgets and USB OTG, which can switch from one role to > another. In order to have that hierarchy handled in the DT binding files, > we need to collect common properties in a common DT schema and specific > properties in dedicated schemas. Seeing the usb-hcd.yaml DT schema is > dedicated for the USB host controllers only, let's move some common > properties from there into the usb.yaml schema. So the later would be > available to evaluate all currently supported types of the USB > controllers. > > While at it add an explicit "additionalProperties: true" into the > usb-hcd.yaml as setting the additionalProperties/unevaluateProperties > properties is going to be get mandatory soon. > > Signed-off-by: Serge Semin > > --- > > Changelog v4: > - This is a new patch created as a result of the comment left > by Chunfeng Yun in v3 > > Changelog v5: > - Discard duplicated additionalProperties property definition. > --- > .../devicetree/bindings/usb/usb-hcd.yaml | 14 ++--- > .../devicetree/bindings/usb/usb.yaml | 29 +++ > 2 files changed, 31 insertions(+), 12 deletions(-) > create mode 100644 Documentation/devicetree/bindings/usb/usb.yaml > My bot found errors running 'make dt_binding_check' on your patch: yamllint warnings/errors: dtschema/dtc warnings/errors: schemas/usb/usb-hcd.yaml: ignoring, error in schema: /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/usb/usb-hcd.yaml: 'anyOf' conditional failed, one must be fixed: 'properties' is a required property 'patternProperties' is a required property schemas/usb/usb-hcd.yaml: ignoring, error in schema: /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/usb/usb-hcd.yaml: ignoring, error in schema: warning: no schema found in file: ./Documentation/devicetree/bindings/usb/usb-hcd.yaml schemas/usb/usb-hcd.yaml: ignoring, error in schema: dt-validate: recursion error: Check for prior errors in a referenced schema schemas/usb/usb-hcd.yaml: ignoring, error in schema: dt-validate: recursion error: Check for prior errors in a referenced schema schemas/usb/usb-hcd.yaml: ignoring, error in schema: dt-validate: recursion error: Check for prior errors in a referenced schema schemas/usb/usb-hcd.yaml: ignoring, error in schema: dt-validate: recursion error: Check for prior errors in a referenced schema schemas/usb/usb-hcd.yaml: ignoring, error in schema: dt-validate: recursion error: Check for prior errors in a referenced schema dt-validate: recursion error: Check for prior errors in a referenced schema See https://patchwork.ozlabs.org/patch/1411574 The base for the patch is generally the last rc1. Any dependencies should be noted. If you already ran 'make dt_binding_check' and didn't see the above error(s), then make sure 'yamllint' is installed and dt-schema is up to date: pip3 install dtschema --upgrade Please check and re-submit. ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v5 10/19] dt-bindings: usb: Convert DWC USB3 bindings to DT schema
On Sat, 05 Dec 2020 18:24:17 +0300, Serge Semin wrote: > DWC USB3 DT node is supposed to be compliant with the Generic xHCI > Controller schema, but with additional vendor-specific properties, the > controller-specific reference clocks and PHYs. So let's convert the > currently available legacy text-based DWC USB3 bindings to the DT schema > and make sure the DWC USB3 nodes are also validated against the > usb-xhci.yaml schema. > > Note 1. we have to discard the nodename restriction of being prefixed with > "dwc3@" string, since in accordance with the usb-hcd.yaml schema USB nodes > are supposed to be named as "^usb(@.*)". > > Note 2. The clock-related properties are marked as optional to match the > DWC USB3 driver expectation and to improve the bindings mainainability > so in case if there is a glue-node it would the responsible for the > clocks initialization. > > Signed-off-by: Serge Semin > > --- > > Changelog v2: > - Discard '|' from the descriptions, since we don't need to preserve > the text formatting in any of them. > - Drop quotes from around the string constants. > - Fix the "clock-names" prop description to be referring the enumerated > clock-names instead of the ones from the Databook. > > Changelog v3: > - Apply usb-xhci.yaml# schema only if the controller is supposed to work > as either host or otg. > > Changelog v4: > - Apply usb-drd.yaml schema first. If the controller is configured > to work in a gadget mode only, then apply the usb.yaml schema too, > otherwise apply the usb-xhci.yaml schema. > - Discard the Rob'es Reviewed-by tag. Please review the patch one more > time. > > Changelog v5: > - Add "snps,dis-split-quirk" property to the DWC USB3 DT schema. > - Add a commit log text about the clock-related property changes. > - Make sure dr_mode exist to apply the USB-gadget-only schema. > --- > .../devicetree/bindings/usb/dwc3.txt | 128 --- > .../devicetree/bindings/usb/snps,dwc3.yaml| 312 ++ > 2 files changed, 312 insertions(+), 128 deletions(-) > delete mode 100644 Documentation/devicetree/bindings/usb/dwc3.txt > create mode 100644 Documentation/devicetree/bindings/usb/snps,dwc3.yaml > My bot found errors running 'make dt_binding_check' on your patch: yamllint warnings/errors: ./Documentation/devicetree/bindings/usb/snps,dwc3.yaml:55:4: [warning] wrong indentation: expected 4 but found 3 (indentation) dtschema/dtc warnings/errors: Unknown file referenced: [Errno 2] No such file or directory: '/usr/local/lib/python3.8/dist-packages/dtschema/schemas/usb/usb-drd.yaml' xargs: dt-doc-validate: exited with status 255; aborting make[1]: *** [Documentation/devicetree/bindings/Makefile:59: Documentation/devicetree/bindings/processed-schema-examples.json] Error 124 make: *** [Makefile:1364: dt_binding_check] Error 2 See https://patchwork.ozlabs.org/patch/1411582 The base for the patch is generally the last rc1. Any dependencies should be noted. If you already ran 'make dt_binding_check' and didn't see the above error(s), then make sure 'yamllint' is installed and dt-schema is up to date: pip3 install dtschema --upgrade Please check and re-submit. ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v4 10/18] dt-bindings: usb: Convert DWC USB3 bindings to DT schema
On Wed, Nov 25, 2020 at 1:32 AM Serge Semin wrote: > > On Sat, Nov 21, 2020 at 06:42:28AM -0600, Rob Herring wrote: > > On Thu, Nov 12, 2020 at 01:29:46PM +0300, Serge Semin wrote: > > > On Wed, Nov 11, 2020 at 02:14:23PM -0600, Rob Herring wrote: > > > > On Wed, Nov 11, 2020 at 12:08:45PM +0300, Serge Semin wrote: > > > > > DWC USB3 DT node is supposed to be compliant with the Generic xHCI > > > > > Controller schema, but with additional vendor-specific properties, the > > > > > controller-specific reference clocks and PHYs. So let's convert the > > > > > currently available legacy text-based DWC USB3 bindings to the DT > > > > > schema > > > > > and make sure the DWC USB3 nodes are also validated against the > > > > > usb-xhci.yaml schema. > > > > > > > > > > Note we have to discard the nodename restriction of being prefixed > > > > > with > > > > > "dwc3@" string, since in accordance with the usb-hcd.yaml schema USB > > > > > nodes > > > > > are supposed to be named as "^usb(@.*)". > > > > > > > > > > Signed-off-by: Serge Semin > > > > > > > > > > --- > > > > > > > > > > Changelog v2: > > > > > - Discard '|' from the descriptions, since we don't need to preserve > > > > > the text formatting in any of them. > > > > > - Drop quotes from around the string constants. > > > > > - Fix the "clock-names" prop description to be referring the > > > > > enumerated > > > > > clock-names instead of the ones from the Databook. > > > > > > > > > > Changelog v3: > > > > > - Apply usb-xhci.yaml# schema only if the controller is supposed to > > > > > work > > > > > as either host or otg. > > > > > > > > > > Changelog v4: > > > > > - Apply usb-drd.yaml schema first. If the controller is configured > > > > > to work in a gadget mode only, then apply the usb.yaml schema too, > > > > > otherwise apply the usb-xhci.yaml schema. > > > > > - Discard the Rob'es Reviewed-by tag. Please review the patch one more > > > > > time. > > > > > --- > > > > > .../devicetree/bindings/usb/dwc3.txt | 125 > > > > > .../devicetree/bindings/usb/snps,dwc3.yaml| 303 > > > > > ++ > > > > > 2 files changed, 303 insertions(+), 125 deletions(-) > > > > > delete mode 100644 Documentation/devicetree/bindings/usb/dwc3.txt > > > > > create mode 100644 > > > > > Documentation/devicetree/bindings/usb/snps,dwc3.yaml > > > > > > > > > diff --git a/Documentation/devicetree/bindings/usb/snps,dwc3.yaml > > > > > b/Documentation/devicetree/bindings/usb/snps,dwc3.yaml > > > > > new file mode 100644 > > > > > index ..079617891da6 > > > > > --- /dev/null > > > > > +++ b/Documentation/devicetree/bindings/usb/snps,dwc3.yaml > > > > > @@ -0,0 +1,303 @@ > > > > > +# SPDX-License-Identifier: GPL-2.0 > > > > > +%YAML 1.2 > > > > > +--- > > > > > +$id: http://devicetree.org/schemas/usb/snps,dwc3.yaml# > > > > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > > > > + > > > > > +title: Synopsys DesignWare USB3 Controller > > > > > + > > > > > +maintainers: > > > > > + - Felipe Balbi > > > > > + > > > > > +description: > > > > > + This is usually a subnode to DWC3 glue to which it is connected, > > > > > but can also > > > > > + be presented as a standalone DT node with an optional > > > > > vendor-specific > > > > > + compatible string. > > > > > + > > > > > > > > +allOf: > > > > > + - $ref: usb-drd.yaml# > > > > > + - if: > > > > > + properties: > > > > > +dr_mode: > > > > > + const: peripheral > > > > > Another thing, this evaluates to true if dr_mode is not present. You > > need to add 'required'? > > Right. Will something like this do that? Yes. > > + allOf: > + - $ref: usb-drd.yaml# > + - if: > + properties: > +dr_mode: > + const: peripheral > + > + required: > +- dr_mode > +then: > + $ref: usb.yaml# > +else > + $ref: usb-xhci.yaml# > > > If dr_mode is otg, then don't you need to apply > > both usb.yaml and usb-xhci.yaml? > > No I don't. Since there is no peripheral-specific DT schema, then the > only schema any USB-gadget node needs to pass is usb.yaml, which > is already included into the usb-xhci.yaml schema. So for pure OTG devices > with xHCI host and gadget capabilities it's enough to evaluate: allOf: > [$ref: usb-drd.yaml#, $ref: usb-xhci.yaml#]. Please see the > sketch/ASCII-figure below and the following text for details. Okay. Rob ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v4 10/18] dt-bindings: usb: Convert DWC USB3 bindings to DT schema
On Thu, Nov 12, 2020 at 01:29:46PM +0300, Serge Semin wrote: > On Wed, Nov 11, 2020 at 02:14:23PM -0600, Rob Herring wrote: > > On Wed, Nov 11, 2020 at 12:08:45PM +0300, Serge Semin wrote: > > > DWC USB3 DT node is supposed to be compliant with the Generic xHCI > > > Controller schema, but with additional vendor-specific properties, the > > > controller-specific reference clocks and PHYs. So let's convert the > > > currently available legacy text-based DWC USB3 bindings to the DT schema > > > and make sure the DWC USB3 nodes are also validated against the > > > usb-xhci.yaml schema. > > > > > > Note we have to discard the nodename restriction of being prefixed with > > > "dwc3@" string, since in accordance with the usb-hcd.yaml schema USB nodes > > > are supposed to be named as "^usb(@.*)". > > > > > > Signed-off-by: Serge Semin > > > > > > --- > > > > > > Changelog v2: > > > - Discard '|' from the descriptions, since we don't need to preserve > > > the text formatting in any of them. > > > - Drop quotes from around the string constants. > > > - Fix the "clock-names" prop description to be referring the enumerated > > > clock-names instead of the ones from the Databook. > > > > > > Changelog v3: > > > - Apply usb-xhci.yaml# schema only if the controller is supposed to work > > > as either host or otg. > > > > > > Changelog v4: > > > - Apply usb-drd.yaml schema first. If the controller is configured > > > to work in a gadget mode only, then apply the usb.yaml schema too, > > > otherwise apply the usb-xhci.yaml schema. > > > - Discard the Rob'es Reviewed-by tag. Please review the patch one more > > > time. > > > --- > > > .../devicetree/bindings/usb/dwc3.txt | 125 > > > .../devicetree/bindings/usb/snps,dwc3.yaml| 303 ++ > > > 2 files changed, 303 insertions(+), 125 deletions(-) > > > delete mode 100644 Documentation/devicetree/bindings/usb/dwc3.txt > > > create mode 100644 Documentation/devicetree/bindings/usb/snps,dwc3.yaml > > > diff --git a/Documentation/devicetree/bindings/usb/snps,dwc3.yaml > > > b/Documentation/devicetree/bindings/usb/snps,dwc3.yaml > > > new file mode 100644 > > > index ..079617891da6 > > > --- /dev/null > > > +++ b/Documentation/devicetree/bindings/usb/snps,dwc3.yaml > > > @@ -0,0 +1,303 @@ > > > +# SPDX-License-Identifier: GPL-2.0 > > > +%YAML 1.2 > > > +--- > > > +$id: http://devicetree.org/schemas/usb/snps,dwc3.yaml# > > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > > + > > > +title: Synopsys DesignWare USB3 Controller > > > + > > > +maintainers: > > > + - Felipe Balbi > > > + > > > +description: > > > + This is usually a subnode to DWC3 glue to which it is connected, but > > > can also > > > + be presented as a standalone DT node with an optional vendor-specific > > > + compatible string. > > > + > > > > +allOf: > > > + - $ref: usb-drd.yaml# > > > + - if: > > > + properties: > > > +dr_mode: > > > + const: peripheral Another thing, this evaluates to true if dr_mode is not present. You need to add 'required'? If dr_mode is otg, then don't you need to apply both usb.yaml and usb-xhci.yaml? > > > +then: > > > + $ref: usb.yaml# > > > > This part could be done in usb-drd.yaml? > > Originally I was thinking about that, but then in order to minimize > the properties validation I've decided to split the properties in > accordance with the USB controllers functionality: > > +- USB Gadget/Peripheral Controller. There is no > | specific schema for the gadgets since there is no > | common gadget properties (at least I failed to find > | ones). So the pure gadget controllers need to be > | validated just against usb.yaml schema. > | > usb.yaml <--+-- usb-hcd.yaml - Generic USB Host Controller. The schema > ^ turns out to include the OHCI/UHCI/EHCI > | properties, which AFAICS are also > | applicable for the other host controllers. > | So any USB host controller node needs to >
Re: [PATCH v4 02/18] dt-bindings: usb: Convert generic USB properties to DT schemas
On Wed, 11 Nov 2020 12:08:37 +0300, Serge Semin wrote: > The generic USB properties have been described in the legacy bindings > text file: Documentation/devicetree/bindings/usb/generic.txt . Let's > convert its content into the generic USB, USB HCD and USB DRD DT > schemas. So the Generic USB schema will be applicable to all USB > controllers, USB HCD - for the generic USB Host controllers and the USB > DRD - for the USB Dual-role controllers. > > Note the USB DRD schema is supposed to work in conjunction with > the USB peripheral/gadget and USB host controllers DT schemas. > > Signed-off-by: Serge Semin > > --- > > Changelog v2: > - Discard '|' in all the new properties, since we don't need to preserve > the text formatting. > - Convert abbreviated form of the "maximum-speed" enum restriction into > the multi-lined version of the list. > - Drop quotes from around the string constants. > > Changelog v4: > - Redistribute the properties between generic ones, USB HCD-specific and > USB DRD-specific. > - Discard the Rob'es Reviewed-by tag. Please review the patch one more time. > --- > .../devicetree/bindings/usb/generic.txt | 57 -- > .../devicetree/bindings/usb/usb-drd.yaml | 77 +++ > .../devicetree/bindings/usb/usb-hcd.yaml | 5 ++ > .../devicetree/bindings/usb/usb.yaml | 22 ++ > 4 files changed, 104 insertions(+), 57 deletions(-) > delete mode 100644 Documentation/devicetree/bindings/usb/generic.txt > create mode 100644 Documentation/devicetree/bindings/usb/usb-drd.yaml > Reviewed-by: Rob Herring ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v4 10/18] dt-bindings: usb: Convert DWC USB3 bindings to DT schema
On Wed, Nov 11, 2020 at 12:08:45PM +0300, Serge Semin wrote: > DWC USB3 DT node is supposed to be compliant with the Generic xHCI > Controller schema, but with additional vendor-specific properties, the > controller-specific reference clocks and PHYs. So let's convert the > currently available legacy text-based DWC USB3 bindings to the DT schema > and make sure the DWC USB3 nodes are also validated against the > usb-xhci.yaml schema. > > Note we have to discard the nodename restriction of being prefixed with > "dwc3@" string, since in accordance with the usb-hcd.yaml schema USB nodes > are supposed to be named as "^usb(@.*)". > > Signed-off-by: Serge Semin > > --- > > Changelog v2: > - Discard '|' from the descriptions, since we don't need to preserve > the text formatting in any of them. > - Drop quotes from around the string constants. > - Fix the "clock-names" prop description to be referring the enumerated > clock-names instead of the ones from the Databook. > > Changelog v3: > - Apply usb-xhci.yaml# schema only if the controller is supposed to work > as either host or otg. > > Changelog v4: > - Apply usb-drd.yaml schema first. If the controller is configured > to work in a gadget mode only, then apply the usb.yaml schema too, > otherwise apply the usb-xhci.yaml schema. > - Discard the Rob'es Reviewed-by tag. Please review the patch one more > time. > --- > .../devicetree/bindings/usb/dwc3.txt | 125 > .../devicetree/bindings/usb/snps,dwc3.yaml| 303 ++ > 2 files changed, 303 insertions(+), 125 deletions(-) > delete mode 100644 Documentation/devicetree/bindings/usb/dwc3.txt > create mode 100644 Documentation/devicetree/bindings/usb/snps,dwc3.yaml > > diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt > b/Documentation/devicetree/bindings/usb/dwc3.txt > deleted file mode 100644 > index d03edf9d3935.. > --- a/Documentation/devicetree/bindings/usb/dwc3.txt > +++ /dev/null > @@ -1,125 +0,0 @@ > -synopsys DWC3 CORE > - > -DWC3- USB3 CONTROLLER. Complies to the generic USB binding properties > - as described in 'usb/generic.txt' > - > -Required properties: > - - compatible: must be "snps,dwc3" > - - reg : Address and length of the register set for the device > - - interrupts: Interrupts used by the dwc3 controller. > - - clock-names: list of clock names. Ideally should be "ref", > -"bus_early", "suspend" but may be less or more. > - - clocks: list of phandle and clock specifier pairs corresponding to > - entries in the clock-names property. > - > -Exception for clocks: > - clocks are optional if the parent node (i.e. glue-layer) is compatible to > - one of the following: > -"cavium,octeon-7130-usb-uctl" > -"qcom,dwc3" > -"samsung,exynos5250-dwusb3" > -"samsung,exynos5433-dwusb3" > -"samsung,exynos7-dwusb3" > -"sprd,sc9860-dwc3" > -"st,stih407-dwc3" > -"ti,am437x-dwc3" > -"ti,dwc3" > -"ti,keystone-dwc3" > -"rockchip,rk3399-dwc3" > -"xlnx,zynqmp-dwc3" > - > -Optional properties: > - - usb-phy : array of phandle for the PHY device. The first element > - in the array is expected to be a handle to the USB2/HS PHY and > - the second element is expected to be a handle to the USB3/SS PHY > - - phys: from the *Generic PHY* bindings > - - phy-names: from the *Generic PHY* bindings; supported names are "usb2-phy" > - or "usb3-phy". > - - resets: set of phandle and reset specifier pairs > - - snps,usb2-lpm-disable: indicate if we don't want to enable USB2 HW LPM > - - snps,usb3_lpm_capable: determines if platform is USB3 LPM capable > - - snps,dis-start-transfer-quirk: when set, disable isoc START TRANSFER > command > - failure SW work-around for DWC_usb31 version 1.70a-ea06 > - and prior. > - - snps,disable_scramble_quirk: true when SW should disable data scrambling. > - Only really useful for FPGA builds. > - - snps,has-lpm-erratum: true when DWC3 was configured with LPM Erratum > enabled > - - snps,lpm-nyet-threshold: LPM NYET threshold > - - snps,u2exit_lfps_quirk: set if we want to enable u2exit lfps quirk > - - snps,u2ss_inp3_quirk: set if we enable P3 OK for U2/SS Inactive quirk > - - snps,req_p1p2p3_quirk: when set, the core will always request for > - P1/P2/P3 transition sequence. > - - snps,del_p1p2p3_quirk: when set core will delay P1/P2/P3 until a certain > - amount of 8B10B errors occur. > - - snps,del_phy_power_chg_quirk: when set core will delay PHY power change > - from P0 to P1/P2/P3. > - - snps,lfps_filter_quirk: when set core will filter LFPS reception. > - - snps,rx_detect_poll_quirk: when set core will disable a 400us delay to > start > - Polling LFPS after RX.Detect. > - - snps,tx_de_emphasis_quirk: when set core will set Tx de-emphasis value. > - - snps,tx_de_emphasis: the value driven to the PHY is con
Re: [PATCH v4 01/18] dt-bindings: usb: usb-hcd: Detach generic USB controller properties
On Wed, 11 Nov 2020 12:08:36 +0300, Serge Semin wrote: > There can be three distinctive types of the USB controllers: USB hosts, > USB peripherals/gadgets and USB OTG, which can switch from one role to > another. In order to have that hierarchy handled in the DT binding files, > we need to collect common properties in a common DT schema and specific > properties in dedicated schemas. Seeing the usb-hcd.yaml DT schema is > dedicated for the USB host controllers only, let's move some common > properties from there into the usb.yaml schema. So the later would be > available to evaluate all currently supported types of the USB > controllers. > > While at it add an explicit "additionalProperties: true" into the > usb-hcd.yaml as setting the additionalProperties/unevaluateProperties > properties is going to be get mandatory soon. > > Signed-off-by: Serge Semin > > --- > > Changelog v4: > - This is a new patch created as a result of the comment left > by Chunfeng Yun in v3 > --- > .../devicetree/bindings/usb/usb-hcd.yaml | 14 ++--- > .../devicetree/bindings/usb/usb.yaml | 29 +++ > 2 files changed, 32 insertions(+), 11 deletions(-) > create mode 100644 Documentation/devicetree/bindings/usb/usb.yaml > My bot found errors running 'make dt_binding_check' on your patch: yamllint warnings/errors: ./Documentation/devicetree/bindings/usb/usb-hcd.yaml:17:1: [error] duplication of key "additionalProperties" in mapping (key-duplicates) dtschema/dtc warnings/errors: Traceback (most recent call last): File "/usr/local/bin/dt-extract-example", line 45, in binding = yaml.load(open(args.yamlfile, encoding='utf-8').read()) File "/usr/local/lib/python3.8/dist-packages/ruamel/yaml/main.py", line 343, in load return constructor.get_single_data() File "/usr/local/lib/python3.8/dist-packages/ruamel/yaml/constructor.py", line 113, in get_single_data return self.construct_document(node) File "/usr/local/lib/python3.8/dist-packages/ruamel/yaml/constructor.py", line 123, in construct_document for _dummy in generator: File "/usr/local/lib/python3.8/dist-packages/ruamel/yaml/constructor.py", line 723, in construct_yaml_map value = self.construct_mapping(node) File "/usr/local/lib/python3.8/dist-packages/ruamel/yaml/constructor.py", line 440, in construct_mapping return BaseConstructor.construct_mapping(self, node, deep=deep) File "/usr/local/lib/python3.8/dist-packages/ruamel/yaml/constructor.py", line 257, in construct_mapping if self.check_mapping_key(node, key_node, mapping, key, value): File "/usr/local/lib/python3.8/dist-packages/ruamel/yaml/constructor.py", line 295, in check_mapping_key raise DuplicateKeyError(*args) ruamel.yaml.constructor.DuplicateKeyError: while constructing a mapping in "", line 4, column 1 found duplicate key "additionalProperties" with value "True" (original value: "True") in "", line 17, column 1 To suppress this check see: http://yaml.readthedocs.io/en/latest/api.html#duplicate-keys Duplicate keys will become an error in future releases, and are errors by default when using the new API. make[1]: *** [Documentation/devicetree/bindings/Makefile:20: Documentation/devicetree/bindings/usb/usb-hcd.example.dts] Error 1 make[1]: *** Deleting file 'Documentation/devicetree/bindings/usb/usb-hcd.example.dts' make[1]: *** Waiting for unfinished jobs make[1]: *** [Documentation/devicetree/bindings/Makefile:59: Documentation/devicetree/bindings/processed-schema-examples.json] Error 123 make: *** [Makefile:1364: dt_binding_check] Error 2 See https://patchwork.ozlabs.org/patch/1398034 The base for the patch is generally the last rc1. Any dependencies should be noted. If you already ran 'make dt_binding_check' and didn't see the above error(s), then make sure 'yamllint' is installed and dt-schema is up to date: pip3 install dtschema --upgrade Please check and re-submit. ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v3 09/16] dt-bindings: usb: Convert DWC USB3 bindings to DT schema
On Tue, 20 Oct 2020 14:20:54 +0300, Serge Semin wrote: > DWC USB3 DT node is supposed to be compliant with the Generic xHCI > Controller schema, but with additional vendor-specific properties, the > controller-specific reference clocks and PHYs. So let's convert the > currently available legacy text-based DWC USB3 bindings to the DT schema > and make sure the DWC USB3 nodes are also validated against the > usb-xhci.yaml schema. > > Note we have to discard the nodename restriction of being prefixed with > "dwc3@" string, since in accordance with the usb-hcd.yaml schema USB nodes > are supposed to be named as "^usb(@.*)". > > Signed-off-by: Serge Semin > > --- > > Changelog v2: > - Discard '|' from the descriptions, since we don't need to preserve > the text formatting in any of them. > - Drop quotes from around the string constants. > - Fix the "clock-names" prop description to be referring the enumerated > clock-names instead of the ones from the Databook. > > Changelog v3: > - Apply usb-xhci.yaml# schema only if the controller is supposed to work > as either host or otg. > --- > .../devicetree/bindings/usb/dwc3.txt | 125 > .../devicetree/bindings/usb/snps,dwc3.yaml| 302 ++ > 2 files changed, 302 insertions(+), 125 deletions(-) > delete mode 100644 Documentation/devicetree/bindings/usb/dwc3.txt > create mode 100644 Documentation/devicetree/bindings/usb/snps,dwc3.yaml > Reviewed-by: Rob Herring ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 15/20] dt-bindings: usb: meson-g12a-usb: Validate DWC2/DWC3 sub-nodes
On Wed, 14 Oct 2020 13:13:57 +0300, Serge Semin wrote: > Amlogic G12A USB DT sub-nodes are supposed to be compatible with the > generic DWC USB2 and USB3 devices. Since now we've got DT schemas for > both of the later IP cores let's make sure that the Amlogic G12A USB > DT nodes are fully evaluated including the DWC sub-nodes. > > Signed-off-by: Serge Semin > Reviewed-by: Neil Armstrong > > --- > > Changelog v2: > - Use "oneOf: [dwc2.yaml#, snps,dwc3.yaml#]" instead of the bulky "if: > properties: compatibe: ..." statement. > --- > .../devicetree/bindings/usb/amlogic,meson-g12a-usb-ctrl.yaml | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > Reviewed-by: Rob Herring ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 17/20] dt-bindings: usb: qcom, dwc3: Validate DWC3 sub-node
On Wed, 14 Oct 2020 13:13:59 +0300, Serge Semin wrote:
> Qualcomm msm8996/sc7180/sdm845 DWC3 compatible DT nodes are supposed to
> have a DWC USB3 compatible sub-node to describe a fully functioning USB
> interface. Let's use the available DWC USB3 DT schema to validate the
> Qualcomm DWC3 sub-nodes.
>
> Note since the generic DWC USB3 DT node is supposed to be named as generic
> USB HCD ("^usb(@.*)?") one we have to accordingly fix the sub-nodes name
> regexp and fix the DT node example.
>
> Signed-off-by: Serge Semin
>
> ---
>
> Changelog v2:
> - Discard the "^dwc3@[0-9a-f]+$" nodes from being acceptable as sub-nodes.
> ---
> Documentation/devicetree/bindings/usb/qcom,dwc3.yaml | 9 +++------
> 1 file changed, 3 insertions(+), 6 deletions(-)
>
Reviewed-by: Rob Herring
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 16/20] dt-bindings: usb: keystone-dwc3: Validate DWC3 sub-node
On Wed, 14 Oct 2020 13:13:58 +0300, Serge Semin wrote: > TI Keystone DWC3 compatible DT node is supposed to have a DWC USB3 > compatible sub-node to describe a fully functioning USB interface. > Since DWC USB3 has now got a DT schema describing its DT node, let's make > sure the TI Keystone DWC3 sub-node passes validation against it. > > Signed-off-by: Serge Semin > > --- > > Changelog v2: > - Grammar fix: "s/it'/its" > --- > Documentation/devicetree/bindings/usb/ti,keystone-dwc3.yaml | 4 +--- > 1 file changed, 1 insertion(+), 3 deletions(-) > Reviewed-by: Rob Herring ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 14/20] dt-bindings: usb: meson-g12a-usb: Fix FL-adj property value
On Wed, 14 Oct 2020 13:13:56 +0300, Serge Semin wrote: > An empty snps,quirk-frame-length-adjustment won't cause any change > performed by the driver. Moreover the DT schema validation will fail, > since it expects the property being assigned with some value. So set > fix the example by setting a valid FL-adj value in accordance with > Neil Armstrong comment. > > Link: > https://lore.kernel.org/linux-usb/20201010224121.12672-16-sergey.se...@baikalelectronics.ru/ > Signed-off-by: Serge Semin > Acked-by: Neil Armstrong > > --- > > Note the same problem is in the DT source file > arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi . > --- > .../devicetree/bindings/usb/amlogic,meson-g12a-usb-ctrl.yaml| 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > Reviewed-by: Rob Herring ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 13/20] dt-bindings: usb: dwc3: Add Frame Length Adj restrictions
On Wed, 14 Oct 2020 13:13:55 +0300, Serge Semin wrote: > In accordance with the IP core databook the > snps,quirk-frame-length-adjustment property can be set within [0, 0x3F]. > Let's make sure the DT schema applies a correct restriction on the > property. > > Signed-off-by: Serge Semin > --- > Documentation/devicetree/bindings/usb/snps,dwc3.yaml | 2 ++ > 1 file changed, 2 insertions(+) > Reviewed-by: Rob Herring ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 12/20] dt-bindings: usb: dwc3: Add Tx De-emphasis restrictions
On Wed, 14 Oct 2020 13:13:54 +0300, Serge Semin wrote: > In accordance with the driver comments the PIPE3 de-emphasis can be tuned > to be either -6dB, -2.5dB or disabled. Let's add the de-emphasis > property restriction so the DT schema would make sure the controller DT > node is equipped with correct value. > > Signed-off-by: Serge Semin > > --- > > Changelog v2: > - Grammar fix: "s/tunned/tuned" > - Grammar fix: remove redundant "or" conjunction. > --- > Documentation/devicetree/bindings/usb/snps,dwc3.yaml | 4 ++++ > 1 file changed, 4 insertions(+) > Reviewed-by: Rob Herring ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 11/20] dt-bindings: usb: dwc3: Add synopsys,dwc3 compatible string
On Thu, Oct 15, 2020 at 12:35:54AM +0300, Serge Semin wrote: > On Wed, Oct 14, 2020 at 10:18:18PM +0200, Krzysztof Kozlowski wrote: > > On Wed, Oct 14, 2020 at 01:13:53PM +0300, Serge Semin wrote: > > > The DWC USB3 driver and some DTS files like Exynos 5250, Keystone k2e, etc > > > expects the DWC USB3 DT node to have the compatible string with the > > > "synopsys" vendor prefix. Let's add the corresponding compatible string to > > > the controller DT schema, but mark it as deprecated seeing the Synopsys, > > > Inc. is presented with just "snps" vendor prefix. > > > > > Instead of adding deprecated schema just correct the DTSes to use snps. > > The "synopsys" is not even in vendor prefixes. > > Yeah, it's not, but the driver and some dts'es use it this way. I am not sure > that the solution suggested by you is much better than mine. So let's hear the > Rob'es opinion out in this matter. @Rob, what do you think? I think we should fix the dts files given there's only 5. Rob ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 10/20] dt-bindings: usb: dwc3: Add interrupt-names property support
On Wed, 14 Oct 2020 13:13:52 +0300, Serge Semin wrote: > The controller driver supports two types of DWC USB3 devices: with a > common interrupt lane and with individual interrupts for each mode. Add > support for both these cases to the DWC USB3 DT schema. > > Signed-off-by: Serge Semin > > --- > > Changelog v2: > - Grammar fix: "s/both of these cases support/support for both these cases" > - Drop quotes from around the string constants. > --- > Documentation/devicetree/bindings/usb/snps,dwc3.yaml | 11 +++ > 1 file changed, 11 insertions(+) > Reviewed-by: Rob Herring ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 08/20] dt-bindings: usb: renesas-xhci: Refer to the usb-xhci.yaml file
On Wed, 14 Oct 2020 13:13:50 +0300, Serge Semin wrote: > With minor peculiarities (like uploading some vendor-specific firmware) > these are just Generic xHCI controllers fully compatible with its > properties. Make sure the Renesas USB xHCI DT nodes are also validated > against the Generic xHCI DT schema. > > Signed-off-by: Serge Semin > --- > Documentation/devicetree/bindings/usb/renesas,usb-xhci.yaml | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > Reviewed-by: Rob Herring ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 06/20] dt-bindings: usb: Convert xHCI bindings to DT schema
On Wed, 14 Oct 2020 13:13:48 +0300, Serge Semin wrote: > Currently the DT bindings of Generic xHCI Controllers are described by means > of the legacy text file. Since such format is deprecated in favor of the > DT schema, let's convert the Generic xHCI Controllers bindings file to the > corresponding yaml files. There will be two of them: a DT schema for the > xHCI controllers on a generic platform and a DT schema validating a generic > xHCI controllers properties. The later will be used to validate the xHCI > controllers, which aside from some vendor-specific features support the > basic xHCI functionality. > > An xHCI-compatible DT node shall support the standard USB HCD properties > and custom ones like: usb2-lpm-disable, usb3-lpm-capable, > quirk-broken-port-ped and imod-interval-ns. In addition if a generic xHCI > controller is being validated against the DT schema it is also supposed to > be equipped with mandatory compatible string, single registers range, > single interrupts source, and is supposed to optionally contain up to two > reference clocks for the controller core and CSRs. > > Signed-off-by: Serge Semin > > --- > > Changelog v2: > - Add explicit "additionalProperties: true" to the usb-xhci.yaml schema, > since additionalProperties/unevaluatedProperties are going to be mandary > for each binding. > --- > .../devicetree/bindings/usb/generic-xhci.yaml | 63 +++ > .../devicetree/bindings/usb/usb-xhci.txt | 41 > .../devicetree/bindings/usb/usb-xhci.yaml | 42 + > 3 files changed, 105 insertions(+), 41 deletions(-) > create mode 100644 Documentation/devicetree/bindings/usb/generic-xhci.yaml > delete mode 100644 Documentation/devicetree/bindings/usb/usb-xhci.txt > create mode 100644 Documentation/devicetree/bindings/usb/usb-xhci.yaml > Reviewed-by: Rob Herring ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 07/20] dt-bindings: usb: xhci: Add Broadcom STB v2 compatible device
On Wed, 14 Oct 2020 13:13:49 +0300, Serge Semin wrote: > For some reason the "brcm,xhci-brcm-v2" compatible string has been missing > in the original bindings file. Add it to the Generic xHCI Controllers DT > schema since the controller driver expects it to be supported. > > Signed-off-by: Serge Semin > --- > Documentation/devicetree/bindings/usb/generic-xhci.yaml | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > Reviewed-by: Rob Herring ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 04/20] dt-bindings: usb: usb-hcd: Add "tpl-support" property
On Wed, 14 Oct 2020 13:13:46 +0300, Serge Semin wrote: > The host controller device might be designed to work for the particular > products or applications. In that case its DT node is supposed to be > equipped with the tpl-support property. > > Signed-off-by: Serge Semin > > --- > > Changelog v2: > - Grammar fix: "s/it'/its" > - Discard '|' from the property description, since we don't need to preserve > the text formatting. > --- > Documentation/devicetree/bindings/usb/usb-hcd.yaml | 6 ++ > 1 file changed, 6 insertions(+) > Reviewed-by: Rob Herring ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 05/20] dt-bindings: usb: usb-hcd: Add generic "usb-phy" property
On Wed, 14 Oct 2020 13:13:47 +0300, Serge Semin wrote: > Even though the Generic PHY framework is the more preferable way of > setting the USB PHY up, there are still many dts-files and DT bindings > which rely on having the legacy "usb-phy" specified to attach particular > USB PHYs to USB cores. Let's have the "usb-phy" property described in > the generic USB HCD binding file so it would be validated against the > nodes in which it's specified. Mark the property as deprecated to > discourage the developers from using it. > > Signed-off-by: Serge Semin > > --- > > Changelog v2: > - Discard '|' from the property description, since we don't need to preserve > the text formatting. > --- > Documentation/devicetree/bindings/usb/usb-hcd.yaml | 7 +++ > 1 file changed, 7 insertions(+) > Reviewed-by: Rob Herring ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 03/20] dt-bindings: usb: usb-hcd: Add "ulpi/serial/hsic" PHY types
On Wed, 14 Oct 2020 13:13:45 +0300, Serge Semin wrote: > Aside from the UTMI+ there are also ULPI, Serial and HSIC PHY types > that can be specified in the phy_type HCD property. Add them to the > enumeration of the acceptable values. > > Signed-off-by: Serge Semin > > --- > > Changelog v2: > - Grammar fix: "s/PHY types can be/PHY types that can be" > - Drop quotes from around the string constants. > --- > Documentation/devicetree/bindings/usb/usb-hcd.yaml | 10 ++ > 1 file changed, 6 insertions(+), 4 deletions(-) > Reviewed-by: Rob Herring ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 02/20] dt-bindings: usb: usb-hcd: Add "otg-rev" property restriction
On Wed, 14 Oct 2020 13:13:44 +0300, Serge Semin wrote: > There are only four OTG revisions are currently supported by the kernel: > 0x0100, 0x0120, 0x0130, 0x0200. Any another value is considered as > invalid. > > Signed-off-by: Serge Semin > --- > Documentation/devicetree/bindings/usb/usb-hcd.yaml | 1 + > 1 file changed, 1 insertion(+) > Reviewed-by: Rob Herring ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 01/20] dt-bindings: usb: usb-hcd: Convert generic USB properties to DT schema
On Wed, 14 Oct 2020 13:13:43 +0300, Serge Semin wrote: > The generic USB HCD properties have been described in the legacy bindings > text file: Documentation/devicetree/bindings/usb/generic.txt . Let's > convert it' content into the USB HCD DT schema properties so all USB DT > nodes would be validated to have them properly utilized. > > Signed-off-by: Serge Semin > > --- > > Changelog v2: > - Discard '|' in all the new properties, since we don't need to preserve > the text formatting. > - Convert abbreviated form of the "maximum-speed" enum restriction into > the multi-lined version of the list. > - Drop quotes from around the string constants. > --- > .../devicetree/bindings/usb/generic.txt | 57 > .../devicetree/bindings/usb/usb-hcd.yaml | 88 +++ > 2 files changed, 88 insertions(+), 57 deletions(-) > delete mode 100644 Documentation/devicetree/bindings/usb/generic.txt > Reviewed-by: Rob Herring ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 04/20] dt-bindings: usb: usb-hcd: Add "tpl-support" property
On Wed, Oct 14, 2020 at 08:27:10PM +0300, Serge Semin wrote: > On Wed, Oct 14, 2020 at 08:27:56AM -0500, Rob Herring wrote: > > On Wed, 14 Oct 2020 13:13:46 +0300, Serge Semin wrote: > > > The host controller device might be designed to work for the particular > > > products or applications. In that case its DT node is supposed to be > > > equipped with the tpl-support property. > > > > > > Signed-off-by: Serge Semin > > > > > > --- > > > > > > Changelog v2: > > > - Grammar fix: "s/it'/its" > > > - Discard '|' from the property description, since we don't need to > > > preserve > > > the text formatting. > > > --- > > > Documentation/devicetree/bindings/usb/usb-hcd.yaml | 6 ++ > > > 1 file changed, 6 insertions(+) > > > > > > > > > My bot found errors running 'make dt_binding_check' on your patch: > > > > Traceback (most recent call last): > > File "/usr/local/bin/dt-extract-example", line 45, in > > binding = yaml.load(open(args.yamlfile, encoding='utf-8').read()) > > File "/usr/local/lib/python3.8/dist-packages/ruamel/yaml/main.py", line > > 343, in load > > return constructor.get_single_data() > > File "/usr/local/lib/python3.8/dist-packages/ruamel/yaml/constructor.py", > > line 111, in get_single_data > > node = self.composer.get_single_node() > > File "_ruamel_yaml.pyx", line 706, in _ruamel_yaml.CParser.get_single_node > > File "_ruamel_yaml.pyx", line 724, in > > _ruamel_yaml.CParser._compose_document > > File "_ruamel_yaml.pyx", line 775, in _ruamel_yaml.CParser._compose_node > > File "_ruamel_yaml.pyx", line 891, in > > _ruamel_yaml.CParser._compose_mapping_node > > File "_ruamel_yaml.pyx", line 904, in > > _ruamel_yaml.CParser._parse_next_event > > ruamel.yaml.scanner.ScannerError: mapping values are not allowed in this > > context > > in "", line 27, column 14 > > make[1]: *** [Documentation/devicetree/bindings/Makefile:20: > > Documentation/devicetree/bindings/usb/usb-hcd.example.dts] Error 1 > > make[1]: *** Deleting file > > 'Documentation/devicetree/bindings/usb/usb-hcd.example.dts' > > make[1]: *** Waiting for unfinished jobs > > ./Documentation/devicetree/bindings/usb/usb-hcd.yaml:27:14: [error] syntax > > error: mapping values are not allowed here (syntax) > > make[1]: *** [Documentation/devicetree/bindings/Makefile:59: > > Documentation/devicetree/bindings/processed-schema-examples.json] Error 123 > > make: *** [Makefile:1366: dt_binding_check] Error 2 > > > > > > See https://patchwork.ozlabs.org/patch/1382001 > > > > If you already ran 'make dt_binding_check' and didn't see the above > > error(s), then make sure dt-schema is up to date: > > > > pip3 install git+https://github.com/devicetree-org/dt-schema.git@master > > --upgrade > > > > Please check and re-submit. > > Hm, that's weird. Of course I did the dt_binding_check before submission, but > even after the dt-schema repo update I failed to see the error: > > $ make -j8 ARCH=mips CROSS_COMPILE=mipsel-baikal-linux- dt_binding_check > DT_SCHEMA_FILES=Documentation/devicetree/bindings/usb/usb-hcd.yaml > CHKDT Documentation/devicetree/bindings/usb/usb-hcd.yaml > SCHEMA Documentation/devicetree/bindings/processed-schema-examples.yaml > DTC Documentation/devicetree/bindings/usb/usb-hcd.example.dt.yaml > CHECK Documentation/devicetree/bindings/usb/usb-hcd.example.dt.yaml > > Rob, any idea why has the bot got mad at me? Humm, I'm not sure. We'll see if it happens again when you send v2. Note that yamllint is also run now and that's the line with '[error]'. So neither yamllint nor ruamel are happy (could be the same parser code ultimately). Rob ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 20/20] arch: dts: Fix DWC USB3 DT nodes name
On Wed, Oct 14, 2020 at 9:37 AM Serge Semin
wrote:
>
> On Wed, Oct 14, 2020 at 05:09:37PM +0300, Felipe Balbi wrote:
> >
> > Hi Serge,
> >
> > Serge Semin writes:
> > > In accordance with the DWC USB3 bindings the corresponding node name is
> > > suppose to comply with Generic USB HCD DT schema, which requires the USB
> >
>
> > DWC3 is not a simple HDC, though.
>
> Yeah, strictly speaking it is equipped with a lot of vendor-specific stuff,
> which are tuned by the DWC USB3 driver in the kernel. But after that the
> controller is registered as xhci-hcd device so it's serviced by the xHCI
> driver,
> which then registers the HCD device so the corresponding DT node is supposed
> to be compatible with the next bindings: usb/usb-hcd.yaml, usb/usb-xhci.yaml
> and usb/snps,dwc3,yaml. I've created the later one so to validate the denoted
> compatibility.
>
> >
> > > nodes to have the name acceptable by the regexp: "^usb(@.*)?" . But a lot
> > > of the DWC USB3-compatible nodes defined in the ARM/ARM64 DTS files have
> > > name as "^dwc3@.*" or "^usb[1-3]@.*" or even "^dwusb@.*", which will cause
> > > the dtbs_check procedure failure. Let's fix the nodes naming to be
> > > compatible with the DWC USB3 DT schema to make dtbs_check happy.
> > >
> > > Note we don't change the DWC USB3-compatible nodes names of
> > > arch/arm64/boot/dts/apm/{apm-storm.dtsi,apm-shadowcat.dtsi} since the
> > > in-source comment says that the nodes name need to be preserved as
> > > "^dwusb@.*" for some backward compatibility.
> >
>
> > interesting, compatibility with what? Some debugfs files, perhaps? :-)
>
> Don't really know.) In my experience the worst type of such compatibility is
> connected with some bootloader magic, which may add/remove/modify properties
> to nodes with pre-defined names.
I seriously doubt anyone is using the APM machines with DT (even ACPI
is somewhat doubtful). I say change them. Or remove the dts files and
see what happens. Either way it can always be reverted.
Rob
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 09/20] dt-bindings: usb: Convert DWC USB3 bindings to DT schema
On Wed, 14 Oct 2020 13:13:51 +0300, Serge Semin wrote: > DWC USB3 DT node is supposed to be compliant with the Generic xHCI > Controller schema, but with additional vendor-specific properties, the > controller-specific reference clocks and PHYs. So let's convert the > currently available legacy text-based DWC USB3 bindings to the DT schema > and make sure the DWC USB3 nodes are also validated against the > usb-xhci.yaml schema. > > Note we have to discard the nodename restriction of being prefixed with > "dwc3@" string, since in accordance with the usb-hcd.yaml schema USB nodes > are supposed to be named as "^usb(@.*)". > > Signed-off-by: Serge Semin > > --- > > Changelog v2: > - Discard '|' from the descriptions, since we don't need to preserve > the text formatting in any of them. > - Drop quotes from around the string constants. > - Fix the "clock-names" prop description to be referring the enumerated > clock-names instead of the ones from the Databook. > --- > .../devicetree/bindings/usb/dwc3.txt | 125 > .../devicetree/bindings/usb/snps,dwc3.yaml| 295 ++ > 2 files changed, 295 insertions(+), 125 deletions(-) > delete mode 100644 Documentation/devicetree/bindings/usb/dwc3.txt > create mode 100644 Documentation/devicetree/bindings/usb/snps,dwc3.yaml > My bot found errors running 'make dt_binding_check' on your patch: ./Documentation/devicetree/bindings/usb/snps,dwc3.yaml:44:4: [warning] wrong indentation: expected 4 but found 3 (indentation) /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/usb/qcom,dwc3.example.dt.yaml: dwc3@a60: $nodename:0: 'dwc3@a60' does not match '^usb(@.*)?' From schema: /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/usb/snps,dwc3.yaml /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/usb/amlogic,meson-g12a-usb-ctrl.example.dt.yaml: usb@ff50: snps,quirk-frame-length-adjustment: True is not of type 'array' From schema: /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/usb/snps,dwc3.yaml See https://patchwork.ozlabs.org/patch/1382003 If you already ran 'make dt_binding_check' and didn't see the above error(s), then make sure dt-schema is up to date: pip3 install git+https://github.com/devicetree-org/dt-schema.git@master --upgrade Please check and re-submit. ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 04/20] dt-bindings: usb: usb-hcd: Add "tpl-support" property
On Wed, 14 Oct 2020 13:13:46 +0300, Serge Semin wrote: > The host controller device might be designed to work for the particular > products or applications. In that case its DT node is supposed to be > equipped with the tpl-support property. > > Signed-off-by: Serge Semin > > --- > > Changelog v2: > - Grammar fix: "s/it'/its" > - Discard '|' from the property description, since we don't need to preserve > the text formatting. > --- > Documentation/devicetree/bindings/usb/usb-hcd.yaml | 6 ++ > 1 file changed, 6 insertions(+) > My bot found errors running 'make dt_binding_check' on your patch: Traceback (most recent call last): File "/usr/local/bin/dt-extract-example", line 45, in binding = yaml.load(open(args.yamlfile, encoding='utf-8').read()) File "/usr/local/lib/python3.8/dist-packages/ruamel/yaml/main.py", line 343, in load return constructor.get_single_data() File "/usr/local/lib/python3.8/dist-packages/ruamel/yaml/constructor.py", line 111, in get_single_data node = self.composer.get_single_node() File "_ruamel_yaml.pyx", line 706, in _ruamel_yaml.CParser.get_single_node File "_ruamel_yaml.pyx", line 724, in _ruamel_yaml.CParser._compose_document File "_ruamel_yaml.pyx", line 775, in _ruamel_yaml.CParser._compose_node File "_ruamel_yaml.pyx", line 891, in _ruamel_yaml.CParser._compose_mapping_node File "_ruamel_yaml.pyx", line 904, in _ruamel_yaml.CParser._parse_next_event ruamel.yaml.scanner.ScannerError: mapping values are not allowed in this context in "", line 27, column 14 make[1]: *** [Documentation/devicetree/bindings/Makefile:20: Documentation/devicetree/bindings/usb/usb-hcd.example.dts] Error 1 make[1]: *** Deleting file 'Documentation/devicetree/bindings/usb/usb-hcd.example.dts' make[1]: *** Waiting for unfinished jobs ./Documentation/devicetree/bindings/usb/usb-hcd.yaml:27:14: [error] syntax error: mapping values are not allowed here (syntax) make[1]: *** [Documentation/devicetree/bindings/Makefile:59: Documentation/devicetree/bindings/processed-schema-examples.json] Error 123 make: *** [Makefile:1366: dt_binding_check] Error 2 See https://patchwork.ozlabs.org/patch/1382001 If you already ran 'make dt_binding_check' and didn't see the above error(s), then make sure dt-schema is up to date: pip3 install git+https://github.com/devicetree-org/dt-schema.git@master --upgrade Please check and re-submit. ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v6 5/6] dt-bindings: dw-apb-ictl: convert to json-schema
On Thu, Sep 24, 2020 at 03:17:53PM +0800, Zhen Lei wrote:
> Convert the Synopsys DesignWare APB interrupt controller (dw_apb_ictl)
> binding to DT schema format using json-schema.
>
> Signed-off-by: Zhen Lei
> ---
> .../interrupt-controller/snps,dw-apb-ictl.txt | 43 -
> .../interrupt-controller/snps,dw-apb-ictl.yaml | 74
> ++
> 2 files changed, 74 insertions(+), 43 deletions(-)
> delete mode 100644
> Documentation/devicetree/bindings/interrupt-controller/snps,dw-apb-ictl.txt
> create mode 100644
> Documentation/devicetree/bindings/interrupt-controller/snps,dw-apb-ictl.yaml
>
> diff --git
> a/Documentation/devicetree/bindings/interrupt-controller/snps,dw-apb-ictl.txt
> b/Documentation/devicetree/bindings/interrupt-controller/snps,dw-apb-ictl.txt
> deleted file mode 100644
> index 2db59df9408f4c6..000
> ---
> a/Documentation/devicetree/bindings/interrupt-controller/snps,dw-apb-ictl.txt
> +++ /dev/null
> @@ -1,43 +0,0 @@
> -Synopsys DesignWare APB interrupt controller (dw_apb_ictl)
> -
> -Synopsys DesignWare provides interrupt controller IP for APB known as
> -dw_apb_ictl. The IP is used as secondary interrupt controller in some SoCs
> with
> -APB bus, e.g. Marvell Armada 1500. It can also be used as primary interrupt
> -controller in some SoCs, e.g. Hisilicon SD5203.
> -
> -Required properties:
> -- compatible: shall be "snps,dw-apb-ictl"
> -- reg: physical base address of the controller and length of memory mapped
> - region starting with ENABLE_LOW register
> -- interrupt-controller: identifies the node as an interrupt controller
> -- #interrupt-cells: number of cells to encode an interrupt-specifier, shall
> be 1
> -
> -Additional required property when it's used as secondary interrupt
> controller:
> -- interrupts: interrupt reference to primary interrupt controller
> -
> -The interrupt sources map to the corresponding bits in the interrupt
> -registers, i.e.
> -- 0 maps to bit 0 of low interrupts,
> -- 1 maps to bit 1 of low interrupts,
> -- 32 maps to bit 0 of high interrupts,
> -- 33 maps to bit 1 of high interrupts,
> -- (optional) fast interrupts start at 64.
> -
> -Example:
> - /* dw_apb_ictl is used as secondary interrupt controller */
> - aic: interrupt-controller@3000 {
> - compatible = "snps,dw-apb-ictl";
> - reg = <0x3000 0xc00>;
> - interrupt-controller;
> - #interrupt-cells = <1>;
> - interrupt-parent = <&gic>;
> - interrupts = ;
> - };
> -
> - /* dw_apb_ictl is used as primary interrupt controller */
> - vic: interrupt-controller@1013 {
> - compatible = "snps,dw-apb-ictl";
> - reg = <0x1013 0x1000>;
> - interrupt-controller;
> - #interrupt-cells = <1>;
> - };
> diff --git
> a/Documentation/devicetree/bindings/interrupt-controller/snps,dw-apb-ictl.yaml
>
> b/Documentation/devicetree/bindings/interrupt-controller/snps,dw-apb-ictl.yaml
> new file mode 100644
> index 000..1b05d36b5f7b943
> --- /dev/null
> +++
> b/Documentation/devicetree/bindings/interrupt-controller/snps,dw-apb-ictl.yaml
> @@ -0,0 +1,74 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id:
> http://devicetree.org/schemas/interrupt-controller/snps,dw-apb-ictl.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Synopsys DesignWare APB interrupt controller (dw_apb_ictl)
> +
> +maintainers:
> + - Sebastian Hesselbarth
> +
> +description: |
> + Synopsys DesignWare provides interrupt controller IP for APB known as
> + dw_apb_ictl. The IP is used as secondary interrupt controller in some SoCs
> + with APB bus, e.g. Marvell Armada 1500. It can also be used as primary
> + interrupt controller in some SoCs, e.g. Hisilicon SD5203.
> +
> + The interrupt sources map to the corresponding bits in the interrupt
> + registers, i.e.
> + - 0 maps to bit 0 of low interrupts,
> + - 1 maps to bit 1 of low interrupts,
> + - 32 maps to bit 0 of high interrupts,
> + - 33 maps to bit 1 of high interrupts,
> + - (optional) fast interrupts start at 64.
> +
> +allOf:
> + - $ref: /schemas/interrupt-controller.yaml#
Don't need this. It's already selected based on node name.
> +
> +properties:
> + compatible:
> +const: snps,dw-apb-ictl
> +
> + interrupt-controller: true
> +
> + reg:
> +description: |
> + Physical base address of the controller and length of memory mapped
> + region starting with ENABLE_LOW register.
> +maxItems: 1
> +
> + interrupts:
> +description: Interrupt reference to primary interrupt controller.
May not be primary. Could be another level in the middle. In any case,
it's outside the scope of this binding, so just drop description.
> +maxItems: 1
> +
> + "#interrupt-cells":
> +description: Number of cells to encode an interrupt-specifier.
Can drop this.
> +const: 1
> +
> +requ
Re: [PATCH v5 4/6] dt-bindings: dw-apb-ictl: support hierarchy irq domain
On Fri, 18 Sep 2020 19:22:00 +0800, Zhen Lei wrote: > Add support to use dw-apb-ictl as primary interrupt controller. > > Signed-off-by: Zhen Lei > --- > .../bindings/interrupt-controller/snps,dw-apb-ictl.txt | 14 > +- > 1 file changed, 13 insertions(+), 1 deletion(-) > Reviewed-by: Rob Herring ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v5 5/6] dt-bindings: dw-apb-ictl: convert to json-schema
On Fri, Sep 18, 2020 at 07:22:01PM +0800, Zhen Lei wrote:
> Convert the Synopsys DesignWare APB interrupt controller (dw_apb_ictl)
> binding to DT schema format using json-schema.
>
> Signed-off-by: Zhen Lei
> ---
> .../interrupt-controller/snps,dw-apb-ictl.txt | 43 -
> .../interrupt-controller/snps,dw-apb-ictl.yaml | 75
> ++
> 2 files changed, 75 insertions(+), 43 deletions(-)
> delete mode 100644
> Documentation/devicetree/bindings/interrupt-controller/snps,dw-apb-ictl.txt
> create mode 100644
> Documentation/devicetree/bindings/interrupt-controller/snps,dw-apb-ictl.yaml
>
> diff --git
> a/Documentation/devicetree/bindings/interrupt-controller/snps,dw-apb-ictl.txt
> b/Documentation/devicetree/bindings/interrupt-controller/snps,dw-apb-ictl.txt
> deleted file mode 100644
> index 2db59df9408f4c6..000
> ---
> a/Documentation/devicetree/bindings/interrupt-controller/snps,dw-apb-ictl.txt
> +++ /dev/null
> @@ -1,43 +0,0 @@
> -Synopsys DesignWare APB interrupt controller (dw_apb_ictl)
> -
> -Synopsys DesignWare provides interrupt controller IP for APB known as
> -dw_apb_ictl. The IP is used as secondary interrupt controller in some SoCs
> with
> -APB bus, e.g. Marvell Armada 1500. It can also be used as primary interrupt
> -controller in some SoCs, e.g. Hisilicon SD5203.
> -
> -Required properties:
> -- compatible: shall be "snps,dw-apb-ictl"
> -- reg: physical base address of the controller and length of memory mapped
> - region starting with ENABLE_LOW register
> -- interrupt-controller: identifies the node as an interrupt controller
> -- #interrupt-cells: number of cells to encode an interrupt-specifier, shall
> be 1
> -
> -Additional required property when it's used as secondary interrupt
> controller:
> -- interrupts: interrupt reference to primary interrupt controller
> -
> -The interrupt sources map to the corresponding bits in the interrupt
> -registers, i.e.
> -- 0 maps to bit 0 of low interrupts,
> -- 1 maps to bit 1 of low interrupts,
> -- 32 maps to bit 0 of high interrupts,
> -- 33 maps to bit 1 of high interrupts,
> -- (optional) fast interrupts start at 64.
> -
> -Example:
> - /* dw_apb_ictl is used as secondary interrupt controller */
> - aic: interrupt-controller@3000 {
> - compatible = "snps,dw-apb-ictl";
> - reg = <0x3000 0xc00>;
> - interrupt-controller;
> - #interrupt-cells = <1>;
> - interrupt-parent = <&gic>;
> - interrupts = ;
> - };
> -
> - /* dw_apb_ictl is used as primary interrupt controller */
> - vic: interrupt-controller@1013 {
> - compatible = "snps,dw-apb-ictl";
> - reg = <0x1013 0x1000>;
> - interrupt-controller;
> - #interrupt-cells = <1>;
> - };
> diff --git
> a/Documentation/devicetree/bindings/interrupt-controller/snps,dw-apb-ictl.yaml
>
> b/Documentation/devicetree/bindings/interrupt-controller/snps,dw-apb-ictl.yaml
> new file mode 100644
> index 000..70c12979c843bf0
> --- /dev/null
> +++
> b/Documentation/devicetree/bindings/interrupt-controller/snps,dw-apb-ictl.yaml
> @@ -0,0 +1,75 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id:
> http://devicetree.org/schemas/interrupt-controller/snps,dw-apb-ictl.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Synopsys DesignWare APB interrupt controller (dw_apb_ictl)
> +
> +maintainers:
> + - Marc Zyngier
Usually this would be an owner for this IP block, not the subsystem
maintainer.
> +
> +description:
> + Synopsys DesignWare provides interrupt controller IP for APB known as
> + dw_apb_ictl. The IP is used as secondary interrupt controller in some SoCs
> + with APB bus, e.g. Marvell Armada 1500. It can also be used as primary
> + interrupt controller in some SoCs, e.g. Hisilicon SD5203.
> +
> +allOf:
> + - $ref: /schemas/interrupt-controller.yaml#
You can drop this, it's already applied based on node name.
> +
> +properties:
> + compatible:
> +const: snps,dw-apb-ictl
> +
> + interrupt-controller: true
> +
> + reg:
> +description:
> + Physical base address of the controller and length of memory mapped
> + region starting with ENABLE_LOW register.
Need to define how many reg regions (maxItems: 1).
> +
> + interrupts:
> +description:
> + Interrupt reference to primary interrupt controller.
> +
> + The interrupt sources map to the corresponding bits in the interrupt
> + registers, i.e.
> + - 0 maps to bit 0 of low interrupts,
> + - 1 maps to bit 1 of low interrupts,
> + - 32 maps to bit 0 of high interrupts,
> + - 33 maps to bit 1 of high interrupts,
> + - (optional) fast interrupts start at 64.
> +minItems: 1
> +maxItems: 65
65 connections to the primary interrupt controller? I think this is for
the child interrupts? If so, move to #interrupt
Re: [PATCH v2 3/4] ARC: [plat-hsdk-4xd] initial port for HSDK-4xD board
On Thu, Jun 4, 2020 at 11:39 AM Eugeniy Paltsev
wrote:
>
Need to cc the DT list.
> This initial port adds support of ARC HS4x/HS4xD Development Kit board
> with some basic features such serial port, USB, SD/MMC, SPI flash,
> Ethernet and others.
>
> The HSDK-4xD board has much in common with its predecessor - HSDK board.
> However HSDK-4xD has some differences in comparison with its predecessor:
> * based on quad core ARC HS48/HS47D processor (instead of quad core
>ARC HS38)
> * has ThinkSilicon GPU (instead of Vivante GPU)
> * has ARC PGU and HDMI output
> * has separate SDIO controller for WiFi module
> * has additional timers with clocksource independent from CPU clocksource
>(required for DVFS)
> * has performance counters interrupt
> * other minor stuff
>
> NOTE:
> HSDK-4xD and HSDK may share part of DTS so we can move this common part
> to one .dtsi file (as we have done it in U-boot). However we have quite
> enough out of the tree patches for tweaking HSDK DTS (patches in out
> Linux kernel verification flow, patches for run in simulation, etc...),
> so I'd prefer to keep HSDK DTS untouched. That's why HSDK-4xD DTS is
> created as an separate file.
>
> Cc: Rob Herring
> Signed-off-by: Eugeniy Paltsev
> ---
> arch/arc/boot/dts/hsdk-4xd.dts | 322
Please check this using W=1 and also build 'dtbs_check' (which needs
dt-schema installed).
> arch/arc/configs/hsdk_4xd_defconfig | 98 +
> arch/arc/kernel/devtree.c | 1 +
> arch/arc/plat-hsdk/Kconfig | 3 +-
> arch/arc/plat-hsdk/platform.c | 1 +
> 5 files changed, 424 insertions(+), 1 deletion(-)
> create mode 100644 arch/arc/boot/dts/hsdk-4xd.dts
> create mode 100644 arch/arc/configs/hsdk_4xd_defconfig
>
> diff --git a/arch/arc/boot/dts/hsdk-4xd.dts b/arch/arc/boot/dts/hsdk-4xd.dts
> new file mode 100644
> index ..2b7f76a01e3e
> --- /dev/null
> +++ b/arch/arc/boot/dts/hsdk-4xd.dts
> @@ -0,0 +1,322 @@
> +// SPDX-License-Identifier: GPL-2.0-only
Don't care about non-GPL OS's?
> +/*
> + * Copyright (C) 2020 Synopsys, Inc. (www.synopsys.com)
> + */
> +
> +/*
> + * Device Tree for ARC HS4x/HS4xD Development Kit
> + */
> +/dts-v1/;
> +
> +#include
> +#include
> +
> +/ {
> + model = "snps,hsdk-4xd";
> + compatible = "snps,hsdk-4xd";
> +
> + #address-cells = <2>;
> + #size-cells = <2>;
> +
> + chosen {
> + bootargs = "earlycon=uart8250,mmio32,0xf0005000,115200n8
> console=ttyS0,115200n8 debug print-fatal-signals=1";
You shouldn't really put debug options here like 'earlycon'. Also, use
'stdout-path' instead for the console.
> + };
> +
> + aliases {
> + ethernet = &gmac;
> + };
> +
> + cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + cpu@0 {
> + device_type = "cpu";
> + compatible = "snps,archs48";
Not documented.
> + reg = <0>;
> + clocks = <&core_clk>;
> + };
> +
> + cpu@1 {
> + device_type = "cpu";
> + compatible = "snps,archs48";
> + reg = <1>;
> + clocks = <&core_clk>;
> + };
> +
> + cpu@2 {
> + device_type = "cpu";
> + compatible = "snps,archs48";
> + reg = <2>;
> + clocks = <&core_clk>;
> + };
> +
> + cpu@3 {
> + device_type = "cpu";
> + compatible = "snps,archs48";
> + reg = <3>;
> + clocks = <&core_clk>;
> + };
> + };
> +
> + input_clk: input-clk {
> + #clock-cells = <0>;
> + compatible = "fixed-clock";
> + clock-frequency = <>;
> + };
> +
> + reg_5v0: regulator-5v0 {
> + compatible = "regulator-fixed";
> +
> + regulator-name = "5v0-supply";
> + regulator-min-microvolt = <500>;
> + regulator-max-microvolt = <500>;
> + };
> +
> + cpu_intc:
Re: [PATCH v3 2/2] dt-bindings: Document the Synopsys ARC HDMI TX bindings
On Wed, Apr 15, 2020 at 02:29:29AM +0300, Eugeniy Paltsev wrote:
> This patch adds documentation of device tree bindings for the Synopsys
> HDMI 2.0 TX encoder driver for ARC SoCs.
You're going to need to base this on top of Laurent's conversion of
dw_hdmi.txt to schema.
>
> Acked-by: Sam Ravnborg
> Signed-off-by: Eugeniy Paltsev
> ---
> .../display/bridge/snps,arc-dw-hdmi.yaml | 136 ++
> 1 file changed, 136 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/display/bridge/snps,arc-dw-hdmi.yaml
>
> diff --git
> a/Documentation/devicetree/bindings/display/bridge/snps,arc-dw-hdmi.yaml
> b/Documentation/devicetree/bindings/display/bridge/snps,arc-dw-hdmi.yaml
> new file mode 100644
> index ..9b2fdfecd5b3
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/bridge/snps,arc-dw-hdmi.yaml
> @@ -0,0 +1,136 @@
> +# SPDX-License-Identifier: GPL-2.0
Dual license new bindings please:
(GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/bridge/snps,arc-dw-hdmi.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Synopsys DesignWare HDMI 2.0 TX encoder driver
Bindings are for h/w blocks, not drivers.
> +
> +maintainers:
> + - Eugeniy Paltsev
> +
> +description: |
> + The HDMI transmitter is a Synopsys DesignWare HDMI 2.0 TX controller IP
> + with a companion of Synopsys DesignWare HDMI 2.0 TX PHY IP.
Sounds like 2 blocks?
> +
> + These DT bindings follow the Synopsys DWC HDMI TX bindings defined in
> + Documentation/devicetree/bindings/display/bridge/dw_hdmi.txt
> + with the following device-specific properties.
> +
> +properties:
> + compatible:
> +const: snps,arc-dw-hdmi-hsdk
> +
> + reg:
> +maxItems: 1
> +description: |
> + Memory mapped base address and length of the DWC HDMI TX registers.
Can drop.
> +
> + clocks:
> +items:
> + - description: The bus clock for AHB / APB
> + - description: The internal register configuration clock
> +
> + clock-names:
> +items:
> + - const: iahb
> + - const: isfr
> +
> + interrupts:
> +maxItems: 1
> +description: Reference to the DWC HDMI TX interrupt
Can drop.
> +
> + reg-io-width:
> +allOf:
> + - $ref: /schemas/types.yaml#/definitions/uint32
> + - enum: [1, 4]
> +description: |
> + Width of the registers specified by the reg property. The
> + value is expressed in bytes and must be equal to 1 or 4 if
> specified.
> + The register width defaults to 1 if the property is not present.
default: 1
The description is pretty much a plain text version of the constraints,
so all but the first sentence can be dropped.
> +
> + ports:
> +type: object
> +description: |
> + A ports node with endpoint definitions as defined in
> + Documentation/devicetree/bindings/media/video-interfaces.txt
Can drop. That's all 'ports'.
> +
> +properties:
> + "#address-cells":
> +const: 1
> +
> + "#size-cells":
> +const: 0
> +
> + port@0:
> +type: object
> +description: |
> + Video input endpoints of the controller.
> + Usually it is associated with ARC PGU.
> +
> + port@1:
> +type: object
> +description: |
> + Output endpoints of the controller. HDMI connector.
> +
> +required:
> + - "#address-cells"
> + - "#size-cells"
> + - port@0
> + - port@1
> +
> +required:
> + - compatible
> + - reg
> + - clocks
> + - clock-names
> + - interrupts
> + - ports
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> +hdmi@1 {
> +compatible = "snps,arc-dw-hdmi-hsdk";
> +reg = <0x1 0x1>;
> +reg-io-width = <4>;
> +interrupts = <14>;
> +clocks = <&apbclk>, <&hdmi_pix_clk>;
> +clock-names = "iahb", "isfr";
> +
> +ports {
> +#address-cells = <1>;
> +#size-cells = <0>;
> +
> +port@0 {
> +reg = <0>;
> +hdmi_enc_input: endpoint {
> +remote-endpoint = <&pgu_output>;
> +};
> +};
> +
> +port@1 {
> +reg = <1>;
> +hdmi_enc_out: endpoint {
> +remote-endpoint = <&hdmi_con>;
> +};
> +};
> +};
> +};
> +
> +hdmi-out {
> +port {
> +hdmi_con: endpoint {
> +remote-endpoint = <&hdmi_enc_out>;
> +};
> +};
> +};
> +
> +pgu {
> +port_o: port {
> +pgu_output: endpoint {
> +remote-endpoint = <&hdmi_enc_input>;
> +};
> +};
> +};
> --
> 2.21.1
>
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v2 2/2] dt-bindings: Document the Synopsys ARC HDMI TX bindings
On Tue, 14 Apr 2020 17:44:02 +0300, Eugeniy Paltsev wrote:
> This patch adds documentation of device tree bindings for the Synopsys
> HDMI 2.0 TX encoder driver for ARC SoCs.
>
> Signed-off-by: Eugeniy Paltsev
> ---
> .../display/bridge/snps,arc-dw-hdmi.yaml | 131 ++
> 1 file changed, 131 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/display/bridge/snps,arc-dw-hdmi.yaml
>
My bot found errors running 'make dt_binding_check' on your patch:
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/display/bridge/snps,arc-dw-hdmi.example.dt.yaml:
example-0: 'hdmi@0x1' does not match any of the regexes: '.*-names$',
'.*-supply$', '^#.*-cells$', '^#[a-zA-Z0-9,+\\-._]{0,63}$',
'^[a-zA-Z][a-zA-Z0-9,+\\-._]{0,63}$',
'^[a-zA-Z][a-zA-Z0-9,+\\-._]{0,63}@[0-9a-fA-F]+(,[0-9a-fA-F]+)*$', '^__.*__$',
'pinctrl-[0-9]+'
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/display/bridge/snps,arc-dw-hdmi.example.dt.yaml:
hdmi@0x1: 'interrupts' does not match any of the regexes: 'pinctrl-[0-9]+'
See https://patchwork.ozlabs.org/patch/1270389
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure dt-schema is up to date:
pip3 install git+https://github.com/devicetree-org/dt-schema.git@master
--upgrade
Please check and re-submit.
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 4/7] dt-bindings: chosen: Add clocksource and clockevent selection
On Wed, Sep 11, 2019 at 07:18:07AM +, claudiu.bez...@microchip.com wrote:
>
>
> On 11.09.2019 03:03, Linus Walleij wrote:
> > External E-Mail
> >
> >
> > On Tue, Sep 10, 2019 at 4:11 PM Alexandre Belloni
> > wrote:
> >> On 10/09/2019 16:08:26+0100, Sudeep Holla wrote:
> >>> On Tue, Sep 10, 2019 at 02:51:50PM +, claudiu.bez...@microchip.com
> >>> wrote:
> >
> >>> In that case, why can't we identify capability that with the compatibles
> >>> for this timer IP ?
> >>>
> >>> IOW, I don't like the proposal as it's hardware limitation.
> >>
> >> To be clear, bot timers are exactly the same but can't be clocksource
> >> and clockevent at the same time. Why would we have different compatibles
> >> for the exact same IP?
> >
> > In that case why not just pick the first one you find as clocksource
> > and the second one as clock event? As they all come to the
> > same timer of init function two simple local state variables can
> > solve that:
> >
> > static bool registered_clocksource;
> > static bool registered_clockevent;
> >
> > probe(timer) {
> >if (!registered_clocksource) {
> >register_clocksource(timer);
> >registrered_clocksource = true;
> >return;
> >}
> >if (!registered_clockevent) {
> >register_clockevent(timer);
> >registered_clockevent = true;
> >return;
> >}
> >pr_info("surplus timer %p\n", timer);
> > }
> >
>
> That was also my proposal for the driver I'm sending this series for (see
> [1]) but it has been proposed to implement a mechanism similar to this one
> in this series (see [2] and [3]).
This comes up over and over, and the answer is still no. Either each
block is identical and doesn't matter which one is used for what or
there is some h/w difference that you should describe.
If you want something that would even be considered to put into DT,
then define something BSD or other OS's could use too. (That's not a
suggestion to respin this with generalized names.)
Rob
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v2 3/3] dt-bindings: IDU-intc: Add support for edge-triggered interrupts
On Wed, 24 Jul 2019 14:04:36 +0200, Mischa Jonker wrote: > This updates the documentation for supporting an optional extra interrupt > cell to specify edge vs level triggered. > > Signed-off-by: Mischa Jonker > --- > .../interrupt-controller/snps,archs-idu-intc.txt | 19 > ++- > 1 file changed, 14 insertions(+), 5 deletions(-) > Reviewed-by: Rob Herring
Re: [PATCH v2 2/3] dt-bindings: IDU-intc: Clean up documentation
On Wed, 24 Jul 2019 14:04:35 +0200, Mischa Jonker wrote: > * Some lines exceeded 80 characters. > * Clarified statement about AUX register interface > > Signed-off-by: Mischa Jonker > --- > .../bindings/interrupt-controller/snps,archs-idu-intc.txt| 9 > + > 1 file changed, 5 insertions(+), 4 deletions(-) > Reviewed-by: Rob Herring
Re: [PATCH 06/12] dma-mapping: improve selection of dma_declare_coherent availability
On Wed, Feb 13, 2019 at 12:24 PM Christoph Hellwig wrote: > > On Tue, Feb 12, 2019 at 02:40:23PM -0600, Rob Herring wrote: > > > diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig > > > index 3607fd2810e4..f8c66a9472a4 100644 > > > --- a/drivers/of/Kconfig > > > +++ b/drivers/of/Kconfig > > > @@ -43,6 +43,7 @@ config OF_FLATTREE > > > > > > config OF_EARLY_FLATTREE > > > bool > > > + select DMA_DECLARE_COHERENT > > > > Is selecting DMA_DECLARE_COHERENT okay on UML? We run the unittests with > > UML. > > No, that will fail with undefined references to memunmap. > > I gues this needs to be > > select DMA_DECLARE_COHERENT if HAS_DMA > > > Maybe we should just get rid of OF_RESERVED_MEM. If we support booting > > from DT, then it should always be enabled anyways. > > Fine with me. Do you want me to respin the series to just remove > it? Either now or it can wait. I don't want to hold this up any. Rob ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 06/12] dma-mapping: improve selection of dma_declare_coherent availability
On Mon, Feb 11, 2019 at 7:37 AM Christoph Hellwig wrote: > > This API is primarily used through DT entries, but two architectures > and two drivers call it directly. So instead of selecting the config > symbol for random architectures pull it in implicitly for the actual > users. Also rename the Kconfig option to describe the feature better. > > Signed-off-by: Christoph Hellwig > --- > arch/arc/Kconfig| 1 - > arch/arm/Kconfig| 2 +- > arch/arm64/Kconfig | 1 - > arch/csky/Kconfig | 1 - > arch/mips/Kconfig | 1 - > arch/riscv/Kconfig | 1 - > arch/sh/Kconfig | 2 +- > arch/unicore32/Kconfig | 1 - > arch/x86/Kconfig| 1 - > drivers/mfd/Kconfig | 2 ++ > drivers/of/Kconfig | 3 ++- > include/linux/device.h | 2 +- > include/linux/dma-mapping.h | 8 > kernel/dma/Kconfig | 2 +- > kernel/dma/Makefile | 2 +- > 15 files changed, 13 insertions(+), 17 deletions(-) > diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig > index 3607fd2810e4..f8c66a9472a4 100644 > --- a/drivers/of/Kconfig > +++ b/drivers/of/Kconfig > @@ -43,6 +43,7 @@ config OF_FLATTREE > > config OF_EARLY_FLATTREE > bool > + select DMA_DECLARE_COHERENT Is selecting DMA_DECLARE_COHERENT okay on UML? We run the unittests with UML. Maybe we should just get rid of OF_RESERVED_MEM. If we support booting from DT, then it should always be enabled anyways. > select OF_FLATTREE > > config OF_PROMTREE > @@ -83,7 +84,7 @@ config OF_MDIO > config OF_RESERVED_MEM > bool > depends on OF_EARLY_FLATTREE > - default y if HAVE_GENERIC_DMA_COHERENT || DMA_CMA > + default y if DMA_DECLARE_COHERENT || DMA_CMA > > config OF_RESOLVE > bool ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 03/12] of: mark early_init_dt_alloc_reserved_memory_arch static
On Mon, Feb 11, 2019 at 7:36 AM Christoph Hellwig wrote: > > This function is only used in of_reserved_mem.c, and never overridden > despite the __weak marker. > > Signed-off-by: Christoph Hellwig > --- > drivers/of/of_reserved_mem.c| 2 +- > include/linux/of_reserved_mem.h | 7 --- > 2 files changed, 1 insertion(+), 8 deletions(-) Reviewed-by: Rob Herring Looks like this one isn't a dependency, so I can take it if you want. Rob ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 04/12] of: select OF_RESERVED_MEM automatically
On Mon, Feb 11, 2019 at 7:37 AM Christoph Hellwig wrote: > > The OF_RESERVED_MEM can be used if we have either CMA or the generic > declare coherent code built and we support the early flattened DT. > > So don't bother making it a user visible options that is selected > by most configs that fit the above category, but just select it when > the requirements are met. > > Signed-off-by: Christoph Hellwig > --- > arch/arc/Kconfig | 1 - > arch/arm/Kconfig | 1 - > arch/arm64/Kconfig | 1 - > arch/csky/Kconfig| 1 - > arch/powerpc/Kconfig | 1 - > arch/xtensa/Kconfig | 1 - > drivers/of/Kconfig | 5 ++--- > 7 files changed, 2 insertions(+), 9 deletions(-) Reviewed-by: Rob Herring ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v2] ARC: [scripted] fix node name and address spelling
On Thu, Jan 24, 2019 at 6:17 AM Alexey Brodkin wrote: > > From: Alexey Brodkin > > 1. Remove "0x" prefix from unit-address of node names > --->8 > sed -i 's/@0x/@/g' arch/arc/boot/dts/*.dts* > --->8 > > 2. Make all hex addresses lowercase: > --->8 > sed -i 's/@\([0-9A-Za-z]*\)/@\L\1/g' arch/arc/boot/dts/*.dts* > sed -i 's/0x\([0-9A-Za-z]*\)/0x\L\1/g' arch/arc/boot/dts/*.dts* > --->8 > > Inspired by [1] and the like. > > [1] http://kisskb.ellerman.id.au/kisskb/buildresult/13612017/ > > Signed-off-by: Alexey Brodkin > Cc: Rob Herring > --- > > Changes v1 -> v2: > > * Convert all hex addresses to lower-case [Rob] > > arch/arc/boot/dts/abilis_tb100.dtsi| 58 > arch/arc/boot/dts/abilis_tb100_dvk.dts | 14 > arch/arc/boot/dts/abilis_tb101.dtsi| 58 > arch/arc/boot/dts/abilis_tb101_dvk.dts | 14 > arch/arc/boot/dts/abilis_tb10x.dtsi| 60 > +- > arch/arc/boot/dts/axc001.dtsi | 6 ++-- > arch/arc/boot/dts/axc003.dtsi | 16 - > arch/arc/boot/dts/axc003_idu.dtsi | 16 - > arch/arc/boot/dts/axs10x_mb.dtsi | 22 ++--- > arch/arc/boot/dts/hsdk.dts | 4 +-- > arch/arc/boot/dts/vdk_axc003.dtsi | 4 +-- > arch/arc/boot/dts/vdk_axc003_idu.dtsi | 4 +-- > arch/arc/boot/dts/vdk_axs10x_mb.dtsi | 18 +- > 13 files changed, 147 insertions(+), 147 deletions(-) Reviewed-by: Rob Herring ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v2 19/21] treewide: add checks for the return value of memblock_alloc*()
On Mon, Jan 21, 2019 at 10:04:06AM +0200, Mike Rapoport wrote:
> Add check for the return value of memblock_alloc*() functions and call
> panic() in case of error.
> The panic message repeats the one used by panicing memblock allocators with
> adjustment of parameters to include only relevant ones.
>
> The replacement was mostly automated with semantic patches like the one
> below with manual massaging of format strings.
>
> @@
> expression ptr, size, align;
> @@
> ptr = memblock_alloc(size, align);
> + if (!ptr)
> + panic("%s: Failed to allocate %lu bytes align=0x%lx\n", __func__,
> size, align);
>
> Signed-off-by: Mike Rapoport
> Reviewed-by: Guo Ren # c-sky
> Acked-by: Paul Burton# MIPS
> Acked-by: Heiko Carstens # s390
> Reviewed-by: Juergen Gross # Xen
> ---
> arch/alpha/kernel/core_cia.c | 3 +++
> arch/alpha/kernel/core_marvel.c | 6 ++
> arch/alpha/kernel/pci-noop.c | 13 +++--
> arch/alpha/kernel/pci.c | 11 ++-
> arch/alpha/kernel/pci_iommu.c | 12
> arch/arc/mm/highmem.c | 4
> arch/arm/kernel/setup.c | 6 ++
> arch/arm/mm/mmu.c | 14 +-
> arch/arm64/kernel/setup.c | 8 +---
> arch/arm64/mm/kasan_init.c| 10 ++
> arch/c6x/mm/dma-coherent.c| 4
> arch/c6x/mm/init.c| 3 +++
> arch/csky/mm/highmem.c| 5 +
> arch/h8300/mm/init.c | 3 +++
> arch/m68k/atari/stram.c | 4
> arch/m68k/mm/init.c | 3 +++
> arch/m68k/mm/mcfmmu.c | 6 ++
> arch/m68k/mm/motorola.c | 9 +
> arch/m68k/mm/sun3mmu.c| 6 ++
> arch/m68k/sun3/sun3dvma.c | 3 +++
> arch/microblaze/mm/init.c | 8 ++--
> arch/mips/cavium-octeon/dma-octeon.c | 3 +++
> arch/mips/kernel/setup.c | 3 +++
> arch/mips/kernel/traps.c | 3 +++
> arch/mips/mm/init.c | 5 +
> arch/nds32/mm/init.c | 12
> arch/openrisc/mm/ioremap.c| 8 ++--
> arch/powerpc/kernel/dt_cpu_ftrs.c | 5 +
> arch/powerpc/kernel/pci_32.c | 3 +++
> arch/powerpc/kernel/setup-common.c| 3 +++
> arch/powerpc/kernel/setup_64.c| 4
> arch/powerpc/lib/alloc.c | 3 +++
> arch/powerpc/mm/hash_utils_64.c | 3 +++
> arch/powerpc/mm/mmu_context_nohash.c | 9 +
> arch/powerpc/mm/pgtable-book3e.c | 12 ++--
> arch/powerpc/mm/pgtable-book3s64.c| 3 +++
> arch/powerpc/mm/pgtable-radix.c | 9 -
> arch/powerpc/mm/ppc_mmu_32.c | 3 +++
> arch/powerpc/platforms/pasemi/iommu.c | 3 +++
> arch/powerpc/platforms/powermac/nvram.c | 3 +++
> arch/powerpc/platforms/powernv/opal.c | 3 +++
> arch/powerpc/platforms/powernv/pci-ioda.c | 8
> arch/powerpc/platforms/ps3/setup.c| 3 +++
> arch/powerpc/sysdev/msi_bitmap.c | 3 +++
> arch/s390/kernel/setup.c | 13 +
> arch/s390/kernel/smp.c| 5 -
> arch/s390/kernel/topology.c | 6 ++
> arch/s390/numa/mode_emu.c | 3 +++
> arch/s390/numa/numa.c | 6 +-
> arch/sh/mm/init.c | 6 ++
> arch/sh/mm/numa.c | 4
> arch/um/drivers/net_kern.c| 3 +++
> arch/um/drivers/vector_kern.c | 3 +++
> arch/um/kernel/initrd.c | 2 ++
> arch/um/kernel/mem.c | 16
> arch/unicore32/kernel/setup.c | 4
> arch/unicore32/mm/mmu.c | 15 +--
> arch/x86/kernel/acpi/boot.c | 3 +++
> arch/x86/kernel/apic/io_apic.c| 5 +
> arch/x86/kernel/e820.c| 3 +++
> arch/x86/platform/olpc/olpc_dt.c | 3 +++
> arch/x86/xen/p2m.c| 11 +--
> arch/xtensa/mm/kasan_init.c | 4
> arch/xtensa/mm/mmu.c | 3 +++
> drivers/clk/ti/clk.c | 3 +++
> drivers/macintosh/smu.c | 3 +++
> drivers/of/fdt.c | 8 +++-
> drivers/of/unittest.c | 8 +++-
Acked-by: Rob Herrin
Re: [PATCH 19/21] treewide: add checks for the return value of memblock_alloc*()
On Wed, Jan 16, 2019 at 7:46 AM Mike Rapoport wrote:
>
> Add check for the return value of memblock_alloc*() functions and call
> panic() in case of error.
> The panic message repeats the one used by panicing memblock allocators with
> adjustment of parameters to include only relevant ones.
>
> The replacement was mostly automated with semantic patches like the one
> below with manual massaging of format strings.
>
> @@
> expression ptr, size, align;
> @@
> ptr = memblock_alloc(size, align);
> + if (!ptr)
> + panic("%s: Failed to allocate %lu bytes align=0x%lx\n", __func__,
> size, align);
>
> Signed-off-by: Mike Rapoport
> ---
> arch/alpha/kernel/core_cia.c | 3 +++
> arch/alpha/kernel/core_marvel.c | 6 ++
> arch/alpha/kernel/pci-noop.c | 11 ++-
> arch/alpha/kernel/pci.c | 11 ++-
> arch/alpha/kernel/pci_iommu.c | 12
> arch/arc/mm/highmem.c | 4
> arch/arm/kernel/setup.c | 6 ++
> arch/arm/mm/mmu.c | 14 +-
> arch/arm64/kernel/setup.c | 9 ++---
> arch/arm64/mm/kasan_init.c| 10 ++
> arch/c6x/mm/dma-coherent.c| 4
> arch/c6x/mm/init.c| 3 +++
> arch/csky/mm/highmem.c| 5 +
> arch/h8300/mm/init.c | 3 +++
> arch/m68k/atari/stram.c | 4
> arch/m68k/mm/init.c | 3 +++
> arch/m68k/mm/mcfmmu.c | 6 ++
> arch/m68k/mm/motorola.c | 9 +
> arch/m68k/mm/sun3mmu.c| 6 ++
> arch/m68k/sun3/sun3dvma.c | 3 +++
> arch/microblaze/mm/init.c | 8 ++--
> arch/mips/cavium-octeon/dma-octeon.c | 3 +++
> arch/mips/kernel/setup.c | 3 +++
> arch/mips/kernel/traps.c | 3 +++
> arch/mips/mm/init.c | 5 +
> arch/nds32/mm/init.c | 12
> arch/openrisc/mm/ioremap.c| 8 ++--
> arch/powerpc/kernel/dt_cpu_ftrs.c | 5 +
> arch/powerpc/kernel/pci_32.c | 3 +++
> arch/powerpc/kernel/setup-common.c| 3 +++
> arch/powerpc/kernel/setup_64.c| 4
> arch/powerpc/lib/alloc.c | 3 +++
> arch/powerpc/mm/hash_utils_64.c | 3 +++
> arch/powerpc/mm/mmu_context_nohash.c | 9 +
> arch/powerpc/mm/pgtable-book3e.c | 12 ++--
> arch/powerpc/mm/pgtable-book3s64.c| 3 +++
> arch/powerpc/mm/pgtable-radix.c | 9 -
> arch/powerpc/mm/ppc_mmu_32.c | 3 +++
> arch/powerpc/platforms/pasemi/iommu.c | 3 +++
> arch/powerpc/platforms/powermac/nvram.c | 3 +++
> arch/powerpc/platforms/powernv/opal.c | 3 +++
> arch/powerpc/platforms/powernv/pci-ioda.c | 8
> arch/powerpc/platforms/ps3/setup.c| 3 +++
> arch/powerpc/sysdev/msi_bitmap.c | 3 +++
> arch/s390/kernel/setup.c | 13 +
> arch/s390/kernel/smp.c| 5 -
> arch/s390/kernel/topology.c | 6 ++
> arch/s390/numa/mode_emu.c | 3 +++
> arch/s390/numa/numa.c | 6 +-
> arch/s390/numa/toptree.c | 8 ++--
> arch/sh/mm/init.c | 6 ++
> arch/sh/mm/numa.c | 4
> arch/um/drivers/net_kern.c| 3 +++
> arch/um/drivers/vector_kern.c | 3 +++
> arch/um/kernel/initrd.c | 2 ++
> arch/um/kernel/mem.c | 16
> arch/unicore32/kernel/setup.c | 4
> arch/unicore32/mm/mmu.c | 15 +--
> arch/x86/kernel/acpi/boot.c | 3 +++
> arch/x86/kernel/apic/io_apic.c| 5 +
> arch/x86/kernel/e820.c| 3 +++
> arch/x86/platform/olpc/olpc_dt.c | 3 +++
> arch/x86/xen/p2m.c| 11 +--
> arch/xtensa/mm/kasan_init.c | 4
> arch/xtensa/mm/mmu.c | 3 +++
> drivers/clk/ti/clk.c | 3 +++
> drivers/macintosh/smu.c | 3 +++
> drivers/of/fdt.c | 8 +++-
> drivers/of/unittest.c | 8 +++-
Acked-by: Rob Herring
> drivers/xen/swiotlb-xen.c | 7 +--
> kernel/power/snapshot.c | 3 +++
> lib/cpuma
Re: [PATCH 08/21] memblock: drop __memblock_alloc_base()
On Wed, Jan 16, 2019 at 7:45 AM Mike Rapoport wrote: > > The __memblock_alloc_base() function tries to allocate a memory up to the > limit specified by its max_addr parameter. Depending on the value of this > parameter, the __memblock_alloc_base() can is replaced with the appropriate > memblock_phys_alloc*() variant. > > Signed-off-by: Mike Rapoport > --- > arch/sh/kernel/machine_kexec.c | 3 ++- > arch/x86/kernel/e820.c | 2 +- > arch/x86/mm/numa.c | 12 > drivers/of/of_reserved_mem.c | 7 ++- > include/linux/memblock.h | 2 -- > mm/memblock.c | 9 ++--- > 6 files changed, 11 insertions(+), 24 deletions(-) Acked-by: Rob Herring ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH] ARC: Remove 0x prefix from unit-address of node names
On Sat, Dec 8, 2018 at 1:01 AM Alexey Brodkin
wrote:
>
> Done automatically with help of:
> --->8
> sed -i 's/@0x/@/g' arch/arc/boot/dts/*.dts*
> --->8
>
> Inspired by [1] and the like.
>
> [1] http://kisskb.ellerman.id.au/kisskb/buildresult/13612017/
>
> Signed-off-by: Alexey Brodkin
> Cc: Rob Herring
>
> Signed-off-by: Alexey Brodkin
> ---
> arch/arc/boot/dts/abilis_tb10x.dtsi | 4 ++--
> arch/arc/boot/dts/axc001.dtsi | 6 +++---
> arch/arc/boot/dts/axc003.dtsi | 14 +++---
> arch/arc/boot/dts/axc003_idu.dtsi | 14 +++---
> arch/arc/boot/dts/axs10x_mb.dtsi | 22 +++---
> arch/arc/boot/dts/vdk_axc003.dtsi | 4 ++--
> arch/arc/boot/dts/vdk_axc003_idu.dtsi | 4 ++--
> arch/arc/boot/dts/vdk_axs10x_mb.dtsi | 14 +++---
> 8 files changed, 41 insertions(+), 41 deletions(-)
>
> diff --git a/arch/arc/boot/dts/abilis_tb10x.dtsi
> b/arch/arc/boot/dts/abilis_tb10x.dtsi
> index 3121536b25a3..77ac1368a65b 100644
> --- a/arch/arc/boot/dts/abilis_tb10x.dtsi
> +++ b/arch/arc/boot/dts/abilis_tb10x.dtsi
> @@ -178,7 +178,7 @@
> clocks = <&ahb_clk>;
> };
>
> - spi0: spi@0xFE01 {
> + spi0: spi@FE01 {
This should be lowercase too.
> #address-cells = <1>;
> #size-cells = <0>;
> cell-index = <0>;
[...]
> @@ -119,7 +119,7 @@
> * This node is intentionally put outside of MB above becase
> * it maps areas outside of MB's 0xEz-0xFz.
> */
> - uio_ev: uio@0xD000 {
> + uio_ev: uio@D000 {
lowercase
> compatible = "generic-uio";
> reg = <0xD000 0x2000 0xD100 0x2000 0x9000
> 0x1000 0xC000 0x1000>;
> reg-names = "ev_gsa", "ev_ctrl", "ev_shared_mem",
> "ev_code_mem";
> --
> 2.16.2
>
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v4 0/6] arm64: Get rid of __early_init_dt_declare_initrd()
On Mon, Nov 12, 2018 at 06:22:16PM -0600, Rob Herring wrote: > On Mon, Nov 12, 2018 at 12:32:50PM -0800, Florian Fainelli wrote: > > On 11/6/18 6:06 AM, Mike Rapoport wrote: > > > On Mon, Nov 05, 2018 at 02:54:25PM -0800, Florian Fainelli wrote: > > >> Hi all, > > >> > > >> Changes in v4: > > >> > > >> - dropped initrd_below_start_ok assignment in ARM64, not necessary at > > >> all (Ard) > > >> - replace #ifdef CONFIG_BLK_DEV_INITRD with if > > >> (IS_ENABLED(CONFIG_BLK_DEV_INITRD) for consistency with other parts > > >> of arm64_memblock_init() (Rob) > > >> > > >> Changes in v3: > > >> > > >> - use C conditionals in drivers/of/fdt.c > > >> - added check on phys_initrd_size in arch/arm64/mm/init.c to determine > > >> whether initrd_start must be populated > > >> - fixed a build warning with ARC that was just missing an (unsigned > > >> long) cast > > >> > > >> Changes in v2: > > >> > > >> - get rid of ARCH_HAS_PHYS_INITRD and instead define > > >> phys_initrd_start/phys_initrd_size in init/do_mounts_initrd.c > > >> > > >> - make __early_init_dt_declare_initrd() account for ARM64 specific > > >> behavior with __va() when having CONFIG_DEBUG_VM enabled > > >> > > >> - consolidate early_initrd() command line parsing into > > >> init/do_mounts_initrd.c > > >> > > >> Because phys_initrd_start/phys_initrd_size are now compiled in > > >> ini/do_mounts_initrd.c which is only built with CONFIG_BLK_DEV_INITRD=y, > > >> we need to be a bit careful about the uses throughout architecture > > >> specific code. > > >> > > >> Previous discussions/submissions list here: > > >> > > >> v3: > > >> https://www.spinics.net/lists/arm-kernel/msg683566.html > > >> v2: > > >> https://lkml.org/lkml/2018/10/25/4 > > >> > > >> Florian Fainelli (6): > > >> nds32: Remove phys_initrd_start and phys_initrd_size > > >> arch: Make phys_initrd_start and phys_initrd_size global variables > > >> of/fdt: Populate phys_initrd_start/phys_initrd_size from FDT > > >> arm64: Utilize phys_initrd_start/phys_initrd_size > > >> of/fdt: Remove custom __early_init_dt_declare_initrd() implementation > > >> arch: Move initrd= parsing into do_mounts_initrd.c > > > > > > For the series: > > > > > > Reviewed-by: Mike Rapoport > > > > Thanks Mike, Rob, do you want to merge that series through the OF tree? > > Sure, some arch maintainer acks would be nice. I've now applied the series. Thanks, Rob ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v4 0/6] arm64: Get rid of __early_init_dt_declare_initrd()
On Mon, Nov 12, 2018 at 12:32:50PM -0800, Florian Fainelli wrote: > On 11/6/18 6:06 AM, Mike Rapoport wrote: > > On Mon, Nov 05, 2018 at 02:54:25PM -0800, Florian Fainelli wrote: > >> Hi all, > >> > >> Changes in v4: > >> > >> - dropped initrd_below_start_ok assignment in ARM64, not necessary at > >> all (Ard) > >> - replace #ifdef CONFIG_BLK_DEV_INITRD with if > >> (IS_ENABLED(CONFIG_BLK_DEV_INITRD) for consistency with other parts > >> of arm64_memblock_init() (Rob) > >> > >> Changes in v3: > >> > >> - use C conditionals in drivers/of/fdt.c > >> - added check on phys_initrd_size in arch/arm64/mm/init.c to determine > >> whether initrd_start must be populated > >> - fixed a build warning with ARC that was just missing an (unsigned > >> long) cast > >> > >> Changes in v2: > >> > >> - get rid of ARCH_HAS_PHYS_INITRD and instead define > >> phys_initrd_start/phys_initrd_size in init/do_mounts_initrd.c > >> > >> - make __early_init_dt_declare_initrd() account for ARM64 specific > >> behavior with __va() when having CONFIG_DEBUG_VM enabled > >> > >> - consolidate early_initrd() command line parsing into > >> init/do_mounts_initrd.c > >> > >> Because phys_initrd_start/phys_initrd_size are now compiled in > >> ini/do_mounts_initrd.c which is only built with CONFIG_BLK_DEV_INITRD=y, > >> we need to be a bit careful about the uses throughout architecture > >> specific code. > >> > >> Previous discussions/submissions list here: > >> > >> v3: > >> https://www.spinics.net/lists/arm-kernel/msg683566.html > >> v2: > >> https://lkml.org/lkml/2018/10/25/4 > >> > >> Florian Fainelli (6): > >> nds32: Remove phys_initrd_start and phys_initrd_size > >> arch: Make phys_initrd_start and phys_initrd_size global variables > >> of/fdt: Populate phys_initrd_start/phys_initrd_size from FDT > >> arm64: Utilize phys_initrd_start/phys_initrd_size > >> of/fdt: Remove custom __early_init_dt_declare_initrd() implementation > >> arch: Move initrd= parsing into do_mounts_initrd.c > > > > For the series: > > > > Reviewed-by: Mike Rapoport > > Thanks Mike, Rob, do you want to merge that series through the OF tree? Sure, some arch maintainer acks would be nice. Rob ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v3 0/6] arm64: Get rid of __early_init_dt_declare_initrd()
On Wed, Oct 31, 2018 at 12:28:37PM -0700, Florian Fainelli wrote: > Hi all, > > Changes in v3: > > - use C conditionals in drivers/of/fdt.c > - added check on phys_initrd_size in arch/arm64/mm/init.c to determine > whether initrd_start must be populated > - fixed a build warning with ARC that was just missing an (unsigned > long) cast > > Changes in v2: > > - get rid of ARCH_HAS_PHYS_INITRD and instead define > phys_initrd_start/phys_initrd_size in init/do_mounts_initrd.c > > - make __early_init_dt_declare_initrd() account for ARM64 specific > behavior with __va() when having CONFIG_DEBUG_VM enabled > > - consolidate early_initrd() command line parsing into > init/do_mounts_initrd.c > > Because phys_initrd_start/phys_initrd_size are now compiled in > ini/do_mounts_initrd.c which is only built with CONFIG_BLK_DEV_INITRD=y, > we need to be a bit careful about the uses throughout architecture > specific code. > > Previous discussions/submissions list here: > > v3: > https://www.spinics.net/lists/arm-kernel/msg683566.html > v2: > https://lkml.org/lkml/2018/10/25/4 > > Florian Fainelli (6): > nds32: Remove phys_initrd_start and phys_initrd_size > arch: Make phys_initrd_start and phys_initrd_size global variables > of/fdt: Populate phys_initrd_start/phys_initrd_size from FDT > arm64: Utilize phys_initrd_start/phys_initrd_size > of/fdt: Remove custom __early_init_dt_declare_initrd() implementation > arch: Move initrd= parsing into do_mounts_initrd.c This all looks good to me. I can take it via the DT if you want. I'll give folks some more time to review though. Rob > > arch/arc/mm/init.c | 25 + > arch/arm/mm/init.c | 28 ++-- > arch/arm64/include/asm/memory.h | 8 > arch/arm64/mm/init.c| 33 +++-- > arch/nds32/mm/init.c| 2 -- > arch/unicore32/mm/init.c| 24 +--- > drivers/of/fdt.c| 17 - > include/linux/initrd.h | 3 +++ > init/do_mounts_initrd.c | 20 > 9 files changed, 54 insertions(+), 106 deletions(-) > > -- > 2.17.1 > ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v3 4/6] arm64: Utilize phys_initrd_start/phys_initrd_size
On Wed, Oct 31, 2018 at 12:28:41PM -0700, Florian Fainelli wrote:
> ARM64 is the only architecture that re-defines
> __early_init_dt_declare_initrd() in order for that function to populate
> initrd_start/initrd_end with physical addresses instead of virtual
> addresses. Instead of having an override we can leverage
> drivers/of/fdt.c populating phys_initrd_start/phys_initrd_size to
> populate those variables for us.
>
> Signed-off-by: Florian Fainelli
> ---
> arch/arm64/mm/init.c | 19 +--
> 1 file changed, 9 insertions(+), 10 deletions(-)
>
> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> index 3cf87341859f..00ef2166bb73 100644
> --- a/arch/arm64/mm/init.c
> +++ b/arch/arm64/mm/init.c
> @@ -72,8 +72,8 @@ static int __init early_initrd(char *p)
> if (*endp == ',') {
> size = memparse(endp + 1, NULL);
>
> - initrd_start = start;
> - initrd_end = start + size;
> + phys_initrd_start = start;
> + phys_initrd_size = size;
> }
> return 0;
> }
> @@ -408,14 +408,14 @@ void __init arm64_memblock_init(void)
> memblock_add(__pa_symbol(_text), (u64)(_end - _text));
> }
>
> - if (IS_ENABLED(CONFIG_BLK_DEV_INITRD) && initrd_start) {
> + if (IS_ENABLED(CONFIG_BLK_DEV_INITRD) && phys_initrd_size) {
> /*
>* Add back the memory we just removed if it results in the
>* initrd to become inaccessible via the linear mapping.
>* Otherwise, this is a no-op
>*/
> - u64 base = initrd_start & PAGE_MASK;
> - u64 size = PAGE_ALIGN(initrd_end) - base;
> + u64 base = phys_initrd_start & PAGE_MASK;
> + u64 size = PAGE_ALIGN(phys_initrd_size);
>
> /*
>* We can only add back the initrd memory if we don't end up
> @@ -460,12 +460,11 @@ void __init arm64_memblock_init(void)
>*/
> memblock_reserve(__pa_symbol(_text), _end - _text);
> #ifdef CONFIG_BLK_DEV_INITRD
> - if (initrd_start) {
> - memblock_reserve(initrd_start, initrd_end - initrd_start);
> -
> + if (phys_initrd_size) {
Since we're touching the if anyways, perhaps convert the #ifdef to a C
IS_ENABLED().
> /* the generic initrd code expects virtual addresses */
> - initrd_start = __phys_to_virt(initrd_start);
> - initrd_end = __phys_to_virt(initrd_end);
> + initrd_start = __phys_to_virt(phys_initrd_start);
> + initrd_end = initrd_start + phys_initrd_size;
> + initrd_below_start_ok = 0;
> }
> #endif
>
> --
> 2.17.1
>
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v2 5/6] of/fdt: Remove custom __early_init_dt_declare_initrd() implementation
On Tue, Oct 30, 2018 at 6:07 PM Florian Fainelli wrote:
>
> Now that ARM64 uses phys_initrd_start/phys_initrd_size, we can get rid
> of its custom __early_init_dt_declare_initrd() which causes a fair
> amount of objects rebuild when changing CONFIG_BLK_DEV_INITRD. In order
> to make sure ARM64 does not produce a BUG() when VM debugging is turned
> on though, we must avoid early calls to __va() which is what
> __early_init_dt_declare_initrd() does and wrap this around to avoid
> running that code on ARM64.
>
> Signed-off-by: Florian Fainelli
> ---
> arch/arm64/include/asm/memory.h | 8
> drivers/of/fdt.c| 9 +++--
> 2 files changed, 7 insertions(+), 10 deletions(-)
>
> diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
> index b96442960aea..dc3ca21ba240 100644
> --- a/arch/arm64/include/asm/memory.h
> +++ b/arch/arm64/include/asm/memory.h
> @@ -168,14 +168,6 @@
> #define IOREMAP_MAX_ORDER (PMD_SHIFT)
> #endif
>
> -#ifdef CONFIG_BLK_DEV_INITRD
> -#define __early_init_dt_declare_initrd(__start, __end) \
> - do {\
> - initrd_start = (__start); \
> - initrd_end = (__end); \
> - } while (0)
> -#endif
> -
> #ifndef __ASSEMBLY__
>
> #include
> diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
> index e34cb49231b5..f2b5becae96a 100644
> --- a/drivers/of/fdt.c
> +++ b/drivers/of/fdt.c
> @@ -892,15 +892,20 @@ const void * __init of_flat_dt_match_machine(const void
> *default_match,
> }
>
> #ifdef CONFIG_BLK_DEV_INITRD
> -#ifndef __early_init_dt_declare_initrd
> static void __early_init_dt_declare_initrd(unsigned long start,
>unsigned long end)
> {
> + /* ARM64 would cause a BUG to occur here when CONFIG_DEBUG_VM is
> +* enabled since __va() is called too early. ARM64 does make use
> +* of phys_initrd_start/phys_initrd_size so we can skip this
> +* conversion.
> +*/
> +#if (!IS_ENABLED(CONFIG_ARM64))
Use 'if' not '#if'. Use C code rather than preprocessor whenever possible.
> initrd_start = (unsigned long)__va(start);
> initrd_end = (unsigned long)__va(end);
> initrd_below_start_ok = 1;
> -}
> #endif
> +}
>
> /**
> * early_init_dt_check_for_initrd - Decode initrd location from flat tree
> --
> 2.17.1
>
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v2 0/2] arm64: Cut rebuild time when changing CONFIG_BLK_DEV_INITRD
On Thu, Oct 25, 2018 at 12:30 PM Mike Rapoport wrote:
>
> On Thu, Oct 25, 2018 at 08:15:15AM -0500, Rob Herring wrote:
> > +Ard
> >
> > On Thu, Oct 25, 2018 at 4:38 AM Mike Rapoport wrote:
> > >
> > > On Wed, Oct 24, 2018 at 02:55:17PM -0500, Rob Herring wrote:
> > > > On Wed, Oct 24, 2018 at 2:33 PM Florian Fainelli
> > > > wrote:
> > > > >
> > > > > Hi all,
> > > > >
> > > > > While investigating why ARM64 required a ton of objects to be rebuilt
> > > > > when toggling CONFIG_DEV_BLK_INITRD, it became clear that this was
> > > > > because we define __early_init_dt_declare_initrd() differently and we
> > > > > do
> > > > > that in arch/arm64/include/asm/memory.h which gets included by a fair
> > > > > amount of other header files, and translation units as well.
> > > >
> > > > I scratch my head sometimes as to why some config options rebuild so
> > > > much stuff. One down, ? to go. :)
> > > >
> > > > > Changing the value of CONFIG_DEV_BLK_INITRD is a common thing with
> > > > > build
> > > > > systems that generate two kernels: one with the initramfs and one
> > > > > without. buildroot is one of these build systems, OpenWrt is also
> > > > > another one that does this.
> > > > >
> > > > > This patch series proposes adding an empty initrd.h to satisfy the
> > > > > need
> > > > > for drivers/of/fdt.c to unconditionally include that file, and moves
> > > > > the
> > > > > custom __early_init_dt_declare_initrd() definition away from
> > > > > asm/memory.h
> > > > >
> > > > > This cuts the number of objects rebuilds from 1920 down to 26, so a
> > > > > factor 73 approximately.
> > > > >
> > > > > Apologies for the long CC list, please let me know how you would go
> > > > > about merging that and if another approach would be preferable, e.g:
> > > > > introducing a CONFIG_ARCH_INITRD_BELOW_START_OK Kconfig option or
> > > > > something like that.
> > > >
> > > > There may be a better way as of 4.20 because bootmem is now gone and
> > > > only memblock is used. This should unify what each arch needs to do
> > > > with initrd early. We need the physical address early for memblock
> > > > reserving. Then later on we need the virtual address to access the
> > > > initrd. Perhaps we should just change initrd_start and initrd_end to
> > > > physical addresses (or add 2 new variables would be less invasive and
> > > > allow for different translation than __va()). The sanity checks and
> > > > memblock reserve could also perhaps be moved to a common location.
> > > >
> > > > Alternatively, given arm64 is the only oddball, I'd be fine with an
> > > > "if (IS_ENABLED(CONFIG_ARM64))" condition in the default
> > > > __early_init_dt_declare_initrd as long as we have a path to removing
> > > > it like the above option.
> > >
> > > I think arm64 does not have to redefine __early_init_dt_declare_initrd().
> > > Something like this might be just all we need (completely untested,
> > > probably it won't even compile):
> > >
> > > diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> > > index 9d9582c..e9ca238 100644
> > > --- a/arch/arm64/mm/init.c
> > > +++ b/arch/arm64/mm/init.c
> > > @@ -62,6 +62,9 @@ s64 memstart_addr __ro_after_init = -1;
> > > phys_addr_t arm64_dma_phys_limit __ro_after_init;
> > >
> > > #ifdef CONFIG_BLK_DEV_INITRD
> > > +
> > > +static phys_addr_t initrd_start_phys, initrd_end_phys;
> > > +
> > > static int __init early_initrd(char *p)
> > > {
> > > unsigned long start, size;
> > > @@ -71,8 +74,8 @@ static int __init early_initrd(char *p)
> > > if (*endp == ',') {
> > > size = memparse(endp + 1, NULL);
> > >
> > > - initrd_start = start;
> > > - initrd_end = start + size;
> > > + initrd_start_phys = start;
> > > + initrd_end_phys = end;
> > > }
> > > return 0;
> > > }
> > > @@ -407,14 +410,27 @@ void __init arm64_memblock_init(void)
> > >
Re: [PATCH v2 0/2] arm64: Cut rebuild time when changing CONFIG_BLK_DEV_INITRD
+Ard
On Thu, Oct 25, 2018 at 4:38 AM Mike Rapoport wrote:
>
> On Wed, Oct 24, 2018 at 02:55:17PM -0500, Rob Herring wrote:
> > On Wed, Oct 24, 2018 at 2:33 PM Florian Fainelli
> > wrote:
> > >
> > > Hi all,
> > >
> > > While investigating why ARM64 required a ton of objects to be rebuilt
> > > when toggling CONFIG_DEV_BLK_INITRD, it became clear that this was
> > > because we define __early_init_dt_declare_initrd() differently and we do
> > > that in arch/arm64/include/asm/memory.h which gets included by a fair
> > > amount of other header files, and translation units as well.
> >
> > I scratch my head sometimes as to why some config options rebuild so
> > much stuff. One down, ? to go. :)
> >
> > > Changing the value of CONFIG_DEV_BLK_INITRD is a common thing with build
> > > systems that generate two kernels: one with the initramfs and one
> > > without. buildroot is one of these build systems, OpenWrt is also
> > > another one that does this.
> > >
> > > This patch series proposes adding an empty initrd.h to satisfy the need
> > > for drivers/of/fdt.c to unconditionally include that file, and moves the
> > > custom __early_init_dt_declare_initrd() definition away from
> > > asm/memory.h
> > >
> > > This cuts the number of objects rebuilds from 1920 down to 26, so a
> > > factor 73 approximately.
> > >
> > > Apologies for the long CC list, please let me know how you would go
> > > about merging that and if another approach would be preferable, e.g:
> > > introducing a CONFIG_ARCH_INITRD_BELOW_START_OK Kconfig option or
> > > something like that.
> >
> > There may be a better way as of 4.20 because bootmem is now gone and
> > only memblock is used. This should unify what each arch needs to do
> > with initrd early. We need the physical address early for memblock
> > reserving. Then later on we need the virtual address to access the
> > initrd. Perhaps we should just change initrd_start and initrd_end to
> > physical addresses (or add 2 new variables would be less invasive and
> > allow for different translation than __va()). The sanity checks and
> > memblock reserve could also perhaps be moved to a common location.
> >
> > Alternatively, given arm64 is the only oddball, I'd be fine with an
> > "if (IS_ENABLED(CONFIG_ARM64))" condition in the default
> > __early_init_dt_declare_initrd as long as we have a path to removing
> > it like the above option.
>
> I think arm64 does not have to redefine __early_init_dt_declare_initrd().
> Something like this might be just all we need (completely untested,
> probably it won't even compile):
>
> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> index 9d9582c..e9ca238 100644
> --- a/arch/arm64/mm/init.c
> +++ b/arch/arm64/mm/init.c
> @@ -62,6 +62,9 @@ s64 memstart_addr __ro_after_init = -1;
> phys_addr_t arm64_dma_phys_limit __ro_after_init;
>
> #ifdef CONFIG_BLK_DEV_INITRD
> +
> +static phys_addr_t initrd_start_phys, initrd_end_phys;
> +
> static int __init early_initrd(char *p)
> {
> unsigned long start, size;
> @@ -71,8 +74,8 @@ static int __init early_initrd(char *p)
> if (*endp == ',') {
> size = memparse(endp + 1, NULL);
>
> - initrd_start = start;
> - initrd_end = start + size;
> + initrd_start_phys = start;
> + initrd_end_phys = end;
> }
> return 0;
> }
> @@ -407,14 +410,27 @@ void __init arm64_memblock_init(void)
> memblock_add(__pa_symbol(_text), (u64)(_end - _text));
> }
>
> - if (IS_ENABLED(CONFIG_BLK_DEV_INITRD) && initrd_start) {
> + if (IS_ENABLED(CONFIG_BLK_DEV_INITRD) &&
> + (initrd_start || initrd_start_phys)) {
> + /*
> +* FIXME: ensure proper precendence between
> +* early_initrd and DT when both are present
Command line takes precedence, so just reverse the order.
> +*/
> + if (initrd_start) {
> + initrd_start_phys = __phys_to_virt(initrd_start);
> + initrd_end_phys = __phys_to_virt(initrd_end);
AIUI, the original issue was doing the P2V translation was happening
too early and the VA could be wrong if the linear range is adjusted.
So I don't think this would work.
I suppose you could convert the VA back to a PA before any adjustments
and then back to a VA again after. But that's kind of hacky. 2 wrongs
making a right.
>
Re: [PATCH v2 0/2] arm64: Cut rebuild time when changing CONFIG_BLK_DEV_INITRD
On Wed, Oct 24, 2018 at 3:01 PM Florian Fainelli wrote: > > On 10/24/18 12:55 PM, Rob Herring wrote: > > On Wed, Oct 24, 2018 at 2:33 PM Florian Fainelli > > wrote: > >> > >> Hi all, > >> > >> While investigating why ARM64 required a ton of objects to be rebuilt > >> when toggling CONFIG_DEV_BLK_INITRD, it became clear that this was > >> because we define __early_init_dt_declare_initrd() differently and we do > >> that in arch/arm64/include/asm/memory.h which gets included by a fair > >> amount of other header files, and translation units as well. > > > > I scratch my head sometimes as to why some config options rebuild so > > much stuff. One down, ? to go. :) > > > > This one was by far the most invasive one due to its include chain, but > yes, there would be many more that could be optimized. > > >> Changing the value of CONFIG_DEV_BLK_INITRD is a common thing with build > >> systems that generate two kernels: one with the initramfs and one > >> without. buildroot is one of these build systems, OpenWrt is also > >> another one that does this. > >> > >> This patch series proposes adding an empty initrd.h to satisfy the need > >> for drivers/of/fdt.c to unconditionally include that file, and moves the > >> custom __early_init_dt_declare_initrd() definition away from > >> asm/memory.h > >> > >> This cuts the number of objects rebuilds from 1920 down to 26, so a > >> factor 73 approximately. > >> > >> Apologies for the long CC list, please let me know how you would go > >> about merging that and if another approach would be preferable, e.g: > >> introducing a CONFIG_ARCH_INITRD_BELOW_START_OK Kconfig option or > >> something like that. > > > > There may be a better way as of 4.20 because bootmem is now gone and > > only memblock is used. This should unify what each arch needs to do > > with initrd early. We need the physical address early for memblock > > reserving. Then later on we need the virtual address to access the > > initrd. Perhaps we should just change initrd_start and initrd_end to > > physical addresses (or add 2 new variables would be less invasive and > > allow for different translation than __va()). The sanity checks and > > memblock reserve could also perhaps be moved to a common location. > > > > Alternatively, given arm64 is the only oddball, I'd be fine with an > > "if (IS_ENABLED(CONFIG_ARM64))" condition in the default > > __early_init_dt_declare_initrd as long as we have a path to removing > > it like the above option. > > OK, let me cook a patch doing that and meanwhile I will look at how much > work is involved to implement the above option you outlined, which also > sounds entirely reasonable. BTW, I would suspect that initrd_below_start_ok being 1 is not okay for most arches. I'm not sure how that would work. min_low_pfn is typically based on the start of memory. arm64 is not even setting it. Rob > -- > Florian ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v2 0/2] arm64: Cut rebuild time when changing CONFIG_BLK_DEV_INITRD
On Wed, Oct 24, 2018 at 2:33 PM Florian Fainelli wrote: > > Hi all, > > While investigating why ARM64 required a ton of objects to be rebuilt > when toggling CONFIG_DEV_BLK_INITRD, it became clear that this was > because we define __early_init_dt_declare_initrd() differently and we do > that in arch/arm64/include/asm/memory.h which gets included by a fair > amount of other header files, and translation units as well. I scratch my head sometimes as to why some config options rebuild so much stuff. One down, ? to go. :) > Changing the value of CONFIG_DEV_BLK_INITRD is a common thing with build > systems that generate two kernels: one with the initramfs and one > without. buildroot is one of these build systems, OpenWrt is also > another one that does this. > > This patch series proposes adding an empty initrd.h to satisfy the need > for drivers/of/fdt.c to unconditionally include that file, and moves the > custom __early_init_dt_declare_initrd() definition away from > asm/memory.h > > This cuts the number of objects rebuilds from 1920 down to 26, so a > factor 73 approximately. > > Apologies for the long CC list, please let me know how you would go > about merging that and if another approach would be preferable, e.g: > introducing a CONFIG_ARCH_INITRD_BELOW_START_OK Kconfig option or > something like that. There may be a better way as of 4.20 because bootmem is now gone and only memblock is used. This should unify what each arch needs to do with initrd early. We need the physical address early for memblock reserving. Then later on we need the virtual address to access the initrd. Perhaps we should just change initrd_start and initrd_end to physical addresses (or add 2 new variables would be less invasive and allow for different translation than __va()). The sanity checks and memblock reserve could also perhaps be moved to a common location. Alternatively, given arm64 is the only oddball, I'd be fine with an "if (IS_ENABLED(CONFIG_ARM64))" condition in the default __early_init_dt_declare_initrd as long as we have a path to removing it like the above option. Rob ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[PATCH v4 6/9] kbuild: consolidate Devicetree dtb build rules
There is nothing arch specific about building dtb files other than their location under /arch/*/boot/dts/. Keeping each arch aligned is a pain. The dependencies and supported targets are all slightly different. Also, a cross-compiler for each arch is needed, but really the host compiler preprocessor is perfectly fine for building dtbs. Move the build rules to a common location and remove the arch specific ones. This is done in a single step to avoid warnings about overriding rules. The build dependencies had been a mixture of 'scripts' and/or 'prepare'. These pull in several dependencies some of which need a target compiler (specifically devicetable-offsets.h) and aren't needed to build dtbs. All that is really needed is dtc, so adjust the dependencies to only be dtc. This change enables support 'dtbs_install' on some arches which were missing the target. Acked-by: Will Deacon Acked-by: Paul Burton Acked-by: Ley Foon Tan Cc: Masahiro Yamada Cc: Michal Marek Cc: Vineet Gupta Cc: Russell King Cc: Catalin Marinas Cc: Yoshinori Sato Cc: Michal Simek Cc: Ralf Baechle Cc: James Hogan Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Cc: Michael Ellerman Cc: Chris Zankel Cc: Max Filippov Cc: linux-kbu...@vger.kernel.org Cc: linux-snps-arc@lists.infradead.org Cc: linux-arm-ker...@lists.infradead.org Cc: uclinux-h8-de...@lists.sourceforge.jp Cc: linux-m...@linux-mips.org Cc: nios2-...@lists.rocketboards.org Cc: linuxppc-...@lists.ozlabs.org Cc: linux-xte...@linux-xtensa.org Signed-off-by: Rob Herring --- v4: - Make dtbs and %.dtb rules depend on arch/$ARCH/boot/dts path rather than CONFIG_OF_EARLY_FLATTREE - Fix install path missing kernel version for dtbs_install - Fix "make CONFIG_OF_ALL_DTBS=y" for arches like ARM which selectively enable CONFIG_OF (and therefore dtc) Makefile | 37 ++- arch/arc/Makefile | 6 - arch/arm/Makefile | 20 + arch/arm64/Makefile | 17 +- arch/c6x/Makefile | 2 -- arch/h8300/Makefile | 11 + arch/microblaze/Makefile | 4 +--- arch/microblaze/boot/dts/Makefile | 2 ++ arch/mips/Makefile| 15 + arch/nds32/Makefile | 2 +- arch/nios2/Makefile | 7 -- arch/nios2/boot/Makefile | 4 arch/powerpc/Makefile | 3 --- arch/xtensa/Makefile | 12 +- scripts/Makefile | 3 +-- scripts/Makefile.lib | 2 +- scripts/dtc/Makefile | 2 +- 17 files changed, 48 insertions(+), 101 deletions(-) diff --git a/Makefile b/Makefile index 6c3da3e10f07..251875470c5b 100644 --- a/Makefile +++ b/Makefile @@ -1061,7 +1061,7 @@ include/config/kernel.release: $(srctree)/Makefile FORCE # Carefully list dependencies so we do not try to build scripts twice # in parallel PHONY += scripts -scripts: scripts_basic asm-generic gcc-plugins $(autoksyms_h) +scripts: scripts_basic scripts_dtc asm-generic gcc-plugins $(autoksyms_h) $(Q)$(MAKE) $(build)=$(@) # Things we need to do before we recursively start building the kernel @@ -1205,6 +1205,35 @@ kselftest-merge: $(srctree)/tools/testing/selftests/*/config +$(Q)$(MAKE) -f $(srctree)/Makefile olddefconfig +# --- +# Devicetree files + +ifneq ($(wildcard $(srctree)/arch/$(SRCARCH)/boot/dts/),) +dtstree := arch/$(SRCARCH)/boot/dts +endif + +ifneq ($(dtstree),) + +%.dtb: prepare3 scripts_dtc + $(Q)$(MAKE) $(build)=$(dtstree) $(dtstree)/$@ + +PHONY += dtbs dtbs_install +dtbs: prepare3 scripts_dtc + $(Q)$(MAKE) $(build)=$(dtstree) + +dtbs_install: + $(Q)$(MAKE) $(dtbinst)=$(dtstree) + +ifdef CONFIG_OF_EARLY_FLATTREE +all: dtbs +endif + +endif + +PHONY += scripts_dtc +scripts_dtc: scripts_basic + $(Q)$(MAKE) $(build)=scripts/dtc + # --- # Modules @@ -1414,6 +1443,12 @@ help: @echo ' kselftest-merge - Merge all the config dependencies of kselftest to existing' @echo '.config.' @echo '' + @$(if $(dtstree), \ + echo 'Devicetree:'; \ + echo '* dtbs- Build device tree blobs for enabled boards'; \ + echo ' dtbs_install- Install dtbs to $(INSTALL_DTBS_PATH)'; \ + echo '') + @echo 'Userspace tools targets:' @echo ' use "make tools/help"' @echo ' or "cd tools; make help"' diff --git a/arch/arc/Makefile b/arch/arc/Makefile index 99cce77ab98f..caece8866080 100644 --- a/arch/arc/Makefile +++ b/arch/arc/Makefi
[PATCH v4 0/9] Devicetree build consolidation
This series addresses a couple of issues I have with building dts files. First, the ability to build all the dts files in the tree. This has been supported on most arches for some time with powerpc being the main exception. The reason powerpc wasn't supported was it needed a change in the location built dtb files are put. Secondly, it's a pain to acquire all the cross-compilers needed to build dtbs for each arch. There's no reason to build with the cross compiler and the host compiler is perfectly fine as we only need the pre-processor. I started addressing just those 2 problems, but kept finding small differences such as target dependencies and dtbs_install support across architectures. Instead of trying to align all these, I've consolidated the build targets moving them out of the arch makefiles. I'd like to take the series via the DT tree. PPC maintainers, really need you review/ack on this especially patch 1. Rob v4: - Make dtbs and %.dtb rules depend on arch/$ARCH/boot/dts path rather than CONFIG_OF_EARLY_FLATTREE - Fix install path missing kernel version for dtbs_install - Fix "make CONFIG_OF_ALL_DTBS=y" for arches like ARM which selectively enable CONFIG_OF (and therefore dtc) v3: - Rework dtc dependency to avoid 2 entry paths to scripts/dtc/. Essentially, I copied 'scripts_basic'. - Add missing scripts_basic dependency for dtc and missing PHONY tag. - Drop the '|' order only from dependencies - Drop %.dtb.S and %.dtb.o as top-level targets - PPC: remove duplicate mpc5200 dtbs from image-y targets v2: - Fix $arch/boot/dts path check for out of tree builds - Fix dtc dependency for building built-in dtbs - Fix microblaze built-in dtb building - Add dtbs target for microblaze Rob Herring (9): powerpc: build .dtb files in dts directory nios2: build .dtb files in dts directory nios2: use common rules to build built-in dtb nios2: fix building all dtbs c6x: use common built-in dtb support kbuild: consolidate Devicetree dtb build rules powerpc: enable building all dtbs c6x: enable building all dtbs microblaze: enable building all dtbs Makefile | 37 +++- arch/arc/Makefile | 6 arch/arm/Makefile | 20 +-- arch/arm64/Makefile| 17 + arch/c6x/Makefile | 2 -- arch/c6x/boot/dts/Makefile | 17 - arch/c6x/boot/dts/linked_dtb.S | 2 -- arch/c6x/include/asm/sections.h| 1 - arch/c6x/kernel/setup.c| 4 +-- arch/c6x/kernel/vmlinux.lds.S | 10 -- arch/h8300/Makefile| 11 +- arch/microblaze/Makefile | 4 +-- arch/microblaze/boot/dts/Makefile | 4 +++ arch/mips/Makefile | 15 +--- arch/nds32/Makefile| 2 +- arch/nios2/Makefile| 11 +- arch/nios2/boot/Makefile | 22 arch/nios2/boot/dts/Makefile | 6 arch/nios2/boot/linked_dtb.S | 19 --- arch/powerpc/Makefile | 3 -- arch/powerpc/boot/Makefile | 55 ++ arch/powerpc/boot/dts/Makefile | 6 arch/powerpc/boot/dts/fsl/Makefile | 4 +++ arch/xtensa/Makefile | 12 +-- scripts/Makefile | 3 +- scripts/Makefile.lib | 2 +- scripts/dtc/Makefile | 2 +- 27 files changed, 102 insertions(+), 195 deletions(-) delete mode 100644 arch/c6x/boot/dts/linked_dtb.S create mode 100644 arch/nios2/boot/dts/Makefile delete mode 100644 arch/nios2/boot/linked_dtb.S create mode 100644 arch/powerpc/boot/dts/Makefile create mode 100644 arch/powerpc/boot/dts/fsl/Makefile -- 2.17.1 ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v3 6/9] kbuild: consolidate Devicetree dtb build rules
On Mon, Oct 1, 2018 at 12:49 AM Masahiro Yamada wrote: > > Hi Rob, > > > 2018年9月29日(土) 0:43 Rob Herring : > > > +# > > --- > > +# Devicetree files > > + > > +ifneq ($(wildcard $(srctree)/arch/$(SRCARCH)/boot/dts/),) > > +dtstree := arch/$(SRCARCH)/boot/dts > > +endif > > + > > +ifneq ($(dtstree),) > > + > > +%.dtb : scripts_dtc > > %.dtb: prepare3 prepare I assume you didn't mean to drop scripts_dtc as that doesn't work. Why "prepare" here and not on dtbs? > because we need to make sure KERNELRELEASE > is correctly defined before dtbs_install happens. Yes, indeed. With prepare3 added I get: cp: cannot create regular file '/boot/dtbs/4.19.0-rc3-9-g0afba9b7b2ea-dirty': No such file or directory vs. with it: cp: cannot create regular file '/boot/dtbs/': Not a directory > > > > + $(Q)$(MAKE) $(build)=$(dtstree) $(dtstree)/$@ > > + > > +PHONY += dtbs dtbs_install > > +dtbs: scripts_dtc > > > dtbs: prepare3 scripts_dtc > > > > > + $(Q)$(MAKE) $(build)=$(dtstree) > > + > > +dtbs_install: dtbs > > > Please do not have dtbs_install to depend on dtbs. > > No install targets should ever trigger building anything > in the source tree. > > > For the background, see the commit log of > 19514fc665ffbce624785f76ee7ad0ea6378a527 Okay, thanks. Rob ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v3 6/9] kbuild: consolidate Devicetree dtb build rules
On Fri, Sep 28, 2018 at 12:21 PM Andreas Färber wrote: > > Hi Geert, > > Am 13.09.18 um 17:51 schrieb Geert Uytterhoeven: > > On Wed, Sep 12, 2018 at 3:02 AM Masahiro Yamada > > wrote: > >> Even x86 can enable OF and OF_UNITTEST. > >> > >> Another solution might be, > >> guard it by 'depends on ARCH_SUPPORTS_OF'. > >> > >> This is actually what ACPI does. > >> > >> menuconfig ACPI > >> bool "ACPI (Advanced Configuration and Power Interface) Support" > >> depends on ARCH_SUPPORTS_ACPI > >> ... > > > > ACPI is a real platform feature, as it depends on firmware. > > > > CONFIG_OF can be enabled, and DT overlays can be loaded, on any platform, > > even if it has ACPI ;-) > > How would loading a DT overlay work on an ACPI platform? I.e., what > would it overlay against and how to practically load such a file? The DT unittests do just that. I run them on x86 and UM builds. In this case, the loading source is built-in. > I wonder whether that could be helpful for USB devices and serdev... How to load the overlays is pretty orthogonal to the issues to be solved here. It would certainly be possible to move forward with prototyping this and just have the overlay built-in. It may not even need to be an overlay if we can support multiple root nodes. Rob ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v3 6/9] kbuild: consolidate Devicetree dtb build rules
On Sun, Sep 23, 2018 at 06:31:14AM -0400, Masahiro Yamada wrote: > 2018-09-13 11:51 GMT-04:00 Geert Uytterhoeven : > > Hi Yamada-san, > > > > On Wed, Sep 12, 2018 at 3:02 AM Masahiro Yamada > > wrote: > >> 2018-09-12 0:40 GMT+09:00 Rob Herring : > >> > On Mon, Sep 10, 2018 at 10:04 AM Rob Herring wrote: > >> >> There is nothing arch specific about building dtb files other than their > >> >> location under /arch/*/boot/dts/. Keeping each arch aligned is a pain. > >> >> The dependencies and supported targets are all slightly different. > >> >> Also, a cross-compiler for each arch is needed, but really the host > >> >> compiler preprocessor is perfectly fine for building dtbs. Move the > >> >> build rules to a common location and remove the arch specific ones. This > >> >> is done in a single step to avoid warnings about overriding rules. > >> >> > >> >> The build dependencies had been a mixture of 'scripts' and/or 'prepare'. > >> >> These pull in several dependencies some of which need a target compiler > >> >> (specifically devicetable-offsets.h) and aren't needed to build dtbs. > >> >> All that is really needed is dtc, so adjust the dependencies to only be > >> >> dtc. > >> >> > >> >> This change enables support 'dtbs_install' on some arches which were > >> >> missing the target. > >> > > >> > [...] > >> > > >> >> @@ -1215,6 +1215,33 @@ kselftest-merge: > >> >> $(srctree)/tools/testing/selftests/*/config > >> >> +$(Q)$(MAKE) -f $(srctree)/Makefile olddefconfig > >> >> > >> >> +# > >> >> --- > >> >> +# Devicetree files > >> >> + > >> >> +ifneq ($(wildcard $(srctree)/arch/$(SRCARCH)/boot/dts/),) > >> >> +dtstree := arch/$(SRCARCH)/boot/dts > >> >> +endif > >> >> + > >> >> +ifdef CONFIG_OF_EARLY_FLATTREE > >> > > >> > This can be true when dtstree is unset. So this line should be this > >> > instead to fix the 0-day reported error: > >> > > >> > ifneq ($(dtstree),) > >> > > >> >> + > >> >> +%.dtb : scripts_dtc > >> >> + $(Q)$(MAKE) $(build)=$(dtstree) $(dtstree)/$@ > >> >> + > >> >> +PHONY += dtbs dtbs_install > >> >> +dtbs: scripts_dtc > >> >> + $(Q)$(MAKE) $(build)=$(dtstree) > >> >> + > >> >> +dtbs_install: dtbs > >> >> + $(Q)$(MAKE) $(dtbinst)=$(dtstree) > >> >> + > >> >> +all: dtbs > >> >> + > >> >> +endif > >> > >> > >> Ah, right. > >> Even x86 can enable OF and OF_UNITTEST. > >> > >> > >> > >> Another solution might be, > >> guard it by 'depends on ARCH_SUPPORTS_OF'. > >> > >> > >> > >> This is actually what ACPI does. > >> > >> menuconfig ACPI > >> bool "ACPI (Advanced Configuration and Power Interface) Support" > >> depends on ARCH_SUPPORTS_ACPI > >> ... > > > > ACPI is a real platform feature, as it depends on firmware. > > > > CONFIG_OF can be enabled, and DT overlays can be loaded, on any platform, > > even if it has ACPI ;-) > > > > OK, understood. Any other comments on this? I'd like to get the series into linux-next soon. There was one other problem 0-day reported when building with CONFIG_OF=n while setting CONFIG_OF_ALL_DTBS=y on the kernel command line. The problem is dtc is not built as setting options on the command line doesn't invoke kconfig select(s). This can be fixed by also adding CONFIG_DTC=y to the command line, always building dtc regardless of Kconfig, or making 'all' conditionally dependent on 'dtbs'. I've gone with the last option as that is how this problem was avoided before. So the hunk in question with the 2 fixes now looks like this: @@ -1215,6 +1215,35 @@ kselftest-merge: $(srctree)/tools/testing/selftests/*/config +$(Q)$(MAKE) -f $(srctree)/Makefile olddefconfig +# --- +# Devicetree files + +ifneq ($(wildcard $(srctree)/arch/$(SRCARCH)/boot/dts/),) +dtstree := arch/$(SRCARCH)/boot/dts +endif + +ifneq ($(dtstree),) + +%.dtb : scripts_dtc + $(Q)$(MAKE) $(build)=$(dtstree) $(dtstree)/$@ + +PHONY += dtbs dtbs_install +dtbs: scripts_dtc + $(Q)$(MAKE) $(build)=$(dtstree) + +dtbs_install: dtbs + $(Q)$(MAKE) $(dtbinst)=$(dtstree) + +ifdef CONFIG_OF_EARLY_FLATTREE +all: dtbs +endif + +endif + +PHONY += scripts_dtc +scripts_dtc: scripts_basic + $(Q)$(MAKE) $(build)=scripts/dtc + # --- # Modules ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v3 2/2] dt-bindings: Document the Synopsys GPIO via CREG bindings
On Tue, 11 Sep 2018 18:09:25 +0300, Eugeniy Paltsev wrote: > This patch adds documentation of device tree bindings for the Synopsys > GPIO via CREG driver. > > Signed-off-by: Eugeniy Paltsev > --- > .../devicetree/bindings/gpio/snps,creg-gpio.txt| 18 > ++ > 1 file changed, 18 insertions(+) > create mode 100644 Documentation/devicetree/bindings/gpio/snps,creg-gpio.txt > Reviewed-by: Rob Herring ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH] ARC: Get rid of toolchain check
On Thu, Sep 13, 2018 at 3:24 PM Alexey Brodkin wrote: > > This check is very naive: we simply test if GCC invoked without > "-mcpu=XXX" has ARC700 define set. In that case we think that GCC > was built with "--with-cpu=arc700" and has libgcc built for ARC700. > > Otherwise if ARC700 is not defined we think that everythng was built > for ARCv2. > > But in reality our life is much more interesting. > > 1. Regardless of GCC configuration (i.e. what we pass in "--with-cpu" >it may generate code for any ARC core). > > 2. libgcc might be built with explicitly specified "--mcpu=YYY" > > That's exactly what happens in case of multilibbed toolchains: > - GCC is configured with default settings > - All the libs built for many different CPU flavors > > I.e. that check gets in the way of usage of multilibbed > toolchains. And even non-multilibbed toolchains are affected. > OpenEmbedded also builds GCC without "--with-cpu" because > each and every target component later is compiled with explicitly > set "-mcpu=ZZZ". > > Signed-off-by: Alexey Brodkin > --- > arch/arc/Makefile | 14 -- > 1 file changed, 14 deletions(-) +1 for this. Removing it also helps with my work to be able to build all the .dts files with only a host compiler. That also needs the hunk setting CROSS_COMPILE removed and not having a built-in dtb by default, but this is a step in the right direction. Acked-by: Rob Herring Rob ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v3 6/9] kbuild: consolidate Devicetree dtb build rules
On Mon, Sep 10, 2018 at 10:04 AM Rob Herring wrote: > > There is nothing arch specific about building dtb files other than their > location under /arch/*/boot/dts/. Keeping each arch aligned is a pain. > The dependencies and supported targets are all slightly different. > Also, a cross-compiler for each arch is needed, but really the host > compiler preprocessor is perfectly fine for building dtbs. Move the > build rules to a common location and remove the arch specific ones. This > is done in a single step to avoid warnings about overriding rules. > > The build dependencies had been a mixture of 'scripts' and/or 'prepare'. > These pull in several dependencies some of which need a target compiler > (specifically devicetable-offsets.h) and aren't needed to build dtbs. > All that is really needed is dtc, so adjust the dependencies to only be > dtc. > > This change enables support 'dtbs_install' on some arches which were > missing the target. [...] > @@ -1215,6 +1215,33 @@ kselftest-merge: > $(srctree)/tools/testing/selftests/*/config > +$(Q)$(MAKE) -f $(srctree)/Makefile olddefconfig > > +# --- > +# Devicetree files > + > +ifneq ($(wildcard $(srctree)/arch/$(SRCARCH)/boot/dts/),) > +dtstree := arch/$(SRCARCH)/boot/dts > +endif > + > +ifdef CONFIG_OF_EARLY_FLATTREE This can be true when dtstree is unset. So this line should be this instead to fix the 0-day reported error: ifneq ($(dtstree),) > + > +%.dtb : scripts_dtc > + $(Q)$(MAKE) $(build)=$(dtstree) $(dtstree)/$@ > + > +PHONY += dtbs dtbs_install > +dtbs: scripts_dtc > + $(Q)$(MAKE) $(build)=$(dtstree) > + > +dtbs_install: dtbs > + $(Q)$(MAKE) $(dtbinst)=$(dtstree) > + > +all: dtbs > + > +endif ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[PATCH v3 6/9] kbuild: consolidate Devicetree dtb build rules
There is nothing arch specific about building dtb files other than their location under /arch/*/boot/dts/. Keeping each arch aligned is a pain. The dependencies and supported targets are all slightly different. Also, a cross-compiler for each arch is needed, but really the host compiler preprocessor is perfectly fine for building dtbs. Move the build rules to a common location and remove the arch specific ones. This is done in a single step to avoid warnings about overriding rules. The build dependencies had been a mixture of 'scripts' and/or 'prepare'. These pull in several dependencies some of which need a target compiler (specifically devicetable-offsets.h) and aren't needed to build dtbs. All that is really needed is dtc, so adjust the dependencies to only be dtc. This change enables support 'dtbs_install' on some arches which were missing the target. Acked-by: Will Deacon Acked-by: Paul Burton Acked-by: Ley Foon Tan Cc: Masahiro Yamada Cc: Michal Marek Cc: Vineet Gupta Cc: Russell King Cc: Catalin Marinas Cc: Yoshinori Sato Cc: Michal Simek Cc: Ralf Baechle Cc: James Hogan Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Cc: Michael Ellerman Cc: Chris Zankel Cc: Max Filippov Cc: linux-kbu...@vger.kernel.org Cc: linux-snps-arc@lists.infradead.org Cc: linux-arm-ker...@lists.infradead.org Cc: uclinux-h8-de...@lists.sourceforge.jp Cc: linux-m...@linux-mips.org Cc: nios2-...@lists.rocketboards.org Cc: linuxppc-...@lists.ozlabs.org Cc: linux-xte...@linux-xtensa.org Signed-off-by: Rob Herring --- Makefile | 35 ++- arch/arc/Makefile | 6 -- arch/arm/Makefile | 20 +- arch/arm64/Makefile | 17 +-- arch/c6x/Makefile | 2 -- arch/h8300/Makefile | 11 +- arch/microblaze/Makefile | 4 +--- arch/microblaze/boot/dts/Makefile | 2 ++ arch/mips/Makefile| 15 + arch/nds32/Makefile | 2 +- arch/nios2/Makefile | 7 --- arch/nios2/boot/Makefile | 4 arch/powerpc/Makefile | 3 --- arch/xtensa/Makefile | 12 +-- scripts/Makefile | 3 +-- scripts/Makefile.lib | 2 +- scripts/dtc/Makefile | 2 +- 17 files changed, 46 insertions(+), 101 deletions(-) diff --git a/Makefile b/Makefile index 19948e556941..c43859eba70f 100644 --- a/Makefile +++ b/Makefile @@ -1071,7 +1071,7 @@ include/config/kernel.release: $(srctree)/Makefile FORCE # Carefully list dependencies so we do not try to build scripts twice # in parallel PHONY += scripts -scripts: scripts_basic asm-generic gcc-plugins $(autoksyms_h) +scripts: scripts_basic scripts_dtc asm-generic gcc-plugins $(autoksyms_h) $(Q)$(MAKE) $(build)=$(@) # Things we need to do before we recursively start building the kernel @@ -1215,6 +1215,33 @@ kselftest-merge: $(srctree)/tools/testing/selftests/*/config +$(Q)$(MAKE) -f $(srctree)/Makefile olddefconfig +# --- +# Devicetree files + +ifneq ($(wildcard $(srctree)/arch/$(SRCARCH)/boot/dts/),) +dtstree := arch/$(SRCARCH)/boot/dts +endif + +ifdef CONFIG_OF_EARLY_FLATTREE + +%.dtb : scripts_dtc + $(Q)$(MAKE) $(build)=$(dtstree) $(dtstree)/$@ + +PHONY += dtbs dtbs_install +dtbs: scripts_dtc + $(Q)$(MAKE) $(build)=$(dtstree) + +dtbs_install: dtbs + $(Q)$(MAKE) $(dtbinst)=$(dtstree) + +all: dtbs + +endif + +PHONY += scripts_dtc +scripts_dtc: scripts_basic + $(Q)$(MAKE) $(build)=scripts/dtc + # --- # Modules @@ -1424,6 +1451,12 @@ help: @echo ' kselftest-merge - Merge all the config dependencies of kselftest to existing' @echo '.config.' @echo '' + @$(if $(dtstree), \ + echo 'Devicetree:'; \ + echo '* dtbs- Build device tree blobs for enabled boards'; \ + echo ' dtbs_install- Install dtbs to $(INSTALL_DTBS_PATH)'; \ + echo '') + @echo 'Userspace tools targets:' @echo ' use "make tools/help"' @echo ' or "cd tools; make help"' diff --git a/arch/arc/Makefile b/arch/arc/Makefile index fb026196aaab..5c7bc6d62f43 100644 --- a/arch/arc/Makefile +++ b/arch/arc/Makefile @@ -132,11 +132,5 @@ boot_targets += uImage uImage.bin uImage.gz $(boot_targets): vmlinux $(Q)$(MAKE) $(build)=$(boot) $(boot)/$@ -%.dtb %.dtb.S %.dtb.o: scripts - $(Q)$(MAKE) $(build)=$(boot)/dts $(boot)/dts/$@ - -dtbs: scripts - $(Q)$(MAKE) $(build)=$(boot)/dts - archclean: $(Q)$(MAKE)
[PATCH v3 0/9] Devicetree build consolidation
This series addresses a couple of issues I have with building dts files. First, the ability to build all the dts files in the tree. This has been supported on most arches for some time with powerpc being the main exception. The reason powerpc wasn't supported was it needed a change in the location built dtb files are put. Secondly, it's a pain to acquire all the cross-compilers needed to build dtbs for each arch. There's no reason to build with the cross compiler and the host compiler is perfectly fine as we only need the pre-processor. I started addressing just those 2 problems, but kept finding small differences such as target dependencies and dtbs_install support across architectures. Instead of trying to align all these, I've consolidated the build targets moving them out of the arch makefiles. I'd like to take the series via the DT tree. Rob v3: - Rework dtc dependency to avoid 2 entry paths to scripts/dtc/. Essentially, I copied 'scripts_basic'. - Add missing scripts_basic dependency for dtc and missing PHONY tag. - Drop the '|' order only from dependencies - Drop %.dtb.S and %.dtb.o as top-level targets - PPC: remove duplicate mpc5200 dtbs from image-y targets v2: - Fix $arch/boot/dts path check for out of tree builds - Fix dtc dependency for building built-in dtbs - Fix microblaze built-in dtb building - Add dtbs target for microblaze Rob Herring (9): powerpc: build .dtb files in dts directory nios2: build .dtb files in dts directory nios2: use common rules to build built-in dtb nios2: fix building all dtbs c6x: use common built-in dtb support kbuild: consolidate Devicetree dtb build rules powerpc: enable building all dtbs c6x: enable building all dtbs microblaze: enable building all dtbs Makefile | 35 ++- arch/arc/Makefile | 6 arch/arm/Makefile | 20 +-- arch/arm64/Makefile| 17 + arch/c6x/Makefile | 2 -- arch/c6x/boot/dts/Makefile | 17 - arch/c6x/boot/dts/linked_dtb.S | 2 -- arch/c6x/include/asm/sections.h| 1 - arch/c6x/kernel/setup.c| 4 +-- arch/c6x/kernel/vmlinux.lds.S | 10 -- arch/h8300/Makefile| 11 +- arch/microblaze/Makefile | 4 +-- arch/microblaze/boot/dts/Makefile | 4 +++ arch/mips/Makefile | 15 +--- arch/nds32/Makefile| 2 +- arch/nios2/Makefile| 11 +- arch/nios2/boot/Makefile | 22 arch/nios2/boot/dts/Makefile | 6 arch/nios2/boot/linked_dtb.S | 19 --- arch/powerpc/Makefile | 3 -- arch/powerpc/boot/Makefile | 55 ++ arch/powerpc/boot/dts/Makefile | 6 arch/powerpc/boot/dts/fsl/Makefile | 4 +++ arch/xtensa/Makefile | 12 +-- scripts/Makefile | 3 +- scripts/Makefile.lib | 2 +- scripts/dtc/Makefile | 2 +- 27 files changed, 100 insertions(+), 195 deletions(-) delete mode 100644 arch/c6x/boot/dts/linked_dtb.S create mode 100644 arch/nios2/boot/dts/Makefile delete mode 100644 arch/nios2/boot/linked_dtb.S create mode 100644 arch/powerpc/boot/dts/Makefile create mode 100644 arch/powerpc/boot/dts/fsl/Makefile -- 2.17.1 ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v2 6/9] kbuild: consolidate Devicetree dtb build rules
On Sun, Sep 9, 2018 at 6:28 PM Masahiro Yamada wrote: > > 2018-09-06 8:53 GMT+09:00 Rob Herring : > > There is nothing arch specific about building dtb files other than their > > location under /arch/*/boot/dts/. Keeping each arch aligned is a pain. > > The dependencies and supported targets are all slightly different. > > Also, a cross-compiler for each arch is needed, but really the host > > compiler preprocessor is perfectly fine for building dtbs. Move the > > build rules to a common location and remove the arch specific ones. This > > is done in a single step to avoid warnings about overriding rules. > > > > The build dependencies had been a mixture of 'scripts' and/or 'prepare'. > > These pull in several dependencies some of which need a target compiler > > (specifically devicetable-offsets.h) and aren't needed to build dtbs. > > All that is really needed is dtc, so adjust the dependencies to only be > > dtc. > > > > This change enables support 'dtbs_install' on some arches which were > > missing the target. > > > > Cc: Masahiro Yamada > > Cc: Michal Marek > > Cc: Vineet Gupta > > Cc: Russell King > > Cc: Catalin Marinas > > Cc: Will Deacon > > Cc: Yoshinori Sato > > Cc: Michal Simek > > Cc: Ralf Baechle > > Cc: Paul Burton > > Cc: James Hogan > > Cc: Ley Foon Tan > > Cc: Benjamin Herrenschmidt > > Cc: Paul Mackerras > > Cc: Michael Ellerman > > Cc: Chris Zankel > > Cc: Max Filippov > > Cc: linux-kbu...@vger.kernel.org > > Cc: linux-snps-arc@lists.infradead.org > > Cc: linux-arm-ker...@lists.infradead.org > > Cc: uclinux-h8-de...@lists.sourceforge.jp > > Cc: linux-m...@linux-mips.org > > Cc: nios2-...@lists.rocketboards.org > > Cc: linuxppc-...@lists.ozlabs.org > > Cc: linux-xte...@linux-xtensa.org > > Signed-off-by: Rob Herring > > --- > > Please ack so I can take the whole series via the DT tree. > > > > v2: > > - Fix $arch/boot/dts path check for out of tree builds > > - Fix dtc dependency for building built-in dtbs > > - Fix microblaze built-in dtb building > > > > Makefile | 32 +++ > > arch/arc/Makefile | 6 -- > > arch/arm/Makefile | 20 +-- > > arch/arm64/Makefile | 17 +--- > > arch/c6x/Makefile | 2 -- > > arch/h8300/Makefile | 11 +-- > > arch/microblaze/Makefile | 4 +--- > > arch/microblaze/boot/dts/Makefile | 2 ++ > > arch/mips/Makefile| 15 +-- > > arch/nds32/Makefile | 2 +- > > arch/nios2/Makefile | 7 --- > > arch/nios2/boot/Makefile | 4 > > arch/powerpc/Makefile | 3 --- > > arch/xtensa/Makefile | 12 +--- > > scripts/Makefile.lib | 2 +- > > 15 files changed, 42 insertions(+), 97 deletions(-) > > > > diff --git a/Makefile b/Makefile > > index 2b458801ba74..bc18dbbc16c5 100644 > > --- a/Makefile > > +++ b/Makefile > > @@ -1212,6 +1212,32 @@ kselftest-merge: > > $(srctree)/tools/testing/selftests/*/config > > +$(Q)$(MAKE) -f $(srctree)/Makefile olddefconfig > > > > +# > > --- > > +# Devicetree files > > + > > +ifneq ($(wildcard $(srctree)/arch/$(SRCARCH)/boot/dts/),) > > +dtstree := arch/$(SRCARCH)/boot/dts > > +endif > > + > > +ifdef CONFIG_OF_EARLY_FLATTREE > > + > > +%.dtb %.dtb.S %.dtb.o: | dtc > > + $(Q)$(MAKE) $(build)=$(dtstree) $(dtstree)/$@ > > > Hmm, I was worried about '%.dtb.o: | dtc' > but seems working. > > Compiling %.S -> %.o requires objtool for x86, > but x86 does not support DT. Well, x86 does support DT to some extent. There's 2 platforms and the DT unittests build and run on x86. Actually, we can remove "%.dtb.S %.dtb.o" because we don't need those as top-level build targets. Must have been a copy-n-paste relic from before having common rules. > > If CONFIG_MODVERSIONS=y, scripts/genksyms/genksyms is required, > %.dtb.S does not contain EXPORT_SYMBOL. Okay, but that shouldn't affect any of this. We only build *.dtb.S when doing built-in dtbs. > BTW, 'dtc' should be a PHONY target. Right, I found that too. Rob ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v2 6/9] kbuild: consolidate Devicetree dtb build rules
On Fri, Sep 7, 2018 at 5:33 AM Masahiro Yamada wrote: > > 2018-09-06 8:53 GMT+09:00 Rob Herring : > > There is nothing arch specific about building dtb files other than their > > location under /arch/*/boot/dts/. Keeping each arch aligned is a pain. > > The dependencies and supported targets are all slightly different. > > Also, a cross-compiler for each arch is needed, but really the host > > compiler preprocessor is perfectly fine for building dtbs. Move the > > build rules to a common location and remove the arch specific ones. This > > is done in a single step to avoid warnings about overriding rules. > > > > The build dependencies had been a mixture of 'scripts' and/or 'prepare'. > > These pull in several dependencies some of which need a target compiler > > (specifically devicetable-offsets.h) and aren't needed to build dtbs. > > All that is really needed is dtc, so adjust the dependencies to only be > > dtc. > > > > This change enables support 'dtbs_install' on some arches which were > > missing the target. > > > > Cc: Masahiro Yamada > > Cc: Michal Marek > > Cc: Vineet Gupta > > Cc: Russell King > > Cc: Catalin Marinas > > Cc: Will Deacon > > Cc: Yoshinori Sato > > Cc: Michal Simek > > Cc: Ralf Baechle > > Cc: Paul Burton > > Cc: James Hogan > > Cc: Ley Foon Tan > > Cc: Benjamin Herrenschmidt > > Cc: Paul Mackerras > > Cc: Michael Ellerman > > Cc: Chris Zankel > > Cc: Max Filippov > > Cc: linux-kbu...@vger.kernel.org > > Cc: linux-snps-arc@lists.infradead.org > > Cc: linux-arm-ker...@lists.infradead.org > > Cc: uclinux-h8-de...@lists.sourceforge.jp > > Cc: linux-m...@linux-mips.org > > Cc: nios2-...@lists.rocketboards.org > > Cc: linuxppc-...@lists.ozlabs.org > > Cc: linux-xte...@linux-xtensa.org > > Signed-off-by: Rob Herring > > --- > > Please ack so I can take the whole series via the DT tree. > > > > v2: > > - Fix $arch/boot/dts path check for out of tree builds > > - Fix dtc dependency for building built-in dtbs > > - Fix microblaze built-in dtb building > > > This breaks parallel building > because two threads could descend into scripts/dtc > at the same time. > > 'all' depends on both 'scripts' and 'dtc'. > > * 'scripts' target -- descends into scripts/, then scripts/dtc > * 'dtc' target -- descents into scripts/dtc directly Any suggestions for how to fix given the problem with depending on scripts? I suppose I could make scripts depend on dtc instead, but I'd be back to needing to fix cleaning. Or I could just skip removing the cross compiler dependency for now. Rob ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[PATCH v2 6/9] kbuild: consolidate Devicetree dtb build rules
There is nothing arch specific about building dtb files other than their location under /arch/*/boot/dts/. Keeping each arch aligned is a pain. The dependencies and supported targets are all slightly different. Also, a cross-compiler for each arch is needed, but really the host compiler preprocessor is perfectly fine for building dtbs. Move the build rules to a common location and remove the arch specific ones. This is done in a single step to avoid warnings about overriding rules. The build dependencies had been a mixture of 'scripts' and/or 'prepare'. These pull in several dependencies some of which need a target compiler (specifically devicetable-offsets.h) and aren't needed to build dtbs. All that is really needed is dtc, so adjust the dependencies to only be dtc. This change enables support 'dtbs_install' on some arches which were missing the target. Cc: Masahiro Yamada Cc: Michal Marek Cc: Vineet Gupta Cc: Russell King Cc: Catalin Marinas Cc: Will Deacon Cc: Yoshinori Sato Cc: Michal Simek Cc: Ralf Baechle Cc: Paul Burton Cc: James Hogan Cc: Ley Foon Tan Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Cc: Michael Ellerman Cc: Chris Zankel Cc: Max Filippov Cc: linux-kbu...@vger.kernel.org Cc: linux-snps-arc@lists.infradead.org Cc: linux-arm-ker...@lists.infradead.org Cc: uclinux-h8-de...@lists.sourceforge.jp Cc: linux-m...@linux-mips.org Cc: nios2-...@lists.rocketboards.org Cc: linuxppc-...@lists.ozlabs.org Cc: linux-xte...@linux-xtensa.org Signed-off-by: Rob Herring --- Please ack so I can take the whole series via the DT tree. v2: - Fix $arch/boot/dts path check for out of tree builds - Fix dtc dependency for building built-in dtbs - Fix microblaze built-in dtb building Makefile | 32 +++ arch/arc/Makefile | 6 -- arch/arm/Makefile | 20 +-- arch/arm64/Makefile | 17 +--- arch/c6x/Makefile | 2 -- arch/h8300/Makefile | 11 +-- arch/microblaze/Makefile | 4 +--- arch/microblaze/boot/dts/Makefile | 2 ++ arch/mips/Makefile| 15 +-- arch/nds32/Makefile | 2 +- arch/nios2/Makefile | 7 --- arch/nios2/boot/Makefile | 4 arch/powerpc/Makefile | 3 --- arch/xtensa/Makefile | 12 +--- scripts/Makefile.lib | 2 +- 15 files changed, 42 insertions(+), 97 deletions(-) diff --git a/Makefile b/Makefile index 2b458801ba74..bc18dbbc16c5 100644 --- a/Makefile +++ b/Makefile @@ -1212,6 +1212,32 @@ kselftest-merge: $(srctree)/tools/testing/selftests/*/config +$(Q)$(MAKE) -f $(srctree)/Makefile olddefconfig +# --- +# Devicetree files + +ifneq ($(wildcard $(srctree)/arch/$(SRCARCH)/boot/dts/),) +dtstree := arch/$(SRCARCH)/boot/dts +endif + +ifdef CONFIG_OF_EARLY_FLATTREE + +%.dtb %.dtb.S %.dtb.o: | dtc + $(Q)$(MAKE) $(build)=$(dtstree) $(dtstree)/$@ + +PHONY += dtbs +dtbs: | dtc + $(Q)$(MAKE) $(build)=$(dtstree) + +dtbs_install: dtbs + $(Q)$(MAKE) $(dtbinst)=$(dtstree) + +all: dtbs + +dtc: + $(Q)$(MAKE) $(build)=scripts/dtc + +endif + # --- # Modules @@ -1421,6 +1447,12 @@ help: @echo ' kselftest-merge - Merge all the config dependencies of kselftest to existing' @echo '.config.' @echo '' + @$(if $(dtstree), \ + echo 'Devicetree:'; \ + echo '* dtbs- Build device tree blobs for enabled boards'; \ + echo ' dtbs_install- Install dtbs to $(INSTALL_DTBS_PATH)'; \ + echo '') + @echo 'Userspace tools targets:' @echo ' use "make tools/help"' @echo ' or "cd tools; make help"' diff --git a/arch/arc/Makefile b/arch/arc/Makefile index fb026196aaab..5c7bc6d62f43 100644 --- a/arch/arc/Makefile +++ b/arch/arc/Makefile @@ -132,11 +132,5 @@ boot_targets += uImage uImage.bin uImage.gz $(boot_targets): vmlinux $(Q)$(MAKE) $(build)=$(boot) $(boot)/$@ -%.dtb %.dtb.S %.dtb.o: scripts - $(Q)$(MAKE) $(build)=$(boot)/dts $(boot)/dts/$@ - -dtbs: scripts - $(Q)$(MAKE) $(build)=$(boot)/dts - archclean: $(Q)$(MAKE) $(clean)=$(boot) diff --git a/arch/arm/Makefile b/arch/arm/Makefile index d1516f85f25d..161c2df6567e 100644 --- a/arch/arm/Makefile +++ b/arch/arm/Makefile @@ -307,12 +307,7 @@ else KBUILD_IMAGE := $(boot)/zImage endif -# Build the DT binary blobs if we have OF configured -ifeq ($(CONFIG_USE_OF),y) -KBUILD_DTBS := dtbs -endif - -all: $(notdir $(KBUILD_IMAGE)) $(KBUILD_DTB
[PATCH v2 0/9] Devicetree build consolidation
This series addresses a couple of issues I have with building dts files. First, the ability to build all the dts files in the tree. This has been supported on most arches for some time with powerpc being the main exception. The reason powerpc wasn't supported was it needed a change in the location built dtb files are put. Secondly, it's a pain to acquire all the cross-compilers needed to build dtbs for each arch. There's no reason to build with the cross compiler and the host compiler is perfectly fine as we only need the pre-processor. I started addressing just those 2 problems, but kept finding small differences such as target dependencies and dtbs_install support across architectures. Instead of trying to align all these, I've consolidated the build targets moving them out of the arch makefiles. I'd like to take the series via the DT tree. Rob v2: - Fix $arch/boot/dts path check for out of tree builds - Fix dtc dependency for building built-in dtbs - Fix microblaze built-in dtb building - Add dtbs target for microblaze Rob Herring (9): powerpc: build .dtb files in dts directory nios2: build .dtb files in dts directory nios2: use common rules to build built-in dtb nios2: fix building all dtbs c6x: use common built-in dtb support kbuild: consolidate Devicetree dtb build rules powerpc: enable building all dtbs c6x: enable building all dtbs microblaze: enable building all dtbs Makefile | 32 +++ arch/arc/Makefile | 6 arch/arm/Makefile | 20 +--- arch/arm64/Makefile| 17 +-- arch/c6x/Makefile | 2 -- arch/c6x/boot/dts/Makefile | 17 +-- arch/c6x/boot/dts/linked_dtb.S | 2 -- arch/c6x/include/asm/sections.h| 1 - arch/c6x/kernel/setup.c| 4 +-- arch/c6x/kernel/vmlinux.lds.S | 10 -- arch/h8300/Makefile| 11 +-- arch/microblaze/Makefile | 4 +-- arch/microblaze/boot/dts/Makefile | 4 +++ arch/mips/Makefile | 15 + arch/nds32/Makefile| 2 +- arch/nios2/Makefile| 11 +-- arch/nios2/boot/Makefile | 22 -- arch/nios2/boot/dts/Makefile | 6 arch/nios2/boot/linked_dtb.S | 19 arch/powerpc/Makefile | 3 -- arch/powerpc/boot/Makefile | 49 ++ arch/powerpc/boot/dts/Makefile | 6 arch/powerpc/boot/dts/fsl/Makefile | 4 +++ arch/xtensa/Makefile | 12 +--- scripts/Makefile.lib | 2 +- 25 files changed, 93 insertions(+), 188 deletions(-) delete mode 100644 arch/c6x/boot/dts/linked_dtb.S create mode 100644 arch/nios2/boot/dts/Makefile delete mode 100644 arch/nios2/boot/linked_dtb.S create mode 100644 arch/powerpc/boot/dts/Makefile create mode 100644 arch/powerpc/boot/dts/fsl/Makefile -- 2.17.1 ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v2 2/2] dt-bindings: Document the Synopsys GPIO via CREG bindings
On Tue, Aug 28, 2018 at 02:27:21PM +0300, Eugeniy Paltsev wrote:
> This patch adds documentation of device tree bindings for the Synopsys
> GPIO via CREG driver.
>
> Signed-off-by: Eugeniy Paltsev
> ---
> .../devicetree/bindings/gpio/snps,creg-gpio.txt| 49
> ++
> 1 file changed, 49 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/gpio/snps,creg-gpio.txt
>
> diff --git a/Documentation/devicetree/bindings/gpio/snps,creg-gpio.txt
> b/Documentation/devicetree/bindings/gpio/snps,creg-gpio.txt
> new file mode 100644
> index ..eb022d44ccda
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/gpio/snps,creg-gpio.txt
> @@ -0,0 +1,49 @@
> +GPIO via CREG (Control REGisers) driver
REGisters?
Bindings don't describe drivers.
> +
> +This is is single-register MMIO GPIO driver to control such strangely mapped
> +outputs:
> +
> +31118 75 0 < bit number
> +| || || |
> +[ not used | gpio-1 | shift-1 | gpio-0 | shift-0 ] < 32 bit MMIO
> register
> + ^ ^
> + | |
> + | write 0x2 == set output to "1" (on)
> + | write 0x3 == set output to "0" (off)
> + |
> +write 0x1 == set output to "1" (on)
> +write 0x4 == set output to "0" (off)
What kind of crazy h/w designer designed this?
> +Required properties:
> +- compatible : "snps,creg-gpio"
> +- reg : Exactly one register range with length 0x4.
> +- #gpio-cells : Should be one - the pin number.
> +- gpio-controller : Marks the device node as a GPIO controller.
> +- snps,ngpios: Number of GPIO pins.
> +- snps,bit-per-line: Number of bits per each gpio line (see picture).
> + Array the size of "snps,ngpios"
> +- snps,shift: Shift (in bits) of the each GPIO field from the previous one in
> + register (see picture). Array the size of "snps,ngpios"
> +- snps,on-val: Value should be set in corresponding field to set
> + output to "1" (see picture). Array the size of "snps,ngpios"
> +- snps,off-val: Value should be set in corresponding field to set
> + output to "0" (see picture). Array the size of "snps,ngpios"
Convince me we need to parameterize all this. We try to avoid describing
h/w like this.
> +
> +Optional properties:
> +- snps,default-val: default output field values. Array the size of
> "snps,ngpios"
> +
> +Example (see picture):
> +
> +gpio: gpio@f00014b0 {
> + compatible = "snps,creg-gpio";
> + reg = <0xf00014b0 0x4>;
> + gpio-controller;
> + #gpio-cells = <1>;
> + snps,ngpios = <2>;
> + snps,shift = <5 1>;
> + snps,bit-per-line = <2 3>;
> + snps,on-val = <2 1>;
> + snps,off-val = <3 4>;
> + snps,default-val = <2 1>;
> +};
> --
> 2.14.4
>
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 6/8] kbuild: consolidate Devicetree dtb build rules
On Sat, Aug 25, 2018 at 9:06 PM Masahiro Yamada wrote: > > Hi Rob, > > > 2018-08-22 6:55 GMT+09:00 Rob Herring : > > There is nothing arch specific about building dtb files other than their > > location under /arch/*/boot/dts/. Keeping each arch aligned is a pain. > > The dependencies and supported targets are all slightly different. > > Also, a cross-compiler for each arch is needed, but really the host > > compiler preprocessor is perfectly fine for building dtbs. Move the > > build rules to a common location and remove the arch specific ones. This > > is done in a single step to avoid warnings about overriding rules. > > > > The build dependencies had been a mixture of 'scripts' and/or 'prepare'. > > These pull in several dependencies some of which need a target compiler > > (specifically devicetable-offsets.h) and aren't needed to build dtbs. > > All that is really needed is dtc, so adjust the dependencies to only be > > dtc. > > > > This change enables support 'dtbs_install' on some arches which were > > missing the target. > > > > Cc: Masahiro Yamada > > Cc: Michal Marek > > Cc: Vineet Gupta > > Cc: Russell King > > Cc: Catalin Marinas > > Cc: Will Deacon > > Cc: Yoshinori Sato > > Cc: Michal Simek > > Cc: Ralf Baechle > > Cc: Paul Burton > > Cc: James Hogan > > Cc: Ley Foon Tan > > Cc: Benjamin Herrenschmidt > > Cc: Paul Mackerras > > Cc: Michael Ellerman > > Cc: Chris Zankel > > Cc: Max Filippov > > Cc: linux-kbu...@vger.kernel.org > > Cc: linux-snps-arc@lists.infradead.org > > Cc: linux-arm-ker...@lists.infradead.org > > Cc: uclinux-h8-de...@lists.sourceforge.jp > > Cc: linux-m...@linux-mips.org > > Cc: nios2-...@lists.rocketboards.org > > Cc: linuxppc-...@lists.ozlabs.org > > Cc: linux-xte...@linux-xtensa.org > > Signed-off-by: Rob Herring > > --- > > Makefile | 30 ++ > > arch/arc/Makefile| 6 -- > > arch/arm/Makefile| 20 +--- > > arch/arm64/Makefile | 17 + > > arch/c6x/Makefile| 2 -- > > arch/h8300/Makefile | 11 +-- > > arch/microblaze/Makefile | 4 +--- > > arch/mips/Makefile | 15 +-- > > arch/nds32/Makefile | 2 +- > > arch/nios2/Makefile | 7 --- > > arch/nios2/boot/Makefile | 4 > > arch/powerpc/Makefile| 3 --- > > arch/xtensa/Makefile | 12 +--- > > scripts/Makefile | 1 - > > scripts/Makefile.lib | 2 +- > > 15 files changed, 38 insertions(+), 98 deletions(-) > > > > diff --git a/Makefile b/Makefile > > index c13f8b85ba60..6d89e673f192 100644 > > --- a/Makefile > > +++ b/Makefile > > @@ -1212,6 +1212,30 @@ kselftest-merge: > > $(srctree)/tools/testing/selftests/*/config > > +$(Q)$(MAKE) -f $(srctree)/Makefile olddefconfig > > > > +# > > --- > > +# Devicetree files > > + > > +dtstree := $(wildcard arch/$(SRCARCH)/boot/dts) BTW, there's an error here too. It doesn't work right with KBUILD_OUTPUT set and should be: ifneq ($(wildcard $(srctree)/arch/$(SRCARCH)/boot/dts/),) dtstree := arch/$(SRCARCH)/boot/dts endif > > + > > +ifdef CONFIG_OF_EARLY_FLATTREE > > + > > +%.dtb %.dtb.S %.dtb.o: | dtc > > I think the pipe operator is unnecessary > because Kbuild will descend to $(dtstree) anyway. The pipe means 'order-only', right? So it is just a weaker dependency for things which are not input files as dtc is not. The 'dtc' here is just the dtc rule below, not the actual executable. Or am I missing something? > > + $(Q)$(MAKE) $(build)=$(dtstree) $(dtstree)/$@ > > + > > +PHONY += dtbs > > +dtbs: | dtc > > Ditto. > > > > + $(Q)$(MAKE) $(build)=$(dtstree) > > + > > +dtbs_install: dtbs > > + $(Q)$(MAKE) $(dtbinst)=$(dtstree) > > + > > +all: dtbs > > + > > +dtc: > > + $(Q)$(MAKE) $(build)=scripts/dtc > > + > > +endif > > + > > > arch/*/boot/dts/ are not only directories that > require dtc. Ah yes, of course... > > diff --git a/scripts/Makefile b/scripts/Makefile > > index 61affa300d25..a716a6b10954 100644 > > --- a/scripts/Makefile > > +++ b/scripts/Makefile > > @@ -39,7 +39,6 @@ build_unifdef: $(obj)/unifdef > > subdir-$(CONFIG_MODVERSIONS) += genksyms > > subdir-y += mod > > subdir-$(CONFIG_SECURITY_SELINUX) += selinux > > -subdir-$(CONFIG_DTC) += dtc > > subdir-$(CONFIG_GDB_SCRIPTS) += gdb > > > > # Let clean descend into subdirs Looks like I need to leave this line to fix the above and cleaning. Thanks for the review. Rob ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[PATCH 6/8] kbuild: consolidate Devicetree dtb build rules
There is nothing arch specific about building dtb files other than their location under /arch/*/boot/dts/. Keeping each arch aligned is a pain. The dependencies and supported targets are all slightly different. Also, a cross-compiler for each arch is needed, but really the host compiler preprocessor is perfectly fine for building dtbs. Move the build rules to a common location and remove the arch specific ones. This is done in a single step to avoid warnings about overriding rules. The build dependencies had been a mixture of 'scripts' and/or 'prepare'. These pull in several dependencies some of which need a target compiler (specifically devicetable-offsets.h) and aren't needed to build dtbs. All that is really needed is dtc, so adjust the dependencies to only be dtc. This change enables support 'dtbs_install' on some arches which were missing the target. Cc: Masahiro Yamada Cc: Michal Marek Cc: Vineet Gupta Cc: Russell King Cc: Catalin Marinas Cc: Will Deacon Cc: Yoshinori Sato Cc: Michal Simek Cc: Ralf Baechle Cc: Paul Burton Cc: James Hogan Cc: Ley Foon Tan Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Cc: Michael Ellerman Cc: Chris Zankel Cc: Max Filippov Cc: linux-kbu...@vger.kernel.org Cc: linux-snps-arc@lists.infradead.org Cc: linux-arm-ker...@lists.infradead.org Cc: uclinux-h8-de...@lists.sourceforge.jp Cc: linux-m...@linux-mips.org Cc: nios2-...@lists.rocketboards.org Cc: linuxppc-...@lists.ozlabs.org Cc: linux-xte...@linux-xtensa.org Signed-off-by: Rob Herring --- Makefile | 30 ++ arch/arc/Makefile| 6 -- arch/arm/Makefile| 20 +--- arch/arm64/Makefile | 17 + arch/c6x/Makefile| 2 -- arch/h8300/Makefile | 11 +-- arch/microblaze/Makefile | 4 +--- arch/mips/Makefile | 15 +-- arch/nds32/Makefile | 2 +- arch/nios2/Makefile | 7 --- arch/nios2/boot/Makefile | 4 arch/powerpc/Makefile| 3 --- arch/xtensa/Makefile | 12 +--- scripts/Makefile | 1 - scripts/Makefile.lib | 2 +- 15 files changed, 38 insertions(+), 98 deletions(-) diff --git a/Makefile b/Makefile index c13f8b85ba60..6d89e673f192 100644 --- a/Makefile +++ b/Makefile @@ -1212,6 +1212,30 @@ kselftest-merge: $(srctree)/tools/testing/selftests/*/config +$(Q)$(MAKE) -f $(srctree)/Makefile olddefconfig +# --- +# Devicetree files + +dtstree := $(wildcard arch/$(SRCARCH)/boot/dts) + +ifdef CONFIG_OF_EARLY_FLATTREE + +%.dtb %.dtb.S %.dtb.o: | dtc + $(Q)$(MAKE) $(build)=$(dtstree) $(dtstree)/$@ + +PHONY += dtbs +dtbs: | dtc + $(Q)$(MAKE) $(build)=$(dtstree) + +dtbs_install: dtbs + $(Q)$(MAKE) $(dtbinst)=$(dtstree) + +all: dtbs + +dtc: + $(Q)$(MAKE) $(build)=scripts/dtc + +endif + # --- # Modules @@ -1425,6 +1449,12 @@ help: @echo ' kselftest-merge - Merge all the config dependencies of kselftest to existing' @echo '.config.' @echo '' + @$(if $(dtstree), \ + echo 'Devicetree:'; \ + echo '* dtbs- Build device tree blobs for enabled boards'; \ + echo ' dtbs_install- Install dtbs to $(INSTALL_DTBS_PATH)'; \ + echo '') + @echo 'Userspace tools targets:' @echo ' use "make tools/help"' @echo ' or "cd tools; make help"' diff --git a/arch/arc/Makefile b/arch/arc/Makefile index 6c1b20dd76ad..cbfb7a16b570 100644 --- a/arch/arc/Makefile +++ b/arch/arc/Makefile @@ -132,11 +132,5 @@ boot_targets += uImage uImage.bin uImage.gz $(boot_targets): vmlinux $(Q)$(MAKE) $(build)=$(boot) $(boot)/$@ -%.dtb %.dtb.S %.dtb.o: scripts - $(Q)$(MAKE) $(build)=$(boot)/dts $(boot)/dts/$@ - -dtbs: scripts - $(Q)$(MAKE) $(build)=$(boot)/dts - archclean: $(Q)$(MAKE) $(clean)=$(boot) diff --git a/arch/arm/Makefile b/arch/arm/Makefile index e7d703d8fac3..7f02ef8dfdb2 100644 --- a/arch/arm/Makefile +++ b/arch/arm/Makefile @@ -308,12 +308,7 @@ else KBUILD_IMAGE := $(boot)/zImage endif -# Build the DT binary blobs if we have OF configured -ifeq ($(CONFIG_USE_OF),y) -KBUILD_DTBS := dtbs -endif - -all: $(notdir $(KBUILD_IMAGE)) $(KBUILD_DTBS) +all: $(notdir $(KBUILD_IMAGE)) archheaders: @@ -340,17 +335,6 @@ $(BOOT_TARGETS): vmlinux $(INSTALL_TARGETS): $(Q)$(MAKE) $(build)=$(boot) MACHINE=$(MACHINE) $@ -%.dtb: | scripts - $(Q)$(MAKE) $(build)=$(boot)/dts MACHINE=$(MACHINE) $(boot)/dts/$@ - -PHONY += dtbs dtbs_install - -dtbs: prepare scripts - $(Q)$(MAKE) $(build)=$(boot)/dts - -dtbs_install: -
[PATCH 0/8] Devicetree build consolidation
This series addresses a couple of issues I have with building dts files. First, the ability to build all the dts files in the tree. This has been supported on most arches for some time with powerpc being the main exception. The reason powerpc wasn't supported was it needed a change in the location built dtb files are put. Secondly, it's a pain to acquire all the cross-compilers needed to build dtbs for each arch. There's no reason to build with the cross compiler and the host compiler is perfectly fine as we only need the pre-processor. I started addressing just those 2 problems, but kept finding small differences such as target dependencies and dtbs_install support across architectures. Instead of trying to align all these, I've consolidated the build targets moving them out of the arch makefiles. I'd like to take the series via the DT tree. Rob Rob Herring (8): powerpc: build .dtb files in dts directory nios2: build .dtb files in dts directory nios2: use common rules to build built-in dtb nios2: fix building all dtbs c6x: use common built-in dtb support kbuild: consolidate Devicetree dtb build rules powerpc: enable building all dtbs c6x: enable building all dtbs Makefile | 30 ++ arch/arc/Makefile | 6 arch/arm/Makefile | 20 +--- arch/arm64/Makefile| 17 +-- arch/c6x/Makefile | 2 -- arch/c6x/boot/dts/Makefile | 17 +-- arch/c6x/boot/dts/linked_dtb.S | 2 -- arch/c6x/include/asm/sections.h| 1 - arch/c6x/kernel/setup.c| 4 +-- arch/c6x/kernel/vmlinux.lds.S | 10 -- arch/h8300/Makefile| 11 +-- arch/microblaze/Makefile | 4 +-- arch/mips/Makefile | 15 + arch/nds32/Makefile| 2 +- arch/nios2/Makefile| 11 +-- arch/nios2/boot/Makefile | 22 -- arch/nios2/boot/dts/Makefile | 6 arch/nios2/boot/linked_dtb.S | 19 arch/powerpc/Makefile | 3 -- arch/powerpc/boot/Makefile | 49 ++ arch/powerpc/boot/dts/Makefile | 6 arch/powerpc/boot/dts/fsl/Makefile | 4 +++ arch/xtensa/Makefile | 12 +--- scripts/Makefile | 1 - scripts/Makefile.lib | 2 +- 25 files changed, 87 insertions(+), 189 deletions(-) delete mode 100644 arch/c6x/boot/dts/linked_dtb.S create mode 100644 arch/nios2/boot/dts/Makefile delete mode 100644 arch/nios2/boot/linked_dtb.S create mode 100644 arch/powerpc/boot/dts/Makefile create mode 100644 arch/powerpc/boot/dts/fsl/Makefile -- 2.17.1 ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v3 2/2] dt-bindings: Document the Synopsys DW AXI DMA bindings
On Tue, Mar 06, 2018 at 02:46:15PM +0300, Eugeniy Paltsev wrote: > This patch adds documentation of device tree bindings for the Synopsys > DesignWare AXI DMA controller. > > Signed-off-by: Eugeniy Paltsev > --- > Changes v2->v3: > * None. > > .../devicetree/bindings/dma/snps,dw-axi-dmac.txt | 41 > ++ > 1 file changed, 41 insertions(+) > create mode 100644 Documentation/devicetree/bindings/dma/snps,dw-axi-dmac.txt Reviewed-by: Rob Herring ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v2 2/2] dt-bindings: Document the Synopsys DW AXI DMA bindings
On Mon, Mar 05, 2018 at 11:02:56AM +0530, Vinod Koul wrote:
> On Fri, Mar 02, 2018 at 08:32:20AM +, Alexey Brodkin wrote:
> > Hi Vinod,
> >
> > On Fri, 2018-03-02 at 13:44 +0530, Vinod Koul wrote:
> > > On Mon, Feb 26, 2018 at 05:56:28PM +0300, Eugeniy Paltsev wrote:
> > > > This patch adds documentation of device tree bindings for the Synopsys
> > > > DesignWare AXI DMA controller.
> > > >
> > > > Signed-off-by: Eugeniy Paltsev
> > > > ---
> > > > .../devicetree/bindings/dma/snps,dw-axi-dmac.txt | 41
> > > > ++
> > > > 1 file changed, 41 insertions(+)
> > > > create mode 100644
> > > > Documentation/devicetree/bindings/dma/snps,dw-axi-dmac.txt
> > > >
> > > > diff --git a/Documentation/devicetree/bindings/dma/snps,dw-axi-dmac.txt
> > > > b/Documentation/devicetree/bindings/dma/snps,dw-axi-dmac.txt
> > > > new file mode 100644
> > > > index 000..f237b79
> > > > --- /dev/null
> > > > +++ b/Documentation/devicetree/bindings/dma/snps,dw-axi-dmac.txt
> > > > @@ -0,0 +1,41 @@
> > > > +Synopsys DesignWare AXI DMA Controller
> > > > +
> > > > +Required properties:
> > > > +- compatible: "snps,axi-dma-1.01a"
> > > > +- reg: Address range of the DMAC registers. This should include
> > > > + all of the per-channel registers.
> > > > +- interrupt: Should contain the DMAC interrupt number.
> > > > +- interrupt-parent: Should be the phandle for the interrupt controller
> > > > + that services interrupts for this device.
> > > > +- dma-channels: Number of channels supported by hardware.
> > > > +- snps,dma-masters: Number of AXI masters supported by the hardware.
> > > > +- snps,data-width: Maximum AXI data width supported by hardware.
> > > > + (0 - 8bits, 1 - 16bits, 2 - 32bits, ..., 6 - 512bits)
> > > > +- snps,priority: Priority of channel. Array size is equal to the
> > > > number of
> > > > + dma-channels. Priority value must be programmed within
> > > > [0:dma-channels-1]
> > > > + range. (0 - minimum priority)
> > > > +- snps,block-size: Maximum block size supported by the controller
> > > > channel.
> > > > + Array size is equal to the number of dma-channels.
> > > > +
> > > > +Optional properties:
> > > > +- snps,axi-max-burst-len: Restrict master AXI burst length by value
> > > > specified
> > > > + in this property. If this property is missing the maximum AXI burst
> > > > length
> > > > + supported by DMAC is used. [1:256]
> > > > +
> > > > +Example:
> > > > +
> > > > +dmac: dma-controller@8 {
> > > > + compatible = "snps,axi-dma-1.01a";
> > >
> > > do we need "snps here..?
> >
> > Synopsys is this IP-block vendor so shouldn't we put it that way?
>
> Not a DT expert but why should vendor name come here, you can read the
> properties from device node, vendor name seems redundant to me
I don't follow...
In any case, yes, it must have a vendor prefix. It should also have a
compatible for the vendor(s) that integrate the block because they all
break it in different ways. Speaking of which, we already have
snps-dma.txt and at least Analog Devices binding using a Synopsys DMA.
What's the difference?
Rob
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH] arc: dts: Remove leading 0x and 0s from bindings notation
On Thu, Dec 14, 2017 at 10:53 AM, Mathieu Malaterre wrote:
> Improve the DTS files by removing all the leading "0x" and zeros to fix the
> following dtc warnings:
>
> Warning (unit_address_format): Node /XXX unit name should not have leading
> "0x"
>
> and
>
> Warning (unit_address_format): Node /XXX unit name should not have leading 0s
>
> Converted using the following command:
>
> find . -type f \( -iname *.dts -o -iname *.dtsi \) -exec sed -E -i -e
> "s/@0x([0-9a-fA-F\.]+)\s?\{/@\L\1 \{/g" -e "s/@0+([0-9a-fA-F\.]+)\s?\{/@\L\1
> \{/g" {} +
>
> For simplicity, two sed expressions were used to solve each warnings
> separately.
>
> To make the regex expression more robust a few other issues were resolved,
> namely setting unit-address to lower case, and adding a whitespace before the
> the opening curly brace:
>
> https://elinux.org/Device_Tree_Linux#Linux_conventions
>
> This is a follow up to commit 4c9847b7375a ("dt-bindings: Remove leading 0x
> from bindings notation")
>
> Reported-by: David Daney
> Suggested-by: Rob Herring
> Signed-off-by: Mathieu Malaterre
> ---
For the series,
Reviewed-by: Rob Herring
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: Setting CPU clock frequency on early boot
On Wed, Sep 6, 2017 at 11:22 AM, Alexey Brodkin
wrote:
> Hi Rob,
>
> On Wed, 2017-09-06 at 10:25 -0500, Rob Herring wrote:
>> On Wed, Sep 6, 2017 at 8:51 AM, Alexey Brodkin
>> wrote:
>> >
>> > Hi Vineet, Rob,
>> >
>> > On Tue, 2017-09-05 at 16:40 -0700, Vineet Gupta wrote:
>> > >
>> > > On 09/05/2017 03:04 PM, Rob Herring wrote:
>> > > >
>> > > >
>> > > > On Tue, Sep 5, 2017 at 10:37 AM, Alexey Brodkin
>> > > > wrote:
>
> [snip]
>
>> > Yeah, that's an interesting question. We may indeed move more smarts to
>> > the clock driver
>> > but:
>> > 1. We'll have duplicate code in different clock drivers. Even today that
>> > kind of clock
>> > setup is applicable to AXS10x and HSDK platforms (and they use
>> > different clock drivers).
>>
>> No, you could provide a common, shared function to call. Then each
>> platform can opt-in. If you can make something that applies to every
>> single platform now or in the future, then I'd put it in arch. If you
>> have plans to decouple the timer and cpu clocks, then sounds like you
>> can't.
>
> Right so we'll implement a function which is called by a platform if required.
> That way we escape copy-pasting while keeping enough flexibility for current
> and future platforms.
>
>> IMO, if it's not part of the defined CPU architecture, then don't put
>> it in arch/. That's how we end up with multiple copies of the same
>> thing done arbitrarily different ways because few people look across
>> architectures.
>
> So do you propose to have the function [that reads "clock-frequency" from say
> CPU node and passes its value to CPU's parent clock driver] in generic
> [i.e. architecture agnostic] code somewhere in "init/main.c"?
No, just like you said above and have the platform's clock driver
initialize frequencies.
I haven't seen anyone else want such a thing as generally the
bootloader should initialize things to something reasonable.
>> > 2. Print out of CPU frequency which is used during boot process for us is
>> > important as well
>> > especially during bring-up of new HW.
>> >
>> > 3. If there's no dedicated "clock-frequency" parameter in CPU node we
>> > won't
>> > change anything so that non-affected platforms will live as they used
>> > to.
>> >
>> > That said IMHO proposed implementation is what we want to kep for now.
>> >
>> > >
>> > > Also note that this code is using a new / adhoc DT binding cpu-freq in
>> > > cou node to
>> > > do the override - is that acceptable ?
>>
>> No, I meant to point that out.
>
> Sorry, but for me it's not clear what did you mean here.
> Care to elaborate a bit more?
I noticed the same thing and meant to highlight that in my first
reply. Use clock-frequency, don't invent something new.
>> > I think we'll switch to more common "clock-frequency" in the next respin.
>> > Indeed "cpu-freq" might be a bit misleading.
>>
>> Ideally, you'd use the clock binding eventually.
>
> Again I'm probably missing something :)
"clock-frequency" property and the clock bindings (i.e. clocks =
<&phandle>) are generally mutually exclusive at least within clock
consumer side. There's the assigned-clocks binding which provides the
ability to set both parent clocks and frequency.
> I meant we will have both clock phandle and "clock-frequency" at the same
> time.
> Something like this:
> >8---
> cpus {
> #address-cells = <1>;
> #size-cells = <0>;
>
> cpu@0 {
> device_type = "cpu";
> compatible = "snps,archs38";
> reg = <0>;
> clocks = <&core_clk>;
> clock-frequency = <1>; <-- That's where we
> want to set desired value
> };
> ...
> }
>
> core_clk: core-clk@80 {
> compatible = "snps,axs10x-arc-pll-clock";
> reg = <0x80 0x10>, <0x100 0x10>;
> #clock-cells = <0>;
> clocks = <&input_clk>;
> };
> >8---
>
> Or alternatively we may move "clock-frequency" right to the clock's node and
> have
> it like that:
> >8---
> core_clk: core-clk@80 {
> compatible = "snps,axs10x-arc-pll-clock";
> reg = <0x80 0x10>, <0x100 0x10>;
>
> #clock-cells = <0>;
> clocks = <&input_clk>;
> clock-frequency = <1>; <-- That's where we want to
> set desired value
I think this is how it should be done if you use clock-frequency prop.
This is inline with how fixed-clock binding is done.
Rob
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: Setting CPU clock frequency on early boot
On Wed, Sep 6, 2017 at 8:51 AM, Alexey Brodkin wrote: > Hi Vineet, Rob, > > On Tue, 2017-09-05 at 16:40 -0700, Vineet Gupta wrote: >> On 09/05/2017 03:04 PM, Rob Herring wrote: >> > >> > On Tue, Sep 5, 2017 at 10:37 AM, Alexey Brodkin >> > wrote: >> > > >> > > Hello, >> > > >> > > I'd like to get some feedback on our idea as well as check >> > > if somebody faces similar situations and if so what would be the best >> > > way to implement some generic solution that suits everyone. >> > > >> > > So that's our problem: >> > > 1. On power-on hardware might start clocking CPU with either >> > > too high frequency (such that CPU may get stuck at some point) >> > > or too low frequency. >> > > >> > > That all sounds stupid but let me elaborate a bit here. >> > > I'm talking about FPGA-based devboards firmware for which >> > > (here I mean just image loaded in FPGA with CPU implementation >> > > but not some software yet) might not be stable or be even >> > > experimental. >> > > >> > > For example we may deal with dual-core or quad-core designs. >> > > Former might be OK running @100MHz and latter is only usable >> > > @75MHz and lower. The simplest solution might be to use some safe >> > > value before something like CPUfreq kicks in. But we don't yet have >> > > CPUfreq for ARC (we do plan to get it working sometime soon) >> >> But even if we had cpufreq driver going - I don't think it would be usable >> for >> doing large freq switches, since in current implementations of SoCs (or >> fpga), the >> clk/pll etc driving core (and all timers etc) are not fixed like say ARM. >> And as >> discussed before (and pointed to by tglx), timer subsys can't tolerate (on >> purpose) such large drifts. > > Essentially cpufreq only makes sense for "compatible" systems and > unfortunately > most of our current boards are not capable due to missing constant [decoupled > from > CPU frequency] clock source. But looking forward we are planning to improve > on that > so that hopefully even our FPGA-based boards will be usable with cpufreq. > >> > > which >> > > means simple change of CPU frequency once time-keeping infrastructure >> > > was brought-up is not an option... I.e. we'll end up with the system >> > > running >> > > much slower compared what could have been possible. >> > > >> > > 2. Up until now we used to do dirty hacks in early platform init code. >> > > Namely (see axs103_early_init() in arch/arc/plat-axs10x/axs10x.c): >> > > 1) Read CPU's "clock-frequency" from .dtb (remember we're on very >> > > early >> > > boot stage still so no expanded DevTree yet exists). >> > > 2) Check how many cores we have and which freq is usable >> > > 3) Update PLL settings right in place if new freq != existing in >> > > PLL. >> > > >> > > Even though it is proven to work but with more platforms in the >> > > pipeline >> > > we'll need to copy-paste pretty much the same stuff across all >> > > affected >> > > plats. Which is not nice. >> > > >> > > Moreover back in the day we didn't have a proper clk driver for >> > > CPU's PLL. >> > > Thus acting on PLL registers right in place was the only thing we >> > > were able >> > > to do. Now with introduction of normal clk driver >> > > (see drivers/clk/axs10x/pll_clock.c in linux-next) we'd like to >> > > utilize >> > > it and have a cleaner and more universal solution to the problem. >> > > >> > > That's how it could be done - >> > > https://urldefense.proofpoint.com/v2/url?u=http-3A__patchwork.ozlabs.org_patch_801240_&d=DwICAg&c=DPL6_X_6JkXF >> > > x7AXWqB0tg&r=c14YS-cH- >> > > kdhTOW89KozFhBtBJgs1zXscZojEZQ0THs&m=wuUcceY8Cz5EhVklWLAgj7RzU3rvpanujvQ3qTJK0Gw&s=N5IBjq_eCyOf_GRkZskzqGhczBPTbxLJW_MUfauKvuA&e= >> > > Basically in architecture's time_init() we check if there's >> > > explicitly >> > > specified "clock-frequency" parameter in cpu's node in Device Tree >> > > an
Re: Setting CPU clock frequency on early boot
On Tue, Sep 5, 2017 at 10:37 AM, Alexey Brodkin wrote: > Hello, > > I'd like to get some feedback on our idea as well as check > if somebody faces similar situations and if so what would be the best > way to implement some generic solution that suits everyone. > > So that's our problem: > 1. On power-on hardware might start clocking CPU with either >too high frequency (such that CPU may get stuck at some point) >or too low frequency. > >That all sounds stupid but let me elaborate a bit here. >I'm talking about FPGA-based devboards firmware for which >(here I mean just image loaded in FPGA with CPU implementation >but not some software yet) might not be stable or be even experimental. > >For example we may deal with dual-core or quad-core designs. >Former might be OK running @100MHz and latter is only usable >@75MHz and lower. The simplest solution might be to use some safe >value before something like CPUfreq kicks in. But we don't yet have >CPUfreq for ARC (we do plan to get it working sometime soon) which >means simple change of CPU frequency once time-keeping infrastructure >was brought-up is not an option... I.e. we'll end up with the system > running >much slower compared what could have been possible. > > 2. Up until now we used to do dirty hacks in early platform init code. >Namely (see axs103_early_init() in arch/arc/plat-axs10x/axs10x.c): > 1) Read CPU's "clock-frequency" from .dtb (remember we're on very early >boot stage still so no expanded DevTree yet exists). > 2) Check how many cores we have and which freq is usable > 3) Update PLL settings right in place if new freq != existing in PLL. > >Even though it is proven to work but with more platforms in the pipeline >we'll need to copy-paste pretty much the same stuff across all affected >plats. Which is not nice. > >Moreover back in the day we didn't have a proper clk driver for CPU's PLL. >Thus acting on PLL registers right in place was the only thing we were able >to do. Now with introduction of normal clk driver >(see drivers/clk/axs10x/pll_clock.c in linux-next) we'd like to utilize >it and have a cleaner and more universal solution to the problem. > >That's how it could be done - http://patchwork.ozlabs.org/patch/801240/ >Basically in architecture's time_init() we check if there's explicitly >specified "clock-frequency" parameter in cpu's node in Device Tree and >if there's one we set it via just instantiated clk driver. The patch looks generally okay. I'd move all the logic to the clock driver unless perhaps how to set the cpu freq is defined by the architecture. > We may indeed proceed with mentioned solution for ARC but if that makes > sense for somebody else it might worth getting something similar in generic > init code. Any thoughts? If any ARM platforms are doing something similar, then it's done in their clock driver via of_clk_init. Or they just wait for cpufreq to kick in and expect the bootloader has initialized things to a reasonable frequency. Rob ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v2] OF: move extern declarations of of_stdout inside ifdef
On Fri, Aug 25, 2017 at 11:56 AM, Eugeniy Paltsev wrote: > Move extern declarations of "of_stdout" pointer inside "CONFIG_OF" > ifdef to be able to get rid of "CONFIG_OF" ifdef in its usage places. > > Suggested-by: Steven Rostedt > > Signed-off-by: Eugeniy Paltsev > --- > For example see: https://lkml.org/lkml/2017/8/25/337 > > Changes v1->v2: > * Move only "of_stdout" declarations instead of all entry pointers >declarations > > include/linux/of.h | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) Acked-by: Rob Herring Merge this with the console change needing it. Rob ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH] OF: move extern declarations of entry pointers inside ifdef
On Fri, Aug 25, 2017 at 10:00 AM, Eugeniy Paltsev
wrote:
> Move extern declarations of "of_root", "of_chosen", "of_aliases",
> "of_stdout" pointers inside "CONFIG_OF" ifdef to be able to get rid
> of "CONFIG_OF" ifdef in their usage places.
>
> Suggested-by: Steven Rostedt
>
> Signed-off-by: Eugeniy Paltsev
> ---
> For example see: https://lkml.org/lkml/2017/8/25/337
>
> include/linux/of.h | 15 ++-
> 1 file changed, 10 insertions(+), 5 deletions(-)
>
> diff --git a/include/linux/of.h b/include/linux/of.h
> index cfc3411..d117bf1 100644
> --- a/include/linux/of.h
> +++ b/include/linux/of.h
> @@ -131,11 +131,6 @@ static inline struct device_node *of_node_get(struct
> device_node *node)
> static inline void of_node_put(struct device_node *node) { }
> #endif /* !CONFIG_OF_DYNAMIC */
>
> -/* Pointer for first entry in chain of all nodes. */
> -extern struct device_node *of_root;
> -extern struct device_node *of_chosen;
> -extern struct device_node *of_aliases;
> -extern struct device_node *of_stdout;
Just move what you need. Some of these I'd like to see be internal to
the DT code.
Rob
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
