* [PATCH 2/3] ARM: imx: add cpu idle support for i.MX6SLL
From: kbuild test robot @ 2018-06-02 3:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527664358-17844-2-git-send-email-Anson.Huang@nxp.com>
Hi Anson,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on shawnguo/for-next]
[also build test ERROR on v4.17-rc7 next-20180601]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Anson-Huang/ARM-imx-add-L2-page-power-control-for-GPC/20180602-080503
base: https://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux.git for-next
config: arm-arm67 (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm
All errors (new ones prefixed by >>):
arch/arm/mach-imx/mach-imx6sl.o: In function `imx6sl_init_late':
>> mach-imx6sl.c:(.init.text+0x2c): undefined reference to `imx6sx_cpuidle_init'
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 31074 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180602/b9cf1083/attachment-0001.gz>
^ permalink raw reply
* [PATCH V5] scsi: hpsa: disable device during shutdown
From: Sinan Kaya @ 2018-06-02 4:28 UTC (permalink / raw)
To: linux-arm-kernel
'Commit cc27b735ad3a ("PCI/portdrv: Turn off PCIe services during
shutdown")' has been added to kernel to shutdown pending PCIe port
service interrupts during reboot so that a newly started kexec kernel
wouldn't observe pending interrupts.
pcie_port_device_remove() is disabling the root port and switches by
calling pci_disable_device() after all PCIe service drivers are shutdown.
This has been found to cause crashes on HP DL360 Gen9 machines during
reboot due to hpsa driver not clearing the bus master bit during the
shutdown procedure by calling pci_disable_device().
Disable device as part of the shutdown sequence.
Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
Link: https://bugzilla.kernel.org/show_bug.cgi?id=199779
Fixes: cc27b735ad3a ("PCI/portdrv: Turn off PCIe services during shutdown")
Cc: stable at vger.kernel.org
Reported-by: Ryan Finnie <ryan@finnie.org>
Tested-by: Don Brace <don.brace@microsemi.com>
Acked-by: Don Brace <don.brace@microsemi.com>
---
drivers/scsi/hpsa.c | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/scsi/hpsa.c b/drivers/scsi/hpsa.c
index 3a9eca1..b92f86a 100644
--- a/drivers/scsi/hpsa.c
+++ b/drivers/scsi/hpsa.c
@@ -8869,7 +8869,7 @@ static void hpsa_disable_rld_caching(struct ctlr_info *h)
kfree(options);
}
-static void hpsa_shutdown(struct pci_dev *pdev)
+static void __hpsa_shutdown(struct pci_dev *pdev)
{
struct ctlr_info *h;
@@ -8884,6 +8884,12 @@ static void hpsa_shutdown(struct pci_dev *pdev)
hpsa_disable_interrupt_mode(h); /* pci_init 2 */
}
+static void hpsa_shutdown(struct pci_dev *pdev)
+{
+ __hpsa_shutdown(pdev);
+ pci_disable_device(pdev);
+}
+
static void hpsa_free_device_info(struct ctlr_info *h)
{
int i;
@@ -8927,7 +8933,7 @@ static void hpsa_remove_one(struct pci_dev *pdev)
scsi_remove_host(h->scsi_host); /* init_one 8 */
/* includes hpsa_free_irqs - init_one 4 */
/* includes hpsa_disable_interrupt_mode - pci_init 2 */
- hpsa_shutdown(pdev);
+ __hpsa_shutdown(pdev);
hpsa_free_device_info(h); /* scan */
--
2.7.4
^ permalink raw reply related
* [PATCH] clkdev: Remove duplicated negative index check from __of_clk_get()
From: Stephen Boyd @ 2018-06-02 4:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMuHMdUNXQDdv-CQs+KpaHJ8gGFjFrPRNXF3HPZNyTdQr+23Og@mail.gmail.com>
Quoting Geert Uytterhoeven (2018-06-01 12:22:33)
> Hi Stephen,
>
> On Fri, Jun 1, 2018 at 9:20 PM, Stephen Boyd <sboyd@kernel.org> wrote:
> > Quoting Geert Uytterhoeven (2018-05-18 03:58:40)
> >> __of_clk_get() calls of_parse_phandle_with_args(), which rejects
> >> negative indices since commit bd69f73f2c81eed9 ("of: Create function for
> >> counting number of phandles in a property").
> >>
> >> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> >> ---
> >> Commit bd69f73f2c81eed9 is in v3.9.
> >
> > Did you send this to Russell's patch tracker? Otherwise I can pick it up
>
> Not yet. The patch tracker is for reviewed patches, AFAIK.
>
> > to clk-next.
>
> Thanks!
>
Ok. If you need my reviewed-by to add it to the tracker feel free to
have:
Reviewed-by: Stephen Boyd <sboyd@kernel.org>
^ permalink raw reply
* [PATCH v2 08/21] clk: bcm2835: use match_string() helper
From: Stephen Boyd @ 2018-06-02 6:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527765086-19873-9-git-send-email-xieyisheng1@huawei.com>
Quoting Yisheng Xie (2018-05-31 04:11:13)
> match_string() returns the index of an array for a matching string,
> which can be used instead of open coded variant.
>
> Reviewed-by: Eric Anholt <eric@anholt.net>
> Cc: Michael Turquette <mturquette@baylibre.com>
> Cc: Stephen Boyd <sboyd@kernel.org>
> Cc: Eric Anholt <eric@anholt.net>
> Cc: Stefan Wahren <stefan.wahren@i2se.com>
> Cc: linux-clk at vger.kernel.org
> Cc: linux-rpi-kernel at lists.infradead.org
> Cc: linux-arm-kernel at lists.infradead.org
> Signed-off-by: Yisheng Xie <xieyisheng1@huawei.com>
> ---
Applied to clk-next
^ permalink raw reply
* [PATCH 1/2] clk: imx6ul: add GPIO clock gates
From: Stephen Boyd @ 2018-06-02 6:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1439344955.9677.1526991935718@email.1und1.de>
Quoting Stefan Wahren (2018-05-22 05:25:35)
> > +++ b/include/dt-bindings/clock/imx6ul-clock.h
> > @@ -242,20 +242,25 @@
> > #define IMX6UL_CLK_CKO2_PODF 229
> > #define IMX6UL_CLK_CKO2 230
> > #define IMX6UL_CLK_CKO 231
> > +#define IMX6UL_CLK_GPIO1 232
> > +#define IMX6UL_CLK_GPIO2 233
> > +#define IMX6UL_CLK_GPIO3 234
> > +#define IMX6UL_CLK_GPIO4 235
> > +#define IMX6UL_CLK_GPIO5 236
>
> this change looks like a breakage of devicetree ABI. You are changing the mean of the existing clock IDs on i.MX6ULL, which probably regress the combination of older DTBs with newer kernel.
>
Agreed. Why can't we just tack on more numbers at the end?
> >
> > /* For i.MX6ULL */
> > -#define IMX6ULL_CLK_ESAI_PRED 232
^ permalink raw reply
* [PATCH v3 1/3] dt-bindings: clk: Update Stingray binding doc
From: Stephen Boyd @ 2018-06-02 6:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527900968-12017-2-git-send-email-ray.jui@broadcom.com>
Quoting Ray Jui (2018-06-01 17:56:06)
> From: Pramod Kumar <pramod.kumar@broadcom.com>
>
> Update Stingray clock binding document to add additional clock entries
> with names matching the latest ASIC datasheet. Also modify a few existing
> entries to make their naming more consistent with the rest of the entries
>
> Signed-off-by: Pramod Kumar <pramod.kumar@broadcom.com>
> Signed-off-by: Ray Jui <ray.jui@broadcom.com>
> ---
Applied to clk-next
^ permalink raw reply
* [PATCH v3 2/3] clk: bcm: Update and add Stingray clock entries
From: Stephen Boyd @ 2018-06-02 6:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527900968-12017-3-git-send-email-ray.jui@broadcom.com>
Quoting Ray Jui (2018-06-01 17:56:07)
> From: Pramod Kumar <pramod.kumar@broadcom.com>
>
> Update and add Stingray clock definitions and tables so they match the
> binding document and the latest ASIC datasheet
>
> Signed-off-by: Pramod Kumar <pramod.kumar@broadcom.com>
> Signed-off-by: Ray Jui <ray.jui@broadcom.com>
> ---
Applied to clk-next
^ permalink raw reply
* [PATCH v2 5/6] ARM: dts: Add generic interconnect target module node for MCAN
From: Stephen Boyd @ 2018-06-02 6:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180530141133.3711-6-faiz_abbas@ti.com>
Quoting Faiz Abbas (2018-05-30 07:11:32)
> diff --git a/arch/arm/boot/dts/dra76x.dtsi b/arch/arm/boot/dts/dra76x.dtsi
> index bfc82636999c..57b8dc0fe719 100644
> --- a/arch/arm/boot/dts/dra76x.dtsi
> +++ b/arch/arm/boot/dts/dra76x.dtsi
> @@ -11,6 +11,25 @@
> / {
> compatible = "ti,dra762", "ti,dra7";
>
> + ocp {
> +
> + target-module at 0x42c00000 {
Drop the 0x on unit address. Also, it should match the first register
property. And what is a "target-module"?
> + compatible = "ti,sysc-dra7-mcan";
> + ranges = <0x0 0x42c00000 0x2000>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> + reg = <0x42c01900 0x4>,
> + <0x42c01904 0x4>,
>
^ permalink raw reply
* [PATCH] clk: qcom: Export clk_fabia_pll_configure()
From: sboyd at kernel.org @ 2018-06-02 7:21 UTC (permalink / raw)
To: linux-arm-kernel
From: Stephen Boyd <sboyd@kernel.org>
This is used by the video clk driver on sdm845 and that's a module.
Export it to prevent module build failures.
Cc: Amit Nischal <anischal@codeaurora.org>
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
---
drivers/clk/qcom/clk-alpha-pll.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/clk/qcom/clk-alpha-pll.c b/drivers/clk/qcom/clk-alpha-pll.c
index 9722b701fbdb..3c49a60072f1 100644
--- a/drivers/clk/qcom/clk-alpha-pll.c
+++ b/drivers/clk/qcom/clk-alpha-pll.c
@@ -885,6 +885,7 @@ void clk_fabia_pll_configure(struct clk_alpha_pll *pll, struct regmap *regmap,
regmap_update_bits(regmap, PLL_MODE(pll), PLL_RESET_N, PLL_RESET_N);
}
+EXPORT_SYMBOL_GPL(clk_fabia_pll_configure);
static int alpha_pll_fabia_enable(struct clk_hw *hw)
{
--
Sent by a computer through tubes
^ permalink raw reply related
* [PATCH] kbuild: add machine size to CHEKCFLAGS
From: Masahiro Yamada @ 2018-06-02 7:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180530204838.22079-1-luc.vanoostenryck@gmail.com>
2018-05-31 5:48 GMT+09:00 Luc Van Oostenryck <luc.vanoostenryck@gmail.com>:
> By default, sparse assumes a 64bit machine when compiled on x86-64
> and 32bit when compiled on anything else.
>
> This can of course create all sort of problems for the other archs, like
> issuing false warnings ('shift too big (32) for type unsigned long'), or
> worse, failing to emit legitimate warnings.
>
> Fix this by adding the -m32/-m64 flag, depending on CONFIG_64BIT,
> to CHECKFLAGS in the main Makefile (and so for all archs).
> Also, remove the now unneeded -m32/-m64 in arch specific Makefiles.
>
> Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
> ---
Fixed CHEKCFLAGS -> CHECKFLAGS
and applied to linux-kbuild. Thanks!
> Makefile | 3 +++
> arch/alpha/Makefile | 2 +-
> arch/arm/Makefile | 2 +-
> arch/arm64/Makefile | 2 +-
> arch/ia64/Makefile | 2 +-
> arch/mips/Makefile | 3 ---
> arch/parisc/Makefile | 2 +-
> arch/sparc/Makefile | 2 +-
> arch/x86/Makefile | 2 +-
> 9 files changed, 10 insertions(+), 10 deletions(-)
>
> diff --git a/Makefile b/Makefile
> index 6c6610913..18379987c 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -881,6 +881,9 @@ endif
> # insure the checker run with the right endianness
> CHECKFLAGS += $(if $(CONFIG_CPU_BIG_ENDIAN),-mbig-endian,-mlittle-endian)
>
> +# the checker needs the correct machine size
> +CHECKFLAGS += $(if $(CONFIG_64BIT),-m64,-m32)
> +
> # Default kernel image to build when no specific target is given.
> # KBUILD_IMAGE may be overruled on the command line or
> # set in the environment
> diff --git a/arch/alpha/Makefile b/arch/alpha/Makefile
> index 2cc3cc519..c5ec8c09c 100644
> --- a/arch/alpha/Makefile
> +++ b/arch/alpha/Makefile
> @@ -11,7 +11,7 @@
> NM := $(NM) -B
>
> LDFLAGS_vmlinux := -static -N #-relax
> -CHECKFLAGS += -D__alpha__ -m64
> +CHECKFLAGS += -D__alpha__
> cflags-y := -pipe -mno-fp-regs -ffixed-8
> cflags-y += $(call cc-option, -fno-jump-tables)
>
> diff --git a/arch/arm/Makefile b/arch/arm/Makefile
> index e4e537f27..f32a5468d 100644
> --- a/arch/arm/Makefile
> +++ b/arch/arm/Makefile
> @@ -135,7 +135,7 @@ endif
> KBUILD_CFLAGS +=$(CFLAGS_ABI) $(CFLAGS_ISA) $(arch-y) $(tune-y) $(call cc-option,-mshort-load-bytes,$(call cc-option,-malignment-traps,)) -msoft-float -Uarm
> KBUILD_AFLAGS +=$(CFLAGS_ABI) $(AFLAGS_ISA) $(arch-y) $(tune-y) -include asm/unified.h -msoft-float
>
> -CHECKFLAGS += -D__arm__ -m32
> +CHECKFLAGS += -D__arm__
>
> #Default value
> head-y := arch/arm/kernel/head$(MMUEXT).o
> diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile
> index 87f7d2f9f..3c353b471 100644
> --- a/arch/arm64/Makefile
> +++ b/arch/arm64/Makefile
> @@ -78,7 +78,7 @@ LDFLAGS += -maarch64linux
> UTS_MACHINE := aarch64
> endif
>
> -CHECKFLAGS += -D__aarch64__ -m64
> +CHECKFLAGS += -D__aarch64__
>
> ifeq ($(CONFIG_ARM64_MODULE_PLTS),y)
> KBUILD_LDFLAGS_MODULE += -T $(srctree)/arch/arm64/kernel/module.lds
> diff --git a/arch/ia64/Makefile b/arch/ia64/Makefile
> index 2dd7f519a..45f59808b 100644
> --- a/arch/ia64/Makefile
> +++ b/arch/ia64/Makefile
> @@ -18,7 +18,7 @@ READELF := $(CROSS_COMPILE)readelf
>
> export AWK
>
> -CHECKFLAGS += -m64 -D__ia64=1 -D__ia64__=1 -D_LP64 -D__LP64__
> +CHECKFLAGS += -D__ia64=1 -D__ia64__=1 -D_LP64 -D__LP64__
>
> OBJCOPYFLAGS := --strip-all
> LDFLAGS_vmlinux := -static
> diff --git a/arch/mips/Makefile b/arch/mips/Makefile
> index 5e9fce076..e2122cca4 100644
> --- a/arch/mips/Makefile
> +++ b/arch/mips/Makefile
> @@ -309,9 +309,6 @@ ifdef CONFIG_MIPS
> CHECKFLAGS += $(shell $(CC) $(KBUILD_CFLAGS) -dM -E -x c /dev/null | \
> egrep -vw '__GNUC_(|MINOR_|PATCHLEVEL_)_' | \
> sed -e "s/^\#define /-D'/" -e "s/ /'='/" -e "s/$$/'/" -e 's/\$$/&&/g')
> -ifdef CONFIG_64BIT
> -CHECKFLAGS += -m64
> -endif
> endif
>
> OBJCOPYFLAGS += --remove-section=.reginfo
> diff --git a/arch/parisc/Makefile b/arch/parisc/Makefile
> index 348ae4779..714284ea6 100644
> --- a/arch/parisc/Makefile
> +++ b/arch/parisc/Makefile
> @@ -28,7 +28,7 @@ export LIBGCC
>
> ifdef CONFIG_64BIT
> UTS_MACHINE := parisc64
> -CHECKFLAGS += -D__LP64__=1 -m64
> +CHECKFLAGS += -D__LP64__=1
> CC_ARCHES = hppa64
> LD_BFD := elf64-hppa-linux
> else # 32-bit
> diff --git a/arch/sparc/Makefile b/arch/sparc/Makefile
> index edac927e4..966a13d2b 100644
> --- a/arch/sparc/Makefile
> +++ b/arch/sparc/Makefile
> @@ -39,7 +39,7 @@ else
> # sparc64
> #
>
> -CHECKFLAGS += -D__sparc__ -D__sparc_v9__ -D__arch64__ -m64
> +CHECKFLAGS += -D__sparc__ -D__sparc_v9__ -D__arch64__
> LDFLAGS := -m elf64_sparc
> export BITS := 64
> UTS_MACHINE := sparc64
> diff --git a/arch/x86/Makefile b/arch/x86/Makefile
> index 60135cbd9..f0a6ea224 100644
> --- a/arch/x86/Makefile
> +++ b/arch/x86/Makefile
> @@ -94,7 +94,7 @@ ifeq ($(CONFIG_X86_32),y)
> else
> BITS := 64
> UTS_MACHINE := x86_64
> - CHECKFLAGS += -D__x86_64__ -m64
> + CHECKFLAGS += -D__x86_64__
>
> biarch := -m64
> KBUILD_AFLAGS += -m64
> --
> 2.17.0
>
--
Best Regards
Masahiro Yamada
^ permalink raw reply
* [PATCH 1/8] media: uniphier: add DT bindings documentation for UniPhier HSC
From: Masahiro Yamada @ 2018-06-02 8:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180530090946.1635-2-suzuki.katsuhiro@socionext.com>
2018-05-30 18:09 GMT+09:00 Katsuhiro Suzuki <suzuki.katsuhiro@socionext.com>:
> This patch adds DT binding documentation for UniPhier HSC which is
> MPEG2-TS input/output and demux subsystem.
>
> Signed-off-by: Katsuhiro Suzuki <suzuki.katsuhiro@socionext.com>
> ---
> .../bindings/media/uniphier,hsc.txt | 38 +++++++++++++++++++
> 1 file changed, 38 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/media/uniphier,hsc.txt
>
> diff --git a/Documentation/devicetree/bindings/media/uniphier,hsc.txt b/Documentation/devicetree/bindings/media/uniphier,hsc.txt
This file name is strange.
A comma should be used a separator between a vendor name and a device name.
The "uniphier" is not a vendor name.
socionext,uniphier-hsc.txt
or
uniphier-hsc.txt
> new file mode 100644
> index 000000000000..4242483b2ecc
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/uniphier,hsc.txt
> @@ -0,0 +1,38 @@
> +Socionext UniPhier HSC (High-speed Stream Controller)
> +
> +The Socionext UniPhier HSC subsystem consists of MPEG2-TS input/output and
> +demultiplexer cores in the same register space.
> +
> +This interface is support TS serial signals (clock, valid, sync, data) from
"is support" -> "supports"
> +external demodulators.
> +
> +Required properties:
> +- compatible : should be one of the following:
> + "socionext,uniphier-ld11-hsc"
> + "socionext,uniphier-ld20-hsc"
> +- reg : offset and length of the register set for the device.
> +- interrupts : should contain DMA and TSI error interrupt.
> +- pinctrl-names : should be "default".
> +- pinctrl-0 : defined TS serial signal pins for external demodulators.
> +- clock-names : should include following entries:
> + "hsc", "stdmac"
> +- clocks : a list of phandle, should contain an entry for each
> + entry in clock-names.
> +- reset-names : should include following entries:
> + "hsc", "stdmac"
> +- resets : a list of phandle, should contain an entry for each
> + entry in reset-names.
> +
> +Example:
> + hsc {
> + compatible = "socionext,uniphier-ld20-hsc";
> + reg = <0x5c000000 0x100000>;
> + interrupts = <0 100 4>, <0 101 4>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_hscin2_s>,
> + <&pinctrl_hscin3_s>;
> + clock-names = "stdmac", "hsc";
> + clocks = <&sys_clk 8>, <&sys_clk 9>;
> + reset-names = "stdmac", "hsc";
> + resets = <&sys_rst 8>, <&sys_rst 9>;
> + };
> --
> 2.17.0
>
--
Best Regards
Masahiro Yamada
^ permalink raw reply
* [PATCH 1/6] arm64: dts: amlogic: Add missing cooling device properties for CPUs
From: Olof Johansson @ 2018-06-02 8:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180528111358.meyle364fy6wuruf@vireshk-i7>
On Mon, May 28, 2018 at 04:43:58PM +0530, Viresh Kumar wrote:
> On 25-05-18, 14:10, Olof Johansson wrote:
> > On Fri, May 25, 2018 at 11:10:01AM +0530, Viresh Kumar wrote:
> > > The cooling device properties, like "#cooling-cells" and
> > > "dynamic-power-coefficient", should either be present for all the CPUs
> > > of a cluster or none. If these are present only for a subset of CPUs of
> > > a cluster then things will start falling apart as soon as the CPUs are
> > > brought online in a different order. For example, this will happen
> > > because the operating system looks for such properties in the CPU node
> > > it is trying to bring up, so that it can register a cooling device.
> > >
> > > Add such missing properties.
> >
> > This seems awkward compared to just having one cooling-cells in the /cpus node
> > instead.
>
> Well, we don't allow that property to be present in /cpus node right
> now and it is per device. And then we may not want all the CPUs to be
> cooling devices really.
And what I am saying is that it sounds like a broken binding if you don't allow
that, especially since it'll be a super common case that all CPUs will specify
the same cooling-device specifier.
> > What's it used for? I don't see any properties in the device nodes on meson-gxm
> > that have any cooling-foo cells in them? So why should #cooling-cells be
> > needed?
>
> This property is required to declare a device as a cooling-device and
> the device here is CPU. We use it as a cooling device by limiting its
> higher range of frequencies, so that it doesn't generate too much
> heat.
>
> It is already there for CPU0 and CPU4, but it should really be there
> for all the CPUs, like we have clock, supply, caches, etc.
You have #cooling-cells in the cpu node, but the actual data is in the
thermal-zones nodes. Why isn't #cooling-cells under thermal-zones, next to
cooling-maps?
-Olof
^ permalink raw reply
* [GIT PULL] i.MX maintainers update for 4.18
From: Olof Johansson @ 2018-06-02 8:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180528081549.GD3143@dragon>
On Mon, May 28, 2018 at 04:15:50PM +0800, Shawn Guo wrote:
> Hi Arnd, Olof,
>
> I'm not sure which one is easier for you. You can pull the request or
> apply the patch to some arm-soc branch directly.
>
> Shawn
>
>
> The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:
>
> Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux.git tags/imx-maintainers-4.18
>
> for you to fetch changes up to c309f0cdc30667efd233f1220587fb0b18c8423b:
>
> MAINTAINERS: add NXP linux team maillist as i.MX reviewer (2018-05-28 15:55:07 +0800)
Merged, thanks!
-Olof
^ permalink raw reply
* [PATCH] ARM: dts: aspeed: Fix hwrng register address
From: Olof Johansson @ 2018-06-02 8:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180530061740.31547-1-joel@jms.id.au>
On Wed, May 30, 2018 at 03:47:40PM +0930, Joel Stanley wrote:
> The register address should be the full address of the rng, not the
> offset from the start of the SCU.
>
> Fixes: 5daa8212c08e ("ARM: dts: aspeed: Describe random number device")
> Reviewed-by: Andrew Jeffery <andrew@aj.id.au>
> Signed-off-by: Joel Stanley <joel@jms.id.au>
> ---
> Hi ARM maintainers, this was found when testing next-20180529 after the
> merge of the aspeed 4.18 pull request. Can you please apply this one to
> your -next tree?
Certainly, applied to our next/dt branch now.
Thanks,
-Olof
^ permalink raw reply
* [GIT PULL] pxa for v4.18
From: Olof Johansson @ 2018-06-02 8:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87d0xftunu.fsf@belgarion.home>
On Mon, May 28, 2018 at 10:03:17PM +0200, Robert Jarzmik wrote:
> Hi Arnd, Kevin, and Olof,
>
> This is the pxa pull request for 4.18, a minor one.
>
> Can you please consider pulling ?
>
> The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:
>
> Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)
>
> are available in the git repository at:
>
> https://github.com/rjarzmik/linux.git tags/pxa-for-4.18
>
> for you to fetch changes up to c1c14f8954c6d1cb9867024618e93687d9d035ba:
>
> ARM: pxa3xx: enable external wakeup pins (2018-05-25 22:40:17 +0200)
>
> ----------------------------------------------------------------
> This is is the pxa changes for v4.18 cycle :
> - change to phase out at24 eeprom platform data
> - add a missing wakeup pin on pxa320 SoCs
Hi,
This is coming in very late, but it's also a pretty small pull request so I've
merged it for v4.18. If you can, please try to get your staged patches set
around rc5/rc6 timeframe.
Thanks,
-Olof
^ permalink raw reply
* [GIT PULL] pxa-dt for v4.18
From: Olof Johansson @ 2018-06-02 8:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <878t83tujv.fsf@belgarion.home>
On Mon, May 28, 2018 at 10:05:40PM +0200, Robert Jarzmik wrote:
> Hi Arnd, Kevin, and Olof,
>
> This is the pxa pull request for 4.18 device-tree, with a couple fixes from
> Daniel for pxa3xx.
>
> The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:
>
> Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)
>
> are available in the git repository at:
>
> https://github.com/rjarzmik/linux.git tags/pxa-dt-4.18
>
> for you to fetch changes up to 07c8d21d08a589bc01238fe09a6edb54d24f3da0:
>
> ARM: dts: pxa3xx: fix MMC clocks (2018-05-25 23:16:18 +0200)
>
> ----------------------------------------------------------------
> This device-tree pxa update brings :
> - fix pxa3xx MMC bindings
> - add pxa3xx GPIOs
> - add pxa3xx missing pin controller
Same comment as for the other pull request but merged now. Thanks!
-Olof
^ permalink raw reply
* [GIT PULL] ARM: mvebu: fixes for v4.17 (#2)
From: Olof Johansson @ 2018-06-02 8:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <871sdvyfxj.fsf@bootlin.com>
On Mon, May 28, 2018 at 05:10:16PM +0200, Gregory CLEMENT wrote:
> Hi,
>
> Here is the second pull request for fixes for mvebu for v4.17.
> Nothing really critical but it needs to be fixed.
>
> Gregory
>
> The following changes since commit f43194c1447c9536efb0859c2f3f46f6bf2b9154:
>
> ARM64: dts: marvell: armada-cp110: Add mg_core_clk for ethernet node (2018-04-27 17:47:24 +0200)
>
> are available in the Git repository at:
>
> git://git.infradead.org/linux-mvebu.git tags/mvebu-fixes-4.17-2
>
> for you to fetch changes up to ac62cc9d9cd6fa4c79e171c13dc8d58c3862b678:
>
> arm: dts: armada: Fix "#cooling-cells" property's name (2018-05-28 16:54:44 +0200)
>
> ----------------------------------------------------------------
> mvebu fixes for 4.17 (part 2)
>
> - Use correct size for ICU nodes (irq controller) on Armada 7K/8K
> - Fix "#cooling-cells" property's name on Synology DS116 (Armada 385)
>
> ----------------------------------------------------------------
> Miquel Raynal (1):
> arm64: dts: marvell: fix CP110 ICU node size
>
> Viresh Kumar (1):
> arm: dts: armada: Fix "#cooling-cells" property's name
Subject here should be 'ARM: dts: ...'
The latter is definitely not 4.17 material by now. It's unclear on the ICU
patch whether it's causing a real problem in reality, i.e. if it's an urgent
regression fix or if it's just fixing up the register range to be correct per
documentation. Let me know if it's a real issue and I can either cherry-pick
it or send a separate pull request with just that fix.
-Olof
^ permalink raw reply
* [GIT PULL] Renesas ARM64 Based SoC DT Updates for v4.18
From: Olof Johansson @ 2018-06-02 8:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180528074436.rctyzocv4qfmdfzy@verge.net.au>
On Mon, May 28, 2018 at 09:44:41AM +0200, Simon Horman wrote:
> Hi Olof,
>
> On Sat, May 26, 2018 at 02:14:20PM -0700, Olof Johansson wrote:
> > Hi Simon,
> >
> > On Fri, May 18, 2018 at 01:16:00PM +0200, Simon Horman wrote:
> > > Hi Olof, Hi Kevin, Hi Arnd,
> > >
> > > Please consider these Renesas ARM64 based SoC DT updates for v4.18.
> > >
> > >
> > > The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:
> > >
> > > Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)
> > >
> > > are available in the git repository at:
> > >
> > > https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git tags/renesas-arm64-dt-for-v4.18
> > >
> > > for you to fetch changes up to 908001d778eba06ee1d832863d4e9a1e2cfd4746:
> > >
> > > arm64: dts: renesas: salvator-common: Add ADV7482 support (2018-05-18 11:52:03 +0200)
> >
> > This pull request is really, really hard for us to digest. The tag
> > description is very large, and it repeats several SoCs several times,
> > making it hard to get an overview of what is in it. The verbosity of "<x>
> > says.." makes it harder on this size of a pull request as well.
>
> I appologise that this pull-request has turned out to be hard to digest.
>
> I think that one reason for this is that there are an unusally large number
> of commits. It seems that the team has been a little more productive than
> usual and I might have been better to send a smaller pull-request earlier
> in the development cycle and then follow-up with a second batch. I'll try
> to pay more attention to this aspect of things going forwards.
>
> Regarding your specific comments:
>
> * Repetition of SoCs. I do try to group things in a logical manner,
> but clearly I failed in this case. I'll try to make that a bit clearer
> in future.
I don't think you're helped by the fact that Renesas product names seem
to have little rhyme or reason to them, and mumbles families and product
names and numbers seemingly random. :(
> * Verbosity: There as a request a few development cycles for me
> to include more information in the commit logs. It seems that
> I may have gone a bit too far. I'll try to find a better balance next
> time around.
There's a balance to be found here. You chose to describe some very small
changes with 3 lines of description, and as a result it's hard to get an
overview of what's in the pull request.
As a maintainer, you should strive to be the editor that makes sure that things
are easy to understand, and arranged in a manner that makes sense for both your
developers and the rest of the community (and the upstream maintainers).
> * Patches for the same change split up for different SoCs/boards.
> Featurs broken out into incremental patches. And so on.
>
> This has been a long-standing practice for Renesas SoC development.
> We find that in general it aids review. It also works well
> with the way we develop patches. But I do see your point that
> it may be a little excessive - f.e. multiple patches for the same
> whitespace fixes. Again, we'll try to find a better balance.
I can understand where the policy comes from, but it seems to me that at least
in this case it's one that's no longer scaling to the number of SoCs you're
supporting, and the number of (each small) additions that you're doing.
Grouping in some of the simpler dtsi additions into one per SoC, or one per IP
block across all SoCs, seems like something to attempt here.
> > For example:
> >
> > > * Condor board with R-Car V3H (r8a77980) SoC
> > > - Enable eMMC
> > >
> > > Sergei Shtylyov says "We're adding the R8A77980 MMC (SDHI)
> > > device nodes and then enable eMMC support on the Condor board."
> >
> > The "Enable eMMC" line is just fine here.
> >
> > > ----------------------------------------------------------------
> > > Geert Uytterhoeven (11):
> > > arm64: dts: renesas: draak: Rename EtherAVB "mdc" pin group to "mdio"
> > > arm64: dts: renesas: salvator-common: Rename EtherAVB "mdc" pin group to "mdio"
> > > arm64: dts: renesas: ulcb: Rename EtherAVB "mdc" pin group to "mdio"
> >
> > Why can't these be done in one commit?
> >
> > > arm64: dts: renesas: r8a7795: Correct whitespace
> > > arm64: dts: renesas: r8a7796: Correct whitespace
> > > arm64: dts: renesas: r8a77965: Correct whitespace
> >
> > Do these really need to be three commits to fix some whitespace?
> >
> > > arm64: dts: renesas: ulcb: Add BD9571 PMIC
> > > arm64: dts: renesas: salvator-common: Add PMIC DDR Backup Power config
> > > arm64: dts: renesas: ulcb: Add PMIC DDR Backup Power config
> > > arm64: dts: renesas: r8a77970: Add secondary CA53 CPU core
> > > arm64: dts: renesas: r8a77970: Add Cortex-A53 PMU node
> >
> > Why can't these be done in the same commit?
> >
> > > Kieran Bingham (7):
> > > arm64: dts: renesas: r8a77965: Add FCPF and FCPV instances
> > > arm64: dts: renesas: r8a77965: Add VSP instances
> > > arm64: dts: renesas: r8a77965: Populate the DU instance placeholder
> > > arm64: dts: renesas: r8a77965: Add HDMI encoder instance
> > > arm64: dts: renesas: r8a77965-salvator-x: Enable DU external clocks and HDMI
> > > arm64: dts: renesas: r8a77965-salvator-xs: Enable DU external clocks and HDMI
> >
> > These two can probably be in one commit as well.
> >
> > > arm64: dts: renesas: salvator-common: Add ADV7482 support
> > >
> > > Kuninori Morimoto (8):
> > > arm64: dts: renesas: r8a7795: add HDMI sound support
> > > arm64: dts: renesas: r8a7796: add HDMI sound support
> >
> > ... starting to see a trend?
> >
> > > arm64: dts: renesas: salvator-common: use audio-graph-card for Sound
> > > arm64: dts: renesas: r8a7795-es1-salvator-x: enable HDMI sound
> > > arm64: dts: renesas: r8a7795-salvator-xs: enable HDMI sound
> > > arm64: dts: renesas: r8a7796-salvator-xs: enable HDMI sound
> > > arm64: dts: renesas: r8a7795-salvator-x: enable HDMI sound
> > > arm64: dts: renesas: r8a7796-salvator-x: enable HDMI sound
> >
> > ... and more.
> >
> > >
> > > Magnus Damm (5):
> > > arm64: dts: renesas: r8a77970: Update IPMMU DS1 bit number
> > > arm64: dts: renesas: r8a7795: Enable IPMMU devices
> > > arm64: dts: renesas: r8a7796: Enable IPMMU devices
> > > arm64: dts: renesas: r8a77970: Enable IPMMU devices
> > > arm64: dts: renesas: r8a77995: Enable IPMMU devices
> >
> > I think these 4 could be in one commit too.
> >
> > >
> > > Niklas S?derlund (11):
> > > arm64: dts: renesas: r8a7795: decrease temperature hysteresis
> > > arm64: dts: renesas: r8a7796: decrease temperature hysteresis
> > > arm64: dts: renesas: r8a77965: use r8a77965-sysc binding definitions
> > > arm64: dts: renesas: r8a77965: Add R-Car Gen3 thermal support
> > > arm64: dts: renesas: r8a77965: add I2C support
> > > arm64: dts: renesas: r8a7795: add VIN and CSI-2 nodes
> > > arm64: dts: renesas: r8a7795-es1: add CSI-2 node
> > > arm64: dts: renesas: r8a7796: add VIN and CSI-2 nodes
> > > arm64: dts: renesas: r8a77965: add VIN and CSI-2 nodes
> > > arm64: dts: renesas: r8a77970: add VIN and CSI-2 nodes
> >
> >
> > .... etc, etc. I'll stop here.
> >
> >
> > I haven't merged this branch yet, will need to set aside more time to review
> > the contents. I can't guarantee that it'll make v4.18 but I'll try.
>
> Please let me know if there is anything I can do to help make this happen.
> This work is very important to Renesas.
I've queued this and the SoC branch up in a next/late branch now. I'm planning
on sending it in unless it's a messy or hard merge window for some reason.
-Olof
^ permalink raw reply
* [GIT PULL] Renesas ARM Based SoC DT Updates for v4.18
From: Olof Johansson @ 2018-06-02 8:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1526641667.git.horms+renesas@verge.net.au>
On Fri, May 18, 2018 at 01:17:37PM +0200, Simon Horman wrote:
> Hi Olof, Hi Kevin, Hi Arnd,
>
> Please consider these Renesas ARM based SoC DT updates for v4.18.
>
>
> The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:
>
> Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)
>
> are available in the git repository at:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git tags/renesas-dt-for-v4.18
>
> for you to fetch changes up to 7fad92d05887319998b8d2bb40082b8b224d5ef5:
>
> ARM: dts: r8a7740: Add CEU1 (2018-05-16 10:54:50 +0200)
Per the other subthread, I have queued this up in next/late now. Thanks.
-Olof
^ permalink raw reply
* [PATCH v3 2/5] gpio: syscon: rockchip: add GPIO_MUTE support for rk3328
From: Levin Du @ 2018-06-02 8:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAL_JsqKSy4q5dfVfXbRMLa7koTWufpAt3yNdE-9mwyJ-VzVQRQ@mail.gmail.com>
Rob Herring <robh+dt@kernel.org> writes:
> On Thu, May 31, 2018 at 9:05 PM, Levin <djw@t-chip.com.cn>
> wrote:
>> Hi Rob,
>>
>>
>> On 2018-05-31 10:45 PM, Rob Herring wrote:
>>>
>>> On Wed, May 30, 2018 at 10:27 PM, <djw@t-chip.com.cn> wrote:
>>>>
>>>> From: Levin Du <djw@t-chip.com.cn>
>>>>
>>>> In Rockchip RK3328, the output only GPIO_MUTE pin, originally
>>>> for codec
>>>> mute control, can also be used for general purpose. It is
>>>> manipulated by
>>>> the GRF_SOC_CON10 register.
>>>>
>>>> Signed-off-by: Levin Du <djw@t-chip.com.cn>
>>>>
>>>> ---
>>>>
>>>> Changes in v3:
>>>> - Change from general gpio-syscon to specific
>>>> rk3328-gpio-mute
>>>>
>>>> Changes in v2:
>>>> - Rename gpio_syscon10 to gpio_mute in doc
>>>>
>>>> Changes in v1:
>>>> - Refactured for general gpio-syscon usage for Rockchip SoCs.
>>>> - Add doc rockchip,gpio-syscon.txt
>>>>
>>>> .../bindings/gpio/rockchip,rk3328-gpio-mute.txt | 28
>>>> +++++++++++++++++++
>>>> drivers/gpio/gpio-syscon.c | 31
>>>> ++++++++++++++++++++++
>>>> 2 files changed, 59 insertions(+)
>>>> create mode 100644
>>>> Documentation/devicetree/bindings/gpio/rockchip,rk3328-gpio-mute.txt
>>>>
>>>> diff --git
>>>> a/Documentation/devicetree/bindings/gpio/rockchip,rk3328-gpio-mute.txt
>>>> b/Documentation/devicetree/bindings/gpio/rockchip,rk3328-gpio-mute.txt
>>>> new file mode 100644
>>>> index 0000000..10bc632
>>>> --- /dev/null
>>>> +++
>>>> b/Documentation/devicetree/bindings/gpio/rockchip,rk3328-gpio-mute.txt
>>>> @@ -0,0 +1,28 @@
>>>> +Rockchip RK3328 GPIO controller dedicated for the GPIO_MUTE
>>>> pin.
>>>> +
>>>> +In Rockchip RK3328, the output only GPIO_MUTE pin,
>>>> originally for codec
>>>> mute
>>>> +control, can also be used for general purpose. It is
>>>> manipulated by the
>>>> +GRF_SOC_CON10 register.
>>>> +
>>>> +Required properties:
>>>> +- compatible: Should contain "rockchip,rk3328-gpio-mute".
>>>> +- gpio-controller: Marks the device node as a gpio
>>>> controller.
>>>> +- #gpio-cells: Should be 2. The first cell is the pin number
>>>> and
>>>> + the second cell is used to specify the gpio polarity:
>>>> + 0 = Active high,
>>>> + 1 = Active low.
>>>> +
>>>> +Example:
>>>> +
>>>> + grf: syscon at ff100000 {
>>>> + compatible = "rockchip,rk3328-grf", "syscon",
>>>> "simple-mfd";
>>>> +
>>>> + gpio_mute: gpio-mute {
>>>
>>> Node names should be generic:
>>>
>>> gpio {
>>>
>>> This also means you can't add another GPIO node in the future
>>> and
>>> you'll have to live with "rockchip,rk3328-gpio-mute" covering
>>> more
>>> than 1 GPIO if you do need to add more GPIOs.
>>
>>
>> As the first line describes, this GPIO controller is dedicated
>> for the
>> GPIO_MUTE pin.
>> There's only one GPIO pin in the GRF_SOC_CON10 register.
>> Therefore the
>> gpio_mute
>> name is proper IMHO.
>
> It's how many GPIOs in the GRF, not this register. What I'm
> saying is
> when you come along later to add another GPIO in the GRF, you
> had
> better just add it to this same node. I'm not going to accept
> another
> GPIO controller node within the GRF. You have the cells to
> support
> more than 1, so it would only be a driver change. The compatible
> string would then not be ideally named at that point. But
> compatible
> strings are just unique identifiers, so it doesn't really matter
> what
> the string is.
>
I'll try my best to introduce the situation here. The GRF,
GPIO0~GPIO3
are register blocks in the RK3328 Soc. The GPIO0~GPIO3 contain
registers
for GPIO operations like reading/writing data, setting direction,
interruption etc, which corresponds to the GPIO banks
(gpio0~gpio3)
defined in rk3328.dtsi:
pinctrl: pinctrl {
compatible = "rockchip,rk3328-pinctrl";
rockchip,grf = <&grf>;
#address-cells = <2>;
#size-cells = <2>;
ranges;
gpio0: gpio0 at ff210000 {
compatible = "rockchip,gpio-bank";
reg = <0x0 0xff210000 0x0 0x100>;
interrupts = <GIC_SPI 51
IRQ_TYPE_LEVEL_HIGH>;
clocks = <&cru PCLK_GPIO0>;
gpio-controller;
#gpio-cells = <2>;
interrupt-controller;
#interrupt-cells = <2>;
};
gpio1: gpio1 at ff220000 {
//...
};
gpio2: gpio2 at ff230000 {
//...
};
gpio3: gpio3 at ff240000 {
//...
};
}
However, these general GPIO pins has multiplexed functions and
their
pull up/down and driving strength can also be configured. These
settings
are manipulated by the GRF registers in pinctrl driver. Quoted
from the
TRM, the GRF has the following function:
- IOMUX control
- Control the state of GPIO in power-down mode
- GPIO PAD pull down and pull up control
- Used for common system control
- Used to record the system state
Therefore the functions of the GRF are messy and scattered in
different
nodes. The so-called GPIO_MUTE does not belong to GPIO0~GPIO3. It
is
manipulated by the GRF_SOC_CON10 register in the GRF block.
> I'm being told both "this is the only GPIO" and "the GRF has too
> many
> different functions for us to tell you what they all are". So
> which is
> it?
>
> Rob
They are both true, but lack of context. See the above
description.
Thanks,
Levin
^ permalink raw reply
* [clk:clk-bcm-stingray 1/2] drivers/clk/bcm/clk-sr.c:217:3: error: 'BCM_SR_LCPLL0_SATA_REF_CLK' undeclared here (not in a function); did you mean 'BCM_SR_LCPLL0_SATA_REFN_CLK'?
From: kbuild test robot @ 2018-06-02 9:01 UTC (permalink / raw)
To: linux-arm-kernel
tree: https://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git clk-bcm-stingray
head: 5afa881c6635427e68c73861a2c22d8cac00b984
commit: 48bf9a522c14449cc7c214c6062668ac54e4e88f [1/2] dt-bindings: clk: Update Stingray binding doc
config: sh-allmodconfig (attached as .config)
compiler: sh4-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 48bf9a522c14449cc7c214c6062668ac54e4e88f
# save the attached .config to linux build tree
make.cross ARCH=sh
Note: the clk/clk-bcm-stingray HEAD 5afa881c6635427e68c73861a2c22d8cac00b984 builds fine.
It only hurts bisectibility.
All errors (new ones prefixed by >>):
drivers/clk/bcm/clk-sr.c:59:3: error: 'BCM_SR_GENPLL0_SATA_CLK' undeclared here (not in a function); did you mean 'BCM_SR_GENPLL0_SCR_CLK'?
[BCM_SR_GENPLL0_SATA_CLK] = {
^~~~~~~~~~~~~~~~~~~~~~~
BCM_SR_GENPLL0_SCR_CLK
drivers/clk/bcm/clk-sr.c:59:3: error: array index in initializer not of integer type
drivers/clk/bcm/clk-sr.c:59:3: note: (near initialization for 'sr_genpll0_clk')
drivers/clk/bcm/clk-sr.c:184:3: error: 'BCM_SR_GENPLL5_FS_CLK' undeclared here (not in a function); did you mean 'BCM_SR_GENPLL2_FS4_CLK'?
[BCM_SR_GENPLL5_FS_CLK] = {
^~~~~~~~~~~~~~~~~~~~~
BCM_SR_GENPLL2_FS4_CLK
drivers/clk/bcm/clk-sr.c:184:3: error: array index in initializer not of integer type
drivers/clk/bcm/clk-sr.c:184:3: note: (near initialization for 'sr_genpll5_clk')
drivers/clk/bcm/clk-sr.c:185:14: warning: initialization makes integer from pointer without a cast [-Wint-conversion]
.channel = BCM_SR_GENPLL5_FS_CLK,
^~~~~~~~~~~~~~~~~~~~~
drivers/clk/bcm/clk-sr.c:185:14: note: (near initialization for 'sr_genpll5_clk[0].channel')
drivers/clk/bcm/clk-sr.c:185:14: error: initializer element is not constant
drivers/clk/bcm/clk-sr.c:185:14: note: (near initialization for 'sr_genpll5_clk[0].channel')
drivers/clk/bcm/clk-sr.c:190:3: error: 'BCM_SR_GENPLL5_SPU_CLK' undeclared here (not in a function); did you mean 'BCM_SR_GENPLL5_FS_CLK'?
[BCM_SR_GENPLL5_SPU_CLK] = {
^~~~~~~~~~~~~~~~~~~~~~
BCM_SR_GENPLL5_FS_CLK
drivers/clk/bcm/clk-sr.c:190:3: error: array index in initializer not of integer type
drivers/clk/bcm/clk-sr.c:190:3: note: (near initialization for 'sr_genpll5_clk')
drivers/clk/bcm/clk-sr.c:191:14: warning: initialization makes integer from pointer without a cast [-Wint-conversion]
.channel = BCM_SR_GENPLL5_SPU_CLK,
^~~~~~~~~~~~~~~~~~~~~~
drivers/clk/bcm/clk-sr.c:191:14: note: (near initialization for 'sr_genpll5_clk[1].channel')
drivers/clk/bcm/clk-sr.c:191:14: error: initializer element is not constant
drivers/clk/bcm/clk-sr.c:191:14: note: (near initialization for 'sr_genpll5_clk[1].channel')
>> drivers/clk/bcm/clk-sr.c:217:3: error: 'BCM_SR_LCPLL0_SATA_REF_CLK' undeclared here (not in a function); did you mean 'BCM_SR_LCPLL0_SATA_REFN_CLK'?
[BCM_SR_LCPLL0_SATA_REF_CLK] = {
^~~~~~~~~~~~~~~~~~~~~~~~~~
BCM_SR_LCPLL0_SATA_REFN_CLK
drivers/clk/bcm/clk-sr.c:217:3: error: array index in initializer not of integer type
drivers/clk/bcm/clk-sr.c:217:3: note: (near initialization for 'sr_lcpll0_clk')
drivers/clk/bcm/clk-sr.c:218:14: warning: initialization makes integer from pointer without a cast [-Wint-conversion]
.channel = BCM_SR_LCPLL0_SATA_REF_CLK,
^~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/clk/bcm/clk-sr.c:218:14: note: (near initialization for 'sr_lcpll0_clk[0].channel')
drivers/clk/bcm/clk-sr.c:218:14: error: initializer element is not constant
drivers/clk/bcm/clk-sr.c:218:14: note: (near initialization for 'sr_lcpll0_clk[0].channel')
drivers/clk/bcm/clk-sr.c:223:3: error: 'BCM_SR_LCPLL0_USB_REF_CLK' undeclared here (not in a function); did you mean 'BCM_SR_LCPLL1_USB_REF_CLK'?
[BCM_SR_LCPLL0_USB_REF_CLK] = {
^~~~~~~~~~~~~~~~~~~~~~~~~
BCM_SR_LCPLL1_USB_REF_CLK
drivers/clk/bcm/clk-sr.c:223:3: error: array index in initializer not of integer type
drivers/clk/bcm/clk-sr.c:223:3: note: (near initialization for 'sr_lcpll0_clk')
drivers/clk/bcm/clk-sr.c:224:14: warning: initialization makes integer from pointer without a cast [-Wint-conversion]
.channel = BCM_SR_LCPLL0_USB_REF_CLK,
^~~~~~~~~~~~~~~~~~~~~~~~~
drivers/clk/bcm/clk-sr.c:224:14: note: (near initialization for 'sr_lcpll0_clk[1].channel')
drivers/clk/bcm/clk-sr.c:224:14: error: initializer element is not constant
drivers/clk/bcm/clk-sr.c:224:14: note: (near initialization for 'sr_lcpll0_clk[1].channel')
>> drivers/clk/bcm/clk-sr.c:229:3: error: 'BCM_SR_LCPLL0_SATA_REFPN_CLK' undeclared here (not in a function); did you mean 'BCM_SR_LCPLL0_SATA_REFN_CLK'?
[BCM_SR_LCPLL0_SATA_REFPN_CLK] = {
^~~~~~~~~~~~~~~~~~~~~~~~~~~~
BCM_SR_LCPLL0_SATA_REFN_CLK
drivers/clk/bcm/clk-sr.c:229:3: error: array index in initializer not of integer type
drivers/clk/bcm/clk-sr.c:229:3: note: (near initialization for 'sr_lcpll0_clk')
drivers/clk/bcm/clk-sr.c:230:14: warning: initialization makes integer from pointer without a cast [-Wint-conversion]
.channel = BCM_SR_LCPLL0_SATA_REFPN_CLK,
^~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/clk/bcm/clk-sr.c:230:14: note: (near initialization for 'sr_lcpll0_clk[2].channel')
drivers/clk/bcm/clk-sr.c:230:14: error: initializer element is not constant
drivers/clk/bcm/clk-sr.c:230:14: note: (near initialization for 'sr_lcpll0_clk[2].channel')
vim +217 drivers/clk/bcm/clk-sr.c
654cdd32 Sandeep Tripathy 2017-06-06 182
654cdd32 Sandeep Tripathy 2017-06-06 183 static const struct iproc_clk_ctrl sr_genpll5_clk[] = {
654cdd32 Sandeep Tripathy 2017-06-06 184 [BCM_SR_GENPLL5_FS_CLK] = {
654cdd32 Sandeep Tripathy 2017-06-06 185 .channel = BCM_SR_GENPLL5_FS_CLK,
654cdd32 Sandeep Tripathy 2017-06-06 186 .flags = IPROC_CLK_AON,
654cdd32 Sandeep Tripathy 2017-06-06 187 .enable = ENABLE_VAL(0x4, 6, 0, 12),
654cdd32 Sandeep Tripathy 2017-06-06 188 .mdiv = REG_VAL(0x18, 0, 9),
654cdd32 Sandeep Tripathy 2017-06-06 189 },
654cdd32 Sandeep Tripathy 2017-06-06 @190 [BCM_SR_GENPLL5_SPU_CLK] = {
654cdd32 Sandeep Tripathy 2017-06-06 191 .channel = BCM_SR_GENPLL5_SPU_CLK,
654cdd32 Sandeep Tripathy 2017-06-06 192 .flags = IPROC_CLK_AON,
654cdd32 Sandeep Tripathy 2017-06-06 193 .enable = ENABLE_VAL(0x4, 6, 0, 12),
654cdd32 Sandeep Tripathy 2017-06-06 194 .mdiv = REG_VAL(0x18, 10, 9),
654cdd32 Sandeep Tripathy 2017-06-06 195 },
654cdd32 Sandeep Tripathy 2017-06-06 196 };
654cdd32 Sandeep Tripathy 2017-06-06 197
654cdd32 Sandeep Tripathy 2017-06-06 198 static int sr_genpll5_clk_init(struct platform_device *pdev)
654cdd32 Sandeep Tripathy 2017-06-06 199 {
654cdd32 Sandeep Tripathy 2017-06-06 200 iproc_pll_clk_setup(pdev->dev.of_node,
654cdd32 Sandeep Tripathy 2017-06-06 201 &sr_genpll5, NULL, 0, sr_genpll5_clk,
654cdd32 Sandeep Tripathy 2017-06-06 202 ARRAY_SIZE(sr_genpll5_clk));
654cdd32 Sandeep Tripathy 2017-06-06 203 return 0;
654cdd32 Sandeep Tripathy 2017-06-06 204 }
654cdd32 Sandeep Tripathy 2017-06-06 205
654cdd32 Sandeep Tripathy 2017-06-06 206 static const struct iproc_pll_ctrl sr_lcpll0 = {
654cdd32 Sandeep Tripathy 2017-06-06 207 .flags = IPROC_CLK_AON | IPROC_CLK_PLL_NEEDS_SW_CFG,
654cdd32 Sandeep Tripathy 2017-06-06 208 .aon = AON_VAL(0x0, 2, 19, 18),
654cdd32 Sandeep Tripathy 2017-06-06 209 .reset = RESET_VAL(0x0, 31, 30),
654cdd32 Sandeep Tripathy 2017-06-06 210 .sw_ctrl = SW_CTRL_VAL(0x4, 31),
654cdd32 Sandeep Tripathy 2017-06-06 211 .ndiv_int = REG_VAL(0x4, 16, 10),
654cdd32 Sandeep Tripathy 2017-06-06 212 .pdiv = REG_VAL(0x4, 26, 4),
654cdd32 Sandeep Tripathy 2017-06-06 213 .status = REG_VAL(0x38, 12, 1),
654cdd32 Sandeep Tripathy 2017-06-06 214 };
654cdd32 Sandeep Tripathy 2017-06-06 215
654cdd32 Sandeep Tripathy 2017-06-06 216 static const struct iproc_clk_ctrl sr_lcpll0_clk[] = {
654cdd32 Sandeep Tripathy 2017-06-06 @217 [BCM_SR_LCPLL0_SATA_REF_CLK] = {
654cdd32 Sandeep Tripathy 2017-06-06 218 .channel = BCM_SR_LCPLL0_SATA_REF_CLK,
654cdd32 Sandeep Tripathy 2017-06-06 219 .flags = IPROC_CLK_AON,
654cdd32 Sandeep Tripathy 2017-06-06 220 .enable = ENABLE_VAL(0x0, 7, 1, 13),
654cdd32 Sandeep Tripathy 2017-06-06 221 .mdiv = REG_VAL(0x14, 0, 9),
654cdd32 Sandeep Tripathy 2017-06-06 222 },
654cdd32 Sandeep Tripathy 2017-06-06 @223 [BCM_SR_LCPLL0_USB_REF_CLK] = {
654cdd32 Sandeep Tripathy 2017-06-06 224 .channel = BCM_SR_LCPLL0_USB_REF_CLK,
654cdd32 Sandeep Tripathy 2017-06-06 225 .flags = IPROC_CLK_AON,
654cdd32 Sandeep Tripathy 2017-06-06 226 .enable = ENABLE_VAL(0x0, 8, 2, 14),
654cdd32 Sandeep Tripathy 2017-06-06 227 .mdiv = REG_VAL(0x14, 10, 9),
654cdd32 Sandeep Tripathy 2017-06-06 228 },
654cdd32 Sandeep Tripathy 2017-06-06 @229 [BCM_SR_LCPLL0_SATA_REFPN_CLK] = {
654cdd32 Sandeep Tripathy 2017-06-06 230 .channel = BCM_SR_LCPLL0_SATA_REFPN_CLK,
654cdd32 Sandeep Tripathy 2017-06-06 231 .flags = IPROC_CLK_AON,
654cdd32 Sandeep Tripathy 2017-06-06 232 .enable = ENABLE_VAL(0x0, 9, 3, 15),
654cdd32 Sandeep Tripathy 2017-06-06 233 .mdiv = REG_VAL(0x14, 20, 9),
654cdd32 Sandeep Tripathy 2017-06-06 234 },
654cdd32 Sandeep Tripathy 2017-06-06 235 };
654cdd32 Sandeep Tripathy 2017-06-06 236
:::::: The code at line 217 was first introduced by commit
:::::: 654cdd3229cd1d3f2bfb9df57baf88ba382a52be clk: bcm: Add clocks for Stingray SOC
:::::: TO: Sandeep Tripathy <sandeep.tripathy@broadcom.com>
:::::: CC: Stephen Boyd <sboyd@codeaurora.org>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 47758 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180602/d7e73bfe/attachment-0001.gz>
^ permalink raw reply
* [PATCH] arm64: tegra: Remove unused interrupt properties
From: Bhadram Varka @ 2018-06-02 9:11 UTC (permalink / raw)
To: linux-arm-kernel
DWC EQOS on Tegra handles all interrupts through
common interrupt line. So lets remove unused power
and per-channel interrupt properties.
Signed-off-by: Bhadram Varka <vbhadram@nvidia.com>
---
arch/arm64/boot/dts/nvidia/tegra186.dtsi | 11 +----------
1 file changed, 1 insertion(+), 10 deletions(-)
diff --git a/arch/arm64/boot/dts/nvidia/tegra186.dtsi b/arch/arm64/boot/dts/nvidia/tegra186.dtsi
index b762227..252133b 100644
--- a/arch/arm64/boot/dts/nvidia/tegra186.dtsi
+++ b/arch/arm64/boot/dts/nvidia/tegra186.dtsi
@@ -41,16 +41,7 @@
compatible = "nvidia,tegra186-eqos",
"snps,dwc-qos-ethernet-4.10";
reg = <0x0 0x02490000 0x0 0x10000>;
- interrupts = <GIC_SPI 194 IRQ_TYPE_LEVEL_HIGH>, /* common */
- <GIC_SPI 195 IRQ_TYPE_LEVEL_HIGH>, /* power */
- <GIC_SPI 190 IRQ_TYPE_LEVEL_HIGH>, /* rx0 */
- <GIC_SPI 186 IRQ_TYPE_LEVEL_HIGH>, /* tx0 */
- <GIC_SPI 191 IRQ_TYPE_LEVEL_HIGH>, /* rx1 */
- <GIC_SPI 187 IRQ_TYPE_LEVEL_HIGH>, /* tx1 */
- <GIC_SPI 192 IRQ_TYPE_LEVEL_HIGH>, /* rx2 */
- <GIC_SPI 188 IRQ_TYPE_LEVEL_HIGH>, /* tx2 */
- <GIC_SPI 193 IRQ_TYPE_LEVEL_HIGH>, /* rx3 */
- <GIC_SPI 189 IRQ_TYPE_LEVEL_HIGH>; /* tx3 */
+ interrupts = <GIC_SPI 194 IRQ_TYPE_LEVEL_HIGH>; /* common */
clocks = <&bpmp TEGRA186_CLK_AXI_CBB>,
<&bpmp TEGRA186_CLK_EQOS_AXI>,
<&bpmp TEGRA186_CLK_EQOS_RX>,
--
2.7.4
^ permalink raw reply related
* [PATCH 2/3] arm64: tegra: Enable multi-queue for DWC EQOS
From: Bhadram Varka @ 2018-06-02 9:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527930713-4479-1-git-send-email-vbhadram@nvidia.com>
DWC EQOS supports four MTL queues for Tx and Rx
separately.
Signed-off-by: Bhadram Varka <vbhadram@nvidia.com>
---
arch/arm64/boot/dts/nvidia/tegra186.dtsi | 48 ++++++++++++++++++++++++++++++++
1 file changed, 48 insertions(+)
diff --git a/arch/arm64/boot/dts/nvidia/tegra186.dtsi b/arch/arm64/boot/dts/nvidia/tegra186.dtsi
index 0f4bed8..f27730d 100644
--- a/arch/arm64/boot/dts/nvidia/tegra186.dtsi
+++ b/arch/arm64/boot/dts/nvidia/tegra186.dtsi
@@ -37,6 +37,52 @@
gpio-controller;
};
+ mtl_rx_setup: rx-queues-config {
+ snps,rx-queues-to-use = <4>;
+ snps,rx-sched-sp;
+ queue0 {
+ snps,dcb-algorithm;
+ snps,map-to-dma-channel = <0x0>;
+ snps,priority = <0x0>;
+ };
+ queue1 {
+ snps,dcb-algorithm;
+ snps,map-to-dma-channel = <0x1>;
+ snps,priority = <0x1>;
+ };
+ queue2 {
+ snps,dcb-algorithm;
+ snps,map-to-dma-channel = <0x2>;
+ snps,priority = <0x2>;
+ };
+ queue3 {
+ snps,dcb-algorithm;
+ snps,map-to-dma-channel = <0x2>;
+ snps,priority = <0x3>;
+ };
+ };
+
+ mtl_tx_setup: tx-queues-config {
+ snps,tx-queues-to-use = <4>;
+ snps,tx-sched-sp;
+ queue0 {
+ snps,dcb-algorithm;
+ snps,priority = <0x0>;
+ };
+ queue1 {
+ snps,dcb-algorithm;
+ snps,priority = <0x1>;
+ };
+ queue2 {
+ snps,dcb-algorithm;
+ snps,priority = <0x2>;
+ };
+ queue3 {
+ snps,dcb-algorithm;
+ snps,priority = <0x3>;
+ };
+ };
+
ethernet at 2490000 {
compatible = "nvidia,tegra186-eqos",
"snps,dwc-qos-ethernet-4.10";
@@ -57,6 +103,8 @@
snps,burst-map = <0x7>;
snps,txpbl = <32>;
snps,rxpbl = <8>;
+ snps,mtl-rx-config = <&mtl_rx_setup>;
+ snps,mtl-tx-config = <&mtl_tx_setup>;
};
memory-controller at 2c00000 {
--
2.7.4
^ permalink raw reply related
* [PATCH 3/3] arm64: tegra: Configure DWC EQOS TxPBL for multi-queue
From: Bhadram Varka @ 2018-06-02 9:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527930713-4479-1-git-send-email-vbhadram@nvidia.com>
PBL should be limited to half of the Queue size.
For multi-queue: Total MTL queue size 4KB.
PBL = 16, PBLx8 = 1 -> This setting would lead
to an effective burst = 8*16 = 128, which would
mean 128*16B = 2KB (half of queue size)
Signed-off-by: Bhadram Varka <vbhadram@nvidia.com>
---
arch/arm64/boot/dts/nvidia/tegra186.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/nvidia/tegra186.dtsi b/arch/arm64/boot/dts/nvidia/tegra186.dtsi
index f27730d..630cb81 100644
--- a/arch/arm64/boot/dts/nvidia/tegra186.dtsi
+++ b/arch/arm64/boot/dts/nvidia/tegra186.dtsi
@@ -101,7 +101,7 @@
snps,write-requests = <1>;
snps,read-requests = <3>;
snps,burst-map = <0x7>;
- snps,txpbl = <32>;
+ snps,txpbl = <16>;
snps,rxpbl = <8>;
snps,mtl-rx-config = <&mtl_rx_setup>;
snps,mtl-tx-config = <&mtl_tx_setup>;
--
2.7.4
^ permalink raw reply related
* [PATCH V2 1/3] arm64: tegra: Remove unused interrupt properties
From: Bhadram Varka @ 2018-06-02 9:20 UTC (permalink / raw)
To: linux-arm-kernel
DWC EQOS on Tegra handles all interrupts through
common interrupt line. So lets remove unused power
and per-channel interrupt properties.
Signed-off-by: Bhadram Varka <vbhadram@nvidia.com>
---
arch/arm64/boot/dts/nvidia/tegra186.dtsi | 11 +----------
1 file changed, 1 insertion(+), 10 deletions(-)
diff --git a/arch/arm64/boot/dts/nvidia/tegra186.dtsi b/arch/arm64/boot/dts/nvidia/tegra186.dtsi
index b762227..252133b 100644
--- a/arch/arm64/boot/dts/nvidia/tegra186.dtsi
+++ b/arch/arm64/boot/dts/nvidia/tegra186.dtsi
@@ -41,16 +41,7 @@
compatible = "nvidia,tegra186-eqos",
"snps,dwc-qos-ethernet-4.10";
reg = <0x0 0x02490000 0x0 0x10000>;
- interrupts = <GIC_SPI 194 IRQ_TYPE_LEVEL_HIGH>, /* common */
- <GIC_SPI 195 IRQ_TYPE_LEVEL_HIGH>, /* power */
- <GIC_SPI 190 IRQ_TYPE_LEVEL_HIGH>, /* rx0 */
- <GIC_SPI 186 IRQ_TYPE_LEVEL_HIGH>, /* tx0 */
- <GIC_SPI 191 IRQ_TYPE_LEVEL_HIGH>, /* rx1 */
- <GIC_SPI 187 IRQ_TYPE_LEVEL_HIGH>, /* tx1 */
- <GIC_SPI 192 IRQ_TYPE_LEVEL_HIGH>, /* rx2 */
- <GIC_SPI 188 IRQ_TYPE_LEVEL_HIGH>, /* tx2 */
- <GIC_SPI 193 IRQ_TYPE_LEVEL_HIGH>, /* rx3 */
- <GIC_SPI 189 IRQ_TYPE_LEVEL_HIGH>; /* tx3 */
+ interrupts = <GIC_SPI 194 IRQ_TYPE_LEVEL_HIGH>; /* common */
clocks = <&bpmp TEGRA186_CLK_AXI_CBB>,
<&bpmp TEGRA186_CLK_EQOS_AXI>,
<&bpmp TEGRA186_CLK_EQOS_RX>,
--
2.7.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox