dri-devel November 2012

dri-devel@lists.freedesktop.org

126 participants
797 discussions

[PATCH] libdrm: add missing DRM_CAP_TIMESTAMP_MONOTONIC
by Imre Deak 22 Nov '12

22 Nov '12

Just add the definition according the kernel's copy of drm.h Signed-off-by: Imre Deak <imre.deak(a)intel.com> --- include/drm/drm.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/drm/drm.h b/include/drm/drm.h index a847689..d14b973 100644 --- a/include/drm/drm.h +++ b/include/drm/drm.h @@ -779,6 +779,7 @@ struct drm_event_vblank { #define DRM_CAP_DUMB_PREFERRED_DEPTH 0x3 #define DRM_CAP_DUMB_PREFER_SHADOW 0x4 #define DRM_CAP_PRIME 0x5 +#define DRM_CAP_TIMESTAMP_MONOTONIC 0x6 #define DRM_PRIME_CAP_IMPORT 0x1 #define DRM_PRIME_CAP_EXPORT 0x2 -- 1.7.9.5

1 0

Re: [PATCH v2 05/18] DRM/KMS/EDID: Test EDDC if EDID announces more than one Extension Block (v2)
by Egbert Eich 22 Nov '12

22 Nov '12

Ville Syrj�l� writes: > > Me neither. I just figured it might reduce the chance of false > positives. But if you say that can't happen, I'll take your word > for it. > > > Regarding memcmp() you are definitely right, I will change the code. > > > > > > > > Also the comment is somehow misleading. It talks about the base block > > > even though we're looking at the extension block. > > > > > > Reason for this patch: > > I had a bug report for a monitor announcing extension blocks in the extension > > block flag of the base block (over 200!) although it wasn't EDDC capable. > > For some reason it got past the ACK check when the segment number was written > > to address 0x30 and happily transferred the base block for any odd numbered > > block and some garbage for even ones. > > That's nasty. When I saw your patch I was immediately thinking that this > is caused by the IGNORE_NAK flag, but then I read the current code, and > realized that we're not using that flag. It was used in the original > EDDC patch, and I was worried that this kind of bad behaviour would be > possible if use the flag. But it seems I underestimated how crappy the > monitor hardwar can be. Right. This flag would only make sense for the base block (to reset an EDDC capable monitor but not fail on non-EDDC capable ones). In fact I had a patch to add this, but then I realized that none of the I2C implemenations in the gfx drivers honored this flag. But then I reread the VESA spec for EDDC, this requires that the segment address in the monitor has to be reset on a STOP condition. So if there ever is the case that a monitor has a segment > 0 selected when drm_read_edid() is called for the first time (because of a system crash for instance) the validation will fail and causes a 2nd read attempt for which the segment address should be reset by the previous transfer. Regarding crappiness of monitor hardware: catch me at a bar and I can tell you more stories ... ;p > > > The only reliable way we found to catch this condition early was to check if > > block 2 had the header of a base block which will happen when the display > > cannot deal with the segment number. > > > > This was what I tried to summarize in very few words - maybe i should reword > > it a bit. > > Right. The idea seems reasonable, I just found the comment somehow a > bit confusing when I was reading the code following it. > > So maybe something like 'Test if base block ..., by checking whether the > extension block is a duplicate the base block.' Although the use of > memcmp() will already make things much clearer. Right. I've already reworked it. Will send out. Cheers, Egbert.

1 0

Re: [PATCH v2 05/18] DRM/KMS/EDID: Test EDDC if EDID announces more than one Extension Block (v2)
by Egbert Eich 22 Nov '12

22 Nov '12

Ville Syrj�l� writes: > On Thu, Nov 22, 2012 at 05:22:55AM -0500, Egbert Eich wrote: > > There are displays which announce EDID extension blocks in the > > Extension Flag of the EDID base block although they are not EDDC > > capable (ie. take a segment address at I2C slave address 0x30). > > We test this by looking for an EDID header which is only possible > > in the base block. > > If the segment address is not taken into account, this block will > > be identical to the base block in which case we stop reading further > > EEDID blocks, correct the extension flag and just return the base > > block. > > > > v2: Split up EDID fixup code into separate commit. > > > > Signed-off-by: Egbert Eich <eich(a)suse.com> > > --- > > drivers/gpu/drm/drm_edid.c | 13 +++++++++++++ > > 1 files changed, 13 insertions(+), 0 deletions(-) > > > > diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c > > index a952cfe..5a0e331 100644 > > --- a/drivers/gpu/drm/drm_edid.c > > +++ b/drivers/gpu/drm/drm_edid.c > > @@ -364,6 +364,19 @@ drm_do_get_edid(struct drm_connector *connector, struct i2c_adapter *adapter) > > } > > if (drm_edid_block_valid(block + (valid_extensions + 1) * EDID_LENGTH, j, print_bad_edid)) { > > valid_extensions++; > > + /* Test if base block announced extension blocks although > > + * display is not EDDC capable. > > + */ > > + if (j == 2) { > > + int k; > > + for (k = 0; k < sizeof(edid_header); k++) > > + if (block[(EDID_LENGTH * 2) + k] != edid_header[k]) > > + break; > > + if (k == sizeof(edid_header)) { > > + valid_extensions = 0; > > + goto done_fix_extension_count; > > + } > > memcmp()? Also couldn't we just memcmp() the whole block against the base > block, instead of just the header part? I don't see an advantage of comparing the entire block with the base block: the signature should already be unique. However I don't insist ;) Regarding memcmp() you are definitely right, I will change the code. > > Also the comment is somehow misleading. It talks about the base block > even though we're looking at the extension block. Reason for this patch: I had a bug report for a monitor announcing extension blocks in the extension block flag of the base block (over 200!) although it wasn't EDDC capable. For some reason it got past the ACK check when the segment number was written to address 0x30 and happily transferred the base block for any odd numbered block and some garbage for even ones. The only reliable way we found to catch this condition early was to check if block 2 had the header of a base block which will happen when the display cannot deal with the segment number. This was what I tried to summarize in very few words - maybe i should reword it a bit. Thanks! Egbert.

2 1

[PATCH v12 0/6] of: add display helper
by Steffen Trumtrar 22 Nov '12

22 Nov '12

Hi! Changes since v11: - make pointers const where applicable - add reviewed-by Laurent Pinchart Regards, Steffen Steffen Trumtrar (6): video: add display_timing and videomode video: add of helper for videomode fbmon: add videomode helpers fbmon: add of_videomode helpers drm_modes: add videomode helpers drm_modes: add of_videomode helpers .../devicetree/bindings/video/display-timings.txt | 107 ++++++++++ drivers/gpu/drm/drm_modes.c | 70 +++++++ drivers/video/Kconfig | 19 ++ drivers/video/Makefile | 4 + drivers/video/display_timing.c | 24 +++ drivers/video/fbmon.c | 86 ++++++++ drivers/video/of_display_timing.c | 216 ++++++++++++++++++++ drivers/video/of_videomode.c | 48 +++++ drivers/video/videomode.c | 46 +++++ include/drm/drmP.h | 12 ++ include/linux/display_timing.h | 70 +++++++ include/linux/fb.h | 13 ++ include/linux/of_display_timings.h | 20 ++ include/linux/of_videomode.h | 18 ++ include/linux/videomode.h | 40 ++++ 15 files changed, 793 insertions(+) create mode 100644 Documentation/devicetree/bindings/video/display-timings.txt create mode 100644 drivers/video/display_timing.c create mode 100644 drivers/video/of_display_timing.c create mode 100644 drivers/video/of_videomode.c create mode 100644 drivers/video/videomode.c create mode 100644 include/linux/display_timing.h create mode 100644 include/linux/of_display_timings.h create mode 100644 include/linux/of_videomode.h create mode 100644 include/linux/videomode.h -- 1.7.10.4

9 38

[PATCH] drm/edid: tune down debug message in parse_hdmi_vsdb
by Daniel Vetter 22 Nov '12

22 Nov '12

Those tend to be totally not interesting for end-users, and for debugging we tend to dump the entire noise anyway by enabling all debug messages. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=57388 Signed-off-by: Daniel Vetter <daniel.vetter(a)ffwll.ch> --- drivers/gpu/drm/drm_edid.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c index 1648200..484c36a 100644 --- a/drivers/gpu/drm/drm_edid.c +++ b/drivers/gpu/drm/drm_edid.c @@ -1639,7 +1639,7 @@ parse_hdmi_vsdb(struct drm_connector *connector, const u8 *db) if (len >= 12) connector->audio_latency[1] = db[12]; - DRM_LOG_KMS("HDMI: DVI dual %d, " + DRM_DEBUG_KMS("HDMI: DVI dual %d, " "max TMDS clock %d, " "latency present %d %d, " "video latency %d %d, " -- 1.7.10.4

1 0

[PATCH 1/1] drm/exynos: Fix potential NULL pointer dereference in exynos_drm_encoder.c
by Sachin Kamat 22 Nov '12

22 Nov '12

Check overlay_ops is not NULL as checked in the previous 'if' condition. Fixes the following smatch error: drivers/gpu/drm/exynos/exynos_drm_encoder.c:509 exynos_drm_encoder_plane_disable() error: we previously assumed 'overlay_ops' could be null (see line 499) Signed-off-by: Sachin Kamat <sachin.kamat(a)linaro.org> --- drivers/gpu/drm/exynos/exynos_drm_encoder.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_encoder.c b/drivers/gpu/drm/exynos/exynos_drm_encoder.c index e51503f..a44238e 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_encoder.c +++ b/drivers/gpu/drm/exynos/exynos_drm_encoder.c @@ -506,6 +506,6 @@ void exynos_drm_encoder_plane_disable(struct drm_encoder *encoder, void *data) * because the setting for disabling the overlay will be updated * at vsync. */ - if (overlay_ops->wait_for_vblank) + if (overlay_ops && overlay_ops->wait_for_vblank) overlay_ops->wait_for_vblank(manager->dev); } -- 1.7.4.1

2 8

[PATCH] drm/exynos: use sgt instead of pages for framebuffer address
by Prathyush K 22 Nov '12

22 Nov '12

The 'pages' structure in the exynos gem buffer has been removed. So we get the fix.smem_start from the first sgl of the scatter gather table. Signed-off-by: Prathyush K <prathyush.k(a)samsung.com> --- drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c index 3d5910f..d37f281 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c +++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c @@ -117,8 +117,8 @@ static int exynos_drm_fbdev_update(struct drm_fb_helper *helper, dev->mode_config.fb_base = (resource_size_t)buffer->dma_addr; fbi->screen_base = buffer->kvaddr + offset; - fbi->fix.smem_start = (unsigned long)(page_to_phys(buffer->pages[0]) + - offset); + fbi->fix.smem_start = (unsigned long) + (page_to_phys(sg_page(buffer->sgt->sgl)) + offset); fbi->screen_size = size; fbi->fix.smem_len = size; -- 1.7.0.4

2 1

[PATCH 1/4] drm/crtc: Remove redundant NULL check before kfree
by Sachin Kamat 22 Nov '12

22 Nov '12

kfree() on a NULL input is a no-op. Hence remove the check. Signed-off-by: Sachin Kamat <sachin.kamat(a)linaro.org> --- This series is build tested on the latest linux-next (20121115). --- drivers/gpu/drm/drm_crtc.c | 6 ++---- 1 files changed, 2 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c index 3533609..807336a 100644 --- a/drivers/gpu/drm/drm_crtc.c +++ b/drivers/gpu/drm/drm_crtc.c @@ -470,10 +470,8 @@ void drm_crtc_cleanup(struct drm_crtc *crtc) { struct drm_device *dev = crtc->dev; - if (crtc->gamma_store) { - kfree(crtc->gamma_store); - crtc->gamma_store = NULL; - } + kfree(crtc->gamma_store); + crtc->gamma_store = NULL; drm_mode_object_put(dev, &crtc->base); list_del(&crtc->head); -- 1.7.4.1

1 5

[resend PATCH] drm/nouveau: unpin buffers before releasing to prevent lockdep warnings
by Maarten Lankhorst 22 Nov '12

22 Nov '12

This will otherwise cause a lockdep splat if reservations were a real lock type, so warn when nouveau forgets to unpin a buffer, and fix up the ones I've hit. Signed-off-by: Maarten Lankhorst <maarten.lankhorst(a)canonical.com> --- diff --git a/drivers/gpu/drm/nouveau/nouveau_abi16.c b/drivers/gpu/drm/nouveau/nouveau_abi16.c index cc79c79..acc6b08 100644 --- a/drivers/gpu/drm/nouveau/nouveau_abi16.c +++ b/drivers/gpu/drm/nouveau/nouveau_abi16.c @@ -123,6 +123,7 @@ nouveau_abi16_chan_fini(struct nouveau_abi16 *abi16, if (chan->ntfy) { nouveau_bo_vma_del(chan->ntfy, &chan->ntfy_vma); + nouveau_bo_unpin(chan->ntfy); drm_gem_object_unreference_unlocked(chan->ntfy->gem); } diff --git a/drivers/gpu/drm/nouveau/nouveau_fbcon.c b/drivers/gpu/drm/nouveau/nouveau_fbcon.c index 67a1a06..f337976 100644 --- a/drivers/gpu/drm/nouveau/nouveau_fbcon.c +++ b/drivers/gpu/drm/nouveau/nouveau_fbcon.c @@ -429,6 +429,7 @@ nouveau_fbcon_destroy(struct drm_device *dev, struct nouveau_fbdev *fbcon) if (nouveau_fb->nvbo) { nouveau_bo_unmap(nouveau_fb->nvbo); nouveau_bo_vma_del(nouveau_fb->nvbo, &nouveau_fb->vma); + nouveau_bo_unpin(nouveau_fb->nvbo); drm_gem_object_unreference_unlocked(nouveau_fb->nvbo->gem); nouveau_fb->nvbo = NULL; } diff --git a/drivers/gpu/drm/nouveau/nouveau_gem.c b/drivers/gpu/drm/nouveau/nouveau_gem.c index 5972ecd..6d8391d 100644 --- a/drivers/gpu/drm/nouveau/nouveau_gem.c +++ b/drivers/gpu/drm/nouveau/nouveau_gem.c @@ -52,7 +52,8 @@ nouveau_gem_object_del(struct drm_gem_object *gem) return; nvbo->gem = NULL; - if (unlikely(nvbo->pin_refcnt)) { + /* Lockdep hates you for doing reserve with gem object lock held */ + if (WARN_ON_ONCE(nvbo->pin_refcnt)) { nvbo->pin_refcnt = 1; nouveau_bo_unpin(nvbo); } diff --git a/drivers/gpu/drm/nouveau/nouveau_prime.c b/drivers/gpu/drm/nouveau/nouveau_prime.c index 366462c..bd785dd 100644 --- a/drivers/gpu/drm/nouveau/nouveau_prime.c +++ b/drivers/gpu/drm/nouveau/nouveau_prime.c @@ -57,10 +57,11 @@ static void nouveau_gem_dmabuf_release(struct dma_buf *dma_buf) { struct nouveau_bo *nvbo = dma_buf->priv; - if (nvbo->gem->export_dma_buf == dma_buf) { + if (nvbo->gem->export_dma_buf == dma_buf) nvbo->gem->export_dma_buf = NULL; - drm_gem_object_unreference_unlocked(nvbo->gem); - } + + nouveau_bo_unpin(nvbo); + drm_gem_object_unreference_unlocked(nvbo->gem); } static void *nouveau_gem_kmap_atomic(struct dma_buf *dma_buf, unsigned long page_num) @@ -175,13 +176,17 @@ struct dma_buf *nouveau_gem_prime_export(struct drm_device *dev, { struct nouveau_bo *nvbo = nouveau_gem_object(obj); int ret = 0; + struct dma_buf *buf; /* pin buffer into GTT */ ret = nouveau_bo_pin(nvbo, TTM_PL_FLAG_TT); if (ret) return ERR_PTR(-EINVAL); - return dma_buf_export(nvbo, &nouveau_dmabuf_ops, obj->size, flags); + buf = dma_buf_export(nvbo, &nouveau_dmabuf_ops, obj->size, flags); + if (IS_ERR(buf)) + nouveau_bo_unpin(nvbo); + return buf; } struct drm_gem_object *nouveau_gem_prime_import(struct drm_device *dev,

1 0

[pull] radeon drm-fixes-3.7
by alexdeucher＠gmail.com 21 Nov '12

21 Nov '12

From: Alex Deucher <alexander.deucher(a)amd.com> Hi Dave, A couple more small fixes for 3.7: - another evergreen_mc fix - add an AGP quirk for an old RV250 The following changes since commit 6f755116c93ca35f496ccf1910dcd28cd16713e3: Merge branch 'drm-intel-fixes' of git://people.freedesktop.org/~danvet/drm-intel into drm-fixes (2012-11-16 10:00:43 +1000) are available in the git repository at: git://people.freedesktop.org/~agd5f/linux drm-fixes-3.7 Alex Deucher (1): drm/radeon: properly track the crtc not_enabled case evergreen_mc_stop() Paul Bolle (1): radeon: add AGPMode 1 quirk for RV250 drivers/gpu/drm/radeon/evergreen.c | 2 ++ drivers/gpu/drm/radeon/radeon_agp.c | 5 ++++- 2 files changed, 6 insertions(+), 1 deletions(-)

2 1

← Newer
1
...
50
51
52
53
54
55
56
...
80
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel November 2012