https://bugzilla.kernel.org/show_bug.cgi?id=78111
Bug ID: 78111
Summary: APU turbo core boost not working when radeon.dpm=1
Product: Drivers
Version: 2.5
Kernel Version: 3.14.6
Hardware: x86-64
OS: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: Video(DRI - non Intel)
Assignee: drivers_video-dri(a)kernel-bugs.osdl.org
…
[View More]Reporter: bgz.marko(a)gmail.com
Regression: No
I am testing with A6-1450 APU on Arch Linux. If I pass radeon.dpm=1 parameter
at boot and start a single core workload then turbostat will report max
frequency of about 1000 MHz:
Core CPU Avg_MHz Bzy_MHz TSC_MHz time
- - 262 998 998 5**
0 0 12 998 998 5**
1 1 998 998 998
2 2 16 998 998
3 3 21 998 998
"cpupower frequency-info" reports that boost state support is supported, but
not active:
boost state support:
Supported: yes
Active: no
However, when dynamic power management is disabled (radeon.dpm=0), turbostat
reports higher frequencies for single core load, up to 1300 Mhz:
Core CPU Avg_MHz Bzy_MHz TSC_MHz time
- - 320 1214 998 5**
0 0 9 1226 998 5**
1 1 13 1194 998
2 2 41 1143 998
3 3 1216 1216 998
"cpupower frequency-info" confirms that boost is now active.
boost state support:
Supported: yes
Active: yes
--
You are receiving this mail because:
You are watching the assignee of the bug.
[View Less]
Hi,
This is a resend of the v1, after adding Pekka's reviewed-by, rebasing
to latest drm-misc, and re-testing. The cover letter from v1:
This series is based on patches sent about a year ago:
https://lists.freedesktop.org/archives/dri-devel/2019-September/233966.htmlhttps://lists.freedesktop.org/archives/dri-devel/2019-September/233967.html
I've fixed the minor issues reported, and according to the recent
discussions with Pekka and Daniel, I have changed how the gamma works.
After these …
[View More]patches omapdrm will expose DEGAMMA_LUT (and no GAMMA_LUT),
and the legacy gamma-set ioctl will use DEGAMMA_LUT underneath. And on
top of that, we have the CTM and plane color mgmt.
Tomi
Jyri Sarha (2):
drm/omap: Implement CTM property for CRTC using OVL managers CPR
matrix
drm/omap: Enable COLOR_ENCODING and COLOR_RANGE properties for planes
Tomi Valkeinen (3):
drm: add legacy support for using degamma for gamma
drm/omap: use degamma property for gamma table
drm/omap: rearrange includes in omapdss.h
drivers/gpu/drm/drm_atomic_helper.c | 81 +++++++++++++++-----
drivers/gpu/drm/omapdrm/dss/dispc.c | 104 ++++++++++++++++----------
drivers/gpu/drm/omapdrm/dss/omapdss.h | 12 ++-
drivers/gpu/drm/omapdrm/omap_crtc.c | 51 +++++++++++--
drivers/gpu/drm/omapdrm/omap_plane.c | 30 ++++++++
include/drm/drm_atomic_helper.h | 4 +
6 files changed, 209 insertions(+), 73 deletions(-)
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
[View Less]
Some drivers have hardware capability to get the precise timestamp of
certain events based on which the fences are triggered. This allows it
to set accurate timestamp factoring out any software and IRQ latencies.
Move the timestamp parameter out of union in dma_fence struct to allow
signaling drivers to set it. If the parameter is not set, ktime_get is
used to set the current time to fence timestamp during dma_fence_signal.
Signed-off-by: Veera Sundaram Sankaran <veeras(a)codeaurora.org>
…
[View More]---
drivers/dma-buf/dma-fence.c | 18 ++++++++++--------
include/linux/dma-fence.h | 15 +++------------
2 files changed, 13 insertions(+), 20 deletions(-)
diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
index 43624b4..7cef49a 100644
--- a/drivers/dma-buf/dma-fence.c
+++ b/drivers/dma-buf/dma-fence.c
@@ -4,6 +4,7 @@
*
* Copyright (C) 2012 Canonical Ltd
* Copyright (C) 2012 Texas Instruments
+ * Copyright (c) 2020 The Linux Foundation. All rights reserved.
*
* Authors:
* Rob Clark <robdclark(a)gmail.com>
@@ -329,7 +330,6 @@ void __dma_fence_might_wait(void)
int dma_fence_signal_locked(struct dma_fence *fence)
{
struct dma_fence_cb *cur, *tmp;
- struct list_head cb_list;
lockdep_assert_held(fence->lock);
@@ -337,16 +337,18 @@ int dma_fence_signal_locked(struct dma_fence *fence)
&fence->flags)))
return -EINVAL;
- /* Stash the cb_list before replacing it with the timestamp */
- list_replace(&fence->cb_list, &cb_list);
-
- fence->timestamp = ktime_get();
+ /* set current time, if not set by signaling driver */
+ if (!fence->timestamp)
+ fence->timestamp = ktime_get();
set_bit(DMA_FENCE_FLAG_TIMESTAMP_BIT, &fence->flags);
trace_dma_fence_signaled(fence);
- list_for_each_entry_safe(cur, tmp, &cb_list, node) {
- INIT_LIST_HEAD(&cur->node);
- cur->func(fence, cur);
+ if (!list_empty(&fence->cb_list)) {
+ list_for_each_entry_safe(cur, tmp, &fence->cb_list, node) {
+ INIT_LIST_HEAD(&cur->node);
+ cur->func(fence, cur);
+ }
+ INIT_LIST_HEAD(&fence->cb_list);
}
return 0;
diff --git a/include/linux/dma-fence.h b/include/linux/dma-fence.h
index 09e23ad..a9eebaf 100644
--- a/include/linux/dma-fence.h
+++ b/include/linux/dma-fence.h
@@ -4,6 +4,7 @@
*
* Copyright (C) 2012 Canonical Ltd
* Copyright (C) 2012 Texas Instruments
+ * Copyright (c) 2020 The Linux Foundation. All rights reserved.
*
* Authors:
* Rob Clark <robdclark(a)gmail.com>
@@ -70,26 +71,16 @@ struct dma_fence {
* release the fence it is unused. No one should be adding to the
* cb_list that they don't themselves hold a reference for.
*
- * The lifetime of the timestamp is similarly tied to both the
- * rcu freelist and the cb_list. The timestamp is only set upon
- * signaling while simultaneously notifying the cb_list. Ergo, we
- * only use either the cb_list of timestamp. Upon destruction,
- * neither are accessible, and so we can use the rcu. This means
- * that the cb_list is *only* valid until the signal bit is set,
- * and to read either you *must* hold a reference to the fence,
- * and not just the rcu_read_lock.
- *
* Listed in chronological order.
*/
union {
struct list_head cb_list;
- /* @cb_list replaced by @timestamp on dma_fence_signal() */
- ktime_t timestamp;
- /* @timestamp replaced by @rcu on dma_fence_release() */
+ /* @cb_list replaced by @rcu on dma_fence_release() */
struct rcu_head rcu;
};
u64 context;
u64 seqno;
+ ktime_t timestamp;
unsigned long flags;
struct kref refcount;
int error;
--
2.7.4
[View Less]
This RFC is more of a proof of concept then a fully working solution as there are a few unresolved issues we are hoping to get advise on from people on the mailing list.
Until now extracting a card either by physical extraction (e.g. eGPU with thunderbolt connection or by emulation through syfs -> /sys/bus/pci/devices/device_id/remove)
would cause random crashes in user apps. The random crashes in apps were mostly due to the app having mapped a device backed BO into its address space was …
[View More]still
trying to access the BO while the backing device was gone.
To answer this first problem Christian suggested to fix the handling of mapped memory in the clients when the device goes away by forcibly unmap all buffers
the user processes has by clearing their respective VMAs mapping the device BOs. Then when the VMAs try to fill in the page tables again we check in the fault handler
if the device is removed and if so, return an error. This will generate a SIGBUS to the application which can then cleanly terminate.
This indeed was done but this in turn created a problem of kernel OOPs were the OOPSes were due to the fact that while the app was terminating because of the SIGBUS
it would trigger use after free in the driver by calling to accesses device structures that were already released from the pci remove sequence.
This was handled by introducing a 'flush' sequence during device removal were we wait for drm file reference to drop to 0 meaning all user clients directly using this device terminated.
With this I was able to cleanly emulate device unplug with X and glxgears running and later emulate device plug back and restart of X and glxgears.
v2:
Based on discussions in the mailing list with Daniel and Pekka [1] and based on the document produced by Pekka from those discussions [2] the whole approach with returning SIGBUS
and waiting for all user clients having CPU mapping of device BOs to die was dropped. Instead as per the document suggestion the device structures are kept alive until the last
reference to the device is dropped by user client and in the meanwhile all existing and new CPU mappings of the BOs belonging to the device directly or by dma-buf import are rerouted
to per user process dummy rw page.
Also, I skipped the 'Requirements for KMS UAPI' section of [2] since i am trying to get the minimal set of requiremnts that still give useful solution to work and this is the
'Requirements for Render and Cross-Device UAPI' section and so my test case is removing a secondary device, which is render only and is not involved in KMS.
This iteration is still more of a draft as I am still facing a few unsolved issues such as a crash in user client when trying to CPU map imported BO if the map happens after device was
removed and HW failure to plug back a removed device. Also since i don't have real life setup with external GPU connected through TB I am using sysfs to emulate pci remove and i
expect to encounter more issues once i try this on real life case. I am also expecting some help on this from a user who volunteered to test in the related gitlab ticket.
So basically this is more of a way to get feedback if I am moving in the right direction.
[1] - Discussions during v1 of the patchset https://lists.freedesktop.org/archives/dri-devel/2020-May/265386.html
[2] - drm/doc: device hot-unplug for userspace https://www.spinics.net/lists/dri-devel/msg259755.html
[3] - Related gitlab ticket https://gitlab.freedesktop.org/drm/amd/-/issues/1081
Andrey Grodzovsky (8):
drm: Add dummy page per device or GEM object
drm/ttm: Remap all page faults to per process dummy page.
drm/ttm: Add unampping of the entire device address space
drm/amdgpu: Split amdgpu_device_fini into early and late
drm/amdgpu: Refactor sysfs removal
drm/amdgpu: Unmap entire device address space on device remove.
drm/amdgpu: Fix sdma code crash post device unplug
drm/amdgpu: Prevent any job recoveries after device is unplugged.
drivers/gpu/drm/amd/amdgpu/amdgpu.h | 19 +++++++-
drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c | 7 ++-
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 50 +++++++++++++++++----
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 23 ++++++++--
drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c | 12 +++--
drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c | 24 ++++++----
drivers/gpu/drm/amd/amdgpu/amdgpu_irq.h | 1 +
drivers/gpu/drm/amd/amdgpu/amdgpu_job.c | 8 ++++
drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 23 +++++++---
drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c | 8 +++-
drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c | 3 ++
drivers/gpu/drm/amd/amdgpu/amdgpu_vm_sdma.c | 21 ++++++---
drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 17 +++++++-
drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c | 13 +++++-
drivers/gpu/drm/amd/amdgpu/df_v3_6.c | 10 +++--
drivers/gpu/drm/drm_file.c | 8 ++++
drivers/gpu/drm/drm_prime.c | 10 +++++
drivers/gpu/drm/ttm/ttm_bo.c | 8 +++-
drivers/gpu/drm/ttm/ttm_bo_vm.c | 65 ++++++++++++++++++++++++----
include/drm/drm_file.h | 2 +
include/drm/drm_gem.h | 2 +
include/drm/ttm/ttm_bo_driver.h | 7 +++
22 files changed, 286 insertions(+), 55 deletions(-)
--
2.7.4
[View Less]
This is the third version of the patch series. Change log:
v3:
* Add parameter 'iova' to the new ibv_reg_dmabuf_mr() API
* Change the way of allocating dma-buf object - use /dev/dri/renderD*
instead of /dev/dri/card* and use GEM object instead of dumb buffer
* Add cmake function to allow building modules with mixed cython and C
source files
* Add new tests that use dma-buf MRs for send/recv and rdma traffic
* Skip dma-buf tests on unsupported systems
* Remove some use of random values in …
[View More]the new tests
* Add dealloc() and close() methods to the new classes
* Replace string.format with f-string in python code
* Fix some coding style issues: spacing, indentation, typo, comments
v2: https://www.spinics.net/lists/linux-rdma/msg97936.html
* Put the kernel header updates into a separate commit
* Add comments for the data structure used in python ioctl calls
* Fix issues related to symbol versioning
* Fix styling issues: extra spaces, unncecessary variable, typo
* Fix an inproper error code usage
* Put the new op into ibv_context_ops instead if verbs_context
v1: https://www.spinics.net/lists/linux-rdma/msg97865.html
* Add user space API for registering dma-buf based memory regions
* Update pyverbs with the new API
* Add new tests
This is the user space counter-part of the kernel patch set to add
dma-buf support to the RDMA subsystem.
This series consists of six patches. The first patch updates the
kernel headers for dma-buf support. Patch 2 adds the new API function
and updates the man pages. Patch 3 implements the new API in the mlx5
provider. Patch 4 adds new class definitions to pyverbs for the new API.
Patch 5 adds a set of new tests for the new API. Patch 6 fixes bug in
the utility code of the tests.
Pull request at github: https://github.com/linux-rdma/rdma-core/pull/895
Jianxin Xiong (6):
Update kernel headers
verbs: Support dma-buf based memory region
mlx5: Support dma-buf based memory region
pyverbs: Add dma-buf based MR support
tests: Add tests for dma-buf based memory regions
tests: Bug fix for get_access_flags()
buildlib/pyverbs_functions.cmake | 52 ++++++
debian/libibverbs1.symbols | 2 +
kernel-headers/rdma/ib_user_ioctl_cmds.h | 14 ++
kernel-headers/rdma/ib_user_verbs.h | 14 --
libibverbs/CMakeLists.txt | 2 +-
libibverbs/cmd_mr.c | 38 ++++
libibverbs/driver.h | 7 +
libibverbs/dummy_ops.c | 11 ++
libibverbs/libibverbs.map.in | 6 +
libibverbs/man/ibv_reg_mr.3 | 27 ++-
libibverbs/verbs.c | 18 ++
libibverbs/verbs.h | 11 ++
providers/mlx5/mlx5.c | 2 +
providers/mlx5/mlx5.h | 3 +
providers/mlx5/verbs.c | 22 +++
pyverbs/CMakeLists.txt | 7 +
pyverbs/dmabuf.pxd | 15 ++
pyverbs/dmabuf.pyx | 72 ++++++++
pyverbs/dmabuf_alloc.c | 296 +++++++++++++++++++++++++++++++
pyverbs/dmabuf_alloc.h | 19 ++
pyverbs/libibverbs.pxd | 2 +
pyverbs/mr.pxd | 6 +
pyverbs/mr.pyx | 103 ++++++++++-
tests/test_mr.py | 239 ++++++++++++++++++++++++-
tests/utils.py | 30 +++-
25 files changed, 996 insertions(+), 22 deletions(-)
create mode 100644 pyverbs/dmabuf.pxd
create mode 100644 pyverbs/dmabuf.pyx
create mode 100644 pyverbs/dmabuf_alloc.c
create mode 100644 pyverbs/dmabuf_alloc.h
--
1.8.3.1
[View Less]
From: Mikhail Durnev <mikhail_durnev(a)mentor.com>
Hi All,
This patch series is aiming at extending the mipi-dbi bus driver
to support Intel 8080 type parallel bus (Type B) over GPIO and
adding a new driver for ILI9341 display panels with 8- or 16-bit
parallel interface.
It was tested with the MRB2801 display module [1] that had
a connector compatible with the ALIENTEK STM32 development board.
The module was connected to Raspberry Pi 3 via GPIO pins.
The parallel bus is implemented …
[View More]partially. It supports only write
operations from the host to the display. Read operations would
require switching GPIO mode between input and output back and
forth. But this implementation is very simple, and GPIO mode can
be set for all used pins to output once at initialization.
The RD pin of the display has to always receive the logic high
signal to make sure the data bus pins from the dislay side are
always in the high impedance state. Otherwise the display module
as well as the GPIO controller of the host can be damaged.
To be on the safe side I recommend using protective resistors
for all GPIO pins conneced to DB pins of the display. Resistors
of 10 kOhms are just fine for RPi 3. The WR and DC pins may not
work well with 10K resistors. Although there is no need to protect
them, you can try using 1K resistors if you want.
Bit banging is used to transmit data over the parallel bus from
host to display. There are two numbers that contol timings. They
should be defined in the device tree via the wr-up-down-delays
property. The first number is related to the write control pulse
duration, and the second number is related to the write cycle
duration. For ILI9341, the write pulse cannot be shorter than 15 ns,
and the write duration cannot be shorter than 66 ns. Delays of
10 and 51 ns respectively allow to meet the specifications on
RPi 3. Faster machines may need values closer to 15 and 66.
[1] http://www.lcdwiki.com/2.8inch_16BIT_Module_ILI9341_SKU:MRB2801
Signed-off-by: Mikhail Durnev <mikhail_durnev(a)mentor.com>
v1 -> v2:
- Moved the definition of mipi_dbi_machine_little_endian()
out of the "#if IS_ENABLED(CONFIG_SPI)" clause. That static
function is used in mipi_dbi_gpio_init which does not need
CONFIG_SPI enabled
v0 -> v1:
- Rebased on v5.10-rc6
- Replaced "dbi->spi = 0;" with "dbi->spi = NULL;" in
mipi_dbi_gpio_init
v0:
- Based on branch rpi-5.10.y
- Tested on Raspberry Pi 3 Model B V 1.2
Mikhail Durnev (3):
drm/mipi-dbi: Add support for Type B
drm/tiny: Add driver for ili9341 with parallel bus
dt-bindings: panel: Add bindings for MRB2801
.../devicetree/bindings/display/ronbo,mrb2801.txt | 42 +++
drivers/gpu/drm/drm_mipi_dbi.c | 134 +++++++++-
drivers/gpu/drm/tiny/Kconfig | 13 +
drivers/gpu/drm/tiny/Makefile | 1 +
drivers/gpu/drm/tiny/ili9341_gpio.c | 290 +++++++++++++++++++++
include/drm/drm_mipi_dbi.h | 30 ++-
6 files changed, 499 insertions(+), 11 deletions(-)
create mode 100644 Documentation/devicetree/bindings/display/ronbo,mrb2801.txt
create mode 100644 drivers/gpu/drm/tiny/ili9341_gpio.c
--
2.7.4
[View Less]