Re: [PATCH 2/3] dt-bindings: clock: ti: remove unstable remark

2024-02-28 Thread Tony Lindgren
* 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

2023-09-26 Thread Tony Lindgren
* 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>

2021-04-17 Thread Tony Lindgren
* 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

2021-04-15 Thread Tony Lindgren
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

2021-04-09 Thread tip-bot2 for Tony Lindgren
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

2021-04-09 Thread tip-bot2 for Tony Lindgren
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

2021-04-09 Thread tip-bot2 for Tony Lindgren
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

2021-04-09 Thread tip-bot2 for Tony Lindgren
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

2021-04-08 Thread Tony Lindgren
* 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

2021-04-08 Thread Tony Lindgren
* 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

2021-04-07 Thread Tony Lindgren
* 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

2021-04-07 Thread Tony Lindgren
* 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

2021-04-07 Thread Tony Lindgren
* 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

2021-04-07 Thread Tony Lindgren
* 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

2021-04-06 Thread Tony Lindgren
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

2021-03-31 Thread Tony Lindgren
* 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

2021-03-31 Thread Tony Lindgren
* 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

2021-03-31 Thread Tony Lindgren
* 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

2021-03-31 Thread Tony Lindgren
* 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

2021-03-31 Thread Tony Lindgren
* 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

2021-03-31 Thread Tony Lindgren
* 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

2021-03-30 Thread Tony Lindgren
* 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

2021-03-30 Thread Tony Lindgren
* 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

2021-03-24 Thread Tony Lindgren
* 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

2021-03-24 Thread Tony Lindgren
* 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

2021-03-24 Thread Tony Lindgren
* 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

2021-03-24 Thread Tony Lindgren
* 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

2021-03-24 Thread Tony Lindgren
* 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

2021-03-24 Thread Tony Lindgren
* 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

2021-03-24 Thread Tony Lindgren
* 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

2021-03-24 Thread Tony Lindgren
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

2021-03-24 Thread Tony Lindgren
* 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()

2021-03-24 Thread Tony Lindgren
* 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

2021-03-24 Thread Tony Lindgren
* 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

2021-03-24 Thread Tony Lindgren
* 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'

2021-03-24 Thread Tony Lindgren
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

2021-03-23 Thread Tony Lindgren
* 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

2021-03-23 Thread Tony Lindgren
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

2021-03-23 Thread Tony Lindgren
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

2021-03-23 Thread Tony Lindgren
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

2021-03-23 Thread Tony Lindgren
* 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

2021-03-22 Thread Tony Lindgren
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

2021-03-22 Thread Tony Lindgren
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

2021-03-19 Thread Tony Lindgren
* 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

2021-03-19 Thread Tony Lindgren
* 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

2021-03-17 Thread Tony Lindgren
* 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

2021-03-12 Thread Tony Lindgren
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

2021-03-12 Thread Tony Lindgren
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

2021-03-12 Thread Tony Lindgren
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

2021-03-09 Thread Tony Lindgren
* 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

2021-03-08 Thread Tony Lindgren
* 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()

2021-03-08 Thread Tony Lindgren
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

2021-03-08 Thread Tony Lindgren
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

2021-03-08 Thread Tony Lindgren
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

2021-03-08 Thread Tony Lindgren
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

2021-03-08 Thread Tony Lindgren
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

2021-03-08 Thread Tony Lindgren
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

2021-03-04 Thread Tony Lindgren
* 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()

2021-03-04 Thread Tony Lindgren
* 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

2021-03-03 Thread Tony Lindgren
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

2021-03-03 Thread Tony Lindgren
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

2021-03-03 Thread Tony Lindgren
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()

2021-03-03 Thread Tony Lindgren
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

2021-03-03 Thread Tony Lindgren
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

2021-03-03 Thread Tony Lindgren
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

2021-03-03 Thread Tony Lindgren
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[]

2021-02-25 Thread Tony Lindgren
* 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

2021-02-21 Thread Tony Lindgren
* 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

2021-02-19 Thread Tony Lindgren
* 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

2021-02-18 Thread Tony Lindgren
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

2021-02-18 Thread Tony Lindgren
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

2021-02-17 Thread Tony Lindgren
* 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

2021-02-15 Thread Tony Lindgren
* 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

2021-02-14 Thread Tony Lindgren
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

2021-02-10 Thread Tony Lindgren
* 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

2021-02-10 Thread Tony Lindgren
* 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

2021-02-10 Thread Tony Lindgren
* 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

2021-02-10 Thread Tony Lindgren
* 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

2021-02-10 Thread Tony Lindgren
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

2021-02-08 Thread Tony Lindgren
* 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

2021-02-05 Thread Tony Lindgren
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

2021-02-05 Thread Tony Lindgren
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

2021-02-05 Thread Tony Lindgren
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

2021-02-05 Thread Tony Lindgren
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

2021-02-05 Thread Tony Lindgren
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

2021-02-03 Thread Tony Lindgren
* 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

2021-02-03 Thread Tony Lindgren
* 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

2021-02-03 Thread Tony Lindgren
* 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

2021-01-30 Thread Tony Lindgren
* 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()

2021-01-28 Thread Tony Lindgren
* 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()

2021-01-28 Thread Tony Lindgren
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

2021-01-27 Thread Tony Lindgren
* 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

2021-01-26 Thread Tony Lindgren
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

2021-01-26 Thread Tony Lindgren
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

2021-01-26 Thread Tony Lindgren
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

2021-01-26 Thread Tony Lindgren
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

2021-01-26 Thread Tony Lindgren
* 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

2021-01-26 Thread Tony Lindgren
* 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

2021-01-26 Thread Tony Lindgren
* 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

2021-01-26 Thread Tony Lindgren
* 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


  1   2   3   4   5   6   7   8   9   10   >