[PATCH] [v3] drm: pre allocate node for create_block

Hi On Thu, Jul 4, 2013 at 10:14 PM, Ben Widawsky wrote: > 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

[Bug 60510] AMD Mobility Radeon HD4650 Screen Corruption with DPM

https://bugzilla.kernel.org/show_bug.cgi?id=60510 --- Comment #4 from Wong Yong Jie --- Created attachment 106795 --> https://bugzilla.kernel.org/attachment.cgi?id=106795=edit Video BIOS -- You are receiving this mail because: You are watching the assignee of the bug.

[Bug 60510] AMD Mobility Radeon HD4650 Screen Corruption with DPM

https://bugzilla.kernel.org/show_bug.cgi?id=60510 --- Comment #3 from Wong Yong Jie --- Created attachment 106794 --> https://bugzilla.kernel.org/attachment.cgi?id=106794=edit glxinfo -- You are receiving this mail because: You are watching the assignee of the bug.

[Bug 60510] AMD Mobility Radeon HD4650 Screen Corruption with DPM

https://bugzilla.kernel.org/show_bug.cgi?id=60510 --- Comment #2 from Wong Yong Jie --- Created attachment 106793 --> https://bugzilla.kernel.org/attachment.cgi?id=106793=edit lspci -- You are receiving this mail because: You are watching the assignee of the bug.

[Bug 60510] AMD Mobility Radeon HD4650 Screen Corruption with DPM

https://bugzilla.kernel.org/show_bug.cgi?id=60510 --- Comment #1 from Wong Yong Jie --- Created attachment 106792 --> https://bugzilla.kernel.org/attachment.cgi?id=106792=edit dmesg -- You are receiving this mail because: You are watching the assignee of the bug.

[Bug 60510] New: AMD Mobility Radeon HD4650 Screen Corruption with DPM

https://bugzilla.kernel.org/show_bug.cgi?id=60510 Bug ID: 60510 Summary: AMD Mobility Radeon HD4650 Screen Corruption with DPM Product: Drivers Version: 2.5 Kernel Version: 3.10.0-drm-next-20130705 Hardware: All OS: Linux

[PATCH] drm/exynos: exynos_drm_ipp: fix return value check

From: Wei Yongjun In case of error, the function ipp_find_obj() returns ERR_PTR() and never returns NULL. The NULL test in the return value check should be replaced with IS_ERR(). Signed-off-by: Wei Yongjun --- drivers/gpu/drm/exynos/exynos_drm_ipp.c | 12

Best practice device tree design for display subsystems/DRM

On Thu, Jul 4, 2013 at 5:28 PM, Dave Airlie wrote: > > ... Sorry but I'd like to say that this cannot be used commonly. Shouldn't you really consider Linux framebuffer or other subsystems? The above dtsi file is specific to DRM subsystem. And I think the dtsi file has

[PATCH] via: New TTM/GEM ioctls to support.

Add new TTM/GEM ioctls to be able to manage buffer regions from different domains. Included in the new ioctls is the ability to query hardware information. Signed-Off-by: James Simmons --- include/uapi/drm/via_drm.h | 115 1 file changed, 95

[PATCH 2/2] drm/rcar-du: Fix buffer pitch alignment

The DU requires a 16 pixels pitch alignement. Make sure dumb buffers are allocated with the correct pitch, and validate the pitch when creating frame buffers. Signed-off-by: Laurent Pinchart --- drivers/gpu/drm/rcar-du/rcar_du_drv.c | 2 +-

[PATCH 1/2] drm/rcar-du: Don't ignore rcar_du_crtc_create() return value

Handle error cases correctly. Signed-off-by: Laurent Pinchart --- drivers/gpu/drm/rcar-du/rcar_du_kms.c | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c

[PATCH 0/2] R-Car DU DRM fixes for v3.11

