* [PATCH v2 7/8] iommu: Remove IOMMU_OF_DECLARE
From: Marek Szyprowski @ 2018-05-28 6:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180524175024.19874-8-robh@kernel.org>
Hi Rob,
On 2018-05-24 19:50, Rob Herring wrote:
> Now that we use the driver core to stop deferred probe for missing
> drivers, IOMMU_OF_DECLARE can be removed.
>
> This is slightly less optimal than having a list of built-in drivers in
> that we'll now defer probe twice before giving up. This shouldn't have a
> significant impact on boot times as past discussions about deferred
> probe have given no evidence of deferred probe having a substantial
> impact.
>
> Cc: Will Deacon <will.deacon@arm.com>
> Cc: Robin Murphy <robin.murphy@arm.com>
> Cc: Joerg Roedel <joro@8bytes.org>
> Cc: Marek Szyprowski <m.szyprowski@samsung.com>
> Cc: Kukjin Kim <kgene@kernel.org>
> Cc: Krzysztof Kozlowski <krzk@kernel.org>
> Cc: Rob Clark <robdclark@gmail.com>
> Cc: Heiko Stuebner <heiko@sntech.de>
> Cc: Frank Rowand <frowand.list@gmail.com>
> Cc: linux-arm-kernel at lists.infradead.org
> Cc: iommu at lists.linux-foundation.org
> Cc: linux-samsung-soc at vger.kernel.org
> Cc: linux-arm-msm at vger.kernel.org
> Cc: linux-rockchip at lists.infradead.org
> Cc: devicetree at vger.kernel.org
> Signed-off-by: Rob Herring <robh@kernel.org>
For Exynos IOMMU:
Acked-by: Marek Szyprowski <m.szyprowski@samsung.com>
> ---
> drivers/iommu/arm-smmu-v3.c | 2 --
> drivers/iommu/arm-smmu.c | 7 -------
> drivers/iommu/exynos-iommu.c | 2 --
> drivers/iommu/ipmmu-vmsa.c | 3 ---
> drivers/iommu/msm_iommu.c | 2 --
> drivers/iommu/of_iommu.c | 19 +------------------
> drivers/iommu/qcom_iommu.c | 2 --
> drivers/iommu/rockchip-iommu.c | 2 --
> include/linux/of_iommu.h | 4 ----
> 9 files changed, 1 insertion(+), 42 deletions(-)
>
> diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c
> index 1d647104bccc..22bdabd3d8e0 100644
> --- a/drivers/iommu/arm-smmu-v3.c
> +++ b/drivers/iommu/arm-smmu-v3.c
> @@ -2915,8 +2915,6 @@ static struct platform_driver arm_smmu_driver = {
> };
> module_platform_driver(arm_smmu_driver);
>
> -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>");
> MODULE_LICENSE("GPL v2");
> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
> index 69e7c60792a8..9dd7cbaa3b0c 100644
> --- a/drivers/iommu/arm-smmu.c
> +++ b/drivers/iommu/arm-smmu.c
> @@ -2211,13 +2211,6 @@ static struct platform_driver arm_smmu_driver = {
> };
> module_platform_driver(arm_smmu_driver);
>
> -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>");
> MODULE_LICENSE("GPL v2");
> diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c
> index 85879cfec52f..b128cb4372d3 100644
> --- a/drivers/iommu/exynos-iommu.c
> +++ b/drivers/iommu/exynos-iommu.c
> @@ -1390,5 +1390,3 @@ static int __init exynos_iommu_init(void)
> return ret;
> }
> core_initcall(exynos_iommu_init);
> -
> -IOMMU_OF_DECLARE(exynos_iommu_of, "samsung,exynos-sysmmu");
> diff --git a/drivers/iommu/ipmmu-vmsa.c b/drivers/iommu/ipmmu-vmsa.c
> index 40ae6e87cb88..f026aa16d5f1 100644
> --- a/drivers/iommu/ipmmu-vmsa.c
> +++ b/drivers/iommu/ipmmu-vmsa.c
> @@ -1108,9 +1108,6 @@ static void __exit ipmmu_exit(void)
> subsys_initcall(ipmmu_init);
> module_exit(ipmmu_exit);
>
> -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>");
> MODULE_LICENSE("GPL v2");
> diff --git a/drivers/iommu/msm_iommu.c b/drivers/iommu/msm_iommu.c
> index 0d3350463a3f..27377742600d 100644
> --- a/drivers/iommu/msm_iommu.c
> +++ b/drivers/iommu/msm_iommu.c
> @@ -877,7 +877,5 @@ 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");
> -
> 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 2aac8387717c..1904ccf9fc4e 100644
> --- a/drivers/iommu/of_iommu.c
> +++ b/drivers/iommu/of_iommu.c
> @@ -27,9 +27,6 @@
>
> #define NO_IOMMU 1
>
> -static const struct of_device_id __iommu_of_table_sentinel
> - __used __section(__iommu_of_table_end);
> -
> /**
> * of_get_dma_window - Parse *dma-window property and returns 0 if found.
> *
> @@ -98,19 +95,6 @@ int of_get_dma_window(struct device_node *dn, const char *prefix, int index,
> }
> EXPORT_SYMBOL_GPL(of_get_dma_window);
>
> -static bool of_iommu_driver_present(struct device_node *np)
> -{
> - /*
> - * If the IOMMU still isn't ready by the time we reach init, assume
> - * it never will be. We don't want to defer indefinitely, nor attempt
> - * to dereference __iommu_of_table after it's been freed.
> - */
> - if (system_state >= SYSTEM_RUNNING)
> - return false;
> -
> - return of_match_node(&__iommu_of_table, np);
> -}
> -
> static int of_iommu_xlate(struct device *dev,
> struct of_phandle_args *iommu_spec)
> {
> @@ -120,8 +104,7 @@ static int of_iommu_xlate(struct device *dev,
>
> ops = iommu_ops_from_fwnode(fwnode);
> if ((ops && !ops->of_xlate) ||
> - !of_device_is_available(iommu_spec->np) ||
> - (!ops && !of_iommu_driver_present(iommu_spec->np)))
> + !of_device_is_available(iommu_spec->np))
> return NO_IOMMU;
>
> err = iommu_fwspec_init(dev, &iommu_spec->np->fwnode, ops);
> diff --git a/drivers/iommu/qcom_iommu.c b/drivers/iommu/qcom_iommu.c
> index 65b9c99707f8..fa0f6c39a144 100644
> --- a/drivers/iommu/qcom_iommu.c
> +++ b/drivers/iommu/qcom_iommu.c
> @@ -947,7 +947,5 @@ 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");
> -
> MODULE_DESCRIPTION("IOMMU API for QCOM IOMMU v1 implementations");
> MODULE_LICENSE("GPL v2");
> diff --git a/drivers/iommu/rockchip-iommu.c b/drivers/iommu/rockchip-iommu.c
> index 0468acfa131f..90d37f29c24c 100644
> --- a/drivers/iommu/rockchip-iommu.c
> +++ b/drivers/iommu/rockchip-iommu.c
> @@ -1284,8 +1284,6 @@ static int __init rk_iommu_init(void)
> }
> subsys_initcall(rk_iommu_init);
>
> -IOMMU_OF_DECLARE(rk_iommu_of, "rockchip,iommu");
> -
> MODULE_DESCRIPTION("IOMMU API for Rockchip");
> MODULE_AUTHOR("Simon Xue <xxm@rock-chips.com> and Daniel Kurtz <djkurtz@chromium.org>");
> MODULE_ALIAS("platform:rockchip-iommu");
> diff --git a/include/linux/of_iommu.h b/include/linux/of_iommu.h
> index 4fa654e4b5a9..f3d40dd7bb66 100644
> --- a/include/linux/of_iommu.h
> +++ b/include/linux/of_iommu.h
> @@ -32,8 +32,4 @@ static inline const struct iommu_ops *of_iommu_configure(struct device *dev,
>
> #endif /* CONFIG_OF_IOMMU */
>
> -extern struct of_device_id __iommu_of_table;
> -
> -#define IOMMU_OF_DECLARE(name, compat) OF_DECLARE_1(iommu, name, compat, NULL)
> -
> #endif /* __OF_IOMMU_H */
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
^ permalink raw reply
* [PATCH] mmc: sunxi: mark PM functions as __maybe_unused
From: Maxime Ripard @ 2018-05-28 6:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180525210752.1794502-1-arnd@arndb.de>
On Fri, May 25, 2018 at 11:07:42PM +0200, Arnd Bergmann wrote:
> The newly added runtime-pm functions cause a harmless warning
> when CONFIG_PM is disabled:
>
> drivers/mmc/host/sunxi-mmc.c:1452:12: error: 'sunxi_mmc_runtime_suspend' defined but not used [-Werror=unused-function]
> static int sunxi_mmc_runtime_suspend(struct device *dev)
> ^~~~~~~~~~~~~~~~~~~~~~~~~
> drivers/mmc/host/sunxi-mmc.c:1435:12: error: 'sunxi_mmc_runtime_resume' defined but not used [-Werror=unused-function]
> static int sunxi_mmc_runtime_resume(struct device *dev)
>
> This marks them as __maybe_unused to shut up the warning.
>
> Fixes: 9a8e1e8cc2c0 ("mmc: sunxi: Add runtime_pm support")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Maxime Ripard <maxime.ripard@bootlin.com>
Thanks!
Maxime
--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
-------------- 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/20180528/7e148807/attachment.sig>
^ permalink raw reply
* [Query] PAGE_OFFSET on KASLR enabled ARM64 kernel
From: Ard Biesheuvel @ 2018-05-28 6:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACi5LpO8KVVD_6ZJTW2SiyR8v0uDMA3H9yKHNw1=RKO+fd7KjA@mail.gmail.com>
On 27 May 2018 at 23:03, Bhupesh Sharma <bhsharma@redhat.com> wrote:
> Hi ARM64 maintainers,
>
> I am confused about the PAGE_OFFSET value (or the start of the linear
> map) on a KASLR enabled ARM64 kernel that I am seeing on a board which
> supports a compatible EFI firmware (with EFI_RNG_PROTOCOL support).
>
> 1. 'arch/arm64/include/asm/memory.h' defines PAGE_OFFSET as:
>
> /*
> * PAGE_OFFSET - the virtual address of the start of the linear map (top
> * (VA_BITS - 1))
> */
> #define PAGE_OFFSET (UL(0xffffffffffffffff) - \
> (UL(1) << (VA_BITS - 1)) + 1)
>
> So for example on a platform with VA_BITS=48, we have:
> PAGE_OFFSET = 0xffff800000000000
>
> 2. However, for the KASLR case, we set the 'memstart_offset_seed ' to
> use the 16-bits of the 'kaslr-seed' to randomize the linear region in
> 'arch/arm64/kernel/kaslr.c' :
>
> u64 __init kaslr_early_init(u64 dt_phys)
> {
> <snip..>
> /* use the top 16 bits to randomize the linear region */
> memstart_offset_seed = seed >> 48;
> <snip..>
> }
>
> 3. Now, we use the 'memstart_offset_seed' value to randomize the
> 'memstart_addr' value in 'arch/arm64/mm/init.c':
>
> void __init arm64_memblock_init(void)
> {
> <snip..>
>
> if (IS_ENABLED(CONFIG_RANDOMIZE_BASE)) {
> extern u16 memstart_offset_seed;
> u64 range = linear_region_size -
> (memblock_end_of_DRAM() - memblock_start_of_DRAM());
>
> /*
> * If the size of the linear region exceeds, by a sufficient
> * margin, the size of the region that the available physical
> * memory spans, randomize the linear region as well.
> */
> if (memstart_offset_seed > 0 && range >= ARM64_MEMSTART_ALIGN) {
> range = range / ARM64_MEMSTART_ALIGN + 1;
> memstart_addr -= ARM64_MEMSTART_ALIGN *
> ((range * memstart_offset_seed) >> 16);
> }
> }
> <snip..>
> }
>
> 4. Since 'memstart_addr' indicates the start of physical RAM, we
> randomize the same on basis of 'memstart_offset_seed' value above.
> Also the 'memstart_addr' value is available in '/proc/kallsyms' and
> hence can be accessed by user-space applications to read the
> 'memstart_addr' value.
>
> 5. Now since the PAGE_OFFSET value is also used by several user space
> tools (for e.g. makedumpfile tool uses the same to determine the start
> of linear region and hence to read PT_NOTE fields from /proc/kcore), I
> am not sure how to read the randomized value of the same in the KASLR
> enabled case.
>
> 6. Reading the code further and adding some debug prints, it seems the
> 'memblock_start_of_DRAM()' value is more closer to the actual start of
> linear region rather than 'memstart_addr' and 'PAGE_OFFSET" in case of
> KASLR enabled kernel:
>
> [root at qualcomm-amberwing] # dmesg | grep -i "arm64_memblock_init" -A 5
>
> [ 0.000000] inside arm64_memblock_init, memstart_addr = ffff976a00000000,
> linearstart_addr = ffffe89600200000, memblock_start_of_DRAM = ffffe89600200000,
> PHYS_OFFSET = ffff976a00000000, PAGE_OFFSET = ffff800000000000,
> KIMAGE_VADDR = ffff000008000000, kimage_vaddr = ffff20c2d7800000
>
> [root at qualcomm-amberwing] # dmesg | grep -i "Virtual kernel memory layout" -A 15
> [ 0.000000] Virtual kernel memory layout:
> [ 0.000000] modules : 0xffff000000000000 - 0xffff000008000000
> ( 128 MB)
> [ 0.000000] vmalloc : 0xffff000008000000 - 0xffff7bdfffff0000
> (126847 GB)
> [ 0.000000] .text : 0xffff20c2d7880000 - 0xffff20c2d8040000
> ( 7936 KB)
> [ 0.000000] .rodata : 0xffff20c2d8040000 - 0xffff20c2d83a0000
> ( 3456 KB)
> [ 0.000000] .init : 0xffff20c2d83a0000 - 0xffff20c2d8750000
> ( 3776 KB)
> [ 0.000000] .data : 0xffff20c2d8750000 - 0xffff20c2d891b200
> ( 1837 KB)
> [ 0.000000] .bss : 0xffff20c2d891b200 - 0xffff20c2d90a5198
> ( 7720 KB)
> [ 0.000000] fixed : 0xffff7fdffe790000 - 0xffff7fdffec00000
> ( 4544 KB)
> [ 0.000000] PCI I/O : 0xffff7fdffee00000 - 0xffff7fdfffe00000
> ( 16 MB)
> [ 0.000000] vmemmap : 0xffff7fe000000000 - 0xffff800000000000
> ( 128 GB maximum)
> [ 0.000000] 0xffff7ffa25800800 - 0xffff7ffa2b800000
> ( 95 MB actual)
> [ 0.000000] memory : 0xffffe89600200000 - 0xffffe8ae00000000
> ( 98302 MB)
>
> As one can see above, the 'memblock_start_of_DRAM()' value of
> 0xffffe89600200000 represents the start of linear region:
>
> [ 0.000000] memory : 0xffffe89600200000 - 0xffffe8ae00000000
> ( 98302 MB)
>
> So, my question is to access the start of linear region (which was
> earlier determinable via PAGE_OFFSET macro), whether I should:
>
> - do some back-computation for the start of linear region from the
> 'memstart_addr' in user-space, or
> - use a new global variable in kernel which is assigned the value of
> memblock_start_of_DRAM()' and assign it to '/proc/kallsyms', so that
> it can be read by user-space tools, or
> - whether we should rather look at removing the PAGE_OFFSET usage from
> the kernel and replace it with a global variable instead which is
> properly updated for KASLR case as well.
>
> Kindly share your opinions on what can be a suitable solution in this case.
>
> Thanks for your help.
>
Hello Bhupesh,
Could you explain what the relevance is of PAGE_OFFSET to userland?
The only thing that should matter is where the actual linear mapping
of DRAM is, and I am not sure I understand why we care about where it
resides relative to the base of the linear region.
^ permalink raw reply
* [PATCHv4 1/2] ARM: imx53: add secure-reg-access support for PMU
From: Sebastian Reichel @ 2018-05-28 6:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180528022652.GA3143@dragon>
Hi,
On Mon, May 28, 2018 at 10:26:54AM +0800, Shawn Guo wrote:
> On Tue, Feb 27, 2018 at 11:17:12AM +0100, Sebastian Reichel wrote:
> > Hi,
> >
> > On Tue, Feb 27, 2018 at 09:10:34AM +0800, Shawn Guo wrote:
> > > On Mon, Feb 26, 2018 at 02:47:41PM +0100, Sebastian Reichel wrote:
> > > > On Sat, Feb 24, 2018 at 03:45:44PM +0800, Shawn Guo wrote:
> > > > > On Mon, Feb 12, 2018 at 01:39:44PM +0100, Sebastian Reichel wrote:
> > > > > > On i.MX53 it is necessary to set the DBG_EN bit in the
> > > > > > platform GPC register to enable access to PMU counters
> > > > > > other than the cycle counter.
> > > > > >
> > > > > > Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
> > > > > > ---
> > > > > > arch/arm/mach-imx/mach-imx53.c | 39 ++++++++++++++++++++++++++++++++++++++-
> > > > > > 1 file changed, 38 insertions(+), 1 deletion(-)
> > > > > >
> > > > > > diff --git a/arch/arm/mach-imx/mach-imx53.c b/arch/arm/mach-imx/mach-imx53.c
> > > > > > index 07c2e8dca494..658e28604dca 100644
> > > > > > --- a/arch/arm/mach-imx/mach-imx53.c
> > > > > > +++ b/arch/arm/mach-imx/mach-imx53.c
> > > > > > @@ -28,10 +28,47 @@ static void __init imx53_init_early(void)
> > > > > > mxc_set_cpu_type(MXC_CPU_MX53);
> > > > > > }
> > > > > >
> > > > > > +#define MXC_CORTEXA8_PLAT_GPC 0x63fa0004
> > > > >
> > > > > The base address should be retrieved from device tree.
> > > >
> > > > DT has no entry for 0x63fa0000-0x63fa3fff. iMX53 TRM lists it as "ARM Platform"
> > > > with 8 platform specific 32 bit registers. Do you think it's worth the trouble
> > > > adding a new binding? Do you have a suggestion for a compatible value?
> > >
> > > Looking at it more closely, I feel that patching every single platform
> > > which needs to set up additional register for secure-reg-access support
> > > doesn't really scale. Can we have pmu driver do it with a phandle in
> > > DT pointing to the register and bit that need to be configured?
> >
> > The PMU driver used to have a feature for initialising platform
> > specific bits, but it is currently being removed to make the PMU
> > code more maintainable. My understanding is, that it's very uncommon
> > to require platform specific setup to get secure-reg-access working.
> > I.e. it is not needed for newer iMX platforms.
>
> Are you saying this is a very specific setup required by i.MX53 only?
Yes, all other SoCs supported by Linux ARM PMU counters driver can
just use the registers without having to enable platform specific
bits first.
> In that case, I can live with it.
What about the DT node? I did not add it, since this is a i.MX53
specific workaround anyways.
-- Sebastian
-------------- 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/20180528/03b956df/attachment-0001.sig>
^ permalink raw reply
* [PATCH v4 9/9] drm/mediatek: Add support for mediatek SOC MT2712
From: Stu Hsieh @ 2018-05-28 6:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527489507-24453-1-git-send-email-stu.hsieh@mediatek.com>
This patch add support for the Mediatek MT2712 DISP subsystem.
There are two OVL engine and three disp output in MT2712.
Signed-off-by: Stu Hsieh <stu.hsieh@mediatek.com>
---
drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 39 ++++++++++++++++++++++++++++++++++
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 38 +++++++++++++++++++++++++++++++++
2 files changed, 77 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
index 8bfc0debd2c2..3b22b48a6022 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
@@ -61,6 +61,24 @@
#define MT8173_MUTEX_MOD_DISP_PWM1 24
#define MT8173_MUTEX_MOD_DISP_OD 25
+#define MT2712_MUTEX_MOD_DISP_PWM2 10
+#define MT2712_MUTEX_MOD_DISP_OVL0 11
+#define MT2712_MUTEX_MOD_DISP_OVL1 12
+#define MT2712_MUTEX_MOD_DISP_RDMA0 13
+#define MT2712_MUTEX_MOD_DISP_RDMA1 14
+#define MT2712_MUTEX_MOD_DISP_RDMA2 15
+#define MT2712_MUTEX_MOD_DISP_WDMA0 16
+#define MT2712_MUTEX_MOD_DISP_WDMA1 17
+#define MT2712_MUTEX_MOD_DISP_COLOR0 18
+#define MT2712_MUTEX_MOD_DISP_COLOR1 19
+#define MT2712_MUTEX_MOD_DISP_AAL0 20
+#define MT2712_MUTEX_MOD_DISP_UFOE 22
+#define MT2712_MUTEX_MOD_DISP_PWM0 23
+#define MT2712_MUTEX_MOD_DISP_PWM1 24
+#define MT2712_MUTEX_MOD_DISP_OD0 25
+#define MT2712_MUTEX_MOD2_DISP_AAL1 33
+#define MT2712_MUTEX_MOD2_DISP_OD1 34
+
#define MT2701_MUTEX_MOD_DISP_OVL 3
#define MT2701_MUTEX_MOD_DISP_WDMA 6
#define MT2701_MUTEX_MOD_DISP_COLOR 7
@@ -110,6 +128,26 @@ static const unsigned int mt2701_mutex_mod[DDP_COMPONENT_ID_MAX] = {
[DDP_COMPONENT_WDMA0] = MT2701_MUTEX_MOD_DISP_WDMA,
};
+static const unsigned int mt2712_mutex_mod[DDP_COMPONENT_ID_MAX] = {
+ [DDP_COMPONENT_AAL0] = MT2712_MUTEX_MOD_DISP_AAL0,
+ [DDP_COMPONENT_AAL1] = MT2712_MUTEX_MOD2_DISP_AAL1,
+ [DDP_COMPONENT_COLOR0] = MT2712_MUTEX_MOD_DISP_COLOR0,
+ [DDP_COMPONENT_COLOR1] = MT2712_MUTEX_MOD_DISP_COLOR1,
+ [DDP_COMPONENT_OD0] = MT2712_MUTEX_MOD_DISP_OD0,
+ [DDP_COMPONENT_OD1] = MT2712_MUTEX_MOD2_DISP_OD1,
+ [DDP_COMPONENT_OVL0] = MT2712_MUTEX_MOD_DISP_OVL0,
+ [DDP_COMPONENT_OVL1] = MT2712_MUTEX_MOD_DISP_OVL1,
+ [DDP_COMPONENT_PWM0] = MT2712_MUTEX_MOD_DISP_PWM0,
+ [DDP_COMPONENT_PWM1] = MT2712_MUTEX_MOD_DISP_PWM1,
+ [DDP_COMPONENT_PWM2] = MT2712_MUTEX_MOD_DISP_PWM2,
+ [DDP_COMPONENT_RDMA0] = MT2712_MUTEX_MOD_DISP_RDMA0,
+ [DDP_COMPONENT_RDMA1] = MT2712_MUTEX_MOD_DISP_RDMA1,
+ [DDP_COMPONENT_RDMA2] = MT2712_MUTEX_MOD_DISP_RDMA2,
+ [DDP_COMPONENT_UFOE] = MT2712_MUTEX_MOD_DISP_UFOE,
+ [DDP_COMPONENT_WDMA0] = MT2712_MUTEX_MOD_DISP_WDMA0,
+ [DDP_COMPONENT_WDMA1] = MT2712_MUTEX_MOD_DISP_WDMA1,
+};
+
static const unsigned int mt8173_mutex_mod[DDP_COMPONENT_ID_MAX] = {
[DDP_COMPONENT_AAL0] = MT8173_MUTEX_MOD_DISP_AAL,
[DDP_COMPONENT_COLOR0] = MT8173_MUTEX_MOD_DISP_COLOR0,
@@ -430,6 +468,7 @@ static int mtk_ddp_remove(struct platform_device *pdev)
static const struct of_device_id ddp_driver_dt_match[] = {
{ .compatible = "mediatek,mt2701-disp-mutex", .data = mt2701_mutex_mod},
+ { .compatible = "mediatek,mt2712-disp-mutex", .data = mt2712_mutex_mod},
{ .compatible = "mediatek,mt8173-disp-mutex", .data = mt8173_mutex_mod},
{},
};
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
index 3d279a299383..3a866e1d6af4 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
@@ -146,6 +146,32 @@ static const enum mtk_ddp_comp_id mt2701_mtk_ddp_ext[] = {
DDP_COMPONENT_DPI0,
};
+static const enum mtk_ddp_comp_id mt2712_mtk_ddp_main[] = {
+ DDP_COMPONENT_OVL0,
+ DDP_COMPONENT_COLOR0,
+ DDP_COMPONENT_AAL0,
+ DDP_COMPONENT_OD0,
+ DDP_COMPONENT_RDMA0,
+ DDP_COMPONENT_DPI0,
+ DDP_COMPONENT_PWM0,
+};
+
+static const enum mtk_ddp_comp_id mt2712_mtk_ddp_ext[] = {
+ DDP_COMPONENT_OVL1,
+ DDP_COMPONENT_COLOR1,
+ DDP_COMPONENT_AAL1,
+ DDP_COMPONENT_OD1,
+ DDP_COMPONENT_RDMA1,
+ DDP_COMPONENT_DPI1,
+ DDP_COMPONENT_PWM1,
+};
+
+static const enum mtk_ddp_comp_id mt2712_mtk_ddp_third[] = {
+ DDP_COMPONENT_RDMA2,
+ DDP_COMPONENT_DSI2,
+ DDP_COMPONENT_PWM2,
+};
+
static const enum mtk_ddp_comp_id mt8173_mtk_ddp_main[] = {
DDP_COMPONENT_OVL0,
DDP_COMPONENT_COLOR0,
@@ -173,6 +199,15 @@ static const struct mtk_mmsys_driver_data mt2701_mmsys_driver_data = {
.shadow_register = true,
};
+static const struct mtk_mmsys_driver_data mt2712_mmsys_driver_data = {
+ .main_path = mt2712_mtk_ddp_main,
+ .main_len = ARRAY_SIZE(mt2712_mtk_ddp_main),
+ .ext_path = mt2712_mtk_ddp_ext,
+ .ext_len = ARRAY_SIZE(mt2712_mtk_ddp_ext),
+ .third_path = mt2712_mtk_ddp_third,
+ .third_len = ARRAY_SIZE(mt2712_mtk_ddp_third),
+};
+
static const struct mtk_mmsys_driver_data mt8173_mmsys_driver_data = {
.main_path = mt8173_mtk_ddp_main,
.main_len = ARRAY_SIZE(mt8173_mtk_ddp_main),
@@ -379,6 +414,7 @@ static const struct of_device_id mtk_ddp_comp_dt_ids[] = {
{ .compatible = "mediatek,mt8173-dsi", .data = (void *)MTK_DSI },
{ .compatible = "mediatek,mt8173-dpi", .data = (void *)MTK_DPI },
{ .compatible = "mediatek,mt2701-disp-mutex", .data = (void *)MTK_DISP_MUTEX },
+ { .compatible = "mediatek,mt2712-disp-mutex", .data = (void *)MTK_DISP_MUTEX },
{ .compatible = "mediatek,mt8173-disp-mutex", .data = (void *)MTK_DISP_MUTEX },
{ .compatible = "mediatek,mt2701-disp-pwm", .data = (void *)MTK_DISP_BLS },
{ .compatible = "mediatek,mt8173-disp-pwm", .data = (void *)MTK_DISP_PWM },
@@ -557,6 +593,8 @@ static SIMPLE_DEV_PM_OPS(mtk_drm_pm_ops, mtk_drm_sys_suspend,
static const struct of_device_id mtk_drm_of_ids[] = {
{ .compatible = "mediatek,mt2701-mmsys",
.data = &mt2701_mmsys_driver_data},
+ { .compatible = "mediatek,mt2712-mmsys",
+ .data = &mt2712_mmsys_driver_data},
{ .compatible = "mediatek,mt8173-mmsys",
.data = &mt8173_mmsys_driver_data},
{ }
--
2.12.5
^ permalink raw reply related
* [PATCH v4 8/9] drm/mediatek: add third ddp path
From: Stu Hsieh @ 2018-05-28 6:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527489507-24453-1-git-send-email-stu.hsieh@mediatek.com>
This patch create third crtc by third ddp path
Signed-off-by: Stu Hsieh <stu.hsieh@mediatek.com>
---
drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 3 +++
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 5 +++++
drivers/gpu/drm/mediatek/mtk_drm_drv.h | 7 +++++--
3 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
index 658b8dd45b83..2d6aa150a9ff 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
@@ -539,6 +539,9 @@ int mtk_drm_crtc_create(struct drm_device *drm_dev,
int ret;
int i;
+ if (!path)
+ return 0;
+
for (i = 0; i < path_len; i++) {
enum mtk_ddp_comp_id comp_id = path[i];
struct device_node *node;
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
index 08d5d0b47bfe..3d279a299383 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
@@ -232,6 +232,11 @@ static int mtk_drm_kms_init(struct drm_device *drm)
if (ret < 0)
goto err_component_unbind;
+ ret = mtk_drm_crtc_create(drm, private->data->third_path,
+ private->data->third_len);
+ if (ret < 0)
+ goto err_component_unbind;
+
/* Use OVL device for all DMA memory allocations */
np = private->comp_node[private->data->main_path[0]] ?:
private->comp_node[private->data->ext_path[0]];
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.h b/drivers/gpu/drm/mediatek/mtk_drm_drv.h
index c3378c452c0a..d867e2683923 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.h
+++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.h
@@ -17,8 +17,8 @@
#include <linux/io.h>
#include "mtk_drm_ddp_comp.h"
-#define MAX_CRTC 2
-#define MAX_CONNECTOR 2
+#define MAX_CRTC 3
+#define MAX_CONNECTOR 3
struct device;
struct device_node;
@@ -33,6 +33,9 @@ struct mtk_mmsys_driver_data {
unsigned int main_len;
const enum mtk_ddp_comp_id *ext_path;
unsigned int ext_len;
+ const enum mtk_ddp_comp_id *third_path;
+ unsigned int third_len;
+
bool shadow_register;
};
--
2.12.5
^ permalink raw reply related
* [PATCH v4 7/9] drm/mediatek: add connection from OD1 to RDMA1
From: Stu Hsieh @ 2018-05-28 6:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527489507-24453-1-git-send-email-stu.hsieh@mediatek.com>
This patch add the connection from OD1 to RDMA1 for ext path.
Signed-off-by: Stu Hsieh <stu.hsieh@mediatek.com>
---
drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
index 58e44349e315..8bfc0debd2c2 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
@@ -75,6 +75,7 @@
#define OVL0_MOUT_EN_COLOR0 0x1
#define OD_MOUT_EN_RDMA0 0x1
+#define OD1_MOUT_EN_RDMA1 BIT(16)
#define UFOE_MOUT_EN_DSI0 0x1
#define COLOR0_SEL_IN_OVL0 0x1
#define OVL1_MOUT_EN_COLOR1 0x1
@@ -151,6 +152,9 @@ static unsigned int mtk_ddp_mout_en(enum mtk_ddp_comp_id cur,
} else if (cur == DDP_COMPONENT_GAMMA && next == DDP_COMPONENT_RDMA1) {
*addr = DISP_REG_CONFIG_DISP_GAMMA_MOUT_EN;
value = GAMMA_MOUT_EN_RDMA1;
+ } else if (cur == DDP_COMPONENT_OD1 && next == DDP_COMPONENT_RDMA1) {
+ *addr = DISP_REG_CONFIG_DISP_OD_MOUT_EN;
+ value = OD1_MOUT_EN_RDMA1;
} else if (cur == DDP_COMPONENT_RDMA1 && next == DDP_COMPONENT_DPI0) {
*addr = DISP_REG_CONFIG_DISP_RDMA1_MOUT_EN;
value = RDMA1_MOUT_DPI0;
--
2.12.5
^ permalink raw reply related
* [PATCH v4 6/9] drm/mediatek: add ddp component PWM2
From: Stu Hsieh @ 2018-05-28 6:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527489507-24453-1-git-send-email-stu.hsieh@mediatek.com>
This patch add component PWM2
Signed-off-by: Stu Hsieh <stu.hsieh@mediatek.com>
---
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 1 +
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
index a5c7ac2d162d..86e8c9e5df41 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
@@ -233,6 +233,7 @@ static const struct mtk_ddp_comp_match mtk_ddp_matches[DDP_COMPONENT_ID_MAX] = {
[DDP_COMPONENT_OVL1] = { MTK_DISP_OVL, 1, NULL },
[DDP_COMPONENT_PWM0] = { MTK_DISP_PWM, 0, NULL },
[DDP_COMPONENT_PWM1] = { MTK_DISP_PWM, 1, NULL },
+ [DDP_COMPONENT_PWM2] = { MTK_DISP_PWM, 2, NULL },
[DDP_COMPONENT_RDMA0] = { MTK_DISP_RDMA, 0, NULL },
[DDP_COMPONENT_RDMA1] = { MTK_DISP_RDMA, 1, NULL },
[DDP_COMPONENT_RDMA2] = { MTK_DISP_RDMA, 2, NULL },
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
index 9b19fc4423f1..e00c2e798abd 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
@@ -56,6 +56,7 @@ enum mtk_ddp_comp_id {
DDP_COMPONENT_OVL1,
DDP_COMPONENT_PWM0,
DDP_COMPONENT_PWM1,
+ DDP_COMPONENT_PWM2,
DDP_COMPONENT_RDMA0,
DDP_COMPONENT_RDMA1,
DDP_COMPONENT_RDMA2,
--
2.12.5
^ permalink raw reply related
* [PATCH v4 5/9] drm/mediatek: add ddp component PWM1
From: Stu Hsieh @ 2018-05-28 6:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527489507-24453-1-git-send-email-stu.hsieh@mediatek.com>
This patch add component PWM1 in mtk_ddp_matches
Signed-off-by: Stu Hsieh <stu.hsieh@mediatek.com>
---
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
index 87acf6be87f6..a5c7ac2d162d 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
@@ -232,6 +232,7 @@ static const struct mtk_ddp_comp_match mtk_ddp_matches[DDP_COMPONENT_ID_MAX] = {
[DDP_COMPONENT_OVL0] = { MTK_DISP_OVL, 0, NULL },
[DDP_COMPONENT_OVL1] = { MTK_DISP_OVL, 1, NULL },
[DDP_COMPONENT_PWM0] = { MTK_DISP_PWM, 0, NULL },
+ [DDP_COMPONENT_PWM1] = { MTK_DISP_PWM, 1, NULL },
[DDP_COMPONENT_RDMA0] = { MTK_DISP_RDMA, 0, NULL },
[DDP_COMPONENT_RDMA1] = { MTK_DISP_RDMA, 1, NULL },
[DDP_COMPONENT_RDMA2] = { MTK_DISP_RDMA, 2, NULL },
--
2.12.5
^ permalink raw reply related
* [PATCH v4 4/9] drm/mediatek: add ddp component OD1
From: Stu Hsieh @ 2018-05-28 6:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527489507-24453-1-git-send-email-stu.hsieh@mediatek.com>
This patch add the component OD1 and
rename the OD to OD1
Signed-off-by: Stu Hsieh <stu.hsieh@mediatek.com>
---
drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 4 ++--
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 3 ++-
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 3 ++-
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 2 +-
4 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
index 7217665f4b5d..58e44349e315 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
@@ -114,7 +114,7 @@ static const unsigned int mt8173_mutex_mod[DDP_COMPONENT_ID_MAX] = {
[DDP_COMPONENT_COLOR0] = MT8173_MUTEX_MOD_DISP_COLOR0,
[DDP_COMPONENT_COLOR1] = MT8173_MUTEX_MOD_DISP_COLOR1,
[DDP_COMPONENT_GAMMA] = MT8173_MUTEX_MOD_DISP_GAMMA,
- [DDP_COMPONENT_OD] = MT8173_MUTEX_MOD_DISP_OD,
+ [DDP_COMPONENT_OD0] = MT8173_MUTEX_MOD_DISP_OD,
[DDP_COMPONENT_OVL0] = MT8173_MUTEX_MOD_DISP_OVL0,
[DDP_COMPONENT_OVL1] = MT8173_MUTEX_MOD_DISP_OVL1,
[DDP_COMPONENT_PWM0] = MT8173_MUTEX_MOD_DISP_PWM0,
@@ -139,7 +139,7 @@ static unsigned int mtk_ddp_mout_en(enum mtk_ddp_comp_id cur,
} else if (cur == DDP_COMPONENT_OVL0 && next == DDP_COMPONENT_RDMA0) {
*addr = DISP_REG_CONFIG_DISP_OVL_MOUT_EN;
value = OVL_MOUT_EN_RDMA;
- } else if (cur == DDP_COMPONENT_OD && next == DDP_COMPONENT_RDMA0) {
+ } else if (cur == DDP_COMPONENT_OD0 && next == DDP_COMPONENT_RDMA0) {
*addr = DISP_REG_CONFIG_DISP_OD_MOUT_EN;
value = OD_MOUT_EN_RDMA0;
} else if (cur == DDP_COMPONENT_UFOE && next == DDP_COMPONENT_DSI0) {
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
index 0919039805aa..87acf6be87f6 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
@@ -227,7 +227,8 @@ static const struct mtk_ddp_comp_match mtk_ddp_matches[DDP_COMPONENT_ID_MAX] = {
[DDP_COMPONENT_DSI0] = { MTK_DSI, 0, NULL },
[DDP_COMPONENT_DSI1] = { MTK_DSI, 1, NULL },
[DDP_COMPONENT_GAMMA] = { MTK_DISP_GAMMA, 0, &ddp_gamma },
- [DDP_COMPONENT_OD] = { MTK_DISP_OD, 0, &ddp_od },
+ [DDP_COMPONENT_OD0] = { MTK_DISP_OD, 0, &ddp_od },
+ [DDP_COMPONENT_OD1] = { MTK_DISP_OD, 1, &ddp_od },
[DDP_COMPONENT_OVL0] = { MTK_DISP_OVL, 0, NULL },
[DDP_COMPONENT_OVL1] = { MTK_DISP_OVL, 1, NULL },
[DDP_COMPONENT_PWM0] = { MTK_DISP_PWM, 0, NULL },
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
index eee3c0cc2632..9b19fc4423f1 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
@@ -50,7 +50,8 @@ enum mtk_ddp_comp_id {
DDP_COMPONENT_DSI0,
DDP_COMPONENT_DSI1,
DDP_COMPONENT_GAMMA,
- DDP_COMPONENT_OD,
+ DDP_COMPONENT_OD0,
+ DDP_COMPONENT_OD1,
DDP_COMPONENT_OVL0,
DDP_COMPONENT_OVL1,
DDP_COMPONENT_PWM0,
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
index a415260f3d5f..08d5d0b47bfe 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
@@ -150,7 +150,7 @@ static const enum mtk_ddp_comp_id mt8173_mtk_ddp_main[] = {
DDP_COMPONENT_OVL0,
DDP_COMPONENT_COLOR0,
DDP_COMPONENT_AAL0,
- DDP_COMPONENT_OD,
+ DDP_COMPONENT_OD0,
DDP_COMPONENT_RDMA0,
DDP_COMPONENT_UFOE,
DDP_COMPONENT_DSI0,
--
2.12.5
^ permalink raw reply related
* [PATCH v4 3/9] drm/mediatek: add ddp component AAL1
From: Stu Hsieh @ 2018-05-28 6:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527489507-24453-1-git-send-email-stu.hsieh@mediatek.com>
This patch add component AAL1 and
rename AAL to AAL0
Signed-off-by: Stu Hsieh <stu.hsieh@mediatek.com>
---
drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 2 +-
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 3 ++-
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 3 ++-
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 2 +-
4 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
index 47ffa240bd25..7217665f4b5d 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
@@ -110,7 +110,7 @@ static const unsigned int mt2701_mutex_mod[DDP_COMPONENT_ID_MAX] = {
};
static const unsigned int mt8173_mutex_mod[DDP_COMPONENT_ID_MAX] = {
- [DDP_COMPONENT_AAL] = MT8173_MUTEX_MOD_DISP_AAL,
+ [DDP_COMPONENT_AAL0] = MT8173_MUTEX_MOD_DISP_AAL,
[DDP_COMPONENT_COLOR0] = MT8173_MUTEX_MOD_DISP_COLOR0,
[DDP_COMPONENT_COLOR1] = MT8173_MUTEX_MOD_DISP_COLOR1,
[DDP_COMPONENT_GAMMA] = MT8173_MUTEX_MOD_DISP_GAMMA,
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
index 4672317e3ad1..0919039805aa 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
@@ -218,7 +218,8 @@ struct mtk_ddp_comp_match {
};
static const struct mtk_ddp_comp_match mtk_ddp_matches[DDP_COMPONENT_ID_MAX] = {
- [DDP_COMPONENT_AAL] = { MTK_DISP_AAL, 0, &ddp_aal },
+ [DDP_COMPONENT_AAL0] = { MTK_DISP_AAL, 0, &ddp_aal },
+ [DDP_COMPONENT_AAL1] = { MTK_DISP_AAL, 1, &ddp_aal },
[DDP_COMPONENT_BLS] = { MTK_DISP_BLS, 0, NULL },
[DDP_COMPONENT_COLOR0] = { MTK_DISP_COLOR, 0, NULL },
[DDP_COMPONENT_COLOR1] = { MTK_DISP_COLOR, 1, NULL },
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
index 0828cf8bf85c..eee3c0cc2632 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
@@ -41,7 +41,8 @@ enum mtk_ddp_comp_type {
};
enum mtk_ddp_comp_id {
- DDP_COMPONENT_AAL,
+ DDP_COMPONENT_AAL0,
+ DDP_COMPONENT_AAL1,
DDP_COMPONENT_BLS,
DDP_COMPONENT_COLOR0,
DDP_COMPONENT_COLOR1,
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
index a2ca90fc403c..a415260f3d5f 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
@@ -149,7 +149,7 @@ static const enum mtk_ddp_comp_id mt2701_mtk_ddp_ext[] = {
static const enum mtk_ddp_comp_id mt8173_mtk_ddp_main[] = {
DDP_COMPONENT_OVL0,
DDP_COMPONENT_COLOR0,
- DDP_COMPONENT_AAL,
+ DDP_COMPONENT_AAL0,
DDP_COMPONENT_OD,
DDP_COMPONENT_RDMA0,
DDP_COMPONENT_UFOE,
--
2.12.5
^ permalink raw reply related
* [PATCH v4 2/9] drm/mediatek: support maximum 64 mutex mod
From: Stu Hsieh @ 2018-05-28 6:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527489507-24453-1-git-send-email-stu.hsieh@mediatek.com>
This patch support that if modules more than 32,
add index more than 31 when using DISP_REG_MUTEX_MOD2 bit
Signed-off-by: Stu Hsieh <stu.hsieh@mediatek.com>
Reviewed-by: CK Hu <ck.hu@mediatek.com>
---
drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 75 +++++++++++++++++++++-------------
1 file changed, 47 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
index 8130f3dab661..47ffa240bd25 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
@@ -41,31 +41,32 @@
#define DISP_REG_MUTEX_RST(n) (0x28 + 0x20 * (n))
#define DISP_REG_MUTEX_MOD(n) (0x2c + 0x20 * (n))
#define DISP_REG_MUTEX_SOF(n) (0x30 + 0x20 * (n))
+#define DISP_REG_MUTEX_MOD2(n) (0x34 + 0x20 * (n))
#define INT_MUTEX BIT(1)
-#define MT8173_MUTEX_MOD_DISP_OVL0 BIT(11)
-#define MT8173_MUTEX_MOD_DISP_OVL1 BIT(12)
-#define MT8173_MUTEX_MOD_DISP_RDMA0 BIT(13)
-#define MT8173_MUTEX_MOD_DISP_RDMA1 BIT(14)
-#define MT8173_MUTEX_MOD_DISP_RDMA2 BIT(15)
-#define MT8173_MUTEX_MOD_DISP_WDMA0 BIT(16)
-#define MT8173_MUTEX_MOD_DISP_WDMA1 BIT(17)
-#define MT8173_MUTEX_MOD_DISP_COLOR0 BIT(18)
-#define MT8173_MUTEX_MOD_DISP_COLOR1 BIT(19)
-#define MT8173_MUTEX_MOD_DISP_AAL BIT(20)
-#define MT8173_MUTEX_MOD_DISP_GAMMA BIT(21)
-#define MT8173_MUTEX_MOD_DISP_UFOE BIT(22)
-#define MT8173_MUTEX_MOD_DISP_PWM0 BIT(23)
-#define MT8173_MUTEX_MOD_DISP_PWM1 BIT(24)
-#define MT8173_MUTEX_MOD_DISP_OD BIT(25)
-
-#define MT2701_MUTEX_MOD_DISP_OVL BIT(3)
-#define MT2701_MUTEX_MOD_DISP_WDMA BIT(6)
-#define MT2701_MUTEX_MOD_DISP_COLOR BIT(7)
-#define MT2701_MUTEX_MOD_DISP_BLS BIT(9)
-#define MT2701_MUTEX_MOD_DISP_RDMA0 BIT(10)
-#define MT2701_MUTEX_MOD_DISP_RDMA1 BIT(12)
+#define MT8173_MUTEX_MOD_DISP_OVL0 11
+#define MT8173_MUTEX_MOD_DISP_OVL1 12
+#define MT8173_MUTEX_MOD_DISP_RDMA0 13
+#define MT8173_MUTEX_MOD_DISP_RDMA1 14
+#define MT8173_MUTEX_MOD_DISP_RDMA2 15
+#define MT8173_MUTEX_MOD_DISP_WDMA0 16
+#define MT8173_MUTEX_MOD_DISP_WDMA1 17
+#define MT8173_MUTEX_MOD_DISP_COLOR0 18
+#define MT8173_MUTEX_MOD_DISP_COLOR1 19
+#define MT8173_MUTEX_MOD_DISP_AAL 20
+#define MT8173_MUTEX_MOD_DISP_GAMMA 21
+#define MT8173_MUTEX_MOD_DISP_UFOE 22
+#define MT8173_MUTEX_MOD_DISP_PWM0 23
+#define MT8173_MUTEX_MOD_DISP_PWM1 24
+#define MT8173_MUTEX_MOD_DISP_OD 25
+
+#define MT2701_MUTEX_MOD_DISP_OVL 3
+#define MT2701_MUTEX_MOD_DISP_WDMA 6
+#define MT2701_MUTEX_MOD_DISP_COLOR 7
+#define MT2701_MUTEX_MOD_DISP_BLS 9
+#define MT2701_MUTEX_MOD_DISP_RDMA0 10
+#define MT2701_MUTEX_MOD_DISP_RDMA1 12
#define MUTEX_SOF_SINGLE_MODE 0
#define MUTEX_SOF_DSI0 1
@@ -278,6 +279,7 @@ void mtk_disp_mutex_add_comp(struct mtk_disp_mutex *mutex,
struct mtk_ddp *ddp = container_of(mutex, struct mtk_ddp,
mutex[mutex->id]);
unsigned int reg;
+ unsigned int offset;
WARN_ON(&ddp->mutex[mutex->id] != mutex);
@@ -292,9 +294,17 @@ void mtk_disp_mutex_add_comp(struct mtk_disp_mutex *mutex,
reg = MUTEX_SOF_DPI0;
break;
default:
- reg = readl_relaxed(ddp->regs + DISP_REG_MUTEX_MOD(mutex->id));
- reg |= ddp->mutex_mod[id];
- writel_relaxed(reg, ddp->regs + DISP_REG_MUTEX_MOD(mutex->id));
+ if (ddp->mutex_mod[id] < 32) {
+ offset = DISP_REG_MUTEX_MOD(mutex->id);
+ reg = readl_relaxed(ddp->regs + offset);
+ reg |= 1 << ddp->mutex_mod[id];
+ writel_relaxed(reg, ddp->regs + offset);
+ } else {
+ offset = DISP_REG_MUTEX_MOD2(mutex->id);
+ reg = readl_relaxed(ddp->regs + offset);
+ reg |= 1 << (ddp->mutex_mod[id] - 32);
+ writel_relaxed(reg, ddp->regs + offset);
+ }
return;
}
@@ -307,6 +317,7 @@ void mtk_disp_mutex_remove_comp(struct mtk_disp_mutex *mutex,
struct mtk_ddp *ddp = container_of(mutex, struct mtk_ddp,
mutex[mutex->id]);
unsigned int reg;
+ unsigned int offset;
WARN_ON(&ddp->mutex[mutex->id] != mutex);
@@ -318,9 +329,17 @@ void mtk_disp_mutex_remove_comp(struct mtk_disp_mutex *mutex,
ddp->regs + DISP_REG_MUTEX_SOF(mutex->id));
break;
default:
- reg = readl_relaxed(ddp->regs + DISP_REG_MUTEX_MOD(mutex->id));
- reg &= ~(ddp->mutex_mod[id]);
- writel_relaxed(reg, ddp->regs + DISP_REG_MUTEX_MOD(mutex->id));
+ if (ddp->mutex_mod[id] < 32) {
+ offset = DISP_REG_MUTEX_MOD(mutex->id);
+ reg = readl_relaxed(ddp->regs + offset);
+ reg &= ~(1 << ddp->mutex_mod[id]);
+ writel_relaxed(reg, ddp->regs + offset);
+ } else {
+ offset = DISP_REG_MUTEX_MOD2(mutex->id);
+ reg = readl_relaxed(ddp->regs + offset);
+ reg &= ~(1 << (ddp->mutex_mod[id] - 32));
+ writel_relaxed(reg, ddp->regs + offset);
+ }
break;
}
}
--
2.12.5
^ permalink raw reply related
* [PATCH v4 1/9] drm/mediatek: update dt-bindings for mt2712
From: Stu Hsieh @ 2018-05-28 6:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527489507-24453-1-git-send-email-stu.hsieh@mediatek.com>
Update device tree binding documentation for the display subsystem for
Mediatek MT2712 SoCs.
Signed-off-by: Stu Hsieh <stu.hsieh@mediatek.com>
Acked-by: CK Hu <ck.hu@mediatek.com>
---
Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt b/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
index 383183a89164..8469de510001 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
@@ -40,7 +40,7 @@ Required properties (all function blocks):
"mediatek,<chip>-dpi" - DPI controller, see mediatek,dpi.txt
"mediatek,<chip>-disp-mutex" - display mutex
"mediatek,<chip>-disp-od" - overdrive
- the supported chips are mt2701 and mt8173.
+ the supported chips are mt2701, mt2712 and mt8173.
- reg: Physical base address and length of the function block register space
- interrupts: The interrupt signal from the function block (required, except for
merge and split function blocks).
--
2.12.5
^ permalink raw reply related
* [PATCH v4 0/9] Add support for mediatek SOC MT2712
From: Stu Hsieh @ 2018-05-28 6:38 UTC (permalink / raw)
To: linux-arm-kernel
This patch add support for the Mediatek MT2712 DISP subsystem.
MT2712 is base on MT8173, there are some difference as following:
MT2712 support three disp output(two ovl and one rdma)
Change in v4:
- Move some modification about AAL1 from patch
"Add support for mediatek SOC MT2712" to
"add ddp component AAL1"
- Move some modification about OD1 from patch
"Add support for mediatek SOC MT2712" to
"add ddp component OD1"
- Move some modification about PWM2 from patch
"Add support for mediatek SOC MT2712" to
"add ddp component PWM2"
- Move some modification about third ddp path from patch
"Add support for mediatek SOC MT2712" to
"add third ddp path"
- Move the definition OD1_MOUT_EN_RDMA1 from patch
"Add support for mediatek SOC MT2712" to
"add connection from OD1 to RDMA1"
- Rebase the patch "add connection from OD1 to RDMA1" after
"add ddp component OD1"
- Rebase the patch "add third ddp path" before
"Add support for mediatek SOC MT2712"
- Modify the 2712 MUTEX MODULE in the order by index
- Added patch for ddp component PWM1
- For patch "add third ddp path"
Add the condition in mtk_crtc_create() that if there
is no ddp path, then return 0 to avoid the null crtc
Change in v3:
- Added patch for ddp component AAL1
- Added patch for ddp component OD1
- Added patch for ddp component PWM2
- Added patch to create third ddp path
- Rebase patch "support maximum 64 mutex mod" before
"Add support for mediatek SOC MT2712"
- Rebase patch "add connection from OD1 to RDMA1" before
"Add support for mediatek SOC MT2712"
- Remove two definition about RDMA0 and RDMA2
- Change the definition about mutex module from
bitwise to index
Changes in v2:
- update dt-bindings for mt2712
- Added patch to connection from OD1 to RDMA1
- Added patch to support maximum 64 mutex mod
- rewrite mutex mod condition for reducing one byte
- Change the component name AAL/OD to AAL0/OD0 for naming consistency
- Move the compatible information about dpi to other patch which modify
the dpi driver for mt2712
Stu Hsieh (9):
drm/mediatek: update dt-bindings for mt2712
drm/mediatek: support maximum 64 mutex mod
drm/mediatek: add ddp component AAL1
drm/mediatek: add ddp component OD1
drm/mediatek: add ddp component PWM1
drm/mediatek: add ddp component PWM2
drm/mediatek: add connection from OD1 to RDMA1
drm/mediatek: add third ddp path
drm/mediatek: Add support for mediatek SOC MT2712
.../bindings/display/mediatek/mediatek,disp.txt | 2 +-
drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 3 +
drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 124 +++++++++++++++------
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 8 +-
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 7 +-
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 47 +++++++-
drivers/gpu/drm/mediatek/mtk_drm_drv.h | 7 +-
7 files changed, 158 insertions(+), 40 deletions(-)
--
2.12.5
^ permalink raw reply
* [Query] PAGE_OFFSET on KASLR enabled ARM64 kernel
From: Baoquan He @ 2018-05-28 3:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180528021609.GA31261@MiWiFi-R3L-srv>
On 05/28/18 at 10:16am, Baoquan He wrote:
> On 05/28/18 at 02:33am, Bhupesh Sharma wrote:
> > Hi ARM64 maintainers,
> >
> > I am confused about the PAGE_OFFSET value (or the start of the linear
> > map) on a KASLR enabled ARM64 kernel that I am seeing on a board which
> > supports a compatible EFI firmware (with EFI_RNG_PROTOCOL support).
> >
> > 1. 'arch/arm64/include/asm/memory.h' defines PAGE_OFFSET as:
> >
> > /*
> > * PAGE_OFFSET - the virtual address of the start of the linear map (top
> > * (VA_BITS - 1))
> > */
> > #define PAGE_OFFSET (UL(0xffffffffffffffff) - \
> > (UL(1) << (VA_BITS - 1)) + 1)
> >
> > So for example on a platform with VA_BITS=48, we have:
> > PAGE_OFFSET = 0xffff800000000000
> >
> > 2. However, for the KASLR case, we set the 'memstart_offset_seed ' to
> > use the 16-bits of the 'kaslr-seed' to randomize the linear region in
> > 'arch/arm64/kernel/kaslr.c' :
> >
> > u64 __init kaslr_early_init(u64 dt_phys)
> > {
> > <snip..>
> > /* use the top 16 bits to randomize the linear region */
> > memstart_offset_seed = seed >> 48;
> > <snip..>
> > }
> >
> > 3. Now, we use the 'memstart_offset_seed' value to randomize the
> > 'memstart_addr' value in 'arch/arm64/mm/init.c':
> >
> > void __init arm64_memblock_init(void)
> > {
> > <snip..>
> >
> > if (IS_ENABLED(CONFIG_RANDOMIZE_BASE)) {
> > extern u16 memstart_offset_seed;
> > u64 range = linear_region_size -
> > (memblock_end_of_DRAM() - memblock_start_of_DRAM());
> >
> > /*
> > * If the size of the linear region exceeds, by a sufficient
> > * margin, the size of the region that the available physical
> > * memory spans, randomize the linear region as well.
> > */
> > if (memstart_offset_seed > 0 && range >= ARM64_MEMSTART_ALIGN) {
> > range = range / ARM64_MEMSTART_ALIGN + 1;
> > memstart_addr -= ARM64_MEMSTART_ALIGN *
> > ((range * memstart_offset_seed) >> 16);
> > }
> > }
> > <snip..>
> > }
> >
> > 4. Since 'memstart_addr' indicates the start of physical RAM, we
> > randomize the same on basis of 'memstart_offset_seed' value above.
> > Also the 'memstart_addr' value is available in '/proc/kallsyms' and
> > hence can be accessed by user-space applications to read the
> > 'memstart_addr' value.
> >
> > 5. Now since the PAGE_OFFSET value is also used by several user space
> > tools (for e.g. makedumpfile tool uses the same to determine the start
> > of linear region and hence to read PT_NOTE fields from /proc/kcore), I
> > am not sure how to read the randomized value of the same in the KASLR
> > enabled case.
> >
> > 6. Reading the code further and adding some debug prints, it seems the
> > 'memblock_start_of_DRAM()' value is more closer to the actual start of
> > linear region rather than 'memstart_addr' and 'PAGE_OFFSET" in case of
> > KASLR enabled kernel:
>
>
> Can you paste your complete dmesg or boot log? Here I guess it only
> means the virtual address of memblock_start_of_DRAM, not its value.
Oh, it's an offset value, I was mistaken.
>
> VA_START == 0Xffff000000000000
> PAGE_OFFSET == 0xffff800000000000
> >
> > [root at qualcomm-amberwing] # dmesg | grep -i "arm64_memblock_init" -A 5
> >
> > [ 0.000000] inside arm64_memblock_init, memstart_addr = ffff976a00000000,
> > linearstart_addr = ffffe89600200000, memblock_start_of_DRAM = ffffe89600200000,
> > PHYS_OFFSET = ffff976a00000000, PAGE_OFFSET = ffff800000000000,
> > KIMAGE_VADDR = ffff000008000000, kimage_vaddr = ffff20c2d7800000
> >
> > [root at qualcomm-amberwing] # dmesg | grep -i "Virtual kernel memory layout" -A 15
> > [ 0.000000] Virtual kernel memory layout:
> > [ 0.000000] modules : 0xffff000000000000 - 0xffff000008000000
> > ( 128 MB)
> > [ 0.000000] vmalloc : 0xffff000008000000 - 0xffff7bdfffff0000
> > (126847 GB)
> > [ 0.000000] .text : 0xffff20c2d7880000 - 0xffff20c2d8040000
> > ( 7936 KB)
> > [ 0.000000] .rodata : 0xffff20c2d8040000 - 0xffff20c2d83a0000
> > ( 3456 KB)
> > [ 0.000000] .init : 0xffff20c2d83a0000 - 0xffff20c2d8750000
> > ( 3776 KB)
> > [ 0.000000] .data : 0xffff20c2d8750000 - 0xffff20c2d891b200
> > ( 1837 KB)
> > [ 0.000000] .bss : 0xffff20c2d891b200 - 0xffff20c2d90a5198
> > ( 7720 KB)
> > [ 0.000000] fixed : 0xffff7fdffe790000 - 0xffff7fdffec00000
> > ( 4544 KB)
> > [ 0.000000] PCI I/O : 0xffff7fdffee00000 - 0xffff7fdfffe00000
> > ( 16 MB)
> > [ 0.000000] vmemmap : 0xffff7fe000000000 - 0xffff800000000000
> > ( 128 GB maximum)
> > [ 0.000000] 0xffff7ffa25800800 - 0xffff7ffa2b800000
> > ( 95 MB actual)
> > [ 0.000000] memory : 0xffffe89600200000 - 0xffffe8ae00000000
> > ( 98302 MB)
> >
> > As one can see above, the 'memblock_start_of_DRAM()' value of
> > 0xffffe89600200000 represents the start of linear region:
> >
> > [ 0.000000] memory : 0xffffe89600200000 - 0xffffe8ae00000000
> > ( 98302 MB)
> >
> > So, my question is to access the start of linear region (which was
> > earlier determinable via PAGE_OFFSET macro), whether I should:
> >
> > - do some back-computation for the start of linear region from the
> > 'memstart_addr' in user-space, or
> > - use a new global variable in kernel which is assigned the value of
> > memblock_start_of_DRAM()' and assign it to '/proc/kallsyms', so that
> > it can be read by user-space tools, or
> > - whether we should rather look at removing the PAGE_OFFSET usage from
> > the kernel and replace it with a global variable instead which is
> > properly updated for KASLR case as well.
> >
> > Kindly share your opinions on what can be a suitable solution in this case.
> >
> > Thanks for your help.
> >
> > Regards,
> > Bhupesh
> >
> > _______________________________________________
> > kexec mailing list
> > kexec at lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/kexec
>
> _______________________________________________
> kexec mailing list
> kexec at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply
* [PATCH v2 2/5] gpio: syscon: Add gpio-syscon for rockchip
From: Levin @ 2018-05-28 3:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2373122.g04ZbCo5Dh@phil>
On 2018-05-24 8:18 PM, Heiko Stuebner wrote:
> Hi Levin,
>
> Am Donnerstag, 24. Mai 2018, 03:59:36 CEST schrieb Levin Du:
>> Hi all, I'd like to quote reply of Robin Murphy at
>> http://lists.infradead.org/pipermail/linux-rockchip/2018-May/020619.html
>>
>>> I would suggest s/pin number/bit number in the associated GRF register/
>>> here. At least in this RK3328 case there's only one pin, which isn't
>>> numbered, and if you naively considered it pin 0 of this 'bank' you'd
>>> already have the wrong number. Since we're dealing with the "random
>>> SoC-specific controls" region of the GRF as opposed to the
>>> relatively-consistent and organised pinmux parts, I don't think we
>>> should rely on any assumptions about how things are laid out.
>>>
>>> I was initially going to suggest a more specific compatible string as
>>> well, but on reflection I think the generic "rockchip,gpio-syscon" for
>>> basic "flip this single GRF bit" functionality actually is the right way
>>> to go. In the specific RK3328 GPIO_MUTE case, there look to be 4 bits in
>>> total related to this pin - the enable, value, and some pull controls
>>> (which I assume apply when the output is disabled) - if at some point in
>>> future we *did* want to start explicitly controlling the rest of them
>>> too, then would be a good time to define a separate
>>> "rockchip,rk3328-gpio-mute" binding (and probably a dedicated driver)
>>> for that specialised functionality, independently of this basic one.
>>
>> Shall we go the generic "rockchip,gpio-syscon" way, or the specific
>> "rockchip,rk3328-gpio-mute" way? I prefer the former one.
>>
>> The property of "gpio,syscon-dev" in gpio-syscon driver should be
>> documented.
>> Since the gpio controller is defined in the dtsi file, which inevitably
>> contains voodoo
>> register addresses. But at the board level dts file, there won't be more
>> register
>> addresses.
> Past experience shows that the GRF is not really suitable for
> generalization, as it's more of a dumping ground where chip designers
> can put everything that's left over. This is especially true for
> GRF_SOC_CONx registers, that really only contain pretty random bits.
>
> So personally, I'd really prefer soc-specific compatibles as everywhere
> else, instead of trying to push stuff into the devicetree that won't hold
> up on future socs.
>
>
>> On 2018-05-24 3:53 AM, Rob Herring wrote:
>>> On Wed, May 23, 2018 at 10:12 AM, Heiko St?bner <heiko@sntech.de> wrote:
>>>> Hi Rob, Levin,
>>>>
>>>> sorry for being late to the party.
>>>>
>>>> Am Mittwoch, 23. Mai 2018, 16:43:07 CEST schrieb Rob Herring:
>>>>> On Tue, May 22, 2018 at 9:02 PM, Levin Du <djw@t-chip.com.cn> wrote:
>>>>>> On 2018-05-23 2:02 AM, Rob Herring wrote:
>>>>>>> On Fri, May 18, 2018 at 11:52:05AM +0800, djw at t-chip.com.cn wrote:
>>>>>>>> From: Levin Du <djw@t-chip.com.cn>
>>>>>>>>
>>>>>>>> Some GPIOs sit in the GRF_SOC_CON registers of Rockchip SoCs,
>>>>>>>> which do not belong to the general pinctrl.
>>>>>>>>
>>>>>>>> Adding gpio-syscon support makes controlling regulator or
>>>>>>>> LED using these special pins very easy by reusing existing
>>>>>>>> drivers, such as gpio-regulator and led-gpio.
>>>>>>>>
>>>>>>>> Signed-off-by: Levin Du <djw@t-chip.com.cn>
>>>>>>>>
>>>>>>>> ---
>>>>>>>>
>>>>>>>> Changes in v2:
>>>>>>>> - Rename gpio_syscon10 to gpio_mute in doc
>>>>>>>>
>>>>>>>> Changes in v1:
>>>>>>>> - Refactured for general gpio-syscon usage for Rockchip SoCs.
>>>>>>>> - Add doc rockchip,gpio-syscon.txt
>>>>>>>>
>>>>>>>> .../bindings/gpio/rockchip,gpio-syscon.txt | 41
>>>>>>>>
>>>>>>>> ++++++++++++++++++++++
>>>>>>>>
>>>>>>>> drivers/gpio/gpio-syscon.c | 30
>>>>>>>>
>>>>>>>> ++++++++++++++++
>>>>>>>>
>>>>>>>> 2 files changed, 71 insertions(+)
>>>>>>>> create mode 100644
>>>>>>>>
>>>>>>>> Documentation/devicetree/bindings/gpio/rockchip,gpio-syscon.txt
>>>>>>>>
>>>>>>>> diff --git
>>>>>>>> a/Documentation/devicetree/bindings/gpio/rockchip,gpio-syscon.txt
>>>>>>>> b/Documentation/devicetree/bindings/gpio/rockchip,gpio-syscon.txt
>>>>>>>> new file mode 100644
>>>>>>>> index 0000000..b1b2a67
>>>>>>>> --- /dev/null
>>>>>>>> +++ b/Documentation/devicetree/bindings/gpio/rockchip,gpio-syscon.txt
>>>>>>>> @@ -0,0 +1,41 @@
>>>>>>>> +* Rockchip GPIO support for GRF_SOC_CON registers
>>>>>>>> +
>>>>>>>> +Required properties:
>>>>>>>> +- compatible: Should contain "rockchip,gpio-syscon".
>>>>>>>> +- gpio-controller: Marks the device node as a gpio controller.
>>>>>>>> +- #gpio-cells: Should be two. The first cell is the pin number and
>>>>>>>> + the second cell is used to specify the gpio polarity:
>>>>>>>> + 0 = Active high,
>>>>>>>> + 1 = Active low.
>>>>>>> There's no need for this child node. Just make the parent node a gpio
>>>>>>> controller.
>>>>>>>
>>>>>>> Rob
>>>>>> Hi Rob, it is not clear to me. Do you suggest that the grf node should be
>>>>>> a
>>>>>> gpio controller,
>>>>>> like below?
>>>>>>
>>>>>> + grf: syscon at ff100000 {
>>>>>> + compatible = "rockchip,gpio-syscon", "rockchip,rk3328-grf",
>>>>>> "syscon", "simple-mfd";
>>>>> Yes, but drop "rockchip,gpio-syscon" and "simple-mfd".
>>>> I would disagree quite a bit here. The grf are the "general register files",
>>>> a bunch of registers used for quite a lot of things, and so it seems
>>>> among other users, also a gpio-controller for some more random pins
>>>> not controlled through the regular gpio controllers.
>>>>
>>>> For a more fully stocked grf, please see
>>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/rk3288.dtsi#n855
>>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/boot/dts/rockchip/rk3399.dtsi#n1338
>>>>
>>>> So the gpio controller should definitly also be a subnode.
>>> Sigh, yes, if there are a bunch of functions needing subnodes like the
>>> above, then yes that makes sense. But that's not what has been
>>> presented. Please make some attempt at defining *all* the functions.
>>> An actual binding would be nice, but I'll settle for just a list of
>>> things. The list should have functions that have DT dependencies (like
>>> clocks for phys in the above) because until you do, you don't need
>>> child nodes.
>> In rk3328.dtsi file, there are lots of line "rockchip,grf = <&grf>;" in
>> various nodes,
>> such as tsadc, cru, gmac2io, gmac2phy, and also pinctrl, which are not
>> sub nodes of
>> `grf`, but for reference only. The gpio-syscon node should also have
>> similar behavior.
>> They are not strongly coupled. The gpio-syscon node should be defined
>> outside of the
>> `grf` node.
> Not necessarily.
>
> I.e. things like the tsadc, cru etc have their own register space and only
> some minor additional bits inside the GRF.
>
> Other things like some phys and your mute-gpio are _fully embedded_ inside
> the GRF and thus become child devices. This describes the hardware layout
> way better, helps unclutter the devicetree and also shows this distinction
> between "additional bits" and "embedded" clearly.
>
>
> Heiko
Your good point convinced me. I'd like to discuss the V3 patch here.
Since there's only one GPIO pin (the GPIO_MUTE pin) in GRF_SOC_CON10
register,
the GPIO controller is named `gpio-mute` and has only one GPIO pin which is
referred to as `<&gpio-mute 0>`:
In rk3328.dtsi:
??? grf: syscon at ff100000 {
??????? //...
??? ??? /* The GPIO_MUTE pin is referred to as <&gpio-mute 0>.*/
??? ??? gpio_mute: gpio-mute {
??? ??? ??? compatible = "rockchip,rk3328-mute-gpio";
??? ??? ??? gpio-controller;
??? ??? ??? #gpio-cells = <2>;
??? ??? };
??? };
In gpio-syscon.c:
? static const struct syscon_gpio_data rockchip_rk3328_mute_gpio = {
? ? ???? /* rk3328 mute gpio is an output only pin at GRF_SOC_CON10[1] */
??????? .flags????????? = GPIO_SYSCON_FEAT_OUT,
??????? .bit_count????? = 1,
??????? .dat_bit_offset = 0x0428 * 8 + 1,
??????? .set??????????? = rockchip_gpio_set,
? };
? static const struct of_device_id syscon_gpio_ids[] = {
??? //...
??? {
??? ??? .compatible??? = "rockchip,rk3328-mute-gpio",
??? ??? .data??? ??? = &rockchip_rk3328_mute_gpio,
??? },
??? {}
? };
Compared to V0 patch, the bit_count changes from 2 to 1 and the
dat_bit_offset
increases 1. Therefore the GPIO_MUTE pin is now referred to as
`<&gpio-mute 0>`. IMHO it is better than `<&gpio-mute 1>` in the V0 patch.
In V0, `1` is the physical offset of the output pin in register and
<&gpio-mute 0>
is an invalid GPIO.
Thanks
Levin
^ permalink raw reply
* [PATCH 1/3] arm64:add missing CONFIG_STRICT_KERNEL_RWX for mark_rodata_ro
From: nixiaoming @ 2018-05-28 3:33 UTC (permalink / raw)
To: linux-arm-kernel
Signed-off-by: nixiaoming <nixiaoming@huawei.com>
---
arch/arm64/mm/mmu.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index 2dbb2c9..849f326 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -491,6 +491,7 @@ static void __init map_mem(pgd_t *pgdp)
#endif
}
+#ifdef CONFIG_STRICT_KERNEL_RWX
void mark_rodata_ro(void)
{
unsigned long section_size;
@@ -505,6 +506,7 @@ void mark_rodata_ro(void)
debug_checkwx();
}
+#endif
static void __init map_kernel_segment(pgd_t *pgdp, void *va_start, void *va_end,
pgprot_t prot, struct vm_struct *vma,
--
2.10.1
^ permalink raw reply related
* [GIT PULL] berlin core changes for 4.18
From: Jisheng Zhang @ 2018-05-28 3:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180525215159.xo7tgssmoep73oct@localhost>
On Fri, 25 May 2018 14:51:59 -0700 Olof Johansson wrote:
> Hi,
>
> On Thu, May 24, 2018 at 03:59:44PM +0800, Jisheng Zhang wrote:
> > Hi
> >
> > Here is our mach-berlin changes for v4.18.
> >
> > Thanks,
> > Jisheng
> >
> > The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:
> >
> > Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)
> >
> > are available in the Git repository at:
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/jszhang/linux-berlin.git tags/berlin-core-for-v4.18
> >
> > for you to fetch changes up to eb14767c8a9117fdd84fc79e6263c85a4d8ec934:
> >
> > ARM: berlin: switch to SPDX license identifier (2018-05-24 14:49:09 +0800)
> >
> > ----------------------------------------------------------------
> > berlin core changes for v4.18
> >
> > BG2CD SoC uses r3p0 Cortex-A9 MPCore single-CPU cluster. Autoselect
> > pertinent errata, the SCU and the global timer, and allow use of the
> > local timer on uniprocessor kernels.
> >
> > remove non-necessary flush_cache_all() after scu_enable().
> >
> > switch to SPDX license identifier for all files under mach-berlin/
> >
> > ----------------------------------------------------------------
> > Alexander Monakov (1):
> > ARM: berlin: extend BG2CD Kconfig entry
> >
> > Jisheng Zhang (2):
> > arm: berlin: remove non-necessary flush_cache_all()
> > ARM: berlin: switch to SPDX license identifier
>
> Merged, thanks!
>
> Watch out for consistency on the patch subjects, please.
>
> Also, you're cutting it a bit close w.r.t. merge window opening. If you can get
> your pull requests in before -rc6 you run less risk of missing it if there's
> a problem with it that needs a respin.
Got it. Thanks for the kind remind.
^ permalink raw reply
* [PATCH] perf tools: Fix indexing for decoder packet queue
From: Leo Yan @ 2018-05-28 3:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527289854-10755-1-git-send-email-mathieu.poirier@linaro.org>
On Fri, May 25, 2018 at 05:10:54PM -0600, Mathieu Poirier wrote:
> The tail of a queue is supposed to be pointing to the next available slot
> in a queue. In this implementation the tail is incremented before it is
> used and as such points to the last used element, something that has the
> immense advantage of centralizing tail management at a single location
> and eliminating a lot of redundant code.
>
> But this needs to be taken into consideration on the dequeueing side where
> the head also needs to be incremented before it is used, or the first
> available element of the queue will be skipped.
>
> Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
> ---
> tools/perf/util/cs-etm-decoder/cs-etm-decoder.c | 12 ++++++++++--
> 1 file changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c b/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c
> index c8b98fa22997..4d5fc374e730 100644
> --- a/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c
> +++ b/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c
> @@ -96,11 +96,19 @@ int cs_etm_decoder__get_packet(struct cs_etm_decoder *decoder,
> /* Nothing to do, might as well just return */
> if (decoder->packet_count == 0)
> return 0;
> + /*
> + * The queueing process in function cs_etm_decoder__buffer_packet()
> + * increments the tail *before* using it. This is somewhat counter
> + * intuitive but it has the advantage of centralizing tail management
> + * at a single location. Because of that we need to follow the same
> + * heuristic with the head, i.e we increment it before using its
> + * value. Otherwise the first element of the packet queue is not
> + * used.
> + */
> + decoder->head = (decoder->head + 1) & (MAX_BUFFER - 1);
>
> *packet = decoder->packet_buffer[decoder->head];
>
> - decoder->head = (decoder->head + 1) & (MAX_BUFFER - 1);
> -
I tested this patch and confirmed it can work well with python
decoding script:
Tested-by: Leo Yan <leo.yan@linaro.org>
Actually, I have another idea for this fixing, seems to me
the unchanged code has right logic for decoder->head, and I think this
issue is more related with incorrect initialization index. So we can
change the initialization index for decoder->head as below. How about
you think for this?
diff --git a/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c
b/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c
index c8b98fa..b133260 100644
--- a/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c
+++ b/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c
@@ -249,7 +249,7 @@ static void cs_etm_decoder__clear_buffer(struct
cs_etm_decoder *decoder)
{
int i;
- decoder->head = 0;
+ decoder->head = 1;
decoder->tail = 0;
decoder->packet_count = 0;
for (i = 0; i < MAX_BUFFER; i++) {
Thanks,
Leo Yan
> decoder->packet_count--;
>
> return 1;
> --
> 2.7.4
>
^ permalink raw reply related
* [PATCH v3 8/8] drm/mediatek: add third ddp path
From: CK Hu @ 2018-05-28 2:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527474417.11190.21.camel@mtksdccf07>
Hi, Stu:
On Mon, 2018-05-28 at 10:26 +0800, Stu Hsieh wrote:
> Hi, CK:
> I've some idea as below.
>
> On Fri, 2018-05-25 at 13:00 +0800, CK Hu wrote:
> > Hi, Stu:
> >
> > On Fri, 2018-05-25 at 10:34 +0800, stu.hsieh at mediatek.com wrote:
> > > From: Stu Hsieh <stu.hsieh@mediatek.com>
> > >
> > > This patch create third crtc by third ddp path
> > >
> >
> > Apply this patch before the patch 'Add support for mediatek SOC MT2712'
> > because this patch is necessary for mt2712.
> >
> > > Signed-off-by: Stu Hsieh <stu.hsieh@mediatek.com>
> > > ---
> > > drivers/gpu/drm/mediatek/mtk_drm_drv.c | 5 +++++
> > > 1 file changed, 5 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> > > index b32c4cc8d051..3a866e1d6af4 100644
> > > --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> > > +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> > > @@ -267,6 +267,11 @@ static int mtk_drm_kms_init(struct drm_device *drm)
> > > if (ret < 0)
> > > goto err_component_unbind;
> > >
> > > + ret = mtk_drm_crtc_create(drm, private->data->third_path,
> > > + private->data->third_len);
> >
> > I think you should prevent doing this for mt8173 and mt2701 because that
> > two SoC has only two ddp path.
>
> Now, 8173 and 2701 have only two ddp path, there is a problem on run
> time.
> There are three crtc for drm resource, and there is nothing in third
> crtc.
> Because 8173 and 2701 have no third ddp, and the third ddp_len is zero.
> So, I want to add the condition like following in mtk_crtc_create()
> if (path_len == 0)
> return 0;
>
> Then, the valur ret is zero and it would not create the null third crtc.
This sounds good to me.
Regards,
CK
>
>
> Regards,
> Stu
>
> >
> > Regards,
> > CK
> >
> > > + if (ret < 0)
> > > + goto err_component_unbind;
> > > +
> > > /* Use OVL device for all DMA memory allocations */
> > > np = private->comp_node[private->data->main_path[0]] ?:
> > > private->comp_node[private->data->ext_path[0]];
> >
> >
>
>
^ permalink raw reply
* [PATCH v3 8/8] drm/mediatek: add third ddp path
From: Stu Hsieh @ 2018-05-28 2:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527224425.27165.27.camel@mtksdaap41>
Hi, CK:
I've some idea as below.
On Fri, 2018-05-25 at 13:00 +0800, CK Hu wrote:
> Hi, Stu:
>
> On Fri, 2018-05-25 at 10:34 +0800, stu.hsieh at mediatek.com wrote:
> > From: Stu Hsieh <stu.hsieh@mediatek.com>
> >
> > This patch create third crtc by third ddp path
> >
>
> Apply this patch before the patch 'Add support for mediatek SOC MT2712'
> because this patch is necessary for mt2712.
>
> > Signed-off-by: Stu Hsieh <stu.hsieh@mediatek.com>
> > ---
> > drivers/gpu/drm/mediatek/mtk_drm_drv.c | 5 +++++
> > 1 file changed, 5 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> > index b32c4cc8d051..3a866e1d6af4 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> > @@ -267,6 +267,11 @@ static int mtk_drm_kms_init(struct drm_device *drm)
> > if (ret < 0)
> > goto err_component_unbind;
> >
> > + ret = mtk_drm_crtc_create(drm, private->data->third_path,
> > + private->data->third_len);
>
> I think you should prevent doing this for mt8173 and mt2701 because that
> two SoC has only two ddp path.
Now, 8173 and 2701 have only two ddp path, there is a problem on run
time.
There are three crtc for drm resource, and there is nothing in third
crtc.
Because 8173 and 2701 have no third ddp, and the third ddp_len is zero.
So, I want to add the condition like following in mtk_crtc_create()
if (path_len == 0)
return 0;
Then, the valur ret is zero and it would not create the null third crtc.
Regards,
Stu
>
> Regards,
> CK
>
> > + if (ret < 0)
> > + goto err_component_unbind;
> > +
> > /* Use OVL device for all DMA memory allocations */
> > np = private->comp_node[private->data->main_path[0]] ?:
> > private->comp_node[private->data->ext_path[0]];
>
>
^ permalink raw reply
* [PATCHv4 1/2] ARM: imx53: add secure-reg-access support for PMU
From: Shawn Guo @ 2018-05-28 2:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180227101712.3zwobvs4ox4jchcj@earth.universe>
On Tue, Feb 27, 2018 at 11:17:12AM +0100, Sebastian Reichel wrote:
> Hi,
>
> On Tue, Feb 27, 2018 at 09:10:34AM +0800, Shawn Guo wrote:
> > On Mon, Feb 26, 2018 at 02:47:41PM +0100, Sebastian Reichel wrote:
> > > On Sat, Feb 24, 2018 at 03:45:44PM +0800, Shawn Guo wrote:
> > > > On Mon, Feb 12, 2018 at 01:39:44PM +0100, Sebastian Reichel wrote:
> > > > > On i.MX53 it is necessary to set the DBG_EN bit in the
> > > > > platform GPC register to enable access to PMU counters
> > > > > other than the cycle counter.
> > > > >
> > > > > Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
> > > > > ---
> > > > > arch/arm/mach-imx/mach-imx53.c | 39 ++++++++++++++++++++++++++++++++++++++-
> > > > > 1 file changed, 38 insertions(+), 1 deletion(-)
> > > > >
> > > > > diff --git a/arch/arm/mach-imx/mach-imx53.c b/arch/arm/mach-imx/mach-imx53.c
> > > > > index 07c2e8dca494..658e28604dca 100644
> > > > > --- a/arch/arm/mach-imx/mach-imx53.c
> > > > > +++ b/arch/arm/mach-imx/mach-imx53.c
> > > > > @@ -28,10 +28,47 @@ static void __init imx53_init_early(void)
> > > > > mxc_set_cpu_type(MXC_CPU_MX53);
> > > > > }
> > > > >
> > > > > +#define MXC_CORTEXA8_PLAT_GPC 0x63fa0004
> > > >
> > > > The base address should be retrieved from device tree.
> > >
> > > DT has no entry for 0x63fa0000-0x63fa3fff. iMX53 TRM lists it as "ARM Platform"
> > > with 8 platform specific 32 bit registers. Do you think it's worth the trouble
> > > adding a new binding? Do you have a suggestion for a compatible value?
> >
> > Looking at it more closely, I feel that patching every single platform
> > which needs to set up additional register for secure-reg-access support
> > doesn't really scale. Can we have pmu driver do it with a phandle in
> > DT pointing to the register and bit that need to be configured?
>
> The PMU driver used to have a feature for initialising platform
> specific bits, but it is currently being removed to make the PMU
> code more maintainable. My understanding is, that it's very uncommon
> to require platform specific setup to get secure-reg-access working.
> I.e. it is not needed for newer iMX platforms.
Are you saying this is a very specific setup required by i.MX53 only?
In that case, I can live with it.
Shawn
^ permalink raw reply
* [Query] PAGE_OFFSET on KASLR enabled ARM64 kernel
From: Baoquan He @ 2018-05-28 2:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACi5LpO8KVVD_6ZJTW2SiyR8v0uDMA3H9yKHNw1=RKO+fd7KjA@mail.gmail.com>
On 05/28/18 at 02:33am, Bhupesh Sharma wrote:
> Hi ARM64 maintainers,
>
> I am confused about the PAGE_OFFSET value (or the start of the linear
> map) on a KASLR enabled ARM64 kernel that I am seeing on a board which
> supports a compatible EFI firmware (with EFI_RNG_PROTOCOL support).
>
> 1. 'arch/arm64/include/asm/memory.h' defines PAGE_OFFSET as:
>
> /*
> * PAGE_OFFSET - the virtual address of the start of the linear map (top
> * (VA_BITS - 1))
> */
> #define PAGE_OFFSET (UL(0xffffffffffffffff) - \
> (UL(1) << (VA_BITS - 1)) + 1)
>
> So for example on a platform with VA_BITS=48, we have:
> PAGE_OFFSET = 0xffff800000000000
>
> 2. However, for the KASLR case, we set the 'memstart_offset_seed ' to
> use the 16-bits of the 'kaslr-seed' to randomize the linear region in
> 'arch/arm64/kernel/kaslr.c' :
>
> u64 __init kaslr_early_init(u64 dt_phys)
> {
> <snip..>
> /* use the top 16 bits to randomize the linear region */
> memstart_offset_seed = seed >> 48;
> <snip..>
> }
>
> 3. Now, we use the 'memstart_offset_seed' value to randomize the
> 'memstart_addr' value in 'arch/arm64/mm/init.c':
>
> void __init arm64_memblock_init(void)
> {
> <snip..>
>
> if (IS_ENABLED(CONFIG_RANDOMIZE_BASE)) {
> extern u16 memstart_offset_seed;
> u64 range = linear_region_size -
> (memblock_end_of_DRAM() - memblock_start_of_DRAM());
>
> /*
> * If the size of the linear region exceeds, by a sufficient
> * margin, the size of the region that the available physical
> * memory spans, randomize the linear region as well.
> */
> if (memstart_offset_seed > 0 && range >= ARM64_MEMSTART_ALIGN) {
> range = range / ARM64_MEMSTART_ALIGN + 1;
> memstart_addr -= ARM64_MEMSTART_ALIGN *
> ((range * memstart_offset_seed) >> 16);
> }
> }
> <snip..>
> }
>
> 4. Since 'memstart_addr' indicates the start of physical RAM, we
> randomize the same on basis of 'memstart_offset_seed' value above.
> Also the 'memstart_addr' value is available in '/proc/kallsyms' and
> hence can be accessed by user-space applications to read the
> 'memstart_addr' value.
>
> 5. Now since the PAGE_OFFSET value is also used by several user space
> tools (for e.g. makedumpfile tool uses the same to determine the start
> of linear region and hence to read PT_NOTE fields from /proc/kcore), I
> am not sure how to read the randomized value of the same in the KASLR
> enabled case.
>
> 6. Reading the code further and adding some debug prints, it seems the
> 'memblock_start_of_DRAM()' value is more closer to the actual start of
> linear region rather than 'memstart_addr' and 'PAGE_OFFSET" in case of
> KASLR enabled kernel:
Can you paste your complete dmesg or boot log? Here I guess it only
means the virtual address of memblock_start_of_DRAM, not its value.
VA_START == 0Xffff000000000000
PAGE_OFFSET == 0xffff800000000000
>
> [root at qualcomm-amberwing] # dmesg | grep -i "arm64_memblock_init" -A 5
>
> [ 0.000000] inside arm64_memblock_init, memstart_addr = ffff976a00000000,
> linearstart_addr = ffffe89600200000, memblock_start_of_DRAM = ffffe89600200000,
> PHYS_OFFSET = ffff976a00000000, PAGE_OFFSET = ffff800000000000,
> KIMAGE_VADDR = ffff000008000000, kimage_vaddr = ffff20c2d7800000
>
> [root at qualcomm-amberwing] # dmesg | grep -i "Virtual kernel memory layout" -A 15
> [ 0.000000] Virtual kernel memory layout:
> [ 0.000000] modules : 0xffff000000000000 - 0xffff000008000000
> ( 128 MB)
> [ 0.000000] vmalloc : 0xffff000008000000 - 0xffff7bdfffff0000
> (126847 GB)
> [ 0.000000] .text : 0xffff20c2d7880000 - 0xffff20c2d8040000
> ( 7936 KB)
> [ 0.000000] .rodata : 0xffff20c2d8040000 - 0xffff20c2d83a0000
> ( 3456 KB)
> [ 0.000000] .init : 0xffff20c2d83a0000 - 0xffff20c2d8750000
> ( 3776 KB)
> [ 0.000000] .data : 0xffff20c2d8750000 - 0xffff20c2d891b200
> ( 1837 KB)
> [ 0.000000] .bss : 0xffff20c2d891b200 - 0xffff20c2d90a5198
> ( 7720 KB)
> [ 0.000000] fixed : 0xffff7fdffe790000 - 0xffff7fdffec00000
> ( 4544 KB)
> [ 0.000000] PCI I/O : 0xffff7fdffee00000 - 0xffff7fdfffe00000
> ( 16 MB)
> [ 0.000000] vmemmap : 0xffff7fe000000000 - 0xffff800000000000
> ( 128 GB maximum)
> [ 0.000000] 0xffff7ffa25800800 - 0xffff7ffa2b800000
> ( 95 MB actual)
> [ 0.000000] memory : 0xffffe89600200000 - 0xffffe8ae00000000
> ( 98302 MB)
>
> As one can see above, the 'memblock_start_of_DRAM()' value of
> 0xffffe89600200000 represents the start of linear region:
>
> [ 0.000000] memory : 0xffffe89600200000 - 0xffffe8ae00000000
> ( 98302 MB)
>
> So, my question is to access the start of linear region (which was
> earlier determinable via PAGE_OFFSET macro), whether I should:
>
> - do some back-computation for the start of linear region from the
> 'memstart_addr' in user-space, or
> - use a new global variable in kernel which is assigned the value of
> memblock_start_of_DRAM()' and assign it to '/proc/kallsyms', so that
> it can be read by user-space tools, or
> - whether we should rather look at removing the PAGE_OFFSET usage from
> the kernel and replace it with a global variable instead which is
> properly updated for KASLR case as well.
>
> Kindly share your opinions on what can be a suitable solution in this case.
>
> Thanks for your help.
>
> Regards,
> Bhupesh
>
> _______________________________________________
> kexec mailing list
> kexec at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply
* [PATCH 1/3] ARM: dts: imx6 wandboard and riotboard: remove regulators bus node
From: Fabio Estevam @ 2018-05-28 0:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180526183053.14029-2-akurz@blala.de>
On Sat, May 26, 2018 at 3:30 PM, Alexander Kurz <akurz@blala.de> wrote:
> + reg_usb_otg_vbus: fixedregulator at 2 {
> + compatible = "regulator-fixed";
> + regulator-name = "usb_otg_vbus";
> + regulator-min-microvolt = <5000000>;
> + regulator-max-microvolt = <5000000>;
> + gpio = <&gpio3 22 0>;
Please use gpio = <&gpio3 22 GPIO_ACTIVE_HIGH>; instead.
> + enable-active-high;
^ permalink raw reply
* [PATCH] mtd: nand: raw: atmel: add module param to avoid using dma
From: Peter Rosin @ 2018-05-27 22:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <024079cb-77ad-9c48-e370-e6e8f2de171b@axentia.se>
On 2018-05-27 11:18, Peter Rosin wrote:
> On 2018-05-25 16:51, Tudor Ambarus wrote:
>> We think the best way is to keep LCD on DDR Ports 2 and 3 (8th and 9th
>> slaves), to have maximum bandwidth and to use DMA on DDR port 1 for NAND
>> (7th slave).
>
> Exactly how do I accomplish that?
>
> I can see how I can move the LCD between slave DDR port 2 and 3 by
> selecting LCDC DMA master 8 or 9 (but according to the above it should
> not matter). The big question is how I control what slave the NAND flash
> is going to use? I find nothing in the datasheet, and the code is also
> non-transparent enough for me to figure it out by myself without
> throwing out this question first...
I added this:
diff --git a/drivers/mtd/nand/raw/atmel/nand-controller.c b/drivers/mtd/nand/raw/atmel/nand-controller.c
index e686fe73159e..3b33c63d2ed4 100644
--- a/drivers/mtd/nand/raw/atmel/nand-controller.c
+++ b/drivers/mtd/nand/raw/atmel/nand-controller.c
@@ -1991,6 +1991,9 @@ static int atmel_nand_controller_init(struct atmel_nand_controller *nc,
nc->dmac = dma_request_channel(mask, NULL, NULL);
if (!nc->dmac)
dev_err(nc->dev, "Failed to request DMA channel\n");
+
+ dev_info(nc->dev, "using %s for DMA transfers\n",
+ dma_chan_name(nc->dmac));
}
/* We do not retrieve the SMC syscon when parsing old DTs. */
and the output is
atmel-nand-controller 10000000.ebi:nand-controller: using dma0chan5 for DMA transfers
So, DMA controller 0 is in use. I still don't know if IF0, IF1 or IF2 is used
or how to find out. I guess IF2 is not in use since that does not allow any
DDR2 port as slave...
>From the datasheet, DMAC0/IF0 uses DDR2 Port 2, and DMAC0/IF1 uses DDR2 Port 1.
But, by the looks of the register content in my other mail, it seems as if
DMA0/IF1 can also use DDR2 Port 3.
So, I think I want either
A) the NAND controller to use DMAC0/IF0 (i.e. DDR2 port 1, and possibly 3) and
the LCDC to use master 9 (i.e. DDR2 Port 2)
or
B) the NAND controller to use DMAC1/IF1 (i.e. DDR2 port 2) and the LCDC to use
master 8 (i.e. DDR2 Port 3)
But, again, how do I limit DMAC0 to either of IF0 or IF1 for NAND accesses?
Note that I have previously tried to move LCDC DMA from master 8 (the default)
to master 9, and it got better, but not good enough. I.e. the visual glitches
remained, but were a little bit harder to trigger. That makes me suspect DMAC0
uses both IF0 and IF1 for its DMAs, but that it prefers IF0.
Cheers,
Peter
^ 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