dri-devel December 2011

dri-devel@lists.freedesktop.org

83 participants
552 discussions

[ANNOUNCE] libdrm 2.4.29
by Chris Wilson 13 Dec '11

13 Dec '11

This publishes some new API for Intel to be able to cap the number of VMA that libdrm_intel caches amongst its bo. This is intended to be used by clients to prevent applications (such as the xserver) from exhausting their per-process limits on inactive GTT mmaps whilst also mitigating against the costs of recreating those mmaps. -Chris Chris Wilson (6): intel: Clean up mmaps on freeing the buffer intel: Add an interface to limit vma caching intel: Evict cached VMA in order to make room for new mappings intel: Update map-count for an early error return during mapping intel: Remove the fresh assertions used to debug the vma cacheing configure: Bump version for 2.4.29 Dave Airlie (1): test/radeon: add missing files for dist git tag: 2.4.29 http://dri.freedesktop.org/libdrm/libdrm-2.4.29.tar.bz2 MD5: 96d5e3e9edd55f4b016fe3b5dd0a1953 libdrm-2.4.29.tar.bz2 SHA1: 054ca4f6b9145b1bb5192f3cba4dd1835fcc5977 libdrm-2.4.29.tar.bz2 SHA256: e2432dc93e933479132123a1dca382294c30f55bc895bb737b6bdd6f2b8c452e libdrm-2.4.29.tar.bz2 http://dri.freedesktop.org/libdrm/libdrm-2.4.29.tar.gz MD5: 2596e48b4d2663ed075f0a86e977cf99 libdrm-2.4.29.tar.gz SHA1: 68d46937f5e725b439a8ed748211f0a27168caf3 libdrm-2.4.29.tar.gz SHA256: d60ecf6fc52f92663ee80cc94560ead56b493e4b91d1ee99f2292f7ecdab40b2 libdrm-2.4.29.tar.gz -- Chris Wilson, Intel Open Source Technology Centre

1 0

EDID Override
by Thorsten Schoel 13 Dec '11

13 Dec '11

Dear all, please find below a patch that will allow overriding a monitor's EDID with something provided by the user. This can be helpful in a number of situations as a quick google for "edid override" or similar suggests; I wrote it because my monitor is broken and doesn't provide any EDID at all. This is done through a module parameter named edid_override which is made up of three parts, each separated by a colon from the next. First is the name of a connector, second is the type of source for the information, third is the source of the information itself. If the second part is an 'f', the third will be the name of a file containing the EDID, if it is a 'w', the third will be the name of a firmware blob (i.e. the kernel firmware loading mechanism will be used to get the data), and if it is an 'r' th third part is raw EDID encoded as a stream of hexadecimal characters. 'd' as the second part will simply remove any previous edid override for the connector. Since this is my first attempt at getting a patch into the kernel the patch might well be in need of some additional work which I will be pleased to provide if someone provides me with a description and explanation of what needs to be done. The following points are on my mind. These are not things that I think have to be fixed but rather that I am unsure of: - Is drm_edid.c, the file where all the logic and currently everything else is placed, really the right place for the definition of the module parameter or should this go elsewhere? - Is it really desirable to have three different ways of fetching the EDID-data? Yet, having the raw EDID in hex (256 characters) on the kernel command line might not always be desirable. Loading the EDID as firmware may sometimes be more convenient than reading it from an arbitrary file. But if you look at it closely EDID data is not exactly what you think of when you think of firmware. - Adding an override through sysfs doesn't work yet and I can't figure out why. The patch was written and tested on Fedora 16, Linux 3.1. I have adopted it to 3.2-rc5 though. If anyone desires the 3.1 patch I can provide that as well. It is only marginally different though. Best, Thorsten

1 0

[PATCH] drm/i915: By default, enable RC6 on IVB and SNB when reasonable
by Keith Packard 13 Dec '11

13 Dec '11

