dri-devel September 2012

dri-devel@lists.freedesktop.org

134 participants
706 discussions

[Bug 26891] Radeon KMS fails with inaccessible AtomBIOS on systems with (U)EFI boot
by bugzilla-daemon＠freedesktop.org 05 Sep '12

05 Sep '12

https://bugs.freedesktop.org/show_bug.cgi?id=26891 Florian Mickler <florian(a)mickler.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |florian(a)mickler.org --- Comment #37 from Florian Mickler <florian(a)mickler.org> 2012-09-05 20:39:27 UTC --- A patch referencing this bug report has been merged in Linux v3.6-rc3: commit 268ba0a99f89a84dc5eb312470896113d0709c74 Author: David Lamparter <equinox(a)diac24.net> Date: Thu Aug 16 15:45:20 2012 -0400 drm/radeon: implement ACPI VFCT vbios fetch (v3) -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 0

[Bug 42490] NUTMEG DP to VGA bridge not working
by bugzilla-daemon＠freedesktop.org 05 Sep '12

05 Sep '12

https://bugs.freedesktop.org/show_bug.cgi?id=42490 --- Comment #31 from Alex Deucher <agd5f(a)yahoo.com> 2012-09-05 18:34:56 UTC --- Please try my 3.6 fixes tree (should show up in 3.6.0rc4+ and eventually stable kernels). http://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-fixes-3.6 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 0

[Bug 42490] NUTMEG DP to VGA bridge not working
by bugzilla-daemon＠freedesktop.org 05 Sep '12

05 Sep '12

https://bugs.freedesktop.org/show_bug.cgi?id=42490 lukenshiro(a)ngi.it changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |lukenshiro(a)ngi.it --- Comment #30 from lukenshiro(a)ngi.it 2012-09-05 18:31:11 UTC --- I have a similar problem: right after boot, my screen works (displays kernel messages) until maybe drm module is loaded (I guess by udev), then it becomes immediately blank and monitor is blinking, and then works again some time after fbcon and radeon modules are manually loaded in boot scripts (before starting X). It depends on modeset=1; if I use modeset=0 this behaviour doesn't appear, bua X cannot run without KMS. I have an AMD A4-3300 APU and using a (vanilla) linux kernel 3.5.3 (on Slackware64) The real problem is that some time (a couple of minutes or so) after video adapter is in idle mode (e.g. if I am not using the PC), monitor blinks (as in low power mode) screen is blank and system is no longer recoverable (unless I use e.g. ssh just to power it off). I don't know if the two problems are really related or not. Voltage problems? I have these messages in dmesg, too, when it happens: """ [ 2405.888198] [drm:radeon_atom_encoder_dpms], encoder dpms 33 to mode 0, devices 00000001, active_devices 00000001 [ 2405.892352] [drm:radeon_dp_get_link_status], link status 44 44 01 00 44 44 [ 2405.892360] [drm:dp_get_adjust_train], requested signal parameters: lane 0 voltage 0.4V pre_emph 3.5dB [ 2405.892365] [drm:dp_get_adjust_train], using signal parameters: voltage 0.4V pre_emph 3.5dB [ 2405.893921] [drm:radeon_dp_get_link_status], link status 44 44 01 00 48 44 [ 2405.893926] [drm:dp_get_adjust_train], requested signal parameters: lane 0 voltage 0.4V pre_emph 6dB [ 2405.893931] [drm:dp_get_adjust_train], using signal parameters: voltage 0.4V pre_emph 6dB [ 2405.895508] [drm:radeon_dp_get_link_status], link status 44 44 01 00 4c 44 [ 2405.895514] [drm:dp_get_adjust_train], requested signal parameters: lane 0 voltage 0.4V pre_emph 9.5dB [ 2405.895518] [drm:dp_get_adjust_train], using signal parameters: voltage 0.4V pre_emph 9.5dB [ 2405.897079] [drm:radeon_dp_get_link_status], link status 44 44 01 00 41 44 [ 2405.897085] [drm:dp_get_adjust_train], requested signal parameters: lane 0 voltage 0.6V pre_emph 0dB [ 2405.897089] [drm:dp_get_adjust_train], using signal parameters: voltage 0.6V pre_emph 0dB [ 2405.898632] [drm:radeon_dp_get_link_status], link status 44 44 01 00 45 44 [ 2405.898634] [drm:dp_get_adjust_train], requested signal parameters: lane 0 voltage 0.6V pre_emph 3.5dB [ 2405.898636] [drm:dp_get_adjust_train], using signal parameters: voltage 0.6V pre_emph 3.5dB [ 2405.900152] [drm:radeon_dp_get_link_status], link status 44 44 01 00 49 44 [ 2405.900155] [drm:dp_get_adjust_train], requested signal parameters: lane 0 voltage 0.6V pre_emph 6dB [ 2405.900156] [drm:dp_get_adjust_train], using signal parameters: voltage 0.6V pre_emph 6dB [ 2405.901674] [drm:radeon_dp_get_link_status], link status 44 44 01 00 42 44 [ 2405.901676] [drm:dp_get_adjust_train], requested signal parameters: lane 0 voltage 0.8V pre_emph 0dB [ 2405.901677] [drm:dp_get_adjust_train], using signal parameters: voltage 0.8V pre_emph 0dB [ 2405.903194] [drm:radeon_dp_get_link_status], link status 44 44 01 00 46 44 [ 2405.903196] [drm:dp_get_adjust_train], requested signal parameters: lane 0 voltage 0.8V pre_emph 3.5dB [ 2405.903197] [drm:dp_get_adjust_train], using signal parameters: voltage 0.8V pre_emph 3.5dB [ 2405.904715] [drm:radeon_dp_get_link_status], link status 44 44 01 00 43 44 [ 2405.904717] [drm:dp_get_adjust_train], requested signal parameters: lane 0 voltage 1.2V pre_emph 0dB [ 2405.904718] [drm:dp_get_adjust_train], using signal parameters: voltage 1.2V pre_emph 0dB [ 2405.906235] [drm:radeon_dp_get_link_status], link status 44 44 01 00 43 44 [ 2405.906238] [drm:radeon_dp_link_train_cr] *ERROR* clock recovery reached max voltage [ 2405.906240] [drm:radeon_dp_link_train_cr] *ERROR* clock recovery failed """ -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 0

Fix GPU triggering random system read after VRAM start change
by j.glisse＠gmail.com 05 Sep '12

05 Sep '12

So first patch is a fix in itself, smallest possible and should go to stable. Second patch is an improvement as a first step to flicker free boot. I have yet extensively tested second patch, especialy not on AGP but so far on few GPU/motherboard it looks good. It can probably wait 3.7. Will test it more and report. I have a third patch that is a step closer to flicker free boot on uefi, waiting ack to release a reg. Cheers, Jerome

4 8

[PATCH] drm: use %*ph to dump small buffers
by Andy Shevchenko 05 Sep '12

05 Sep '12

Signed-off-by: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com> --- drivers/gpu/drm/nouveau/nouveau_dp.c | 4 +--- drivers/gpu/drm/radeon/atombios_dp.c | 4 +--- drivers/gpu/drm/udl/udl_main.c | 7 ++----- 3 files changed, 4 insertions(+), 11 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_dp.c b/drivers/gpu/drm/nouveau/nouveau_dp.c index 7e289d2..e754aa3 100644 --- a/drivers/gpu/drm/nouveau/nouveau_dp.c +++ b/drivers/gpu/drm/nouveau/nouveau_dp.c @@ -289,9 +289,7 @@ dp_link_train_update(struct drm_device *dev, struct dp_state *dp, u32 delay) if (ret) return ret; - NV_DEBUG_KMS(dev, "status %02x %02x %02x %02x %02x %02x\n", - dp->stat[0], dp->stat[1], dp->stat[2], dp->stat[3], - dp->stat[4], dp->stat[5]); + NV_DEBUG_KMS(dev, "status %*ph\n", 6, dp->stat); return 0; } diff --git a/drivers/gpu/drm/radeon/atombios_dp.c b/drivers/gpu/drm/radeon/atombios_dp.c index 3623b98..d48224b 100644 --- a/drivers/gpu/drm/radeon/atombios_dp.c +++ b/drivers/gpu/drm/radeon/atombios_dp.c @@ -653,9 +653,7 @@ static bool radeon_dp_get_link_status(struct radeon_connector *radeon_connector, return false; } - DRM_DEBUG_KMS("link status %02x %02x %02x %02x %02x %02x\n", - link_status[0], link_status[1], link_status[2], - link_status[3], link_status[4], link_status[5]); + DRM_DEBUG_KMS("link status %*ph\n", 6, link_status); return true; } diff --git a/drivers/gpu/drm/udl/udl_main.c b/drivers/gpu/drm/udl/udl_main.c index 4c2d836..40bf468 100644 --- a/drivers/gpu/drm/udl/udl_main.c +++ b/drivers/gpu/drm/udl/udl_main.c @@ -41,11 +41,8 @@ static int udl_parse_vendor_descriptor(struct drm_device *dev, total_len = usb_get_descriptor(usbdev, 0x5f, /* vendor specific */ 0, desc, MAX_VENDOR_DESCRIPTOR_SIZE); if (total_len > 5) { - DRM_INFO("vendor descriptor length:%x data:%02x %02x %02x %02x" \ - "%02x %02x %02x %02x %02x %02x %02x\n", - total_len, desc[0], - desc[1], desc[2], desc[3], desc[4], desc[5], desc[6], - desc[7], desc[8], desc[9], desc[10]); + DRM_INFO("vendor descriptor length:%x data:%*ph\n", + total_len, 11, desc); if ((desc[0] != total_len) || /* descriptor length */ (desc[1] != 0x5f) || /* vendor descriptor type */ -- 1.7.10.4

1 0

[PATCH] drm/prime: drop reference on imported dma-buf
by Rob Clark 05 Sep '12

05 Sep '12

From: Rob Clark <rob(a)ti.com> The GEM handle takes the reference. If a driver is actually importing a foreign dmabuf, rather than just re-importing it's own dmabuf, it needs to do a get_dma_buf(). Signed-off-by: Rob Clark <rob(a)ti.com> --- drivers/gpu/drm/drm_prime.c | 7 +++++++ drivers/gpu/drm/exynos/exynos_drm_dmabuf.c | 4 ++++ drivers/gpu/drm/i915/i915_gem_dmabuf.c | 4 ++++ drivers/gpu/drm/nouveau/nouveau_prime.c | 5 +++++ drivers/gpu/drm/radeon/radeon_prime.c | 4 ++++ drivers/gpu/drm/udl/udl_gem.c | 4 ++++ 6 files changed, 28 insertions(+) diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c index 4f80374..088e018 100644 --- a/drivers/gpu/drm/drm_prime.c +++ b/drivers/gpu/drm/drm_prime.c @@ -185,6 +185,13 @@ int drm_gem_prime_fd_to_handle(struct drm_device *dev, mutex_unlock(&file_priv->prime.lock); drm_gem_object_unreference_unlocked(obj); + /* + * Drop the ref we obtained w/ dma_buf_get() for the benefit of + * drivers simply re-importing their own dma-buf.. if drivers + * import a foreign dma-buf, they should get_dma_buf(). + */ + dma_buf_put(dma_buf); + return 0; fail: diff --git a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c b/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c index f270790..f8ac75b 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c +++ b/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c @@ -190,6 +190,9 @@ struct drm_gem_object *exynos_dmabuf_prime_import(struct drm_device *drm_dev, } } + /* since we are attaching, we need to hold a ref */ + get_dma_buf(dma_buf); + attach = dma_buf_attach(dma_buf, drm_dev->dev); if (IS_ERR(attach)) return ERR_PTR(-EINVAL); @@ -250,6 +253,7 @@ err_unmap_attach: dma_buf_unmap_attachment(attach, sgt, DMA_BIDIRECTIONAL); err_buf_detach: dma_buf_detach(dma_buf, attach); + dma_buf_put(dma_buf); return ERR_PTR(ret); } diff --git a/drivers/gpu/drm/i915/i915_gem_dmabuf.c b/drivers/gpu/drm/i915/i915_gem_dmabuf.c index cf6bdec..9d2b2eb 100644 --- a/drivers/gpu/drm/i915/i915_gem_dmabuf.c +++ b/drivers/gpu/drm/i915/i915_gem_dmabuf.c @@ -189,6 +189,9 @@ struct drm_gem_object *i915_gem_prime_import(struct drm_device *dev, } } + /* since we are attaching, we need to hold a ref */ + get_dma_buf(dma_buf); + /* need to attach */ attach = dma_buf_attach(dma_buf, dev->dev); if (IS_ERR(attach)) @@ -224,5 +227,6 @@ fail_unmap: dma_buf_unmap_attachment(attach, sg, DMA_BIDIRECTIONAL); fail_detach: dma_buf_detach(dma_buf, attach); + dma_buf_put(dma_buf); return ERR_PTR(ret); } diff --git a/drivers/gpu/drm/nouveau/nouveau_prime.c b/drivers/gpu/drm/nouveau/nouveau_prime.c index 4c82801..fc30886 100644 --- a/drivers/gpu/drm/nouveau/nouveau_prime.c +++ b/drivers/gpu/drm/nouveau/nouveau_prime.c @@ -200,6 +200,10 @@ struct drm_gem_object *nouveau_gem_prime_import(struct drm_device *dev, } } } + + /* since we are attaching, we need to hold a ref */ + get_dma_buf(dma_buf); + /* need to attach */ attach = dma_buf_attach(dma_buf, dev->dev); if (IS_ERR(attach)) @@ -223,6 +227,7 @@ fail_unmap: dma_buf_unmap_attachment(attach, sg, DMA_BIDIRECTIONAL); fail_detach: dma_buf_detach(dma_buf, attach); + dma_buf_put(dma_buf); return ERR_PTR(ret); } diff --git a/drivers/gpu/drm/radeon/radeon_prime.c b/drivers/gpu/drm/radeon/radeon_prime.c index 28f79ac..073a8d3 100644 --- a/drivers/gpu/drm/radeon/radeon_prime.c +++ b/drivers/gpu/drm/radeon/radeon_prime.c @@ -195,6 +195,9 @@ struct drm_gem_object *radeon_gem_prime_import(struct drm_device *dev, } } + /* since we are attaching, we need to hold a ref */ + get_dma_buf(dma_buf); + /* need to attach */ attach = dma_buf_attach(dma_buf, dev->dev); if (IS_ERR(attach)) @@ -218,5 +221,6 @@ fail_unmap: dma_buf_unmap_attachment(attach, sg, DMA_BIDIRECTIONAL); fail_detach: dma_buf_detach(dma_buf, attach); + dma_buf_put(dma_buf); return ERR_PTR(ret); } diff --git a/drivers/gpu/drm/udl/udl_gem.c b/drivers/gpu/drm/udl/udl_gem.c index 7bd65bd..47f25d5 100644 --- a/drivers/gpu/drm/udl/udl_gem.c +++ b/drivers/gpu/drm/udl/udl_gem.c @@ -305,6 +305,9 @@ struct drm_gem_object *udl_gem_prime_import(struct drm_device *dev, struct udl_gem_object *uobj; int ret; + /* since we are attaching, we need to hold a ref */ + get_dma_buf(dma_buf); + /* need to attach */ attach = dma_buf_attach(dma_buf, dev->dev); if (IS_ERR(attach)) @@ -329,5 +332,6 @@ fail_unmap: dma_buf_unmap_attachment(attach, sg, DMA_BIDIRECTIONAL); fail_detach: dma_buf_detach(dma_buf, attach); + dma_buf_put(dma_buf); return ERR_PTR(ret); } -- 1.7.9.5

3 5

[PATCH] drm/exynos: add dummy support for dmabuf-mmap
by Inki Dae 05 Sep '12

05 Sep '12

From: Tomasz Stanislawski <t.stanislaws(a)samsung.com> This patch adds a stub function for DMABUF mmap. This allows to export a DMABUF. Signed-off-by: Tomasz Stanislawski <t.stanislaws(a)samsung.com> Signed-off-by: Kyungmin Park <kyungmin.park(a)samsung.com> Signed-off-by: Inki Dae <inki.dae(a)samsung.com> --- drivers/gpu/drm/exynos/exynos_drm_dmabuf.c | 7 +++++++ 1 files changed, 7 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c b/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c index 613bf8a..ae13feb 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c +++ b/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c @@ -163,6 +163,12 @@ static void exynos_gem_dmabuf_kunmap(struct dma_buf *dma_buf, /* TODO */ } +static int exynos_gem_dmabuf_mmap(struct dma_buf *dma_buf, + struct vm_area_struct *vma) +{ + return -ENOTTY; +} + static struct dma_buf_ops exynos_dmabuf_ops = { .map_dma_buf = exynos_gem_map_dma_buf, .unmap_dma_buf = exynos_gem_unmap_dma_buf, @@ -170,6 +176,7 @@ static struct dma_buf_ops exynos_dmabuf_ops = { .kmap_atomic = exynos_gem_dmabuf_kmap_atomic, .kunmap = exynos_gem_dmabuf_kunmap, .kunmap_atomic = exynos_gem_dmabuf_kunmap_atomic, + .mmap = exynos_gem_dmabuf_mmap, .release = exynos_dmabuf_release, }; -- 1.7.4.1

1 0

Re: Re: [PATCH V3 1/2] drm/exynos: add platform_device_id table and driver data for exynos5 drm fimd
by Leela Krishna Amudala 05 Sep '12

05 Sep '12

Hi Tomasz, Please find the inline comments. Will post the next version today. Thanks. Leela Krishna Amudala. ------- Original Message ------- Sender : Tomasz Figa<t.figa(a)samsung.com> Junior Software Engineer/SPRC-Linux Platform (SSD)/Samsung Electronics Date : Sep 05, 2012 13:22 (GMT+05:30) Title : Re: [PATCH V3 1/2] drm/exynos: add platform_device_id table and driver data for exynos5 drm fimd Hi Leela, See my comments inline. On Thursday 16 of August 2012 12:08:08 Leela Krishna Amudala wrote: > +enum fimd_version_type { > + VERSION_8, /* FIMD_VERSION8 */ > +}; > + > +struct drm_fimd_driver_data { > + enum fimd_version_type fimd_ver; > +}; > + > +struct drm_fimd_driver_data exynos5_drm_fimd_driver_data = { > + .fimd_ver = VERSION_8, > +}; I think that the approach with timing_base, as suggested by Joonyoung Shim, would be much cleaner. Leela: Okay, will go with timing_base approach only > +static struct platform_device_id exynos_drm_fimd_driver_ids[] = { > + { > + .name = "exynos4-fb", > + }, { > + .name = "exynos5-drm-fimd", > + .driver_data = (unsigned long)&exynos5_drm_fimd_driver_data, > + }, > + {}, > +}; > +MODULE_DEVICE_TABLE(platform, exynos_drm_fimd_driver_ids); If I see correctly, this will crash on a null pointer dereference on Exynos4 without DT, because of NULL driver_data. Leela: yes, you are right, will take care of this P.S. I think you should CC linux-arm-kernel and linux-samsung-soc lists when submitting patches related to ARM and Samsung SoCs. Leela: Okay, will do it next time. Best regards, -- Tomasz Figa Samsung Poland R&D Center

1 0

[PATCH] drm: refcnt drm_framebuffer
by Rob Clark 05 Sep '12

05 Sep '12

From: Rob Clark <rob(a)ti.com> This simplifies drm fb lifetime, and if the crtc/plane needs to hold a ref to the fb when disabling a pipe until the next vblank, this avoids the need to make disabling an overlay synchronous. This is a problem that shows up when userspace is using a drm plane to implement a hw cursor.. making overlay disable synchronous causes a performance problem when x11 is rapidly enabling/disabling the hw cursor. But not making it synchronous opens up a race condition for crashing if userspace turns around and immediately deletes the fb. Refcnt'ing the fb makes it possible to solve this problem. v1: original v2: add drm_framebuffer_remove() which is called in all paths where fb->funcs->destroy() was directly called before. This cleans up the CRTCs/planes that the fb was attached to. You should only directly use drm_framebuffer_unreference() if you are also using drm_framebuffer_reference() to keep a ref to the fb. Signed-off-by: Rob Clark <rob(a)ti.com> --- drivers/gpu/drm/drm_crtc.c | 78 +++++++++++++++++++++++++---- drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 4 +- drivers/gpu/drm/i915/intel_display.c | 4 +- drivers/staging/omapdrm/omap_fbdev.c | 4 +- include/drm/drm_crtc.h | 5 ++ 5 files changed, 78 insertions(+), 17 deletions(-) diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c index 901de9a..96e236f 100644 --- a/drivers/gpu/drm/drm_crtc.c +++ b/drivers/gpu/drm/drm_crtc.c @@ -294,6 +294,8 @@ int drm_framebuffer_init(struct drm_device *dev, struct drm_framebuffer *fb, { int ret; + kref_init(&fb->refcount); + ret = drm_mode_object_get(dev, &fb->base, DRM_MODE_OBJECT_FB); if (ret) return ret; @@ -307,6 +309,38 @@ int drm_framebuffer_init(struct drm_device *dev, struct drm_framebuffer *fb, } EXPORT_SYMBOL(drm_framebuffer_init); +static void drm_framebuffer_free(struct kref *kref) +{ + struct drm_framebuffer *fb = + container_of(kref, struct drm_framebuffer, refcount); + fb->funcs->destroy(fb); +} + +/** + * drm_framebuffer_unreference - unref a framebuffer + * + * LOCKING: + * Caller must hold mode config lock. + */ +void drm_framebuffer_unreference(struct drm_framebuffer *fb) +{ + struct drm_device *dev = fb->dev; + DRM_DEBUG("FB ID: %d\n", fb->base.id); + WARN_ON(!mutex_is_locked(&dev->mode_config.mutex)); + kref_put(&fb->refcount, drm_framebuffer_free); +} +EXPORT_SYMBOL(drm_framebuffer_unreference); + +/** + * drm_framebuffer_reference - incr the fb refcnt + */ +void drm_framebuffer_reference(struct drm_framebuffer *fb) +{ + DRM_DEBUG("FB ID: %d\n", fb->base.id); + kref_get(&fb->refcount); +} +EXPORT_SYMBOL(drm_framebuffer_reference); + /** * drm_framebuffer_cleanup - remove a framebuffer object * @fb: framebuffer to remove @@ -320,6 +354,32 @@ EXPORT_SYMBOL(drm_framebuffer_init); void drm_framebuffer_cleanup(struct drm_framebuffer *fb) { struct drm_device *dev = fb->dev; + /* + * This could be moved to drm_framebuffer_remove(), but for + * debugging is nice to keep around the list of fb's that are + * no longer associated w/ a drm_file but are not unreferenced + * yet. (i915 and omapdrm have debugfs files which will show + * this.) + */ + drm_mode_object_put(dev, &fb->base); + list_del(&fb->head); + dev->mode_config.num_fb--; +} +EXPORT_SYMBOL(drm_framebuffer_cleanup); + +/** + * drm_framebuffer_remove - remove and unreference a framebuffer object + * @fb: framebuffer to remove + * + * LOCKING: + * Caller must hold mode config lock. + * + * Scans all the CRTCs and planes in @dev's mode_config. If they're + * using @fb, removes it, setting it to NULL. + */ +void drm_framebuffer_remove(struct drm_framebuffer *fb) +{ + struct drm_device *dev = fb->dev; struct drm_crtc *crtc; struct drm_plane *plane; struct drm_mode_set set; @@ -350,11 +410,11 @@ void drm_framebuffer_cleanup(struct drm_framebuffer *fb) } } - drm_mode_object_put(dev, &fb->base); - list_del(&fb->head); - dev->mode_config.num_fb--; + list_del(&fb->filp_head); + + drm_framebuffer_unreference(fb); } -EXPORT_SYMBOL(drm_framebuffer_cleanup); +EXPORT_SYMBOL(drm_framebuffer_remove); /** * drm_crtc_init - Initialise a new CRTC object @@ -1032,7 +1092,7 @@ void drm_mode_config_cleanup(struct drm_device *dev) } list_for_each_entry_safe(fb, fbt, &dev->mode_config.fb_list, head) { - fb->funcs->destroy(fb); + drm_framebuffer_remove(fb); } list_for_each_entry_safe(crtc, ct, &dev->mode_config.crtc_list, head) { @@ -2343,11 +2403,8 @@ int drm_mode_rmfb(struct drm_device *dev, goto out; } - /* TODO release all crtc connected to the framebuffer */ - /* TODO unhock the destructor from the buffer object */ - list_del(&fb->filp_head); - fb->funcs->destroy(fb); + drm_framebuffer_remove(fb); out: mutex_unlock(&dev->mode_config.mutex); @@ -2497,8 +2554,7 @@ void drm_fb_release(struct drm_file *priv) mutex_lock(&dev->mode_config.mutex); list_for_each_entry_safe(fb, tfb, &priv->fbs, filp_head) { - list_del(&fb->filp_head); - fb->funcs->destroy(fb); + drm_framebuffer_remove(fb); } mutex_unlock(&dev->mode_config.mutex); } diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c index d5586cc..f4ac433 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c +++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c @@ -266,8 +266,8 @@ static void exynos_drm_fbdev_destroy(struct drm_device *dev, /* release drm framebuffer and real buffer */ if (fb_helper->fb && fb_helper->fb->funcs) { fb = fb_helper->fb; - if (fb && fb->funcs->destroy) - fb->funcs->destroy(fb); + if (fb) + drm_framebuffer_remove(fb); } /* release linux framebuffer */ diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index a69a3d0..2109c9f 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -5687,7 +5687,7 @@ bool intel_get_load_detect_pipe(struct intel_encoder *intel_encoder, if (!drm_crtc_helper_set_mode(crtc, mode, 0, 0, old_fb)) { DRM_DEBUG_KMS("failed to set mode on load-detect pipe\n"); if (old->release_fb) - old->release_fb->funcs->destroy(old->release_fb); + drm_framebuffer_remove(old->release_fb); crtc->fb = old_fb; return false; } @@ -5717,7 +5717,7 @@ void intel_release_load_detect_pipe(struct intel_encoder *intel_encoder, drm_helper_disable_unused_functions(dev); if (old->release_fb) - old->release_fb->funcs->destroy(old->release_fb); + drm_framebuffer_remove(old->release_fb); return; } diff --git a/drivers/staging/omapdrm/omap_fbdev.c b/drivers/staging/omapdrm/omap_fbdev.c index 8c6ed3b..8a027bb 100644 --- a/drivers/staging/omapdrm/omap_fbdev.c +++ b/drivers/staging/omapdrm/omap_fbdev.c @@ -276,7 +276,7 @@ fail: if (fbi) framebuffer_release(fbi); if (fb) - fb->funcs->destroy(fb); + drm_framebuffer_remove(fb); } return ret; @@ -401,7 +401,7 @@ void omap_fbdev_free(struct drm_device *dev) /* this will free the backing object */ if (fbdev->fb) - fbdev->fb->funcs->destroy(fbdev->fb); + drm_framebuffer_remove(fbdev->fb); kfree(fbdev); diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h index a82e0a2..2442d01 100644 --- a/include/drm/drm_crtc.h +++ b/include/drm/drm_crtc.h @@ -219,6 +219,7 @@ struct drm_display_info { }; struct drm_framebuffer_funcs { + /* note: use drm_framebuffer_remove() */ void (*destroy)(struct drm_framebuffer *framebuffer); int (*create_handle)(struct drm_framebuffer *fb, struct drm_file *file_priv, @@ -243,6 +244,7 @@ struct drm_framebuffer_funcs { struct drm_framebuffer { struct drm_device *dev; + struct kref refcount; struct list_head head; struct drm_mode_object base; const struct drm_framebuffer_funcs *funcs; @@ -921,6 +923,9 @@ extern int drm_object_property_get_value(struct drm_mode_object *obj, extern int drm_framebuffer_init(struct drm_device *dev, struct drm_framebuffer *fb, const struct drm_framebuffer_funcs *funcs); +void drm_framebuffer_unreference(struct drm_framebuffer *fb); +void drm_framebuffer_reference(struct drm_framebuffer *fb); +void drm_framebuffer_remove(struct drm_framebuffer *fb); extern void drm_framebuffer_cleanup(struct drm_framebuffer *fb); extern void drm_connector_attach_property(struct drm_connector *connector, -- 1.7.9.5

2 1

[PATCH V3 0/2] video: drm: Add Device tree support to DRM-FIMD
by Leela Krishna Amudala 05 Sep '12

05 Sep '12

This patch set adds device tree support for DRM-FIMD for Samsung's Exynos5250. It includes parsing platform data from dts file. Also, adds the driver data for exynos5 device. This patchset is based and tested on top of v3.6-rc1 Also depends on below patchset http://lists.freedesktop.org/archives/dri-devel/2012-August/026076.html Changes since V2: - Added driver data to exynos5-drm-fimd as per Marek Szyprowski suggestion Changes since V1: - Corrected typo errors and changed compatibility string Leela Krishna Amudala (2): drm/exynos: add platform_device_id table and driver data for exynos5 drm fimd video: drm: exynos: Add device tree support Documentation/devicetree/bindings/fb/drm-fimd.txt | 80 +++++++++++ drivers/gpu/drm/exynos/exynos_drm_fimd.c | 151 ++++++++++++++++++++- 2 files changed, 224 insertions(+), 7 deletions(-) create mode 100644 Documentation/devicetree/bindings/fb/drm-fimd.txt

6 14

← Newer
1
...
64
65
66
67
68
69
70
71
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel September 2012