Multiple platforms are using the generic cpufreq-dt driver now, and all
of them are required to create a platform device with name "cpufreq-dt",
in order to get the cpufreq-dt probed.
Many of them do it from platform code, others have special drivers just
to do that.
It would be more sensible to do this at a generic place, where all such
platform can mark their entries.
The first patch fixes an issue that becomes visible only after the
second patch is applied. The second one creates a new driver to create
platform-device based on current platform and the last one converts
exynos platform to use this common infrastructure.
I will migrate rest of the platforms after this is accepted as the right
way ahead.
@Arnd: Does this look sane? We can fix the arm64 (no platform code)
issue with this now.
Viresh Kumar (3):
cpufreq: dt: Include types.h from cpufreq-dt.h
cpufreq: dt: Add generic platform-device creation support
cpufreq: exynos: Use generic platdev driver
arch/arm/mach-exynos/exynos.c | 25 -----------------
drivers/cpufreq/Kconfig | 11 ++++++++
drivers/cpufreq/Makefile | 1 +
drivers/cpufreq/cpufreq-dt-platdev.c | 53 ++++++++++++++++++++++++++++++++++++
include/linux/cpufreq-dt.h | 2 ++
5 files changed, 67 insertions(+), 25 deletions(-)
create mode 100644 drivers/cpufreq/cpufreq-dt-platdev.c
--
2.7.1.410.g6faf27b
Hi There,
I am working to implement hibernation (Suspend to disk) on ARM and have
successfully done that by using swsusp ARM patch by Sebastian Capella
<https://lists.linaro.org/pipermail/linaro-kernel/2014-March/012112.html>.
Now I can hibernate (suspend to swap partition in *sd* card) the kernel
using the command echo disk > /sys/power/state and the system will resume
its state with the next power on. But if I press reset again the kernel
follow a normal boot sequence.
My question is how can I make that swap area and hibernate image in that
area permanent, so that in every reset it will awake from that permanent
image? I have given the value of swapiness=0 so that I expect there wont be
any swapping of pages any more while system is alive. How kernel decide
whether go for a normal boot or awake from (resume=/dev/swap_partition)
hibernation?
I searched a lot on internet but didn't get a clear idea about how Linux
kernel is awaking from hibernation and what it will do with swap after
resuming once.Thank you for your time
My kernel version is 3.14
--
Regards,
Shyamjith K V
Hi all,
I found one bug for enabling Hikey's usb gadget driver; this bug only
happen when I use linux-linaro-lsk-v4.1-android but
linux-linaro-lsk-v4.1 has no such issue.
The detailed info for this bug is: When system bootup, I use configfs
to enable ethernet on USB, kernel dumps below backtrace.
After narrow down this issue, found below patch introduce this issue:
commit 3fdf0dcfea876a0d730da5544f947b0a19c37fdc
Author: Badhri Jagan Sridharan <Badhri(a)google.com>
Date: Wed Sep 24 18:58:23 2014 -0700
usb: u_ether: Add workqueue as bottom half handler for rx data path
u_ether driver passes rx data to network layer and resubmits the
request back to usb hardware in interrupt context. Network layer
processes rx data by scheduling tasklet. For high throughput
scenarios on rx data path driver is spending lot of time in interrupt
context due to rx data processing by tasklet and continuous completion
and re-submission of the usb requests which results in watchdog bark.
Hence move the rx data processing and usb request submission to a
workqueue bottom half handler.
Change-Id: I316de8e267997137ac189a8b7b2846fa325f4a5a
Signed-off-by: Badhri Jagan Sridharan <Badhri(a)google.com>
I'm not familiar with USB driver, so want to get some suggestion to fix
this issue. BTW, I also searched this patch, but this patch have not
been really merged into mainline kernel.
Thanks,
Leo Yan
--- Kernel dump log ---
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
[ 11.638907] using random self ethernet address
[ 11.643381] using random host ethernet address
[ 11.677646] usb0: HOST MAC 0a:70:5f:8a:c1:aa
[ 11.682136] usb0: MAC 1e:84:31:c3:50:0f
[ 11.689207] dwc2 f72c0000.usb: bound driver configfs-gadget
[ 11.701933] dwc2 f72c0000.usb: bound driver configfs-gadget
SIOCSIFHWADDR: Device or resource busy - you may need to down the interface
root@linaro-developer:~# [ 12.009430] dwc2 f72c0000.usb: new device is high-speed
[ 12.094179] dwc2 f72c0000.usb: new device is high-speed
[ 12.164194] dwc2 f72c0000.usb: new address 53
[ 12.191379] configfs-gadget gadget: high-speed config #1: c
[ 12.256053] ------------[ cut here ]------------
[ 12.260753] WARNING: CPU: 0 PID: 0 at kernel/workqueue.c:1369 __queue_work+0x2dc/0x354()
[ 12.268861] Modules linked in:
[ 12.271932] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.1.15+ #86
[ 12.278033] Hardware name: HiKey Development Board (DT)
[ 12.283265] Call trace:
[ 12.285722] [<ffffffc00008a928>] dump_backtrace+0x0/0x164
[ 12.291131] [<ffffffc00008aaac>] show_stack+0x20/0x28
[ 12.296196] [<ffffffc0006f0b38>] dump_stack+0x84/0xc4
[ 12.301260] [<ffffffc0000bc960>] warn_slowpath_common+0xa8/0xdc
[ 12.307192] [<ffffffc0000bcae0>] warn_slowpath_null+0x38/0x44
[ 12.312959] [<ffffffc0000d51d8>] __queue_work+0x2dc/0x354
[ 12.318377] [<ffffffc0000d52d0>] queue_work_on+0x80/0xa4
[ 12.323712] [<ffffffc00057e748>] rx_complete+0xd4/0x1ac
[ 12.328958] [<ffffffc00057c110>] usb_gadget_giveback_request+0x2c/0x38
[ 12.335510] [<ffffffc0005516d4>] s3c_hsotg_complete_request+0xdc/0x1ec
[ 12.342059] [<ffffffc000553e08>] s3c_hsotg_handle_outdone+0xa4/0x1d0
[ 12.348433] [<ffffffc0005541d0>] s3c_hsotg_epint+0x29c/0x6f4
[ 12.354112] [<ffffffc000554dd8>] s3c_hsotg_irq+0x408/0x734
[ 12.359621] [<ffffffc00010fca4>] handle_irq_event_percpu+0x64/0x210
[ 12.365909] [<ffffffc00010fea4>] handle_irq_event+0x54/0x80
[ 12.371501] [<ffffffc000112f6c>] handle_fasteoi_irq+0xb4/0x178
[ 12.377355] [<ffffffc00010f214>] generic_handle_irq+0x3c/0x54
[ 12.383121] [<ffffffc00010f564>] __handle_domain_irq+0x6c/0xbc
[ 12.388972] [<ffffffc000082494>] gic_handle_irq+0x3c/0x88
[ 12.394388] Exception stack(0xffffffc000a83d30 to 0xffffffc000a83e50)
[ 12.400850] 3d20: d91bd3d5 00000002 00b0bce0 ffffffc0
[ 12.409063] 3d40: 00a83e70 ffffffc0 005ae31c ffffffc0 00000000 00000000 005ae318 ffffffc0
[ 12.417275] 3d60: 00a80000 ffffffc0 005d8518 ffffffc0 00000020 00000000 004ea4a9 00000000
[ 12.425487] 3d80: 5fe6aba0 00023c34 00000019 00000000 b5193519 00000032 00084800 ffffffc0
[ 12.433697] 3da0: 00000000 00000000 00000000 00000000 34d5d91d 00000000 00000000 00000000
[ 12.441908] 3dc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[ 12.450120] 3de0: 00000000 00000000 d91bd3d5 00000002 00b0bce0 ffffffc0 3a3bfe00 ffffffc0
[ 12.458332] 3e00: 00000002 00000000 00000001 00000000 00000000 00000000 d8fad491 00000002
[ 12.466544] 3e20: 00a64b50 ffffffc0 00a6a1d8 ffffffc0 007099b0 ffffffc0 00a83e70 ffffffc0
[ 12.474753] 3e40: 005ae318 ffffffc0 00a83e70 ffffffc0
[ 12.479822] [<ffffffc0000855ac>] el1_irq+0x6c/0xe0
[ 12.484634] [<ffffffc0005ae568>] cpuidle_enter+0x30/0x3c
[ 12.489967] [<ffffffc0000fff98>] call_cpuidle+0x44/0x78
[ 12.495212] [<ffffffc0001001f8>] cpu_startup_entry+0x22c/0x314
[ 12.501064] [<ffffffc0006ebc44>] rest_init+0x8c/0x94
[ 12.506051] [<ffffffc0009b3980>] start_kernel+0x394/0x3a8
[ 12.511466] ---[ end trace 7240af96fd6fdc18 ]---
Hi Alex,
Below two patches are important for CPU's suspend/resume flow; These
two patches have been merged into mainline kernel already.
If without Sudeep's patch, cpu will get wrong context when it returns
back and finally introduce system hang issue. So patch 1 is fatal.
For Will Deacon's patch, I have not seen obvious issue if without it
on Hikey. But for more safe, also ported this patch to fetch correct
instructions from PoU but discard potential stale instructions which
fetched from PoC.
Sudeep Holla (1):
arm64: restore cpu suspend/resume functionality
Will Deacon (1):
arm64: mm: ensure patched kernel text is fetched from PoU
arch/arm64/kernel/head.S | 8 ++++++++
arch/arm64/kernel/sleep.S | 9 ++++++++-
arch/arm64/mm/proc.S | 1 -
3 files changed, 16 insertions(+), 2 deletions(-)
--
1.9.1