Re: [PATCH 2/3] dt-bindings: clock: ti: remove unstable remark
* Stephen Boyd [240228 22:59]: > +Tony > > Quoting Krzysztof Kozlowski (2024-02-24 01:12:35) > > Several TI SoC clock bindings were marked as work-in-progress / unstable > > between 2013-2016, for example in commit f60b1ea5ea7a ("CLK: TI: add > > support for gate clock"). It was enough of time to consider them stable > > and expect usual ABI rules. > > > > Signed-off-by: Krzysztof Kozlowski > > --- > > Acked-by: Stephen Boyd Makes sense to me: Acked-by: Tony Lindgren
Re: droid4 -- weird behaviour when attempting to use usb host
* Pavel Machek [230925 14:36]: > Hi! > > I'm having some fun with usb host. Good news is it works with > externally powered hub... after a while. I get some error messages > about inability to go host mode, but with enough patience it > eventually does enter host mode and I see my keyboard/mouse. > > And usually in that process, one of my cpu cores disappear. top no > longer shows 2 cores, and I was wondering for a while if d4 is > single-core system. It is not, my two cores are back after reboot. > > That's with 6.1.9 kernel from leste. Ideas how to debug this would be > welcome. (Do you use usb host?) You are using a "proper" non-standard usb micro-b cable that grounds the id pin, right? If not, try with one of those as it allows the hardware to do what it's supposed to do. And presumably you don't have a hacked usb hub that feeds back the vbus to your phone, right? If you have, that should not be used as the pmic can feed vbus. Regards, Tony
Re: [PATCH 0/2] fdt: translate address if #size-cells = <0>
* Dario Binacchi [210414 20:40]: > > Il 12/04/2021 09:41 Tero Kristo ha scritto: > > The change on the DT itself would be pretty large, removing all clock > > nodes and modifying any existing handles towards the clock nodes, and > > this would impact all OMAP architectures. > > > > Anyways, it is mostly up-to Tony how he wants to see the DT change, as > > he is the maintainer for the OMAP family DT data. While I think all the clocks should use a similar binding to the clkctrl binding, I don't know if it makes sense to start changing things around at such a large scale. Certainly if somebody does the patches and they can be tested to not cause regressions, sure why not :) > > I am just raising the opinion here that from kernel point of view, > > adding the missing size cells seems unnecessary, and I can't see why > > u-boot can't be changed to support the existing broken DT. It is broken > > now, and it will be broken with the addition of the size cells in place, > > and the actual "neat" end result would be to get rid of the clock nodes > > completely. > > I'll fix U-boot. > Thanks for your explanations. > Hope for SSC patch review from you and/or some TI MAINTAINER. Best to fix the issues first, then make any clean-up patches a separate series. Regards, Tony
[PATCH] clocksource/drivers/timer-ti-dm: Save and restore timer TIOCP_CFG
As we are using cpu_pm to save and restore context, we must also save and restore the timer sysconfig register TIOCP_CFG. This is needed because we are not calling PM runtime functions at all with cpu_pm. Fixes: b34677b0999a ("clocksource/drivers/timer-ti-dm: Implement cpu_pm notifier for context save and restore") Cc: Aaro Koskinen Cc: Adam Ford Cc: Andreas Kemnade Cc: Lokesh Vutla Cc: Peter Ujfalusi Signed-off-by: Tony Lindgren --- drivers/clocksource/timer-ti-dm.c | 6 ++ include/clocksource/timer-ti-dm.h | 1 + 2 files changed, 7 insertions(+) diff --git a/drivers/clocksource/timer-ti-dm.c b/drivers/clocksource/timer-ti-dm.c --- a/drivers/clocksource/timer-ti-dm.c +++ b/drivers/clocksource/timer-ti-dm.c @@ -78,6 +78,9 @@ static void omap_dm_timer_write_reg(struct omap_dm_timer *timer, u32 reg, static void omap_timer_restore_context(struct omap_dm_timer *timer) { + __omap_dm_timer_write(timer, OMAP_TIMER_OCP_CFG_OFFSET, + timer->context.ocp_cfg, 0); + omap_dm_timer_write_reg(timer, OMAP_TIMER_WAKEUP_EN_REG, timer->context.twer); omap_dm_timer_write_reg(timer, OMAP_TIMER_COUNTER_REG, @@ -95,6 +98,9 @@ static void omap_timer_restore_context(struct omap_dm_timer *timer) static void omap_timer_save_context(struct omap_dm_timer *timer) { + timer->context.ocp_cfg = + __omap_dm_timer_read(timer, OMAP_TIMER_OCP_CFG_OFFSET, 0); + timer->context.tclr = omap_dm_timer_read_reg(timer, OMAP_TIMER_CTRL_REG); timer->context.twer = diff --git a/include/clocksource/timer-ti-dm.h b/include/clocksource/timer-ti-dm.h --- a/include/clocksource/timer-ti-dm.h +++ b/include/clocksource/timer-ti-dm.h @@ -74,6 +74,7 @@ #define OMAP_TIMER_ERRATA_I103_I7670x8000 struct timer_regs { + u32 ocp_cfg; u32 tidr; u32 tier; u32 twer; -- 2.31.1
[tip: timers/core] clocksource/drivers/timer-ti-dm: Add missing set_state_oneshot_stopped
The following commit has been merged into the timers/core branch of tip: Commit-ID: ac4daf737674b4d29e19b7c300caff3bcf7160d8 Gitweb: https://git.kernel.org/tip/ac4daf737674b4d29e19b7c300caff3bcf7160d8 Author:Tony Lindgren AuthorDate:Thu, 04 Mar 2021 09:21:35 +02:00 Committer: Daniel Lezcano CommitterDate: Thu, 08 Apr 2021 13:23:47 +02:00 clocksource/drivers/timer-ti-dm: Add missing set_state_oneshot_stopped To avoid spurious timer interrupts when KTIME_MAX is used, we need to configure set_state_oneshot_stopped(). Although implementing this is optional, it still affects things like power management for the extra timer interrupt. For more information, please see commit 8fff52fd5093 ("clockevents: Introduce CLOCK_EVT_STATE_ONESHOT_STOPPED state") and commit cf8c5009ee37 ("clockevents/drivers/arm_arch_timer: Implement ->set_state_oneshot_stopped()"). Fixes: 52762fbd1c47 ("clocksource/drivers/timer-ti-dm: Add clockevent and clocksource support") Signed-off-by: Tony Lindgren Signed-off-by: Daniel Lezcano Link: https://lore.kernel.org/r/20210304072135.52712-4-t...@atomide.com --- drivers/clocksource/timer-ti-dm-systimer.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/clocksource/timer-ti-dm-systimer.c b/drivers/clocksource/timer-ti-dm-systimer.c index 3a65434..186a599 100644 --- a/drivers/clocksource/timer-ti-dm-systimer.c +++ b/drivers/clocksource/timer-ti-dm-systimer.c @@ -554,6 +554,7 @@ static int __init dmtimer_clockevent_init(struct device_node *np) dev->set_state_shutdown = dmtimer_clockevent_shutdown; dev->set_state_periodic = dmtimer_set_periodic; dev->set_state_oneshot = dmtimer_clockevent_shutdown; + dev->set_state_oneshot_stopped = dmtimer_clockevent_shutdown; dev->tick_resume = dmtimer_clockevent_shutdown; dev->cpumask = cpu_possible_mask;
[tip: timers/core] clocksource/drivers/timer-ti-dm: Fix posted mode status check order
The following commit has been merged into the timers/core branch of tip: Commit-ID: 212709926c5493a566ca4086ad4f4b0d4e66b553 Gitweb: https://git.kernel.org/tip/212709926c5493a566ca4086ad4f4b0d4e66b553 Author:Tony Lindgren AuthorDate:Thu, 04 Mar 2021 09:21:33 +02:00 Committer: Daniel Lezcano CommitterDate: Thu, 08 Apr 2021 13:23:41 +02:00 clocksource/drivers/timer-ti-dm: Fix posted mode status check order When the timer is configured in posted mode, we need to check the write- posted status register (TWPS) before writing to the register. We now check TWPS after the write starting with commit 52762fbd1c47 ("clocksource/drivers/timer-ti-dm: Add clockevent and clocksource support"). For example, in the TRM for am571x the following is documented in chapter "22.2.4.13.1.1 Write Posting Synchronization Mode": "For each register, a status bit is provided in the timer write-posted status (TWPS) register. In this mode, it is mandatory that software check this status bit before any write access. If a write is attempted to a register with a previous access pending, the previous access is discarded without notice." The regression happened when I updated the code to use standard read/write accessors for the driver instead of using __omap_dm_timer_load_start(). We have__omap_dm_timer_load_start() check the TWPS status correctly using __omap_dm_timer_write(). Fixes: 52762fbd1c47 ("clocksource/drivers/timer-ti-dm: Add clockevent and clocksource support") Signed-off-by: Tony Lindgren Signed-off-by: Daniel Lezcano Link: https://lore.kernel.org/r/20210304072135.52712-2-t...@atomide.com --- drivers/clocksource/timer-ti-dm-systimer.c | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/drivers/clocksource/timer-ti-dm-systimer.c b/drivers/clocksource/timer-ti-dm-systimer.c index 614c838..3a65434 100644 --- a/drivers/clocksource/timer-ti-dm-systimer.c +++ b/drivers/clocksource/timer-ti-dm-systimer.c @@ -449,13 +449,13 @@ static int dmtimer_set_next_event(unsigned long cycles, struct dmtimer_systimer *t = >t; void __iomem *pend = t->base + t->pend; - writel_relaxed(0x - cycles, t->base + t->counter); while (readl_relaxed(pend) & WP_TCRR) cpu_relax(); + writel_relaxed(0x - cycles, t->base + t->counter); - writel_relaxed(OMAP_TIMER_CTRL_ST, t->base + t->ctrl); while (readl_relaxed(pend) & WP_TCLR) cpu_relax(); + writel_relaxed(OMAP_TIMER_CTRL_ST, t->base + t->ctrl); return 0; } @@ -490,18 +490,18 @@ static int dmtimer_set_periodic(struct clock_event_device *evt) dmtimer_clockevent_shutdown(evt); /* Looks like we need to first set the load value separately */ - writel_relaxed(clkevt->period, t->base + t->load); while (readl_relaxed(pend) & WP_TLDR) cpu_relax(); + writel_relaxed(clkevt->period, t->base + t->load); - writel_relaxed(clkevt->period, t->base + t->counter); while (readl_relaxed(pend) & WP_TCRR) cpu_relax(); + writel_relaxed(clkevt->period, t->base + t->counter); - writel_relaxed(OMAP_TIMER_CTRL_AR | OMAP_TIMER_CTRL_ST, - t->base + t->ctrl); while (readl_relaxed(pend) & WP_TCLR) cpu_relax(); + writel_relaxed(OMAP_TIMER_CTRL_AR | OMAP_TIMER_CTRL_ST, + t->base + t->ctrl); return 0; }
[tip: timers/core] clocksource/drivers/timer-ti-dm: Prepare to handle dra7 timer wrap issue
The following commit has been merged into the timers/core branch of tip: Commit-ID: 3efe7a878a11c13b5297057bfc1e5639ce1241ce Gitweb: https://git.kernel.org/tip/3efe7a878a11c13b5297057bfc1e5639ce1241ce Author:Tony Lindgren AuthorDate:Tue, 23 Mar 2021 09:43:25 +02:00 Committer: Daniel Lezcano CommitterDate: Thu, 08 Apr 2021 16:15:54 +02:00 clocksource/drivers/timer-ti-dm: Prepare to handle dra7 timer wrap issue There is a timer wrap issue on dra7 for the ARM architected timer. In a typical clock configuration the timer fails to wrap after 388 days. To work around the issue, we need to use timer-ti-dm timers instead. Let's prepare for adding support for percpu timers by adding a common dmtimer_clkevt_init_common() and call it from dmtimer_clockevent_init(). This patch makes no intentional functional changes. Signed-off-by: Tony Lindgren Signed-off-by: Daniel Lezcano Link: https://lore.kernel.org/r/20210323074326.28302-2-t...@atomide.com --- drivers/clocksource/timer-ti-dm-systimer.c | 66 + 1 file changed, 43 insertions(+), 23 deletions(-) diff --git a/drivers/clocksource/timer-ti-dm-systimer.c b/drivers/clocksource/timer-ti-dm-systimer.c index 186a599..3308031 100644 --- a/drivers/clocksource/timer-ti-dm-systimer.c +++ b/drivers/clocksource/timer-ti-dm-systimer.c @@ -530,17 +530,17 @@ static void omap_clockevent_unidle(struct clock_event_device *evt) writel_relaxed(OMAP_TIMER_INT_OVERFLOW, t->base + t->wakeup); } -static int __init dmtimer_clockevent_init(struct device_node *np) +static int __init dmtimer_clkevt_init_common(struct dmtimer_clockevent *clkevt, +struct device_node *np, +unsigned int features, +const struct cpumask *cpumask, +const char *name, +int rating) { - struct dmtimer_clockevent *clkevt; struct clock_event_device *dev; struct dmtimer_systimer *t; int error; - clkevt = kzalloc(sizeof(*clkevt), GFP_KERNEL); - if (!clkevt) - return -ENOMEM; - t = >t; dev = >dev; @@ -548,25 +548,23 @@ static int __init dmtimer_clockevent_init(struct device_node *np) * We mostly use cpuidle_coupled with ARM local timers for runtime, * so there's probably no use for CLOCK_EVT_FEAT_DYNIRQ here. */ - dev->features = CLOCK_EVT_FEAT_PERIODIC | CLOCK_EVT_FEAT_ONESHOT; - dev->rating = 300; + dev->features = features; + dev->rating = rating; dev->set_next_event = dmtimer_set_next_event; dev->set_state_shutdown = dmtimer_clockevent_shutdown; dev->set_state_periodic = dmtimer_set_periodic; dev->set_state_oneshot = dmtimer_clockevent_shutdown; dev->set_state_oneshot_stopped = dmtimer_clockevent_shutdown; dev->tick_resume = dmtimer_clockevent_shutdown; - dev->cpumask = cpu_possible_mask; + dev->cpumask = cpumask; dev->irq = irq_of_parse_and_map(np, 0); - if (!dev->irq) { - error = -ENXIO; - goto err_out_free; - } + if (!dev->irq) + return -ENXIO; error = dmtimer_systimer_setup(np, >t); if (error) - goto err_out_free; + return error; clkevt->period = 0x - DIV_ROUND_CLOSEST(t->rate, HZ); @@ -578,32 +576,54 @@ static int __init dmtimer_clockevent_init(struct device_node *np) writel_relaxed(OMAP_TIMER_CTRL_POSTED, t->base + t->ifctrl); error = request_irq(dev->irq, dmtimer_clockevent_interrupt, - IRQF_TIMER, "clockevent", clkevt); + IRQF_TIMER, name, clkevt); if (error) goto err_out_unmap; writel_relaxed(OMAP_TIMER_INT_OVERFLOW, t->base + t->irq_ena); writel_relaxed(OMAP_TIMER_INT_OVERFLOW, t->base + t->wakeup); - pr_info("TI gptimer clockevent: %s%lu Hz at %pOF\n", - of_find_property(np, "ti,timer-alwon", NULL) ? + pr_info("TI gptimer %s: %s%lu Hz at %pOF\n", + name, of_find_property(np, "ti,timer-alwon", NULL) ? "always-on " : "", t->rate, np->parent); - clockevents_config_and_register(dev, t->rate, + return 0; + +err_out_unmap: + iounmap(t->base); + + return error; +} + +static int __init dmtimer_clockevent_init(struct device_node *np) +{ + struct dmtimer_clockevent *clkevt; + int error; + + clkevt = kzalloc(sizeof(*clkevt), GFP_KERNEL); + if (!clkevt) + return -ENOMEM; + + error = dmti
[tip: timers/core] clocksource/drivers/timer-ti-dm: Handle dra7 timer wrap errata i940
The following commit has been merged into the timers/core branch of tip: Commit-ID: 25de4ce5ed02994aea8bc111d133308f6fd62566 Gitweb: https://git.kernel.org/tip/25de4ce5ed02994aea8bc111d133308f6fd62566 Author:Tony Lindgren AuthorDate:Tue, 23 Mar 2021 09:43:26 +02:00 Committer: Daniel Lezcano CommitterDate: Thu, 08 Apr 2021 16:41:18 +02:00 clocksource/drivers/timer-ti-dm: Handle dra7 timer wrap errata i940 There is a timer wrap issue on dra7 for the ARM architected timer. In a typical clock configuration the timer fails to wrap after 388 days. To work around the issue, we need to use timer-ti-dm percpu timers instead. Let's configure dmtimer3 and 4 as percpu timers by default, and warn about the issue if the dtb is not configured properly. Let's do this as a single patch so it can be backported to v5.8 and later kernels easily. Note that this patch depends on earlier timer-ti-dm systimer posted mode fixes, and a preparatory clockevent patch "clocksource/drivers/timer-ti-dm: Prepare to handle dra7 timer wrap issue". For more information, please see the errata for "AM572x Sitara Processors Silicon Revisions 1.1, 2.0": https://www.ti.com/lit/er/sprz429m/sprz429m.pdf The concept is based on earlier reference patches done by Tero Kristo and Keerthy. Cc: Keerthy Cc: Tero Kristo Signed-off-by: Tony Lindgren Signed-off-by: Daniel Lezcano Link: https://lore.kernel.org/r/20210323074326.28302-3-t...@atomide.com --- arch/arm/boot/dts/dra7-l4.dtsi | 4 +- arch/arm/boot/dts/dra7.dtsi| 20 ++- drivers/clocksource/timer-ti-dm-systimer.c | 76 +- include/linux/cpuhotplug.h | 1 +- 4 files changed, 99 insertions(+), 2 deletions(-) diff --git a/arch/arm/boot/dts/dra7-l4.dtsi b/arch/arm/boot/dts/dra7-l4.dtsi index 3bf90d9..a294a02 100644 --- a/arch/arm/boot/dts/dra7-l4.dtsi +++ b/arch/arm/boot/dts/dra7-l4.dtsi @@ -1168,7 +1168,7 @@ }; }; - target-module@34000 { /* 0x48034000, ap 7 46.0 */ + timer3_target: target-module@34000 {/* 0x48034000, ap 7 46.0 */ compatible = "ti,sysc-omap4-timer", "ti,sysc"; reg = <0x34000 0x4>, <0x34010 0x4>; @@ -1195,7 +1195,7 @@ }; }; - target-module@36000 { /* 0x48036000, ap 9 4e.0 */ + timer4_target: target-module@36000 {/* 0x48036000, ap 9 4e.0 */ compatible = "ti,sysc-omap4-timer", "ti,sysc"; reg = <0x36000 0x4>, <0x36010 0x4>; diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi index ce11947..53d6878 100644 --- a/arch/arm/boot/dts/dra7.dtsi +++ b/arch/arm/boot/dts/dra7.dtsi @@ -46,6 +46,7 @@ timer { compatible = "arm,armv7-timer"; + status = "disabled";/* See ARM architected timer wrap erratum i940 */ interrupts = , , , @@ -1241,3 +1242,22 @@ assigned-clock-parents = <_32k_ck>; }; }; + +/* Local timers, see ARM architected timer wrap erratum i940 */ +_target { + ti,no-reset-on-init; + ti,no-idle; + timer@0 { + assigned-clocks = <_clkctrl DRA7_L4PER_TIMER3_CLKCTRL 24>; + assigned-clock-parents = <_sys_clk_div>; + }; +}; + +_target { + ti,no-reset-on-init; + ti,no-idle; + timer@0 { + assigned-clocks = <_clkctrl DRA7_L4PER_TIMER4_CLKCTRL 24>; + assigned-clock-parents = <_sys_clk_div>; + }; +}; diff --git a/drivers/clocksource/timer-ti-dm-systimer.c b/drivers/clocksource/timer-ti-dm-systimer.c index 3308031..b6f9796 100644 --- a/drivers/clocksource/timer-ti-dm-systimer.c +++ b/drivers/clocksource/timer-ti-dm-systimer.c @@ -2,6 +2,7 @@ #include #include #include +#include #include #include #include @@ -630,6 +631,78 @@ err_out_free: return error; } +/* Dmtimer as percpu timer. See dra7 ARM architected timer wrap erratum i940 */ +static DEFINE_PER_CPU(struct dmtimer_clockevent, dmtimer_percpu_timer); + +static int __init dmtimer_percpu_timer_init(struct device_node *np, int cpu) +{ + struct dmtimer_clockevent *clkevt; + int error; + + if (!cpu_possible(cpu)) + return -EINVAL; + + if (!of_property_read_bool(np->parent, "ti,no-reset-on-init") || + !of_property_read_bool(np->parent, "ti,no-idle")) + pr_warn("Incomplete dtb for percpu dmtimer %pOF\n", np->parent); + + clkevt = per_cpu_ptr(_per
Re: [PATCH 1/6] PM: runtime: enable wake irq after runtime_suspend hook called
* Ikjoon Jang [210409 05:33]: > Hi Chunfeng, > > On Thu, Apr 8, 2021 at 5:35 PM Chunfeng Yun wrote: > > > > When the dedicated wake irq is level trigger, enable it before > > calling runtime_suspend, will trigger an interrupt. > > > > e.g. > > for a low level trigger type, it's low level at running time (0), > > and becomes high level when enters suspend (runtime_suspend (1) is > > called), a wakeup signal at (2) make it become low level, wake irq > > will be triggered. > > > > -- > >| ^ ^| > > | | -- > > |<---(0)--->|<--(1)--| (3) (2)(4) > > > > Can't we just use a falling edge type for this irq line? Sounds reasonable to me :) Tony
Re: [PATCH 1/6] PM: runtime: enable wake irq after runtime_suspend hook called
* Chunfeng Yun [210409 01:54]: > On Thu, 2021-04-08 at 19:41 +0200, Rafael J. Wysocki wrote: > > On Thu, Apr 8, 2021 at 11:35 AM Chunfeng Yun > > wrote: > > > > > > When the dedicated wake irq is level trigger, enable it before > > > calling runtime_suspend, will trigger an interrupt. > > > > > > e.g. > > > for a low level trigger type, it's low level at running time (0), > > > and becomes high level when enters suspend (runtime_suspend (1) is > > > called), a wakeup signal at (2) make it become low level, wake irq > > > will be triggered. > > > > > > -- > > >| ^ ^| > > > | | -- > > > |<---(0)--->|<--(1)--| (3) (2)(4) > > > > > > if we enable the wake irq before calling runtime_suspend during (0), > > > an interrupt will arise, it causes resume immediately; > > > > But that's necessary to avoid missing a wakeup interrupt, isn't it? > That's also what I worry about. Yeah sounds like this patch will lead into missed wakeirqs. Regards, Tony
Re: [PATCH] i2c: omap: Fix rumtime PM imbalance on error
* Vignesh Raghavendra [210407 07:46]: > Hi, > > On 4/7/21 11:57 AM, Tony Lindgren wrote: > > * Vignesh Raghavendra [210407 06:20]: > >> Do we need a Fixes: tag to enable stable backports? > > > > Well pm_runtime_resume_and_get() was introduced quite recently, and > > we already handle the error and bail out. And likely after an error > > not much works anyways :) So it might be better to add just a stable > > tag v5.10 and later as further backports are not likely needed. > > > > Agree this is not a critical patch for backport. But I do know that > pm_runtime_resume_and_get() is backported to v5.4 stable kernel at least > [1]. So stable tag with v5.4 perhaps would probably help tools looking > for patches to backport. OK no objections to adding a fixes tag. Regards, Tony > [1] https://lkml.org/lkml/2020/12/28/588
Re: [PATCH] i2c: omap: Fix rumtime PM imbalance on error
* Vignesh Raghavendra [210407 06:20]: > Do we need a Fixes: tag to enable stable backports? Well pm_runtime_resume_and_get() was introduced quite recently, and we already handle the error and bail out. And likely after an error not much works anyways :) So it might be better to add just a stable tag v5.10 and later as further backports are not likely needed. Naturally nothing stopping doing separate backports if really needed though. Regards, Tony
Re: [PATCH] i2c: omap: Fix rumtime PM imbalance on error
* Dinghao Liu [210407 03:31]: > pm_runtime_get_sync() will increase the rumtime PM counter > even it returns an error. Thus a pairing decrement is needed > to prevent refcount leak. Fix this by replacing this API with > pm_runtime_resume_and_get(), which will not change the runtime > PM counter on error. > > Signed-off-by: Dinghao Liu Reviewed-by: Tony Lindgren > --- > drivers/i2c/busses/i2c-omap.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c > index 12ac4212aded..c9ee0875a79d 100644 > --- a/drivers/i2c/busses/i2c-omap.c > +++ b/drivers/i2c/busses/i2c-omap.c > @@ -1404,7 +1404,7 @@ omap_i2c_probe(struct platform_device *pdev) > pm_runtime_set_autosuspend_delay(omap->dev, OMAP_I2C_PM_TIMEOUT); > pm_runtime_use_autosuspend(omap->dev); > > - r = pm_runtime_get_sync(omap->dev); > + r = pm_runtime_resume_and_get(omap->dev); > if (r < 0) > goto err_free_mem; > > -- > 2.17.1 >
Re: [PATCH] Input: gpio-keys - fix crash when disabliing GPIO-less buttons
* Dmitry Torokhov [210407 05:30]: > My brain-damaged adjustments to Paul's patch caused crashes in > gpio_keys_disable_button() when driver is used in GPIO-less (i.e. > purely interrupt-driven) setups, because I mixed together debounce and > release timers when they are in fact separate: > > Unable to handle kernel NULL pointer dereference at virtual address 000c > ... > PC is at hrtimer_active+0xc/0x98 > LR is at hrtimer_try_to_cancel+0x24/0x140 > ... > [] (hrtimer_active) from [] > (hrtimer_try_to_cancel+0x24/0x140) > [] (hrtimer_try_to_cancel) from [] > (hrtimer_cancel+0x14/0x4c) > [] (hrtimer_cancel) from [] > (gpio_keys_attr_store_helper+0x1b8/0x1d8 [gpio_keys]) > [] (gpio_keys_attr_store_helper [gpio_keys]) from [] > (gpio_keys_store_disabled_keys+0x18/0x24 [gpio_keys]) > [] (gpio_keys_store_disabled_keys [gpio_keys]) from [] > (kernfs_fop_write_iter+0x10c/0x1cc) > [] (kernfs_fop_write_iter) from [] (vfs_write+0x2ac/0x404) > [] (vfs_write) from [] (ksys_write+0x64/0xdc) > [] (ksys_write) from [] (ret_fast_syscall+0x0/0x58) > > Let's fix it up. > > Fixes: c9efb0ba281e ("Input: gpio-keys - use hrtimer for software debounce, > if possible") > Reported-by: Tony Lindgren > Signed-off-by: Dmitry Torokhov > --- > > Tony, could you please try this patch and see if it fixes the crash you > observed? Yes great, thanks this works for me: Tested-by: Tony Lindgren
Re: [PATCH v3 3/3] input: gpio-keys: Use hrtimer for software debounce, if possible
Hi, * Dmitry Torokhov [700101 02:00]: > On Sun, Mar 07, 2021 at 10:22:40PM +, Paul Cercueil wrote: > > We want to be able to report the input event as soon as the debounce > > delay elapsed. However, the current code does not really ensure that, > > as it uses the jiffies-based schedule_delayed_work() API. With a small > > enough HZ value (HZ <= 100), this results in some input events being > > lost, when a key is quickly pressed then released (on a human's time > > scale). > > > > Switching to hrtimers fixes this issue, and will work even on extremely > > low HZ values (tested at HZ=24). This is however only possible if > > reading the GPIO is possible without sleeping. If this condition is not > > met, the previous approach of using a jiffies-based timer is taken. > > > > Signed-off-by: Paul Cercueil > > Applied with minor edits to make more use of debounce_use_hrtimer flag. While testing Linux next I noticed that this patch causes a null pointer dereference at least when unbinding a gpio-keys instance, see below. Regards, Tony 8< - Unable to handle kernel NULL pointer dereference at virtual address 000c ... PC is at hrtimer_active+0xc/0x98 LR is at hrtimer_try_to_cancel+0x24/0x140 ... [] (hrtimer_active) from [] (hrtimer_try_to_cancel+0x24/0x140) [] (hrtimer_try_to_cancel) from [] (hrtimer_cancel+0x14/0x4c) [] (hrtimer_cancel) from [] (gpio_keys_attr_store_helper+0x1b8/0x1d8 [gpio_keys]) [] (gpio_keys_attr_store_helper [gpio_keys]) from [] (gpio_keys_store_disabled_keys+0x18/0x24 [gpio_keys]) [] (gpio_keys_store_disabled_keys [gpio_keys]) from [] (kernfs_fop_write_iter+0x10c/0x1cc) [] (kernfs_fop_write_iter) from [] (vfs_write+0x2ac/0x404) [] (vfs_write) from [] (ksys_write+0x64/0xdc) [] (ksys_write) from [] (ret_fast_syscall+0x0/0x58)
Re: [PATCH] MAINTAINERS: remove obsolete OMAP HWMOD DATA FOR OMAP4-BASED DEVICES
* Lukas Bulwahn [210318 19:26]: > Commit 2584d7e7f87a ("ARM: OMAP2+: Drop legacy platform data for omap4 > hwmod") drops the file ./arch/arm/mach-omap2/omap_hwmod_44xx_data.c, but > misses to drop the now obsolete OMAP HWMOD DATA FOR OMAP4-BASED DEVICES > section in MAINTAINERS, which refers to only that file. > > Hence, ./scripts/get_maintainer.pl --self-test=patterns complains: > > warning: no file matches F: arch/arm/mach-omap2/omap_hwmod_44xx_data.c > > Remove the obsolete OMAP HWMOD DATA FOR OMAP4-BASED DEVICES section. Thanks applying into omap-for-v5.13/genpd-cleanup. Tony
Re: arch/arm/mach-omap2/sr_device.c:207:51: warning: variable 'sr_inst' is uninitialized when used here
* kernel test robot [210327 05:06]: > >> arch/arm/mach-omap2/sr_device.c:207:51: warning: variable 'sr_inst' is > >> uninitialized when used here [-Wuninitialized] >name = kasprintf(GFP_KERNEL, "smartreflex_%s", > sr_inst[i]); > > ^~~ >arch/arm/mach-omap2/sr_device.c:191:29: note: initialize the variable > 'sr_inst' to silence this warning >const char * const *sr_inst; > ^ >= NULL >1 warning generated. Thanks for the report, FYI I posted a fix for this at: https://lore.kernel.org/linux-omap/20210331063556.30654-1-t...@atomide.com/T/#u Regards, Tony
Re: [PATCH 03/12] ARM: omap1: osk: Constify the software node
* Heikki Krogerus [210329 10:51]: > Additional device properties are always just a part of a > software fwnode. If the device properties are constant, the > software node can also be constant. > > Signed-off-by: Heikki Krogerus > Cc: Aaro Koskinen > Cc: Tony Lindgren Probably best to merge this via the rest of the series: Acked-by: Tony Lindgren > --- > arch/arm/mach-omap1/board-osk.c | 6 +- > 1 file changed, 5 insertions(+), 1 deletion(-) > > diff --git a/arch/arm/mach-omap1/board-osk.c b/arch/arm/mach-omap1/board-osk.c > index 0a4c9b0b13b0c..e18b6f13300eb 100644 > --- a/arch/arm/mach-omap1/board-osk.c > +++ b/arch/arm/mach-omap1/board-osk.c > @@ -332,11 +332,15 @@ static const struct property_entry > mistral_at24_properties[] = { > { } > }; > > +static const struct software_node mistral_at24_node = { > + .properties = mistral_at24_properties, > +}; > + > static struct i2c_board_info __initdata mistral_i2c_board_info[] = { > { > /* NOTE: powered from LCD supply */ > I2C_BOARD_INFO("24c04", 0x50), > - .properties = mistral_at24_properties, > + .swnode = _at24_node, > }, > /* TODO when driver support is ready: >* - optionally ov9640 camera sensor at 0x30 > -- > 2.30.2 >
Re: [PATCH] ARM: OMAP2+: fix incorrect kernel-doc comment syntax in file
* Aditya Srivastava [210331 00:00]: > The opening comment mark '/**' is used for highlighting the beginning of > kernel-doc comments. > The header for arch/arm/mach-omap2/omap_twl.c follows this syntax, but the > content inside does not comply with kernel-doc. > > This line was probably not meant for kernel-doc parsing, but is parsed > due to the presence of kernel-doc like comment syntax(i.e, '/**'), which > causes unexpected warning from kernel-doc: > "warning: wrong kernel-doc identifier on line: > * OMAP and TWL PMIC specific initializations." > > Provide a simple fix by replacing this occurrence with general comment > format, i.e. '/*', to prevent kernel-doc from parsing it. Thanks applying into omap-for-v5.13/soc. Tony
Re: [PATCH] ARM: OMAP1: fix incorrect kernel-doc comment syntax in file
* Aditya Srivastava [210330 23:54]: > The opening comment mark '/**' is used for highlighting the beginning of > kernel-doc comments. > The header for arch/arm/mach-omap1/timer.c follows this syntax, but the > content inside does not comply with kernel-doc. > > This line was probably not meant for kernel-doc parsing, but is parsed > due to the presence of kernel-doc like comment syntax(i.e, '/**'), which > causes unexpected warning from kernel-doc: > "warning: expecting prototype for OMAP1 Dual(). Prototype was for > OMAP1610_GPTIMER1_BASE() instead" > > Provide a simple fix by replacing this occurrence with general comment > format, i.e. '/*', to prevent kernel-doc from parsing it. Thanks applying into omap-for-v5.13/soc. Tony
Re: [PATCH -next] ARM: OMAP: Use DEFINE_SPINLOCK() for spinlock
* Chen Lifu [210327 11:53]: > From: Lifu Chen > > spinlock can be initialized automatically with DEFINE_SPINLOCK() > rather than explicitly calling spin_lock_init(). Thanks applying into omap-for-v5.13/soc. Tony
Re: [PATCH] ARM: dts: am335x-boneblack.dts: unique gpio-line-names
* Drew Fustini [210325 00:25]: > Based on linux-gpio discussion [1], it is best practice to make the > gpio-line-names unique. Generic names like "[ethernet]" are replaced > with the name of the unique signal on the AM3358 SoC ball corresponding > to the gpio line. "[NC]" is also renamed to the standard "NC" name to > represent "not connected". Thanks applying into omap-for-v5.13/dt-v2. Tony
Re: [PATCH v3 0/4] clk: ti: add am33xx spread spectrum clock support
* Stephen Boyd [210330 02:25]: > Quoting Dario Binacchi (2021-03-29 09:42:17) > > > > As reported by the TI spruh73x RM, MPU and LCD modules support spread > > spectrum clocking (SSC) on their output clocks. SSC is used to spread > > the spectral peaking of the clock to reduce any electromagnetic > > interference (EMI) that may be caused due to the clock’s fundamental > > or any of its harmonics. > > The series allows you to enable and adjust the spread spectrum clocking > > for all am33xx PLLs for which it is supported. > > > > What is your merge strategy? Should all the patches go through clk tree? > Or you'll send via arm-soc? Probably best to just merge all via the clk tree as that's where most of the changes are. Regards, Tony
Re: [PATCH v4 3/3] pinctrl: pinctrl-single: fix pcs_pin_dbg_show() when bits_per_mux is not zero
* Hanna Hawa [700101 02:00]: > A System Error (SError, followed by kernel panic) was detected when > trying to print the supported pins in a pinctrl device which supports > multiple pins per register. This change fixes the pcs_pin_dbg_show() in > pinctrl-single driver when bits_per_mux is not zero. In addition move > offset calculation and pin offset in register to common function. Reviewed-by: Tony Lindgren
Re: [PATCH v4 2/3] pinctrl: pinctrl-single: remove unused parameter
* Hanna Hawa [700101 02:00]: > Remove unused parameter 'pin_pos' from pcs_add_pin(). Reviewed-by: Tony Lindgren
Re: [PATCH v4 1/3] pinctrl: pinctrl-single: remove unused variable
* Hanna Hawa [700101 02:00]: > Remove unused parameter 'num_pins_in_register' from > pcs_allocate_pin_table(). Reviewed-by: Tony Lindgren
Re: [PATCH] ARM: OMAP2+: use true and false for bool variable
* Yang Li [210315 09:06]: > fixed the following coccicheck: > ./arch/arm/mach-omap2/powerdomain.c:1205:9-10: WARNING: return of 0/1 in > function 'pwrdm_can_ever_lose_context' with return type bool Thanks applying into omap-for-v5.13/soc. Tony
Re: [PATCH v2 3/4] ARM: dts: am33xx-clocks: add spread spectrum support
* Dario Binacchi [210318 17:28]: > Registers for adjusting the spread spectrum clocking (SSC) have been > added. As reported by the TI spruh73x RM, SSC is supported only for > LCD and MPU PLLs. Probably best to keep the series together: Acked-by: Tony Lindgren
Re: [RESEND PATCH] ARM: dts: am33xx-l4: fix tscadc@0 node indentation
* Dario Binacchi [210314 17:17]: > Fix the broken indentation of tscadc@0 node. Applying into omap-for-v5.13/dt thanks. Tony
Re: [PATCH 1/2] ARM: dts: omap3-echo: Update LED configuration
* André Hentschel [210130 14:29]: > Changes made in 54212f5a1ba3123281877e54c1e5f672bf7563d8 and previous commits > broke with the way > the LED drivers were described in device-trees before. These adjustments fix > that. Thanks applying both into omap-for-v5.13/dt. Tony
Re: [PATCH 1/2] ARM: dts: am335x-pocketbeagle: unique gpio-line-names
Hi, * Drew Fustini [210127 02:04]: > Based on linux-gpio discussion [1], it is best practice to make the > gpio-line-names unique. Generic names like "[ethernet]" are replaced > with the name of the unique signal on the AM3358 SoC ball corresponding > to the gpio line. "[NC]" is also renamed to the standard "NC" name to > represent "not connected". Applying this one into omap-for-v5.13/dt thanks. However the second patch does not apply against v5.12-rc2, Drew can you please repost the second patch? Regards, Tony
Re: [PATCH -next] bus: ti-sysc: Use kzalloc for allocating only one thing
* Zheng Yongjun [201229 15:51]: > Use kzalloc rather than kcalloc(1,...) Thanks applying into omap-for-v5.13/ti-sysc. Tony
Re: [PATCH] ARM: OMAP2+: add missing call to of_node_put()
* Yang Li [210225 10:55]: > In one of the error paths of the for_each_child_of_node() loop, > add missing call to of_node_put(). Thanks applying into omap-for-v5.13/soc. Tony
Re: [PATCH] bus: ti-sysc: remove unneeded semicolon
* Yang Li [210202 09:00]: > Eliminate the following coccicheck warning: > ./drivers/bus/ti-sysc.c:1595:2-3: Unneeded semicolon > ./drivers/bus/ti-sysc.c:2833:3-4: Unneeded semicolon Thanks applying into omap-for-v5.13/ti-sysc. Tony
Re: [PATCH] arm: omap2: Replace DEFINE_SIMPLE_ATTRIBUTE with DEFINE_DEBUGFS_ATTRIBUTE
* Jiapeng Chong [210202 05:43]: > Fix the following coccicheck warning: > > ./arch/arm/mach-omap2/pm-debug.c:171:0-23: WARNING: pwrdm_suspend_fops > should be defined with DEFINE_DEBUGFS_ATTRIBUTE. Thanks applying into omap-for-v5.13/soc. Tony
Re: arch/arm/mach-omap2/board-generic.c:36:28: warning: no previous prototype for 'omap_init_time_of'
Hi, * kernel test robot [210226 13:11]: > Hi Tony, > > FYI, the error/warning still remains. Thanks for the report and sorry for the delay in responding. I've posted a fix for this at: https://lore.kernel.org/linux-omap/20210324105102.7286-1-t...@atomide.com/T/#u Regards, Tony > tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git > master > head: 2c87f7a38f930ef6f6a7bdd04aeb82ce3971b54b > commit: e69b4e1a7577c169e9f52edf977401734a6a29eb ARM: OMAP2+: Add > omap_init_time_of() > date: 9 months ago > config: arm-randconfig-r012-20210226 (attached as .config) > compiler: arm-linux-gnueabi-gcc (GCC) 9.3.0 > reproduce (this is a W=1 build): > wget > https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O > ~/bin/make.cross > chmod +x ~/bin/make.cross > # > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e69b4e1a7577c169e9f52edf977401734a6a29eb > git remote add linus > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git > git fetch --no-tags linus master > git checkout e69b4e1a7577c169e9f52edf977401734a6a29eb > # save the attached .config to linux build tree > COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross > ARCH=arm > > If you fix the issue, kindly add following tag as appropriate > Reported-by: kernel test robot > > All warnings (new ones prefixed by >>): > > >> arch/arm/mach-omap2/board-generic.c:36:28: warning: no previous prototype > >> for 'omap_init_time_of' [-Wmissing-prototypes] > 36 | void __init __maybe_unused omap_init_time_of(void) > |^ > > > vim +/omap_init_time_of +36 arch/arm/mach-omap2/board-generic.c > > 34 > 35/* Clocks are needed early, see drivers/clocksource for the > rest */ > > 36void __init __maybe_unused omap_init_time_of(void) > 37{ > 38omap_clk_init(); > 39timer_probe(); > 40} > 41 > > --- > 0-DAY CI Kernel Test Service, Intel Corporation > https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
Re: [PATCHv2 01/38] ARM: dts: motorola-cpcap-mapphone: Prepare for dtbs_check parsing
* Sebastian Reichel [210323 12:52]: > Hi Tony, > > On Wed, Mar 17, 2021 at 04:29:19PM +0200, Tony Lindgren wrote: > > * Sebastian Reichel [210317 13:50]: > > > '< parameters parameters>' and '< parameters>, > > > < parameters>' result in the same DTB, but second format has > > > better source code readability. Also 'dtbs_check' currently uses > > > this format to determine the amount of items specified, so using > > > this syntax is needed to successfully verify the devicetree source > > > against a DT schema format. > > > > Looks good to me: > > > > Acked-by: Tony Lindgren > > Please take this patch via your tree. I will take the other ones > through the power-supply tree. OK will do. Thanks, Tony
[PATCH 1/2] clocksource/drivers/timer-ti-dm: Prepare to handle dra7 timer wrap issue
There is a timer wrap issue on dra7 for the ARM architected timer. In a typical clock configuration the timer fails to wrap after 388 days. To work around the issue, we need to use timer-ti-dm timers instead. Let's prepare for adding support for percpu timers by adding a common dmtimer_clkevt_init_common() and call it from dmtimer_clockevent_init(). This patch makes no intentional functional changes. Signed-off-by: Tony Lindgren --- drivers/clocksource/timer-ti-dm-systimer.c | 66 ++ 1 file changed, 43 insertions(+), 23 deletions(-) diff --git a/drivers/clocksource/timer-ti-dm-systimer.c b/drivers/clocksource/timer-ti-dm-systimer.c --- a/drivers/clocksource/timer-ti-dm-systimer.c +++ b/drivers/clocksource/timer-ti-dm-systimer.c @@ -530,17 +530,17 @@ static void omap_clockevent_unidle(struct clock_event_device *evt) writel_relaxed(OMAP_TIMER_INT_OVERFLOW, t->base + t->wakeup); } -static int __init dmtimer_clockevent_init(struct device_node *np) +static int __init dmtimer_clkevt_init_common(struct dmtimer_clockevent *clkevt, +struct device_node *np, +unsigned int features, +const struct cpumask *cpumask, +const char *name, +int rating) { - struct dmtimer_clockevent *clkevt; struct clock_event_device *dev; struct dmtimer_systimer *t; int error; - clkevt = kzalloc(sizeof(*clkevt), GFP_KERNEL); - if (!clkevt) - return -ENOMEM; - t = >t; dev = >dev; @@ -548,25 +548,23 @@ static int __init dmtimer_clockevent_init(struct device_node *np) * We mostly use cpuidle_coupled with ARM local timers for runtime, * so there's probably no use for CLOCK_EVT_FEAT_DYNIRQ here. */ - dev->features = CLOCK_EVT_FEAT_PERIODIC | CLOCK_EVT_FEAT_ONESHOT; - dev->rating = 300; + dev->features = features; + dev->rating = rating; dev->set_next_event = dmtimer_set_next_event; dev->set_state_shutdown = dmtimer_clockevent_shutdown; dev->set_state_periodic = dmtimer_set_periodic; dev->set_state_oneshot = dmtimer_clockevent_shutdown; dev->set_state_oneshot_stopped = dmtimer_clockevent_shutdown; dev->tick_resume = dmtimer_clockevent_shutdown; - dev->cpumask = cpu_possible_mask; + dev->cpumask = cpumask; dev->irq = irq_of_parse_and_map(np, 0); - if (!dev->irq) { - error = -ENXIO; - goto err_out_free; - } + if (!dev->irq) + return -ENXIO; error = dmtimer_systimer_setup(np, >t); if (error) - goto err_out_free; + return error; clkevt->period = 0x - DIV_ROUND_CLOSEST(t->rate, HZ); @@ -578,32 +576,54 @@ static int __init dmtimer_clockevent_init(struct device_node *np) writel_relaxed(OMAP_TIMER_CTRL_POSTED, t->base + t->ifctrl); error = request_irq(dev->irq, dmtimer_clockevent_interrupt, - IRQF_TIMER, "clockevent", clkevt); + IRQF_TIMER, name, clkevt); if (error) goto err_out_unmap; writel_relaxed(OMAP_TIMER_INT_OVERFLOW, t->base + t->irq_ena); writel_relaxed(OMAP_TIMER_INT_OVERFLOW, t->base + t->wakeup); - pr_info("TI gptimer clockevent: %s%lu Hz at %pOF\n", - of_find_property(np, "ti,timer-alwon", NULL) ? + pr_info("TI gptimer %s: %s%lu Hz at %pOF\n", + name, of_find_property(np, "ti,timer-alwon", NULL) ? "always-on " : "", t->rate, np->parent); - clockevents_config_and_register(dev, t->rate, + return 0; + +err_out_unmap: + iounmap(t->base); + + return error; +} + +static int __init dmtimer_clockevent_init(struct device_node *np) +{ + struct dmtimer_clockevent *clkevt; + int error; + + clkevt = kzalloc(sizeof(*clkevt), GFP_KERNEL); + if (!clkevt) + return -ENOMEM; + + error = dmtimer_clkevt_init_common(clkevt, np, + CLOCK_EVT_FEAT_PERIODIC | + CLOCK_EVT_FEAT_ONESHOT, + cpu_possible_mask, "clockevent", + 300); + if (error) + goto err_out_free; + + clockevents_config_and_register(>dev, clkevt->t.rate, 3, /* Timer internal resynch latency */ 0x); if (of_machine_i
[PATCH 2/2] clocksource/drivers/timer-ti-dm: Handle dra7 timer wrap errata i940
There is a timer wrap issue on dra7 for the ARM architected timer. In a typical clock configuration the timer fails to wrap after 388 days. To work around the issue, we need to use timer-ti-dm percpu timers instead. Let's configure dmtimer3 and 4 as percpu timers by default, and warn about the issue if the dtb is not configured properly. Let's do this as a single patch so it can be backported to v5.8 and later kernels easily. Note that this patch depends on earlier timer-ti-dm systimer posted mode fixes, and a preparatory clockevent patch "clocksource/drivers/timer-ti-dm: Prepare to handle dra7 timer wrap issue". For more information, please see the errata for "AM572x Sitara Processors Silicon Revisions 1.1, 2.0": https://www.ti.com/lit/er/sprz429m/sprz429m.pdf The concept is based on earlier reference patches done by Tero Kristo and Keerthy. Cc: Keerthy Cc: Tero Kristo Signed-off-by: Tony Lindgren --- arch/arm/boot/dts/dra7-l4.dtsi | 4 +- arch/arm/boot/dts/dra7.dtsi| 20 ++ drivers/clocksource/timer-ti-dm-systimer.c | 76 ++ include/linux/cpuhotplug.h | 1 + 4 files changed, 99 insertions(+), 2 deletions(-) diff --git a/arch/arm/boot/dts/dra7-l4.dtsi b/arch/arm/boot/dts/dra7-l4.dtsi --- a/arch/arm/boot/dts/dra7-l4.dtsi +++ b/arch/arm/boot/dts/dra7-l4.dtsi @@ -1168,7 +1168,7 @@ timer2: timer@0 { }; }; - target-module@34000 { /* 0x48034000, ap 7 46.0 */ + timer3_target: target-module@34000 {/* 0x48034000, ap 7 46.0 */ compatible = "ti,sysc-omap4-timer", "ti,sysc"; reg = <0x34000 0x4>, <0x34010 0x4>; @@ -1195,7 +1195,7 @@ timer3: timer@0 { }; }; - target-module@36000 { /* 0x48036000, ap 9 4e.0 */ + timer4_target: target-module@36000 {/* 0x48036000, ap 9 4e.0 */ compatible = "ti,sysc-omap4-timer", "ti,sysc"; reg = <0x36000 0x4>, <0x36010 0x4>; diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi --- a/arch/arm/boot/dts/dra7.dtsi +++ b/arch/arm/boot/dts/dra7.dtsi @@ -46,6 +46,7 @@ aliases { timer { compatible = "arm,armv7-timer"; + status = "disabled";/* See ARM architected timer wrap erratum i940 */ interrupts = , , , @@ -1241,3 +1242,22 @@ timer@0 { assigned-clock-parents = <_32k_ck>; }; }; + +/* Local timers, see ARM architected timer wrap erratum i940 */ +_target { + ti,no-reset-on-init; + ti,no-idle; + timer@0 { + assigned-clocks = <_clkctrl DRA7_L4PER_TIMER3_CLKCTRL 24>; + assigned-clock-parents = <_sys_clk_div>; + }; +}; + +_target { + ti,no-reset-on-init; + ti,no-idle; + timer@0 { + assigned-clocks = <_clkctrl DRA7_L4PER_TIMER4_CLKCTRL 24>; + assigned-clock-parents = <_sys_clk_div>; + }; +}; diff --git a/drivers/clocksource/timer-ti-dm-systimer.c b/drivers/clocksource/timer-ti-dm-systimer.c --- a/drivers/clocksource/timer-ti-dm-systimer.c +++ b/drivers/clocksource/timer-ti-dm-systimer.c @@ -2,6 +2,7 @@ #include #include #include +#include #include #include #include @@ -630,6 +631,78 @@ static int __init dmtimer_clockevent_init(struct device_node *np) return error; } +/* Dmtimer as percpu timer. See dra7 ARM architected timer wrap erratum i940 */ +static DEFINE_PER_CPU(struct dmtimer_clockevent, dmtimer_percpu_timer); + +static int __init dmtimer_percpu_timer_init(struct device_node *np, int cpu) +{ + struct dmtimer_clockevent *clkevt; + int error; + + if (!cpu_possible(cpu)) + return -EINVAL; + + if (!of_property_read_bool(np->parent, "ti,no-reset-on-init") || + !of_property_read_bool(np->parent, "ti,no-idle")) + pr_warn("Incomplete dtb for percpu dmtimer %pOF\n", np->parent); + + clkevt = per_cpu_ptr(_percpu_timer, cpu); + + error = dmtimer_clkevt_init_common(clkevt, np, CLOCK_EVT_FEAT_ONESHOT, + cpumask_of(cpu), "percpu-dmtimer", + 500); + if (error) + return error; + + return 0; +} + +/* See TRM for timer internal resynch latency */ +static int omap_dmtimer_starting_cpu(unsigned int cpu) +{ + struct dmtimer_clockevent *clkevt = per_cpu_ptr(_percpu_timer, cpu); + struct clock_event_device *dev = >dev; + struct dm
[PATCHv2 0/2] Fixes for for dra7 timer wrap errata i940
Hi all, Here is v2 set of fixes for dra7 ARM architected timer wrap errata i940 where the timer fails to wrap after 388 days. The workaround is to use two dmtimers as the local timers instead. Note that these patches depend on timer posted mode fixes series "[PATCH 0/3] Fixes for timer-ti-dm systimer posted mode" for the write status register check fix. Also the spurious timer interrupt fix is good to have from that series. Regards, Tony Changes since v1: - Drop pointless irqflags and IRQF_NOBALANCING as noted by Daniel Tony Lindgren (2): clocksource/drivers/timer-ti-dm: Prepare to handle dra7 timer wrap issue clocksource/drivers/timer-ti-dm: Handle dra7 timer wrap errata i940 arch/arm/boot/dts/dra7-l4.dtsi | 4 +- arch/arm/boot/dts/dra7.dtsi| 20 +++ drivers/clocksource/timer-ti-dm-systimer.c | 142 + include/linux/cpuhotplug.h | 1 + 4 files changed, 142 insertions(+), 25 deletions(-) -- 2.31.0
Re: [PATCH 1/2] clocksource/drivers/timer-ti-dm: Prepare to handle dra7 timer wrap issue
* Daniel Lezcano [210322 18:24]: > On 22/03/2021 17:33, Tony Lindgren wrote: > > Hi, > > > > * Daniel Lezcano [210322 15:56]: > >> On 04/03/2021 08:37, Tony Lindgren wrote: > >>> There is a timer wrap issue on dra7 for the ARM architected timer. > >>> In a typical clock configuration the timer fails to wrap after 388 days. > >>> > >>> To work around the issue, we need to use timer-ti-dm timers instead. > >>> > >>> Let's prepare for adding support for percpu timers by adding a common > >>> dmtimer_clkevt_init_common() and call it from dmtimer_clockevent_init(). > >>> This patch makes no intentional functional changes. > >>> > >>> Signed-off-by: Tony Lindgren > >>> --- > >> > >> [ ... ] > >> > >>> @@ -575,33 +574,60 @@ static int __init dmtimer_clockevent_init(struct > >>> device_node *np) > >>>*/ > >>> writel_relaxed(OMAP_TIMER_CTRL_POSTED, t->base + t->ifctrl); > >>> > >>> + if (dev->cpumask == cpu_possible_mask) > >>> + irqflags = IRQF_TIMER; > >>> + else > >>> + irqflags = IRQF_TIMER | IRQF_NOBALANCING; > >> > >> Can you explain the reasoning behind the test above ? > > > > In the per cpu case we assign one dmtimer per cpu, and we want the > > interrupt handling on the assigned CPU. In the per cpu case we have > > the cpu specified with dev->cpumask unlike for the normal clockevent > > case. > > > > In the per cpu dmtimer case the interrupt line is not wired per cpu > > though, so I don't think we want to add IRQF_PERCPU here. > > If it is per cpu, then the parameter will be cpumask_of(cpu). If there > is one cpu, no balancing can happen and then the IRQF_NOBALANCING is not > needed, neither this test and the irqflags, right? Oh yeah you're right, none of that is needed. For the percpu case we already have irq_force_affinity() in omap_dmtimer_starting_cpu(). I'll update and send out v2 of these two patches. Thanks, Tony
Re: [PATCH 1/2] clocksource/drivers/timer-ti-dm: Prepare to handle dra7 timer wrap issue
Hi, * Daniel Lezcano [210322 15:56]: > On 04/03/2021 08:37, Tony Lindgren wrote: > > There is a timer wrap issue on dra7 for the ARM architected timer. > > In a typical clock configuration the timer fails to wrap after 388 days. > > > > To work around the issue, we need to use timer-ti-dm timers instead. > > > > Let's prepare for adding support for percpu timers by adding a common > > dmtimer_clkevt_init_common() and call it from dmtimer_clockevent_init(). > > This patch makes no intentional functional changes. > > > > Signed-off-by: Tony Lindgren > > --- > > [ ... ] > > > @@ -575,33 +574,60 @@ static int __init dmtimer_clockevent_init(struct > > device_node *np) > > */ > > writel_relaxed(OMAP_TIMER_CTRL_POSTED, t->base + t->ifctrl); > > > > + if (dev->cpumask == cpu_possible_mask) > > + irqflags = IRQF_TIMER; > > + else > > + irqflags = IRQF_TIMER | IRQF_NOBALANCING; > > Can you explain the reasoning behind the test above ? In the per cpu case we assign one dmtimer per cpu, and we want the interrupt handling on the assigned CPU. In the per cpu case we have the cpu specified with dev->cpumask unlike for the normal clockevent case. In the per cpu dmtimer case the interrupt line is not wired per cpu though, so I don't think we want to add IRQF_PERCPU here. Or do you have some better suggestion for the flags to use here? :) Regards, Tony
Re: [PATCH 2/2] clocksource/drivers/timer-ti-dm: Handle dra7 timer wrap errata i940
Hi, * Daniel Lezcano [210322 10:16]: > On 04/03/2021 08:37, Tony Lindgren wrote: > > There is a timer wrap issue on dra7 for the ARM architected timer. > > In a typical clock configuration the timer fails to wrap after 388 days. > > > > To work around the issue, we need to use timer-ti-dm percpu timers instead. > > > > Let's configure dmtimer3 and 4 as percpu timers by default, and warn about > > the issue if the dtb is not configured properly. > > > > Let's do this as a single patch so it can be backported to v5.8 and later > > kernels easily. > > Cc: # v5.8+ > > ?? Yes please, that would be great. Thanks, Tony
Re: [PATCHv2 03/38] dt-bindings: power: supply: cpcap-charger: Convert to DT schema format
* Sebastian Reichel [210317 13:50]: > Convert the binding to DT schema format. I also added the missing bits > used by the only in-tree user and implemented in the driver. Reviewed-by: Tony Lindgren
Re: [PATCHv2 02/38] dt-bindings: power: supply: cpcap-battery: Convert to DT schema format
* Sebastian Reichel [210317 13:50]: > Convert the binding to DT schema format. I also added the missing bits > used by the only in-tree user and implemented in the driver. Reviewed-by: Tony Lindgren
Re: [PATCHv2 01/38] ARM: dts: motorola-cpcap-mapphone: Prepare for dtbs_check parsing
* Sebastian Reichel [210317 13:50]: > '< parameters parameters>' and '< parameters>, > < parameters>' result in the same DTB, but second format has > better source code readability. Also 'dtbs_check' currently uses > this format to determine the amount of items specified, so using > this syntax is needed to successfully verify the devicetree source > against a DT schema format. Looks good to me: Acked-by: Tony Lindgren
[PATCH 0/2] Few clean-up patches after dropping legacy data
Hi all, Here are few clean-up patches after we are dropping the legacy data for omap4/5 and dra7. These are against my omap-for-v5.13/genpd-drop-legacy branch at [0]. Regards, Tony [0] https://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap.git/log/?h=omap-for-v5.13/genpd-drop-legacy Tony Lindgren (2): ARM: OMAP2+: Stop building legacy code for dra7 and omap4/5 bus: ti-sysc: Warn about old dtb for dra7 and omap4/5 arch/arm/mach-omap2/Makefile | 8 arch/arm/mach-omap2/io.c | 7 ++- arch/arm/mach-omap2/omap_hwmod.h | 13 + arch/arm/mach-omap2/pdata-quirks.c | 2 +- arch/arm/mach-omap2/sr_device.c| 7 +++ drivers/bus/ti-sysc.c | 3 +++ 6 files changed, 34 insertions(+), 6 deletions(-) -- 2.30.2
[PATCH 2/2] bus: ti-sysc: Warn about old dtb for dra7 and omap4/5
Let's warn if an old incomplete dtb is detected. We now assume the dtb is complete and does not depend on the legacy platform data. Signed-off-by: Tony Lindgren --- drivers/bus/ti-sysc.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/bus/ti-sysc.c b/drivers/bus/ti-sysc.c --- a/drivers/bus/ti-sysc.c +++ b/drivers/bus/ti-sysc.c @@ -2886,6 +2886,9 @@ static int sysc_init_soc(struct sysc *ddata) switch (sysc_soc->soc) { case SOC_AM3: case SOC_AM4: + case SOC_4430 ... SOC_4470: + case SOC_5430: + case SOC_DRA7: np = of_find_node_by_path("/ocp"); WARN_ONCE(np && of_device_is_compatible(np, "simple-bus"), "ti-sysc: Incomplete old dtb, please update\n"); -- 2.30.2
[PATCH 1/2] ARM: OMAP2+: Stop building legacy code for dra7 and omap4/5
With the recent changes we are now booting am3/4, dra7, and omap4/5 without legacy data using devicetree, simple-pm-bus and genpd. Let's not initialize and build the legacy data unless CONFIG_OMAP_HWMOD is selected based on the SoCs enabled in .config. Signed-off-by: Tony Lindgren --- arch/arm/mach-omap2/Makefile | 8 arch/arm/mach-omap2/io.c | 7 ++- arch/arm/mach-omap2/omap_hwmod.h | 13 + arch/arm/mach-omap2/pdata-quirks.c | 2 +- arch/arm/mach-omap2/sr_device.c| 7 +++ 5 files changed, 31 insertions(+), 6 deletions(-) diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -20,14 +20,14 @@ secure-common = omap-smc.o omap-secure.o obj-$(CONFIG_ARCH_OMAP2) += $(omap-2-3-common) $(hwmod-common) obj-$(CONFIG_ARCH_OMAP3) += $(omap-2-3-common) $(hwmod-common) $(secure-common) -obj-$(CONFIG_ARCH_OMAP4) += $(hwmod-common) $(secure-common) +obj-$(CONFIG_ARCH_OMAP4) += $(secure-common) obj-$(CONFIG_SOC_AM33XX) += $(secure-common) -obj-$(CONFIG_SOC_OMAP5) += $(hwmod-common) $(secure-common) +obj-$(CONFIG_SOC_OMAP5) += $(secure-common) obj-$(CONFIG_SOC_AM43XX) += $(secure-common) -obj-$(CONFIG_SOC_DRA7XX) += $(hwmod-common) $(secure-common) +obj-$(CONFIG_SOC_DRA7XX) += $(secure-common) ifneq ($(CONFIG_SND_SOC_OMAP_MCBSP),) -obj-y += mcbsp.o +obj-$(CONFIG_OMAP_HWMOD) += mcbsp.o endif obj-$(CONFIG_TWL4030_CORE) += omap_twl.o diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c --- a/arch/arm/mach-omap2/io.c +++ b/arch/arm/mach-omap2/io.c @@ -402,6 +402,7 @@ static int __init _omap2_init_reprogram_sdrc(void) return v; } +#ifdef CONFIG_OMAP_HWMOD static int _set_hwmod_postsetup_state(struct omap_hwmod *oh, void *data) { return omap_hwmod_set_postsetup_state(oh, *(u8 *)data); @@ -414,6 +415,11 @@ static void __init __maybe_unused omap_hwmod_init_postsetup(void) /* Set the default postsetup state for all hwmods */ omap_hwmod_for_each(_set_hwmod_postsetup_state, _state); } +#else +static inline void omap_hwmod_init_postsetup(void) +{ +} +#endif #ifdef CONFIG_SOC_OMAP2420 void __init omap2420_init_early(void) @@ -615,7 +621,6 @@ void __init omap4430_init_early(void) omap44xx_voltagedomains_init(); omap44xx_powerdomains_init(); omap44xx_clockdomains_init(); - omap_hwmod_init_postsetup(); omap_l2_cache_init(); omap_clk_soc_init = omap4xxx_dt_clk_init; omap_secure_init(); diff --git a/arch/arm/mach-omap2/omap_hwmod.h b/arch/arm/mach-omap2/omap_hwmod.h --- a/arch/arm/mach-omap2/omap_hwmod.h +++ b/arch/arm/mach-omap2/omap_hwmod.h @@ -607,6 +607,8 @@ struct omap_hwmod { struct omap_hwmod *parent_hwmod; }; +#ifdef CONFIG_OMAP_HWMOD + struct device_node; struct omap_hwmod *omap_hwmod_lookup(const char *name); @@ -656,6 +658,17 @@ extern void __init omap_hwmod_init(void); const char *omap_hwmod_get_main_clk(struct omap_hwmod *oh); +#else /* CONFIG_OMAP_HWMOD */ + +static inline int +omap_hwmod_for_each_by_class(const char *classname, +int (*fn)(struct omap_hwmod *oh, void *user), +void *user) +{ + return 0; +} +#endif /* CONFIG_OMAP_HWMOD */ + /* * */ diff --git a/arch/arm/mach-omap2/pdata-quirks.c b/arch/arm/mach-omap2/pdata-quirks.c --- a/arch/arm/mach-omap2/pdata-quirks.c +++ b/arch/arm/mach-omap2/pdata-quirks.c @@ -443,7 +443,7 @@ void omap_auxdata_legacy_init(struct device *dev) dev->platform_data = _gpio_auxdata; } -#if IS_ENABLED(CONFIG_SND_SOC_OMAP_MCBSP) +#if defined(CONFIG_ARCH_OMAP3) && IS_ENABLED(CONFIG_SND_SOC_OMAP_MCBSP) static struct omap_mcbsp_platform_data mcbsp_pdata; static void __init omap3_mcbsp_init(void) { diff --git a/arch/arm/mach-omap2/sr_device.c b/arch/arm/mach-omap2/sr_device.c --- a/arch/arm/mach-omap2/sr_device.c +++ b/arch/arm/mach-omap2/sr_device.c @@ -152,6 +152,7 @@ static int __init sr_init_by_name(const char *name, const char *voltdm) return 0; } +#ifdef CONFIG_OMAP_HWMOD static int __init sr_dev_init(struct omap_hwmod *oh, void *user) { struct omap_smartreflex_dev_attr *sr_dev_attr; @@ -165,6 +166,12 @@ static int __init sr_dev_init(struct omap_hwmod *oh, void *user) return sr_init_by_name(oh->name, sr_dev_attr->sensor_voltdm_name); } +#else +static int __init sr_dev_init(struct omap_hwmod *oh, void *user) +{ + return -EINVAL; +} +#endif /* * API to be called from board files to enable smartreflex -- 2.30.2
Re: [PATCH] ARM: omap1: fix building with clang IAS
* Arnd Bergmann [210308 15:35]: > From: Arnd Bergmann > > The clang integrated assembler fails to build one file with > a complex asm instruction: > > arch/arm/mach-omap1/ams-delta-fiq-handler.S:249:2: error: invalid > instruction, any one of the following would fix this: > mov r10, #(1 << (((NR_IRQS_LEGACY + 12) - NR_IRQS_LEGACY) % 32)) @ set > deferred_fiq bit > ^ > arch/arm/mach-omap1/ams-delta-fiq-handler.S:249:2: note: instruction > requires: armv6t2 > mov r10, #(1 << (((NR_IRQS_LEGACY + 12) - NR_IRQS_LEGACY) % 32)) @ set > deferred_fiq bit > ^ > arch/arm/mach-omap1/ams-delta-fiq-handler.S:249:2: note: instruction > requires: thumb2 > mov r10, #(1 << (((NR_IRQS_LEGACY + 12) - NR_IRQS_LEGACY) % 32)) @ set > deferred_fiq bit > ^ > > The problem is that 'NR_IRQS_LEGACY' is not defined here. Apparently > gas does not care because we first add and then subtract this number, > leading to the immediate value to be the same regardless of the > specific definition of NR_IRQS_LEGACY. > > Neither the way that 'gas' just silently builds this file, nor the > way that clang IAS makes nonsensical suggestions for how to fix it > is great. Fortunately there is an easy fix, which is to #include > the header that contains the definition. Acked-by: Tony Lindgren
Re: [RFT PATCH v3 06/27] dt-bindings: timer: arm,arch_timer: Add interrupt-names support
* Hector Martin [210304 21:40]: > Not all platforms provide the same set of timers/interrupts, and Linux > only needs one (plus kvm/guest ones); some platforms are working around > this by using dummy fake interrupts. Implementing interrupt-names allows > the devicetree to specify an arbitrary set of available interrupts, so > the timer code can pick the right one. > > This also adds the hyp-virt timer/interrupt, which was previously not > expressed in the fixed 4-interrupt form. I like this one too: Reviewed-by: Tony Lindgren
Re: [PATCH 2/3] clocksource/drivers/timer-ti-dm: Remove extra of_node_put()
Hi, * Tony Lindgren [210305 07:58]: > * Grygorii Strashko [210304 20:56]: > > > > > > On 04/03/2021 09:21, Tony Lindgren wrote: > > > We have of_translate_address() already do of_node_put() as needed. > > > I probably looked at __of_translate_address() earlier by accident > > > that of_translate_address() uses. > > > > I do not see of_node_put() in of_translate_address() and > > __of_translate_address() is doing of_node_get(dev); > > ? > > Oh right.. this is confusing.. Yeah we can ignore this patch. > We should have the use count set for only the system timer(s) > we claim. Daniel, would you like me to repost this series with this patch dropped? Regards, Tony
[PATCH 3/4] clk: ti: omap5: Add missing gpmc and ocmc clkctrl
The gpmc clock is needed to update omap5 to boot with genpd with the related devicetree patches. The ocmc clock is currently not used but let's add it so we have all the clocks for the l3main2 defined. Cc: Stephen Boyd Cc: Tero Kristo Signed-off-by: Tony Lindgren --- drivers/clk/ti/clk-54xx.c | 2 ++ include/dt-bindings/clock/omap5.h | 2 ++ 2 files changed, 4 insertions(+) diff --git a/drivers/clk/ti/clk-54xx.c b/drivers/clk/ti/clk-54xx.c --- a/drivers/clk/ti/clk-54xx.c +++ b/drivers/clk/ti/clk-54xx.c @@ -156,6 +156,8 @@ static const struct omap_clkctrl_reg_data omap5_l3main1_clkctrl_regs[] __initcon static const struct omap_clkctrl_reg_data omap5_l3main2_clkctrl_regs[] __initconst = { { OMAP5_L3_MAIN_2_CLKCTRL, NULL, 0, "l3_iclk_div" }, + { OMAP5_L3_MAIN_2_GPMC_CLKCTRL, NULL, CLKF_HW_SUP, "l3_iclk_div" }, + { OMAP5_L3_MAIN_2_OCMC_RAM_CLKCTRL, NULL, CLKF_HW_SUP, "l3_iclk_div" }, { 0 }, }; diff --git a/include/dt-bindings/clock/omap5.h b/include/dt-bindings/clock/omap5.h --- a/include/dt-bindings/clock/omap5.h +++ b/include/dt-bindings/clock/omap5.h @@ -32,6 +32,8 @@ /* l3main2 clocks */ #define OMAP5_L3_MAIN_2_CLKCTRLOMAP5_CLKCTRL_INDEX(0x20) +#define OMAP5_L3_MAIN_2_GPMC_CLKCTRL OMAP5_CLKCTRL_INDEX(0x28) +#define OMAP5_L3_MAIN_2_OCMC_RAM_CLKCTRL OMAP5_CLKCTRL_INDEX(0x30) /* ipu clocks */ #define OMAP5_MMU_IPU_CLKCTRL OMAP5_CLKCTRL_INDEX(0x20) -- 2.30.1
[PATCH 1/4] ARM: OMAP2+: Init both prm and prcm nodes early for clocks
We need to probe both prm and prcm nodes early for clocks as they are needed by system timers. Signed-off-by: Tony Lindgren --- arch/arm/mach-omap2/pdata-quirks.c | 29 + 1 file changed, 21 insertions(+), 8 deletions(-) diff --git a/arch/arm/mach-omap2/pdata-quirks.c b/arch/arm/mach-omap2/pdata-quirks.c --- a/arch/arm/mach-omap2/pdata-quirks.c +++ b/arch/arm/mach-omap2/pdata-quirks.c @@ -569,10 +569,29 @@ static void pdata_quirks_check(struct pdata_init *quirks) } } -void __init pdata_quirks_init(const struct of_device_id *omap_dt_match_table) +static const char * const pdata_quirks_init_nodes[] = { + "prcm", + "prm", +}; + +void __init +pdata_quirks_init_clocks(const struct of_device_id *omap_dt_match_table) { struct device_node *np; + int i; + + for (i = 0; i < ARRAY_SIZE(pdata_quirks_init_nodes); i++) { + np = of_find_node_by_name(NULL, pdata_quirks_init_nodes[i]); + if (!np) + continue; + of_platform_populate(np, omap_dt_match_table, +omap_auxdata_lookup, NULL); + } +} + +void __init pdata_quirks_init(const struct of_device_id *omap_dt_match_table) +{ /* * We still need this for omap2420 and omap3 PM to work, others are * using drivers/misc/sram.c already. @@ -585,13 +604,7 @@ void __init pdata_quirks_init(const struct of_device_id *omap_dt_match_table) omap3_mcbsp_init(); pdata_quirks_check(auxdata_quirks); - /* Populate always-on PRCM in l4_wkup to probe l4_wkup */ - np = of_find_node_by_name(NULL, "prcm"); - if (!np) - np = of_find_node_by_name(NULL, "prm"); - if (np) - of_platform_populate(np, omap_dt_match_table, -omap_auxdata_lookup, NULL); + pdata_quirks_init_clocks(omap_dt_match_table); of_platform_populate(NULL, omap_dt_match_table, omap_auxdata_lookup, NULL); -- 2.30.1
[PATCH 2/4] soc: ti: omap-prm: Allow hardware supported retention when idle
When moving the l4 interconnect instances to probe with simple-pm-bus and genpd, we will have l4per and core domains stop idling unless we configure the domain bits to allow retention when idle. As the TI SoCs have hardware autoidle capabilities, this is safe to do. The domains will only enter retention on WFI when none of the devices on the domain block autoidle in the hardware. This follows what we are already currently doing. Cc: Santosh Shilimkar Cc: Tero Kristo Signed-off-by: Tony Lindgren --- drivers/soc/ti/omap_prm.c | 16 1 file changed, 12 insertions(+), 4 deletions(-) diff --git a/drivers/soc/ti/omap_prm.c b/drivers/soc/ti/omap_prm.c --- a/drivers/soc/ti/omap_prm.c +++ b/drivers/soc/ti/omap_prm.c @@ -88,6 +88,7 @@ struct omap_reset_data { #define OMAP_PRM_HAS_RSTCTRL BIT(0) #define OMAP_PRM_HAS_RSTST BIT(1) #define OMAP_PRM_HAS_NO_CLKDM BIT(2) +#define OMAP_PRM_RET_WHEN_IDLE BIT(3) #define OMAP_PRM_HAS_RESETS(OMAP_PRM_HAS_RSTCTRL | OMAP_PRM_HAS_RSTST) @@ -174,7 +175,8 @@ static const struct omap_prm_data omap4_prm_data[] = { .name = "core", .base = 0x4a306700, .pwrstctrl = 0x0, .pwrstst = 0x4, .dmap = _prm_reton, .rstctrl = 0x210, .rstst = 0x214, .clkdm_name = "ducati", - .rstmap = rst_map_012 + .rstmap = rst_map_012, + .flags = OMAP_PRM_RET_WHEN_IDLE, }, { .name = "ivahd", .base = 0x4a306f00, @@ -199,7 +201,8 @@ static const struct omap_prm_data omap4_prm_data[] = { }, { .name = "l4per", .base = 0x4a307400, - .pwrstctrl = 0x0, .pwrstst = 0x4, .dmap = _prm_reton + .pwrstctrl = 0x0, .pwrstst = 0x4, .dmap = _prm_reton, + .flags = OMAP_PRM_RET_WHEN_IDLE, }, { .name = "cefuse", .base = 0x4a307600, @@ -517,7 +520,7 @@ static int omap_prm_domain_power_on(struct generic_pm_domain *domain) { struct omap_prm_domain *prmd; int ret; - u32 v; + u32 v, mode; prmd = genpd_to_prm_domain(domain); if (!prmd->cap) @@ -530,7 +533,12 @@ static int omap_prm_domain_power_on(struct generic_pm_domain *domain) else v = readl_relaxed(prmd->prm->base + prmd->pwrstctrl); - writel_relaxed(v | OMAP_PRMD_ON_ACTIVE, + if (prmd->prm->data->flags & OMAP_PRM_RET_WHEN_IDLE) + mode = OMAP_PRMD_RETENTION; + else + mode = OMAP_PRMD_ON_ACTIVE; + + writel_relaxed((v & ~PRM_POWERSTATE_MASK) | mode, prmd->prm->base + prmd->pwrstctrl); /* wait for the transition bit to get cleared */ -- 2.30.1
[PATCH 4/4] bus: ti-sysc: Check for old incomplete dtb
Let's be nice and show an error on the SoCs about old imcomplete devicetree if the dtb is still using "simple-bus" instead of "simple-pm-bus" for the root OCP node. Signed-off-by: Tony Lindgren --- drivers/bus/ti-sysc.c | 16 1 file changed, 16 insertions(+) diff --git a/drivers/bus/ti-sysc.c b/drivers/bus/ti-sysc.c --- a/drivers/bus/ti-sysc.c +++ b/drivers/bus/ti-sysc.c @@ -2858,6 +2858,7 @@ static int sysc_init_soc(struct sysc *ddata) const struct soc_device_attribute *match; struct ti_sysc_platform_data *pdata; unsigned long features = 0; + struct device_node *np; if (sysc_soc) return 0; @@ -2878,6 +2879,21 @@ static int sysc_init_soc(struct sysc *ddata) if (match && match->data) sysc_soc->soc = (int)match->data; + /* +* Check and warn about possible old incomplete dtb. We now want to see +* simple-pm-bus instead of simple-bus in the dtb for genpd using SoCs. +*/ + switch (sysc_soc->soc) { + case SOC_AM3: + case SOC_AM4: + np = of_find_node_by_path("/ocp"); + WARN_ONCE(np && of_device_is_compatible(np, "simple-bus"), + "ti-sysc: Incomplete old dtb, please update\n"); + break; + default: + break; + } + /* Ignore devices that are not available on HS and EMU SoCs */ if (!sysc_soc->general_purpose) { switch (sysc_soc->soc) { -- 2.30.1
[PATCH 0/4] ti-sysc changes for dropping omap4/5 legacy data
Hi all, Here are few ti-sysc related changes that are needed to drop legacy data for omap4/5. The last patch also starts warning users about old incomplete dtb, we do that initially only for am3/4 that no longer have the legacy data. Regards, Tony Tony Lindgren (4): ARM: OMAP2+: Init both prm and prcm nodes early for clocks soc: ti: omap-prm: Allow hardware supported retention when idle clk: ti: omap5: Add missing gpmc and ocmc clkctrl bus: ti-sysc: Check for old incomplete dtb arch/arm/mach-omap2/pdata-quirks.c | 29 + drivers/bus/ti-sysc.c | 16 drivers/clk/ti/clk-54xx.c | 2 ++ drivers/soc/ti/omap_prm.c | 16 include/dt-bindings/clock/omap5.h | 2 ++ 5 files changed, 53 insertions(+), 12 deletions(-) -- 2.30.1
Re: [PATCH 1/3] clocksource/drivers/timer-ti-dm: Fix posted mode status check order
* Grygorii Strashko [210304 20:58]: > On 04/03/2021 09:21, Tony Lindgren wrote: > > When the timer is configured in posted mode, we need to check the write- > > posted status register (TWPS) before writing to the register. ... > > --- a/drivers/clocksource/timer-ti-dm-systimer.c > > +++ b/drivers/clocksource/timer-ti-dm-systimer.c > > @@ -449,13 +449,13 @@ static int dmtimer_set_next_event(unsigned long > > cycles, > > struct dmtimer_systimer *t = >t; > > void __iomem *pend = t->base + t->pend; > > - writel_relaxed(0x - cycles, t->base + t->counter); > > while (readl_relaxed(pend) & WP_TCRR) > > cpu_relax(); > > + writel_relaxed(0x - cycles, t->base + t->counter); > > - writel_relaxed(OMAP_TIMER_CTRL_ST, t->base + t->ctrl); > > while (readl_relaxed(pend) & WP_TCLR) > > cpu_relax(); > > + writel_relaxed(OMAP_TIMER_CTRL_ST, t->base + t->ctrl); > > It seems static [and inline] helper here could be better solution. no? Well we wanted to get rid of the confusing macros. And in this case I suspect we can eventually do just one read of the pending register for the registers used mask rather than check the status separately multiple times. But that needs to be carefully tested and is not a fix :) Regards, Tony
Re: [PATCH 2/3] clocksource/drivers/timer-ti-dm: Remove extra of_node_put()
* Grygorii Strashko [210304 20:56]: > > > On 04/03/2021 09:21, Tony Lindgren wrote: > > We have of_translate_address() already do of_node_put() as needed. > > I probably looked at __of_translate_address() earlier by accident > > that of_translate_address() uses. > > I do not see of_node_put() in of_translate_address() and > __of_translate_address() is doing of_node_get(dev); > ? Oh right.. this is confusing.. Yeah we can ignore this patch. We should have the use count set for only the system timer(s) we claim. Regards, Tony
[PATCH 1/2] clocksource/drivers/timer-ti-dm: Prepare to handle dra7 timer wrap issue
There is a timer wrap issue on dra7 for the ARM architected timer. In a typical clock configuration the timer fails to wrap after 388 days. To work around the issue, we need to use timer-ti-dm timers instead. Let's prepare for adding support for percpu timers by adding a common dmtimer_clkevt_init_common() and call it from dmtimer_clockevent_init(). This patch makes no intentional functional changes. Signed-off-by: Tony Lindgren --- drivers/clocksource/timer-ti-dm-systimer.c | 72 +++--- 1 file changed, 49 insertions(+), 23 deletions(-) diff --git a/drivers/clocksource/timer-ti-dm-systimer.c b/drivers/clocksource/timer-ti-dm-systimer.c --- a/drivers/clocksource/timer-ti-dm-systimer.c +++ b/drivers/clocksource/timer-ti-dm-systimer.c @@ -528,17 +528,18 @@ static void omap_clockevent_unidle(struct clock_event_device *evt) writel_relaxed(OMAP_TIMER_INT_OVERFLOW, t->base + t->wakeup); } -static int __init dmtimer_clockevent_init(struct device_node *np) +static int __init dmtimer_clkevt_init_common(struct dmtimer_clockevent *clkevt, +struct device_node *np, +unsigned int features, +const struct cpumask *cpumask, +const char *name, +int rating) { - struct dmtimer_clockevent *clkevt; struct clock_event_device *dev; struct dmtimer_systimer *t; + unsigned long irqflags; int error; - clkevt = kzalloc(sizeof(*clkevt), GFP_KERNEL); - if (!clkevt) - return -ENOMEM; - t = >t; dev = >dev; @@ -546,25 +547,23 @@ static int __init dmtimer_clockevent_init(struct device_node *np) * We mostly use cpuidle_coupled with ARM local timers for runtime, * so there's probably no use for CLOCK_EVT_FEAT_DYNIRQ here. */ - dev->features = CLOCK_EVT_FEAT_PERIODIC | CLOCK_EVT_FEAT_ONESHOT; - dev->rating = 300; + dev->features = features; + dev->rating = rating; dev->set_next_event = dmtimer_set_next_event; dev->set_state_shutdown = dmtimer_clockevent_shutdown; dev->set_state_periodic = dmtimer_set_periodic; dev->set_state_oneshot = dmtimer_clockevent_shutdown; dev->set_state_oneshot_stopped = dmtimer_clockevent_shutdown; dev->tick_resume = dmtimer_clockevent_shutdown; - dev->cpumask = cpu_possible_mask; + dev->cpumask = cpumask; dev->irq = irq_of_parse_and_map(np, 0); - if (!dev->irq) { - error = -ENXIO; - goto err_out_free; - } + if (!dev->irq) + return -ENXIO; error = dmtimer_systimer_setup(np, >t); if (error) - goto err_out_free; + return error; clkevt->period = 0x - DIV_ROUND_CLOSEST(t->rate, HZ); @@ -575,33 +574,60 @@ static int __init dmtimer_clockevent_init(struct device_node *np) */ writel_relaxed(OMAP_TIMER_CTRL_POSTED, t->base + t->ifctrl); + if (dev->cpumask == cpu_possible_mask) + irqflags = IRQF_TIMER; + else + irqflags = IRQF_TIMER | IRQF_NOBALANCING; + error = request_irq(dev->irq, dmtimer_clockevent_interrupt, - IRQF_TIMER, "clockevent", clkevt); + irqflags, name, clkevt); if (error) goto err_out_unmap; writel_relaxed(OMAP_TIMER_INT_OVERFLOW, t->base + t->irq_ena); writel_relaxed(OMAP_TIMER_INT_OVERFLOW, t->base + t->wakeup); - pr_info("TI gptimer clockevent: %s%lu Hz at %pOF\n", - of_find_property(np, "ti,timer-alwon", NULL) ? + pr_info("TI gptimer %s: %s%lu Hz at %pOF\n", + name, of_find_property(np, "ti,timer-alwon", NULL) ? "always-on " : "", t->rate, np->parent); - clockevents_config_and_register(dev, t->rate, + return 0; + +err_out_unmap: + iounmap(t->base); + + return error; +} + +static int __init dmtimer_clockevent_init(struct device_node *np) +{ + struct dmtimer_clockevent *clkevt; + int error; + + clkevt = kzalloc(sizeof(*clkevt), GFP_KERNEL); + if (!clkevt) + return -ENOMEM; + + error = dmtimer_clkevt_init_common(clkevt, np, + CLOCK_EVT_FEAT_PERIODIC | + CLOCK_EVT_FEAT_ONESHOT, + cpu_possible_mask, "clockevent", + 300); + if (error) + goto err_out_free; + + cl
[PATCH 2/2] clocksource/drivers/timer-ti-dm: Handle dra7 timer wrap errata i940
There is a timer wrap issue on dra7 for the ARM architected timer. In a typical clock configuration the timer fails to wrap after 388 days. To work around the issue, we need to use timer-ti-dm percpu timers instead. Let's configure dmtimer3 and 4 as percpu timers by default, and warn about the issue if the dtb is not configured properly. Let's do this as a single patch so it can be backported to v5.8 and later kernels easily. Note that this patch depends on earlier timer-ti-dm systimer posted mode fixes, and a preparatory clockevent patch "clocksource/drivers/timer-ti-dm: Prepare to handle dra7 timer wrap issue". For more information, please see the errata for "AM572x Sitara Processors Silicon Revisions 1.1, 2.0": https://www.ti.com/lit/er/sprz429m/sprz429m.pdf The concept is based on earlier reference patches done by Tero Kristo and Keerthy. Cc: Keerthy Cc: Tero Kristo Signed-off-by: Tony Lindgren --- arch/arm/boot/dts/dra7-l4.dtsi | 4 +- arch/arm/boot/dts/dra7.dtsi| 20 ++ drivers/clocksource/timer-ti-dm-systimer.c | 76 ++ include/linux/cpuhotplug.h | 1 + 4 files changed, 99 insertions(+), 2 deletions(-) diff --git a/arch/arm/boot/dts/dra7-l4.dtsi b/arch/arm/boot/dts/dra7-l4.dtsi --- a/arch/arm/boot/dts/dra7-l4.dtsi +++ b/arch/arm/boot/dts/dra7-l4.dtsi @@ -1168,7 +1168,7 @@ timer2: timer@0 { }; }; - target-module@34000 { /* 0x48034000, ap 7 46.0 */ + timer3_target: target-module@34000 {/* 0x48034000, ap 7 46.0 */ compatible = "ti,sysc-omap4-timer", "ti,sysc"; reg = <0x34000 0x4>, <0x34010 0x4>; @@ -1195,7 +1195,7 @@ timer3: timer@0 { }; }; - target-module@36000 { /* 0x48036000, ap 9 4e.0 */ + timer4_target: target-module@36000 {/* 0x48036000, ap 9 4e.0 */ compatible = "ti,sysc-omap4-timer", "ti,sysc"; reg = <0x36000 0x4>, <0x36010 0x4>; diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi --- a/arch/arm/boot/dts/dra7.dtsi +++ b/arch/arm/boot/dts/dra7.dtsi @@ -46,6 +46,7 @@ aliases { timer { compatible = "arm,armv7-timer"; + status = "disabled";/* See ARM architected timer wrap erratum i940 */ interrupts = , , , @@ -1241,3 +1242,22 @@ timer@0 { assigned-clock-parents = <_32k_ck>; }; }; + +/* Local timers, see ARM architected timer wrap erratum i940 */ +_target { + ti,no-reset-on-init; + ti,no-idle; + timer@0 { + assigned-clocks = <_clkctrl DRA7_L4PER_TIMER3_CLKCTRL 24>; + assigned-clock-parents = <_sys_clk_div>; + }; +}; + +_target { + ti,no-reset-on-init; + ti,no-idle; + timer@0 { + assigned-clocks = <_clkctrl DRA7_L4PER_TIMER4_CLKCTRL 24>; + assigned-clock-parents = <_sys_clk_div>; + }; +}; diff --git a/drivers/clocksource/timer-ti-dm-systimer.c b/drivers/clocksource/timer-ti-dm-systimer.c --- a/drivers/clocksource/timer-ti-dm-systimer.c +++ b/drivers/clocksource/timer-ti-dm-systimer.c @@ -2,6 +2,7 @@ #include #include #include +#include #include #include #include @@ -634,6 +635,78 @@ static int __init dmtimer_clockevent_init(struct device_node *np) return error; } +/* Dmtimer as percpu timer. See dra7 ARM architected timer wrap erratum i940 */ +static DEFINE_PER_CPU(struct dmtimer_clockevent, dmtimer_percpu_timer); + +static int __init dmtimer_percpu_timer_init(struct device_node *np, int cpu) +{ + struct dmtimer_clockevent *clkevt; + int error; + + if (!cpu_possible(cpu)) + return -EINVAL; + + if (!of_property_read_bool(np->parent, "ti,no-reset-on-init") || + !of_property_read_bool(np->parent, "ti,no-idle")) + pr_warn("Incomplete dtb for percpu dmtimer %pOF\n", np->parent); + + clkevt = per_cpu_ptr(_percpu_timer, cpu); + + error = dmtimer_clkevt_init_common(clkevt, np, CLOCK_EVT_FEAT_ONESHOT, + cpumask_of(cpu), "percpu-dmtimer", + 500); + if (error) + return error; + + return 0; +} + +/* See TRM for timer internal resynch latency */ +static int omap_dmtimer_starting_cpu(unsigned int cpu) +{ + struct dmtimer_clockevent *clkevt = per_cpu_ptr(_percpu_timer, cpu); + struct clock_event_device *dev = >dev; + struct dm
[PATCH 0/2] Fixes for for dra7 timer wrap errata i940
Hi all, Here are fixes for dra7 ARM architected timer wrap errata i940 where it fails to wrap after 388 days. The workaround is to use two dmtimers as the local timers instead. Note that these patches depend on timer posted mode fixes series "[PATCH 0/3] Fixes for timer-ti-dm systimer posted mode" for the write status register check fix. Also the spurious timer interrupt fix is good to have from that series. Regards, Tony Tony Lindgren (2): clocksource/drivers/timer-ti-dm: Prepare to handle dra7 timer wrap issue clocksource/drivers/timer-ti-dm: Handle dra7 timer wrap errata i940 arch/arm/boot/dts/dra7-l4.dtsi | 4 +- arch/arm/boot/dts/dra7.dtsi| 20 +++ drivers/clocksource/timer-ti-dm-systimer.c | 148 + include/linux/cpuhotplug.h | 1 + 4 files changed, 148 insertions(+), 25 deletions(-) -- 2.30.1
[PATCH 2/3] clocksource/drivers/timer-ti-dm: Remove extra of_node_put()
We have of_translate_address() already do of_node_put() as needed. I probably looked at __of_translate_address() earlier by accident that of_translate_address() uses. Fixes: 52762fbd1c47 ("clocksource/drivers/timer-ti-dm: Add clockevent and clocksource support") Signed-off-by: Tony Lindgren --- drivers/clocksource/timer-ti-dm-systimer.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/clocksource/timer-ti-dm-systimer.c b/drivers/clocksource/timer-ti-dm-systimer.c --- a/drivers/clocksource/timer-ti-dm-systimer.c +++ b/drivers/clocksource/timer-ti-dm-systimer.c @@ -265,7 +265,6 @@ static void __init dmtimer_systimer_assign_alwon(void) pa == 0x48318000) continue; - of_node_put(np); break; } } @@ -300,7 +299,6 @@ static u32 __init dmtimer_systimer_find_first_available(void) continue; } - of_node_put(np); break; } } -- 2.30.1
[PATCH 0/3] Fixes for timer-ti-dm systimer posted mode
Hi all, Here are few timer-ti-dm fixes. The first fix corrects the status bit check order for posted mode. The other two are minor fixes noticed while reviewing and testing the code. Regards, Tony Tony Lindgren (3): clocksource/drivers/timer-ti-dm: Fix posted mode status check order clocksource/drivers/timer-ti-dm: Remove extra of_node_put() clocksource/drivers/timer-ti-dm: Add missing set_state_oneshot_stopped drivers/clocksource/timer-ti-dm-systimer.c | 15 +++ 1 file changed, 7 insertions(+), 8 deletions(-) -- 2.30.1
[PATCH 3/3] clocksource/drivers/timer-ti-dm: Add missing set_state_oneshot_stopped
To avoid spurious timer interrupts when KTIME_MAX is used, we need to configure set_state_oneshot_stopped(). Although implementing this is optional, it still affects things like power management for the extra timer interrupt. For more information, please see commit 8fff52fd5093 ("clockevents: Introduce CLOCK_EVT_STATE_ONESHOT_STOPPED state") and commit cf8c5009ee37 ("clockevents/drivers/arm_arch_timer: Implement ->set_state_oneshot_stopped()"). Fixes: 52762fbd1c47 ("clocksource/drivers/timer-ti-dm: Add clockevent and clocksource support") Signed-off-by: Tony Lindgren --- drivers/clocksource/timer-ti-dm-systimer.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/clocksource/timer-ti-dm-systimer.c b/drivers/clocksource/timer-ti-dm-systimer.c --- a/drivers/clocksource/timer-ti-dm-systimer.c +++ b/drivers/clocksource/timer-ti-dm-systimer.c @@ -552,6 +552,7 @@ static int __init dmtimer_clockevent_init(struct device_node *np) dev->set_state_shutdown = dmtimer_clockevent_shutdown; dev->set_state_periodic = dmtimer_set_periodic; dev->set_state_oneshot = dmtimer_clockevent_shutdown; + dev->set_state_oneshot_stopped = dmtimer_clockevent_shutdown; dev->tick_resume = dmtimer_clockevent_shutdown; dev->cpumask = cpu_possible_mask; -- 2.30.1
[PATCH 1/3] clocksource/drivers/timer-ti-dm: Fix posted mode status check order
When the timer is configured in posted mode, we need to check the write- posted status register (TWPS) before writing to the register. We now check TWPS after the write starting with commit 52762fbd1c47 ("clocksource/drivers/timer-ti-dm: Add clockevent and clocksource support"). For example, in the TRM for am571x the following is documented in chapter "22.2.4.13.1.1 Write Posting Synchronization Mode": "For each register, a status bit is provided in the timer write-posted status (TWPS) register. In this mode, it is mandatory that software check this status bit before any write access. If a write is attempted to a register with a previous access pending, the previous access is discarded without notice." The regression happened when I updated the code to use standard read/write accessors for the driver instead of using __omap_dm_timer_load_start(). We have__omap_dm_timer_load_start() check the TWPS status correctly using __omap_dm_timer_write(). Fixes: 52762fbd1c47 ("clocksource/drivers/timer-ti-dm: Add clockevent and clocksource support") Signed-off-by: Tony Lindgren --- drivers/clocksource/timer-ti-dm-systimer.c | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/drivers/clocksource/timer-ti-dm-systimer.c b/drivers/clocksource/timer-ti-dm-systimer.c --- a/drivers/clocksource/timer-ti-dm-systimer.c +++ b/drivers/clocksource/timer-ti-dm-systimer.c @@ -449,13 +449,13 @@ static int dmtimer_set_next_event(unsigned long cycles, struct dmtimer_systimer *t = >t; void __iomem *pend = t->base + t->pend; - writel_relaxed(0x - cycles, t->base + t->counter); while (readl_relaxed(pend) & WP_TCRR) cpu_relax(); + writel_relaxed(0x - cycles, t->base + t->counter); - writel_relaxed(OMAP_TIMER_CTRL_ST, t->base + t->ctrl); while (readl_relaxed(pend) & WP_TCLR) cpu_relax(); + writel_relaxed(OMAP_TIMER_CTRL_ST, t->base + t->ctrl); return 0; } @@ -490,18 +490,18 @@ static int dmtimer_set_periodic(struct clock_event_device *evt) dmtimer_clockevent_shutdown(evt); /* Looks like we need to first set the load value separately */ - writel_relaxed(clkevt->period, t->base + t->load); while (readl_relaxed(pend) & WP_TLDR) cpu_relax(); + writel_relaxed(clkevt->period, t->base + t->load); - writel_relaxed(clkevt->period, t->base + t->counter); while (readl_relaxed(pend) & WP_TCRR) cpu_relax(); + writel_relaxed(clkevt->period, t->base + t->counter); - writel_relaxed(OMAP_TIMER_CTRL_AR | OMAP_TIMER_CTRL_ST, - t->base + t->ctrl); while (readl_relaxed(pend) & WP_TCLR) cpu_relax(); + writel_relaxed(OMAP_TIMER_CTRL_AR | OMAP_TIMER_CTRL_ST, + t->base + t->ctrl); return 0; } -- 2.30.1
Re: [PATCH] memory: gpmc: fix out of bounds read and dereference on gpmc_cs[]
* Krzysztof Kozlowski [210224 08:11]: > On Wed, Feb 24, 2021 at 10:55:52AM +0300, Dan Carpenter wrote: > > On Tue, Feb 23, 2021 at 07:38:21PM +, Colin King wrote: > > > From: Colin Ian King > > > > > > Currently the array gpmc_cs is indexed by cs before it cs is range checked > > > and the pointer read from this out-of-index read is dereferenced. Fix this > > > by performing the range check on cs before the read and the following > > > pointer dereference. > > > > > > Addresses-Coverity: ("Negative array index read") > > > Fixes: 186401937927 ("memory: gpmc: Move omap gpmc code to live under > > > drivers") > > > Signed-off-by: Colin Ian King > > > --- > > > drivers/memory/omap-gpmc.c | 7 +-- > > > 1 file changed, 5 insertions(+), 2 deletions(-) > > > > > > diff --git a/drivers/memory/omap-gpmc.c b/drivers/memory/omap-gpmc.c > > > index cfa730cfd145..f80c2ea39ca4 100644 > > > --- a/drivers/memory/omap-gpmc.c > > > +++ b/drivers/memory/omap-gpmc.c > > > @@ -1009,8 +1009,8 @@ EXPORT_SYMBOL(gpmc_cs_request); > > > > > > void gpmc_cs_free(int cs) > > > { > > > - struct gpmc_cs_data *gpmc = _cs[cs]; > > > - struct resource *res = >mem; > > > > There is no actual dereferencing going on here, it just taking the > > addresses. But the patch is also harmless and improves readability. > > Hm, in the second line indeed the compiler will just calculate the > offset of "mem" field against the "gpmc_cs+cs" and return it's probable > address. > > To me still the code is a little bit non-obvious or obfuscated - first > you play with the array[index] and then you check the validity of index. To me it seems the fixes tag is not ideal.. Seems this issue was there earlier too before moving the code. In any case: Reviewed-by: Tony Lindgren
Re: Droid 4 charging
* Pavel Machek [210219 21:58]: > > > If I turn off charging with echo 0 > input_current_limit, 0.2 to 0.4A > > > is drawn from USB, and battery is not discharged: > > > > > > root@devuan-droid4:/sys/class/power_supply/usb# echo 0 > > > > input_current_limit > > > root@devuan-droid4:/sys/class/power_supply/usb# cat current_now > > > 0 > > > > Hmm so have you measured that setting the current limit to 0 actually > > draws something from the USB? > > Yes, it does, if I do the echo when charge is done. (I have small USB > passthrough with volt and amp meters). It has been behaving weirdly in > other cases.p OK great, seems like we can just change the charger timeout then. > > I recall clearing the ichrgr bits stops the vbus draw completely, but > > I could be wrong. > > > > > Is that a better way to handle full battery? > > > > We could experiment with switching over to usb power when the battery is > > full. Looking at the docs for mc1378 it might be possible that setting > > CPCAP_REG_CRM_FET_OVRD and clearing CPCAP_REG_CRM_FET_CTRL after the > > battery is full disables charging but still keep drawing power from > > the usb. I'd assume the current limit still needs to be nonzero there > > too? Totally untested.. > > I may be able to test patches... Yeah this too might be worth testing on some donor device.. > > And switching back to battery power on usb disconnect will potentially > > only give us very little time based on the different line length for > > vbus and ground pins compared to data pins on the usb connector.. And > > uvos had some concerns about the battery capacity putting it back online, > > so adding him to Cc also. > > You mean, we'd have to take interrupt and switch registers in order to > switch back to battery power, and system would crash if we did not > make it in time? Yes hopefully we don't need to do that. My guess is we should find some FET_OVRD and FET_CTRL setting we can always keep enabled after charger negotation. Maybe we already have the right settings based on your tests :) Regards, Tony
Re: [PATCH] soc: ti: omap-prm: Fix occasional abort on reset deassert for dra7 iva
* Yongqin Liu [210219 05:02]: > Thanks for the fix, Tony! > Tested with x15 android build, and it resolves the boot failures problem. OK great. May I add your Tested-by: to the patch? Regards, Tony
[PATCH] soc: ti: omap-prm: Fix occasional abort on reset deassert for dra7 iva
On reset deassert, we must wait a bit after the rstst bit change before we allow clockdomain autoidle again. Otherwise we get the following oops sometimes on dra7 with iva: Unhandled fault: imprecise external abort (0x1406) at 0x 4400.ocp:L3 Standard Error: MASTER MPU TARGET IVA_CONFIG (Read Link): At Address: 0x0005A410 : Data Access in User mode during Functional access Internal error: : 1406 [#1] SMP ARM ... (sysc_write_sysconfig) from [] (sysc_enable_module+0xcc/0x260) (sysc_enable_module) from [] (sysc_runtime_resume+0xc8/0x174) (sysc_runtime_resume) from [] (genpd_runtime_resume+0x94/0x224) (genpd_runtime_resume) from [] (__rpm_callback+0xd8/0x180) It is unclear what all devices this might affect, but presumably other devices with the rstst bit too can be affected. So let's just enable the delay for all the devices with rstst bit for now. Later on we may want to limit the list to the know affected devices if needed. Fixes: d30cd83f6853 ("soc: ti: omap-prm: add support for denying idle for reset clockdomain") Reported-by: Yongqin Liu Signed-off-by: Tony Lindgren --- drivers/soc/ti/omap_prm.c | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/soc/ti/omap_prm.c b/drivers/soc/ti/omap_prm.c --- a/drivers/soc/ti/omap_prm.c +++ b/drivers/soc/ti/omap_prm.c @@ -830,8 +830,12 @@ static int omap_reset_deassert(struct reset_controller_dev *rcdev, reset->prm->data->name, id); exit: - if (reset->clkdm) + if (reset->clkdm) { + /* At least dra7 iva needs a delay before clkdm idle */ + if (has_rstst) + udelay(1); pdata->clkdm_allow_idle(reset->clkdm); + } return ret; } -- 2.30.1
[PATCH] bus: ti-sysc: Fix warning on unbind if reset is not deasserted
We currently get thefollowing on driver unbind if a reset is configured and asserted: WARNING: CPU: 0 PID: 993 at drivers/reset/core.c:432 reset_control_assert ... (reset_control_assert) from [] (sysc_remove+0x190/0x1e4) (sysc_remove) from [] (platform_remove+0x24/0x3c) (platform_remove) from [] (__device_release_driver+0x154/0x214) (__device_release_driver) from [] (device_driver_detach+0x3c/0x8c) (device_driver_detach) from [] (unbind_store+0x60/0xd4) (unbind_store) from [] (kernfs_fop_write_iter+0x10c/0x1cc) Let's fix it by checking the reset status. Signed-off-by: Tony Lindgren --- drivers/bus/ti-sysc.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/bus/ti-sysc.c b/drivers/bus/ti-sysc.c --- a/drivers/bus/ti-sysc.c +++ b/drivers/bus/ti-sysc.c @@ -3053,7 +3053,9 @@ static int sysc_remove(struct platform_device *pdev) pm_runtime_put_sync(>dev); pm_runtime_disable(>dev); - reset_control_assert(ddata->rsts); + + if (!reset_control_status(ddata->rsts)) + reset_control_assert(ddata->rsts); unprepare: sysc_unprepare(ddata); -- 2.30.1
Re: [PATCH v6 0/3] pinctrl: pinmux: Add pinmux-select debugfs file
* Drew Fustini [210216 22:46]: > This series first converts the debugfs files in the pinctrl subsystem to > octal permissions and then adds a new debugfs file "pinmux-select". > > Function name and group name can be written to "pinmux-select" which > will cause the function and group to be activated on the pin controller. Nice to see this happening! Reviewed-by: Tony Lindgren
Re: [PATCH v2 06/25] arm64: arch_timer: implement support for interrupt-names
* Hector Martin [210215 12:18]: > This allows the devicetree to correctly represent the available set of > timers, which varies from device to device, without the need for fake > dummy interrupts for unavailable slots. I like the idea of using interrupt-names property for mapping timers :) Similar approach might help other SoCs too. And clocksources never really had similar issues. With Marc's comments addressed, please feel free to add: Reviewed-by: Tony Lindgren
Re: Droid 4 charging
Hi, * Pavel Machek [210206 13:14]: > Hi! > > (I'm using Leste 5.10 kernel here). > > When battery is full, green light is off and 0.00A being drawn from > USB. > > But that means that phone is now powered from battery, discharging > it... And soon charging starts again. (Pretty much immediately, for me) > > That's bad ... right? It wears the battery out. Well maintenance charging at 4.2V sure is better for the battery than what android is doing charging it at 4.31V contantly.. > If I turn off charging with echo 0 > input_current_limit, 0.2 to 0.4A > is drawn from USB, and battery is not discharged: > > root@devuan-droid4:/sys/class/power_supply/usb# echo 0 > input_current_limit > root@devuan-droid4:/sys/class/power_supply/usb# cat current_now > 0 Hmm so have you measured that setting the current limit to 0 actually draws something from the USB? I recall clearing the ichrgr bits stops the vbus draw completely, but I could be wrong. > Is that a better way to handle full battery? We could experiment with switching over to usb power when the battery is full. Looking at the docs for mc1378 it might be possible that setting CPCAP_REG_CRM_FET_OVRD and clearing CPCAP_REG_CRM_FET_CTRL after the battery is full disables charging but still keep drawing power from the usb. I'd assume the current limit still needs to be nonzero there too? Totally untested.. And switching back to battery power on usb disconnect will potentially only give us very little time based on the different line length for vbus and ground pins compared to data pins on the usb connector.. And uvos had some concerns about the battery capacity putting it back online, so adding him to Cc also. Maybe just clearing ichrgr does all this already though and is enough. It should be measured on the vbus line. And then we still need to restart the charger at some point, but that could happen based on much longer timeouts that what we currently have. Regards, Tony
Re: [PATCH 18/18] arm64: apple: Add initial Mac Mini 2020 (M1) devicetree
* Krzysztof Kozlowski [210210 12:56]: > On Wed, Feb 10, 2021 at 01:34:50PM +0200, Tony Lindgren wrote: > > * Hector Martin [210210 11:14]: > > > On 10/02/2021 19.19, Tony Lindgren wrote: > > > > * Hector Martin 'marcan' [210208 12:05]: > > > > > On 08/02/2021 20.04, Krzysztof Kozlowski wrote: > > > > ... > > > > > > > > > > > + clk24: clk24 { > > > > > > > > > > > > Just "clock". Node names should be generic. > > > > > > > > > > Really? Almost every other device device tree uses unique clock node > > > > > names. > > > > > > > > Yeah please just use generic node name "clock". FYI, we're still hurting > > > > because of this for the TI clock node names years after because the > > > > drivers > > > > got a chance to rely on the clock node name.. > > > > > > > > Using "clock" means your clock driver code won't get a chance to wrongly > > > > use the node name and you avoid similar issues. > > > > > > That means it'll end up like this (so that we can have more than one > > > fixed-clock): > > > > > > clocks { > > > #address-cells = <1>; > > > #size-cells = <0>; > > > > > > clk123: clock@0 { > > > ... > > > reg = <0> > > > } > > > > > > clk456: clock@1 { > > > ... > > > reg = <1> > > > } > > > } > > > > > > Correct? > > > > Yeah, just don't use an imaginary dummy index for the reg. Use a real > > register offset from a clock controller instance base, and a register > > bit offset too if needed. > > No, there is no need for fake "clocks" node with fake addresses. If you > have multiple clocks, the rules are the same as for other similar cases, > e.g. leds: > > { > clock-0 { >... > }; > > clock-1 { > .. > }; > > soc@0 { > }; > } > > This should not generate any dtc W=1 warnings and work with dtschema > (you need to check for both). OK yeah so no need for the node name there after the "clock-" :) Sounds good to me. Regards, Tony
Re: [PATCH 18/18] arm64: apple: Add initial Mac Mini 2020 (M1) devicetree
* Daniel Palmer [210210 12:24]: > Hi Hector, > > On Wed, 10 Feb 2021 at 20:49, Hector Martin wrote: > > > > Yeah, just don't use an imaginary dummy index for the reg. Use a real > > > register offset from a clock controller instance base, and a register > > > bit offset too if needed. > > > > I mean for fixed input clocks without any particular numbering, or for > > temporary fake clocks while we figure out the clock controller. Once a > > real clock controller is involved, if there are hardware indexes > > involved that are consistent then of course I'll use those in some way > > that makes sense. > > This exact problem exists for MStar/SigmaStar too. > As it stands there is no documentation to show what the actual clock > tree looks like so everything is guess and I need to come up with numbers. > I'm interested to see what the solution to this is as it will come up again > when mainlining chips without documentation. > > > > The purpose of the clock in this particular case is just to make the > > uart driver work, since it wants to know its reference clock; there is > > work to be done here to figure out the real clock tree > > FWIW arm/boot/dts/mstar-v7.dtsi has the same issue: Needs uart, > has no uart clock. In that instance the uart clock setup by u-boot > is passed to the uart driver as a property instead of creating a fake > clock. Using more local dts nodes for the fixed clocks might help a bit with the dummy numbering problem but is still not a nice solution. How about using node names like "clock-foo" for the fixed clocks? This would be along what we do for with regulator names. Rob and Stephen might have some better suggestions here. Regards, Tony
Re: [PATCH 18/18] arm64: apple: Add initial Mac Mini 2020 (M1) devicetree
* Hector Martin [210210 11:14]: > On 10/02/2021 19.19, Tony Lindgren wrote: > > * Hector Martin 'marcan' [210208 12:05]: > > > On 08/02/2021 20.04, Krzysztof Kozlowski wrote: > > ... > > > > > > > + clk24: clk24 { > > > > > > > > Just "clock". Node names should be generic. > > > > > > Really? Almost every other device device tree uses unique clock node > > > names. > > > > Yeah please just use generic node name "clock". FYI, we're still hurting > > because of this for the TI clock node names years after because the drivers > > got a chance to rely on the clock node name.. > > > > Using "clock" means your clock driver code won't get a chance to wrongly > > use the node name and you avoid similar issues. > > That means it'll end up like this (so that we can have more than one > fixed-clock): > > clocks { > #address-cells = <1>; > #size-cells = <0>; > > clk123: clock@0 { > ... > reg = <0> > } > > clk456: clock@1 { > ... > reg = <1> > } > } > > Correct? Yeah, just don't use an imaginary dummy index for the reg. Use a real register offset from a clock controller instance base, and a register bit offset too if needed. That way if you discover a new clock inbetween somewhere, you don't have renumber any imaginary lists in the driver or device tree. So try to follow sort of what the standard interrupts binding is doing only describing the hardware. > Incidentally, there is just one example in the kernel tree of doing this > right (in arch/arm/boot/dts/imx6qdl-tx6.dtsi). All the others that use > non-mmio clocks called `clock`, including the various tegra devicetrees, > violate the DT spec by not including a dummy reg property matching the > unit-address. Doing it right will save you tons of time later on ;) FYI, for the TI clocks, we ended up redoing most of the clocks as documented in Documentation/devicetree/bindings/clock/ti-clkctrl.txt. Regards, Tony
Re: [PATCH 18/18] arm64: apple: Add initial Mac Mini 2020 (M1) devicetree
* Hector Martin 'marcan' [210208 12:05]: > On 08/02/2021 20.04, Krzysztof Kozlowski wrote: ... > > > + clk24: clk24 { > > > > Just "clock". Node names should be generic. > > Really? Almost every other device device tree uses unique clock node names. Yeah please just use generic node name "clock". FYI, we're still hurting because of this for the TI clock node names years after because the drivers got a chance to rely on the clock node name.. Using "clock" means your clock driver code won't get a chance to wrongly use the node name and you avoid similar issues. Regards, Tony
[PATCH] soc: ti: omap-prm: Fix reboot issue with invalid pcie reset map for dra7
Yongqin Liu reported an issue where reboot hangs on beagleboard-x15. This started happening after commit 7078a5ba7a58 ("soc: ti: omap-prm: Fix boot time errors for rst_map_012 bits 0 and 1"). We now assert any 012 type resets on init to prevent unconfigured accelerator MMUs getting enabled on init depending on the bootloader or kexec configured state. Turns out that we now also wrongly assert dra7 l3init domain PCIe reset bits causing a hang during reboot. Let's fix the l3init reset bits to use a 01 map instead of 012 map. There are only two rstctrl bits and not three. This is documented in TRM "Table 3-1647. RM_PCIESS_RSTCTRL". Fixes: 5a68c87afde0 ("soc: ti: omap-prm: dra7: add genpd support for remaining PRM instances") Fixes: 7078a5ba7a58 ("soc: ti: omap-prm: Fix boot time errors for rst_map_012 bits 0 and 1") Cc: Kishon Vijay Abraham I Reported-by: Yongqin Liu Signed-off-by: Tony Lindgren --- drivers/soc/ti/omap_prm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/soc/ti/omap_prm.c b/drivers/soc/ti/omap_prm.c --- a/drivers/soc/ti/omap_prm.c +++ b/drivers/soc/ti/omap_prm.c @@ -332,7 +332,7 @@ static const struct omap_prm_data dra7_prm_data[] = { { .name = "l3init", .base = 0x4ae07300, .pwrstctrl = 0x0, .pwrstst = 0x4, .dmap = _prm_alwon, - .rstctrl = 0x10, .rstst = 0x14, .rstmap = rst_map_012, + .rstctrl = 0x10, .rstst = 0x14, .rstmap = rst_map_01, .clkdm_name = "pcie" }, { -- 2.30.1
Re: [GIT PULL 2/3] ARM: dts: samsung: DTS for v5.12
* Geert Uytterhoeven [210206 19:48]: > On Sat, Feb 6, 2021 at 3:36 PM Arnd Bergmann wrote: > > What do others think about this? Should we generally assume > > that breaking old kernels with new dtbs is acceptable, or should > > we try to avoid it if possible, the same way we try to avoid > > breaking new kernels with old dtbs? Should this be a platform > > specific policy or should we try to handle all platforms the same > > way? > > For Renesas SoCs, we typically only consider compatibility of new > kernels with old DTBs, not the other way around. > However, most DTB updates are due to new hardware support, so using the > new DTB with an old kernel usually just means no newly documented > hardware, or new feature, is being used by the old kernel. > > In case there was a real issue fixed, and using the new DTB with the old > kernel would cause a regression, and we're aware of it, we do make sure > the DTS update is postponed until the corresponding driver update has > hit upstream. Yeah agreed. Adding new devicetree properties should not be a problem for device drivers. For renamed devicetree properties, the driver won't be aware of them if a newer dtb is used. The only thing the driver can possibly do at this point is maybe warn about some missing old property and bail out. Making sure the driver changes are in place first helps a bit.. But naturally fixing the driver in advance won't help booting kernels before the driver changes with a newer dtb :) What helps though is to make sure git bisect works for building and booting already at -rc1 kernel to make debugging the issue easy. As -rc1 is used typically as the merge base the problem causing branches can be tested separately that way. Regards, Tony
[PATCH 3/4] thermal: ti-soc-thermal: Simplify polling with iopoll
We can use iopoll for checking the EOCZ (end of conversion) bit. And with this we now also want to handle the timeout errors properly. For omap3, we need about 1.2ms for the single mode sampling to wait for EOCZ down, so let's use 1.5ms timeout there. Waiting for sampling to start is faster and we can use 1ms timeout. Cc: Adam Ford Cc: Carl Philipp Klemm Cc: Eduardo Valentin Cc: H. Nikolaus Schaller Cc: Merlijn Wajer Cc: Pavel Machek Cc: Peter Ujfalusi Cc: Sebastian Reichel Signed-off-by: Tony Lindgren --- drivers/thermal/ti-soc-thermal/ti-bandgap.c | 30 ++--- 1 file changed, 14 insertions(+), 16 deletions(-) diff --git a/drivers/thermal/ti-soc-thermal/ti-bandgap.c b/drivers/thermal/ti-soc-thermal/ti-bandgap.c --- a/drivers/thermal/ti-soc-thermal/ti-bandgap.c +++ b/drivers/thermal/ti-soc-thermal/ti-bandgap.c @@ -15,7 +15,6 @@ #include #include #include -#include #include #include #include @@ -27,6 +26,7 @@ #include #include #include +#include #include #include #include @@ -604,7 +604,9 @@ static int ti_bandgap_force_single_read(struct ti_bandgap *bgp, int id) { struct temp_sensor_registers *tsr = bgp->conf->sensors[id].registers; - u32 counter; + void __iomem *temp_sensor_ctrl = bgp->base + tsr->temp_sensor_ctrl; + int error; + u32 val; /* Select continuous or single conversion mode */ if (TI_BANDGAP_HAS(bgp, MODE_CONFIG)) { @@ -619,26 +621,22 @@ ti_bandgap_force_single_read(struct ti_bandgap *bgp, int id) RMW_BITS(bgp, id, temp_sensor_ctrl, bgap_soc_mask, 1); /* Wait for EOCZ going up */ - counter = 1000; - while (--counter) { - if (ti_bandgap_readl(bgp, tsr->temp_sensor_ctrl) & - tsr->bgap_eocz_mask) - break; - udelay(1); - } + error = readl_poll_timeout_atomic(temp_sensor_ctrl, val, + val & tsr->bgap_eocz_mask, + 1, 1000); + if (error) + dev_warn(bgp->dev, "eocz timed out waiting high\n"); /* Clear Start of Conversion if available */ RMW_BITS(bgp, id, temp_sensor_ctrl, bgap_soc_mask, 0); } /* Wait for EOCZ going down, always needed even if no bgap_soc_mask */ - counter = 1000; - while (--counter) { - if (!(ti_bandgap_readl(bgp, tsr->temp_sensor_ctrl) & - tsr->bgap_eocz_mask)) - break; - udelay(1); - } + error = readl_poll_timeout_atomic(temp_sensor_ctrl, val, + !(val & tsr->bgap_eocz_mask), + 1, 1500); + if (error) + dev_warn(bgp->dev, "eocz timed out waiting low\n"); return 0; } -- 2.30.0
[PATCH 4/4] thermal: ti-soc-thermal: Use non-inverted define for omap4
When we set bit 10 high we use continuous mode and not single mode. Let's correct this to avoid confusion. No functional changes here, the code does the right thing with bit 10. Cc: Adam Ford Cc: Carl Philipp Klemm Cc: Eduardo Valentin Cc: H. Nikolaus Schaller Cc: Merlijn Wajer Cc: Pavel Machek Cc: Peter Ujfalusi Cc: Sebastian Reichel Signed-off-by: Tony Lindgren --- drivers/thermal/ti-soc-thermal/omap4-thermal-data.c | 4 ++-- drivers/thermal/ti-soc-thermal/omap4xxx-bandgap.h | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/thermal/ti-soc-thermal/omap4-thermal-data.c b/drivers/thermal/ti-soc-thermal/omap4-thermal-data.c --- a/drivers/thermal/ti-soc-thermal/omap4-thermal-data.c +++ b/drivers/thermal/ti-soc-thermal/omap4-thermal-data.c @@ -24,7 +24,7 @@ omap4430_mpu_temp_sensor_registers = { .bgap_dtemp_mask = OMAP4430_BGAP_TEMP_SENSOR_DTEMP_MASK, .bgap_mode_ctrl = OMAP4430_TEMP_SENSOR_CTRL_OFFSET, - .mode_ctrl_mask = OMAP4430_SINGLE_MODE_MASK, + .mode_ctrl_mask = OMAP4430_CONTINUOUS_MODE_MASK, .bgap_efuse = OMAP4430_FUSE_OPP_BGAP, }; @@ -97,7 +97,7 @@ omap4460_mpu_temp_sensor_registers = { .mask_cold_mask = OMAP4460_MASK_COLD_MASK, .bgap_mode_ctrl = OMAP4460_BGAP_CTRL_OFFSET, - .mode_ctrl_mask = OMAP4460_SINGLE_MODE_MASK, + .mode_ctrl_mask = OMAP4460_CONTINUOUS_MODE_MASK, .bgap_counter = OMAP4460_BGAP_COUNTER_OFFSET, .counter_mask = OMAP4460_COUNTER_MASK, diff --git a/drivers/thermal/ti-soc-thermal/omap4xxx-bandgap.h b/drivers/thermal/ti-soc-thermal/omap4xxx-bandgap.h --- a/drivers/thermal/ti-soc-thermal/omap4xxx-bandgap.h +++ b/drivers/thermal/ti-soc-thermal/omap4xxx-bandgap.h @@ -40,7 +40,7 @@ /* OMAP4430.TEMP_SENSOR bits */ #define OMAP4430_BGAP_TEMPSOFF_MASKBIT(12) #define OMAP4430_BGAP_TSHUT_MASK BIT(11) -#define OMAP4430_SINGLE_MODE_MASK BIT(10) +#define OMAP4430_CONTINUOUS_MODE_MASK BIT(10) #define OMAP4430_BGAP_TEMP_SENSOR_SOC_MASK BIT(9) #define OMAP4430_BGAP_TEMP_SENSOR_EOCZ_MASKBIT(8) #define OMAP4430_BGAP_TEMP_SENSOR_DTEMP_MASK (0xff << 0) @@ -113,7 +113,7 @@ #define OMAP4460_BGAP_TEMP_SENSOR_DTEMP_MASK (0x3ff << 0) /* OMAP4460.BANDGAP_CTRL bits */ -#define OMAP4460_SINGLE_MODE_MASK BIT(31) +#define OMAP4460_CONTINUOUS_MODE_MASK BIT(31) #define OMAP4460_MASK_HOT_MASK BIT(1) #define OMAP4460_MASK_COLD_MASKBIT(0) -- 2.30.0
[PATCH 1/4] thermal: ti-soc-thermal: Skip pointless register access for dra7
On dra7, there is no Start of Conversion (SOC) register bit and we have an empty bgap_soc_mask in the configuration for the thermal driver. Let's not do pointless reads and writes with the empty mask. There's also no point waiting for End of Conversion bit (EOCZ) to go high on dra7. We only care about it going down, and are now mostly timing out waiting for EOCZ high while it has already gone down. When we add checking for the timeout errors in a later patch, waiting for EOCZ high would cause bogus time out errors. Cc: Adam Ford Cc: Carl Philipp Klemm Cc: Eduardo Valentin Cc: H. Nikolaus Schaller Cc: Merlijn Wajer Cc: Pavel Machek Cc: Peter Ujfalusi Cc: Sebastian Reichel Signed-off-by: Tony Lindgren --- drivers/thermal/ti-soc-thermal/ti-bandgap.c | 29 +++-- 1 file changed, 15 insertions(+), 14 deletions(-) diff --git a/drivers/thermal/ti-soc-thermal/ti-bandgap.c b/drivers/thermal/ti-soc-thermal/ti-bandgap.c --- a/drivers/thermal/ti-soc-thermal/ti-bandgap.c +++ b/drivers/thermal/ti-soc-thermal/ti-bandgap.c @@ -602,29 +602,30 @@ void *ti_bandgap_get_sensor_data(struct ti_bandgap *bgp, int id) static int ti_bandgap_force_single_read(struct ti_bandgap *bgp, int id) { - u32 counter = 1000; - struct temp_sensor_registers *tsr; + struct temp_sensor_registers *tsr = bgp->conf->sensors[id].registers; + u32 counter; /* Select single conversion mode */ if (TI_BANDGAP_HAS(bgp, MODE_CONFIG)) RMW_BITS(bgp, id, bgap_mode_ctrl, mode_ctrl_mask, 0); - /* Start of Conversion = 1 */ - RMW_BITS(bgp, id, temp_sensor_ctrl, bgap_soc_mask, 1); + /* Set Start of Conversion if available */ + if (tsr->bgap_soc_mask) { + RMW_BITS(bgp, id, temp_sensor_ctrl, bgap_soc_mask, 1); - /* Wait for EOCZ going up */ - tsr = bgp->conf->sensors[id].registers; + /* Wait for EOCZ going up */ + counter = 1000; + while (--counter) { + if (ti_bandgap_readl(bgp, tsr->temp_sensor_ctrl) & + tsr->bgap_eocz_mask) + break; + } - while (--counter) { - if (ti_bandgap_readl(bgp, tsr->temp_sensor_ctrl) & - tsr->bgap_eocz_mask) - break; + /* Clear Start of Conversion if available */ + RMW_BITS(bgp, id, temp_sensor_ctrl, bgap_soc_mask, 0); } - /* Start of Conversion = 0 */ - RMW_BITS(bgp, id, temp_sensor_ctrl, bgap_soc_mask, 0); - - /* Wait for EOCZ going down */ + /* Wait for EOCZ going down, always needed even if no bgap_soc_mask */ counter = 1000; while (--counter) { if (!(ti_bandgap_readl(bgp, tsr->temp_sensor_ctrl) & -- 2.30.0
[PATCH 2/4] thermal: ti-soc-thermal: Fix stuck sensor with continuous mode for 4430
At least for 4430, trying to use the single conversion mode eventually hangs the thermal sensor. This can be quite easily seen with errors: thermal thermal_zone0: failed to read out thermal zone (-5) Also, trying to read the temperature shows a stuck value with: $ while true; do cat /sys/class/thermal/thermal_zone0/temp; done Where the temperature is not rising at all with the busy loop. Additionally, the EOCZ (end of conversion) bit is not rising on 4430 in single conversion mode while it works fine in continuous conversion mode. It is also possible that the hung temperature sensor can affect the thermal shutdown alert too. Let's fix the issue by adding TI_BANDGAP_FEATURE_CONT_MODE_ONLY flag and use it for 4430. Note that we also need to add udelay to for the EOCZ (end of conversion) bit polling as otherwise we have it time out too early on 4430. We'll be changing the loop to use iopoll in the following clean-up patch. Cc: Adam Ford Cc: Carl Philipp Klemm Cc: Eduardo Valentin Cc: H. Nikolaus Schaller Cc: Merlijn Wajer Cc: Pavel Machek Cc: Peter Ujfalusi Cc: Sebastian Reichel Signed-off-by: Tony Lindgren --- drivers/thermal/ti-soc-thermal/omap4-thermal-data.c | 3 ++- drivers/thermal/ti-soc-thermal/ti-bandgap.c | 13 ++--- drivers/thermal/ti-soc-thermal/ti-bandgap.h | 2 ++ 3 files changed, 14 insertions(+), 4 deletions(-) diff --git a/drivers/thermal/ti-soc-thermal/omap4-thermal-data.c b/drivers/thermal/ti-soc-thermal/omap4-thermal-data.c --- a/drivers/thermal/ti-soc-thermal/omap4-thermal-data.c +++ b/drivers/thermal/ti-soc-thermal/omap4-thermal-data.c @@ -58,7 +58,8 @@ omap4430_adc_to_temp[OMAP4430_ADC_END_VALUE - OMAP4430_ADC_START_VALUE + 1] = { const struct ti_bandgap_data omap4430_data = { .features = TI_BANDGAP_FEATURE_MODE_CONFIG | TI_BANDGAP_FEATURE_CLK_CTRL | - TI_BANDGAP_FEATURE_POWER_SWITCH, + TI_BANDGAP_FEATURE_POWER_SWITCH | + TI_BANDGAP_FEATURE_CONT_MODE_ONLY, .fclock_name = "bandgap_fclk", .div_ck_name = "bandgap_fclk", .conv_table = omap4430_adc_to_temp, diff --git a/drivers/thermal/ti-soc-thermal/ti-bandgap.c b/drivers/thermal/ti-soc-thermal/ti-bandgap.c --- a/drivers/thermal/ti-soc-thermal/ti-bandgap.c +++ b/drivers/thermal/ti-soc-thermal/ti-bandgap.c @@ -15,6 +15,7 @@ #include #include #include +#include #include #include #include @@ -605,9 +606,13 @@ ti_bandgap_force_single_read(struct ti_bandgap *bgp, int id) struct temp_sensor_registers *tsr = bgp->conf->sensors[id].registers; u32 counter; - /* Select single conversion mode */ - if (TI_BANDGAP_HAS(bgp, MODE_CONFIG)) - RMW_BITS(bgp, id, bgap_mode_ctrl, mode_ctrl_mask, 0); + /* Select continuous or single conversion mode */ + if (TI_BANDGAP_HAS(bgp, MODE_CONFIG)) { + if (TI_BANDGAP_HAS(bgp, CONT_MODE_ONLY)) + RMW_BITS(bgp, id, bgap_mode_ctrl, mode_ctrl_mask, 1); + else + RMW_BITS(bgp, id, bgap_mode_ctrl, mode_ctrl_mask, 0); + } /* Set Start of Conversion if available */ if (tsr->bgap_soc_mask) { @@ -619,6 +624,7 @@ ti_bandgap_force_single_read(struct ti_bandgap *bgp, int id) if (ti_bandgap_readl(bgp, tsr->temp_sensor_ctrl) & tsr->bgap_eocz_mask) break; + udelay(1); } /* Clear Start of Conversion if available */ @@ -631,6 +637,7 @@ ti_bandgap_force_single_read(struct ti_bandgap *bgp, int id) if (!(ti_bandgap_readl(bgp, tsr->temp_sensor_ctrl) & tsr->bgap_eocz_mask)) break; + udelay(1); } return 0; diff --git a/drivers/thermal/ti-soc-thermal/ti-bandgap.h b/drivers/thermal/ti-soc-thermal/ti-bandgap.h --- a/drivers/thermal/ti-soc-thermal/ti-bandgap.h +++ b/drivers/thermal/ti-soc-thermal/ti-bandgap.h @@ -280,6 +280,7 @@ struct ti_temp_sensor { * has Errata 814 * TI_BANDGAP_FEATURE_UNRELIABLE - used when the sensor readings are too * inaccurate. + * TI_BANDGAP_FEATURE_CONT_MODE_ONLY - used when single mode hangs the sensor * TI_BANDGAP_HAS(b, f) - macro to check if a bandgap device is capable of a * specific feature (above) or not. Return non-zero, if yes. */ @@ -295,6 +296,7 @@ struct ti_temp_sensor { #define TI_BANDGAP_FEATURE_HISTORY_BUFFER BIT(9) #define TI_BANDGAP_FEATURE_ERRATA_814 BIT(10) #define TI_BANDGAP_FEATURE_UNRELIABLE BIT(11) +#define TI_BANDGAP_FEATURE_CONT_MODE_ONLY BIT(12) #define TI_BANDGAP_HAS(b, f) \ ((b)->conf->features & TI_BANDGAP_FEATURE_ ## f) -- 2.30.0
[PATCHv2 0/4] Thermal fixes for omaps for single mode read
Hi all, Here's v2 set of thermal fixes for single mode read. Turns out the EOCZ and SOC bit handling is quite different between the various SoCs. With these changes we fix the following issues for reading a single sample: - Get rid of pointless register access and loops for dra7 - Fix omap3 to use proper timeouts, the current looping is way too short and always times out probably leading to bogus values as folks have reported - Fix omap4430 where EOCZ only seems to work for continuous mode Regards, Tony Changes since v1: - Use better MODE_CONFIG checks as suggested by Peter - Fix issues for omap3 as noted by Adam - Fix handling for dra7 Tony Lindgren (4): thermal: ti-soc-thermal: Skip pointless register access for dra7 thermal: ti-soc-thermal: Fix stuck sensor with continuous mode for 4430 thermal: ti-soc-thermal: Simplify polling with iopoll thermal: ti-soc-thermal: Use non-inverted define for omap4 .../ti-soc-thermal/omap4-thermal-data.c | 7 +-- .../thermal/ti-soc-thermal/omap4xxx-bandgap.h | 4 +- drivers/thermal/ti-soc-thermal/ti-bandgap.c | 54 ++- drivers/thermal/ti-soc-thermal/ti-bandgap.h | 2 + 4 files changed, 38 insertions(+), 29 deletions(-) -- 2.30.0
Re: [PATCH] bus: omap_l3_noc: mark l3 irqs as IRQF_NO_THREAD
* Grygorii Strashko [210128 21:16]: > The main purpose of l3 IRQs is to catch OCP bus access errors and identify > corresponding code places by showing call stack, so it's important to > handle L3 interconnect errors as fast as possible. On RT these IRQs will > became threaded and will be scheduled mach more late from the moment actual > error occurred so showing completely useless information. > > Hence, mark l3 IRQs as IRQF_NO_THREAD so they will not be forced threaded > on RT or if force_irqthreads = true. > > Fixes: 0ee7261c9212 ("drivers: bus: Move the OMAP interconnect driver to > drivers/bus/") Thanks applying into fixes. Tony
Re: [PATCH 1/2] ARM: dts: am335x-pocketbeagle: unique gpio-line-names
* Drew Fustini [210127 02:04]: > Based on linux-gpio discussion [1], it is best practice to make the > gpio-line-names unique. Generic names like "[ethernet]" are replaced > with the name of the unique signal on the AM3358 SoC ball corresponding > to the gpio line. "[NC]" is also renamed to the standard "NC" name to > represent "not connected". > > [1] https://lore.kernel.org/linux-gpio/20201216195357.GA2583366@x1/ So are these needed for v5.12 as fixes, or can these wait until after the merge window for v5.13? Regards, Tony
Re: [PATCH] ARM: dts: am33xx: add aliases for mmc interfaces
* Måns Rullgård [210129 11:40]: > Tony Lindgren writes: > > > * Mans Rullgard [210128 18:09]: > >> Without DT aliases, the numbering of mmc interfaces is unpredictable. > >> Adding them makes it possible to refer to devices consistently. The > >> popular suggestion to use UUIDs obviously doesn't work with a blank > >> device fresh from the factory. > >> > >> See fa2d0aa96941 "mmc: core: Allow setting slot index via device tree > >> alias" for more discussion. > > > > Sounds good to me, but will wait a few days before applying to make sure > > this is still what we have agreed on :) > > If it helps the decision, my existing systems fail to boot without > something like this due to the eMMC moving from /dev/mmcblk1 to mmcblk0, > at least sometimes. I guess the kernel cares deeply about not breaking > userspace, except when it doesn't give a damn. > > I've been fighting this problem in various forms for the last 10 years > or so, and I was hoping it would finally be over. Yes this issue has been bugging folks for long time. Applying into fixes thanks. Tony
Re: [PATCHv1] ASoC: cpcap: fix microphone timeslot mask
* Sebastian Reichel [210123 17:30]: > This is compile tested only, since I currently do not have > my Droid 4 ready for running some tests. Maybe Tony, Pavel or > Merlijn can give it a go using e.g. arecord. I just tried recording with arecord -D plughw:CARD=Audio,DEV=1 | hd but only see the header and no data.. DEV=0 won't produce anything, maybe I have the alsamixer settings wrong. Let me know if you want me to try something else. I do have the pending voice call patches applied on top, voice calls work just fine with your patch. So as it looks correct to me: Reviewed-by: Tony Lindgren
Re: [PATCH] PCI: dwc: layerscape: convert to builtin_platform_driver()
* Geert Uytterhoeven [210128 09:32]: > It wasn't. The regression is that the driver no longer probes at first > try, because its dependencies are now probed later. The question is: > why are the dependencies now probed later? How to fix that? I'm afraid that may be unfixable.. It depends on things like the bus driver probe that might get also deferred. As suggested, I agree it's best to get rid of builtin_platform_driver_probe where possible at the cost of dropping the __init as needed. To me it seems we can't even add a warning to __platform_driver_probe() if there's drv->driver.of_match_table for example. That warning would show up on all the devices with driver in question built in even if the device has no such hardware. Regards, Tony
Re: [PATCH] PCI: dwc: layerscape: convert to builtin_platform_driver()
Hi, * Michael Walle [210125 19:52]: > Although I do have the changes for the builtin_platform_driver_probe() > ready, I don't think it makes much sense to send these unless we agree > on the increased memory footprint. While there are just a few > builtin_platform_driver_probe() and memory increase _might_ be > negligible, there are many more module_platform_driver_probe(). I just noticed this thread today and have pretty much come to the same conclusions. No need to post a patch for pci-dra7xx.c, I already posted a patch for pci-dra7xx.c yesterday as part of genpd related changes. For me probing started breaking as the power-domains property got added. FYI, it's the following patch: [PATCH 01/15] PCI: pci-dra7xx: Prepare for deferred probe with module_platform_driver Regards, Tony
Re: [PATCH] ASoC: ti: Allocate dais dynamically for TDM and audio graph card
* Péter Ujfalusi [210126 06:00]: > On 1/24/21 11:27 AM, Pavel Machek wrote: > > From: Tony Lindgren > > + for (i = 0; i < mcbsp->dai_count; i++) { > > + struct snd_soc_dai_driver *dai = >dais[i]; > > + > > + dai->name = devm_kasprintf(mcbsp->dev, GFP_KERNEL, "%s-dai%i", > > + dev_name(mcbsp->dev), i); > > + > > + if (i == 0) { > > + dai->probe = omap_mcbsp_probe; > > + dai->remove = omap_mcbsp_remove; > > + dai->ops = _dai_ops; > > + } > > You are effectively creating extra dummy-dais (no ops), but naming them as > McBSP. > The dummy-dais will only work if the real dai is in use and the dai link > which contains the real dai must be configured (TDM slots, format, channels) > to accomodate the link which contains the dummy-dai. > > The idea did not aged well for me ;) > It still looks and sounds like a hack to model the TDM slots on a single DAI > as multiple DAIs just to satisfy a generic binding which is not aimed to > satisfy the droid4 setup (which is far from anything simple). After thinking about this a bit more, I think the voice call dai should be created by the voice dai. When we have an active voice call, the data transfer is completely out of control of the kernel mcbsp driver. It needs to be only configured on the pmic. So I'm suggesting tha we create the modem voice call dai as a child for sound/soc/codecs/cpcap.c, does that sound OK to you guys? I think from snd-soc-audio-graph-card binding point of view, we'd just move the cpu_dai_mdm endpoint out of the mcbsp in the device tree and drop the $subject patch. Then the dts for the pmic voice codec becomes something like this (untested): cpcap_audio: audio-codec { #sound-dai-cells = <1>; #address-cells = <1>; #size-cells = <0>; port@0 { reg = <0>; cpcap_audio_codec0: endpoint { }; }; port@1 { reg = <1>; cpcap_audio_codec1: endpoint@0 { }; cpu_dai_mdm: endpoint@1 { reg = <1>; dai-format = "dsp_a"; frame-master = <_audio_codec1>; bitclock-master = <_audio_codec1>; remote-endpoint = <_mdm6600_audio_codec0>; }; }; }; For things like recording a voice call, I think mcbsp could be configured to also listen on the traffic and dump it out. I guess that could also happen directly with calls from the sound/soc/codecs/cpcap.c driver to the mcbsp driver since we havethe audio graph mapping. Anyways, that's a separate series of patches, still something to consider. Regards, Tony
[PATCH 3/3] bus: ti-sysc: Detect more modules for debugging
We want to see what the interconnect target module names are for debugging. Signed-off-by: Tony Lindgren --- drivers/bus/ti-sysc.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/drivers/bus/ti-sysc.c b/drivers/bus/ti-sysc.c --- a/drivers/bus/ti-sysc.c +++ b/drivers/bus/ti-sysc.c @@ -1496,12 +1496,16 @@ static const struct sysc_revision_quirk sysc_revision_quirks[] = { SYSC_QUIRK("dwc3", 0, 0, 0x10, -ENODEV, 0x500a0200, 0x, 0), SYSC_QUIRK("d2d", 0x4a0b6000, 0, 0x10, 0x14, 0x0010, 0x, 0), SYSC_QUIRK("d2d", 0x4a0cd000, 0, 0x10, 0x14, 0x0010, 0x, 0), + SYSC_QUIRK("elm", 0x4808, 0, 0x10, 0x14, 0x0020, 0x, 0), + SYSC_QUIRK("emif", 0, 0, -ENODEV, -ENODEV, 0x40441403, 0x0fff, 0), + SYSC_QUIRK("emif", 0, 0, -ENODEV, -ENODEV, 0x50440500, 0x, 0), SYSC_QUIRK("epwmss", 0, 0, 0x4, -ENODEV, 0x4741, 0x, 0), SYSC_QUIRK("gpu", 0, 0x1fc00, 0x1fc10, -ENODEV, 0, 0, 0), SYSC_QUIRK("gpu", 0, 0xfe00, 0xfe10, -ENODEV, 0x4000 , 0x, 0), SYSC_QUIRK("hdmi", 0, 0, 0x10, -ENODEV, 0x50031d00, 0x, 0), SYSC_QUIRK("hsi", 0, 0, 0x10, 0x14, 0x50043101, 0x, 0), SYSC_QUIRK("iss", 0, 0, 0x10, -ENODEV, 0x4101, 0x, 0), + SYSC_QUIRK("keypad", 0x4a31c000, 0, 0x10, 0x14, 0x0020, 0x, 0), SYSC_QUIRK("mcasp", 0, 0, 0x4, -ENODEV, 0x44306302, 0x, 0), SYSC_QUIRK("mcasp", 0, 0, 0x4, -ENODEV, 0x44307b02, 0x, 0), SYSC_QUIRK("mcbsp", 0, -ENODEV, 0x8c, -ENODEV, 0, 0, 0), @@ -1513,11 +1517,14 @@ static const struct sysc_revision_quirk sysc_revision_quirks[] = { SYSC_QUIRK("ocp2scp", 0, 0, -ENODEV, -ENODEV, 0x50060007, 0x, 0), SYSC_QUIRK("padconf", 0, 0, 0x10, -ENODEV, 0x4fff0800, 0x, 0), SYSC_QUIRK("padconf", 0, 0, -ENODEV, -ENODEV, 0x40001100, 0x, 0), + SYSC_QUIRK("pcie", 0x5100, -ENODEV, -ENODEV, -ENODEV, 0, 0, 0), + SYSC_QUIRK("pcie", 0x5180, -ENODEV, -ENODEV, -ENODEV, 0, 0, 0), SYSC_QUIRK("prcm", 0, 0, -ENODEV, -ENODEV, 0x4100, 0x, 0), SYSC_QUIRK("prcm", 0, 0, -ENODEV, -ENODEV, 0x4102, 0x, 0), SYSC_QUIRK("prcm", 0, 0, -ENODEV, -ENODEV, 0x4400, 0x, 0), SYSC_QUIRK("rfbi", 0x4832a800, 0, 0x10, 0x14, 0x0010, 0x, 0), SYSC_QUIRK("rfbi", 0x58002000, 0, 0x10, 0x14, 0x0010, 0x, 0), + SYSC_QUIRK("sata", 0, 0xfc, 0x1100, -ENODEV, 0x5e412000, 0x, 0), SYSC_QUIRK("scm", 0, 0, 0x10, -ENODEV, 0x4900, 0x, 0), SYSC_QUIRK("scm", 0, 0, -ENODEV, -ENODEV, 0x4e8b0100, 0x, 0), SYSC_QUIRK("scm", 0, 0, -ENODEV, -ENODEV, 0x4f000100, 0x, 0), -- 2.30.0
[PATCH 0/3] Few ti-sysc changes for v5.12 merge window
Hi, Here are few ti-sysc changes to mostly to have l4_wkup and l4_cfg interconnects before l4_per interconnects. Regards, Tony Tony Lindgren (3): bus: ti-sysc: Fix initializing module_pa for modules without sysc register bus: ti-sysc: Probe for l4_wkup and l4_cfg interconnect devices first bus: ti-sysc: Detect more modules for debugging drivers/bus/ti-sysc.c | 62 --- 1 file changed, 59 insertions(+), 3 deletions(-) -- 2.30.0
[PATCH 2/3] bus: ti-sysc: Probe for l4_wkup and l4_cfg interconnect devices first
We want to probe l4_wkup and l4_cfg interconnect devices first to avoid issues with missing resources. Otherwise we attempt to probe l4_per devices first causing pointless deferred probe and also annoyingh renumbering of the MMC devices for example. Signed-off-by: Tony Lindgren --- drivers/bus/ti-sysc.c | 49 +++ 1 file changed, 49 insertions(+) diff --git a/drivers/bus/ti-sysc.c b/drivers/bus/ti-sysc.c --- a/drivers/bus/ti-sysc.c +++ b/drivers/bus/ti-sysc.c @@ -635,6 +635,51 @@ static int sysc_parse_and_check_child_range(struct sysc *ddata) return 0; } +/* Interconnect instances to probe before l4_per instances */ +static struct resource early_bus_ranges[] = { + /* am3/4 l4_wkup */ + { .start = 0x44c0, .end = 0x44c0 + 0x30, }, + /* omap4/5 and dra7 l4_cfg */ + { .start = 0x4a00, .end = 0x4a00 + 0x30, }, + /* omap4 l4_wkup */ + { .start = 0x4a30, .end = 0x4a30 + 0x3, }, + /* omap5 and dra7 l4_wkup without dra7 dcan segment */ + { .start = 0x4ae0, .end = 0x4ae0 + 0x3, }, +}; + +static atomic_t sysc_defer = ATOMIC_INIT(10); + +/** + * sysc_defer_non_critical - defer non_critical interconnect probing + * @ddata: device driver data + * + * We want to probe l4_cfg and l4_wkup interconnect instances before any + * l4_per instances as l4_per instances depend on resources on l4_cfg and + * l4_wkup interconnects. + */ +static int sysc_defer_non_critical(struct sysc *ddata) +{ + struct resource *res; + int i; + + if (!atomic_read(_defer)) + return 0; + + for (i = 0; i < ARRAY_SIZE(early_bus_ranges); i++) { + res = _bus_ranges[i]; + if (ddata->module_pa >= res->start && + ddata->module_pa <= res->end) { + atomic_set(_defer, 0); + + return 0; + } + } + + atomic_dec_if_positive(_defer); + + return -EPROBE_DEFER; +} + static struct device_node *stdout_path; static void sysc_init_stdout_path(struct sysc *ddata) @@ -860,6 +905,10 @@ static int sysc_map_and_check_registers(struct sysc *ddata) if (error) return error; + error = sysc_defer_non_critical(ddata); + if (error) + return error; + sysc_check_children(ddata); if (!of_get_property(np, "reg", NULL)) -- 2.30.0
[PATCH 1/3] bus: ti-sysc: Fix initializing module_pa for modules without sysc register
We have interconnect target modules with no known registers using only clocks and resets, but we still want to detect them based on the module IO range. So let's call sysc_parse_and_check_child_range() earlier so we have module_pa properly initialized. Fixes: 2928135c93f8 ("bus: ti-sysc: Support modules without control registers") Signed-off-by: Tony Lindgren --- drivers/bus/ti-sysc.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/bus/ti-sysc.c b/drivers/bus/ti-sysc.c --- a/drivers/bus/ti-sysc.c +++ b/drivers/bus/ti-sysc.c @@ -856,15 +856,15 @@ static int sysc_map_and_check_registers(struct sysc *ddata) struct device_node *np = ddata->dev->of_node; int error; - if (!of_get_property(np, "reg", NULL)) - return 0; - error = sysc_parse_and_check_child_range(ddata); if (error) return error; sysc_check_children(ddata); + if (!of_get_property(np, "reg", NULL)) + return 0; + error = sysc_parse_registers(ddata); if (error) return error; -- 2.30.0
Re: [PATCH] ARM: dts: omap3-igep: Change email address in copyright notice
* Javier Martinez Canillas [210118 10:17]: > I've switched employer a long time ago and the mentioned email address no > longer exists. Use my personal address to prevent the issue in the future. Thanks applying into omap-for-v5.12/dt. Tony
Re: [PATCH] arm/mach-omap2: fix spellint typo
* Wang Qing [200917 10:49]: > Change the comment typo: "ununsed" -> "unused". Sorry looks like this is still pending, applying into omap-for-v5.12/soc. Thanks, Tony
Re: [PATCH V2] ARM: dts: omap36xx: Remove turbo mode for 1GHz variants
* Adam Ford [210109 19:01]: > Previously, the 1GHz variants were marked as a turbo, > because that variant has reduced thermal operating range. > > Now that the thermal throttling is in place, it should be > safe to remove the turbo-mode from the 1GHz variants, because > the CPU will automatically slow if the thermal limit is reached. Thanks applying into omap-for-v5.12/dt. Tony
Re: [PATCH] ARM: dts: omap3-echo: Add speaker sound card support
* André Hentschel [201227 19:18]: > This adds audio playback to the first generation Amazon Echo > > Signed-off-by: André Hentschel > --- > > It took me by far too long to get this working as the codec sets one > important bit based on the > combination of provided supplies. That was just too hidden for me. > The first generation Amazon Echo was codenamed Misto, so I used that for the > sound card name. Cool, so it's now usable as a music player then :) Applying into omap-for-v5.12/dt thanks. Tony