* [PATCH v2] hardlockup: detect hard lockups without NMIs using secondary cpus
From: Frederic Weisbecker @ 2013-01-15 0:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1357941108-14138-1-git-send-email-ccross@android.com>
2013/1/11 Colin Cross <ccross@android.com>:
> Emulate NMIs on systems where they are not available by using timer
> interrupts on other cpus. Each cpu will use its softlockup hrtimer
> to check that the next cpu is processing hrtimer interrupts by
> verifying that a counter is increasing.
>
> This patch is useful on systems where the hardlockup detector is not
> available due to a lack of NMIs, for example most ARM SoCs.
> Without this patch any cpu stuck with interrupts disabled can
> cause a hardware watchdog reset with no debugging information,
> but with this patch the kernel can detect the lockup and panic,
> which can result in useful debugging info.
>
> Signed-off-by: Colin Cross <ccross@android.com>
I believe this is pretty much what the RCU stall detector does
already: checks for other CPUs being responsive. The only difference
is on how it checks that. For RCU it's about checking for CPUs
reporting quiescent states when requested to do so. In your case it's
about ensuring the hrtimer interrupt is well handled.
One thing you can do is to enqueue an RCU callback (cal_rcu()) every
minute so you can force other CPUs to report quiescent states
periodically and thus check for lockups.
Now you'll face the same problem in the end: if you don't have NMIs,
you won't have a very useful report.
^ permalink raw reply
* [PATCH v2] hardlockup: detect hard lockups without NMIs using secondary cpus
From: Colin Cross @ 2013-01-15 0:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130114154914.6d69eb27.akpm@linux-foundation.org>
On Mon, Jan 14, 2013 at 3:49 PM, Andrew Morton
<akpm@linux-foundation.org> wrote:
> On Fri, 11 Jan 2013 13:51:48 -0800
> Colin Cross <ccross@android.com> wrote:
>
>> Emulate NMIs on systems where they are not available by using timer
>> interrupts on other cpus. Each cpu will use its softlockup hrtimer
>> to check that the next cpu is processing hrtimer interrupts by
>> verifying that a counter is increasing.
>
> Seems sensible.
>
>> This patch is useful on systems where the hardlockup detector is not
>> available due to a lack of NMIs, for example most ARM SoCs.
>> Without this patch any cpu stuck with interrupts disabled can
>> cause a hardware watchdog reset with no debugging information,
>> but with this patch the kernel can detect the lockup and panic,
>> which can result in useful debugging info.
>
> But we don't get the target cpu's stack, yes? That's a pretty big loss.
It's a huge loss, but its still useful. For one, it can separate
"linux locked up one cpu" bugs from "the whole cpu complex stopped
responding" bugs, which are much more common than you would hope on
ARM cpus. Also, as a separate patch I'm hoping to add reading the
DBGPCSR register of both cpus during panic, which will at least give
you the PC of the cpu that is stuck.
>>
>> ...
>>
>> +#ifdef CONFIG_HARDLOCKUP_DETECTOR_OTHER_CPU
>> +static unsigned int watchdog_next_cpu(unsigned int cpu)
>> +{
>> + cpumask_t cpus = watchdog_cpus;
>
> cpumask_t can be tremendously huge and putting one on the stack is
> risky. Can we use watchdog_cpus directly here? Perhaps with a lock?
> or take a copy into a static local, with a lock?
Sure, I can use a lock around it. I'm used to very small numbers of cpus.
>> + unsigned int next_cpu;
>> +
>> + next_cpu = cpumask_next(cpu, &cpus);
>> + if (next_cpu >= nr_cpu_ids)
>> + next_cpu = cpumask_first(&cpus);
>> +
>> + if (next_cpu == cpu)
>> + return nr_cpu_ids;
>> +
>> + return next_cpu;
>> +}
>> +
>> +static int is_hardlockup_other_cpu(unsigned int cpu)
>> +{
>> + unsigned long hrint = per_cpu(hrtimer_interrupts, cpu);
>> +
>> + if (per_cpu(hrtimer_interrupts_saved, cpu) == hrint)
>> + return 1;
>> +
>> + per_cpu(hrtimer_interrupts_saved, cpu) = hrint;
>> + return 0;
>> +}
>
> This could return a bool type.
I based it on is_hardlockup, but I can convert it to a bool.
>> +static void watchdog_check_hardlockup_other_cpu(void)
>> +{
>> + unsigned int next_cpu;
>> +
>> + /*
>> + * Test for hardlockups every 3 samples. The sample period is
>> + * watchdog_thresh * 2 / 5, so 3 samples gets us back to slightly over
>> + * watchdog_thresh (over by 20%).
>> + */
>> + if (__this_cpu_read(hrtimer_interrupts) % 3 != 0)
>> + return;
>
> The hardwired interval Seems Wrong. watchdog_thresh is tunable at runtime.
>
> The comment could do with some fleshing out. *why* do we want to test
> at an interval "slightly over watchdog_thresh"? What's going on here?
I'll reword it. We don't want to be slightly over watchdog_thresh,
ideally we would be exactly at watchdog_thresh. However, since this
relies on the hrtimer interrupts that are scheduled at watchdog_thresh
* 2 / 5, there is no multiple of hrtimer_interrupts that will result
in watchdog_thresh. watchdog_thresh * 2 / 5 * 3 (watchdog_thresh *
1.2) is the closest I can get to testing for a hardlockup once every
watchdog_thresh seconds.
>> + /* check for a hardlockup on the next cpu */
>> + next_cpu = watchdog_next_cpu(smp_processor_id());
>> + if (next_cpu >= nr_cpu_ids)
>> + return;
>> +
>> + smp_rmb();
>
> Mystery barrier (always) needs an explanatory comment, please.
OK. Will add: smp_rmb matches smp_wmb in watchdog_nmi_enable and
watchdog_nmi_disable to ensure watchdog_nmi_touch is updated for a cpu
before any other cpu sees it is online.
>> + if (per_cpu(watchdog_nmi_touch, next_cpu) == true) {
>> + per_cpu(watchdog_nmi_touch, next_cpu) = false;
>> + return;
>> + }
>
> I wonder if a well-timed CPU plug/unplug could result in two CPUs
> simultaneously checking one other CPU's state.
It can, which is why I set watchdog_nmi_touch for a cpu when it comes
online or when the previous cpu goes offline. That should prevent a
false positive by preventing the first cpu that checks from updating
hrtimer_interrupts_saved.
>> + if (is_hardlockup_other_cpu(next_cpu)) {
>> + /* only warn once */
>> + if (per_cpu(hard_watchdog_warn, next_cpu) == true)
>> + return;
>> +
>> + if (hardlockup_panic)
>> + panic("Watchdog detected hard LOCKUP on cpu %u", next_cpu);
>> + else
>> + WARN(1, "Watchdog detected hard LOCKUP on cpu %u", next_cpu);
>
> I suggest we use messages here which make it clear to people who read
> kernel output that this was triggered by hrtimers, not by NMI. Most
> importantly because people will need to know that the CPU which locked
> up is *not this CPU* and that any backtrace from the reporting CPU is
> misleading.
>
> Also, there was never any sense in making the LOCKUP all-caps ;)
I'll change to "hrtimer watchdog on cpu %u detected hard lockup on cpu
%u". Given the discussion above about the lack of backtraces on the
affected cpu, I'll also change the WARN to pr_warn, since the
backtrace of the warning cpu is misleading. The panic will still get
the backtrace of the detecting cpu, but hopefully the clearer message
will avoid confusing people.
>> + per_cpu(hard_watchdog_warn, next_cpu) = true;
>> + } else {
>> + per_cpu(hard_watchdog_warn, next_cpu) = false;
>> + }
>> +}
>> +#else
>> +static inline void watchdog_check_hardlockup_other_cpu(void) { return; }
>> +#endif
>> +
>>
>> ...
>>
>> --- a/lib/Kconfig.debug
>> +++ b/lib/Kconfig.debug
>> @@ -191,15 +191,27 @@ config LOCKUP_DETECTOR
>> The overhead should be minimal. A periodic hrtimer runs to
>> generate interrupts and kick the watchdog task every 4 seconds.
>> An NMI is generated every 10 seconds or so to check for hardlockups.
>> + If NMIs are not available on the platform, every 12 seconds the
>
> hm. Is the old "4 seconds" still true/accurate/complete?
Yes, unless watchdog_thresh is changed on the command line or at run
time. I can update the message to clarify that 4 seconds is the
default.
>> + hrtimer interrupt on one cpu will be used to check for hardlockups
>> + on the next cpu.
>>
>> The frequency of hrtimer and NMI events and the soft and hard lockup
>> thresholds can be controlled through the sysctl watchdog_thresh.
>>
>> -config HARDLOCKUP_DETECTOR
>> +config HARDLOCKUP_DETECTOR_NMI
>> def_bool y
>> depends on LOCKUP_DETECTOR && !HAVE_NMI_WATCHDOG
>> depends on PERF_EVENTS && HAVE_PERF_EVENTS_NMI
>
> Confused. I'd have expected this to depend on HAVE_NMI_WATCHDOG,
> rather than -no-that. What does "HAVE_NMI_WATCHDOG" actually mean and
> what's happening here?
HAVE_NMI_WATCHDOG used to be called ARCH_HAS_NMI_WATCHDOG, which was a
little clearer. I believe it means that the architecture has its own
NMI watchdog implementation, and doesn't require this perf-based one.
^ permalink raw reply
* [PATCH v2] hardlockup: detect hard lockups without NMIs using secondary cpus
From: Colin Cross @ 2013-01-15 0:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAFTL4hzYkPCmkfqBafkTA5E_snkLoC_y3p9xwumj=L1xWAWK0g@mail.gmail.com>
On Mon, Jan 14, 2013 at 4:13 PM, Frederic Weisbecker <fweisbec@gmail.com> wrote:
> 2013/1/11 Colin Cross <ccross@android.com>:
>> Emulate NMIs on systems where they are not available by using timer
>> interrupts on other cpus. Each cpu will use its softlockup hrtimer
>> to check that the next cpu is processing hrtimer interrupts by
>> verifying that a counter is increasing.
>>
>> This patch is useful on systems where the hardlockup detector is not
>> available due to a lack of NMIs, for example most ARM SoCs.
>> Without this patch any cpu stuck with interrupts disabled can
>> cause a hardware watchdog reset with no debugging information,
>> but with this patch the kernel can detect the lockup and panic,
>> which can result in useful debugging info.
>>
>> Signed-off-by: Colin Cross <ccross@android.com>
>
> I believe this is pretty much what the RCU stall detector does
> already: checks for other CPUs being responsive. The only difference
> is on how it checks that. For RCU it's about checking for CPUs
> reporting quiescent states when requested to do so. In your case it's
> about ensuring the hrtimer interrupt is well handled.
>
> One thing you can do is to enqueue an RCU callback (cal_rcu()) every
> minute so you can force other CPUs to report quiescent states
> periodically and thus check for lockups.
That's a good point, I'll take a look at using that. A minute is too
long, some SoCs have maximum HW watchdog periods of under 30 seconds,
but a call_rcu every 10-20 seconds might be sufficient.
> Now you'll face the same problem in the end: if you don't have NMIs,
> you won't have a very useful report.
Yes, but its still better than a silent reset.
^ permalink raw reply
* [PATCH v2] hardlockup: detect hard lockups without NMIs using secondary cpus
From: Andrew Morton @ 2013-01-15 0:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMbhsRR29Zhje9mGtUwHfUsX+eFsggYkVMHPyQ+zgrGUp_rqTQ@mail.gmail.com>
On Mon, 14 Jan 2013 16:19:23 -0800
Colin Cross <ccross@android.com> wrote:
> >> +static void watchdog_check_hardlockup_other_cpu(void)
> >> +{
> >> + unsigned int next_cpu;
> >> +
> >> + /*
> >> + * Test for hardlockups every 3 samples. The sample period is
> >> + * watchdog_thresh * 2 / 5, so 3 samples gets us back to slightly over
> >> + * watchdog_thresh (over by 20%).
> >> + */
> >> + if (__this_cpu_read(hrtimer_interrupts) % 3 != 0)
> >> + return;
> >
> > The hardwired interval Seems Wrong. watchdog_thresh is tunable at runtime.
> >
> > The comment could do with some fleshing out. *why* do we want to test
> > at an interval "slightly over watchdog_thresh"? What's going on here?
>
> I'll reword it. We don't want to be slightly over watchdog_thresh,
> ideally we would be exactly at watchdog_thresh. However, since this
> relies on the hrtimer interrupts that are scheduled at watchdog_thresh
> * 2 / 5, there is no multiple of hrtimer_interrupts that will result
> in watchdog_thresh. watchdog_thresh * 2 / 5 * 3 (watchdog_thresh *
> 1.2) is the closest I can get to testing for a hardlockup once every
> watchdog_thresh seconds.
It needs more than rewording, doesn't it? What happens if watchdog_thresh is
altered at runtime?
^ permalink raw reply
* [PATCH v2] hardlockup: detect hard lockups without NMIs using secondary cpus
From: Frederic Weisbecker @ 2013-01-15 0:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMbhsRQv=ogNmkK=Np6JGM-iuG=aocqb_4aMBC6CW5mpkGvpmw@mail.gmail.com>
2013/1/15 Colin Cross <ccross@android.com>:
> On Mon, Jan 14, 2013 at 4:13 PM, Frederic Weisbecker <fweisbec@gmail.com> wrote:
>> I believe this is pretty much what the RCU stall detector does
>> already: checks for other CPUs being responsive. The only difference
>> is on how it checks that. For RCU it's about checking for CPUs
>> reporting quiescent states when requested to do so. In your case it's
>> about ensuring the hrtimer interrupt is well handled.
>>
>> One thing you can do is to enqueue an RCU callback (cal_rcu()) every
>> minute so you can force other CPUs to report quiescent states
>> periodically and thus check for lockups.
>
> That's a good point, I'll take a look at using that. A minute is too
> long, some SoCs have maximum HW watchdog periods of under 30 seconds,
> but a call_rcu every 10-20 seconds might be sufficient.
Sure. And you can tune CONFIG_RCU_CPU_STALL_TIMEOUT accordingly.
^ permalink raw reply
* [PATCH v2] hardlockup: detect hard lockups without NMIs using secondary cpus
From: Colin Cross @ 2013-01-15 0:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130114162504.e667a4be.akpm@linux-foundation.org>
On Mon, Jan 14, 2013 at 4:25 PM, Andrew Morton
<akpm@linux-foundation.org> wrote:
> On Mon, 14 Jan 2013 16:19:23 -0800
> Colin Cross <ccross@android.com> wrote:
>
>> >> +static void watchdog_check_hardlockup_other_cpu(void)
>> >> +{
>> >> + unsigned int next_cpu;
>> >> +
>> >> + /*
>> >> + * Test for hardlockups every 3 samples. The sample period is
>> >> + * watchdog_thresh * 2 / 5, so 3 samples gets us back to slightly over
>> >> + * watchdog_thresh (over by 20%).
>> >> + */
>> >> + if (__this_cpu_read(hrtimer_interrupts) % 3 != 0)
>> >> + return;
>> >
>> > The hardwired interval Seems Wrong. watchdog_thresh is tunable at runtime.
>> >
>> > The comment could do with some fleshing out. *why* do we want to test
>> > at an interval "slightly over watchdog_thresh"? What's going on here?
>>
>> I'll reword it. We don't want to be slightly over watchdog_thresh,
>> ideally we would be exactly at watchdog_thresh. However, since this
>> relies on the hrtimer interrupts that are scheduled at watchdog_thresh
>> * 2 / 5, there is no multiple of hrtimer_interrupts that will result
>> in watchdog_thresh. watchdog_thresh * 2 / 5 * 3 (watchdog_thresh *
>> 1.2) is the closest I can get to testing for a hardlockup once every
>> watchdog_thresh seconds.
>
> It needs more than rewording, doesn't it? What happens if watchdog_thresh is
> altered at runtime?
I'm not sure what you mean. If watchdog_thresh changes, the next
hrtimer interrupt on each cpu will move the following hrtimer
interrupt forward by the new watchdog_thresh * 2 / 5. There may be a
single cycle of watchdog checks at an intermediate period, but nothing
bad should happen.
This code doesn't ever deal with watchdog_thresh directly, it is only
counting hrtimer interrupts. 3 hrtimer interrupts is always a
reasonable approximation of watchdog_thresh.
^ permalink raw reply
* shmobile and struct sys_timer removal conflicts
From: Simon Horman @ 2013-01-15 0:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50F445E5.6010203@wwwdotorg.org>
On Mon, Jan 14, 2013 at 10:52:37AM -0700, Stephen Warren wrote:
> Simon,
>
> I notice that the following shmobile-related commits in next-20130114
> add new ARM machine descriptors, but set the .timer field rather than
> the new .init_time field. I believe the code in these commits won't
> build in linux-next or Linux 3.9 once it's released:
>
> a625586 ARM: mach-shmobile: kzm9g: Reference DT implementation
> ac0876f ARM: shmobile: armadillo800eva: Reference DT implementation
> be1fc65 ARM: shmobile: add a reference DT implementation for mackerel
> 66f1162 ARM: mach-shmobile: sh73a0: Minimal setup using DT
>
> In order to solve this problem, you'll need to adjust those changes
> according to:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git timer/cleanup
>
> (where "adjust" is probably "rebase on top of")
Hi Stephen,
thanks. I'll get this sorted out.
^ permalink raw reply
* [GIT PULL v2] Renesas ARM-based SoC defconfig for v3.9
From: Simon Horman @ 2013-01-15 0:49 UTC (permalink / raw)
To: linux-arm-kernel
Hi Olof, Hi Arnd,
please consider the following defconfig enhancements for 3.9.
----------------------------------------------------------------
The following changes since commit a49f0d1ea3ec94fc7cf33a7c36a16343b74bd565:
Linux 3.8-rc1 (2012-12-21 17:19:00 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git
for you to fetch changes up to 8098df15c26b2bf16924df5a134d1a649692ab62:
ARM: mach-shmobile: kzm9d: update defconfig (2013-01-15 08:57:09 +0900)
----------------------------------------------------------------
Simon Horman (5):
ARM: mach-shmobile: mackerel: update defconfig
ARM: mach-shmobile: fix memory size for kota2_defconfig
ARM: mach-shmobile: kzm9g: defconfig update
ARM: mach-shmobile: armadillo: update defconfig
ARM: mach-shmobile: kzm9d: update defconfig
arch/arm/boot/dts/emev2-kzm9d.dts | 2 +-
arch/arm/boot/dts/r8a7740-armadillo800eva.dts | 4 ++++
arch/arm/boot/dts/sh7372-mackerel.dts | 4 ++++
arch/arm/boot/dts/sh73a0-kzm9g.dts | 4 ++++
arch/arm/configs/armadillo800eva_defconfig | 5 ++---
arch/arm/configs/kota2_defconfig | 2 +-
arch/arm/configs/kzm9d_defconfig | 4 +---
arch/arm/configs/kzm9g_defconfig | 4 +++-
arch/arm/configs/mackerel_defconfig | 2 +-
9 files changed, 21 insertions(+), 10 deletions(-)
^ permalink raw reply
* [PATCH 1/5] ARM: mach-shmobile: mackerel: update defconfig
From: Simon Horman @ 2013-01-15 0:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358210975-26970-1-git-send-email-horms+renesas@verge.net.au>
* Enable ARM_APPENDED_DTB
Typically the bootloader of a mackerel board does not support DT
so this option is useful
* Add "rw" to command line
This appears to be necessary for a successful NFS-root boot
* Remove memchunk from kernel command line,
it is not used outside of arch/sh
* Move command line to dts
This brings us one small step closer to sharing defconfig
between mackerel and other boards
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
arch/arm/boot/dts/sh7372-mackerel.dts | 4 ++++
arch/arm/configs/mackerel_defconfig | 2 +-
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/sh7372-mackerel.dts b/arch/arm/boot/dts/sh7372-mackerel.dts
index 286f0ca..2623de8 100644
--- a/arch/arm/boot/dts/sh7372-mackerel.dts
+++ b/arch/arm/boot/dts/sh7372-mackerel.dts
@@ -15,6 +15,10 @@
model = "Mackerel (AP4 EVM 2nd)";
compatible = "renesas,mackerel";
+ chosen {
+ bootargs = "console=tty0, console=ttySC0,115200 earlyprintk=sh-sci.0,115200 root=/dev/nfs nfsroot=,tcp,v3 ip=dhcp mem=240m rw";
+ };
+
memory {
device_type = "memory";
reg = <0x40000000 0x10000000>;
diff --git a/arch/arm/configs/mackerel_defconfig b/arch/arm/configs/mackerel_defconfig
index 2098ce1..e6881ac 100644
--- a/arch/arm/configs/mackerel_defconfig
+++ b/arch/arm/configs/mackerel_defconfig
@@ -23,7 +23,7 @@ CONFIG_AEABI=y
CONFIG_FORCE_MAX_ZONEORDER=15
CONFIG_ZBOOT_ROM_TEXT=0x0
CONFIG_ZBOOT_ROM_BSS=0x0
-CONFIG_CMDLINE="console=tty0, console=ttySC0,115200 earlyprintk=sh-sci.0,115200 root=/dev/nfs nfsroot=,tcp,v3 ip=dhcp memchunk.vpu=64m memchunk.veu0=8m memchunk.spu0=2m mem=240m"
+CONFIG_ARM_APPENDED_DTB=y
CONFIG_KEXEC=y
# CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set
CONFIG_PM=y
--
1.7.10.4
^ permalink raw reply related
* [PATCH 2/5] ARM: mach-shmobile: fix memory size for kota2_defconfig
From: Simon Horman @ 2013-01-15 0:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358210975-26970-1-git-send-email-horms+renesas@verge.net.au>
The CONFIG_MEMORY_SIZE value is interpreted as a 32 bit integer, which
makes sense on a system without PAE. It appears that a trailing 0 was
appended to the value and after some testing it appears that 0x1e000000 is
the correct value.
Without this patch, building kota2_defconfig results in:
/home/arnd/linux-arm/arch/arm/kernel/setup.c:790:2: warning: large integer implicitly truncated to unsigned type [-Woverflow]
Reported-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Olof Johansson <olof@lixom.net>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
arch/arm/configs/kota2_defconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/configs/kota2_defconfig b/arch/arm/configs/kota2_defconfig
index fa83db1..57ad3d4 100644
--- a/arch/arm/configs/kota2_defconfig
+++ b/arch/arm/configs/kota2_defconfig
@@ -21,7 +21,7 @@ CONFIG_ARCH_SHMOBILE=y
CONFIG_KEYBOARD_GPIO_POLLED=y
CONFIG_ARCH_SH73A0=y
CONFIG_MACH_KOTA2=y
-CONFIG_MEMORY_SIZE=0x1e0000000
+CONFIG_MEMORY_SIZE=0x1e000000
# CONFIG_SH_TIMER_TMU is not set
# CONFIG_SWP_EMULATE is not set
CONFIG_CPU_BPREDICT_DISABLE=y
--
1.7.10.4
^ permalink raw reply related
* [PATCH 3/5] ARM: mach-shmobile: kzm9g: defconfig update
From: Simon Horman @ 2013-01-15 0:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358210975-26970-1-git-send-email-horms+renesas@verge.net.au>
* Enable ARM_APPENDED_DTB
Typically the bootloader of a kzm9g board does not support DT
so this option is useful.
* Use voltage regulators by default
* Move command line to dts
This brings us one small step closer to sharing defconfig
between kzm9g and other boards
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
arch/arm/boot/dts/sh73a0-kzm9g.dts | 4 ++++
arch/arm/configs/kzm9g_defconfig | 4 +++-
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/sh73a0-kzm9g.dts b/arch/arm/boot/dts/sh73a0-kzm9g.dts
index bcb9119..9a43879 100644
--- a/arch/arm/boot/dts/sh73a0-kzm9g.dts
+++ b/arch/arm/boot/dts/sh73a0-kzm9g.dts
@@ -15,6 +15,10 @@
model = "KZM-A9-GT";
compatible = "renesas,kzm9g", "renesas,sh73a0";
+ chosen {
+ bootargs = "console=tty0 console=ttySC4,115200 root=/dev/nfs ip=dhcp ignore_loglevel earlyprintk=sh-sci.4,115200";
+ };
+
memory {
device_type = "memory";
reg = <0x41000000 0x1e800000>;
diff --git a/arch/arm/configs/kzm9g_defconfig b/arch/arm/configs/kzm9g_defconfig
index afbae28..670c3b6 100644
--- a/arch/arm/configs/kzm9g_defconfig
+++ b/arch/arm/configs/kzm9g_defconfig
@@ -39,7 +39,7 @@ CONFIG_AEABI=y
CONFIG_HIGHMEM=y
CONFIG_ZBOOT_ROM_TEXT=0x0
CONFIG_ZBOOT_ROM_BSS=0x0
-CONFIG_CMDLINE="console=tty0 console=ttySC4,115200 root=/dev/nfs ip=dhcp ignore_loglevel earlyprintk=sh-sci.4,115200"
+CONFIG_ARM_APPENDED_DTB=y
CONFIG_KEXEC=y
CONFIG_VFP=y
CONFIG_NEON=y
@@ -85,6 +85,8 @@ CONFIG_I2C_CHARDEV=y
CONFIG_I2C_SH_MOBILE=y
CONFIG_GPIO_PCF857X=y
# CONFIG_HWMON is not set
+CONFIG_REGULATOR=y
+CONFIG_REGULATOR_DUMMY=y
CONFIG_FB=y
CONFIG_FB_SH_MOBILE_LCDC=y
CONFIG_FRAMEBUFFER_CONSOLE=y
--
1.7.10.4
^ permalink raw reply related
* [PATCH 4/5] ARM: mach-shmobile: armadillo: update defconfig
From: Simon Horman @ 2013-01-15 0:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358210975-26970-1-git-send-email-horms+renesas@verge.net.au>
* Enable ARM_APPENDED_DTB
Typically the bootloader of an armadillo board does not support DT
so this option is useful.
* Do not disable SUSPEND
Suspend seems to work fine on the armadillo
* Enable PM_RUNTIME
This also seems to work fine.
* Move command line to dts
This brings us one small step closer to sharing defconfig
between armadillo and other boards
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
arch/arm/boot/dts/r8a7740-armadillo800eva.dts | 4 ++++
arch/arm/configs/armadillo800eva_defconfig | 5 ++---
2 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/r8a7740-armadillo800eva.dts b/arch/arm/boot/dts/r8a7740-armadillo800eva.dts
index a7505a9..52cfead 100644
--- a/arch/arm/boot/dts/r8a7740-armadillo800eva.dts
+++ b/arch/arm/boot/dts/r8a7740-armadillo800eva.dts
@@ -15,6 +15,10 @@
model = "armadillo 800 eva";
compatible = "renesas,armadillo800eva";
+ chosen {
+ bootargs = "console=tty0 console=ttySC1,115200 earlyprintk=sh-sci.1,115200 ignore_loglevel root=/dev/nfs ip=dhcp nfsroot=,rsize=4096,wsize=4096 rw";
+ };
+
memory {
device_type = "memory";
reg = <0x40000000 0x20000000>;
diff --git a/arch/arm/configs/armadillo800eva_defconfig b/arch/arm/configs/armadillo800eva_defconfig
index 2e1a825..f9e2701 100644
--- a/arch/arm/configs/armadillo800eva_defconfig
+++ b/arch/arm/configs/armadillo800eva_defconfig
@@ -34,12 +34,11 @@ CONFIG_AEABI=y
CONFIG_FORCE_MAX_ZONEORDER=13
CONFIG_ZBOOT_ROM_TEXT=0x0
CONFIG_ZBOOT_ROM_BSS=0x0
-CONFIG_CMDLINE="console=tty0 console=ttySC1,115200 earlyprintk=sh-sci.1,115200 ignore_loglevel root=/dev/nfs ip=dhcp nfsroot=,rsize=4096,wsize=4096 rw"
-CONFIG_CMDLINE_FORCE=y
+CONFIG_ARM_APPENDED_DTB=y
CONFIG_KEXEC=y
CONFIG_VFP=y
# CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set
-# CONFIG_SUSPEND is not set
+CONFIG_PM_RUNTIME=y
CONFIG_NET=y
CONFIG_PACKET=y
CONFIG_UNIX=y
--
1.7.10.4
^ permalink raw reply related
* [PATCH 5/5] ARM: mach-shmobile: kzm9d: update defconfig
From: Simon Horman @ 2013-01-15 0:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358210975-26970-1-git-send-email-horms+renesas@verge.net.au>
* Do not disable SUSPEND
Suspend seems to work fine on the kzm9d.
This is part of an effort reduce differences between mach-shmobile
defconfigs with a view to using a common defconfig.
* Enable PM_RUNTIME
This also seems to work fine on the kzm9d.
This is part of an effort reduce differences between mach-shmobile
defconfigs with a view to using a common defconfig.
* Move kernel command line from defconfig to dts.
This brings us one small step closer to sharing defconfig
between kzm9d and other boards.
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
arch/arm/boot/dts/emev2-kzm9d.dts | 2 +-
arch/arm/configs/kzm9d_defconfig | 4 +---
2 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/emev2-kzm9d.dts b/arch/arm/boot/dts/emev2-kzm9d.dts
index 297e3ba..b9b3241 100644
--- a/arch/arm/boot/dts/emev2-kzm9d.dts
+++ b/arch/arm/boot/dts/emev2-kzm9d.dts
@@ -21,6 +21,6 @@
};
chosen {
- bootargs = "console=ttyS1,115200n81";
+ bootargs = "console=tty0 console=ttyS1,115200n81 earlyprintk=serial8250-em.1,115200n81 mem=128M at 0x40000000 ignore_loglevel root=/dev/nfs ip=dhcp nfsroot=,rsize=4096,wsize=4096";
};
};
diff --git a/arch/arm/configs/kzm9d_defconfig b/arch/arm/configs/kzm9d_defconfig
index 8c49df6..6c37f4a 100644
--- a/arch/arm/configs/kzm9d_defconfig
+++ b/arch/arm/configs/kzm9d_defconfig
@@ -32,11 +32,9 @@ CONFIG_FORCE_MAX_ZONEORDER=13
CONFIG_ZBOOT_ROM_TEXT=0x0
CONFIG_ZBOOT_ROM_BSS=0x0
CONFIG_ARM_APPENDED_DTB=y
-CONFIG_CMDLINE="console=tty0 console=ttyS1,115200n81 earlyprintk=serial8250-em.1,115200n81 mem=128M at 0x40000000 ignore_loglevel root=/dev/nfs ip=dhcp nfsroot=,rsize=4096,wsize=4096"
-CONFIG_CMDLINE_FORCE=y
CONFIG_VFP=y
# CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set
-# CONFIG_SUSPEND is not set
+CONFIG_PM_RUNTIME=y
CONFIG_NET=y
CONFIG_PACKET=y
CONFIG_UNIX=y
--
1.7.10.4
^ permalink raw reply related
* [PATCH] clk: max77686: Avoid double free at remove time
From: Mike Turquette @ 2013-01-15 1:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1357520719-3782-1-git-send-email-laurent.pinchart@ideasonboard.com>
Quoting Laurent Pinchart (2013-01-06 17:05:19)
> The clk_lookup entry is dropped at remove time by a call to
> clkdev_drop(). That function frees the entry, which is also freed by the
> driver core as it has been allocated through devm_kzalloc(). This
> results in a double free.
>
> Use kzalloc() instead of devm_kzalloc() to fix this.
>
> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Hi Laurent,
Thanks for the fix. Applied to clk-next.
Regards,
Mike
> ---
> drivers/clk/clk-max77686.c | 3 +--
> 1 files changed, 1 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/clk/clk-max77686.c b/drivers/clk/clk-max77686.c
> index d098f72..6de05c5 100644
> --- a/drivers/clk/clk-max77686.c
> +++ b/drivers/clk/clk-max77686.c
> @@ -130,8 +130,7 @@ static int max77686_clk_register(struct device *dev,
> if (IS_ERR(clk))
> return -ENOMEM;
>
> - max77686->lookup = devm_kzalloc(dev, sizeof(struct clk_lookup),
> - GFP_KERNEL);
> + max77686->lookup = kzalloc(sizeof(struct clk_lookup), GFP_KERNEL);
> if (IS_ERR(max77686->lookup))
> return -ENOMEM;
>
> --
> Regards,
>
> Laurent Pinchart
^ permalink raw reply
* [PATCH v3 1/3] usb: fsl-mxc-udc: replace cpu_is_xxx() with platform_device_id
From: Peter Chen @ 2013-01-15 1:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130114175724.GD12611@arwen.pp.htv.fi>
On Mon, Jan 14, 2013 at 07:57:24PM +0200, Felipe Balbi wrote:
> On Mon, Jan 14, 2013 at 06:54:22PM +0100, Marc Kleine-Budde wrote:
> > On 01/14/2013 06:40 PM, Felipe Balbi wrote:
> > > Hi,
> > >
> > > On Mon, Jan 14, 2013 at 08:56:33PM +0800, Peter Chen wrote:
> > >
> > > <snip>
> > >
> > >>>> Usually there isn't any Changelog between IP cores used in the different
> > >>>> fsl processors (at least available outside of fsl), that makes it quite
> > >>>> difficult to say if something found on one imx is really the same as on
> > >>>> the other one. And they (usually) don't provide any versioning
> > >>>> information in a register or the documentation.
> > >>>>
> > >>>> just my 2?
> > >>>
> > >>> $SUBJECT is trying to differentiate a single feature (or maybe two) to
> > >>> replace cpu_is_xxx(), then expose that on driver_data without creating
> > >>> one enum value for each release from fsl.
> > >>
> > >> Felipe, every one or two SoCs may have their special operations for
> > >> integrate PHY interface, clk operation, or workaround for IC
> > >> limitation.
> > >
> > > the particular PHY and clk used should be hidden by phy layer and clk
> > > API respectively. Workarounds, fair enough, we need to handle them; but
> > > ideally those should be based on runtime revision detection, not some
> > > hackery using driver_data.
> >
> > If this is actually possible, I'd love to do this. But IP vendor don't
> > include a version register in their cores. :(
>
> then fair enough, driver_data or platform_data is the way to go, still
> my point (a) below is valid.
I will send v5 patch with your suggestion.
>
> --
> balbi
--
Best Regards,
Peter Chen
^ permalink raw reply
* [PATCH v2] hardlockup: detect hard lockups without NMIs using secondary cpus
From: Colin Cross @ 2013-01-15 1:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMbhsRR29Zhje9mGtUwHfUsX+eFsggYkVMHPyQ+zgrGUp_rqTQ@mail.gmail.com>
On Mon, Jan 14, 2013 at 4:19 PM, Colin Cross <ccross@android.com> wrote:
> On Mon, Jan 14, 2013 at 3:49 PM, Andrew Morton
> <akpm@linux-foundation.org> wrote:
>> On Fri, 11 Jan 2013 13:51:48 -0800
>> Colin Cross <ccross@android.com> wrote:
>>
>>> Emulate NMIs on systems where they are not available by using timer
>>> interrupts on other cpus. Each cpu will use its softlockup hrtimer
>>> to check that the next cpu is processing hrtimer interrupts by
>>> verifying that a counter is increasing.
>>
>> Seems sensible.
>>
>>> This patch is useful on systems where the hardlockup detector is not
>>> available due to a lack of NMIs, for example most ARM SoCs.
>>> Without this patch any cpu stuck with interrupts disabled can
>>> cause a hardware watchdog reset with no debugging information,
>>> but with this patch the kernel can detect the lockup and panic,
>>> which can result in useful debugging info.
>>
>> But we don't get the target cpu's stack, yes? That's a pretty big loss.
>
> It's a huge loss, but its still useful. For one, it can separate
> "linux locked up one cpu" bugs from "the whole cpu complex stopped
> responding" bugs, which are much more common than you would hope on
> ARM cpus. Also, as a separate patch I'm hoping to add reading the
> DBGPCSR register of both cpus during panic, which will at least give
> you the PC of the cpu that is stuck.
>
>>>
>>> ...
>>>
>>> +#ifdef CONFIG_HARDLOCKUP_DETECTOR_OTHER_CPU
>>> +static unsigned int watchdog_next_cpu(unsigned int cpu)
>>> +{
>>> + cpumask_t cpus = watchdog_cpus;
>>
>> cpumask_t can be tremendously huge and putting one on the stack is
>> risky. Can we use watchdog_cpus directly here? Perhaps with a lock?
>> or take a copy into a static local, with a lock?
>
> Sure, I can use a lock around it. I'm used to very small numbers of cpus.
>
On second thought, I'm just going to remove the local copy and read
the global directly. watchdog_cpus is updated with atomic bitmask
operations, so there is no erroneous value that could be returned when
referencing the global directly that couldn't also occur with a
slightly different order of updates. The local copy is also not
completely atomic, since the bitmask could span multiple words. All
intermediate values during multiple sequential updates should already
be handled by setting watchdog_nmi_touch on the appropriate cpus
during watchdog_nmi_enable and watchdog_nmi_disable.
^ permalink raw reply
* [PATCH] clk: prima2: enable dt-binding clkdev mapping
From: Barry Song @ 2013-01-15 1:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130114215259.23734.68185@quantum>
Hi Mike,
2013/1/15 Mike Turquette <mturquette@linaro.org>:
> Quoting Barry Song (2012-12-20 00:51:31)
>> From: Barry Song <Baohua.Song@csr.com>
>>
>> this patche deletes hard code that registers clkdev by things like:
>> clk_register_clkdev(clk, NULL, "b0030000.nand");
>> clk_register_clkdev(clk, NULL, "b0040000.audio");
>> clk_register_clkdev(clk, NULL, "b0080000.usp");
>> prima2 clock controller becomes a clock provider and every dt node
>> just declares its clock sources by dt prop.
>>
>> it also makes us easier to extend this driver to support both prima2
>> and marco as marco has different address mapping with prima2.
>>
>> Signed-off-by: Barry Song <Baohua.Song@csr.com>
>
> Barry,
>
> The changes to clk-prima2.c look OK to me. Did you want me to take this
> patch through clk-next?
yes. since it has no conflict with what i am handling in my machine codes.
>
> Thanks,
> Mike
>
>> ---
>> .../devicetree/bindings/clock/prima2-clock.txt | 73 +++++++
>> arch/arm/boot/dts/prima2.dtsi | 31 +++-
>> drivers/clk/clk-prima2.c | 205 ++++++++------------
>> 3 files changed, 183 insertions(+), 126 deletions(-)
>> create mode 100644 Documentation/devicetree/bindings/clock/prima2-clock.txt
-barry
^ permalink raw reply
* [PATCH v2] hardlockup: detect hard lockups without NMIs using secondary cpus
From: Colin Cross @ 2013-01-15 1:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAFTL4hxnCn13PigcWjrcnSV9RAz5gSX-VtQk9J8HEbQco7jbbQ@mail.gmail.com>
On Mon, Jan 14, 2013 at 4:25 PM, Frederic Weisbecker <fweisbec@gmail.com> wrote:
> 2013/1/15 Colin Cross <ccross@android.com>:
>> On Mon, Jan 14, 2013 at 4:13 PM, Frederic Weisbecker <fweisbec@gmail.com> wrote:
>>> I believe this is pretty much what the RCU stall detector does
>>> already: checks for other CPUs being responsive. The only difference
>>> is on how it checks that. For RCU it's about checking for CPUs
>>> reporting quiescent states when requested to do so. In your case it's
>>> about ensuring the hrtimer interrupt is well handled.
>>>
>>> One thing you can do is to enqueue an RCU callback (cal_rcu()) every
>>> minute so you can force other CPUs to report quiescent states
>>> periodically and thus check for lockups.
>>
>> That's a good point, I'll take a look at using that. A minute is too
>> long, some SoCs have maximum HW watchdog periods of under 30 seconds,
>> but a call_rcu every 10-20 seconds might be sufficient.
>
> Sure. And you can tune CONFIG_RCU_CPU_STALL_TIMEOUT accordingly.
After considering this, I think the hrtimer watchdog is more useful.
RCU stalls are not usually panic events, and I wouldn't want to add a
panic on every RCU stall. The lack of stack traces on the affected
cpu makes a panic important. I'm planning to add an ARM DBGPCSR panic
handler, which will be able to dump the PC of a stuck cpu even if it
is not responding to interrupts. kexec or kgdb on panic might also
allow some inspection of the stack on stuck cpu.
Failing to process interrupts is a much more serious event than an RCU
stall, and being able to detect them separately may be very valuable
for debugging.
^ permalink raw reply
* [PATCH v5 0/3] Fix the Build error for fsl_mxc_udc.c
From: Peter Chen @ 2013-01-15 2:29 UTC (permalink / raw)
To: linux-arm-kernel
Changes for v5:
- Using strcmp to get specific SoC
- Delete one cpu_is_mx35() as it has already pdata runtime check
Changes for v4:
- Using pdev's struct resource to do ioremap
- Add ioremap return value check
Changes for v3:
- Split the one big patch into three patches
Changes for v2:
- Add const for fsl_udc_devtype
- Do ioremap for phy address at fsl-mxc-udc
Peter Chen (3):
usb: fsl-mxc-udc: replace cpu_is_xxx() with platform_device_id
usb: fsl_mxc_udc: replace MX35_IO_ADDRESS to ioremap
ARM: i.MX clock: Change the connection-id for fsl-usb2-udc
arch/arm/mach-imx/clk-imx25.c | 6 +-
arch/arm/mach-imx/clk-imx27.c | 6 +-
arch/arm/mach-imx/clk-imx31.c | 6 +-
arch/arm/mach-imx/clk-imx35.c | 6 +-
arch/arm/mach-imx/clk-imx51-imx53.c | 6 +-
arch/arm/mach-imx/devices/devices-common.h | 1 +
arch/arm/mach-imx/devices/platform-fsl-usb2-udc.c | 15 ++++---
drivers/usb/gadget/fsl_mxc_udc.c | 40 ++++++++++++------
drivers/usb/gadget/fsl_udc_core.c | 46 +++++++++++++--------
drivers/usb/gadget/fsl_usb2_udc.h | 5 +-
10 files changed, 82 insertions(+), 55 deletions(-)
^ permalink raw reply
* [PATCH v5 1/3] usb: fsl-mxc-udc: replace cpu_is_xxx() with platform_device_id
From: Peter Chen @ 2013-01-15 2:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358216975-1404-1-git-send-email-peter.chen@freescale.com>
As mach/hardware.h is deleted, we need to use platform_device_id to
differentiate SoCs. Besides, one cpu_is_mx35 is useless as it has
already used pdata to differentiate runtime
Meanwhile we update the platform code accordingly.
Signed-off-by: Peter Chen <peter.chen@freescale.com>
---
arch/arm/mach-imx/devices/devices-common.h | 1 +
arch/arm/mach-imx/devices/platform-fsl-usb2-udc.c | 15 ++++---
drivers/usb/gadget/fsl_mxc_udc.c | 24 +++++-------
drivers/usb/gadget/fsl_udc_core.c | 42 +++++++++++++--------
4 files changed, 45 insertions(+), 37 deletions(-)
diff --git a/arch/arm/mach-imx/devices/devices-common.h b/arch/arm/mach-imx/devices/devices-common.h
index 6277baf..9bd5777 100644
--- a/arch/arm/mach-imx/devices/devices-common.h
+++ b/arch/arm/mach-imx/devices/devices-common.h
@@ -63,6 +63,7 @@ struct platform_device *__init imx_add_flexcan(
#include <linux/fsl_devices.h>
struct imx_fsl_usb2_udc_data {
+ const char *devid;
resource_size_t iobase;
resource_size_t irq;
};
diff --git a/arch/arm/mach-imx/devices/platform-fsl-usb2-udc.c b/arch/arm/mach-imx/devices/platform-fsl-usb2-udc.c
index 37e4439..fb527c7 100644
--- a/arch/arm/mach-imx/devices/platform-fsl-usb2-udc.c
+++ b/arch/arm/mach-imx/devices/platform-fsl-usb2-udc.c
@@ -11,35 +11,36 @@
#include "../hardware.h"
#include "devices-common.h"
-#define imx_fsl_usb2_udc_data_entry_single(soc) \
+#define imx_fsl_usb2_udc_data_entry_single(soc, _devid) \
{ \
+ .devid = _devid, \
.iobase = soc ## _USB_OTG_BASE_ADDR, \
.irq = soc ## _INT_USB_OTG, \
}
#ifdef CONFIG_SOC_IMX25
const struct imx_fsl_usb2_udc_data imx25_fsl_usb2_udc_data __initconst =
- imx_fsl_usb2_udc_data_entry_single(MX25);
+ imx_fsl_usb2_udc_data_entry_single(MX25, "imx-udc-mx25");
#endif /* ifdef CONFIG_SOC_IMX25 */
#ifdef CONFIG_SOC_IMX27
const struct imx_fsl_usb2_udc_data imx27_fsl_usb2_udc_data __initconst =
- imx_fsl_usb2_udc_data_entry_single(MX27);
+ imx_fsl_usb2_udc_data_entry_single(MX27, "imx-udc-mx27");
#endif /* ifdef CONFIG_SOC_IMX27 */
#ifdef CONFIG_SOC_IMX31
const struct imx_fsl_usb2_udc_data imx31_fsl_usb2_udc_data __initconst =
- imx_fsl_usb2_udc_data_entry_single(MX31);
+ imx_fsl_usb2_udc_data_entry_single(MX31, "imx-udc-mx31");
#endif /* ifdef CONFIG_SOC_IMX31 */
#ifdef CONFIG_SOC_IMX35
const struct imx_fsl_usb2_udc_data imx35_fsl_usb2_udc_data __initconst =
- imx_fsl_usb2_udc_data_entry_single(MX35);
+ imx_fsl_usb2_udc_data_entry_single(MX35, "imx-udc-mx35");
#endif /* ifdef CONFIG_SOC_IMX35 */
#ifdef CONFIG_SOC_IMX51
const struct imx_fsl_usb2_udc_data imx51_fsl_usb2_udc_data __initconst =
- imx_fsl_usb2_udc_data_entry_single(MX51);
+ imx_fsl_usb2_udc_data_entry_single(MX51, "imx-udc-mx51");
#endif
struct platform_device *__init imx_add_fsl_usb2_udc(
@@ -57,7 +58,7 @@ struct platform_device *__init imx_add_fsl_usb2_udc(
.flags = IORESOURCE_IRQ,
},
};
- return imx_add_platform_device_dmamask("fsl-usb2-udc", -1,
+ return imx_add_platform_device_dmamask(data->devid, -1,
res, ARRAY_SIZE(res),
pdata, sizeof(*pdata), DMA_BIT_MASK(32));
}
diff --git a/drivers/usb/gadget/fsl_mxc_udc.c b/drivers/usb/gadget/fsl_mxc_udc.c
index 1b0f086..1176bd8 100644
--- a/drivers/usb/gadget/fsl_mxc_udc.c
+++ b/drivers/usb/gadget/fsl_mxc_udc.c
@@ -18,8 +18,6 @@
#include <linux/platform_device.h>
#include <linux/io.h>
-#include <mach/hardware.h>
-
static struct clk *mxc_ahb_clk;
static struct clk *mxc_per_clk;
static struct clk *mxc_ipg_clk;
@@ -59,7 +57,7 @@ int fsl_udc_clk_init(struct platform_device *pdev)
clk_prepare_enable(mxc_per_clk);
/* make sure USB_CLK is running at 60 MHz +/- 1000 Hz */
- if (!cpu_is_mx51()) {
+ if (strcmp(pdev->id_entry->name, "imx-udc-mx51")) {
freq = clk_get_rate(mxc_per_clk);
if (pdata->phy_mode != FSL_USB2_PHY_ULPI &&
(freq < 59999000 || freq > 60001000)) {
@@ -82,17 +80,15 @@ eclkrate:
void fsl_udc_clk_finalize(struct platform_device *pdev)
{
struct fsl_usb2_platform_data *pdata = pdev->dev.platform_data;
- if (cpu_is_mx35()) {
- unsigned int v;
-
- /* workaround ENGcm09152 for i.MX35 */
- if (pdata->workaround & FLS_USB2_WORKAROUND_ENGCM09152) {
- v = readl(MX35_IO_ADDRESS(MX35_USB_BASE_ADDR +
- USBPHYCTRL_OTGBASE_OFFSET));
- writel(v | USBPHYCTRL_EVDO,
- MX35_IO_ADDRESS(MX35_USB_BASE_ADDR +
- USBPHYCTRL_OTGBASE_OFFSET));
- }
+ unsigned int v;
+
+ /* workaround ENGcm09152 for i.MX35 */
+ if (pdata->workaround & FLS_USB2_WORKAROUND_ENGCM09152) {
+ v = readl(MX35_IO_ADDRESS(MX35_USB_BASE_ADDR +
+ USBPHYCTRL_OTGBASE_OFFSET));
+ writel(v | USBPHYCTRL_EVDO,
+ MX35_IO_ADDRESS(MX35_USB_BASE_ADDR +
+ USBPHYCTRL_OTGBASE_OFFSET));
}
/* ULPI transceivers don't need usbpll */
diff --git a/drivers/usb/gadget/fsl_udc_core.c b/drivers/usb/gadget/fsl_udc_core.c
index c19f7f1..c971e84 100644
--- a/drivers/usb/gadget/fsl_udc_core.c
+++ b/drivers/usb/gadget/fsl_udc_core.c
@@ -41,6 +41,7 @@
#include <linux/fsl_devices.h>
#include <linux/dmapool.h>
#include <linux/delay.h>
+#include <linux/of_device.h>
#include <asm/byteorder.h>
#include <asm/io.h>
@@ -2438,11 +2439,6 @@ static int __init fsl_udc_probe(struct platform_device *pdev)
unsigned int i;
u32 dccparams;
- if (strcmp(pdev->name, driver_name)) {
- VDBG("Wrong device");
- return -ENODEV;
- }
-
udc_controller = kzalloc(sizeof(struct fsl_udc), GFP_KERNEL);
if (udc_controller == NULL) {
ERR("malloc udc failed\n");
@@ -2756,22 +2752,36 @@ static int fsl_udc_otg_resume(struct device *dev)
return fsl_udc_resume(NULL);
}
-
/*-------------------------------------------------------------------------
Register entry point for the peripheral controller driver
--------------------------------------------------------------------------*/
-
+static const struct platform_device_id fsl_udc_devtype[] = {
+ {
+ .name = "imx-udc-mx25",
+ }, {
+ .name = "imx-udc-mx27",
+ }, {
+ .name = "imx-udc-mx31",
+ }, {
+ .name = "imx-udc-mx35",
+ }, {
+ .name = "imx-udc-mx51",
+ }
+};
+MODULE_DEVICE_TABLE(platform, fsl_udc_devtype);
static struct platform_driver udc_driver = {
- .remove = __exit_p(fsl_udc_remove),
+ .remove = __exit_p(fsl_udc_remove),
+ /* Just for FSL i.mx SoC currently */
+ .id_table = fsl_udc_devtype,
/* these suspend and resume are not usb suspend and resume */
- .suspend = fsl_udc_suspend,
- .resume = fsl_udc_resume,
- .driver = {
- .name = (char *)driver_name,
- .owner = THIS_MODULE,
- /* udc suspend/resume called from OTG driver */
- .suspend = fsl_udc_otg_suspend,
- .resume = fsl_udc_otg_resume,
+ .suspend = fsl_udc_suspend,
+ .resume = fsl_udc_resume,
+ .driver = {
+ .name = (char *)driver_name,
+ .owner = THIS_MODULE,
+ /* udc suspend/resume called from OTG driver */
+ .suspend = fsl_udc_otg_suspend,
+ .resume = fsl_udc_otg_resume,
},
};
--
1.7.0.4
^ permalink raw reply related
* [PATCH v5 2/3] usb: fsl_mxc_udc: replace MX35_IO_ADDRESS to ioremap
From: Peter Chen @ 2013-01-15 2:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358216975-1404-1-git-send-email-peter.chen@freescale.com>
As mach/hardware.h is deleted, we can't visit platform code at driver.
It has no phy driver to combine with this controller, so it has to use
ioremap to map phy address as a workaround.
Signed-off-by: Peter Chen <peter.chen@freescale.com>
---
drivers/usb/gadget/fsl_mxc_udc.c | 30 +++++++++++++++++++++++-------
drivers/usb/gadget/fsl_udc_core.c | 4 +++-
drivers/usb/gadget/fsl_usb2_udc.h | 5 +++--
3 files changed, 29 insertions(+), 10 deletions(-)
diff --git a/drivers/usb/gadget/fsl_mxc_udc.c b/drivers/usb/gadget/fsl_mxc_udc.c
index 1176bd8..bb65c46 100644
--- a/drivers/usb/gadget/fsl_mxc_udc.c
+++ b/drivers/usb/gadget/fsl_mxc_udc.c
@@ -23,7 +23,8 @@ static struct clk *mxc_per_clk;
static struct clk *mxc_ipg_clk;
/* workaround ENGcm09152 for i.MX35 */
-#define USBPHYCTRL_OTGBASE_OFFSET 0x608
+#define MX35_USBPHYCTRL_OFFSET 0x600
+#define USBPHYCTRL_OTGBASE_OFFSET 0x8
#define USBPHYCTRL_EVDO (1 << 23)
int fsl_udc_clk_init(struct platform_device *pdev)
@@ -77,25 +78,40 @@ eclkrate:
return ret;
}
-void fsl_udc_clk_finalize(struct platform_device *pdev)
+int fsl_udc_clk_finalize(struct platform_device *pdev)
{
struct fsl_usb2_platform_data *pdata = pdev->dev.platform_data;
- unsigned int v;
+ int ret = 0;
/* workaround ENGcm09152 for i.MX35 */
if (pdata->workaround & FLS_USB2_WORKAROUND_ENGCM09152) {
- v = readl(MX35_IO_ADDRESS(MX35_USB_BASE_ADDR +
- USBPHYCTRL_OTGBASE_OFFSET));
+ unsigned int v;
+ struct resource *res = platform_get_resource
+ (pdev, IORESOURCE_MEM, 0);
+ void __iomem *phy_regs = ioremap(res->start +
+ MX35_USBPHYCTRL_OFFSET, 512);
+ if (!phy_regs) {
+ dev_err(&pdev->dev, "ioremap for phy address fails\n");
+ ret = -EINVAL;
+ goto ioremap_err;
+ }
+
+ v = readl(phy_regs + USBPHYCTRL_OTGBASE_OFFSET);
writel(v | USBPHYCTRL_EVDO,
- MX35_IO_ADDRESS(MX35_USB_BASE_ADDR +
- USBPHYCTRL_OTGBASE_OFFSET));
+ phy_regs + USBPHYCTRL_OTGBASE_OFFSET);
+
+ iounmap(phy_regs);
}
+
+ioremap_err:
/* ULPI transceivers don't need usbpll */
if (pdata->phy_mode == FSL_USB2_PHY_ULPI) {
clk_disable_unprepare(mxc_per_clk);
mxc_per_clk = NULL;
}
+
+ return ret;
}
void fsl_udc_clk_release(void)
diff --git a/drivers/usb/gadget/fsl_udc_core.c b/drivers/usb/gadget/fsl_udc_core.c
index c971e84..347b1ed 100644
--- a/drivers/usb/gadget/fsl_udc_core.c
+++ b/drivers/usb/gadget/fsl_udc_core.c
@@ -2543,7 +2543,9 @@ static int __init fsl_udc_probe(struct platform_device *pdev)
dr_controller_setup(udc_controller);
}
- fsl_udc_clk_finalize(pdev);
+ ret = fsl_udc_clk_finalize(pdev);
+ if (ret)
+ goto err_free_irq;
/* Setup gadget structure */
udc_controller->gadget.ops = &fsl_gadget_ops;
diff --git a/drivers/usb/gadget/fsl_usb2_udc.h b/drivers/usb/gadget/fsl_usb2_udc.h
index f61a967..c6703bb 100644
--- a/drivers/usb/gadget/fsl_usb2_udc.h
+++ b/drivers/usb/gadget/fsl_usb2_udc.h
@@ -592,15 +592,16 @@ static inline struct ep_queue_head *get_qh_by_ep(struct fsl_ep *ep)
struct platform_device;
#ifdef CONFIG_ARCH_MXC
int fsl_udc_clk_init(struct platform_device *pdev);
-void fsl_udc_clk_finalize(struct platform_device *pdev);
+int fsl_udc_clk_finalize(struct platform_device *pdev);
void fsl_udc_clk_release(void);
#else
static inline int fsl_udc_clk_init(struct platform_device *pdev)
{
return 0;
}
-static inline void fsl_udc_clk_finalize(struct platform_device *pdev)
+static inline int fsl_udc_clk_finalize(struct platform_device *pdev)
{
+ return 0;
}
static inline void fsl_udc_clk_release(void)
{
--
1.7.0.4
^ permalink raw reply related
* [PATCH v5 3/3] ARM: i.MX clock: Change the connection-id for fsl-usb2-udc
From: Peter Chen @ 2013-01-15 2:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358216975-1404-1-git-send-email-peter.chen@freescale.com>
As we use platform_device_id for fsl-usb2-udc driver, it needs to
change clk connection-id, or the related devm_clk_get will be failed.
Signed-off-by: Peter Chen <peter.chen@freescale.com>
---
arch/arm/mach-imx/clk-imx25.c | 6 +++---
arch/arm/mach-imx/clk-imx27.c | 6 +++---
arch/arm/mach-imx/clk-imx31.c | 6 +++---
arch/arm/mach-imx/clk-imx35.c | 6 +++---
arch/arm/mach-imx/clk-imx51-imx53.c | 6 +++---
5 files changed, 15 insertions(+), 15 deletions(-)
diff --git a/arch/arm/mach-imx/clk-imx25.c b/arch/arm/mach-imx/clk-imx25.c
index b197aa7..67e353d 100644
--- a/arch/arm/mach-imx/clk-imx25.c
+++ b/arch/arm/mach-imx/clk-imx25.c
@@ -254,9 +254,9 @@ int __init mx25_clocks_init(void)
clk_register_clkdev(clk[ipg], "ipg", "mxc-ehci.2");
clk_register_clkdev(clk[usbotg_ahb], "ahb", "mxc-ehci.2");
clk_register_clkdev(clk[usb_div], "per", "mxc-ehci.2");
- clk_register_clkdev(clk[ipg], "ipg", "fsl-usb2-udc");
- clk_register_clkdev(clk[usbotg_ahb], "ahb", "fsl-usb2-udc");
- clk_register_clkdev(clk[usb_div], "per", "fsl-usb2-udc");
+ clk_register_clkdev(clk[ipg], "ipg", "imx-udc-mx25");
+ clk_register_clkdev(clk[usbotg_ahb], "ahb", "imx-udc-mx25");
+ clk_register_clkdev(clk[usb_div], "per", "imx-udc-mx25");
clk_register_clkdev(clk[nfc_ipg_per], NULL, "imx25-nand.0");
/* i.mx25 has the i.mx35 type cspi */
clk_register_clkdev(clk[cspi1_ipg], NULL, "imx35-cspi.0");
diff --git a/arch/arm/mach-imx/clk-imx27.c b/arch/arm/mach-imx/clk-imx27.c
index 4c1d1e4..1ffe3b5 100644
--- a/arch/arm/mach-imx/clk-imx27.c
+++ b/arch/arm/mach-imx/clk-imx27.c
@@ -236,9 +236,9 @@ int __init mx27_clocks_init(unsigned long fref)
clk_register_clkdev(clk[lcdc_ahb_gate], "ahb", "imx21-fb.0");
clk_register_clkdev(clk[csi_ahb_gate], "ahb", "imx27-camera.0");
clk_register_clkdev(clk[per4_gate], "per", "imx27-camera.0");
- clk_register_clkdev(clk[usb_div], "per", "fsl-usb2-udc");
- clk_register_clkdev(clk[usb_ipg_gate], "ipg", "fsl-usb2-udc");
- clk_register_clkdev(clk[usb_ahb_gate], "ahb", "fsl-usb2-udc");
+ clk_register_clkdev(clk[usb_div], "per", "imx-udc-mx27");
+ clk_register_clkdev(clk[usb_ipg_gate], "ipg", "imx-udc-mx27");
+ clk_register_clkdev(clk[usb_ahb_gate], "ahb", "imx-udc-mx27");
clk_register_clkdev(clk[usb_div], "per", "mxc-ehci.0");
clk_register_clkdev(clk[usb_ipg_gate], "ipg", "mxc-ehci.0");
clk_register_clkdev(clk[usb_ahb_gate], "ahb", "mxc-ehci.0");
diff --git a/arch/arm/mach-imx/clk-imx31.c b/arch/arm/mach-imx/clk-imx31.c
index 8be64e0..ef66eaf 100644
--- a/arch/arm/mach-imx/clk-imx31.c
+++ b/arch/arm/mach-imx/clk-imx31.c
@@ -139,9 +139,9 @@ int __init mx31_clocks_init(unsigned long fref)
clk_register_clkdev(clk[usb_div_post], "per", "mxc-ehci.2");
clk_register_clkdev(clk[usb_gate], "ahb", "mxc-ehci.2");
clk_register_clkdev(clk[ipg], "ipg", "mxc-ehci.2");
- clk_register_clkdev(clk[usb_div_post], "per", "fsl-usb2-udc");
- clk_register_clkdev(clk[usb_gate], "ahb", "fsl-usb2-udc");
- clk_register_clkdev(clk[ipg], "ipg", "fsl-usb2-udc");
+ clk_register_clkdev(clk[usb_div_post], "per", "imx-udc-mx31");
+ clk_register_clkdev(clk[usb_gate], "ahb", "imx-udc-mx31");
+ clk_register_clkdev(clk[ipg], "ipg", "imx-udc-mx31");
clk_register_clkdev(clk[csi_gate], NULL, "mx3-camera.0");
/* i.mx31 has the i.mx21 type uart */
clk_register_clkdev(clk[uart1_gate], "per", "imx21-uart.0");
diff --git a/arch/arm/mach-imx/clk-imx35.c b/arch/arm/mach-imx/clk-imx35.c
index 66f3d65..69fe9c8 100644
--- a/arch/arm/mach-imx/clk-imx35.c
+++ b/arch/arm/mach-imx/clk-imx35.c
@@ -251,9 +251,9 @@ int __init mx35_clocks_init()
clk_register_clkdev(clk[usb_div], "per", "mxc-ehci.2");
clk_register_clkdev(clk[ipg], "ipg", "mxc-ehci.2");
clk_register_clkdev(clk[usbotg_gate], "ahb", "mxc-ehci.2");
- clk_register_clkdev(clk[usb_div], "per", "fsl-usb2-udc");
- clk_register_clkdev(clk[ipg], "ipg", "fsl-usb2-udc");
- clk_register_clkdev(clk[usbotg_gate], "ahb", "fsl-usb2-udc");
+ clk_register_clkdev(clk[usb_div], "per", "imx-udc-mx35");
+ clk_register_clkdev(clk[ipg], "ipg", "imx-udc-mx35");
+ clk_register_clkdev(clk[usbotg_gate], "ahb", "imx-udc-mx35");
clk_register_clkdev(clk[wdog_gate], NULL, "imx2-wdt.0");
clk_register_clkdev(clk[nfc_div], NULL, "imx25-nand.0");
clk_register_clkdev(clk[csi_gate], NULL, "mx3-camera.0");
diff --git a/arch/arm/mach-imx/clk-imx51-imx53.c b/arch/arm/mach-imx/clk-imx51-imx53.c
index 579023f..fb7cb84 100644
--- a/arch/arm/mach-imx/clk-imx51-imx53.c
+++ b/arch/arm/mach-imx/clk-imx51-imx53.c
@@ -269,9 +269,9 @@ static void __init mx5_clocks_common_init(unsigned long rate_ckil,
clk_register_clkdev(clk[usboh3_per_gate], "per", "mxc-ehci.2");
clk_register_clkdev(clk[usboh3_gate], "ipg", "mxc-ehci.2");
clk_register_clkdev(clk[usboh3_gate], "ahb", "mxc-ehci.2");
- clk_register_clkdev(clk[usboh3_per_gate], "per", "fsl-usb2-udc");
- clk_register_clkdev(clk[usboh3_gate], "ipg", "fsl-usb2-udc");
- clk_register_clkdev(clk[usboh3_gate], "ahb", "fsl-usb2-udc");
+ clk_register_clkdev(clk[usboh3_per_gate], "per", "imx-udc-mx51");
+ clk_register_clkdev(clk[usboh3_gate], "ipg", "imx-udc-mx51");
+ clk_register_clkdev(clk[usboh3_gate], "ahb", "imx-udc-mx51");
clk_register_clkdev(clk[nfc_gate], NULL, "imx51-nand");
clk_register_clkdev(clk[ssi1_ipg_gate], NULL, "imx-ssi.0");
clk_register_clkdev(clk[ssi2_ipg_gate], NULL, "imx-ssi.1");
--
1.7.0.4
^ permalink raw reply related
* [PATCH 00/16] big.LITTLE low-level CPU and cluster power management
From: Joseph Lo @ 2013-01-15 2:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.LFD.2.02.1301140849020.6300@xanadu.home>
On Mon, 2013-01-14 at 22:05 +0800, Nicolas Pitre wrote:
> On Mon, 14 Jan 2013, Joseph Lo wrote:
>
> > Hi Nicolas,
> >
> > On Thu, 2013-01-10 at 08:20 +0800, Nicolas Pitre wrote:
> > > This is the initial public posting of the initial support for big.LITTLE.
> > > Included here is the code required to safely power up and down CPUs in a
> > > b.L system, whether this is via CPU hotplug, a cpuidle driver or the
> > > Linaro b.L in-kernel switcher[*] on top of this. Only SMP secondary
> > > boot and CPU hotplug support is included at this time. Getting to this
> > > point already represents a significcant chunk of code as illustrated by
> > > the diffstat below.
> > >
> > >
> >
> > Thanks for introducing this series.
> > I am taking a look at this series. It introduced an algorithm for
> > syncing and avoid racing when syncing the power status of clusters and
> > CPUs. Do you think these codes could have a chance to become a generic
> > framework?
>
> Yes. As I mentioned before, the bL_ prefix is implied only by the fact
> that big.LITTLE was the motivation for creating this code.
>
> > The Tegra chip series had a similar design for CPU clusters and it
> had
> > limitation that the CPU0 always needs to be the last CPU to be shut down
> > before cluster power down as well. I believe it can also get benefits of
> > this works. We indeed need a similar algorithm to sync CPUs power status
> > before cluster power down and switching.
> >
> > The "bL_entry.c", "bL_entry.S", "bL_entry.h", "vlock.h" and "vlock.S"
> > looks have a chance to be a common framework for ARM platform even if it
> > just support one cluster. Because some systems had the limitations for
> > cluster power down. That's why the coupled cpuidle been introduced. And
> > this framework could be enabled automatically if platform dependent or
> > by menuconfig.
>
> Absolutely.
>
So do you have a plan to make it become a generic framework in this
series or later work?
(And I will add some common power sync wrapper functions that based on
this framework for all Tegra series.)
>
> > For ex,
> > select CPUS_CLUSTERS_POWER_SYNC_FRAMEWORK if SMP && CPU_PM
> >
> > How do you think of this suggestion?
>
> I'd prefer a more concise name though.
>
Sure. :-)
Thanks,
Joseph
^ permalink raw reply
* [PATCH v2] hardlockup: detect hard lockups without NMIs using secondary cpus
From: Frederic Weisbecker @ 2013-01-15 2:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMbhsRQiK=rChiNdwM5M6t=1v_iKwYLhUn=HLW5kSkBzQdso8g@mail.gmail.com>
2013/1/15 Colin Cross <ccross@android.com>:
> On Mon, Jan 14, 2013 at 4:25 PM, Frederic Weisbecker <fweisbec@gmail.com> wrote:
>> 2013/1/15 Colin Cross <ccross@android.com>:
>>> On Mon, Jan 14, 2013 at 4:13 PM, Frederic Weisbecker <fweisbec@gmail.com> wrote:
>>>> I believe this is pretty much what the RCU stall detector does
>>>> already: checks for other CPUs being responsive. The only difference
>>>> is on how it checks that. For RCU it's about checking for CPUs
>>>> reporting quiescent states when requested to do so. In your case it's
>>>> about ensuring the hrtimer interrupt is well handled.
>>>>
>>>> One thing you can do is to enqueue an RCU callback (cal_rcu()) every
>>>> minute so you can force other CPUs to report quiescent states
>>>> periodically and thus check for lockups.
>>>
>>> That's a good point, I'll take a look at using that. A minute is too
>>> long, some SoCs have maximum HW watchdog periods of under 30 seconds,
>>> but a call_rcu every 10-20 seconds might be sufficient.
>>
>> Sure. And you can tune CONFIG_RCU_CPU_STALL_TIMEOUT accordingly.
>
> After considering this, I think the hrtimer watchdog is more useful.
> RCU stalls are not usually panic events, and I wouldn't want to add a
> panic on every RCU stall. The lack of stack traces on the affected
> cpu makes a panic important. I'm planning to add an ARM DBGPCSR panic
> handler, which will be able to dump the PC of a stuck cpu even if it
> is not responding to interrupts. kexec or kgdb on panic might also
> allow some inspection of the stack on stuck cpu.
>
> Failing to process interrupts is a much more serious event than an RCU
> stall, and being able to detect them separately may be very valuable
> for debugging.
RCU stalls can happen for different reasons: softlockup (failure to
schedule another task), hardlockup (failure to process interrupts), or
a bug in RCU itself. But if you have a hardlockup, it will report it.
Now why do you need a panic in any case? I don't know DBGPCSR, is this
a breakpoint register? How do you plan to use it remotely from the CPU
that detects the lockup?
^ permalink raw reply
* [PATCH V2 2/6] ARM: tegra20: cpuidle: add powered-down state for secondary CPU
From: Joseph Lo @ 2013-01-15 3:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130111122417.GE30538@e102568-lin.cambridge.arm.com>
On Fri, 2013-01-11 at 20:24 +0800, Lorenzo Pieralisi wrote:
> On Fri, Jan 11, 2013 at 07:20:29AM +0000, Joseph Lo wrote:
> > On Wed, 2012-12-05 at 18:50 +0800, Lorenzo Pieralisi wrote:
> > > On Wed, Dec 05, 2012 at 10:01:49AM +0000, Joseph Lo wrote:
> > > > The powered-down state of Tegra20 requires power gating both CPU cores.
> > > > When the secondary CPU requests to enter powered-down state, it saves
> > > > its own contexts and then enters WFI. The Tegra20 had a limition to
> > > > power down both CPU cores. The secondary CPU must waits for CPU0 in
> > > > powered-down state too. If the secondary CPU be woken up before CPU0
> > > > entering powered-down state, then it needs to restore its CPU states
> > > > and waits for next chance.
> > > >
> > > > Be aware of that, you may see the legacy power state "LP2" in the code
> > > > which is exactly the same meaning of "CPU power down".
> > > >
> > > > Based on the work by:
> > > > Colin Cross <ccross@android.com>
> > > > Gary King <gking@nvidia.com>
> > > >
> > > > Signed-off-by: Joseph Lo <josephl@nvidia.com>
> > > > +
> > > > +#ifdef CONFIG_PM_SLEEP
> > > > +/*
> > > > + * tegra_pen_lock
> > > > + *
> > > > + * spinlock implementation with no atomic test-and-set and no coherence
> > > > + * using Peterson's algorithm on strongly-ordered registers
> > > > + * used to synchronize a cpu waking up from wfi with entering lp2 on idle
> > > > + *
> > > > + * SCRATCH37 = r1 = !turn (inverted from Peterson's algorithm)
> > > > + * on cpu 0:
> > > > + * SCRATCH38 = r2 = flag[0]
> > > > + * SCRATCH39 = r3 = flag[1]
> > > > + * on cpu1:
> > > > + * SCRATCH39 = r2 = flag[1]
> > > > + * SCRATCH38 = r3 = flag[0]
> > > > + *
> > > > + * must be called with MMU on
> > > > + * corrupts r0-r3, r12
> > > > + */
> > > > +ENTRY(tegra_pen_lock)
> > > > + mov32 r3, TEGRA_PMC_VIRT
> > > > + cpu_id r0
> > > > + add r1, r3, #PMC_SCRATCH37
> > > > + cmp r0, #0
> > > > + addeq r2, r3, #PMC_SCRATCH38
> > > > + addeq r3, r3, #PMC_SCRATCH39
> > > > + addne r2, r3, #PMC_SCRATCH39
> > > > + addne r3, r3, #PMC_SCRATCH38
> > > > +
> > > > + mov r12, #1
> > > > + str r12, [r2] @ flag[cpu] = 1
> > > > + dsb
> > > > + str r12, [r1] @ !turn = cpu
> > > > +1: dsb
> > > > + ldr r12, [r3]
> > > > + cmp r12, #1 @ flag[!cpu] == 1?
> > > > + ldreq r12, [r1]
> > > > + cmpeq r12, r0 @ !turn == cpu?
> > > > + beq 1b @ while !turn == cpu && flag[!cpu] == 1
> > > > +
> > > > + mov pc, lr @ locked
> > > > +ENDPROC(tegra_pen_lock)
> > > > +
> > > > +ENTRY(tegra_pen_unlock)
> > > > + dsb
> > > > + mov32 r3, TEGRA_PMC_VIRT
> > > > + cpu_id r0
> > > > + cmp r0, #0
> > > > + addeq r2, r3, #PMC_SCRATCH38
> > > > + addne r2, r3, #PMC_SCRATCH39
> > > > + mov r12, #0
> > > > + str r12, [r2]
> > > > + mov pc, lr
> > > > +ENDPROC(tegra_pen_unlock)
> > >
> > > There is an ongoing work to make this locking scheme for MMU/coherency off
> > > paths ARM generic, and we do not want to merge yet another platform specific
> > > locking mechanism. I will point you to the patchset when it hits LAK.
> > >
> >
> > You did mention there is an ARM generic locking scheme for MMU/coherency
> > off case before. Do you mean the patch below?
> >
> > https://patchwork.kernel.org/patch/1957911/
> > https://patchwork.kernel.org/patch/1957901/
>
> Those are used for first-man election when multiple CPUs come out of
> idle at once.
>
> You should have a look at the entire series and in particular:
>
> https://patchwork.kernel.org/patch/1957891/
> https://patchwork.kernel.org/patch/1957951/
>
> > I gave it a review today. Looks it can't fit our usage for CPU idle
> > powered-down mode on Tegra20.
> >
> > The generic mechanism only can be used when CPUs in non coherent world.
> > But our usage needs the mechanism could be used in both coherent and non
> > coherent case. OK. The case is we need to sync the status about the CPU1
> > was ready to power down. In this case, the CPU0 is still in coherent
> > world but the CPU1 isn't. So we need the locking scheme could be still
> > safe in this situation.
>
> I know, I implemented something of that sort for an A9 based development
> platform, that's why I pointed you to this new patchset.
>
> Have a look at the series, it should do what you want.
>
Hi Lorenzo,
May I upstream this stuff first? I can promise to you I will re-work a
common CPUs and cluster power sync wrappers (platform_power_ops) for all
Tegra series that based on the generic framework. Because we didn't have
this work in Tegra tree yet and we indeed need it for supporting cluster
power down and switching.
But it need lots of time for re-work, testing and verification. And I
have lots of patches that need the function of cpu suspend that be
introduced in this patch series to support platform suspend for Tegra.
So I am asking the permission here for upstream this series first and I
will continue the job to come out a common CPUs and cluster power sync
wrappers for Tegra that we indeed need it to support cluster power down
and switching.
Thanks,
Joseph
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox