dri-devel July 2018

dri-devel@lists.freedesktop.org

277 participants
1883 discussions

[radeon-alex:amd-staging-drm-next 690/717] drivers/gpu/drm/ttm/ttm_page_alloc_dma.c:272:7: error: implicit declaration of function 'set_pages_array_uc'; did you mean 'ttm_set_pages_array_uc'?
by kbuild test robot 01 Aug '18

01 Aug '18

tree: git://people.freedesktop.org/~agd5f/linux.git amd-staging-drm-next head: 5bb19d15d8f29153cdb83ceb9ccc78dce4cd31e4 commit: b6fde54f62b2e7da0ce5361746ddb81f52bfe6d9 [690/717] drm/ttm: clean up non-x86 definitions on ttm_page_alloc_dma config: ia64-allmodconfig (attached as .config) compiler: ia64-linux-gcc (GCC) 8.1.0 reproduce: wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross git checkout b6fde54f62b2e7da0ce5361746ddb81f52bfe6d9 # save the attached .config to linux build tree GCC_VERSION=8.1.0 make.cross ARCH=ia64 All errors (new ones prefixed by >>): drivers/gpu/drm/ttm/ttm_page_alloc_dma.c: In function 'ttm_set_pages_caching': >> drivers/gpu/drm/ttm/ttm_page_alloc_dma.c:272:7: error: implicit declaration of function 'set_pages_array_uc'; did you mean 'ttm_set_pages_array_uc'? [-Werror=implicit-function-declaration] r = set_pages_array_uc(pages, cpages); ^~~~~~~~~~~~~~~~~~ ttm_set_pages_array_uc cc1: some warnings being treated as errors vim +272 drivers/gpu/drm/ttm/ttm_page_alloc_dma.c 2334b75f Konrad Rzeszutek Wilk 2011-11-03 265 2334b75f Konrad Rzeszutek Wilk 2011-11-03 266 static int ttm_set_pages_caching(struct dma_pool *pool, 2334b75f Konrad Rzeszutek Wilk 2011-11-03 267 struct page **pages, unsigned cpages) 2334b75f Konrad Rzeszutek Wilk 2011-11-03 268 { 2334b75f Konrad Rzeszutek Wilk 2011-11-03 269 int r = 0; 2334b75f Konrad Rzeszutek Wilk 2011-11-03 270 /* Set page caching */ 2334b75f Konrad Rzeszutek Wilk 2011-11-03 271 if (pool->type & IS_UC) { 2334b75f Konrad Rzeszutek Wilk 2011-11-03 @272 r = set_pages_array_uc(pages, cpages); 2334b75f Konrad Rzeszutek Wilk 2011-11-03 273 if (r) 25d0479a Joe Perches 2012-03-16 274 pr_err("%s: Failed to set %d pages to uc!\n", 2334b75f Konrad Rzeszutek Wilk 2011-11-03 275 pool->dev_name, cpages); 2334b75f Konrad Rzeszutek Wilk 2011-11-03 276 } 2334b75f Konrad Rzeszutek Wilk 2011-11-03 277 if (pool->type & IS_WC) { b6fde54f Huang Rui 2018-07-26 278 r = ttm_set_pages_array_wc(pages, cpages); 2334b75f Konrad Rzeszutek Wilk 2011-11-03 279 if (r) 25d0479a Joe Perches 2012-03-16 280 pr_err("%s: Failed to set %d pages to wc!\n", 2334b75f Konrad Rzeszutek Wilk 2011-11-03 281 pool->dev_name, cpages); 2334b75f Konrad Rzeszutek Wilk 2011-11-03 282 } 2334b75f Konrad Rzeszutek Wilk 2011-11-03 283 return r; 2334b75f Konrad Rzeszutek Wilk 2011-11-03 284 } 2334b75f Konrad Rzeszutek Wilk 2011-11-03 285 :::::: The code at line 272 was first introduced by commit :::::: 2334b75ffbef6b8932f09ec4418b65ddb764ae99 drm/ttm: provide dma aware ttm page pool code V9 :::::: TO: Konrad Rzeszutek Wilk <konrad.wilk(a)oracle.com> :::::: CC: Dave Airlie <airlied(a)redhat.com> --- 0-DAY kernel test infrastructure Open Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation

2 1

[PATCH] drm/amdgpu/pm: Fix potential Spectre v1
by Gustavo A. R. Silva 31 Jul '18

31 Jul '18

idx can be indirectly controlled by user-space, hence leading to a potential exploitation of the Spectre variant 1 vulnerability. This issue was detected with the help of Smatch: drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c:408 amdgpu_set_pp_force_state() warn: potential spectre issue 'data.states' Fix this by sanitizing idx before using it to index data.states Notice that given that speculation windows are large, the policy is to kill the speculation on the first load and not worry if it can be completed with a dependent load/store [1]. [1] https://marc.info/?l=linux-kernel&m=152449131114778&w=2 Cc: stable(a)vger.kernel.org Signed-off-by: Gustavo A. R. Silva <gustavo(a)embeddedor.com> --- drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c index 15a1192..a446c7c 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c @@ -31,7 +31,7 @@ #include <linux/power_supply.h> #include <linux/hwmon.h> #include <linux/hwmon-sysfs.h> - +#include <linux/nospec.h> static int amdgpu_debugfs_pm_init(struct amdgpu_device *adev); @@ -403,6 +403,7 @@ static ssize_t amdgpu_set_pp_force_state(struct device *dev, count = -EINVAL; goto fail; } + idx = array_index_nospec(idx, ARRAY_SIZE(data.states)); amdgpu_dpm_get_pp_num_states(adev, &data); state = data.states[idx]; -- 2.7.4

4 5

[bug report] drm/amd/display: Read AUX channel even if only status byte is returned
by Dan Carpenter 31 Jul '18

31 Jul '18

