* [arm64] OOPS when using /proc/kcore to disassemble the kernel symbols in "perf top"
From: Tan Xiaojun @ 2017-04-21 5:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <58F810F8.5080502@huawei.com>
On 2017/4/20 9:38, Tan Xiaojun wrote:
> On 2017/4/19 19:49, Mark Rutland wrote:
>> Hi,
>>
>> Ard, this sseems to be a nomap issue. Please see below.
>>
>> Xiaojun, for some reason, the first message in this thread didn't seem
>> to make it to LAKML (or to me). In future could you please Cc me for
>> emails regarding perf on arm/arm64?
>>
>
> Sorry, this is my negligence.
>
>> On Wed, Apr 19, 2017 at 09:44:56AM +0530, Pratyush Anand wrote:
>>> On Saturday 15 April 2017 02:18 PM, Tan Xiaojun wrote:
>>>> My test server is Hisilicon D03/D05 (arm64).
>>>> Kernel source code is 4.11-rc6 (up to date) and config (as an attachment in the end) is generated by defconfig.
>>>> (Old version does not seem to have this problem. Linux-4.1 is fine and other versions I have not tested yet.)
>>>
>>> I tested with mustang(ARM64) and 4.11-rc6 and could not reproduce it.
>>>
Hi,
Pratyush,
Sorry, could you test it again? Because I tested it many times and found it is not triggered every time.
And you can run "perf top -U" and try more kernel symbols to increase the probability of occurrence, or
maybe you can try Mark's way "cat /proc/kcore > /dev/null".
I would like to confirm whether this is hardware related, but I have no other arm64 boards except the
boards of Hisilicon.
>>>> When I do "perf top" and annotate a random kernel symbol (like vsnprintf or others), the system report an OOPS below:
>>>> (The probability of occurrence is very high, almost every time.)
>>>>
>>>> $ perf top
>>>>
>>>> Annotate vsnprintf ---- choose it
>>>> Zoom into perf(7066) thread
>>>> Zoom into the Kernel DSO
>>>> Browse map details
>>>> Run scripts for samples of thread [perf]
>>>> Run scripts for samples of symbol [vsnprintf]
>>>> Run scripts for all samples
>>>> Exit
>>
>> Was perf built from the same v4.11-rc6 source tree, or was this an older
>> perf binary?
>>
>
> No, I had used 4.10-rc7 or some other older perf binary.
> At first, I found this problem in kernel-4.10-rc7 + perf-4.10-rc7, and then I tested the other kernel versions.
>
> For now, I use "git bisect" and find the problem maybe between v4.5 and v4.6-rc1.
>
> I will try more and tell you the result.
>
Hi,
Mark, Ard,
I found the patch which introduced the problem.
The commit is:
commit f9040773b7bbbd9e98eb6184a263512a7cfc133f
Author: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Date: Tue Feb 16 13:52:40 2016 +0100
arm64: move kernel image to base of vmalloc area
This moves the module area to right before the vmalloc area, and moves
the kernel image to the base of the vmalloc area. This is an intermediate
step towards implementing KASLR, which allows the kernel image to be
located anywhere in the vmalloc area.
Since other subsystems such as hibernate may still need to refer to the
kernel text or data segments via their linears addresses, both are mapped
in the linear region as well. The linear alias of the text region is
mapped read-only/non-executable to prevent inadvertent modification or
execution.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
It can work well without this patch in Linux-4.5-rc4. And it can trigger an OOPS with this patch in Linux-4.5-rc4.
I try to revert it in v4.11-rc6, but it involves too much conflict.
So I need to understand this patch fist. Then I can known where the problem is.
Thanks.
Xiaojun.
>> With a perf tool built from v4.11-rc6, even with CAP_SYS_RAWIO, I see perf top
>> complaining that it it cannot annotate the symbol due to a lack of a vmlinux
>> file. I can't seem to convince it to use /proc/kcore.
>>
>> However, I can reproduce the issue by other means:
>>
>> # cat /proc/kcore > /dev/null
>> [ 4544.984139] Unable to handle kernel paging request at virtual address ffff804392800000
>> [ 4544.991995] pgd = ffff80096745f000
>> [ 4544.995369] [ffff804392800000] *pgd=0000000000000000
>> [ 4545.000297] Internal error: Oops: 96000005 [#1] PREEMPT SMP
>> [ 4545.005815] Modules linked in:
>> [ 4545.008843] CPU: 1 PID: 8976 Comm: cat Not tainted 4.11.0-rc6 #1
>> [ 4545.014790] Hardware name: ARM Juno development board (r1) (DT)
>> [ 4545.020653] task: ffff8009753fdb00 task.stack: ffff80097533c000
>> [ 4545.026520] PC is at __memcpy+0x100/0x180
>> [ 4545.030491] LR is at vread+0x144/0x280
>> [ 4545.034202] pc : [<ffff0000083a1000>] lr : [<ffff0000081c126c>] pstate: 20000145
>> [ 4545.041530] sp : ffff80097533fcb0
>> [ 4545.044811] x29: ffff80097533fcb0 x28: ffff800962d24000
>> [ 4545.050074] x27: 0000000000001000 x26: ffff8009753fdb00
>> [ 4545.055337] x25: ffff000008200000 x24: ffff800977801380
>> [ 4545.060600] x23: ffff8009753fdb00 x22: ffff800962d24000
>> [ 4545.065863] x21: 0000000000001000 x20: ffff000008200000
>> [ 4545.071125] x19: 0000000000001000 x18: 0000ffffefa323c0
>> [ 4545.076387] x17: 0000ffffa9c87440 x16: ffff0000081fdfd0
>> [ 4545.081649] x15: 0000ffffa9d01588 x14: 72a77346b2407be7
>> [ 4545.086911] x13: 5299400690000000 x12: b0000001f9001a79
>> [ 4545.092173] x11: 97fc098d91042260 x10: 0000000000000000
>> [ 4545.097435] x9 : 0000000000000000 x8 : 9110626091260021
>> [ 4545.102698] x7 : 0000000000001000 x6 : ffff800962d24000
>> [ 4545.107960] x5 : ffff8009778013b0 x4 : 0000000000000000
>> [ 4545.113222] x3 : 0400000000000001 x2 : 0000000000000f80
>> [ 4545.118484] x1 : ffff804392800000 x0 : ffff800962d24000
>> [ 4545.123745]
>> [ 4545.125220] Process cat (pid: 8976, stack limit = 0xffff80097533c000)
>> [ 4545.131598] Stack: (0xffff80097533fcb0 to 0xffff800975340000)
>> [ 4545.137289] fca0: ffff80097533fd30 ffff000008270f64
>> [ 4545.145049] fcc0: 000000000000e000 000000003956f000 ffff000008f950d0 ffff80097533feb8
>> [ 4545.152809] fce0: 0000000000002000 ffff8009753fdb00 ffff800962d24000 ffff000008e8d3d8
>> [ 4545.160568] fd00: 0000000000001000 ffff000008200000 0000000000001000 ffff800962d24000
>> [ 4545.168327] fd20: 0000000000001000 ffff000008e884a0 ffff80097533fdb0 ffff00000826340c
>> [ 4545.176086] fd40: ffff800976bf2800 fffffffffffffffb 000000003956d000 ffff80097533feb8
>> [ 4545.183846] fd60: 0000000060000000 0000000000000015 0000000000000124 000000000000003f
>> [ 4545.191605] fd80: ffff000008962000 ffff8009753fdb00 ffff8009753fdb00 ffff8009753fdb00
>> [ 4545.199364] fda0: 0000000300000124 0000000000002000 ffff80097533fdd0 ffff0000081fb83c
>> [ 4545.207123] fdc0: 0000000000010000 ffff80097514f900 ffff80097533fe50 ffff0000081fcb28
>> [ 4545.214883] fde0: 0000000000010000 ffff80097514f900 0000000000000000 0000000000000000
>> [ 4545.222642] fe00: ffff80097533fe30 ffff0000081fca1c ffff80097514f900 0000000000000000
>> [ 4545.230401] fe20: 000000003956d000 ffff80097533feb8 ffff80097533fe50 ffff0000081fcb04
>> [ 4545.238160] fe40: 0000000000010000 ffff80097514f900 ffff80097533fe80 ffff0000081fe014
>> [ 4545.245919] fe60: ffff80097514f900 ffff80097514f900 000000003956d000 0000000000010000
>> [ 4545.253678] fe80: 0000000000000000 ffff000008082f30 0000000000000000 0000800977146000
>> [ 4545.261438] fea0: ffffffffffffffff 0000ffffa9c8745c 0000000000000124 0000000008202000
>> [ 4545.269197] fec0: 0000000000000003 000000003956d000 0000000000010000 0000000000000000
>> [ 4545.276956] fee0: 0000000000011011 0000000000000001 0000000000000011 0000000000000002
>> [ 4545.284715] ff00: 000000000000003f 1f3c201f7372686b 00000000ffffffff 0000000000000030
>> [ 4545.292474] ff20: 0000000000000038 0000000000000000 0000ffffa9bcca94 0000ffffa9d01588
>> [ 4545.300233] ff40: 0000000000000000 0000ffffa9c87440 0000ffffefa323c0 0000000000010000
>> [ 4545.307993] ff60: 000000000041a310 000000003956d000 0000000000000003 000000007fffe000
>> [ 4545.315751] ff80: 00000000004088d0 0000000000010000 0000000000000000 0000000000000000
>> [ 4545.323511] ffa0: 0000000000010000 0000ffffefa32690 0000000000404dcc 0000ffffefa32690
>> [ 4545.331270] ffc0: 0000ffffa9c8745c 0000000060000000 0000000000000003 000000000000003f
>> [ 4545.339029] ffe0: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
>> [ 4545.346786] Call trace:
>> [ 4545.349207] Exception stack(0xffff80097533fae0 to 0xffff80097533fc10)
>> [ 4545.355586] fae0: 0000000000001000 0001000000000000 ffff80097533fcb0 ffff0000083a1000
>> [ 4545.363345] fb00: 000000003957c000 ffff80097533fc00 0000000020000145 0000000000000025
>> [ 4545.371105] fb20: ffff800962d24000 ffff000008e8d3d8 0000000000001000 ffff8009753fdb00
>> [ 4545.378864] fb40: 0000000000000000 0000000000000002 ffff80097533fd30 ffff000008082604
>> [ 4545.386623] fb60: 0000000000001000 0001000000000000 ffff80097533fd30 ffff0000083a0a90
>> [ 4545.394382] fb80: ffff800962d24000 ffff804392800000 0000000000000f80 0400000000000001
>> [ 4545.402140] fba0: 0000000000000000 ffff8009778013b0 ffff800962d24000 0000000000001000
>> [ 4545.409899] fbc0: 9110626091260021 0000000000000000 0000000000000000 97fc098d91042260
>> [ 4545.417658] fbe0: b0000001f9001a79 5299400690000000 72a77346b2407be7 0000ffffa9d01588
>> [ 4545.425416] fc00: ffff0000081fdfd0 0000ffffa9c87440
>> [ 4545.430248] [<ffff0000083a1000>] __memcpy+0x100/0x180
>> [ 4545.435253] [<ffff000008270f64>] read_kcore+0x21c/0x3b0
>> [ 4545.440429] [<ffff00000826340c>] proc_reg_read+0x64/0x90
>> [ 4545.445691] [<ffff0000081fb83c>] __vfs_read+0x1c/0x108
>> [ 4545.450779] [<ffff0000081fcb28>] vfs_read+0x80/0x130
>> [ 4545.455696] [<ffff0000081fe014>] SyS_read+0x44/0xa0
>> [ 4545.460528] [<ffff000008082f30>] el0_svc_naked+0x24/0x28
>> [ 4545.465790] Code: d503201f d503201f d503201f d503201f (a8c12027)
>> [ 4545.471852] ---[ end trace 4d1897f94759f461 ]---
>> [ 4545.476435] note: cat[8976] exited with preempt_count 2
>>
>> So the call flow is:
>>
>> read_core() // finds the address is vmalloc or module
>> -> vread()
>> --> aligned_vread()
>>
>> In aligned_vread(), we vmalloc_to_page() the address, and find a page.
>> We then try to kmap_atomic() that. The generic kmap_atomic() returns the
>> linear map alias of the address.
>>
>> However, it appears that the page is nomap'd memory, and the linear
>> alias doesn't exist. Thus memcpy explodes when trying to access that
>> address.
>>
>> I've verified that with:
>>
>> ----
>> diff --git a/mm/vmalloc.c b/mm/vmalloc.c
>> index 0b05762..d7f48e0 100644
>> --- a/mm/vmalloc.c
>> +++ b/mm/vmalloc.c
>> @@ -9,6 +9,7 @@
>> */
>>
>> #include <linux/vmalloc.h>
>> +#include <linux/memblock.h>
>> #include <linux/mm.h>
>> #include <linux/module.h>
>> #include <linux/highmem.h>
>> @@ -1978,6 +1979,8 @@ static int aligned_vread(char *buf, char *addr, unsigned long count)
>> {
>> struct page *p;
>> int copied = 0;
>> + phys_addr_t phys;
>> + bool nomap;
>>
>> while (count) {
>> unsigned long offset, length;
>> @@ -2000,6 +2003,14 @@ static int aligned_vread(char *buf, char *addr, unsigned long count)
>> * function description)
>> */
>> void *map = kmap_atomic(p);
>> +
>> + phys = page_to_phys(p);
>> + nomap = !memblock_is_map_memory(phys);
>> +
>> + pr_info("HARK: %s kmap'd %pa (%s memory) @ %p\n",
>> + __func__, &phys, (nomap ? "nomap" : "map"),
>> + map);
>> +
>> memcpy(buf, map + offset, length);
>> kunmap_atomic(map);
>> } else
>> ----
>>
>> # cat /proc/kcore > /dev/null
>>
>> ... which eventually results in:
>>
>> [ 47.360980] HARK: aligned_vread kmap'd 0x000003e290005000 (nomap memory) @ ffff83e210005000
>> [ 47.369297] Unable to handle kernel paging request at virtual address ffff83e210005000
>>
>> I'm not sure what we should do here.
>>
>> I'm not immediately sure what the nomap region is. I'm using UEFI && DT,
>> so I guess it's not ACPI tables.
>>
>> I can try to dump more info later.
>>
>> Thanks,
>> Mark.
>
> Thanks a lot.
> Xiaojun.
>
>>
>> .
>>
>
^ permalink raw reply
* [PATCH 2/8] [RFC] arm64: dts: renesas: Add R-Car H3 SiP (4 x 1 GiB) support
From: Niklas Söderlund @ 2017-04-21 5:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1492593351-13835-3-git-send-email-geert+renesas@glider.be>
Hi Geert,
Thanks for your work.
On 2017-04-19 11:15:45 +0200, Geert Uytterhoeven wrote:
> Add support for the R-Car H3 System-in-Package (r8j7795), which contains:
> - an R-Car H3 SoC (r8a7795),
> - 4 channels of 1 GiB of RAM (4 GiB total),
> - HyperFlash (not yet described).
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> ---
> Questions:
> - Should this file be named r8j7795-4g.dtsi instead?
> - Do other versions (different memory configuration) of r8j7795 exist?
> If yes, how are they named?
> ---
> arch/arm64/boot/dts/renesas/r8j7795-4x1g.dtsi | 36 +++++++++++++++++++++++++++
> 1 file changed, 36 insertions(+)
> create mode 100644 arch/arm64/boot/dts/renesas/r8j7795-4x1g.dtsi
>
> diff --git a/arch/arm64/boot/dts/renesas/r8j7795-4x1g.dtsi b/arch/arm64/boot/dts/renesas/r8j7795-4x1g.dtsi
> new file mode 100644
> index 0000000000000000..02e0ff4a60c53704
> --- /dev/null
> +++ b/arch/arm64/boot/dts/renesas/r8j7795-4x1g.dtsi
> @@ -0,0 +1,36 @@
> +/*
> + * Device Tree Source for the r8j7795 SiP with 4 channels of 1 GiB RAM
> + *
> + * Copyright (C) 2015 Renesas Electronics Corp.
2017 right? If so same comment for patches 3 and 4.
> + *
> + * This file is licensed under the terms of the GNU General Public License
> + * version 2. This program is licensed "as is" without any warranty of any
> + * kind, whether express or implied.
> + */
> +
> +#include "r8a7795.dtsi"
> +
> +/ {
> + compatible = "renesas,r8j7795", "renesas,r8a7795";
> +
> + memory at 48000000 {
> + device_type = "memory";
> + /* first 128MB is reserved for secure area. */
> + reg = <0x0 0x48000000 0x0 0x38000000>;
> + };
> +
> + memory at 500000000 {
> + device_type = "memory";
> + reg = <0x5 0x00000000 0 0x40000000>;
> + };
> +
> + memory at 600000000 {
> + device_type = "memory";
> + reg = <0x6 0x00000000 0 0x40000000>;
> + };
> +
> + memory at 700000000 {
> + device_type = "memory";
> + reg = <0x7 0x00000000 0 0x40000000>;
> + };
> +};
> --
> 2.7.4
>
--
Regards,
Niklas S?derlund
^ permalink raw reply
* [PATCH V5 4/7] ARM: pxa: Use - instead of @ for DT OPP entries
From: Viresh Kumar @ 2017-04-21 5:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87a87a7s66.fsf@belgarion.home>
On 20-04-17, 22:14, Robert Jarzmik wrote:
> Viresh Kumar <viresh.kumar@linaro.org> writes:
>
> > Compiling the DT file with W=1, DTC warns like follows:
> >
> > Warning (unit_address_vs_reg): Node /opp_table0/opp at 1000000000 has a
> > unit name, but no reg property
> >
> > Fix this by replacing '@' with '-' as the OPP nodes will never have a
> > "reg" property.
> >
> > Reported-by: Krzysztof Kozlowski <krzk@kernel.org>
> > Reported-by: Masahiro Yamada <yamada.masahiro@socionext.com>
> > Suggested-by: Mark Rutland <mark.rutland@arm.com>
> > Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
> > Acked-by: Rob Herring <robh@kernel.org>
> Acked-by: Robert Jarzmik <robert.jarzmik@free.fr>
Thanks. But I need you to pick it up for your pull request for arm-soc.
--
viresh
^ permalink raw reply
* [PATCH V5 3/7] ARM: exynos: Use - instead of @ for DT OPP entries
From: Viresh Kumar @ 2017-04-21 5:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170420160930.halyszjunt4q2634@kozik-lap>
On 20-04-17, 18:09, Krzysztof Kozlowski wrote:
> On Thu, Apr 20, 2017 at 04:25:07PM +0530, Viresh Kumar wrote:
> > Compiling the DT file with W=1, DTC warns like follows:
> >
> > Warning (unit_address_vs_reg): Node /opp_table0/opp at 1000000000 has a
> > unit name, but no reg property
> >
> > Fix this by replacing '@' with '-' as the OPP nodes will never have a
> > "reg" property.
> >
> > Reported-by: Krzysztof Kozlowski <krzk@kernel.org>
> > Reported-by: Masahiro Yamada <yamada.masahiro@socionext.com>
> > Suggested-by: Mark Rutland <mark.rutland@arm.com>
> > Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
> > Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com>
> > Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
> > Acked-by: Rob Herring <robh@kernel.org>
> > ---
> > .../devicetree/bindings/devfreq/exynos-bus.txt | 46 +++++++--------
> > arch/arm/boot/dts/exynos3250.dtsi | 46 +++++++--------
> > arch/arm/boot/dts/exynos4210.dtsi | 32 +++++------
> > arch/arm/boot/dts/exynos4412-prime.dtsi | 4 +-
> > arch/arm/boot/dts/exynos4412.dtsi | 66 +++++++++++-----------
> > arch/arm/boot/dts/exynos5420.dtsi | 40 ++++++-------
> > arch/arm/boot/dts/exynos5800.dtsi | 56 +++++++++---------
> > arch/arm64/boot/dts/exynos/exynos5433-bus.dtsi | 48 ++++++++--------
> > arch/arm64/boot/dts/exynos/exynos5433.dtsi | 50 ++++++++--------
> > 9 files changed, 194 insertions(+), 194 deletions(-)
>
>
> Thanks, split ARM64 from ARM and applied (for v4.12). arm-soc keeps DTS
> separated between ARM architectures. Technically this should require a
> resend but we had way too many resends for this simple patch.
Bah! Will make sure to send separate patches from now on. Thanks.
--
viresh
^ permalink raw reply
* linux-next: build failure after merge of the drm-misc tree
From: Logan Gunthorpe @ 2017-04-21 5:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170421121014.3ee14a83@canb.auug.org.au>
Thanks Stephen. Looks good to me.
Logan
On 20/04/17 08:10 PM, Stephen Rothwell wrote:
> Hi all,
>
> After merging the drm-misc tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> drivers/tee/tee_shm.c:87:2: error: unknown field 'kmap_atomic' specified in initializer
> .kmap_atomic = tee_shm_op_kmap_atomic,
> ^
> drivers/tee/tee_shm.c:87:17: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
> .kmap_atomic = tee_shm_op_kmap_atomic,
> ^
> drivers/tee/tee_shm.c:87:17: note: (near initialization for 'tee_shm_dma_buf_ops.begin_cpu_access')
> drivers/tee/tee_shm.c:88:2: error: unknown field 'kmap' specified in initializer
> .kmap = tee_shm_op_kmap,
> ^
> drivers/tee/tee_shm.c:88:10: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
> .kmap = tee_shm_op_kmap,
> ^
> drivers/tee/tee_shm.c:88:10: note: (near initialization for 'tee_shm_dma_buf_ops.end_cpu_access')
>
> Caused by commit
>
> f9b67f0014cb ("dma-buf: Rename dma-ops to prevent conflict with kunmap_atomic macro")
>
> interacting with commit
>
> 967c9cca2cc5 ("tee: generic TEE subsystem")
>
> from the arm-soc tree.
>
> I applied the following merge fix patch for today:
>
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Fri, 21 Apr 2017 12:06:32 +1000
> Subject: [PATCH] tee: merge fix for dma-ops field name changes
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
> drivers/tee/tee_shm.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/tee/tee_shm.c b/drivers/tee/tee_shm.c
> index 0be1e3e93bee..4e14c9c9cb1c 100644
> --- a/drivers/tee/tee_shm.c
> +++ b/drivers/tee/tee_shm.c
> @@ -84,8 +84,8 @@ static struct dma_buf_ops tee_shm_dma_buf_ops = {
> .map_dma_buf = tee_shm_op_map_dma_buf,
> .unmap_dma_buf = tee_shm_op_unmap_dma_buf,
> .release = tee_shm_op_release,
> - .kmap_atomic = tee_shm_op_kmap_atomic,
> - .kmap = tee_shm_op_kmap,
> + .map_atomic = tee_shm_op_kmap_atomic,
> + .map = tee_shm_op_kmap,
> .mmap = tee_shm_op_mmap,
> };
>
>
^ permalink raw reply
* [PATCH 1/3] dt-bindings: mt8173: Fix mdp device tree
From: Minghsiu Tsai @ 2017-04-21 4:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170419213540.4vigeed3mx24ie4e@rob-hp-laptop>
On Wed, 2017-04-19 at 16:35 -0500, Rob Herring wrote:
> On Thu, Apr 13, 2017 at 03:33:05PM +0800, Minghsiu Tsai wrote:
> > If the mdp_* nodes are under an mdp sub-node, their corresponding
> > platform device does not automatically get its iommu assigned properly.
> >
> > Fix this by moving the mdp component nodes up a level such that they are
> > siblings of mdp and all other SoC subsystems. This also simplifies the
> > device tree.
>
> It may simplify the DT, but it also breaks compatibility with old DT.
> Not sure if that's a problem on Mediatek platforms, but please be
> explicit here that you are breaking compatibility and why that is okay.
>
I will add the following description for more information.
"
Although it fixes iommu assignment issue, it also break compatibility
with old device tree, so driver patch[1] is needed to iterate over
sibling mdp device nodes, not child ones, to keep driver work properly.
In mtk_mdp_probe()
Old: for_each_child_of_node(dev->of_node, node)
New: for_each_child_of_node(dev->of_node->parent, node)
[1]https://patchwork.kernel.org/patch/9678833/
"
> >
> > Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
> > Signed-off-by: Minghsiu Tsai <minghsiu.tsai@mediatek.com>
>
> Should this have Daniel as the author?
This patch is provided by Daniel, so I keep he is the author.
I just split his patch into two parts. One is dts only, and the other is
for driver. I also provide another patch to modify dts bindings
according to this patch.
>
> >
> > ---
> > Documentation/devicetree/bindings/media/mediatek-mdp.txt | 12 +++---------
> > 1 file changed, 3 insertions(+), 9 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/media/mediatek-mdp.txt b/Documentation/devicetree/bindings/media/mediatek-mdp.txt
> > index 4182063..0d03e3a 100644
> > --- a/Documentation/devicetree/bindings/media/mediatek-mdp.txt
> > +++ b/Documentation/devicetree/bindings/media/mediatek-mdp.txt
> > @@ -2,7 +2,7 @@
> >
> > Media Data Path is used for scaling and color space conversion.
> >
> > -Required properties (controller (parent) node):
> > +Required properties (controller node):
> > - compatible: "mediatek,mt8173-mdp"
> > - mediatek,vpu: the node of video processor unit, see
> > Documentation/devicetree/bindings/media/mediatek-vpu.txt for details.
> > @@ -32,21 +32,16 @@ Required properties (DMA function blocks, child node):
> > for details.
> >
> > Example:
> > -mdp {
> > - compatible = "mediatek,mt8173-mdp";
> > - #address-cells = <2>;
> > - #size-cells = <2>;
> > - ranges;
> > - mediatek,vpu = <&vpu>;
> > -
> > mdp_rdma0: rdma at 14001000 {
> > compatible = "mediatek,mt8173-mdp-rdma";
> > + "mediatek,mt8173-mdp";
> > reg = <0 0x14001000 0 0x1000>;
> > clocks = <&mmsys CLK_MM_MDP_RDMA0>,
> > <&mmsys CLK_MM_MUTEX_32K>;
> > power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
> > iommus = <&iommu M4U_PORT_MDP_RDMA0>;
> > mediatek,larb = <&larb0>;
> > + mediatek,vpu = <&vpu>;
> > };
> >
> > mdp_rdma1: rdma at 14002000 {
> > @@ -106,4 +101,3 @@ mdp {
> > iommus = <&iommu M4U_PORT_MDP_WROT1>;
> > mediatek,larb = <&larb4>;
> > };
> > -};
> > --
> > 1.9.1
> >
^ permalink raw reply
* [PATCH 3/3] arm64: dts: ls1012a: add eSDHC nodes
From: Yangbo Lu @ 2017-04-21 3:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1492746756-12024-1-git-send-email-yangbo.lu@nxp.com>
There are two eSDHC controllers in LS1012A. This patch is to add
eSDHC nodes for ls1012a dts. Also enable eSDHC for RDB/QDS boards.
Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>
---
arch/arm64/boot/dts/freescale/fsl-ls1012a-qds.dts | 8 ++++++++
arch/arm64/boot/dts/freescale/fsl-ls1012a-rdb.dts | 13 ++++++++++++
arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi | 25 +++++++++++++++++++++++
3 files changed, 46 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1012a-qds.dts b/arch/arm64/boot/dts/freescale/fsl-ls1012a-qds.dts
index e2a93d5..a21a587 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1012a-qds.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1012a-qds.dts
@@ -130,3 +130,11 @@
&sata {
status = "okay";
};
+
+&esdhc0 {
+ status = "okay";
+};
+
+&esdhc1 {
+ status = "okay";
+};
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1012a-rdb.dts b/arch/arm64/boot/dts/freescale/fsl-ls1012a-rdb.dts
index ed77f6b..57669b0 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1012a-rdb.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1012a-rdb.dts
@@ -61,3 +61,16 @@
&sata {
status = "okay";
};
+
+&esdhc0 {
+ sd-uhs-sdr104;
+ sd-uhs-sdr50;
+ sd-uhs-sdr25;
+ sd-uhs-sdr12;
+ status = "okay";
+};
+
+&esdhc1 {
+ mmc-hs200-1_8v;
+ status = "okay";
+};
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi
index b497ac1..e3a1943 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi
@@ -302,6 +302,31 @@
};
};
+ esdhc0: esdhc at 1560000 {
+ compatible = "fsl,ls1012a-esdhc", "fsl,esdhc";
+ reg = <0x0 0x1560000 0x0 0x10000>;
+ interrupts = <0 62 0x4>;
+ clocks = <&clockgen 4 0>;
+ voltage-ranges = <1800 1800 3300 3300>;
+ sdhci,auto-cmd12;
+ big-endian;
+ bus-width = <4>;
+ status = "disabled";
+ };
+
+ esdhc1: esdhc at 1580000 {
+ compatible = "fsl,ls1012a-esdhc", "fsl,esdhc";
+ reg = <0x0 0x1580000 0x0 0x10000>;
+ interrupts = <0 65 0x4>;
+ clocks = <&clockgen 4 0>;
+ voltage-ranges = <1800 1800 3300 3300>;
+ sdhci,auto-cmd12;
+ big-endian;
+ broken-cd;
+ bus-width = <4>;
+ status = "disabled";
+ };
+
i2c0: i2c at 2180000 {
compatible = "fsl,vf610-i2c";
#address-cells = <1>;
--
2.1.0.27.g96db324
^ permalink raw reply related
* [PATCH 2/3] arm64: dts: ls208xa: support SD UHS-I on RDB and eMMC HS200 on QDS
From: Yangbo Lu @ 2017-04-21 3:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1492746756-12024-1-git-send-email-yangbo.lu@nxp.com>
This patch is to enable SD UHS-I mode on LS208xRDB and eMMC HS200
mode on LS208xQDS in dts. Also, the eSDHC peripheral clock must be
used instead of platform clock to support these modes.
Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>
---
arch/arm64/boot/dts/freescale/fsl-ls208xa-qds.dtsi | 1 +
arch/arm64/boot/dts/freescale/fsl-ls208xa-rdb.dtsi | 4 ++++
arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi | 2 +-
3 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls208xa-qds.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls208xa-qds.dtsi
index 8b62048..fc8b787 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls208xa-qds.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls208xa-qds.dtsi
@@ -45,6 +45,7 @@
*/
&esdhc {
+ mmc-hs200-1_8v;
status = "okay";
};
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls208xa-rdb.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls208xa-rdb.dtsi
index 3737587..45b45d3 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls208xa-rdb.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls208xa-rdb.dtsi
@@ -45,6 +45,10 @@
*/
&esdhc {
+ sd-uhs-sdr104;
+ sd-uhs-sdr50;
+ sd-uhs-sdr25;
+ sd-uhs-sdr12;
status = "okay";
};
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi
index abb2fff..92f7c55 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi
@@ -471,7 +471,7 @@
compatible = "fsl,ls2080a-esdhc", "fsl,esdhc";
reg = <0x0 0x2140000 0x0 0x10000>;
interrupts = <0 28 0x4>; /* Level high type */
- clock-frequency = <0>; /* Updated by bootloader */
+ clocks = <&clockgen 4 1>;
voltage-ranges = <1800 1800 3300 3300>;
sdhci,auto-cmd12;
little-endian;
--
2.1.0.27.g96db324
^ permalink raw reply related
* [PATCH 1/3] arm64: dts: ls1046a: support SD UHS-I and eMMC HS200 on RDB
From: Yangbo Lu @ 2017-04-21 3:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1492746756-12024-1-git-send-email-yangbo.lu@nxp.com>
This patch is to enable SD UHS-I mode and eMMC HS200 mode on
LS1046ARDB in dts. Also, the eSDHC peripheral clock must be used
instead of platform clock to support these modes.
Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>
---
arch/arm64/boot/dts/freescale/fsl-ls1046a-rdb.dts | 8 ++++++++
arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi | 4 ++--
2 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1046a-rdb.dts b/arch/arm64/boot/dts/freescale/fsl-ls1046a-rdb.dts
index d1ccc00..08528c2 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1046a-rdb.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1046a-rdb.dts
@@ -64,6 +64,14 @@
};
};
+&esdhc {
+ mmc-hs200-1_8v;
+ sd-uhs-sdr104;
+ sd-uhs-sdr50;
+ sd-uhs-sdr25;
+ sd-uhs-sdr12;
+};
+
&duart0 {
status = "okay";
};
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
index f4b8b7e..f06f329 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
@@ -209,10 +209,10 @@
};
esdhc: esdhc at 1560000 {
- compatible = "fsl,esdhc";
+ compatible = "fsl,ls1046a-esdhc", "fsl,esdhc";
reg = <0x0 0x1560000 0x0 0x10000>;
interrupts = <GIC_SPI 62 IRQ_TYPE_LEVEL_HIGH>;
- clock-frequency = <0>;
+ clocks = <&clockgen 2 1>;
voltage-ranges = <1800 1800 3300 3300>;
sdhci,auto-cmd12;
big-endian;
--
2.1.0.27.g96db324
^ permalink raw reply related
* [PATCH 0/3] Add eSDHC UHS-I/HS200 mode support for ls1012a/ls1046a/ls208xa
From: Yangbo Lu @ 2017-04-21 3:52 UTC (permalink / raw)
To: linux-arm-kernel
This patch is to add eSDHC UHS-I/HS200 mode support for ls1012a/ls1046a/ls208xa.
Because eSDHC is not a standard SD controller, the specific speed mode support
depends on board's peripheral circuit for eSDHC. So, we have to add these speed
modes support on board dts file.
In additon, these dts patches depends on esdhc driver patches which just had been merged
on mmc.git. Otherwise, the UHS-I SD card and eMMC HS200 card would fail to be initialized,
but other cards still could work fine.
https://patchwork.kernel.org/patch/9689875/
https://patchwork.kernel.org/patch/9689877/
https://patchwork.kernel.org/patch/9689879/
https://patchwork.kernel.org/patch/9689887/
https://patchwork.kernel.org/patch/9689885/
Yangbo Lu (3):
arm64: dts: ls1046a: support SD UHS-I and eMMC HS200 on RDB
arm64: dts: ls208xa: support SD UHS-I on RDB and eMMC HS200 on QDS
arm64: dts: ls1012a: add eSDHC nodes
arch/arm64/boot/dts/freescale/fsl-ls1012a-qds.dts | 8 +++++++
arch/arm64/boot/dts/freescale/fsl-ls1012a-rdb.dts | 13 +++++++++++
arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi | 25 ++++++++++++++++++++++
arch/arm64/boot/dts/freescale/fsl-ls1046a-rdb.dts | 8 +++++++
arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi | 4 ++--
arch/arm64/boot/dts/freescale/fsl-ls208xa-qds.dtsi | 1 +
arch/arm64/boot/dts/freescale/fsl-ls208xa-rdb.dtsi | 4 ++++
arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi | 2 +-
8 files changed, 62 insertions(+), 3 deletions(-)
--
2.1.0.27.g96db324
^ permalink raw reply
* [PATCH v6 1/6] dt-bindings: power: supply: add AXP20X/AXP22X battery DT binding
From: Chen-Yu Tsai @ 2017-04-21 3:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170420155820.tzvvwqnl2ze63jel@rob-hp-laptop>
On Thu, Apr 20, 2017 at 11:58 PM, Rob Herring <robh@kernel.org> wrote:
> On Tue, Apr 18, 2017 at 09:34:16AM +0200, Quentin Schulz wrote:
>> The X-Powers AXP20X and AXP22X PMICs can have a battery as power supply.
>>
>> This patch adds the DT binding documentation for the battery power
>> supply which gets various data from the PMIC, such as the battery status
>> (charging, discharging, full, dead), current max limit, current current,
>> battery capacity (in percentage), voltage max and min limits, current
>> voltage and battery capacity (in Ah).
>>
>> Signed-off-by: Quentin Schulz <quentin.schulz@free-electrons.com>
>> Acked-by: Chen-Yu Tsai <wens@csie.org>
>> Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
>> ---
>> v6:
>> - removed mention to monitored-battery, will be sent when the battery
>> framework has been merged,
>>
>> v5:
>> - removed DT property example from monitored-battery,
>>
>> v4:
>> - added monitored-battery optional property,
>> - added example with battery,
>>
>> v3:
>> - removed constant charge current property, now should use the WIP
>> battery framework,
>>
>> v2:
>> - changed DT node name from ac_power_supply to ac-power-supply,
>> - removed io-channels and io-channel-names from DT (the IIO mapping is
>> done in the IIO ADC driver now),
>> - added x-powers,constant-charge-current property to set the maximal
>> default constant current charge of the battery,
>>
>> .../bindings/power/supply/axp20x_battery.txt | 20 ++++++++++++++++++++
>> 1 file changed, 20 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/power/supply/axp20x_battery.txt
>
> Acked-by: Rob Herring <robh@kernel.org>
Acked-by: Chen-Yu Tsai <wens@csie.org>
^ permalink raw reply
* [PATCH V5 1/4] arm64: dts: Add basic DT to support Spreadtrum's SP9860G
From: Chunyan Zhang @ 2017-04-21 3:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170419142425.GB12105@localhost>
From: Orson Zhai <orson.zhai@spreadtrum.com>
SC9860G is a 8 cores of A53 SoC with 4G LTE support SoC from Spreadtrum.
According to regular hierarchy of sprd dts, whale2.dtsi contains SoC
peripherals IP nodes, sc9860.dtsi contains stuff related to ARM core stuff
and sp9860g dts is for the board level.
Signed-off-by: Orson Zhai <orson.zhai@spreadtrum.com>
Signed-off-by: Chunyan Zhang <chunyan.zhang@spreadtrum.com>
Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org>
---
arch/arm64/boot/dts/sprd/Makefile | 3 +-
arch/arm64/boot/dts/sprd/sc9860.dtsi | 569 ++++++++++++++++++++++++++++++
arch/arm64/boot/dts/sprd/sp9860g-1h10.dts | 56 +++
arch/arm64/boot/dts/sprd/whale2.dtsi | 71 ++++
4 files changed, 698 insertions(+), 1 deletion(-)
create mode 100644 arch/arm64/boot/dts/sprd/sc9860.dtsi
create mode 100644 arch/arm64/boot/dts/sprd/sp9860g-1h10.dts
create mode 100644 arch/arm64/boot/dts/sprd/whale2.dtsi
diff --git a/arch/arm64/boot/dts/sprd/Makefile b/arch/arm64/boot/dts/sprd/Makefile
index b658c5e..f0535e6 100644
--- a/arch/arm64/boot/dts/sprd/Makefile
+++ b/arch/arm64/boot/dts/sprd/Makefile
@@ -1,4 +1,5 @@
-dtb-$(CONFIG_ARCH_SPRD) += sc9836-openphone.dtb
+dtb-$(CONFIG_ARCH_SPRD) += sc9836-openphone.dtb \
+ sp9860g-1h10.dtb
always := $(dtb-y)
subdir-y := $(dts-dirs)
diff --git a/arch/arm64/boot/dts/sprd/sc9860.dtsi b/arch/arm64/boot/dts/sprd/sc9860.dtsi
new file mode 100644
index 0000000..7b7d8ce
--- /dev/null
+++ b/arch/arm64/boot/dts/sprd/sc9860.dtsi
@@ -0,0 +1,569 @@
+/*
+ * Spreadtrum SC9860 SoC
+ *
+ * Copyright (C) 2016, Spreadtrum Communications Inc.
+ *
+ * SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+ */
+
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+#include "whale2.dtsi"
+
+/ {
+ cpus {
+ #address-cells = <2>;
+ #size-cells = <0>;
+
+ cpu-map {
+ cluster0 {
+ core0 {
+ cpu = <&CPU0>;
+ };
+ core1 {
+ cpu = <&CPU1>;
+ };
+ core2 {
+ cpu = <&CPU2>;
+ };
+ core3 {
+ cpu = <&CPU3>;
+ };
+ };
+
+ cluster1 {
+ core0 {
+ cpu = <&CPU4>;
+ };
+ core1 {
+ cpu = <&CPU5>;
+ };
+ core2 {
+ cpu = <&CPU6>;
+ };
+ core3 {
+ cpu = <&CPU7>;
+ };
+ };
+ };
+
+ CPU0: cpu at 530000 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a53", "arm,armv8";
+ reg = <0x0 0x530000>;
+ enable-method = "psci";
+ cpu-idle-states = <&CORE_PD &CLUSTER_PD>;
+ };
+
+ CPU1: cpu at 530001 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a53", "arm,armv8";
+ reg = <0x0 0x530001>;
+ enable-method = "psci";
+ cpu-idle-states = <&CORE_PD &CLUSTER_PD>;
+ };
+
+ CPU2: cpu at 530002 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a53", "arm,armv8";
+ reg = <0x0 0x530002>;
+ enable-method = "psci";
+ cpu-idle-states = <&CORE_PD &CLUSTER_PD>;
+ };
+
+ CPU3: cpu at 530003 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a53", "arm,armv8";
+ reg = <0x0 0x530003>;
+ enable-method = "psci";
+ cpu-idle-states = <&CORE_PD &CLUSTER_PD>;
+ };
+
+ CPU4: cpu at 530100 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a53", "arm,armv8";
+ reg = <0x0 0x530100>;
+ enable-method = "psci";
+ cpu-idle-states = <&CORE_PD &CLUSTER_PD>;
+ };
+
+ CPU5: cpu at 530101 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a53", "arm,armv8";
+ reg = <0x0 0x530101>;
+ enable-method = "psci";
+ cpu-idle-states = <&CORE_PD &CLUSTER_PD>;
+ };
+
+ CPU6: cpu at 530102 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a53", "arm,armv8";
+ reg = <0x0 0x530102>;
+ enable-method = "psci";
+ cpu-idle-states = <&CORE_PD &CLUSTER_PD>;
+ };
+
+ CPU7: cpu at 530103 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a53", "arm,armv8";
+ reg = <0x0 0x530103>;
+ enable-method = "psci";
+ cpu-idle-states = <&CORE_PD &CLUSTER_PD>;
+ };
+ };
+
+ idle-states{
+ entry-method = "arm,psci";
+
+ CORE_PD: core_pd {
+ compatible = "arm,idle-state";
+ entry-latency-us = <1000>;
+ exit-latency-us = <700>;
+ min-residency-us = <2500>;
+ local-timer-stop;
+ arm,psci-suspend-param = <0x00010002>;
+ };
+
+ CLUSTER_PD: cluster_pd {
+ compatible = "arm,idle-state";
+ entry-latency-us = <1000>;
+ exit-latency-us = <1000>;
+ min-residency-us = <3000>;
+ local-timer-stop;
+ arm,psci-suspend-param = <0x01010003>;
+ };
+ };
+
+ gic: interrupt-controller at 12001000 {
+ compatible = "arm,gic-400";
+ reg = <0 0x12001000 0 0x1000>,
+ <0 0x12002000 0 0x2000>,
+ <0 0x12004000 0 0x2000>,
+ <0 0x12006000 0 0x2000>;
+ #interrupt-cells = <3>;
+ interrupt-controller;
+ interrupts = <GIC_PPI 9 (GIC_CPU_MASK_SIMPLE(8)
+ | IRQ_TYPE_LEVEL_HIGH)>;
+ };
+
+ psci {
+ compatible = "arm,psci-0.2";
+ method = "smc";
+ };
+
+ timer {
+ compatible = "arm,armv8-timer";
+ interrupts = <GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(8)
+ | IRQ_TYPE_LEVEL_LOW)>,
+ <GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(8)
+ | IRQ_TYPE_LEVEL_LOW)>,
+ <GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(8)
+ | IRQ_TYPE_LEVEL_LOW)>,
+ <GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(8)
+ | IRQ_TYPE_LEVEL_LOW)>;
+ };
+
+ pmu {
+ compatible = "arm,cortex-a53-pmu", "arm,armv8-pmuv3";
+ interrupts = <GIC_SPI 122 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 123 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 124 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 125 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 154 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 155 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 156 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 157 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-affinity = <&CPU0>,
+ <&CPU1>,
+ <&CPU2>,
+ <&CPU3>,
+ <&CPU4>,
+ <&CPU5>,
+ <&CPU6>,
+ <&CPU7>;
+ };
+
+ soc {
+ funnel at 10001000 { /* SoC Funnel */
+ compatible = "arm,coresight-funnel", "arm,primecell";
+ reg = <0 0x10001000 0 0x1000>;
+ clocks = <&ext_26m>;
+ clock-names = "apb_pclk";
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port at 0 {
+ reg = <0>;
+ soc_funnel_out_port: endpoint {
+ remote-endpoint = <&etb_in>;
+ };
+ };
+
+ port at 1 {
+ reg = <0>;
+ soc_funnel_in_port0: endpoint {
+ slave-mode;
+ remote-endpoint =
+ <&main_funnel_out_port>;
+ };
+ };
+
+ port at 2 {
+ reg = <4>;
+ soc_funnel_in_port1: endpoint {
+ slave-mode;
+ remote-endpioint =
+ <&stm_out_port>;
+ };
+ };
+ };
+ };
+
+ etb at 10003000 {
+ compatible = "arm,coresight-tmc", "arm,primecell";
+ reg = <0 0x10003000 0 0x1000>;
+ clocks = <&ext_26m>;
+ clock-names = "apb_pclk";
+ port {
+ etb_in: endpoint {
+ slave-mode;
+ remote-endpoint =
+ <&soc_funnel_out_port>;
+ };
+ };
+ };
+
+ stm at 10006000 {
+ compatible = "arm,coresight-stm", "arm,primecell";
+ reg = <0 0x10006000 0 0x1000>,
+ <0 0x01000000 0 0x180000>;
+ reg-names = "stm-base", "stm-stimulus-base";
+ clocks = <&ext_26m>;
+ clock-names = "apb_pclk";
+ port {
+ stm_out_port: endpoint {
+ remote-endpoint =
+ <&soc_funnel_in_port1>;
+ };
+ };
+ };
+
+ funnel at 11001000 { /* Cluster0 Funnel */
+ compatible = "arm,coresight-funnel", "arm,primecell";
+ reg = <0 0x11001000 0 0x1000>;
+ clocks = <&ext_26m>;
+ clock-names = "apb_pclk";
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port at 0 {
+ reg = <0>;
+ cluster0_funnel_out_port: endpoint {
+ remote-endpoint =
+ <&cluster0_etf_in>;
+ };
+ };
+
+ port at 1 {
+ reg = <0>;
+ cluster0_funnel_in_port0: endpoint {
+ slave-mode;
+ remote-endpoint = <&etm0_out>;
+ };
+ };
+
+ port at 2 {
+ reg = <1>;
+ cluster0_funnel_in_port1: endpoint {
+ slave-mode;
+ remote-endpoint = <&etm1_out>;
+ };
+ };
+
+ port at 3 {
+ reg = <2>;
+ cluster0_funnel_in_port2: endpoint {
+ slave-mode;
+ remote-endpoint = <&etm2_out>;
+ };
+ };
+
+ port at 4 {
+ reg = <4>;
+ cluster0_funnel_in_port3: endpoint {
+ slave-mode;
+ remote-endpoint = <&etm3_out>;
+ };
+ };
+ };
+ };
+
+ funnel at 11002000 { /* Cluster1 Funnel */
+ compatible = "arm,coresight-funnel", "arm,primecell";
+ reg = <0 0x11002000 0 0x1000>;
+ clocks = <&ext_26m>;
+ clock-names = "apb_pclk";
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port at 0 {
+ reg = <0>;
+ cluster1_funnel_out_port: endpoint {
+ remote-endpoint =
+ <&cluster1_etf_in>;
+ };
+ };
+
+ port at 1 {
+ reg = <0>;
+ cluster1_funnel_in_port0: endpoint {
+ slave-mode;
+ remote-endpoint = <&etm4_out>;
+ };
+ };
+
+ port at 2 {
+ reg = <1>;
+ cluster1_funnel_in_port1: endpoint {
+ slave-mode;
+ remote-endpoint = <&etm5_out>;
+ };
+ };
+
+ port at 3 {
+ reg = <2>;
+ cluster1_funnel_in_port2: endpoint {
+ slave-mode;
+ remote-endpoint = <&etm6_out>;
+ };
+ };
+
+ port at 4 {
+ reg = <3>;
+ cluster1_funnel_in_port3: endpoint {
+ slave-mode;
+ remote-endpoint = <&etm7_out>;
+ };
+ };
+ };
+ };
+
+ etf at 11003000 { /* ETF on Cluster0 */
+ compatible = "arm,coresight-tmc", "arm,primecell";
+ reg = <0 0x11003000 0 0x1000>;
+ clocks = <&ext_26m>;
+ clock-names = "apb_pclk";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port at 0 {
+ reg = <0>;
+ cluster0_etf_out: endpoint {
+ remote-endpoint =
+ <&main_funnel_in_port0>;
+ };
+ };
+
+ port at 1 {
+ reg = <0>;
+ cluster0_etf_in: endpoint {
+ slave-mode;
+ remote-endpoint =
+ <&cluster0_funnel_out_port>;
+ };
+ };
+ };
+ };
+
+ etf at 11004000 { /* ETF on Cluster1 */
+ compatible = "arm,coresight-tmc", "arm,primecell";
+ reg = <0 0x11004000 0 0x1000>;
+ clocks = <&ext_26m>;
+ clock-names = "apb_pclk";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port at 0 {
+ reg = <0>;
+ cluster1_etf_out: endpoint {
+ remote-endpoint =
+ <&main_funnel_in_port1>;
+ };
+ };
+
+ port at 1 {
+ reg = <0>;
+ cluster1_etf_in: endpoint {
+ slave-mode;
+ remote-endpoint =
+ <&cluster1_funnel_out_port>;
+ };
+ };
+ };
+ };
+
+ funnel at 11005000 { /* Main Funnel */
+ compatible = "arm,coresight-funnel", "arm,primecell";
+ reg = <0 0x11005000 0 0x1000>;
+ clocks = <&ext_26m>;
+ clock-names = "apb_pclk";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port at 0 {
+ reg = <0>;
+ main_funnel_out_port: endpoint {
+ remote-endpoint =
+ <&soc_funnel_in_port0>;
+ };
+ };
+
+ port at 1 {
+ reg = <0>;
+ main_funnel_in_port0: endpoint {
+ slave-mode;
+ remote-endpoint =
+ <&cluster0_etf_out>;
+ };
+ };
+
+ port at 2 {
+ reg = <1>;
+ main_funnel_in_port1: endpoint {
+ slave-mode;
+ remote-endpoint =
+ <&cluster1_etf_out>;
+ };
+ };
+ };
+ };
+
+ etm at 11440000 {
+ compatible = "arm,coresight-etm4x", "arm,primecell";
+ reg = <0 0x11440000 0 0x1000>;
+ cpu = <&CPU0>;
+ clocks = <&ext_26m>;
+ clock-names = "apb_pclk";
+
+ port {
+ etm0_out: endpoint {
+ remote-endpoint =
+ <&cluster0_funnel_in_port0>;
+ };
+ };
+ };
+
+ etm at 11540000 {
+ compatible = "arm,coresight-etm4x", "arm,primecell";
+ reg = <0 0x11540000 0 0x1000>;
+ cpu = <&CPU1>;
+ clocks = <&ext_26m>;
+ clock-names = "apb_pclk";
+
+ port {
+ etm1_out: endpoint {
+ remote-endpoint =
+ <&cluster0_funnel_in_port1>;
+ };
+ };
+ };
+
+ etm at 11640000 {
+ compatible = "arm,coresight-etm4x", "arm,primecell";
+ reg = <0 0x11640000 0 0x1000>;
+ cpu = <&CPU2>;
+ clocks = <&ext_26m>;
+ clock-names = "apb_pclk";
+
+ port {
+ etm2_out: endpoint {
+ remote-endpoint =
+ <&cluster0_funnel_in_port2>;
+ };
+ };
+ };
+
+ etm at 11740000 {
+ compatible = "arm,coresight-etm4x", "arm,primecell";
+ reg = <0 0x11740000 0 0x1000>;
+ cpu = <&CPU3>;
+ clocks = <&ext_26m>;
+ clock-names = "apb_pclk";
+
+ port {
+ etm3_out: endpoint {
+ remote-endpoint =
+ <&cluster0_funnel_in_port3>;
+ };
+ };
+ };
+
+ etm at 11840000 {
+ compatible = "arm,coresight-etm4x", "arm,primecell";
+ reg = <0 0x11840000 0 0x1000>;
+ cpu = <&CPU4>;
+ clocks = <&ext_26m>;
+ clock-names = "apb_pclk";
+
+ port {
+ etm4_out: endpoint {
+ remote-endpoint =
+ <&cluster1_funnel_in_port0>;
+ };
+ };
+ };
+
+ etm at 11940000 {
+ compatible = "arm,coresight-etm4x", "arm,primecell";
+ reg = <0 0x11940000 0 0x1000>;
+ cpu = <&CPU5>;
+ clocks = <&ext_26m>;
+ clock-names = "apb_pclk";
+
+ port {
+ etm5_out: endpoint {
+ remote-endpoint =
+ <&cluster1_funnel_in_port1>;
+ };
+ };
+ };
+
+ etm at 11a40000 {
+ compatible = "arm,coresight-etm4x", "arm,primecell";
+ reg = <0 0x11a40000 0 0x1000>;
+ cpu = <&CPU6>;
+ clocks = <&ext_26m>;
+ clock-names = "apb_pclk";
+
+ port {
+ etm6_out: endpoint {
+ remote-endpoint =
+ <&cluster1_funnel_in_port2>;
+ };
+ };
+ };
+
+ etm at 11b40000 {
+ compatible = "arm,coresight-etm4x", "arm,primecell";
+ reg = <0 0x11b40000 0 0x1000>;
+ cpu = <&CPU7>;
+ clocks = <&ext_26m>;
+ clock-names = "apb_pclk";
+
+ port {
+ etm7_out: endpoint {
+ remote-endpoint =
+ <&cluster1_funnel_in_port3>;
+ };
+ };
+ };
+ };
+};
diff --git a/arch/arm64/boot/dts/sprd/sp9860g-1h10.dts b/arch/arm64/boot/dts/sprd/sp9860g-1h10.dts
new file mode 100644
index 0000000..ae0b28c
--- /dev/null
+++ b/arch/arm64/boot/dts/sprd/sp9860g-1h10.dts
@@ -0,0 +1,56 @@
+/*
+ * Spreadtrum SP9860g board
+ *
+ * Copyright (C) 2017, Spreadtrum Communications Inc.
+ *
+ * SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+ */
+
+/dts-v1/;
+
+#include "sc9860.dtsi"
+
+/ {
+ model = "Spreadtrum SP9860G 3GFHD Board";
+
+ compatible = "sprd,sp9860g-1h10", "sprd,sc9860";
+
+ aliases {
+ serial0 = &uart0; /* for Bluetooth */
+ serial1 = &uart1; /* UART console */
+ serial2 = &uart2; /* Reserved */
+ serial3 = &uart3; /* for GPS */
+ };
+
+ memory{
+ device_type = "memory";
+ reg = <0x0 0x80000000 0 0x60000000>,
+ <0x1 0x80000000 0 0x60000000>;
+ };
+
+ chosen {
+ stdout-path = "serial1:115200n8";
+ };
+
+ reserved-memory {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+ };
+};
+
+&uart0 {
+ status = "okay";
+};
+
+&uart1 {
+ status = "okay";
+};
+
+&uart2 {
+ status = "okay";
+};
+
+&uart3 {
+ status = "okay";
+};
diff --git a/arch/arm64/boot/dts/sprd/whale2.dtsi b/arch/arm64/boot/dts/sprd/whale2.dtsi
new file mode 100644
index 0000000..7c217c5
--- /dev/null
+++ b/arch/arm64/boot/dts/sprd/whale2.dtsi
@@ -0,0 +1,71 @@
+/*
+ * Spreadtrum Whale2 platform peripherals
+ *
+ * Copyright (C) 2016, Spreadtrum Communications Inc.
+ *
+ * SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+ */
+
+/ {
+ interrupt-parent = <&gic>;
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ soc: soc {
+ compatible = "simple-bus";
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ ap-apb {
+ compatible = "simple-bus";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0 0x0 0x70000000 0x10000000>;
+
+ uart0: serial at 0 {
+ compatible = "sprd,sc9860-uart",
+ "sprd,sc9836-uart";
+ reg = <0x0 0x100>;
+ interrupts = <GIC_SPI 2 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&ext_26m>;
+ status = "disabled";
+ };
+
+ uart1: serial at 100000 {
+ compatible = "sprd,sc9860-uart",
+ "sprd,sc9836-uart";
+ reg = <0x100000 0x100>;
+ interrupts = <GIC_SPI 3 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&ext_26m>;
+ status = "disabled";
+ };
+
+ uart2: serial at 200000 {
+ compatible = "sprd,sc9860-uart",
+ "sprd,sc9836-uart";
+ reg = <0x200000 0x100>;
+ interrupts = <GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&ext_26m>;
+ status = "disabled";
+ };
+
+ uart3: serial at 300000 {
+ compatible = "sprd,sc9860-uart",
+ "sprd,sc9836-uart";
+ reg = <0x300000 0x100>;
+ interrupts = <GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&ext_26m>;
+ status = "disabled";
+ };
+ };
+
+ };
+
+ ext_26m: ext-26m {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <26000000>;
+ clock-output-names = "ext_26m";
+ };
+};
--
2.7.4
^ permalink raw reply related
* [PATCH 3/3] ARM: sun8i: a83t: Rename pinmux setting names
From: Chen-Yu Tsai @ 2017-04-21 3:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170418042205.27894-4-wens@csie.org>
On Tue, Apr 18, 2017 at 12:22 PM, Chen-Yu Tsai <wens@csie.org> wrote:
> The pinmux setting nodes all have an address element in their node
> names, however the pinctrl node does not have #address-cells.
>
> Rename the existing pinmux setting nodes and labels in sun8i-a83t.dtsi,
> dropping identifiers for functions that only have one possible setting,
> and using the pingroup name if the function is identically available on
> different pingroups.
>
> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
> ---
> arch/arm/boot/dts/sun8i-a83t-allwinner-h8homlet-v2.dts | 2 +-
> arch/arm/boot/dts/sun8i-a83t-cubietruck-plus.dts | 2 +-
> arch/arm/boot/dts/sun8i-a83t.dtsi | 10 +++++-----
> 3 files changed, 7 insertions(+), 7 deletions(-)
>
[...]
> diff --git a/arch/arm/boot/dts/sun8i-a83t.dtsi b/arch/arm/boot/dts/sun8i-a83t.dtsi
> index 82cb87f21b96..87b99338716b 100644
> --- a/arch/arm/boot/dts/sun8i-a83t.dtsi
> +++ b/arch/arm/boot/dts/sun8i-a83t.dtsi
> @@ -174,7 +174,7 @@
> #interrupt-cells = <3>;
> #gpio-cells = <3>;
>
> - mmc0_pins_a: mmc0 at 0 {
> + mmc0_pins: mmc0_pins {
> pins = "PF0", "PF1", "PF2",
> "PF3", "PF4", "PF5";
> function = "mmc0";
> @@ -182,13 +182,13 @@
> bias-pull-up;
> };
>
> - uart0_pins_a: uart0 at 0 {
> - pins = "PF2", "PF4";
> + uart0_pb_pins: uart0_pb_pins {
Duh... Forgot to use hyphens instead of underscores in the node names.
I'll send a patch for you to squash in.
ChenYu
> + pins = "PB9", "PB10";
> function = "uart0";
> };
>
> - uart0_pins_b: uart0 at 1 {
> - pins = "PB9", "PB10";
> + uart0_pf_pins: uart0_pf_pins {
> + pins = "PF2", "PF4";
> function = "uart0";
> };
> };
> --
> 2.11.0
>
^ permalink raw reply
* [PATCH 2/5] mtd: nand: gpmi: add i.MX 7 SoC support
From: Stefan Agner @ 2017-04-21 3:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <af3fe671-c5fb-d3cf-c891-e6b7c973baa1@gmail.com>
On 2017-04-20 19:03, Marek Vasut wrote:
> On 04/21/2017 03:07 AM, Stefan Agner wrote:
>> Add support for i.MX 7 SoC. The i.MX 7 has a slightly different
>> clock architecture requiring only two clocks to be referenced.
>> The IP is slightly different compared to i.MX 6SoloX, but currently
>> none of this differences are in use so there is no detection needed
>> and the driver can reuse IS_MX6SX.
>>
>> Signed-off-by: Stefan Agner <stefan@agner.ch>
>> ---
>> drivers/mtd/nand/gpmi-nand/gpmi-nand.c | 15 +++++++++++++++
>> 1 file changed, 15 insertions(+)
>>
>> diff --git a/drivers/mtd/nand/gpmi-nand/gpmi-nand.c b/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
>> index c8bbf5da2ab8..4a45d37ddc80 100644
>> --- a/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
>> +++ b/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
>> @@ -127,6 +127,18 @@ static const struct gpmi_devdata gpmi_devdata_imx6sx = {
>> .clks_count = ARRAY_SIZE(gpmi_clks_for_mx6),
>> };
>>
>> +static const char * const gpmi_clks_for_mx7d[] = {
>> + "gpmi_io", "gpmi_bch_apb",
>> +};
>> +
>> +static const struct gpmi_devdata gpmi_devdata_imx7d = {
>> + .type = IS_MX6SX,
>
> Would it make sense to use IS_MX7 here already to prevent future surprises ?
>
Yeah I was thinking we can do it once we have an actual reason to
distinguish.
But then, adding the type would only require 2-3 lines of change if I
add it to the GPMI_IS_MX6 macro...
--
Stefan
>> + .bch_max_ecc_strength = 62,
>> + .max_chain_delay = 12,
>> + .clks = gpmi_clks_for_mx7d,
>> + .clks_count = ARRAY_SIZE(gpmi_clks_for_mx7d),
>> +};
>> +
>> static irqreturn_t bch_irq(int irq, void *cookie)
>> {
>> struct gpmi_nand_data *this = cookie;
>> @@ -2071,6 +2083,9 @@ static const struct of_device_id gpmi_nand_id_table[] = {
>> }, {
>> .compatible = "fsl,imx6sx-gpmi-nand",
>> .data = &gpmi_devdata_imx6sx,
>> + }, {
>> + .compatible = "fsl,imx7d-gpmi-nand",
>> + .data = &gpmi_devdata_imx7d,
>> }, {}
>> };
>> MODULE_DEVICE_TABLE(of, gpmi_nand_id_table);
>>
^ permalink raw reply
* [PATCH 0/5] mtd: nand: gpmi: add i.MX 7 support
From: Marek Vasut @ 2017-04-21 2:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170421010755.18025-1-stefan@agner.ch>
On 04/21/2017 03:07 AM, Stefan Agner wrote:
> This patchset adds support for i.MX 7 SoC for the GPMI NAND controller.
> There have been similar patchsets already:
> https://lkml.org/lkml/2016/2/23/912
>
> However, this patchset does not make use of any of the new features.
> The current feature set seems to work fine, I successfully run the MTD
> tests on a Colibri iMX7.
>
> --
The rest of the patchset is IMO OK too, but you probably want the DT
changes Acked by Shawn or Fabio.
--
Best regards,
Marek Vasut
^ permalink raw reply
* [PATCH V8 5/6] ACPI: Support the probing on the devices which apply indirect-IO
From: zhichang.yuan @ 2017-04-21 2:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CALdTtnuO=592n+PoR_kkdTyeFYRd90VyPf0JLwnEo7DtXwzoPA@mail.gmail.com>
Hi, Dann,
On 04/21/2017 04:57 AM, dann frazier wrote:
> On Thu, Mar 30, 2017 at 9:26 AM, zhichang.yuan
> <yuanzhichang@hisilicon.com> wrote:
>> On some platforms(such as Hip06/Hip07), the legacy ISA/LPC devices access I/O
>> with some special host-local I/O ports known on x86. To access the I/O
>> peripherals, an indirect-IO mechanism is introduced to mapped the host-local
>> I/O to system logical/fake PIO similar the PCI MMIO on architectures where no
>> separate I/O space exists. Just as PCI MMIO, the host I/O range should be
>> registered before probing the downstream devices and set up the I/O mapping.
>> But current ACPI bus probing doesn't support these indirect-IO hosts/devices.
>>
>> This patch introdueces a new ACPI handler for this device category. Through the
>> handler attach callback, the indirect-IO hosts I/O registration is done and
>> all peripherals' I/O resources are translated into logic/fake PIO before
>> starting the enumeration.
>>
>> Signed-off-by: zhichang.yuan <yuanzhichang@hisilicon.com>
>> Signed-off-by: Gabriele Paoloni <gabriele.paoloni@huawei.com>
>> ---
>> drivers/acpi/Makefile | 1 +
>> drivers/acpi/acpi_indirectio.c | 344 +++++++++++++++++++++++++++++++++++++++++
>> drivers/acpi/internal.h | 5 +
>> drivers/acpi/scan.c | 1 +
>> 4 files changed, 351 insertions(+)
>> create mode 100644 drivers/acpi/acpi_indirectio.c
>>
>> diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
>> index a391bbc..10e5f2b 100644
>> --- a/drivers/acpi/Makefile
>> +++ b/drivers/acpi/Makefile
>> @@ -57,6 +57,7 @@ acpi-$(CONFIG_ACPI_PROCFS_POWER) += cm_sbs.o
>> acpi-y += acpi_lpat.o
>> acpi-$(CONFIG_ACPI_GENERIC_GSI) += irq.o
>> acpi-$(CONFIG_ACPI_WATCHDOG) += acpi_watchdog.o
>> +acpi-$(CONFIG_INDIRECT_PIO) += acpi_indirectio.o
>>
>> # These are (potentially) separate modules
>>
>> diff --git a/drivers/acpi/acpi_indirectio.c b/drivers/acpi/acpi_indirectio.c
>> new file mode 100644
>> index 0000000..c8c80b5
>> --- /dev/null
>> +++ b/drivers/acpi/acpi_indirectio.c
>> @@ -0,0 +1,344 @@
[snip]
>> +acpi_build_logiciores_template(struct acpi_device *adev,
>> + struct acpi_buffer *buffer)
>> +{
>> + acpi_handle handle = adev->handle;
>> + struct acpi_resource *resource;
>> + acpi_status status;
>> + int res_cnt = 0;
>> +
>> + status = acpi_walk_resources(handle, METHOD_NAME__CRS,
>> + acpi_count_logiciores, &res_cnt);
>> + if (ACPI_FAILURE(status) || !res_cnt) {
>> + dev_err(&adev->dev, "can't evaluate _CRS: %d\n", status);
>> + return -EINVAL;
>> + }
>> +
>> + buffer->length = sizeof(struct acpi_resource) * (res_cnt + 1) + 1;
>> + buffer->pointer = kzalloc(buffer->length - 1, GFP_KERNEL);
>
> (Seth Forshee noticed this issue, just passing it on)
>
> Should this just allocate the full buffer->length? That would keep the
> length attribute accurate (possibly avoiding an off-by-1 error later).
> It's not clear what the trailing byte is needed for, but other drivers
> allocate it as well (drivers/acpi/pci_link.c and
> drivers/platform/x86/sony-laptop.c).
Thanks for your suggestion!
I also curious why this one appended byte is needed as it seems the later
acpi_set_current_resources() doesn't use this byte.
And I tested without setting the buffer->length as the length of resource list
directly, it seems ok.
But anyway, it looks more reasonable to allocate the memory with the
buffer->length rather than buffer->length - 1;
I was made the V9 patch-set, and I can add your suggestion there. But I also
awaiting for ARM64 ACPI maintainer's comment about this patch before really
sending V9. I wonder whether there is better way to make our indirect-IO devices
can be assigned the logic PIO before the enumeration...
Lorenzo, Hanjun, what do you think about this patch?
Thanks,
Zhichang
>
> -dann
>
^ permalink raw reply
* [GIT PULL] ARM: aspeed: defconfig for 4.12
From: Joel Stanley @ 2017-04-21 2:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170419140639.GO29219@localhost>
On Wed, Apr 19, 2017 at 11:36 PM, Olof Johansson <olof@lixom.net> wrote:
> On Wed, Apr 12, 2017 at 12:29:10PM +0930, Joel Stanley wrote:
>> Hello Arnd, Olof,
>>
>> These are the Aspeed defconfig changes for 4.12.
>>
>> The following changes since commit c1ae3cfa0e89fa1a7ecc4c99031f5e9ae99d9201:
>>
>> Linux 4.11-rc1 (2017-03-05 12:59:56 -0800)
>>
>> are available in the git repository at:
>>
>> git://git.kernel.org/pub/scm/linux/kernel/git/joel/aspeed.git
>> tags/aspeed-4.12-defconfig
>>
>> for you to fetch changes up to 97bae47812dbbd220e354bc9f15c3b3c8b481a86:
>>
>> ARM: configs: aspeed: Add new drivers (2017-04-07 15:29:50 +0930)
>>
>> ----------------------------------------------------------------
>> Aspeed defconfig updates for 4.12
>>
>> Add newly unstreamed drivers to the defconfigs for the Aspeed SoCs.
>
> I highly recommend upstreaming drivers instead of unstreaming them. :-)
Good call. Don't cross the streams.
>
>> The defconfigs are reworked to be useful for development and testing
>> of OpenBMC on these systems.
>
> Merged, thanks!
Cheers!
Joel
^ permalink raw reply
* [PATCH] ASoC: mediatek: add I2C dependency for CS42XX8
From: Ryder Lee @ 2017-04-21 2:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170420081541.658178-1-arnd@arndb.de>
On Thu, 2017-04-20 at 10:15 +0200, Arnd Bergmann wrote:
> We should not select drivers that depend on I2C when that is disabled,
> as it results in a build error:
>
> warning: (SND_SOC_MT2701_WM8960) selects SND_SOC_WM8960 which has unmet direct dependencies (SOUND && !M68K && !UML && SND && SND_SOC && I2C)
> sound/soc/codecs/wm8960.c:1469:1: error: data definition has no type or storage class [-Werror]
> sound/soc/codecs/wm8960.c:1469:1: error: type defaults to 'int' in declaration of 'module_i2c_driver' [-Werror=implicit-int]
>
> Fixes: 8625c1dbd876 ("ASoC: mediatek: Add mt2701-wm8960 machine driver")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> sound/soc/mediatek/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/sound/soc/mediatek/Kconfig b/sound/soc/mediatek/Kconfig
> index c6f39040f71f..5c68797f36c4 100644
> --- a/sound/soc/mediatek/Kconfig
> +++ b/sound/soc/mediatek/Kconfig
> @@ -24,7 +24,7 @@ config SND_SOC_MT2701_CS42448
>
> config SND_SOC_MT2701_WM8960
> tristate "ASoc Audio driver for MT2701 with WM8960 codec"
> - depends on SND_SOC_MT2701
> + depends on SND_SOC_MT2701 && I2C
> select SND_SOC_WM8960
> help
> This adds ASoC driver for Mediatek MT2701 boards
Acked-by: Ryder Lee <ryder.lee@mediatek.com>
Thanks
^ permalink raw reply
* linux-next: build failure after merge of the drm-misc tree
From: Stephen Rothwell @ 2017-04-21 2:10 UTC (permalink / raw)
To: linux-arm-kernel
Hi all,
After merging the drm-misc tree, today's linux-next build (x86_64
allmodconfig) failed like this:
drivers/tee/tee_shm.c:87:2: error: unknown field 'kmap_atomic' specified in initializer
.kmap_atomic = tee_shm_op_kmap_atomic,
^
drivers/tee/tee_shm.c:87:17: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
.kmap_atomic = tee_shm_op_kmap_atomic,
^
drivers/tee/tee_shm.c:87:17: note: (near initialization for 'tee_shm_dma_buf_ops.begin_cpu_access')
drivers/tee/tee_shm.c:88:2: error: unknown field 'kmap' specified in initializer
.kmap = tee_shm_op_kmap,
^
drivers/tee/tee_shm.c:88:10: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
.kmap = tee_shm_op_kmap,
^
drivers/tee/tee_shm.c:88:10: note: (near initialization for 'tee_shm_dma_buf_ops.end_cpu_access')
Caused by commit
f9b67f0014cb ("dma-buf: Rename dma-ops to prevent conflict with kunmap_atomic macro")
interacting with commit
967c9cca2cc5 ("tee: generic TEE subsystem")
from the arm-soc tree.
I applied the following merge fix patch for today:
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Fri, 21 Apr 2017 12:06:32 +1000
Subject: [PATCH] tee: merge fix for dma-ops field name changes
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
drivers/tee/tee_shm.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/tee/tee_shm.c b/drivers/tee/tee_shm.c
index 0be1e3e93bee..4e14c9c9cb1c 100644
--- a/drivers/tee/tee_shm.c
+++ b/drivers/tee/tee_shm.c
@@ -84,8 +84,8 @@ static struct dma_buf_ops tee_shm_dma_buf_ops = {
.map_dma_buf = tee_shm_op_map_dma_buf,
.unmap_dma_buf = tee_shm_op_unmap_dma_buf,
.release = tee_shm_op_release,
- .kmap_atomic = tee_shm_op_kmap_atomic,
- .kmap = tee_shm_op_kmap,
+ .map_atomic = tee_shm_op_kmap_atomic,
+ .map = tee_shm_op_kmap,
.mmap = tee_shm_op_mmap,
};
--
2.11.0
--
Cheers,
Stephen Rothwell
^ permalink raw reply related
* [PATCH 2/5] mtd: nand: gpmi: add i.MX 7 SoC support
From: Marek Vasut @ 2017-04-21 2:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170421010755.18025-3-stefan@agner.ch>
On 04/21/2017 03:07 AM, Stefan Agner wrote:
> Add support for i.MX 7 SoC. The i.MX 7 has a slightly different
> clock architecture requiring only two clocks to be referenced.
> The IP is slightly different compared to i.MX 6SoloX, but currently
> none of this differences are in use so there is no detection needed
> and the driver can reuse IS_MX6SX.
>
> Signed-off-by: Stefan Agner <stefan@agner.ch>
> ---
> drivers/mtd/nand/gpmi-nand/gpmi-nand.c | 15 +++++++++++++++
> 1 file changed, 15 insertions(+)
>
> diff --git a/drivers/mtd/nand/gpmi-nand/gpmi-nand.c b/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
> index c8bbf5da2ab8..4a45d37ddc80 100644
> --- a/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
> +++ b/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
> @@ -127,6 +127,18 @@ static const struct gpmi_devdata gpmi_devdata_imx6sx = {
> .clks_count = ARRAY_SIZE(gpmi_clks_for_mx6),
> };
>
> +static const char * const gpmi_clks_for_mx7d[] = {
> + "gpmi_io", "gpmi_bch_apb",
> +};
> +
> +static const struct gpmi_devdata gpmi_devdata_imx7d = {
> + .type = IS_MX6SX,
Would it make sense to use IS_MX7 here already to prevent future surprises ?
> + .bch_max_ecc_strength = 62,
> + .max_chain_delay = 12,
> + .clks = gpmi_clks_for_mx7d,
> + .clks_count = ARRAY_SIZE(gpmi_clks_for_mx7d),
> +};
> +
> static irqreturn_t bch_irq(int irq, void *cookie)
> {
> struct gpmi_nand_data *this = cookie;
> @@ -2071,6 +2083,9 @@ static const struct of_device_id gpmi_nand_id_table[] = {
> }, {
> .compatible = "fsl,imx6sx-gpmi-nand",
> .data = &gpmi_devdata_imx6sx,
> + }, {
> + .compatible = "fsl,imx7d-gpmi-nand",
> + .data = &gpmi_devdata_imx7d,
> }, {}
> };
> MODULE_DEVICE_TABLE(of, gpmi_nand_id_table);
>
--
Best regards,
Marek Vasut
^ permalink raw reply
* [PATCH 1/5] mtd: nand: gpmi: unify clock handling
From: Marek Vasut @ 2017-04-21 2:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170421010755.18025-2-stefan@agner.ch>
On 04/21/2017 03:07 AM, Stefan Agner wrote:
> Add device specific list of clocks required, and handle all clocks
> in a single for loop. This avoids further code duplication when
> adding i.MX 7 support.
>
> Signed-off-by: Stefan Agner <stefan@agner.ch>
[...]
> diff --git a/drivers/mtd/nand/gpmi-nand/gpmi-nand.h b/drivers/mtd/nand/gpmi-nand/gpmi-nand.h
> index 4e49a1f5fa27..2e584e18d980 100644
> --- a/drivers/mtd/nand/gpmi-nand/gpmi-nand.h
> +++ b/drivers/mtd/nand/gpmi-nand/gpmi-nand.h
> @@ -130,6 +130,8 @@ struct gpmi_devdata {
> enum gpmi_type type;
> int bch_max_ecc_strength;
> int max_chain_delay; /* See the async EDO mode */
> + const char * const *clks;
> + int clks_count;
const int ? :)
Reviewed-by: Marek Vasut <marek.vasut@gmail.com>
--
Best regards,
Marek Vasut
^ permalink raw reply
* [PATCH v5 1/4] printk/nmi: generic solution for safe printk in NMI
From: Sergey Senozhatsky @ 2017-04-21 1:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170420131154.GL3452@pathway.suse.cz>
Hello,
On (04/20/17 15:11), Petr Mladek wrote:
[..]
> Good analyze. I would summarize it that we need to be careful of:
>
> + logbug_lock
> + PRINTK_SAFE_CONTEXT
> + locks used by console drivers
>
> The first two things are easy to check. Except that a check for logbuf_lock
> might produce false negatives. The last check is very hard.
>
> > so at the moment what I can think of is something like
> >
> > -- check this_cpu_read(printk_context) in NMI prink
> >
> > -- if we are NOT in printk_safe on this CPU, then do printk_deferred()
> > and bypass `nmi_print_seq' buffer
>
> I would add also a check for logbuf_lock.
> > -- if we are in printk_safe
> > -- well... bad luck... have a bigger buffer.
>
> Yup, we do the best effort while still trying to stay on the safe
> side.
>
> I have cooked up a patch based on this. It uses printk_deferred()
> in NMI when it is safe. Note that console_flush_on_panic() will
> try to get them on the console when a kdump is not generated.
> I believe that it will help Steven.
OK. I need to look more at the patch. It does more than I'd expected/imagined.
[..]
> void printk_nmi_enter(void)
> {
> - this_cpu_or(printk_context, PRINTK_NMI_CONTEXT_MASK);
> + /*
> + * The size of the extra per-CPU buffer is limited. Use it
> + * only when really needed.
> + */
> + if (this_cpu_read(printk_context) & PRINTK_SAFE_CONTEXT_MASK ||
> + raw_spin_is_locked(&logbuf_lock)) {
> + this_cpu_or(printk_context, PRINTK_NMI_CONTEXT_MASK);
> + } else {
> + this_cpu_or(printk_context, PRINTK_NMI_DEFERRED_CONTEXT_MASK);
> + }
> }
well... the logbuf_lock can temporarily be locked from another CPU. I'd say
that spin_is_locked() has better chances for false positive than
this_cpu_read(printk_context). because this_cpu_read(printk_context) depends
only on this CPU state, while spin_is_locked() depends on all CPUs. and the
idea with this_cpu_read(printk_context) was that we check if the logbuf_lock
was locked from this particular CPU.
I agree that this_cpu_read(printk_context) covers slightly more than
logbuf_lock scope, so we may get positive this_cpu_read(printk_context)
with unlocked logbuf_lock, but I don't tend to think that it's a big
problem.
wouldn't something as simple as below do the trick?
// absolutely and completely untested //
diff --git a/kernel/printk/printk_safe.c b/kernel/printk/printk_safe.c
index 033e50a7d706..c7477654c5b1 100644
--- a/kernel/printk/printk_safe.c
+++ b/kernel/printk/printk_safe.c
@@ -303,7 +303,10 @@ static int vprintk_nmi(const char *fmt, va_list args)
{
struct printk_safe_seq_buf *s = this_cpu_ptr(&nmi_print_seq);
- return printk_safe_log_store(s, fmt, args);
+ if (this_cpu_read(printk_context) & PRINTK_SAFE_CONTEXT_MASK)
+ return printk_safe_log_store(s, fmt, args);
+
+ return vprintk_emit(0, LOGLEVEL_SCHED, NULL, 0, fmt, args);
}
-ss
^ permalink raw reply related
* [linux-sunxi] Re: [PATCH v2 1/6] clk: sunxi-ng: Add sun4i/sun7i CCU driver
From: Chen-Yu Tsai @ 2017-04-21 1:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170420195917.GA16113@plaes.org>
On Fri, Apr 21, 2017 at 3:59 AM, Priit Laes <plaes@plaes.org> wrote:
> On Fri, Apr 07, 2017 at 03:38:05PM +0200, Maxime Ripard wrote:
>> Hi Priit,
>>
>> On Tue, Apr 04, 2017 at 08:09:19PM +0000, Priit Laes wrote:
>> > > > +/* Not documented on A10 */
>> > > > +static SUNXI_CCU_GATE(pll_periph_sata_clk, "pll-periph-sata", "pll-periph",
>> > > > + 0x028, BIT(14), 0);
>> > >
>> > > The rate doesn't come from pll-periph directly, does it?
>> >
>> > So it uses hosc (24MHz parent clock) instead of pll-periph?
>>
>> I never looked too much at this, but it looks more like the input is
>> pll-periph-sata itself.
>
> OK, I think I have now fixed most of the issues thanks to Maxime and Chen-Yu
> and I'm almost ready to send out V3.
>
> From my side there is only single issue remaining - how to create "sata-ext"
> clock?
>
> [snip]
> static struct ccu_div pll_periph_sata_clk = {
> .enable = BIT(14),
> .div = _SUNXI_CCU_DIV(0, 2),
> .common = {
> .prediv = 6,
> .reg = 0x028,
> .features = CCU_FEATURE_ALL_PREDIV,
> .hw.init = CLK_HW_INIT("pll-periph-sata",
> "pll-periph-base",
> &ccu_nk_ops, 0),
> },
> };
>
> static const char* const sata_parents[] = {"pll-periph-sata", "sata-ext"};
> static SUNXI_CCU_MUX_WITH_GATE(sata_clk, "sata", sata_parents,
> 0x0c8, 24, 1, BIT(31), 0);
> [/snip]
>
> Should I create a fixed-clock node in the dtsi:
>
> sata-ext: clk at 0 {
> #clock-cells = <0>;
> compatible = "fixed-clock";
> clock-frequency = <200000000>;
> clock-output-names = "sata-ext";
> };
You can just leave it missing. You probably shouldn't register it
if it's not populated. The clk core can cope with missing parents,
as long as they aren't all missing.
>
> And would it also need pio definition?
Nope. It has dedicated pins.
ChenYu
^ permalink raw reply
* [PATCH 4/4] mmc: pxamci: Fix race condition between pxamci_dma_irq() and pxamci_irq()
From: Petr Cvek @ 2017-04-21 1:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87fuh46w3r.fsf@belgarion.home>
Dne 19.4.2017 v 21:22 Robert Jarzmik napsal(a):
> Petr Cvek <petr.cvek@tul.cz> writes:
>
>> The data write requests may require an FIFO flush when the DMA transaction
>> ends. This is handled by a DMA callback pxamci_dma_irq(). After flushing
>> the FIFO the MCI controller generates the DATA_TRAN_DONE interrupt.
>>
>> Problem is the DATA_TRAN_DONE interrupt will be generated when the write
>> data length is divisible by the FIFO size (no flush is required). And in
>> this case the DMA callback can be called long time after the
>> DATA_TRAN_DONE interrupt (as the DMA callback is realised by a tasklet,
>> it can even stack). When the DMA callback is finally called there can
>> already be a different type of the transaction (another data read or write
>> request).
>>
>> The dmaengine_tx_status() will be called for a wrong DMA transaction and
>> in some case it returns DMA_IN_PROGRESS, which the code recognize as
>> an error and ends a running DMA and halts the MCI controller.
>>
>> The problem presents itself under heavy (interrupt) load with a high MCI
>> traffic with this message:
>>
>> mmc0: DMA error on tx channel
>>
>> The fix must obey these situations:
>> - Any command will erase the FIFO
>> - Data writes divisible by the FIFO size will (probably) automatically
>> generate a DATA_TRAN_DONE interrupt
>> - Data writes with a nonzero FIFO remainder must be flushed and then MCI
>> generates a DATA_TRAN_DONE interrupt
>> - Data reads do not require a flush but they will generate
>> a DATA_TRAN_DONE interrupt
>>
>> The fix changes the DATA_TRAN_DONE interrupt enable from read/write
>> requests to read requests. The DATA_TRAN_DONE interrupt for a write
>> request is enabled in the DMA callback, this assures a DATA_TRAN_DONE
>> interrupt will be always called after a callback (with or without an FIFO
>> flush).
>
> I'm a bit concerned with the way this patch works.
> What bothers me is the re-enabling of the interrupt source in the DMA completion
> path, ie. in pxamci_dma_irq().
> For example, imagine :
> - the tran_done bit is left set (for whatever reason)
You mean DATA_TRAN_DONE flag? The datasheet (page for reg MMC_STAT) says it is cleared at the start of the every command sequence. So inside pxamci_data_done() it can stay only activated in the case of an error (after dropping the third patch of this patchset "Disable DATA_TRAN_DONE interrupt sooner") or in the case of no STOP command.
> - a new transation is queued
In the case of pxa27x the TX DMA (the one with a callback and patched behavior) will start only after the end of the command sequence. But I see, there could be a problem outside the PXA27x SoC (PXA3xx?) as in that case the DMA is started (dma_async_issue_pending()) before the command sequence.
> - the DMA finishes, but not the last request
That would be a problem on itself because the MCI flushes the FIFO at the every command. Anyway if the DATA_TRAN_DONE flag was left as "1" from the previous transaction. It should cause an interrupt in the original driver version before applying my patch too. If I'm right (and it is possible I'm not) your situation is independent to my patch.
> - the pxamci_enable_irq() enables the interrupt, which fires right away even if
> the tran_done for this interrupt wasn't yet set
>
Maybe we can add some sanity checks in the pxamci_finish_request() or at the start of pxamci_request().
> I will need a bit more time to think this one through, as I'm not yet set about
> all the consequences. That shouldn't prevent you from pushing for reviews of
> these patches of course, as I think this serie (or an equivalent) is required to
> fix the current race condition.
Well during the bug hunting and reading the documentation I was wondering if a hardware could be designed to be incompatible with the kernel subsystems ;-).
>
> As this is the last patch, I wonder if this serie is bisectable, especially is
> patch 1/4 self contained ?
Applying only the patch 1/4 itself should not change the behavior at all if the mmc core sends only "01" and "10" in these bit fields. The exact way I've found it was that I traced the callback and found it assigns:
chan = host->dma_chan_rx;
even though it is called only for the TX. I have checked the flags definitions and found they are not a single bit and changed it to more descriptive if(){} (why negate the read if there is write AND they are not mutually exclusive AND callback is for write).
The patches 1, 1+2, 1+2+3 should boot, but the MMC will of course fail as only the 4 repairs it. Do you want me to send them independently? (or I can sort them that the race condition repair is the first one)
>
> Cheers.
>
> --
> Robert
>
^ permalink raw reply
* [PATCH 5/5] ARM: dts: imx7-colibri: add NAND support
From: Stefan Agner @ 2017-04-21 1:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170421010755.18025-1-stefan@agner.ch>
The Colibri iMX7 modules come with 512MB on-module SLC NAND flash
populated. Make use of it by enabling the GPMI controller.
Signed-off-by: Stefan Agner <stefan@agner.ch>
---
arch/arm/boot/dts/imx7-colibri.dtsi | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/arch/arm/boot/dts/imx7-colibri.dtsi b/arch/arm/boot/dts/imx7-colibri.dtsi
index 2d87489f9105..ad4ce19d455b 100644
--- a/arch/arm/boot/dts/imx7-colibri.dtsi
+++ b/arch/arm/boot/dts/imx7-colibri.dtsi
@@ -106,6 +106,15 @@
fsl,magic-packet;
};
+&gpmi {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_gpmi_nand>;
+ fsl,use-minimum-ecc;
+ nand-on-flash-bbt;
+ nand-ecc-mode = "hw";
+ status = "okay";
+};
+
&i2c1 {
clock-frequency = <100000>;
pinctrl-names = "default";
--
2.12.2
^ 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