The new MSR PMU driver made use of rdtsc() which does not exist (yet) in
this tree:
arch/x86/kernel/cpu/perf_event_msr.c:91:3: error: implicit declaration of function 'rdtsc'
Use the old rdtscll() primitive for now.
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Enable the GK20A GPU (via the Nouveau driver) and CPU frequency scaling
on Tegra124.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAABCAAGBQJVzfssAAoJEN0jrNd/PrOh1CsQAKsOxJ9vt6rxIbTi3qhOVQku
+MwcX7uPImV8BCr2bCQLIm/pKGG052pjqwQ9oV9YF6t8McGJWwguwpZu6Eb5lUP9
qNNYcXqkL7ZdiDxCzSBx5kshYLmRLdYHPtJkkWvya3FgHzub/Kuv+b9QO4OHBV/D
7piftcSghj2WGxHnjZHK68El5JqrlqEVe5C/MqoPowC30x5w65XVIDhqsYZwl8tX
FvskW/lWgvcRe11/rD/isicN0xOSeNUDEdBnwCUVCetWibZRMXv/YQBE8URfRVOs
36BiLpi8N/NzpXX68rbl3TL9cye0GwlYXV8xk7GlKtUtg6d19wcVClih3ZK5RJCU
u42U3b+KA8xceJZIIF6qp9/G7oPJIEGb2bBMPm0OxboliN8A9/LmYJI1DGFR06gn
lZN+Rv6s91nDqW4GmEirz179zukDvGbvJfUos92Os7TMxZx0fXK7Dx7rfFlfWQlc
08hBaP769yrX62iVh785f/YA3rCq0127ZdA42lTKl3Wdg9y9wQ1IC5w04j9ROrh/
AREl9tZqL2wgdqAy0aOutkdzUaaymcuL9rMMdXOYz+lGFa5MlnKXZBUumYwo1gWd
DxxOPCfCL8QqXhLNjDj2HpcI+OC6KQsRvTP63dVDSvGphljOtxBlayKOipkn7TK1
iB5BnvZuGKZ+kBrCY81j
=xW1n
-----END PGP SIGNATURE-----
Merge tag 'tegra-for-4.3-defconfig' of git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux into next/defconfig
ARM: tegra: Default configuration updates for v4.3-rc1
Enable the GK20A GPU (via the Nouveau driver) and CPU frequency scaling
on Tegra124.
* tag 'tegra-for-4.3-defconfig' of git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux:
ARM: tegra: Update multi_v7_defconfig
ARM: tegra: Update default configuration
Signed-off-by: Olof Johansson <olof@lixom.net>
This contains a bit more of Tegra210 support, which is shaping up pretty
nicely. Other than that there are a couple of cleanup patches here, too.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAABCAAGBQJVzfFHAAoJEN0jrNd/PrOhvF0QAK6TZ/mSuK5sWsF2LWY/yCk1
sbS5NpOkP0Js+39CZFfRJXOeAlopyeA8UEAnmobyUIprYQWoK0iE4y0q+Iy6nn72
tZdsZlz87dUM/CYjT+AyPK7aUILB1s3dLjul+Lua5mAhUCwju+HHdHgm6OI5c/GN
4W5T3ysfF7aDy+o8a85YLPaPwhP36yTy6x3cx9lLvmFIKVgwWIn+cuOJOpaziy3W
frh7v26Vjl5Ja8Ml1LZd5TQhWJBzsSAIr81PJnk8nNliKspASw6a+hWvTkd2vMll
4qN9sekg55xeGk9lDJeesOmc2dmE4m1r0kg1aVcnpno/oy1k3VicHXfrI/AoN96w
cwRPHwAny9V5wW9vR5WojyGEuGojr/tbHVPGVMAhv+nw1Vod2A9iO5yNJyOs5a96
G6+YZNWwKJRecvQu+3SbhKKjSJoe66Ac36qTlTYjCiwVdcBceBMiqHl4sEslxLd9
pzrI6xjBlyqBcxdBeunKi6CoSeXRVv8HqO7lKLSBDMeMJQD3utYBhGgR59B0sI6P
sSyzPmPpv91YuXXJ2xhtRkFmBrW3KmN9ot8JgsfmzCxgef3zUa6vxOVrSGIbmWGB
qzB4V0X8GOVoZNejFLx+LGLHXeW6wdOJ3n6vqvZjaFTTeYz9kDm9Y3EUBXxX6hzs
ULBUWV18Nh/YDUIZIaV8
=xo46
-----END PGP SIGNATURE-----
Merge tag 'tegra-for-4.3-soc' of git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux into next/drivers
ARM: tegra: Core SoC changes for v4.3-rc1
This contains a bit more of Tegra210 support, which is shaping up pretty
nicely. Other than that there are a couple of cleanup patches here, too.
* tag 'tegra-for-4.3-soc' of git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux:
ARM: tegra: cpuidle: implement cpuidle_state.enter_freeze()
ARM: tegra: Disable cpuidle if PSCI is available
soc/tegra: pmc: Use existing pclk reference
soc/tegra: pmc: Remove unnecessary return statement
soc: tegra: Remove redundant $(CONFIG_ARCH_TEGRA) in Makefile
soc/tegra: fuse: Add spare bit offset for Tegra210
soc/tegra: fuse: Add spare bit offset for Tegra124
soc/tegra: fuse: Add spare bit offset for Tegra114
soc/tegra: fuse: Rename core_* to soc_*
soc/tegra: fuse: Add Tegra210 support
soc/tegra: fuse: Unify Tegra20 and Tegra30 drivers
soc/tegra: fuse: Restrict legacy code to 32-bit ARM
soc/tegra: pmc: Add Tegra210 support
soc/tegra: pmc: Restrict legacy code to 32-bit ARM
soc/tegra: pmc: Avoid usage of uninitialized variable
soc/tegra: Add Tegra210 support
soc/tegra: Add Tegra132 support
Signed-off-by: Olof Johansson <olof@lixom.net>
- for exynos_defconfig
: enable SND_SOC_ODROIDX2 and SND_SIMPLE_CARD for
Odroid-XU3 to use max98090 audio codec
: enalbe SENSORS_NTC_THERMISTOR for Peach boards
: enable cpufreq-dt driver with ONDEMAND governor
for Exynos SoCs 3250, 4210, 4212, 4412 and 5250
- for multi_v7_defconfig:
: remove SAMSUNG_USB2PHY and SAMSUNG_USB3PHY are not used now
: enable SENSORS_NTC_THERMISTOR and EXYNOS_ADC for Peach boards
: enable REGULATOR_MAX77802 for Peach boards
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQIcBAABAgAGBQJVzOCKAAoJEA0Cl+kVi2xqf6sQAIYMjcKFNT1g4MrJVflGLTnx
06OZ5mLGmXn6xMf8mlFWRGs7mDZs1E6uVAM64zRbnXoQEQpi5UkwEX44/8ViywLJ
9vOVMXdzdhnaH1eOUsfF6Ny+IWQAfEViXufEOZzU0UPHFHSwV2Mu/I0aj864Xhpa
AzrNgRhXJS9NphB0iXIZGdRtH5T0kydfIe1myuGiW5Ts0oEQDTncLF0J64kjDd3F
sFwwIN7bAW+JK9ovyZY6w68WNfpAc/csvhC8ieBwviS2Oy0LT23u3EROYxYrfZOX
ZoxvjkfRZLpCbjwC//LIzt8nrffEzjrZgN2SZb1hhDaH4d9z18KUH5iew/Nqphjf
bj4ydt52WfMnEWG5l5+SsMHJ7sbBQUxcxfCVoEqmfSkmZZS5rSuY9kcAkRDk6iQ5
zprHwbvvnJKz8QiLYYalcMLKxVuaMnQXwLM5bfvGf7QYOKJgpLJEvHpM/bQbgQa4
IuviiSVUhCoMt2zyhT2/5bins0HBchZma+7Zr5NSMcvGNVb0UqGNobPkEmZZ2DVX
7nnMMmxnGE9DNRKtDlhrF+8XLla4RxeSH15GLPUQJ95lWx6nvlNvV6oxZvx7XTpl
6t3XuoPFqmeopu9htSFnEwVVmtcKenlVLcwaM2SgoLrcq8BWJ8LZm3dfYg1uCHKK
z1i7krNCGgHn2EUX7G+2
=0McP
-----END PGP SIGNATURE-----
Merge tag 'samsung-defconfig-new' of git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung into next/late
Samsung defconfig updates for v4.3
- for exynos_defconfig
: enable SND_SOC_ODROIDX2 and SND_SIMPLE_CARD for
Odroid-XU3 to use max98090 audio codec
: enalbe SENSORS_NTC_THERMISTOR for Peach boards
: enable cpufreq-dt driver with ONDEMAND governor
for Exynos SoCs 3250, 4210, 4212, 4412 and 5250
- for multi_v7_defconfig:
: remove SAMSUNG_USB2PHY and SAMSUNG_USB3PHY are not used now
: enable SENSORS_NTC_THERMISTOR and EXYNOS_ADC for Peach boards
: enable REGULATOR_MAX77802 for Peach boards
* tag 'samsung-defconfig-new' of git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung:
ARM: exynos_defconfig: Enable cpufreq-dt driver
ARM: multi_v7_defconfig: Enable max77802 regulator
ARM: exynos_defconfig: Enable NTC Thermistors support
ARM: multi_v7_defconfig: Enable NTC Thermistors support
ARM: multi_v7_defconfig: Remove old Samsung USB PHY configs
ARM: exynos_defconfig: Enable CONFIG_SND_SOC_ODROIDX2 for Odroid-XU3
Signed-off-by: Olof Johansson <olof@lixom.net>
- add compatible string to exynos_cpufreq_matchs to switch for
supporting generic cpufreq driver for exynos3250, 4210, 4212
and 5250 SoCs in mach-exynos/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQIcBAABAgAGBQJVzN/vAAoJEA0Cl+kVi2xqTzYP/1RNCO8Ph9f77fp44fcYypYF
echISQs18c5Gnm9U8AzBHr4S72ddNHUGInMQElGAkQoNbycCAO+i1ROBlTcpPEbt
zJY+U5bJXGu6MYbYajVBI738qWbRv2ftxWwQalxB+tZO8Iige0uBv6upRTu1dIwF
qb8wO0gY2t9wMlqymp2N5KjiNQIdMRrNTlDf4vVzqPMF1fZvUKNwnW5Pt7bE2bgv
NywX1RwK9RC+W43F+cHt1eczVH8r2HHlpaHzqfkh1PdzTMFNxBEOFVEC6dc25isT
XoLf/UITHSDXp9xMd5IFZtUNPLwBtmEZAPR6qx15sHI6Xu5dx1GCxUbkpP+F4Wzw
jlU2RG8/dsaSy0uJ6j+TLscno3g4SUpuQaPNJYngxDr531GACwy4JHl7jy2AJXg/
61Z8V82VOaEX5gEKg1AsYyM35ncUO/ZS84a9Dk7+h4kFCYaSg7JTGpaqjBf23lQl
SLAao/B2xrFX3Vlhsf+u2KaHK07V4O8iQsJkVPQ10xfHSxSzeAl943EfMWXCKZxm
ml3VPfDl/HurdBakBGTABZ7dgfZGqLX/kjBEe7g5gSZXwoek4KYu5wgJM4MkhgDU
BvzayuFNcKhV4LpUKRkrvEJPJgxRGNZswRdweGgd/tXWDGFeI5O/Q094yCAOx141
IRCXWBdKruIp8eukRV/u
=XGyP
-----END PGP SIGNATURE-----
Merge tag 'samsung-soc' of git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung into next/late
Samsung SoC updates for v4.3
- add compatible string to exynos_cpufreq_matchs to switch for
supporting generic cpufreq driver for exynos3250, 4210, 4212
and 5250 SoCs in mach-exynos/
* tag 'samsung-soc' of git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung:
ARM: EXYNOS: switch to using generic cpufreq driver for exynos4x12
ARM: EXYNOS: Add exynos3250 compatible to use generic cpufreq driver
ARM: EXYNOS: switch to using generic cpufreq driver for exynos5250
Signed-off-by: Olof Johansson <olof@lixom.net>
- for exynos3250, 4212, 4412 and 5250
: add CPU OPP and regulator supply property
- for exynos3250
: add CPU cooling binding for exynos3250 boards
- for exynos4 SoCs
: add iommu property to JPEG device
- for exynos4412-odroidu3
: enable SPI1
- for exynos5250-snow
: add SPI CS
- for exynos5422
: add exynos5422-cpus.dtsi to correct cpu order
* Note this branch is depending on tags/samsung-clk-driver
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQIcBAABAgAGBQJVzN+JAAoJEA0Cl+kVi2xqQ0wQAJFjixPF33+E3O03cjqBc/xo
NZWAn8WParahqXIUfv+Kaz7Gq3eDwqp1NtOnxoouKerkf+82duoU24vQtfUMMLrI
m57CMQMMiSOPFIxlE1f5ZI40Izg3MuNLWq5UsNXVwiFWOFtxTEoCUX0EomqTeMND
tPNTTMO2RNIOef3iKYfr3R1XJCDcIlf6ccYcE/Yl4spSJzwANBsNrlLBF6LMhKPz
tLEQC99YZepHIixcWZox8SjUpzBEn+WevyRMDug8wkDnaEAq/TjfgT15RehKRYVH
+xx1dDNuQB2cfjxx7CRHZa4l1lgqX3T4N3V141ghCZDksBByrvSJ+hEUWQ6a8z+1
w0ISrNHdRxY9GoF4mdfAhc4tohEkU/Wwc8G5l4p8E+LZGY5YO0zfjG1wYoU6YLZ6
/MBX+mU19EP8yIqgFRACesa0cX6lTiX/2lcOCF4Sa9SiIlLAcGJ8tymkvD/UEEP+
HupOQN6bANRRbYh9jBf6fEvdh+HGhnLU4sNyvzJ5IhvYe61K0/naHtL1I2jBC+PH
OSQr0UsZ16wVQ1Zq8iDqTeKbCMWyJGTCwELRApEolLIKowZz0Spmcth6ehEaAJv+
zPxotpJ7eMz5O3YJQcRhz4e1b+EnXkicsszRNWAudiwJmrDjMXIhs0Sq7mxcDN90
ynICl1mQVWRFDbxNcKcG
=MKr+
-----END PGP SIGNATURE-----
Merge tag 'samsung-late-dt' of git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung into next/late
Samsung 2nd DT updates for v4.3
- for exynos3250, 4212, 4412 and 5250
: add CPU OPP and regulator supply property
- for exynos3250
: add CPU cooling binding for exynos3250 boards
- for exynos4 SoCs
: add iommu property to JPEG device
- for exynos4412-odroidu3
: enable SPI1
- for exynos5250-snow
: add SPI CS
- for exynos5422
: add exynos5422-cpus.dtsi to correct cpu order
* Note this branch is depending on tags/samsung-clk-driver
* tag 'samsung-late-dt' of git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung: (22 commits)
ARM: dts: add iommu property to JPEG device for exynos4
ARM: dts: enable SPI1 for exynos4412-odroidu3
ARM: dts: Add SPI CS on exynos5250-snow
ARM: dts: Add CPU cooling binding for exynos3250 boards
ARM: dts: add exynos5422-cpus.dtsi to correct cpu order
ARM: dts: add CPU OPP and regulator supply property for exynos4x12
ARM: dts: Add CPU OPP and regulator supply property for exynos3250
ARM: dts: add CPU OPP and regulator supply property for exynos5250
ARM: dts: Extend exynos5420-pinctrl nodes using labels instead of paths
ARM: dts: Include exynos5420-pinctrl after the nodes were defined for exynos5420
ARM: dts: Extend exynos5250-pinctrl nodes using labels instead of paths
ARM: dts: Include exynos5250-pinctrl after the nodes were defined for exynos5250
ARM: dts: Enable thermal-zones for exynos5422-odroidxu3
ARM: dts: Define default thermal-zones for exynos5422
ARM: dts: Enable TMU for exynos5422-odroidxu3
ARM: dts: Add pwm-fan node for exynos5422-odroidxu3
ARM: dts: Use labels for overriding nodes for exynos4210-universal_c210
ARM: dts: Set max17047 over heat and voltage thresholds for exynos4412-trats2
ARM: dts: Enable USB3 regulators for exynos5422-odroidxu3
ARM: dts: Clean up indentation for exynos5410-smdk5410
...
Signed-off-by: Olof Johansson <olof@lixom.net>
- moved the DT reset binding includes from
include/dt-bindings/reset-controller to include/dt-bindings/reset
- new driver for LPC18xx Reset Generation Unit (RGU)
- of_device_id array in the STi driver changed to const.
- extend SoCFPGA reset driver to support Arria10
- new ath79 reset controller driver for AR71XX/AR9XXX
- new driver for Xilinx Zynq reset controller
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJV0Km0AAoJEFDCiBxwnmDrOUgQAMkd/AF+Kl2cLpU0am/7yDZE
eO4UgnlQ50L3+bXjOdgX0Ge24S6yQRpe66Nj1vpK0lfxzPM+K2/sTfXso0iAhtGd
7OqapeQv+/hlBq2mmPT1smEbDucOFffFmQAq9sV3PbAYgGRn2CD8GYvSoS//0EMm
39KbocTEsuZErf0hmNlhtIwa6vg+Q9H1eWN0A3CZrGOy3zMMGEypyKOyJznIpBZv
HccpVN4y3D3BTf2HIWa5p9dHueWv5BdmudM2IypO3EVXOULhu4Jzqt1Fizu9F+yR
jvxbB96W8gNDRT5c49vFshkVWfNJAkYnKcXISjWUb0bM9V1l5V62R8f4OJWj24rh
GXgT8spdqjze38YYT8VQx7SWXjm6H2aMnrYNMLQsHunJbEbboqCb/JHTTCOrzMSZ
FgHWCp0uodNYo/VGWx8GgMKPwrfYpY8iMtm16WSucPZA/ppx21oD8VLzIY1Bd0CW
JM5oHG4uYB90EFxQS5XJoAxa9HbIlV6UbHdt44bVPcaQGw9ID+j978Djsjalqqf7
uhA+8wVYGcopOcUWJ8ISsMerQqCiJfMwczhwDh0yEd9NshGv76NbycgsVP/4De6f
c8xCEkuADYtWPtaQQakU+l8TfctmrsakNmD5DbkUgoLut+FnkfN1cmHHGnFlI36d
DTaKtOAddWkrWebdpXW1
=GBec
-----END PGP SIGNATURE-----
Merge tag 'reset-for-4.3' of git://git.pengutronix.de/git/pza/linux into next/drivers
Reset controller changes for v4.3
- moved the DT reset binding includes from
include/dt-bindings/reset-controller to include/dt-bindings/reset
- new driver for LPC18xx Reset Generation Unit (RGU)
- of_device_id array in the STi driver changed to const.
- extend SoCFPGA reset driver to support Arria10
- new ath79 reset controller driver for AR71XX/AR9XXX
- new driver for Xilinx Zynq reset controller
* tag 'reset-for-4.3' of git://git.pengutronix.de/git/pza/linux:
reset: reset-zynq: Adding support for Xilinx Zynq reset controller.
docs: dts: Added documentation for Xilinx Zynq Reset Controller bindings.
MIPS: ath79: Add the reset controller to the AR9132 dtsi
reset: Add a driver for the reset controller on the AR71XX/AR9XXX
devicetree: Add bindings for the ATH79 reset controller
reset: socfpga: Update reset-socfpga to read the altr,modrst-offset property
doc: dt: add documentation for lpc1850-rgu reset driver
reset: add driver for lpc18xx rgu
reset: sti: constify of_device_id array
ARM: STi: DT: Move reset controller constants into common location
MAINTAINERS: add include/dt-bindings/reset path to reset controller entry
Signed-off-by: Olof Johansson <olof@lixom.net>
This SoC is integrated with 4 Cortex-A9 cores. The GIC bindings
document says that the bits[15:8] of the 3rd cell of the interrupts
property represents PPI interrupt CPU mask. Because the timer
interrupts are wired to all of the 4 cores, bits[15:8] should be set
to 0xf.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Olof Johansson <olof@lixom.net>
When getting translated from a downstream device tree that used slightly
different DT bindings, these regulators got labeled with the
"on-in-suspend" state, when they were actually supposed to be turned off
for S3 suspend. This was harmless, but not intentional, AFAICT.
Let's turn them off to get the optimal power state.
Signed-off-by: Brian Norris <briannorris@chromium.org>
Reviewed-by: Javier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
This DTS file was submitted with non-upstream bindings. I happened
across this while reviewing the jaq DTS.
Signed-off-by: Brian Norris <briannorris@chromium.org>
Reviewed-by: Javier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Commit b253149b84 ("sched/idle/x86: Restore mwait_idle() to fix boot
hangs, to improve power savings and to improve performance") restores
mwait_idle(), but the trace_cpu_idle related calls are missing. This
causes powertop on my old desktop powered by Intel Core2 E6550 to
report zero wakeups and zero events.
Add them back to restore the proper behaviour.
Fixes: b253149b84 ("sched/idle/x86: Restore mwait_idle() to ...")
Signed-off-by: Jisheng Zhang <jszhang@marvell.com>
Cc: <len.brown@intel.com>
Cc: stable@vger.kernel.org # 4.1
Link: http://lkml.kernel.org/r/1440046479-4262-1-git-send-email-jszhang@marvell.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Add comments to the cachemode translation tables to clarify that
the default values are set as minimal supported mode, which are
necessary to handle WC and WT fallback to UC- when they are not
enabled.
Signed-off-by: Toshi Kani <toshi.kani@hp.com>
Cc: Jan Beulich <jbeulich@suse.com>
Cc: Borislav Petkov <bp@suse.de>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/1437588371-28223-1-git-send-email-toshi.kani@hp.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
- Fix i386 build with an (uncommon) configuration
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAABAgAGBQJV1bZtAAoJEFxbo/MsZsTR3sYH/2Q+wabqeFZotSZsJjYjSh+q
6hCRB/tD+LbmReYuFBsqStHUDEL0Ljh9kw6YQvUrEVLv6CIH/pCVhj2U+/INlUur
aScKQe1ttKaMzEAB2opLQnYMw5Q/C/pHAtq88MYMWnYBb9fM/puMyI0iXu8FhoOP
+QYdaDt7+hRfID3PWZ7JxLGu+AqVgis5OAh/rt/Y4aC/WaNF7ifrE4qIJlgaR9x4
IDglRBc4cPhLjwb2yhykiRHREhydVvRqEPsgji20T7pXVduj5DEqqVpU1XMqKBNU
0EmZ5wLnELvWxPWv3zCScAtvmH30+i4QQcGB/3igJCeYN0gBxzeoGbTKWf4P0HM=
=lRue
-----END PGP SIGNATURE-----
Merge tag 'for-linus-4.2-rc7-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip
Pull xen build fix from David Vrabel:
"Fix i386 build with an (uncommon) configuration"
* tag 'for-linus-4.2-rc7-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip:
x86/xen: make CONFIG_XEN depend on CONFIG_X86_LOCAL_APIC
Update the annotation for the kaddr pointer returned by direct_access()
so that it is a __pmem pointer. This is consistent with the PMEM driver
and with how this direct_access() pointer is used in the DAX code.
Signed-off-by: Ross Zwisler <ross.zwisler@linux.intel.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Add support for two new PMEM APIs, copy_from_iter_pmem() and
clear_pmem(). copy_from_iter_pmem() is used to copy data from an
iterator into a PMEM buffer. clear_pmem() zeros a PMEM memory range.
Both of these new APIs must be explicitly ordered using a wmb_pmem()
function call and are implemented in such a way that the wmb_pmem()
will make the stores to PMEM durable. Because both APIs are unordered
they can be called as needed without introducing any unwanted memory
barriers.
Signed-off-by: Ross Zwisler <ross.zwisler@linux.intel.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Prior to this change x86_64 used the pmem defines in
arch/x86/include/asm/pmem.h, and UM used the default ones at the
top of include/linux/pmem.h. The inclusion or exclusion in linux/pmem.h
was controlled by CONFIG_ARCH_HAS_PMEM_API, but the ones in asm/pmem.h
were controlled by ARCH_HAS_NOCACHE_UACCESS.
Instead, control them both with CONFIG_ARCH_HAS_PMEM_API so that it's
clear that they are related and we don't run into the possibility where
they are both included or excluded. Also remove a bunch of stale
function prototypes meant for UM in asm/pmem.h - these just conflicted
with the inline defaults in linux/pmem.h and gave compile errors.
Signed-off-by: Ross Zwisler <ross.zwisler@linux.intel.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Prior to this change arch_has_wmb_pmem() was only called by
arch_has_pmem_api(). Both arch_has_wmb_pmem() and arch_has_pmem_api()
checked to make sure that CONFIG_ARCH_HAS_PMEM_API was enabled.
Instead, remove the old arch_has_wmb_pmem() wrapper to be rid of one
extra layer of indirection and the redundant CONFIG_ARCH_HAS_PMEM_API
check. Rename __arch_has_wmb_pmem() to arch_has_wmb_pmem() since we no
longer have a wrapper, and just have arch_has_pmem_api() call the
architecture specific arch_has_wmb_pmem() directly.
Signed-off-by: Ross Zwisler <ross.zwisler@linux.intel.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Move the x86 PMEM API implementation out of asm/cacheflush.h and into
its own header asm/pmem.h. This will allow members of the PMEM API to
be more easily identified on this and other architectures.
Signed-off-by: Ross Zwisler <ross.zwisler@linux.intel.com>
Suggested-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
ARM now uses pci_bus->msi to store the msi_controller pointer, so we don't
need to save it in struct pci_sys_data, and we don't need to implement
pcibios_msi_controller() to get it out of pci_sys_data.
Remove msi_controller from struct pci_sys_data and
pcibios_msi_controller().
[bhelgaas: changelog, split into separate patch]
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Jingoo Han <jingoohan1@gmail.com>
ARM previously stored the msi_controller pointer in its sysdata, struct
pci_sys_data, and implemented pcibios_msi_controller() to retrieve it.
That made PCI host controller drivers specific to ARM because they had to
put the msi_controller pointer in the ARM-specific pci_sys_data.
There is now a generic mechanism, pci_scan_root_bus_msi(), for giving the
msi_controller pointer to the PCI core. Use this for all ARM systems and
for the DesignWare and Xilinx PCI host controller drivers.
This removes an ARM dependency from the DesignWare, DRA7xx, EXYNOS, i.MX6,
Keystone, Layerscape, SPEAr13xx, and Xilinx drivers.
[bhelgaas: changelog, split into separate patch]
Suggested-by: Russell King <linux@arm.linux.org.uk>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Jingoo Han <jingoohan1@gmail.com>
CC: Pratyush Anand <pratyush.anand@gmail.com>
CC: Arnd Bergmann <arnd@arndb.de>
CC: Simon Horman <horms@verge.net.au>
CC: Russell King <linux@arm.linux.org.uk>
CC: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
CC: Thierry Reding <thierry.reding@gmail.com>
CC: Michal Simek <michal.simek@xilinx.com>
CC: Marc Zyngier <marc.zyngier@arm.com>
In the ARM PCI bios32 layer, failures to dynamically allocate pci_sys_data
for a PCI bus, or a PCI bus scan failure have to be considered serious
warnings but they should not trigger a system panic so that at least the
system is given a chance to be debugged.
This patch replaces the panic statements with WARN() messages to improve
error reporting in the ARM PCI bios32 layer.
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Jingoo Han <jingoohan1@gmail.com>
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
CC: Russell King <linux@arm.linux.org.uk>
CC: Marc Zyngier <marc.zyngier@arm.com>
Current sed script makes assumptions about the structure of rules that
group .text sections in the vmlinux linker script. These assumptions
get broken occasionally, e.g.: 779c88c94c "ARM: 8321/1: asm-generic:
introduce.text.fixup input section", or 9bebe9e5b0 "kbuild: Fix
.text.unlikely placement".
Rewrite sed rules so that they don't depend on number/arrangement of text
sections in *(...) blocks.
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
We don't want to expose the DCC to userspace, particularly as there is
a kernel console driver for it.
This patch resets mdscr_el1 to disable userspace access to the DCC
registers on the cold boot path.
Signed-off-by: Will Deacon <will.deacon@arm.com>
When kernel's binary becomes large enough (32M and more) errors
may occur during the final linkage stage. It happens because
the build system uses short relocations for ARC by default.
This problem may be easily resolved by passing -mlong-calls
option to GCC to use long absolute jumps (j) instead of short
relative branchs (b).
But there are fragments of pure assembler code exist which use
branchs in inappropriate places and cause a linkage error because
of relocations overflow.
First of these fragments is .fixup insertion in futex.h and
unaligned.c. It inserts a code in the separate section (.fixup)
with branch instruction. It leads to the linkage error when
kernel becomes large.
Second of these fragments is calling scheduler's functions
(common kernel code) from entry.S of ARC's code. When kernel's
binary becomes large it may lead to the linkage error because
scheduler may occur far enough from ARC's code in the final
binary.
Signed-off-by: Yuriy Kolerov <yuriy.kolerov@synopsys.com>
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
W/o hardware assisted atomic r-m-w the best we can do is to disable
preemption.
Cc: David Hildenbrand <dahi@linux.vnet.ibm.com>
Cc: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Michel Lespinasse <walken@google.com>
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
ARC doesn't need the runtime detection of futex cmpxchg op
Cc: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
Callers of cmpxchg_futex_value_locked() in futex code expect bimodal
return value:
!0 (essentially -EFAULT as failure)
0 (success)
Before this patch, the success return value was old value of futex,
which could very well be non zero, causing caller to possibly take the
failure path erroneously.
Fix that by returning 0 for success
(This fix was done back in 2011 for all upstream arches, which ARC
obviously missed)
Cc: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Michel Lespinasse <walken@google.com>
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
The atomic ops on futex need to provide the full barrier just like
regular atomics in kernel.
Also remove pagefault_enable/disable in futex_atomic_cmpxchg_inatomic()
as core code already does that
Cc: David Hildenbrand <dahi@linux.vnet.ibm.com>
Cc: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Michel Lespinasse <walken@google.com>
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
In case of ARCv2 CPU there're could be following configurations
that affect cache handling for data exchanged with peripherals
via DMA:
[1] Only L1 cache exists
[2] Both L1 and L2 exist, but no IO coherency unit
[3] L1, L2 caches and IO coherency unit exist
Current implementation takes care of [1] and [2].
Moreover support of [2] is implemented with run-time check
for SLC existence which is not super optimal.
This patch introduces support of [3] and rework of DMA ops
usage. Instead of doing run-time check every time a particular
DMA op is executed we'll have 3 different implementations of
DMA ops and select appropriate one during init.
As for IOC support for it we need:
[a] Implement empty DMA ops because IOC takes care of cache
coherency with DMAed data
[b] Route dma_alloc_coherent() via dma_alloc_noncoherent()
This is required to make IOC work in first place and also
serves as optimization as LD/ST to coherent buffers can be
srviced from caches w/o going all the way to memory
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
[vgupta:
-Added some comments about IOC gains
-Marked dma ops as static,
-Massaged changelog a bit]
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
ARM guests are always HVM. The current implementation is assuming a 1:1
mapping which is only true for DOM0 and may not be at all in the future.
Furthermore, all the helpers but arbitrary_virt_to_machine are used in
x86 specific code (or only compiled for).
The helper arbitrary_virt_to_machine is only used in PV specific code.
Therefore we should never call the function.
Add a BUG() in this helper and drop all the others.
Signed-off-by: Julien Grall <julien.grall@citrix.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Since VPMU code emulates RDPMC instruction with RDMSR and because hypervisor
does not emulate it there is no reason to try setting CR4's PCE bit (and the
hypervisor will warn on seeing it set).
Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Add PMU emulation code that runs when we are processing a PMU interrupt.
This code will allow us not to trap to hypervisor on each MSR/LVTPC access
(of which there may be quite a few in the handler).
Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Reviewed-by: David Vrabel <david.vrabel@citrix.com>
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Provide interfaces for recognizing accesses to PMU-related MSRs and
LVTPC APIC and process these accesses in Xen PMU code.
(The interrupt handler performs XENPMU_flush right away in the beginning
since no PMU emulation is available. It will be added with a later patch).
Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Reviewed-by: David Vrabel <david.vrabel@citrix.com>
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
AMD and Intel PMU register initialization and helpers that determine
whether a register belongs to PMU.
This and some of subsequent PMU emulation code is somewhat similar to
Xen's PMU implementation.
Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Reviewed-by: David Vrabel <david.vrabel@citrix.com>
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Map shared data structure that will hold CPU registers, VPMU context,
V/PCPU IDs of the CPU interrupted by PMU interrupt. Hypervisor fills
this information in its handler and passes it to the guest for further
processing.
Set up PMU VIRQ.
Now that perf infrastructure will assume that PMU is available on a PV
guest we need to be careful and make sure that accesses via RDPMC
instruction don't cause fatal traps by the hypervisor. Provide a nop
RDPMC handler.
For the same reason avoid issuing a warning on a write to APIC's LVTPC.
Both of these will be made functional in later patches.
Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Reviewed-by: David Vrabel <david.vrabel@citrix.com>
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Set Xen's PMU mode via /sys/hypervisor/pmu/pmu_mode. Add XENPMU hypercall.
Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Cleanup by removing arch/x86/xen/p2m.h as it isn't needed any more.
Most definitions in this file are used in p2m.c only. Move those into
p2m.c.
set_phys_range_identity() is already declared in
arch/x86/include/asm/xen/page.h, add __init annotation there.
MAX_REMAP_RANGES isn't used at all, just delete it.
The only define left is P2M_PER_PAGE which is moved to page.h as well.
Signed-off-by: Juergen Gross <jgross@suse.com>
Acked-by: Konrad Rzeszutek Wilk <Konrad.wilk@oracle.com>
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
64 bit pv-domains under Xen are limited to 512 GB of RAM today. The
main reason has been the 3 level p2m tree, which was replaced by the
virtual mapped linear p2m list. Parallel to the p2m list which is
being used by the kernel itself there is a 3 level mfn tree for usage
by the Xen tools and eventually for crash dump analysis. For this tree
the linear p2m list can serve as a replacement, too. As the kernel
can't know whether the tools are capable of dealing with the p2m list
instead of the mfn tree, the limit of 512 GB can't be dropped in all
cases.
This patch replaces the hard limit by a kernel parameter which tells
the kernel to obey the 512 GB limit or not. The default is selected by
a configuration parameter which specifies whether the 512 GB limit
should be active per default for domUs (domain save/restore/migration
and crash dump analysis are affected).
Memory above the domain limit is returned to the hypervisor instead of
being identity mapped, which was wrong anyway.
The kernel configuration parameter to specify the maximum size of a
domain can be deleted, as it is not relevant any more.
Signed-off-by: Juergen Gross <jgross@suse.com>
Acked-by: Konrad Rzeszutek Wilk <Konrad.wilk@oracle.com>
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Check whether the hypervisor supplied p2m list is placed at a location
which is conflicting with the target E820 map. If this is the case
relocate it to a new area unused up to now and compliant to the E820
map.
As the p2m list might by huge (up to several GB) and is required to be
mapped virtually, set up a temporary mapping for the copied list.
For pvh domains just delete the p2m related information from start
info instead of reserving the p2m memory, as we don't need it at all.
For 32 bit kernels adjust the memblock_reserve() parameters in order
to cover the page tables only. This requires to memblock_reserve() the
start_info page on it's own.
Signed-off-by: Juergen Gross <jgross@suse.com>
Acked-by: Konrad Rzeszutek Wilk <Konrad.wilk@oracle.com>
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Some special pages containing interfaces to xen are being reserved
implicitly only today. The memblock_reserve() call to reserve them is
meant to reserve the p2m list supplied by xen. It is just reserving
not only the p2m list itself, but some more pages up to the start of
the xen built page tables.
To be able to move the p2m list to another pfn range, which is needed
for support of huge RAM, this memblock_reserve() must be split up to
cover all affected reserved pages explicitly.
The affected pages are:
- start_info page
- xenstore ring (might be missing, mfn is 0 in this case)
- console ring (not for initial domain)
Signed-off-by: Juergen Gross <jgross@suse.com>
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Check whether the initrd is placed at a location which is conflicting
with the target E820 map. If this is the case relocate it to a new
area unused up to now and compliant to the E820 map.
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: David Vrabel <david.vrabel@citrix.com>
Acked-by: Konrad Rzeszutek Wilk <Konrad.wilk@oracle.com>
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Check whether the page tables built by the domain builder are at
memory addresses which are in conflict with the target memory map.
If this is the case just panic instead of running into problems
later.
Signed-off-by: Juergen Gross <jgross@suse.com>
Acked-by: Konrad Rzeszutek Wilk <Konrad.wilk@oracle.com>
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Checks whether the pre-allocated memory of the loaded kernel is in
conflict with the target memory map. If this is the case, just panic
instead of run into problems later, as there is nothing we can do
to repair this situation.
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: David Vrabel <david.vrabel@citrix.com>
Acked-by: Konrad Rzeszutek Wilk <Konrad.wilk@oracle.com>
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
For being able to relocate pre-allocated data areas like initrd or
p2m list it is mandatory to find a contiguous memory area which is
not yet in use and doesn't conflict with the memory map we want to
be in effect.
In case such an area is found reserve it at once as this will be
required to be done in any case.
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: David Vrabel <david.vrabel@citrix.com>
Acked-by: Konrad Rzeszutek Wilk <Konrad.wilk@oracle.com>
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Provide a service routine to check a physical memory area against the
E820 map. The routine will return false if the complete area is RAM
according to the E820 map and true otherwise.
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: David Vrabel <david.vrabel@citrix.com>
Acked-by: Konrad Rzeszutek Wilk <Konrad.wilk@oracle.com>
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Memory pages in the initial memory setup done by the Xen hypervisor
conflicting with the target E820 map are remapped. In order to do this
those pages are counted and remapped in xen_set_identity_and_remap().
Split the counting from the remapping operation to be able to setup
the needed memory sizes in time but doing the remap operation at a
later time. This enables us to simplify the interface to
xen_set_identity_and_remap() as the number of remapped and released
pages is no longer needed here.
Finally move the remapping further down to prepare relocating
conflicting memory contents before the memory might be clobbered by
xen_set_identity_and_remap(). This requires to not destroy the Xen
E820 map when the one for the system is being constructed.
Signed-off-by: Juergen Gross <jgross@suse.com>
Acked-by: Konrad Rzeszutek Wilk <Konrad.wilk@oracle.com>
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
