[Bug 76490] Hang during boot when DPM is on (R9 270X)

vel/attachments/20140702/f70617e0/attachment.html>

[Bug 69723] GPU lockups with kernel 3.11.0 / 3.12-rc1 when dpm=1 on r600g (Cayman)

speed capacity for cards not sticking to reference board) -- 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/20140702/08cf2

display put to sleep before init completes (& stays black)

On Wed, 02 Jul 2014, Vernon Tonnesen wrote: > Details reported in https://bugzilla.redhat.com/show_bug.cgi?id=1115241 > > Is this a DRI problem? Smells like an i915 problem. Please file a bug on DRM/Intel at https://bugs.freedesktop.org/enter_bug.cgi?product=DRI. Thanks, Jani. -- Jani

[Bug 76223] [radeonsi] luxmark segfault

t;http://lists.freedesktop.org/archives/dri-devel/attachments/20140702/76362ace/attachment.html>

[PATCH 1/3] drm/radeon: stop poisoning the GART TLB

> FWIW, I've also had successful runs with the first three of the split > changes, and with all of them. Ok I've just pushed a branch testing-3.15-v3 to fdo which moves all page table allocation to the end of VRAM. Please try with this memory layout, it should give us a good idea if it's indeed

[PATCH] drm/radeon: page table BOs are kernel allocations

From: Christian K?nig Userspace shouldn't be able to access them. Signed-off-by: Christian K?nig Cc: stable at vger.kernel.org --- drivers/gpu/drm/radeon/radeon_vm.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git

[PATCH 4/4] ARM: tegra: roth: add display DT node

DSI support has been fixed to support continuous clock behavior that the panel used on SHIELD requires, so finally add its device tree node since it is functional. Signed-off-by: Alexandre Courbot --- arch/arm/boot/dts/tegra114-roth.dts | 23 --- 1 file changed, 20

[PATCH 3/4] drm/panel: LG LH500WX1-SD03 uses continuous clock

This panel can only operate in continuous clock behavior, so set the appropriate flag to inform host drivers of this fact. Signed-off-by: Alexandre Courbot --- drivers/gpu/drm/panel/panel-simple.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH 2/4] drm/tegra: dsi - Handle continuous clock flag

Handle the MIPI_DSI_MODE_CLOCK_CONTINUOUS flag and only set TX-only clock behavior when this flag is not present for the DSI device. Signed-off-by: Alexandre Courbot --- drivers/gpu/drm/tegra/dsi.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/tegra/dsi.c

[PATCH 1/4] drm/dsi: Add flag for continuous clock behavior

As per section 5.6.1 of the DSI specification, all DSI transmitters must support continuous clock behavior on the clock lane, while non-continuous mode support is only optional. Add a flag that allows devices to indicate that they require continuous clock mode to operate properly. Signed-off-by:

[PATCH 0/4] drm/dsi/tegra: continuous clock support

This small series adds support for DSI continuous clock as required by the DSI specification and as needed for NVIDIA SHIELD's panel. Continuous clock mode can be specified as the flags of a DSI device, and host drivers can check this flag to adapt their behavior. The flag is then added to the

[PATCH] drm/ttm: fix handling of TTM_PL_FLAG_TOPDOWN

From: Christian K?nig bo->mem.placement is not initialized when ttm_bo_man_get_node is called, so the flag had no effect at all. Signed-off-by: Christian K?nig Cc: stable at vger.kernel.org --- drivers/gpu/drm/ttm/ttm_bo.c | 6 +++---

[Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

On Wed, Jul 02, 2014 at 12:05:27PM -0400, Konrad Rzeszutek Wilk wrote: > On Wed, Jul 02, 2014 at 05:08:43PM +0300, Michael S. Tsirkin wrote: > > On Wed, Jul 02, 2014 at 10:00:33AM -0400, Konrad Rzeszutek Wilk wrote: > > > On Wed, Jul 02, 2014 at 01:33:09PM +0200, Paolo Bonzini wrote: > > > > Il

[Bug 77001] Radeon R9 270X GPU lockup and resume failure after all night inactivity [drm,radeonsi]

https://bugzilla.kernel.org/show_bug.cgi?id=77001 Grzegorz Kowal changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

[PATCH] ASoC: tda998x: add a codec to the HDMI transmitter

ure.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140702/bc2ef7e8/attachment-0001.sig>

[PATCH] ASoC: tda998x: add a codec to the HDMI transmitter

ktop.org/archives/dri-devel/attachments/20140702/6be10f4f/attachment-0001.sig>

[Bug 80827] [radeonsi,R9 270X] Corruptions in window menus in KDE

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

[Bug 80827] [radeonsi,R9 270X] Corruptions in window menus in KDE

next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140702/218858ae/attachment.html>

[Bug 68571] GPU lockup on AMD Radeon HD6850 with DPM=1

https://bugzilla.kernel.org/show_bug.cgi?id=68571 --- Comment #60 from Alex Deucher --- (In reply to kilobug from comment #59) > I mean I manually applied the patch on > https://bugzilla.kernel.org/attachment.cgi?id=141741=diff to the > "drm-fixes-3.16" branch, I'll try the drm-fixes-3.16-wip

[Bug 68571] GPU lockup on AMD Radeon HD6850 with DPM=1

https://bugzilla.kernel.org/show_bug.cgi?id=68571 --- Comment #59 from kilobug at kilobug.org --- I mean I manually (In reply to Alex Deucher from comment #56) > (In reply to kilobug from comment #55) > > I tried the patch on the "drm-fixes-3.16" branch, but I got the same result > > : freeze

[Bug 80827] [radeonsi,R9 270X] Corruptions in window menus in KDE

|| -- 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/20140702/57d3032d/attachment.html>

[Bug 80827] New: [radeonsi,R9 270X] Corruptions in window menus in KDE

e for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140702/fb089ea3/attachment.html>

[Bug 76490] Hang during boot when DPM is on (R9 270X)

-- 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/20140702/f79c30aa/attachment-0001.html>

[PATCH] ASoC: tda998x: add a codec to the HDMI transmitter

On Wed, 2 Jul 2014 18:56:28 +0200 Andrew Lunn wrote: > How well will this work with Russell concept of a front end and two > backends? Can you uses your CODEC twice, once with the I2S backend and > a second time with the S/PDIF backend? Hi Andrew, The TDA998x CODEC has two functions: - it sets

[Bug 80015] Transparency glitches in native Civilization 5 (Civ5) port

ttp://lists.freedesktop.org/archives/dri-devel/attachments/20140702/02dd2716/attachment.html>

[PATCH 2/2] drm/radeon: Complete page flip even if waiting on the BO fence fails

From: Michel D?nzer Otherwise the DRM core and userspace will be confused about which BO the CRTC is scanning out. Signed-off-by: Michel D?nzer --- drivers/gpu/drm/radeon/radeon_display.c | 24 +--- 1 file changed, 9 insertions(+), 15 deletions(-)

[PATCH 1/2] drm/radeon: Move pinning the BO back to radeon_crtc_page_flip()

From: Michel D?nzer As well as enabling the vblank interrupt. These shouldn't take any significant amount of time, but at least pinning the BO has actually been seen to fail in practice before, in which case we need to let userspace know about it. Signed-off-by: Michel

[RFC] drm/msm: DT support for 8960/8064

On Tue, Jul 01, 2014 at 07:57:35PM +0100, Rob Clark wrote: > Now that we (almost) have enough dependencies in place (MMCC, RPM, etc), > add necessary DT support so that we can use drm/msm on upstream kernel. > > Signed-off-by: Rob Clark > --- > Commence bikeshedding :-) > >

[PATCH] ASoC: tda998x: add a codec to the HDMI transmitter

On Wed, Jul 02, 2014 at 07:51:54PM +0200, Jean-Francois Moine wrote: > On Wed, 2 Jul 2014 18:56:28 +0200 > Andrew Lunn wrote: > > > How well will this work with Russell concept of a front end and two > > backends? Can you uses your CODEC twice, once with the I2S backend and > > a second time

[PATCH] ASoC: tda998x: add a codec to the HDMI transmitter

On Wed, Jul 02, 2014 at 06:38:41PM +0200, Jean-Francois Moine wrote: > This patch adds a CODEC function to the NXP TDA998x HDMI transmitter. > > The CODEC handles both I2S and S/PDIF inputs and does dynamic input > switch in the TDA998x I2C driver on start/stop audio streaming. Hi Jean-Francois

[PATCH] drm/radeon: add user pointer support v2

> Yes this could be argued that way, that anyway user than can use the gpu > can already pin large amount of ram. But pining anonymous memory or file > backed memory (ie non regular bo memory) is different as pages are still > on the lru list and thus the vmscan code will still go over them which

[Bug 80419] XCOM: Enemy Unknown Causes lockup

tachments/20140702/145ddb93/attachment.html>

[PATCH] ASoC: tda998x: add a codec to the HDMI transmitter

This patch adds a CODEC function to the NXP TDA998x HDMI transmitter. The CODEC handles both I2S and S/PDIF inputs and does dynamic input switch in the TDA998x I2C driver on start/stop audio streaming. Signed-off-by: Jean-Francois Moine --- This patch applies against linux-next. ---

[Bug 68571] GPU lockup on AMD Radeon HD6850 with DPM=1

https://bugzilla.kernel.org/show_bug.cgi?id=68571 --- Comment #58 from perry3d at gmail.com --- Created attachment 141941 --> https://bugzilla.kernel.org/attachment.cgi?id=141941=edit Directly booted into Arch Linux -- You are receiving this mail because: You are watching the assignee of the

[Bug 68571] GPU lockup on AMD Radeon HD6850 with DPM=1

https://bugzilla.kernel.org/show_bug.cgi?id=68571 --- Comment #57 from perry3d at gmail.com --- Created attachment 141931 --> https://bugzilla.kernel.org/attachment.cgi?id=141931=edit Log file after i boot Windows 7 Hi again, the bug is still not fixed for me. I still get a freeze when login

[Bug 68571] GPU lockup on AMD Radeon HD6850 with DPM=1

https://bugzilla.kernel.org/show_bug.cgi?id=68571 --- Comment #56 from Alex Deucher --- (In reply to kilobug from comment #55) > I tried the patch on the "drm-fixes-3.16" branch, but I got the same result > : freeze after a while when playing a movie on mplayer -vo gl (that's the > most reliable

[PATCH 1/1] drm/vmwgfx: correct fb_fix_screeninfo.line_length

At least one source has reported that vmwgfx_fb.c::vmw_fb_check_var() is not even a code path that is traversed when the bug occurs (i.e. inserted unique log message -> never seen in logs). Also, everyone encountering the bug seems to be on a slightly older version of VMWare Player. It does not

[Bug 68571] GPU lockup on AMD Radeon HD6850 with DPM=1

https://bugzilla.kernel.org/show_bug.cgi?id=68571 --- Comment #55 from kilobug at kilobug.org --- I tried the patch on the "drm-fixes-3.16" branch, but I got the same result : freeze after a while when playing a movie on mplayer -vo gl (that's the most reliable method I found to get the freeze),

[PATCH v3 0/3] drm/nouveau: support for probing platform devices

On Thu, Jun 26, 2014 at 2:33 PM, Alexandre Courbot wrote: > This series adds support for probing platform devices on Nouveau, as well as > the DT bindings for GK20A. It doesn't enable the GPU yet on Tegra boards since > a few extra things need to be supported before that. > > This version is

[PATCH/RESEND 0/9] drm: tilcdc driver fixes

On 02 Jul 02:08 PM, Dave Airlie wrote: > On 2 July 2014 12:31, Darren Etheridge wrote: > > On 07/01/2014 06:39 PM, Guido Mart?nez wrote: > >> > >> On Fri, Jun 27, 2014 at 05:08:51PM -0500, Darren Etheridge wrote: > >>> > >>> [snip] > >>> > >>> Otherwise I think this is a good and useful patch

[pull] radeon drm-fixes-3.16

Hi Dave, Some additional radeon fixes for 3.16. It's a bit bigger than usual since I missed last week. Fixes for some system hangs, displays issues, and some fallout from the new pageflipping changes. The following changes since commit 0fcb70c30131aac40f62ba13f89963d5c13b48a7: Merge tag

[PATCH RFC v2 3/8] component: add support for component match array

On Thu, Jul 03, 2014 at 12:26:39AM +0900, Inki Dae wrote: > It's has been just a week. I will check and look into your patch > series. I think Exynos drm should also be considered for the use of > component match array. Actually, this series has been around for much longer than just a week. Your

[RFC] drm/msm: DT support for 8960/8064

On Wed, Jul 2, 2014 at 2:09 PM, Mark Rutland wrote: > On Tue, Jul 01, 2014 at 07:57:35PM +0100, Rob Clark wrote: >> Now that we (almost) have enough dependencies in place (MMCC, RPM, etc), >> add necessary DT support so that we can use drm/msm on upstream kernel. >> >> Signed-off-by: Rob Clark

[PATCH 0/2] Update copyright notices for Renesas DRM drivers

Hi Dave, Could you please pick those two patches up for v3.17 ? On Thursday 06 February 2014 18:41:56 Laurent Pinchart wrote: > The "Renesas Corporation" listed in the copyright notices doesn't exist. > Replace it with "Renesas Electronics Corporation" and update the > copyright years. > >

[RFC] drm/msm: DT support for 8960/8064

On Wed, Jul 2, 2014 at 1:12 PM, Olof Johansson wrote: > On Wed, Jul 2, 2014 at 7:26 AM, Jordan Crouse > wrote: >> On 07/01/2014 12:57 PM, Rob Clark wrote: >>> >>> diff --git a/Documentation/devicetree/bindings/drm/msm/gpu.txt >>> b/Documentation/devicetree/bindings/drm/msm/gpu.txt >>> new file

[PATCH 4/7] Exynos: add support for 'domain-always-on' property

Hi Marek, On 07/01/2014 06:08 PM, Marek Szyprowski wrote: > Hello, > > On 2014-07-01 10:52, Tobias Jakobi wrote: >> Hello Marek, >> >> I think you had a similar patch in the tizen tree, but according to >> Tomasz Figa, it was considered a hack. I don't quite see how this is >> different. >> >>

[RFC][PATCH] gpu:drm:i915:intel_detect_pch: back to check devfn instead of check class type

On 2014/7/2 14:21, Michael S. Tsirkin wrote: > On Thu, Jun 19, 2014 at 05:53:51PM +0800, Tiejun Chen wrote: >> Originally the reason to probe ISA bridge instead of Dev31:Fun0 >> is to make graphics device passthrough work easy for VMM, that >> only need to expose ISA bridge to let driver know the

[PATCH v3 RESEND] drm/i2c: tda998x: Fix lack of required reg in DT documentation

On Thu, Jun 19, 2014 at 10:47:32AM +0200, Jean-Francois Moine wrote: > The I2C address (reg) is required for the TDA998x driver to be loaded > and initialized. > > Signed-off-by: Jean-Francois Moine > --- > - v3 > - change subject to drm/i2c > - v2 > - don't force the I2C address to

[PATCH v3 0/8] component helper improvements

On Tue, Jul 01, 2014 at 03:40:11PM +0100, Russell King - ARM Linux wrote: > A while back, Laurent raised some comments about the component helper, > which this patch set starts to address. I looked back over the two other times which this series has posted, and noticed that two patches had been

[PATCH 1/3] drm/radeon: stop poisoning the GART TLB

On 01.07.2014 21:16, Christian K?nig wrote: > Am 01.07.2014 08:48, schrieb Michel D?nzer: >> On 30.06.2014 16:43, Christian K?nig wrote: >>> Am 30.06.2014 08:10, schrieb Michel D?nzer: On 29.06.2014 19:34, Christian K?nig wrote: > I've just pushed the branch testing-3.15 to >

[PATCH] drm/radeon: page table BOs are kernel allocations

On Wed, Jul 2, 2014 at 3:28 PM, Christian K?nig wrote: > From: Christian K?nig > > Userspace shouldn't be able to access them. > > Signed-off-by: Christian K?nig > Cc: stable at vger.kernel.org I assume this is for 3.15. I had to tweak it slightly for 3.16. Reviewed-by: Alex Deucher > ---

[Bug 79850] [awesomenauts][radeonsi] pageflip is clearly missing vblank with vsync on

part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140702/b75b68d0/attachment.html>

[Bug 64131] Radeon card stays in highest DPM power state on boot and after resume

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

[PATCH 2/2] drm/udl: Implement page_flip ioctl

This is a very crude page_flip implementation for UDL. There are ways to make it better (make it asynchronous, make it do actual vsynced flips...) but that's for another patch. Signed-off-by: St?phane Marchesin --- drivers/gpu/drm/udl/udl_modeset.c | 21 + 1 file changed, 21

[PATCH 1/2] drm/udl: add vblank support

This is needed to be able to send page flip completion events. Also while I'm at it, fix the error paths on init. Signed-off-by: St?phane Marchesin --- drivers/gpu/drm/udl/udl_main.c | 15 +++ 1 file changed, 15 insertions(+) diff --git a/drivers/gpu/drm/udl/udl_main.c

[RFC] drm/msm: DT support for 8960/8064

On 07/02/2014 03:01 PM, Rob Clark wrote: > As far as I can tell from diving downstream android kgsl code, seems > like some a2xx you might be able to read the value from hw. Beyond > that I'm not entirely sure. (Remember, no docs.) Ohhh! I get to tell a story! The on chip registers have a long

[PATCH] glx/dri3: Use four buffers until X driver supports async flips

A driver which doesn't have async flip support will queue up flips without any way to replace them afterwards. This means we've got a scanout buffer pinned as soon as we schedule a flip and so we need another buffer to keep from stalling. When vblank_mode=0, if there are only three buffers we do:

[PATCH 1/1] drm/i915: replace ALIGN(PAGE_SIZE) by PAGE_ALIGN

On Tue, 01 Jul 2014, Fabian Frederick wrote: > use mm.h definition > > Cc: Daniel Vetter > Cc: Jani Nikula > Cc: intel-gfx at lists.freedesktop.org > Cc: dri-devel at lists.freedesktop.org > Signed-off-by: Fabian Frederick Pushed to drm-intel-next-queued, thanks for the patch. BR, Jani. >

[PATCH/RESEND 0/9] drm: tilcdc driver fixes

On 2 July 2014 12:31, Darren Etheridge wrote: > On 07/01/2014 06:39 PM, Guido Mart?nez wrote: >> >> On Fri, Jun 27, 2014 at 05:08:51PM -0500, Darren Etheridge wrote: >>> >>> [snip] >>> >>> Otherwise I think this is a good and useful patch series. >> >> It that a Tested-by tag? :) > > > Sure - I

[PATCH] drm: reduce default drm vblank off delay to 50ms

On Wed, 2 Jul 2014 13:35:19 -0700 St?phane Marchesin wrote: > On Tue, Oct 30, 2012 at 12:20 PM, Daniel Vetter wrote: > > On Tue, Oct 30, 2012 at 8:09 PM, Jesse Barnes > > wrote: > >> People keep whining about this, but no one seems to send a patch. This > >> *ought* to be safe now that we've

[PATCH 1/2] drm/radeon: Move pinning the BO back to radeon_crtc_page_flip()

Am 02.07.2014 12:10, schrieb Michel D?nzer: > From: Michel D?nzer > > As well as enabling the vblank interrupt. These shouldn't take any > significant amount of time, but at least pinning the BO has actually been > seen to fail in practice before, in which case we need to let userspace > know

[PATCH] drm: reduce default drm vblank off delay to 50ms

On Tue, Oct 30, 2012 at 12:20 PM, Daniel Vetter wrote: > On Tue, Oct 30, 2012 at 8:09 PM, Jesse Barnes > wrote: >> People keep whining about this, but no one seems to send a patch. This >> *ought* to be safe now that we've dealt with the hw races in Mario's >> updated code, and fixed the bugs

[PATCH v2 1/2] drm/radeon: Program page flips to execute in hblank instead of vblank

Am 02.07.2014 05:55, schrieb Michel D?nzer: > From: Michel D?nzer > > But move the programming back to the vertical blank interrupt handler. > And signal the flip as being completed immediately after programming it > to the hardware. > > This way we don't have to guess whether or not the hardware

Pixel clock property from DT is not used in OMAP DRM

Hi all, I was trying to bring up parallel LCD on our custom board (similar to BeagleBoard-xM) and I did it finally - but I needed to tweak hardcoded value of 'Invert pixel clock'. Maybe I'm doing something wrong, but anyway: According to the display-timing.txt doc the

[PATCH v2 2/2] drm/radeon: Remove radeon_kms_pflip_irq_get/put() and the pflip atomic

From: Michel D?nzer The vertical blank interrupt is already enabled/disabled via drm_vblank_get/put(), and radeon_crtc_handle_flip() now bails gracefully when there is no page flip ready. Signed-off-by: Michel D?nzer --- v2: Remove the pflip atomic as well

[PATCH v2 1/2] drm/radeon: Program page flips to execute in hblank instead of vblank

From: Michel D?nzer But move the programming back to the vertical blank interrupt handler. And signal the flip as being completed immediately after programming it to the hardware. This way we don't have to guess whether or not the hardware will execute the flip in a

[PATCH 1/2] drm/radeon: Program page flips to execute in hblank instead of vblank

On 02.07.2014 12:11, Michel D?nzer wrote: > On 02.07.2014 12:01, Dieter N?tzel wrote: >> Am 02.07.2014 02:29, schrieb Michel D?nzer: >>> On 02.07.2014 01:46, Dieter N?tzel wrote: Am 01.07.2014 10:14, schrieb Michel D?nzer: > From: Michel D?nzer > > But move the programming back

[Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

On Wed, Jul 02, 2014 at 06:29:23PM +0200, Paolo Bonzini wrote: > Il 02/07/2014 17:27, Michael S. Tsirkin ha scritto: > > At some level, maybe Paolo is right. Ignore existing drivers and ask > > intel developers to update their drivers to do something sane on > > hypervisors, even if they do ugly

[RFC PATCH 0/8] component helper improvements

On Wed, May 14, 2014 at 08:42:17PM +0200, Thierry Reding wrote: > I've been looking at converting the Tegra DRM driver to the component > helpers for a while now and had to make some changes to make it work for > that particular use-case. While updating the imx-drm and msm DRM drivers > for those

[PATCH 1/2] drm/radeon: Program page flips to execute in hblank instead of vblank

On 02.07.2014 12:01, Dieter N?tzel wrote: > Am 02.07.2014 02:29, schrieb Michel D?nzer: >> On 02.07.2014 01:46, Dieter N?tzel wrote: >>> Am 01.07.2014 10:14, schrieb Michel D?nzer: From: Michel D?nzer But move the programming back to the vertical blank interrupt handler. And

[Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

On Wed, Jul 02, 2014 at 05:08:43PM +0300, Michael S. Tsirkin wrote: > On Wed, Jul 02, 2014 at 10:00:33AM -0400, Konrad Rzeszutek Wilk wrote: > > On Wed, Jul 02, 2014 at 01:33:09PM +0200, Paolo Bonzini wrote: > > > Il 01/07/2014 19:39, Ross Philipson ha scritto: > > > > > > > >We do IGD

[Bug 79862] Driver crash while playing YouTube video (flash)

. It's extremely annoying. I switched to Windows for the time being. -- 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/20140

[PATCH] exynos: Put a stop to the userptr heresy.

On Thu, Jul 03, 2014 at 12:09:25AM +0900, Inki Dae wrote: > 2014-07-02 0:03 GMT+09:00 Jerome Glisse : > > On Tue, Jul 01, 2014 at 05:55:25PM +0900, Inki Dae wrote: > >> > >> Hi Jerome, > >> > >> > >> On 2014? 07? 01? 06:46, j.glisse at gmail.com wrote: > >> > From: Jerome Glisse > >> > > >> >

[PATCH v2 0/9] Updated fence patch series

op 02-07-14 07:37, Greg KH schreef: > On Tue, Jul 01, 2014 at 12:57:02PM +0200, Maarten Lankhorst wrote: >> So after some more hacking I've moved dma-buf to its own subdirectory, >> drivers/dma-buf and applied the fence patches to its new place. I believe >> that the >> first patch should be

drm: i915: "plane B assertion failure, should be off on pipe B but is still active"

On Tue, 2014-07-01 at 12:17 +0300, Jani Nikula wrote: > This does not ring any bells to me (but that doesn't prove anything). A > bisect result would be awesome. Too bad. Unless someone else has a better idea I hope to start bisecting one of these days (that might take quite some time,

[RFC] drm/msm: DT support for 8960/8064

On 07/02/2014 08:42 AM, Rob Clark wrote: > On Wed, Jul 2, 2014 at 10:26 AM, Jordan Crouse > wrote: >> >> On 07/01/2014 12:57 PM, Rob Clark wrote: >>> >>> diff --git a/Documentation/devicetree/bindings/drm/msm/gpu.txt >>> b/Documentation/devicetree/bindings/drm/msm/gpu.txt >>> new file mode

[RFC] drm/msm: DT support for 8960/8064

On Wed, Jul 2, 2014 at 10:26 AM, Jordan Crouse wrote: > > On 07/01/2014 12:57 PM, Rob Clark wrote: >> >> diff --git a/Documentation/devicetree/bindings/drm/msm/gpu.txt >> b/Documentation/devicetree/bindings/drm/msm/gpu.txt >> new file mode 100644 >> index 000..6e33efe >> --- /dev/null >>

[PATCH v3 0/3] drm/nouveau: support for probing platform devices

On 07/02/2014 03:09 AM, Alexandre Courbot wrote: > On Thu, Jun 26, 2014 at 2:33 PM, Alexandre Courbot > wrote: >> This series adds support for probing platform devices on Nouveau, as well as >> the DT bindings for GK20A. It doesn't enable the GPU yet on Tegra boards >> since >> a few extra

[RFC] drm/msm: DT support for 8960/8064

On Wed, Jul 2, 2014 at 7:26 AM, Jordan Crouse wrote: > On 07/01/2014 12:57 PM, Rob Clark wrote: >> >> diff --git a/Documentation/devicetree/bindings/drm/msm/gpu.txt >> b/Documentation/devicetree/bindings/drm/msm/gpu.txt >> new file mode 100644 >> index 000..6e33efe >> --- /dev/null >> +++

display put to sleep before init completes (& stays black)

Details reported in https://bugzilla.redhat.com/show_bug.cgi?id=1115241 Is this a DRI problem? -- The husband should fulfill his marital duty to his wife, and likewise the wife to her husband. 1 Corinthians 7:3 NIV VT

[PATCH 4/7] Exynos: add support for 'domain-always-on' property

Hello, On 2014-07-01 19:54, Tobias Jakobi wrote: > Marek Szyprowski wrote: >> On 2014-07-01 10:52, Tobias Jakobi wrote: >>> I think you had a similar patch in the tizen tree, but according to >>> Tomasz Figa, it was considered a hack. I don't quite see how this is >>> different. >>> >>> Also, if

[PATCH 4/4] ARM: tegra: roth: add display DT node

On 07/02/2014 06:19 AM, Alexandre Courbot wrote: > DSI support has been fixed to support continuous clock behavior that the > panel used on SHIELD requires, so finally add its device tree node since > it is functional. > diff --git a/arch/arm/boot/dts/tegra114-roth.dts >

[Bug 60523] Radeon DPM not working with 2 monitors attached to Radeon HD5770 (Juniper)

https://bugzilla.kernel.org/show_bug.cgi?id=60523 --- Comment #57 from Mathias Tillman --- No difference here either, unfortunately. -- You are receiving this mail because: You are watching the assignee of the bug.

[PATCH 2/2] drm/exynos: Remove unused variable in exynos_drm_gem.c

'exynos_gem_obj' is not used in the function. Remove it. Signed-off-by: Sachin Kamat --- drivers/gpu/drm/exynos/exynos_drm_gem.c |3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c b/drivers/gpu/drm/exynos/exynos_drm_gem.c index 163a054..15db801

[PATCH 1/2] drm/exynos: Remove unused variable from exynos_hdmi.c

'frame_size_code' is not used in the function. Remove it. Signed-off-by: Sachin Kamat --- drivers/gpu/drm/exynos/exynos_hdmi.c |3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c b/drivers/gpu/drm/exynos/exynos_hdmi.c index

[PATCH 1/2] drm/radeon: Program page flips to execute in hblank instead of vblank

On 02.07.2014 01:46, Dieter N?tzel wrote: > Am 01.07.2014 10:14, schrieb Michel D?nzer: >> From: Michel D?nzer >> >> But move the programming back to the vertical blank interrupt handler. >> And signal the flip as being completed immediately after programming it >> to the hardware. >> >> This way

[RFC][PATCH] gpu:drm:i915:intel_detect_pch: back to check devfn instead of check class type

On Thu, Jun 19, 2014 at 05:53:51PM +0800, Tiejun Chen wrote: > Originally the reason to probe ISA bridge instead of Dev31:Fun0 > is to make graphics device passthrough work easy for VMM, that > only need to expose ISA bridge to let driver know the real > hardware underneath. This is a requirement

[RFC] drm/msm: DT support for 8960/8064

On 07/01/2014 12:57 PM, Rob Clark wrote: > diff --git a/Documentation/devicetree/bindings/drm/msm/gpu.txt > b/Documentation/devicetree/bindings/drm/msm/gpu.txt > new file mode 100644 > index 000..6e33efe > --- /dev/null > +++ b/Documentation/devicetree/bindings/drm/msm/gpu.txt > @@ -0,0 +1,51

[PATCH 1/1] drm/vmwgfx: correct fb_fix_screeninfo.line_length

tachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140702/257bd30a/attachment.html>

[Bug 75241] radeon_compute_pll_avivo broken in 3.15-rc3

https://bugzilla.kernel.org/show_bug.cgi?id=75241 Dan Merillat changed: What|Removed |Added CC||bugzilla at dan.merillat.org --- Comment

[PATCH 1/1] drm/vmwgfx: correct fb_fix_screeninfo.line_length

On 07/02/2014 05:01 AM, Christopher Friedt wrote: > I have been unable to reproduce this issue in a plethora of test > cases, although granted, I do not have access to a Win7 machine. For > that, I have asked an Ubuntu tester to run through some tests for me. > >

[Bug 79850] [awesomenauts][radeonsi] pageflip is clearly missing vblank with vsync on

es described above are rasterized as two triangles each, which makes the tearing more noticeable. -- 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

[Bug 80141] Fails to page flip multiple time, queue overflows waiting for one to finish that never does crashing entire system.

-- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140702/2a0bbb7a/attachment.html>

[PATCH 1/2] drm/radeon: Program page flips to execute in hblank instead of vblank

Am 02.07.2014 02:29, schrieb Michel D?nzer: > On 02.07.2014 01:46, Dieter N?tzel wrote: >> Am 01.07.2014 10:14, schrieb Michel D?nzer: >>> From: Michel D?nzer >>> >>> But move the programming back to the vertical blank interrupt >>> handler. >>> And signal the flip as being completed

[Bug 64131] Radeon card stays in highest DPM power state on boot and after resume

https://bugzilla.kernel.org/show_bug.cgi?id=64131 Dieter N?tzel changed: What|Removed |Added CC||Dieter at nuetzel-hh.de --- Comment #1

[Bug 78661] GPU sometimes locks up after boot and/or resume

https://bugzilla.kernel.org/show_bug.cgi?id=78661 Dieter N?tzel changed: What|Removed |Added CC||Dieter at nuetzel-hh.de --- Comment #6

[Bug 60523] Radeon DPM not working with 2 monitors attached to Radeon HD5770 (Juniper)

https://bugzilla.kernel.org/show_bug.cgi?id=60523 --- Comment #56 from Tobias Droste --- No change here -- You are receiving this mail because: You are watching the assignee of the bug.

[Bug 78661] GPU sometimes locks up after boot and/or resume

https://bugzilla.kernel.org/show_bug.cgi?id=78661 --- Comment #5 from Nikolaus Waxweiler --- Created attachment 141821 --> https://bugzilla.kernel.org/attachment.cgi?id=141821=edit It happened again with radeon.dpm=0 and power_profile set to low. syslog since using radeon.dpm=0 on ther kernel

[PATCH 1/1] drm/vmwgfx: correct fb_fix_screeninfo.line_length

I have been unable to reproduce this issue in a plethora of test cases, although granted, I do not have access to a Win7 machine. For that, I have asked an Ubuntu tester to run through some tests for me. https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-vmware/+bug/1328898/comments/8