* Re: [PATCH 1/2] kbuild: change *FLAGS_<basetarget>.o to take the path relative to $(obj)
From: kbuild test robot @ 2019-08-27 1:36 UTC (permalink / raw)
To: Masahiro Yamada
Cc: linux-arm-kernel, x86, Michal Marek, linux-kbuild, Marc Zyngier,
Suzuki K Poulose, Russell King, linux-kernel, Masahiro Yamada,
Ingo Molnar, Borislav Petkov, kbuild-all, Andy Lutomirski,
H. Peter Anvin, James Morse, Thomas Gleixner, kvmarm,
Julien Thierry
In-Reply-To: <20190825172833.5708-1-yamada.masahiro@socionext.com>
[-- Attachment #1: Type: text/plain, Size: 12184 bytes --]
Hi Masahiro,
I love your patch! Yet something to improve:
[auto build test ERROR on linus/master]
[cannot apply to v5.3-rc6 next-20190826]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Masahiro-Yamada/kbuild-change-FLAGS_-basetarget-o-to-take-the-path-relative-to-obj/20190827-071627
config: ia64-allnoconfig (attached as .config)
compiler: ia64-linux-gcc (GCC) 7.4.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=7.4.0 make.cross ARCH=ia64
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot <lkp@intel.com>
All errors (new ones prefixed by >>):
arch/ia64/kernel/efi.o: In function `find_memmap_space':
efi.c:(.text+0x2402): undefined reference to `__udivdi3'
arch/ia64/kernel/time.o: In function `ia64_init_itm':
time.c:(.text+0xa32): undefined reference to `__udivdi3'
time.c:(.text+0xae2): undefined reference to `__udivdi3'
time.c:(.text+0xb62): undefined reference to `__udivdi3'
time.c:(.text+0xd62): undefined reference to `__udivdi3'
arch/ia64/kernel/time.o:time.c:(.text+0xe12): more undefined references to `__udivdi3' follow
kernel/ptrace.o: In function `ptrace_request':
ptrace.c:(.text+0x3262): undefined reference to `__umoddi3'
kernel/sched/core.o: In function `to_ratio':
core.c:(.text+0x2c32): undefined reference to `__udivdi3'
kernel/sched/cputime.o: In function `cputime_adjust':
cputime.c:(.text+0xd72): undefined reference to `__udivdi3'
kernel/sched/fair.o: In function `__calc_delta':
fair.c:(.text+0x362): undefined reference to `__udivdi3'
kernel/time/timekeeping.o: In function `scale64_check_overflow':
timekeeping.c:(.text+0x42): undefined reference to `__umoddi3'
timekeeping.c:(.text+0x62): undefined reference to `__udivdi3'
timekeeping.c:(.text+0x1b2): undefined reference to `__udivdi3'
kernel/time/timekeeping.o: In function `timekeeping_advance':
timekeeping.c:(.text+0x1552): undefined reference to `__udivdi3'
kernel/time/timekeeping.o: In function `tk_setup_internals.constprop.6':
timekeeping.c:(.text+0x19b2): undefined reference to `__udivdi3'
kernel/time/timekeeping.o: In function `get_device_system_crosststamp':
timekeeping.c:(.text+0x3f52): undefined reference to `__umoddi3'
timekeeping.c:(.text+0x3f72): undefined reference to `__udivdi3'
timekeeping.c:(.text+0x3f92): undefined reference to `__udivdi3'
kernel/time/clocksource.o: In function `clocks_calc_mult_shift':
clocksource.c:(.text+0x4b2): undefined reference to `__udivdi3'
kernel/time/clocksource.o: In function `clocks_calc_max_nsecs':
clocksource.c:(.text+0xaa2): undefined reference to `__udivdi3'
kernel/time/clocksource.o: In function `__clocksource_update_freq_scale':
clocksource.c:(.text+0xb72): undefined reference to `__udivdi3'
kernel/time/clocksource.o:clocksource.c:(.text+0xb82): more undefined references to `__udivdi3' follow
mm/percpu.o: In function `pcpu_setup_first_chunk':
>> percpu.c:(.init.text+0xa02): undefined reference to `__moddi3'
>> percpu.c:(.init.text+0xae2): undefined reference to `__udivdi3'
percpu.c:(.init.text+0xb22): undefined reference to `__moddi3'
percpu.c:(.init.text+0xc32): undefined reference to `__udivdi3'
percpu.c:(.init.text+0xc72): undefined reference to `__moddi3'
percpu.c:(.init.text+0xd52): undefined reference to `__udivdi3'
percpu.c:(.init.text+0xd92): undefined reference to `__moddi3'
percpu.c:(.init.text+0xe72): undefined reference to `__udivdi3'
percpu.c:(.init.text+0xeb2): undefined reference to `__moddi3'
percpu.c:(.init.text+0xf92): undefined reference to `__udivdi3'
percpu.c:(.init.text+0xfd2): undefined reference to `__moddi3'
percpu.c:(.init.text+0x10b2): undefined reference to `__udivdi3'
percpu.c:(.init.text+0x1132): undefined reference to `__moddi3'
percpu.c:(.init.text+0x1242): undefined reference to `__udivdi3'
percpu.c:(.init.text+0x12c2): undefined reference to `__moddi3'
percpu.c:(.init.text+0x1672): undefined reference to `__udivdi3'
percpu.c:(.init.text+0x16e2): undefined reference to `__moddi3'
percpu.c:(.init.text+0x1812): undefined reference to `__udivdi3'
percpu.c:(.init.text+0x1882): undefined reference to `__moddi3'
percpu.c:(.init.text+0x1a72): undefined reference to `__udivdi3'
percpu.c:(.init.text+0x1ae2): undefined reference to `__moddi3'
percpu.c:(.init.text+0x1bc2): undefined reference to `__udivdi3'
percpu.c:(.init.text+0x1c32): undefined reference to `__moddi3'
mm/page_alloc.o: In function `setup_per_zone_lowmem_reserve':
page_alloc.c:(.text+0x572): undefined reference to `__udivdi3'
mm/page_alloc.o: In function `__setup_per_zone_wmarks':
page_alloc.c:(.text+0xb42): undefined reference to `__udivdi3'
mm/page_alloc.o: In function `pageset_set_high_and_batch':
page_alloc.c:(.text+0x15e2): undefined reference to `__udivdi3'
mm/page_alloc.o: In function `find_zone_movable_pfns_for_nodes':
page_alloc.c:(.init.text+0x9f2): undefined reference to `__udivdi3'
page_alloc.c:(.init.text+0xa72): undefined reference to `__udivdi3'
mm/page_alloc.o:page_alloc.c:(.init.text+0x2d82): more undefined references to `__udivdi3' follow
mm/dmapool.o: In function `dma_pool_create':
dmapool.c:(.text+0x3e2): undefined reference to `__umoddi3'
mm/mempolicy.o: In function `offset_il_node':
mempolicy.c:(.text+0x412): undefined reference to `__umoddi3'
mm/slub.o: In function `__kmem_cache_create':
slub.c:(.text+0x6ff2): undefined reference to `__udivdi3'
slub.c:(.text+0x7042): undefined reference to `__udivdi3'
slub.c:(.text+0x7302): undefined reference to `__udivdi3'
slub.c:(.text+0x7392): undefined reference to `__udivdi3'
slub.c:(.text+0x7732): undefined reference to `__udivdi3'
slub.c:(.text+0x7752): undefined reference to `__umoddi3'
slub.c:(.text+0x77b2): undefined reference to `__umoddi3'
slub.c:(.text+0x77d2): undefined reference to `__udivdi3'
slub.c:(.text+0x7932): undefined reference to `__umoddi3'
slub.c:(.text+0x7992): undefined reference to `__umoddi3'
slub.c:(.text+0x7a52): undefined reference to `__umoddi3'
slub.c:(.text+0x7ab2): undefined reference to `__umoddi3'
mm/quicklist.o: In function `quicklist_trim':
quicklist.c:(.text+0x142): undefined reference to `__udivdi3'
fs/super.o: In function `super_cache_scan':
super.c:(.text+0x1ca2): undefined reference to `__udivdi3'
super.c:(.text+0x1cc2): undefined reference to `__umoddi3'
super.c:(.text+0x1cf2): undefined reference to `__udivdi3'
super.c:(.text+0x1d42): undefined reference to `__udivdi3'
super.c:(.text+0x1dc2): undefined reference to `__udivdi3'
fs/inode.o: In function `timespec64_trunc':
inode.c:(.text+0x5172): undefined reference to `__moddi3'
fs/inode.o: In function `current_time':
inode.c:(.text+0x52b2): undefined reference to `__moddi3'
lib/bitmap.o: In function `bitmap_remap':
bitmap.c:(.text+0x24c2): undefined reference to `__umoddi3'
lib/bitmap.o: In function `bitmap_bitremap':
bitmap.c:(.text+0x2682): undefined reference to `__moddi3'
lib/bitmap.o: In function `bitmap_fold':
bitmap.c:(.text+0x2982): undefined reference to `__umoddi3'
lib/kfifo.o: In function `kfifo_copy_from_user.isra.1':
kfifo.c:(.text+0x232): undefined reference to `__udivdi3'
kfifo.c:(.text+0x312): undefined reference to `__udivdi3'
lib/kfifo.o: In function `kfifo_copy_to_user.isra.2':
kfifo.c:(.text+0x582): undefined reference to `__udivdi3'
lib/kfifo.o: In function `__kfifo_init':
kfifo.c:(.text+0x1302): undefined reference to `__udivdi3'
lib/kfifo.o: In function `__kfifo_from_user':
kfifo.c:(.text+0x1672): undefined reference to `__udivdi3'
lib/kfifo.o:kfifo.c:(.text+0x17a2): more undefined references to `__udivdi3' follow
lib/string_helpers.o: In function `string_get_size':
string_helpers.c:(.text+0x282): undefined reference to `__umoddi3'
lib/hexdump.o: In function `hex_dump_to_buffer':
hexdump.c:(.text+0x682): undefined reference to `__umoddi3'
hexdump.c:(.text+0x6a2): undefined reference to `__udivdi3'
lib/kstrtox.o: In function `_parse_integer':
kstrtox.c:(.text+0x2e2): undefined reference to `__udivdi3'
lib/math/lcm.o: In function `lcm':
lcm.c:(.text+0x62): undefined reference to `__udivdi3'
lib/math/lcm.o: In function `lcm_not_zero':
lcm.c:(.text+0x122): undefined reference to `__udivdi3'
lib/math/reciprocal_div.o: In function `reciprocal_value':
reciprocal_div.c:(.text+0xd2): undefined reference to `__udivdi3'
lib/math/reciprocal_div.o:reciprocal_div.c:(.text+0x1e2): more undefined references to `__udivdi3' follow
drivers/pci/pci.o: In function `pci_set_cacheline_size':
pci.c:(.text+0xb7e2): undefined reference to `__umoddi3'
drivers/pci/setup-bus.o: In function `pci_bus_distribute_available_resources':
setup-bus.c:(.text+0x1ec2): undefined reference to `__udivdi3'
setup-bus.c:(.text+0x1f42): undefined reference to `__udivdi3'
setup-bus.c:(.text+0x1fc2): undefined reference to `__udivdi3'
setup-bus.c:(.text+0x21a2): undefined reference to `__udivdi3'
setup-bus.c:(.text+0x2212): undefined reference to `__udivdi3'
drivers/pci/setup-bus.o:setup-bus.c:(.text+0x2282): more undefined references to `__udivdi3' follow
drivers/acpi/acpica/exfldio.o: In function `acpi_ex_insert_into_field':
exfldio.c:(.text+0x812): undefined reference to `__umoddi3'
drivers/acpi/acpica/exfldio.o: In function `acpi_ex_extract_from_field':
exfldio.c:(.text+0x1222): undefined reference to `__udivdi3'
exfldio.c:(.text+0x1332): undefined reference to `__udivdi3'
exfldio.c:(.text+0x1362): undefined reference to `__umoddi3'
drivers/acpi/acpica/tbutils.o: In function `acpi_tb_parse_root_table':
tbutils.c:(.init.text+0x462): undefined reference to `__udivdi3'
drivers/acpi/acpica/utmath.o: In function `acpi_ut_short_divide':
utmath.c:(.text+0x152): undefined reference to `__udivdi3'
utmath.c:(.text+0x192): undefined reference to `__umoddi3'
drivers/acpi/acpica/utmath.o: In function `acpi_ut_divide':
utmath.c:(.text+0x262): undefined reference to `__udivdi3'
utmath.c:(.text+0x2a2): undefined reference to `__umoddi3'
drivers/tty/tty_port.o: In function `tty_port_close_start.part.1':
tty_port.c:(.text+0x5a2): undefined reference to `__udivdi3'
drivers/char/random.o: In function `add_device_randomness':
random.c:(.text+0x39d2): undefined reference to `__umoddi3'
drivers/char/random.o: In function `randomize_page':
random.c:(.text+0x4f82): undefined reference to `__umoddi3'
drivers/base/swnode.o: In function `software_node_read_int_array':
swnode.c:(.text+0x12f2): undefined reference to `__udivdi3'
drivers/firmware/efi/memmap.o: In function `__efi_memmap_init':
>> memmap.c:(.init.text+0x112): undefined reference to `__udivdi3'
arch/ia64/hp/common/sba_iommu.o: In function `sba_init':
sba_iommu.c:(.init.text+0x982): undefined reference to `__udivdi3'
arch/ia64/sn/kernel/bte.o: In function `bte_copy':
bte.c:(.text+0x3b2): undefined reference to `__moddi3'
arch/ia64/sn/pci/tioca_provider.o: In function `tioca_bus_fixup':
tioca_provider.c:(.text+0x662): undefined reference to `__udivdi3'
tioca_provider.c:(.text+0x772): undefined reference to `__udivdi3'
tioca_provider.c:(.text+0xab2): undefined reference to `__udivdi3'
arch/ia64/sn/pci/tioca_provider.o: In function `tioca_dma_map':
tioca_provider.c:(.text+0x1392): undefined reference to `__umoddi3'
lib/nodemask.o: In function `node_random':
nodemask.c:(.text+0x102): undefined reference to `__umoddi3'
lib/vsprintf.o: In function `vsscanf':
vsprintf.c:(.text+0xac62): undefined reference to `__udivdi3'
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 6360 bytes --]
[-- Attachment #3: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 4/5] perf symbols: Use CAP_SYSLOG with kptr_restrict checks
From: Igor Lubashev @ 2019-08-27 1:39 UTC (permalink / raw)
To: Jiri Olsa, Arnaldo Carvalho de Melo, Mathieu Poirier
Cc: Suzuki Poulouse, Alexander Shishkin, Alexey Budankov,
Igor Lubashev, James Morris, Linux Kernel Mailing List,
Peter Zijlstra, Namhyung Kim, linux-arm-kernel
In-Reply-To: <1566869956-7154-1-git-send-email-ilubashe@akamai.com>
The kernel is using CAP_SYSLOG capability instead of uid==0 and euid==0
when checking kptr_restrict. Make perf do the same.
Also, the kernel is a more restrictive than "no restrictions" in case of
kptr_restrict==0, so add the same logic to perf.
Signed-off-by: Igor Lubashev <ilubashe@akamai.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Alexey Budankov <alexey.budankov@linux.intel.com>
Cc: James Morris <jmorris@namei.org>
Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Suzuki Poulouse <suzuki.poulose@arm.com>
Cc: linux-arm-kernel@lists.infradead.org
Link: http://lkml.kernel.org/r/291d2cda6ee75b4cd4c9ce717c177db18bf03a31.1565188228.git.ilubashe@akamai.com
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
---
tools/perf/util/symbol.c | 15 ++++++++++++---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/tools/perf/util/symbol.c b/tools/perf/util/symbol.c
index 4efde7879474..035f2e75728c 100644
--- a/tools/perf/util/symbol.c
+++ b/tools/perf/util/symbol.c
@@ -4,6 +4,7 @@
#include <stdlib.h>
#include <stdio.h>
#include <string.h>
+#include <linux/capability.h>
#include <linux/kernel.h>
#include <linux/mman.h>
#include <linux/time64.h>
@@ -15,8 +16,10 @@
#include <inttypes.h>
#include "annotate.h"
#include "build-id.h"
+#include "cap.h"
#include "util.h"
#include "debug.h"
+#include "event.h"
#include "machine.h"
#include "map.h"
#include "symbol.h"
@@ -2195,13 +2198,19 @@ static bool symbol__read_kptr_restrict(void)
char line[8];
if (fgets(line, sizeof(line), fp) != NULL)
- value = ((geteuid() != 0) || (getuid() != 0)) ?
- (atoi(line) != 0) :
- (atoi(line) == 2);
+ value = perf_cap__capable(CAP_SYSLOG) ?
+ (atoi(line) >= 2) :
+ (atoi(line) != 0);
fclose(fp);
}
+ /* Per kernel/kallsyms.c:
+ * we also restrict when perf_event_paranoid > 1 w/o CAP_SYSLOG
+ */
+ if (perf_event_paranoid() > 1 && !perf_cap__capable(CAP_SYSLOG))
+ value = true;
+
return value;
}
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 2/5] perf tools: Use CAP_SYS_ADMIN with perf_event_paranoid checks
From: Igor Lubashev @ 2019-08-27 1:39 UTC (permalink / raw)
To: Jiri Olsa, Arnaldo Carvalho de Melo, Mathieu Poirier
Cc: Suzuki Poulouse, Alexander Shishkin, Alexey Budankov,
Igor Lubashev, James Morris, Linux Kernel Mailing List,
Peter Zijlstra, Namhyung Kim, linux-arm-kernel
In-Reply-To: <1566869956-7154-1-git-send-email-ilubashe@akamai.com>
The kernel is using CAP_SYS_ADMIN instead of euid==0 to override
perf_event_paranoid check. Make perf do the same.
Signed-off-by: Igor Lubashev <ilubashe@akamai.com>
Acked-by: Jiri Olsa <jolsa@kernel.org>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Alexey Budankov <alexey.budankov@linux.intel.com>
Cc: James Morris <jmorris@namei.org>
Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Suzuki Poulouse <suzuki.poulose@arm.com>
Cc: linux-arm-kernel@lists.infradead.org
Link: http://lkml.kernel.org/r/ad56df5452eeafb99dda9fc3d30f0f487aace503.1565188228.git.ilubashe@akamai.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
---
tools/perf/arch/arm/util/cs-etm.c | 3 ++-
tools/perf/arch/arm64/util/arm-spe.c | 3 ++-
tools/perf/arch/x86/util/intel-bts.c | 3 ++-
tools/perf/arch/x86/util/intel-pt.c | 2 +-
tools/perf/util/evsel.c | 2 +-
5 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/tools/perf/arch/arm/util/cs-etm.c b/tools/perf/arch/arm/util/cs-etm.c
index 5cb07e8cb296..b87a1ca2968f 100644
--- a/tools/perf/arch/arm/util/cs-etm.c
+++ b/tools/perf/arch/arm/util/cs-etm.c
@@ -18,6 +18,7 @@
#include "../../perf.h"
#include "../../util/auxtrace.h"
#include "../../util/cpumap.h"
+#include "../../util/event.h"
#include "../../util/evlist.h"
#include "../../util/evsel.h"
#include "../../util/pmu.h"
@@ -254,7 +255,7 @@ static int cs_etm_recording_options(struct auxtrace_record *itr,
struct perf_pmu *cs_etm_pmu = ptr->cs_etm_pmu;
struct evsel *evsel, *cs_etm_evsel = NULL;
struct perf_cpu_map *cpus = evlist->core.cpus;
- bool privileged = (geteuid() == 0 || perf_event_paranoid() < 0);
+ bool privileged = perf_event_paranoid_check(-1);
int err = 0;
ptr->evlist = evlist;
diff --git a/tools/perf/arch/arm64/util/arm-spe.c b/tools/perf/arch/arm64/util/arm-spe.c
index 00915b8fd05b..29275a0544cd 100644
--- a/tools/perf/arch/arm64/util/arm-spe.c
+++ b/tools/perf/arch/arm64/util/arm-spe.c
@@ -12,6 +12,7 @@
#include <time.h>
#include "../../util/cpumap.h"
+#include "../../util/event.h"
#include "../../util/evsel.h"
#include "../../util/evlist.h"
#include "../../util/session.h"
@@ -66,7 +67,7 @@ static int arm_spe_recording_options(struct auxtrace_record *itr,
container_of(itr, struct arm_spe_recording, itr);
struct perf_pmu *arm_spe_pmu = sper->arm_spe_pmu;
struct evsel *evsel, *arm_spe_evsel = NULL;
- bool privileged = geteuid() == 0 || perf_event_paranoid() < 0;
+ bool privileged = perf_event_paranoid_check(-1);
struct evsel *tracking_evsel;
int err;
diff --git a/tools/perf/arch/x86/util/intel-bts.c b/tools/perf/arch/x86/util/intel-bts.c
index 7b23318ebd7b..56a76142e9fd 100644
--- a/tools/perf/arch/x86/util/intel-bts.c
+++ b/tools/perf/arch/x86/util/intel-bts.c
@@ -12,6 +12,7 @@
#include <linux/zalloc.h>
#include "../../util/cpumap.h"
+#include "../../util/event.h"
#include "../../util/evsel.h"
#include "../../util/evlist.h"
#include "../../util/session.h"
@@ -107,7 +108,7 @@ static int intel_bts_recording_options(struct auxtrace_record *itr,
struct perf_pmu *intel_bts_pmu = btsr->intel_bts_pmu;
struct evsel *evsel, *intel_bts_evsel = NULL;
const struct perf_cpu_map *cpus = evlist->core.cpus;
- bool privileged = geteuid() == 0 || perf_event_paranoid() < 0;
+ bool privileged = perf_event_paranoid_check(-1);
btsr->evlist = evlist;
btsr->snapshot_mode = opts->auxtrace_snapshot_mode;
diff --git a/tools/perf/arch/x86/util/intel-pt.c b/tools/perf/arch/x86/util/intel-pt.c
index a8e633aa278a..7abccc0b0dc0 100644
--- a/tools/perf/arch/x86/util/intel-pt.c
+++ b/tools/perf/arch/x86/util/intel-pt.c
@@ -578,7 +578,7 @@ static int intel_pt_recording_options(struct auxtrace_record *itr,
bool have_timing_info, need_immediate = false;
struct evsel *evsel, *intel_pt_evsel = NULL;
const struct perf_cpu_map *cpus = evlist->core.cpus;
- bool privileged = geteuid() == 0 || perf_event_paranoid() < 0;
+ bool privileged = perf_event_paranoid_check(-1);
u64 tsc_bit;
int err;
diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c
index 0a33f7322ecc..0b3b5af33954 100644
--- a/tools/perf/util/evsel.c
+++ b/tools/perf/util/evsel.c
@@ -279,7 +279,7 @@ struct evsel *perf_evsel__new_idx(struct perf_event_attr *attr, int idx)
static bool perf_event_can_profile_kernel(void)
{
- return geteuid() == 0 || perf_event_paranoid() == -1;
+ return perf_event_paranoid_check(-1);
}
struct evsel *perf_evsel__new_cycles(bool precise)
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 3/5] perf util: kernel profiling is disallowed only when perf_event_paranoid > 1
From: Igor Lubashev @ 2019-08-27 1:39 UTC (permalink / raw)
To: Jiri Olsa, Arnaldo Carvalho de Melo, Mathieu Poirier
Cc: Suzuki Poulouse, Alexander Shishkin, Alexey Budankov,
Igor Lubashev, James Morris, Linux Kernel Mailing List,
Peter Zijlstra, Namhyung Kim, linux-arm-kernel
In-Reply-To: <1566869956-7154-1-git-send-email-ilubashe@akamai.com>
Perf was too restrictive about sysctl kernel.perf_event_paranoid. The
kernel only disallows profiling when perf_event_paranoid > 1. Make perf do
the same.
Signed-off-by: Igor Lubashev <ilubashe@akamai.com>
---
tools/perf/util/evsel.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c
index 0b3b5af33954..bfe6ed2abcc2 100644
--- a/tools/perf/util/evsel.c
+++ b/tools/perf/util/evsel.c
@@ -279,7 +279,7 @@ struct evsel *perf_evsel__new_idx(struct perf_event_attr *attr, int idx)
static bool perf_event_can_profile_kernel(void)
{
- return perf_event_paranoid_check(-1);
+ return perf_event_paranoid_check(1);
}
struct evsel *perf_evsel__new_cycles(bool precise)
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 1/5] perf event: Check ref_reloc_sym before using it
From: Igor Lubashev @ 2019-08-27 1:39 UTC (permalink / raw)
To: Jiri Olsa, Arnaldo Carvalho de Melo, Mathieu Poirier
Cc: Suzuki Poulouse, Alexander Shishkin, Alexey Budankov,
Igor Lubashev, James Morris, Linux Kernel Mailing List,
Peter Zijlstra, Namhyung Kim, linux-arm-kernel
In-Reply-To: <1566869956-7154-1-git-send-email-ilubashe@akamai.com>
Check for ref_reloc_sym before using it instead of checking
symbol_conf.kptr_restrict and relying solely on that check.
Signed-off-by: Igor Lubashev <ilubashe@akamai.com>
Reported-by: Mathieu Poirier <mathieu.poirier@linaro.org>
---
tools/perf/util/event.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/tools/perf/util/event.c b/tools/perf/util/event.c
index f440fdc3e953..b84f5f3c9651 100644
--- a/tools/perf/util/event.c
+++ b/tools/perf/util/event.c
@@ -913,11 +913,13 @@ static int __perf_event__synthesize_kernel_mmap(struct perf_tool *tool,
int err;
union perf_event *event;
- if (symbol_conf.kptr_restrict)
- return -1;
if (map == NULL)
return -1;
+ kmap = map__kmap(map);
+ if (!kmap->ref_reloc_sym)
+ return -1;
+
/*
* We should get this from /sys/kernel/sections/.text, but till that is
* available use this, and after it is use this as a fallback for older
@@ -940,7 +942,6 @@ static int __perf_event__synthesize_kernel_mmap(struct perf_tool *tool,
event->header.misc = PERF_RECORD_MISC_GUEST_KERNEL;
}
- kmap = map__kmap(map);
size = snprintf(event->mmap.filename, sizeof(event->mmap.filename),
"%s%s", machine->mmap_name, kmap->ref_reloc_sym->name) + 1;
size = PERF_ALIGN(size, sizeof(u64));
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 5/5] perf: warn that perf_event_paranoid can restrict kernel symbols
From: Igor Lubashev @ 2019-08-27 1:39 UTC (permalink / raw)
To: Jiri Olsa, Arnaldo Carvalho de Melo, Mathieu Poirier
Cc: Suzuki Poulouse, Alexander Shishkin, Alexey Budankov,
Igor Lubashev, James Morris, Linux Kernel Mailing List,
Peter Zijlstra, Namhyung Kim, linux-arm-kernel
In-Reply-To: <1566869956-7154-1-git-send-email-ilubashe@akamai.com>
Warn that /proc/sys/kernel/perf_event_paranoid can also restrict kernel
symbols.
Signed-off-by: Igor Lubashev <ilubashe@akamai.com>
---
tools/perf/builtin-record.c | 2 +-
tools/perf/builtin-top.c | 2 +-
tools/perf/builtin-trace.c | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
index f71631f2bcb5..18505d92ff69 100644
--- a/tools/perf/builtin-record.c
+++ b/tools/perf/builtin-record.c
@@ -2372,7 +2372,7 @@ int cmd_record(int argc, const char **argv)
if (symbol_conf.kptr_restrict && !perf_evlist__exclude_kernel(rec->evlist))
pr_warning(
"WARNING: Kernel address maps (/proc/{kallsyms,modules}) are restricted,\n"
-"check /proc/sys/kernel/kptr_restrict.\n\n"
+"check /proc/sys/kernel/kptr_restrict and /proc/sys/kernel/perf_event_paranoid.\n\n"
"Samples in kernel functions may not be resolved if a suitable vmlinux\n"
"file is not found in the buildid cache or in the vmlinux path.\n\n"
"Samples in kernel modules won't be resolved at all.\n\n"
diff --git a/tools/perf/builtin-top.c b/tools/perf/builtin-top.c
index 5970723cd55a..29e910fb2d9a 100644
--- a/tools/perf/builtin-top.c
+++ b/tools/perf/builtin-top.c
@@ -770,7 +770,7 @@ static void perf_event__process_sample(struct perf_tool *tool,
if (!perf_evlist__exclude_kernel(top->session->evlist)) {
ui__warning(
"Kernel address maps (/proc/{kallsyms,modules}) are restricted.\n\n"
-"Check /proc/sys/kernel/kptr_restrict.\n\n"
+"Check /proc/sys/kernel/kptr_restrict and /proc/sys/kernel/perf_event_paranoid.\n\n"
"Kernel%s samples will not be resolved.\n",
al.map && map__has_symbols(al.map) ?
" modules" : "");
diff --git a/tools/perf/builtin-trace.c b/tools/perf/builtin-trace.c
index bc44ed29e05a..9443b8e05810 100644
--- a/tools/perf/builtin-trace.c
+++ b/tools/perf/builtin-trace.c
@@ -1381,7 +1381,7 @@ static char *trace__machine__resolve_kernel_addr(void *vmachine, unsigned long l
if (symbol_conf.kptr_restrict) {
pr_warning("Kernel address maps (/proc/{kallsyms,modules}) are restricted.\n\n"
- "Check /proc/sys/kernel/kptr_restrict.\n\n"
+ "Check /proc/sys/kernel/kptr_restrict and /proc/sys/kernel/perf_event_paranoid.\n\n"
"Kernel samples will not be resolved.\n");
machine->kptr_restrict_warned = true;
return NULL;
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 0/5] perf: Treat perf_event_paranoid and kptr_restrict like the kernel does it
From: Igor Lubashev @ 2019-08-27 1:39 UTC (permalink / raw)
To: Jiri Olsa, Arnaldo Carvalho de Melo, Mathieu Poirier
Cc: Suzuki Poulouse, Alexander Shishkin, Alexey Budankov,
Igor Lubashev, James Morris, Linux Kernel Mailing List,
Peter Zijlstra, Namhyung Kim, linux-arm-kernel
This is a follow up series to the ensure perf treats perf_event_paranoid and
kptr_restrict in a way that is similar to the kernel's. That includes use of
capabilities instead of euid==0, when possible, as well as adjusting the logic
and fixing bugs.
Prior discussion: https://lkml.kernel.org/lkml/cover.1565188228.git.ilubashe@akamai.com
=== Testing notes ===
I have tested on x86 with perf binary installed according to
Documentation/admin-guide/perf-security.rst (cap_sys_admin, cap_sys_ptrace,
cap_syslog assigned to the perf executable).
I tested each permutation of:
* 7 commits:
1. HEAD of perf/core
2. patch 01 on top of perf/core
3. patches 01-02 on top of perf/core
4. patches 01-03 on top of perf/core
5. patches 01-04 on top of perf/core
6. patches 01-05 on top of perf/core
7. HEAD of perf/cap (with known bug fixed by patch 01 of this series)
* 2 build environments: with and without libcap-dev
* 3 kernel.kptr_restrict values: 0, 1, 2
* 4 kernel.perf_event_paranoid values: -1, 0, 1, 2
* 2 users: root and non-root
Total: 336 permutations
Each permutation consisted of:
perf test
perf record -e instructions -- sleep 1
All test runs were expected. Also, as expected, the following permutation (just
that permutation) resulted in segmentation failure:
commit: perf/cap
build: no libcap-dev
kernel.kptr_restrict: 0
kernel.perf_event_paranoid: 2
user: non-root
The perf/cap commit was included in the test to ensure that we can reproduce the
crash and hence test that the patch series fixes the crash, while retaining the
desired behavior of perf/cap.
=== Series Contents ===
01: perf event: Check ref_reloc_sym before using it
Fix the pre-existing cause of the crash above: use of ref_reloc_sym without
a check for NULL
02: perf tools: Use CAP_SYS_ADMIN with perf_event_paranoid checks
Replace the use of euid==0 with a check for CAP_SYS_ADMIN whenever
perf_event_paranoid level is verified.
* This patch has been reviewed previously and is unchanged.
* I kept Acks and Sign-offs.
03: perf util: kernel profiling is disallowed only when perf_event_paranoid>1
Align perf logic regarding perf_event_paranoid to match kernel's.
This has been reported by Arnaldo.
04: perf symbols: Use CAP_SYSLOG with kptr_restrict checks
Replace the use of uid and euid with a check for CAP_SYSLOG when
kptr_restrict is verified (similar to kernel/kallsyms.c and lib/vsprintf.c).
Consult perf_event_paranoid when kptr_restrict==0 (see kernel/kallsyms.c).
* A previous version of this patch has been reviewed previously, but I
* modified it in a non-trivial way, so I removed Acks.
05: perf: warn perf_event_paranoid restrict kernel symbols
Warn that /proc/sys/kernel/perf_event_paranoid can also restrict kernel
symbols.
Igor Lubashev (5):
perf event: Check ref_reloc_sym before using it
perf tools: Use CAP_SYS_ADMIN with perf_event_paranoid checks
perf util: kernel profiling is disallowed only when perf_event_paranoid > 1
perf symbols: Use CAP_SYSLOG with kptr_restrict checks
perf: warn that perf_event_paranoid can restrict kernel symbols
tools/perf/arch/arm/util/cs-etm.c | 3 ++-
tools/perf/arch/arm64/util/arm-spe.c | 3 ++-
tools/perf/arch/x86/util/intel-bts.c | 3 ++-
tools/perf/arch/x86/util/intel-pt.c | 2 +-
tools/perf/builtin-record.c | 2 +-
tools/perf/builtin-top.c | 2 +-
tools/perf/builtin-trace.c | 2 +-
tools/perf/util/event.c | 7 ++++---
tools/perf/util/evsel.c | 2 +-
tools/perf/util/symbol.c | 15 ++++++++++++---
10 files changed, 27 insertions(+), 14 deletions(-)
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: CPUfreq fail on rk3399-firefly
From: Kever Yang @ 2019-08-27 1:54 UTC (permalink / raw)
To: Kevin Hilman, Heiko Stuebner
Cc: kernel-build-reports, linux-rockchip, linux-next,
闫孝军, 张晴, linux-arm-kernel
In-Reply-To: <7h4l23zwej.fsf@baylibre.com>
On 2019/8/27 上午1:09, Kevin Hilman wrote:
> Hi Kever,
>
> Kever Yang <kever.yang@rock-chips.com> writes:
>
>> Hi Kevin,
>>
>> I want to have a test with my board, I can get the Image and dtb
>> from the link for the job,
>>
>> but how can I get the randisk which is named initrd-SDbyy2.cpio.gz?
> The ramdisk images are here:
>
> https://storage.kernelci.org/images/rootfs/buildroot/kci-2019.02/arm64/base/
>
> in the kernelCI logs the ramdisk is slightly modified because the kernel
> modules have been inserted into the cpio archive.
>
> However, for the purposes of this test, you can just test with the
> unmodified rootfs.cpio.gz above.
I try with this ramdisk, and it hangs at fan53555 init, but not get into
cpufreq.
Any suggestion?
My boot log:
https://paste.ubuntu.com/p/WYZKPWp7sk/
Thanks,
- Kever
>
> Kevin
>
>
>> Thanks,
>>
>> - Kever
>>
>> On 2019/8/24 上午1:03, Kevin Hilman wrote:
>>> Kevin Hilman <khilman@baylibre.com> writes:
>>>
>>>> Kever Yang <kever.yang@rock-chips.com> writes:
>>>>
>>>>> Hi Kevin, Heiko,
>>>>>
>>>>> On 2019/8/22 上午2:59, Kevin Hilman wrote:
>>>>>> Hi Heiko,
>>>>>>
>>>>>> Heiko Stuebner <heiko@sntech.de> writes:
>>>>>>
>>>>>>> Am Dienstag, 13. August 2019, 19:35:31 CEST schrieb Kevin Hilman:
>>>>>>>> [ resent with correct addr for linux-rockchip list ]
>>>>>>>>
>>>>>>>> Mark Brown <broonie@kernel.org> writes:
>>>>>>>>
>>>>>>>>> On Thu, Jul 18, 2019 at 04:28:08AM -0700, kernelci.org bot wrote:
>>>>>>>>>
>>>>>>>>> Today's -next started failing to boot defconfig on rk3399-firefly:
>>>>>>>>>
>>>>>>>>>> arm64:
>>>>>>>>>> defconfig:
>>>>>>>>>> gcc-8:
>>>>>>>>>> rk3399-firefly: 1 failed lab
>>>>>>>>> It hits a BUG() trying to set up cpufreq:
>>>>>>>>>
>>>>>>>>> [ 87.381606] cpufreq: cpufreq_online: CPU0: Running at unlisted freq: 200000 KHz
>>>>>>>>> [ 87.393244] cpufreq: cpufreq_online: CPU0: Unlisted initial frequency changed to: 408000 KHz
>>>>>>>>> [ 87.469777] cpufreq: cpufreq_online: CPU4: Running at unlisted freq: 12000 KHz
>>>>>>>>> [ 87.488595] cpu cpu4: _generic_set_opp_clk_only: failed to set clock rate: -22
>>>>>>>>> [ 87.491881] cpufreq: __target_index: Failed to change cpu frequency: -22
>>>>>>>>> [ 87.495335] ------------[ cut here ]------------
>>>>>>>>> [ 87.496821] kernel BUG at drivers/cpufreq/cpufreq.c:1438!
>>>>>>>>> [ 87.498462] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
>>>>>>>>>
>>>>>>>>> I'm struggling to see anything relevant in the diff from yesterday, the
>>>>>>>>> unlisted frequency warnings were there in the logs yesterday but no oops
>>>>>>>>> and I'm not seeing any changes in cpufreq, clk or anything relevant
>>>>>>>>> looking.
>>>>>>>>>
>>>>>>>>> Full bootlog and other info can be found here:
>>>>>>>>>
>>>>>>>>> https://kernelci.org/boot/id/5d302d8359b51498d049e983/
>>>>>>>> I confirm that disabling CPUfreq in the defconfig (CONFIG_CPU_FREQ=n)
>>>>>>>> makes the firefly board start working again.
>>>>>>>>
>>>>>>>> Note that the default defconfig enables the "performance" CPUfreq
>>>>>>>> governor as the default governor, so during kernel boot, it will always
>>>>>>>> switch to the max frequency.
>>>>>>>>
>>>>>>>> For fun, I set the default governor to "userspace" so the kernel
>>>>>>>> wouldn't make any OPP changes, and that leads to a slightly more
>>>>>>>> informative splat[1]
>>>>>>>>
>>>>>>>> There is still an OPP change happening because the detected OPP is not
>>>>>>>> one that's listed in the table, so it tries to change to a listed OPP
>>>>>>>> and fails in the bowels of clk_set_rate()
>>>>>>> Though I think that might only be a symptom as well.
>>>>>>> Both the PLL setting code as well as the actual cpu-clock implementation
>>>>>>> is unchanged since 2017 (and runs just fine on all boards in my farm).
>>>>>>>
>>>>>>> One source for these issues is often the regulator supplying the cpu
>>>>>>> going haywire - aka the voltage not matching the opp.
>>>>>>>
>>>>>>> As in this error-case it's CPU4 being set, this would mean it might
>>>>>>> be the big cluster supplied by the external syr825 (fan5355 clone)
>>>>>>> that might act up. In the Firefly-rk3399 case this is even stranger.
>>>>>>>
>>>>>>> There is a discrepancy between the "fcs,suspend-voltage-selector"
>>>>>>> between different bootloader versions (how the selection-pin is set up),
>>>>>>> so the kernel might actually write his requested voltage to the wrong
>>>>>>> register (not the one for actual voltage, but the second set used for
>>>>>>> the suspend voltage).
>>>>>>>
>>>>>>> Did you by chance swap bootloaders at some point in recent past?
>>>>>> No, haven't touched bootloader since I initially setup the board.
>>>>> The CPU voltage does not affect by bootloader for kernel should have its
>>>>> own opp-table,
>>>>>
>>>>> the bootloader may only affect the center/logic power supply.
>>>>>
>>>>>>> I'd assume [2] might actually be the same issue last year, though
>>>>>>> the CI-logs are not available anymore it seems.
>>>>>>>
>>>>>>> Could you try to set the vdd_cpu_b regulator to disabled, so that
>>>>>>> cpufreq for this cluster defers and see what happens?
>>>>>> Yes, this change[1] definitely makes things boot reliably again, so
>>>>>> there's defintiely something a bit unstable with this regulator, at
>>>>>> least on this firefly.
>>>>> Is it possible to target which patch introduce this bug? This board
>>>>> should have work correctly for a long time with upstream source code.
>>>> Unfortunately, it seems to be a regular, but intermittent failure, so
>>>> bisection is not producing anything reliable.
>>>>
>>>> You can see that both in mainline[1] and in linux-next[2] there are
>>>> periodic failures, but it's hard to see any patterns.
>>> Even worse, I (re)tested mainline for versions that were previously
>>> passing (v5.2, v5.3-rc5) and they are also failing now.
>>>
>>> They work again if I disable that regulator as suggested by Heiko.
>>>
>>> So this is increasingly pointing to failing hardware.
>>>
>>> Kevin
>>>
>>>
>>>
>
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* RE: [PATCH v3 3/4] perf: Use CAP_SYSLOG with kptr_restrict checks
From: Lubashev, Igor @ 2019-08-27 1:58 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo, Mathieu Poirier
Cc: Suzuki K Poulose, Peter Zijlstra, Alexey Budankov,
Linux Kernel Mailing List, Alexander Shishkin, Ingo Molnar,
Leo Yan, Namhyung Kim, Jiri Olsa, linux-arm-kernel
In-Reply-To: <20190820171342.GD3929@kernel.org>
On Tue, August 20, 2019 at 1:14 PM Arnaldo Carvalho de Melo <arnaldo.melo@gmail.com> wrote:
> > Arnaldo, once we decide what the right fix is, I am happy to post the
> update (options 1, 1+2) as a patch series.
>
> I think you should get the checks for ref_reloc_sym in place so as to make the
> code overall more robust, and also go on continuing to make the checks in
> tools/perf/ to match what is checked on the other side of the mirror, i.e. by
> the kernel, so from a quick read, please put first the robustness patches
> (check ref_reloc_sym) do your other suggestions and update the warnings,
> then refresh the two patches that still are not in my perf/core branch:
>
> [acme@quaco perf]$ git rebase perf/core
> First, rewinding head to replay your work on top of it...
> Applying: perf tools: Use CAP_SYS_ADMIN with perf_event_paranoid checks
> Applying: perf symbols: Use CAP_SYSLOG with kptr_restrict checks
> [acme@quaco perf]$
>
> I've pushed out perf/cap, so you can go from there as it is rebased on my
> current perf/core.
>
> Then test all these cases: with/without libcap, with euid==0 and different
> than zero, with capabilities, etc, patch by patch so that we don't break
> bisection nor regress,
All done. I've posted the update as a new follow-up series: https://lkml.kernel.org/lkml/1566869956-7154-1-git-send-email-ilubashe@akamai.com/ rebased on your perf/core.
I've tested 336 permutations (see the new cover). In particular, I was able to reproduce the crash on perf/cap and confirm that no permutation can cause such crashes for any of the patches in the series.
> Thanks and keep up the good work!
>
> - Arnaldo
- Igor
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: swiotlb-xen cleanups
From: Stefano Stabellini @ 2019-08-27 2:00 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Stefano Stabellini, Konrad Rzeszutek Wilk, x86, linux-kernel,
iommu, xen-devel, linux-arm-kernel
In-Reply-To: <20190816130013.31154-1-hch@lst.de>
On Fri, 16 Aug 2019, Christoph Hellwig wrote:
> Hi Xen maintainers and friends,
>
> please take a look at this series that cleans up the parts of swiotlb-xen
> that deal with non-coherent caches.
Hi Christoph,
I just wanted to let you know that your series is on my radar, but I
have been swamped the last few days. I hope to get to it by the end of
the week.
Cheers,
Stefano
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] kvm/arm/vgic: fix potential deadlock when ap_list is long
From: Guoheyi @ 2019-08-27 2:08 UTC (permalink / raw)
To: linux-arm-kernel, kvmarm, linux-kernel
Cc: Suzuki K Poulose, Marc Zyngier, James Morse, Zenghui Yu,
wanghaibin.wang, Julien Thierry
In-Reply-To: <1566837552-127854-1-git-send-email-guoheyi@huawei.com>
On 2019/8/27 0:39, Heyi Guo wrote:
> If ap_list is longer than 256, merge_final() in sort_list() will call
> comparison function with the same element just as below:
>
> do {
> /*
> * If the merge is highly unbalanced (e.g. the input is
> * already sorted), this loop may run many iterations.
> * Continue callbacks to the client even though no
> * element comparison is needed, so the client's cmp()
> * routine can invoke cond_resched() periodically.
> */
> if (unlikely(!++count))
> cmp(priv, b, b);
>
> This will definitely cause deadlock in vgic_irq_cmp() and the call trace
> is:
>
> [ 2667.130283] Call trace:
> [ 2667.130284] queued_spin_lock_slowpath+0x64/0x2a8
> [ 2667.130284] vgic_irq_cmp+0xfc/0x130
> [ 2667.130284] list_sort.part.0+0x1c0/0x268
> [ 2667.130285] list_sort+0x18/0x28
> [ 2667.130285] vgic_flush_lr_state+0x158/0x518
> [ 2667.130285] kvm_vgic_flush_hwstate+0x70/0x108
> [ 2667.130286] kvm_arch_vcpu_ioctl_run+0x114/0xa50
> [ 2667.130286] kvm_vcpu_ioctl+0x490/0x8c8
> [ 2667.130286] do_vfs_ioctl+0xc4/0x8c0
> [ 2667.130287] ksys_ioctl+0x8c/0xa0
> [ 2667.130287] __arm64_sys_ioctl+0x28/0x38
> [ 2667.130287] el0_svc_common+0x78/0x130
> [ 2667.130288] el0_svc_handler+0x38/0x78
> [ 2667.130288] el0_svc+0x8/0xc
>
> So return 0 immediately when a==b.
>
> Signed-off-by: Zenghui Yu <yuzenghui@huawei.com>
> Signed-off-by: Heyi Guo <guoheyi@huawei.com>
> Cc: Marc Zyngier <maz@kernel.org>
> Cc: James Morse <james.morse@arm.com>
> Cc: Julien Thierry <julien.thierry.kdev@gmail.com>
> Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
> ---
> virt/kvm/arm/vgic/vgic.c | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/virt/kvm/arm/vgic/vgic.c b/virt/kvm/arm/vgic/vgic.c
> index 13d4b38..64ed0dc 100644
> --- a/virt/kvm/arm/vgic/vgic.c
> +++ b/virt/kvm/arm/vgic/vgic.c
> @@ -254,6 +254,13 @@ static int vgic_irq_cmp(void *priv, struct list_head *a, struct list_head *b)
> bool penda, pendb;
> int ret;
>
> + /*
> + * list_sort may call this function with the same element when the list
> + * is farely long.
Sorry, s/farely/fairly/ :)
HG
> + */
> + if (unlikely(a == b))
> + return 0;
> +
> raw_spin_lock(&irqa->irq_lock);
> raw_spin_lock_nested(&irqb->irq_lock, SINGLE_DEPTH_NESTING);
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: CPUfreq fail on rk3399-firefly
From: Heiko Stuebner @ 2019-08-27 2:14 UTC (permalink / raw)
To: Kever Yang
Cc: kernel-build-reports, Kevin Hilman, linux-rockchip, linux-next,
闫孝军, 张晴, linux-arm-kernel
In-Reply-To: <852dd7d4-520b-7eb0-f307-c3fa9c0ebf2a@rock-chips.com>
Hi Kever,
Am Dienstag, 27. August 2019, 03:54:26 CEST schrieb Kever Yang:
> On 2019/8/27 上午1:09, Kevin Hilman wrote:
> > Kever Yang <kever.yang@rock-chips.com> writes:
> >> I want to have a test with my board, I can get the Image and dtb
> >> from the link for the job,
> >>
> >> but how can I get the randisk which is named initrd-SDbyy2.cpio.gz?
> > The ramdisk images are here:
> >
> > https://storage.kernelci.org/images/rootfs/buildroot/kci-2019.02/arm64/base/
> >
> > in the kernelCI logs the ramdisk is slightly modified because the kernel
> > modules have been inserted into the cpio archive.
> >
> > However, for the purposes of this test, you can just test with the
> > unmodified rootfs.cpio.gz above.
>
>
> I try with this ramdisk, and it hangs at fan53555 init, but not get into
> cpufreq.
>
> Any suggestion?
My guess would be the fcs,suspend-voltage-selector maybe?
I.e. old uboots somehow set the voltage gpio strangely, so you'd need
fcs,suspend-voltage-selector = <0>
while newer uboots I think do configure the gpio, needing a value of <1>;
So try to swap that number in the dts perhaps for a start?
Heiko
> My boot log:
>
> https://paste.ubuntu.com/p/WYZKPWp7sk/
>
> Thanks,
>
> - Kever
>
> >
> > Kevin
> >
> >
> >> Thanks,
> >>
> >> - Kever
> >>
> >> On 2019/8/24 上午1:03, Kevin Hilman wrote:
> >>> Kevin Hilman <khilman@baylibre.com> writes:
> >>>
> >>>> Kever Yang <kever.yang@rock-chips.com> writes:
> >>>>
> >>>>> Hi Kevin, Heiko,
> >>>>>
> >>>>> On 2019/8/22 上午2:59, Kevin Hilman wrote:
> >>>>>> Hi Heiko,
> >>>>>>
> >>>>>> Heiko Stuebner <heiko@sntech.de> writes:
> >>>>>>
> >>>>>>> Am Dienstag, 13. August 2019, 19:35:31 CEST schrieb Kevin Hilman:
> >>>>>>>> [ resent with correct addr for linux-rockchip list ]
> >>>>>>>>
> >>>>>>>> Mark Brown <broonie@kernel.org> writes:
> >>>>>>>>
> >>>>>>>>> On Thu, Jul 18, 2019 at 04:28:08AM -0700, kernelci.org bot wrote:
> >>>>>>>>>
> >>>>>>>>> Today's -next started failing to boot defconfig on rk3399-firefly:
> >>>>>>>>>
> >>>>>>>>>> arm64:
> >>>>>>>>>> defconfig:
> >>>>>>>>>> gcc-8:
> >>>>>>>>>> rk3399-firefly: 1 failed lab
> >>>>>>>>> It hits a BUG() trying to set up cpufreq:
> >>>>>>>>>
> >>>>>>>>> [ 87.381606] cpufreq: cpufreq_online: CPU0: Running at unlisted freq: 200000 KHz
> >>>>>>>>> [ 87.393244] cpufreq: cpufreq_online: CPU0: Unlisted initial frequency changed to: 408000 KHz
> >>>>>>>>> [ 87.469777] cpufreq: cpufreq_online: CPU4: Running at unlisted freq: 12000 KHz
> >>>>>>>>> [ 87.488595] cpu cpu4: _generic_set_opp_clk_only: failed to set clock rate: -22
> >>>>>>>>> [ 87.491881] cpufreq: __target_index: Failed to change cpu frequency: -22
> >>>>>>>>> [ 87.495335] ------------[ cut here ]------------
> >>>>>>>>> [ 87.496821] kernel BUG at drivers/cpufreq/cpufreq.c:1438!
> >>>>>>>>> [ 87.498462] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
> >>>>>>>>>
> >>>>>>>>> I'm struggling to see anything relevant in the diff from yesterday, the
> >>>>>>>>> unlisted frequency warnings were there in the logs yesterday but no oops
> >>>>>>>>> and I'm not seeing any changes in cpufreq, clk or anything relevant
> >>>>>>>>> looking.
> >>>>>>>>>
> >>>>>>>>> Full bootlog and other info can be found here:
> >>>>>>>>>
> >>>>>>>>> https://kernelci.org/boot/id/5d302d8359b51498d049e983/
> >>>>>>>> I confirm that disabling CPUfreq in the defconfig (CONFIG_CPU_FREQ=n)
> >>>>>>>> makes the firefly board start working again.
> >>>>>>>>
> >>>>>>>> Note that the default defconfig enables the "performance" CPUfreq
> >>>>>>>> governor as the default governor, so during kernel boot, it will always
> >>>>>>>> switch to the max frequency.
> >>>>>>>>
> >>>>>>>> For fun, I set the default governor to "userspace" so the kernel
> >>>>>>>> wouldn't make any OPP changes, and that leads to a slightly more
> >>>>>>>> informative splat[1]
> >>>>>>>>
> >>>>>>>> There is still an OPP change happening because the detected OPP is not
> >>>>>>>> one that's listed in the table, so it tries to change to a listed OPP
> >>>>>>>> and fails in the bowels of clk_set_rate()
> >>>>>>> Though I think that might only be a symptom as well.
> >>>>>>> Both the PLL setting code as well as the actual cpu-clock implementation
> >>>>>>> is unchanged since 2017 (and runs just fine on all boards in my farm).
> >>>>>>>
> >>>>>>> One source for these issues is often the regulator supplying the cpu
> >>>>>>> going haywire - aka the voltage not matching the opp.
> >>>>>>>
> >>>>>>> As in this error-case it's CPU4 being set, this would mean it might
> >>>>>>> be the big cluster supplied by the external syr825 (fan5355 clone)
> >>>>>>> that might act up. In the Firefly-rk3399 case this is even stranger.
> >>>>>>>
> >>>>>>> There is a discrepancy between the "fcs,suspend-voltage-selector"
> >>>>>>> between different bootloader versions (how the selection-pin is set up),
> >>>>>>> so the kernel might actually write his requested voltage to the wrong
> >>>>>>> register (not the one for actual voltage, but the second set used for
> >>>>>>> the suspend voltage).
> >>>>>>>
> >>>>>>> Did you by chance swap bootloaders at some point in recent past?
> >>>>>> No, haven't touched bootloader since I initially setup the board.
> >>>>> The CPU voltage does not affect by bootloader for kernel should have its
> >>>>> own opp-table,
> >>>>>
> >>>>> the bootloader may only affect the center/logic power supply.
> >>>>>
> >>>>>>> I'd assume [2] might actually be the same issue last year, though
> >>>>>>> the CI-logs are not available anymore it seems.
> >>>>>>>
> >>>>>>> Could you try to set the vdd_cpu_b regulator to disabled, so that
> >>>>>>> cpufreq for this cluster defers and see what happens?
> >>>>>> Yes, this change[1] definitely makes things boot reliably again, so
> >>>>>> there's defintiely something a bit unstable with this regulator, at
> >>>>>> least on this firefly.
> >>>>> Is it possible to target which patch introduce this bug? This board
> >>>>> should have work correctly for a long time with upstream source code.
> >>>> Unfortunately, it seems to be a regular, but intermittent failure, so
> >>>> bisection is not producing anything reliable.
> >>>>
> >>>> You can see that both in mainline[1] and in linux-next[2] there are
> >>>> periodic failures, but it's hard to see any patterns.
> >>> Even worse, I (re)tested mainline for versions that were previously
> >>> passing (v5.2, v5.3-rc5) and they are also failing now.
> >>>
> >>> They work again if I disable that regulator as suggested by Heiko.
> >>>
> >>> So this is increasingly pointing to failing hardware.
> >>>
> >>> Kevin
> >>>
> >>>
> >>>
> >
> >
>
>
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* RE: [PATCH V5 1/3] perf: imx8_ddr_perf: add AXI ID filter support
From: Joakim Zhang @ 2019-08-27 2:15 UTC (permalink / raw)
To: Frank Li, Mark Rutland
Cc: will@kernel.org, robin.murphy@arm.com, dl-linux-imx,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <AM6PR04MB49032FA7159DC8B2B96488DC88A10@AM6PR04MB4903.eurprd04.prod.outlook.com>
> -----Original Message-----
> From: Frank Li
> Sent: 2019年8月26日 23:37
> To: Joakim Zhang <qiangqing.zhang@nxp.com>; Mark Rutland
> <mark.rutland@arm.com>
> Cc: robin.murphy@arm.com; will@kernel.org;
> linux-arm-kernel@lists.infradead.org; dl-linux-imx <linux-imx@nxp.com>
> Subject: RE: [PATCH V5 1/3] perf: imx8_ddr_perf: add AXI ID filter support
>
>
>
> > -----Original Message-----
> > From: Joakim Zhang
> > Sent: Monday, August 26, 2019 2:12 AM
> > To: Mark Rutland <mark.rutland@arm.com>
> > Cc: robin.murphy@arm.com; will@kernel.org; Frank Li
> > <frank.li@nxp.com>; linux-arm-kernel@lists.infradead.org; dl-linux-imx
> > <linux-imx@nxp.com>
> > Subject: RE: [PATCH V5 1/3] perf: imx8_ddr_perf: add AXI ID filter
> > support
> >
> >
> > > -----Original Message-----
> > > From: Mark Rutland <mark.rutland@arm.com>
> > > Sent: 2019年8月23日 20:57
> > > To: Joakim Zhang <qiangqing.zhang@nxp.com>
> > > Cc: robin.murphy@arm.com; will@kernel.org; Frank Li
> > > <frank.li@nxp.com>; linux-arm-kernel@lists.infradead.org;
> > > dl-linux-imx <linux-imx@nxp.com>
> > > Subject: Re: [PATCH V5 1/3] perf: imx8_ddr_perf: add AXI ID filter
> > > support
> > >
> > > On Thu, Aug 08, 2019 at 06:45:29AM +0000, Joakim Zhang wrote:
> > > > AXI filtering is used by CSV modes 0x41 and 0x42 to count reads or
> > > > writes with an ARID or AXID matching filter setting. Granularity
> > > > is at subsystem level. Implementation does not allow filtring
> > > > between masters within a subsystem. Filter is defined with 2
> configuration registers.
> > > >
> > > > --AXI_ID defines AxID matching value --AXI_MASKING defines which
> > > > bits of AxID are meaningful for the matching
> > > >
> > > > When non-masked bits are matching corresponding AXI_ID bits then
> > > > counter is incremented. This filter allows counting read or write
> > > > access from a subsystem or multiple subsystems.
> > > >
> > > > Perf counter is incremented if AxID && AXI_MASKING == AXI_ID &&
> > > > AXI_MASKING
> > >
> > > Just to check, the filter does not affect other events, right?
> >
> > [Joakim] Yes, this filter is only for events 0x41 and 0x42.
> >
> > > >
> > > > AXI_ID and AXI_MASKING are mapped on DPCR1 register in performance
> > > counter.
> > > >
> > > > Read and write AXI ID filter should write same value to DPCR1 if
> > > > want to specify at the same time as this filter is shared between
> counters.
> > > >
> > > > e.g.
> > > > perf stat -a -e
> > > >
> > >
> imx8_ddr0/axi-id-read,axi_id=0xMMMMDDDD/,imx8_ddr0/axi-id-write,axi_
> > > id
> > > > =0xMMMMDDDD/ cmd
> > > > MMMM: AXI_MASKING
> > > > DDDD: AXI_ID
> > >
> > > You might want to expose this to userspace as two fields:
> > >
> > > axi_id=DDDD
> > > axi_mask=MMMM
> > >
> > > ... where axi_mask is inverted (i.e. set bits are bits to ignore),
> > > so that the user can just specify axi_id to monitor a specific id,
> > > rather than having to specifiy axi_id=0xffff<id>.
> >
> > [Joakim] No, axi_mask is not inverted, should specify axi_id =
> > 0xffff<id> for the particular AXI ID. I will improve the commit message.
> > 0: corresponding bit is masked
> > 1: corresponding bit is not masked, i.e. used to do the matching
> >
>
> [Frank Li] Joakim, mark's means is that revert it at your driver.
> Most case user just want to filter a AXID. For example 0x12
>
> If you revert mask at driver, user just need input axi_id = 0x12 instead of
> axi_id=0xffff0012.
[Joakim] Sorry for my misunderstanding, I will improve it in V7. Thanks.
>
> > > >
> > > > ChangeLog:
> > > > V1 -> V2:
> > > > * add error log if user specifies read/write AXI ID filter at
> > > > the same time.
> > > > * of_device_get_match_data() instead of of_match_device(), and
> > > > remove the check of return value.
> > > > V2 -> V3:
> > > > * move the AXI ID check to event_add().
> > > > * add support for same value of axi_id.
> > > > V3 -> V4:
> > > > * move the AXI ID check to event_init().
> > > > V4 -> V5:
> > > > * reject event group if AXI ID not consistent in event_init().
> > > >
> > > > Signed-off-by: Joakim Zhang <qiangqing.zhang@nxp.com>
> > > > ---
> > > > drivers/perf/fsl_imx8_ddr_perf.c | 63
> > > > +++++++++++++++++++++++++++++++-
> > > > 1 file changed, 61 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/drivers/perf/fsl_imx8_ddr_perf.c
> > > > b/drivers/perf/fsl_imx8_ddr_perf.c
> > > > index 63fe21600072..f25cf5cbe156 100644
> > > > --- a/drivers/perf/fsl_imx8_ddr_perf.c
> > > > +++ b/drivers/perf/fsl_imx8_ddr_perf.c
> > > > @@ -42,9 +42,22 @@
> > > >
> > > > static DEFINE_IDA(ddr_ida);
> > > >
> > > > +/* DDR Perf hardware feature */
> > > > +#define DDR_CAP_AXI_ID_FILTER 0x1 /* support AXI ID filter
> > */
> > > > +
> > > > +struct fsl_ddr_devtype_data {
> > > > + unsigned int quirks; /* quirks needed for different DDR Perf core */
> > > > +};
> > > > +
> > > > +static const struct fsl_ddr_devtype_data imx8_devtype_data;
> > > > +
> > > > +static const struct fsl_ddr_devtype_data imx8m_devtype_data = {
> > > > + .quirks = DDR_CAP_AXI_ID_FILTER, };
> > > > +
> > > > static const struct of_device_id imx_ddr_pmu_dt_ids[] = {
> > > > - { .compatible = "fsl,imx8-ddr-pmu",},
> > > > - { .compatible = "fsl,imx8m-ddr-pmu",},
> > > > + { .compatible = "fsl,imx8-ddr-pmu", .data = &imx8_devtype_data},
> > > > + { .compatible = "fsl,imx8m-ddr-pmu", .data =
> > > > +&imx8m_devtype_data},
> > > > { /* sentinel */ }
> > > > };
> > >
> > > Are new DDR PMUs going to lack this feature?
> > >
> > > If all PMUs the driver supports have it, then we don't need this
> > > quirk/feature list.
> > >
> > > That would make the subsequent code a bit nicer, as all the
> > > filtering code would lose a level of indentation.
> >
> > [Joakim] This feature may drop, some coming SOCs will improve this AXI
> > ID filtering, let it can filter from different ID separately, and ang other
> extensions.
> >
> > > >
> > > > @@ -57,6 +70,7 @@ struct ddr_pmu {
> > > > struct perf_event *events[NUM_COUNTERS];
> > > > int active_events;
> > > > enum cpuhp_state cpuhp_state;
> > > > + const struct fsl_ddr_devtype_data *devtype_data;
> > > > int irq;
> > > > int id;
> > > > };
> > > > @@ -128,6 +142,8 @@ static struct attribute *ddr_perf_events_attrs[] =
> {
> > > > IMX8_DDR_PMU_EVENT_ATTR(refresh, 0x37),
> > > > IMX8_DDR_PMU_EVENT_ATTR(write, 0x38),
> > > > IMX8_DDR_PMU_EVENT_ATTR(raw-hazard, 0x39),
> > > > + IMX8_DDR_PMU_EVENT_ATTR(axi-id-read, 0x41),
> > > > + IMX8_DDR_PMU_EVENT_ATTR(axi-id-write, 0x42),
> > > > NULL,
> > > > };
> > > >
> > > > @@ -137,9 +153,11 @@ static struct attribute_group
> > > > ddr_perf_events_attr_group = { };
> > > >
> > > > PMU_FORMAT_ATTR(event, "config:0-7");
> > > > +PMU_FORMAT_ATTR(axi_id, "config1:0-31");
> > > >
> > > > static struct attribute *ddr_perf_format_attrs[] = {
> > > > &format_attr_event.attr,
> > > > + &format_attr_axi_id.attr,
> > > > NULL,
> > > > };
> > > >
> > > > @@ -189,6 +207,16 @@ static u32 ddr_perf_read_counter(struct
> > > > ddr_pmu
> > > *pmu, int counter)
> > > > return readl_relaxed(pmu->base + COUNTER_READ + counter *
> 4); }
> > > >
> > > > +static bool ddr_perf_is_filtered(struct perf_event *event) {
> > > > + return event->attr.config == 0x41 || event->attr.config == 0x42;
> > > > +}
> > > > +
> > > > +static u32 ddr_perf_filter_val(struct perf_event *event) {
> > > > + return event->attr.config1;
> > > > +}
> > > > +
> > >
> > > Let's add another helper:
> > >
> > > static bool ddr_perf_filters_compatible(struct perf_event *a,
> > > struct perf_event *b)
> > > {
> > > if (!ddr_perf_is_filtered(a))
> > > return true;
> > > if (!ddr_perf_is_filtered(b))
> > > return true;
> > > return ddr_perf_filter_val(a) == ddr_perf_filter_val(b); }
> > >
> > > > static int ddr_perf_event_init(struct perf_event *event) {
> > > > struct ddr_pmu *pmu = to_ddr_pmu(event->pmu); @@ -215,6
> +243,18
> > > @@
> > > > static int ddr_perf_event_init(struct perf_event *event)
> > > > !is_software_event(event->group_leader))
> > > > return -EINVAL;
> > > >
> > > > + if (pmu->devtype_data->quirks & DDR_CAP_AXI_ID_FILTER) {
> > > > + bool is_filtered = ddr_perf_is_filtered(event);
> > > > + u32 filter_val = ddr_perf_filter_val(event);
> > > > +
> > > > + for_each_sibling_event(sibling, event->group_leader) {
> > > > + if (is_filtered && ddr_perf_is_filtered(sibling) &&
> > > > + ddr_perf_filter_val(sibling) != filter_val) {
> > > > + return -EINVAL;
> > > > + }
> > > > + }
> > > > + }
> > >
> > > ... so this can be:
> > >
> > > if (pmu->devtype_data->quirks & DDR_CAP_AXI_ID_FILTER) {
> > > if (!ddr_perf_filters_compatible(event, event->group_leader))
> > > return -EINVAL;
> > > for_each_sibling_event(sibling, event->group_leader) {
> > > if (!ddr_perf_filters_compatible(event, sibling))
> > > return -EINVAL;
> > > }
> > > }
> >
> > [Joakim] Got it.
> >
> > > Note: that checks group_leader, which you mised above. When the
> > > event is the group leader, it's trivially compatible with itself, so
> > > we don't need a special case there.
> > >
> > > > +
> > > > for_each_sibling_event(sibling, event->group_leader) {
> > > > if (sibling->pmu != event->pmu &&
> > > > !is_software_event(sibling))
> > > > @@ -288,6 +328,23 @@ static int ddr_perf_event_add(struct
> > > > perf_event
> > > *event, int flags)
> > > > int counter;
> > > > int cfg = event->attr.config;
> > > >
> > > > + if (pmu->devtype_data->quirks & DDR_CAP_AXI_ID_FILTER) {
> > > > + int i;
> > > > + bool is_filtered = ddr_perf_is_filtered(event);
> > > > + u32 filter_val = ddr_perf_filter_val(event);
> > > > +
> > > > + for (i = 1; i < NUM_COUNTERS; i++) {
> > > > + if (is_filtered && pmu->events[i] &&
> > > > + ddr_perf_is_filtered(pmu->events[i]) &&
> > > > + ddr_perf_filter_val(pmu->events[i]) != filter_val) {
> > > > + dev_dbg(pmu->dev, "Contradictory axi id filter
> > value\n");
> > > > + return -EINVAL;
> > > > + }
> > > > + }
> > >
> > > ... and likewise:
> > >
> > > if (pmu->devtype_data->quirks & DDR_CAP_AXI_ID_FILTER) {
> > > int i;
> > >
> > > for (i = 1; i < NUM_COUNTERS; i++) {
> > > if (!ddr_perf_filters_compatible(event, pmu->events[i]))
> > > return -EINVAL;
> > > }
> > > }
> > >
> > > Please drop the dev_dbg() here, since when perf rotates events this
> > > can happen many times per second, and it's entirely legitimate.
> >
> > [Joakim] Got it.
> >
> > > Otherwise, this looks good to me.
> >
> > [Joakim] Thanks Mark, I will sent out a V6, please help review.
> >
> > Best Regards,
> > Joakim Zhang
> > > Thanks,
> > > Mark.
> > >
> > > > +
> > > > + writel(filter_val, pmu->base + COUNTER_DPCR1);
> > > > + }
> > > > +
> > > > counter = ddr_perf_alloc_counter(pmu, cfg);
> > > > if (counter < 0) {
> > > > dev_dbg(pmu->dev, "There are not enough counters\n"); @@ -
> > 472,6
> > > > +529,8 @@ static int ddr_perf_probe(struct platform_device *pdev)
> > > > if (!name)
> > > > return -ENOMEM;
> > > >
> > > > + pmu->devtype_data = of_device_get_match_data(&pdev->dev);
> > > > +
> > > > pmu->cpu = raw_smp_processor_id();
> > > > ret = cpuhp_setup_state_multi(CPUHP_AP_ONLINE_DYN,
> > > > DDR_CPUHP_CB_NAME,
> > > > --
> > > > 2.17.1
> > > >
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH V7 1/3] perf: imx8_ddr_perf: add AXI ID filter support
From: Joakim Zhang @ 2019-08-27 2:39 UTC (permalink / raw)
To: mark.rutland@arm.com, will@kernel.org, robin.murphy@arm.com
Cc: Frank Li, dl-linux-imx, linux-arm-kernel@lists.infradead.org,
Joakim Zhang
AXI filtering is used by CSV modes 0x41 and 0x42 to count reads or
writes with an ARID or AWID matching filter setting. Granularity is at
subsystem level. Implementation does not allow filtring between masters
within a subsystem. Filter is defined with 2 configuration parameters.
--AXI_ID defines AxID matching value
--AXI_MASKING defines which bits of AxID are meaningful for the matching
0：corresponding bit is masked
1: corresponding bit is not masked, i.e. used to do the matching
When non-masked bits are matching corresponding AXI_ID bits then counter
is incremented. This filter allows counting read or write access from a
subsystem or multiple subsystems.
Perf counter is incremented if AxID && AXI_MASKING == AXI_ID && AXI_MASKING
AXI_ID and AXI_MASKING are mapped on DPCR1 register in performance counter.
Read and write AXI ID filter should write same value to DPCR1 if want to
specify at the same time as this filter is shared between counters.
e.g.
perf stat -a -e imx8_ddr0/axid-read,axi_id=0xMMMMDDDD/,imx8_ddr0/axid-write,axi_id=0xMMMMDDDD/ cmd
MMMM: AXI_MASKING DDDD: AXI_ID
perf stat -a -e imx8_ddr0/axid-read,axi_id=0x12/ cmd, which will monitor ARID=0x12
NOTE: AXI_MASKING is inverted at driver(i.e. set bits are bits to mask), so
that the user can just specify axi_id to monitor a specific id, rather than
having to specify axi_id=0xffff<id>.
ChangeLog:
V1 -> V2:
* add error log if user specifies read/write AXI ID filter at
the same time.
* of_device_get_match_data() instead of of_match_device(), and
remove the check of return value.
V2 -> V3:
* move the AXI ID check to event_add().
* add support for same value of axi_id.
V3 -> V4:
* move the AXI ID check to event_init().
V4 -> V5:
* reject event group if AXI ID not consistent in event_init().
V5 -> V6:
* change the event name: axi-id-read->axid-read;
axi-id-write->axid-write
* add another helper: ddr_perf_filters_compatible()
* drop the dev_dbg()
V6 -> V7:
* revert AXI_MASKING at driver.
Signed-off-by: Joakim Zhang <qiangqing.zhang@nxp.com>
---
drivers/perf/fsl_imx8_ddr_perf.c | 70 +++++++++++++++++++++++++++++++-
1 file changed, 68 insertions(+), 2 deletions(-)
diff --git a/drivers/perf/fsl_imx8_ddr_perf.c b/drivers/perf/fsl_imx8_ddr_perf.c
index 0e3310dbb145..ec2120fc3207 100644
--- a/drivers/perf/fsl_imx8_ddr_perf.c
+++ b/drivers/perf/fsl_imx8_ddr_perf.c
@@ -35,6 +35,8 @@
#define EVENT_CYCLES_COUNTER 0
#define NUM_COUNTERS 4
+#define AXI_MASKING_REVERT 0xffff0000 /* AXI_MASKING(MSB 16bits) + AXI_ID(LSB 16bits) */
+
#define to_ddr_pmu(p) container_of(p, struct ddr_pmu, pmu)
#define DDR_PERF_DEV_NAME "imx8_ddr"
@@ -42,9 +44,22 @@
static DEFINE_IDA(ddr_ida);
+/* DDR Perf hardware feature */
+#define DDR_CAP_AXI_ID_FILTER 0x1 /* support AXI ID filter */
+
+struct fsl_ddr_devtype_data {
+ unsigned int quirks; /* quirks needed for different DDR Perf core */
+};
+
+static const struct fsl_ddr_devtype_data imx8_devtype_data;
+
+static const struct fsl_ddr_devtype_data imx8m_devtype_data = {
+ .quirks = DDR_CAP_AXI_ID_FILTER,
+};
+
static const struct of_device_id imx_ddr_pmu_dt_ids[] = {
- { .compatible = "fsl,imx8-ddr-pmu",},
- { .compatible = "fsl,imx8m-ddr-pmu",},
+ { .compatible = "fsl,imx8-ddr-pmu", .data = &imx8_devtype_data},
+ { .compatible = "fsl,imx8m-ddr-pmu", .data = &imx8m_devtype_data},
{ /* sentinel */ }
};
MODULE_DEVICE_TABLE(of, imx_ddr_pmu_dt_ids);
@@ -58,6 +73,7 @@ struct ddr_pmu {
struct perf_event *events[NUM_COUNTERS];
int active_events;
enum cpuhp_state cpuhp_state;
+ const struct fsl_ddr_devtype_data *devtype_data;
int irq;
int id;
};
@@ -129,6 +145,8 @@ static struct attribute *ddr_perf_events_attrs[] = {
IMX8_DDR_PMU_EVENT_ATTR(refresh, 0x37),
IMX8_DDR_PMU_EVENT_ATTR(write, 0x38),
IMX8_DDR_PMU_EVENT_ATTR(raw-hazard, 0x39),
+ IMX8_DDR_PMU_EVENT_ATTR(axid-read, 0x41),
+ IMX8_DDR_PMU_EVENT_ATTR(axid-write, 0x42),
NULL,
};
@@ -138,9 +156,11 @@ static struct attribute_group ddr_perf_events_attr_group = {
};
PMU_FORMAT_ATTR(event, "config:0-7");
+PMU_FORMAT_ATTR(axi_id, "config1:0-31");
static struct attribute *ddr_perf_format_attrs[] = {
&format_attr_event.attr,
+ &format_attr_axi_id.attr,
NULL,
};
@@ -190,6 +210,26 @@ static u32 ddr_perf_read_counter(struct ddr_pmu *pmu, int counter)
return readl_relaxed(pmu->base + COUNTER_READ + counter * 4);
}
+static bool ddr_perf_is_filtered(struct perf_event *event)
+{
+ return event->attr.config == 0x41 || event->attr.config == 0x42;
+}
+
+static u32 ddr_perf_filter_val(struct perf_event *event)
+{
+ return event->attr.config1;
+}
+
+static bool ddr_perf_filters_compatible(struct perf_event *a,
+ struct perf_event *b)
+{
+ if (!ddr_perf_is_filtered(a))
+ return true;
+ if (!ddr_perf_is_filtered(b))
+ return true;
+ return ddr_perf_filter_val(a) == ddr_perf_filter_val(b);
+}
+
static int ddr_perf_event_init(struct perf_event *event)
{
struct ddr_pmu *pmu = to_ddr_pmu(event->pmu);
@@ -216,6 +256,15 @@ static int ddr_perf_event_init(struct perf_event *event)
!is_software_event(event->group_leader))
return -EINVAL;
+ if (pmu->devtype_data->quirks & DDR_CAP_AXI_ID_FILTER) {
+ if (!ddr_perf_filters_compatible(event, event->group_leader))
+ return -EINVAL;
+ for_each_sibling_event(sibling, event->group_leader) {
+ if (!ddr_perf_filters_compatible(event, sibling))
+ return -EINVAL;
+ }
+ }
+
for_each_sibling_event(sibling, event->group_leader) {
if (sibling->pmu != event->pmu &&
!is_software_event(sibling))
@@ -288,6 +337,21 @@ static int ddr_perf_event_add(struct perf_event *event, int flags)
struct hw_perf_event *hwc = &event->hw;
int counter;
int cfg = event->attr.config;
+ int cfg1 = event->attr.config1;
+
+ if (pmu->devtype_data->quirks & DDR_CAP_AXI_ID_FILTER) {
+ int i;
+
+ for (i = 1; i < NUM_COUNTERS; i++) {
+ if (pmu->events[i] &&
+ !ddr_perf_filters_compatible(event, pmu->events[i]))
+ return -EINVAL;
+ }
+
+ /* revert axi_id masking value */
+ cfg1 ^= AXI_MASKING_REVERT;
+ writel(cfg1, pmu->base + COUNTER_DPCR1);
+ }
counter = ddr_perf_alloc_counter(pmu, cfg);
if (counter < 0) {
@@ -473,6 +537,8 @@ static int ddr_perf_probe(struct platform_device *pdev)
if (!name)
return -ENOMEM;
+ pmu->devtype_data = of_device_get_match_data(&pdev->dev);
+
pmu->cpu = raw_smp_processor_id();
ret = cpuhp_setup_state_multi(CPUHP_AP_ONLINE_DYN,
DDR_CPUHP_CB_NAME,
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH V7 2/3] Documentation: admin-guide: perf: add i.MX8 ddr pmu user doc
From: Joakim Zhang @ 2019-08-27 2:39 UTC (permalink / raw)
To: mark.rutland@arm.com, will@kernel.org, robin.murphy@arm.com
Cc: Frank Li, dl-linux-imx, linux-arm-kernel@lists.infradead.org,
Joakim Zhang
In-Reply-To: <20190827023557.7071-1-qiangqing.zhang@nxp.com>
Add i.MX8 ddr pmu user doc.
ChangeLog:
V1 -> V4:
* new add in V4.
V4 -> V5:
* no change.
V5 -> V6:
* change the event name
V6 -> V7:
* no change.
Signed-off-by: Joakim Zhang <qiangqing.zhang@nxp.com>
---
Documentation/admin-guide/perf/imx-ddr.rst | 30 ++++++++++++++++++++++
1 file changed, 30 insertions(+)
create mode 100644 Documentation/admin-guide/perf/imx-ddr.rst
diff --git a/Documentation/admin-guide/perf/imx-ddr.rst b/Documentation/admin-guide/perf/imx-ddr.rst
new file mode 100644
index 000000000000..2540a4d1417b
--- /dev/null
+++ b/Documentation/admin-guide/perf/imx-ddr.rst
@@ -0,0 +1,30 @@
+====================================================
+Freescale i.MX8 DDR Performance Monitoring Unit (PMU)
+====================================================
+
+There are no performance counters inside the DRAM controller, so performance
+signals are brought out to the edge of the controller where a set of 4 x 32 bit
+counters is implemented. This is controlled by the Performance log on parameter
+which causes a large number of PERF signals to be generated.
+
+Selection of the value for each counter is done via the config registiers. There
+is one register for each counter. Counter 0 is special in that it always counts
+“time” and when expired causes a lock on itself and the other counters and an
+interrupt ie enable of counter 0 is a global function.
+
+The "format" directory describes format of the config (event ID) and config1
+(AXI ID filter) fields of the perf_event_attr structure, see /sys/bus/event_source/
+devices/imx8_ddr0/format/. The "events" directory describes the events types
+hardware supported that can be used with perf tool, see /sys/bus/event_source/
+devices/imx8_ddr0/events/.
+
+AXI ID filter is only used by CSV modes 0x41 (axid-read) and 0x42 (axid-write)
+to count reading or writing matches filter setting. User should specify this two
+events with the same AXI ID filter value if want to count at the same time, as
+this filter register is shared between counters.
+
+Example for perf tool use::
+
+ perf stat -a -e imx8_ddr0/cycles/ cmd
+ perf stat -a -e imx8_ddr0/read/,imx8_ddr0/write/ cmd
+ perf stat -a -e imx8_ddr0/axid-read,axi_id=0xMMMMDDDD/,imx8_ddr0/axid-write,axi_id=0xMMMMDDDD/ cmd
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH V7 3/3] MAINTAINERS: add imx8 ddr perf admin-guide maintainer information
From: Joakim Zhang @ 2019-08-27 2:39 UTC (permalink / raw)
To: mark.rutland@arm.com, will@kernel.org, robin.murphy@arm.com
Cc: Frank Li, dl-linux-imx, linux-arm-kernel@lists.infradead.org,
Joakim Zhang
In-Reply-To: <20190827023557.7071-1-qiangqing.zhang@nxp.com>
Add imx8 ddr perf admin-guide maintainer information.
ChangeLog:
V1 -> V5:
* new add in V5.
V5 -> V6:
* no change.
V6 -> V7:
* no change.
Signed-off-by: Joakim Zhang <qiangqing.zhang@nxp.com>
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index e60f5c361969..2ba378e806c7 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6462,6 +6462,7 @@ M: Frank Li <Frank.li@nxp.com>
L: linux-arm-kernel@lists.infradead.org
S: Maintained
F: drivers/perf/fsl_imx8_ddr_perf.c
+F: Documentation/admin-guide/perf/imx-ddr.rst
F: Documentation/devicetree/bindings/perf/fsl-imx-ddr.txt
FREESCALE IMX LPI2C DRIVER
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [GIT PULL] SOC: TI soc updates for 5.4
From: Santosh Shilimkar @ 2019-08-27 3:11 UTC (permalink / raw)
To: arm, linux-arm-kernel
Cc: olof, santosh.shilimkar, linux-kernel, arnd, khilman
The following changes since commit 609488bc979f99f805f34e9a32c1e3b71179d10b:
Linux 5.3-rc2 (2019-07-28 12:47:02 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux-keystone.git tags/drivers_soc_for_5.4
for you to fetch changes up to 23013399a2252e9f592c2c52a62b213d3ef09217:
soc: ti: ti_sci_pm_domains: Add support for exclusive and shared access (2019-08-26 20:00:41 -0700)
----------------------------------------------------------------
soc: TI soc updates for 5.4
- Update firmware to support PM domain shared and exclusive support
- Update driver and dt binding docs for the same.
----------------------------------------------------------------
Lokesh Vutla (3):
firmware: ti_sci: Allow for device shared and exclusive requests
dt-bindings: ti_sci_pm_domains: Add support for exclusive and shared
access
soc: ti: ti_sci_pm_domains: Add support for exclusive and shared
access
.../devicetree/bindings/soc/ti/sci-pm-domain.txt | 11 +++++-
MAINTAINERS | 1 +
drivers/firmware/ti_sci.c | 45 +++++++++++++++++++++-
drivers/soc/ti/ti_sci_pm_domains.c | 23 ++++++++++-
include/dt-bindings/soc/ti,sci_pm_domain.h | 9 +++++
include/linux/soc/ti/ti_sci_protocol.h | 3 ++
6 files changed, 86 insertions(+), 6 deletions(-)
create mode 100644 include/dt-bindings/soc/ti,sci_pm_domain.h
--
1.9.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] ASoC: imx-audmix: register the card on a proper dev
From: Shengjiu Wang @ 2019-08-27 15:55 UTC (permalink / raw)
To: timur, nicoleotsuka, Xiubo.Lee, festevam, broonie, lgirdwood,
perex, tiwai, shawnguo, s.hauer, kernel, alsa-devel, viorel.suman
Cc: linuxppc-dev, linux-imx, linux-arm-kernel, linux-kernel
This platform device is registered from "fsl_audmix", which is
its parent device. If use pdev->dev.parent for the priv->card.dev,
the value set by dev_set_drvdata in parent device will be covered
by the value in child device.
Fixes: b86ef5367761 ("ASoC: fsl: Add Audio Mixer machine driver")
Signed-off-by: Viorel Suman <viorel.suman@nxp.com>
Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
---
sound/soc/fsl/imx-audmix.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/sound/soc/fsl/imx-audmix.c b/sound/soc/fsl/imx-audmix.c
index 9e1cb18859ce..71590ca6394b 100644
--- a/sound/soc/fsl/imx-audmix.c
+++ b/sound/soc/fsl/imx-audmix.c
@@ -325,14 +325,14 @@ static int imx_audmix_probe(struct platform_device *pdev)
priv->card.num_configs = priv->num_dai_conf;
priv->card.dapm_routes = priv->dapm_routes;
priv->card.num_dapm_routes = priv->num_dapm_routes;
- priv->card.dev = pdev->dev.parent;
+ priv->card.dev = &pdev->dev;
priv->card.owner = THIS_MODULE;
priv->card.name = "imx-audmix";
platform_set_drvdata(pdev, &priv->card);
snd_soc_card_set_drvdata(&priv->card, priv);
- ret = devm_snd_soc_register_card(pdev->dev.parent, &priv->card);
+ ret = devm_snd_soc_register_card(&pdev->dev, &priv->card);
if (ret) {
dev_err(&pdev->dev, "snd_soc_register_card failed\n");
return ret;
--
2.21.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [RESEND, PATCH v13 11/12] soc: mediatek: cmdq: add cmdq_dev_get_client_reg function
From: Bibby Hsieh @ 2019-08-27 3:59 UTC (permalink / raw)
To: Matthias Brugger
Cc: devicetree, Nicolas Boichat, Philipp Zabel, srv_heupstream,
Daoyuan Huang, Sascha Hauer, Jassi Brar, linux-kernel,
Daniel Kurtz, Dennis-YC Hsieh, YT Shen, Rob Herring,
linux-mediatek, Houlong Wei, Sascha Hauer, CK HU, Jiaguang Zhang,
linux-arm-kernel, ginny.chen
In-Reply-To: <ccd3782e-b1bb-7887-f4a5-d7774183c7b7@gmail.com>
On Fri, 2019-08-23 at 16:21 +0200, Matthias Brugger wrote:
>
> On 20/08/2019 10:49, Bibby Hsieh wrote:
> > GCE cannot know the register base address, this function
> > can help cmdq client to get the cmdq_client_reg structure.
> >
> > Signed-off-by: Bibby Hsieh <bibby.hsieh@mediatek.com>
> > Reviewed-by: CK Hu <ck.hu@mediatek.com>
> > ---
> > drivers/soc/mediatek/mtk-cmdq-helper.c | 29 ++++++++++++++++++++++++++
> > include/linux/soc/mediatek/mtk-cmdq.h | 21 +++++++++++++++++++
> > 2 files changed, 50 insertions(+)
> >
> > diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c b/drivers/soc/mediatek/mtk-cmdq-helper.c
> > index c53f8476c68d..80f75a1075b4 100644
> > --- a/drivers/soc/mediatek/mtk-cmdq-helper.c
> > +++ b/drivers/soc/mediatek/mtk-cmdq-helper.c
> > @@ -27,6 +27,35 @@ struct cmdq_instruction {
> > u8 op;
> > };
> >
> > +int cmdq_dev_get_client_reg(struct device *dev,
> > + struct cmdq_client_reg *client_reg, int idx)
> > +{
>
> Can't we do/call this in cmdq_mbox_create parsing the number of gce-client-reg
> properties we have and allocating these using a pointer to cmdq_client_reg in
> cmdq_client?
> We will have to free the pointer then in cmdq_mbox_destroy.
>
> Regards,
> Matthias
I don't think we need to keep the cmdq_client_reg in cmdq_client
structure.
Because our client will have own data structure, they will copy the
client_reg information into their own structure.
In the design now, we do not allocate the cmdq_client_reg, client pass
the cmdq_client_reg pointer into this API.
Client will destroy the pointer after they get the information they
want.
Thanks for the comments so much.
Bibby
>
> > + struct of_phandle_args spec;
> > + int err;
> > +
> > + if (!client_reg)
> > + return -ENOENT;
> > +
> > + err = of_parse_phandle_with_fixed_args(dev->of_node,
> > + "mediatek,gce-client-reg",
> > + 3, idx, &spec);
> > + if (err < 0) {
> > + dev_err(dev,
> > + "error %d can't parse gce-client-reg property (%d)",
> > + err, idx);
> > +
> > + return err;
> > + }
> > +
> > + client_reg->subsys = (u8)spec.args[0];
> > + client_reg->offset = (u16)spec.args[1];
> > + client_reg->size = (u16)spec.args[2];
> > + of_node_put(spec.np);
> > +
> > + return 0;
> > +}
> > +EXPORT_SYMBOL(cmdq_dev_get_client_reg);
> > +
> > static void cmdq_client_timeout(struct timer_list *t)
> > {
> > struct cmdq_client *client = from_timer(client, t, timer);
> > diff --git a/include/linux/soc/mediatek/mtk-cmdq.h b/include/linux/soc/mediatek/mtk-cmdq.h
> > index a345870a6d10..02ddd60b212f 100644
> > --- a/include/linux/soc/mediatek/mtk-cmdq.h
> > +++ b/include/linux/soc/mediatek/mtk-cmdq.h
> > @@ -15,6 +15,12 @@
> >
> > struct cmdq_pkt;
> >
> > +struct cmdq_client_reg {
> > + u8 subsys;
> > + u16 offset;
> > + u16 size;
> > +};
> > +
> > struct cmdq_client {
> > spinlock_t lock;
> > u32 pkt_cnt;
> > @@ -24,6 +30,21 @@ struct cmdq_client {
> > u32 timeout_ms; /* in unit of microsecond */
> > };
> >
> > +/**
> > + * cmdq_dev_get_client_reg() - parse cmdq client reg from the device
> > + * node of CMDQ client
> > + * @dev: device of CMDQ mailbox client
> > + * @client_reg: CMDQ client reg pointer
> > + * @idx: the index of desired reg
> > + *
> > + * Return: 0 for success; else the error code is returned
> > + *
> > + * Help CMDQ client parsing the cmdq client reg
> > + * from the device node of CMDQ client.
> > + */
> > +int cmdq_dev_get_client_reg(struct device *dev,
> > + struct cmdq_client_reg *client_reg, int idx);
> > +
> > /**
> > * cmdq_mbox_create() - create CMDQ mailbox client and channel
> > * @dev: device of CMDQ mailbox client
> >
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RESEND, PATCH v13 10/12] soc: mediatek: cmdq: add polling function
From: Bibby Hsieh @ 2019-08-27 4:07 UTC (permalink / raw)
To: Matthias Brugger
Cc: devicetree, Nicolas Boichat, Philipp Zabel, srv_heupstream,
Daoyuan Huang, Sascha Hauer, Jassi Brar, linux-kernel,
Daniel Kurtz, Dennis-YC Hsieh, YT Shen, Rob Herring,
linux-mediatek, Houlong Wei, Sascha Hauer, CK HU, Jiaguang Zhang,
linux-arm-kernel, ginny.chen
In-Reply-To: <2dfb6a69-c325-9caf-e11b-bf0f0fbf4bb6@gmail.com>
On Fri, 2019-08-23 at 16:05 +0200, Matthias Brugger wrote:
>
> On 20/08/2019 10:49, Bibby Hsieh wrote:
> > add polling function in cmdq helper functions
> >
> > Signed-off-by: Bibby Hsieh <bibby.hsieh@mediatek.com>
> > Reviewed-by: CK Hu <ck.hu@mediatek.com>
> > ---
> > drivers/soc/mediatek/mtk-cmdq-helper.c | 28 ++++++++++++++++++++++++
> > include/linux/mailbox/mtk-cmdq-mailbox.h | 1 +
> > include/linux/soc/mediatek/mtk-cmdq.h | 15 +++++++++++++
> > 3 files changed, 44 insertions(+)
> >
> > diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c b/drivers/soc/mediatek/mtk-cmdq-helper.c
> > index e3d5b0be8e79..c53f8476c68d 100644
> > --- a/drivers/soc/mediatek/mtk-cmdq-helper.c
> > +++ b/drivers/soc/mediatek/mtk-cmdq-helper.c
> > @@ -221,6 +221,34 @@ int cmdq_pkt_clear_event(struct cmdq_pkt *pkt, u16 event)
> > }
> > EXPORT_SYMBOL(cmdq_pkt_clear_event);
> >
> > +int cmdq_pkt_poll(struct cmdq_pkt *pkt, u8 subsys,
> > + u16 offset, u32 value, u32 mask)
> > +{
> > + struct cmdq_instruction *inst;
> > +
> > + if (mask != 0xffffffff) {
>
> Is this necessary? Can't we just always set the mask, even if it's 0xffffffff?
>
> Regarding interfaces, depending on how often you expect the mask being ~0 we
> might think of adding a cmdq_pkt_poll_mask call.
> What I want to say, if in the end most of the callers will use the mask with
> 0xffffffff, then we should add a call cmdq_pkt_poll_mask which actually allows
> to set the mask and let cmdq_pkt_poll set the mask in it's function body.
> As I already said, this depends on how often you think a caller will use/not-use
> the mask.
> Does this make sense?
It's better to have two function: cmdq_pkt_poll_mask and cmdq_pkt_poll,
client can choose which they need by themselves.
Thanks for the comments.
Bibby
> > + inst = cmdq_pkt_append_command(pkt);
> > + if (!inst)
> > + return -ENOMEM;
> > +
> > + inst->op = CMDQ_CODE_MASK;
> > + inst->value = ~mask;
> > + offset = offset | 0x1;
> > + }
> > +
> > + inst = cmdq_pkt_append_command(pkt);
> > + if (!inst)
> > + return -ENOMEM;
> > +
> > + inst->op = CMDQ_CODE_POLL;
> > + inst->value = value;
> > + inst->offset = offset;
> > + inst->subsys = subsys;
> > +
> > + return 0;
> > +}
> > +EXPORT_SYMBOL(cmdq_pkt_poll);
> > +
> > static int cmdq_pkt_finalize(struct cmdq_pkt *pkt)
> > {
> > struct cmdq_instruction *inst;
> > diff --git a/include/linux/mailbox/mtk-cmdq-mailbox.h b/include/linux/mailbox/mtk-cmdq-mailbox.h
> > index c8adedefaf42..9e3502945bc1 100644
> > --- a/include/linux/mailbox/mtk-cmdq-mailbox.h
> > +++ b/include/linux/mailbox/mtk-cmdq-mailbox.h
> > @@ -46,6 +46,7 @@
> > enum cmdq_code {
> > CMDQ_CODE_MASK = 0x02,
> > CMDQ_CODE_WRITE = 0x04,
> > + CMDQ_CODE_POLL = 0x08,
> > CMDQ_CODE_JUMP = 0x10,
> > CMDQ_CODE_WFE = 0x20,
> > CMDQ_CODE_EOC = 0x40,
> > diff --git a/include/linux/soc/mediatek/mtk-cmdq.h b/include/linux/soc/mediatek/mtk-cmdq.h
> > index 9618debb9ceb..a345870a6d10 100644
> > --- a/include/linux/soc/mediatek/mtk-cmdq.h
> > +++ b/include/linux/soc/mediatek/mtk-cmdq.h
> > @@ -99,6 +99,21 @@ int cmdq_pkt_wfe(struct cmdq_pkt *pkt, u16 event);
> > */
> > int cmdq_pkt_clear_event(struct cmdq_pkt *pkt, u16 event);
> >
> > +/**
> > + * cmdq_pkt_poll() - Append polling command to the CMDQ packet, ask GCE to
> > + * execute an instruction that wait for a specified hardware
> > + * register to check for the value. All GCE hardware
> > + * threads will be blocked by this instruction.
> > + * @pkt: the CMDQ packet
> > + * @subsys: the CMDQ sub system code
> > + * @offset: register offset from CMDQ sub system
> > + * @value: the specified target register value
> > + * @mask: the specified target register mask
> > + *
> > + * Return: 0 for success; else the error code is returned
> > + */
> > +int cmdq_pkt_poll(struct cmdq_pkt *pkt, u8 subsys,
> > + u16 offset, u32 value, u32 mask);
> > /**
> > * cmdq_pkt_flush_async() - trigger CMDQ to asynchronously execute the CMDQ
> > * packet and call back at the end of done packet
> >
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RESEND, PATCH v13 09/12] soc: mediatek: cmdq: define the instruction struct
From: Bibby Hsieh @ 2019-08-27 4:12 UTC (permalink / raw)
To: Matthias Brugger
Cc: devicetree, Nicolas Boichat, Philipp Zabel, srv_heupstream,
Daoyuan Huang, Sascha Hauer, Jassi Brar, linux-kernel,
Daniel Kurtz, Dennis-YC Hsieh, YT Shen, Rob Herring,
linux-mediatek, Houlong Wei, Sascha Hauer, CK HU, Jiaguang Zhang,
linux-arm-kernel, ginny.chen
In-Reply-To: <486deaa3-d139-d4af-e0cf-e324b3270f3b@gmail.com>
On Fri, 2019-08-23 at 15:50 +0200, Matthias Brugger wrote:
>
> On 20/08/2019 10:49, Bibby Hsieh wrote:
> > Define an instruction structure for gce driver to append command.
> > This structure can make the client's code more readability.
> >
> > Signed-off-by: Bibby Hsieh <bibby.hsieh@mediatek.com>
> > Reviewed-by: CK Hu <ck.hu@mediatek.com>
> > ---
> > drivers/soc/mediatek/mtk-cmdq-helper.c | 106 +++++++++++++++--------
> > include/linux/mailbox/mtk-cmdq-mailbox.h | 2 +
> > 2 files changed, 74 insertions(+), 34 deletions(-)
> >
> > diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c b/drivers/soc/mediatek/mtk-cmdq-helper.c
> > index 7aa0517ff2f3..e3d5b0be8e79 100644
> > --- a/drivers/soc/mediatek/mtk-cmdq-helper.c
> > +++ b/drivers/soc/mediatek/mtk-cmdq-helper.c
> > @@ -9,12 +9,24 @@
> > #include <linux/mailbox_controller.h>
> > #include <linux/soc/mediatek/mtk-cmdq.h>
> >
> > -#define CMDQ_ARG_A_WRITE_MASK 0xffff
> > #define CMDQ_WRITE_ENABLE_MASK BIT(0)
> > #define CMDQ_EOC_IRQ_EN BIT(0)
> > #define CMDQ_EOC_CMD ((u64)((CMDQ_CODE_EOC << CMDQ_OP_CODE_SHIFT)) \
> > << 32 | CMDQ_EOC_IRQ_EN)
> >
> > +struct cmdq_instruction {
> > + union {
> > + u32 value;
> > + u32 mask;
> > + };
> > + union {
> > + u16 offset;
> > + u16 event;
> > + };
> > + u8 subsys;
> > + u8 op;
> > +};
> > +
> > static void cmdq_client_timeout(struct timer_list *t)
> > {
> > struct cmdq_client *client = from_timer(client, t, timer);
> > @@ -110,10 +122,8 @@ void cmdq_pkt_destroy(struct cmdq_pkt *pkt)
> > }
> > EXPORT_SYMBOL(cmdq_pkt_destroy);
> >
> > -static int cmdq_pkt_append_command(struct cmdq_pkt *pkt, enum cmdq_code code,
> > - u32 arg_a, u32 arg_b)
> > +static struct cmdq_instruction *cmdq_pkt_append_command(struct cmdq_pkt *pkt)
> > {
> > - u64 *cmd_ptr;
> >
> > if (unlikely(pkt->cmd_buf_size + CMDQ_INST_SIZE > pkt->buf_size)) {
> > /*
> > @@ -127,81 +137,109 @@ static int cmdq_pkt_append_command(struct cmdq_pkt *pkt, enum cmdq_code code,
> > pkt->cmd_buf_size += CMDQ_INST_SIZE;
> > WARN_ONCE(1, "%s: buffer size %u is too small !\n",
> > __func__, (u32)pkt->buf_size);
> > - return -ENOMEM;
> > + return NULL;
> > }
> > - cmd_ptr = pkt->va_base + pkt->cmd_buf_size;
> > - (*cmd_ptr) = (u64)((code << CMDQ_OP_CODE_SHIFT) | arg_a) << 32 | arg_b;
> > +
> > + *(u64 *)(pkt->va_base + pkt->cmd_buf_size) = 0;> pkt->cmd_buf_size += CMDQ_INST_SIZE;
> >
> > - return 0;
> > + return pkt->va_base + pkt->cmd_buf_size - CMDQ_INST_SIZE;
> > }
> >
> > int cmdq_pkt_write(struct cmdq_pkt *pkt, u8 subsys, u16 offset, u32 value)
> > {
> > - u32 arg_a = (offset & CMDQ_ARG_A_WRITE_MASK) |
> > - (subsys << CMDQ_SUBSYS_SHIFT);
> > + struct cmdq_instruction *inst;
> > +
> > + inst = cmdq_pkt_append_command(pkt);
> > + if (!inst)
> > + return -ENOMEM;
> > +
> > + inst->op = CMDQ_CODE_WRITE;
> > + inst->value = value;
> > + inst->offset = offset;
> > + inst->subsys = subsys;
> >
>
> I can see that using cmdq_instruction will make the code more readable, but I
> dislike the approach that cmdq_pkt_append_command returns a pointer where we
> write the instruction to. Better we pass inst to cmdq_pkt_append_command() and
> write it there to cmd_ptr.
>
> I think this way we can get rid of explicitly setting the memory to zero:
> *(u64 *)(pkt->va_base + pkt->cmd_buf_size) = 0;
>
> And if we pass the inst to the append_command we don't have to change the return
> value handling of cmdq_pkt_append_command(), which makes the patch easier to
> understand.
Ok, I will change and resend it.
>
> > - return cmdq_pkt_append_command(pkt, CMDQ_CODE_WRITE, arg_a, value);
> > + return 0;
> > }
> > EXPORT_SYMBOL(cmdq_pkt_write);
> >
> > int cmdq_pkt_write_mask(struct cmdq_pkt *pkt, u8 subsys,
> > u16 offset, u32 value, u32 mask)
> > {
> > - u32 offset_mask = offset;
> > - int err = 0;
> > + struct cmdq_instruction *inst;
> > + u16 offset_mask = offset;
> >
> > if (mask != 0xffffffff) {
> > - err = cmdq_pkt_append_command(pkt, CMDQ_CODE_MASK, 0, ~mask);
> > + inst = cmdq_pkt_append_command(pkt);
> > + if (!inst)
> > + return -ENOMEM;
> > +
> > + inst->op = CMDQ_CODE_MASK;
> > + inst->mask = ~mask;
> > offset_mask |= CMDQ_WRITE_ENABLE_MASK;
> > }
> > - err |= cmdq_pkt_write(pkt, value, subsys, offset_mask);
> >
> > - return err;
> > + return cmdq_pkt_write(pkt, subsys, offset_mask, value);
> > }
> > EXPORT_SYMBOL(cmdq_pkt_write_mask);
> >
> > int cmdq_pkt_wfe(struct cmdq_pkt *pkt, u16 event)
> > {
> > - u32 arg_b;
> > + struct cmdq_instruction *inst;
> >
> > if (event >= CMDQ_MAX_EVENT)
> > return -EINVAL;
> >
> > - /*
> > - * WFE arg_b
> > - * bit 0-11: wait value
> > - * bit 15: 1 - wait, 0 - no wait
> > - * bit 16-27: update value
> > - * bit 31: 1 - update, 0 - no update
> > - */
>
> I have no strong opinion of CMDQ_WFE_OPTION but if you want to introduce it,
> then please copy the comment over to include/linux/mailbox/mtk-cmdq-mailbox.h
Ok. let's move the descriptions to header.
>
> Just one question, why did you call it _OPTION? It's not really expressive for me.
Actually, _OPTION is come from our hardware design name...
>
> > - arg_b = CMDQ_WFE_UPDATE | CMDQ_WFE_WAIT | CMDQ_WFE_WAIT_VALUE;
> > + inst = cmdq_pkt_append_command(pkt);
> > + if (!inst)
> > + return -ENOMEM;
> > +
> > + inst->op = CMDQ_CODE_WFE;
> > + inst->value = CMDQ_WFE_OPTION;
> > + inst->event = event;
> >
> > - return cmdq_pkt_append_command(pkt, CMDQ_CODE_WFE, event, arg_b);
> > + return 0;
> > }
> > EXPORT_SYMBOL(cmdq_pkt_wfe);
> >
> > int cmdq_pkt_clear_event(struct cmdq_pkt *pkt, u16 event)
> > {
> > + struct cmdq_instruction *inst;
> > +
> > if (event >= CMDQ_MAX_EVENT)
> > return -EINVAL;
> >
> > - return cmdq_pkt_append_command(pkt, CMDQ_CODE_WFE, event,
> > - CMDQ_WFE_UPDATE);
> > + inst = cmdq_pkt_append_command(pkt);
> > + if (!inst)
> > + return -ENOMEM;
> > +
> > + inst->op = CMDQ_CODE_WFE;
> > + inst->value = CMDQ_WFE_UPDATE;
> > + inst->event = event;
> > +
> > + return 0;
> > }
> > EXPORT_SYMBOL(cmdq_pkt_clear_event);
> >
> > static int cmdq_pkt_finalize(struct cmdq_pkt *pkt)
> > {
> > - int err;
> > + struct cmdq_instruction *inst;
> > +
> > + inst = cmdq_pkt_append_command(pkt);
> > + if (!inst)
> > + return -ENOMEM;
> >
> > - /* insert EOC and generate IRQ for each command iteration */
>
> Please don't delete the comment.
>
> > - err = cmdq_pkt_append_command(pkt, CMDQ_CODE_EOC, 0, CMDQ_EOC_IRQ_EN);
> > + inst->op = CMDQ_CODE_EOC;
> > + inst->value = CMDQ_EOC_IRQ_EN;
> >
> > - /* JUMP to end */
>
> Same here.
>
> Regards,
> Matthias
>
> > - err |= cmdq_pkt_append_command(pkt, CMDQ_CODE_JUMP, 0, CMDQ_JUMP_PASS);
> > + inst = cmdq_pkt_append_command(pkt);
> > + if (!inst)
> > + return -ENOMEM;
> > +
> > + inst->op = CMDQ_CODE_JUMP;
> > + inst->value = CMDQ_JUMP_PASS;
> >
> > - return err;
> > + return 0;
> > }
> >
> > static void cmdq_pkt_flush_async_cb(struct cmdq_cb_data data)
> > diff --git a/include/linux/mailbox/mtk-cmdq-mailbox.h b/include/linux/mailbox/mtk-cmdq-mailbox.h
> > index 911475da7a53..c8adedefaf42 100644
> > --- a/include/linux/mailbox/mtk-cmdq-mailbox.h
> > +++ b/include/linux/mailbox/mtk-cmdq-mailbox.h
> > @@ -19,6 +19,8 @@
> > #define CMDQ_WFE_UPDATE BIT(31)
> > #define CMDQ_WFE_WAIT BIT(15)
> > #define CMDQ_WFE_WAIT_VALUE 0x1
> > +#define CMDQ_WFE_OPTION (CMDQ_WFE_UPDATE | CMDQ_WFE_WAIT | \
> > + CMDQ_WFE_WAIT_VALUE)
> > /** cmdq event maximum */
> > #define CMDQ_MAX_EVENT 0x3ff
> >
> >
--
Bibby
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [linux-sunxi] [PATCH v6 1/3] ASoC: sun4i-i2s: incorrect regmap for A83T
From: Chen-Yu Tsai @ 2019-08-27 4:13 UTC (permalink / raw)
To: Code Kipper
Cc: Linux-ALSA, linux-kernel, Maxime Ripard, Liam Girdwood,
Andrea Venturi (pers), linux-sunxi, Mark Brown, linux-arm-kernel
In-Reply-To: <20190826180734.15801-2-codekipper@gmail.com>
On Tue, Aug 27, 2019 at 2:07 AM <codekipper@gmail.com> wrote:
>
> From: Marcus Cooper <codekipper@gmail.com>
>
> The regmap configuration is set up for the legacy block on the
> A83T whereas it uses the new block with a larger register map.
Looking at the code Allwinner previously released [1], that doesn't seem to be
the case. Keep in mind that the register map shown in the user manual is for
the TDM interface, which we don't actually support right now.
The file shows the base address as 0x01c22800, and the last defined register
is SUNXI_RXCHMAP at 0x3c.
The I2S driver [2] also shows that it is the old register map size, but with
TX_FIFO and INT_STA swapped around. This might mean that it would need a
separate regmap_config, as the read/write callbacks need to be changed to
fit the swapped registers.
Finally, the TDM driver [3], which matches the TDM section in the manual, shows
a larger register map.
A83T is SUN8IW6, while SUN8IW7 refers to the H3.
ChenYu
[1] https://github.com/allwinner-zh/linux-3.4-sunxi/blob/master/sound/soc/sunxi/hdmiaudio/sunxi-hdmipcm.h
[2] https://github.com/allwinner-zh/linux-3.4-sunxi/blob/master/sound/soc/sunxi/i2s0/sunxi-i2s0.h
[3] https://github.com/allwinner-zh/linux-3.4-sunxi/blob/master/sound/soc/sunxi/daudio0/sunxi-daudio0.h
> Fixes: 21faaea1343f ("ASoC: sun4i-i2s: Add support for A83T")
> Signed-off-by: Marcus Cooper <codekipper@gmail.com>
> ---
> sound/soc/sunxi/sun4i-i2s.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/sound/soc/sunxi/sun4i-i2s.c b/sound/soc/sunxi/sun4i-i2s.c
> index 57bf2a33753e..34575a8aa9f6 100644
> --- a/sound/soc/sunxi/sun4i-i2s.c
> +++ b/sound/soc/sunxi/sun4i-i2s.c
> @@ -1100,7 +1100,7 @@ static const struct sun4i_i2s_quirks sun6i_a31_i2s_quirks = {
> static const struct sun4i_i2s_quirks sun8i_a83t_i2s_quirks = {
> .has_reset = true,
> .reg_offset_txdata = SUN8I_I2S_FIFO_TX_REG,
> - .sun4i_i2s_regmap = &sun4i_i2s_regmap_config,
> + .sun4i_i2s_regmap = &sun8i_i2s_regmap_config,
> .field_clkdiv_mclk_en = REG_FIELD(SUN4I_I2S_CLK_DIV_REG, 8, 8),
> .field_fmt_wss = REG_FIELD(SUN4I_I2S_FMT0_REG, 0, 2),
> .field_fmt_sr = REG_FIELD(SUN4I_I2S_FMT0_REG, 4, 6),
> --
> 2.23.0
>
> --
> You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe@googlegroups.com.
> To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/20190826180734.15801-2-codekipper%40gmail.com.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 2/2] arm: Add DRM_MSM to defconfigs with ARCH_QCOM
From: Bjorn Andersson @ 2019-08-27 4:49 UTC (permalink / raw)
To: Linus Walleij
Cc: Geert Uytterhoeven, Tony Lindgren, Catalin Marinas, Miquel Raynal,
Leonard Crestez, Will Deacon, Marek Szyprowski, Anson Huang,
Russell King, Krzysztof Kozlowski, Marcin Juszkiewicz, Andy Gross,
Jagan Teki, Brian Masney, Alexandre Torgue, Arnd Bergmann, MSM,
Maxime Ripard, Enric Balletbo i Serra, Jordan Crouse,
Simon Horman, Fabrice Gasnier, Linux ARM, freedreno,
linux-kernel@vger.kernel.org, Yannick Fertr?, Dinh Nguyen,
Olof Johansson, Shawn Guo, Frank Rowand
In-Reply-To: <CACRpkdbtPo9dr7E2hZ4=fEWTXappWTaypKJyd9M2jz0tYu7HXw@mail.gmail.com>
On Thu 22 Aug 23:52 PDT 2019, Linus Walleij wrote:
> On Tue, Aug 13, 2019 at 4:46 PM Jordan Crouse <jcrouse@codeaurora.org> wrote:
>
> > Now that CONFIG_DRM_MSM is no longer default 'y' add it as a module to all
> > ARCH_QCOM enabled defconfigs to restore the previous expected build
> > behavior.
> >
> > Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
>
> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
>
> I suppose Andy will pick this up?
>
Not sure why, but this patch isn't in any of my mailboxes. So thanks for
the reminder, I've picked it from patchworks for 5.4.
Regards,
Bjorn
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] rpmsg: virtio_rpmsg_bus: replace "%p" with "%pK"
From: Bjorn Andersson @ 2019-08-27 5:10 UTC (permalink / raw)
To: Suman Anna
Cc: linux-arm-kernel, linux-remoteproc, linux-kernel, Loic Pallardy
In-Reply-To: <40831f80-1e36-66ca-b8e5-684d46ba167e@ti.com>
On Fri 09 Aug 13:25 PDT 2019, Suman Anna wrote:
> Hi Bjorn,
>
Hi Suman
> On 10/23/18 8:19 PM, Suman Anna wrote:
> > The virtio_rpmsg_bus driver uses the "%p" format-specifier for
> > printing the vring buffer address. This prints only a hashed
> > pointer even for previliged users. Use "%pK" instead so that
> > the address can be printed during debug using kptr_restrict
> > sysctl.
>
> Seems to have been lost among the patches, can you pick up this trivial
> patch for 5.4? Should apply cleanly on the latest HEAD as well.
>
I share Andrew's question regarding what benefit you have from knowing
this value. Should we not just remove the va from the print? Or do you
actually have a use case for it?
Regards,
Bjorn
> regards
> Suman
>
> >
> > Signed-off-by: Suman Anna <s-anna@ti.com>
> > ---
> > drivers/rpmsg/virtio_rpmsg_bus.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/rpmsg/virtio_rpmsg_bus.c b/drivers/rpmsg/virtio_rpmsg_bus.c
> > index f29dee731026..1345f373a1a0 100644
> > --- a/drivers/rpmsg/virtio_rpmsg_bus.c
> > +++ b/drivers/rpmsg/virtio_rpmsg_bus.c
> > @@ -950,7 +950,7 @@ static int rpmsg_probe(struct virtio_device *vdev)
> > goto vqs_del;
> > }
> >
> > - dev_dbg(&vdev->dev, "buffers: va %p, dma %pad\n",
> > + dev_dbg(&vdev->dev, "buffers: va %pK, dma %pad\n",
> > bufs_va, &vrp->bufs_dma);
> >
> > /* half of the buffers is dedicated for RX */
> >
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] drm/meson: vclk: use the correct G12A frac max value
From: Martin Blumenstingl @ 2019-08-27 5:40 UTC (permalink / raw)
To: Neil Armstrong; +Cc: linux-arm-kernel, linux-amlogic, linux-kernel, dri-devel
In-Reply-To: <20190826144647.17302-1-narmstrong@baylibre.com>
On Mon, Aug 26, 2019 at 4:47 PM Neil Armstrong <narmstrong@baylibre.com> wrote:
>
> When calculating the HDMI PLL settings for a DMT mode PHY frequency,
> use the correct max fractional PLL value for G12A VPU.
>
> With this fix, we can finally setup the 1024x76-60 mode.
nit-pick: is this really 1024x76 or 1024x768?
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox