dri-devel December 2014

dri-devel@lists.freedesktop.org

156 participants
1053 discussions

[Bug 73338] Fan speed in idle at 40% with radeonsi and at 18% with catalyst
by bugzilla-daemon＠freedesktop.org 05 Dec '14

05 Dec '14

https://bugs.freedesktop.org/show_bug.cgi?id=73338 Chernovsky Oleg <adonai(a)xaker.ru> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #106588|0 |1 is obsolete| | --- Comment #63 from Chernovsky Oleg <adonai(a)xaker.ru> --- Created attachment 110476 --> https://bugs.freedesktop.org/attachment.cgi?id=110476&action=edit hwmon interface for manual fan control on CI cards Hi Alex, I've made rough patch implementing hwmon interface for the code you've provided. Please take a look (comments inside). Patch is done on top of your 3.19-wip branch. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[git pull] drm intel fixes
by Dave Airlie 05 Dec '14

05 Dec '14

Hi Linus, two intel stable fixes, that should be it from me for this round. Dave. The following changes since commit ebea76f5b95caddb59f49a3e288da26358e6ab1f: Merge tag 'media/v3.18-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media (2014-12-04 16:06:02 -0800) are available in the git repository at: git://people.freedesktop.org/~airlied/linux drm-fixes for you to fetch changes up to 3e3282c0a23d8eb9438dcf4ac908a5eb48c7038b: Merge tag 'drm-intel-fixes-2014-12-04' of git://anongit.freedesktop.org/drm-intel into drm-fixes (2014-12-05 11:12:29 +1000) ---------------------------------------------------------------- Daniel Vetter (2): drm/i915: More cautious with pch fifo underruns drm/i915: Unlock panel even when LVDS is disabled Dave Airlie (1): Merge tag 'drm-intel-fixes-2014-12-04' of git://anongit.freedesktop.org/drm-intel into drm-fixes drivers/gpu/drm/i915/intel_display.c | 2 -- drivers/gpu/drm/i915/intel_lvds.c | 22 +++++++++++----------- 2 files changed, 11 insertions(+), 13 deletions(-)

1 0

[Bug 67681] Asus G75VW F key Not Working For Screen Brightness
by bugzilla-daemon＠bugzilla.kernel.org 05 Dec '14

05 Dec '14

https://bugzilla.kernel.org/show_bug.cgi?id=67681 --- Comment #32 from KernelBug <3fdd1e5d(a)opayq.com> --- Hi, Has there been any progress on this? As I mentioned in the past I use xbindkeys in my $HOME a file called, .xbindkeysrc and these are the command I use below; ################################## # End of xbindkeys configuration # ################################## # My keybindings #decrease brightness "~/.config/openbox/backlight-dn.sh" m:0x0 + c:71 F5 #increase brightness "~/.config/openbox/backlight-up.sh" m:0x0 + c:72 F6 Which simply run; xbacklight -inc 10 xbacklight -dec 10 Seeing that xbacklight works in this situation, does that help shed light on comiing up with a solution? thank you... -- You are receiving this mail because: You are watching the assignee of the bug.

1 0

[RFC 0/7+1] Add in-kernel vblank delaying mechanism
by Paulo Zanoni 05 Dec '14

05 Dec '14