Hello, Here are two small fixes to the R-Car DU DRM driver. They have previously been posted as part of the larger "R-Car DU DRM support for R8A7790" series, and Daniel Vetter rightfully noticed that they should be applied to v3.11. Laurent Pinchart (2): drm/rcar-du: Don't ignore

[Bug 63599] [r600][r600] GPU lockup CP stall (kernel 3.2.47, 3.4, 3.8, 3.9)

attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130704/145a0ebe/attachment.html>

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

because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130704/83a36dc2/attachment.html>

[Bug 66452] JUNIPER UVD accelerated playback of WMV3 streams does not work

|Drivers/Gallium/r600 -- 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/20130704/186ea491/attachment.html>

[Bug 66450] JUNIPER UVD accelerated playback of MPEG 1/2 streams does not work

|Drivers/Gallium/r600 -- 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/20130704/0915d9ba/attachment.html>

Best practice device tree design for display subsystems/DRM

> -Original Message- > From: Sebastian Hesselbarth [mailto:sebastian.hesselbarth at gmail.com] > Sent: Thursday, July 04, 2013 4:25 PM > To: Inki Dae > Cc: 'Jean-Francois Moine'; 'Daniel Drake'; devicetree- > discuss at lists.ozlabs.org; dri-devel at lists.freedesktop.org; 'Sascha >

[Bug 64503] audio glitches when running at 24hz/24p

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/20130704/6c311c9b/attachment.html>

[GIT PULL v2] exynos-drm-next

Hi Dave, This is final pull request for 3.11. This resolves some memory leak issues, and includes some code and dt document file cleanups; just removed unnecessary descriptions. And the patch work for enhancing hdmiphy driver isn't in progress so this patch may go to 3.12. Please

[PATCH RESEND] drm/prime: fix sgt NULL checking

The drm_gem_map_detach() can be called with sgt is NULL. Signed-off-by: Joonyoung Shim --- drivers/gpu/drm/drm_prime.c | 11 ++- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c index 1e0de41..ff5fece 100644 ---

[PATCH] drm/prime: fix sgt NULL checking

The drm_gem_map_detach() can be called with sgt is NULL. Change-Id: I3b2f5878dfac6e1e77aebeeb7be781113dec59a7 Signed-off-by: Joonyoung Shim --- drivers/gpu/drm/drm_prime.c | 11 ++- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/drm_prime.c

[Bug 64850] Second screen black on Pitcairn PRO

are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130704/805e9f78/attachment.html>

[PATCH v2 0/3] drm/cma: use prime helpers instead GEM CMA specific dma_buf functionality

On 07/04/2013 07:11 AM, Laurent Pinchart wrote: > Hi Joonyoung, > > Thank you for the patches. > > On Friday 28 June 2013 14:24:43 Joonyoung Shim wrote: >> Hello, >> >> This is the second version patchset. >> >> GEM CMA supports dma_buf but it needs GEM CMA specific functionality for >> dma_buf.

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 8:52 PM > To: Inki Dae > Cc: 'Russell King'; devicetree-discuss at lists.ozlabs.org; 'Jean-Francois > Moine'; 'Sascha Hauer'; 'Daniel Drake'; dri-devel at

[PATCH 4/4] drm/radeon: separate UVD code

From: Christian K?nig Our different hardware blocks are actually completely separated, so it doesn't make much sense any more to structure the code by pure chipset generations. Signed-off-by: Christian K?nig --- drivers/gpu/drm/radeon/Makefile | 12 +-

[PATCH 3/4] drm/radeon: remove special handling for the DMA ring

From: Christian K?nig Now that we have callbacks for [rw]ptr handling we can remove the special handling for the DMA rings and use the callbacks instead. Signed-off-by: Christian K?nig --- drivers/gpu/drm/radeon/cik.c | 20 ++-

[PATCH 2/4] drm/radeon: rework UVD writeback & [rw]ptr handling

From: Christian K?nig The hardware just doesn't support this correctly. Disable it before we accidentally write anywhere we shouldn't. Signed-off-by: Christian K?nig --- drivers/gpu/drm/radeon/cik.c |3 +-- drivers/gpu/drm/radeon/evergreen.c |3 +--

[PATCH 1/4] drm/radeon: rework ring function handling

From: Christian K?nig Give the ring functions a separate structure and let the asic structure point to the ring specific functions. This simplifies the code and allows us to make changes at only point. No change in functionality. Signed-off-by: Christian K?nig ---

[PATCH 0/4] drm/radeon: code restructuring

Hi everybody, for quite some time we have the idea of restructuring the kernel driver code to actually better reflect the different hardware blocks and also the different generations of them. The following patchset starts this task by separating out the UVD block into files for different UVD

[PATCH v2 14/14] drm/radeon: use new drm_kick_out_firmware()

Kick out firmware DRM and fbdev drivers via the new drm_kick_out_firmware() before loading radeon. Signed-off-by: David Herrmann --- drivers/gpu/drm/radeon/radeon_drv.c | 28 drivers/gpu/drm/radeon/radeon_kms.c | 30 ++ 2 files changed,

[PATCH v2 13/14] drm/i915: use new drm_kick_out_firmware()

Use the new DRM infrastructure to kick out firmware DRM drivers before loading i915. Signed-off-by: David Herrmann --- drivers/gpu/drm/i915/i915_dma.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c

[PATCH v2 12/14] drm: nouveau: kick out firmware drivers during probe

Use the new DRM infrastructure to kick out firmware drivers before probing the real driver. Signed-off-by: David Herrmann --- drivers/gpu/drm/nouveau/nouveau_drm.c | 29 ++--- 1 file changed, 22 insertions(+), 7 deletions(-) diff --git

[PATCH v2 11/14] drm: add helpers to kick out firmware drivers

If we load a real hardware DRM driver, we want all firmware drivers to be unloaded. Historically, this was done via remove_conflicting_framebuffers(), but for DRM drivers (like SimpleDRM) we need a new way. This patch introduces DRIVER_FIRMWARE and DRM apertures to provide a quite similar way to

[PATCH v2 10/14] drm: simpledrm: add fbdev fallback support

Create a simple fbdev device during SimpleDRM setup so legacy user-space and fbcon can use it. Signed-off-by: David Herrmann --- drivers/gpu/drm/simpledrm/Kconfig | 11 ++ drivers/gpu/drm/simpledrm/Makefile | 1 + drivers/gpu/drm/simpledrm/simpledrm.h | 22

[PATCH v2 09/14] drm: add SimpleDRM driver

The SimpleDRM driver binds to simple-framebuffer devices and provides a DRM/KMS API. It provides only a single CRTC+encoder+connector combination plus one initial mode. Userspace can create one dumb-buffer and attach it to the CRTC. Only if the buffer is destroyed, a new buffer can be created.

[PATCH v2 08/14] fbdev: fbcon: select VT_HW_CONSOLE_BINDING

fbdev provides framebuffer hotplugging, hence, we need to allow fbcon to unbind from framebuffers. Unfortunately, fbcon_fb_unbind() cannot unbind from the last framebuffer, unless console-unbinding is supported. Fixing fbcon_unbind() to return 0 caused some horrible NULL-derefs in the VT layer

[PATCH v2 07/14] fbdev: efifb: bind to efi-framebuffer

Instead of creating a dummy device, we now bind to the efi-fb device which is provided by x86 initialization code. Signed-off-by: David Herrmann --- drivers/video/efifb.c | 68 +-- 1 file changed, 22 insertions(+), 46 deletions(-) diff --git

[PATCH v2 06/14] fbdev: vesafb: bind to platform-framebuffer device

x86 creates platform-framebuffer platform devices for every system framebuffer. Use these instead of creating a dummy device. This requires us to remove the __init annotations as hotplugging may occur during runtime. Signed-off-by: David Herrmann --- drivers/video/vesafb.c | 55

[PATCH v2 05/14] fbdev: simplefb: add 32bit RGB formats

32bit XRGB and ARGB are used by modern x86 systems for EFI and VESA framebuffers. Add both variants so simplefb can be used on such systems. Signed-off-by: David Herrmann --- include/linux/platform_data/simplefb.h | 2 ++ 1 file changed, 2 insertions(+) diff --git

[PATCH v2 04/14] x86: sysfb: move EFI quirks from efifb to sysfb

The EFI FB quirks from efifb.c are useful for simple-framebuffer devices as well. Apply them by default so we can convert efifb.c to use efi-framebuffer platform devices. Signed-off-by: David Herrmann --- arch/x86/include/asm/sysfb.h | 57 +++ arch/x86/kernel/Makefile | 1 +

[PATCH v2 03/14] x86: provide platform-devices for boot-framebuffers

The current situation regarding boot-framebuffers (VGA, VESA/VBE, EFI) on x86 causes troubles when loading multiple fbdev drivers. The global "struct screen_info" does not provide any state-tracking about which drivers use the FBs. request_mem_region() theoretically works, but unfortunately

[PATCH v2 02/14] fbdev: simplefb: mark as fw and allocate apertures

fbdev-core uses FBINFO_MISC_FIRMWARE to mark drivers that use firmware framebuffers. Furthermore, we now allocate apertures for the fbinfo device. Both information is used by remove_conflicting_framebuffers() to remove a fbdev device whenever a real driver is loaded. This is used heavily on x86

[PATCH v2 01/14] fbdev: simplefb: add init through platform_data

If we create proper platform-devices in x86 boot-code, we can use simplefb for VBE or EFI framebuffers, too. However, there is normally no OF support so we introduce a platform_data object so x86 boot-code can pass the parameters via plain old platform-data. This also removes the OF dependency as

[PATCH v2 00/14] Platform Framebuffers and SimpleDRM

Hi This series changes the way we handle firmware framebuffers on x86 systems. On other architectures the recently introduced "simple-framebuffer" platform-devices provide a sane and proper way to handle firmware framebuffers. So why not use it on x86, too? This series adds x86 setup code to

[PATCH] [v3] 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

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

On Thu, Jul 04, 2013 at 11:19:58AM +0200, David Herrmann wrote: > Hi > > On Wed, Jul 3, 2013 at 11:45 PM, Ben Widawsky wrote: > > 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

Best practice device tree design for display subsystems/DRM

On 07/04/13 12:09, Sascha Hauer wrote: > On Thu, Jul 04, 2013 at 11:44:41AM +0200, Sebastian Hesselbarth wrote: >> On 07/04/13 11:30, Sascha Hauer wrote: >>> On Thu, Jul 04, 2013 at 10:11:31AM +0100, Russell King wrote: On Thu, Jul 04, 2013 at 10:58:17AM +0200, Sascha Hauer wrote: > On

Best practice device tree design for display subsystems/DRM

On Thu, Jul 04, 2013 at 11:44:41AM +0200, Sebastian Hesselbarth wrote: > On 07/04/13 11:30, Sascha Hauer wrote: > >On Thu, Jul 04, 2013 at 10:11:31AM +0100, Russell King wrote: > >>On Thu, Jul 04, 2013 at 10:58:17AM +0200, Sascha Hauer wrote: > >>>On Thu, Jul 04, 2013 at 09:40:52AM +0100, Russell

Best practice device tree design for display subsystems/DRM

On Thu, Jul 04, 2013 at 11:40:17AM +0200, Sebastian Hesselbarth wrote: > On 07/04/13 11:23, Sascha Hauer wrote: > > > >With this you can describe the whole graph of devices you have in the > >devicetree. The examples in this file have a path from a camera sensor > >via a MIPI converter to a

Best practice device tree design for display subsystems/DRM

On Thu, Jul 04, 2013 at 10:08:29AM +0100, Russell King wrote: > On Thu, Jul 04, 2013 at 10:33:07AM +0200, Sascha Hauer wrote: > > A componentized device never completes and it doesn't have to. A > > componentized device can start once there is a path from an input > > (crtc, i2s unit) to an output

Best practice device tree design for display subsystems/DRM

On 07/04/13 11:30, Sascha Hauer wrote: > On Thu, Jul 04, 2013 at 10:11:31AM +0100, Russell King wrote: >> On Thu, Jul 04, 2013 at 10:58:17AM +0200, Sascha Hauer wrote: >>> On Thu, Jul 04, 2013 at 09:40:52AM +0100, Russell King wrote: Wrong. Please read the example with the diagrams I gave.

Best practice device tree design for display subsystems/DRM

On 07/04/13 11:23, Sascha Hauer wrote: > On Thu, Jul 04, 2013 at 11:10:35AM +0200, Sebastian Hesselbarth wrote: >> On 07/04/13 10:53, Sascha Hauer wrote: >>> On Thu, Jul 04, 2013 at 10:45:40AM +0200, Sebastian Hesselbarth wrote: On 07/04/13 10:33, Sascha Hauer wrote: > > A

Best practice device tree design for display subsystems/DRM

On Thu, Jul 04, 2013 at 10:11:31AM +0100, Russell King wrote: > On Thu, Jul 04, 2013 at 10:58:17AM +0200, Sascha Hauer wrote: > > On Thu, Jul 04, 2013 at 09:40:52AM +0100, Russell King wrote: > > > Wrong. Please read the example with the diagrams I gave. Consider > > > what happens if you have

Best practice device tree design for display subsystems/DRM

On Thu, Jul 04, 2013 at 11:10:35AM +0200, Sebastian Hesselbarth wrote: > On 07/04/13 10:53, Sascha Hauer wrote: > >On Thu, Jul 04, 2013 at 10:45:40AM +0200, Sebastian Hesselbarth wrote: > >>On 07/04/13 10:33, Sascha Hauer wrote: > >>> > >>>A componentized device never completes and it doesn't have

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

Hi On Wed, Jul 3, 2013 at 11:45 PM, Ben Widawsky wrote: > 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

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

Hi On Wed, Jul 3, 2013 at 11:45 PM, Ben Widawsky wrote: > 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

Best practice device tree design for display subsystems/DRM

On Wed, Jul 3, 2013 at 5:02 AM, 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

Best practice device tree design for display subsystems/DRM

On 07/04/13 10:53, Sascha Hauer wrote: > On Thu, Jul 04, 2013 at 10:45:40AM +0200, Sebastian Hesselbarth wrote: >> On 07/04/13 10:33, Sascha Hauer wrote: >>> >>> A componentized device never completes and it doesn't have to. A >>> componentized device can start once there is a path from an input

[ANNOUNCE] libdrm 2.4.46

On Wed, Jul 03, 2013 at 09:35:12PM -0400, Ilija Hadzic wrote: > > 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: > >

Best practice device tree design for display subsystems/DRM

> -Original Message- > From: Russell King [mailto:rmk at arm.linux.org.uk] > Sent: Wednesday, July 03, 2013 9:05 PM > To: Inki Dae > Cc: 'Sebastian Hesselbarth'; 'Sascha Hauer'; 'Daniel Drake'; 'Jean- > Francois Moine'; devicetree-discuss at lists.ozlabs.org; dri- > devel at

Best practice device tree design for display subsystems/DRM

On Thu, Jul 04, 2013 at 09:40:52AM +0100, Russell King wrote: > On Thu, Jul 04, 2013 at 10:33:07AM +0200, Sascha Hauer wrote: > > On Wed, Jul 03, 2013 at 10:52:49AM +0100, Russell King wrote: > > > > > Sorry but I'd like to say that this cannot be used commonly. > > > > > Shouldn't you > > > > >

