* [RESEND PATCH] ARM: dts: stm32f469-disco: Fix memory size from 8MB to 16MB
From: Bruno Meirelles Herrera @ 2016-11-18 14:58 UTC (permalink / raw)
To: linux-arm-kernel
From: Bruno Herrera <bruherrera@gmail.com>
This patch fix memory size to support 16MB of external SDRAM.
Signed-off-by: Bruno Herrera <bruherrera@gmail.com>
---
arch/arm/boot/dts/stm32f469-disco.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/stm32f469-disco.dts b/arch/arm/boot/dts/stm32f469-disco.dts
index 75f4303..fda12a4 100644
--- a/arch/arm/boot/dts/stm32f469-disco.dts
+++ b/arch/arm/boot/dts/stm32f469-disco.dts
@@ -58,7 +58,7 @@
};
memory {
- reg = <0x00000000 0x800000>;
+ reg = <0x00000000 0x1000000>;
};
aliases {
--
2.9.3 (Apple Git-75)
^ permalink raw reply related
* [RFC 1/6] drm/etnaviv: add binding for the gc320 found in ti socs
From: Robert Nelson @ 2016-11-18 15:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479476068.20533.19.camel@pengutronix.de>
On Fri, Nov 18, 2016 at 7:34 AM, Lucas Stach <l.stach@pengutronix.de> wrote:
> Am Freitag, den 18.11.2016, 12:13 +0000 schrieb Russell King - ARM
> Linux:
>> On Thu, Nov 17, 2016 at 08:53:38PM -0600, Nishanth Menon wrote:
>> > >diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.c b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
>> > >index a6799b0..ce51270 100644
>> > >--- a/drivers/gpu/drm/etnaviv/etnaviv_drv.c
>> > >+++ b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
>> > >@@ -653,6 +653,7 @@ static int etnaviv_pdev_remove(struct platform_device *pdev)
>> > > static const struct of_device_id dt_match[] = {
>> > > { .compatible = "fsl,imx-gpu-subsystem" },
>> > > { .compatible = "marvell,dove-gpu-subsystem" },
>> > >+ { .compatible = "ti,gc320-gpu-subsystem" },
>>
>> We need to get away from this ever-increasing set of compatible
>> strings here, as this is not long-term maintainable.
>>
>> What we should have is a common compatible which describes that
>> the node is compatible with this driver, and then use SoC specific
>> compatible strings later if we need to (eg, because of some GPU
>> subsystem SoC specifics.)
>>
>> So, I'd suggest that we update the documentation and add:
>>
>> "vivante,gc-gpu-subsystem"
>>
>> as a common compatible now, and if necessary move on to more specific
>> compatibles if we need to later.
>>
>> Also, I'd strongly suggest that no compatibles should contain the ID
>> number of the GPU core for exactly the same reason - Vivante GPU cores
>> vary according to features, and we don't want to end up with a long
>> list of specific compatibles (eg)
>> "ti,gc2000-and-gc320-and-gc355-gpu-subsystem" because TI
>> decides to integrate a 3d, 2d and VG core.
>>
> All of the above sounds sensible and I would prefer if the patches are
> reworked to take those things into account.
Thanks for reviewing guys, the "vivante,gc-gpu-subsystem" will work
perfectly fine for me, as the etnaviv driver does a great job at auto
detecting the hardware..
Regards,
--
Robert Nelson
https://rcn-ee.com/
^ permalink raw reply
* [RESEND PATCH v1] ARM: dts: stm32f429: Add missing USART3 pin config to STM32F469I-DISCO board
From: Bruno Meirelles Herrera @ 2016-11-18 15:10 UTC (permalink / raw)
To: linux-arm-kernel
Including new STM32 maintainer. Rebased at stm32-dt-for-v4.10-1 and
stm32-dt-for-v4.10-2 branches. It fix the port/pin initialization in
case boot-loader does not configure/initialize the pins.
Fixing line wrapping from last patch
This patch adds USART3 pin configuration on PB10/PA11 pins
for STM32F469I-DISCO board.
Signed-off-by: Bruno Herrera <bruherrera@gmail.com>
---
arch/arm/boot/dts/stm32f429.dtsi | 13 +++++++++++++
arch/arm/boot/dts/stm32f469-disco.dts | 2 ++
2 files changed, 15 insertions(+)
diff --git a/arch/arm/boot/dts/stm32f429.dtsi b/arch/arm/boot/dts/stm32f429.dtsi
index e4dae0e..1b8b105 100644
--- a/arch/arm/boot/dts/stm32f429.dtsi
+++ b/arch/arm/boot/dts/stm32f429.dtsi
@@ -316,6 +316,19 @@
};
};
+ usart3_pins_a: usart3 at 0 {
+ pins1 {
+ pinmux = <STM32F429_PB10_FUNC_USART3_TX>;
+ bias-disable;
+ drive-push-pull;
+ slew-rate = <0>;
+ };
+ pins2 {
+ pinmux = <STM32F429_PB11_FUNC_USART3_RX>;
+ bias-disable;
+ };
+ };
+
usbotg_hs_pins_a: usbotg_hs at 0 {
pins {
pinmux = <STM32F429_PH4_FUNC_OTG_HS_ULPI_NXT>,
diff --git a/arch/arm/boot/dts/stm32f469-disco.dts b/arch/arm/boot/dts/stm32f469-disco.dts
index 8877c00..75f4303 100644
--- a/arch/arm/boot/dts/stm32f469-disco.dts
+++ b/arch/arm/boot/dts/stm32f469-disco.dts
@@ -79,5 +79,7 @@
};
&usart3 {
+ pinctrl-0 = <&usart3_pins_a>;
+ pinctrl-names = "default";
status = "okay";
};
--
2.9.3 (Apple Git-75)
^ permalink raw reply related
* [PATCH v2 5/8] dt-bindings: mfd: Provide human readable defines for TPS65217 interrupts
From: Tony Lindgren @ 2016-11-18 15:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161118145353.GE2301@dell.home>
* Lee Jones <lee.jones@linaro.org> [161118 06:51]:
> On Fri, 28 Oct 2016, Milo Kim wrote:
>
> > TPS65217 supports three interrupt sources. This patch enables assigning
> > each IRQ number in the charger and power button node. Then corresponding
> > IRQ will be requested by each driver.
> >
> > Signed-off-by: Milo Kim <woogyom.kim@gmail.com>
> > ---
> > include/dt-bindings/mfd/tps65217.h | 26 ++++++++++++++++++++++++++
> > 1 file changed, 26 insertions(+)
> > create mode 100644 include/dt-bindings/mfd/tps65217.h
> >
> > diff --git a/include/dt-bindings/mfd/tps65217.h b/include/dt-bindings/mfd/tps65217.h
> > new file mode 100644
> > index 0000000..cafb9e6
> > --- /dev/null
> > +++ b/include/dt-bindings/mfd/tps65217.h
> > @@ -0,0 +1,26 @@
> > +/*
> > + * This header provides macros for TI TPS65217 DT bindings.
> > + *
> > + * Copyright (C) 2016 Texas Instruments
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License version 2 as
> > + * published by the Free Software Foundation.
> > + *
> > + * This program is distributed in the hope that it will be useful, but
> > + * WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> > + * General Public License for more details.
> > + *
> > + * You should have received a copy of the GNU General Public License along with
> > + * this program. If not, see <http://www.gnu.org/licenses/>.
> > + */
> > +
> > +#ifndef __DT_BINDINGS_TPS65217_H__
> > +#define __DT_BINDINGS_TPS65217_H__
> > +
> > +#define TPS65217_IRQ_USB 0
> > +#define TPS65217_IRQ_AC 1
> > +#define TPS65217_IRQ_PB 2
>
> What are "AC" and "PB". Seeing as these are meant to be "human
> readable", let's make them more human friendly.
Good idea. Milo, please do an incremental single follow-up patch as
I already have applied this and the dts changes using it.
Regards,
Tony
^ permalink raw reply
* [PATCH v8 10/16] drivers: iommu: arm-smmu-v3: split probe functions into DT/generic portions
From: Will Deacon @ 2016-11-18 15:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161116152936.22955-11-lorenzo.pieralisi@arm.com>
On Wed, Nov 16, 2016 at 03:29:30PM +0000, Lorenzo Pieralisi wrote:
> Current ARM SMMUv3 probe functions intermingle HW and DT probing in the
> initialization functions to detect and programme the ARM SMMU v3 driver
> features. In order to allow probing the ARM SMMUv3 with other firmwares
> than DT, this patch splits the ARM SMMUv3 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>
> Acked-by: Will Deacon <will.deacon@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>
> Cc: Joerg Roedel <joro@8bytes.org>
> ---
> drivers/iommu/arm-smmu-v3.c | 46 +++++++++++++++++++++++++++++----------------
> 1 file changed, 30 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c
> index e6e1c87..ed563307 100644
> --- a/drivers/iommu/arm-smmu-v3.c
> +++ b/drivers/iommu/arm-smmu-v3.c
> @@ -2381,10 +2381,10 @@ static int arm_smmu_device_reset(struct arm_smmu_device *smmu, bool bypass)
> return 0;
> }
>
> -static int arm_smmu_device_probe(struct arm_smmu_device *smmu)
> +static int arm_smmu_device_hw_probe(struct arm_smmu_device *smmu)
> {
> u32 reg;
> - bool coherent;
> + bool coherent = smmu->features & ARM_SMMU_FEAT_COHERENCY;
>
> /* IDR0 */
> reg = readl_relaxed(smmu->base + ARM_SMMU_IDR0);
> @@ -2436,13 +2436,9 @@ static int arm_smmu_device_probe(struct arm_smmu_device *smmu)
> smmu->features |= ARM_SMMU_FEAT_HYP;
>
> /*
> - * The dma-coherent property is used in preference to the ID
> + * The coherency feature as set by FW is used in preference to the ID
> * register, but warn on mismatch.
> */
> - coherent = of_dma_is_coherent(smmu->dev->of_node);
> - if (coherent)
> - smmu->features |= ARM_SMMU_FEAT_COHERENCY;
> -
> if (!!(reg & IDR0_COHACC) != coherent)
> dev_warn(smmu->dev, "IDR0.COHACC overridden by dma-coherent property (%s)\n",
> coherent ? "true" : "false");
> @@ -2563,21 +2559,37 @@ static int arm_smmu_device_probe(struct arm_smmu_device *smmu)
> return 0;
> }
>
> -static int arm_smmu_device_dt_probe(struct platform_device *pdev)
> +static int arm_smmu_device_dt_probe(struct platform_device *pdev,
> + struct arm_smmu_device *smmu,
> + bool *bypass)
> {
> - int irq, ret;
> - struct resource *res;
> - struct arm_smmu_device *smmu;
> struct device *dev = &pdev->dev;
> - bool bypass = true;
> u32 cells;
>
> + *bypass = true;
> +
> if (of_property_read_u32(dev->of_node, "#iommu-cells", &cells))
> dev_err(dev, "missing #iommu-cells property\n");
> else if (cells != 1)
> dev_err(dev, "invalid #iommu-cells value (%d)\n", cells);
> else
> - bypass = false;
> + *bypass = false;
> +
> + parse_driver_options(smmu);
> +
> + if (of_dma_is_coherent(dev->of_node))
> + smmu->features |= ARM_SMMU_FEAT_COHERENCY;
> +
> + return 0;
I know you're only moving code here, but the *bypass output parameter
now seems to be redundant with the unconditional return 0. Given that
we only set bypass to true if something went wrong, why don't we return
-ENODEV in those cases, kill the bypass parameter and rework the return
value check in the caller so that, rather than fail the probe, we pass
bypass=true to the reset function?
Will
^ permalink raw reply
* [PATCH v8 11/16] drivers: iommu: arm-smmu-v3: add IORT configuration
From: Will Deacon @ 2016-11-18 15:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161116152936.22955-12-lorenzo.pieralisi@arm.com>
On Wed, Nov 16, 2016 at 03:29:31PM +0000, Lorenzo Pieralisi wrote:
> In ACPI bases systems, in order to be able to create platform
> devices and initialize them for ARM SMMU v3 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 v3 components.
>
> Add static configuration functions to the IORT kernel layer for
> the ARM SMMU v3 components, so that the ARM SMMU v3 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 | 103 +++++++++++++++++++++++++++++++++++++++++++-
> drivers/iommu/arm-smmu-v3.c | 49 ++++++++++++++++++++-
> 2 files changed, 150 insertions(+), 2 deletions(-)
[...]
> diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c
> index ed563307..9315bf3 100644
> --- a/drivers/iommu/arm-smmu-v3.c
> +++ b/drivers/iommu/arm-smmu-v3.c
> @@ -20,6 +20,8 @@
> * This driver is powered by bad coffee and bombay mix.
> */
>
> +#include <linux/acpi.h>
> +#include <linux/acpi_iort.h>
> #include <linux/delay.h>
> #include <linux/dma-iommu.h>
> #include <linux/err.h>
> @@ -2559,6 +2561,36 @@ static int arm_smmu_device_hw_probe(struct arm_smmu_device *smmu)
> return 0;
> }
>
> +#ifdef CONFIG_ACPI
> +static int arm_smmu_device_acpi_probe(struct platform_device *pdev,
> + struct arm_smmu_device *smmu,
> + bool *bypass)
> +{
> + struct acpi_iort_smmu_v3 *iort_smmu;
> + struct device *dev = smmu->dev;
> + struct acpi_iort_node *node;
> +
> + node = *(struct acpi_iort_node **)dev_get_platdata(dev);
> +
> + /* Retrieve SMMUv3 specific data */
> + iort_smmu = (struct acpi_iort_smmu_v3 *)node->node_data;
> +
> + if (iort_smmu->flags & ACPI_IORT_SMMU_V3_COHACC_OVERRIDE)
> + smmu->features |= ARM_SMMU_FEAT_COHERENCY;
> +
> + *bypass = false;
> +
> + return 0;
> +}
> +#else
> +static inline int arm_smmu_device_acpi_probe(struct platform_device *pdev,
> + struct arm_smmu_device *smmu,
> + bool *bypass)
> +{
> + return -ENODEV;
> +}
> +#endif
Same bypass comments as before, but you'll probably need to do something
so that you *can* abort the probe if !ACPI, perhaps by allocating two
error codes to distinguish the "I no nothing about this SMMU" from "I know
enough to put it into bypass, but nothing more".
Will
^ permalink raw reply
* [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
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