Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/ttm/ttm_device.c:42: warning: Function parameter or member
'ttm_global_mutex' not described in 'DEFINE_MUTEX'
drivers/gpu/drm/ttm/ttm_device.c:42: warning: expecting prototype for
ttm_global_mutex(). Prototype was for DEFINE_MUTE
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/radeon/radeon_device.c:1101: warning: This comment starts with
'/**', but isn't a kernel-doc comment. Refer
Documentation/doc-guide/kernel-doc.rst
Cc: Alex Deucher
Cc: "Christian König"
Cc: David Airlie
Cc: Daniel Vetter
Cc:
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c: In function
‘amdgpu_device_suspend’:
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:3733:6: warning: variable ‘r’ set
but not used [-Wunused-but-set-variable]
Cc: Alex Deucher
Cc: "Christian König"
Cc:
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/panel/panel-raspberrypi-touchscreen.c:33: warning: This
comment starts with '/**', but isn't a kernel-doc comment. Refer
Documentation/doc-guide/kernel-doc.rst
Cc: Thierry Reding
Cc: Sam Ravnborg
Cc: David Airlie
Cc: Daniel Ve
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/scheduler/sched_entity.c:204: warning: expecting prototype for
drm_sched_entity_kill_jobs(). Prototype was for drm_sched_entity_kill_jobs_cb()
instead
drivers/gpu/drm/scheduler/sched_entity.c:262: warning: expecting prototype for
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/ttm/ttm_tt.c:398: warning: Function parameter or member
'num_pages' not described in 'ttm_tt_mgr_init'
drivers/gpu/drm/ttm/ttm_tt.c:398: warning: Function parameter or member
'num_dma32_pages' not described in 'ttm_tt_mgr_init'
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/ttm/ttm_bo.c:293: warning: expecting prototype for function
ttm_bo_cleanup_refs(). Prototype was for ttm_bo_cleanup_refs() instead
Cc: Christian Koenig
Cc: Huang Rui
Cc: David Airlie
Cc: Daniel Vetter
Cc: Sumit Semwal
Cc: dri
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/xlnx/zynqmp_dp.c:806: warning: expecting prototype for
zynqmp_dp_link_train(). Prototype was for zynqmp_dp_train() instead
Cc: Hyun Kwon
Cc: Laurent Pinchart
Cc: David Airlie
Cc: Daniel Vetter
Cc: Michal Simek
Cc: Philipp Zab
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/xlnx/zynqmp_disp.c:101: warning: expecting prototype for enum
zynqmp_disp_id. Prototype was for enum zynqmp_disp_layer_id instead
Cc: Hyun Kwon
Cc: Laurent Pinchart
Cc: David Airlie
Cc: Daniel Vetter
Cc: Michal Simek
Cc: dri-
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/omapdrm/omap_gem.c:619: warning: expecting prototype for
omap_gem_dumb_map(). Prototype was for omap_gem_dumb_map_offset() instead
Cc: Tomi Valkeinen
Cc: David Airlie
Cc: Daniel Vetter
Cc: Sumit Semwal
Cc: "Christian König"
C
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/omapdrm/omap_irq.c:114: warning: expecting prototype for
enable_vblank(). Prototype was for omap_irq_enable_vblank() instead
drivers/gpu/drm/omapdrm/omap_irq.c:140: warning: expecting prototype for
disable_vblank(). Prototype was
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/nouveau/nouveau_ioc32.c:52: warning: Function parameter or
member 'filp' not described in 'nouveau_compat_ioctl'
drivers/gpu/drm/nouveau/nouveau_ioc32.c:52: warning: Function parameter or
member 'cmd' not described in 'nouveau_co
Fixes the following W=1 kernel build warning(s):
drivers/gpu/host1x/bus.c:774: warning: Excess function parameter 'key'
description in '__host1x_client_register'
Cc: Thierry Reding
Cc: dri-de...@lists.freedesktop.org
Cc: linux-te...@vger.kernel.org
Signed-off-by: Lee Jones
---
drivers/gpu/ho
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/nouveau/nouveau_svm.c: In function ‘nouveau_pfns_map’:
drivers/gpu/drm/nouveau/nouveau_svm.c:810:6: warning: variable ‘ret’ set but
not used [-Wunused-but-set-variable]
Cc: Ben Skeggs
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/nouveau/dispnv50/disp.c:2599:1: warning: no previous prototype
for ‘nv50_display_create’ [-Wmissing-prototypes]
Cc: Ben Skeggs
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-de...@lists.freedesktop.org
Cc: nouv...@lists.freedesktop
Fixes the following build error:
drivers/gpu/drm/nouveau/dispnv50/disp.c:2530:1: error: conflicting types for
‘nv50_display_fini’
In file included from drivers/gpu/drm/nouveau/dispnv50/disp.c:71:
drivers/gpu/drm/nouveau/nv50_display.h:36:6: note: previous declaration of
‘nv50_display_fini’ wa
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/nouveau/nouveau_ioc32.c:2: warning: Cannot understand * file
mga_ioc32.c
Cc: Ben Skeggs
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-de...@lists.freedesktop.org
Cc: nouv...@lists.freedesktop.org
Signed-off-by: Lee Jones
---
dr
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/nouveau/dispnv50/headc57d.c:173:1: warning: no previous
prototype for ‘headc57d_olut’ [-Wmissing-prototypes]
Cc: Ben Skeggs
Cc: David Airlie
Cc: Daniel Vetter
Cc: Lyude Paul
Cc: dri-de...@lists.freedesktop.org
Cc: nouv...@list
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/nouveau/nouveau_bo.c: In function ‘nouveau_ttm_tt_populate’:
drivers/gpu/drm/nouveau/nouveau_bo.c:1228:17: warning: variable ‘dev’ set but
not used [-Wunused-but-set-variable]
drivers/gpu/drm/nouveau/nouveau_bo.c: In function ‘no
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/nouveau/dispnv50/disp.c: In function ‘nv50_mstm_cleanup’:
drivers/gpu/drm/nouveau/dispnv50/disp.c:1357:6: warning: variable ‘ret’ set
but not used [-Wunused-but-set-variable]
Cc: Ben Skeggs
Cc: David Airlie
Cc: Daniel Vetter
C
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/nouveau/dispnv04/crtc.c:462: warning: Function parameter or
member 'crtc' not described in 'nv_crtc_mode_set_regs'
drivers/gpu/drm/nouveau/dispnv04/crtc.c:462: warning: Function parameter or
member 'mode' not described in 'nv_crt
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/nouveau/nouveau_display.c: In function
‘nouveau_framebuffer_new’:
drivers/gpu/drm/nouveau/nouveau_display.c:309:15: warning: variable ‘width’
set but not used [-Wunused-but-set-variable]
Cc: Ben Skeggs
Cc: David Airlie
Cc: Dan
In the macro for_each_oldnew_plane_in_state() 'new_plane_state' is provided
as a container for state->planes[i].new_state, but is not utilised in
some use-cases, so we fake-use it instead.
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/nouveau/nvkm/engine/gr/gf100.c:992: warning: Function
parameter or member 'gr' not described in 'gf100_gr_wait_idle'
Cc: Ben Skeggs
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-de...@lists.freedesktop.org
Cc: nouv...@lists.freede
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/msm/dp/dp_display.c: In function
‘dp_display_usbpd_attention_cb’:
drivers/gpu/drm/msm/dp/dp_display.c:496:19: warning: variable ‘hpd’ set but
not used [-Wunused-but-set-variable]
Cc: Rob Clark
Cc: Sean Paul
Cc: David Airlie
C
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/nouveau/nvkm/subdev/volt/gk20a.c:53: warning: Function
parameter or member 'speedo' not described in 'gk20a_volt_get_cvb_voltage'
drivers/gpu/drm/nouveau/nvkm/subdev/volt/gk20a.c:53: warning: Function
parameter or member 's_scale
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/nouveau/dispnv50/disp.c:1381:6: warning: variable ‘ret’ set
but not used [-Wunused-but-set-variable]
Cc: Ben Skeggs
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-de...@lists.freedesktop.org
Cc: nouv...@lists.freedesktop.org
Signed
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c:584: warning: Function
parameter or member 'init' not described in 'init_reserved'
drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c:611: warning: Function
parameter or member 'init' not described in
This set is part of a larger effort attempting to clean-up W=1
kernel builds, which are currently overwhelmingly riddled with
niggly little warnings.
Lee Jones (40):
drm/nouveau/nvkm/subdev/bios/init: Demote obvious abuse of kernel-doc
drm/nouveau/dispnv50/disp: Remove unused variable 'ret'
Check that enough time has passed such that the modify channel message
has been processed before taking a CPU offline.
Signed-off-by: Andrea Parri (Microsoft)
---
drivers/hv/hv.c | 56 ++---
1 file changed, 53 insertions(+), 3 deletions(-)
diff --git
Introduce the CHANNELMSG_MODIFYCHANNEL_RESPONSE message type, and code
to receive and process such a message.
Signed-off-by: Andrea Parri (Microsoft)
Reviewed-by: Michael Kelley
---
drivers/hv/channel.c | 99 ---
drivers/hv/channel_mgmt.c | 42 ++
Hyper-V has added VMBus protocol version 5.3. Allow Linux guests to
negotiate the new version on version of Hyper-V that support it.
Signed-off-by: Andrea Parri (Microsoft)
---
drivers/hv/connection.c | 3 ++-
include/linux/hyperv.h | 2 ++
2 files changed, 4 insertions(+), 1 deletion(-)
diff
Changes since v2[1]:
- fix VMbus protocol version name
- add Reviewed-by: tag
- refactor/simplyfy changes in hv_synic_cleanup()
Changes since v1[2]:
- rebase on hyperv-next
- split changes into three patches
- fix&simplify error handling in send_modifychannel_with_ack()
- remove resc
On Fri, Apr 16, 2021 at 04:26:19PM +0200, Auger Eric wrote:
> This was largely done during several confs including plumber, KVM forum,
> for several years. Also API docs were shared on the ML. I don't remember
> any voice was raised at those moments.
I don't think anyone objects to the high level
Add some words and examples to help understanding of
Intel hybrid perf support.
Signed-off-by: Jin Yao
---
v4:
- Update due to PERF_TYPE_HARDWARE and PERF_TYPE_HW_CACHE
are extended to be PMU type aware.
tools/perf/Documentation/intel-hybrid.txt | 214 ++
tools/perf/D
Hi,
On Wed, Apr 14, 2021 at 11:10 AM Matthias Kaehlcke wrote:
>
> Add ADC and thermal monitor configuration for skin temperature,
> plus a thermal zone that monitors the skin temperature and uses
> the big cores as cooling devices.
>
> CoachZ rev1 is stuffed with an incompatible thermistor for th
Joe Perches writes:
On Fri, 2021-04-16 at 14:56 +0100, Chris Down wrote:
Any better suggestions? :-)
A gcc plugin that looks for functions marked __printf(fmt, pos)
so any const fmt is stored.
I fail to see any way in which that can solve the problem described, which is
mobility of the leve
On Fri, 16 Apr 2021, Joe Perches wrote:
> > I'm not sure if that complex message
> > routing via `blogic_msg' is worth having even, rather than calling
> > `printk' or suitable variants directly.
>
> It's to allow the message content to be added to the internal
> &adapter->msgbuf[adapter-
alloc_calls and free_calls implementation in sysfs have two issues,
one is PAGE_SIZE limitiation of sysfs and other is it does not adhere
to "one value per file" rule.
To overcome this issues, move the alloc_calls and free_calls implemeation
to debugfs.
Signed-off-by: Faiyaz Mohammed
---
includ
The following commit has been merged into the x86/core branch of tip:
Commit-ID: 2c88d45edbb89029c1190bb3b136d2602f057c98
Gitweb:
https://git.kernel.org/tip/2c88d45edbb89029c1190bb3b136d2602f057c98
Author:Alison Schofield
AuthorDate:Wed, 10 Mar 2021 11:02:33 -08:00
Committ
On 4/16/21 5:35 AM, Michal Hocko wrote:
> I have to confess that I haven't grasped the initialization
> completely. There is a nice comment explaining a 2 socket system with
> 3 different NUMA nodes attached to it with one node being terminal.
> This is OK if the terminal node is PMEM but h
Hi,
On 4/16/21 4:05 PM, Jason Gunthorpe wrote:
> On Fri, Apr 16, 2021 at 03:38:02PM +0200, Auger Eric wrote:
>
>> The redesign requirement came pretty late in the development process.
>> The iommu user API is upstream for a while, the VFIO interfaces have
>> been submitted a long time ago and unde
On Thu, 15 Apr 2021, Hsin-Yi Wang wrote:
> pm_resume and pm_suspend might be conflict with the ones defined in
> include/linux/suspend.h. Rename pm_resume{suspend} to
> i915_pm_resume{suspend} since they are only used here.
I agree with the rationale here.
Do you need this to be part of your ser
From: Amit Kumar Mahapatra
During a transfer the driver filled the fifo with 4bytes,
even if the data that needs to be transfer is less that 4bytes.
This resulted in slab-out-of-bounds bug in KernelAddressSanitizer.
This patch resolves slab-out-of-bounds bug by filling the fifo
with the number o
From: Quanyang Wang
When handling op->addr, it is using the buffer "tmpbuf" which has been
freed. This will trigger a use-after-free KASAN warning. Let's use
temporary variables to store op->addr.val and op->cmd.opcode to fix
this issue.
Signed-off-by: Quanyang Wang
---
drivers/spi/spi-zynqmp-
From: Quanyang Wang
The spi controller supports 44-bit address space on AXI in DMA mode,
so set dma_addr_t width to 44-bit to avoid using a swiotlb mapping.
In addition, if dma_map_single fails, it should return immediately
instead of continuing doing the DMA operation which bases on invalid
addr
From: Quanyang Wang
After calling platform_set_drvdata(pdev, xqspi) in probe, the return
value of dev_get_drvdata(dev) is a pointer to struct zynqmp_qspi but
not struct spi_controller. A wrong structure type passing to the
functions spi_controller_suspend/resume will hang the system.
And we shou
From: Quanyang Wang
The clks "pclk" and "ref_clk" are enabled twice during the probe. The
first time is in the function zynqmp_qspi_probe and the second time is
in zynqmp_qspi_setup_op which is called by devm_spi_register_controller.
Then calling zynqmp_qspi_remove (rmmod this module) to disable
From: Quanyang Wang
Hi all,
V2:
Remove all "Fixes:" tags since they base on some patches are not
with "Fixes:".
V1:
This series fix some issues that occurs in spi-zynqmp-gqspi.c.
Thanks,
Quanyang
Amit Kumar Mahapatra (1):
spi: spi-zynqmp-gqspi: Resolved slab-out-of-bounds bug
Quanyang Wang
On Fri, Apr 16, 2021 at 1:24 PM Peter Zijlstra wrote:
>
> IMO RAII is over-valued, but just in case you care, the below seems to
> work just fine. No fancy new language needed, works today. Similarly you
> can create refcount_t guards, or with a little more work full blown
> smart_ptr crud.
Pleas
On Fri, Apr 16, 2021 at 02:51:59PM +0200, Greg Kroah-Hartman wrote:
> On Fri, Apr 16, 2021 at 03:31:16PM +0300, Andy Shevchenko wrote:
> > The infamous commit c440eee1a7a1 ("Staging: fbtft: Switch to
> > the GPIO descriptor interface") broke GPIO handling completely.
> > It has already four commits
The custom ->reset() repeats the generic one, replace it.
Note, in newer kernels the context of the function is a sleeping one,
it's fine to switch over to the sleeping functions. Keeping the reset
line asserted longer than 20 microseconds is also okay, it's an idling
state of the hardware.
Fixes
When requesting GPIO line the probe can be deferred.
In such case don't spam logs with an error message.
This can be achieved by switching to dev_err_probe().
Signed-off-by: Andy Shevchenko
---
v2: no changes
drivers/staging/fbtft/fbtft-core.c | 12
1 file changed, 4 insertions(+),
The infamous commit c440eee1a7a1 ("Staging: fbtft: Switch to
the GPIO descriptor interface") broke GPIO handling completely.
It has already four commits to rectify and it seems not enough.
In order to fix the mess here we:
1) Set default to "inactive" for all requested pins
2) Fix CS, RD, and
Now, after a few fixes we may consider the conversion to
the GPIO descriptor API is done.
Signed-off-by: Andy Shevchenko
---
v2: new patch split from the bigger fix (Greg)
drivers/staging/fbtft/TODO | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/staging/fbtft/TODO b/drivers/stag
There is a minor race in setting the fuse out request error
between fuse_abort_conn() and fuse_dev_do_read() as explained
below.
Thread-1 Thread-2
->fuse_simple_request() ->shutdown
->__fuse_request_send()
->queue_
On Fri, Apr 16, 2021 at 04:05:56PM +0200, Johan Hovold wrote:
> When DMA is enabled the receive handler runs in a threaded handler, but
> the primary handler up until very recently neither disabled interrupts
Scratch the "up until very recently" bit here since the driver still
doesn't disable inte
On Fri, Apr 16, 2021 at 02:07:49PM +0100, Wedson Almeida Filho wrote:
> On Fri, Apr 16, 2021 at 01:24:23PM +0200, Peter Zijlstra wrote:
> > int perf_event_task_enable(void)
> > {
> > + DEFINE_MUTEX_GUARD(event_mutex, ¤t->perf_event_mutex);
>
> There is nothing in C forcing developers to actua
Hello,
On Fri, Apr 16, 2021 at 06:26:15PM +0530, Pratik Sampat wrote:
> Hello Roman,
>
> I've tried the v3 patch series on a POWER9 and an x86 KVM setup.
>
> My results of the percpu_test are as follows:
> Intel KVM 4CPU:4G
> Vanilla 5.12-rc6
> # ./percpu_test.sh
> Percpu: 1952 kB
>
On 2021-04-16 19:23, Alexander Shishkin wrote:
Tao Zhang writes:
Add property "coresight-name" for coresight component name. This
allows coresight driver to read device name from device entries.
Signed-off-by: Tao Zhang
---
Documentation/devicetree/bindings/arm/coresight.txt | 2 ++
1 file
[6.343387] BUG: KASAN: slab-out-of-bounds in
acpi_cppc_processor_probe+0x15c/0xa50
[6.343474] Read of size 4 at addr 888120cf1630 by task swapper/0/1
[6.343565] CPU: 1 PID: 1 Comm: swapper/0 Tainted: G I
5.12.0.g8b1fdf9-tip #2
[6.343654] Hardware name: HP HP Sp
[+ Mark]
On Fri, 16 Apr 2021 07:22:17 +0100,
He Ying wrote:
>
> We found this problem in our kernel src tree:
>
> [ 14.816231] [ cut here ]
> [ 14.816231] kernel BUG at irq.c:99!
> [ 14.816232] Internal error: Oops - BUG: 0 [#1] SMP
> [ 14.816232] Process swapper
On Fri, Apr 16, 2021 at 01:29:04PM +0300, Paul Fertser wrote:
> Certain VRs might be configured to use only the first output channel and
> so the mode for the second will be 0. Handle this gracefully.
>
> Fixes: b9fa0a3acfd8 ("hwmon: (pmbus/core) Add support for vid mode detection
> per page base
On Tue, Apr 13, 2021 at 1:03 PM wrote:
>
> On 12.04.2021 21:29, Bartosz Golaszewski wrote:
> > EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> > content is safe
> >
> > On Mon, Apr 12, 2021 at 9:42 AM wrote:
> >>
> >> On 07.04.2021 21:37, Bartosz Golaszewski wrote:
>
When DMA is enabled the receive handler runs in a threaded handler, but
the primary handler up until very recently neither disabled interrupts
in the device or used IRQF_ONESHOT. This would lead to a deadlock if an
interrupt comes in while the threaded receive handler is running under
the port lock
The uart_unlock_and_check_sysrq() helper can be used to defer processing
of sysrq until the interrupt handler has released the port lock and is
about to return.
Since commit 81e2073c175b ("genirq: Disable interrupts for force
threaded handlers") interrupt handlers that are not explicitly requested
Use the uart_unlock_and_check_sysrq() helper to defer sysrq processing
until receive processing is done and the port lock has been released.
This allows cleaning up the console_write() implementation by not having
to work around the recursive sysrq case (by dropping locking completely)
and also ma
The first patch cleans up the interrupt handlers that rely on deferred
sysrq processing by not needlessly saving the interrupt state.
The second fixes the threaded interrupt handling of the stm32 driver
and properly fixes a couple of deadlocks that were incidentally worked
around by a recent commi
On Fri, Apr 16, 2021 at 11:27 AM 'Grygorii Strashko' via Clang Built
Linux wrote:
> On 10/04/2021 11:52, Ilias Apalodimas wrote:
> > +CC Grygorii for the cpsw part as Ivan's email is not valid anymore
> The TI platforms am3/4/5 (cpsw) and Keystone 2 (netcp) can do only 32bit DMA
> even in case of
On Fri, Apr 16, 2021 at 06:10:41PM +0800, dillon.min...@gmail.com wrote:
> From: dillon min
>
> This patch aims to fix two potential bug:
> - no lock to protect uart register in this case
>
> stm32_usart_threaded_interrupt()
> spin_lock(&port->lock);
> ...
> stm32_usart_receive_
On Wed, Apr 14, 2021 at 7:29 PM Hsin-Yi Wang wrote:
>
> cd5676db0574 ("misc: eeprom: at24: support pm_runtime control") disables
> regulator in runtime suspend. If runtime suspend is called before
> regulator disable, it will results in regulator unbalanced disabling.
>
> Signed-off-by: Hsin-Yi Wa
Some events are not supported. Only pick up some cases for hybrid.
# ./perf test 67
67: Parse and process metrics : Ok
Signed-off-by: Jin Yao
---
tools/perf/tests/parse-metric.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --gi
Since for "cycles:u' on hybrid platform, it creates two "cycles".
So the second evsel in evlist also needs initialization.
With this patch,
# ./perf test 71
71: Convert perf time to TSC: Ok
Signed-off-by: Jin Yao
---
tools/perf/tests/perf-time-to-tsc
On Fri, 2021-04-16 at 14:56 +0100, Chris Down wrote:
> Any better suggestions? :-)
A gcc plugin that looks for functions marked __printf(fmt, pos)
so any const fmt is stored.
Currently we don't support shadow stat for hybrid.
root@ssp-pwrt-002:~# ./perf stat -e cycles,instructions -a -- sleep 1
Performance counter stats for 'system wide':
12,883,109,591 cpu_core/cycles/
6,405,163,221 cpu_atom/cycles/
555,553,778 cpu_core/inst
Force to create one event "cpu_core/cycles/" by default,
otherwise in evlist__valid_sample_type, the checking of
'if (evlist->core.nr_entries == 1)' would be failed.
# ./perf test 41
41: Session topology: Ok
Signed-off-by: Jin Yao
---
tools/pe
Since for "cycles:u' on hybrid platform, it creates two "cycles".
So the number of events in evlist is not expected in next test
steps. Now we just use one event "cpu_core/cycles:u/" for hybrid.
# ./perf test 35
35: Track with sched_switch : Ok
Signed-o
For hybrid, the attr.type consists of pmu type id + original type.
There will be much changes for this test. Now we temporarily
skip this test case and TODO in future.
Signed-off-by: Jin Yao
---
tools/perf/tests/attr.c | 4
1 file changed, 4 insertions(+)
diff --git a/tools/perf/tests/attr
Add basic hybrid test cases for 'Parse event definition strings' test.
# perf test 6
6: Parse event definition strings : Ok
Signed-off-by: Jin Yao
---
tools/perf/tests/parse-events.c | 152
1 file changed, 152 insertions(+)
Since for one hw event, two hybrid events are created.
For example,
evsel->idx evsel__name(evsel)
0 cycles
1 cycles
2 instructions
3 instructions
...
So for comparing the evsel name on hybrid, the evsel->idx
needs to be divided by 2.
If a group has events which are from different hybrid PMUs,
shows a warning:
"WARNING: events in group from different hybrid PMUs!"
This is to remind the user not to put the core event and atom
event into one group.
Next, just disable grouping.
# perf stat -e "{cpu_core/cycles/,cpu_atom/cycle
For perf-record, it would be useful to tell user the pmu which the
event belongs to.
For example,
# perf record -a -- sleep 1
# perf report
# To display the perf.data header info, please use --header/--header-only
options.
#
#
# Total Lost Samples: 0
#
# Samples: 106 of event '
Previously if '-e' is not specified in perf stat, some software events
and hardware events are added to evlist by default.
Before:
# ./perf stat -a -- sleep 1
Performance counter stats for 'system wide':
24,044.40 msec cpu-clock # 23.946 CPUs utilized
perf-stat has supported some aggregation modes, such as --per-core,
--per-socket and etc. While for hybrid event, it may only available
on part of cpus. So for --per-core, we need to filter out the
unavailable cores, for --per-socket, filter out the unavailable
sockets, and so on.
Before:
# per
When evlist is empty, for example no '-e' specified in perf record,
one default 'cycles' event is added to evlist.
While on hybrid platform, it needs to create two default 'cycles'
events. One is for cpu_core, the other is for cpu_atom.
This patch actually calls evsel__new_cycles() two times to c
On hybrid platform, user may want to enable event only on one pmu.
Following syntax will be supported:
cpu_core//
cpu_atom//
For hardware event, hardware cache event and raw event, two events
are created by default. We pass the specified pmu name in parse_state
and it would be checked before even
On hybrid platform, user may want to enable events on one pmu.
Following syntax are supported:
cpu_core//
cpu_atom//
But the syntax doesn't work for cache event.
Before:
# perf stat -e cpu_core/LLC-loads/ -a -- sleep 1
event syntax error: 'cpu_core/LLC-loads/'
On hybrid platform, same raw event is possible to be available
on both cpu_core pmu and cpu_atom pmu. It's supported to create
two raw events for one event encoding. For raw events, the
attr.type is PMU type.
# perf stat -e r3c -a -vv -- sleep 1
Control descriptor is not initialized
Current hardware events has special perf types PERF_TYPE_HARDWARE.
But it doesn't pass the PMU type in the user interface. For a hybrid
system, the perf kernel doesn't know which PMU the events belong to.
So now this type is extended to be PMU aware type. The PMU type ID
is stored at attr.config[6
The functions perf_pmu__is_hybrid and perf_pmu__find_hybrid_pmu
can be used to identify the hybrid platform and return the found
hybrid cpu pmu. All the detected hybrid pmus have been saved in
'perf_pmu__hybrid_pmus' list. So we just need to search this list.
perf_pmu__hybrid_type_to_pmu converts
It would be useful to tell user the pmu which the event belongs to.
perf-stat has supported '--no-merge' option and it can print the pmu
name after the event name, such as:
"cycles [cpu_core]"
Now this option is enabled by default for hybrid platform but change
the format to:
"cpu_core/cycles/"
For cache events, they have pre-defined configs. The kernel needs
to know where the cache event comes from (e.g. from cpu_core pmu
or from cpu_atom pmu). But the perf type PERF_TYPE_HW_CACHE
can't carry pmu information.
Now the type PERF_TYPE_HW_CACHE is extended to be PMU aware type.
The PMU type
We identify the cpu_core pmu and cpu_atom pmu by explicitly
checking following files:
For cpu_core, checks:
"/sys/bus/event_source/devices/cpu_core/cpus"
For cpu_atom, checks:
"/sys/bus/event_source/devices/cpu_atom/cpus"
If the 'cpus' file exists and it has data, the pmu exists.
But in order n
For some Intel platforms, such as Alderlake, which is a hybrid platform
and it consists of atom cpu and core cpu. Each cpu has dedicated event
list. Part of events are available on core cpu, part of events are
available on atom cpu.
The kernel exports new cpu pmus: cpu_core and cpu_atom. The event
Simplify the arguments of __perf_pmu__new_alias() by passing
the whole 'struct pme_event' pointer.
Signed-off-by: Jin Yao
---
v4:
- No change.
tools/perf/util/pmu.c | 36
1 file changed, 16 insertions(+), 20 deletions(-)
diff --git a/tools/perf/util/pmu.c
On hybrid platform, one event is available on one pmu
(such as, available on cpu_core or on cpu_atom).
This patch saves the pmu name to the pmu field of struct perf_pmu_alias.
Then next we can know the pmu which the event can be enabled on.
Signed-off-by: Jin Yao
---
v4:
- No change.
v3:
- Ch
To get the changes in:
Liang Kan's patch
[PATCH V6 21/25] perf: Extend PERF_TYPE_HARDWARE and PERF_TYPE_HW_CACHE
Kan's patch is in review at the moment. The following perf tool
patches need this interface for hybrid support.
This patch can be removed after Kan's patch is upstreamed.
Signed-off-
AlderLake uses a hybrid architecture utilizing Golden Cove cores
(core cpu) and Gracemont cores (atom cpu). Each cpu has dedicated
event list. Some events are available on core cpu, some events
are available on atom cpu and some events can be available on both.
Kernel exports new pmus "cpu_core" a
On Fri, Apr 16, 2021 at 03:38:02PM +0200, Auger Eric wrote:
> The redesign requirement came pretty late in the development process.
> The iommu user API is upstream for a while, the VFIO interfaces have
> been submitted a long time ago and under review for a bunch of time.
> Redesigning everything
Hi Mark,
On 4/16/21 8:55 PM, Mark Brown wrote:
On Fri, Apr 16, 2021 at 08:46:48AM +0800, quanyang.w...@windriver.com wrote:
Since pm_runtime works now, clks can be enabled/disabled by calling
zynqmp_runtime_suspend/resume. So we don't need to enable these clks
explicitly in zynqmp_qspi_setup_o
701 - 800 of 1286 matches
Mail list logo
