* [PATCH 1/1] power: reset: remove unused imx-snvs-poweroff driver
From: Sebastian Reichel @ 2018-01-09 16:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513938539-20873-1-git-send-email-aisheng.dong@nxp.com>
Hi,
On Fri, Dec 22, 2017 at 06:28:59PM +0800, Dong Aisheng wrote:
> There's no user of it in kernel now and it basically functions the same
> as the generic syscon-poweroff.c to which we have already switched.
> So let's remove it.
>
> Cc: Robin Gong <yibin.gong@nxp.com>
> Cc: Shawn Guo <shawnguo@kernel.org>
> Signed-off-by: Dong Aisheng <aisheng.dong@nxp.com>
> ---
Thanks, queued.
-- Sebastian
> .../bindings/power/reset/imx-snvs-poweroff.txt | 23 --------
> drivers/power/reset/Kconfig | 9 ---
> drivers/power/reset/Makefile | 1 -
> drivers/power/reset/imx-snvs-poweroff.c | 66 ----------------------
> 4 files changed, 99 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/power/reset/imx-snvs-poweroff.txt
> delete mode 100644 drivers/power/reset/imx-snvs-poweroff.c
>
> diff --git a/Documentation/devicetree/bindings/power/reset/imx-snvs-poweroff.txt b/Documentation/devicetree/bindings/power/reset/imx-snvs-poweroff.txt
> deleted file mode 100644
> index 1b81fcd..0000000
> --- a/Documentation/devicetree/bindings/power/reset/imx-snvs-poweroff.txt
> +++ /dev/null
> @@ -1,23 +0,0 @@
> -i.mx6 Poweroff Driver
> -
> -SNVS_LPCR in SNVS module can power off the whole system by pull
> -PMIC_ON_REQ low if PMIC_ON_REQ is connected with external PMIC.
> -If you don't want to use PMIC_ON_REQ as power on/off control,
> -please set status='disabled' to disable this driver.
> -
> -Required Properties:
> --compatible: "fsl,sec-v4.0-poweroff"
> --reg: Specifies the physical address of the SNVS_LPCR register
> -
> -Example:
> - snvs at 20cc000 {
> - compatible = "fsl,sec-v4.0-mon", "simple-bus";
> - #address-cells = <1>;
> - #size-cells = <1>;
> - ranges = <0 0x020cc000 0x4000>;
> - .....
> - snvs_poweroff: snvs-poweroff at 38 {
> - compatible = "fsl,sec-v4.0-poweroff";
> - reg = <0x38 0x4>;
> - };
> - }
> diff --git a/drivers/power/reset/Kconfig b/drivers/power/reset/Kconfig
> index ca0de1a..a102e74 100644
> --- a/drivers/power/reset/Kconfig
> +++ b/drivers/power/reset/Kconfig
> @@ -98,15 +98,6 @@ config POWER_RESET_HISI
> help
> Reboot support for Hisilicon boards.
>
> -config POWER_RESET_IMX
> - bool "IMX6 power-off driver"
> - depends on POWER_RESET && SOC_IMX6
> - help
> - This driver support power off external PMIC by PMIC_ON_REQ on i.mx6
> - boards.If you want to use other pin to control external power,please
> - say N here or disable in dts to make sure pm_power_off never be
> - overwrote wrongly by this driver.
> -
> config POWER_RESET_MSM
> bool "Qualcomm MSM power-off driver"
> depends on ARCH_QCOM
> diff --git a/drivers/power/reset/Makefile b/drivers/power/reset/Makefile
> index aeb65ed..dcc92f5 100644
> --- a/drivers/power/reset/Makefile
> +++ b/drivers/power/reset/Makefile
> @@ -10,7 +10,6 @@ obj-$(CONFIG_POWER_RESET_GEMINI_POWEROFF) += gemini-poweroff.o
> obj-$(CONFIG_POWER_RESET_GPIO) += gpio-poweroff.o
> obj-$(CONFIG_POWER_RESET_GPIO_RESTART) += gpio-restart.o
> obj-$(CONFIG_POWER_RESET_HISI) += hisi-reboot.o
> -obj-$(CONFIG_POWER_RESET_IMX) += imx-snvs-poweroff.o
> obj-$(CONFIG_POWER_RESET_MSM) += msm-poweroff.o
> obj-$(CONFIG_POWER_RESET_PIIX4_POWEROFF) += piix4-poweroff.o
> obj-$(CONFIG_POWER_RESET_LTC2952) += ltc2952-poweroff.o
> diff --git a/drivers/power/reset/imx-snvs-poweroff.c b/drivers/power/reset/imx-snvs-poweroff.c
> deleted file mode 100644
> index ad6ce50..0000000
> --- a/drivers/power/reset/imx-snvs-poweroff.c
> +++ /dev/null
> @@ -1,66 +0,0 @@
> -/* Power off driver for i.mx6
> - * Copyright (c) 2014, FREESCALE CORPORATION. All rights reserved.
> - *
> - * based on msm-poweroff.c
> - *
> - * This program is free software; you can redistribute it and/or modify
> - * it under the terms of the GNU General Public License version 2 and
> - * only 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.
> - *
> - */
> -
> -#include <linux/err.h>
> -#include <linux/init.h>
> -#include <linux/io.h>
> -#include <linux/kernel.h>
> -#include <linux/module.h>
> -#include <linux/of.h>
> -#include <linux/of_address.h>
> -#include <linux/platform_device.h>
> -
> -static void __iomem *snvs_base;
> -
> -static void do_imx_poweroff(void)
> -{
> - u32 value = readl(snvs_base);
> -
> - /* set TOP and DP_EN bit */
> - writel(value | 0x60, snvs_base);
> -}
> -
> -static int imx_poweroff_probe(struct platform_device *pdev)
> -{
> - snvs_base = of_iomap(pdev->dev.of_node, 0);
> - if (!snvs_base) {
> - dev_err(&pdev->dev, "failed to get memory\n");
> - return -ENODEV;
> - }
> -
> - pm_power_off = do_imx_poweroff;
> - return 0;
> -}
> -
> -static const struct of_device_id of_imx_poweroff_match[] = {
> - { .compatible = "fsl,sec-v4.0-poweroff", },
> - {},
> -};
> -MODULE_DEVICE_TABLE(of, of_imx_poweroff_match);
> -
> -static struct platform_driver imx_poweroff_driver = {
> - .probe = imx_poweroff_probe,
> - .driver = {
> - .name = "imx-snvs-poweroff",
> - .of_match_table = of_match_ptr(of_imx_poweroff_match),
> - },
> -};
> -
> -static int __init imx_poweroff_init(void)
> -{
> - return platform_driver_register(&imx_poweroff_driver);
> -}
> -device_initcall(imx_poweroff_init);
> --
> 2.7.4
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180109/10ab19fd/attachment.sig>
^ permalink raw reply
* [PATCH v2 3/3] iommu: Clean up of_iommu_init_fn
From: Robin Murphy @ 2018-01-09 16:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <da664cf8f60c77cbb657cc2e3849560604eaf6da.1515512134.git.robin.murphy@arm.com>
Now that no more drivers rely on arbitrary early initialisation via an
of_iommu_init_fn hook, let's clean up the redundant remnants. The
IOMMU_OF_DECLARE() macro needs to remain for now, as the probe-deferral
mechanism has no other nice way to detect built-in drivers before they
have registered themselves, such that it can make the right decision.
Reviewed-by: Sricharan R <sricharan@codeaurora.org>
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
---
v2: Rebase to 4.15-rc, add tags
drivers/iommu/arm-smmu-v3.c | 2 +-
drivers/iommu/arm-smmu.c | 12 ++++++------
drivers/iommu/exynos-iommu.c | 2 +-
drivers/iommu/ipmmu-vmsa.c | 4 ++--
drivers/iommu/msm_iommu.c | 2 +-
drivers/iommu/of_iommu.c | 16 ----------------
drivers/iommu/qcom_iommu.c | 2 +-
include/linux/of_iommu.h | 5 +----
8 files changed, 13 insertions(+), 32 deletions(-)
diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c
index f122071688fd..7f186beaa1a6 100644
--- a/drivers/iommu/arm-smmu-v3.c
+++ b/drivers/iommu/arm-smmu-v3.c
@@ -2962,7 +2962,7 @@ static struct platform_driver arm_smmu_driver = {
};
module_platform_driver(arm_smmu_driver);
-IOMMU_OF_DECLARE(arm_smmuv3, "arm,smmu-v3", NULL);
+IOMMU_OF_DECLARE(arm_smmuv3, "arm,smmu-v3");
MODULE_DESCRIPTION("IOMMU API for ARM architected SMMUv3 implementations");
MODULE_AUTHOR("Will Deacon <will.deacon@arm.com>");
diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index 78d4c6b8f1ba..69e7c60792a8 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -2211,12 +2211,12 @@ static struct platform_driver arm_smmu_driver = {
};
module_platform_driver(arm_smmu_driver);
-IOMMU_OF_DECLARE(arm_smmuv1, "arm,smmu-v1", NULL);
-IOMMU_OF_DECLARE(arm_smmuv2, "arm,smmu-v2", NULL);
-IOMMU_OF_DECLARE(arm_mmu400, "arm,mmu-400", NULL);
-IOMMU_OF_DECLARE(arm_mmu401, "arm,mmu-401", NULL);
-IOMMU_OF_DECLARE(arm_mmu500, "arm,mmu-500", NULL);
-IOMMU_OF_DECLARE(cavium_smmuv2, "cavium,smmu-v2", NULL);
+IOMMU_OF_DECLARE(arm_smmuv1, "arm,smmu-v1");
+IOMMU_OF_DECLARE(arm_smmuv2, "arm,smmu-v2");
+IOMMU_OF_DECLARE(arm_mmu400, "arm,mmu-400");
+IOMMU_OF_DECLARE(arm_mmu401, "arm,mmu-401");
+IOMMU_OF_DECLARE(arm_mmu500, "arm,mmu-500");
+IOMMU_OF_DECLARE(cavium_smmuv2, "cavium,smmu-v2");
MODULE_DESCRIPTION("IOMMU API for ARM architected SMMU implementations");
MODULE_AUTHOR("Will Deacon <will.deacon@arm.com>");
diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c
index 736d4552d96f..2138102ef611 100644
--- a/drivers/iommu/exynos-iommu.c
+++ b/drivers/iommu/exynos-iommu.c
@@ -1401,4 +1401,4 @@ static int __init exynos_iommu_init(void)
}
core_initcall(exynos_iommu_init);
-IOMMU_OF_DECLARE(exynos_iommu_of, "samsung,exynos-sysmmu", NULL);
+IOMMU_OF_DECLARE(exynos_iommu_of, "samsung,exynos-sysmmu");
diff --git a/drivers/iommu/ipmmu-vmsa.c b/drivers/iommu/ipmmu-vmsa.c
index 331dad909301..40ae6e87cb88 100644
--- a/drivers/iommu/ipmmu-vmsa.c
+++ b/drivers/iommu/ipmmu-vmsa.c
@@ -1108,8 +1108,8 @@ static void __exit ipmmu_exit(void)
subsys_initcall(ipmmu_init);
module_exit(ipmmu_exit);
-IOMMU_OF_DECLARE(ipmmu_vmsa_iommu_of, "renesas,ipmmu-vmsa", NULL);
-IOMMU_OF_DECLARE(ipmmu_r8a7795_iommu_of, "renesas,ipmmu-r8a7795", NULL);
+IOMMU_OF_DECLARE(ipmmu_vmsa_iommu_of, "renesas,ipmmu-vmsa");
+IOMMU_OF_DECLARE(ipmmu_r8a7795_iommu_of, "renesas,ipmmu-r8a7795");
MODULE_DESCRIPTION("IOMMU API for Renesas VMSA-compatible IPMMU");
MODULE_AUTHOR("Laurent Pinchart <laurent.pinchart@ideasonboard.com>");
diff --git a/drivers/iommu/msm_iommu.c b/drivers/iommu/msm_iommu.c
index dda1ce87a070..0d3350463a3f 100644
--- a/drivers/iommu/msm_iommu.c
+++ b/drivers/iommu/msm_iommu.c
@@ -877,7 +877,7 @@ static void __exit msm_iommu_driver_exit(void)
subsys_initcall(msm_iommu_driver_init);
module_exit(msm_iommu_driver_exit);
-IOMMU_OF_DECLARE(msm_iommu_of, "qcom,apq8064-iommu", NULL);
+IOMMU_OF_DECLARE(msm_iommu_of, "qcom,apq8064-iommu");
MODULE_LICENSE("GPL v2");
MODULE_AUTHOR("Stepan Moskovchenko <stepanm@codeaurora.org>");
diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
index 50947ebb6d17..5c36a8b7656a 100644
--- a/drivers/iommu/of_iommu.c
+++ b/drivers/iommu/of_iommu.c
@@ -231,19 +231,3 @@ const struct iommu_ops *of_iommu_configure(struct device *dev,
return ops;
}
-
-static int __init of_iommu_init(void)
-{
- struct device_node *np;
- const struct of_device_id *match, *matches = &__iommu_of_table;
-
- for_each_matching_node_and_match(np, matches, &match) {
- const of_iommu_init_fn init_fn = match->data;
-
- if (init_fn && init_fn(np))
- pr_err("Failed to initialise IOMMU %pOF\n", np);
- }
-
- return 0;
-}
-postcore_initcall_sync(of_iommu_init);
diff --git a/drivers/iommu/qcom_iommu.c b/drivers/iommu/qcom_iommu.c
index e07f02d00c68..65b9c99707f8 100644
--- a/drivers/iommu/qcom_iommu.c
+++ b/drivers/iommu/qcom_iommu.c
@@ -947,7 +947,7 @@ static void __exit qcom_iommu_exit(void)
module_init(qcom_iommu_init);
module_exit(qcom_iommu_exit);
-IOMMU_OF_DECLARE(qcom_iommu_dev, "qcom,msm-iommu-v1", NULL);
+IOMMU_OF_DECLARE(qcom_iommu_dev, "qcom,msm-iommu-v1");
MODULE_DESCRIPTION("IOMMU API for QCOM IOMMU v1 implementations");
MODULE_LICENSE("GPL v2");
diff --git a/include/linux/of_iommu.h b/include/linux/of_iommu.h
index cddfaff4d0b7..4fa654e4b5a9 100644
--- a/include/linux/of_iommu.h
+++ b/include/linux/of_iommu.h
@@ -34,9 +34,6 @@ static inline const struct iommu_ops *of_iommu_configure(struct device *dev,
extern struct of_device_id __iommu_of_table;
-typedef int (*of_iommu_init_fn)(struct device_node *);
-
-#define IOMMU_OF_DECLARE(name, compat, fn) \
- _OF_DECLARE(iommu, name, compat, fn, of_iommu_init_fn)
+#define IOMMU_OF_DECLARE(name, compat) OF_DECLARE_1(iommu, name, compat, NULL)
#endif /* __OF_IOMMU_H */
--
2.13.4.dirty
^ permalink raw reply related
* [PATCH v2 2/3] iommu/ipmmu-vmsa: Remove redundant of_iommu_init_fn hook
From: Robin Murphy @ 2018-01-09 16:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <da664cf8f60c77cbb657cc2e3849560604eaf6da.1515512134.git.robin.murphy@arm.com>
Having of_iommu_init() call ipmmu_init() via ipmmu_vmsa_iommu_of_setup()
does nothing that the subsys_initcall wouldn't do slightly later anyway,
since probe-deferral of masters means it is no longer critical to
register the driver super-early. Clean it up.
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
---
v2: New (somehow v1 was based on 4.14-rc3 so missed this...)
drivers/iommu/ipmmu-vmsa.c | 14 ++------------
1 file changed, 2 insertions(+), 12 deletions(-)
diff --git a/drivers/iommu/ipmmu-vmsa.c b/drivers/iommu/ipmmu-vmsa.c
index 8dce3a9de9d8..331dad909301 100644
--- a/drivers/iommu/ipmmu-vmsa.c
+++ b/drivers/iommu/ipmmu-vmsa.c
@@ -1108,18 +1108,8 @@ static void __exit ipmmu_exit(void)
subsys_initcall(ipmmu_init);
module_exit(ipmmu_exit);
-#ifdef CONFIG_IOMMU_DMA
-static int __init ipmmu_vmsa_iommu_of_setup(struct device_node *np)
-{
- ipmmu_init();
- return 0;
-}
-
-IOMMU_OF_DECLARE(ipmmu_vmsa_iommu_of, "renesas,ipmmu-vmsa",
- ipmmu_vmsa_iommu_of_setup);
-IOMMU_OF_DECLARE(ipmmu_r8a7795_iommu_of, "renesas,ipmmu-r8a7795",
- ipmmu_vmsa_iommu_of_setup);
-#endif
+IOMMU_OF_DECLARE(ipmmu_vmsa_iommu_of, "renesas,ipmmu-vmsa", NULL);
+IOMMU_OF_DECLARE(ipmmu_r8a7795_iommu_of, "renesas,ipmmu-r8a7795", NULL);
MODULE_DESCRIPTION("IOMMU API for Renesas VMSA-compatible IPMMU");
MODULE_AUTHOR("Laurent Pinchart <laurent.pinchart@ideasonboard.com>");
--
2.13.4.dirty
^ permalink raw reply related
* [PATCH v2 1/3] iommu/msm: Claim bus ops on probe
From: Robin Murphy @ 2018-01-09 16:17 UTC (permalink / raw)
To: linux-arm-kernel
Since the MSM IOMMU driver now probes via DT exclusively rather than
platform data, dependent masters should be deferred until the IOMMU
itself is ready. Thus we can do away with the early initialisation
hook to unconditionally claim the bus ops, and instead do that only
once an IOMMU is actually probed. Furthermore, this should also make
the driver safe for multiplatform kernels on non-MSM SoCs.
Reviewed-by: Sricharan R <sricharan@codeaurora.org>
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
---
v2: Rebase to 4.15-rc, add tags
drivers/iommu/msm_iommu.c | 16 +++-------------
1 file changed, 3 insertions(+), 13 deletions(-)
diff --git a/drivers/iommu/msm_iommu.c b/drivers/iommu/msm_iommu.c
index 04f4d51ffacb..dda1ce87a070 100644
--- a/drivers/iommu/msm_iommu.c
+++ b/drivers/iommu/msm_iommu.c
@@ -823,6 +823,8 @@ static int msm_iommu_probe(struct platform_device *pdev)
goto fail;
}
+ bus_set_iommu(&platform_bus_type, &msm_iommu_ops);
+
pr_info("device mapped at %p, irq %d with %d ctx banks\n",
iommu->base, iommu->irq, iommu->ncb);
@@ -875,19 +877,7 @@ static void __exit msm_iommu_driver_exit(void)
subsys_initcall(msm_iommu_driver_init);
module_exit(msm_iommu_driver_exit);
-static int __init msm_iommu_init(void)
-{
- bus_set_iommu(&platform_bus_type, &msm_iommu_ops);
- return 0;
-}
-
-static int __init msm_iommu_of_setup(struct device_node *np)
-{
- msm_iommu_init();
- return 0;
-}
-
-IOMMU_OF_DECLARE(msm_iommu_of, "qcom,apq8064-iommu", msm_iommu_of_setup);
+IOMMU_OF_DECLARE(msm_iommu_of, "qcom,apq8064-iommu", NULL);
MODULE_LICENSE("GPL v2");
MODULE_AUTHOR("Stepan Moskovchenko <stepanm@codeaurora.org>");
--
2.13.4.dirty
^ permalink raw reply related
* [PATCH v3 11/13] arm64: Implement branch predictor hardening for affected Cortex-A CPUs
From: Suzuki K Poulose @ 2018-01-09 16:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1515432758-26440-12-git-send-email-will.deacon@arm.com>
On 08/01/18 17:32, Will Deacon wrote:
> Cortex-A57, A72, A73 and A75 are susceptible to branch predictor aliasing
> and can theoretically be attacked by malicious code.
>
> This patch implements a PSCI-based mitigation for these CPUs when available.
> The call into firmware will invalidate the branch predictor state, preventing
> any malicious entries from affecting other victim contexts.
>
> Co-developed-by: Marc Zyngier <marc.zyngier@arm.com>
> Signed-off-by: Will Deacon <will.deacon@arm.com>
Will, Marc,
> +#ifdef CONFIG_HARDEN_BRANCH_PREDICTOR
> + {
> + .capability = ARM64_HARDEN_BRANCH_PREDICTOR,
> + MIDR_ALL_VERSIONS(MIDR_CORTEX_A57),
> + .enable = enable_psci_bp_hardening,
> + },
> + {
> + .capability = ARM64_HARDEN_BRANCH_PREDICTOR,
> + MIDR_ALL_VERSIONS(MIDR_CORTEX_A72),
> + .enable = enable_psci_bp_hardening,
> + },
> + {
> + .capability = ARM64_HARDEN_BRANCH_PREDICTOR,
> + MIDR_ALL_VERSIONS(MIDR_CORTEX_A73),
> + .enable = enable_psci_bp_hardening,
> + },
> + {
> + .capability = ARM64_HARDEN_BRANCH_PREDICTOR,
> + MIDR_ALL_VERSIONS(MIDR_CORTEX_A75),
> + .enable = enable_psci_bp_hardening,
> + },
> +#endif
The introduction of multiple entries for the same capability breaks
some assumptions in this_cpu_has_caps() and verify_local_cpu_features()
as they all stop at the first entry matching the "capability" and could
return wrong results. We need something like the following to make this
work, should someone add duplicate feature entry or use
this_cpu_has_caps() on one of the errata.
---8>---
arm64: capabilities: Handle duplicate entries for a capability
Sometimes a single capability could be listed multiple times with
differing matches(), e.g, CPU errata for different MIDR versions.
This breaks verify_local_cpu_feature() and this_cpu_has_cap() as
we stop checking for a capability on a CPU with the first
entry in the given table, which is not sufficient. Make sure we
run the checks for all entries of the same capability. We do
this by fixing __this_cpu_has_cap() to run through all the
entries in the given table for a match and reuse it for
verify_local_cpu_feature().
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
---
arch/arm64/kernel/cpufeature.c | 44 ++++++++++++++++++++++--------------------
1 file changed, 23 insertions(+), 21 deletions(-)
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index 862a417ca0e2..0c43447f7406 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -1120,6 +1120,26 @@ static void __init setup_elf_hwcaps(const struct arm64_cpu_capabilities *hwcaps)
cap_set_elf_hwcap(hwcaps);
}
+/*
+ * Check if the current CPU has a given feature capability.
+ * Should be called from non-preemptible context.
+ */
+static bool __this_cpu_has_cap(const struct arm64_cpu_capabilities *cap_array,
+ unsigned int cap)
+{
+ const struct arm64_cpu_capabilities *caps;
+
+ if (WARN_ON(preemptible()))
+ return false;
+
+ for (caps = cap_array; caps->desc; caps++)
+ if (caps->capability == cap &&
+ caps->matches &&
+ caps->matches(caps, SCOPE_LOCAL_CPU))
+ return true;
+ return false;
+}
+
void update_cpu_capabilities(const struct arm64_cpu_capabilities *caps,
const char *info)
{
@@ -1183,8 +1203,9 @@ verify_local_elf_hwcaps(const struct arm64_cpu_capabilities *caps)
}
static void
-verify_local_cpu_features(const struct arm64_cpu_capabilities *caps)
+verify_local_cpu_features(const struct arm64_cpu_capabilities *caps_list)
{
+ const struct arm64_cpu_capabilities *caps = caps_list;
for (; caps->matches; caps++) {
if (!cpus_have_cap(caps->capability))
continue;
@@ -1192,7 +1213,7 @@ verify_local_cpu_features(const struct arm64_cpu_capabilities *caps)
* If the new CPU misses an advertised feature, we cannot proceed
* further, park the cpu.
*/
- if (!caps->matches(caps, SCOPE_LOCAL_CPU)) {
+ if (!__this_cpu_has_cap(caps_list, caps->capability)) {
pr_crit("CPU%d: missing feature: %s\n",
smp_processor_id(), caps->desc);
cpu_die_early();
@@ -1274,25 +1295,6 @@ static void __init mark_const_caps_ready(void)
static_branch_enable(&arm64_const_caps_ready);
}
-/*
- * Check if the current CPU has a given feature capability.
- * Should be called from non-preemptible context.
- */
-static bool __this_cpu_has_cap(const struct arm64_cpu_capabilities *cap_array,
- unsigned int cap)
-{
- const struct arm64_cpu_capabilities *caps;
-
- if (WARN_ON(preemptible()))
- return false;
-
- for (caps = cap_array; caps->desc; caps++)
- if (caps->capability == cap && caps->matches)
- return caps->matches(caps, SCOPE_LOCAL_CPU);
-
- return false;
-}
-
extern const struct arm64_cpu_capabilities arm64_errata[];
bool this_cpu_has_cap(unsigned int cap)
--
2.13.6
^ permalink raw reply related
* [PATCH v2 2/7] PCI: aardvark: set PIO_ADDR_LS correctly in advk_pcie_rd_conf()
From: Thomas Petazzoni @ 2018-01-09 16:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171005172545.GQ25517@bhelgaas-glaptop.roam.corp.google.com>
Hello,
On Thu, 5 Oct 2017 12:25:45 -0500, Bjorn Helgaas wrote:
> > diff --git a/drivers/pci/host/pci-aardvark.c b/drivers/pci/host/pci-aardvark.c
> > index da2881ba7737..af7a9c4a61a4 100644
> > --- a/drivers/pci/host/pci-aardvark.c
> > +++ b/drivers/pci/host/pci-aardvark.c
> > @@ -459,7 +459,7 @@ static int advk_pcie_rd_conf(struct pci_bus *bus, u32 devfn,
> > advk_writel(pcie, reg, PIO_CTRL);
> >
> > /* Program the address registers */
> > - reg = PCIE_BDF(devfn) | PCIE_CONF_REG(where);
> > + reg = PCIE_CONF_ADDR(bus->number, devfn, where);
>
> I think PCIE_BDF() is now unused and should be removed.
True, I'll fix this in v3.
Thanks!
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH] pwm: mediatek: fix up PWM4 and PWM5 malfunction on MT7623
From: Sean Wang @ 2018-01-09 16:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <0ebe339a-f40e-8567-e475-a0e671409777@gmail.com>
On Tue, 2018-01-09 at 16:32 +0100, Matthias Brugger wrote:
>
> On 12/25/2017 03:59 PM, sean.wang at mediatek.com wrote:
> > From: Sean Wang <sean.wang@mediatek.com>
> >
> > Since the offset for both registers, PWMDWIDTH and PWMTHRES, used to
> > control PWM4 or PWM5 are distinct from the other PWMs, whose wrong
> > programming on PWM hardware causes waveform cannot be output as expected.
> > Thus, the patch adds the extra condition for fixing up the weird case to
> > let PWM4 or PWM5 able to work on MT7623.
> >
> > Signed-off-by: Sean Wang <sean.wang@mediatek.com>
> > Cc: Zhi Mao <zhi.mao@mediatek.com>
> > Cc: John Crispin <john@phrozen.org>
> > ---
> > drivers/pwm/pwm-mediatek.c | 24 +++++++++++++++++++++---
> > 1 file changed, 21 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/pwm/pwm-mediatek.c b/drivers/pwm/pwm-mediatek.c
> > index f5d97e0..9311574 100644
> > --- a/drivers/pwm/pwm-mediatek.c
> > +++ b/drivers/pwm/pwm-mediatek.c
> > @@ -29,7 +29,9 @@
> > #define PWMGDUR 0x0c
> > #define PWMWAVENUM 0x28
> > #define PWMDWIDTH 0x2c
> > +#define PWM45DWIDTH_QUIRK 0x30
> > #define PWMTHRES 0x30
> > +#define PWM45THRES_QUIRK 0x34
> >
> > #define PWM_CLK_DIV_MAX 7
> >
> > @@ -54,6 +56,7 @@ static const char * const mtk_pwm_clk_name[MTK_CLK_MAX] = {
> >
> > struct mtk_pwm_platform_data {
> > unsigned int num_pwms;
> > + bool pwm45_quirk;
> > };
> >
> > /**
> > @@ -66,6 +69,7 @@ struct mtk_pwm_chip {
> > struct pwm_chip chip;
> > void __iomem *regs;
> > struct clk *clks[MTK_CLK_MAX];
> > + const struct mtk_pwm_platform_data *soc;
> > };
> >
> > static const unsigned int mtk_pwm_reg_offset[] = {
> > @@ -131,7 +135,8 @@ static int mtk_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm,
> > {
> > struct mtk_pwm_chip *pc = to_mtk_pwm_chip(chip);
> > struct clk *clk = pc->clks[MTK_CLK_PWM1 + pwm->hwpwm];
> > - u32 resolution, clkdiv = 0;
> > + u32 resolution, clkdiv = 0, reg_width = PWMDWIDTH,
> > + reg_thres = PWMTHRES;
> > int ret;
> >
> > ret = mtk_pwm_clk_enable(chip, pwm);
> > @@ -151,9 +156,18 @@ static int mtk_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm,
> > return -EINVAL;
> > }
> >
> > + if (pc->soc->pwm45_quirk && pwm->hwpwm > 2) {
> > + /*
> > + * PWM[4,5] has distinct offset for PWMDWIDTH and PWMTHRES
> > + * from the other PWMs on MT7623.
> > + */
> > + reg_width = PWM45DWIDTH_QUIRK;
> > + reg_thres = PWM45THRES_QUIRK;
> > + }
> > +
> > mtk_pwm_writel(pc, pwm->hwpwm, PWMCON, BIT(15) | clkdiv);
> > - mtk_pwm_writel(pc, pwm->hwpwm, PWMDWIDTH, period_ns / resolution);
> > - mtk_pwm_writel(pc, pwm->hwpwm, PWMTHRES, duty_ns / resolution);
> > + mtk_pwm_writel(pc, pwm->hwpwm, reg_width, period_ns / resolution);
> > + mtk_pwm_writel(pc, pwm->hwpwm, reg_thres, duty_ns / resolution);
> >
> > mtk_pwm_clk_disable(chip, pwm);
> >
> > @@ -211,6 +225,7 @@ static int mtk_pwm_probe(struct platform_device *pdev)
> > data = of_device_get_match_data(&pdev->dev);
> > if (data == NULL)
> > return -EINVAL;
> > + pc->soc = data;
> >
> > res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > pc->regs = devm_ioremap_resource(&pdev->dev, res);
> > @@ -251,14 +266,17 @@ static int mtk_pwm_remove(struct platform_device *pdev)
> >
> > static const struct mtk_pwm_platform_data mt2712_pwm_data = {
> > .num_pwms = 8,
> > + .pwm45_quirk = false,
>
> Hm for me it doesn't look like a quirk but just the values a different. I wonder
> why you decided to add a quirk flag.
actually, I also felt using quirk is not proper naming here. It should
be worth of better naming than the one to describe the hardware weird
case that only happens on PWM4 and PWM5. do you have idea what naming is
better?
> I'd added the access values to the
> mtk_pwm_platform_data struct directly.
do you mean should I add extra fields in struct mtk_pwm_platform to hold
its WIDTH and THRES for PWM4, and PWM5 value for each platform?
But these data aren't useful for the other platform, it would take one
more byte, and the extra conditional checked also cannot be saved. So,
I think to add one flag seems to produce the lesser penalty.
Regards,
> Matthias
>
^ permalink raw reply
* [PATCH v5 6/6] ARM: imx_v6_v7_defconfig: Enable Dialog Semiconductor DA9062 driver
From: Stefan Riedmueller @ 2018-01-09 16:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1515514200-9801-1-git-send-email-s.riedmueller@phytec.de>
The phyCORE-i.MX 6 uses the DA9062/63 PMIC, RTC and Watchdog driver.
Enable these options by default.
Signed-off-by: Stefan Riedmueller <s.riedmueller@phytec.de>
Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
---
arch/arm/configs/imx_v6_v7_defconfig | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm/configs/imx_v6_v7_defconfig b/arch/arm/configs/imx_v6_v7_defconfig
index 6726c83..e3c4163 100644
--- a/arch/arm/configs/imx_v6_v7_defconfig
+++ b/arch/arm/configs/imx_v6_v7_defconfig
@@ -216,8 +216,10 @@ CONFIG_THERMAL_WRITABLE_TRIPS=y
CONFIG_CPU_THERMAL=y
CONFIG_IMX_THERMAL=y
CONFIG_WATCHDOG=y
+CONFIG_DA9062_WATCHDOG=y
CONFIG_IMX2_WDT=y
CONFIG_MFD_DA9052_I2C=y
+CONFIG_MFD_DA9062=y
CONFIG_MFD_MC13XXX_SPI=y
CONFIG_MFD_MC13XXX_I2C=y
CONFIG_MFD_STMPE=y
@@ -225,6 +227,7 @@ CONFIG_REGULATOR=y
CONFIG_REGULATOR_FIXED_VOLTAGE=y
CONFIG_REGULATOR_ANATOP=y
CONFIG_REGULATOR_DA9052=y
+CONFIG_REGULATOR_DA9062=y
CONFIG_REGULATOR_GPIO=y
CONFIG_REGULATOR_MC13783=y
CONFIG_REGULATOR_MC13892=y
@@ -348,6 +351,7 @@ CONFIG_RTC_DRV_ISL1208=y
CONFIG_RTC_DRV_PCF8523=y
CONFIG_RTC_DRV_PCF8563=y
CONFIG_RTC_DRV_M41T80=y
+CONFIG_RTC_DRV_DA9063=y
CONFIG_RTC_DRV_MC13XXX=y
CONFIG_RTC_DRV_MXC=y
CONFIG_RTC_DRV_SNVS=y
--
2.7.4
^ permalink raw reply related
* [PATCH v5 5/6] ARM: dts: imx6: Add support for phyBOARD-Mira with i.MX 6QuadPlus
From: Stefan Riedmueller @ 2018-01-09 16:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1515514200-9801-1-git-send-email-s.riedmueller@phytec.de>
From: Enrico Scholz <enrico.scholz@sigma-chemnitz.de>
Add support for the PHYTEC phyBOARD-Mira with i.MX 6QuadPlus with NAND.
It is based on the phyBOARD-Mira with i.MX 6Quad/Dual and supports the
same interfaces.
Signed-off-by: Enrico Scholz <enrico.scholz@sigma-chemnitz.de>
Signed-off-by: Stefan Lengfeld <s.lengfeld@phytec.de>
Signed-off-by: Christian Hemp <c.hemp@phytec.de>
Signed-off-by: Stefan Riedmueller <s.riedmueller@phytec.de>
Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/imx6qp-phytec-mira-rdk-nand.dts | 72 +++++++++++++++++++++++
2 files changed, 73 insertions(+)
create mode 100644 arch/arm/boot/dts/imx6qp-phytec-mira-rdk-nand.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 07d99a1..d42b522 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -479,6 +479,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
imx6q-zii-rdu2.dtb \
imx6qp-nitrogen6_max.dtb \
imx6qp-nitrogen6_som2.dtb \
+ imx6qp-phytec-mira-rdk-nand.dtb \
imx6qp-sabreauto.dtb \
imx6qp-sabresd.dtb \
imx6qp-tx6qp-8037.dtb \
diff --git a/arch/arm/boot/dts/imx6qp-phytec-mira-rdk-nand.dts b/arch/arm/boot/dts/imx6qp-phytec-mira-rdk-nand.dts
new file mode 100644
index 0000000..3618e53
--- /dev/null
+++ b/arch/arm/boot/dts/imx6qp-phytec-mira-rdk-nand.dts
@@ -0,0 +1,72 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (C) 2018 PHYTEC Messtechnik GmbH
+ * Author: Enrico Scholz <enrico.scholz@sigma-chemnitz.de>
+ */
+
+/dts-v1/;
+#include "imx6qp.dtsi"
+#include "imx6qdl-phytec-phycore-som.dtsi"
+#include "imx6qdl-phytec-mira.dtsi"
+
+/ {
+ model = "PHYTEC phyBOARD-Mira QuadPlus Carrier-Board with NAND";
+ compatible = "phytec,imx6qp-pbac06-nand", "phytec,imx6qp-pbac06",
+ "phytec,imx6qdl-pcm058", "fsl,imx6qp";
+
+ chosen {
+ linux,stdout-path = &uart2;
+ };
+};
+
+&can1 {
+ status = "okay";
+};
+
+&fec {
+ status = "okay";
+};
+
+&gpmi {
+ status = "okay";
+};
+
+&hdmi {
+ status = "okay";
+};
+
+&i2c1 {
+ status = "okay";
+};
+
+&i2c2 {
+ status = "okay";
+};
+
+&i2c_rtc {
+ status = "okay";
+};
+
+&m25p80 {
+ status = "okay";
+};
+
+&pcie {
+ status = "okay";
+};
+
+&uart3 {
+ status = "okay";
+};
+
+&usbh1 {
+ status = "okay";
+};
+
+&usbotg {
+ status = "okay";
+};
+
+&usdhc1 {
+ status = "okay";
+};
--
2.7.4
^ permalink raw reply related
* [PATCH v5 4/6] ARM: dts: imx6: Add support for phyBOARD-Mira i.MX 6 DualLight/Solo RDK
From: Stefan Riedmueller @ 2018-01-09 16:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1515514200-9801-1-git-send-email-s.riedmueller@phytec.de>
From: Christian Hemp <c.hemp@phytec.de>
Add support for the PHYTEC phyBOARD-Mira Low-Cost Rapid Development Kit
with i.MX 6DualLight/Solo with NAND.
Following interfaces are supported:
- 100 MBit Ethernet
- USB Host
- RS232
- HDMI
Signed-off-by: Christian Hemp <c.hemp@phytec.de>
Signed-off-by: Stefan Christ <s.christ@phytec.de>
Signed-off-by: Stefan Riedmueller <s.riedmueller@phytec.de>
Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/imx6dl-phytec-mira-rdk-nand.dts | 64 +++++++++++++++++++++++
2 files changed, 65 insertions(+)
create mode 100644 arch/arm/boot/dts/imx6dl-phytec-mira-rdk-nand.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index b793617..07d99a1 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -388,6 +388,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
imx6dl-icore-rqs.dtb \
imx6dl-nit6xlite.dtb \
imx6dl-nitrogen6x.dtb \
+ imx6dl-phytec-mira-rdk-nand.dtb \
imx6dl-phytec-pbab01.dtb \
imx6dl-rex-basic.dtb \
imx6dl-riotboard.dtb \
diff --git a/arch/arm/boot/dts/imx6dl-phytec-mira-rdk-nand.dts b/arch/arm/boot/dts/imx6dl-phytec-mira-rdk-nand.dts
new file mode 100644
index 0000000..a8adcb2
--- /dev/null
+++ b/arch/arm/boot/dts/imx6dl-phytec-mira-rdk-nand.dts
@@ -0,0 +1,64 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (C) 2018 PHYTEC Messtechnik GmbH
+ * Author: Christian Hemp <c.hemp@phytec.de>
+ */
+
+/dts-v1/;
+#include "imx6dl.dtsi"
+#include "imx6qdl-phytec-phycore-som.dtsi"
+#include "imx6qdl-phytec-mira.dtsi"
+
+/ {
+ model = "PHYTEC phyBOARD-Mira DualLite/Solo Carrier-Board with NAND";
+ compatible = "phytec,imx6dl-pbac06-nand", "phytec,imx6dl-pbac06",
+ "phytec,imx6qdl-pcm058", "fsl,imx6dl";
+
+ chosen {
+ linux,stdout-path = &uart2;
+ };
+};
+
+ðphy {
+ max-speed = <100>;
+};
+
+&fec {
+ status = "okay";
+};
+
+&gpmi {
+ status = "okay";
+};
+
+&hdmi {
+ status = "okay";
+};
+
+&i2c1 {
+ status = "okay";
+};
+
+&i2c2 {
+ status = "okay";
+};
+
+&i2c_rtc {
+ status = "okay";
+};
+
+&uart3 {
+ status = "okay";
+};
+
+&usbh1 {
+ status = "okay";
+};
+
+&usbotg {
+ status = "okay";
+};
+
+&usdhc1 {
+ status = "okay";
+};
--
2.7.4
^ permalink raw reply related
* [PATCH v5 3/6] ARM: dts: imx6: Add support for phyBOARD-Mira i.MX 6Quad/Dual RDK
From: Stefan Riedmueller @ 2018-01-09 16:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1515514200-9801-1-git-send-email-s.riedmueller@phytec.de>
From: Christian Hemp <c.hemp@phytec.de>
Add support for the PHYTEC phyBOARD-Mira Rapid Development Kit with
i.MX 6Quad/Dual with eMMC or NAND.
Following interfaces are supported:
- Gigabit Ethernet
- USB Host
- CAN
- RS232
- PCIe
- LVDS
- HDMI
Signed-off-by: Christian Hemp <c.hemp@phytec.de>
Signed-off-by: Stefan Christ <s.christ@phytec.de>
Signed-off-by: Stefan Riedmueller <s.riedmueller@phytec.de>
Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
---
arch/arm/boot/dts/Makefile | 2 +
arch/arm/boot/dts/imx6q-phytec-mira-rdk-emmc.dts | 72 ++++++++++++++++++++++++
arch/arm/boot/dts/imx6q-phytec-mira-rdk-nand.dts | 72 ++++++++++++++++++++++++
3 files changed, 146 insertions(+)
create mode 100644 arch/arm/boot/dts/imx6q-phytec-mira-rdk-emmc.dts
create mode 100644 arch/arm/boot/dts/imx6q-phytec-mira-rdk-nand.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index d0381e9..b793617 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -449,6 +449,8 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
imx6q-nitrogen6_max.dtb \
imx6q-nitrogen6_som2.dtb \
imx6q-novena.dtb \
+ imx6q-phytec-mira-rdk-emmc.dtb \
+ imx6q-phytec-mira-rdk-nand.dtb \
imx6q-phytec-pbab01.dtb \
imx6q-pistachio.dtb \
imx6q-rex-pro.dtb \
diff --git a/arch/arm/boot/dts/imx6q-phytec-mira-rdk-emmc.dts b/arch/arm/boot/dts/imx6q-phytec-mira-rdk-emmc.dts
new file mode 100644
index 0000000..8fdce3c
--- /dev/null
+++ b/arch/arm/boot/dts/imx6q-phytec-mira-rdk-emmc.dts
@@ -0,0 +1,72 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (C) 2018 PHYTEC Messtechnik GmbH
+ * Author: Christian Hemp <c.hemp@phytec.de>
+ */
+
+/dts-v1/;
+#include "imx6q.dtsi"
+#include "imx6qdl-phytec-phycore-som.dtsi"
+#include "imx6qdl-phytec-mira.dtsi"
+
+/ {
+ model = "PHYTEC phyBOARD-Mira Quad Carrier-Board with eMMC";
+ compatible = "phytec,imx6q-pbac06-emmc", "phytec,imx6q-pbac06",
+ "phytec,imx6qdl-pcm058", "fsl,imx6q";
+
+ chosen {
+ linux,stdout-path = &uart2;
+ };
+};
+
+&can1 {
+ status = "okay";
+};
+
+&fec {
+ status = "okay";
+};
+
+&hdmi {
+ status = "okay";
+};
+
+&i2c1 {
+ status = "okay";
+};
+
+&i2c2 {
+ status = "okay";
+};
+
+&i2c_rtc {
+ status = "okay";
+};
+
+&m25p80 {
+ status = "okay";
+};
+
+&pcie {
+ status = "okay";
+};
+
+&uart3 {
+ status = "okay";
+};
+
+&usbh1 {
+ status = "okay";
+};
+
+&usbotg {
+ status = "okay";
+};
+
+&usdhc1 {
+ status = "okay";
+};
+
+&usdhc4 {
+ status = "okay";
+};
diff --git a/arch/arm/boot/dts/imx6q-phytec-mira-rdk-nand.dts b/arch/arm/boot/dts/imx6q-phytec-mira-rdk-nand.dts
new file mode 100644
index 0000000..8afa5ce
--- /dev/null
+++ b/arch/arm/boot/dts/imx6q-phytec-mira-rdk-nand.dts
@@ -0,0 +1,72 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (C) 2018 PHYTEC Messtechnik GmbH
+ * Author: Christian Hemp <c.hemp@phytec.de>
+ */
+
+/dts-v1/;
+#include "imx6q.dtsi"
+#include "imx6qdl-phytec-phycore-som.dtsi"
+#include "imx6qdl-phytec-mira.dtsi"
+
+/ {
+ model = "PHYTEC phyBOARD-Mira Quad Carrier-Board with NAND";
+ compatible = "phytec,imx6q-pbac06-nand", "phytec,imx6q-pbac06",
+ "phytec,imx6qdl-pcm058", "fsl,imx6q";
+
+ chosen {
+ linux,stdout-path = &uart2;
+ };
+};
+
+&can1 {
+ status = "okay";
+};
+
+&fec {
+ status = "okay";
+};
+
+&gpmi {
+ status = "okay";
+};
+
+&hdmi {
+ status = "okay";
+};
+
+&i2c1 {
+ status = "okay";
+};
+
+&i2c2 {
+ status = "okay";
+};
+
+&i2c_rtc {
+ status = "okay";
+};
+
+&m25p80 {
+ status = "okay";
+};
+
+&pcie {
+ status = "okay";
+};
+
+&uart3 {
+ status = "okay";
+};
+
+&usbh1 {
+ status = "okay";
+};
+
+&usbotg {
+ status = "okay";
+};
+
+&usdhc1 {
+ status = "okay";
+};
--
2.7.4
^ permalink raw reply related
* [PATCH v5 2/6] ARM: dts: imx6: Add initial support for phyBOARD-Mira
From: Stefan Riedmueller @ 2018-01-09 16:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1515514200-9801-1-git-send-email-s.riedmueller@phytec.de>
This patch adds basic support for PHYTEC phyBOARD-Mira as carrier board
for PHYTEC phyCORE-i.MX 6.
Signed-off-by: Christian Hemp <c.hemp@phytec.de>
Signed-off-by: Stefan Christ <s.christ@phytec.de>
Signed-off-by: Christoph Fritz <chf.fritz@googlemail.com>
Signed-off-by: Stefan Riedmueller <s.riedmueller@phytec.de>
Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
---
arch/arm/boot/dts/imx6qdl-phytec-mira.dtsi | 390 +++++++++++++++++++++++++++++
1 file changed, 390 insertions(+)
create mode 100644 arch/arm/boot/dts/imx6qdl-phytec-mira.dtsi
diff --git a/arch/arm/boot/dts/imx6qdl-phytec-mira.dtsi b/arch/arm/boot/dts/imx6qdl-phytec-mira.dtsi
new file mode 100644
index 0000000..9ebd438
--- /dev/null
+++ b/arch/arm/boot/dts/imx6qdl-phytec-mira.dtsi
@@ -0,0 +1,390 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (C) 2018 PHYTEC Messtechnik GmbH
+ * Author: Christian Hemp <c.hemp@phytec.de>
+ */
+
+
+/ {
+ aliases {
+ rtc0 = &i2c_rtc;
+ };
+
+ backlight: backlight {
+ compatible = "pwm-backlight";
+ brightness-levels = <0 4 8 16 32 64 128 255>;
+ default-brightness-level = <7>;
+ power-supply = <®_backlight>;
+ pwms = <&pwm1 0 5000000>;
+ status = "okay";
+ };
+
+ gpio_leds: leds {
+ compatible = "gpio-leds";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_gpioleds>;
+ status = "disabled";
+
+ red {
+ label = "phyboard-mira:red";
+ gpios = <&gpio5 22 GPIO_ACTIVE_HIGH>;
+ };
+
+ green {
+ label = "phyboard-mira:green";
+ gpios = <&gpio5 23 GPIO_ACTIVE_HIGH>;
+ };
+
+ blue {
+ label = "phyboard-mira:blue";
+ gpios = <&gpio5 24 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "mmc0";
+ };
+ };
+
+ reg_backlight: regulator-backlight {
+ compatible = "regulator-fixed";
+ regulator-name = "backlight_3v3";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ };
+
+ reg_en_switch: regulator-en-switch {
+ compatible = "regulator-fixed";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_en_switch>;
+ regulator-name = "Enable Switch";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ enable-active-high;
+ gpio = <&gpio3 4 GPIO_ACTIVE_HIGH>;
+ regulator-always-on;
+ };
+
+ reg_flexcan1: regulator-flexcan1 {
+ compatible = "regulator-fixed";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_flexcan1_en>;
+ regulator-name = "flexcan1-reg";
+ regulator-min-microvolt = <1500000>;
+ regulator-max-microvolt = <1500000>;
+ gpio = <&gpio2 20 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
+ reg_panel: regulator-panel {
+ compatible = "regulator-fixed";
+ regulator-name = "panel-power-supply";
+ regulator-min-microvolt = <12000000>;
+ regulator-max-microvolt = <12000000>;
+ regulator-always-on;
+ };
+
+ reg_pcie: regulator-pcie {
+ compatible = "regulator-fixed";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_pcie_reg>;
+ regulator-name = "mPCIe_1V5";
+ regulator-min-microvolt = <1500000>;
+ regulator-max-microvolt = <1500000>;
+ gpio = <&gpio3 0 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
+ reg_usb_h1_vbus: usb-h1-vbus {
+ compatible = "regulator-fixed";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usbh1_vbus>;
+ regulator-name = "usb_h1_vbus";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ gpio = <&gpio2 18 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
+ reg_usbotg_vbus: usbotg-vbus {
+ compatible = "regulator-fixed";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usbotg_vbus>;
+ regulator-name = "usb_otg_vbus";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ gpio = <&gpio2 19 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
+ panel {
+ compatible = "auo,g104sn02";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_panel_en>;
+ power-supply = <®_panel>;
+ enable-gpios = <&gpio2 28 GPIO_ACTIVE_LOW>;
+ backlight = <&backlight>;
+
+ port {
+ panel_in: endpoint {
+ remote-endpoint = <&lvds0_out>;
+ };
+ };
+ };
+};
+
+&can1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_flexcan1>;
+ xceiver-supply = <®_flexcan1>;
+ status = "disabled";
+};
+
+&hdmi {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_hdmicec>;
+ ddc-i2c-bus = <&i2c2>;
+ status = "disabled";
+};
+
+&i2c1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c1>;
+ clock-frequency = <400000>;
+ status = "disabled";
+
+ stmpe: touchctrl at 44 {
+ compatible = "st,stmpe811";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_stmpe>;
+ reg = <0x44>;
+ interrupt-parent = <&gpio7>;
+ interrupts = <12 IRQ_TYPE_NONE>;
+ status = "disabled";
+
+ stmpe_touchscreen {
+ compatible = "st,stmpe-ts";
+ st,sample-time = <4>;
+ st,mod-12b = <1>;
+ st,ref-sel = <0>;
+ st,adc-freq = <1>;
+ st,ave-ctrl = <1>;
+ st,touch-det-delay = <2>;
+ st,settling = <2>;
+ st,fraction-z = <7>;
+ st,i-drive = <1>;
+ };
+ };
+
+ i2c_rtc: rtc at 68 {
+ compatible = "microcrystal,rv4162";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_rtc_int>;
+ reg = <0x68>;
+ interrupt-parent = <&gpio7>;
+ interrupts = <8 IRQ_TYPE_LEVEL_HIGH>;
+ status = "disabled";
+ };
+};
+
+&i2c2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c2>;
+ clock-frequency = <100000>;
+ status = "disabled";
+};
+
+&ldb {
+ status = "okay";
+
+ lvds-channel at 0 {
+ fsl,data-mapping = "spwg";
+ fsl,data-width = <24>;
+ status = "disabled";
+
+ port at 4 {
+ reg = <4>;
+
+ lvds0_out: endpoint {
+ remote-endpoint = <&panel_in>;
+ };
+ };
+ };
+};
+
+&pcie {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_pcie>;
+ reset-gpio = <&gpio2 25 GPIO_ACTIVE_LOW>;
+ vpcie-supply = <®_pcie>;
+ status = "disabled";
+};
+
+&pwm1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_pwm1>;
+ status = "okay";
+};
+
+&uart2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart2>;
+ status = "okay";
+};
+
+&uart3 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart3>;
+ uart-has-rtscts;
+ status = "disabled";
+};
+
+&usbh1 {
+ vbus-supply = <®_usb_h1_vbus>;
+ disable-over-current;
+ status = "disabled";
+};
+
+&usbotg {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usbotg>;
+ vbus-supply = <®_usbotg_vbus>;
+ disable-over-current;
+ status = "disabled";
+};
+
+&usdhc1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usdhc1>;
+ cd-gpios = <&gpio6 31 GPIO_ACTIVE_LOW>;
+ no-1-8-v;
+ status = "disabled";
+};
+
+&iomuxc {
+ pinctrl_panel_en: panelen1grp {
+ fsl,pins = <
+ MX6QDL_PAD_EIM_EB0__GPIO2_IO28 0xb0b1
+ >;
+ };
+
+ pinctrl_en_switch: enswitchgrp {
+ fsl,pins = <
+ MX6QDL_PAD_EIM_DA4__GPIO3_IO04 0xb0b1
+ >;
+ };
+
+ pinctrl_flexcan1: flexcan1grp {
+ fsl,pins = <
+ MX6QDL_PAD_GPIO_7__FLEXCAN1_TX 0x1b0b0
+ MX6QDL_PAD_GPIO_8__FLEXCAN1_RX 0x1b0b0
+ >;
+ };
+
+ pinctrl_flexcan1_en: flexcan1engrp {
+ fsl,pins = <
+ MX6QDL_PAD_EIM_A18__GPIO2_IO20 0xb0b1
+ >;
+ };
+
+ pinctrl_gpioleds: gpioledsgrp {
+ fsl,pins = <
+ MX6QDL_PAD_CSI0_DAT4__GPIO5_IO22 0x1b0b0
+ MX6QDL_PAD_CSI0_DAT5__GPIO5_IO23 0x1b0b0
+ MX6QDL_PAD_CSI0_DAT6__GPIO5_IO24 0x1b0b0
+ >;
+ };
+
+ pinctrl_hdmicec: hdmicecgrp {
+ fsl,pins = <
+ MX6QDL_PAD_KEY_ROW2__HDMI_TX_CEC_LINE 0x1f8b0
+ >;
+ };
+
+ pinctrl_i2c2: i2c2grp {
+ fsl,pins = <
+ MX6QDL_PAD_KEY_ROW3__I2C2_SDA 0x4001b8b1
+ MX6QDL_PAD_KEY_COL3__I2C2_SCL 0x4001b8b1
+ >;
+ };
+
+ pinctrl_i2c1: i2c1grp {
+ fsl,pins = <
+ MX6QDL_PAD_EIM_D21__I2C1_SCL 0x4001b8b1
+ MX6QDL_PAD_EIM_D28__I2C1_SDA 0x4001b8b1
+ >;
+ };
+
+ pinctrl_pcie: pciegrp {
+ fsl,pins = <
+ MX6QDL_PAD_EIM_OE__GPIO2_IO25 0xb0b1
+ >;
+ };
+
+ pinctrl_pcie_reg: pciereggrp {
+ fsl,pins = <
+ MX6QDL_PAD_EIM_DA0__GPIO3_IO00 0xb0b1
+ >;
+ };
+
+ pinctrl_pwm1: pwm1grp {
+ fsl,pins = <
+ MX6QDL_PAD_GPIO_9__PWM1_OUT 0x1b0b1
+ >;
+ };
+
+ pinctrl_rtc_int: rtcintgrp {
+ fsl,pins = <
+ MX6QDL_PAD_SD3_RST__GPIO7_IO08 0x1b0b0
+ >;
+ };
+
+ pinctrl_stmpe: stmpegrp {
+ fsl,pins = <
+ MX6QDL_PAD_GPIO_17__GPIO7_IO12 0x1b0b0
+ >;
+ };
+
+ pinctrl_uart2: uart2grp {
+ fsl,pins = <
+ MX6QDL_PAD_EIM_D26__UART2_TX_DATA 0x1b0b1
+ MX6QDL_PAD_EIM_D27__UART2_RX_DATA 0x1b0b1
+ >;
+ };
+
+ pinctrl_uart3: uart3grp {
+ fsl,pins = <
+ MX6QDL_PAD_EIM_EB3__UART3_CTS_B 0x1b0b1
+ MX6QDL_PAD_EIM_D23__UART3_RTS_B 0x1b0b1
+ MX6QDL_PAD_EIM_D24__UART3_TX_DATA 0x1b0b1
+ MX6QDL_PAD_EIM_D25__UART3_RX_DATA 0x1b0b1
+ >;
+ };
+
+ pinctrl_usbh1_vbus: usbh1vbusgrp {
+ fsl,pins = <
+ MX6QDL_PAD_EIM_A20__GPIO2_IO18 0xb0b1
+ >;
+ };
+
+ pinctrl_usbotg: usbotggrp {
+ fsl,pins = <
+ MX6QDL_PAD_GPIO_1__USB_OTG_ID 0x17059
+ >;
+ };
+
+ pinctrl_usbotg_vbus: usbotgvbusgrp {
+ fsl,pins = <
+ MX6QDL_PAD_EIM_A19__GPIO2_IO19 0xb0b1
+ >;
+ };
+
+ pinctrl_usdhc1: usdhc1grp {
+ fsl,pins = <
+ MX6QDL_PAD_SD1_CMD__SD1_CMD 0x170f9
+ MX6QDL_PAD_SD1_CLK__SD1_CLK 0x100f9
+ MX6QDL_PAD_SD1_DAT0__SD1_DATA0 0x170f9
+ MX6QDL_PAD_SD1_DAT1__SD1_DATA1 0x170f9
+ MX6QDL_PAD_SD1_DAT2__SD1_DATA2 0x170f9
+ MX6QDL_PAD_SD1_DAT3__SD1_DATA3 0x170f9
+ MX6QDL_PAD_EIM_BCLK__GPIO6_IO31 0xb0b1 /* CD */
+ >;
+ };
+};
--
2.7.4
^ permalink raw reply related
* [PATCH v5 1/6] ARM: dts: imx6: Add initial support for phyCORE-i.MX 6 SOM
From: Stefan Riedmueller @ 2018-01-09 16:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1515514200-9801-1-git-send-email-s.riedmueller@phytec.de>
This patch adds basic support for PHYTEC phyCORE-i.MX 6 SOM with i.MX
6Quad/Dual or i.MX 6DualLight/Solo.
Signed-off-by: Christian Hemp <c.hemp@phytec.de>
Signed-off-by: Stefan Christ <s.christ@phytec.de>
Signed-off-by: Christoph Fritz <chf.fritz@googlemail.com>
Signed-off-by: Stefan Riedmueller <s.riedmueller@phytec.de>
Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
---
arch/arm/boot/dts/imx6qdl-phytec-phycore-som.dtsi | 279 ++++++++++++++++++++++
1 file changed, 279 insertions(+)
create mode 100644 arch/arm/boot/dts/imx6qdl-phytec-phycore-som.dtsi
diff --git a/arch/arm/boot/dts/imx6qdl-phytec-phycore-som.dtsi b/arch/arm/boot/dts/imx6qdl-phytec-phycore-som.dtsi
new file mode 100644
index 0000000..6486df3
--- /dev/null
+++ b/arch/arm/boot/dts/imx6qdl-phytec-phycore-som.dtsi
@@ -0,0 +1,279 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (C) 2018 PHYTEC Messtechnik GmbH
+ * Author: Christian Hemp <c.hemp@phytec.de>
+ */
+
+#include <dt-bindings/gpio/gpio.h>
+
+/ {
+ aliases {
+ rtc1 = &da9062_rtc;
+ rtc2 = &snvs_rtc;
+ };
+
+ /*
+ * Set the minimum memory size here and
+ * let the bootloader set the real size.
+ */
+ memory at 10000000 {
+ device_type = "memory";
+ reg = <0x10000000 0x8000000>;
+ };
+
+ gpio_leds_som: somleds {
+ compatible = "gpio-leds";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_gpioleds_som>;
+
+ som-led-green {
+ label = "phycore:green";
+ gpios = <&gpio1 4 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "heartbeat";
+ };
+ };
+};
+
+&ecspi1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_ecspi1>;
+ cs-gpios = <&gpio3 19 GPIO_ACTIVE_LOW>;
+ status = "okay";
+
+ m25p80: flash at 0 {
+ compatible = "jedec,spi-nor";
+ spi-max-frequency = <20000000>;
+ reg = <0>;
+ status = "disabled";
+ };
+};
+
+&fec {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_enet>;
+ phy-handle = <ðphy>;
+ phy-mode = "rgmii";
+ phy-supply = <&vdd_eth_io>;
+ phy-reset-gpios = <&gpio1 14 GPIO_ACTIVE_LOW>;
+ status = "disabled";
+
+ mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ethphy: ethernet-phy at 3 {
+ reg = <3>;
+ txc-skew-ps = <1680>;
+ rxc-skew-ps = <1860>;
+ };
+ };
+};
+
+&gpmi {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_gpmi_nand>;
+ nand-on-flash-bbt;
+ status = "disabled";
+};
+
+&i2c3 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c3>;
+ clock-frequency = <400000>;
+ status = "okay";
+
+ eeprom at 50 {
+ compatible = "atmel,24c32";
+ reg = <0x50>;
+ };
+
+ pmic at 58 {
+ compatible = "dlg,da9062";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_pmic>;
+ reg = <0x58>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <2 IRQ_TYPE_LEVEL_LOW>;
+ interrupt-controller;
+
+ da9062_rtc: rtc {
+ compatible = "dlg,da9062-rtc";
+ };
+
+ watchdog {
+ compatible = "dlg,da9062-watchdog";
+ };
+
+ regulators {
+ vdd_arm: buck1 {
+ regulator-name = "vdd_arm";
+ regulator-min-microvolt = <730000>;
+ regulator-max-microvolt = <1380000>;
+ regulator-always-on;
+ };
+
+ vdd_soc: buck2 {
+ regulator-name = "vdd_soc";
+ regulator-min-microvolt = <730000>;
+ regulator-max-microvolt = <1380000>;
+ regulator-always-on;
+ };
+
+ vdd_ddr3_1p5: buck3 {
+ regulator-name = "vdd_ddr3";
+ regulator-min-microvolt = <1500000>;
+ regulator-max-microvolt = <1500000>;
+ regulator-always-on;
+ };
+
+ vdd_eth_1p2: buck4 {
+ regulator-name = "vdd_eth";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1200000>;
+ regulator-always-on;
+ };
+
+ vdd_snvs: ldo1 {
+ regulator-name = "vdd_snvs";
+ regulator-min-microvolt = <3000000>;
+ regulator-max-microvolt = <3000000>;
+ regulator-always-on;
+ };
+
+ vdd_high: ldo2 {
+ regulator-name = "vdd_high";
+ regulator-min-microvolt = <3000000>;
+ regulator-max-microvolt = <3000000>;
+ regulator-always-on;
+ };
+
+ vdd_eth_io: ldo3 {
+ regulator-name = "vdd_eth_io";
+ regulator-min-microvolt = <2500000>;
+ regulator-max-microvolt = <2500000>;
+ };
+
+ vdd_emmc_1p8: ldo4 {
+ regulator-name = "vdd_emmc";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ };
+ };
+ };
+};
+
+®_arm {
+ vin-supply = <&vdd_arm>;
+};
+
+®_pu {
+ vin-supply = <&vdd_soc>;
+};
+
+®_soc {
+ vin-supply = <&vdd_soc>;
+};
+
+&snvs_poweroff {
+ status = "okay";
+};
+
+&usdhc4 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usdhc4>;
+ bus-width = <8>;
+ non-removable;
+ vmmc-supply = <&vdd_emmc_1p8>;
+ status = "disabled";
+};
+
+&iomuxc {
+ 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_ENET_TX_EN__ENET_TX_EN 0x1b0b0
+ MX6QDL_PAD_SD2_DAT1__GPIO1_IO14 0x1b0b0
+ >;
+ };
+
+ pinctrl_gpioleds_som: gpioledssomgrp {
+ fsl,pins = <
+ MX6QDL_PAD_GPIO_4__GPIO1_IO04 0x1b0b0
+ >;
+ };
+
+ pinctrl_gpmi_nand: gpminandgrp {
+ fsl,pins = <
+ MX6QDL_PAD_NANDF_CLE__NAND_CLE 0xb0b1
+ MX6QDL_PAD_NANDF_ALE__NAND_ALE 0xb0b1
+ MX6QDL_PAD_NANDF_WP_B__NAND_WP_B 0xb0b1
+ MX6QDL_PAD_NANDF_RB0__NAND_READY_B 0xb000
+ MX6QDL_PAD_NANDF_CS0__NAND_CE0_B 0xb0b1
+ MX6QDL_PAD_NANDF_CS1__NAND_CE1_B 0xb0b1
+ MX6QDL_PAD_NANDF_CS2__NAND_CE2_B 0xb0b1
+ MX6QDL_PAD_NANDF_CS3__NAND_CE3_B 0xb0b1
+ MX6QDL_PAD_SD4_CMD__NAND_RE_B 0xb0b1
+ MX6QDL_PAD_SD4_CLK__NAND_WE_B 0xb0b1
+ MX6QDL_PAD_NANDF_D0__NAND_DATA00 0xb0b1
+ MX6QDL_PAD_NANDF_D1__NAND_DATA01 0xb0b1
+ MX6QDL_PAD_NANDF_D2__NAND_DATA02 0xb0b1
+ MX6QDL_PAD_NANDF_D3__NAND_DATA03 0xb0b1
+ MX6QDL_PAD_NANDF_D4__NAND_DATA04 0xb0b1
+ MX6QDL_PAD_NANDF_D5__NAND_DATA05 0xb0b1
+ MX6QDL_PAD_NANDF_D6__NAND_DATA06 0xb0b1
+ MX6QDL_PAD_NANDF_D7__NAND_DATA07 0xb0b1
+ MX6QDL_PAD_SD4_DAT0__NAND_DQS 0x00b1
+ >;
+ };
+
+ pinctrl_i2c3: i2c3grp {
+ fsl,pins = <
+ MX6QDL_PAD_GPIO_6__I2C3_SDA 0x4001b8b1
+ MX6QDL_PAD_GPIO_5__I2C3_SCL 0x4001b8b1
+ >;
+ };
+
+ pinctrl_ecspi1: ecspi1grp {
+ fsl,pins = <
+ MX6QDL_PAD_EIM_D16__ECSPI1_SCLK 0x100b1
+ MX6QDL_PAD_EIM_D17__ECSPI1_MISO 0x100b1
+ MX6QDL_PAD_EIM_D18__ECSPI1_MOSI 0x100b1
+ MX6QDL_PAD_EIM_D19__GPIO3_IO19 0x1b0b0
+ >;
+ };
+
+ pinctrl_pmic: pmicgrp {
+ fsl,pins = <
+ MX6QDL_PAD_GPIO_2__GPIO1_IO02 0x1b0b0
+ >;
+ };
+
+ pinctrl_usdhc4: usdhc4grp {
+ fsl,pins = <
+ MX6QDL_PAD_SD4_CMD__SD4_CMD 0x17059
+ MX6QDL_PAD_SD4_CLK__SD4_CLK 0x10059
+ MX6QDL_PAD_SD4_DAT0__SD4_DATA0 0x17059
+ MX6QDL_PAD_SD4_DAT1__SD4_DATA1 0x17059
+ MX6QDL_PAD_SD4_DAT2__SD4_DATA2 0x17059
+ MX6QDL_PAD_SD4_DAT3__SD4_DATA3 0x17059
+ MX6QDL_PAD_SD4_DAT4__SD4_DATA4 0x17059
+ MX6QDL_PAD_SD4_DAT5__SD4_DATA5 0x17059
+ MX6QDL_PAD_SD4_DAT6__SD4_DATA6 0x17059
+ MX6QDL_PAD_SD4_DAT7__SD4_DATA7 0x17059
+ >;
+ };
+};
--
2.7.4
^ permalink raw reply related
* [PATCH v5 0/6] ARM: dts: Add PHYTEC phyCORE-i.MX 6 and phyBOARD-Mira carrier board support
From: Stefan Riedmueller @ 2018-01-09 16:09 UTC (permalink / raw)
To: linux-arm-kernel
This patchset adds support for the PHYTEC phyCORE-i.MX 6 and phyBOARD-Mira.
Following boards are included:
phyBOARD-Mira with phyCORE-i.MX 6 Quad/Dual with:
- i.MX 6Quad/Dual SOC
- NAND or eMMC
- HDMI interface
- LVDS display interface
- Gigabit Ethernet
- USB Host
- CAN
- RS232
- PCIe
This board also contains an LVDS camera interface and parallel display
interface which are not yet supported.
phyBAORD-Mira with phyCORE-i.MX 6 DualLight/Solo with:
- i.MX 6DualLight/Solo
- NAND
- HDMI interface
- 100 MBit/s Ethernet
- USB Host
- RS232
phyBOARD-Mira with phyCORE-i.MX 6 QuadPlus with:
- i.MX 6QuadPlus SOC
- NAND
- HDMI interface
- LVDS display interface
- Gigabit Ethernet
- USB Host
- CAN
- RS232
- PCIe
This board also contains an LVDS camera interface and parallel display
interface which are not yet supported.
The entire series is based on v4.15-rc4.
Changes since v1:
- Removed unnecessary ipu aliases
- Added unit-address to memory node name
- Fixed eeprom compatible to correct vendor name (atmel instead of cat)
- Fixed rtc compatible to correct vendor name (microcrystal instead of mc)
- Changed pcie regulator to be used with vpcie-supply in &pcie node and
removed regulator-always-on
- Changed pcie reset-gpio polarity to GPIO_ACTIVE_LOW
- Replaced fsl,uart-has-rtscts by uart-has-rtscts
- Fixed typos in defconfig patch
Changes since v2:
- Fixed typo in patch subject PATCH 4/6
- Added reviewed by tags on PATCH 4/6 and PATCH 6/6
Changes since v3:
- Removed model and compatible from phycore dtsi
- Changed flash compatible to jedec,spi-nor
- Renamed some_green node to som-led-green
- Dropped labels for eeprom, pmic, da9062_wdt and da9062_reg
- Renamed flash label to m25p80
- Put compatible at beginning of property lists
- Changed copyright year to 2018
- Added reviewed by tags on PATCH 1/6, 2/6, 3/6 and 5/6
Changes since v4:
- Rearranged &m25p80 node in dts files to fit alphabetical order
- Fixed a parenthesis for uniformity in mira dtsi
Christian Hemp (2):
ARM: dts: imx6: Add support for phyBOARD-Mira i.MX 6Quad/Dual RDK
ARM: dts: imx6: Add support for phyBOARD-Mira i.MX 6 DualLight/Solo
RDK
Enrico Scholz (1):
ARM: dts: imx6: Add support for phyBOARD-Mira with i.MX 6QuadPlus
Stefan Riedmueller (3):
ARM: dts: imx6: Add initial support for phyCORE-i.MX 6 SOM
ARM: dts: imx6: Add initial support for phyBOARD-Mira
ARM: imx_v6_v7_defconfig: Enable Dialog Semiconductor DA9062 driver
arch/arm/boot/dts/Makefile | 4 +
arch/arm/boot/dts/imx6dl-phytec-mira-rdk-nand.dts | 64 ++++
arch/arm/boot/dts/imx6q-phytec-mira-rdk-emmc.dts | 72 ++++
arch/arm/boot/dts/imx6q-phytec-mira-rdk-nand.dts | 72 ++++
arch/arm/boot/dts/imx6qdl-phytec-mira.dtsi | 390 ++++++++++++++++++++++
arch/arm/boot/dts/imx6qdl-phytec-phycore-som.dtsi | 279 ++++++++++++++++
arch/arm/boot/dts/imx6qp-phytec-mira-rdk-nand.dts | 72 ++++
arch/arm/configs/imx_v6_v7_defconfig | 4 +
8 files changed, 957 insertions(+)
create mode 100644 arch/arm/boot/dts/imx6dl-phytec-mira-rdk-nand.dts
create mode 100644 arch/arm/boot/dts/imx6q-phytec-mira-rdk-emmc.dts
create mode 100644 arch/arm/boot/dts/imx6q-phytec-mira-rdk-nand.dts
create mode 100644 arch/arm/boot/dts/imx6qdl-phytec-mira.dtsi
create mode 100644 arch/arm/boot/dts/imx6qdl-phytec-phycore-som.dtsi
create mode 100644 arch/arm/boot/dts/imx6qp-phytec-mira-rdk-nand.dts
--
2.7.4
^ permalink raw reply
* [PATCH 04/11] drm/bridge/synopsys: dw-hdmi: Export some PHY related functions
From: Laurent Pinchart @ 2018-01-09 16:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <10903755.CJpSM8RM5e@jernej-laptop>
Hello,
On Tuesday, 9 January 2018 17:58:46 EET Jernej ?krabec wrote:
> Dne torek, 09. januar 2018 ob 11:43:08 CET je Archit Taneja napisal(a):
> > On 12/31/2017 02:31 AM, Jernej Skrabec wrote:
> >> Parts of PHY code could be useful also for custom PHYs. For example,
> >> Allwinner A83T has custom PHY which is probably Synopsys gen2 PHY
> >> with few additional memory mapped registers, so most of the Synopsys PHY
> >> related code could be reused.
> >>
> >> It turns out that even completely custom HDMI PHYs, such as the one
> >> found in Allwinner H3, can reuse some of those functions. This would
> >> suggest that (some?) functions exported in this commit are actually part
> >> of generic PHY interface and not really specific to Synopsys PHYs.
> >>
> >> Export useful PHY functions.
> >>
> >> Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
> >> ---
> >>
> >> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 45 +++++++++++++++++-------
> >> drivers/gpu/drm/bridge/synopsys/dw-hdmi.h | 2 ++
> >> include/drm/bridge/dw_hdmi.h | 10 +++++++
> >> 3 files changed, 44 insertions(+), 13 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> >> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c index
> >> 7ca14d7325b5..67467d0b683a 100644
> >> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> >> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
[snip]
> >> @@ -1065,6 +1067,23 @@ static void
> >> dw_hdmi_phy_sel_interface_control(struct dw_hdmi *hdmi, u8 enable)
> >> HDMI_PHY_CONF0_SELDIPIF_MASK);
> >> }
> >>
> >> +void dw_hdmi_phy_gen2_reset(struct dw_hdmi *hdmi, u8 enable)
> >> +{
> >> + hdmi_mask_writeb(hdmi, enable, HDMI_MC_PHYRSTZ,
> >> + HDMI_MC_PHYRSTZ_PHYRSTZ_OFFSET,
> >> + HDMI_MC_PHYRSTZ_PHYRSTZ_MASK);
> >> +}
> >> +EXPORT_SYMBOL_GPL(dw_hdmi_phy_gen2_reset);
I don't remember the details, is the reset signal Gen2-specific ?
How about asserting and deasserting the reset signal in the same call instead
of having to call this function twice ?
> >> +void dw_hdmi_phy_set_slave_addr(struct dw_hdmi *hdmi)
> >> +{
> >> + hdmi_phy_test_clear(hdmi, 1);
> >> + hdmi_writeb(hdmi, HDMI_PHY_I2CM_SLAVE_ADDR_PHY_GEN2,
> >> + HDMI_PHY_I2CM_SLAVE_ADDR);
> >> + hdmi_phy_test_clear(hdmi, 0);
> >> +}
> >> +EXPORT_SYMBOL_GPL(dw_hdmi_phy_set_slave_addr);
> >
> > Should this be called dw_hdmi_phy_gen2_set_slave_addr?
>
> Probably. I will rename it in v2 to be consistent with other phy functions.
The I2C write function is called dw_hdmi_phy_i2c_write(). If we want to be
conosistent we should either rename this one to dw_hdmi_phy_i2c_set_addr() or
rename them both to dw_hdmi_phy_gen2_i2c_write() and
dw_hdmi_phy_gen2_i2c_set_addr(). I think I'd prefer the former, and we could
even drop gen2 from dw_hdmi_phy_gen2_pddq() and dw_hdmi_phy_gen2_txpwron() if
desired.
> > Looks good otherwise. Same for patches 3 and 4 in this series.
> >
> >> +
> >> static void dw_hdmi_phy_power_off(struct dw_hdmi *hdmi)
> >> {
> >> const struct dw_hdmi_phy_data *phy = hdmi->phy.data;
[snip]
--
Regards,
Laurent Pinchart
^ permalink raw reply
* [PATCH 04/11] drm/bridge/synopsys: dw-hdmi: Export some PHY related functions
From: Jernej Škrabec @ 2018-01-09 16:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4765263.5spOVExvvT@avalon>
Hi Laurent,
Dne torek, 09. januar 2018 ob 14:30:22 CET je Laurent Pinchart napisal(a):
> Hi Jernej,
>
> Thank you for the patch.
>
> On Saturday, 30 December 2017 23:01:56 EET Jernej Skrabec wrote:
> > Parts of PHY code could be useful also for custom PHYs. For example,
> > Allwinner A83T has custom PHY which is probably Synopsys gen2 PHY
> > with few additional memory mapped registers, so most of the Synopsys PHY
> > related code could be reused.
> >
> > It turns out that even completely custom HDMI PHYs, such as the one
> > found in Allwinner H3, can reuse some of those functions. This would
> > suggest that (some?) functions exported in this commit are actually part
> > of generic PHY interface and not really specific to Synopsys PHYs.
>
> That's correct, those functions control the interface between the HDMI
> controller and the PHY. They're not specific to Synopsys PHYs, but they're
> specific to the PHY interface as designed by Synopsys.
Ok, I'll update commit message.
>
> > Export useful PHY functions.
> >
> > Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
> > ---
> >
> > drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 45
> > ++++++++++++++++++++-------
> > drivers/gpu/drm/bridge/synopsys/dw-hdmi.h | 2 ++
> > include/drm/bridge/dw_hdmi.h | 10 +++++++
> > 3 files changed, 44 insertions(+), 13 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> > b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c index
> > 7ca14d7325b5..67467d0b683a 100644
> > --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> > +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> > @@ -1037,19 +1037,21 @@ static void dw_hdmi_phy_enable_svsret(struct
> > dw_hdmi *hdmi, u8 enable) HDMI_PHY_CONF0_SVSRET_MASK);
> >
> > }
> >
> > -static void dw_hdmi_phy_gen2_pddq(struct dw_hdmi *hdmi, u8 enable)
> > +void dw_hdmi_phy_gen2_pddq(struct dw_hdmi *hdmi, u8 enable)
> >
> > {
> >
> > hdmi_mask_writeb(hdmi, enable, HDMI_PHY_CONF0,
> >
> > HDMI_PHY_CONF0_GEN2_PDDQ_OFFSET,
> > HDMI_PHY_CONF0_GEN2_PDDQ_MASK);
> >
> > }
> >
> > +EXPORT_SYMBOL_GPL(dw_hdmi_phy_gen2_pddq);
> >
> > -static void dw_hdmi_phy_gen2_txpwron(struct dw_hdmi *hdmi, u8 enable)
> > +void dw_hdmi_phy_gen2_txpwron(struct dw_hdmi *hdmi, u8 enable)
> >
> > {
> >
> > hdmi_mask_writeb(hdmi, enable, HDMI_PHY_CONF0,
> >
> > HDMI_PHY_CONF0_GEN2_TXPWRON_OFFSET,
> > HDMI_PHY_CONF0_GEN2_TXPWRON_MASK);
> >
> > }
> >
> > +EXPORT_SYMBOL_GPL(dw_hdmi_phy_gen2_txpwron);
> >
> > static void dw_hdmi_phy_sel_data_en_pol(struct dw_hdmi *hdmi, u8 enable)
> > {
> >
> > @@ -1065,6 +1067,23 @@ static void
> > dw_hdmi_phy_sel_interface_control(struct
> > dw_hdmi *hdmi, u8 enable) HDMI_PHY_CONF0_SELDIPIF_MASK);
> >
> > }
> >
> > +void dw_hdmi_phy_gen2_reset(struct dw_hdmi *hdmi, u8 enable)
> > +{
> > + hdmi_mask_writeb(hdmi, enable, HDMI_MC_PHYRSTZ,
> > + HDMI_MC_PHYRSTZ_PHYRSTZ_OFFSET,
> > + HDMI_MC_PHYRSTZ_PHYRSTZ_MASK);
> > +}
> > +EXPORT_SYMBOL_GPL(dw_hdmi_phy_gen2_reset);
> > +
> > +void dw_hdmi_phy_set_slave_addr(struct dw_hdmi *hdmi)
> > +{
> > + hdmi_phy_test_clear(hdmi, 1);
> > + hdmi_writeb(hdmi, HDMI_PHY_I2CM_SLAVE_ADDR_PHY_GEN2,
> > + HDMI_PHY_I2CM_SLAVE_ADDR);
> > + hdmi_phy_test_clear(hdmi, 0);
> > +}
> > +EXPORT_SYMBOL_GPL(dw_hdmi_phy_set_slave_addr);
>
> Should the I2C address be passed as an argument ?
Yes, I already planned to do that for v2.
Best regards,
Jernej
>
> > static void dw_hdmi_phy_power_off(struct dw_hdmi *hdmi)
> > {
> >
> > const struct dw_hdmi_phy_data *phy = hdmi->phy.data;
> >
> > @@ -1204,15 +1223,12 @@ static int hdmi_phy_configure(struct dw_hdmi
> > *hdmi)
> >
> > dw_hdmi_phy_enable_svsret(hdmi, 1);
> >
> > /* PHY reset. The reset signal is active high on Gen2 PHYs. */
> >
> > - hdmi_writeb(hdmi, HDMI_MC_PHYRSTZ_PHYRSTZ, HDMI_MC_PHYRSTZ);
> > - hdmi_writeb(hdmi, 0, HDMI_MC_PHYRSTZ);
> > + dw_hdmi_phy_gen2_reset(hdmi, 1);
> > + dw_hdmi_phy_gen2_reset(hdmi, 0);
> >
> > hdmi_writeb(hdmi, HDMI_MC_HEACPHY_RST_ASSERT, HDMI_MC_HEACPHY_RST);
> >
> > - hdmi_phy_test_clear(hdmi, 1);
> > - hdmi_writeb(hdmi, HDMI_PHY_I2CM_SLAVE_ADDR_PHY_GEN2,
> > - HDMI_PHY_I2CM_SLAVE_ADDR);
> > - hdmi_phy_test_clear(hdmi, 0);
> > + dw_hdmi_phy_set_slave_addr(hdmi);
> >
> > /* Write to the PHY as configured by the platform */
> > if (pdata->configure_phy)
> >
> > @@ -1251,15 +1267,16 @@ static void dw_hdmi_phy_disable(struct dw_hdmi
> > *hdmi, void *data) dw_hdmi_phy_power_off(hdmi);
> >
> > }
> >
> > -static enum drm_connector_status dw_hdmi_phy_read_hpd(struct dw_hdmi
> > *hdmi, - void *data)
> > +enum drm_connector_status dw_hdmi_phy_read_hpd(struct dw_hdmi *hdmi,
> > + void *data)
> >
> > {
> >
> > return hdmi_readb(hdmi, HDMI_PHY_STAT0) & HDMI_PHY_HPD ?
> >
> > connector_status_connected : connector_status_disconnected;
> >
> > }
> >
> > +EXPORT_SYMBOL_GPL(dw_hdmi_phy_read_hpd);
> >
> > -static void dw_hdmi_phy_update_hpd(struct dw_hdmi *hdmi, void *data,
> > - bool force, bool disabled, bool rxsense)
> > +void dw_hdmi_phy_update_hpd(struct dw_hdmi *hdmi, void *data,
> > + bool force, bool disabled, bool rxsense)
> >
> > {
> >
> > u8 old_mask = hdmi->phy_mask;
> >
> > @@ -1271,8 +1288,9 @@ static void dw_hdmi_phy_update_hpd(struct dw_hdmi
> > *hdmi, void *data, if (old_mask != hdmi->phy_mask)
> >
> > hdmi_writeb(hdmi, hdmi->phy_mask, HDMI_PHY_MASK0);
> >
> > }
> >
> > +EXPORT_SYMBOL_GPL(dw_hdmi_phy_update_hpd);
> >
> > -static void dw_hdmi_phy_setup_hpd(struct dw_hdmi *hdmi, void *data)
> > +void dw_hdmi_phy_setup_hpd(struct dw_hdmi *hdmi, void *data)
> >
> > {
> >
> > /*
> >
> > * Configure the PHY RX SENSE and HPD interrupts polarities and clear
> >
> > @@ -1291,6 +1309,7 @@ static void dw_hdmi_phy_setup_hpd(struct dw_hdmi
> > *hdmi, void *data) hdmi_writeb(hdmi, ~(HDMI_IH_PHY_STAT0_HPD |
> > HDMI_IH_PHY_STAT0_RX_SENSE), HDMI_IH_MUTE_PHY_STAT0);
> >
> > }
> >
> > +EXPORT_SYMBOL_GPL(dw_hdmi_phy_setup_hpd);
> >
> > static const struct dw_hdmi_phy_ops dw_hdmi_synopsys_phy_ops = {
> >
> > .init = dw_hdmi_phy_init,
> >
> > diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.h
> > b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.h index
> > 9d90eb9c46e5..fd150430d0b3 100644
> > --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.h
> > +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.h
> > @@ -950,6 +950,8 @@ enum {
> >
> > /* MC_PHYRSTZ field values */
> >
> > HDMI_MC_PHYRSTZ_PHYRSTZ = 0x01,
> >
> > + HDMI_MC_PHYRSTZ_PHYRSTZ_OFFSET = 0x00,
> > + HDMI_MC_PHYRSTZ_PHYRSTZ_MASK = 0x01,
> >
> > /* MC_HEACPHY_RST field values */
> >
> > HDMI_MC_HEACPHY_RST_ASSERT = 0x1,
> >
> > diff --git a/include/drm/bridge/dw_hdmi.h b/include/drm/bridge/dw_hdmi.h
> > index 182f83283e24..f5cca4362154 100644
> > --- a/include/drm/bridge/dw_hdmi.h
> > +++ b/include/drm/bridge/dw_hdmi.h
> > @@ -159,5 +159,15 @@ void dw_hdmi_audio_disable(struct dw_hdmi *hdmi);
> >
> > /* PHY configuration */
> > void dw_hdmi_phy_i2c_write(struct dw_hdmi *hdmi, unsigned short data,
> >
> > unsigned char addr);
> >
> > +enum drm_connector_status dw_hdmi_phy_read_hpd(struct dw_hdmi *hdmi,
> > + void *data);
> > +void dw_hdmi_phy_update_hpd(struct dw_hdmi *hdmi, void *data,
> > + bool force, bool disabled, bool rxsense);
> > +void dw_hdmi_phy_setup_hpd(struct dw_hdmi *hdmi, void *data);
> > +
> > +void dw_hdmi_phy_gen2_pddq(struct dw_hdmi *hdmi, u8 enable);
> > +void dw_hdmi_phy_gen2_txpwron(struct dw_hdmi *hdmi, u8 enable);
> > +void dw_hdmi_phy_gen2_reset(struct dw_hdmi *hdmi, u8 enable);
> > +void dw_hdmi_phy_set_slave_addr(struct dw_hdmi *hdmi);
> >
> > #endif /* __IMX_HDMI_H__ */
>
> --
> Regards,
>
> Laurent Pinchart
^ permalink raw reply
* [PATCH 04/11] drm/bridge/synopsys: dw-hdmi: Export some PHY related functions
From: Jernej Škrabec @ 2018-01-09 15:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6b454804-e910-e8e8-6d2b-5bc25c7a4d4c@codeaurora.org>
Hi Archit,
Dne torek, 09. januar 2018 ob 11:43:08 CET je Archit Taneja napisal(a):
> On 12/31/2017 02:31 AM, Jernej Skrabec wrote:
> > Parts of PHY code could be useful also for custom PHYs. For example,
> > Allwinner A83T has custom PHY which is probably Synopsys gen2 PHY
> > with few additional memory mapped registers, so most of the Synopsys PHY
> > related code could be reused.
> >
> > It turns out that even completely custom HDMI PHYs, such as the one
> > found in Allwinner H3, can reuse some of those functions. This would
> > suggest that (some?) functions exported in this commit are actually part
> > of generic PHY interface and not really specific to Synopsys PHYs.
> >
> > Export useful PHY functions.
> >
> > Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
> > ---
> >
> > drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 45
> > ++++++++++++++++++++++---------
> > drivers/gpu/drm/bridge/synopsys/dw-hdmi.h | 2 ++
> > include/drm/bridge/dw_hdmi.h | 10 +++++++
> > 3 files changed, 44 insertions(+), 13 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> > b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c index
> > 7ca14d7325b5..67467d0b683a 100644
> > --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> > +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> > @@ -1037,19 +1037,21 @@ static void dw_hdmi_phy_enable_svsret(struct
> > dw_hdmi *hdmi, u8 enable)>
> > HDMI_PHY_CONF0_SVSRET_MASK);
> >
> > }
> >
> > -static void dw_hdmi_phy_gen2_pddq(struct dw_hdmi *hdmi, u8 enable)
> > +void dw_hdmi_phy_gen2_pddq(struct dw_hdmi *hdmi, u8 enable)
> >
> > {
> >
> > hdmi_mask_writeb(hdmi, enable, HDMI_PHY_CONF0,
> >
> > HDMI_PHY_CONF0_GEN2_PDDQ_OFFSET,
> > HDMI_PHY_CONF0_GEN2_PDDQ_MASK);
> >
> > }
> >
> > +EXPORT_SYMBOL_GPL(dw_hdmi_phy_gen2_pddq);
> >
> > -static void dw_hdmi_phy_gen2_txpwron(struct dw_hdmi *hdmi, u8 enable)
> > +void dw_hdmi_phy_gen2_txpwron(struct dw_hdmi *hdmi, u8 enable)
> >
> > {
> >
> > hdmi_mask_writeb(hdmi, enable, HDMI_PHY_CONF0,
> >
> > HDMI_PHY_CONF0_GEN2_TXPWRON_OFFSET,
> > HDMI_PHY_CONF0_GEN2_TXPWRON_MASK);
> >
> > }
> >
> > +EXPORT_SYMBOL_GPL(dw_hdmi_phy_gen2_txpwron);
> >
> > static void dw_hdmi_phy_sel_data_en_pol(struct dw_hdmi *hdmi, u8 enable)
> > {
> >
> > @@ -1065,6 +1067,23 @@ static void
> > dw_hdmi_phy_sel_interface_control(struct dw_hdmi *hdmi, u8 enable)>
> > HDMI_PHY_CONF0_SELDIPIF_MASK);
> >
> > }
> >
> > +void dw_hdmi_phy_gen2_reset(struct dw_hdmi *hdmi, u8 enable)
> > +{
> > + hdmi_mask_writeb(hdmi, enable, HDMI_MC_PHYRSTZ,
> > + HDMI_MC_PHYRSTZ_PHYRSTZ_OFFSET,
> > + HDMI_MC_PHYRSTZ_PHYRSTZ_MASK);
> > +}
> > +EXPORT_SYMBOL_GPL(dw_hdmi_phy_gen2_reset);
> > +
> > +void dw_hdmi_phy_set_slave_addr(struct dw_hdmi *hdmi)
> > +{
> > + hdmi_phy_test_clear(hdmi, 1);
> > + hdmi_writeb(hdmi, HDMI_PHY_I2CM_SLAVE_ADDR_PHY_GEN2,
> > + HDMI_PHY_I2CM_SLAVE_ADDR);
> > + hdmi_phy_test_clear(hdmi, 0);
> > +}
> > +EXPORT_SYMBOL_GPL(dw_hdmi_phy_set_slave_addr);
>
> Should this be called dw_hdmi_phy_gen2_set_slave_addr?
Probably. I will rename it in v2 to be consistent with other phy functions.
Best regards,
Jernej
>
> Looks good otherwise. Same for patches 3 and 4 in this series.
>
> Thanks,
> Archit
>
> > +
> >
> > static void dw_hdmi_phy_power_off(struct dw_hdmi *hdmi)
> > {
> >
> > const struct dw_hdmi_phy_data *phy = hdmi->phy.data;
> >
> > @@ -1204,15 +1223,12 @@ static int hdmi_phy_configure(struct dw_hdmi
> > *hdmi)
> >
> > dw_hdmi_phy_enable_svsret(hdmi, 1);
> >
> > /* PHY reset. The reset signal is active high on Gen2 PHYs. */
> >
> > - hdmi_writeb(hdmi, HDMI_MC_PHYRSTZ_PHYRSTZ, HDMI_MC_PHYRSTZ);
> > - hdmi_writeb(hdmi, 0, HDMI_MC_PHYRSTZ);
> > + dw_hdmi_phy_gen2_reset(hdmi, 1);
> > + dw_hdmi_phy_gen2_reset(hdmi, 0);
> >
> > hdmi_writeb(hdmi, HDMI_MC_HEACPHY_RST_ASSERT, HDMI_MC_HEACPHY_RST);
> >
> > - hdmi_phy_test_clear(hdmi, 1);
> > - hdmi_writeb(hdmi, HDMI_PHY_I2CM_SLAVE_ADDR_PHY_GEN2,
> > - HDMI_PHY_I2CM_SLAVE_ADDR);
> > - hdmi_phy_test_clear(hdmi, 0);
> > + dw_hdmi_phy_set_slave_addr(hdmi);
> >
> > /* Write to the PHY as configured by the platform */
> > if (pdata->configure_phy)
> >
> > @@ -1251,15 +1267,16 @@ static void dw_hdmi_phy_disable(struct dw_hdmi
> > *hdmi, void *data)>
> > dw_hdmi_phy_power_off(hdmi);
> >
> > }
> >
> > -static enum drm_connector_status dw_hdmi_phy_read_hpd(struct dw_hdmi
> > *hdmi, - void *data)
> > +enum drm_connector_status dw_hdmi_phy_read_hpd(struct dw_hdmi *hdmi,
> > + void *data)
> >
> > {
> >
> > return hdmi_readb(hdmi, HDMI_PHY_STAT0) & HDMI_PHY_HPD ?
> >
> > connector_status_connected : connector_status_disconnected;
> >
> > }
> >
> > +EXPORT_SYMBOL_GPL(dw_hdmi_phy_read_hpd);
> >
> > -static void dw_hdmi_phy_update_hpd(struct dw_hdmi *hdmi, void *data,
> > - bool force, bool disabled, bool rxsense)
> > +void dw_hdmi_phy_update_hpd(struct dw_hdmi *hdmi, void *data,
> > + bool force, bool disabled, bool rxsense)
> >
> > {
> >
> > u8 old_mask = hdmi->phy_mask;
> >
> > @@ -1271,8 +1288,9 @@ static void dw_hdmi_phy_update_hpd(struct dw_hdmi
> > *hdmi, void *data,>
> > if (old_mask != hdmi->phy_mask)
> >
> > hdmi_writeb(hdmi, hdmi->phy_mask, HDMI_PHY_MASK0);
> >
> > }
> >
> > +EXPORT_SYMBOL_GPL(dw_hdmi_phy_update_hpd);
> >
> > -static void dw_hdmi_phy_setup_hpd(struct dw_hdmi *hdmi, void *data)
> > +void dw_hdmi_phy_setup_hpd(struct dw_hdmi *hdmi, void *data)
> >
> > {
> >
> > /*
> >
> > * Configure the PHY RX SENSE and HPD interrupts polarities and clear
> >
> > @@ -1291,6 +1309,7 @@ static void dw_hdmi_phy_setup_hpd(struct dw_hdmi
> > *hdmi, void *data)>
> > hdmi_writeb(hdmi, ~(HDMI_IH_PHY_STAT0_HPD |
> > HDMI_IH_PHY_STAT0_RX_SENSE),
> >
> > HDMI_IH_MUTE_PHY_STAT0);
> >
> > }
> >
> > +EXPORT_SYMBOL_GPL(dw_hdmi_phy_setup_hpd);
> >
> > static const struct dw_hdmi_phy_ops dw_hdmi_synopsys_phy_ops = {
> >
> > .init = dw_hdmi_phy_init,
> >
> > diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.h
> > b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.h index
> > 9d90eb9c46e5..fd150430d0b3 100644
> > --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.h
> > +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.h
> > @@ -950,6 +950,8 @@ enum {
> >
> > /* MC_PHYRSTZ field values */
> >
> > HDMI_MC_PHYRSTZ_PHYRSTZ = 0x01,
> >
> > + HDMI_MC_PHYRSTZ_PHYRSTZ_OFFSET = 0x00,
> > + HDMI_MC_PHYRSTZ_PHYRSTZ_MASK = 0x01,
> >
> > /* MC_HEACPHY_RST field values */
> >
> > HDMI_MC_HEACPHY_RST_ASSERT = 0x1,
> >
> > diff --git a/include/drm/bridge/dw_hdmi.h b/include/drm/bridge/dw_hdmi.h
> > index 182f83283e24..f5cca4362154 100644
> > --- a/include/drm/bridge/dw_hdmi.h
> > +++ b/include/drm/bridge/dw_hdmi.h
> > @@ -159,5 +159,15 @@ void dw_hdmi_audio_disable(struct dw_hdmi *hdmi);
> >
> > /* PHY configuration */
> > void dw_hdmi_phy_i2c_write(struct dw_hdmi *hdmi, unsigned short data,
> >
> > unsigned char addr);
> >
> > +enum drm_connector_status dw_hdmi_phy_read_hpd(struct dw_hdmi *hdmi,
> > + void *data);
> > +void dw_hdmi_phy_update_hpd(struct dw_hdmi *hdmi, void *data,
> > + bool force, bool disabled, bool rxsense);
> > +void dw_hdmi_phy_setup_hpd(struct dw_hdmi *hdmi, void *data);
> > +
> > +void dw_hdmi_phy_gen2_pddq(struct dw_hdmi *hdmi, u8 enable);
> > +void dw_hdmi_phy_gen2_txpwron(struct dw_hdmi *hdmi, u8 enable);
> > +void dw_hdmi_phy_gen2_reset(struct dw_hdmi *hdmi, u8 enable);
> > +void dw_hdmi_phy_set_slave_addr(struct dw_hdmi *hdmi);
> >
> > #endif /* __IMX_HDMI_H__ */
>
> --
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH 05/67] dma-mapping: replace PCI_DMA_BUS_IS_PHYS with a flag in struct dma_map_ops
From: Jesper Nilsson @ 2018-01-09 15:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171229081911.2802-6-hch@lst.de>
On Fri, Dec 29, 2017 at 09:18:09AM +0100, Christoph Hellwig wrote:
> The current PCI_DMA_BUS_IS_PHYS decided if a dma implementation is bound
> by the dma mask in the device because it directly maps to a physical
> address range (modulo an offset in the device), or if it is virtualized
> by an iommu and can map any address (that includes virtual iommus like
> swiotlb). The problem with this scheme is that it is per-architecture and
> not per dma_ops instance, and we are growing more and more setups that
> have multiple different dma operations in use on a single system, for
> which this scheme can't provide a correct answer. Depending on the
> architecture that means we either get a false positive or false negative
> at the moment.
>
> This patch instead extents the is_phys flag in struct dma_map_ops that
> is currently only used by a few architectures to be used tree wide.
>
> Note that this means that we now need a struct device parent in the
> Scsi_Host or netdevice. Every modern driver has these, but there might
> still be a few outdated legacy drivers out there, which now won't make
> an intelligent decision.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
For the CRIS part:
Acked-by: Jesper Nilsson <jesper.nilsson@axis.com>
> ---
> arch/cris/arch-v32/drivers/pci/dma.c | 1 +
> arch/cris/include/asm/pci.h | 6 ------
/^JN - Jesper Nilsson
--
Jesper Nilsson -- jesper.nilsson at axis.com
^ permalink raw reply
* [PATCH 22/67] dma-mapping: clear harmful GFP_* flags in common code
From: Jesper Nilsson @ 2018-01-09 15:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171229081911.2802-23-hch@lst.de>
On Fri, Dec 29, 2017 at 09:18:26AM +0100, Christoph Hellwig wrote:
> Life the code from x86 so that we behave consistently. In the future we
> should probably warn if any of these is set.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
Acked-by: Jesper Nilsson <jesper.nilsson@axis.com>
> ---
> arch/cris/arch-v32/drivers/pci/dma.c | 3 ---
/^JN - Jesper Nilsson
--
Jesper Nilsson -- jesper.nilsson at axis.com
^ permalink raw reply
* [linux-sunxi] Re: [PATCH 01/11] clk: sunxi-ng: Don't set k if width is 0 for nkmp plls
From: Jernej Škrabec @ 2018-01-09 15:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGb2v6463B-JVw5A9C39iiuo7Xzj3Bq06m6VzdAUqr0b-S91MQ@mail.gmail.com>
Hi Chen-Yu,
Dne ponedeljek, 08. januar 2018 ob 10:19:47 CET je Chen-Yu Tsai napisal(a):
> On Fri, Jan 5, 2018 at 3:28 AM, Jernej ?krabec <jernej.skrabec@siol.net>
wrote:
> > Hi,
> >
> > Dne ?etrtek, 04. januar 2018 ob 15:45:18 CET je Chen-Yu Tsai napisal(a):
> >> On Sun, Dec 31, 2017 at 5:01 AM, Jernej Skrabec <jernej.skrabec@siol.net>
> >
> > wrote:
> >> > For example, A83T have nmp plls which are modelled as nkmp plls. Since
> >> > k
> >> > is not specified, it has offset 0, shift 0 and lowest value 1. This
> >> > means that LSB bit is always set to 1, which may change clock rate.
> >> >
> >> > Fix that by applying k factor only if k width is greater than 0.
> >> >
> >> > Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
> >> > ---
> >> >
> >> > drivers/clk/sunxi-ng/ccu_nkmp.c | 21 +++++++++++++--------
> >> > 1 file changed, 13 insertions(+), 8 deletions(-)
> >> >
> >> > diff --git a/drivers/clk/sunxi-ng/ccu_nkmp.c
> >> > b/drivers/clk/sunxi-ng/ccu_nkmp.c index e58c95787f94..709f528af2b3
> >> > 100644
> >> > --- a/drivers/clk/sunxi-ng/ccu_nkmp.c
> >> > +++ b/drivers/clk/sunxi-ng/ccu_nkmp.c
> >> > @@ -81,7 +81,7 @@ static unsigned long ccu_nkmp_recalc_rate(struct
> >> > clk_hw
> >> > *hw,>
> >> >
> >> > unsigned long parent_rate)
> >> >
> >> > {
> >> >
> >> > struct ccu_nkmp *nkmp = hw_to_ccu_nkmp(hw);
> >> >
> >> > - unsigned long n, m, k, p;
> >> > + unsigned long n, m, k = 1, p;
> >> >
> >> > u32 reg;
> >> >
> >> > reg = readl(nkmp->common.base + nkmp->common.reg);
> >> >
> >> > @@ -92,11 +92,13 @@ static unsigned long ccu_nkmp_recalc_rate(struct
> >> > clk_hw *hw,>
> >> >
> >> > if (!n)
> >> >
> >> > n++;
> >> >
> >> > - k = reg >> nkmp->k.shift;
> >> > - k &= (1 << nkmp->k.width) - 1;
> >> > - k += nkmp->k.offset;
> >> > - if (!k)
> >> > - k++;
> >> > + if (nkmp->k.width) {
> >> > + k = reg >> nkmp->k.shift;
> >> > + k &= (1 << nkmp->k.width) - 1;
> >> > + k += nkmp->k.offset;
> >> > + if (!k)
> >> > + k++;
> >> > + }
> >>
> >> The conditional shouldn't be necessary. With nkmp->k.width = 0,
> >> you'd simply get k & 0, which is 0, which then gets bumped up to 1,
> >> unless k.offset > 1, which would be a bug.
> >>
> >> > m = reg >> nkmp->m.shift;
> >> > m &= (1 << nkmp->m.width) - 1;
> >> >
> >> > @@ -153,12 +155,15 @@ static int ccu_nkmp_set_rate(struct clk_hw *hw,
> >> > unsigned long rate,>
> >> >
> >> > reg = readl(nkmp->common.base + nkmp->common.reg);
> >> > reg &= ~GENMASK(nkmp->n.width + nkmp->n.shift - 1,
> >> > nkmp->n.shift);
> >> >
> >> > - reg &= ~GENMASK(nkmp->k.width + nkmp->k.shift - 1,
> >> > nkmp->k.shift);
> >> > + if (nkmp->k.width)
> >> > + reg &= ~GENMASK(nkmp->k.width + nkmp->k.shift - 1,
> >> > + nkmp->k.shift);
> >> >
> >> > reg &= ~GENMASK(nkmp->m.width + nkmp->m.shift - 1,
> >> > nkmp->m.shift);
> >> > reg &= ~GENMASK(nkmp->p.width + nkmp->p.shift - 1,
> >> > nkmp->p.shift);
> >> >
> >> > reg |= (_nkmp.n - nkmp->n.offset) << nkmp->n.shift;
> >> >
> >> > - reg |= (_nkmp.k - nkmp->k.offset) << nkmp->k.shift;
> >> > + if (nkmp->k.width)
> >> > + reg |= (_nkmp.k - nkmp->k.offset) << nkmp->k.shift;
> >>
> >> I think a better way would be
> >>
> >> reg |= ((_nkmp.k - nkmp->k.offset) << nkmp->k.shift) &
> >>
> >> GENMASK(nkmp->k.width + nkmp->k.shift - 1, nkmp->k.shift);
> >>
> >> And do this for all the factors, not just k. This pattern is what
> >> regmap_update_bits does, which seems much safer. I wonder what
> >> GENMASK() with a negative value would do though...
> >
> > You're right, GENMASK(-1, 0) equals 0 (calculated by hand, not tested).
> > This seems much more elegant solution.
> >
> > Semi-related question: All nmp PLLs have much wider N range than real nkmp
> > PLLs. This causes integer overflow when using nkmp formula from datasheet.
> > Usually, N is 1-256 for nmp PLLs, which means that for very high N
> > factors, it overflows. This also causes issue that M factor is never
> > higher than 1.
> Sounds like we can't use u8 for storing the factors. At least the
> intermediate values we use to calculate the rates.
Only issue with u8 could be max field in struct ccu_mult_internal for K factor.
But since it's not used, there is no issue. All intermediate variables in
ccu_nkmp are wider.
>
> > I was wondering, if patch would be acceptable which would change this
> > formula:
> >
> > RATE = (24MHz * N * K) / (M * P)
> >
> > to this:
> >
> > RATE ((24MHz / M) * N * K) / P
> >
> > I checked all M factors and are all in 1-4 or 1-2 range, which means it
> > wouldn't have any impact for real nkmp PLLs when parent is 24 MHz clock
> > which is probably always.
> >
> > What do you think?
>
> I think this is acceptable. M is normally the pre-divider, so this
> actually fits how the hardware works, including possible rounding
> errors.
Ok, I'll add a patch for that in v2.
Best regards,
Jernej
>
> ChenYu
>
> > I discovered that when I tried to set A83T PLL_VIDEO to 346.5 MHz which is
> > possible only when above formula is changed.
> >
> > Best regards,
> > Jernej
> >
> >> ChenYu
> >>
> >> > reg |= (_nkmp.m - nkmp->m.offset) << nkmp->m.shift;
> >> > reg |= ilog2(_nkmp.p) << nkmp->p.shift;
> >> >
> >> > --
> >> > 2.15.1
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> > "linux-sunxi" group. To unsubscribe from this group and stop receiving
> > emails from it, send an email to
> > linux-sunxi+unsubscribe at googlegroups.com. For more options, visit
> > https://groups.google.com/d/optout.
^ permalink raw reply
* [PATCH net-next v3 4/4] net: mvpp2: 2500baseX support
From: Antoine Tenart @ 2018-01-09 15:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180109151735.GB23676@kwain>
Hi Russell,
On Tue, Jan 09, 2018 at 04:17:35PM +0100, Antoine Tenart wrote:
> On Tue, Jan 09, 2018 at 02:44:48PM +0000, Russell King - ARM Linux wrote:
> > On Tue, Jan 09, 2018 at 09:59:45AM +0100, Antoine Tenart wrote:
> > > val |= MVPP2_GMAC_CONFIG_GMII_SPEED |
> > > MVPP2_GMAC_CONFIG_FULL_DUPLEX;
> > > + else if (port->phy_interface == PHY_INTERFACE_MODE_2500BASEX)
> > > + val |= MVPP2_GMAC_CONFIG_GMII_SPEED |
> > > + MVPP2_GMAC_CONFIG_MII_SPEED |
> > > + MVPP2_GMAC_CONFIG_FULL_DUPLEX;
> >
> > I think you'll find you don't need to set MII_SPEED here, since
> > MII_SPEED selects between 10 and 100, GMII_SPEED always takes
> > precidence selecting 1000, and 2500 is done by the comphy
> > increasing the clocks by 2.5x.
>
> I just had a look at the datasheet, and as you say it seems GMII_SPEED
> takes over MII_SPEED. I'll see if there is a corner case here or if
> selecting MII_SPEED doesn't make sense, and update accordingly.
I just checked, this can be removed for this mode. I'll update the
patch.
Thanks!
Antoine
--
Antoine T?nart, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH 34/67] cris: use dma-direct
From: Jesper Nilsson @ 2018-01-09 15:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171229081911.2802-35-hch@lst.de>
On Fri, Dec 29, 2017 at 09:18:38AM +0100, Christoph Hellwig wrote:
> cris currently has an incomplete direct mapping dma_map_ops implementation
> is PCI support is enabled. Replace it with the fully feature generic
> dma-direct implementation.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
For CRIS:
Acked-by: Jesper Nilsson <jesper.nilsson@axis.com>
> ---
> arch/cris/Kconfig | 4 ++
> arch/cris/arch-v32/drivers/pci/Makefile | 2 +-
> arch/cris/arch-v32/drivers/pci/dma.c | 78 ---------------------------------
> arch/cris/include/asm/Kbuild | 1 +
> arch/cris/include/asm/dma-mapping.h | 20 ---------
> 5 files changed, 6 insertions(+), 99 deletions(-)
> delete mode 100644 arch/cris/arch-v32/drivers/pci/dma.c
> delete mode 100644 arch/cris/include/asm/dma-mapping.h
>
/^JN - Jesper Nilsson
--
Jesper Nilsson -- jesper.nilsson at axis.com
^ permalink raw reply
* [PATCH v2 3/7] PCI: aardvark: set host and device to the same MAX payload size
From: Thomas Petazzoni @ 2018-01-09 15:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171005173102.GR25517@bhelgaas-glaptop.roam.corp.google.com>
Hello Bjorn,
On Thu, 5 Oct 2017 12:31:02 -0500, Bjorn Helgaas wrote:
> On Thu, Sep 28, 2017 at 02:58:34PM +0200, Thomas Petazzoni wrote:
> > From: Victor Gu <xigu@marvell.com>
> >
> > Since the Aardvark does not implement a PCIe root bus,
>
> What exactly do you mean by "does not implement a PCIe root bus"? I
> assume there is still a hierarchy of PCI buses, and I assume the
> hierarchy has a top-most ("root") bus.
>
> Maybe there's no Root Port? There are other systems that don't have
> Root Ports, and we've made changes to accommodate that, e.g.,
>
> http://git.kernel.org/cgit/linux/kernel/git/helgaas/pci.git/commit/?id=1b8a6079015f
I'm trying to get back (finally) to this topic. Unfortunately, your
branch has been rebased, and this commit no longer exists. Do you have
an updated pointer about what you suggest to use for systems that don't
have Root Ports ?
Thanks!
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH 16/67] powerpc: rename dma_direct_ to dma_nommu_
From: Christoph Hellwig @ 2018-01-09 15:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180104084930.GB3251@lst.de>
On Thu, Jan 04, 2018 at 09:49:30AM +0100, Christoph Hellwig wrote:
> On Tue, Jan 02, 2018 at 08:45:30PM +1100, Michael Ellerman wrote:
> > Christoph Hellwig <hch@lst.de> writes:
> >
> > > We want to use the dma_direct_ namespace for a generic implementation,
> > > so rename powerpc to the second best choice: dma_nommu_.
> >
> > I'm not a fan of "nommu". Some of the users of direct ops *are* using an
> > IOMMU, they're just setting up a 1:1 mapping once at init time, rather
> > than mapping dynamically.
> >
> > Though I don't have a good idea for a better name, maybe "1to1",
> > "linear", "premapped" ?
>
> It seems like a nice counter part to the dma_iommu_ops used just about
> anywhere else in ppc.
>
> But I'll happily take any maintainer bike shed decision for the next
> series. Remember that in a merge window or two it will hopefully
> go away in favor of the new generic dma_direct ops.
Michael, please suggest what name you want for the next iteration,
I don't want to hold up the series on a naming bikeshed.
^ permalink raw reply
* [PATCH v2] iommu/exynos: Don't unconditionally steal bus ops
From: Robin Murphy @ 2018-01-09 15:34 UTC (permalink / raw)
To: linux-arm-kernel
Removing the early device registration hook overlooked the fact that
it only ran conditionally on a compatible device being present in the
DT. With exynos_iommu_init() now running as an unconditional initcall,
problems arise on non-Exynos systems when other IOMMU drivers find
themselves unable to install their ops on the platform bus, or at worst
the Exynos ops get called with someone else's domain and all hell breaks
loose.
The global ops/cache setup could probably all now be triggered from the
first IOMMU probe, as with dma_dev assigment, but for the time being the
simplest fix is to resurrect the logic from commit a7b67cd5d9af
("iommu/exynos: Play nice in multi-platform builds") to explicitly check
the DT for the presence of an Exynos IOMMU before trying anything.
Fixes: 928055a01b3f ("iommu/exynos: Remove custom platform device registration code")
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
---
v2: Use the simpler explicit DT check.
drivers/iommu/exynos-iommu.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c
index 79c45650f8de..736d4552d96f 100644
--- a/drivers/iommu/exynos-iommu.c
+++ b/drivers/iommu/exynos-iommu.c
@@ -1353,8 +1353,15 @@ static const struct iommu_ops exynos_iommu_ops = {
static int __init exynos_iommu_init(void)
{
+ struct device_node *np;
int ret;
+ np = of_find_matching_node(NULL, sysmmu_of_match);
+ if (!np)
+ return 0;
+
+ of_node_put(np);
+
lv2table_kmem_cache = kmem_cache_create("exynos-iommu-lv2table",
LV2TABLE_SIZE, LV2TABLE_SIZE, 0, NULL);
if (!lv2table_kmem_cache) {
--
2.13.4.dirty
^ 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