From: Paulo Zanoni <paulo.r.zanoni(a)intel.com> Hi --- TL;DR summary: I wrote patches. Help me choose the best implementation and interface. --- So the i915.ko driver could use some mechanism to run functions after a given number of vblanks. Implementations for this mechanism were already proposed in the past (by Chris Wilson and others), but they were i915-specific instead of a generic drm.ko implementation. We even had patches that make use of this new mechanism. Since this is very similar to the vblank IOCTL we currently have, but with the caller being a Kernel module instead of user space, I decided to write an implementation that tries to reuse the current IOCTL infrastructure. In the first patch we add all the necessary code to allow the modules to call the vblank ioctl from Kernel space: they provide a callback function that is going to be called instead of the traditional send_vblank_event(), which means the Kernel callers don't have to deal with the file descriptors and DRM events. In the second patch we add a simple extension of the feature, to allow the drivers to have their callbacks called in a non-atomic context. In all the other subsequent patches we rework the underlying code so that the common aspects between the user space vblank IOCTL and the Kernel interface are all stored in a single structure (struct drm_vblank_wait_item), and then anything that is specific to the different users is stored in a structure that contains struct drm_vblank_wait_item. This way, most of the drm.ko code only needs to deal with struct drm_vblank_wait_item, not really knowing how it is wrapped. The advantage of this rework is that it reduces the number of memory allocations needed in some cases (from 2 to 1) and it also reduces the amount of memory used on each allocation. But while this all sounds nice in the above description, I had the feeling that this adds a lot of complexity and makes the code not-so-beautiful. If we ever need more extensions/options to this feature, we're going to have to untangle the code even more from the IOCTL part. We also have a small "abstraction break" in change introduced in patch 6. And there's the risk that some of the reworks may have added a regression somewhere. Based on that, I decided to also provide an alternative implementation. In this implementation we add a new dev->vblank_kernel_list instead of reusing dev->vblank_event_list, and add new code to handle that this. This new code is completely based on the code that handles dev->vblank_kernel_list, so there's some duplication here. On the other hand, since the in-Kernel infrastructure is not tied to the IOCTL structure, we can very easily grow and adapt the Kernel code without having to fight against the IOCTL code. And the risk of regressions is greatly reduced. The second difference of this alternative implementation is the signature of the drm_wait_vblank_kernel() function. While it could be exactly the same as the one used in the other series, I decided to make it different so we can also choose which one to use. In the 7-patch series implementation, all the user needs to do is to allocate the structure, and call the function, properly setting all its arguments. Then the function is responsible for parsing the arguments and populating the structure based on that. On the alternative implementation, the user has to fill the structure with the appropriate arguments, and then call drm_wait_vblank_kernel() passing just the allocated structure as an argument. If you notice, you will see that these patches add a new debugfs file to i915.ko. This file is just a very simple example user of the new interface, which I used while developing. If you have difficulty understanding the new interface, please also look at the i915/i915_debugfs.c diff. Of course, I plan to exclude this debugfs interface from the final to-be-merged patches. So, in summary, we have a few things we need to discuss: 1. Which implementation to use? a. Just the 2 first patches of the 7-patch series? Pros: - the Kernel users basically call the vblank IOCTL - the code changes are minimal Cons: - The amount of memory allocations and memory space consumed is not optimal b. The full 7-patch series? Pros: - The same backend is used for both the Kernel and IOCTL. Cons: - The code gets more complex. - Extending the Kernel interface can get complicated due to the fact that it shares code with the IOCTL interface. - I didn't really like this solution. c. The alternative implementation I wrote? Pros: - It's independent from the IOCTL code, making further patches easier. Cons: - There is some duplicated code. d. Something totally different from these alternatives? 2. How should the driver interface look like? a. All the possibilities are passed through the function call, so the drm.ko code needs to set the struct members itself. b. The caller already sets the struct members instead of passing them as parameters to the function. c. Something different? All these patches are based on top of Daniel Vetter's drm-intel-nightly tree. It's all just an RFC, so don't expect something very well tested. Flamewars and bikeshedding are welcome! Thanks, Paulo Paulo Zanoni (7): - First implementation: drm: allow the drivers to call the vblank IOCTL internally drm: allow drm_wait_vblank_kernel() callback from workqueues drm: introduce struct drm_vblank_wait_item drm: add wanted_seq to drm_vblank_wait_item drm: change the drm vblank callback item type drm: make vblank_event_list handle drm_vblank_wait_item types drm: make the callers of drm_wait_vblank() allocate the memory - Alternative implementation: drm: add a mechanism for drivers to schedule vblank callbacks Stats for only the first implementation: drivers/gpu/drm/drm_fops.c | 15 ++- drivers/gpu/drm/drm_ioctl.c | 2 +- drivers/gpu/drm/drm_irq.c | 178 ++++++++++++++++++++++++++---------- drivers/gpu/drm/i915/i915_debugfs.c | 90 ++++++++++++++++++ include/drm/drmP.h | 35 ++++++- 5 files changed, 264 insertions(+), 56 deletions(-) -- 2.1.1

4 17

[pull] radeon drm-next-3.19
by Alex Deucher 04 Dec '14

04 Dec '14

Hi Dave, A few more fixes for 3.19. - More cursor and hotspot handling fixes - Fix some typos in the new smc fan control code and enable on CI - VM and CS cleanups The following changes since commit d5b75dc01fa9c699aee5f82f5dbe508da438ff94: Merge branch 'vmwgfx-next' of git://people.freedesktop.org/~thomash/linux into drm-next (2014-12-03 19:35:05 +1000) are available in the git repository at: git://people.freedesktop.org/~agd5f/linux drm-next-3.19-wip for you to fetch changes up to eb8d4d0d994aebe4ebb6bccd3637ab55eab3fa81: drm/radeon: enable smc fan control on CI (2014-12-03 19:05:19 -0500) ---------------------------------------------------------------- Alex Deucher (4): drm/radeon: fix typo in new fan control registers for SI/CI drm/radeon: fix copy paste typos in fan control for si/ci drm/radeon: check the right ring in radeon_evict_flags() drm/radeon: enable smc fan control on CI Christian König (9): drm/radeon: sync all BOs involved in a CS drm/radeon drop gobj from radeon_cs_reloc drm/radeon: drop the handle from radeon_cs_reloc drm/radeon: rename radeon_cs_reloc to radeon_bo_list drm/radeon: fence PT updates as shared drm/radeon: add spinlock for BO_VA status protection (v2) drm/ttm: optionally move duplicates to a separate list drm/radeon: remove duplicates check drm/radeon: use pointers instead of indexes for CS chunks Michel Dänzer (3): drm/radeon: Re-show the cursor after a modeset drm/radeon: Move hotspot handling out of radeon_set_cursor drm/radeon: Hide cursor on CRTCs used by fbdev (v2) drivers/gpu/drm/qxl/qxl_release.c | 3 +- drivers/gpu/drm/radeon/atombios_crtc.c | 1 + drivers/gpu/drm/radeon/ci_dpm.c | 7 +- drivers/gpu/drm/radeon/cikd.h | 8 +- drivers/gpu/drm/radeon/evergreen_cs.c | 14 +-- drivers/gpu/drm/radeon/r100.c | 10 +-- drivers/gpu/drm/radeon/r200.c | 2 +- drivers/gpu/drm/radeon/r300.c | 6 +- drivers/gpu/drm/radeon/r600_cs.c | 26 +++--- drivers/gpu/drm/radeon/radeon.h | 43 +++++----- drivers/gpu/drm/radeon/radeon_cs.c | 129 +++++++++++----------------- drivers/gpu/drm/radeon/radeon_cursor.c | 107 +++++++++++++++-------- drivers/gpu/drm/radeon/radeon_fb.c | 32 ++++++- drivers/gpu/drm/radeon/radeon_gem.c | 4 +- drivers/gpu/drm/radeon/radeon_legacy_crtc.c | 1 + drivers/gpu/drm/radeon/radeon_mode.h | 1 + drivers/gpu/drm/radeon/radeon_object.c | 15 +++- drivers/gpu/drm/radeon/radeon_trace.h | 2 +- drivers/gpu/drm/radeon/radeon_ttm.c | 2 +- drivers/gpu/drm/radeon/radeon_uvd.c | 14 +-- drivers/gpu/drm/radeon/radeon_vce.c | 8 +- drivers/gpu/drm/radeon/radeon_vm.c | 74 +++++++++++----- drivers/gpu/drm/radeon/si_dpm.c | 6 +- drivers/gpu/drm/radeon/sid.h | 8 +- drivers/gpu/drm/ttm/ttm_execbuf_util.c | 10 ++- drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 6 +- drivers/gpu/drm/vmwgfx/vmwgfx_resource.c | 2 +- include/drm/ttm/ttm_execbuf_util.h | 9 +- 28 files changed, 324 insertions(+), 226 deletions(-)

1 0

Clipping src and crtc rectangles for SetCrtc and SetPlane
by Adam Cheney 04 Dec '14

04 Dec '14

Hi dri-devel, I have a question about validating the user specified rectangles in SetCrtc and SetPlane. To me this is required for src_ or crtc_ rectangles to be legal, true for both SetCrtc and SetPlane: 1) src_{x,y,w,h} fits entirely within the fb size 2) crtc_{x,y,w,h} fits entirely within the mode size There is some common code that enforces 1), but 2) appears to be up to individual drivers to enforce (if they choose to) as far as I can tell. If the crtc_ output rectangle extends outside of the connector's active mode, should DRM drivers perform the mode clipping themselves, or should this be considered an application bug and an error code returned? Is there any reason not to enforce 2) in the core DRM code, rather than in the individual drivers? Thanks, -Adam ----------------------------------------------------------------------------------- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. -----------------------------------------------------------------------------------

2 2

[Bug 61533] New: GPU lockups uccurs regularilly on kernel 3.8 caused by Opera browser hardware accelerated rendering
by bugzilla-daemon＠freedesktop.org 04 Dec '14

04 Dec '14

