* [PATCH] pwm: omap-dmtimer: Fix frequency when using prescaler
From: Ladislav Michl @ 2017-12-18 11:38 UTC (permalink / raw)
To: linux-arm-kernel
Prescaler setting is currently not taken into account.
Fix that by introducing freq member variable and initialize
it at device probe time. This also avoids frequency
recomputing at each pwm configure time.
Signed-off-by: Ladislav Michl <ladis@linux-mips.org>
---
drivers/pwm/pwm-omap-dmtimer.c | 66 +++++++++++++++++++++++++-----------------
1 file changed, 39 insertions(+), 27 deletions(-)
diff --git a/drivers/pwm/pwm-omap-dmtimer.c b/drivers/pwm/pwm-omap-dmtimer.c
index 3b27aff585b7..0a23d1c1b153 100644
--- a/drivers/pwm/pwm-omap-dmtimer.c
+++ b/drivers/pwm/pwm-omap-dmtimer.c
@@ -40,6 +40,7 @@ struct pwm_omap_dmtimer_chip {
pwm_omap_dmtimer *dm_timer;
struct omap_dm_timer_ops *pdata;
struct platform_device *dm_timer_pdev;
+ unsigned long freq;
};
static inline struct pwm_omap_dmtimer_chip *
@@ -99,8 +100,6 @@ static int pwm_omap_dmtimer_config(struct pwm_chip *chip,
struct pwm_omap_dmtimer_chip *omap = to_pwm_omap_dmtimer_chip(chip);
u32 period_cycles, duty_cycles;
u32 load_value, match_value;
- struct clk *fclk;
- unsigned long clk_rate;
bool timer_active;
dev_dbg(chip->dev, "requested duty cycle: %d ns, period: %d ns\n",
@@ -114,19 +113,6 @@ static int pwm_omap_dmtimer_config(struct pwm_chip *chip,
return 0;
}
- fclk = omap->pdata->get_fclk(omap->dm_timer);
- if (!fclk) {
- dev_err(chip->dev, "invalid pmtimer fclk\n");
- goto err_einval;
- }
-
- clk_rate = clk_get_rate(fclk);
- if (!clk_rate) {
- dev_err(chip->dev, "invalid pmtimer fclk rate\n");
- goto err_einval;
- }
-
- dev_dbg(chip->dev, "clk rate: %luHz\n", clk_rate);
/*
* Calculate the appropriate load and match values based on the
@@ -144,35 +130,35 @@ static int pwm_omap_dmtimer_config(struct pwm_chip *chip,
* OMAP4430/60/70 TRM sections 22.2.4.10 and 22.2.4.11
* AM335x Sitara TRM sections 20.1.3.5 and 20.1.3.6
*/
- period_cycles = pwm_omap_dmtimer_get_clock_cycles(clk_rate, period_ns);
- duty_cycles = pwm_omap_dmtimer_get_clock_cycles(clk_rate, duty_ns);
+ period_cycles = pwm_omap_dmtimer_get_clock_cycles(omap->freq, period_ns);
+ duty_cycles = pwm_omap_dmtimer_get_clock_cycles(omap->freq, duty_ns);
if (period_cycles < 2) {
dev_info(chip->dev,
"period %d ns too short for clock rate %lu Hz\n",
- period_ns, clk_rate);
+ period_ns, omap->freq);
goto err_einval;
}
if (duty_cycles < 1) {
dev_dbg(chip->dev,
"duty cycle %d ns is too short for clock rate %lu Hz\n",
- duty_ns, clk_rate);
+ duty_ns, omap->freq);
dev_dbg(chip->dev, "using minimum of 1 clock cycle\n");
duty_cycles = 1;
} else if (duty_cycles >= period_cycles) {
dev_dbg(chip->dev,
"duty cycle %d ns is too long for period %d ns at clock rate %lu Hz\n",
- duty_ns, period_ns, clk_rate);
+ duty_ns, period_ns, omap->freq);
dev_dbg(chip->dev, "using maximum of 1 clock cycle less than period\n");
duty_cycles = period_cycles - 1;
}
dev_dbg(chip->dev, "effective duty cycle: %lld ns, period: %lld ns\n",
DIV_ROUND_CLOSEST_ULL((u64)NSEC_PER_SEC * duty_cycles,
- clk_rate),
+ omap->freq),
DIV_ROUND_CLOSEST_ULL((u64)NSEC_PER_SEC * period_cycles,
- clk_rate));
+ omap->freq));
load_value = (DM_TIMER_MAX - period_cycles) + 1;
match_value = load_value + duty_cycles - 1;
@@ -248,6 +234,7 @@ static int pwm_omap_dmtimer_probe(struct platform_device *pdev)
struct dmtimer_platform_data *timer_pdata;
struct omap_dm_timer_ops *pdata;
pwm_omap_dmtimer *dm_timer;
+ struct clk *fclk;
u32 v;
int status;
@@ -311,12 +298,37 @@ static int pwm_omap_dmtimer_probe(struct platform_device *pdev)
if (pm_runtime_active(&omap->dm_timer_pdev->dev))
omap->pdata->stop(omap->dm_timer);
- if (!of_property_read_u32(pdev->dev.of_node, "ti,prescaler", &v))
- omap->pdata->set_prescaler(omap->dm_timer, v);
-
/* setup dmtimer clock source */
- if (!of_property_read_u32(pdev->dev.of_node, "ti,clock-source", &v))
- omap->pdata->set_source(omap->dm_timer, v);
+ if (!of_property_read_u32(pdev->dev.of_node, "ti,clock-source", &v)) {
+ status = omap->pdata->set_source(omap->dm_timer, v);
+ if (status) {
+ dev_err(&pdev->dev, "invalid clock-source\n");
+ return status;
+ }
+ }
+
+ fclk = omap->pdata->get_fclk(omap->dm_timer);
+ if (!fclk) {
+ dev_err(&pdev->dev, "invalid fclk\n");
+ return -EINVAL;
+ }
+
+ omap->freq = clk_get_rate(fclk);
+ if (!omap->freq) {
+ dev_err(&pdev->dev, "invalid fclk rate\n");
+ return -EINVAL;
+ }
+
+ if (!of_property_read_u32(pdev->dev.of_node, "ti,prescaler", &v)) {
+ status = omap->pdata->set_prescaler(omap->dm_timer, v);
+ if (status) {
+ dev_err(&pdev->dev, "invalid prescaler\n");
+ return status;
+ }
+ omap->freq >>= v + 1;
+ }
+
+ dev_dbg(&pdev->dev, "clk rate: %luHz\n", omap->freq);
omap->chip.dev = &pdev->dev;
omap->chip.ops = &pwm_omap_dmtimer_ops;
--
2.15.1
^ permalink raw reply related
* [PATCH] ARM64: meson-axg: enable hardware rng
From: Jerome Brunet @ 2017-12-18 11:35 UTC (permalink / raw)
To: linux-arm-kernel
Enable the hardware random generator
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
---
Hi Kevin,
This patch depends on the changes adding the ethernet controller [0],
for including the axg clock binding header.
Cheers
Jerome
[0]: https://lkml.kernel.org/r/20171216035527.96952-2-yixun.lan at amlogic.com
arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
index dea1bc31b4de..c741fc16486f 100644
--- a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
@@ -212,6 +212,13 @@
#size-cells = <2>;
ranges = <0x0 0x0 0x0 0xff634000 0x0 0x2000>;
+ hwrng: rng {
+ compatible = "amlogic,meson-rng";
+ reg = <0x0 0x18 0x0 0x4>;
+ clocks = <&clkc CLKID_RNG0>;
+ clock-names = "core";
+ };
+
pinctrl_periphs: pinctrl at 480 {
compatible = "amlogic,meson-axg-periphs-pinctrl";
#address-cells = <2>;
--
2.14.3
^ permalink raw reply related
* [PATCH 2/2] clocksource: timer-dm: Check prescaler value
From: Ladislav Michl @ 2017-12-18 11:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171218111610.GA16906@lenoch>
Invalid prescaler value is silently ignored. Fix that
by returning -EINVAL in such case. As invalid value
disabled use of the prescaler, use -1 explicitely for
that purpose.
Signed-off-by: Ladislav Michl <ladis@linux-mips.org>
---
drivers/clocksource/timer-dm.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/clocksource/timer-dm.c b/drivers/clocksource/timer-dm.c
index ec3a28c90c70..95cd98be8541 100644
--- a/drivers/clocksource/timer-dm.c
+++ b/drivers/clocksource/timer-dm.c
@@ -609,6 +609,9 @@ static int omap_dm_timer_set_prescaler(struct omap_dm_timer *timer,
if (prescaler >= 0x00 && prescaler <= 0x07) {
l |= OMAP_TIMER_CTRL_PRE;
l |= prescaler << 2;
+ } else {
+ if (prescaler != -1)
+ return -EINVAL;
}
omap_dm_timer_write_reg(timer, OMAP_TIMER_CTRL_REG, l);
--
2.15.1
^ permalink raw reply related
* [PATCH 1/2] clocksource: timer-dm: Make unexported functions static
From: Ladislav Michl @ 2017-12-18 11:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171218111610.GA16906@lenoch>
As dmtimer no longer exports functions, there is no point
to have them non-static. Also delete those not used anywhere.
Signed-off-by: Ladislav Michl <ladis@linux-mips.org>
---
drivers/clocksource/timer-dm.c | 125 ++++++++---------------------------------
include/clocksource/dmtimer.h | 26 ---------
2 files changed, 23 insertions(+), 128 deletions(-)
diff --git a/drivers/clocksource/timer-dm.c b/drivers/clocksource/timer-dm.c
index 392978ccd8a6..ec3a28c90c70 100644
--- a/drivers/clocksource/timer-dm.c
+++ b/drivers/clocksource/timer-dm.c
@@ -204,16 +204,6 @@ static inline u32 omap_dm_timer_reserved_systimer(int id)
return (omap_reserved_systimers & (1 << (id - 1))) ? 1 : 0;
}
-int omap_dm_timer_reserve_systimer(int id)
-{
- if (omap_dm_timer_reserved_systimer(id))
- return -ENODEV;
-
- omap_reserved_systimers |= (1 << (id - 1));
-
- return 0;
-}
-
static struct omap_dm_timer *_omap_dm_timer_request(int req_type, void *data)
{
struct omap_dm_timer *timer = NULL, *t;
@@ -298,16 +288,16 @@ static struct omap_dm_timer *_omap_dm_timer_request(int req_type, void *data)
return timer;
}
-struct omap_dm_timer *omap_dm_timer_request(void)
+static struct omap_dm_timer *omap_dm_timer_request(void)
{
return _omap_dm_timer_request(REQUEST_ANY, NULL);
}
-struct omap_dm_timer *omap_dm_timer_request_specific(int id)
+static struct omap_dm_timer *omap_dm_timer_request_specific(int id)
{
/* Requesting timer by ID is not supported when device tree is used */
if (of_have_populated_dt()) {
- pr_warn("%s: Please use omap_dm_timer_request_by_cap/node()\n",
+ pr_warn("%s: Please use omap_dm_timer_request_by_node()\n",
__func__);
return NULL;
}
@@ -315,20 +305,6 @@ struct omap_dm_timer *omap_dm_timer_request_specific(int id)
return _omap_dm_timer_request(REQUEST_BY_ID, &id);
}
-/**
- * omap_dm_timer_request_by_cap - Request a timer by capability
- * @cap: Bit mask of capabilities to match
- *
- * Find a timer based upon capabilities bit mask. Callers of this function
- * should use the definitions found in the plat/dmtimer.h file under the
- * comment "timer capabilities used in hwmod database". Returns pointer to
- * timer handle on success and a NULL pointer on failure.
- */
-struct omap_dm_timer *omap_dm_timer_request_by_cap(u32 cap)
-{
- return _omap_dm_timer_request(REQUEST_BY_CAP, &cap);
-}
-
/**
* omap_dm_timer_request_by_node - Request a timer by device-tree node
* @np: Pointer to device-tree timer node
@@ -336,7 +312,7 @@ struct omap_dm_timer *omap_dm_timer_request_by_cap(u32 cap)
* Request a timer based upon a device node pointer. Returns pointer to
* timer handle on success and a NULL pointer on failure.
*/
-struct omap_dm_timer *omap_dm_timer_request_by_node(struct device_node *np)
+static struct omap_dm_timer *omap_dm_timer_request_by_node(struct device_node *np)
{
if (!np)
return NULL;
@@ -344,7 +320,7 @@ struct omap_dm_timer *omap_dm_timer_request_by_node(struct device_node *np)
return _omap_dm_timer_request(REQUEST_BY_NODE, np);
}
-int omap_dm_timer_free(struct omap_dm_timer *timer)
+static int omap_dm_timer_free(struct omap_dm_timer *timer)
{
if (unlikely(!timer))
return -EINVAL;
@@ -424,7 +400,7 @@ __u32 omap_dm_timer_modify_idlect_mask(__u32 inputmask)
#else
-struct clk *omap_dm_timer_get_fclk(struct omap_dm_timer *timer)
+static struct clk *omap_dm_timer_get_fclk(struct omap_dm_timer *timer)
{
if (timer && !IS_ERR(timer->fclk))
return timer->fclk;
@@ -440,18 +416,7 @@ __u32 omap_dm_timer_modify_idlect_mask(__u32 inputmask)
#endif
-int omap_dm_timer_trigger(struct omap_dm_timer *timer)
-{
- if (unlikely(!timer || pm_runtime_suspended(&timer->pdev->dev))) {
- pr_err("%s: timer not available or enabled.\n", __func__);
- return -EINVAL;
- }
-
- omap_dm_timer_write_reg(timer, OMAP_TIMER_TRIGGER_REG, 0);
- return 0;
-}
-
-int omap_dm_timer_start(struct omap_dm_timer *timer)
+static int omap_dm_timer_start(struct omap_dm_timer *timer)
{
u32 l;
@@ -471,7 +436,7 @@ int omap_dm_timer_start(struct omap_dm_timer *timer)
return 0;
}
-int omap_dm_timer_stop(struct omap_dm_timer *timer)
+static int omap_dm_timer_stop(struct omap_dm_timer *timer)
{
unsigned long rate = 0;
@@ -556,8 +521,8 @@ int omap_dm_timer_set_source(struct omap_dm_timer *timer, int source)
return ret;
}
-int omap_dm_timer_set_load(struct omap_dm_timer *timer, int autoreload,
- unsigned int load)
+static int omap_dm_timer_set_load(struct omap_dm_timer *timer, int autoreload,
+ unsigned int load)
{
u32 l;
@@ -581,37 +546,8 @@ int omap_dm_timer_set_load(struct omap_dm_timer *timer, int autoreload,
return 0;
}
-/* Optimized set_load which removes costly spin wait in timer_start */
-int omap_dm_timer_set_load_start(struct omap_dm_timer *timer, int autoreload,
- unsigned int load)
-{
- u32 l;
-
- if (unlikely(!timer))
- return -EINVAL;
-
- omap_dm_timer_enable(timer);
-
- l = omap_dm_timer_read_reg(timer, OMAP_TIMER_CTRL_REG);
- if (autoreload) {
- l |= OMAP_TIMER_CTRL_AR;
- omap_dm_timer_write_reg(timer, OMAP_TIMER_LOAD_REG, load);
- } else {
- l &= ~OMAP_TIMER_CTRL_AR;
- }
- l |= OMAP_TIMER_CTRL_ST;
-
- __omap_dm_timer_load_start(timer, l, load, timer->posted);
-
- /* Save the context */
- timer->context.tclr = l;
- timer->context.tldr = load;
- timer->context.tcrr = load;
- return 0;
-}
-
-int omap_dm_timer_set_match(struct omap_dm_timer *timer, int enable,
- unsigned int match)
+static int omap_dm_timer_set_match(struct omap_dm_timer *timer, int enable,
+ unsigned int match)
{
u32 l;
@@ -634,8 +570,8 @@ int omap_dm_timer_set_match(struct omap_dm_timer *timer, int enable,
return 0;
}
-int omap_dm_timer_set_pwm(struct omap_dm_timer *timer, int def_on,
- int toggle, int trigger)
+static int omap_dm_timer_set_pwm(struct omap_dm_timer *timer, int def_on,
+ int toggle, int trigger)
{
u32 l;
@@ -659,7 +595,8 @@ int omap_dm_timer_set_pwm(struct omap_dm_timer *timer, int def_on,
return 0;
}
-int omap_dm_timer_set_prescaler(struct omap_dm_timer *timer, int prescaler)
+static int omap_dm_timer_set_prescaler(struct omap_dm_timer *timer,
+ int prescaler)
{
u32 l;
@@ -681,8 +618,8 @@ int omap_dm_timer_set_prescaler(struct omap_dm_timer *timer, int prescaler)
return 0;
}
-int omap_dm_timer_set_int_enable(struct omap_dm_timer *timer,
- unsigned int value)
+static int omap_dm_timer_set_int_enable(struct omap_dm_timer *timer,
+ unsigned int value)
{
if (unlikely(!timer))
return -EINVAL;
@@ -704,7 +641,7 @@ int omap_dm_timer_set_int_enable(struct omap_dm_timer *timer,
*
* Disables the specified timer interrupts for a timer.
*/
-int omap_dm_timer_set_int_disable(struct omap_dm_timer *timer, u32 mask)
+static int omap_dm_timer_set_int_disable(struct omap_dm_timer *timer, u32 mask)
{
u32 l = mask;
@@ -727,7 +664,7 @@ int omap_dm_timer_set_int_disable(struct omap_dm_timer *timer, u32 mask)
return 0;
}
-unsigned int omap_dm_timer_read_status(struct omap_dm_timer *timer)
+static unsigned int omap_dm_timer_read_status(struct omap_dm_timer *timer)
{
unsigned int l;
@@ -741,7 +678,7 @@ unsigned int omap_dm_timer_read_status(struct omap_dm_timer *timer)
return l;
}
-int omap_dm_timer_write_status(struct omap_dm_timer *timer, unsigned int value)
+static int omap_dm_timer_write_status(struct omap_dm_timer *timer, unsigned int value)
{
if (unlikely(!timer || pm_runtime_suspended(&timer->pdev->dev)))
return -EINVAL;
@@ -751,7 +688,7 @@ int omap_dm_timer_write_status(struct omap_dm_timer *timer, unsigned int value)
return 0;
}
-unsigned int omap_dm_timer_read_counter(struct omap_dm_timer *timer)
+static unsigned int omap_dm_timer_read_counter(struct omap_dm_timer *timer)
{
if (unlikely(!timer || pm_runtime_suspended(&timer->pdev->dev))) {
pr_err("%s: timer not iavailable or enabled.\n", __func__);
@@ -761,7 +698,7 @@ unsigned int omap_dm_timer_read_counter(struct omap_dm_timer *timer)
return __omap_dm_timer_read_counter(timer, timer->posted);
}
-int omap_dm_timer_write_counter(struct omap_dm_timer *timer, unsigned int value)
+static int omap_dm_timer_write_counter(struct omap_dm_timer *timer, unsigned int value)
{
if (unlikely(!timer || pm_runtime_suspended(&timer->pdev->dev))) {
pr_err("%s: timer not available or enabled.\n", __func__);
@@ -775,22 +712,6 @@ int omap_dm_timer_write_counter(struct omap_dm_timer *timer, unsigned int value)
return 0;
}
-int omap_dm_timers_active(void)
-{
- struct omap_dm_timer *timer;
-
- list_for_each_entry(timer, &omap_timer_list, node) {
- if (!timer->reserved)
- continue;
-
- if (omap_dm_timer_read_reg(timer, OMAP_TIMER_CTRL_REG) &
- OMAP_TIMER_CTRL_ST) {
- return 1;
- }
- }
- return 0;
-}
-
static const struct of_device_id omap_timer_match[];
/**
diff --git a/include/clocksource/dmtimer.h b/include/clocksource/dmtimer.h
index 862ad62dab9d..63d6ec0747d9 100644
--- a/include/clocksource/dmtimer.h
+++ b/include/clocksource/dmtimer.h
@@ -124,40 +124,14 @@ struct omap_dm_timer {
struct list_head node;
};
-int omap_dm_timer_reserve_systimer(int id);
-struct omap_dm_timer *omap_dm_timer_request(void);
-struct omap_dm_timer *omap_dm_timer_request_specific(int timer_id);
-struct omap_dm_timer *omap_dm_timer_request_by_cap(u32 cap);
-struct omap_dm_timer *omap_dm_timer_request_by_node(struct device_node *np);
-int omap_dm_timer_free(struct omap_dm_timer *timer);
void omap_dm_timer_enable(struct omap_dm_timer *timer);
void omap_dm_timer_disable(struct omap_dm_timer *timer);
int omap_dm_timer_get_irq(struct omap_dm_timer *timer);
u32 omap_dm_timer_modify_idlect_mask(u32 inputmask);
-struct clk *omap_dm_timer_get_fclk(struct omap_dm_timer *timer);
-
-int omap_dm_timer_trigger(struct omap_dm_timer *timer);
-int omap_dm_timer_start(struct omap_dm_timer *timer);
-int omap_dm_timer_stop(struct omap_dm_timer *timer);
int omap_dm_timer_set_source(struct omap_dm_timer *timer, int source);
-int omap_dm_timer_set_load(struct omap_dm_timer *timer, int autoreload, unsigned int value);
-int omap_dm_timer_set_load_start(struct omap_dm_timer *timer, int autoreload, unsigned int value);
-int omap_dm_timer_set_match(struct omap_dm_timer *timer, int enable, unsigned int match);
-int omap_dm_timer_set_pwm(struct omap_dm_timer *timer, int def_on, int toggle, int trigger);
-int omap_dm_timer_set_prescaler(struct omap_dm_timer *timer, int prescaler);
-
-int omap_dm_timer_set_int_enable(struct omap_dm_timer *timer, unsigned int value);
-int omap_dm_timer_set_int_disable(struct omap_dm_timer *timer, u32 mask);
-
-unsigned int omap_dm_timer_read_status(struct omap_dm_timer *timer);
-int omap_dm_timer_write_status(struct omap_dm_timer *timer, unsigned int value);
-unsigned int omap_dm_timer_read_counter(struct omap_dm_timer *timer);
-int omap_dm_timer_write_counter(struct omap_dm_timer *timer, unsigned int value);
-
-int omap_dm_timers_active(void);
/*
* Do not use the defines below, they are not needed. They should be only
--
2.15.1
^ permalink raw reply related
* [PATCH] drm/rockchip: analogix_dp: Ensure that the bridge is powered before poking it
From: Marc Zyngier @ 2017-12-18 11:28 UTC (permalink / raw)
To: linux-arm-kernel
Stopping the X display manager on a kevin platform results in the
following crash:
[ 674.833536] Synchronous External Abort: synchronous external abort (0x96000010) at 0xffff00000c970640
[ 674.843886] Internal error: : 96000010 [#1] PREEMPT SMP
[ 674.849744] Modules linked in:
[ 674.849755] CPU: 1 PID: 86 Comm: kworker/1:1 Not tainted 4.15.0-rc3-00057-gff24f8cf492d-dirty #3
[ 674.849760] detected fb_set_par error, error code: -16
[ 674.849761] Hardware name: Google Kevin (DT)
[ 674.849773] Workqueue: events analogix_dp_psr_work
[ 674.849778] pstate: 60000005 (nZCv daif -PAN -UAO)
[ 674.849784] pc : analogix_dp_send_psr_spd+0x8/0x168
[ 674.849788] lr : analogix_dp_enable_psr+0x54/0x60
[ 674.849789] sp : ffff000009b2bd60
[ 674.849790] x29: ffff000009b2bd60 x28: 0000000000000000
[ 674.849794] x27: ffff000009913d20 x26: ffff00000900fbf0
[ 674.849797] x25: ffff8000f1b30000 x24: ffff8000f0c21d98
[ 674.849800] x23: 0000000000000000 x22: ffff8000f7d3aa00
[ 674.849803] x21: ffff8000f7d36980 x20: ffff8000f0c21c18
[ 674.849806] x19: ffff8000f0c21db8 x18: 0000000000000001
[ 674.849809] x17: 0000ffff89f2ed58 x16: ffff000008222908
[ 674.849812] x15: 0000000000000000 x14: 0000000000000400
[ 674.849815] x13: 0000000000000400 x12: 0000000000000000
[ 674.849817] x11: 0000000000001414 x10: 0000000000000a00
[ 674.849820] x9 : ffff000009b2bbb0 x8 : ffff8000f1b30a60
[ 674.849823] x7 : 0000000000080000 x6 : 0000000000000001
[ 674.849826] x5 : 0000000000000010 x4 : 0000000000000007
[ 674.849829] x3 : 0000000000000002 x2 : ffff00000c970640
[ 674.849832] x1 : ffff000009b2bd78 x0 : ffff8000f1624018
[ 674.849836] Process kworker/1:1 (pid: 86, stack limit = 0x0000000083e5f7c3)
[ 674.849838] Call trace:
[ 674.849842] analogix_dp_send_psr_spd+0x8/0x168
[ 674.849844] analogix_dp_psr_work+0x9c/0xa0
[ 674.849849] process_one_work+0x1cc/0x328
[ 674.849852] worker_thread+0x50/0x450
[ 674.849856] kthread+0xf8/0x128
[ 674.849860] ret_from_fork+0x10/0x18
[ 674.849864] Code: b9000001 d65f03c0 f9445802 91190042 (b9400042)
Further investigation show that this happens because the the workqueue
races with the analogix_dp_bridge_disable() call from the core DRM code,
and end up trying to write to the DP bridge that has already been powered
down. This result is a very black screen, and a hard reset.
Instead of counting on luck to keep the bridge alive, let's use the
pm_runtime framework and take a reference on the device when we're about
to poke it. That is a fairly big hammer, but one that allows the system
to stay alive across dozens of X start/stop sequences.
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
---
drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
index 08743ad96cb9..7f2c190f75e7 100644
--- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
+++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
@@ -14,6 +14,7 @@
#include <linux/component.h>
#include <linux/mfd/syscon.h>
+#include <linux/pm_runtime.h>
#include <linux/of_device.h>
#include <linux/of_graph.h>
#include <linux/regmap.h>
@@ -113,10 +114,12 @@ static void analogix_dp_psr_work(struct work_struct *work)
}
mutex_lock(&dp->psr_lock);
+ pm_runtime_get_sync(dp->dev);
if (dp->psr_state == EDP_VSC_PSR_STATE_ACTIVE)
analogix_dp_enable_psr(dp->dev);
else
analogix_dp_disable_psr(dp->dev);
+ pm_runtime_put_sync(dp->dev);
mutex_unlock(&dp->psr_lock);
}
--
2.14.2
^ permalink raw reply related
* arm64 crashkernel fails to boot on acpi-only machines due to ACPI regions being no longer mapped as NOMAP
From: AKASHI Takahiro @ 2017-12-18 11:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAFTCetQ55zUKe25jSku0DHp8uVZA4hB32d5W6MSCNsTVpxu7Gw@mail.gmail.com>
Bhupesh,
On Mon, Dec 18, 2017 at 02:29:05PM +0530, Bhupesh SHARMA wrote:
> On Mon, Dec 18, 2017 at 11:24 AM, AKASHI Takahiro
> <takahiro.akashi@linaro.org> wrote:
> > On Mon, Dec 18, 2017 at 01:16:57PM +0800, Dave Young wrote:
> >> kexec at fedoraproject... is for Fedora kexec scripts discussion, changed it
> >> to kexec at lists.infradead.org
> >>
> >> Also add linux-acpi list
> >
> > Thank you.
> >
> >> On 12/18/17 at 02:31am, Bhupesh Sharma wrote:
> >> > On Fri, Dec 15, 2017 at 3:05 PM, Ard Biesheuvel
> >> > <ard.biesheuvel@linaro.org> wrote:
> >> > > On 15 December 2017 at 09:59, AKASHI Takahiro
> >> > > <takahiro.akashi@linaro.org> wrote:
> >> > >> On Wed, Dec 13, 2017 at 12:17:22PM +0000, Ard Biesheuvel wrote:
> >> > >>> On 13 December 2017 at 12:16, AKASHI Takahiro
> >> > >>> <takahiro.akashi@linaro.org> wrote:
> >> > >>> > On Wed, Dec 13, 2017 at 10:49:27AM +0000, Ard Biesheuvel wrote:
> >> > >>> >> On 13 December 2017 at 10:26, AKASHI Takahiro
> >> > >>> >> <takahiro.akashi@linaro.org> wrote:
> >> > >>> >> > Bhupesh, Ard,
> >> > >>> >> >
> >> > >>> >> > On Wed, Dec 13, 2017 at 03:21:59AM +0530, Bhupesh Sharma wrote:
> >> > >>> >> >> Hi Ard, Akashi
> >> > >>> >> >>
> >> > >>> >> > (snip)
> >> > >>> >> >
> >> > >>> >> >> Looking deeper into the issue, since the arm64 kexec-tools uses the
> >> > >>> >> >> 'linux,usable-memory-range' dt property to allow crash dump kernel to
> >> > >>> >> >> identify its own usable memory and exclude, at its boot time, any
> >> > >>> >> >> other memory areas that are part of the panicked kernel's memory.
> >> > >>> >> >> (see https://www.kernel.org/doc/Documentation/devicetree/bindings/chosen.txt
> >> > >>> >> >> , for details)
> >> > >>> >> >
> >> > >>> >> > Right.
> >> > >>> >> >
> >> > >>> >> >> 1). Now when 'kexec -p' is executed, this node is patched up only
> >> > >>> >> >> with the crashkernel memory range:
> >> > >>> >> >>
> >> > >>> >> >> /* add linux,usable-memory-range */
> >> > >>> >> >> nodeoffset = fdt_path_offset(new_buf, "/chosen");
> >> > >>> >> >> result = fdt_setprop_range(new_buf, nodeoffset,
> >> > >>> >> >> PROP_USABLE_MEM_RANGE, &crash_reserved_mem,
> >> > >>> >> >> address_cells, size_cells);
> >> > >>> >> >>
> >> > >>> >> >> (see https://git.kernel.org/pub/scm/utils/kernel/kexec/kexec-tools.git/tree/kexec/arch/arm64/kexec-arm64.c#n465
> >> > >>> >> >> , for details)
> >> > >>> >> >>
> >> > >>> >> >> 2). This excludes the ACPI reclaim regions irrespective of whether
> >> > >>> >> >> they are marked as System RAM or as RESERVED. As,
> >> > >>> >> >> 'linux,usable-memory-range' dt node is patched up only with
> >> > >>> >> >> 'crash_reserved_mem' and not 'system_memory_ranges'
> >> > >>> >> >>
> >> > >>> >> >> 3). As a result when the crashkernel boots up it doesn't find this
> >> > >>> >> >> ACPI memory and crashes while trying to access the same:
> >> > >>> >> >>
> >> > >>> >> >> # kexec -p /boot/vmlinuz-`uname -r` --initrd=/boot/initramfs-`uname
> >> > >>> >> >> -r`.img --reuse-cmdline -d
> >> > >>> >> >>
> >> > >>> >> >> [snip..]
> >> > >>> >> >>
> >> > >>> >> >> Reserved memory range
> >> > >>> >> >> 000000000e800000-000000002e7fffff (0)
> >> > >>> >> >>
> >> > >>> >> >> Coredump memory ranges
> >> > >>> >> >> 0000000000000000-000000000e7fffff (0)
> >> > >>> >> >> 000000002e800000-000000003961ffff (0)
> >> > >>> >> >> 0000000039d40000-000000003ed2ffff (0)
> >> > >>> >> >> 000000003ed60000-000000003fbfffff (0)
> >> > >>> >> >> 0000001040000000-0000001ffbffffff (0)
> >> > >>> >> >> 0000002000000000-0000002ffbffffff (0)
> >> > >>> >> >> 0000009000000000-0000009ffbffffff (0)
> >> > >>> >> >> 000000a000000000-000000affbffffff (0)
> >> > >>> >> >>
> >> > >>> >> >> 4). So if we revert Ard's patch or just comment the fixing up of the
> >> > >>> >> >> memory cap'ing passed to the crash kernel inside
> >> > >>> >> >> 'arch/arm64/mm/init.c' (see below):
> >> > >>> >> >>
> >> > >>> >> >> static void __init fdt_enforce_memory_region(void)
> >> > >>> >> >> {
> >> > >>> >> >> struct memblock_region reg = {
> >> > >>> >> >> .size = 0,
> >> > >>> >> >> };
> >> > >>> >> >>
> >> > >>> >> >> of_scan_flat_dt(early_init_dt_scan_usablemem, ®);
> >> > >>> >> >>
> >> > >>> >> >> if (reg.size)
> >> > >>> >> >> //memblock_cap_memory_range(reg.base, reg.size); /*
> >> > >>> >> >> comment this out */
> >> > >>> >> >> }
> >> > >>> >> >
> >> > >>> >> > Please just don't do that. It can cause a fatal damage on
> >> > >>> >> > memory contents of the *crashed* kernel.
> >> > >>> >> >
> >> > >>> >> >> 5). Both the above temporary solutions fix the problem.
> >> > >>> >> >>
> >> > >>> >> >> 6). However exposing all System RAM regions to the crashkernel is not
> >> > >>> >> >> advisable and may cause the crashkernel or some crashkernel drivers to
> >> > >>> >> >> fail.
> >> > >>> >> >>
> >> > >>> >> >> 6a). I am trying an approach now, where the ACPI reclaim regions are
> >> > >>> >> >> added to '/proc/iomem' separately as ACPI reclaim regions by the
> >> > >>> >> >> kernel code and on the other hand the user-space 'kexec-tools' will
> >> > >>> >> >> pick up the ACPI reclaim regions from '/proc/iomem' and add it to the
> >> > >>> >> >> dt node 'linux,usable-memory-range'
> >> > >>> >> >
> >> > >>> >> > I still don't understand why we need to carry over the information
> >> > >>> >> > about "ACPI Reclaim memory" to crash dump kernel. In my understandings,
> >> > >>> >> > such regions are free to be reused by the kernel after some point of
> >> > >>> >> > initialization. Why does crash dump kernel need to know about them?
> >> > >>> >> >
> >> > >>> >>
> >> > >>> >> Not really. According to the UEFI spec, they can be reclaimed after
> >> > >>> >> the OS has initialized, i.e., when it has consumed the ACPI tables and
> >> > >>> >> no longer needs them. Of course, in order to be able to boot a kexec
> >> > >>> >> kernel, those regions needs to be preserved, which is why they are
> >> > >>> >> memblock_reserve()'d now.
> >> > >>> >
> >> > >>> > For my better understandings, who is actually accessing such regions
> >> > >>> > during boot time, uefi itself or efistub?
> >> > >>> >
> >> > >>>
> >> > >>> No, only the kernel. This is where the ACPI tables are stored. For
> >> > >>> instance, on QEMU we have
> >> > >>>
> >> > >>> ACPI: RSDP 0x0000000078980000 000024 (v02 BOCHS )
> >> > >>> ACPI: XSDT 0x0000000078970000 000054 (v01 BOCHS BXPCFACP 00000001
> >> > >>> 01000013)
> >> > >>> ACPI: FACP 0x0000000078930000 00010C (v05 BOCHS BXPCFACP 00000001
> >> > >>> BXPC 00000001)
> >> > >>> ACPI: DSDT 0x0000000078940000 0011DA (v02 BOCHS BXPCDSDT 00000001
> >> > >>> BXPC 00000001)
> >> > >>> ACPI: APIC 0x0000000078920000 000140 (v03 BOCHS BXPCAPIC 00000001
> >> > >>> BXPC 00000001)
> >> > >>> ACPI: GTDT 0x0000000078910000 000060 (v02 BOCHS BXPCGTDT 00000001
> >> > >>> BXPC 00000001)
> >> > >>> ACPI: MCFG 0x0000000078900000 00003C (v01 BOCHS BXPCMCFG 00000001
> >> > >>> BXPC 00000001)
> >> > >>> ACPI: SPCR 0x00000000788F0000 000050 (v02 BOCHS BXPCSPCR 00000001
> >> > >>> BXPC 00000001)
> >> > >>> ACPI: IORT 0x00000000788E0000 00007C (v00 BOCHS BXPCIORT 00000001
> >> > >>> BXPC 00000001)
> >> > >>>
> >> > >>> covered by
> >> > >>>
> >> > >>> efi: 0x0000788e0000-0x00007894ffff [ACPI Reclaim Memory ...]
> >> > >>> ...
> >> > >>> efi: 0x000078970000-0x00007898ffff [ACPI Reclaim Memory ...]
> >> > >>
> >> > >> OK. I mistakenly understood those regions could be freed after exiting
> >> > >> UEFI boot services.
> >> > >>
> >> > >>>
> >> > >>> >> So it seems that kexec does not honour the memblock_reserve() table
> >> > >>> >> when booting the next kernel.
> >> > >>> >
> >> > >>> > not really.
> >> > >>> >
> >> > >>> >> > (In other words, can or should we skip some part of ACPI-related init code
> >> > >>> >> > on crash dump kernel?)
> >> > >>> >> >
> >> > >>> >>
> >> > >>> >> I don't think so. And the change to the handling of ACPI reclaim
> >> > >>> >> regions only revealed the bug, not created it (given that other
> >> > >>> >> memblock_reserve regions may be affected as well)
> >> > >>> >
> >> > >>> > As whether we should honor such reserved regions over kexec'ing
> >> > >>> > depends on each one's specific nature, we will have to take care one-by-one.
> >> > >>> > As a matter of fact, no information about "reserved" memblocks is
> >> > >>> > exposed to user space (via proc/iomem).
> >> > >>> >
> >> > >>>
> >> > >>> That is why I suggested (somewhere in this thread?) to not expose them
> >> > >>> as 'System RAM'. Do you think that could solve this?
> >> > >>
> >> > >> Memblock-reserv'ing them is necessary to prevent their corruption and
> >> > >> marking them under another name in /proc/iomem would also be good in order
> >> > >> not to allocate them as part of crash kernel's memory.
> >> > >>
> >> > >
> >> > > I agree. However, this may not be entirely trivial, since iterating
> >> > > over the memblock_reserved table and creating iomem entries may result
> >> > > in collisions.
> >> >
> >> > I found a method (using the patch I shared earlier in this thread) to mark these
> >> > entries as 'ACPI reclaim memory' ranges rather than System RAM or
> >> > reserved regions.
> >> >
> >> > >> But I'm not still convinced that we should export them in useable-
> >> > >> memory-range to crash dump kernel. They will be accessed through
> >> > >> acpi_os_map_memory() and so won't be required to be part of system ram
> >> > >> (or memblocks), I guess.
> >> > >
> >> > > Agreed. They will be covered by the linear mapping in the boot kernel,
> >> > > and be mapped explicitly via ioremap_cache() in the kexec kernel,
> >> > > which is exactly what we want in this case.
> >> >
> >> > Now this is what is confusing me. I don't see the above happening.
> >> >
> >> > I see that the primary kernel boots up and adds the ACPI regions via:
> >> > acpi_os_ioremap
> >> > -> ioremap_cache
> >> >
> >> > But during the crashkernel boot, ''acpi_os_ioremap' calls
> >> > 'ioremap' for the ACPI Reclaim Memory regions and not the _cache
> >> > variant.
> >
> > It is natural if that region is out of memblocks.
>
> Thanks for the confirmation. This was my understanding as well.
>
> >> > And it fails while accessing the ACPI tables:
> >> >
> >> > [ 0.039205] ACPI: Core revision 20170728
> >> > pud=000000002e7d0003, *pmd=000000002e7c0003, *pte=00e8000039710707
> >> > [ 0.095098] Internal error: Oops: 96000021 [#1] SMP
> >
> > this (ESR = 0x96000021) means that Data Abort and Alignment fault happened.
> > As ioremap() makes the mapping as "Device memory", unaligned memory
> > access won't be allowed.
> >
> >> > [ 0.100022] Modules linked in:
> >> > [ 0.103102] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.14.0-rc6 #1
> >> > [ 0.109432] task: ffff000008d05180 task.stack: ffff000008cc0000
> >> > [ 0.115414] PC is at acpi_ns_lookup+0x25c/0x3c0
> >> > [ 0.119987] LR is at acpi_ds_load1_begin_op+0xa4/0x294
> >> > [ 0.125175] pc : [<ffff0000084a6764>] lr : [<ffff00000849b4f8>]
> >> > pstate: 60000045
> >> > [ 0.132647] sp : ffff000008ccfb40
> >> > [ 0.135989] x29: ffff000008ccfb40 x28: ffff000008a9f2a4
> >> > [ 0.141354] x27: ffff0000088be820 x26: 0000000000000000
> >> > [ 0.146718] x25: 000000000000001b x24: 0000000000000001
> >> > [ 0.152083] x23: 0000000000000001 x22: ffff000009710027
> >> > [ 0.157447] x21: ffff000008ccfc50 x20: 0000000000000001
> >> > [ 0.162812] x19: 000000000000001b x18: 0000000000000005
> >> > [ 0.168176] x17: 0000000000000000 x16: 0000000000000000
> >> > [ 0.173541] x15: 0000000000000000 x14: 000000000000038e
> >> > [ 0.178905] x13: ffffffff00000000 x12: ffffffffffffffff
> >> > [ 0.184270] x11: 0000000000000006 x10: 00000000ffffff76
> >> > [ 0.189634] x9 : 000000000000005f x8 : ffff8000126d0140
> >> > [ 0.194998] x7 : 0000000000000000 x6 : ffff000008ccfc50
> >> > [ 0.200362] x5 : ffff80000fe62c00 x4 : 0000000000000001
> >> > [ 0.205727] x3 : ffff000008ccfbe0 x2 : ffff0000095e3980
> >> > [ 0.211091] x1 : ffff000009710027 x0 : 0000000000000000
> >> > [ 0.216456] Process swapper/0 (pid: 0, stack limit = 0xffff000008cc0000)
> >> > [ 0.223224] Call trace:
> >> > [ 0.225688] Exception stack(0xffff000008ccfa00 to 0xffff000008ccfb40)
> >> > [ 0.232194] fa00: 0000000000000000 ffff000009710027
> >> > ffff0000095e3980 ffff000008ccfbe0
> >> > [ 0.240106] fa20: 0000000000000001 ffff80000fe62c00
> >> > ffff000008ccfc50 0000000000000000
> >> > [ 0.248018] fa40: ffff8000126d0140 000000000000005f
> >> > 00000000ffffff76 0000000000000006
> >> > [ 0.255931] fa60: ffffffffffffffff ffffffff00000000
> >> > 000000000000038e 0000000000000000
> >> > [ 0.263843] fa80: 0000000000000000 0000000000000000
> >> > 0000000000000005 000000000000001b
> >> > [ 0.271754] faa0: 0000000000000001 ffff000008ccfc50
> >> > ffff000009710027 0000000000000001
> >> > [ 0.279667] fac0: 0000000000000001 000000000000001b
> >> > 0000000000000000 ffff0000088be820
> >> > [ 0.287579] fae0: ffff000008a9f2a4 ffff000008ccfb40
> >> > ffff00000849b4f8 ffff000008ccfb40
> >> > [ 0.295491] fb00: ffff0000084a6764 0000000060000045
> >> > ffff000008ccfb40 ffff000008260a18
> >> > [ 0.303403] fb20: ffffffffffffffff ffff0000087f3fb0
> >> > ffff000008ccfb40 ffff0000084a6764
> >> > [ 0.311316] [<ffff0000084a6764>] acpi_ns_lookup+0x25c/0x3c0
> >> > [ 0.316943] [<ffff00000849b4f8>] acpi_ds_load1_begin_op+0xa4/0x294
> >> > [ 0.323186] [<ffff0000084ad4ac>] acpi_ps_build_named_op+0xc4/0x198
> >> > [ 0.329428] [<ffff0000084ad6cc>] acpi_ps_create_op+0x14c/0x270
> >> > [ 0.335319] [<ffff0000084acfa8>] acpi_ps_parse_loop+0x188/0x5c8
> >> > [ 0.341298] [<ffff0000084ae048>] acpi_ps_parse_aml+0xb0/0x2b8
> >> > [ 0.347101] [<ffff0000084a8e10>] acpi_ns_one_complete_parse+0x144/0x184
> >> > [ 0.353783] [<ffff0000084a8e98>] acpi_ns_parse_table+0x48/0x68
> >> > [ 0.359675] [<ffff0000084a82cc>] acpi_ns_load_table+0x4c/0xdc
> >> > [ 0.365479] [<ffff0000084b32f8>] acpi_tb_load_namespace+0xe4/0x264
> >> > [ 0.371723] [<ffff000008baf9b4>] acpi_load_tables+0x48/0xc0
> >> > [ 0.377350] [<ffff000008badc20>] acpi_early_init+0x9c/0xd0
> >> > [ 0.382891] [<ffff000008b70d50>] start_kernel+0x3b4/0x43c
> >> > [ 0.388343] Code: b9008fb9 2a000318 36380054 32190318 (b94002c0)
> >> > [ 0.394500] ---[ end trace c46ed37f9651c58e ]---
> >> > [ 0.399160] Kernel panic - not syncing: Fatal exception
> >> > [ 0.404437] Rebooting in 10 seconds.
> >> >
> >> > So, I think the linear mapping done by the primary kernel does not
> >> > make these accessible in the crash kernel directly.
> >> >
> >> > Any pointers?
> >>
> >> Can you get the code line number for acpi_ns_lookup+0x25c?
> >
> > So should we always avoid ioremap() in acpi_os_ioremap() entirely, or
> > modify acpi_ns_lookup() (or any acpi functions') to prevent unaligned
> > accesses?
> > (I didn't find out how unaligned accesses could happen there.)
> >
>
> Right. Like I captured somewhere in this thread (perhaps the first
> email on this subject),
> this is indeed an unaligned address access.
>
> Now, modifying acpi_os_ioremap() to not ioremap() and thus avoiding
> assigning this memory range
> as device memory doesn't seem a neat solution as it means we are not
> marking some thing with the right memory attribute and we can fall in
> similar/related issues later.
>
> Regarding the later suggestion, what I am seeing now is that the acpi
> table access functions are perhaps reused from the earlier x86
> implementation, but on the arm64 (or even arm) arch we should not be
> allowing unaligned accesses which might cause UNDEFINED behaviour and
> resultant crash.
>
> So I can try going this approach and see if it works for me.
>
> However, I am still not very sure as to why the crashkernel ranges
> historically do not include the System RAM regions (which may include
> the ACPI regions as well). These regions are available for the kernel
> usage and perhaps should be exported to the crashkernel as well.
>
> I am not fully aware of the previous discussions on capp'ing the
> crashkernel memory being passed to the kdump kernel, but did we run
> into any issues while doing so?
>
> Also, even if I extend the kexec-tools to modify the
> linux,usable-memory-range and add the ACPI regions to it, the
> crashkernel fails to boot with the below message (I have added some
> logic to print the DTB on the crash kernel boot start):
>
> [ 0.000000] chosen {
> [ 0.000000] linux,usable-memory-range
> [ 0.000000] = <
> [ 0.000000] 0x00000000
> [ 0.000000] 0x0e800000
> [ 0.000000] 0x00000000
> [ 0.000000] 0x20000000
> [ 0.000000] 0x00000000
> [ 0.000000] 0x396c0000
> [ 0.000000] 0x00000000
> [ 0.000000] 0x000a0000
> [ 0.000000] 0x00000000
> [ 0.000000] 0x39770000
> [ 0.000000] 0x00000000
> [ 0.000000] 0x00040000
> [ 0.000000] 0x00000000
> [ 0.000000] 0x398a0000
> [ 0.000000] 0x00000000
> [ 0.000000] 0x00020000
> [ 0.000000] >
> [ 0.000000] ;
>
> [snip..]
>
> [ 0.000000] linux,usable-memory-range base e800000, size 20000000
> [ 0.000000] - e800000 , 20000000
> [ 0.000000] linux,usable-memory-range base 396c0000, size a0000
> [ 0.000000] - 396c0000 , a0000
> [ 0.000000] linux,usable-memory-range base 39770000, size 40000
> [ 0.000000] - 39770000 , 40000
> [ 0.000000] linux,usable-memory-range base 398a0000, size 20000
> [ 0.000000] - 398a0000 , 20000
> [ 0.000000] initrd not fully accessible via the linear mapping --
> please check your bootloader ...
> [ 0.000000] ------------[ cut here ]------------
> [ 0.000000] WARNING: CPU: 0 PID: 0 at arch/arm64/mm/init.c:597
> arm64_memblock_init+0x210/0x484
> [ 0.000000] Modules linked in:
> [ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 4.14.0+ #7
> [ 0.000000] task: ffff000008d05580 task.stack: ffff000008cc0000
> [ 0.000000] PC is at arm64_memblock_init+0x210/0x484
> [ 0.000000] LR is at arm64_memblock_init+0x210/0x484
> [ 0.000000] pc : [<ffff000008b76984>] lr : [<ffff000008b76984>]
> pstate: 600000c5
> [ 0.000000] sp : ffff000008ccfe80
> [ 0.000000] x29: ffff000008ccfe80 x28: 000000000f370018
> [ 0.000000] x27: 0000000011230000 x26: 00000000013b0000
> [ 0.000000] x25: 000000000fe80000 x24: ffff000008cf3000
> [ 0.000000] x23: ffff000008ec0000 x22: ffff000009680000
> [ 0.000000] x21: ffff000008afa000 x20: ffff000008080000
> [ 0.000000] x19: ffff000008afa000 x18: 000000000c283806
> [ 0.000000] x17: 0000000000000000 x16: ffff000008d05580
> [ 0.000000] x15: 000000002be00842 x14: 79206b6365686320
> [ 0.000000] x13: 657361656c70202d x12: 2d20676e69707061
> [ 0.000000] x11: 6d207261656e696c x10: 2065687420616976
> [ 0.000000] x9 : 00000000000000f4 x8 : ffff000008517414
> [ 0.000000] x7 : 746f6f622072756f x6 : 000000000000000d
> [ 0.000000] x5 : ffff000008c96360 x4 : 0000000000000001
> [ 0.000000] x3 : 0000000000000000 x2 : 0000000000000000
> [ 0.000000] x1 : 0000000000000000 x0 : 0000000000000056
> [ 0.000000] Call trace:
> [ 0.000000] Exception stack(0xffff000008ccfd40 to 0xffff000008ccfe80)
> [ 0.000000] fd40: 0000000000000056 0000000000000000
> 0000000000000000 0000000000000000
> [ 0.000000] fd60: 0000000000000001 ffff000008c96360
> 000000000000000d 746f6f622072756f
> [ 0.000000] fd80: ffff000008517414 00000000000000f4
> 2065687420616976 6d207261656e696c
> [ 0.000000] fda0: 2d20676e69707061 657361656c70202d
> 79206b6365686320 000000002be00842
> [ 0.000000] fdc0: ffff000008d05580 0000000000000000
> 000000000c283806 ffff000008afa000
> [ 0.000000] fde0: ffff000008080000 ffff000008afa000
> ffff000009680000 ffff000008ec0000
> [ 0.000000] fe00: ffff000008cf3000 000000000fe80000
> 00000000013b0000 0000000011230000
> [ 0.000000] fe20: 000000000f370018 ffff000008ccfe80
> ffff000008b76984 ffff000008ccfe80
> [ 0.000000] fe40: ffff000008b76984 00000000600000c5
> ffff00000959b7a8 ffff000008ec0000
> [ 0.000000] fe60: ffffffffffffffff 0000000000000005
> ffff000008ccfe80 ffff000008b76984
> [ 0.000000] [<ffff000008b76984>] arm64_memblock_init+0x210/0x484
> [ 0.000000] [<ffff000008b7398c>] setup_arch+0x1b8/0x5f4
> [ 0.000000] [<ffff000008b70a10>] start_kernel+0x74/0x43c
> [ 0.000000] random: get_random_bytes called from
> print_oops_end_marker+0x50/0x6c with crng_init=0
> [ 0.000000] ---[ end trace 0000000000000000 ]---
> [ 0.000000] Reserving 4KB of memory at 0x2e7f0000 for elfcorehdr
> [ 0.000000] cma: Failed to reserve 512 MiB
> [ 0.000000] Kernel panic - not syncing: ERROR: Failed to allocate
> 0x0000000000010000 bytes below 0x0000000000000000.
> [ 0.000000]
> [ 0.000000] CPU: 0 PID: 0 Comm: swapper Tainted: G W
> ------------ 4.14.0+ #7
> [ 0.000000] Call trace:
> [ 0.000000] [<ffff000008088da8>] dump_backtrace+0x0/0x23c
> [ 0.000000] [<ffff000008089008>] show_stack+0x24/0x2c
> [ 0.000000] [<ffff0000087f647c>] dump_stack+0x84/0xa8
> [ 0.000000] [<ffff0000080cfd44>] panic+0x138/0x2a0
> [ 0.000000] [<ffff000008b95c88>] memblock_alloc_base+0x44/0x4c
> [ 0.000000] [<ffff000008b95cbc>] memblock_alloc+0x2c/0x38
> [ 0.000000] [<ffff000008b772dc>] early_pgtable_alloc+0x20/0x74
> [ 0.000000] [<ffff000008b7755c>] paging_init+0x28/0x544
> [ 0.000000] [<ffff000008b73990>] setup_arch+0x1bc/0x5f4
> [ 0.000000] [<ffff000008b70a10>] start_kernel+0x74/0x43c
> [ 0.000000] ---[ end Kernel panic - not syncing: ERROR: Failed to
> allocate 0x0000000000010000 bytes below 0x0000000000000000.
> [ 0.000000]
>
> I guess it is because of the 1G alignment requirement between the
> kernel image and the initrd and how we populate the holes between the
> kernel image, segments (including dtb) and the initrd from the
> kexec-tools.
>
> Akashi, any pointers on this will be helpful as well.
Please show me:
* "Virtual kernel memory layout" in dmesg
* /proc/iomem
* debug messages from kexec-tools (kexec -d)
-Takahiro AKASHI
> Regards,
> Bhupesh
>
>
> >> >
> >> > Regards,
> >> > Bhupesh
> >> >
> >> > >> Just FYI, on x86, ACPI tables seems to be exposed to crash dump kernel
> >> > >> via a kernel command line parameter, "memmap=".
> >> > >>
> >> > _______________________________________________
> >> > kexec mailing list -- kexec at lists.fedoraproject.org
> >> > To unsubscribe send an email to kexec-leave at lists.fedoraproject.org
^ permalink raw reply
* [PATCH 2/3] ARM: dts: r8a7743: Add CMT SoC specific support
From: Simon Horman @ 2017-12-18 11:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <TY1PR06MB08954C04D41BDA8EFA04E1DFC0350@TY1PR06MB0895.apcprd06.prod.outlook.com>
On Wed, Dec 13, 2017 at 10:15:39AM +0000, Fabrizio Castro wrote:
> Hello Geert,
>
> thank you for your feedback.
>
> > Hi Fabrizio,
> >
> > On Wed, Dec 13, 2017 at 10:42 AM, Fabrizio Castro
> > <fabrizio.castro@bp.renesas.com> wrote:
> > >> On Tue, Dec 12, 2017 at 06:49:38PM +0000, Fabrizio Castro wrote:
> > >> > Add CMT[01] support to SoC DT.
> > >> > Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
> > >> > Reviewed-by: Biju Das <biju.das@bp.renesas.com>
> > >> > ---
> > >> > arch/arm/boot/dts/r8a7743.dtsi | 30 ++++++++++++++++++++++++++++++
> > >> > 1 file changed, 30 insertions(+)
> > >>
> > >> I was expecting the cmt nodes to be "disabled" in the SoC file
> > >> and then enabled selectively in board files. Am I missing something?
> > >
> > > Since this component is just a compare and match timer, I thought there was no harm in enabling it by default in the SoC specific DT.
> > > The system will park it and leave its clock disabled until actually needed for something.
> > > The user can still disable it in the board specific DT if he/she doesn't mean to even have the option to use it. Do you prefer I left it
> > disabled by default?
> >
> > It's debatable (thus up to Simon the maintainer ;-).
> > For I/O devices, we disable them in the SoC .dtsi file.
> > For core infrastructure like interrupt, DMA, and GPIO controllers, we keep
> > them enabled.
> >
> > Timers are core functionality, but who's actually using these timers?
>
> I don't have a use case in mind unfortunately, but it's still core
> functionality and pretty harmless as far as I can tell. Let's see what
> Simon thinks about this.
On Renesas SoCs we have a bit more flexibility with timers than might
be the case on other SoCs. Thus I'd like to keep with the scheme of
disabling them in .dtsi and enabling them when they are needed.
Please update the patches.
^ permalink raw reply
* [PATCH v5 0/8] omap: dmtimer: Move driver out of plat-omap
From: Ladislav Michl @ 2017-12-18 11:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513059137-21593-1-git-send-email-j-keerthy@ti.com>
Keerthy,
On Tue, Dec 12, 2017 at 11:42:09AM +0530, Keerthy wrote:
> The series moves dmtimer out of plat-omap to drivers/clocksource.
> The series also does a bunch of changes to pwm-omap-dmtimer code
> to adapt to the driver migration and clean up plat specific
> pdata-quirks and use the dmtimer platform data.
thanks for nice work. I'll send two more patches as a reply to this
one. I'd be glad if you could make them part of your serie. One of
them would be nice to have for pwm driver prescaler fix which will
be send independently.
Also, if that helps you can have my
Tested-by: Ladislav Michl <ladis@linux-mips.org>
on IGEPv2 (OMAP3430 based)
> Boot tested on DRA7-EVM and AM437X-GP-EVM.
I guess PWM driver was not tested, right? See comment to PATCH 7/8.
> Compile tested omap1_defconfig.
Thank you,
ladis
^ permalink raw reply
* [PATCH 0/5] Add Sound support for iWave RZ/G1M board
From: Simon Horman @ 2017-12-18 11:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <KL1PR06MB170226A1E9F3CA011EBF3E2DB8350@KL1PR06MB1702.apcprd06.prod.outlook.com>
On Wed, Dec 13, 2017 at 09:27:30AM +0000, Biju Das wrote:
> Hi Simon,
>
> Thanks.
>
> There is a typo in the documentation dependency link.
> The correct one is https://patchwork.kernel.org/patch/10108015/
Thanks, series applied.
^ permalink raw reply
* [PATCH v3 05/11] thermal: armada: Add support for Armada AP806
From: Baruch Siach @ 2017-12-18 11:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171218104127.65017555@xps13>
Hi Miqu?l,
On Mon, Dec 18, 2017 at 10:41:27AM +0100, Miquel RAYNAL wrote:
> Hello Gregory & Baruch,
>
> On Thu, 14 Dec 2017 12:05:43 +0100
> Gregory CLEMENT <gregory.clement@free-electrons.com> wrote:
>
> > > @@ -184,9 +214,9 @@ static int armada_get_temp(struct
> > > thermal_zone_device *thermal, div = priv->data->coef_div;
> > >
> > > if (priv->data->inverted)
> > > - *temp = ((m * reg) - b) / div;
> > > + *temp = ((m * sample) - b) / div;
> > > else
> > > - *temp = (b - (m * reg)) / div;
> > > + *temp = (b - (m * sample)) / div;
> > > return 0;
> > > }
> > >
> > > @@ -237,6 +267,19 @@ static const struct armada_thermal_data
> > > armada380_data = { .inverted = true,
> > > };
> > >
> > > +static const struct armada_thermal_data armada_ap806_data = {
> > > + .is_valid = armada_is_valid,
> > > + .init_sensor = armada_ap806_init_sensor,
> > > + .is_valid_bit = BIT(16),
> > > + .temp_shift = 0,
> > > + .temp_mask = 0x3ff,
> > > + .coef_b = -150000,
> >
> > Don't you expect any side effect by storing a negative value in a
> > unsigned variable?
>
> That is a fair question, I did not spot that.
>
> As other values are really close to 2^32 I don't know what is the best
> option for us in this case. Should I:
> - don't care?
> - use signed values? (dangerous IMHO)
> - use a union with a signed and an unsigned value? (problem moved to
> ->get_temp())
Another option is to use s64 type.
baruch
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
- baruch at tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
^ permalink raw reply
* [PATCH 0/4 v5] Support bridge timings
From: Laurent Pinchart @ 2017-12-18 11:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <33bc6bf1-1730-e02a-2a03-17a60f0e5c65@samsung.com>
Hi Andrzej,
On Monday, 18 December 2017 10:43:51 EET Andrzej Hajda wrote:
> On 15.12.2017 16:54, Daniel Vetter wrote:
> > On Fri, Dec 15, 2017 at 01:30:24PM +0100, Linus Walleij wrote:
> >> On Fri, Dec 15, 2017 at 1:10 PM, Linus Walleij <linus.walleij@linaro.org>
wrote:
> >>> - The connector is apparently not the right abstraction to carry
> >>>
> >>> the detailed timings specification between DRI drivers and bridge
> >>> drivers.
> >>>
> >>> - Instead put detailed timing data into the bridge itself as an
> >>>
> >>> optional information pointer.
> >>
> >> Notice that this is just my fumbling attempts to deal with the situation.
> >>
> >> Laurent made me understand what the actual technical problem was,
> >> how come my pixels were flickering.
> >>
> >> Both Laurent and DVetter mentioned that we may need to convey
> >> information between the bridge and the display engine in some
> >> way.
> >>
> >> Alternatively I could go and hack on adding this to e.g. drm_display_info
> >> which was used in the previous patch sets by setting the negede flag
> >> in bus_formats.
> >>
> >> I don't know. struct drm_display_info is getting a bit heavy as
> >> container of misc settings related to "some kind of display".
> >> The bridge isn't even a display itself, that is on the other side
> >> of it. So using the connector and treating a bridge as "some kind
> >> of display" seems wrong too.
> >>
> >> Is there a third way?
> >
> > If you don't plan to nest bridges too deeply, there is. Atm we have 2
> > modes in drm_crtc_state:
> >
> > - mode, which is what userspace requested, and what it expects logically
> > to be the actual real thing. I.e. timing, resolution and all that that
> > userspace can observe (through plane positioning and vblank timestamps)
> > should match this mode. For external screens this should also match
> > what's physically going over the cable.
> >
> > - adjusted_mode, which is something entirely undefined and to be used by
> > drivers internally. Most drivers use it as the thing that's actually
> > transported between the CRTC and the encoder.
> >
> > There's a few common reasons for adjusted mode to be different:
> > - integrated panel, and your CRTC has a scaler. In that case the
> > userspace-requested mode is what you feed into into the scaler, and the
> > adjusted mode is what comes out of your scaler and then goes down the
> > wire to the panel.
> >
> > - your encoder is funky, and e.g. transcodes to the output mode itself,
> > but expects that you program the input mode always the same. Usual
> > reasons for this are transcoders that always want non-interlaced mode
> > (and do the interlacing themselves), if the transcoder has some scaler
> > itself (some TV-out transcoders had that), or if it has a strict
> > expectation about signalling edges and stuff (and then transcodes the
> > signal again). DACs are common doing that.
> >
> > Anyway, sounds like your bridge is of the 2nd kind, so all you have to do
> > is
> > - in your bridge->mode_fixup function, adjust the adjusted_mode as needed
> > - in your pl111 driver, program the adjusted mode, not the originally
> >
> > requested mode
> >
> > adjusted mode is set to be a copy of the requested mode by atomic helpers,
> > so this should keep working as-is on any other bridge driver.
> >
> > No idea why I didn't tell you this right away, or maybe I'm missing
> > something this time around.
>
> Using adjusted_mode will probably help here, fortunately the pipeline is
> short in this case and one adjusted_mode per pipeline should be enough.
> But there is more fundamental problem here - drm core does not provide a
> way to interact between adjacent components of the pipeline. So they are
> not able to negotiate/exchange parameters specific for the video link
> between them.
> adjusted_mode is one per pipeline and will note scale without hacks.
> Anyway I remember multiple attempts to somehow workaround this issue,
> for example:
> - passing DSI specific settings (currently performed via DSI control bus),
> - passing info about panel command mode parameters(by adding these
> properties to crtc node),
> - passing bus flags from panel to encoder/bridge (via drm_display_mode,
> nacked if I remember, I do not know if/how it is solved actually).
>
> Another concern is that adjusted_mode used inside drm driver (ie.
> between encoder and crtc) is something private per drm driver. In this
> case we have bridge which theoretically should work with ANY video
> source with compatible video bus: encoder, or another bridge before it.
> So adjusted_mode is not private anymore, and will be problematic if two
> different bridges/encoders will use it differently.
I agree completely. I believe we'll need to introduce new bridge operations to
report and negotiate timings along the pipeline. Ideally the same operations
would also be implemented by panel drivers for easier handling of the
pipeline, in which case we'll need a common data structure for both bridges
and panels. We can however start with bridges and extend that to panels in a
second step.
I'm currently reworking the bridge and panel code for the omapdrm driver,
which uses omapdrm-specific drivers not based on the drm_bridge and drm_panel
API. The goal is to replace them by standard bridge and panel drivers. As part
of that work I plan to propose new operations for bridges as discussed above.
I can't tell however when the first version will be ready, so if you want to
give it a go, feel free to do so.
> >> I'm just a bit lost.
> >
> > Once your un-lost, pls review the docs for drm_crtc_state and the various
> > mode_fixup functions, to make sure they're clear on how this is supposed
> > to work. Might need a new overview DOC: comment that ties it all together.
--
Regards,
Laurent Pinchart
^ permalink raw reply
* [PATCH 2/4] clocksource: stm32: use prescaler to adjust the resolution
From: Benjamin Gaignard @ 2017-12-18 11:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <fb09288e-1893-d99a-d15b-5cbc33fcc9a0@linaro.org>
2017-12-18 11:54 GMT+01:00 Daniel Lezcano <daniel.lezcano@linaro.org>:
> On 18/12/2017 10:44, Benjamin Gaignard wrote:
>> 2017-12-18 10:26 GMT+01:00 Daniel Lezcano <daniel.lezcano@linaro.org>:
>>> On 15/12/2017 09:52, Benjamin Gaignard wrote:
>>>> Rather than use fixed prescaler values compute it to get a clock
>>>> as close as possible of 10KHz and a resolution of 0.1ms.
>>>>
>>>> Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com>
>>>> ---
>>>> drivers/clocksource/timer-stm32.c | 23 ++++++++++++++++-------
>>>> 1 file changed, 16 insertions(+), 7 deletions(-)
>>>>
>>>> diff --git a/drivers/clocksource/timer-stm32.c b/drivers/clocksource/timer-stm32.c
>>>> index 23a321cca45b..de721d318065 100644
>>>> --- a/drivers/clocksource/timer-stm32.c
>>>> +++ b/drivers/clocksource/timer-stm32.c
>>>> @@ -37,6 +37,11 @@
>>>>
>>>> #define TIM_EGR_UG BIT(0)
>>>>
>>>> +#define MAX_TIM_PSC 0xFFFF
>>>> +
>>>> +/* Target a 10KHz clock to get a resolution of 0.1 ms */
>>>> +#define TARGETED_CLK_RATE 10000
>>>> +
>>>> static int stm32_clock_event_shutdown(struct clock_event_device *evt)
>>>> {
>>>> struct timer_of *to = to_timer_of(evt);
>>>> @@ -83,7 +88,7 @@ static irqreturn_t stm32_clock_event_handler(int irq, void *dev_id)
>>>> static void __init stm32_clockevent_init(struct timer_of *to)
>>>> {
>>>> unsigned long max_delta;
>>>> - int prescaler;
>>>> + unsigned long prescaler;
>>>>
>>>> to->clkevt.name = "stm32_clockevent";
>>>> to->clkevt.features = CLOCK_EVT_FEAT_PERIODIC;
>>>> @@ -96,13 +101,17 @@ static void __init stm32_clockevent_init(struct timer_of *to)
>>>> /* Detect whether the timer is 16 or 32 bits */
>>>> writel_relaxed(~0U, timer_of_base(to) + TIM_ARR);
>>>> max_delta = readl_relaxed(timer_of_base(to) + TIM_ARR);
>>>> - if (max_delta == ~0U) {
>>>> - prescaler = 1;
>>>> + to->clkevt.rating = 50;
>>>> + if (max_delta == ~0U)
>>>> to->clkevt.rating = 250;
>>>> - } else {
>>>> - prescaler = 1024;
>>>> - to->clkevt.rating = 50;
>>>> - }
>>>> +
>>>> + /*
>>>> + * Get the highest possible prescaler value to be as close
>>>> + * as possible of TARGETED_CLK_RATE
>>>> + */
>>>> + prescaler = DIV_ROUND_CLOSEST(timer_of_rate(to), TARGETED_CLK_RATE);
>>>
>>> With a 90MHz or 125MHz, the prescaler will be 9000 or 12500, so much
>>> more than the 1024 we have today for 16b, and 1 for 32b.
>>>
>>> Shouldn't the computation be weighted with the bits width ?
>>
>> My goal was to get the same resolution (0.1ms) for all the timers so
>> the wrap will depend of the number of bits like you describe below.
>
> Do you really want 1ms resolution with a 32bits timer ?
I want a resolution of 0.1 ms (TARGETED_CLK_RATE = 10.000)
for all the timers or 0.01ms if you think is better.
>
>>> Otherwise the timer will wrap like:
>>>
>>> 32bits:
>>>
>>> before: (2^32 / 90e6) x 1 = 47.72 seconds
>>> after: (2^32 / 90e6) x 9000 = 119.3 *hours* ~= 5days
>>>
>>> 16bits:
>>>
>>> before: (2^16 / 90e6) x 1024 = 0.745 seconds
>>> after: (2^16 / 90e6) x 9000 = 6.55 seconds
>>>
>>> The patch is ok to target the 10KHz timer rate for 16b with a 1ms
>>> resolution wrapping up after 6.55 seconds. But not for the 32bits timer.
>>> Furthermore, we can't tell anymore the 32bits timers have a rating of
>>> 250 after this patch.
>>
>> What is the link between rating and resolution (or wrap) ?
>
> Low resolution => hardly suitable for real use case => bad rating.
>
> From include/linux/clocksource.h
>
> [ ... ]
>
> * 100-199: Base level usability.
> * Functional for real use, but not desired.
> * 200-299: Good.
> * A correct and usable clocksource.
>
> [ ... ]
>
> If you want to set a timer with a delta of 12.345ms and the resolution
> is 1ms. Then you end up with a timer expiring after 13ms.
>
>> Is it a problem to get a long wrap ?
>
> It is not a problem to go for a long wrap, it is usually interesting
> when the CPU has deep idle states. But it is not worth to sacrifice the
> resolution with the 32bits timer in order to have 5 days before wrap.
>
> Keeping 47secs is fine for the moment. If you want a coarser grain, that
> could be acceptable because the resolution is very high but we can
> postpone that for later after solving this 16b / 32b thing.
When the resolution is too high I have issues with min delta value because
CPU can handle interrupt each 11ns.
>
>>> Leave the 32bits part as it is and compute the prescaler only in case of
>>> 16bits with the target rate, which sounds a reasonable approach.
>>>
>>>> + if (prescaler > MAX_TIM_PSC)
>>>> + prescaler = MAX_TIM_PSC;
>>>
>>> That can happen only if the clock rate is greater than ~655MHz, that
>>> could not happen today as far as I can tell regarding the DT. So if we
>>> hit this condition, we should speak up in the log (pr_warn).
>>
>> It is to be futur proof for next possible SoC but even if prescaler
>> reach this limit
>> it is not a problem the only consequence would be that resolution and
>> wrap change.
>
> Got that, but that needs to be logged with a pr_warn or pr_info.
OK
>
>>>> writel_relaxed(0, timer_of_base(to) + TIM_ARR);
>>>> writel_relaxed(prescaler - 1, timer_of_base(to) + TIM_PSC);
>>>
>>> Can you fix this prescaler - 1 in order to be consistent with the
>>> computation with 16b ? (32b prescaler = 0, 16b prescaler = clk_rate /
>>> target ).
>>
>> In the hardware the clock is divise by " TIM_PSC value 1" so to be coherent
>> with that I need to do prescaler -1.
>
> Ah, ok.
>
>
> --
> <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs
>
> Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
> <http://twitter.com/#!/linaroorg> Twitter |
> <http://www.linaro.org/linaro-blog/> Blog
>
--
Benjamin Gaignard
Graphic Study Group
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH] clk: sunxi: sun9i-mmc: Implement reset callback for reset controls
From: Philipp Zabel @ 2017-12-18 11:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171218035751.20661-1-wens@csie.org>
On Mon, 2017-12-18 at 11:57 +0800, Chen-Yu Tsai wrote:
> Our MMC host driver now issues a reset, instead of just deasserting
> the reset control, since commit c34eda69ad4c ("mmc: sunxi: Reset the
> device at probe time"). The sun9i-mmc clock driver does not support
> this, and will fail, which results in MMC not probing.
>
> This patch implements the reset callback by asserting the reset control,
> then deasserting it after a small delay.
>
> Fixes: 7a6fca879f59 ("clk: sunxi: Add driver for A80 MMC config clocks/resets")
> Cc: <stable@vger.kernel.org> # 4.14.x
> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Acked-by: Philipp Zabel <p.zabel@pengutronix.de>
regards
Philipp
^ permalink raw reply
* [PATCH 2/3] arm64: dts: renesas: r8a7796: move nodes which have no reg property out of bus
From: Simon Horman @ 2017-12-18 11:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMuHMdUx=MyFZypFpJPwXH-mz1Oz9W-UkEZP4QO3TSGnKEw0Fg@mail.gmail.com>
On Wed, Dec 13, 2017 at 09:34:15AM +0100, Geert Uytterhoeven wrote:
> Hi Simon,
>
> On Wed, Dec 13, 2017 at 9:25 AM, Simon Horman <horms@verge.net.au> wrote:
> > For now I've applied the following:
> >
> > From: Simon Horman <horms+renesas@verge.net.au>
> > Date: Tue, 12 Dec 2017 09:24:35 +0100
> > Subject: [PATCH] arm64: dts: renesas: r8a7796: move nodes which have no reg
> > property out of bus
> >
> > Move pmu_a5[73], timer and thermal-zones nodes from soc node to root node.
> > The nodes that have been moved do not have any register properties and thus
> > shouldn't be placed on the bus.
>
> > index c1b0d0344329..e82b4db1ad1a 100644
> > --- a/arch/arm64/boot/dts/renesas/r8a7796.dtsi
> > +++ b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
> > @@ -154,6 +154,23 @@
> > clock-frequency = <0>;
> > };
> >
> > + pmu_a57 {
> > + compatible = "arm,cortex-a57-pmu";
> > + interrupts-extended = <&gic GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH>,
> > + <&gic GIC_SPI 73 IRQ_TYPE_LEVEL_HIGH>;
> > + interrupt-affinity = <&a57_0>,
> > + <&a57_1>;
>
> Merge?
Sure, sorry for missing that.
>
> > + };
> > +
> > + pmu_a53 {
> > + compatible = "arm,cortex-a53-pmu";
> > + interrupts-extended = <&gic GIC_SPI 84 IRQ_TYPE_LEVEL_HIGH>,
> > + <&gic GIC_SPI 85 IRQ_TYPE_LEVEL_HIGH>,
> > + <&gic GIC_SPI 86 IRQ_TYPE_LEVEL_HIGH>,
> > + <&gic GIC_SPI 87 IRQ_TYPE_LEVEL_HIGH>;
> > + interrupt-affinity = <&a53_0>, <&a53_1>, <&a53_2>, <&a53_3>;
>
> Thanks!
>
> > + };
>
> > @@ -2027,4 +1968,56 @@
> > resets = <&cpg 822>;
> > };
> > };
> > +
> > + timer {
> > + compatible = "arm,armv8-timer";
> > + interrupts-extended = <&gic GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(6) | IRQ_TYPE_LEVEL_LOW)>,
> > + <&gic GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(6) | IRQ_TYPE_LEVEL_LOW)>,
> > + <&gic GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(6) | IRQ_TYPE_LEVEL_LOW)>,
> > + <&gic GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(6) | IRQ_TYPE_LEVEL_LOW)>;
>
> Much better!
>
> Or even
>
> > + interrupts-extended =
> > + <&gic GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(6) | IRQ_TYPE_LEVEL_LOW)>,
> > + <&gic GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(6) | IRQ_TYPE_LEVEL_LOW)>,
> > + <&gic GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(6) | IRQ_TYPE_LEVEL_LOW)>,
> > + <&gic GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(6) | IRQ_TYPE_LEVEL_LOW)>;
>
> I don't care that much, it extends beyond 80 characters anyway.
As its over 80 characters anyway lets go with my version.
^ permalink raw reply
* [PATCH 0/4 v5] Support bridge timings
From: Laurent Pinchart @ 2017-12-18 11:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171215155415.GT26573@phenom.ffwll.local>
Hi Daniel,
On Friday, 15 December 2017 17:54:15 EET Daniel Vetter wrote:
> On Fri, Dec 15, 2017 at 01:30:24PM +0100, Linus Walleij wrote:
> > On Fri, Dec 15, 2017 at 1:10 PM, Linus Walleij <linus.walleij@linaro.org>
wrote:
> >> - The connector is apparently not the right abstraction to carry
> >> the detailed timings specification between DRI drivers and bridge
> >> drivers.
> >>
> >> - Instead put detailed timing data into the bridge itself as an
> >> optional information pointer.
> >
> > Notice that this is just my fumbling attempts to deal with the situation.
> >
> > Laurent made me understand what the actual technical problem was,
> > how come my pixels were flickering.
> >
> > Both Laurent and DVetter mentioned that we may need to convey
> > information between the bridge and the display engine in some
> > way.
> >
> > Alternatively I could go and hack on adding this to e.g. drm_display_info
> > which was used in the previous patch sets by setting the negede flag
> > in bus_formats.
> >
> > I don't know. struct drm_display_info is getting a bit heavy as
> > container of misc settings related to "some kind of display".
> > The bridge isn't even a display itself, that is on the other side
> > of it. So using the connector and treating a bridge as "some kind
> > of display" seems wrong too.
> >
> > Is there a third way?
>
> If you don't plan to nest bridges too deeply, there is. Atm we have 2
> modes in drm_crtc_state:
>
> - mode, which is what userspace requested, and what it expects logically
> to be the actual real thing. I.e. timing, resolution and all that that
> userspace can observe (through plane positioning and vblank timestamps)
> should match this mode. For external screens this should also match
> what's physically going over the cable.
>
> - adjusted_mode, which is something entirely undefined and to be used by
> drivers internally. Most drivers use it as the thing that's actually
> transported between the CRTC and the encoder.
>
> There's a few common reasons for adjusted mode to be different:
> - integrated panel, and your CRTC has a scaler. In that case the
> userspace-requested mode is what you feed into into the scaler, and the
> adjusted mode is what comes out of your scaler and then goes down the
> wire to the panel.
>
> - your encoder is funky, and e.g. transcodes to the output mode itself,
> but expects that you program the input mode always the same. Usual
> reasons for this are transcoders that always want non-interlaced mode
> (and do the interlacing themselves), if the transcoder has some scaler
> itself (some TV-out transcoders had that), or if it has a strict
> expectation about signalling edges and stuff (and then transcodes the
> signal again). DACs are common doing that.
>
> Anyway, sounds like your bridge is of the 2nd kind, so all you have to do
> is
> - in your bridge->mode_fixup function, adjust the adjusted_mode as needed
> - in your pl111 driver, program the adjusted mode, not the originally
> requested mode
>
> adjusted mode is set to be a copy of the requested mode by atomic helpers,
> so this should keep working as-is on any other bridge driver.
I don't think that's the right fix.
The problem here is that the display engine has to output data in a way that
doesn't violate the DAC setup and hold times. Depending on the display engine,
you can just select the output clock edge, or adjust the phase of the data
compared to the pixel clock by a fraction of a clock cycle (1/4 is common,
I've seen smaller steps too). Note that selecting the opposite clock edge is
simple a 1/2 clock cycle delay.
The delay has to be computed based on the receiver's setup and hold times, but
also take into account other components on the board (such as buffer or
voltage shifters, or even inverters) and the PCB delay itself. This
computation doesn't belong to the bridge driver, especially given than its
goal is to compute a delay that depends on the display engine's capabilities
(inverting the clock vs. smaller step delays for instance). For this reason I
think the bridge driver should expose its timing parameters, and the display
engine should then decide how to output its data accordingly.
> No idea why I didn't tell you this right away, or maybe I'm missing
> something this time around.
>
> > I'm just a bit lost.
>
> Once your un-lost, pls review the docs for drm_crtc_state and the various
> mode_fixup functions, to make sure they're clear on how this is supposed
> to work. Might need a new overview DOC: comment that ties it all together.
--
Regards,
Laurent Pinchart
^ permalink raw reply
* [PATCH 1/1] arm: sunxi: Add alternative pins for spi0
From: Stefan Mavrodiev @ 2017-12-18 11:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171218092814.n5ptd5mhvo4nkjgq@flea.lan>
On 12/18/2017 11:28 AM, Maxime Ripard wrote:
> On Mon, Dec 18, 2017 at 08:24:21AM +0200, Stefan Mavrodiev wrote:
>> On 12/15/2017 05:08 PM, Maxime Ripard wrote:
>>> Hi,
>>>
>>> On Thu, Dec 14, 2017 at 08:24:54AM +0200, Stefan Mavrodiev wrote:
>>>> On 12/13/2017 05:40 PM, Maxime Ripard wrote:
>>>>> Hi,
>>>>>
>>>>> On Wed, Dec 13, 2017 at 09:44:34AM +0200, Stefan Mavrodiev wrote:
>>>>>> Allwinner A10/A13/A20 SoCs have pinmux for spi0
>>>>>> on port C. The patch adds these pins in the respective
>>>>>> dts includes.
>>>>>>
>>>>>> Signed-off-by: Stefan Mavrodiev <stefan@olimex.com>
>>>>> Do you have any boards that are using these?
>>>>>
>>>>> We won't merge that patch if there's no users for it.
>>>> A20-OLinuXino-Lime/Lime2 and A10-OLinuXino-Lime with spi flash.
>>>> For A13 we still doesn't have that option.
>>> If this bus is exposed on the headers, you can add those to the DT but
>>> leave them disabled if you want. Buf if there's no users of those
>>> nodes, our policy is not to merge them.
>> So basically I should resend the patch, enabling the those pins only for
>> sun4i and sun7i platform?
> I'm not quite sure what you mean, but you should do something like
> 77df9d66b0b1ad01c685fd6341ce501493899658
>
> Maxime
>
I guess, since this patch actually supports optional component, it
shouldn't be applied.
(This is already commented here:
https://patchwork.kernel.org/patch/10076721/ )
Thanks,
Stefan Mavrodiev
^ permalink raw reply
* [PATCH] phy: rockchip-typec: Try to turn the PHY on several times
From: Enric Balletbo Serra @ 2017-12-18 10:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAD=FV=Vw3_foX0_VfFG8h0xVrEEfOCWmVfF6xDVg++AqBbDRCA@mail.gmail.com>
Hi,
2017-12-13 20:14 GMT+01:00 Doug Anderson <dianders@chromium.org>:
> Hi,
>
> On Wed, Dec 13, 2017 at 4:41 AM, Enric Balletbo Serra
> <eballetbo@gmail.com> wrote:
>> Hi Doug,
>>
>> 2017-12-11 22:45 GMT+01:00 Douglas Anderson <dianders@chromium.org>:
>>> Bind / unbind stress testing of the USB controller on rk3399 found
>>> that we'd often end up with lots of failures that looked like this:
>>>
>>> phy phy-ff800000.phy.9: phy poweron failed --> -110
>>> dwc3 fe900000.dwc3: failed to initialize core
>>> dwc3: probe of fe900000.dwc3 failed with error -110
>>>
>>> Those errors were sometimes seen at bootup too, in which case USB
>>> peripherals wouldn't work until unplugged and re-plugged in.
>>>
>>> I spent some time trying to figure out why the PHY was failing to
>>> power on but I wasn't able to. Possibly this has to do with the fact
>>> that the PHY docs say that the USB controller "needs to be held in
>>> reset to hold pipe power state in P2 before initializing the Type C
>>> PHY" but that doesn't appear to be easy to do with the dwc3 driver
>>> today. Messing around with the ordering of the reset vs. the PHY
>>> initialization in the dwc3 driver didn't seem to fix things.
>>>
>>> I did, however, find that if I simply retry the power on it seems to
>>> have a good chance of working. So let's add some retries. I ran a
>>> pretty tight bind/unbind loop overnight. When I did so, I found that
>>> I need to retry between 1% and 2% of the time. Overnight I found only
>>> a small handful of times where I needed 2 retries. I never found a
>>> case where I needed 3 retries.
>>>
>>> I'm completely aware of the fact that this is quite an ugly hack and I
>>> wish I didn't have to resort to it, but I have no other real idea how
>>> to make this hardware reliable. If Rockchip in the future can come up
>>> with a solution we can always revert this hack. Until then, let's at
>>> least have something that works.
>>>
>>> This patch is tested atop Enric's latest dwc3 patch series ending at:
>>> https://patchwork.kernel.org/patch/10095527/
>>> ...but it could be applied independently of that series without any
>>> bad effects.
>>>
>>> For some more details on this bug, you can refer to:
>>> https://bugs.chromium.org/p/chromium/issues/detail?id=783464
>>>
>>> Signed-off-by: Douglas Anderson <dianders@chromium.org>
>>> ---
>>>
>>> drivers/phy/rockchip/phy-rockchip-typec.c | 24 ++++++++++++++++++++++--
>>> 1 file changed, 22 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/phy/rockchip/phy-rockchip-typec.c b/drivers/phy/rockchip/phy-rockchip-typec.c
>>> index ee85fa0ca4b0..5c2157156ce1 100644
>>> --- a/drivers/phy/rockchip/phy-rockchip-typec.c
>>> +++ b/drivers/phy/rockchip/phy-rockchip-typec.c
>>> @@ -349,6 +349,8 @@
>>> #define MODE_DFP_USB BIT(1)
>>> #define MODE_DFP_DP BIT(2)
>>>
>>> +#define POWER_ON_TRIES 5
>>> +
>>
>> I did the test of increase the number of tries to 100 because
>> unfortunately, even with this patch applied, I can see the problem on
>> my kevin with current mainline.
>>
>> [ 244.309094] rockchip-typec-phy ff800000.phy: Turn on failed after 100 loops
>>
>> That's an extra debug print ^
>>
>> [ 244.317019] phy phy-ff800000.phy.8: phy poweron failed --> -110
>> [ 244.323824] dwc3 fe900000.dwc3: failed to initialize core
>> [ 244.330057] dwc3: probe of fe900000.dwc3 failed with error -110
>>
>> So I'm wondering if there is something else that I need to apply to
>> really fix this as you didn't reproduce the issue doing lots of tests
>> and I can reproduce the issue very easily.
>
> Ah! I added that message to the top of my upstream series and,
> indeed, I sometimes see the PHY fail to turn on. Doh.
>
> OK, so here's what I've done:
>
> * The place where I ran the overnight loops was actually the Chrome OS
> 4.4 kernel. In that kernel I had a message very similar to yours and
> I didn't hit it. I just re-ran this for 20 minutes now and I can
> re-confirm. In the Chrome OS kernel I never see it needing more than
> a 1 (or 2) loops and it doesn't ever get into the "totally failed"
> case.
>
Ok, blame me, so the reason I saw that message often is because my DT
missed the entries to define the reset (fixed in the latest series I
sent) So completely my fault.
> * Previously I ran ~10 minutes with the upstream kernel, but at the
> time I didn't have your printout. After 10 minutes I checked my logs
> and I definitely saw the "Needed 1 loops to turn on", so I knew my
> patch was doing something useful. It didn't occur to me to re-confirm
> that I didn't get the "totally failed" upstream, though now that I say
> it out loud it's stupid that I didn't think to do this.
>
Doing your bind/unbind stress test with mainline I'm getting some
errors though, the 'phy poweron failed --> -110' disapeared and your
patch helps.
But sometimes I get :
[ 6451.626640] usb 5-1: new high-speed USB device number 2 using xhci-hcd
[ 6451.814221] hub 5-1:1.0: USB hub found
[ 6451.819897] hub 5-1:1.0: 4 ports detected
[ 6451.914772] usb 6-1: new SuperSpeed USB device number 2 using xhci-hcd
[ 6451.958372] hub 6-1:1.0: USB hub found
[ 6451.962867] hub 6-1:1.0: 4 ports detected
[ 6452.152438] xhci-hcd xhci-hcd.1.auto: remove, state 1
[ 6452.158121] usb 5-1.2: new full-speed USB device number 3 using xhci-hcd
[ 6452.158126] usb 5-1.2: hub failed to enable device, error -108
[ 6452.172323] usb usb6: USB disconnect, device number 1
[ 6452.174638] hub 6-1:1.0: activate --> -19
[ 6452.182507] usb 6-1: USB disconnect, device number 2
And after some minutes of test I get a:
[ 9182.623783] Unable to handle kernel NULL pointer dereference at
virtual address 00000090
[ 9182.632831] Mem abort info:
[ 9182.635945] ESR = 0x96000004
[ 9182.639350] Exception class = DABT (current EL), IL = 32 bits
[ 9182.645959] SET = 0, FnV = 0
[ 9182.649365] EA = 0, S1PTW = 0
[ 9182.652866] Data abort info:
[ 9182.656076] ISV = 0, ISS = 0x00000004
[ 9182.660355] CM = 0, WnR = 0
[ 9182.663665] user pgtable: 4k pages, 48-bit VAs, pgd = 0000000087ab6ba9
[ 9182.670957] [0000000000000090] *pgd=0000000000000000
[ 9182.676504] Internal error: Oops: 96000004 [#1] PREEMPT SMP
[ 9182.682727] Modules linked in: fuse mwifiex_pcie mwifiex cdc_ether
usbnet r8152 cfg80211 rfkill cros_ec_sensors cros_ec_sensors_core
indust
rialio_triggered_buffer kfifo_buf phy_rockchip_pcie snd_soc_max98357a
snd_soc_rk3399_gru_sound atmel_mxt_ts videobuf2_vmalloc
videobuf2_memops
videobuf2_v4l2 crc32_ce videobuf2_core videodev crct10dif_ce
snd_soc_rockchip_i2s snd_soc_da7219 snd_soc_rt5514 snd_soc_rt5514_spi
cros_ec_de
vs rockchip_saradc snd_soc_rl6231 rockchip_thermal media pcie_rockchip
ip_tables x_tables ipv6
[ 9182.733489] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.15.0-rc3+ #39
[ 9182.740681] Hardware name: Google Kevin (DT)
[ 9182.745448] pstate: 80000085 (Nzcv daIf -PAN -UAO)
[ 9182.750803] pc : xhci_irq+0x30c/0x1360
[ 9182.754986] lr : xhci_irq+0x40/0x1360
[ 9182.759071] sp : ffff000008003d90
[ 9182.762768] x29: ffff000008003d90 x28: ffff8000b4948220
[ 9182.768701] x27: 0000000000000001 x26: ffff00000a51d640
[ 9182.774633] x25: ffff00000914eb6b x24: 0000000000000000
[ 9182.780566] x23: 0000000000000000 x22: 0000000000000080
[ 9182.786499] x21: ffff8000b4948000 x20: ffff8000b494826c
[ 9182.792431] x19: ffff8000b4948000 x18: 0000000000040f00
[ 9182.798363] x17: 0000ffffb54b1b90 x16: ffff000008222b68
[ 9182.804296] x15: 0000000000000000 x14: 00000000000023de
[ 9182.810229] x13: 7fffffffffffffff x12: 0000000000000040
[ 9182.816161] x11: ffff8000f24cc000 x10: 000000000000001e
[ 9182.822093] x9 : ffff8000f24cc118 x8 : 0000000000000000
[ 9182.828026] x7 : ffff8000f1735000 x6 : 0000000000000001
[ 9182.833959] x5 : 0000000000000000 x4 : ffff8000c186e100
[ 9182.839891] x3 : 0000000000000001 x2 : 0000000000000002
[ 9182.845823] x1 : ffff8000b4948000 x0 : 0000000000000003
[ 9182.851758] Process swapper/0 (pid: 0, stack limit = 0x0000000049fd774f)
[ 9182.859242] Call trace:
[ 9182.861972] xhci_irq+0x30c/0x1360
[ 9182.865769] usb_hcd_irq+0x2c/0x48
[ 9182.869566] __handle_irq_event_percpu+0x9c/0x128
[ 9182.874818] handle_irq_event_percpu+0x1c/0x58
[ 9182.879778] handle_irq_event+0x48/0x78
[ 9182.874818] handle_irq_event_percpu+0x1c/0x58
[ 9182.884061] handle_fasteoi_irq+0xa0/0x180
[ 9182.888634] generic_handle_irq+0x24/0x38
[ 9182.893108] __handle_domain_irq+0x5c/0xb8
[ 9182.897682] gic_handle_irq+0xc4/0x180
[ 9182.901865] el1_irq+0xb0/0x128
[ 9182.905370] arch_cpu_idle+0x10/0x18
[ 9182.909361] do_idle+0x11c/0x1e0
[ 9182.912962] cpu_startup_entry+0x24/0x28
[ 9182.917343] rest_init+0xd0/0xe0
[ 9182.920946] start_kernel+0x398/0x3ac
[ 9182.925035] Code: f9400798 340035c0 7103fc1f 54004ac0 (b9409305)
[ 9182.931848] ---[ end trace dc830bbccf53c326 ]---
So there is still something wrong with current mainline that seems
it's solved in chromeos. I'll try to investigate a bit.
> * Previously when playing with patches on the upstream kernel I saw
> lots of problems powering on the PHY and I thought my patch was
> helping, but that was all very non-scientific.
>
>
> So to say it shortly:
>
> * For me, my patch makes things a slightly better even on the upstream
> kernel (I do sometimes see the "turned on after 1 tries")
>
> * I can confirm that my patch doesn't fix everything upstream, so
> there's something different about the Chrome OS tree still.
>
> ---
>
> I also picked all the local patches from the Chrome OS kernel to the
> PHY driver and now my PHY driver in the upstream and downstream trees
> match. I can still reproduce problems. So the issue is somewhere at
> a higher level...
>
>
> So basically something outside the PHY driver is causing it to fail
> unexpectedly upstream. I guess the hacky retry won't work well enough
> there after all. :(
>
> One question: if you get the "failed after 100 loops" and then you do
> another unbind / bind, does it work after that? The original reason I
> got the idea to retry was because if I simply tried an unbind / bind
> again then things worked OK...
>
>
> -Doug
Regards,
-Enric
^ permalink raw reply
* [PATCH 2/4] clocksource: stm32: use prescaler to adjust the resolution
From: Daniel Lezcano @ 2017-12-18 10:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CA+M3ks5qBNzwjDimVYUS1sHzDDHD+Y44OtyT9L=imbQoNbsnFA@mail.gmail.com>
On 18/12/2017 10:44, Benjamin Gaignard wrote:
> 2017-12-18 10:26 GMT+01:00 Daniel Lezcano <daniel.lezcano@linaro.org>:
>> On 15/12/2017 09:52, Benjamin Gaignard wrote:
>>> Rather than use fixed prescaler values compute it to get a clock
>>> as close as possible of 10KHz and a resolution of 0.1ms.
>>>
>>> Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com>
>>> ---
>>> drivers/clocksource/timer-stm32.c | 23 ++++++++++++++++-------
>>> 1 file changed, 16 insertions(+), 7 deletions(-)
>>>
>>> diff --git a/drivers/clocksource/timer-stm32.c b/drivers/clocksource/timer-stm32.c
>>> index 23a321cca45b..de721d318065 100644
>>> --- a/drivers/clocksource/timer-stm32.c
>>> +++ b/drivers/clocksource/timer-stm32.c
>>> @@ -37,6 +37,11 @@
>>>
>>> #define TIM_EGR_UG BIT(0)
>>>
>>> +#define MAX_TIM_PSC 0xFFFF
>>> +
>>> +/* Target a 10KHz clock to get a resolution of 0.1 ms */
>>> +#define TARGETED_CLK_RATE 10000
>>> +
>>> static int stm32_clock_event_shutdown(struct clock_event_device *evt)
>>> {
>>> struct timer_of *to = to_timer_of(evt);
>>> @@ -83,7 +88,7 @@ static irqreturn_t stm32_clock_event_handler(int irq, void *dev_id)
>>> static void __init stm32_clockevent_init(struct timer_of *to)
>>> {
>>> unsigned long max_delta;
>>> - int prescaler;
>>> + unsigned long prescaler;
>>>
>>> to->clkevt.name = "stm32_clockevent";
>>> to->clkevt.features = CLOCK_EVT_FEAT_PERIODIC;
>>> @@ -96,13 +101,17 @@ static void __init stm32_clockevent_init(struct timer_of *to)
>>> /* Detect whether the timer is 16 or 32 bits */
>>> writel_relaxed(~0U, timer_of_base(to) + TIM_ARR);
>>> max_delta = readl_relaxed(timer_of_base(to) + TIM_ARR);
>>> - if (max_delta == ~0U) {
>>> - prescaler = 1;
>>> + to->clkevt.rating = 50;
>>> + if (max_delta == ~0U)
>>> to->clkevt.rating = 250;
>>> - } else {
>>> - prescaler = 1024;
>>> - to->clkevt.rating = 50;
>>> - }
>>> +
>>> + /*
>>> + * Get the highest possible prescaler value to be as close
>>> + * as possible of TARGETED_CLK_RATE
>>> + */
>>> + prescaler = DIV_ROUND_CLOSEST(timer_of_rate(to), TARGETED_CLK_RATE);
>>
>> With a 90MHz or 125MHz, the prescaler will be 9000 or 12500, so much
>> more than the 1024 we have today for 16b, and 1 for 32b.
>>
>> Shouldn't the computation be weighted with the bits width ?
>
> My goal was to get the same resolution (0.1ms) for all the timers so
> the wrap will depend of the number of bits like you describe below.
Do you really want 1ms resolution with a 32bits timer ?
>> Otherwise the timer will wrap like:
>>
>> 32bits:
>>
>> before: (2^32 / 90e6) x 1 = 47.72 seconds
>> after: (2^32 / 90e6) x 9000 = 119.3 *hours* ~= 5days
>>
>> 16bits:
>>
>> before: (2^16 / 90e6) x 1024 = 0.745 seconds
>> after: (2^16 / 90e6) x 9000 = 6.55 seconds
>>
>> The patch is ok to target the 10KHz timer rate for 16b with a 1ms
>> resolution wrapping up after 6.55 seconds. But not for the 32bits timer.
>> Furthermore, we can't tell anymore the 32bits timers have a rating of
>> 250 after this patch.
>
> What is the link between rating and resolution (or wrap) ?
Low resolution => hardly suitable for real use case => bad rating.
>From include/linux/clocksource.h
[ ... ]
* 100-199: Base level usability.
* Functional for real use, but not desired.
* 200-299: Good.
* A correct and usable clocksource.
[ ... ]
If you want to set a timer with a delta of 12.345ms and the resolution
is 1ms. Then you end up with a timer expiring after 13ms.
> Is it a problem to get a long wrap ?
It is not a problem to go for a long wrap, it is usually interesting
when the CPU has deep idle states. But it is not worth to sacrifice the
resolution with the 32bits timer in order to have 5 days before wrap.
Keeping 47secs is fine for the moment. If you want a coarser grain, that
could be acceptable because the resolution is very high but we can
postpone that for later after solving this 16b / 32b thing.
>> Leave the 32bits part as it is and compute the prescaler only in case of
>> 16bits with the target rate, which sounds a reasonable approach.
>>
>>> + if (prescaler > MAX_TIM_PSC)
>>> + prescaler = MAX_TIM_PSC;
>>
>> That can happen only if the clock rate is greater than ~655MHz, that
>> could not happen today as far as I can tell regarding the DT. So if we
>> hit this condition, we should speak up in the log (pr_warn).
>
> It is to be futur proof for next possible SoC but even if prescaler
> reach this limit
> it is not a problem the only consequence would be that resolution and
> wrap change.
Got that, but that needs to be logged with a pr_warn or pr_info.
>>> writel_relaxed(0, timer_of_base(to) + TIM_ARR);
>>> writel_relaxed(prescaler - 1, timer_of_base(to) + TIM_PSC);
>>
>> Can you fix this prescaler - 1 in order to be consistent with the
>> computation with 16b ? (32b prescaler = 0, 16b prescaler = clk_rate /
>> target ).
>
> In the hardware the clock is divise by " TIM_PSC value 1" so to be coherent
> with that I need to do prescaler -1.
Ah, ok.
--
<http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
^ permalink raw reply
* linux-next: Signed-off-by missing for commit in the mvebu tree
From: Gregory CLEMENT @ 2017-12-18 10:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171218074035.7ed52363@canb.auug.org.au>
Hi Stephen,
On lun., d?c. 18 2017, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi all,
>
> Commit
>
> a2e2a5860be3 ("arm64: dts: marvell: add NAND support on the 8040-DB board")
>
> is missing a Signed-off-by from its committer.
Thanks for the notice, I will fix it.
Gregory
>
> --
> Cheers,
> Stephen Rothwell
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCH 4/4 v5] drm/pl111: Support handling bridge timings
From: Laurent Pinchart @ 2017-12-18 10:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171215121047.3650-5-linus.walleij@linaro.org>
Hi Linus,
Thank you for the patch.
On Friday, 15 December 2017 14:10:47 EET Linus Walleij wrote:
> If the bridge has a too strict setup time for the incoming
> signals, we may not be fast enough and then we need to
> compensate by outputting the signal on the inverse clock
> edge so it is for sure stable when the bridge samples it.
>
> Since bridges in difference to panels does not expose their
> connectors, make the connector optional in the display
> setup code.
>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> ---
> ChangeLog v4->v5:
> - Use the new bridge timings setup method.
> ---
> drivers/gpu/drm/pl111/Kconfig | 1 +
> drivers/gpu/drm/pl111/pl111_display.c | 35 ++++++++++++++++++++++++++++----
> drivers/gpu/drm/pl111/pl111_drv.c | 20 +++++++++++---------
> 3 files changed, 43 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/pl111/Kconfig b/drivers/gpu/drm/pl111/Kconfig
> index e5e2abd66491..82cb3e60ddc8 100644
> --- a/drivers/gpu/drm/pl111/Kconfig
> +++ b/drivers/gpu/drm/pl111/Kconfig
> @@ -8,6 +8,7 @@ config DRM_PL111
> select DRM_GEM_CMA_HELPER
> select DRM_BRIDGE
> select DRM_PANEL_BRIDGE
> + select DRM_DUMB_VGA_DAC
> select VT_HW_CONSOLE_BINDING if FRAMEBUFFER_CONSOLE
> help
> Choose this option for DRM support for the PL111 CLCD controller.
> diff --git a/drivers/gpu/drm/pl111/pl111_display.c
> b/drivers/gpu/drm/pl111/pl111_display.c index 06c4bf756b69..7fe4040aea46
> 100644
> --- a/drivers/gpu/drm/pl111/pl111_display.c
> +++ b/drivers/gpu/drm/pl111/pl111_display.c
> @@ -94,6 +94,7 @@ static void pl111_display_enable(struct
> drm_simple_display_pipe *pipe, const struct drm_display_mode *mode =
> &cstate->mode;
> struct drm_framebuffer *fb = plane->state->fb;
> struct drm_connector *connector = priv->connector;
> + struct drm_bridge *bridge = priv->bridge;
> u32 cntl;
> u32 ppl, hsw, hfp, hbp;
> u32 lpp, vsw, vfp, vbp;
> @@ -143,11 +144,37 @@ static void pl111_display_enable(struct
> drm_simple_display_pipe *pipe, if (mode->flags & DRM_MODE_FLAG_NVSYNC)
> tim2 |= TIM2_IVS;
>
> - if (connector->display_info.bus_flags & DRM_BUS_FLAG_DE_LOW)
> - tim2 |= TIM2_IOE;
> + if (connector) {
> + if (connector->display_info.bus_flags & DRM_BUS_FLAG_DE_LOW)
> + tim2 |= TIM2_IOE;
>
> - if (connector->display_info.bus_flags & DRM_BUS_FLAG_PIXDATA_NEGEDGE)
> - tim2 |= TIM2_IPC;
> + if (connector->display_info.bus_flags &
> + DRM_BUS_FLAG_PIXDATA_NEGEDGE)
> + tim2 |= TIM2_IPC;
> + }
> +
> + if (bridge) {
> + const struct drm_bridge_timings *btimings = bridge->timings;
> +
> + /*
> + * Here is when things get really fun. Sometimes the bridge
> + * timings are such that the signal out from PL11x is not
> + * stable before the receiving bridge (such as a dumb VGA DAC
> + * or similar) samples it. If that happens, we compensate by
> + * the only method we have: output the data on the opposite
> + * edge of the clock so it is for sure stable when it gets
> + * sampled.
> + *
> + * The PL111 manual does not contain proper timining diagrams
> + * or data for these details, but we know from experiments
> + * that the setup time is more than 3000 picoseconds (3 ns).
> + * If we have a bridge that requires the signal to be stable
> + * earlier than 3000 ps before the clock pulse, we have to
> + * output the data on the opposite edge to avoid flicker.
This should probably depend on the pixel clock frequency, but if it works for
you for now, I have no objection.
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> + */
> + if (btimings && btimings->setup_time_ps >= 3000)
> + tim2 ^= TIM2_IPC;
> + }
>
> tim2 |= cpl << 16;
> writel(tim2, priv->regs + CLCD_TIM2);
> diff --git a/drivers/gpu/drm/pl111/pl111_drv.c
> b/drivers/gpu/drm/pl111/pl111_drv.c index 201d57d5cb54..101a9c7db6ff 100644
> --- a/drivers/gpu/drm/pl111/pl111_drv.c
> +++ b/drivers/gpu/drm/pl111/pl111_drv.c
> @@ -107,11 +107,17 @@ static int pl111_modeset_init(struct drm_device *dev)
> ret = PTR_ERR(bridge);
> goto out_config;
> }
> - /*
> - * TODO: when we are using a different bridge than a panel
> - * (such as a dumb VGA connector) we need to devise a different
> - * method to get the connector out of the bridge.
> - */
> + } else if (bridge) {
> + dev_info(dev->dev, "Using non-panel bridge\n");
> + } else {
> + dev_err(dev->dev, "No bridge, exiting\n");
> + return -ENODEV;
> + }
> +
> + priv->bridge = bridge;
> + if (panel) {
> + priv->panel = panel;
> + priv->connector = panel->connector;
> }
>
> ret = pl111_display_init(dev);
> @@ -125,10 +131,6 @@ static int pl111_modeset_init(struct drm_device *dev)
> if (ret)
> return ret;
>
> - priv->bridge = bridge;
> - priv->panel = panel;
> - priv->connector = panel->connector;
> -
> ret = drm_vblank_init(dev, 1);
> if (ret != 0) {
> dev_err(dev->dev, "Failed to init vblank\n");
--
Regards,
Laurent Pinchart
^ permalink raw reply
* [PATCH 3/4 v5] drm/bridge: Add timing support to dumb VGA DAC
From: Laurent Pinchart @ 2017-12-18 10:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171215121047.3650-4-linus.walleij@linaro.org>
Hi Linus,
Thank you for the patch.
On Friday, 15 December 2017 14:10:46 EET Linus Walleij wrote:
> This extends the dumb VGA DAC bridge to handle the THS8134A
> and THS8134B VGA DACs in addition to those already handled.
>
> We assign the proper timing data to the pointer inside the
> bridge struct so display controllers that need to align their
> timings to the bridge can pick it up and work from there.
>
> Cc: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> Cc: Bartosz Golaszewski <bgolaszewski@baylibre.com>
> Cc: Maxime Ripard <maxime.ripard@free-electrons.com>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> ---
> ChangeLog v4->v5:
> - Rewrite the support using the new concept of defining
> fine-granular sampling (setup+hold) timing definitions
> stored in the bridge timings struct.
> ChangeLog v3->v4:
> - Actually have the code syntactically correct and compiling :(
> (Kconfig mistake.)
> (...)
> AS usr/initramfs_data.o
> AR usr/built-in.o
> CC drivers/gpu/drm/bridge/dumb-vga-dac.o
> AR drivers/gpu/drm/bridge/built-in.o
> AR drivers/gpu/drm/built-in.o
> AR drivers/gpu/built-in.o
> AR drivers/built-in.o
> (...)
> ChangeLog v2->v3:
> - Move const specifier.
> - Cut one line of code assigning bus flags.
> - Preserve the "ti,ths8135" compatible for elder device trees.
> ChangeLog v1->v2:
> - Alphabetize includes
> - Use a u32 with the bus polarity flags and just encode the
> polarity using the DRM define directly.
> - Rename vendor_data to vendor_info.
> - Simplify assignment of the flag as it is just a simple
> u32 now.
> - Probe all TI variants on the "ti,ths813x" wildcard for now,
> we only need to know that the device is in this family to
> set the clock edge flag right.
> ---
> drivers/gpu/drm/bridge/dumb-vga-dac.c | 61 ++++++++++++++++++++++++++++++--
> 1 file changed, 58 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/dumb-vga-dac.c
> b/drivers/gpu/drm/bridge/dumb-vga-dac.c index de5e7dee7ad6..34788783a90f
> 100644
> --- a/drivers/gpu/drm/bridge/dumb-vga-dac.c
> +++ b/drivers/gpu/drm/bridge/dumb-vga-dac.c
> @@ -11,6 +11,7 @@
> */
>
> #include <linux/module.h>
> +#include <linux/of_device.h>
> #include <linux/of_graph.h>
> #include <linux/regulator/consumer.h>
>
> @@ -176,11 +177,13 @@ static struct i2c_adapter
> *dumb_vga_retrieve_ddc(struct device *dev) static int dumb_vga_probe(struct
> platform_device *pdev)
> {
> struct dumb_vga *vga;
> + const struct drm_bridge_timings *timings;
>
> vga = devm_kzalloc(&pdev->dev, sizeof(*vga), GFP_KERNEL);
> if (!vga)
> return -ENOMEM;
> platform_set_drvdata(pdev, vga);
> + timings = of_device_get_match_data(&pdev->dev);
>
> vga->vdd = devm_regulator_get_optional(&pdev->dev, "vdd");
> if (IS_ERR(vga->vdd)) {
> @@ -204,6 +207,7 @@ static int dumb_vga_probe(struct platform_device *pdev)
>
> vga->bridge.funcs = &dumb_vga_bridge_funcs;
> vga->bridge.of_node = pdev->dev.of_node;
> + vga->bridge.timings = timings;
Do you need the intermediate timings variable ?
> drm_bridge_add(&vga->bridge);
>
> @@ -222,10 +226,61 @@ static int dumb_vga_remove(struct platform_device
> *pdev) return 0;
> }
>
> +/*
> + * We assume the ADV7123 DAC is the "default" for historical reasons
> + * Information taken from the ADV7123 datasheet, revision D.
> + * NOTE: the ADV7123EP seems to have other timings and need a new timings
> + * set if used.
> + */
> +static const struct drm_bridge_timings default_dac_timings = {
> + /* Timing specifications, datasheet page 7 */
> + .sampling_edge = true,
> + .setup_time_ps = 500,
> + .hold_time_ps = 1500,
> +};
You know what's lovely ? The setup time depends on the power supply voltage
:-) Let's use 500ps for now, that's a conservative value that will work for
both 5V and 3.3V. If anyone needs to lower it to 200ps later, they can always
implement support for voltage-dependent timings.
> +/*
> + * Information taken from the THS8134, THS8134A, THS8134B datasheet named
> + * "SLVS205D", dated May 1990, revised March 2000.
> + */
> +static const struct drm_bridge_timings ti_ths8134_dac_timings = {
> + /* From timing diagram, datasheet page 9 */
> + .sampling_edge = true,
> + /* From datasheet, page 12 */
> + .setup_time_ps = 3000,
> + /* I guess this means latched input */
> + .hold_time_ps = 0,
> +};
> +
> +/*
> + * Information taken from the THS8135 datasheet named "SLAS343B", dated
> + * May 2001, revised April 2013.
> + */
> +static const struct drm_bridge_timings ti_ths8135_dac_timings = {
> + /* From timing diagram, datasheet page 14 */
> + .sampling_edge = true,
> + /* From datasheet, page 16 */
> + .setup_time_ps = 2000,
> + .hold_time_ps = 500,
> +};
> +
> static const struct of_device_id dumb_vga_match[] = {
> - { .compatible = "dumb-vga-dac" },
> - { .compatible = "adi,adv7123" },
> - { .compatible = "ti,ths8135" },
> + {
> + .compatible = "dumb-vga-dac",
> + .data = &default_dac_timings,
Shouldn't we leave this NULL for dumb VGA DACs ? They're made of passive
components and don't sample the signal, so there's no real timings that we can
report.
Apart from that,
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> + },
> + {
> + .compatible = "adi,adv7123",
> + .data = &default_dac_timings,
> + },
> + {
> + .compatible = "ti,ths8135",
> + .data = &ti_ths8135_dac_timings,
> + },
> + {
> + .compatible = "ti,ths8134",
> + .data = &ti_ths8134_dac_timings,
> + },
> {},
> };
> MODULE_DEVICE_TABLE(of, dumb_vga_match);
--
Regards,
Laurent Pinchart
^ permalink raw reply
* [linux-sunxi] [PATCH v3 2/3] dt-bindings: media: Add Allwinner V3s Camera Sensor Interface (CSI)
From: Chen-Yu Tsai @ 2017-12-18 10:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171218174309.9170c971c5acac0d14dd782d@magewell.com>
On Mon, Dec 18, 2017 at 5:43 PM, Yong <yong.deng@magewell.com> wrote:
> Hi,
>
> On Mon, 18 Dec 2017 10:24:37 +0100
> Maxime Ripard <maxime.ripard@free-electrons.com> wrote:
>
>> Hi,
>>
>> On Mon, Dec 18, 2017 at 04:49:21PM +0800, Yong wrote:
>> > > > + compatible = "allwinner,sun8i-v3s-csi";
>> > > > + reg = <0x01cb4000 0x1000>;
>> > > > + interrupts = <GIC_SPI 84 IRQ_TYPE_LEVEL_HIGH>;
>> > > > + clocks = <&ccu CLK_BUS_CSI>,
>> > > > + <&ccu CLK_CSI1_SCLK>,
>> > >
>> > > CSI also has an MCLK. Do you need that one?
>> >
>> > MCLK is not needed if the front end is not a sensor (like adv7611).
>> > I will add it as an option.
>>
>> I guess this should always be needed then. And the driver will make
>> the decision to enable it or not.
>
> But how the driver to know if it should be enabled?
> I think MCLK should be added in DT just if the subdev need it.
Looking around the docs, there doesn't seem to be anything related
to MCLK within the CSI section.
Furthermore, camera sensor bindings, such as for the OV5640, in fact
do have a property for a reference clock, which is called XCLK or
XVCLK.
Since the clock is already exported from the CCU, I suppose it's
just a matter of referencing the clock from the camera node, with
the proper pinctrl for that pin.
So to summarize, just ignore my comment about the missing MCLK. :)
ChenYu
^ permalink raw reply
* [PATCH] ARM64: dts: meson-gxl: add internal ethernet PHY irq
From: Jerome Brunet @ 2017-12-18 10:27 UTC (permalink / raw)
To: linux-arm-kernel
Add the interrupt of the internal ethernet PHY
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
---
Hi Kevin,
This changes depends on the net-next changes adding interrupt support [0].
It is really important that this change is not merged before its
dependency.
If it is merged before, instead of polling, the phy would wait for an
interrupt which has not been configured and will never fire.
Tested on the libretech-cc and khadas VIM.
Cheers
Jerome
https://lkml.kernel.org/r/20171218094446.31912-7-jbrunet at baylibre.com
arch/arm64/boot/dts/amlogic/meson-gxl.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi
index 4a316a11a00e..8bc404508a4f 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi
@@ -631,6 +631,7 @@
internal_phy: ethernet-phy at 8 {
compatible = "ethernet-phy-id0181.4400", "ethernet-phy-ieee802.3-c22";
+ interrupts = <GIC_SPI 9 IRQ_TYPE_LEVEL_HIGH>;
reg = <8>;
max-speed = <100>;
};
--
2.14.3
^ permalink raw reply related
* pxa3xx_nand times out in 4.14 with JFFS2
From: Miquel RAYNAL @ 2017-12-18 10:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171218070617.GA16559@1wt.eu>
Hello Willy,
On Mon, 18 Dec 2017 08:06:17 +0100
Willy Tarreau <w@1wt.eu> wrote:
> On Mon, Dec 18, 2017 at 07:37:15AM +0100, Willy Tarreau wrote:
> > > As Boris said, we would really welcome a test of this branch,
> > > because you almost have the same setup as Sean in the thread
> > > "pxa3xx: wait time out when scanning for bb" and I am running out
> > > of explanation for his problem unless it is related to U-Boot. So
> > > if you could try booting with and without the on-flash-bbt
> > > property and report whether it fails or not it would be of great
> > > help!
> >
> > Yes, I noticed your work mentionned in some of the threads I've read
> > during my troubleshooting session and considered giving it a try.
> > I'll probably do this next week-end.
>
> Finally I figured the test was quick enough and could help you, so I
> built and booted it, I'm getting this at boot :
>
> marvell-nfc f10d0000.nand-controller: Timeout waiting for RB signal
> nand_bbt: error while writing BBT block -110
> marvell-nfc f10d0000.nand-controller: Timeout waiting for RB signal
> marvell-nfc f10d0000.nand-controller: Timeout waiting for RB signal
> nand_bbt: error -110 while marking block 1023 bad
> marvell-nfc f10d0000.nand-controller: Timeout waiting for RB signal
> nand_bbt: error while writing BBT block -110
> marvell-nfc f10d0000.nand-controller: Timeout waiting for RB signal
> marvell-nfc f10d0000.nand-controller: Timeout waiting for RB signal
Thanks for testing.
I fixed two problems happening during read/write of 2kiB page NAND
chips, I am quite confident this would solve the issues you report
here. Could you please give it a try?
Same branch as before [1], just some more fixups! on it :)
Thank you,
Miqu?l
[1] https://github.com/miquelraynal/linux/tree/marvell/nand-next/nfc
^ permalink raw reply
* [PATCH 04/25] arm: exynos/s3c: dts: Remove leading 0x and 0s from bindings notation
From: Mathieu Malaterre @ 2017-12-18 10:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAJKOXPdkYLisej5965rh2SbOjbFms-RK2VnXt=L==MW_JcA+OA@mail.gmail.com>
On Mon, Dec 18, 2017 at 10:40 AM, Krzysztof Kozlowski <krzk@kernel.org> wrote:
> On Fri, Dec 15, 2017 at 1:46 PM, Mathieu Malaterre <malat@debian.org> wrote:
>> Improve the DTS files by removing all the leading "0x" and zeros to fix the
>> following dtc warnings:
>>
>> Warning (unit_address_format): Node /XXX unit name should not have leading "0x"
>>
>> and
>>
>> Warning (unit_address_format): Node /XXX unit name should not have leading 0s
>>
>> Converted using the following command:
>>
>> find . -type f \( -iname *.dts -o -iname *.dtsi \) -exec sed -i -e "s/@\([0-9a-fA-FxX\.;:#]+\)\s*{/@\L\1 {/g" -e "s/@0x\(.*\) {/@\1 {/g" -e "s/@0+\(.*\) {/@\1 {/g" {} +^C
>>
>> For simplicity, two sed expressions were used to solve each warnings separately.
>>
>> To make the regex expression more robust a few other issues were resolved,
>> namely setting unit-address to lower case, and adding a whitespace before the
>> the opening curly brace:
>>
>> https://elinux.org/Device_Tree_Linux#Linux_conventions
>>
>> This will solve as a side effect warning:
>>
>> Warning (simple_bus_reg): Node /XXX@<UPPER> simple-bus unit address format error, expected "<lower>"
>>
>> This is a follow up to commit 4c9847b7375a ("dt-bindings: Remove leading 0x from bindings notation")
>>
>> Reported-by: David Daney <ddaney@caviumnetworks.com>
>> Suggested-by: Rob Herring <robh@kernel.org>
>> Acked-by: Krzysztof Kozlowski <krzk@kernel.org>
>
> Ack was for different patchset, touching only three files...
So sorry, when I read your email:
https://lkml.org/lkml/2017/12/15/152
I assumed you meant for all the Exynos* and S3C* DTS files, but I did
not check carefully which files were touched originally.
>> Signed-off-by: Mathieu Malaterre <malat@debian.org>
>> ---
>> arch/arm/boot/dts/exynos3250.dtsi | 34 ++++++------
>> arch/arm/boot/dts/exynos4.dtsi | 56 +++++++++----------
>> arch/arm/boot/dts/exynos4210.dtsi | 8 +--
>> arch/arm/boot/dts/exynos4412-pinctrl.dtsi | 2 +-
>> arch/arm/boot/dts/exynos4412.dtsi | 22 ++++----
>> arch/arm/boot/dts/exynos5.dtsi | 22 ++++----
>> arch/arm/boot/dts/exynos5250.dtsi | 64 +++++++++++-----------
>> arch/arm/boot/dts/exynos5260.dtsi | 26 ++++-----
>> arch/arm/boot/dts/exynos5420.dtsi | 78 +++++++++++++--------------
>> arch/arm/boot/dts/exynos5422-odroid-core.dtsi | 2 +-
>> arch/arm/boot/dts/exynos5440.dtsi | 14 ++---
>> arch/arm/boot/dts/s3c2416.dtsi | 8 +--
>> 12 files changed, 168 insertions(+), 168 deletions(-)
>>
>> diff --git a/arch/arm/boot/dts/exynos3250.dtsi b/arch/arm/boot/dts/exynos3250.dtsi
>> index 2bd3872221a1..8d47571b3984 100644
>> --- a/arch/arm/boot/dts/exynos3250.dtsi
>> +++ b/arch/arm/boot/dts/exynos3250.dtsi
>> @@ -164,31 +164,31 @@
>> syscon = <&pmu_system_controller>;
>> };
>>
>> - pd_cam: cam-power-domain at 10023C00 {
>> + pd_cam: cam-power-domain at 10023c00 {
>
> This is not related to this patch and it was not present in the
> version I acked. I also already fixed this here:
> https://patchwork.kernel.org/patch/10113323/
>
> There is no changelog explaining the difference in patches. Original
> patch was okay, why changing it?
Accept my sincere apologizes I really messed this series. I discover
my original ARM patch did not apply lower case to all unit-address
equally, so I added at last minute a sed expression to make all
unit-address lower case.
I guess you can just drop this one for now.
-M
^ 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