* [PATCH 2/2] ARM: probes: avoid adding kprobes to sensitive kernel-entry/exit code
From: Sam Protsenko @ 2017-12-21 19:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <E1eIYic-0007t7-Df@rmk-PC.armlinux.org.uk>
On 25 November 2017 at 13:33, Russell King <rmk+kernel@armlinux.org.uk> wrote:
> Avoid adding kprobes to any of the kernel entry/exit or startup
> assembly code, or code in the identity-mapped region. This code does
> not conform to the standard C conventions, which means that the
> expectations of the kprobes code is not forfilled.
>
> Placing kprobes at some of these locations results in the kernel trying
> to return to userspace addresses while retaining the CPU in kernel mode.
>
> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
> ---
> arch/arm/include/asm/exception.h | 3 +--
> arch/arm/include/asm/sections.h | 21 +++++++++++++++++++++
> arch/arm/include/asm/traps.h | 12 ------------
> arch/arm/kernel/entry-armv.S | 6 +-----
> arch/arm/kernel/entry-common.S | 1 +
> arch/arm/kernel/stacktrace.c | 14 ++------------
> arch/arm/kernel/traps.c | 4 ++--
> arch/arm/kernel/vmlinux.lds.S | 6 +++---
> arch/arm/mm/fault.c | 5 ++---
> arch/arm/probes/kprobes/core.c | 14 +++++++++++---
> 10 files changed, 44 insertions(+), 42 deletions(-)
>
> diff --git a/arch/arm/include/asm/exception.h b/arch/arm/include/asm/exception.h
> index a7273ad9587a..58e039a851af 100644
> --- a/arch/arm/include/asm/exception.h
> +++ b/arch/arm/include/asm/exception.h
> @@ -10,11 +10,10 @@
>
> #include <linux/interrupt.h>
>
> -#define __exception __attribute__((section(".exception.text")))
> #ifdef CONFIG_FUNCTION_GRAPH_TRACER
> #define __exception_irq_entry __irq_entry
> #else
> -#define __exception_irq_entry __exception
> +#define __exception_irq_entry
> #endif
>
> #endif /* __ASM_ARM_EXCEPTION_H */
> diff --git a/arch/arm/include/asm/sections.h b/arch/arm/include/asm/sections.h
> index 63dfe1f10335..4ceb4f757d4d 100644
> --- a/arch/arm/include/asm/sections.h
> +++ b/arch/arm/include/asm/sections.h
> @@ -6,4 +6,25 @@
>
> extern char _exiprom[];
>
> +extern char __idmap_text_start[];
> +extern char __idmap_text_end[];
> +extern char __entry_text_start[];
> +extern char __entry_text_end[];
> +extern char __hyp_idmap_text_start[];
> +extern char __hyp_idmap_text_end[];
> +
> +static inline bool in_entry_text(unsigned long addr)
> +{
> + return memory_contains(__entry_text_start, __entry_text_end,
> + (void *)addr, 1);
> +}
> +
> +static inline bool in_idmap_text(unsigned long addr)
> +{
> + void *a = (void *)addr;
> + return memory_contains(__idmap_text_start, __idmap_text_end, a, 1) ||
> + memory_contains(__hyp_idmap_text_start, __hyp_idmap_text_end,
> + a, 1);
> +}
> +
> #endif /* _ASM_ARM_SECTIONS_H */
> diff --git a/arch/arm/include/asm/traps.h b/arch/arm/include/asm/traps.h
> index f9a6c5fc3fd1..a00288d75ee6 100644
> --- a/arch/arm/include/asm/traps.h
> +++ b/arch/arm/include/asm/traps.h
> @@ -28,18 +28,6 @@ static inline int __in_irqentry_text(unsigned long ptr)
> ptr < (unsigned long)&__irqentry_text_end;
> }
>
> -static inline int in_exception_text(unsigned long ptr)
> -{
> - extern char __exception_text_start[];
> - extern char __exception_text_end[];
> - int in;
> -
> - in = ptr >= (unsigned long)&__exception_text_start &&
> - ptr < (unsigned long)&__exception_text_end;
> -
> - return in ? : __in_irqentry_text(ptr);
> -}
> -
> extern void __init early_trap_init(void *);
> extern void dump_backtrace_entry(unsigned long where, unsigned long from, unsigned long frame);
> extern void ptrace_break(struct task_struct *tsk, struct pt_regs *regs);
> diff --git a/arch/arm/kernel/entry-armv.S b/arch/arm/kernel/entry-armv.S
> index 10ad44f3886a..b8ab97dfdd17 100644
> --- a/arch/arm/kernel/entry-armv.S
> +++ b/arch/arm/kernel/entry-armv.S
> @@ -82,11 +82,7 @@
> #endif
> .endm
>
> -#ifdef CONFIG_KPROBES
> - .section .kprobes.text,"ax",%progbits
> -#else
> - .text
> -#endif
> + .section .entry.text,"ax",%progbits
>
> /*
> * Invalid mode handlers
> diff --git a/arch/arm/kernel/entry-common.S b/arch/arm/kernel/entry-common.S
> index e655dcd0a933..3c4f88701f22 100644
> --- a/arch/arm/kernel/entry-common.S
> +++ b/arch/arm/kernel/entry-common.S
> @@ -37,6 +37,7 @@ saved_pc .req lr
> #define TRACE(x...)
> #endif
>
> + .section .entry.text,"ax",%progbits
> .align 5
> #if !(IS_ENABLED(CONFIG_TRACE_IRQFLAGS) || IS_ENABLED(CONFIG_CONTEXT_TRACKING))
> /*
> diff --git a/arch/arm/kernel/stacktrace.c b/arch/arm/kernel/stacktrace.c
> index 65228bf4c6df..a56e7c856ab5 100644
> --- a/arch/arm/kernel/stacktrace.c
> +++ b/arch/arm/kernel/stacktrace.c
> @@ -3,6 +3,7 @@
> #include <linux/sched/debug.h>
> #include <linux/stacktrace.h>
>
> +#include <asm/sections.h>
> #include <asm/stacktrace.h>
> #include <asm/traps.h>
>
> @@ -63,7 +64,6 @@ EXPORT_SYMBOL(walk_stackframe);
> #ifdef CONFIG_STACKTRACE
> struct stack_trace_data {
> struct stack_trace *trace;
> - unsigned long last_pc;
> unsigned int no_sched_functions;
> unsigned int skip;
> };
> @@ -87,16 +87,7 @@ static int save_trace(struct stackframe *frame, void *d)
> if (trace->nr_entries >= trace->max_entries)
> return 1;
>
> - /*
> - * in_exception_text() is designed to test if the PC is one of
> - * the functions which has an exception stack above it, but
> - * unfortunately what is in frame->pc is the return LR value,
> - * not the saved PC value. So, we need to track the previous
> - * frame PC value when doing this.
> - */
> - addr = data->last_pc;
> - data->last_pc = frame->pc;
> - if (!in_exception_text(addr))
> + if (!in_entry_text(frame->pc))
> return 0;
>
> regs = (struct pt_regs *)frame->sp;
> @@ -114,7 +105,6 @@ static noinline void __save_stack_trace(struct task_struct *tsk,
> struct stackframe frame;
>
> data.trace = trace;
> - data.last_pc = ULONG_MAX;
> data.skip = trace->skip;
> data.no_sched_functions = nosched;
>
> diff --git a/arch/arm/kernel/traps.c b/arch/arm/kernel/traps.c
> index 5de2bc46153f..95978073db53 100644
> --- a/arch/arm/kernel/traps.c
> +++ b/arch/arm/kernel/traps.c
> @@ -73,7 +73,7 @@ void dump_backtrace_entry(unsigned long where, unsigned long from, unsigned long
> printk("Function entered at [<%08lx>] from [<%08lx>]\n", where, from);
> #endif
>
> - if (in_exception_text(where))
> + if (in_entry_text(from))
> dump_mem("", "Exception stack", frame + 4, frame + 4 + sizeof(struct pt_regs));
> }
>
> @@ -434,7 +434,7 @@ static int call_undef_hook(struct pt_regs *regs, unsigned int instr)
> return fn ? fn(regs, instr) : 1;
> }
>
> -asmlinkage void __exception do_undefinstr(struct pt_regs *regs)
> +asmlinkage void do_undefinstr(struct pt_regs *regs)
> {
> unsigned int instr;
> siginfo_t info;
> diff --git a/arch/arm/kernel/vmlinux.lds.S b/arch/arm/kernel/vmlinux.lds.S
> index ee53f6518872..84a1ae3ce46e 100644
> --- a/arch/arm/kernel/vmlinux.lds.S
> +++ b/arch/arm/kernel/vmlinux.lds.S
> @@ -105,9 +105,9 @@ SECTIONS
> .text : { /* Real text segment */
> _stext = .; /* Text and read-only data */
> IDMAP_TEXT
> - __exception_text_start = .;
> - *(.exception.text)
> - __exception_text_end = .;
> + __entry_text_start = .;
> + *(.entry.text)
> + __entry_text_end = .;
> IRQENTRY_TEXT
> SOFTIRQENTRY_TEXT
> TEXT_TEXT
> diff --git a/arch/arm/mm/fault.c b/arch/arm/mm/fault.c
> index 42f585379e19..b75eada23d0a 100644
> --- a/arch/arm/mm/fault.c
> +++ b/arch/arm/mm/fault.c
> @@ -21,7 +21,6 @@
> #include <linux/highmem.h>
> #include <linux/perf_event.h>
>
> -#include <asm/exception.h>
> #include <asm/pgtable.h>
> #include <asm/system_misc.h>
> #include <asm/system_info.h>
> @@ -545,7 +544,7 @@ hook_fault_code(int nr, int (*fn)(unsigned long, unsigned int, struct pt_regs *)
> /*
> * Dispatch a data abort to the relevant handler.
> */
> -asmlinkage void __exception
> +asmlinkage void
> do_DataAbort(unsigned long addr, unsigned int fsr, struct pt_regs *regs)
> {
> const struct fsr_info *inf = fsr_info + fsr_fs(fsr);
> @@ -578,7 +577,7 @@ hook_ifault_code(int nr, int (*fn)(unsigned long, unsigned int, struct pt_regs *
> ifsr_info[nr].name = name;
> }
>
> -asmlinkage void __exception
> +asmlinkage void
> do_PrefetchAbort(unsigned long addr, unsigned int ifsr, struct pt_regs *regs)
> {
> const struct fsr_info *inf = ifsr_info + fsr_fs(ifsr);
> diff --git a/arch/arm/probes/kprobes/core.c b/arch/arm/probes/kprobes/core.c
> index 52d1cd14fda4..e90cc8a08186 100644
> --- a/arch/arm/probes/kprobes/core.c
> +++ b/arch/arm/probes/kprobes/core.c
> @@ -32,6 +32,7 @@
> #include <linux/percpu.h>
> #include <linux/bug.h>
> #include <asm/patch.h>
> +#include <asm/sections.h>
>
> #include "../decode-arm.h"
> #include "../decode-thumb.h"
> @@ -64,9 +65,6 @@ int __kprobes arch_prepare_kprobe(struct kprobe *p)
> int is;
> const struct decode_checker **checkers;
>
> - if (in_exception_text(addr))
> - return -EINVAL;
> -
> #ifdef CONFIG_THUMB2_KERNEL
> thumb = true;
> addr &= ~1; /* Bit 0 would normally be set to indicate Thumb code */
> @@ -680,3 +678,13 @@ int __init arch_init_kprobes()
> #endif
> return 0;
> }
> +
> +bool arch_within_kprobe_blacklist(unsigned long addr)
> +{
> + void *a = (void *)addr;
> +
> + return __in_irqentry_text(addr) ||
> + in_entry_text(addr) ||
> + in_idmap_text(addr) ||
> + memory_contains(__kprobes_text_start, __kprobes_text_end, a, 1);
> +}
> --
> 2.7.4
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Hi Russel,
Can you please tell us what is the status of this patch? It fixes the
issue for us ([1]), but we are waiting for it to be merged.
Tested-by: Sam Protsenko <semen.protsenko@linaro.org>
Thanks!
[1] https://bugs.linaro.org/show_bug.cgi?id=3297
^ permalink raw reply
* [RFC PATCH 2/5] perf jevents: add support for arch recommended events
From: Jiri Olsa @ 2017-12-21 19:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5d322353-2785-a99f-bcd8-b948bd6cb09a@huawei.com>
On Fri, Dec 15, 2017 at 11:22:50AM +0000, John Garry wrote:
> > > Actually having a scalable JSON standard format for pmu events, which allows
> > > us to define common events per architecture / vendor and reference them per
> > > platform JSON could be useful.
> > >
> > > Here we're dealing with trade-off between duplication (simplicity) vs
> > > complexity (or over-engineering).
> >
> > understood, but as I said we already are ok with duplicates,
> > if it's reasonable size as is for x86 now.. how much amount
> > are we talking about for arm?
> >
>
> Hi Jirka,
>
> When you say reasonable size for x86, I ran a string duplication finder on
> the x86 JSONs and the results show a huge amount of duplication. Please
> check this:
> https://gist.githubusercontent.com/johnpgarry/68bc87e823ae2ce0f7b475b4e55e5795/raw/f4cea138999d8b34151b9586d733592e01774d7a/x86%2520JSON%2520duplication
>
> Extract:
> "Found a 65 line (311 tokens) duplication in the following files:
> Starting at line 100 of
> /linux/tools/perf/pmu-events/arch/x86/ivybridge/ivb-metrics.json
> Starting at line 100 of
> /linux/tools/perf/pmu-events/arch/x86/ivytown/ivt-metrics.json
> Starting at line 100 of
> /linux/tools/perf/pmu-events/arch/x86/broadwell/bdw-metrics.json
> Starting at line 100 of
> /linux/tools/perf/pmu-events/arch/x86/skylakex/skx-metrics.json
> Starting at line 76 of
> /linux/tools/perf/pmu-events/arch/x86/jaketown/jkt-metrics.json
> Starting at line 100 of
> /linux/tools/perf/pmu-events/arch/x86/skylake/skl-metrics.json
> Starting at line 76 of
> /linux/tools/perf/pmu-events/arch/x86/sandybridge/snb-metrics.json
> Starting at line 100 of
> /linux/tools/perf/pmu-events/arch/x86/broadwellx/bdx-metrics.json"
>
> Won't this all potentially have a big maintainence cost?
as Andi said it's mostly just the disk space,
which is not big deal
I'm not doing JSON file updates, but I think having
simple single dir for platform/cpu could save us some
confusion in future
however I won't oppose if you want to add this logic,
but please:
- use the list_head ;-)
- leave the process_one_file function simple
and separate the level0 processing
- you are using 'EventCode' as an unique ID to find
the base, but it's not unique for x86, you'll need
to add some other ID scheme that fits to all archs
thanks,
jirka
>
> For example, I saw multiple JSON update patches which look identical:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/tools/perf/pmu-events/arch/x86?h=v4.15-rc3&id=7347bba5552f479d4292ffd008d18d41a965f021
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/tools/perf/pmu-events/arch/x86?h=v4.15-rc3&id=984d91f4c62f64026cbfef51f609971025934cec
>
> I just don't know how this schema scales with more archs and more platforms
> supported. It's just early days now...
>
> Regards,
> John
>
> > jirka
> >
> > .
> >
>
>
^ permalink raw reply
* [GIT PULL 2/3] arm64: dts: exynos: DTS for v4.16
From: Krzysztof Kozlowski @ 2017-12-21 19:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAK8P3a2obLRFK8cZ3B1M1qCzDQq=-7ux4_Tu4kG+ksW6NCieYg@mail.gmail.com>
On Thu, Dec 21, 2017 at 5:50 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Wed, Dec 20, 2017 at 6:36 PM, Krzysztof Kozlowski <krzk@kernel.org> wrote:
>> Samsung DTS ARM64 changes for v4.16
>>
>> 1. Add CPU perf counters to Exynos5433.
>> 2. Add missing power domains to Exynos5433.
>> 3. Add NFC chip to Exynos5433 TM2/TM2E.
>> 4. Fix obscure bugs on I2C transfers to MHL chip on TM2/TM2E.
>
> Pulled into next/dt, thanks!
>
> One question: do you know if anyone is working on support for the newer
> Exynos chips, or the Nexell S5P6818 series? It seems odd that none of
> the chips from the past three years are supported yet.
For the new Exynos chips - I think Samsung folks are working on them.
Indeed it looks like the pace for new chips has slowed down.
The Nexell series are similar to Exynos but this is different company
so probably they would end up in different sub-arch. Only some IP
blocks are similar to Exynos even though the datasheet has Samsung
marks. I saw patches for U-Boot (I do not remember the author) so
maybe soon something will happen on LKML.
Best regards,
Krzysztof
^ permalink raw reply
* [net-next: PATCH 0/8] Armada 7k/8k PP2 ACPI support
From: Antoine Tenart @ 2017-12-21 19:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513588684-15647-1-git-send-email-mw@semihalf.com>
Hi Marcin,
On Mon, Dec 18, 2017 at 10:17:56AM +0100, Marcin Wojtas wrote:
>
> Marcin Wojtas (8):
> device property: Introduce fwnode_get_mac_address()
> device property: Introduce fwnode_get_phy_mode()
> mdio_bus: Introduce fwnode MDIO helpers
> net: mvmdio: add ACPI support
> net: mvpp2: simplify maintaining enabled ports' list
> net: mvpp2: use device_*/fwnode_* APIs instead of of_*
> net: mvpp2: handle PHY with its fwnode
> net: mvpp2: enable ACPI support in the driver
I tested your series on a mcbin, using the dt way. It still worked. If
it is relevant, you can add on the mvpp2 related patches:
Tested-by: Antoine Tenart <antoine.tenart@free-electrons.com>
Thanks!
Antoine
--
Antoine T?nart, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH v2] IPI performance benchmark
From: Yury Norov @ 2017-12-21 19:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CANRm+Cx6Lm8r2Oej+-EX=Dz76bvu81rVKD-RU0=LRSNs3dw7mw@mail.gmail.com>
On Wed, Dec 20, 2017 at 02:44:25PM +0800, Wanpeng Li wrote:
> Hi Yury,
> 2017-12-19 16:50 GMT+08:00 Yury Norov <ynorov@caviumnetworks.com>:
> > This benchmark sends many IPIs in different modes and measures
> > time for IPI delivery (first column), and total time, ie including
> > time to acknowledge the receive by sender (second column).
> >
> > The scenarios are:
> > Dry-run: do everything except actually sending IPI. Useful
> > to estimate system overhead.
> > Self-IPI: Send IPI to self CPU.
> > Normal IPI: Send IPI to some other CPU.
> > Broadcast IPI: Send broadcast IPI to all online CPUs.
> > Broadcast lock: Send broadcast IPI to all online CPUs and force them
> > acquire/release spinlock.
> >
> > The raw output looks like this:
> > [ 155.363374] Dry-run: 0, 2999696 ns
> > [ 155.429162] Self-IPI: 30385328, 65589392 ns
> > [ 156.060821] Normal IPI: 566914128, 631453008 ns
> > [ 158.384427] Broadcast IPI: 0, 2323368720 ns
> > [ 160.831850] Broadcast lock: 0, 2447000544 ns
> >
> > For virtualized guests, sending and reveiving IPIs causes guest exit.
> > I used this test to measure performance impact on KVM subsystem of
> > Christoffer Dall's series "Optimize KVM/ARM for VHE systems" [1].
> >
> > Test machine is ThunderX2, 112 online CPUs. Below the results normalized
> > to host dry-run time, broadcast lock results omitted. Smaller - better.
>
> Could you test on a x86 box? I see a lot of calltraces on my haswell
> client host, there is no calltrace in the guest, however, I can still
> observe "Invalid parameters" warning when insmod this module. In
> addition, the x86 box fails to boot when ipi_benchmark is buildin.
I tried to boot kernel with builtin test both on real hardware and
qemu+kvm - no calltraces or other problems. Kernel is 4.14, config for
host is attached.
CPU is Intel(R) Core(TM) i7-7600U CPU @ 2.80GHz
Kernel is 4.14, config for host is attached, but it's default Ubuntu
config. Results and qemu command are below. Could you share more details
about your configuration?
Yury
qemu-system-x86_64 -hda debian_squeeze_amd64_standard.qcow2 \
-smp 1 -curses --nographic --enable-kvm
Host, 4 cores:
[ 0.237279] Dry-run: 0, 170292 ns
[ 0.643269] Self-IPI: 458516336, 922256372 ns
[ 0.902545] Self-IPI: 508518362, 972130665 ns
[ 0.646500] Broadcast IPI: 0, 97301545 ns
[ 0.649712] Broadcast lock: 0, 102364755 ns
KVM, single core:
[ 0.237279] Dry-run: 0, 124500 ns
[ 0.643269] Self-IPI: 202518310, 405444790 ns
[ 0.643694] Normal IPI FAILED: -2
[ 0.646500] Broadcast IPI: 0, 2524370 ns
[ 0.649712] Broadcast lock: 0, 2642270 ns
KVM, 4 cores:
[ 0.492676] Dry-run: 0, 126380 ns
[ 0.902545] Self-IPI: 204085450, 409863800 ns
[ 2.179676] Normal IPI: 1058014940, 1276742820 ns
[ 3.396132] Broadcast IPI: 0, 1215934730 ns
[ 4.610719] Broadcast lock: 0, 1213945500 ns
-------------- next part --------------
A non-text attachment was scrubbed...
Name: config.gz
Type: application/gzip
Size: 38449 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20171221/0d9308cd/attachment-0001.gz>
^ permalink raw reply
* [PATCH] clk: divider: fix incorrect usage of container_of
From: Stephen Boyd @ 2017-12-21 18:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171221163054.13600-1-jbrunet@baylibre.com>
On 12/21, Jerome Brunet wrote:
> divider_recalc_rate() is an helper function used by clock divider of
> different types, so the structure containing the 'hw' pointer is not
> always a 'struct clk_divider'
>
> At the following line:
> > div = _get_div(table, val, flags, divider->width);
>
> in several cases, the value of 'divider->width' is garbage as the actual
> structure behind this memory is not a 'struct clk_divider'
>
> Fortunately, this width value is used by _get_val() only when
> CLK_DIVIDER_MAX_AT_ZERO flag is set. This has never been the case so
> far when the structure is not a 'struct clk_divider'. This is probably
> why we did not notice this bug before
>
> Fixes: afe76c8fd030 ("clk: allow a clk divider with max divisor when zero")
> Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
> ---
> Hi Stephen, Mike,
>
> In addition to clock, this patch also touch the rtc and drm directories.
> As it is changing the API of the helper function, I have this fix in a
> single commit to avoid breaking bisect.
>
> Please let me know if you prefer to do differently.
>
Looks good. Thanks for catching this before it became a real
problem. It would be good to get acks from DRM and RTC
maintainers.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH v6 2/2] soc: xilinx: xlnx_vcu: Add Xilinx ZYNQMP VCU logicoreIP init driver
From: Dhaval Shah @ 2017-12-21 18:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513881186-26020-1-git-send-email-dshah@xilinx.com>
Xilinx ZYNQMP logicoreIP Init driver is based on the new
LogiCoreIP design created. This driver provides the processing system
and programmable logic isolation. Set the frequency based on the clock
information get from the logicoreIP register set.
Signed-off-by: Dhaval Shah <dshah@xilinx.com>
---
Changes since v6:
* Path of the driver is updated to "drivers/soc/xilinx/" from "drivers/misc"
* Patch is rebase on top of the https://patchwork.kernel.org/patch/10123235/
Changes since v5:
* Changes made to include index 0 of the array.
Changes since v4:
* Indent the help text (below) by 2 additional spaces, as documented in coding-style.rst
* Spell check are resolved as per the review comment.
* inline the read() and write() functions..
* multi-line comment style
* Updated subject line prefix
Changes since v3:
No Changes.
Changes since v2:
* Removed the "default n" from the Kconfig
* More help text added to explain more about the logicoreIP driver
* SPDX id is relocated at top of the file with // style comment
* Removed the export API and header file and make it a single driver
which provides logocoreIP init.
* Provide the information in commit message as well for the why driver
in drivers/misc.
drivers/soc/xilinx/Kconfig | 15 +
drivers/soc/xilinx/Makefile | 1 +
drivers/soc/xilinx/xlnx_vcu.c | 630 ++++++++++++++++++++++++++++++++++++++++++
3 files changed, 646 insertions(+)
create mode 100644 drivers/soc/xilinx/xlnx_vcu.c
diff --git a/drivers/soc/xilinx/Kconfig b/drivers/soc/xilinx/Kconfig
index ffaaa2f..266b50f 100644
--- a/drivers/soc/xilinx/Kconfig
+++ b/drivers/soc/xilinx/Kconfig
@@ -1,4 +1,19 @@
# SPDX-License-Identifier: GPL-2.0
menu "Xilinx SoC drivers"
+config XILINX_VCU
+ tristate "Xilinx VCU logicoreIP Init"
+ help
+ Provides the driver to enable and disable the isolation between the
+ processing system and programmable logic part by using the logicoreIP
+ register set. This driver also configures the frequency based on the
+ clock information from the logicoreIP register set.
+
+ If you say yes here you get support for the logicoreIP.
+
+ If unsure, say N.
+
+ To compile this driver as a module, choose M here: the
+ module will be called xlnx_vcu.
+
endmenu
diff --git a/drivers/soc/xilinx/Makefile b/drivers/soc/xilinx/Makefile
index f66554c..dee8fd5 100644
--- a/drivers/soc/xilinx/Makefile
+++ b/drivers/soc/xilinx/Makefile
@@ -1 +1,2 @@
# SPDX-License-Identifier: GPL-2.0
+obj-$(CONFIG_XILINX_VCU) += xlnx_vcu.o
diff --git a/drivers/soc/xilinx/xlnx_vcu.c b/drivers/soc/xilinx/xlnx_vcu.c
new file mode 100644
index 0000000..46ec3fd
--- /dev/null
+++ b/drivers/soc/xilinx/xlnx_vcu.c
@@ -0,0 +1,630 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Xilinx VCU Init
+ *
+ * Copyright (C) 2016 - 2017 Xilinx, Inc.
+ *
+ * Contacts Dhaval Shah <dshah@xilinx.com>
+ */
+#include <linux/clk.h>
+#include <linux/device.h>
+#include <linux/errno.h>
+#include <linux/io.h>
+#include <linux/module.h>
+#include <linux/of_platform.h>
+#include <linux/platform_device.h>
+
+/* Address map for different registers implemented in the VCU LogiCORE IP. */
+#define VCU_ECODER_ENABLE 0x00
+#define VCU_DECODER_ENABLE 0x04
+#define VCU_MEMORY_DEPTH 0x08
+#define VCU_ENC_COLOR_DEPTH 0x0c
+#define VCU_ENC_VERTICAL_RANGE 0x10
+#define VCU_ENC_FRAME_SIZE_X 0x14
+#define VCU_ENC_FRAME_SIZE_Y 0x18
+#define VCU_ENC_COLOR_FORMAT 0x1c
+#define VCU_ENC_FPS 0x20
+#define VCU_MCU_CLK 0x24
+#define VCU_CORE_CLK 0x28
+#define VCU_PLL_BYPASS 0x2c
+#define VCU_ENC_CLK 0x30
+#define VCU_PLL_CLK 0x34
+#define VCU_ENC_VIDEO_STANDARD 0x38
+#define VCU_STATUS 0x3c
+#define VCU_AXI_ENC_CLK 0x40
+#define VCU_AXI_DEC_CLK 0x44
+#define VCU_AXI_MCU_CLK 0x48
+#define VCU_DEC_VIDEO_STANDARD 0x4c
+#define VCU_DEC_FRAME_SIZE_X 0x50
+#define VCU_DEC_FRAME_SIZE_Y 0x54
+#define VCU_DEC_FPS 0x58
+#define VCU_BUFFER_B_FRAME 0x5c
+#define VCU_WPP_EN 0x60
+#define VCU_PLL_CLK_DEC 0x64
+#define VCU_GASKET_INIT 0x74
+#define VCU_GASKET_VALUE 0x03
+
+/* vcu slcr registers, bitmask and shift */
+#define VCU_PLL_CTRL 0x24
+#define VCU_PLL_CTRL_RESET_MASK 0x01
+#define VCU_PLL_CTRL_RESET_SHIFT 0
+#define VCU_PLL_CTRL_BYPASS_MASK 0x01
+#define VCU_PLL_CTRL_BYPASS_SHIFT 3
+#define VCU_PLL_CTRL_FBDIV_MASK 0x7f
+#define VCU_PLL_CTRL_FBDIV_SHIFT 8
+#define VCU_PLL_CTRL_POR_IN_MASK 0x01
+#define VCU_PLL_CTRL_POR_IN_SHIFT 1
+#define VCU_PLL_CTRL_PWR_POR_MASK 0x01
+#define VCU_PLL_CTRL_PWR_POR_SHIFT 2
+#define VCU_PLL_CTRL_CLKOUTDIV_MASK 0x03
+#define VCU_PLL_CTRL_CLKOUTDIV_SHIFT 16
+#define VCU_PLL_CTRL_DEFAULT 0
+#define VCU_PLL_DIV2 2
+
+#define VCU_PLL_CFG 0x28
+#define VCU_PLL_CFG_RES_MASK 0x0f
+#define VCU_PLL_CFG_RES_SHIFT 0
+#define VCU_PLL_CFG_CP_MASK 0x0f
+#define VCU_PLL_CFG_CP_SHIFT 5
+#define VCU_PLL_CFG_LFHF_MASK 0x03
+#define VCU_PLL_CFG_LFHF_SHIFT 10
+#define VCU_PLL_CFG_LOCK_CNT_MASK 0x03ff
+#define VCU_PLL_CFG_LOCK_CNT_SHIFT 13
+#define VCU_PLL_CFG_LOCK_DLY_MASK 0x7f
+#define VCU_PLL_CFG_LOCK_DLY_SHIFT 25
+#define VCU_ENC_CORE_CTRL 0x30
+#define VCU_ENC_MCU_CTRL 0x34
+#define VCU_DEC_CORE_CTRL 0x38
+#define VCU_DEC_MCU_CTRL 0x3c
+#define VCU_PLL_DIVISOR_MASK 0x3f
+#define VCU_PLL_DIVISOR_SHIFT 4
+#define VCU_SRCSEL_MASK 0x01
+#define VCU_SRCSEL_SHIFT 0
+#define VCU_SRCSEL_PLL 1
+
+#define VCU_PLL_STATUS 0x60
+#define VCU_PLL_STATUS_LOCK_STATUS_MASK 0x01
+
+#define MHZ 1000000
+#define FVCO_MIN (1500U * MHZ)
+#define FVCO_MAX (3000U * MHZ)
+#define DIVISOR_MIN 0
+#define DIVISOR_MAX 63
+#define FRAC 100
+#define LIMIT (10 * MHZ)
+
+/**
+ * struct xvcu_device - Xilinx VCU init device structure
+ * @dev: Platform device
+ * @pll_ref: pll ref clock source
+ * @aclk: axi clock source
+ * @logicore_reg_ba: logicore reg base address
+ * @vcu_slcr_ba: vcu_slcr Register base address
+ * @coreclk: core clock frequency
+ */
+struct xvcu_device {
+ struct device *dev;
+ struct clk *pll_ref;
+ struct clk *aclk;
+ void __iomem *logicore_reg_ba;
+ void __iomem *vcu_slcr_ba;
+ u32 coreclk;
+};
+
+/**
+ * struct xvcu_pll_cfg - Helper data
+ * @fbdiv: The integer portion of the feedback divider to the PLL
+ * @cp: PLL charge pump control
+ * @res: PLL loop filter resistor control
+ * @lfhf: PLL loop filter high frequency capacitor control
+ * @lock_dly: Lock circuit configuration settings for lock windowsize
+ * @lock_cnt: Lock circuit counter setting
+ */
+struct xvcu_pll_cfg {
+ u32 fbdiv;
+ u32 cp;
+ u32 res;
+ u32 lfhf;
+ u32 lock_dly;
+ u32 lock_cnt;
+};
+
+static const struct xvcu_pll_cfg xvcu_pll_cfg[] = {
+ { 25, 3, 10, 3, 63, 1000 },
+ { 26, 3, 10, 3, 63, 1000 },
+ { 27, 4, 6, 3, 63, 1000 },
+ { 28, 4, 6, 3, 63, 1000 },
+ { 29, 4, 6, 3, 63, 1000 },
+ { 30, 4, 6, 3, 63, 1000 },
+ { 31, 6, 1, 3, 63, 1000 },
+ { 32, 6, 1, 3, 63, 1000 },
+ { 33, 4, 10, 3, 63, 1000 },
+ { 34, 5, 6, 3, 63, 1000 },
+ { 35, 5, 6, 3, 63, 1000 },
+ { 36, 5, 6, 3, 63, 1000 },
+ { 37, 5, 6, 3, 63, 1000 },
+ { 38, 5, 6, 3, 63, 975 },
+ { 39, 3, 12, 3, 63, 950 },
+ { 40, 3, 12, 3, 63, 925 },
+ { 41, 3, 12, 3, 63, 900 },
+ { 42, 3, 12, 3, 63, 875 },
+ { 43, 3, 12, 3, 63, 850 },
+ { 44, 3, 12, 3, 63, 850 },
+ { 45, 3, 12, 3, 63, 825 },
+ { 46, 3, 12, 3, 63, 800 },
+ { 47, 3, 12, 3, 63, 775 },
+ { 48, 3, 12, 3, 63, 775 },
+ { 49, 3, 12, 3, 63, 750 },
+ { 50, 3, 12, 3, 63, 750 },
+ { 51, 3, 2, 3, 63, 725 },
+ { 52, 3, 2, 3, 63, 700 },
+ { 53, 3, 2, 3, 63, 700 },
+ { 54, 3, 2, 3, 63, 675 },
+ { 55, 3, 2, 3, 63, 675 },
+ { 56, 3, 2, 3, 63, 650 },
+ { 57, 3, 2, 3, 63, 650 },
+ { 58, 3, 2, 3, 63, 625 },
+ { 59, 3, 2, 3, 63, 625 },
+ { 60, 3, 2, 3, 63, 625 },
+ { 61, 3, 2, 3, 63, 600 },
+ { 62, 3, 2, 3, 63, 600 },
+ { 63, 3, 2, 3, 63, 600 },
+ { 64, 3, 2, 3, 63, 600 },
+ { 65, 3, 2, 3, 63, 600 },
+ { 66, 3, 2, 3, 63, 600 },
+ { 67, 3, 2, 3, 63, 600 },
+ { 68, 3, 2, 3, 63, 600 },
+ { 69, 3, 2, 3, 63, 600 },
+ { 70, 3, 2, 3, 63, 600 },
+ { 71, 3, 2, 3, 63, 600 },
+ { 72, 3, 2, 3, 63, 600 },
+ { 73, 3, 2, 3, 63, 600 },
+ { 74, 3, 2, 3, 63, 600 },
+ { 75, 3, 2, 3, 63, 600 },
+ { 76, 3, 2, 3, 63, 600 },
+ { 77, 3, 2, 3, 63, 600 },
+ { 78, 3, 2, 3, 63, 600 },
+ { 79, 3, 2, 3, 63, 600 },
+ { 80, 3, 2, 3, 63, 600 },
+ { 81, 3, 2, 3, 63, 600 },
+ { 82, 3, 2, 3, 63, 600 },
+ { 83, 4, 2, 3, 63, 600 },
+ { 84, 4, 2, 3, 63, 600 },
+ { 85, 4, 2, 3, 63, 600 },
+ { 86, 4, 2, 3, 63, 600 },
+ { 87, 4, 2, 3, 63, 600 },
+ { 88, 4, 2, 3, 63, 600 },
+ { 89, 4, 2, 3, 63, 600 },
+ { 90, 4, 2, 3, 63, 600 },
+ { 91, 4, 2, 3, 63, 600 },
+ { 92, 4, 2, 3, 63, 600 },
+ { 93, 4, 2, 3, 63, 600 },
+ { 94, 4, 2, 3, 63, 600 },
+ { 95, 4, 2, 3, 63, 600 },
+ { 96, 4, 2, 3, 63, 600 },
+ { 97, 4, 2, 3, 63, 600 },
+ { 98, 4, 2, 3, 63, 600 },
+ { 99, 4, 2, 3, 63, 600 },
+ { 100, 4, 2, 3, 63, 600 },
+ { 101, 4, 2, 3, 63, 600 },
+ { 102, 4, 2, 3, 63, 600 },
+ { 103, 5, 2, 3, 63, 600 },
+ { 104, 5, 2, 3, 63, 600 },
+ { 105, 5, 2, 3, 63, 600 },
+ { 106, 5, 2, 3, 63, 600 },
+ { 107, 3, 4, 3, 63, 600 },
+ { 108, 3, 4, 3, 63, 600 },
+ { 109, 3, 4, 3, 63, 600 },
+ { 110, 3, 4, 3, 63, 600 },
+ { 111, 3, 4, 3, 63, 600 },
+ { 112, 3, 4, 3, 63, 600 },
+ { 113, 3, 4, 3, 63, 600 },
+ { 114, 3, 4, 3, 63, 600 },
+ { 115, 3, 4, 3, 63, 600 },
+ { 116, 3, 4, 3, 63, 600 },
+ { 117, 3, 4, 3, 63, 600 },
+ { 118, 3, 4, 3, 63, 600 },
+ { 119, 3, 4, 3, 63, 600 },
+ { 120, 3, 4, 3, 63, 600 },
+ { 121, 3, 4, 3, 63, 600 },
+ { 122, 3, 4, 3, 63, 600 },
+ { 123, 3, 4, 3, 63, 600 },
+ { 124, 3, 4, 3, 63, 600 },
+ { 125, 3, 4, 3, 63, 600 },
+};
+
+/**
+ * xvcu_read - Read from the VCU register space
+ * @iomem: vcu reg space base address
+ * @offset: vcu reg offset from base
+ *
+ * Return: Returns 32bit value from VCU register specified
+ *
+ */
+static inline u32 xvcu_read(void __iomem *iomem, u32 offset)
+{
+ return ioread32(iomem + offset);
+}
+
+/**
+ * xvcu_write - Write to the VCU register space
+ * @iomem: vcu reg space base address
+ * @offset: vcu reg offset from base
+ * @value: Value to write
+ */
+static inline void xvcu_write(void __iomem *iomem, u32 offset, u32 value)
+{
+ iowrite32(value, iomem + offset);
+}
+
+/**
+ * xvcu_write_field_reg - Write to the vcu reg field
+ * @iomem: vcu reg space base address
+ * @offset: vcu reg offset from base
+ * @field: vcu reg field to write to
+ * @mask: vcu reg mask
+ * @shift: vcu reg number of bits to shift the bitfield
+ */
+static void xvcu_write_field_reg(void __iomem *iomem, int offset,
+ u32 field, u32 mask, int shift)
+{
+ u32 val = xvcu_read(iomem, offset);
+
+ val &= ~(mask << shift);
+ val |= (field & mask) << shift;
+
+ xvcu_write(iomem, offset, val);
+}
+
+/**
+ * xvcu_set_vcu_pll_info - Set the VCU PLL info
+ * @xvcu: Pointer to the xvcu_device structure
+ *
+ * Programming the VCU PLL based on the user configuration
+ * (ref clock freq, core clock freq, mcu clock freq).
+ * Core clock frequency has higher priority than mcu clock frequency
+ * Errors in following cases
+ * - When mcu or clock clock get from logicoreIP is 0
+ * - When VCU PLL DIV related bits value other than 1
+ * - When proper data not found for given data
+ * - When sis570_1 clocksource related operation failed
+ *
+ * Return: Returns status, either success or error+reason
+ */
+static int xvcu_set_vcu_pll_info(struct xvcu_device *xvcu)
+{
+ u32 refclk, coreclk, mcuclk, inte, deci;
+ u32 divisor_mcu, divisor_core, fvco;
+ u32 clkoutdiv, vcu_pll_ctrl, pll_clk;
+ u32 cfg_val, mod, ctrl;
+ int ret, i;
+ const struct xvcu_pll_cfg *found = NULL;
+
+ inte = xvcu_read(xvcu->logicore_reg_ba, VCU_PLL_CLK);
+ deci = xvcu_read(xvcu->logicore_reg_ba, VCU_PLL_CLK_DEC);
+ coreclk = xvcu_read(xvcu->logicore_reg_ba, VCU_CORE_CLK) * MHZ;
+ mcuclk = xvcu_read(xvcu->logicore_reg_ba, VCU_MCU_CLK) * MHZ;
+ if (!mcuclk || !coreclk) {
+ dev_err(xvcu->dev, "Invalid mcu and core clock data\n");
+ return -EINVAL;
+ }
+
+ refclk = (inte * MHZ) + (deci * (MHZ / FRAC));
+ dev_dbg(xvcu->dev, "Ref clock from logicoreIP is %uHz\n", refclk);
+ dev_dbg(xvcu->dev, "Core clock from logicoreIP is %uHz\n", coreclk);
+ dev_dbg(xvcu->dev, "Mcu clock from logicoreIP is %uHz\n", mcuclk);
+
+ clk_disable_unprepare(xvcu->pll_ref);
+ ret = clk_set_rate(xvcu->pll_ref, refclk);
+ if (ret)
+ dev_warn(xvcu->dev, "failed to set logicoreIP refclk rate\n");
+
+ ret = clk_prepare_enable(xvcu->pll_ref);
+ if (ret) {
+ dev_err(xvcu->dev, "failed to enable pll_ref clock source\n");
+ return ret;
+ }
+
+ refclk = clk_get_rate(xvcu->pll_ref);
+
+ /*
+ * The divide-by-2 should be always enabled (==1)
+ * to meet the timing in the design.
+ * Otherwise, it's an error
+ */
+ vcu_pll_ctrl = xvcu_read(xvcu->vcu_slcr_ba, VCU_PLL_CTRL);
+ clkoutdiv = vcu_pll_ctrl >> VCU_PLL_CTRL_CLKOUTDIV_SHIFT;
+ clkoutdiv = clkoutdiv && VCU_PLL_CTRL_CLKOUTDIV_MASK;
+ if (clkoutdiv != 1) {
+ dev_err(xvcu->dev, "clkoutdiv value is invalid\n");
+ return -EINVAL;
+ }
+
+ for (i = ARRAY_SIZE(xvcu_pll_cfg) - 1; i >= 0; i--) {
+ const struct xvcu_pll_cfg *cfg = &xvcu_pll_cfg[i];
+
+ fvco = cfg->fbdiv * refclk;
+ if (fvco >= FVCO_MIN && fvco <= FVCO_MAX) {
+ pll_clk = fvco / VCU_PLL_DIV2;
+ if (fvco % VCU_PLL_DIV2 != 0)
+ pll_clk++;
+ mod = pll_clk % coreclk;
+ if (mod < LIMIT) {
+ divisor_core = pll_clk / coreclk;
+ } else if (coreclk - mod < LIMIT) {
+ divisor_core = pll_clk / coreclk;
+ divisor_core++;
+ } else {
+ continue;
+ }
+ if (divisor_core >= DIVISOR_MIN &&
+ divisor_core <= DIVISOR_MAX) {
+ found = cfg;
+ divisor_mcu = pll_clk / mcuclk;
+ mod = pll_clk % mcuclk;
+ if (mcuclk - mod < LIMIT)
+ divisor_mcu++;
+ break;
+ }
+ }
+ }
+
+ if (!found) {
+ dev_err(xvcu->dev, "Invalid clock combination.\n");
+ return -EINVAL;
+ }
+
+ xvcu->coreclk = pll_clk / divisor_core;
+ mcuclk = pll_clk / divisor_mcu;
+ dev_dbg(xvcu->dev, "Actual Ref clock freq is %uHz\n", refclk);
+ dev_dbg(xvcu->dev, "Actual Core clock freq is %uHz\n", xvcu->coreclk);
+ dev_dbg(xvcu->dev, "Actual Mcu clock freq is %uHz\n", mcuclk);
+
+ vcu_pll_ctrl &= ~(VCU_PLL_CTRL_FBDIV_MASK << VCU_PLL_CTRL_FBDIV_SHIFT);
+ vcu_pll_ctrl |= (found->fbdiv & VCU_PLL_CTRL_FBDIV_MASK) <<
+ VCU_PLL_CTRL_FBDIV_SHIFT;
+ vcu_pll_ctrl &= ~(VCU_PLL_CTRL_POR_IN_MASK <<
+ VCU_PLL_CTRL_POR_IN_SHIFT);
+ vcu_pll_ctrl |= (VCU_PLL_CTRL_DEFAULT & VCU_PLL_CTRL_POR_IN_MASK) <<
+ VCU_PLL_CTRL_POR_IN_SHIFT;
+ vcu_pll_ctrl &= ~(VCU_PLL_CTRL_PWR_POR_MASK <<
+ VCU_PLL_CTRL_PWR_POR_SHIFT);
+ vcu_pll_ctrl |= (VCU_PLL_CTRL_DEFAULT & VCU_PLL_CTRL_PWR_POR_MASK) <<
+ VCU_PLL_CTRL_PWR_POR_SHIFT;
+ xvcu_write(xvcu->vcu_slcr_ba, VCU_PLL_CTRL, vcu_pll_ctrl);
+
+ /* Set divisor for the core and mcu clock */
+ ctrl = xvcu_read(xvcu->vcu_slcr_ba, VCU_ENC_CORE_CTRL);
+ ctrl &= ~(VCU_PLL_DIVISOR_MASK << VCU_PLL_DIVISOR_SHIFT);
+ ctrl |= (divisor_core & VCU_PLL_DIVISOR_MASK) <<
+ VCU_PLL_DIVISOR_SHIFT;
+ ctrl &= ~(VCU_SRCSEL_MASK << VCU_SRCSEL_SHIFT);
+ ctrl |= (VCU_SRCSEL_PLL & VCU_SRCSEL_MASK) << VCU_SRCSEL_SHIFT;
+ xvcu_write(xvcu->vcu_slcr_ba, VCU_ENC_CORE_CTRL, ctrl);
+
+ ctrl = xvcu_read(xvcu->vcu_slcr_ba, VCU_DEC_CORE_CTRL);
+ ctrl &= ~(VCU_PLL_DIVISOR_MASK << VCU_PLL_DIVISOR_SHIFT);
+ ctrl |= (divisor_core & VCU_PLL_DIVISOR_MASK) <<
+ VCU_PLL_DIVISOR_SHIFT;
+ ctrl &= ~(VCU_SRCSEL_MASK << VCU_SRCSEL_SHIFT);
+ ctrl |= (VCU_SRCSEL_PLL & VCU_SRCSEL_MASK) << VCU_SRCSEL_SHIFT;
+ xvcu_write(xvcu->vcu_slcr_ba, VCU_DEC_CORE_CTRL, ctrl);
+
+ ctrl = xvcu_read(xvcu->vcu_slcr_ba, VCU_ENC_MCU_CTRL);
+ ctrl &= ~(VCU_PLL_DIVISOR_MASK << VCU_PLL_DIVISOR_SHIFT);
+ ctrl |= (divisor_mcu & VCU_PLL_DIVISOR_MASK) << VCU_PLL_DIVISOR_SHIFT;
+ ctrl &= ~(VCU_SRCSEL_MASK << VCU_SRCSEL_SHIFT);
+ ctrl |= (VCU_SRCSEL_PLL & VCU_SRCSEL_MASK) << VCU_SRCSEL_SHIFT;
+ xvcu_write(xvcu->vcu_slcr_ba, VCU_ENC_MCU_CTRL, ctrl);
+
+ ctrl = xvcu_read(xvcu->vcu_slcr_ba, VCU_DEC_MCU_CTRL);
+ ctrl &= ~(VCU_PLL_DIVISOR_MASK << VCU_PLL_DIVISOR_SHIFT);
+ ctrl |= (divisor_mcu & VCU_PLL_DIVISOR_MASK) << VCU_PLL_DIVISOR_SHIFT;
+ ctrl &= ~(VCU_SRCSEL_MASK << VCU_SRCSEL_SHIFT);
+ ctrl |= (VCU_SRCSEL_PLL & VCU_SRCSEL_MASK) << VCU_SRCSEL_SHIFT;
+ xvcu_write(xvcu->vcu_slcr_ba, VCU_DEC_MCU_CTRL, ctrl);
+
+ /* Set RES, CP, LFHF, LOCK_CNT and LOCK_DLY cfg values */
+ cfg_val = (found->res << VCU_PLL_CFG_RES_SHIFT) |
+ (found->cp << VCU_PLL_CFG_CP_SHIFT) |
+ (found->lfhf << VCU_PLL_CFG_LFHF_SHIFT) |
+ (found->lock_cnt << VCU_PLL_CFG_LOCK_CNT_SHIFT) |
+ (found->lock_dly << VCU_PLL_CFG_LOCK_DLY_SHIFT);
+ xvcu_write(xvcu->vcu_slcr_ba, VCU_PLL_CFG, cfg_val);
+
+ return 0;
+}
+
+/**
+ * xvcu_set_pll - PLL init sequence
+ * @xvcu: Pointer to the xvcu_device structure
+ *
+ * Call the api to set the PLL info and once that is done then
+ * init the PLL sequence to make the PLL stable.
+ *
+ * Return: Returns status, either success or error+reason
+ */
+static int xvcu_set_pll(struct xvcu_device *xvcu)
+{
+ u32 lock_status;
+ unsigned long timeout;
+ int ret;
+
+ ret = xvcu_set_vcu_pll_info(xvcu);
+ if (ret) {
+ dev_err(xvcu->dev, "failed to set pll info\n");
+ return ret;
+ }
+
+ xvcu_write_field_reg(xvcu->vcu_slcr_ba, VCU_PLL_CTRL,
+ 1, VCU_PLL_CTRL_BYPASS_MASK,
+ VCU_PLL_CTRL_BYPASS_SHIFT);
+ xvcu_write_field_reg(xvcu->vcu_slcr_ba, VCU_PLL_CTRL,
+ 1, VCU_PLL_CTRL_RESET_MASK,
+ VCU_PLL_CTRL_RESET_SHIFT);
+ xvcu_write_field_reg(xvcu->vcu_slcr_ba, VCU_PLL_CTRL,
+ 0, VCU_PLL_CTRL_RESET_MASK,
+ VCU_PLL_CTRL_RESET_SHIFT);
+ /*
+ * Defined the timeout for the max time to wait the
+ * PLL_STATUS to be locked.
+ */
+ timeout = jiffies + msecs_to_jiffies(2000);
+ do {
+ lock_status = xvcu_read(xvcu->vcu_slcr_ba, VCU_PLL_STATUS);
+ if (lock_status & VCU_PLL_STATUS_LOCK_STATUS_MASK) {
+ xvcu_write_field_reg(xvcu->vcu_slcr_ba, VCU_PLL_CTRL,
+ 0, VCU_PLL_CTRL_BYPASS_MASK,
+ VCU_PLL_CTRL_BYPASS_SHIFT);
+ return 0;
+ }
+ } while (!time_after(jiffies, timeout));
+
+ /* PLL is not locked even after the timeout of the 2sec */
+ dev_err(xvcu->dev, "PLL is not locked\n");
+ return -ETIMEDOUT;
+}
+
+/**
+ * xvcu_probe - Probe existence of the logicoreIP
+ * and initialize PLL
+ *
+ * @pdev: Pointer to the platform_device structure
+ *
+ * Return: Returns 0 on success
+ * Negative error code otherwise
+ */
+static int xvcu_probe(struct platform_device *pdev)
+{
+ struct resource *res;
+ struct xvcu_device *xvcu;
+ int ret;
+
+ xvcu = devm_kzalloc(&pdev->dev, sizeof(*xvcu), GFP_KERNEL);
+ if (!xvcu)
+ return -ENOMEM;
+
+ xvcu->dev = &pdev->dev;
+ res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "vcu_slcr");
+ if (!res) {
+ dev_err(&pdev->dev, "get vcu_slcr memory resource failed.\n");
+ return -ENODEV;
+ }
+
+ xvcu->vcu_slcr_ba = devm_ioremap_nocache(&pdev->dev,
+ res->start, resource_size(res));
+ if (!xvcu->vcu_slcr_ba) {
+ dev_err(&pdev->dev, "vcu_slcr register mapping failed.\n");
+ return -ENOMEM;
+ }
+
+ res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "logicore");
+ if (!res) {
+ dev_err(&pdev->dev, "get logicore memory resource failed.\n");
+ return -ENODEV;
+ }
+
+ xvcu->logicore_reg_ba = devm_ioremap_nocache(&pdev->dev,
+ res->start, resource_size(res));
+ if (!xvcu->logicore_reg_ba) {
+ dev_err(&pdev->dev, "logicore register mapping failed.\n");
+ return -ENOMEM;
+ }
+
+ xvcu->aclk = devm_clk_get(&pdev->dev, "aclk");
+ if (IS_ERR(xvcu->aclk)) {
+ dev_err(&pdev->dev, "Could not get aclk clock\n");
+ return PTR_ERR(xvcu->aclk);
+ }
+
+ xvcu->pll_ref = devm_clk_get(&pdev->dev, "pll_ref");
+ if (IS_ERR(xvcu->pll_ref)) {
+ dev_err(&pdev->dev, "Could not get pll_ref clock\n");
+ return PTR_ERR(xvcu->pll_ref);
+ }
+
+ ret = clk_prepare_enable(xvcu->aclk);
+ if (ret) {
+ dev_err(&pdev->dev, "aclk clock enable failed\n");
+ return ret;
+ }
+
+ ret = clk_prepare_enable(xvcu->pll_ref);
+ if (ret) {
+ dev_err(&pdev->dev, "pll_ref clock enable failed\n");
+ goto error_aclk;
+ }
+
+ /*
+ * Do the Gasket isolation and put the VCU out of reset
+ * Bit 0 : Gasket isolation
+ * Bit 1 : put VCU out of reset
+ */
+ xvcu_write(xvcu->logicore_reg_ba, VCU_GASKET_INIT, VCU_GASKET_VALUE);
+
+ /* Do the PLL Settings based on the ref clk,core and mcu clk freq */
+ ret = xvcu_set_pll(xvcu);
+ if (ret) {
+ dev_err(&pdev->dev, "Failed to set the pll\n");
+ goto error_pll_ref;
+ }
+
+ dev_set_drvdata(&pdev->dev, xvcu);
+
+ dev_info(&pdev->dev, "%s: Probed successfully\n", __func__);
+
+ return 0;
+
+error_pll_ref:
+ clk_disable_unprepare(xvcu->pll_ref);
+error_aclk:
+ clk_disable_unprepare(xvcu->aclk);
+ return ret;
+}
+
+/**
+ * xvcu_remove - Insert gasket isolation
+ * and disable the clock
+ * @pdev: Pointer to the platform_device structure
+ *
+ * Return: Returns 0 on success
+ * Negative error code otherwise
+ */
+static int xvcu_remove(struct platform_device *pdev)
+{
+ struct xvcu_device *xvcu;
+
+ xvcu = platform_get_drvdata(pdev);
+ if (!xvcu)
+ return -ENODEV;
+
+ /* Add the the Gasket isolation and put the VCU in reset. */
+ xvcu_write(xvcu->logicore_reg_ba, VCU_GASKET_INIT, 0);
+
+ clk_disable_unprepare(xvcu->pll_ref);
+ clk_disable_unprepare(xvcu->aclk);
+
+ return 0;
+}
+
+static const struct of_device_id xvcu_of_id_table[] = {
+ { .compatible = "xlnx,vcu" },
+ { .compatible = "xlnx,vcu-logicoreip-1.0" },
+ { }
+};
+MODULE_DEVICE_TABLE(of, xvcu_of_id_table);
+
+static struct platform_driver xvcu_driver = {
+ .driver = {
+ .name = "xilinx-vcu",
+ .of_match_table = xvcu_of_id_table,
+ },
+ .probe = xvcu_probe,
+ .remove = xvcu_remove,
+};
+
+module_platform_driver(xvcu_driver);
+
+MODULE_AUTHOR("Dhaval Shah <dshah@xilinx.com>");
+MODULE_DESCRIPTION("Xilinx VCU init Driver");
+MODULE_LICENSE("GPL v2");
--
2.7.4
^ permalink raw reply related
* [PATCH v6 1/2] dt-bindings: soc: xilinx: Add DT bindings to xlnx_vcu driver
From: Dhaval Shah @ 2017-12-21 18:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513881186-26020-1-git-send-email-dshah@xilinx.com>
Add Device Tree binding document for logicoreIP. This logicoreIP
provides the isolation between the processing system and
programmable logic. Also provides the clock related information.
Signed-off-by: Dhaval Shah <dshah@xilinx.com>
Reviewed-by: Rob Herring <robh@kernel.org>
---
Changes since v6:
* Updated path of the dt-bindings doc as driver path is updated.
Chnages since v5:
No Changes.
Chnages since v4:
No Changes.
Chnages since v3:
* Use "dt-bindings: misc: ..." for the subject.
Changes since v2:
* Describe the h/w
* compatible string is updated to make it more specific
based on the logicoreIP version.
* Removed that encoder and decoder child nodes and relatd properties as that
will be a separate driver and dts nodes. other team is working on that.
* Updated to use as a single driver.
.../devicetree/bindings/soc/xilinx/xlnx,vcu.txt | 31 ++++++++++++++++++++++
1 file changed, 31 insertions(+)
create mode 100644 Documentation/devicetree/bindings/soc/xilinx/xlnx,vcu.txt
diff --git a/Documentation/devicetree/bindings/soc/xilinx/xlnx,vcu.txt b/Documentation/devicetree/bindings/soc/xilinx/xlnx,vcu.txt
new file mode 100644
index 0000000..6786d67
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/xilinx/xlnx,vcu.txt
@@ -0,0 +1,31 @@
+LogicoreIP designed compatible with Xilinx ZYNQ family.
+-------------------------------------------------------
+
+General concept
+---------------
+
+LogicoreIP design to provide the isolation between processing system
+and programmable logic. Also provides the list of register set to configure
+the frequency.
+
+Required properties:
+- compatible: shall be one of:
+ "xlnx,vcu"
+ "xlnx,vcu-logicoreip-1.0"
+- reg, reg-names: There are two sets of registers need to provide.
+ 1. vcu slcr
+ 2. Logicore
+ reg-names should contain name for the each register sequence.
+- clocks: phandle for aclk and pll_ref clocksource
+- clock-names: The identification string, "aclk", is always required for
+ the axi clock. "pll_ref" is required for pll.
+Example:
+
+ xlnx_vcu: vcu at a0040000 {
+ compatible = "xlnx,vcu-logicoreip-1.0";
+ reg = <0x0 0xa0040000 0x0 0x1000>,
+ <0x0 0xa0041000 0x0 0x1000>;
+ reg-names = "vcu_slcr", "logicore";
+ clocks = <&si570_1>, <&clkc 71>;
+ clock-names = "pll_ref", "aclk";
+ };
--
2.7.4
^ permalink raw reply related
* [PATCH v6 0/2] Documentation and driver of logicoreIP
From: Dhaval Shah @ 2017-12-21 18:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAK8P3a0z6HF8Rg08HUj7_T+7ZxxnHoReiu68bNzF6CnEooQSdA@mail.gmail.com>
1st patch provide Device Tree binding document for logicoreIP
2nd patch provide the xlnx_vcu logicoreIP driver, Kconfig changes
and Makefile changes for the driver.
Dhaval Shah (2):
dt-bindings: misc: Add DT bindings to xlnx_vcu driver
misc: xlnx_vcu: Add Xilinx ZYNQMP VCU logicoreIP init driver
.../devicetree/bindings/soc/xilinx/xlnx,vcu.txt | 31 +
drivers/soc/xilinx/Kconfig | 15 +
drivers/soc/xilinx/Makefile | 1 +
drivers/soc/xilinx/xlnx_vcu.c | 630 +++++++++++++++++++++
4 files changed, 677 insertions(+)
create mode 100644 Documentation/devicetree/bindings/soc/xilinx/xlnx,vcu.txt
create mode 100644 drivers/soc/xilinx/xlnx_vcu.c
--
2.7.4
^ permalink raw reply
* [PATCH V2 02/10] clk: reparent orphans after critical clocks enabled
From: Stephen Boyd @ 2017-12-21 18:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171220143322.GC30461@b29396-OptiPlex-7040>
On 12/20, Dong Aisheng wrote:
> On Thu, Nov 02, 2017 at 12:36:09AM -0700, Stephen Boyd wrote:
> > On 07/13, Dong Aisheng wrote:
> > > The orphan clocks reparent operation should be moved after the critical
> > > clocks enabled, otherwise it may get a chance to disable a newly
> > > registered critical clock which triggers the following warning.
> > >
> > > Assuming we have two clocks: A and B, B is the parent of A.
> > > Clock A has flag: CLK_OPS_PARENT_ENABLE
> > > Clock B has flag: CLK_IS_CRITICAL
> > >
> > > Step 1:
> > > Clock A is registered, then it becomes orphan.
> > >
> > > Step 2:
> > > Clock B is registered. Before clock B reach the critical clock enable
> > > operation, orphan A will find the newly registered parent B and do
> > > reparent operation, then parent B will be finally disabled in
> > > __clk_set_parent_after() due to CLK_OPS_PARENT_ENABLE flag as there's
> > > still no users of B which will then trigger the following warning.
> > >
> > > [ 0.000000] WARNING: CPU: 0 PID: 0 at drivers/clk/clk.c:597 clk_core_disable+0xb4/0xe0
> > > [ 0.000000] Modules linked in:
> > > [ 0.000000] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.11.0-rc1-00056-gdff1f66-dirty #1373
> > > [ 0.000000] Hardware name: Generic DT based system
> > > [ 0.000000] Backtrace:
> > > [ 0.000000] [<c010c4bc>] (dump_backtrace) from [<c010c764>] (show_stack+0x18/0x1c)
> > > [ 0.000000] r6:600000d3 r5:00000000 r4:c0e26358 r3:00000000
> > > [ 0.000000] [<c010c74c>] (show_stack) from [<c040599c>] (dump_stack+0xb4/0xe8)
> > > [ 0.000000] [<c04058e8>] (dump_stack) from [<c0125c94>] (__warn+0xd8/0x104)
> > > [ 0.000000] r10:c0c21cd0 r9:c048aa78 r8:00000255 r7:00000009 r6:c0c1cd90 r5:00000000
> > > [ 0.000000] r4:00000000 r3:c0e01d34
> > > [ 0.000000] [<c0125bbc>] (__warn) from [<c0125d74>] (warn_slowpath_null+0x28/0x30)
> > > [ 0.000000] r9:00000000 r8:ef00bf80 r7:c165ac4c r6:ef00bf80 r5:ef00bf80 r4:ef00bf80
> > > [ 0.000000] [<c0125d4c>] (warn_slowpath_null) from [<c048aa78>] (clk_core_disable+0xb4/0xe0)
> > > [ 0.000000] [<c048a9c4>] (clk_core_disable) from [<c048be88>] (clk_core_disable_lock+0x20/0x2c)
> > > [ 0.000000] r4:000000d3 r3:c0e0af00
> > > [ 0.000000] [<c048be68>] (clk_core_disable_lock) from [<c048c224>] (clk_core_disable_unprepare+0x14/0x28)
> > > [ 0.000000] r5:00000000 r4:ef00bf80
> > > [ 0.000000] [<c048c210>] (clk_core_disable_unprepare) from [<c048c270>] (__clk_set_parent_after+0x38/0x54)
> > > [ 0.000000] r4:ef00bd80 r3:000010a0
> > > [ 0.000000] [<c048c238>] (__clk_set_parent_after) from [<c048daa8>] (clk_register+0x4d0/0x648)
> > > [ 0.000000] r6:ef00d500 r5:ef00bf80 r4:ef00bd80 r3:ef00bfd4
> > > [ 0.000000] [<c048d5d8>] (clk_register) from [<c048dc30>] (clk_hw_register+0x10/0x1c)
> > > [ 0.000000] r9:00000000 r8:00000003 r7:00000000 r6:00000824 r5:00000001 r4:ef00d500
> > > [ 0.000000] [<c048dc20>] (clk_hw_register) from [<c048e698>] (_register_divider+0xcc/0x120)
> > > [ 0.000000] [<c048e5cc>] (_register_divider) from [<c048e730>] (clk_register_divider+0x44/0x54)
> > > [ 0.000000] r10:00000004 r9:00000003 r8:00000001 r7:00000000 r6:00000003 r5:00000001
> > > [ 0.000000] r4:f0810030
> > > [ 0.000000] [<c048e6ec>] (clk_register_divider) from [<c0d3ff58>] (imx7ulp_clocks_init+0x558/0xe98)
> > > [ 0.000000] r7:c0e296f8 r6:c165c808 r5:00000000 r4:c165c808
> > > [ 0.000000] [<c0d3fa00>] (imx7ulp_clocks_init) from [<c0d24db0>] (of_clk_init+0x118/0x1e0)
> > > [ 0.000000] r10:00000001 r9:c0e01f68 r8:00000000 r7:c0e01f60 r6:ef7f8974 r5:ef0035c0
> > > [ 0.000000] r4:00000006
> > > [ 0.000000] [<c0d24c98>] (of_clk_init) from [<c0d04a50>] (time_init+0x2c/0x38)
> > > [ 0.000000] r10:efffed40 r9:c0d61a48 r8:c0e78000 r7:c0e07900 r6:ffffffff r5:c0e78000
> > > [ 0.000000] r4:00000000
> > > [ 0.000000] [<c0d04a24>] (time_init) from [<c0d00b8c>] (start_kernel+0x218/0x394)
> > > [ 0.000000] [<c0d00974>] (start_kernel) from [<6000807c>] (0x6000807c)
> > > [ 0.000000] r10:00000000 r9:410fc075 r8:6000406a r7:c0e0c930 r6:c0d61a44 r5:c0e07918
> > > [ 0.000000] r4:c0e78294
> > > [ 0.000000] ---[ end trace 0000000000000000 ]---
> >
> > Please remove timestamps from logs unless they're important.
> >
>
> Got it.
>
> > >
> > > Fixes: fc8726a2c021 ("clk: core: support clocks which requires parents enable (part 2)")
> > > Cc: Stephen Boyd <sboyd@codeaurora.org>
> > > Cc: Michael Turquette <mturquette@baylibre.com>
> > > Cc: Shawn Guo <shawnguo@kernel.org>
> > > Signed-off-by: Dong Aisheng <aisheng.dong@nxp.com>
> > >
> > > ---
> > > ChangeLog:
> > > v1->v2:
> > > * add more detailed commit messages
> >
> > Thanks for that. We shouldn't be touching the hardware during clk
> > registration though, so something is wrong there. It seems that
> > adding the flag to enable clks when touching their registers has
> > exposed that we should just be doing the toggle of the bookeeping
> > stuff underneath the enable lock here.
> >
> > We know that the clk isn't enabled with any sort of prepare_count
> > here so we don't need to enable anything to prevent a race. And
> > we're holding the prepare mutex so set_rate/set_parent can't race
> > here either.
> >
>
> Well, it looks like a good suggestion and it does make sense.
>
> > Can you try this patch instead?
> >
> > ---8<----
> > diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> > index c8d83acda006..416d44cc772c 100644
> > --- a/drivers/clk/clk.c
> > +++ b/drivers/clk/clk.c
> > @@ -2476,14 +2476,17 @@ static int __clk_core_init(struct clk_core *core)
> > */
> > hlist_for_each_entry_safe(orphan, tmp2, &clk_orphan_list, child_node) {
> > struct clk_core *parent = __clk_init_parent(orphan);
> > + unsigned long flags;
> >
> > /*
> > * we could call __clk_set_parent, but that would result in a
> > * redundant call to the .set_rate op, if it exists
> > */
> > if (parent) {
> > - __clk_set_parent_before(orphan, parent);
> > - __clk_set_parent_after(orphan, parent, NULL);
> > + /* update the clk tree topology */
> > + flags = clk_enable_lock();
> > + clk_reparent(orphan, parent);
> > + clk_enable_unlock(flags);
> > __clk_recalc_accuracies(orphan);
> > __clk_recalc_rates(orphan, 0);
> > }
>
>
> I tested this change worked well.
> I could resent the patch with this new method later.
>
Ok. Great. I'm going to apply this patch now into clk-next to
look for regressions on other platforms. If this was the only
questionable thing about this series then I think I can apply the
rest of it without you needing to resend. I'll check today.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [GIT PULL 2/2] Rockchip dts64 changes for 4.16
From: Heiko Stuebner @ 2017-12-21 18:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2013174.TmhWXT9G0E@phil>
The following changes since commit 4fbd8d194f06c8a3fd2af1ce560ddb31f7ec8323:
Linux 4.15-rc1 (2017-11-26 16:01:47 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip.git tags/v4.16-rockchip-dts64-1
for you to fetch changes up to 13bc2c0a6a14f430abaa6a859792418644b7febd:
arm64: dts: rockchip: Add efuse device node for RK3328 SoC (2017-12-20 13:12:13 +0100)
----------------------------------------------------------------
General RK3399 gets Mipi nodes, fixes for usb3 support and better support
for the type-c phys. The Kevin Chromebooks based on rk3399 now can use their
internal edp displays. RK3328 gets its efuse node and Mali450 gpu node,
which actually produces already some nice results with the WIP Lima driver.
----------------------------------------------------------------
Brian Norris (1):
arm64: dts: rockchip: add rk3399 DSI0 reset
Enric Balletbo i Serra (5):
arm64: dts: rockchip: add pd_usb3 power-domain node for rk3399
arm64: dts: rockchip: add the aclk_usb3 clocks for USB3 on rk3399
arm64: dts: rockchip: add reset property for dwc3 controllers on rk3399
arm64: dts: rockchip: add usb3-phy otg-port support for rk3399
arm64: dts: rockchip: add extcon nodes and enable tcphy rk3399-gru
Finley Xiao (1):
arm64: dts: rockchip: Add efuse device node for RK3328 SoC
Heiko Stuebner (2):
dt-bindings: gpu: mali-utgard: add rockchip,rk3328-mali compatible
arm64: dts: rockchip: add rk3328 mali gpu node
Jeffy Chen (1):
arm64: dts: rockchip: Enable edp disaplay on kevin
Nickey Yang (2):
arm64: dts: rockchip: add mipi_dsi1 support for rk3399
arm64: dts: rockchip: update mipi cells for RK3399
.../devicetree/bindings/gpu/arm,mali-utgard.txt | 1 +
arch/arm64/boot/dts/rockchip/rk3328.dtsi | 47 ++++++++++++
arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts | 29 ++++++++
arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi | 42 +++++++++++
arch/arm64/boot/dts/rockchip/rk3399.dtsi | 85 +++++++++++++++++++---
5 files changed, 195 insertions(+), 9 deletions(-)
^ permalink raw reply
* [GIT PULL 1/2] Rockchip dts32 changes for 4.16
From: Heiko Stuebner @ 2017-12-21 18:30 UTC (permalink / raw)
To: linux-arm-kernel
Hi Arnd, Kevin, Olof,
please find below and in the next mail Rockchip changes for 4.16.
The volume especially on 32bit is quite low this time, possibly due
to the holiday season. So if nothing looks bad, please pull
Thanks and merry xmas
Heiko
The following changes since commit 4fbd8d194f06c8a3fd2af1ce560ddb31f7ec8323:
Linux 4.15-rc1 (2017-11-26 16:01:47 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip.git tags/v4.16-rockchip-dts32-1
for you to fetch changes up to fe8fd85a23a746bd7f0a14e5dcd55c9bc517a055:
ARM: dts: rockchip: add reset property for rk3066a-rayeager emac phy (2017-12-16 21:09:37 +0100)
----------------------------------------------------------------
Just the reset property for the rk3066a-rayeager emac phy
----------------------------------------------------------------
Chris Zhong (1):
ARM: dts: rockchip: add reset property for rk3066a-rayeager emac phy
arch/arm/boot/dts/rk3066a-rayeager.dts | 1 +
1 file changed, 1 insertion(+)
^ permalink raw reply
* [PATCH v2] ARM: dts: sunxi: Add sid for a83t
From: Emmanuel Vadot @ 2017-12-21 18:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171221152630.2vf57x5o2yi5sv3n@flea.lan>
Hi Maxime,
On Thu, 21 Dec 2017 16:26:30 +0100
Maxime Ripard <maxime.ripard@free-electrons.com> wrote:
> Hi,
>
> On Thu, Dec 21, 2017 at 09:19:24AM -0600, Kyle Evans wrote:
> > On Thu, Dec 21, 2017 at 8:55 AM, Maxime Ripard
> > <maxime.ripard@free-electrons.com> wrote:
> > > Hi Kyle,
> > >
> > > On Tue, Dec 19, 2017 at 03:05:23PM -0600, kevans91 at ksu.edu wrote:
> > >> Allwinner a83t has a 1 KB sid block with efuse for security rootkey and
> > >> thermal calibration data, add node to describe it.
> > >>
> > >> a83t-sid is not currently supported by nvmem/sunxi-sid, but it is
> > >> supported in an external driver for FreeBSD.
> > >>
> > >> Signed-off-by: Kyle Evans <kevans91@ksu.edu>
> > >
> > > The patch looks fine in itself, but we've had a number of issues with
> > > the register layout (and access patterns) in the past, so I'd rather
> > > have something that works in Linux too if possible.
> >
> > I have a patch that I think should make it work fine on Linux [1], but
> > I'm afraid I have little to no capability to test it myself and so I
> > did not add it as well.
> >
> > I do know that the rootkey is offset 0x200 into the given space [2],
> > as is the case with the H3, and that the readout quirk is not needed.
> > I wasn't 100% sure that the a83t has 2Kbit worth of efuse space as the
> > H3, but I do know that thermal data can be found at 0x34 and 0x38 in
> > this space.
>
> Then maybe we should leave it aside until someone takes some time on
> the A83t.
Take some time on the Linux driver and do not apply this patch for
now you mean ?
Cheers,
> The good news is that the binding itself looks fine, so as
> far as FreeBSD goes, there shouldn't be anything preventing you from
> using it I guess.
>
> Chen-Yu, what do you think?
>
> Thanks!
> Maxime
>
> --
> Maxime Ripard, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com
--
Emmanuel Vadot <manu@bidouilliste.com>
^ permalink raw reply
* [PATCH 4/4] ARM: dts: vf610-zii-dev-rev-b: add interrupts for 88e1545 PHY
From: Russell King - ARM Linux @ 2017-12-21 17:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171221134058.GA15416@lunn.ch>
On Thu, Dec 21, 2017 at 02:40:58PM +0100, Andrew Lunn wrote:
> On Thu, Dec 21, 2017 at 01:32:21PM +0100, Linus Walleij wrote:
> > On Thu, Dec 21, 2017 at 12:12 AM, Russell King
> > <rmk+kernel@armlinux.org.uk> wrote:
> >
> > > The 88e1545 PHY has its interrupts wired to the VF610, so we might as
> > > well use them.
> > >
> > > Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
> > > ---
> > > This is certainly not correct, as all PHYs on this device share the
> > > same interrupt line, but we can't specify the pinmux settings
> > > individually on each PHY. How should this be handled?
> >
> > I do not know the details of the Marvell switch.
>
> Hi Linus
>
> The 88e1545 is a discreet quad PHY. It is connected to the switch, but
> not integrated into the switch. All its interrupt handling is done
> with a GPIO onto the Freescale processor, via a GPIO. There is nothing
> DSA related here at all with respect to the interrupt. It is just a
> normal GPIO interrupt. What is a bit odd is that it one shared
> interrupt for all four PHYs.
>
> What you described with an irqchip inside the switch is what we
> actually do for the internal PHYs on Marvell devices. And it is what i
> recommend for all DSA drivers. Expose standard IRQs, and let phylib
> use them in its normal way.
... and it has to be said that model doesn't work in this case,
because, although there is the possibility to demux the interrupt
any of the PHYs, you already need to be driving one of the PHYs.
It's not an interrupt controller itself (there's no possibility to
enable/disable individual interrupts from a PHY) so it doesn't make
sense.
What we have here is _really_ a shared interrupt between four
separate devices, and we need a way to sanely describe resources
shared between several device instances to pinmux. Unfortunately,
it seems pinmux is designed around one device having exclusive use
of a resource, which makes it hard to describe shared interrupts in
DT.
Given that DT should be a description of the hardware, and should be
independent of the OS implementation, I'd say this is a pinmux bug,
because pinmux gets in the way of describing the hardware correctly.
;)
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
^ permalink raw reply
* [GIT PULL v2] arm: Updates for soc driver for v4.15-next
From: Arnd Bergmann @ 2017-12-21 17:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5e11ef1f-fe9d-61c6-abe4-44ba4c99e060@gmail.com>
On Thu, Dec 21, 2017 at 12:48 PM, Matthias Brugger
<matthias.bgg@gmail.com> wrote:
> ----------------------------------------------------------------
> - change kconfig entry for armv7 SoCs to be more generic
> - add support for mt2701 scpsys driver
> binding documentation
> extend driver to allow the bus protection to overwrite the register
Pulled into next/soc, thanks!
Arnd
^ permalink raw reply
* [GIT PULL v2] arm64: Updates of aarch64 DTS for v4.15-next
From: Arnd Bergmann @ 2017-12-21 17:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <9bcf1c0b-b60a-fff1-d259-02d791bf561b@gmail.com>
On Thu, Dec 21, 2017 at 12:47 PM, Matthias Brugger
<matthias.bgg@gmail.com> wrote:
>
> arm64: dts: Add power controller device node of MT2712 (2017-12-21 11:35:18 +0100)
>
> ----------------------------------------------------------------
> - mt8173 add cpufreq related nodes
> supply nodes
> frequency/voltage operation table
>
> - mt2712 add cpufreq related nodes
> fixed regulator
> supply nodes
> frequency/voltage operation table
> - mt2712 add clock contoller nodes
> - mt2712 add scpsys node
>
Pulled into next/dt64, thanks!
Arnd
^ permalink raw reply
* [GIT PULL v2] arm: Updates of armv7 DTS for v4.15-next
From: Arnd Bergmann @ 2017-12-21 17:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <938d913c-02c2-e44c-1c03-e620276ce35e@gmail.com>
On Thu, Dec 21, 2017 at 12:45 PM, Matthias Brugger
<matthias.bgg@gmail.com> wrote:
> The following changes since commit 4fbd8d194f06c8a3fd2af1ce560ddb31f7ec8323:
>
> Linux 4.15-rc1 (2017-11-26 16:01:47 -0800)
>
> are available in the Git repository at:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux.git
> tags/v4.15-next-dts32
>
> for you to fetch changes up to a227cf4dfd74a873857c9cc017100168d01539ed:
>
> dt-bindings: ARM: Mediatek: Fix ethsys documentation (2017-12-20 18:10:12 +0100)
>
> ----------------------------------------------------------------
> - add reset cells mt2701 and mt7623 ethsys
> - update mmc nodes for mt7623
> - mt7623 change mmc card detection pin to active low
> - mt7623 set unit address to lower case
Pulled into next/dt, thanks!
Arnd
^ permalink raw reply
* [GIT PULL 3/5] memory: tegra: Changes for v4.16-rc1
From: Arnd Bergmann @ 2017-12-21 17:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171220191900.757-3-thierry.reding@gmail.com>
On Wed, Dec 20, 2017 at 8:18 PM, Thierry Reding
<thierry.reding@gmail.com> wrote:
> ----------------------------------------------------------------
> memory: tegra: Changes for v4.16-rc1
>
> The Tegra memory controller driver will now instruct the SMMU driver to
> create groups, which will make it easier for device drivers to share an
> IOMMU domain between multiple devices.
>
> Initial Tegra186 support is also added in a separate driver.
Pulled into next/drivers.
Arnd
^ permalink raw reply
* [GIT PULL v2 2/5] soc/tegra: Changes for v4.16-rc1
From: Arnd Bergmann @ 2017-12-21 17:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171221161252.12920-1-thierry.reding@gmail.com>
On Thu, Dec 21, 2017 at 5:12 PM, Thierry Reding
<thierry.reding@gmail.com> wrote:
>
> soc/tegra: fuse: Explicitly request DMA channel from APB DMA driver (2017-12-21 17:04:12 +0100)
>
> This includes two additional patches that have been sitting in patchwork
> for a long time and that I had forgotten to include. Please ignore the
> first pull request and pull this instead.
>
> Thanks,
> Thierry
>
> ----------------------------------------------------------------
> soc/tegra: Changes for v4.16-rc1
>
> Fuse and chip ID support for Tegra186 is added in this set of changes,
> followed by some unification work for the PMC driver in order to avoid
> code duplication between Tegra186 and prior chips.
>
> This also contains a couple of fixes for reading fuses on Tegra20.
Pulled into next/soc, thanks!
Arnd
^ permalink raw reply
* [PATCH, RFT] ARM: use --fix-v4bx to allow building ARMv4 with future gcc
From: Arnd Bergmann @ 2017-12-21 17:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkday7Z8NM9_tapSHUNVdNbdZcup-kagg65p+sEzwNXqp5g@mail.gmail.com>
On Thu, Dec 21, 2017 at 5:57 PM, Linus Walleij <linus.walleij@linaro.org> wrote:
> On Wed, Dec 20, 2017 at 2:00 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>
>> gcc-6.0 and later marks support for ARMv3 and ARMv4 as 'deprecated',
>> meaning that this is expected to be removed at some point in the future,
>> with gcc-8.0 as the earliest.
>>
>> When building the kernel, the difference between ARMv4 and ARMv4T
>> is relatively small because the kernel never runs THUMB instructions
>> on ARMv4T and does not need any support for interworking.
>>
>> For any future compiler that does not support -march=armv4, we now
>> fall back to -march=armv4t as the architecture level selection,
>> but keep using -march=armv4 by default as long as that is supported
>> by the compiler.
>>
>> Similarly, the -mtune=strongarm110 and -mtune=strongarm1100 options
>> will go away at the same time as -march=armv4, so this adds a check
>> to see if the compiler supports them, falling back to no -mtune
>> option otherwise.
>>
>> Compiling with -march=armv4t leads the compiler to using 'bx reg'
>> instructions instead of 'mov pc,reg'. This is not supported on
>> ARMv4 based CPUs, but the linker can work around this by rewriting
>> those instructions to the ARMv4 version if we pass --fix-v4bx
>> to the linker. This should work with binutils-2.15 (released
>> May 2004) or higher, and we can probably assume that anyone using
>> gcc-7.x will have a much more recent binutils version as well.
>>
>> However, in order to still allow users of old toolchains to link
>> the kernel, we only pass the option to linkers that support it,
>> based on a $(ld-option ...) call. I'm intentionally passing the
>> flag to all linker versions here regardless of whether it's needed
>> or not, so we can more easily spot any regressions if something
>> goes wrong.
>>
>> For consistency, I'm passing the --fix-v4bx flag for both the
>> vmlinux final link and the individual loadable modules.
>> The module loader code already interprets the R_ARM_V4BX relocations
>> in loadable modules and converts bx instructions into mov even
>> when running on ARMv4T or ARMv5 processors. This is now redundant
>> when we pass --fix-v4bx to the linker for building modules, but
>> I see no harm in leaving the current implementation and doing both.
>>
>> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>> ---
>> Please test by making the -march=armv4t switch unconditional
>> and see if that results in a working kernel
>
> I did this:
> diff --git a/arch/arm/Makefile b/arch/arm/Makefile
> index 66e46aec0cd0..3944ecd6cd31 100644
> --- a/arch/arm/Makefile
> +++ b/arch/arm/Makefile
> @@ -81,7 +81,7 @@ arch-$(CONFIG_CPU_32v6K)
> =-D__LINUX_ARM_ARCH__=6 $(call cc-option,-march=armv6k,
> endif
> arch-$(CONFIG_CPU_32v5) =-D__LINUX_ARM_ARCH__=5 $(call
> cc-option,-march=armv5te,-march=armv4t)
> arch-$(CONFIG_CPU_32v4T) =-D__LINUX_ARM_ARCH__=4 -march=armv4t
> -arch-$(CONFIG_CPU_32v4) =-D__LINUX_ARM_ARCH__=4 $(call
> cc-option,-march=armv4,-march=armv4t)
> +arch-$(CONFIG_CPU_32v4) =-D__LINUX_ARM_ARCH__=4 -march=armv4t
> arch-$(CONFIG_CPU_32v3) =-D__LINUX_ARM_ARCH__=3 -march=armv3
>
> Built and booted on the Gemini platform.
>
> It crashes immediately and goes into the boot loader
> on thos FA-526 based platform.
Hmm, maybe the decompressor needs the fixup separately. Can you try
something like this completely untested patch on top?
Arnd
diff --git a/arch/arm/boot/compressed/Makefile
b/arch/arm/boot/compressed/Makefile
index f0548b6948f1..0e141b2cae98 100644
--- a/arch/arm/boot/compressed/Makefile
+++ b/arch/arm/boot/compressed/Makefile
@@ -134,6 +134,11 @@ endif
ifeq ($(CONFIG_CPU_ENDIAN_BE8),y)
LDFLAGS_vmlinux += --be8
endif
+
+ifdef CONFIG_CPU_32v4
+LDFLAGS_vmlinux += --fix-v4bx
+endif
+
# ?
LDFLAGS_vmlinux += -p
# Report unresolved symbol references
^ permalink raw reply related
* [PATCH 03/10] arm64: handle 52-bit addresses in TTBR
From: Marc Zyngier @ 2017-12-21 17:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171221164851.edxq536yobjuagwe@armageddon.cambridge.arm.com>
On 21/12/17 16:48, Catalin Marinas wrote:
> On Thu, Dec 14, 2017 at 06:50:05PM +0000, Marc Zyngier wrote:
>> On 13/12/17 17:07, Kristina Martsenko wrote:
>>> diff --git a/arch/arm64/include/asm/pgtable-hwdef.h b/arch/arm64/include/asm/pgtable-hwdef.h
>>> index eb0c2bd90de9..2b3104af79d0 100644
>>> --- a/arch/arm64/include/asm/pgtable-hwdef.h
>>> +++ b/arch/arm64/include/asm/pgtable-hwdef.h
>>> @@ -16,6 +16,8 @@
>>> #ifndef __ASM_PGTABLE_HWDEF_H
>>> #define __ASM_PGTABLE_HWDEF_H
>>>
>>> +#include <asm/memory.h>
>>> +
>>> /*
>>> * Number of page-table levels required to address 'va_bits' wide
>>> * address, without section mapping. We resolve the top (va_bits - PAGE_SHIFT)
>>> @@ -277,4 +279,11 @@
>>> #define TCR_HA (UL(1) << 39)
>>> #define TCR_HD (UL(1) << 40)
>>>
>>> +/*
>>> + * TTBR
>>> + */
>>> +#ifdef CONFIG_ARM64_PA_BITS_52
>>> +#define TTBR_BADDR_MASK_52 (((UL(1) << 46) - 1) << 2)
>>
>> This really hurts by brain. How about
>>
>> #define TTBR_BADDR_MASK_52 GENMASK_UL(47, 2)
>
> This file is included in assembly code and GENMASK_ULL has a C-only
> version (include/linux/bitops.h). I'll leave Kristina's original code in
> place.
Ah, that's a shame. I really liked it! ;-)
>
>> instead, together with a comment saying that TTBR[1] is RES0.
>
> I can add the comment.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH v2] i2c/ARM: davinci: Deep refactoring of I2C recovery
From: Arnd Bergmann @ 2017-12-21 16:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdY73GCcT24RsL3AGpGJDrwScHni1dYzSGm8rphZ8x0nZw@mail.gmail.com>
On Thu, Dec 21, 2017 at 5:48 PM, Linus Walleij <linus.walleij@linaro.org> wrote:
> On Thu, Dec 21, 2017 at 4:36 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>> On Wed, Dec 20, 2017 at 1:17 PM, Linus Walleij <linus.walleij@linaro.org> wrote:
>>> Alter the DaVinci GPIO recovery fetch to use descriptors
>>> all the way down into the board files.
>>>
>>> Cc: arm at kernel.org
>>> Cc: Kevin Hilman <khilman@kernel.org>
>>> Cc: Keerthy <j-keerthy@ti.com>
>>> Cc: Sekhar Nori <nsekhar@ti.com>
>>> Acked-by: Sekhar Nori <nsekhar@ti.com>
>>> Tested-by: Sekhar Nori <nsekhar@ti.com>
>>> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
>>> ---
>>> ChangeLog v1->v2:
>>> - Change gpiochip name from gpio_davinci.0 to gpio_davinci, simply.
>>
>> This seems to clash with "i2c: davinci: Add PM Runtime Support", please
>> rebase on top of v4.15-rc and resend.
>
> Since it is dependent on changes in the I2C tree and the
> current patch is based on linux-next I guess something
> got applied ahead of me, I guess I should just rebase
> on Wolfram's tree.
If it helps, you could merge the patch through his tree with my
Acked-by: Arnd Bergmann <arnd@arndb.de>
Arnd
^ permalink raw reply
* [PATCH, RFT] ARM: use --fix-v4bx to allow building ARMv4 with future gcc
From: Linus Walleij @ 2017-12-21 16:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171220130016.3156090-1-arnd@arndb.de>
On Wed, Dec 20, 2017 at 2:00 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> gcc-6.0 and later marks support for ARMv3 and ARMv4 as 'deprecated',
> meaning that this is expected to be removed at some point in the future,
> with gcc-8.0 as the earliest.
>
> When building the kernel, the difference between ARMv4 and ARMv4T
> is relatively small because the kernel never runs THUMB instructions
> on ARMv4T and does not need any support for interworking.
>
> For any future compiler that does not support -march=armv4, we now
> fall back to -march=armv4t as the architecture level selection,
> but keep using -march=armv4 by default as long as that is supported
> by the compiler.
>
> Similarly, the -mtune=strongarm110 and -mtune=strongarm1100 options
> will go away at the same time as -march=armv4, so this adds a check
> to see if the compiler supports them, falling back to no -mtune
> option otherwise.
>
> Compiling with -march=armv4t leads the compiler to using 'bx reg'
> instructions instead of 'mov pc,reg'. This is not supported on
> ARMv4 based CPUs, but the linker can work around this by rewriting
> those instructions to the ARMv4 version if we pass --fix-v4bx
> to the linker. This should work with binutils-2.15 (released
> May 2004) or higher, and we can probably assume that anyone using
> gcc-7.x will have a much more recent binutils version as well.
>
> However, in order to still allow users of old toolchains to link
> the kernel, we only pass the option to linkers that support it,
> based on a $(ld-option ...) call. I'm intentionally passing the
> flag to all linker versions here regardless of whether it's needed
> or not, so we can more easily spot any regressions if something
> goes wrong.
>
> For consistency, I'm passing the --fix-v4bx flag for both the
> vmlinux final link and the individual loadable modules.
> The module loader code already interprets the R_ARM_V4BX relocations
> in loadable modules and converts bx instructions into mov even
> when running on ARMv4T or ARMv5 processors. This is now redundant
> when we pass --fix-v4bx to the linker for building modules, but
> I see no harm in leaving the current implementation and doing both.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> Please test by making the -march=armv4t switch unconditional
> and see if that results in a working kernel
I did this:
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index 66e46aec0cd0..3944ecd6cd31 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -81,7 +81,7 @@ arch-$(CONFIG_CPU_32v6K)
=-D__LINUX_ARM_ARCH__=6 $(call cc-option,-march=armv6k,
endif
arch-$(CONFIG_CPU_32v5) =-D__LINUX_ARM_ARCH__=5 $(call
cc-option,-march=armv5te,-march=armv4t)
arch-$(CONFIG_CPU_32v4T) =-D__LINUX_ARM_ARCH__=4 -march=armv4t
-arch-$(CONFIG_CPU_32v4) =-D__LINUX_ARM_ARCH__=4 $(call
cc-option,-march=armv4,-march=armv4t)
+arch-$(CONFIG_CPU_32v4) =-D__LINUX_ARM_ARCH__=4 -march=armv4t
arch-$(CONFIG_CPU_32v3) =-D__LINUX_ARM_ARCH__=3 -march=armv3
Built and booted on the Gemini platform.
It crashes immediately and goes into the boot loader
on thos FA-526 based platform.
Yours,
Linus Walleij
^ permalink raw reply related
* [GIT PULL 5/5] arm64: tegra: Changes for v4.16-rc1
From: Arnd Bergmann @ 2017-12-21 16:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171220191900.757-5-thierry.reding@gmail.com>
On Wed, Dec 20, 2017 at 8:19 PM, Thierry Reding
<thierry.reding@gmail.com> wrote:
> ----------------------------------------------------------------
> arm64: tegra: Changes for v4.16-rc1
>
> This set of patches enables a bunch of new features on Jetson TX2 that
> were finally unblocked by the GPIO driver getting merged for v4.15.
Pulled into next/dt, thanks!
Arnd
^ permalink raw reply
* [GIT PULL 4/5] ARM: tegra: Device tree changes for v4.16-rc1
From: Arnd Bergmann @ 2017-12-21 16:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171220191900.757-4-thierry.reding@gmail.com>
On Wed, Dec 20, 2017 at 8:18 PM, Thierry Reding
<thierry.reding@gmail.com> wrote:
> ----------------------------------------------------------------
> ARM: tegra: Device tree changes for v4.16-rc1
>
> These changes enable the video decoder engine found on Tegra20 SoCs.
Pulled into next/dt, thanks!
Arnd
^ 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