* [GIT PULL 1/3] ARM: dts: exynos: DT for v4.10
From: Krzysztof Kozlowski @ 2016-11-08 18:26 UTC (permalink / raw)
To: Olof Johansson, Arnd Bergmann, Kevin Hilman, arm
Cc: Krzysztof Kozlowski, Kukjin Kim, linux-arm-kernel,
linux-samsung-soc, linux-kernel, Javier Martinez Canillas
In-Reply-To: <1478629589-7520-1-git-send-email-krzk@kernel.org>
Hi,
Hurray! New board! ... Exynos4415 slowly is going away.
Best regards,
Krzysztof
The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:
Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git tags/samsung-dt-4.10
for you to fetch changes up to 05a3589f46f913fbe91704f12fdca46a0eb0a27b:
ARM: dts: exynos: Add SCU device node to exynos4.dtsi (2016-11-05 17:39:50 +0200)
----------------------------------------------------------------
Samsung DeviceTree update for v4.10:
1. Add TOPEET itop core and Elite boards, based on Exynos4412.
2. Remove the Exynos4415 DTSI. We did not have any mainlined boards
using it. I am also not aware of any popular out-of-tree boards using it.
3. Add Snoop Control Unit node for Exynos4.
4. Minor cleanups.
----------------------------------------------------------------
Javier Martinez Canillas (1):
ARM: dts: exynos: Document eMMC/SD/SDIO devices in Snow and Peach boards
Krzysztof Kozlowski (1):
ARM: dts: exynos: Remove exynos4415.dtsi
Pankaj Dubey (1):
ARM: dts: exynos: Add SCU device node to exynos4.dtsi
Randy Li (2):
ARM: dts: exynos: Add TOPEET itop core board SCP package version
ARM: dts: exynos: Add TOPEET itop elite based board
Sylwester Nawrocki (2):
ARM: dts: exynos: Remove "simple-bus" compatible from fimc-is node
ARM: dts: exynos: Add entries for sound support on Odroid-XU board
.../bindings/arm/samsung/samsung-boards.txt | 3 +
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/exynos4.dtsi | 5 +
arch/arm/boot/dts/exynos4412-itop-elite.dts | 240 ++++++++
arch/arm/boot/dts/exynos4412-itop-scp-core.dtsi | 501 ++++++++++++++++
arch/arm/boot/dts/exynos4415-pinctrl.dtsi | 575 ------------------
arch/arm/boot/dts/exynos4415.dtsi | 650 ---------------------
arch/arm/boot/dts/exynos4x12.dtsi | 2 +-
arch/arm/boot/dts/exynos5250-snow-common.dtsi | 4 +
arch/arm/boot/dts/exynos5410-odroidxu.dts | 69 +++
arch/arm/boot/dts/exynos5410-pinctrl.dtsi | 9 +
arch/arm/boot/dts/exynos5410.dtsi | 59 ++
arch/arm/boot/dts/exynos5420-peach-pit.dts | 3 +
arch/arm/boot/dts/exynos5800-peach-pi.dts | 3 +
14 files changed, 898 insertions(+), 1226 deletions(-)
create mode 100644 arch/arm/boot/dts/exynos4412-itop-elite.dts
create mode 100644 arch/arm/boot/dts/exynos4412-itop-scp-core.dtsi
delete mode 100644 arch/arm/boot/dts/exynos4415-pinctrl.dtsi
delete mode 100644 arch/arm/boot/dts/exynos4415.dtsi
^ permalink raw reply
* GPF in sidtab_context_to_sid
From: Roberts, William C @ 2016-11-08 18:26 UTC (permalink / raw)
To: 'selinux@tycho.nsa.gov'
[-- Attachment #1: Type: text/plain, Size: 5335 bytes --]
I found a very similar oops online:
http://oops.kernel.org/oops/general-protection-fault-in-sidtab_context_to_sid/
Has anyone encountered this bug?
I had something reported to me very similar where the faulting instruction was:
0xffffffff8133c81e <+174>: mov 0x14(%r12),%eax
Addr2line on vmlinux produced:
$ addr2line -f -e ./vmlinux ffffffff8133c81e
context_cmp
kernel/cht/security/selinux/ss/context.h:152
Actual Dump:
[131436.409639] general protection fault: 0000 [#1] PREEMPT SMP
[131436.416085] Modules linked in: tcp_diag inet_diag
atomisp_css2401a0_v21 videobuf_vmalloc videobuf_core bt_lpm
rfkill_gpio 8723bs(O) cfg80211 ov2680 ov8858_driver silead_ts ltr501
bmg160 ak09911 kxcjk_1013
[131436.436623] CPU: 3 PID: 3177 Comm: SettingsProvide Tainted: G
W O 3.14.70-x86_64-02246-g49319b8 #1
[131436.447500] Hardware name: XXX
CHTMRD.A6.002.016 09/20/2016
[131436.456542] task: ffff88006039cb30 ti: ffff88005e2ea000 task.ti:
ffff88005e2ea000
[131436.465000] RIP: 0010:[<ffffffff8133c81e>]
[131436.469579] [<ffffffff8133c81e>] sidtab_context_to_sid+0xae/0x480
[131436.476783] RSP: 0018:ffff88005e2ebae0 EFLAGS: 00010286
[131436.482814] RAX: 00000000fff9f9f9 RBX: ffffffff82776540 RCX:
0000000000000000
[131436.490884] RDX: 0000000000000000 RSI: 0000000000000000 RDI:
ffffffff82776540
[131436.498953] RBP: ffff88005e2ebb28 R08: ffff88005e2ebb88 R09:
0000000000000000
[131436.507022] R10: ffff88007826c000 R11: 2f2f2f2f2f2f2f2f R12:
fff9f9f9fff9f9f9
[131436.515091] R13: ffff88005e2ebba0 R14: ffff88005e2ebbb8 R15:
0000000000000068
[131436.523160] FS: 00000000d1efbe00(006b) GS:ffff880079380000(0063)
knlGS:00000000d1a77960
[131436.532297] CS: 0010 DS: 002b ES: 002b CR0: 0000000080050033
[131436.538813] CR2: 0000000072e67750 CR3: 000000005e1ba000 CR4:
00000000001007e0
[131436.546883] Last Branch Records:
[131436.550590] to: [<ffffffff81aa9ac0>] general_protection+0x0/0x80
[131436.557700] from: [<ffffffff8133c81e>] sidtab_context_to_sid+0xae/0x480
[131436.565292] to: [<ffffffff8133c810>] sidtab_context_to_sid+0xa0/0x480
[131436.572885] from: [<ffffffff8133c806>] sidtab_context_to_sid+0x96/0x480
[131436.580478] to: [<ffffffff8133c800>] sidtab_context_to_sid+0x90/0x480
[131436.588070] from: [<ffffffff8133c825>] sidtab_context_to_sid+0xb5/0x480
[131436.595662] to: [<ffffffff8133c810>] sidtab_context_to_sid+0xa0/0x480
[131436.603255] from: [<ffffffff8133c842>] sidtab_context_to_sid+0xd2/0x480
[131436.610847] to: [<ffffffff8133c810>] sidtab_context_to_sid+0xa0/0x480
[131436.618439] from: [<ffffffff8133c842>] sidtab_context_to_sid+0xd2/0x480
[131436.626031] to: [<ffffffff8133c810>] sidtab_context_to_sid+0xa0/0x480
[131436.633624] from: [<ffffffff8133c842>] sidtab_context_to_sid+0xd2/0x480
[131436.641216] to: [<ffffffff8133c81e>] sidtab_context_to_sid+0xae/0x480
[131436.648810] from: [<ffffffff8133c7ef>] sidtab_context_to_sid+0x7f/0x480
[131436.656401] to: [<ffffffff8133c7e5>] sidtab_context_to_sid+0x75/0x480
[131436.663994] from: [<ffffffff8133cabb>] sidtab_context_to_sid+0x34b/0x480
[131436.671684] Stack:
[131436.674023] ffff88005e2ebb88 ffff88005e2ebb08 ffffffff8134938e
ffff88005e2ebc3c
[131436.682416] 0000000000000000 ffff88005e2ebb88 0000000000000010
ffff880060371ea8
[131436.690809] ffff8800716d4968 ffff88005e2ebbf8 ffffffff8134372f
0000000600000000
[131436.699204] Call Trace:
[131436.702036] [<ffffffff8134938e>] ? mls_context_isvalid+0x2e/0xb0
[131436.708944] [<ffffffff8134372f>] security_compute_sid.part.10+0x43f/0x550
[131436.716727] [<ffffffff81275d00>] ? search_dir+0x40/0x120
[131436.722851] [<ffffffff8134388e>] security_compute_sid+0x4e/0x50
[131436.729660] [<ffffffff81345d8d>] security_transition_sid+0x2d/0x40
[131436.736762] [<ffffffff81330496>] may_create+0x96/0x100
[131436.742699] [<ffffffff81330553>] selinux_inode_create+0x13/0x20
[131436.749509] [<ffffffff8132bcef>] security_inode_create+0x1f/0x30
[131436.756417] [<ffffffff811d146e>] vfs_create+0x8e/0x140
[131436.762353] [<ffffffff811d1d01>] do_last+0x7e1/0x1210
[131436.768192] [<ffffffff811cd71c>] ? link_path_walk+0x8c/0xfb0
[131436.774712] [<ffffffff811ab3f1>] ? kmem_cache_alloc_trace+0xe1/0x1d0
[131436.782008] [<ffffffff81333e4c>] ? selinux_file_alloc_security+0x3c/0x60
[131436.789692] [<ffffffff811d27eb>] path_openat+0xbb/0x6d0
[131436.795724] [<ffffffff811d0fb8>] ? SYSC_renameat+0xe8/0x3f0
[131436.802146] [<ffffffff811d363a>] do_filp_open+0x3a/0xa0
[131436.808179] [<ffffffff81aa8e78>] ? _raw_spin_unlock+0x18/0x40
[131436.814795] [<ffffffff811e03b7>] ? __alloc_fd+0xa7/0x130
[131436.820925] [<ffffffff811c090c>] do_sys_open+0x12c/0x220
[131436.827056] [<ffffffff812176a1>] compat_SyS_openat+0x11/0x20
[131436.833574] [<ffffffff81ab2f23>] sysenter_dispatch+0x7/0x1f
[131436.839997] [<ffffffff8139b49b>] ? trace_hardirqs_on_thunk+0x3a/0x3c
[131436.847289] Code: 02 00 00 66 2e 0f 1f 84 00 00 00 00 00 41 8b 50
0c 85 d2 74 08 39 d0 0f 84 70 02 00 00 4d 8b 64 24 50 4d 85 e4 0f 84
92 02 00 00 <41> 8b 44 24 14 85 c0 75 d9 41 8b 48 0c 85 c9 75 e1 49 8b
00 49
[131436.869023] RIP
[131436.870977] [<ffffffff8133c81e>] sidtab_context_to_sid+0xae/0x480
[131436.878180] RSP <ffff88005e2ebae0>
[131436.882285] ---[ end trace 4c33bfa820f020fe ]---
[-- Attachment #2: Type: text/html, Size: 11405 bytes --]
^ permalink raw reply
* [GIT PULL 0/3] ARM: exynos: Stuff for v4.10
From: Krzysztof Kozlowski @ 2016-11-08 18:26 UTC (permalink / raw)
To: Olof Johansson, Arnd Bergmann, Kevin Hilman, arm
Cc: Krzysztof Kozlowski, Kukjin Kim, linux-arm-kernel,
linux-samsung-soc, linux-kernel, Javier Martinez Canillas
Hi,
Two weeks ago it looked it will be very boring merge window for Samsung,
but luckily it is not!
So far we got Exynos5433 and two boards on it. ARMv7 got one board
using Exynos4412.
I am pushing this patches early but expect another pull requests in few weeks.
No order of pulling, no dependencies.
Best regards,
Krzysztof
^ permalink raw reply
* [GIT PULL 2/3] ARM64: dts: exynos: DT for v4.10
From: Krzysztof Kozlowski @ 2016-11-08 18:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478629589-7520-1-git-send-email-krzk@kernel.org>
Hi,
Exynos5433 + two boards using it. Mobile boards! :)
I am really happy to push it. I know that it has been a lot of effort
in Samsung to mainline this.
Best regards,
Krzysztof
The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:
Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git tags/samsung-dt64-4.10
for you to fetch changes up to 8ac46fc57df82efbc19194dddd335b6c7a960c31:
arm64: dts: exynos: Add dts file for Exynos5433-based TM2E board (2016-11-03 22:19:57 +0200)
----------------------------------------------------------------
Finally, I am really pleased to announce adding support for Exynos5433 ARMv8
SoC along with two boards. A lot of Samsung people contributed into this
but the final work and commits were done by Chanwoo Choi.
This means that for v4.10 we got:
1. Exynos5433 DTSI.
2. Two boards: TM2 and TM2E. These are (almost fully) working mobile phones.
----------------------------------------------------------------
Chanwoo Choi (3):
arm64: dts: exynos: Add dtsi files for Samsung Exynos5433 64bit SoC
arm64: dts: exynos: Add dts file for Exynos5433-based TM2 board
arm64: dts: exynos: Add dts file for Exynos5433-based TM2E board
.../bindings/arm/samsung/samsung-boards.txt | 2 +
arch/arm64/boot/dts/exynos/Makefile | 5 +-
arch/arm64/boot/dts/exynos/exynos5433-pinctrl.dtsi | 794 ++++++++++++
arch/arm64/boot/dts/exynos/exynos5433-tm2.dts | 974 ++++++++++++++
arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts | 41 +
.../dts/exynos/exynos5433-tmu-g3d-sensor-conf.dtsi | 23 +
.../dts/exynos/exynos5433-tmu-sensor-conf.dtsi | 22 +
arch/arm64/boot/dts/exynos/exynos5433-tmu.dtsi | 296 +++++
arch/arm64/boot/dts/exynos/exynos5433.dtsi | 1356 ++++++++++++++++++++
9 files changed, 3512 insertions(+), 1 deletion(-)
create mode 100644 arch/arm64/boot/dts/exynos/exynos5433-pinctrl.dtsi
create mode 100644 arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
create mode 100644 arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts
create mode 100644 arch/arm64/boot/dts/exynos/exynos5433-tmu-g3d-sensor-conf.dtsi
create mode 100644 arch/arm64/boot/dts/exynos/exynos5433-tmu-sensor-conf.dtsi
create mode 100644 arch/arm64/boot/dts/exynos/exynos5433-tmu.dtsi
create mode 100644 arch/arm64/boot/dts/exynos/exynos5433.dtsi
^ permalink raw reply
* [GIT PULL 1/3] ARM: dts: exynos: DT for v4.10
From: Krzysztof Kozlowski @ 2016-11-08 18:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478629589-7520-1-git-send-email-krzk@kernel.org>
Hi,
Hurray! New board! ... Exynos4415 slowly is going away.
Best regards,
Krzysztof
The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:
Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git tags/samsung-dt-4.10
for you to fetch changes up to 05a3589f46f913fbe91704f12fdca46a0eb0a27b:
ARM: dts: exynos: Add SCU device node to exynos4.dtsi (2016-11-05 17:39:50 +0200)
----------------------------------------------------------------
Samsung DeviceTree update for v4.10:
1. Add TOPEET itop core and Elite boards, based on Exynos4412.
2. Remove the Exynos4415 DTSI. We did not have any mainlined boards
using it. I am also not aware of any popular out-of-tree boards using it.
3. Add Snoop Control Unit node for Exynos4.
4. Minor cleanups.
----------------------------------------------------------------
Javier Martinez Canillas (1):
ARM: dts: exynos: Document eMMC/SD/SDIO devices in Snow and Peach boards
Krzysztof Kozlowski (1):
ARM: dts: exynos: Remove exynos4415.dtsi
Pankaj Dubey (1):
ARM: dts: exynos: Add SCU device node to exynos4.dtsi
Randy Li (2):
ARM: dts: exynos: Add TOPEET itop core board SCP package version
ARM: dts: exynos: Add TOPEET itop elite based board
Sylwester Nawrocki (2):
ARM: dts: exynos: Remove "simple-bus" compatible from fimc-is node
ARM: dts: exynos: Add entries for sound support on Odroid-XU board
.../bindings/arm/samsung/samsung-boards.txt | 3 +
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/exynos4.dtsi | 5 +
arch/arm/boot/dts/exynos4412-itop-elite.dts | 240 ++++++++
arch/arm/boot/dts/exynos4412-itop-scp-core.dtsi | 501 ++++++++++++++++
arch/arm/boot/dts/exynos4415-pinctrl.dtsi | 575 ------------------
arch/arm/boot/dts/exynos4415.dtsi | 650 ---------------------
arch/arm/boot/dts/exynos4x12.dtsi | 2 +-
arch/arm/boot/dts/exynos5250-snow-common.dtsi | 4 +
arch/arm/boot/dts/exynos5410-odroidxu.dts | 69 +++
arch/arm/boot/dts/exynos5410-pinctrl.dtsi | 9 +
arch/arm/boot/dts/exynos5410.dtsi | 59 ++
arch/arm/boot/dts/exynos5420-peach-pit.dts | 3 +
arch/arm/boot/dts/exynos5800-peach-pi.dts | 3 +
14 files changed, 898 insertions(+), 1226 deletions(-)
create mode 100644 arch/arm/boot/dts/exynos4412-itop-elite.dts
create mode 100644 arch/arm/boot/dts/exynos4412-itop-scp-core.dtsi
delete mode 100644 arch/arm/boot/dts/exynos4415-pinctrl.dtsi
delete mode 100644 arch/arm/boot/dts/exynos4415.dtsi
^ permalink raw reply
* [GIT PULL 3/3] ARM: defconfig: Samsung defconfigs for v4.10
From: Krzysztof Kozlowski @ 2016-11-08 18:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478629589-7520-1-git-send-email-krzk@kernel.org>
Hi,
Nothing special.
Best regards,
Krzysztof
The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:
Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git tags/samsung-defconfig-4.10
for you to fetch changes up to e471e9b4b13b59ee8cb7079018472c4dda46cb7a:
ARM: multi_v7_defconfig: Enable exynos-gsc driver as module (2016-10-17 19:43:29 +0300)
----------------------------------------------------------------
Samsung defconfig update for v4.10:
1. Enable the Exynos gscaler driver on multi_v7 and exynos defconfigs.
----------------------------------------------------------------
Javier Martinez Canillas (2):
ARM: exynos_defconfig: Enable exynos-gsc driver as module
ARM: multi_v7_defconfig: Enable exynos-gsc driver as module
arch/arm/configs/exynos_defconfig | 1 +
arch/arm/configs/multi_v7_defconfig | 1 +
2 files changed, 2 insertions(+)
^ permalink raw reply
* [GIT PULL 3/3] ARM: defconfig: Samsung defconfigs for v4.10
From: Krzysztof Kozlowski @ 2016-11-08 18:26 UTC (permalink / raw)
To: Olof Johansson, Arnd Bergmann, Kevin Hilman, arm
Cc: Krzysztof Kozlowski, Kukjin Kim, linux-arm-kernel,
linux-samsung-soc, linux-kernel, Javier Martinez Canillas
In-Reply-To: <1478629589-7520-1-git-send-email-krzk@kernel.org>
Hi,
Nothing special.
Best regards,
Krzysztof
The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:
Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git tags/samsung-defconfig-4.10
for you to fetch changes up to e471e9b4b13b59ee8cb7079018472c4dda46cb7a:
ARM: multi_v7_defconfig: Enable exynos-gsc driver as module (2016-10-17 19:43:29 +0300)
----------------------------------------------------------------
Samsung defconfig update for v4.10:
1. Enable the Exynos gscaler driver on multi_v7 and exynos defconfigs.
----------------------------------------------------------------
Javier Martinez Canillas (2):
ARM: exynos_defconfig: Enable exynos-gsc driver as module
ARM: multi_v7_defconfig: Enable exynos-gsc driver as module
arch/arm/configs/exynos_defconfig | 1 +
arch/arm/configs/multi_v7_defconfig | 1 +
2 files changed, 2 insertions(+)
^ permalink raw reply
* [GIT PULL 0/3] ARM: exynos: Stuff for v4.10
From: Krzysztof Kozlowski @ 2016-11-08 18:26 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
Two weeks ago it looked it will be very boring merge window for Samsung,
but luckily it is not!
So far we got Exynos5433 and two boards on it. ARMv7 got one board
using Exynos4412.
I am pushing this patches early but expect another pull requests in few weeks.
No order of pulling, no dependencies.
Best regards,
Krzysztof
^ permalink raw reply
* Richacl and stored but ignored permissions
From: Steve French @ 2016-11-08 18:25 UTC (permalink / raw)
To: Andreas Gruenbacher, linux-fsdevel, samba-technical
Cc: Anne Marie Merritt, Weston Andros Adamson
I noticed that setrichacl (on ext4/xfs with richacl patches from your
tree) allows setting some of the five "stored but ignored" permissions
S synchronize
W write named attributes
R read named attributes
e write retention
E write retention hold
but it brings up some questions:
1) why is 'S' the only one of those five that although allowed to be
set, will not be displayed by getrichacl? Presumably if it can be
set, you might as well display it on getrichacl and that might have
been the original intent since there is a space for it when you do
"getrichacl --full" but that implies (probably correctly) that
'Sychronize' permission is always granted.
2) should we allow 'e' and 'E' to be set (I lean toward yes, but NFS
rejected it when I tried, although xfs/ext4 accepted it).
3) Shouldn't we actually do something with 'W' (and maybe 'R'
permission but presumably that can be just implied to be on since some
attributes always need to be readable) and actually enforce use of W
permission to allow/forbid the setting of xattrs on the file?
4) Shouldn't we display as enabled permissions those that are implicit
rather than leaving them out (as if they are forbidden)? e.g. the
'owner' permission ('o') presumably can be displayed for root (as it
is by default granted), Also note the 'a' and 'S' permissions when
you do "getrichacl --full" are displayed as unset even though they are
implicitly granted. You can fix that by setting 'a' explicitly but it
seems wrong to implicitly grant a permission, but not display it as
granted in getrichacl
--
Thanks,
Steve
^ permalink raw reply
* Re: [PATCH RFC 00/12] tda998x updates
From: Russell King - ARM Linux @ 2016-11-08 18:24 UTC (permalink / raw)
To: Jon Medhurst (Tixy)
Cc: Liviu Dudau, Jyri Sarha, dri-devel, Robin Murphy, Brian Starkey,
linux-arm-kernel
In-Reply-To: <1478625636.27416.7.camel@linaro.org>
On Tue, Nov 08, 2016 at 05:20:36PM +0000, Jon Medhurst (Tixy) wrote:
> On Tue, 2016-11-08 at 13:34 +0000, Russell King - ARM Linux wrote:
> > On Tue, Nov 08, 2016 at 01:32:15PM +0000, Russell King - ARM Linux wrote:
> > > Unfortunately, my drm-tda998x-devel branch is slightly out of date with
> > > these patches it's the original set of 10 patches. I've not pushed
> > > these ones out to that branch yet, as I've three additional patches on
> > > top of these which aren't "ready" for pushing out.
> >
> > Here's the delta between the branch and what I just posted:
> >
> > diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c b/drivers/gpu/drm/i2c/tda998x_drv.c
> [...]
>
> I have a working setup for HDMI audio on Juno an would like to test this
> series but am struggling to work out which patches to apply in what
> order to what branch, can you be specific? (I've tried various
> combinations of patches series from the list, drm-tda998x-devel, and the
> diff you posted)
Hmm, I guess this is going to be annoyingly rather difficult then.
The structure of my git tree is:
v4.8 ---------------- mali patch ------------------ merge --- these patches
v4.7 -- tda998x audio patches (up to df0bd1e8f3c5) --^
which makes it rather difficult to send out a series that people can
apply as patches without first replicating that merge. I guess the
answer is... use the _patches_ for review, and I'll push out the
changes into drm-tda998x-devel... should be there soon. Look for
commit hash d61fa2e50f2a. (Bah, slow 'net connections.)
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [PATCH RFC 00/12] tda998x updates
From: Russell King - ARM Linux @ 2016-11-08 18:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478625636.27416.7.camel@linaro.org>
On Tue, Nov 08, 2016 at 05:20:36PM +0000, Jon Medhurst (Tixy) wrote:
> On Tue, 2016-11-08 at 13:34 +0000, Russell King - ARM Linux wrote:
> > On Tue, Nov 08, 2016 at 01:32:15PM +0000, Russell King - ARM Linux wrote:
> > > Unfortunately, my drm-tda998x-devel branch is slightly out of date with
> > > these patches it's the original set of 10 patches. I've not pushed
> > > these ones out to that branch yet, as I've three additional patches on
> > > top of these which aren't "ready" for pushing out.
> >
> > Here's the delta between the branch and what I just posted:
> >
> > diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c b/drivers/gpu/drm/i2c/tda998x_drv.c
> [...]
>
> I have a working setup for HDMI audio on Juno an would like to test this
> series but am struggling to work out which patches to apply in what
> order to what branch, can you be specific? (I've tried various
> combinations of patches series from the list, drm-tda998x-devel, and the
> diff you posted)
Hmm, I guess this is going to be annoyingly rather difficult then.
The structure of my git tree is:
v4.8 ---------------- mali patch ------------------ merge --- these patches
v4.7 -- tda998x audio patches (up to df0bd1e8f3c5) --^
which makes it rather difficult to send out a series that people can
apply as patches without first replicating that merge. I guess the
answer is... use the _patches_ for review, and I'll push out the
changes into drm-tda998x-devel... should be there soon. Look for
commit hash d61fa2e50f2a. (Bah, slow 'net connections.)
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* Re: [dpdk-moving] Draft Project Charter
From: O'Driscoll, Tim @ 2016-11-08 18:23 UTC (permalink / raw)
To: Matt Spencer, Vincent JARDIN, moving@dpdk.org; +Cc: dev@dpdk.org
In-Reply-To: <AM5PR0801MB20516E1B9DF6B283C5897B2395A60@AM5PR0801MB2051.eurprd08.prod.outlook.com>
Agreed. I think we should use next week's meeting to walk through the document, discuss the comments, and agree on the changes.
As I said before, the two-level structure that's in there at the moment is a placeholder, but it does allow for one level of contribution to the shared lab and a lower level contribution for marketing purposes.
Tim
From: Matt Spencer [mailto:Matt.Spencer@arm.com]
Sent: Tuesday, November 8, 2016 6:18 PM
To: O'Driscoll, Tim <tim.odriscoll@intel.com>; Vincent JARDIN <vincent.jardin@6wind.com>; moving@dpdk.org
Cc: dev@dpdk.org
Subject: Re: [dpdk-moving] [dpdk-dev] Draft Project Charter
I think we need a discussion about the levels of membership - possibly at next weeks meeting?
My feeling is that we need more than one level
- One to enable contribution of hardware to the lab, as the lab will add cost to the overall project budget
- A second to enable contribution to the marketing aspects of the project and to allow association for marketing purposes
Calling these Gold and Silver is fine with me, but as I say, lets discuss this at next weeks meeting.
Matt
________________________________
From: moving <moving-bounces@dpdk.org<mailto:moving-bounces@dpdk.org>> on behalf of O'Driscoll, Tim <tim.odriscoll@intel.com<mailto:tim.odriscoll@intel.com>>
Sent: 08 November 2016 03:57:36
To: Vincent JARDIN; moving@dpdk.org<mailto:moving@dpdk.org>
Cc: dev@dpdk.org<mailto:dev@dpdk.org>
Subject: Re: [dpdk-moving] [dpdk-dev] Draft Project Charter
> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Vincent JARDIN
> Sent: Tuesday, November 8, 2016 11:41 AM
> To: moving@dpdk.org<mailto:moving@dpdk.org>
> Cc: dev@dpdk.org<mailto:dev@dpdk.org>
> Subject: Re: [dpdk-dev] [dpdk-moving] Draft Project Charter
>
> Tim,
>
> Thanks for your draft, but it is not a good proposal. It is not written
> in the spirit that we have discussed in Dublin:
> - you create the status of "Gold" members that we do not want from
> Linux Foundation,
As I said in the email, I put in two levels of membership as a placeholder. The first thing we need to decide is if we want to have a budget and membership, or if we want the OVS model with 0 budget and no membership. We can discuss that at today's meeting.
If we do want a membership model then we'll need to decide if everybody contributes at the same rate or if we support multiple levels. So, for now, the text on having two levels is just an example to show what a membership model might look like.
> - you start with "DPDK's first $1,000,000", it is far from the $O
> that we agreed based on OVS model.
That's just standard text that I see in all the LF charters. It's even in the OVS charter (http://openvswitch.org/charter/charter.pdf) even though they have 0 budget. I assumed it's standard text for the LF. I'm sure Mike Dolan can clarify.
>
> Please, explain why you did change it?
>
> Thank you,
> Vincent
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
^ permalink raw reply
* Re: linux-next: Tree for Nov 8 (netdev, netfilter)
From: Randy Dunlap @ 2016-11-08 18:22 UTC (permalink / raw)
To: Stephen Rothwell, linux-next
Cc: linux-kernel, netdev@vger.kernel.org, netfilter-devel
In-Reply-To: <20161108183855.5f8c209a@canb.auug.org.au>
On 11/07/16 23:38, Stephen Rothwell wrote:
> Hi all,
>
> Changes since 20161028:
on i386 or x86_64:
net/built-in.o: In function `nf_sk_lookup_slow_v4':
(.text+0x97414): undefined reference to `udp4_lib_lookup'
when these are not enabled:
#if IS_ENABLED(CONFIG_NETFILTER_XT_MATCH_SOCKET) || \
IS_ENABLED(CONFIG_NETFILTER_XT_TARGET_TPROXY)
and
CONFIG_NF_SOCKET_IPV4=y
See net/ipv4/netfilter/nf_socket_ipv4.c.
Reported-by: Randy Dunlap <rdunlap@infradead.org>
--
~Randy
^ permalink raw reply
* RE: [PATCH] x86/MCE: Remove MCP_TIMESTAMP
From: Luck, Tony @ 2016-11-08 18:22 UTC (permalink / raw)
To: Borislav Petkov; +Cc: linux-edac, X86 ML, LKML
In-Reply-To: <20161108180932.wvvcbbzrzrai26eg@pd.tnic>
> This still preserves the precise TSC timestamp in intel_threshold_interrupt().
Yup - this looks right.
Acked-by: Tony Luck <tony.luck@intel.com>
-Tony
^ permalink raw reply
* Re: BUG: Hung task timeouts in for-4.10/dio
From: Jens Axboe @ 2016-11-08 18:21 UTC (permalink / raw)
To: Logan Gunthorpe, Christoph Hellwig; +Cc: linux-block, Stephen Bates
In-Reply-To: <366c9429-1bf8-a385-c8b3-a7e6c06a9907@deltatee.com>
On 11/08/2016 11:16 AM, Logan Gunthorpe wrote:
> Hi guys,
>
> We were looking at testing the new IO polling improvements and we built
> a kernel from the 'for-4.10/dio' (64ead7d) branch in linux-block.
> However this branch seems to cause hung tasks when booted. Most
> noticeably, dhclient seems to always hang as it tries to read from it's
> leases file, and that means networking does not work on the computers we
> tested on. Other tasks seemed to hang occasionally and randomly.
>
> We tested on two machines with radically different hardware but both
> running Debian Jessie. (One is a dual-socket server system with the
> root FS on an HDD and the other is an off the shelf commodity
> motherboard with root on an SSD.)
>
> We performed a bisect to find the culprit commit to be:
>
> [b685d3d65ac791406e0dfd8779cc9b3707fea5a3] block: treat REQ_FUA and
> REQ_PREFLUSH as synchronous
>
> I've attached a bisect log.
I don't think that's right. The version you ran has a bug in the stats
code. Please update to the current for-4.10/dio branch (82a78cd682bf)
and I think you'll have more luck.
--
Jens Axboe
^ permalink raw reply
* Re: [PATCH v3 1/2] arm64: Add hypervisor safe helper for checking constant capabilities
From: Will Deacon @ 2016-11-08 18:11 UTC (permalink / raw)
To: Suzuki K Poulose
Cc: linux-arm-kernel, linux-kernel, ard.biesheuvel, catalin.marinas,
mark.rutland, marc.zyngier, kvmarm, Robert Ritcher,
Tirumalesh Chalamarla
In-Reply-To: <1478613381-5718-2-git-send-email-suzuki.poulose@arm.com>
On Tue, Nov 08, 2016 at 01:56:20PM +0000, Suzuki K Poulose wrote:
> The hypervisor may not have full access to the kernel data structures
> and hence cannot safely use cpus_have_cap() helper for checking the
> system capability. Add a safe helper for hypervisors to check a constant
> system capability, which *doesn't* fall back to checking the bitmap
> maintained by the kernel. With this, make the cpus_have_cap() only
> check the bitmask and force constant cap checks to use the new API
> for quicker checks.
>
> Cc: Robert Ritcher <rritcher@cavium.com>
> Cc: Tirumalesh Chalamarla <tchalamarla@cavium.com>
> Cc: Marc Zyngier <marc.zyngier@arm.com>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Will Deacon <will.deacon@arm.com>
> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
> ---
> arch/arm64/include/asm/cpufeature.h | 19 ++++++++++++-------
> arch/arm64/kernel/cpufeature.c | 2 +-
> arch/arm64/kernel/process.c | 2 +-
> drivers/irqchip/irq-gic-v3.c | 13 +------------
It might be worth having the GIC changes as a separate patch, but either
way:
Reviewed-by: Will Deacon <will.deacon@arm.com>
Will
^ permalink raw reply
* Re: [PATCH v3 4/4] posix-timers: make it configurable
From: Nicolas Pitre @ 2016-11-08 18:19 UTC (permalink / raw)
To: John Stultz
Cc: Michal Marek, Richard Cochran, Paul Bolle, Thomas Gleixner,
Josh Triplett, Edward Cree, netdev, linux-kbuild, lkml
In-Reply-To: <CALAqxLVrGRW3ODzZk=4-8FSLe5wBwHJSOEAW=+kMFjTRoe1HzQ@mail.gmail.com>
On Tue, 8 Nov 2016, John Stultz wrote:
> One spot of concern is that the
> tools/testing/selftests/timers/posix_timers.c test hangs testing
> virtual itimers. Looking through the code I'm not seeing where an
> error case is missed.
>
> The strace looks like:
> ...
> write(1, "Testing posix timers. False nega"..., 66Testing posix
> timers. False negative may happen on CPU execution
> ) = 66
> write(1, "based timers if other threads ru"..., 48based timers if
> other threads run on the CPU...
> ) = 48
> write(1, "Check itimer virtual... ", 24Check itimer virtual... ) = 24
> rt_sigaction(SIGVTALRM, {0x400a80, [VTALRM], SA_RESTORER|SA_RESTART,
> 0x7fb73306ccb0}, {SIG_DFL, [], 0}, 8) = 0
> gettimeofday({1478710402, 937476}, NULL) = 0
> setitimer(ITIMER_VIRTUAL, {it_interval={0, 0}, it_value={2, 0}}, NULL) = 0
> <Hang>
>
>
> Where as with posix timers enabled:
> ...
> write(1, "Testing posix timers. False nega"..., 138Testing posix
> timers. False negative may happen on CPU execution
> based timers if other threads run on the CPU...
> Check itimer virtual... ) = 138
> rt_sigaction(SIGVTALRM, {0x400a80, [VTALRM], SA_RESTORER|SA_RESTART,
> 0x7f231ba8ccb0}, {SIG_DFL, [], 0}, 8) = 0
> gettimeofday({1478626751, 904856}, NULL) = 0
> setitimer(ITIMER_VIRTUAL, {it_interval={0, 0}, it_value={2, 0}}, NULL) = 0
> --- SIGVTALRM {si_signo=SIGVTALRM, si_code=SI_KERNEL} ---
> rt_sigreturn() = 0
I'll have a look.
> So I suspect you were a little too aggressive with the #ifdefs around
> the itimers/signal code, or we need to make sure we return an error on
> the setitimer ITIMER_VIRTUAL case as well.
Well, it seemed to me that with POSIX_TIMERS=n, all the code that would
set up that signal is gone, so there was no point keeping the code to
deliver it.
Now... would it make more sense to remove itimer support as well when
POSIX_TIMERS=n? The same reasoning would apply.
Nicolas
^ permalink raw reply
* Re: Xen ARM community call
From: Stefano Stabellini @ 2016-11-08 18:19 UTC (permalink / raw)
To: Julien Grall
Cc: Edgar Iglesias (edgar.iglesias@xilinx.com), andrii.anisov,
Stefano Stabellini, Steve Capper, alistair.francis, Lars Kurth,
stewart.hildebrand, Goel, Sameer, xen-devel@lists.xen.org,
Shanker Donthineni
In-Reply-To: <bc284008-e878-737d-5277-f7cff47fc626@arm.com>
On Tue, 8 Nov 2016, Julien Grall wrote:
> Hi all,
>
> I would like to start organizing a recurring community call to discuss and
> sync-up on upcoming features for Xen ARM.
>
> Example of features that could be discussed:
> - Sharing co-processor between guests
> - PCI passthrough
>
> I would suggest to start with a 1 hour meeting on the Wednesday 23rd November.
> I know that people are spread across different timezones, so I would like to
> gather thought before choosing a time.
Hi Julien,
I would like to join, I am UTC-8.
Thanks for organizing this!
- Stefano
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply
* Re: [dpdk-moving] Draft Project Charter
From: Matt Spencer @ 2016-11-08 18:18 UTC (permalink / raw)
To: O'Driscoll, Tim, Vincent JARDIN, moving@dpdk.org; +Cc: dev@dpdk.org
In-Reply-To: <26FA93C7ED1EAA44AB77D62FBE1D27BA6760E5AC@IRSMSX108.ger.corp.intel.com>
I think we need a discussion about the levels of membership - possibly at next weeks meeting?
My feeling is that we need more than one level
- One to enable contribution of hardware to the lab, as the lab will add cost to the overall project budget
- A second to enable contribution to the marketing aspects of the project and to allow association for marketing purposes
Calling these Gold and Silver is fine with me, but as I say, lets discuss this at next weeks meeting.
Matt
________________________________
From: moving <moving-bounces@dpdk.org> on behalf of O'Driscoll, Tim <tim.odriscoll@intel.com>
Sent: 08 November 2016 03:57:36
To: Vincent JARDIN; moving@dpdk.org
Cc: dev@dpdk.org
Subject: Re: [dpdk-moving] [dpdk-dev] Draft Project Charter
> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Vincent JARDIN
> Sent: Tuesday, November 8, 2016 11:41 AM
> To: moving@dpdk.org
> Cc: dev@dpdk.org
> Subject: Re: [dpdk-dev] [dpdk-moving] Draft Project Charter
>
> Tim,
>
> Thanks for your draft, but it is not a good proposal. It is not written
> in the spirit that we have discussed in Dublin:
> - you create the status of "Gold" members that we do not want from
> Linux Foundation,
As I said in the email, I put in two levels of membership as a placeholder. The first thing we need to decide is if we want to have a budget and membership, or if we want the OVS model with 0 budget and no membership. We can discuss that at today's meeting.
If we do want a membership model then we'll need to decide if everybody contributes at the same rate or if we support multiple levels. So, for now, the text on having two levels is just an example to show what a membership model might look like.
> - you start with "DPDK's first $1,000,000", it is far from the $O
> that we agreed based on OVS model.
That's just standard text that I see in all the LF charters. It's even in the OVS charter (http://openvswitch.org/charter/charter.pdf) even though they have 0 budget. I assumed it's standard text for the LF. I'm sure Mike Dolan can clarify.
>
> Please, explain why you did change it?
>
> Thank you,
> Vincent
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
^ permalink raw reply
* Re: [RFC v3 1/6] Track the active utilisation
From: Luca Abeni @ 2016-11-08 18:17 UTC (permalink / raw)
To: Juri Lelli
Cc: linux-kernel, Peter Zijlstra, Ingo Molnar, Claudio Scordino,
Steven Rostedt
In-Reply-To: <20161108175635.GF16920@e106622-lin>
Hi Juri,
On Tue, 8 Nov 2016 17:56:35 +0000
Juri Lelli <juri.lelli@arm.com> wrote:
[...]
> > > > static void switched_to_dl(struct rq *rq, struct task_struct
> > > > *p) {
> > > > + add_running_bw(&p->dl, &rq->dl);
> > > >
> > > > /* If p is not queued we will update its parameters at
> > > > next wakeup. */ if (!task_on_rq_queued(p))
> > >
> > > Don't we also need to remove bw in task_dead_dl()?
> > I think task_dead_dl() is invoked after invoking dequeue_task_dl(),
> > which takes care of this... Or am I wrong? (I think I explicitly
> > tested this, and modifications to task_dead_dl() turned out to be
> > unneeded)
> >
>
> Mmm. You explicitly check that TASK_ON_RQ_MIGRATING or DEQUEUE_SLEEP
> (which btw can be actually put together with an or condition), so I
> don't think that any of those turn out to be true when the task dies.
I might be very wrong here, but I think do_exit() just does something
like
tsk->state = TASK_DEAD;
and then invokes schedule(), and __schedule() does
if (!preempt && prev->state) {
if (unlikely(signal_pending_state(prev->state, prev))) {
prev->state = TASK_RUNNING;
} else {
deactivate_task(rq, prev, DEQUEUE_SLEEP);
[...]
so dequeue_task_dl() will see DEQUEUE_SLEEP... Or am I misunderstanding
what you are saying?
> Also, AFAIU, do_exit() works on current and the TASK_DEAD case is
> handled in finish_task_switch(), so I don't think we are taking care
> of the "task is dying" condition.
Ok, so I am missing something... The state is set to TASK_DEAD, and
then schedule() is called... So, __schedule() sees the dying task as
"prev" and invokes deactivate_task() with the DEQUEUE_SLEEP flag...
After that, finish_task_switch() calls task_dead_dl(). Is this wrong?
If not, why aren't we taking care of the "task is dying" condition?
> Peter, does what I'm saying make any sense? :)
>
> I still have to set up things here to test these patches (sorry, I was
> travelling), but could you try to create some tasks and that kill them
> from another shell to see if the accounting deviates or not? Or did
> you already do this test?
I think this is one of the tests I tried...
I have to check if I changed this code after the test (but I do not
think I did). Anyway, tomorrow I'll write a script for automating this
test, and I'll leave it running for some hours.
Luca
^ permalink raw reply
* [Qemu-devel] [PULL 0/1] Tracing patches
From: Stefan Hajnoczi @ 2016-11-08 18:17 UTC (permalink / raw)
To: qemu-devel; +Cc: Peter Maydell, Stefan Hajnoczi
The following changes since commit 207faf24c58859f5240f66bf6decc33b87a1776e:
Merge remote-tracking branch 'pm215/tags/pull-target-arm-20161107' into staging (2016-11-07 14:02:15 +0000)
are available in the git repository at:
git://github.com/stefanha/qemu.git tags/tracing-pull-request
for you to fetch changes up to 3b0fc80dd8ed9bd1ac738898e4fbd70c4a618925:
docs/tracing.txt: Update documentation of default backend (2016-11-08 18:16:48 +0000)
----------------------------------------------------------------
----------------------------------------------------------------
Peter Maydell (1):
docs/tracing.txt: Update documentation of default backend
docs/tracing.txt | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
--
2.7.4
^ permalink raw reply
* [Qemu-devel] [PULL 1/1] docs/tracing.txt: Update documentation of default backend
From: Stefan Hajnoczi @ 2016-11-08 18:17 UTC (permalink / raw)
To: qemu-devel; +Cc: Peter Maydell, Stefan Hajnoczi
In-Reply-To: <1478629053-31709-1-git-send-email-stefanha@redhat.com>
From: Peter Maydell <peter.maydell@linaro.org>
In commit baf86d6b3c we switched the default trace backend from "nop"
to "log". Update the documentation to match.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Message-id: 1478276837-31780-1-git-send-email-peter.maydell@linaro.org
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
---
docs/tracing.txt | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/docs/tracing.txt b/docs/tracing.txt
index e62444c..f351998a 100644
--- a/docs/tracing.txt
+++ b/docs/tracing.txt
@@ -150,13 +150,16 @@ The trace backends are chosen at configure time:
For a list of supported trace backends, try ./configure --help or see below.
If multiple backends are enabled, the trace is sent to them all.
+If no backends are explicitly selected, configure will default to the
+"log" backend.
+
The following subsections describe the supported trace backends.
=== Nop ===
The "nop" backend generates empty trace event functions so that the compiler
-can optimize out trace events completely. This is the default and imposes no
-performance penalty.
+can optimize out trace events completely. This imposes no performance
+penalty.
Note that regardless of the selected trace backend, events with the "disable"
property will be generated with the "nop" backend.
--
2.7.4
^ permalink raw reply related
* [Qemu-devel] [kvm-unit-tests PATCH v8 3/3] arm: pmu: Add CPI checking
From: Wei Huang @ 2016-11-08 18:17 UTC (permalink / raw)
To: cov
Cc: qemu-devel, kvm, kvmarm, shannon.zhao, alistair.francis, croberts,
alindsay, drjones
In-Reply-To: <1478629035-12938-1-git-send-email-wei@redhat.com>
From: Christopher Covington <cov@codeaurora.org>
Calculate the numbers of cycles per instruction (CPI) implied by ARM
PMU cycle counter values. The code includes a strict checking facility
intended for the -icount option in TCG mode in the configuration file.
Signed-off-by: Christopher Covington <cov@codeaurora.org>
Signed-off-by: Wei Huang <wei@redhat.com>
---
arm/pmu.c | 101 +++++++++++++++++++++++++++++++++++++++++++++++++++++-
arm/unittests.cfg | 14 ++++++++
2 files changed, 114 insertions(+), 1 deletion(-)
diff --git a/arm/pmu.c b/arm/pmu.c
index d5e3ac3..09aff89 100644
--- a/arm/pmu.c
+++ b/arm/pmu.c
@@ -15,6 +15,7 @@
#include "libcflat.h"
#define PMU_PMCR_E (1 << 0)
+#define PMU_PMCR_C (1 << 2)
#define PMU_PMCR_N_SHIFT 11
#define PMU_PMCR_N_MASK 0x1f
#define PMU_PMCR_ID_SHIFT 16
@@ -75,6 +76,23 @@ static inline void pmccfiltr_write(uint32_t value)
pmselr_write(PMU_CYCLE_IDX);
pmxevtyper_write(value);
}
+
+/*
+ * Extra instructions inserted by the compiler would be difficult to compensate
+ * for, so hand assemble everything between, and including, the PMCR accesses
+ * to start and stop counting.
+ */
+static inline void loop(int i, uint32_t pmcr)
+{
+ asm volatile(
+ " mcr p15, 0, %[pmcr], c9, c12, 0\n"
+ "1: subs %[i], %[i], #1\n"
+ " bgt 1b\n"
+ " mcr p15, 0, %[z], c9, c12, 0\n"
+ : [i] "+r" (i)
+ : [pmcr] "r" (pmcr), [z] "r" (0)
+ : "cc");
+}
#elif defined(__aarch64__)
static inline uint32_t pmcr_read(void)
{
@@ -106,6 +124,23 @@ static inline void pmccfiltr_write(uint32_t value)
{
asm volatile("msr pmccfiltr_el0, %0" : : "r" (value));
}
+
+/*
+ * Extra instructions inserted by the compiler would be difficult to compensate
+ * for, so hand assemble everything between, and including, the PMCR accesses
+ * to start and stop counting.
+ */
+static inline void loop(int i, uint32_t pmcr)
+{
+ asm volatile(
+ " msr pmcr_el0, %[pmcr]\n"
+ "1: subs %[i], %[i], #1\n"
+ " b.gt 1b\n"
+ " msr pmcr_el0, xzr\n"
+ : [i] "+r" (i)
+ : [pmcr] "r" (pmcr)
+ : "cc");
+}
#endif
/*
@@ -156,8 +191,71 @@ static bool check_cycles_increase(void)
return true;
}
-int main(void)
+/*
+ * Execute a known number of guest instructions. Only odd instruction counts
+ * greater than or equal to 3 are supported by the in-line assembly code. The
+ * control register (PMCR_EL0) is initialized with the provided value (allowing
+ * for example for the cycle counter or event counters to be reset). At the end
+ * of the exact instruction loop, zero is written to PMCR_EL0 to disable
+ * counting, allowing the cycle counter or event counters to be read at the
+ * leisure of the calling code.
+ */
+static void measure_instrs(int num, uint32_t pmcr)
+{
+ int i = (num - 1) / 2;
+
+ assert(num >= 3 && ((num - 1) % 2 == 0));
+ loop(i, pmcr);
+}
+
+/*
+ * Measure cycle counts for various known instruction counts. Ensure that the
+ * cycle counter progresses (similar to check_cycles_increase() but with more
+ * instructions and using reset and stop controls). If supplied a positive,
+ * nonzero CPI parameter, also strictly check that every measurement matches
+ * it. Strict CPI checking is used to test -icount mode.
+ */
+static bool check_cpi(int cpi)
+{
+ uint32_t pmcr = pmcr_read() | PMU_PMCR_C | PMU_PMCR_E;
+
+ if (cpi > 0)
+ printf("Checking for CPI=%d.\n", cpi);
+ printf("instrs : cycles0 cycles1 ...\n");
+
+ for (int i = 3; i < 300; i += 32) {
+ int avg, sum = 0;
+
+ printf("%d :", i);
+ for (int j = 0; j < NR_SAMPLES; j++) {
+ int cycles;
+
+ measure_instrs(i, pmcr);
+ cycles =pmccntr_read();
+ printf(" %d", cycles);
+
+ if (!cycles || (cpi > 0 && cycles != i * cpi)) {
+ printf("\n");
+ return false;
+ }
+
+ sum += cycles;
+ }
+ avg = sum / NR_SAMPLES;
+ printf(" sum=%d avg=%d avg_ipc=%d avg_cpi=%d\n",
+ sum, avg, i / avg, avg / i);
+ }
+
+ return true;
+}
+
+int main(int argc, char *argv[])
{
+ int cpi = 0;
+
+ if (argc >= 1)
+ cpi = atol(argv[0]);
+
report_prefix_push("pmu");
/* init for PMU event access, right now only care about cycle count */
@@ -166,6 +264,7 @@ int main(void)
report("Control register", check_pmcr());
report("Monotonically increasing cycle count", check_cycles_increase());
+ report("Cycle/instruction ratio", check_cpi(cpi));
return report_summary();
}
diff --git a/arm/unittests.cfg b/arm/unittests.cfg
index 7645180..2050dc8 100644
--- a/arm/unittests.cfg
+++ b/arm/unittests.cfg
@@ -59,3 +59,17 @@ groups = selftest
[pmu]
file = pmu.flat
groups = pmu
+
+# Test PMU support (TCG) with -icount IPC=1
+[pmu-tcg-icount-1]
+file = pmu.flat
+extra_params = -icount 0 -append '1'
+groups = pmu
+accel = tcg
+
+# Test PMU support (TCG) with -icount IPC=256
+[pmu-tcg-icount-256]
+file = pmu.flat
+extra_params = -icount 8 -append '256'
+groups = pmu
+accel = tcg
--
1.8.3.1
^ permalink raw reply related
* [Qemu-devel] [kvm-unit-tests PATCH v8 1/3] arm: Add PMU test
From: Wei Huang @ 2016-11-08 18:17 UTC (permalink / raw)
To: cov
Cc: qemu-devel, kvm, kvmarm, shannon.zhao, alistair.francis, croberts,
alindsay, drjones
In-Reply-To: <1478629035-12938-1-git-send-email-wei@redhat.com>
From: Christopher Covington <cov@codeaurora.org>
Beginning with a simple sanity check of the control register, add
a unit test for the ARM Performance Monitors Unit (PMU).
Signed-off-by: Christopher Covington <cov@codeaurora.org>
Signed-off-by: Wei Huang <wei@redhat.com>
---
arm/Makefile.common | 3 ++-
arm/pmu.c | 73 +++++++++++++++++++++++++++++++++++++++++++++++++++++
arm/unittests.cfg | 5 ++++
3 files changed, 80 insertions(+), 1 deletion(-)
create mode 100644 arm/pmu.c
diff --git a/arm/Makefile.common b/arm/Makefile.common
index ccb554d..f98f422 100644
--- a/arm/Makefile.common
+++ b/arm/Makefile.common
@@ -11,7 +11,8 @@ endif
tests-common = \
$(TEST_DIR)/selftest.flat \
- $(TEST_DIR)/spinlock-test.flat
+ $(TEST_DIR)/spinlock-test.flat \
+ $(TEST_DIR)/pmu.flat
all: test_cases
diff --git a/arm/pmu.c b/arm/pmu.c
new file mode 100644
index 0000000..0b29088
--- /dev/null
+++ b/arm/pmu.c
@@ -0,0 +1,73 @@
+/*
+ * Test the ARM Performance Monitors Unit (PMU).
+ *
+ * Copyright (c) 2015-2016, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU Lesser General Public License version 2.1 and
+ * only version 2.1 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU Lesser General Public License
+ * for more details.
+ */
+#include "libcflat.h"
+
+#define PMU_PMCR_N_SHIFT 11
+#define PMU_PMCR_N_MASK 0x1f
+#define PMU_PMCR_ID_SHIFT 16
+#define PMU_PMCR_ID_MASK 0xff
+#define PMU_PMCR_IMP_SHIFT 24
+#define PMU_PMCR_IMP_MASK 0xff
+
+#if defined(__arm__)
+static inline uint32_t pmcr_read(void)
+{
+ uint32_t ret;
+
+ asm volatile("mrc p15, 0, %0, c9, c12, 0" : "=r" (ret));
+ return ret;
+}
+#elif defined(__aarch64__)
+static inline uint32_t pmcr_read(void)
+{
+ uint32_t ret;
+
+ asm volatile("mrs %0, pmcr_el0" : "=r" (ret));
+ return ret;
+}
+#endif
+
+/*
+ * As a simple sanity check on the PMCR_EL0, ensure the implementer field isn't
+ * null. Also print out a couple other interesting fields for diagnostic
+ * purposes. For example, as of fall 2016, QEMU TCG mode doesn't implement
+ * event counters and therefore reports zero event counters, but hopefully
+ * support for at least the instructions event will be added in the future and
+ * the reported number of event counters will become nonzero.
+ */
+static bool check_pmcr(void)
+{
+ uint32_t pmcr;
+
+ pmcr = pmcr_read();
+
+ printf("PMU implementer: %c\n",
+ (pmcr >> PMU_PMCR_IMP_SHIFT) & PMU_PMCR_IMP_MASK);
+ printf("Identification code: 0x%x\n",
+ (pmcr >> PMU_PMCR_ID_SHIFT) & PMU_PMCR_ID_MASK);
+ printf("Event counters: %d\n",
+ (pmcr >> PMU_PMCR_N_SHIFT) & PMU_PMCR_N_MASK);
+
+ return ((pmcr >> PMU_PMCR_IMP_SHIFT) & PMU_PMCR_IMP_MASK) != 0;
+}
+
+int main(void)
+{
+ report_prefix_push("pmu");
+
+ report("Control register", check_pmcr());
+
+ return report_summary();
+}
diff --git a/arm/unittests.cfg b/arm/unittests.cfg
index 3f6fa45..7645180 100644
--- a/arm/unittests.cfg
+++ b/arm/unittests.cfg
@@ -54,3 +54,8 @@ file = selftest.flat
smp = $MAX_SMP
extra_params = -append 'smp'
groups = selftest
+
+# Test PMU support
+[pmu]
+file = pmu.flat
+groups = pmu
--
1.8.3.1
^ permalink raw reply related
* [Qemu-devel] [kvm-unit-tests PATCH v8 2/3] arm: pmu: Check cycle count increases
From: Wei Huang @ 2016-11-08 18:17 UTC (permalink / raw)
To: cov
Cc: qemu-devel, kvm, kvmarm, shannon.zhao, alistair.francis, croberts,
alindsay, drjones
In-Reply-To: <1478629035-12938-1-git-send-email-wei@redhat.com>
From: Christopher Covington <cov@codeaurora.org>
Ensure that reads of the PMCCNTR_EL0 are monotonically increasing,
even for the smallest delta of two subsequent reads.
Signed-off-by: Christopher Covington <cov@codeaurora.org>
Signed-off-by: Wei Huang <wei@redhat.com>
---
arm/pmu.c | 98 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 98 insertions(+)
diff --git a/arm/pmu.c b/arm/pmu.c
index 0b29088..d5e3ac3 100644
--- a/arm/pmu.c
+++ b/arm/pmu.c
@@ -14,6 +14,7 @@
*/
#include "libcflat.h"
+#define PMU_PMCR_E (1 << 0)
#define PMU_PMCR_N_SHIFT 11
#define PMU_PMCR_N_MASK 0x1f
#define PMU_PMCR_ID_SHIFT 16
@@ -21,6 +22,10 @@
#define PMU_PMCR_IMP_SHIFT 24
#define PMU_PMCR_IMP_MASK 0xff
+#define PMU_CYCLE_IDX 31
+
+#define NR_SAMPLES 10
+
#if defined(__arm__)
static inline uint32_t pmcr_read(void)
{
@@ -29,6 +34,47 @@ static inline uint32_t pmcr_read(void)
asm volatile("mrc p15, 0, %0, c9, c12, 0" : "=r" (ret));
return ret;
}
+
+static inline void pmcr_write(uint32_t value)
+{
+ asm volatile("mcr p15, 0, %0, c9, c12, 0" : : "r" (value));
+}
+
+static inline void pmselr_write(uint32_t value)
+{
+ asm volatile("mcr p15, 0, %0, c9, c12, 5" : : "r" (value));
+}
+
+static inline void pmxevtyper_write(uint32_t value)
+{
+ asm volatile("mcr p15, 0, %0, c9, c13, 1" : : "r" (value));
+}
+
+/*
+ * While PMCCNTR can be accessed as a 64 bit coprocessor register, returning 64
+ * bits doesn't seem worth the trouble when differential usage of the result is
+ * expected (with differences that can easily fit in 32 bits). So just return
+ * the lower 32 bits of the cycle count in AArch32.
+ */
+static inline uint32_t pmccntr_read(void)
+{
+ uint32_t cycles;
+
+ asm volatile("mrc p15, 0, %0, c9, c13, 0" : "=r" (cycles));
+ return cycles;
+}
+
+static inline void pmcntenset_write(uint32_t value)
+{
+ asm volatile("mcr p15, 0, %0, c9, c12, 1" : : "r" (value));
+}
+
+/* PMCCFILTR is an obsolete name for PMXEVTYPER31 in ARMv7 */
+static inline void pmccfiltr_write(uint32_t value)
+{
+ pmselr_write(PMU_CYCLE_IDX);
+ pmxevtyper_write(value);
+}
#elif defined(__aarch64__)
static inline uint32_t pmcr_read(void)
{
@@ -37,6 +83,29 @@ static inline uint32_t pmcr_read(void)
asm volatile("mrs %0, pmcr_el0" : "=r" (ret));
return ret;
}
+
+static inline void pmcr_write(uint32_t value)
+{
+ asm volatile("msr pmcr_el0, %0" : : "r" (value));
+}
+
+static inline uint32_t pmccntr_read(void)
+{
+ uint32_t cycles;
+
+ asm volatile("mrs %0, pmccntr_el0" : "=r" (cycles));
+ return cycles;
+}
+
+static inline void pmcntenset_write(uint32_t value)
+{
+ asm volatile("msr pmcntenset_el0, %0" : : "r" (value));
+}
+
+static inline void pmccfiltr_write(uint32_t value)
+{
+ asm volatile("msr pmccfiltr_el0, %0" : : "r" (value));
+}
#endif
/*
@@ -63,11 +132,40 @@ static bool check_pmcr(void)
return ((pmcr >> PMU_PMCR_IMP_SHIFT) & PMU_PMCR_IMP_MASK) != 0;
}
+/*
+ * Ensure that the cycle counter progresses between back-to-back reads.
+ */
+static bool check_cycles_increase(void)
+{
+ pmcr_write(pmcr_read() | PMU_PMCR_E);
+
+ for (int i = 0; i < NR_SAMPLES; i++) {
+ unsigned long a, b;
+
+ a = pmccntr_read();
+ b = pmccntr_read();
+
+ if (a >= b) {
+ printf("Read %ld then %ld.\n", a, b);
+ return false;
+ }
+ }
+
+ pmcr_write(pmcr_read() & ~PMU_PMCR_E);
+
+ return true;
+}
+
int main(void)
{
report_prefix_push("pmu");
+ /* init for PMU event access, right now only care about cycle count */
+ pmcntenset_write(1 << PMU_CYCLE_IDX);
+ pmccfiltr_write(0); /* count cycles in EL0, EL1, but not EL2 */
+
report("Control register", check_pmcr());
+ report("Monotonically increasing cycle count", check_cycles_increase());
return report_summary();
}
--
1.8.3.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.