RC6 should always work on IVB, and should work on SNB whenever IO remapping is disabled. Make the default value for the parameter turn it on in these cases. Setting the value to either 0 or 1 will force the specified behavior. Signed-off-by: Keith Packard <keithp(a)keithp.com> --- drivers/gpu/drm/i915/i915_drv.c | 4 ++-- drivers/gpu/drm/i915/i915_drv.h | 2 +- drivers/gpu/drm/i915/intel_display.c | 26 +++++++++++++++++++++++--- 3 files changed, 26 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c index 15bfa91..cf5c1bd 100644 --- a/drivers/gpu/drm/i915/i915_drv.c +++ b/drivers/gpu/drm/i915/i915_drv.c @@ -63,10 +63,10 @@ module_param_named(semaphores, i915_semaphores, int, 0600); MODULE_PARM_DESC(semaphores, "Use semaphores for inter-ring sync (default: false)"); -unsigned int i915_enable_rc6 __read_mostly = 0; +int i915_enable_rc6 __read_mostly = -1; module_param_named(i915_enable_rc6, i915_enable_rc6, int, 0600); MODULE_PARM_DESC(i915_enable_rc6, - "Enable power-saving render C-state 6 (default: true)"); + "Enable power-saving render C-state 6 (default: -1 (false when VT-d enabled)"); int i915_enable_fbc __read_mostly = -1; module_param_named(i915_enable_fbc, i915_enable_fbc, int, 0600); diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h index 4a9c1b9..172b022 100644 --- a/drivers/gpu/drm/i915/i915_drv.h +++ b/drivers/gpu/drm/i915/i915_drv.h @@ -1002,7 +1002,7 @@ extern unsigned int i915_semaphores __read_mostly; extern unsigned int i915_lvds_downclock __read_mostly; extern int i915_panel_use_ssc __read_mostly; extern int i915_vbt_sdvo_panel_type __read_mostly; -extern unsigned int i915_enable_rc6 __read_mostly; +extern int i915_enable_rc6 __read_mostly; extern int i915_enable_fbc __read_mostly; extern bool i915_enable_hangcheck __read_mostly; diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index e77a863..13fd4c0 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -38,8 +38,11 @@ #include "i915_drv.h" #include "i915_trace.h" #include "drm_dp_helper.h" - #include "drm_crtc_helper.h" +#ifdef CONFIG_INTEL_IOMMU +#include <linux/dma_remapping.h> +#include <linux/dmar.h> +#endif #define HAS_eDP (intel_pipe_has_type(crtc, INTEL_OUTPUT_EDP)) @@ -7887,6 +7890,23 @@ void intel_init_emon(struct drm_device *dev) dev_priv->corr = (lcfuse & LCFUSE_HIV_MASK); } +static bool intel_enable_rc6(struct drm_device *dev) +{ + if (i915_enable_rc6 >= 0) + return i915_enable_rc6; + if (INTEL_INFO(dev)->gen >= 7) + return 1; +#ifdef CONFIG_INTEL_IOMMU + /* + * Only enable RC6 if all dma remapping is disabled, or if + * there's no iommu present in the machine. + */ + if (INTEL_INFO(dev)->gen == 6) + return no_iommu || dmar_disabled; +#endif + return 0; +} + void gen6_enable_rps(struct drm_i915_private *dev_priv) { u32 rp_state_cap = I915_READ(GEN6_RP_STATE_CAP); @@ -7923,7 +7943,7 @@ void gen6_enable_rps(struct drm_i915_private *dev_priv) I915_WRITE(GEN6_RC6p_THRESHOLD, 100000); I915_WRITE(GEN6_RC6pp_THRESHOLD, 64000); /* unused */ - if (i915_enable_rc6) + if (intel_enable_rc6(dev_priv->dev)) rc6_mask = GEN6_RC_CTL_RC6p_ENABLE | GEN6_RC_CTL_RC6_ENABLE; @@ -8372,7 +8392,7 @@ void ironlake_enable_rc6(struct drm_device *dev) /* rc6 disabled by default due to repeated reports of hanging during * boot and resume. */ - if (!i915_enable_rc6) + if (!intel_enable_rc6(dev)) return; mutex_lock(&dev->struct_mutex); -- 1.7.7.3

8 26

[PATCH 0/2] update exynos drm driver.
by Inki Dae 13 Dec '11

13 Dec '11

this patch sets are as the following: - consolidate dpms framework. - add runtime pm feature for fimd driver. this patch is based on git repository below: git://people.freedesktop.org/~airlied/linux.git branch name: drm-fixes commit-id: 24bb5a0ce39c51a2e2602c947f218a19e4b26d7d and you can pull git repository below: git://git.infradead.org/users/kmpark/linux-samsung exynos-drm-fixes Inki Dae (1): drm/exynos: updated crtc and encoder dpms framework. Joonyoung Shim (1): drm/exynos: add runtime pm feature for fimd drivers/gpu/drm/exynos/exynos_drm_crtc.c | 58 ++++++++- drivers/gpu/drm/exynos/exynos_drm_drv.h | 6 +- drivers/gpu/drm/exynos/exynos_drm_encoder.c | 109 ++++++++++++---- drivers/gpu/drm/exynos/exynos_drm_encoder.h | 3 + drivers/gpu/drm/exynos/exynos_drm_fimd.c | 189 ++++++++++++++++++++------- 5 files changed, 282 insertions(+), 83 deletions(-) -- 1.7.4.1

3 15

drm_framebuffer_cleanup cleanup..
by Rob Clark 12 Dec '11

12 Dec '11

On Wed, Oct 19, 2011 at 8:27 AM, Daniel Vetter <daniel(a)ffwll.ch> wrote: >> +static void omap_framebuffer_destroy(struct drm_framebuffer *fb) >> +{ >> + struct drm_device *dev = fb->dev; >> + struct omap_framebuffer *omap_fb = to_omap_framebuffer(fb); >> + >> + DBG("destroy: FB ID: %d (%p)", fb->base.id, fb); >> + >> + drm_framebuffer_cleanup(fb); > > This is a bit a general mess in kms. All drivers need to call this, and > for added hilarity > - drm_crtc.c drm_mode_rmfb has a TODO that this is missing > - nouveau/radeon only do this _after_ unref'ing the backing storage > - gma500 also tries to restore the kernel console here which should be > done in lastclose (because you might disable another userspace fb on > another output). > > Can I prod you to write the patches to clean this up and move > drm_framebuffer_cleanup into common code? fyi, I'm starting to look at this.. looks like crtc/encoder/connector cleanup could also benefit from some similar treatment. I'll start w/ just fb, since that is a resource that is actually dynamically created/destroyed, so seems a bit more critical.. BR, -R

3 3

ttm dma allocator issue ?
by Jerome Glisse 12 Dec '11

12 Dec '11

Hi Konrad i stumble on this after a long period of test : Dec 9 12:00:37 homer kernel: ------------[ cut here ]------------ Dec 9 12:00:37 homer kernel: WARNING: at lib/dma-debug.c:894 check_unmap+0x262/0x7e0() Dec 9 12:00:37 homer kernel: Hardware name: GA-A75M-UD2H Dec 9 12:00:37 homer kernel: radeon 0000:01:00.0: DMA-API: device driver frees DMA memory with different CPU address [device address=0x00000002093f3000] [size=4096 bytes] [cpu alloc address=0x0000000213bf2000] [cpu free address=0x00000002093f3000] Dec 9 12:00:37 homer kernel: Modules linked in: radeon ttm drm_kms_helper drm ip6t_REJECT ipt_REJECT nf_conntrack_ipv6 nf_conntrack_ipv4 nf_defrag_ipv6 nf_defrag_ipv4 xt_state nf_conntrack ip6table_filter iptable_filter ip6_tables ip_tables dm_mirror dm_region_hash dm_log dm_mod snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_hwdep snd_seq snd_seq_device r8169 snd_pcm microcode serio_raw xhci_hcd mii hwmon i2c_piix4 i2c_algo_bit snd_timer snd soundcore snd_page_alloc ipv6 ext4 mbcache jbd2 ata_generic pata_atiixp [last unloaded: drm] Dec 9 12:00:37 homer kernel: Pid: 1158, comm: Heaven_x64 Not tainted 3.2.0-rc4+ #72 Dec 9 12:00:37 homer kernel: Call Trace: Dec 9 12:00:37 homer kernel: [<ffffffff81043d0f>] warn_slowpath_common+0x7f/0xc0 Dec 9 12:00:37 homer kernel: [<ffffffff81043e06>] warn_slowpath_fmt+0x46/0x50 Dec 9 12:00:37 homer kernel: [<ffffffff81229382>] check_unmap+0x262/0x7e0 Dec 9 12:00:37 homer kernel: [<ffffffff81113977>] ?vm_unmap_aliases+0x77/0x1d0 Dec 9 12:00:37 homer kernel: [<ffffffff8122996d>] debug_dma_free_coherent+0x6d/0x80 Dec 9 12:00:37 homer kernel: [<ffffffff8104bb60>] ?__request_resource+0x60/0x60 Dec 9 12:00:37 homer kernel: [<ffffffffa03e7597>] __ttm_dma_free_page+0x67/0xd0 [ttm] Dec 9 12:00:37 homer kernel: [<ffffffffa03e7f45>] ttm_dma_unpopulate+0x2c5/0x340 [ttm] Dec 9 12:00:37 homer kernel: [<ffffffffa042a81f>] radeon_ttm_tt_unpopulate+0xdf/0xf0 [radeon] Dec 9 12:00:37 homer kernel: [<ffffffffa03df151>] ttm_tt_destroy+0x31/0x70 [ttm] Dec 9 12:00:37 homer kernel: [<ffffffffa03df703>] ttm_bo_cleanup_memtype_use+0x43/0xb0 [ttm] Dec 9 12:00:37 homer kernel: [<ffffffffa03e0988>] ttm_bo_release+0x218/0x240 [ttm] Dec 9 12:00:37 homer kernel: [<ffffffffa03e0770>] ?ttm_bo_delayed_workqueue+0x40/0x40 [ttm] Dec 9 12:00:37 homer kernel: [<ffffffff8120df96>] kref_put+0x36/0x70 Dec 9 12:00:37 homer kernel: [<ffffffffa03dfa71>] ttm_bo_unref+0x41/0x60 [ttm] Dec 9 12:00:37 homer kernel: [<ffffffffa042bb29>] radeon_bo_unref+0x49/0x80 [radeon] Dec 9 12:00:37 homer kernel: [<ffffffffa038e4d0>] ?drm_gem_object_release_handle+0x90/0x90 [drm] Dec 9 12:00:37 homer kernel: [<ffffffffa043cd16>] radeon_gem_object_free+0x26/0x30 [radeon] Dec 9 12:00:37 homer kernel: [<ffffffffa038e4fa>] drm_gem_object_free+0x2a/0x30 [drm] Dec 9 12:00:37 homer kernel: [<ffffffff8120df96>] kref_put+0x36/0x70 Dec 9 12:00:37 homer kernel: [<ffffffffa038e152>] drm_gem_handle_delete+0xc2/0x110 [drm] Dec 9 12:00:37 homer kernel: [<ffffffffa038e7e8>] drm_gem_close_ioctl+0x28/0x30 [drm] Dec 9 12:00:37 homer kernel: [<ffffffffa038c5d4>] drm_ioctl+0x444/0x510 [drm] Dec 9 12:00:37 homer kernel: [<ffffffffa038e7c0>] ?drm_gem_destroy+0x60/0x60 [drm] Dec 9 12:00:37 homer kernel: [<ffffffff811c4670>] ?inode_has_perm+0x30/0x40 Dec 9 12:00:37 homer kernel: [<ffffffff811c4d6c>] ?file_has_perm+0xdc/0xf0 Dec 9 12:00:37 homer kernel: [<ffffffff81146198>] do_vfs_ioctl+0x98/0x570 Dec 9 12:00:37 homer kernel: [<ffffffff81146701>] sys_ioctl+0x91/0xa0 Dec 9 12:00:37 homer kernel: [<ffffffff814bf42b>] system_call_fastpath+0x16/0x1b Dec 9 12:00:37 homer kernel: ---[ end trace 8219ad8f7980f419 ]--- Dec 9 12:00:37 homer kernel: Mapped at: Dec 9 12:00:37 homer kernel: [<ffffffff812282eb>] debug_dma_alloc_coherent+0x3b/0x90 Dec 9 12:00:37 homer kernel: [<ffffffffa03e84a0>] ttm_dma_populate+0x340/0xa30 [ttm] Dec 9 12:00:37 homer kernel: [<ffffffffa042ae4f>] radeon_ttm_tt_populate+0x19f/0x280 [radeon] Dec 9 12:00:37 homer kernel: [<ffffffffa03df0ae>] ttm_tt_bind+0x3e/0x70 [ttm] Dec 9 12:00:37 homer kernel: [<ffffffffa03e0fcf>] ttm_bo_handle_move_mem+0x36f/0x3e0 [ttm] Dec 9 12:01:29 homer kernel: DMA-API: debugging out of memory - disabling Dec 9 19:16:54 homer kernel: [drm:radeon_dvi_detect] *ERROR* DVI-I-1: probed a monitor but no|invalid EDID Nothing else in the log. Quite frankly i dont this how this can happen. Any ideas ? Cheers, Jerome

2 3

crash with "drm/ttm: callback move_notify any time bo placement change v4" patch
by Konrad Rzeszutek Wilk 12 Dec '11

12 Dec '11

Hey, When I use the drm-next tree without the patch it works fine. (albeit slowly - but I posted the patches for that). With the patch mentioned I get this: 00:0d.0 VGA compatible controller: nVidia Corporation C61 [GeForce 6150SE nForce 430] (rev a2) sh-4.1# cd 0000:00:0d.0 sh-4.1# cd driver sh-4.1# echo "0000:00:0d.0" > unbind [ 144.585574] BUG: unable to handle kernel NULL pointer dereference at (null) [ 144.585588] IP: [<ffffffffa012a805>] nouveau_bo_move_ntfy+0x25/0xb0 [nouveau] [ 144.585605] PGD 30b5a067 PUD 30af1067 PMD 0 [ 144.585612] Oops: 0000 [#1] PREEMPT SMP [ 144.585619] CPU 0 [ 144.585622] Modules linked in: dm_multipath dm_mod xen_evtchn iscsi_boot_sysfs iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi libcrc32c crc32c radeon sg sd_mod fbcon tileblit nouveau font bitblit softcursor ttm drm_kms_helper mxm_wmi wmi video sata_nv ata_generic libata skge e1000 scsi_mod xen_blkfront xen_netfront fb_sys_fops sysimgblt sysfillrect syscopyarea xenfs [last unloaded: dump_dma] [ 144.585705] [ 144.585709] Pid: 3223, comm: sh Tainted: G O 3.2.0-rc5-00169-g82d722f #2 BIOSTAR Group N61PB-M2S/N61PB-M2S [ 144.585718] RIP: e030:[<ffffffffa012a805>] [<ffffffffa012a805>] nouveau_bo_move_ntfy+0x25/0xb0 [nouveau] [ 144.585730] RSP: e02b:ffff880030a69bf8 EFLAGS: 00010292 [ 144.585733] RAX: ffffffffa012a7e0 RBX: ffff88002dacca10 RCX: ffff88000ef80498 [ 144.585737] RDX: ffff88000ef80498 RSI: 0000000000000000 RDI: ffff88002dacc800 [ 144.585741] RBP: ffff880030a69c28 R08: 0000000000000000 R09: ffff88000f228d38 [ 144.585745] R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000 [ 144.585749] R13: ffff88002dacca10 R14: ffff88002dacc800 R15: ffff88000f228d38 [ 144.585757] FS: 00007fcdfa067700(0000) GS:ffff88003fe5b000(0000) knlGS:0000000000000000 [ 144.585761] CS: e033 DS: 0000 ES: 0000 CR0: 000000008005003b [ 144.585765] CR2: 0000000000000000 CR3: 0000000030bc6000 CR4: 0000000000000660 [ 144.585769] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 144.585774] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 [ 144.585778] Process sh (pid: 3223, threadinfo ffff880030a68000, task ffff88003a3809f0) [ 144.585782] Stack: [ 144.585784] ffff880030a69c18 ffff88002dacc800 0000000000000001 ffff88000ef80728 [ 144.585793] ffff88000ef80320 ffff88000f228d38 ffff880030a69c48 ffffffffa00f4aa1 [ 144.585802] ffff880030a69c48 ffff88002dacc800 ffff880030a69cb8 ffffffffa00f7ad9 [ 144.585810] Call Trace: [ 144.585818] [<ffffffffa00f4aa1>] ttm_bo_cleanup_memtype_use+0x21/0x80 [ttm] [ 144.585825] [<ffffffffa00f7ad9>] ttm_bo_release+0x249/0x270 [ttm] [ 144.585833] [<ffffffff81085261>] ? get_parent_ip+0x11/0x50 [ 144.585839] [<ffffffffa00f7890>] ? ttm_bo_create+0x110/0x110 [ttm] [ 144.585846] [<ffffffff812c2007>] kref_put+0x37/0x70 [ 144.585852] [<ffffffffa00f541d>] ttm_bo_unref+0x3d/0x50 [ttm] [ 144.585859] [<ffffffff8139be20>] ? drm_gem_object_handle_free+0x90/0x90 [ 144.585868] [<ffffffffa012e49a>] nouveau_gem_object_del+0x3a/0x70 [nouveau] [ 144.585874] [<ffffffff8139be45>] drm_gem_object_free+0x25/0x40 [ 144.585879] [<ffffffff812c2007>] kref_put+0x37/0x70 [ 144.585890] [<ffffffffa014b401>] nouveau_fbcon_fini+0xb1/0x130 [nouveau] [ 144.585899] [<ffffffffa0121f05>] nouveau_unload+0x1b5/0x220 [nouveau] [ 144.585904] [<ffffffff8139a302>] ? drm_lastclose+0x2b2/0x300 [ 144.585910] [<ffffffff813a038e>] drm_put_dev+0x6e/0x240 [ 144.585918] [<ffffffffa0121018>] nouveau_pci_remove+0x18/0x20 [nouveau] [ 144.585924] [<ffffffff812e6eb2>] pci_device_remove+0x32/0x60 [ 144.585930] [<ffffffff813b8b41>] __device_release_driver+0x61/0xc0 [ 144.585935] [<ffffffff813b8c98>] device_release_driver+0x28/0x40 [ 144.585940] [<ffffffff813b81a9>] driver_unbind+0x99/0xb0 [ 144.585945] [<ffffffff813b7747>] drv_attr_store+0x27/0x30 [ 144.585951] [<ffffffff811ebb2d>] sysfs_write_file+0xdd/0x160 [ 144.585957] [<ffffffff8117d018>] vfs_write+0xc8/0x190 [ 144.585962] [<ffffffff8117d1cc>] sys_write+0x4c/0x90 [ 144.585968] [<ffffffff815df452>] system_call_fastpath+0x16/0x1b [ 144.585972] Code: 84 00 00 00 00 00 55 48 89 e5 41 57 41 56 49 89 fe 41 55 4c 8d af 10 02 00 00 41 54 49 89 f4 53 48 83 ec 08 48 8b 9f 10 02 00 00 <4c> 8b 3e 4c 39 eb 75 13 eb 61 90 48 89 df e8 78 75 02 00 48 8b [ 144.586053] RIP [<ffffffffa012a805>] nouveau_bo_move_ntfy+0x25/0xb0 [nouveau] [ 144.586059] RSP <ffff880030a69bf8> [ 144.586059] CR2: 0000000000000000 [ 144.586059] ---[ end trace 520b019831a63add ]--- Dec 12 16:49:49 tst004 init: process '/bin/sh' (pid 3223) exited. Scheduling for restart. Dec 12 16:49:49 tst004 init: starting pid 3331, tty '/dev/hvc0': '/bin/sh' sh-4.1#

1 0

[PATCH] drm/radeon/kms: add some new pci ids
by alexdeucher＠gmail.com 12 Dec '11

12 Dec '11

From: Alex Deucher <alexander.deucher(a)amd.com> Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=43739 Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> Cc: stable(a)kernel.org --- include/drm/drm_pciids.h | 10 ++++++++++ 1 files changed, 10 insertions(+), 0 deletions(-) diff --git a/include/drm/drm_pciids.h b/include/drm/drm_pciids.h index 4e4fbb8..14b6cd0 100644 --- a/include/drm/drm_pciids.h +++ b/include/drm/drm_pciids.h @@ -182,8 +182,11 @@ {0x1002, 0x6748, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_TURKS|RADEON_NEW_MEMMAP}, \ {0x1002, 0x6749, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_TURKS|RADEON_NEW_MEMMAP}, \ {0x1002, 0x6750, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_TURKS|RADEON_NEW_MEMMAP}, \ + {0x1002, 0x6751, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_TURKS|RADEON_NEW_MEMMAP}, \ {0x1002, 0x6758, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_TURKS|RADEON_NEW_MEMMAP}, \ {0x1002, 0x6759, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_TURKS|RADEON_NEW_MEMMAP}, \ + {0x1002, 0x675B, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_TURKS|RADEON_NEW_MEMMAP}, \ + {0x1002, 0x675D, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_TURKS|RADEON_NEW_MEMMAP}, \ {0x1002, 0x675F, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_TURKS|RADEON_NEW_MEMMAP}, \ {0x1002, 0x6760, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_CAICOS|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP}, \ {0x1002, 0x6761, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_CAICOS|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP}, \ @@ -195,8 +198,10 @@ {0x1002, 0x6767, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_CAICOS|RADEON_NEW_MEMMAP}, \ {0x1002, 0x6768, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_CAICOS|RADEON_NEW_MEMMAP}, \ {0x1002, 0x6770, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_CAICOS|RADEON_NEW_MEMMAP}, \ + {0x1002, 0x6772, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_CAICOS|RADEON_NEW_MEMMAP}, \ {0x1002, 0x6778, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_CAICOS|RADEON_NEW_MEMMAP}, \ {0x1002, 0x6779, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_CAICOS|RADEON_NEW_MEMMAP}, \ + {0x1002, 0x677B, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_CAICOS|RADEON_NEW_MEMMAP}, \ {0x1002, 0x6840, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_TURKS|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP}, \ {0x1002, 0x6841, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_TURKS|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP}, \ {0x1002, 0x6842, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_TURKS|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP}, \ @@ -246,6 +251,7 @@ {0x1002, 0x68f2, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_CEDAR|RADEON_NEW_MEMMAP}, \ {0x1002, 0x68f8, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_CEDAR|RADEON_NEW_MEMMAP}, \ {0x1002, 0x68f9, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_CEDAR|RADEON_NEW_MEMMAP}, \ + {0x1002, 0x68fa, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_CEDAR|RADEON_NEW_MEMMAP}, \ {0x1002, 0x68fe, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_CEDAR|RADEON_NEW_MEMMAP}, \ {0x1002, 0x7100, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_R520|RADEON_NEW_MEMMAP}, \ {0x1002, 0x7101, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_R520|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP}, \ @@ -488,6 +494,8 @@ {0x1002, 0x9647, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_SUMO|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP|RADEON_IS_IGP},\ {0x1002, 0x9648, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_SUMO|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP|RADEON_IS_IGP},\ {0x1002, 0x964a, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_SUMO|RADEON_NEW_MEMMAP|RADEON_IS_IGP}, \ + {0x1002, 0x964b, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_SUMO|RADEON_NEW_MEMMAP|RADEON_IS_IGP}, \ + {0x1002, 0x964c, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_SUMO|RADEON_NEW_MEMMAP|RADEON_IS_IGP}, \ {0x1002, 0x964e, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_SUMO|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP|RADEON_IS_IGP},\ {0x1002, 0x964f, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_SUMO|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP|RADEON_IS_IGP},\ {0x1002, 0x9710, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_RS880|RADEON_NEW_MEMMAP|RADEON_IS_IGP}, \ @@ -502,6 +510,8 @@ {0x1002, 0x9805, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_PALM|RADEON_NEW_MEMMAP|RADEON_IS_IGP}, \ {0x1002, 0x9806, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_PALM|RADEON_NEW_MEMMAP|RADEON_IS_IGP}, \ {0x1002, 0x9807, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_PALM|RADEON_NEW_MEMMAP|RADEON_IS_IGP}, \ + {0x1002, 0x9808, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_PALM|RADEON_NEW_MEMMAP|RADEON_IS_IGP}, \ + {0x1002, 0x9809, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_PALM|RADEON_NEW_MEMMAP|RADEON_IS_IGP}, \ {0, 0, 0} #define r128_PCI_IDS \ -- 1.7.3.4

1 0

[Dual-LVDS Acer Iconia laptop] i915/DRM issue: one screen stays off [3.2-rc4+]
by Baptiste Jonglez 11 Dec '11

11 Dec '11

Hi, I've got a lot of troubles with a dual-LVDS Acer laptop (it doesn't have a keyboard, but two displays with touchscreens) The Intel GPU is integrated into the Core i5-480M CPU: it's a bit older than Sandybridge, as it seems to be based on the Arrandale micro-architecture. In the BIOS, both displays work fine; but as soon as the kernel boots up, the second display (i.e. the one where you usually find a keyboard) is turned off. The main display works as expected. xrandr reports two LVDS displays: LVDS1, which is connected, and LVDS2, which is marked as "disconnected". No matter what I tried, I can't bring that second display up. During the boot, just after the drm is set up, the following message shows up: [drm:intel_dsm_pci_probe] *ERROR* failed to get supported _DSM functions (attached is the relevant part of dmesg [1]) I then tried booting with "video=LVDS-2:e". The same message shows up while booting, with these two following: [drm:drm_crtc_helper_set_config] *ERROR* failed to set mode on [CRTC:4] fbcon_init: detected unhandled fb_set_par error, error code -22 (attached is the relevant part of dmesg [2]) With that kernel command line forcing LVDS2, the "drm_crtc_helper_set_config" error shows up each time I switch tty; additionally, X does not want to start anymore (spewing out the aforementioned error multiple times before giving up) I'm currently using the latest 3.2 kernel from linus' tree (af968e29acd91ebeb4224e899202c46c93171ecd), but the behavior was similar with a vanilla 3.1.2. Other notes about this issue: - with an Ubuntu 2.6.35 kernel, the second display is on but flickering (with the picture distorted like an old analog TV...). The main display is working fine, as always. - with an Archlinux 2.6.37.5 kernel, the behavior is the same as with 3.2, the main display is ok and the second one is off. - I did succeed, only once and out of pure luck, to get the second screen to work with the 3.1.2 kernel. I haven't been able to reproduce that... I had booted with "video=LVDS-2:e" and let the laptop running ; pressing a key a few hours later turned back *both* displays on (the main display had been turned off by DPMS, and the second, well, was off from the start, as always) While not very helpful, it shows that it's definitely possible. - there are a some unhandled WMI events logged from the acer-wmi module [3] when closing the lid, opening it, and most importantly, when the (main) screen is turned on or off by DPMS. What do you think? I haven't really succeeded in nailing the source of the issue down, but here are a few possibilities I'm thinking of: - the driver is not aware it can drive two LVDS displays (not very likely, and it has worked once, see above) - there is some kind of switch that is able to turn the second screen on or off (I'm thinking of something like rfkill). If so, it looks like something non-standard and undocumented. This would explain the WMI events (see the last note above) - buggy ACPI implementation. I tried to extract then recompile the DSDT [4], and iasl spews out 17 errors and 12 warnings. Also worth noticing is that line in dmesg: "pci0000:00: ACPI _OSC request failed (AE_ERROR), returned control mask: 0x1d" The Archlinux userland is: - libdrm 2.4.27 - xorg-server 1.11.2 - intel-dri 7.11.1 - xf86-video-intel 2.17.0 Please let me know if there are any other details I should provide. Regards, Baptiste Attachments: [1] dmesg-DSM-functions.log - drm errors when booting normally [2] dmesg-video-lvds2.log - drm errors when forcing LVDS2 on the cmdline [3] acer_wmi.log - WMI events that land in dmesg [4] dsdt - /sys/firmware/acpi/tables/DSDT

4 8

[PATCH 1/3] drm/omap: allocation fail check
by Rob Clark 10 Dec '11

10 Dec '11

From: Rob Clark <rob(a)ti.com> Signed-off-by: Rob Clark <rob(a)ti.com> --- drivers/staging/omapdrm/omap_gem.c | 4 ++++ 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/drivers/staging/omapdrm/omap_gem.c b/drivers/staging/omapdrm/omap_gem.c index 1054da3..a451c57 100644 --- a/drivers/staging/omapdrm/omap_gem.c +++ b/drivers/staging/omapdrm/omap_gem.c @@ -1094,6 +1094,10 @@ void omap_gem_init(struct drm_device *dev) } usergart = kzalloc(3 * sizeof(*usergart), GFP_KERNEL); + if (!usergart) { + dev_warn(dev->dev, "could not allocate usergart\n"); + return; + } /* reserve 4k aligned/wide regions for userspace mappings: */ for (i = 0; i < ARRAY_SIZE(fmts); i++) { -- 1.7.5.4

1 2

← Newer
1
...
47
48
49
50
51
52
53
...
56
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel December 2011