Best practice device tree design for display subsystems/DRM

On Thu, Jul 04, 2013 at 10:45:40AM +0200, Sebastian Hesselbarth wrote: > On 07/04/13 10:33, Sascha Hauer wrote: > > > >A componentized device never completes and it doesn't have to. A > >componentized device can start once there is a path from an input > >(crtc, i2s unit) to an output (connector,

[PATCH v2 00/14] Platform Framebuffers and SimpleDRM

On 07/04/2013 05:25 AM, David Herrmann wrote: > - What FB formats are common on x86 that we should add to SIMPLEFB_FORMATS? > (other than ARGB/XRGB32) The common pixel formats on x86 are: - Palettized 4-bit planar (bigendian, i.e. MSB to the left) - Palettized 8-bit packed (one byte per

Best practice device tree design for display subsystems/DRM

On 07/04/13 10:33, Sascha Hauer wrote: > On Wed, Jul 03, 2013 at 10:52:49AM +0100, Russell King wrote: Sorry but I'd like to say that this cannot be used commonly. Shouldn't you really consider Linux framebuffer or other subsystems? The above dtsi file is specific to DRM subsystem.

Best practice device tree design for display subsystems/DRM

On Wed, Jul 03, 2013 at 10:52:49AM +0100, Russell King wrote: > > > Sorry but I'd like to say that this cannot be used commonly. Shouldn't you > > > really consider Linux framebuffer or other subsystems? The above dtsi file > > > is specific to DRM subsystem. And I think the dtsi file has no any >

Best practice device tree design for display subsystems/DRM

On Thu, Jul 04, 2013 at 10:58:17AM +0200, Sascha Hauer wrote: > On Thu, Jul 04, 2013 at 09:40:52AM +0100, Russell King wrote: > > Wrong. Please read the example with the diagrams I gave. Consider > > what happens if you have two display devices connected to a single > > output, one which fixes

Best practice device tree design for display subsystems/DRM

On Thu, Jul 04, 2013 at 10:33:07AM +0200, Sascha Hauer wrote: > A componentized device never completes and it doesn't have to. A > componentized device can start once there is a path from an input > (crtc, i2s unit) to an output (connector, speaker). Sorry for the incomplete reply. If you read

[Bug 43114] Can't set high engine clock for RadeonHD 6620G

https://bugzilla.kernel.org/show_bug.cgi?id=43114 RussianNeuroMancer changed: What|Removed |Added Status|NEW |RESOLVED Resolution|

Best practice device tree design for display subsystems/DRM

On Thu, Jul 04, 2013 at 10:33:07AM +0200, Sascha Hauer wrote: > On Wed, Jul 03, 2013 at 10:52:49AM +0100, Russell King wrote: > > > > Sorry but I'd like to say that this cannot be used commonly. Shouldn't > > > > you > > > > really consider Linux framebuffer or other subsystems? The above dtsi >

Bug report for Radeon HD 7870

On Don, 2013-07-04 at 00:51 +0200, Andrej Gelenberg wrote: > > i have an Radeon HD 7870 GHz Edition graphic card and at finnaly got > some 3D and VDPAU acceleration with kernel 3.10, mesa 9.2 from > 19.6.2013 and glamor accelerations, but it carsh a lot. I attached > dmesg witch hopefully helpful

Best practice device tree design for display subsystems/DRM

On 07/04/13 09:05, Inki Dae wrote: >> -Original Message- >> From: Sebastian Hesselbarth [mailto:sebastian.hesselbarth at gmail.com] >> Sent: Wednesday, July 03, 2013 8:52 PM >> To: Inki Dae >> Cc: 'Russell King'; devicetree-discuss at lists.ozlabs.org; 'Jean-Francois >> Moine'; 'Sascha

[Bug 60381] AMD Radeon 7770 Ghz edition Crash with DPM active

https://bugzilla.kernel.org/show_bug.cgi?id=60381 --- Comment #6 from Michel D?nzer 2013-07-04 08:20:06 --- (In reply to comment #0) > with static PM it crashes if you try to change the profile FWIW, that might work better if you explicitly set the low profile first. -- Configure

[Bug 60381] AMD Radeon 7770 Ghz edition Crash with DPM active

https://bugzilla.kernel.org/show_bug.cgi?id=60381 --- Comment #5 from rafael castillo 2013-07-04 01:12:10 --- Created an attachment (id=106781) --> (https://bugzilla.kernel.org/attachment.cgi?id=106781) vbios.rom -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email

[Bug 60381] AMD Radeon 7770 Ghz edition Crash with DPM active

https://bugzilla.kernel.org/show_bug.cgi?id=60381 --- Comment #4 from rafael castillo 2013-07-04 01:11:51 --- thanks for your response, im attaching the vbios info but im unable to get an dmesg output in the moment of the crash since it kicks in kms load and hangs[keyboard keys blinking]

[Bug 60381] AMD Radeon 7770 Ghz edition Crash with DPM active

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

Bug report for Radeon HD 7870

nts/20130704/5fc948c3/attachment-0001.obj> -- next part -- A non-text attachment was scrubbed... Name: Xorg.0.log Type: text/x-log Size: 45824 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130704/5fc948c3/attachment-0001.bin>

[PATCH] radeon: Fix surface register on r100

Working on KMS support on OpenBSD/sparc64, I ended up with the initial framebuffer on a Sun XVR-100 card (Radeon 7000/VE, RV100 with OpenFirmware) being tiled when none of the tiling flags were set. Tracked it down to an issue with r100_set_surface_reg(). The tiling bits on these older chips are

[Bug 60381] AMD Radeon 7770 Ghz edition Crash with DPM active

https://bugzilla.kernel.org/show_bug.cgi?id=60381 --- Comment #2 from rafael castillo 2013-07-04 00:38:24 --- Created an attachment (id=106751) --> (https://bugzilla.kernel.org/attachment.cgi?id=106751) lspci -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email

[Bug 60381] AMD Radeon 7770 Ghz edition Crash with DPM active

https://bugzilla.kernel.org/show_bug.cgi?id=60381 --- Comment #1 from rafael castillo 2013-07-04 00:38:04 --- Created an attachment (id=106741) --> (https://bugzilla.kernel.org/attachment.cgi?id=106741) glxinfo -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email

[Bug 60381] New: AMD Radeon 7770 Ghz edition Crash with DPM active

https://bugzilla.kernel.org/show_bug.cgi?id=60381 Summary: AMD Radeon 7770 Ghz edition Crash with DPM active Product: Drivers Version: 2.5 Kernel Version: 3.10.0-next-20130703 Platform: All OS/Version: Linux Tree: Mainline

[PATCH v2 0/3] drm/cma: use prime helpers instead GEM CMA specific dma_buf functionality

Hi Joonyoung, Thank you for the patches. On Friday 28 June 2013 14:24:43 Joonyoung Shim wrote: > Hello, > > This is the second version patchset. > > GEM CMA supports dma_buf but it needs GEM CMA specific functionality for > dma_buf. We can use prime helpers for dma_buf by commit >

Re: 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 also use it

Re: 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 =

Re: 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 compatible

Re: 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 intention...

Re: 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 compatible controller: Intel

Re: 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

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

-Original Message- From: Sebastian Hesselbarth [mailto:sebastian.hesselba...@gmail.com] Sent: Wednesday, July 03, 2013 8:52 PM To: Inki Dae Cc: 'Russell King'; devicetree-disc...@lists.ozlabs.org; 'Jean-Francois Moine'; 'Sascha Hauer'; 'Daniel Drake';

Re: [PATCH v2 0/3] drm/cma: use prime helpers instead GEM CMA specific dma_buf functionality

On 07/04/2013 07:11 AM, Laurent Pinchart wrote: Hi Joonyoung, Thank you for the patches. On Friday 28 June 2013 14:24:43 Joonyoung Shim wrote: Hello, This is the second version patchset. GEM CMA supports dma_buf but it needs GEM CMA specific functionality for dma_buf. We can use prime

[PATCH] drm/prime: fix sgt NULL checking

The drm_gem_map_detach() can be called with sgt is NULL. Change-Id: I3b2f5878dfac6e1e77aebeeb7be781113dec59a7 Signed-off-by: Joonyoung Shim jy0922.s...@samsung.com --- drivers/gpu/drm/drm_prime.c | 11 ++- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git

[PATCH RESEND] drm/prime: fix sgt NULL checking

The drm_gem_map_detach() can be called with sgt is NULL. Signed-off-by: Joonyoung Shim jy0922.s...@samsung.com --- drivers/gpu/drm/drm_prime.c | 11 ++- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c index

Re: Bug report for Radeon HD 7870

On Don, 2013-07-04 at 00:51 +0200, Andrej Gelenberg wrote: i have an Radeon HD 7870 GHz Edition graphic card and at finnaly got some 3D and VDPAU acceleration with kernel 3.10, mesa 9.2 from 19.6.2013 and glamor accelerations, but it carsh a lot. I attached dmesg witch hopefully helpful

[GIT PULL v2] exynos-drm-next

Hi Dave, This is final pull request for 3.11. This resolves some memory leak issues, and includes some code and dt document file cleanups; just removed unnecessary descriptions. And the patch work for enhancing hdmiphy driver isn't in progress so this patch may go to 3.12. Please

Re: [ANNOUNCE] libdrm 2.4.46

On Wed, Jul 03, 2013 at 09:35:12PM -0400, Ilija Hadzic wrote: 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:

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

-Original Message- From: Sebastian Hesselbarth [mailto:sebastian.hesselba...@gmail.com] Sent: Thursday, July 04, 2013 4:25 PM To: Inki Dae Cc: 'Jean-Francois Moine'; 'Daniel Drake'; devicetree- disc...@lists.ozlabs.org; dri-devel@lists.freedesktop.org; 'Sascha Hauer'; 'Russell

[Bug 60381] AMD Radeon 7770 Ghz edition Crash with DPM active

https://bugzilla.kernel.org/show_bug.cgi?id=60381 --- Comment #6 from Michel Dänzer mic...@daenzer.net 2013-07-04 08:20:06 --- (In reply to comment #0) with static PM it crashes if you try to change the profile FWIW, that might work better if you explicitly set the low profile first. --

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

On Wed, Jul 03, 2013 at 10:52:49AM +0100, Russell King wrote: Sorry but I'd like to say that this cannot be used commonly. Shouldn't you really consider Linux framebuffer or other subsystems? The above dtsi file is specific to DRM subsystem. And I think the dtsi file has no any

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

On Thu, Jul 04, 2013 at 10:45:40AM +0200, Sebastian Hesselbarth wrote: On 07/04/13 10:33, Sascha Hauer wrote: A componentized device never completes and it doesn't have to. A componentized device can start once there is a path from an input (crtc, i2s unit) to an output (connector, speaker).

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

On Thu, Jul 04, 2013 at 09:40:52AM +0100, Russell King wrote: On Thu, Jul 04, 2013 at 10:33:07AM +0200, Sascha Hauer wrote: On Wed, Jul 03, 2013 at 10:52:49AM +0100, Russell King wrote: Sorry but I'd like to say that this cannot be used commonly. Shouldn't you really consider

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

Hi On Wed, Jul 3, 2013 at 11:45 PM, Ben Widawsky b...@bwidawsk.net wrote: 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

  1   2   >