* [PATCH 3/3] [media] mtk-mdp: mark PM functions as __maybe_unused
From: Arnd Bergmann @ 2016-11-18 16:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161118161621.798004-1-arnd@arndb.de>
The driver still produces a warning when CONFIG_PM is disabled, an
earlier fix only partially solved this:
media/platform/mtk-mdp/mtk_mdp_core.c:72:13: error: 'mtk_mdp_clock_off' defined but not used [-Werror=unused-function]
media/platform/mtk-mdp/mtk_mdp_core.c:63:13: error: 'mtk_mdp_clock_on' defined but not used [-Werror=unused-function]
This removes the incorrect #ifdef again and instead marks the PM
functions as __maybe_unused, which reliably shuts up the warning.
Fixes: 1b06fcf56aa6 ("[media] media: mtk-mdp: fix build error")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/media/platform/mtk-mdp/mtk_mdp_core.c | 12 ++++--------
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/drivers/media/platform/mtk-mdp/mtk_mdp_core.c b/drivers/media/platform/mtk-mdp/mtk_mdp_core.c
index 51f2b50e406f..9e4eb7dcc424 100644
--- a/drivers/media/platform/mtk-mdp/mtk_mdp_core.c
+++ b/drivers/media/platform/mtk-mdp/mtk_mdp_core.c
@@ -234,8 +234,7 @@ static int mtk_mdp_remove(struct platform_device *pdev)
return 0;
}
-#ifdef CONFIG_PM
-static int mtk_mdp_pm_suspend(struct device *dev)
+static int __maybe_unused mtk_mdp_pm_suspend(struct device *dev)
{
struct mtk_mdp_dev *mdp = dev_get_drvdata(dev);
@@ -244,7 +243,7 @@ static int mtk_mdp_pm_suspend(struct device *dev)
return 0;
}
-static int mtk_mdp_pm_resume(struct device *dev)
+static int __maybe_unused mtk_mdp_pm_resume(struct device *dev)
{
struct mtk_mdp_dev *mdp = dev_get_drvdata(dev);
@@ -252,10 +251,8 @@ static int mtk_mdp_pm_resume(struct device *dev)
return 0;
}
-#endif /* CONFIG_PM */
-#ifdef CONFIG_PM_SLEEP
-static int mtk_mdp_suspend(struct device *dev)
+static int __maybe_unused mtk_mdp_suspend(struct device *dev)
{
if (pm_runtime_suspended(dev))
return 0;
@@ -263,14 +260,13 @@ static int mtk_mdp_suspend(struct device *dev)
return mtk_mdp_pm_suspend(dev);
}
-static int mtk_mdp_resume(struct device *dev)
+static int __maybe_unused mtk_mdp_resume(struct device *dev)
{
if (pm_runtime_suspended(dev))
return 0;
return mtk_mdp_pm_resume(dev);
}
-#endif /* CONFIG_PM_SLEEP */
static const struct dev_pm_ops mtk_mdp_pm_ops = {
SET_SYSTEM_SLEEP_PM_OPS(mtk_mdp_suspend, mtk_mdp_resume)
--
2.9.0
^ permalink raw reply related
* [GIT PULL 1/10] mailbox: Add Tegra HSP driver
From: Thierry Reding @ 2016-11-18 16:17 UTC (permalink / raw)
To: linux-arm-kernel
Hi ARM SoC maintainers,
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/tegra/linux.git tags/tegra-for-4.10-mailbox
for you to fetch changes up to 68050eb6c611527232fe5574c7306e97e47499ef:
mailbox: tegra-hsp: Use after free in tegra_hsp_remove_doorbells() (2016-11-18 14:32:13 +0100)
Thanks,
Thierry
----------------------------------------------------------------
mailbox: Add Tegra HSP driver
This contains the device tree bindings and a driver for the Tegra HSP, a
hardware block that provides hardware synchronization primitives and is
the foundation for inter-processor communication between CPU and BPMP.
----------------------------------------------------------------
Dan Carpenter (1):
mailbox: tegra-hsp: Use after free in tegra_hsp_remove_doorbells()
Joseph Lo (2):
soc/tegra: Add Tegra186 support
dt-bindings: mailbox: Add Tegra HSP binding
Thierry Reding (2):
Merge branch 'for-4.10/soc' into for-4.10/mailbox
mailbox: Add Tegra HSP driver
.../bindings/mailbox/nvidia,tegra186-hsp.txt | 52 +++
drivers/mailbox/Kconfig | 9 +
drivers/mailbox/Makefile | 2 +
drivers/mailbox/tegra-hsp.c | 479 +++++++++++++++++++++
drivers/soc/tegra/Kconfig | 14 +
include/dt-bindings/mailbox/tegra186-hsp.h | 24 ++
6 files changed, 580 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mailbox/nvidia,tegra186-hsp.txt
create mode 100644 drivers/mailbox/tegra-hsp.c
create mode 100644 include/dt-bindings/mailbox/tegra186-hsp.h
^ permalink raw reply
* [GIT PULL 2/10] firmware: Add Tegra IVC and BPMP support
From: Thierry Reding @ 2016-11-18 16:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161118161719.24153-1-thierry.reding@gmail.com>
Hi ARM SoC maintainers,
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/tegra/linux.git tags/tegra-for-4.10-firmware
for you to fetch changes up to b704ed8095ee91af5f3f7343bb3be23aae1cb26d:
dt-bindings: firmware: Allow child nodes inside the Tegra BPMP (2016-11-18 14:33:44 +0100)
Thanks,
Thierry
----------------------------------------------------------------
firmware: Add Tegra IVC and BPMP support
IVC is an inter-processor communication protocol that uses shared memory
to exchange data between processors. The BPMP driver makes use of this
to communicate with the Boot and Power Management Processor (BPMP) and
uses an additional hardware synchronization primitive from the HSP block
to signal availability of new data (doorbell).
Firmware running on the BPMP implements a number of services such as the
control of clocks and resets within the system, or the ability to ungate
or gate power partitions.
----------------------------------------------------------------
Dan Carpenter (1):
mailbox: tegra-hsp: Use after free in tegra_hsp_remove_doorbells()
Joseph Lo (3):
soc/tegra: Add Tegra186 support
dt-bindings: mailbox: Add Tegra HSP binding
dt-bindings: firmware: Add bindings for Tegra BPMP
Stephen Warren (2):
dt-bindings: Add power domains to Tegra BPMP firmware
dt-bindings: firmware: Allow child nodes inside the Tegra BPMP
Thierry Reding (5):
Merge branch 'for-4.10/soc' into for-4.10/mailbox
mailbox: Add Tegra HSP driver
Merge branch 'for-4.10/mailbox' into for-4.10/firmware
firmware: tegra: Add IVC library
firmware: tegra: Add BPMP support
.../bindings/firmware/nvidia,tegra186-bpmp.txt | 108 ++
.../bindings/mailbox/nvidia,tegra186-hsp.txt | 52 +
drivers/firmware/Kconfig | 1 +
drivers/firmware/Makefile | 1 +
drivers/firmware/tegra/Kconfig | 25 +
drivers/firmware/tegra/Makefile | 2 +
drivers/firmware/tegra/bpmp.c | 868 +++++++++++
drivers/firmware/tegra/ivc.c | 695 +++++++++
drivers/mailbox/Kconfig | 9 +
drivers/mailbox/Makefile | 2 +
drivers/mailbox/tegra-hsp.c | 479 ++++++
drivers/soc/tegra/Kconfig | 14 +
include/dt-bindings/clock/tegra186-clock.h | 940 ++++++++++++
include/dt-bindings/mailbox/tegra186-hsp.h | 24 +
include/dt-bindings/power/tegra186-powergate.h | 39 +
include/dt-bindings/reset/tegra186-reset.h | 217 +++
include/soc/tegra/bpmp-abi.h | 1601 ++++++++++++++++++++
include/soc/tegra/bpmp.h | 141 ++
include/soc/tegra/ivc.h | 109 ++
19 files changed, 5327 insertions(+)
create mode 100644 Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.txt
create mode 100644 Documentation/devicetree/bindings/mailbox/nvidia,tegra186-hsp.txt
create mode 100644 drivers/firmware/tegra/Kconfig
create mode 100644 drivers/firmware/tegra/Makefile
create mode 100644 drivers/firmware/tegra/bpmp.c
create mode 100644 drivers/firmware/tegra/ivc.c
create mode 100644 drivers/mailbox/tegra-hsp.c
create mode 100644 include/dt-bindings/clock/tegra186-clock.h
create mode 100644 include/dt-bindings/mailbox/tegra186-hsp.h
create mode 100644 include/dt-bindings/power/tegra186-powergate.h
create mode 100644 include/dt-bindings/reset/tegra186-reset.h
create mode 100644 include/soc/tegra/bpmp-abi.h
create mode 100644 include/soc/tegra/bpmp.h
create mode 100644 include/soc/tegra/ivc.h
^ permalink raw reply
* [GIT PULL 3/10] reset: Add Tegra BPMP reset driver
From: Thierry Reding @ 2016-11-18 16:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161118161719.24153-1-thierry.reding@gmail.com>
Hi ARM SoC maintainers,
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/tegra/linux.git tags/tegra-for-4.10-reset
for you to fetch changes up to dc606c5205536a828c17bd96f06559dafaf75fb7:
reset: Add Tegra BPMP reset driver (2016-11-18 14:34:56 +0100)
Thanks,
Thierry
----------------------------------------------------------------
reset: Add Tegra BPMP reset driver
This contains a patch which implements a reset driver using the services
provided by the BPMP firmware (via the MRQ_RESET request).
----------------------------------------------------------------
Dan Carpenter (1):
mailbox: tegra-hsp: Use after free in tegra_hsp_remove_doorbells()
Joseph Lo (3):
soc/tegra: Add Tegra186 support
dt-bindings: mailbox: Add Tegra HSP binding
dt-bindings: firmware: Add bindings for Tegra BPMP
Stephen Warren (2):
dt-bindings: Add power domains to Tegra BPMP firmware
dt-bindings: firmware: Allow child nodes inside the Tegra BPMP
Thierry Reding (7):
Merge branch 'for-4.10/soc' into for-4.10/mailbox
mailbox: Add Tegra HSP driver
Merge branch 'for-4.10/mailbox' into for-4.10/firmware
firmware: tegra: Add IVC library
firmware: tegra: Add BPMP support
Merge branch 'for-4.10/firmware' into for-4.10/reset
reset: Add Tegra BPMP reset driver
.../bindings/firmware/nvidia,tegra186-bpmp.txt | 108 ++
.../bindings/mailbox/nvidia,tegra186-hsp.txt | 52 +
drivers/firmware/Kconfig | 1 +
drivers/firmware/Makefile | 1 +
drivers/firmware/tegra/Kconfig | 25 +
drivers/firmware/tegra/Makefile | 2 +
drivers/firmware/tegra/bpmp.c | 868 +++++++++++
drivers/firmware/tegra/ivc.c | 695 +++++++++
drivers/mailbox/Kconfig | 9 +
drivers/mailbox/Makefile | 2 +
drivers/mailbox/tegra-hsp.c | 479 ++++++
drivers/reset/Kconfig | 1 +
drivers/reset/Makefile | 1 +
drivers/reset/tegra/Kconfig | 2 +
drivers/reset/tegra/Makefile | 1 +
drivers/reset/tegra/reset-bpmp.c | 71 +
drivers/soc/tegra/Kconfig | 14 +
include/dt-bindings/clock/tegra186-clock.h | 940 ++++++++++++
include/dt-bindings/mailbox/tegra186-hsp.h | 24 +
include/dt-bindings/power/tegra186-powergate.h | 39 +
include/dt-bindings/reset/tegra186-reset.h | 217 +++
include/soc/tegra/bpmp-abi.h | 1601 ++++++++++++++++++++
include/soc/tegra/bpmp.h | 141 ++
include/soc/tegra/ivc.h | 109 ++
24 files changed, 5403 insertions(+)
create mode 100644 Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.txt
create mode 100644 Documentation/devicetree/bindings/mailbox/nvidia,tegra186-hsp.txt
create mode 100644 drivers/firmware/tegra/Kconfig
create mode 100644 drivers/firmware/tegra/Makefile
create mode 100644 drivers/firmware/tegra/bpmp.c
create mode 100644 drivers/firmware/tegra/ivc.c
create mode 100644 drivers/mailbox/tegra-hsp.c
create mode 100644 drivers/reset/tegra/Kconfig
create mode 100644 drivers/reset/tegra/Makefile
create mode 100644 drivers/reset/tegra/reset-bpmp.c
create mode 100644 include/dt-bindings/clock/tegra186-clock.h
create mode 100644 include/dt-bindings/mailbox/tegra186-hsp.h
create mode 100644 include/dt-bindings/power/tegra186-powergate.h
create mode 100644 include/dt-bindings/reset/tegra186-reset.h
create mode 100644 include/soc/tegra/bpmp-abi.h
create mode 100644 include/soc/tegra/bpmp.h
create mode 100644 include/soc/tegra/ivc.h
^ permalink raw reply
* [GIT PULL 4/10] bus: Add Tegra GMI support
From: Thierry Reding @ 2016-11-18 16:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161118161719.24153-1-thierry.reding@gmail.com>
Hi ARM SoC maintainers,
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/tegra/linux.git tags/tegra-for-4.10-bus
for you to fetch changes up to 40eb47767852a9122ef99a48f8d208ec6327e07f:
bus: Add support for Tegra Generic Memory Interface (2016-11-15 17:27:53 +0100)
Thanks,
Thierry
----------------------------------------------------------------
bus: Add Tegra GMI support
This provides a driver to enable the use of the Generic Memory Interface
found on Tegra SoCs that can host various types of high-speed devices.
----------------------------------------------------------------
Mirza Krak (2):
dt/bindings: Add bindings for Tegra GMI controller
bus: Add support for Tegra Generic Memory Interface
.../devicetree/bindings/bus/nvidia,tegra20-gmi.txt | 132 ++++++++++
drivers/bus/Kconfig | 7 +
drivers/bus/Makefile | 1 +
drivers/bus/tegra-gmi.c | 284 +++++++++++++++++++++
4 files changed, 424 insertions(+)
create mode 100644 Documentation/devicetree/bindings/bus/nvidia,tegra20-gmi.txt
create mode 100644 drivers/bus/tegra-gmi.c
^ permalink raw reply
* [GIT PULL 5/10] soc: tegra: Core SoC changes for v4.10-rc1
From: Thierry Reding @ 2016-11-18 16:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161118161719.24153-1-thierry.reding@gmail.com>
Hi ARM SoC maintainers,
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/tegra/linux.git tags/tegra-for-4.10-soc
for you to fetch changes up to 4522112069a976908e32e5dd3231c9272d19794a:
soc/tegra: pmc: Use consistent naming for PM domains (2016-11-15 15:51:56 +0100)
Thanks,
Thierry
----------------------------------------------------------------
soc: tegra: Core SoC changes for v4.10-rc1
This contains mostly cleanup and new feature work on the power
management controller as well as the addition of a Kconfig symbol for
the new Tegra186 (Parker) SoC generation.
----------------------------------------------------------------
Jon Hunter (4):
soc/tegra: pmc: Guard against uninitialised PMC clock
soc/tegra: pmc: Simplify IO rail bit handling
soc/tegra: pmc: Check return code for pm_genpd_init()
soc/tegra: pmc: Remove genpd when adding provider fails
Joseph Lo (1):
soc/tegra: Add Tegra186 support
Laxman Dewangan (3):
soc/tegra: pmc: Use BIT macro for register field definition
soc/tegra: pmc: Correct type of variable for tegra_pmc_readl()
soc/tegra: pmc: Add I/O pad voltage support
Thierry Reding (3):
soc/tegra: pmc: Use consistent ordering of bit definitions
soc/tegra: pmc: Clean-up I/O rail error messages
soc/tegra: pmc: Use consistent naming for PM domains
drivers/soc/tegra/Kconfig | 14 ++
drivers/soc/tegra/pmc.c | 398 +++++++++++++++++++++++++++++++++++-----------
include/soc/tegra/pmc.h | 126 +++++++++++----
3 files changed, 414 insertions(+), 124 deletions(-)
^ permalink raw reply
* [GIT PULL 6/10] dt-bindings: Cleanups and additions for v4.10-rc1
From: Thierry Reding @ 2016-11-18 16:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161118161719.24153-1-thierry.reding@gmail.com>
Hi ARM SoC maintainers,
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/tegra/linux.git tags/tegra-for-4.10-dt-bindings
for you to fetch changes up to 2e002bdedcdcbd6a708f5698a09eb32df568efb8:
dt-bindings: Add documentation for Tegra186 Denver (2016-11-17 18:09:05 +0100)
Thanks,
Thierry
----------------------------------------------------------------
dt-bindings: Cleanups and additions for v4.10-rc1
Contains two small patches, one fixing a typo and the other adding the
compatible string for the Denver CPUs found on the new Tegra186 SoCs.
----------------------------------------------------------------
Mirza Krak (1):
serial: tegra20-hsuart: Fix typo in dmas DT binding description
Thierry Reding (1):
dt-bindings: Add documentation for Tegra186 Denver
Documentation/devicetree/bindings/arm/cpus.txt | 1 +
Documentation/devicetree/bindings/serial/nvidia,tegra20-hsuart.txt | 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)
^ permalink raw reply
* [GIT PULL 7/10] ARM: tegra: Device tree changes for v4.10-rc1
From: Thierry Reding @ 2016-11-18 16:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161118161719.24153-1-thierry.reding@gmail.com>
Hi ARM SoC maintainers,
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/tegra/linux.git tags/tegra-for-4.10-arm-dt
for you to fetch changes up to 5e8a724d143308f3195375951b0c8f01b2ca59fe:
ARM: tegra: apalis-tk1: Drop leading 0 from unit-address (2016-11-08 11:14:02 +0100)
Thanks,
Thierry
----------------------------------------------------------------
ARM: tegra: Device tree changes for v4.10-rc1
Adds support for GMI on Tegra20 and Tegra30 and enables the GPU on Nyan
Chromebooks. It also enables sound support on various Toradex devices.
----------------------------------------------------------------
Marcel Ziswiler (1):
ARM: tegra: apalis/colibri t30: Integrate audio
Mirza Krak (2):
ARM: tegra: Add Tegra20 GMI support
ARM: tegra: Add Tegra30 GMI support
Paul Kocialkowski (1):
ARM: tegra: nyan: Enable GPU node and related supply
Thierry Reding (1):
ARM: tegra: apalis-tk1: Drop leading 0 from unit-address
arch/arm/boot/dts/tegra124-apalis.dtsi | 2 +-
arch/arm/boot/dts/tegra124-nyan.dtsi | 8 +++++-
arch/arm/boot/dts/tegra20.dtsi | 13 +++++++++
arch/arm/boot/dts/tegra30-apalis.dtsi | 49 ++++++++++++++++++++++++++++++++++
arch/arm/boot/dts/tegra30-colibri.dtsi | 49 ++++++++++++++++++++++++++++++++++
arch/arm/boot/dts/tegra30.dtsi | 13 +++++++++
6 files changed, 132 insertions(+), 2 deletions(-)
^ permalink raw reply
* [GIT PULL 8/10] ARM: tegra: Default configuration updates for v4.10-rc1
From: Thierry Reding @ 2016-11-18 16:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161118161719.24153-1-thierry.reding@gmail.com>
Hi ARM SoC maintainers,
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/tegra/linux.git tags/tegra-for-4.10-arm-defconfig
for you to fetch changes up to dafba3f6fb8614a114f939e5626447d71db864af:
ARM: tegra: Enable GMI driver in default configuration (2016-11-08 11:49:41 +0100)
Thanks,
Thierry
----------------------------------------------------------------
ARM: tegra: Default configuration updates for v4.10-rc1
Enable audio support for various Toradex devices as well as the GMI.
----------------------------------------------------------------
Marcel Ziswiler (1):
ARM: tegra: Enable SGTL5000 audio
Thierry Reding (2):
ARM: tegra: Update default configuration for v4.9-rc1
ARM: tegra: Enable GMI driver in default configuration
arch/arm/configs/tegra_defconfig | 27 +++++++++++++--------------
1 file changed, 13 insertions(+), 14 deletions(-)
^ permalink raw reply
* [GIT PULL 9/10] arm64: tegra: Device tree changes for v4.10-rc1
From: Thierry Reding @ 2016-11-18 16:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161118161719.24153-1-thierry.reding@gmail.com>
Hi ARM SoC maintainers,
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/tegra/linux.git tags/tegra-for-4.10-arm64-dt
for you to fetch changes up to cc13b4fa4ac780cec6c21b64a39ab2950e95e8f6:
arm64: tegra: Add NVIDIA P2771 board support (2016-11-18 14:35:53 +0100)
Thanks,
Thierry
----------------------------------------------------------------
arm64: tegra: Device tree changes for v4.10-rc1
This adds initial support for Tegra186, the P3310 processor module as
well as the P2771 development board. Not much is functional, but there
is enough to boot to an initial ramdisk with debug serial output.
----------------------------------------------------------------
Dan Carpenter (1):
mailbox: tegra-hsp: Use after free in tegra_hsp_remove_doorbells()
Joseph Lo (6):
soc/tegra: Add Tegra186 support
dt-bindings: mailbox: Add Tegra HSP binding
dt-bindings: firmware: Add bindings for Tegra BPMP
arm64: tegra: Add Tegra186 support
arm64: tegra: Add NVIDIA P3310 processor module support
arm64: tegra: Add NVIDIA P2771 board support
Stephen Warren (2):
dt-bindings: Add power domains to Tegra BPMP firmware
dt-bindings: firmware: Allow child nodes inside the Tegra BPMP
Thierry Reding (12):
Merge branch 'for-4.10/soc' into for-4.10/mailbox
mailbox: Add Tegra HSP driver
Merge branch 'for-4.10/mailbox' into for-4.10/firmware
firmware: tegra: Add IVC library
firmware: tegra: Add BPMP support
Merge branch 'for-4.10/firmware' into for-4.10/arm64/dt
arm64: tegra: Add CPU nodes for Tegra186
arm64: tegra: Add serial ports on Tegra186
arm64: tegra: Add I2C controllers on Tegra186
arm64: tegra: Add SDHCI controllers on Tegra186
arm64: tegra: Add GPIO controllers on Tegra186
arm64: tegra: Enable PSCI on P3310
.../bindings/firmware/nvidia,tegra186-bpmp.txt | 108 ++
.../bindings/mailbox/nvidia,tegra186-hsp.txt | 52 +
arch/arm64/boot/dts/nvidia/Makefile | 1 +
arch/arm64/boot/dts/nvidia/tegra186-p2771-0000.dts | 8 +
arch/arm64/boot/dts/nvidia/tegra186-p3310.dtsi | 64 +
arch/arm64/boot/dts/nvidia/tegra186.dtsi | 402 +++++
drivers/firmware/Kconfig | 1 +
drivers/firmware/Makefile | 1 +
drivers/firmware/tegra/Kconfig | 25 +
drivers/firmware/tegra/Makefile | 2 +
drivers/firmware/tegra/bpmp.c | 868 +++++++++++
drivers/firmware/tegra/ivc.c | 695 +++++++++
drivers/mailbox/Kconfig | 9 +
drivers/mailbox/Makefile | 2 +
drivers/mailbox/tegra-hsp.c | 479 ++++++
drivers/soc/tegra/Kconfig | 14 +
include/dt-bindings/clock/tegra186-clock.h | 940 ++++++++++++
include/dt-bindings/mailbox/tegra186-hsp.h | 24 +
include/dt-bindings/power/tegra186-powergate.h | 39 +
include/dt-bindings/reset/tegra186-reset.h | 217 +++
include/soc/tegra/bpmp-abi.h | 1601 ++++++++++++++++++++
include/soc/tegra/bpmp.h | 141 ++
include/soc/tegra/ivc.h | 109 ++
23 files changed, 5802 insertions(+)
create mode 100644 Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.txt
create mode 100644 Documentation/devicetree/bindings/mailbox/nvidia,tegra186-hsp.txt
create mode 100644 arch/arm64/boot/dts/nvidia/tegra186-p2771-0000.dts
create mode 100644 arch/arm64/boot/dts/nvidia/tegra186-p3310.dtsi
create mode 100644 arch/arm64/boot/dts/nvidia/tegra186.dtsi
create mode 100644 drivers/firmware/tegra/Kconfig
create mode 100644 drivers/firmware/tegra/Makefile
create mode 100644 drivers/firmware/tegra/bpmp.c
create mode 100644 drivers/firmware/tegra/ivc.c
create mode 100644 drivers/mailbox/tegra-hsp.c
create mode 100644 include/dt-bindings/clock/tegra186-clock.h
create mode 100644 include/dt-bindings/mailbox/tegra186-hsp.h
create mode 100644 include/dt-bindings/power/tegra186-powergate.h
create mode 100644 include/dt-bindings/reset/tegra186-reset.h
create mode 100644 include/soc/tegra/bpmp-abi.h
create mode 100644 include/soc/tegra/bpmp.h
create mode 100644 include/soc/tegra/ivc.h
^ permalink raw reply
* [GIT PULL 10/10] arm64: tegra: Default configuration updates for v4.10-rc1
From: Thierry Reding @ 2016-11-18 16:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161118161719.24153-1-thierry.reding@gmail.com>
Hi ARM SoC maintainers,
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/tegra/linux.git tags/tegra-for-4.10-arm64-defconfig
for you to fetch changes up to c6299451bb45bf3370cc3aa53891fb9d48bed774:
arm64: defconfig: Enable Tegra186 SoC (2016-11-15 16:26:03 +0100)
Thanks,
Thierry
----------------------------------------------------------------
arm64: tegra: Default configuration updates for v4.10-rc1
Enable Tegra186 support.
----------------------------------------------------------------
Joseph Lo (1):
arm64: defconfig: Enable Tegra186 SoC
arch/arm64/configs/defconfig | 1 +
1 file changed, 1 insertion(+)
^ permalink raw reply
* [PATCH V5 3/3] ARM64 LPC: LPC driver implementation on Hip06
From: Gabriele Paoloni @ 2016-11-18 16:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2271602.GoSoby0zHK@wuerfel>
> -----Original Message-----
> From: Arnd Bergmann [mailto:arnd at arndb.de]
> Sent: 18 November 2016 13:43
> To: linux-arm-kernel at lists.infradead.org
> Cc: Gabriele Paoloni; mark.rutland at arm.com; benh at kernel.crashing.org;
> catalin.marinas at arm.com; liviu.dudau at arm.com; Linuxarm;
> lorenzo.pieralisi at arm.com; xuwei (O); Jason Gunthorpe; linux-
> serial at vger.kernel.org; linux-pci at vger.kernel.org;
> devicetree at vger.kernel.org; minyard at acm.org; will.deacon at arm.com; John
> Garry; zourongrong at gmail.com; robh+dt at kernel.org; bhelgaas at go og
> le.com; kantyzc at 163.com; zhichang.yuan02 at gmail.com; Thomas Petazzoni;
> linux-kernel at vger.kernel.org; Yuanzhichang; olof at lixom.net
> Subject: Re: [PATCH V5 3/3] ARM64 LPC: LPC driver implementation on
> Hip06
>
> On Friday, November 18, 2016 12:53:08 PM CET Gabriele Paoloni wrote:
> > From: Arnd Bergmann [mailto:arnd at arndb.de]
> > > On Friday, November 18, 2016 12:07:28 PM CET Gabriele Paoloni
> wrote:
> > > > > I think there is no need to change a) here, we have
> PCIBIOS_MIN_IO
> > > > > today and even if we don't need it, there is no obvious
> downside.
> > > > > I would also argue that we can ignore b) for the discussion of
> > > > > the HiSilicon LPC driver, we just need to assign some range
> > > > > of logical addresses to each domain.
> > > > >
> > > > > That means solving c) is the important problem here, and it
> > > > > shouldn't be so hard. We can do this either with a single
> > > > > special domain as in the v5 patch series, or by generalizing it
> > > > > so that any I/O space mapping gets looked up through the device
> > > > > pointer of the bus master.
> > > >
> > > > I am not very on the "generalized" multi-domain solution...
> > > > Currently the IO accessors prototypes have an unsigned long addr
> > > > as input parameter. If we live in a multi-domain IO system
> > > > how can we distinguish inside the accessor which domain addr
> > > > belongs to?
> > >
> > > The easiest change compared to the v5 code would be to walk
> > > a linked list of 'struct extio_ops' structures rather than
> > > assuming there is only ever one of them. I think one of the
> > > earlier versions actually did this.
> >
> > Right but if my understanding is correct if we live in a multi-
> > domain I/O space world when you have an input addr in the I/O
> > accessors this addr can be duplicated (for example for the standard
> > PCI IO domain and for our special LPC domain).
> > So effectively even if you walk a linked list there is a problem
> > of disambiguation...am I right?
>
> No, unlike the PCI memory space, the PIO addresses are not
> usually distinct, i.e. every PCI bus has its own 64K I/O
> addresses starting at zero. We linearize them into the
> Linux I/O space using the per-domain io_offset value.
I am going to summarize my understanding here below:
It seems to me that what is linearized is the virtual address
space associated to the IO address space. This address space
goes from PCI_IOBASE to (PCI_IOBASE + IO_SPACE_LIMIT).
The I/O accessors perform rd/wr operation on this address
space using a port IO token.
Each token map into a cpu physical address range
Each cpu physical address range maps to a bus address range
if the bus controller specifies a range property.
Devices under a bus controller specify the bus addresses that
they operate on in their reg property.
So each device can use the same bus addresses under two
separate bus controllers as long as the bus controller
use the range properties to map the same bus range to different
cpu address range.
>
> For the ISA/LPC spaces there are only 4k of addresses, they
> the bus addresses always overlap, but we can trivially
> figure out the bus address from Linux I/O port number
> by subtracting the start of the range.
Are you saying that our LPC controller should specify a
range property to map bus addresses into a cpu address range?
>
> > > Another option the IA64 approach mentioned in another subthread
> > > today, looking up the operations based on an index from the
> > > upper bits of the port number. If we do this, we probably
> > > want to do that for all PIO access and replace the entire
> > > virtual address remapping logic with that. I think Bjorn
> > > in the past argued in favor of such an approach, while I
> > > advocated the current scheme for simplicity based on how
> > > every I/O space these days is just memory mapped (which now
> > > turned out to be false, both on powerpc and arm64).
> >
> > This seems really complex...I am a bit worried that possibly
> > we end up in having the maintainers saying that it is not worth
> > to re-invent the world just for this special LPC device...
>
> It would clearly be a rather invasive change, but the
> end-result isn't necessarily more complex than what we
> have today, as we'd kill off the crazy pci_pio_to_address()
> and pci_address_to_pio() hacks in address translation.
I have to look better into this...can you provide me a reference
to the Bjorn argument in favor of this approach?
>
> > To be honest with you I would keep things simple for this
> > LPC and introduce more complex reworks later if more devices
> > need to be introduced.
> >
> > What if we stick on a single domain now where we introduce a
> > reserved threshold for the IO space (say INDIRECT_MAX_IO).
>
> I said having a single domain is fine, but I still don't
> like the idea of reserving low port numbers for this hack,
> it would mean that the numbers change for everyone else.
I don't get this much...I/O tokens that are passed to the I/O
accessors are not fixed anyway and they vary depending on the order
of adding ranges to io_range_list...so I don't see a big issue
with this...
>
> > We define INDIRECT_MAX_IO as 0 in "include/linux/extio.h" and
> > we define INDIRECT_MAX_IO as 0x1000 in "arch/arm64/include/asm/io.h"
> >
> > So effectively this threshold can change according to the
> > architecture and so far we only define it for ARM64 as we need
> > it for ARM64...
>
> I liked the idea of having it done in asm-generic/io.h (in an ifdef)
> and lib/*.c under an as someone suggested earlier. There is nothing
> ARM64 specific in the implementation.
Correct and ideally if the INDIRECT_MAX_IO approach was taken then we
should define INDIRECT_MAX_IO for any architecture that can support the
special LPC devices. We would define it for ARM64 just because LPC
is used in our case under ARM64; the idea was to leave other architecture
to define their own ones as needed...but probably this is wrong and
we should have defined this for all the architectures.
Many thanks
Gab
>
> Arnd
^ permalink raw reply
* [PATCH 1/3] dt-bindings: Add Macnica Americas vendor prefix
From: Dinh Nguyen @ 2016-11-18 16:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161101153632.6844-1-dinguyen@kernel.org>
Hi Rob,
On Tue, Nov 1, 2016 at 10:36 AM, Dinh Nguyen <dinguyen@kernel.org> wrote:
> Add a vendor prefix for the Macnica company.
> http://http://www.macnica.com
>
> Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
> ---
> Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
> index f0a48ea..81674f2 100644
> --- a/Documentation/devicetree/bindings/vendor-prefixes.txt
> +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
> @@ -158,6 +158,7 @@ lg LG Corporation
> linux Linux-specific binding
> lltc Linear Technology Corporation
> lsi LSI Corp. (LSI Logic)
> +macnica Macnica Americas
> marvell Marvell Technology Group Ltd.
> maxim Maxim Integrated Products
> meas Measurement Specialties
> --
> 2.8.3
Just a gentle ping.
Thanks,
Dinh
^ permalink raw reply
* System/uncore PMUs and unit aggregation
From: Liang, Kan @ 2016-11-18 16:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161118092629.GK3117@twins.programming.kicks-ass.net>
> On Thu, Nov 17, 2016 at 06:17:08PM +0000, Will Deacon wrote:
> > Hi all,
> >
> > We currently have support for three arm64 system PMUs in flight:
> >
> > [Cavium ThunderX]
> > http://lkml.kernel.org/r/cover.1477741719.git.jglauber at cavium.com
> > [Hisilicon Hip0x]
> > http://lkml.kernel.org/r/1478151727-20250-1-git-send-email-
> anurup.m at hu
> > awei.com [Qualcomm L2]
> > http://lkml.kernel.org/r/1477687813-11412-1-git-send-email-nleeder at cod
> > eaurora.org
> >
> > Each of which have to deal with multiple underlying hardware units in
> > one way or another. Mark and I recently expressed a desire to expose
> > these units to userspace as individual PMU instances, since this can allow:
> >
> > * Fine-grained control of events from userspace, when you want to see
> > individual numbers as opposed to a summed total
> >
> > * Potentially ease migration to new SoC revisions, where the units
> > are laid out slightly differently
> >
> > * Easier handling of cases where the units aren't quite identical
>
> This is I think similar to the Intel Uncore situation. We expose every single
> individual PMU independently. The Intel uncore is wide and varied between
> parts.
>
> Leaving the rest for Kan, who's doing the Intel uncore bits.
>
> ~ Peter
>
> > however, this received pushback from all of the patch authors, so
> > there's clearly a problem with this approach. I'm hoping we can try to
> > resolve this here.
> >
> > Speaking to Mark earlier today, we came up with the following rough
> > rules for drivers that present multiple hardware units as a single PMU:
> >
> > 1. If the units share some part of the programming interface (e.g. control
> > registers or interrupts), then they must be handled by the same PMU.
> > Otherwise, they should be treated independently as separate PMU
> > instances.
> >
> > 2. If the units are handled by the same PMU, then care must be taken to
> > handle event groups correctly. That is, if the units cannot be started
> > and stopped atomically, cross-unit groups must be rejected by the
> > driver. Furthermore, any cross-unit scheduling constraints must be
> > honoured so that all the units targetted by a group can schedule the
> > group concurrently.
> >
> > 3. Summing the counters across units is only permitted if the units
> > can all be started and stopped atomically. Otherwise, the counters
> > should be exposed individually. It's up to the driver author to
> > decide what makes sense to sum.
> >
> > 4. Unit topology can optionally be described in sysfs (we should pick
> > some standard directory naming here), and then events targetting
> > specific units can have the unit identifier extracted from the topology
> > encoded in some configN fields.
> >
> > The million dollar question is: how does that fit in with the drivers
> > I mentioned at the top? Is this overly restrictive, or have we missed stuff?
> >
> > We certainly want to allow flexibility in the way in which the drivers
> > talk to the hardware, but given that these decisions directly affect
> > the user ABI, some consistent ground rules are required.
> >
> > For Cavium ThunderX, it's not clear whether or not the individual
> > units could be expressed as separate PMUs, or whether they're caught
> > by one of the rules above.
The individual unit should be a separate PMU. They are standalone system,
although they share the same PCI ID.
I think you can use bus:dev:fun to distinguish among them. That is what
we did for Skylake and KNL.
I noticed that you pick up random CPU for your uncore PMU.
In our implementation, we usually pick up the first available CPU.
>> The Qualcomm L2 looks like it's doing the
> > right thing and
If there is only one device, it should be OK.
But the variable "num_pmus" make me very confuse.
> > we can't quite work out what the Hisilicon Hip0x
> > topology looks like, since the interaction with djtag is confusing.
Each djtag device has its own PMU. They name them by scl_id. hisi_l3c*.
> >
> > If the driver authors (on To:) could shed some light on this, then
> > that would be much appreciated!
> >
> > Thanks,
> >
> > Will
^ permalink raw reply
* [RFC 2/6] drm/etnaviv: allow building etnaviv on omap devices
From: Rob Herring @ 2016-11-18 16:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161118024436.13447-2-robertcnelson@gmail.com>
On Thu, Nov 17, 2016 at 08:44:32PM -0600, Robert Nelson wrote:
> Signed-off-by: Robert Nelson <robertcnelson@gmail.com>
> CC: Christian Gmeiner <christian.gmeiner@gmail.com>
> CC: Russell King <rmk+kernel@arm.linux.org.uk>
> CC: Lucas Stach <l.stach@pengutronix.de>
> ---
> drivers/gpu/drm/etnaviv/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/etnaviv/Kconfig b/drivers/gpu/drm/etnaviv/Kconfig
> index 2cde7a5..b776f41 100644
> --- a/drivers/gpu/drm/etnaviv/Kconfig
> +++ b/drivers/gpu/drm/etnaviv/Kconfig
> @@ -2,7 +2,7 @@
> config DRM_ETNAVIV
> tristate "ETNAVIV (DRM support for Vivante GPU IP cores)"
> depends on DRM
> - depends on ARCH_MXC || ARCH_DOVE
> + depends on ARCH_MXC || ARCH_DOVE || ARCH_OMAP2PLUS
Why not just drop this line. Then it will get better build testing, too.
> select SHMEM
> select TMPFS
> select IOMMU_API
> --
> 2.10.2
>
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH V5 3/3] ARM64 LPC: LPC driver implementation on Hip06
From: Arnd Bergmann @ 2016-11-18 16:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <EE11001F9E5DDD47B7634E2F8A612F2E1F921858@lhreml507-mbx>
On Friday, November 18, 2016 4:18:07 PM CET Gabriele Paoloni wrote:
> From: Arnd Bergmann [mailto:arnd at arndb.de]
> > On Friday, November 18, 2016 12:53:08 PM CET Gabriele Paoloni wrote:
> > > From: Arnd Bergmann [mailto:arnd at arndb.de]
> > > > On Friday, November 18, 2016 12:07:28 PM CET Gabriele Paoloni
> > > > The easiest change compared to the v5 code would be to walk
> > > > a linked list of 'struct extio_ops' structures rather than
> > > > assuming there is only ever one of them. I think one of the
> > > > earlier versions actually did this.
> > >
> > > Right but if my understanding is correct if we live in a multi-
> > > domain I/O space world when you have an input addr in the I/O
> > > accessors this addr can be duplicated (for example for the standard
> > > PCI IO domain and for our special LPC domain).
> > > So effectively even if you walk a linked list there is a problem
> > > of disambiguation...am I right?
> >
> > No, unlike the PCI memory space, the PIO addresses are not
> > usually distinct, i.e. every PCI bus has its own 64K I/O
> > addresses starting at zero. We linearize them into the
> > Linux I/O space using the per-domain io_offset value.
>
> I am going to summarize my understanding here below:
>
> It seems to me that what is linearized is the virtual address
> space associated to the IO address space. This address space
> goes from PCI_IOBASE to (PCI_IOBASE + IO_SPACE_LIMIT).
>
> The I/O accessors perform rd/wr operation on this address
> space using a port IO token.
>
> Each token map into a cpu physical address range
> Each cpu physical address range maps to a bus address range
> if the bus controller specifies a range property.
>
> Devices under a bus controller specify the bus addresses that
> they operate on in their reg property.
>
> So each device can use the same bus addresses under two
> separate bus controllers as long as the bus controller
> use the range properties to map the same bus range to different
> cpu address range.
Sounds all correct to me so far, yes.
> > For the ISA/LPC spaces there are only 4k of addresses, they
> > the bus addresses always overlap, but we can trivially
> > figure out the bus address from Linux I/O port number
> > by subtracting the start of the range.
>
> Are you saying that our LPC controller should specify a
> range property to map bus addresses into a cpu address range?
No. There is not CPU address associated with it, because it's
not memory mapped.
Instead, we need to associate a bus address with a logical
Linux port number, both in of_address_to_resource and
in inb()/outb().
> > > > Another option the IA64 approach mentioned in another subthread
> > > > today, looking up the operations based on an index from the
> > > > upper bits of the port number. If we do this, we probably
> > > > want to do that for all PIO access and replace the entire
> > > > virtual address remapping logic with that. I think Bjorn
> > > > in the past argued in favor of such an approach, while I
> > > > advocated the current scheme for simplicity based on how
> > > > every I/O space these days is just memory mapped (which now
> > > > turned out to be false, both on powerpc and arm64).
> > >
> > > This seems really complex...I am a bit worried that possibly
> > > we end up in having the maintainers saying that it is not worth
> > > to re-invent the world just for this special LPC device...
> >
> > It would clearly be a rather invasive change, but the
> > end-result isn't necessarily more complex than what we
> > have today, as we'd kill off the crazy pci_pio_to_address()
> > and pci_address_to_pio() hacks in address translation.
>
> I have to look better into this...can you provide me a reference
> to the Bjorn argument in favor of this approach?
The thread seems to have been pci: Introduce pci_register_io_range()
helper function, e.g. in https://lkml.org/lkml/2014/7/8/969
> > > To be honest with you I would keep things simple for this
> > > LPC and introduce more complex reworks later if more devices
> > > need to be introduced.
> > >
> > > What if we stick on a single domain now where we introduce a
> > > reserved threshold for the IO space (say INDIRECT_MAX_IO).
> >
> > I said having a single domain is fine, but I still don't
> > like the idea of reserving low port numbers for this hack,
> > it would mean that the numbers change for everyone else.
>
> I don't get this much...I/O tokens that are passed to the I/O
> accessors are not fixed anyway and they vary depending on the order
> of adding ranges to io_range_list...so I don't see a big issue
> with this...
On machines with a legacy devices behind the PCI bridge,
there may still be a reason to have the low I/O port range
reserved for the primary bus, e.g. to get a VGA text console
to work.
On powerpc, this is called the "primary" PCI host, i.e. the
only one that is allowed to have an ISA bridge.
Arnd
^ permalink raw reply
* [PATCH v10 01/11] remoteproc: st_slim_rproc: add a slimcore rproc driver
From: Bjorn Andersson @ 2016-11-18 16:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161117095252.GC2698@localhost>
On Thu 17 Nov 01:52 PST 2016, Vinod Koul wrote:
> On Wed, Nov 16, 2016 at 10:36:46PM -0800, Bjorn Andersson wrote:
> > On Sun 13 Nov 21:18 PST 2016, Vinod Koul wrote:
> >
> > > On Mon, Nov 07, 2016 at 01:57:35PM +0000, Peter Griffin wrote:
> > > > >
> > > > > As you now make changes to the entire remoteproc Kconfig file, rather
> > > > > than simply add a Kconfig symbol we can't bring this in via Vinod's tree
> > > > > without providing Linus with a messy merge conflict.
> > > > >
> > > > > So the remoteproc parts now has to go through my tree.
> > > >
> > > > OK, I think the best approach is for Vinod to create an immutable
> > > > branch with the entire fdma series on, and then both of you merge that branch into
> > > > your respective trees.
> > >
> > > my topic/st_fdma is immutable branch. You cna merge it, if you need a signed
> > > tag, please do let me know
> > >
> >
> > Hi Vinod,
> >
> > It looks like you reverted the wrong Kconfig fix, the one I objected to
> > was the change in drivers/remoteproc, not the one in drivers/dma.
> >
> > The ST_FMDA depends on functions exposed by REMOTEPROC and
> > ST_SLIM_REMOTEPROC, the latter in turn depends on REMOTEPROC, which you
> > guys made user selectable - and as such should not be selected - but I
> > think we should move forward and get everything merged and then we can
> > go back and figure out how this should be addressed (or left alone?).
> >
> > I have merged "topic/st_fdma" into rproc-next, so that I can fix up the
> > now broken drivers/remoteproc/Kconfig.
> >
> > We do however both need to revert the revert or there will be link
> > errors if you build the dma driver with remoteproc=n. If you do this I
> > can merge the topic once more and we'll keep the set of changes in sync.
>
> Oops my bad, thanks for letting me know. I have reverted this now and
> pushing out. Please do let me know if this was fine
>
Thanks for the update Vinod, I've merged in your updated branch into
mine, so now we should be good.
Regards,
Bjorn
^ permalink raw reply
* [RFC 6/6] ARM: dts: am57xx-beagle-x15-common: enable etnaviv
From: Rob Herring @ 2016-11-18 16:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <e69a797c-bec3-2243-5c19-9d7633092369@ti.com>
On Thu, Nov 17, 2016 at 08:56:18PM -0600, Nishanth Menon wrote:
> On 11/17/2016 08:44 PM, Robert Nelson wrote:
> again.. a short commit message at least please? :)
>
> > Signed-off-by: Robert Nelson <robertcnelson@gmail.com>
> > CC: Julien <jboulnois@gmail.com>
> > CC: Nishanth Menon <nm@ti.com>
> > CC: Tomi Valkeinen <tomi.valkeinen@ti.com>
> > CC: Tony Lindgren <tony@atomide.com>
> > ---
> > arch/arm/boot/dts/am57xx-beagle-x15-common.dtsi | 11 +++++++++++
> > 1 file changed, 11 insertions(+)
> >
> > diff --git a/arch/arm/boot/dts/am57xx-beagle-x15-common.dtsi b/arch/arm/boot/dts/am57xx-beagle-x15-common.dtsi
> > index 6df7829..3bc47be 100644
> > --- a/arch/arm/boot/dts/am57xx-beagle-x15-common.dtsi
> > +++ b/arch/arm/boot/dts/am57xx-beagle-x15-common.dtsi
> > @@ -97,6 +97,12 @@
> > #cooling-cells = <2>;
> > };
> >
> > + gpu-subsystem {
> A) do we want to make things clear that this is gpu subsystem for gc320?
No.
> B) How about other platforms that could equally reuse?
Better yet, get rid of this nonsense. You are defining a wrapper to
group 1 nodes. Yes, I know this is what the driver wants, but you should
be able to make it deal with this situation and only have a gc320 node.
> > + compatible = "ti,gc320-gpu-subsystem";
> > + cores = <&bb2d>;
> > + status = "okay";
> > + };
> > +
^ permalink raw reply
* [PATCH v8 12/16] drivers: iommu: arm-smmu: split probe functions into DT/generic portions
From: Robin Murphy @ 2016-11-18 16:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161118160006.GW13470@arm.com>
On 18/11/16 16:00, Will Deacon wrote:
> On Wed, Nov 16, 2016 at 03:29:32PM +0000, Lorenzo Pieralisi wrote:
>> Current ARM SMMU probe functions intermingle HW and DT probing
>> in the initialization functions to detect and programme the ARM SMMU
>> driver features. In order to allow probing the ARM SMMU with other
>> firmwares than DT, this patch splits the ARM SMMU init functions into
>> DT and HW specific portions so that other FW interfaces (ie ACPI) can
>> reuse the HW probing functions and skip the DT portion accordingly.
>>
>> This patch implements no functional change, only code reshuffling.
>>
>> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
>> Reviewed-by: Tomasz Nowicki <tn@semihalf.com>
>> Tested-by: Hanjun Guo <hanjun.guo@linaro.org>
>> Tested-by: Tomasz Nowicki <tn@semihalf.com>
>> Cc: Will Deacon <will.deacon@arm.com>
>> Cc: Hanjun Guo <hanjun.guo@linaro.org>
>> Cc: Robin Murphy <robin.murphy@arm.com>
>> ---
>> drivers/iommu/arm-smmu.c | 62 +++++++++++++++++++++++++++++-------------------
>> 1 file changed, 37 insertions(+), 25 deletions(-)
>
> Reviewed-by: Will Deacon <will.deacon@arm.com>
>
> Although I'd also like Robin to have a look at this.
Sorry, I've been slow this week. Having finally got round to taking a
proper look, I swear this seems even tidier than the last version I
looked at closely. It doesn't break DT boot on my Juno, either.
Reviewed-by: Robin Murphy <robin.murphy@arm.com>
>
> Will
>
^ permalink raw reply
* [PATCH V8 1/3] tracing: add a possibility of exporting function trace to other places instead of ring buffer only
From: Steven Rostedt @ 2016-11-18 16:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87vavkesy6.fsf@ashishki-desk.ger.corp.intel.com>
On Fri, 18 Nov 2016 16:57:53 +0200
Alexander Shishkin <alexander.shishkin@linux.intel.com> wrote:
> Steven Rostedt <rostedt@goodmis.org> writes:
>
> > This looks good to me, although I would like this to go through my tree
> > (to make sure it gets all my testing). I understand the next two
> > patches depend on this, how would you want to go about that?
> >
> > One is that I can pull it in the next merge window, and the rest go in
> > after that. Or I can take the other two patches with the proper acks as
> > well.
>
> I just asked for the last patch be split 4 ways, but otherwise, they
> have my acks. If Chunyan can do that, you can take all of them into your
> tree.
>
OK, I'll wait for the split then.
Thanks,
-- Steve
^ permalink raw reply
* [PATCHv3 5/6] arm64: Use __pa_symbol for kernel symbols
From: Mark Rutland @ 2016-11-18 16:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161118143543.GC1197@leverpostej>
On Fri, Nov 18, 2016 at 02:35:44PM +0000, Mark Rutland wrote:
> Hi Laura,
>
> On Thu, Nov 17, 2016 at 05:16:55PM -0800, Laura Abbott wrote:
> >
> > __pa_symbol is technically the marco that should be used for kernel
> > symbols. Switch to this as a pre-requisite for DEBUG_VIRTUAL which
> > will do bounds checking.
> >
> > Signed-off-by: Laura Abbott <labbott@redhat.com>
> > ---
> > v3: Conversion of more sites besides just _end. Addition of __lm_sym_addr
> > macro to take care of the _va(__pa_symbol(..)) idiom.
> >
> > Note that a copy of __pa_symbol was added to avoid a mess of headers
> > since the #ifndef __pa_symbol case is defined in linux/mm.h
>
> I think we also need to fix up virt_to_phys(__cpu_soft_restart) in
> arch/arm64/kernel/cpu-reset.h. Otherwise, this looks complete for uses
> falling under arch/arm64/.
I think I spoke too soon. :(
In the kasan code, use of tmp_pg_dir, kasan_zero_{page,pte,pmd,pud} all
need to be vetted, as those are in the image, but get passed directly to
functions which will end up doing a virt_to_phys behind the scenes (e.g.
cpu_replace_ttbr1(), pmd_populate_kernel()).
There's also some virt_to_pfn(<symbol>) usage that needs to be fixed up
in arch/arm64/kernel/hibernate.c.
... there's also more of that in common kernel code. :(
Thanks,
Mark.
^ permalink raw reply
* [arm-soc:qcom/arm64 13/13] arch/arm64/boot/dts/qcom/msm8994.dtsi:14:48: fatal error: dt-bindings/clock/qcom,gcc-msm8994.h: No such file or directory
From: Andy Gross @ 2016-11-18 16:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201611182005.RuBSvaJ7%fengguang.wu@intel.com>
On Fri, Nov 18, 2016 at 08:20:07PM +0800, kbuild test robot wrote:
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git qcom/arm64
> head: feeaf56ac78d283efe65ea60ec999d4bf3cf395e
> commit: feeaf56ac78d283efe65ea60ec999d4bf3cf395e [13/13] arm64: dts: msm8994 SoC and Huawei Angler (Nexus 6P) support
> config: arm64-defconfig (attached as .config)
> compiler: aarch64-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
> reproduce:
> wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
> chmod +x ~/bin/make.cross
> git checkout feeaf56ac78d283efe65ea60ec999d4bf3cf395e
> # save the attached .config to linux build tree
> make.cross ARCH=arm64
>
> All errors (new ones prefixed by >>):
>
> In file included from arch/arm64/boot/dts/qcom/msm8994-angler-rev-101.dts:16:0:
> >> arch/arm64/boot/dts/qcom/msm8994.dtsi:14:48: fatal error: dt-bindings/clock/qcom,gcc-msm8994.h: No such file or directory
> #include <dt-bindings/clock/qcom,gcc-msm8994.h>
So I completely forgot to add the point that the 8994 dt-include information is
coming in through the clk-tree. We've been working with a immutable branch and
both will land for the next rc1. As such this hasn't been a problem in next,
but it will be for arm-soc for standalone testing.
Andy
^ permalink raw reply
* [PATCH 8/9] mfd: wm97xx-core: core support for wm97xx Codec
From: Lee Jones @ 2016-11-18 16:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477510907-23495-9-git-send-email-robert.jarzmik@free.fr>
On Wed, 26 Oct 2016, Robert Jarzmik wrote:
> The WM9705, WM9712 and WM9713 are highly integrated codecs, with an
> audio codec, DAC and ADC, GPIO unit and a touchscreen interface.
>
> Historically the support was spread across drivers/input/touchscreen and
> sound/soc/codecs. The sharing was done through ac97 bus sharing. This
> model will not withstand the new AC97 bus model, where codecs are
> discovered on runtime.
>
> Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
> ---
> drivers/mfd/Kconfig | 14 +++
> drivers/mfd/Makefile | 1 +
> drivers/mfd/wm97xx-core.c | 282 +++++++++++++++++++++++++++++++++++++++++++++
> include/linux/mfd/wm97xx.h | 31 +++++
> 4 files changed, 328 insertions(+)
> create mode 100644 drivers/mfd/wm97xx-core.c
> create mode 100644 include/linux/mfd/wm97xx.h
>
> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> index c6df6442ba2b..2ac818127b0a 100644
> --- a/drivers/mfd/Kconfig
> +++ b/drivers/mfd/Kconfig
> @@ -1597,6 +1597,20 @@ config MFD_WM8994
> core support for the WM8994, in order to use the actual
> functionaltiy of the device other drivers must be enabled.
>
> +config MFD_WM97xx
> + tristate "Wolfson Microelectronics WM97xx"
> + select MFD_CORE
> + select REGMAP_AC97
> + select AC97_BUS_COMPAT if AC97_BUS_NEW
> + help
> +
Surplus '\n' here.
> + The WM9705, WM9712 and WM9713 is a highly integrated hi-fi CODEC
> + designed for smartphone applications. As well as audio functionality
> + it has on board GPIO and a touchscreen functionality which is
> + supported via the relevant subsystems. This driver provides core
> + support for the WM97xx, in order to use the actual functionaltiy of
Always spell check your work.
> + the device other drivers must be enabled.
> +
> config MFD_STW481X
> tristate "Support for ST Microelectronics STw481x"
> depends on I2C && (ARCH_NOMADIK || COMPILE_TEST)
> diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
> index 9834e669d985..5c3534f4c7c3 100644
> --- a/drivers/mfd/Makefile
> +++ b/drivers/mfd/Makefile
> @@ -69,6 +69,7 @@ obj-$(CONFIG_MFD_WM8350) += wm8350.o
> obj-$(CONFIG_MFD_WM8350_I2C) += wm8350-i2c.o
> wm8994-objs := wm8994-core.o wm8994-irq.o wm8994-regmap.o
> obj-$(CONFIG_MFD_WM8994) += wm8994.o
> +obj-$(CONFIG_MFD_WM97xx) += wm97xx-core.o
>
> obj-$(CONFIG_TPS6105X) += tps6105x.o
> obj-$(CONFIG_TPS65010) += tps65010.o
> diff --git a/drivers/mfd/wm97xx-core.c b/drivers/mfd/wm97xx-core.c
> new file mode 100644
> index 000000000000..f2cd80354b4a
> --- /dev/null
> +++ b/drivers/mfd/wm97xx-core.c
> @@ -0,0 +1,282 @@
> +/*
> + * Wolfson WM97xx -- Core device
> + *
> + * Copyright (C) 2016 Robert Jarzmik
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * Features:
> + * - an AC97 audio codec
> + * - a touchscreen driver
> + * - a GPIO block
Place this above the Copyright.
> + */
> +
> +#include <linux/module.h>
Why is this seperted?
> +#include <linux/device.h>
> +#include <linux/mfd/core.h>
> +#include <linux/mfd/wm97xx.h>
> +#include <linux/wm97xx.h>
> +#include <linux/regmap.h>
> +#include <linux/slab.h>
> +#include <sound/ac97/codec.h>
> +#include <sound/ac97/compat.h>
Alphabetical.
> +#define WM9705_VENDOR_ID 0x574d4c05
> +#define WM9712_VENDOR_ID 0x574d4c12
> +#define WM9713_VENDOR_ID 0x574d4c13
> +#define WM97xx_VENDOR_ID_MASK 0xffffffff
Use tabs, not spaces.
These are probably better represented as enums.
> +struct wm97xx_priv {
> + struct regmap *regmap;
> + struct snd_ac97 *ac97;
> + struct device *dev;
> +};
Replace _priv with _ddata.
Also document using kerneldoc.
> +static bool wm97xx_readable_reg(struct device *dev, unsigned int reg)
> +{
> + switch (reg) {
> + case AC97_RESET ... AC97_PCM_SURR_DAC_RATE:
> + case AC97_PCM_LR_ADC_RATE:
> + case AC97_CENTER_LFE_MASTER:
> + case AC97_SPDIF ... AC97_LINE1_LEVEL:
> + case AC97_GPIO_CFG ... 0x5c:
Please define.
> + case AC97_CODEC_CLASS_REV ... AC97_PCI_SID:
> + case 0x74 ... AC97_VENDOR_ID2:
As above.
> + default:
> + return false;
> + }
> +}
> +
> +static bool wm97xx_writeable_reg(struct device *dev, unsigned int reg)
> +{
> + switch (reg) {
> + case AC97_VENDOR_ID1:
> + case AC97_VENDOR_ID2:
> + return false;
> + default:
> + return wm97xx_readable_reg(dev, reg);
> + }
> +}
> +
> +static const struct reg_default wm97xx_reg_defaults[] = {
> +};
What's the point in this?
> +static const struct regmap_config wm9705_regmap_config = {
> + .reg_bits = 16,
> + .reg_stride = 2,
> + .val_bits = 16,
> + .max_register = 0x7e,
> + .cache_type = REGCACHE_RBTREE,
> +
> + .reg_defaults = wm97xx_reg_defaults,
> + .num_reg_defaults = ARRAY_SIZE(wm97xx_reg_defaults),
> + .volatile_reg = regmap_ac97_default_volatile,
> + .readable_reg = wm97xx_readable_reg,
> + .writeable_reg = wm97xx_writeable_reg,
> +};
> +
> +static const struct regmap_config wm9712_regmap_config = {
> + .reg_bits = 16,
> + .reg_stride = 2,
> + .val_bits = 16,
> + .max_register = 0x7e,
> + .cache_type = REGCACHE_RBTREE,
> +
> + .reg_defaults = wm97xx_reg_defaults,
> + .num_reg_defaults = ARRAY_SIZE(wm97xx_reg_defaults),
> + .volatile_reg = regmap_ac97_default_volatile,
> + .readable_reg = wm97xx_readable_reg,
> + .writeable_reg = wm97xx_writeable_reg,
> +};
> +
> +static int wm9705_register(struct wm97xx_priv *wm97xx)
> +{
> + return 0;
> +}
> +
> +static int wm9712_register(struct wm97xx_priv *wm97xx)
> +{
> + return 0;
> +}
I don't get it?
Either populate or don't provide.
> +static const struct reg_default wm9713_reg_defaults[] = {
> + { 0x02, 0x8080 }, /* Speaker Output Volume */
> + { 0x04, 0x8080 }, /* Headphone Output Volume */
> + { 0x06, 0x8080 }, /* Out3/OUT4 Volume */
> + { 0x08, 0xc880 }, /* Mono Volume */
> + { 0x0a, 0xe808 }, /* LINEIN Volume */
> + { 0x0c, 0xe808 }, /* DAC PGA Volume */
> + { 0x0e, 0x0808 }, /* MIC PGA Volume */
> + { 0x10, 0x00da }, /* MIC Routing Control */
> + { 0x12, 0x8000 }, /* Record PGA Volume */
> + { 0x14, 0xd600 }, /* Record Routing */
> + { 0x16, 0xaaa0 }, /* PCBEEP Volume */
> + { 0x18, 0xaaa0 }, /* VxDAC Volume */
> + { 0x1a, 0xaaa0 }, /* AUXDAC Volume */
> + { 0x1c, 0x0000 }, /* Output PGA Mux */
> + { 0x1e, 0x0000 }, /* DAC 3D control */
> + { 0x20, 0x0f0f }, /* DAC Tone Control*/
> + { 0x22, 0x0040 }, /* MIC Input Select & Bias */
> + { 0x24, 0x0000 }, /* Output Volume Mapping & Jack */
> + { 0x26, 0x7f00 }, /* Powerdown Ctrl/Stat*/
> + { 0x28, 0x0405 }, /* Extended Audio ID */
> + { 0x2a, 0x0410 }, /* Extended Audio Start/Ctrl */
> + { 0x2c, 0xbb80 }, /* Audio DACs Sample Rate */
> + { 0x2e, 0xbb80 }, /* AUXDAC Sample Rate */
> + { 0x32, 0xbb80 }, /* Audio ADCs Sample Rate */
> + { 0x36, 0x4523 }, /* PCM codec control */
> + { 0x3a, 0x2000 }, /* SPDIF control */
> + { 0x3c, 0xfdff }, /* Powerdown 1 */
> + { 0x3e, 0xffff }, /* Powerdown 2 */
> + { 0x40, 0x0000 }, /* General Purpose */
> + { 0x42, 0x0000 }, /* Fast Power-Up Control */
> + { 0x44, 0x0080 }, /* MCLK/PLL Control */
> + { 0x46, 0x0000 }, /* MCLK/PLL Control */
> +
> + { 0x4c, 0xfffe }, /* GPIO Pin Configuration */
> + { 0x4e, 0xffff }, /* GPIO Pin Polarity / Type */
> + { 0x50, 0x0000 }, /* GPIO Pin Sticky */
> + { 0x52, 0x0000 }, /* GPIO Pin Wake-Up */
> + /* GPIO Pin Status */
> + { 0x56, 0xfffe }, /* GPIO Pin Sharing */
> + { 0x58, 0x4000 }, /* GPIO PullUp/PullDown */
> + { 0x5a, 0x0000 }, /* Additional Functions 1 */
> + { 0x5c, 0x0000 }, /* Additional Functions 2 */
> + { 0x60, 0xb032 }, /* ALC Control */
> + { 0x62, 0x3e00 }, /* ALC / Noise Gate Control */
> + { 0x64, 0x0000 }, /* AUXDAC input control */
> + { 0x74, 0x0000 }, /* Digitiser Reg 1 */
> + { 0x76, 0x0006 }, /* Digitiser Reg 2 */
> + { 0x78, 0x0001 }, /* Digitiser Reg 3 */
> + { 0x7a, 0x0000 }, /* Digitiser Read Back */
> +};
> +
> +static const struct regmap_config wm9713_regmap_config = {
> + .reg_bits = 16,
> + .reg_stride = 2,
> + .val_bits = 16,
> + .max_register = 0x7e,
> + .cache_type = REGCACHE_RBTREE,
> +
> + .reg_defaults = wm9713_reg_defaults,
> + .num_reg_defaults = ARRAY_SIZE(wm9713_reg_defaults),
> + .volatile_reg = regmap_ac97_default_volatile,
> + .readable_reg = wm97xx_readable_reg,
> + .writeable_reg = wm97xx_writeable_reg,
> +};
> +
> +static int wm9713_register(struct wm97xx_priv *wm97xx,
> + struct wm97xx_pdata *pdata)
> +{
What are you lining this up with?
> + struct wm97xx_platform_data codec_pdata;
> + const struct mfd_cell cells[] = {
> + {
> + .name = "wm9713-codec",
> + .platform_data = &codec_pdata,
> + .pdata_size = sizeof(codec_pdata),
> + },
> + {
> + .name = "wm97xx-ts",
> + .platform_data = &codec_pdata,
> + .pdata_size = sizeof(codec_pdata),
> + },
> + };
> +
> + codec_pdata.ac97 = wm97xx->ac97;
> + codec_pdata.regmap = devm_regmap_init_ac97(wm97xx->ac97,
> + &wm9713_regmap_config);
> + codec_pdata.batt_pdata = pdata->batt_pdata;
> + if (IS_ERR(codec_pdata.regmap))
> + return PTR_ERR(codec_pdata.regmap);
This doesn't look like pdata. You can get rid of all of this hoop
jumping if you add it to ddata and set it as such.
> + return devm_mfd_add_devices(wm97xx->dev, -1, cells,
Use the defines.
> + ARRAY_SIZE(cells), NULL, 0, NULL);
> +}
> +
> +static int wm97xx_ac97_probe(struct ac97_codec_device *adev)
This looks sound specific.
Why isn't this a plane platform driver?
> +{
> + struct wm97xx_priv *wm97xx;
> + int ret;
> + void *pdata = snd_ac97_codec_get_platdata(adev);
> +
> + wm97xx = devm_kzalloc(ac97_codec_dev2dev(adev),
> + sizeof(*wm97xx), GFP_KERNEL);
> + if (!wm97xx)
> + return -ENOMEM;
> +
> + wm97xx->dev = ac97_codec_dev2dev(adev);
> + wm97xx->ac97 = snd_ac97_compat_alloc(adev);
> + if (IS_ERR(wm97xx->ac97))
> + return PTR_ERR(wm97xx->ac97);
> +
> +
> + ac97_set_drvdata(adev, wm97xx);
> + dev_info(wm97xx->dev, "wm97xx core found, id=0x%x\n",
> + adev->vendor_id);
All of this ac97/sound stuff should be done in the ac97/sound driver.
> + switch (adev->vendor_id) {
> + case WM9705_VENDOR_ID:
> + ret = wm9705_register(wm97xx);
> + break;
> + case WM9712_VENDOR_ID:
> + ret = wm9712_register(wm97xx);
> + break;
> + case WM9713_VENDOR_ID:
> + ret = wm9713_register(wm97xx, pdata);
> + break;
> + default:
> + ret = -ENODEV;
> + }
> +
> + if (ret)
> + snd_ac97_compat_release(wm97xx->ac97);
> +
> + return ret;
> +}
> +
> +static int wm97xx_ac97_remove(struct ac97_codec_device *adev)
> +{
> + struct wm97xx_priv *wm97xx = ac97_get_drvdata(adev);
> +
> + snd_ac97_compat_release(wm97xx->ac97);
> +
> + return 0;
> +}
> +
> +static const struct ac97_id wm97xx_ac97_ids[] = {
> + { .id = WM9705_VENDOR_ID, .mask = WM97xx_VENDOR_ID_MASK },
> + { .id = WM9712_VENDOR_ID, .mask = WM97xx_VENDOR_ID_MASK },
> + { .id = WM9713_VENDOR_ID, .mask = WM97xx_VENDOR_ID_MASK },
> + { }
> +};
> +
> +static struct ac97_codec_driver wm97x3_ac97_driver = {
> + .driver = {
> + .name = "wm97xx-core",
> + },
> + .probe = wm97xx_ac97_probe,
> + .remove = wm97xx_ac97_remove,
> + .id_table = wm97xx_ac97_ids,
> +};
> +
> +static int __init wm97xx_module_init(void)
> +{
> + return snd_ac97_codec_driver_register(&wm97x3_ac97_driver);
> +}
> +module_init(wm97xx_module_init);
> +
> +static void __exit wm97xx_module_exit(void)
> +{
> + snd_ac97_codec_driver_unregister(&wm97x3_ac97_driver);
> +}
> +module_exit(wm97xx_module_exit);
> +
> +MODULE_DESCRIPTION("WM9712, WM9713 core driver");
> +MODULE_AUTHOR("Robert Jarzmik <robert.jarzmik@free.fr>");
> +MODULE_LICENSE("GPL");
> +
> diff --git a/include/linux/mfd/wm97xx.h b/include/linux/mfd/wm97xx.h
> new file mode 100644
> index 000000000000..627322f14d48
> --- /dev/null
> +++ b/include/linux/mfd/wm97xx.h
> @@ -0,0 +1,31 @@
> +/*
> + * wm97xx client interface
> + *
> + * Copyright (C) 2016 Robert Jarzmik
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * 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 General Public License for more details.
> + */
> +
> +#ifndef __LINUX_MFD_WM97XX_H
> +#define __LINUX_MFD_WM97XX_H
> +
> +struct regmap;
> +struct wm97xx_batt_pdata;
> +struct snd_ac97;
Why can't you just add the include files?
> +struct wm97xx_platform_data {
> + struct snd_ac97 *ac97;
> + struct regmap *regmap;
> + struct wm97xx_batt_pdata *batt_pdata;
> +};
> +
> +
> +#endif
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH v8 6/7] arm/arm64: vgic: Implement VGICv3 CPU interface access
From: Vijay Kilari @ 2016-11-18 16:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161117160951.GB23588@cbox>
On Thu, Nov 17, 2016 at 9:39 PM, Christoffer Dall
<christoffer.dall@linaro.org> wrote:
> On Thu, Nov 17, 2016 at 09:25:59PM +0530, Vijay Kilari wrote:
>> On Thu, Nov 17, 2016 at 12:22 AM, Christoffer Dall
>> <christoffer.dall@linaro.org> wrote:
>> > On Fri, Nov 04, 2016 at 04:43:32PM +0530, vijay.kilari at gmail.com wrote:
>> >> From: Vijaya Kumar K <Vijaya.Kumar@cavium.com>
>> >>
>> >> VGICv3 CPU interface registers are accessed using
>> >> KVM_DEV_ARM_VGIC_CPU_SYSREGS ioctl. These registers are accessed
>> >> as 64-bit. The cpu MPIDR value is passed along with register id.
>> >> is used to identify the cpu for registers access.
>> >>
>> >> The version of VGIC v3 specification is define here
>> >> http://lists.infradead.org/pipermail/linux-arm-kernel/2016-July/445611.html
>> >>
>> >> Signed-off-by: Pavel Fedin <p.fedin@samsung.com>
>> >> Signed-off-by: Vijaya Kumar K <Vijaya.Kumar@cavium.com>
>> >> ---
>> >> arch/arm64/include/uapi/asm/kvm.h | 3 +
>> >> arch/arm64/kvm/Makefile | 1 +
>> >> include/kvm/arm_vgic.h | 9 +
>> >> virt/kvm/arm/vgic/vgic-kvm-device.c | 27 +++
>> >> virt/kvm/arm/vgic/vgic-mmio-v3.c | 19 +++
>> >> virt/kvm/arm/vgic/vgic-sys-reg-v3.c | 324 ++++++++++++++++++++++++++++++++++++
>> >> virt/kvm/arm/vgic/vgic-v3.c | 8 +
>> >> virt/kvm/arm/vgic/vgic.h | 4 +
>> >> 8 files changed, 395 insertions(+)
>> >>
>> >> diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
>> >> index 56dc08d..91c7137 100644
>> >> --- a/arch/arm64/include/uapi/asm/kvm.h
>> >> +++ b/arch/arm64/include/uapi/asm/kvm.h
>> >> @@ -206,9 +206,12 @@ struct kvm_arch_memory_slot {
>> >> (0xffffffffULL << KVM_DEV_ARM_VGIC_V3_MPIDR_SHIFT)
>> >> #define KVM_DEV_ARM_VGIC_OFFSET_SHIFT 0
>> >> #define KVM_DEV_ARM_VGIC_OFFSET_MASK (0xffffffffULL << KVM_DEV_ARM_VGIC_OFFSET_SHIFT)
>> >> +#define KVM_DEV_ARM_VGIC_SYSREG_INSTR_MASK (0xffff)
>> >> #define KVM_DEV_ARM_VGIC_GRP_NR_IRQS 3
>> >> #define KVM_DEV_ARM_VGIC_GRP_CTRL 4
>> >> #define KVM_DEV_ARM_VGIC_GRP_REDIST_REGS 5
>> >> +#define KVM_DEV_ARM_VGIC_CPU_SYSREGS 6
>> >> +
>> >> #define KVM_DEV_ARM_VGIC_CTRL_INIT 0
>> >>
>> >> /* Device Control API on vcpu fd */
>> >> diff --git a/arch/arm64/kvm/Makefile b/arch/arm64/kvm/Makefile
>> >> index d50a82a..1a14e29 100644
>> >> --- a/arch/arm64/kvm/Makefile
>> >> +++ b/arch/arm64/kvm/Makefile
>> >> @@ -32,5 +32,6 @@ kvm-$(CONFIG_KVM_ARM_HOST) += $(KVM)/arm/vgic/vgic-mmio-v3.o
>> >> kvm-$(CONFIG_KVM_ARM_HOST) += $(KVM)/arm/vgic/vgic-kvm-device.o
>> >> kvm-$(CONFIG_KVM_ARM_HOST) += $(KVM)/arm/vgic/vgic-its.o
>> >> kvm-$(CONFIG_KVM_ARM_HOST) += $(KVM)/irqchip.o
>> >> +kvm-$(CONFIG_KVM_ARM_HOST) += $(KVM)/arm/vgic/vgic-sys-reg-v3.o
>> >
>> > Thi is making me wonder: Are we properly handling GICv3 save/restore
>> > for AArch32 now that we have GICv3 support for AArch32? By properly I
>> > mean that either it is clearly only supported on AArch64 systems or it's
>> > supported on both AArch64 and AArch32, but it shouldn't break randomly
>> > on AArch32.
>>
>> It supports both AArch64 and AArch64 in handling of system registers
>> save/restore.
>> All system registers that we save/restore are 32-bit for both aarch64
>> and aarch32.
>> Though opcode op0 should be zero for aarch32, the remaining Op and CRn codes
>> are same. However the codes sent by qemu is matched and register
>> are handled properly irrespective of AArch32 or AArch64.
>>
>> I don't have platform which support AArch32 guests to verify.
>
> Actually this is not about the guest, it's about an ARMv8 AArch32 host
> that has a GICv3.
>
> I just tried to do a v7 compile with your patches, and it results in an
> epic failure, so there's something for you to look at.
>
>> >
>> >> kvm-$(CONFIG_KVM_ARM_HOST) += $(KVM)/arm/arch_timer.o
>> >> kvm-$(CONFIG_KVM_ARM_PMU) += $(KVM)/arm/pmu.o
>> >> diff --git a/include/kvm/arm_vgic.h b/include/kvm/arm_vgic.h
>> >> index 002f092..730a18a 100644
>> >> --- a/include/kvm/arm_vgic.h
>> >> +++ b/include/kvm/arm_vgic.h
>> >> @@ -71,6 +71,9 @@ struct vgic_global {
>> >>
>> >> /* GIC system register CPU interface */
>> >> struct static_key_false gicv3_cpuif;
>> >> +
>> >> + /* Cache ICH_VTR_EL2 reg value */
>> >> + u32 ich_vtr_el2;
>> >> };
>> >>
>> >> extern struct vgic_global kvm_vgic_global_state;
>> >> @@ -269,6 +272,12 @@ struct vgic_cpu {
>> >> u64 pendbaser;
>> >>
>> >> bool lpis_enabled;
>> >> +
>> >> + /* Cache guest priority bits */
>> >> + u32 num_pri_bits;
>> >> +
>> >> + /* Cache guest interrupt ID bits */
>> >> + u32 num_id_bits;
>> >> };
>> >>
>> >> extern struct static_key_false vgic_v2_cpuif_trap;
>> >> diff --git a/virt/kvm/arm/vgic/vgic-kvm-device.c b/virt/kvm/arm/vgic/vgic-kvm-device.c
>> >> index 6c7d30c..da532d1 100644
>> >> --- a/virt/kvm/arm/vgic/vgic-kvm-device.c
>> >> +++ b/virt/kvm/arm/vgic/vgic-kvm-device.c
>> >> @@ -504,6 +504,14 @@ static int vgic_v3_attr_regs_access(struct kvm_device *dev,
>> >> if (!is_write)
>> >> *reg = tmp32;
>> >> break;
>> >> + case KVM_DEV_ARM_VGIC_CPU_SYSREGS: {
>> >> + u64 regid;
>> >> +
>> >> + regid = (attr->attr & KVM_DEV_ARM_VGIC_SYSREG_INSTR_MASK);
>> >> + ret = vgic_v3_cpu_sysregs_uaccess(vcpu, is_write,
>> >> + regid, reg);
>> >> + break;
>> >> + }
>> >> default:
>> >> ret = -EINVAL;
>> >> break;
>> >> @@ -537,6 +545,15 @@ static int vgic_v3_set_attr(struct kvm_device *dev,
>> >> reg = tmp32;
>> >> return vgic_v3_attr_regs_access(dev, attr, ®, true);
>> >> }
>> >> + case KVM_DEV_ARM_VGIC_CPU_SYSREGS: {
>> >> + u64 __user *uaddr = (u64 __user *)(long)attr->addr;
>> >> + u64 reg;
>> >> +
>> >> + if (get_user(reg, uaddr))
>> >> + return -EFAULT;
>> >> +
>> >> + return vgic_v3_attr_regs_access(dev, attr, ®, true);
>> >> + }
>> >> }
>> >> return -ENXIO;
>> >> }
>> >> @@ -563,6 +580,15 @@ static int vgic_v3_get_attr(struct kvm_device *dev,
>> >> tmp32 = reg;
>> >> return put_user(tmp32, uaddr);
>> >> }
>> >> + case KVM_DEV_ARM_VGIC_CPU_SYSREGS: {
>> >> + u64 __user *uaddr = (u64 __user *)(long)attr->addr;
>> >> + u64 reg;
>> >> +
>> >> + ret = vgic_v3_attr_regs_access(dev, attr, ®, false);
>> >> + if (ret)
>> >> + return ret;
>> >> + return put_user(reg, uaddr);
>> >> + }
>> >> }
>> >>
>> >> return -ENXIO;
>> >> @@ -581,6 +607,7 @@ static int vgic_v3_has_attr(struct kvm_device *dev,
>> >> break;
>> >> case KVM_DEV_ARM_VGIC_GRP_DIST_REGS:
>> >> case KVM_DEV_ARM_VGIC_GRP_REDIST_REGS:
>> >> + case KVM_DEV_ARM_VGIC_CPU_SYSREGS:
>> >> return vgic_v3_has_attr_regs(dev, attr);
>> >> case KVM_DEV_ARM_VGIC_GRP_NR_IRQS:
>> >> return 0;
>> >> diff --git a/virt/kvm/arm/vgic/vgic-mmio-v3.c b/virt/kvm/arm/vgic/vgic-mmio-v3.c
>> >> index b35fb83..519b919 100644
>> >> --- a/virt/kvm/arm/vgic/vgic-mmio-v3.c
>> >> +++ b/virt/kvm/arm/vgic/vgic-mmio-v3.c
>> >> @@ -23,6 +23,7 @@
>> >>
>> >> #include "vgic.h"
>> >> #include "vgic-mmio.h"
>> >> +#include "sys_regs.h"
>> >>
>> >> /* extract @num bytes at @offset bytes offset in data */
>> >> unsigned long extract_bytes(u64 data, unsigned int offset,
>> >> @@ -639,6 +640,24 @@ int vgic_v3_has_attr_regs(struct kvm_device *dev, struct kvm_device_attr *attr)
>> >> nr_regions = ARRAY_SIZE(vgic_v3_rdbase_registers);
>> >> break;
>> >> }
>> >> + case KVM_DEV_ARM_VGIC_CPU_SYSREGS: {
>> >> + u64 reg, id;
>> >> + unsigned long vgic_mpidr, mpidr_reg;
>> >> + struct kvm_vcpu *vcpu;
>> >> +
>> >> + vgic_mpidr = (attr->attr & KVM_DEV_ARM_VGIC_V3_MPIDR_MASK) >>
>> >> + KVM_DEV_ARM_VGIC_V3_MPIDR_SHIFT;
>> >> +
>> >> + /* Convert plain mpidr value to MPIDR reg format */
>> >> + mpidr_reg = VGIC_TO_MPIDR(vgic_mpidr);
>> >> +
>> >> + vcpu = kvm_mpidr_to_vcpu(dev->kvm, mpidr_reg);
>> >> + if (!vcpu)
>> >> + return -EINVAL;
>> >> +
>> >> + id = (attr->attr & KVM_DEV_ARM_VGIC_SYSREG_INSTR_MASK);
>> >> + return vgic_v3_has_cpu_sysregs_attr(vcpu, 0, id, ®);
>> >> + }
>> >> default:
>> >> return -ENXIO;
>> >> }
>> >> diff --git a/virt/kvm/arm/vgic/vgic-sys-reg-v3.c b/virt/kvm/arm/vgic/vgic-sys-reg-v3.c
>> >> new file mode 100644
>> >> index 0000000..69d8597
>> >> --- /dev/null
>> >> +++ b/virt/kvm/arm/vgic/vgic-sys-reg-v3.c
>> >
>> > Shouldn't we have a GPL header here?
>> >
>> >> @@ -0,0 +1,324 @@
>> >> +#include <linux/irqchip/arm-gic-v3.h>
>> >> +#include <linux/kvm.h>
>> >> +#include <linux/kvm_host.h>
>> >> +#include <kvm/iodev.h>
>> >> +#include <kvm/arm_vgic.h>
>> >> +#include <asm/kvm_emulate.h>
>> >> +#include <asm/kvm_arm.h>
>> >> +#include <asm/kvm_mmu.h>
>> >> +
>> >> +#include "vgic.h"
>> >> +#include "vgic-mmio.h"
>> >> +#include "sys_regs.h"
>> >> +
>> >> +static bool access_gic_ctlr(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
>> >> + const struct sys_reg_desc *r)
>> >> +{
>> >> + struct vgic_cpu *vgic_v3_cpu = &vcpu->arch.vgic_cpu;
>> >> + struct vgic_vmcr vmcr;
>> >> + u64 val;
>> >> + u32 num_pri_bits, num_id_bits;
>> >> +
>> >> + vgic_get_vmcr(vcpu, &vmcr);
>> >> + if (p->is_write) {
>> >> + val = p->regval;
>> >> +
>> >> + /*
>> >> + * Does not allow update of ICC_CTLR_EL1 if HW does not support
>> >> + * guest programmed ID and PRI bits
>> >> + */
>> >
>> > I would suggest rewording this comment:
>> > Disallow restoring VM state not supported by this hardware.
>> >
>> >> + num_pri_bits = ((val & ICC_CTLR_EL1_PRI_BITS_MASK) >>
>> >> + ICC_CTLR_EL1_PRI_BITS_SHIFT) + 1;
>> >> + if (num_pri_bits > vgic_v3_cpu->num_pri_bits)
>> >> + return false;
>> >> +
>> >> + vgic_v3_cpu->num_pri_bits = num_pri_bits;
>> >
>> > hmmm, this looks weird to me, because vgic_v3_cpu->num_pri_bits I don't
>> > understand which effect this is intended to have?
>> >
>> > Sure, it may limit what you do with other registers later, but since
>> > there's no ordering requirement that the ctlr be restored first, I'm not
>> > sure it makes sense.
>> >
>> > Also, since this field is RO in the ICH_VTR, we'll have a strange
>> > situation during runtime after a GICv3 restore where the
>> > vgic_v3_cpu->num_pri_its differs from the hardware's ICH_VTR_EL2 field,
>> > which is never the case if you didn't do a save/restore.
>>
>> Yes, but in any case, vgic_v3_cpu->num_pri_bits will be always less
>> than HW supported
>> value.
>>
>
> So answer my question: What is the intended effect of writing this
> value? Is it just so that if you migrate this platform back again, then
> you're checking compatibility with what the guest would potentially do,
Yes and also to limit the valid aprn registers access as you said above.
But that has ordering restriction. Which I think we should follow.
> or should you maintain the num_pri_bits limitation during runtime
> somehow?
Once after checking compatibility, at runtime it is not updated
and this value is not used at all in VGIC further
>
>> >
>> > Finally, should we somehow ensure that this field is set to the same
>> > value across VCPUs or is that not an architectural requirement?
>> >
>> Yes it is nice to have it same across VCPUs. But should be ok as
>> we are ensuring value is not greater than HW supported value.
>
> Does the architecture allow having a different number of priority bits
> supported across CPUs? If not, you shouldn't allow a VM programming
> things that way either.
AFAIK, architecturally it is not mentioned any where in the spec that priority
bits should be same across CPUs.
>
>> There is no single point of place where we can make such a check
>>
>> >> +
>> >> + num_id_bits = (val & ICC_CTLR_EL1_ID_BITS_MASK) >>
>> >> + ICC_CTLR_EL1_ID_BITS_SHIFT;
>> >> + if (num_id_bits > vgic_v3_cpu->num_id_bits)
>> >> + return false;
>> >> +
>> >> + vgic_v3_cpu->num_id_bits = num_id_bits;
>> >
>> > same questions
>> >
>> >> +
>> >> + vmcr.ctlr &= ~(ICH_VMCR_CBPR_MASK | ICH_VMCR_EOIM_MASK);
>> >> + vmcr.ctlr |= ((val & ICC_CTLR_EL1_CBPR_MASK) >>
>> >> + ICC_CTLR_EL1_CBPR_SHIFT) << ICH_VMCR_CBPR_SHIFT;
>> >> + vmcr.ctlr |= ((val & ICC_CTLR_EL1_EOImode_MASK) >>
>> >> + ICC_CTLR_EL1_EOImode_SHIFT) <<
>> >> + ICH_VMCR_EOIM_SHIFT;
>> >
>> > I'm really confused here. Is the vmcr.ctlr field in the ICC_CTLR_EL1
>> > format or in the VMCR format? I would assume the former, since
>> > otherwise I don't get the point with this indirection, and for GICv2
>> > vmcr.ctlr captures the GICC_CTLR value and git_set_vmcr transforms this
>> > into VMCR values.
>> >
>> > Having a line that says "ctlr &= ~ICH_VMCR" should make some alarm bells
>> > ring.
>>
>> I will check and fix it.
>> >
>> >> + vgic_set_vmcr(vcpu, &vmcr);
>> >
>> > Should we check compatibility between the source and destination for the
>> > SEIS and A3V support here?
>>
>> Can be checked. But I feel A3V check makes more sense than checking for
>> SEIS.
>>
>
> Please argue the *why* for whatever you end up doing with respect to
> both bits in the commit message of your next patch revision.
>
>> >
>> >> + } else {
>> >> + val = 0;
>> >> + val |= (vgic_v3_cpu->num_pri_bits - 1) <<
>> >> + ICC_CTLR_EL1_PRI_BITS_SHIFT;
>> >> + val |= vgic_v3_cpu->num_id_bits <<
>> >> + ICC_CTLR_EL1_ID_BITS_SHIFT;
>> >> + val |= ((kvm_vgic_global_state.ich_vtr_el2 &
>> >> + ICH_VTR_SEIS_MASK) >> ICH_VTR_SEIS_SHIFT) <<
>> >> + ICC_CTLR_EL1_SEIS_SHIFT;
>> >> + val |= ((kvm_vgic_global_state.ich_vtr_el2 &
>> >> + ICH_VTR_A3V_MASK) >> ICH_VTR_A3V_SHIFT) <<
>> >> + ICC_CTLR_EL1_A3V_SHIFT;
>> >> + val |= ((vmcr.ctlr & ICH_VMCR_CBPR_MASK) >>
>> >> + ICH_VMCR_CBPR_SHIFT) << ICC_CTLR_EL1_CBPR_SHIFT;
>> >> + val |= ((vmcr.ctlr & ICH_VMCR_EOIM_MASK) >>
>> >> + ICH_VMCR_EOIM_SHIFT) << ICC_CTLR_EL1_EOImode_SHIFT;
>> >
>> > again, these last two look weird to me.
>> >
>> >> +
>> >> + p->regval = val;
>> >> + }
>> >> +
>> >> + return true;
>> >> +}
>> >> +
>> >> +static bool access_gic_pmr(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
>> >> + const struct sys_reg_desc *r)
>> >> +{
>> >> + struct vgic_vmcr vmcr;
>> >> +
>> >> + vgic_get_vmcr(vcpu, &vmcr);
>> >> + if (p->is_write) {
>> >> + vmcr.pmr = (p->regval & ICC_PMR_EL1_MASK) >> ICC_PMR_EL1_SHIFT;
>> >> + vgic_set_vmcr(vcpu, &vmcr);
>> >> + } else {
>> >> + p->regval = (vmcr.pmr << ICC_PMR_EL1_SHIFT) & ICC_PMR_EL1_MASK;
>> >> + }
>> >> +
>> >> + return true;
>> >> +}
>> >> +
>> >> +static bool access_gic_bpr0(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
>> >> + const struct sys_reg_desc *r)
>> >> +{
>> >> + struct vgic_vmcr vmcr;
>> >> +
>> >> + vgic_get_vmcr(vcpu, &vmcr);
>> >> + if (p->is_write) {
>> >> + vmcr.bpr = (p->regval & ICC_BPR0_EL1_MASK) >>
>> >> + ICC_BPR0_EL1_SHIFT;
>> >> + vgic_set_vmcr(vcpu, &vmcr);
>> >> + } else {
>> >> + p->regval = (vmcr.bpr << ICC_BPR0_EL1_SHIFT) &
>> >> + ICC_BPR0_EL1_MASK;
>> >> + }
>> >> +
>> >> + return true;
>> >> +}
>> >> +
>> >> +static bool access_gic_bpr1(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
>> >> + const struct sys_reg_desc *r)
>> >> +{
>> >> + struct vgic_vmcr vmcr;
>> >> +
>> >> + if (!p->is_write)
>> >> + p->regval = 0;
>> >> +
>> >> + vgic_get_vmcr(vcpu, &vmcr);
>> >> + if (!((vmcr.ctlr & ICH_VMCR_CBPR_MASK) >> ICH_VMCR_CBPR_SHIFT)) {
>> >> + if (p->is_write) {
>> >> + vmcr.abpr = (p->regval & ICC_BPR1_EL1_MASK) >>
>> >> + ICC_BPR1_EL1_SHIFT;
>> >> + vgic_set_vmcr(vcpu, &vmcr);
>> >> + } else {
>> >> + p->regval = (vmcr.abpr << ICC_BPR1_EL1_SHIFT) &
>> >> + ICC_BPR1_EL1_MASK;
>> >> + }
>> >> + } else {
>> >> + if (!p->is_write)
>> >> + p->regval = min((vmcr.bpr + 1), 7U);
>> >> + }
>> >> +
>> >> + return true;
>> >> +}
>> >> +
>> >> +static bool access_gic_grpen0(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
>> >> + const struct sys_reg_desc *r)
>> >> +{
>> >> + struct vgic_vmcr vmcr;
>> >> +
>> >> + vgic_get_vmcr(vcpu, &vmcr);
>> >> + if (p->is_write) {
>> >> + vmcr.grpen0 = (p->regval & ICC_IGRPEN0_EL1_MASK) >>
>> >> + ICC_IGRPEN0_EL1_SHIFT;
>> >> + vgic_set_vmcr(vcpu, &vmcr);
>> >> + } else {
>> >> + p->regval = (vmcr.grpen0 << ICC_IGRPEN0_EL1_SHIFT) &
>> >> + ICC_IGRPEN0_EL1_MASK;
>> >> + }
>> >> +
>> >> + return true;
>> >> +}
>> >> +
>> >> +static bool access_gic_grpen1(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
>> >> + const struct sys_reg_desc *r)
>> >> +{
>> >> + struct vgic_vmcr vmcr;
>> >> +
>> >> + vgic_get_vmcr(vcpu, &vmcr);
>> >> + if (p->is_write) {
>> >> + vmcr.grpen1 = (p->regval & ICC_IGRPEN1_EL1_MASK) >>
>> >> + ICC_IGRPEN1_EL1_SHIFT;
>> >> + vgic_set_vmcr(vcpu, &vmcr);
>> >> + } else {
>> >> + p->regval = (vmcr.grpen1 << ICC_IGRPEN1_EL1_SHIFT) &
>> >> + ICC_IGRPEN1_EL1_MASK;
>> >> + }
>> >> +
>> >> + return true;
>> >> +}
>> >> +
>> >> +static void vgic_v3_access_apr_reg(struct kvm_vcpu *vcpu,
>> >> + struct sys_reg_params *p, u8 apr, u8 idx)
>> >> +{
>> >> + struct vgic_v3_cpu_if *vgicv3 = &vcpu->arch.vgic_cpu.vgic_v3;
>> >> + uint32_t *ap_reg;
>> >> +
>> >> + if (apr)
>> >> + ap_reg = &vgicv3->vgic_ap1r[idx];
>> >> + else
>> >> + ap_reg = &vgicv3->vgic_ap0r[idx];
>> >> +
>> >> + if (p->is_write)
>> >> + *ap_reg = p->regval;
>> >> + else
>> >> + p->regval = *ap_reg;
>> >> +}
>> >> +
>> >> +static void access_gic_aprn(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
>> >> + const struct sys_reg_desc *r, u8 apr)
>> >> +{
>> >> + struct vgic_cpu *vgic_v3_cpu = &vcpu->arch.vgic_cpu;
>> >> + u8 idx = r->Op2 & 3;
>> >> +
>> >> + switch (vgic_v3_cpu->num_pri_bits) {
>> >> + case 7:
>> >> + if (idx > 3)
>> >> + goto err;
>> >
>> > idx cannot be higher than three given the mask above, right?
>> >
>> >> + vgic_v3_access_apr_reg(vcpu, p, apr, idx);
>> >> + break;
>> >> + case 6:
>> >> + if (idx > 1)
>> >> + goto err;
>> >> + vgic_v3_access_apr_reg(vcpu, p, apr, idx);
>> >> + break;
>> >> + default:
>> >> + if (idx > 0)
>> >> + goto err;
>> >> + vgic_v3_access_apr_reg(vcpu, p, apr, idx);
>> >> + }
>> >
>> > what's the rationale behind ignoring the case where userspace is using
>> > unsupported priorities? Is it that this will be checked during
>> > save/restore of the ctlr?
>> >
>> > This sort of thing just looks like the case that's impossible to debug,
>> > because userspace could be scratching its head trying to understand why
>> > the value it wrote isn't recorded anywhere...
>> >
>> > If there's a good rationale for doing it this way, then could we have a
>> > comment to that effect?
>>
>> Accessing umplemented priority registers raised UNDEF exception.
>> So userspace accesing should be ignored instead of recording unsupported
>> values.
>>
>
> That's not what I asked.
>
> I asked why it's silently ignored as opposed to raising an error visible
> to user space?
>
>> >
>> >> +
>> >> + return;
>> >> +err:
>> >> + if (!p->is_write)
>> >> + p->regval = 0;
>> >> +}
>> >> +
>> >> +static bool access_gic_ap0r(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
>> >> + const struct sys_reg_desc *r)
>> >> +{
>> >> + access_gic_aprn(vcpu, p, r, 0);
>> >> +
>> >> + return true;
>> >> +}
>> >> +
>> >> +static bool access_gic_ap1r(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
>> >> + const struct sys_reg_desc *r)
>> >> +{
>> >> + access_gic_aprn(vcpu, p, r, 1);
>> >> +
>> >> + return true;
>> >> +}
>> >> +
>> >> +static bool access_gic_sre(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
>> >> + const struct sys_reg_desc *r)
>> >> +{
>> >> + struct vgic_v3_cpu_if *vgicv3 = &vcpu->arch.vgic_cpu.vgic_v3;
>> >> +
>> >> + /* Validate SRE bit */
>> >> + if (p->is_write) {
>> >> + if (!(p->regval & ICC_SRE_EL1_SRE))
>> >> + return false;
>> >> + } else {
>> >> + p->regval = vgicv3->vgic_sre;
>> >> + }
>> >> +
>> >> + return true;
>> >> +}
>> >> +
>> >> +static const struct sys_reg_desc gic_v3_icc_reg_descs[] = {
>> >> + /* ICC_PMR_EL1 */
>> >> + { Op0(3), Op1(0), CRn(4), CRm(6), Op2(0), access_gic_pmr },
>> >> + /* ICC_BPR0_EL1 */
>> >> + { Op0(3), Op1(0), CRn(12), CRm(8), Op2(3), access_gic_bpr0 },
>> >> + /* ICC_AP0R0_EL1 */
>> >> + { Op0(3), Op1(0), CRn(12), CRm(8), Op2(4), access_gic_ap0r },
>> >> + /* ICC_AP0R1_EL1 */
>> >> + { Op0(3), Op1(0), CRn(12), CRm(8), Op2(5), access_gic_ap0r },
>> >> + /* ICC_AP0R2_EL1 */
>> >> + { Op0(3), Op1(0), CRn(12), CRm(8), Op2(6), access_gic_ap0r },
>> >> + /* ICC_AP0R3_EL1 */
>> >> + { Op0(3), Op1(0), CRn(12), CRm(8), Op2(7), access_gic_ap0r },
>> >> + /* ICC_AP1R0_EL1 */
>> >> + { Op0(3), Op1(0), CRn(12), CRm(9), Op2(0), access_gic_ap1r },
>> >> + /* ICC_AP1R1_EL1 */
>> >> + { Op0(3), Op1(0), CRn(12), CRm(9), Op2(1), access_gic_ap1r },
>> >> + /* ICC_AP1R2_EL1 */
>> >> + { Op0(3), Op1(0), CRn(12), CRm(9), Op2(2), access_gic_ap1r },
>> >> + /* ICC_AP1R3_EL1 */
>> >> + { Op0(3), Op1(0), CRn(12), CRm(9), Op2(3), access_gic_ap1r },
>> >> + /* ICC_BPR1_EL1 */
>> >> + { Op0(3), Op1(0), CRn(12), CRm(12), Op2(3), access_gic_bpr1 },
>> >> + /* ICC_CTLR_EL1 */
>> >> + { Op0(3), Op1(0), CRn(12), CRm(12), Op2(4), access_gic_ctlr },
>> >> + /* ICC_SRE_EL1 */
>> >> + { Op0(3), Op1(0), CRn(12), CRm(12), Op2(5), access_gic_sre },
>> >> + /* ICC_IGRPEN0_EL1 */
>> >> + { Op0(3), Op1(0), CRn(12), CRm(12), Op2(6), access_gic_grpen0 },
>> >> + /* ICC_GRPEN1_EL1 */
>> >> + { Op0(3), Op1(0), CRn(12), CRm(12), Op2(7), access_gic_grpen1 },
>> >> +};
>> >> +
>> >> +int vgic_v3_has_cpu_sysregs_attr(struct kvm_vcpu *vcpu, bool is_write, u64 id,
>> >> + u64 *reg)
>> >> +{
>> >> + struct sys_reg_params params;
>> >> + u64 sysreg = (id & KVM_DEV_ARM_VGIC_SYSREG_MASK) | KVM_REG_SIZE_U64;
>> >> +
>> >> + params.regval = *reg;
>> >> + params.is_write = is_write;
>> >> + params.is_aarch32 = false;
>> >> + params.is_32bit = false;
>> >> +
>> >> + if (find_reg_by_id(sysreg, ¶ms, gic_v3_icc_reg_descs,
>> >> + ARRAY_SIZE(gic_v3_icc_reg_descs)))
>> >> + return 0;
>> >> +
>> >> + return -ENXIO;
>> >> +}
>> >> +
>> >> +int vgic_v3_cpu_sysregs_uaccess(struct kvm_vcpu *vcpu, bool is_write, u64 id,
>> >> + u64 *reg)
>> >> +{
>> >> + struct sys_reg_params params;
>> >> + const struct sys_reg_desc *r;
>> >> + u64 sysreg = (id & KVM_DEV_ARM_VGIC_SYSREG_MASK) | KVM_REG_SIZE_U64;
>> >> +
>> >> + if (is_write)
>> >> + params.regval = *reg;
>> >> + params.is_write = is_write;
>> >> + params.is_aarch32 = false;
>> >> + params.is_32bit = false;
>> >> +
>> >> + r = find_reg_by_id(sysreg, ¶ms, gic_v3_icc_reg_descs,
>> >> + ARRAY_SIZE(gic_v3_icc_reg_descs));
>> >> + if (!r)
>> >> + return -ENXIO;
>> >> +
>> >> + if (!r->access(vcpu, ¶ms, r))
>> >> + return -EINVAL;
>> >
>> > According to the API, EINVAL meansinvalid mpidr. Should we expand on
>> > how it can be used or allocate a new error code?
>> How abt EACCES error code?
>>
>
> That would mean permission denied, which is a bit weird.
Yes I agree, but you can suggest.
>
>> >
>> >> +
>> >> + if (!is_write)
>> >> + *reg = params.regval;
>> >> +
>> >> + return 0;
>> >> +}
>> >> diff --git a/virt/kvm/arm/vgic/vgic-v3.c b/virt/kvm/arm/vgic/vgic-v3.c
>> >> index 967c295..1139971 100644
>> >> --- a/virt/kvm/arm/vgic/vgic-v3.c
>> >> +++ b/virt/kvm/arm/vgic/vgic-v3.c
>> >> @@ -228,6 +228,13 @@ void vgic_v3_enable(struct kvm_vcpu *vcpu)
>> >> vgic_v3->vgic_sre = 0;
>> >> }
>> >>
>> >> + vcpu->arch.vgic_cpu.num_id_bits = (kvm_vgic_global_state.ich_vtr_el2 &
>> >> + ICH_VTR_ID_BITS_MASK) >>
>> >> + ICH_VTR_ID_BITS_SHIFT;
>> >> + vcpu->arch.vgic_cpu.num_pri_bits = ((kvm_vgic_global_state.ich_vtr_el2 &
>> >> + ICH_VTR_PRI_BITS_MASK) >>
>> >> + ICH_VTR_PRI_BITS_SHIFT) + 1;
>> >> +
>> >> /* Get the show on the road... */
>> >> vgic_v3->vgic_hcr = ICH_HCR_EN;
>> >> }
>> >> @@ -328,6 +335,7 @@ int vgic_v3_probe(const struct gic_kvm_info *info)
>> >> */
>> >> kvm_vgic_global_state.nr_lr = (ich_vtr_el2 & 0xf) + 1;
>> >> kvm_vgic_global_state.can_emulate_gicv2 = false;
>> >> + kvm_vgic_global_state.ich_vtr_el2 = ich_vtr_el2;
>> >>
>> >> if (!info->vcpu.start) {
>> >> kvm_info("GICv3: no GICV resource entry\n");
>> >> diff --git a/virt/kvm/arm/vgic/vgic.h b/virt/kvm/arm/vgic/vgic.h
>> >> index c461f6b..0e632d0 100644
>> >> --- a/virt/kvm/arm/vgic/vgic.h
>> >> +++ b/virt/kvm/arm/vgic/vgic.h
>> >> @@ -126,6 +126,10 @@ int vgic_v3_dist_uaccess(struct kvm_vcpu *vcpu, bool is_write,
>> >> int offset, u32 *val);
>> >> int vgic_v3_redist_uaccess(struct kvm_vcpu *vcpu, bool is_write,
>> >> int offset, u32 *val);
>> >> +int vgic_v3_cpu_sysregs_uaccess(struct kvm_vcpu *vcpu, bool is_write,
>> >> + u64 id, u64 *val);
>> >> +int vgic_v3_has_cpu_sysregs_attr(struct kvm_vcpu *vcpu, bool is_write, u64 id,
>> >> + u64 *reg);
>> >> #else
>> >> static inline int vgic_register_its_iodevs(struct kvm *kvm)
>> >> {
>> >> --
>
> Thanks,
> -Christoffer
^ permalink raw reply
* [PATCH V5 3/3] ARM64 LPC: LPC driver implementation on Hip06
From: Gabriele Paoloni @ 2016-11-18 17:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2364530.A9QSbaqvfm@wuerfel>
> -----Original Message-----
> From: Arnd Bergmann [mailto:arnd at arndb.de]
> Sent: 18 November 2016 16:35
> To: Gabriele Paoloni
> Cc: linux-arm-kernel at lists.infradead.org; mark.rutland at arm.com;
> benh at kernel.crashing.org; catalin.marinas at arm.com; liviu.dudau at arm.com;
> Linuxarm; lorenzo.pieralisi at arm.com; xuwei (O); Jason Gunthorpe; linux-
> serial at vger.kernel.org; linux-pci at vger.kernel.org;
> devicetree at vger.kernel.org; minyard at acm.org; will.deacon at arm.com; John
> Garry; zourongrong at gmail.com; robh+dt at kernel.org; bhelgaas at go og
> le.com; kantyzc at 163.com; zhichang.yuan02 at gmail.com; T homas Petazzoni;
> linux-kernel at vger.kernel.org; Yuanzhichang; olof at lixom.net
> Subject: Re: [PATCH V5 3/3] ARM64 LPC: LPC driver implementation on
> Hip06
>
> On Friday, November 18, 2016 4:18:07 PM CET Gabriele Paoloni wrote:
> > From: Arnd Bergmann [mailto:arnd at arndb.de]
> > > On Friday, November 18, 2016 12:53:08 PM CET Gabriele Paoloni
> wrote:
> > > > From: Arnd Bergmann [mailto:arnd at arndb.de]
> > > > > On Friday, November 18, 2016 12:07:28 PM CET Gabriele Paoloni
> > > > > The easiest change compared to the v5 code would be to walk
> > > > > a linked list of 'struct extio_ops' structures rather than
> > > > > assuming there is only ever one of them. I think one of the
> > > > > earlier versions actually did this.
> > > >
> > > > Right but if my understanding is correct if we live in a multi-
> > > > domain I/O space world when you have an input addr in the I/O
> > > > accessors this addr can be duplicated (for example for the
> standard
> > > > PCI IO domain and for our special LPC domain).
> > > > So effectively even if you walk a linked list there is a problem
> > > > of disambiguation...am I right?
> > >
> > > No, unlike the PCI memory space, the PIO addresses are not
> > > usually distinct, i.e. every PCI bus has its own 64K I/O
> > > addresses starting at zero. We linearize them into the
> > > Linux I/O space using the per-domain io_offset value.
> >
> > I am going to summarize my understanding here below:
> >
> > It seems to me that what is linearized is the virtual address
> > space associated to the IO address space. This address space
> > goes from PCI_IOBASE to (PCI_IOBASE + IO_SPACE_LIMIT).
> >
> > The I/O accessors perform rd/wr operation on this address
> > space using a port IO token.
> >
> > Each token map into a cpu physical address range
> > Each cpu physical address range maps to a bus address range
> > if the bus controller specifies a range property.
> >
> > Devices under a bus controller specify the bus addresses that
> > they operate on in their reg property.
> >
> > So each device can use the same bus addresses under two
> > separate bus controllers as long as the bus controller
> > use the range properties to map the same bus range to different
> > cpu address range.
>
> Sounds all correct to me so far, yes.
>
> > > For the ISA/LPC spaces there are only 4k of addresses, they
> > > the bus addresses always overlap, but we can trivially
> > > figure out the bus address from Linux I/O port number
> > > by subtracting the start of the range.
> >
> > Are you saying that our LPC controller should specify a
> > range property to map bus addresses into a cpu address range?
>
> No. There is not CPU address associated with it, because it's
> not memory mapped.
>
> Instead, we need to associate a bus address with a logical
> Linux port number, both in of_address_to_resource and
> in inb()/outb().
I think this is effectively what we are doing so far with patch 2/3.
The problem with this patch is that we are carving out a "forbidden"
IO tokens range that goes from 0 to PCIBIOS_MIN_IO.
I think that the proper solution would be to have the LPC driver to
set the carveout threshold used in pci_register_io_range(),
pci_pio_to_address(), pci_address_to_pio(), but this would impose
a probe dependency on the LPC itself that should be probed before
the PCI controller (or before any other devices calling these
functions...)
>
> > > > > Another option the IA64 approach mentioned in another subthread
> > > > > today, looking up the operations based on an index from the
> > > > > upper bits of the port number. If we do this, we probably
> > > > > want to do that for all PIO access and replace the entire
> > > > > virtual address remapping logic with that. I think Bjorn
> > > > > in the past argued in favor of such an approach, while I
> > > > > advocated the current scheme for simplicity based on how
> > > > > every I/O space these days is just memory mapped (which now
> > > > > turned out to be false, both on powerpc and arm64).
> > > >
> > > > This seems really complex...I am a bit worried that possibly
> > > > we end up in having the maintainers saying that it is not worth
> > > > to re-invent the world just for this special LPC device...
> > >
> > > It would clearly be a rather invasive change, but the
> > > end-result isn't necessarily more complex than what we
> > > have today, as we'd kill off the crazy pci_pio_to_address()
> > > and pci_address_to_pio() hacks in address translation.
> >
> > I have to look better into this...can you provide me a reference
> > to the Bjorn argument in favor of this approach?
>
> The thread seems to have been pci: Introduce pci_register_io_range()
> helper function, e.g. in https://lkml.org/lkml/2014/7/8/969
Ok many thanks I am going to look at it
>
> > > > To be honest with you I would keep things simple for this
> > > > LPC and introduce more complex reworks later if more devices
> > > > need to be introduced.
> > > >
> > > > What if we stick on a single domain now where we introduce a
> > > > reserved threshold for the IO space (say INDIRECT_MAX_IO).
> > >
> > > I said having a single domain is fine, but I still don't
> > > like the idea of reserving low port numbers for this hack,
> > > it would mean that the numbers change for everyone else.
> >
> > I don't get this much...I/O tokens that are passed to the I/O
> > accessors are not fixed anyway and they vary depending on the order
> > of adding ranges to io_range_list...so I don't see a big issue
> > with this...
>
> On machines with a legacy devices behind the PCI bridge,
> there may still be a reason to have the low I/O port range
> reserved for the primary bus, e.g. to get a VGA text console
> to work.
>
> On powerpc, this is called the "primary" PCI host, i.e. the
> only one that is allowed to have an ISA bridge.
Yes but
1) isn't the PCI controller range property that defines how IO bus address
map into physical CPU addresses?
2) How can you guarantee that the cpu range associated with this
IO bus range is the first to be registered in pci_register_io_range()?
( i.e. are you saying that they are just relying on the fact that it is the
only IO range in the system and by chance the IO tokens and corresponding
bus addresses are the same? )
Thanks
Gab
>
> Arnd
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox