[ANNOUNCE] libdrm 2.4.46

> I certainly don't pull patches in from others to it very often, and > modetest I generally blame on jbarnes. > Speaking of forgotten patches, could someone with the commit access please pick up this one: http://lists.freedesktop.org/archives/dri-devel/2012-November/030852.html ATI DDX already

[ANNOUNCE] libdrm 2.4.46

Hi Dave, On Wednesday 03 July 2013 10:17:34 Dave Airlie wrote: > On Wed, Jul 3, 2013 at 9:55 AM, Laurent Pinchart wrote: > > On Tuesday 02 July 2013 18:22:01 Dave Airlie wrote: > >> -BEGIN PGP SIGNED MESSAGE- > >> Hash: SHA1 > >> > >> Release because I want the cursor ioctls released, >

[Bug 66349] Using SB shader optimization caused segfault in Serious Sam 3: BFE

rom it. -- 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/20130703/cf2a3cba/attachment.html>

Best practice device tree design for display subsystems/DRM

> -Original Message- > From: Sebastian Hesselbarth [mailto:sebastian.hesselbarth at gmail.com] > Sent: Wednesday, July 03, 2013 7:53 PM > To: Russell King > Cc: Inki Dae; 'Sascha Hauer'; 'Daniel Drake'; 'Jean-Francois Moine'; > devicetree-discuss at lists.ozlabs.org; dri-devel at

[Bug 66558] RS690: 3D artifacts when playing SuperTuxKart

-- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130703/540f7778/attachment.html>

[Bug 66558] RS690: 3D artifacts when playing SuperTuxKart

-- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130703/6c2b3a84/attachment.html>

[Bug 66349] Using SB shader optimization caused segfault in Serious Sam 3: BFE

bed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130703/45a39661/attachment-0001.html>

[Bug 66558] RS690: 3D artifacts when playing SuperTuxKart

ttp://lists.freedesktop.org/archives/dri-devel/attachments/20130703/a3f8bc8c/attachment.html>

[Bug 66558] RS690: 3D artifacts when playing SuperTuxKart

|| -- 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/20130703/baaeccde/attachment.html>

[Bug 66558] RS690: 3D artifacts when playing SuperTuxKart

art -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130703/d2365505/attachment.html>

[Bug 66558] RS690: 3D artifacts when playing SuperTuxKart

art -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130703/ed17b4d9/attachment.html>

[Bug 66558] New: RS690: 3D artifacts when playing SuperTuxKart

ent was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130703/47661c3e/attachment.html>

Best practice device tree design for display subsystems/DRM

On 07/03/13 13:32, Russell King wrote: > On Wed, Jul 03, 2013 at 12:52:37PM +0200, Sebastian Hesselbarth wrote: >> But honestly, I see no way around it and it is the only way >> to allow to even have the decision for one or two cards at all. >> There is no way for auto-probing the users

Best practice device tree design for display subsystems/DRM

> -Original Message- > From: Sebastian Hesselbarth [mailto:sebastian.hesselbarth at gmail.com] > Sent: Wednesday, July 03, 2013 6:09 PM > To: Sascha Hauer > Cc: Inki Dae; 'Daniel Drake'; 'Jean-Francois Moine'; devicetree- > discuss at lists.ozlabs.org; 'Russell King'; dri-devel at >

Best practice device tree design for display subsystems/DRM

> -Original Message- > From: dri-devel-bounces+inki.dae=samsung.com at lists.freedesktop.org > [mailto:dri-devel-bounces+inki.dae=samsung.com at lists.freedesktop.org] On > Behalf Of Sebastian Hesselbarth > Sent: Wednesday, July 03, 2013 6:41 AM > To: Daniel Drake > Cc: Jean-Francois

[pull] radeon drm-next-3.11

From: Alex Deucher Hi Dave, A few more DPM fixes. The following changes since commit 7982128c3d447df27db963af67bc6b8dc7efb1de: drm/radeon/dpm: add debugfs support for SI (2013-07-01 16:09:06 -0400) are available in the git repository at:

[PATCH 3/3] drm/exynos: remove duplicated error routine and unnecessary assign

There were duplicated error handling routines during allocating pages in lowlevel_buffer_allocate() and g2d_userptr_get_dma_addr(). Also unnecessary NULL assignments for variable used not any more are removed from g2d_userptr_get_dma_addr() and g2d_userptr_put_dma_addr(). Signed-off-by: Seung-Woo

[PATCH v2 2/3] drm/exynos: fix pages allocation size in lowlevel_buffer_allocate

From: YoungJun Cho When IOMMU is not supported, buf->pages has to be allocated to assign the result of phys_to_page() which return type is struct page *. So it is sufficient to allocate buf->pages with the size of multiple struct page pointers. Signed-off-by: YoungJun Cho

[PATCH 1/3] drm/exynos: use drm_calloc_large when allocates pointer array

From: YoungJun Cho If the type of object is pointer array, the drm_calloc_large() is more suitable than kzalloc() for its allocation function. And uses drm_free_large() instead of kfree() also. Signed-off-by: YoungJun Cho Signed-off-by: Seung-Woo Kim Signed-off-by:

Best practice device tree design for display subsystems/DRM

> -Original Message- > From: dri-devel-bounces+inki.dae=samsung.com at lists.freedesktop.org > [mailto:dri-devel-bounces+inki.dae=samsung.com at lists.freedesktop.org] On > Behalf Of Russell King > Sent: Wednesday, July 03, 2013 4:08 AM > To: Daniel Drake > Cc: Jean-Fran?ois Moine;

Best practice device tree design for display subsystems/DRM

> -Original Message- > From: dri-devel-bounces+inki.dae=samsung.com at lists.freedesktop.org > [mailto:dri-devel-bounces+inki.dae=samsung.com at lists.freedesktop.org] On > Behalf Of Stephane Marchesin > Sent: Wednesday, July 03, 2013 10:46 AM > To: Dave Airlie > Cc: Jean-Francois Moine;

[ANNOUNCE] libdrm 2.4.46

On Wed, Jul 3, 2013 at 3:20 PM, Laurent Pinchart wrote: > Hi Dave, > > On Wednesday 03 July 2013 10:17:34 Dave Airlie wrote: >> On Wed, Jul 3, 2013 at 9:55 AM, Laurent Pinchart wrote: >> > On Tuesday 02 July 2013 18:22:01 Dave Airlie wrote: >> >> -BEGIN PGP SIGNED MESSAGE- >> >> Hash:

MacBook Pro 10,1 + i915

Dear Chris Wilson, > On Wed, Jul 03, 2013 at 01:35:35PM +0200, Marek Vasut wrote: > > Hi Chris, > > > > > On Mon, Jul 01, 2013 at 10:39:14PM +0200, Marek Vasut wrote: > > > > Hi guys, > > > > > > > > I recently got the rMBP 10,1 model, it has two graphic cards: > > > > > > > > 00:02.0 VGA

[PATCH 6/6] drm: Optionally create mm blocks from top-to-bottom

From: Chris Wilson Clients like i915 needs to segregate cache domains within the GTT which can lead to small amounts of fragmentation. By allocating the uncached buffers from the bottom and the cacheable buffers from the top, we can reduce the amount of wasted space and

[PATCH 1/6] drm: pre allocate node for create_block

For an upcoming patch where we introduce the i915 VMA, it's ideal to have the drm_mm_node as part of the VMA struct (ie. it's pre-allocated). Part of the conversion to VMAs is to kill off obj->gtt_space. Doing this will break a bunch of code, but amongst them are 2 callers of

Best practice device tree design for display subsystems/DRM

Am Dienstag, den 02.07.2013, 18:46 -0700 schrieb St?phane Marchesin: > On Tue, Jul 2, 2013 at 3:02 PM, Dave Airlie wrote: > > On Wed, Jul 3, 2013 at 7:50 AM, Sascha Hauer > > wrote: > >> On Tue, Jul 02, 2013 at 09:25:48PM +0100, Russell King wrote: > >>> On Tue, Jul 02, 2013 at 09:57:32PM

[Bug 66473] hdmi oops with mem sleep

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/20130703/02a710d8/attachment.html>

[Bug 66551] New: System hang when DPM enabled on rs780.

. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130703/a41eef19/attachment-0001.html>

[Bug 66425] "failed testing IB on ring 5" when suspending to disk

ing around with the different soft reset methods, but I have my doubts that this will ever work correctly. -- 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/ar

Best practice device tree design for display subsystems/DRM

On 07/03/13 13:43, Inki Dae wrote: >> I do not understand why you keep referring to the SoC dtsi. Im my >> example, I said that it is made up and joined from both SoC dtsi and >> board dts. >> >> So, of course, lcd controller nodes and dcon are part of dove.dtsi >> because they are physically

MacBook Pro 10,1 + i915

On Wed, Jul 03, 2013 at 01:35:35PM +0200, Marek Vasut wrote: > Hi Chris, > > > On Mon, Jul 01, 2013 at 10:39:14PM +0200, Marek Vasut wrote: > > > Hi guys, > > > > > > I recently got the rMBP 10,1 model, it has two graphic cards: > > > > > > 00:02.0 VGA compatible controller: Intel Corporation

MacBook Pro 10,1 + i915

Hi Chris, > On Mon, Jul 01, 2013 at 10:39:14PM +0200, Marek Vasut wrote: > > Hi guys, > > > > I recently got the rMBP 10,1 model, it has two graphic cards: > > > > 00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core > > processor Graphics Controller (rev 09) > > 01:00.0 VGA

[Bug 66519] 3.10 kernel: [drm:evergreen_startup] *ERROR* radeon: error initializing UVD (-1).

K?nig --- Thanks for the info, closing it. -- 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/20130703/5492ebdf/attachment.html>

Best practice device tree design for display subsystems/DRM

On Wed, Jul 03, 2013 at 10:52:49AM +0100, Russell King wrote: > On Wed, Jul 03, 2013 at 11:02:42AM +0200, Sascha Hauer wrote: > > > > +1 for not encoding the projected usecase of the graphics subsystem into > > the devicetree. Whether the two LCD controllers shall be used together > > or

[PULL] drm-intel-fixes for 3.11

Hi Dave, Pile of fixes for 3.11. A bit large in patch count, but that's simply due to two fixes being split up into really small parts. Also I've included a few more vlv patches than I'd have included for other platforms. But since vlv is officially supported for the first time only in 3.11 that

[Bug 66519] 3.10 kernel: [drm:evergreen_startup] *ERROR* radeon: error initializing UVD (-1).

|--- |INVALID -- 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/20130703/affc9712/attachment.html>

[Bug 66519] 3.10 kernel: [drm:evergreen_startup] *ERROR* radeon: error initializing UVD (-1).

pable at 0x3C0FE035F000 [1.291695] [drm] vram apper at 0x3C0FE000 [1.291750] [drm] size 9216000 [1.291804] [drm] fb depth is 24 [1.291858] [drm]pitch is 7680 Thanks, Justin. -- 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/20130703/25f55753/attachment.html>

Best practice device tree design for display subsystems/DRM

On 07/03/13 11:52, Russell King wrote: > On Wed, Jul 03, 2013 at 11:02:42AM +0200, Sascha Hauer wrote: >> On Wed, Jul 03, 2013 at 05:57:18PM +0900, Inki Dae wrote: video { /* Single video card w/ multiple lcd controllers */ card0 { compatible =

Best practice device tree design for display subsystems/DRM

On Wed, Jul 03, 2013 at 08:43:20PM +0900, Inki Dae wrote: > In case of fbdev, framebuffer driver would use lcd0 or lcd1 driver, or lcd0 > and lcd1 drivers which are placed in drivers/video/backlight/. No, that's totally wrong. Framebuffer drivers are not backlights. Framebuffer drivers go in

Best practice device tree design for display subsystems/DRM

On 07/03/13 11:53, Russell King wrote: > On Wed, Jul 03, 2013 at 06:48:41PM +0900, Inki Dae wrote: >> That's not whether we can write device driver or not. dtsi is common spot in >> other subsystems. Do you think the cardX node is meaningful to other >> subsystems? > > Yes, because fbdev could

[Bug 64850] Second screen black on Pitcairn PRO

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

[patch] drm/nvc0/gr: remove duplicate break statements

There are two break statements in a row. Signed-off-by: Dan Carpenter diff --git a/drivers/gpu/drm/nouveau/core/engine/graph/ctxnvc0.c b/drivers/gpu/drm/nouveau/core/engine/graph/ctxnvc0.c index 3be7b95..f1c0767 100644 --- a/drivers/gpu/drm/nouveau/core/engine/graph/ctxnvc0.c +++

[Bug 66519] 3.10 kernel: [drm:evergreen_startup] *ERROR* radeon: error initializing UVD (-1).

the kernel. -- 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/20130703/0385d71c/attachment.html>

Best practice device tree design for display subsystems/DRM

On Wed, Jul 03, 2013 at 12:52:37PM +0200, Sebastian Hesselbarth wrote: > But honestly, I see no way around it and it is the only way > to allow to even have the decision for one or two cards at all. > There is no way for auto-probing the users intention... It's not _just_ about the users

[PATCH] drm/nouveau: bump fence timeout to 150 seconds

Fixes parallel piglit runs on fermi with boot clock speeds. Signed-off-by: Maarten Lankhorst --- diff --git a/drivers/gpu/drm/nouveau/nouveau_fence.c b/drivers/gpu/drm/nouveau/nouveau_fence.c index 1e753b0..460dd00 100644 --- a/drivers/gpu/drm/nouveau/nouveau_fence.c +++

[PATCH] drm/exynos: add error check routine in exynos_drm_open

Nice catch!!!. Applied. Thanks, Inki Dae 2013/7/1 Seung-Woo Kim : > From: YoungJun Cho > > When the exynos_drm_subdrv_open() returns error, the file_priv > should be released and file->driver_priv set to NULL. > > Signed-off-by: YoungJun Cho > Signed-off-by: Kyungmin Park > --- >

[PATCH 2/2] drm/exynos: initialize the buf_num in vp_video_buffer

Applied. Thanks, Inki Dae 2013/7/1 Seung-Woo Kim : > From: YoungJun Cho > > The buf_num in vp_video_buffer() should be 1 or 2, but it is not > initialized, and only set to 2 in NV12M or NV12MT cases. > So this patch initializes the buf_num with 1 as default. > > Signed-off-by: YoungJun Cho >

[PATCH 1/2] drm/exynos: remove dead code in vidi_power_on

Applied. Thanks, Inki Dae 2013/7/1 Seung-Woo Kim : > From: YoungJun Cho > > The type of input parameter enable is bool, so it does not need > to check whether true or false. > > Signed-off-by: YoungJun Cho > Signed-off-by: Kyungmin Park > --- > drivers/gpu/drm/exynos/exynos_drm_vidi.c |3

[PATCH] drm/exynos: fix not to remain exynos_gem_obj as a leak

Applied. Thanks, Inki Dae 2013/7/1 Seung-Woo Kim : > From: YoungJun Cho > > The exynos_drm_gem_create() only calls drm_gem_object_release() > when exynos_drm_alloc_buf() is failed, and exynos_gem_obj remains > as a leak, which is allocated in exynos_drm_gem_init(). > So this patch fixes it not

Best practice device tree design for display subsystems/DRM

On 07/03/13 11:02, Sascha Hauer wrote: > On Wed, Jul 03, 2013 at 05:57:18PM +0900, Inki Dae wrote: >>> video { >>> /* Single video card w/ multiple lcd controllers */ >>> card0 { >>> compatible = "marvell,armada-510-display"; >>> reg = <0 0x3f00 0x100>; /*

Best practice device tree design for display subsystems/DRM

On Wed, Jul 03, 2013 at 05:57:18PM +0900, Inki Dae wrote: > > video { > > /* Single video card w/ multiple lcd controllers */ > > card0 { > > compatible = "marvell,armada-510-display"; > > reg = <0 0x3f00 0x100>; /* video-mem hole */ > > /*

Best practice device tree design for display subsystems/DRM

On Wed, Jul 03, 2013 at 06:48:41PM +0900, Inki Dae wrote: > That's not whether we can write device driver or not. dtsi is common spot in > other subsystems. Do you think the cardX node is meaningful to other > subsystems? Yes, because fbdev could also use it to solve the same problem which we're

Best practice device tree design for display subsystems/DRM

On Wed, Jul 03, 2013 at 11:02:42AM +0200, Sascha Hauer wrote: > On Wed, Jul 03, 2013 at 05:57:18PM +0900, Inki Dae wrote: > > > video { > > > /* Single video card w/ multiple lcd controllers */ > > > card0 { > > > compatible = "marvell,armada-510-display"; > > > reg = <0

[Bug 66519] 3.10 kernel: [drm:evergreen_startup] *ERROR* radeon: error initializing UVD (-1).

art -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130703/11ff26a9/attachment.html>

[Bug 66519] 3.10 kernel: [drm:evergreen_startup] *ERROR* radeon: error initializing UVD (-1).

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/20130703/470cf6f5/attachment.html>

Best practice device tree design for display subsystems/DRM

On 07/03/13 08:55, Sascha Hauer wrote: > On Wed, Jul 03, 2013 at 08:02:05AM +1000, Dave Airlie wrote: >> Have you also considered how suspend/resume works in such a place, >> where every driver is independent? The ChromeOS guys have bitched >> before about the exynos driver which is has lots of

"radeon: error initializing UVD" in kernel 3.10 on hybrid laptop with CEDAR / R600 [Solved]

Alex Deucher wrote, on 07/03/2013 00:49: > On Tue, Jul 2, 2013 at 4:34 PM, J?rg-Volker Peetz wrote: >> Alex Deucher wrote, on 07/02/2013 22:17: >>> On Tue, Jul 2, 2013 at 4:15 PM, J?rg-Volker Peetz wrote: Alex Deucher wrote, on 07/02/2013 21:46: > On Tue, Jul 2, 2013 at 10:09 AM,

[ANNOUNCE] libdrm 2.4.46

On Wed, Jul 3, 2013 at 9:55 AM, Laurent Pinchart wrote: > Hi Dave, > > On Tuesday 02 July 2013 18:22:01 Dave Airlie wrote: >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> Release because I want the cursor ioctls released, >> also haswell and radeon ids. > > Any chance to get the "[PATCH

Best practice device tree design for display subsystems/DRM

On Tue, Jul 02, 2013 at 11:14:45PM +0100, Russell King wrote: > On Wed, Jul 03, 2013 at 08:02:05AM +1000, Dave Airlie wrote: > > Have you also considered how suspend/resume works in such a place, > > where every driver is independent? The ChromeOS guys have bitched > > before about the exynos

[pull] radeon drm-next-3.11

On Wed, Jul 3, 2013 at 2:39 AM, Ruslan N. Marchenko wrote: > Am 01.07.2013 23:01, schrieb alexdeucher at gmail.com: >> >> From: Alex Deucher >> >> Hi Dave, >> >> A few more patches for 3.11: >> - add debugfs interface to check current DPM state >> - Fix a bug that caused problems with DPM on

3.10 kernel: [drm:evergreen_startup] *ERROR* radeon: error initializing UVD (-1). [SOLVED]

-Original Message- From: Alex Deucher [mailto:alexdeuc...@gmail.com] Sent: Tuesday, July 02, 2013 3:41 PM To: Justin Piszcz Cc: linux-kernel at vger.kernel.org; dri-devel at lists.freedesktop.org Subject: Re: 3.10 kernel: [drm:evergreen_startup] *ERROR* radeon: error initializing UVD

"radeon: error initializing UVD" in kernel 3.10 on hybrid laptop with CEDAR / R600 [Solved]

Alex Deucher wrote, on 07/03/2013 00:49: > On Tue, Jul 2, 2013 at 4:34 PM, J?rg-Volker Peetz wrote: >> Alex Deucher wrote, on 07/02/2013 22:17: >>> On Tue, Jul 2, 2013 at 4:15 PM, J?rg-Volker Peetz wrote: Alex Deucher wrote, on 07/02/2013 21:46: > On Tue, Jul 2, 2013 at 10:09 AM,

[PATCH] drm/exynos: fix pages allocation in lowlevel_buffer_allocate

gt; >> > >> -- > >> Ville Syrj?l? > >> Intel OTC > >> ___ > >> dri-devel mailing list > >> dri-devel at lists.freedesktop.org > >> http://lists.freedesktop.org/mailman/listinfo/dri-devel > > > > > > ___ > > dri-devel mailing list > > dri-devel at lists.freedesktop.org > > http://lists.freedesktop.org/mailman/listinfo/dri-devel > > > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130703/a130c657/attachment-0001.html>

"radeon: error initializing UVD" in kernel 3.10 on hybrid laptop with CEDAR / R600 [Solved]

On Wed, Jul 3, 2013 at 3:14 AM, J?rg-Volker Peetz wrote: > Alex Deucher wrote, on 07/03/2013 00:49: >> On Tue, Jul 2, 2013 at 4:34 PM, J?rg-Volker Peetz wrote: >>> Alex Deucher wrote, on 07/02/2013 22:17: On Tue, Jul 2, 2013 at 4:15 PM, J?rg-Volker Peetz wrote: > Alex Deucher

MacBook Pro 10,1 + i915

On Mon, Jul 01, 2013 at 10:39:14PM +0200, Marek Vasut wrote: > Hi guys, > > I recently got the rMBP 10,1 model, it has two graphic cards: > > 00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core processor > Graphics Controller (rev 09) > 01:00.0 VGA compatible controller: NVIDIA

Best practice device tree design for display subsystems/DRM

On Wed, Jul 03, 2013 at 08:02:05AM +1000, Dave Airlie wrote: > On Wed, Jul 3, 2013 at 7:50 AM, Sascha Hauer > wrote: > > On Tue, Jul 02, 2013 at 09:25:48PM +0100, Russell King wrote: > >> On Tue, Jul 02, 2013 at 09:57:32PM +0200, Sebastian Hesselbarth wrote: > >> > I am against a super node

[pull] radeon drm-next-3.11

Am 01.07.2013 23:01, schrieb alexdeucher at gmail.com: > From: Alex Deucher > > Hi Dave, > > A few more patches for 3.11: > - add debugfs interface to check current DPM state > - Fix a bug that caused problems with DPM on BTC+ asics. > > The following changes since commit

[Bug 66519] 3.10 kernel: [drm:evergreen_startup] *ERROR* radeon: error initializing UVD (-1).

--- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130703/42ab302f/attachment.html>

[Bug 66519] 3.10 kernel: [drm:evergreen_startup] *ERROR* radeon: error initializing UVD (-1).

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/20130703/6f78c822/attachment.html>

Best practice device tree design for display subsystems/DRM

On Wed, Jul 3, 2013 at 7:50 AM, Sascha Hauer wrote: > On Tue, Jul 02, 2013 at 09:25:48PM +0100, Russell King wrote: >> On Tue, Jul 02, 2013 at 09:57:32PM +0200, Sebastian Hesselbarth wrote: >> > I am against a super node which contains lcd and dcon/ire nodes. You can >> > enable those devices on

[Bug 66425] "failed testing IB on ring 5" when suspending to disk

.org/archives/dri-devel/attachments/20130703/11d9d10a/attachment.html>

[PATCH] drm/nva3/disp: Fix HDMI audio regression

This is the nva3 counterpart to commit beba44b17 (drm/nv84/disp: Fix HDMI audio regression). The regression happened as a result of refactoring in commit 8e9e3d2de (drm/nv84/disp: move hdmi control into core). Reported-and-tested-by: Max Baldwin Signed-off-by: Ilia Mirkin --- The actual

[PATCH 0/6] DRM: Unified VMA Offset Manager

Hi David, On Monday 01 July 2013 20:32:57 David Herrmann wrote: > Hi > > I picked up the initial work from Dave [1], fixed several bugs, rewrote the > drm_mm node handling and adjusted the different drivers. > The series tries to replace the VMA-offset managers from GEM and TTM with a > single

[ANNOUNCE] libdrm 2.4.46

Hi Dave, On Tuesday 02 July 2013 18:22:01 Dave Airlie wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Release because I want the cursor ioctls released, > also haswell and radeon ids. Any chance to get the "[PATCH v6 00/23] modetest enhancements" series included in the next

Best practice device tree design for display subsystems/DRM

On Tue, Jul 02, 2013 at 09:25:48PM +0100, Russell King wrote: > On Tue, Jul 02, 2013 at 09:57:32PM +0200, Sebastian Hesselbarth wrote: > > I am against a super node which contains lcd and dcon/ire nodes. You can > > enable those devices on a per board basis. We add them to dove.dtsi but > >

Best practice device tree design for display subsystems/DRM

On 07/02/2013 11:04 PM, Daniel Drake wrote: > On Tue, Jul 2, 2013 at 1:57 PM, Sebastian Hesselbarth > wrote: >> I am against a super node which contains lcd and dcon/ire nodes. You can >> enable those devices on a per board basis. We add them to dove.dtsi but >> disable them by default (status =

Best practice device tree design for display subsystems/DRM

On Wed, Jul 03, 2013 at 08:02:05AM +1000, Dave Airlie wrote: > Have you also considered how suspend/resume works in such a place, > where every driver is independent? The ChromeOS guys have bitched > before about the exynos driver which is has lots of sub-drivers, how > do you control the s/r

RE: Best practice device tree design for display subsystems/DRM

-Original Message- From: dri-devel-bounces+inki.dae=samsung@lists.freedesktop.org [mailto:dri-devel-bounces+inki.dae=samsung@lists.freedesktop.org] On Behalf Of Stephane Marchesin Sent: Wednesday, July 03, 2013 10:46 AM To: Dave Airlie Cc: Jean-Francois Moine; Daniel

Re: [pull] radeon drm-next-3.11

Am 01.07.2013 23:01, schrieb alexdeuc...@gmail.com: From: Alex Deucheralexander.deuc...@amd.com Hi Dave, A few more patches for 3.11: - add debugfs interface to check current DPM state - Fix a bug that caused problems with DPM on BTC+ asics. The following changes since commit

Re: Best practice device tree design for display subsystems/DRM

On Wed, Jul 03, 2013 at 08:02:05AM +1000, Dave Airlie wrote: On Wed, Jul 3, 2013 at 7:50 AM, Sascha Hauer s.ha...@pengutronix.de wrote: On Tue, Jul 02, 2013 at 09:25:48PM +0100, Russell King wrote: On Tue, Jul 02, 2013 at 09:57:32PM +0200, Sebastian Hesselbarth wrote: I am against a super

[PATCH] drm/nva3/disp: Fix HDMI audio regression

This is the nva3 counterpart to commit beba44b17 (drm/nv84/disp: Fix HDMI audio regression). The regression happened as a result of refactoring in commit 8e9e3d2de (drm/nv84/disp: move hdmi control into core). Reported-and-tested-by: Max Baldwin archerse...@gmail.com Signed-off-by: Ilia Mirkin

[PATCH] drm/exynos: Add missing includes

From: Mark Brown broo...@linaro.org Ensure that all externally accessed functions are correctly prototyped when defined in each file by making sure the headers with the protoypes are included in the file with the definition. Signed-off-by: Mark Brown broo...@linaro.org ---

[PATCH] drm: Convert drm class driver from legacy pm ops to dev_pm_ops

Convert drivers/gpu/drm class to use dev_pm_ops for power management and remove Legacy PM ops hooks. With this change, drm class registers suspend/resume callbacks via class-pm (dev_pm_ops) instead of Legacy class-suspend/resume. When __device_suspend() runs call-backs, it will find class-pm ops

armada_drm clock selection - try 2

Hi Russell, Here is a new patch which should incorporate all your previous feedback. Now each variant passes clock info to the main driver via a new armada_clk_info structure. A helper function in the core lets each variant find the best clock. As you suggested we first try external (dedicated)

MacBook Pro 10,1 + i915

Hi guys, I recently got the rMBP 10,1 model, it has two graphic cards: 00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core processor Graphics Controller (rev 09) 01:00.0 VGA compatible controller: NVIDIA Corporation GK107M [GeForce GT 650M Mac Edition] (rev a1) I'm running linux

Re: armada_drm clock selection - try 2

On 07/01/2013 10:30 PM, Daniel Drake wrote: Here is a new patch which should incorporate all your previous feedback. Now each variant passes clock info to the main driver via a new armada_clk_info structure. A helper function in the core lets each variant find the best clock. As you suggested

Re: [PATCH RFC 1/3] DRM: Armada: Add Armada DRM driver

On 07/01/2013 11:55 PM, Rob Clark wrote: On Mon, Jul 1, 2013 at 4:52 AM, Sebastian Hesselbarth sebastian.hesselba...@gmail.com wrote: - TDA998x irq handling - ignored - TDA998x sync fix - ignored At least the sync fix, looks like I missed it (it probably is a good idea to CC me if you want

Re: armada_drm clock selection - try 2

On Mon, Jul 1, 2013 at 3:48 PM, Sebastian Hesselbarth sebastian.hesselba...@gmail.com wrote: I guess extclk0 and extclk1 should be sufficient for clock names. Also, they are not dedicated as you can have CRTC0 and CRTC1 use e.g. extclk0 simultaneously. See below for .is_dedicated in general.

Re: linux-next: Tree for Jul 1 [ drm-intel-next: Several call-traces ]

On Mon, Jul 1, 2013 at 11:03 AM, Sedat Dilek sedat.di...@gmail.com wrote: On Mon, Jul 1, 2013 at 10:52 AM, Daniel Vetter daniel.vet...@ffwll.ch wrote: On Mon, Jul 1, 2013 at 10:49 AM, Sedat Dilek sedat.di...@gmail.com wrote: On Mon, Jul 1, 2013 at 9:59 AM, Stephen Rothwell s...@canb.auug.org.au

Re: RADEON / DPM: GPU cannot properly up-clock

2013/6/28 Joshua C. joshua...@gmail.com: 2013/6/27 Alex Deucher alexdeuc...@gmail.com: On Wed, Jun 26, 2013 at 4:57 PM, Joshua C. joshua...@gmail.com wrote: 2013/6/26 Deucher, Alexander alexander.deuc...@amd.com: -Original Message- From: Joshua C. [mailto:joshua...@gmail.com] Sent:

Re: armada_drm clock selection - try 2

On 07/02/13 03:57, Daniel Drake wrote: On Mon, Jul 1, 2013 at 3:48 PM, Sebastian Hesselbarth sebastian.hesselba...@gmail.com wrote: I prefer not to try to find the best clock (source) at all. Let the user pass the clock name by e.g. platform_data (or DT) and just try to get the requested pixclk

Re: [PATCH] drm/exynos: Add missing includes

On Tue, Jul 02, 2013 at 09:21:32PM +0900, Inki Dae wrote: Ensure that all externally accessed functions are correctly prototyped when defined in each file by making sure the headers with the protoypes are included in the file with the definition. I don't see why this patch is needed. it

PCI device IDs for device needing the i915 invert_brightness quirk

Dear all, Recently I've come across this article about a probable fix for my laptop's black screen on boot: http://people.skolelinux.org/pere/blog/Fixing_the_Linux_black_screen_of_death_on_machines_with_Intel_HD_video.html I've tried the fix and it works perfectly so I'm contacting you as

Best practice device tree design for display subsystems/DRM

Hi, I'm looking into implementing devicetree support in armada_drm and would like to better understand the best practice here. Adding DT support for a DRM driver seems to be complicated by the fact that DRM is not hotpluggable - it is not possible for the drm_device to be initialised without an

Re: [PATCH RFC 1/3] DRM: Armada: Add Armada DRM driver

On Tue, Jul 02, 2013 at 09:01:55PM +0300, Ville Syrjälä wrote: On Sun, Jun 30, 2013 at 07:29:27PM +0200, Daniel Vetter wrote: On Sun, Jun 30, 2013 at 2:52 PM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: | Default Colorimetry | | ... | | 480p, 480i, 576p, 576i, 240p

Re: Best practice device tree design for display subsystems/DRM

On Tue, 2 Jul 2013 11:43:59 -0600 Daniel Drake d...@laptop.org wrote: Hi, Hi Daniel, I'm looking into implementing devicetree support in armada_drm and would like to better understand the best practice here. Adding DT support for a DRM driver seems to be complicated by the fact that DRM

Re: Best practice device tree design for display subsystems/DRM

On Tue, Jul 02, 2013 at 11:43:59AM -0600, Daniel Drake wrote: exynos seems to take a the same approach. Components are separate in the device tree, and each component is implemented as a platform driver or i2c driver. However all the drivers are built together in the same module, and the

Re: Best practice device tree design for display subsystems/DRM

On Tue, Jul 2, 2013 at 12:43 PM, Russell King r...@arm.linux.org.uk wrote: I will point out that relying on driver probing orders has already been stated by driver model people to be unsafe. This is why I will not adopt such a solution for my driver; it is a bad design. Just to clarify, what

Re: Best practice device tree design for display subsystems/DRM

On Tue, Jul 02, 2013 at 12:54:41PM -0600, Daniel Drake wrote: On Tue, Jul 2, 2013 at 12:43 PM, Russell King r...@arm.linux.org.uk wrote: I will point out that relying on driver probing orders has already been stated by driver model people to be unsafe. This is why I will not adopt such a

Re: Best practice device tree design for display subsystems/DRM

On Tue, Jul 02, 2013 at 08:42:55PM +0200, Jean-Francois Moine wrote: It seems that you did not look at the NVIDIA Tegra driver (I got its general concept for my own driver, but I used a simple atomic counter): - at probe time, the main driver (drivers/gpu/host1x/drm/drm.c) scans the DT and

  1   2   >