* [PATCH 4/4] ARM: versatile: support configuring versatile machine for no-MMU
From: Greg Ungerer @ 2016-12-07 6:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481093992-30520-1-git-send-email-gerg@uclinux.org>
Allow the arm versatile machine to be configured for no-MMU operation.
The approach taken is similar to the support for no-MMU arm v7 machines.
A new define, CONFIG_ARM_SINGLE_ARMV5, is used to enable a class of v5
core based machines that are supported for building with !CONFIG_MMU.
Currently only the versatile machine is configured to support this.
Older kernels had the ability to build the versatile machine with the MMU
disabled (!CONFIG_MMU). Recent changes to convert the versatile machine
to device tree lost this ability. (Although older kernels could be built
they did not run due to a bug in the IO_ADDRESS() mapping on this machine).
The motivation for this is that the versatile machine is well supported
in qemu. And this provides an excellent platform for development and
testing no-MMU support on ARM in general.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
---
arch/arm/Kconfig | 10 ++++++++++
arch/arm/Kconfig.debug | 3 ++-
arch/arm/mach-versatile/Kconfig | 3 ++-
3 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index b5d529f..74a0e7a 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -353,6 +353,16 @@ config ARM_SINGLE_ARMV7M
select SPARSE_IRQ
select USE_OF
+config ARM_SINGLE_ARMV5
+ bool "ARMv5 based platforms (ARM926T)"
+ depends on !MMU
+ select AUTO_ZRELADDR
+ select CLKSRC_OF
+ select COMMON_CLK
+ select GENERIC_CLOCKEVENTS
+ select SPARSE_IRQ
+ select USE_OF
+
config ARCH_GEMINI
bool "Cortina Systems Gemini"
select CLKSRC_MMIO
diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index d83f7c3..483709e 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -1712,7 +1712,8 @@ config DEBUG_UNCOMPRESS
config UNCOMPRESS_INCLUDE
string
default "debug/uncompress.h" if ARCH_MULTIPLATFORM || ARCH_MSM || \
- PLAT_SAMSUNG || ARM_SINGLE_ARMV7M
+ PLAT_SAMSUNG || ARM_SINGLE_ARMV7M || \
+ ARM_SINGLE_ARMV5
default "mach/uncompress.h"
config EARLY_PRINTK
diff --git a/arch/arm/mach-versatile/Kconfig b/arch/arm/mach-versatile/Kconfig
index c257d40..2613f0f 100644
--- a/arch/arm/mach-versatile/Kconfig
+++ b/arch/arm/mach-versatile/Kconfig
@@ -1,12 +1,13 @@
config ARCH_VERSATILE
bool "ARM Ltd. Versatile family"
- depends on ARCH_MULTI_V5
+ depends on ARCH_MULTI_V5 || ARM_SINGLE_ARMV5
select ARM_AMBA
select ARM_TIMER_SP804
select ARM_VIC
select CLKSRC_VERSATILE
select COMMON_CLK_VERSATILE
select CPU_ARM926T
+ select GPIOLIB
select ICST
select MFD_SYSCON
select PLAT_VERSATILE
--
1.9.1
^ permalink raw reply related
* [PATCH 3/4] ARM: versatile: empty Makefile.boot needed for no-MMU compile
From: Greg Ungerer @ 2016-12-07 6:59 UTC (permalink / raw)
To: linux-arm-kernel
To compile the arm versatile board with the MMU disabled (!CONFIG_MMU)
a Makefile.boot is required. Without it you get:
SYSMAP System.map
arch/arm/boot/Makefile:15: arch/arm/mach-versatile//Makefile.boot: No such file or directory
make[2]: *** No rule to make target `arch/arm/mach-versatile//Makefile.boot'. Stop.
Create an empty Makefile.boot for the versatile machine. This is a
copy of the other empty machine Makefile.boot files. (A few have this
same commented empty file: stm32, ep93xx, lpc18xx, efm32 and vexpress).
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
---
arch/arm/mach-versatile/Makefile.boot | 3 +++
1 file changed, 3 insertions(+)
create mode 100644 arch/arm/mach-versatile/Makefile.boot
diff --git a/arch/arm/mach-versatile/Makefile.boot b/arch/arm/mach-versatile/Makefile.boot
new file mode 100644
index 0000000..eacfc3f
--- /dev/null
+++ b/arch/arm/mach-versatile/Makefile.boot
@@ -0,0 +1,3 @@
+# Empty file waiting for deletion once Makefile.boot isn't needed any more.
+# Patch waits for application at
+# http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=7889/1 .
--
1.9.1
^ permalink raw reply related
* [PATCH 7/7] arm: Add livepatch necessary arch selects into Kconfig
From: kbuild test robot @ 2016-12-07 6:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481043967-15602-8-git-send-email-abelvesa@linux.com>
Hi Abel,
[auto build test WARNING on linus/master]
[also build test WARNING on v4.9-rc8 next-20161206]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Abel-Vesa/arm-Add-livepatch-support/20161207-074210
config: arm-allmodconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm
All warnings (new ones prefixed by >>):
arch/arm/kernel/entry-ftrace.S: Assembler messages:
>> arch/arm/kernel/entry-ftrace.S:259: Warning: if writeback register is in list, it must be the lowest reg in the list
>> arch/arm/kernel/entry-ftrace.S:259: Warning: writeback of base register when in register list is UNPREDICTABLE
vim +259 arch/arm/kernel/entry-ftrace.S
82112379 Russell King 2014-10-28 243 #else
82112379 Russell King 2014-10-28 244 __mcount
82112379 Russell King 2014-10-28 245 #endif
82112379 Russell King 2014-10-28 246 UNWIND(.fnend)
82112379 Russell King 2014-10-28 247 ENDPROC(__gnu_mcount_nc)
82112379 Russell King 2014-10-28 248
82112379 Russell King 2014-10-28 249 #ifdef CONFIG_DYNAMIC_FTRACE
82112379 Russell King 2014-10-28 250 ENTRY(ftrace_caller)
82112379 Russell King 2014-10-28 251 UNWIND(.fnstart)
82112379 Russell King 2014-10-28 252 __ftrace_caller
82112379 Russell King 2014-10-28 253 UNWIND(.fnend)
82112379 Russell King 2014-10-28 254 ENDPROC(ftrace_caller)
22cc202f Abel Vesa 2016-12-06 255
22cc202f Abel Vesa 2016-12-06 256 #ifdef CONFIG_DYNAMIC_FTRACE_WITH_REGS
22cc202f Abel Vesa 2016-12-06 257 ENTRY(ftrace_regs_caller)
22cc202f Abel Vesa 2016-12-06 258 UNWIND(.fnstart)
22cc202f Abel Vesa 2016-12-06 @259 __ftrace_regs_caller
22cc202f Abel Vesa 2016-12-06 260 UNWIND(.fnend)
22cc202f Abel Vesa 2016-12-06 261 ENDPROC(ftrace_regs_caller)
22cc202f Abel Vesa 2016-12-06 262 #endif
22cc202f Abel Vesa 2016-12-06 263
82112379 Russell King 2014-10-28 264 #endif
82112379 Russell King 2014-10-28 265
82112379 Russell King 2014-10-28 266 #ifdef CONFIG_FUNCTION_GRAPH_TRACER
82112379 Russell King 2014-10-28 267 ENTRY(ftrace_graph_caller)
:::::: The code at line 259 was first introduced by commit
:::::: 22cc202f6f168f6987ec2441a19ce1601a296a4e arm: Add ftrace with regs support
:::::: TO: Abel Vesa <abelvesa@linux.com>
:::::: CC: 0day robot <fengguang.wu@intel.com>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 59460 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161207/57348213/attachment-0001.gz>
^ permalink raw reply
* [PATCH v3 1/3] ARM: da850: fix infinite loop in clk_set_rate()
From: Sekhar Nori @ 2016-12-07 6:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <148e4d35-da65-a212-1490-c2d902dd4410@lechnology.com>
On Wednesday 07 December 2016 07:24 AM, David Lechner wrote:
> On 12/05/2016 04:09 AM, Bartosz Golaszewski wrote:
>> The aemif clock is added twice to the lookup table in da850.c. This
>> breaks the children list of pll0_sysclk3 as we're using the same list
>> links in struct clk. When calling clk_set_rate(), we get stuck in
>> propagate_rate().
>
> &emac_clk is used twice in this list as well. Shouldn't we fix it too? I
> would expect that it causes the same problem.
Yes, indeed.
Thanks,
Sekhar
^ permalink raw reply
* [PATCH v3 3/3] MAINTAINERS: add 2967 SoC drivers to ARM ZTE architecture
From: Baoyou Xie @ 2016-12-07 6:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481091204-6559-1-git-send-email-baoyou.xie@linaro.org>
Add the 2967 SoC drivers as maintained by ARM ZTE
architecture maintainers, as they're parts of the core IP.
By the way, this patch adds the maintainer for ARM
ZTE architecture to Baoyou Xie.
Signed-off-by: Baoyou Xie <baoyou.xie@linaro.org>
---
MAINTAINERS | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index ad199da..d32aef0 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1975,12 +1975,16 @@ F: arch/arm/mach-pxa/include/mach/z2.h
ARM/ZTE ARCHITECTURE
M: Jun Nie <jun.nie@linaro.org>
+M: Baoyou Xie <baoyou.xie@linaro.org>
L: linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
S: Maintained
F: arch/arm/mach-zx/
F: drivers/clk/zte/
+F: drivers/soc/zte/
F: Documentation/devicetree/bindings/arm/zte.txt
F: Documentation/devicetree/bindings/clock/zx296702-clk.txt
+F: Documentation/devicetree/bindings/soc/zte/
+F: include/dt-bindings/arm/zte*.h
ARM/ZYNQ ARCHITECTURE
M: Michal Simek <michal.simek@xilinx.com>
--
2.7.4
^ permalink raw reply related
* [PATCH v3 2/3] soc: zte: pm_domains: Add support for zx296718 board
From: Baoyou Xie @ 2016-12-07 6:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481091204-6559-1-git-send-email-baoyou.xie@linaro.org>
This patch introduces the power domain driver of zx296718
which belongs to zte's 2967 family.
Signed-off-by: Baoyou Xie <baoyou.xie@linaro.org>
---
drivers/soc/zte/Makefile | 2 +-
drivers/soc/zte/zx296718_pm_domains.c | 194 ++++++++++++++++++++++++++++++++++
2 files changed, 195 insertions(+), 1 deletion(-)
create mode 100644 drivers/soc/zte/zx296718_pm_domains.c
diff --git a/drivers/soc/zte/Makefile b/drivers/soc/zte/Makefile
index 97ac8ea..2d2a2cc 100644
--- a/drivers/soc/zte/Makefile
+++ b/drivers/soc/zte/Makefile
@@ -1,4 +1,4 @@
#
# zx SOC drivers
#
-obj-$(CONFIG_ZX_PM_DOMAINS) += pm_domains.o
+obj-$(CONFIG_ZX_PM_DOMAINS) += pm_domains.o zx296718_pm_domains.o
diff --git a/drivers/soc/zte/zx296718_pm_domains.c b/drivers/soc/zte/zx296718_pm_domains.c
new file mode 100644
index 0000000..5355b94
--- /dev/null
+++ b/drivers/soc/zte/zx296718_pm_domains.c
@@ -0,0 +1,194 @@
+/*
+ * Copyright (C) 2015 ZTE Ltd.
+ *
+ * Author: Baoyou Xie <baoyou.xie@linaro.org>
+ * License terms: GNU General Public License (GPL) version 2
+ */
+#include <dt-bindings/arm/zte_pm_domains.h>
+#include "pm_domains.h"
+
+static u16 zx296718_offsets[REG_ARRAY_SIZE] = {
+ [REG_CLKEN] = 0x18,
+ [REG_ISOEN] = 0x1c,
+ [REG_RSTEN] = 0x20,
+ [REG_PWREN] = 0x24,
+ [REG_ACK_SYNC] = 0x28,
+};
+
+enum {
+ PCU_DM_VOU = 0,
+ PCU_DM_SAPPU,
+ PCU_DM_VDE,
+ PCU_DM_VCE,
+ PCU_DM_HDE,
+ PCU_DM_VIU,
+ PCU_DM_USB20,
+ PCU_DM_USB21,
+ PCU_DM_USB30,
+ PCU_DM_HSIC,
+ PCU_DM_GMAC,
+ PCU_DM_TS,
+};
+
+static struct zx_pm_domain vou_domain = {
+ .dm = {
+ .name = "vou_domain",
+ .power_off = zx_normal_power_off,
+ .power_on = zx_normal_power_on,
+ },
+ .bit = PCU_DM_VOU,
+ .polarity = PWREN,
+ .reg_offset = zx296718_offsets,
+};
+static struct zx_pm_domain sappu_domain = {
+ .dm = {
+ .name = "sappu_domain",
+ .power_off = zx_normal_power_off,
+ .power_on = zx_normal_power_on,
+ },
+ .bit = PCU_DM_SAPPU,
+ .polarity = PWREN,
+ .reg_offset = zx296718_offsets,
+};
+static struct zx_pm_domain vde_domain = {
+ .dm = {
+ .name = "vde_domain",
+ .power_off = zx_normal_power_off,
+ .power_on = zx_normal_power_on,
+ },
+ .bit = PCU_DM_VDE,
+ .polarity = PWREN,
+ .reg_offset = zx296718_offsets,
+};
+static struct zx_pm_domain vce_domain = {
+ .dm = {
+ .name = "vce_domain",
+ .power_off = zx_normal_power_off,
+ .power_on = zx_normal_power_on,
+ },
+ .bit = PCU_DM_VCE,
+ .polarity = PWREN,
+ .reg_offset = zx296718_offsets,
+};
+static struct zx_pm_domain hde_domain = {
+ .dm = {
+ .name = "hde_domain",
+ .power_off = zx_normal_power_off,
+ .power_on = zx_normal_power_on,
+ },
+ .bit = PCU_DM_HDE,
+ .polarity = PWREN,
+ .reg_offset = zx296718_offsets,
+};
+
+static struct zx_pm_domain viu_domain = {
+ .dm = {
+ .name = "viu_domain",
+ .power_off = zx_normal_power_off,
+ .power_on = zx_normal_power_on,
+ },
+ .bit = PCU_DM_VIU,
+ .polarity = PWREN,
+ .reg_offset = zx296718_offsets,
+};
+static struct zx_pm_domain usb20_domain = {
+ .dm = {
+ .name = "usb20_domain",
+ .power_off = zx_normal_power_off,
+ .power_on = zx_normal_power_on,
+ },
+ .bit = PCU_DM_USB20,
+ .polarity = PWREN,
+ .reg_offset = zx296718_offsets,
+};
+static struct zx_pm_domain usb21_domain = {
+ .dm = {
+ .name = "usb21_domain",
+ .power_off = zx_normal_power_off,
+ .power_on = zx_normal_power_on,
+ },
+ .bit = PCU_DM_USB21,
+ .polarity = PWREN,
+ .reg_offset = zx296718_offsets,
+};
+static struct zx_pm_domain usb30_domain = {
+ .dm = {
+ .name = "usb30_domain",
+ .power_off = zx_normal_power_off,
+ .power_on = zx_normal_power_on,
+ },
+ .bit = PCU_DM_USB30,
+ .polarity = PWREN,
+ .reg_offset = zx296718_offsets,
+};
+static struct zx_pm_domain hsic_domain = {
+ .dm = {
+ .name = "hsic_domain",
+ .power_off = zx_normal_power_off,
+ .power_on = zx_normal_power_on,
+ },
+ .bit = PCU_DM_HSIC,
+ .polarity = PWREN,
+ .reg_offset = zx296718_offsets,
+};
+static struct zx_pm_domain gmac_domain = {
+ .dm = {
+ .name = "gmac_domain",
+ .power_off = zx_normal_power_off,
+ .power_on = zx_normal_power_on,
+ },
+ .bit = PCU_DM_GMAC,
+ .polarity = PWREN,
+ .reg_offset = zx296718_offsets,
+};
+static struct zx_pm_domain ts_domain = {
+ .dm = {
+ .name = "ts_domain",
+ .power_off = zx_normal_power_off,
+ .power_on = zx_normal_power_on,
+ },
+ .bit = PCU_DM_TS,
+ .polarity = PWREN,
+ .reg_offset = zx296718_offsets,
+};
+struct generic_pm_domain *zx296718_pm_domains[] = {
+ [DM_ZX296718_SAPPU] = &sappu_domain.dm,
+ [DM_ZX296718_VDE] = &vde_domain.dm,
+ [DM_ZX296718_VCE] = &vce_domain.dm,
+ [DM_ZX296718_HDE] = &hde_domain.dm,
+ [DM_ZX296718_VIU] = &viu_domain.dm,
+ [DM_ZX296718_USB20] = &usb20_domain.dm,
+ [DM_ZX296718_USB21] = &usb21_domain.dm,
+ [DM_ZX296718_USB30] = &usb30_domain.dm,
+ [DM_ZX296718_HSIC] = &hsic_domain.dm,
+ [DM_ZX296718_GMAC] = &gmac_domain.dm,
+ [DM_ZX296718_TS] = &ts_domain.dm,
+ [DM_ZX296718_VOU] = &vou_domain.dm,
+};
+
+static int zx296718_pd_probe(struct platform_device *pdev)
+{
+ return zx_pd_probe(pdev,
+ zx296718_pm_domains,
+ ARRAY_SIZE(zx296718_pm_domains));
+}
+
+static const struct of_device_id zx296718_pm_domain_matches[] = {
+ { .compatible = "zte,zx296718-pcu", },
+ { },
+};
+
+static struct platform_driver zx296718_pd_driver = {
+ .driver = {
+ .name = "zx-powerdomain",
+ .owner = THIS_MODULE,
+ .of_match_table = zx296718_pm_domain_matches,
+ },
+ .probe = zx296718_pd_probe,
+};
+
+static int __init zx296718_pd_init(void)
+{
+ return platform_driver_register(&zx296718_pd_driver);
+}
+subsys_initcall(zx296718_pd_init);
--
2.7.4
^ permalink raw reply related
* [PATCH v3 1/3] soc: zte: pm_domains: Prepare for supporting ARMv8 2967 family
From: Baoyou Xie @ 2016-12-07 6:13 UTC (permalink / raw)
To: linux-arm-kernel
The ARMv8 2967 family (296718, 296716 etc) uses different value
for controlling the power domain on/off registers, Choose the
value depending on the compatible.
Multiple domains are prepared for the family, this patch prepares
the common functions.
Signed-off-by: Baoyou Xie <baoyou.xie@linaro.org>
---
drivers/soc/Kconfig | 1 +
drivers/soc/Makefile | 1 +
drivers/soc/zte/Kconfig | 13 ++++
drivers/soc/zte/Makefile | 4 ++
drivers/soc/zte/pm_domains.c | 150 +++++++++++++++++++++++++++++++++++++++++++
drivers/soc/zte/pm_domains.h | 48 ++++++++++++++
6 files changed, 217 insertions(+)
create mode 100644 drivers/soc/zte/Kconfig
create mode 100644 drivers/soc/zte/Makefile
create mode 100644 drivers/soc/zte/pm_domains.c
create mode 100644 drivers/soc/zte/pm_domains.h
diff --git a/drivers/soc/Kconfig b/drivers/soc/Kconfig
index f31bceb..f09023f 100644
--- a/drivers/soc/Kconfig
+++ b/drivers/soc/Kconfig
@@ -11,5 +11,6 @@ source "drivers/soc/tegra/Kconfig"
source "drivers/soc/ti/Kconfig"
source "drivers/soc/ux500/Kconfig"
source "drivers/soc/versatile/Kconfig"
+source "drivers/soc/zte/Kconfig"
endmenu
diff --git a/drivers/soc/Makefile b/drivers/soc/Makefile
index 50c23d0..05eae52 100644
--- a/drivers/soc/Makefile
+++ b/drivers/soc/Makefile
@@ -16,3 +16,4 @@ obj-$(CONFIG_ARCH_TEGRA) += tegra/
obj-$(CONFIG_SOC_TI) += ti/
obj-$(CONFIG_ARCH_U8500) += ux500/
obj-$(CONFIG_PLAT_VERSATILE) += versatile/
+obj-$(CONFIG_ARCH_ZX) += zte/
diff --git a/drivers/soc/zte/Kconfig b/drivers/soc/zte/Kconfig
new file mode 100644
index 0000000..4953c3fa
--- /dev/null
+++ b/drivers/soc/zte/Kconfig
@@ -0,0 +1,13 @@
+#
+# zx SoC drivers
+#
+menuconfig SOC_ZX
+ bool "zx SoC driver support"
+
+if SOC_ZX
+
+config ZX_PM_DOMAINS
+ bool "zx PM domains"
+ depends on PM_GENERIC_DOMAINS
+
+endif
diff --git a/drivers/soc/zte/Makefile b/drivers/soc/zte/Makefile
new file mode 100644
index 0000000..97ac8ea
--- /dev/null
+++ b/drivers/soc/zte/Makefile
@@ -0,0 +1,4 @@
+#
+# zx SOC drivers
+#
+obj-$(CONFIG_ZX_PM_DOMAINS) += pm_domains.o
diff --git a/drivers/soc/zte/pm_domains.c b/drivers/soc/zte/pm_domains.c
new file mode 100644
index 0000000..e4d1235
--- /dev/null
+++ b/drivers/soc/zte/pm_domains.c
@@ -0,0 +1,150 @@
+/*
+ * Copyright (C) 2015 ZTE Ltd.
+ *
+ * Author: Baoyou Xie <baoyou.xie@linaro.org>
+ * License terms: GNU General Public License (GPL) version 2
+ */
+#include <linux/delay.h>
+#include <linux/err.h>
+#include <linux/io.h>
+#include <linux/of.h>
+#include "pm_domains.h"
+
+#define PCU_DM_CLKEN(zpd) ((zpd)->reg_offset[REG_CLKEN])
+#define PCU_DM_ISOEN(zpd) ((zpd)->reg_offset[REG_ISOEN])
+#define PCU_DM_RSTEN(zpd) ((zpd)->reg_offset[REG_RSTEN])
+#define PCU_DM_PWREN(zpd) ((zpd)->reg_offset[REG_PWREN])
+#define PCU_DM_PWRDN(zpd) ((zpd)->reg_offset[REG_PWRDN])
+#define PCU_DM_ACK_SYNC(zpd) ((zpd)->reg_offset[REG_ACK_SYNC])
+
+static void __iomem *pcubase;
+
+int zx_normal_power_on(struct generic_pm_domain *domain)
+{
+ struct zx_pm_domain *zpd = (struct zx_pm_domain *)domain;
+ unsigned long loop = 1000;
+ u32 val;
+
+ if (zpd->polarity == PWREN) {
+ val = readl_relaxed(pcubase + PCU_DM_PWREN(zpd));
+ val |= BIT(zpd->bit);
+ writel_relaxed(val, pcubase + PCU_DM_PWREN(zpd));
+ } else {
+ val = readl_relaxed(pcubase + PCU_DM_PWRDN(zpd));
+ val &= ~BIT(zpd->bit);
+ writel_relaxed(val, pcubase + PCU_DM_PWRDN(zpd));
+ }
+
+ do {
+ udelay(1);
+ val = readl_relaxed(pcubase + PCU_DM_ACK_SYNC(zpd))
+ & BIT(zpd->bit);
+ } while (--loop && !val);
+
+ if (!loop) {
+ pr_err("Error: %s %s fail\n", __func__, domain->name);
+ return -EIO;
+ }
+
+ val = readl_relaxed(pcubase + PCU_DM_RSTEN(zpd));
+ val &= ~BIT(zpd->bit);
+ writel_relaxed(val | BIT(zpd->bit), pcubase + PCU_DM_RSTEN(zpd));
+ udelay(5);
+
+ val = readl_relaxed(pcubase + PCU_DM_ISOEN(zpd));
+ val &= ~BIT(zpd->bit);
+ writel_relaxed(val, pcubase + PCU_DM_ISOEN(zpd));
+ udelay(5);
+
+ val = readl_relaxed(pcubase + PCU_DM_CLKEN(zpd));
+ val &= ~BIT(zpd->bit);
+ writel_relaxed(val | BIT(zpd->bit), pcubase + PCU_DM_CLKEN(zpd));
+ udelay(5);
+
+ pr_info("normal poweron %s\n", domain->name);
+
+ return 0;
+}
+
+int zx_normal_power_off(struct generic_pm_domain *domain)
+{
+ struct zx_pm_domain *zpd = (struct zx_pm_domain *)domain;
+ unsigned long loop = 1000;
+ u32 val;
+
+ val = readl_relaxed(pcubase + PCU_DM_CLKEN(zpd));
+ val &= ~BIT(zpd->bit);
+ writel_relaxed(val, pcubase + PCU_DM_CLKEN(zpd));
+ udelay(5);
+
+ val = readl_relaxed(pcubase + PCU_DM_ISOEN(zpd));
+ val &= ~BIT(zpd->bit);
+ writel_relaxed(val | BIT(zpd->bit), pcubase + PCU_DM_ISOEN(zpd));
+ udelay(5);
+
+ val = readl_relaxed(pcubase + PCU_DM_RSTEN(zpd));
+ val &= ~BIT(zpd->bit);
+ writel_relaxed(val, pcubase + PCU_DM_RSTEN(zpd));
+ udelay(5);
+
+ if (zpd->polarity == PWREN) {
+ val = readl_relaxed(pcubase + PCU_DM_PWREN(zpd));
+ val &= ~BIT(zpd->bit);
+ writel_relaxed(val, pcubase + PCU_DM_PWREN(zpd));
+ } else {
+ val = readl_relaxed(pcubase + PCU_DM_PWRDN(zpd));
+ val |= BIT(zpd->bit);
+ writel_relaxed(val, pcubase + PCU_DM_PWRDN(zpd));
+ }
+
+ do {
+ udelay(1);
+ val = readl_relaxed(pcubase + PCU_DM_ACK_SYNC(zpd))
+ & BIT(zpd->bit);
+ } while (--loop && val);
+
+ if (!loop) {
+ pr_err("Error: %s %s fail\n", __func__, domain->name);
+ return -EIO;
+ }
+
+ pr_info("normal poweroff %s\n", domain->name);
+
+ return 0;
+}
+
+int
+zx_pd_probe(struct platform_device *pdev,
+ struct generic_pm_domain **zx_pm_domains,
+ int domain_num)
+{
+ struct genpd_onecell_data *genpd_data;
+ struct resource *res;
+ int i;
+
+ genpd_data = devm_kzalloc(&pdev->dev, sizeof(*genpd_data), GFP_KERNEL);
+ if (!genpd_data)
+ return -ENOMEM;
+
+ genpd_data->domains = zx_pm_domains;
+ genpd_data->num_domains = domain_num;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (!res) {
+ dev_err(&pdev->dev, "no memory resource defined\n");
+ return -ENODEV;
+ }
+
+ pcubase = devm_ioremap_resource(&pdev->dev, res);
+ if (IS_ERR(pcubase)) {
+ dev_err(&pdev->dev, "ioremap fail.\n");
+ return -EIO;
+ }
+
+ for (i = 0; i < domain_num; ++i)
+ pm_genpd_init(zx_pm_domains[i], NULL, false);
+
+ of_genpd_add_provider_onecell(pdev->dev.of_node, genpd_data);
+ dev_info(&pdev->dev, "powerdomain init ok\n");
+ return 0;
+}
diff --git a/drivers/soc/zte/pm_domains.h b/drivers/soc/zte/pm_domains.h
new file mode 100644
index 0000000..d3a52fd
--- /dev/null
+++ b/drivers/soc/zte/pm_domains.h
@@ -0,0 +1,48 @@
+/*
+ * Copyright (c) 2015 ZTE Co., Ltd.
+ * http://www.zte.com.cn
+ *
+ * Header for ZTE's Power Domain Driver support
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#ifndef __ZTE_PM_DOMAIN_H
+#define __ZTE_PM_DOMAIN_H
+
+#include <linux/platform_device.h>
+#include <linux/pm_domain.h>
+
+enum {
+ REG_CLKEN,
+ REG_ISOEN,
+ REG_RSTEN,
+ REG_PWREN,
+ REG_PWRDN,
+ REG_ACK_SYNC,
+
+ /* The size of the array - must be last */
+ REG_ARRAY_SIZE,
+};
+
+enum zx_power_polarity {
+ PWREN,
+ PWRDN,
+};
+
+struct zx_pm_domain {
+ struct generic_pm_domain dm;
+ const u16 bit;
+ const enum zx_power_polarity polarity;
+ const u16 *reg_offset;
+};
+
+extern int zx_normal_power_on(struct generic_pm_domain *domain);
+extern int zx_normal_power_off(struct generic_pm_domain *domain);
+extern int
+zx_pd_probe(struct platform_device *pdev,
+ struct generic_pm_domain **zx_pm_domains,
+ int domain_num);
+#endif /* __ZTE_PM_DOMAIN_H */
--
2.7.4
^ permalink raw reply related
* [PATCH 3/5] arm64: dts: exynos5433: Add PPMU dt node
From: Krzysztof Kozlowski @ 2016-12-07 6:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5847A419.9050801@samsung.com>
On Wed, Dec 7, 2016 at 7:54 AM, Chanwoo Choi <cw00.choi@samsung.com> wrote:
> On 2016? 12? 07? 13:12, Chanwoo Choi wrote:
>> On 2016? 12? 07? 04:07, Krzysztof Kozlowski wrote:
>>> On Fri, Dec 02, 2016 at 04:18:05PM +0900, Chanwoo Choi wrote:
>>>> This patch adds PPMU (Platform Performance Monitoring Unit) Device-tree node
>>>> to measure the utilization of each IP in Exynos SoC.
>>>>
>>>> - PPMU_D{0|1}_CPU are used to measure the utilization of MIF (Memory Interface)
>>>> block with VDD_MIF power source.
>>>> - PPMU_D{0|1}_GENERAL are used to measure the utilization of INT(Internal)
>>>> block with VDD_INT power source.
>>>>
>>>> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
>>>> ---
>>>> arch/arm64/boot/dts/exynos/exynos5433.dtsi | 24 ++++++++++++++++++++++++
>>>> 1 file changed, 24 insertions(+)
>>>>
>>>> diff --git a/arch/arm64/boot/dts/exynos/exynos5433.dtsi b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
>>>> index 64226d5ae471..8c4ee84d5232 100644
>>>> --- a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
>>>> +++ b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
>>>> @@ -599,6 +599,30 @@
>>>> clock-names = "fin_pll", "mct";
>>>> };
>>>>
>>>> + ppmu_d0_cpu: ppmu at 10480000 {
>>>> + compatible = "samsung,exynos-ppmu-v2";
>>>> + reg = <0x10480000 0x2000>;
>>>> + status = "disabled";
>>>
>>> Why these are disabled? They have some external dependencies?
>>
>> There is no any dependency. If you want to remain it always enabled,
>> I'm OK.
>
> One more comment. Each PPMU has the four events which is used for devfreq driver
> to get the utilization. If I remove the 'status = "disabled"' from exynos5433.dtsi,
> first probe of PPMU device is fail on case1.
>
> Case1. Disable PPMU device and then enable it on exynos5433-tm2.dts
> [ 2.560126] exynos-ppmu: new PPMU device registered 10490000.ppmu (ppmu-event0-d0-general)
> [ 2.565957] exynos-ppmu: new PPMU device registered 104c0000.ppmu (ppmu-event0-d1-general)
>
> Case2. Enable PPMU device always. First probe is failed and then second probe is successful.
> [ 2.898781] exynos-ppmu 10480000.ppmu: failed to get child node of devfreq-event devices
> [ 2.899077] exynos-ppmu 10480000.ppmu: failed to parse exynos ppmu dt node
> [ 2.899289] exynos-ppmu 10480000.ppmu: failed to parse devicetree for resource
> [ 2.899602] exynos-ppmu: probe of 10480000.ppmu failed with error -22
> [ 2.905364] exynos-ppmu: new PPMU device registered 10490000.ppmu (ppmu-event0-d0-general)
> [ 2.913535] exynos-ppmu 104b0000.ppmu: failed to get child node of devfreq-event devices
> [ 2.921402] exynos-ppmu 104b0000.ppmu: failed to parse exynos ppmu dt node
> [ 2.928250] exynos-ppmu 104b0000.ppmu: failed to parse devicetree for resource
> [ 2.935571] exynos-ppmu: probe of 104b0000.ppmu failed with error -22
> [ 2.942144] exynos-ppmu: new PPMU device registered 104c0000.ppmu (ppmu-event0-d1-general)
I got it, so leaving it as disabled makes sense. For the reference:
Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH 1/3] ARM: Define KERNEL_START and KERNEL_END
From: kbuild test robot @ 2016-12-07 6:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161206195312.22354-2-f.fainelli@gmail.com>
Hi Florian,
[auto build test WARNING on linus/master]
[also build test WARNING on v4.9-rc8 next-20161206]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Florian-Fainelli/ARM-Add-support-for-CONFIG_DEBUG_VIRTUAL/20161207-071442
config: arm-lart_defconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm
All warnings (new ones prefixed by >>):
>> drivers/mtd/devices/lart.c:83:0: warning: "KERNEL_START" redefined
#define KERNEL_START (BLOB_START + BLOB_LEN)
In file included from arch/arm/include/asm/page.h:163:0,
from arch/arm/include/asm/thread_info.h:17,
from include/linux/thread_info.h:58,
from include/asm-generic/preempt.h:4,
from ./arch/arm/include/generated/asm/preempt.h:1,
from include/linux/preempt.h:59,
from include/linux/spinlock.h:50,
from include/linux/seqlock.h:35,
from include/linux/time.h:5,
from include/linux/stat.h:18,
from include/linux/module.h:10,
from drivers/mtd/devices/lart.c:38:
arch/arm/include/asm/memory.h:117:0: note: this is the location of the previous definition
#define KERNEL_START _stext
vim +/KERNEL_START +83 drivers/mtd/devices/lart.c
^1da177e Linus Torvalds 2005-04-16 67
^1da177e Linus Torvalds 2005-04-16 68 /*
^1da177e Linus Torvalds 2005-04-16 69 * These values are specific to LART
^1da177e Linus Torvalds 2005-04-16 70 */
^1da177e Linus Torvalds 2005-04-16 71
^1da177e Linus Torvalds 2005-04-16 72 /* general */
^1da177e Linus Torvalds 2005-04-16 73 #define BUSWIDTH 4 /* don't change this - a lot of the code _will_ break if you change this */
^1da177e Linus Torvalds 2005-04-16 74 #define FLASH_OFFSET 0xe8000000 /* see linux/arch/arm/mach-sa1100/lart.c */
^1da177e Linus Torvalds 2005-04-16 75
^1da177e Linus Torvalds 2005-04-16 76 /* blob */
^1da177e Linus Torvalds 2005-04-16 77 #define NUM_BLOB_BLOCKS FLASH_NUMBLOCKS_16m_PARAM
^1da177e Linus Torvalds 2005-04-16 78 #define BLOB_START 0x00000000
^1da177e Linus Torvalds 2005-04-16 79 #define BLOB_LEN (NUM_BLOB_BLOCKS * FLASH_BLOCKSIZE_PARAM)
^1da177e Linus Torvalds 2005-04-16 80
^1da177e Linus Torvalds 2005-04-16 81 /* kernel */
^1da177e Linus Torvalds 2005-04-16 82 #define NUM_KERNEL_BLOCKS 7
^1da177e Linus Torvalds 2005-04-16 @83 #define KERNEL_START (BLOB_START + BLOB_LEN)
^1da177e Linus Torvalds 2005-04-16 84 #define KERNEL_LEN (NUM_KERNEL_BLOCKS * FLASH_BLOCKSIZE_MAIN)
^1da177e Linus Torvalds 2005-04-16 85
^1da177e Linus Torvalds 2005-04-16 86 /* initial ramdisk */
^1da177e Linus Torvalds 2005-04-16 87 #define NUM_INITRD_BLOCKS 24
^1da177e Linus Torvalds 2005-04-16 88 #define INITRD_START (KERNEL_START + KERNEL_LEN)
^1da177e Linus Torvalds 2005-04-16 89 #define INITRD_LEN (NUM_INITRD_BLOCKS * FLASH_BLOCKSIZE_MAIN)
^1da177e Linus Torvalds 2005-04-16 90
^1da177e Linus Torvalds 2005-04-16 91 /*
:::::: The code at line 83 was first introduced by commit
:::::: 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 Linux-2.6.12-rc2
:::::: TO: Linus Torvalds <torvalds@ppc970.osdl.org>
:::::: CC: Linus Torvalds <torvalds@ppc970.osdl.org>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 11578 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161207/3829bed8/attachment-0001.gz>
^ permalink raw reply
* [PATCH 2/4] ARM: versatile: define empty debug_ll_io_init() for no-MMU
From: Greg Ungerer @ 2016-12-07 6:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481090912-29835-1-git-send-email-gerg@uclinux.org>
No-MMU configured targets have no definition for debug_ll_io_init().
Not all machines use this and it will only be required if CONFIG_DEBUG_LL
is enabled.
But when compiling for a target that uses it and it is configured for
no-MMU (!CONFIG_MMU), for example the versatile machine, you will get:
CC arch/arm/mach-versatile/versatile_dt.o
arch/arm/mach-versatile/versatile_dt.c: In function ?versatile_map_io?:
arch/arm/mach-versatile/versatile_dt.c:283:2: error: implicit declaration of function ?debug_ll_io_init? [-Werror=implicit-function-declaration]
debug_ll_io_init();
^
Fix by adding a macro for it to the !CONFIG_MMU path in map.h.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
---
arch/arm/include/asm/mach/map.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/include/asm/mach/map.h b/arch/arm/include/asm/mach/map.h
index 9b7c328..b1fe9c8 100644
--- a/arch/arm/include/asm/mach/map.h
+++ b/arch/arm/include/asm/mach/map.h
@@ -62,6 +62,7 @@ extern int ioremap_page(unsigned long virt, unsigned long phys,
#else
#define iotable_init(map,num) do { } while (0)
#define vm_reserve_area_early(a,s,c) do { } while (0)
+#define debug_ll_io_init() do { } while (0)
#endif
#endif
--
1.9.1
^ permalink raw reply related
* [PATCH 1/4] ARM: versatile: support no-MMU mode addressing
From: Greg Ungerer @ 2016-12-07 6:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481090912-29835-1-git-send-email-gerg@uclinux.org>
Currently for the versatile boards the IO_ADDRESS() macro applies static
virtual address mapping for built-in IO devices. When operating without
the MMU enabled IO devices are accessed at their physical address, no
address translation is required.
For the !CONFIG_MMU case then define the IO_ADDRESS() macro to return the
physical address.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
---
arch/arm/mach-versatile/versatile_dt.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm/mach-versatile/versatile_dt.c b/arch/arm/mach-versatile/versatile_dt.c
index 3c8d39c..8cfa05a 100644
--- a/arch/arm/mach-versatile/versatile_dt.c
+++ b/arch/arm/mach-versatile/versatile_dt.c
@@ -37,7 +37,11 @@
#include <asm/mach/map.h>
/* macro to get at MMIO space when running virtually */
+#ifdef CONFIG_MMU
#define IO_ADDRESS(x) (((x) & 0x0fffffff) + (((x) >> 4) & 0x0f000000) + 0xf0000000)
+#else
+#define IO_ADDRESS(x) (x)
+#endif
#define __io_address(n) ((void __iomem __force *)IO_ADDRESS(n))
/*
--
1.9.1
^ permalink raw reply related
* [PATCH 0/4] arm/versatile: no-MMU support
From: Greg Ungerer @ 2016-12-07 6:08 UTC (permalink / raw)
To: linux-arm-kernel
Does the ARM Versatile machine have a maintainer?
I have CC'ed this patch set to those names reported by get_maintainer.
I had no feedback on the first posting of this series back in August.
The following patches support configuring and building the versatile
machine with a no-MMU kernel.
There is only a few minor changes required. It was previously possible
in older kernels to build for versatile with CONFIG_MMU disabled, but
the change to devicetree lost that capability. These changes make it
possible again.
One patch is a fix for address translation (broken in older kernels too),
two are build problems when CONFIG_MMU is disabled, and the last is the
actuall configuration changes needed.
The motivation for this is that the versatile machine is well supported
in qemu. And this provides an excellent platform for development and
testing no-MMU support on ARM in general. With these patches applied
it is possible to build and run a kernel with MMU disabled on qemu.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
---
arch/arm/Kconfig | 10 ++++++++++
arch/arm/Kconfig.debug | 3 ++-
arch/arm/include/asm/mach/map.h | 1 +
arch/arm/mach-versatile/Kconfig | 3 ++-
arch/arm/mach-versatile/Makefile.boot | 3 +++
arch/arm/mach-versatile/versatile_dt.c | 4 ++++
6 files changed, 22 insertions(+), 2 deletions(-)
^ permalink raw reply
* [PATCH 3/5] arm64: dts: exynos5433: Add PPMU dt node
From: Chanwoo Choi @ 2016-12-07 5:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <58478C41.5090500@samsung.com>
On 2016? 12? 07? 13:12, Chanwoo Choi wrote:
> On 2016? 12? 07? 04:07, Krzysztof Kozlowski wrote:
>> On Fri, Dec 02, 2016 at 04:18:05PM +0900, Chanwoo Choi wrote:
>>> This patch adds PPMU (Platform Performance Monitoring Unit) Device-tree node
>>> to measure the utilization of each IP in Exynos SoC.
>>>
>>> - PPMU_D{0|1}_CPU are used to measure the utilization of MIF (Memory Interface)
>>> block with VDD_MIF power source.
>>> - PPMU_D{0|1}_GENERAL are used to measure the utilization of INT(Internal)
>>> block with VDD_INT power source.
>>>
>>> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
>>> ---
>>> arch/arm64/boot/dts/exynos/exynos5433.dtsi | 24 ++++++++++++++++++++++++
>>> 1 file changed, 24 insertions(+)
>>>
>>> diff --git a/arch/arm64/boot/dts/exynos/exynos5433.dtsi b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
>>> index 64226d5ae471..8c4ee84d5232 100644
>>> --- a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
>>> +++ b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
>>> @@ -599,6 +599,30 @@
>>> clock-names = "fin_pll", "mct";
>>> };
>>>
>>> + ppmu_d0_cpu: ppmu at 10480000 {
>>> + compatible = "samsung,exynos-ppmu-v2";
>>> + reg = <0x10480000 0x2000>;
>>> + status = "disabled";
>>
>> Why these are disabled? They have some external dependencies?
>
> There is no any dependency. If you want to remain it always enabled,
> I'm OK.
One more comment. Each PPMU has the four events which is used for devfreq driver
to get the utilization. If I remove the 'status = "disabled"' from exynos5433.dtsi,
first probe of PPMU device is fail on case1.
Case1. Disable PPMU device and then enable it on exynos5433-tm2.dts
[ 2.560126] exynos-ppmu: new PPMU device registered 10490000.ppmu (ppmu-event0-d0-general)
[ 2.565957] exynos-ppmu: new PPMU device registered 104c0000.ppmu (ppmu-event0-d1-general)
Case2. Enable PPMU device always. First probe is failed and then second probe is successful.
[ 2.898781] exynos-ppmu 10480000.ppmu: failed to get child node of devfreq-event devices
[ 2.899077] exynos-ppmu 10480000.ppmu: failed to parse exynos ppmu dt node
[ 2.899289] exynos-ppmu 10480000.ppmu: failed to parse devicetree for resource
[ 2.899602] exynos-ppmu: probe of 10480000.ppmu failed with error -22
[ 2.905364] exynos-ppmu: new PPMU device registered 10490000.ppmu (ppmu-event0-d0-general)
[ 2.913535] exynos-ppmu 104b0000.ppmu: failed to get child node of devfreq-event devices
[ 2.921402] exynos-ppmu 104b0000.ppmu: failed to parse exynos ppmu dt node
[ 2.928250] exynos-ppmu 104b0000.ppmu: failed to parse devicetree for resource
[ 2.935571] exynos-ppmu: probe of 104b0000.ppmu failed with error -22
[ 2.942144] exynos-ppmu: new PPMU device registered 104c0000.ppmu (ppmu-event0-d1-general)
Best Regards,
Chanwoo Choi
[snip]
^ permalink raw reply
* [PATCH v5 5/5] [media] davinci: VPIF: add basic support for DT init
From: Kevin Hilman @ 2016-12-07 5:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161207050826.23174-1-khilman@baylibre.com>
Add basic support for initialization via DT
Signed-off-by: Kevin Hilman <khilman@baylibre.com>
---
drivers/media/platform/davinci/vpif.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/drivers/media/platform/davinci/vpif.c b/drivers/media/platform/davinci/vpif.c
index f50148dcba64..1b02a6363f77 100644
--- a/drivers/media/platform/davinci/vpif.c
+++ b/drivers/media/platform/davinci/vpif.c
@@ -467,8 +467,17 @@ static const struct dev_pm_ops vpif_pm = {
#define vpif_pm_ops NULL
#endif
+#if IS_ENABLED(CONFIG_OF)
+static const struct of_device_id vpif_of_match[] = {
+ { .compatible = "ti,da850-vpif", },
+ { /* sentinel */ },
+};
+MODULE_DEVICE_TABLE(of, vpif_of_match);
+#endif
+
static struct platform_driver vpif_driver = {
.driver = {
+ .of_match_table = of_match_ptr(vpif_of_match),
.name = VPIF_DRIVER_NAME,
.pm = vpif_pm_ops,
},
--
2.9.3
^ permalink raw reply related
* [PATCH v5 4/5] [media] dt-bindings: add TI VPIF documentation
From: Kevin Hilman @ 2016-12-07 5:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161207050826.23174-1-khilman@baylibre.com>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Kevin Hilman <khilman@baylibre.com>
---
.../devicetree/bindings/media/ti,da850-vpif.txt | 67 ++++++++++++++++++++++
1 file changed, 67 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/ti,da850-vpif.txt
diff --git a/Documentation/devicetree/bindings/media/ti,da850-vpif.txt b/Documentation/devicetree/bindings/media/ti,da850-vpif.txt
new file mode 100644
index 000000000000..fa06dfdb6898
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/ti,da850-vpif.txt
@@ -0,0 +1,67 @@
+Texas Instruments VPIF
+----------------------
+
+The TI Video Port InterFace (VPIF) is the primary component for video
+capture and display on the DA850/AM18x family of TI DaVinci/Sitara
+SoCs.
+
+TI Document reference: SPRUH82C, Chapter 35
+http://www.ti.com/lit/pdf/spruh82
+
+Required properties:
+- compatible: must be "ti,da850-vpif"
+- reg: physical base address and length of the registers set for the device;
+- interrupts: should contain IRQ line for the VPIF
+
+Video Capture:
+
+VPIF has a 16-bit parallel bus input, supporting 2 8-bit channels or a
+single 16-bit channel. It should contain at least one port child node
+with child 'endpoint' node. Please refer to the bindings defined in
+Documentation/devicetree/bindings/media/video-interfaces.txt.
+
+Example using 2 8-bit input channels, one of which is connected to an
+I2C-connected TVP5147 decoder:
+
+ vpif: vpif at 217000 {
+ compatible = "ti,da850-vpif";
+ reg = <0x217000 0x1000>;
+ interrupts = <92>;
+
+ port {
+ vpif_ch0: endpoint at 0 {
+ reg = <0>;
+ bus-width = <8>;
+ remote-endpoint = <&composite>;
+ };
+
+ vpif_ch1: endpoint at 1 {
+ reg = <1>;
+ bus-width = <8>;
+ data-shift = <8>;
+ };
+ };
+ };
+
+[ ... ]
+
+&i2c0 {
+
+ tvp5147 at 5d {
+ compatible = "ti,tvp5147";
+ reg = <0x5d>;
+ status = "okay";
+
+ port {
+ composite: endpoint {
+ hsync-active = <1>;
+ vsync-active = <1>;
+ pclk-sample = <0>;
+
+ /* VPIF channel 0 (lower 8-bits) */
+ remote-endpoint = <&vpif_ch0>;
+ bus-width = <8>;
+ };
+ };
+ };
+};
--
2.9.3
^ permalink raw reply related
* [PATCH v5 3/5] [media] davinci: vpif_capture: fix start/stop streaming locking
From: Kevin Hilman @ 2016-12-07 5:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161207050826.23174-1-khilman@baylibre.com>
Video capture subdevs may be over I2C and may sleep during xfer, so we
cannot do IRQ-disabled locking when calling the subdev.
The IRQ-disabled locking is meant to protect the DMA queue list
throughout the rest of the driver, so update the locking in
[start|stop]_streaming to protect just this list.
Suggested-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Kevin Hilman <khilman@baylibre.com>
---
drivers/media/platform/davinci/vpif_capture.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/media/platform/davinci/vpif_capture.c b/drivers/media/platform/davinci/vpif_capture.c
index c24049acd40a..f72a719efb3d 100644
--- a/drivers/media/platform/davinci/vpif_capture.c
+++ b/drivers/media/platform/davinci/vpif_capture.c
@@ -179,8 +179,6 @@ static int vpif_start_streaming(struct vb2_queue *vq, unsigned int count)
unsigned long addr, flags;
int ret;
- spin_lock_irqsave(&common->irqlock, flags);
-
/* Initialize field_id */
ch->field_id = 0;
@@ -211,6 +209,7 @@ static int vpif_start_streaming(struct vb2_queue *vq, unsigned int count)
vpif_config_addr(ch, ret);
/* Get the next frame from the buffer queue */
+ spin_lock_irqsave(&common->irqlock, flags);
common->cur_frm = common->next_frm = list_entry(common->dma_queue.next,
struct vpif_cap_buffer, list);
/* Remove buffer from the buffer queue */
@@ -244,6 +243,7 @@ static int vpif_start_streaming(struct vb2_queue *vq, unsigned int count)
return 0;
err:
+ spin_lock_irqsave(&common->irqlock, flags);
list_for_each_entry_safe(buf, tmp, &common->dma_queue, list) {
list_del(&buf->list);
vb2_buffer_done(&buf->vb.vb2_buf, VB2_BUF_STATE_QUEUED);
@@ -287,7 +287,6 @@ static void vpif_stop_streaming(struct vb2_queue *vq)
vpif_dbg(1, debug, "stream off failed in subdev\n");
/* release all active buffers */
- spin_lock_irqsave(&common->irqlock, flags);
if (common->cur_frm == common->next_frm) {
vb2_buffer_done(&common->cur_frm->vb.vb2_buf,
VB2_BUF_STATE_ERROR);
@@ -300,6 +299,7 @@ static void vpif_stop_streaming(struct vb2_queue *vq)
VB2_BUF_STATE_ERROR);
}
+ spin_lock_irqsave(&common->irqlock, flags);
while (!list_empty(&common->dma_queue)) {
common->next_frm = list_entry(common->dma_queue.next,
struct vpif_cap_buffer, list);
--
2.9.3
^ permalink raw reply related
* [PATCH v5 2/5] [media] davinci: vpif_capture: remove hard-coded I2C adapter id
From: Kevin Hilman @ 2016-12-07 5:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161207050826.23174-1-khilman@baylibre.com>
Remove hard-coded I2C adapter in favor of getting the
ID from platform_data.
Signed-off-by: Kevin Hilman <khilman@baylibre.com>
---
drivers/media/platform/davinci/vpif_capture.c | 5 ++++-
include/media/davinci/vpif_types.h | 1 +
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/media/platform/davinci/vpif_capture.c b/drivers/media/platform/davinci/vpif_capture.c
index 20c4344ed118..c24049acd40a 100644
--- a/drivers/media/platform/davinci/vpif_capture.c
+++ b/drivers/media/platform/davinci/vpif_capture.c
@@ -1486,7 +1486,10 @@ static __init int vpif_probe(struct platform_device *pdev)
}
if (!vpif_obj.config->asd_sizes) {
- i2c_adap = i2c_get_adapter(1);
+ int i2c_id = vpif_obj.config->i2c_adapter_id;
+
+ i2c_adap = i2c_get_adapter(i2c_id);
+ WARN_ON(!i2c_adap);
for (i = 0; i < subdev_count; i++) {
subdevdata = &vpif_obj.config->subdev_info[i];
vpif_obj.sd[i] =
diff --git a/include/media/davinci/vpif_types.h b/include/media/davinci/vpif_types.h
index 3cb1704a0650..4282a7db99d4 100644
--- a/include/media/davinci/vpif_types.h
+++ b/include/media/davinci/vpif_types.h
@@ -82,6 +82,7 @@ struct vpif_capture_config {
struct vpif_capture_chan_config chan_config[VPIF_CAPTURE_MAX_CHANNELS];
struct vpif_subdev_info *subdev_info;
int subdev_count;
+ int i2c_adapter_id;
const char *card_name;
struct v4l2_async_subdev **asd; /* Flat array, arranged in groups */
int *asd_sizes; /* 0-terminated array of asd group sizes */
--
2.9.3
^ permalink raw reply related
* [PATCH v5 1/5] [media] davinci: VPIF: fix module loading, init errors
From: Kevin Hilman @ 2016-12-07 5:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161207050826.23174-1-khilman@baylibre.com>
Fix problems with automatic module loading by adding MODULE_ALIAS. Also
fix various load-time errors cause by incorrect or not present
platform_data.
Signed-off-by: Kevin Hilman <khilman@baylibre.com>
---
drivers/media/platform/davinci/vpif.c | 5 ++++-
drivers/media/platform/davinci/vpif_capture.c | 15 ++++++++++++++-
drivers/media/platform/davinci/vpif_display.c | 6 ++++++
3 files changed, 24 insertions(+), 2 deletions(-)
diff --git a/drivers/media/platform/davinci/vpif.c b/drivers/media/platform/davinci/vpif.c
index 0380cf2e5775..f50148dcba64 100644
--- a/drivers/media/platform/davinci/vpif.c
+++ b/drivers/media/platform/davinci/vpif.c
@@ -32,6 +32,9 @@
MODULE_DESCRIPTION("TI DaVinci Video Port Interface driver");
MODULE_LICENSE("GPL");
+#define VPIF_DRIVER_NAME "vpif"
+MODULE_ALIAS("platform:" VPIF_DRIVER_NAME);
+
#define VPIF_CH0_MAX_MODES 22
#define VPIF_CH1_MAX_MODES 2
#define VPIF_CH2_MAX_MODES 15
@@ -466,7 +469,7 @@ static const struct dev_pm_ops vpif_pm = {
static struct platform_driver vpif_driver = {
.driver = {
- .name = "vpif",
+ .name = VPIF_DRIVER_NAME,
.pm = vpif_pm_ops,
},
.remove = vpif_remove,
diff --git a/drivers/media/platform/davinci/vpif_capture.c b/drivers/media/platform/davinci/vpif_capture.c
index 5104cc0ee40e..20c4344ed118 100644
--- a/drivers/media/platform/davinci/vpif_capture.c
+++ b/drivers/media/platform/davinci/vpif_capture.c
@@ -45,6 +45,7 @@ module_param(debug, int, 0644);
MODULE_PARM_DESC(debug, "Debug level 0-1");
#define VPIF_DRIVER_NAME "vpif_capture"
+MODULE_ALIAS("platform:" VPIF_DRIVER_NAME);
/* global variables */
static struct vpif_device vpif_obj = { {NULL} };
@@ -647,6 +648,10 @@ static int vpif_input_to_subdev(
vpif_dbg(2, debug, "vpif_input_to_subdev\n");
+ if (!chan_cfg)
+ return -1;
+ if (input_index >= chan_cfg->input_count)
+ return -1;
subdev_name = chan_cfg->inputs[input_index].subdev_name;
if (subdev_name == NULL)
return -1;
@@ -654,7 +659,7 @@ static int vpif_input_to_subdev(
/* loop through the sub device list to get the sub device info */
for (i = 0; i < vpif_cfg->subdev_count; i++) {
subdev_info = &vpif_cfg->subdev_info[i];
- if (!strcmp(subdev_info->name, subdev_name))
+ if (subdev_info && !strcmp(subdev_info->name, subdev_name))
return i;
}
return -1;
@@ -685,6 +690,9 @@ static int vpif_set_input(
if (sd_index >= 0) {
sd = vpif_obj.sd[sd_index];
subdev_info = &vpif_cfg->subdev_info[sd_index];
+ } else {
+ /* no subdevice, no input to setup */
+ return 0;
}
/* first setup input path from sub device to vpif */
@@ -1435,6 +1443,11 @@ static __init int vpif_probe(struct platform_device *pdev)
int res_idx = 0;
int i, err;
+ if (!pdev->dev.platform_data) {
+ dev_warn(&pdev->dev, "Missing platform data. Giving up.\n");
+ return -EINVAL;
+ }
+
vpif_dev = &pdev->dev;
err = initialize_vpif();
diff --git a/drivers/media/platform/davinci/vpif_display.c b/drivers/media/platform/davinci/vpif_display.c
index 75b27233ec2f..7f632b757d32 100644
--- a/drivers/media/platform/davinci/vpif_display.c
+++ b/drivers/media/platform/davinci/vpif_display.c
@@ -42,6 +42,7 @@ module_param(debug, int, 0644);
MODULE_PARM_DESC(debug, "Debug level 0-1");
#define VPIF_DRIVER_NAME "vpif_display"
+MODULE_ALIAS("platform:" VPIF_DRIVER_NAME);
/* Is set to 1 in case of SDTV formats, 2 in case of HDTV formats. */
static int ycmux_mode;
@@ -1249,6 +1250,11 @@ static __init int vpif_probe(struct platform_device *pdev)
int res_idx = 0;
int i, err;
+ if (!pdev->dev.platform_data) {
+ dev_warn(&pdev->dev, "Missing platform data. Giving up.\n");
+ return -EINVAL;
+ }
+
vpif_dev = &pdev->dev;
err = initialize_vpif();
--
2.9.3
^ permalink raw reply related
* [PATCH v5 0/5] davinci: VPIF: add DT support
From: Kevin Hilman @ 2016-12-07 5:08 UTC (permalink / raw)
To: linux-arm-kernel
Prepare the groundwork for adding DT support for davinci VPIF drivers.
This series does some fixups/cleanups and then adds the DT binding and
DT compatible string matching for DT probing.
The controversial part from previous versions around async subdev
parsing, and specifically hard-coding the input/output routing of
subdevs, has been left out of this series. That part can be done as a
follow-on step after agreement has been reached on the path forward.
With this version, platforms can still use the VPIF capture/display
drivers, but must provide platform_data for the subdevs and subdev
routing.
Tested video capture to memory on da850-lcdk board using composite
input.
Changes since v4:
- dropped controversial async subdev parsing support. That can be
done as a follow-up step after the discussions have finalized on the
right approach.
- DT binding Acked by DT maintainer (Rob H.)
- reworked locking fix (suggested by Laurent)
Changes since v3:
- move to a single VPIF node, DT binding updated accordingly
- misc fixes/updates based on reviews from Sakari
Changes since v2:
- DT binding doc: fix example to use correct compatible
Changes since v1:
- more specific compatible strings, based on SoC: ti,da850-vpif*
- fix locking bug when unlocking over subdev s_stream
Kevin Hilman (5):
[media] davinci: VPIF: fix module loading, init errors
[media] davinci: vpif_capture: remove hard-coded I2C adapter id
[media] davinci: vpif_capture: fix start/stop streaming locking
[media] dt-bindings: add TI VPIF documentation
[media] davinci: VPIF: add basic support for DT init
.../devicetree/bindings/media/ti,da850-vpif.txt | 67 ++++++++++++++++++++++
drivers/media/platform/davinci/vpif.c | 14 ++++-
drivers/media/platform/davinci/vpif_capture.c | 26 +++++++--
drivers/media/platform/davinci/vpif_display.c | 6 ++
include/media/davinci/vpif_types.h | 1 +
5 files changed, 108 insertions(+), 6 deletions(-)
create mode 100644 Documentation/devicetree/bindings/media/ti,da850-vpif.txt
--
2.9.3
^ permalink raw reply
* [PATCH 3/5] arm64: dts: exynos5433: Add PPMU dt node
From: Chanwoo Choi @ 2016-12-07 4:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161206190756.GA12683@kozik-lap>
On 2016? 12? 07? 04:07, Krzysztof Kozlowski wrote:
> On Fri, Dec 02, 2016 at 04:18:05PM +0900, Chanwoo Choi wrote:
>> This patch adds PPMU (Platform Performance Monitoring Unit) Device-tree node
>> to measure the utilization of each IP in Exynos SoC.
>>
>> - PPMU_D{0|1}_CPU are used to measure the utilization of MIF (Memory Interface)
>> block with VDD_MIF power source.
>> - PPMU_D{0|1}_GENERAL are used to measure the utilization of INT(Internal)
>> block with VDD_INT power source.
>>
>> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
>> ---
>> arch/arm64/boot/dts/exynos/exynos5433.dtsi | 24 ++++++++++++++++++++++++
>> 1 file changed, 24 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/exynos/exynos5433.dtsi b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
>> index 64226d5ae471..8c4ee84d5232 100644
>> --- a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
>> +++ b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
>> @@ -599,6 +599,30 @@
>> clock-names = "fin_pll", "mct";
>> };
>>
>> + ppmu_d0_cpu: ppmu at 10480000 {
>> + compatible = "samsung,exynos-ppmu-v2";
>> + reg = <0x10480000 0x2000>;
>> + status = "disabled";
>
> Why these are disabled? They have some external dependencies?
There is no any dependency. If you want to remain it always enabled,
I'm OK.
Best Regards,
Chanwoo Choi
>
> Best regards,
> Krzysztof
>
>> + };
>> +
>> + ppmu_d0_general: ppmu at 10490000 {
>> + compatible = "samsung,exynos-ppmu-v2";
>> + reg = <0x10490000 0x2000>;
>> + status = "disabled";
>> + };
>> +
>> + ppmu_d1_cpu: ppmu at 104b0000 {
>> + compatible = "samsung,exynos-ppmu-v2";
>> + reg = <0x104b0000 0x2000>;
>> + status = "disabled";
>> + };
>> +
>> + ppmu_d1_general: ppmu at 104c0000 {
>> + compatible = "samsung,exynos-ppmu-v2";
>> + reg = <0x104c0000 0x2000>;
>> + status = "disabled";
>> + };
>> +
>> pinctrl_alive: pinctrl at 10580000 {
>> compatible = "samsung,exynos5433-pinctrl";
>> reg = <0x10580000 0x1a20>, <0x11090000 0x100>;
>> --
>> 1.9.1
>>
>
>
>
^ permalink raw reply
* [PATCH 03/12] power_supply: axp288_charger: Replace the extcon API
From: Chanwoo Choi @ 2016-12-07 3:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161207030527.n2u4q4tf7po74clg@earth>
Hi Sebastian,
On 2016? 12? 07? 12:05, Sebastian Reichel wrote:
> Hi Chanwoo,
>
> On Tue, Dec 06, 2016 at 09:26:14AM +0900, Chanwoo Choi wrote:
>> Could you please review and pick the patch3/4 for power-supply driver?
>
> Patches look fine. As I expect the merge window to open next week I
> would rather not queue this for 4.10 and instead do it once 4.10-rc1
> has been tagged.
>
> -- Sebastian
>
Thanks for your pick up.
--
Best Regards,
Chanwoo Choi
^ permalink raw reply
* [PATCH] i2c: rk3x: keep i2c irq ON in suspend
From: David.Wu @ 2016-12-07 3:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAD=FV=VgGy5hA4+7nvLs4NPNRuopak+bTW34S6X6S_vWgtnkjg@mail.gmail.com>
Hi Doug,
? 2016/12/7 0:31, Doug Anderson ??:
> Hi,
>
> On Tue, Dec 6, 2016 at 12:12 AM, David.Wu <david.wu@rock-chips.com> wrote:
>> Hi Heiko,
>>
>> ? 2016/12/5 18:54, Heiko Stuebner ??:
>>>
>>> Hi David,
>>>
>>> Am Montag, 5. Dezember 2016, 16:02:59 CET schrieb David Wu:
>>>>
>>>> During suspend there may still be some i2c access happening.
>>>> And if we don't keep i2c irq ON, there may be i2c access timeout if
>>>> i2c is in irq mode of operation.
>>>
>>>
>>> can you describe the issue you're trying to fix a bit more please?
>>
>>
>> Sometimes we could see the i2c timeout errors during suspend/resume, which
>> makes the duration of suspend/resume too longer.
>>
>> [ 484.171541] CPU4: Booted secondary processor [410fd082]
>> [ 485.172777] rk3x-i2c ff3c0000.i2c: timeout, ipd: 0x10, state: 1
>> [ 486.172760] rk3x-i2c ff3c0000.i2c: timeout, ipd: 0x10, state: 1
>> [ 487.172759] rk3x-i2c ff3c0000.i2c: timeout, ipd: 0x10, state: 1
>> [ 487.172840] cpu cpu4: _set_opp_voltage: failed to set voltage (800000
>> 800000 800000 mV): -110
>> [ 487.172874] cpu cpu4: failed to set volt 800000
>>
>>>
>>> I.e. I'd think the i2c-core does suspend i2c-client devices first, so that
>>> these should be able to finish up their ongoing transfers and not start
>>> any
>>> new ones instead?
>>>
>>> Your irq can still happen slightly after the system started going to
>>> actually
>>> sleep, so to me it looks like you just widened the window where irqs can
>>> be
>>> handled. Especially as your irq could also just simply stem from the start
>>> state, so you cannot even be sure if your transaction actually is
>>> finished.
>>
>>
>> Okay, you are right. I want to give it a double insurance at first, but it
>> may hide the unhappend issue.
>>
>>>
>>> So to me it looks like the i2c-connected device driver should be fixed
>>> instead?
>>
>>
>> I tell them to fix it in rk808 driver.
>
> To me it seems like perhaps cpufreq should not be changing frequencies
> until it is resumed properly. Presumably if all the ordering is done
> right then cpufreq should be resumed _after_ the i2c regulator so you
> should be OK. ...or am I somehow confused about that?
yes?the cpufreq and regulator should start i2c job after they resume
properly.
>
> Also note that previous i2c busses I worked with simply returned -EIO
> in the case where they were called when suspended. See
> "i2c-exynos5.c" and "i2c-s3c2410.c".
In "i2c-exynos5.c", it seems that using the "i2c->suspended" to protect
i2c transfer works most of the time. Of course it could prevent the next
new i2c transfer to start. But in one case, if the current i2c job was
not finished until the i2c irq was disabled by system suspend, the i2c
timeout error would also happen, as the current i2c job may have a large
data to transfer and it lasts from a long time.
So is it necessary to add a mutex lock to wait the current job to be
finished before the "i2c->suspended" is changed in i2c_suspend_noirq()?
However, the i2c_suspend_noirq() is called after suspend_device_irqs()
in system suspend, it means that the i2c timeout errors could happen
during the time between suspend_device_irqs() and i2c_suspend_noirq(),
if there were i2c transfers started.
>
> -Doug
>
>
>
^ permalink raw reply
* [PATCH] n900 device tree: cleanup
From: Sebastian Reichel @ 2016-12-07 3:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161011081243.GA24580@amd>
Hi Tony,
It looks like this fell through the cracks. Apart from inconsistent
patch subject:
Reviewed-By: Sebastian Reichel <sre@kernel.org>
-- Sebastian
On Tue, Oct 11, 2016 at 10:12:43AM +0200, Pavel Machek wrote:
> Fix GPIO comment to be consistent with rest of file and add comment what
> tpa6130 is.
>
> Signed-off-by: Pavel Machek <pavel@ucw.cz>
>
> diff --git a/arch/arm/boot/dts/omap3-n900.dts b/arch/arm/boot/dts/omap3-n900.dts
> index bfffd6c..ca9fe8c 100644
> --- a/arch/arm/boot/dts/omap3-n900.dts
> +++ b/arch/arm/boot/dts/omap3-n900.dts
> @@ -47,7 +47,7 @@
> compatible = "gpio-leds";
> heartbeat {
> label = "debug::sleep";
> - gpios = <&gpio6 2 GPIO_ACTIVE_HIGH>; /* gpio162 */
> + gpios = <&gpio6 2 GPIO_ACTIVE_HIGH>; /* 162 */
> linux,default-trigger = "default-on";
> pinctrl-names = "default";
> pinctrl-0 = <&debug_leds>;
> @@ -637,6 +637,7 @@
> reg = <0x55>;
> };
>
> + /* Stereo headphone amplifier */
> tpa6130a2: tpa6130a2 at 60 {
> compatible = "ti,tpa6130a2";
> reg = <0x60>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161207/6681dd12/attachment.sig>
^ permalink raw reply
* [PATCH 03/12] power_supply: axp288_charger: Replace the extcon API
From: Sebastian Reichel @ 2016-12-07 3:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <584605A6.1010803@samsung.com>
Hi Chanwoo,
On Tue, Dec 06, 2016 at 09:26:14AM +0900, Chanwoo Choi wrote:
> Could you please review and pick the patch3/4 for power-supply driver?
Patches look fine. As I expect the merge window to open next week I
would rather not queue this for 4.10 and instead do it once 4.10-rc1
has been tagged.
-- Sebastian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161207/8511f8ce/attachment.sig>
^ permalink raw reply
* [PATCH 7/7] arm: Add livepatch necessary arch selects into Kconfig
From: Steven Rostedt @ 2016-12-07 2:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481043967-15602-8-git-send-email-abelvesa@linux.com>
On Tue, 6 Dec 2016 17:06:07 +0000
Abel Vesa <abelvesa@linux.com> wrote:
> This adds HAVE_LIVEPATCH, MODULES_USE_ELF_RELA and HAVE_LIVEPATCH
> to arm Kconfig.
>
> Signed-off-by: Abel Vesa <abelvesa@linux.com>
Patch 5, 6 and 7 really ought to be one patch.
-- Steve
^ 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