* [PATCH 1/2] ARM: dts: imx6qdl-nitrogen6_max: fix sgtl5000 pinctrl init
From: Gary Bisson @ 2017-01-03 11:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170103114316.GC20956@dragon>
Hi Shawn,
On Tue, Jan 03, 2017 at 07:43:17PM +0800, Shawn Guo wrote:
> On Tue, Jan 03, 2017 at 12:22:46PM +0100, Gary Bisson wrote:
> > This patch fixes the following error:
> > sgtl5000 0-000a: Error reading chip id -6
> > imx-sgtl5000 sound: ASoC: CODEC DAI sgtl5000 not registered
> > imx-sgtl5000 sound: snd_soc_register_card failed (-517)
> >
> > The problem was that the pinctrl group was linked to the sound driver
> > instead of the codec node. Since the codec is probed first, the sys_mclk
> > was missing and it would therefore fail to initialize.
> >
> > Signed-off-by: Gary Bisson <gary.bisson@boundarydevices.com>
>
> Should we have it go as a fix for v4.10-rc cycles? In that case, please
> add a Fixes: tag. Also, do we need to apply it for stable kernel?
Sure it'd be great if it could be in v4.10.
Fixes: b32e700256bc ("ARM: dts: imx: add Boundary Devices Nitrogen6_Max board")
As for stable kernel, I guess it wouldn't hurt but it's not mandatory in
my opinion.
Do you want me to re-send with the Fixes line? What about the SOM2
patch, should it include a Fixes line although it works thanks to
U-Boot?
Thanks,
Gary
^ permalink raw reply
* [PATCH 3/4] arm64: dts: exynos: make tm2 and tm2e independent from each other
From: Andi Shyti @ 2017-01-03 11:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGTfZH3ez4DPTE7-bDeayjhSGxJ_8Mj1MQz1M7O1qhwOGOnmMQ@mail.gmail.com>
Hi Chanwoo,
> >> >> > Currently tm2e dts includes tm2 but there are some differences
> >> >> > between the two boards and tm2 has some properties that tm2e
> >> >> > doesn't have.
> >> >> >
> >> >> > That's why it's important to keep the two dts files independent
> >> >> > and put all the commonalities in a tm2-common.dtsi file.
> >> >> >
> >> >> > Signed-off-by: Andi Shyti <andi.shyti@samsung.com>
> >> >> > Signed-off-by: Jaechul Lee <jcsing.lee@samsung.com>
> >> >> > ---
> >> >> > .../boot/dts/exynos/exynos5433-tm2-common.dtsi | 1046 ++++++++++++++++++++
> >> >> > arch/arm64/boot/dts/exynos/exynos5433-tm2.dts | 1033 +------------------
> >> >> > arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts | 2 +-
> >> >> > 3 files changed, 1049 insertions(+), 1032 deletions(-)
> >> >> > create mode 100644 arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
> >> >>
[...]
> > Because exynos5433-tm2.dts results modified, while
> > exynos5433-tm2-common.dtsi is new. Even though I did:
> >
> > 1. mv exynos5433-tm2.dts exynos5433-tm2-common.dtsi
> > 2. copied pieces from exynos5433-tm2-common.dtsi to a new
> > exynos5433-tm2.dts
>
> I think that exynos5433-tm2-common.dtsi is not necessary because there
> is small difference between TM2 and TM2E.
>
> I explain the detailed difference between TM2 and TM2E and then reply
> how to support the TM2E board with existing exynos5433-tm2.dts file
> without exynos5433-tm2-common.dtsi.
>
> Difference and the way to support TM2E with existing
> exynos5433-tm2.dts file as following:
> - hsi2c_9 is either used or not. TM2 uses the hsi2c_9 node for
> touchkey. but TM2E do not use the hsi2c_9.
> : We can just disable the hsi2c_9 node on tm2e.dts as following:
>
> &hsi2c_9 {
> status = "disable";
> };
I thought about this alternative too, it just looked cleaner to
me to have a tm2-common.dtsi file.
Anyway, as you guys wish. If for you and Krzysztof is better this
way, we can drop this patch and add the above lines in the current
Jaechul's patch 4/4.
Thanks,
Andi
^ permalink raw reply
* [PATCH 3/4] arm64: dts: exynos: make tm2 and tm2e independent from each other
From: Chanwoo Choi @ 2017-01-03 11:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170103102548.73jg6qddlcthe2mu@gangnam.samsung>
Dear all,
2017-01-03 19:25 GMT+09:00 Andi Shyti <andi.shyti@samsung.com>:
>> >> > Currently tm2e dts includes tm2 but there are some differences
>> >> > between the two boards and tm2 has some properties that tm2e
>> >> > doesn't have.
>> >> >
>> >> > That's why it's important to keep the two dts files independent
>> >> > and put all the commonalities in a tm2-common.dtsi file.
>> >> >
>> >> > Signed-off-by: Andi Shyti <andi.shyti@samsung.com>
>> >> > Signed-off-by: Jaechul Lee <jcsing.lee@samsung.com>
>> >> > ---
>> >> > .../boot/dts/exynos/exynos5433-tm2-common.dtsi | 1046 ++++++++++++++++++++
>> >> > arch/arm64/boot/dts/exynos/exynos5433-tm2.dts | 1033 +------------------
>> >> > arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts | 2 +-
>> >> > 3 files changed, 1049 insertions(+), 1032 deletions(-)
>> >> > create mode 100644 arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
>> >>
>> >> I would like to see here the rename and diff from it. Not entire delta
>> >> (deletions and addons). It is not possible to compare it... I think
>> >> git supports it by default with similarity of 50%.
>> >
>> > I understand, it's indeed quite cryptic to understand. But all
>> > the diff algorithms (patience, minimal, histogram, myers) give
>> > the same result. I don't know how to make it better.
>> >
>> > I could split this patch, but this also means breaking tm2's
>> > functionality, which looks worse.
>> >
>> > Please tell me if you know a better way for generating the patch.
>>
>> git format-patch -M95%?
>
> Same thing with all M values.
>
> Because exynos5433-tm2.dts results modified, while
> exynos5433-tm2-common.dtsi is new. Even though I did:
>
> 1. mv exynos5433-tm2.dts exynos5433-tm2-common.dtsi
> 2. copied pieces from exynos5433-tm2-common.dtsi to a new
> exynos5433-tm2.dts
I think that exynos5433-tm2-common.dtsi is not necessary because there
is small difference between TM2 and TM2E.
I explain the detailed difference between TM2 and TM2E and then reply
how to support the TM2E board with existing exynos5433-tm2.dts file
without exynos5433-tm2-common.dtsi.
Difference and the way to support TM2E with existing
exynos5433-tm2.dts file as following:
- hsi2c_9 is either used or not. TM2 uses the hsi2c_9 node for
touchkey. but TM2E do not use the hsi2c_9.
: We can just disable the hsi2c_9 node on tm2e.dts as following:
&hsi2c_9 {
status = "disable";
};
- The difference name and voltage of regulators.
: Already modified on tm2e.dts.
- The size of touchscreen between tm2 and tm2e ('x-size', 'y-size')
: We can update the x/y size on tm2e.dts.
- The timing value of display-timing between tm2 and tm2e
('clock-frequency', 'hactive')
: We can update the 'clock-frequency' and 'hactive' on tm2e.dts.
--
Best Regards,
Chanwoo Choi
^ permalink raw reply
* [PATCH v2 2/2] mtd: nand: Update dependency of IFC for LS1021A
From: Marek Vasut @ 2017-01-03 11:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483411266-45875-2-git-send-email-b18965@freescale.com>
On 01/03/2017 03:41 AM, Alison Wang wrote:
> As NAND support for Freescale/NXP IFC controller is available on
> LS1021A, the dependency for LS1021A is added.
Does LS stand for LayerScape ? Yes it does. So why does ARCH_LAYERSCAPE
not cover LS1021 ?
> Signed-off-by: Alison Wang <alison.wang@nxp.com>
> ---
> Changes in v2:
> - None
>
> drivers/mtd/nand/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
> index 353a9dd..85e3860 100644
> --- a/drivers/mtd/nand/Kconfig
> +++ b/drivers/mtd/nand/Kconfig
> @@ -441,7 +441,7 @@ config MTD_NAND_FSL_ELBC
>
> config MTD_NAND_FSL_IFC
> tristate "NAND support for Freescale IFC controller"
> - depends on FSL_SOC || ARCH_LAYERSCAPE
> + depends on FSL_SOC || ARCH_LAYERSCAPE || SOC_LS1021A
> select FSL_IFC
> select MEMORY
> help
>
--
Best regards,
Marek Vasut
^ permalink raw reply
* [PATCH 1/2] ARM: dts: imx6qdl-nitrogen6_max: fix sgtl5000 pinctrl init
From: Shawn Guo @ 2017-01-03 11:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170103112247.4563-2-gary.bisson@boundarydevices.com>
On Tue, Jan 03, 2017 at 12:22:46PM +0100, Gary Bisson wrote:
> This patch fixes the following error:
> sgtl5000 0-000a: Error reading chip id -6
> imx-sgtl5000 sound: ASoC: CODEC DAI sgtl5000 not registered
> imx-sgtl5000 sound: snd_soc_register_card failed (-517)
>
> The problem was that the pinctrl group was linked to the sound driver
> instead of the codec node. Since the codec is probed first, the sys_mclk
> was missing and it would therefore fail to initialize.
>
> Signed-off-by: Gary Bisson <gary.bisson@boundarydevices.com>
Should we have it go as a fix for v4.10-rc cycles? In that case, please
add a Fixes: tag. Also, do we need to apply it for stable kernel?
Shawn
> ---
> arch/arm/boot/dts/imx6qdl-nitrogen6_max.dtsi | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/boot/dts/imx6qdl-nitrogen6_max.dtsi b/arch/arm/boot/dts/imx6qdl-nitrogen6_max.dtsi
> index 34887a10c5f1..47ba97229a48 100644
> --- a/arch/arm/boot/dts/imx6qdl-nitrogen6_max.dtsi
> +++ b/arch/arm/boot/dts/imx6qdl-nitrogen6_max.dtsi
> @@ -319,8 +319,6 @@
> compatible = "fsl,imx6q-nitrogen6_max-sgtl5000",
> "fsl,imx-audio-sgtl5000";
> model = "imx6q-nitrogen6_max-sgtl5000";
> - pinctrl-names = "default";
> - pinctrl-0 = <&pinctrl_sgtl5000>;
> ssi-controller = <&ssi1>;
> audio-codec = <&codec>;
> audio-routing =
> @@ -402,6 +400,8 @@
>
> codec: sgtl5000 at 0a {
> compatible = "fsl,sgtl5000";
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_sgtl5000>;
> reg = <0x0a>;
> clocks = <&clks IMX6QDL_CLK_CKO>;
> VDDA-supply = <®_2p5v>;
> --
> 2.11.0
>
^ permalink raw reply
* [PATCH 1/2] arm64: setup: introduce kaslr_offset()
From: Will Deacon @ 2017-01-03 11:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <db9266fb-5c6e-5dfb-2aac-4165c6b2b337@nvidia.com>
On Tue, Jan 03, 2017 at 11:18:15AM +0000, Jon Hunter wrote:
> On 22/12/16 12:51, Alexander Popov wrote:
> > On 22.12.2016 09:18, Yury Norov wrote:
> >> On Sun, Dec 11, 2016 at 03:50:55AM +0300, Alexander Popov wrote:
> >>> Introduce kaslr_offset() similarly to x86_64 for fixing kcov.
> >
> > [...]
> >
> >> Hi Alexander,
> >>
> >> I found today's linux-next master broken:
> >
> > [...]
> >
> >> It looks like you declare kaslr_offset() twice - in this patch, and in 7ede8665f
> >> (arm64: setup: introduce kaslr_offset()).
> >
> > Hello Yury,
> >
> > There was a race during applying this patch. So currently linux-next has 2 versions of it.
> >
> > The first one is 1a339a14b1f2c7a0dfdd6db79eee1e55d3cec357, which is original.
> > The second one is 7ede8665f27cde7da69e8b2fbeaa1ed0664879c5, updated by Will Deacon and
> > applied to the mainline.
> >
> > I'm sorry for that. The first one should be definitely dropped.
>
> Looks like this is still broken in today's -next.
I think this is coming in via akpm's tree, so there's nothing we can do
about it from the arm64 side :/
Andrew -- please can you drop 1a339a14b1f2 ("arm64: setup: introduce
kaslr_offset()") from your -next branch? It's superceded by
7ede8665f27c ("arm64: setup: introduce kaslr_offset()"), which landed
in mainline for -rc1, so you'll need to pick that up if you want your
branch to build on its own.
Thanks,
Will
^ permalink raw reply
* [PATCH v4 1/3] soc: zte: pm_domains: Prepare for supporting ARMv8 zx2967 family
From: Shawn Guo @ 2017-01-03 11:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483426577-5470-1-git-send-email-baoyou.xie@linaro.org>
On Tue, Jan 03, 2017 at 02:56:15PM +0800, Baoyou Xie wrote:
> The ARMv8 zx2967 family (296718, 296716 etc) uses different value
> for controlling the power domain on/off registers, Choose the
> value depending on the compatible.
>
> Multiple domains are prepared for the family, this patch prepares
> the common functions.
>
> Signed-off-by: Baoyou Xie <baoyou.xie@linaro.org>
> ---
> drivers/soc/Kconfig | 1 +
> drivers/soc/Makefile | 1 +
> drivers/soc/zte/Kconfig | 13 ++++
> drivers/soc/zte/Makefile | 4 ++
> drivers/soc/zte/zx2967_pm_domains.c | 138 ++++++++++++++++++++++++++++++++++++
> drivers/soc/zte/zx2967_pm_domains.h | 45 ++++++++++++
> 6 files changed, 202 insertions(+)
> create mode 100644 drivers/soc/zte/Kconfig
> create mode 100644 drivers/soc/zte/Makefile
> create mode 100644 drivers/soc/zte/zx2967_pm_domains.c
> create mode 100644 drivers/soc/zte/zx2967_pm_domains.h
>
> diff --git a/drivers/soc/Kconfig b/drivers/soc/Kconfig
> index f31bceb..f09023f 100644
> --- a/drivers/soc/Kconfig
> +++ b/drivers/soc/Kconfig
> @@ -11,5 +11,6 @@ source "drivers/soc/tegra/Kconfig"
> source "drivers/soc/ti/Kconfig"
> source "drivers/soc/ux500/Kconfig"
> source "drivers/soc/versatile/Kconfig"
> +source "drivers/soc/zte/Kconfig"
>
> endmenu
> diff --git a/drivers/soc/Makefile b/drivers/soc/Makefile
> index 50c23d0..05eae52 100644
> --- a/drivers/soc/Makefile
> +++ b/drivers/soc/Makefile
> @@ -16,3 +16,4 @@ obj-$(CONFIG_ARCH_TEGRA) += tegra/
> obj-$(CONFIG_SOC_TI) += ti/
> obj-$(CONFIG_ARCH_U8500) += ux500/
> obj-$(CONFIG_PLAT_VERSATILE) += versatile/
> +obj-$(CONFIG_ARCH_ZX) += zte/
> diff --git a/drivers/soc/zte/Kconfig b/drivers/soc/zte/Kconfig
> new file mode 100644
> index 0000000..20bde38
> --- /dev/null
> +++ b/drivers/soc/zte/Kconfig
> @@ -0,0 +1,13 @@
> +#
> +# ZTE SoC drivers
> +#
> +menuconfig SOC_ZTE
> + bool "ZTE SoC driver support"
> +
> +if SOC_ZTE
> +
> +config ZX2967_PM_DOMAINS
> + bool "ZX2967 PM domains"
> + depends on PM_GENERIC_DOMAINS
> +
> +endif
> diff --git a/drivers/soc/zte/Makefile b/drivers/soc/zte/Makefile
> new file mode 100644
> index 0000000..8a37f2f
> --- /dev/null
> +++ b/drivers/soc/zte/Makefile
> @@ -0,0 +1,4 @@
> +#
> +# ZTE SOC drivers
> +#
> +obj-$(CONFIG_ZX2967_PM_DOMAINS) += zx2967_pm_domains.o
> diff --git a/drivers/soc/zte/zx2967_pm_domains.c b/drivers/soc/zte/zx2967_pm_domains.c
> new file mode 100644
> index 0000000..98b3b5f
> --- /dev/null
> +++ b/drivers/soc/zte/zx2967_pm_domains.c
> @@ -0,0 +1,138 @@
> +/*
> + * Copyright (C) 2015 ZTE Ltd.
What about year 2017?
> + *
> + * Author: Baoyou Xie <baoyou.xie@linaro.org>
> + * License terms: GNU General Public License (GPL) version 2
> + */
> +#include <linux/delay.h>
> +#include <linux/err.h>
> +#include <linux/io.h>
> +#include <linux/of.h>
Can we have a newline between system and local includes?
> +#include "zx2967_pm_domains.h"
> +
> +#define PCU_DM_CLKEN(zpd) ((zpd)->reg_offset[REG_CLKEN])
> +#define PCU_DM_ISOEN(zpd) ((zpd)->reg_offset[REG_ISOEN])
> +#define PCU_DM_RSTEN(zpd) ((zpd)->reg_offset[REG_RSTEN])
> +#define PCU_DM_PWREN(zpd) ((zpd)->reg_offset[REG_PWREN])
> +#define PCU_DM_PWRDN(zpd) ((zpd)->reg_offset[REG_PWRDN])
> +#define PCU_DM_ACK_SYNC(zpd) ((zpd)->reg_offset[REG_ACK_SYNC])
> +
> +static void __iomem *pcubase;
> +
> +int zx2967_power_on(struct generic_pm_domain *domain)
> +{
> + struct zx2967_pm_domain *zpd = (struct zx2967_pm_domain *)domain;
> + unsigned long loop = 1000;
> + u32 val;
> +
> + val = readl_relaxed(pcubase + PCU_DM_PWREN(zpd));
> + if (zpd->polarity == PWREN)
> + val |= BIT(zpd->bit);
> + else
> + val &= ~BIT(zpd->bit);
> + writel_relaxed(val, pcubase + PCU_DM_PWRDN(zpd));
Hmm, do you really want to read val from PCU_DM_PWREN and then write
back to PCU_DM_PWRDN? They are two different registers or same one? A
bit confused here.
> +
> + do {
> + udelay(1);
> + val = readl_relaxed(pcubase + PCU_DM_ACK_SYNC(zpd))
> + & BIT(zpd->bit);
> + } while (--loop && !val);
> +
> + if (!loop) {
> + pr_err("Error: %s %s fail\n", __func__, domain->name);
> + return -EIO;
> + }
> +
> + val = readl_relaxed(pcubase + PCU_DM_RSTEN(zpd));
> + val |= BIT(zpd->bit);
> + writel_relaxed(val, pcubase + PCU_DM_RSTEN(zpd));
> + udelay(5);
> +
> + val = readl_relaxed(pcubase + PCU_DM_ISOEN(zpd));
> + val &= ~BIT(zpd->bit);
> + writel_relaxed(val, pcubase + PCU_DM_ISOEN(zpd));
> + udelay(5);
> +
> + val = readl_relaxed(pcubase + PCU_DM_CLKEN(zpd));
> + val |= BIT(zpd->bit);
> + writel_relaxed(val, pcubase + PCU_DM_CLKEN(zpd));
> + udelay(5);
> +
> + pr_debug("normal poweron %s\n", domain->name);
> +
> + return 0;
> +}
> +
> +int zx2967_power_off(struct generic_pm_domain *domain)
> +{
> + struct zx2967_pm_domain *zpd = (struct zx2967_pm_domain *)domain;
> + unsigned long loop = 1000;
> + u32 val;
> +
> + val = readl_relaxed(pcubase + PCU_DM_CLKEN(zpd));
> + val &= ~BIT(zpd->bit);
> + writel_relaxed(val, pcubase + PCU_DM_CLKEN(zpd));
> + udelay(5);
> +
> + val = readl_relaxed(pcubase + PCU_DM_ISOEN(zpd));
> + val |= BIT(zpd->bit);
> + writel_relaxed(val, pcubase + PCU_DM_ISOEN(zpd));
> + udelay(5);
> +
> + val = readl_relaxed(pcubase + PCU_DM_RSTEN(zpd));
> + val &= ~BIT(zpd->bit);
> + writel_relaxed(val, pcubase + PCU_DM_RSTEN(zpd));
> + udelay(5);
> +
> + val = readl_relaxed(pcubase + PCU_DM_PWREN(zpd));
> + if (zpd->polarity == PWREN)
> + val &= ~BIT(zpd->bit);
> + else
> + val |= BIT(zpd->bit);
> + writel_relaxed(val, pcubase + PCU_DM_PWRDN(zpd));
Ditto
> +
> + do {
> + udelay(1);
> + val = readl_relaxed(pcubase + PCU_DM_ACK_SYNC(zpd))
> + & BIT(zpd->bit);
> + } while (--loop && val);
> +
> + if (!loop) {
> + pr_err("Error: %s %s fail\n", __func__, domain->name);
> + return -EIO;
> + }
> +
> + pr_debug("normal poweroff %s\n", domain->name);
> +
> + return 0;
> +}
> +
> +int zx2967_pd_probe(struct platform_device *pdev,
> + struct generic_pm_domain **zx_pm_domains,
> + int domain_num)
Please fix the indentation as below.
int zx2967_pd_probe(struct platform_device *pdev,
struct generic_pm_domain **zx_pm_domains,
int domain_num)
> +{
> + struct genpd_onecell_data *genpd_data;
> + struct resource *res;
> + int i;
> +
> + genpd_data = devm_kzalloc(&pdev->dev, sizeof(*genpd_data), GFP_KERNEL);
> + if (!genpd_data)
> + return -ENOMEM;
> +
> + genpd_data->domains = zx_pm_domains;
> + genpd_data->num_domains = domain_num;
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + pcubase = devm_ioremap_resource(&pdev->dev, res);
> + if (IS_ERR(pcubase)) {
> + dev_err(&pdev->dev, "ioremap fail.\n");
> + return PTR_ERR(pcubase);
> + }
> +
> + for (i = 0; i < domain_num; ++i)
> + pm_genpd_init(zx_pm_domains[i], NULL, false);
> +
> + of_genpd_add_provider_onecell(pdev->dev.of_node, genpd_data);
> + dev_info(&pdev->dev, "powerdomain init ok\n");
> + return 0;
> +}
> diff --git a/drivers/soc/zte/zx2967_pm_domains.h b/drivers/soc/zte/zx2967_pm_domains.h
> new file mode 100644
> index 0000000..35938c3
> --- /dev/null
> +++ b/drivers/soc/zte/zx2967_pm_domains.h
> @@ -0,0 +1,45 @@
> +/*
> + * Header for ZTE's Power Domain Driver support
> + *
> + * Copyright (C) 2015 ZTE Ltd.
> + *
> + * Author: Baoyou Xie <baoyou.xie@linaro.org>
> + * License terms: GNU General Public License (GPL) version 2
> + */
> +
> +#ifndef __ZTE_ZX2967_PM_DOMAIN_H
> +#define __ZTE_ZX2967_PM_DOMAIN_H
> +
> +#include <linux/platform_device.h>
> +#include <linux/pm_domain.h>
> +
> +enum {
> + REG_CLKEN,
> + REG_ISOEN,
> + REG_RSTEN,
> + REG_PWREN,
> + REG_PWRDN,
> + REG_ACK_SYNC,
> +
> + /* The size of the array - must be last */
> + REG_ARRAY_SIZE,
> +};
> +
> +enum zx2967_power_polarity {
> + PWREN,
> + PWRDN,
> +};
> +
> +struct zx2967_pm_domain {
> + struct generic_pm_domain dm;
> + const u16 bit;
> + const enum zx2967_power_polarity polarity;
> + const u16 *reg_offset;
> +};
> +
> +extern int zx2967_power_on(struct generic_pm_domain *domain);
> +extern int zx2967_power_off(struct generic_pm_domain *domain);
> +extern int zx2967_pd_probe(struct platform_device *pdev,
> + struct generic_pm_domain **zx_pm_domains,
> + int domain_num);
Have a newline here.
Shawn
> +#endif /* __ZTE_ZX2967_PM_DOMAIN_H */
> --
> 2.7.4
>
^ permalink raw reply
* [PATCH v6 05/14] ACPI: platform-msi: retrieve dev id from IORT
From: Tomasz Nowicki @ 2017-01-03 11:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4ab6a7e3-7aa3-367d-a333-effb24399fd5@semihalf.com>
On 03.01.2017 10:37, Tomasz Nowicki wrote:
> On 03.01.2017 09:43, Tomasz Nowicki wrote:
>> On 02.01.2017 14:31, Hanjun Guo wrote:
>>> For devices connecting to ITS, it needs dev id to identify
>>> itself, and this dev id is represented in the IORT table in
>>> named componant node [1] for platform devices, so in this
>>> patch we will scan the IORT to retrieve device's dev id.
>>>
>>> Introduce iort_pmsi_get_dev_id() with pointer dev passed
>>> in for that purpose.
>>>
>>> [1]:
>>> https://static.docs.arm.com/den0049/b/DEN0049B_IO_Remapping_Table.pdf
>>>
>>> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
>>> Tested-by: Sinan Kaya <okaya@codeaurora.org>
>>> Tested-by: Majun <majun258@huawei.com>
>>> Tested-by: Xinwei Kong <kong.kongxinwei@hisilicon.com>
>>> Cc: Marc Zyngier <marc.zyngier@arm.com>
>>> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
>>> Cc: Tomasz Nowicki <tn@semihalf.com>
>>> Cc: Thomas Gleixner <tglx@linutronix.de>
>>> ---
>>> drivers/acpi/arm64/iort.c | 26
>>> ++++++++++++++++++++++++++
>>> drivers/irqchip/irq-gic-v3-its-platform-msi.c | 4 +++-
>>> include/linux/acpi_iort.h | 8 ++++++++
>>> 3 files changed, 37 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
>>> index 174e983..ab7bae7 100644
>>> --- a/drivers/acpi/arm64/iort.c
>>> +++ b/drivers/acpi/arm64/iort.c
>>> @@ -444,6 +444,32 @@ u32 iort_msi_map_rid(struct device *dev, u32
>>> req_id)
>>> }
>>>
>>> /**
>>> + * iort_pmsi_get_dev_id() - Get the device id for a device
>>> + * @dev: The device for which the mapping is to be done.
>>> + * @dev_id: The device ID found.
>>> + *
>>> + * Returns: 0 for successful find a dev id, errors otherwise
>>> + */
>>> +int iort_pmsi_get_dev_id(struct device *dev, u32 *dev_id)
>>> +{
>>> + struct acpi_iort_node *node;
>>> +
>>> + if (!iort_table)
>>> + return -ENODEV;
>>> +
>>> + node = iort_find_dev_node(dev);
>>> + if (!node) {
>>> + dev_err(dev, "can't find related IORT node\n");
>>> + return -ENODEV;
>>> + }
>>> +
>>> + if(!iort_node_get_id(node, dev_id, IORT_MSI_TYPE, 0))
>>> + return -ENODEV;
>>> +
>>> + return 0;
>>> +}
>>> +
>>> +/**
>> Giving that you are extending this to NC->
>> SMMU->ITS case in later patch, we can use existing helpers from iort.c,
>> like that:
>>
>> +/**
>> + * iort_pmsi_get_dev_id() - Get the device id for a device
>> + * @dev: The device for which the mapping is to be done.
>> + * @dev_id: The device ID found.
>> + *
>> + * Returns: 0 for successful find a dev id, errors otherwise
>> + */
>> +int iort_pmsi_get_dev_id(struct device *dev, u32 *dev_id)
>> +{
>> + struct acpi_iort_node *node;
>> +
>> + node = iort_find_dev_node(dev);
>> + if (!node)
>> + return -ENODEV;
>> +
>> + if (!iort_node_map_rid(node, 0, dev_id, IORT_MSI_TYPE))
>> + return -ENODEV;
>> +
>> + return 0;
>> +}
>>
>> Correct me if I am wrong.
>>
>
> "0" as rid_in for iort_node_map_rid() isn't good idea, sorry...
>
I refactored iort_node_map_rid() and added new
iort_node_map_single_rid() which should works for you. Below patch bases
on v4.10-rc2:
diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
index e0d2e6e..2526b89 100644
--- a/drivers/acpi/arm64/iort.c
+++ b/drivers/acpi/arm64/iort.c
@@ -297,8 +297,17 @@ static acpi_status iort_match_node_callback(struct
acpi_iort_node *node,
}
static int iort_id_map(struct acpi_iort_id_mapping *map, u8 type, u32
rid_in,
- u32 *rid_out)
+ u32 *rid_out, bool single)
{
+ if (!single) {
+ if (rid_in < map->input_base ||
+ (rid_in >= map->input_base + map->id_count))
+ return -ENXIO;
+
+ *rid_out = map->output_base + (rid_in - map->input_base);
+ return 0;
+ }
+
/* Single mapping does not care for input id */
if (map->flags & ACPI_IORT_ID_SINGLE_MAPPING) {
if (type == ACPI_IORT_NODE_NAMED_COMPONENT ||
@@ -309,15 +318,9 @@ static int iort_id_map(struct acpi_iort_id_mapping
*map, u8 type, u32 rid_in,
pr_warn(FW_BUG "[map %p] SINGLE MAPPING flag not allowed for node
type %d, skipping ID map\n",
map, type);
- return -ENXIO;
}
- if (rid_in < map->input_base ||
- (rid_in >= map->input_base + map->id_count))
- return -ENXIO;
-
- *rid_out = map->output_base + (rid_in - map->input_base);
- return 0;
+ return -ENXIO;
}
static
@@ -359,6 +362,38 @@ struct acpi_iort_node *iort_node_get_id(struct
acpi_iort_node *node,
return NULL;
}
+static struct acpi_iort_node *iort_node_map_rid_one(struct
acpi_iort_node *node,
+ u32 *rid, bool single)
+{
+ struct acpi_iort_id_mapping *map;
+ struct acpi_iort_node *next;
+ int i;
+
+ if (!node->mapping_offset || !node->mapping_count)
+ return NULL;
+
+ map = ACPI_ADD_PTR(struct acpi_iort_id_mapping, node,
+ node->mapping_offset);
+
+ /* Firmware bug! */
+ if (!map->output_reference) {
+ pr_err(FW_BUG "[node %p type %d] ID map has NULL parent reference\n",
+ node, node->type);
+ return NULL;
+ }
+
+ next = ACPI_ADD_PTR(struct acpi_iort_node, iort_table,
+ map->output_reference);
+
+ /* Do the RID translation */
+ for (i = 0; i < node->mapping_count; i++, map++) {
+ if (!iort_id_map(map, node->type, *rid, rid, single))
+ return next;
+ }
+
+ return NULL;
+}
+
static struct acpi_iort_node *iort_node_map_rid(struct acpi_iort_node
*node,
u32 rid_in, u32 *rid_out,
u8 type_mask)
@@ -367,42 +402,15 @@ static struct acpi_iort_node
*iort_node_map_rid(struct acpi_iort_node *node,
/* Parse the ID mapping tree to find specified node type */
while (node) {
- struct acpi_iort_id_mapping *map;
- int i;
-
if (IORT_TYPE_MASK(node->type) & type_mask) {
if (rid_out)
*rid_out = rid;
return node;
}
- if (!node->mapping_offset || !node->mapping_count)
- goto fail_map;
-
- map = ACPI_ADD_PTR(struct acpi_iort_id_mapping, node,
- node->mapping_offset);
-
- /* Firmware bug! */
- if (!map->output_reference) {
- pr_err(FW_BUG "[node %p type %d] ID map has NULL parent reference\n",
- node, node->type);
- goto fail_map;
- }
-
- /* Do the RID translation */
- for (i = 0; i < node->mapping_count; i++, map++) {
- if (!iort_id_map(map, node->type, rid, &rid))
- break;
- }
-
- if (i == node->mapping_count)
- goto fail_map;
-
- node = ACPI_ADD_PTR(struct acpi_iort_node, iort_table,
- map->output_reference);
+ node = iort_node_map_rid_one(node, &rid, false);
}
-fail_map:
/* Map input RID to output RID unchanged on mapping failure*/
if (rid_out)
*rid_out = rid_in;
@@ -410,6 +418,20 @@ static struct acpi_iort_node
*iort_node_map_rid(struct acpi_iort_node *node,
return NULL;
}
+static struct acpi_iort_node *iort_node_map_single_rid(
+ struct acpi_iort_node *node,
+ u32 *rid_out, u8 type_mask)
+{
+ u32 rid;
+
+ /* Get the initial rid */
+ node = iort_node_map_rid_one(node, &rid, true);
+ if (!node)
+ return NULL;
+
+ return iort_node_map_rid(node, rid, rid_out, type_mask);
+}
+
static struct acpi_iort_node *iort_find_dev_node(struct device *dev)
{
struct pci_bus *pbus;
^ permalink raw reply related
* [PATCH 2/2] ARM: dts: imx6qdl-nitrogen6_som2: fix sgtl5000 pinctrl init
From: Gary Bisson @ 2017-01-03 11:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170103112247.4563-1-gary.bisson@boundarydevices.com>
Since the codec is probed first, the pinctrl node should be
under the codec node.
The codec init was working for this board since U-Boot was
already setting GPIO_0 as CLKO1 but better fix it anyway.
Signed-off-by: Gary Bisson <gary.bisson@boundarydevices.com>
---
arch/arm/boot/dts/imx6qdl-nitrogen6_som2.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/imx6qdl-nitrogen6_som2.dtsi b/arch/arm/boot/dts/imx6qdl-nitrogen6_som2.dtsi
index d80f21abea62..31d4cc62dbc7 100644
--- a/arch/arm/boot/dts/imx6qdl-nitrogen6_som2.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-nitrogen6_som2.dtsi
@@ -250,8 +250,6 @@
compatible = "fsl,imx6q-nitrogen6_som2-sgtl5000",
"fsl,imx-audio-sgtl5000";
model = "imx6q-nitrogen6_som2-sgtl5000";
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_sgtl5000>;
ssi-controller = <&ssi1>;
audio-codec = <&codec>;
audio-routing =
@@ -320,6 +318,8 @@
codec: sgtl5000 at 0a {
compatible = "fsl,sgtl5000";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_sgtl5000>;
reg = <0x0a>;
clocks = <&clks IMX6QDL_CLK_CKO>;
VDDA-supply = <®_2p5v>;
--
2.11.0
^ permalink raw reply related
* [PATCH 1/2] ARM: dts: imx6qdl-nitrogen6_max: fix sgtl5000 pinctrl init
From: Gary Bisson @ 2017-01-03 11:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170103112247.4563-1-gary.bisson@boundarydevices.com>
This patch fixes the following error:
sgtl5000 0-000a: Error reading chip id -6
imx-sgtl5000 sound: ASoC: CODEC DAI sgtl5000 not registered
imx-sgtl5000 sound: snd_soc_register_card failed (-517)
The problem was that the pinctrl group was linked to the sound driver
instead of the codec node. Since the codec is probed first, the sys_mclk
was missing and it would therefore fail to initialize.
Signed-off-by: Gary Bisson <gary.bisson@boundarydevices.com>
---
arch/arm/boot/dts/imx6qdl-nitrogen6_max.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/imx6qdl-nitrogen6_max.dtsi b/arch/arm/boot/dts/imx6qdl-nitrogen6_max.dtsi
index 34887a10c5f1..47ba97229a48 100644
--- a/arch/arm/boot/dts/imx6qdl-nitrogen6_max.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-nitrogen6_max.dtsi
@@ -319,8 +319,6 @@
compatible = "fsl,imx6q-nitrogen6_max-sgtl5000",
"fsl,imx-audio-sgtl5000";
model = "imx6q-nitrogen6_max-sgtl5000";
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_sgtl5000>;
ssi-controller = <&ssi1>;
audio-codec = <&codec>;
audio-routing =
@@ -402,6 +400,8 @@
codec: sgtl5000 at 0a {
compatible = "fsl,sgtl5000";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_sgtl5000>;
reg = <0x0a>;
clocks = <&clks IMX6QDL_CLK_CKO>;
VDDA-supply = <®_2p5v>;
--
2.11.0
^ permalink raw reply related
* [PATCH 0/2] ARM: dts: boundary: fix sgtl5000 pinctrl init
From: Gary Bisson @ 2017-01-03 11:22 UTC (permalink / raw)
To: linux-arm-kernel
Hi Shawn, all,
While testing other features, I realized that the sound card wouldn't
probe on Nitrogen6_MAX. This is because the pinctrl node was under the
sound driver node whereas it should be under the codec one.
This caused GPIO_0 not to be set as CLKO1 and therefore the codec probing
was failing. The pinctrl node is just moved around to fix it.
Also making the same patch for our SOM2 although it was working, the
reason is that U-Boot is setting GPIO_0 in U-Boot for SOM2 and not MAX.
Regards,
Gary
Gary Bisson (2):
ARM: dts: imx6qdl-nitrogen6_max: fix sgtl5000 pinctrl init
ARM: dts: imx6qdl-nitrogen6_som2: fix sgtl5000 pinctrl init
arch/arm/boot/dts/imx6qdl-nitrogen6_max.dtsi | 4 ++--
arch/arm/boot/dts/imx6qdl-nitrogen6_som2.dtsi | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
--
2.11.0
^ permalink raw reply
* [PATCH] ARM: OMAP1: DMA: Correct the number of logical channels
From: Peter Ujfalusi @ 2017-01-03 11:22 UTC (permalink / raw)
To: linux-arm-kernel
OMAP1510, OMAP5910 and OMAP310 have only 9 logical channels.
OMAP1610, OMAP5912, OMAP1710, OMAP730, and OMAP850 have 16 logical channels
available.
The wired 17 for the lch_count must have been used to cover the 16 + 1
dedicated LCD channel, in reality we can only use 9 or 16 channels.
The d->chan_count is not used by the omap-dma stack, so we can skip the
setup. chan_count was configured to the number of logical channels and not
the actual number of physical channels anyways.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
---
arch/arm/mach-omap1/dma.c | 16 +++++++---------
1 file changed, 7 insertions(+), 9 deletions(-)
diff --git a/arch/arm/mach-omap1/dma.c b/arch/arm/mach-omap1/dma.c
index f6ba589cd312..c821c1d5610e 100644
--- a/arch/arm/mach-omap1/dma.c
+++ b/arch/arm/mach-omap1/dma.c
@@ -32,7 +32,6 @@
#include "soc.h"
#define OMAP1_DMA_BASE (0xfffed800)
-#define OMAP1_LOGICAL_DMA_CH_COUNT 17
static u32 enable_1510_mode;
@@ -348,8 +347,6 @@ static int __init omap1_system_dma_init(void)
goto exit_iounmap;
}
- d->lch_count = OMAP1_LOGICAL_DMA_CH_COUNT;
-
/* Valid attributes for omap1 plus processors */
if (cpu_is_omap15xx())
d->dev_caps = ENABLE_1510_MODE;
@@ -366,13 +363,14 @@ static int __init omap1_system_dma_init(void)
d->dev_caps |= CLEAR_CSR_ON_READ;
d->dev_caps |= IS_WORD_16;
- if (cpu_is_omap15xx())
- d->chan_count = 9;
- else if (cpu_is_omap16xx() || cpu_is_omap7xx()) {
- if (!(d->dev_caps & ENABLE_1510_MODE))
- d->chan_count = 16;
+ /* available logical channels */
+ if (cpu_is_omap15xx()) {
+ d->lch_count = 9;
+ } else {
+ if (d->dev_caps & ENABLE_1510_MODE)
+ d->lch_count = 9;
else
- d->chan_count = 9;
+ d->lch_count = 16;
}
p = dma_plat_info;
--
2.11.0
^ permalink raw reply related
* [arm-platforms:kvm-arm64/gicv4-wip 26/39] drivers/irqchip/irq-gic-v3-its.c:2053:3: error: implicit declaration of function 'writeq_relaxed'
From: kbuild test robot @ 2017-01-03 11:20 UTC (permalink / raw)
To: linux-arm-kernel
tree: https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git kvm-arm64/gicv4-wip
head: ff003d7a3416337cc037320bfd175aaee79f05ae
commit: 0c2bc9e2fd28b4be9bc1f4e7442e0926714994d3 [26/39] irqchip/gic-v3-its: Add VPE scheduling
config: arm-multi_v7_defconfig (attached as .config)
compiler: arm-linux-gnueabi-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 0c2bc9e2fd28b4be9bc1f4e7442e0926714994d3
# save the attached .config to linux build tree
make.cross ARCH=arm
All error/warnings (new ones prefixed by >>):
In file included from include/linux/kernel.h:10:0,
from include/linux/list.h:8,
from include/linux/resource_ext.h:17,
from include/linux/acpi.h:26,
from drivers/irqchip/irq-gic-v3-its.c:18:
drivers/irqchip/irq-gic-v3-its.c: In function 'its_vpe_set_vcpu_affinity':
>> include/linux/bitops.h:22:27: warning: right shift count is negative [-Wshift-count-negative]
(((~0UL) << (l)) & (~0UL >> (BITS_PER_LONG - 1 - (h))))
^
>> drivers/irqchip/irq-gic-v3-its.c:2049:4: note: in expansion of macro 'GENMASK'
GENMASK(51, 12);
^~~~~~~
>> drivers/irqchip/irq-gic-v3-its.c:2053:3: error: implicit declaration of function 'writeq_relaxed' [-Werror=implicit-function-declaration]
writeq_relaxed(val, gic_data_rdist_vlpi_base() + GICR_VPROPBASER);
^~~~~~~~~~~~~~
In file included from include/linux/kernel.h:10:0,
from include/linux/list.h:8,
from include/linux/resource_ext.h:17,
from include/linux/acpi.h:26,
from drivers/irqchip/irq-gic-v3-its.c:18:
>> include/linux/bitops.h:22:27: warning: right shift count is negative [-Wshift-count-negative]
(((~0UL) << (l)) & (~0UL >> (BITS_PER_LONG - 1 - (h))))
^
drivers/irqchip/irq-gic-v3-its.c:2055:54: note: in expansion of macro 'GENMASK'
val = virt_to_phys(page_address(vpe->vpt_page)) & GENMASK(51, 16);
^~~~~~~
>> drivers/irqchip/irq-gic-v3-its.c:2069:9: error: implicit declaration of function 'readq_relaxed' [-Werror=implicit-function-declaration]
val = readq_relaxed(gic_data_rdist_vlpi_base() + GICR_VPENDBASER);
^~~~~~~~~~~~~
In file included from drivers/irqchip/irq-gic-v3-its.c:38:0:
drivers/irqchip/irq-gic-v3-its.c: In function 'its_probe_one':
include/linux/irqchip/arm-gic-v3.h:308:32: warning: left shift count >= width of type [-Wshift-count-overflow]
#define GITS_TYPER_VMOVP (1UL << 37)
^
drivers/irqchip/irq-gic-v3-its.c:2416:30: note: in expansion of macro 'GITS_TYPER_VMOVP'
if (its->is_v4 && !(typer & GITS_TYPER_VMOVP)) {
^~~~~~~~~~~~~~~~
cc1: some warnings being treated as errors
vim +/writeq_relaxed +2053 drivers/irqchip/irq-gic-v3-its.c
2043
2044 switch (info->cmd_type) {
2045 case SCHEDULE_VPE:
2046 {
2047 /* Schedule the VPE */
2048 val = virt_to_phys(page_address(vpe->its_vm->vprop_page)) &
> 2049 GENMASK(51, 12);
2050 val |= (LPI_NRBITS - 1) & GICR_VPROPBASER_IDBITS_MASK;
2051 val |= GICR_VPROPBASER_RaWb;
2052 val |= GICR_VPROPBASER_InnerShareable;
> 2053 writeq_relaxed(val, gic_data_rdist_vlpi_base() + GICR_VPROPBASER);
2054
2055 val = virt_to_phys(page_address(vpe->vpt_page)) & GENMASK(51, 16);
2056 val |= GICR_VPENDBASER_WaWb;
2057 val |= GICR_VPENDBASER_NonShareable;
2058 val |= GICR_PENDBASER_PendingLast;
2059 val |= vpe->idai ? GICR_PENDBASER_IDAI : 0;
2060 val |= GICR_PENDBASER_Valid;
2061 writeq_relaxed(val, gic_data_rdist_vlpi_base() + GICR_VPENDBASER);
2062
2063 return 0;
2064 }
2065
2066 case DESCHEDULE_VPE:
2067 {
2068 /* We're being scheduled out */
> 2069 val = readq_relaxed(gic_data_rdist_vlpi_base() + GICR_VPENDBASER);
2070 val &= ~GICR_PENDBASER_Valid;
2071 writeq_relaxed(val, gic_data_rdist_vlpi_base() + GICR_VPENDBASER);
2072
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 39862 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170103/e7d8f8c7/attachment-0001.gz>
^ permalink raw reply
* [PATCH 1/2] arm64: setup: introduce kaslr_offset()
From: Jon Hunter @ 2017-01-03 11:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4094c1ef-0a75-7076-58e0-52ece326188b@linux.com>
Hi Will, Catalin,
On 22/12/16 12:51, Alexander Popov wrote:
> On 22.12.2016 09:18, Yury Norov wrote:
>> On Sun, Dec 11, 2016 at 03:50:55AM +0300, Alexander Popov wrote:
>>> Introduce kaslr_offset() similarly to x86_64 for fixing kcov.
>
> [...]
>
>> Hi Alexander,
>>
>> I found today's linux-next master broken:
>
> [...]
>
>> It looks like you declare kaslr_offset() twice - in this patch, and in 7ede8665f
>> (arm64: setup: introduce kaslr_offset()).
>
> Hello Yury,
>
> There was a race during applying this patch. So currently linux-next has 2 versions of it.
>
> The first one is 1a339a14b1f2c7a0dfdd6db79eee1e55d3cec357, which is original.
> The second one is 7ede8665f27cde7da69e8b2fbeaa1ed0664879c5, updated by Will Deacon and
> applied to the mainline.
>
> I'm sorry for that. The first one should be definitely dropped.
Looks like this is still broken in today's -next.
Cheers
Jon
--
nvpublic
^ permalink raw reply
* [RFC PATCH net-next v4 1/2] macb: Add 1588 support in Cadence GEM.
From: Richard Cochran @ 2017-01-03 11:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <BN3PR07MB25168573DD82F1681CDC8437C96E0@BN3PR07MB2516.namprd07.prod.outlook.com>
On Tue, Jan 03, 2017 at 10:47:56AM +0000, Rafal Ozieblo wrote:
> We could use only descriptor approach but there are many Atmel's cores on the market which support only event registers.
As I said in my other reply in this thread, the Atmel cores cannot
possibly be made to work correctly.
Sad, but true.
Thanks,
Richard
^ permalink raw reply
* [PATCH v4 2/3] soc: zte: pm_domains: Add support for zx296718 board
From: Shawn Guo @ 2017-01-03 11:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483426577-5470-2-git-send-email-baoyou.xie@linaro.org>
On Tue, Jan 03, 2017 at 02:56:16PM +0800, Baoyou Xie wrote:
> This patch introduces the power domain driver of zx296718
> which belongs to zte's zx2967 family.
>
> Signed-off-by: Baoyou Xie <baoyou.xie@linaro.org>
It seems that none of the review comments I put on v3 [1] gets addressed
in this version. You missed them?
Shawn
[1] http://www.spinics.net/lists/arm-kernel/msg547691.html
^ permalink raw reply
* [arm-platforms:kvm-arm64/gicv4-wip 9/39] include/linux/irqchip/arm-gic-v3.h:245:32: warning: left shift count >= width of type
From: kbuild test robot @ 2017-01-03 11:02 UTC (permalink / raw)
To: linux-arm-kernel
tree: https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git kvm-arm64/gicv4-wip
head: ff003d7a3416337cc037320bfd175aaee79f05ae
commit: c02d4af9238775c4d1cfed01cf2072bc60d8c1ed [9/39] irqchip/gic-v3-its: Add probing for VLPI properties
config: arm-multi_v7_defconfig (attached as .config)
compiler: arm-linux-gnueabi-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 c02d4af9238775c4d1cfed01cf2072bc60d8c1ed
# save the attached .config to linux build tree
make.cross ARCH=arm
All warnings (new ones prefixed by >>):
In file included from drivers/irqchip/irq-gic-v3-its.c:38:0:
drivers/irqchip/irq-gic-v3-its.c: In function 'its_probe_one':
>> include/linux/irqchip/arm-gic-v3.h:245:32: warning: left shift count >= width of type [-Wshift-count-overflow]
#define GITS_TYPER_VMOVP (1UL << 37)
^
>> drivers/irqchip/irq-gic-v3-its.c:1706:30: note: in expansion of macro 'GITS_TYPER_VMOVP'
if (its->is_v4 && !(typer & GITS_TYPER_VMOVP)) {
^~~~~~~~~~~~~~~~
vim +245 include/linux/irqchip/arm-gic-v3.h
229 #define GITS_CIDR3 0xfffc
230
231 #define GITS_TRANSLATER 0x10040
232
233 #define GITS_CTLR_ENABLE (1U << 0)
234 #define GITS_CTLR_ITS_NUMBER_SHIFT 4
235 #define GITS_CTLR_ITS_NUMBER (0xFU << GITS_CTLR_ITS_NUMBER_SHIFT)
236 #define GITS_CTLR_QUIESCENT (1U << 31)
237
238 #define GITS_TYPER_PLPIS (1UL << 0)
239 #define GITS_TYPER_VLPIS (1UL << 1)
240 #define GITS_TYPER_IDBITS_SHIFT 8
241 #define GITS_TYPER_DEVBITS_SHIFT 13
242 #define GITS_TYPER_DEVBITS(r) ((((r) >> GITS_TYPER_DEVBITS_SHIFT) & 0x1f) + 1)
243 #define GITS_TYPER_PTA (1UL << 19)
244 #define GITS_TYPER_HWCOLLCNT_SHIFT 24
> 245 #define GITS_TYPER_VMOVP (1UL << 37)
246
247 #define GITS_CBASER_VALID (1ULL << 63)
248 #define GITS_CBASER_SHAREABILITY_SHIFT (10)
249 #define GITS_CBASER_INNER_CACHEABILITY_SHIFT (59)
250 #define GITS_CBASER_OUTER_CACHEABILITY_SHIFT (53)
251 #define GITS_CBASER_SHAREABILITY_MASK \
252 GIC_BASER_SHAREABILITY(GITS_CBASER, SHAREABILITY_MASK)
253 #define GITS_CBASER_INNER_CACHEABILITY_MASK \
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 39862 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170103/e35a6692/attachment-0001.gz>
^ permalink raw reply
* [PATCH v1] mtd: nand: tango: Reset pbus to raw mode in probe
From: Boris Brezillon @ 2017-01-03 10:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <e73bf318-c715-af8c-3fdc-3c5c93a13472@sigmadesigns.com>
On Tue, 3 Jan 2017 11:01:14 +0100
Marc Gonzalez <marc_gonzalez@sigmadesigns.com> wrote:
> Linux should not expect the boot loader to properly configure the
> peripheral bus "pad mode", so reset PBUS_PAD_MODE to raw.
>
Applied to nand/fixes.
Thanks,
Boris
> Signed-off-by: Marc Gonzalez <marc_gonzalez@sigmadesigns.com>
> ---
> drivers/mtd/nand/tango_nand.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/mtd/nand/tango_nand.c b/drivers/mtd/nand/tango_nand.c
> index d370c0382808..2456640fe4d5 100644
> --- a/drivers/mtd/nand/tango_nand.c
> +++ b/drivers/mtd/nand/tango_nand.c
> @@ -644,6 +644,8 @@ static int tango_nand_probe(struct platform_device *pdev)
> if (IS_ERR(nfc->pbus_base))
> return PTR_ERR(nfc->pbus_base);
>
> + writel_relaxed(MODE_RAW, nfc->pbus_base + PBUS_PAD_MODE);
> +
> clk = clk_get(&pdev->dev, NULL);
> if (IS_ERR(clk))
> return PTR_ERR(clk);
>
^ permalink raw reply
* [PATCH] mtd: nand: fsmc: remove stale non-DT probe path
From: Boris Brezillon @ 2017-01-03 10:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482060895-26838-1-git-send-email-linus.walleij@linaro.org>
On Sun, 18 Dec 2016 12:34:55 +0100
Linus Walleij <linus.walleij@linaro.org> wrote:
> The FSMC driver has an execution path and a header file in
> <linux/mtd/fsmc.h> that serves to support passing in platform
> data through board files, albeit no upstream users of this
> mechanism exist.
>
> The header file also contains function headers for functions that
> do not exist in the kernel.
>
> Delete this and move the platform data struct, parsing and
> handling into the driver, assume we are using OF and make the
> driver depend on OF, remove the ifdefs making that optional.
Applied.
Thanks,
Boris
>
> Cc: Viresh Kumar <viresh.kumar@linaro.org>
> Cc: Stefan Roese <sr@denx.de>
> Cc: Vipin Kumar <vipin.kumar@st.com>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> ---
> drivers/mtd/nand/Kconfig | 1 +
> drivers/mtd/nand/fsmc_nand.c | 153 ++++++++++++++++++++++++++++++++++++------
> include/linux/mtd/fsmc.h | 156 -------------------------------------------
> 3 files changed, 133 insertions(+), 177 deletions(-)
> delete mode 100644 include/linux/mtd/fsmc.h
>
> diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
> index 353a9ddf6b97..7d5a9cb4594d 100644
> --- a/drivers/mtd/nand/Kconfig
> +++ b/drivers/mtd/nand/Kconfig
> @@ -534,6 +534,7 @@ config MTD_NAND_JZ4780
>
> config MTD_NAND_FSMC
> tristate "Support for NAND on ST Micros FSMC"
> + depends on OF
> depends on PLAT_SPEAR || ARCH_NOMADIK || ARCH_U8500 || MACH_U300
> help
> Enables support for NAND Flash chips on the ST Microelectronics
> diff --git a/drivers/mtd/nand/fsmc_nand.c b/drivers/mtd/nand/fsmc_nand.c
> index 4924b43977ef..bda1e4667138 100644
> --- a/drivers/mtd/nand/fsmc_nand.c
> +++ b/drivers/mtd/nand/fsmc_nand.c
> @@ -35,10 +35,133 @@
> #include <linux/mtd/partitions.h>
> #include <linux/io.h>
> #include <linux/slab.h>
> -#include <linux/mtd/fsmc.h>
> #include <linux/amba/bus.h>
> #include <mtd/mtd-abi.h>
>
> +#define FSMC_NAND_BW8 1
> +#define FSMC_NAND_BW16 2
> +
> +#define FSMC_MAX_NOR_BANKS 4
> +#define FSMC_MAX_NAND_BANKS 4
> +
> +#define FSMC_FLASH_WIDTH8 1
> +#define FSMC_FLASH_WIDTH16 2
> +
> +/* fsmc controller registers for NOR flash */
> +#define CTRL 0x0
> + /* ctrl register definitions */
> + #define BANK_ENABLE (1 << 0)
> + #define MUXED (1 << 1)
> + #define NOR_DEV (2 << 2)
> + #define WIDTH_8 (0 << 4)
> + #define WIDTH_16 (1 << 4)
> + #define RSTPWRDWN (1 << 6)
> + #define WPROT (1 << 7)
> + #define WRT_ENABLE (1 << 12)
> + #define WAIT_ENB (1 << 13)
> +
> +#define CTRL_TIM 0x4
> + /* ctrl_tim register definitions */
> +
> +#define FSMC_NOR_BANK_SZ 0x8
> +#define FSMC_NOR_REG_SIZE 0x40
> +
> +#define FSMC_NOR_REG(base, bank, reg) (base + \
> + FSMC_NOR_BANK_SZ * (bank) + \
> + reg)
> +
> +/* fsmc controller registers for NAND flash */
> +#define PC 0x00
> + /* pc register definitions */
> + #define FSMC_RESET (1 << 0)
> + #define FSMC_WAITON (1 << 1)
> + #define FSMC_ENABLE (1 << 2)
> + #define FSMC_DEVTYPE_NAND (1 << 3)
> + #define FSMC_DEVWID_8 (0 << 4)
> + #define FSMC_DEVWID_16 (1 << 4)
> + #define FSMC_ECCEN (1 << 6)
> + #define FSMC_ECCPLEN_512 (0 << 7)
> + #define FSMC_ECCPLEN_256 (1 << 7)
> + #define FSMC_TCLR_1 (1)
> + #define FSMC_TCLR_SHIFT (9)
> + #define FSMC_TCLR_MASK (0xF)
> + #define FSMC_TAR_1 (1)
> + #define FSMC_TAR_SHIFT (13)
> + #define FSMC_TAR_MASK (0xF)
> +#define STS 0x04
> + /* sts register definitions */
> + #define FSMC_CODE_RDY (1 << 15)
> +#define COMM 0x08
> + /* comm register definitions */
> + #define FSMC_TSET_0 0
> + #define FSMC_TSET_SHIFT 0
> + #define FSMC_TSET_MASK 0xFF
> + #define FSMC_TWAIT_6 6
> + #define FSMC_TWAIT_SHIFT 8
> + #define FSMC_TWAIT_MASK 0xFF
> + #define FSMC_THOLD_4 4
> + #define FSMC_THOLD_SHIFT 16
> + #define FSMC_THOLD_MASK 0xFF
> + #define FSMC_THIZ_1 1
> + #define FSMC_THIZ_SHIFT 24
> + #define FSMC_THIZ_MASK 0xFF
> +#define ATTRIB 0x0C
> +#define IOATA 0x10
> +#define ECC1 0x14
> +#define ECC2 0x18
> +#define ECC3 0x1C
> +#define FSMC_NAND_BANK_SZ 0x20
> +
> +#define FSMC_NAND_REG(base, bank, reg) (base + FSMC_NOR_REG_SIZE + \
> + (FSMC_NAND_BANK_SZ * (bank)) + \
> + reg)
> +
> +#define FSMC_BUSY_WAIT_TIMEOUT (1 * HZ)
> +
> +struct fsmc_nand_timings {
> + uint8_t tclr;
> + uint8_t tar;
> + uint8_t thiz;
> + uint8_t thold;
> + uint8_t twait;
> + uint8_t tset;
> +};
> +
> +enum access_mode {
> + USE_DMA_ACCESS = 1,
> + USE_WORD_ACCESS,
> +};
> +
> +/**
> + * fsmc_nand_platform_data - platform specific NAND controller config
> + * @nand_timings: timing setup for the physical NAND interface
> + * @partitions: partition table for the platform, use a default fallback
> + * if this is NULL
> + * @nr_partitions: the number of partitions in the previous entry
> + * @options: different options for the driver
> + * @width: bus width
> + * @bank: default bank
> + * @select_bank: callback to select a certain bank, this is
> + * platform-specific. If the controller only supports one bank
> + * this may be set to NULL
> + */
> +struct fsmc_nand_platform_data {
> + struct fsmc_nand_timings *nand_timings;
> + struct mtd_partition *partitions;
> + unsigned int nr_partitions;
> + unsigned int options;
> + unsigned int width;
> + unsigned int bank;
> +
> + enum access_mode mode;
> +
> + void (*select_bank)(uint32_t bank, uint32_t busw);
> +
> + /* priv structures for dma accesses */
> + void *read_dma_priv;
> + void *write_dma_priv;
> +};
> +
> static int fsmc_ecc1_ooblayout_ecc(struct mtd_info *mtd, int section,
> struct mtd_oob_region *oobregion)
> {
> @@ -714,7 +837,6 @@ static bool filter(struct dma_chan *chan, void *slave)
> return true;
> }
>
> -#ifdef CONFIG_OF
> static int fsmc_nand_probe_config_dt(struct platform_device *pdev,
> struct device_node *np)
> {
> @@ -757,13 +879,6 @@ static int fsmc_nand_probe_config_dt(struct platform_device *pdev,
> }
> return 0;
> }
> -#else
> -static int fsmc_nand_probe_config_dt(struct platform_device *pdev,
> - struct device_node *np)
> -{
> - return -ENOSYS;
> -}
> -#endif
>
> /*
> * fsmc_nand_probe - Probe function
> @@ -782,19 +897,15 @@ static int __init fsmc_nand_probe(struct platform_device *pdev)
> u32 pid;
> int i;
>
> - if (np) {
> - pdata = devm_kzalloc(&pdev->dev, sizeof(*pdata), GFP_KERNEL);
> - pdev->dev.platform_data = pdata;
> - ret = fsmc_nand_probe_config_dt(pdev, np);
> - if (ret) {
> - dev_err(&pdev->dev, "no platform data\n");
> - return -ENODEV;
> - }
> - }
> + pdata = devm_kzalloc(&pdev->dev, sizeof(*pdata), GFP_KERNEL);
> + if (!pdata)
> + return -ENOMEM;
>
> - if (!pdata) {
> - dev_err(&pdev->dev, "platform data is NULL\n");
> - return -EINVAL;
> + pdev->dev.platform_data = pdata;
> + ret = fsmc_nand_probe_config_dt(pdev, np);
> + if (ret) {
> + dev_err(&pdev->dev, "no platform data\n");
> + return -ENODEV;
> }
>
> /* Allocate memory for the device structure (and zero it) */
> diff --git a/include/linux/mtd/fsmc.h b/include/linux/mtd/fsmc.h
> deleted file mode 100644
> index ad3c3488073c..000000000000
> --- a/include/linux/mtd/fsmc.h
> +++ /dev/null
> @@ -1,156 +0,0 @@
> -/*
> - * incude/mtd/fsmc.h
> - *
> - * ST Microelectronics
> - * Flexible Static Memory Controller (FSMC)
> - * platform data interface and header file
> - *
> - * Copyright ? 2010 ST Microelectronics
> - * Vipin Kumar <vipin.kumar@st.com>
> - *
> - * This file is licensed under the terms of the GNU General Public
> - * License version 2. This program is licensed "as is" without any
> - * warranty of any kind, whether express or implied.
> - */
> -
> -#ifndef __MTD_FSMC_H
> -#define __MTD_FSMC_H
> -
> -#include <linux/io.h>
> -#include <linux/platform_device.h>
> -#include <linux/mtd/physmap.h>
> -#include <linux/types.h>
> -#include <linux/mtd/partitions.h>
> -#include <asm/param.h>
> -
> -#define FSMC_NAND_BW8 1
> -#define FSMC_NAND_BW16 2
> -
> -#define FSMC_MAX_NOR_BANKS 4
> -#define FSMC_MAX_NAND_BANKS 4
> -
> -#define FSMC_FLASH_WIDTH8 1
> -#define FSMC_FLASH_WIDTH16 2
> -
> -/* fsmc controller registers for NOR flash */
> -#define CTRL 0x0
> - /* ctrl register definitions */
> - #define BANK_ENABLE (1 << 0)
> - #define MUXED (1 << 1)
> - #define NOR_DEV (2 << 2)
> - #define WIDTH_8 (0 << 4)
> - #define WIDTH_16 (1 << 4)
> - #define RSTPWRDWN (1 << 6)
> - #define WPROT (1 << 7)
> - #define WRT_ENABLE (1 << 12)
> - #define WAIT_ENB (1 << 13)
> -
> -#define CTRL_TIM 0x4
> - /* ctrl_tim register definitions */
> -
> -#define FSMC_NOR_BANK_SZ 0x8
> -#define FSMC_NOR_REG_SIZE 0x40
> -
> -#define FSMC_NOR_REG(base, bank, reg) (base + \
> - FSMC_NOR_BANK_SZ * (bank) + \
> - reg)
> -
> -/* fsmc controller registers for NAND flash */
> -#define PC 0x00
> - /* pc register definitions */
> - #define FSMC_RESET (1 << 0)
> - #define FSMC_WAITON (1 << 1)
> - #define FSMC_ENABLE (1 << 2)
> - #define FSMC_DEVTYPE_NAND (1 << 3)
> - #define FSMC_DEVWID_8 (0 << 4)
> - #define FSMC_DEVWID_16 (1 << 4)
> - #define FSMC_ECCEN (1 << 6)
> - #define FSMC_ECCPLEN_512 (0 << 7)
> - #define FSMC_ECCPLEN_256 (1 << 7)
> - #define FSMC_TCLR_1 (1)
> - #define FSMC_TCLR_SHIFT (9)
> - #define FSMC_TCLR_MASK (0xF)
> - #define FSMC_TAR_1 (1)
> - #define FSMC_TAR_SHIFT (13)
> - #define FSMC_TAR_MASK (0xF)
> -#define STS 0x04
> - /* sts register definitions */
> - #define FSMC_CODE_RDY (1 << 15)
> -#define COMM 0x08
> - /* comm register definitions */
> - #define FSMC_TSET_0 0
> - #define FSMC_TSET_SHIFT 0
> - #define FSMC_TSET_MASK 0xFF
> - #define FSMC_TWAIT_6 6
> - #define FSMC_TWAIT_SHIFT 8
> - #define FSMC_TWAIT_MASK 0xFF
> - #define FSMC_THOLD_4 4
> - #define FSMC_THOLD_SHIFT 16
> - #define FSMC_THOLD_MASK 0xFF
> - #define FSMC_THIZ_1 1
> - #define FSMC_THIZ_SHIFT 24
> - #define FSMC_THIZ_MASK 0xFF
> -#define ATTRIB 0x0C
> -#define IOATA 0x10
> -#define ECC1 0x14
> -#define ECC2 0x18
> -#define ECC3 0x1C
> -#define FSMC_NAND_BANK_SZ 0x20
> -
> -#define FSMC_NAND_REG(base, bank, reg) (base + FSMC_NOR_REG_SIZE + \
> - (FSMC_NAND_BANK_SZ * (bank)) + \
> - reg)
> -
> -#define FSMC_BUSY_WAIT_TIMEOUT (1 * HZ)
> -
> -struct fsmc_nand_timings {
> - uint8_t tclr;
> - uint8_t tar;
> - uint8_t thiz;
> - uint8_t thold;
> - uint8_t twait;
> - uint8_t tset;
> -};
> -
> -enum access_mode {
> - USE_DMA_ACCESS = 1,
> - USE_WORD_ACCESS,
> -};
> -
> -/**
> - * fsmc_nand_platform_data - platform specific NAND controller config
> - * @nand_timings: timing setup for the physical NAND interface
> - * @partitions: partition table for the platform, use a default fallback
> - * if this is NULL
> - * @nr_partitions: the number of partitions in the previous entry
> - * @options: different options for the driver
> - * @width: bus width
> - * @bank: default bank
> - * @select_bank: callback to select a certain bank, this is
> - * platform-specific. If the controller only supports one bank
> - * this may be set to NULL
> - */
> -struct fsmc_nand_platform_data {
> - struct fsmc_nand_timings *nand_timings;
> - struct mtd_partition *partitions;
> - unsigned int nr_partitions;
> - unsigned int options;
> - unsigned int width;
> - unsigned int bank;
> -
> - enum access_mode mode;
> -
> - void (*select_bank)(uint32_t bank, uint32_t busw);
> -
> - /* priv structures for dma accesses */
> - void *read_dma_priv;
> - void *write_dma_priv;
> -};
> -
> -extern int __init fsmc_nor_init(struct platform_device *pdev,
> - unsigned long base, uint32_t bank, uint32_t width);
> -extern void __init fsmc_init_board_info(struct platform_device *pdev,
> - struct mtd_partition *partitions, unsigned int nr_partitions,
> - unsigned int width);
> -
> -#endif /* __MTD_FSMC_H */
^ permalink raw reply
* [RFC PATCH net-next v4 1/2] macb: Add 1588 support in Cadence GEM.
From: Harini Katakam @ 2017-01-03 10:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170103102958.GC24780@localhost.localdomain>
Hi Richard,
On Tue, Jan 3, 2017 at 3:59 PM, Richard Cochran
<richardcochran@gmail.com> wrote:
> On Tue, Jan 03, 2017 at 10:36:11AM +0530, Harini Katakam wrote:
>> I understand that it is not accurate - it is an initial version.
>
> Why do you say, "it is an initial version?"
>
> The Atmel device has this IP core burned in. The core is hopelessly
> broken, and it cannot be fixed in SW either, so what is your point?
>
I'm sorry - I just meant that this was before many necessary
enhancements and fixes.
Newer SoCs including ZynqMP (for which the original series was sent)
have the descriptor based approach which is reliable.
Regards,
Harini
^ permalink raw reply
* [PATCH 3/5] arm64: dts: sun50i: add MMC nodes
From: André Przywara @ 2017-01-03 10:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGb2v65GJFTnQZtWHCS7CAtA+Dry94o77aakPLr938BpQksLog@mail.gmail.com>
On 03/01/17 02:52, Chen-Yu Tsai wrote:
Hi,
> On Tue, Jan 3, 2017 at 7:03 AM, Andre Przywara <andre.przywara@arm.com> wrote:
>
> A commit message explaining the mmc controllers would be nice.
OK.
>> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
>> ---
>> arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 67 +++++++++++++++++++++++++++
>> 1 file changed, 67 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
>> index e0dcab8..c680566 100644
>> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
>> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
>> @@ -150,6 +150,32 @@
>> pins = "PB8", "PB9";
>> function = "uart0";
>> };
>> +
>> + mmc0_pins: mmc0 at 0 {
>> + pins = "PF0", "PF1", "PF2", "PF3", "PF4", "PF5";
>> + function = "mmc0";
>> + drive-strength = <30>;
>> + };
>> +
>> + mmc0_default_cd_pin: mmc0_cd_pin at 0 {
>> + pins = "PF6";
>> + function = "gpio_in";
>> + bias-pull-up;
>> + };
>
> We are starting to drop pinmux nodes for gpio usage.
And replacing them with what?
Or do you mean they go in the individual board .dts files?
In this case I believe having a default pin defined here would help to
define it in every .dts.
>> +
>> + mmc1_pins: mmc1 at 0 {
>> + pins = "PG0", "PG1", "PG2", "PG3", "PG4", "PG5";
>> + function = "mmc1";
>> + drive-strength = <30>;
>> + };
>> +
>> + mmc2_pins: mmc2 at 0 {
>> + pins = "PC1", "PC5", "PC6", "PC8", "PC9",
>> + "PC10", "PC11", "PC12", "PC13", "PC14",
>> + "PC15", "PC16";
>> + function = "mmc2";
>> + drive-strength = <30>;
>> + };
>
> Moreover I think you should split out the pinmux nodes to a separate patch.
I can surely do, just wondering what's the rationale is behind that?
>
>> };
>>
>> uart0: serial at 1c28000 {
>> @@ -240,6 +266,47 @@
>> #size-cells = <0>;
>> };
>>
>> + mmc0: mmc at 1c0f000 {
>> + compatible = "allwinner,sun50i-a64-mmc",
>> + "allwinner,sun5i-a13-mmc";
>
> Given that sun5i doesn't support mmc delay timings, and the A64 has
> calibration and delay timings, I wouldn't call them compatible.
>
> Or are you claiming that for the A64 has a delay of 0 for the
> currently supported speeds, so the calibration doesn't really
> matter? If so this should be mentioned in the commit message.
Yes, that's my observation: Driving it with sun5-a13-mmc just works.
This sun5i driver version does not (and will never) support higher
transfer modes anyway, so for that subset they are compatible. This
opens up the door to other operating systems not having a particular
driver for the A64, for instance, also older Linux kernels.
I know that sunxi doesn't use this compatible feature much, but IMHO we
should really start thinking about the DT not just being Linux specific
- or even being specific to a certain Linux version. And this case here
is a good example: An A13 MMC driver can drive this device - if there is
no better driver (an A64 one) available.
>
>> + reg = <0x01c0f000 0x1000>;
>> + clocks = <&ccu 31>, <&ccu 75>;
>
> The clock / reset index macros are in the tree now.
> Please switch to them.
The include file is in the tree, but it isn't used in the current HEAD
(as in #included and the actual macros being used in the .dtsi).
So I was wondering if there is a patch pending for that?
Cheers,
Andre
>> + clock-names = "ahb", "mmc";
>> + resets = <&ccu 8>;
>> + reset-names = "ahb";
>> + interrupts = <GIC_SPI 60 IRQ_TYPE_LEVEL_HIGH>;
>> + status = "disabled";
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + };
>> +
>> + mmc1: mmc at 1c10000 {
>> + compatible = "allwinner,sun50i-a64-mmc",
>> + "allwinner,sun5i-a13-mmc";
>> + reg = <0x01c10000 0x1000>;
>> + clocks = <&ccu 32>, <&ccu 76>;
>> + clock-names = "ahb", "mmc";
>> + resets = <&ccu 9>;
>> + reset-names = "ahb";
>> + interrupts = <GIC_SPI 61 IRQ_TYPE_LEVEL_HIGH>;
>> + status = "disabled";
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + };
>> +
>> + mmc2: mmc at 1c11000 {
>> + compatible = "allwinner,sun50i-a64-emmc";
>> + reg = <0x01c11000 0x1000>;
>> + clocks = <&ccu 33>, <&ccu 77>;
>> + clock-names = "ahb", "mmc";
>> + resets = <&ccu 10>;
>> + reset-names = "ahb";
>> + interrupts = <GIC_SPI 62 IRQ_TYPE_LEVEL_HIGH>;
>> + status = "disabled";
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + };
>> +
>> gic: interrupt-controller at 1c81000 {
>> compatible = "arm,gic-400";
>> reg = <0x01c81000 0x1000>,
>> --
>> 2.8.2
>>
^ permalink raw reply
* [RFC PATCH net-next v4 1/2] macb: Add 1588 support in Cadence GEM.
From: Rafal Ozieblo @ 2017-01-03 10:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAFcVECK1vt7Hu4tgSZ2+kKpMxoT-wpikMDq65HaxRv-EMgobHA@mail.gmail.com>
>From: Harini Katakam [mailto:harinikatakamlinux at gmail.com]
>Sent: 3 stycznia 2017 06:06
>Subject: Re: [RFC PATCH net-next v4 1/2] macb: Add 1588 support in Cadence GEM.
>
>Hi Richard,
>
>On Mon, Jan 2, 2017 at 9:43 PM, Richard Cochran <richardcochran@gmail.com> wrote:
>> On Mon, Jan 02, 2017 at 03:47:07PM +0100, Nicolas Ferre wrote:
>>> Le 02/01/2017 ? 12:31, Richard Cochran a ?crit :
>>> > This Cadence IP core is a complete disaster.
>>>
>>> Well, it evolved and propose several options to different SoC
>>> integrators. This is not something unusual...
>>> I suspect as well that some other network adapters have the same
>>> weakness concerning PTP timestamp in single register as the early
>>> revisions of this IP.
>>
>> It appears that this core can neither latch the time on read or write,
>> or even latch time stamps. I have worked with many different PTP HW
>> implementations, even early ones like on the ixp4xx, and it is no
>> exaggeration to say that this one is uniquely broken.
>>
>>> I suspect that Rafal tend to jump too quickly to the latest IP
>>> revisions and add more options to this series: let's not try to pour
>>> too much things into this code right now.
>>
>> Why can't you check the IP version in the driver?
>
>There is an IP revision register but it would be probably be better to rely on "caps" from the compatibility strings - to cover SoC specific implementations. Also, when this extended BD is added (with timestamp), additional words will need to be added statically which will be consistent with Andrei's CONFIG_ checks.
We can distinguish IP cores with and without PTP support by reading Design Configuration Register. But to distinguish IP cores with timestamps in buffer descriptors and which support only event registers, we can only check IP version by reading the revision ID register and base on that.
I agree with Harini, compatibility strings could be better. But we might end up with many different configuration in the future.
We could use only descriptor approach but there are many Atmel's cores on the market which support only event registers.
^ permalink raw reply
* [PATCH] mtd: nand: lpc32xx: fix invalid error handling of a requested irq
From: Boris Brezillon @ 2017-01-03 10:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <72ab91ec-a919-af42-8a82-f5d99b245edf@mleia.com>
On Tue, 3 Jan 2017 12:16:26 +0200
Vladimir Zapolskiy <vz@mleia.com> wrote:
> Hi Boris,
>
> On 01/03/2017 11:12 AM, Boris Brezillon wrote:
> > Hi Vladimir
> >
> > On Mon, 5 Dec 2016 03:47:10 +0200
> > Vladimir Zapolskiy <vz@mleia.com> wrote:
> >
> >> Semantics of NR_IRQS is different on machines with SPARSE_IRQ option
> >> disabled or enabled, in the latter case IRQs are allocated starting
> >> at least from the value specified by NR_IRQS and going upwards, so
> >> the check of (irq >= NR_IRQ) to decide about an error code returned by
> >> platform_get_irq() is completely invalid, don't attempt to overrule
> >> irq subsystem in the driver.
> >>
> >> The change fixes LPC32xx NAND MLC driver initialization on boot.
> >
> > Do you need to backport this fix to stable releases? If that's the
> > case, I'll add the Cc: stable tag when applying.
>
> that will be great if you can add
>
> Cc: stable at kernel.org # v4.7+
>
> Please feel free to add also the tag
>
> Fixes: 8cb17b5ed017 ("irqchip: Add LPC32xx interrupt controller driver")
Applied to nand/next (this patch will appear in 4.11).
Thanks,
Boris
>
> --
> With best wishes,
> Vladimir
>
^ permalink raw reply
* [PATCH v3 2/2] ARM: dts: imx6q: Add mccmon6 board support
From: Lukasz Majewski @ 2017-01-03 10:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483440381-24268-1-git-send-email-lukma@denx.de>
From: Lukasz Majewski <l.majewski@majess.pl>
This patch provides support for Liebherr's Monitor 6 board (abverrated as
mccmon6) to Linux kernel.
Signed-off-by: Lukasz Majewski <lukma@denx.de>
---
Changes for v3:
- Reorganize the dts file according to Shawn Guo's comments
Changes for v2:
- Reorganize the dts file according to Valdimir Zapolskiy's comments
---
MCCMON6 board support depends on following patches:
1. "video: backlight: pwm_bl: Initialize fb_bl_on[x] and use_count during pwm_backlight_probe()"
http://patchwork.ozlabs.org/patch/708844/
2. "pwm: imx: Provide atomic operation for IMX PWM driver"
http://patchwork.ozlabs.org/patch/708847/ - http://patchwork.ozlabs.org/patch/708843/
The patch applies to v4.10-rc2
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/imx6q-mccmon6.dts | 473 ++++++++++++++++++++++++++++++++++++
2 files changed, 474 insertions(+)
create mode 100644 arch/arm/boot/dts/imx6q-mccmon6.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index cccdbcb..316c178 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -393,6 +393,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
imx6q-icore.dtb \
imx6q-icore-rqs.dtb \
imx6q-marsboard.dtb \
+ imx6q-mccmon6.dtb \
imx6q-nitrogen6x.dtb \
imx6q-nitrogen6_max.dtb \
imx6q-nitrogen6_som2.dtb \
diff --git a/arch/arm/boot/dts/imx6q-mccmon6.dts b/arch/arm/boot/dts/imx6q-mccmon6.dts
new file mode 100644
index 0000000..eedbe73
--- /dev/null
+++ b/arch/arm/boot/dts/imx6q-mccmon6.dts
@@ -0,0 +1,473 @@
+/*
+ * Copyright 2016-2017
+ * Lukasz Majewski, DENX Software Engineering, lukma at denx.de
+ *
+ * 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.
+ *
+ */
+
+/dts-v1/;
+
+#include "imx6q.dtsi"
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/pwm/pwm.h>
+
+/ {
+ model = "Liebherr (LWN) monitor6 i.MX6 Quad Board";
+ compatible = "lwn,mccmon6", "fsl,imx6q";
+
+ memory {
+ reg = <0x10000000 0x80000000>;
+ };
+
+ backlight_lvds: backlight {
+ compatible = "pwm-backlight";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_backlight>;
+ pwms = <&pwm2 0 5000000 PWM_POLARITY_INVERTED>;
+ brightness-levels = < 0 1 2 3 4 5 6 7 8 9
+ 10 11 12 13 14 15 16 17 18 19
+ 20 21 22 23 24 25 26 27 28 29
+ 30 31 32 33 34 35 36 37 38 39
+ 40 41 42 43 44 45 46 47 48 49
+ 50 51 52 53 54 55 56 57 58 59
+ 60 61 62 63 64 65 66 67 68 69
+ 70 71 72 73 74 75 76 77 78 79
+ 80 81 82 83 84 85 86 87 88 89
+ 90 91 92 93 94 95 96 97 98 99
+ 100 101 102 103 104 105 106 107 108 109
+ 110 111 112 113 114 115 116 117 118 119
+ 120 121 122 123 124 125 126 127 128 129
+ 130 131 132 133 134 135 136 137 138 139
+ 140 141 142 143 144 145 146 147 148 149
+ 150 151 152 153 154 155 156 157 158 159
+ 160 161 162 163 164 165 166 167 168 169
+ 170 171 172 173 174 175 176 177 178 179
+ 180 181 182 183 184 185 186 187 188 189
+ 190 191 192 193 194 195 196 197 198 199
+ 200 201 202 203 204 205 206 207 208 209
+ 210 211 212 213 214 215 216 217 218 219
+ 220 221 222 223 224 225 226 227 228 229
+ 230 231 232 233 234 235 236 237 238 239
+ 240 241 242 243 244 245 246 247 248 249
+ 250 251 252 253 254 255>;
+ default-brightness-level = <50>;
+ enable-gpios = <&gpio1 2 GPIO_ACTIVE_LOW>;
+ };
+
+ reg_lvds: regulator-lvds {
+ compatible = "regulator-fixed";
+ regulator-name = "lvds_ppen";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-boot-on;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_reg_lvds>;
+ gpio = <&gpio1 19 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
+ panel-lvds0 {
+ compatible = "innolux,g121x1-l03";
+ backlight = <&backlight_lvds>;
+ power-supply = <®_lvds>;
+
+ port {
+ panel_in_lvds0: endpoint {
+ remote-endpoint = <&lvds0_out>;
+ };
+ };
+ };
+};
+
+&ecspi3 {
+ cs-gpios = <&gpio4 24 GPIO_ACTIVE_LOW>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_ecspi3 &pinctrl_ecspi3_cs &pinctrl_ecspi3_flwp>;
+ status = "okay";
+
+ s25sl032p: flash at 0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "jedec,spi-nor";
+ spi-max-frequency = <40000000>;
+ reg = <0>;
+ };
+};
+
+&fec {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_enet>;
+ phy-mode = "rgmii";
+ phy-reset-gpios = <&gpio1 27 GPIO_ACTIVE_LOW>;
+ interrupts-extended = <&gpio1 6 IRQ_TYPE_LEVEL_HIGH>,
+ <&intc 0 119 IRQ_TYPE_LEVEL_HIGH>;
+ status = "okay";
+};
+
+&i2c1 {
+ clock-frequency = <100000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c1>;
+ status = "okay";
+};
+
+&i2c2 {
+ clock-frequency = <100000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c2>;
+ status = "okay";
+
+ pfuze100: pmic at 08 {
+ compatible = "fsl,pfuze100";
+ reg = <0x08>;
+
+ regulators {
+ sw1a_reg: sw1ab {
+ regulator-min-microvolt = <300000>;
+ regulator-max-microvolt = <1875000>;
+ regulator-boot-on;
+ regulator-always-on;
+ regulator-ramp-delay = <6250>;
+ };
+
+ sw1c_reg: sw1c {
+ regulator-min-microvolt = <300000>;
+ regulator-max-microvolt = <1875000>;
+ regulator-boot-on;
+ regulator-always-on;
+ regulator-ramp-delay = <6250>;
+ };
+
+ sw2_reg: sw2 {
+ regulator-min-microvolt = <800000>;
+ regulator-max-microvolt = <3950000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ sw3a_reg: sw3a {
+ regulator-min-microvolt = <400000>;
+ regulator-max-microvolt = <1975000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ sw3b_reg: sw3b {
+ regulator-min-microvolt = <400000>;
+ regulator-max-microvolt = <1975000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ sw4_reg: sw4 {
+ regulator-min-microvolt = <800000>;
+ regulator-max-microvolt = <3300000>;
+ };
+
+ swbst_reg: swbst {
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5150000>;
+ };
+
+ snvs_reg: vsnvs {
+ regulator-min-microvolt = <1000000>;
+ regulator-max-microvolt = <3000000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ vref_reg: vrefddr {
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ vgen1_reg: vgen1 {
+ regulator-min-microvolt = <800000>;
+ regulator-max-microvolt = <1550000>;
+ };
+
+ vgen2_reg: vgen2 {
+ regulator-min-microvolt = <800000>;
+ regulator-max-microvolt = <1550000>;
+ };
+
+ vgen3_reg: vgen3 {
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+ };
+
+ vgen4_reg: vgen4 {
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ };
+
+ vgen5_reg: vgen5 {
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ };
+
+ vgen6_reg: vgen6 {
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ };
+ };
+ };
+};
+
+&ldb {
+ status = "okay";
+
+ lvds0: lvds-channel at 0 {
+ fsl,data-mapping = "spwg";
+ fsl,data-width = <24>;
+ status = "okay";
+
+ port at 4 {
+ reg = <4>;
+
+ lvds0_out: endpoint {
+ remote-endpoint = <&panel_in_lvds0>;
+ };
+ };
+ };
+};
+
+&pwm2 {
+ #pwm-cells = <3>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_pwm2>;
+ status = "okay";
+};
+
+&uart1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart1>;
+ status = "okay";
+};
+
+&uart4 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart4>;
+ uart-has-rtscts;
+ status = "okay";
+};
+
+&usdhc2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usdhc2>;
+ cd-gpios = <&gpio1 4 GPIO_ACTIVE_LOW>;
+ bus-width = <4>;
+ status = "okay";
+};
+
+&usdhc3 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usdhc3>;
+ bus-width = <8>;
+ non-removable;
+ status = "okay";
+};
+
+&weim {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_weim_nor &pinctrl_weim_cs0>;
+ ranges = <0 0 0x08000000 0x08000000>;
+ status = "okay";
+
+ nor at 0,0 {
+ compatible = "cfi-flash";
+ reg = <0 0 0x02000000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ bank-width = <2>;
+ use-advanced-sector-protection;
+ fsl,weim-cs-timing = <0x00620081 0x00000001 0x1c022000
+ 0x0000c000 0x1404a38e 0x00000000>;
+ };
+};
+
+&iomuxc {
+ pinctrl-names = "default";
+
+ pinctrl_backlight: dispgrp {
+ fsl,pins = <
+ /* BLEN_OUT */
+ MX6QDL_PAD_GPIO_2__GPIO1_IO02 0x1b0b0
+ >;
+ };
+
+ pinctrl_ecspi3: ecspi3grp {
+ fsl,pins = <
+ MX6QDL_PAD_DISP0_DAT2__ECSPI3_MISO 0x100b1
+ MX6QDL_PAD_DISP0_DAT1__ECSPI3_MOSI 0x100b1
+ MX6QDL_PAD_DISP0_DAT0__ECSPI3_SCLK 0x100b1
+ >;
+ };
+
+ pinctrl_ecspi3_cs: ecspi3csgrp {
+ fsl,pins = <
+ MX6QDL_PAD_DISP0_DAT3__GPIO4_IO24 0x80000000
+ >;
+ };
+
+ pinctrl_ecspi3_flwp: ecspi3flwpgrp {
+ fsl,pins = <
+ MX6QDL_PAD_DISP0_DAT6__GPIO4_IO27 0x80000000
+ >;
+ };
+
+ pinctrl_enet: enetgrp {
+ fsl,pins = <
+ MX6QDL_PAD_ENET_MDIO__ENET_MDIO 0x1b0b0
+ MX6QDL_PAD_ENET_MDC__ENET_MDC 0x1b0b0
+ MX6QDL_PAD_RGMII_TXC__RGMII_TXC 0x1b0b0
+ MX6QDL_PAD_RGMII_TD0__RGMII_TD0 0x1b0b0
+ MX6QDL_PAD_RGMII_TD1__RGMII_TD1 0x1b0b0
+ MX6QDL_PAD_RGMII_TD2__RGMII_TD2 0x1b0b0
+ MX6QDL_PAD_RGMII_TD3__RGMII_TD3 0x1b0b0
+ MX6QDL_PAD_RGMII_TX_CTL__RGMII_TX_CTL 0x1b0b0
+ MX6QDL_PAD_ENET_REF_CLK__ENET_TX_CLK 0x1b0b0
+ MX6QDL_PAD_RGMII_RXC__RGMII_RXC 0x1b0b0
+ MX6QDL_PAD_RGMII_RD0__RGMII_RD0 0x1b0b0
+ MX6QDL_PAD_RGMII_RD1__RGMII_RD1 0x1b0b0
+ MX6QDL_PAD_RGMII_RD2__RGMII_RD2 0x1b0b0
+ MX6QDL_PAD_RGMII_RD3__RGMII_RD3 0x1b0b0
+ MX6QDL_PAD_RGMII_RX_CTL__RGMII_RX_CTL 0x1b0b0
+ MX6QDL_PAD_GPIO_16__ENET_REF_CLK 0x4001b0a8
+ MX6QDL_PAD_GPIO_6__ENET_IRQ 0x000b1
+ MX6QDL_PAD_ENET_RXD0__GPIO1_IO27 0x1b0b0
+ >;
+ };
+
+ pinctrl_i2c1: i2c1grp {
+ fsl,pins = <
+ MX6QDL_PAD_CSI0_DAT9__I2C1_SCL 0x4001b8b1
+ MX6QDL_PAD_CSI0_DAT8__I2C1_SDA 0x4001b8b1
+ >;
+ };
+
+ pinctrl_i2c2: i2c2grp {
+ fsl,pins = <
+ MX6QDL_PAD_KEY_COL3__I2C2_SCL 0x4001b8b1
+ MX6QDL_PAD_KEY_ROW3__I2C2_SDA 0x4001b8b1
+ >;
+ };
+
+ pinctrl_pwm2: pwm2grp {
+ fsl,pins = <
+ MX6QDL_PAD_GPIO_1__PWM2_OUT 0x1b0b1
+ >;
+ };
+
+ pinctrl_reg_lvds: reqlvdsgrp {
+ fsl,pins = <
+ /* LVDS_PPEN_OUT */
+ MX6QDL_PAD_SD1_DAT2__GPIO1_IO19 0x1b0b0
+ >;
+ };
+
+ pinctrl_uart1: uart1grp {
+ fsl,pins = <
+ MX6QDL_PAD_CSI0_DAT10__UART1_TX_DATA 0x1b0b1
+ MX6QDL_PAD_CSI0_DAT11__UART1_RX_DATA 0x1b0b1
+ >;
+ };
+
+ pinctrl_uart4: uart4grp {
+ fsl,pins = <
+ MX6QDL_PAD_KEY_COL0__UART4_TX_DATA 0x1b0b1
+ MX6QDL_PAD_KEY_ROW0__UART4_RX_DATA 0x1b0b1
+ MX6QDL_PAD_CSI0_DAT16__UART4_RTS_B 0x1b0b1
+ MX6QDL_PAD_CSI0_DAT17__UART4_CTS_B 0x1b0b1
+ >;
+ };
+
+ pinctrl_usdhc2: usdhc2grp {
+ fsl,pins = <
+ MX6QDL_PAD_SD2_CMD__SD2_CMD 0x17059
+ MX6QDL_PAD_SD2_CLK__SD2_CLK 0x10059
+ MX6QDL_PAD_SD2_DAT0__SD2_DATA0 0x17059
+ MX6QDL_PAD_SD2_DAT1__SD2_DATA1 0x17059
+ MX6QDL_PAD_SD2_DAT2__SD2_DATA2 0x17059
+ MX6QDL_PAD_SD2_DAT3__SD2_DATA3 0x17059
+ MX6QDL_PAD_GPIO_4__GPIO1_IO04 0x1b0b1
+ >;
+ };
+
+ pinctrl_usdhc3: usdhc3grp {
+ fsl,pins = <
+ MX6QDL_PAD_SD3_CMD__SD3_CMD 0x17059
+ MX6QDL_PAD_SD3_CLK__SD3_CLK 0x10059
+ MX6QDL_PAD_SD3_DAT0__SD3_DATA0 0x17059
+ MX6QDL_PAD_SD3_DAT1__SD3_DATA1 0x17059
+ MX6QDL_PAD_SD3_DAT2__SD3_DATA2 0x17059
+ MX6QDL_PAD_SD3_DAT3__SD3_DATA3 0x17059
+ MX6QDL_PAD_SD3_DAT4__SD3_DATA4 0x17059
+ MX6QDL_PAD_SD3_DAT5__SD3_DATA5 0x17059
+ MX6QDL_PAD_SD3_DAT6__SD3_DATA6 0x17059
+ MX6QDL_PAD_SD3_DAT7__SD3_DATA7 0x17059
+ MX6QDL_PAD_SD3_RST__SD3_RESET 0x17059
+ >;
+ };
+
+ pinctrl_weim_cs0: weimcs0grp {
+ fsl,pins = <
+ MX6QDL_PAD_EIM_CS0__EIM_CS0_B 0xb0b1
+ >;
+ };
+
+ pinctrl_weim_nor: weimnorgrp {
+ fsl,pins = <
+ MX6QDL_PAD_EIM_OE__EIM_OE_B 0xb0b1
+ MX6QDL_PAD_EIM_RW__EIM_RW 0xb0b1
+ MX6QDL_PAD_EIM_WAIT__EIM_WAIT_B 0xb060
+ MX6QDL_PAD_EIM_D16__EIM_DATA16 0x1b0b0
+ MX6QDL_PAD_EIM_D17__EIM_DATA17 0x1b0b0
+ MX6QDL_PAD_EIM_D18__EIM_DATA18 0x1b0b0
+ MX6QDL_PAD_EIM_D19__EIM_DATA19 0x1b0b0
+ MX6QDL_PAD_EIM_D20__EIM_DATA20 0x1b0b0
+ MX6QDL_PAD_EIM_D21__EIM_DATA21 0x1b0b0
+ MX6QDL_PAD_EIM_D22__EIM_DATA22 0x1b0b0
+ MX6QDL_PAD_EIM_D23__EIM_DATA23 0x1b0b0
+ MX6QDL_PAD_EIM_D24__EIM_DATA24 0x1b0b0
+ MX6QDL_PAD_EIM_D25__EIM_DATA25 0x1b0b0
+ MX6QDL_PAD_EIM_D26__EIM_DATA26 0x1b0b0
+ MX6QDL_PAD_EIM_D27__EIM_DATA27 0x1b0b0
+ MX6QDL_PAD_EIM_D28__EIM_DATA28 0x1b0b0
+ MX6QDL_PAD_EIM_D29__EIM_DATA29 0x1b0b0
+ MX6QDL_PAD_EIM_D30__EIM_DATA30 0x1b0b0
+ MX6QDL_PAD_EIM_D31__EIM_DATA31 0x1b0b0
+ MX6QDL_PAD_EIM_A23__EIM_ADDR23 0xb0b1
+ MX6QDL_PAD_EIM_A22__EIM_ADDR22 0xb0b1
+ MX6QDL_PAD_EIM_A21__EIM_ADDR21 0xb0b1
+ MX6QDL_PAD_EIM_A20__EIM_ADDR20 0xb0b1
+ MX6QDL_PAD_EIM_A19__EIM_ADDR19 0xb0b1
+ MX6QDL_PAD_EIM_A18__EIM_ADDR18 0xb0b1
+ MX6QDL_PAD_EIM_A17__EIM_ADDR17 0xb0b1
+ MX6QDL_PAD_EIM_A16__EIM_ADDR16 0xb0b1
+ MX6QDL_PAD_EIM_DA15__EIM_AD15 0xb0b1
+ MX6QDL_PAD_EIM_DA14__EIM_AD14 0xb0b1
+ MX6QDL_PAD_EIM_DA13__EIM_AD13 0xb0b1
+ MX6QDL_PAD_EIM_DA12__EIM_AD12 0xb0b1
+ MX6QDL_PAD_EIM_DA11__EIM_AD11 0xb0b1
+ MX6QDL_PAD_EIM_DA10__EIM_AD10 0xb0b1
+ MX6QDL_PAD_EIM_DA9__EIM_AD09 0xb0b1
+ MX6QDL_PAD_EIM_DA8__EIM_AD08 0xb0b1
+ MX6QDL_PAD_EIM_DA7__EIM_AD07 0xb0b1
+ MX6QDL_PAD_EIM_DA6__EIM_AD06 0xb0b1
+ MX6QDL_PAD_EIM_DA5__EIM_AD05 0xb0b1
+ MX6QDL_PAD_EIM_DA4__EIM_AD04 0xb0b1
+ MX6QDL_PAD_EIM_DA3__EIM_AD03 0xb0b1
+ MX6QDL_PAD_EIM_DA2__EIM_AD02 0xb0b1
+ MX6QDL_PAD_EIM_DA1__EIM_AD01 0xb0b1
+ MX6QDL_PAD_EIM_DA0__EIM_AD00 0xb0b1
+ >;
+ };
+};
--
2.1.4
^ permalink raw reply related
* [PATCH v3 1/2] Doc: devicetree: bindings: Add vendor prefix entry - lwn
From: Lukasz Majewski @ 2017-01-03 10:46 UTC (permalink / raw)
To: linux-arm-kernel
This patch adds entry for LWN - the Liebherr-Werk Nenzing GmbH company to
vendor-prefixes.txt file.
Signed-off-by: Lukasz Majewski <lukma@denx.de>
---
Changes for v3:
- Update to v4.10-rc2
Changes for v2:
- New patch
---
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 16d3b5e..8e2abcb 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -164,6 +164,7 @@ lg LG Corporation
linux Linux-specific binding
lltc Linear Technology Corporation
lsi LSI Corp. (LSI Logic)
+lwn Liebherr-Werk Nenzing GmbH
macnica Macnica Americas
marvell Marvell Technology Group Ltd.
maxim Maxim Integrated Products
--
2.1.4
^ permalink raw reply related
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