[ Potential security issue, if I'm reading the code correctly. I don't really know the code and I haven't looked at the larger context. -dan ] Hello Leo (Sunpeng) Li, The patch edf6ffe4f47e: "drm/amd/display: Read AUX channel even if only status byte is returned" from Jun 26, 2018, leads to the following static checker warning: drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link_ddc.c:673 dc_link_aux_transfer() warn: 'returned_bytes' is unsigned drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link_ddc.c 634 int dc_link_aux_transfer(struct ddc_service *ddc, 635 unsigned int address, 636 uint8_t *reply, 637 void *buffer, 638 unsigned int size, 639 enum aux_transaction_type type, 640 enum i2caux_transaction_action action) 641 { 642 struct ddc *ddc_pin = ddc->ddc_pin; 643 struct engine *engine; 644 struct aux_engine *aux_engine; 645 enum aux_channel_operation_result operation_result; 646 struct aux_request_transaction_data aux_req; 647 struct aux_reply_transaction_data aux_rep; 648 uint8_t returned_bytes = 0; ^^^^^^^^^^^^^^^^^^^^^^^^^^ returned_bytes is a u8. 649 int res = -1; 650 uint32_t status; 651 652 memset(&aux_req, 0, sizeof(aux_req)); 653 memset(&aux_rep, 0, sizeof(aux_rep)); 654 655 engine = ddc->ctx->dc->res_pool->engines[ddc_pin->pin_data->en]; 656 aux_engine = engine->funcs->acquire(engine, ddc_pin); 657 658 aux_req.type = type; 659 aux_req.action = action; 660 661 aux_req.address = address; 662 aux_req.delay = 0; 663 aux_req.length = size; 664 aux_req.data = buffer; 665 666 aux_engine->funcs->submit_channel_request(aux_engine, &aux_req); 667 operation_result = aux_engine->funcs->get_channel_status(aux_engine, &returned_bytes); 668 669 switch (operation_result) { 670 case AUX_CHANNEL_OPERATION_SUCCEEDED: 671 res = returned_bytes; ^^^^^^^^^^^^^^^^^^^^ res = 0-255 672 673 if (res <= size && res >= 0) ^^^^^^^^^^^^^^^^^^^^^^^ So obviously the res >= 0 check can be removed, but that's harmless. The bigger problem is that the other test looks to be reversed. Instead of <= it should be >= size. Otherwise we are reading beyond the end of the returned bytes. 674 res = aux_engine->funcs->read_channel_reply(aux_engine, size, 675 buffer, reply, 676 &status); 677 678 break; regards, dan carpenter

2 1

[Bug 107367] [regression, bisected] Games freeze the PC with newest AMD Staging DRM Next Kernel
by bugzilla-daemon＠freedesktop.org 31 Jul '18

31 Jul '18

https://bugs.freedesktop.org/show_bug.cgi?id=107367 Bug ID: 107367 Summary: [regression, bisected] Games freeze the PC with newest AMD Staging DRM Next Kernel Product: Mesa Version: git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel(a)lists.freedesktop.org Reporter: gr.muench(a)gmail.com QA Contact: dri-devel(a)lists.freedesktop.org This reproducible all the time with Dota2 starting a benchmark with 1920x1080 and Vulkan using Phoronix test suite. Starting the benchmark makes the machine freeze and you just can hit the reset button. I also experienced the freeze with Shadow of Mordor but not all the time. fc9a53946d9c107a36b79de3dd1a4eac43f13f3f is the first bad commit commit fc9a53946d9c107a36b79de3dd1a4eac43f13f3f Author: Junwei Zhang <Jerry.Zhang(a)amd.com> Date: Mon Jul 16 10:53:43 2018 +0800 drm/scheduler: add NULL pointer check for run queue (v2) To check rq pointer before adding entity into it. That avoids NULL pointer access in some case. v2: move the check to caller Suggested-by: Christian König <christian.koenig(a)amd.com> Signed-off-by: Junwei Zhang <Jerry.Zhang(a)amd.com> Reviewed-by: Christian König <christian.koenig(a)amd.com> :040000 040000 aa8b4eb640e3995a1f77907edd6ec8fc6fccd1b3 4a061e532ddb8a1293e781a4ccd5ece2efe35d8a M drivers Reverting the commit let the freeze go away. -- You are receiving this mail because: You are the assignee for the bug.

1 11

[Bug 198745] New: Blank screen on RX 580 with AMDGPU Display Core enabled
by bugzilla-daemon＠bugzilla.kernel.org 31 Jul '18

31 Jul '18

https://bugzilla.kernel.org/show_bug.cgi?id=198745 Bug ID: 198745 Summary: Blank screen on RX 580 with AMDGPU Display Core enabled Product: Drivers Version: 2.5 Kernel Version: 4.15.2 Hardware: Other OS: Linux Tree: Mainline Status: NEW Severity: high Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri(a)kernel-bugs.osdl.org Reporter: kyle.devir(a)mykolab.com Regression: No Created attachment 274089 --> https://bugzilla.kernel.org/attachment.cgi?id=274089&action=edit journalctl output for amdgpu When enabling AMDGPU Display Core for my Gigabyte RX 580, I get nothing more than a blank screen on my HDMI monitor. -- You are receiving this mail because: You are watching the assignee of the bug.

1 24

[PATCH 0/2] drm/vkms: Add CRC support
by Haneen Mohammed 31 Jul '18

31 Jul '18

This patchset implement CRC debugfs API and add functions needed to compute and add CRCs entries. Haneen Mohammed (2): drm/vkms: Subclass plane state drm/vkms: Implement CRC debugfs API drivers/gpu/drm/vkms/Makefile | 2 +- drivers/gpu/drm/vkms/vkms_crc.c | 75 +++++++++++++++++++++++++ drivers/gpu/drm/vkms/vkms_crtc.c | 56 ++++++++++++++++--- drivers/gpu/drm/vkms/vkms_drv.c | 1 + drivers/gpu/drm/vkms/vkms_drv.h | 32 +++++++++++ drivers/gpu/drm/vkms/vkms_plane.c | 91 ++++++++++++++++++++++++++++++- 6 files changed, 245 insertions(+), 12 deletions(-) create mode 100644 drivers/gpu/drm/vkms/vkms_crc.c -- 2.17.1

2 4

[GIT PULL] hdlcd fixes for drm-next
by Liviu Dudau 31 Jul '18

31 Jul '18

Hi Dave, I managed to loose track of a few patches for HDLCD while focusing on Mali DP and found them again when investigating an issue with the way HDLCD behaves on teardown. They can go into drm-next for one of the v4.19-rcX if you're not going to do another pull request before the merge window. Many thanks, Liviu The following changes since commit 3fce4618279373efc59a91adb16c11da46cd69e5: BackMerge v4.18-rc7 into drm-next (2018-07-30 10:39:22 +1000) are available in the Git repository at: git://linux-arm.org/linux-ld.git for-upstream/hdlcd for you to fetch changes up to d664b851eb2bcdf84a3c063cf59457bb15bc6120: drm/arm/hdlcd: Reject atomic commits that disable only the plane (2018-07-31 16:31:50 +0100) ---------------------------------------------------------------- Laurent Pinchart (2): drm: arm: hdlcd: Don't destroy plane manually in hdlcd_setup_crtc() drm: arm: hdlcd: Use drm_atomic_helper_shutdown() to disable planes on removal Liviu Dudau (1): drm/arm/hdlcd: Reject atomic commits that disable only the plane Noralf Trønnes (2): drm/arm/hdlcd: Use drm_mode_config_helper_suspend/resume() drm/arm/hdlcd: Use drm_fb_cma_fbdev_init/fini() drivers/gpu/drm/arm/hdlcd_crtc.c | 35 +++++++----------- drivers/gpu/drm/arm/hdlcd_drv.c | 76 ++++++++++------------------------------ drivers/gpu/drm/arm/hdlcd_drv.h | 2 -- 3 files changed, 31 insertions(+), 82 deletions(-) -- ==================== | I would like to | | fix the world, | | but they're not | | giving me the | \ source code! / --------------- ¯\_(ツ)_/¯

1 0

[PATCH v5 0/8] xen: dma-buf support for grant device
by Oleksandr Andrushchenko 31 Jul '18

31 Jul '18

From: Oleksandr Andrushchenko <oleksandr_andrushchenko(a)epam.com> This work is in response to my previous attempt to introduce Xen/DRM zero-copy driver [1] to enable Linux dma-buf API [2] for Xen based frontends/backends. There is also an existing hyper_dmabuf approach available [3] which, if reworked to utilize the proposed solution, can greatly benefit as well. RFC for this series was published and discussed [9], comments addressed. The original rationale behind this work was to enable zero-copying use-cases while working with Xen para-virtual display driver [4]: when using Xen PV DRM frontend driver then on backend side one will need to do copying of display buffers' contents (filled by the frontend's user-space) into buffers allocated at the backend side. Taking into account the size of display buffers and frames per second it may result in unneeded huge data bus occupation and performance loss. The helper driver [4] allows implementing zero-copying use-cases when using Xen para-virtualized frontend display driver by implementing a DRM/KMS helper driver running on backend's side. It utilizes PRIME buffers API (implemented on top of Linux dma-buf) to share frontend's buffers with physical device drivers on backend's side: - a dumb buffer created on backend's side can be shared with the Xen PV frontend driver, so it directly writes into backend's domain memory (into the buffer exported from DRM/KMS driver of a physical display device) - a dumb buffer allocated by the frontend can be imported into physical device DRM/KMS driver, thus allowing to achieve no copying as well Finally, it was discussed and decided ([1], [5]) that it is worth implementing such use-cases via extension of the existing Xen gntdev driver instead of introducing new DRM specific driver. Please note, that the support of dma-buf is Linux only, as dma-buf is a Linux only thing. Now to the proposed solution. The changes to the existing Xen drivers in the Linux kernel fall into 2 categories: 1. DMA-able memory buffer allocation and increasing/decreasing memory reservation of the pages of such a buffer. This is required if we are about to share dma-buf with the hardware that does require those to be allocated with dma_alloc_xxx API. (It is still possible to allocate a dma-buf from any system memory, e.g. system pages). 2. Extension of the gntdev driver to enable it to import/export dma-buf’s. The first five patches are in preparation for Xen dma-buf support, but I consider those usable regardless of the dma-buf use-case, e.g. other frontend/backend kernel modules may also benefit from these for better code reuse: 0001-xen-grant-table-Make-set-clear-page-private-code-sha.patch 0002-xen-balloon-Share-common-memory-reservation-routines.patch 0003-xen-grant-table-Allow-allocating-buffers-suitable-fo.patch 0004-xen-gntdev-Allow-mappings-for-DMA-buffers.patch 0005-xen-gntdev-Make-private-routines-structures-accessib.patch The next three patches are Xen implementation of dma-buf as part of the grant device: 0006-xen-gntdev-Add-initial-support-for-dma-buf-UAPI.patch 0007-xen-gntdev-Implement-dma-buf-export-functionality.patch 0008-xen-gntdev-Implement-dma-buf-import-functionality.patch The corresponding libxengnttab changes are available at [6]. All the above was tested with display backend [7] and its accompanying helper library [8] on Renesas ARM64 based board. Basic balloon tests on x86. *To all the communities*: I would like to ask you to review the proposed solution and give feedback on it, so I can improve and send final patches for review (this is still work in progress, but enough to start discussing the implementation). Thank you in advance, Oleksandr Andrushchenko [1] https://lists.freedesktop.org/archives/dri-devel/2018-April/173163.html [2] https://elixir.bootlin.com/linux/v4.17-rc5/source/Documentation/driver-api/… [3] https://lists.xenproject.org/archives/html/xen-devel/2018-02/msg01202.html [4] https://cgit.freedesktop.org/drm/drm-misc/tree/drivers/gpu/drm/xen [5] https://patchwork.kernel.org/patch/10279681/ [6] https://github.com/andr2000/xen/tree/xen_dma_buf_v1 [7] https://github.com/andr2000/displ_be/tree/xen_dma_buf_v1 [8] https://github.com/andr2000/libxenbe/tree/xen_dma_buf_v1 [9] https://lkml.org/lkml/2018/5/17/215 Changes since v4: ***************** - added r-b tags - rebased onto v4.18-rc5 Changes since v3: ***************** - added r-b tags - minor fixes - removed gntdev_remove_map as it can be coded directly now - moved IOCTL code to gntdev-dmabuf.c - removed usless wait list walks and changed some walks to use normal version of list iterators instead of safe ones as we run under a lock anyways - cleaned up comments, descriptions, pr_debug messages Changes since v2: ***************** - fixed missed break in dmabuf_exp_wait_obj_signal - re-worked debug and error messages, be less verbose - removed patch for making gntdev functions available to other drivers - removed WARN_ON's in dma-buf code - moved all dma-buf related code into gntdev-dmabuf - introduced gntdev-common.h with common structures and function prototypes - added additional checks for number of grants in IOCTLs - gnttab patch cleanup - made xenmem_reservation_scrub_page defined in the header as inline - fixed __pfn_to_mfn use to pfn_to_bfn - no changes to patches 1-2 Changes since v1: ***************** - Define GNTDEV_DMA_FLAG_XXX starting from bit 0 - Rename mem_reservation.h to mem-reservation.h - Remove usless comments - Change licenses from GPLv2 OR MIT to GPLv2 only - Make xenmem_reservation_va_mapping_{update|clear} inline - Change EXPORT_SYMBOL to EXPORT_SYMBOL_GPL for new functions - Make gnttab_dma_{alloc|free}_pages to request frames array be allocated outside - Fixe gnttab_dma_alloc_pages fail path (added xenmem_reservation_increase) - Move most of dma-buf from gntdev.c to gntdev-dmabuf.c - Add required dependencies to Kconfig - Rework "#ifdef CONFIG_XEN_XXX" for if/else - Export gnttab_{alloc|free}_pages as GPL symbols (patch 1) Oleksandr Andrushchenko (8): xen/grant-table: Make set/clear page private code shared xen/balloon: Share common memory reservation routines xen/grant-table: Allow allocating buffers suitable for DMA xen/gntdev: Allow mappings for DMA buffers xen/gntdev: Make private routines/structures accessible xen/gntdev: Add initial support for dma-buf UAPI xen/gntdev: Implement dma-buf export functionality xen/gntdev: Implement dma-buf import functionality drivers/xen/Kconfig | 24 + drivers/xen/Makefile | 2 + drivers/xen/balloon.c | 75 +-- drivers/xen/gntdev-common.h | 94 ++++ drivers/xen/gntdev-dmabuf.c | 855 ++++++++++++++++++++++++++++++++++ drivers/xen/gntdev-dmabuf.h | 33 ++ drivers/xen/gntdev.c | 220 ++++++--- drivers/xen/grant-table.c | 151 +++++- drivers/xen/mem-reservation.c | 118 +++++ include/uapi/xen/gntdev.h | 106 +++++ include/xen/grant_table.h | 21 + include/xen/mem-reservation.h | 59 +++ 12 files changed, 1599 insertions(+), 159 deletions(-) create mode 100644 drivers/xen/gntdev-common.h create mode 100644 drivers/xen/gntdev-dmabuf.c create mode 100644 drivers/xen/gntdev-dmabuf.h create mode 100644 drivers/xen/mem-reservation.c create mode 100644 include/xen/mem-reservation.h -- 2.18.0

