From: Mark Brown <broonie(a)linaro.org>
The s6105-ipcam driver calls i2c_register_board_info() which means that
not only does it need I2C to be enabled to be built but since that
symbol is not exported it means that the driver also can't be linked as
a module. Use a bool instead of a tristate and add a dependency on I2C
to fix these issues.
Commit b5dd60fd263 (ASoC: s6000: Allow to build when COMPILE_TEST is
enabled) made this problem more visible since it enabled build of the
driver on more common architectures but this has always been an issue.
Signed-off-by: Mark Brown <broonie(a)linaro.org>
---
sound/soc/s6000/Kconfig | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/sound/soc/s6000/Kconfig b/sound/soc/s6000/Kconfig
index 4823e1e4daef..f244a2566f20 100644
--- a/sound/soc/s6000/Kconfig
+++ b/sound/soc/s6000/Kconfig
@@ -15,8 +15,9 @@ config SND_S6000_SOC_I2S
tristate
config SND_S6000_SOC_S6IPCAM
- tristate "SoC Audio support for Stretch 6105 IP Camera"
- depends on SND_S6000_SOC
+ bool "SoC Audio support for Stretch 6105 IP Camera"
+ depends on SND_S6000_SOC=y
+ depends on I2C=y
depends on XTENSA_PLATFORM_S6105 || COMPILE_TEST
select SND_S6000_SOC_I2S
select SND_SOC_TLV320AIC3X
--
2.0.0
From: Mark Brown <broonie(a)linaro.org>
Without the dependencies for the accessors the driver can be enabled on
architectures where it will fail to build.
Signed-off-by: Mark Brown <broonie(a)linaro.org>
---
drivers/spi/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index f41431331c3e..79ace88030c4 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -384,6 +384,7 @@ config SPI_PXA2XX_PCI
config SPI_ROCKCHIP
tristate "Rockchip SPI controller driver"
+ depends on ARM || ARM64 || AVR32 || HEXAGON || MIPS || SUPERH
help
This selects a driver for Rockchip SPI controller.
--
2.0.0
Currently, the ->set_mode() method of a clockevent device is not
allowed to fail, so it has no return value. In order to add new
clockevent modes, and allow the setting of those modes to fail, we
need the clockevent core to be able to detect when setting a mode
fails.
Rather than changing the current ->set_mode() and requiring all
clockevent devices to change immedately, introduce a new mode setting
method ->set_dev_mode() which returns 'int'.
In addition, migrate a few drivers over to the new method to
demonstrate how the new method is to be used, and how to convert.
Proposal for new method originally suggested by Thomas Gleixner[1].
[1] https://lkml.org/lkml/2014/5/10/86
Viresh Kumar (2):
clockevents: introduce ->set_dev_mode() which can return error
clockevents: migrate some drivers to new ->set_dev_mode()
drivers/clocksource/arm_arch_timer.c | 46 +++++++++++++++++---------------
drivers/clocksource/bcm2835_timer.c | 10 +++----
drivers/clocksource/bcm_kona_timer.c | 15 ++++++++---
drivers/clocksource/i8253.c | 11 +++++---
drivers/clocksource/time-armada-370-xp.c | 21 +++++++++++----
include/linux/clockchips.h | 5 +++-
kernel/time/clockevents.c | 21 ++++++++++++---
kernel/time/timer_list.c | 5 +++-
8 files changed, 91 insertions(+), 43 deletions(-)
--
1.9.2
Currently, the ->set_mode() method of a clockevent device is not
allowed to fail, so it has no return value. In order to add new
clockevent modes, and allow the setting of those modes to fail, we
need the clockevent core to be able to detect when setting a mode
fails.
Rather than changing the current ->set_mode() and requiring all
clockevent devices to change immedately, introduce a new mode setting
method ->set_dev_mode() which returns 'int'.
In addition, migrate a few drivers over to the new method to
demonstrate how the new method is to be used, and how to convert.
Proposal for new method originally suggested by Thomas Gleixner[1].
[1] https://lkml.org/lkml/2014/5/10/86
Viresh Kumar (2):
clockevents: introduce ->set_dev_mode() which can return error
clockevents: migrate some drivers to new ->set_dev_mode()
drivers/clocksource/arm_arch_timer.c | 46 +++++++++++++++++---------------
drivers/clocksource/bcm2835_timer.c | 10 +++----
drivers/clocksource/bcm_kona_timer.c | 15 ++++++++---
drivers/clocksource/i8253.c | 11 +++++---
drivers/clocksource/time-armada-370-xp.c | 21 +++++++++++----
include/linux/clockchips.h | 5 +++-
kernel/time/clockevents.c | 21 ++++++++++++---
kernel/time/timer_list.c | 5 +++-
8 files changed, 91 insertions(+), 43 deletions(-)
--
1.9.2
Hi Thomas et al,
I was analyzing few traces with 'trace-cmd' and realized that timings
weren't matching properly. For example consider this trace:
1 cat-1867 [000] d.h1 149.750891: hrtimer_expire_entry:
hrtimer=ee7b3740 function=tick_sched_timer now=149740008694
2 cat-1867 [000] d.h1 149.750900: softirq_raise: vec=1
[action=TIMER]
3 cat-1867 [000] d.h1 149.750905: softirq_raise: vec=9
[action=RCU]
4 cat-1867 [000] d.h2 149.750910: sched_stat_runtime:
comm=cat pid=1867 runtime=1463250 [ns] vruntime=4777557704 [ns]
5 cat-1867 [000] d.h1 149.750914: softirq_raise: vec=7
[action=SCHED]
6 cat-1867 [000] d.h1 149.750919: hrtimer_expire_exit:
hrtimer=ee7b3740
7 cat-1867 [000] d.h2 149.750922: hrtimer_start:
hrtimer=ee7b3740 function=tick_sched_timer expires=149745000000
softexpires=149745000000
Line 1: now=149.740008694 and trace-time: 149.750891. diff 10ms (consistently)
Line 7: trace-time: 149.750922 and expires: 149.745000000, diff 5ms
So, either there is a mismatch of trace-times and required to be
fixed? (@Steven)
Or we are almost always adding the tick-sched hrtimer in past?
I wasn't sure and tried to go through tick-sched and hrtimer core
code again and this is what I realized.
At certain points we are trying to make sure that 'jiffies' are updated
for current-time with loops like:
Lowres mode:
while (tick_nohz_reprogram(ts, now)) {
now = ktime_get();
tick_do_update_jiffies64(now);
}
tick_nohz_reprogram() does check if expires is in past and returns
-ETIME (right?). And so we are guaranteed to updated jiffies to
current time and reprogram clkevt device in future.
Highres mode:
- First of all this kind of loop is missing from tick-handler:
tick_sched_timer() as we are relying on hrtimer core to restart hrtimer
for us and so we aren't trying to updated jiffies to latest values. And
so we might (maybe always as shown in my traces) enqueue hrtimer
in past.
- At some places we do have a while loop:
static void tick_nohz_restart(struct tick_sched *ts, ktime_t now)
{
...
while (1) {
/* Forward the time to expire in the future */
hrtimer_forward(&ts->sched_timer, now, tick_period);
if (ts->nohz_mode == NOHZ_MODE_HIGHRES) {
hrtimer_start_expires(&ts->sched_timer,
HRTIMER_MODE_ABS_PINNED);
/* Check, if the timer was already in the past */
if (hrtimer_active(&ts->sched_timer))
break;
} else {
...
}
...
}
}
But I couldn't make out that this while loop will actually run for
hres mode. Unlike tick_nohz_reprogram(), hrtimer_start_expires()
never fails and calls enqueue_hrtimer() which does this:
timer->state |= HRTIMER_STATE_ENQUEUED;
And so hrtimer_active() is guaranteed to return 'true' ? From the
comment over hrtimer_active() here it looks we are trying to make
sure that we aren't adding hrtimer in past, but code doesn't look
like that.
And so there is a possibility that hrtimers are getting added in past.
I tried to go to the initial commit: 79bf2bb (tick-management:
dyntick / highres functionality) and see if things were different there.
But they weren't.
Sorry for the long mail :)
--
viresh
Commit 64c862a83... added new alloc variants to the devres managed
API. These should be included in the list of managed API found in
devres.txt.
Signed-off-by: Daniel Thompson <daniel.thompson(a)linaro.org>
Cc: Randy Dunlap <rdunlap(a)infradead.org>
Cc: Grant Likely <grant.likely(a)linaro.org>
Cc: Rob Herring <robh+dt(a)kernel.org>
Cc: Joe Perches <joe(a)perches.com>
Cc: linux-doc(a)vger.kernel.org
---
Documentation/driver-model/devres.txt | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Documentation/driver-model/devres.txt b/Documentation/driver-model/devres.txt
index 1525e30..91f5633 100644
--- a/Documentation/driver-model/devres.txt
+++ b/Documentation/driver-model/devres.txt
@@ -234,7 +234,10 @@ certainly invest a bit more effort into libata core layer).
-----------------------------
MEM
+ devm_kmalloc()
devm_kzalloc()
+ devm_kmalloc_array()
+ devm_kcalloc()
devm_kfree()
devm_kmemdup()
devm_get_free_pages()
--
1.9.3
When expiry is set to KTIME_MAX, we cancel the 'tick-sched' hrtimer in highres
mode and skip reprogramming clockevent device in lowres mode. But, the
clockevent device is already reprogrammed from tick-handler.
We will get interrupted atleast one more time.
In highres mode, as there is no hrtimer to service, hrtimer_interrupt() will
return without calling tick-handler.
But the problem is somewhat bigger in lowres mode. We unconditionally reschedule
tick everytime tick_nohz_handler() is called and so even if tick_stopped is set,
we never enter full dynticks mode.
To fix this, skip rescheduling next tick from tick-handler when we are running
tickless.
OTOH, when expires isn't equal to KTIME_MAX, we avoid reprogramming the clkdev
from the tick when it is stopped because it's going to be reprogrammed from
irq_exit() anyway. So we could avoid one useless device write.
Signed-off-by: Viresh Kumar <viresh.kumar(a)linaro.org>
---
kernel/time/tick-sched.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/kernel/time/tick-sched.c b/kernel/time/tick-sched.c
index 6558b7a..a4a45e0 100644
--- a/kernel/time/tick-sched.c
+++ b/kernel/time/tick-sched.c
@@ -956,6 +956,12 @@ static void tick_nohz_handler(struct clock_event_device *dev)
tick_sched_do_timer(now);
tick_sched_handle(ts, regs);
+ /*
+ * Skip reprogramming next event if we are running tickless.
+ */
+ if (ts->tick_stopped)
+ return;
+
while (tick_nohz_reprogram(ts, now)) {
now = ktime_get();
tick_do_update_jiffies64(now);
--
2.0.0.rc2
Changes in v4:
- Add device_remove hook, so hisi-smmu and smmu-v3 can reclaim other resources.
like dynamic allocted memory. And s1cbt and s2cbt memory are now allocated in
driver(Previously, I hope BIOS to do this).
- Fix bugs according to review comments. CB_FAR_LOW, CB_FAR_HIGH are (n) << 3.
- Change context_map in struct arm_smmu_device to dynamic memory allocation.
- Merge original patch 3 and 4 into one patch.
Changes in v3:
- Split arm-smmu.c into three files: arm-smmu.h arm-smmu-base.c arm-smmu.c.
To build stardard arm-smmu driver, use these three files.
To build hisilicon smmu driver, replace arm-smmu.c with hisi-smmu.c.
Now, hisi smmu driver is not dependent on arm smmu driver. They can seperate
exist, or coexist, when both building and running time.
- Give up Hisilicon private properties.
- Place hooks from global variable into struct arm_smmu_device.
And deleted three hooks: tlb_sync, flush_pgtable and dt_cfg_probe.
- Share the codes which are used to limit the size of smmu ias,oas,ubs.
- Add two little patchs about code style, variable types, etc.
Changes in v2:
- Split Hisilicon smmu implementation in a separate file, hisi-smmu.c
- Refactor arm-smmu.c. Some direct call hardware dependent functions replaced
with hooks. And move common struct and marco definition into arm-smmu.h
- Merge the description of Hisilicon private properties into arm,smmu.txt
I tried to merge hisi-smmu driver into arm-smmu.c, but it looks impossible.
The biggest problem is that too many registers are diffrent: the base address,
the field definition, or present only on one side. And if I use #if, hisi-smmu
and arm-smmu can not coexist in one binary file. Almost need 20 #if.
In addition, SMMUv3 is also not compatible with v2. And something is similar
with hisi-smmu: registers definition and fault handler is different with v2,
but can reuse fdt configuration and memory map. Hence, arm-smmu-base.c and
arm-smmu.h should be shared by all SMMUs(v2, v3 and hisi), and each smmu will
own a private file, like: arm-smmu.c(for v1 and v2), arm-smmu-v3.c, hisi-smmu.c
In this patch, arm-smmu.h is not suitable for v3. Because it contains macros
about v2 registers. SMMUv3 draft have not given detailed registers definition.
So I don't know how many macros can be reused. In fact, I think all marcos
which are not used in arm-smmu-base.c and arm-smmu.h, should place into each
private file, and abide duplication(After all, it is hardware dependent. It
will not bring any maintenance headaches, except when need rename the marcos).
Zhen Lei (5):
iommu/arm: change some structure member types in arm_smmu_device
iommu/arm: eliminate errors reported by checkpatch
iommu/arm: split arm-smmu.c into three files
iommu/hisilicon: Add support for Hisilicon Ltd. System MMU
architecture
documentation/iommu: Add description of Hisilicon SMMU private
binding
.../devicetree/bindings/iommu/arm,smmu.txt | 2 +
drivers/iommu/Kconfig | 14 +
drivers/iommu/Makefile | 2 +
drivers/iommu/arm-smmu-base.c | 1067 +++++++++++++++
drivers/iommu/arm-smmu.c | 1406 +-------------------
drivers/iommu/arm-smmu.h | 438 ++++++
drivers/iommu/hisi-smmu.c | 541 ++++++++
7 files changed, 2103 insertions(+), 1367 deletions(-)
create mode 100644 drivers/iommu/arm-smmu-base.c
create mode 100644 drivers/iommu/arm-smmu.h
create mode 100644 drivers/iommu/hisi-smmu.c
--
1.8.0
Stephen Boyd sent few patches today around a new cpufreq driver for Qualcomm's
Krait SoC: https://lkml.org/lkml/2014/6/24/918.
Krait couldn't use existing cpufreq-cpu0 driver as it doesn't have support for
SoC's with multiple clusters or SoC's which don't share clock line for all CPUs.
And I thought about trying updating cpu0 driver to see if we can get rid of this
limitation easily and use it for Krait as well.
It took me longer than I thought, around 4 hours to get this working on my dual
A15 exynos board.
First patch adds some space for driver specific data in 'struct cpufreq_policy'
and second one updates cpufreq-cpu0..
@Stephen: Can you please test this on Krait and see if it works?
Pushed here:
Rebased over rc2:
git://git.linaro.org/people/viresh.kumar/linux.git cpufreq/cpu0-krait
For guys looking to test on exynos, rebased over linux-next + some patches from
Thomas Abraham to use cpufreq-cpu0 for exynos:
git://git.linaro.org/people/viresh.kumar/linux.git cpufreq/cpu0-exynos
In case this is acceptable and bug free, next step would be to get cpufreq-cpu0
renamed a bit as its not about CPU0 anymore. Any suggestions on that would be
great :), cpufreq_generic.c ?
Thanks.
Viresh Kumar (2):
cpufreq: Add support for per-policy driver data
cpufreq: cpu0: Extend support beyond CPU0
.../devicetree/bindings/cpufreq/cpufreq-cpu0.txt | 8 +-
drivers/cpufreq/Kconfig | 5 +-
drivers/cpufreq/cpufreq-cpu0.c | 280 +++++++++++++--------
include/linux/cpufreq.h | 3 +
4 files changed, 193 insertions(+), 103 deletions(-)
--
2.0.0.rc2
Hi,
This patch adds support for PCI to AArch64. It is based on my v8 patch
that adds support for creating generic host bridge structure from
device tree. With that in place, I was able to boot a platform that
has PCIe host bridge support and use a PCIe network card.
Changes from v7:
- Rebased to v3.16-rc3
- Removed pci_ioremap_io() function as it is provided by my v8 generic
PCI host bridge patches under a different name.
Changes from v6:
- Guard the pci_domain_nr() inline implementation with #ifdef CONFIG_PCI as
to avoid conflict with default empty version present in include/linux/pci.h.
Thanks to Jingoo Han for catching this.
Changes from v5:
- Removed pcibios_fixup_bridge_ranges() as the week default version is fine.
- Removed the ALIGN() call in pcibios_align_resource()
- Stopped exporting pcibios_align_resource()
Changes from v4:
- Fixed the pci_domain_nr() implementation for arm64. Now we use
find_pci_host_bride() to find the host bridge before we retrieve
the domain number.
Changes from v3:
- Added Acks accumulated so far ;)
- Still carrying Catalin's patch for moving the PCI_IO_BASE until it
lands in linux-next or mainline, in order to ease applying the series
Changes from v2:
- Implement an arch specific version of pci_register_io_range() and
pci_address_to_pio().
- Return 1 from pci_proc_domain().
Changes from v1:
- Added Catalin's patch for moving the PCI_IO_BASE location and extend
its size to 16MB
- Integrated Arnd's version of pci_ioremap_io that uses a bitmap for
keeping track of assigned IO space and returns an io_offset. At the
moment the code is added in arch/arm64 but it can be moved in drivers/pci.
- Added a fix for the generic ioport_map() function when !CONFIG_GENERIC_IOMAP
as suggested by Arnd.
v7 thread here: https://lkml.org/lkml/2014/3/14/320
v6 thread here: https://lkml.org/lkml/2014/3/5/41
v5 thread here: https://lkml.org/lkml/2014/3/4/307
v4 thread here: https://lkml.org/lkml/2014/3/3/298
v3 thread here: https://lkml.org/lkml/2014/2/28/211
v2 thread here: https://lkml.org/lkml/2014/2/27/255
v1 thread here: https://lkml.org/lkml/2014/2/3/389
The API used is different from the one used by ARM architecture. There is
no pci_common_init_dev() function and no hw_pci structure, as that is no
longer needed. Here is an example of what the probe function of a generic
host bridge could look like:
static int myhostbridge_probe(struct platform_device *pdev)
{
int err;
struct device_node *dev;
struct pci_host_bridge *bridge;
struct myhostbridge_port *pp;
resource_size_t lastbus;
dev = pdev->dev.of_node;
if (!of_device_is_available(dev)) {
pr_warn("%s: disabled\n", dev->full_name);
return -ENODEV;
}
pp = kzalloc(sizeof(struct myhostbridge_port), GFP_KERNEL);
if (!pp)
return -ENOMEM;
bridge = of_create_pci_host_bridge(&pdev->dev, &myhostbridge_ops, pp);
if (IS_ERR(bridge)) {
err = PTR_ERR(bridge);
goto bridge_create_fail;
}
err = myhostbridge_setup(bridge->bus);
if (err)
goto bridge_setup_fail;
/* We always enable PCI domains and we keep domain 0 backward
* compatible in /proc for video cards
*/
pci_add_flags(PCI_ENABLE_PROC_DOMAINS);
pci_add_flags(PCI_REASSIGN_ALL_BUS | PCI_REASSIGN_ALL_RSRC);
lastbus = pci_scan_child_bus(bridge->bus);
pci_bus_update_busn_res_end(bridge->bus, lastbus);
pci_assign_unassigned_bus_resources(bridge->bus);
pci_bus_add_devices(bridge->bus);
return 0;
bridge_setup_fail:
put_device(&bridge->dev);
device_unregister(&bridge->dev);
bridge_create_fail:
kfree(pp);
return err;
}
Liviu Dudau (1):
arm64: Add architectural support for PCI
arch/arm64/Kconfig | 19 ++++++++++++++++-
arch/arm64/include/asm/Kbuild | 1 +
arch/arm64/include/asm/io.h | 3 ++-
arch/arm64/include/asm/pci.h | 49 +++++++++++++++++++++++++++++++++++++++++++
arch/arm64/kernel/Makefile | 1 +
arch/arm64/kernel/pci.c | 38 +++++++++++++++++++++++++++++++++
6 files changed, 109 insertions(+), 2 deletions(-)
create mode 100644 arch/arm64/include/asm/pci.h
create mode 100644 arch/arm64/kernel/pci.c
--
2.0.0
Hi,
I am trying to understand the suspend/resume mechanism in mmc.
The kernel ( in hibernation as well as in suspend to ram) first calls
suspend_thaw_processes() and then calls
pm_notifier_call_chain(PM_POST_SUSPEND/HIBERNATION). The mmc driver
schedules mmc_rescan on receiving the notification of
PM_POST_SUSPEND/HIBERNATION. Thus before mmc_rescan() gets called, the
mmc card is not ready to be used.
So if any processes before hibernation/suspend were using mmc device,
then on resume when these processes would be unfrozen( from
thaw_processes ) and if it tries to access the mmc device( before
mmc_rescan gets scheduled), then it would hit a problem.
Please let me know if my understanding is correct or not.
Regards,
Ayan Kumar Halder
From: Viresh Kumar <viresh.kumar(a)linaro.org>
3.12-stable review patch. If anyone has any objections, please let me know.
===============
commit 27630532ef5ead28b98cfe28d8f95222ef91c2b7 upstream.
Since commit d689fe222 (NOHZ: Check for nohz active instead of nohz
enabled) the tick_nohz_switch_to_nohz() function returns because it
checks for the tick_nohz_active flag. This can't be set, because the
function itself sets it.
Undo the change in tick_nohz_switch_to_nohz().
Signed-off-by: Viresh Kumar <viresh.kumar(a)linaro.org>
Cc: linaro-kernel(a)lists.linaro.org
Cc: fweisbec(a)gmail.com
Cc: Arvind.Chauhan(a)arm.com
Cc: linaro-networking(a)linaro.org
Cc: <stable(a)vger.kernel.org> # 3.13+
Link: http://lkml.kernel.org/r/40939c05f2d65d781b92b20302b02243d0654224.139753798…
Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de>
Signed-off-by: Jiri Slaby <jslaby(a)suse.cz>
---
kernel/time/tick-sched.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/time/tick-sched.c b/kernel/time/tick-sched.c
index ea20f7d1ac2c..29b063b32ff0 100644
--- a/kernel/time/tick-sched.c
+++ b/kernel/time/tick-sched.c
@@ -970,7 +970,7 @@ static void tick_nohz_switch_to_nohz(void)
struct tick_sched *ts = &__get_cpu_var(tick_cpu_sched);
ktime_t next;
- if (!tick_nohz_active)
+ if (!tick_nohz_enabled)
return;
local_irq_disable();
--
2.0.0
HI Guys,
I have been working on CPU Isolation work since sometime
now. The target here is to isolate a Core (for High performance
Networking: data plane thread) from all kernel activities. A single
data plane thread must run on isolated CPU indefinitely.
So, we need isolation from tasks, timers, ticks, workqueues, etc.
Anything I missed in this list?
I am doing this with help of CPUSets/NO_HZ_FULL, etc currently.
One of the problem which isn't solved very well until now is:
"How can we guarantee that CPU is isolated" ?
Currently, my script is relying on the fact that on most of the
interruptions per-cpu tick gets updated and checking its value
must be enough from /proc/interrupts for clkevt device.
Is that enough? Or there are cases when there might be some
interruption and ticks don't get updated?
The problem with the /proc/interrupts solution is that it changes
with clkevt-driver. Some platforms might have strings as
"arch_timer" or "twd" or something else.
Is there some robust way which would work on any platform?
ARM/X86/etc ..
--
viresh
When tracing with tracepoints events the IP and CPSR are set to 0,
preventing the perf code to resolve the symbols:
./perf record -e kmem:kmalloc cal
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.007 MB perf.data (~321 samples) ]
./perf report
Overhead Command Shared Object Symbol
........ ....... ............. ...........
40.78% cal [unknown] [.]00000000
31.6% cal [unknown] [.]00000000
The examination of the gathered samples (perf report -D) shows the IP
is set to 0 and that the samples are considered as user space samples,
while the IP should be set from the registers and the samples should be
considered as kernel samples.
The fix is to implement perf_arch_fetch_caller_regs for ARM, which
fills the necessary registers used for the callchain unwinding and
to determine the user/kernel space property of the samples: ip, sp, fp
and cpsr.
Tested with perf record and tracepoints filtering (-e <tracepoint>), with
unwinding using fp (--call-graph fp) and dwarf info (--call-graph dwarf).
Reported by Sneha Priya on linaro-dev, cf.
http://lists.linaro.org/pipermail/linaro-dev/2014-May/017151.html
Signed-off-by: Jean Pihet <jean.pihet(a)linaro.org>
Cc: Will Deacon <will.deacon(a)arm.com>
Reported-by: Sneha Priya <sneha.cse(a)hotmail.com>
---
arch/arm/include/asm/perf_event.h | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
diff --git a/arch/arm/include/asm/perf_event.h b/arch/arm/include/asm/perf_event.h
index 7558775..5e31d46 100644
--- a/arch/arm/include/asm/perf_event.h
+++ b/arch/arm/include/asm/perf_event.h
@@ -26,6 +26,25 @@ struct pt_regs;
extern unsigned long perf_instruction_pointer(struct pt_regs *regs);
extern unsigned long perf_misc_flags(struct pt_regs *regs);
#define perf_misc_flags(regs) perf_misc_flags(regs)
+
+/*
+ * Take a snapshot of the regs.
+ * We only need a few of the regs:
+ * - ip for PERF_SAMPLE_IP
+ * - sp, fp for callchains
+ * - cpsr for user_mode() tests
+ */
+#define perf_arch_fetch_caller_regs(regs, __ip) { \
+ instruction_pointer(regs)= (__ip); \
+ __asm__ ( \
+ "mov %[_ARM_sp], sp \n\t" \
+ "mov %[_ARM_fp], fp \n\t" \
+ "mrs %[_ARM_cpsr], cpsr \n\t" \
+ : [_ARM_sp] "=r" (regs->ARM_sp), \
+ [_ARM_fp] "=r" (regs->ARM_fp), \
+ [_ARM_cpsr] "=r" (regs->ARM_cpsr) \
+ ); \
+}
#endif
#endif /* __ARM_PERF_EVENT_H__ */
--
1.8.1.2
when lock checking option enabled in kernel config, TC2 catch a deadlock bug
as following,
It looks hmp_idle_pull --> hmp_keepalive_delay --> cpuidle_driver_ref
interrupt into cpuidle_register_driver.
Since what we needs of cpuidle_driver in hmp_keepalive_delay are
exit_latency/target_residency, they should be fixed for this board.
So, could we avoid the cpuidle_driver_ref calling by giving a fixed value?
That also can save a cpuidle_get_cpu_driver?
===============
[ 113.878488] [ INFO: inconsistent lock state ]
[ 113.878493] 3.10.42+ #4 Not tainted
[ 113.878496] ---------------------------------
[ 113.878501] inconsistent
{SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage.
[ 113.878507] ksoftirqd/4/28 [HC0[0]:SC1[1]:HE1:SE0] takes:
[ 113.878531] (cpuidle_driver_lock){+.?...}, at: [<c035bded>] cpuidle_driver_ref+0x15/0x58
[ 113.878534] {SOFTIRQ-ON-W}
state was registered at:
[ 113.878545] [<c006eedd>] __lock_acquire+0x539/0x8c8
[ 113.878554] [<c006f913>] lock_acquire+0x113/0x164
[ 113.878565] [<c047e24b>] _raw_spin_lock+0x33/0x40
[ 113.878573] [<c035bc73>] cpuidle_register_driver+0x37/0xf4
[ 113.878583] [<c06bab1d>] bl_idle_init+0x85/0x128
[ 113.878592] [<c0008665>] do_one_initcall+0x99/0x11c
[ 113.878603] [<c0695a5f>] kernel_init_freeable+0x10b/0x188
[ 113.878611] [<c046f96d>] kernel_init+0x19/0x108
[ 113.878619] [<c000d4a9>] ret_from_fork+0x11/0x1c
[ 113.878622] irq event stamp: 28
[ 113.878633] hardirqs last enabled at (28): [<c047e48f>] _raw_spin_unlock_irqrestore+0x2f/0x44
[ 113.878642] hardirqs last disabled at (27): [<c047e335>] _raw_spin_lock_irqsave+0x19/0x4c
[ 113.878652] softirqs last enabled at (0): [<c001d658>] copy_process+0x3c4/0xe34
[ 113.878661] softirqs last disabled at (17): [<c002578b>] run_ksoftirqd+0x2f/0x5c
[ 113.878664]
[ 113.878664] other info that might help us debug this:
[ 113.878667] Possible unsafe locking scenario:
[ 113.878667]
[ 113.878670] CPU0
[ 113.878673] ----
[ 113.878681] lock(cpuidle_driver_lock);
[ 113.878684] <Interrupt>
[ 113.878691] lock(cpuidle_driver_lock);
[ 113.878693]
[ 113.878693] *** DEADLOCK ***
[ 113.878693]
[ 113.878697] 1 lock held by ksoftirqd/4/28:
[ 113.878719] #0: (hmp_force_migration){+.....}, at: [<c0054da5>] hmp_idle_pull+0x49/0x508
[ 113.878722]
--
Thanks
Alex
Changelog:
V5:
* Removed patch : "Move clock setup to pm.c"
* Added patch : "Move arm core power down clock to exynos5250 common code"
V4:
* Took into account Tomasz's comments
* Fixed missing call in for central suspend
* Passed parameter to the wakeup mask function
* Moved wakeup mask, boot vector and aftr state into a single
function
* Used this function as callback for platform data
* Moved S5P_CHECK_AFTR/S5P_CHECK_SLEEP into pm.c
* Set boot vector only one time
* Splitted some patches to make them more readable
V3:
* Added patch : "ARM: exynos: cpuidle: Disable cpuidle for 5440"
* Removed patch : "ARM: exynos: config: Enable cpuidle"
* Removed default ARM_EXYNOS4210_CPUIDLE=y
* Added comment about bug fix side effect 'for_each_possible_cpu'
V2:
* Added comment in changelog for calls order (5/17)
* Call the powerdown only for cpu0 in the pm notifier
* Set the pm notifier for all boards
V1: initial post
This patchset relies on the cpm_pm notifier to initiate the powerdown sequence
operations from pm.c instead cpuidle.c. Thus the cpuidle driver is no longer
dependent from arch specific code as everything is called from the pm.c file.
The patchset applies on top of linux-samsung/for-next.
Tested on exynos4: 4210
Tested on exynos5: 5250 (without AFTR)
Amit Daniel Kachhap (1):
ARM: EXYNOS: Move arm core power down clock to exynos5250 common
clock
Daniel Lezcano (19):
ARM: exynos: cpuidle: Prevent forward declaration
ARM: exynos: cpuidle: Use cpuidle_register
ARM: exynos: cpuidle: Change function name prefix
ARM: exynos: cpuidle: Encapsulate register access inside a function
ARM: exynos: cpuidle: Move some code inside the idle_finisher
ARM: exynos: cpuidle: Fix S5P_WAKEUP_STAT call
ARM: exynos: cpuidle: Use the cpu_pm notifier
ARM: exynos: cpuidle: Move scu_enable in the cpu_pm notifier
ARM: exynos: cpuidle: Remove ifdef for scu_enable
ARM: exynos: cpuidle: Pass wakeup mask parameter to function
ARM: exynos: cpuidle: Encapsulate boot vector code into a function
ARM: exynos: cpuidle: Disable cpuidle for 5440
ARM: exynos: cpuidle: Encapsulate the AFTR code into a function
ARM: exynos: cpuidle: Move the AFTR state function into pm.c
ARM: exynos: cpuidle: Move the power sequence call in the cpu_pm
notifier
ARM: exynos: cpuidle: Move S5P_CHECK_SLEEP into pm.c
ARM: exynos: cpuidle: Pass the AFTR callback to the platform_data
ARM: exynos: cpuidle: Cleanup all unneeded headers from cpuidle.c
ARM: exynos: cpuidle: Move the driver to drivers/cpuidle directory
arch/arm/mach-exynos/Makefile | 1 -
arch/arm/mach-exynos/common.h | 1 +
arch/arm/mach-exynos/cpuidle.c | 255 ----------------------------------
arch/arm/mach-exynos/exynos.c | 8 +-
arch/arm/mach-exynos/pm.c | 152 ++++++++++++++++----
arch/arm/mach-exynos/regs-pmu.h | 2 -
drivers/clk/samsung/clk-exynos5250.c | 42 ++++++
drivers/cpuidle/Kconfig.arm | 6 +
drivers/cpuidle/Makefile | 1 +
drivers/cpuidle/cpuidle-exynos.c | 98 +++++++++++++
10 files changed, 277 insertions(+), 289 deletions(-)
delete mode 100644 arch/arm/mach-exynos/cpuidle.c
create mode 100644 drivers/cpuidle/cpuidle-exynos.c
--
1.7.9.5