* [PATCH] arm64: acpi: arch_apei_get_mem_attributes() should use memblock
From: Ard Biesheuvel @ 2016-11-09 12:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161108102714.29931-1-james.morse@arm.com>
Hi James,
On 8 November 2016 at 10:27, James Morse <james.morse@arm.com> wrote:
> arm64's arch_apei_get_mem_attributes() tries to use
> efi_mem_attributes() to read the memory attributes from the efi
> memory map.
>
> drivers/firmware/efi/arm-init.c:efi_init() calls efi_memmap_unmap(),
> which clears the EFI_MEMMAP bit from efi.flags once efi_init() has
> finished with the memory map. This causes efi_mem_attributes() to
> return 0 meaning PROT_DEVICE_nGnRnE is the chosen memory type for
> all ACPI APEI mappings.
>
> APEI may call this from NMI context, so we can't re-map the EFI
> memory map as this may need to allocate virtual address space.
> 'ghes_ioremap_area' is APEIs cache of virtual address space to
> access the buffer once we tell it the memory attributes.
>
> Do as acpi_os_ioremap() does, and consult memblock to learn if
> the provided address is memory, or not.
>
> Signed-off-by: James Morse <james.morse@arm.com>
> Cc: Jonathan (Zhixiong) Zhang <zjzhang@codeaurora.org>
> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> ---
> Fixes: 89e44b51cc0d ("arm64, acpi/apei: Implement arch_apei_get_mem_attributes()")
>
> This doesn't code even get built on mainline as HAVE_ACPI_APEI isn't
> defined, until https://lkml.org/lkml/2016/8/10/231 gets merged.
> I don't think this should go to stable.
>
> I also took the opportunity to remove some unnecessarily ifdef'd
> includes.
>
> arch/arm64/kernel/acpi.c | 28 ++++++++--------------------
> 1 file changed, 8 insertions(+), 20 deletions(-)
>
> diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
> index 252a6d9c1da5..985f721f3bdd 100644
> --- a/arch/arm64/kernel/acpi.c
> +++ b/arch/arm64/kernel/acpi.c
> @@ -18,6 +18,7 @@
> #include <linux/acpi.h>
> #include <linux/bootmem.h>
> #include <linux/cpumask.h>
> +#include <linux/efi.h>
> #include <linux/init.h>
> #include <linux/irq.h>
> #include <linux/irqdomain.h>
> @@ -28,13 +29,9 @@
>
> #include <asm/cputype.h>
> #include <asm/cpu_ops.h>
> +#include <asm/pgtable.h>
> #include <asm/smp_plat.h>
>
> -#ifdef CONFIG_ACPI_APEI
> -# include <linux/efi.h>
> -# include <asm/pgtable.h>
> -#endif
> -
> int acpi_noirq = 1; /* skip ACPI IRQ initialization */
> int acpi_disabled = 1;
> EXPORT_SYMBOL(acpi_disabled);
> @@ -241,22 +238,13 @@ void __init acpi_boot_table_init(void)
> pgprot_t arch_apei_get_mem_attribute(phys_addr_t addr)
> {
> /*
> - * According to "Table 8 Map: EFI memory types to AArch64 memory
> - * types" of UEFI 2.5 section 2.3.6.1, each EFI memory type is
> - * mapped to a corresponding MAIR attribute encoding.
> - * The EFI memory attribute advises all possible capabilities
> - * of a memory region. We use the most efficient capability.
> + * The EFI memmap isn't mapped, instead read the version exported
> + * into memblock. EFI's reserve_regions() call adds memory with the
> + * WB attribute to memblock via early_init_dt_add_memory_arch().
> */
> + if (!memblock_is_memory(addr))
> + return __pgprot(PROT_DEVICE_nGnRnE);
>
> - u64 attr;
> -
> - attr = efi_mem_attributes(addr);
> - if (attr & EFI_MEMORY_WB)
> - return PAGE_KERNEL;
> - if (attr & EFI_MEMORY_WT)
> - return __pgprot(PROT_NORMAL_WT);
> - if (attr & EFI_MEMORY_WC)
> - return __pgprot(PROT_NORMAL_NC);
> - return __pgprot(PROT_DEVICE_nGnRnE);
> + return PAGE_KERNEL;
As you know, we recently applied [0] to ensure that memory regions
that are marked by UEFI was write-through cacheable (WT) or
write-combining (WC) are not misidentified by the kernel as having
strongly ordered semantics.
This means that in this case, you may be returning PAGE_KERNEL for
regions that are lacking the EFI_MEMORY_WB attribute, which kind of
defeats the purpose of this function (AIUI), to align the kernel's
view of the region's attributes with the view of the firmware. I would
expect that, for use cases like this one, the burden is on the
firmware to ensure that only a single EFI_MEMORY_xx attribute is set
if any kind of coherency between UEFI and the kernel is expected. If
that single attribute is WT or WC, PAGE_KERNEL is most certainly
wrong.
[0] http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=cb82cce7035
^ permalink raw reply
* [PATCH v3 0/2] Remove static mapping of SCU from mach-exynos
From: Pankaj Dubey @ 2016-11-09 12:15 UTC (permalink / raw)
To: linux-arm-kernel
This patch series is part of patch series [1], which adds support of SCU
device node for Cortex-A9 based Exynos4 SoC. First two patches of the same
has been accepted and hence not included them in v3.
This patch series does some cleanup for Exynos4 SoC based boards.
We are currently statically mapping SCU SFRs in mach-exynos/exynos.c
which can be avoided if map this from device node of SCU
[1]: https://www.spinics.net/lists/arm-kernel/msg540498.html
This patch series is prepared on Krzysztof's for-next
(SHA_ID: b33c7bb9d59c3f4100d4)
I have tested these patches on Exynos4210 based on Origen board for SMP boot.
Patchset v1 was tested by Marek Szyprowski on Exynos4412-based Odroid U3
for SMP boot and S2R.
To confirm concern raised by Alim, I intentionally removed SCU device node
from exynos4.dtsi and tested on Origen board, I can see code handles this
case gracefully without any crash and system boot was fine. Of-course in such
case only single core will be able to boot.
Following boot message observed on Origen in case of missing SCU node
-------------
[ 0.000864] CPU: Testing write buffer coherency: ok
[ 0.001068] CPU0: thread -1, cpu 0, socket 9, mpidr 80000900
[ 0.001456] exynos_scu_enable failed to map scu_base
[ 0.001477] Setting up static identity map for 0x40100000 - 0x40100058
[ 1.120003] CPU1: failed to come online
[ 1.120059] Brought up 1 CPUs
[ 1.120068] SMP: Total of 1 processors activated (48.00 BogoMIPS).
[ 1.120076] CPU: All CPU(s) started in SVC mode.
-------------
Changes since v2:
- Removed unnecessary header file inclusion from pm.c.
- Move out call_firmware_op call from CORTEX-A9 check.
- Update commit log for 1/2 patch describing dependency on DTS and affect of
the patch on out-of-tree DTS
Changes since v1:
- Address review comments from Krzysztof
- Moved scu_enable from pm.c and suspend.c to single place in platsmp.c
- Added error handling during scu_enable in platsmp.c
- Added Reviewed-by tag from Alim.
Pankaj Dubey (2):
ARM: EXYNOS: Remove static mapping of SCU SFR
ARM: EXYNOS: Remove unused soc_is_exynos{4,5}
arch/arm/mach-exynos/common.h | 6 +----
arch/arm/mach-exynos/exynos.c | 22 ------------------
arch/arm/mach-exynos/include/mach/map.h | 2 --
arch/arm/mach-exynos/platsmp.c | 34 +++++++++++++++++++++-------
arch/arm/mach-exynos/pm.c | 4 +---
arch/arm/mach-exynos/suspend.c | 4 +---
arch/arm/plat-samsung/include/plat/map-s5p.h | 4 ----
7 files changed, 29 insertions(+), 47 deletions(-)
--
2.7.4
^ permalink raw reply
* [PATCH v3 1/2] ARM: EXYNOS: Remove static mapping of SCU SFR
From: Pankaj Dubey @ 2016-11-09 12:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478693755-11953-1-git-send-email-pankaj.dubey@samsung.com>
Lets remove static mapping of SCU SFR mainly used in CORTEX-A9 SoC based
boards. Instead use mapping from device tree node of SCU.
NOTE: This patch has dependency on DT file of any such CORTEX-A9 SoC
based boards, in the absence of SCU device node in DTS file, only single
CPU will boot. So if you are using OUT-OF-TREE DTS file of CORTEX-A9 based
Exynos SoC make sure to add SCU device node to DTS file for SMP boot.
Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
Reviewed-by: Alim Akhtar <alim.akhtar@samsung.com>
---
arch/arm/mach-exynos/common.h | 1 +
arch/arm/mach-exynos/exynos.c | 22 ------------------
arch/arm/mach-exynos/include/mach/map.h | 2 --
arch/arm/mach-exynos/platsmp.c | 34 +++++++++++++++++++++-------
arch/arm/mach-exynos/pm.c | 4 +---
arch/arm/mach-exynos/suspend.c | 4 +---
arch/arm/plat-samsung/include/plat/map-s5p.h | 4 ----
7 files changed, 29 insertions(+), 42 deletions(-)
diff --git a/arch/arm/mach-exynos/common.h b/arch/arm/mach-exynos/common.h
index 9424a8a..dd5d8e8 100644
--- a/arch/arm/mach-exynos/common.h
+++ b/arch/arm/mach-exynos/common.h
@@ -161,6 +161,7 @@ extern void exynos_cpu_restore_register(void);
extern void exynos_pm_central_suspend(void);
extern int exynos_pm_central_resume(void);
extern void exynos_enter_aftr(void);
+extern int exynos_scu_enable(void);
extern struct cpuidle_exynos_data cpuidle_coupled_exynos_data;
diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c
index 757fc11..fa08ef9 100644
--- a/arch/arm/mach-exynos/exynos.c
+++ b/arch/arm/mach-exynos/exynos.c
@@ -28,15 +28,6 @@
#include "common.h"
-static struct map_desc exynos4_iodesc[] __initdata = {
- {
- .virtual = (unsigned long)S5P_VA_COREPERI_BASE,
- .pfn = __phys_to_pfn(EXYNOS4_PA_COREPERI),
- .length = SZ_8K,
- .type = MT_DEVICE,
- },
-};
-
static struct platform_device exynos_cpuidle = {
.name = "exynos_cpuidle",
#ifdef CONFIG_ARM_EXYNOS_CPUIDLE
@@ -99,17 +90,6 @@ static int __init exynos_fdt_map_chipid(unsigned long node, const char *uname,
return 1;
}
-/*
- * exynos_map_io
- *
- * register the standard cpu IO areas
- */
-static void __init exynos_map_io(void)
-{
- if (soc_is_exynos4())
- iotable_init(exynos4_iodesc, ARRAY_SIZE(exynos4_iodesc));
-}
-
static void __init exynos_init_io(void)
{
debug_ll_io_init();
@@ -118,8 +98,6 @@ static void __init exynos_init_io(void)
/* detect cpu id and rev. */
s5p_init_cpu(S5P_VA_CHIPID);
-
- exynos_map_io();
}
/*
diff --git a/arch/arm/mach-exynos/include/mach/map.h b/arch/arm/mach-exynos/include/mach/map.h
index 5fb0040..0eef407 100644
--- a/arch/arm/mach-exynos/include/mach/map.h
+++ b/arch/arm/mach-exynos/include/mach/map.h
@@ -18,6 +18,4 @@
#define EXYNOS_PA_CHIPID 0x10000000
-#define EXYNOS4_PA_COREPERI 0x10500000
-
#endif /* __ASM_ARCH_MAP_H */
diff --git a/arch/arm/mach-exynos/platsmp.c b/arch/arm/mach-exynos/platsmp.c
index a5d6841..94405c7 100644
--- a/arch/arm/mach-exynos/platsmp.c
+++ b/arch/arm/mach-exynos/platsmp.c
@@ -168,6 +168,27 @@ int exynos_cluster_power_state(int cluster)
S5P_CORE_LOCAL_PWR_EN);
}
+/**
+ * exynos_scu_enable : enables SCU for Cortex-A9 based system
+ * returns 0 on success else non-zero error code
+ */
+int exynos_scu_enable(void)
+{
+ struct device_node *np;
+ void __iomem *scu_base;
+
+ np = of_find_compatible_node(NULL, NULL, "arm,cortex-a9-scu");
+ scu_base = of_iomap(np, 0);
+ of_node_put(np);
+ if (!scu_base) {
+ pr_err("%s failed to map scu_base\n", __func__);
+ return -ENOMEM;
+ }
+ scu_enable(scu_base);
+ iounmap(scu_base);
+ return 0;
+}
+
static void __iomem *cpu_boot_reg_base(void)
{
if (soc_is_exynos4210() && samsung_rev() == EXYNOS4210_REV_1_1)
@@ -224,11 +245,6 @@ static void write_pen_release(int val)
sync_cache_w(&pen_release);
}
-static void __iomem *scu_base_addr(void)
-{
- return (void __iomem *)(S5P_VA_SCU);
-}
-
static DEFINE_SPINLOCK(boot_lock);
static void exynos_secondary_init(unsigned int cpu)
@@ -393,9 +409,11 @@ static void __init exynos_smp_prepare_cpus(unsigned int max_cpus)
exynos_set_delayed_reset_assertion(true);
- if (read_cpuid_part() == ARM_CPU_PART_CORTEX_A9)
- scu_enable(scu_base_addr());
-
+ if (read_cpuid_part() == ARM_CPU_PART_CORTEX_A9) {
+ /* if exynos_scu_enable fails, return */
+ if (exynos_scu_enable())
+ return;
+ }
/*
* Write the address of secondary startup into the
* system-wide flags register. The boot monitor waits
diff --git a/arch/arm/mach-exynos/pm.c b/arch/arm/mach-exynos/pm.c
index 487295f..c0b46c3 100644
--- a/arch/arm/mach-exynos/pm.c
+++ b/arch/arm/mach-exynos/pm.c
@@ -26,8 +26,6 @@
#include <asm/suspend.h>
#include <asm/cacheflush.h>
-#include <mach/map.h>
-
#include "common.h"
static inline void __iomem *exynos_boot_vector_addr(void)
@@ -177,7 +175,7 @@ void exynos_enter_aftr(void)
cpu_suspend(0, exynos_aftr_finisher);
if (read_cpuid_part() == ARM_CPU_PART_CORTEX_A9) {
- scu_enable(S5P_VA_SCU);
+ exynos_scu_enable();
if (call_firmware_op(resume) == -ENOSYS)
exynos_cpu_restore_register();
}
diff --git a/arch/arm/mach-exynos/suspend.c b/arch/arm/mach-exynos/suspend.c
index 06332f6..73df9f3 100644
--- a/arch/arm/mach-exynos/suspend.c
+++ b/arch/arm/mach-exynos/suspend.c
@@ -34,8 +34,6 @@
#include <asm/smp_scu.h>
#include <asm/suspend.h>
-#include <mach/map.h>
-
#include <plat/pm-common.h>
#include "common.h"
@@ -462,7 +460,7 @@ static void exynos_pm_resume(void)
exynos_pm_release_retention();
if (cpuid == ARM_CPU_PART_CORTEX_A9)
- scu_enable(S5P_VA_SCU);
+ exynos_scu_enable();
if (call_firmware_op(resume) == -ENOSYS
&& cpuid == ARM_CPU_PART_CORTEX_A9)
diff --git a/arch/arm/plat-samsung/include/plat/map-s5p.h b/arch/arm/plat-samsung/include/plat/map-s5p.h
index 0fe2828..512ed1f 100644
--- a/arch/arm/plat-samsung/include/plat/map-s5p.h
+++ b/arch/arm/plat-samsung/include/plat/map-s5p.h
@@ -15,10 +15,6 @@
#define S5P_VA_CHIPID S3C_ADDR(0x02000000)
-#define S5P_VA_COREPERI_BASE S3C_ADDR(0x02800000)
-#define S5P_VA_COREPERI(x) (S5P_VA_COREPERI_BASE + (x))
-#define S5P_VA_SCU S5P_VA_COREPERI(0x0)
-
#define VA_VIC(x) (S3C_VA_IRQ + ((x) * 0x10000))
#define VA_VIC0 VA_VIC(0)
#define VA_VIC1 VA_VIC(1)
--
2.7.4
^ permalink raw reply related
* [PATCH v3 2/2] ARM: EXYNOS: Remove unused soc_is_exynos{4,5}
From: Pankaj Dubey @ 2016-11-09 12:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478693755-11953-1-git-send-email-pankaj.dubey@samsung.com>
As no more user of soc_is_exynos{4,5} we can safely remove them.
Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
Reviewed-by: Alim Akhtar <alim.akhtar@samsung.com>
---
arch/arm/mach-exynos/common.h | 5 -----
1 file changed, 5 deletions(-)
diff --git a/arch/arm/mach-exynos/common.h b/arch/arm/mach-exynos/common.h
index dd5d8e8..fb12d11 100644
--- a/arch/arm/mach-exynos/common.h
+++ b/arch/arm/mach-exynos/common.h
@@ -105,11 +105,6 @@ IS_SAMSUNG_CPU(exynos5800, EXYNOS5800_SOC_ID, EXYNOS5_SOC_MASK)
# define soc_is_exynos5800() 0
#endif
-#define soc_is_exynos4() (soc_is_exynos4210() || soc_is_exynos4212() || \
- soc_is_exynos4412())
-#define soc_is_exynos5() (soc_is_exynos5250() || soc_is_exynos5410() || \
- soc_is_exynos5420() || soc_is_exynos5800())
-
extern u32 cp15_save_diag;
extern u32 cp15_save_power;
--
2.7.4
^ permalink raw reply related
* [PATCH 1/5] iommu: Allow taking a reference on a group directly
From: Robin Murphy @ 2016-11-09 12:47 UTC (permalink / raw)
To: linux-arm-kernel
iommu_group_get_for_dev() expects that the IOMMU driver's device_group
callback return a group with a reference held for the given device.
Whilst allocating a new group is fine, and pci_device_group() correctly
handles reusing an existing group, there is no general means for IOMMU
drivers doing their own group lookup to take additional references on an
existing group pointer without having to also store device pointers or
resort to elaborate trickery.
Add an IOMMU-driver-specific function to fill the hole.
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
---
drivers/iommu/iommu.c | 14 ++++++++++++++
include/linux/iommu.h | 1 +
2 files changed, 15 insertions(+)
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index 9a2f1960873b..b0b052bc6bb5 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -552,6 +552,20 @@ struct iommu_group *iommu_group_get(struct device *dev)
EXPORT_SYMBOL_GPL(iommu_group_get);
/**
+ * __iommu_group_get - Increment reference on a group
+ * @group: the group to use, must not be NULL
+ *
+ * This function may be called by internal iommu driver group management
+ * when the context of a struct device pointer is not available. It is
+ * not for general use. Returns the given group for convenience.
+ */
+struct iommu_group *__iommu_group_get(struct iommu_group *group)
+{
+ kobject_get(group->devices_kobj);
+ return group;
+}
+
+/**
* iommu_group_put - Decrement group reference
* @group: the group to use
*
diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index 436dc21318af..3f5d3f9d2440 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -253,6 +253,7 @@ extern void iommu_group_remove_device(struct device *dev);
extern int iommu_group_for_each_dev(struct iommu_group *group, void *data,
int (*fn)(struct device *, void *));
extern struct iommu_group *iommu_group_get(struct device *dev);
+extern struct iommu_group *__iommu_group_get(struct iommu_group *group);
extern void iommu_group_put(struct iommu_group *group);
extern int iommu_group_register_notifier(struct iommu_group *group,
struct notifier_block *nb);
--
2.10.2.dirty
^ permalink raw reply related
* [PATCH 2/5] iommu/arm-smmu: Fix group refcounting
From: Robin Murphy @ 2016-11-09 12:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3922e1f14d8ecb50440b2d9b0d1123f3c9307fc5.1478695557.git.robin.murphy@arm.com>
When arm_smmu_device_group() finds an existing group due to Stream ID
aliasing, it should be taking an additional reference on that group.
Reported-by: Sricharan R <sricharan@codeaurora.org>
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
---
drivers/iommu/arm-smmu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index 8f7281444551..9f760cfba4fa 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -1478,7 +1478,7 @@ static struct iommu_group *arm_smmu_device_group(struct device *dev)
}
if (group)
- return group;
+ return __iommu_group_get(group);
if (dev_is_pci(dev))
group = pci_device_group(dev);
--
2.10.2.dirty
^ permalink raw reply related
* [PATCH 3/5] iommu/amd: Fix group refcounting
From: Robin Murphy @ 2016-11-09 12:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3922e1f14d8ecb50440b2d9b0d1123f3c9307fc5.1478695557.git.robin.murphy@arm.com>
If acpihid_device_group() finds an existing group for the relevant
devid, it should be taking an additional reference on that group.
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
---
drivers/iommu/amd_iommu.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c
index 754595ee11b6..4ef05691ceb1 100644
--- a/drivers/iommu/amd_iommu.c
+++ b/drivers/iommu/amd_iommu.c
@@ -373,6 +373,8 @@ static struct iommu_group *acpihid_device_group(struct device *dev)
if (!entry->group)
entry->group = generic_device_group(dev);
+ else
+ __iommu_group_get(entry->group);
return entry->group;
}
--
2.10.2.dirty
^ permalink raw reply related
* [PATCH 4/5] iommu/mediatek: Fix M4Uv2 group refcounting
From: Robin Murphy @ 2016-11-09 12:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3922e1f14d8ecb50440b2d9b0d1123f3c9307fc5.1478695557.git.robin.murphy@arm.com>
For each subsequent device assigned to the m4u_group after its initial
allocation, we need to take an additional reference.
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
---
drivers/iommu/mtk_iommu.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index b12c12d74c33..f5591f6aef49 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -410,6 +410,8 @@ static struct iommu_group *mtk_iommu_device_group(struct device *dev)
data->m4u_group = iommu_group_alloc();
if (IS_ERR(data->m4u_group))
dev_err(dev, "Failed to allocate M4U IOMMU group\n");
+ } else {
+ __iommu_group_get(data->m4u_group);
}
return data->m4u_group;
}
--
2.10.2.dirty
^ permalink raw reply related
* [PATCH 5/5] iommu/mediatek: Fix M4Uv1 group refcounting
From: Robin Murphy @ 2016-11-09 12:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3922e1f14d8ecb50440b2d9b0d1123f3c9307fc5.1478695557.git.robin.murphy@arm.com>
For each subsequent device assigned to the m4u_group after its initial
allocation, we need to take an additional reference.
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
---
drivers/iommu/mtk_iommu_v1.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/iommu/mtk_iommu_v1.c b/drivers/iommu/mtk_iommu_v1.c
index b8aeb0768483..1b736990373f 100644
--- a/drivers/iommu/mtk_iommu_v1.c
+++ b/drivers/iommu/mtk_iommu_v1.c
@@ -502,6 +502,8 @@ static struct iommu_group *mtk_iommu_device_group(struct device *dev)
data->m4u_group = iommu_group_alloc();
if (IS_ERR(data->m4u_group))
dev_err(dev, "Failed to allocate M4U IOMMU group\n");
+ } else {
+ __iommu_group_get(data->m4u_group);
}
return data->m4u_group;
}
--
2.10.2.dirty
^ permalink raw reply related
* [alsa-devel] [PATCH 2/9] ALSA: ac97: add an ac97 bus
From: Lars-Peter Clausen @ 2016-11-09 13:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87eg2ly8k6.fsf@belgarion.home>
On 11/08/2016 10:18 PM, Robert Jarzmik wrote:
[...]
>>> +/**
>>> + * struct ac97_controller - The AC97 controller of the AC-Link
>>> + * @ops: the AC97 operations.
>>> + * @controllers: linked list of all existing controllers.
>>> + * @dev: the device providing the AC97 controller.
>>> + * @slots_available: the mask of accessible/scanable codecs.
>>> + * @codecs: the 4 possible AC97 codecs (NULL if none found).
>>> + * @codecs_pdata: platform_data for each codec (NULL if no pdata).
>>> + *
>>> + * This structure is internal to AC97 bus, and should not be used by the
>>> + * controllers themselves, excepting for using @dev.
>>> + */
>>> +struct ac97_controller {
>>> + const struct ac97_controller_ops *ops;
>>> + struct list_head controllers;
>>> + struct device *dev;
>>
>> I'd make the controller itself a struct dev, rather than just having the
>> pointer to the parent. This is more idiomatic and matches what other
>> subsystems do. It has several advantages, you get proper refcounting of your
>> controller structure, the controller gets its own sysfs directory where the
>> CODECs appear as children, you don't need the manual sysfs attribute
>> creation and removal in ac97_controler_{un,}register().
>
> If you mean having "struct device dev" instead of "struct device *dev", it has
> also a drawback : all the legacy platforms have already a probing method, be
> that platform data, device-tree or something else.
>
> I'm a bit converned about the conversion toll. Maybe I've not understood your
> point fully, so please feel free to explain, with an actual example even better.
This would be a struct device that is not bound to a driver, but just acts
as a shell for the controller and places it inside the device hierarchy. You
get reference counting and other management functions as well as a
consistent naming scheme. E.g. you can call the devices ac97c%d (or
something similar) and then call the CODEC ac97c%d.%d.
This is how most frameworks implementing some kind of control bus are
structured in the Linux kernel. E.g. take a look at I2C or SPI.
Your controller driver itself is unaffected by this, you still call
snd_ac97_controller_register() from the probe function and so on.
>
>>> + void (*wait)(struct ac97_controller *adrv, int slot);
>>> + void (*init)(struct ac97_controller *adrv, int slot);
>>
>> Neither wait nor init are ever used.
> This is because I've not begun to porting sound/pci/ac97_codec.c into
> sound/ac97.
Ok, makes sense. But maybe just leave them out for now and add them when
they are used.
[...]
>>> + ret = sysfs_create_link(&codec->dev.kobj, &ac97_ctrl->dev->kobj,
>>> + "ac97_controller");
>>
>> Since the CODEC is a child of the controller this should not be necessary as
>> this just points one directory up. It's like `ln -s .. parent`
> This creates :
> /sys/bus/ac97/devices/pxa2xx-ac97\:0/ac97_controller
>
> Of course as you pointed out, it's a 'ln -s .. parent' like link, but it seems
> to me very unfriendly to have :
> - /sys/bus/ac97/devices/pxa2xx-ac97\:0/../ac97_operations
> - while /sys/bus/ac97/devices/ac97_operations doesn't exist (obviously)
>
> Mmm, I don't know for this one, my mind is not set, it's a bit hard to tell if
> it's only an unecessary link bringing "comfort", or something usefull.
It is additional ABI and we do not have this for any other bus either (e.g.
you don't see a backlink for a I2C or SPI device to the parent). In my
opinion for the sake of keeping things consistent and simple we should not
add this.
>>
>>> + if (ret)
>>> + goto err_unregister_device;
>>> +
>>> + return 0;
>>> +err_unregister_device:
>>> + put_device(&codec->dev);
>>> +err_free_codec:
>>> + kfree(codec);
>>
>> Since the struct is reference counted, the freeing is done in the release
>> callback and this leads to a double free.
> A yes in the "goto err_unregister_device" case right, while it's necessary in
> the "goto err_free_codec" case ... I need to rework that a bit.
It should use put_device() in both cases, check the the device_register()
documentation. It says that put_device() must be used, even if
device_register() fails.
>
>>> +int snd_ac97_codec_driver_register(struct ac97_codec_driver *drv)
>>> +{
>>> + int ret;
>>> +
>>> + drv->driver.bus = &ac97_bus_type;
>>> +
>>> + ret = driver_register(&drv->driver);
>>> + if (!ret)
>>> + ac97_rescan_all_controllers();
>>
>> Rescanning the bus when a new codec driver is registered should not be
>> neccessary. The bus is scanned once when the controller is registered, this
>> creates the device. The device driver core will take care of binding the
>> device to the driver, if the driver is registered after thed evice.
> That's because you suppose the initial scanning found all the ac97 codecs.
> But that's an incomplete vision as a codec might be powered off at that time and
> not seen by the first scanning, while the new scanning will discover it.
But why would the device become suddenly visible when the driver is
registered. This seems to be an as arbitrary point in time as any other.
Also consider that when you build a driver as a module, the module will
typically only be auto-loaded after the device has been detected, based on
the device ID. On the other hand, if the driver is built-in driver
registration will happen either before or shortly after the controller
registration.
If there is the expectation that the AC97 CODEC might randomly appear on the
bus, the core should periodically scan the bus.
[...]
>>> + ac97_ctrl->ops->warm_reset(ac97_ctrl);
>>> + return len;
>>> +}
>>> +static DEVICE_ATTR_WO(warm_reset);
>>> +
>>> +static struct attribute *ac97_controller_device_attrs[] = {
>>> + &dev_attr_cold_reset.attr,
>>> + &dev_attr_warm_reset.attr,
>>> + NULL
>>> +};
>>
>> This adds new userspace ABI that is not documented at the moment.
> Very true. And as all userspace interface, it needs to be discussed. If nobody
> complains, I'll add the documentation for next patch round.
>>
>>> +int snd_ac97_controller_register(const struct ac97_controller_ops *ops,
>>> + struct device *dev,
>>> + unsigned short slots_available,
>>> + void **codecs_pdata)
>>
>> In my opinion this should return a handle to a ac97 controller which can
>> then be passed to snd_ac97_controller_unregister(). This is in my opinion
>> the better approach rather than looking up the controller by parent device.
> This is another "legacy drivers" issue.
>
> The legacy driver (the one probed by platform_data or devicetree) doesn't
> necessarily have a private structure to store this ac97_controller pointer.
I might be missing something, but I'm not convinced by this. Can you point
me to such a legacy driver where you think this would not work?
^ permalink raw reply
* [PATCH v2 0/9] rockchip: add more power domain and devices dts for rk3399
From: Caesar Wang @ 2016-11-09 13:21 UTC (permalink / raw)
To: linux-arm-kernel
Hi all,
Please allow me to integrate these patches.
They are missing or losing for upstream, then there are some patches
are always depending on them.
The following patches are releated to PD.
git log --oneline
827198c arm64: dts: rockchip: add the usb3 pd for rk3399
95e95b4 arm64: dts: rockchip: support dwc3 USB for rk3399
3ced49c arm64: dts: rockchip: add pd_edp node for rk3399
e19db3f arm64: dts: rockchip: introduce pclk_vio_grf in eDP device node
eb92079 arm64: dts: rockchip: add backlight support for rk3399 evb board
20b8135 arm64: dts: rockchip: add eDP device node for rk3399
480a1bb arm64: dts: rockchip: add VOP and VOP iommu node for rk3399
4964c0a arm64: dts: rockchip: add pd_sd power node for rk3399
c407a4c arm64: dts: rockchip: add eMMC's power domain support for rk3399
----
Hi Heiko & guys,
This series patches support the below PDs.
1) sd & emmc pd
4964c0a arm64: dts: rockchip: add pd_sd power node for rk3399
c407a4c arm64: dts: rockchip: add eMMC's power domain support for rk3399
2) edp pd
3ced49c arm64: dts: rockchip: add pd_edp node for rk3399
e19db3f arm64: dts: rockchip: introduce pclk_vio_grf in eDP device node
eb92079 arm64: dts: rockchip: add backlight support for rk3399 evb board
20b8135 arm64: dts: rockchip: add eDP device node for rk3399
480a1bb arm64: dts: rockchip: add VOP and VOP iommu node for rk3399
3) usb3 pd
827198c arm64: dts: rockchip: add the usb3 pd for rk3399
95e95b4 arm64: dts: rockchip: support dwc3 USB for rk3399
Thanks,
Caesar
Changes in v2:
- Reviewed-on: https://chromium-review.googlesource.com/376558
- Verified on ChromeOS kernel4.4
- v1 on https://patchwork.kernel.org/patch/9322553/
- Reviewed-on: https://chromium-review.googlesource.com/386483
- Verified on ChromeOS kernel4.4
- Yakir posted the original patch on
- https://patchwork.kernel.org/patch/9191777
- the original patches from brian posting on
https://chromium-review.googlesource.com/343603
- Reviewed-on: https://chromium-review.googlesource.com/384280
Brian Norris (1):
arm64: dts: rockchip: support dwc3 USB for rk3399
Caesar Wang (1):
arm64: dts: rockchip: add the usb3 pd for rk3399
Mark Yao (1):
arm64: dts: rockchip: add VOP and VOP iommu node for rk3399
Yakir Yang (3):
arm64: dts: rockchip: add eDP device node for rk3399
arm64: dts: rockchip: add backlight support for rk3399 evb board
arm64: dts: rockchip: introduce pclk_vio_grf in eDP device node
Ziyuan Xu (1):
arm64: dts: rockchip: add eMMC's power domain support for rk3399
zhangqing (2):
arm64: dts: rockchip: add pd_sd power node for rk3399
arm64: dts: rockchip: add pd_edp node for rk3399
arch/arm64/boot/dts/rockchip/rk3399-evb.dts | 40 ++++++
arch/arm64/boot/dts/rockchip/rk3399.dtsi | 210 ++++++++++++++++++++++++++++
2 files changed, 250 insertions(+)
--
2.7.4
^ permalink raw reply
* [PATCH v2 1/9] arm64: dts: rockchip: add eMMC's power domain support for rk3399
From: Caesar Wang @ 2016-11-09 13:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478697721-2323-1-git-send-email-wxt@rock-chips.com>
From: Ziyuan Xu <xzy.xu@rock-chips.com>
Control power domain for eMMC via genpd to reduce power consumption.
Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>
Signed-off-by: Ziyuan Xu <xzy.xu@rock-chips.com>
Signed-off-by: Caesar Wang <wxt@rock-chips.com>
---
Changes in v2:
- Reviewed-on: https://chromium-review.googlesource.com/376558
- Verified on ChromeOS kernel4.4
arch/arm64/boot/dts/rockchip/rk3399.dtsi | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index cbb7f8b..b401176 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -269,6 +269,7 @@
#clock-cells = <0>;
phys = <&emmc_phy>;
phy-names = "phy_arasan";
+ power-domains = <&power RK3399_PD_EMMC>;
status = "disabled";
};
@@ -690,6 +691,11 @@
status = "disabled";
};
+ qos_emmc: qos at ffa58000 {
+ compatible = "syscon";
+ reg = <0x0 0xffa58000 0x0 0x20>;
+ };
+
qos_gmac: qos at ffa5c000 {
compatible = "syscon";
reg = <0x0 0xffa5c000 0x0 0x20>;
@@ -823,6 +829,11 @@
};
/* These power domains are grouped by VD_LOGIC */
+ pd_emmc at RK3399_PD_EMMC {
+ reg = <RK3399_PD_EMMC>;
+ clocks = <&cru ACLK_EMMC>;
+ pm_qos = <&qos_emmc>;
+ };
pd_gmac at RK3399_PD_GMAC {
reg = <RK3399_PD_GMAC>;
clocks = <&cru ACLK_GMAC>;
--
2.7.4
^ permalink raw reply related
* [PATCH v2 2/9] arm64: dts: rockchip: add pd_sd power node for rk3399
From: Caesar Wang @ 2016-11-09 13:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478697721-2323-1-git-send-email-wxt@rock-chips.com>
From: zhangqing <zhangqing@rock-chips.com>
1.add pd node for RK3399 Soc
2.create power domain tree
3.add qos node for domain
4.add the pd_sd consumers node
Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>
Signed-off-by: Caesar Wang <wxt@rock-chips.com>
---
Changes in v2:
- v1 on https://patchwork.kernel.org/patch/9322553/
- Reviewed-on: https://chromium-review.googlesource.com/386483
- Verified on ChromeOS kernel4.4
arch/arm64/boot/dts/rockchip/rk3399.dtsi | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index b401176..e5b5b3d 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -253,6 +253,7 @@
<&cru SCLK_SDMMC_DRV>, <&cru SCLK_SDMMC_SAMPLE>;
clock-names = "biu", "ciu", "ciu-drive", "ciu-sample";
fifo-depth = <0x100>;
+ power-domains = <&power RK3399_PD_SD>;
status = "disabled";
};
@@ -691,6 +692,11 @@
status = "disabled";
};
+ qos_sd: qos at ffa74000 {
+ compatible = "syscon";
+ reg = <0x0 0xffa74000 0x0 0x20>;
+ };
+
qos_emmc: qos at ffa58000 {
compatible = "syscon";
reg = <0x0 0xffa58000 0x0 0x20>;
@@ -839,6 +845,12 @@
clocks = <&cru ACLK_GMAC>;
pm_qos = <&qos_gmac>;
};
+ pd_sd at RK3399_PD_SD {
+ reg = <RK3399_PD_SD>;
+ clocks = <&cru HCLK_SDMMC>,
+ <&cru SCLK_SDMMC>;
+ pm_qos = <&qos_sd>;
+ };
pd_vio at RK3399_PD_VIO {
reg = <RK3399_PD_VIO>;
#address-cells = <1>;
--
2.7.4
^ permalink raw reply related
* [PATCH v2 3/9] arm64: dts: rockchip: add VOP and VOP iommu node for rk3399
From: Caesar Wang @ 2016-11-09 13:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478697721-2323-1-git-send-email-wxt@rock-chips.com>
From: Mark Yao <mark.yao@rock-chips.com>
Add the core display-subsystem node and the two display controllers
available on the rk3399.
Signed-off-by: Mark Yao <mark.yao@rock-chips.com>
Signed-off-by: Yakir Yang <ykk@rock-chips.com>
Signed-off-by: Caesar Wang <wxt@rock-chips.com>
---
Changes in v2: None
arch/arm64/boot/dts/rockchip/rk3399.dtsi | 58 ++++++++++++++++++++++++++++++++
1 file changed, 58 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index e5b5b3d..f1d289a 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -1290,6 +1290,64 @@
status = "disabled";
};
+ vopl: vop at ff8f0000 {
+ compatible = "rockchip,rk3399-vop-lit";
+ reg = <0x0 0xff8f0000 0x0 0x3efc>;
+ interrupts = <GIC_SPI 119 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cru ACLK_VOP1>, <&cru DCLK_VOP1>, <&cru HCLK_VOP1>;
+ clock-names = "aclk_vop", "dclk_vop", "hclk_vop";
+ resets = <&cru SRST_A_VOP1>, <&cru SRST_H_VOP1>, <&cru SRST_D_VOP1>;
+ reset-names = "axi", "ahb", "dclk";
+ iommus = <&vopl_mmu>;
+ status = "disabled";
+
+ vopl_out: port {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+ };
+
+ vopl_mmu: iommu at ff8f3f00 {
+ compatible = "rockchip,iommu";
+ reg = <0x0 0xff8f3f00 0x0 0x100>;
+ interrupts = <GIC_SPI 119 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "vopl_mmu";
+ #iommu-cells = <0>;
+ status = "disabled";
+ };
+
+ vopb: vop at ff900000 {
+ compatible = "rockchip,rk3399-vop-big";
+ reg = <0x0 0xff900000 0x0 0x3efc>;
+ interrupts = <GIC_SPI 118 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cru ACLK_VOP0>, <&cru DCLK_VOP0>, <&cru HCLK_VOP0>;
+ clock-names = "aclk_vop", "dclk_vop", "hclk_vop";
+ resets = <&cru SRST_A_VOP0>, <&cru SRST_H_VOP0>, <&cru SRST_D_VOP0>;
+ reset-names = "axi", "ahb", "dclk";
+ iommus = <&vopb_mmu>;
+ status = "disabled";
+
+ vopb_out: port {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+ };
+
+ vopb_mmu: iommu at ff903f00 {
+ compatible = "rockchip,iommu";
+ reg = <0x0 0xff903f00 0x0 0x100>;
+ interrupts = <GIC_SPI 118 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "vopb_mmu";
+ #iommu-cells = <0>;
+ status = "disabled";
+ };
+
+ display_subsystem: display-subsystem {
+ compatible = "rockchip,display-subsystem";
+ ports = <&vopl_out>, <&vopb_out>;
+ status = "disabled";
+ };
+
pinctrl: pinctrl {
compatible = "rockchip,rk3399-pinctrl";
rockchip,grf = <&grf>;
--
2.7.4
^ permalink raw reply related
* [PATCH v2 4/9] arm64: dts: rockchip: add eDP device node for rk3399
From: Caesar Wang @ 2016-11-09 13:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478697721-2323-1-git-send-email-wxt@rock-chips.com>
From: Yakir Yang <ykk@rock-chips.com>
Add rk3399 eDP device node, and connect to VOP device node with
remote endpoint.
Signed-off-by: Yakir Yang <ykk@rock-chips.com>
Signed-off-by: Caesar Wang <wxt@rock-chips.com>
(Caesar rebase the lastest and solve the conflict)
---
Changes in v2:
- Yakir posted the original patch on
- https://patchwork.kernel.org/patch/9191777
arch/arm64/boot/dts/rockchip/rk3399.dtsi | 52 ++++++++++++++++++++++++++++++++
1 file changed, 52 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index f1d289a..6544910 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -1304,6 +1304,11 @@
vopl_out: port {
#address-cells = <1>;
#size-cells = <0>;
+
+ vopl_out_edp: endpoint at 0 {
+ reg = <0>;
+ remote-endpoint = <&edp_in_vopl>;
+ };
};
};
@@ -1330,6 +1335,11 @@
vopb_out: port {
#address-cells = <1>;
#size-cells = <0>;
+
+ vopb_out_edp: endpoint at 0 {
+ reg = <0>;
+ remote-endpoint = <&edp_in_vopb>;
+ };
};
};
@@ -1342,6 +1352,41 @@
status = "disabled";
};
+ edp: edp at ff970000 {
+ compatible = "rockchip,rk3399-edp";
+ reg = <0x0 0xff970000 0x0 0x8000>;
+ interrupts = <GIC_SPI 10 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cru PCLK_EDP>, <&cru PCLK_EDP_CTRL>;
+ clock-names = "dp", "pclk";
+ resets = <&cru SRST_P_EDP_CTRL>;
+ reset-names = "dp";
+ rockchip,grf = <&grf>;
+ status = "disabled";
+ pinctrl-names = "default";
+ pinctrl-0 = <&edp_hpd>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ edp_in: port at 0 {
+ reg = <0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ edp_in_vopb: endpoint at 0 {
+ reg = <0>;
+ remote-endpoint = <&vopb_out_edp>;
+ };
+
+ edp_in_vopl: endpoint at 1 {
+ reg = <1>;
+ remote-endpoint = <&vopl_out_edp>;
+ };
+ };
+ };
+ };
+
display_subsystem: display-subsystem {
compatible = "rockchip,display-subsystem";
ports = <&vopl_out>, <&vopb_out>;
@@ -1469,6 +1514,13 @@
};
};
+ edp {
+ edp_hpd: edp-hpd {
+ rockchip,pins =
+ <4 23 RK_FUNC_2 &pcfg_pull_none>;
+ };
+ };
+
gmac {
rgmii_pins: rgmii-pins {
rockchip,pins =
--
2.7.4
^ permalink raw reply related
* [PATCH v2 5/9] arm64: dts: rockchip: add backlight support for rk3399 evb board
From: Caesar Wang @ 2016-11-09 13:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478697721-2323-1-git-send-email-wxt@rock-chips.com>
From: Yakir Yang <ykk@rock-chips.com>
Add backlight node for evb board, perpare for panel device node.
Signed-off-by: Yakir Yang <ykk@rock-chips.com>
Signed-off-by: Caesar Wang <wxt@rock-chips.com>
---
Changes in v2: None
arch/arm64/boot/dts/rockchip/rk3399-evb.dts | 40 +++++++++++++++++++++++++++++
1 file changed, 40 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-evb.dts b/arch/arm64/boot/dts/rockchip/rk3399-evb.dts
index 8e82497..c585e93 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-evb.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3399-evb.dts
@@ -49,6 +49,46 @@
compatible = "rockchip,rk3399-evb", "rockchip,rk3399",
"google,rk3399evb-rev2";
+ backlight: backlight {
+ compatible = "pwm-backlight";
+ pwms = <&pwm0 0 25000 0>;
+ 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 = <200>;
+ enable-gpios = <&gpio1 13 GPIO_ACTIVE_HIGH>;
+ };
+
clkin_gmac: external-gmac-clock {
compatible = "fixed-clock";
clock-frequency = <125000000>;
--
2.7.4
^ permalink raw reply related
* [PATCH v2 6/9] arm64: dts: rockchip: introduce pclk_vio_grf in eDP device node
From: Caesar Wang @ 2016-11-09 13:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478697721-2323-1-git-send-email-wxt@rock-chips.com>
From: Yakir Yang <ykk@rock-chips.com>
The pclk_vio_grf supply power for VIO GRF IOs, if it is disabled, driver
would failed to operate the VIO GRF registers.
Signed-off-by: Yakir Yang <ykk@rock-chips.com>
Signed-off-by: Caesar Wang <wxt@rock-chips.com>
---
Changes in v2: None
arch/arm64/boot/dts/rockchip/rk3399.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index 6544910..74deb44 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -1356,8 +1356,8 @@
compatible = "rockchip,rk3399-edp";
reg = <0x0 0xff970000 0x0 0x8000>;
interrupts = <GIC_SPI 10 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&cru PCLK_EDP>, <&cru PCLK_EDP_CTRL>;
- clock-names = "dp", "pclk";
+ clocks = <&cru PCLK_EDP>, <&cru PCLK_EDP_CTRL>, <&cru PCLK_VIO_GRF>;
+ clock-names = "dp", "pclk", "grf";
resets = <&cru SRST_P_EDP_CTRL>;
reset-names = "dp";
rockchip,grf = <&grf>;
--
2.7.4
^ permalink raw reply related
* [PATCH v2 7/9] arm64: dts: rockchip: add pd_edp node for rk3399
From: Caesar Wang @ 2016-11-09 13:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478697721-2323-1-git-send-email-wxt@rock-chips.com>
From: zhangqing <zhangqing@rock-chips.com>
1. add pd node for RK3399 Soc
2. create power domain tree
3. add qos node for domain
4. add the pd support for edp
Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>
Signed-off-by: Caesar Wang <wxt@rock-chips.com>
---
Changes in v2: None
arch/arm64/boot/dts/rockchip/rk3399.dtsi | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index 74deb44..09ebf4e 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -835,6 +835,10 @@
};
/* These power domains are grouped by VD_LOGIC */
+ pd_edp at RK3399_PD_EDP {
+ reg = <RK3399_PD_EDP>;
+ clocks = <&cru PCLK_EDP_CTRL>;
+ };
pd_emmc at RK3399_PD_EMMC {
reg = <RK3399_PD_EMMC>;
clocks = <&cru ACLK_EMMC>;
@@ -1364,6 +1368,7 @@
status = "disabled";
pinctrl-names = "default";
pinctrl-0 = <&edp_hpd>;
+ power-domains = <&power RK3399_PD_EDP>;
ports {
#address-cells = <1>;
--
2.7.4
^ permalink raw reply related
* [PATCH v2 8/9] arm64: dts: rockchip: support dwc3 USB for rk3399
From: Caesar Wang @ 2016-11-09 13:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478697721-2323-1-git-send-email-wxt@rock-chips.com>
From: Brian Norris <briannorris@chromium.org>
Add the dwc3 usb needed node information for rk3399.
Signed-off-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Caesar Wang <wxt@rock-chips.com>
---
Changes in v2:
- the original patches from brian posting on
https://chromium-review.googlesource.com/343603
arch/arm64/boot/dts/rockchip/rk3399.dtsi | 54 ++++++++++++++++++++++++++++++++
1 file changed, 54 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index 09ebf4e..3659c56 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -353,6 +353,60 @@
status = "disabled";
};
+ usbdrd3_0: usb at fe800000 {
+ compatible = "rockchip,rk3399-dwc3";
+ clocks = <&cru SCLK_USB3OTG0_REF>, <&cru SCLK_USB3OTG0_SUSPEND>,
+ <&cru ACLK_USB3OTG0>, <&cru ACLK_USB3_GRF>;
+ clock-names = "ref_clk", "suspend_clk",
+ "bus_clk", "grf_clk";
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+ status = "disabled";
+ usbdrd_dwc3_0: dwc3 at fe800000 {
+ compatible = "snps,dwc3";
+ reg = <0x0 0xfe800000 0x0 0x100000>;
+ interrupts = <GIC_SPI 105 IRQ_TYPE_LEVEL_HIGH 0>;
+ dr_mode = "otg";
+ phys = <&tcphy0_usb3>;
+ phy-names = "usb3-phy";
+ phy_type = "utmi_wide";
+ snps,dis_enblslpm_quirk;
+ snps,dis-u2-freeclk-exists-quirk;
+ snps,dis_u2_susphy_quirk;
+ snps,dis-del-phy-power-chg-quirk;
+ snps,xhci-slow-suspend-quirk;
+ status = "disabled";
+ };
+ };
+
+ usbdrd3_1: usb at fe900000 {
+ compatible = "rockchip,rk3399-dwc3";
+ clocks = <&cru SCLK_USB3OTG1_REF>, <&cru SCLK_USB3OTG1_SUSPEND>,
+ <&cru ACLK_USB3OTG1>, <&cru ACLK_USB3_GRF>;
+ clock-names = "ref_clk", "suspend_clk",
+ "bus_clk", "grf_clk";
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+ status = "disabled";
+ usbdrd_dwc3_1: dwc3 at fe900000 {
+ compatible = "snps,dwc3";
+ reg = <0x0 0xfe900000 0x0 0x100000>;
+ interrupts = <GIC_SPI 110 IRQ_TYPE_LEVEL_HIGH 0>;
+ dr_mode = "host";
+ phys = <&tcphy1_usb3>;
+ phy-names = "usb3-phy";
+ phy_type = "utmi_wide";
+ snps,dis_enblslpm_quirk;
+ snps,dis-u2-freeclk-exists-quirk;
+ snps,dis_u2_susphy_quirk;
+ snps,dis-del-phy-power-chg-quirk;
+ snps,xhci-slow-suspend-quirk;
+ status = "disabled";
+ };
+ };
+
gic: interrupt-controller at fee00000 {
compatible = "arm,gic-v3";
#interrupt-cells = <4>;
--
2.7.4
^ permalink raw reply related
* [PATCH v2 9/9] arm64: dts: rockchip: add the usb3 pd for rk3399
From: Caesar Wang @ 2016-11-09 13:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478697721-2323-1-git-send-email-wxt@rock-chips.com>
1. add pd node for RK3399 Soc
2. create power domain tree
3. add qos node for domain
4. add the pd support for usb3
Signed-off-by: Caesar Wang <wxt@rock-chips.com>
---
Changes in v2:
- Reviewed-on: https://chromium-review.googlesource.com/384280
arch/arm64/boot/dts/rockchip/rk3399.dtsi | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index 3659c56..7480fa7 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -376,6 +376,7 @@
snps,dis_u2_susphy_quirk;
snps,dis-del-phy-power-chg-quirk;
snps,xhci-slow-suspend-quirk;
+ power-domains = <&power RK3399_PD_USB3>;
status = "disabled";
};
};
@@ -403,6 +404,7 @@
snps,dis_u2_susphy_quirk;
snps,dis-del-phy-power-chg-quirk;
snps,xhci-slow-suspend-quirk;
+ power-domains = <&power RK3399_PD_USB3>;
status = "disabled";
};
};
@@ -746,6 +748,16 @@
status = "disabled";
};
+ qos_usb_otg0: qos at ffa70000 {
+ compatible = "syscon";
+ reg = <0x0 0xffa70000 0x0 0x20>;
+ };
+
+ qos_usb_otg1: qos at ffa70080 {
+ compatible = "syscon";
+ reg = <0x0 0xffa70080 0x0 0x20>;
+ };
+
qos_sd: qos at ffa74000 {
compatible = "syscon";
reg = <0x0 0xffa74000 0x0 0x20>;
@@ -909,6 +921,12 @@
<&cru SCLK_SDMMC>;
pm_qos = <&qos_sd>;
};
+ pd_usb3 at RK3399_PD_USB3 {
+ reg = <RK3399_PD_USB3>;
+ clocks = <&cru ACLK_USB3>;
+ pm_qos = <&qos_usb_otg0>,
+ <&qos_usb_otg1>;
+ };
pd_vio at RK3399_PD_VIO {
reg = <RK3399_PD_VIO>;
#address-cells = <1>;
--
2.7.4
^ permalink raw reply related
* [PATCH v6 13/16] drivers: iommu: arm-smmu: add IORT configuration
From: Tomasz Nowicki @ 2016-11-09 13:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161018160414.1228-14-lorenzo.pieralisi@arm.com>
Hi Lorenzo,
On 18.10.2016 18:04, Lorenzo Pieralisi wrote:
> In ACPI bases systems, in order to be able to create platform
> devices and initialize them for ARM SMMU components, the IORT
> kernel implementation requires a set of static functions to be
> used by the IORT kernel layer to configure platform devices for
> ARM SMMU components.
>
> Add static configuration functions to the IORT kernel layer for
> the ARM SMMU components, so that the ARM SMMU driver can
> initialize its respective platform device by relying on the IORT
> kernel infrastructure and by adding a corresponding ACPI device
> early probe section entry.
>
> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> Cc: Will Deacon <will.deacon@arm.com>
> Cc: Robin Murphy <robin.murphy@arm.com>
> Cc: Joerg Roedel <joro@8bytes.org>
> ---
> drivers/acpi/arm64/iort.c | 81 +++++++++++++++++++++++++++++++++++++++++++++
> drivers/iommu/arm-smmu.c | 84 ++++++++++++++++++++++++++++++++++++++++++++++-
> include/linux/acpi_iort.h | 3 ++
> 3 files changed, 167 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
> index ea90bc8..04cc5f7 100644
> --- a/drivers/acpi/arm64/iort.c
> +++ b/drivers/acpi/arm64/iort.c
> @@ -548,6 +548,78 @@ static bool __init arm_smmu_v3_is_coherent(struct acpi_iort_node *node)
> return smmu->flags & ACPI_IORT_SMMU_V3_COHACC_OVERRIDE;
> }
>
[...]
> +
> +static int arm_smmu_device_acpi_probe(struct platform_device *pdev,
> + struct arm_smmu_device *smmu)
> +{
> + struct device *dev = smmu->dev;
> + struct acpi_iort_node *node =
> + *(struct acpi_iort_node **)dev_get_platdata(dev);
> + struct acpi_iort_smmu *iort_smmu;
> + u64 *glb_irq;
> + int ret;
> +
> + /* Retrieve SMMU1/2 specific data */
> + iort_smmu = (struct acpi_iort_smmu *)node->node_data;
> +
> + ret = acpi_smmu_get_data(iort_smmu->model, &smmu->version,
> + &smmu->model);
> + if (ret < 0)
> + return ret;
> +
> + glb_irq = ACPI_ADD_PTR(u64, iort_smmu,
> + iort_smmu->global_interrupt_offset);
One bug that I found:
- glb_irq = ACPI_ADD_PTR(u64, iort_smmu,
- iort_smmu->global_interrupt_offset);
+ glb_irq = ACPI_ADD_PTR(u64, node,
+ iort_smmu->global_interrupt_offset);
With this fix, I run VM with several PCI devices (NIC, SATA) in
passthrough mode successfully on ACPI host using ThunderX 1-socket board.
Also, for my tests I used Eric's patches:
https://github.com/eauger/linux/commits/v4.9-rc3-reserved-rfc-v2
Including bug fix above:
Tested-by: Tomasz Nowicki <tn@semihalf.com> for all series.
> +
> + if (!IORT_IRQ_MASK(glb_irq[1])) /* 0 means not implemented */
> + smmu->num_global_irqs = 1;
> + else
> + smmu->num_global_irqs = 2;
> +
> + if (iort_smmu->flags & ACPI_IORT_SMMU_COHERENT_WALK)
> + smmu->features |= ARM_SMMU_FEAT_COHERENT_WALK;
> +
> + return 0;
> +}
> +#else
> +static inline int arm_smmu_device_acpi_probe(struct platform_device *pdev,
> + struct arm_smmu_device *smmu)
> +{
> + return -ENODEV;
> +}
> +#endif
> +
Thanks,
Tomasz
^ permalink raw reply
* [PATCH v2 0/7] soc: renesas: Identify SoC and register with the SoC bus
From: Geert Uytterhoeven @ 2016-11-09 13:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMuHMdV4HG0aOr4Qp_OZXU=3jLeOJ2QaMKp09a3v4489ABbRcA@mail.gmail.com>
Hi Arnd,
On Mon, Nov 7, 2016 at 10:35 AM, Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> On Mon, Oct 31, 2016 at 12:30 PM, Geert Uytterhoeven
> <geert+renesas@glider.be> wrote:
>> Some Renesas SoCs may exist in different revisions, providing slightly
>> different functionalities (e.g. R-Car H3 ES1.x and ES2.0), and behavior
>> (errate and quirks). This needs to be catered for by drivers and/or
>> platform code. The recently proposed soc_device_match() API seems like
>> a good fit to handle this.
>>
>> This patch series implements the core infrastructure to provide SoC and
>> revision information through the SoC bus for Renesas ARM SoCs. It
>> consists of 7 patches:
>> - Patches 1-4 provide soc_device_match(), with some related fixes,
>> - Patches 5-7 implement identification of Renesas SoCs and
>> registration with the SoC bus,
>>
>> Changes compared to v1:
>> - Add Acked-by,
>> - New patches:
>> - "[4/7] base: soc: Provide a dummy implementation of
>> soc_device_match()",
>> - "[5/7] ARM: shmobile: Document DT bindings for CCCR and PRR",
>> - "[6/7] arm64: dts: r8a7795: Add device node for PRR"
>> (more similar patches available, I'm not yet spamming you all
>> with them),
>> - Drop SoC families and family names; use fixed "Renesas" instead,
>> - Drop EMEV2, which doesn't have a chip ID register, and doesn't share
>> devices with other SoCs,
>> - Drop RZ/A1H and R-CAR M1A, which don't have chip ID registers (for
>> M1A: not accessible from the ARM core?),
>> - On arm, move "select SOC_BUS" from ARCH_RENESAS to Kconfig symbols
>> for SoCs that provide a chip ID register,
>> - Build renesas-soc only if SOC_BUS is enabled,
>> - Use "renesas,prr" and "renesas,cccr" device nodes in DT if
>> available, else fall back to hardcoded addresses for compatibility
>> with existing DTBs,
>> - Remove verification of product IDs; just print the ID instead,
>> - Don't register the SoC bus if the chip ID register is missing,
>> - Change R-Mobile APE6 fallback to use PRR instead of CCCR (it has
>> both).
>>
>> Merge strategy:
>> - In theory, patches 1-4 should go through Greg's driver core tree.
>> But it's a hard dependency for all users.
>> If people agree, I can provide an immutable branch in my
>> renesas-drivers repository, to be merged by all interested parties.
>> So far I'm aware of Freescale/NXP, and Renesas.
>
> And Samsung.
> Shall I create the immutable branch now?
Arnd: are you happy with the new patches and changes?
Thanks again!
>> - Patches 5-7 obviously have to go through Simon's Renesas tree (after
>> merging the soc_device_match() core), and arm-soc.
>>
>> Tested on (machine, soc_id, optional revision):
>> EMEV2 KZM9D Board, emev2
>> Genmai, r7s72100
>> APE6EVM, r8a73a4, ES1.0
>> armadillo 800 eva, r8a7740, ES2.0
>> bockw, r8a7778
>> marzen, r8a7779, ES1.0
>> Lager, r8a7790, ES1.0
>> Koelsch, r8a7791, ES1.0
>> Porter, r8a7791, ES3.0
>> Blanche, r8a7792, ES1.1
>> Gose, r8a7793, ES1.0
>> Alt, r8a7794, ES1.0
>> Renesas Salvator-X board based on r8a7795, r8a7795, ES1.0
>> Renesas Salvator-X board based on r8a7795, r8a7795, ES1.1
>> Renesas Salvator-X board based on r8a7796, r8a7796, ES1.0
>> KZM-A9-GT, sh73a0, ES2.0
>>
>> For your convenience, this series (incl. more DT updates to add device
>> nodes for CCCR and PRR to all other Renesas ARM SoCs) is also available
>> in the topic/renesas-soc-id-v2 branch of my renesas-drivers git
>> repository at
>> git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git
>> Its first user is support for R-Car H3 ES2.0 in branch
>> topic/r8a7795-es2-v1-rebased2.
>>
>> Thanks for your comments!
>>
>> Arnd Bergmann (1):
>> base: soc: Introduce soc_device_match() interface
>>
>> Geert Uytterhoeven (6):
>> base: soc: Early register bus when needed
>> base: soc: Check for NULL SoC device attributes
>> base: soc: Provide a dummy implementation of soc_device_match()
>> ARM: shmobile: Document DT bindings for CCCR and PRR
>> arm64: dts: r8a7795: Add device node for PRR
>> soc: renesas: Identify SoC and register with the SoC bus
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH V5 2/3] ARM64 LPC: Add missing range exception for special ISA
From: One Thousand Gnomes @ 2016-11-09 13:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2368890.jTbyGqYR0M@wuerfel>
> I think it is a relatively safe assumption that there is only one
> ISA bridge. A lot of old drivers hardcode PIO or memory addresses
It's not a safe assumption for x86 at least. There are a few systems with
multiple ISA busses particularly older laptops with a docking station.
> when talking to an ISA device, so having multiple instances is
> already problematic.
PCMCIA devices handle it themselves so are ok. I'm not clear how the dual
PIIX4 configuration used in the older IBM laptop docks actually worked so
I assume the transaction went out of both bridges and providing one of
them responded the other kept silent as you simply stuffed the card into
the dock and it worked.
Alan
^ permalink raw reply
* [PATCH 11/13] ARM: dts: rockchip: replace to "max-frequency" instead of "clock-freq-min-max"
From: Heiko Stuebner @ 2016-11-09 14:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161103062135.10697-12-jh80.chung@samsung.com>
Am Donnerstag, 3. November 2016, 15:21:33 CET schrieb Jaehoon Chung:
> In drivers/mmc/core/host.c, there is "max-frequency" property.
> It should be same behavior. So use the "max-frequency" instead of
> "clock-freq-min-max".
>
> Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
looks good, my veyron-pinky and rk3036-kylin still seem to work and hopefully
I haven't missed any spelling errors in the properties :-), so applied to my
dts32 branch for 4.10
Thanks
Heiko
^ permalink raw reply
* [PATCH] drm/rockchip: analogix_dp: add supports for regulators in edp IP
From: ayaka @ 2016-11-09 14:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <16dfbe16-eae7-8da9-4108-07e623210d35@rock-chips.com>
On 10/28/2016 05:29 PM, Randy Li wrote:
>
>
> On 10/28/2016 05:11 PM, Shawn Lin wrote:
>> On 2016/10/23 3:18, Randy Li wrote:
>>> I found if eDP_AVDD_1V0 and eDP_AVDD_1V8 are not been power at
>>> RK3288, once trying to enable the pclk clock, the kernel would dead.
>>> This patch would try to enable them first. The eDP_AVDD_1V8 more
>>> likely to be applied to eDP phy, but I have no time to confirmed
>>> it yet.
>>
>> Comfirm it or at least someone should be able to answer your
>> question, Mark?
> I just forget to ask the IC department, the TRM didn't cover that.
The IC staff have told me that the AVDD_1V8 is for phy, but AVDD_1V0 is
for both of them. I should find a way to make the power sequence correctly.
I am a little busy recently, a new patch would not be available in a
short time.
>>
>> Have you considered to add some details about vcc-supply and vccio-
>> supply for your analogix_dp-rockchip.txt ?
>>
>> From your commit msg, these two properties are more likely to be
>> required but the code itself tell me them should be optional(from the
>> point of backward compatibility, it should also be optinoal).
> Yes, I keep it optional for the same reason. Most of boards won't turn
> off those power supply and may use some fixed regulators.
>>
>>>
>>> Signed-off-by: Randy Li <ayaka@soulik.info>
>>> ---
>>> drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 25
>>> +++++++++++++++++++++++++
>>> 1 file changed, 25 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
>>> b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
>>> index 8548e82..6bf0441 100644
>>> --- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
>>> +++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
>>> @@ -17,6 +17,7 @@
>>> #include <linux/of_device.h>
>>> #include <linux/of_graph.h>
>>> #include <linux/regmap.h>
>>> +#include <linux/regulator/consumer.h>
>>> #include <linux/reset.h>
>>> #include <linux/clk.h>
>>>
>>> @@ -70,6 +71,7 @@ struct rockchip_dp_device {
>>> struct clk *grfclk;
>>> struct regmap *grf;
>>> struct reset_control *rst;
>>> + struct regulator_bulk_data supplies[2];
>>>
>>> struct work_struct psr_work;
>>> spinlock_t psr_lock;
>>> @@ -146,6 +148,13 @@ static int rockchip_dp_poweron(struct
>>> analogix_dp_plat_data *plat_data)
>>>
>>> cancel_work_sync(&dp->psr_work);
>>>
>>> + ret = regulator_bulk_enable(ARRAY_SIZE(dp->supplies),
>>> + dp->supplies);
>>> + if (ret) {
>>> + dev_err(dp->dev, "failed to enable vdd supply %d\n", ret);
>>> + return ret;
>>> + }
>>> +
>>> ret = clk_prepare_enable(dp->pclk);
>>> if (ret < 0) {
>>> dev_err(dp->dev, "failed to enable pclk %d\n", ret);
>>> @@ -168,6 +177,9 @@ static int rockchip_dp_powerdown(struct
>>> analogix_dp_plat_data *plat_data)
>>>
>>> clk_disable_unprepare(dp->pclk);
>>>
>>> + regulator_bulk_disable(ARRAY_SIZE(dp->supplies),
>>> + dp->supplies);
>>> +
>>> return 0;
>>> }
>>>
>>> @@ -323,6 +335,19 @@ static int rockchip_dp_init(struct
>>> rockchip_dp_device *dp)
>>> return PTR_ERR(dp->rst);
>>> }
>>>
>>> + dp->supplies[0].supply = "vcc";
>>> + dp->supplies[1].supply = "vccio";
>>> + ret = devm_regulator_bulk_get(dev, ARRAY_SIZE(dp->supplies),
>>> + dp->supplies);
>>> + if (ret < 0) {
>>> + dev_err(dev, "failed to get regulators: %d\n", ret);
>>> + }
>>> + ret = regulator_bulk_enable(ARRAY_SIZE(dp->supplies),
>>> + dp->supplies);
>>> + if (ret < 0) {
>>> + dev_err(dev, "failed to enable regulators: %d\n", ret);
>>> + }
>>> +
>>> ret = clk_prepare_enable(dp->pclk);
>>> if (ret < 0) {
>>> dev_err(dp->dev, "failed to enable pclk %d\n", ret);
>>>
>>
>>
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox