[PATCH] drm/exynos: make sure that overlay data are updated
This patch removes wait_for_vblank call from exynos_drm_encoder_plane_disable function and move it to exynos_drm_encoder_plane_commit function. Disabling dma channel to each plane doens't need vblank signal to update data to real hardware. But updating overlay data to real hardware does need vblank signal. Signed-off-by: Inki Dae Signed-off-by: Kyungmin Park --- drivers/gpu/drm/exynos/exynos_drm_encoder.c | 17 +++-- 1 files changed, 7 insertions(+), 10 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_encoder.c b/drivers/gpu/drm/exynos/exynos_drm_encoder.c index 607231a..b284dea 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_encoder.c +++ b/drivers/gpu/drm/exynos/exynos_drm_encoder.c @@ -473,6 +473,13 @@ void exynos_drm_encoder_plane_commit(struct drm_encoder *encoder, void *data) if (overlay_ops && overlay_ops->commit) overlay_ops->commit(manager->dev, zpos); + + /* +* wait for vblank interrupt +* - this makes user that overlay data are updated to real hardware. +*/ + if (overlay_ops->wait_for_vblank) + overlay_ops->wait_for_vblank(manager->dev); } void exynos_drm_encoder_plane_enable(struct drm_encoder *encoder, void *data) @@ -505,14 +512,4 @@ void exynos_drm_encoder_plane_disable(struct drm_encoder *encoder, void *data) if (overlay_ops && overlay_ops->disable) overlay_ops->disable(manager->dev, zpos); - - /* -* wait for vblank interrupt -* - this makes sure that hardware overlay is disabled to avoid -* for the dma accesses to memory after gem buffer was released -* because the setting for disabling the overlay will be updated -* at vsync. -*/ - if (overlay_ops->wait_for_vblank) - overlay_ops->wait_for_vblank(manager->dev); } -- 1.7.4.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/1] media: Entities with sink pads must have at least one enabled link
On Wed, Nov 14, 2012 at 11:58:42AM +0100, Laurent Pinchart wrote: > I think my preference would go for a helper function that drivers can use, > possibly first waiting until a second driver requires this kind of checks > before implementing it. I'd like to see a driver that doesn't. Quite likelye either it has no configurable links or it's broken. :-) -- Sakari Ailus e-mail: sakari.ailus at iki.fi XMPP: sailus at retiisi.org.uk
[PATCH 1/1] media: Entities with sink pads must have at least one enabled link
Hi Sylwester, Thanks for the comments. On Wed, Nov 14, 2012 at 10:23:19AM +0100, Sylwester Nawrocki wrote: > On 11/13/2012 03:24 PM, Sakari Ailus wrote: > > Hi all, > > > > Comments would be appreciated, either positive or negative. The omap3isp > > driver does the same check itself currently, but I think this is more > > generic than that. > > > > Thanks. > > > > On Fri, Oct 26, 2012 at 10:46:17PM +0300, Sakari Ailus wrote: > >> If an entity has sink pads, at least one of them must be connected to > >> another pad with an enabled link. If a driver with multiple sink pads has > >> more strict requirements the check should be done in the driver itself. > >> > >> Just requiring one sink pad is connected with an enabled link is enough > >> API-wise: entities with sink pads with only disabled links should not be > >> allowed to stream in the first place, but also in a different operation > >> mode > >> a device might require only one of its pads connected with an active link. > >> > >> If an entity has an ability to function as a source entity another logical > >> entity connected to the aforementioned one should be used for the purpose. > > Why not leave it to individual drivers ? I'm not sure if it is a good idea > not to allow an entity with sink pads to be used as a source only. It might > be appropriate for most of the cases but likely not all. I'm inclined not to > add this requirement in the API. Just my opinion though. I'm just wondering what would be the use case for that. What comes closest is generating a test pattern, but even that should be a separate subdev: the test pattern can be enabled by enabling the link from the test pattern generator subdev. As it seems not everyone is outright happy about the idea of making this mandatory, then how about making it optional? I'd hate having a link validate function for each subdev e.g. in the OMAP 3 ISP driver that just checks that its sink pad is actually connected with an enabled link. That'd be lots of mostly useless code. If this is done in the framework, the drivers will be spared from copying this code in a number of places. Which was why I originally wrote this patch. The alternative is to re-parse the whole graph in the driver which I'd also like to avoid. One opion I can think of is to call link_validate op of struct media_entity_operations also for disabled links on entities that are connected through active links (on V4L2 to a video node right before streaming, for example). That'd make it easy to perform the check in the drivers. What do you think? -- Kind regards, Sakari Ailus e-mail: sakari.ailus at iki.fi XMPP: sailus at retiisi.org.uk
Regression due to "mm: fix-up zone present pages"
On Wed, Nov 14, 2012 at 6:09 PM, Daniel Vetter wrote: > Hi all, > > Our QA noticed a regression in one of our i915/GEM testcases in 3.7: > > https://bugs.freedesktop.org/show_bug.cgi?id=56859 > > Direct link to dmesg of the machine: > https://bugs.freedesktop.org/attachment.cgi?id=70052 Note that the > machine is 32bit, which seems to be important since Chris Wilson > confirmed the bug on his 32bit Sandybridge machine, whereas mine here > with a 64bit kernel works flawlessly. > > The testcase is gem_tiled_swapping: > > http://cgit.freedesktop.org/xorg/app/intel-gpu-tools/tree/tests/gem_tiled_swapping.c > > Quick high-level description of the workload: > > It allocates a working set larger than available memory, then fills it > by writing it through the gpu gart (required to get a linear view of > tiled buffers) and afterwards reads it to check whether anything got > corrupted. Since the working set is too large to fit into ram, this > will force all buffers through swap. We've written this testcase to > exercise the reswizzle swapin path since some platforms have a tiling > layout depending upon physical pfn (awesome feature btw), but not snb. > So within the kernel this workload simply grabs the backing storage > from shmemfs with shmem_read_mapping_page_gfp and then binds them into > the gpu pagetables (the GTT). This happens in the i915_gem_fault > fucntion. Unbinding in this workload happens either directly (if the > gem code can't get enough memory) or through our shrinker > (i915_gem_inactive_shrink). Swapout is then left to shmemfs to handle. > All the above stuff is in drivers/gpu/drm/i915_gem.c > > Testcase fails because it detects a mismatch between what has been > written and what has been read back. > > Our qa people bisected the regression to > > commit 7f1290f2f2a4d2c3f1b7ce8e87256e052ca23125 > Author: Jianguo Wu > Date: Mon Oct 8 16:33:06 2012 -0700 > > mm: fix-up zone present pages > > and confirmed the revert on top of the latest drm-intel-nightly branch > (which is based on top of 3.7-rc2 and contains the -next stuff for > 3.8). They've also tested the for-QA branch which had latest Linus > upstream merged in, which did not fix the problem. For reference the > intel trees are at (but I don't think it matters really that it's not > plain upstream, nothing really changed in the relevant i915/gem paths > compared to upstream): > > http://cgit.freedesktop.org/~danvet/drm-intel > > I have no idea how that early boot zone init fix could even corrupt > swapping in such a fashion, so ideas highly welcome. QA people are > cc'ed, and hopefully I haven't missed anyone else on the cc list. > You can take a look at this thread: [PATCH] mm: fix a regression with HIGHMEM introduced by changeset 7f1290f2f2a4d http://lkml.org/lkml/2012/11/5/866 I think it's the same problem. -- Regards, --Bob
[PATCH v2] drm/exynos: add vm_ops to specific gem mmaper
Changelog v2: call mutex_lock before drm_vm_open_locked is called. Changelog v1: This patch makes it takes a reference to gem object when specific gem mmap is requested. For this, it sets dev->driver->gem_vm_ops to vma->vm_ops. And this patch is based on exynos-drm-next-iommu branch of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos Signed-off-by: Inki Dae Signed-off-by: Kyungmin Park --- drivers/gpu/drm/exynos/exynos_drm_gem.c | 23 ++- 1 files changed, 22 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c b/drivers/gpu/drm/exynos/exynos_drm_gem.c index 50d73f1..de524d9 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_gem.c +++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c @@ -372,10 +372,13 @@ static int exynos_drm_gem_mmap_buffer(struct file *filp, struct exynos_drm_gem_obj *exynos_gem_obj = to_exynos_gem_obj(obj); struct exynos_drm_gem_buf *buffer; unsigned long vm_size; + int ret; DRM_DEBUG_KMS("%s\n", __FILE__); vma->vm_flags |= VM_IO | VM_DONTEXPAND | VM_DONTDUMP; + vma->vm_private_data = obj; + vma->vm_ops = obj->dev->driver->gem_vm_ops; update_vm_cache_attr(exynos_gem_obj, vma); @@ -391,9 +394,25 @@ static int exynos_drm_gem_mmap_buffer(struct file *filp, if (vm_size > buffer->size) return -EINVAL; - return dma_mmap_attrs(obj->dev->dev, vma, buffer->kvaddr, + ret = dma_mmap_attrs(obj->dev->dev, vma, buffer->kvaddr, buffer->dma_addr, buffer->size, &buffer->dma_attrs); + if (ret < 0) { + DRM_ERROR("failed to mmap.\n"); + return ret; + } + + /* +* take a reference to this mapping of the object. And this reference +* is unreferenced by the corresponding vm_close call. +*/ + drm_gem_object_reference(obj); + + mutex_lock(&obj->dev->struct_mutex); + drm_vm_open_locked(obj->dev, vma); + mutex_unlock(&obj->dev->struct_mutex); + + return 0; } static const struct file_operations exynos_drm_gem_fops = { @@ -426,6 +445,8 @@ int exynos_drm_gem_mmap_ioctl(struct drm_device *dev, void *data, addr = vm_mmap(obj->filp, 0, args->size, PROT_READ | PROT_WRITE, MAP_SHARED, 0); + /* restore it to drm_file object. */ + obj->filp->private_data = file_priv; drm_gem_object_unreference_unlocked(obj); if (IS_ERR((void *)addr)) -- 1.7.4.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] drm/exynos: fix overlay updating issue
Chagelog v2: Move encoder's dpms updating into exynos_drm_encoder_commit function because when crtc's dpms is updated, encoder's dpms is updated also. This would induce the issue that encoder isn't disabled after crtc is disabled. Changelog v1: This patch fixes a issue that overlay data aren't applied to real hardware when dpms off goes to on after setcrtc was requested like below, dpms off -> setcrtc -> dpms off -> dpms on For this, it makes encoder's dpms to be updated when setcrtc is requested. Signed-off-by: Inki Dae Signed-off-by: Kyungmin Park --- drivers/gpu/drm/exynos/exynos_drm_encoder.c |6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_encoder.c b/drivers/gpu/drm/exynos/exynos_drm_encoder.c index 241ad1e..607231a 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_encoder.c +++ b/drivers/gpu/drm/exynos/exynos_drm_encoder.c @@ -226,6 +226,12 @@ static void exynos_drm_encoder_commit(struct drm_encoder *encoder) * already updated or not by exynos_drm_encoder_dpms function. */ exynos_encoder->updated = true; + + /* +* In case of setcrtc, there is no way to update encoder's dpms +* so update it here. +*/ + exynos_encoder->dpms = DRM_MODE_DPMS_ON; } static void exynos_drm_encoder_disable(struct drm_encoder *encoder) -- 1.7.4.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/exynos: fix overlay updating issue
This patch fixes a issue that overlay data aren't applied to real hardware when dpms off goes to on after setcrtc was requested like below, dpms off -> setcrtc -> dpms off -> dpms on For this, it makes encoder's dpms to be updated when setcrtc is requested. Signed-off-by: Inki Dae Signed-off-by: Kyungmin Park --- drivers/gpu/drm/exynos/exynos_drm_encoder.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_encoder.c b/drivers/gpu/drm/exynos/exynos_drm_encoder.c index 241ad1e..d971c95 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_encoder.c +++ b/drivers/gpu/drm/exynos/exynos_drm_encoder.c @@ -423,6 +423,8 @@ void exynos_drm_encoder_crtc_dpms(struct drm_encoder *encoder, void *data) if (!encoder->crtc) manager->pipe = -1; } + + exynos_encoder->dpms = mode; } void exynos_drm_encoder_crtc_pipe(struct drm_encoder *encoder, void *data) -- 1.7.4.1
[Bug 50091] [BISECTED]GeForce 6150SE: system hangs on X-server start with garbled screen
https://bugzilla.kernel.org/show_bug.cgi?id=50091 Marcin Slusarz changed: What|Removed |Added CC||marcin.slusarz at gmail.com --- Comment #2 from Marcin Slusarz 2012-11-14 20:28:08 --- Please attach dmesgs from both 3.6.x and 3.7-rcLatest. What's the problem with bisection? If you can't continue because of build error, please attach it too. I hope ebb945a94bba2ce8dff7b0942ff2b3f2a52a0a69 is not a culprit... (146 files changed, 14219 insertions(+), 11099 deletions(-)) -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[RESEND][PATCH] drm/prime: drop reference on imported dma-buf come from gem
Increasing ref counts of both dma-buf and gem for imported dma-buf come from gem makes memory leak. release function of dma-buf cannot be called because f_count of dma-buf increased by importing gem and gem ref count cannot be decrease because of exported dma-buf. So I add dma_buf_put() for imported gem come from its own gem into each drivers having prime_import and prime_export capabilities. With this, only gem ref count is increased if importing gem exported from gem of same driver. Signed-off-by: Seung-Woo Kim Signed-off-by: Kyungmin.park Cc: Inki Dae Cc: Daniel Vetter Cc: Rob Clark Cc: Alex Deucher --- Mmap failiure in i915 was reported by Jani, and I think it was fixed with Dave's commit "drm/prime: add exported buffers to current fprivs imported buffer list (v2)", so I resend this patch. I can send exynos only, but this issue is common in all drm driver having both prime inport and export, IMHO, it's better to send for all drivers. drivers/gpu/drm/exynos/exynos_drm_dmabuf.c |5 + drivers/gpu/drm/i915/i915_gem_dmabuf.c |5 + drivers/gpu/drm/nouveau/nouveau_prime.c|1 + drivers/gpu/drm/radeon/radeon_prime.c |1 + drivers/staging/omapdrm/omap_gem_dmabuf.c |5 + 5 files changed, 17 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c b/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c index ae13feb..b0897c9 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c +++ b/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c @@ -211,7 +211,12 @@ struct drm_gem_object *exynos_dmabuf_prime_import(struct drm_device *drm_dev, /* is it from our device? */ if (obj->dev == drm_dev) { + /* +* Importing dmabuf exported from out own gem increases +* refcount on gem itself instead of f_count of dmabuf. +*/ drm_gem_object_reference(obj); + dma_buf_put(dma_buf); return obj; } } diff --git a/drivers/gpu/drm/i915/i915_gem_dmabuf.c b/drivers/gpu/drm/i915/i915_gem_dmabuf.c index aa308e1..32e6287 100644 --- a/drivers/gpu/drm/i915/i915_gem_dmabuf.c +++ b/drivers/gpu/drm/i915/i915_gem_dmabuf.c @@ -188,7 +188,12 @@ struct drm_gem_object *i915_gem_prime_import(struct drm_device *dev, obj = dma_buf->priv; /* is it from our device? */ if (obj->base.dev == dev) { + /* +* Importing dmabuf exported from out own gem increases +* refcount on gem itself instead of f_count of dmabuf. +*/ drm_gem_object_reference(&obj->base); + dma_buf_put(dma_buf); return &obj->base; } } diff --git a/drivers/gpu/drm/nouveau/nouveau_prime.c b/drivers/gpu/drm/nouveau/nouveau_prime.c index a25cf2c..bb653c6 100644 --- a/drivers/gpu/drm/nouveau/nouveau_prime.c +++ b/drivers/gpu/drm/nouveau/nouveau_prime.c @@ -199,6 +199,7 @@ struct drm_gem_object *nouveau_gem_prime_import(struct drm_device *dev, if (nvbo->gem) { if (nvbo->gem->dev == dev) { drm_gem_object_reference(nvbo->gem); + dma_buf_put(dma_buf); return nvbo->gem; } } diff --git a/drivers/gpu/drm/radeon/radeon_prime.c b/drivers/gpu/drm/radeon/radeon_prime.c index 6bef46a..d344a3be 100644 --- a/drivers/gpu/drm/radeon/radeon_prime.c +++ b/drivers/gpu/drm/radeon/radeon_prime.c @@ -195,6 +195,7 @@ struct drm_gem_object *radeon_gem_prime_import(struct drm_device *dev, bo = dma_buf->priv; if (bo->gem_base.dev == dev) { drm_gem_object_reference(&bo->gem_base); + dma_buf_put(dma_buf); return &bo->gem_base; } } diff --git a/drivers/staging/omapdrm/omap_gem_dmabuf.c b/drivers/staging/omapdrm/omap_gem_dmabuf.c index 42728e0..5b50eb6 100644 --- a/drivers/staging/omapdrm/omap_gem_dmabuf.c +++ b/drivers/staging/omapdrm/omap_gem_dmabuf.c @@ -207,7 +207,12 @@ struct drm_gem_object * omap_gem_prime_import(struct drm_device *dev, obj = buffer->priv; /* is it from our device? */ if (obj->dev == dev) { + /* +* Importing dmabuf exported from out own gem increases +* refcount on gem itself instead of f_count of dmabuf. +*/ drm_gem_object_reference(obj); + dma_buf_put(buffer); return obj; } } -- 1.7.4.1 ___ dri-devel mailing li
[PATCH] drm: exynos: fix for loosing display mode header during mode adjustment
2012/11/9 Rahul Sharma > This patch is to preserve the display mode header during the mode > adjustment. > Display mode header is overwritten with the adjusted mode header which is > throwing the stack dump. > > Signed-off-by: Rahul Sharma > --- > drivers/gpu/drm/exynos/exynos_hdmi.c |8 > 1 files changed, 8 insertions(+), 0 deletions(-) > > diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c > b/drivers/gpu/drm/exynos/exynos_hdmi.c > index ee110c9..c7844ea 100644 > --- a/drivers/gpu/drm/exynos/exynos_hdmi.c > +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c > @@ -1974,6 +1974,8 @@ static void hdmi_mode_fixup(void *ctx, struct > drm_connector *connector, > { > struct drm_display_mode *m; > struct hdmi_context *hdata = ctx; > + struct drm_mode_object base; > + struct list_head head; > Remove base and head, > int index; > > DRM_DEBUG_KMS("[%d] %s\n", __LINE__, __func__); > @@ -2002,7 +2004,13 @@ static void hdmi_mode_fixup(void *ctx, struct > drm_connector *connector, > if (index >= 0) { > And declare them here. Thanks, Inki Dae > DRM_INFO("desired mode doesn't exist so\n"); > DRM_INFO("use the most suitable mode among > modes.\n"); > + > + /* preserve display mode header while copying. */ > + head = adjusted_mode->head; > + base = adjusted_mode->base; > memcpy(adjusted_mode, m, sizeof(*m)); > + adjusted_mode->head = head; > + adjusted_mode->base = base; > break; > } > } > -- > 1.7.0.4 > > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel > -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121114/66f05448/attachment.html>
[PATCH 2/2] drm/exynos: release fb pended by page flip
This patch releases the fb pended by page flip after fbdev is restored propely. And fixes invalid memory access when drm is released while doing pageflip. This patch makes fb's refcount to be increased when setcrtc and pageflip are requested. In other words, it increases fb's refcount only if dma is going to access memory region to fb and decreases old fb's because the old fb isn't accessed by dma anymore. This could guarantee releasing gem buffer to the fb after dma access to the gem buffer has been completed. Signed-off-by: Inki Dae Signed-off-by: Kyungmin Park --- drivers/gpu/drm/exynos/exynos_drm_crtc.c | 42 - drivers/gpu/drm/exynos/exynos_drm_fb.c| 23 drivers/gpu/drm/exynos/exynos_drm_fb.h|6 drivers/gpu/drm/exynos/exynos_drm_fbdev.c |9 ++ drivers/gpu/drm/exynos/exynos_drm_plane.c | 18 +++- 5 files changed, 96 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c b/drivers/gpu/drm/exynos/exynos_drm_crtc.c index 2efa4b0..2a52b7e 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c +++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c @@ -32,6 +32,7 @@ #include "exynos_drm_drv.h" #include "exynos_drm_encoder.h" #include "exynos_drm_plane.h" +#include "exynos_drm_fb.h" #define to_exynos_crtc(x) container_of(x, struct exynos_drm_crtc,\ drm_crtc) @@ -137,8 +138,26 @@ exynos_drm_crtc_mode_set(struct drm_crtc *crtc, struct drm_display_mode *mode, return ret; plane->crtc = crtc; + + /* +* If old_fb exists, unreference the fb. +* +* This means that memory region to the fb isn't accessed by the dma +* of this plane anymore. +*/ + if (old_fb) + drm_framebuffer_unreference(old_fb); + plane->fb = crtc->fb; + /* +* Take a reference to new fb. +* +* Taking a reference means that this plane's dma is going to access +* memory region to the new fb. +*/ + drm_framebuffer_reference(plane->fb); + exynos_drm_fn_encoder(crtc, &pipe, exynos_drm_encoder_crtc_pipe); return 0; @@ -168,6 +187,24 @@ static int exynos_drm_crtc_mode_set_base(struct drm_crtc *crtc, int x, int y, x, y, crtc_w, crtc_h); if (ret) return ret; + /* +* If old_fb exists, unreference the fb. +* +* This means that memory region to the fb isn't accessed by the dma +* of this plane anymore. +*/ + if (old_fb) + drm_framebuffer_unreference(old_fb); + + plane->fb = crtc->fb; + + /* +* Take a reference to new fb. +* +* Taking a reference means that this plane's dma is going to access +* memory region to the new fb. +*/ + drm_framebuffer_reference(plane->fb); exynos_drm_crtc_commit(crtc); @@ -243,7 +280,7 @@ static int exynos_drm_crtc_page_flip(struct drm_crtc *crtc, crtc->fb = fb; ret = exynos_drm_crtc_mode_set_base(crtc, crtc->x, crtc->y, - NULL); + old_fb); if (ret) { crtc->fb = old_fb; @@ -254,6 +291,9 @@ static int exynos_drm_crtc_page_flip(struct drm_crtc *crtc, goto out; } + + exynos_drm_fb_set_pending(old_fb, false); + exynos_drm_fb_set_pending(fb, true); } out: mutex_unlock(&dev->struct_mutex); diff --git a/drivers/gpu/drm/exynos/exynos_drm_fb.c b/drivers/gpu/drm/exynos/exynos_drm_fb.c index 4ef4cd3..f100035 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_fb.c +++ b/drivers/gpu/drm/exynos/exynos_drm_fb.c @@ -43,11 +43,15 @@ * @fb: drm framebuffer obejct. * @buf_cnt: a buffer count to drm framebuffer. * @exynos_gem_obj: array of exynos specific gem object containing a gem object. + * @pending: indicate whehter a fb was pended by page flip. + * if true, the fb should be released after fbdev is restored to avoid + * accessing invalid memory region. */ struct exynos_drm_fb { struct drm_framebuffer fb; unsigned intbuf_cnt; struct exynos_drm_gem_obj *exynos_gem_obj[MAX_FB_BUFFER]; + boolpending; }; static void exynos_drm_fb_destroy(struct drm_framebuffer *fb) @@ -228,6 +232,25 @@ exynos_user_fb_create(struct drm_device *dev, struct drm_file *file_priv, return fb; } +void exynos_drm_fb_set_pending(struct drm_framebuffer *fb, bool pending) +{ + struct exynos_drm_fb *exynos_fb; + + exynos_fb = to_exynos_fb(fb); + + exynos_fb->pending = pending; +} + +void exynos_drm_release_pended_fb(struct drm_framebuffer *fb) +{ + struct exynos_drm_fb *exynos_f
[PATCH 1/2] drm/exynos: remove unnecessary code.
plane->fb will be set to new fb after update_plane callback is called by drm_mode_set_plane() Signed-off-by: Inki Dae Signed-off-by: Kyungmin Park --- drivers/gpu/drm/exynos/exynos_drm_plane.c |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_plane.c b/drivers/gpu/drm/exynos/exynos_drm_plane.c index 60b877a..862ca1e 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_plane.c +++ b/drivers/gpu/drm/exynos/exynos_drm_plane.c @@ -204,7 +204,6 @@ exynos_update_plane(struct drm_plane *plane, struct drm_crtc *crtc, return ret; plane->crtc = crtc; - plane->fb = crtc->fb; exynos_plane_commit(plane); exynos_plane_dpms(plane, DRM_MODE_DPMS_ON); -- 1.7.4.1
[PATCH 0/2] drm/exynos: fix invalid memory access
This patch releases the fb pended by page flip after fbdev is restored propely. And fixes invalid memory access when drm is released while doing pageflip. This patch makes fb's refcount to be increased when setcrtc and pageflip are requested. In other words, it increases fb's refcount only if dma is going to access memory region to fb and decreases old fb's because the old fb isn't accessed by dma anymore. This could guarantee releasing gem buffer to the fb after dma access to the gem buffer has been completed. Inki Dae (2): drm/exynos: remove unnecessary code. drm/exynos: release fb pended by page flip drivers/gpu/drm/exynos/exynos_drm_crtc.c | 42 - drivers/gpu/drm/exynos/exynos_drm_fb.c| 23 drivers/gpu/drm/exynos/exynos_drm_fb.h|6 drivers/gpu/drm/exynos/exynos_drm_fbdev.c |9 ++ drivers/gpu/drm/exynos/exynos_drm_plane.c | 19 +++- 5 files changed, 96 insertions(+), 3 deletions(-) -- 1.7.4.1
Re: please add datasheet URL to dri.freedesktop.org/wiki/SMedia
On Wed, 2012-11-14 at 14:52 -0800, Eric Anholt wrote: > I noticed this marked todo in my mail. I've added you to the dri.fdo > edit group. Great, thanks! I've updated the wiki page to point at the datasheets. Since I noticed that you are using GPG, some OpenPGP best practices: https://we.riseup.net/riseuplabs+paow/openpgp-best-practices Your key violates at least "self-signatures must not use SHA1". -- bye, pabs http://bonedaddy.net/pabs3/ signature.asc Description: This is a digitally signed message part ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/1] media: Entities with sink pads must have at least one enabled link
On Wed, Nov 14, 2012 at 11:58:42AM +0100, Laurent Pinchart wrote: > I think my preference would go for a helper function that drivers can use, > possibly first waiting until a second driver requires this kind of checks > before implementing it. I'd like to see a driver that doesn't. Quite likelye either it has no configurable links or it's broken. :-) -- Sakari Ailus e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/1] media: Entities with sink pads must have at least one enabled link
Hi Sylwester, Thanks for the comments. On Wed, Nov 14, 2012 at 10:23:19AM +0100, Sylwester Nawrocki wrote: > On 11/13/2012 03:24 PM, Sakari Ailus wrote: > > Hi all, > > > > Comments would be appreciated, either positive or negative. The omap3isp > > driver does the same check itself currently, but I think this is more > > generic than that. > > > > Thanks. > > > > On Fri, Oct 26, 2012 at 10:46:17PM +0300, Sakari Ailus wrote: > >> If an entity has sink pads, at least one of them must be connected to > >> another pad with an enabled link. If a driver with multiple sink pads has > >> more strict requirements the check should be done in the driver itself. > >> > >> Just requiring one sink pad is connected with an enabled link is enough > >> API-wise: entities with sink pads with only disabled links should not be > >> allowed to stream in the first place, but also in a different operation > >> mode > >> a device might require only one of its pads connected with an active link. > >> > >> If an entity has an ability to function as a source entity another logical > >> entity connected to the aforementioned one should be used for the purpose. > > Why not leave it to individual drivers ? I'm not sure if it is a good idea > not to allow an entity with sink pads to be used as a source only. It might > be appropriate for most of the cases but likely not all. I'm inclined not to > add this requirement in the API. Just my opinion though. I'm just wondering what would be the use case for that. What comes closest is generating a test pattern, but even that should be a separate subdev: the test pattern can be enabled by enabling the link from the test pattern generator subdev. As it seems not everyone is outright happy about the idea of making this mandatory, then how about making it optional? I'd hate having a link validate function for each subdev e.g. in the OMAP 3 ISP driver that just checks that its sink pad is actually connected with an enabled link. That'd be lots of mostly useless code. If this is done in the framework, the drivers will be spared from copying this code in a number of places. Which was why I originally wrote this patch. The alternative is to re-parse the whole graph in the driver which I'd also like to avoid. One opion I can think of is to call link_validate op of struct media_entity_operations also for disabled links on entities that are connected through active links (on V4L2 to a video node right before streaming, for example). That'd make it easy to perform the check in the drivers. What do you think? -- Kind regards, Sakari Ailus e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: linux-next: Tree for Nov 14 (gpu/drm/i915)
On 11/13/2012 09:30 PM, Stephen Rothwell wrote: > Hi all, > > News: next-20121115 (i.e. tomorrow) will be the last release until > next-20121126 (which should be just be after -rc7, I guess - assuming > that Linus does not release v3.7 before then), so if you want something > in linux-next for a reasonable amount of testing, it should probably be > committed tomorrow. > > Changes since 20121113: > on i386: ERROR: "__build_bug_on_failed" [drivers/gpu/drm/i915/i915.ko] undefined! Reference to that symbol is found in i915_gem_execbuffer.o. Reference to BUILD_BUG_ON() is found in i915_gem_execbuffer.c: static struct eb_objects * eb_create(int size) { struct eb_objects *eb; int count = PAGE_SIZE / sizeof(struct hlist_head) / 2; BUILD_BUG_ON(!is_power_of_2(PAGE_SIZE / sizeof(struct hlist_head))); -- ~Randy ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Regression due to "mm: fix-up zone present pages"
On Wed, Nov 14, 2012 at 6:09 PM, Daniel Vetter wrote: > Hi all, > > Our QA noticed a regression in one of our i915/GEM testcases in 3.7: > > https://bugs.freedesktop.org/show_bug.cgi?id=56859 > > Direct link to dmesg of the machine: > https://bugs.freedesktop.org/attachment.cgi?id=70052 Note that the > machine is 32bit, which seems to be important since Chris Wilson > confirmed the bug on his 32bit Sandybridge machine, whereas mine here > with a 64bit kernel works flawlessly. > > The testcase is gem_tiled_swapping: > > http://cgit.freedesktop.org/xorg/app/intel-gpu-tools/tree/tests/gem_tiled_swapping.c > > Quick high-level description of the workload: > > It allocates a working set larger than available memory, then fills it > by writing it through the gpu gart (required to get a linear view of > tiled buffers) and afterwards reads it to check whether anything got > corrupted. Since the working set is too large to fit into ram, this > will force all buffers through swap. We've written this testcase to > exercise the reswizzle swapin path since some platforms have a tiling > layout depending upon physical pfn (awesome feature btw), but not snb. > So within the kernel this workload simply grabs the backing storage > from shmemfs with shmem_read_mapping_page_gfp and then binds them into > the gpu pagetables (the GTT). This happens in the i915_gem_fault > fucntion. Unbinding in this workload happens either directly (if the > gem code can't get enough memory) or through our shrinker > (i915_gem_inactive_shrink). Swapout is then left to shmemfs to handle. > All the above stuff is in drivers/gpu/drm/i915_gem.c > > Testcase fails because it detects a mismatch between what has been > written and what has been read back. > > Our qa people bisected the regression to > > commit 7f1290f2f2a4d2c3f1b7ce8e87256e052ca23125 > Author: Jianguo Wu > Date: Mon Oct 8 16:33:06 2012 -0700 > > mm: fix-up zone present pages > > and confirmed the revert on top of the latest drm-intel-nightly branch > (which is based on top of 3.7-rc2 and contains the -next stuff for > 3.8). They've also tested the for-QA branch which had latest Linus > upstream merged in, which did not fix the problem. For reference the > intel trees are at (but I don't think it matters really that it's not > plain upstream, nothing really changed in the relevant i915/gem paths > compared to upstream): > > http://cgit.freedesktop.org/~danvet/drm-intel > > I have no idea how that early boot zone init fix could even corrupt > swapping in such a fashion, so ideas highly welcome. QA people are > cc'ed, and hopefully I haven't missed anyone else on the cc list. > You can take a look at this thread: [PATCH] mm: fix a regression with HIGHMEM introduced by changeset 7f1290f2f2a4d http://lkml.org/lkml/2012/11/5/866 I think it's the same problem. -- Regards, --Bob ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/1] media: Entities with sink pads must have at least one enabled link
Hi Sakari, On Wednesday 14 November 2012 23:13:45 Sakari Ailus wrote: > On Wed, Nov 14, 2012 at 10:23:19AM +0100, Sylwester Nawrocki wrote: > > On 11/13/2012 03:24 PM, Sakari Ailus wrote: > > > Hi all, > > > > > > Comments would be appreciated, either positive or negative. The omap3isp > > > driver does the same check itself currently, but I think this is more > > > generic than that. > > > > > > Thanks. > > > > > > On Fri, Oct 26, 2012 at 10:46:17PM +0300, Sakari Ailus wrote: > > >> If an entity has sink pads, at least one of them must be connected to > > >> another pad with an enabled link. If a driver with multiple sink pads > > >> has more strict requirements the check should be done in the driver > > >> itself. > > >> > > >> Just requiring one sink pad is connected with an enabled link is enough > > >> API-wise: entities with sink pads with only disabled links should not > > >> be allowed to stream in the first place, but also in a different > > >> operation mode a device might require only one of its pads connected > > >> with an active link. > > >> > > >> If an entity has an ability to function as a source entity another > > >> logical entity connected to the aforementioned one should be used for > > >> the purpose. > > > > Why not leave it to individual drivers ? I'm not sure if it is a good idea > > not to allow an entity with sink pads to be used as a source only. It > > might be appropriate for most of the cases but likely not all. I'm > > inclined not to add this requirement in the API. Just my opinion though. > > I'm just wondering what would be the use case for that. > > What comes closest is generating a test pattern, but even that should be a > separate subdev: the test pattern can be enabled by enabling the link from > the test pattern generator subdev. That would force creating a separate subdev just to support test pattern generation, I'm not sure if I want to push for that. There might also be other use cases not related to V4L (thus the cross-posting). > As it seems not everyone is outright happy about the idea of making this > mandatory, then how about making it optional? > > I'd hate having a link validate function for each subdev e.g. in the OMAP 3 > ISP driver that just checks that its sink pad is actually connected with an > enabled link. That'd be lots of mostly useless code. Agreed. > If this is done in the framework, the drivers will be spared from copying > this code in a number of places. Which was why I originally wrote this > patch. The alternative is to re-parse the whole graph in the driver which > I'd also like to avoid. I'd also prefer to avoid that *if*possible*, as we already walk the graph during link validation. > One opion I can think of is to call link_validate op of struct > media_entity_operations also for disabled links on entities that are > connected through active links (on V4L2 to a video node right before > streaming, for example). > > That'd make it easy to perform the check in the drivers. > > What do you think? I think that would be a bit too complex. Drivers (or the V4L core) would need to gather data from multiple links in some state object to find out if the complete pipeline is valid or not. Another option would be to set a flag somewhere to indicate whether the check should be performed by the media core or left to drivers. As different types of drivers might need different types of checks, I think I would prefer for now to walk the graph one more time in the OMAP3 ISP driver, as currently done, and revisit this issue when we will have a couple of drivers implementing pipeline validity checks. I'm just a bit uncomfortable adding core code for a feature that has a single user at the moment without a clear view regarding how it would scale. -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/omap: Fix usage of IS_ERR_OR_NULL and PTR_ERR
On Wed, Nov 14, 2012 at 11:22:37AM -0600, Andy Gross wrote: > Return -ENOMEM if dmm_txn_init cannot allocate a refill engine. > > v2: Fix typing issue seen with newer compilers > > Signed-off-by: Andy Gross > Signed-off-by: Rob Clark > --- > drivers/staging/omapdrm/omap_dmm_tiler.c |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) This doesn't apply anymore, care to refresh it against my latest tree? thanks, greg k-h ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] drm/omap: Fix usage of IS_ERR_OR_NULL and PTR_ERR
On Wed, Nov 14, 2012 at 11:22:37AM -0600, Andy Gross wrote: > Return -ENOMEM if dmm_txn_init cannot allocate a refill engine. > > v2: Fix typing issue seen with newer compilers > > Signed-off-by: Andy Gross > Signed-off-by: Rob Clark > --- > drivers/staging/omapdrm/omap_dmm_tiler.c |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) This doesn't apply anymore, care to refresh it against my latest tree? thanks, greg k-h
[Bug 56865] Mesa 9.0 extremely slow and produces fading output on radeon Evergreen
https://bugs.freedesktop.org/show_bug.cgi?id=56865 --- Comment #19 from Alex Deucher --- (In reply to comment #18) > > As far as I understand, expected usage of MLAA with Mesa is to enable it > > only for the applications where you want it (games etc) with either > > app-specific drirc settings or environment variables. > It is probably so. A **huge** problem for me is a common lack of > documentation. I'm okay with English and not too lazy to read but I could > hardly find what to read, though. I mean - relevant while not obsolete. > Things usually work in default configuration, which may not be optimal for > some cases, and if I want to do something about it - this is where troubles > begin - for me and maybe for developers who have to answer my sometimes > stupid questions. All this video stuff looks so complicated and chaotic for > me due to lack of documentation... I even did not comprehend if mesa is > commonly responsible only for 3D rendering how comes erroneously enabled > MLAA blurs fonts, too. Fonts currently are rendered by DDX driver, aren't > they? MLAA affects all rendering that goes through OpenGL. While the text rendering for non-GL X apps may be rendered by the ddx using xrendr, the pixmaps end up going though OpenGL if you are using an OpenGL compositor (gnome shell/compiz/kwin/etc.). When the application window is composited to the front buffer by the OpenGL compositor, the MLAA is applied. -- 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/20121114/7c743efe/attachment.html>
[Bug 56865] Mesa 9.0 extremely slow and produces fading output on radeon Evergreen
https://bugs.freedesktop.org/show_bug.cgi?id=56865 --- Comment #18 from ka.nick at mail.ru --- (In reply to comment #17) > I suspect that it works as intended though it's not what one might expect > comparing to similar options in proprietary drivers. I think you're completely right. In my case the issue was provoked by two things: first, the program I use (GTK driconf o.9.1) suggests MLAA to be set to 8 as default value (however, resets it to 0 by default), and second, that it did not actually work for me in mesa 8.0. So I was misled a little bit after I installed mesa 9... > As far as I understand, expected usage of MLAA with Mesa is to enable it > only for the applications where you want it (games etc) with either > app-specific drirc settings or environment variables. It is probably so. A **huge** problem for me is a common lack of documentation. I'm okay with English and not too lazy to read but I could hardly find what to read, though. I mean - relevant while not obsolete. Things usually work in default configuration, which may not be optimal for some cases, and if I want to do something about it - this is where troubles begin - for me and maybe for developers who have to answer my sometimes stupid questions. All this video stuff looks so complicated and chaotic for me due to lack of documentation... I even did not comprehend if mesa is commonly responsible only for 3D rendering how comes erroneously enabled MLAA blurs fonts, too. Fonts currently are rendered by DDX driver, aren't they? > So I don't think it's a bug, though perhaps it would be nice to make Mesa > behave more like other drivers. Or at least, make things documented somehow. Currently the tuning knobs are spread across three areas: drirc (which is created somehow, or not, often beyond the user control); environment variables (hardly documented), Xorg.conf. Oh yes, there is fourth: USE flags/.configure options. A little bit to complicated... Just the same, thank you guys for what you do. -- 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/20121114/500ba688/attachment.html>
[Bug 56139] [bisected] kernel 3.7.0-rc1 breaks 6950 (boot/grub2 and suspend/resume) (CAYMAN)
https://bugs.freedesktop.org/show_bug.cgi?id=56139 --- Comment #31 from Alexandre Demers --- Here are the videos. Sorry, they were recorded with my iPod and they are inverted. Normal boot sequence before the culprit commit (kernel 3.6) http://www.filedropper.com/k36 A normal boot sequence with kernel 3.6 from grub 2 to booting console. Resolution is kept from grub to console, there is no sync problem and no purple flicker. A problematic boot with kernel 3.7-rc5 using gfxpayload=keep in Grub 2. http://www.filedropper.com/k37keep It starts normally, the booting console uses the same resolution as Grub 2. However, possibly when radeon driver kicks in, there is a purple flicker followed by a wrong (badly synced) display (shifted by about half a screen to the right). The result could have been a black screen, a couple of interlaced vertical lines or a different shifted display. A non problematic boot with kernel 3.7-rc5 using gfxpayload=text in Grub 2. http://www.filedropper.com/k37text It doesn't show the purple flicker we see in the previous video, it just flickers as a normal boot would do, but it does show the purple color from time to time. However, the display is OK. A problematic suspend/resume sequence with 3.7-rc5 (gfxpayload doesn't change anything) http://www.filedropper.com/k37suspend Going in suspend mode just after booting up. When resuming, X/gdm briefly appears, then it crashes. The computer continue to run, but the display stays black and no input can be used (tried to switch console and reboot but it doesn't work). Often, it will reboot by itself after some time. Suspend and resume work great before the culprit commit or if I remove the changes in "...mc_stop()" -- 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/20121114/23d4af52/attachment-0001.html>
[PATCH] drm/radeon: fix logic error in atombios_encoders.c
On Mit, 2012-11-14 at 09:13 -0500, alexdeucher at gmail.com wrote: > From: Alex Deucher > > Fixes: > https://bugzilla.kernel.org/show_bug.cgi?id=50431 > > Reported-by: David Binderman > Signed-off-by: Alex Deucher > Cc: stable at vger.kernel.org Reviewed-by: Michel D?nzer > drivers/gpu/drm/radeon/atombios_encoders.c |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/drivers/gpu/drm/radeon/atombios_encoders.c > b/drivers/gpu/drm/radeon/atombios_encoders.c > index ba498f8..010bae1 100644 > --- a/drivers/gpu/drm/radeon/atombios_encoders.c > +++ b/drivers/gpu/drm/radeon/atombios_encoders.c > @@ -1625,7 +1625,7 @@ radeon_atom_encoder_dpms_dig(struct drm_encoder > *encoder, int mode) > atombios_dig_transmitter_setup(encoder, > ATOM_TRANSMITTER_ACTION_SETUP, 0, 0); > atombios_dig_transmitter_setup(encoder, > ATOM_TRANSMITTER_ACTION_ENABLE, 0, 0); > /* some early dce3.2 boards have a bug in their > transmitter control table */ > - if ((rdev->family != CHIP_RV710) || (rdev->family != > CHIP_RV730)) > + if ((rdev->family != CHIP_RV710) && (rdev->family != > CHIP_RV730)) Ouch, the compiler didn't warn about this always evaluating to true? -- Earthling Michel D?nzer | http://www.amd.com Libre software enthusiast | Debian, X and DRI developer
[PATCH v9 5/6] drm_modes: add videomode helpers
On Wed, Nov 14, 2012 at 01:49:44PM +0100, Thierry Reding wrote: > On Wed, Nov 14, 2012 at 12:43:22PM +0100, Steffen Trumtrar wrote: > [...] > > diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c > [...] > > @@ -504,6 +505,41 @@ drm_gtf_mode(struct drm_device *dev, int hdisplay, int > > vdisplay, int vrefresh, > > } > > EXPORT_SYMBOL(drm_gtf_mode); > > > > +#if IS_ENABLED(CONFIG_VIDEOMODE) > > +int display_mode_from_videomode(struct videomode *vm, struct > > drm_display_mode *dmode) > > Given that this is still a DRM core function, maybe it should get a drm_ > prefix? Also the line is too long, so you may want to wrap the argument > list. > > Thierry Yes, seems to fit better to the rest of the file. Regards, Steffen -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
[PATCH v9 3/6] fbmon: add videomode helpers
On Wed, Nov 14, 2012 at 01:12:07PM +0100, Thierry Reding wrote: > On Wed, Nov 14, 2012 at 12:43:20PM +0100, Steffen Trumtrar wrote: > > Add a function to convert from the generic videomode to a fb_videomode. > > > > Signed-off-by: Steffen Trumtrar > > --- > > drivers/video/fbmon.c | 38 ++ > > include/linux/fb.h|5 + > > 2 files changed, 43 insertions(+) > > > > diff --git a/drivers/video/fbmon.c b/drivers/video/fbmon.c > > index cef6557..cccef17 100644 > > --- a/drivers/video/fbmon.c > > +++ b/drivers/video/fbmon.c > > @@ -31,6 +31,7 @@ > > #include > > #include > > #include > > +#include > > #ifdef CONFIG_PPC_OF > > #include > > #include > > @@ -1373,6 +1374,43 @@ int fb_get_mode(int flags, u32 val, struct > > fb_var_screeninfo *var, struct fb_inf > > kfree(timings); > > return err; > > } > > + > > +#if IS_ENABLED(CONFIG_VIDEOMODE) > > +int fb_videomode_from_videomode(struct videomode *vm, struct fb_videomode > > *fbmode) > > +{ > > + fbmode->xres = vm->hactive; > > + fbmode->left_margin = vm->hback_porch; > > + fbmode->right_margin = vm->hfront_porch; > > + fbmode->hsync_len = vm->hsync_len; > > + > > + fbmode->yres = vm->vactive; > > + fbmode->upper_margin = vm->vback_porch; > > + fbmode->lower_margin = vm->vfront_porch; > > + fbmode->vsync_len = vm->vsync_len; > > + > > + fbmode->pixclock = KHZ2PICOS(vm->pixelclock / 1000); > > + > > + fbmode->sync = 0; > > + fbmode->vmode = 0; > > + if (vm->hah) > > + fbmode->sync |= FB_SYNC_HOR_HIGH_ACT; > > + if (vm->vah) > > + fbmode->sync |= FB_SYNC_VERT_HIGH_ACT; > > + if (vm->interlaced) > > + fbmode->vmode |= FB_VMODE_INTERLACED; > > + if (vm->doublescan) > > + fbmode->vmode |= FB_VMODE_DOUBLE; > > + if (vm->de) > > + fbmode->sync |= FB_SYNC_DATA_ENABLE_HIGH_ACT; > > + fbmode->refresh = (vm->pixelclock*1000) / (vm->hactive * vm->vactive); > > CodingStyle that you should have spaces around '*'. Also I'm not sure if > that formula is correct. Shouldn't the blanking intervals be counted as > well? So: > > unsigned int htotal = vm->hactive + vm->hfront_porch + > vm->hback_porch + vm->hsync_len; > unsigned int vtotal = vm->vactive + vm->vfront_porch + > vm->vback_porch + vm->vsync_len; > > fbmode->refresh = (vm->pixelclock * 1000) / (htotal * vtotal); > > ? > Sounds correct. Done. > > + fbmode->flag = 0; > > + > > + return 0; > > +} > > +EXPORT_SYMBOL_GPL(fb_videomode_from_videomode); > > +#endif > > + > > + > > Gratuitous blank line. > > > #else > > int fb_parse_edid(unsigned char *edid, struct fb_var_screeninfo *var) > > { > > diff --git a/include/linux/fb.h b/include/linux/fb.h > > index c7a9571..6a3a675 100644 > > --- a/include/linux/fb.h > > +++ b/include/linux/fb.h > > @@ -14,6 +14,7 @@ > > #include > > #include > > #include > > +#include > > > > struct vm_area_struct; > > struct fb_info; > > @@ -714,6 +715,10 @@ extern void fb_destroy_modedb(struct fb_videomode > > *modedb); > > extern int fb_find_mode_cvt(struct fb_videomode *mode, int margins, int > > rb); > > extern unsigned char *fb_ddc_read(struct i2c_adapter *adapter); > > > > +#if IS_ENABLED(CONFIG_VIDEOMODE) > > +extern int fb_videomode_from_videomode(struct videomode *vm, > > + struct fb_videomode *fbmode); > > +#endif > > /* drivers/video/modedb.c */ > > These in turn could use an extra blank line. > > Thierry > ___ > devicetree-discuss mailing list > devicetree-discuss at lists.ozlabs.org > https://lists.ozlabs.org/listinfo/devicetree-discuss -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
Re: please add datasheet URL to dri.freedesktop.org/wiki/SMedia
Paul Wise writes: > Hi all, > > Sean from OpenMoko recently released the SMedia Glamo datasheets[1]. > Could someone with permission add them to the wiki page[2]? > > My account (PaulWise) does not appear to be able to edit the page. > > 1. http://people.openmoko.org/sean/datasheets/glamo3362/ > 2. http://dri.freedesktop.org/wiki/SMedia I noticed this marked todo in my mail. I've added you to the dri.fdo edit group. pgpfqUhLsuwLB.pgp Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
please add datasheet URL to dri.freedesktop.org/wiki/SMedia
Paul Wise writes: > Hi all, > > Sean from OpenMoko recently released the SMedia Glamo datasheets[1]. > Could someone with permission add them to the wiki page[2]? > > My account (PaulWise) does not appear to be able to edit the page. > > 1. http://people.openmoko.org/sean/datasheets/glamo3362/ > 2. http://dri.freedesktop.org/wiki/SMedia I noticed this marked todo in my mail. I've added you to the dri.fdo edit group. -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121114/97dbdfdf/attachment.pgp>
[PATCH v2] drm/omap: Fix usage of IS_ERR_OR_NULL and PTR_ERR
On Wed, Nov 14, 2012 at 11:22 AM, Andy Gross wrote: > Return -ENOMEM if dmm_txn_init cannot allocate a refill engine. > > v2: Fix typing issue seen with newer compilers > > Signed-off-by: Andy Gross Signed-off-by: Rob Clark --- > drivers/staging/omapdrm/omap_dmm_tiler.c |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/drivers/staging/omapdrm/omap_dmm_tiler.c > b/drivers/staging/omapdrm/omap_dmm_tiler.c > index 3ae3955..1499521 100644 > --- a/drivers/staging/omapdrm/omap_dmm_tiler.c > +++ b/drivers/staging/omapdrm/omap_dmm_tiler.c > @@ -279,7 +279,7 @@ static int fill(struct tcm_area *area, struct page > **pages, > > txn = dmm_txn_init(omap_dmm, area->tcm); > if (IS_ERR_OR_NULL(txn)) > - return PTR_ERR(txn); > + return -ENOMEM; > > tcm_for_each_slice(slice, *area, area_s) { > struct pat_area p_area = { > -- > 1.7.5.4 > > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 50091] [BISECTED]GeForce 6150SE: system hangs on X-server start with garbled screen
https://bugzilla.kernel.org/show_bug.cgi?id=50091 Alan changed: What|Removed |Added Summary|GeForce 6150SE: system |[BISECTED]GeForce 6150SE: |hangs on X-server start |system hangs on X-server |with garbled screen |start with garbled screen -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[PATCH v9 2/6] video: add of helper for videomode
On Wed, Nov 14, 2012 at 01:00:45PM +0100, Thierry Reding wrote: > On Wed, Nov 14, 2012 at 12:43:19PM +0100, Steffen Trumtrar wrote: > [...] > > +display-timings bindings > > + > > + > > +display timings node > > I didn't express myself very clearly here =). The way I think this > should be written is "display-timings node". > > > +required properties: > > + - hactive, vactive: Display resolution > > + - hfront-porch, hback-porch, hsync-len: Horizontal Display timing > > parameters > > + in pixels > > + vfront-porch, vback-porch, vsync-len: Vertical display timing > > parameters in > > + lines > > + - clock-frequency: displayclock in Hz > > I still think "displayclock" should be two words: "display clock". > > > +/** > > + * of_get_display_timings - parse all display_timing entries from a > > device_node > > + * @np: device_node with the subnodes > > + **/ > > +struct display_timings *of_get_display_timings(struct device_node *np) > > +{ > [...] > > + disp->num_timings = 0; > > + disp->native_mode = 0; > > + > > + for_each_child_of_node(timings_np, entry) { > > + struct display_timing *dt; > > + > > + dt = of_get_display_timing(entry); > > + if (!dt) { > > + /* to not encourage wrong devicetrees, fail in case of > > an error */ > > + pr_err("%s: error in timing %d\n", __func__, > > disp->num_timings+1); > > + goto timingfail; > > I believe you're still potentially leaking memory here. In case you have > 5 entries for instance, and the last one fails to parse, then this will > cause the memory allocated for the 4 correct entries to be lost. > > Can't you just call display_timings_release() in this case and then jump > to dispfail? That would still leak the native_mode device node. Maybe it > would be better to keep timingfail but modify it to free the display > timings with display_timings_release() instead? See below. > > > + } > > + > > + if (native_mode == entry) > > + disp->native_mode = disp->num_timings; > > + > > + disp->timings[disp->num_timings] = dt; > > + disp->num_timings++; > > + } > > + of_node_put(timings_np); > > + of_node_put(native_mode); > > + > > + if (disp->num_timings > 0) > > + pr_info("%s: got %d timings. Using timing #%d as default\n", > > __func__, > > + disp->num_timings , disp->native_mode + 1); > > + else { > > + pr_err("%s: no valid timings specified\n", __func__); > > + display_timings_release(disp); > > + return NULL; > > + } > > + return disp; > > + > > +timingfail: > > + if (native_mode) > > + of_node_put(native_mode); > > + kfree(disp->timings); > > Call display_timings_release(disp) instead of kfree(disp->timings)? > Yes. That would be the appropriate way to fail here. Done. > > diff --git a/include/linux/of_videomode.h b/include/linux/of_videomode.h > > new file mode 100644 > > index 000..4138758 > > --- /dev/null > > +++ b/include/linux/of_videomode.h > > @@ -0,0 +1,16 @@ > > +/* > > + * Copyright 2012 Steffen Trumtrar > > + * > > + * videomode of-helpers > > + * > > + * This file is released under the GPLv2 > > + */ > > + > > +#ifndef __LINUX_OF_VIDEOMODE_H > > +#define __LINUX_OF_VIDEOMODE_H > > + > > +#include > > +#include > > + > > +int of_get_videomode(struct device_node *np, struct videomode *vm, int > > index); > > +#endif /* __LINUX_OF_VIDEOMODE_H */ > > Nit: should have a blank line before #endif. > > Thierry > ___ > devicetree-discuss mailing list > devicetree-discuss at lists.ozlabs.org > https://lists.ozlabs.org/listinfo/devicetree-discuss -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
[Bug 50431] drivers/gpu/drm/radeon/atombios_encoders.c:1628: possible bad if test
https://bugzilla.kernel.org/show_bug.cgi?id=50431 Alex Deucher changed: What|Removed |Added CC||alexdeucher at gmail.com --- Comment #1 from Alex Deucher 2012-11-14 14:13:53 --- Good catch. Thanks! Patch queued. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[PATCH v9 6/6] drm_modes: add of_videomode helpers
On Wed, Nov 14, 2012 at 12:43:23PM +0100, Steffen Trumtrar wrote: [...] > +EXPORT_SYMBOL_GPL(of_get_drm_display_mode); > +#endif > /** Nit: there should be a blank line between the last two. Thierry -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121114/b0917da7/attachment.pgp>
[Bug 50091] GeForce 6150SE: system hangs on X-server start with garbled screen
https://bugzilla.kernel.org/show_bug.cgi?id=50091 --- Comment #1 from schaefer.frank at gmx.net 2012-11-14 13:50:31 --- Last good commit is 5787640db6ae722aeadb394d480c7ca21b603e34 drm/nv04-nv40/instmem: remove use of nouveau_gpuobj_new_fake() First bad commit is ebb945a94bba2ce8dff7b0942ff2b3f2a52a0a69 drm/nouveau: port all engines to new engine module format Can't test 16 commits inbetween (70ee6f1cd6911098ddd4c11ee21b69dbe51fb3f9 to ac1499d9573f4aadd1d2beac11fe23af8ce90c24). -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[PATCH v9 5/6] drm_modes: add videomode helpers
On Wed, Nov 14, 2012 at 12:43:22PM +0100, Steffen Trumtrar wrote: [...] > diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c [...] > @@ -504,6 +505,41 @@ drm_gtf_mode(struct drm_device *dev, int hdisplay, int > vdisplay, int vrefresh, > } > EXPORT_SYMBOL(drm_gtf_mode); > > +#if IS_ENABLED(CONFIG_VIDEOMODE) > +int display_mode_from_videomode(struct videomode *vm, struct > drm_display_mode *dmode) Given that this is still a DRM core function, maybe it should get a drm_ prefix? Also the line is too long, so you may want to wrap the argument list. Thierry -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121114/476e294f/attachment.pgp>
[PATCH v9 4/6] fbmon: add of_videomode helpers
On Wed, Nov 14, 2012 at 12:43:21PM +0100, Steffen Trumtrar wrote: [...] > diff --git a/drivers/video/fbmon.c b/drivers/video/fbmon.c [...] > +#if IS_ENABLED(CONFIG_OF_VIDEOMODE) > +static void dump_fb_videomode(struct fb_videomode *m) static inline? Thierry -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121114/cc2311dd/attachment.pgp>
[PATCH v9 3/6] fbmon: add videomode helpers
On Wed, Nov 14, 2012 at 12:43:20PM +0100, Steffen Trumtrar wrote: > Add a function to convert from the generic videomode to a fb_videomode. > > Signed-off-by: Steffen Trumtrar > --- > drivers/video/fbmon.c | 38 ++ > include/linux/fb.h|5 + > 2 files changed, 43 insertions(+) > > diff --git a/drivers/video/fbmon.c b/drivers/video/fbmon.c > index cef6557..cccef17 100644 > --- a/drivers/video/fbmon.c > +++ b/drivers/video/fbmon.c > @@ -31,6 +31,7 @@ > #include > #include > #include > +#include > #ifdef CONFIG_PPC_OF > #include > #include > @@ -1373,6 +1374,43 @@ int fb_get_mode(int flags, u32 val, struct > fb_var_screeninfo *var, struct fb_inf > kfree(timings); > return err; > } > + > +#if IS_ENABLED(CONFIG_VIDEOMODE) > +int fb_videomode_from_videomode(struct videomode *vm, struct fb_videomode > *fbmode) > +{ > + fbmode->xres = vm->hactive; > + fbmode->left_margin = vm->hback_porch; > + fbmode->right_margin = vm->hfront_porch; > + fbmode->hsync_len = vm->hsync_len; > + > + fbmode->yres = vm->vactive; > + fbmode->upper_margin = vm->vback_porch; > + fbmode->lower_margin = vm->vfront_porch; > + fbmode->vsync_len = vm->vsync_len; > + > + fbmode->pixclock = KHZ2PICOS(vm->pixelclock / 1000); > + > + fbmode->sync = 0; > + fbmode->vmode = 0; > + if (vm->hah) > + fbmode->sync |= FB_SYNC_HOR_HIGH_ACT; > + if (vm->vah) > + fbmode->sync |= FB_SYNC_VERT_HIGH_ACT; > + if (vm->interlaced) > + fbmode->vmode |= FB_VMODE_INTERLACED; > + if (vm->doublescan) > + fbmode->vmode |= FB_VMODE_DOUBLE; > + if (vm->de) > + fbmode->sync |= FB_SYNC_DATA_ENABLE_HIGH_ACT; > + fbmode->refresh = (vm->pixelclock*1000) / (vm->hactive * vm->vactive); CodingStyle that you should have spaces around '*'. Also I'm not sure if that formula is correct. Shouldn't the blanking intervals be counted as well? So: unsigned int htotal = vm->hactive + vm->hfront_porch + vm->hback_porch + vm->hsync_len; unsigned int vtotal = vm->vactive + vm->vfront_porch + vm->vback_porch + vm->vsync_len; fbmode->refresh = (vm->pixelclock * 1000) / (htotal * vtotal); ? > + fbmode->flag = 0; > + > + return 0; > +} > +EXPORT_SYMBOL_GPL(fb_videomode_from_videomode); > +#endif > + > + Gratuitous blank line. > #else > int fb_parse_edid(unsigned char *edid, struct fb_var_screeninfo *var) > { > diff --git a/include/linux/fb.h b/include/linux/fb.h > index c7a9571..6a3a675 100644 > --- a/include/linux/fb.h > +++ b/include/linux/fb.h > @@ -14,6 +14,7 @@ > #include > #include > #include > +#include > > struct vm_area_struct; > struct fb_info; > @@ -714,6 +715,10 @@ extern void fb_destroy_modedb(struct fb_videomode > *modedb); > extern int fb_find_mode_cvt(struct fb_videomode *mode, int margins, int rb); > extern unsigned char *fb_ddc_read(struct i2c_adapter *adapter); > > +#if IS_ENABLED(CONFIG_VIDEOMODE) > +extern int fb_videomode_from_videomode(struct videomode *vm, > +struct fb_videomode *fbmode); > +#endif > /* drivers/video/modedb.c */ These in turn could use an extra blank line. Thierry -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121114/503e0c89/attachment.pgp>
[PATCH v9 2/6] video: add of helper for videomode
On Wed, Nov 14, 2012 at 12:43:19PM +0100, Steffen Trumtrar wrote: [...] > +optional properties: > + - native-mode: the native mode for the display, in case multiple modes are > + provided. When omitted, assume the first node is the native. I forgot: The first sentence in this description should also start with a capital letter as you terminate with a full stop. Thierry -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121114/1a73073a/attachment.pgp>
[PATCH v9 1/6] video: add display_timing and videomode
On Wed, Nov 14, 2012 at 12:43:18PM +0100, Steffen Trumtrar wrote: [...] > diff --git a/include/linux/videomode.h b/include/linux/videomode.h [...] > +int videomode_from_timing(struct display_timings *disp, struct videomode *vm, > + unsigned int index); > +#endif Nit: should have a blank line before the #endif. Thierry -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121114/d5905222/attachment.pgp>
[PATCH v9 2/6] video: add of helper for videomode
On Wed, Nov 14, 2012 at 12:43:19PM +0100, Steffen Trumtrar wrote: [...] > +display-timings bindings > + > + > +display timings node I didn't express myself very clearly here =). The way I think this should be written is "display-timings node". > +required properties: > + - hactive, vactive: Display resolution > + - hfront-porch, hback-porch, hsync-len: Horizontal Display timing parameters > + in pixels > + vfront-porch, vback-porch, vsync-len: Vertical display timing parameters > in > + lines > + - clock-frequency: displayclock in Hz I still think "displayclock" should be two words: "display clock". > +/** > + * of_get_display_timings - parse all display_timing entries from a > device_node > + * @np: device_node with the subnodes > + **/ > +struct display_timings *of_get_display_timings(struct device_node *np) > +{ [...] > + disp->num_timings = 0; > + disp->native_mode = 0; > + > + for_each_child_of_node(timings_np, entry) { > + struct display_timing *dt; > + > + dt = of_get_display_timing(entry); > + if (!dt) { > + /* to not encourage wrong devicetrees, fail in case of > an error */ > + pr_err("%s: error in timing %d\n", __func__, > disp->num_timings+1); > + goto timingfail; I believe you're still potentially leaking memory here. In case you have 5 entries for instance, and the last one fails to parse, then this will cause the memory allocated for the 4 correct entries to be lost. Can't you just call display_timings_release() in this case and then jump to dispfail? That would still leak the native_mode device node. Maybe it would be better to keep timingfail but modify it to free the display timings with display_timings_release() instead? See below. > + } > + > + if (native_mode == entry) > + disp->native_mode = disp->num_timings; > + > + disp->timings[disp->num_timings] = dt; > + disp->num_timings++; > + } > + of_node_put(timings_np); > + of_node_put(native_mode); > + > + if (disp->num_timings > 0) > + pr_info("%s: got %d timings. Using timing #%d as default\n", > __func__, > + disp->num_timings , disp->native_mode + 1); > + else { > + pr_err("%s: no valid timings specified\n", __func__); > + display_timings_release(disp); > + return NULL; > + } > + return disp; > + > +timingfail: > + if (native_mode) > + of_node_put(native_mode); > + kfree(disp->timings); Call display_timings_release(disp) instead of kfree(disp->timings)? > diff --git a/include/linux/of_videomode.h b/include/linux/of_videomode.h > new file mode 100644 > index 000..4138758 > --- /dev/null > +++ b/include/linux/of_videomode.h > @@ -0,0 +1,16 @@ > +/* > + * Copyright 2012 Steffen Trumtrar > + * > + * videomode of-helpers > + * > + * This file is released under the GPLv2 > + */ > + > +#ifndef __LINUX_OF_VIDEOMODE_H > +#define __LINUX_OF_VIDEOMODE_H > + > +#include > +#include > + > +int of_get_videomode(struct device_node *np, struct videomode *vm, int > index); > +#endif /* __LINUX_OF_VIDEOMODE_H */ Nit: should have a blank line before #endif. Thierry -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121114/a129718a/attachment.pgp>
[PATCH v9 6/6] drm_modes: add of_videomode helpers
Add helper to get drm_display_mode from devicetree. Signed-off-by: Steffen Trumtrar --- drivers/gpu/drm/drm_modes.c | 35 ++- include/drm/drmP.h |6 ++ 2 files changed, 40 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c index 42ea099..c3ae5d2 100644 --- a/drivers/gpu/drm/drm_modes.c +++ b/drivers/gpu/drm/drm_modes.c @@ -35,7 +35,8 @@ #include #include #include -#include +#include +#include /** * drm_mode_debug_printmodeline - debug print a mode @@ -540,6 +541,38 @@ int display_mode_from_videomode(struct videomode *vm, struct drm_display_mode *d EXPORT_SYMBOL_GPL(display_mode_from_videomode); #endif +#if IS_ENABLED(CONFIG_OF_VIDEOMODE) +/** + * of_get_drm_display_mode - get a drm_display_mode from devicetree + * @np: device_node with the timing specification + * @dmode: will be set to the return value + * @index: index into the list of display timings in devicetree + * + * This function is expensive and should only be used, if only one mode is to be + * read from DT. To get multiple modes start with of_get_display_timings and + * work with that instead. + */ +int of_get_drm_display_mode(struct device_node *np, struct drm_display_mode *dmode, + unsigned int index) +{ + struct videomode vm; + int ret; + + ret = of_get_videomode(np, &vm, index); + if (ret) + return ret; + + display_mode_from_videomode(&vm, dmode); + + pr_info("%s: got %dx%d display mode from %s\n", __func__, vm.hactive, + vm.vactive, np->name); + drm_mode_debug_printmodeline(dmode); + + return 0; + +} +EXPORT_SYMBOL_GPL(of_get_drm_display_mode); +#endif /** * drm_mode_set_name - set the name on a mode * @mode: name will be set in this mode diff --git a/include/drm/drmP.h b/include/drm/drmP.h index 1e0d846..e8f46a1 100644 --- a/include/drm/drmP.h +++ b/include/drm/drmP.h @@ -56,6 +56,7 @@ #include #include #include +#include #include #if defined(__alpha__) || defined(__powerpc__) #include/* For pte_wrprotect */ @@ -1459,6 +1460,11 @@ drm_mode_create_from_cmdline_mode(struct drm_device *dev, extern int display_mode_from_videomode(struct videomode *vm, struct drm_display_mode *dmode); #endif +#if IS_ENABLED(CONFIG_OF_VIDEOMODE) +extern int of_get_drm_display_mode(struct device_node *np, + struct drm_display_mode *dmode, + unsigned int index); +#endif /* Modesetting support */ extern void drm_vblank_pre_modeset(struct drm_device *dev, int crtc); -- 1.7.10.4
[PATCH v9 5/6] drm_modes: add videomode helpers
Add conversion from videomode to drm_display_mode Signed-off-by: Steffen Trumtrar --- drivers/gpu/drm/drm_modes.c | 36 include/drm/drmP.h |6 ++ 2 files changed, 42 insertions(+) diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c index 59450f3..42ea099 100644 --- a/drivers/gpu/drm/drm_modes.c +++ b/drivers/gpu/drm/drm_modes.c @@ -35,6 +35,7 @@ #include #include #include +#include /** * drm_mode_debug_printmodeline - debug print a mode @@ -504,6 +505,41 @@ drm_gtf_mode(struct drm_device *dev, int hdisplay, int vdisplay, int vrefresh, } EXPORT_SYMBOL(drm_gtf_mode); +#if IS_ENABLED(CONFIG_VIDEOMODE) +int display_mode_from_videomode(struct videomode *vm, struct drm_display_mode *dmode) +{ + dmode->hdisplay = vm->hactive; + dmode->hsync_start = dmode->hdisplay + vm->hfront_porch; + dmode->hsync_end = dmode->hsync_start + vm->hsync_len; + dmode->htotal = dmode->hsync_end + vm->hback_porch; + + dmode->vdisplay = vm->vactive; + dmode->vsync_start = dmode->vdisplay + vm->vfront_porch; + dmode->vsync_end = dmode->vsync_start + vm->vsync_len; + dmode->vtotal = dmode->vsync_end + vm->vback_porch; + + dmode->clock = vm->pixelclock / 1000; + + dmode->flags = 0; + if (vm->hah) + dmode->flags |= DRM_MODE_FLAG_PHSYNC; + else + dmode->flags |= DRM_MODE_FLAG_NHSYNC; + if (vm->vah) + dmode->flags |= DRM_MODE_FLAG_PVSYNC; + else + dmode->flags |= DRM_MODE_FLAG_NVSYNC; + if (vm->interlaced) + dmode->flags |= DRM_MODE_FLAG_INTERLACE; + if (vm->doublescan) + dmode->flags |= DRM_MODE_FLAG_DBLSCAN; + drm_mode_set_name(dmode); + + return 0; +} +EXPORT_SYMBOL_GPL(display_mode_from_videomode); +#endif + /** * drm_mode_set_name - set the name on a mode * @mode: name will be set in this mode diff --git a/include/drm/drmP.h b/include/drm/drmP.h index 3fd8280..1e0d846 100644 --- a/include/drm/drmP.h +++ b/include/drm/drmP.h @@ -56,6 +56,7 @@ #include #include #include +#include #if defined(__alpha__) || defined(__powerpc__) #include/* For pte_wrprotect */ #endif @@ -1454,6 +1455,11 @@ extern struct drm_display_mode * drm_mode_create_from_cmdline_mode(struct drm_device *dev, struct drm_cmdline_mode *cmd); +#if IS_ENABLED(CONFIG_VIDEOMODE) +extern int display_mode_from_videomode(struct videomode *vm, + struct drm_display_mode *dmode); +#endif + /* Modesetting support */ extern void drm_vblank_pre_modeset(struct drm_device *dev, int crtc); extern void drm_vblank_post_modeset(struct drm_device *dev, int crtc); -- 1.7.10.4
[PATCH v9 4/6] fbmon: add of_videomode helpers
Add helper to get fb_videomode from devicetree. Signed-off-by: Steffen Trumtrar --- drivers/video/fbmon.c | 42 +- include/linux/fb.h|6 ++ 2 files changed, 47 insertions(+), 1 deletion(-) diff --git a/drivers/video/fbmon.c b/drivers/video/fbmon.c index cccef17..3a48abd 100644 --- a/drivers/video/fbmon.c +++ b/drivers/video/fbmon.c @@ -31,7 +31,7 @@ #include #include #include -#include +#include #ifdef CONFIG_PPC_OF #include #include @@ -1410,6 +1410,46 @@ int fb_videomode_from_videomode(struct videomode *vm, struct fb_videomode *fbmod EXPORT_SYMBOL_GPL(fb_videomode_from_videomode); #endif +#if IS_ENABLED(CONFIG_OF_VIDEOMODE) +static void dump_fb_videomode(struct fb_videomode *m) +{ + pr_debug("fb_videomode = %ux%u@%uHz (%ukHz) %u %u %u %u %u %u %u %u %u\n", +m->xres, m->yres, m->refresh, m->pixclock, m->left_margin, +m->right_margin, m->upper_margin, m->lower_margin, +m->hsync_len, m->vsync_len, m->sync, m->vmode, m->flag); +} + +/** + * of_get_fb_videomode - get a fb_videomode from devicetree + * @np: device_node with the timing specification + * @fb: will be set to the return value + * @index: index into the list of display timings in devicetree + * + * DESCRIPTION: + * This function is expensive and should only be used, if only one mode is to be + * read from DT. To get multiple modes start with of_get_display_timings ond + * work with that instead. + */ +int of_get_fb_videomode(struct device_node *np, struct fb_videomode *fb, + unsigned int index) +{ + struct videomode vm; + int ret; + + ret = of_get_videomode(np, &vm, index); + if (ret) + return ret; + + fb_videomode_from_videomode(&vm, fb); + + pr_info("%s: got %dx%d display mode from %s\n", __func__, vm.hactive, + vm.vactive, np->name); + dump_fb_videomode(fb); + + return 0; +} +EXPORT_SYMBOL_GPL(of_get_fb_videomode); +#endif #else int fb_parse_edid(unsigned char *edid, struct fb_var_screeninfo *var) diff --git a/include/linux/fb.h b/include/linux/fb.h index 6a3a675..8aeece8 100644 --- a/include/linux/fb.h +++ b/include/linux/fb.h @@ -15,6 +15,8 @@ #include #include #include +#include +#include struct vm_area_struct; struct fb_info; @@ -715,6 +717,10 @@ extern void fb_destroy_modedb(struct fb_videomode *modedb); extern int fb_find_mode_cvt(struct fb_videomode *mode, int margins, int rb); extern unsigned char *fb_ddc_read(struct i2c_adapter *adapter); +#if IS_ENABLED(CONFIG_OF_VIDEOMODE) +extern int of_get_fb_videomode(struct device_node *np, struct fb_videomode *fb, + unsigned int index); +#endif #if IS_ENABLED(CONFIG_VIDEOMODE) extern int fb_videomode_from_videomode(struct videomode *vm, struct fb_videomode *fbmode); -- 1.7.10.4
[PATCH v9 3/6] fbmon: add videomode helpers
Add a function to convert from the generic videomode to a fb_videomode. Signed-off-by: Steffen Trumtrar --- drivers/video/fbmon.c | 38 ++ include/linux/fb.h|5 + 2 files changed, 43 insertions(+) diff --git a/drivers/video/fbmon.c b/drivers/video/fbmon.c index cef6557..cccef17 100644 --- a/drivers/video/fbmon.c +++ b/drivers/video/fbmon.c @@ -31,6 +31,7 @@ #include #include #include +#include #ifdef CONFIG_PPC_OF #include #include @@ -1373,6 +1374,43 @@ int fb_get_mode(int flags, u32 val, struct fb_var_screeninfo *var, struct fb_inf kfree(timings); return err; } + +#if IS_ENABLED(CONFIG_VIDEOMODE) +int fb_videomode_from_videomode(struct videomode *vm, struct fb_videomode *fbmode) +{ + fbmode->xres = vm->hactive; + fbmode->left_margin = vm->hback_porch; + fbmode->right_margin = vm->hfront_porch; + fbmode->hsync_len = vm->hsync_len; + + fbmode->yres = vm->vactive; + fbmode->upper_margin = vm->vback_porch; + fbmode->lower_margin = vm->vfront_porch; + fbmode->vsync_len = vm->vsync_len; + + fbmode->pixclock = KHZ2PICOS(vm->pixelclock / 1000); + + fbmode->sync = 0; + fbmode->vmode = 0; + if (vm->hah) + fbmode->sync |= FB_SYNC_HOR_HIGH_ACT; + if (vm->vah) + fbmode->sync |= FB_SYNC_VERT_HIGH_ACT; + if (vm->interlaced) + fbmode->vmode |= FB_VMODE_INTERLACED; + if (vm->doublescan) + fbmode->vmode |= FB_VMODE_DOUBLE; + if (vm->de) + fbmode->sync |= FB_SYNC_DATA_ENABLE_HIGH_ACT; + fbmode->refresh = (vm->pixelclock*1000) / (vm->hactive * vm->vactive); + fbmode->flag = 0; + + return 0; +} +EXPORT_SYMBOL_GPL(fb_videomode_from_videomode); +#endif + + #else int fb_parse_edid(unsigned char *edid, struct fb_var_screeninfo *var) { diff --git a/include/linux/fb.h b/include/linux/fb.h index c7a9571..6a3a675 100644 --- a/include/linux/fb.h +++ b/include/linux/fb.h @@ -14,6 +14,7 @@ #include #include #include +#include struct vm_area_struct; struct fb_info; @@ -714,6 +715,10 @@ extern void fb_destroy_modedb(struct fb_videomode *modedb); extern int fb_find_mode_cvt(struct fb_videomode *mode, int margins, int rb); extern unsigned char *fb_ddc_read(struct i2c_adapter *adapter); +#if IS_ENABLED(CONFIG_VIDEOMODE) +extern int fb_videomode_from_videomode(struct videomode *vm, + struct fb_videomode *fbmode); +#endif /* drivers/video/modedb.c */ #define VESA_MODEDB_SIZE 34 extern void fb_var_to_videomode(struct fb_videomode *mode, -- 1.7.10.4
[PATCH v9 2/6] video: add of helper for videomode
This adds support for reading display timings from DT or/and convert one of those timings to a videomode. The of_display_timing implementation supports multiple children where each property can have up to 3 values. All children are read into an array, that can be queried. of_get_videomode converts exactly one of that timings to a struct videomode. Signed-off-by: Steffen Trumtrar Signed-off-by: Philipp Zabel Acked-by: Stephen Warren --- .../devicetree/bindings/video/display-timings.txt | 107 ++ drivers/video/Kconfig | 13 ++ drivers/video/Makefile |2 + drivers/video/of_display_timing.c | 211 drivers/video/of_videomode.c | 47 + include/linux/of_display_timings.h | 20 ++ include/linux/of_videomode.h | 16 ++ 7 files changed, 416 insertions(+) create mode 100644 Documentation/devicetree/bindings/video/display-timings.txt create mode 100644 drivers/video/of_display_timing.c create mode 100644 drivers/video/of_videomode.c create mode 100644 include/linux/of_display_timings.h create mode 100644 include/linux/of_videomode.h diff --git a/Documentation/devicetree/bindings/video/display-timings.txt b/Documentation/devicetree/bindings/video/display-timings.txt new file mode 100644 index 000..c9d9e1b --- /dev/null +++ b/Documentation/devicetree/bindings/video/display-timings.txt @@ -0,0 +1,107 @@ +display-timings bindings + + +display timings node + + +required properties: + - none + +optional properties: + - native-mode: the native mode for the display, in case multiple modes are + provided. When omitted, assume the first node is the native. + +timings subnode +--- + +required properties: + - hactive, vactive: Display resolution + - hfront-porch, hback-porch, hsync-len: Horizontal Display timing parameters + in pixels + vfront-porch, vback-porch, vsync-len: Vertical display timing parameters in + lines + - clock-frequency: displayclock in Hz + +optional properties: + - hsync-active: Hsync pulse is active low/high/ignored + - vsync-active: Vsync pulse is active low/high/ignored + - de-active: Data-Enable pulse is active low/high/ignored + - pixelclk-inverted: pixelclock is inverted/non-inverted/ignored + - interlaced (bool) + - doublescan (bool) + +All the optional properties that are not bool follow the following logic: +<1>: high active +<0>: low active +omitted: not used on hardware + +There are different ways of describing the capabilities of a display. The devicetree +representation corresponds to the one commonly found in datasheets for displays. +If a display supports multiple signal timings, the native-mode can be specified. + +The parameters are defined as + +struct display_timing += + + +--+-+--+---+ + | |?| | | + | ||vback_porch | | | + | |?| | | + +--###--+---+ + | #?# | | + | #|# | | + | hback #|# hfront | hsync | + | porch #| hactive # porch | len | + |<>#<---+--->#<>|<->| + | #|# | | + | #|vactive # | | + | #|# | | + | #?# | | + +--###--+---+ + | |?| | | + | ||vfront_porch| | | + | |?| | | + +--+-+--+---+ + | |?| | | + | ||vsync_len | | | + | |?| | | + +--+-+--+---+ + + +Example: + + display-timings { + native-mode = <&timing0>; + timing0: 1920p24 { + /* 1920x1080p24 */ + clock-
[PATCH v9 1/6] video: add display_timing and videomode
Add display_timing structure and the according helper functions. This allows the description of a display via its supported timing parameters. Every timing parameter can be specified as a single value or a range . Also, add helper functions to convert from display timings to a generic videomode structure. This videomode can then be converted to the corresponding subsystem mode representation (e.g. fb_videomode). Signed-off-by: Steffen Trumtrar --- drivers/video/Kconfig |6 drivers/video/Makefile |2 ++ drivers/video/display_timing.c | 24 ++ drivers/video/videomode.c | 45 ++ include/linux/display_timing.h | 69 include/linux/videomode.h | 39 +++ 6 files changed, 185 insertions(+) create mode 100644 drivers/video/display_timing.c create mode 100644 drivers/video/videomode.c create mode 100644 include/linux/display_timing.h create mode 100644 include/linux/videomode.h diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig index d08d799..2a23b18 100644 --- a/drivers/video/Kconfig +++ b/drivers/video/Kconfig @@ -33,6 +33,12 @@ config VIDEO_OUTPUT_CONTROL This framework adds support for low-level control of the video output switch. +config DISPLAY_TIMING + bool + +config VIDEOMODE + bool + menuconfig FB tristate "Support for frame buffer devices" ---help--- diff --git a/drivers/video/Makefile b/drivers/video/Makefile index 23e948e..fc30439 100644 --- a/drivers/video/Makefile +++ b/drivers/video/Makefile @@ -167,3 +167,5 @@ obj-$(CONFIG_FB_VIRTUAL) += vfb.o #video output switch sysfs driver obj-$(CONFIG_VIDEO_OUTPUT_CONTROL) += output.o +obj-$(CONFIG_DISPLAY_TIMING) += display_timing.o +obj-$(CONFIG_VIDEOMODE) += videomode.o diff --git a/drivers/video/display_timing.c b/drivers/video/display_timing.c new file mode 100644 index 000..ac9bbbc --- /dev/null +++ b/drivers/video/display_timing.c @@ -0,0 +1,24 @@ +/* + * generic display timing functions + * + * Copyright (c) 2012 Steffen Trumtrar , Pengutronix + * + * This file is released under the GPLv2 + */ + +#include +#include +#include + +void display_timings_release(struct display_timings *disp) +{ + if (disp->timings) { + unsigned int i; + + for (i = 0; i < disp->num_timings; i++) + kfree(disp->timings[i]); + kfree(disp->timings); + } + kfree(disp); +} +EXPORT_SYMBOL_GPL(display_timings_release); diff --git a/drivers/video/videomode.c b/drivers/video/videomode.c new file mode 100644 index 000..087374a --- /dev/null +++ b/drivers/video/videomode.c @@ -0,0 +1,45 @@ +/* + * generic display timing functions + * + * Copyright (c) 2012 Steffen Trumtrar , Pengutronix + * + * This file is released under the GPLv2 + */ + +#include +#include +#include +#include +#include + +int videomode_from_timing(struct display_timings *disp, struct videomode *vm, + unsigned int index) +{ + struct display_timing *dt; + + dt = display_timings_get(disp, index); + if (!dt) + return -EINVAL; + + vm->pixelclock = display_timing_get_value(&dt->pixelclock, 0); + vm->hactive = display_timing_get_value(&dt->hactive, 0); + vm->hfront_porch = display_timing_get_value(&dt->hfront_porch, 0); + vm->hback_porch = display_timing_get_value(&dt->hback_porch, 0); + vm->hsync_len = display_timing_get_value(&dt->hsync_len, 0); + + vm->vactive = display_timing_get_value(&dt->vactive, 0); + vm->vfront_porch = display_timing_get_value(&dt->vfront_porch, 0); + vm->vback_porch = display_timing_get_value(&dt->vback_porch, 0); + vm->vsync_len = display_timing_get_value(&dt->vsync_len, 0); + + vm->vah = dt->vsync_pol_active; + vm->hah = dt->hsync_pol_active; + vm->de = dt->de_pol_active; + vm->pixelclk_pol = dt->pixelclk_pol; + + vm->interlaced = dt->interlaced; + vm->doublescan = dt->doublescan; + + return 0; +} +EXPORT_SYMBOL_GPL(videomode_from_timing); diff --git a/include/linux/display_timing.h b/include/linux/display_timing.h new file mode 100644 index 000..caee2a8 --- /dev/null +++ b/include/linux/display_timing.h @@ -0,0 +1,69 @@ +/* + * Copyright 2012 Steffen Trumtrar + * + * description of display timings + * + * This file is released under the GPLv2 + */ + +#ifndef __LINUX_DISPLAY_TIMINGS_H +#define __LINUX_DISPLAY_TIMINGS_H + +#include + +struct timing_entry { + u32 min; + u32 typ; + u32 max; +}; + +struct display_timing { + struct timing_entry pixelclock; + + struct timing_entry hactive; + struct timing_entry hfront_porch; + struct timing_entry hback_porch; + struct timing_entry hsync_len; + + struct timing_entry vactive; + struct timing_entry vfront_porch; + str
[PATCH v9 0/6] of: add display helper
Hi! Changes since v8: - fix memory leaks - change API to be more consistent (foo_from_bar(struct bar, struct foo)) - include headers were necessary - misc minor bufixes 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| 69 +++ drivers/video/Kconfig | 19 ++ drivers/video/Makefile |4 + drivers/video/display_timing.c | 24 +++ drivers/video/fbmon.c | 78 drivers/video/of_display_timing.c | 211 drivers/video/of_videomode.c | 47 + drivers/video/videomode.c | 45 + include/drm/drmP.h | 12 ++ include/linux/display_timing.h | 69 +++ include/linux/fb.h | 11 + include/linux/of_display_timings.h | 20 ++ include/linux/of_videomode.h | 16 ++ include/linux/videomode.h | 39 15 files changed, 771 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
Re: [PATCH v2] drm/omap: Fix usage of IS_ERR_OR_NULL and PTR_ERR
On Wed, Nov 14, 2012 at 11:22 AM, Andy Gross wrote: > Return -ENOMEM if dmm_txn_init cannot allocate a refill engine. > > v2: Fix typing issue seen with newer compilers > > Signed-off-by: Andy Gross Signed-off-by: Rob Clark --- > drivers/staging/omapdrm/omap_dmm_tiler.c |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/drivers/staging/omapdrm/omap_dmm_tiler.c > b/drivers/staging/omapdrm/omap_dmm_tiler.c > index 3ae3955..1499521 100644 > --- a/drivers/staging/omapdrm/omap_dmm_tiler.c > +++ b/drivers/staging/omapdrm/omap_dmm_tiler.c > @@ -279,7 +279,7 @@ static int fill(struct tcm_area *area, struct page > **pages, > > txn = dmm_txn_init(omap_dmm, area->tcm); > if (IS_ERR_OR_NULL(txn)) > - return PTR_ERR(txn); > + return -ENOMEM; > > tcm_for_each_slice(slice, *area, area_s) { > struct pat_area p_area = { > -- > 1.7.5.4 > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 50431] drivers/gpu/drm/radeon/atombios_encoders.c:1628: possible bad if test
https://bugzilla.kernel.org/show_bug.cgi?id=50431 Alan changed: What|Removed |Added CC||alan at lxorguk.ukuu.org.uk Component|Other |Video(DRI - non Intel) AssignedTo|drivers_other at kernel-bugs.o |drivers_video-dri at kernel-bu |sdl.org |gs.osdl.org -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[Bug 50091] [BISECTED]GeForce 6150SE: system hangs on X-server start with garbled screen
https://bugzilla.kernel.org/show_bug.cgi?id=50091 Marcin Slusarz changed: What|Removed |Added CC||marcin.slus...@gmail.com --- Comment #2 from Marcin Slusarz 2012-11-14 20:28:08 --- Please attach dmesgs from both 3.6.x and 3.7-rcLatest. What's the problem with bisection? If you can't continue because of build error, please attach it too. I hope ebb945a94bba2ce8dff7b0942ff2b3f2a52a0a69 is not a culprit... (146 files changed, 14219 insertions(+), 11099 deletions(-)) -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: linux-next: Tree for Nov 14 (gpu/drm/i915)
On Wed, 14 Nov 2012 11:41:49 -0800 Randy Dunlap wrote: > On 11/13/2012 09:30 PM, Stephen Rothwell wrote: > > > Hi all, > > > > News: next-20121115 (i.e. tomorrow) will be the last release until > > next-20121126 (which should be just be after -rc7, I guess - assuming > > that Linus does not release v3.7 before then), so if you want something > > in linux-next for a reasonable amount of testing, it should probably be > > committed tomorrow. > > > > Changes since 20121113: > > > > > > on i386: > > ERROR: "__build_bug_on_failed" [drivers/gpu/drm/i915/i915.ko] undefined! > > Reference to that symbol is found in > i915_gem_execbuffer.o. Reference to BUILD_BUG_ON() is found in > i915_gem_execbuffer.c: > > static struct eb_objects * > eb_create(int size) > { > struct eb_objects *eb; > int count = PAGE_SIZE / sizeof(struct hlist_head) / 2; > BUILD_BUG_ON(!is_power_of_2(PAGE_SIZE / sizeof(struct hlist_head))); > Where to start. - eb_create() has no business assuming that the hlist_head has any particular size. We could easily add some conditionally-compiled debug fields in there, and drm blows up. - The assertion is obviously true at present, so I assume that gcc screwed up and failed to reduce all that to a compile-time constant. - We have a BUILD_BUG_ON_NOT_POWER_OF_2(). Use it? - This code is using PAGE_SIZE to scale a kernel data structure. PAGE_SIZE can vary by a factor of 16, depending on Kconfig. This can result in 64k PAGE_SIZE machines exhibiting different beahviour from that which the testers saw. Don't do it. It's better to hard-wire 4096. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
linux-next: Tree for Nov 14 (gpu/drm/i915)
On Wed, 14 Nov 2012 11:41:49 -0800 Randy Dunlap wrote: > On 11/13/2012 09:30 PM, Stephen Rothwell wrote: > > > Hi all, > > > > News: next-20121115 (i.e. tomorrow) will be the last release until > > next-20121126 (which should be just be after -rc7, I guess - assuming > > that Linus does not release v3.7 before then), so if you want something > > in linux-next for a reasonable amount of testing, it should probably be > > committed tomorrow. > > > > Changes since 20121113: > > > > > > on i386: > > ERROR: "__build_bug_on_failed" [drivers/gpu/drm/i915/i915.ko] undefined! > > Reference to that symbol is found in > i915_gem_execbuffer.o. Reference to BUILD_BUG_ON() is found in > i915_gem_execbuffer.c: > > static struct eb_objects * > eb_create(int size) > { > struct eb_objects *eb; > int count = PAGE_SIZE / sizeof(struct hlist_head) / 2; > BUILD_BUG_ON(!is_power_of_2(PAGE_SIZE / sizeof(struct hlist_head))); > Where to start. - eb_create() has no business assuming that the hlist_head has any particular size. We could easily add some conditionally-compiled debug fields in there, and drm blows up. - The assertion is obviously true at present, so I assume that gcc screwed up and failed to reduce all that to a compile-time constant. - We have a BUILD_BUG_ON_NOT_POWER_OF_2(). Use it? - This code is using PAGE_SIZE to scale a kernel data structure. PAGE_SIZE can vary by a factor of 16, depending on Kconfig. This can result in 64k PAGE_SIZE machines exhibiting different beahviour from that which the testers saw. Don't do it. It's better to hard-wire 4096.
[PATCH v8 1/6] video: add display_timing and videomode
On Wed, Nov 14, 2012 at 12:10:15PM +0100, Steffen Trumtrar wrote: > On Wed, Nov 14, 2012 at 12:02:15PM +0100, Thierry Reding wrote: > > On Wed, Nov 14, 2012 at 11:59:25AM +0100, Steffen Trumtrar wrote: > > > On Wed, Nov 14, 2012 at 11:56:34AM +0100, Thierry Reding wrote: > > > > On Mon, Nov 12, 2012 at 04:37:01PM +0100, Steffen Trumtrar wrote: > > > > [...] > > > > > diff --git a/drivers/video/display_timing.c > > > > > b/drivers/video/display_timing.c > > > > [...] > > > > > +void display_timings_release(struct display_timings *disp) > > > > > +{ > > > > > + if (disp->timings) { > > > > > + unsigned int i; > > > > > + > > > > > + for (i = 0; i < disp->num_timings; i++) > > > > > + kfree(disp->timings[i]); > > > > > + kfree(disp->timings); > > > > > + } > > > > > + kfree(disp); > > > > > +} > > > > > > > > I think this is still missing an EXPORT_SYMBOL_GPL. Otherwise it can't > > > > be used from modules. > > > > > > > > Thierry > > > > > > Yes. Just in time. I was just starting to type the send-email command ;-) > > > > Great! In that case don't forget to also look at my other email before > > sending. =) > > > Sure. Besides those comments (and those from other people) I think your patchset is in pretty good shape. Have you thought about how and when you want to get things merged? Thierry -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121114/9bcd3f0a/attachment.pgp>
[PATCH v8 1/6] video: add display_timing and videomode
On Wed, Nov 14, 2012 at 12:02:15PM +0100, Thierry Reding wrote: > On Wed, Nov 14, 2012 at 11:59:25AM +0100, Steffen Trumtrar wrote: > > On Wed, Nov 14, 2012 at 11:56:34AM +0100, Thierry Reding wrote: > > > On Mon, Nov 12, 2012 at 04:37:01PM +0100, Steffen Trumtrar wrote: > > > [...] > > > > diff --git a/drivers/video/display_timing.c > > > > b/drivers/video/display_timing.c > > > [...] > > > > +void display_timings_release(struct display_timings *disp) > > > > +{ > > > > + if (disp->timings) { > > > > + unsigned int i; > > > > + > > > > + for (i = 0; i < disp->num_timings; i++) > > > > + kfree(disp->timings[i]); > > > > + kfree(disp->timings); > > > > + } > > > > + kfree(disp); > > > > +} > > > > > > I think this is still missing an EXPORT_SYMBOL_GPL. Otherwise it can't > > > be used from modules. > > > > > > Thierry > > > > Yes. Just in time. I was just starting to type the send-email command ;-) > > Great! In that case don't forget to also look at my other email before > sending. =) > Sure. -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
[PATCH v8 1/6] video: add display_timing and videomode
On Wed, Nov 14, 2012 at 11:59:25AM +0100, Steffen Trumtrar wrote: > On Wed, Nov 14, 2012 at 11:56:34AM +0100, Thierry Reding wrote: > > On Mon, Nov 12, 2012 at 04:37:01PM +0100, Steffen Trumtrar wrote: > > [...] > > > diff --git a/drivers/video/display_timing.c > > > b/drivers/video/display_timing.c > > [...] > > > +void display_timings_release(struct display_timings *disp) > > > +{ > > > + if (disp->timings) { > > > + unsigned int i; > > > + > > > + for (i = 0; i < disp->num_timings; i++) > > > + kfree(disp->timings[i]); > > > + kfree(disp->timings); > > > + } > > > + kfree(disp); > > > +} > > > > I think this is still missing an EXPORT_SYMBOL_GPL. Otherwise it can't > > be used from modules. > > > > Thierry > > Yes. Just in time. I was just starting to type the send-email command ;-) Great! In that case don't forget to also look at my other email before sending. =) Thierry -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121114/413fe4c5/attachment.pgp>
[PATCH v8 2/6] video: add of helper for videomode
On Mon, Nov 12, 2012 at 04:37:02PM +0100, Steffen Trumtrar wrote: [...] > diff --git a/include/linux/of_display_timings.h > b/include/linux/of_display_timings.h [...] > +#ifndef __LINUX_OF_DISPLAY_TIMINGS_H > +#define __LINUX_OF_DISPLAY_TIMINGS_H > + > +#include > + > +#define OF_USE_NATIVE_MODE -1 > + > +struct display_timings *of_get_display_timings(struct device_node *np); > +int of_display_timings_exists(struct device_node *np); This either needs to include linux/of.h or a forward declaration of struct device_node. Otherwise this will fail to compile if the file where this is included from doesn't pull linux/of.h in explicitly. > diff --git a/include/linux/of_videomode.h b/include/linux/of_videomode.h [...] > +#ifndef __LINUX_OF_VIDEOMODE_H > +#define __LINUX_OF_VIDEOMODE_H > + > +#include > + > +int of_get_videomode(struct device_node *np, struct videomode *vm, int > index); Same here. Thierry -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121114/0fed625a/attachment.pgp>
[PATCH v8 1/6] video: add display_timing and videomode
On Wed, Nov 14, 2012 at 11:56:34AM +0100, Thierry Reding wrote: > On Mon, Nov 12, 2012 at 04:37:01PM +0100, Steffen Trumtrar wrote: > [...] > > diff --git a/drivers/video/display_timing.c b/drivers/video/display_timing.c > [...] > > +void display_timings_release(struct display_timings *disp) > > +{ > > + if (disp->timings) { > > + unsigned int i; > > + > > + for (i = 0; i < disp->num_timings; i++) > > + kfree(disp->timings[i]); > > + kfree(disp->timings); > > + } > > + kfree(disp); > > +} > > I think this is still missing an EXPORT_SYMBOL_GPL. Otherwise it can't > be used from modules. > > Thierry Yes. Just in time. I was just starting to type the send-email command ;-) Regards, Steffen -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
[PATCH 1/1] media: Entities with sink pads must have at least one enabled link
Hi Sylwester, On Wednesday 14 November 2012 10:23:19 Sylwester Nawrocki wrote: > On 11/13/2012 03:24 PM, Sakari Ailus wrote: > > Hi all, > > > > Comments would be appreciated, either positive or negative. The omap3isp > > driver does the same check itself currently, but I think this is more > > generic than that. > > > > Thanks. > > > > On Fri, Oct 26, 2012 at 10:46:17PM +0300, Sakari Ailus wrote: > >> If an entity has sink pads, at least one of them must be connected to > >> another pad with an enabled link. If a driver with multiple sink pads has > >> more strict requirements the check should be done in the driver itself. > >> > >> Just requiring one sink pad is connected with an enabled link is enough > >> API-wise: entities with sink pads with only disabled links should not be > >> allowed to stream in the first place, but also in a different operation > >> mode a device might require only one of its pads connected with an > >> active link. > >> > >> If an entity has an ability to function as a source entity another > >> logical entity connected to the aforementioned one should be used for the > >> purpose. > > Why not leave it to individual drivers ? I'm not sure if it is a good idea > not to allow an entity with sink pads to be used as a source only. It might > be appropriate for most of the cases but likely not all. I'm inclined not to > add this requirement in the API. Just my opinion though. I have mixed feelings about this patch too, which is why I've asked Sakari to cross-post it. It's pretty easy to add this check to the core now, but pushing it back to drivers late if we realize it's too restrictive would be difficult. I think my preference would go for a helper function that drivers can use, possibly first waiting until a second driver requires this kind of checks before implementing it. -- Regards, Laurent Pinchart
[PATCH v8 1/6] video: add display_timing and videomode
On Mon, Nov 12, 2012 at 04:37:01PM +0100, Steffen Trumtrar wrote: [...] > diff --git a/drivers/video/display_timing.c b/drivers/video/display_timing.c [...] > +void display_timings_release(struct display_timings *disp) > +{ > + if (disp->timings) { > + unsigned int i; > + > + for (i = 0; i < disp->num_timings; i++) > + kfree(disp->timings[i]); > + kfree(disp->timings); > + } > + kfree(disp); > +} I think this is still missing an EXPORT_SYMBOL_GPL. Otherwise it can't be used from modules. Thierry -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121114/cff56431/attachment.pgp>
linux-next: Tree for Nov 14 (gpu/drm/i915)
On 11/13/2012 09:30 PM, Stephen Rothwell wrote: > Hi all, > > News: next-20121115 (i.e. tomorrow) will be the last release until > next-20121126 (which should be just be after -rc7, I guess - assuming > that Linus does not release v3.7 before then), so if you want something > in linux-next for a reasonable amount of testing, it should probably be > committed tomorrow. > > Changes since 20121113: > on i386: ERROR: "__build_bug_on_failed" [drivers/gpu/drm/i915/i915.ko] undefined! Reference to that symbol is found in i915_gem_execbuffer.o. Reference to BUILD_BUG_ON() is found in i915_gem_execbuffer.c: static struct eb_objects * eb_create(int size) { struct eb_objects *eb; int count = PAGE_SIZE / sizeof(struct hlist_head) / 2; BUILD_BUG_ON(!is_power_of_2(PAGE_SIZE / sizeof(struct hlist_head))); -- ~Randy
[PATCH v2] drm/omap: Fix usage of IS_ERR_OR_NULL and PTR_ERR
Return -ENOMEM if dmm_txn_init cannot allocate a refill engine. v2: Fix typing issue seen with newer compilers Signed-off-by: Andy Gross --- drivers/staging/omapdrm/omap_dmm_tiler.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/staging/omapdrm/omap_dmm_tiler.c b/drivers/staging/omapdrm/omap_dmm_tiler.c index 3ae3955..1499521 100644 --- a/drivers/staging/omapdrm/omap_dmm_tiler.c +++ b/drivers/staging/omapdrm/omap_dmm_tiler.c @@ -279,7 +279,7 @@ static int fill(struct tcm_area *area, struct page **pages, txn = dmm_txn_init(omap_dmm, area->tcm); if (IS_ERR_OR_NULL(txn)) - return PTR_ERR(txn); + return -ENOMEM; tcm_for_each_slice(slice, *area, area_s) { struct pat_area p_area = { -- 1.7.5.4
Regression due to "mm: fix-up zone present pages"
Hi all, Our QA noticed a regression in one of our i915/GEM testcases in 3.7: https://bugs.freedesktop.org/show_bug.cgi?id=56859 Direct link to dmesg of the machine: https://bugs.freedesktop.org/attachment.cgi?id=70052 Note that the machine is 32bit, which seems to be important since Chris Wilson confirmed the bug on his 32bit Sandybridge machine, whereas mine here with a 64bit kernel works flawlessly. The testcase is gem_tiled_swapping: http://cgit.freedesktop.org/xorg/app/intel-gpu-tools/tree/tests/gem_tiled_swapping.c Quick high-level description of the workload: It allocates a working set larger than available memory, then fills it by writing it through the gpu gart (required to get a linear view of tiled buffers) and afterwards reads it to check whether anything got corrupted. Since the working set is too large to fit into ram, this will force all buffers through swap. We've written this testcase to exercise the reswizzle swapin path since some platforms have a tiling layout depending upon physical pfn (awesome feature btw), but not snb. So within the kernel this workload simply grabs the backing storage from shmemfs with shmem_read_mapping_page_gfp and then binds them into the gpu pagetables (the GTT). This happens in the i915_gem_fault fucntion. Unbinding in this workload happens either directly (if the gem code can't get enough memory) or through our shrinker (i915_gem_inactive_shrink). Swapout is then left to shmemfs to handle. All the above stuff is in drivers/gpu/drm/i915_gem.c Testcase fails because it detects a mismatch between what has been written and what has been read back. Our qa people bisected the regression to commit 7f1290f2f2a4d2c3f1b7ce8e87256e052ca23125 Author: Jianguo Wu Date: Mon Oct 8 16:33:06 2012 -0700 mm: fix-up zone present pages and confirmed the revert on top of the latest drm-intel-nightly branch (which is based on top of 3.7-rc2 and contains the -next stuff for 3.8). They've also tested the for-QA branch which had latest Linus upstream merged in, which did not fix the problem. For reference the intel trees are at (but I don't think it matters really that it's not plain upstream, nothing really changed in the relevant i915/gem paths compared to upstream): http://cgit.freedesktop.org/~danvet/drm-intel I have no idea how that early boot zone init fix could even corrupt swapping in such a fashion, so ideas highly welcome. QA people are cc'ed, and hopefully I haven't missed anyone else on the cc list. Yours, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[PATCH v2 1/2] drm: Add NVIDIA Tegra20 support
On 11/14/2012 01:37 AM, Stephen Warren wrote: > On 11/13/2012 12:15 AM, Mark Zhang wrote: >> On 11/13/2012 05:55 AM, Thierry Reding wrote: >>> This commit adds a KMS driver for the Tegra20 SoC. This includes basic >>> support for host1x and the two display controllers found on the Tegra20 >>> SoC. Each display controller can drive a separate RGB/LVDS output. > > Mark, when you're replying to a long patch, it's useful to quote only > the code you're directly responding to; slowly scrolling through your > email to find your comments is rather error-prone and time-consuming. > Sure. Sorry for the inconvenience. Thanks. > Thanks for the feedback though. >
[PATCH 1/1] media: Entities with sink pads must have at least one enabled link
Hi Sakari, On 11/13/2012 03:24 PM, Sakari Ailus wrote: > Hi all, > > Comments would be appreciated, either positive or negative. The omap3isp > driver does the same check itself currently, but I think this is more > generic than that. > > Thanks. > > On Fri, Oct 26, 2012 at 10:46:17PM +0300, Sakari Ailus wrote: >> If an entity has sink pads, at least one of them must be connected to >> another pad with an enabled link. If a driver with multiple sink pads has >> more strict requirements the check should be done in the driver itself. >> >> Just requiring one sink pad is connected with an enabled link is enough >> API-wise: entities with sink pads with only disabled links should not be >> allowed to stream in the first place, but also in a different operation mode >> a device might require only one of its pads connected with an active link. >> >> If an entity has an ability to function as a source entity another logical >> entity connected to the aforementioned one should be used for the purpose. Why not leave it to individual drivers ? I'm not sure if it is a good idea not to allow an entity with sink pads to be used as a source only. It might be appropriate for most of the cases but likely not all. I'm inclined not to add this requirement in the API. Just my opinion though. -- Thanks, Sylwester
[PATCH] drm/ttm: remove unneeded preempt_disable/enable
On 11/09/2012 01:10 PM, Akinobu Mita wrote: > It is unnecessary to disable preemption explicitly while calling > copy_highpage(). Because copy_highpage() will do it again through > kmap_atomic/kunmap_atomic. > > Signed-off-by: Akinobu Mita > Cc: dri-devel at lists.freedesktop.org > Cc: David Airlie > --- > drivers/gpu/drm/ttm/ttm_tt.c | 4 > 1 file changed, 4 deletions(-) > > diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm/ttm/ttm_tt.c > index bf82601..7d759a4 100644 > --- a/drivers/gpu/drm/ttm/ttm_tt.c > +++ b/drivers/gpu/drm/ttm/ttm_tt.c > @@ -308,9 +308,7 @@ int ttm_tt_swapin(struct ttm_tt *ttm) > if (unlikely(to_page == NULL)) > goto out_err; > > - preempt_disable(); > copy_highpage(to_page, from_page); > - preempt_enable(); > page_cache_release(from_page); > } > > @@ -358,9 +356,7 @@ int ttm_tt_swapout(struct ttm_tt *ttm, struct file > *persistent_swap_storage) > ret = PTR_ERR(to_page); > goto out_err; > } > - preempt_disable(); > copy_highpage(to_page, from_page); > - preempt_enable(); > set_page_dirty(to_page); > mark_page_accessed(to_page); > page_cache_release(to_page); Reviewed-by: Thomas Hellstrom
[PATCH] ttm_get_pages() will OOPS with highmem allocation
On 11/13/2012 07:31 PM, Jonathan Morton wrote: > Reposting from this kernel bug: > https://bugzilla.kernel.org/show_bug.cgi?id=50241 > > I've tested the patch and it solves a highly repeatable OOPS with the > CedarView driver that I'm porting. > > > >From 3552913d3a1c2d3c4ce158e91dc18cd12b522cb2 Mon Sep 17 00:00:00 2001 > From: Yakui Zhao > Date: Tue, 7 Feb 2012 15:33:13 -0500 > Subject: [PATCH] Clear the ttm page allocated from high memory zone correctly > > The TTM page can be allocated from high memory. In such case it is > wrong to use the page_address(page) as the virtual address for the high memory > page. > > Signed-off-by: Zhao Yakui > --- > drivers/gpu/drm/ttm/ttm_page_alloc.c |5 - > 1 files changed, 4 insertions(+), 1 deletions(-) > > diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c > b/drivers/gpu/drm/ttm/ttm_page_alloc.c > index d948575..df976d9 100644 > --- a/drivers/gpu/drm/ttm/ttm_page_alloc.c > +++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c > @@ -708,7 +708,10 @@ int ttm_get_pages(struct list_head *pages, int flags, > /* clear the pages coming from the pool if requested */ > if (flags & TTM_PAGE_FLAG_ZERO_ALLOC) { > list_for_each_entry(p, pages, lru) { > - clear_page(page_address(p)); > + if (PageHighMem(p)) > + clear_highpage(p); > + else > + clear_page(page_address(p)); > } > } > This is a pretty bad bug. I think the only reason it hasn't been hit more often is that TTM_PAGE_FLAG_ZERO_ALLOC may not be used that often. Please resend this patch with Cc: stable at vger.kernel.org Reviewed-by: Thomas Hellstrom Thanks, Thomas
[PATCH] drm/radeon: fix logic error in atombios_encoders.c
On Wed, Nov 14, 2012 at 9:32 AM, Michel D?nzer wrote: > On Mit, 2012-11-14 at 09:13 -0500, alexdeucher at gmail.com wrote: >> From: Alex Deucher >> >> Fixes: >> https://bugzilla.kernel.org/show_bug.cgi?id=50431 >> >> Reported-by: David Binderman >> Signed-off-by: Alex Deucher >> Cc: stable at vger.kernel.org > > Reviewed-by: Michel D?nzer > > >> drivers/gpu/drm/radeon/atombios_encoders.c |2 +- >> 1 files changed, 1 insertions(+), 1 deletions(-) >> >> diff --git a/drivers/gpu/drm/radeon/atombios_encoders.c >> b/drivers/gpu/drm/radeon/atombios_encoders.c >> index ba498f8..010bae1 100644 >> --- a/drivers/gpu/drm/radeon/atombios_encoders.c >> +++ b/drivers/gpu/drm/radeon/atombios_encoders.c >> @@ -1625,7 +1625,7 @@ radeon_atom_encoder_dpms_dig(struct drm_encoder >> *encoder, int mode) >> atombios_dig_transmitter_setup(encoder, >> ATOM_TRANSMITTER_ACTION_SETUP, 0, 0); >> atombios_dig_transmitter_setup(encoder, >> ATOM_TRANSMITTER_ACTION_ENABLE, 0, 0); >> /* some early dce3.2 boards have a bug in their >> transmitter control table */ >> - if ((rdev->family != CHIP_RV710) || (rdev->family != >> CHIP_RV730)) >> + if ((rdev->family != CHIP_RV710) && (rdev->family != >> CHIP_RV730)) > > Ouch, the compiler didn't warn about this always evaluating to true? Nope. At least not on any of my machines. > > > -- > Earthling Michel D?nzer | http://www.amd.com > Libre software enthusiast | Debian, X and DRI developer
[PATCH v2] drm/omap: Fix usage of IS_ERR_OR_NULL and PTR_ERR
Return -ENOMEM if dmm_txn_init cannot allocate a refill engine. v2: Fix typing issue seen with newer compilers Signed-off-by: Andy Gross --- drivers/staging/omapdrm/omap_dmm_tiler.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/staging/omapdrm/omap_dmm_tiler.c b/drivers/staging/omapdrm/omap_dmm_tiler.c index 3ae3955..1499521 100644 --- a/drivers/staging/omapdrm/omap_dmm_tiler.c +++ b/drivers/staging/omapdrm/omap_dmm_tiler.c @@ -279,7 +279,7 @@ static int fill(struct tcm_area *area, struct page **pages, txn = dmm_txn_init(omap_dmm, area->tcm); if (IS_ERR_OR_NULL(txn)) - return PTR_ERR(txn); + return -ENOMEM; tcm_for_each_slice(slice, *area, area_s) { struct pat_area p_area = { -- 1.7.5.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/radeon: fix logic error in atombios_encoders.c
From: Alex Deucher Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=50431 Reported-by: David Binderman Signed-off-by: Alex Deucher Cc: stable at vger.kernel.org --- drivers/gpu/drm/radeon/atombios_encoders.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/radeon/atombios_encoders.c b/drivers/gpu/drm/radeon/atombios_encoders.c index ba498f8..010bae1 100644 --- a/drivers/gpu/drm/radeon/atombios_encoders.c +++ b/drivers/gpu/drm/radeon/atombios_encoders.c @@ -1625,7 +1625,7 @@ radeon_atom_encoder_dpms_dig(struct drm_encoder *encoder, int mode) atombios_dig_transmitter_setup(encoder, ATOM_TRANSMITTER_ACTION_SETUP, 0, 0); atombios_dig_transmitter_setup(encoder, ATOM_TRANSMITTER_ACTION_ENABLE, 0, 0); /* some early dce3.2 boards have a bug in their transmitter control table */ - if ((rdev->family != CHIP_RV710) || (rdev->family != CHIP_RV730)) + if ((rdev->family != CHIP_RV710) && (rdev->family != CHIP_RV730)) atombios_dig_transmitter_setup(encoder, ATOM_TRANSMITTER_ACTION_ENABLE_OUTPUT, 0, 0); } if (ENCODER_MODE_IS_DP(atombios_get_encoder_mode(encoder)) && connector) { -- 1.7.7.5
[Bug 56865] Mesa 9.0 extremely slow and produces fading output on radeon Evergreen
https://bugs.freedesktop.org/show_bug.cgi?id=56865 --- Comment #19 from Alex Deucher --- (In reply to comment #18) > > As far as I understand, expected usage of MLAA with Mesa is to enable it > > only for the applications where you want it (games etc) with either > > app-specific drirc settings or environment variables. > It is probably so. A **huge** problem for me is a common lack of > documentation. I'm okay with English and not too lazy to read but I could > hardly find what to read, though. I mean - relevant while not obsolete. > Things usually work in default configuration, which may not be optimal for > some cases, and if I want to do something about it - this is where troubles > begin - for me and maybe for developers who have to answer my sometimes > stupid questions. All this video stuff looks so complicated and chaotic for > me due to lack of documentation... I even did not comprehend if mesa is > commonly responsible only for 3D rendering how comes erroneously enabled > MLAA blurs fonts, too. Fonts currently are rendered by DDX driver, aren't > they? MLAA affects all rendering that goes through OpenGL. While the text rendering for non-GL X apps may be rendered by the ddx using xrendr, the pixmaps end up going though OpenGL if you are using an OpenGL compositor (gnome shell/compiz/kwin/etc.). When the application window is composited to the front buffer by the OpenGL compositor, the MLAA is applied. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 56865] Mesa 9.0 extremely slow and produces fading output on radeon Evergreen
https://bugs.freedesktop.org/show_bug.cgi?id=56865 --- Comment #18 from ka.n...@mail.ru --- (In reply to comment #17) > I suspect that it works as intended though it's not what one might expect > comparing to similar options in proprietary drivers. I think you're completely right. In my case the issue was provoked by two things: first, the program I use (GTK driconf o.9.1) suggests MLAA to be set to 8 as default value (however, resets it to 0 by default), and second, that it did not actually work for me in mesa 8.0. So I was misled a little bit after I installed mesa 9... > As far as I understand, expected usage of MLAA with Mesa is to enable it > only for the applications where you want it (games etc) with either > app-specific drirc settings or environment variables. It is probably so. A **huge** problem for me is a common lack of documentation. I'm okay with English and not too lazy to read but I could hardly find what to read, though. I mean - relevant while not obsolete. Things usually work in default configuration, which may not be optimal for some cases, and if I want to do something about it - this is where troubles begin - for me and maybe for developers who have to answer my sometimes stupid questions. All this video stuff looks so complicated and chaotic for me due to lack of documentation... I even did not comprehend if mesa is commonly responsible only for 3D rendering how comes erroneously enabled MLAA blurs fonts, too. Fonts currently are rendered by DDX driver, aren't they? > So I don't think it's a bug, though perhaps it would be nice to make Mesa > behave more like other drivers. Or at least, make things documented somehow. Currently the tuning knobs are spread across three areas: drirc (which is created somehow, or not, often beyond the user control); environment variables (hardly documented), Xorg.conf. Oh yes, there is fourth: USE flags/.configure options. A little bit to complicated... Just the same, thank you guys for what you do. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 56139] [bisected] kernel 3.7.0-rc1 breaks 6950 (boot/grub2 and suspend/resume) (CAYMAN)
https://bugs.freedesktop.org/show_bug.cgi?id=56139 --- Comment #31 from Alexandre Demers --- Here are the videos. Sorry, they were recorded with my iPod and they are inverted. Normal boot sequence before the culprit commit (kernel 3.6) http://www.filedropper.com/k36 A normal boot sequence with kernel 3.6 from grub 2 to booting console. Resolution is kept from grub to console, there is no sync problem and no purple flicker. A problematic boot with kernel 3.7-rc5 using gfxpayload=keep in Grub 2. http://www.filedropper.com/k37keep It starts normally, the booting console uses the same resolution as Grub 2. However, possibly when radeon driver kicks in, there is a purple flicker followed by a wrong (badly synced) display (shifted by about half a screen to the right). The result could have been a black screen, a couple of interlaced vertical lines or a different shifted display. A non problematic boot with kernel 3.7-rc5 using gfxpayload=text in Grub 2. http://www.filedropper.com/k37text It doesn't show the purple flicker we see in the previous video, it just flickers as a normal boot would do, but it does show the purple color from time to time. However, the display is OK. A problematic suspend/resume sequence with 3.7-rc5 (gfxpayload doesn't change anything) http://www.filedropper.com/k37suspend Going in suspend mode just after booting up. When resuming, X/gdm briefly appears, then it crashes. The computer continue to run, but the display stays black and no input can be used (tried to switch console and reboot but it doesn't work). Often, it will reboot by itself after some time. Suspend and resume work great before the culprit commit or if I remove the changes in "...mc_stop()" -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/radeon: fix logic error in atombios_encoders.c
On Wed, Nov 14, 2012 at 9:32 AM, Michel Dänzer wrote: > On Mit, 2012-11-14 at 09:13 -0500, alexdeuc...@gmail.com wrote: >> From: Alex Deucher >> >> Fixes: >> https://bugzilla.kernel.org/show_bug.cgi?id=50431 >> >> Reported-by: David Binderman >> Signed-off-by: Alex Deucher >> Cc: sta...@vger.kernel.org > > Reviewed-by: Michel Dänzer > > >> drivers/gpu/drm/radeon/atombios_encoders.c |2 +- >> 1 files changed, 1 insertions(+), 1 deletions(-) >> >> diff --git a/drivers/gpu/drm/radeon/atombios_encoders.c >> b/drivers/gpu/drm/radeon/atombios_encoders.c >> index ba498f8..010bae1 100644 >> --- a/drivers/gpu/drm/radeon/atombios_encoders.c >> +++ b/drivers/gpu/drm/radeon/atombios_encoders.c >> @@ -1625,7 +1625,7 @@ radeon_atom_encoder_dpms_dig(struct drm_encoder >> *encoder, int mode) >> atombios_dig_transmitter_setup(encoder, >> ATOM_TRANSMITTER_ACTION_SETUP, 0, 0); >> atombios_dig_transmitter_setup(encoder, >> ATOM_TRANSMITTER_ACTION_ENABLE, 0, 0); >> /* some early dce3.2 boards have a bug in their >> transmitter control table */ >> - if ((rdev->family != CHIP_RV710) || (rdev->family != >> CHIP_RV730)) >> + if ((rdev->family != CHIP_RV710) && (rdev->family != >> CHIP_RV730)) > > Ouch, the compiler didn't warn about this always evaluating to true? Nope. At least not on any of my machines. > > > -- > Earthling Michel Dänzer | http://www.amd.com > Libre software enthusiast | Debian, X and DRI developer ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 50091] [BISECTED]GeForce 6150SE: system hangs on X-server start with garbled screen
https://bugzilla.kernel.org/show_bug.cgi?id=50091 Alan changed: What|Removed |Added Summary|GeForce 6150SE: system |[BISECTED]GeForce 6150SE: |hangs on X-server start |system hangs on X-server |with garbled screen |start with garbled screen -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/radeon: fix logic error in atombios_encoders.c
On Mit, 2012-11-14 at 09:13 -0500, alexdeuc...@gmail.com wrote: > From: Alex Deucher > > Fixes: > https://bugzilla.kernel.org/show_bug.cgi?id=50431 > > Reported-by: David Binderman > Signed-off-by: Alex Deucher > Cc: sta...@vger.kernel.org Reviewed-by: Michel Dänzer > drivers/gpu/drm/radeon/atombios_encoders.c |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/drivers/gpu/drm/radeon/atombios_encoders.c > b/drivers/gpu/drm/radeon/atombios_encoders.c > index ba498f8..010bae1 100644 > --- a/drivers/gpu/drm/radeon/atombios_encoders.c > +++ b/drivers/gpu/drm/radeon/atombios_encoders.c > @@ -1625,7 +1625,7 @@ radeon_atom_encoder_dpms_dig(struct drm_encoder > *encoder, int mode) > atombios_dig_transmitter_setup(encoder, > ATOM_TRANSMITTER_ACTION_SETUP, 0, 0); > atombios_dig_transmitter_setup(encoder, > ATOM_TRANSMITTER_ACTION_ENABLE, 0, 0); > /* some early dce3.2 boards have a bug in their > transmitter control table */ > - if ((rdev->family != CHIP_RV710) || (rdev->family != > CHIP_RV730)) > + if ((rdev->family != CHIP_RV710) && (rdev->family != > CHIP_RV730)) Ouch, the compiler didn't warn about this always evaluating to true? -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Debian, X and DRI developer ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v9 5/6] drm_modes: add videomode helpers
On Wed, Nov 14, 2012 at 01:49:44PM +0100, Thierry Reding wrote: > On Wed, Nov 14, 2012 at 12:43:22PM +0100, Steffen Trumtrar wrote: > [...] > > diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c > [...] > > @@ -504,6 +505,41 @@ drm_gtf_mode(struct drm_device *dev, int hdisplay, int > > vdisplay, int vrefresh, > > } > > EXPORT_SYMBOL(drm_gtf_mode); > > > > +#if IS_ENABLED(CONFIG_VIDEOMODE) > > +int display_mode_from_videomode(struct videomode *vm, struct > > drm_display_mode *dmode) > > Given that this is still a DRM core function, maybe it should get a drm_ > prefix? Also the line is too long, so you may want to wrap the argument > list. > > Thierry Yes, seems to fit better to the rest of the file. Regards, Steffen -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 50431] drivers/gpu/drm/radeon/atombios_encoders.c:1628: possible bad if test
https://bugzilla.kernel.org/show_bug.cgi?id=50431 Alex Deucher changed: What|Removed |Added CC||alexdeuc...@gmail.com --- Comment #1 from Alex Deucher 2012-11-14 14:13:53 --- Good catch. Thanks! Patch queued. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/radeon: fix logic error in atombios_encoders.c
From: Alex Deucher Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=50431 Reported-by: David Binderman Signed-off-by: Alex Deucher Cc: sta...@vger.kernel.org --- drivers/gpu/drm/radeon/atombios_encoders.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/radeon/atombios_encoders.c b/drivers/gpu/drm/radeon/atombios_encoders.c index ba498f8..010bae1 100644 --- a/drivers/gpu/drm/radeon/atombios_encoders.c +++ b/drivers/gpu/drm/radeon/atombios_encoders.c @@ -1625,7 +1625,7 @@ radeon_atom_encoder_dpms_dig(struct drm_encoder *encoder, int mode) atombios_dig_transmitter_setup(encoder, ATOM_TRANSMITTER_ACTION_SETUP, 0, 0); atombios_dig_transmitter_setup(encoder, ATOM_TRANSMITTER_ACTION_ENABLE, 0, 0); /* some early dce3.2 boards have a bug in their transmitter control table */ - if ((rdev->family != CHIP_RV710) || (rdev->family != CHIP_RV730)) + if ((rdev->family != CHIP_RV710) && (rdev->family != CHIP_RV730)) atombios_dig_transmitter_setup(encoder, ATOM_TRANSMITTER_ACTION_ENABLE_OUTPUT, 0, 0); } if (ENCODER_MODE_IS_DP(atombios_get_encoder_mode(encoder)) && connector) { -- 1.7.7.5 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v9 3/6] fbmon: add videomode helpers
On Wed, Nov 14, 2012 at 01:12:07PM +0100, Thierry Reding wrote: > On Wed, Nov 14, 2012 at 12:43:20PM +0100, Steffen Trumtrar wrote: > > Add a function to convert from the generic videomode to a fb_videomode. > > > > Signed-off-by: Steffen Trumtrar > > --- > > drivers/video/fbmon.c | 38 ++ > > include/linux/fb.h|5 + > > 2 files changed, 43 insertions(+) > > > > diff --git a/drivers/video/fbmon.c b/drivers/video/fbmon.c > > index cef6557..cccef17 100644 > > --- a/drivers/video/fbmon.c > > +++ b/drivers/video/fbmon.c > > @@ -31,6 +31,7 @@ > > #include > > #include > > #include > > +#include > > #ifdef CONFIG_PPC_OF > > #include > > #include > > @@ -1373,6 +1374,43 @@ int fb_get_mode(int flags, u32 val, struct > > fb_var_screeninfo *var, struct fb_inf > > kfree(timings); > > return err; > > } > > + > > +#if IS_ENABLED(CONFIG_VIDEOMODE) > > +int fb_videomode_from_videomode(struct videomode *vm, struct fb_videomode > > *fbmode) > > +{ > > + fbmode->xres = vm->hactive; > > + fbmode->left_margin = vm->hback_porch; > > + fbmode->right_margin = vm->hfront_porch; > > + fbmode->hsync_len = vm->hsync_len; > > + > > + fbmode->yres = vm->vactive; > > + fbmode->upper_margin = vm->vback_porch; > > + fbmode->lower_margin = vm->vfront_porch; > > + fbmode->vsync_len = vm->vsync_len; > > + > > + fbmode->pixclock = KHZ2PICOS(vm->pixelclock / 1000); > > + > > + fbmode->sync = 0; > > + fbmode->vmode = 0; > > + if (vm->hah) > > + fbmode->sync |= FB_SYNC_HOR_HIGH_ACT; > > + if (vm->vah) > > + fbmode->sync |= FB_SYNC_VERT_HIGH_ACT; > > + if (vm->interlaced) > > + fbmode->vmode |= FB_VMODE_INTERLACED; > > + if (vm->doublescan) > > + fbmode->vmode |= FB_VMODE_DOUBLE; > > + if (vm->de) > > + fbmode->sync |= FB_SYNC_DATA_ENABLE_HIGH_ACT; > > + fbmode->refresh = (vm->pixelclock*1000) / (vm->hactive * vm->vactive); > > CodingStyle that you should have spaces around '*'. Also I'm not sure if > that formula is correct. Shouldn't the blanking intervals be counted as > well? So: > > unsigned int htotal = vm->hactive + vm->hfront_porch + > vm->hback_porch + vm->hsync_len; > unsigned int vtotal = vm->vactive + vm->vfront_porch + > vm->vback_porch + vm->vsync_len; > > fbmode->refresh = (vm->pixelclock * 1000) / (htotal * vtotal); > > ? > Sounds correct. Done. > > + fbmode->flag = 0; > > + > > + return 0; > > +} > > +EXPORT_SYMBOL_GPL(fb_videomode_from_videomode); > > +#endif > > + > > + > > Gratuitous blank line. > > > #else > > int fb_parse_edid(unsigned char *edid, struct fb_var_screeninfo *var) > > { > > diff --git a/include/linux/fb.h b/include/linux/fb.h > > index c7a9571..6a3a675 100644 > > --- a/include/linux/fb.h > > +++ b/include/linux/fb.h > > @@ -14,6 +14,7 @@ > > #include > > #include > > #include > > +#include > > > > struct vm_area_struct; > > struct fb_info; > > @@ -714,6 +715,10 @@ extern void fb_destroy_modedb(struct fb_videomode > > *modedb); > > extern int fb_find_mode_cvt(struct fb_videomode *mode, int margins, int > > rb); > > extern unsigned char *fb_ddc_read(struct i2c_adapter *adapter); > > > > +#if IS_ENABLED(CONFIG_VIDEOMODE) > > +extern int fb_videomode_from_videomode(struct videomode *vm, > > + struct fb_videomode *fbmode); > > +#endif > > /* drivers/video/modedb.c */ > > These in turn could use an extra blank line. > > Thierry > ___ > devicetree-discuss mailing list > devicetree-disc...@lists.ozlabs.org > https://lists.ozlabs.org/listinfo/devicetree-discuss -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 50091] GeForce 6150SE: system hangs on X-server start with garbled screen
https://bugzilla.kernel.org/show_bug.cgi?id=50091 --- Comment #1 from schaefer.fr...@gmx.net 2012-11-14 13:50:31 --- Last good commit is 5787640db6ae722aeadb394d480c7ca21b603e34 drm/nv04-nv40/instmem: remove use of nouveau_gpuobj_new_fake() First bad commit is ebb945a94bba2ce8dff7b0942ff2b3f2a52a0a69 drm/nouveau: port all engines to new engine module format Can't test 16 commits inbetween (70ee6f1cd6911098ddd4c11ee21b69dbe51fb3f9 to ac1499d9573f4aadd1d2beac11fe23af8ce90c24). -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v9 2/6] video: add of helper for videomode
On Wed, Nov 14, 2012 at 01:00:45PM +0100, Thierry Reding wrote: > On Wed, Nov 14, 2012 at 12:43:19PM +0100, Steffen Trumtrar wrote: > [...] > > +display-timings bindings > > + > > + > > +display timings node > > I didn't express myself very clearly here =). The way I think this > should be written is "display-timings node". > > > +required properties: > > + - hactive, vactive: Display resolution > > + - hfront-porch, hback-porch, hsync-len: Horizontal Display timing > > parameters > > + in pixels > > + vfront-porch, vback-porch, vsync-len: Vertical display timing > > parameters in > > + lines > > + - clock-frequency: displayclock in Hz > > I still think "displayclock" should be two words: "display clock". > > > +/** > > + * of_get_display_timings - parse all display_timing entries from a > > device_node > > + * @np: device_node with the subnodes > > + **/ > > +struct display_timings *of_get_display_timings(struct device_node *np) > > +{ > [...] > > + disp->num_timings = 0; > > + disp->native_mode = 0; > > + > > + for_each_child_of_node(timings_np, entry) { > > + struct display_timing *dt; > > + > > + dt = of_get_display_timing(entry); > > + if (!dt) { > > + /* to not encourage wrong devicetrees, fail in case of > > an error */ > > + pr_err("%s: error in timing %d\n", __func__, > > disp->num_timings+1); > > + goto timingfail; > > I believe you're still potentially leaking memory here. In case you have > 5 entries for instance, and the last one fails to parse, then this will > cause the memory allocated for the 4 correct entries to be lost. > > Can't you just call display_timings_release() in this case and then jump > to dispfail? That would still leak the native_mode device node. Maybe it > would be better to keep timingfail but modify it to free the display > timings with display_timings_release() instead? See below. > > > + } > > + > > + if (native_mode == entry) > > + disp->native_mode = disp->num_timings; > > + > > + disp->timings[disp->num_timings] = dt; > > + disp->num_timings++; > > + } > > + of_node_put(timings_np); > > + of_node_put(native_mode); > > + > > + if (disp->num_timings > 0) > > + pr_info("%s: got %d timings. Using timing #%d as default\n", > > __func__, > > + disp->num_timings , disp->native_mode + 1); > > + else { > > + pr_err("%s: no valid timings specified\n", __func__); > > + display_timings_release(disp); > > + return NULL; > > + } > > + return disp; > > + > > +timingfail: > > + if (native_mode) > > + of_node_put(native_mode); > > + kfree(disp->timings); > > Call display_timings_release(disp) instead of kfree(disp->timings)? > Yes. That would be the appropriate way to fail here. Done. > > diff --git a/include/linux/of_videomode.h b/include/linux/of_videomode.h > > new file mode 100644 > > index 000..4138758 > > --- /dev/null > > +++ b/include/linux/of_videomode.h > > @@ -0,0 +1,16 @@ > > +/* > > + * Copyright 2012 Steffen Trumtrar > > + * > > + * videomode of-helpers > > + * > > + * This file is released under the GPLv2 > > + */ > > + > > +#ifndef __LINUX_OF_VIDEOMODE_H > > +#define __LINUX_OF_VIDEOMODE_H > > + > > +#include > > +#include > > + > > +int of_get_videomode(struct device_node *np, struct videomode *vm, int > > index); > > +#endif /* __LINUX_OF_VIDEOMODE_H */ > > Nit: should have a blank line before #endif. > > Thierry > ___ > devicetree-discuss mailing list > devicetree-disc...@lists.ozlabs.org > https://lists.ozlabs.org/listinfo/devicetree-discuss -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v9 6/6] drm_modes: add of_videomode helpers
On Wed, Nov 14, 2012 at 12:43:23PM +0100, Steffen Trumtrar wrote: [...] > +EXPORT_SYMBOL_GPL(of_get_drm_display_mode); > +#endif > /** Nit: there should be a blank line between the last two. Thierry pgp8o6Hp3t2Ea.pgp Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v9 5/6] drm_modes: add videomode helpers
On Wed, Nov 14, 2012 at 12:43:22PM +0100, Steffen Trumtrar wrote: [...] > diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c [...] > @@ -504,6 +505,41 @@ drm_gtf_mode(struct drm_device *dev, int hdisplay, int > vdisplay, int vrefresh, > } > EXPORT_SYMBOL(drm_gtf_mode); > > +#if IS_ENABLED(CONFIG_VIDEOMODE) > +int display_mode_from_videomode(struct videomode *vm, struct > drm_display_mode *dmode) Given that this is still a DRM core function, maybe it should get a drm_ prefix? Also the line is too long, so you may want to wrap the argument list. Thierry pgpMscvNL6dxG.pgp Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v9 4/6] fbmon: add of_videomode helpers
On Wed, Nov 14, 2012 at 12:43:21PM +0100, Steffen Trumtrar wrote: [...] > diff --git a/drivers/video/fbmon.c b/drivers/video/fbmon.c [...] > +#if IS_ENABLED(CONFIG_OF_VIDEOMODE) > +static void dump_fb_videomode(struct fb_videomode *m) static inline? Thierry pgpumGF25FWfy.pgp Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 50431] drivers/gpu/drm/radeon/atombios_encoders.c:1628: possible bad if test
https://bugzilla.kernel.org/show_bug.cgi?id=50431 Alan changed: What|Removed |Added CC||a...@lxorguk.ukuu.org.uk Component|Other |Video(DRI - non Intel) AssignedTo|drivers_other@kernel-bugs.o |drivers_video-dri@kernel-bu |sdl.org |gs.osdl.org -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v9 3/6] fbmon: add videomode helpers
On Wed, Nov 14, 2012 at 12:43:20PM +0100, Steffen Trumtrar wrote: > Add a function to convert from the generic videomode to a fb_videomode. > > Signed-off-by: Steffen Trumtrar > --- > drivers/video/fbmon.c | 38 ++ > include/linux/fb.h|5 + > 2 files changed, 43 insertions(+) > > diff --git a/drivers/video/fbmon.c b/drivers/video/fbmon.c > index cef6557..cccef17 100644 > --- a/drivers/video/fbmon.c > +++ b/drivers/video/fbmon.c > @@ -31,6 +31,7 @@ > #include > #include > #include > +#include > #ifdef CONFIG_PPC_OF > #include > #include > @@ -1373,6 +1374,43 @@ int fb_get_mode(int flags, u32 val, struct > fb_var_screeninfo *var, struct fb_inf > kfree(timings); > return err; > } > + > +#if IS_ENABLED(CONFIG_VIDEOMODE) > +int fb_videomode_from_videomode(struct videomode *vm, struct fb_videomode > *fbmode) > +{ > + fbmode->xres = vm->hactive; > + fbmode->left_margin = vm->hback_porch; > + fbmode->right_margin = vm->hfront_porch; > + fbmode->hsync_len = vm->hsync_len; > + > + fbmode->yres = vm->vactive; > + fbmode->upper_margin = vm->vback_porch; > + fbmode->lower_margin = vm->vfront_porch; > + fbmode->vsync_len = vm->vsync_len; > + > + fbmode->pixclock = KHZ2PICOS(vm->pixelclock / 1000); > + > + fbmode->sync = 0; > + fbmode->vmode = 0; > + if (vm->hah) > + fbmode->sync |= FB_SYNC_HOR_HIGH_ACT; > + if (vm->vah) > + fbmode->sync |= FB_SYNC_VERT_HIGH_ACT; > + if (vm->interlaced) > + fbmode->vmode |= FB_VMODE_INTERLACED; > + if (vm->doublescan) > + fbmode->vmode |= FB_VMODE_DOUBLE; > + if (vm->de) > + fbmode->sync |= FB_SYNC_DATA_ENABLE_HIGH_ACT; > + fbmode->refresh = (vm->pixelclock*1000) / (vm->hactive * vm->vactive); CodingStyle that you should have spaces around '*'. Also I'm not sure if that formula is correct. Shouldn't the blanking intervals be counted as well? So: unsigned int htotal = vm->hactive + vm->hfront_porch + vm->hback_porch + vm->hsync_len; unsigned int vtotal = vm->vactive + vm->vfront_porch + vm->vback_porch + vm->vsync_len; fbmode->refresh = (vm->pixelclock * 1000) / (htotal * vtotal); ? > + fbmode->flag = 0; > + > + return 0; > +} > +EXPORT_SYMBOL_GPL(fb_videomode_from_videomode); > +#endif > + > + Gratuitous blank line. > #else > int fb_parse_edid(unsigned char *edid, struct fb_var_screeninfo *var) > { > diff --git a/include/linux/fb.h b/include/linux/fb.h > index c7a9571..6a3a675 100644 > --- a/include/linux/fb.h > +++ b/include/linux/fb.h > @@ -14,6 +14,7 @@ > #include > #include > #include > +#include > > struct vm_area_struct; > struct fb_info; > @@ -714,6 +715,10 @@ extern void fb_destroy_modedb(struct fb_videomode > *modedb); > extern int fb_find_mode_cvt(struct fb_videomode *mode, int margins, int rb); > extern unsigned char *fb_ddc_read(struct i2c_adapter *adapter); > > +#if IS_ENABLED(CONFIG_VIDEOMODE) > +extern int fb_videomode_from_videomode(struct videomode *vm, > +struct fb_videomode *fbmode); > +#endif > /* drivers/video/modedb.c */ These in turn could use an extra blank line. Thierry pgpJZZSAp8yHi.pgp Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/exynos: fix overlay updating issue
This patch fixes a issue that overlay data aren't applied to real hardware when dpms off goes to on after setcrtc was requested like below, dpms off -> setcrtc -> dpms off -> dpms on For this, it makes encoder's dpms to be updated when setcrtc is requested. Signed-off-by: Inki Dae Signed-off-by: Kyungmin Park --- drivers/gpu/drm/exynos/exynos_drm_encoder.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_encoder.c b/drivers/gpu/drm/exynos/exynos_drm_encoder.c index 241ad1e..d971c95 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_encoder.c +++ b/drivers/gpu/drm/exynos/exynos_drm_encoder.c @@ -423,6 +423,8 @@ void exynos_drm_encoder_crtc_dpms(struct drm_encoder *encoder, void *data) if (!encoder->crtc) manager->pipe = -1; } + + exynos_encoder->dpms = mode; } void exynos_drm_encoder_crtc_pipe(struct drm_encoder *encoder, void *data) -- 1.7.4.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v9 2/6] video: add of helper for videomode
On Wed, Nov 14, 2012 at 12:43:19PM +0100, Steffen Trumtrar wrote: [...] > +optional properties: > + - native-mode: the native mode for the display, in case multiple modes are > + provided. When omitted, assume the first node is the native. I forgot: The first sentence in this description should also start with a capital letter as you terminate with a full stop. Thierry pgpOOVHi4jp3O.pgp Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v9 1/6] video: add display_timing and videomode
On Wed, Nov 14, 2012 at 12:43:18PM +0100, Steffen Trumtrar wrote: [...] > diff --git a/include/linux/videomode.h b/include/linux/videomode.h [...] > +int videomode_from_timing(struct display_timings *disp, struct videomode *vm, > + unsigned int index); > +#endif Nit: should have a blank line before the #endif. Thierry pgpTCd7avRF49.pgp Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v9 2/6] video: add of helper for videomode
On Wed, Nov 14, 2012 at 12:43:19PM +0100, Steffen Trumtrar wrote: [...] > +display-timings bindings > + > + > +display timings node I didn't express myself very clearly here =). The way I think this should be written is "display-timings node". > +required properties: > + - hactive, vactive: Display resolution > + - hfront-porch, hback-porch, hsync-len: Horizontal Display timing parameters > + in pixels > + vfront-porch, vback-porch, vsync-len: Vertical display timing parameters > in > + lines > + - clock-frequency: displayclock in Hz I still think "displayclock" should be two words: "display clock". > +/** > + * of_get_display_timings - parse all display_timing entries from a > device_node > + * @np: device_node with the subnodes > + **/ > +struct display_timings *of_get_display_timings(struct device_node *np) > +{ [...] > + disp->num_timings = 0; > + disp->native_mode = 0; > + > + for_each_child_of_node(timings_np, entry) { > + struct display_timing *dt; > + > + dt = of_get_display_timing(entry); > + if (!dt) { > + /* to not encourage wrong devicetrees, fail in case of > an error */ > + pr_err("%s: error in timing %d\n", __func__, > disp->num_timings+1); > + goto timingfail; I believe you're still potentially leaking memory here. In case you have 5 entries for instance, and the last one fails to parse, then this will cause the memory allocated for the 4 correct entries to be lost. Can't you just call display_timings_release() in this case and then jump to dispfail? That would still leak the native_mode device node. Maybe it would be better to keep timingfail but modify it to free the display timings with display_timings_release() instead? See below. > + } > + > + if (native_mode == entry) > + disp->native_mode = disp->num_timings; > + > + disp->timings[disp->num_timings] = dt; > + disp->num_timings++; > + } > + of_node_put(timings_np); > + of_node_put(native_mode); > + > + if (disp->num_timings > 0) > + pr_info("%s: got %d timings. Using timing #%d as default\n", > __func__, > + disp->num_timings , disp->native_mode + 1); > + else { > + pr_err("%s: no valid timings specified\n", __func__); > + display_timings_release(disp); > + return NULL; > + } > + return disp; > + > +timingfail: > + if (native_mode) > + of_node_put(native_mode); > + kfree(disp->timings); Call display_timings_release(disp) instead of kfree(disp->timings)? > diff --git a/include/linux/of_videomode.h b/include/linux/of_videomode.h > new file mode 100644 > index 000..4138758 > --- /dev/null > +++ b/include/linux/of_videomode.h > @@ -0,0 +1,16 @@ > +/* > + * Copyright 2012 Steffen Trumtrar > + * > + * videomode of-helpers > + * > + * This file is released under the GPLv2 > + */ > + > +#ifndef __LINUX_OF_VIDEOMODE_H > +#define __LINUX_OF_VIDEOMODE_H > + > +#include > +#include > + > +int of_get_videomode(struct device_node *np, struct videomode *vm, int > index); > +#endif /* __LINUX_OF_VIDEOMODE_H */ Nit: should have a blank line before #endif. Thierry pgprAuTNoQsFb.pgp Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v9 2/6] video: add of helper for videomode
This adds support for reading display timings from DT or/and convert one of those timings to a videomode. The of_display_timing implementation supports multiple children where each property can have up to 3 values. All children are read into an array, that can be queried. of_get_videomode converts exactly one of that timings to a struct videomode. Signed-off-by: Steffen Trumtrar Signed-off-by: Philipp Zabel Acked-by: Stephen Warren --- .../devicetree/bindings/video/display-timings.txt | 107 ++ drivers/video/Kconfig | 13 ++ drivers/video/Makefile |2 + drivers/video/of_display_timing.c | 211 drivers/video/of_videomode.c | 47 + include/linux/of_display_timings.h | 20 ++ include/linux/of_videomode.h | 16 ++ 7 files changed, 416 insertions(+) create mode 100644 Documentation/devicetree/bindings/video/display-timings.txt create mode 100644 drivers/video/of_display_timing.c create mode 100644 drivers/video/of_videomode.c create mode 100644 include/linux/of_display_timings.h create mode 100644 include/linux/of_videomode.h diff --git a/Documentation/devicetree/bindings/video/display-timings.txt b/Documentation/devicetree/bindings/video/display-timings.txt new file mode 100644 index 000..c9d9e1b --- /dev/null +++ b/Documentation/devicetree/bindings/video/display-timings.txt @@ -0,0 +1,107 @@ +display-timings bindings + + +display timings node + + +required properties: + - none + +optional properties: + - native-mode: the native mode for the display, in case multiple modes are + provided. When omitted, assume the first node is the native. + +timings subnode +--- + +required properties: + - hactive, vactive: Display resolution + - hfront-porch, hback-porch, hsync-len: Horizontal Display timing parameters + in pixels + vfront-porch, vback-porch, vsync-len: Vertical display timing parameters in + lines + - clock-frequency: displayclock in Hz + +optional properties: + - hsync-active: Hsync pulse is active low/high/ignored + - vsync-active: Vsync pulse is active low/high/ignored + - de-active: Data-Enable pulse is active low/high/ignored + - pixelclk-inverted: pixelclock is inverted/non-inverted/ignored + - interlaced (bool) + - doublescan (bool) + +All the optional properties that are not bool follow the following logic: +<1>: high active +<0>: low active +omitted: not used on hardware + +There are different ways of describing the capabilities of a display. The devicetree +representation corresponds to the one commonly found in datasheets for displays. +If a display supports multiple signal timings, the native-mode can be specified. + +The parameters are defined as + +struct display_timing += + + +--+-+--+---+ + | |↑| | | + | ||vback_porch | | | + | |↓| | | + +--###--+---+ + | #↑# | | + | #|# | | + | hback #|# hfront | hsync | + | porch #| hactive # porch | len | + |<>#<---+--->#<>|<->| + | #|# | | + | #|vactive # | | + | #|# | | + | #↓# | | + +--###--+---+ + | |↑| | | + | ||vfront_porch| | | + | |↓| | | + +--+-+--+---+ + | |↑| | | + | ||vsync_len | | | + | |↓| | | + +--+-+--+---+ + + +Example: + + display-timings { + native-mode = <&timing0>; + timing0: 1920p24 { + /* 1920x1080p24 */ + clock-
[PATCH v9 4/6] fbmon: add of_videomode helpers
Add helper to get fb_videomode from devicetree. Signed-off-by: Steffen Trumtrar --- drivers/video/fbmon.c | 42 +- include/linux/fb.h|6 ++ 2 files changed, 47 insertions(+), 1 deletion(-) diff --git a/drivers/video/fbmon.c b/drivers/video/fbmon.c index cccef17..3a48abd 100644 --- a/drivers/video/fbmon.c +++ b/drivers/video/fbmon.c @@ -31,7 +31,7 @@ #include #include #include -#include +#include #ifdef CONFIG_PPC_OF #include #include @@ -1410,6 +1410,46 @@ int fb_videomode_from_videomode(struct videomode *vm, struct fb_videomode *fbmod EXPORT_SYMBOL_GPL(fb_videomode_from_videomode); #endif +#if IS_ENABLED(CONFIG_OF_VIDEOMODE) +static void dump_fb_videomode(struct fb_videomode *m) +{ + pr_debug("fb_videomode = %ux%u@%uHz (%ukHz) %u %u %u %u %u %u %u %u %u\n", +m->xres, m->yres, m->refresh, m->pixclock, m->left_margin, +m->right_margin, m->upper_margin, m->lower_margin, +m->hsync_len, m->vsync_len, m->sync, m->vmode, m->flag); +} + +/** + * of_get_fb_videomode - get a fb_videomode from devicetree + * @np: device_node with the timing specification + * @fb: will be set to the return value + * @index: index into the list of display timings in devicetree + * + * DESCRIPTION: + * This function is expensive and should only be used, if only one mode is to be + * read from DT. To get multiple modes start with of_get_display_timings ond + * work with that instead. + */ +int of_get_fb_videomode(struct device_node *np, struct fb_videomode *fb, + unsigned int index) +{ + struct videomode vm; + int ret; + + ret = of_get_videomode(np, &vm, index); + if (ret) + return ret; + + fb_videomode_from_videomode(&vm, fb); + + pr_info("%s: got %dx%d display mode from %s\n", __func__, vm.hactive, + vm.vactive, np->name); + dump_fb_videomode(fb); + + return 0; +} +EXPORT_SYMBOL_GPL(of_get_fb_videomode); +#endif #else int fb_parse_edid(unsigned char *edid, struct fb_var_screeninfo *var) diff --git a/include/linux/fb.h b/include/linux/fb.h index 6a3a675..8aeece8 100644 --- a/include/linux/fb.h +++ b/include/linux/fb.h @@ -15,6 +15,8 @@ #include #include #include +#include +#include struct vm_area_struct; struct fb_info; @@ -715,6 +717,10 @@ extern void fb_destroy_modedb(struct fb_videomode *modedb); extern int fb_find_mode_cvt(struct fb_videomode *mode, int margins, int rb); extern unsigned char *fb_ddc_read(struct i2c_adapter *adapter); +#if IS_ENABLED(CONFIG_OF_VIDEOMODE) +extern int of_get_fb_videomode(struct device_node *np, struct fb_videomode *fb, + unsigned int index); +#endif #if IS_ENABLED(CONFIG_VIDEOMODE) extern int fb_videomode_from_videomode(struct videomode *vm, struct fb_videomode *fbmode); -- 1.7.10.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v9 3/6] fbmon: add videomode helpers
Add a function to convert from the generic videomode to a fb_videomode. Signed-off-by: Steffen Trumtrar --- drivers/video/fbmon.c | 38 ++ include/linux/fb.h|5 + 2 files changed, 43 insertions(+) diff --git a/drivers/video/fbmon.c b/drivers/video/fbmon.c index cef6557..cccef17 100644 --- a/drivers/video/fbmon.c +++ b/drivers/video/fbmon.c @@ -31,6 +31,7 @@ #include #include #include +#include #ifdef CONFIG_PPC_OF #include #include @@ -1373,6 +1374,43 @@ int fb_get_mode(int flags, u32 val, struct fb_var_screeninfo *var, struct fb_inf kfree(timings); return err; } + +#if IS_ENABLED(CONFIG_VIDEOMODE) +int fb_videomode_from_videomode(struct videomode *vm, struct fb_videomode *fbmode) +{ + fbmode->xres = vm->hactive; + fbmode->left_margin = vm->hback_porch; + fbmode->right_margin = vm->hfront_porch; + fbmode->hsync_len = vm->hsync_len; + + fbmode->yres = vm->vactive; + fbmode->upper_margin = vm->vback_porch; + fbmode->lower_margin = vm->vfront_porch; + fbmode->vsync_len = vm->vsync_len; + + fbmode->pixclock = KHZ2PICOS(vm->pixelclock / 1000); + + fbmode->sync = 0; + fbmode->vmode = 0; + if (vm->hah) + fbmode->sync |= FB_SYNC_HOR_HIGH_ACT; + if (vm->vah) + fbmode->sync |= FB_SYNC_VERT_HIGH_ACT; + if (vm->interlaced) + fbmode->vmode |= FB_VMODE_INTERLACED; + if (vm->doublescan) + fbmode->vmode |= FB_VMODE_DOUBLE; + if (vm->de) + fbmode->sync |= FB_SYNC_DATA_ENABLE_HIGH_ACT; + fbmode->refresh = (vm->pixelclock*1000) / (vm->hactive * vm->vactive); + fbmode->flag = 0; + + return 0; +} +EXPORT_SYMBOL_GPL(fb_videomode_from_videomode); +#endif + + #else int fb_parse_edid(unsigned char *edid, struct fb_var_screeninfo *var) { diff --git a/include/linux/fb.h b/include/linux/fb.h index c7a9571..6a3a675 100644 --- a/include/linux/fb.h +++ b/include/linux/fb.h @@ -14,6 +14,7 @@ #include #include #include +#include struct vm_area_struct; struct fb_info; @@ -714,6 +715,10 @@ extern void fb_destroy_modedb(struct fb_videomode *modedb); extern int fb_find_mode_cvt(struct fb_videomode *mode, int margins, int rb); extern unsigned char *fb_ddc_read(struct i2c_adapter *adapter); +#if IS_ENABLED(CONFIG_VIDEOMODE) +extern int fb_videomode_from_videomode(struct videomode *vm, + struct fb_videomode *fbmode); +#endif /* drivers/video/modedb.c */ #define VESA_MODEDB_SIZE 34 extern void fb_var_to_videomode(struct fb_videomode *mode, -- 1.7.10.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v9 0/6] of: add display helper
Hi! Changes since v8: - fix memory leaks - change API to be more consistent (foo_from_bar(struct bar, struct foo)) - include headers were necessary - misc minor bufixes 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| 69 +++ drivers/video/Kconfig | 19 ++ drivers/video/Makefile |4 + drivers/video/display_timing.c | 24 +++ drivers/video/fbmon.c | 78 drivers/video/of_display_timing.c | 211 drivers/video/of_videomode.c | 47 + drivers/video/videomode.c | 45 + include/drm/drmP.h | 12 ++ include/linux/display_timing.h | 69 +++ include/linux/fb.h | 11 + include/linux/of_display_timings.h | 20 ++ include/linux/of_videomode.h | 16 ++ include/linux/videomode.h | 39 15 files changed, 771 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 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v9 5/6] drm_modes: add videomode helpers
Add conversion from videomode to drm_display_mode Signed-off-by: Steffen Trumtrar --- drivers/gpu/drm/drm_modes.c | 36 include/drm/drmP.h |6 ++ 2 files changed, 42 insertions(+) diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c index 59450f3..42ea099 100644 --- a/drivers/gpu/drm/drm_modes.c +++ b/drivers/gpu/drm/drm_modes.c @@ -35,6 +35,7 @@ #include #include #include +#include /** * drm_mode_debug_printmodeline - debug print a mode @@ -504,6 +505,41 @@ drm_gtf_mode(struct drm_device *dev, int hdisplay, int vdisplay, int vrefresh, } EXPORT_SYMBOL(drm_gtf_mode); +#if IS_ENABLED(CONFIG_VIDEOMODE) +int display_mode_from_videomode(struct videomode *vm, struct drm_display_mode *dmode) +{ + dmode->hdisplay = vm->hactive; + dmode->hsync_start = dmode->hdisplay + vm->hfront_porch; + dmode->hsync_end = dmode->hsync_start + vm->hsync_len; + dmode->htotal = dmode->hsync_end + vm->hback_porch; + + dmode->vdisplay = vm->vactive; + dmode->vsync_start = dmode->vdisplay + vm->vfront_porch; + dmode->vsync_end = dmode->vsync_start + vm->vsync_len; + dmode->vtotal = dmode->vsync_end + vm->vback_porch; + + dmode->clock = vm->pixelclock / 1000; + + dmode->flags = 0; + if (vm->hah) + dmode->flags |= DRM_MODE_FLAG_PHSYNC; + else + dmode->flags |= DRM_MODE_FLAG_NHSYNC; + if (vm->vah) + dmode->flags |= DRM_MODE_FLAG_PVSYNC; + else + dmode->flags |= DRM_MODE_FLAG_NVSYNC; + if (vm->interlaced) + dmode->flags |= DRM_MODE_FLAG_INTERLACE; + if (vm->doublescan) + dmode->flags |= DRM_MODE_FLAG_DBLSCAN; + drm_mode_set_name(dmode); + + return 0; +} +EXPORT_SYMBOL_GPL(display_mode_from_videomode); +#endif + /** * drm_mode_set_name - set the name on a mode * @mode: name will be set in this mode diff --git a/include/drm/drmP.h b/include/drm/drmP.h index 3fd8280..1e0d846 100644 --- a/include/drm/drmP.h +++ b/include/drm/drmP.h @@ -56,6 +56,7 @@ #include #include #include +#include #if defined(__alpha__) || defined(__powerpc__) #include/* For pte_wrprotect */ #endif @@ -1454,6 +1455,11 @@ extern struct drm_display_mode * drm_mode_create_from_cmdline_mode(struct drm_device *dev, struct drm_cmdline_mode *cmd); +#if IS_ENABLED(CONFIG_VIDEOMODE) +extern int display_mode_from_videomode(struct videomode *vm, + struct drm_display_mode *dmode); +#endif + /* Modesetting support */ extern void drm_vblank_pre_modeset(struct drm_device *dev, int crtc); extern void drm_vblank_post_modeset(struct drm_device *dev, int crtc); -- 1.7.10.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v9 1/6] video: add display_timing and videomode
Add display_timing structure and the according helper functions. This allows the description of a display via its supported timing parameters. Every timing parameter can be specified as a single value or a range . Also, add helper functions to convert from display timings to a generic videomode structure. This videomode can then be converted to the corresponding subsystem mode representation (e.g. fb_videomode). Signed-off-by: Steffen Trumtrar --- drivers/video/Kconfig |6 drivers/video/Makefile |2 ++ drivers/video/display_timing.c | 24 ++ drivers/video/videomode.c | 45 ++ include/linux/display_timing.h | 69 include/linux/videomode.h | 39 +++ 6 files changed, 185 insertions(+) create mode 100644 drivers/video/display_timing.c create mode 100644 drivers/video/videomode.c create mode 100644 include/linux/display_timing.h create mode 100644 include/linux/videomode.h diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig index d08d799..2a23b18 100644 --- a/drivers/video/Kconfig +++ b/drivers/video/Kconfig @@ -33,6 +33,12 @@ config VIDEO_OUTPUT_CONTROL This framework adds support for low-level control of the video output switch. +config DISPLAY_TIMING + bool + +config VIDEOMODE + bool + menuconfig FB tristate "Support for frame buffer devices" ---help--- diff --git a/drivers/video/Makefile b/drivers/video/Makefile index 23e948e..fc30439 100644 --- a/drivers/video/Makefile +++ b/drivers/video/Makefile @@ -167,3 +167,5 @@ obj-$(CONFIG_FB_VIRTUAL) += vfb.o #video output switch sysfs driver obj-$(CONFIG_VIDEO_OUTPUT_CONTROL) += output.o +obj-$(CONFIG_DISPLAY_TIMING) += display_timing.o +obj-$(CONFIG_VIDEOMODE) += videomode.o diff --git a/drivers/video/display_timing.c b/drivers/video/display_timing.c new file mode 100644 index 000..ac9bbbc --- /dev/null +++ b/drivers/video/display_timing.c @@ -0,0 +1,24 @@ +/* + * generic display timing functions + * + * Copyright (c) 2012 Steffen Trumtrar , Pengutronix + * + * This file is released under the GPLv2 + */ + +#include +#include +#include + +void display_timings_release(struct display_timings *disp) +{ + if (disp->timings) { + unsigned int i; + + for (i = 0; i < disp->num_timings; i++) + kfree(disp->timings[i]); + kfree(disp->timings); + } + kfree(disp); +} +EXPORT_SYMBOL_GPL(display_timings_release); diff --git a/drivers/video/videomode.c b/drivers/video/videomode.c new file mode 100644 index 000..087374a --- /dev/null +++ b/drivers/video/videomode.c @@ -0,0 +1,45 @@ +/* + * generic display timing functions + * + * Copyright (c) 2012 Steffen Trumtrar , Pengutronix + * + * This file is released under the GPLv2 + */ + +#include +#include +#include +#include +#include + +int videomode_from_timing(struct display_timings *disp, struct videomode *vm, + unsigned int index) +{ + struct display_timing *dt; + + dt = display_timings_get(disp, index); + if (!dt) + return -EINVAL; + + vm->pixelclock = display_timing_get_value(&dt->pixelclock, 0); + vm->hactive = display_timing_get_value(&dt->hactive, 0); + vm->hfront_porch = display_timing_get_value(&dt->hfront_porch, 0); + vm->hback_porch = display_timing_get_value(&dt->hback_porch, 0); + vm->hsync_len = display_timing_get_value(&dt->hsync_len, 0); + + vm->vactive = display_timing_get_value(&dt->vactive, 0); + vm->vfront_porch = display_timing_get_value(&dt->vfront_porch, 0); + vm->vback_porch = display_timing_get_value(&dt->vback_porch, 0); + vm->vsync_len = display_timing_get_value(&dt->vsync_len, 0); + + vm->vah = dt->vsync_pol_active; + vm->hah = dt->hsync_pol_active; + vm->de = dt->de_pol_active; + vm->pixelclk_pol = dt->pixelclk_pol; + + vm->interlaced = dt->interlaced; + vm->doublescan = dt->doublescan; + + return 0; +} +EXPORT_SYMBOL_GPL(videomode_from_timing); diff --git a/include/linux/display_timing.h b/include/linux/display_timing.h new file mode 100644 index 000..caee2a8 --- /dev/null +++ b/include/linux/display_timing.h @@ -0,0 +1,69 @@ +/* + * Copyright 2012 Steffen Trumtrar + * + * description of display timings + * + * This file is released under the GPLv2 + */ + +#ifndef __LINUX_DISPLAY_TIMINGS_H +#define __LINUX_DISPLAY_TIMINGS_H + +#include + +struct timing_entry { + u32 min; + u32 typ; + u32 max; +}; + +struct display_timing { + struct timing_entry pixelclock; + + struct timing_entry hactive; + struct timing_entry hfront_porch; + struct timing_entry hback_porch; + struct timing_entry hsync_len; + + struct timing_entry vactive; + struct timing_entry vfront_porch; + str
[PATCH v9 6/6] drm_modes: add of_videomode helpers
Add helper to get drm_display_mode from devicetree. Signed-off-by: Steffen Trumtrar --- drivers/gpu/drm/drm_modes.c | 35 ++- include/drm/drmP.h |6 ++ 2 files changed, 40 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c index 42ea099..c3ae5d2 100644 --- a/drivers/gpu/drm/drm_modes.c +++ b/drivers/gpu/drm/drm_modes.c @@ -35,7 +35,8 @@ #include #include #include -#include +#include +#include /** * drm_mode_debug_printmodeline - debug print a mode @@ -540,6 +541,38 @@ int display_mode_from_videomode(struct videomode *vm, struct drm_display_mode *d EXPORT_SYMBOL_GPL(display_mode_from_videomode); #endif +#if IS_ENABLED(CONFIG_OF_VIDEOMODE) +/** + * of_get_drm_display_mode - get a drm_display_mode from devicetree + * @np: device_node with the timing specification + * @dmode: will be set to the return value + * @index: index into the list of display timings in devicetree + * + * This function is expensive and should only be used, if only one mode is to be + * read from DT. To get multiple modes start with of_get_display_timings and + * work with that instead. + */ +int of_get_drm_display_mode(struct device_node *np, struct drm_display_mode *dmode, + unsigned int index) +{ + struct videomode vm; + int ret; + + ret = of_get_videomode(np, &vm, index); + if (ret) + return ret; + + display_mode_from_videomode(&vm, dmode); + + pr_info("%s: got %dx%d display mode from %s\n", __func__, vm.hactive, + vm.vactive, np->name); + drm_mode_debug_printmodeline(dmode); + + return 0; + +} +EXPORT_SYMBOL_GPL(of_get_drm_display_mode); +#endif /** * drm_mode_set_name - set the name on a mode * @mode: name will be set in this mode diff --git a/include/drm/drmP.h b/include/drm/drmP.h index 1e0d846..e8f46a1 100644 --- a/include/drm/drmP.h +++ b/include/drm/drmP.h @@ -56,6 +56,7 @@ #include #include #include +#include #include #if defined(__alpha__) || defined(__powerpc__) #include/* For pte_wrprotect */ @@ -1459,6 +1460,11 @@ drm_mode_create_from_cmdline_mode(struct drm_device *dev, extern int display_mode_from_videomode(struct videomode *vm, struct drm_display_mode *dmode); #endif +#if IS_ENABLED(CONFIG_OF_VIDEOMODE) +extern int of_get_drm_display_mode(struct device_node *np, + struct drm_display_mode *dmode, + unsigned int index); +#endif /* Modesetting support */ extern void drm_vblank_pre_modeset(struct drm_device *dev, int crtc); -- 1.7.10.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 41971] [kms] Muxless radeon takes 20 seconds to fetch rom
https://bugs.freedesktop.org/show_bug.cgi?id=41971 Mike Lothian changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #17 from Mike Lothian --- I'm not sure when this was fixed but it's now no longer an issue -- 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/20121114/23743209/attachment-0001.html>
Re: [PATCH v8 1/6] video: add display_timing and videomode
On Wed, Nov 14, 2012 at 12:10:15PM +0100, Steffen Trumtrar wrote: > On Wed, Nov 14, 2012 at 12:02:15PM +0100, Thierry Reding wrote: > > On Wed, Nov 14, 2012 at 11:59:25AM +0100, Steffen Trumtrar wrote: > > > On Wed, Nov 14, 2012 at 11:56:34AM +0100, Thierry Reding wrote: > > > > On Mon, Nov 12, 2012 at 04:37:01PM +0100, Steffen Trumtrar wrote: > > > > [...] > > > > > diff --git a/drivers/video/display_timing.c > > > > > b/drivers/video/display_timing.c > > > > [...] > > > > > +void display_timings_release(struct display_timings *disp) > > > > > +{ > > > > > + if (disp->timings) { > > > > > + unsigned int i; > > > > > + > > > > > + for (i = 0; i < disp->num_timings; i++) > > > > > + kfree(disp->timings[i]); > > > > > + kfree(disp->timings); > > > > > + } > > > > > + kfree(disp); > > > > > +} > > > > > > > > I think this is still missing an EXPORT_SYMBOL_GPL. Otherwise it can't > > > > be used from modules. > > > > > > > > Thierry > > > > > > Yes. Just in time. I was just starting to type the send-email command ;-) > > > > Great! In that case don't forget to also look at my other email before > > sending. =) > > > Sure. Besides those comments (and those from other people) I think your patchset is in pretty good shape. Have you thought about how and when you want to get things merged? Thierry pgpqkrgytdEzJ.pgp Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel