[Bug 83998] Oopses on R9270X using UVD since radeon/uvd: use PIPE_USAGE_STAGING for msg buffers

bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141119/04a42fdc/attachment.html>

[Bug 83998] Oopses on R9270X using UVD since radeon/uvd: use PIPE_USAGE_STAGING for msg buffers

. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141119/76e67f07/attachment.html>

[Bug 31532] [RADEON:KMS:RV670:AGP:R600C-R600G] PCIE gart stalls

ttp://lists.freedesktop.org/archives/dri-devel/attachments/20141119/bdf30d13/attachment.html>

[RFC PATCH 1/3] drm/exynos: make kms drivers to be independent modules

2014-11-19 17:49 GMT+09:00 Andrzej Hajda : > On 11/18/2014 04:26 PM, Inki Dae wrote: >> This patch makes kms drivers to be independent modules. >> For this, it removes all register codes to kms drivers >> from exynos_drm_drv module and adds module_init/exit >> for each kms driver so that each kms

[PATCH 6/6] drm/atomic_helper: Make it clear that commit_planes gets the old state

On Wed, Nov 19, 2014 at 03:29:30PM -0500, Rob Clark wrote: > On Wed, Nov 19, 2014 at 12:38 PM, Daniel Vetter > wrote: > > Oversight from my kerneldoc cleanup when doing the original atomic > > helper series - I've only applied this clarification to the modeset > > related helpers, and not the

[radeonsi, regression, bisected] All my Steam games fail to load into the 3D-engine-powered part (SIGPWR and SIGXCPU)

36.165392] [drm] Initialized radeon 2.40.0 20080528 for :01:00.0 on minor 0 Let me know, if you need something else. Cheers, Kai -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 648 bytes Desc: OpenPGP digita

[Bug 88481] Kernel oops leaves system without graphical output [radeon]

https://bugzilla.kernel.org/show_bug.cgi?id=88481 Daniel Otero changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

[PATCH 01/11] drm/radeon: rework vm_flush parameters

xt attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 648 bytes Desc: OpenPGP digital signature URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141119/1f735e44/attachment-0001.sig>

[PATCH 01/11] drm/radeon: rework vm_flush parameters

Am 19.11.2014 um 19:28 schrieb Alex Deucher: > On Wed, Nov 19, 2014 at 8:01 AM, Christian König > wrote: >> From: Christian König >> >> Use ring structure instead of index and provide vm_id and pd_addr separately. >> >> Signed-off-by: Christian König > Pushed to my 3.19-wip tree. I'll send

3.18-rc regression: drm/nouveau: use shared fences for readable objects

On Wed, Nov 19, 2014 at 12:10 AM, Maarten Lankhorst wrote: > Hey, > > On 19-11-14 07:43, Michael Marineau wrote: >> On 3.18-rc kernel's I have been intermittently experiencing GPU >> lockups shortly after startup, accompanied with one or both of the >> following errors: >> >> nouveau E[

[Bug 61941] Random GPU lockups/resets on Mobility Radeon HD 3650 with radeon.dpm=1

https://bugzilla.kernel.org/show_bug.cgi?id=61941 Pavol Klačanský changed: What|Removed |Added CC||pavol at klacansky.com --- Comment

[PATCH] drm/radeon: update the VM after setting BO address v4

From: Christian König This way the necessary VM update is kicked off immediately if all BOs involved are in GPU accessible memory. v2: fix vm lock v3: immediately update unmaps as well v4: use drm_free_large instead of kfree Signed-off-by: Christian König

[PULL] drm-intel-fixes

Hi Dave, couple of regression fixes, both cc: stable. BR, Jani. The following changes since commit fc14f9c1272f62c3e8d01300f52467c0d9af50f9: Linux 3.18-rc5 (2014-11-16 16:36:20 -0800) are available in the git repository at: git://anongit.freedesktop.org/drm-intel

[PATCH 6/6] drm/atomic_helper: Make it clear that commit_planes gets the old state

Oversight from my kerneldoc cleanup when doing the original atomic helper series - I've only applied this clarification to the modeset related helpers, and not the plane update code. Remedy this asap. Signed-off-by: Daniel Vetter --- drivers/gpu/drm/drm_atomic_helper.c | 12 ++-- 1 file

[PATCH 5/6] drm: s/enum_blob_list/enum_list/ in drm_property

I guess for hysterical raisins this was meant to be the way to read blob properties. But that's done with the two-stage approach which uses separate blob kms object and the special-purpose get_blob ioctl. Shipping userspace seems to have never relied on this, and the kernel also never put any