4 15

[PATCH v3 0/2] fbdev/core: Disable console-lock warnings when fb.lockless_register_fb is set
by Thomas Zimmermann 31 Jul '18

31 Jul '18

Hi, this is version 3 of the WARN_CONSOLE_UNLOCKED patch set. The macro prints a warning if the console's critical sections are entered without holding the console lock. This patch set allows to disable the warnings while debugging the console. In the original approach, WARN_CONSOLE_UNLOCKED was disabled by setting ignore_console_lock_warning of type bool. As suggested by Petr Mladek, the new implementation is based on atomic_t and allows multiple threads to manipulate the warning state concurrently. With version 3, the patch set now includes the patch for introducing ignore_console_lock_warning. This patch superseds all previous patches of the same purpose. Best regards Thomas v3: - implement ignore_console_lock_warning with atomic_t v2: - restore ignore_console_lock_warning if lock_fb_info() fails Thomas Zimmermann (2): console: Replace #if 0 with atomic var 'ignore_console_lock_warning' fbdev/core: Disable console-lock warnings when fb.lockless_register_fb is set drivers/video/fbdev/core/fbmem.c | 13 +++++++++---- include/linux/console.h | 14 +++++++++----- kernel/printk/printk.c | 3 +++ 3 files changed, 21 insertions(+), 9 deletions(-) -- 2.18.0

6 9

[PATCH v3] drm/nouveau: Fix potential memory access error in debugfs_pstate_get/set()
by Lyude Paul 31 Jul '18

31 Jul '18

nouveau_debugfs(drm) will never be NULL, because we're taking the value of the potentially null device pointer and adding to it so it isn't 0x0. So, check if drm is NULL instead. Signed-off-by: Lyude Paul <lyude(a)redhat.com> Cc: Karol Herbst <karolherbst(a)gmail.com> --- Changes since v2: - Also fix nouveau_debugfs_pstate_set() drivers/gpu/drm/nouveau/nouveau_debugfs.c | 16 ++++++++++------ 1 file changed, 10 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_debugfs.c b/drivers/gpu/drm/nouveau/nouveau_debugfs.c index 963a4dba8213..b7440b542cb2 100644 --- a/drivers/gpu/drm/nouveau/nouveau_debugfs.c +++ b/drivers/gpu/drm/nouveau/nouveau_debugfs.c @@ -50,13 +50,15 @@ static int nouveau_debugfs_pstate_get(struct seq_file *m, void *data) { struct drm_device *drm = m->private; - struct nouveau_debugfs *debugfs = nouveau_debugfs(drm); - struct nvif_object *ctrl = &debugfs->ctrl; + struct nouveau_debugfs *debugfs; + struct nvif_object *ctrl; struct nvif_control_pstate_info_v0 info = {}; int ret, i; - if (!debugfs) + if (!drm) return -ENODEV; + debugfs = nouveau_debugfs(drm); + ctrl = &debugfs->ctrl; ret = nvif_mthd(ctrl, NVIF_CONTROL_PSTATE_INFO, &info, sizeof(info)); if (ret) @@ -121,14 +123,16 @@ nouveau_debugfs_pstate_set(struct file *file, const char __user *ubuf, { struct seq_file *m = file->private_data; struct drm_device *drm = m->private; - struct nouveau_debugfs *debugfs = nouveau_debugfs(drm); - struct nvif_object *ctrl = &debugfs->ctrl; + struct nouveau_debugfs *debugfs; + struct nvif_object *ctrl; struct nvif_control_pstate_user_v0 args = { .pwrsrc = -EINVAL }; char buf[32] = {}, *tmp, *cur = buf; long value, ret; - if (!debugfs) + if (!drm) return -ENODEV; + debugfs = nouveau_debugfs(drm); + ctrl = &debugfs->ctrl; if (len >= sizeof(buf)) return -EINVAL; -- 2.17.1

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel July 2018