https://bugs.freedesktop.org/show_bug.cgi?id=61533 Priority: medium Bug ID: 61533 Assignee: dri-devel(a)lists.freedesktop.org Summary: GPU lockups uccurs regularilly on kernel 3.8 caused by Opera browser hardware accelerated rendering Severity: critical Classification: Unclassified OS: Linux (All) Reporter: ken20001(a)ukr.net Hardware: x86-64 (AMD64) Status: NEW Version: XFree86 4.4.0 Component: DRM/Radeon Product: DRI Just upgraded kernel to version 3.8 on my system and several GPU lockups uccured when I opened pastebin link in Opera browser. (Here is expample link: http://paste.ubuntu.com/5568971/ or http://paste.ubuntu.com/5568954/). Several times I opened such several links in Opera and one time it caused GPU lockup and other times it even freezes. After turning off Opera Hardware Acceleration there was no lokups. And the thing is that with kernel 3.5 no lockups occured even with hardware acceleration turned on. Software: Kubuntu 12.10 x86_64 Linux 3.8.0-7-generic #16~lp1084783v1 KDE 4.10, desktop effects enabled. OpenGL version string: 3.0 Mesa 9.2-devel (git-533dc3b quantal-oibaf-ppa) libdrm-radeon1: 2.4.42+git1302251607.41fc2c~gd~q xserver-xorg-video-radeon: 1:7.1.0+git1302220944.f1059e~gd~q xserver-xorg-core: 2:1.13.0-0ubuntu6.1 Hardware: Intel C2D 7200 ASUS P5B Deluxe AMD Radeon HD 2600 XТ -- You are receiving this mail because: You are the assignee for the bug.

1 20

[PULL] amdkfd-next-3.19-fixes
by Oded Gabbay 04 Dec '14

04 Dec '14

Hi Dave, Just three more fixes for 3.19. This is the last request until -rc1. I will have our QA team run a full HSA stack test on 3.19-rc1 and if we find problems, I will send a fixes pull request. - Oded The following changes since commit d5b75dc01fa9c699aee5f82f5dbe508da438ff94: Merge branch 'vmwgfx-next' of git://people.freedesktop.org/~thomash/linux into drm-next (2014-12-03 19:35:05 +1000) are available in the git repository at: git://people.freedesktop.org/~gabbayo/linux amdkfd-next-3.19 for you to fetch changes up to a550bb3d5313c3d894cac552e13037394ac78fd4: amdkfd: Set *buffer_ptr to NULL in case of error (2014-12-04 14:09:02 +0200) ---------------------------------------------------------------- Oded Gabbay (1): amdkfd: Set *buffer_ptr to NULL in case of error Sasha Levin (2): amdkfd: use sizeof(long) granularity for the pasid bitmask amdkfd: use atomic allocations within srcu callbacks drivers/gpu/drm/amd/amdkfd/kfd_kernel_queue.c | 8 +++++++- drivers/gpu/drm/amd/amdkfd/kfd_pasid.c | 3 +-- drivers/gpu/drm/amd/amdkfd/kfd_process.c | 2 +- 3 files changed, 9 insertions(+), 4 deletions(-)

1 0

[PATCH] amdkfd: Set *buffer_ptr to NULL in case of error
by Oded Gabbay 04 Dec '14

04 Dec '14