[PATCH 4/6] drm/crtc: Polish kerneldoc

- Make it clear that it's a negative errno (more in line with everything else). - Clean up the confusion around get_properties vs. getproperty ioctls: One reads per-obj property values, the other reads property metadata. Signed-off-by: Daniel Vetter --- drivers/gpu/drm/drm_crtc.c | 79

[PATCH 3/6] drm/atomic: Don't overrun the connector array when hotplugging

Yet another fallout from not considering DP MST hotplug. With the previous patches we have stable indices, but it might still happen that a connector gets added between when we allocate the array and when we actually add a connector. Especially when we back off due to ww mutex contention or

[PATCH 2/6] drm/atomic: Only destroy connector states with connection mutex held

Otherwise the connector might have been unplugged and destroyed while we didn't look. Yet another fallout from DP MST hotplugging that I didn't consider. To make sure we get this right add an appropriate WARN_ON to drm_atomic_state_clear (obviously only when we actually have a state to clear up).

[PATCH 1/6] drm/atomic: Ensure that drm_connector_index is stable

I've totally forgotten that with DP MST connectors can now be hotplugged. And failed to adapt Rob's drm_atomic_state code (which predates connector hotplugging) to the new realities. The first step is to make sure that the connector indices used to access the arrays of pointers are stable. The

[Bug 88501] AMD/ATI RS690M Console blanks to white

https://bugzilla.kernel.org/show_bug.cgi?id=88501 --- Comment #4 from Alex Deucher --- Created attachment 158211 --> https://bugzilla.kernel.org/attachment.cgi?id=158211=edit possible fix Does this patch fix the issue (against 3.17 or newer kernel)? -- You are receiving this mail because:

[PATCH 2/2] drm/msm: Add the eDP connector in msm drm driver

Modified the hard-coded hdmi connector/encoder implementations in msm drm driver to support both edp and hdmi. Signed-off-by: Hai Li --- drivers/gpu/drm/msm/mdp/mdp5/mdp5_encoder.c | 38 +-- drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c | 47 -

[PATCH 1/2] drm/msm: Initial add eDP support in msm drm driver

This change adds a new eDP connector in msm drm driver. With this change, eDP panel can work with msm platform under drm framework. Signed-off-by: Hai Li --- drivers/gpu/drm/msm/Makefile|6 + drivers/gpu/drm/msm/edp/edp.c | 211 drivers/gpu/drm/msm/edp/edp.h

[Bug 88501] AMD/ATI RS690M Console blanks to white

https://bugzilla.kernel.org/show_bug.cgi?id=88501 Alex Deucher changed: What|Removed |Added CC||alexdeucher at gmail.com --- Comment #3

[PATCH 1/1] DRM-vmwgfx: Deletion of an unnecessary check before the function call "vfree"

From: Markus Elfring Date: Wed, 19 Nov 2014 17:50:19 +0100 The vfree() function performes also input parameter validation. Thus the test around the call is not needed. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring ---

[Bug 86471] Unreal Engine 4.6 Editor dont start

rmMisc: FPlatformMisc::RequestExit(0) [2014.11.19-17.15.00:846][ 0]LogExit: Preparing to exit. [2014.11.19-17.15.00:852][ 0]LogExit: Exiting. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141119/0b98624e/attachment-0001.html>

[RFC PATCH 1/1] drm/exynos: Move platform drivers registration to module init

[adding Paolo and Vivek as cc] Hello, On 11/18/2014 07:41 PM, Kevin Hilman wrote: > > It fixes the DRM deadlock, issue for me on exynos5800-peach-pi, but then > it proceeds to panic in the workqueue code called by the asoc max98090 > codec[1]. > > If I then disable CONFIG_SND_SOC_SNOW, I can

[PATCH 11/11] drm/radeon: update the VM after setting BO address v3

r/b69c7c5dac >> libdrm: Git:master/00847fa48b >> LLVM: SVN:trunk/r54 (3.6 devel) >> X.Org: 2:1.16.1-1 >> Firmware: <http://people.freedesktop.org/~agd5f/radeon_ucode/> >> # 9e05820da42549ce9c89d147cf1f8e19 hawaii_ce.bin >> # c8bab593090fc54f239c8d7596c8d846 hawaii_mc.bin >> # 3618dbb955d8a84970e262bb2e6d2a16 hawaii_me.bin >> # c000b0fc9ff6582145f66504b0ec9597 hawaii_mec.bin >> # 0643ad24b3beff2214cce533e094c1b7 hawaii_pfp.bin >> # ba6054b7d78184a74602fd81607e1386 hawaii_rlc.bin >> # 11288f635737331b69de9ee82fe04898 hawaii_sdma.bin >> # 284429675a5560e0fad42aa982965fc2 hawaii_smc.bin >> libclc: Git:master/7f6f5bff1f >> DDX: 1:7.5.0-1 >> >> Let me know, if you need something else; see also the original thread >> <http://thread.gmane.org/gmane.comp.video.dri.devel/118415> for further >> information. >> >> Cheers, >> Kai >> > -- Kai Wasserbäch (Kai Wasserbaech) E-Mail: kai at dev.carbon-project.org -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 648 bytes Desc: OpenPGP digital signature URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141119/5e6f1370/attachment-0001.sig>

[RFC 7/7] drm: make the callers of drm_wait_vblank() allocate the memory

From: Paulo Zanoni This way, the Kernel users will be able to fully control the lifetime of struct drm_vblank_wait_item, and they will also be able to wrap it to store their own information. As a result, one less memory allocation will happen, and the Kernel codepath

[RFC 6/7] drm: make vblank_event_list handle drm_vblank_wait_item types

From: Paulo Zanoni Which means the list doesn't really need to know if the event is from user space or kernel space. The only place here where we have to break the abstraction is at drm_fops, when we're releasing all the events associated with a file_priv. Here we

[RFC 5/7] drm: change the drm vblank callback item type

From: Paulo Zanoni Now that we have created drm_vblank_wait_item, let's use it as the type passed. In the future, callers will have to use container_of to find our their original allocated structure, just like we're doing with the send_vblank_event() callback.

[RFC 4/7] drm: add wanted_seq to drm_vblank_wait_item

From: Paulo Zanoni Store the wanted sequence in the wait_item instead of storing it in the event structure that is eventually going to be sent to user space. The plan is to make Kernel vblank wait items not have the user space event, so we need to store the wanted

[RFC 3/7] drm: introduce struct drm_vblank_wait_item

From: Paulo Zanoni It's supposed to contain all the information that is required for both kernel and user space vblank wait items, but not hold any information required by just one of them. For now, we just moved the struct members from one place to another, but the

[RFC 2/7] drm: allow drm_wait_vblank_kernel() callback from workqueues

From: Paulo Zanoni This is going to be needed by i915.ko, and I guess other drivers could use it too. Signed-off-by: Paulo Zanoni --- drivers/gpu/drm/drm_irq.c | 46 - drivers/gpu/drm/i915/i915_debugfs.c | 45

[RFC 1/7] drm: allow the drivers to call the vblank IOCTL internally

From: Paulo Zanoni The i915.ko driver needs a way to schedule certain functions to run after some amount of vblanks. There are many different pieces of the driver which could benefit from that. Since what we want is essentially the vblank ioctl, this patch does the

[RFC] drm: add a mechanism for drivers to schedule vblank callbacks

From: Paulo Zanoni The drivers need a way to schedule functions to be ran after a certain number of vblanks. The i915.ko driver has plenty of examples where this could be used, such as for unpinning buffers after a modeset. Since the vblank wait IOCTL does basically

[RFC 0/7+1] Add in-kernel vblank delaying mechanism

From: Paulo Zanoni 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

[PATCH V8 00/14] drm/exynos: few patches to enhance bridge chip support

Am 19.11.2014 um 17:28 schrieb Javier Martinez Canillas: > On 11/19/2014 05:22 PM, Paolo Pisati wrote: >> On Wed, Nov 19, 2014 at 12:20:53PM +0100, Javier Martinez Canillas wrote: >>> >>> If someone else is interested, I've pushed a branch [0] with 3.18-rc5 + all >>> the needed patches. >>> >>>

[PATCH 1/1] DRM-UDL: Deletion of an unnecessary check before the function call "vunmap"

From: Markus Elfring Date: Wed, 19 Nov 2014 17:33:32 +0100 The vunmap() function performes also input parameter validation. Thus the test around the call is not needed. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring ---

[PATCH v2 2/2] arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy

Hi Javier, On Wed, Nov 19, 2014 at 5:06 PM, Javier Martinez Canillas wrote: > [adding Kukjin to cc list] > > Hello Vivek, > > On Wed, Nov 12, 2014 at 5:21 AM, Jingoo Han wrote: >> On Thursday, October 30, 2014 10:24 PM, Vivek Gautam wrote: >>> >>> DP PHY now require pmu-system-controller to

[PATCH V8 00/14] drm/exynos: few patches to enhance bridge chip support

Hello Paolo, On 11/19/2014 05:22 PM, Paolo Pisati wrote: > On Wed, Nov 19, 2014 at 12:20:53PM +0100, Javier Martinez Canillas wrote: >> >> If someone else is interested, I've pushed a branch [0] with 3.18-rc5 + all >> the needed patches. >> >> Ajay, feel free to add to your series: >> >>

[PATCH 08/11] drm/radeon/ci: apply disp voltage changes before clk changes

On Wed, Nov 19, 2014 at 4:59 PM, Alexandre Demers wrote: > Technical reminder about this patch: usually, for electronic > stability, you'll have to raise the voltage BEFORE increasing the > clock speed; on the other, you'll have to lower the voltage AFTER > lowering the clock speed. You may

[PATCH V8 00/14] drm/exynos: few patches to enhance bridge chip support

On Wed, Nov 19, 2014 at 12:20:53PM +0100, Javier Martinez Canillas wrote: > > If someone else is interested, I've pushed a branch [0] with 3.18-rc5 + all > the needed patches. > > Ajay, feel free to add to your series: > > Tested-by: Javier Martinez Canillas > > Best regards, > Javier > >

[PATCH 11/11] drm/radeon: update the VM after setting BO address v3

# 0643ad24b3beff2214cce533e094c1b7 hawaii_pfp.bin > # ba6054b7d78184a74602fd81607e1386 hawaii_rlc.bin > # 11288f635737331b69de9ee82fe04898 hawaii_sdma.bin > # 284429675a5560e0fad42aa982965fc2 hawaii_smc.bin > libclc: Git:master/7f6f5bff1f > DDX: 1:7.5.0-1 > > Let me know, if you need something else; see also the original thread > <http://thread.gmane.org/gmane.comp.video.dri.devel/118415> for further > information. > > Cheers, > Kai > -- next part -- A non-text attachment was scrubbed... Name: 0001-drm-radeon-update-the-VM-after-setting-BO-address-v4.patch Type: text/x-diff Size: 2831 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141119/253ea8dc/attachment.patch>

[PATCH 1/1] DRM-tilcdc: Deletion of an unnecessary check before the function call "drm_fbdev_cma_hotplug_event"

From: Markus Elfring Date: Wed, 19 Nov 2014 17:05:20 +0100 The drm_fbdev_cma_hotplug_event() function tests whether its argument is NULL and then returns immediately. Thus the test around the call is not needed. This issue was detected by using the Coccinelle

[PATCH 08/11] drm/radeon/ci: apply disp voltage changes before clk changes

Technical reminder about this patch: usually, for electronic stability, you'll have to raise the voltage BEFORE increasing the clock speed; on the other, you'll have to lower the voltage AFTER lowering the clock speed. You may encounter stability problem if you don't follow this order. The patch

Long radeon stalls on recent kernels

On Wed, Nov 19, 2014 at 4:07 PM, Andy Lutomirski wrote: > On Tue, Nov 18, 2014 at 11:19 PM, Michel Dänzer > wrote: >> On 19.11.2014 09:21, Andy Lutomirski wrote: >>> >>> On Mon, Nov 17, 2014 at 1:51 AM, Michel Dänzer >>> wrote: On 15.11.2014 07:21, Andy Lutomirski wrote: >

[Bug 88481] Kernel oops leaves system without graphical output [radeon]

https://bugzilla.kernel.org/show_bug.cgi?id=88481 Alex Deucher changed: What|Removed |Added CC||alexdeucher at gmail.com --- Comment #7

[PATCH 11/11] drm/radeon: update the VM after setting BO address v3

also the original thread <http://thread.gmane.org/gmane.comp.video.dri.devel/118415> for further information. Cheers, Kai -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 648 bytes Desc: OpenPGP digital signature URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141119/5e6b6ca9/attachment.sig>

[PATCH 1/1] DRM-EDID: Deletion of an unnecessary check before the function call "release_firmware"

From: Markus Elfring Date: Wed, 19 Nov 2014 16:33:17 +0100 The release_firmware() function tests whether its argument is NULL and then returns immediately. Thus the test around the call is not needed. This issue was detected by using the Coccinelle software.

Long radeon stalls on recent kernels

On 19.11.2014 09:21, Andy Lutomirski wrote: > On Mon, Nov 17, 2014 at 1:51 AM, Michel Dänzer wrote: >> On 15.11.2014 07:21, Andy Lutomirski wrote: >>> >>> On recent kernels (3.16 through 3.18-rc4, perhaps), doing anything >>> graphics intensive seems to cause my system to become unusable for >>>

3.18-rc regression: drm/nouveau: use shared fences for readable objects

On 19.11.2014 09:10, Maarten Lankhorst wrote: > Hey, > > On 19-11-14 07:43, Michael Marineau wrote: >> On 3.18-rc kernel's I have been intermittently experiencing GPU >> lockups shortly after startup, accompanied with one or both of the >> following errors: >> >> nouveau E[ PFIFO][:01:00.0]

[Bug 88501] AMD/ATI RS690M Console blanks to white

https://bugzilla.kernel.org/show_bug.cgi?id=88501 --- Comment #2 from business.kid at gmail.com --- Created attachment 158201 --> https://bugzilla.kernel.org/attachment.cgi?id=158201=edit Kernel Config 3.6.0-rc5+ -- You are receiving this mail because: You are watching the assignee of the

Long radeon stalls on recent kernels

On Tue, Nov 18, 2014 at 11:19 PM, Michel Dänzer wrote: > On 19.11.2014 09:21, Andy Lutomirski wrote: >> >> On Mon, Nov 17, 2014 at 1:51 AM, Michel Dänzer >> wrote: >>> >>> On 15.11.2014 07:21, Andy Lutomirski wrote: On recent kernels (3.16 through 3.18-rc4, perhaps), doing

[Bug 82186] [r600g] BARTS GPU lockup with minecraft shaders

ttp://lists.freedesktop.org/archives/dri-devel/attachments/20141119/76751ce7/attachment.html>

[PATCH v2] drm/tilcdc: add missing clk_put in tilcdc_unload()

We need to call clk_put on display clock, in the same way as functional clock. Also remove the check for priv->clk, since clk_put() is safe against NULL pointers. Signed-off-by: Julien CHAUVEAU --- Changes since v1: - remove the check for priv->clk, as suggested by Felipe Balbi

[Bug 88481] Kernel oops leaves system without graphical output [radeon]

https://bugzilla.kernel.org/show_bug.cgi?id=88481 Daniel Otero changed: What|Removed |Added Attachment #158101|application/octet-stream|text/plain mime type|

[Bug 88501] AMD/ATI RS690M Console blanks to white

https://bugzilla.kernel.org/show_bug.cgi?id=88501 --- Comment #1 from business.kid at gmail.com --- Created attachment 158191 --> https://bugzilla.kernel.org/attachment.cgi?id=158191=edit LSPCI -vnn -- You are receiving this mail because: You are watching the assignee of the bug.

[Bug 88501] New: AMD/ATI RS690M Console blanks to white

https://bugzilla.kernel.org/show_bug.cgi?id=88501 Bug ID: 88501 Summary: AMD/ATI RS690M Console blanks to white Product: Drivers Version: 2.5 Kernel Version: 3.6.0-rc5 to 3.18.0-rc4 Hardware: x86-64 OS: Linux

[PATCH 6/6] drm/atomic_helper: Make it clear that commit_planes gets the old state

On Wed, Nov 19, 2014 at 12:38 PM, Daniel Vetter wrote: > Oversight from my kerneldoc cleanup when doing the original atomic > helper series - I've only applied this clarification to the modeset > related helpers, and not the plane update code. Remedy this asap. > > Signed-off-by: Daniel Vetter

[PATCH 4/6] drm/crtc: Polish kerneldoc

On Wed, Nov 19, 2014 at 12:38 PM, Daniel Vetter wrote: > - Make it clear that it's a negative errno (more in line with > everything else). > - Clean up the confusion around get_properties vs. getproperty ioctls: > One reads per-obj property values, the other reads property > metadata. > >

[PATCH 5/6] drm: s/enum_blob_list/enum_list/ in drm_property

On Wed, Nov 19, 2014 at 12:38 PM, Daniel Vetter wrote: > I guess for hysterical raisins this was meant to be the way to read > blob properties. But that's done with the two-stage approach which > uses separate blob kms object and the special-purpose get_blob ioctl. > > Shipping userspace seems

[Intel-gfx] [PATCH 3/6] drm/atomic: Don't overrun the connector array when hotplugging

On Wed, Nov 19, 2014 at 12:38 PM, Daniel Vetter wrote: > Yet another fallout from not considering DP MST hotplug. With the > previous patches we have stable indices, but it might still happen > that a connector gets added between when we allocate the array and > when we actually add a connector.

[Intel-gfx] [PATCH 2/6] drm/atomic: Only destroy connector states with connection mutex held

On Wed, Nov 19, 2014 at 12:38 PM, Daniel Vetter wrote: > Otherwise the connector might have been unplugged and destroyed while > we didn't look. Yet another fallout from DP MST hotplugging that I > didn't consider. > > To make sure we get this right add an appropriate WARN_ON to >

[Intel-gfx] [PATCH 1/6] drm/atomic: Ensure that drm_connector_index is stable

On Wed, Nov 19, 2014 at 12:38 PM, Daniel Vetter wrote: > I've totally forgotten that with DP MST connectors can now be > hotplugged. And failed to adapt Rob's drm_atomic_state code (which > predates connector hotplugging) to the new realities. > > The first step is to make sure that the

[PATCH 01/11] drm/radeon: rework vm_flush parameters

On Wed, Nov 19, 2014 at 2:48 PM, Kai Wasserbäch wrote: > Christian König wrote on 19.11.2014 20:40: >> Am 19.11.2014 um 19:28 schrieb Alex Deucher: >>> On Wed, Nov 19, 2014 at 8:01 AM, Christian König >>> wrote: From: Christian König Use ring structure instead of index and

[PATCH] drm/tilcdc: add missing clk_put in tilcdc_unload()

We need to call clk_put on display clock, in the same way as functional clock. Signed-off-by: Julien CHAUVEAU --- drivers/gpu/drm/tilcdc/tilcdc_drv.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.c b/drivers/gpu/drm/tilcdc/tilcdc_drv.c index

[PATCH V8 00/14] drm/exynos: few patches to enhance bridge chip support

Hi Javier, In the cover letter, I have mentioned that it is tested on Linus tree: "This series is based on master branch of Linus tree at: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git" Kindly test the patches with that. Ajay On Wed, Nov 19, 2014 at 3:05 PM, Javier Martinez

[Bug 86320] Monitor on DisplayPort doesn't wake up

ttp://lists.freedesktop.org/archives/dri-devel/attachments/20141119/8a3014cc/attachment.html>

NULL derefs after failed suspend (i915, pm, ext4, slub)

On Tue, Oct 28, 2014 at 03:29:10PM +0100, Johan Hovold wrote: > Hi, > > I have had some problems with crashes involving suspend-to-disk after > updating to v3.16. > > Below is a log with 3.16.6 from a failed suspend attempt after which I > get a NULL deref in ext4 code. > > A couple of weeks

[PATCH v8 2/2] drm: add DT bindings documentation for atmel-hlcdc-dc driver

The Atmel HLCDC (HLCD Controller) IP available on some Atmel SoCs (i.e. at91sam9n12, at91sam9x5 family or sama5d3 family) provides a display controller device. The HLCDC block provides a single RGB output port, and only supports LCD panels connection to LCD panels for now. The atmel,panel

[PATCH v8 1/2] drm: add Atmel HLCDC Display Controller support

The Atmel HLCDC (HLCD Controller) IP available on some Atmel SoCs (i.e. at91sam9n12, at91sam9x5 family or sama5d3 family) provides a display controller device. This display controller supports at least one primary plane and might provide several overlays and an hardware cursor depending on the IP

[PATCH v8 0/2] drm: add support for Atmel HLCDC Display Controller

