* Re: [BOOTWRAPPER PATCH] Enable TME for lower exception levels
From: Mark Rutland @ 2019-08-27 11:08 UTC (permalink / raw)
To: Will Deacon; +Cc: linux-arm-kernel
In-Reply-To: <20190823145015.15974-1-will@kernel.org>
On Fri, Aug 23, 2019 at 03:50:15PM +0100, Will Deacon wrote:
> By default, TME is not available to exception levels below EL3, so
> enable it in SCR_EL3 if we detect that it is implemented.
>
> Signed-off-by: Will Deacon <will@kernel.org>
Applied, thanks!
Mark.
> ---
> arch/aarch64/boot.S | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/arch/aarch64/boot.S b/arch/aarch64/boot.S
> index 74705cded338..c2fe92c90297 100644
> --- a/arch/aarch64/boot.S
> +++ b/arch/aarch64/boot.S
> @@ -48,6 +48,13 @@ _start:
> orr x0, x0, #(1 << 16) // AP key enable
> orr x0, x0, #(1 << 17) // AP insn enable
> 1:
> + /* Enable TME if present */
> + mrs x1, id_aa64isar0_el1
> + ubfx x1, x1, #24, #4
> + cbz x1, 1f
> +
> + orr x0, x0, #(1 << 34) // TME enable
> +1:
> #ifndef KERNEL_32
> orr x0, x0, #(1 << 10) // 64-bit EL2
> #endif
> --
> 2.11.0
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v4 1/7] perf: arm64: Add test to check userspace access to hardware counters.
From: Jonathan Cameron @ 2019-08-27 11:17 UTC (permalink / raw)
To: Raphael Gault
Cc: mark.rutland, raph.gault+kdev, peterz, catalin.marinas,
will.deacon, linux-kernel, acme, mingo, linux-arm-kernel
In-Reply-To: <20190822144220.27860-2-raphael.gault@arm.com>
On Thu, 22 Aug 2019 15:42:14 +0100
Raphael Gault <raphael.gault@arm.com> wrote:
> This test relies on the fact that the PMU registers are accessible
> from userspace. It then uses the perf_event_mmap_page to retrieve
> the counter index and access the underlying register.
>
> This test uses sched_setaffinity(2) in order to run on all CPU and thus
> check the behaviour of the PMU of all cpus in a big.LITTLE environment.
>
> Signed-off-by: Raphael Gault <raphael.gault@arm.com>
Hi Raphael,
I just tested this on 1620 and it works fairly nicely with one exception...
The test will run and generate garbage numbers if the rest of the
series isn't yet applied to the kernel. Is there anything we can do
to prevent that?
It's a slightly silly complaint, but this also take a while compared to all
the other tests if you have lots of cores, so maybe a slightly shorter
test?
Thanks,
Jonathan
> ---
> tools/perf/arch/arm64/include/arch-tests.h | 7 +
> tools/perf/arch/arm64/tests/Build | 1 +
> tools/perf/arch/arm64/tests/arch-tests.c | 4 +
> tools/perf/arch/arm64/tests/user-events.c | 254 +++++++++++++++++++++
> 4 files changed, 266 insertions(+)
> create mode 100644 tools/perf/arch/arm64/tests/user-events.c
>
> diff --git a/tools/perf/arch/arm64/include/arch-tests.h b/tools/perf/arch/arm64/include/arch-tests.h
> index 90ec4c8cb880..6a8483de1015 100644
> --- a/tools/perf/arch/arm64/include/arch-tests.h
> +++ b/tools/perf/arch/arm64/include/arch-tests.h
> @@ -2,11 +2,18 @@
> #ifndef ARCH_TESTS_H
> #define ARCH_TESTS_H
>
> +#include <linux/compiler.h>
> +
> #ifdef HAVE_DWARF_UNWIND_SUPPORT
> struct thread;
> struct perf_sample;
> +int test__arch_unwind_sample(struct perf_sample *sample,
> + struct thread *thread);
> #endif
>
> extern struct test arch_tests[];
> +int test__rd_pmevcntr(struct test *test __maybe_unused,
> + int subtest __maybe_unused);
> +
>
> #endif
> diff --git a/tools/perf/arch/arm64/tests/Build b/tools/perf/arch/arm64/tests/Build
> index a61c06bdb757..3f9a20c17fc6 100644
> --- a/tools/perf/arch/arm64/tests/Build
> +++ b/tools/perf/arch/arm64/tests/Build
> @@ -1,4 +1,5 @@
> perf-y += regs_load.o
> perf-$(CONFIG_DWARF_UNWIND) += dwarf-unwind.o
>
> +perf-y += user-events.o
> perf-y += arch-tests.o
> diff --git a/tools/perf/arch/arm64/tests/arch-tests.c b/tools/perf/arch/arm64/tests/arch-tests.c
> index 5b1543c98022..57df9b89dede 100644
> --- a/tools/perf/arch/arm64/tests/arch-tests.c
> +++ b/tools/perf/arch/arm64/tests/arch-tests.c
> @@ -10,6 +10,10 @@ struct test arch_tests[] = {
> .func = test__dwarf_unwind,
> },
> #endif
> + {
> + .desc = "User counter access",
> + .func = test__rd_pmevcntr,
> + },
> {
> .func = NULL,
> },
> diff --git a/tools/perf/arch/arm64/tests/user-events.c b/tools/perf/arch/arm64/tests/user-events.c
> new file mode 100644
> index 000000000000..b048d7e392bc
> --- /dev/null
> +++ b/tools/perf/arch/arm64/tests/user-events.c
> @@ -0,0 +1,254 @@
> +// SPDX-License-Identifier: GPL-2.0
> +#include <asm/bug.h>
> +#include <errno.h>
> +#include <unistd.h>
> +#include <sched.h>
> +#include <stdlib.h>
> +#include <signal.h>
> +#include <sys/mman.h>
> +#include <sys/sysinfo.h>
> +#include <sys/types.h>
> +#include <sys/wait.h>
> +#include <linux/types.h>
> +#include "perf.h"
> +#include "debug.h"
> +#include "tests/tests.h"
> +#include "cloexec.h"
> +#include "util.h"
> +#include "arch-tests.h"
> +
> +/*
> + * ARMv8 ARM reserves the following encoding for system registers:
> + * (Ref: ARMv8 ARM, Section: "System instruction class encoding overview",
> + * C5.2, version:ARM DDI 0487A.f)
> + * [20-19] : Op0
> + * [18-16] : Op1
> + * [15-12] : CRn
> + * [11-8] : CRm
> + * [7-5] : Op2
> + */
> +#define Op0_shift 19
> +#define Op0_mask 0x3
> +#define Op1_shift 16
> +#define Op1_mask 0x7
> +#define CRn_shift 12
> +#define CRn_mask 0xf
> +#define CRm_shift 8
> +#define CRm_mask 0xf
> +#define Op2_shift 5
> +#define Op2_mask 0x7
> +
> +#define __stringify(x) #x
> +
> +#define read_sysreg(r) ({ \
> + u64 __val; \
> + asm volatile("mrs %0, " __stringify(r) : "=r" (__val)); \
> + __val; \
> +})
> +
> +#define PMEVCNTR_READ_CASE(idx) \
> + case idx: \
> + return read_sysreg(pmevcntr##idx##_el0)
> +
> +#define PMEVCNTR_CASES(readwrite) \
> + PMEVCNTR_READ_CASE(0); \
> + PMEVCNTR_READ_CASE(1); \
> + PMEVCNTR_READ_CASE(2); \
> + PMEVCNTR_READ_CASE(3); \
> + PMEVCNTR_READ_CASE(4); \
> + PMEVCNTR_READ_CASE(5); \
> + PMEVCNTR_READ_CASE(6); \
> + PMEVCNTR_READ_CASE(7); \
> + PMEVCNTR_READ_CASE(8); \
> + PMEVCNTR_READ_CASE(9); \
> + PMEVCNTR_READ_CASE(10); \
> + PMEVCNTR_READ_CASE(11); \
> + PMEVCNTR_READ_CASE(12); \
> + PMEVCNTR_READ_CASE(13); \
> + PMEVCNTR_READ_CASE(14); \
> + PMEVCNTR_READ_CASE(15); \
> + PMEVCNTR_READ_CASE(16); \
> + PMEVCNTR_READ_CASE(17); \
> + PMEVCNTR_READ_CASE(18); \
> + PMEVCNTR_READ_CASE(19); \
> + PMEVCNTR_READ_CASE(20); \
> + PMEVCNTR_READ_CASE(21); \
> + PMEVCNTR_READ_CASE(22); \
> + PMEVCNTR_READ_CASE(23); \
> + PMEVCNTR_READ_CASE(24); \
> + PMEVCNTR_READ_CASE(25); \
> + PMEVCNTR_READ_CASE(26); \
> + PMEVCNTR_READ_CASE(27); \
> + PMEVCNTR_READ_CASE(28); \
> + PMEVCNTR_READ_CASE(29); \
> + PMEVCNTR_READ_CASE(30)
> +
> +/*
> + * Read a value direct from PMEVCNTR<idx>
> + */
> +static u64 read_evcnt_direct(int idx)
> +{
> + switch (idx) {
> + PMEVCNTR_CASES(READ);
> + default:
> + WARN_ON(1);
> + }
> +
> + return 0;
> +}
> +
> +static u64 mmap_read_self(void *addr)
> +{
> + struct perf_event_mmap_page *pc = addr;
> + u32 seq, idx, time_mult = 0, time_shift = 0;
> + u64 count, cyc = 0, time_offset = 0, enabled, running, delta;
> +
> + do {
> + seq = READ_ONCE(pc->lock);
> + barrier();
> +
> + enabled = READ_ONCE(pc->time_enabled);
> + running = READ_ONCE(pc->time_running);
> +
> + if (enabled != running) {
> + cyc = read_sysreg(cntvct_el0);
> + time_mult = READ_ONCE(pc->time_mult);
> + time_shift = READ_ONCE(pc->time_shift);
> + time_offset = READ_ONCE(pc->time_offset);
> + }
> +
> + idx = READ_ONCE(pc->index);
> + count = READ_ONCE(pc->offset);
> + if (idx)
> + count += read_evcnt_direct(idx - 1);
> +
> + barrier();
> + } while (READ_ONCE(pc->lock) != seq);
> +
> + if (enabled != running) {
> + u64 quot, rem;
> +
> + quot = (cyc >> time_shift);
> + rem = cyc & (((u64)1 << time_shift) - 1);
> + delta = time_offset + quot * time_mult +
> + ((rem * time_mult) >> time_shift);
> +
> + enabled += delta;
> + if (idx)
> + running += delta;
> +
> + quot = count / running;
> + rem = count % running;
> + count = quot * enabled + (rem * enabled) / running;
> + }
> +
> + return count;
> +}
> +
> +static int __test__rd_pmevcntr(void)
> +{
> + volatile int tmp = 0;
> + u64 i, loops = 1000;
> + int n;
> + int fd;
> + void *addr;
> + struct perf_event_attr attr = {
> + .type = PERF_TYPE_HARDWARE,
> + .config = PERF_COUNT_HW_INSTRUCTIONS,
> + .exclude_kernel = 1,
> + };
> + u64 delta_sum = 0;
> + char sbuf[STRERR_BUFSIZE];
> +
> + fd = sys_perf_event_open(&attr, 0, -1, -1,
> + perf_event_open_cloexec_flag());
> + if (fd < 0) {
> + pr_err("Error: sys_perf_event_open() syscall returned with %d (%s)\n", fd,
> + str_error_r(errno, sbuf, sizeof(sbuf)));
> + return -1;
> + }
> +
> + addr = mmap(NULL, page_size, PROT_READ, MAP_SHARED, fd, 0);
> + if (addr == (void *)(-1)) {
> + pr_err("Error: mmap() syscall returned with (%s)\n",
> + str_error_r(errno, sbuf, sizeof(sbuf)));
> + goto out_close;
> + }
> +
> + for (n = 0; n < 6; n++) {
> + u64 stamp, now, delta;
> +
> + stamp = mmap_read_self(addr);
> +
> + for (i = 0; i < loops; i++)
> + tmp++;
> +
> + now = mmap_read_self(addr);
> + loops *= 10;
> +
> + delta = now - stamp;
> + pr_debug("%14d: %14llu\n", n, (long long)delta);
> +
> + delta_sum += delta;
> + }
> +
> + munmap(addr, page_size);
> + pr_debug(" ");
> +
> +out_close:
> + close(fd);
> +
> + if (!delta_sum)
> + return -1;
> +
> + return 0;
> +}
> +
> +int test__rd_pmevcntr(struct test __maybe_unused *test,
> + int __maybe_unused subtest)
> +{
> + int status = 0;
> + int wret = 0;
> + int ret = 0;
> + int pid;
> + int cpu;
> + cpu_set_t cpu_set;
> +
> + pid = fork();
> + if (pid < 0)
> + return -1;
> +
> + if (!pid) {
> + for (cpu = 0; cpu < get_nprocs(); cpu++) {
> + pr_info("setting affinity to cpu: %d\n", cpu);
> + CPU_ZERO(&cpu_set);
> + CPU_SET(cpu, &cpu_set);
> + if (sched_setaffinity(getpid(),
> + sizeof(cpu_set),
> + &cpu_set) == -1) {
> + pr_err("Error: impossible to set cpu (%d) affinity\n",
> + cpu);
> + continue;
> + }
> + ret = __test__rd_pmevcntr();
> + }
> + exit(ret);
> + }
> +
> + wret = waitpid(pid, &status, 0);
> + if (wret < 0)
> + return -1;
> +
> + if (WIFSIGNALED(status)) {
> + pr_err("Error: the child process was interrupted by a signal\n");
> + return -1;
> +
> + if (WIFEXITED(status) && WEXITSTATUS(status)) {
> + pr_err("Error: the child process exited with: %d\n",
> + WEXITSTATUS(status));
> + return -1;
> + }
> +
> + return 0;
> +}
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] fdt: Update CRC check for rng-seed
From: Geert Uytterhoeven @ 2019-08-27 11:19 UTC (permalink / raw)
To: Hsin-Yi Wang; +Cc: Linux-Renesas, Will Deacon, Linux ARM
In-Reply-To: <20190827103353.109218-1-hsinyi@chromium.org>
Hi Hsin-Yi,
Thanks for the prompt fix!
On Tue, Aug 27, 2019 at 12:34 PM Hsin-Yi Wang <hsinyi@chromium.org> wrote:
> Commit 428826f5358c ("fdt: add support for rng-seed") moves of_fdt_crc32
> from early_init_dt_verify() to early_init_dt_scan() since
> early_init_dt_scan_chosen() may modify fdt to erase rng-seed.
>
> However, arm and some other arch won't call early_init_dt_scan(), they
> call early_init_dt_verify() then early_init_dt_scan_nodes().
>
> Restore of_fdt_crc32 to early_init_dt_verify() then update it in
> early_init_dt_scan_chosen() if fdt if updated.
>
> Fixes: 428826f5358c ("fdt: add support for rng-seed")
Reported-by: Geert Uytterhoeven <geert+renesas@glider.be>
> Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org>
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] usb: dwc3: Add shutdown to platform_driver
From: Vicente Bergas @ 2019-08-27 11:45 UTC (permalink / raw)
To: Felipe Balbi, Robin Murphy
Cc: Matthias Brugger, Heiko Stuebner, MarcZyngier, Catalin Marinas,
linux-usb, Will Deacon, linux-rockchip, Greg Kroah-Hartman,
linux-arm-kernel
In-Reply-To: <20190817174140.6394-1-vicencb@gmail.com>
On Saturday, August 17, 2019 7:41:40 PM CEST, Vicente Bergas wrote:
> Otherwise the device keeps writing to memory after kexec and disturbs
> the next kernel.
>
> Signed-off-by: Vicente Bergas <vicencb@gmail.com>
> ---
> drivers/usb/dwc3/dwc3-of-simple.c | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> Hi Felipe, Robin,
> this version calls 'remove' from 'shutdown' instead of just asserting
> a reset because it looks like a cleaner way to stop the device.
>
> Calling remove from shutdown in core.c instead of dwc3-of-simple.c does not
> fix the issue either.
>
> It has been tested on the sapphire board, a RK3399 platform.
>
> Regards,
> Vicenç.
>
> diff --git a/drivers/usb/dwc3/dwc3-of-simple.c
> b/drivers/usb/dwc3/dwc3-of-simple.c
> index bdac3e7d7b18..d5fd45c64901 100644
> --- a/drivers/usb/dwc3/dwc3-of-simple.c
> +++ b/drivers/usb/dwc3/dwc3-of-simple.c
> @@ -133,6 +133,11 @@ static int dwc3_of_simple_remove(struct
> platform_device *pdev)
> return 0;
> }
>
> +static void dwc3_of_simple_shutdown(struct platform_device *pdev)
> +{
> + dwc3_of_simple_remove(pdev);
> +}
> +
> static int __maybe_unused
> dwc3_of_simple_runtime_suspend(struct device *dev)
> {
> struct dwc3_of_simple *simple = dev_get_drvdata(dev);
> @@ -190,6 +195,7 @@ MODULE_DEVICE_TABLE(of, of_dwc3_simple_match);
> static struct platform_driver dwc3_of_simple_driver = {
> .probe = dwc3_of_simple_probe,
> .remove = dwc3_of_simple_remove,
> + .shutdown = dwc3_of_simple_shutdown,
> .driver = {
> .name = "dwc3-of-simple",
> .of_match_table = of_dwc3_simple_match,
Hi,
please, can you provide some feedback on this?
Regards,
Vicenç.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] usb: dwc3: Add shutdown to platform_driver
From: Felipe Balbi @ 2019-08-27 11:53 UTC (permalink / raw)
To: Vicente Bergas, Robin Murphy
Cc: Matthias Brugger, Heiko Stuebner, MarcZyngier, Catalin Marinas,
linux-usb, Will Deacon, linux-rockchip, Greg Kroah-Hartman,
linux-arm-kernel
In-Reply-To: <8d48017a-64c5-4b25-8d85-113ffcf502c9@gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 1852 bytes --]
Hi,
Vicente Bergas <vicencb@gmail.com> writes:
> On Saturday, August 17, 2019 7:41:40 PM CEST, Vicente Bergas wrote:
>> Otherwise the device keeps writing to memory after kexec and disturbs
>> the next kernel.
>>
>> Signed-off-by: Vicente Bergas <vicencb@gmail.com>
>> ---
>> drivers/usb/dwc3/dwc3-of-simple.c | 6 ++++++
>> 1 file changed, 6 insertions(+)
>>
>> Hi Felipe, Robin,
>> this version calls 'remove' from 'shutdown' instead of just asserting
>> a reset because it looks like a cleaner way to stop the device.
>>
>> Calling remove from shutdown in core.c instead of dwc3-of-simple.c does not
>> fix the issue either.
>>
>> It has been tested on the sapphire board, a RK3399 platform.
>>
>> Regards,
>> Vicenç.
>>
>> diff --git a/drivers/usb/dwc3/dwc3-of-simple.c
>> b/drivers/usb/dwc3/dwc3-of-simple.c
>> index bdac3e7d7b18..d5fd45c64901 100644
>> --- a/drivers/usb/dwc3/dwc3-of-simple.c
>> +++ b/drivers/usb/dwc3/dwc3-of-simple.c
>> @@ -133,6 +133,11 @@ static int dwc3_of_simple_remove(struct
>> platform_device *pdev)
>> return 0;
>> }
>>
>> +static void dwc3_of_simple_shutdown(struct platform_device *pdev)
>> +{
>> + dwc3_of_simple_remove(pdev);
>> +}
>> +
>> static int __maybe_unused
>> dwc3_of_simple_runtime_suspend(struct device *dev)
>> {
>> struct dwc3_of_simple *simple = dev_get_drvdata(dev);
>> @@ -190,6 +195,7 @@ MODULE_DEVICE_TABLE(of, of_dwc3_simple_match);
>> static struct platform_driver dwc3_of_simple_driver = {
>> .probe = dwc3_of_simple_probe,
>> .remove = dwc3_of_simple_remove,
>> + .shutdown = dwc3_of_simple_shutdown,
why don't you just have shutdown use the same exact function as remove?
Frankly, though, I still don't fully understand what's going wrong
here. Why is the device still alive during kexec?
cheers
--
balbi
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 1/2] dt-bindings: arm: sunxi: Add compatible for A64 OlinuXino with eMMC
From: Rob Herring @ 2019-08-27 11:55 UTC (permalink / raw)
To: Sunil Mohan Adapa
Cc: Maxime Ripard, devicetree, Chen-Yu Tsai, Mark Rutland,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <20190821195217.4166-2-sunil@medhas.org>
On Wed, Aug 21, 2019 at 2:53 PM Sunil Mohan Adapa <sunil@medhas.org> wrote:
>
> A64 OLinuXino board from Olimex has three variants with onboard eMMC:
> A64-OLinuXino-1Ge16GW, A64-OLinuXino-1Ge4GW and A64-OLinuXino-2Ge8G-IND. In
> addition, there are two variants without eMMC. One without eMMC and one with SPI
> flash. This suggests the need for separate device tree for the three eMMC
> variants.
>
> Add new compatible string to the bindings documentation for the A64 OlinuXino
> board variant with on-board eMMC.
>
> Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
> ---
> Documentation/devicetree/bindings/arm/sunxi.yaml | 5 +++++
> 1 file changed, 5 insertions(+)
Reviewed-by: Rob Herring <robh@kernel.org>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 2/2] dma-contiguous: Use fallback alloc_pages for single pages
From: Christoph Hellwig @ 2019-08-27 11:55 UTC (permalink / raw)
To: Masahiro Yamada
Cc: Ulf Hansson, Tony Lindgren, Catalin Marinas, Will Deacon,
Linux Kernel Mailing List, Max Filippov, Christoph Hellwig,
Marek Szyprowski, Stephen Rothwell, Joerg Roedel, Russell King,
Thierry Reding, linux-xtensa, Kees Cook, Nicolin Chen,
Andrew Morton, linux-arm-kernel, Chris Zankel, Wolfram Sang,
Robin Murphy, linux-mmc, Adrian Hunter, iommu, iamjoonsoo.kim,
David Woodhouse
In-Reply-To: <CAK7LNAQZ+bueZZzSoMADmgLjWNvijHRV=wLQzN_kvLG3b5Uu+w@mail.gmail.com>
On Tue, Aug 27, 2019 at 06:03:14PM +0900, Masahiro Yamada wrote:
> Yes, this makes my driver working again
> when CONFIG_DMA_CMA=y.
>
>
> If I apply the following, my driver gets back working
> irrespective of CONFIG_DMA_CMA.
That sounds a lot like the device simply isn't 64-bit DMA capable, and
previously always got CMA allocations under the limit it actually
supported. I suggest that you submit this quirk to the mmc maintainers.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 02/20] dt-bindings: arm: Convert Marvell MMP board/soc bindings to json-schema
From: Rob Herring @ 2019-08-27 11:59 UTC (permalink / raw)
To: Lubomir Rintel
Cc: Mark Rutland, devicetree, Jason Cooper, Stephen Boyd,
Marc Zyngier, Michael Turquette, Russell King,
Kishon Vijay Abraham I,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
Olof Johansson, Thomas Gleixner, linux-clk,
linux-kernel@vger.kernel.org
In-Reply-To: <20190822092643.593488-3-lkundrak@v3.sk>
On Thu, Aug 22, 2019 at 4:27 AM Lubomir Rintel <lkundrak@v3.sk> wrote:
>
> Convert Marvell MMP SoC bindings to DT schema format using json-schema.
>
> Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
>
> ---
> Changes since v1:
> - Added this patch
>
> .../devicetree/bindings/arm/mrvl/mrvl.txt | 14 ---------
> .../devicetree/bindings/arm/mrvl/mrvl.yaml | 31 +++++++++++++++++++
> 2 files changed, 31 insertions(+), 14 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/arm/mrvl/mrvl.txt
> create mode 100644 Documentation/devicetree/bindings/arm/mrvl/mrvl.yaml
>
> diff --git a/Documentation/devicetree/bindings/arm/mrvl/mrvl.txt b/Documentation/devicetree/bindings/arm/mrvl/mrvl.txt
> deleted file mode 100644
> index 951687528efb0..0000000000000
> --- a/Documentation/devicetree/bindings/arm/mrvl/mrvl.txt
> +++ /dev/null
> @@ -1,14 +0,0 @@
> -Marvell Platforms Device Tree Bindings
> -----------------------------------------------------
> -
> -PXA168 Aspenite Board
> -Required root node properties:
> - - compatible = "mrvl,pxa168-aspenite", "mrvl,pxa168";
> -
> -PXA910 DKB Board
> -Required root node properties:
> - - compatible = "mrvl,pxa910-dkb";
> -
> -MMP2 Brownstone Board
> -Required root node properties:
> - - compatible = "mrvl,mmp2-brownstone", "mrvl,mmp2";
> diff --git a/Documentation/devicetree/bindings/arm/mrvl/mrvl.yaml b/Documentation/devicetree/bindings/arm/mrvl/mrvl.yaml
> new file mode 100644
> index 0000000000000..dc9de506ac6e3
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/mrvl/mrvl.yaml
> @@ -0,0 +1,31 @@
> +# SPDX-License-Identifier: GPL-2.0
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/arm/mrvl/mrvl.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Marvell Platforms Device Tree Bindings
> +
> +maintainers:
> + - Lubomir Rintel <lkundrak@v3.sk>
> +
> +properties:
> + $nodename:
> + const: '/'
> + compatible:
> + oneOf:
> + - description: PXA168 Aspenite Board
> + items:
> + - enum:
> + - mrvl,pxa168-aspenite
> + - const: mrvl,pxa168
> + - description: PXA910 DKB Board
> + items:
> + - enum:
> + - mrvl,pxa910-dkb
Doesn't match what's in dts file:
arch/arm/boot/dts/pxa910-dkb.dts: compatible =
"mrvl,pxa910-dkb", "mrvl,pxa910";
> + - description: MMP2 Brownstone Board
If this entry is only for this board...
> + items:
> + - enum:
> + - mrvl,mmp2-brownstone
...then this can be a 'const' instead. Same for the others.
> + - const: mrvl,mmp2
> +...
> --
> 2.21.0
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 03/20] dt-bindings: arm: mrvl: Document MMP3 compatible string
From: Rob Herring @ 2019-08-27 12:00 UTC (permalink / raw)
To: Lubomir Rintel
Cc: Mark Rutland, devicetree, Jason Cooper, Stephen Boyd,
Marc Zyngier, Michael Turquette, Russell King,
Kishon Vijay Abraham I,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
Olof Johansson, Thomas Gleixner, linux-clk,
linux-kernel@vger.kernel.org
In-Reply-To: <20190822092643.593488-4-lkundrak@v3.sk>
On Thu, Aug 22, 2019 at 4:33 AM Lubomir Rintel <lkundrak@v3.sk> wrote:
>
> Marvel MMP3 is a successor to MMP2, containing similar peripherals with two
> PJ4B cores.
>
> Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
>
> ---
> Changes since v1:
> - Rebased on top of mrvl.txt->mrvl.yaml conversion
>
> Documentation/devicetree/bindings/arm/mrvl/mrvl.yaml | 3 +++
> 1 file changed, 3 insertions(+)
Reviewed-by: Rob Herring <robh@kernel.org>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 1/2] dt-bindings: display/bridge: Add binding for NWL mipi dsi host controller
From: Rob Herring @ 2019-08-27 12:09 UTC (permalink / raw)
To: Guido Günther
Cc: Mark Rutland, devicetree, Jernej Skrabec, Daniel Vetter,
Sam Ravnborg, Neil Armstrong, David Airlie, Fabio Estevam,
Sascha Hauer, Jonas Karlman, linux-kernel@vger.kernel.org,
dri-devel, Andrzej Hajda, Arnd Bergmann, NXP Linux Team,
Pengutronix Kernel Team, Robert Chiras, Lee Jones, Shawn Guo,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
Laurent Pinchart
In-Reply-To: <36f62b431f32bc76e92d21e04dc48464aef43869.1566470526.git.agx@sigxcpu.org>
On Thu, Aug 22, 2019 at 5:44 AM Guido Günther <agx@sigxcpu.org> wrote:
>
> The Northwest Logic MIPI DSI IP core can be found in NXPs i.MX8 SoCs.
>
> Signed-off-by: Guido Günther <agx@sigxcpu.org>
> ---
> .../bindings/display/bridge/nwl-dsi.yaml | 155 ++++++++++++++++++
> 1 file changed, 155 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/display/bridge/nwl-dsi.yaml
>
> diff --git a/Documentation/devicetree/bindings/display/bridge/nwl-dsi.yaml b/Documentation/devicetree/bindings/display/bridge/nwl-dsi.yaml
> new file mode 100644
> index 000000000000..24d17a6310dc
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/bridge/nwl-dsi.yaml
> @@ -0,0 +1,155 @@
> +# SPDX-License-Identifier: GPL-2.0
(GPL-2.0-only OR BSD-2-Clause) is preferred for new bindings.
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/bridge/nwl-dsi.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Northwest Logic MIPI-DSI controller on i.MX SoCs
> +
> +maintainers:
> + - Guido Gúnther <agx@sigxcpu.org>
> + - Robert Chiras <robert.chiras@nxp.com>
> +
> +description: |
> + NWL MIPI-DSI host controller found on i.MX8 platforms. This is a dsi bridge for
> + the SOCs NWL MIPI-DSI host controller.
> +
> +properties:
> + compatible:
> + const: fsl,imx8mq-nwl-dsi
> +
> + reg:
> + maxItems: 1
> +
> + interrupts:
> + maxItems: 1
> +
> + clocks:
> + items:
> + - description: DSI core clock
> + - description: RX_ESC clock (used in escape mode)
> + - description: TX_ESC clock (used in escape mode)
> + - description: PHY_REF clock
> +
> + clock-names:
> + items:
> + - const: core
> + - const: rx_esc
> + - const: tx_esc
> + - const: phy_ref
> +
> + mux-controls:
> + description:
> + mux controller node to use for operating the input mux
> +
> + phys:
> + maxItems: 1
> + description:
> + A phandle to the phy module representing the DPHY
> +
> + phy-names:
> + items:
> + - const: dphy
> +
> + power-domains:
> + maxItems: 1
> + description:
> + A phandle to the power domain
Don't need a description for common properties unless you have
something specific about this device to say.
> +
> + resets:
> + description:
> + phandles to the reset controller
Same here.
> + items:
> + - description: dsi byte reset line
> + - description: dsi dpi reset line
> + - description: dsi esc reset line
> + - description: dsi pclk reset line
> +
> + reset-names:
> + items:
> + - const: byte
> + - const: dpi
> + - const: esc
> + - const: pclk
> +
> + ports:
> + type: object
> + description:
> + A node containing DSI input & output port nodes with endpoint
> + definitions as documented in
> + Documentation/devicetree/bindings/graph.txt.
> +
> + port@0:
These are child nodes of ports. So under ports you need 'properties'
with these. And 'required'.
> + type: object
> + description:
> + Input port node to receive pixel data from the
> + display controller
> +
> + port@1:
> + type: object
> + description:
> + DSI output port node to the panel or the next bridge
> + in the chain
> +
> +patternProperties:
> + "^panel@[0-9]+$": true
This is a node, so:
type: object
> +
> +required:
> + - clock-names
> + - clocks
> + - compatible
> + - interrupts
> + - mux-controls
> + - phy-names
> + - phys
> + - ports
> + - reg
> + - reset-names
> + - resets
Add a:
additionalProperties: false
> +
> +examples:
> + - |
> +
> + mipi_dsi: mipi_dsi@30a00000 {
> + #address-cells = <1>;
> + #size-cells = <0>;
These need to be listed above.
> + compatible = "fsl,imx8mq-nwl-dsi";
> + reg = <0x30A00000 0x300>;
> + clocks = <&clk 163>, <&clk 244>, <&clk 245>, <&clk 164>;
> + clock-names = "core", "rx_esc", "tx_esc", "phy_ref";
> + interrupts = <0 34 4>;
> + mux-controls = <&mux 0>;
> + power-domains = <&pgc_mipi>;
> + resets = <&src 0>, <&src 1>, <&src 2>, <&src 3>;
> + reset-names = "byte", "dpi", "esc", "pclk";
> + phys = <&dphy>;
> + phy-names = "dphy";
> +
> + panel@0 {
> + compatible = "rocktech,jh057n00900";
> + reg = <0>;
> + port@0 {
> + panel_in: endpoint {
> + remote-endpoint = <&mipi_dsi_out>;
> + };
> + };
> + };
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> + mipi_dsi_in: endpoint {
> + remote-endpoint = <&lcdif_mipi_dsi>;
> + };
> + };
> + port@1 {
> + reg = <1>;
> + mipi_dsi_out: endpoint {
> + remote-endpoint = <&panel_in>;
> + };
> + };
> + };
> + };
> --
> 2.20.1
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v4 4/8] dt-bindings: clock: Add devicetree binding for BM1880 SoC
From: Rob Herring @ 2019-08-27 12:12 UTC (permalink / raw)
To: Manivannan Sadhasivam
Cc: devicetree, Stephen Boyd, Michael Turquette,
linux-kernel@vger.kernel.org, darren.tsao, haitao.suo,
fisher.cheng, alec.lin, linux-clk,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <20190822172426.25879-5-manivannan.sadhasivam@linaro.org>
On Thu, Aug 22, 2019 at 12:25 PM Manivannan Sadhasivam
<manivannan.sadhasivam@linaro.org> wrote:
>
> Add YAML devicetree binding for Bitmain BM1880 SoC.
>
> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
> ---
> .../bindings/clock/bitmain,bm1880-clk.yaml | 74 +++++++++++++++++
> include/dt-bindings/clock/bm1880-clock.h | 82 +++++++++++++++++++
> 2 files changed, 156 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/clock/bitmain,bm1880-clk.yaml
> create mode 100644 include/dt-bindings/clock/bm1880-clock.h
>
> diff --git a/Documentation/devicetree/bindings/clock/bitmain,bm1880-clk.yaml b/Documentation/devicetree/bindings/clock/bitmain,bm1880-clk.yaml
> new file mode 100644
> index 000000000000..31c48dcf5b8e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/bitmain,bm1880-clk.yaml
> @@ -0,0 +1,74 @@
> +# SPDX-License-Identifier: GPL-2.0+
Dual license please.
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/bindings/clock/bitmain,bm1880-clk.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Bitmain BM1880 Clock Controller
> +
> +maintainers:
> + - Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
> +
> +description: |
> + The Bitmain BM1880 clock controller generates and supplies clock to
> + various peripherals within the SoC.
> +
> + This binding uses common clock bindings
> + [1] Documentation/devicetree/bindings/clock/clock-bindings.txt
> +
> +properties:
> + compatible:
> + const: bitmain,bm1880-clk
> +
> + reg:
> + items:
> + - description: pll registers
> + - description: system registers
> +
> + reg-names:
> + items:
> + - const: pll
> + - const: sys
> +
> + clocks:
> + maxItems: 1
> +
> + clock-names:
> + const: osc
> +
> + '#clock-cells':
> + const: 1
> +
> +required:
> + - compatible
> + - reg
> + - reg-names
> + - clocks
> + - clock-names
> + - '#clock-cells'
additionalProperties: false
> +
> +examples:
> + # Clock controller node:
> + - |
> + clk: clock-controller@e8 {
> + compatible = "bitmain,bm1880-clk";
> + reg = <0xe8 0x0c>, <0x800 0xb0>;
> + reg-names = "pll", "sys";
> + clocks = <&osc>;
> + clock-names = "osc";
> + #clock-cells = <1>;
> + };
> +
> + # Example UART controller node that consumes clock generated by the clock controller:
> + - |
> + uart0: serial@58018000 {
> + compatible = "snps,dw-apb-uart";
> + reg = <0x0 0x58018000 0x0 0x2000>;
> + clocks = <&clk 45>, <&clk 46>;
> + clock-names = "baudclk", "apb_pclk";
> + interrupts = <0 9 4>;
> + reg-shift = <2>;
> + reg-io-width = <4>;
> + };
> +
> +...
> diff --git a/include/dt-bindings/clock/bm1880-clock.h b/include/dt-bindings/clock/bm1880-clock.h
> new file mode 100644
> index 000000000000..b46732361b25
> --- /dev/null
> +++ b/include/dt-bindings/clock/bm1880-clock.h
> @@ -0,0 +1,82 @@
> +/* SPDX-License-Identifier: GPL-2.0+ */
> +/*
> + * Device Tree binding constants for Bitmain BM1880 SoC
> + *
> + * Copyright (c) 2019 Linaro Ltd.
> + */
> +
> +#ifndef __DT_BINDINGS_CLOCK_BM1880_H
> +#define __DT_BINDINGS_CLOCK_BM1880_H
> +
> +#define BM1880_CLK_OSC 0
> +#define BM1880_CLK_MPLL 1
> +#define BM1880_CLK_SPLL 2
> +#define BM1880_CLK_FPLL 3
> +#define BM1880_CLK_DDRPLL 4
> +#define BM1880_CLK_A53 5
> +#define BM1880_CLK_50M_A53 6
> +#define BM1880_CLK_AHB_ROM 7
> +#define BM1880_CLK_AXI_SRAM 8
> +#define BM1880_CLK_DDR_AXI 9
> +#define BM1880_CLK_EFUSE 10
> +#define BM1880_CLK_APB_EFUSE 11
> +#define BM1880_CLK_AXI5_EMMC 12
> +#define BM1880_CLK_EMMC 13
> +#define BM1880_CLK_100K_EMMC 14
> +#define BM1880_CLK_AXI5_SD 15
> +#define BM1880_CLK_SD 16
> +#define BM1880_CLK_100K_SD 17
> +#define BM1880_CLK_500M_ETH0 18
> +#define BM1880_CLK_AXI4_ETH0 19
> +#define BM1880_CLK_500M_ETH1 20
> +#define BM1880_CLK_AXI4_ETH1 21
> +#define BM1880_CLK_AXI1_GDMA 22
> +#define BM1880_CLK_APB_GPIO 23
> +#define BM1880_CLK_APB_GPIO_INTR 24
> +#define BM1880_CLK_GPIO_DB 25
> +#define BM1880_CLK_AXI1_MINER 26
> +#define BM1880_CLK_AHB_SF 27
> +#define BM1880_CLK_SDMA_AXI 28
> +#define BM1880_CLK_SDMA_AUD 29
> +#define BM1880_CLK_APB_I2C 30
> +#define BM1880_CLK_APB_WDT 31
> +#define BM1880_CLK_APB_JPEG 32
> +#define BM1880_CLK_JPEG_AXI 33
> +#define BM1880_CLK_AXI5_NF 34
> +#define BM1880_CLK_APB_NF 35
> +#define BM1880_CLK_NF 36
> +#define BM1880_CLK_APB_PWM 37
> +#define BM1880_CLK_DIV_0_RV 38
> +#define BM1880_CLK_DIV_1_RV 39
> +#define BM1880_CLK_MUX_RV 40
> +#define BM1880_CLK_RV 41
> +#define BM1880_CLK_APB_SPI 42
> +#define BM1880_CLK_TPU_AXI 43
> +#define BM1880_CLK_DIV_UART_500M 44
> +#define BM1880_CLK_UART_500M 45
> +#define BM1880_CLK_APB_UART 46
> +#define BM1880_CLK_APB_I2S 47
> +#define BM1880_CLK_AXI4_USB 48
> +#define BM1880_CLK_APB_USB 49
> +#define BM1880_CLK_125M_USB 50
> +#define BM1880_CLK_33K_USB 51
> +#define BM1880_CLK_DIV_12M_USB 52
> +#define BM1880_CLK_12M_USB 53
> +#define BM1880_CLK_APB_VIDEO 54
> +#define BM1880_CLK_VIDEO_AXI 55
> +#define BM1880_CLK_VPP_AXI 56
> +#define BM1880_CLK_APB_VPP 57
> +#define BM1880_CLK_DIV_0_AXI1 58
> +#define BM1880_CLK_DIV_1_AXI1 59
> +#define BM1880_CLK_AXI1 60
> +#define BM1880_CLK_AXI2 61
> +#define BM1880_CLK_AXI3 62
> +#define BM1880_CLK_AXI4 63
> +#define BM1880_CLK_AXI5 64
> +#define BM1880_CLK_DIV_0_AXI6 65
> +#define BM1880_CLK_DIV_1_AXI6 66
> +#define BM1880_CLK_MUX_AXI6 67
> +#define BM1880_CLK_AXI6 68
> +#define BM1880_NR_CLKS 69
> +
> +#endif /* __DT_BINDINGS_CLOCK_BM1880_H */
> --
> 2.17.1
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 01/11] kselftest: arm64: introduce new boilerplate code
From: Cristian Marussi @ 2019-08-27 12:14 UTC (permalink / raw)
To: Dave Martin; +Cc: andreyknvl, shuah, linux-arm-kernel, linux-kselftest
In-Reply-To: <20190813162337.GY10425@arm.com>
Hi
On 13/08/2019 17:23, Dave Martin wrote:
> ^ Regarding the subject line, "boilerplate code" sounds a bit vague.
> Could we say something like "Add skeleton Makefile"?
>
Yes of course.
> On Fri, Aug 02, 2019 at 06:02:50PM +0100, Cristian Marussi wrote:
>> Added a new arm64-specific empty subsystem amongst TARGETS of KSFT build
>> framework; once populated with testcases, it will be possible to build
>> and invoke the new KSFT TARGETS=arm64 related tests from the toplevel
>> Makefile in the usual ways.
>>
>> Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
>> ---
>> Reviewed the build instructions reported in the README, to be more
>> agnostic regarding user/device etc..
>> ---
>> tools/testing/selftests/Makefile | 1 +
>> tools/testing/selftests/arm64/Makefile | 51 ++++++++++++++++++++++++++
>> tools/testing/selftests/arm64/README | 43 ++++++++++++++++++++++
>> 3 files changed, 95 insertions(+)
>> create mode 100644 tools/testing/selftests/arm64/Makefile
>> create mode 100644 tools/testing/selftests/arm64/README
>>
>> diff --git a/tools/testing/selftests/Makefile b/tools/testing/selftests/Makefile
>> index 25b43a8c2b15..1722dae9381a 100644
>> --- a/tools/testing/selftests/Makefile
>> +++ b/tools/testing/selftests/Makefile
>> @@ -1,5 +1,6 @@
>> # SPDX-License-Identifier: GPL-2.0
>> TARGETS = android
>> +TARGETS += arm64
>> TARGETS += bpf
>> TARGETS += breakpoints
>> TARGETS += capabilities
>> diff --git a/tools/testing/selftests/arm64/Makefile b/tools/testing/selftests/arm64/Makefile
>> new file mode 100644
>> index 000000000000..03a0d4f71218
>> --- /dev/null
>> +++ b/tools/testing/selftests/arm64/Makefile
>> @@ -0,0 +1,51 @@
>> +# SPDX-License-Identifier: GPL-2.0
>> +# Copyright (C) 2019 ARM Limited
>> +
>> +# When ARCH not overridden for crosscompiling, lookup machine
>> +ARCH ?= $(shell uname -m)
>> +ARCH := $(shell echo $(ARCH) | sed -e s/aarch64/arm64/)
>> +
>> +ifeq ("x$(ARCH)", "xarm64")
>> +SUBDIRS :=
>> +else
>> +SUBDIRS :=
>> +endif
>> +
>> +CFLAGS := -Wall -O2 -g
>> +
>> +export CC
>> +export CFLAGS
>> +
>> +all:
>> + @for DIR in $(SUBDIRS); do \
>> + BUILD_TARGET=$(OUTPUT)/$$DIR; \
>> + mkdir -p $$BUILD_TARGET; \
>> + make OUTPUT=$$BUILD_TARGET -C $$DIR $@; \
>> + done
>> +
>> +install: all
>> + @for DIR in $(SUBDIRS); do \
>> + BUILD_TARGET=$(OUTPUT)/$$DIR; \
>> + make OUTPUT=$$BUILD_TARGET -C $$DIR $@; \
>> + done
>> +
>> +run_tests: all
>> + @for DIR in $(SUBDIRS); do \
>> + BUILD_TARGET=$(OUTPUT)/$$DIR; \
>> + make OUTPUT=$$BUILD_TARGET -C $$DIR $@; \
>> + done
>> +
>> +# Avoid any output on non arm64 on emit_tests
>> +emit_tests: all
>> + @for DIR in $(SUBDIRS); do \
>> + BUILD_TARGET=$(OUTPUT)/$$DIR; \
>> + make OUTPUT=$$BUILD_TARGET -C $$DIR $@; \
>> + done
>> +
>> +clean:
>> + @for DIR in $(SUBDIRS); do \
>> + BUILD_TARGET=$(OUTPUT)/$$DIR; \
>> + make OUTPUT=$$BUILD_TARGET -C $$DIR $@; \
>> + done
>> +
>> +.PHONY: all clean install run_tests emit_tests
>> diff --git a/tools/testing/selftests/arm64/README b/tools/testing/selftests/arm64/README
>> new file mode 100644
>> index 000000000000..dee3306071cc
>> --- /dev/null
>> +++ b/tools/testing/selftests/arm64/README
>> @@ -0,0 +1,43 @@
>> +KSelfTest ARM64
>> +===============
>> +
>> +- These tests are arm64 specific and so not built or run but just skipped
>> + completely when env-variable ARCH is found to be different than 'arm64'
>> + and `uname -m` reports other than 'aarch64'.
>> +
>> +- Holding true the above, ARM64 KSFT tests can be run:
>> +
>> + + as standalone (example for signal tests)
>> +
>> + $ make -C tools/testing/selftest/arm64/signal \
>> + INSTALL_PATH=<your-installation-path> install
>> +
>> + and then launching on the target device inside the installed path:
>> +
>> + $ <your-installed-path>/test_arm64_signals.sh [-k | -v]
>> +
>> + + within the KSelfTest framework using standard Linux top-level-makefile
>> + targets:
>> +
>> + $ make TARGETS=arm64 kselftest-clean
>> + $ make TARGETS=arm64 kselftest
>> +
>> + Further details on building and running KFST can be found in:
>> + Documentation/dev-tools/kselftest.rst
>
> The next two paragraphs aren't relevant yet. Can we split them out of
> this patch and add them alongside the relevant code / Makefile changes?
>
Sure. I'm going to remove also standalone mode in V4 as elsewhere advised,
so I'll drop part of this README too.
>> +
>> +- Tests can depend on some arch-specific definitions which can be found in a
>> + standard Kernel Headers installation in $(top_srcdir)/usr/include.
>> + Such Kernel Headers are automatically installed (via make headers_install)
>> + by KSFT framework itself in a dedicated directory when tests are launched
>> + via KSFT itself; when running standalone, instead, a Warning is issued
>> + if such headers cannot be found somewhere (we try to guess a few standard
>> + locations anyway)
>> +
>> +- Some of these tests may be related to possibly not implemented ARMv8
>> + features: depending on their implementation status on the effective HW
>> + we'll expect different results. The tests' harness will take care to check
>> + at run-time if the required features are supported and will act accordingly.
>> + Moreover, in order to avoid any kind of compile-time dependency on the
>> + toolchain (possibly due to the above mentioned not-implemented features),
>> + we make strictly use of direct 'S3_ sysreg' raw-encoding while checking for
>> + those features and/or lookin up sysregs.
>
> This last paragraph is only relevant for people adding new tests. It
> probably makes sense to start "When adding new tests, try to avoid
> unnecessary toolchain dependencies where possible. [...]"
>
> Cheers
> ---Dave
>
Cheers
Cristian
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] usb: dwc3: Add shutdown to platform_driver
From: Vicente Bergas @ 2019-08-27 12:16 UTC (permalink / raw)
To: Felipe Balbi
Cc: Matthias Brugger, Heiko Stuebner, MarcZyngier, Catalin Marinas,
linux-usb, Will Deacon, linux-rockchip, Greg Kroah-Hartman,
Robin Murphy, linux-arm-kernel
In-Reply-To: <87v9uix1sv.fsf@gmail.com>
On Tuesday, August 27, 2019 1:53:04 PM CEST, Felipe Balbi wrote:
> Hi,
>
> Vicente Bergas <vicencb@gmail.com> writes:
>> On Saturday, August 17, 2019 7:41:40 PM CEST, Vicente Bergas wrote:
>>> Otherwise the device keeps writing to memory after kexec and disturbs
>>> the next kernel.
...
>
> why don't you just have shutdown use the same exact function as remove?
> Frankly, though, I still don't fully understand what's going wrong
> here. Why is the device still alive during kexec?
>
> cheers
Hi Felipe,
the remove and shutdown functions have different prototypes, so
shutdown is wrapping remove.
Would it be preferable to cast remove as shutdown?
The issue with kexec is that the device is being used during the livetime
of the first kernel. When the first kernel executes kexec it calls the
shutdown function of drivers (instead of remove). Because of this the dwc3
device keeps doing things like DMA.
While the second kernel is taking over, it gets its memory corrupted with
such DMA accesses from the device. When the second kernel reaches the point
of taking over the dwc3 device, re-initializes it, but it is already too
late. Still worse, if the second kernel did not have the dwc3 driver, it
would get endless memory corruptions.
All in all, devices that can do DMA need to stop doing it on shutdown.
Regards,
Vicenç.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] Documentation: add link to stm32mp157 docs
From: Gerald BAEZA @ 2019-08-27 12:19 UTC (permalink / raw)
To: corbet@lwn.net, mcoquelin.stm32@gmail.com, Alexandre TORGUE,
linux-doc@vger.kernel.org,
linux-stm32@st-md-mailman.stormreply.com,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Cc: Gerald BAEZA
Link to the online stm32mp157 documentation added
in the overview.
Signed-off-by: Gerald Baeza <gerald.baeza@st.com>
---
Documentation/arm/stm32/stm32mp157-overview.rst | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/Documentation/arm/stm32/stm32mp157-overview.rst b/Documentation/arm/stm32/stm32mp157-overview.rst
index f62fdc8..8d5a476 100644
--- a/Documentation/arm/stm32/stm32mp157-overview.rst
+++ b/Documentation/arm/stm32/stm32mp157-overview.rst
@@ -14,6 +14,12 @@ It features:
- Standard connectivity, widely inherited from the STM32 MCU family
- Comprehensive security support
+Resources
+---------
+
+Datasheet and reference manual are publicly available on ST website:
+.. _STM32MP157: https://www.st.com/en/microcontrollers-microprocessors/stm32mp157.html
+
:Authors:
- Ludovic Barre <ludovic.barre@st.com>
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH] arm: xen: mm: use __GPF_DMA32 for arm64
From: Robin Murphy @ 2019-08-27 12:23 UTC (permalink / raw)
To: Peng Fan, sstabellini@kernel.org, linux@armlinux.org.uk
Cc: van.freenix@gmail.com, xen-devel@lists.xenproject.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, dl-linux-imx
In-Reply-To: <20190709083729.11135-1-peng.fan@nxp.com>
On 09/07/2019 09:22, Peng Fan wrote:
> arm64 shares some code under arch/arm/xen, including mm.c.
> However ZONE_DMA is removed by commit
> ad67f5a6545("arm64: replace ZONE_DMA with ZONE_DMA32").
> So to ARM64, need use __GFP_DMA32.
>
> Signed-off-by: Peng Fan <peng.fan@nxp.com>
> ---
> arch/arm/xen/mm.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/xen/mm.c b/arch/arm/xen/mm.c
> index e1d44b903dfc..a95e76d18bf9 100644
> --- a/arch/arm/xen/mm.c
> +++ b/arch/arm/xen/mm.c
> @@ -27,7 +27,7 @@ unsigned long xen_get_swiotlb_free_pages(unsigned int order)
>
> for_each_memblock(memory, reg) {
> if (reg->base < (phys_addr_t)0xffffffff) {
> - flags |= __GFP_DMA;
> + flags |= __GFP_DMA | __GFP_DMA32;
Given the definition of GFP_ZONE_BAD, I'm not sure this combination of
flags is strictly valid, but rather is implicitly reliant on only one of
those zones ever actually existing. As such, it seems liable to blow up
if the plans to add ZONE_DMA to arm64[1] go ahead.
Robin.
[1]
https://lore.kernel.org/linux-arm-kernel/20190820145821.27214-1-nsaenzjulienne@suse.de/
> break;
> }
> }
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v2 1/2] ASoC: sun4i-i2s: Revert "ASoC: sun4i-i2s: Remove duplicated quirks structure"
From: Maxime Ripard @ 2019-08-27 12:31 UTC (permalink / raw)
To: Chen-Yu Tsai, Maxime Ripard, lgirdwood, broonie
Cc: codekipper, alsa-devel, linux-kernel, linux-arm-kernel
From: Maxime Ripard <maxime.ripard@bootlin.com>
This reverts commit 3e9acd7ac6933cdc20c441bbf9a38ed9e42e1490.
It turns out that while one I2S controller is described in the A83t
datasheet, the driver supports another, undocumented, one that has been
inherited from the older SoCs, while the documented one uses the new
design.
Fixes: 3e9acd7ac693 ("ASoC: sun4i-i2s: Remove duplicated quirks structure")
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
---
Changes from v1:
- Add the proper prefix to the commit title
---
sound/soc/sunxi/sun4i-i2s.c | 25 ++++++++++++++++++++++++-
1 file changed, 24 insertions(+), 1 deletion(-)
diff --git a/sound/soc/sunxi/sun4i-i2s.c b/sound/soc/sunxi/sun4i-i2s.c
index 57bf2a33753e..a6a3f772fdf0 100644
--- a/sound/soc/sunxi/sun4i-i2s.c
+++ b/sound/soc/sunxi/sun4i-i2s.c
@@ -1097,6 +1097,11 @@ static const struct sun4i_i2s_quirks sun6i_a31_i2s_quirks = {
.set_fmt = sun4i_i2s_set_soc_fmt,
};
+/*
+ * This doesn't describe the TDM controller documented in the A83t
+ * datasheet, but the three undocumented I2S controller that use the
+ * older design.
+ */
static const struct sun4i_i2s_quirks sun8i_a83t_i2s_quirks = {
.has_reset = true,
.reg_offset_txdata = SUN8I_I2S_FIFO_TX_REG,
@@ -1115,6 +1120,24 @@ static const struct sun4i_i2s_quirks sun8i_a83t_i2s_quirks = {
.set_fmt = sun8i_i2s_set_soc_fmt,
};
+static const struct sun4i_i2s_quirks sun8i_h3_i2s_quirks = {
+ .has_reset = true,
+ .reg_offset_txdata = SUN8I_I2S_FIFO_TX_REG,
+ .sun4i_i2s_regmap = &sun8i_i2s_regmap_config,
+ .field_clkdiv_mclk_en = REG_FIELD(SUN4I_I2S_CLK_DIV_REG, 8, 8),
+ .field_fmt_wss = REG_FIELD(SUN4I_I2S_FMT0_REG, 0, 2),
+ .field_fmt_sr = REG_FIELD(SUN4I_I2S_FMT0_REG, 4, 6),
+ .bclk_dividers = sun8i_i2s_clk_div,
+ .num_bclk_dividers = ARRAY_SIZE(sun8i_i2s_clk_div),
+ .mclk_dividers = sun8i_i2s_clk_div,
+ .num_mclk_dividers = ARRAY_SIZE(sun8i_i2s_clk_div),
+ .get_bclk_parent_rate = sun8i_i2s_get_bclk_parent_rate,
+ .get_sr = sun8i_i2s_get_sr_wss,
+ .get_wss = sun8i_i2s_get_sr_wss,
+ .set_chan_cfg = sun8i_i2s_set_chan_cfg,
+ .set_fmt = sun8i_i2s_set_soc_fmt,
+};
+
static const struct sun4i_i2s_quirks sun50i_a64_codec_i2s_quirks = {
.has_reset = true,
.reg_offset_txdata = SUN8I_I2S_FIFO_TX_REG,
@@ -1296,7 +1319,7 @@ static const struct of_device_id sun4i_i2s_match[] = {
},
{
.compatible = "allwinner,sun8i-h3-i2s",
- .data = &sun8i_a83t_i2s_quirks,
+ .data = &sun8i_h3_i2s_quirks,
},
{
.compatible = "allwinner,sun50i-a64-codec-i2s",
--
2.21.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v2 2/2] ASoC: sun4i: Revert A83t description
From: Maxime Ripard @ 2019-08-27 12:31 UTC (permalink / raw)
To: Chen-Yu Tsai, Maxime Ripard, lgirdwood, broonie
Cc: codekipper, alsa-devel, linux-kernel, linux-arm-kernel
In-Reply-To: <20190827123131.29129-1-mripard@kernel.org>
From: Maxime Ripard <maxime.ripard@bootlin.com>
The last set of reworks included some fixes to change the A83t behaviour
and "fix" it.
It turns out that the controller described in the datasheet and the one
supported here are not the same, yet the A83t has the two of them, and the
one supported in the driver wasn't the one described in the datasheet.
Fix this by reintroducing the proper quirks.
Fixes: 69e450e50ca6 ("ASoC: sun4i-i2s: Fix the LRCK period on A83t")
Fixes: bf943d527987 ("ASoC: sun4i-i2s: Fix MCLK Enable bit offset on A83t")
Fixes: 2e04fc4dbf50 ("ASoC: sun4i-i2s: Fix WSS and SR fields for the A83t")
Fixes: 515fcfbc7736 ("ASoC: sun4i-i2s: Fix LRCK and BCLK polarity offsets on newer SoCs")
Fixes: c1d3a921d72b ("ASoC: sun4i-i2s: Fix the MCLK and BCLK dividers on newer SoCs")
Fixes: fb19739d7f68 ("ASoC: sun4i-i2s: Use module clock as BCLK parent on newer SoCs")
Fixes: 71137bcd0a9a ("ASoC: sun4i-i2s: Move the format configuration to a callback")
Fixes: d70be625f25a ("ASoC: sun4i-i2s: Move the channel configuration to a callback")
Reported-by: Chen-Yu Tsai <wens@csie.org>
Tested-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
---
Changes from v1:
- Fix function name
---
sound/soc/sunxi/sun4i-i2s.c | 24 ++++++++++++------------
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/sound/soc/sunxi/sun4i-i2s.c b/sound/soc/sunxi/sun4i-i2s.c
index a6a3f772fdf0..d0a8d5810c0a 100644
--- a/sound/soc/sunxi/sun4i-i2s.c
+++ b/sound/soc/sunxi/sun4i-i2s.c
@@ -1106,18 +1106,18 @@ static const struct sun4i_i2s_quirks sun8i_a83t_i2s_quirks = {
.has_reset = true,
.reg_offset_txdata = SUN8I_I2S_FIFO_TX_REG,
.sun4i_i2s_regmap = &sun4i_i2s_regmap_config,
- .field_clkdiv_mclk_en = REG_FIELD(SUN4I_I2S_CLK_DIV_REG, 8, 8),
- .field_fmt_wss = REG_FIELD(SUN4I_I2S_FMT0_REG, 0, 2),
- .field_fmt_sr = REG_FIELD(SUN4I_I2S_FMT0_REG, 4, 6),
- .bclk_dividers = sun8i_i2s_clk_div,
- .num_bclk_dividers = ARRAY_SIZE(sun8i_i2s_clk_div),
- .mclk_dividers = sun8i_i2s_clk_div,
- .num_mclk_dividers = ARRAY_SIZE(sun8i_i2s_clk_div),
- .get_bclk_parent_rate = sun8i_i2s_get_bclk_parent_rate,
- .get_sr = sun8i_i2s_get_sr_wss,
- .get_wss = sun8i_i2s_get_sr_wss,
- .set_chan_cfg = sun8i_i2s_set_chan_cfg,
- .set_fmt = sun8i_i2s_set_soc_fmt,
+ .field_clkdiv_mclk_en = REG_FIELD(SUN4I_I2S_CLK_DIV_REG, 7, 7),
+ .field_fmt_wss = REG_FIELD(SUN4I_I2S_FMT0_REG, 2, 3),
+ .field_fmt_sr = REG_FIELD(SUN4I_I2S_FMT0_REG, 4, 5),
+ .bclk_dividers = sun4i_i2s_bclk_div,
+ .num_bclk_dividers = ARRAY_SIZE(sun4i_i2s_bclk_div),
+ .mclk_dividers = sun4i_i2s_mclk_div,
+ .num_mclk_dividers = ARRAY_SIZE(sun4i_i2s_mclk_div),
+ .get_bclk_parent_rate = sun4i_i2s_get_bclk_parent_rate,
+ .get_sr = sun4i_i2s_get_sr,
+ .get_wss = sun4i_i2s_get_wss,
+ .set_chan_cfg = sun4i_i2s_set_chan_cfg,
+ .set_fmt = sun4i_i2s_set_soc_fmt,
};
static const struct sun4i_i2s_quirks sun8i_h3_i2s_quirks = {
--
2.21.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v2 2/2] arm: dts: imx6qdl: snvs-pwrkey: Change compatible string
From: Robin van der Gracht @ 2019-08-27 12:32 UTC (permalink / raw)
To: Robin Gong
Cc: Mark Rutland, devicetree @ vger . kernel . org,
Robin van der Gracht, Shawn Guo, Sascha Hauer, Dmitry Torokhov,
linux-kernel @ vger . kernel . org, Rob Herring, dl-linux-imx,
Pengutronix Kernel Team, linux-input @ vger . kernel . org,
Adam Ford, Fabio Estevam,
linux-arm-kernel @ lists . infradead . org
In-Reply-To: <20190827123216.32728-1-robin@protonic.nl>
The older imx6 SoCs do not send a power key press interrupt, instead it
sends a power down request interrupt when the key is released between
750ms and 5 seconds. The driver uses a different compatible string to ID
the older SoCs.
Signed-off-by: Robin van der Gracht <robin@protonic.nl>
---
arch/arm/boot/dts/imx6qdl.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
index b3a77bcf00d5..91b97816881c 100644
--- a/arch/arm/boot/dts/imx6qdl.dtsi
+++ b/arch/arm/boot/dts/imx6qdl.dtsi
@@ -836,7 +836,7 @@
};
snvs_pwrkey: snvs-powerkey {
- compatible = "fsl,sec-v4.0-pwrkey";
+ compatible = "fsl,imx6qdl-snvs-pwrkey";
regmap = <&snvs>;
interrupts = <GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>;
linux,keycode = <KEY_POWER>;
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v2 1/2] input: keyboard: snvs_pwrkey: Send key events for i.MX6 S, DL and Q
From: Robin van der Gracht @ 2019-08-27 12:32 UTC (permalink / raw)
To: Robin Gong
Cc: Mark Rutland, devicetree @ vger . kernel . org,
Robin van der Gracht, Shawn Guo, Sascha Hauer, Dmitry Torokhov,
linux-kernel @ vger . kernel . org, Rob Herring, dl-linux-imx,
Pengutronix Kernel Team, linux-input @ vger . kernel . org,
Adam Ford, Fabio Estevam,
linux-arm-kernel @ lists . infradead . org
The first generation i.MX6 processors does not send an interrupt when the
power key is pressed. It sends a power down request interrupt if the key is
released before a hard shutdown (5 second press). This should allow
software to bring down the SoC safely.
For this driver to work as a regular power key with the older SoCs, we need
to send a keypress AND release when we get the power down request irq.
Signed-off-by: Robin van der Gracht <robin@protonic.nl>
---
.../devicetree/bindings/crypto/fsl-sec4.txt | 16 ++++--
drivers/input/keyboard/Kconfig | 2 +-
drivers/input/keyboard/snvs_pwrkey.c | 52 ++++++++++++++++---
3 files changed, 57 insertions(+), 13 deletions(-)
diff --git a/Documentation/devicetree/bindings/crypto/fsl-sec4.txt b/Documentation/devicetree/bindings/crypto/fsl-sec4.txt
index 2fe245ca816a..e4fbb9797082 100644
--- a/Documentation/devicetree/bindings/crypto/fsl-sec4.txt
+++ b/Documentation/devicetree/bindings/crypto/fsl-sec4.txt
@@ -420,14 +420,22 @@ EXAMPLE
=====================================================================
System ON/OFF key driver
- The snvs-pwrkey is designed to enable POWER key function which controlled
- by SNVS ONOFF, the driver can report the status of POWER key and wakeup
- system if pressed after system suspend.
+ The snvs-pwrkey is designed to enable POWER key function which is controlled
+ by SNVS ONOFF. It can wakeup the system if pressed after system suspend.
+
+ There are two generations of SVNS pwrkey hardware. The first generation is
+ included in i.MX6 Solo, DualLite and Quad processors. The second generation
+ is included in i.MX6 SoloX and newer SoCs.
+
+ Second generation SNVS can detect and report the status of POWER key, but the
+ first generation can only detect a key release and so emits an instantaneous
+ press and release event when the key is released.
- compatible:
Usage: required
Value type: <string>
- Definition: Mush include "fsl,sec-v4.0-pwrkey".
+ Definition: Must include "fsl,sec-v4.0-pwrkey" for i.MX6 SoloX and newer
+ or "fsl,imx6qdl-snvs-pwrkey" for older SoCs.
- interrupts:
Usage: required
diff --git a/drivers/input/keyboard/Kconfig b/drivers/input/keyboard/Kconfig
index 7c4f19dab34f..937e58da5ce1 100644
--- a/drivers/input/keyboard/Kconfig
+++ b/drivers/input/keyboard/Kconfig
@@ -436,7 +436,7 @@ config KEYBOARD_SNVS_PWRKEY
depends on OF
help
This is the snvs powerkey driver for the Freescale i.MX application
- processors that are newer than i.MX6 SX.
+ processors.
To compile this driver as a module, choose M here; the
module will be called snvs_pwrkey.
diff --git a/drivers/input/keyboard/snvs_pwrkey.c b/drivers/input/keyboard/snvs_pwrkey.c
index 5342d8d45f81..d71c44733103 100644
--- a/drivers/input/keyboard/snvs_pwrkey.c
+++ b/drivers/input/keyboard/snvs_pwrkey.c
@@ -29,6 +29,11 @@
#define DEBOUNCE_TIME 30
#define REPEAT_INTERVAL 60
+enum imx_snvs_hwtype {
+ IMX6SX_SNVS, /* i.MX6 SoloX and newer */
+ IMX6QDL_SNVS, /* i.MX6 Solo, DualLite and Quad */
+};
+
struct pwrkey_drv_data {
struct regmap *snvs;
int irq;
@@ -37,14 +42,41 @@ struct pwrkey_drv_data {
int wakeup;
struct timer_list check_timer;
struct input_dev *input;
+ enum imx_snvs_hwtype hwtype;
};
+static const struct of_device_id imx_snvs_pwrkey_ids[] = {
+ {
+ .compatible = "fsl,sec-v4.0-pwrkey",
+ .data = (const void *)IMX6SX_SNVS,
+ },
+ {
+ .compatible = "fsl,imx6qdl-snvs-pwrkey",
+ .data = (const void *)IMX6QDL_SNVS,
+ },
+ { /* sentinel */ },
+};
+MODULE_DEVICE_TABLE(of, imx_snvs_pwrkey_ids);
+
static void imx_imx_snvs_check_for_events(struct timer_list *t)
{
struct pwrkey_drv_data *pdata = from_timer(pdata, t, check_timer);
struct input_dev *input = pdata->input;
u32 state;
+ if (pdata->hwtype == IMX6QDL_SNVS) {
+ /*
+ * The first generation i.MX6 SoCs only sends an interrupt on
+ * button release. To mimic power-key usage, we'll prepend a
+ * press event.
+ */
+ input_report_key(input, pdata->keycode, 1);
+ input_report_key(input, pdata->keycode, 0);
+ input_sync(input);
+ pm_relax(input->dev.parent);
+ return;
+ }
+
regmap_read(pdata->snvs, SNVS_HPSR_REG, &state);
state = state & SNVS_HPSR_BTN ? 1 : 0;
@@ -67,13 +99,17 @@ static irqreturn_t imx_snvs_pwrkey_interrupt(int irq, void *dev_id)
{
struct platform_device *pdev = dev_id;
struct pwrkey_drv_data *pdata = platform_get_drvdata(pdev);
+ unsigned long expire = jiffies;
u32 lp_status;
pm_wakeup_event(pdata->input->dev.parent, 0);
regmap_read(pdata->snvs, SNVS_LPSR_REG, &lp_status);
- if (lp_status & SNVS_LPSR_SPO)
- mod_timer(&pdata->check_timer, jiffies + msecs_to_jiffies(DEBOUNCE_TIME));
+ if (lp_status & SNVS_LPSR_SPO) {
+ if (pdata->hwtype == IMX6SX_SNVS)
+ expire += msecs_to_jiffies(DEBOUNCE_TIME);
+ mod_timer(&pdata->check_timer, expire);
+ }
/* clear SPO status */
regmap_write(pdata->snvs, SNVS_LPSR_REG, SNVS_LPSR_SPO);
@@ -93,6 +129,7 @@ static int imx_snvs_pwrkey_probe(struct platform_device *pdev)
struct pwrkey_drv_data *pdata = NULL;
struct input_dev *input = NULL;
struct device_node *np;
+ const struct of_device_id *match;
int error;
/* Get SNVS register Page */
@@ -100,6 +137,10 @@ static int imx_snvs_pwrkey_probe(struct platform_device *pdev)
if (!np)
return -ENODEV;
+ match = of_match_node(imx_snvs_pwrkey_ids, np);
+ if (!match)
+ return -ENODEV;
+
pdata = devm_kzalloc(&pdev->dev, sizeof(*pdata), GFP_KERNEL);
if (!pdata)
return -ENOMEM;
@@ -115,6 +156,7 @@ static int imx_snvs_pwrkey_probe(struct platform_device *pdev)
dev_warn(&pdev->dev, "KEY_POWER without setting in dts\n");
}
+ pdata->hwtype = (enum imx_snvs_hwtype)match->data;
pdata->wakeup = of_property_read_bool(np, "wakeup-source");
pdata->irq = platform_get_irq(pdev, 0);
@@ -175,12 +217,6 @@ static int imx_snvs_pwrkey_probe(struct platform_device *pdev)
return 0;
}
-static const struct of_device_id imx_snvs_pwrkey_ids[] = {
- { .compatible = "fsl,sec-v4.0-pwrkey" },
- { /* sentinel */ }
-};
-MODULE_DEVICE_TABLE(of, imx_snvs_pwrkey_ids);
-
static struct platform_driver imx_snvs_pwrkey_driver = {
.driver = {
.name = "snvs_pwrkey",
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH] dt-bindings: mmc: aspeed: Update example ranges property
From: Rob Herring @ 2019-08-27 12:36 UTC (permalink / raw)
To: Andrew Jeffery
Cc: Mark Rutland, devicetree, Ulf Hansson, linux-aspeed, linux-mmc,
linux-kernel@vger.kernel.org, Joel Stanley,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <20190826021620.11915-1-andrew@aj.id.au>
On Sun, Aug 25, 2019 at 9:15 PM Andrew Jeffery <andrew@aj.id.au> wrote:
>
> The example node in the binding uses the AST2500 compatible string for
> the SD controller with a 64kiB ranges property, but the SD controller is
> allocated 128kiB of MMIO space according to the AST2500 datasheet. Fix
> the example to correctly reflect the hardware in the AST2500, however it
> should be noted that the MMIO region is reduced to 64kiB in the AST2600
> where a second SD controller block has been introduced into the address
> space.
>
> Also add the IBM copyright header that I left out of the initial patch.
>
> Suggested-by: Joel Stanley <joel@jms.id.au>
> Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
> ---
> Hi Ulf, this is the follow-up fix as discussed here:
>
> http://patchwork.ozlabs.org/patch/1143090/
>
> Documentation/devicetree/bindings/mmc/aspeed,sdhci.yaml | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
Acked-by: Rob Herring <robh@kernel.org>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 10/10] arm64: Retrieve stolen time as paravirtualized guest
From: Zenghui Yu @ 2019-08-27 12:43 UTC (permalink / raw)
To: Steven Price, Marc Zyngier, Will Deacon, linux-arm-kernel, kvmarm
Cc: kvm, linux-doc, Catalin Marinas, linux-kernel, Russell King,
Paolo Bonzini
In-Reply-To: <29cd1304-6b4d-05ef-3c08-6b4ba769c8fa@arm.com>
On 2019/8/23 22:22, Steven Price wrote:
> On 23/08/2019 12:45, Zenghui Yu wrote:
>> Hi Steven,
>>
>> On 2019/8/21 23:36, Steven Price wrote:
>>> Enable paravirtualization features when running under a hypervisor
>>> supporting the PV_TIME_ST hypercall.
>>>
>>> For each (v)CPU, we ask the hypervisor for the location of a shared
>>> page which the hypervisor will use to report stolen time to us. We set
>>> pv_time_ops to the stolen time function which simply reads the stolen
>>> value from the shared page for a VCPU. We guarantee single-copy
>>> atomicity using READ_ONCE which means we can also read the stolen
>>> time for another VCPU than the currently running one while it is
>>> potentially being updated by the hypervisor.
>>>
>>> Signed-off-by: Steven Price <steven.price@arm.com>
>>> ---
>>> arch/arm64/include/asm/paravirt.h | 9 +-
>>> arch/arm64/kernel/paravirt.c | 148 ++++++++++++++++++++++++++++++
>>> arch/arm64/kernel/time.c | 3 +
>>> include/linux/cpuhotplug.h | 1 +
>>> 4 files changed, 160 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/arch/arm64/include/asm/paravirt.h
>>> b/arch/arm64/include/asm/paravirt.h
>>> index 799d9dd6f7cc..125c26c42902 100644
>>> --- a/arch/arm64/include/asm/paravirt.h
>>> +++ b/arch/arm64/include/asm/paravirt.h
>>> @@ -21,6 +21,13 @@ static inline u64 paravirt_steal_clock(int cpu)
>>> {
>>> return pv_ops.time.steal_clock(cpu);
>>> }
>>> -#endif
>>> +
>>> +int __init kvm_guest_init(void);
>>> +
>>> +#else
>>> +
>>> +#define kvm_guest_init()
>>> +
>>> +#endif // CONFIG_PARAVIRT
>>> #endif
>>> diff --git a/arch/arm64/kernel/paravirt.c b/arch/arm64/kernel/paravirt.c
>>> index 4cfed91fe256..ea8dbbbd3293 100644
>>> --- a/arch/arm64/kernel/paravirt.c
>>> +++ b/arch/arm64/kernel/paravirt.c
>>> @@ -6,13 +6,161 @@
>>> * Author: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>>> */
>>> +#define pr_fmt(fmt) "kvmarm-pv: " fmt
>>> +
>>> +#include <linux/arm-smccc.h>
>>> +#include <linux/cpuhotplug.h>
>>> #include <linux/export.h>
>>> +#include <linux/io.h>
>>> #include <linux/jump_label.h>
>>> +#include <linux/printk.h>
>>> +#include <linux/psci.h>
>>> +#include <linux/reboot.h>
>>> +#include <linux/slab.h>
>>> #include <linux/types.h>
>>> +
>>> #include <asm/paravirt.h>
>>> +#include <asm/pvclock-abi.h>
>>> +#include <asm/smp_plat.h>
>>> struct static_key paravirt_steal_enabled;
>>> struct static_key paravirt_steal_rq_enabled;
>>> struct paravirt_patch_template pv_ops;
>>> EXPORT_SYMBOL_GPL(pv_ops);
>>> +
>>> +struct kvmarm_stolen_time_region {
>>> + struct pvclock_vcpu_stolen_time *kaddr;
>>> +};
>>> +
>>> +static DEFINE_PER_CPU(struct kvmarm_stolen_time_region,
>>> stolen_time_region);
>>> +
>>> +static bool steal_acc = true;
>>> +static int __init parse_no_stealacc(char *arg)
>>> +{
>>> + steal_acc = false;
>>> + return 0;
>>> +}
>>> +
>>> +early_param("no-steal-acc", parse_no_stealacc);
>>> +
>>> +/* return stolen time in ns by asking the hypervisor */
>>> +static u64 kvm_steal_clock(int cpu)
>>> +{
>>> + struct kvmarm_stolen_time_region *reg;
>>> +
>>> + reg = per_cpu_ptr(&stolen_time_region, cpu);
>>> + if (!reg->kaddr) {
>>> + pr_warn_once("stolen time enabled but not configured for cpu
>>> %d\n",
>>> + cpu);
>>> + return 0;
>>> + }
>>> +
>>> + return le64_to_cpu(READ_ONCE(reg->kaddr->stolen_time));
>>> +}
>>> +
>>> +static int disable_stolen_time_current_cpu(void)
>>> +{
>>> + struct kvmarm_stolen_time_region *reg;
>>> +
>>> + reg = this_cpu_ptr(&stolen_time_region);
>>> + if (!reg->kaddr)
>>> + return 0;
>>> +
>>> + memunmap(reg->kaddr);
>>> + memset(reg, 0, sizeof(*reg));
>>> +
>>> + return 0;
>>> +}
>>> +
>>> +static int stolen_time_dying_cpu(unsigned int cpu)
>>> +{
>>> + return disable_stolen_time_current_cpu();
>>> +}
>>> +
>>> +static int init_stolen_time_cpu(unsigned int cpu)
>>> +{
>>> + struct kvmarm_stolen_time_region *reg;
>>> + struct arm_smccc_res res;
>>> +
>>> + reg = this_cpu_ptr(&stolen_time_region);
>>> +
>>> + arm_smccc_1_1_invoke(ARM_SMCCC_HV_PV_TIME_ST, &res);
>>> +
>>> + if ((long)res.a0 < 0)
>>> + return -EINVAL;
>>> +
>>> + reg->kaddr = memremap(res.a0,
>>> + sizeof(struct pvclock_vcpu_stolen_time),
>>> + MEMREMAP_WB);
>>
>> cpuhp callbacks can be invoked in atomic context (see:
>> secondary_start_kernel ->
>> notify_cpu_starting ->
>> invoke callbacks),
>> but memremap might sleep...
>>
>> Try to run a DEBUG_ATOMIC_SLEEP enabled PV guest, I guess we will be
>> greeted by the Sleep-in-Atomic-Context BUG. We need an alternative
>> here?
>
> Actually I had run DEBUG_ATOMIC_SLEEP and not seen any issue. But I
> think that's because of the way I've configured the region in my kvmtool
> changes. I'm hitting the path where the memory region is in the linear
> map of the kernel and so no actual remapping is needed and hence
> memremap doesn't sleep (the shared structure is in a reserved region of
> RAM).
>
> But even changing the memory layout of the guest so the call goes into
> ioremap_page_range() (which contains a might_sleep()) I'm not seeing any
> problems.
Emm, I hit this SAC BUG when testing your V1 with the kvmtool changes
you've provided, but forgot to report it at that time. I go back to V1
and get the following call trace:
[ 0.120113] BUG: sleeping function called from invalid context at
mm/slab.h:501
[ 0.120118] in_atomic(): 1, irqs_disabled(): 128, pid: 0, name: swapper/1
[ 0.120122] no locks held by swapper/1/0.
[ 0.120126] irq event stamp: 0
[ 0.120135] hardirqs last enabled at (0): [<0000000000000000>] 0x0
[ 0.120145] hardirqs last disabled at (0): [<ffff200010113b40>]
copy_process+0x870/0x2878
[ 0.120152] softirqs last enabled at (0): [<ffff200010113b40>]
copy_process+0x870/0x2878
[ 0.120157] softirqs last disabled at (0): [<0000000000000000>] 0x0
[ 0.120164] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 5.3.0-rc6+ #2
[ 0.120168] Hardware name: linux,dummy-virt (DT)
[ 0.120173] Call trace:
[ 0.120179] dump_backtrace+0x0/0x250
[ 0.120184] show_stack+0x24/0x30
[ 0.120192] dump_stack+0x120/0x174
[ 0.120198] ___might_sleep+0x1b0/0x280
[ 0.120203] __might_sleep+0x80/0xf0
[ 0.120209] kmem_cache_alloc_node_trace+0x30c/0x3c8
[ 0.120216] __get_vm_area_node+0x9c/0x208
[ 0.120221] get_vm_area_caller+0x58/0x68
[ 0.120227] __ioremap_caller+0x78/0x120
[ 0.120233] ioremap_cache+0xf0/0x1a8
[ 0.120240] memremap+0x154/0x3b8
[ 0.120245] init_stolen_time_cpu+0x94/0x150
[ 0.120251] cpuhp_invoke_callback+0x12c/0x12f8
[ 0.120257] notify_cpu_starting+0xa0/0xc0
[ 0.120263] secondary_start_kernel+0x1d4/0x328
But things may have changed because we're talking about V3 now...
I will dig it a bit deeper.
> Am I missing something? I have to admit I don't entirely follow the
> early start up - perhaps it's a simple as DEBUG_ATOMIC_SLEEP doesn't
> work this early in boot?
I think it should work.
Thanks,
zenghui
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 3/4] watchdog/aspeed: add support for dual boot
From: Guenter Roeck @ 2019-08-27 13:06 UTC (permalink / raw)
To: Ivan Mikhaylov, Wim Van Sebroeck
Cc: Mark Rutland, devicetree, linux-watchdog, linux-aspeed,
Andrew Jeffery, openbmc, Alexander Amelkin, linux-kernel,
Rob Herring, Joel Stanley, linux-arm-kernel
In-Reply-To: <818746d20661b51914a7802dcbe0081352900b05.camel@yadro.com>
On 8/27/19 2:24 AM, Ivan Mikhaylov wrote:
> On Mon, 2019-08-26 at 17:14 -0700, Guenter Roeck wrote:
>>> +/*
>>> + * At alternate side the 'access_cs0' sysfs node provides:
>>> + * ast2400: a way to get access to the primary SPI flash chip at CS0
>>> + * after booting from the alternate chip at CS1.
>>> + * ast2500: a way to restore the normal address mapping from
>>> + * (CS0->CS1, CS1->CS0) to (CS0->CS0, CS1->CS1).
>>> + *
>>> + * Clearing the boot code selection and timeout counter also resets to the
>>> + * initial state the chip select line mapping. When the SoC is in normal
>>> + * mapping state (i.e. booted from CS0), clearing those bits does nothing
>>> for
>>> + * both versions of the SoC. For alternate boot mode (booted from CS1 due
>>> to
>>> + * wdt2 expiration) the behavior differs as described above.
>>> + *
>> The above needs to be in the sysfs attribute documentation as well.
>
> My apologies but I didn't find any suitable, only watchdog parameters with
> dtbindings file, where should I put it? Documentation/watchdog/aspeed-wdt-
> sysfs.rst?
>
Documentation/ABI/testing/sysfs-class-watchdog
Guenter
>>> + * This option can be used with wdt2 (watchdog1) only.
>>
>> This implies a specific watchdog numbering which is not guaranteed.
>> Someone might implement a system with some external watchdog.
>>
>>> + */
>>> +static DEVICE_ATTR_RW(access_cs0);
>>> +
>>> +static struct attribute *bswitch_attrs[] = {
>>> + &dev_attr_access_cs0.attr,
>>> + NULL
>>> +};
>>> +ATTRIBUTE_GROUPS(bswitch);
>>> +
>>> static const struct watchdog_ops aspeed_wdt_ops = {
>>> .start = aspeed_wdt_start,
>>> .stop = aspeed_wdt_stop,
>>> @@ -306,9 +359,16 @@ static int aspeed_wdt_probe(struct platform_device
>>> *pdev)
>>> }
>>>
>>> status = readl(wdt->base + WDT_TIMEOUT_STATUS);
>>> - if (status & WDT_TIMEOUT_STATUS_BOOT_SECONDARY)
>>> + if (status & WDT_TIMEOUT_STATUS_BOOT_SECONDARY) {
>>> wdt->wdd.bootstatus = WDIOF_CARDRESET;
>>>
>>> + if (of_device_is_compatible(np, "aspeed,ast2400-wdt") ||
>>> + of_device_is_compatible(np, "aspeed,ast2500-wdt"))
>>> + wdt->wdd.groups = bswitch_groups;
>
>> Kind of odd that the attribute only exists if the system booted from the
>> second flash, but if that is what you want I won't object. Just make sure
>> that this is explained properly.
> Perhaps dts configuration option would be better solution for it then? "force-
> cs0-switch" as example? Also, if it would be an option, dtbindings/wdt file for
You said earlier that this can not be done automatically but _must_ be done
from user space after the system has booted. Otherwise you could just
automatically switch to cs0 when the driver probes.
As I said, all I am asking for is proper documentation.
Guenter
> documentation will be the right place for it. Usage of this at side 0 will not
> get any good/bad results, it just makes user confused, so I decided to put it
> only at side 1. It works only for ast2400/2500 board unfortunately, for 2600
> there is big difference in switching mechanism. Any other thoughts how to make
> it better?
>
> Thanks.
>
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: linux-next: Fixes tags need some work in the arm-soc tree
From: Arnd Bergmann @ 2019-08-27 13:07 UTC (permalink / raw)
To: Alexandre Torgue
Cc: Stephen Rothwell, Linux Kernel Mailing List,
Linux Next Mailing List, Olof Johansson, Fabrice Gasnier, ARM
In-Reply-To: <f4e0e924-03ea-bf63-85a0-5718874ceb38@st.com>
On Mon, Aug 26, 2019 at 11:44 AM Alexandre Torgue
<alexandre.torgue@st.com> wrote:
> On 8/13/19 11:47 PM, Stephen Rothwell wrote:
> > Hi Arnd,
> >
> > On Tue, 13 Aug 2019 21:35:58 +0200 Arnd Bergmann <arnd@arndb.de> wrote:
> >>
> >> On Tue, Aug 13, 2019 at 4:28 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >>
> >>>
> >>> Please do not split Fixes tags over more than one line. Also, please
> >>> keep them with the rest of the other tags.
> >>
> >> Thanks for the report. How bad is this? Should I undo the merge and
> >> wait for an updated pull request?
> >
> > Its probably ok to leave as long as lessons are learnt :-)
> >
>
> Sorry for my late answer.
>
> Thanks Stephen for information. I'll take care next time before merging
> patches with "fixes" tag.
>
> Arnd, no need to update the PR ?
No, since it's already pulled, just leave it for this time.
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 01/10] PCI: designware-ep: Add multiple PFs support for DWC
From: Andrew Murray @ 2019-08-27 13:10 UTC (permalink / raw)
To: Xiaowei Bao
Cc: mark.rutland@arm.com, Roy Zang, lorenzo.pieralisi@arm.co,
arnd@arndb.de, devicetree@vger.kernel.org,
gregkh@linuxfoundation.org, linuxppc-dev@lists.ozlabs.org,
linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
kishon@ti.com, M.h. Lian, robh+dt@kernel.org,
gustavo.pimentel@synopsys.com, jingoohan1@gmail.com,
bhelgaas@google.com, Leo Li, shawnguo@kernel.org, Mingkai Hu,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <AM5PR04MB32997FFCD08E2C34541D2F9BF5A40@AM5PR04MB3299.eurprd04.prod.outlook.com>
On Fri, Aug 23, 2019 at 11:50:20PM +0000, Xiaowei Bao wrote:
>
>
> > -----Original Message-----
> > From: Andrew Murray <andrew.murray@arm.com>
> > Sent: 2019年8月23日 21:25
> > To: Xiaowei Bao <xiaowei.bao@nxp.com>
> > Cc: bhelgaas@google.com; robh+dt@kernel.org; mark.rutland@arm.com;
> > shawnguo@kernel.org; Leo Li <leoyang.li@nxp.com>; kishon@ti.com;
> > lorenzo.pieralisi@arm.co; arnd@arndb.de; gregkh@linuxfoundation.org; M.h.
> > Lian <minghuan.lian@nxp.com>; Mingkai Hu <mingkai.hu@nxp.com>; Roy
> > Zang <roy.zang@nxp.com>; jingoohan1@gmail.com;
> > gustavo.pimentel@synopsys.com; linux-pci@vger.kernel.org;
> > devicetree@vger.kernel.org; linux-kernel@vger.kernel.org;
> > linux-arm-kernel@lists.infradead.org; linuxppc-dev@lists.ozlabs.org
> > Subject: Re: [PATCH v2 01/10] PCI: designware-ep: Add multiple PFs support
> > for DWC
> >
> > On Thu, Aug 22, 2019 at 07:22:33PM +0800, Xiaowei Bao wrote:
> > > Add multiple PFs support for DWC, different PF have different config
> > > space we use pf-offset property which get from the DTS to access the
> > > different pF config space.
> >
> > It looks like you're missing a --cover-letter again.
> >
> > >
> > > Signed-off-by: Xiaowei Bao <xiaowei.bao@nxp.com>
> > > ---
> > > v2:
> > > - Remove duplicate redundant code.
> > > - Reimplement the PF config space access way.
> > >
> > > drivers/pci/controller/dwc/pcie-designware-ep.c | 122
> > ++++++++++++++++--------
> > > drivers/pci/controller/dwc/pcie-designware.c | 59 ++++++++----
> > > drivers/pci/controller/dwc/pcie-designware.h | 11 ++-
> > > 3 files changed, 134 insertions(+), 58 deletions(-)
> > >
> > > diff --git a/drivers/pci/controller/dwc/pcie-designware-ep.c
> > > b/drivers/pci/controller/dwc/pcie-designware-ep.c
> > > index 2bf5a35..3e2b740 100644
> > > --- a/drivers/pci/controller/dwc/pcie-designware-ep.c
> > > +++ b/drivers/pci/controller/dwc/pcie-designware-ep.c
> > > @@ -19,12 +19,17 @@ void dw_pcie_ep_linkup(struct dw_pcie_ep *ep)
> > > pci_epc_linkup(epc);
> > > }
> > >
> > > -static void __dw_pcie_ep_reset_bar(struct dw_pcie *pci, enum pci_barno
> > bar,
> > > - int flags)
> > > +static void __dw_pcie_ep_reset_bar(struct dw_pcie *pci, u8 func_no,
> > > + enum pci_barno bar, int flags)
> > > {
> > > u32 reg;
> > > + unsigned int func_offset = 0;
> > > + struct dw_pcie_ep *ep = &pci->ep;
> > >
> > > - reg = PCI_BASE_ADDRESS_0 + (4 * bar);
> > > + if (ep->ops->func_conf_select)
> > > + func_offset = ep->ops->func_conf_select(ep, func_no);
> > > +
> > > + reg = func_offset + PCI_BASE_ADDRESS_0 + (4 * bar);
> >
> > This pattern of checking if func_conf_select exists and using it to get an offset
> > is repeated a lot throughout this file. You could move this functionality into a
> > new function (similar to dw_pcie_read_dbi etc). Or perhaps a new variant of
> > dw_pcie_writel_ should be created that writes takes a func_no argument.
>
> Thanks for your comments, I thought about this method before, but there is a issue
> about the method of access the different func config space, due to our platform use
> this method that different func have different offset from dbi_base to access the
> different config space, but others platform maybe use the way that write a register
> to implement different func config space access, so I think reserve a callback function
My point here was really to move out duplicated code to its own small function.
I wasn't making any comment about (removing) the callback, just that the test and
callback could be in one function.
> to different platform to implement the own method, my point is that, if use register
> method they can implement the code in this function and return offset is 0, if use
> offset method, they can return the offset value which can be use by dw_pcie_ep driver.
By the way, I haven't looked to see how many of the dw_pcie_write_xxx functions
would benefit from a func_no argument - if there were many calls to
dw_pcie_write_xxx that all used a reg value originated from func_conf_select
then an approach similar to the implementation of dw_pcie_write_dbi could
probably be justified (i.e. rather than change the value of reg) for writing to
functions.
>
> >
> >
> > > dw_pcie_dbi_ro_wr_en(pci);
> > > dw_pcie_writel_dbi2(pci, reg, 0x0);
> > > dw_pcie_writel_dbi(pci, reg, 0x0);
> >
> >
> > > @@ -235,7 +257,7 @@ static int dw_pcie_ep_map_addr(struct pci_epc
> > *epc, u8 func_no,
> > > struct dw_pcie_ep *ep = epc_get_drvdata(epc);
> > > struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
> > >
> > > - ret = dw_pcie_ep_outbound_atu(ep, addr, pci_addr, size);
> > > + ret = dw_pcie_ep_outbound_atu(ep, func_no, addr, pci_addr, size);
> > > if (ret) {
> > > dev_err(pci->dev, "Failed to enable address\n");
> > > return ret;
> > > @@ -249,11 +271,15 @@ static int dw_pcie_ep_get_msi(struct pci_epc
> > *epc, u8 func_no)
> > > struct dw_pcie_ep *ep = epc_get_drvdata(epc);
> > > struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
> > > u32 val, reg;
> > > + unsigned int func_offset = 0;
> > > +
> > > + if (ep->ops->func_conf_select)
> > > + func_offset = ep->ops->func_conf_select(ep, func_no);
> > >
> > > if (!ep->msi_cap)
> > > return -EINVAL;
> > >
> > > - reg = ep->msi_cap + PCI_MSI_FLAGS;
> > > + reg = ep->msi_cap + func_offset + PCI_MSI_FLAGS;
> >
> > This makes me nervous.
> >
> > From a PCI viewpoint, each function has it's own capability structure and
> > within each function there may exist a MSI capability. Yet what we're doing
> > here is using dw_pcie_ep_find_capability to get the list of capabilities for
> > function 0, and then applying offsets from that for subsequent functions. I.e.
> > we're applying DW specific knowledge to find the correct capability, rather
> > than following the general PCI approach.
> >
> > I think the above hunk shouldn't be required - but instead
> > dw_pcie_ep_find_capability is updated to take a func_no parameter.
> >
> > Have I understood this correctly?
>
> Yes, this is a issue, I think the different func maybe have different capability,
> but the dw_pcie_ep_find_capability function is called by dw_pcie_ep_init
> function, we can't add func_no parameter to dw_pcie_ep_find_capability,
Why not?
Given that 'struct dw_pcie' represents a controller - and thus potentially
multiple functions - then the _find_capability function should be able to
provide the correct offset for the given function. Surely it needs to know
which function number? Unless there is some reason why we can assume that all
functions share the same capability offset.
Also the 'struct dw_pcie_ep' which represents an endpoint controller - this
has msi_cap and msix_cap fields - given this may be a multifunction device
what do these fields actually refer to?
Perhaps Jungoo/Gustavo can comment.
> I will try to fix it use a new patch, I think move this function to ep_init callback
> function If better, thanks.
>
>
> >
> > > val = dw_pcie_readw_dbi(pci, reg);
> > > if (!(val & PCI_MSI_FLAGS_ENABLE))
> > > return -EINVAL;
> > > @@ -268,11 +294,15 @@ static int dw_pcie_ep_set_msi(struct pci_epc
> > *epc, u8 func_no, u8 interrupts)
> > > struct dw_pcie_ep *ep = epc_get_drvdata(epc);
> > > struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
> > > u32 val, reg;
> > > + unsigned int func_offset = 0;
> > > +
> > > + if (ep->ops->func_conf_select)
> > > + func_offset = ep->ops->func_conf_select(ep, func_no);
> > >
> > > if (!ep->msi_cap)
> > > return -EINVAL;
> > >
> > > - reg = ep->msi_cap + PCI_MSI_FLAGS;
> > > + reg = ep->msi_cap + func_offset + PCI_MSI_FLAGS;
> > > val = dw_pcie_readw_dbi(pci, reg);
> > > val &= ~PCI_MSI_FLAGS_QMASK;
> > > val |= (interrupts << 1) & PCI_MSI_FLAGS_QMASK; @@ -288,11 +318,15
> > > @@ static int dw_pcie_ep_get_msix(struct pci_epc *epc, u8 func_no)
> > > struct dw_pcie_ep *ep = epc_get_drvdata(epc);
> > > struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
> > > u32 val, reg;
> > > + unsigned int func_offset = 0;
> > > +
> > > + if (ep->ops->func_conf_select)
> > > + func_offset = ep->ops->func_conf_select(ep, func_no);
> > >
> > > if (!ep->msix_cap)
> > > return -EINVAL;
> > >
> > > - reg = ep->msix_cap + PCI_MSIX_FLAGS;
> > > + reg = ep->msix_cap + func_offset + PCI_MSIX_FLAGS;
> >
> > Same for MSIX.
>
> Yes.
>
> >
> > > val = dw_pcie_readw_dbi(pci, reg);
> > > if (!(val & PCI_MSIX_FLAGS_ENABLE))
> > > return -EINVAL;
> > > @@ -307,11 +341,15 @@ static int dw_pcie_ep_set_msix(struct pci_epc
> > *epc, u8 func_no, u16 interrupts)
> > > struct dw_pcie_ep *ep = epc_get_drvdata(epc);
> > > struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
> > > u32 val, reg;
> > > + unsigned int func_offset = 0;
> > > +
> > > + if (ep->ops->func_conf_select)
> > > + func_offset = ep->ops->func_conf_select(ep, func_no);
> > >
> > > if (!ep->msix_cap)
> > > return -EINVAL;
> > >
> > > - reg = ep->msix_cap + PCI_MSIX_FLAGS;
> > > + reg = ep->msix_cap + func_offset + PCI_MSIX_FLAGS;
> > > val = dw_pcie_readw_dbi(pci, reg);
> > > val &= ~PCI_MSIX_FLAGS_QSIZE;
> > > val |= interrupts;
> > > @@ -398,29 +436,33 @@ int dw_pcie_ep_raise_msi_irq(struct
> > dw_pcie_ep *ep, u8 func_no,
> > > struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
> > > struct pci_epc *epc = ep->epc;
> > > unsigned int aligned_offset;
> > > + unsigned int func_offset = 0;
> > > u16 msg_ctrl, msg_data;
> > > u32 msg_addr_lower, msg_addr_upper, reg;
> > > u64 msg_addr;
> > > bool has_upper;
> > > int ret;
> > >
> > > + if (ep->ops->func_conf_select)
> > > + func_offset = ep->ops->func_conf_select(ep, func_no);
> > > +
> >
> > You could probably move this hunk below the test for msi_cap to save some
> > cycles.
>
> Sorry, I didn't understand the means, please explain it detailly, thanks a lot, ^_^
If you insert the call to func_conf_select *after* the test for
!msi_cap below - then in the case where msi_cap is NULL then you will
save some CPU cycles by not bothering to call func_conf_select.
> >
> > > if (!ep->msi_cap)
> > > return -EINVAL;
> > >
> > > /* Raise MSI per the PCI Local Bus Specification Revision 3.0, 6.8.1. */
> > > - reg = ep->msi_cap + PCI_MSI_FLAGS;
> > > + reg = ep->msi_cap + func_offset + PCI_MSI_FLAGS;
> > > msg_ctrl = dw_pcie_readw_dbi(pci, reg);
> > > has_upper = !!(msg_ctrl & PCI_MSI_FLAGS_64BIT);
> > > - reg = ep->msi_cap + PCI_MSI_ADDRESS_LO;
> > > + reg = ep->msi_cap + func_offset + PCI_MSI_ADDRESS_LO;
> > > msg_addr_lower = dw_pcie_readl_dbi(pci, reg);
> > > if (has_upper) {
> > > - reg = ep->msi_cap + PCI_MSI_ADDRESS_HI;
> > > + reg = ep->msi_cap + func_offset + PCI_MSI_ADDRESS_HI;
> > > msg_addr_upper = dw_pcie_readl_dbi(pci, reg);
> > > - reg = ep->msi_cap + PCI_MSI_DATA_64;
> > > + reg = ep->msi_cap + func_offset + PCI_MSI_DATA_64;
> > > msg_data = dw_pcie_readw_dbi(pci, reg);
> > > } else {
> > > msg_addr_upper = 0;
> > > - reg = ep->msi_cap + PCI_MSI_DATA_32;
> > > + reg = ep->msi_cap + func_offset + PCI_MSI_DATA_32;
> > > msg_data = dw_pcie_readw_dbi(pci, reg);
> > > }
> > > aligned_offset = msg_addr_lower & (epc->mem->page_size - 1);
> >
> >
> >
> > > diff --git a/drivers/pci/controller/dwc/pcie-designware.c
> > > b/drivers/pci/controller/dwc/pcie-designware.c
> > > index 7d25102..305e73d 100644
> > > --- a/drivers/pci/controller/dwc/pcie-designware.c
> > > +++ b/drivers/pci/controller/dwc/pcie-designware.c
> > > @@ -158,9 +158,10 @@ static void dw_pcie_writel_ob_unroll(struct
> > dw_pcie *pci, u32 index, u32 reg,
> > > dw_pcie_writel_atu(pci, offset + reg, val); }
> > >
> > > -static void dw_pcie_prog_outbound_atu_unroll(struct dw_pcie *pci, int
> > index,
> > > - int type, u64 cpu_addr,
> > > - u64 pci_addr, u32 size)
> > > +static void dw_pcie_prog_outbound_atu_unroll(struct dw_pcie *pci, u8
> > func_no,
> > > + int index, int type,
> > > + u64 cpu_addr, u64 pci_addr,
> > > + u32 size)
> > > {
> > > u32 retries, val;
> > >
> > > @@ -175,7 +176,7 @@ static void
> > dw_pcie_prog_outbound_atu_unroll(struct dw_pcie *pci, int index,
> > > dw_pcie_writel_ob_unroll(pci, index, PCIE_ATU_UNR_UPPER_TARGET,
> > > upper_32_bits(pci_addr));
> > > dw_pcie_writel_ob_unroll(pci, index, PCIE_ATU_UNR_REGION_CTRL1,
> > > - type);
> > > + type | PCIE_ATU_FUNC_NUM(func_no));
> >
> > Much better :)
>
> Do you mean that use the expression "a? b:c"
>
> >
> > > dw_pcie_writel_ob_unroll(pci, index, PCIE_ATU_UNR_REGION_CTRL2,
> > > PCIE_ATU_ENABLE);
> > >
> > > @@ -194,8 +195,9 @@ static void
> > dw_pcie_prog_outbound_atu_unroll(struct dw_pcie *pci, int index,
> > > dev_err(pci->dev, "Outbound iATU is not being enabled\n"); }
> > >
> > > -void dw_pcie_prog_outbound_atu(struct dw_pcie *pci, int index, int type,
> > > - u64 cpu_addr, u64 pci_addr, u32 size)
> > > +static void __dw_pcie_prog_outbound_atu(struct dw_pcie *pci, u8
> > func_no,
> > > + int index, int type, u64 cpu_addr,
> > > + u64 pci_addr, u32 size)
> > > {
> > > u32 retries, val;
> > >
> > > @@ -203,8 +205,8 @@ void dw_pcie_prog_outbound_atu(struct dw_pcie
> > *pci, int index, int type,
> > > cpu_addr = pci->ops->cpu_addr_fixup(pci, cpu_addr);
> > >
> > > if (pci->iatu_unroll_enabled) {
> > > - dw_pcie_prog_outbound_atu_unroll(pci, index, type, cpu_addr,
> > > - pci_addr, size);
> > > + dw_pcie_prog_outbound_atu_unroll(pci, func_no, index, type,
> > > + cpu_addr, pci_addr, size);
> > > return;
> > > }
> > >
> >
> >
> > > diff --git a/drivers/pci/controller/dwc/pcie-designware.h
> > > b/drivers/pci/controller/dwc/pcie-designware.h
> > > index ffed084..a0fdbf7 100644
> > > --- a/drivers/pci/controller/dwc/pcie-designware.h
> > > +++ b/drivers/pci/controller/dwc/pcie-designware.h
> > > @@ -71,9 +71,11 @@
> > > #define PCIE_ATU_TYPE_IO 0x2
> > > #define PCIE_ATU_TYPE_CFG0 0x4
> > > #define PCIE_ATU_TYPE_CFG1 0x5
> > > +#define PCIE_ATU_FUNC_NUM(pf) (pf << 20)
> >
> > "Macro argument 'pf' may be better as '(pf)' to avoid precedence issues"
> >
> > > #define PCIE_ATU_CR2 0x908
> > > #define PCIE_ATU_ENABLE BIT(31)
> > > #define PCIE_ATU_BAR_MODE_ENABLE BIT(30)
> > > +#define PCIE_ATU_FUNC_NUM_MATCH_EN BIT(19)
> > > #define PCIE_ATU_LOWER_BASE 0x90C
> > > #define PCIE_ATU_UPPER_BASE 0x910
> > > #define PCIE_ATU_LIMIT 0x914
> > > @@ -197,6 +199,7 @@ struct dw_pcie_ep_ops {
> > > int (*raise_irq)(struct dw_pcie_ep *ep, u8 func_no,
> > > enum pci_epc_irq_type type, u16 interrupt_num);
> > > const struct pci_epc_features* (*get_features)(struct dw_pcie_ep
> > > *ep);
> > > + unsigned int (*func_conf_select)(struct dw_pcie_ep *ep, u8 func_no);
> >
> > Given that this function will return an offset, I'm not sure the name you have
> > is suitable. Something like get_pf_offset or similar is more descriptive.
>
> As above explain, my initial view is that this function can return 0 or offset depends on
> the platform implement mechanism, so I named it func_conf_select, I think add a
> comment for this function, like this:
> /*
> * provide a method to implement the method of different func config space access,
> * if use offset method, return the offset from dbi_base, if your register method, implement
> * the code in this callback function and return 0.
> */
> How about it?
This means that func_conf_select can never (easily) indicate an error to the
caller as this would change the offset. Where func_conf_select doesn't change
the offset there probably isn't much else it can do instead (unless it was
responsible for doing the write as well). So I'm not sure how well this approach
works.
Thanks,
Andrew Murray
>
> >
> > Thanks,
> >
> > Andrew Murray
> >
> > > };
> > >
> > > struct dw_pcie_ep {
> > > @@ -265,8 +268,12 @@ int dw_pcie_wait_for_link(struct dw_pcie *pci);
> > > void dw_pcie_prog_outbound_atu(struct dw_pcie *pci, int index,
> > > int type, u64 cpu_addr, u64 pci_addr,
> > > u32 size);
> > > -int dw_pcie_prog_inbound_atu(struct dw_pcie *pci, int index, int bar,
> > > - u64 cpu_addr, enum dw_pcie_as_type as_type);
> > > +void dw_pcie_prog_ep_outbound_atu(struct dw_pcie *pci, u8 func_no, int
> > index,
> > > + int type, u64 cpu_addr, u64 pci_addr,
> > > + u32 size);
> > > +int dw_pcie_prog_inbound_atu(struct dw_pcie *pci, u8 func_no, int index,
> > > + int bar, u64 cpu_addr,
> > > + enum dw_pcie_as_type as_type);
> > > void dw_pcie_disable_atu(struct dw_pcie *pci, int index,
> > > enum dw_pcie_region_type type);
> > > void dw_pcie_setup(struct dw_pcie *pci);
> > > --
> > > 2.9.5
> > >
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v4 1/2] dt-bindings: mailbox: add binding doc for the ARM SMC/HVC mailbox
From: Rob Herring @ 2019-08-27 13:13 UTC (permalink / raw)
To: Peng Fan
Cc: mark.rutland@arm.com, devicetree@vger.kernel.org,
f.fainelli@gmail.com, andre.przywara@arm.com,
jassisinghbrar@gmail.com, linux-kernel@vger.kernel.org,
dl-linux-imx, sudeep.holla@arm.com,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <1566942646-18015-2-git-send-email-peng.fan@nxp.com>
On Tue, Aug 27, 2019 at 4:51 AM Peng Fan <peng.fan@nxp.com> wrote:
>
> From: Peng Fan <peng.fan@nxp.com>
>
> The ARM SMC/HVC mailbox binding describes a firmware interface to trigger
> actions in software layers running in the EL2 or EL3 exception levels.
> The term "ARM" here relates to the SMC instruction as part of the ARM
> instruction set, not as a standard endorsed by ARM Ltd.
>
> Signed-off-by: Peng Fan <peng.fan@nxp.com>
> ---
> .../devicetree/bindings/mailbox/arm-smc.yaml | 126 +++++++++++++++++++++
> 1 file changed, 126 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mailbox/arm-smc.yaml
>
> diff --git a/Documentation/devicetree/bindings/mailbox/arm-smc.yaml b/Documentation/devicetree/bindings/mailbox/arm-smc.yaml
> new file mode 100644
> index 000000000000..ae677e0c0910
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mailbox/arm-smc.yaml
> @@ -0,0 +1,126 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/mailbox/arm-smc.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: ARM SMC Mailbox Interface
> +
> +maintainers:
> + - Peng Fan <peng.fan@nxp.com>
> +
> +description: |
> + This mailbox uses the ARM smc (secure monitor call) and hvc (hypervisor
> + call) instruction to trigger a mailbox-connected activity in firmware,
> + executing on the very same core as the caller. By nature this operation
> + is synchronous and this mailbox provides no way for asynchronous messages
> + to be delivered the other way round, from firmware to the OS, but
> + asynchronous notification could also be supported. However the value of
> + r0/w0/x0 the firmware returns after the smc call is delivered as a received
> + message to the mailbox framework, so a synchronous communication can be
> + established, for a asynchronous notification, no value will be returned.
> + The exact meaning of both the action the mailbox triggers as well as the
> + return value is defined by their users and is not subject to this binding.
> +
> + One use case of this mailbox is the SCMI interface, which uses shared memory
> + to transfer commands and parameters, and a mailbox to trigger a function
> + call. This allows SoCs without a separate management processor (or when
> + such a processor is not available or used) to use this standardized
> + interface anyway.
> +
> + This binding describes no hardware, but establishes a firmware interface.
> + Upon receiving an SMC using one of the described SMC function identifiers,
> + the firmware is expected to trigger some mailbox connected functionality.
> + The communication follows the ARM SMC calling convention.
> + Firmware expects an SMC function identifier in r0 or w0. The supported
> + identifiers are passed from consumers, or listed in the the arm,func-ids
> + properties as described below. The firmware can return one value in
> + the first SMC result register, it is expected to be an error value,
> + which shall be propagated to the mailbox client.
> +
> + Any core which supports the SMC or HVC instruction can be used, as long as
> + a firmware component running in EL3 or EL2 is handling these calls.
> +
> +properties:
> + compatible:
> + const: arm,smc-mbox
> +
> + "#mbox-cells":
> + const: 1
> +
> + arm,num-chans:
> + description: The number of channels supported.
> + items:
> + minimum: 1
> + maximum: 4096 # Should be enough?
> +
> + method:
> + items:
You can drop 'items' as this is a single entry.
> + - enum:
> + - smc
> + - hvc
> +
> + transports:
> + items:
same here
> + - enum:
> + - mem
> + - reg
> +
> + arm,func-ids:
Needs a $ref to a type (uint32-array).
> + description: |
> + An array of 32-bit values specifying the function IDs used by each
> + mailbox channel. Those function IDs follow the ARM SMC calling
> + convention standard [1].
> +
> + There is one identifier per channel and the number of supported
> + channels is determined by the length of this array.
> + minItems: 0
> + maxItems: 4096 # Should be enough?
> +
> +required:
> + - compatible
> + - "#mbox-cells"
> + - arm,num-chans
> + - transports
> + - method
> +
> +examples:
> + - |
> + sram@910000 {
> + compatible = "mmio-sram";
> + reg = <0x0 0x93f000 0x0 0x1000>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges = <0 0x0 0x93f000 0x1000>;
> +
> + cpu_scp_lpri: scp-shmem@0 {
Looks like some indentation problem...
> + compatible = "arm,scmi-shmem";
> + reg = <0x0 0x200>;
> + };
> +
> + cpu_scp_hpri: scp-shmem@200 {
> + compatible = "arm,scmi-shmem";
> + reg = <0x200 0x200>;
> + };
> + };
> +
> + firmware {
> + smc_mbox: mailbox {
> + #mbox-cells = <1>;
> + compatible = "arm,smc-mbox";
> + method = "smc";
> + arm,num-chans = <0x2>;
> + transports = "mem";
> + /* Optional */
> + arm,func-ids = <0xc20000fe>, <0xc20000ff>;
> + };
> +
> + scmi {
> + compatible = "arm,scmi";
> + mboxes = <&mailbox 0 &mailbox 1>;
&smc_mbox and <> each entry.
> + mbox-names = "tx", "rx";
> + shmem = <&cpu_scp_lpri &cpu_scp_hpri>;
<> each entry
> + };
> + };
> +
> +...
> --
> 2.16.4
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox