* [PATCH 17/18] arm64: convert compat wrappers to C
From: Christoph Hellwig @ 2018-05-14 12:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180514094640.27569-18-mark.rutland@arm.com>
> +COMPAT_SYSCALL_DEFINE3(aarch32_statfs64, const char __user *, pathname,
> + compat_size_t, sz, struct compat_statfs64 __user *, buf)
> +{
> + if (sz == 88)
> + sz = 84;
> +
> + return kcompat_sys_statfs64(pathname, sz, buf);
This really needs a comment, and it looks very obviously bogus.
In case it isn't it needs a very good explanation.
^ permalink raw reply
* Delivery Status Notification (Failure)
From: Pintu Kumar @ 2018-05-14 12:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOuPNLgRHCasmsXTVwcy5ohq8TYjbr4MThxm4Q-HFWihJ7ARww@mail.gmail.com>
Hi,
Is there any work around possible to set IRQ affinity for some GPIO interrupt ?
How to avoid CPU0 to receive the current GPIO interrupt ?
How do we assign GPIO interrupts to any CPU other than CPU0 ?
Is it possible to isolate CPU0 for a sometime, from my GPIO driver so
that GPIO interrupt can be served by another CPU ?
Need your inputs to decide whether it is still possible to set
affinity for GPIO interrupt, or its impossible ?
Thanks,
Pintu
On Fri, May 11, 2018 at 8:07 PM, Pintu Kumar <pintu.ping@gmail.com> wrote:
> On Fri, May 11, 2018 at 6:34 PM, Lucas Stach <l.stach@pengutronix.de> wrote:
>> Am Freitag, den 11.05.2018, 13:39 +0100 schrieb Russell King - ARM Linux:
>>> On Fri, May 11, 2018 at 05:07:37PM +0530, Pintu Kumar wrote:
>>> > Hi,
>>> >
>>> > I need one help.
>>> > I am using i.MX7 Sabre board with kernel version 4.1.15
>>> >
>>> > Let's say I am interested in GPIO number: 21
>>> > I wanted to set CPU affinity for particular GPIO->IRQ number, so I
>>> > tried the below steps:
>>> > root at 10:~# echo 21 > /sys/class/gpio/export
>>> > root at 10:~# echo "rising" > /sys/class/gpio/gpio21/edge
>>> > root at 10:~# cat /proc/interrupts | grep 21
>>> > 47: 0 0 gpio-mxc 21 Edge gpiolib
>>> > root at 10:~# cat /sys/class/gpio/gpio21/direction
>>> > in
>>> > root at 10:~# cat /proc/irq/47/smp_affinity
>>> > 3
>>> > root at 10:~# echo 2 > /proc/irq/47/smp_affinity
>>> > -bash: echo: write error: Input/output error
>>> >
>>> > But I get input/output error.
>>> > When I debug further, found that irq_can_set_affinity is returning 0:
>>> > [ 0.000000] genirq: irq_can_set_affinity (0): balance: 1,
>>> > irq_data.chip: a81b7e48, irq_set_affinity: (null)
>>> > [ 0.000000] write_irq_affinity: FAIL
>>> >
>>> > I also tried first setting /proc/irq/default_smp_affinity to 2 (from 3).
>>> > This change is working, but the smp_affinity setting for the new IRQ
>>> > is not working.
>>> >
>>> > When I try to set smp_affinity for mmc0, then it works.
>>> > # cat /proc/interrupts | grep mmc
>>> > 295: 55 0 GPCV2 22 Edge mmc0
>>> > 296: 0 0 GPCV2 23 Edge mmc1
>>> > 297: 52 0 GPCV2 24 Edge mmc2
>>> >
>>> > root at 10:~# echo 2 > /proc/irq/295/smp_affinity
>>> > root at 10:~#
>>> >
>>> >
>>> > So, I wanted to know what are the conditions for which setting
>>> > smp_affinity for an IRQ will work ?
>>> >
>>> > Is there any way by which I can set CPU affinity to a GPIO -> IRQ ?
>>> > Whether, irq_set_affinity_hint() will work in this case ?
>>>
>>> IRQ affinity is only supported where interrupts are _directly_ wired to
>>> the GIC. It's the GIC which does the interrupt steering to the CPU
>>> cores.
>>>
>>> Interrupts on downstream interrupt controllers (such as GPCV2) have no
>>> ability to be directed independently to other CPUs - the only possible
>>> way to change the mapping is to move _all_ interrupts on that controller,
>>> and any downstream chained interrupts at GIC level.
>>>
>>> Hence why Interrupt 295 has no irq_set_affinity function: there is no way
>>> for the interrupt controller itself to change the affinity of the input
>>> interrupt.
>>
>> The GPCv2 though is a secondary IRQ controller which has a 1:1 mapping
>> of its input IRQs to the upstream GIC IRQ lines. Affinity can thus be
>> handled by forwarding the request to the GIC by
>> irq_chip_set_affinity_parent().
>>
>> As this is handled correctly in the upstream kernel since the first
>> commit introducing support for the GPCv2, it seems the issue is only
>> present in some downstream kernel.
>>
>
> OK. Thanks so much for your reply.
>
> I saw some of the drivers using irq_set_affinity_hint() to force the
> IRQ affinity to a particular CPU.
> This is the sample:
> {
> cpumask_clear(mask);
> cpumask_set_cpu(cpu, mask);
> irq_set_affinity_hint(irq, mask);
> }
>
> Whether this logic will work for a particular GPIO pin ?
>
>
>> Regards,
>> Lucas
^ permalink raw reply
* [FAIL bisect] Sound card probe error
From: Sylwester Nawrocki @ 2018-05-14 12:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAJKOXPfD8gZR8nZkmAr=Ldt3xESuFocQLnMtrDsNZu=ba55jcw@mail.gmail.com>
Hi,
On 05/14/2018 12:17 PM, Krzysztof Kozlowski wrote:
> Bisected to:
> 8c123c14bbba4add148536b6d47a9226deda2f7a is the first bad commit
> commit 8c123c14bbba4add148536b6d47a9226deda2f7a
> Author: Ulf Hansson <ulf.hansson@linaro.org>
> Date: Thu Apr 26 10:53:06 2018 +0200
>
> driver core: Respect all error codes from dev_pm_domain_attach()
>
> The limitation of being able to check only for -EPROBE_DEFER from
> dev_pm_domain_attach() has been removed. Hence let's respect all error
> codes and bail out accordingly.
>
> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
The DRM driver creates the HDMI codec but its registration fails, due
to some missing clocks. The clock are missing because the exynos5-subcmu
driver probing fails.
[ 0.678578] exynos5-subcmu: probe of GSC failed with error -17
[ 0.679250] exynos5-subcmu: probe of MFC failed with error -17
[ 0.679992] exynos5-subcmu: probe of DISP failed with error -17
The exynos5-subcmu driver before registering platform device makes
of_genpd_add_device() call, so in platform_drv_probe() dev_pm_domain_attach()
call will fail, as dev->pm_domain is already set. Previously the error
was masked by code removed in the above commit and platform_drv_probe()
was could complete successfully.
--
Regards,
Sylwester
^ permalink raw reply
* [GIT PULL 0/5] perf/urgent fixes
From: Arnaldo Carvalho de Melo @ 2018-05-14 12:23 UTC (permalink / raw)
To: linux-arm-kernel
Hi Ingo,
Please consider pulling,
- Arnaldo
Test results at the end of this message, as usual.
The following changes since commit 49cf4a4b3f5a8b02556dd4f45c5cee598d4fc799:
Merge tag 'perf-urgent-for-mingo-4.17-20180507' of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/urgent (2018-05-10 20:09:00 +0200)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git tags/perf-urgent-for-mingo-4.17-20180514
for you to fetch changes up to c23080a6e4e853cff2834436e3cf33eae7723900:
perf tools: Add missing newline when parsing empty BPF proggie (2018-05-11 12:10:02 -0300)
----------------------------------------------------------------
perf/urgent fixes:
- Fix segfault when processing unknown threads in cs-etm (Leo Yan)
- Fix "perf test inet_pton" on s390 failing due to missing inline (Thomas Richter)
- Display all available events on 'perf annotate --stdio' (Jin Yao)
- Add missing newline when parsing empty BPF proggie (Arnaldo Carvalho de Melo)
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
----------------------------------------------------------------
Arnaldo Carvalho de Melo (1):
perf tools: Add missing newline when parsing empty BPF proggie
Jin Yao (1):
perf annotate: Display all available events on --stdio
Leo Yan (2):
perf cs-etm: Support unknown_thread in cs_etm_auxtrace
perf cs-etm: Remove redundant space
Thomas Richter (1):
perf test: "probe libc's inet_pton" fails on s390 due to missing inline
.../tests/shell/record+probe_libc_inet_pton.sh | 2 +-
tools/perf/util/annotate.c | 3 +++
tools/perf/util/cs-etm.c | 28 ++++++++++++++++++----
tools/perf/util/parse-events.c | 2 +-
4 files changed, 29 insertions(+), 6 deletions(-)
Test results:
The first ones are container (docker) based builds of tools/perf with
and without libelf support. Where clang is available, it is also used
to build perf with/without libelf, and building with LIBCLANGLLVM=1
(built-in clang) with gcc and clang when clang and its devel libraries
are installed.
The objtool and samples/bpf/ builds are disabled now that I'm switching from
using the sources in a local volume to fetching them from a http server to
build it inside the container, to make it easier to build in a container cluster.
Those will come back later.
Several are cross builds, the ones with -x-ARCH and the android one, and those
may not have all the features built, due to lack of multi-arch devel packages,
available and being used so far on just a few, like
debian:experimental-x-{arm64,mipsel}.
The 'perf test' one will perform a variety of tests exercising
tools/perf/util/, tools/lib/{bpf,traceevent,etc}, as well as run perf commands
with a variety of command line event specifications to then intercept the
sys_perf_event syscall to check that the perf_event_attr fields are set up as
expected, among a variety of other unit tests.
Then there is the 'make -C tools/perf build-test' ones, that build tools/perf/
with a variety of feature sets, exercising the build with an incomplete set of
features as well as with a complete one. It is planned to have it run on each
of the containers mentioned above, using some container orchestration
infrastructure. Get in contact if interested in helping having this in place.
# dm
1 alpine:3.4 : Ok gcc (Alpine 5.3.0) 5.3.0
2 alpine:3.5 : Ok gcc (Alpine 6.2.1) 6.2.1 20160822
3 alpine:3.6 : Ok gcc (Alpine 6.3.0) 6.3.0
4 alpine:3.7 : Ok gcc (Alpine 6.4.0) 6.4.0
5 alpine:edge : Ok gcc (Alpine 6.4.0) 6.4.0
6 amazonlinux:1 : Ok gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-11)
7 amazonlinux:2 : Ok gcc (GCC) 7.3.1 20180303 (Red Hat 7.3.1-5)
8 android-ndk:r12b-arm : Ok arm-linux-androideabi-gcc (GCC) 4.9.x 20150123 (prerelease)
9 android-ndk:r15c-arm : Ok arm-linux-androideabi-gcc (GCC) 4.9.x 20150123 (prerelease)
10 centos:5 : Ok gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-55)
11 centos:6 : Ok gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-18)
12 centos:7 : Ok gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-16)
13 debian:7 : Ok gcc (Debian 4.7.2-5) 4.7.2
14 debian:8 : Ok gcc (Debian 4.9.2-10+deb8u1) 4.9.2
15 debian:9 : Ok gcc (Debian 6.3.0-18+deb9u1) 6.3.0 20170516
16 debian:experimental : Ok gcc (Debian 7.3.0-15) 7.3.0
17 debian:experimental-x-arm64 : Ok aarch64-linux-gnu-gcc (Debian 7.3.0-15) 7.3.0
18 debian:experimental-x-mips : Ok mips-linux-gnu-gcc (Debian 7.3.0-12) 7.3.0
19 debian:experimental-x-mips64 : Ok mips64-linux-gnuabi64-gcc (Debian 7.3.0-12) 7.3.0
20 debian:experimental-x-mipsel : Ok mipsel-linux-gnu-gcc (Debian 7.3.0-12) 7.3.0
21 fedora:20 : Ok gcc (GCC) 4.8.3 20140911 (Red Hat 4.8.3-7)
22 fedora:21 : Ok gcc (GCC) 4.9.2 20150212 (Red Hat 4.9.2-6)
23 fedora:22 : Ok gcc (GCC) 5.3.1 20160406 (Red Hat 5.3.1-6)
24 fedora:23 : Ok gcc (GCC) 5.3.1 20160406 (Red Hat 5.3.1-6)
25 fedora:24 : Ok gcc (GCC) 6.3.1 20161221 (Red Hat 6.3.1-1)
26 fedora:24-x-ARC-uClibc : Ok arc-linux-gcc (ARCompact ISA Linux uClibc toolchain 2017.09-rc2) 7.1.1 20170710
27 fedora:25 : Ok gcc (GCC) 6.4.1 20170727 (Red Hat 6.4.1-1)
28 fedora:26 : Ok gcc (GCC) 7.3.1 20180130 (Red Hat 7.3.1-2)
29 fedora:27 : Ok gcc (GCC) 7.3.1 20180303 (Red Hat 7.3.1-5)
30 fedora:28 : Ok gcc (GCC) 8.0.1 20180324 (Red Hat 8.0.1-0.20)
31 fedora:rawhide : Ok gcc (GCC) 8.0.1 20180324 (Red Hat 8.0.1-0.20)
32 gentoo-stage3-amd64:latest : Ok gcc (Gentoo 6.4.0-r1 p1.3) 6.4.0
33 mageia:5 : Ok gcc (GCC) 4.9.2
34 mageia:6 : Ok gcc (Mageia 5.5.0-1.mga6) 5.5.0
35 opensuse:42.1 : Ok gcc (SUSE Linux) 4.8.5
36 opensuse:42.2 : Ok gcc (SUSE Linux) 4.8.5
37 opensuse:42.3 : Ok gcc (SUSE Linux) 4.8.5
38 opensuse:tumbleweed : Ok gcc (SUSE Linux) 7.3.1 20180323 [gcc-7-branch revision 258812]
39 oraclelinux:6 : Ok gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-18)
40 oraclelinux:7 : Ok gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-28.0.1)
41 ubuntu:12.04.5 : Ok gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3
42 ubuntu:14.04.4 : Ok gcc (Ubuntu 4.8.4-2ubuntu1~14.04.3) 4.8.4
43 ubuntu:14.04.4-x-linaro-arm64 : Ok aarch64-linux-gnu-gcc (Linaro GCC 5.4-2017.05) 5.4.1 20170404
44 ubuntu:15.04 : Ok gcc (Ubuntu 4.9.2-10ubuntu13) 4.9.2
45 ubuntu:16.04 : Ok gcc (Ubuntu 5.4.0-6ubuntu1~16.04.9) 5.4.0 20160609
46 ubuntu:16.04-x-arm : Ok arm-linux-gnueabihf-gcc (Ubuntu/Linaro 5.4.0-6ubuntu1~16.04.9) 5.4.0 20160609
47 ubuntu:16.04-x-arm64 : Ok aarch64-linux-gnu-gcc (Ubuntu/Linaro 5.4.0-6ubuntu1~16.04.9) 5.4.0 20160609
48 ubuntu:16.04-x-powerpc : Ok powerpc-linux-gnu-gcc (Ubuntu 5.4.0-6ubuntu1~16.04.9) 5.4.0 20160609
49 ubuntu:16.04-x-powerpc64 : Ok powerpc64-linux-gnu-gcc (Ubuntu/IBM 5.4.0-6ubuntu1~16.04.9) 5.4.0 20160609
50 ubuntu:16.04-x-powerpc64el : Ok powerpc64le-linux-gnu-gcc (Ubuntu/IBM 5.4.0-6ubuntu1~16.04.9) 5.4.0 20160609
51 ubuntu:16.04-x-s390 : Ok s390x-linux-gnu-gcc (Ubuntu 5.4.0-6ubuntu1~16.04.9) 5.4.0 20160609
52 ubuntu:16.10 : Ok gcc (Ubuntu 6.2.0-5ubuntu12) 6.2.0 20161005
53 ubuntu:17.04 : Ok gcc (Ubuntu 6.3.0-12ubuntu2) 6.3.0 20170406
54 ubuntu:17.10 : Ok gcc (Ubuntu 7.2.0-8ubuntu3.2) 7.2.0
55 ubuntu:18.04 : Ok gcc (Ubuntu 7.3.0-16ubuntu3) 7.3.0
# uname -a
Linux jouet 4.17.0-rc3-00034-gf4ef6a438cee #18 SMP Thu May 3 11:49:35 -03 2018 x86_64 x86_64 x86_64 GNU/Linux
# perf test
1: vmlinux symtab matches kallsyms : Ok
2: Detect openat syscall event : Ok
3: Detect openat syscall event on all cpus : Ok
4: Read samples using the mmap interface : Ok
5: Test data source output : Ok
6: Parse event definition strings : Ok
7: Simple expression parser : Ok
8: PERF_RECORD_* events & perf_sample fields : Ok
9: Parse perf pmu format : Ok
10: DSO data read : Ok
11: DSO data cache : Ok
12: DSO data reopen : Ok
13: Roundtrip evsel->name : Ok
14: Parse sched tracepoints fields : Ok
15: syscalls:sys_enter_openat event fields : Ok
16: Setup struct perf_event_attr : Ok
17: Match and link multiple hists : Ok
18: 'import perf' in python : Ok
19: Breakpoint overflow signal handler : Ok
20: Breakpoint overflow sampling : Ok
21: Breakpoint accounting : Ok
22: Number of exit events of a simple workload : Ok
23: Software clock events period values : Ok
24: Object code reading : Ok
25: Sample parsing : Ok
26: Use a dummy software event to keep tracking : Ok
27: Parse with no sample_id_all bit set : Ok
28: Filter hist entries : Ok
29: Lookup mmap thread : Ok
30: Share thread mg : Ok
31: Sort output of hist entries : Ok
32: Cumulate child hist entries : Ok
33: Track with sched_switch : Ok
34: Filter fds with revents mask in a fdarray : Ok
35: Add fd to a fdarray, making it autogrow : Ok
36: kmod_path__parse : Ok
37: Thread map : Ok
38: LLVM search and compile :
38.1: Basic BPF llvm compile : Ok
38.2: kbuild searching : Ok
38.3: Compile source for BPF prologue generation : Ok
38.4: Compile source for BPF relocation : Ok
39: Session topology : Ok
40: BPF filter :
40.1: Basic BPF filtering : Ok
40.2: BPF pinning : Ok
40.3: BPF prologue generation : Ok
40.4: BPF relocation checker : Ok
41: Synthesize thread map : Ok
42: Remove thread map : Ok
43: Synthesize cpu map : Ok
44: Synthesize stat config : Ok
45: Synthesize stat : Ok
46: Synthesize stat round : Ok
47: Synthesize attr update : Ok
48: Event times : Ok
49: Read backward ring buffer : Ok
50: Print cpu map : Ok
51: Probe SDT events : Ok
52: is_printable_array : Ok
53: Print bitmap : Ok
54: perf hooks : Ok
55: builtin clang support : Skip (not compiled in)
56: unit_number__scnprintf : Ok
57: mem2node : Ok
58: x86 rdpmc : Ok
59: Convert perf time to TSC : Ok
60: DWARF unwind : Ok
61: x86 instruction decoder - new instructions : Ok
62: Use vfs_getname probe to get syscall args filenames : Ok
63: Check open filename arg using perf trace + vfs_getname: Ok
64: probe libc's inet_pton & backtrace it with ping : Ok
65: Add vfs_getname probe to get syscall args filenames : Ok
#
$ make -C tools/perf build-test
make: Entering directory '/home/acme/git/perf/tools/perf'
- tarpkg: ./tests/perf-targz-src-pkg .
make_no_libdw_dwarf_unwind_O: make NO_LIBDW_DWARF_UNWIND=1
make_with_clangllvm_O: make LIBCLANGLLVM=1
make_util_pmu_bison_o_O: make util/pmu-bison.o
make_no_libperl_O: make NO_LIBPERL=1
make_tags_O: make tags
make_no_gtk2_O: make NO_GTK2=1
make_no_libelf_O: make NO_LIBELF=1
make_install_prefix_O: make install prefix=/tmp/krava
make_no_libunwind_O: make NO_LIBUNWIND=1
make_clean_all_O: make clean all
make_no_ui_O: make NO_NEWT=1 NO_SLANG=1 NO_GTK2=1
make_no_libbionic_O: make NO_LIBBIONIC=1
make_with_babeltrace_O: make LIBBABELTRACE=1
make_doc_O: make doc
make_no_libaudit_O: make NO_LIBAUDIT=1
make_no_backtrace_O: make NO_BACKTRACE=1
make_help_O: make help
make_no_auxtrace_O: make NO_AUXTRACE=1
make_no_libbpf_O: make NO_LIBBPF=1
make_no_libnuma_O: make NO_LIBNUMA=1
make_static_O: make LDFLAGS=-static
make_no_libpython_O: make NO_LIBPYTHON=1
make_pure_O: make
make_no_scripts_O: make NO_LIBPYTHON=1 NO_LIBPERL=1
make_perf_o_O: make perf.o
make_no_demangle_O: make NO_DEMANGLE=1
make_install_prefix_slash_O: make install prefix=/tmp/krava/
make_install_bin_O: make install-bin
make_util_map_o_O: make util/map.o
make_no_newt_O: make NO_NEWT=1
make_debug_O: make DEBUG=1
make_minimal_O: make NO_LIBPERL=1 NO_LIBPYTHON=1 NO_NEWT=1 NO_GTK2=1 NO_DEMANGLE=1 NO_LIBELF=1 NO_LIBUNWIND=1 NO_BACKTRACE=1 NO_LIBNUMA=1 NO_LIBAUDIT=1 NO_LIBBIONIC=1 NO_LIBDW_DWARF_UNWIND=1 NO_AUXTRACE=1 NO_LIBBPF=1 NO_LIBCRYPTO=1 NO_SDT=1 NO_JVMTI=1
make_install_O: make install
make_no_slang_O: make NO_SLANG=1
OK
make: Leaving directory '/home/acme/git/perf/tools/perf'
$
^ permalink raw reply
* [PATCH 3/5] perf cs-etm: Support unknown_thread in cs_etm_auxtrace
From: Arnaldo Carvalho de Melo @ 2018-05-14 12:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180514122321.27304-1-acme@kernel.org>
From: Leo Yan <leo.yan@linaro.org>
CoreSight doesn't allocate thread structure for unknown_thread in ETM
auxtrace, so unknown_thread is NULL pointer. If the perf data doesn't
contain valid tid and then cs_etm__mem_access() uses unknown_thread
instead as thread handler, this results in a segmentation fault when
thread__find_addr_map() accesses the thread handler.
This commit creates a new thread data which is used by unknown_thread, so
CoreSight tracing can roll back to use unknown_thread if perf data
doesn't include valid thread info. This commit also releases thread
data for initialization failure case and for normal auxtrace free flow.
Signed-off-by: Leo Yan <leo.yan@linaro.org>
Acked-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: linux-arm-kernel at lists.infradead.org
Link: http://lkml.kernel.org/r/1525924920-4381-1-git-send-email-leo.yan at linaro.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
---
tools/perf/util/cs-etm.c | 24 ++++++++++++++++++++++--
1 file changed, 22 insertions(+), 2 deletions(-)
diff --git a/tools/perf/util/cs-etm.c b/tools/perf/util/cs-etm.c
index 40020b1ca54f..2bf28b5acc08 100644
--- a/tools/perf/util/cs-etm.c
+++ b/tools/perf/util/cs-etm.c
@@ -239,6 +239,7 @@ static void cs_etm__free(struct perf_session *session)
for (i = 0; i < aux->num_cpu; i++)
zfree(&aux->metadata[i]);
+ thread__zput(aux->unknown_thread);
zfree(&aux->metadata);
zfree(&aux);
}
@@ -1357,6 +1358,23 @@ int cs_etm__process_auxtrace_info(union perf_event *event,
etm->auxtrace.free = cs_etm__free;
session->auxtrace = &etm->auxtrace;
+ etm->unknown_thread = thread__new(999999999, 999999999);
+ if (!etm->unknown_thread)
+ goto err_free_queues;
+
+ /*
+ * Initialize list node so that at thread__zput() we can avoid
+ * segmentation fault at list_del_init().
+ */
+ INIT_LIST_HEAD(&etm->unknown_thread->node);
+
+ err = thread__set_comm(etm->unknown_thread, "unknown", 0);
+ if (err)
+ goto err_delete_thread;
+
+ if (thread__init_map_groups(etm->unknown_thread, etm->machine))
+ goto err_delete_thread;
+
if (dump_trace) {
cs_etm__print_auxtrace_info(auxtrace_info->priv, num_cpu);
return 0;
@@ -1371,16 +1389,18 @@ int cs_etm__process_auxtrace_info(union perf_event *event,
err = cs_etm__synth_events(etm, session);
if (err)
- goto err_free_queues;
+ goto err_delete_thread;
err = auxtrace_queues__process_index(&etm->queues, session);
if (err)
- goto err_free_queues;
+ goto err_delete_thread;
etm->data_queued = etm->queues.populated;
return 0;
+err_delete_thread:
+ thread__zput(etm->unknown_thread);
err_free_queues:
auxtrace_queues__free(&etm->queues);
session->auxtrace = NULL;
--
2.14.3
^ permalink raw reply related
* [PATCH 4/5] perf cs-etm: Remove redundant space
From: Arnaldo Carvalho de Melo @ 2018-05-14 12:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180514122321.27304-1-acme@kernel.org>
From: Leo Yan <leo.yan@linaro.org>
There have two spaces ahead function name cs_etm__set_pid_tid_cpu(), so
remove one space and correct indentation.
Signed-off-by: Leo Yan <leo.yan@linaro.org>
Acked-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: linux-arm-kernel at lists.infradead.org
Link: http://lkml.kernel.org/r/1525924920-4381-2-git-send-email-leo.yan at linaro.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
---
tools/perf/util/cs-etm.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/perf/util/cs-etm.c b/tools/perf/util/cs-etm.c
index 2bf28b5acc08..bf16dc9ee507 100644
--- a/tools/perf/util/cs-etm.c
+++ b/tools/perf/util/cs-etm.c
@@ -613,8 +613,8 @@ cs_etm__get_trace(struct cs_etm_buffer *buff, struct cs_etm_queue *etmq)
return buff->len;
}
-static void cs_etm__set_pid_tid_cpu(struct cs_etm_auxtrace *etm,
- struct auxtrace_queue *queue)
+static void cs_etm__set_pid_tid_cpu(struct cs_etm_auxtrace *etm,
+ struct auxtrace_queue *queue)
{
struct cs_etm_queue *etmq = queue->priv;
--
2.14.3
^ permalink raw reply related
* [FAIL bisect] Sound card probe error
From: Krzysztof Kozlowski @ 2018-05-14 12:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <b193b8a0-ad25-1895-8f8d-ffab97261dc1@samsung.com>
On Mon, May 14, 2018 at 2:22 PM, Sylwester Nawrocki
<s.nawrocki@samsung.com> wrote:
> Hi,
>
> On 05/14/2018 12:17 PM, Krzysztof Kozlowski wrote:
>
>> Bisected to:
>> 8c123c14bbba4add148536b6d47a9226deda2f7a is the first bad commit
>> commit 8c123c14bbba4add148536b6d47a9226deda2f7a
>> Author: Ulf Hansson <ulf.hansson@linaro.org>
>> Date: Thu Apr 26 10:53:06 2018 +0200
>>
>> driver core: Respect all error codes from dev_pm_domain_attach()
>>
>> The limitation of being able to check only for -EPROBE_DEFER from
>> dev_pm_domain_attach() has been removed. Hence let's respect all error
>> codes and bail out accordingly.
>>
>> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
>> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
>
> The DRM driver creates the HDMI codec but its registration fails, due
> to some missing clocks. The clock are missing because the exynos5-subcmu
> driver probing fails.
>
> [ 0.678578] exynos5-subcmu: probe of GSC failed with error -17
> [ 0.679250] exynos5-subcmu: probe of MFC failed with error -17
> [ 0.679992] exynos5-subcmu: probe of DISP failed with error -17
>
> The exynos5-subcmu driver before registering platform device makes
> of_genpd_add_device() call, so in platform_drv_probe() dev_pm_domain_attach()
> call will fail, as dev->pm_domain is already set. Previously the error
> was masked by code removed in the above commit and platform_drv_probe()
> was could complete successfully.
Thanks Sylwester!
Ah, I missed these messages because I was looking at err dmesg level
(and for some reason these are warn). Anyway do you have any thoughts
how is it connected with missing Odroid XU3 sound card and max98090
codec?
Best regards,
Krzysztof
^ permalink raw reply
* [FAIL bisect] Sound card probe error
From: Ulf Hansson @ 2018-05-14 12:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <b193b8a0-ad25-1895-8f8d-ffab97261dc1@samsung.com>
On 14 May 2018 at 14:22, Sylwester Nawrocki <s.nawrocki@samsung.com> wrote:
> Hi,
>
> On 05/14/2018 12:17 PM, Krzysztof Kozlowski wrote:
>
>> Bisected to:
>> 8c123c14bbba4add148536b6d47a9226deda2f7a is the first bad commit
>> commit 8c123c14bbba4add148536b6d47a9226deda2f7a
>> Author: Ulf Hansson <ulf.hansson@linaro.org>
>> Date: Thu Apr 26 10:53:06 2018 +0200
>>
>> driver core: Respect all error codes from dev_pm_domain_attach()
>>
>> The limitation of being able to check only for -EPROBE_DEFER from
>> dev_pm_domain_attach() has been removed. Hence let's respect all error
>> codes and bail out accordingly.
>>
>> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
>> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
>
> The DRM driver creates the HDMI codec but its registration fails, due
> to some missing clocks. The clock are missing because the exynos5-subcmu
> driver probing fails.
>
> [ 0.678578] exynos5-subcmu: probe of GSC failed with error -17
> [ 0.679250] exynos5-subcmu: probe of MFC failed with error -17
> [ 0.679992] exynos5-subcmu: probe of DISP failed with error -17
>
> The exynos5-subcmu driver before registering platform device makes
> of_genpd_add_device() call, so in platform_drv_probe() dev_pm_domain_attach()
> call will fail, as dev->pm_domain is already set. Previously the error
> was masked by code removed in the above commit and platform_drv_probe()
> was could complete successfully.
Thanks for providing this information!
I was about to tell that I overlooked the fact that there is more than
one way to assign PM domain pointers to devices. To fix the problem,
dev_pm_domain_attach() should return 0, not -EEXIST when it finds and
existing PM domain pointer.
Does the below patch fix the problem?
From: Ulf Hansson <ulf.hansson@linaro.org>
Date: Mon, 14 May 2018 14:26:16 +0200
Subject: [PATCH] PM / Domains: Don't return -EEXIST at attach when PM domain
exists
As dev_pm_domain_attach() isn't the only way to assign PM domain pointers
to devices, clearly we must allow a device to have the pointer already
being assigned. For this reason, return 0 instead of -EEXIST.
Reported-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
---
drivers/base/power/common.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/base/power/common.c b/drivers/base/power/common.c
index 5e4b481..390868c 100644
--- a/drivers/base/power/common.c
+++ b/drivers/base/power/common.c
@@ -106,7 +106,7 @@ int dev_pm_domain_attach(struct device *dev, bool power_on)
int ret;
if (dev->pm_domain)
- return -EEXIST;
+ return 0;
ret = acpi_dev_pm_attach(dev, power_on);
if (!ret)
--
2.7.4
^ permalink raw reply related
* [PATCH V3] ARM: dts: da850-evm: Enable LCD and Backlight
From: Sekhar Nori @ 2018-05-14 12:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAHCN7xJgTBGHL_VzhXGz1HEmEn-LW8pcG0BWJDysx0pkHXT-Mg@mail.gmail.com>
On Monday 14 May 2018 04:22 PM, Adam Ford wrote:
> On Mon, May 14, 2018 at 12:29 AM, Sekhar Nori <nsekhar@ti.com> wrote:
>> Hi Adam,
>>
>> On Monday 14 May 2018 04:50 AM, Adam Ford wrote:
>>> When using the board files the LCD works, but not with the DT.
>>> This adds enables the original da850-evm to work with the same
>>> LCD in device tree mode.
>>>
>>> The EVM has a gpio for the regulator and a gpio enable. The LCD and
>>> the vpif display pins are mutually exclusive, so if using the LCD,
>>> do not load the vpif driver.
>>
>> Its not sufficient just note this in patch description.
>>
>> a) Disable (status = "disabled") the VPIF node which clashes for pins
>> with LCD.
>> b) Add a comment on top of the status = "disabled" giving information on
>> how user can enable it (disable lcdc node and then change to status =
>> "okay").
>>
>>>
>>> Signed-off-by: Adam Ford <aford173@gmail.com>
>>> ---
>>> V3: Fix errant GPIO, label GPIO pins, and rename the regulator to be more explict to
>>> backlight which better matches the schematic. Updated the description to explain
>>> that it cannot be used at the same time as the vpif driver.
>>>
>>> V2: Add regulator and GPIO enable pins. Remove PWM backlight and replace with GPIO
>>>
>>> diff --git a/arch/arm/boot/dts/da850-evm.dts b/arch/arm/boot/dts/da850-evm.dts
>>> index 2e817da37fdb..3f1c8be07efe 100644
>>> --- a/arch/arm/boot/dts/da850-evm.dts
>>> +++ b/arch/arm/boot/dts/da850-evm.dts
>>> @@ -27,6 +27,50 @@
>>> spi0 = &spi1;
>>> };
>>>
>>> + backlight {
>>> + compatible = "gpio-backlight";
>>> + enable-gpios = <&gpio 7 GPIO_ACTIVE_HIGH>; /* GP0[7] */
>>
>> The gpio-backlight binding does not describe a property called
>> enable-gpios. It should just be gpios.
>
> I will fix that.
>
>>
>> a) Are you using gpio-backlight because you are not able to get the PWM
>> to work?
>>
> Yes, You told me not to worry about doing a PWM backlight because the
> legacy board does not PWM either.
Yeah, I meant not to add backlight control till the time we are able to
get it working using PWM. Is this needed for the basic LCD functionality
to work? I would like to avoid the churn of adding it using GPIO now and
changing to PWM later, if possible.
>
>> b) What is GP0[7] connected to in the schematic you have? In the
>> schematic I have I see LCD_PWM0 is connected to
>> SPI1_SCS[0]/EPWM1B/GP2[14]/TM64P3_IN12.
>
> I have schematic 1016572 dated Wednesday, August 18, 2010. According
> to it, AXR15 / EPWMN0_TZ[0] / ECAP2_APWM2 / GPIO0[7] connects to U25,
> Pin 46 to generate M_LCD_PWM0. You might have one of the early,
> pre-release versions.
Ah, okay. In your schematic, is GP2[14] connected to anything?
>
>>
>> c) The /* GP0[7] */ comment is not really useful on its own as it can be
>> computed. What I wanted to see is the schematic symbol like "LCD_PWM0".
>> Same for other places like this below.
>
> I can do that.
>>
>>> @@ -35,6 +79,16 @@
>>> regulator-boot-on;
>>> };
>>>
>>> + backlight_reg: backlight-regulator {
>>> + compatible = "regulator-fixed";
>>> + regulator-name = "lcd_backlight_pwr";
>>> + regulator-min-microvolt = <3300000>;
>>> + regulator-max-microvolt = <3300000>;
>>> + gpio = <&gpio 47 GPIO_ACTIVE_HIGH>; /* GP2[15] */
>>> + regulator-always-on;
>>
>> Why should this regulator never be disabled?
>
> The gpio-backlight does not have a way that I can see to associate the
> regulator to it. I read through the bindings, but I didn't see an
> option to associate a regulator it. I use this regulator to drive
> lcd_backlight_pwr and the backlight driver to write lcd_pwm0. Without
> this option, the system disables lcd_backlight_pwr and the screen is
> blank
It sounds like this is a hack to enable backlight on this board. I think
either the backlight driver needs to gain functionality to enable the
GPIO. Or backlight could be treated as part of the panel and enabled
using enable-gpios property in the panel. TBH, I will be okay either
way. Can you check with Jyri, Tomi and rest of the DRM folks on what
should be right way of dealing with this?
Thanks,
Sekhar
^ permalink raw reply
* [FAIL bisect] Sound card probe error
From: Marek Szyprowski @ 2018-05-14 12:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAJKOXPc+kLA+BPBmaP14zMLbbxxCmWF1eZnKoa_PcO2z9jG9JQ@mail.gmail.com>
Hi Krzysztof,
On 2018-05-14 14:29, Krzysztof Kozlowski wrote:
> On Mon, May 14, 2018 at 2:22 PM, Sylwester Nawrocki
> <s.nawrocki@samsung.com> wrote:
>> Hi,
>>
>> On 05/14/2018 12:17 PM, Krzysztof Kozlowski wrote:
>>
>>> Bisected to:
>>> 8c123c14bbba4add148536b6d47a9226deda2f7a is the first bad commit
>>> commit 8c123c14bbba4add148536b6d47a9226deda2f7a
>>> Author: Ulf Hansson <ulf.hansson@linaro.org>
>>> Date: Thu Apr 26 10:53:06 2018 +0200
>>>
>>> driver core: Respect all error codes from dev_pm_domain_attach()
>>>
>>> The limitation of being able to check only for -EPROBE_DEFER from
>>> dev_pm_domain_attach() has been removed. Hence let's respect all error
>>> codes and bail out accordingly.
>>>
>>> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
>>> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>>> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
>> The DRM driver creates the HDMI codec but its registration fails, due
>> to some missing clocks. The clock are missing because the exynos5-subcmu
>> driver probing fails.
>>
>> [ 0.678578] exynos5-subcmu: probe of GSC failed with error -17
>> [ 0.679250] exynos5-subcmu: probe of MFC failed with error -17
>> [ 0.679992] exynos5-subcmu: probe of DISP failed with error -17
>>
>> The exynos5-subcmu driver before registering platform device makes
>> of_genpd_add_device() call, so in platform_drv_probe() dev_pm_domain_attach()
>> call will fail, as dev->pm_domain is already set. Previously the error
>> was masked by code removed in the above commit and platform_drv_probe()
>> was could complete successfully.
> Thanks Sylwester!
>
> Ah, I missed these messages because I was looking at err dmesg level
> (and for some reason these are warn). Anyway do you have any thoughts
> how is it connected with missing Odroid XU3 sound card and max98090
> codec?
Odroid XU3 sound card driver is waiting for HDMI codec, which is being
created
by Exynos DRM HDMI driver, which was deferred by lack of clocks.
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
^ permalink raw reply
* [FAIL bisect] Sound card probe error
From: Sylwester Nawrocki @ 2018-05-14 12:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAJKOXPc+kLA+BPBmaP14zMLbbxxCmWF1eZnKoa_PcO2z9jG9JQ@mail.gmail.com>
On 05/14/2018 02:29 PM, Krzysztof Kozlowski wrote:
> Ah, I missed these messages because I was looking at err dmesg level
> (and for some reason these are warn). Anyway do you have any thoughts
> how is it connected with missing Odroid XU3 sound card and max98090
> codec?
One reason is that the DRM driver registers an ASoC codec object which
is required for the sound card registration to complete. But I wonder
why there is no any error messages related to this.
--
Regards,
Sylwester
^ permalink raw reply
* [PATCH 07/11] irqchip: stm32: add stm32mp1 support with hierarchy domain
From: Ludovic BARRE @ 2018-05-14 12:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAL_JsqLh4+vs-hQceg3bZ-ALWKE182vKbL90xxLwdgb09OtZ7Q@mail.gmail.com>
On 05/04/2018 10:38 PM, Rob Herring wrote:
> On Thu, May 3, 2018 at 4:55 AM, Ludovic BARRE <ludovic.barre@st.com> wrote:
>>
>>
>> On 05/02/2018 07:45 PM, Rob Herring wrote:
>>>
>>> On Wed, May 2, 2018 at 11:03 AM, Ludovic BARRE <ludovic.barre@st.com>
>>> wrote:
>>>>
>>>> Hi Rob
>>>>
>>>>
>>>>
>>>> On 05/01/2018 04:56 PM, Rob Herring wrote:
>>>>>
>>>>>
>>>>> On Thu, Apr 26, 2018 at 06:18:30PM +0200, Ludovic Barre wrote:
>>>>>>
>>>>>>
>>>>>> From: Ludovic Barre <ludovic.barre@st.com>
>>>>>>
>>>>>> Exti controller has been differently integrated on stm32mp1 SoC.
>>>>>> A parent irq has only one external interrupt. A hierachy domain could
>>>>>> be used. Handlers are call by parent, each parent interrupt could be
>>>>>> masked and unmasked according to the needs.
>>>>>>
>>>>>> Signed-off-by: Ludovic Barre <ludovic.barre@st.com>
>>>>>> ---
>>>>>> .../interrupt-controller/st,stm32-exti.txt | 3 +
>>>>>> drivers/irqchip/irq-stm32-exti.c | 322
>>>>>> +++++++++++++++++++++
>>>>>> 2 files changed, 325 insertions(+)
>>>>>>
>>>>>> diff --git
>>>>>>
>>>>>> a/Documentation/devicetree/bindings/interrupt-controller/st,stm32-exti.txt
>>>>>>
>>>>>> b/Documentation/devicetree/bindings/interrupt-controller/st,stm32-exti.txt
>>>>>> index edf03f0..136bd61 100644
>>>>>> ---
>>>>>>
>>>>>> a/Documentation/devicetree/bindings/interrupt-controller/st,stm32-exti.txt
>>>>>> +++
>>>>>>
>>>>>> b/Documentation/devicetree/bindings/interrupt-controller/st,stm32-exti.txt
>>>>>> @@ -5,11 +5,14 @@ Required properties:
>>>>>> - compatible: Should be:
>>>>>> "st,stm32-exti"
>>>>>> "st,stm32h7-exti"
>>>>>> + "st,stm32mp1-exti"
>>>>>> - reg: Specifies base physical address and size of the registers
>>>>>> - interrupt-controller: Indentifies the node as an interrupt
>>>>>> controller
>>>>>> - #interrupt-cells: Specifies the number of cells to encode an
>>>>>> interrupt
>>>>>> specifier, shall be 2
>>>>>> - interrupts: interrupts references to primary interrupt controller
>>>>>> + (only needed for exti controller with multiple exti under
>>>>>> + same parent interrupt: st,stm32-exti and st,stm32h7-exti")
>>>>>> Example:
>>>>>> diff --git a/drivers/irqchip/irq-stm32-exti.c
>>>>>> b/drivers/irqchip/irq-stm32-exti.c
>>>>>> index b38c655..ebf7146 100644
>>>>>> --- a/drivers/irqchip/irq-stm32-exti.c
>>>>>> +++ b/drivers/irqchip/irq-stm32-exti.c
>>>>>
>>>>>
>>>>>
>>>>> [...]
>>>>>
>>>>>> +static const struct stm32_desc_irq stm32mp1_desc_irq[] = {
>>>>>> + { .exti = 1, .irq_parent = 7 },
>>>>>> + { .exti = 2, .irq_parent = 8 },
>>>>>> + { .exti = 3, .irq_parent = 9 },
>>>>>> + { .exti = 4, .irq_parent = 10 },
>>>>>> + { .exti = 5, .irq_parent = 23 },
>>>>>> + { .exti = 6, .irq_parent = 64 },
>>>>>> + { .exti = 7, .irq_parent = 65 },
>>>>>> + { .exti = 8, .irq_parent = 66 },
>>>>>> + { .exti = 9, .irq_parent = 67 },
>>>>>> + { .exti = 10, .irq_parent = 40 },
>>>>>> + { .exti = 11, .irq_parent = 42 },
>>>>>> + { .exti = 12, .irq_parent = 76 },
>>>>>> + { .exti = 13, .irq_parent = 77 },
>>>>>> + { .exti = 14, .irq_parent = 121 },
>>>>>> + { .exti = 15, .irq_parent = 127 },
>>>>>> + { .exti = 16, .irq_parent = 1 },
>>>>>> + { .exti = 65, .irq_parent = 144 },
>>>>>> + { .exti = 68, .irq_parent = 143 },
>>>>>> + { .exti = 73, .irq_parent = 129 },
>>>>>> +};
>>>>>
>>>>>
>>>>>
>>>>> You can use an interrupt-map property rather than put this into the
>>>>> driver.
>>>>
>>>>
>>>>
>>>> interrupt-map seemed interesting and promising like used in pci host.
>>>> At first sight this property can't be used into node with
>>>> "interrupt-controller" property (see in drivers/of/irq.c function:
>>>> of_irq_parse_raw) because "of_irq_parse_raw" checks if node got
>>>> it first, and after lookup the interrupt-map.
>>>>
>>>> Rob, Thomas, Jason, Marc what do you prefers or the right ways...?
>>>
>>>
>>> I believe the correct thing to do is simply drop "interrupt-controller".
>>
>
> Actually, that's not right.
>
>> if I drop "interrupt-controller" of my node, my driver will not be
>> initialized by "of_irq_init"
>> (start_kernel->init_IRQ->irqchip_init->of_irq_init).
>> Probably, we could replace "IRQCHIP_DECLARE" by a
>> "module_platform_driver" or "postcore_initcall" but I'm not a big fan of
>> this solution. what do you think ?
>
> You'd have to parse 'interrupt-map' yourself to extract the data for
> this to work because interrupt-map currently only works when the
> translation is transparent (i.e. doesn't need s/w handling). So I
> guess leave this in the driver. Sorry for the noise.
>
Sorry, I don't know if I've correctly understand the answer.
I hesitate between:
- keep the code like this, with stm32mp1_desc_irq tab.
- parse interrupt-map property into stm32 exti driver.
Just to be sure, and avoid misunderstand.
BR
Ludo
> Rob
>
^ permalink raw reply
* [PATCH 02/18] arm64: move SCTLR_EL{1,2} assertions to <asm/sysreg.h>
From: Dave Martin @ 2018-05-14 12:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180514120609.3vd2s4l3rknd2b3e@lakrids.cambridge.arm.com>
On Mon, May 14, 2018 at 01:06:10PM +0100, Mark Rutland wrote:
> On Mon, May 14, 2018 at 12:56:09PM +0100, Robin Murphy wrote:
> > On 14/05/18 12:20, Dave Martin wrote:
> > > On Mon, May 14, 2018 at 11:08:59AM +0100, Mark Rutland wrote:
> > > > On Mon, May 14, 2018 at 11:00:53AM +0100, Dave Martin wrote:
> > > > > On Mon, May 14, 2018 at 10:46:24AM +0100, Mark Rutland wrote:
> > > > > > -/* Check all the bits are accounted for */
> > > > > > -#define SCTLR_EL2_BUILD_BUG_ON_MISSING_BITS BUILD_BUG_ON((SCTLR_EL2_SET ^ SCTLR_EL2_CLEAR) != ~0)
> > > > > > -
> > > > > > +#if (SCTLR_EL2_SET ^ SCTLR_EL2_CLEAR) != 0xffffffff
> > > > > > +#error "Inconsistent SCTLR_EL2 set/clear bits"
> > > > > > +#endif
> > > > >
> > > > > Can we have a comment on the != 0xffffffff versus != ~0 here?
> > > > >
> > > > > The subtle differences in evaluation semantics between #if and
> > > > > other contexts here may well trip people up during maintenance...
> > > >
> > > > Do you have any suggestion as to the wording?
> > > >
> > > > I'm happy to add a comment, but I don't really know what to say.
> > >
> > >
> > > How about the following?
> > >
> > > /* Watch out for #if evaluation rules: ~0 is not ~(int)0! */
> >
> > Or, more formally, perhaps something even less vague like "Note that in
> > preprocessor arithmetic these constants are effectively of type intmax_t,
> > which is 64-bit, thus ~0 is not what we want."
>
> I'll drop something in the commit message to that effect, rather than a
> comment.
>
> A comment will end up terse and vague or large and bloatsome (and
> redundant as we have this pattern twice).
>
> Anyone attempting to "clean" this up will find things break, and they can
> look at the git log to find out why it is the way it is...
Fair enough. So long as we say something somewhere, that's
sufficient for me.
With that,
Reviewed-by: Dave Martin <Dave.Martin@arm.com>
(as previously stated).
Cheers
---Dave
^ permalink raw reply
* [FAIL bisect] Sound card probe error
From: Krzysztof Kozlowski @ 2018-05-14 12:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAPDyKFoQFxHqupyqH3JsriUDdJHpUDecD37OqOSKn-sT26gEiA@mail.gmail.com>
On Mon, May 14, 2018 at 2:30 PM, Ulf Hansson <ulf.hansson@linaro.org> wrote:
> On 14 May 2018 at 14:22, Sylwester Nawrocki <s.nawrocki@samsung.com> wrote:
>> Hi,
>>
>> On 05/14/2018 12:17 PM, Krzysztof Kozlowski wrote:
>>
>>> Bisected to:
>>> 8c123c14bbba4add148536b6d47a9226deda2f7a is the first bad commit
>>> commit 8c123c14bbba4add148536b6d47a9226deda2f7a
>>> Author: Ulf Hansson <ulf.hansson@linaro.org>
>>> Date: Thu Apr 26 10:53:06 2018 +0200
>>>
>>> driver core: Respect all error codes from dev_pm_domain_attach()
>>>
>>> The limitation of being able to check only for -EPROBE_DEFER from
>>> dev_pm_domain_attach() has been removed. Hence let's respect all error
>>> codes and bail out accordingly.
>>>
>>> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
>>> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>>> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
>>
>> The DRM driver creates the HDMI codec but its registration fails, due
>> to some missing clocks. The clock are missing because the exynos5-subcmu
>> driver probing fails.
>>
>> [ 0.678578] exynos5-subcmu: probe of GSC failed with error -17
>> [ 0.679250] exynos5-subcmu: probe of MFC failed with error -17
>> [ 0.679992] exynos5-subcmu: probe of DISP failed with error -17
>>
>> The exynos5-subcmu driver before registering platform device makes
>> of_genpd_add_device() call, so in platform_drv_probe() dev_pm_domain_attach()
>> call will fail, as dev->pm_domain is already set. Previously the error
>> was masked by code removed in the above commit and platform_drv_probe()
>> was could complete successfully.
>
> Thanks for providing this information!
>
> I was about to tell that I overlooked the fact that there is more than
> one way to assign PM domain pointers to devices. To fix the problem,
> dev_pm_domain_attach() should return 0, not -EEXIST when it finds and
> existing PM domain pointer.
>
> Does the below patch fix the problem?
>
> From: Ulf Hansson <ulf.hansson@linaro.org>
> Date: Mon, 14 May 2018 14:26:16 +0200
> Subject: [PATCH] PM / Domains: Don't return -EEXIST at attach when PM domain
> exists
>
> As dev_pm_domain_attach() isn't the only way to assign PM domain pointers
> to devices, clearly we must allow a device to have the pointer already
> being assigned. For this reason, return 0 instead of -EEXIST.
>
> Reported-by: Krzysztof Kozlowski <krzk@kernel.org>
> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
> ---
> drivers/base/power/common.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Yes, this fixes the issue.
Tested-by: Krzysztof Kozlowski <krzk@kernel.org>
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH 17/18] arm64: convert compat wrappers to C
From: Mark Rutland @ 2018-05-14 12:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180514121022.GB11638@infradead.org>
On Mon, May 14, 2018 at 05:10:22AM -0700, Christoph Hellwig wrote:
> > +COMPAT_SYSCALL_DEFINE3(aarch32_statfs64, const char __user *, pathname,
> > + compat_size_t, sz, struct compat_statfs64 __user *, buf)
> > +{
> > + if (sz == 88)
> > + sz = 84;
> > +
> > + return kcompat_sys_statfs64(pathname, sz, buf);
>
> This really needs a comment, and it looks very obviously bogus.
> In case it isn't it needs a very good explanation.
Per arch/arm/kernel/sys_oabi-compat.c:
struct statfs64 has extra padding with EABI growing its size from
84 to 88. This struct is now __attribute__((packed,aligned(4)))
with a small assembly wrapper to force the sz argument to 84 if it is 88
to avoid copying the extra padding over user space unexpecting it.
This is the behaviour for both EABI and OABI on 32-bit arm, and thus we
must do the same for compat (and have done since day one of arm64).
I'll add a comment.
Thanks,
Mark.
^ permalink raw reply
* [RFC PATCH] driver core: make deferring probe forever optional
From: Michal Simek @ 2018-05-14 12:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <c6655f84-747f-c08b-7b9c-f76ff8857567@suse.de>
On 14.5.2018 09:37, Alexander Graf wrote:
>
> On 05/14/2018 12:01 AM, Linus Walleij wrote:
>> On Wed, May 9, 2018 at 11:44 AM, Alexander Graf <agraf@suse.de> wrote:
>>> On 05/07/2018 08:31 PM, Bjorn Andersson wrote:
>>>> Can you please name platform that has enough support for Alexander to
>>>> care about backwards and forwards compatibility but lacks a pinctrl
>>>> driver.
>>> ZynqMP is one example that immediately comes to my mind. I'm sure
>>> there are
>>> others too.
>> Why isn't that using drivers/pinctrl/pinctrl-zynq.c?
>>
>> How is it so very different from (old) Zynq as it is already using
>> the same GPIO driver?
>
> That one is very simple: ZynqMP is usually an AMP system where Linux
> doesn't have full knowledge of the overall system. IIUC they have a tiny
> microblaze (PMU) that does the actual full system configuration for
> peripherals that may interfere with each other. This architecture also
> allows for safety critical code to run alongside a (less safe) Linux
> system.
Linux is running in non secure world that's why Linux can't have full
system visibility and Linux should ask firmware. It doesn't matter if
firmware is running on specific unit or just secure SW in EL3/EL1-S, EL0-S.
You can also configure ZynqMP to protect these address ranges not to be
accessible from NS sw.
If you don't care about security you can use normal read/write accesses
at least for gpio case. Pinctrl/clk will be driven via firmware interface.
On Zynq we have never finished running Linux in NS and having firmware
to handle it that's why only read/write is used there.
Thanks,
Michal
^ permalink raw reply
* [FAIL bisect] Sound card probe error
From: Krzysztof Kozlowski @ 2018-05-14 12:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4c61c422-a036-8fec-1153-d612fe5df878@samsung.com>
On Mon, May 14, 2018 at 2:40 PM, Sylwester Nawrocki
<s.nawrocki@samsung.com> wrote:
> On 05/14/2018 02:29 PM, Krzysztof Kozlowski wrote:
>> Ah, I missed these messages because I was looking at err dmesg level
>> (and for some reason these are warn). Anyway do you have any thoughts
>> how is it connected with missing Odroid XU3 sound card and max98090
>> codec?
>
> One reason is that the DRM driver registers an ASoC codec object which
> is required for the sound card registration to complete. But I wonder
> why there is no any error messages related to this.
Thanks Marek and Sylwester. Another point is that probably OOPS later
should not happen...
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH v4 5/6] bus: fsl-mc: supoprt dma configure for devices on fsl-mc bus
From: Bjorn Helgaas @ 2018-05-14 12:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525069641-8523-6-git-send-email-nipun.gupta@nxp.com>
When you add the changleog, please also fix the subject typo:
- bus: fsl-mc: supoprt dma configure for devices on fsl-mc bus
^^^^^^^
+ bus: fsl-mc: support dma configure for devices on fsl-mc bus
On Mon, Apr 30, 2018 at 11:57:20AM +0530, Nipun Gupta wrote:
> Signed-off-by: Nipun Gupta <nipun.gupta@nxp.com>
> ---
> drivers/bus/fsl-mc/fsl-mc-bus.c | 16 ++++++++++++----
> 1 file changed, 12 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/bus/fsl-mc/fsl-mc-bus.c b/drivers/bus/fsl-mc/fsl-mc-bus.c
> index 5d8266c..624828b 100644
> --- a/drivers/bus/fsl-mc/fsl-mc-bus.c
> +++ b/drivers/bus/fsl-mc/fsl-mc-bus.c
> @@ -127,6 +127,16 @@ static int fsl_mc_bus_uevent(struct device *dev, struct kobj_uevent_env *env)
> return 0;
> }
>
> +static int fsl_mc_dma_configure(struct device *dev)
> +{
> + struct device *dma_dev = dev;
> +
> + while (dev_is_fsl_mc(dma_dev))
> + dma_dev = dma_dev->parent;
> +
> + return of_dma_configure(dev, dma_dev->of_node, 0);
> +}
> +
> static ssize_t modalias_show(struct device *dev, struct device_attribute *attr,
> char *buf)
> {
> @@ -148,6 +158,7 @@ struct bus_type fsl_mc_bus_type = {
> .name = "fsl-mc",
> .match = fsl_mc_bus_match,
> .uevent = fsl_mc_bus_uevent,
> + .dma_configure = fsl_mc_dma_configure,
> .dev_groups = fsl_mc_dev_groups,
> };
> EXPORT_SYMBOL_GPL(fsl_mc_bus_type);
> @@ -616,6 +627,7 @@ int fsl_mc_device_add(struct fsl_mc_obj_desc *obj_desc,
> mc_dev->icid = parent_mc_dev->icid;
> mc_dev->dma_mask = FSL_MC_DEFAULT_DMA_MASK;
> mc_dev->dev.dma_mask = &mc_dev->dma_mask;
> + mc_dev->dev.coherent_dma_mask = mc_dev->dma_mask;
> dev_set_msi_domain(&mc_dev->dev,
> dev_get_msi_domain(&parent_mc_dev->dev));
> }
> @@ -633,10 +645,6 @@ int fsl_mc_device_add(struct fsl_mc_obj_desc *obj_desc,
> goto error_cleanup_dev;
> }
>
> - /* Objects are coherent, unless 'no shareability' flag set. */
> - if (!(obj_desc->flags & FSL_MC_OBJ_FLAG_NO_MEM_SHAREABILITY))
> - arch_setup_dma_ops(&mc_dev->dev, 0, 0, NULL, true);
> -
> /*
> * The device-specific probe callback will get invoked by device_add()
> */
> --
> 1.9.1
>
^ permalink raw reply
* [FAIL bisect] Sound card probe error
From: Krzysztof Kozlowski @ 2018-05-14 12:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAJKOXPc6Yj0+Z6zd-Gm-fYvfQB4rPPn0k6ED8bWScJ-tdZ=Ysw@mail.gmail.com>
On Mon, May 14, 2018 at 2:45 PM, Krzysztof Kozlowski <krzk@kernel.org> wrote:
> On Mon, May 14, 2018 at 2:40 PM, Sylwester Nawrocki
> <s.nawrocki@samsung.com> wrote:
>> On 05/14/2018 02:29 PM, Krzysztof Kozlowski wrote:
>>> Ah, I missed these messages because I was looking at err dmesg level
>>> (and for some reason these are warn). Anyway do you have any thoughts
>>> how is it connected with missing Odroid XU3 sound card and max98090
>>> codec?
>>
>> One reason is that the DRM driver registers an ASoC codec object which
>> is required for the sound card registration to complete. But I wonder
>> why there is no any error messages related to this.
>
> Thanks Marek and Sylwester. Another point is that probably OOPS later
> should not happen...
Separate topic (trim Cc list):
... and this means that disabling Exynos DRM causes lack of Audio. I
tried it now and indeed without DRM there is no audio again. I think
it is not nice... There are not many such use cases but there are
(playing audio from console/ssh with a headless board).\
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH 08/18] arm64: convert raw syscall invocation to C
From: Dave Martin @ 2018-05-14 12:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180514114104.oubxdf526hf2m6t5@lakrids.cambridge.arm.com>
On Mon, May 14, 2018 at 12:41:10PM +0100, Mark Rutland wrote:
> On Mon, May 14, 2018 at 12:07:18PM +0100, Dave Martin wrote:
> > On Mon, May 14, 2018 at 10:46:30AM +0100, Mark Rutland wrote:
> > > As a first step towards invoking syscalls with a pt_regs argument,
> > > convert the raw syscall invocation logic to C. We end up with a bit more
> > > register shuffling, but the unified invocation logic means we can unify
> > > the tracing paths, too.
> > >
> > > This only converts the invocation of the syscall. The rest of the
> > > syscall triage and tracing is left in assembly for now, and will be
> > > converted in subsequent patches.
> > >
> > > Signed-off-by: Mark Rutland <mark.rutland@arm.com>
> > > Cc: Catalin Marinas <catalin.marinas@arm.com>
> > > Cc: Will Deacon <will.deacon@arm.com>
> > > ---
> > > arch/arm64/kernel/Makefile | 3 ++-
> > > arch/arm64/kernel/entry.S | 36 ++++++++++--------------------------
> > > arch/arm64/kernel/syscall.c | 29 +++++++++++++++++++++++++++++
> > > 3 files changed, 41 insertions(+), 27 deletions(-)
> > > create mode 100644 arch/arm64/kernel/syscall.c
> > >
> > > diff --git a/arch/arm64/kernel/Makefile b/arch/arm64/kernel/Makefile
> > > index bf825f38d206..c22e8ace5ea3 100644
> > > --- a/arch/arm64/kernel/Makefile
> > > +++ b/arch/arm64/kernel/Makefile
> > > @@ -18,7 +18,8 @@ arm64-obj-y := debug-monitors.o entry.o irq.o fpsimd.o \
> > > hyp-stub.o psci.o cpu_ops.o insn.o \
> > > return_address.o cpuinfo.o cpu_errata.o \
> > > cpufeature.o alternative.o cacheinfo.o \
> > > - smp.o smp_spin_table.o topology.o smccc-call.o
> > > + smp.o smp_spin_table.o topology.o smccc-call.o \
> > > + syscall.o
> > >
> > > extra-$(CONFIG_EFI) := efi-entry.o
> > >
> > > diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S
> > > index 08ea3cbfb08f..d6e057500eaf 100644
> > > --- a/arch/arm64/kernel/entry.S
> > > +++ b/arch/arm64/kernel/entry.S
> > > @@ -873,7 +873,6 @@ ENDPROC(el0_error)
> > > */
> > > ret_fast_syscall:
> > > disable_daif
> > > - str x0, [sp, #S_X0] // returned x0
> > > ldr x1, [tsk, #TSK_TI_FLAGS] // re-check for syscall tracing
> > > and x2, x1, #_TIF_SYSCALL_WORK
> > > cbnz x2, ret_fast_syscall_trace
> > > @@ -946,15 +945,11 @@ el0_svc_naked: // compat entry point
> > >
> > > tst x16, #_TIF_SYSCALL_WORK // check for syscall hooks
> > > b.ne __sys_trace
> > > - cmp wscno, wsc_nr // check upper syscall limit
> > > - b.hs ni_sys
> > > - mask_nospec64 xscno, xsc_nr, x19 // enforce bounds for syscall number
> > > - ldr x16, [stbl, xscno, lsl #3] // address in the syscall table
> > > - blr x16 // call sys_* routine
> > > - b ret_fast_syscall
> > > -ni_sys:
> > > mov x0, sp
> > > - bl do_ni_syscall
> > > + mov w1, wscno
> > > + mov w2, wsc_nr
> > > + mov x3, stbl
> > > + bl invoke_syscall
> > > b ret_fast_syscall
> > > ENDPROC(el0_svc)
> > >
> > > @@ -971,29 +966,18 @@ __sys_trace:
> > > bl syscall_trace_enter
> > > cmp w0, #NO_SYSCALL // skip the syscall?
> > > b.eq __sys_trace_return_skipped
> > > - mov wscno, w0 // syscall number (possibly new)
> > > - mov x1, sp // pointer to regs
> > > - cmp wscno, wsc_nr // check upper syscall limit
> > > - b.hs __ni_sys_trace
> > > - ldp x0, x1, [sp] // restore the syscall args
> > > - ldp x2, x3, [sp, #S_X2]
> > > - ldp x4, x5, [sp, #S_X4]
> > > - ldp x6, x7, [sp, #S_X6]
> > > - ldr x16, [stbl, xscno, lsl #3] // address in the syscall table
> > > - blr x16 // call sys_* routine
> > >
> > > -__sys_trace_return:
> > > - str x0, [sp, #S_X0] // save returned x0
> > > + mov x0, sp
> > > + mov w1, wscno
> > > + mov w2, wsc_nr
> > > + mov x3, stbl
> > > + bl invoke_syscall
> > > +
> > > __sys_trace_return_skipped:
> > > mov x0, sp
> > > bl syscall_trace_exit
> > > b ret_to_user
> > >
> > > -__ni_sys_trace:
> > > - mov x0, sp
> > > - bl do_ni_syscall
> > > - b __sys_trace_return
> > > -
> >
> > Can you explain why ni_syscall is special here,
>
> This is for out-of-range syscall numbers, instances of ni_syscall in the
> syscall table are handled by the regular path. When the syscall number
> is out-of-range, we can't index the syscall table, and have to call
> ni_sys directly.
>
> The c invoke_syscall() wrapper handles that case internally so that we
> don't have to open-code it everywhere.
>
> > why __sys_trace_return existed,
>
> The __sys_trace_return label existed so that the special __ni_sys_trace
> path could return into a common tracing return path.
>
> > and why its disappearance doesn't break anything?
>
> Now that invoke_syscall() handles out-of-range syscall numbers, and we
> can remove the __ni_sys_trace path, nothing branches to
> __sys_trace_return.
>
> Only the label has been removed, not the usual return path.
OK, I think I understand. I think the name "__sys_trace_return" was
confusing me, as if this was something special that only relates to the
ni_syscall case. If it was only ever intended as the merge point for
those two paths, then I can see that merging the paths for real enables
us to get rid of it.
> > Not saying there's a bug, just that I'm a little confuse -- I see no
> > real reason for ni_syscall being special, and this may be a good
> > opportunity to decruft it. (See also comments below.)
>
> Hopefully the above clarifies things?
Yes, I think so.
> I've updated the commit message with a description.
>
> [...]
>
> > > +asmlinkage void invoke_syscall(struct pt_regs *regs, int scno, int sc_nr,
> > > + syscall_fn_t syscall_table[])
> > > +{
> > > + if (scno < sc_nr) {
> >
> > What if (int)scno < 0? Should those args both by unsigned ints?
>
> Yes, they should -- I've fixed that up locally.
>
> That is a *very* good point, thanks!
>
> > "sc_nr" sounds too much like "syscall number" to me. Might
> > "syscall_table_size" might be clearer? Similarly, we could have
> > "stbl_size" or similar in the asm. This is purely cosmetic,
> > though.
>
> I'd tried to stick to the naming used in assembly to keep the conversion
> clearer for those familiar with the asm.
>
> I agree the names aren't great.
Not a big deal. If you feel you would like to rename them though, I
won't argue with it ;)
> > > + syscall_fn_t syscall_fn;
> > > + syscall_fn = syscall_table[array_index_nospec(scno, sc_nr)];
> > > + __invoke_syscall(regs, syscall_fn);
> > > + } else {
> > > + regs->regs[0] = do_ni_syscall(regs);
> >
> > Can we make __invoke_syscall() the universal syscall wrapper, and give
> > do_ni_syscall() the same interface as any other syscall body?
>
> Not at this point in time, since the prototype (in core code) differs.
>
> I agree that would be nicer, but there are a number of complications;
> more details below.
>
> > Then you could factor this as
> >
> > static syscall_fn_t syscall_fn(syscall_fn_t const syscall_table[],
> > (unsigned) int scno, (unsigned) int sc_nr)
> > {
> > if (sc_no >= sc_nr)
> > return sys_ni_syscall;
> >
> > return syscall_table[array_index_nospec(scno, sc_nr)];
> > }
> >
> > ...
> > __invoke_syscall(regs, syscall_fn(syscall_table, scno, sc_nr);
> >
> >
> >
> > This is cosmetic too, of course.
> >
> > do_ni_syscall() should be given a pt_regs-based wrapper like all the
> > rest.
>
> I agree it would be nicer if it had a wrapper that took a pt_regs, even
> if it does nothing with it.
>
> We can't use SYSCALL_DEFINE0() due to the fault injection muck, we'd
> need a ksys_ni_syscall() for our traps.c logic, and adding this
> uniformly would involve some arch-specific rework for x86, too, so I
> decided it was not worth the effort.
Does allowing error injection for ni_syscall actually matter? Error
injection is an ABI break by itself. It would arguably be a bit
strange though.
Cheers
---Dave
^ permalink raw reply
* [PATCH 02/18] arm64: move SCTLR_EL{1,2} assertions to <asm/sysreg.h>
From: Mark Rutland @ 2018-05-14 13:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180514124122.GJ7753@e103592.cambridge.arm.com>
On Mon, May 14, 2018 at 01:41:23PM +0100, Dave Martin wrote:
> On Mon, May 14, 2018 at 01:06:10PM +0100, Mark Rutland wrote:
> > On Mon, May 14, 2018 at 12:56:09PM +0100, Robin Murphy wrote:
> > > On 14/05/18 12:20, Dave Martin wrote:
> > > > How about the following?
> > > >
> > > > /* Watch out for #if evaluation rules: ~0 is not ~(int)0! */
> > >
> > > Or, more formally, perhaps something even less vague like "Note that in
> > > preprocessor arithmetic these constants are effectively of type intmax_t,
> > > which is 64-bit, thus ~0 is not what we want."
> >
> > I'll drop something in the commit message to that effect, rather than a
> > comment.
> >
> > A comment will end up terse and vague or large and bloatsome (and
> > redundant as we have this pattern twice).
> >
> > Anyone attempting to "clean" this up will find things break, and they can
> > look at the git log to find out why it is the way it is...
>
> Fair enough. So long as we say something somewhere, that's
> sufficient for me.
>
> With that,
>
> Reviewed-by: Dave Martin <Dave.Martin@arm.com>
>
> (as previously stated).
Cheers!
Mark.
^ permalink raw reply
* Delivery Status Notification (Failure)
From: Lucas Stach @ 2018-05-14 13:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOuPNLiFr3qbNVAwF4wj2aAG0UXRVsgRo-8JfaKFCsoL+Ggk9w@mail.gmail.com>
Am Montag, den 14.05.2018, 17:42 +0530 schrieb Pintu Kumar:
> Hi,
>
> Is there any work around possible to set IRQ affinity for some GPIO
> interrupt ?
> How to avoid CPU0 to receive the current GPIO interrupt ?
> How do we assign GPIO interrupts to any CPU other than CPU0 ?
> Is it possible to isolate CPU0 for a sometime, from my GPIO driver so
> that GPIO interrupt can be served by another CPU ?
>
> Need your inputs to decide whether it is still possible to set
> affinity for GPIO interrupt, or its impossible ?
This is not possible. The GPIO IRQs are aggregated into one GPC/GIC IRQ
line per GPIO bank, so it is not possible to change affinity of a
single GPIO interrupt to another CPU. Best we could do is change the
affinity of the whole bank, but given the limited usefulness of
something like that, nobody bothered to implement such a thing.
Regards,
Lucas
>
>
> On Fri, May 11, 2018 at 8:07 PM, Pintu Kumar <pintu.ping@gmail.com>
> wrote:
> > On Fri, May 11, 2018 at 6:34 PM, Lucas Stach <l.stach@pengutronix.d
> > e> wrote:
> > > Am Freitag, den 11.05.2018, 13:39 +0100 schrieb Russell King -
> > > ARM Linux:
> > > > On Fri, May 11, 2018 at 05:07:37PM +0530, Pintu Kumar wrote:
> > > > > Hi,
> > > > >
> > > > > I need one help.
> > > > > I am using i.MX7 Sabre board with kernel version 4.1.15
> > > > >
> > > > > Let's say I am interested in GPIO number: 21
> > > > > I wanted to set CPU affinity for particular GPIO->IRQ number,
> > > > > so I
> > > > > tried the below steps:
> > > > > root at 10:~# echo 21 > /sys/class/gpio/export
> > > > > root at 10:~# echo "rising" > /sys/class/gpio/gpio21/edge
> > > > > root at 10:~# cat /proc/interrupts | grep 21
> > > > > ? 47: 0 0 gpio-mxc 21 Edge gpiolib
> > > > > root at 10:~# cat /sys/class/gpio/gpio21/direction
> > > > > in
> > > > > root at 10:~# cat /proc/irq/47/smp_affinity
> > > > > 3
> > > > > root at 10:~# echo 2 > /proc/irq/47/smp_affinity
> > > > > -bash: echo: write error: Input/output error
> > > > >
> > > > > But I get input/output error.
> > > > > When I debug further, found that irq_can_set_affinity is
> > > > > returning 0:
> > > > > [????0.000000] genirq: irq_can_set_affinity (0): balance: 1,
> > > > > irq_data.chip: a81b7e48, irq_set_affinity:???(null)
> > > > > [????0.000000] write_irq_affinity: FAIL
> > > > >
> > > > > I also tried first setting /proc/irq/default_smp_affinity to
> > > > > 2 (from 3).
> > > > > This change is working, but the smp_affinity setting for the
> > > > > new IRQ
> > > > > is not working.
> > > > >
> > > > > When I try to set smp_affinity for mmc0, then it works.
> > > > > # cat /proc/interrupts | grep mmc
> > > > > 295:?????????55??????????0?????GPCV2??22 Edge??????mmc0
> > > > > 296:??????????0??????????0?????GPCV2??23 Edge??????mmc1
> > > > > 297:?????????52??????????0?????GPCV2??24 Edge??????mmc2
> > > > >
> > > > > root at 10:~# echo 2 > /proc/irq/295/smp_affinity
> > > > > root at 10:~#
> > > > >
> > > > >
> > > > > So, I wanted to know what are the conditions for which
> > > > > setting
> > > > > smp_affinity for an IRQ will work ?
> > > > >
> > > > > Is there any way by which I can set CPU affinity to a GPIO ->
> > > > > IRQ ?
> > > > > Whether, irq_set_affinity_hint() will work in this case ?
> > > >
> > > > IRQ affinity is only supported where interrupts are _directly_
> > > > wired to
> > > > the GIC.??It's the GIC which does the interrupt steering to the
> > > > CPU
> > > > cores.
> > > >
> > > > Interrupts on downstream interrupt controllers (such as GPCV2)
> > > > have no
> > > > ability to be directed independently to other CPUs - the only
> > > > possible
> > > > way to change the mapping is to move _all_ interrupts on that
> > > > controller,
> > > > and any downstream chained interrupts at GIC level.
> > > >
> > > > Hence why Interrupt 295 has no irq_set_affinity function: there
> > > > is no way
> > > > for the interrupt controller itself to change the affinity of
> > > > the input
> > > > interrupt.
> > >
> > > The GPCv2 though is a secondary IRQ controller which has a 1:1
> > > mapping
> > > of its input IRQs to the upstream GIC IRQ lines. Affinity can
> > > thus be
> > > handled by forwarding the request to the GIC by
> > > irq_chip_set_affinity_parent().
> > >
> > > As this is handled correctly in the upstream kernel since the
> > > first
> > > commit introducing support for the GPCv2, it seems the issue is
> > > only
> > > present in some downstream kernel.
> > >
> >
> > OK. Thanks so much for your reply.
> >
> > I saw some of the drivers using irq_set_affinity_hint() to force
> > the
> > IRQ affinity to a particular CPU.
> > This is the sample:
> > {
> > cpumask_clear(mask);
> > cpumask_set_cpu(cpu, mask);
> > irq_set_affinity_hint(irq, mask);
> > }
> >
> > Whether this logic will work for a particular GPIO pin ?
> >
> >
> > > Regards,
> > > Lucas
^ permalink raw reply
* [PATCH v6 00/14] CPU scaling support for msm8996
From: Ilia Lin @ 2018-05-14 13:11 UTC (permalink / raw)
To: linux-arm-kernel
[v6]
* Addressed comments from Viresh about:
** Comments style
** Kconfig bool instead of tristate
** DT and documentation style
** Resourses deallocation on an error
** Typos
[v5]
* Rebased
* Addressed comments from Bjorn about SPDX style,
functions and parameters naming
* Addressed comments from Viresh DT properties and style, comments style,
resourses deallocation, documentation placement
* Addressed comments from Sricharan about unnessesary include
* Addressed comments from Nicolas
* Addressed comments from Rob about the commit messages and acks
* Addressed comments from Mark
[v4]
* Adressed all comments from Stephen
* Added CPU regulator support
* Added qcom-cpufreq-kryo driver
[v3]
* Rebased on top of the latest PLL driver changes
* Addressed comment from Rob Herring for bindings
[v2]
* Addressed comments from Rob Herring for bindings
* Addressed comments from Mark Rutland for memory barrier
* Addressed comments from Julien Thierry for clock reenabling condition
* Tuned the HW configuration for clock frequencies below 600MHz
Clocks:
This series adds support for the CPU clocks on msm8996 devices.
The driver uses the existing PLL drivers and is required to control
the CPU frequency scaling on the MSM8996.
Regulators:
Added SAW regulator support to the SPMI regulator driver. The SAW regulators
will be controlled through special CPU registers instead of direct
SPMI accesses.
Cpufreq:
The qcom-cpufreq-kryo driver is aimed to support different SOC versions.
The driver reads eFuse information and chooses the required OPP subset
by passing the OPP supported-hw parameter.
A previous post of RFC can be found here:
https://patchwork.kernel.org/patch/10377887/
Ilia Lin (11):
soc: qcom: Separate kryo l2 accessors from PMU driver
clk: qcom: Add CPU clock driver for msm8996
clk: qcom: Add DT bindings for CPU clock driver for msm8996
clk: qcom: Add ACD path to CPU clock driver for msm8996
dt: qcom: Add opp and thermal to the msm8996
regulator: qcom_spmi: Add support for SAW
dt-bindings: qcom_spmi: Add support for SAW documentation
dt: qcom: Add SAW regulator for 8x96 CPUs
cpufreq: Add Kryo CPU scaling driver
dt-bindings: cpufreq: Document operating-points-v2-kryo-cpu
dt: qcom: Add qcom-cpufreq-kryo driver configuration
Rajendra Nayak (3):
clk: qcom: Make clk_alpha_pll_configure available to modules
clk: qcom: cpu-8996: Add support to switch to alternate PLL
clk: qcom: cpu-8996: Add support to switch below 600Mhz
.../devicetree/bindings/clock/qcom,kryocc.txt | 17 +
.../devicetree/bindings/opp/kryo-cpufreq.txt | 680 +++++++++++++++++++++
.../bindings/regulator/qcom,spmi-regulator.txt | 45 ++
arch/arm64/boot/dts/qcom/apq8096-db820c.dts | 2 +-
arch/arm64/boot/dts/qcom/msm8996.dtsi | 650 +++++++++++++++++++-
drivers/clk/clk-fixed-factor.c | 2 +-
drivers/clk/qcom/Kconfig | 9 +
drivers/clk/qcom/Makefile | 1 +
drivers/clk/qcom/clk-alpha-pll.c | 1 +
drivers/clk/qcom/clk-alpha-pll.h | 6 +
drivers/clk/qcom/clk-cpu-8996.c | 519 ++++++++++++++++
drivers/cpufreq/Kconfig.arm | 11 +
drivers/cpufreq/Makefile | 1 +
drivers/cpufreq/cpufreq-dt-platdev.c | 3 +
drivers/cpufreq/qcom-cpufreq-kryo.c | 148 +++++
drivers/perf/Kconfig | 1 +
drivers/perf/qcom_l2_pmu.c | 90 +--
drivers/regulator/qcom_spmi-regulator.c | 133 +++-
drivers/soc/qcom/Kconfig | 3 +
drivers/soc/qcom/Makefile | 1 +
drivers/soc/qcom/kryo-l2-accessors.c | 65 ++
include/soc/qcom/kryo-l2-accessors.h | 21 +
22 files changed, 2329 insertions(+), 80 deletions(-)
create mode 100644 Documentation/devicetree/bindings/clock/qcom,kryocc.txt
create mode 100644 Documentation/devicetree/bindings/opp/kryo-cpufreq.txt
create mode 100644 drivers/clk/qcom/clk-cpu-8996.c
create mode 100644 drivers/cpufreq/qcom-cpufreq-kryo.c
create mode 100644 drivers/soc/qcom/kryo-l2-accessors.c
create mode 100644 include/soc/qcom/kryo-l2-accessors.h
--
1.9.1
^ permalink raw reply
* [PATCH v6 01/14] soc: qcom: Separate kryo l2 accessors from PMU driver
From: Ilia Lin @ 2018-05-14 13:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1526303520-5843-1-git-send-email-ilialin@codeaurora.org>
The driver provides kernel level API for other drivers
to access the MSM8996 L2 cache registers.
Separating the L2 access code from the PMU driver and
making it public to allow other drivers use it.
The accesses must be separated with a single spinlock,
maintained in this driver.
Signed-off-by: Ilia Lin <ilialin@codeaurora.org>
---
drivers/perf/Kconfig | 1 +
drivers/perf/qcom_l2_pmu.c | 90 ++++++++++--------------------------
drivers/soc/qcom/Kconfig | 3 ++
drivers/soc/qcom/Makefile | 1 +
drivers/soc/qcom/kryo-l2-accessors.c | 65 ++++++++++++++++++++++++++
include/soc/qcom/kryo-l2-accessors.h | 21 +++++++++
6 files changed, 115 insertions(+), 66 deletions(-)
create mode 100644 drivers/soc/qcom/kryo-l2-accessors.c
create mode 100644 include/soc/qcom/kryo-l2-accessors.h
diff --git a/drivers/perf/Kconfig b/drivers/perf/Kconfig
index 28bb5a0..561252a 100644
--- a/drivers/perf/Kconfig
+++ b/drivers/perf/Kconfig
@@ -69,6 +69,7 @@ config HISI_PMU
config QCOM_L2_PMU
bool "Qualcomm Technologies L2-cache PMU"
depends on ARCH_QCOM && ARM64 && ACPI
+ select QCOM_KRYO_L2_ACCESSORS
help
Provides support for the L2 cache performance monitor unit (PMU)
in Qualcomm Technologies processors.
diff --git a/drivers/perf/qcom_l2_pmu.c b/drivers/perf/qcom_l2_pmu.c
index 842135c..cc31f51 100644
--- a/drivers/perf/qcom_l2_pmu.c
+++ b/drivers/perf/qcom_l2_pmu.c
@@ -31,6 +31,7 @@
#include <asm/barrier.h>
#include <asm/local64.h>
#include <asm/sysreg.h>
+#include <soc/qcom/kryo-l2-accessors.h>
#define MAX_L2_CTRS 9
@@ -87,8 +88,6 @@
#define L2_COUNTER_RELOAD BIT_ULL(31)
#define L2_CYCLE_COUNTER_RELOAD BIT_ULL(63)
-#define L2CPUSRSELR_EL1 sys_reg(3, 3, 15, 0, 6)
-#define L2CPUSRDR_EL1 sys_reg(3, 3, 15, 0, 7)
#define reg_idx(reg, i) (((i) * IA_L2_REG_OFFSET) + reg##_BASE)
@@ -107,48 +106,7 @@
#define L2_EVENT_STREX 0x421
#define L2_EVENT_CLREX 0x422
-static DEFINE_RAW_SPINLOCK(l2_access_lock);
-/**
- * set_l2_indirect_reg: write value to an L2 register
- * @reg: Address of L2 register.
- * @value: Value to be written to register.
- *
- * Use architecturally required barriers for ordering between system register
- * accesses
- */
-static void set_l2_indirect_reg(u64 reg, u64 val)
-{
- unsigned long flags;
-
- raw_spin_lock_irqsave(&l2_access_lock, flags);
- write_sysreg_s(reg, L2CPUSRSELR_EL1);
- isb();
- write_sysreg_s(val, L2CPUSRDR_EL1);
- isb();
- raw_spin_unlock_irqrestore(&l2_access_lock, flags);
-}
-
-/**
- * get_l2_indirect_reg: read an L2 register value
- * @reg: Address of L2 register.
- *
- * Use architecturally required barriers for ordering between system register
- * accesses
- */
-static u64 get_l2_indirect_reg(u64 reg)
-{
- u64 val;
- unsigned long flags;
-
- raw_spin_lock_irqsave(&l2_access_lock, flags);
- write_sysreg_s(reg, L2CPUSRSELR_EL1);
- isb();
- val = read_sysreg_s(L2CPUSRDR_EL1);
- raw_spin_unlock_irqrestore(&l2_access_lock, flags);
-
- return val;
-}
struct cluster_pmu;
@@ -219,28 +177,28 @@ static inline struct cluster_pmu *get_cluster_pmu(
static void cluster_pmu_reset(void)
{
/* Reset all counters */
- set_l2_indirect_reg(L2PMCR, L2PMCR_RESET_ALL);
- set_l2_indirect_reg(L2PMCNTENCLR, l2_counter_present_mask);
- set_l2_indirect_reg(L2PMINTENCLR, l2_counter_present_mask);
- set_l2_indirect_reg(L2PMOVSCLR, l2_counter_present_mask);
+ kryo_l2_set_indirect_reg(L2PMCR, L2PMCR_RESET_ALL);
+ kryo_l2_set_indirect_reg(L2PMCNTENCLR, l2_counter_present_mask);
+ kryo_l2_set_indirect_reg(L2PMINTENCLR, l2_counter_present_mask);
+ kryo_l2_set_indirect_reg(L2PMOVSCLR, l2_counter_present_mask);
}
static inline void cluster_pmu_enable(void)
{
- set_l2_indirect_reg(L2PMCR, L2PMCR_COUNTERS_ENABLE);
+ kryo_l2_set_indirect_reg(L2PMCR, L2PMCR_COUNTERS_ENABLE);
}
static inline void cluster_pmu_disable(void)
{
- set_l2_indirect_reg(L2PMCR, L2PMCR_COUNTERS_DISABLE);
+ kryo_l2_set_indirect_reg(L2PMCR, L2PMCR_COUNTERS_DISABLE);
}
static inline void cluster_pmu_counter_set_value(u32 idx, u64 value)
{
if (idx == l2_cycle_ctr_idx)
- set_l2_indirect_reg(L2PMCCNTR, value);
+ kryo_l2_set_indirect_reg(L2PMCCNTR, value);
else
- set_l2_indirect_reg(reg_idx(IA_L2PMXEVCNTR, idx), value);
+ kryo_l2_set_indirect_reg(reg_idx(IA_L2PMXEVCNTR, idx), value);
}
static inline u64 cluster_pmu_counter_get_value(u32 idx)
@@ -248,46 +206,46 @@ static inline u64 cluster_pmu_counter_get_value(u32 idx)
u64 value;
if (idx == l2_cycle_ctr_idx)
- value = get_l2_indirect_reg(L2PMCCNTR);
+ value = kryo_l2_get_indirect_reg(L2PMCCNTR);
else
- value = get_l2_indirect_reg(reg_idx(IA_L2PMXEVCNTR, idx));
+ value = kryo_l2_get_indirect_reg(reg_idx(IA_L2PMXEVCNTR, idx));
return value;
}
static inline void cluster_pmu_counter_enable(u32 idx)
{
- set_l2_indirect_reg(L2PMCNTENSET, idx_to_reg_bit(idx));
+ kryo_l2_set_indirect_reg(L2PMCNTENSET, idx_to_reg_bit(idx));
}
static inline void cluster_pmu_counter_disable(u32 idx)
{
- set_l2_indirect_reg(L2PMCNTENCLR, idx_to_reg_bit(idx));
+ kryo_l2_set_indirect_reg(L2PMCNTENCLR, idx_to_reg_bit(idx));
}
static inline void cluster_pmu_counter_enable_interrupt(u32 idx)
{
- set_l2_indirect_reg(L2PMINTENSET, idx_to_reg_bit(idx));
+ kryo_l2_set_indirect_reg(L2PMINTENSET, idx_to_reg_bit(idx));
}
static inline void cluster_pmu_counter_disable_interrupt(u32 idx)
{
- set_l2_indirect_reg(L2PMINTENCLR, idx_to_reg_bit(idx));
+ kryo_l2_set_indirect_reg(L2PMINTENCLR, idx_to_reg_bit(idx));
}
static inline void cluster_pmu_set_evccntcr(u32 val)
{
- set_l2_indirect_reg(L2PMCCNTCR, val);
+ kryo_l2_set_indirect_reg(L2PMCCNTCR, val);
}
static inline void cluster_pmu_set_evcntcr(u32 ctr, u32 val)
{
- set_l2_indirect_reg(reg_idx(IA_L2PMXEVCNTCR, ctr), val);
+ kryo_l2_set_indirect_reg(reg_idx(IA_L2PMXEVCNTCR, ctr), val);
}
static inline void cluster_pmu_set_evtyper(u32 ctr, u32 val)
{
- set_l2_indirect_reg(reg_idx(IA_L2PMXEVTYPER, ctr), val);
+ kryo_l2_set_indirect_reg(reg_idx(IA_L2PMXEVTYPER, ctr), val);
}
static void cluster_pmu_set_resr(struct cluster_pmu *cluster,
@@ -303,11 +261,11 @@ static void cluster_pmu_set_resr(struct cluster_pmu *cluster,
spin_lock_irqsave(&cluster->pmu_lock, flags);
- resr_val = get_l2_indirect_reg(L2PMRESR);
+ resr_val = kryo_l2_get_indirect_reg(L2PMRESR);
resr_val &= ~(L2PMRESR_GROUP_MASK << shift);
resr_val |= field;
resr_val |= L2PMRESR_EN;
- set_l2_indirect_reg(L2PMRESR, resr_val);
+ kryo_l2_set_indirect_reg(L2PMRESR, resr_val);
spin_unlock_irqrestore(&cluster->pmu_lock, flags);
}
@@ -323,14 +281,14 @@ static inline void cluster_pmu_set_evfilter_sys_mode(u32 ctr)
L2PMXEVFILTER_ORGFILTER_IDINDEP |
L2PMXEVFILTER_ORGFILTER_ALL;
- set_l2_indirect_reg(reg_idx(IA_L2PMXEVFILTER, ctr), val);
+ kryo_l2_set_indirect_reg(reg_idx(IA_L2PMXEVFILTER, ctr), val);
}
static inline u32 cluster_pmu_getreset_ovsr(void)
{
- u32 result = get_l2_indirect_reg(L2PMOVSSET);
+ u32 result = kryo_l2_get_indirect_reg(L2PMOVSSET);
- set_l2_indirect_reg(L2PMOVSCLR, result);
+ kryo_l2_set_indirect_reg(L2PMOVSCLR, result);
return result;
}
@@ -783,7 +741,7 @@ static int get_num_counters(void)
{
int val;
- val = get_l2_indirect_reg(L2PMCR);
+ val = kryo_l2_get_indirect_reg(L2PMCR);
/*
* Read number of counters from L2PMCR and add 1
diff --git a/drivers/soc/qcom/Kconfig b/drivers/soc/qcom/Kconfig
index 7093fe7..0567dff 100644
--- a/drivers/soc/qcom/Kconfig
+++ b/drivers/soc/qcom/Kconfig
@@ -39,6 +39,9 @@ config QCOM_GSBI
functions for connecting the underlying serial UART, SPI, and I2C
devices to the output pins.
+config QCOM_KRYO_L2_ACCESSORS
+ bool
+
config QCOM_MDT_LOADER
tristate
select QCOM_SCM
diff --git a/drivers/soc/qcom/Makefile b/drivers/soc/qcom/Makefile
index cbf414c..e4d3f5a 100644
--- a/drivers/soc/qcom/Makefile
+++ b/drivers/soc/qcom/Makefile
@@ -14,3 +14,4 @@ obj-$(CONFIG_QCOM_SMEM_STATE) += smem_state.o
obj-$(CONFIG_QCOM_SMP2P) += smp2p.o
obj-$(CONFIG_QCOM_SMSM) += smsm.o
obj-$(CONFIG_QCOM_WCNSS_CTRL) += wcnss_ctrl.o
+obj-$(CONFIG_QCOM_KRYO_L2_ACCESSORS) += kryo-l2-accessors.o
diff --git a/drivers/soc/qcom/kryo-l2-accessors.c b/drivers/soc/qcom/kryo-l2-accessors.c
new file mode 100644
index 0000000..d35a860
--- /dev/null
+++ b/drivers/soc/qcom/kryo-l2-accessors.c
@@ -0,0 +1,65 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2014-2015, 2018, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/spinlock.h>
+#include <asm/sysreg.h>
+#include <soc/qcom/kryo-l2-accessors.h>
+
+#define L2CPUSRSELR_EL1 sys_reg(3, 3, 15, 0, 6)
+#define L2CPUSRDR_EL1 sys_reg(3, 3, 15, 0, 7)
+
+static DEFINE_RAW_SPINLOCK(l2_access_lock);
+
+/**
+ * kryo_l2_set_indirect_reg() - write value to an L2 register
+ * @reg: Address of L2 register.
+ * @value: Value to be written to register.
+ *
+ * Use architecturally required barriers for ordering between system register
+ * accesses, and system registers with respect to device memory
+ */
+void kryo_l2_set_indirect_reg(u64 reg, u64 val)
+{
+ unsigned long flags;
+
+ raw_spin_lock_irqsave(&l2_access_lock, flags);
+ write_sysreg_s(reg, L2CPUSRSELR_EL1);
+ isb();
+ write_sysreg_s(val, L2CPUSRDR_EL1);
+ isb();
+ raw_spin_unlock_irqrestore(&l2_access_lock, flags);
+}
+EXPORT_SYMBOL(kryo_l2_set_indirect_reg);
+
+/**
+ * kryo_l2_get_indirect_reg() - read an L2 register value
+ * @reg: Address of L2 register.
+ *
+ * Use architecturally required barriers for ordering between system register
+ * accesses, and system registers with respect to device memory
+ */
+u64 kryo_l2_get_indirect_reg(u64 reg)
+{
+ u64 val;
+ unsigned long flags;
+
+ raw_spin_lock_irqsave(&l2_access_lock, flags);
+ write_sysreg_s(reg, L2CPUSRSELR_EL1);
+ isb();
+ val = read_sysreg_s(L2CPUSRDR_EL1);
+ raw_spin_unlock_irqrestore(&l2_access_lock, flags);
+
+ return val;
+}
+EXPORT_SYMBOL(kryo_l2_get_indirect_reg);
diff --git a/include/soc/qcom/kryo-l2-accessors.h b/include/soc/qcom/kryo-l2-accessors.h
new file mode 100644
index 0000000..0840e87
--- /dev/null
+++ b/include/soc/qcom/kryo-l2-accessors.h
@@ -0,0 +1,21 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (c) 2018, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#ifndef __SOC_ARCH_QCOM_KRYO_L2_ACCESSORS_H
+#define __SOC_ARCH_QCOM_KRYO_L2_ACCESSORS_H
+
+void kryo_l2_set_indirect_reg(u64 reg, u64 val);
+u64 kryo_l2_get_indirect_reg(u64 reg);
+
+#endif
--
1.9.1
^ permalink raw reply related
* [PATCH v6 02/14] clk: qcom: Make clk_alpha_pll_configure available to modules
From: Ilia Lin @ 2018-05-14 13:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1526303520-5843-1-git-send-email-ilialin@codeaurora.org>
From: Rajendra Nayak <rnayak@codeaurora.org>
Allow clk_alpha_pll_configure to be called from loadable
kernel modules.
Signed-off-by: Rajendra Nayak <rnayak@codeaurora.org>
Signed-off-by: Ilia Lin <ilialin@codeaurora.org>
---
drivers/clk/qcom/clk-alpha-pll.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/clk/qcom/clk-alpha-pll.c b/drivers/clk/qcom/clk-alpha-pll.c
index 9722b70..57f2084 100644
--- a/drivers/clk/qcom/clk-alpha-pll.c
+++ b/drivers/clk/qcom/clk-alpha-pll.c
@@ -228,6 +228,7 @@ void clk_alpha_pll_configure(struct clk_alpha_pll *pll, struct regmap *regmap,
if (pll->flags & SUPPORTS_FSM_MODE)
qcom_pll_set_fsm_mode(regmap, PLL_MODE(pll), 6, 0);
}
+EXPORT_SYMBOL_GPL(clk_alpha_pll_configure);
static int clk_alpha_pll_hwfsm_enable(struct clk_hw *hw)
{
--
1.9.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox