* [PATCH v3 10/13] pinctrl: samsung: Add infrastructure for pin-bank retention control
From: Marek Szyprowski @ 2017-01-19 13:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484833733-16082-1-git-send-email-m.szyprowski@samsung.com>
Pad retention control after suspend/resume cycle should be done from pin
controller driver instead of PMU (power management unit) driver to avoid
possible ordering and logical dependencies. Till now it worked fine only
because PMU driver registered its sys_ops after pin controller.
This patch adds infrastructure to handle pad retention during pin control
driver resume.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
Acked-by: Tomasz Figa <tomasz.figa@gmail.com>
---
drivers/pinctrl/samsung/pinctrl-samsung.c | 12 +++++++++
drivers/pinctrl/samsung/pinctrl-samsung.h | 42 +++++++++++++++++++++++++++++++
2 files changed, 54 insertions(+)
diff --git a/drivers/pinctrl/samsung/pinctrl-samsung.c b/drivers/pinctrl/samsung/pinctrl-samsung.c
index 59f99ea7e65b..021abd7221f8 100644
--- a/drivers/pinctrl/samsung/pinctrl-samsung.c
+++ b/drivers/pinctrl/samsung/pinctrl-samsung.c
@@ -1060,6 +1060,13 @@ static int samsung_pinctrl_probe(struct platform_device *pdev)
if (res)
drvdata->irq = res->start;
+ if (ctrl->retention_data) {
+ drvdata->retention_ctrl = ctrl->retention_data->init(drvdata,
+ ctrl->retention_data);
+ if (IS_ERR(drvdata->retention_ctrl))
+ return PTR_ERR(drvdata->retention_ctrl);
+ }
+
ret = samsung_gpiolib_register(pdev, drvdata);
if (ret)
return ret;
@@ -1126,6 +1133,8 @@ static void samsung_pinctrl_suspend_dev(
if (drvdata->suspend)
drvdata->suspend(drvdata);
+ if (drvdata->retention_ctrl && drvdata->retention_ctrl->enable)
+ drvdata->retention_ctrl->enable(drvdata);
}
/**
@@ -1173,6 +1182,9 @@ static void samsung_pinctrl_resume_dev(struct samsung_pinctrl_drv_data *drvdata)
if (widths[type])
writel(bank->pm_save[type], reg + offs[type]);
}
+
+ if (drvdata->retention_ctrl && drvdata->retention_ctrl->disable)
+ drvdata->retention_ctrl->disable(drvdata);
}
/**
diff --git a/drivers/pinctrl/samsung/pinctrl-samsung.h b/drivers/pinctrl/samsung/pinctrl-samsung.h
index 6f7ce7539a00..515a61035e54 100644
--- a/drivers/pinctrl/samsung/pinctrl-samsung.h
+++ b/drivers/pinctrl/samsung/pinctrl-samsung.h
@@ -185,10 +185,48 @@ struct samsung_pin_bank {
};
/**
+ * struct samsung_retention_data: runtime pin-bank retention control data.
+ * @regs: array of PMU registers to control pad retention.
+ * @nr_regs: number of registers in @regs array.
+ * @value: value to store to registers to turn off retention.
+ * @refcnt: atomic counter if retention control affects more than one bank.
+ * @priv: retention control code private data
+ * @enable: platform specific callback to enter retention mode.
+ * @disable: platform specific callback to exit retention mode.
+ **/
+struct samsung_retention_ctrl {
+ const u32 *regs;
+ int nr_regs;
+ u32 value;
+ atomic_t *refcnt;
+ void *priv;
+ void (*enable)(struct samsung_pinctrl_drv_data *);
+ void (*disable)(struct samsung_pinctrl_drv_data *);
+};
+
+/**
+ * struct samsung_retention_data: represent a pin-bank retention control data.
+ * @regs: array of PMU registers to control pad retention.
+ * @nr_regs: number of registers in @regs array.
+ * @value: value to store to registers to turn off retention.
+ * @refcnt: atomic counter if retention control affects more than one bank.
+ * @init: platform specific callback to initialize retention control.
+ **/
+struct samsung_retention_data {
+ const u32 *regs;
+ int nr_regs;
+ u32 value;
+ atomic_t *refcnt;
+ struct samsung_retention_ctrl *(*init)(struct samsung_pinctrl_drv_data *,
+ const struct samsung_retention_data *);
+};
+
+/**
* struct samsung_pin_ctrl: represent a pin controller.
* @pin_banks: list of pin banks included in this controller.
* @nr_banks: number of pin banks.
* @nr_ext_resources: number of the extra base address for pin banks.
+ * @retention_data: configuration data for retention control.
* @eint_gpio_init: platform specific callback to setup the external gpio
* interrupts for the controller.
* @eint_wkup_init: platform specific callback to setup the external wakeup
@@ -198,6 +236,7 @@ struct samsung_pin_ctrl {
const struct samsung_pin_bank_data *pin_banks;
u32 nr_banks;
int nr_ext_resources;
+ const struct samsung_retention_data *retention_data;
int (*eint_gpio_init)(struct samsung_pinctrl_drv_data *);
int (*eint_wkup_init)(struct samsung_pinctrl_drv_data *);
@@ -219,6 +258,7 @@ struct samsung_pin_ctrl {
* @nr_function: number of such pin functions.
* @pin_base: starting system wide pin number.
* @nr_pins: number of pins supported by the controller.
+ * @retention_ctrl: retention control runtime data.
*/
struct samsung_pinctrl_drv_data {
struct list_head node;
@@ -238,6 +278,8 @@ struct samsung_pinctrl_drv_data {
unsigned int pin_base;
unsigned int nr_pins;
+ struct samsung_retention_ctrl *retention_ctrl;
+
void (*suspend)(struct samsung_pinctrl_drv_data *);
void (*resume)(struct samsung_pinctrl_drv_data *);
};
--
1.9.1
^ permalink raw reply related
* [PATCH v3 11/13] pinctrl: samsung: Move retention control from mach-exynos to the pinctrl driver
From: Marek Szyprowski @ 2017-01-19 13:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484833733-16082-1-git-send-email-m.szyprowski@samsung.com>
This patch moves pad retention control from PMU driver to Exynos pin
controller driver. This helps to avoid possible ordering and logical
dependencies between machine, PMU and pin control code. Till now it
worked fine only because sys_ops for PMU and pin controller were called
in registration order.
This is also a preparation for adding new features to Exynos pin
controller driver, like runtime power management and suspending
individual pin controllers, which might be a part of some power domain.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
Acked-by: Tomasz Figa <tomasz.figa@gmail.com>
---
arch/arm/mach-exynos/suspend.c | 64 --------------
drivers/pinctrl/samsung/pinctrl-exynos.c | 145 +++++++++++++++++++++++++++++++
2 files changed, 145 insertions(+), 64 deletions(-)
diff --git a/arch/arm/mach-exynos/suspend.c b/arch/arm/mach-exynos/suspend.c
index 94df5d5c024e..710bcb4d8f60 100644
--- a/arch/arm/mach-exynos/suspend.c
+++ b/arch/arm/mach-exynos/suspend.c
@@ -57,7 +57,6 @@ struct exynos_wkup_irq {
struct exynos_pm_data {
const struct exynos_wkup_irq *wkup_irq;
unsigned int wake_disable_mask;
- const unsigned int *release_ret_regs;
void (*pm_prepare)(void);
void (*pm_resume_prepare)(void);
@@ -95,47 +94,6 @@ struct exynos_pm_data {
{ /* sentinel */ },
};
-static const unsigned int exynos_release_ret_regs[] = {
- S5P_PAD_RET_MAUDIO_OPTION,
- S5P_PAD_RET_GPIO_OPTION,
- S5P_PAD_RET_UART_OPTION,
- S5P_PAD_RET_MMCA_OPTION,
- S5P_PAD_RET_MMCB_OPTION,
- S5P_PAD_RET_EBIA_OPTION,
- S5P_PAD_RET_EBIB_OPTION,
- REG_TABLE_END,
-};
-
-static const unsigned int exynos3250_release_ret_regs[] = {
- S5P_PAD_RET_MAUDIO_OPTION,
- S5P_PAD_RET_GPIO_OPTION,
- S5P_PAD_RET_UART_OPTION,
- S5P_PAD_RET_MMCA_OPTION,
- S5P_PAD_RET_MMCB_OPTION,
- S5P_PAD_RET_EBIA_OPTION,
- S5P_PAD_RET_EBIB_OPTION,
- S5P_PAD_RET_MMC2_OPTION,
- S5P_PAD_RET_SPI_OPTION,
- REG_TABLE_END,
-};
-
-static const unsigned int exynos5420_release_ret_regs[] = {
- EXYNOS_PAD_RET_DRAM_OPTION,
- EXYNOS_PAD_RET_MAUDIO_OPTION,
- EXYNOS_PAD_RET_JTAG_OPTION,
- EXYNOS5420_PAD_RET_GPIO_OPTION,
- EXYNOS5420_PAD_RET_UART_OPTION,
- EXYNOS5420_PAD_RET_MMCA_OPTION,
- EXYNOS5420_PAD_RET_MMCB_OPTION,
- EXYNOS5420_PAD_RET_MMCC_OPTION,
- EXYNOS5420_PAD_RET_HSI_OPTION,
- EXYNOS_PAD_RET_EBIA_OPTION,
- EXYNOS_PAD_RET_EBIB_OPTION,
- EXYNOS5420_PAD_RET_SPI_OPTION,
- EXYNOS5420_PAD_RET_DRAM_COREBLK_OPTION,
- REG_TABLE_END,
-};
-
static int exynos_irq_set_wake(struct irq_data *data, unsigned int state)
{
const struct exynos_wkup_irq *wkup_irq;
@@ -441,15 +399,6 @@ static int exynos5420_pm_suspend(void)
return 0;
}
-static void exynos_pm_release_retention(void)
-{
- unsigned int i;
-
- for (i = 0; (pm_data->release_ret_regs[i] != REG_TABLE_END); i++)
- pmu_raw_writel(EXYNOS_WAKEUP_FROM_LOWPWR,
- pm_data->release_ret_regs[i]);
-}
-
static void exynos_pm_resume(void)
{
u32 cpuid = read_cpuid_part();
@@ -457,9 +406,6 @@ static void exynos_pm_resume(void)
if (exynos_pm_central_resume())
goto early_wakeup;
- /* For release retention */
- exynos_pm_release_retention();
-
if (cpuid == ARM_CPU_PART_CORTEX_A9)
scu_enable(S5P_VA_SCU);
@@ -481,9 +427,6 @@ static void exynos3250_pm_resume(void)
if (exynos_pm_central_resume())
goto early_wakeup;
- /* For release retention */
- exynos_pm_release_retention();
-
pmu_raw_writel(S5P_USE_STANDBY_WFI_ALL, S5P_CENTRAL_SEQ_OPTION);
if (call_firmware_op(resume) == -ENOSYS
@@ -521,9 +464,6 @@ static void exynos5420_pm_resume(void)
if (exynos_pm_central_resume())
goto early_wakeup;
- /* For release retention */
- exynos_pm_release_retention();
-
pmu_raw_writel(exynos_pmu_spare3, S5P_PMU_SPARE3);
early_wakeup:
@@ -636,7 +576,6 @@ static void exynos_suspend_finish(void)
static const struct exynos_pm_data exynos3250_pm_data = {
.wkup_irq = exynos3250_wkup_irq,
.wake_disable_mask = ((0xFF << 8) | (0x1F << 1)),
- .release_ret_regs = exynos3250_release_ret_regs,
.pm_suspend = exynos_pm_suspend,
.pm_resume = exynos3250_pm_resume,
.pm_prepare = exynos3250_pm_prepare,
@@ -646,7 +585,6 @@ static void exynos_suspend_finish(void)
static const struct exynos_pm_data exynos4_pm_data = {
.wkup_irq = exynos4_wkup_irq,
.wake_disable_mask = ((0xFF << 8) | (0x1F << 1)),
- .release_ret_regs = exynos_release_ret_regs,
.pm_suspend = exynos_pm_suspend,
.pm_resume = exynos_pm_resume,
.pm_prepare = exynos_pm_prepare,
@@ -656,7 +594,6 @@ static void exynos_suspend_finish(void)
static const struct exynos_pm_data exynos5250_pm_data = {
.wkup_irq = exynos5250_wkup_irq,
.wake_disable_mask = ((0xFF << 8) | (0x1F << 1)),
- .release_ret_regs = exynos_release_ret_regs,
.pm_suspend = exynos_pm_suspend,
.pm_resume = exynos_pm_resume,
.pm_prepare = exynos_pm_prepare,
@@ -666,7 +603,6 @@ static void exynos_suspend_finish(void)
static const struct exynos_pm_data exynos5420_pm_data = {
.wkup_irq = exynos5250_wkup_irq,
.wake_disable_mask = (0x7F << 7) | (0x1F << 1),
- .release_ret_regs = exynos5420_release_ret_regs,
.pm_resume_prepare = exynos5420_prepare_pm_resume,
.pm_resume = exynos5420_pm_resume,
.pm_suspend = exynos5420_pm_suspend,
diff --git a/drivers/pinctrl/samsung/pinctrl-exynos.c b/drivers/pinctrl/samsung/pinctrl-exynos.c
index 70b94ad10cc1..e7a099c4fb78 100644
--- a/drivers/pinctrl/samsung/pinctrl-exynos.c
+++ b/drivers/pinctrl/samsung/pinctrl-exynos.c
@@ -28,7 +28,10 @@
#include <linux/io.h>
#include <linux/slab.h>
#include <linux/spinlock.h>
+#include <linux/regmap.h>
#include <linux/err.h>
+#include <linux/soc/samsung/exynos-pmu.h>
+#include <linux/soc/samsung/exynos-regs-pmu.h>
#include "pinctrl-samsung.h"
#include "pinctrl-exynos.h"
@@ -690,6 +693,54 @@ static void exynos_pinctrl_resume(struct samsung_pinctrl_drv_data *drvdata)
},
};
+/* Pad retention control code for accessing PMU regmap */
+static atomic_t exynos_shared_retention_refcnt;
+
+static void exynos_retention_enable(struct samsung_pinctrl_drv_data *drvdata)
+{
+ if (drvdata->retention_ctrl->refcnt)
+ atomic_inc(drvdata->retention_ctrl->refcnt);
+}
+
+static void exynos_retention_disable(struct samsung_pinctrl_drv_data *drvdata)
+{
+ struct samsung_retention_ctrl *ctrl = drvdata->retention_ctrl;
+ struct regmap *pmu_regs = ctrl->priv;
+ int i;
+
+ if (ctrl->refcnt && !atomic_dec_and_test(ctrl->refcnt))
+ return;
+
+ for (i = 0; i < ctrl->nr_regs; i++)
+ regmap_write(pmu_regs, ctrl->regs[i], ctrl->value);
+}
+
+static struct samsung_retention_ctrl *
+exynos_retention_init(struct samsung_pinctrl_drv_data *drvdata,
+ const struct samsung_retention_data *data)
+{
+ struct samsung_retention_ctrl *ctrl;
+ struct regmap *pmu_regs;
+
+ ctrl = devm_kzalloc(drvdata->dev, sizeof(*ctrl), GFP_KERNEL);
+ if (!ctrl)
+ return ERR_PTR(-ENOMEM);
+
+ pmu_regs = exynos_get_pmu_regmap();
+ if (IS_ERR(pmu_regs))
+ return ERR_CAST(pmu_regs);
+
+ ctrl->priv = pmu_regs;
+ ctrl->regs = data->regs;
+ ctrl->nr_regs = data->nr_regs;
+ ctrl->value = data->value;
+ ctrl->refcnt = data->refcnt;
+ ctrl->enable = exynos_retention_enable;
+ ctrl->disable = exynos_retention_disable;
+
+ return ctrl;
+}
+
/* pin banks of exynos3250 pin-controller 0 */
static const struct samsung_pin_bank_data exynos3250_pin_banks0[] __initconst = {
EXYNOS_PIN_BANK_EINTG(8, 0x000, "gpa0", 0x00),
@@ -722,6 +773,30 @@ static void exynos_pinctrl_resume(struct samsung_pinctrl_drv_data *drvdata)
};
/*
+ * PMU pad retention groups for Exynos3250 doesn't match pin banks, so handle
+ * them all together
+ */
+static const u32 exynos3250_retention_regs[] = {
+ S5P_PAD_RET_MAUDIO_OPTION,
+ S5P_PAD_RET_GPIO_OPTION,
+ S5P_PAD_RET_UART_OPTION,
+ S5P_PAD_RET_MMCA_OPTION,
+ S5P_PAD_RET_MMCB_OPTION,
+ S5P_PAD_RET_EBIA_OPTION,
+ S5P_PAD_RET_EBIB_OPTION,
+ S5P_PAD_RET_MMC2_OPTION,
+ S5P_PAD_RET_SPI_OPTION,
+};
+
+static const struct samsung_retention_data exynos3250_retention_data __initconst = {
+ .regs = exynos3250_retention_regs,
+ .nr_regs = ARRAY_SIZE(exynos3250_retention_regs),
+ .value = EXYNOS_WAKEUP_FROM_LOWPWR,
+ .refcnt = &exynos_shared_retention_refcnt,
+ .init = exynos_retention_init,
+};
+
+/*
* Samsung pinctrl driver data for Exynos3250 SoC. Exynos3250 SoC includes
* two gpio/pin-mux/pinconfig controllers.
*/
@@ -733,6 +808,7 @@ static void exynos_pinctrl_resume(struct samsung_pinctrl_drv_data *drvdata)
.eint_gpio_init = exynos_eint_gpio_init,
.suspend = exynos_pinctrl_suspend,
.resume = exynos_pinctrl_resume,
+ .retention_data = &exynos3250_retention_data,
}, {
/* pin-controller instance 1 data */
.pin_banks = exynos3250_pin_banks1,
@@ -741,6 +817,7 @@ static void exynos_pinctrl_resume(struct samsung_pinctrl_drv_data *drvdata)
.eint_wkup_init = exynos_eint_wkup_init,
.suspend = exynos_pinctrl_suspend,
.resume = exynos_pinctrl_resume,
+ .retention_data = &exynos3250_retention_data,
},
};
@@ -793,6 +870,36 @@ static void exynos_pinctrl_resume(struct samsung_pinctrl_drv_data *drvdata)
EXYNOS_PIN_BANK_EINTN(7, 0x000, "gpz"),
};
+/* PMU pad retention groups registers for Exynos4 (without audio) */
+static const u32 exynos4_retention_regs[] = {
+ S5P_PAD_RET_GPIO_OPTION,
+ S5P_PAD_RET_UART_OPTION,
+ S5P_PAD_RET_MMCA_OPTION,
+ S5P_PAD_RET_MMCB_OPTION,
+ S5P_PAD_RET_EBIA_OPTION,
+ S5P_PAD_RET_EBIB_OPTION,
+};
+
+static const struct samsung_retention_data exynos4_retention_data __initconst = {
+ .regs = exynos4_retention_regs,
+ .nr_regs = ARRAY_SIZE(exynos4_retention_regs),
+ .value = EXYNOS_WAKEUP_FROM_LOWPWR,
+ .refcnt = &exynos_shared_retention_refcnt,
+ .init = exynos_retention_init,
+};
+
+/* PMU retention control for audio pins can be tied to audio pin bank */
+static const u32 exynos4_audio_retention_regs[] = {
+ S5P_PAD_RET_MAUDIO_OPTION,
+};
+
+static const struct samsung_retention_data exynos4_audio_retention_data __initconst = {
+ .regs = exynos4_audio_retention_regs,
+ .nr_regs = ARRAY_SIZE(exynos4_audio_retention_regs),
+ .value = EXYNOS_WAKEUP_FROM_LOWPWR,
+ .init = exynos_retention_init,
+};
+
/*
* Samsung pinctrl driver data for Exynos4210 SoC. Exynos4210 SoC includes
* three gpio/pin-mux/pinconfig controllers.
@@ -805,6 +912,7 @@ static void exynos_pinctrl_resume(struct samsung_pinctrl_drv_data *drvdata)
.eint_gpio_init = exynos_eint_gpio_init,
.suspend = exynos_pinctrl_suspend,
.resume = exynos_pinctrl_resume,
+ .retention_data = &exynos4_retention_data,
}, {
/* pin-controller instance 1 data */
.pin_banks = exynos4210_pin_banks1,
@@ -813,10 +921,12 @@ static void exynos_pinctrl_resume(struct samsung_pinctrl_drv_data *drvdata)
.eint_wkup_init = exynos_eint_wkup_init,
.suspend = exynos_pinctrl_suspend,
.resume = exynos_pinctrl_resume,
+ .retention_data = &exynos4_retention_data,
}, {
/* pin-controller instance 2 data */
.pin_banks = exynos4210_pin_banks2,
.nr_banks = ARRAY_SIZE(exynos4210_pin_banks2),
+ .retention_data = &exynos4_audio_retention_data,
},
};
@@ -890,6 +1000,7 @@ static void exynos_pinctrl_resume(struct samsung_pinctrl_drv_data *drvdata)
.eint_gpio_init = exynos_eint_gpio_init,
.suspend = exynos_pinctrl_suspend,
.resume = exynos_pinctrl_resume,
+ .retention_data = &exynos4_retention_data,
}, {
/* pin-controller instance 1 data */
.pin_banks = exynos4x12_pin_banks1,
@@ -898,6 +1009,7 @@ static void exynos_pinctrl_resume(struct samsung_pinctrl_drv_data *drvdata)
.eint_wkup_init = exynos_eint_wkup_init,
.suspend = exynos_pinctrl_suspend,
.resume = exynos_pinctrl_resume,
+ .retention_data = &exynos4_retention_data,
}, {
/* pin-controller instance 2 data */
.pin_banks = exynos4x12_pin_banks2,
@@ -905,6 +1017,7 @@ static void exynos_pinctrl_resume(struct samsung_pinctrl_drv_data *drvdata)
.eint_gpio_init = exynos_eint_gpio_init,
.suspend = exynos_pinctrl_suspend,
.resume = exynos_pinctrl_resume,
+ .retention_data = &exynos4_audio_retention_data,
}, {
/* pin-controller instance 3 data */
.pin_banks = exynos4x12_pin_banks3,
@@ -984,6 +1097,7 @@ static void exynos_pinctrl_resume(struct samsung_pinctrl_drv_data *drvdata)
.eint_wkup_init = exynos_eint_wkup_init,
.suspend = exynos_pinctrl_suspend,
.resume = exynos_pinctrl_resume,
+ .retention_data = &exynos4_retention_data,
}, {
/* pin-controller instance 1 data */
.pin_banks = exynos5250_pin_banks1,
@@ -991,6 +1105,7 @@ static void exynos_pinctrl_resume(struct samsung_pinctrl_drv_data *drvdata)
.eint_gpio_init = exynos_eint_gpio_init,
.suspend = exynos_pinctrl_suspend,
.resume = exynos_pinctrl_resume,
+ .retention_data = &exynos4_retention_data,
}, {
/* pin-controller instance 2 data */
.pin_banks = exynos5250_pin_banks2,
@@ -1005,6 +1120,7 @@ static void exynos_pinctrl_resume(struct samsung_pinctrl_drv_data *drvdata)
.eint_gpio_init = exynos_eint_gpio_init,
.suspend = exynos_pinctrl_suspend,
.resume = exynos_pinctrl_resume,
+ .retention_data = &exynos4_audio_retention_data,
},
};
@@ -1231,6 +1347,30 @@ static void exynos_pinctrl_resume(struct samsung_pinctrl_drv_data *drvdata)
EXYNOS_PIN_BANK_EINTG(7, 0x000, "gpz", 0x00),
};
+/* PMU pad retention groups registers for Exynos5420 (without audio) */
+static const u32 exynos5420_retention_regs[] = {
+ EXYNOS_PAD_RET_DRAM_OPTION,
+ EXYNOS_PAD_RET_JTAG_OPTION,
+ EXYNOS5420_PAD_RET_GPIO_OPTION,
+ EXYNOS5420_PAD_RET_UART_OPTION,
+ EXYNOS5420_PAD_RET_MMCA_OPTION,
+ EXYNOS5420_PAD_RET_MMCB_OPTION,
+ EXYNOS5420_PAD_RET_MMCC_OPTION,
+ EXYNOS5420_PAD_RET_HSI_OPTION,
+ EXYNOS_PAD_RET_EBIA_OPTION,
+ EXYNOS_PAD_RET_EBIB_OPTION,
+ EXYNOS5420_PAD_RET_SPI_OPTION,
+ EXYNOS5420_PAD_RET_DRAM_COREBLK_OPTION,
+};
+
+static const struct samsung_retention_data exynos5420_retention_data __initconst = {
+ .regs = exynos5420_retention_regs,
+ .nr_regs = ARRAY_SIZE(exynos5420_retention_regs),
+ .value = EXYNOS_WAKEUP_FROM_LOWPWR,
+ .refcnt = &exynos_shared_retention_refcnt,
+ .init = exynos_retention_init,
+};
+
/*
* Samsung pinctrl driver data for Exynos5420 SoC. Exynos5420 SoC includes
* four gpio/pin-mux/pinconfig controllers.
@@ -1242,26 +1382,31 @@ static void exynos_pinctrl_resume(struct samsung_pinctrl_drv_data *drvdata)
.nr_banks = ARRAY_SIZE(exynos5420_pin_banks0),
.eint_gpio_init = exynos_eint_gpio_init,
.eint_wkup_init = exynos_eint_wkup_init,
+ .retention_data = &exynos5420_retention_data,
}, {
/* pin-controller instance 1 data */
.pin_banks = exynos5420_pin_banks1,
.nr_banks = ARRAY_SIZE(exynos5420_pin_banks1),
.eint_gpio_init = exynos_eint_gpio_init,
+ .retention_data = &exynos5420_retention_data,
}, {
/* pin-controller instance 2 data */
.pin_banks = exynos5420_pin_banks2,
.nr_banks = ARRAY_SIZE(exynos5420_pin_banks2),
.eint_gpio_init = exynos_eint_gpio_init,
+ .retention_data = &exynos5420_retention_data,
}, {
/* pin-controller instance 3 data */
.pin_banks = exynos5420_pin_banks3,
.nr_banks = ARRAY_SIZE(exynos5420_pin_banks3),
.eint_gpio_init = exynos_eint_gpio_init,
+ .retention_data = &exynos5420_retention_data,
}, {
/* pin-controller instance 4 data */
.pin_banks = exynos5420_pin_banks4,
.nr_banks = ARRAY_SIZE(exynos5420_pin_banks4),
.eint_gpio_init = exynos_eint_gpio_init,
+ .retention_data = &exynos4_audio_retention_data,
},
};
--
1.9.1
^ permalink raw reply related
* [PATCH v3 12/13] pinctrl: samsung: Move retention control from mach-s5pv210 to the pinctrl driver
From: Marek Szyprowski @ 2017-01-19 13:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484833733-16082-1-git-send-email-m.szyprowski@samsung.com>
This patch moves pad retention control from S5PV210 machine code to
Exynos pin controller driver. This helps to avoid possible ordering
and logical dependencies between machine and pin control code. Till
now it worked fine only because sys_ops for machine code and pin
controller were called in registration order.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Acked-by: Tomasz Figa <tomasz.figa@gmail.com>
For mach-s5pv210:
Acked-by: Krzysztof Kozlowski <krzk@kernel.org>
---
arch/arm/mach-s5pv210/pm.c | 7 ----
arch/arm/mach-s5pv210/regs-clock.h | 4 ---
drivers/pinctrl/samsung/pinctrl-exynos.c | 56 ++++++++++++++++++++++++++++++++
3 files changed, 56 insertions(+), 11 deletions(-)
diff --git a/arch/arm/mach-s5pv210/pm.c b/arch/arm/mach-s5pv210/pm.c
index 2d5f08015e34..07cee14a363b 100644
--- a/arch/arm/mach-s5pv210/pm.c
+++ b/arch/arm/mach-s5pv210/pm.c
@@ -155,13 +155,6 @@ static void s5pv210_suspend_finish(void)
*/
static void s5pv210_pm_resume(void)
{
- u32 tmp;
-
- tmp = __raw_readl(S5P_OTHERS);
- tmp |= (S5P_OTHERS_RET_IO | S5P_OTHERS_RET_CF |\
- S5P_OTHERS_RET_MMC | S5P_OTHERS_RET_UART);
- __raw_writel(tmp , S5P_OTHERS);
-
s3c_pm_do_restore_core(s5pv210_core_save, ARRAY_SIZE(s5pv210_core_save));
}
diff --git a/arch/arm/mach-s5pv210/regs-clock.h b/arch/arm/mach-s5pv210/regs-clock.h
index 4640f0f03c12..fb3eb77412db 100644
--- a/arch/arm/mach-s5pv210/regs-clock.h
+++ b/arch/arm/mach-s5pv210/regs-clock.h
@@ -188,10 +188,6 @@
#define S5P_SLEEP_CFG_USBOSC_EN (1 << 1)
/* OTHERS Resgister */
-#define S5P_OTHERS_RET_IO (1 << 31)
-#define S5P_OTHERS_RET_CF (1 << 30)
-#define S5P_OTHERS_RET_MMC (1 << 29)
-#define S5P_OTHERS_RET_UART (1 << 28)
#define S5P_OTHERS_USB_SIG_MASK (1 << 16)
/* S5P_DAC_CONTROL */
diff --git a/drivers/pinctrl/samsung/pinctrl-exynos.c b/drivers/pinctrl/samsung/pinctrl-exynos.c
index e7a099c4fb78..63e51b56a22a 100644
--- a/drivers/pinctrl/samsung/pinctrl-exynos.c
+++ b/drivers/pinctrl/samsung/pinctrl-exynos.c
@@ -24,6 +24,7 @@
#include <linux/irqdomain.h>
#include <linux/irq.h>
#include <linux/irqchip/chained_irq.h>
+#include <linux/of_address.h>
#include <linux/of_irq.h>
#include <linux/io.h>
#include <linux/slab.h>
@@ -643,6 +644,60 @@ static void exynos_pinctrl_resume(struct samsung_pinctrl_drv_data *drvdata)
exynos_pinctrl_resume_bank(drvdata, bank);
}
+/* Retention control for S5PV210 are located at the end of clock controller */
+#define S5P_OTHERS 0xE000
+
+#define S5P_OTHERS_RET_IO (1 << 31)
+#define S5P_OTHERS_RET_CF (1 << 30)
+#define S5P_OTHERS_RET_MMC (1 << 29)
+#define S5P_OTHERS_RET_UART (1 << 28)
+
+static void s5pv210_retention_disable(struct samsung_pinctrl_drv_data *drvdata)
+{
+ void *clk_base = drvdata->retention_ctrl->priv;
+ u32 tmp;
+
+ tmp = __raw_readl(clk_base + S5P_OTHERS);
+ tmp |= (S5P_OTHERS_RET_IO | S5P_OTHERS_RET_CF | S5P_OTHERS_RET_MMC |
+ S5P_OTHERS_RET_UART);
+ __raw_writel(tmp, clk_base + S5P_OTHERS);
+}
+
+static struct samsung_retention_ctrl *
+s5pv210_retention_init(struct samsung_pinctrl_drv_data *drvdata,
+ const struct samsung_retention_data *data)
+{
+ struct samsung_retention_ctrl *ctrl;
+ struct device_node *np;
+ void *clk_base;
+
+ ctrl = devm_kzalloc(drvdata->dev, sizeof(*ctrl), GFP_KERNEL);
+ if (!ctrl)
+ return ERR_PTR(-ENOMEM);
+
+ np = of_find_compatible_node(NULL, NULL, "samsung,s5pv210-clock");
+ if (!np) {
+ pr_err("%s: failed to find clock controller DT node\n",
+ __func__);
+ return ERR_PTR(-ENODEV);
+ }
+
+ clk_base = of_iomap(np, 0);
+ if (!clk_base) {
+ pr_err("%s: failed to map clock registers\n", __func__);
+ return ERR_PTR(-EINVAL);
+ }
+
+ ctrl->priv = clk_base;
+ ctrl->disable = s5pv210_retention_disable;
+
+ return ctrl;
+}
+
+static const struct samsung_retention_data s5pv210_retention_data __initconst = {
+ .init = s5pv210_retention_init,
+};
+
/* pin banks of s5pv210 pin-controller */
static const struct samsung_pin_bank_data s5pv210_pin_bank[] __initconst = {
EXYNOS_PIN_BANK_EINTG(8, 0x000, "gpa0", 0x00),
@@ -690,6 +745,7 @@ static void exynos_pinctrl_resume(struct samsung_pinctrl_drv_data *drvdata)
.eint_wkup_init = exynos_eint_wkup_init,
.suspend = exynos_pinctrl_suspend,
.resume = exynos_pinctrl_resume,
+ .retention_data = &s5pv210_retention_data,
},
};
--
1.9.1
^ permalink raw reply related
* [PATCH v3 13/13] pinctrl: samsung: Replace syscore ops with standard platform device pm_ops
From: Marek Szyprowski @ 2017-01-19 13:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484833733-16082-1-git-send-email-m.szyprowski@samsung.com>
Once the dependency on PMU driver (for pad retention control) has been
removed, there is no reason to use syscore_ops based suspend/resume.
This patch replaces it with standard platform device pm_ops based solution.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
Acked-by: Tomasz Figa <tomasz.figa@gmail.com>
---
drivers/pinctrl/samsung/pinctrl-samsung.c | 72 ++++++-------------------------
1 file changed, 14 insertions(+), 58 deletions(-)
diff --git a/drivers/pinctrl/samsung/pinctrl-samsung.c b/drivers/pinctrl/samsung/pinctrl-samsung.c
index 021abd7221f8..d79eadad6c5f 100644
--- a/drivers/pinctrl/samsung/pinctrl-samsung.c
+++ b/drivers/pinctrl/samsung/pinctrl-samsung.c
@@ -29,7 +29,6 @@
#include <linux/irqdomain.h>
#include <linux/of_device.h>
#include <linux/spinlock.h>
-#include <linux/syscore_ops.h>
#include "../core.h"
#include "pinctrl-samsung.h"
@@ -49,9 +48,6 @@
{ "samsung,pin-val", PINCFG_TYPE_DAT },
};
-/* Global list of devices (struct samsung_pinctrl_drv_data) */
-static LIST_HEAD(drvdata_list);
-
static unsigned int pin_base;
static int samsung_get_group_count(struct pinctrl_dev *pctldev)
@@ -1084,22 +1080,18 @@ static int samsung_pinctrl_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, drvdata);
- /* Add to the global list */
- list_add_tail(&drvdata->node, &drvdata_list);
-
return 0;
}
#ifdef CONFIG_PM
-
/**
- * samsung_pinctrl_suspend_dev - save pinctrl state for suspend for a device
+ * samsung_pinctrl_suspend - save pinctrl state for suspend
*
* Save data for all banks handled by this device.
*/
-static void samsung_pinctrl_suspend_dev(
- struct samsung_pinctrl_drv_data *drvdata)
+static int samsung_pinctrl_suspend(struct device *dev)
{
+ struct samsung_pinctrl_drv_data *drvdata = dev_get_drvdata(dev);
int i;
for (i = 0; i < drvdata->nr_banks; i++) {
@@ -1135,18 +1127,21 @@ static void samsung_pinctrl_suspend_dev(
drvdata->suspend(drvdata);
if (drvdata->retention_ctrl && drvdata->retention_ctrl->enable)
drvdata->retention_ctrl->enable(drvdata);
+
+ return 0;
}
/**
- * samsung_pinctrl_resume_dev - restore pinctrl state from suspend for a device
+ * samsung_pinctrl_resume - restore pinctrl state from suspend
*
* Restore one of the banks that was saved during suspend.
*
* We don't bother doing anything complicated to avoid glitching lines since
* we're called before pad retention is turned off.
*/
-static void samsung_pinctrl_resume_dev(struct samsung_pinctrl_drv_data *drvdata)
+static int samsung_pinctrl_resume(struct device *dev)
{
+ struct samsung_pinctrl_drv_data *drvdata = dev_get_drvdata(dev);
int i;
if (drvdata->resume)
@@ -1185,48 +1180,11 @@ static void samsung_pinctrl_resume_dev(struct samsung_pinctrl_drv_data *drvdata)
if (drvdata->retention_ctrl && drvdata->retention_ctrl->disable)
drvdata->retention_ctrl->disable(drvdata);
-}
-
-/**
- * samsung_pinctrl_suspend - save pinctrl state for suspend
- *
- * Save data for all banks across all devices.
- */
-static int samsung_pinctrl_suspend(void)
-{
- struct samsung_pinctrl_drv_data *drvdata;
-
- list_for_each_entry(drvdata, &drvdata_list, node) {
- samsung_pinctrl_suspend_dev(drvdata);
- }
return 0;
}
-
-/**
- * samsung_pinctrl_resume - restore pinctrl state for suspend
- *
- * Restore data for all banks across all devices.
- */
-static void samsung_pinctrl_resume(void)
-{
- struct samsung_pinctrl_drv_data *drvdata;
-
- list_for_each_entry_reverse(drvdata, &drvdata_list, node) {
- samsung_pinctrl_resume_dev(drvdata);
- }
-}
-
-#else
-#define samsung_pinctrl_suspend NULL
-#define samsung_pinctrl_resume NULL
#endif
-static struct syscore_ops samsung_pinctrl_syscore_ops = {
- .suspend = samsung_pinctrl_suspend,
- .resume = samsung_pinctrl_resume,
-};
-
static const struct of_device_id samsung_pinctrl_dt_match[] = {
#ifdef CONFIG_PINCTRL_EXYNOS
{ .compatible = "samsung,exynos3250-pinctrl",
@@ -1268,25 +1226,23 @@ static void samsung_pinctrl_resume(void)
};
MODULE_DEVICE_TABLE(of, samsung_pinctrl_dt_match);
+static const struct dev_pm_ops samsung_pinctrl_pm_ops = {
+ SET_LATE_SYSTEM_SLEEP_PM_OPS(samsung_pinctrl_suspend,
+ samsung_pinctrl_resume)
+};
+
static struct platform_driver samsung_pinctrl_driver = {
.probe = samsung_pinctrl_probe,
.driver = {
.name = "samsung-pinctrl",
.of_match_table = samsung_pinctrl_dt_match,
.suppress_bind_attrs = true,
+ .pm = &samsung_pinctrl_pm_ops,
},
};
static int __init samsung_pinctrl_drv_register(void)
{
- /*
- * Register syscore ops for save/restore of registers across suspend.
- * It's important to ensure that this driver is running at an earlier
- * initcall level than any arch-specific init calls that install syscore
- * ops that turn off pad retention (like exynos_pm_resume).
- */
- register_syscore_ops(&samsung_pinctrl_syscore_ops);
-
return platform_driver_register(&samsung_pinctrl_driver);
}
postcore_initcall(samsung_pinctrl_drv_register);
--
1.9.1
^ permalink raw reply related
* [PATCH v9 0/4] arm64: arch_timer: Add workaround for hisilicon-161010101 erratum
From: Marc Zyngier @ 2017-01-19 13:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484832916-7248-1-git-send-email-dingtianhong@huawei.com>
On 19/01/17 13:35, Ding Tianhong wrote:
> Erratum Hisilicon-161010101 says that the ARM generic timer counter "has the
> potential to contain an erroneous value when the timer value changes".
> Accesses to TVAL (both read and write) are also affected due to the implicit counter
> read. Accesses to CVAL are not affected.
Please. 3 series in 2 hours is not fun, and is not helping your case
either. Give us the time to properly review your patches, and wait until
we ask you to respin if we think that this is required.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [arm:phy-cleanup 10/10] arch/mips/cavium-octeon/octeon-platform.c:1064:15: error: expected declaration specifiers or '...' before string constant
From: Russell King - ARM Linux @ 2017-01-19 13:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201701192138.NZ3q3lNY%fengguang.wu@intel.com>
Hi David,
Is there a reason why there's these MODULE_* macros at the bottom of
this file? From what I can see:
(a) this file can't be built as a module as the Makefile doesn't allow it:
obj-y := cpu.o setup.o octeon-platform.o octeon-irq.o csrc-octeon.o
(b) this file will not be functional as a module anyway, because of the
multiple *_initcall() statements, each of which are translated to
a module_init() call, each of which define an alias to
int init_module(void) - and that will cause a build error.
Can we just kill these, rather than adding a linux/module.h include to
this file?
Thanks.
On Thu, Jan 19, 2017 at 09:08:42PM +0800, kbuild test robot wrote:
> tree: git://git.armlinux.org.uk/~rmk/linux-arm.git phy-cleanup
> head: ef8cb7d5f838770f22cae0e20fee8d1157fc88fd
> commit: ef8cb7d5f838770f22cae0e20fee8d1157fc88fd [10/10] net: dsa: remove unnecessary phy*.h includes
> config: mips-cavium_octeon_defconfig (attached as .config)
> compiler: mips64-linux-gnuabi64-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
> git checkout ef8cb7d5f838770f22cae0e20fee8d1157fc88fd
> # save the attached .config to linux build tree
> make.cross ARCH=mips
>
> All errors (new ones prefixed by >>):
>
> >> arch/mips/cavium-octeon/octeon-platform.c:1064:15: error: expected declaration specifiers or '...' before string constant
> MODULE_AUTHOR("David Daney <ddaney@caviumnetworks.com>");
> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> arch/mips/cavium-octeon/octeon-platform.c:1065:16: error: expected declaration specifiers or '...' before string constant
> MODULE_LICENSE("GPL");
> ^~~~~
> arch/mips/cavium-octeon/octeon-platform.c:1066:20: error: expected declaration specifiers or '...' before string constant
> MODULE_DESCRIPTION("Platform driver for Octeon SOC");
> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> vim +1064 arch/mips/cavium-octeon/octeon-platform.c
>
> d617f9e9 David Daney 2013-12-03 1048 break;
> d617f9e9 David Daney 2013-12-03 1049 default:
> d617f9e9 David Daney 2013-12-03 1050 break;
> d617f9e9 David Daney 2013-12-03 1051 }
> d617f9e9 David Daney 2013-12-03 1052 }
> d617f9e9 David Daney 2013-12-03 1053 }
> d617f9e9 David Daney 2013-12-03 1054
> 7ed18152 David Daney 2012-07-05 1055 return 0;
> 7ed18152 David Daney 2012-07-05 1056 }
> 7ed18152 David Daney 2012-07-05 1057
> 7ed18152 David Daney 2012-07-05 1058 static int __init octeon_publish_devices(void)
> 7ed18152 David Daney 2012-07-05 1059 {
> 7ed18152 David Daney 2012-07-05 1060 return of_platform_bus_probe(NULL, octeon_ids, NULL);
> 7ed18152 David Daney 2012-07-05 1061 }
> 8074d782 Aaro Koskinen 2016-08-23 1062 arch_initcall(octeon_publish_devices);
> 7ed18152 David Daney 2012-07-05 1063
> 512254ba David Daney 2009-09-16 @1064 MODULE_AUTHOR("David Daney <ddaney@caviumnetworks.com>");
> 512254ba David Daney 2009-09-16 1065 MODULE_LICENSE("GPL");
> 512254ba David Daney 2009-09-16 1066 MODULE_DESCRIPTION("Platform driver for Octeon SOC");
>
> :::::: The code at line 1064 was first introduced by commit
> :::::: 512254ba8383c5dd7eca6819d0da1ce2fe9ede47 MIPS: Octeon: Move some platform device registration to its own file.
>
> :::::: TO: David Daney <ddaney@caviumnetworks.com>
> :::::: CC: Ralf Baechle <ralf@linux-mips.org>
>
> ---
> 0-DAY kernel test infrastructure Open Source Technology Center
> https://lists.01.org/pipermail/kbuild-all Intel Corporation
--
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] coresight: STM: Balance enable/disable
From: Suzuki K Poulose @ 2017-01-19 13:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170119114037.GR28024@kroah.com>
On 19/01/17 11:40, Greg KH wrote:
>> Fixes: commit 237483aa5cf43 ("coresight: stm: adding driver for CoreSight STM component")
>> Cc: Pratik Patel <pratikp@codeaurora.org>
>> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>> Cc: stable at vger.kernel.org # 4.7+
>> Acked-by: Mathieu Poirier <mathieu.poirier@linaro.org>
>> Reviewed-by: Chunyan Zhang <zhang.chunyan@linaro.org>
>> Reported-by: Robert Walker <robert.walker@arm.com>
>> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
>> ---
>>
>> Greg,
>>
>> Without this patch, the coresight STM IP can only be used for one tracing
>> session per boot, seriously limiting its usability.
>
> When you resend a patch, please tell me what is different from the
> previous version you sent. I figured it out here, but please do this
> next time.
Hi Greg,
Sure, will keep that in mind. For this patch nothing has changed, except for
the addition of Review/Ack. It was resent (with to: you) just to make sure it
gets through the rc series. Thanks for queuing it.
Suzuki
^ permalink raw reply
* [PATCH 2/4] ARM: nommu: dynamic exception base address setting
From: Vladimir Murzin @ 2017-01-19 13:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170118203807.6467-1-afzal.mohd.ma@gmail.com>
Hi,
On 18/01/17 20:38, afzal mohammed wrote:
> No-MMU dynamic exception base address configuration on CP15
> processors. In the case of low vectors, decision based on whether
> security extensions are enabled & whether remap vectors to RAM
> CONFIG option is selected.
>
> For no-MMU without CP15, current default value of 0x0 is retained.
>
> Signed-off-by: afzal mohammed <afzal.mohd.ma@gmail.com>
> ---
> arch/arm/mm/nommu.c | 64 +++++++++++++++++++++++++++++++++++++++++++++++++++--
> 1 file changed, 62 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/mm/nommu.c b/arch/arm/mm/nommu.c
> index 2740967727e2..db8e784f20f3 100644
> --- a/arch/arm/mm/nommu.c
> +++ b/arch/arm/mm/nommu.c
> @@ -11,6 +11,7 @@
> #include <linux/kernel.h>
>
> #include <asm/cacheflush.h>
> +#include <asm/cp15.h>
> #include <asm/sections.h>
> #include <asm/page.h>
> #include <asm/setup.h>
> @@ -22,6 +23,8 @@
>
> #include "mm.h"
>
> +unsigned long vectors_base;
> +
> #ifdef CONFIG_ARM_MPU
> struct mpu_rgn_info mpu_rgn_info;
>
> @@ -278,15 +281,72 @@ static void sanity_check_meminfo_mpu(void) {}
> static void __init mpu_setup(void) {}
> #endif /* CONFIG_ARM_MPU */
>
> +#ifdef CONFIG_CPU_CP15
> +#ifdef CONFIG_CPU_HIGH_VECTOR
> +static unsigned long __init setup_vectors_base(void)
> +{
> + unsigned long reg = get_cr();
> +
> + set_cr(reg | CR_V);
> + return 0xffff0000;
> +}
> +#else /* CONFIG_CPU_HIGH_VECTOR */
> +/*
> + * ID_PRF1 bits (CP#15 ID_PFR1)
> + */
> +#define ID_PFR1_SE (0x3 << 4) /* Security extension enable bits */
This bitfiled is 4 bits wide.
> +
> +/* Read processor feature register ID_PFR1 */
> +static unsigned long get_id_pfr1(void)
> +{
> + unsigned long val;
> +
> + asm("mrc p15, 0, %0, c0, c1, 1" : "=r" (val) : : "cc");
> + return val;
> +}
> +
> +/* Write exception base address to VBAR */
> +static void set_vbar(unsigned long val)
> +{
> + asm("mcr p15, 0, %0, c12, c0, 0" : : "r" (val) : "cc");
> +}
> +
> +static bool __init security_extensions_enabled(void)
> +{
> + return !!(get_id_pfr1() & ID_PFR1_SE);
> +}
> +
> +static unsigned long __init setup_vectors_base(void)
> +{
> + unsigned long base = 0, reg = get_cr();
> +
> + set_cr(reg & ~CR_V);
> + if (security_extensions_enabled()) {
You can use
cpuid_feature_extract(CPUID_EXT_PFR1, 4)
and add a comment explaining what we are looking for and why.
> + if (IS_ENABLED(CONFIG_REMAP_VECTORS_TO_RAM))
> + base = CONFIG_DRAM_BASE;
> + set_vbar(base);
> + } else if (IS_ENABLED(CONFIG_REMAP_VECTORS_TO_RAM)) {
> + if (CONFIG_DRAM_BASE != 0)
> + pr_err("Security extensions not enabled, vectors cannot be remapped to RAM, vectors base will be 0x00000000\n");
> + }
> +
> + return base;
> +}
> +#endif /* CONFIG_CPU_HIGH_VECTOR */
> +#endif /* CONFIG_CPU_CP15 */
> +
> void __init arm_mm_memblock_reserve(void)
> {
> #ifndef CONFIG_CPU_V7M
> +#ifdef CONFIG_CPU_CP15
> + vectors_base = setup_vectors_base();
> +#endif
alternatively it can be
unsigned long vector_base = IS_ENABLED(CONFIG_CPU_CP15) ? setup_vbar() : 0;
Thanks
Vladimir
> /*
> * Register the exception vector page.
> * some architectures which the DRAM is the exception vector to trap,
> * alloc_page breaks with error, although it is not NULL, but "0."
> */
> - memblock_reserve(CONFIG_VECTORS_BASE, 2 * PAGE_SIZE);
> + memblock_reserve(vectors_base, 2 * PAGE_SIZE);
> #else /* ifndef CONFIG_CPU_V7M */
> /*
> * There is no dedicated vector page on V7-M. So nothing needs to be
> @@ -310,7 +370,7 @@ void __init sanity_check_meminfo(void)
> */
> void __init paging_init(const struct machine_desc *mdesc)
> {
> - early_trap_init((void *)CONFIG_VECTORS_BASE);
> + early_trap_init((void *)vectors_base);
> mpu_setup();
> bootmem_init();
> }
>
^ permalink raw reply
* [PATCH v2] ARM: dts: imx: Pass 'chosen' and 'memory' nodes
From: Fabio Estevam @ 2017-01-19 14:02 UTC (permalink / raw)
To: linux-arm-kernel
Commit 7f107887d199 ("ARM: dts: imx: Remove skeleton.dtsi") causes boot
issues when the bootloader does not create a 'chosen' node if such node
is not present in the dtb.
The reason for the boot failure is well explained by Javier Martinez
Canillas: "the decompressor relies on a pre-existing chosen node to be
available to insert the command line and merge other ATAGS info."
, so pass an empty 'chosen' node to fix the boot problem.
This issue has been seen in the kernelci reports with Barebox as
bootloader.
Also pass the 'memory' node in order to fix boot issues on the SolidRun
iMX6 platforms.
Fixes: 7f107887d199 ("ARM: dts: imx: Remove skeleton.dtsi")
Reported-by: kernelci.org bot <bot@kernelci.org>
Reported-by: Russell King <rmk+kernel@armlinux.org.uk>
Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
---
Changes since v1:
- Also pass the memory node.
arch/arm/boot/dts/imx1.dtsi | 2 ++
arch/arm/boot/dts/imx23.dtsi | 2 ++
arch/arm/boot/dts/imx25.dtsi | 2 ++
arch/arm/boot/dts/imx27.dtsi | 2 ++
arch/arm/boot/dts/imx28.dtsi | 2 ++
arch/arm/boot/dts/imx31.dtsi | 2 ++
arch/arm/boot/dts/imx35.dtsi | 2 ++
arch/arm/boot/dts/imx50.dtsi | 2 ++
arch/arm/boot/dts/imx51.dtsi | 2 ++
arch/arm/boot/dts/imx53.dtsi | 2 ++
arch/arm/boot/dts/imx6qdl.dtsi | 2 ++
arch/arm/boot/dts/imx6sl.dtsi | 2 ++
arch/arm/boot/dts/imx6sx.dtsi | 2 ++
arch/arm/boot/dts/imx6ul.dtsi | 2 ++
arch/arm/boot/dts/imx7s.dtsi | 2 ++
15 files changed, 30 insertions(+)
diff --git a/arch/arm/boot/dts/imx1.dtsi b/arch/arm/boot/dts/imx1.dtsi
index dd3de38..7ef0d36 100644
--- a/arch/arm/boot/dts/imx1.dtsi
+++ b/arch/arm/boot/dts/imx1.dtsi
@@ -18,6 +18,8 @@
/ {
#address-cells = <1>;
#size-cells = <1>;
+ chosen {};
+ memory { device_type = "memory"; reg = <0 0>; };
aliases {
gpio0 = &gpio1;
diff --git a/arch/arm/boot/dts/imx23.dtsi b/arch/arm/boot/dts/imx23.dtsi
index 96eae64..7bb662c 100644
--- a/arch/arm/boot/dts/imx23.dtsi
+++ b/arch/arm/boot/dts/imx23.dtsi
@@ -16,6 +16,8 @@
#size-cells = <1>;
interrupt-parent = <&icoll>;
+ chosen {};
+ memory { device_type = "memory"; reg = <0 0>; };
aliases {
gpio0 = &gpio0;
diff --git a/arch/arm/boot/dts/imx25.dtsi b/arch/arm/boot/dts/imx25.dtsi
index 213d86e..f328ecc 100644
--- a/arch/arm/boot/dts/imx25.dtsi
+++ b/arch/arm/boot/dts/imx25.dtsi
@@ -14,6 +14,8 @@
/ {
#address-cells = <1>;
#size-cells = <1>;
+ chosen {};
+ memory { device_type = "memory"; reg = <0 0>; };
aliases {
ethernet0 = &fec;
diff --git a/arch/arm/boot/dts/imx27.dtsi b/arch/arm/boot/dts/imx27.dtsi
index 6a7cb9e..3271ec49 100644
--- a/arch/arm/boot/dts/imx27.dtsi
+++ b/arch/arm/boot/dts/imx27.dtsi
@@ -19,6 +19,8 @@
/ {
#address-cells = <1>;
#size-cells = <1>;
+ chosen {};
+ memory { device_type = "memory"; reg = <0 0>; };
aliases {
ethernet0 = &fec;
diff --git a/arch/arm/boot/dts/imx28.dtsi b/arch/arm/boot/dts/imx28.dtsi
index 905bdb5..5f47558 100644
--- a/arch/arm/boot/dts/imx28.dtsi
+++ b/arch/arm/boot/dts/imx28.dtsi
@@ -17,6 +17,8 @@
#size-cells = <1>;
interrupt-parent = <&icoll>;
+ chosen {};
+ memory { device_type = "memory"; reg = <0 0>; };
aliases {
ethernet0 = &mac0;
diff --git a/arch/arm/boot/dts/imx31.dtsi b/arch/arm/boot/dts/imx31.dtsi
index c0a5d5f..afd4106 100644
--- a/arch/arm/boot/dts/imx31.dtsi
+++ b/arch/arm/boot/dts/imx31.dtsi
@@ -12,6 +12,8 @@
/ {
#address-cells = <1>;
#size-cells = <1>;
+ chosen {};
+ memory { device_type = "memory"; reg = <0 0>; };
aliases {
serial0 = &uart1;
diff --git a/arch/arm/boot/dts/imx35.dtsi b/arch/arm/boot/dts/imx35.dtsi
index 6f7b943..e08e574 100644
--- a/arch/arm/boot/dts/imx35.dtsi
+++ b/arch/arm/boot/dts/imx35.dtsi
@@ -13,6 +13,8 @@
/ {
#address-cells = <1>;
#size-cells = <1>;
+ chosen {};
+ memory { device_type = "memory"; reg = <0 0>; };
aliases {
ethernet0 = &fec;
diff --git a/arch/arm/boot/dts/imx50.dtsi b/arch/arm/boot/dts/imx50.dtsi
index fe0221e..46329ff 100644
--- a/arch/arm/boot/dts/imx50.dtsi
+++ b/arch/arm/boot/dts/imx50.dtsi
@@ -17,6 +17,8 @@
/ {
#address-cells = <1>;
#size-cells = <1>;
+ chosen {};
+ memory { device_type = "memory"; reg = <0 0>; };
aliases {
ethernet0 = &fec;
diff --git a/arch/arm/boot/dts/imx51.dtsi b/arch/arm/boot/dts/imx51.dtsi
index 33526ca..c6ffc7b 100644
--- a/arch/arm/boot/dts/imx51.dtsi
+++ b/arch/arm/boot/dts/imx51.dtsi
@@ -19,6 +19,8 @@
/ {
#address-cells = <1>;
#size-cells = <1>;
+ chosen {};
+ memory { device_type = "memory"; reg = <0 0>; };
aliases {
ethernet0 = &fec;
diff --git a/arch/arm/boot/dts/imx53.dtsi b/arch/arm/boot/dts/imx53.dtsi
index ca51dc0..2d56f26 100644
--- a/arch/arm/boot/dts/imx53.dtsi
+++ b/arch/arm/boot/dts/imx53.dtsi
@@ -19,6 +19,8 @@
/ {
#address-cells = <1>;
#size-cells = <1>;
+ chosen {};
+ memory { device_type = "memory"; reg = <0 0>; };
aliases {
ethernet0 = &fec;
diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
index 89b834f..c88a373 100644
--- a/arch/arm/boot/dts/imx6qdl.dtsi
+++ b/arch/arm/boot/dts/imx6qdl.dtsi
@@ -16,6 +16,8 @@
/ {
#address-cells = <1>;
#size-cells = <1>;
+ chosen {};
+ memory { device_type = "memory"; reg = <0 0>; };
aliases {
ethernet0 = &fec;
diff --git a/arch/arm/boot/dts/imx6sl.dtsi b/arch/arm/boot/dts/imx6sl.dtsi
index 19cbd87..89e8315 100644
--- a/arch/arm/boot/dts/imx6sl.dtsi
+++ b/arch/arm/boot/dts/imx6sl.dtsi
@@ -14,6 +14,8 @@
/ {
#address-cells = <1>;
#size-cells = <1>;
+ chosen {};
+ memory { device_type = "memory"; reg = <0 0>; };
aliases {
ethernet0 = &fec;
diff --git a/arch/arm/boot/dts/imx6sx.dtsi b/arch/arm/boot/dts/imx6sx.dtsi
index 10f3330..f52d017 100644
--- a/arch/arm/boot/dts/imx6sx.dtsi
+++ b/arch/arm/boot/dts/imx6sx.dtsi
@@ -15,6 +15,8 @@
/ {
#address-cells = <1>;
#size-cells = <1>;
+ chosen {};
+ memory { device_type = "memory"; reg = <0 0>; };
aliases {
can0 = &flexcan1;
diff --git a/arch/arm/boot/dts/imx6ul.dtsi b/arch/arm/boot/dts/imx6ul.dtsi
index 0f69a3f..1d93601 100644
--- a/arch/arm/boot/dts/imx6ul.dtsi
+++ b/arch/arm/boot/dts/imx6ul.dtsi
@@ -15,6 +15,8 @@
/ {
#address-cells = <1>;
#size-cells = <1>;
+ chosen {};
+ memory { device_type = "memory"; reg = <0 0>; };
aliases {
ethernet0 = &fec1;
diff --git a/arch/arm/boot/dts/imx7s.dtsi b/arch/arm/boot/dts/imx7s.dtsi
index 8db1eb9..1757789 100644
--- a/arch/arm/boot/dts/imx7s.dtsi
+++ b/arch/arm/boot/dts/imx7s.dtsi
@@ -50,6 +50,8 @@
/ {
#address-cells = <1>;
#size-cells = <1>;
+ chosen {};
+ memory { device_type = "memory"; reg = <0 0>; };
aliases {
gpio0 = &gpio1;
--
2.7.4
^ permalink raw reply related
* [PATCH] ARM: dts: fix SolidRun iMX6 platforms
From: Fabio Estevam @ 2017-01-19 14:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <E1cUC4p-00087z-NF@rmk-PC.armlinux.org.uk>
Hi Russell,
On Thu, Jan 19, 2017 at 10:44 AM, Russell King
<rmk+kernel@armlinux.org.uk> wrote:
> Removal of skeleton.dtsi from imx6qdl.dtsi caused a regression on
> SolidRun platforms as the /chosen and /memory nodes are no longer
> populated. Fix this by adding the nodes into the platform .dtsi
> files.
>
> Uncompressing Linux... done, booting the kernel.
> Booting Linux on physical CPU 0x0
> Linux version 4.10.0-rc3+ (rmk at rmk-PC.arm.linux.org.uk) (gcc version 4.7.4 (GCC) ) #2066 SMP Thu Jan 19 12:31:19 GMT 2017
> CPU: ARMv7 Processor [412fc09a] revision 10 (ARMv7), cr=10c5387d
> CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
> OF: fdt:Machine model: SolidRun Cubox-i Dual/Quad
> INITRD: 0x20000000+0x001cd000 is not a memory region - disabling initrd
> cma: Failed to reserve 256 MiB
> Memory policy: Data cache writealloc
> Kernel panic - not syncing: ERROR: Failed to allocate 0x2000 bytes below 0x0.
>
> CPU: 0 PID: 0 Comm: swapper Not tainted 4.10.0-rc3+ #2066
> Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
> Backtrace: invalid frame pointer 0xc09e5e44c
> ---[ end Kernel panic - not syncing: ERROR: Failed to allocate 0x2000 bytes below 0x0.
>
> Fixes: 7f107887d199 ("ARM: dts: imx: Remove skeleton.dtsi")
> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
I made a previous attempt to fix this issue and realized that it was
not complete.
Just sent a v2, which hopefully will fix this problem for all i.MX dtsi files.
^ permalink raw reply
* [PATCH 1/4] ARM: mmu: decouple VECTORS_BASE from Kconfig
From: kbuild test robot @ 2017-01-19 14:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170118203739.6400-1-afzal.mohd.ma@gmail.com>
Hi afzal,
[auto build test ERROR on linus/master]
[also build test ERROR on v4.10-rc4 next-20170119]
[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/afzal-mohammed/ARM-mmu-decouple-VECTORS_BASE-from-Kconfig/20170119-171424
config: arm-stm32_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
Note: the linux-review/afzal-mohammed/ARM-mmu-decouple-VECTORS_BASE-from-Kconfig/20170119-171424 HEAD dd110acc21d40c8f50374de1e500a091d14f29c8 builds fine.
It only hurts bisectibility.
All error/warnings (new ones prefixed by >>):
arch/arm/mm/init.c: In function 'mem_init':
>> arch/arm/mm/init.c:525:11: error: 'VECTORS_BASEUL' undeclared (first use in this function)
MLK(UL(VECTORS_BASE), UL(VECTORS_BASE) + (PAGE_SIZE)),
^
arch/arm/mm/init.c:501:19: note: in definition of macro 'MLK'
#define MLK(b, t) b, t, ((t) - (b)) >> 10
^
>> include/uapi/linux/const.h:20:18: note: in expansion of macro '__AC'
#define _AC(X,Y) __AC(X,Y)
^~~~
>> arch/arm/include/asm/memory.h:29:15: note: in expansion of macro '_AC'
#define UL(x) _AC(x, UL)
^~~
>> include/linux/printk.h:297:36: note: in expansion of macro 'UL'
printk(KERN_NOTICE pr_fmt(fmt), ##__VA_ARGS__)
^~~~~~~~~~~
>> arch/arm/mm/init.c:505:2: note: in expansion of macro 'pr_notice'
pr_notice("Virtual kernel memory layout:\n"
^~~~~~~~~
arch/arm/mm/init.c:525:11: note: each undeclared identifier is reported only once for each function it appears in
MLK(UL(VECTORS_BASE), UL(VECTORS_BASE) + (PAGE_SIZE)),
^
arch/arm/mm/init.c:501:19: note: in definition of macro 'MLK'
#define MLK(b, t) b, t, ((t) - (b)) >> 10
^
>> include/uapi/linux/const.h:20:18: note: in expansion of macro '__AC'
#define _AC(X,Y) __AC(X,Y)
^~~~
>> arch/arm/include/asm/memory.h:29:15: note: in expansion of macro '_AC'
#define UL(x) _AC(x, UL)
^~~
>> include/linux/printk.h:297:36: note: in expansion of macro 'UL'
printk(KERN_NOTICE pr_fmt(fmt), ##__VA_ARGS__)
^~~~~~~~~~~
>> arch/arm/mm/init.c:505:2: note: in expansion of macro 'pr_notice'
pr_notice("Virtual kernel memory layout:\n"
^~~~~~~~~
vim +/VECTORS_BASEUL +525 arch/arm/mm/init.c
499 mem_init_print_info(NULL);
500
501 #define MLK(b, t) b, t, ((t) - (b)) >> 10
502 #define MLM(b, t) b, t, ((t) - (b)) >> 20
503 #define MLK_ROUNDUP(b, t) b, t, DIV_ROUND_UP(((t) - (b)), SZ_1K)
504
> 505 pr_notice("Virtual kernel memory layout:\n"
506 " vector : 0x%08lx - 0x%08lx (%4ld kB)\n"
507 #ifdef CONFIG_HAVE_TCM
508 " DTCM : 0x%08lx - 0x%08lx (%4ld kB)\n"
509 " ITCM : 0x%08lx - 0x%08lx (%4ld kB)\n"
510 #endif
511 " fixmap : 0x%08lx - 0x%08lx (%4ld kB)\n"
512 " vmalloc : 0x%08lx - 0x%08lx (%4ld MB)\n"
513 " lowmem : 0x%08lx - 0x%08lx (%4ld MB)\n"
514 #ifdef CONFIG_HIGHMEM
515 " pkmap : 0x%08lx - 0x%08lx (%4ld MB)\n"
516 #endif
517 #ifdef CONFIG_MODULES
518 " modules : 0x%08lx - 0x%08lx (%4ld MB)\n"
519 #endif
520 " .text : 0x%p" " - 0x%p" " (%4td kB)\n"
521 " .init : 0x%p" " - 0x%p" " (%4td kB)\n"
522 " .data : 0x%p" " - 0x%p" " (%4td kB)\n"
523 " .bss : 0x%p" " - 0x%p" " (%4td kB)\n",
524
> 525 MLK(UL(VECTORS_BASE), UL(VECTORS_BASE) + (PAGE_SIZE)),
526 #ifdef CONFIG_HAVE_TCM
527 MLK(DTCM_OFFSET, (unsigned long) dtcm_end),
528 MLK(ITCM_OFFSET, (unsigned long) itcm_end),
---
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: 8634 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170119/6e0941b0/attachment.gz>
^ permalink raw reply
* [PATCH 1/2] [media] exynos-gsc: Fix unbalanced pm_runtime_enable() error
From: Marek Szyprowski @ 2017-01-19 14:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484699402-28738-1-git-send-email-javier@osg.samsung.com>
Hi Javier,
On 2017-01-18 01:30, Javier Martinez Canillas wrote:
> Commit a006c04e6218 ("[media] exynos-gsc: Fixup clock management at
> ->remove()") changed the driver's .remove function logic to fist do
> a pm_runtime_get_sync() to make sure the device is powered before
> attempting to gate the gsc clock.
>
> But the commit also removed a pm_runtime_disable() call that leads
> to an unbalanced pm_runtime_enable() error if the driver is removed
> and re-probed:
>
> exynos-gsc 13e00000.video-scaler: Unbalanced pm_runtime_enable!
> exynos-gsc 13e10000.video-scaler: Unbalanced pm_runtime_enable!
>
> Fixes: a006c04e6218 ("[media] exynos-gsc: Fixup clock management at ->remove()")
> Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
I must have mixed something during the rebase of the Ulf's patch, because
the original one kept pm_runtime_disable in the right place:
http://lists.infradead.org/pipermail/linux-arm-kernel/2015-January/317678.html
I'm really sorry.
Acked-by: Marek Szyprowski <m.szyprowski@samsung.com>
> ---
>
> drivers/media/platform/exynos-gsc/gsc-core.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/media/platform/exynos-gsc/gsc-core.c b/drivers/media/platform/exynos-gsc/gsc-core.c
> index cbf75b6194b4..83272f10722d 100644
> --- a/drivers/media/platform/exynos-gsc/gsc-core.c
> +++ b/drivers/media/platform/exynos-gsc/gsc-core.c
> @@ -1118,6 +1118,7 @@ static int gsc_remove(struct platform_device *pdev)
> clk_disable_unprepare(gsc->clock[i]);
>
> pm_runtime_put_noidle(&pdev->dev);
> + pm_runtime_disable(&pdev->dev);
>
> dev_dbg(&pdev->dev, "%s driver unloaded\n", pdev->name);
> return 0;
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
^ permalink raw reply
* [PATCH v2] ARM: dts: imx: Pass 'chosen' and 'memory' nodes
From: Uwe Kleine-König @ 2017-01-19 14:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484834566-19845-1-git-send-email-fabio.estevam@nxp.com>
On Thu, Jan 19, 2017 at 12:02:46PM -0200, Fabio Estevam wrote:
> Commit 7f107887d199 ("ARM: dts: imx: Remove skeleton.dtsi") causes boot
> issues when the bootloader does not create a 'chosen' node if such node
> is not present in the dtb.
>
> The reason for the boot failure is well explained by Javier Martinez
> Canillas: "the decompressor relies on a pre-existing chosen node to be
> available to insert the command line and merge other ATAGS info."
>
> , so pass an empty 'chosen' node to fix the boot problem.
>
> This issue has been seen in the kernelci reports with Barebox as
> bootloader.
>
> Also pass the 'memory' node in order to fix boot issues on the SolidRun
> iMX6 platforms.
>
> Fixes: 7f107887d199 ("ARM: dts: imx: Remove skeleton.dtsi")
> Reported-by: kernelci.org bot <bot@kernelci.org>
> Reported-by: Russell King <rmk+kernel@armlinux.org.uk>
> Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
> ---
> Changes since v1:
> - Also pass the memory node.
>
> arch/arm/boot/dts/imx1.dtsi | 2 ++
> arch/arm/boot/dts/imx23.dtsi | 2 ++
> arch/arm/boot/dts/imx25.dtsi | 2 ++
> arch/arm/boot/dts/imx27.dtsi | 2 ++
> arch/arm/boot/dts/imx28.dtsi | 2 ++
> arch/arm/boot/dts/imx31.dtsi | 2 ++
> arch/arm/boot/dts/imx35.dtsi | 2 ++
> arch/arm/boot/dts/imx50.dtsi | 2 ++
> arch/arm/boot/dts/imx51.dtsi | 2 ++
> arch/arm/boot/dts/imx53.dtsi | 2 ++
> arch/arm/boot/dts/imx6qdl.dtsi | 2 ++
> arch/arm/boot/dts/imx6sl.dtsi | 2 ++
> arch/arm/boot/dts/imx6sx.dtsi | 2 ++
> arch/arm/boot/dts/imx6ul.dtsi | 2 ++
> arch/arm/boot/dts/imx7s.dtsi | 2 ++
> 15 files changed, 30 insertions(+)
>
> diff --git a/arch/arm/boot/dts/imx1.dtsi b/arch/arm/boot/dts/imx1.dtsi
> index dd3de38..7ef0d36 100644
> --- a/arch/arm/boot/dts/imx1.dtsi
> +++ b/arch/arm/boot/dts/imx1.dtsi
> @@ -18,6 +18,8 @@
> / {
> #address-cells = <1>;
> #size-cells = <1>;
> + chosen {};
> + memory { device_type = "memory"; reg = <0 0>; };
Would it be nice to add a comment about why this was added? Something to
prevent a cleanup like "remove empty nodes and invalid memory
configurations".
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* [PATCH 2/2] [media] exynos-gsc: Fix imprecise external abort due disabled power domain
From: Marek Szyprowski @ 2017-01-19 14:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484699402-28738-2-git-send-email-javier@osg.samsung.com>
Hi Javier,
On 2017-01-18 01:30, Javier Martinez Canillas wrote:
> Commit 15f90ab57acc ("[media] exynos-gsc: Make driver functional when
> CONFIG_PM is unset") removed the implicit dependency that the driver
> had with CONFIG_PM, since it relied on the config option to be enabled.
>
> In order to work with !CONFIG_PM, the GSC reset logic that happens in
> the runtime resume callback had to be executed on the probe function.
>
> The problem is that if CONFIG_PM is enabled, the power domain for the
> GSC could be disabled and so an attempt to write to the GSC_SW_RESET
> register leads to an unhandled fault / imprecise external abort error:
Driver core ensures that driver's probe() is called with respective power
domain turned on, so this is not the right reason for the proposed change.
> [ 10.178825] Unhandled fault: imprecise external abort (0x1406) at 0x00000000
> [ 10.186982] pgd = ed728000
> [ 10.190847] [00000000] *pgd=00000000
> [ 10.195553] Internal error: : 1406 [#1] PREEMPT SMP ARM
> [ 10.229761] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
> [ 10.237134] task: ed49e400 task.stack: ed724000
> [ 10.242934] PC is at gsc_wait_reset+0x5c/0x6c [exynos_gsc]
> [ 10.249710] LR is at gsc_probe+0x300/0x33c [exynos_gsc]
> [ 10.256139] pc : [<bf2429e0>] lr : [<bf240734>] psr: 60070013
> [ 10.256139] sp : ed725d30 ip : 00000000 fp : 00000001
> [ 10.271492] r10: eea74800 r9 : ecd6a2c0 r8 : ed7d8854
> [ 10.277912] r7 : ed7d8c08 r6 : ed7d8810 r5 : ffff8ecd r4 : c0c03900
> [ 10.285664] r3 : 00000000 r2 : 00000001 r1 : ed7d8b98 r0 : ed7d8810
>
> So only do a GSC reset if CONFIG_PM is disabled, since if is enabled the
> runtime PM resume callback will be called by the VIDIOC_STREAMON ioctl,
> making the reset in probe unneeded.
>
> Fixes: 15f90ab57acc ("[media] exynos-gsc: Make driver functional when CONFIG_PM is unset")
> Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
Frankly, I don't get why this change is needed.
>
> ---
>
> I-ve only tested with CONFIG_PM enabled since my Exynos5422 Odroid
> XU4 board fails to boot when the config option is disabled.
>
> Best regards,
> Javier
>
> drivers/media/platform/exynos-gsc/gsc-core.c | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/media/platform/exynos-gsc/gsc-core.c b/drivers/media/platform/exynos-gsc/gsc-core.c
> index 83272f10722d..42e1e09ea915 100644
> --- a/drivers/media/platform/exynos-gsc/gsc-core.c
> +++ b/drivers/media/platform/exynos-gsc/gsc-core.c
> @@ -1083,8 +1083,10 @@ static int gsc_probe(struct platform_device *pdev)
>
> platform_set_drvdata(pdev, gsc);
>
> - gsc_hw_set_sw_reset(gsc);
> - gsc_wait_reset(gsc);
> + if (!IS_ENABLED(CONFIG_PM)) {
> + gsc_hw_set_sw_reset(gsc);
> + gsc_wait_reset(gsc);
> + }
>
> vb2_dma_contig_set_max_seg_size(dev, DMA_BIT_MASK(32));
>
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
^ permalink raw reply
* [PATCH v1 2/2] arm: dts: mt2701: add nor flash node
From: Rob Herring @ 2017-01-19 14:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170119091428.598eb987@bbrezillon>
On Thu, Jan 19, 2017 at 2:14 AM, Boris Brezillon
<boris.brezillon@free-electrons.com> wrote:
> Hi Rob,
>
> On Wed, 18 Jan 2017 20:51:08 -0600
> Rob Herring <robh@kernel.org> wrote:
>
>> On Wed, Jan 18, 2017 at 5:38 PM, Thomas Petazzoni
>> <thomas.petazzoni@free-electrons.com> wrote:
>> > Hello,
>> >
>> > On Wed, 18 Jan 2017 16:20:10 -0600, Rob Herring wrote:
>> >
>> >> > > Rob, Mark, any opinion?
>> >> >
>> >>
>> >> Sigh, is how to do compatibles really not yet understood?
>> >
>> > Well, it seems like not everyone necessarily understands what is the
>> > best strategy to adopt (me included).
>> >
>> >> > I agree that a clarification would be good. There are really two
>> >> > options:
>> >> >
>> >> > 1. Have two compatible strings in the DT, the one that matches the
>> >> > exact SoC where the IP is found (first compatible string) and the
>> >> > one that matches some other SoC where the same IP is found (second
>> >> > compatible string). Originally, Linux only supports the second
>> >> > compatible string in its device driver, but if it happens that a
>> >> > difference is found between two IPs that we thought were the same,
>> >> > we can add support for the first compatible string in the driver,
>> >> > with a slightly different behavior.
>> >>
>> >> This. And no wildcards in the compatible string.
>> >
>> > OK. So it means that today we do something like:
>> >
>> > compatible = "baz,foo-12", "baz,foo-00";
>> >
>> > and support only baz,foo-00 in the driver. If tomorrow we discover
>> > that there is in fact a difference between the two IP blocks, we can
>> > add support for baz,foo-12 in the driver, and handle the differences.
>> >
>> > But then, the DT still contains:
>> >
>> > compatible = "baz,foo-12", "baz,foo-00";
>> >
>> > and therefore pretends that the IP block is compatible with
>> > "baz,foo-00" which is in fact *not* the case. It was a mistake to
>> > consider it as compatible. So we keep living with a DT that has
>> > incorrect information.
>>
>> I wouldn't say it's a mistake necessarily. The old compatible would
>> probably work to some extent. I'd assume it was tested to some level.
>> Or it could be other changes exposing a difference.
>
> One last question and I'm done: is something like that acceptable?
>
> compatible = "<vendor>,<old-soc>","<vendor>,<new-soc>";
>
> This can happen when someone adds support for an unsupported feature
> on a brand new SoC, and then someone else use the same driver for an
> older SoC embedding the same IP but still wants to add a new compatible
> just in case these 2 IPs appear to be slightly different.
Yes, it's old and new compatible strings in this case and it's newest
compatible string first.
> Here the order of compat strings is no longer following a clear rule
> like 'most-specific compatible first' or 'newest IP/SoC version first',
> it's completely dependent on the order these IPs were supported in the
> OS (Linux). I'm perfectly fine with that BTW, just want to make sure
> this is authorized.
I guess we should say "newest compatible for IP first" instead. There
are some exceptions where we add fallbacks later on, but that falls
under the most-specific part.
It's order that the bindings are defined, not Linux support really,
but in practice those are the same.
Rob
^ permalink raw reply
* [PATCH 1/2] [media] exynos-gsc: Fix unbalanced pm_runtime_enable() error
From: Javier Martinez Canillas @ 2017-01-19 14:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <74767acf-052e-80ec-7172-67306b73b691@samsung.com>
Hello Marek,
On 01/19/2017 11:12 AM, Marek Szyprowski wrote:
> Hi Javier,
>
> On 2017-01-18 01:30, Javier Martinez Canillas wrote:
>> Commit a006c04e6218 ("[media] exynos-gsc: Fixup clock management at
>> ->remove()") changed the driver's .remove function logic to fist do
>> a pm_runtime_get_sync() to make sure the device is powered before
>> attempting to gate the gsc clock.
>>
>> But the commit also removed a pm_runtime_disable() call that leads
>> to an unbalanced pm_runtime_enable() error if the driver is removed
>> and re-probed:
>>
>> exynos-gsc 13e00000.video-scaler: Unbalanced pm_runtime_enable!
>> exynos-gsc 13e10000.video-scaler: Unbalanced pm_runtime_enable!
>>
>> Fixes: a006c04e6218 ("[media] exynos-gsc: Fixup clock management at ->remove()")
>> Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
>
> I must have mixed something during the rebase of the Ulf's patch, because
> the original one kept pm_runtime_disable in the right place:
> http://lists.infradead.org/pipermail/linux-arm-kernel/2015-January/317678.html
>
> I'm really sorry.
>
Ah, I see. No worries.
> Acked-by: Marek Szyprowski <m.szyprowski@samsung.com>
>
Thanks a lot for your review.
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
^ permalink raw reply
* [PATCH 1/2] ARM: imx6: fix min/max voltage of anatop 2p5 regulator
From: Lucas Stach @ 2017-01-19 14:21 UTC (permalink / raw)
To: linux-arm-kernel
The regulation bound of this regulator are 2.1V to 2.875V, the
wrong DT values cause the driver to miscalculate the effective
voltage.
This isn't really an issue right now, as nobody actively changes
the regulator voltage, but better fix it now.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
---
arch/arm/boot/dts/imx6qdl.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
index 53e6e63cbb02..9313b9af2da8 100644
--- a/arch/arm/boot/dts/imx6qdl.dtsi
+++ b/arch/arm/boot/dts/imx6qdl.dtsi
@@ -661,8 +661,8 @@
anatop-vol-bit-shift = <8>;
anatop-vol-bit-width = <5>;
anatop-min-bit-val = <0>;
- anatop-min-voltage = <2000000>;
- anatop-max-voltage = <2750000>;
+ anatop-min-voltage = <2100000>;
+ anatop-max-voltage = <2875000>;
};
reg_arm: regulator-vddcore {
--
2.11.0
^ permalink raw reply related
* [PATCH 2/2] ARM: imx6: fix regulator constraints on anatop 1p1 and 2p5
From: Lucas Stach @ 2017-01-19 14:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170119142134.8572-1-l.stach@pengutronix.de>
Fix the min/max voltage constraints for the anatop 1p1 and 2p5
regulator to match the typical operating range mentioned in the
datasheet.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
---
arch/arm/boot/dts/imx6qdl.dtsi | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
index 9313b9af2da8..e9ba244cda54 100644
--- a/arch/arm/boot/dts/imx6qdl.dtsi
+++ b/arch/arm/boot/dts/imx6qdl.dtsi
@@ -626,8 +626,8 @@
regulator-1p1 {
compatible = "fsl,anatop-regulator";
regulator-name = "vdd1p1";
- regulator-min-microvolt = <800000>;
- regulator-max-microvolt = <1375000>;
+ regulator-min-microvolt = <1000000>;
+ regulator-max-microvolt = <1200000>;
regulator-always-on;
anatop-reg-offset = <0x110>;
anatop-vol-bit-shift = <8>;
@@ -654,7 +654,7 @@
regulator-2p5 {
compatible = "fsl,anatop-regulator";
regulator-name = "vdd2p5";
- regulator-min-microvolt = <2000000>;
+ regulator-min-microvolt = <2250000>;
regulator-max-microvolt = <2750000>;
regulator-always-on;
anatop-reg-offset = <0x130>;
--
2.11.0
^ permalink raw reply related
* [PATCH 1/3] ARM: dts: Add support for phyCORE-AM335x PCM-953 carrier board
From: Vladimir Zapolskiy @ 2017-01-19 14:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484831270-7251-1-git-send-email-t.remmet@phytec.de>
On 01/19/2017 03:07 PM, Teresa Remmet wrote:
> The phyCORE-AM335x development kit is a combination of the
> phyCORE-AM335x SoM and a PCM-953 carrier board. The features
> of the PCM-953 are:
> * ETH phy on carrier board: 1x RGMII
> * 1x CAN
> * Up to 4x UART
> * USB0 (otg)
> * USB1 (host)
> * SD slot
> * User gpio-keys
> * User LEDs
>
> Signed-off-by: Teresa Remmet <t.remmet@phytec.de>
> Reviewed-by: Wadim Egorov <w.egorov@phytec.de>
> ---
> .../devicetree/bindings/arm/omap/omap.txt | 3 +
> arch/arm/boot/dts/Makefile | 1 +
> arch/arm/boot/dts/am335x-pcm-953.dtsi | 303 +++++++++++++++++++++
> arch/arm/boot/dts/am335x-phycore-rdk.dts | 27 ++
> 4 files changed, 334 insertions(+)
> create mode 100644 arch/arm/boot/dts/am335x-pcm-953.dtsi
> create mode 100644 arch/arm/boot/dts/am335x-phycore-rdk.dts
>
> diff --git a/Documentation/devicetree/bindings/arm/omap/omap.txt b/Documentation/devicetree/bindings/arm/omap/omap.txt
> index 05f95c3..8219b2c 100644
> --- a/Documentation/devicetree/bindings/arm/omap/omap.txt
> +++ b/Documentation/devicetree/bindings/arm/omap/omap.txt
> @@ -151,6 +151,9 @@ Boards:
> - AM335X SBC-T335 : single board computer, built around the Sitara AM3352/4
> compatible = "compulab,sbc-t335", "compulab,cm-t335", "ti,am33xx"
>
> +- AM335X phyCORE-AM335x: Development kit
> + compatible = "phytec,am335x-pcm-953", "phytec,am335x-phycore-som", "ti,am33xx"
> +
> - OMAP5 EVM : Evaluation Module
> compatible = "ti,omap5-evm", "ti,omap5"
>
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index 7327250..dd71afe 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -573,6 +573,7 @@ dtb-$(CONFIG_SOC_AM33XX) += \
> am335x-lxm.dtb \
> am335x-nano.dtb \
> am335x-pepper.dtb \
> + am335x-phycore-rdk.dtb \
> am335x-shc.dtb \
> am335x-sbc-t335.dtb \
> am335x-sl50.dtb \
> diff --git a/arch/arm/boot/dts/am335x-pcm-953.dtsi b/arch/arm/boot/dts/am335x-pcm-953.dtsi
> new file mode 100644
> index 0000000..54a171d
> --- /dev/null
> +++ b/arch/arm/boot/dts/am335x-pcm-953.dtsi
> @@ -0,0 +1,303 @@
> +/*
> + * Copyright (C) 2014-2017 Phytec Messtechnik GmbH
> + * Author: Wadim Egorov <w.egorov@phytec.de>
> + * Teresa Remmet <t.remmet@phytec.de>
> + *
> + * 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.
> + */
> +
> +#include <dt-bindings/input/input.h>
> +
> +/ {
> + model = "Phytec AM335x PCM-953";
> + compatible = "phytec,am335x-pcm-953", "phytec,am335x-phycore-som", "ti,am33xx";
> +
> + user_leds: user_leds {
> + compatible = "gpio-leds";
> + };
> +
> + user_buttons: user_buttons {
> + compatible = "gpio-keys";
> + };
> +
> + regulators {
> + compatible = "simple-bus";
Please drop "simple-bus" compatible, see http://www.spinics.net/lists/linux-usb/msg101497.html
> +
> + vcc3v3: fixedregulator at 1 {
> + compatible = "regulator-fixed";
> + };
> +
> + vcc1v8: fixedregulator at 2 {
> + compatible = "regulator-fixed";
> + };
> + };
> +};
> +
> +/* CAN */
> +&am33xx_pinmux {
Which .dtsi file contains the referenced am33xx_pinmux device node?
You should include that file firstly, this is relevant to all other
references to device nodes used in this file.
> + dcan1_pins: pinmux_dcan1 {
> + pinctrl-single,pins = <
> + AM33XX_IOPAD(0x980, PIN_OUTPUT_PULLUP | MUX_MODE2) /* uart1_rxd.dcan1_tx_mux2 */
> + AM33XX_IOPAD(0x984, PIN_INPUT_PULLUP | MUX_MODE2) /* uart1_txd.dcan1_rx_mux2 */
> + >;
> + };
> +};
> +
> +&dcan1 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&dcan1_pins>;
> + status = "okay";
> +};
> +
> +/* Ethernet */
> +&am33xx_pinmux {
> + ethernet1_pins: pinmux_ethernet1 {
> + pinctrl-single,pins = <
> + AM33XX_IOPAD(0x840, PIN_OUTPUT_PULLDOWN | MUX_MODE2) /* gpmc_a0.rgmii2_tctl */
> + AM33XX_IOPAD(0x844, PIN_INPUT_PULLDOWN | MUX_MODE2) /* gpmc_a1.rgmii2_rctl */
> + AM33XX_IOPAD(0x848, PIN_OUTPUT_PULLDOWN | MUX_MODE2) /* gpmc_a2.rgmii2_td3 */
> + AM33XX_IOPAD(0x84c, PIN_OUTPUT_PULLDOWN | MUX_MODE2) /* gpmc_a3.rgmii2_td2 */
> + AM33XX_IOPAD(0x850, PIN_OUTPUT_PULLDOWN | MUX_MODE2) /* gpmc_a4.rgmii2_td1 */
> + AM33XX_IOPAD(0x854, PIN_OUTPUT_PULLDOWN | MUX_MODE2) /* gpmc_a5.rgmii2_td0 */
> + AM33XX_IOPAD(0x858, PIN_OUTPUT_PULLDOWN | MUX_MODE2) /* gpmc_a6.rgmii2_tclk */
> + AM33XX_IOPAD(0x85c, PIN_INPUT_PULLDOWN | MUX_MODE2) /* gpmc_a7.rgmii2_rclk */
> + AM33XX_IOPAD(0x860, PIN_INPUT_PULLDOWN | MUX_MODE2) /* gpmc_a8.rgmii2_rd3 */
> + AM33XX_IOPAD(0x864, PIN_INPUT_PULLDOWN | MUX_MODE2) /* gpmc_a9.rgmii2_rd2 */
> + AM33XX_IOPAD(0x868, PIN_INPUT_PULLDOWN | MUX_MODE2) /* gpmc_a10.rgmii2_rd1 */
> + AM33XX_IOPAD(0x86c, PIN_INPUT_PULLDOWN | MUX_MODE2) /* gpmc_a11.rgmii2_rd0 */
> + >;
> + };
> +};
> +
> +&cpsw_emac1 {
> + phy-handle = <&phy1>;
> + phy-mode = "rgmii-id";
> + dual_emac_res_vlan = <2>;
> + status = "okay";
> +};
> +
> +&davinci_mdio {
> + phy1: ethernet-phy at 1 {
> + reg = <2>;
There is a mismatch between unit address and 'reg' property values.
> +
> + /* Register 260 (104h) ? RGMII Clock and Control Pad Skew */
> + rxc-skew-ps = <1400>;
> + rxdv-skew-ps = <0>;
> + txc-skew-ps = <1400>;
> + txen-skew-ps = <0>;
> + /* Register 261 (105h) ? RGMII RX Data Pad Skew */
> + rxd3-skew-ps = <0>;
> + rxd2-skew-ps = <0>;
> + rxd1-skew-ps = <0>;
> + rxd0-skew-ps = <0>;
> + /* Register 262 (106h) ? RGMII TX Data Pad Skew */
> + txd3-skew-ps = <0>;
> + txd2-skew-ps = <0>;
> + txd1-skew-ps = <0>;
> + txd0-skew-ps = <0>;
> + };
> +};
> +
> +&mac {
> + slaves = <2>;
> + pinctrl-names = "default";
> + pinctrl-0 = <ðernet0_pins ðernet1_pins>;
> + dual_emac;
It seems that TI has properties with underscores in the names, acked.
> +};
> +
> +/* Misc */
> +&am33xx_pinmux {
> + pinctrl-names = "default";
> + pinctrl-0 = <&cb_gpio_pins>;
> +
> + cb_gpio_pins: pinmux_cb_gpio {
> + pinctrl-single,pins = <
> + AM33XX_IOPAD(0x968, PIN_OUTPUT_PULLDOWN | MUX_MODE7) /* uart0_ctsn.gpio1_8 */
> + AM33XX_IOPAD(0x96c, PIN_OUTPUT_PULLDOWN | MUX_MODE7) /* uart0_rtsn.gpio1_9 */
> + >;
> + };
> +};
> +
> +/* MMC */
> +&am33xx_pinmux {
> + mmc1_pins: pinmux_mmc1_pins {
> + pinctrl-single,pins = <
> + AM33XX_IOPAD(0x8f0, PIN_INPUT_PULLUP | MUX_MODE0) /* mmc0_dat3.mmc0_dat3 */
> + AM33XX_IOPAD(0x8f4, PIN_INPUT_PULLUP | MUX_MODE0) /* mmc0_dat2.mmc0_dat2 */
> + AM33XX_IOPAD(0x8f8, PIN_INPUT_PULLUP | MUX_MODE0) /* mmc0_dat1.mmc0_dat1 */
> + AM33XX_IOPAD(0x8fc, PIN_INPUT_PULLUP | MUX_MODE0) /* mmc0_dat0.mmc0_dat0 */
> + AM33XX_IOPAD(0x900, PIN_INPUT_PULLUP | MUX_MODE0) /* mmc0_clk.mmc0_clk */
> + AM33XX_IOPAD(0x904, PIN_INPUT_PULLUP | MUX_MODE0) /* mmc0_cmd.mmc0_cmd */
> + AM33XX_IOPAD(0x960, PIN_INPUT_PULLUP | MUX_MODE7) /* spi0_cs1.mmc0_sdcd */
> + >;
> + };
> +};
> +
> +&mmc1 {
> + vmmc-supply = <&vcc3v3>;
> + bus-width = <4>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&mmc1_pins>;
> + cd-gpios = <&gpio0 6 GPIO_ACTIVE_HIGH>;
> + status = "okay";
> +};
> +
> +/* Power */
> +&vcc3v3 {
> + regulator-name = "vcc3v3";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + regulator-boot-on;
> +};
Please add properties directly into vcc3v3 device node.
> +
> +&vcc1v8 {
> + regulator-name = "vcc1v8";
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + regulator-boot-on;
> +};
> +
Please add properties directly into vcc1v8 device node.
> +/* UARTs */
> +&am33xx_pinmux {
> + uart0_pins: pinmux_uart0 {
> + pinctrl-single,pins = <
> + AM33XX_IOPAD(0x970, PIN_INPUT_PULLUP | MUX_MODE0) /* uart0_rxd.uart0_rxd */
> + AM33XX_IOPAD(0x974, PIN_OUTPUT_PULLDOWN | MUX_MODE0) /* uart0_txd.uart0_txd */
> + >;
> + };
> +
> + uart1_pins: pinmux_uart1 {
> + pinctrl-single,pins = <
> + AM33XX_IOPAD(0x980, PIN_INPUT_PULLUP | MUX_MODE0) /* uart1_rxd.uart1_rxd */
> + AM33XX_IOPAD(0x984, PIN_OUTPUT_PULLDOWN | MUX_MODE0) /* uart1_txd.uart1_txd */
> + AM33XX_IOPAD(0x978, PIN_INPUT | MUX_MODE0) /* uart1_ctsn.uart1_ctsn */
> + AM33XX_IOPAD(0x97c, PIN_OUTPUT_PULLDOWN | MUX_MODE0) /* uart1_rtsn.uart1_rtsn */
> + >;
> + };
> +
> + uart2_pins: pinmux_uart2 {
> + pinctrl-single,pins = <
> + AM33XX_IOPAD(0x92c, PIN_INPUT_PULLUP | MUX_MODE1) /* mii1_tx_clk.uart2_rxd */
> + AM33XX_IOPAD(0x930, PIN_OUTPUT_PULLDOWN | MUX_MODE1) /* mii1_rx_clk.uart2_txd */
> + >;
> + };
> +
> + uart3_pins: pinmux_uart3 {
> + pinctrl-single,pins = <
> + AM33XX_IOPAD(0x934, PIN_INPUT_PULLUP | MUX_MODE1) /* mii1_rxd3.uart3_rxd */
> + AM33XX_IOPAD(0x938, PIN_OUTPUT_PULLDOWN | MUX_MODE1) /* mii1_rxd2.uart3_txd */
> + >;
> + };
> +};
> +
> +&uart0 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&uart0_pins>;
> + status = "okay";
> +};
> +
> +&uart1 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&uart1_pins>;
> +};
> +
> +&uart2 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&uart2_pins>;
> + status = "okay";
> +};
> +
> +&uart3 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&uart3_pins>;
> + status = "okay";
> +};
> +
> +/* USB */
> +&cppi41dma {
> + status = "okay";
> +};
> +
> +&usb_ctrl_mod {
> + status = "okay";
> +};
> +
> +&usb {
> + status = "okay";
> +};
> +
> +&usb0 {
> + status = "okay";
> +};
> +
> +&usb0_phy {
> + status = "okay";
> +};
> +
> +&usb1 {
> + status = "okay";
> + dr_mode = "host";
> +};
> +
> +&usb1_phy {
> + status = "okay";
> +};
> +
> +/* User IO */
> +&am33xx_pinmux {
> + user_buttons_pins: pinmux_user_buttons {
> + pinctrl-single,pins = <
> + AM33XX_IOPAD(0x9e4, PIN_INPUT_PULLDOWN | MUX_MODE7) /* emu0.gpio3_7 */
> + AM33XX_IOPAD(0x9e8, PIN_INPUT_PULLDOWN | MUX_MODE7) /* emu1.gpio3_8 */
> + >;
> + };
> +
> + user_leds_pins: pinmux_user_leds {
> + pinctrl-single,pins = <
> + AM33XX_IOPAD(0x880, PIN_OUTPUT_PULLDOWN | MUX_MODE7) /* gpmc_csn1.gpio1_30 */
> + AM33XX_IOPAD(0x884, PIN_OUTPUT_PULLDOWN | MUX_MODE7) /* gpmc_csn2.gpio1_31 */
> + >;
> + };
> +};
> +
> +&user_buttons {
Please add properties directly into user_buttons device node.
> + pinctrl-names = "default";
> + pinctrl-0 = <&user_buttons_pins>;
> + status = "okay";
Please remove the redundant property above.
> +
> + button at 0 {
> + label = "home";
> + linux,code = <KEY_HOME>;
> + gpios = <&gpio3 7 GPIO_ACTIVE_HIGH>;
> + gpio-key,wakeup;
> + };
> +
> + button at 1 {
> + label = "menu";
> + linux,code = <KEY_MENU>;
> + gpios = <&gpio3 8 GPIO_ACTIVE_HIGH>;
> + gpio-key,wakeup;
> + };
> +};
> +
> +&user_leds {
Please add properties directly into user_leds device node.
> + pinctrl-names = "default";
> + pinctrl-0 = <&user_leds_pins>;
> + status = "okay";
Please remove the redundant property above.
> +
> + green {
> + label = "green:user";
> + gpios = <&gpio1 30 GPIO_ACTIVE_HIGH>;
> + linux,default-trigger = "gpio";
> + default-state = "on";
> + };
> +
> + yellow {
> + label = "yellow:user";
> + gpios = <&gpio1 31 GPIO_ACTIVE_LOW>;
> + linux,default-trigger = "gpio";
> + default-state = "on";
> + };
> +};
> diff --git a/arch/arm/boot/dts/am335x-phycore-rdk.dts b/arch/arm/boot/dts/am335x-phycore-rdk.dts
> new file mode 100644
> index 0000000..305f0b3
> --- /dev/null
> +++ b/arch/arm/boot/dts/am335x-phycore-rdk.dts
> @@ -0,0 +1,27 @@
> +/*
> + * Copyright (C) 2014 PHYTEC Messtechnik GmbH
> + * Author: Wadim Egorov <w.egorov@phytec.de>
> + *
> + * 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.
> + */
> +
> +/dts-v1/;
> +
> +#include "am335x-phycore-som.dtsi"
> +#include "am335x-pcm-953.dtsi"
> +
> +/* SoM */
> +&i2c_eeprom {
> + status = "okay";
> +};
> +
> +&i2c_rtc {
> + status = "okay";
> +};
> +
> +&serial_flash {
> + status = "okay";
> +
> +};
>
^ permalink raw reply
* [PATCH 1/4] ARM: mmu: decouple VECTORS_BASE from Kconfig
From: Russell King - ARM Linux @ 2017-01-19 14:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170118203739.6400-1-afzal.mohd.ma@gmail.com>
On Thu, Jan 19, 2017 at 02:07:39AM +0530, afzal mohammed wrote:
> diff --git a/arch/arm/include/asm/memory.h b/arch/arm/include/asm/memory.h
> index 76cbd9c674df..9cc9f1dbc88e 100644
> --- a/arch/arm/include/asm/memory.h
> +++ b/arch/arm/include/asm/memory.h
> @@ -83,6 +83,8 @@
> #define IOREMAP_MAX_ORDER 24
> #endif
>
> +#define VECTORS_BASE 0xffff0000
This should be UL(0xffff0000)
> - MLK(UL(CONFIG_VECTORS_BASE), UL(CONFIG_VECTORS_BASE) +
> - (PAGE_SIZE)),
> + MLK(UL(VECTORS_BASE), UL(VECTORS_BASE) + (PAGE_SIZE)),
which means you don't need it here, which will then fix the build error
reported by the 0-day builder.
--
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
* imx6: PCIe imx6_pcie_assert_core_reset() hangs after watchdog reset
From: Lucas Stach @ 2017-01-19 14:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOMZO5C+3rCnpQvonXyDaMmUxsDYAnXRBXrUwbP3AT5TbofSgQ@mail.gmail.com>
Hi Fabio,
Am Montag, den 07.11.2016, 10:15 -0200 schrieb Fabio Estevam:
> Hi Lucas,
>
> On Mon, Nov 7, 2016 at 8:34 AM, Lucas Stach <l.stach@pengutronix.de> wrote:
>
> > The problem is definitely present in current mainline Linux. I intent to
> > remove this workaround from the kernel, but we need to make sure that
> > the bootloader properly disables PCIe before jumping to the kernel
> > image.
> >
> > I don't know what the status of this is in U-Boot, but Barebox already
> > does this correctly.
> >
> > Fabio, would you mind to port this coed to U-Boot, or at least check if
> > it does the right thing?
>
> Sure, could you point me to the Barebox fix so I can take a look?
Did you have some time to validate/fix this in U-Boot? I would like to
get the workaround removed from the kernel.
Regards,
Lucas
^ permalink raw reply
* [PATCH net-next v3 06/10] net: dsa: Migrate to device_find_class()
From: Greg KH @ 2017-01-19 14:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <912e6143-c67a-d909-2a6c-939de79efc5d@gmail.com>
On Mon, Jan 16, 2017 at 12:01:02PM -0800, Florian Fainelli wrote:
> On 01/15/2017 11:16 AM, Andrew Lunn wrote:
> >>> What exactly is the relationship between these devices (a ascii-art tree
> >>> or sysfs tree output might be nice) so I can try to understand what is
> >>> going on here.
> >
> > Hi Greg, Florian
> >
> > A few diagrams and trees which might help understand what is going on.
> >
> > The first diagram comes from the 2008 patch which added all this code:
> >
> > +-----------+ +-----------+
> > | | RGMII | |
> > | +-------+ +------ 1000baseT MDI ("WAN")
> > | | | 6-port +------ 1000baseT MDI ("LAN1")
> > | CPU | | ethernet +------ 1000baseT MDI ("LAN2")
> > | |MIImgmt| switch +------ 1000baseT MDI ("LAN3")
> > | +-------+ w/5 PHYs +------ 1000baseT MDI ("LAN4")
> > | | | |
> > +-----------+ +-----------+
> >
> > We have an ethernet switch and a host CPU. The switch is connected to
> > the CPU in two different ways. RGMII allows us to get Ethernet frames
> > from the CPU into the switch. MIImgmt, is the management bus normally
> > used for Ethernet PHYs, but Marvell switches also use it for Managing
> > switches.
> >
> > The diagram above is the simplest setup. You can have multiple
> > Ethernet switches, connected together via switch ports. Each switch
> > has its own MIImgmt connect to the CPU, but there is only one RGMII
> > link.
> >
> > When this code was designed back in 2008, it was decided to represent
> > this is a platform device, and it has a platform_data, which i have
> > slightly edited to keep it simple:
> >
> > struct dsa_platform_data {
> > /*
> > * Reference to a Linux network interface that connects
> > * to the root switch chip of the tree.
> > */
> > struct device *netdev;
This I think is the oddest thing, why do you need to have the "root
switch" here? You seem to have dropped the next value in this
structure:
struct net_device *of_netdev;
Isn't that the "real" net_device you need/want to get to here?
Or, when you set netdev, can't you also point to the "real" net_device
you want to later get to?
> > /*
> > * Info structs describing each of the switch chips
> > * connected via this network interface.
> > */
> > int nr_chips;
> > struct dsa_chip_data *chip;
> > };
> >
> > This netdev is the CPU side of the RGMII interface.
> >
> > Each switch has a dsa_chip_data, again edited:
> >
> > struct dsa_chip_data {
> > /*
> > * How to access the switch configuration registers.
> > */
> > struct device *host_dev;
> > int sw_addr;
> > ...
> > }
If each switch only has one dsa_chip_data, can't you point directly from
that structure back to the dsa_platform_device? Or is that what this
"host_dev" pointer is pointing to?
> > The host_dev is the CPU side of the MIImgmt, and we have the address
> > the switch is using on the bus.
"cpu side" means what? What 'struct device' is this? The host
controller? The platform device? Something else?
> > During probe of this platform device, we need to get from the
> > struct device *netdev to a struct net_device *dev.
Wait, what exactly is this "struct device *"? Who created it?
And why are you using a platform device? Shouldn't this be a custom
bus? I know people like to abuse platform devices, is that the case
here, or is it really driven only by a device tree representation?
Shouldn't you have a bus for RGMII devices? Is that the real problem
here, you don't have a representation for your RGMII "bus" with a
controller to bundle everything under (like a USB host controller, it
bridges from one bus to another).
> > So the code looks in the device net class to find the device
> >
> > | | | |-- f1074000.ethernet
> > | | | | |-- deferred_probe
> > | | | | |-- driver -> ../../../../../bus/platform/drivers/mvneta
> > | | | | |-- driver_override
> > | | | | |-- modalias
> > | | | | |-- net
> > | | | | | `-- eth1
> > | | | | | |-- addr_assign_type
> > | | | | | |-- address
> > | | | | | |-- addr_len
> > | | | | | |-- broadcast
> > | | | | | |-- carrier
> > | | | | | |-- carrier_changes
> > | | | | | |-- deferred_probe
> > | | | | | |-- device -> ../../../f1074000.ethernet
> >
> > and then use container_of() to get the net_device.
What 'struct device *' are you passing to container_of() here? The one
representing eth1? What call is this? And where are you trying to go
from there, to a peer? Why?
> > Similarly, the code needs to get from struct device *host_dev to a struct mii_bus *.
> >
> > | | | |-- f1072004.mdio
> > | | | | |-- deferred_probe
> > | | | | |-- driver -> ../../../../../bus/platform/drivers/orion-mdio
> > | | | | |-- driver_override
> > | | | | |-- mdio_bus
> > | | | | | `-- f1072004.mdio-mi
> > | | | | | |-- deferred_probe
> > | | | | | |-- device -> ../../../f1072004.mdio
Ok, this looks like the "peer" you want to get to from eth1, you want
f1072004.mdio-mi, right?
If so, why is eth1 not below f1072004.mdio-mi in the heirachy already?
Why is it up attached to the parent device, making this a "flat"
heirachy?
That's what is confusing about your functions, you are just walking all
of the "child" devices of a specific struct device, trying to find the
first random one that happens to belong to a specific 'bus' because you
are related to it.
Which is wrong, eth1 should be a child of your bus device, that way you
"know" how to get to it (it's your parent!).
So, I'm still confused, and still think this is all wrong, but feel free
to prove me wrong about this :)
thanks,
greg k-h
^ permalink raw reply
* [PATCH] ARM: dts: imx6q-utilite-pro: enable 2nd display pipeline
From: Philipp Zabel @ 2017-01-19 14:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <17a7f9cea35944288f97735e66859929@rwthex-s1-b.rwth-ad.de>
Hi Christopher,
On Wed, 2017-01-18 at 23:20 +0100, Christopher Spinrath wrote:
> Hi Philipp,
>
> turns out I have a question on your comment after all:
>
> On 01/17/2017 07:35 PM, Christopher Spinrath wrote:
> > Hi Philipp,
> >
> > thanks for the review!
> >
> > On 01/17/2017 09:57 AM, Philipp Zabel wrote:
> >> [...]
> >>> +
> >>> + parallel-display {
> >>> + compatible = "fsl,imx-parallel-display";
> >>> + #address-cells = <1>;
> >>> + #size-cells = <0>;
> >>> + pinctrl-names = "default";
> >>> + pinctrl-0 = <&pinctrl_ipu1>;
> >>> +
> >>> + interface-pix-fmt = "rgb24";
> >>
> >> This is not necessary if the connector created by the tpf410 has the
> >> correct media bus format set in its display_info structure. This can be
> >> done in tfp410_attach, before calling drm_mode_connector_attach_encoder:
> >>
> >> u32 bus_format = MEDIA_BUS_FMT_RGB888_1X24;
> >>
> >> drm_display_info_set_bus_formats(&dvi->connector.display_info,
> >> &bus_format, 1);
> >>
> >> After this is done, the above line should be removed in a follow-up
> >> patch.
>
> On closer inspection the tfp410 can handle rgb12, rgb24, and DVI
> formats. Considering this it feels wrong to hardcode the bus format to
> rgb24 (isn't it?).
That is a good point, I agree. I have some thoughts on this:
> So a solution might be to add a property specifying the bus format to
> the tfp410 binding. But then we would effectively just move this
> property from one node to another. I wonder if this is still desireable...?
If this is configurable on both ends, the necessary setting is neither a
hardware property of the bridge, nor of the display interface, but
rather one of the board specific wiring between the two (if at all).
Ideally all possible settings should be known to the drivers and the
best format should be negotiated. Note that display_info.bus_formats
already is an array of possible bus formats, even though the parallel
display driver currently only looks at the first element.
If there is no limitation imposed by the wiring, presenting best format
first in that array seems reasonable for now.
Otherwise I think the links should describe the parallel bus layout,
which is specified for the (input) media video interfaces:
Documentation/devicetree/bindings/media/video-interfaces.txt
Using the
bus-width = <24>;
or
bus-width = <12>;
property the tfp510 driver could choose which bus_formats to add to the
display_info.
regards
Philipp
^ permalink raw reply
* [PATCH 1/4] phy: sun4i-usb: support PHY0 on H3 in MUSB mode
From: Maxime Ripard @ 2017-01-19 14:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGb2v67kYtrTdw9YMS7wvRa=2MWYJ=BEc9SmUOds7hNYZKOz9g@mail.gmail.com>
On Wed, Jan 18, 2017 at 04:09:32AM +0800, Chen-Yu Tsai wrote:
> Hi,
>
> On Wed, Jan 18, 2017 at 4:06 AM, Maxime Ripard
> <maxime.ripard@free-electrons.com> wrote:
> > On Wed, Jan 18, 2017 at 12:57:08AM +0800, Icenowy Zheng wrote:
> >>
> >>
> >> 17.01.2017, 16:06, "Maxime Ripard" <maxime.ripard@free-electrons.com>:
> >> > On Tue, Jan 17, 2017 at 03:14:46AM +0800, Icenowy Zheng wrote:
> >> >> The PHY0 on H3 can be wired either to MUSB controller or OHCI/EHCI
> >> >> controller.
> >> >>
> >> >> The original driver wired it to OHCI/EHCI controller; however, as the
> >> >> code to use PHY0 as OHCI/EHCI is missing, it makes the PHY fully
> >> >> unusable.
> >> >>
> >> >> Rename the register (according to its function and the name in BSP
> >> >> driver), and remove the code which wires the PHY0 to OHCI/EHCI, as MUSB
> >> >> can support both peripheral and host mode (although the host mode of
> >> >> MUSB is buggy).
> >> >
> >> > Can you elaborate on that? What's wrong with it?
> >>
> >> The configuration is at bit 0 of register 0x20 in PHY.
> >>
> >> When the PHY is reseted, it defaults as MUSB mode.
> >>
> >> However, the original author of the H3 PHY code seems to be lack of
> >> this knowledge (He named it PHY_UNK_H3), and changed the PHY to HCI
> >> mode.
> >>
> >> I just removed the code that wires it to HCI mode, thus it will work
> >> in MUSB mode, with my sun8i-h3-musb patch.
> >
> > I have no idea what you mean by MUSB mode.
> >
> > Do you mean that the previous code was only working in host mode, and
> > now it only works in peripheral?
>
> From what I understand, with the H3, Allwinner has put a mux
> in front of the MUSB controller. The mux can send the USB data
> to/from the MUSB controller, or a standard EHCI/OHCI pair.
> This register controls said mux.
>
> This means we can use a proper USB host for host mode,
> instead of the limited support in MUSB.
But musb can still operate as a host, right?
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170119/1ebb8bc2/attachment.sig>
^ permalink raw reply
* [PATCH v2] ARM: dts: imx: Pass 'chosen' and 'memory' nodes
From: Fabio Estevam @ 2017-01-19 14:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170119141335.kpbrbpbwaovnijjv@pengutronix.de>
Hi Uwe,
On Thu, Jan 19, 2017 at 12:13 PM, Uwe Kleine-K?nig
<u.kleine-koenig@pengutronix.de> wrote:
> Would it be nice to add a comment about why this was added? Something to
> prevent a cleanup like "remove empty nodes and invalid memory
> configurations".
Do you mean something like this?
/* "chosen" and "memory" nodes are mandatory */
chosen {};
memory { device_type = "memory"; reg = <0 0>; };
^ 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