* [PATCH 3/7] pinctrl: sunxi: add support for the Allwinner H6 main pin controller
From: Rob Herring @ 2018-01-11 20:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180106042326.46519-3-icenowy@aosc.io>
On Sat, Jan 06, 2018 at 12:23:22PM +0800, Icenowy Zheng wrote:
> The Allwinner H6 SoC has two pin controllers, one main controller
> (called CPUX-PORT in user manual) and one controller in CPUs power
> domain (called CPUS-PORT in user manual).
>
> This commit introduces support for the main pin controller on H6.
>
> The pin bank A and B are not wired out and hidden from the SoC's
> documents, however it's shown that the "ATE" (an AC200 chip
> co-packaged with the H6 die) is connected to the main SoC die via these
> pin banks. The information about these banks is just copied from the BSP
> pinctrl driver, but re-formatted to fit the mainline pinctrl driver
> format.
>
> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
> ---
> .../bindings/pinctrl/allwinner,sunxi-pinctrl.txt | 4 +-
> drivers/pinctrl/sunxi/Kconfig | 4 +
> drivers/pinctrl/sunxi/Makefile | 1 +
> drivers/pinctrl/sunxi/pinctrl-sun50i-h6.c | 679 +++++++++++++++++++++
> 4 files changed, 687 insertions(+), 1 deletion(-)
> create mode 100644 drivers/pinctrl/sunxi/pinctrl-sun50i-h6.c
>
> diff --git a/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
> index 09789fdfa749..4523e658b9f2 100644
> --- a/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
> +++ b/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
> @@ -27,6 +27,7 @@ Required properties:
> "allwinner,sun50i-a64-pinctrl"
> "allwinner,sun50i-a64-r-pinctrl"
> "allwinner,sun50i-h5-pinctrl"
> + "allwinner,sun50i-h6-pinctrl"
> "nextthing,gr8-pinctrl"
>
> - reg: Should contain the register physical address and length for the
> @@ -39,7 +40,8 @@ Required properties:
>
> Note: For backward compatibility reasons, the hosc and losc clocks are only
> required if you need to use the optional input-debounce property. Any new
> -device tree should set them.
> +device tree should set them. For the pin controllers on Allwinner H6 SoC,
> +there's no APB bus gate, and the "apb" clock should be omitted.
This should be with the clocks prop definition.
Rob
^ permalink raw reply
* [PATCH 5/7] clk: sunxi-ng: add support for the Allwinner H6 CCU
From: Rob Herring @ 2018-01-11 20:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180106044918.47513-1-icenowy@aosc.io>
On Sat, Jan 06, 2018 at 12:49:16PM +0800, Icenowy Zheng wrote:
> The Allwinner H6 SoC has a CCU which has been largely rearranged.
>
> Add support for it in the sunxi-ng CCU framework.
>
> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
> ---
> .../devicetree/bindings/clock/sunxi-ccu.txt | 1 +
> drivers/clk/sunxi-ng/Kconfig | 5 +
> drivers/clk/sunxi-ng/Makefile | 1 +
> drivers/clk/sunxi-ng/ccu-sun50i-h6.c | 1206 ++++++++++++++++++++
> drivers/clk/sunxi-ng/ccu-sun50i-h6.h | 63 +
> include/dt-bindings/clock/sun50i-h6-ccu.h | 159 +++
> include/dt-bindings/reset/sun50i-h6-ccu.h | 110 ++
> 7 files changed, 1545 insertions(+)
> create mode 100644 drivers/clk/sunxi-ng/ccu-sun50i-h6.c
> create mode 100644 drivers/clk/sunxi-ng/ccu-sun50i-h6.h
> create mode 100644 include/dt-bindings/clock/sun50i-h6-ccu.h
> create mode 100644 include/dt-bindings/reset/sun50i-h6-ccu.h
[...]
> diff --git a/include/dt-bindings/clock/sun50i-h6-ccu.h b/include/dt-bindings/clock/sun50i-h6-ccu.h
> new file mode 100644
> index 000000000000..a2d534d917bb
> --- /dev/null
> +++ b/include/dt-bindings/clock/sun50i-h6-ccu.h
> @@ -0,0 +1,159 @@
> +/*
> + * Copyright (C) 2017 Icenowy Zheng <icenowy@aosc.io>
> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPL or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + * a) This file is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of the
> + * License, or (at your option) any later version.
> + *
> + * This file is distributed in the hope that 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.
> + *
> + * Or, alternatively,
> + *
> + * b) Permission is hereby granted, free of charge, to any person
> + * obtaining a copy of this software and associated documentation
> + * files (the "Software"), to deal in the Software without
> + * restriction, including without limitation the rights to use,
> + * copy, modify, merge, publish, distribute, sublicense, and/or
> + * sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following
> + * conditions:
> + *
> + * The above copyright notice and this permission notice shall be
> + * included in all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
> + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + * OTHER DEALINGS IN THE SOFTWARE.
Use SPDX license tag instead.
> + */
> +
> +#ifndef _DT_BINDINGS_CLK_SUN50I_H6_H_
> +#define _DT_BINDINGS_CLK_SUN50I_H6_H_
> +
> +#define CLK_PLL_PERIPH0 3
> +
> +#define CLK_CPUX 21
> +
> +#define CLK_DE 29
> +#define CLK_BUS_DE 30
> +#define CLK_DEINTERLACE 31
> +#define CLK_BUS_DEINTERLACE 32
> +#define CLK_GPU 33
> +#define CLK_BUS_GPU 34
> +#define CLK_CE 35
> +#define CLK_BUS_CE 36
> +#define CLK_VE 37
> +#define CLK_BUS_VE 38
> +#define CLK_EMCE 39
> +#define CLK_BUS_EMCE 40
> +#define CLK_VP9 41
> +#define CLK_BUS_VP9 42
> +#define CLK_BUS_DMA 43
> +#define CLK_BUS_MSGBOX 44
> +#define CLK_BUS_SPINLOCK 45
> +#define CLK_BUS_HSTIMER 46
> +#define CLK_AVS 47
> +#define CLK_BUS_DBG 48
> +#define CLK_BUS_PSI 49
> +#define CLK_BUS_PWM 50
> +#define CLK_BUS_IOMMU 51
> +
> +#define CLK_MBUS_DMA 53
> +#define CLK_MBUS_VE 54
> +#define CLK_MBUS_CE 55
> +#define CLK_MBUS_TS 56
> +#define CLK_MBUS_NAND 57
> +#define CLK_MBUS_CSI 58
> +#define CLK_MBUS_DEINTERLACE 59
> +
> +#define CLK_NAND0 61
> +#define CLK_NAND1 62
> +#define CLK_BUS_NAND 63
> +#define CLK_MMC0 64
> +#define CLK_MMC1 65
> +#define CLK_MMC2 66
> +#define CLK_BUS_MMC0 67
> +#define CLK_BUS_MMC1 68
> +#define CLK_BUS_MMC2 69
> +#define CLK_BUS_UART0 70
> +#define CLK_BUS_UART1 71
> +#define CLK_BUS_UART2 72
> +#define CLK_BUS_UART3 73
> +#define CLK_BUS_I2C0 74
> +#define CLK_BUS_I2C1 75
> +#define CLK_BUS_I2C2 76
> +#define CLK_BUS_I2C3 77
> +#define CLK_BUS_SCR0 78
> +#define CLK_BUS_SCR1 79
> +#define CLK_SPI0 80
> +#define CLK_SPI1 81
> +#define CLK_BUS_SPI0 82
> +#define CLK_BUS_SPI1 83
> +#define CLK_BUS_EMAC 84
> +#define CLK_TS 85
> +#define CLK_BUS_TS 86
> +#define CLK_IR_TX 87
> +#define CLK_BUS_IR_TX 88
> +#define CLK_BUS_THS 89
> +#define CLK_I2S3 90
> +#define CLK_I2S0 91
> +#define CLK_I2S1 92
> +#define CLK_I2S2 93
> +#define CLK_BUS_I2S0 94
> +#define CLK_BUS_I2S1 95
> +#define CLK_BUS_I2S2 96
> +#define CLK_BUS_I2S3 97
> +#define CLK_SPDIF 98
> +#define CLK_BUS_SPDIF 99
> +#define CLK_DMIC 100
> +#define CLK_BUS_DMIC 101
> +#define CLK_AUDIO_HUB 102
> +#define CLK_BUS_AUDIO_HUB 103
> +#define CLK_USB_OHCI0 104
> +#define CLK_USB_PHY0 105
> +#define CLK_USB_PHY1 106
> +#define CLK_USB_OHCI3 107
> +#define CLK_USB_PHY3 108
> +#define CLK_USB_HSIC_12M 109
> +#define CLK_USB_HSIC 110
> +#define CLK_BUS_OHCI0 111
> +#define CLK_BUS_OHCI3 112
> +#define CLK_BUS_EHCI0 113
> +#define CLK_BUS_XHCI 114
> +#define CLK_BUS_EHCI3 115
> +#define CLK_BUS_OTG 116
> +#define CLK_PCIE_REF_100M 117
> +#define CLK_PCIE_REF 118
> +#define CLK_PCIE_REF_OUT 119
> +#define CLK_PCIE_MAXI 120
> +#define CLK_PCIE_AUX 121
> +#define CLK_BUS_PCIE 122
> +#define CLK_HDMI 123
> +#define CLK_HDMI_CEC 124
> +#define CLK_BUS_HDMI 125
> +#define CLK_BUS_TCON_TOP 126
> +#define CLK_TCON_LCD0 127
> +#define CLK_BUS_TCON_LCD0 128
> +#define CLK_TCON_TV0 129
> +#define CLK_BUS_TCON_TV0 130
> +#define CLK_CSI_CCI 131
> +#define CLK_CSI_TOP 132
> +#define CLK_CSI_MCLK 133
> +#define CLK_BUS_CSI 134
> +#define CLK_HDCP 135
> +#define CLK_BUS_HDCP 136
> +
> +#endif /* _DT_BINDINGS_CLK_SUN50I_H6_H_ */
> diff --git a/include/dt-bindings/reset/sun50i-h6-ccu.h b/include/dt-bindings/reset/sun50i-h6-ccu.h
> new file mode 100644
> index 000000000000..d40ae3bf418f
> --- /dev/null
> +++ b/include/dt-bindings/reset/sun50i-h6-ccu.h
> @@ -0,0 +1,110 @@
> +/*
> + * Copyright (C) 2017 Icenowy Zheng <icenowy@aosc.io>
> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPL or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + * a) This file is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of the
> + * License, or (at your option) any later version.
> + *
> + * This file is distributed in the hope that 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.
> + *
> + * Or, alternatively,
> + *
> + * b) Permission is hereby granted, free of charge, to any person
> + * obtaining a copy of this software and associated documentation
> + * files (the "Software"), to deal in the Software without
> + * restriction, including without limitation the rights to use,
> + * copy, modify, merge, publish, distribute, sublicense, and/or
> + * sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following
> + * conditions:
> + *
> + * The above copyright notice and this permission notice shall be
> + * included in all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
> + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + * OTHER DEALINGS IN THE SOFTWARE.
Use SPDX license tag instead.
> + */
> +
> +#ifndef _DT_BINDINGS_RESET_SUN50I_H6_H_
> +#define _DT_BINDINGS_RESET_SUN50I_H6_H_
> +
> +#define RST_MBUS 0
> +#define RST_BUS_DE 1
> +#define RST_BUS_DEINTERLACE 2
> +#define RST_BUS_GPU 3
> +#define RST_BUS_CE 4
> +#define RST_BUS_VE 5
> +#define RST_BUS_EMCE 6
> +#define RST_BUS_VP9 7
> +#define RST_BUS_DMA 8
> +#define RST_BUS_MSGBOX 9
> +#define RST_BUS_SPINLOCK 10
> +#define RST_BUS_HSTIMER 11
> +#define RST_BUS_DBG 12
> +#define RST_BUS_PSI 13
> +#define RST_BUS_PWM 14
> +#define RST_BUS_IOMMU 15
> +#define RST_BUS_DRAM 16
> +#define RST_BUS_NAND 17
> +#define RST_BUS_MMC0 18
> +#define RST_BUS_MMC1 19
> +#define RST_BUS_MMC2 20
> +#define RST_BUS_UART0 21
> +#define RST_BUS_UART1 22
> +#define RST_BUS_UART2 23
> +#define RST_BUS_UART3 24
> +#define RST_BUS_I2C0 25
> +#define RST_BUS_I2C1 26
> +#define RST_BUS_I2C2 27
> +#define RST_BUS_I2C3 28
> +#define RST_BUS_SCR0 29
> +#define RST_BUS_SCR1 30
> +#define RST_BUS_SPI0 31
> +#define RST_BUS_SPI1 32
> +#define RST_BUS_EMAC 33
> +#define RST_BUS_TS 34
> +#define RST_BUS_IR_TX 35
> +#define RST_BUS_THS 36
> +#define RST_BUS_I2S0 37
> +#define RST_BUS_I2S1 38
> +#define RST_BUS_I2S2 39
> +#define RST_BUS_I2S3 40
> +#define RST_BUS_SPDIF 41
> +#define RST_BUS_DMIC 42
> +#define RST_BUS_AUDIO_HUB 43
> +#define RST_USB_PHY0 44
> +#define RST_USB_PHY1 45
> +#define RST_USB_PHY3 46
> +#define RST_USB_HSIC 47
> +#define RST_BUS_OHCI0 48
> +#define RST_BUS_OHCI3 49
> +#define RST_BUS_EHCI0 50
> +#define RST_BUS_XHCI 51
> +#define RST_BUS_EHCI3 52
> +#define RST_BUS_OTG 53
> +#define RST_BUS_PCIE 54
> +#define RST_PCIE_POWERUP 55
> +#define RST_BUS_HDMI 56
> +#define RST_BUS_HDMI_SUB 57
> +#define RST_BUS_TCON_TOP 58
> +#define RST_BUS_TCON_LCD0 59
> +#define RST_BUS_TCON_TV0 60
> +#define RST_BUS_CSI 61
> +#define RST_BUS_HDCP 62
> +
> +#endif /* _DT_BINDINGS_RESET_SUN50I_H6_H_ */
> --
> 2.14.2
>
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [RFC PATCH 0/2] drivers: clk: Add ZynqMP clock driver support
From: Jolly Shah @ 2018-01-11 20:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6004ad81-96f1-34d9-a037-2c355720dc08@arm.com>
Hi Sudeep,
There are 3 things:
1> IPI mailbox transport - series is already posted
https://patchwork.kernel.org/patch/10145795/
2> EEMI - Posted by me below
https://patchwork.kernel.org/patch/10150665/
3> EEMI Users
Currently posted as RFC as they are dependent on #2.
#2 doesn?t use mailbox so it is a posted as a separate series.
Thanks,
Jolly Shah
> -----Original Message-----
> From: Sudeep Holla [mailto:sudeep.holla at arm.com]
> Sent: Thursday, January 11, 2018 2:55 AM
> To: Jolly Shah <JOLLYS@xilinx.com>; michal.simek at xilinx.com; linux-
> clk at vger.kernel.org
> Cc: mturquette at baylibre.com; sboyd at codeaurora.org; Sudeep Holla
> <sudeep.holla@arm.com>; Jolly Shah <JOLLYS@xilinx.com>; linux-
> kernel at vger.kernel.org; linux-arm-kernel at lists.infradead.org
> Subject: Re: [RFC PATCH 0/2] drivers: clk: Add ZynqMP clock driver support
>
>
>
> On 08/01/18 22:16, Jolly Shah wrote:
> > Add clock driver for ZynqMP
> >
>
> Can you post the complete series in one set for easy of review. It's currently
> broken into *6 - 8* different sets by different authors and it's extremely hard to
> get the full view of how these pieces are connected and extremely misleading.
> Can someone post them collectively as you would already have it if you are
> doing some testing building on each patch set.
>
> IIUC mailbox is used for all the communication, right ?
> If so, to start with just have 2 series one for mailbox/transport and another for
> the whole protocol(eemi?) and users of it.
>
> --
> Regards,
> Sudeep
^ permalink raw reply
* [PATCH] arm64: dts: rockchip: add roc-rk3328-cc board
From: Rob Herring @ 2018-01-11 20:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180106094538.15568-1-djw@t-chip.com.cn>
On Sat, Jan 06, 2018 at 05:45:38PM +0800, djw at t-chip.com.cn wrote:
> From: Levin Du <djw@t-chip.com.cn>
>
> The roc-rk3328-cc is a credit card size single board computer using the
> Rockchip RK3328 Quad-Core ARM Cortex A53 64-Bit Processor and supporting
> up to 2GB 2133MHz LPDDR4 memory. It provides eMMC module socket, MicroSD
> Card slot, USB 2.0/3.0, Gigabit Ethernet, HDMI/CVBS, Infrared Receiver,
> SPDIF/I2S, and SPI/I2C/UART/PWM interfaces.
>
> The devicetree currently supports basic peripherals.
>
> Signed-off-by: Levin Du <djw@t-chip.com.cn>
> ---
> Documentation/devicetree/bindings/arm/rockchip.txt | 4 +
> arch/arm64/boot/dts/rockchip/Makefile | 1 +
> arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts | 313 +++++++++++++++++++++
> 3 files changed, 318 insertions(+)
> create mode 100644 arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts
>
> diff --git a/Documentation/devicetree/bindings/arm/rockchip.txt b/Documentation/devicetree/bindings/arm/rockchip.txt
> index 326d24b..0f76a62 100644
> --- a/Documentation/devicetree/bindings/arm/rockchip.txt
> +++ b/Documentation/devicetree/bindings/arm/rockchip.txt
> @@ -50,6 +50,10 @@ Rockchip platforms device tree bindings
> Required root node properties:
> - compatible = "firefly,firefly-rk3399", "rockchip,rk3399";
>
> +- Firefly roc-rk3328-cc board:
> + Required root node properties:
> + - compatible = "firefly,roc-rk3328-cc", "rockchip,rk3328";
> +
> - ChipSPARK PopMetal-RK3288 board:
> Required root node properties:
> - compatible = "chipspark,popmetal-rk3288", "rockchip,rk3288";
> diff --git a/arch/arm64/boot/dts/rockchip/Makefile b/arch/arm64/boot/dts/rockchip/Makefile
> index ce2701e..cf14b86 100644
> --- a/arch/arm64/boot/dts/rockchip/Makefile
> +++ b/arch/arm64/boot/dts/rockchip/Makefile
> @@ -1,6 +1,7 @@
> # SPDX-License-Identifier: GPL-2.0
> dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3328-evb.dtb
> dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3328-rock64.dtb
> +dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3328-roc-cc.dtb
> dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3368-evb-act8846.dtb
> dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3368-geekbox.dtb
> dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3368-orion-r68-meta.dtb
> diff --git a/arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts b/arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts
> new file mode 100644
> index 0000000..2134baf
> --- /dev/null
> +++ b/arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts
> @@ -0,0 +1,313 @@
> +/*
> + * Copyright (c) 2017 T-Chip Intelligent Technology Co., Ltd
> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPL or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + * a) This library is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of the
> + * License, or (at your option) any later version.
> + *
> + * This library is distributed in the hope that 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.
> + *
> + * Or, alternatively,
> + *
> + * b) Permission is hereby granted, free of charge, to any person
> + * obtaining a copy of this software and associated documentation
> + * files (the "Software"), to deal in the Software without
> + * restriction, including without limitation the rights to use,
> + * copy, modify, merge, publish, distribute, sublicense, and/or
> + * sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following
> + * conditions:
> + *
> + * The above copyright notice and this permission notice shall be
> + * included in all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
> + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + * OTHER DEALINGS IN THE SOFTWARE.
> + */
Use SPDX license tag.
> +
> +/dts-v1/;
> +#include "rk3328.dtsi"
> +
> +/ {
> + model = "Firefly roc-rk3328-cc";
> + compatible = "firefly,roc-rk3328-cc", "rockchip,rk3328";
> +
> + chosen {
> + stdout-path = "serial2:1500000n8";
Just checking, 1.5Mbps for console?
> + };
> +
> + gmac_clkin: external-gmac-clock {
> + compatible = "fixed-clock";
> + clock-frequency = <125000000>;
> + clock-output-names = "gmac_clkin";
> + #clock-cells = <0>;
> + };
> +
> + dc_12v: dc-12v {
> + compatible = "regulator-fixed";
> + regulator-name = "dc_12v";
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <12000000>;
> + regulator-max-microvolt = <12000000>;
> + };
> +
> + vcc_sd: sdmmc-regulator {
> + compatible = "regulator-fixed";
> + gpio = <&gpio0 30 GPIO_ACTIVE_LOW>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&sdmmc0m1_gpio>;
> + regulator-name = "vcc_sd";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + vin-supply = <&vcc_io>;
> + };
> +
> + vcc_host1_5v: vcc_otg_5v: vcc-host1-5v-regulator {
> + compatible = "regulator-fixed";
> + enable-active-high;
> + gpio = <&gpio1 RK_PD2 GPIO_ACTIVE_HIGH>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&usb20_host_drv>;
> + regulator-name = "vcc_host1_5v";
> + regulator-always-on;
> + vin-supply = <&vcc_sys>;
> + };
> +
> + vcc_sys: vcc-sys {
> + compatible = "regulator-fixed";
> + regulator-name = "vcc_sys";
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <5000000>;
> + regulator-max-microvolt = <5000000>;
> + vin-supply = <&dc_12v>;
> + };
> +
> + vcc_phy: vcc-phy-regulator {
> + compatible = "regulator-fixed";
> + regulator-name = "vcc_phy";
> + regulator-always-on;
> + regulator-boot-on;
> + };
> +};
> +
> +&cpu0 {
> + cpu-supply = <&vdd_arm>;
> +};
> +
> +&emmc {
> + bus-width = <8>;
> + cap-mmc-highspeed;
> + non-removable;
> + pinctrl-names = "default";
> + pinctrl-0 = <&emmc_clk &emmc_cmd &emmc_bus8>;
> + status = "okay";
> +};
> +
> +&gmac2io {
> + assigned-clocks = <&cru SCLK_MAC2IO>, <&cru SCLK_MAC2IO_EXT>;
> + assigned-clock-parents = <&gmac_clkin>, <&gmac_clkin>;
> + clock_in_out = "input";
> + phy-supply = <&vcc_phy>;
> + phy-mode = "rgmii";
> + pinctrl-names = "default";
> + pinctrl-0 = <&rgmiim1_pins>;
> + snps,reset-gpio = <&gpio1 RK_PC2 GPIO_ACTIVE_LOW>;
> + snps,reset-active-low;
> + snps,reset-delays-us = <0 10000 50000>;
> + tx_delay = <0x25>;
> + rx_delay = <0x11>;
> + status = "okay";
> +};
> +
> +&i2c1 {
> + status = "okay";
> +
> + rk805: rk805 at 18 {
pmic at 18
> + compatible = "rockchip,rk805";
> + reg = <0x18>;
> + interrupt-parent = <&gpio1>;
> + interrupts = <24 IRQ_TYPE_LEVEL_LOW>;
> + #clock-cells = <1>;
> + clock-output-names = "xin32k", "rk805-clkout2";
> + gpio-controller;
> + #gpio-cells = <2>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pmic_int_l>;
> + rockchip,system-power-controller;
> + wakeup-source;
> +
> + vcc1-supply = <&vcc_sys>;
> + vcc2-supply = <&vcc_sys>;
> + vcc3-supply = <&vcc_sys>;
> + vcc4-supply = <&vcc_sys>;
> + vcc5-supply = <&vcc_io>;
> + vcc6-supply = <&vcc_io>;
> +
> + regulators {
> + vdd_logic: DCDC_REG1 {
Don't use '_' in node names.
> + regulator-name = "vdd_logic";
> + regulator-min-microvolt = <712500>;
> + regulator-max-microvolt = <1450000>;
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-state-mem {
> + regulator-on-in-suspend;
> + regulator-suspend-microvolt = <1000000>;
> + };
> + };
> +
> + vdd_arm: DCDC_REG2 {
> + regulator-name = "vdd_arm";
> + regulator-min-microvolt = <712500>;
> + regulator-max-microvolt = <1450000>;
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-state-mem {
> + regulator-on-in-suspend;
> + regulator-suspend-microvolt = <950000>;
> + };
> + };
> +
> + vcc_ddr: DCDC_REG3 {
> + regulator-name = "vcc_ddr";
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-state-mem {
> + regulator-on-in-suspend;
> + };
> + };
> +
> + vcc_io: DCDC_REG4 {
> + regulator-name = "vcc_io";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-state-mem {
> + regulator-on-in-suspend;
> + regulator-suspend-microvolt = <3300000>;
> + };
> + };
> +
> + vcc_18: LDO_REG1 {
> + regulator-name = "vcc_18";
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-state-mem {
> + regulator-on-in-suspend;
> + regulator-suspend-microvolt = <1800000>;
> + };
> + };
> +
> + vcc18_emmc: LDO_REG2 {
> + regulator-name = "vcc18_emmc";
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-state-mem {
> + regulator-on-in-suspend;
> + regulator-suspend-microvolt = <1800000>;
> + };
> + };
> +
> + vdd_10: LDO_REG3 {
> + regulator-name = "vdd_10";
> + regulator-min-microvolt = <1000000>;
> + regulator-max-microvolt = <1000000>;
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-state-mem {
> + regulator-on-in-suspend;
> + regulator-suspend-microvolt = <1000000>;
> + };
> + };
> + };
> + };
> +};
> +
> +&pinctrl {
> + pmic {
> + pmic_int_l: pmic-int-l {
> + rockchip,pins = <1 RK_PD0 RK_FUNC_GPIO &pcfg_pull_up>;
> + };
> + };
> +
> + usb2 {
> + usb20_host_drv: usb20-host-drv {
> + rockchip,pins = <1 RK_PD2 RK_FUNC_GPIO &pcfg_pull_none>;
> + };
> + };
> +};
> +
> +&sdmmc {
> + bus-width = <4>;
> + cap-mmc-highspeed;
> + cap-sd-highspeed;
> + disable-wp;
> + max-frequency = <150000000>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&sdmmc0_clk &sdmmc0_cmd &sdmmc0_dectn &sdmmc0_bus4>;
> + vmmc-supply = <&vcc_sd>;
> + status = "okay";
> +};
> +
> +&tsadc {
> + status = "okay";
> +};
> +
> +&uart2 {
> + status = "okay";
> +};
> +
> +&u2phy {
> + status = "okay";
> +};
> +
> +&u2phy_host {
> + status = "okay";
> +};
> +
> +&u2phy_otg {
> + status = "okay";
> +};
> +
> +&usb20_otg {
> + status = "okay";
> +};
> +
> +&usb_host0_ehci {
> + status = "okay";
> +};
> +
> +&usb_host0_ohci {
> + status = "okay";
> +};
> +
> +&usbdrd3 {
> + status = "okay";
> +};
> +
> +&usbdrd_dwc3 {
> + dr_mode = "host";
> + status = "okay";
> +};
> --
> 2.9.2
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH linux dev-4.10 3/6] drivers/misc: Add driver for Aspeed PECI and generic PECI headers
From: Jae Hyun Yoo @ 2018-01-11 20:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1515661373.31850.31.camel@kernel.crashing.org>
On 1/11/2018 1:02 AM, Benjamin Herrenschmidt wrote:
> On Wed, 2018-01-10 at 11:18 +0100, Greg KH wrote:
>> On Tue, Jan 09, 2018 at 02:31:23PM -0800, Jae Hyun Yoo wrote:
>>> This commit adds driver implementation for Aspeed PECI. Also adds
>>> generic peci.h and peci_ioctl.h files to provide compatibility
>>> to peci drivers that can be implemented later e.g. Nuvoton's BMC
>>> SoC family.
>>
>> We don't add code that could be used "sometime in the future". Only
>> include stuff that we use now.
>>
>> Please fix up this series based on that and resubmit. There should not
>> be any need for any uapi file then, right?
>
> No Greg, I think you misunderstood (unless I misread myself).
>
> What Jae means is that since PECI is a standard and other drivers
> implementing the same ioctl interface and messages will eventually go
> upstream, instead of having the ioctl definitions in a driver specific
> locations, they go in a generic spot, as they define a generic API for
> all PECI drivers, including the one that's getting merged now.
>
> IE. This doesn't add unused stuff, it just puts the API parts of it
> into a generic location.
>
> At least that's my understanding from a, granted cursory, look at the
> patch.
>
> That said, I do have a problem with the structure definitions of the
> various packet types as they use "long" which has a variable size and
> unclear alignment. It should be using __u8, __u16 and __u32...
>
> Cheers,
> Ben.
>
Thanks for your clear explanation. That is what I actually intended to.
However, the structure definitions you and Greg pointed out need to be
corrected. I will fix it.
Thanks,
Jae
^ permalink raw reply
* [PATCH v7 2/5] dt-bindings: scsi: ufs: add document for hisi-ufs
From: Rob Herring @ 2018-01-11 20:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180106095117.67907-3-liwei213@huawei.com>
On Sat, Jan 06, 2018 at 05:51:14PM +0800, Li Wei wrote:
> add ufs node document for Hisilicon.
>
> Signed-off-by: Li Wei <liwei213@huawei.com>
> ---
> Documentation/devicetree/bindings/ufs/ufs-hisi.txt | 43 ++++++++++++++++++++++
> 1 file changed, 43 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/ufs/ufs-hisi.txt
>
> diff --git a/Documentation/devicetree/bindings/ufs/ufs-hisi.txt b/Documentation/devicetree/bindings/ufs/ufs-hisi.txt
> new file mode 100644
> index 000000000000..175693e47d6b
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/ufs/ufs-hisi.txt
> @@ -0,0 +1,43 @@
> +* Hisilicon Universal Flash Storage (UFS) Host Controller
> +
> +UFS nodes are defined to describe on-chip UFS hardware macro.
> +Each UFS Host Controller should have its own node.
> +
> +Required properties:
> +- compatible : compatible list, contains one of the following -
> + "hisilicon,hi3660-ufs", "jedec,ufs-1.1" for hisi ufs
> + host controller present on Hi36xx chipset.
> +- reg : should contain UFS register address space & UFS SYS CTRL register address,
> +- interrupt-parent : interrupt device
> +- interrupts : interrupt number
> +- clocks : List of phandle and clock specifier pairs
> +- clock-names : List of clock input name strings sorted in the same
> + order as the clocks property. "ref_clk", "phy_clk" is optional
> +- freq-table-hz : Array of <min max> operating frequencies stored in the same
> + order as the clocks property. If this property is not
> + defined or a value in the array is "0" then it is assumed
> + that the frequency is set by the parent clock or a
> + fixed rate clock source.
Doesn't the assigned-clocks binding work here? I'd suggest dropping this
until you really need it.
> +- resets : reset node register, one reset the clk and the other reset the controller
> +- reset-names : describe reset node register
> +
> +Example:
> +
> + ufs: ufs at ff3b0000 {
> + compatible = "hisilicon,hi3660-ufs", "jedec,ufs-1.1";
> + /* 0: HCI standard */
> + /* 1: UFS SYS CTRL */
> + reg = <0x0 0xff3b0000 0x0 0x1000>,
> + <0x0 0xff3b1000 0x0 0x1000>;
> + interrupt-parent = <&gic>;
> + interrupts = <GIC_SPI 278 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&crg_ctrl HI3660_CLK_GATE_UFSIO_REF>,
> + <&crg_ctrl HI3660_CLK_GATE_UFSPHY_CFG>;
> + clock-names = "ref_clk", "phy_clk";
> + freq-table-hz = <0 0>, <0 0>;
> + /* offset: 0x84; bit: 12 */
> + /* offset: 0x84; bit: 7 */
> + resets = <&crg_rst 0x84 12>,
> + <&crg_rst 0x84 7>;
> + reset-names = "rst", "assert";
> + };
> --
> 2.15.0
>
^ permalink raw reply
* [PATCH linux dev-4.10 3/6] drivers/misc: Add driver for Aspeed PECI and generic PECI headers
From: Jae Hyun Yoo @ 2018-01-11 20:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1515661583.31850.34.camel@kernel.crashing.org>
On 1/11/2018 1:06 AM, Benjamin Herrenschmidt wrote:
> On Tue, 2018-01-09 at 14:31 -0800, Jae Hyun Yoo wrote:
>> +struct peci_rd_ia_msr_msg {
>> + unsigned char target;
>> + unsigned char thread_id;
>> + unsigned short address;
>> + unsigned long value;
>> +};
>
> Those types are representing messages on the wire ?
>
> In that case those types aren't suitable. For example "long" will have
> a different size and alignment for 32 and 64-bit userspace. There are
> size-explicit userspace types available.
>
> Also I didn't see any endianness annotations in there. Is that expected
> ? IE are those wire format packets ?
>
> Cheers,
> Ben.
>
Only the 'peci_xfer_msg' struct is representing messages on the wire.
All userspace messages which is using other struct definitions will be
copied into the 'peci_xfer_msg' for each member variable in driver, but
anyway, type definitions of each member variable should be fixed as you
said. Will fix it.
Thanks,
Jae
^ permalink raw reply
* [PATCH linux dev-4.10 6/6] drivers/hwmon: Add a driver for a generic PECI hwmon
From: Jae Hyun Yoo @ 2018-01-11 20:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAK8P3a0xyQQeyDdj8UEMgdGK13jisvo5rOkGbi-wWYZA5QFSMQ@mail.gmail.com>
On 1/11/2018 5:22 AM, Arnd Bergmann wrote:
> On Thu, Jan 11, 2018 at 12:45 AM, Jae Hyun Yoo
> <jae.hyun.yoo@linux.intel.com> wrote:
>> On 1/10/2018 4:29 AM, Arnd Bergmann wrote:
>>>
>>> On Tue, Jan 9, 2018 at 11:31 PM, Jae Hyun Yoo
>>> <jae.hyun.yoo@linux.intel.com> wrote:
>>>>
>>>> This commit adds driver implementation for a generic PECI hwmon.
>>>>
>>>> Signed-off-by: Jae Hyun Yoo <jae.hyun.yoo@linux.intel.com>
>>>
>>>
>>>> +static int xfer_peci_msg(int cmd, void *pmsg)
>>>> +{
>>>> + int rc;
>>>> +
>>>> + mutex_lock(&peci_hwmon_lock);
>>>> + rc = peci_ioctl(NULL, cmd, (unsigned long)pmsg);
>>>> + mutex_unlock(&peci_hwmon_lock);
>>>> +
>>>> + return rc;
>>>> +}
>>>
>>>
>>> I said earlier that peci_ioctl() looked unused, that was obviously
>>> wrong, but what you have here
>>> is not a proper way to abstract a bus.
>>>
>>> Maybe this can be done more like an i2c bus: make the peci controller
>>> a bus device
>>> and register all known target/index pairs as devices with the peci bus
>>> type, and have
>>> them probed from DT. The driver can then bind to each of those
>>> individually.
>>> Not sure if that is getting to granular at that point, I'd have to
>>> understand better
>>> how it is expected to get used, and what the variances are between
>>> implementations.
>>>
>>
>> Thanks for sharing your opinion. In fact, this was also suggested by openbmc
>> community so I should consider of redesigning it. I'm currently thinking
>> about adding a new PECI device class as an abstract layer and any BMC
>> chipset specific driver could be attached to the PECI class driver. Then,
>> each CPU client could be registered as an individual device as you
>> suggested. Will consider your suggestion.
>
> Another idea might be to pretend that PECI was I2C. We already have a few
> drivers for hardware that is not I2C but whose software interface looks
> similar enough that it just works. No idea if that is the case for PECI, but
> xfer_peci_msg might be close enough to i2c_xfer to make it work. If you
> are able to do that, then the PECI controller would just register itself
> as an i2c controller and it can be accessed using /dev/i2c from user space
> or a high-level i2c_driver.
>
> Arnd
>
Thanks for the good idea. It looks like one of possible options. I'll
check this idea as well. :)
Thanks,
Jae
^ permalink raw reply
* [PATCH linux dev-4.10 0/6] Add support PECI and PECI hwmon drivers
From: Benjamin Herrenschmidt @ 2018-01-11 20:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180111095923.GA29233@kroah.com>
On Thu, 2018-01-11 at 10:59 +0100, Greg KH wrote:
> And, if you use it in a device, it's still totally unsupported and
> insecure. Seriously, does no one actually pay attention to the patches
> I merge in the stable trees anymore?
Yeah not sure why we aren't picking an LTC here, it could be that it's
just a dev branch, not release, Joel, what's the process in that case ?
For anything going into products, if we're going to maintain a non-
upstream branch, we should definitely stick it to an LTS release or
we'll be missing a ton of security fixes.
Cheers,
Ben.
^ permalink raw reply
* [PATCH v5 01/44] dt-bindings: clock: Add new bindings for TI Davinci PLL clocks
From: Adam Ford @ 2018-01-11 20:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <a79184c5-3e28-bbac-0783-992615d49fae@lechnology.com>
On Thu, Jan 11, 2018 at 2:04 PM, David Lechner <david@lechnology.com> wrote:
> On 01/11/2018 12:50 PM, Adam Ford wrote:
>>
>> On Thu, Jan 11, 2018 at 12:29 PM, David Lechner <david@lechnology.com>
>> wrote:
>>>
>>> If removing the "clk_ignore_unused" option causes the board to not boot,
>>> then we still have problems that need to be fixed, so please also test
>>> without this option.
>>
>>
>> Without this option, it still does not boot. Without device tree it
>> hangs after:
>>
>> [snip]
>>
>> NET: Registered protocol family 17
>> Loading compiled-in X.509 certificates
>> console [netcon0] enabled
>> netconsole: network logging started
>> davinci_emac davinci_emac.1: using random MAC addr: 5e:38:1a:1f:4f:77
>> mmc0: host does not support reading read-only switch, assuming
>> write-enable
>> hctosys: unable to open rtc device (rtc0)
>> mmc0: new high speed SDHC card at address b368
>>
>>
>> With device tree it hangs after:
>>
>> [snip]
>> 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)
>>
>>
>
> Please try this change:
>
> diff --git a/drivers/clk/davinci/psc-da850.c
> b/drivers/clk/davinci/psc-da850.c
> index 3fd6b49..a526cc2 100644
> --- a/drivers/clk/davinci/psc-da850.c
> +++ b/drivers/clk/davinci/psc-da850.c
> @@ -17,7 +17,7 @@ static const struct davinci_psc_clk_info da850_psc0_info[]
> __initconst = {
> LPSC(0, 0, tpcc0, pll0_sysclk2, LPSC_ALWAYS_ENABLED),
> LPSC(1, 0, tptc0, pll0_sysclk2, LPSC_ALWAYS_ENABLED),
> LPSC(2, 0, tptc1, pll0_sysclk2, LPSC_ALWAYS_ENABLED),
> - LPSC(3, 0, aemif, pll0_sysclk3, 0),
> + LPSC(3, 0, aemif, pll0_sysclk3, LPSC_ALWAYS_ENABLED),
> LPSC(4, 0, spi0, pll0_sysclk2, 0),
> LPSC(5, 0, mmcsd0, pll0_sysclk2, 0),
> LPSC(6, 0, aintc, pll0_sysclk4, LPSC_ALWAYS_ENABLED),
>
>
>
> If that does not work, try adding LPSC_ALWAYS_ENABLED to all of the clocks
> in this file and then eliminate them one by one until you find which one is
> preventing boot.
>
Unfortunately, that didn't work. I switch all the entries in both
tables that had a 0 to LPSC_ALWAYS_ENABLED, but no luck booting.
> If it still does not boot, there is a similar DIVCLK_ALWAYS_ENABLED flag in
> drivers/clk/davinci/pll-da850.c that you can repeat the exercise with. Add
> DIVCLK_ALWAYS_ENABLED to all of the clocks there and then eliminate it one
> by one until you find the clock that is causing the problem.
Still no good news. I switched all the entries with a 0 to
DIVCLK_ALWAYS_ENABLED and it still didn't finish booting.
I wonder if Sekhar Nori might have some suggestions. I didn't look at
the code or try to understand it. I just changed the settings.
>
adam
^ permalink raw reply
* [PATCH] ARM: dts: iwg20m: Enable cmt0
From: Fabrizio Castro @ 2018-01-11 20:59 UTC (permalink / raw)
To: linux-arm-kernel
This patch enables cmt0 support from within the iwg20m SoM dtsi.
Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
Reviewed-by: Biju Das <biju.das@bp.renesas.com>
---
arch/arm/boot/dts/r8a7743-iwg20m.dtsi | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/r8a7743-iwg20m.dtsi b/arch/arm/boot/dts/r8a7743-iwg20m.dtsi
index 75a8ca5..1d3e950 100644
--- a/arch/arm/boot/dts/r8a7743-iwg20m.dtsi
+++ b/arch/arm/boot/dts/r8a7743-iwg20m.dtsi
@@ -34,6 +34,10 @@
};
};
+&cmt0 {
+ status = "okay";
+};
+
&extal_clk {
clock-frequency = <20000000>;
};
--
2.7.4
^ permalink raw reply related
* [PATCH] ARM: dts: iwg22m: Enable cmt0
From: Fabrizio Castro @ 2018-01-11 20:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1515704379-29154-1-git-send-email-fabrizio.castro@bp.renesas.com>
This patch enables cmt0 support from within the iwg22m SoM dtsi.
Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
Reviewed-by: Biju Das <biju.das@bp.renesas.com>
---
arch/arm/boot/dts/r8a7745-iwg22m.dtsi | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/r8a7745-iwg22m.dtsi b/arch/arm/boot/dts/r8a7745-iwg22m.dtsi
index ed9a8cf..8d0a392b 100644
--- a/arch/arm/boot/dts/r8a7745-iwg22m.dtsi
+++ b/arch/arm/boot/dts/r8a7745-iwg22m.dtsi
@@ -29,6 +29,10 @@
};
};
+&cmt0 {
+ status = "okay";
+};
+
&extal_clk {
clock-frequency = <20000000>;
};
--
2.7.4
^ permalink raw reply related
* [PATCH v5 01/44] dt-bindings: clock: Add new bindings for TI Davinci PLL clocks
From: David Lechner @ 2018-01-11 21:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAHCN7x+EtQs6NHAYbVga7vU1U+qQLqOxdf+1MW6HewaT+ZF_Xg@mail.gmail.com>
On 01/11/2018 02:58 PM, Adam Ford wrote:
> On Thu, Jan 11, 2018 at 2:04 PM, David Lechner <david@lechnology.com> wrote:
>> On 01/11/2018 12:50 PM, Adam Ford wrote:
>>>
>>> On Thu, Jan 11, 2018 at 12:29 PM, David Lechner <david@lechnology.com>
>>> wrote:
>>>>
>>>> If removing the "clk_ignore_unused" option causes the board to not boot,
>>>> then we still have problems that need to be fixed, so please also test
>>>> without this option.
>>>
>>>
>>> Without this option, it still does not boot. Without device tree it
>>> hangs after:
>>>
>>> [snip]
>>>
>>> NET: Registered protocol family 17
>>> Loading compiled-in X.509 certificates
>>> console [netcon0] enabled
>>> netconsole: network logging started
>>> davinci_emac davinci_emac.1: using random MAC addr: 5e:38:1a:1f:4f:77
>>> mmc0: host does not support reading read-only switch, assuming
>>> write-enable
>>> hctosys: unable to open rtc device (rtc0)
>>> mmc0: new high speed SDHC card at address b368
>>>
>>>
>>> With device tree it hangs after:
>>>
>>> [snip]
>>> 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)
>>>
>>>
>>
>> Please try this change:
>>
>> diff --git a/drivers/clk/davinci/psc-da850.c
>> b/drivers/clk/davinci/psc-da850.c
>> index 3fd6b49..a526cc2 100644
>> --- a/drivers/clk/davinci/psc-da850.c
>> +++ b/drivers/clk/davinci/psc-da850.c
>> @@ -17,7 +17,7 @@ static const struct davinci_psc_clk_info da850_psc0_info[]
>> __initconst = {
>> LPSC(0, 0, tpcc0, pll0_sysclk2, LPSC_ALWAYS_ENABLED),
>> LPSC(1, 0, tptc0, pll0_sysclk2, LPSC_ALWAYS_ENABLED),
>> LPSC(2, 0, tptc1, pll0_sysclk2, LPSC_ALWAYS_ENABLED),
>> - LPSC(3, 0, aemif, pll0_sysclk3, 0),
>> + LPSC(3, 0, aemif, pll0_sysclk3, LPSC_ALWAYS_ENABLED),
>> LPSC(4, 0, spi0, pll0_sysclk2, 0),
>> LPSC(5, 0, mmcsd0, pll0_sysclk2, 0),
>> LPSC(6, 0, aintc, pll0_sysclk4, LPSC_ALWAYS_ENABLED),
>>
>>
>>
>> If that does not work, try adding LPSC_ALWAYS_ENABLED to all of the clocks
>> in this file and then eliminate them one by one until you find which one is
>> preventing boot.
>>
> Unfortunately, that didn't work. I switch all the entries in both
> tables that had a 0 to LPSC_ALWAYS_ENABLED, but no luck booting.
>
>> If it still does not boot, there is a similar DIVCLK_ALWAYS_ENABLED flag in
>> drivers/clk/davinci/pll-da850.c that you can repeat the exercise with. Add
>> DIVCLK_ALWAYS_ENABLED to all of the clocks there and then eliminate it one
>> by one until you find the clock that is causing the problem.
>
> Still no good news. I switched all the entries with a 0 to
> DIVCLK_ALWAYS_ENABLED and it still didn't finish booting.
>
> I wonder if Sekhar Nori might have some suggestions. I didn't look at
> the code or try to understand it. I just changed the settings.
>>
Even if a clock had another flag besides zero, you will need to add
LPSC_ALWAYS_ENABLED by or-ing it with the other flag.
diff --git a/drivers/clk/davinci/psc-da850.c b/drivers/clk/davinci/psc-da850.c
index 3fd6b49..3375df6a1 100644
--- a/drivers/clk/davinci/psc-da850.c
+++ b/drivers/clk/davinci/psc-da850.c
@@ -17,38 +17,38 @@ static const struct davinci_psc_clk_info da850_psc0_info[] __initconst = {
LPSC(0, 0, tpcc0, pll0_sysclk2, LPSC_ALWAYS_ENABLED),
LPSC(1, 0, tptc0, pll0_sysclk2, LPSC_ALWAYS_ENABLED),
LPSC(2, 0, tptc1, pll0_sysclk2, LPSC_ALWAYS_ENABLED),
- LPSC(3, 0, aemif, pll0_sysclk3, 0),
- LPSC(4, 0, spi0, pll0_sysclk2, 0),
- LPSC(5, 0, mmcsd0, pll0_sysclk2, 0),
+ LPSC(3, 0, aemif, pll0_sysclk3, LPSC_ALWAYS_ENABLED),
+ LPSC(4, 0, spi0, pll0_sysclk2, LPSC_ALWAYS_ENABLED),
+ LPSC(5, 0, mmcsd0, pll0_sysclk2, LPSC_ALWAYS_ENABLED),
LPSC(6, 0, aintc, pll0_sysclk4, LPSC_ALWAYS_ENABLED),
LPSC(7, 0, arm_rom, pll0_sysclk2, LPSC_ALWAYS_ENABLED),
- LPSC(9, 0, uart0, pll0_sysclk2, 0),
- LPSC(13, 0, pruss, pll0_sysclk2, 0),
+ LPSC(9, 0, uart0, pll0_sysclk2, LPSC_ALWAYS_ENABLED),
+ LPSC(13, 0, pruss, pll0_sysclk2, LPSC_ALWAYS_ENABLED),
LPSC(14, 0, arm, pll0_sysclk6, LPSC_ALWAYS_ENABLED),
- LPSC(15, 1, dsp, pll0_sysclk1, LPSC_FORCE | LPSC_LOCAL_RESET),
+ LPSC(15, 1, dsp, pll0_sysclk1, LPSC_FORCE | LPSC_LOCAL_RESET | LPSC_ALWAYS_ENABLED),
{ }
};
static const struct davinci_psc_clk_info da850_psc1_info[] __initconst = {
LPSC(0, 0, tpcc1, pll0_sysclk2, LPSC_ALWAYS_ENABLED),
- LPSC(1, 0, usb0, pll0_sysclk2, 0),
- LPSC(2, 0, usb1, pll0_sysclk4, 0),
- LPSC(3, 0, gpio, pll0_sysclk4, 0),
- LPSC(5, 0, emac, pll0_sysclk4, 0),
+ LPSC(1, 0, usb0, pll0_sysclk2, LPSC_ALWAYS_ENABLED),
+ LPSC(2, 0, usb1, pll0_sysclk4, LPSC_ALWAYS_ENABLED),
+ LPSC(3, 0, gpio, pll0_sysclk4, LPSC_ALWAYS_ENABLED),
+ LPSC(5, 0, emac, pll0_sysclk4, LPSC_ALWAYS_ENABLED),
LPSC(6, 0, emif3, pll0_sysclk5, LPSC_ALWAYS_ENABLED),
- LPSC(7, 0, mcasp0, async3, 0),
- LPSC(8, 0, sata, pll0_sysclk2, LPSC_FORCE),
- LPSC(9, 0, vpif, pll0_sysclk2, 0),
- LPSC(10, 0, spi1, async3, 0),
- LPSC(11, 0, i2c1, pll0_sysclk4, 0),
- LPSC(12, 0, uart1, async3, 0),
- LPSC(13, 0, uart2, async3, 0),
- LPSC(14, 0, mcbsp0, async3, 0),
- LPSC(15, 0, mcbsp1, async3, 0),
- LPSC(16, 0, lcdc, pll0_sysclk2, 0),
- LPSC(17, 0, ehrpwm, async3, 0),
- LPSC(18, 0, mmcsd1, pll0_sysclk2, 0),
- LPSC(20, 0, ecap, async3, 0),
+ LPSC(7, 0, mcasp0, async3, LPSC_ALWAYS_ENABLED),
+ LPSC(8, 0, sata, pll0_sysclk2, LPSC_FORCE | LPSC_ALWAYS_ENABLED),
+ LPSC(9, 0, vpif, pll0_sysclk2, LPSC_ALWAYS_ENABLED),
+ LPSC(10, 0, spi1, async3, LPSC_ALWAYS_ENABLED),
+ LPSC(11, 0, i2c1, pll0_sysclk4, LPSC_ALWAYS_ENABLED),
+ LPSC(12, 0, uart1, async3, LPSC_ALWAYS_ENABLED),
+ LPSC(13, 0, uart2, async3, LPSC_ALWAYS_ENABLED),
+ LPSC(14, 0, mcbsp0, async3, LPSC_ALWAYS_ENABLED),
+ LPSC(15, 0, mcbsp1, async3, LPSC_ALWAYS_ENABLED),
+ LPSC(16, 0, lcdc, pll0_sysclk2, LPSC_ALWAYS_ENABLED),
+ LPSC(17, 0, ehrpwm, async3, LPSC_ALWAYS_ENABLED),
+ LPSC(18, 0, mmcsd1, pll0_sysclk2, LPSC_ALWAYS_ENABLED),
+ LPSC(20, 0, ecap, async3, LPSC_ALWAYS_ENABLED),
LPSC(21, 0, tptc2, pll0_sysclk2, LPSC_ALWAYS_ENABLED),
{ }
};
diff --git a/drivers/clk/davinci/pll-da850.c b/drivers/clk/davinci/pll-da850.c
index 77a7223..f334e69 100644
--- a/drivers/clk/davinci/pll-da850.c
+++ b/drivers/clk/davinci/pll-da850.c
@@ -22,21 +22,21 @@
static const struct davinci_pll_divclk_info
da850_pll0_divclk_info[] __initconst = {
- DIVCLK(1, pll0_sysclk1, pll0, DIVCLK_FIXED_DIV),
- DIVCLK(2, pll0_sysclk2, pll0, DIVCLK_FIXED_DIV),
- DIVCLK(3, pll0_sysclk3, pll0, 0),
- DIVCLK(4, pll0_sysclk4, pll0, DIVCLK_FIXED_DIV),
- DIVCLK(5, pll0_sysclk5, pll0, 0),
- DIVCLK(6, pll0_sysclk6, pll0, DIVCLK_ARM_RATE | DIVCLK_FIXED_DIV),
- DIVCLK(7, pll0_sysclk7, pll0, 0),
+ DIVCLK(1, pll0_sysclk1, pll0, DIVCLK_FIXED_DIV | DIVCLK_ALWAYS_ENABLED),
+ DIVCLK(2, pll0_sysclk2, pll0, DIVCLK_FIXED_DIV | DIVCLK_ALWAYS_ENABLED),
+ DIVCLK(3, pll0_sysclk3, pll0, DIVCLK_ALWAYS_ENABLED),
+ DIVCLK(4, pll0_sysclk4, pll0, DIVCLK_FIXED_DIV | DIVCLK_ALWAYS_ENABLED),
+ DIVCLK(5, pll0_sysclk5, pll0, DIVCLK_ALWAYS_ENABLED),
+ DIVCLK(6, pll0_sysclk6, pll0, DIVCLK_ARM_RATE | DIVCLK_FIXED_DIV| DIVCLK_ALWAYS_ENABLED),
+ DIVCLK(7, pll0_sysclk7, pll0, DIVCLK_ALWAYS_ENABLED),
{ }
};
static const struct davinci_pll_divclk_info
da850_pll1_divclk_info[] __initconst = {
DIVCLK(1, pll1_sysclk1, pll1, DIVCLK_ALWAYS_ENABLED),
- DIVCLK(2, pll1_sysclk2, pll1, 0),
- DIVCLK(3, pll1_sysclk3, pll1, 0),
+ DIVCLK(2, pll1_sysclk2, pll1, DIVCLK_ALWAYS_ENABLED),
+ DIVCLK(3, pll1_sysclk3, pll1, DIVCLK_ALWAYS_ENABLED),
{ }
};
^ permalink raw reply related
* [PATCH 00/10] perf tools: Add support for CoreSight trace decoding
From: Mathieu Poirier @ 2018-01-11 21:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180111112835.1511702c2e6ba0077af4112e@arm.com>
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
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.
>
>> > 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.
>
>> > 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.
>
>> > 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.
>
>> 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.
>
>> >> 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.
>
>> >> 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.
>
> Or are you referring to the higher level linux/scripts/ location of the
> dtc? That's not my point: the libopencsd sources can live under
> somewhere like linux/tools/.
>
> Kim
^ permalink raw reply
* [PATCH v5 09/44] dt-bindings: clock: New bindings for TI Davinci PSC
From: Rob Herring @ 2018-01-11 21:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1515377863-20358-10-git-send-email-david@lechnology.com>
On Sun, Jan 07, 2018 at 08:17:08PM -0600, David Lechner wrote:
> This adds a new binding for the Power Sleep Controller (PSC) for the
> mach-davinci family of processors.
>
> Note: Although TI Keystone has a very similar PSC, we are not using the
> existing bindings. Keystone is using a legacy one-node-per-clock binding
> (actually two nodes if you count the separate reset binding for the same
> IP block). Also, some davinci LPSCs have quirks that aren't handled by
> the keystone bindings, so we would be adding one compatible string per
> clock with quirks instead of just a new compatible string for each
> controller.
>
> Signed-off-by: David Lechner <david@lechnology.com>
> ---
> .../devicetree/bindings/clock/ti/davinci/psc.txt | 47 ++++++++++++++++++++++
> 1 file changed, 47 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/clock/ti/davinci/psc.txt
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH -next] IIO: ADC: fix return value check in stm32_dfsdm_adc_probe()
From: Dan Carpenter @ 2018-01-11 21:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1515669161-125426-1-git-send-email-weiyongjun1@huawei.com>
On Thu, Jan 11, 2018 at 11:12:41AM +0000, Wei Yongjun wrote:
> In case of error, the function devm_iio_device_alloc() returns NULL
> pointer not ERR_PTR(). The IS_ERR() test in the return value check
> should be replaced with NULL test.
>
> Fixes: e2e6771c6462 ("IIO: ADC: add STM32 DFSDM sigma delta ADC support")
> Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
> ---
> drivers/iio/adc/stm32-dfsdm-adc.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/iio/adc/stm32-dfsdm-adc.c b/drivers/iio/adc/stm32-dfsdm-adc.c
> index e628d04..5e87140 100644
> --- a/drivers/iio/adc/stm32-dfsdm-adc.c
> +++ b/drivers/iio/adc/stm32-dfsdm-adc.c
> @@ -1100,9 +1100,9 @@ static int stm32_dfsdm_adc_probe(struct platform_device *pdev)
> dev_data = (const struct stm32_dfsdm_dev_data *)of_id->data;
>
> iio = devm_iio_device_alloc(dev, sizeof(*adc));
> - if (IS_ERR(iio)) {
> + if (!iio) {
> dev_err(dev, "%s: Failed to allocate IIO\n", __func__);
> - return PTR_ERR(iio);
> + return -ENOMEM;
> }
>
> adc = iio_priv(iio);
^^^^^^^^^^^^^^^^^^
This one doesn't return an error pointer either. The check causes a
static check warning for me. (It can't actually fail, though so maybe
it will return an error pointer in the future?)
regards,
dan carpenter
^ permalink raw reply
* [PATCH v5 01/44] dt-bindings: clock: Add new bindings for TI Davinci PLL clocks
From: Adam Ford @ 2018-01-11 21:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5832fd62-16aa-e167-7e52-2ce493e33cdc@lechnology.com>
On Thu, Jan 11, 2018 at 3:04 PM, David Lechner <david@lechnology.com> wrote:
> On 01/11/2018 02:58 PM, Adam Ford wrote:
>>
>> On Thu, Jan 11, 2018 at 2:04 PM, David Lechner <david@lechnology.com>
>> wrote:
>>>
>>> On 01/11/2018 12:50 PM, Adam Ford wrote:
>>>>
>>>>
>>>> On Thu, Jan 11, 2018 at 12:29 PM, David Lechner <david@lechnology.com>
>>>> wrote:
>>>>>
>>>>>
>>>>> If removing the "clk_ignore_unused" option causes the board to not
>>>>> boot,
>>>>> then we still have problems that need to be fixed, so please also test
>>>>> without this option.
>>>>
>>>>
>>>>
>>>> Without this option, it still does not boot. Without device tree it
>>>> hangs after:
>>>>
>>>> [snip]
>>>>
>>>> NET: Registered protocol family 17
>>>> Loading compiled-in X.509 certificates
>>>> console [netcon0] enabled
>>>> netconsole: network logging started
>>>> davinci_emac davinci_emac.1: using random MAC addr: 5e:38:1a:1f:4f:77
>>>> mmc0: host does not support reading read-only switch, assuming
>>>> write-enable
>>>> hctosys: unable to open rtc device (rtc0)
>>>> mmc0: new high speed SDHC card at address b368
>>>>
>>>>
>>>> With device tree it hangs after:
>>>>
>>>> [snip]
>>>> 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)
>>>>
>>>>
>>>
>>> Please try this change:
>>>
>>> diff --git a/drivers/clk/davinci/psc-da850.c
>>> b/drivers/clk/davinci/psc-da850.c
>>> index 3fd6b49..a526cc2 100644
>>> --- a/drivers/clk/davinci/psc-da850.c
>>> +++ b/drivers/clk/davinci/psc-da850.c
>>> @@ -17,7 +17,7 @@ static const struct davinci_psc_clk_info
>>> da850_psc0_info[]
>>> __initconst = {
>>> LPSC(0, 0, tpcc0, pll0_sysclk2, LPSC_ALWAYS_ENABLED),
>>> LPSC(1, 0, tptc0, pll0_sysclk2, LPSC_ALWAYS_ENABLED),
>>> LPSC(2, 0, tptc1, pll0_sysclk2, LPSC_ALWAYS_ENABLED),
>>> - LPSC(3, 0, aemif, pll0_sysclk3, 0),
>>> + LPSC(3, 0, aemif, pll0_sysclk3, LPSC_ALWAYS_ENABLED),
>>> LPSC(4, 0, spi0, pll0_sysclk2, 0),
>>> LPSC(5, 0, mmcsd0, pll0_sysclk2, 0),
>>> LPSC(6, 0, aintc, pll0_sysclk4, LPSC_ALWAYS_ENABLED),
>>>
>>>
>>>
>>> If that does not work, try adding LPSC_ALWAYS_ENABLED to all of the
>>> clocks
>>> in this file and then eliminate them one by one until you find which one
>>> is
>>> preventing boot.
>>>
>> Unfortunately, that didn't work. I switch all the entries in both
>> tables that had a 0 to LPSC_ALWAYS_ENABLED, but no luck booting.
>>
>>> If it still does not boot, there is a similar DIVCLK_ALWAYS_ENABLED flag
>>> in
>>> drivers/clk/davinci/pll-da850.c that you can repeat the exercise with.
>>> Add
>>> DIVCLK_ALWAYS_ENABLED to all of the clocks there and then eliminate it
>>> one
>>> by one until you find the clock that is causing the problem.
>>
>>
>> Still no good news. I switched all the entries with a 0 to
>> DIVCLK_ALWAYS_ENABLED and it still didn't finish booting.
>>
>> I wonder if Sekhar Nori might have some suggestions. I didn't look at
>> the code or try to understand it. I just changed the settings.
>>>
>>>
>
> Even if a clock had another flag besides zero, you will need to add
> LPSC_ALWAYS_ENABLED by or-ing it with the other flag.
>
[snip]
Thanks for clarifying. I was able to make it work with the following patch:
diff --git a/drivers/clk/davinci/psc-da850.c b/drivers/clk/davinci/psc-da850.c
index 3b4583d..a76b8682 100644
--- a/drivers/clk/davinci/psc-da850.c
+++ b/drivers/clk/davinci/psc-da850.c
@@ -25,7 +25,7 @@ static const struct davinci_psc_clk_info
da850_psc0_info[] __initconst = {
LPSC(9, 0, uart0, pll0_sysclk2, 0),
LPSC(13, 0, pruss, pll0_sysclk2, 0),
LPSC(14, 0, arm, pll0_sysclk6, LPSC_ALWAYS_ENABLED),
- LPSC(15, 1, dsp, pll0_sysclk1, LPSC_FORCE | LPSC_LOCAL_RESET),
+ LPSC(15, 1, dsp, pll0_sysclk1, LPSC_FORCE | LPSC_LOCAL_RESET |
LPSC_ALWAYS_ENABLED),
{ }
};
If you have an updated patch series with those two fixes, I add my
name to the tested-by list.
>
>
[snip]
>
^ permalink raw reply related
* [linux, dev-4.10, 6/6] drivers/hwmon: Add a driver for a generic PECI hwmon
From: Guenter Roeck @ 2018-01-11 21:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <261ac28e-813c-a058-c81f-ad4e718d0233@linux.intel.com>
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.
[ ... ]
> >>+
> >>+ 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.
> >>+ 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.
[ ... ]
> >>+
> >>+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
^ permalink raw reply
* [PATCH v5 17/44] dt-bindings: clock: Add bindings for DA8XX CFGCHIP gate clocks
From: Rob Herring @ 2018-01-11 21:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1515377863-20358-18-git-send-email-david@lechnology.com>
On Sun, Jan 07, 2018 at 08:17:16PM -0600, David Lechner wrote:
> This adds a new binding for the gate clocks present in the CFGCHIP syscon
> registers in TI DA8XX SoCs. There are actually other gate clocks in this
> block that could be added in the future, but TBCLK is currently the only
> one being used.
Like how many? 2 more?, then fine. 20 more, then perhaps cfgchip should
be the clock provider.
In any case, I'd prefer to see all the cfgchip clocks documented in one
doc.
>
> Signed-off-by: David Lechner <david@lechnology.com>
> ---
> .../clock/ti/davinci/da8xx-cfgchip-gate.txt | 38 ++++++++++++++++++++++
> 1 file changed, 38 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/clock/ti/davinci/da8xx-cfgchip-gate.txt
>
> diff --git a/Documentation/devicetree/bindings/clock/ti/davinci/da8xx-cfgchip-gate.txt b/Documentation/devicetree/bindings/clock/ti/davinci/da8xx-cfgchip-gate.txt
> new file mode 100644
> index 0000000..55821b0
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/ti/davinci/da8xx-cfgchip-gate.txt
> @@ -0,0 +1,38 @@
> +Binding for TI DA8XX/OMAP-L13X/AM17XX/AM18XX CFGCHIP gate clocks
> +
> +TI DA8XX/OMAP-L13X/AM17XX/AM18XX SoCs contain a general purpose set of
> +registers call CFGCHIPn. Some of these registers function as clock
> +gates. This document describes the bindings for those clocks.
> +
> +Required properties:
> +- compatible: shall be "ti,da830-tbclk".
> +- #clock-cells: from common clock binding; shall be set to 0.
> +- clocks: phandle to the parent clock
> +
> +Optional properties:
> +- clock-output-names: from common clock binding.
> +
> +Parent:
> +This node must be a child of a "ti,da830-cfgchip" node.
> +
> +Assignment:
> +The assigned-clocks and assigned-clock-parents from the common clock bindings
> +can be used to indicate which parent clock should be used.
> +
> +Examples:
> +
> + cfgchip: syscon at 1417c {
> + compatible = "ti,da830-cfgchip", "syscon", "simple-mfd";
> + reg = <0x1417c 0x14>;
> +
> + ehrpwm_tbclk: tbclk {
> + compatible = "ti,da830-tbclk";
> + #clock-cells = <0>;
> + clocks = <&psc1 17>;
> + clock-output-names = "ehrpwm_tbclk";
> + };
> + };
> +
> +Also see:
> +- Documentation/devicetree/bindings/clock/clock-bindings.txt
> +
> --
> 2.7.4
>
^ permalink raw reply
* [PATCH v5 01/44] dt-bindings: clock: Add new bindings for TI Davinci PLL clocks
From: David Lechner @ 2018-01-11 21:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAHCN7xKV+Rwep3WiY2aS49iLu+oiZmjtUN2QK+E=hVkqdSPwhw@mail.gmail.com>
On 01/11/2018 03:34 PM, Adam Ford wrote:
> On Thu, Jan 11, 2018 at 3:04 PM, David Lechner <david@lechnology.com> wrote:
>> On 01/11/2018 02:58 PM, Adam Ford wrote:
>>>
>>> On Thu, Jan 11, 2018 at 2:04 PM, David Lechner <david@lechnology.com>
>>> wrote:
>>>>
>>>> On 01/11/2018 12:50 PM, Adam Ford wrote:
>>>>>
>>>>>
>>>>> On Thu, Jan 11, 2018 at 12:29 PM, David Lechner <david@lechnology.com>
>>>>> wrote:
>>>>>>
>>>>>>
>>>>>> If removing the "clk_ignore_unused" option causes the board to not
>>>>>> boot,
>>>>>> then we still have problems that need to be fixed, so please also test
>>>>>> without this option.
>>>>>
>>>>>
>>>>>
>>>>> Without this option, it still does not boot. Without device tree it
>>>>> hangs after:
>>>>>
>>>>> [snip]
>>>>>
>>>>> NET: Registered protocol family 17
>>>>> Loading compiled-in X.509 certificates
>>>>> console [netcon0] enabled
>>>>> netconsole: network logging started
>>>>> davinci_emac davinci_emac.1: using random MAC addr: 5e:38:1a:1f:4f:77
>>>>> mmc0: host does not support reading read-only switch, assuming
>>>>> write-enable
>>>>> hctosys: unable to open rtc device (rtc0)
>>>>> mmc0: new high speed SDHC card at address b368
>>>>>
>>>>>
>>>>> With device tree it hangs after:
>>>>>
>>>>> [snip]
>>>>> 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)
>>>>>
>>>>>
>>>>
>>>> Please try this change:
>>>>
>>>> diff --git a/drivers/clk/davinci/psc-da850.c
>>>> b/drivers/clk/davinci/psc-da850.c
>>>> index 3fd6b49..a526cc2 100644
>>>> --- a/drivers/clk/davinci/psc-da850.c
>>>> +++ b/drivers/clk/davinci/psc-da850.c
>>>> @@ -17,7 +17,7 @@ static const struct davinci_psc_clk_info
>>>> da850_psc0_info[]
>>>> __initconst = {
>>>> LPSC(0, 0, tpcc0, pll0_sysclk2, LPSC_ALWAYS_ENABLED),
>>>> LPSC(1, 0, tptc0, pll0_sysclk2, LPSC_ALWAYS_ENABLED),
>>>> LPSC(2, 0, tptc1, pll0_sysclk2, LPSC_ALWAYS_ENABLED),
>>>> - LPSC(3, 0, aemif, pll0_sysclk3, 0),
>>>> + LPSC(3, 0, aemif, pll0_sysclk3, LPSC_ALWAYS_ENABLED),
>>>> LPSC(4, 0, spi0, pll0_sysclk2, 0),
>>>> LPSC(5, 0, mmcsd0, pll0_sysclk2, 0),
>>>> LPSC(6, 0, aintc, pll0_sysclk4, LPSC_ALWAYS_ENABLED),
>>>>
>>>>
>>>>
>>>> If that does not work, try adding LPSC_ALWAYS_ENABLED to all of the
>>>> clocks
>>>> in this file and then eliminate them one by one until you find which one
>>>> is
>>>> preventing boot.
>>>>
>>> Unfortunately, that didn't work. I switch all the entries in both
>>> tables that had a 0 to LPSC_ALWAYS_ENABLED, but no luck booting.
>>>
>>>> If it still does not boot, there is a similar DIVCLK_ALWAYS_ENABLED flag
>>>> in
>>>> drivers/clk/davinci/pll-da850.c that you can repeat the exercise with.
>>>> Add
>>>> DIVCLK_ALWAYS_ENABLED to all of the clocks there and then eliminate it
>>>> one
>>>> by one until you find the clock that is causing the problem.
>>>
>>>
>>> Still no good news. I switched all the entries with a 0 to
>>> DIVCLK_ALWAYS_ENABLED and it still didn't finish booting.
>>>
>>> I wonder if Sekhar Nori might have some suggestions. I didn't look at
>>> the code or try to understand it. I just changed the settings.
>>>>
>>>>
>>
>> Even if a clock had another flag besides zero, you will need to add
>> LPSC_ALWAYS_ENABLED by or-ing it with the other flag.
>>
>
> [snip]
>
>
> Thanks for clarifying. I was able to make it work with the following patch:
>
> diff --git a/drivers/clk/davinci/psc-da850.c b/drivers/clk/davinci/psc-da850.c
> index 3b4583d..a76b8682 100644
> --- a/drivers/clk/davinci/psc-da850.c
> +++ b/drivers/clk/davinci/psc-da850.c
> @@ -25,7 +25,7 @@ static const struct davinci_psc_clk_info
> da850_psc0_info[] __initconst = {
> LPSC(9, 0, uart0, pll0_sysclk2, 0),
> LPSC(13, 0, pruss, pll0_sysclk2, 0),
> LPSC(14, 0, arm, pll0_sysclk6, LPSC_ALWAYS_ENABLED),
> - LPSC(15, 1, dsp, pll0_sysclk1, LPSC_FORCE | LPSC_LOCAL_RESET),
> + LPSC(15, 1, dsp, pll0_sysclk1, LPSC_FORCE | LPSC_LOCAL_RESET |
> LPSC_ALWAYS_ENABLED),
> { }
> };
>
>
> If you have an updated patch series with those two fixes, I add my
> name to the tested-by list.
>
>
>>
>>
> [snip]
>>
Great! Thanks again for testing.
Sekhar, have you had a chance to look at the rest of the patches in the
series?
I'll wait a bit before I send a v6 to see if any other comments come.
^ permalink raw reply
* [PATCH 4/6] dt-bindings: tegra: Add documentation for nvidia,tegra194-pmc
From: Rob Herring @ 2018-01-11 21:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1515387278-29777-5-git-send-email-mperttunen@nvidia.com>
On Mon, Jan 08, 2018 at 06:54:36AM +0200, Mikko Perttunen wrote:
> The Tegra194 power management controller has one additional register
> aperture to be specified in the device tree node.
>
> Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com>
> ---
> Documentation/devicetree/bindings/arm/tegra/nvidia,tegra186-pmc.txt | 2 ++
> 1 file changed, 2 insertions(+)
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH 00/10] perf tools: Add support for CoreSight trace decoding
From: Kim Phillips @ 2018-01-11 21:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CANLsYkyW2oH=6TjPRoDyAqtHKVQbAYesNA5O5QmLBSnjCie8dw@mail.gmail.com>
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.
> >> >> 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
* [PATCH v5 17/44] dt-bindings: clock: Add bindings for DA8XX CFGCHIP gate clocks
From: David Lechner @ 2018-01-11 21:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180111214516.quplp3kwwfrzocfp@rob-hp-laptop>
On 01/11/2018 03:45 PM, Rob Herring wrote:
> On Sun, Jan 07, 2018 at 08:17:16PM -0600, David Lechner wrote:
>> This adds a new binding for the gate clocks present in the CFGCHIP syscon
>> registers in TI DA8XX SoCs. There are actually other gate clocks in this
>> block that could be added in the future, but TBCLK is currently the only
>> one being used.
>
> Like how many? 2 more?, then fine. 20 more, then perhaps cfgchip should
> be the clock provider.
Like, one more. Same goes for the mux clock. The USB PHY clocks are also
part of the CFGCHIP.
All of these clocks are randomly spread out, so I didn't really see a logical
way to make a single clock provider with #clock-cells = <1>.
>
> In any case, I'd prefer to see all the cfgchip clocks documented in one
> doc.
I will do that.
^ permalink raw reply
* [PATCH] ARM: dts: sun8i: acivate SPI on Orange Pi R1
From: Hauke Mehrtens @ 2018-01-11 21:53 UTC (permalink / raw)
To: linux-arm-kernel
This board has a SPI flash, activate it also in device tree by default.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
---
arch/arm/boot/dts/sun8i-h2-plus-orangepi-r1.dts | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-h2-plus-orangepi-r1.dts b/arch/arm/boot/dts/sun8i-h2-plus-orangepi-r1.dts
index 112f09c67d67..3356f4210d45 100644
--- a/arch/arm/boot/dts/sun8i-h2-plus-orangepi-r1.dts
+++ b/arch/arm/boot/dts/sun8i-h2-plus-orangepi-r1.dts
@@ -68,6 +68,14 @@
};
};
+&spi0 {
+ status = "okay";
+
+ flash at 0 {
+ compatible = "mxicy,mx25l12805d", "jedec,spi-nor";
+ };
+};
+
&ohci1 {
/*
* RTL8152B USB-Ethernet adapter is connected to USB1,
--
2.11.0
^ permalink raw reply related
* [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
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