* [PATCH v6 3/5] soc: zte: Add header for PM domains specifiers
From: Baoyou Xie @ 2017-01-04 11:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483530494-14177-1-git-send-email-baoyou.xie@linaro.org>
This patch adds header with values used for ZTE 2967
SoC's power domain driver.
Signed-off-by: Baoyou Xie <baoyou.xie@linaro.org>
---
include/dt-bindings/soc/zte,pm_domains.h | 23 +++++++++++++++++++++++
1 file changed, 23 insertions(+)
create mode 100644 include/dt-bindings/soc/zte,pm_domains.h
diff --git a/include/dt-bindings/soc/zte,pm_domains.h b/include/dt-bindings/soc/zte,pm_domains.h
new file mode 100644
index 0000000..01e9abc
--- /dev/null
+++ b/include/dt-bindings/soc/zte,pm_domains.h
@@ -0,0 +1,23 @@
+/*
+ * Copyright (C) 2017 Linaro Ltd.
+ *
+ * Author: Baoyou Xie <baoyou.xie@linaro.org>
+ * License terms: GNU General Public License (GPL) version 2
+ */
+#ifndef _DT_BINDINGS_SOC_ZTE_PM_DOMAINS_H
+#define _DT_BINDINGS_SOC_ZTE_PM_DOMAINS_H
+
+#define DM_ZX296718_SAPPU 0
+#define DM_ZX296718_VDE 1 /* g1v6 */
+#define DM_ZX296718_VCE 2 /* h1v6 */
+#define DM_ZX296718_HDE 3 /* g2v2 */
+#define DM_ZX296718_VIU 4
+#define DM_ZX296718_USB20 5
+#define DM_ZX296718_USB21 6
+#define DM_ZX296718_USB30 7
+#define DM_ZX296718_HSIC 8
+#define DM_ZX296718_GMAC 9
+#define DM_ZX296718_TS 10
+#define DM_ZX296718_VOU 11
+
+#endif /* _DT_BINDINGS_SOC_ZTE_PM_DOMAINS_H */
--
2.7.4
^ permalink raw reply related
* [PATCH v6 4/5] soc: zte: pm_domains: Prepare for supporting ARMv8 zx2967 family
From: Baoyou Xie @ 2017-01-04 11:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483530494-14177-1-git-send-email-baoyou.xie@linaro.org>
The ARMv8 zx2967 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/zx2967_pm_domains.c | 142 ++++++++++++++++++++++++++++++++++++
drivers/soc/zte/zx2967_pm_domains.h | 44 +++++++++++
6 files changed, 205 insertions(+)
create mode 100644 drivers/soc/zte/Kconfig
create mode 100644 drivers/soc/zte/Makefile
create mode 100644 drivers/soc/zte/zx2967_pm_domains.c
create mode 100644 drivers/soc/zte/zx2967_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..20bde38
--- /dev/null
+++ b/drivers/soc/zte/Kconfig
@@ -0,0 +1,13 @@
+#
+# ZTE SoC drivers
+#
+menuconfig SOC_ZTE
+ bool "ZTE SoC driver support"
+
+if SOC_ZTE
+
+config ZX2967_PM_DOMAINS
+ bool "ZX2967 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..8a37f2f
--- /dev/null
+++ b/drivers/soc/zte/Makefile
@@ -0,0 +1,4 @@
+#
+# ZTE SOC drivers
+#
+obj-$(CONFIG_ZX2967_PM_DOMAINS) += zx2967_pm_domains.o
diff --git a/drivers/soc/zte/zx2967_pm_domains.c b/drivers/soc/zte/zx2967_pm_domains.c
new file mode 100644
index 0000000..f190a62
--- /dev/null
+++ b/drivers/soc/zte/zx2967_pm_domains.c
@@ -0,0 +1,142 @@
+/*
+ * Copyright (C) 2017 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 "zx2967_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_ACK_SYNC(zpd) ((zpd)->reg_offset[REG_ACK_SYNC])
+
+static void __iomem *pcubase;
+
+int zx2967_power_on(struct generic_pm_domain *domain)
+{
+ struct zx2967_pm_domain *zpd = (struct zx2967_pm_domain *)domain;
+ unsigned long loop = 1000;
+ u32 val;
+
+ val = readl_relaxed(pcubase + PCU_DM_PWREN(zpd));
+ if (zpd->polarity == PWREN)
+ val |= BIT(zpd->bit);
+ else
+ val &= ~BIT(zpd->bit);
+ writel_relaxed(val, pcubase + PCU_DM_PWREN(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, 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, pcubase + PCU_DM_CLKEN(zpd));
+ udelay(5);
+
+ pr_debug("poweron %s\n", domain->name);
+
+ return 0;
+}
+
+int zx2967_power_off(struct generic_pm_domain *domain)
+{
+ struct zx2967_pm_domain *zpd = (struct zx2967_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, 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);
+
+ val = readl_relaxed(pcubase + PCU_DM_PWREN(zpd));
+ if (zpd->polarity == PWREN)
+ val &= ~BIT(zpd->bit);
+ else
+ val |= BIT(zpd->bit);
+ writel_relaxed(val, pcubase + PCU_DM_PWREN(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_debug("poweroff %s\n", domain->name);
+
+ return 0;
+}
+
+int zx2967_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);
+ pcubase = devm_ioremap_resource(&pdev->dev, res);
+ if (IS_ERR(pcubase)) {
+ dev_err(&pdev->dev, "ioremap fail.\n");
+ return PTR_ERR(pcubase);
+ }
+
+ for (i = 0; i < domain_num; ++i) {
+ zx_pm_domains[i]->power_on = zx2967_power_on;
+ zx_pm_domains[i]->power_off = zx2967_power_off;
+
+ 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/zx2967_pm_domains.h b/drivers/soc/zte/zx2967_pm_domains.h
new file mode 100644
index 0000000..cb46595
--- /dev/null
+++ b/drivers/soc/zte/zx2967_pm_domains.h
@@ -0,0 +1,44 @@
+/*
+ * Header for ZTE's Power Domain Driver support
+ *
+ * Copyright (C) 2017 ZTE Ltd.
+ *
+ * Author: Baoyou Xie <baoyou.xie@linaro.org>
+ * License terms: GNU General Public License (GPL) version 2
+ */
+
+#ifndef __ZTE_ZX2967_PM_DOMAIN_H
+#define __ZTE_ZX2967_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 zx2967_power_polarity {
+ PWREN,
+ PWRDN,
+};
+
+struct zx2967_pm_domain {
+ struct generic_pm_domain dm;
+ const u16 bit;
+ const enum zx2967_power_polarity polarity;
+ const u16 *reg_offset;
+};
+
+int zx2967_pd_probe(struct platform_device *pdev,
+ struct generic_pm_domain **zx_pm_domains,
+ int domain_num);
+
+#endif /* __ZTE_ZX2967_PM_DOMAIN_H */
--
2.7.4
^ permalink raw reply related
* [PATCH v6 5/5] soc: zte: pm_domains: Add support for zx296718
From: Baoyou Xie @ 2017-01-04 11:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483530494-14177-1-git-send-email-baoyou.xie@linaro.org>
This patch introduces the power domain driver of zx296718
which belongs to zte's zx2967 family.
Signed-off-by: Baoyou Xie <baoyou.xie@linaro.org>
Reviewed-by: Jun Nie <jun.nie@linaro.org>
---
drivers/soc/zte/Makefile | 1 +
drivers/soc/zte/zx296718_pm_domains.c | 181 ++++++++++++++++++++++++++++++++++
2 files changed, 182 insertions(+)
create mode 100644 drivers/soc/zte/zx296718_pm_domains.c
diff --git a/drivers/soc/zte/Makefile b/drivers/soc/zte/Makefile
index 8a37f2f..96b7cd4 100644
--- a/drivers/soc/zte/Makefile
+++ b/drivers/soc/zte/Makefile
@@ -2,3 +2,4 @@
# ZTE SOC drivers
#
obj-$(CONFIG_ZX2967_PM_DOMAINS) += zx2967_pm_domains.o
+obj-$(CONFIG_ZX2967_PM_DOMAINS) += 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..52003ee
--- /dev/null
+++ b/drivers/soc/zte/zx296718_pm_domains.c
@@ -0,0 +1,181 @@
+/*
+ * Copyright (C) 2017 ZTE Ltd.
+ *
+ * Author: Baoyou Xie <baoyou.xie@linaro.org>
+ * License terms: GNU General Public License (GPL) version 2
+ */
+#include <dt-bindings/soc/zte,pm_domains.h>
+#include "zx2967_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 zx2967_pm_domain vou_domain = {
+ .dm = {
+ .name = "vou_domain",
+ },
+ .bit = PCU_DM_VOU,
+ .polarity = PWREN,
+ .reg_offset = zx296718_offsets,
+};
+
+static struct zx2967_pm_domain sappu_domain = {
+ .dm = {
+ .name = "sappu_domain",
+ },
+ .bit = PCU_DM_SAPPU,
+ .polarity = PWREN,
+ .reg_offset = zx296718_offsets,
+};
+
+static struct zx2967_pm_domain vde_domain = {
+ .dm = {
+ .name = "vde_domain",
+ },
+ .bit = PCU_DM_VDE,
+ .polarity = PWREN,
+ .reg_offset = zx296718_offsets,
+};
+
+static struct zx2967_pm_domain vce_domain = {
+ .dm = {
+ .name = "vce_domain",
+ },
+ .bit = PCU_DM_VCE,
+ .polarity = PWREN,
+ .reg_offset = zx296718_offsets,
+};
+
+static struct zx2967_pm_domain hde_domain = {
+ .dm = {
+ .name = "hde_domain",
+ },
+ .bit = PCU_DM_HDE,
+ .polarity = PWREN,
+ .reg_offset = zx296718_offsets,
+};
+
+static struct zx2967_pm_domain viu_domain = {
+ .dm = {
+ .name = "viu_domain",
+ },
+ .bit = PCU_DM_VIU,
+ .polarity = PWREN,
+ .reg_offset = zx296718_offsets,
+};
+
+static struct zx2967_pm_domain usb20_domain = {
+ .dm = {
+ .name = "usb20_domain",
+ },
+ .bit = PCU_DM_USB20,
+ .polarity = PWREN,
+ .reg_offset = zx296718_offsets,
+};
+
+static struct zx2967_pm_domain usb21_domain = {
+ .dm = {
+ .name = "usb21_domain",
+ },
+ .bit = PCU_DM_USB21,
+ .polarity = PWREN,
+ .reg_offset = zx296718_offsets,
+};
+
+static struct zx2967_pm_domain usb30_domain = {
+ .dm = {
+ .name = "usb30_domain",
+ },
+ .bit = PCU_DM_USB30,
+ .polarity = PWREN,
+ .reg_offset = zx296718_offsets,
+};
+
+static struct zx2967_pm_domain hsic_domain = {
+ .dm = {
+ .name = "hsic_domain",
+ },
+ .bit = PCU_DM_HSIC,
+ .polarity = PWREN,
+ .reg_offset = zx296718_offsets,
+};
+
+static struct zx2967_pm_domain gmac_domain = {
+ .dm = {
+ .name = "gmac_domain",
+ },
+ .bit = PCU_DM_GMAC,
+ .polarity = PWREN,
+ .reg_offset = zx296718_offsets,
+};
+
+static struct zx2967_pm_domain ts_domain = {
+ .dm = {
+ .name = "ts_domain",
+ },
+ .bit = PCU_DM_TS,
+ .polarity = PWREN,
+ .reg_offset = zx296718_offsets,
+};
+
+static 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 zx2967_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] arm64: errata: Check for --fix-cortex-a53-843419 and --fix-cortex-a53
From: Will Deacon @ 2017-01-04 11:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <c4f5b650-b210-8332-e6f2-4ad9634818b9@gmail.com>
Hi Florian,
On Wed, Dec 28, 2016 at 12:17:23PM -0800, Florian Fainelli wrote:
> On 11/03/2016 10:20 AM, Florian Fainelli wrote:
> > On 11/03/2016 07:16 AM, Will Deacon wrote:
> >> If you can't change toolchain and you want this worked around, why can't you
> >> either build gold with it enabled by default, or pass the extra flag on the
> >> command line to the kernel build system?
> >
> > Because that creates a distribution problem and now we have to document
> > this for people who want to build a kernel on their own, without
> > necessarily understanding if this is something they might need, or why
> > this is needed, and why the kernel is not taking care of that on its
> > own? So yes, this comes down to who is responsible for what, in that
> > case the kernel's Makefile is the best place where to put such knowledge
> > as to which workaround needs to be enabled by the linker and it
> > simplifies things a lot for people.
>
> Was this convincing enough for Catalin to pick Markus' patch or does
> that mean this patch needs to remain out of tree for us because of using
> a slightly older toolchain?
I thought more about this last night, and there are two questions that
might sway me:
1. How prevalent is the binary toolchain with this issue? Is it, for
example, shipping as part of a publicly available LTS distribution?
I know you quoted some Linaro build, but I can't actually find those
binaries on their website.
2. Could we extend the Makefile magic to detect that, not only is
--fix-cortex-a53-843419 unsupported, but also that the linker is
in fact gold?
Will
^ permalink raw reply
* [PATCH 02/22] mfd: axp20x: add ADC data regs to volatile regs for AXP22X
From: Lee Jones @ 2017-01-04 11:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170102163723.7939-3-quentin.schulz@free-electrons.com>
On Mon, 02 Jan 2017, Quentin Schulz wrote:
> The AXP22X PMICs have multiple ADCs, each one exposing data from the
> different power supplies connected to the PMIC.
>
> This adds the different ADC data registers to the volatile registers of
> the AXP22X PMIC.
>
> Signed-off-by: Quentin Schulz <quentin.schulz@free-electrons.com>
For my own reference:
Acked-for-MFD-by: Lee Jones <lee.jones@linaro.org>
> ---
> drivers/mfd/axp20x.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
> index 619a83e..a33db5e 100644
> --- a/drivers/mfd/axp20x.c
> +++ b/drivers/mfd/axp20x.c
> @@ -100,6 +100,7 @@ static const struct regmap_range axp22x_writeable_ranges[] = {
> static const struct regmap_range axp22x_volatile_ranges[] = {
> regmap_reg_range(AXP20X_PWR_INPUT_STATUS, AXP20X_PWR_OP_MODE),
> regmap_reg_range(AXP20X_VBUS_IPSOUT_MGMT, AXP20X_VBUS_IPSOUT_MGMT),
> + regmap_reg_range(AXP22X_TEMP_ADC_H, AXP20X_BATT_DISCHRG_I_L),
> regmap_reg_range(AXP20X_IRQ1_EN, AXP20X_IRQ5_STATE),
> regmap_reg_range(AXP22X_GPIO_STATE, AXP22X_GPIO_STATE),
> regmap_reg_range(AXP22X_PMIC_ADC_H, AXP20X_IPSOUT_V_HIGH_L),
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH 04/22] mfd: axp20x: add ADC cells for AXP20X and AXP22X PMICs
From: Lee Jones @ 2017-01-04 11:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170102163723.7939-5-quentin.schulz@free-electrons.com>
On Mon, 02 Jan 2017, Quentin Schulz wrote:
> This adds the AXP20X/AXP22x ADCs driver to the mfd cells of the AXP209,
> AXP221 and AXP223 MFD.
>
> Signed-off-by: Quentin Schulz <quentin.schulz@free-electrons.com>
> ---
> drivers/mfd/axp20x.c | 9 +++++++++
> 1 file changed, 9 insertions(+)
Applied, thanks.
> diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
> index a33db5e..31a84d81 100644
> --- a/drivers/mfd/axp20x.c
> +++ b/drivers/mfd/axp20x.c
> @@ -582,6 +582,9 @@ static struct mfd_cell axp20x_cells[] = {
> }, {
> .name = "axp20x-regulator",
> }, {
> + .name = "axp20x-adc",
> + .of_compatible = "x-powers,axp209-adc",
> + }, {
> .name = "axp20x-ac-power-supply",
> .of_compatible = "x-powers,axp202-ac-power-supply",
> .num_resources = ARRAY_SIZE(axp20x_ac_power_supply_resources),
> @@ -602,6 +605,9 @@ static struct mfd_cell axp221_cells[] = {
> }, {
> .name = "axp20x-regulator",
> }, {
> + .name = "axp20x-adc",
> + .of_compatible = "x-powers,axp221-adc"
> + }, {
> .name = "axp20x-usb-power-supply",
> .of_compatible = "x-powers,axp221-usb-power-supply",
> .num_resources = ARRAY_SIZE(axp22x_usb_power_supply_resources),
> @@ -615,6 +621,9 @@ static struct mfd_cell axp223_cells[] = {
> .num_resources = ARRAY_SIZE(axp22x_pek_resources),
> .resources = axp22x_pek_resources,
> }, {
> + .name = "axp20x-adc",
> + .of_compatible = "x-powers,axp221-adc"
> + }, {
> .name = "axp20x-regulator",
> }, {
> .name = "axp20x-usb-power-supply",
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH 04/22] mfd: axp20x: add ADC cells for AXP20X and AXP22X PMICs
From: Lee Jones @ 2017-01-04 11:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170104115602.GB24058@dell>
On Wed, 04 Jan 2017, Lee Jones wrote:
> On Mon, 02 Jan 2017, Quentin Schulz wrote:
>
> > This adds the AXP20X/AXP22x ADCs driver to the mfd cells of the AXP209,
> > AXP221 and AXP223 MFD.
> >
> > Signed-off-by: Quentin Schulz <quentin.schulz@free-electrons.com>
> > ---
> > drivers/mfd/axp20x.c | 9 +++++++++
> > 1 file changed, 9 insertions(+)
>
> Applied, thanks.
Whoops, wrong key combo! Should have been:
For my own reference:
Acked-for-MFD-by: Lee Jones <lee.jones@linaro.org>
> > diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
> > index a33db5e..31a84d81 100644
> > --- a/drivers/mfd/axp20x.c
> > +++ b/drivers/mfd/axp20x.c
> > @@ -582,6 +582,9 @@ static struct mfd_cell axp20x_cells[] = {
> > }, {
> > .name = "axp20x-regulator",
> > }, {
> > + .name = "axp20x-adc",
> > + .of_compatible = "x-powers,axp209-adc",
> > + }, {
> > .name = "axp20x-ac-power-supply",
> > .of_compatible = "x-powers,axp202-ac-power-supply",
> > .num_resources = ARRAY_SIZE(axp20x_ac_power_supply_resources),
> > @@ -602,6 +605,9 @@ static struct mfd_cell axp221_cells[] = {
> > }, {
> > .name = "axp20x-regulator",
> > }, {
> > + .name = "axp20x-adc",
> > + .of_compatible = "x-powers,axp221-adc"
> > + }, {
> > .name = "axp20x-usb-power-supply",
> > .of_compatible = "x-powers,axp221-usb-power-supply",
> > .num_resources = ARRAY_SIZE(axp22x_usb_power_supply_resources),
> > @@ -615,6 +621,9 @@ static struct mfd_cell axp223_cells[] = {
> > .num_resources = ARRAY_SIZE(axp22x_pek_resources),
> > .resources = axp22x_pek_resources,
> > }, {
> > + .name = "axp20x-adc",
> > + .of_compatible = "x-powers,axp221-adc"
> > + }, {
> > .name = "axp20x-regulator",
> > }, {
> > .name = "axp20x-usb-power-supply",
>
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH 09/22] mfd: axp20x: add AC power supply cells for AXP22X PMICs
From: Lee Jones @ 2017-01-04 11:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170102163723.7939-10-quentin.schulz@free-electrons.com>
On Mon, 02 Jan 2017, Quentin Schulz wrote:
> The X-Powers AXP20X and AXP22X PMICs expose the status of AC power
> supply.
>
> This adds the AC power supply driver to the MFD cells of the AXP22X
> PMICs.
>
> Signed-off-by: Quentin Schulz <quentin.schulz@free-electrons.com>
> ---
> drivers/mfd/axp20x.c | 10 ++++++++++
> 1 file changed, 10 insertions(+)
For my own reference:
Acked-for-MFD-by: Lee Jones <lee.jones@linaro.org>
> diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
> index 31a84d81..65c57d0 100644
> --- a/drivers/mfd/axp20x.c
> +++ b/drivers/mfd/axp20x.c
> @@ -608,6 +608,11 @@ static struct mfd_cell axp221_cells[] = {
> .name = "axp20x-adc",
> .of_compatible = "x-powers,axp221-adc"
> }, {
> + .name = "axp20x-ac-power-supply",
> + .of_compatible = "x-powers,axp221-ac-power-supply",
> + .num_resources = ARRAY_SIZE(axp20x_ac_power_supply_resources),
> + .resources = axp20x_ac_power_supply_resources,
> + }, {
> .name = "axp20x-usb-power-supply",
> .of_compatible = "x-powers,axp221-usb-power-supply",
> .num_resources = ARRAY_SIZE(axp22x_usb_power_supply_resources),
> @@ -626,6 +631,11 @@ static struct mfd_cell axp223_cells[] = {
> }, {
> .name = "axp20x-regulator",
> }, {
> + .name = "axp20x-ac-power-supply",
> + .of_compatible = "x-powers,axp221-ac-power-supply",
> + .num_resources = ARRAY_SIZE(axp20x_ac_power_supply_resources),
> + .resources = axp20x_ac_power_supply_resources,
> + }, {
> .name = "axp20x-usb-power-supply",
> .of_compatible = "x-powers,axp223-usb-power-supply",
> .num_resources = ARRAY_SIZE(axp22x_usb_power_supply_resources),
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH 15/22] mfd: axp20x: add CHRG_CTRL1 to writeable regs for AXP20X/AXP22X
From: Lee Jones @ 2017-01-04 11:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170102163723.7939-16-quentin.schulz@free-electrons.com>
On Mon, 02 Jan 2017, Quentin Schulz wrote:
> The CHR_CTRL1 register is made of 7 read-write bits with one being used
> to set the target voltage for battery charging.
>
> This adds the CHRG_CTRL1 register to the list of writeable registers for
> AXP20X and AXP22X PMICs.
>
> Signed-off-by: Quentin Schulz <quentin.schulz@free-electrons.com>
> ---
> drivers/mfd/axp20x.c | 2 ++
> 1 file changed, 2 insertions(+)
For my own reference:
Acked-for-MFD-by: Lee Jones <lee.jones@linaro.org>
> diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
> index 65c57d0..19bdba3 100644
> --- a/drivers/mfd/axp20x.c
> +++ b/drivers/mfd/axp20x.c
> @@ -66,6 +66,7 @@ static const struct regmap_access_table axp152_volatile_table = {
> static const struct regmap_range axp20x_writeable_ranges[] = {
> regmap_reg_range(AXP20X_DATACACHE(0), AXP20X_IRQ5_STATE),
> regmap_reg_range(AXP20X_VBUS_IPSOUT_MGMT, AXP20X_VBUS_IPSOUT_MGMT),
> + regmap_reg_range(AXP20X_CHRG_CTRL1, AXP20X_CHRG_CTRL1),
> regmap_reg_range(AXP20X_DCDC_MODE, AXP20X_FG_RES),
> regmap_reg_range(AXP20X_RDC_H, AXP20X_OCV(AXP20X_OCV_MAX)),
> };
> @@ -94,6 +95,7 @@ static const struct regmap_access_table axp20x_volatile_table = {
> static const struct regmap_range axp22x_writeable_ranges[] = {
> regmap_reg_range(AXP20X_DATACACHE(0), AXP20X_IRQ5_STATE),
> regmap_reg_range(AXP20X_VBUS_IPSOUT_MGMT, AXP20X_VBUS_IPSOUT_MGMT),
> + regmap_reg_range(AXP20X_CHRG_CTRL1, AXP20X_CHRG_CTRL1),
> regmap_reg_range(AXP20X_DCDC_MODE, AXP22X_BATLOW_THRES1),
> };
>
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH 16/22] mfd: axp20x: add V_OFF to writeable regs for AXP20X and AXP22X
From: Lee Jones @ 2017-01-04 11:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170102163723.7939-17-quentin.schulz@free-electrons.com>
On Mon, 02 Jan 2017, Quentin Schulz wrote:
> The V_OFF register has its first 3 read-write bits for the minimal
> voltage (Voff) of the battery before the system is automatically shut
> down due to the power being too low.
>
> This adds V_OFF register to the writeable registers of AXP20X and AXP22X
> PMICs.
>
> Signed-off-by: Quentin Schulz <quentin.schulz@free-electrons.com>
> ---
> drivers/mfd/axp20x.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
For my own reference:
Acked-for-MFD-by: Lee Jones <lee.jones@linaro.org>
> diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
> index 19bdba3..7f0f05f 100644
> --- a/drivers/mfd/axp20x.c
> +++ b/drivers/mfd/axp20x.c
> @@ -65,7 +65,7 @@ static const struct regmap_access_table axp152_volatile_table = {
>
> static const struct regmap_range axp20x_writeable_ranges[] = {
> regmap_reg_range(AXP20X_DATACACHE(0), AXP20X_IRQ5_STATE),
> - regmap_reg_range(AXP20X_VBUS_IPSOUT_MGMT, AXP20X_VBUS_IPSOUT_MGMT),
> + regmap_reg_range(AXP20X_VBUS_IPSOUT_MGMT, AXP20X_V_OFF),
> regmap_reg_range(AXP20X_CHRG_CTRL1, AXP20X_CHRG_CTRL1),
> regmap_reg_range(AXP20X_DCDC_MODE, AXP20X_FG_RES),
> regmap_reg_range(AXP20X_RDC_H, AXP20X_OCV(AXP20X_OCV_MAX)),
> @@ -94,7 +94,7 @@ static const struct regmap_access_table axp20x_volatile_table = {
> /* AXP22x ranges are shared with the AXP809, as they cover the same range */
> static const struct regmap_range axp22x_writeable_ranges[] = {
> regmap_reg_range(AXP20X_DATACACHE(0), AXP20X_IRQ5_STATE),
> - regmap_reg_range(AXP20X_VBUS_IPSOUT_MGMT, AXP20X_VBUS_IPSOUT_MGMT),
> + regmap_reg_range(AXP20X_VBUS_IPSOUT_MGMT, AXP20X_V_OFF),
> regmap_reg_range(AXP20X_CHRG_CTRL1, AXP20X_CHRG_CTRL1),
> regmap_reg_range(AXP20X_DCDC_MODE, AXP22X_BATLOW_THRES1),
> };
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH 18/22] mfd: axp20x: add MFD cells for AXP20X and AXP22X battery driver
From: Lee Jones @ 2017-01-04 11:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170102163723.7939-19-quentin.schulz@free-electrons.com>
On Mon, 02 Jan 2017, Quentin Schulz wrote:
> The X-Powers AXP20X and AXP22X PMICs can have a battery as power supply.
>
> This patch adds the AXP20X/AXP22X battery driver to the MFD cells of the
> AXP209, AXP221 and AXP223 MFD.
>
> Signed-off-by: Quentin Schulz <quentin.schulz@free-electrons.com>
> ---
> drivers/mfd/axp20x.c | 9 +++++++++
> 1 file changed, 9 insertions(+)
For my own reference:
Acked-for-MFD-by: Lee Jones <lee.jones@linaro.org>
> diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
> index 7f0f05f..8730fc2 100644
> --- a/drivers/mfd/axp20x.c
> +++ b/drivers/mfd/axp20x.c
> @@ -587,6 +587,9 @@ static struct mfd_cell axp20x_cells[] = {
> .name = "axp20x-adc",
> .of_compatible = "x-powers,axp209-adc",
> }, {
> + .name = "axp20x-battery-power-supply",
> + .of_compatible = "x-powers,axp209-battery-power-supply",
> + }, {
> .name = "axp20x-ac-power-supply",
> .of_compatible = "x-powers,axp202-ac-power-supply",
> .num_resources = ARRAY_SIZE(axp20x_ac_power_supply_resources),
> @@ -615,6 +618,9 @@ static struct mfd_cell axp221_cells[] = {
> .num_resources = ARRAY_SIZE(axp20x_ac_power_supply_resources),
> .resources = axp20x_ac_power_supply_resources,
> }, {
> + .name = "axp20x-battery-power-supply",
> + .of_compatible = "x-powers,axp221-battery-power-supply",
> + }, {
> .name = "axp20x-usb-power-supply",
> .of_compatible = "x-powers,axp221-usb-power-supply",
> .num_resources = ARRAY_SIZE(axp22x_usb_power_supply_resources),
> @@ -631,6 +637,9 @@ static struct mfd_cell axp223_cells[] = {
> .name = "axp20x-adc",
> .of_compatible = "x-powers,axp221-adc"
> }, {
> + .name = "axp20x-battery-power-supply",
> + .of_compatible = "x-powers,axp221-battery-power-supply",
> + }, {
> .name = "axp20x-regulator",
> }, {
> .name = "axp20x-ac-power-supply",
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* arm64: virt_to_page() does not return right page for a kernel image address
From: Pratyush Anand @ 2017-01-04 11:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170104111119.GD8329@leverpostej>
Hi Mark,
On Wednesday 04 January 2017 04:41 PM, Mark Rutland wrote:
> Other than the (new) crypto test and the (not yet upstream) kdump
> patches, does any code rely on virt_to_page() working for a kernel image
> address? If so, and if we cannot fix those in the short term, we may
> want to temporarily revert commit 9f2875912dac35d9 until those are fixed
> up.
>
> Regardless, I think that the kdump code should not rely on
> virt_to_page() for a kernel image (or kmap) result.
Its not the kdump code which is relying on virt_to_page() for a kernel
image.
Its only crypto test which does that. In the first kernel (none kdump
case) also crypto test gets a wrong kmap_atomic() address, however
luckily there exists an entry for that address in page table and so a
valid corresponding physical location. Therefore, it is just that we do
not see the crash. I see still the crypto test failure print in the 1st
kernel.
However, in crash kernel there was no valid physical address and so the
kernel crashed.
~Pratyush
^ permalink raw reply
* [PATCH] mailbox: sti: Fix mbox-names copy and paste error
From: Lee Jones @ 2017-01-04 12:05 UTC (permalink / raw)
To: linux-arm-kernel
Due to an over-sight, mbox-names has become mbox-name in some instances.
Let's put it right.
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
Documentation/devicetree/bindings/mailbox/sti-mailbox.txt | 4 ++--
arch/arm/boot/dts/stih407-family.dtsi | 8 ++++----
drivers/mailbox/mailbox-sti.c | 2 +-
3 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/Documentation/devicetree/bindings/mailbox/sti-mailbox.txt b/Documentation/devicetree/bindings/mailbox/sti-mailbox.txt
index 351f612..648d176 100644
--- a/Documentation/devicetree/bindings/mailbox/sti-mailbox.txt
+++ b/Documentation/devicetree/bindings/mailbox/sti-mailbox.txt
@@ -9,7 +9,7 @@ Controller
Required properties:
- compatible : Should be "st,stih407-mailbox"
- reg : Offset and length of the device's register set
-- mbox-name : Name of the mailbox
+- mbox-names : Name of the mailbox
- #mbox-cells: : Must be 2
<&phandle instance channel direction>
phandle : Label name of controller
@@ -26,7 +26,7 @@ mailbox0: mailbox at 0 {
reg = <0x08f00000 0x1000>;
interrupts = <GIC_SPI 1 IRQ_TYPE_NONE>;
#mbox-cells = <2>;
- mbox-name = "a9";
+ mbox-names = "a9";
};
Client
diff --git a/arch/arm/boot/dts/stih407-family.dtsi b/arch/arm/boot/dts/stih407-family.dtsi
index c8b2944..00c67d4 100644
--- a/arch/arm/boot/dts/stih407-family.dtsi
+++ b/arch/arm/boot/dts/stih407-family.dtsi
@@ -787,7 +787,7 @@
reg = <0x8f00000 0x1000>;
interrupts = <GIC_SPI 1 IRQ_TYPE_NONE>;
#mbox-cells = <2>;
- mbox-name = "a9";
+ mbox-names = "a9";
status = "okay";
};
@@ -795,7 +795,7 @@
compatible = "st,stih407-mailbox";
reg = <0x8f01000 0x1000>;
#mbox-cells = <2>;
- mbox-name = "st231_gp_1";
+ mbox-names = "st231_gp_1";
status = "okay";
};
@@ -803,7 +803,7 @@
compatible = "st,stih407-mailbox";
reg = <0x8f02000 0x1000>;
#mbox-cells = <2>;
- mbox-name = "st231_gp_0";
+ mbox-names = "st231_gp_0";
status = "okay";
};
@@ -811,7 +811,7 @@
compatible = "st,stih407-mailbox";
reg = <0x8f03000 0x1000>;
#mbox-cells = <2>;
- mbox-name = "st231_audio_video";
+ mbox-names = "st231_audio_video";
status = "okay";
};
diff --git a/drivers/mailbox/mailbox-sti.c b/drivers/mailbox/mailbox-sti.c
index 41bcd33..e532a98 100644
--- a/drivers/mailbox/mailbox-sti.c
+++ b/drivers/mailbox/mailbox-sti.c
@@ -434,7 +434,7 @@ static int sti_mbox_probe(struct platform_device *pdev)
if (IS_ERR(mdev->base))
return PTR_ERR(mdev->base);
- ret = of_property_read_string(np, "mbox-name", &mdev->name);
+ ret = of_property_read_string(np, "mbox-names", &mdev->name);
if (ret)
mdev->name = np->full_name;
--
2.10.2
^ permalink raw reply related
* arm64: virt_to_page() does not return right page for a kernel image address
From: Mark Rutland @ 2017-01-04 12:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <c23ad459-9dab-2085-2e0d-91ad4cedc987@redhat.com>
On Wed, Jan 04, 2017 at 05:28:32PM +0530, Pratyush Anand wrote:
> Hi Mark,
Hi Pratyush,
> On Wednesday 04 January 2017 04:41 PM, Mark Rutland wrote:
> >Other than the (new) crypto test and the (not yet upstream) kdump
> >patches, does any code rely on virt_to_page() working for a kernel image
> >address? If so, and if we cannot fix those in the short term, we may
> >want to temporarily revert commit 9f2875912dac35d9 until those are fixed
> >up.
> >
> >Regardless, I think that the kdump code should not rely on
> >virt_to_page() for a kernel image (or kmap) result.
>
> Its not the kdump code which is relying on virt_to_page() for a
> kernel image.
Sorry, I had misread the above. I understand now.
> Its only crypto test which does that. In the first kernel (none
> kdump case) also crypto test gets a wrong kmap_atomic() address,
> however luckily there exists an entry for that address in page table
> and so a valid corresponding physical location. Therefore, it is
> just that we do not see the crash. I see still the crypto test
> failure print in the 1st kernel.
> However, in crash kernel there was no valid physical address and so
> the kernel crashed.
So it seems we need to fix the crypto test.
Looking at crypto/testmgr.c, I can't spot the kmap_atomic() or the
page_address()/virt_to_page(). I guess that's hidden behind helpers,
which might also be used elsewhere?
Could you elaborate on where exactly the problem is in the crypto test?
Thanks,
Mark.
^ permalink raw reply
* arm64: virt_to_page() does not return right page for a kernel image address
From: Catalin Marinas @ 2017-01-04 12:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAHB_GuqqXqVu4i4eCZ3V_d8JbdSO6rjWpA_B0NMJsNc_Zw0Niw@mail.gmail.com>
On Wed, Jan 04, 2017 at 11:19:38AM +0530, Pratyush Anand wrote:
> I noticed that on arm64 kmap_atomic() does not return correct address
> corresponding to a page located in data section. It causes crash in
> kdump kernel with v29 kdump patches. crash happens in a newly
> implemented crypto test [1], and the same test fails(even though it
> does not crash) in 1st kernel as well.
>
> Further debugging showed that the physical address returned by
> virt_to_phys(kaddr) and virt_to_phys(kmap_atomic(virt_to_page(kaddr))
> + offset_in_page(kaddr)) are not same.
>
> Mark Rutland thinks(IRC :#armlinux) that _virt_to_pgoff *only* handles
> linear addresses, and not kernel image addresses. However, we have to
> ask if it should?
It looks like we have a different behaviour for virt_to_page() depending
on whether CONFIG_SPARSEMEM_VMEMMAP is defined.
We've had some discussions about a month ago on whether we should allow
virt_to_phys() on kernel addresses and requiring that __pa_symbol() is
used instead but I forgot on what the decision was (if any). It seems
that we have other cases as well that need to be addressed, in which
case it may be better to simply allow virt_to_page/phys on kernel
symbols.
--
Catalin
^ permalink raw reply
* [GIT PULL] DaVinci fixes for v4.10
From: Sekhar Nori @ 2017-01-04 12:13 UTC (permalink / raw)
To: linux-arm-kernel
The following changes since commit 0c744ea4f77d72b3dcebb7a8f2684633ec79be88:
Linux 4.10-rc2 (2017-01-01 14:31:53 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci.git tags/davinci-fixes-for-v4.10
for you to fetch changes up to d1df1e01af1d7c91e48204b9eb8b9f20cdb90700:
ARM: davinci: da8xx: Fix sleeping function called from invalid context (2017-01-02 16:15:07 +0530)
----------------------------------------------------------------
This pull request contains fixes for the following issues
1) Fix two instances of infinite loop occurring in
clock list for DA850. This fixes kernel hangs in some
instances and so have been marked for stable kernel.
2) Fix for sleeping function called from atomic context
with USB 2.0 clock management code introduced in v4.10
merge window.
----------------------------------------------------------------
Alexandre Bailon (2):
ARM: davinci: Make __clk_{enable,disable} functions public
ARM: davinci: da8xx: Fix sleeping function called from invalid context
Bartosz Golaszewski (2):
ARM: davinci: da850: fix infinite loop in clk_set_rate()
ARM: davinci: da850: don't add emac clock to lookup table twice
arch/arm/mach-davinci/clock.c | 12 ++++++------
arch/arm/mach-davinci/clock.h | 2 ++
arch/arm/mach-davinci/da850.c | 32 ++++++++++++++++++++++++++++++--
arch/arm/mach-davinci/usb-da8xx.c | 34 +++++++++++++++-------------------
4 files changed, 53 insertions(+), 27 deletions(-)
^ permalink raw reply
* [PATCH] rtc: armada38x: add __ro_after_init to armada38x_rtc_ops
From: Russell King - ARM Linux @ 2017-01-04 12:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.20.1701041242080.3073@hadrien>
On Wed, Jan 04, 2017 at 12:43:32PM +0100, Julia Lawall wrote:
> > The question was whether the point to the rtc_class_ops could be made
> > __ro_after_init. And Russell is right, it is pointed to by the ops
> > pointer in a struct rtc_device and that struct is dynamically allocated
> > in rtc_device_register().
>
> OK, I think it's a terminology issue. You mean the structure that
> contains the pointer, and not the pointer itself, which is already const.
That statement is really ambiguous, and really doesn't help the cause -
we have several structures here which contain pointers and it's far from
clear which you're talking about:
- The armada38x_rtc_ops and armada38x_rtc_ops_noirq structures contain
pointers to functions.
- The dynamically allocated struct rtc_device contains an ops pointer,
which will point at one or other of these two structures.
Now, as soon as we make armada38x_rtc_ops and armada38x_rtc_ops_noirq
const, if the pointer is passed through any function call where the
argument is not also marked const, or is assigned to a pointer that is
not marked const (without an explicit cast), the compiler will complain.
Remember that a const pointer (iow, const void *ptr) is just a hint to
the compiler that "ptr" _may_ point at read-only data, and dereferences
of the pointer are not allowed to write - it's just syntactic checking.
Given that this is stuff we should all know, I'm not quite sure what
people are getting in a tiz over... I'm finding it worrying that I'm
even writing this mail, reviewing this stuff! _Really_ worried that
Kees even brought it up in the first place - I suspect that came from
a misunderstanding of my suggestion which is why I later provided the
suggestion in patch form.
What I suggested, and what my patch does is:
1. It places both the armada38x_rtc_ops and armada38x_rtc_ops_noirq
structures into the .rodata section, which will be protected from
writes by hardware when appropriate kernel options are enabled.
2. The driver does _not_ store a local pointer to this memory at a
static address which could be subsequently modified (*).
3. The only pointer to this memory is during driver initialisation
(which may well reside in a CPU register only) before being passed
to the RTC subsystem.
4. The RTC subsystem dynamically allocates a struct rtc_device
structure (in rtc_device_register()) where it eventually stores
this pointer. This pointer is already marked const. This structure
contains read/write data, and can't be marked read-only, just in the
same way as "struct file" can't be.
The whole __ro_after_init thing is completely irrelevant and a total
distraction at this point - there is nothing that you could add a
__ro_after_init annotation to after my patch in regard of these ops
structures.
* - however, a compiler may decide to store the addresses of these
structures as a literal constant near the function, but with RONX
protection for the .text section, this memory is also read-only, and
so can't be modified.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [PATCH 1/2] mm: don't dereference struct page fields of invalid pages
From: Will Deacon @ 2017-01-04 12:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481706707-6211-2-git-send-email-ard.biesheuvel@linaro.org>
On Wed, Dec 14, 2016 at 09:11:46AM +0000, Ard Biesheuvel wrote:
> The VM_BUG_ON() check in move_freepages() checks whether the node
> id of a page matches the node id of its zone. However, it does this
> before having checked whether the struct page pointer refers to a
> valid struct page to begin with. This is guaranteed in most cases,
> but may not be the case if CONFIG_HOLES_IN_ZONE=y.
>
> So reorder the VM_BUG_ON() with the pfn_valid_within() check.
>
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> ---
> mm/page_alloc.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index f64e7bcb43b7..4e298e31fa86 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -1864,14 +1864,14 @@ int move_freepages(struct zone *zone,
> #endif
>
> for (page = start_page; page <= end_page;) {
> - /* Make sure we are not inadvertently changing nodes */
> - VM_BUG_ON_PAGE(page_to_nid(page) != zone_to_nid(zone), page);
> -
> if (!pfn_valid_within(page_to_pfn(page))) {
> page++;
> continue;
> }
>
> + /* Make sure we are not inadvertently changing nodes */
> + VM_BUG_ON_PAGE(page_to_nid(page) != zone_to_nid(zone), page);
> +
> if (!PageBuddy(page)) {
> page++;
> continue;
Acked-by: Will Deacon <will.deacon@arm.com>
I'm guessing akpm can pick this up as a non-urgent fix.
Will
^ permalink raw reply
* arm64: virt_to_page() does not return right page for a kernel image address
From: Pratyush Anand @ 2017-01-04 12:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170104120602.GG8329@leverpostej>
On Wednesday 04 January 2017 05:36 PM, Mark Rutland wrote:
> So it seems we need to fix the crypto test.
>
> Looking at crypto/testmgr.c, I can't spot the kmap_atomic() or the
> page_address()/virt_to_page(). I guess that's hidden behind helpers,
> which might also be used elsewhere?
>
> Could you elaborate on where exactly the problem is in the crypto test?
We have in test_acomp() -> crypto_acomp_decompress() ->
tfm->decompress() -> scomp_acomp_decompress() ->
scomp_acomp_comp_decomp() -> scatterwalk_map_and_copy() ->
scatterwalk_copychunks()
41 if (out != 2) {
42 vaddr = scatterwalk_map(walk);
43 memcpy_dir(buf, vaddr, len_this_page, out);
44 scatterwalk_unmap(vaddr);
45 }
scatterwalk_map() gets vaddr from kmap_atomic().
test_acomp() initializes sg:
sg_init_one(&src, ctemplate[i].input, ilen);
ctemplate is a kernel address (like lzo_comp_tv_template), which was
assigned to walk->sg latter and passed to kmap_atomic().
~Pratyush
^ permalink raw reply
* [PATCH] rtc: armada38x: add __ro_after_init to armada38x_rtc_ops
From: Julia Lawall @ 2017-01-04 12:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170104121425.GP14217@n2100.armlinux.org.uk>
On Wed, 4 Jan 2017, Russell King - ARM Linux wrote:
> On Wed, Jan 04, 2017 at 12:43:32PM +0100, Julia Lawall wrote:
> > > The question was whether the point to the rtc_class_ops could be made
> > > __ro_after_init. And Russell is right, it is pointed to by the ops
> > > pointer in a struct rtc_device and that struct is dynamically allocated
> > > in rtc_device_register().
> >
> > OK, I think it's a terminology issue. You mean the structure that
> > contains the pointer, and not the pointer itself, which is already const.
>
> That statement is really ambiguous, and really doesn't help the cause -
> we have several structures here which contain pointers and it's far from
> clear which you're talking about:
>
> - The armada38x_rtc_ops and armada38x_rtc_ops_noirq structures contain
> pointers to functions.
> - The dynamically allocated struct rtc_device contains an ops pointer,
> which will point at one or other of these two structures.
>
> Now, as soon as we make armada38x_rtc_ops and armada38x_rtc_ops_noirq
> const, if the pointer is passed through any function call where the
> argument is not also marked const, or is assigned to a pointer that is
> not marked const (without an explicit cast), the compiler will complain.
> Remember that a const pointer (iow, const void *ptr) is just a hint to
> the compiler that "ptr" _may_ point at read-only data, and dereferences
> of the pointer are not allowed to write - it's just syntactic checking.
>
> Given that this is stuff we should all know, I'm not quite sure what
> people are getting in a tiz over... I'm finding it worrying that I'm
> even writing this mail, reviewing this stuff! _Really_ worried that
> Kees even brought it up in the first place - I suspect that came from
> a misunderstanding of my suggestion which is why I later provided the
> suggestion in patch form.
>
> What I suggested, and what my patch does is:
>
> 1. It places both the armada38x_rtc_ops and armada38x_rtc_ops_noirq
> structures into the .rodata section, which will be protected from
> writes by hardware when appropriate kernel options are enabled.
>
> 2. The driver does _not_ store a local pointer to this memory at a
> static address which could be subsequently modified (*).
>
> 3. The only pointer to this memory is during driver initialisation
> (which may well reside in a CPU register only) before being passed
> to the RTC subsystem.
>
> 4. The RTC subsystem dynamically allocates a struct rtc_device
> structure (in rtc_device_register()) where it eventually stores
> this pointer. This pointer is already marked const. This structure
> contains read/write data, and can't be marked read-only, just in the
> same way as "struct file" can't be.
>
> The whole __ro_after_init thing is completely irrelevant and a total
> distraction at this point - there is nothing that you could add a
> __ro_after_init annotation to after my patch in regard of these ops
> structures.
>
> * - however, a compiler may decide to store the addresses of these
> structures as a literal constant near the function, but with RONX
> protection for the .text section, this memory is also read-only, and
> so can't be modified.
Thanks for the explanation. I understood the patch, just not Kees's
question.
Basically, the strategy of the patch is that one may consider it
preferable to duplicate the structure for the different alternatives,
rather than use __ro_after_init. Perhaps if the structure were larger,
then __ro_after_init would be a better choice?
thanks,
julia
^ permalink raw reply
* [PATCH v2 04/19] ARM: dts: imx6-sabrelite: add OV5642 and OV5640 camera sensors
From: Vladimir Zapolskiy @ 2017-01-04 12:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483477049-19056-5-git-send-email-steve_longerbeam@mentor.com>
Hi Steve,
On 01/03/2017 10:57 PM, Steve Longerbeam wrote:
> Enables the OV5642 parallel-bus sensor, and the OV5640 MIPI CSI-2 sensor.
> Both hang off the same i2c2 bus, so they require different (and non-
> default) i2c slave addresses.
>
> The OV5642 connects to the parallel-bus mux input port on ipu1_csi0_mux.
>
> The OV5640 connects to the input port on the MIPI CSI-2 receiver on
> mipi_csi. It is set to transmit over MIPI virtual channel 1.
>
> Note there is a pin conflict with GPIO6. This pin functions as a power
> input pin to the OV5642, but ENET uses it as the h/w workaround for
> erratum ERR006687, to wake-up the ARM cores on normal RX and TX packet
> done events (see 6261c4c8). So workaround 6261c4c8 is reverted here to
> support the OV5642, and the "fsl,err006687-workaround-present" boolean
> also must be removed. The result is that the CPUidle driver will no longer
> allow entering the deep idle states on the sabrelite.
For me it sounds like a candidate of its own separate change.
>
> Signed-off-by: Steve Longerbeam <steve_longerbeam@mentor.com>
> ---
[snip]
> &audmux {
> pinctrl-names = "default";
> pinctrl-0 = <&pinctrl_audmux>;
> @@ -271,9 +298,6 @@
> txd1-skew-ps = <0>;
> txd2-skew-ps = <0>;
> txd3-skew-ps = <0>;
> - interrupts-extended = <&gpio1 6 IRQ_TYPE_LEVEL_HIGH>,
> - <&intc 0 119 IRQ_TYPE_LEVEL_HIGH>;
Like you say in the commit message this is a partial revert of 6261c4c8f13e
("ARM: dts: imx6qdl-sabrelite: use GPIO_6 for FEC interrupt.")
> - fsl,err006687-workaround-present;
This is a partial revert of a28eeb43ee57 ("ARM: dts: imx6: tag boards that
have the HW workaround for ERR006687").
The change should be split and reviewed separately in my opinion, also
cc Gary Bisson <gary.bisson@boundarydevices.com> for SabreLite changes.
> status = "okay";
> };
>
> @@ -302,6 +326,52 @@
> pinctrl-names = "default";
> pinctrl-0 = <&pinctrl_i2c2>;
> status = "okay";
> +
> + camera: ov5642 at 42 {
> + compatible = "ovti,ov5642";
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_ov5642>;
> + clocks = <&clks IMX6QDL_CLK_CKO2>;
> + clock-names = "xclk";
> + reg = <0x42>;
> + xclk = <24000000>;
> + reset-gpios = <&gpio1 8 GPIO_ACTIVE_LOW>;
> + pwdn-gpios = <&gpio1 6 GPIO_ACTIVE_HIGH>;
> + gp-gpios = <&gpio1 16 GPIO_ACTIVE_HIGH>;
> +
> + port {
> + ov5642_to_ipu1_csi0_mux: endpoint {
> + remote-endpoint = <&ipu1_csi0_mux_from_parallel_sensor>;
> + bus-width = <8>;
> + hsync-active = <1>;
> + vsync-active = <1>;
> + };
> + };
> + };
> +
> + mipi_camera: ov5640 at 40 {
Please reorder device nodes by address value, also according to ePAPR
node names should be generic, labels can be specific:
ov5640: camera at 40 {
...
};
ov5642: camera at 42 {
...
};
> + compatible = "ovti,ov5640_mipi";
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_ov5640>;
> + clocks = <&mipi_xclk>;
> + clock-names = "xclk";
> + reg = <0x40>;
> + xclk = <22000000>;
> + reset-gpios = <&gpio2 5 GPIO_ACTIVE_LOW>; /* NANDF_D5 */
> + pwdn-gpios = <&gpio6 9 GPIO_ACTIVE_HIGH>; /* NANDF_WP_B */
> +
> + port {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + ov5640_to_mipi_csi: endpoint at 1 {
> + reg = <1>;
> + remote-endpoint = <&mipi_csi_from_mipi_sensor>;
> + data-lanes = <0 1>;
> + clock-lanes = <2>;
> + };
> + };
> + };
> };
>
> &i2c3 {
> @@ -374,7 +444,6 @@
> MX6QDL_PAD_RGMII_RX_CTL__RGMII_RX_CTL 0x1b030
> /* Phy reset */
> MX6QDL_PAD_EIM_D23__GPIO3_IO23 0x000b0
> - MX6QDL_PAD_GPIO_6__ENET_IRQ 0x000b1
Yep.
> >;
> };
>
> @@ -449,6 +518,39 @@
> >;
> };
>
> + pinctrl_ov5642: ov5642grp {
> + fsl,pins = <
> + MX6QDL_PAD_SD1_DAT0__GPIO1_IO16 0x80000000
> + MX6QDL_PAD_GPIO_6__GPIO1_IO06 0x80000000
> + MX6QDL_PAD_GPIO_8__GPIO1_IO08 0x80000000
> + MX6QDL_PAD_GPIO_3__CCM_CLKO2 0x80000000
> + >;
> + };
> +
> + pinctrl_ipu1_csi0: ipu1grp-csi0 {
Please rename node name to ipu1csi0grp.
> + fsl,pins = <
> + MX6QDL_PAD_CSI0_DAT12__IPU1_CSI0_DATA12 0x80000000
> + MX6QDL_PAD_CSI0_DAT13__IPU1_CSI0_DATA13 0x80000000
> + MX6QDL_PAD_CSI0_DAT14__IPU1_CSI0_DATA14 0x80000000
> + MX6QDL_PAD_CSI0_DAT15__IPU1_CSI0_DATA15 0x80000000
> + MX6QDL_PAD_CSI0_DAT16__IPU1_CSI0_DATA16 0x80000000
> + MX6QDL_PAD_CSI0_DAT17__IPU1_CSI0_DATA17 0x80000000
> + MX6QDL_PAD_CSI0_DAT18__IPU1_CSI0_DATA18 0x80000000
> + MX6QDL_PAD_CSI0_DAT19__IPU1_CSI0_DATA19 0x80000000
> + MX6QDL_PAD_CSI0_PIXCLK__IPU1_CSI0_PIXCLK 0x80000000
> + MX6QDL_PAD_CSI0_MCLK__IPU1_CSI0_HSYNC 0x80000000
> + MX6QDL_PAD_CSI0_VSYNC__IPU1_CSI0_VSYNC 0x80000000
> + MX6QDL_PAD_CSI0_DATA_EN__IPU1_CSI0_DATA_EN 0x80000000
> + >;
> + };
> +
> + pinctrl_ov5640: ov5640grp {
> + fsl,pins = <
> + MX6QDL_PAD_NANDF_D5__GPIO2_IO05 0x000b0
> + MX6QDL_PAD_NANDF_WP_B__GPIO6_IO09 0x0b0b0
> + >;
> + };
> +
Indentation issues above, please use tabs instead of spaces.
Also please add new pin control groups preserving the alphanimerical order.
--
With best wishes,
Vladimir
^ permalink raw reply
* [PATCH v2 05/19] ARM: dts: imx6-sabresd: add OV5642 and OV5640 camera sensors
From: Vladimir Zapolskiy @ 2017-01-04 12:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483477049-19056-6-git-send-email-steve_longerbeam@mentor.com>
On 01/03/2017 10:57 PM, Steve Longerbeam wrote:
> Enables the OV5642 parallel-bus sensor, and the OV5640 MIPI CSI-2 sensor.
>
> The OV5642 connects to the parallel-bus mux input port on ipu1_csi0_mux.
>
> The OV5640 connects to the input port on the MIPI CSI-2 receiver on
> mipi_csi. It is set to transmit over MIPI virtual channel 1.
>
> Until the OV5652 sensor module compatible with the SabreSD becomes
> available for testing, the ov5642 node is currently disabled.
>
> Signed-off-by: Steve Longerbeam <steve_longerbeam@mentor.com>
> ---
[snip]
> +
> + camera: ov5642 at 3c {
ov5642: camera at 3c
> + compatible = "ovti,ov5642";
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_ov5642>;
> + clocks = <&clks IMX6QDL_CLK_CKO>;
> + clock-names = "xclk";
> + reg = <0x3c>;
> + xclk = <24000000>;
> + DOVDD-supply = <&vgen4_reg>; /* 1.8v */
> + AVDD-supply = <&vgen5_reg>; /* 2.8v, rev C board is VGEN3
> + rev B board is VGEN5 */
> + DVDD-supply = <&vgen2_reg>; /* 1.5v*/
> + pwdn-gpios = <&gpio1 16 GPIO_ACTIVE_HIGH>; /* SD1_DAT0 */
> + reset-gpios = <&gpio1 17 GPIO_ACTIVE_LOW>; /* SD1_DAT1 */
Comments about SD1_* pad names are redundant.
> + status = "disabled";
Why is it disabled here?
> +
> + port {
> + ov5642_to_ipu1_csi0_mux: endpoint {
> + remote-endpoint = <&ipu1_csi0_mux_from_parallel_sensor>;
> + bus-width = <8>;
> + hsync-active = <1>;
> + vsync-active = <1>;
> + };
> + };
> + };
> };
>
> &i2c2 {
> @@ -322,6 +376,34 @@
> };
> };
> };
> +
> + mipi_camera: ov5640 at 3c {
ov5640: camera at 3c
> + compatible = "ovti,ov5640_mipi";
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_ov5640>;
> + reg = <0x3c>;
> + clocks = <&clks IMX6QDL_CLK_CKO>;
> + clock-names = "xclk";
> + xclk = <24000000>;
> + DOVDD-supply = <&vgen4_reg>; /* 1.8v */
> + AVDD-supply = <&vgen5_reg>; /* 2.8v, rev C board is VGEN3
> + rev B board is VGEN5 */
> + DVDD-supply = <&vgen2_reg>; /* 1.5v*/
> + pwdn-gpios = <&gpio1 19 GPIO_ACTIVE_HIGH>; /* SD1_DAT2 */
> + reset-gpios = <&gpio1 20 GPIO_ACTIVE_LOW>; /* SD1_CLK */
Comments about SD1_* pad names are redundant.
> +
> + port {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + ov5640_to_mipi_csi: endpoint at 1 {
> + reg = <1>;
> + remote-endpoint = <&mipi_csi_from_mipi_sensor>;
> + data-lanes = <0 1>;
> + clock-lanes = <2>;
> + };
> + };
> + };
> };
>
> &i2c3 {
> @@ -426,6 +508,36 @@
> >;
> };
>
> + pinctrl_ov5640: ov5640grp {
> + fsl,pins = <
> + MX6QDL_PAD_SD1_DAT2__GPIO1_IO19 0x80000000
> + MX6QDL_PAD_SD1_CLK__GPIO1_IO20 0x80000000
> + >;
> + };
> +
> + pinctrl_ov5642: ov5642grp {
> + fsl,pins = <
> + MX6QDL_PAD_SD1_DAT0__GPIO1_IO16 0x80000000
> + MX6QDL_PAD_SD1_DAT1__GPIO1_IO17 0x80000000
> + >;
> + };
> +
> + pinctrl_ipu1_csi0: ipu1grp-csi0 {
Please rename the node name to ipu1csi0grp.
Please add new pin control groups preserving the alphanimerical order.
> + fsl,pins = <
> + MX6QDL_PAD_CSI0_DAT12__IPU1_CSI0_DATA12 0x80000000
> + MX6QDL_PAD_CSI0_DAT13__IPU1_CSI0_DATA13 0x80000000
> + MX6QDL_PAD_CSI0_DAT14__IPU1_CSI0_DATA14 0x80000000
> + MX6QDL_PAD_CSI0_DAT15__IPU1_CSI0_DATA15 0x80000000
> + MX6QDL_PAD_CSI0_DAT16__IPU1_CSI0_DATA16 0x80000000
> + MX6QDL_PAD_CSI0_DAT17__IPU1_CSI0_DATA17 0x80000000
> + MX6QDL_PAD_CSI0_DAT18__IPU1_CSI0_DATA18 0x80000000
> + MX6QDL_PAD_CSI0_DAT19__IPU1_CSI0_DATA19 0x80000000
> + MX6QDL_PAD_CSI0_PIXCLK__IPU1_CSI0_PIXCLK 0x80000000
> + MX6QDL_PAD_CSI0_MCLK__IPU1_CSI0_HSYNC 0x80000000
> + MX6QDL_PAD_CSI0_VSYNC__IPU1_CSI0_VSYNC 0x80000000
> + >;
> + };
> +
> pinctrl_pcie: pciegrp {
> fsl,pins = <
> MX6QDL_PAD_GPIO_17__GPIO7_IO12 0x1b0b0
>
--
With best wishes,
Vladimir
^ permalink raw reply
* [PATCH V9 0/3] irqchip: qcom: Add IRQ combiner driver
From: Agustin Vega-Frias @ 2017-01-04 12:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAJZ5v0h_v-iER5Fffdoczj4CAhetGYqOfJOhdO561_kNCnsEFg@mail.gmail.com>
On 2017-01-03 16:56, Rafael J. Wysocki wrote:
> On Tue, Jan 3, 2017 at 4:19 PM, Agustin Vega-Frias
> <agustinv@codeaurora.org> wrote:
>> Hi,
>>
>> Is there any more feedback on this beyond Lorenzo's suggestion to drop
>> the conditional check on the first patch?
>> How can we move forward on this series?
>
> Essentially, I need to convince myself that patches [1-2/3] are fine
> which hasn't happened yet.
>
Thanks Rafael, I'll hold on for your feedback.
> Thanks,
> Rafael
--
Qualcomm Datacenter Technologies, Inc. on behalf of the Qualcomm
Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a
Linux Foundation Collaborative Project.
^ permalink raw reply
* [PATCH v2 09/19] ARM: dts: imx6-sabreauto: add the ADV7180 video decoder
From: Vladimir Zapolskiy @ 2017-01-04 12:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483477049-19056-10-git-send-email-steve_longerbeam@mentor.com>
On 01/03/2017 10:57 PM, Steve Longerbeam wrote:
> Enables the ADV7180 decoder sensor. The ADV7180 connects to the
> parallel-bus mux input on ipu1_csi0_mux.
>
> On the sabreauto, two analog video inputs are routed to the ADV7180,
> composite on Ain1, and composite on Ain3. Those inputs are defined
> via inputs and input-names under the ADV7180 node. The ADV7180 power
> pin is via max7310_b port expander.
>
> Signed-off-by: Steve Longerbeam <steve_longerbeam@mentor.com>
> ---
> arch/arm/boot/dts/imx6qdl-sabreauto.dtsi | 56 ++++++++++++++++++++++++++++++++
> 1 file changed, 56 insertions(+)
>
> diff --git a/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi b/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
> index 83ac2ff..30ee378 100644
> --- a/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
> +++ b/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
> @@ -147,10 +147,42 @@
> gpio-controller;
> #gpio-cells = <2>;
> };
> +
> + camera: adv7180 at 21 {
adv7180: camera at 21
> + compatible = "adi,adv7180";
> + reg = <0x21>;
> + powerdown-gpios = <&max7310_b 2 GPIO_ACTIVE_LOW>;
> + interrupt-parent = <&gpio1>;
> + interrupts = <27 0x8>;
> + inputs = <0x00 0x02>;
> + input-names = "ADV7180 Composite on Ain1",
> + "ADV7180 Composite on Ain3";
> +
> + port {
> + adv7180_to_ipu1_csi0_mux: endpoint {
> + remote-endpoint = <&ipu1_csi0_mux_from_parallel_sensor>;
> + bus-width = <8>;
> + };
> + };
> + };
> };
> };
> };
>
> +&ipu1_csi0_from_ipu1_csi0_mux {
> + bus-width = <8>;
> +};
> +
> +&ipu1_csi0_mux_from_parallel_sensor {
> + remote-endpoint = <&adv7180_to_ipu1_csi0_mux>;
> + bus-width = <8>;
> +};
> +
> +&ipu1_csi0 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_ipu1_csi0>;
> +};
> +
> &clks {
> assigned-clocks = <&clks IMX6QDL_PLL4_BYPASS_SRC>,
> <&clks IMX6QDL_PLL4_BYPASS>,
> @@ -451,6 +483,30 @@
> >;
> };
>
> + pinctrl_ipu1_csi0: ipu1grp-csi0 {
Please rename node name to ipu1csi0grp.
> + fsl,pins = <
> + MX6QDL_PAD_CSI0_DAT4__IPU1_CSI0_DATA04 0x80000000
> + MX6QDL_PAD_CSI0_DAT5__IPU1_CSI0_DATA05 0x80000000
> + MX6QDL_PAD_CSI0_DAT6__IPU1_CSI0_DATA06 0x80000000
> + MX6QDL_PAD_CSI0_DAT7__IPU1_CSI0_DATA07 0x80000000
> + MX6QDL_PAD_CSI0_DAT8__IPU1_CSI0_DATA08 0x80000000
> + MX6QDL_PAD_CSI0_DAT9__IPU1_CSI0_DATA09 0x80000000
> + MX6QDL_PAD_CSI0_DAT10__IPU1_CSI0_DATA10 0x80000000
> + MX6QDL_PAD_CSI0_DAT11__IPU1_CSI0_DATA11 0x80000000
> + MX6QDL_PAD_CSI0_DAT12__IPU1_CSI0_DATA12 0x80000000
> + MX6QDL_PAD_CSI0_DAT13__IPU1_CSI0_DATA13 0x80000000
> + MX6QDL_PAD_CSI0_DAT14__IPU1_CSI0_DATA14 0x80000000
> + MX6QDL_PAD_CSI0_DAT15__IPU1_CSI0_DATA15 0x80000000
> + MX6QDL_PAD_CSI0_DAT16__IPU1_CSI0_DATA16 0x80000000
> + MX6QDL_PAD_CSI0_DAT17__IPU1_CSI0_DATA17 0x80000000
> + MX6QDL_PAD_CSI0_DAT18__IPU1_CSI0_DATA18 0x80000000
> + MX6QDL_PAD_CSI0_DAT19__IPU1_CSI0_DATA19 0x80000000
> + MX6QDL_PAD_CSI0_PIXCLK__IPU1_CSI0_PIXCLK 0x80000000
> + MX6QDL_PAD_CSI0_MCLK__IPU1_CSI0_HSYNC 0x80000000
> + MX6QDL_PAD_CSI0_VSYNC__IPU1_CSI0_VSYNC 0x80000000
> + >;
> + };
> +
> pinctrl_pwm3: pwm1grp {
> fsl,pins = <
> MX6QDL_PAD_SD4_DAT1__PWM3_OUT 0x1b0b1
>
--
With best wishes,
Vladimir
^ permalink raw reply
* [PATCH] rtc: armada38x: add __ro_after_init to armada38x_rtc_ops
From: Russell King - ARM Linux @ 2017-01-04 13:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.20.1701041320140.3073@hadrien>
On Wed, Jan 04, 2017 at 01:23:41PM +0100, Julia Lawall wrote:
> Basically, the strategy of the patch is that one may consider it
> preferable to duplicate the structure for the different alternatives,
> rather than use __ro_after_init. Perhaps if the structure were larger,
> then __ro_after_init would be a better choice?
It depends on not just the size, but how many members need to be
modified, and obviously whether there are likely to be more than one
user of the structure as well.
So I'd say __ro_after_init rarely makes sense for an operations
structure - the only case I can see is:
- a large structure
- only a small number of elements need to be modified
- it is only single-use
which is probably quite rare - this one falls into two out of those
three.
There's another consideration (imho) too - we may wish, at a later
date, to make .text and .rodata both read-only from the start of the
kernel to harden the kernel against possibly init-time exploitation.
(Think about a buggy built-in driver with emulated hardware - much the
same problem that Kees is trying to address in one of his recent patch
sets but with hotplugged hardware while a screen-saver is active.)
Having function pointers in .rodata rather than the ro-after-init
section would provide better protection.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ 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