In function acquire_packet_buffer() we may return -ENOMEM. In that case, we should set the *buffer_ptr to NULL, so that calling functions which check the *buffer_ptr value as a criteria for success, will know that acquire_packet_buffer() failed. Signed-off-by: Oded Gabbay <oded.gabbay(a)amd.com> --- drivers/gpu/drm/amd/amdkfd/kfd_kernel_queue.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_kernel_queue.c b/drivers/gpu/drm/amd/amdkfd/kfd_kernel_queue.c index 9abac48..9350714 100644 --- a/drivers/gpu/drm/amd/amdkfd/kfd_kernel_queue.c +++ b/drivers/gpu/drm/amd/amdkfd/kfd_kernel_queue.c @@ -221,8 +221,14 @@ static int acquire_packet_buffer(struct kernel_queue *kq, queue_size_dwords; if (packet_size_in_dwords >= queue_size_dwords || - packet_size_in_dwords >= available_size) + packet_size_in_dwords >= available_size) { + /* + * make sure calling functions know + * acquire_packet_buffer() failed + */ + *buffer_ptr = NULL; return -ENOMEM; + } if (wptr + packet_size_in_dwords >= queue_size_dwords) { while (wptr > 0) { -- 1.9.1

2 1

[PATCH v17 0/12] dw-hdmi: convert imx hdmi to bridge/dw_hdmi
by Andy Yan 04 Dec '14

04 Dec '14

We found Freescale imx6 and Rockchip rk3288 and Ingenic JZ4780 (Xburst/MIPS) use the interface compatible Designware HDMI IP, but they also have some lightly differences, such as phy pll configuration, register width(imx hdmi register is one byte, but rk3288 is 4 bytes width and can only be accessed by word), 4K support(imx6 doesn't support 4k, but rk3288 does), and HDMI2.0 support. To reuse the imx-hdmi driver, we make this patch set: (1): fix some CodingStyle warning to make checkpatch happy (2): convert imx-hdmi to drm_bridge (3): split platform specific code (4): move imx-hdmi to bridge/dw_hdmi (5): extend dw_hdmi.c to support rk3288 hdmi (6): add rockchip rk3288 platform specific code dw_hdmi-rockchip.c Changes in v17: - remove platform device stuff from dw_hdmi core, adviced by Russell King - remove prompt message of dw_hdmi kconfig, adviced by Russel King - parse resource and irq in platform driver Changes in v16: - use the common binding for the clocks - describe ddc-i2c-bus as optional - add common clocks bindings - modify clocks bindings Changes in v15: - add prefix dw_hdmi/DW_HDMI for public used dw_hdmi structs adviced by Philipp Zabel - remove THIS_MODULE in platform driver - remove unio of the multi-byte register access, adviced by Philipp Zabel - remove THIS_MODULE in platform driver Changes in v14: - add defer probing, adviced by Philipp Zabel - remove drm_connector_register, because imx-drm core has registered connector Changes in v13: - patch against drm-next - split platform specific phy configuration - split phy configuration from patch#4 Changes in v12: - refactor of_node_put(ddc_node) - squash patch <convert dw_hdmi to drm_bridge> - add comment for the depend on patch Changes in v11: - squash patch <split some phy configuration to platform driver> Changes in v10: - split generic dw_hdmi.c improvements from patch#11 (add rk3288 support) - add more display mode support mpll configuration for rk3288 Changes in v9: - move some phy configuration to platform driver Changes in v8: - correct some spelling mistake - modify ddc-i2c-bus and interrupt description - Add documentation for rockchip dw hdmi Changes in v7: - remove unused variables from structure dw_hdmi - remove a wrong modification - add copyrights for dw_hdmi-imx.c Changes in v6: - rearrange the patch order - refactor register access without reg_shift Changes in v5: - refactor reg-io-width Changes in v4: - fix checkpatch CHECK - defer probe ddc i2c adapter Changes in v3: - split multi-register access to one indepent patch Andy Yan (12): drm: imx: imx-hdmi: make checkpatch happy drm: imx: imx-hdmi: return defer if can't get ddc i2c adapter drm: imx: imx-hdmi: convert imx-hdmi to drm_bridge mode drm: imx: imx-hdmi: split phy configuration to platform driver drm: imx: imx-hdmi: move imx-hdmi to bridge/dw_hdmi dt-bindings: add document for dw_hdmi drm: bridge/dw_hdmi: add support for multi-byte register width access drm: bridge/dw_hdmi: add mode_valid support drm: bridge/dw_hdmi: clear i2cmphy_stat0 reg in hdmi_phy_wait_i2c_done drm: bridge/dw_hdmi: add function dw_hdmi_phy_enable_spare dt-bindings: Add documentation for rockchip dw hdmi drm: bridge/dw_hdmi: add rockchip rk3288 support .../devicetree/bindings/drm/bridge/dw_hdmi.txt | 45 ++ .../devicetree/bindings/video/dw_hdmi-rockchip.txt | 46 ++ drivers/gpu/drm/bridge/Kconfig | 5 + drivers/gpu/drm/bridge/Makefile | 1 + .../gpu/drm/{imx/imx-hdmi.c => bridge/dw_hdmi.c} | 716 ++++++++++----------- .../gpu/drm/{imx/imx-hdmi.h => bridge/dw_hdmi.h} | 4 +- drivers/gpu/drm/imx/Kconfig | 1 + drivers/gpu/drm/imx/Makefile | 2 +- drivers/gpu/drm/imx/dw_hdmi-imx.c | 258 ++++++++ drivers/gpu/drm/rockchip/Kconfig | 10 + drivers/gpu/drm/rockchip/Makefile | 2 + drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 340 ++++++++++ include/drm/bridge/dw_hdmi.h | 61 ++ 13 files changed, 1105 insertions(+), 386 deletions(-) create mode 100644 Documentation/devicetree/bindings/drm/bridge/dw_hdmi.txt create mode 100644 Documentation/devicetree/bindings/video/dw_hdmi-rockchip.txt rename drivers/gpu/drm/{imx/imx-hdmi.c => bridge/dw_hdmi.c} (72%) rename drivers/gpu/drm/{imx/imx-hdmi.h => bridge/dw_hdmi.h} (99%) create mode 100644 drivers/gpu/drm/imx/dw_hdmi-imx.c create mode 100644 drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c create mode 100644 include/drm/bridge/dw_hdmi.h -- 1.9.1

2 14

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel December 2014