* [PATCH 5/6] arm64: tegra: Add Tegra194 chip device tree
From: Rob Herring @ 2018-01-11 21:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1515387278-29777-6-git-send-email-mperttunen@nvidia.com>
On Mon, Jan 08, 2018 at 06:54:37AM +0200, Mikko Perttunen wrote:
> Add the chip-level device tree, including binding headers, for the
> NVIDIA Tegra194 "Xavier" system-on-chip. Only a small subset of devices
> are initially available, enough to boot to UART console.
>
> Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com>
> ---
> arch/arm64/boot/dts/nvidia/tegra194.dtsi | 334 +++++++++++++++++++++++++++++
> include/dt-bindings/clock/tegra194-clock.h | 59 +++++
> include/dt-bindings/gpio/tegra194-gpio.h | 59 +++++
> include/dt-bindings/reset/tegra194-reset.h | 40 ++++
> 4 files changed, 492 insertions(+)
> create mode 100644 arch/arm64/boot/dts/nvidia/tegra194.dtsi
> create mode 100644 include/dt-bindings/clock/tegra194-clock.h
> create mode 100644 include/dt-bindings/gpio/tegra194-gpio.h
> create mode 100644 include/dt-bindings/reset/tegra194-reset.h
>
> diff --git a/arch/arm64/boot/dts/nvidia/tegra194.dtsi b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
> new file mode 100644
> index 000000000000..51eff420816d
> --- /dev/null
> +++ b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
> @@ -0,0 +1,334 @@
> +// SPDX-License-Identifier: GPL-2.0
> +#include <dt-bindings/clock/tegra194-clock.h>
> +#include <dt-bindings/gpio/tegra194-gpio.h>
> +#include <dt-bindings/interrupt-controller/arm-gic.h>
> +#include <dt-bindings/mailbox/tegra186-hsp.h>
> +#include <dt-bindings/reset/tegra194-reset.h>
> +
> +/ {
> + compatible = "nvidia,tegra194";
Documented?
> + interrupt-parent = <&gic>;
> + #address-cells = <2>;
> + #size-cells = <2>;
> +
> + uarta: serial at 3100000 {
These should all be under a bus node. Tegra failed to do this at the
start and we're still copy-n-pasting this mistake.
Then you probably don't need 2 address and size cells for all the
peripherals.
> + compatible = "nvidia,tegra194-uart", "nvidia,tegra20-uart";
> + reg = <0x0 0x03100000 0x0 0x40>;
> + reg-shift = <2>;
> + interrupts = <GIC_SPI 112 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&bpmp TEGRA194_CLK_UARTA>;
> + clock-names = "serial";
> + resets = <&bpmp TEGRA194_RESET_UARTA>;
> + reset-names = "serial";
> + status = "disabled";
> + };
> +
> + uartb: serial at 3110000 {
> + compatible = "nvidia,tegra194-uart", "nvidia,tegra20-uart";
> + reg = <0x0 0x03110000 0x0 0x40>;
> + reg-shift = <2>;
> + interrupts = <GIC_SPI 113 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&bpmp TEGRA194_CLK_UARTB>;
> + clock-names = "serial";
> + resets = <&bpmp TEGRA194_RESET_UARTB>;
> + reset-names = "serial";
> + status = "disabled";
> + };
> +
> + uartd: serial at 3130000 {
> + compatible = "nvidia,tegra194-uart", "nvidia,tegra20-uart";
> + reg = <0x0 0x03130000 0x0 0x40>;
> + reg-shift = <2>;
> + interrupts = <GIC_SPI 115 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&bpmp TEGRA194_CLK_UARTD>;
> + clock-names = "serial";
> + resets = <&bpmp TEGRA194_RESET_UARTD>;
> + reset-names = "serial";
> + status = "disabled";
> + };
> +
> + uarte: serial at 3140000 {
> + compatible = "nvidia,tegra194-uart", "nvidia,tegra20-uart";
> + reg = <0x0 0x03140000 0x0 0x40>;
> + reg-shift = <2>;
> + interrupts = <GIC_SPI 116 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&bpmp TEGRA194_CLK_UARTE>;
> + clock-names = "serial";
> + resets = <&bpmp TEGRA194_RESET_UARTE>;
> + reset-names = "serial";
> + status = "disabled";
> + };
> +
> + uartf: serial at 3150000 {
> + compatible = "nvidia,tegra194-uart", "nvidia,tegra20-uart";
> + reg = <0x0 0x03150000 0x0 0x40>;
> + reg-shift = <2>;
> + interrupts = <GIC_SPI 117 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&bpmp TEGRA194_CLK_UARTF>;
> + clock-names = "serial";
> + resets = <&bpmp TEGRA194_RESET_UARTF>;
> + reset-names = "serial";
> + status = "disabled";
> + };
> +
> + gen1_i2c: i2c at 3160000 {
> + compatible = "nvidia,tegra194-i2c", "nvidia,tegra114-i2c";
> + reg = <0x0 0x03160000 0x0 0x10000>;
> + interrupts = <GIC_SPI 25 IRQ_TYPE_LEVEL_HIGH>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + clocks = <&bpmp TEGRA194_CLK_I2C1>;
> + clock-names = "div-clk";
> + resets = <&bpmp TEGRA194_RESET_I2C1>;
> + reset-names = "i2c";
> + status = "disabled";
> + };
> +
> + uarth: serial at 3170000 {
> + compatible = "nvidia,tegra194-uart", "nvidia,tegra20-uart";
> + reg = <0x0 0x03170000 0x0 0x40>;
> + reg-shift = <2>;
> + interrupts = <GIC_SPI 207 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&bpmp TEGRA194_CLK_UARTH>;
> + clock-names = "serial";
> + resets = <&bpmp TEGRA194_RESET_UARTH>;
> + reset-names = "serial";
> + status = "disabled";
> + };
> +
> + cam_i2c: i2c at 3180000 {
> + compatible = "nvidia,tegra194-i2c", "nvidia,tegra114-i2c";
> + reg = <0x0 0x03180000 0x0 0x10000>;
> + interrupts = <GIC_SPI 27 IRQ_TYPE_LEVEL_HIGH>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + clocks = <&bpmp TEGRA194_CLK_I2C3>;
> + clock-names = "div-clk";
> + resets = <&bpmp TEGRA194_RESET_I2C3>;
> + reset-names = "i2c";
> + status = "disabled";
> + };
> +
> + /* shares pads with dpaux1 */
> + dp_aux_ch1_i2c: i2c at 3190000 {
> + compatible = "nvidia,tegra194-i2c", "nvidia,tegra114-i2c";
> + reg = <0x0 0x03190000 0x0 0x10000>;
> + interrupts = <GIC_SPI 28 IRQ_TYPE_LEVEL_HIGH>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + clocks = <&bpmp TEGRA194_CLK_I2C4>;
> + clock-names = "div-clk";
> + resets = <&bpmp TEGRA194_RESET_I2C4>;
> + reset-names = "i2c";
> + status = "disabled";
> + };
> +
> + /* shares pads with dpaux0 */
> + dp_aux_ch0_i2c: i2c at 31b0000 {
> + compatible = "nvidia,tegra194-i2c", "nvidia,tegra114-i2c";
> + reg = <0x0 0x031b0000 0x0 0x10000>;
> + interrupts = <GIC_SPI 30 IRQ_TYPE_LEVEL_HIGH>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + clocks = <&bpmp TEGRA194_CLK_I2C6>;
> + clock-names = "div-clk";
> + resets = <&bpmp TEGRA194_RESET_I2C6>;
> + reset-names = "i2c";
> + status = "disabled";
> + };
> +
> + gen7_i2c: i2c at 31c0000 {
> + compatible = "nvidia,tegra194-i2c", "nvidia,tegra114-i2c";
> + reg = <0x0 0x031c0000 0x0 0x10000>;
> + interrupts = <GIC_SPI 31 IRQ_TYPE_LEVEL_HIGH>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + clocks = <&bpmp TEGRA194_CLK_I2C7>;
> + clock-names = "div-clk";
> + resets = <&bpmp TEGRA194_RESET_I2C7>;
> + reset-names = "i2c";
> + status = "disabled";
> + };
> +
> + gen9_i2c: i2c at 31e0000 {
> + compatible = "nvidia,tegra194-i2c", "nvidia,tegra114-i2c";
> + reg = <0x0 0x031e0000 0x0 0x10000>;
> + interrupts = <GIC_SPI 33 IRQ_TYPE_LEVEL_HIGH>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + clocks = <&bpmp TEGRA194_CLK_I2C9>;
> + clock-names = "div-clk";
> + resets = <&bpmp TEGRA194_RESET_I2C9>;
> + reset-names = "i2c";
> + status = "disabled";
> + };
> +
> + sdmmc1: sdhci at 3400000 {
> + compatible = "nvidia,tegra194-sdhci", "nvidia,tegra186-sdhci";
> + reg = <0x0 0x03400000 0x0 0x10000>;
> + interrupts = <GIC_SPI 62 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&bpmp TEGRA194_CLK_SDMMC1>;
> + clock-names = "sdhci";
> + resets = <&bpmp TEGRA194_RESET_SDMMC1>;
> + reset-names = "sdhci";
> + status = "disabled";
> + };
> +
> + sdmmc3: sdhci at 3440000 {
> + compatible = "nvidia,tegra194-sdhci", "nvidia,tegra186-sdhci";
> + reg = <0x0 0x03440000 0x0 0x10000>;
> + interrupts = <GIC_SPI 64 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&bpmp TEGRA194_CLK_SDMMC3>;
> + clock-names = "sdhci";
> + resets = <&bpmp TEGRA194_RESET_SDMMC3>;
> + reset-names = "sdhci";
> + status = "disabled";
> + };
> +
> + sdmmc4: sdhci at 3460000 {
> + compatible = "nvidia,tegra194-sdhci", "nvidia,tegra186-sdhci";
> + reg = <0x0 0x03460000 0x0 0x10000>;
> + interrupts = <GIC_SPI 65 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&bpmp TEGRA194_CLK_SDMMC4>;
> + clock-names = "sdhci";
> + resets = <&bpmp TEGRA194_RESET_SDMMC4>;
> + reset-names = "sdhci";
> + status = "disabled";
> + };
> +
> + gic: interrupt-controller at 3881000 {
> + compatible = "arm,gic-400";
> + #interrupt-cells = <3>;
> + interrupt-controller;
> + reg = <0x0 0x03881000 0x0 0x1000>,
> + <0x0 0x03882000 0x0 0x2000>;
> + interrupts = <GIC_PPI 9
> + (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;
> + interrupt-parent = <&gic>;
> + };
> +
> + hsp_top0: hsp at 3c00000 {
> + compatible = "nvidia,tegra186-hsp";
> + reg = <0x0 0x03c00000 0x0 0xa0000>;
> + interrupts = <GIC_SPI 176 IRQ_TYPE_LEVEL_HIGH>;
> + interrupt-names = "doorbell";
> + #mbox-cells = <2>;
> + };
> +
> + gen2_i2c: i2c at c240000 {
> + compatible = "nvidia,tegra194-i2c", "nvidia,tegra114-i2c";
> + reg = <0x0 0x0c240000 0x0 0x10000>;
> + interrupts = <GIC_SPI 26 IRQ_TYPE_LEVEL_HIGH>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + clocks = <&bpmp TEGRA194_CLK_I2C2>;
> + clock-names = "div-clk";
> + resets = <&bpmp TEGRA194_RESET_I2C2>;
> + reset-names = "i2c";
> + status = "disabled";
> + };
> +
> + gen8_i2c: i2c at c250000 {
> + compatible = "nvidia,tegra194-i2c", "nvidia,tegra114-i2c";
> + reg = <0x0 0x0c250000 0x0 0x10000>;
> + interrupts = <GIC_SPI 32 IRQ_TYPE_LEVEL_HIGH>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + clocks = <&bpmp TEGRA194_CLK_I2C8>;
> + clock-names = "div-clk";
> + resets = <&bpmp TEGRA194_RESET_I2C8>;
> + reset-names = "i2c";
> + status = "disabled";
> + };
> +
> + uartc: serial at c280000 {
> + compatible = "nvidia,tegra194-uart", "nvidia,tegra20-uart";
> + reg = <0x0 0x0c280000 0x0 0x40>;
> + reg-shift = <2>;
> + interrupts = <GIC_SPI 114 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&bpmp TEGRA194_CLK_UARTC>;
> + clock-names = "serial";
> + resets = <&bpmp TEGRA194_RESET_UARTC>;
> + reset-names = "serial";
> + status = "disabled";
> + };
> +
> + uartg: serial at c290000 {
> + compatible = "nvidia,tegra194-uart", "nvidia,tegra20-uart";
> + reg = <0x0 0x0c290000 0x0 0x40>;
> + reg-shift = <2>;
> + interrupts = <GIC_SPI 118 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&bpmp TEGRA194_CLK_UARTG>;
> + clock-names = "serial";
> + resets = <&bpmp TEGRA194_RESET_UARTG>;
> + reset-names = "serial";
> + status = "disabled";
> + };
> +
> + pmc at c360000 {
> + compatible = "nvidia,tegra194-pmc";
> + reg = <0 0x0c360000 0 0x10000>,
> + <0 0x0c370000 0 0x10000>,
> + <0 0x0c380000 0 0x10000>,
> + <0 0x0c390000 0 0x10000>,
> + <0 0x0c3a0000 0 0x10000>;
> + reg-names = "pmc", "wake", "aotag", "scratch", "misc";
> + };
> +
> + sysram at 40000000 {
> + compatible = "nvidia,tegra194-sysram", "mmio-sram";
> + reg = <0x0 0x40000000 0x0 0x50000>;
> + #address-cells = <2>;
> + #size-cells = <2>;
> + ranges = <0 0x0 0x0 0x40000000 0x0 0x50000>;
> +
> + cpu_bpmp_tx: shmem at 4e000 {
> + compatible = "nvidia,tegra194-bpmp-shmem";
> + reg = <0x0 0x4e000 0x0 0x1000>;
> + label = "cpu-bpmp-tx";
> + pool;
> + };
> +
> + cpu_bpmp_rx: shmem at 4f000 {
> + compatible = "nvidia,tegra194-bpmp-shmem";
> + reg = <0x0 0x4f000 0x0 0x1000>;
> + label = "cpu-bpmp-rx";
> + pool;
> + };
> + };
> +
> + bpmp: bpmp {
> + compatible = "nvidia,tegra186-bpmp";
> + mboxes = <&hsp_top0 TEGRA_HSP_MBOX_TYPE_DB
> + TEGRA_HSP_DB_MASTER_BPMP>;
> + shmem = <&cpu_bpmp_tx &cpu_bpmp_rx>;
> + #clock-cells = <1>;
> + #reset-cells = <1>;
> + #power-domain-cells = <1>;
> +
> + bpmp_i2c: i2c {
> + compatible = "nvidia,tegra186-bpmp-i2c";
> + nvidia,bpmp-bus-id = <5>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> +
> + bpmp_thermal: thermal {
> + compatible = "nvidia,tegra186-bpmp-thermal";
> + #thermal-sensor-cells = <1>;
> + };
> + };
> +
> + timer {
> + compatible = "arm,armv8-timer";
> + interrupts = <GIC_PPI 13
> + (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
> + <GIC_PPI 14
> + (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
> + <GIC_PPI 11
> + (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
> + <GIC_PPI 10
> + (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>;
> + interrupt-parent = <&gic>;
> + };
> +};
> diff --git a/include/dt-bindings/clock/tegra194-clock.h b/include/dt-bindings/clock/tegra194-clock.h
> new file mode 100644
> index 000000000000..7eba4763e375
> --- /dev/null
> +++ b/include/dt-bindings/clock/tegra194-clock.h
> @@ -0,0 +1,59 @@
> +/*
> + * Copyright (c) 2018, NVIDIA CORPORATION. All rights reserved.
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms and conditions of the GNU General Public License,
> + * version 2, as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope it will be useful, but WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
> + * more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program. If not, see <http://www.gnu.org/licenses/>.
Seems you missed using SPDX tag on this one.
> + */
> +
> +#ifndef __ABI_MACH_T194_CLOCK_H
> +#define __ABI_MACH_T194_CLOCK_H
> +
> +/** @clkdesc{i2c_clks, out, mux, CLK_RST_CONTROLLER_CLK_SOURCE_I2C1} */
> +#define TEGRA194_CLK_I2C1 48
> +/** @brief output of mux controlled by CLK_RST_CONTROLLER_CLK_SOURCE_I2C2 */
> +#define TEGRA194_CLK_I2C2 49
> +/** @brief output of mux controlled by CLK_RST_CONTROLLER_CLK_SOURCE_I2C3 */
> +#define TEGRA194_CLK_I2C3 50
> +/** output of mux controlled by CLK_RST_CONTROLLER_CLK_SOURCE_I2C4 */
> +#define TEGRA194_CLK_I2C4 51
> +/** @brief output of mux controlled by CLK_RST_CONTROLLER_CLK_SOURCE_I2C6 */
> +#define TEGRA194_CLK_I2C6 52
> +/** @brief output of mux controlled by CLK_RST_CONTROLLER_CLK_SOURCE_I2C7 */
> +#define TEGRA194_CLK_I2C7 53
> +/** @brief output of mux controlled by CLK_RST_CONTROLLER_CLK_SOURCE_I2C8 */
> +#define TEGRA194_CLK_I2C8 54
> +/** @brief output of mux controlled by CLK_RST_CONTROLLER_CLK_SOURCE_I2C9 */
> +#define TEGRA194_CLK_I2C9 55
> +/** @brief output of mux controlled by CLK_RST_CONTROLLER_CLK_SOURCE_SDMMC1 */
> +#define TEGRA194_CLK_SDMMC1 120
> +/** @brief output of mux controlled by CLK_RST_CONTROLLER_CLK_SOURCE_SDMMC3 */
> +#define TEGRA194_CLK_SDMMC3 122
> +/** @brief output of mux controlled by CLK_RST_CONTROLLER_CLK_SOURCE_SDMMC4 */
> +#define TEGRA194_CLK_SDMMC4 123
> +/** @brief output of mux controlled by CLK_RST_CONTROLLER_CLK_SOURCE_UARTA */
> +#define TEGRA194_CLK_UARTA 155
> +/** @brief output of mux controlled by CLK_RST_CONTROLLER_CLK_SOURCE_UARTB */
> +#define TEGRA194_CLK_UARTB 156
> +/** @brief output of mux controlled by CLK_RST_CONTROLLER_CLK_SOURCE_UARTC */
> +#define TEGRA194_CLK_UARTC 157
> +/** @brief output of mux controlled by CLK_RST_CONTROLLER_CLK_SOURCE_UARTD */
> +#define TEGRA194_CLK_UARTD 158
> +/** @brief output of mux controlled by CLK_RST_CONTROLLER_CLK_SOURCE_UARTE */
> +#define TEGRA194_CLK_UARTE 159
> +/** @brief output of mux controlled by CLK_RST_CONTROLLER_CLK_SOURCE_UARTF */
> +#define TEGRA194_CLK_UARTF 160
> +/** @brief output of mux controlled by CLK_RST_CONTROLLER_CLK_SOURCE_UARTG */
> +#define TEGRA194_CLK_UARTG 161
> +/** @brief CLK_RST_CONTROLLER_CLK_SOURCE_UARTH switch divider output */
> +#define TEGRA194_CLK_UARTH 190
> +
> +#endif
> diff --git a/include/dt-bindings/gpio/tegra194-gpio.h b/include/dt-bindings/gpio/tegra194-gpio.h
> new file mode 100644
> index 000000000000..86435a73ef9e
> --- /dev/null
> +++ b/include/dt-bindings/gpio/tegra194-gpio.h
> @@ -0,0 +1,59 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * This header provides constants for binding nvidia,tegra194-gpio*.
> + *
> + * The first cell in Tegra's GPIO specifier is the GPIO ID. The macros below
> + * provide names for this.
> + *
> + * The second cell contains standard flag values specified in gpio.h.
> + */
> +
> +#ifndef _DT_BINDINGS_GPIO_TEGRA194_GPIO_H
> +#define _DT_BINDINGS_GPIO_TEGRA194_GPIO_H
> +
> +#include <dt-bindings/gpio/gpio.h>
> +
> +/* GPIOs implemented by main GPIO controller */
> +#define TEGRA194_MAIN_GPIO_PORT_A 0
> +#define TEGRA194_MAIN_GPIO_PORT_B 1
> +#define TEGRA194_MAIN_GPIO_PORT_C 2
> +#define TEGRA194_MAIN_GPIO_PORT_D 3
> +#define TEGRA194_MAIN_GPIO_PORT_E 4
> +#define TEGRA194_MAIN_GPIO_PORT_F 5
> +#define TEGRA194_MAIN_GPIO_PORT_G 6
> +#define TEGRA194_MAIN_GPIO_PORT_H 7
> +#define TEGRA194_MAIN_GPIO_PORT_I 8
> +#define TEGRA194_MAIN_GPIO_PORT_J 9
> +#define TEGRA194_MAIN_GPIO_PORT_K 10
> +#define TEGRA194_MAIN_GPIO_PORT_L 11
> +#define TEGRA194_MAIN_GPIO_PORT_M 12
> +#define TEGRA194_MAIN_GPIO_PORT_N 13
> +#define TEGRA194_MAIN_GPIO_PORT_O 14
> +#define TEGRA194_MAIN_GPIO_PORT_P 15
> +#define TEGRA194_MAIN_GPIO_PORT_Q 16
> +#define TEGRA194_MAIN_GPIO_PORT_R 17
> +#define TEGRA194_MAIN_GPIO_PORT_S 18
> +#define TEGRA194_MAIN_GPIO_PORT_T 19
> +#define TEGRA194_MAIN_GPIO_PORT_U 20
> +#define TEGRA194_MAIN_GPIO_PORT_V 21
> +#define TEGRA194_MAIN_GPIO_PORT_W 22
> +#define TEGRA194_MAIN_GPIO_PORT_X 23
> +#define TEGRA194_MAIN_GPIO_PORT_Y 24
> +#define TEGRA194_MAIN_GPIO_PORT_Z 25
> +#define TEGRA194_MAIN_GPIO_PORT_FF 26
> +#define TEGRA194_MAIN_GPIO_PORT_GG 27
> +
> +#define TEGRA194_MAIN_GPIO(port, offset) \
> + ((TEGRA194_MAIN_GPIO_PORT_##port * 8) + offset)
> +
> +/* GPIOs implemented by AON GPIO controller */
> +#define TEGRA194_AON_GPIO_PORT_AA 0
> +#define TEGRA194_AON_GPIO_PORT_BB 1
> +#define TEGRA194_AON_GPIO_PORT_CC 2
> +#define TEGRA194_AON_GPIO_PORT_DD 3
> +#define TEGRA194_AON_GPIO_PORT_EE 4
> +
> +#define TEGRA194_AON_GPIO(port, offset) \
> + ((TEGRA194_AON_GPIO_PORT_##port * 8) + offset)
> +
> +#endif
> diff --git a/include/dt-bindings/reset/tegra194-reset.h b/include/dt-bindings/reset/tegra194-reset.h
> new file mode 100644
> index 000000000000..7c6afac99c4a
> --- /dev/null
> +++ b/include/dt-bindings/reset/tegra194-reset.h
> @@ -0,0 +1,40 @@
> +/*
> + * Copyright (c) 2018, NVIDIA CORPORATION. All rights reserved.
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms and conditions of the GNU General Public License,
> + * version 2, as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope it will be useful, but WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
> + * more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program. If not, see <http://www.gnu.org/licenses/>.
SPDX
> + */
> +
> +#ifndef __ABI_MACH_T194_RESET_H
> +#define __ABI_MACH_T194_RESET_H
> +
> +#define TEGRA194_RESET_I2C1 24
> +#define TEGRA194_RESET_I2C2 29
> +#define TEGRA194_RESET_I2C3 30
> +#define TEGRA194_RESET_I2C4 31
> +#define TEGRA194_RESET_I2C6 32
> +#define TEGRA194_RESET_I2C7 33
> +#define TEGRA194_RESET_I2C8 34
> +#define TEGRA194_RESET_I2C9 35
> +#define TEGRA194_RESET_SDMMC1 82
> +#define TEGRA194_RESET_SDMMC3 84
> +#define TEGRA194_RESET_SDMMC4 85
> +#define TEGRA194_RESET_UARTA 100
> +#define TEGRA194_RESET_UARTB 101
> +#define TEGRA194_RESET_UARTC 102
> +#define TEGRA194_RESET_UARTD 103
> +#define TEGRA194_RESET_UARTE 104
> +#define TEGRA194_RESET_UARTF 105
> +#define TEGRA194_RESET_UARTG 106
> +#define TEGRA194_RESET_UARTH 107
> +
> +#endif
> --
> 2.1.4
>
^ permalink raw reply
* [PATCH 2/2] kasan: clean up KASAN_SHADOW_SCALE_SHIFT usage
From: Andrey Ryabinin @ 2018-01-11 21:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <ff221eca3db7a1f208c30c625b7d209fba33abb9.1515684162.git.andreyknvl@google.com>
On 01/11/2018 06:29 PM, Andrey Konovalov wrote:
> diff --git a/arch/arm64/include/asm/kasan.h b/arch/arm64/include/asm/kasan.h
> index e266f80e45b7..811643fe7640 100644
> --- a/arch/arm64/include/asm/kasan.h
> +++ b/arch/arm64/include/asm/kasan.h
> @@ -27,7 +27,8 @@
> * should satisfy the following equation:
> * KASAN_SHADOW_OFFSET = KASAN_SHADOW_END - (1ULL << 61)
Care to update comments as well?
> */
> -#define KASAN_SHADOW_OFFSET (KASAN_SHADOW_END - (1ULL << (64 - 3)))
> +#define KASAN_SHADOW_OFFSET (KASAN_SHADOW_END - (1ULL << \
> + (64 - KASAN_SHADOW_SCALE_SHIFT)))
>
> void kasan_init(void);
> void kasan_copy_shadow(pgd_t *pgdir);
^ permalink raw reply
* [PATCH v2 02/16] dt-bindings: iio: adc: add binding for X-Powers AXP PMICs ADC
From: Rob Herring @ 2018-01-11 22:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <bef3ba5e4a2c47f13fa9ba8e6fb0267b7bb15026.1515486346.git-series.quentin.schulz@free-electrons.com>
On Tue, Jan 09, 2018 at 10:33:33AM +0100, Quentin Schulz wrote:
> X-Powers PMICs have several ADC channels that can be used for different
> purposes, e.g. PMIC internal temperature, battery voltage or AC current.
>
> This is the documentation for AXP209, AXP221/223 ADC bindings.
>
> Signed-off-by: Quentin Schulz <quentin.schulz@free-electrons.com>
> ---
> Documentation/devicetree/bindings/iio/adc/axp20x_adc.txt | 39 +++++++++-
> 1 file changed, 39 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/iio/adc/axp20x_adc.txt
>
> diff --git a/Documentation/devicetree/bindings/iio/adc/axp20x_adc.txt b/Documentation/devicetree/bindings/iio/adc/axp20x_adc.txt
> new file mode 100644
> index 0000000..ed6d04e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/adc/axp20x_adc.txt
> @@ -0,0 +1,39 @@
> +* X-Powers AXP ADC bindings
> +
> +Required properties:
> + - compatible: should be one of:
> + - "x-powers,axp20x-adc",
> + - "x-powers,axp22x-adc",
> + - #io-channel-cells: should be 1,
> +
> +Example:
> +
> +&axp22x {
> + axp_adc: axp-adc {
adc {
With that,
Reviewed-by: Rob Herring <robh@kernel.org>
> + compatible = "x-powers,axp22x-adc";
> + #io-channel-cells = <1>;
> + };
> +};
> +
> +ADC channels and their indexes per variant:
> +
> +AXP209
> +------
> + 0 | acin_v
> + 1 | acin_i
> + 2 | vbus_v
> + 3 | vbus_i
> + 4 | pmic_temp
> + 5 | gpio0_v
> + 6 | gpio1_v
> + 7 | ipsout_v
> + 8 | batt_v
> + 9 | batt_chrg_i
> +10 | batt_dischrg_i
> +
> +AXP22x
> +------
> + 0 | pmic_temp
> + 1 | batt_v
> + 2 | batt_chrg_i
> + 3 | batt_dischrg_i
> --
> git-series 0.9.1
^ permalink raw reply
* [PATCH v2 07/16] dt-bindings: iio: adc: axp20x_adc: add AXP813 variant
From: Rob Herring @ 2018-01-11 22:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <64b538aadf075ba07e567d9a9db865b64c97fbfc.1515486346.git-series.quentin.schulz@free-electrons.com>
On Tue, Jan 09, 2018 at 10:33:38AM +0100, Quentin Schulz wrote:
> AXP813 is now supported so add documentation for this compatible.
>
> Signed-off-by: Quentin Schulz <quentin.schulz@free-electrons.com>
> ---
> Documentation/devicetree/bindings/iio/adc/axp20x_adc.txt | 9 +++++++++-
> 1 file changed, 9 insertions(+)
You can just squash this into the patch #2.
Either way,
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH V4 1/2] clk: imx: imx7d: add the snvs clock
From: Rob Herring @ 2018-01-11 22:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1515491526-14060-1-git-send-email-Anson.Huang@nxp.com>
On Tue, Jan 09, 2018 at 05:52:05PM +0800, Anson Huang wrote:
> According to the i.MX7D Reference Manual,
> SNVS block has a clock gate, accessing SNVS block
> would need this clock gate to be enabled, add it
> into clock tree so that SNVS module driver can
> operate this clock gate.
>
> Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
> Acked-by: Dong Aisheng <aisheng.dong@nxp.com>
> Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
> ---
> drivers/clk/imx/clk-imx7d.c | 1 +
> include/dt-bindings/clock/imx7d-clock.h | 3 ++-
> 2 files changed, 3 insertions(+), 1 deletion(-)
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH V4 2/2] ARM: dts: imx7s: add snvs rtc clock
From: Rob Herring @ 2018-01-11 22:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1515491526-14060-2-git-send-email-Anson.Huang@nxp.com>
On Tue, Jan 09, 2018 at 05:52:06PM +0800, Anson Huang wrote:
> Add i.MX7 SNVS RTC clock.
>
> Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
> ---
> change since v3:
> add optional for clocks in binding doc statement.
> Documentation/devicetree/bindings/crypto/fsl-sec4.txt | 17 +++++++++++++++++
> arch/arm/boot/dts/imx7s.dtsi | 2 ++
> 2 files changed, 19 insertions(+)
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH 00/10] perf tools: Add support for CoreSight trace decoding
From: Mathieu Poirier @ 2018-01-11 22:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180111154942.37120115a94cc77d8f336368@arm.com>
On 11 January 2018 at 14:49, Kim Phillips <kim.phillips@arm.com> wrote:
> On Thu, 11 Jan 2018 14:11:00 -0700
> Mathieu Poirier <mathieu.poirier@linaro.org> wrote:
>
>> On 11 January 2018 at 10:28, Kim Phillips <kim.phillips@arm.com> wrote:
>> > On Thu, 11 Jan 2018 08:45:21 -0700
>> > Mathieu Poirier <mathieu.poirier@linaro.org> wrote:
>> >
>> >> On 11 January 2018 at 05:23, Mark Brown <broonie@kernel.org> wrote:
>> >> > On Wed, Jan 10, 2018 at 06:08:21PM -0600, Kim Phillips wrote:
>> >> >> Mathieu Poirier <mathieu.poirier@linaro.org> wrote:
>> >> >
>> >> >> > Instructions on how to build and install the openCSD library are provided
>> >> >> > in the HOWTO.md of the project repository.
>> >> >
>> >> >> Usually when a perf builder sees something they need "on," they - or,
>> >> >> at least I - start querying the host's package manager for something
>> >> >> that provides it (e.g., apt search/install libopencsd), but since no
>> >> >> distro provides libopencsd, this is bad because it misleads the user.
>> >> >
>> >> > It's on the radar to push this at distros fairly soon.
>> >
>> > Adding packages to distros takes years, this patchset is being
>> > submitted for inclusion *now*. So until then, it would greatly
>> > facilitate users if the relevant libopencsd source files were
>> > self-contained within perf from the get go.
>>
>> I do not agree with you on the front that it takes years. On the flip
>> side it would take a significant amount of time and effort to refactor
>> the openCSD library so that it can be added to the kernel tree. This
>
> The dtc wasn't refactored before it was added to the kernel tree.
>
>> patchset is available now with a solution that follows what has
>> already been done for dozens of other external library. There is no
>> point in delaying the inclusion of the functionality when an
>> end-to-end solution exists.
>
> See above: I'm not necessarily suggesting the code get refactored.
>
>> >> > Part of the
>> >> > discussion was wanting to get things to the point where the tools using
>> >> > the library were far enough along that we could be reasonably sure that
>> >
>> > Curious, what other tools are there?
>>
>> Ask around at ARM.
>
> I'm asking the person that claimed it.
>
>> >> > there weren't any problems that were going to require ABI breaks to fix
>> >> > before pushing the library at distros since ABI churn isn't nice for
>> >> > packagers to deal with.
>> >
>> > Why make perf the guinea pig? Whatever, this doesn't preclude
>> > adding the code into the tree; it can be removed years from now when
>> > libopencsd becomes ubiquitous among distros.
>>
>> The same can be said about proceeding the other way around - the
>> openCSD library can be added to the kernel tree later if it is deemed
>> necessary. Until then I really don't see why we'd prevent people from
>> accessing the functionality.
>
> Again, I'm not suggesting the code be refactored...
>
>> >> > There's also a bit of a chicken and egg problem
>> >> > in that it's a lot easier to get distros to package libraries that have
>> >> > users available (some are not really bothered about this of course but
>> >> > it still helps).
>> >>
>> >> Moreover including in the kernel tree every library that can
>> >> potentially be used by the perf tools simply doesn't scale.
>> >
>> > This is a trace decoder library we're talking about: there are no
>> > others in perf's system features autodetection list. And why wouldn't
>> > adding such libraries scale?
>>
>> I don't see why a decoder library and say, libelf, need to be treated
>> differently.
>
> libelf is a mature library based on an industry-wide standard, not to
> mention already packaged by most (all?) distros.
>
>> >> The perf
>> >> tools project has come up with a very cleaver way to deal with
>> >> external dependencies and I don't see why the OpenCSD library should
>> >> be different.
>> >
>> > Again, the opencsd library is a decoder library: this patchseries adds
>> > it as a package dependency (when it isn't even a package in any
>> > distro), and it's different in that it's the first decoder library to
>> > be submitted as an external dependency (i.e., not fully built-in, like
>> > Intel's, or even the Arm SPE's pending submission).
>>
>> I don't see why we absolutely need to do exactly the same as Intel.
>> The library is public and this patchset neatly integrates it with the
>> perf tools.
>
> We don't, but it'd be more efficient, upstream-acceptance-wise, but as
> you brought up above, we wouldn't be able to since we'd have to rewrite
> libopencsd to conform to upstream codingstyle, etc., so I'm suggesting
> we might look at a better enablement strategy like how the dtc works.
>
> It'd be nice if the upstream maintainers would comment on what would be
> acceptable instead of us going back and forth between each other.
Agreed.
>
>> >> >> Keeping the library external will also inevitably introduce more
>> >> >> source level synchronization problems because the perf sources being
>> >> >> built may not be compatible with their version of the library, whether
>> >> >> due to new features like new trace hardware support, or API changes.
>> >> >
>> >> > Perf users installing from source rather than from a package (who do
>> >> > tend to the more technical side even for kernel developers) already have
>> >> > to cope with potentially installing at least dwarf, gtk2, libaudit,
>> >> > libbfd, libelf, libnuma, libperl, libpython, libslang, libcrypto,
>> >> > libunwind, libdw-dwarf-unwind, zlib, lzma, bpf and OpenJDK depending on
>> >> > which features they want. I'm not sure that adding one more library is
>> >> > going to be the end of the world here, especially once the packaging
>> >> > starts to filter through distros. Until that happens at least people
>> >> > are no worse off for not having the feature.
>> >>
>> >> I completely agree. Just like any other package, people that want the
>> >> very latest code need to install from source.
>> >
>> > A fully-integrated solution would work better for people, e.g., how are
>> > people supposed to know what 'latest' is when there are separate,
>> > unsynchronized git repos?
>>
>> The same applies to any of the other libraries perf is working with.
>
> The packaged libraries? They are stable: they don't come in the form
> of cloning a git repo and building from scratch.
>
> The decoder libraries? They are self-contained within perf.
>
>> >> >> As Mark Brown (cc'd) mentioned on the Coresight mailing list, this may
>> >> >> be able to be done the same way the dtc is incorporated into the
>> >> >> kernel, where only its relevant sources are included and updated as
>> >> >> needed: see linux/scripts/dtc/update-dtc-source.sh.
>> >> >
>> >> > Bear in mind that we need dtc for essentially all kernel development on
>> >> > ARM and when it was introduced it was a new requirement for existing
>> >> > systems, it's a bit of a different case here where it's an optional
>> >> > feature in an optional tool.
>> >
>> > That argument applies to Intel-PT, yet its decoder is self-contained
>> > within perf: all non-x86 perf binaries are capable of decoding PT.
>> > We'd want that for Arm Coresight where perf gets statically built to
>> > run on much more constrained systems like Android.
>>
>> Traces can't be decoded properly without the support of external
>> libraries, whether we are talking about PT or CS.
>
> Not true; perf has PT decoding self-contained.
>
> Thanks,
>
> Kim
^ permalink raw reply
* [linux, dev-4.10, 6/6] drivers/hwmon: Add a driver for a generic PECI hwmon
From: Andrew Lunn @ 2018-01-11 22:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180111214035.GA14748@roeck-us.net>
> > >>+static const struct of_device_id peci_of_table[] = {
> > >>+ { .compatible = "peci-hwmon", },
> > >
> > >This does not look like a reference to some piece of hardware.
> > >
> >
> > This driver provides generic PECI hwmon function to which controller has
> > PECI HW such as Aspeed or Nuvoton BMC chip so it's not dependant on a
> > specific hardware. Should I remove this or any suggestion?
PECI seems to be an Intel thing. So at least it should be
{ .compatible = "intel,peci-hwmon", }
assuming it is actually compatible with the Intel specification.
Andrew
^ permalink raw reply
* [PATCH v3 1/7] dt-bindings: mtd: document new nand-rb property
From: Rob Herring @ 2018-01-11 22:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180109103637.23798-2-miquel.raynal@free-electrons.com>
On Tue, Jan 09, 2018 at 11:36:31AM +0100, Miquel Raynal wrote:
> There are already an atmel,rb and an allwinner,rb properties, let's not
> make other ones and instead use a generic term: nand-rb to define NAND
> chips Ready/Busy lines.
>
> Signed-off-by: Miquel Raynal <miquel.raynal@free-electrons.com>
> ---
> Documentation/devicetree/bindings/mtd/nand.txt | 1 +
> 1 file changed, 1 insertion(+)
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH v3 0/7] Marvell NAND controller rework with ->exec_op()
From: Miquel RAYNAL @ 2018-01-11 22:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87efmwb8bj.fsf@belgarion.home>
Hi Robert,
On Thu, 11 Jan 2018 18:42:56 +0100
Robert Jarzmik <robert.jarzmik@free.fr> wrote:
> Boris Brezillon <boris.brezillon@free-electrons.com> writes:
>
> Hi Boris and Miquel,
>
> > So, here is the plan: since the driver has been tested on various
> > mvebu platforms and is known to work fine on these platforms, I'd
> > like to queue the driver and the patch modifying mvebu defconfigs
> > (patches 1 to 4) for 4.16.
> That's all right.
>
> > I'll leave other patches for 4.17, which means I'd like remaining
> > bugs to be fixed during the 4.16 release cycle so that we can
> > eventually get rid of the old driver. That's really important to me
> > that we don't keep both drivers around for too long, because my
> > previous experience showed that, when you have 2 drivers for the
> > same HW, people don't switch to the new one until they're forced to
> > do it.
> >
> > Robert, are you fine with this approach? What about the tests you
> > were doing? Did you make any progress? Did you find other issues?
> So far, with the latest branch from Miquel of tip commit 12b9e62c851c
> ("ARM64: dts: marvell: use reworked NAND controller driver on Armada
> 8K"), the bad blocks issue is still there, ie :
> - the old pxa3xx driver doesn't see any bad block and mounts the
> ext2/ubifs correctly
> - barebox doesn't see any bad block
> - marvell_nand sees all (or most all) blocks as bad with
> "flash_bbt=0" in platform data, which is very surprising
>
> I'm really surprised that in your tests on the cm_x300, in a
> platform_data setup (ie. not device-tree setup), you're not seeing
> these errors ...
I have no problems with the cm_x300 board (using platform data) but
there is one big difference: the bootloader. You are using Barebox
while I am using U-Boot.
Please pull this branch which is for testing purpose [1].
There are two "HACK"s:
1/ Dump the timing registers: this is to see how Barebox does
initialize these registers. I will put these values back into my setup
and see how the board reacts.
2/ Dump the OOB area while reading. This is to see why the driver
declares all blocks as bad.
Can you please run this branch first?
Then, can you please:
- boot the old driver
- dump both NDTR[0|1] registers that should be well initialized
- boot the new driver with the values previously retrieved (you can
assign these values where exactly HACK 1/ adds the printk's).
Thank you,
Miqu?l
[1]
https://github.com/miquelraynal/linux/commits/marvell/nand-next/nfc-pxa-bug
^ permalink raw reply
* [PATCH v3 2/7] dt-bindings: mtd: add Marvell NAND controller documentation
From: Rob Herring @ 2018-01-11 22:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180109103637.23798-3-miquel.raynal@free-electrons.com>
On Tue, Jan 09, 2018 at 11:36:32AM +0100, Miquel Raynal wrote:
> Document the legacy and the new bindings for Marvell NAND controller.
>
> The pxa3xx_nand.c driver does only support legacy bindings, which are
> incomplete and inaccurate. A rework of this controller (called
> marvell_nand.c) does support both.
>
> Signed-off-by: Miquel Raynal <miquel.raynal@free-electrons.com>
> ---
> .../devicetree/bindings/mtd/marvell-nand.txt | 123 +++++++++++++++++++++
> 1 file changed, 123 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mtd/marvell-nand.txt
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH v3 0/7] Marvell NAND controller rework with ->exec_op()
From: Willy Tarreau @ 2018-01-11 22:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180109103637.23798-1-miquel.raynal@free-electrons.com>
Hi Miquel,
On Tue, Jan 09, 2018 at 11:36:30AM +0100, Miquel Raynal wrote:
> These changes have been tested on:
> - PXA3xx platform with a CM-X300 board (2kiB page NAND, 1b/512B
> strength, Hamming ECC engine) [32 bits]
> - Armada 385 DB AP (4kiB page NAND, 4b/512B, BCH ECC engine) [32 bits]
> - Armada 398 DB (4kiB page NAND, 8b/512B, BCH ECC engine using a layout
> with a last chunk different than the others) [32 bits]
> - Armada 7040 DB and Armada 8040 DB (4kiB page NAND, 4b/512B, BCH ECC
> engine) [64 bits]
> - Triax dvb-tc board (2kiB page NAND, 4b/512B, BCH ECC engine) [32 bits]
If you're interested, I have a mirabox with an armada 370 which uses the
same driver. I've not powered it up for a while but if that can be useful
I can try to find some time for this.
Just let me know
Willy
^ permalink raw reply
* [1/5] clk: divider: read-only divider can propagate rate change
From: David Lechner @ 2018-01-11 22:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180105170959.17266-2-jbrunet@baylibre.com>
On 01/05/2018 11:09 AM, Jerome Brunet wrote:
> When a divider clock has CLK_DIVIDER_READ_ONLY set, it means that the
> register shall be left un-touched, but it does not mean the clock
> should stop rate propagation if CLK_SET_RATE_PARENT is set
>
> This is properly handled in qcom clk-regmap-divider but it was not in
> the generic divider
>
> Fixes: e6d5e7d90be9 ("clk-divider: Fix READ_ONLY when divider > 1")
> Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
> ---
> drivers/clk/clk-divider.c | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
> diff --git a/drivers/clk/clk-divider.c b/drivers/clk/clk-divider.c
> index b49942b9fe50..a851d3e04c7f 100644
> --- a/drivers/clk/clk-divider.c
> +++ b/drivers/clk/clk-divider.c
> @@ -348,6 +348,7 @@ static long clk_divider_round_rate(struct clk_hw *hw, unsigned long rate,
> unsigned long *prate)
> {
> struct clk_divider *divider = to_clk_divider(hw);
> + struct clk_hw *hw_parent = clk_hw_get_parent(hw);
Very minor suggestion: This could be moved inside the if block since it is only used there.
> int bestdiv;
>
> /* if read only, just return current value */
> @@ -356,6 +357,15 @@ static long clk_divider_round_rate(struct clk_hw *hw, unsigned long rate,
> bestdiv &= div_mask(divider->width);
> bestdiv = _get_div(divider->table, bestdiv, divider->flags,
> divider->width);
> +
> + /* Even a read-only clock can propagate a rate change */
> + if (clk_hw_get_flags(hw) & CLK_SET_RATE_PARENT) {
> + if (!hw_parent)
> + return -EINVAL;
> +
> + *prate = clk_hw_round_rate(hw_parent, rate * bestdiv);
> + }
> +
> return DIV_ROUND_UP_ULL((u64)*prate, bestdiv);
> }
>
>
Tested-by: David Lechner <david@lechnology.com>
^ permalink raw reply
* [linux, dev-4.10, 6/6] drivers/hwmon: Add a driver for a generic PECI hwmon
From: Jae Hyun Yoo @ 2018-01-11 23:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180111214035.GA14748@roeck-us.net>
On 1/11/2018 1:40 PM, Guenter Roeck wrote:
> On Thu, Jan 11, 2018 at 11:47:01AM -0800, Jae Hyun Yoo wrote:
>> On 1/10/2018 1:47 PM, Guenter Roeck wrote:
>>> On Tue, Jan 09, 2018 at 02:31:26PM -0800, Jae Hyun Yoo wrote:
>>>> This commit adds driver implementation for a generic PECI hwmon.
>>>>
>>>> Signed-off-by: Jae Hyun Yoo <jae.hyun.yoo@linux.intel.com>
>
> [ ... ]
>
>>>> +
>>>> + if (priv->temp.tcontrol.valid &&
>>>> + time_before(jiffies, priv->temp.tcontrol.last_updated +
>>>> + UPDATE_INTERVAL_MIN))
>>>> + return 0;
>>>> +
>>>
>>> Is the delay necessary ? Otherwise I would suggest to drop it.
>>> It adds a lot of complexity to the driver. Also, if the user polls
>>> values more often, that is presumably on purpose.
>>>
>>
>> I was intended to reduce traffic on PECI bus because it's low speed single
>> wired bus, and temperature values don't change frequently because the value
>> is sampled and averaged in CPU itself. I'll keep this.
>>
> Then please try to move the common code into a single function.
>
That makes sense. I'll move the common code into a single function.
> [ ... ]
>
>>>> +
>>>> + rc = of_property_read_u32(np, "cpu-id", &priv->cpu_id);
>>>
>>> What entity determines cpu-id ?
>>>
>>
>> CPU ID numbering is determined by hardware SOCKET_ID strap pins. In this
>> driver implementation, cpu-id is being used as CPU client indexing.
>>
> Seems to me the necessary information to identify a given CPU should
> be provided by the PECI core. Also, there are already "cpu" nodes
> in devicetree which, if I recall correctly, may include information
> such as CPU Ids.
>
This driver is implemented to support only BMC (Baseboard Management
Controllers) chipset which is running on a separated linux kernel from a
host server system. Through a PECI connection between them, this driver
collects the host server system's CPU and DIMM temperature information
which is running on a separated OS. That could be a linux, a Windows OS
or any other OSes. I mean, there is no shared devicetree data between
them so it is why the 'cpu_id' was added into dt configuration of this
driver.
Using quite limited hardware connections such as PECI, KSC, eSPI and
SMBus, the BMC manages the host server and this hwmon is one of features
of BMC.
>>>> + if (rc || priv->cpu_id >= CPU_ID_MAX) {
>>>> + dev_err(dev, "Invalid cpu-id configuration\n");
>>>> + return rc;
>>>> + }
>>>> +
>>>> + rc = of_property_read_u32(np, "dimm-nums", &priv->dimm_nums);
>>>
>>> This is an odd devicetree attribute. Normally the number of DIMMs
>>> is dynamic. Isn't there a means to get all that information dynamically
>>> instead of having to set it through devicetree ? What if someone adds
>>> or removes a DIMM ? Who updates the devicetree ?
>>>
>>
>> It means the number of DIMM slots each CPU has, doesn't mean the number of
>> currently installed DIMM components. If a DIMM is inserted a slot, CPU
>> reports its actual temperature but on empty slot, CPU reports 0 instead of
>> reporting an error so it is the reason why this driver enumerates all DIMM
>> slots' attribute.
>>
> And there is no other means to get the number of DIMM slots per CPU ?
> It just seems to be that this is the wrong location to provide such
> information.
>
This devicetree attribute will be configured at runtime using dt overlay
based on the host server's hardware configuration which will be parsed
and managed by a userspace BMC service.
> [ ... ]
>
>>>> +
>>>> +static const struct of_device_id peci_of_table[] = {
>>>> + { .compatible = "peci-hwmon", },
>>>
>>> This does not look like a reference to some piece of hardware.
>>>
>>
>> This driver provides generic PECI hwmon function to which controller has
>> PECI HW such as Aspeed or Nuvoton BMC chip so it's not dependant on a
>> specific hardware. Should I remove this or any suggestion?
>>
>
> I don't really know enough about the system to make a recommendation.
> It seems to me that the PECI core should identify which functionality
> it supports and instantiate the necessary driver(s). Maybe there should
> be sub-nodes to the peci node with relevant information. Those sub-nodes
> should specify the supported functionality in more detail, though -
> such as indicating the supported CPU and/or DIMM sensors.
>
> Guenter
>
As I explained above, BMC and host server are running on separated OSes
so this driver cannot be (actually, doesn't need to be) directly
associated with other kernel modules in the BMC side OS for identifying
the host server system's functionality. My thought is, this driver will
use PECI only for identifying the host server's CPU and DIMM information
and the userspace BMC service could deliver any additional host server
information thru dt overlay if needed before the BMC service initiates
this driver at runtime.
Thanks a lot,
Jae
^ permalink raw reply
* [3/5] clk: divider: add divider_ro_round_rate helper
From: David Lechner @ 2018-01-11 23:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180105170959.17266-4-jbrunet@baylibre.com>
On 01/05/2018 11:09 AM, Jerome Brunet wrote:
> Like divider_round_rate, a couple a of driver are doing more or less
> the same operation to round the rate of the divider when it is read-only.
>
> We can factor this code so let's provide an helper function for this
Perhaps you could also make use of this new helper here (clk-divider.c):
const struct clk_ops clk_divider_ro_ops = {
.recalc_rate = clk_divider_recalc_rate,
.round_rate = clk_divider_round_rate,
};
EXPORT_SYMBOL_GPL(clk_divider_ro_ops);
>
> Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
> ---
> drivers/clk/clk-divider.c | 43 ++++++++++++++++++++++++++++---------------
> include/linux/clk-provider.h | 15 +++++++++++++++
> 2 files changed, 43 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/clk/clk-divider.c b/drivers/clk/clk-divider.c
> index a851d3e04c7f..3eb2b27f3513 100644
> --- a/drivers/clk/clk-divider.c
> +++ b/drivers/clk/clk-divider.c
> @@ -344,29 +344,42 @@ long divider_round_rate_parent(struct clk_hw *hw, struct clk_hw *parent,
> }
> EXPORT_SYMBOL_GPL(divider_round_rate_parent);
>
It is nice to have documentation comments on public functions. Especially
in this case where @prate is an in/out parameter and @table is optional.
> +long divider_ro_round_rate_parent(struct clk_hw *hw, struct clk_hw *parent,
> + unsigned long rate, unsigned long *prate,
> + const struct clk_div_table *table, u8 width,
> + unsigned long flags, unsigned int val)
> +{
> + int div;
> +
> + div = _get_div(table, val, flags, width);
> +
> + /* Even a read-only clock can propagate a rate change */
> + if (clk_hw_get_flags(hw) & CLK_SET_RATE_PARENT) {
> + if (!parent)
> + return -EINVAL;
> +
> + *prate = clk_hw_round_rate(parent, rate * div);
> + }
> +
> + return DIV_ROUND_UP_ULL((u64)*prate, div);
> +}
> +EXPORT_SYMBOL_GPL(divider_ro_round_rate_parent);
> +
> +
> static long clk_divider_round_rate(struct clk_hw *hw, unsigned long rate,
> unsigned long *prate)
> {
> struct clk_divider *divider = to_clk_divider(hw);
> - struct clk_hw *hw_parent = clk_hw_get_parent(hw);
> - int bestdiv;
> + u32 val;
>
> /* if read only, just return current value */
> if (divider->flags & CLK_DIVIDER_READ_ONLY) {
> - bestdiv = clk_readl(divider->reg) >> divider->shift;
> - bestdiv &= div_mask(divider->width);
> - bestdiv = _get_div(divider->table, bestdiv, divider->flags,
> - divider->width);
> -
> - /* Even a read-only clock can propagate a rate change */
> - if (clk_hw_get_flags(hw) & CLK_SET_RATE_PARENT) {
> - if (!hw_parent)
> - return -EINVAL;
> -
> - *prate = clk_hw_round_rate(hw_parent, rate * bestdiv);
> - }
> + val = clk_readl(divider->reg) >> divider->shift;
> + val &= div_mask(divider->width);
>
> - return DIV_ROUND_UP_ULL((u64)*prate, bestdiv);
> + return divider_ro_round_rate(hw, rate, prate, divider->table,
> + divider->width, divider->flags,
> + val);
> }
>
> return divider_round_rate(hw, rate, prate, divider->table,
> diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
> index 175a62a15619..eb2c3a035e98 100644
> --- a/include/linux/clk-provider.h
> +++ b/include/linux/clk-provider.h
> @@ -417,6 +417,10 @@ long divider_round_rate_parent(struct clk_hw *hw, struct clk_hw *parent,
> unsigned long rate, unsigned long *prate,
> const struct clk_div_table *table,
> u8 width, unsigned long flags);
> +long divider_ro_round_rate_parent(struct clk_hw *hw, struct clk_hw *parent,
> + unsigned long rate, unsigned long *prate,
> + const struct clk_div_table *table, u8 width,
> + unsigned long flags, unsigned int val);
> int divider_get_val(unsigned long rate, unsigned long parent_rate,
> const struct clk_div_table *table, u8 width,
> unsigned long flags);
> @@ -772,6 +776,17 @@ static inline long divider_round_rate(struct clk_hw *hw, unsigned long rate,
> rate, prate, table, width, flags);
> }
>
Same here (about documentation comment).
> +static inline long divider_ro_round_rate(struct clk_hw *hw, unsigned long rate,
> + unsigned long *prate,
> + const struct clk_div_table *table,
> + u8 width, unsigned long flags,
> + unsigned int val)
> +{
> + return divider_ro_round_rate_parent(hw, clk_hw_get_parent(hw),
> + rate, prate, table, width, flags,
> + val);
> +}
> +
> /*
> * FIXME clock api without lock protection
> */
>
^ permalink raw reply
* [linux, dev-4.10, 6/6] drivers/hwmon: Add a driver for a generic PECI hwmon
From: Jae Hyun Yoo @ 2018-01-11 23:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180111221845.GA9278@lunn.ch>
On 1/11/2018 2:18 PM, Andrew Lunn wrote:
>>>>> +static const struct of_device_id peci_of_table[] = {
>>>>> + { .compatible = "peci-hwmon", },
>>>>
>>>> This does not look like a reference to some piece of hardware.
>>>>
>>>
>>> This driver provides generic PECI hwmon function to which controller has
>>> PECI HW such as Aspeed or Nuvoton BMC chip so it's not dependant on a
>>> specific hardware. Should I remove this or any suggestion?
>
> PECI seems to be an Intel thing. So at least it should be
>
> { .compatible = "intel,peci-hwmon", }
>
> assuming it is actually compatible with the Intel specification.
>
> Andrew
>
Yes, PECI is an Intel thing but this driver is running on an ARM kernel
on Aspeed or Nuvoton chipsets for now. This driver will be monitoring a
host server's Intel CPU and DIMM which is running on a separated OS.
Thanks,
Jae
^ permalink raw reply
* [PATCH v5 01/44] dt-bindings: clock: Add new bindings for TI Davinci PLL clocks
From: David Lechner @ 2018-01-11 23:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAHCN7xL=h_g6HK2ey82r_w5qRbXg9+68Og+84YUYuePsjYd-Vg@mail.gmail.com>
On 01/11/2018 12:09 PM, Adam Ford wrote:
> On Thu, Jan 11, 2018 at 11:22 AM, David Lechner <david@lechnology.com> wrote:
>> On 01/11/2018 06:45 AM, Adam Ford wrote:
>>>
>>> On Wed, Jan 10, 2018 at 8:50 PM, David Lechner <david@lechnology.com>
>>> wrote:
>>>>
>>>> On 01/10/2018 04:24 PM, Adam Ford wrote:
>>>>>
>>>>>
>>>>>
>>>>> I am available tomorrow to build and test patches against the
>>>>> da850-evm. I just need to know which version(s) to test.
>>>>
>>>>
>>>>
>>>> Great. As per the cover letter:
>>>>
>>>> You can find a working branch with everything included in the
>>>> "common-clk-v5"
>>>> branch of https://github.com/dlech/ev3dev-kernel.git.
>>>
>>>
>>> I wasn't sure if things had changed after some of the dialog about the
>>> bindings and device tree.
>>
>>
>> Not yet. ;-)
>>
>>>
>>> Here is my log with DEBUG_LL and CONFIG_EARLY_PRINTK set :
>>>
>>> Starting kernel ...
>>>
>>> Uncompressing Linux... done, booting the kernel.
>>> Booting Linux on physical CPU 0x0
>>> Linux version 4.15.0-rc4-g8564e0f (aford at ubuntu16) (gcc version 7.2.0
>>> (Buildroot 2017.11.1-00021-g7b43660)) #2 PREEMPT Thu Jan 11 06:35:29
>>> CST 2018
>>> CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=0005317f
>>> CPU: VIVT data cache, VIVT instruction cache
>>> OF: fdt: Machine model: DA850/AM1808/OMAP-L138 EVM
>>
>>
>> OK, using device tree...
>
> Sorry, I thought I was supposed to. I retested using the board file,
> but it also resulted in a hang.
>
>>
>>
> [snip]
>>
>>
>> If you are getting to this point, you probably don't need DEBUG_LL.
>> It looks like "earlyprint" is not being passed to the command line
>> anyway, so CONFIG_EARLY_PRINTK is not actually doing anything.
>>
>>> brd: module loaded
>>> libphy: Fixed MDIO Bus: probed
>>> davinci_mdio 1e24000.mdio: failed to get device clock
>>> davinci_mdio: probe of 1e24000.mdio failed with error -2
>>
>>
>> It looks like this needs a clock-names property in the device tree.
>> Please make this change and try again:
>>
>> diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
>> index 08a9817..fd3e316 100644
>> --- a/arch/arm/boot/dts/da850.dtsi
>> +++ b/arch/arm/boot/dts/da850.dtsi
>> @@ -713,6 +713,7 @@
>> #size-cells = <0>;
>> reg = <0x224000 0x1000>;
>> clocks = <&psc1 5>;
>> + clock-names = "fck";
>> status = "disabled";
>> };
>> eth0: ethernet at 220000 {
>>
>>
> [snip]
>
> I added your copy-names entry to my device tree and we get a login prompt. :-)
>
>> I'm not sure why there is an error here. I'm using I2C0 on my board,
>> so I am fairly confident that it is not a problem introduced by this
>> series.
>>
>>> console [netcon0] enabled
>>> netconsole: network logging started
>>> davinci_emac 1e20000.ethernet: incompatible machine/device type for
>>> reading mac address
>>> hctosys: unable to open rtc device (rtc0)
>>>
>>
>> What is normally the next line after this in a working boot?
>>
>> Also please try passing "clk_ignore_unused" to the kernel command line.
>
> Here is the log. There seems to be some garbled characters that don't
> seem to appear. I'm going to double check those against the stock
> kernel.
>
>
> Starting kernel ...
>
> Uncompressing Linux... done, booting the kernel.
> Booting Linux on physical CPU 0x0
> Linux version 4.15.0-rc4-g8564e0f (aford at ubuntu16) (gcc version 7.2.0
> (Buildroot 2017.11.1-00021-g7b43660)) #2 PREEMPT Thu Jan 11 06:35:29
> CST 2018
> CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=0005317f
> CPU: VIVT data cache, VIVT instruction cache
> OF: fdt: Machine model: DA850/AM1808/OMAP-L138 EVM
> debug: ignoring loglevel setting.
> bootconsole [earlycon0] enabled
> Memory policy: Data cache writethrough
> cma: Reserved 16 MiB at 0xc2c00000
> DaVinci da850/omap-l138 variant 0x0
> On node 0 totalpages: 16384
> DMA zone: 128 pages used for memmap
> DMA zone: 0 pages reserved
> DMA zone: 16384 pages, LIFO batch:3
> random: fast init done
> pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
> pcpu-alloc: [0] 0
> Built 1 zonelists, mobility grouping on. Total pages: 16256
> Kernel command line: console=ttyS2,115200n8 root=/dev/mmcblk0p2 rw
> rootfstype=ext4 rootwait ignore_loglevel earlyprintk clk_ignore_unused
> Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)
> Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)
> Memory: 42164K/65536K available (4548K kernel code, 280K rwdata, 1044K
> rodata, 232K init, 143K bss, 6988K reserved, 16384K cma-reserved)
> Virtual kernel memory layout:
> vector : 0xffff0000 - 0xffff1000 ( 4 kB)
> fixmap : 0xffc00000 - 0xfff00000 (3072 kB)
> vmalloc : 0xc4800000 - 0xff800000 ( 944 MB)
> lowmem : 0xc0000000 - 0xc4000000 ( 64 MB)
> modules : 0xbf000000 - 0xc0000000 ( 16 MB)
> .text : 0x(ptrval) - 0x(ptrval) (4550 kB)
> .init : 0x(ptrval) - 0x(ptrval) ( 232 kB)
> .data : 0x(ptrval) -&?p`? rval) Qm^?`} b ? $\???? ?! ?
> "V ? ???@ B- d?????}bf ?f? i?console [ttyS2] enabled
> console [ttyS2] enabled??F 0x(ptrval) ( 144 kB)
> bootconsole [earlycon0] disabledObjects=0, CP&?p^?-?Mdes=1
> bootconsole [earlycon0] disabledb ?f? i?a ?F $\????
> brd: module loaded??} ??B
> libphy: Fixed MDIO Bus: probed &?p^?-?I
> davinci_mdio 1e24000.mdio: davinci mdio revision 1.5, bus freq 2200000
> a- R? /^???? ???v at a??.???? ^\?`&?`l??f ?????M??? ?E ??????)?)! ?}?y
> ya bK????? ???
> davinci_mdio 1e24000.mdio: detected phy mask
> fffffffe ??I ")=M??-?)!iD????mi-??I ?k??
> ???)? r??.????i2? ?v? ?k$^????-?-!mD??q} ] ?K???? 6m?R?`? q)?M ???^??
> ??
> libphy: 1e24000.mdio:
> probed&?????a I?j?`?a?I???} 2/?p? bv VK,?q? 6M?- ? ??? ?I ??f??a?I???}
> 2 A-!?a-? ?K????!aMq- ")=I??-?-!mD??} 2 A-!?a-? ?K -? &-=M??-?-!mD?
> davinci_mdio 1e24000.mdio: phy[0]: device 1e24000.mdio:00, driver SMSC
> LAN8710/LAN8720??? I?Sm??aM?-! &??P-4RhR?
> ??-? ?K?^t@?
> i2c /dev entries driver
> davinci_mmc 1c40000.mmc: Using DMA, 4-bit mode
> NET: Registered protocol family 10
> Segment Routing with IPv6
> sit: IPv6, IPv4 and MPLS over IPv4 tunneling driver
> NET: Registered protocol family 17
> Loading compiled-in X.509 certificates
> mmc0: host does not support reading read-only switch, assuming write-enable
> mmc0: new high speed SDHC card at address b368
> mmcblk0: mmc0:b368 00000 3.75 GiB
> mmcblk0: p1 p2
> pca953x 0-0020: 0-0020 supply vcc not found, using dummy regulator
> pca953x 0-0020: failed reading register
> pca953x: probe of 0-0020 failed with error -121
> console [netcon0] enabled
> netconsole: network logging started
> davinci_emac 1e20000.ethernet: incompatible machine/device type for
> reading mac address
> hctosys: unable to open rtc device (rtc0)
> clk: Not disabling unused clocks
> vbat: disabling
> EXT4-fs (mmcblk0p2): mounted filesystem with ordered data mode. Opts: (null)
> VFS: Mounted root (ext4 filesystem) on device 179:2.
> devtmpfs: mounted
> Freeing unused kernel memory: 232K
> This architecture does not have kernel memory protection.
> EXT4-fs (mmcblk0p2): re-mounted. Opts: data=ordered
> Starting logging: OK
> Initializing random number generator... done.
> Starting network: OK
>
> Welcome to Buildroot
> buildroot login:
>
>
>>
>
> However, I get a reboot failure:
>
> umount: devtmpfs busy - remounted read-only
> EXT4-fs (mmcblk0p2): re-mounted. Opts: (null)
> The system is going down NOW!
> Sent SIGTERM to all processes
> Sent SIGKILL to all processes
> Requesting system reboot
>
> reboot: Restarting system
> Reboot failed -- System halted
>
Adam,
Did this reboot issue get resolved?
^ permalink raw reply
* [PATCH 34/38] arm: Implement thread_struct whitelist for hardened usercopy
From: Kees Cook @ 2018-01-11 23:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180111102400.GT17719@n2100.armlinux.org.uk>
On Thu, Jan 11, 2018 at 2:24 AM, Russell King - ARM Linux
<linux@armlinux.org.uk> wrote:
> On Wed, Jan 10, 2018 at 06:03:06PM -0800, Kees Cook wrote:
>> ARM does not carry FPU state in the thread structure, so it can declare
>> no usercopy whitelist at all.
>
> This comment seems to be misleading. We have stored FP state in the
> thread structure for a long time - for example, VFP state is stored
> in thread->vfpstate.hard, so we _do_ have floating point state in
> the thread structure.
>
> What I think this commit message needs to describe is why we don't
> need a whitelist _despite_ having FP state in the thread structure.
>
> At the moment, the commit message is making me think that this patch
> is wrong and will introduce a regression.
Yeah, I will improve this comment; it's not clear enough. The places
where I see state copied to/from userspace are all either static sizes
or already use bounce buffers (or both). e.g.:
err |= __copy_from_user(&hwstate->fpregs, &ufp->fpregs,
sizeof(hwstate->fpregs));
I will adjust the commit log and comment to more clearly describe the
lack of whitelisting due to all-static sized copies.
Thanks!
-Kees
--
Kees Cook
Pixel Security
^ permalink raw reply
* [PATCH] usb: dwc2: Fix endless deferral probe
From: Arnd Bergmann @ 2018-01-11 23:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7ef21b99-67c8-b246-cc9a-b7202264a7a0@i2se.com>
On Wed, Jan 10, 2018 at 1:15 PM, Stefan Wahren <stefan.wahren@i2se.com> wrote:
> Hi Arnd,
>
>
> Am 09.01.2018 um 22:33 schrieb Arnd Bergmann:
>>
>> On Tue, Jan 9, 2018 at 8:28 PM, Stefan Wahren <stefan.wahren@i2se.com>
>> wrote:
>>>
>>> The dwc2 USB driver tries to find a generic PHY first and then look
>>> for an old style USB PHY. In case of a valid generic PHY node without
>>> a PHY driver, the PHY layer will return -EPROBE_DEFER forever. So dwc2
>>> will never tries for an USB PHY.
>>>
>>> Fix this issue by finding a generic PHY and an old style USB PHY
>>> at once.
>>
>> This would fix only one of the USB controllers (dwc2), but not the others
>> that are affected. As I wrote in my suggested patch, dwc3 appears to be
>> affected the same way, and all other host drivers that call usb_add_hcd()
>> without first setting hcd->phy would suffer from this as well.
>>
>> If we go down the route of addressing it here in the hcd drivers, we
>> should
>> at least change all three of those, and hope this doesn't regress in
>> another way.
>>
>> Arnd
>
>
> i fully unterstand. But we leaving the path of "fixing a critical issue on
> BCM2835" and go to "fixing multiple USB host controller". I do this all in
> my spare time and don't have any of the other USB controller available. So
> before i proceed with any other patch i like so see some feedback from John,
> Greg or Felipe.
>
> After finalizing this patch i think the chance is little that this would be
> applied to 4.15. So i seems to me that we still revert my DT clean up patch.
Could you confirm that this simpler patch fixes the problem for you?
My feeling right now is that this would be the least invasive variant.
This is obviously a critical regression for BCM2835, but I'm fairly sure
it's just as critical for a lot of other SoCs that haven't done as much
testing on linux-next.
Hans has already verified the earlier (more complex) version, but my
analysis today has made it very likely that this one is fully sufficient
to fix all affected platforms.
Reverting all nine patches that add #phy-cells would still be an option,
but seems way more invasive at this point.
Arnd
diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
index b4964b067aec..93b55fb71d54 100644
--- a/drivers/phy/phy-core.c
+++ b/drivers/phy/phy-core.c
@@ -410,6 +410,10 @@ static struct phy *_of_phy_get(struct device_node
*np, int index)
if (ret)
return ERR_PTR(-ENODEV);
+ /* This phy type handled by the usb-phy subsystem for now */
+ if (of_device_is_compatible(np, "usb-nop-xceiv"))
+ return ERR_PTR(-ENODEV);
+
mutex_lock(&phy_provider_mutex);
phy_provider = of_phy_provider_lookup(args.np);
if (IS_ERR(phy_provider) || !try_module_get(phy_provider->owner)) {
^ permalink raw reply related
* [linux, dev-4.10, 6/6] drivers/hwmon: Add a driver for a generic PECI hwmon
From: Andrew Lunn @ 2018-01-11 23:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <463412a8-ad34-264d-0f44-bd383f100b44@linux.intel.com>
On Thu, Jan 11, 2018 at 03:14:37PM -0800, Jae Hyun Yoo wrote:
> On 1/11/2018 2:18 PM, Andrew Lunn wrote:
> >>>>>+static const struct of_device_id peci_of_table[] = {
> >>>>>+ { .compatible = "peci-hwmon", },
> >>>>
> >>>>This does not look like a reference to some piece of hardware.
> >>>>
> >>>
> >>>This driver provides generic PECI hwmon function to which controller has
> >>>PECI HW such as Aspeed or Nuvoton BMC chip so it's not dependant on a
> >>>specific hardware. Should I remove this or any suggestion?
> >
> >PECI seems to be an Intel thing. So at least it should be
> >
> > { .compatible = "intel,peci-hwmon", }
> >
> >assuming it is actually compatible with the Intel specification.
> >
> > Andrew
> >
>
> Yes, PECI is an Intel thing but this driver is running on an ARM kernel on
> Aspeed or Nuvoton chipsets for now. This driver will be monitoring a host
> server's Intel CPU and DIMM which is running on a separated OS.
Hi Jae
You need to be careful with the name then. You should not claim the
name 'peci' in case somebody actually implements a PECI driver which
is compatible with Intel PECI.
However, looking at other comments, it seems like this part is going
away, if you turn your code into a bus driver.
Andrew
^ permalink raw reply
* [patch v15 3/4] Documentation: jtag: Add bindings for Aspeed SoC 24xx and 25xx families JTAG master driver
From: Joel Stanley @ 2018-01-11 23:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACPK8XfH-4r0mBQYA+BwvUo2+RF8igai2jy+RqTDQcxx2-acsQ@mail.gmail.com>
On Thu, Jan 11, 2018 at 9:50 AM, Joel Stanley <joel@jms.id.au> wrote:
> On Mon, Dec 25, 2017 at 3:53 AM, Oleksandr Shamray <oleksandrs@mellanox.com> wrote:
>> +jtag: jtag at 1e6e4000 {
>> + compatible = "aspeed,ast2500-jtag";
>> + reg = <0x1e6e4000 0x1c>;
>> + clocks = <&clk_apb>;
>
> We've now got a proper clock driver upstream. Can you update the
> example to match the newly added bindings?
>
> clocks = <&syscon ASPEED_CLK_APB>;
>
I think we need to ensure the reset is deasserted as well. You will need:
resets = <&syscon ASPEED_RESET_JTAG_MASTER>;
In addition, we need to make sure the reset line is deasserted in the
driver. Take a look at how I did this in the i2c driver:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=edd20e95bca4a5434f264d8ab40d729761479825
+ bus->rst = devm_reset_control_get_shared(&pdev->dev, NULL);
+ if (IS_ERR(bus->rst)) {
+ dev_err(&pdev->dev,
+ "missing or invalid reset controller device
tree entry");
+ return PTR_ERR(bus->rst);
+ }
+ reset_control_deassert(bus->rst);
Please give this a test with an upstream kernel from a fresh power on.
Cheers,
Joel
^ permalink raw reply
* [PATCH V4 00/26] PCI: deprecate pci_get_bus_and_slot()
From: Bjorn Helgaas @ 2018-01-11 23:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513661883-28662-1-git-send-email-okaya@codeaurora.org>
On Tue, Dec 19, 2017 at 12:37:36AM -0500, Sinan Kaya wrote:
> Deprecate pci_get_bus_and_slot() in favor of pci_get_domain_bus_and_slot()
> in order to remove domain 0 assumptions in the kernel.
>
> pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as
> where a PCI device is present. This restricts the device drivers to be
> reused for other domain numbers.
>
> Use pci_get_domain_bus_and_slot() with a domain number of 0 where we can't
> extract the domain number. Other places, use the actual domain number from
> the device.
>
> Changes from v3:
> * rebase to linux-next
> * drop drm i915 as it is going through the drm tip
> * commit summary cleanups
>
> Sinan Kaya (26):
I applied most of these on pci/deprecate-get-bus-and-slot for v4.16.
Details below:
> alpha/PCI: deprecate pci_get_bus_and_slot()
Applied.
> powerpc/PCI: deprecate pci_get_bus_and_slot()
Aplied with Michael's ack.
> x86/PCI: deprecate pci_get_bus_and_slot()
> ata: deprecate pci_get_bus_and_slot()
> agp: nvidia: deprecate pci_get_bus_and_slot()
> edd: deprecate pci_get_bus_and_slot()
> ibft: deprecate pci_get_bus_and_slot()
> drm/gma500: deprecate pci_get_bus_and_slot()
> drm/nouveau: deprecate pci_get_bus_and_slot()
Applied.
> Drivers: ide: deprecate pci_get_bus_and_slot()
Applied with David's ack.
> iommu/amd: deprecate pci_get_bus_and_slot()
Applied with Gary's informal approval converted to
Reviewed-by: Gary R Hook <gary.hook@amd.com>.
> powerpc/powermac: deprecate pci_get_bus_and_slot()
Applied.
> bnx2x: deprecate pci_get_bus_and_slot()
> pch_gbe: deprecate pci_get_bus_and_slot()
Applied with David's ack.
> PCI: cpqhp: deprecate pci_get_bus_and_slot()
> PCI: ibmphp: deprecate pci_get_bus_and_slot()
Applied.
> PCI/quirks: deprecate pci_get_bus_and_slot()
> PCI/syscall: deprecate pci_get_bus_and_slot()
Applied (squashed together).
> xen: deprecate pci_get_bus_and_slot()
Applied.
> openprom: deprecate pci_get_bus_and_slot()
Applied with David's ack.
> backlight: deprecate pci_get_bus_and_slot()
Dropped because Lee applied it.
> video: fbdev: intelfb: deprecate pci_get_bus_and_slot()
> video: fbdev: nvidia: deprecate pci_get_bus_and_slot()
> video: fbdev: riva: deprecate pci_get_bus_and_slot()
Applied with Bartlomiej's ack.
> i7300_idle: remove unused file
Dropped because Greg KH picked it up.
> PCI: Remove pci_get_bus_and_slot() function
Deferred so pull requests during the merge window can happen in any
order. We can remove it at the end of the merge window or during the
next cycle.
Bjorn
^ permalink raw reply
* PM regression in next
From: Tony Lindgren @ 2018-01-12 0:01 UTC (permalink / raw)
To: linux-arm-kernel
Hi all,
I'm seeing a considerable idle power consumption regression in
Linux next, with power consumption for my idle test system going
to 17.5mW compared to the usual 8mW on my test device.
Git bisect points to merge commit e130bc1d00a4 ("Merge branch
'akpm-current/current'") being the first bad commit.
I have also verified that commit 70286688e5ad ("ipc/mqueue.c:
have RT tasks queue in by priority in wq_add()") is good, and
commit e2d7fe89e8ae ("Merge remote-tracking branch
'init_task/init_task'") is good.
Any ideas?
Regards,
Tony
^ permalink raw reply
* [PATCHv2] ARM: dts: Update ti-sysc data for existing users
From: Tony Lindgren @ 2018-01-12 0:06 UTC (permalink / raw)
To: linux-arm-kernel
Let's update the existing users with features and clock data as
specified in the binding. This is currently the smartreflex for most
part, and also few omap4 modules with no child device driver like
mcasp, abe iss and gfx.
Note that we had few mistakes that did not get noticed as we're still
probing the SmartReflex driver with legacy platform data and using
"ti,hwmods" legacy property for ti-sysc driver.
So let's fix the omap4 and dra7 smartreflex registers as there is no
no revision register.
And on omap4, the mcasp module has a revision register according to
the TRM.
And for omap34xx we need a different configuration compared to 36xx.
And the smartreflex on 3517 we've always kept disabled so let's
remove any references to it.
Signed-off-by: Tony Lindgren <tony@atomide.com>
---
Here's this one again, turns out more smartreflex fixes were needed
---
arch/arm/boot/dts/am3517.dtsi | 4 --
arch/arm/boot/dts/dra7.dtsi | 26 +++++++---
arch/arm/boot/dts/omap3.dtsi | 14 ------
arch/arm/boot/dts/omap34xx.dtsi | 39 +++++++++++++++
arch/arm/boot/dts/omap36xx.dtsi | 46 ++++++++++++++++++
arch/arm/boot/dts/omap4.dtsi | 104 +++++++++++++++++++++++++++++++++++-----
6 files changed, 198 insertions(+), 35 deletions(-)
diff --git a/arch/arm/boot/dts/am3517.dtsi b/arch/arm/boot/dts/am3517.dtsi
--- a/arch/arm/boot/dts/am3517.dtsi
+++ b/arch/arm/boot/dts/am3517.dtsi
@@ -99,9 +99,5 @@
status = "disabled";
};
-&smartreflex_mpu_iva {
- status = "disabled";
-};
-
/include/ "am35xx-clocks.dtsi"
/include/ "omap36xx-am35xx-omap3430es2plus-clocks.dtsi"
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -7,6 +7,8 @@
* Based on "omap4.dtsi"
*/
+#include <dt-bindings/bus/ti-sysc.h>
+#include <dt-bindings/clock/dra7.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/pinctrl/dra.h>
#include <dt-bindings/clock/dra7.h>
@@ -1523,9 +1525,15 @@
target-module at 4a0dd000 {
compatible = "ti,sysc-omap4-sr", "ti,sysc";
ti,hwmods = "smartreflex_core";
- reg = <0x4a0dd000 0x4>,
- <0x4a0dd008 0x4>;
- reg-names = "rev", "sysc";
+ reg = <0x4a0dd038 0x4>;
+ reg-names = "sysc";
+ ti,sysc-mask = <SYSC_OMAP3_SR_ENAWAKEUP>;
+ ti,sysc-sidle = <SYSC_IDLE_FORCE>,
+ <SYSC_IDLE_NO>,
+ <SYSC_IDLE_SMART>,
+ <SYSC_IDLE_SMART_WKUP>;
+ clocks = <&coreaon_clkctrl DRA7_SMARTREFLEX_CORE_CLKCTRL 0>;
+ clock-names = "fck";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0 0x4a0dd000 0x001000>;
@@ -1536,9 +1544,15 @@
target-module at 4a0d9000 {
compatible = "ti,sysc-omap4-sr", "ti,sysc";
ti,hwmods = "smartreflex_mpu";
- reg = <0x4a0d9000 0x4>,
- <0x4a0d9008 0x4>;
- reg-names = "rev", "sysc";
+ reg = <0x4a0d9038 0x4>;
+ reg-names = "sysc";
+ ti,sysc-mask = <SYSC_OMAP3_SR_ENAWAKEUP>;
+ ti,sysc-sidle = <SYSC_IDLE_FORCE>,
+ <SYSC_IDLE_NO>,
+ <SYSC_IDLE_SMART>,
+ <SYSC_IDLE_SMART_WKUP>;
+ clocks = <&coreaon_clkctrl DRA7_SMARTREFLEX_MPU_CLKCTRL 0>;
+ clock-names = "fck";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0 0x4a0d9000 0x001000>;
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -587,20 +587,6 @@
dma-names = "rx";
};
- smartreflex_core: smartreflex at 480cb000 {
- compatible = "ti,omap3-smartreflex-core";
- ti,hwmods = "smartreflex_core";
- reg = <0x480cb000 0x400>;
- interrupts = <19>;
- };
-
- smartreflex_mpu_iva: smartreflex at 480c9000 {
- compatible = "ti,omap3-smartreflex-mpu-iva";
- ti,hwmods = "smartreflex_mpu_iva";
- reg = <0x480c9000 0x400>;
- interrupts = <18>;
- };
-
timer1: timer at 48318000 {
compatible = "ti,omap3430-timer";
reg = <0x48318000 0x400>;
diff --git a/arch/arm/boot/dts/omap34xx.dtsi b/arch/arm/boot/dts/omap34xx.dtsi
--- a/arch/arm/boot/dts/omap34xx.dtsi
+++ b/arch/arm/boot/dts/omap34xx.dtsi
@@ -8,6 +8,7 @@
* kind, whether express or implied.
*/
+#include <dt-bindings/bus/ti-sysc.h>
#include <dt-bindings/media/omap3-isp.h>
#include "omap3.dtsi"
@@ -61,6 +62,44 @@
compatible = "ti,omap34xx-bandgap";
#thermal-sensor-cells = <0>;
};
+
+ target-module at 480cb000 {
+ compatible = "ti,sysc-omap3430-sr", "ti,sysc";
+ ti,hwmods = "smartreflex_core";
+ reg = <0x480cb024 0x4>;
+ reg-names = "sysc";
+ ti,sysc-mask = <SYSC_OMAP2_CLOCKACTIVITY>;
+ clocks = <&sr2_fck>;
+ clock-names = "fck";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0 0x480cb000 0x001000>;
+
+ smartreflex_core: smartreflex at 0 {
+ compatible = "ti,omap3-smartreflex-core";
+ reg = <0 0x400>;
+ interrupts = <19>;
+ };
+ };
+
+ target-module at 480c9000 {
+ compatible = "ti,sysc-omap3430-sr", "ti,sysc";
+ ti,hwmods = "smartreflex_mpu_iva";
+ reg = <0x480c9024 0x4>;
+ reg-names = "sysc";
+ ti,sysc-mask = <SYSC_OMAP2_CLOCKACTIVITY>;
+ clocks = <&sr1_fck>;
+ clock-names = "fck";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0 0x480c9000 0x001000>;
+
+ smartreflex_mpu_iva: smartreflex at 480c9000 {
+ compatible = "ti,omap3-smartreflex-mpu-iva";
+ reg = <0 0x400>;
+ interrupts = <18>;
+ };
+ };
};
thermal_zones: thermal-zones {
diff --git a/arch/arm/boot/dts/omap36xx.dtsi b/arch/arm/boot/dts/omap36xx.dtsi
--- a/arch/arm/boot/dts/omap36xx.dtsi
+++ b/arch/arm/boot/dts/omap36xx.dtsi
@@ -8,6 +8,7 @@
* kind, whether express or implied.
*/
+#include <dt-bindings/bus/ti-sysc.h>
#include <dt-bindings/media/omap3-isp.h>
#include "omap3.dtsi"
@@ -93,6 +94,51 @@
compatible = "ti,omap36xx-bandgap";
#thermal-sensor-cells = <0>;
};
+
+ target-module at 480cb000 {
+ compatible = "ti,sysc-omap3630-sr", "ti,sysc";
+ ti,hwmods = "smartreflex_core";
+ reg = <0x480cb038 0x4>;
+ reg-names = "sysc";
+ ti,sysc-mask = <SYSC_OMAP3_SR_ENAWAKEUP>;
+ ti,sysc-sidle = <SYSC_IDLE_FORCE>,
+ <SYSC_IDLE_NO>,
+ <SYSC_IDLE_SMART>;
+ clocks = <&sr2_fck>;
+ clock-names = "fck";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0 0x480cb000 0x001000>;
+
+ smartreflex_core: smartreflex at 0 {
+ compatible = "ti,omap3-smartreflex-core";
+ reg = <0 0x400>;
+ interrupts = <19>;
+ };
+ };
+
+ target-module at 480c9000 {
+ compatible = "ti,sysc-omap3630-sr", "ti,sysc";
+ ti,hwmods = "smartreflex_mpu_iva";
+ reg = <0x480c9038 0x4>;
+ reg-names = "sysc";
+ ti,sysc-mask = <SYSC_OMAP3_SR_ENAWAKEUP>;
+ ti,sysc-sidle = <SYSC_IDLE_FORCE>,
+ <SYSC_IDLE_NO>,
+ <SYSC_IDLE_SMART>;
+ clocks = <&sr1_fck>;
+ clock-names = "fck";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0 0x480c9000 0x001000>;
+
+
+ smartreflex_mpu_iva: smartreflex at 480c9000 {
+ compatible = "ti,omap3-smartreflex-mpu-iva";
+ reg = <0 0x400>;
+ interrupts = <18>;
+ };
+ };
};
thermal_zones: thermal-zones {
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -6,6 +6,8 @@
* published by the Free Software Foundation.
*/
+#include <dt-bindings/bus/ti-sysc.h>
+#include <dt-bindings/clock/omap4.h>
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/pinctrl/omap.h>
@@ -398,6 +400,13 @@
reg = <0x48076000 0x4>,
<0x48076010 0x4>;
reg-names = "rev", "sysc";
+ ti,sysc-mask = <SYSC_OMAP4_SOFTRESET>;
+ ti,sysc-sidle = <SYSC_IDLE_FORCE>,
+ <SYSC_IDLE_NO>,
+ <SYSC_IDLE_SMART>,
+ <SYSC_IDLE_SMART_WKUP>;
+ clocks = <&l4_per_clkctrl OMAP4_SLIMBUS2_CLKCTRL 0>;
+ clock-names = "fck";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0 0x48076000 0x001000>;
@@ -468,9 +477,15 @@
target-module at 4a0db000 {
compatible = "ti,sysc-omap4-sr", "ti,sysc";
ti,hwmods = "smartreflex_iva";
- reg = <0x4a0db000 0x4>,
- <0x4a0db008 0x4>;
- reg-names = "rev", "sysc";
+ reg = <0x4a0db038 0x4>;
+ reg-names = "sysc";
+ ti,sysc-mask = <SYSC_OMAP3_SR_ENAWAKEUP>;
+ ti,sysc-sidle = <SYSC_IDLE_FORCE>,
+ <SYSC_IDLE_NO>,
+ <SYSC_IDLE_SMART>,
+ <SYSC_IDLE_SMART_WKUP>;
+ clocks = <&l4_ao_clkctrl OMAP4_SMARTREFLEX_IVA_CLKCTRL 0>;
+ clock-names = "fck";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0 0x4a0db000 0x001000>;
@@ -485,9 +500,15 @@
target-module at 4a0dd000 {
compatible = "ti,sysc-omap4-sr", "ti,sysc";
ti,hwmods = "smartreflex_core";
- reg = <0x4a0dd000 0x4>,
- <0x4a0dd008 0x4>;
- reg-names = "rev", "sysc";
+ reg = <0x4a0dd038 0x4>;
+ reg-names = "sysc";
+ ti,sysc-mask = <SYSC_OMAP3_SR_ENAWAKEUP>;
+ ti,sysc-sidle = <SYSC_IDLE_FORCE>,
+ <SYSC_IDLE_NO>,
+ <SYSC_IDLE_SMART>,
+ <SYSC_IDLE_SMART_WKUP>;
+ clocks = <&l4_ao_clkctrl OMAP4_SMARTREFLEX_CORE_CLKCTRL 0>;
+ clock-names = "fck";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0 0x4a0dd000 0x001000>;
@@ -502,9 +523,15 @@
target-module at 4a0d9000 {
compatible = "ti,sysc-omap4-sr", "ti,sysc";
ti,hwmods = "smartreflex_mpu";
- reg = <0x4a0d9000 0x4>,
- <0x4a0d9008 0x4>;
- reg-names = "rev", "sysc";
+ reg = <0x4a0d9038 0x4>;
+ reg-names = "sysc";
+ ti,sysc-mask = <SYSC_OMAP3_SR_ENAWAKEUP>;
+ ti,sysc-sidle = <SYSC_IDLE_FORCE>,
+ <SYSC_IDLE_NO>,
+ <SYSC_IDLE_SMART>,
+ <SYSC_IDLE_SMART_WKUP>;
+ clocks = <&l4_ao_clkctrl OMAP4_SMARTREFLEX_MPU_CLKCTRL 0>;
+ clock-names = "fck";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0 0x4a0d9000 0x001000>;
@@ -725,6 +752,18 @@
reg = <0x52000000 0x4>,
<0x52000010 0x4>;
reg-names = "rev", "sysc";
+ ti,sysc-mask = <SYSC_OMAP4_SOFTRESET>;
+ ti,sysc-midle = <SYSC_IDLE_FORCE>,
+ <SYSC_IDLE_NO>,
+ <SYSC_IDLE_SMART>,
+ <SYSC_IDLE_SMART_WKUP>;
+ ti,sysc-sidle = <SYSC_IDLE_FORCE>,
+ <SYSC_IDLE_NO>,
+ <SYSC_IDLE_SMART>,
+ <SYSC_IDLE_SMART_WKUP>;
+ ti,sysc-delay-us = <2>;
+ clocks = <&iss_clkctrl OMAP4_ISS_CLKCTRL 0>;
+ clock-names = "fck";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0 0x52000000 0x1000000>;
@@ -829,8 +868,15 @@
target-module at 40128000 {
compatible = "ti,sysc-mcasp", "ti,sysc";
ti,hwmods = "mcasp";
- reg = <0x40128004 0x4>;
- reg-names = "sysc";
+ reg = <0x40128000 0x4>,
+ <0x40128004 0x4>;
+ reg-names = "rev", "sysc";
+ ti,sysc-sidle = <SYSC_IDLE_FORCE>,
+ <SYSC_IDLE_NO>,
+ <SYSC_IDLE_SMART>,
+ <SYSC_IDLE_SMART_WKUP>;
+ clocks = <&abe_clkctrl OMAP4_MCASP_CLKCTRL 0>;
+ clock-names = "fck";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x00000000 0x40128000 0x1000>, /* MPU */
@@ -850,6 +896,13 @@
reg = <0x4012c000 0x4>,
<0x4012c010 0x4>;
reg-names = "rev", "sysc";
+ ti,sysc-mask = <SYSC_OMAP4_SOFTRESET>;
+ ti,sysc-sidle = <SYSC_IDLE_FORCE>,
+ <SYSC_IDLE_NO>,
+ <SYSC_IDLE_SMART>,
+ <SYSC_IDLE_SMART_WKUP>;
+ clocks = <&abe_clkctrl OMAP4_SLIMBUS1_CLKCTRL 0>;
+ clock-names = "fck";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x00000000 0x4012c000 0x1000>, /* MPU */
@@ -864,6 +917,15 @@
reg = <0x401f1000 0x4>,
<0x401f1010 0x4>;
reg-names = "rev", "sysc";
+ ti,sysc-midle = <SYSC_IDLE_FORCE>,
+ <SYSC_IDLE_NO>,
+ <SYSC_IDLE_SMART>,
+ <SYSC_IDLE_SMART_WKUP>;
+ ti,sysc-sidle = <SYSC_IDLE_FORCE>,
+ <SYSC_IDLE_NO>,
+ <SYSC_IDLE_SMART>;
+ clocks = <&abe_clkctrl OMAP4_AESS_CLKCTRL 0>;
+ clock-names = "fck";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x00000000 0x401f1000 0x1000>, /* MPU */
@@ -970,6 +1032,16 @@
reg = <0x4a10a000 0x4>,
<0x4a10a010 0x4>;
reg-names = "rev", "sysc";
+ ti,sysc-mask = <SYSC_OMAP4_SOFTRESET>;
+ ti,sysc-midle = <SYSC_IDLE_FORCE>,
+ <SYSC_IDLE_NO>,
+ <SYSC_IDLE_SMART>;
+ ti,sysc-sidle = <SYSC_IDLE_FORCE>,
+ <SYSC_IDLE_NO>,
+ <SYSC_IDLE_SMART>;
+ ti,sysc-delay-us = <2>;
+ clocks = <&iss_clkctrl OMAP4_FDIF_CLKCTRL 0>;
+ clock-names = "fck";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0 0x4a10a000 0x1000>;
@@ -1199,6 +1271,16 @@
reg = <0x5601fc00 0x4>,
<0x5601fc10 0x4>;
reg-names = "rev", "sysc";
+ ti,sysc-midle = <SYSC_IDLE_FORCE>,
+ <SYSC_IDLE_NO>,
+ <SYSC_IDLE_SMART>,
+ <SYSC_IDLE_SMART_WKUP>;
+ ti,sysc-sidle = <SYSC_IDLE_FORCE>,
+ <SYSC_IDLE_NO>,
+ <SYSC_IDLE_SMART>,
+ <SYSC_IDLE_SMART_WKUP>;
+ clocks = <&l3_gfx_clkctrl OMAP4_GPU_CLKCTRL 0>;
+ clock-names = "fck";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0 0x56000000 0x2000000>;
--
2.15.0
^ permalink raw reply
* PM regression in next
From: Andrew Morton @ 2018-01-12 0:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180112000037.GA3875@atomide.com>
On Thu, 11 Jan 2018 16:01:13 -0800 Tony Lindgren <tony@atomide.com> wrote:
> Hi all,
>
> I'm seeing a considerable idle power consumption regression in
> Linux next, with power consumption for my idle test system going
> to 17.5mW compared to the usual 8mW on my test device.
>
> Git bisect points to merge commit e130bc1d00a4 ("Merge branch
> 'akpm-current/current'") being the first bad commit.
>
> I have also verified that commit 70286688e5ad ("ipc/mqueue.c:
> have RT tasks queue in by priority in wq_add()") is good, and
> commit e2d7fe89e8ae ("Merge remote-tracking branch
> 'init_task/init_task'") is good.
Do you mean that everything up to and including 70286688e5ad
("ipc/mqueue.c: have RT tasks queue in by priority in wq_add()") is
good?
^ permalink raw reply
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