Convert the device tree bindings for the MISC register block found on
NVIDIA Tegra SoCs from plain text to json-schema format.
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Document the variant of the memory controller and external memory
controllers found on Tegra234 and add some memory client and SMMU
stream ID definitions for use in device tree files.
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Add YAML device tree bindings for the Tegra NVENC and NVJPG Host1x
engines.
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Thierry Reding <treding@nvidia.com>
The #interconnect-cells properties are required to hook up memory
clients to the MC/EMC in interconnects properties. Add a description for
these properties.
For the nested EMC controller, the list of required properties was
missing. Add it so that the validation can be more strict.
Also, allow multiple reg entries required by Tegra194 and later.
While at it, also remove the dummy BPMP node from the example because it
is incomplete and fails validation. It's also not necessary for this
file and the BPMP DT schema already has a full example.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Tegra SoCs have extra on-chip RAM that can be used for inter-processor
communication. Tegra186 and later make use of it to establish a two-way
channel between the CCPLEX and BPMP. Add missing compatible strings for
Tegra186 and Tegra194 as well as a new compatible string for Tegra234.
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Add a few more clocks that will be used in follow-up patches to enable
more functionality on Tegra234.
Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Add the compatible strings for the Jetson AGX Orin and the
corresponding developer kit.
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Add descriptions to entries that were missing one and don't try to
combine multiple entries into one to avoid confusion.
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Pointless to maintain a head/tail for the list, as we never need to
access the tail. Entries are always LIFO for cache hotness reasons.
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
The batched completions only deal with non-partial requests anyway,
and it doesn't deal with any requests that have errors. Add a completion
handler that assumes it's a full request and that it's all being ended
successfully.
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
The prima driver facilitates the direct programming of beacon filter tables via
SMD commands.
The purpose of beacon filters is quote:
/* When beacon filtering is enabled, firmware will
* analyze the selected beacons received during BMPS,
* and monitor any changes in the IEs as listed below.
* The format of the table is:
* - EID
* - Check for IE presence
* - Byte offset
* - Byte value
* - Bit Mask
* - Byte reference
*/
The default filter table looks something like this:
tBeaconFilterIe gaBcnFilterTable[12] =
{
{ WLAN_EID_DS_PARAMS, 0u, { 0u, 0u, 0u, 0u } },
{ WLAN_EID_ERP_INFO, 0u, { 0u, 0u, 248u, 0u } },
{ WLAN_EID_EDCA_PARAM_SET, 0u, { 0u, 0u, 240u, 0u } },
{ WLAN_EID_QOS_CAPA, 0u, { 0u, 0u, 240u, 0u } },
{ WLAN_EID_CHANNEL_SWITCH, 1u, { 0u, 0u, 0u, 0u } },
{ WLAN_EID_QUIET, 1u, { 0u, 0u, 0u, 0u } },
{ WLAN_EID_HT_OPERATION, 0u, { 0u, 0u, 0u, 0u } },
{ WLAN_EID_HT_OPERATION, 0u, { 1u, 0u, 248u, 0u } },
{ WLAN_EID_HT_OPERATION, 0u, { 2u, 0u, 235u, 0u } },
{ WLAN_EID_HT_OPERATION, 0u, { 5u, 0u, 253u, 0u } },
{ WLAN_EID_PWR_CONSTRAINT, 0u, { 0u, 0u, 0u, 0u } },
{ WLAN_EID_OPMODE_NOTIF, 0u, { 0u, 0u, 0u, 0u } }
};
Add in an equivalent filter set as present in the prima Linux driver.
For now omit the beacon filter "rem" command as the driver does not have an
explicit call to that SMD command. The filter mask should only count when
we are inside BMPS anyway.
Replicating the ability to program the filter table gives us scope to add and
remove elements in future. For now though this patch makes the rote-copy of the
downstream Linux beacon filter table, which we can tweak as desired from now
on.
Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://lore.kernel.org/r/20211214134630.2214840-4-bryan.odonoghue@linaro.org
The comment in the header with respect to beacon filtering makes a
reference to "the structure above" and "the structure below" which would be
informative if the comment appeared in the right place but, it does not.
Fix the comment location so that it a least makes sense w/r/t the physical
location statements.
Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://lore.kernel.org/r/20211214134630.2214840-3-bryan.odonoghue@linaro.org
The beacon filter structures need to be packed. Right now its fine because
we don't yet use these structures so just pack them without marking it for
backporting.
Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Reviewed-by: Loic Poulain <loic.poulain@linaro.org>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://lore.kernel.org/r/20211214134630.2214840-2-bryan.odonoghue@linaro.org
Host DDR memory (contiguous 45 MB in mode-0 or 15 MB in mode-2)
is reserved through DT entries for firmware usage. Send the base
address from DT entries.
If DT entry is available, PCI device will work with
fixed_mem_region else host allocates multiple segments.
IPQ8074 on HK10 board supports multiple PCI devices.
IPQ8074 + QCN9074 is tested with this patch.
Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.4.0.1-01838-QCAHKSWPL_SILICONZ-1
Signed-off-by: Anilkumar Kolli <akolli@codeaurora.org>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://lore.kernel.org/r/1638789319-2950-2-git-send-email-akolli@codeaurora.org
Ath11k driver supports PCI devices such as QCN9074/QCA6390.
Ath11k firmware uses host DDR memory, DT entry is used to
reserve host DDR memory regions, send these memory base
addresses using DT entries.
Signed-off-by: Anilkumar Kolli <akolli@codeaurora.org>
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://lore.kernel.org/r/1638789319-2950-1-git-send-email-akolli@codeaurora.org
vmw_user_bo_lookup can fail to lookup user buffers, especially because
the buffer handles come from the userspace. The return value has
to be checked before the buffers are put back.
This was spotted by Dan's Smatch statick checker:
drivers/gpu/drm/vmwgfx/vmwgfx_bo.c:574 vmw_user_bo_synccpu_release()
error: uninitialized symbol 'vmw_bo'.
Signed-off-by: Zack Rusin <zackr@vmware.com>
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Fixes: 8afa13a058 ("drm/vmwgfx: Implement DRIVER_GEM")
Reviewed-by: Martin Krastev <krastevm@vmware.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211215200224.3693345-1-zack@kde.org
Before the driver had screen targets support we had to disable explicit
bringup of its infrastructure because it was breaking screen objects
support.
Since the implementation of screen targets landed there hasn't been a
reason to explicitly disable it and the options were never used.
Remove of all that unused code.
Signed-off-by: Zack Rusin <zackr@vmware.com>
Fixes: d80efd5cb3 ("drm/vmwgfx: Initial DX support")
Reviewed-by: Martin Krastev <krastevm@vmware.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211215184147.3688785-3-zack@kde.org
Old versions of the svga device used to export virtual vram, handling of
which was optimized on top of transparent hugepages support. Only very
old devices (OpenGL 2.1 support and earlier) used this code and at this
point performance differences are negligible.
Because the code requires very old hardware versions to run it has
been largely untested and unused for a long time.
Furthermore removal of the ttm hugepages support in:
commit 0d97950953 ("drm/ttm: remove ttm_bo_vm_insert_huge()")
broke the coherency mode in vmwgfx when running with hugepages.
Fixes: 0d97950953 ("drm/ttm: remove ttm_bo_vm_insert_huge()")
Signed-off-by: Zack Rusin <zackr@vmware.com>
Cc: Jason Gunthorpe <jgg@nvidia.com>
Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Cc: Christian König <christian.koenig@amd.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Martin Krastev <krastevm@vmware.com>
Reviewed-by: Maaz Mombasawala <mombasawalam@vmware.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211215184147.3688785-2-zack@kde.org
On i386 size_t is of course 32bits and using long int throws warnings,
trivially fix it by using the dedicated size_t format.
This is enough to fix the following warning found by the kernel test
robot:
drivers/gpu/drm/vmwgfx/vmwgfx_gem.c: In function 'vmw_bo_print_info':
>> drivers/gpu/drm/vmwgfx/vmwgfx_gem.c:230:33: warning: format '%ld'
expects argument of type 'long int', but argument 4 has type 'size_t'
{aka 'unsigned int'} [-Wformat=]
230 | seq_printf(m, "\t\t0x%08x: %12ld bytes %s, type = %s",
| ~~~~^
| |
| long int
| %12d
231 | id, bo->base.base.size, placement, type);
| ~~~~~~~~~~~~~~~~~~
| |
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Zack Rusin <zackr@vmware.com>
Fixes: 8afa13a058 ("drm/vmwgfx: Implement DRIVER_GEM")
Reviewed-by: Martin Krastev <krastevm@vmware.com>
Reviewed-by: Maaz Mombasawala <mombasawalam@vmware.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211215184147.3688785-1-zack@kde.org
Add support for the LCD controller present on JZ4780 SoCs.
This SoC uses 8-byte descriptors which extend the current
4-byte descriptors used for other Ingenic SoCs.
Tested on MIPS Creator CI20 board.
Signed-off-by: Paul Boddie <paul@boddie.org.uk>
Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
Signed-off-by: Paul Cercueil <paul@crapouillou.net>
Link: https://patchwork.freedesktop.org/patch/msgid/caf9e56b64b0717563e03172b30fa03736e92e15.1638470392.git.hns@goldelico.com
This changes the way the regmap is allocated to prepare for the
later addition of the JZ4780 which has more registers and bits
than the others.
Therefore we make the regmap as big as the reg property in
the device tree tells.
Suggested-by: Paul Cercueil <paul@crapouillou.net>
Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
Signed-off-by: Paul Cercueil <paul@crapouillou.net>
Link: https://patchwork.freedesktop.org/patch/msgid/ee65e70e91268b3963f8a6581c8aa6c3b643c53e.1638470392.git.hns@goldelico.com
Jay Chen reported that using a kdump kernel on a GICv4.1 system
results in a RAS error being delivered when the secondary kernel
configures the ITS's view of the new VPE table.
As it turns out, that's because each RD still has a pointer to
the previous instance of the VPE table, and that particular
implementation is very upset by seeing two bits of the HW that
should point to the same table with different values.
To solve this, let's invalidate any reference that any RD has to
the VPE table when discovering the RDs. The ITS can then be
programmed as expected.
Reported-by: Jay Chen <jkchen@linux.alibaba.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Link: https://lore.kernel.org/r/20211214064716.21407-1-jkchen@linux.alibaba.com
Link: https://lore.kernel.org/r/20211216144804.1578566-1-maz@kernel.org
The find.h APIs are designed to be used only on unsigned long arguments.
This can technically result in a over-read, but it is harmless in this
case. Regardless, fix it to avoid the warning seen under -Warray-bounds,
which we'd like to enable globally:
In file included from ./include/linux/bitmap.h:9,
from ./include/linux/cpumask.h:12,
from ./include/linux/smp.h:13,
from ./include/linux/lockdep.h:14,
from ./include/linux/mutex.h:17,
from ./include/linux/notifier.h:14,
from ./include/linux/clk.h:14,
from drivers/irqchip/irq-ingenic-tcu.c:7:
drivers/irqchip/irq-ingenic-tcu.c: In function 'ingenic_tcu_intc_cascade':
./include/linux/find.h:40:23: warning: array subscript 'long unsigned int[0]' is partly outside array bounds of 'uint32_t[1]' {aka 'unsigned int[1]'} [-Warray-bounds]
40 | val = *addr & GENMASK(size - 1, offset);
| ^~~~~
drivers/irqchip/irq-ingenic-tcu.c:30:18: note: while referencing 'irq_reg'
30 | uint32_t irq_reg, irq_mask;
| ^~~~~~~
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20211215232457.2069969-1-keescook@chromium.org
imx_gpcv2_instance will not be updated after init, so mark it with
__ro_after_init.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Lucas Stach <l.stach@pengutronix.de>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20211214084711.1357325-1-peng.fan@oss.nxp.com
Florian Westphal says:
====================
fib: merge nl policies
v4: resend with fixed subject line. I preserved review tags
from David Ahern.
v3: drop first two patches, otherwise unchanged.
This series merges the different (largely identical) nla policies.
v2 also squashed the ->suppress() implementation, I've dropped this.
Problem is that it needs ugly ifdef'ry to avoid build breakage
with CONFIG_INET=n || IPV6=n.
Given that even microbenchmark doesn't show any noticeable improvement
when ->suppress is inlined (it uses INDIRECT_CALLABLE) i decided to toss
the patch instead of adding more ifdefs.
====================
Link: https://lore.kernel.org/r/20211216120507.3299-1-fw@strlen.de
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Now that there is only one fib nla_policy there is no need to
keep the macro around. Place it where its used.
Signed-off-by: Florian Westphal <fw@strlen.de>
Reviewed-by: David Ahern <dsahern@kernel.org>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The attributes are identical in all implementations so move the ipv4 one
into the core and remove the per-family nla policies.
Signed-off-by: Florian Westphal <fw@strlen.de>
Reviewed-by: David Ahern <dsahern@kernel.org>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The signal setup code and evlist__prepare_workload() can be used for
other subcommands. Let's move them out of the __cmd_ftrace(). Then
it doesn't need to pass argc and argv.
On the other hand, select_tracer() is specific to the 'trace'
subcommand so it'd better moving it into the __cmd_ftrace().
Signed-off-by: Namhyung Kim <namhyung@kernel.org>
Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Athira Jajeev <atrajeev@linux.vnet.ibm.com>
Cc: Changbin Du <changbin.du@gmail.com>
Cc: Ian Rogers <irogers@google.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Song Liu <songliubraving@fb.com>
Cc: Stephane Eranian <eranian@google.com>
Link: https://lore.kernel.org/r/20211215185154.360314-3-namhyung@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
The registers for ARM and ARM64 are enumerated using two enums that have
the same name. In order to be able to import both headers, the name of
one can be replaced using the C preprocessor like so:
#define perf_event_arm_regs perf_event_arm64_regs
#include <asm/perf_regs.h>
#undef perf_event_arm_regs
This patch updates all imports of ARM64's perf_regs.h in order to
prevent the naming collision.
Reviewed-by: Athira Jajeev <atrajeev@linux.vnet.ibm.com>
Signed-off-by: German Gomez <german.gomez@arm.com>
Tested-by: Athira Jajeev <atrajeev@linux.vnet.ibm.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: John Garry <john.garry@huawei.com>
Cc: Leo Yan <leo.yan@linaro.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Will Deacon <will@kernel.org>
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-csky@vger.kernel.org
Cc: linux-riscv@lists.infradead.org
Link: https://lore.kernel.org/r/20211207180653.1147374-3-german.gomez@arm.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Refactors code for gathering PID infos, it creates the function
nsinfo__get_nspid() to parse process 'status' node in folder '/proc'.
Base on the refactoring, this patch introduces a new helper
nsinfo__is_in_root_namespace(), it returns true when the caller runs in
the root PID namespace.
Signed-off-by: Leo Yan <leo.yan@linaro.org>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Alexei Starovoitov <ast@kernel.org>
Cc: Andrii Nakryiko <andrii@kernel.org>
Cc: Daniel Borkmann <daniel@iogearbox.net>
Cc: Jin Yao <yao.jin@linux.intel.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: John Fastabend <john.fastabend@gmail.com>
Cc: John Garry <john.garry@huawei.com>
Cc: KP Singh <kpsingh@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Martin KaFai Lau <kafai@fb.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Song Liu <songliubraving@fb.com>
Cc: Yonatan Goldschmidt <yonatan.goldschmidt@granulate.io>
Cc: Yonghong Song <yhs@fb.com>
Cc: bpf@vger.kernel.org
Cc: netdev@vger.kernel.org
Link: http://lore.kernel.org/lkml/20211212134721.1721245-2-leo.yan@linaro.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
There is a spelling mistake in a __T_VERBOSE message. Fix it.
Signed-off-by: Colin Ian King <colin.i.king@gmail.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: kernel-janitors@vger.kernel.org
Link: http://lore.kernel.org/lkml/20211212222122.478537-1-colin.i.king@gmail.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Use IS_ERR_OR_NULL() to make the code cleaner.
Also if the priv is NULL, it's improper to call PTR_ERR(priv).
Signed-off-by: Miaoqian Lin <linmq006@gmail.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Alexei Starovoitov <ast@kernel.org>
Cc: Andrii Nakryiko <andrii@kernel.org>
Cc: Daniel Borkmann <daniel@iogearbox.net>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: John Fastabend <john.fastabend@gmail.com>
Cc: KP Singh <kpsingh@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Martin KaFai Lau <kafai@fb.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Song Liu <songliubraving@fb.com>
Cc: Yonghong Song <yhs@fb.com>
Cc: bpf@vger.kernel.org
Cc: netdev@vger.kernel.org
Cc: unlisted-recipients
Link: http://lore.kernel.org/lkml/20211212135613.20000-1-linmq006@gmail.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
There are two checks, one is for size when running without admin, but
this one is covered by the driver and reported on in more detail here
(builtin-record.c):
pr_err("Permission error mapping pages.\n"
"Consider increasing "
"/proc/sys/kernel/perf_event_mlock_kb,\n"
"or try again with a smaller value of -m/--mmap_pages.\n"
"(current value: %u,%u)\n",
This had the effect of artificially limiting the aux buffer size to a
value smaller than what was allowed because perf_event_mlock_kb wasn't
taken into account.
The second is to check for a power of two, but this is covered here
(evlist.c):
pr_info("rounding mmap pages size to %s (%lu pages)\n",
buf, pages);
Reviewed-by: Leo Yan <leo.yan@linaro.org>
Signed-off-by: James Clark <james.clark@arm.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: John Garry <john.garry@huawei.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
Cc: Mike Leach <mike.leach@linaro.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Suzuki Poulouse <suzuki.poulose@arm.com>
Cc: Will Deacon <will@kernel.org>
Cc: coresight@lists.linaro.org
Cc: linux-arm-kernel@lists.infradead.org
Link: https://lore.kernel.org/r/20211208115435.610101-1-james.clark@arm.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
A previous commit adds pmu events into the files
armv8-common-and-microarch.json
armv8-recommended.json
that are actually specified in an armv9 reference supplement, not armv8.
As such, naming the files with the armv8 prefix seems artificial.
This patch renames the files to reflect that these two files are for
arch std events regardless of whether they are defined in armv8 or
armv9.
Reviewed-by: John Garry <john.garry@huawei.com>
Signed-off-by: Andrew Kilroy <andrew.kilroy@arm.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Leo Yan <leo.yan@linaro.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Will Deacon <will@kernel.org>
Cc: linux-arm-kernel@lists.infradead.org
Link: https://lore.kernel.org/r/20211210123706.7490-3-andrew.kilroy@arm.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Updates the common and microarch json file to add counters available in
the Arm Neoverse N2 chip, but should also apply to other ArmV8 and ArmV9
cpus. Specified in ArmV8 architecture reference manual
https://developer.arm.com/documentation/ddi0487/gb/?lang=en
Some of the counters added to armv8-common-and-microarch.json are
specified in the ArmV9 architecture reference manual supplement
(issue A.a):
https://developer.arm.com/documentation/ddi0608/aa
The additional ArmV9 counters are
TRB_WRAP
TRCEXTOUT0
TRCEXTOUT1
TRCEXTOUT2
TRCEXTOUT3
CTI_TRIGOUT4
CTI_TRIGOUT5
CTI_TRIGOUT6
CTI_TRIGOUT7
This patch also adds files in pmu-events/arch/arm64/arm/neoverse-n2 for
perf list to output the counter names in categories.
Counters on the Neoverse N2 are stated in its reference manual:
https://developer.arm.com/documentation/102099/0000
Reviewed-by: John Garry <john.garry@huawei.com>
Signed-off-by: Andrew Kilroy <andrew.kilroy@arm.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Leo Yan <leo.yan@linaro.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Will Deacon <will@kernel.org>
Cc: linux-arm-kernel@lists.infradead.org
Link: https://lore.kernel.org/r/20211210123706.7490-2-andrew.kilroy@arm.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Use total latency info in the SPE counter packet as sample weight so
that we can see it in local_weight and (global) weight sort keys.
Maybe we can use PERF_SAMPLE_WEIGHT_STRUCT to support ins_lat as well
but I'm not sure which latency it matches. So just adding total latency
first.
Reviewed-by: Leo Yan <leo.yan@linaro.org>
Signed-off-by: Namhyung Kim <namhyung@kernel.org>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: German Gomez <german.gomez@arm.com>
Cc: Ian Rogers <irogers@google.com>
Cc: James Clark <james.clark@arm.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Stephane Eranian <eranian@google.com>
Link: http://lore.kernel.org/lkml/20211201220855.1260688-1-namhyung@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
The output of 'perf bench' gets buffered when I pipe it to a file or to
tee, in such a way that I can see it only at the end.
E.g.
$ perf bench internals synthesize -t
< output comes out fine after each test run >
$ perf bench internals synthesize -t | tee file.txt
< output comes out only at the end of all tests >
This patch resolves this issue for 'bench' and 'test' subcommands.
See, also:
$ perf bench mem all | tee file.txt
$ perf bench sched all | tee file.txt
$ perf bench internals all -t | tee file.txt
$ perf bench internals all | tee file.txt
Committer testing:
It really gets staggered, i.e. outputs in bursts, when the buffer fills
up and has to be drained to make up space for more output.
Suggested-by: Riccardo Mancini <rickyman7@gmail.com>
Signed-off-by: Sohaib Mohamed <sohaib.amhmd@gmail.com>
Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Acked-by: Jiri Olsa <jolsa@redhat.com>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Fabian Hemmer <copy@copy.sh>
Cc: Ian Rogers <irogers@google.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: http://lore.kernel.org/lkml/20211119061409.78004-1-sohaib.amhmd@gmail.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
The intel_gmbus_set_speed() function is not used anywhere, remove it.
Note drivers/gpu/drm/gma500 has its own copy called
gma_intel_gmbus_set_speed() which is used, the intel_gmbus_set_speed()
version in the i915 code is not used at all
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211121191001.252076-1-hdegoede@redhat.com
At least the Bay Trail LPSS PWM controller used with DSI panels on many
Bay Trail tablets seems to leave the PWM pin in whatever state it was
(high or low) ATM that the PWM gets disabled. Combined with some panels
not having a separate backlight-enable pin this leads to the backlight
sometimes staying on while it should not (when the pin was high during
PWM-disabling).
First calling intel_backlight_set_pwm_level() will ensure that the pin
is always low (or high for inverted brightness panels) since the passed
in duty-cycle is 0% (or 100%) when the PWM gets disabled fixing the
backlight sometimes staying on.
With the exception of ext_pwm_disable_backlight() all other
foo_disable_backlight() functions call intel_backlight_set_pwm_level()
already before disabling the backlight, so this change also aligns
ext_pwm_disable_backlight() with all the other disable() functions.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211121110032.4720-2-hdegoede@redhat.com
This was found by coccicheck:
./arch/mips/cavium-octeon/octeon-platform.c, 332, 1-7, ERROR missing
put_device; call of_find_device_by_node on line 324, but without a
corresponding object release within this function.
./arch/mips/cavium-octeon/octeon-platform.c, 395, 1-7, ERROR missing
put_device; call of_find_device_by_node on line 387, but without a
corresponding object release within this function.
./arch/mips/cavium-octeon/octeon-usb.c, 512, 3-9, ERROR missing
put_device; call of_find_device_by_node on line 515, but without a
corresponding object release within this function.
./arch/mips/cavium-octeon/octeon-usb.c, 543, 1-7, ERROR missing
put_device; call of_find_device_by_node on line 515, but without a
corresponding object release within this function.
Reported-by: Zeal Robot <zealci@zte.com.cn>
Signed-off-by: Ye Guojin <ye.guojin@zte.com.cn>
Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
The strlcpy should not be used because it doesn't limit the source
length. As linus says, it's a completely useless function if you
can't implicitly trust the source string - but that is almost always
why people think they should use it! All in all the BSD function
will lead some potential bugs.
But the strscpy doesn't require reading memory from the src string
beyond the specified "count" bytes, and since the return value is
easier to error-check than strlcpy()'s. In addition, the implementation
is robust to the string changing out from underneath it, unlike the
current strlcpy() implementation.
Thus, We prefer using strscpy instead of strlcpy.
Signed-off-by: Jason Wang <wangborong@cdjrlc.com>
Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Commit d4a451d5fc ("arch: remove the ARCH_PHYS_ADDR_T_64BIT config
symbol") removes config ARCH_PHYS_ADDR_T_64BIT with all instances of that
config refactored appropriately. Since then, it is recommended to use the
config PHYS_ADDR_T_64BIT instead.
Commit 171543e752 ("MIPS: Disallow CPU_SUPPORTS_HUGEPAGES for XPA,EVA")
introduces the expression "!(32BIT && (ARCH_PHYS_ADDR_T_64BIT || EVA))"
for config CPU_SUPPORTS_HUGEPAGES, which unintentionally refers to the
non-existing symbol ARCH_PHYS_ADDR_T_64BIT instead of the intended
PHYS_ADDR_T_64BIT.
Fix this Kconfig reference to the intended PHYS_ADDR_T_64BIT.
This issue was identified with the script ./scripts/checkkconfigsymbols.py.
I then reported it on the mailing list and Paul confirmed the mistake in
the linked email thread.
Link: https://lore.kernel.org/lkml/H8IU3R.H5QVNRA077PT@crapouillou.net/
Suggested-by: Paul Cercueil <paul@crapouillou.net>
Fixes: 171543e752 ("MIPS: Disallow CPU_SUPPORTS_HUGEPAGES for XPA,EVA")
Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com>
Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