Hello, This patch series adds support for the Atmel HLCDC Display Controller embedded in the HLCDC block. The drivers supports basic CRTC functionalities, several overlays and provides an hardware cursor. At the moment, it only supports connection to LCD panels through an RGB connector (defined

[Bug 88481] Kernel oops leaves system without graphical output [radeon]

https://bugzilla.kernel.org/show_bug.cgi?id=88481 --- Comment #6 from Daniel Otero --- Reverting the commit ffe0245532b98efc4bc0e06f29c51d3f0e471152 from the tag v3.17.3 does resolve the issue. Thanks for your time. -- You are receiving this mail because: You are watching the assignee of the

[PATCH] device coredump: fix minor issue in Kconfig file

On Wed, 2014-11-19 at 05:28 -0800, Amitkumar Karwar wrote: > if "CONFIG_DEV_COREDUMP=y" is added to configuration file, it > gets removed when final configuration file is generated. The > reason is it requires CONFIG_WANT_DEV_COREDUMP to be enabled. > > Currently "make menuconfig" doesn't display

[PATCH] drm/tilcdc: fix check for display clock in tilcdc_load()

This appears to be a copy-paste error. We need to check for errors on disp_clk. Signed-off-by: Julien CHAUVEAU --- drivers/gpu/drm/tilcdc/tilcdc_drv.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.c b/drivers/gpu/drm/tilcdc/tilcdc_drv.c

[PATCH 11/11] drm/radeon: update the VM after setting BO address v3

Am 19.11.2014 um 14:16 schrieb Kai Wasserbäch: > Dear Christian, > Christian König wrote on 19.11.2014 14:01: >> From: Christian König >> >> This way the necessary VM update is kicked off immediately >> if all BOs involved are in GPU accessible memory. >> >> v2: fix vm lock >> v3: immediately

[RFC PATCH 1/1] drm/exynos: Move platform drivers registration to module init

Kevin Hilman writes: > Javier Martinez Canillas writes: > >> [adding Paolo and Vivek as cc] >> >> Hello, >> >> On 11/18/2014 07:41 PM, Kevin Hilman wrote: >>> >>> It fixes the DRM deadlock, issue for me on exynos5800-peach-pi, but then >>> it proceeds to panic in the workqueue code called by

[RFC] drm: Start documenting userspace ABI

On Tue, Nov 18, 2014 at 04:24:39PM +0100, Thierry Reding wrote: > On Tue, Nov 18, 2014 at 04:05:08PM +0100, David Herrmann wrote: > > Hi > > > > On Tue, Nov 18, 2014 at 3:43 PM, Thierry Reding > > wrote: > > > On Tue, Nov 18, 2014 at 03:27:27PM +0100, Daniel Vetter wrote: > > >> On Tue, Nov 18,

[PATCH v12 1/3] drm: rockchip: Add basic drm driver

On Wed, Nov 19, 2014 at 10:04:13AM +0100, Boris Brezillon wrote: > AFAIU, the suggestion was to split drm_connector_init and > drm_connector_register calls: > - drm_connector_init call should still be part of the load procedure >(this function adds the connector to the connector list which is

[PATCH 11/11] drm/radeon: update the VM after setting BO address v3

gital signature URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141119/f633607a/attachment-0001.sig>

[PATCH 11/11] drm/radeon: update the VM after setting BO address v3

From: Christian König This way the necessary VM update is kicked off immediately if all BOs involved are in GPU accessible memory. v2: fix vm lock v3: immediately update unmaps as well Signed-off-by: Christian König --- drivers/gpu/drm/radeon/radeon_gem.c | 64

[PATCH 10/11] drm/radeon: sync PT updates as shared v2

From: Christian König Only invalidating PTEs needs to be executed synchronized to using the PT. v2: fix sync to uses Signed-off-by: Christian König --- drivers/gpu/drm/radeon/radeon_vm.c | 9 - 1 file changed, 8 insertions(+), 1 deletion(-) diff --git

[PATCH 09/11] drm/radeon: sync PD updates as shared

From: Christian König We never invalidate PD entries and making them valid can run with other users in parallel. Signed-off-by: Christian König --- drivers/gpu/drm/radeon/radeon_vm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH 08/11] drm/radeon: fence BO_VAs manually

From: Christian König This allows us to finally remove the VM fence and so allow concurrent use of it from different engines. Signed-off-by: Christian König --- drivers/gpu/drm/radeon/radeon.h| 7 +++ drivers/gpu/drm/radeon/radeon_cs.c | 6 +-

[PATCH 07/11] drm/radeon: use one VMID for each ring

From: Christian König Use multiple VMIDs for each VM, one for each ring. That allows us to execute flushes separately on each ring, still not ideal cause in a lot of cases rings can share IDs. Signed-off-by: Christian König --- drivers/gpu/drm/radeon/cik.c |

[PATCH 06/11] drm/radeon: track VM update fences separately

From: Christian König Note for each fence if it's a VM page table update or not. This allows us to determine the last VM update in a sync object and so to figure out if we need to flush the TLB or not. Signed-off-by: Christian König ---

[PATCH 05/11] drm/radeon: fence PT updates manually v2

From: Christian König This allows us to add the real execution fence as shared. v2: fix typo Signed-off-by: Christian König --- drivers/gpu/drm/radeon/radeon_object.c | 19 ++ drivers/gpu/drm/radeon/radeon_object.h | 2 ++

[PATCH 04/11] drm/radeon: split semaphore and sync object handling v2

From: Christian König Previously we just allocated space for four hardware semaphores in each software semaphore object. Make software semaphore objects represent only one hardware semaphore address again by splitting the sync code into it's own object. v2: fix typo

[PATCH 03/11] drm/radeon: remove unnecessary VM syncs

From: Christian König The PD/PTs reservation object now contains everything needed. Signed-off-by: Christian König --- drivers/gpu/drm/radeon/radeon_vm.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/gpu/drm/radeon/radeon_vm.c

[PATCH 02/11] drm/radeon: stop re-reserving the BO in radeon_vm_bo_set_addr

From: Christian König That's useless when all callers drop the reservation immediately after calling the function. Signed-off-by: Christian König --- drivers/gpu/drm/radeon/radeon_gem.c | 2 +- drivers/gpu/drm/radeon/radeon_kms.c | 2 --

[PATCH 01/11] drm/radeon: rework vm_flush parameters

From: Christian König Use ring structure instead of index and provide vm_id and pd_addr separately. Signed-off-by: Christian König --- drivers/gpu/drm/radeon/cik.c | 23 ++- drivers/gpu/drm/radeon/cik_sdma.c| 22

[RFC PATCH v2] drm/exynos: make non kms drivers to be indenpendent modules

Hi YoungJun, On 2014년 11월 19일 13:39, YoungJun Cho wrote: > Hi Inki, > > There are 3 comments below. > > On 11/19/2014 12:19 PM, Inki Dae wrote: >> This patch makes non kms drivers to be independent modules. >> For this, it removes all register codes to non kms drivers >> from

[RFC PATCH v2] drm/exynos: make non kms drivers to be indenpendent modules

Hi Inki, There are 3 comments below. On 11/19/2014 12:19 PM, Inki Dae wrote: > This patch makes non kms drivers to be independent modules. > For this, it removes all register codes to non kms drivers > from exynos_drm_drv module and adds module_init/exit > for each non kms driver so that each

[PATCH 01/11] drm/radeon: rework vm_flush parameters

On Wed, Nov 19, 2014 at 8:01 AM, Christian König wrote: > From: Christian König > > Use ring structure instead of index and provide vm_id and pd_addr separately. > > Signed-off-by: Christian König Pushed to my 3.19-wip tree. I'll send out a new radeon drm-next pull request later today or

[PATCH] drm/tegra: Select root window for event dispatch

In finish pageflip, the driver was not selecting the root window when dispatching events. This exposed a race where a plane update would change the window selection and cause tegra_dc_finish_page_flip to check the wrong base address. This patch also protects access to the window selection

[PATCH 11/11] drm/radeon/ci: disable needless sclk changes

The current code always reprogrammed the sclk levels, but we don't currently handle disp sclk requirements so just skip it. Signed-off-by: Alex Deucher --- drivers/gpu/drm/radeon/ci_dpm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/radeon/ci_dpm.c

[PATCH 10/11] drm/radeon/ci: force pcie level before sclk and mclk

Preferred ordering. Signed-off-by: Alex Deucher --- drivers/gpu/drm/radeon/ci_dpm.c | 34 +- 1 file changed, 17 insertions(+), 17 deletions(-) diff --git a/drivers/gpu/drm/radeon/ci_dpm.c b/drivers/gpu/drm/radeon/ci_dpm.c index 73f8c4b..630434c 100644 ---

[PATCH 09/11] drm/radeon/ci: use different smc command for pcie dpm

Use unforce levels rather than enable mask instruction. This is the preferred method. Signed-off-by: Alex Deucher --- drivers/gpu/drm/radeon/ci_dpm.c | 12 ++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/radeon/ci_dpm.c

[PATCH 08/11] drm/radeon/ci: apply disp voltage changes before clk changes

Apply voltage changes for displays before changing clocks. Signed-off-by: Alex Deucher --- drivers/gpu/drm/radeon/ci_dpm.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/radeon/ci_dpm.c b/drivers/gpu/drm/radeon/ci_dpm.c index c9963b5..e781628 100644 ---

[PATCH 07/11] drm/radeon: fix PCC debugging message for CI DPM

Add missing newline and print the bad gpio shift. Signed-off-by: Alex Deucher --- drivers/gpu/drm/radeon/ci_dpm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/radeon/ci_dpm.c b/drivers/gpu/drm/radeon/ci_dpm.c index 8312140..c9963b5 100644 ---

  1   2   >