* [PATCH v8 12/16] drivers: iommu: arm-smmu: split probe functions into DT/generic portions
From: Will Deacon @ 2016-11-18 16:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161116152936.22955-13-lorenzo.pieralisi@arm.com>
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.
Will
^ permalink raw reply
* [GIT PULL] pxa-dt for v4.10
From: Robert Jarzmik @ 2016-11-18 16:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161118071932.GB1785@localhost>
Olof Johansson <olof@lixom.net> writes:
>> Vijay Kumar (1):
>> Fix no. of gpio cells in the pxa gpio binding doucmentation
>
> This isn't the right patch subject. Please use standard prefix format
> here (ARM: dts: pxa: ...).
>
>
> Please respin this branch and post a fresh pull request. Thanks!
Ah sorry, wasn't careful enough, will respin.
Cheers.
--
Robert
^ permalink raw reply
* [PATCH v8 13/16] drivers: iommu: arm-smmu: add IORT configuration
From: Will Deacon @ 2016-11-18 16:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161116152936.22955-14-lorenzo.pieralisi@arm.com>
On Wed, Nov 16, 2016 at 03:29:33PM +0000, Lorenzo Pieralisi wrote:
> In ACPI bases systems, in order to be able to create platform
> devices and initialize them for ARM SMMU components, the IORT
> kernel implementation requires a set of static functions to be
> used by the IORT kernel layer to configure platform devices for
> ARM SMMU components.
>
> Add static configuration functions to the IORT kernel layer for
> the ARM SMMU components, so that the ARM SMMU driver can
> initialize its respective platform device by relying on the IORT
> kernel infrastructure and by adding a corresponding ACPI device
> early probe section entry.
>
> 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: Robin Murphy <robin.murphy@arm.com>
> Cc: Joerg Roedel <joro@8bytes.org>
> ---
> drivers/acpi/arm64/iort.c | 81 +++++++++++++++++++++++++++++++++++++++++++++
> drivers/iommu/arm-smmu.c | 83 ++++++++++++++++++++++++++++++++++++++++++++++-
> include/linux/acpi_iort.h | 3 ++
> 3 files changed, 166 insertions(+), 1 deletion(-)
[...]
> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
> index 573b2b6..21d1892 100644
> --- a/drivers/iommu/arm-smmu.c
> +++ b/drivers/iommu/arm-smmu.c
> @@ -28,6 +28,8 @@
>
> #define pr_fmt(fmt) "arm-smmu: " fmt
>
> +#include <linux/acpi.h>
> +#include <linux/acpi_iort.h>
> #include <linux/atomic.h>
> #include <linux/delay.h>
> #include <linux/dma-iommu.h>
> @@ -1904,6 +1906,70 @@ static const struct of_device_id arm_smmu_of_match[] = {
> };
> MODULE_DEVICE_TABLE(of, arm_smmu_of_match);
>
> +#ifdef CONFIG_ACPI
> +static int acpi_smmu_get_data(u32 model, u32 *version, u32 *impl)
You should use the enum type for the version, rather than a u32.
Will
^ permalink raw reply
* [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
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