[Bug 65327] running gnubik produces a segfault
https://bugs.freedesktop.org/show_bug.cgi?id=65327 Andreas Boll changed: What|Removed |Added Product|DRI |Mesa Component|DRM/Radeon |Drivers/Gallium/r300 -- 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 60879] [radeonsi] X11 can't start with acceleration enabled
https://bugs.freedesktop.org/show_bug.cgi?id=60879 --- Comment #35 from Hristo Venev --- OpenCL update: On floating point, addition, subtraction, multiplication, division and pow work. On integer, addition, subtraction and multiplication work. Division and modulo halt the GPU. If they are implemented the same way as in OpenGL, this might be the bug I'm facing. -- 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
[PATCH] drm: Add kernel-doc for plane functions
From: Ville Syrjälä
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_crtc.c | 31 +++
1 file changed, 31 insertions(+)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index f00ba75..f1f11e1 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -795,6 +795,21 @@ void drm_encoder_cleanup(struct drm_encoder *encoder)
}
EXPORT_SYMBOL(drm_encoder_cleanup);
+/**
+ * drm_plane_init - Initialise a new plane object
+ * @dev: DRM device
+ * @plane: plane object to init
+ * @possible_crtcs: bitmask of possible CRTCs
+ * @funcs: callbacks for the new plane
+ * @formats: array of supported formats (%DRM_FORMAT_*)
+ * @format_count: number of elements in @formats
+ * @priv: plane is private (hidden from userspace)?
+ *
+ * Inits a new object created as base part of an driver plane object.
+ *
+ * RETURNS:
+ * Zero on success, error code on failure.
+ */
int drm_plane_init(struct drm_device *dev, struct drm_plane *plane,
unsigned long possible_crtcs,
const struct drm_plane_funcs *funcs,
@@ -843,6 +858,13 @@ int drm_plane_init(struct drm_device *dev, struct
drm_plane *plane,
}
EXPORT_SYMBOL(drm_plane_init);
+/**
+ * drm_plane_cleanup - Cleans up the core plane usage.
+ * @plane: plane to cleanup
+ *
+ * Cleanup @plane. Removes from drm modesetting space
+ * does NOT free object, caller does that.
+ */
void drm_plane_cleanup(struct drm_plane *plane)
{
struct drm_device *dev = plane->dev;
@@ -859,6 +881,15 @@ void drm_plane_cleanup(struct drm_plane *plane)
}
EXPORT_SYMBOL(drm_plane_cleanup);
+/**
+ * drm_plane_force_disable - Forcibly disable a plane
+ * @plane: plane to disable
+ *
+ * Forces the plane to be disabled.
+ *
+ * Used when the plane's current framebuffer is destroyed,
+ * and when restoring fbdev mode.
+ */
void drm_plane_force_disable(struct drm_plane *plane)
{
int ret;
--
1.8.1.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/3] drm/fb-helper: Disable cursors and planes when restoring fbdev mode
On Mon, Jun 03, 2013 at 04:10:42PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Cursors and plane can obscure whatever fbdev wants to show the user.
> Disable them all in drm_fb_helper_restore_fbdev_mode.
>
> After the cursors and planes have been disabled, user space needs to
> explicitly re-enable them to make them visible again.
>
> Signed-off-by: Ville Syrjälä
Yeah, I like that color ;-) For the series:
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_fb_helper.c | 18 --
> 1 file changed, 16 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index 0df0ebb..3d13ca6e2 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -287,13 +287,27 @@ EXPORT_SYMBOL(drm_fb_helper_debug_leave);
> */
> bool drm_fb_helper_restore_fbdev_mode(struct drm_fb_helper *fb_helper)
> {
> + struct drm_device *dev = fb_helper->dev;
> + struct drm_plane *plane;
> bool error = false;
> - int i, ret;
> + int i;
> +
> + drm_warn_on_modeset_not_all_locked(dev);
>
> - drm_warn_on_modeset_not_all_locked(fb_helper->dev);
> + list_for_each_entry(plane, &dev->mode_config.plane_list, head)
> + drm_plane_force_disable(plane);
>
> for (i = 0; i < fb_helper->crtc_count; i++) {
> struct drm_mode_set *mode_set =
> &fb_helper->crtc_info[i].mode_set;
> + struct drm_crtc *crtc = mode_set->crtc;
> + int ret;
> +
> + if (crtc->funcs->cursor_set) {
> + ret = crtc->funcs->cursor_set(crtc, NULL, 0, 0, 0);
> + if (ret)
> + error = true;
> + }
> +
> ret = drm_mode_set_config_internal(mode_set);
> if (ret)
> error = true;
> --
> 1.8.1.5
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH v2 2/2] drm: Remove some unused stuff from drm_plane
On Mon, Jun 03, 2013 at 04:11:42PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> There's a bunch of unused members inside drm_plane, bloating the size of
> the structure needlessly. Eliminate them.
>
> v2: Remove all of it from kernel-doc too
>
> Reviewed-by: Laurent Pinchart
> Signed-off-by: Ville Syrjälä
Yeah, makes sense to ditch this. We can think about this again when atomic
modeset and plane properties pop up again. For both patches:
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_crtc.c | 2 +-
> include/drm/drm_crtc.h | 11 ---
> 2 files changed, 1 insertion(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 865ebfe..f00ba75 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -1749,7 +1749,7 @@ int drm_mode_getplane(struct drm_device *dev, void
> *data,
>
> plane_resp->plane_id = plane->base.id;
> plane_resp->possible_crtcs = plane->possible_crtcs;
> - plane_resp->gamma_size = plane->gamma_size;
> + plane_resp->gamma_size = 0;
>
> /*
>* This ioctl is called twice, once to determine how much space is
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index db7a885..3c14b46 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -654,11 +654,7 @@ struct drm_plane_funcs {
> * @format_count: number of formats supported
> * @crtc: currently bound CRTC
> * @fb: currently bound fb
> - * @gamma_size: size of gamma table
> - * @gamma_store: gamma correction table
> - * @enabled: enabled flag
> * @funcs: helper functions
> - * @helper_private: storage for drver layer
> * @properties: property tracking for this plane
> */
> struct drm_plane {
> @@ -674,14 +670,7 @@ struct drm_plane {
> struct drm_crtc *crtc;
> struct drm_framebuffer *fb;
>
> - /* CRTC gamma size for reporting to userspace */
> - uint32_t gamma_size;
> - uint16_t *gamma_store;
> -
> - bool enabled;
> -
> const struct drm_plane_funcs *funcs;
> - void *helper_private;
>
> struct drm_object_properties properties;
> };
> --
> 1.8.1.5
>
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC][PATCH 0/2] dma-buf: add importer private data for reimporting
On 2013년 06월 01일 00:29, Daniel Vetter wrote: > On Fri, May 31, 2013 at 07:22:24PM +0900, 김승우 wrote: >> Hello Daniel, >> >> Thanks for your comment. >> >> On 2013년 05월 31일 18:14, Daniel Vetter wrote: >>> On Fri, May 31, 2013 at 10:54 AM, Seung-Woo Kim >>> wrote: importer private data in dma-buf attachment can be used by importer to reimport same dma-buf. Seung-Woo Kim (2): dma-buf: add importer private data to attachment drm/prime: find gem object from the reimported dma-buf >>> >>> Self-import should already work (at least with the latest refcount >>> fixes merged). At least the tests to check both re-import on the same >>> drm fd and on a different all work as expected now. >> >> Currently, prime works well for all case including self-importing, >> importing, and reimporting as you describe. Just, importing dma-buf from >> other driver twice with different drm_fd, each import create its own gem >> object even two import is done for same buffer because prime_priv is in >> struct drm_file. This means mapping to the device is done also twice. >> IMHO, these duplicated creations and maps are not necessary if drm can >> find previous import in different prime_priv. > > Well, that's imo a bug with the other driver. If it doesn't export > something really simple (e.g. contiguous memory which doesn't require any > mmio resources at all) it should have a cache of exported dma_buf fds so > that it hands out the same dma_buf every time. Hm, all existing dma-buf exporter including i915 driver implements its map_dma_buf callback as allocating scatter-gather table with pages in its buffer and calling dma_map_sg() with the sgt. With different drm_fds, importing one dma-buf *twice*, then importer calls dma_buf_attach() and dma_buf_map_attachment() twice at least in drm importer because re-importing case can only checked with prime_priv in drm_file as I described. > > Or it needs to be more clever in it's dma_buf_attachment_map functions and > lookup up a pre-existing iommu mapping. > > But dealing with this in the importer is just broken. > >>> Second, the dma_buf_attachment is _definitely_ the wrong place to do >>> this. If you need iommu mapping caching, that should happen at a lower >>> level (i.e. in the map_attachment callback somewhere of the exporter, >>> that's what the priv field in the attachment is for). Snatching away >>> the attachement from some random other import is certainly not the way >>> to go - attachements are _not_ refcounted! >> >> Yes, attachments do not have refcount, so importer should handle and drm >> case in my patch, importer private data is gem object and it has, of >> course, refcount. >> >> And at current, exporter can not classify map_dma_buf requests of same >> importer to same buffer with different attachment because dma_buf_attach >> always makes new attachments. To resolve this exporter should search all >> different attachment from same importer of dma-buf and it seems more >> complex than importer private data to me. >> >> If I misunderstood something, please let me know. > > Like I've said above, just fix this in the exporter. If an importer sees > two different dma_bufs it can very well presume that it those two indeed > point to different backing storage. Yes, my patch does not break this concept. I just fixed case importing _one_ dma-buf twice with different drm_fds. > > This will be even more important if we attach fences two dma_bufs. If your > broken exporter creates multiple dma_bufs each one of them will have their > own fences attached, leading to a complete disasters. Ok, strictly > speaking if you keep the same reservation pointer for each dma_buf it'll > work, but that's just a detail of how you solve this in the exporter. I can not understand about broken exporter you addressed. I don't mean exporter makes dma-bufs from one backing storage. While, my patch prevents not to create drm gem objects from one back storage by importing one dma-buf with different drm-fds. I do not believe the fix of importer is the best way, but at this moment, I have no idea how I can fix the exporter for this issue. Best Regards, - Seung-Woo Kim > > Cheers, Daniel > -- Seung-Woo Kim Samsung Software R&D Center -- ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/5] drm/gem: Split drm_gem_mmap() into object search and object mapping
On Mon, Jun 3, 2013 at 10:20 PM, Laurent Pinchart
wrote:
> The drm_gem_mmap() function first finds the GEM object to be mapped
> based on the fake mmap offset and then maps the object. Split the object
> mapping code into a standalone drm_gem_mmap_obj() function that can be
> used to implement dma-buf mmap() operations.
>
> Signed-off-by: Laurent Pinchart
Cool, thanks.. this was an old TODO of mine that I apparently forgot about :-)
Reviewed-by: Rob Clark
> ---
> drivers/gpu/drm/drm_gem.c | 83
> +--
> include/drm/drmP.h| 2 ++
> 2 files changed, 54 insertions(+), 31 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
> index cf919e3..4321713 100644
> --- a/drivers/gpu/drm/drm_gem.c
> +++ b/drivers/gpu/drm/drm_gem.c
> @@ -644,6 +644,55 @@ void drm_gem_vm_close(struct vm_area_struct *vma)
> }
> EXPORT_SYMBOL(drm_gem_vm_close);
>
> +/**
> + * drm_gem_mmap_obj - memory map a GEM object
> + * @obj: the GEM object to map
> + * @obj_size: the object size to be mapped, in bytes
> + * @vma: VMA for the area to be mapped
> + *
> + * Set up the VMA to prepare mapping of the GEM object using the gem_vm_ops
> + * provided by the driver. Depending on their requirements, drivers can
> either
> + * provide a fault handler in their gem_vm_ops (in which case any accesses to
> + * the object will be trapped, to perform migration, GTT binding, surface
> + * register allocation, or performance monitoring), or mmap the buffer memory
> + * synchronously after calling drm_gem_mmap_obj.
> + *
> + * This function is mainly intended to implement the DMABUF mmap operation,
> when
> + * the GEM object is not looked up based on its fake offset. To implement the
> + * DRM mmap operation, drivers should use the drm_gem_mmap() function.
> + *
> + * Return 0 or success or -EINVAL if the object size is smaller than the VMA
> + * size, or if no gem_vm_ops are provided.
> + */
> +int drm_gem_mmap_obj(struct drm_gem_object *obj, unsigned long obj_size,
> +struct vm_area_struct *vma)
> +{
> + struct drm_device *dev = obj->dev;
> +
> + /* Check for valid size. */
> + if (obj_size < vma->vm_end - vma->vm_start)
> + return -EINVAL;
> +
> + if (!dev->driver->gem_vm_ops)
> + return -EINVAL;
> +
> + vma->vm_flags |= VM_IO | VM_PFNMAP | VM_DONTEXPAND | VM_DONTDUMP;
> + vma->vm_ops = dev->driver->gem_vm_ops;
> + vma->vm_private_data = obj;
> + vma->vm_page_prot =
> pgprot_writecombine(vm_get_page_prot(vma->vm_flags));
> +
> + /* Take a ref for this mapping of the object, so that the fault
> +* handler can dereference the mmap offset's pointer to the object.
> +* This reference is cleaned up by the corresponding vm_close
> +* (which should happen whether the vma was created by this call, or
> +* by a vm_open due to mremap or partial unmap or whatever).
> +*/
> + drm_gem_object_reference(obj);
> +
> + drm_vm_open_locked(dev, vma);
> + return 0;
> +}
> +EXPORT_SYMBOL(drm_gem_mmap_obj);
>
> /**
> * drm_gem_mmap - memory map routine for GEM objects
> @@ -653,11 +702,9 @@ EXPORT_SYMBOL(drm_gem_vm_close);
> * If a driver supports GEM object mapping, mmap calls on the DRM file
> * descriptor will end up here.
> *
> - * If we find the object based on the offset passed in (vma->vm_pgoff will
> + * Look up the GEM object based on the offset passed in (vma->vm_pgoff will
> * contain the fake offset we created when the GTT map ioctl was called on
> - * the object), we set up the driver fault handler so that any accesses
> - * to the object can be trapped, to perform migration, GTT binding, surface
> - * register allocation, or performance monitoring.
> + * the object) and map it with a call to drm_gem_mmap_obj().
> */
> int drm_gem_mmap(struct file *filp, struct vm_area_struct *vma)
> {
> @@ -665,7 +712,6 @@ int drm_gem_mmap(struct file *filp, struct vm_area_struct
> *vma)
> struct drm_device *dev = priv->minor->dev;
> struct drm_gem_mm *mm = dev->mm_private;
> struct drm_local_map *map = NULL;
> - struct drm_gem_object *obj;
> struct drm_hash_item *hash;
> int ret = 0;
>
> @@ -686,32 +732,7 @@ int drm_gem_mmap(struct file *filp, struct
> vm_area_struct *vma)
> goto out_unlock;
> }
>
> - /* Check for valid size. */
> - if (map->size < vma->vm_end - vma->vm_start) {
> - ret = -EINVAL;
> - goto out_unlock;
> - }
> -
> - obj = map->handle;
> - if (!obj->dev->driver->gem_vm_ops) {
> - ret = -EINVAL;
> - goto out_unlock;
> - }
> -
> - vma->vm_flags |= VM_IO | VM_PFNMAP | VM_DONTEXPAND | VM_DONTDUMP;
> - vma->vm_ops = obj->dev->driver->gem_vm_ops;
> - vma->vm_private_data = map->handle;
> - vma->vm_page_prot =
> pg
Re: [PATCH v2 2/5] drm/omap: Use drm_gem_mmap_obj() to implement dma-buf mmap
On Mon, Jun 3, 2013 at 10:20 PM, Laurent Pinchart
wrote:
> The dma-buf mmap code was copied from the GEM mmap implementation.
> Replace it with the new drm_gem_mmap_obj() function.
>
> Signed-off-by: Laurent Pinchart
Reviewed-by: Rob Clark
> ---
> drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c | 32
> +++
> 1 file changed, 3 insertions(+), 29 deletions(-)
>
> diff --git a/drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c
> b/drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c
> index be7cd97..3256693 100644
> --- a/drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c
> +++ b/drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c
> @@ -136,10 +136,6 @@ static void omap_gem_dmabuf_kunmap(struct dma_buf
> *buffer,
> kunmap(pages[page_num]);
> }
>
> -/*
> - * TODO maybe we can split up drm_gem_mmap to avoid duplicating
> - * some here.. or at least have a drm_dmabuf_mmap helper.
> - */
> static int omap_gem_dmabuf_mmap(struct dma_buf *buffer,
> struct vm_area_struct *vma)
> {
> @@ -149,31 +145,9 @@ static int omap_gem_dmabuf_mmap(struct dma_buf *buffer,
> if (WARN_ON(!obj->filp))
> return -EINVAL;
>
> - /* Check for valid size. */
> - if (omap_gem_mmap_size(obj) < vma->vm_end - vma->vm_start) {
> - ret = -EINVAL;
> - goto out_unlock;
> - }
> -
> - if (!obj->dev->driver->gem_vm_ops) {
> - ret = -EINVAL;
> - goto out_unlock;
> - }
> -
> - vma->vm_flags |= VM_IO | VM_PFNMAP | VM_DONTEXPAND | VM_DONTDUMP;
> - vma->vm_ops = obj->dev->driver->gem_vm_ops;
> - vma->vm_private_data = obj;
> - vma->vm_page_prot =
> pgprot_writecombine(vm_get_page_prot(vma->vm_flags));
> -
> - /* Take a ref for this mapping of the object, so that the fault
> -* handler can dereference the mmap offset's pointer to the object.
> -* This reference is cleaned up by the corresponding vm_close
> -* (which should happen whether the vma was created by this call, or
> -* by a vm_open due to mremap or partial unmap or whatever).
> -*/
> - vma->vm_ops->open(vma);
> -
> -out_unlock:
> + ret = drm_gem_mmap_obj(obj, omap_gem_mmap_size(obj), vma);
> + if (ret < 0)
> + return ret;
>
> return omap_gem_mmap_obj(obj, vma);
> }
> --
> 1.8.1.5
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [REGRESSION] system does not resume from ram due to commit "drm/nv50/fifo: prevent races between clients updating playlists"
On Mon, Jun 03, 2013 at 03:50:50PM +1000, Ben Skeggs wrote: > On Fri, May 31, 2013 at 11:05 PM, Konrad Rzeszutek Wilk < > konrad.w...@oracle.com> wrote: > > > On Tue, May 28, 2013 at 08:55:29PM +0200, Sven Joachim wrote: > > > On 2013-05-26 23:09 +0200, Maarten Maathuis wrote: > > > > > > > My NV96 does not resume from suspend to ram (the screen stays black, > > magic > > > > sysrq keys do work) with the current linus git kernel, i bisected it > > to the > > > > following commit. > > > > > > > > drm/nv50/fifo: prevent races between clients updating playlists > > > > b5096566f6e1ee2b88324772f020ae9bc0cfa9a0 > > > > > > > > It's not obvious to me how this causes problems, but reverting this > > commit > > > > does solve my problem. > > > > > > Same here on my NV86. > > > > And as well on this: > > > > 01:00.0 VGA compatible controller: NVIDIA Corporation G84 [GeForce 8600 > > GT] (rev a1) > > > > > > Ben, any ideas? > > > > I've pushed a fix[1] to my git tree. Will pull it across to the "normal" > tree once I've hunted down another regression. You can also add (if you would like) Tested-by: Konrad Rzeszutek Wilk Thanks! > > Thanks, > Ben. > > [1] > http://cgit.freedesktop.org/~darktama/nouveau/commit/?id=d37687a562f0b55cc848cfcdbf8d473a6c692c2d > > > > > > Cheers, > > >Sven > > ___ > > 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
Re: [RFC][PATCH 0/2] dma-buf: add importer private data for reimporting
On Tue, Jun 04, 2013 at 07:42:22PM +0900, 김승우 wrote: > > > On 2013년 06월 01일 00:29, Daniel Vetter wrote: > > On Fri, May 31, 2013 at 07:22:24PM +0900, 김승우 wrote: > >> Hello Daniel, > >> > >> Thanks for your comment. > >> > >> On 2013년 05월 31일 18:14, Daniel Vetter wrote: > >>> On Fri, May 31, 2013 at 10:54 AM, Seung-Woo Kim > >>> wrote: > importer private data in dma-buf attachment can be used by importer to > reimport same dma-buf. > > Seung-Woo Kim (2): > dma-buf: add importer private data to attachment > drm/prime: find gem object from the reimported dma-buf > >>> > >>> Self-import should already work (at least with the latest refcount > >>> fixes merged). At least the tests to check both re-import on the same > >>> drm fd and on a different all work as expected now. > >> > >> Currently, prime works well for all case including self-importing, > >> importing, and reimporting as you describe. Just, importing dma-buf from > >> other driver twice with different drm_fd, each import create its own gem > >> object even two import is done for same buffer because prime_priv is in > >> struct drm_file. This means mapping to the device is done also twice. > >> IMHO, these duplicated creations and maps are not necessary if drm can > >> find previous import in different prime_priv. > > > > Well, that's imo a bug with the other driver. If it doesn't export > > something really simple (e.g. contiguous memory which doesn't require any > > mmio resources at all) it should have a cache of exported dma_buf fds so > > that it hands out the same dma_buf every time. > > Hm, all existing dma-buf exporter including i915 driver implements its > map_dma_buf callback as allocating scatter-gather table with pages in > its buffer and calling dma_map_sg() with the sgt. With different > drm_fds, importing one dma-buf *twice*, then importer calls > dma_buf_attach() and dma_buf_map_attachment() twice at least in drm > importer because re-importing case can only checked with prime_priv in > drm_file as I described. Well, but thanks to all the self-import and re-import checks, it's _impossible_ to import the same dma_buf twice without noticing (presuming both importer and exporter are drm devices). > > > > > Or it needs to be more clever in it's dma_buf_attachment_map functions and > > lookup up a pre-existing iommu mapping. > > > > But dealing with this in the importer is just broken. > > > >>> Second, the dma_buf_attachment is _definitely_ the wrong place to do > >>> this. If you need iommu mapping caching, that should happen at a lower > >>> level (i.e. in the map_attachment callback somewhere of the exporter, > >>> that's what the priv field in the attachment is for). Snatching away > >>> the attachement from some random other import is certainly not the way > >>> to go - attachements are _not_ refcounted! > >> > >> Yes, attachments do not have refcount, so importer should handle and drm > >> case in my patch, importer private data is gem object and it has, of > >> course, refcount. > >> > >> And at current, exporter can not classify map_dma_buf requests of same > >> importer to same buffer with different attachment because dma_buf_attach > >> always makes new attachments. To resolve this exporter should search all > >> different attachment from same importer of dma-buf and it seems more > >> complex than importer private data to me. > >> > >> If I misunderstood something, please let me know. > > > > Like I've said above, just fix this in the exporter. If an importer sees > > two different dma_bufs it can very well presume that it those two indeed > > point to different backing storage. > > Yes, my patch does not break this concept. I just fixed case importing > _one_ dma-buf twice with different drm_fds. See above, if you have two different struct file * for the same underlying buffer object something is wrong already. > > This will be even more important if we attach fences two dma_bufs. If your > > broken exporter creates multiple dma_bufs each one of them will have their > > own fences attached, leading to a complete disasters. Ok, strictly > > speaking if you keep the same reservation pointer for each dma_buf it'll > > work, but that's just a detail of how you solve this in the exporter. > > I can not understand about broken exporter you addressed. I don't mean > exporter makes dma-bufs from one backing storage. > While, my patch prevents not to create drm gem objects from one back > storage by importing one dma-buf with different drm-fds. Well, we also have code in drm prime for that case - if the same dma_buf object shows up multiple times, we'll only import it once. For the second import we'll return the already created drm_gem object from the first import, but with the refcount incremented. > I do not believe the fix of importer is the best way, but at this > moment, I have no idea how I can fix the exporter for this issue. I think if you have drm prime drivers both as impor
[PULL] drm-intel-fixes
Hi Dave, Three regression fixes and one no-lvds quirk update. The regression Egbert Eich tracked down goes back to 2.6.37 ... ugh. The other two are pretty minor: One bogus modeset state checker WARN and a patch to prevent X dying in a SIGBUS after a gpu hang with failed (or not implement as on gen2/3) gpu reset. Cheers, Daniel The following changes since commit d683b96b072dc4680fc74964eca77e6a23d1fa6e: Linux 3.10-rc4 (2013-06-02 17:11:17 +0900) are available in the git repository at: git://people.freedesktop.org/~danvet/drm-intel tags/drm-intel-fixes-2013-06-04 for you to fetch changes up to 53d3b4d7778daf15900867336c85d3f8dd70600c: drm/i915/sdvo: Use &intel_sdvo->ddc instead of intel_sdvo->i2c for DDC. (2013-06-04 17:48:43 +0200) Ben Mesman (1): drm/i915: no lvds quirk for hp t5740 Daniel Vetter (2): drm/i915: Fix spurious -EIO/SIGBUS on wedged gpus drm/i915: Quirk the pipe A quirk in the modeset state checker Egbert Eich (1): drm/i915/sdvo: Use &intel_sdvo->ddc instead of intel_sdvo->i2c for DDC. drivers/gpu/drm/i915/i915_gem.c |7 ++- drivers/gpu/drm/i915/intel_display.c |5 + drivers/gpu/drm/i915/intel_lvds.c|4 ++-- drivers/gpu/drm/i915/intel_sdvo.c|2 +- 4 files changed, 10 insertions(+), 8 deletions(-) -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/tegra: add support for runtime pm
On Tuesday 28 May 2013 02:40 PM, Thierry Reding wrote:
* PGP Signed by an unknown key
On Tue, May 28, 2013 at 08:45:03AM +0300, Terje Bergström wrote:
On 27.05.2013 18:45, Thierry Reding wrote:
On Mon, May 27, 2013 at 07:19:28PM +0530, Mayuresh Kulkarni wrote:
+#ifdef CONFIG_PM_RUNTIME
+static int host1x_runtime_suspend(struct device *dev)
+{
+ struct host1x *host;
+
+ host = dev_get_drvdata(dev);
+ if (IS_ERR_OR_NULL(host))
I think a simple
if (!host)
return -EINVAL;
would be enough here. The driver-data of the device should never be an
ERR_PTR()-encoded value, but either a valid pointer to a host1x object
or NULL.
True, we should avoid IS_ERR_OR_NULL() like plague. We always know if
the called API returns a NULL on error or an error code. In case of
error code we should just propagate that.
Yes, that's the case in general. In this specific case the value
obtained by dev_get_drvdata() should either be a valid pointer or NULL,
never an error code. We can easily make sure by only setting the data
(using platform_set_drvdata()) when the pointer is valid.
Thinking about it some more, I don't think we can ever get NULL here. A
device's .runtime_suspend() cannot be called when the device has been
removed, right? That's the only case where the value returned might be
NULL. It would be NULL too if host1x wasn't initialized yet, but that's
already dealt with by the proper ordering in .probe().
Same comments apply here. Also I think it might be a good idea to split
the host1x and gr2d changes into separate patches.
That's a bit tricky, but doable. We just need to enable it for 2D first,
and then host1x to keep bisectability.
Right, there's a dependency. But I'd still prefer to have them separate.
Unless it gets really messy.
static void action_submit_complete(struct host1x_waitlist *waiter)
{
+ int completed = waiter->count;
struct host1x_channel *channel = waiter->data;
+ /* disable clocks for all the submits that got completed in this lot */
+ while (completed--)
+ pm_runtime_put(channel->dev);
+
host1x_cdma_update(&channel->cdma);
- /* Add nr_completed to trace */
+ /* Add nr_completed to trace */
trace_host1x_channel_submit_complete(dev_name(channel->dev),
waiter->count, waiter->thresh);
-
}
This feels hackish. But I can't see any better place to do this. Terje,
Arto: any ideas how we can do this in a cleaner way? If there's nothing
better then maybe moving the code into a separate function, say
host1x_waitlist_complete(), might make this less awkward?
Yeah, it's a bit awkward. action_submit_complete() actually does handle
completion of multiple jobs, and we do one pm_runtime_get() per job.
We could do pm_runtime_put() in host1x_cdma_update(). It anyway goes
through each job that is completed, so while freeing the job it could as
well call runtime PM. That way we could even remove the waiter->count
variable altogether as it's not needed anymore.
That sounds a lot better. We could add a helper (host1x_job_finish()
perhaps) with the following from update_cdma_locked():
/* Unpin the memory */
host1x_job_unpin(job);
/* Pop push buffer slots */
if (job->num_slots) {
struct push_buffer *pb = &cdma->push_buffer;
host1x_pushbuffer_pop(pb, job->num_slots);
if (cdma->event == CDMA_EVENT_PUSH_BUFFER_SPACE)
signal = true;
}
list_del(&job->list);
And add pm_runtime_put() (as well as potentially other stuff) in there.
That'll prevent update_cdma_unlocked() from growing too much. It isn't
too bad right now, so maybe a helper isn't warranted yet, but I don't
think it'll hurt.
The not-so-beautiful aspect is that we do pm_runtime_get() in
host1x_channel.c and pm_runtime_put() in host1x_cdma.c. For code
readability it's be great to have them in the same file. I actually get
questions every now and then because in downstream because of doing
these operations in different files.
With the above helper in place, we could move host1x_job_submit() to
job.c instead and have all the code in one file.
Thierry
* Unknown Key
* 0x7F3EB3A1
In downstream, we have 2 APIs which are wrapper over runtime PM calls.
We call those from _submit and job complete.
I wonder if we should follow the same here?
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 65192] [r600g] Screensavers lock up machine (screen goes blank, keyboard unresponsive, sound loops; sysrq/ssh possible)
https://bugs.freedesktop.org/show_bug.cgi?id=65192 --- Comment #8 from Michel Dänzer --- (In reply to comment #8) > [...] the bug (or regression, I think it used to work about 2 months ago) Can you try confirming that, e.g. by trying Mesa from the 9.1 branch or an older snapshot from master? -- 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 60879] [radeonsi] X11 can't start with acceleration enabled
https://bugs.freedesktop.org/show_bug.cgi?id=60879 --- Comment #36 from Michel Dänzer --- For OpenCL with radeonsi, make sure your LLVM and Mesa SVN/Git snapshots are up to date as of today. However, I'm afraid your success with OpenCL doesn't necessarily mean anything for the graphics problem, as the latter involves much more complex hardware state setup. -- 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 65254] opengl flicker in xbmc / glxgears
https://bugs.freedesktop.org/show_bug.cgi?id=65254 --- Comment #8 from Vladi --- updated last night to 3.10.0-rc4 + mesa git + xf86-video-ati git and I am now seeing lockups during playback / navigating the UI in xbmc.. will try and track it down further. -- 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 v3] drm: Renesas R-Car Display Unit DRM driver
Hi Daniel,
On Tuesday 04 June 2013 16:12:36 Daniel Vetter wrote:
> On Tue, Jun 04, 2013 at 04:53:40AM +0200, Laurent Pinchart wrote:
> > The R-Car Display Unit (DU) DRM driver supports both superposition
> > processors and all eight planes in RGB and YUV formats with alpha
> > blending.
> >
> > Only VGA and LVDS encoders and connectors are currently supported.
> >
> > Signed-off-by: Laurent Pinchart
> >
>
> Ok, I've done a little review, and the driver looks rather nice.
Thank you.
> With a simpler driver like this the drm boilerplate sticks out more, so I've
> dropped a few grumblings about that. But I've also spotted 3 little things
> which imo should be fixed before merging. Comments inline below.
>
> Cheers, Daniel
[snip]
> > diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> > b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c new file mode 100644
> > index 000..c66fa4c
> > --- /dev/null
> > +++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
[snip]
> > +static void rcar_du_start_stop(struct rcar_du_device *rcdu, bool start)
> > +{
> > + /* Many of the configuration bits are only updated when the display
> > +* reset (DRES) bit in DSYSR is set to 1, disabling *both* CRTCs.
> > +* Some of those bits could be pre-configured, but others (especially
> > +* the bits related to plane assignment to display timing
> > +* controllers) need to be modified at runtime.
> > +*
> > +* Restart the display controller if a start is requested. Sorry for
> > +* the flicker. It should be possible to move most of the "DRES-
> > +* update" bits setup to driver initialization time and minimize the
> > +* number of cases when the display controller will have to be
> > +* restarted.
> > +*/
> > + if (start) {
> > + if (rcdu->used_crtcs++ != 0)
> > + __rcar_du_start_stop(rcdu, false);
> > + __rcar_du_start_stop(rcdu, true);
> > + } else {
> > + if (--rcdu->used_crtcs == 0)
> > + __rcar_du_start_stop(rcdu, false);
> > + }
> > +}
>
> You seem to be a prime user for atomic modeset stuff ;-) Have you looked
> already a bit into sensible additions for the crtc helpers to make that
> possible? Maybe a global modeset_prepare/commit hook?
Not yet. That's somewhere in my to-do list, but it's growing too long :-( I
need to finish CDF first.
[snip]
> > +static int rcar_du_crtc_mode_set(struct drm_crtc *crtc,
> > +struct drm_display_mode *mode,
> > +struct drm_display_mode *adjusted_mode,
> > +int x, int y,
> > +struct drm_framebuffer *old_fb)
> > +{
> > + struct rcar_du_device *rcdu = crtc->dev->dev_private;
> > + struct rcar_du_crtc *rcrtc = to_rcar_crtc(crtc);
> > + const struct rcar_du_format_info *format;
> > + int ret;
> > +
> > + format = rcar_du_format_info(crtc->fb->pixel_format);
> > + if (format == NULL) {
> > + dev_dbg(rcdu->dev, "mode_set: unsupported format %08x\n",
> > + crtc->fb->pixel_format);
> > + ret = -EINVAL;
> > + goto error;
> > + }
> > +
> > + ret = rcar_du_plane_reserve(rcrtc->plane, format);
> > + if (ret < 0)
> > + goto error;
> > +
> > + rcrtc->plane->format = format;
> > + rcrtc->plane->pitch = crtc->fb->pitches[0];
> > +
> > + rcrtc->plane->src_x = x;
> > + rcrtc->plane->src_y = y;
> > + rcrtc->plane->width = mode->hdisplay;
> > + rcrtc->plane->height = mode->vdisplay;
> > +
> > + rcar_du_plane_compute_base(rcrtc->plane, crtc->fb);
> > +
> > + rcrtc->outputs = 0;
> > +
> > + return 0;
> > +
> > +error:
> > + /* There's no rollback/abort operation to clean up in case of error.
> > +* We thus need to release the reference to the DU acquired in
> > +* prepare() here.
> > +*/
>
> Should we add that to crtc helpers, instead of the current "just try to
> smash the old config on top of the ill-defined hw state after a failed
> modeset"?
It would probably make sense to add a rollback operation to undo the prepare
operation, or maybe just a rollback/commit flag to the commit operation. We
would still need to smash the old config back though, as the rollback
operation shouldn't be expected to handle encoders and connectors.
While we're at it, shouldn't we make drivers report supported formats for the
main frame buffer, like we do for planes ? That would allow catching format
errors before calling the prepare operation.
> > + rcar_du_put(rcdu);
> > + return ret;
> > +}
[snip]
> > +static void rcar_du_crtc_finish_page_flip(struct rcar_du_crtc *rcrtc)
> > +{
> > + struct drm_pending_vblank_event *event;
> > + struct drm_device *dev = rcrtc->crtc.dev;
> > + struct timeval vblanktime;
> > + unsigned long flags;
> > +
> > + spin_lock_irqsave(&dev->event_lock, flags);
> > + event = rcrtc->event;
> > + rcrtc->event = NULL;
> > + spin_unlock_irqrestore(&de
Re: [PATCH v2 2/5] drm/omap: Use drm_gem_mmap_obj() to implement dma-buf mmap
Hi Rob, On Tuesday 04 June 2013 07:33:42 Rob Clark wrote: > On Mon, Jun 3, 2013 at 10:20 PM, Laurent Pinchart wrote: > > The dma-buf mmap code was copied from the GEM mmap implementation. > > Replace it with the new drm_gem_mmap_obj() function. > > > > Signed-off-by: Laurent Pinchart > > > > Reviewed-by: Rob Clark Thanks. Any chance you would have time to review 3/5 to 5/5 ? :-) -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3] drm: Renesas R-Car Display Unit DRM driver
On Tue, Jun 4, 2013 at 8:03 PM, Laurent Pinchart
wrote:
> Hi Daniel,
>
> On Tuesday 04 June 2013 16:12:36 Daniel Vetter wrote:
>> On Tue, Jun 04, 2013 at 04:53:40AM +0200, Laurent Pinchart wrote:
[snip]
>> Should we add that to crtc helpers, instead of the current "just try to
>> smash the old config on top of the ill-defined hw state after a failed
>> modeset"?
>
> It would probably make sense to add a rollback operation to undo the prepare
> operation, or maybe just a rollback/commit flag to the commit operation. We
> would still need to smash the old config back though, as the rollback
> operation shouldn't be expected to handle encoders and connectors.
>
> While we're at it, shouldn't we make drivers report supported formats for the
> main frame buffer, like we do for planes ? That would allow catching format
> errors before calling the prepare operation.
Yeah, I've noticed that one, too. I guess we could tackle that as part
of an eventual "make the implicit primary plane a bit more explict"
project. For now I'm not too offended by the duplication of checks.
>> This should use the drm_send_vblank_event helper.
>
> What bothers me about drm_send_vblank_event() is that it calls
> drm_vblank_count_and_time() with the events lock unnecessarily held. I can
> live with that for now, I'll fix the driver to use the helper.
Most other drivers protect a bit of other state with that lock, so
makes sense to hold it outside already. So not sure whether we should
optimize this much ...
>> > + drm_vblank_put(dev, rcrtc->index);
>> > +}
>
> [snip]
>
>> > diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
>> > b/drivers/gpu/drm/rcar-du/rcar_du_drv.c new file mode 100644
>> > index 000..003b34e
>> > --- /dev/null
>> > +++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
>
> [snip]
>
>> > +static void rcar_du_disable_vblank(struct drm_device *dev, int crtc)
>> > +{
>> > + struct rcar_du_device *rcdu = dev->dev_private;
>> > +
>> > + rcar_du_crtc_enable_vblank(&rcdu->crtcs[crtc], false);
>> > +}
>>
>> Blergh, I hate our legacy vblank code which forces kms driver to jump
>> through int pipe -> struct drm_crtc * hoops.
>
> How would you like to fix it ? :-)
Haven't looked at the details, but the first step I have in mind is to
switch all drm core -> driver and driver -> vblank helper interfaces
from int pipe to struct drm_crtc * pointers for kms drivers. That
would allow us to implement at least sane locking for the vblank wait
ioctl (by grabbing the crtc mutex).
My plan was to split things by copy&pasting new kms functions and then
garbage-collecting all unnused features for the ums code (iirc no ums
driver ever supported more than 2 crtcs, vblank events or
high-precision timestamps).
Once that's in place we can look into more stuff. One of the things I
want to play with is support for hw timestamp and vblank counters
(also for pageflips). Then we don't have to enable the vblank
interrupt so often and more important should be able to turn it of
right away without loosing precision due to the potential vblank irq
vs. vblank irq off race.
>> where i counts encoders to say that you can clone itself (userspace might
>> get confused, haven't checked how throughout the modeset ddx is). But it
>> sounds like rcar can clone encoders pretty freely (as long as they're
>> using crtc 0), so maybe you want to use something like drm/i915 does?
>
> The device has two outputs, 0 and 1. Output 0 can be driven by CRTC 0 only,
> and output 1 can be driven by CRTC 0 or CRTC 1.
Ah, that explains it, I've missed the context that we only have 2
crtc/encoder pairs ;-)
>> We smash all cloneable encoders into one groub with a
>> intel_encoder->cloneable flag and then allow cloning any cloneable encoder
>> to any other cloneable encoder with intel_encoder_clones in
>> intel_display.c
>>
>> possible_clones is a bit a ill-defined part of the kms api, but I think we
>> still should strive for consistency. Maybe the modesetting ddx should also
>> grow a warning if the possible_clones mask doesn't make too much sense.
>
> I haven't been able to find an authoritative source of documentation regarding
> whether the possible_clones field should include the encoder itself. That
> should definitely be documented, I can fix the driver accordingly.
Yeah, sounds like something worth clarifying. I'd vote for the
self-clone bit to be set (I'm biased though, that's what i915 does). I
guess we could even enforce consistency by putting this into the drm
encoders.
Since the modesetting driver seems to not care too much I guess we can
fix that later on, imo not something to block merging rcar on.
[snip]
>> > +static int rcar_du_vga_connector_get_modes(struct drm_connector
>> > *connector)
>> > +{
>> > + return drm_add_modes_noedid(connector, 1280, 768);
>> > +}
>>
>> This (and the dummy detect function below) looks a bit funny, since it
>> essentially overrides the default behaviour already provided by the crtc
>> helpers. Until rcar has at least p
Re: [PATCH] nouveau: Load firmware for BSP/VP engines on NV84-NV96, NVA0
On Mon, Jun 3, 2013 at 5:02 AM, Ilia Mirkin wrote:
> These chipsets include the VP2 engine which is composed of a bitstream
> processor (BSP) that decodes H.264 and a video processor (VP) which can
> do iDCT/mo-comp/etc for MPEG1/2, H.264, and VC-1. Both of these are
> driven by separate xtensa chips embedded in the hardware. This patch
> provides the mechanism to load the kernel for the xtensa chips and
> provide the necessary interactions to do the rest of the work.
>
> Signed-off-by: Ilia Mirkin
> ---
>
> This patch applies on top of nouveau/master (16a41bcc8).
>
> This seems to work for me. There was one boot where my userspace
> component didn't work right, but it could just as well be a bug
> there. Subsequent attempts seem to work fine. Note that I'm not
> particularly familiar with any of this stuff, so if something looks
> odd, I probably didn't know any better. I did try to faithfully
> reproduce whatever the blob did. A few questions/thoughts:
>
> 1. There's a LOT of similarity between BSP and VP setup/etc. Is it
>worth it to create a core/xtensa.c or some such, similar to
>falcon.c? Since it's only in two places, not that much code, and
>there _are_ differences, I decided to keep them separate.
>
> 2. Firmware naming. Maarten suggested to use the falcon naming style,
>which is nv$chipset_fuc$offset. However here, all the chips share
>the same firmware. Also the offset would be 103 vs 00f, and is a
>little arbitrary. (And fuc doesn't apply here... xt? xtensa?) I've
>left it the way I had it: nv84_bsp and nv84_vp.
>
> 3. Firmware load time. I chose to load the fw into memory in the ctor,
>and then copy it in in init, due to some potentially bogus
>suspend/resume concerns. Also e.g. mplayer likes to create/destroy
>decoders at startup a few times. The downside is that ~200KB of
>memory is gone. Let me know if I should change it to do the
>request_firmware in init.
>
> There's obviously a userspace piece to this, which I'm still working
> on. But right now I have it working within certain parameters
> (e.g. 1280x544 videos), and I'm relatively confident it can be
> completed without further kernel-side changes.
>
> There's also a hypothetical concern of "what if we create an open
> firmware with a different user API". Ideally there'd be some way to
> expose what kind of firmware is loaded, but I think that can be left
> for "later".
I also happened to notice that NV98, NVA1+ refer to these nv84 engines
(in drivers/gpu/drm/nouveau/core/engine/device/nv50.c). I assume that
means I should create a new nv98.c version of BSP/VP that resembles
the old versions of nv84.c, and point device/nv50.c at those for nv98
and nva1+?
>
> drivers/gpu/drm/nouveau/core/engine/bsp/nv84.c | 139 ++-
> drivers/gpu/drm/nouveau/core/engine/fifo/nv84.c | 4 +
> drivers/gpu/drm/nouveau/core/engine/vp/nv84.c | 140
> +++-
> drivers/gpu/drm/nouveau/core/subdev/mc/nv50.c | 1 +
> drivers/gpu/drm/nouveau/core/subdev/vm/nv50.c | 2 +
> 5 files changed, 278 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/core/engine/bsp/nv84.c
> b/drivers/gpu/drm/nouveau/core/engine/bsp/nv84.c
> index 1d9f614..04880d9 100644
> --- a/drivers/gpu/drm/nouveau/core/engine/bsp/nv84.c
> +++ b/drivers/gpu/drm/nouveau/core/engine/bsp/nv84.c
> @@ -29,6 +29,10 @@
>
> struct nv84_bsp_priv {
> struct nouveau_engine base;
> + u32 *fw;
> + long fw_size;
> + struct nouveau_gpuobj *gpu_fw;
> + void *vm_gpu_fw;
> };
>
>
> /***
> @@ -37,6 +41,7 @@ struct nv84_bsp_priv {
>
> static struct nouveau_oclass
> nv84_bsp_sclass[] = {
> + { 0x74b0, &nouveau_object_ofuncs },
> {},
> };
>
> @@ -44,11 +49,28 @@ nv84_bsp_sclass[] = {
> * BSP context
>
> **/
>
> +static int
> +nv84_bsp_engctx_ctor(struct nouveau_object *parent,
> +struct nouveau_object *engine,
> +struct nouveau_oclass *oclass, void *data, u32 size,
> +struct nouveau_object **pobject)
> +{
> + struct nouveau_engctx *engctx;
> + int ret;
> +
> + ret = nouveau_engctx_create(parent, engine, oclass, NULL,
> + 0x1, 0x1000,
> + NVOBJ_FLAG_ZERO_ALLOC, &engctx);
> + *pobject = nv_object(engctx);
> + return ret;
> +}
> +
> +
> static struct nouveau_oclass
> nv84_bsp_cclass = {
> .handle = NV_ENGCTX(BSP, 0x84),
> .ofuncs = &(struct nouveau_ofuncs) {
> - .ctor = _nouveau_engctx_ctor,
> + .ctor = nv84_bsp_engctx_ctor,
> .dtor = _nouveau_engctx_dtor,
> .init = _nouveau_engctx_init,
> .fini = _nouveau_engctx_fini,
> @@ -61,6 +83,24 @@ nv84_
Re: [PATCH v2 3/5] drm: GEM CMA: Split object creation into object alloc and DMA memory alloc
On Mon, Jun 3, 2013 at 10:20 PM, Laurent Pinchart
wrote:
> This allows creating a GEM CMA object without an associated DMA memory
> buffer, and will be used to implement DRM PRIME support.
>
> Signed-off-by: Laurent Pinchart
Reviewed-by: Rob Clark
> ---
> drivers/gpu/drm/drm_gem_cma_helper.c | 83
> +---
> 1 file changed, 48 insertions(+), 35 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_gem_cma_helper.c
> b/drivers/gpu/drm/drm_gem_cma_helper.c
> index 0a7e011..8cce330 100644
> --- a/drivers/gpu/drm/drm_gem_cma_helper.c
> +++ b/drivers/gpu/drm/drm_gem_cma_helper.c
> @@ -32,62 +32,73 @@ static unsigned int get_gem_mmap_offset(struct
> drm_gem_object *obj)
> return (unsigned int)obj->map_list.hash.key << PAGE_SHIFT;
> }
>
> -static void drm_gem_cma_buf_destroy(struct drm_device *drm,
> - struct drm_gem_cma_object *cma_obj)
> -{
> - dma_free_writecombine(drm->dev, cma_obj->base.size, cma_obj->vaddr,
> - cma_obj->paddr);
> -}
> -
> /*
> - * drm_gem_cma_create - allocate an object with the given size
> + * __drm_gem_cma_create - Create a GEM CMA object without allocating memory
> + * @drm: The drm device
> + * @size: The GEM object size
> *
> - * returns a struct drm_gem_cma_object* on success or ERR_PTR values
> - * on failure.
> + * This function creates and initializes a GEM CMA object of the given size,
> but
> + * doesn't allocate any memory to back the object.
> + *
> + * Return a struct drm_gem_cma_object* on success or ERR_PTR values on
> failure.
> */
> -struct drm_gem_cma_object *drm_gem_cma_create(struct drm_device *drm,
> - unsigned int size)
> +static struct drm_gem_cma_object *
> +__drm_gem_cma_create(struct drm_device *drm, unsigned int size)
> {
> struct drm_gem_cma_object *cma_obj;
> struct drm_gem_object *gem_obj;
> int ret;
>
> - size = round_up(size, PAGE_SIZE);
> -
> cma_obj = kzalloc(sizeof(*cma_obj), GFP_KERNEL);
> if (!cma_obj)
> return ERR_PTR(-ENOMEM);
>
> - cma_obj->vaddr = dma_alloc_writecombine(drm->dev, size,
> - &cma_obj->paddr, GFP_KERNEL | __GFP_NOWARN);
> - if (!cma_obj->vaddr) {
> - dev_err(drm->dev, "failed to allocate buffer with size %d\n",
> size);
> - ret = -ENOMEM;
> - goto err_dma_alloc;
> - }
> -
> gem_obj = &cma_obj->base;
>
> ret = drm_gem_object_init(drm, gem_obj, size);
> if (ret)
> - goto err_obj_init;
> + goto error;
>
> ret = drm_gem_create_mmap_offset(gem_obj);
> - if (ret)
> - goto err_create_mmap_offset;
> + if (ret) {
> + drm_gem_object_release(gem_obj);
> + goto error;
> + }
>
> return cma_obj;
>
> -err_create_mmap_offset:
> - drm_gem_object_release(gem_obj);
> +error:
> + kfree(cma_obj);
> + return ERR_PTR(ret);
> +}
>
> -err_obj_init:
> - drm_gem_cma_buf_destroy(drm, cma_obj);
> +/*
> + * drm_gem_cma_create - allocate an object with the given size
> + *
> + * returns a struct drm_gem_cma_object* on success or ERR_PTR values
> + * on failure.
> + */
> +struct drm_gem_cma_object *drm_gem_cma_create(struct drm_device *drm,
> + unsigned int size)
> +{
> + struct drm_gem_cma_object *cma_obj;
>
> -err_dma_alloc:
> - kfree(cma_obj);
> + size = round_up(size, PAGE_SIZE);
>
> - return ERR_PTR(ret);
> + cma_obj = __drm_gem_cma_create(drm, size);
> + if (IS_ERR(cma_obj))
> + return cma_obj;
> +
> + cma_obj->vaddr = dma_alloc_writecombine(drm->dev, size,
> + &cma_obj->paddr, GFP_KERNEL | __GFP_NOWARN);
> + if (!cma_obj->vaddr) {
> + dev_err(drm->dev, "failed to allocate buffer with size %d\n",
> + size);
> + drm_gem_cma_free_object(&cma_obj->base);
> + return ERR_PTR(-ENOMEM);
> + }
> +
> + return cma_obj;
> }
> EXPORT_SYMBOL_GPL(drm_gem_cma_create);
>
> @@ -143,11 +154,13 @@ void drm_gem_cma_free_object(struct drm_gem_object
> *gem_obj)
> if (gem_obj->map_list.map)
> drm_gem_free_mmap_offset(gem_obj);
>
> - drm_gem_object_release(gem_obj);
> -
> cma_obj = to_drm_gem_cma_obj(gem_obj);
>
> - drm_gem_cma_buf_destroy(gem_obj->dev, cma_obj);
> + if (cma_obj->vaddr)
> + dma_free_writecombine(gem_obj->dev->dev, cma_obj->base.size,
> + cma_obj->vaddr, cma_obj->paddr);
> +
> + drm_gem_object_release(gem_obj);
>
> kfree(cma_obj);
> }
> --
> 1.8.1.5
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 4/5] drm: GEM CMA: Split object mapping into GEM mapping and CMA mapping
On Mon, Jun 3, 2013 at 10:20 PM, Laurent Pinchart
wrote:
> The CMA-specific mapping code will be used to implement dma-buf mmap
> support.
>
> Signed-off-by: Laurent Pinchart
Signed-off-by: Rob Clark
> ---
> drivers/gpu/drm/drm_gem_cma_helper.c | 22 +++---
> 1 file changed, 15 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_gem_cma_helper.c
> b/drivers/gpu/drm/drm_gem_cma_helper.c
> index 8cce330..7a4db4e 100644
> --- a/drivers/gpu/drm/drm_gem_cma_helper.c
> +++ b/drivers/gpu/drm/drm_gem_cma_helper.c
> @@ -228,13 +228,26 @@ const struct vm_operations_struct drm_gem_cma_vm_ops = {
> };
> EXPORT_SYMBOL_GPL(drm_gem_cma_vm_ops);
>
> +static int drm_gem_cma_mmap_obj(struct drm_gem_cma_object *cma_obj,
> + struct vm_area_struct *vma)
> +{
> + int ret;
> +
> + ret = remap_pfn_range(vma, vma->vm_start, cma_obj->paddr >>
> PAGE_SHIFT,
> + vma->vm_end - vma->vm_start, vma->vm_page_prot);
> + if (ret)
> + drm_gem_vm_close(vma);
> +
> + return ret;
> +}
> +
> /*
> * drm_gem_cma_mmap - (struct file_operation)->mmap callback function
> */
> int drm_gem_cma_mmap(struct file *filp, struct vm_area_struct *vma)
> {
> - struct drm_gem_object *gem_obj;
> struct drm_gem_cma_object *cma_obj;
> + struct drm_gem_object *gem_obj;
> int ret;
>
> ret = drm_gem_mmap(filp, vma);
> @@ -244,12 +257,7 @@ int drm_gem_cma_mmap(struct file *filp, struct
> vm_area_struct *vma)
> gem_obj = vma->vm_private_data;
> cma_obj = to_drm_gem_cma_obj(gem_obj);
>
> - ret = remap_pfn_range(vma, vma->vm_start, cma_obj->paddr >>
> PAGE_SHIFT,
> - vma->vm_end - vma->vm_start, vma->vm_page_prot);
> - if (ret)
> - drm_gem_vm_close(vma);
> -
> - return ret;
> + return drm_gem_cma_mmap_obj(cma_obj, vma);
> }
> EXPORT_SYMBOL_GPL(drm_gem_cma_mmap);
>
> --
> 1.8.1.5
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 60879] [radeonsi] X11 can't start with acceleration enabled
https://bugs.freedesktop.org/show_bug.cgi?id=60879
--- Comment #37 from Hristo Venev ---
I updated llvm, clang and mesa. Division and modulo still don't work. Another
thing I noticed is that ifs which depend on memory loads cause llvm crash:
__kernel void add(__global const uint *a, __global const uint *b, __global
uint *c){
ulong id=get_global_id(0); // OK
if(id>10) return; // OK
if(b[id]==0) return; // crash
c[id]=a[id]/b[id]; // GPU hang
}
a[id] is id+1
b[id] is 2*id+2
Stack dump:
0.Running pass 'Function Pass Manager' on module 'radeon'.
1.Running pass 'AMDGPU DAG->DAG Pattern Instruction Selection' on function
'@add'
Segmentation fault
#0 0x7461c8a7 in ?? () from /usr/lib64/llvm/libLLVM-3.4svn.so
#1 0x73e36208 in llvm::SelectionDAGISel::DoInstructionSelection() ()
from /usr/lib64/llvm/libLLVM-3.4svn.so
#2 0x73e3c620 in llvm::SelectionDAGISel::CodeGenAndEmitDAG() () from
/usr/lib64/llvm/libLLVM-3.4svn.so
#3 0x73e3e0f2 in
llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&) () from
/usr/lib64/llvm/libLLVM-3.4svn.so
#4 0x73e3f421 in
llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) () from
/usr/lib64/llvm/libLLVM-3.4svn.so
#5 0x73acaeb2 in llvm::FPPassManager::runOnFunction(llvm::Function&)
() from /usr/lib64/llvm/libLLVM-3.4svn.so
#6 0x73acaf4b in llvm::FPPassManager::runOnModule(llvm::Module&) ()
from /usr/lib64/llvm/libLLVM-3.4svn.so
#7 0x73acb195 in llvm::MPPassManager::runOnModule(llvm::Module&) ()
from /usr/lib64/llvm/libLLVM-3.4svn.so
#8 0x73acd1dc in llvm::PassManagerImpl::run(llvm::Module&) () from
/usr/lib64/llvm/libLLVM-3.4svn.so
#9 0x7417c009 in ?? () from /usr/lib64/llvm/libLLVM-3.4svn.so
#10 0x7417c382 in LLVMTargetMachineEmitToMemoryBuffer () from
/usr/lib64/llvm/libLLVM-3.4svn.so
#11 0x72ae6ab1 in radeon_llvm_compile () from
/usr/lib64/gallium-pipe/pipe_radeonsi.so
#12 0x72adc65d in si_compile_llvm () from
/usr/lib64/gallium-pipe/pipe_radeonsi.so
#13 0x72adef79 in ?? () from /usr/lib64/gallium-pipe/pipe_radeonsi.so
#14 0x76d882a7 in _cl_kernel::exec_context::bind(_cl_command_queue*) ()
from /usr/lib64/libOpenCL.so.1
#15 0x76d88e46 in _cl_kernel::launch(_cl_command_queue&,
std::vector > const&,
std::vector > const&,
std::vector > const&) () from
/usr/lib64/libOpenCL.so.1
#16 0x76d847dc in _cl_event::trigger() () from
/usr/lib64/libOpenCL.so.1
#17 0x76d84e54 in clover::hard_event::hard_event(_cl_command_queue&,
unsigned int, std::vector<_cl_event*, std::allocator<_cl_event*> >,
std::function) ()
from /usr/lib64/libOpenCL.so.1
#18 0x76d9fad5 in clEnqueueNDRangeKernel () from
/usr/lib64/libOpenCL.so.1
--
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 65377] New: Backlight control via /sys/class/backlight/radeon_bl0 not working
https://bugs.freedesktop.org/show_bug.cgi?id=65377 Priority: medium Bug ID: 65377 Assignee: dri-devel@lists.freedesktop.org Summary: Backlight control via /sys/class/backlight/radeon_bl0 not working Severity: normal Classification: Unclassified OS: Linux (All) Reporter: bastian.tril...@gmail.com Hardware: x86-64 (AMD64) Status: NEW Version: XOrg CVS Component: DRM/Radeon Product: DRI This is a Macbook pro 8,2 with an Intel HD Graphics 3000 [8086:0116] and an AMD Radeon HD 6750M [1002:6741]. The backlight interface in /sys/class/backlight/radeon_bl0 does not work. Echoing to "brightness" does not change the brightness of the Monitor. There is also an apple_gmux interface, which works though. I've bound xbacklight to the brightness keys to control the brightness, but it looks like it's confused about which interface it should use: $ xbacklight -inc 5 No outputs have backlight property When I disable the Radeon card on boot and use the Intel card, xbacklight works. -- 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 65377] Backlight control via /sys/class/backlight/radeon_bl0 not working
https://bugs.freedesktop.org/show_bug.cgi?id=65377 --- Comment #1 from Alex Deucher --- If you are booting in EFI mode, does it work if you boot in legacy bios mode? Since it's a mac, it probably requires some mac specific hack. -- 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
[REGRESSION] nouveau: Resume hung after protecting against client races (MBA3,1)
Hi Ben, The new mutexes in nvc0/nv50 (fadb17190/b509656) break resume on my MBA3,1. A dead-lock somewhere, perhaps? Reverting fixes the problem. Thanks, Henrik ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [REGRESSION] nouveau: Resume hung after protecting against client races (MBA3,1)
On Tue, Jun 4, 2013 at 4:48 PM, Henrik Rydberg wrote: > Hi Ben, > > The new mutexes in nvc0/nv50 (fadb17190/b509656) break resume on my > MBA3,1. A dead-lock somewhere, perhaps? Reverting fixes the problem. A bunch of people saw it earlier. Fixed for nv50 (which is what I assume you have) in http://cgit.freedesktop.org/nouveau/linux-2.6/commit/?id=e9de89adcecb7a1296f5bc4d0052f58e18edd0a8 I assume it's on its way to mainline. -ilia ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 65377] Backlight control via /sys/class/backlight/radeon_bl0 not working
https://bugs.freedesktop.org/show_bug.cgi?id=65377 --- Comment #2 from Bastian Triller --- (In reply to comment #1) > If you are booting in EFI mode, does it work if you boot in legacy bios > mode? Since it's a mac, it probably requires some mac specific hack. I'm booting via EFI stub. I'm not sure how to boot the bios emulation mode. Is it possible to plug in a usb stick with a "normal" live system to boot in emulation mode? -- 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 65377] Backlight control via /sys/class/backlight/radeon_bl0 not working
https://bugs.freedesktop.org/show_bug.cgi?id=65377 --- Comment #3 from Alex Deucher --- (In reply to comment #2) > I'm booting via EFI stub. I'm not sure how to boot the bios emulation mode. > Is it possible to plug in a usb stick with a "normal" live system to boot in > emulation mode? I'm not sure. -- 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 60879] [radeonsi] X11 can't start with acceleration enabled
https://bugs.freedesktop.org/show_bug.cgi?id=60879 --- Comment #38 from Tom Stellard --- The OpenCL failures are unrelated to the original bug, so can you please file a separate bug for them. This bug has been outstanding for a while, and it seems like there are actually several "bugs". Could you please summarize the problems you are currently having and list the versions or git HEAD commits that you are using for glamor, xf86-video-ati, Xorg server, Linux kernel, Mesa, and LLVM. Thanks. -- 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 v2 5/5] drm: GEM CMA: Add DRM PRIME support
couple small comments, other than those it looks ok
BR,
-R
On Mon, Jun 3, 2013 at 10:20 PM, Laurent Pinchart
wrote:
> Signed-off-by: Laurent Pinchart
> ---
> drivers/gpu/drm/drm_gem_cma_helper.c | 321
> ++-
> include/drm/drm_gem_cma_helper.h | 9 +
> 2 files changed, 327 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_gem_cma_helper.c
> b/drivers/gpu/drm/drm_gem_cma_helper.c
> index 7a4db4e..1dc2157 100644
> --- a/drivers/gpu/drm/drm_gem_cma_helper.c
> +++ b/drivers/gpu/drm/drm_gem_cma_helper.c
> @@ -21,6 +21,9 @@
> #include
> #include
> #include
> +#if CONFIG_DMA_SHARED_BUFFER
> +#include
> +#endif
I don't think we need the #if, since drm selects DMA_SHARED_BUFFER
and same for other spot below
> #include
>
> #include
> @@ -82,6 +85,8 @@ struct drm_gem_cma_object *drm_gem_cma_create(struct
> drm_device *drm,
> unsigned int size)
> {
> struct drm_gem_cma_object *cma_obj;
> + struct sg_table *sgt = NULL;
> + int ret;
>
> size = round_up(size, PAGE_SIZE);
>
> @@ -94,11 +99,29 @@ struct drm_gem_cma_object *drm_gem_cma_create(struct
> drm_device *drm,
> if (!cma_obj->vaddr) {
> dev_err(drm->dev, "failed to allocate buffer with size %d\n",
> size);
> - drm_gem_cma_free_object(&cma_obj->base);
> - return ERR_PTR(-ENOMEM);
> + ret = -ENOMEM;
> + goto error;
> }
>
> + sgt = kzalloc(sizeof(*cma_obj->sgt), GFP_KERNEL);
> + if (sgt == NULL) {
> + ret = -ENOMEM;
> + goto error;
> + }
> +
> + ret = dma_get_sgtable(drm->dev, sgt, cma_obj->vaddr,
> + cma_obj->paddr, size);
> + if (ret < 0)
> + goto error;
> +
> + cma_obj->sgt = sgt;
> +
> return cma_obj;
> +
> +error:
> + kfree(sgt);
> + drm_gem_cma_free_object(&cma_obj->base);
> + return ERR_PTR(ret);
> }
> EXPORT_SYMBOL_GPL(drm_gem_cma_create);
>
> @@ -156,9 +179,16 @@ void drm_gem_cma_free_object(struct drm_gem_object
> *gem_obj)
>
> cma_obj = to_drm_gem_cma_obj(gem_obj);
>
> - if (cma_obj->vaddr)
> + if (cma_obj->vaddr) {
> dma_free_writecombine(gem_obj->dev->dev, cma_obj->base.size,
> cma_obj->vaddr, cma_obj->paddr);
> + if (cma_obj->sgt) {
> + sg_free_table(cma_obj->sgt);
> + kfree(cma_obj->sgt);
> + }
> + } else if (gem_obj->import_attach) {
> + drm_prime_gem_destroy(gem_obj, cma_obj->sgt);
> + }
>
> drm_gem_object_release(gem_obj);
>
> @@ -291,3 +321,288 @@ void drm_gem_cma_describe(struct drm_gem_cma_object
> *cma_obj, struct seq_file *m
> }
> EXPORT_SYMBOL_GPL(drm_gem_cma_describe);
> #endif
> +
> +/*
> -
> + * DMA-BUF
> + */
> +
> +#if CONFIG_DMA_SHARED_BUFFER
> +struct drm_gem_cma_dmabuf_attachment {
> + struct sg_table sgt;
> + enum dma_data_direction dir;
> +};
> +
> +static int drm_gem_cma_dmabuf_attach(struct dma_buf *dmabuf, struct device
> *dev,
> +struct dma_buf_attachment *attach)
> +{
> + struct drm_gem_cma_dmabuf_attachment *cma_attach;
> +
> + cma_attach = kzalloc(sizeof(*cma_attach), GFP_KERNEL);
> + if (!cma_attach)
> + return -ENOMEM;
> +
> + cma_attach->dir = DMA_NONE;
> + attach->priv = cma_attach;
> +
> + return 0;
> +}
> +
> +static void drm_gem_cma_dmabuf_detach(struct dma_buf *dmabuf,
> + struct dma_buf_attachment *attach)
> +{
> + struct drm_gem_cma_dmabuf_attachment *cma_attach = attach->priv;
> + struct sg_table *sgt;
> +
> + if (cma_attach == NULL)
> + return;
> +
> + sgt = &cma_attach->sgt;
> +
> + if (cma_attach->dir != DMA_NONE)
> + dma_unmap_sg(attach->dev, sgt->sgl, sgt->nents,
> + cma_attach->dir);
> +
> + sg_free_table(sgt);
> + kfree(cma_attach);
> + attach->priv = NULL;
> +}
> +
> +static struct sg_table *
> +drm_gem_cma_dmabuf_map(struct dma_buf_attachment *attach,
> + enum dma_data_direction dir)
> +{
> + struct drm_gem_cma_dmabuf_attachment *cma_attach = attach->priv;
> + struct drm_gem_cma_object *cma_obj = attach->dmabuf->priv;
> + struct drm_device *drm = cma_obj->base.dev;
> + struct scatterlist *rd, *wr;
> + struct sg_table *sgt;
> + unsigned int i;
> + int nents, ret;
> +
> + DRM_DEBUG_PRIME("\n");
> +
> + if (WARN_ON(dir == DMA_NONE))
> + return ERR_PTR(-EINVAL);
> +
> + /* Return the cached mapping when possible. */
> + if (cma_attach->dir == dir)
> +
[pull] radeon drm-fixes-3.10
From: Alex Deucher Hi Dave, Just a few fixes for radeon. The big one is a fix for hangs on older asics due to the ordering of interrupt initialization. The following changes since commit 91f8f105f2b82b4a38dee2d74760bc39d40ec42c: drm/mgag200: Add missing write to index before accessing data register (2013-06-03 19:21:07 +1000) are available in the git repository at: git://people.freedesktop.org/~agd5f/linux drm-fixes-3.10 Adis Hamzić (1): radeon: Fix system hang issue when using KMS with older cards Alex Deucher (1): drm/radeon: don't allow audio on DCE6 Samuel Li (1): drm/radeon: Use direct mapping for fast fb access on RS780/RS880 (v2) drivers/gpu/drm/radeon/atombios_encoders.c | 11 -- drivers/gpu/drm/radeon/evergreen.c | 10 +++-- drivers/gpu/drm/radeon/ni.c| 10 +++-- drivers/gpu/drm/radeon/r100.c |9 +++-- drivers/gpu/drm/radeon/r300.c |9 +++-- drivers/gpu/drm/radeon/r420.c | 10 +++-- drivers/gpu/drm/radeon/r520.c |9 +++-- drivers/gpu/drm/radeon/r600.c | 53 +-- drivers/gpu/drm/radeon/r600d.h |8 drivers/gpu/drm/radeon/radeon_asic.c |4 ++ drivers/gpu/drm/radeon/radeon_asic.h |2 + drivers/gpu/drm/radeon/rs400.c |9 +++-- drivers/gpu/drm/radeon/rs600.c |9 +++-- drivers/gpu/drm/radeon/rs690.c |9 +++-- drivers/gpu/drm/radeon/rv515.c |9 +++-- drivers/gpu/drm/radeon/rv770.c | 10 +++-- drivers/gpu/drm/radeon/si.c| 10 +++-- 17 files changed, 143 insertions(+), 48 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 65192] [r600g] Screensavers lock up machine (screen goes blank, keyboard unresponsive, sound loops; sysrq/ssh possible)
https://bugs.freedesktop.org/show_bug.cgi?id=65192 --- Comment #9 from Luzipher --- Unfortunately I couldn't confirm my thoughts. But I still am quite sure I did not have those problems earlier - I had screensavers and youtube last year and didn't notice regular crashes. I frequently use this linux installation, in fact it's my main os for several years now, so I really would have noticed. Maybe it's another package ? X, libdrm, radeon-ucode, xf86-video-ati come to mind. Maybe mostly radeon-ucode, as I have the feeling that the problems started at about the same time as the buzz on the uvd code drop. Well, tests done (I could reproduce the crash on every of these with directly started juggler3d on closing the window, mostly first or second try): mesa-9.0.3 (forgot to get glxinfo) mesa-9.0.1.ebuild, glxinfo: OpenGL renderer string: Gallium 0.4 on AMD RV770 OpenGL version string: 3.0 Mesa 9.0.1 OpenGL shading language version string: 1.30 mesa-8.0.4-r1.ebuild, glxinfo: OpenGL renderer string: Gallium 0.4 on AMD RV770 OpenGL version string: 2.1 Mesa 8.0.4 OpenGL shading language version string: 1.20 with 8.0.4, I got only garbage and a lot of these messages: radeon: The kernel rejected CS, see dmesg for more information. dmesg: [ 1580.805418] radeon :02:00.0: r600_cs_track_validate_cb invalid tiling 6 for 0 (0x08110668) [ 1580.805463] radeon :02:00.0: r600_packet3_check:1720 invalid cmd stream 573 [ 1580.805465] [drm:radeon_cs_ib_chunk] *ERROR* Invalid command stream ! I also tried the oldest kernel I have with 8.0.4, it's a vanilla 3.4.0-rc6. Even there I could get the same crash after closing the window with the garbage output. -- 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 v2 5/5] drm: GEM CMA: Add DRM PRIME support
Hi Rob,
On Tuesday 04 June 2013 17:56:36 Rob Clark wrote:
> couple small comments, other than those it looks ok
Thanks for the review.
> On Mon, Jun 3, 2013 at 10:20 PM, Laurent Pinchart wrote:
> > Signed-off-by: Laurent Pinchart
> >
> > ---
> >
> > drivers/gpu/drm/drm_gem_cma_helper.c | 321 +-
> > include/drm/drm_gem_cma_helper.h | 9 +
> > 2 files changed, 327 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_gem_cma_helper.c
> > b/drivers/gpu/drm/drm_gem_cma_helper.c index 7a4db4e..1dc2157 100644
> > --- a/drivers/gpu/drm/drm_gem_cma_helper.c
> > +++ b/drivers/gpu/drm/drm_gem_cma_helper.c
> > @@ -21,6 +21,9 @@
> > #include
> > #include
> > #include
> > +#if CONFIG_DMA_SHARED_BUFFER
> > +#include
> > +#endif
>
> I don't think we need the #if, since drm selects DMA_SHARED_BUFFER
>
> and same for other spot below
Indeed. Will be fixed in the next version.
> > #include
> >
> > #include
[snip]
> > @@ -291,3 +321,288 @@ void drm_gem_cma_describe(struct drm_gem_cma_object
> > *cma_obj, struct seq_file *m>
> > }
> > EXPORT_SYMBOL_GPL(drm_gem_cma_describe);
> > #endif
> >
> > +
> > +/*
> > -
> > + * DMA-BUF
> > + */
> > +
> > +#if CONFIG_DMA_SHARED_BUFFER
> > +struct drm_gem_cma_dmabuf_attachment {
> > + struct sg_table sgt;
> > + enum dma_data_direction dir;
> > +};
> > +
> > +static int drm_gem_cma_dmabuf_attach(struct dma_buf *dmabuf, struct
> > device *dev, +struct
> > dma_buf_attachment *attach) +{
> > + struct drm_gem_cma_dmabuf_attachment *cma_attach;
> > +
> > + cma_attach = kzalloc(sizeof(*cma_attach), GFP_KERNEL);
> > + if (!cma_attach)
> > + return -ENOMEM;
> > +
> > + cma_attach->dir = DMA_NONE;
> > + attach->priv = cma_attach;
> > +
> > + return 0;
> > +}
> > +
> > +static void drm_gem_cma_dmabuf_detach(struct dma_buf *dmabuf,
> > + struct dma_buf_attachment *attach)
> > +{
> > + struct drm_gem_cma_dmabuf_attachment *cma_attach = attach->priv;
> > + struct sg_table *sgt;
> > +
> > + if (cma_attach == NULL)
> > + return;
> > +
> > + sgt = &cma_attach->sgt;
> > +
> > + if (cma_attach->dir != DMA_NONE)
> > + dma_unmap_sg(attach->dev, sgt->sgl, sgt->nents,
> > + cma_attach->dir);
> > +
> > + sg_free_table(sgt);
> > + kfree(cma_attach);
> > + attach->priv = NULL;
> > +}
> > +
> > +static struct sg_table *
> > +drm_gem_cma_dmabuf_map(struct dma_buf_attachment *attach,
> > + enum dma_data_direction dir)
> > +{
> > + struct drm_gem_cma_dmabuf_attachment *cma_attach = attach->priv;
> > + struct drm_gem_cma_object *cma_obj = attach->dmabuf->priv;
> > + struct drm_device *drm = cma_obj->base.dev;
> > + struct scatterlist *rd, *wr;
> > + struct sg_table *sgt;
> > + unsigned int i;
> > + int nents, ret;
> > +
> > + DRM_DEBUG_PRIME("\n");
> > +
> > + if (WARN_ON(dir == DMA_NONE))
> > + return ERR_PTR(-EINVAL);
> > +
> > + /* Return the cached mapping when possible. */
> > + if (cma_attach->dir == dir)
> > + return &cma_attach->sgt;
> > +
> > + /* Two mappings with different directions for the same attachment
> > are +* not allowed.
> > +*/
> > + if (WARN_ON(cma_attach->dir != DMA_NONE))
> > + return ERR_PTR(-EBUSY);
> > +
> > + sgt = &cma_attach->sgt;
> > +
> > + ret = sg_alloc_table(sgt, cma_obj->sgt->orig_nents, GFP_KERNEL);
> > + if (ret) {
> > + DRM_ERROR("failed to alloc sgt.\n");
> > + return ERR_PTR(-ENOMEM);
> > + }
> > +
> > + mutex_lock(&drm->struct_mutex);
> > +
> > + rd = cma_obj->sgt->sgl;
> > + wr = sgt->sgl;
> > + for (i = 0; i < sgt->orig_nents; ++i) {
> > + sg_set_page(wr, sg_page(rd), rd->length, rd->offset);
> > + rd = sg_next(rd);
> > + wr = sg_next(wr);
> > + }
> > +
> > + nents = dma_map_sg(attach->dev, sgt->sgl, sgt->orig_nents, dir);
> > + if (!nents) {
> > + DRM_ERROR("failed to map sgl with iommu.\n");
> > + sg_free_table(sgt);
> > + sgt = ERR_PTR(-EIO);
> > + goto done;
> > + }
> > +
> > + cma_attach->dir = dir;
> > + attach->priv = cma_attach;
> > +
> > + DRM_DEBUG_PRIME("buffer size = %zu\n", cma_obj->base.size);
> > +
> > +done:
> > + mutex_unlock(&drm->struct_mutex);
> > + return sgt;
> > +}
> > +
> > +static void drm_gem_cma_dmabuf_unmap(struct dma_buf_attachment *attach,
> > +struct sg_table *sgt,
> > +enum dma_data_direction dir)
> > +
Re: [PATCH v3] drm: Renesas R-Car Display Unit DRM driver
Hi Daniel,
On Tuesday 04 June 2013 20:36:20 Daniel Vetter wrote:
> On Tue, Jun 4, 2013 at 8:03 PM, Laurent Pinchart wrote:
> > On Tuesday 04 June 2013 16:12:36 Daniel Vetter wrote:
> >> On Tue, Jun 04, 2013 at 04:53:40AM +0200, Laurent Pinchart wrote:
>
> [snip]
>
> >> Should we add that to crtc helpers, instead of the current "just try to
> >> smash the old config on top of the ill-defined hw state after a failed
> >> modeset"?
> >
> > It would probably make sense to add a rollback operation to undo the
> > prepare operation, or maybe just a rollback/commit flag to the commit
> > operation. We would still need to smash the old config back though, as
> > the rollback operation shouldn't be expected to handle encoders and
> > connectors.
> >
> > While we're at it, shouldn't we make drivers report supported formats for
> > the main frame buffer, like we do for planes ? That would allow catching
> > format errors before calling the prepare operation.
>
> Yeah, I've noticed that one, too. I guess we could tackle that as part
> of an eventual "make the implicit primary plane a bit more explict"
> project. For now I'm not too offended by the duplication of checks.
It would be nice to treat the primary plane as all the other planes. Several
embedded display engines don't make the primary plane special and just paint
the background with a plain color when the enabled planes don't cover the
entire display.
> >> This should use the drm_send_vblank_event helper.
> >
> > What bothers me about drm_send_vblank_event() is that it calls
> > drm_vblank_count_and_time() with the events lock unnecessarily held. I can
> > live with that for now, I'll fix the driver to use the helper.
>
> Most other drivers protect a bit of other state with that lock, so
> makes sense to hold it outside already. So not sure whether we should
> optimize this much ...
Probably not :-)
> >> > + drm_vblank_put(dev, rcrtc->index);
> >> > +}
> >
> > [snip]
> >
> >> > diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> >> > b/drivers/gpu/drm/rcar-du/rcar_du_drv.c new file mode 100644
> >> > index 000..003b34e
> >> > --- /dev/null
> >> > +++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> >
> > [snip]
> >
> >> > +static void rcar_du_disable_vblank(struct drm_device *dev, int crtc)
> >> > +{
> >> > + struct rcar_du_device *rcdu = dev->dev_private;
> >> > +
> >> > + rcar_du_crtc_enable_vblank(&rcdu->crtcs[crtc], false);
> >> > +}
> >>
> >> Blergh, I hate our legacy vblank code which forces kms driver to jump
> >> through int pipe -> struct drm_crtc * hoops.
> >
> > How would you like to fix it ? :-)
>
> Haven't looked at the details, but the first step I have in mind is to
> switch all drm core -> driver and driver -> vblank helper interfaces from
> int pipe to struct drm_crtc * pointers for kms drivers. That would allow us
> to implement at least sane locking for the vblank wait ioctl (by grabbing
> the crtc mutex).
>
> My plan was to split things by copy&pasting new kms functions and then
> garbage-collecting all unnused features for the ums code (iirc no ums driver
> ever supported more than 2 crtcs, vblank events or high-precision
> timestamps).
>
> Once that's in place we can look into more stuff. One of the things I want
> to play with is support for hw timestamp and vblank counters (also for
> pageflips). Then we don't have to enable the vblank interrupt so often and
> more important should be able to turn it of right away without loosing
> precision due to the potential vblank irq vs. vblank irq off race.
>
> >> where i counts encoders to say that you can clone itself (userspace might
> >> get confused, haven't checked how throughout the modeset ddx is). But it
> >> sounds like rcar can clone encoders pretty freely (as long as they're
> >> using crtc 0), so maybe you want to use something like drm/i915 does?
> >
> > The device has two outputs, 0 and 1. Output 0 can be driven by CRTC 0
> > only, and output 1 can be driven by CRTC 0 or CRTC 1.
>
> Ah, that explains it, I've missed the context that we only have 2
> crtc/encoder pairs ;-)
It wasn't particularly explicit :-)
> >> We smash all cloneable encoders into one groub with a
> >> intel_encoder->cloneable flag and then allow cloning any cloneable
> >> encoder to any other cloneable encoder with intel_encoder_clones in
> >> intel_display.c
> >>
> >> possible_clones is a bit a ill-defined part of the kms api, but I think
> >> we still should strive for consistency. Maybe the modesetting ddx should
> >> also grow a warning if the possible_clones mask doesn't make too much
> >> sense.
> >
> > I haven't been able to find an authoritative source of documentation
> > regarding whether the possible_clones field should include the encoder
> > itself. That should definitely be documented, I can fix the driver
> > accordingly.
>
> Yeah, sounds like something worth clarifying. I'd vote for the self-clone
> bit to be set (I'm biased though, that's what i915 does). I guess
Re: [PATCH] drm: Add kernel-doc for plane functions
Hi Ville,
Thank you for the patch.
On Tuesday 04 June 2013 10:58:35 ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/drm_crtc.c | 31 +++
> 1 file changed, 31 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index f00ba75..f1f11e1 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -795,6 +795,21 @@ void drm_encoder_cleanup(struct drm_encoder *encoder)
> }
> EXPORT_SYMBOL(drm_encoder_cleanup);
>
> +/**
> + * drm_plane_init - Initialise a new plane object
> + * @dev: DRM device
> + * @plane: plane object to init
> + * @possible_crtcs: bitmask of possible CRTCs
> + * @funcs: callbacks for the new plane
> + * @formats: array of supported formats (%DRM_FORMAT_*)
> + * @format_count: number of elements in @formats
> + * @priv: plane is private (hidden from userspace)?
> + *
> + * Inits a new object created as base part of an driver plane object.
s/an driver/a driver/
> + *
> + * RETURNS:
> + * Zero on success, error code on failure.
> + */
> int drm_plane_init(struct drm_device *dev, struct drm_plane *plane,
> unsigned long possible_crtcs,
> const struct drm_plane_funcs *funcs,
> @@ -843,6 +858,13 @@ int drm_plane_init(struct drm_device *dev, struct
> drm_plane *plane, }
> EXPORT_SYMBOL(drm_plane_init);
>
> +/**
> + * drm_plane_cleanup - Cleans up the core plane usage.
Nitpicking, you could remove the full stop at the end of the line to be
consistent with the other two kerneldoc blocks.
And s/Cleans/Clean/
> + * @plane: plane to cleanup
> + *
> + * Cleanup @plane. Removes from drm modesetting space
> + * does NOT free object, caller does that.
As this is documentation, I'd use a more verbose style.
This function clean up @plane and removes it from the DRM mode setting core.
Note that the function does *not* free the plane structure itself, this is the
responsibility of the caller.
> + */
> void drm_plane_cleanup(struct drm_plane *plane)
> {
> struct drm_device *dev = plane->dev;
> @@ -859,6 +881,15 @@ void drm_plane_cleanup(struct drm_plane *plane)
> }
> EXPORT_SYMBOL(drm_plane_cleanup);
>
> +/**
> + * drm_plane_force_disable - Forcibly disable a plane
> + * @plane: plane to disable
> + *
> + * Forces the plane to be disabled.
This feels a bit unclear to me. In particular, how is "force_disable"
different from just disabling the plane ? Maybe the function should be renamed
to drm_plane_disable(), and the documentation updated to mention that the
function just disables the plane and disassociate with from its frame buffer.
> + *
> + * Used when the plane's current framebuffer is destroyed,
> + * and when restoring fbdev mode.
> + */
> void drm_plane_force_disable(struct drm_plane *plane)
> {
> int ret;
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC][PATCH 0/2] dma-buf: add importer private data for reimporting
On 2013년 06월 04일 21:55, Daniel Vetter wrote:
> On Tue, Jun 04, 2013 at 07:42:22PM +0900, 김승우 wrote:
>>
>>
>> On 2013년 06월 01일 00:29, Daniel Vetter wrote:
>>> On Fri, May 31, 2013 at 07:22:24PM +0900, 김승우 wrote:
Hello Daniel,
Thanks for your comment.
On 2013년 05월 31일 18:14, Daniel Vetter wrote:
> On Fri, May 31, 2013 at 10:54 AM, Seung-Woo Kim
> wrote:
>> importer private data in dma-buf attachment can be used by importer to
>> reimport same dma-buf.
>>
>> Seung-Woo Kim (2):
>> dma-buf: add importer private data to attachment
>> drm/prime: find gem object from the reimported dma-buf
>
> Self-import should already work (at least with the latest refcount
> fixes merged). At least the tests to check both re-import on the same
> drm fd and on a different all work as expected now.
Currently, prime works well for all case including self-importing,
importing, and reimporting as you describe. Just, importing dma-buf from
other driver twice with different drm_fd, each import create its own gem
object even two import is done for same buffer because prime_priv is in
struct drm_file. This means mapping to the device is done also twice.
IMHO, these duplicated creations and maps are not necessary if drm can
find previous import in different prime_priv.
>>>
>>> Well, that's imo a bug with the other driver. If it doesn't export
>>> something really simple (e.g. contiguous memory which doesn't require any
>>> mmio resources at all) it should have a cache of exported dma_buf fds so
>>> that it hands out the same dma_buf every time.
>>
>> Hm, all existing dma-buf exporter including i915 driver implements its
>> map_dma_buf callback as allocating scatter-gather table with pages in
>> its buffer and calling dma_map_sg() with the sgt. With different
>> drm_fds, importing one dma-buf *twice*, then importer calls
>> dma_buf_attach() and dma_buf_map_attachment() twice at least in drm
>> importer because re-importing case can only checked with prime_priv in
>> drm_file as I described.
>
> Well, but thanks to all the self-import and re-import checks, it's
> _impossible_ to import the same dma_buf twice without noticing (presuming
> both importer and exporter are drm devices).
No, it is possible. Prime function, drm_gem_prime_fd_to_handle(), checks
re-import with following code.
ret = drm_prime_lookup_buf_handle(&file_priv->prime,
dma_buf, handle);
Unfortunately, file_priv is allocated per each open of drm node so this
code can only find re-import within same drm open context.
And driver specific import functions, like drm_gem_prime_import(), only
check self-import like following code.
if (dma_buf->ops == &drm_gem_prime_dmabuf_ops) {
obj = dma_buf->priv;
if (obj->dev == dev) {
/* ... */
}
}
This means some application like following can make re-import to
different gem objects.
int drm_fd1, drm_fd2, ret;
int dma_buf_fd;
struct drm_prime_handle prime1, prime2;
drm_fd1 = open(DRM_NODE, O_RDWR, 0);
drm_fd2 = open(DRM_NODE, O_RDWR, 0);
/* get some dma-buf_fd from other dma-buf exporter */
prime1.fd = dma_buf_fd;
prime2.fd = dma_buf_fd;
ret = ioctl(drm_fd1, DRM_IOCTL_PRIME_FD_TO_HANDLE, &prime1);
ret = ioctl(drm_fd2, DRM_IOCTL_PRIME_FD_TO_HANDLE, &prime2);
This will import same dma-buf twice as different GEM object because
above checking codes can not check already imported gem object from the
dma-buf.
>>
>>>
>>> Or it needs to be more clever in it's dma_buf_attachment_map functions and
>>> lookup up a pre-existing iommu mapping.
>>>
>>> But dealing with this in the importer is just broken.
>>>
> Second, the dma_buf_attachment is _definitely_ the wrong place to do
> this. If you need iommu mapping caching, that should happen at a lower
> level (i.e. in the map_attachment callback somewhere of the exporter,
> that's what the priv field in the attachment is for). Snatching away
> the attachement from some random other import is certainly not the way
> to go - attachements are _not_ refcounted!
Yes, attachments do not have refcount, so importer should handle and drm
case in my patch, importer private data is gem object and it has, of
course, refcount.
And at current, exporter can not classify map_dma_buf requests of same
importer to same buffer with different attachment because dma_buf_attach
always makes new attachments. To resolve this exporter should search all
different attachment from same importer of dma-buf and it seems more
complex than importer private data to me.
If I misunderstood something, please let me know.
>>>
>>> Like I've said above, just fix this in the exporter. If an importer sees
>>> two different dma_bufs it can very well presume that it those two indeed
>>> point to different backing storage.
>>
>> Yes, my patch does not break this concept. I just fix
Re: [PATCH v2 5/5] drm: GEM CMA: Add DRM PRIME support
On Tue, Jun 4, 2013 at 9:22 PM, Laurent Pinchart
wrote:
> Hi Rob,
>
> On Tuesday 04 June 2013 17:56:36 Rob Clark wrote:
>> couple small comments, other than those it looks ok
>
> Thanks for the review.
>
>> On Mon, Jun 3, 2013 at 10:20 PM, Laurent Pinchart wrote:
>> > Signed-off-by: Laurent Pinchart
>> >
>> > ---
>> >
>> > drivers/gpu/drm/drm_gem_cma_helper.c | 321 +-
>> > include/drm/drm_gem_cma_helper.h | 9 +
>> > 2 files changed, 327 insertions(+), 3 deletions(-)
>> >
>> > diff --git a/drivers/gpu/drm/drm_gem_cma_helper.c
>> > b/drivers/gpu/drm/drm_gem_cma_helper.c index 7a4db4e..1dc2157 100644
>> > --- a/drivers/gpu/drm/drm_gem_cma_helper.c
>> > +++ b/drivers/gpu/drm/drm_gem_cma_helper.c
>> > @@ -21,6 +21,9 @@
>> > #include
>> > #include
>> > #include
>> > +#if CONFIG_DMA_SHARED_BUFFER
>> > +#include
>> > +#endif
>>
>> I don't think we need the #if, since drm selects DMA_SHARED_BUFFER
>>
>> and same for other spot below
>
> Indeed. Will be fixed in the next version.
>
>> > #include
>> >
>> > #include
>
> [snip]
>
>> > @@ -291,3 +321,288 @@ void drm_gem_cma_describe(struct drm_gem_cma_object
>> > *cma_obj, struct seq_file *m>
>> > }
>> > EXPORT_SYMBOL_GPL(drm_gem_cma_describe);
>> > #endif
>> >
>> > +
>> > +/*
>> > -
>> > + * DMA-BUF
>> > + */
>> > +
>> > +#if CONFIG_DMA_SHARED_BUFFER
>> > +struct drm_gem_cma_dmabuf_attachment {
>> > + struct sg_table sgt;
>> > + enum dma_data_direction dir;
>> > +};
>> > +
>> > +static int drm_gem_cma_dmabuf_attach(struct dma_buf *dmabuf, struct
>> > device *dev, +struct
>> > dma_buf_attachment *attach) +{
>> > + struct drm_gem_cma_dmabuf_attachment *cma_attach;
>> > +
>> > + cma_attach = kzalloc(sizeof(*cma_attach), GFP_KERNEL);
>> > + if (!cma_attach)
>> > + return -ENOMEM;
>> > +
>> > + cma_attach->dir = DMA_NONE;
>> > + attach->priv = cma_attach;
>> > +
>> > + return 0;
>> > +}
>> > +
>> > +static void drm_gem_cma_dmabuf_detach(struct dma_buf *dmabuf,
>> > + struct dma_buf_attachment *attach)
>> > +{
>> > + struct drm_gem_cma_dmabuf_attachment *cma_attach = attach->priv;
>> > + struct sg_table *sgt;
>> > +
>> > + if (cma_attach == NULL)
>> > + return;
>> > +
>> > + sgt = &cma_attach->sgt;
>> > +
>> > + if (cma_attach->dir != DMA_NONE)
>> > + dma_unmap_sg(attach->dev, sgt->sgl, sgt->nents,
>> > + cma_attach->dir);
>> > +
>> > + sg_free_table(sgt);
>> > + kfree(cma_attach);
>> > + attach->priv = NULL;
>> > +}
>> > +
>> > +static struct sg_table *
>> > +drm_gem_cma_dmabuf_map(struct dma_buf_attachment *attach,
>> > + enum dma_data_direction dir)
>> > +{
>> > + struct drm_gem_cma_dmabuf_attachment *cma_attach = attach->priv;
>> > + struct drm_gem_cma_object *cma_obj = attach->dmabuf->priv;
>> > + struct drm_device *drm = cma_obj->base.dev;
>> > + struct scatterlist *rd, *wr;
>> > + struct sg_table *sgt;
>> > + unsigned int i;
>> > + int nents, ret;
>> > +
>> > + DRM_DEBUG_PRIME("\n");
>> > +
>> > + if (WARN_ON(dir == DMA_NONE))
>> > + return ERR_PTR(-EINVAL);
>> > +
>> > + /* Return the cached mapping when possible. */
>> > + if (cma_attach->dir == dir)
>> > + return &cma_attach->sgt;
>> > +
>> > + /* Two mappings with different directions for the same attachment
>> > are +* not allowed.
>> > +*/
>> > + if (WARN_ON(cma_attach->dir != DMA_NONE))
>> > + return ERR_PTR(-EBUSY);
>> > +
>> > + sgt = &cma_attach->sgt;
>> > +
>> > + ret = sg_alloc_table(sgt, cma_obj->sgt->orig_nents, GFP_KERNEL);
>> > + if (ret) {
>> > + DRM_ERROR("failed to alloc sgt.\n");
>> > + return ERR_PTR(-ENOMEM);
>> > + }
>> > +
>> > + mutex_lock(&drm->struct_mutex);
>> > +
>> > + rd = cma_obj->sgt->sgl;
>> > + wr = sgt->sgl;
>> > + for (i = 0; i < sgt->orig_nents; ++i) {
>> > + sg_set_page(wr, sg_page(rd), rd->length, rd->offset);
>> > + rd = sg_next(rd);
>> > + wr = sg_next(wr);
>> > + }
>> > +
>> > + nents = dma_map_sg(attach->dev, sgt->sgl, sgt->orig_nents, dir);
>> > + if (!nents) {
>> > + DRM_ERROR("failed to map sgl with iommu.\n");
>> > + sg_free_table(sgt);
>> > + sgt = ERR_PTR(-EIO);
>> > + goto done;
>> > + }
>> > +
>> > + cma_attach->dir = dir;
>> > + attach->priv = cma_attach;
>> > +
>> > + DRM_DEBUG_PRIME("buffer size = %zu\n", cma_obj->base.size);
>> > +
>> > +done:
>> > + mutex_unlock(&drm->struct_mutex);
>> > + return sgt;
>> > +}
>> > +
>> >
[Bug 64257] RS880 issues with r600-llvm-compiler
https://bugs.freedesktop.org/show_bug.cgi?id=64257 --- Comment #30 from Tom Stellard --- Can you try this branch: http://cgit.freedesktop.org/~tstellar/llvm/log/?h=r600-gen-fixes I think it should fix the remaining issues. -- 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
[PATCH] radeon: correct RADEON_GEM_WAIT_IDLE use
RADEON_GEM_WAIT_IDLE is declared DRM_IOW but libdrm
uses it with drmCommandWriteRead instead of drmCommandWrite
which leads to the ioctl being unmatched and returning an
error on at least OpenBSD.
Problem noticed by and patch from Mark Kettenis.
Signed-off-by: Jonathan Gray
---
radeon/radeon_bo_gem.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git radeon/radeon_bo_gem.c radeon/radeon_bo_gem.c
index fca0aaf..4ea405f 100644
--- radeon/radeon_bo_gem.c
+++ radeon/radeon_bo_gem.c
@@ -211,8 +211,8 @@ static int bo_wait(struct radeon_bo_int *boi)
memset(&args, 0, sizeof(args));
args.handle = boi->handle;
do {
-ret = drmCommandWriteRead(boi->bom->fd, DRM_RADEON_GEM_WAIT_IDLE,
- &args, sizeof(args));
+ret = drmCommandWrite(boi->bom->fd, DRM_RADEON_GEM_WAIT_IDLE,
+ &args, sizeof(args));
} while (ret == -EBUSY);
return ret;
}
--
1.8.2.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/exynos: remove ignoring return value warning in hdmi
The definition of regulator_bulk_enable is fixed with __must_check
and this causes following build warning.
warning: ignoring return value of 'regulator_bulk_enable',
declared with attribute warn_unused_result
This patch fixes to check return value of the function.
Signed-off-by: Seung-Woo Kim
---
drivers/gpu/drm/exynos/exynos_hdmi.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 2f78532..f807b13 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -1699,7 +1699,9 @@ static void hdmi_poweron(struct hdmi_context *hdata)
mutex_unlock(&hdata->hdmi_mutex);
- regulator_bulk_enable(res->regul_count, res->regul_bulk);
+ if (regulator_bulk_enable(res->regul_count, res->regul_bulk))
+ DRM_ERROR("failed to enable regulator bulk\n");
+
clk_enable(res->hdmiphy);
clk_enable(res->hdmi);
clk_enable(res->sclk_hdmi);
--
1.7.4.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 64867] Hangs on Cayman (HD6950) when watching flash/using vdpau
https://bugs.freedesktop.org/show_bug.cgi?id=64867 --- Comment #3 from Alex Deucher --- (In reply to comment #2) > I too get system hangs when watching a flash video in firefox. linux-3.8.13, > libdrm, mesa etc. git. Screen simply becomes black (no signal) and machine > is dead, leaving a hard reset as the only option. The dmesg is flooded with > the following lines: > > radeon :01:00.0: GPU fault detected: 147 0x0d859002 > radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x12D8 > radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x05090002 > [...] repeated a hundred times with only the first line changing a bit [...] Something in the mesa drivers is emitting a command buffer without a proper virtual address for CB5. -- 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/20130604/e744e933/attachment.html>
[PATCH] video: display_timing: make parameter const
Hi,
On Monday 27 May 2013 14:33:05 Lucas Stach wrote:
> From: Steffen Trumtrar
>
> As the device_node pointer is not changed in of_get_display_timing and
> parse_timing_property it can be a const pointer.
>
> Signed-off-by: Steffen Trumtrar
Acked-by: Laurent Pinchart
> ---
> drivers/video/of_display_timing.c |5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/video/of_display_timing.c
> b/drivers/video/of_display_timing.c index 56009bc..85c1a41 100644
> --- a/drivers/video/of_display_timing.c
> +++ b/drivers/video/of_display_timing.c
> @@ -23,7 +23,7 @@
> * Every display_timing can be specified with either just the typical value
> or * a range consisting of min/typ/max. This function helps handling this
> **/
> -static int parse_timing_property(struct device_node *np, const char *name,
> +static int parse_timing_property(const struct device_node *np, const char
> *name, struct timing_entry *result)
> {
> struct property *prop;
> @@ -56,7 +56,8 @@ static int parse_timing_property(struct device_node *np,
> const char *name, * of_get_display_timing - parse display_timing entry from
> device_node * @np: device_node with the properties
> **/
> -static struct display_timing *of_get_display_timing(struct device_node *np)
> +static struct display_timing *of_get_display_timing(const struct
> device_node + *np)
> {
> struct display_timing *dt;
> u32 val = 0;
--
Regards,
Laurent Pinchart
[PATCH v2 1/3] drm: Add drm_plane_force_disable()
Hi Ville,
Thanks for the patch.
On Monday 03 June 2013 16:10:40 ville.syrjala at linux.intel.com wrote:
> From: Ville Syrj?l?
>
> drm_plane_force_disable() will forcibly disable the plane even if user
> had previously requested the plane to be enabled.
>
> This can be used to force planes to be off when restoring the fbdev
> mode.
>
> The code was simply pulled from drm_framebuffer_remove(), which now
> calls the new function as well.
>
> v2: Check plane->fb in drm_plane_force_disable(), drop bogus comment
> about disabling crtc
>
> Signed-off-by: Ville Syrj?l?
> ---
> drivers/gpu/drm/drm_crtc.c | 29 +++--
> include/drm/drm_crtc.h | 1 +
> 2 files changed, 20 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index e7e9242..865ebfe 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -569,16 +569,8 @@ void drm_framebuffer_remove(struct drm_framebuffer *fb)
> }
>
> list_for_each_entry(plane, &dev->mode_config.plane_list, head) {
> - if (plane->fb == fb) {
> - /* should turn off the crtc */
> - ret = plane->funcs->disable_plane(plane);
> - if (ret)
> - DRM_ERROR("failed to disable plane with
> busy fb\n");
> - /* disconnect the plane from the fb and crtc: */
> - __drm_framebuffer_unreference(plane->fb);
> - plane->fb = NULL;
> - plane->crtc = NULL;
> - }
> + if (plane->fb == fb)
> + drm_plane_force_disable(plane);
> }
> drm_modeset_unlock_all(dev);
> }
> @@ -867,6 +859,23 @@ void drm_plane_cleanup(struct drm_plane *plane)
> }
> EXPORT_SYMBOL(drm_plane_cleanup);
What about adding kerneldoc ? :-)
> +void drm_plane_force_disable(struct drm_plane *plane)
> +{
> + int ret;
> +
> + if (!plane->fb)
> + return;
> +
> + ret = plane->funcs->disable_plane(plane);
> + if (ret)
> + DRM_ERROR("failed to disable plane with busy fb\n");
> + /* disconnect the plane from the fb and crtc: */
> + __drm_framebuffer_unreference(plane->fb);
> + plane->fb = NULL;
> + plane->crtc = NULL;
> +}
> +EXPORT_SYMBOL(drm_plane_force_disable);
> +
> /**
> * drm_mode_create - create a new display mode
> * @dev: DRM device
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index adb3f9b..db7a885 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -894,6 +894,7 @@ extern int drm_plane_init(struct drm_device *dev,
> const uint32_t *formats, uint32_t format_count,
> bool priv);
> extern void drm_plane_cleanup(struct drm_plane *plane);
> +extern void drm_plane_force_disable(struct drm_plane *plane);
>
> extern void drm_encoder_cleanup(struct drm_encoder *encoder);
--
Regards,
Laurent Pinchart
[Bug 65327] New: running gnubik produces a segfault
https://bugs.freedesktop.org/show_bug.cgi?id=65327
Priority: medium
Bug ID: 65327
Assignee: dri-devel at lists.freedesktop.org
Summary: running gnubik produces a segfault
Severity: normal
Classification: Unclassified
OS: Linux (All)
Reporter: pinode at gmail.com
Hardware: x86 (IA32)
Status: NEW
Version: unspecified
Component: DRM/Radeon
Product: DRI
Created attachment 80263
--> https://bugs.freedesktop.org/attachment.cgi?id=80263&action=edit
bt full
X.Org X Server 1.13.3
Fedora release 18 (Spherical Cow)
bash-4.2$ lspci -v|grep ATI
02:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI RV350
AP [Radeon 9600] (prog-if 00 [VGA controller])
02:00.1 Display controller: Advanced Micro Devices [AMD] nee ATI RV350 AP
[Radeon 9600] (Secondary)
When I run gnubik (a game), the program segfaults immediately:
bash-4.2$ gnubik
Segmentation fault (core dumped)
bash-4.2$ dmesg|tail -n 1
[ 5769.578454] gnubik[7155]: segfault at 0 ip (null) sp bfafcbbc
error 4 in gnubik[8048000+16000]
bash-4.2$ rpm -q gnubik
gnubik-2.4-5.fc18.i686
bash-4.2$ gnubik -v|head -n 1
2.4
#0 0x in ?? ()
#1 0xb217e6f4 in generic_run () from /usr/lib/dri/r300_dri.so
#2 0xb214ae9c in draw_pt_fetch_run_linear ()
from /usr/lib/dri/r300_dri.so
it segfaults on line 646
(gdb) l translate/translate_generic.c:646
641 copy_size = tg->attrib[attr].copy_size;
642 if(likely(copy_size >= 0))
643memcpy(dst, src, copy_size);
644 else
645 {
646tg->attrib[attr].fetch( data, src, 0, 0 );
647
648if (0)
649 debug_printf("Fetch linear attr %d from %p
stride %d index %d: " 650 " %f, %f,
%f, %f \n", (gdb)
the bugtrace is attached
Should any additional info be required, I may provide it.
--
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/20130604/9fa8fbfc/attachment.html>
[PATCH v2 1/5] drm/gem: Split drm_gem_mmap() into object search and object mapping
The drm_gem_mmap() function first finds the GEM object to be mapped
based on the fake mmap offset and then maps the object. Split the object
mapping code into a standalone drm_gem_mmap_obj() function that can be
used to implement dma-buf mmap() operations.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/drm_gem.c | 83 +--
include/drm/drmP.h| 2 ++
2 files changed, 54 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index cf919e3..4321713 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -644,6 +644,55 @@ void drm_gem_vm_close(struct vm_area_struct *vma)
}
EXPORT_SYMBOL(drm_gem_vm_close);
+/**
+ * drm_gem_mmap_obj - memory map a GEM object
+ * @obj: the GEM object to map
+ * @obj_size: the object size to be mapped, in bytes
+ * @vma: VMA for the area to be mapped
+ *
+ * Set up the VMA to prepare mapping of the GEM object using the gem_vm_ops
+ * provided by the driver. Depending on their requirements, drivers can either
+ * provide a fault handler in their gem_vm_ops (in which case any accesses to
+ * the object will be trapped, to perform migration, GTT binding, surface
+ * register allocation, or performance monitoring), or mmap the buffer memory
+ * synchronously after calling drm_gem_mmap_obj.
+ *
+ * This function is mainly intended to implement the DMABUF mmap operation,
when
+ * the GEM object is not looked up based on its fake offset. To implement the
+ * DRM mmap operation, drivers should use the drm_gem_mmap() function.
+ *
+ * Return 0 or success or -EINVAL if the object size is smaller than the VMA
+ * size, or if no gem_vm_ops are provided.
+ */
+int drm_gem_mmap_obj(struct drm_gem_object *obj, unsigned long obj_size,
+struct vm_area_struct *vma)
+{
+ struct drm_device *dev = obj->dev;
+
+ /* Check for valid size. */
+ if (obj_size < vma->vm_end - vma->vm_start)
+ return -EINVAL;
+
+ if (!dev->driver->gem_vm_ops)
+ return -EINVAL;
+
+ vma->vm_flags |= VM_IO | VM_PFNMAP | VM_DONTEXPAND | VM_DONTDUMP;
+ vma->vm_ops = dev->driver->gem_vm_ops;
+ vma->vm_private_data = obj;
+ vma->vm_page_prot =
pgprot_writecombine(vm_get_page_prot(vma->vm_flags));
+
+ /* Take a ref for this mapping of the object, so that the fault
+* handler can dereference the mmap offset's pointer to the object.
+* This reference is cleaned up by the corresponding vm_close
+* (which should happen whether the vma was created by this call, or
+* by a vm_open due to mremap or partial unmap or whatever).
+*/
+ drm_gem_object_reference(obj);
+
+ drm_vm_open_locked(dev, vma);
+ return 0;
+}
+EXPORT_SYMBOL(drm_gem_mmap_obj);
/**
* drm_gem_mmap - memory map routine for GEM objects
@@ -653,11 +702,9 @@ EXPORT_SYMBOL(drm_gem_vm_close);
* If a driver supports GEM object mapping, mmap calls on the DRM file
* descriptor will end up here.
*
- * If we find the object based on the offset passed in (vma->vm_pgoff will
+ * Look up the GEM object based on the offset passed in (vma->vm_pgoff will
* contain the fake offset we created when the GTT map ioctl was called on
- * the object), we set up the driver fault handler so that any accesses
- * to the object can be trapped, to perform migration, GTT binding, surface
- * register allocation, or performance monitoring.
+ * the object) and map it with a call to drm_gem_mmap_obj().
*/
int drm_gem_mmap(struct file *filp, struct vm_area_struct *vma)
{
@@ -665,7 +712,6 @@ int drm_gem_mmap(struct file *filp, struct vm_area_struct
*vma)
struct drm_device *dev = priv->minor->dev;
struct drm_gem_mm *mm = dev->mm_private;
struct drm_local_map *map = NULL;
- struct drm_gem_object *obj;
struct drm_hash_item *hash;
int ret = 0;
@@ -686,32 +732,7 @@ int drm_gem_mmap(struct file *filp, struct vm_area_struct
*vma)
goto out_unlock;
}
- /* Check for valid size. */
- if (map->size < vma->vm_end - vma->vm_start) {
- ret = -EINVAL;
- goto out_unlock;
- }
-
- obj = map->handle;
- if (!obj->dev->driver->gem_vm_ops) {
- ret = -EINVAL;
- goto out_unlock;
- }
-
- vma->vm_flags |= VM_IO | VM_PFNMAP | VM_DONTEXPAND | VM_DONTDUMP;
- vma->vm_ops = obj->dev->driver->gem_vm_ops;
- vma->vm_private_data = map->handle;
- vma->vm_page_prot =
pgprot_writecombine(vm_get_page_prot(vma->vm_flags));
-
- /* Take a ref for this mapping of the object, so that the fault
-* handler can dereference the mmap offset's pointer to the object.
-* This reference is cleaned up by the corresponding vm_close
-* (which should happen whether the vma was created by this call, or
-* by a vm_open due to mremap or partial un
[PATCH v2 0/5] GEM CMA DMA-BUF support
Hello, Here's the second version of the GEM CMA DMA-BUF support patches. The code is based on the Exynos DRM DMA-BUF implementation. The exporter role has been successfully tested with the Renesas R-Car DU driver. Dave, is there a chance this could make it to v3.11 ? Changes compared to v1: - Added a mixing sg_free_table() in drm_gem_cma_dmabuf_map() - Implement drm_gem_cma_dmabuf_mmap() Laurent Pinchart (5): drm/gem: Split drm_gem_mmap() into object search and object mapping drm/omap: Use drm_gem_mmap_obj() to implement dma-buf mmap drm: GEM CMA: Split object creation into object alloc and DMA memory alloc drm: GEM CMA: Split object mapping into GEM mapping and CMA mapping drm: GEM CMA: Add DRM PRIME support drivers/gpu/drm/drm_gem.c | 83 +++--- drivers/gpu/drm/drm_gem_cma_helper.c | 408 +++--- drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c | 32 +-- include/drm/drmP.h| 2 + include/drm/drm_gem_cma_helper.h | 9 + 5 files changed, 438 insertions(+), 96 deletions(-) -- Regards, Laurent Pinchart
[PATCH v2 3/5] drm: GEM CMA: Split object creation into object alloc and DMA memory alloc
This allows creating a GEM CMA object without an associated DMA memory
buffer, and will be used to implement DRM PRIME support.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/drm_gem_cma_helper.c | 83 +---
1 file changed, 48 insertions(+), 35 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem_cma_helper.c
b/drivers/gpu/drm/drm_gem_cma_helper.c
index 0a7e011..8cce330 100644
--- a/drivers/gpu/drm/drm_gem_cma_helper.c
+++ b/drivers/gpu/drm/drm_gem_cma_helper.c
@@ -32,62 +32,73 @@ static unsigned int get_gem_mmap_offset(struct
drm_gem_object *obj)
return (unsigned int)obj->map_list.hash.key << PAGE_SHIFT;
}
-static void drm_gem_cma_buf_destroy(struct drm_device *drm,
- struct drm_gem_cma_object *cma_obj)
-{
- dma_free_writecombine(drm->dev, cma_obj->base.size, cma_obj->vaddr,
- cma_obj->paddr);
-}
-
/*
- * drm_gem_cma_create - allocate an object with the given size
+ * __drm_gem_cma_create - Create a GEM CMA object without allocating memory
+ * @drm: The drm device
+ * @size: The GEM object size
*
- * returns a struct drm_gem_cma_object* on success or ERR_PTR values
- * on failure.
+ * This function creates and initializes a GEM CMA object of the given size,
but
+ * doesn't allocate any memory to back the object.
+ *
+ * Return a struct drm_gem_cma_object* on success or ERR_PTR values on failure.
*/
-struct drm_gem_cma_object *drm_gem_cma_create(struct drm_device *drm,
- unsigned int size)
+static struct drm_gem_cma_object *
+__drm_gem_cma_create(struct drm_device *drm, unsigned int size)
{
struct drm_gem_cma_object *cma_obj;
struct drm_gem_object *gem_obj;
int ret;
- size = round_up(size, PAGE_SIZE);
-
cma_obj = kzalloc(sizeof(*cma_obj), GFP_KERNEL);
if (!cma_obj)
return ERR_PTR(-ENOMEM);
- cma_obj->vaddr = dma_alloc_writecombine(drm->dev, size,
- &cma_obj->paddr, GFP_KERNEL | __GFP_NOWARN);
- if (!cma_obj->vaddr) {
- dev_err(drm->dev, "failed to allocate buffer with size %d\n",
size);
- ret = -ENOMEM;
- goto err_dma_alloc;
- }
-
gem_obj = &cma_obj->base;
ret = drm_gem_object_init(drm, gem_obj, size);
if (ret)
- goto err_obj_init;
+ goto error;
ret = drm_gem_create_mmap_offset(gem_obj);
- if (ret)
- goto err_create_mmap_offset;
+ if (ret) {
+ drm_gem_object_release(gem_obj);
+ goto error;
+ }
return cma_obj;
-err_create_mmap_offset:
- drm_gem_object_release(gem_obj);
+error:
+ kfree(cma_obj);
+ return ERR_PTR(ret);
+}
-err_obj_init:
- drm_gem_cma_buf_destroy(drm, cma_obj);
+/*
+ * drm_gem_cma_create - allocate an object with the given size
+ *
+ * returns a struct drm_gem_cma_object* on success or ERR_PTR values
+ * on failure.
+ */
+struct drm_gem_cma_object *drm_gem_cma_create(struct drm_device *drm,
+ unsigned int size)
+{
+ struct drm_gem_cma_object *cma_obj;
-err_dma_alloc:
- kfree(cma_obj);
+ size = round_up(size, PAGE_SIZE);
- return ERR_PTR(ret);
+ cma_obj = __drm_gem_cma_create(drm, size);
+ if (IS_ERR(cma_obj))
+ return cma_obj;
+
+ cma_obj->vaddr = dma_alloc_writecombine(drm->dev, size,
+ &cma_obj->paddr, GFP_KERNEL | __GFP_NOWARN);
+ if (!cma_obj->vaddr) {
+ dev_err(drm->dev, "failed to allocate buffer with size %d\n",
+ size);
+ drm_gem_cma_free_object(&cma_obj->base);
+ return ERR_PTR(-ENOMEM);
+ }
+
+ return cma_obj;
}
EXPORT_SYMBOL_GPL(drm_gem_cma_create);
@@ -143,11 +154,13 @@ void drm_gem_cma_free_object(struct drm_gem_object
*gem_obj)
if (gem_obj->map_list.map)
drm_gem_free_mmap_offset(gem_obj);
- drm_gem_object_release(gem_obj);
-
cma_obj = to_drm_gem_cma_obj(gem_obj);
- drm_gem_cma_buf_destroy(gem_obj->dev, cma_obj);
+ if (cma_obj->vaddr)
+ dma_free_writecombine(gem_obj->dev->dev, cma_obj->base.size,
+ cma_obj->vaddr, cma_obj->paddr);
+
+ drm_gem_object_release(gem_obj);
kfree(cma_obj);
}
--
1.8.1.5
[PATCH v2 2/5] drm/omap: Use drm_gem_mmap_obj() to implement dma-buf mmap
The dma-buf mmap code was copied from the GEM mmap implementation.
Replace it with the new drm_gem_mmap_obj() function.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c | 32 +++
1 file changed, 3 insertions(+), 29 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c
b/drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c
index be7cd97..3256693 100644
--- a/drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c
+++ b/drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c
@@ -136,10 +136,6 @@ static void omap_gem_dmabuf_kunmap(struct dma_buf *buffer,
kunmap(pages[page_num]);
}
-/*
- * TODO maybe we can split up drm_gem_mmap to avoid duplicating
- * some here.. or at least have a drm_dmabuf_mmap helper.
- */
static int omap_gem_dmabuf_mmap(struct dma_buf *buffer,
struct vm_area_struct *vma)
{
@@ -149,31 +145,9 @@ static int omap_gem_dmabuf_mmap(struct dma_buf *buffer,
if (WARN_ON(!obj->filp))
return -EINVAL;
- /* Check for valid size. */
- if (omap_gem_mmap_size(obj) < vma->vm_end - vma->vm_start) {
- ret = -EINVAL;
- goto out_unlock;
- }
-
- if (!obj->dev->driver->gem_vm_ops) {
- ret = -EINVAL;
- goto out_unlock;
- }
-
- vma->vm_flags |= VM_IO | VM_PFNMAP | VM_DONTEXPAND | VM_DONTDUMP;
- vma->vm_ops = obj->dev->driver->gem_vm_ops;
- vma->vm_private_data = obj;
- vma->vm_page_prot =
pgprot_writecombine(vm_get_page_prot(vma->vm_flags));
-
- /* Take a ref for this mapping of the object, so that the fault
-* handler can dereference the mmap offset's pointer to the object.
-* This reference is cleaned up by the corresponding vm_close
-* (which should happen whether the vma was created by this call, or
-* by a vm_open due to mremap or partial unmap or whatever).
-*/
- vma->vm_ops->open(vma);
-
-out_unlock:
+ ret = drm_gem_mmap_obj(obj, omap_gem_mmap_size(obj), vma);
+ if (ret < 0)
+ return ret;
return omap_gem_mmap_obj(obj, vma);
}
--
1.8.1.5
[PATCH v2 4/5] drm: GEM CMA: Split object mapping into GEM mapping and CMA mapping
The CMA-specific mapping code will be used to implement dma-buf mmap
support.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/drm_gem_cma_helper.c | 22 +++---
1 file changed, 15 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem_cma_helper.c
b/drivers/gpu/drm/drm_gem_cma_helper.c
index 8cce330..7a4db4e 100644
--- a/drivers/gpu/drm/drm_gem_cma_helper.c
+++ b/drivers/gpu/drm/drm_gem_cma_helper.c
@@ -228,13 +228,26 @@ const struct vm_operations_struct drm_gem_cma_vm_ops = {
};
EXPORT_SYMBOL_GPL(drm_gem_cma_vm_ops);
+static int drm_gem_cma_mmap_obj(struct drm_gem_cma_object *cma_obj,
+ struct vm_area_struct *vma)
+{
+ int ret;
+
+ ret = remap_pfn_range(vma, vma->vm_start, cma_obj->paddr >> PAGE_SHIFT,
+ vma->vm_end - vma->vm_start, vma->vm_page_prot);
+ if (ret)
+ drm_gem_vm_close(vma);
+
+ return ret;
+}
+
/*
* drm_gem_cma_mmap - (struct file_operation)->mmap callback function
*/
int drm_gem_cma_mmap(struct file *filp, struct vm_area_struct *vma)
{
- struct drm_gem_object *gem_obj;
struct drm_gem_cma_object *cma_obj;
+ struct drm_gem_object *gem_obj;
int ret;
ret = drm_gem_mmap(filp, vma);
@@ -244,12 +257,7 @@ int drm_gem_cma_mmap(struct file *filp, struct
vm_area_struct *vma)
gem_obj = vma->vm_private_data;
cma_obj = to_drm_gem_cma_obj(gem_obj);
- ret = remap_pfn_range(vma, vma->vm_start, cma_obj->paddr >> PAGE_SHIFT,
- vma->vm_end - vma->vm_start, vma->vm_page_prot);
- if (ret)
- drm_gem_vm_close(vma);
-
- return ret;
+ return drm_gem_cma_mmap_obj(cma_obj, vma);
}
EXPORT_SYMBOL_GPL(drm_gem_cma_mmap);
--
1.8.1.5
[PATCH v2 5/5] drm: GEM CMA: Add DRM PRIME support
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/drm_gem_cma_helper.c | 321 ++-
include/drm/drm_gem_cma_helper.h | 9 +
2 files changed, 327 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem_cma_helper.c
b/drivers/gpu/drm/drm_gem_cma_helper.c
index 7a4db4e..1dc2157 100644
--- a/drivers/gpu/drm/drm_gem_cma_helper.c
+++ b/drivers/gpu/drm/drm_gem_cma_helper.c
@@ -21,6 +21,9 @@
#include
#include
#include
+#if CONFIG_DMA_SHARED_BUFFER
+#include
+#endif
#include
#include
@@ -82,6 +85,8 @@ struct drm_gem_cma_object *drm_gem_cma_create(struct
drm_device *drm,
unsigned int size)
{
struct drm_gem_cma_object *cma_obj;
+ struct sg_table *sgt = NULL;
+ int ret;
size = round_up(size, PAGE_SIZE);
@@ -94,11 +99,29 @@ struct drm_gem_cma_object *drm_gem_cma_create(struct
drm_device *drm,
if (!cma_obj->vaddr) {
dev_err(drm->dev, "failed to allocate buffer with size %d\n",
size);
- drm_gem_cma_free_object(&cma_obj->base);
- return ERR_PTR(-ENOMEM);
+ ret = -ENOMEM;
+ goto error;
}
+ sgt = kzalloc(sizeof(*cma_obj->sgt), GFP_KERNEL);
+ if (sgt == NULL) {
+ ret = -ENOMEM;
+ goto error;
+ }
+
+ ret = dma_get_sgtable(drm->dev, sgt, cma_obj->vaddr,
+ cma_obj->paddr, size);
+ if (ret < 0)
+ goto error;
+
+ cma_obj->sgt = sgt;
+
return cma_obj;
+
+error:
+ kfree(sgt);
+ drm_gem_cma_free_object(&cma_obj->base);
+ return ERR_PTR(ret);
}
EXPORT_SYMBOL_GPL(drm_gem_cma_create);
@@ -156,9 +179,16 @@ void drm_gem_cma_free_object(struct drm_gem_object
*gem_obj)
cma_obj = to_drm_gem_cma_obj(gem_obj);
- if (cma_obj->vaddr)
+ if (cma_obj->vaddr) {
dma_free_writecombine(gem_obj->dev->dev, cma_obj->base.size,
cma_obj->vaddr, cma_obj->paddr);
+ if (cma_obj->sgt) {
+ sg_free_table(cma_obj->sgt);
+ kfree(cma_obj->sgt);
+ }
+ } else if (gem_obj->import_attach) {
+ drm_prime_gem_destroy(gem_obj, cma_obj->sgt);
+ }
drm_gem_object_release(gem_obj);
@@ -291,3 +321,288 @@ void drm_gem_cma_describe(struct drm_gem_cma_object
*cma_obj, struct seq_file *m
}
EXPORT_SYMBOL_GPL(drm_gem_cma_describe);
#endif
+
+/*
-
+ * DMA-BUF
+ */
+
+#if CONFIG_DMA_SHARED_BUFFER
+struct drm_gem_cma_dmabuf_attachment {
+ struct sg_table sgt;
+ enum dma_data_direction dir;
+};
+
+static int drm_gem_cma_dmabuf_attach(struct dma_buf *dmabuf, struct device
*dev,
+struct dma_buf_attachment *attach)
+{
+ struct drm_gem_cma_dmabuf_attachment *cma_attach;
+
+ cma_attach = kzalloc(sizeof(*cma_attach), GFP_KERNEL);
+ if (!cma_attach)
+ return -ENOMEM;
+
+ cma_attach->dir = DMA_NONE;
+ attach->priv = cma_attach;
+
+ return 0;
+}
+
+static void drm_gem_cma_dmabuf_detach(struct dma_buf *dmabuf,
+ struct dma_buf_attachment *attach)
+{
+ struct drm_gem_cma_dmabuf_attachment *cma_attach = attach->priv;
+ struct sg_table *sgt;
+
+ if (cma_attach == NULL)
+ return;
+
+ sgt = &cma_attach->sgt;
+
+ if (cma_attach->dir != DMA_NONE)
+ dma_unmap_sg(attach->dev, sgt->sgl, sgt->nents,
+ cma_attach->dir);
+
+ sg_free_table(sgt);
+ kfree(cma_attach);
+ attach->priv = NULL;
+}
+
+static struct sg_table *
+drm_gem_cma_dmabuf_map(struct dma_buf_attachment *attach,
+ enum dma_data_direction dir)
+{
+ struct drm_gem_cma_dmabuf_attachment *cma_attach = attach->priv;
+ struct drm_gem_cma_object *cma_obj = attach->dmabuf->priv;
+ struct drm_device *drm = cma_obj->base.dev;
+ struct scatterlist *rd, *wr;
+ struct sg_table *sgt;
+ unsigned int i;
+ int nents, ret;
+
+ DRM_DEBUG_PRIME("\n");
+
+ if (WARN_ON(dir == DMA_NONE))
+ return ERR_PTR(-EINVAL);
+
+ /* Return the cached mapping when possible. */
+ if (cma_attach->dir == dir)
+ return &cma_attach->sgt;
+
+ /* Two mappings with different directions for the same attachment are
+* not allowed.
+*/
+ if (WARN_ON(cma_attach->dir != DMA_NONE))
+ return ERR_PTR(-EBUSY);
+
+ sgt = &cma_attach->sgt;
+
+ ret = sg_alloc_table(sgt, cma_obj->sgt->orig_nents, GFP_KERNEL);
+ if (ret) {
+ DRM_ERROR("failed to alloc sgt.\n");
+ return ERR_PTR(-ENOMEM);
+ }
+
+ mutex_lock(&drm->struct_mutex);
+
+ rd
[PATCH v3] drm: Renesas R-Car Display Unit DRM driver
The R-Car Display Unit (DU) DRM driver supports both superposition processors and all eight planes in RGB and YUV formats with alpha blending. Only VGA and LVDS encoders and connectors are currently supported. Signed-off-by: Laurent Pinchart --- Hi Dave, There has been no comment on v2, so I'd like to get v3 in 3.11 is possible. The driver depends on the GEM CMA DMA-BUF patches I've sent earlier. If those can't make it to 3.11 I can sent a v4 with DRM PRIME support removed, and add it back for 3.12. Changes since v1: - Use drm_encoder_cleanup() directly as .destroy handlers - Enable alpha blending support - Don't re-reserve hardware plane at each update - Fix planes allocation for multiplanar formats - Add DRM PRIME support - Fix race condition between page flip request and handler - Add configurable z-order support for planes - Support configurable color keying for planes - Update plane format after releasing hardware planes - Fix register access for global registers - Fix plane index wrap-around for multi-planar overlays Changes since v2: - Enable the DE signal - Split hardware and KMS planes - Add support for the second CRTC - Name the encoder platform data union - Fix crash when disabling an already disabled plane - Prepare/unprepare clock - Centralize DU device core resource management - Reorganize CRTC start/stop and power management code - Create common encoder and connector structures - Add support for cloned mode on DU1 - Add XRGB1555 format support - Add plane property to set global alpha value - Don't modify mode active size in encoder fixup - Use the mode active size in mode set - Take offsets into account in the mode_set_base handler - Fix plane source position configuration - Don't clean up mode setting if it hasn't been initialized - Enable extended range for display timings drivers/gpu/drm/Kconfig | 2 + drivers/gpu/drm/Makefile| 1 + drivers/gpu/drm/rcar-du/Kconfig | 9 + drivers/gpu/drm/rcar-du/Makefile| 8 + drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 602 drivers/gpu/drm/rcar-du/rcar_du_crtc.h | 50 +++ drivers/gpu/drm/rcar-du/rcar_du_drv.c | 325 + drivers/gpu/drm/rcar-du/rcar_du_drv.h | 66 drivers/gpu/drm/rcar-du/rcar_du_kms.c | 245 + drivers/gpu/drm/rcar-du/rcar_du_kms.h | 59 drivers/gpu/drm/rcar-du/rcar_du_lvds.c | 216 drivers/gpu/drm/rcar-du/rcar_du_lvds.h | 24 ++ drivers/gpu/drm/rcar-du/rcar_du_plane.c | 507 +++ drivers/gpu/drm/rcar-du/rcar_du_plane.h | 67 drivers/gpu/drm/rcar-du/rcar_du_regs.h | 445 +++ drivers/gpu/drm/rcar-du/rcar_du_vga.c | 149 drivers/gpu/drm/rcar-du/rcar_du_vga.h | 24 ++ include/linux/platform_data/rcar-du.h | 54 +++ 18 files changed, 2853 insertions(+) create mode 100644 drivers/gpu/drm/rcar-du/Kconfig create mode 100644 drivers/gpu/drm/rcar-du/Makefile create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_crtc.c create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_crtc.h create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_drv.c create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_drv.h create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_kms.c create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_kms.h create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_lvds.c create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_lvds.h create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_plane.c create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_plane.h create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_regs.h create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_vga.c create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_vga.h create mode 100644 include/linux/platform_data/rcar-du.h diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index b16c50e..71ca63b 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -213,6 +213,8 @@ source "drivers/gpu/drm/mgag200/Kconfig" source "drivers/gpu/drm/cirrus/Kconfig" +source "drivers/gpu/drm/rcar-du/Kconfig" + source "drivers/gpu/drm/shmobile/Kconfig" source "drivers/gpu/drm/omapdrm/Kconfig" diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile index 1ecbe5b..801bcaf 100644 --- a/drivers/gpu/drm/Makefile +++ b/drivers/gpu/drm/Makefile @@ -49,6 +49,7 @@ obj-$(CONFIG_DRM_EXYNOS) +=exynos/ obj-$(CONFIG_DRM_GMA500) += gma500/ obj-$(CONFIG_DRM_UDL) += udl/ obj-$(CONFIG_DRM_AST) += ast/ +obj-$(CONFIG_DRM_RCAR_DU) += rcar-du/ obj-$(CONFIG_DRM_SHMOBILE) +=shmobile/ obj-$(CONFIG_DRM_OMAP) += omapdrm/ obj-$(CONFIG_DRM_TILCDC) += tilcdc/ diff --git a/drivers/gpu/drm/rcar-du/Kconfig b/drivers/gpu/drm/rcar-du/Kconfig new file mode 100644 index 000..2eb7d23 --- /dev/null +++ b/drivers/gpu/drm/rcar-du/Kconfig @@ -0,0 +1,9 @@ +config DRM_RCAR_DU + tristate "DRM Support for R-Car Display Unit" + depends on DRM && ARCH_SHM
[Bug 57919] Visual glitches in unity with Radeon HD 7600M
https://bugs.freedesktop.org/show_bug.cgi?id=57919 --- Comment #18 from Thilo Cestonaro --- Hey, latest raring with (ubuntu package versions) kernel- 3.8.0-23-generic mesa - 9.1.1-0ubuntu3 xserver-xorg-video-radeon - 7.1.0-0ubuntu2 xserver-xorg - 7.7+1ubuntu4 still showing the same problem. Greetings Thilo -- 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/20130604/89cc92f9/attachment.html>
[Bug 65327] running gnubik produces a segfault
https://bugs.freedesktop.org/show_bug.cgi?id=65327 Andreas Boll changed: What|Removed |Added Product|DRI |Mesa Component|DRM/Radeon |Drivers/Gallium/r300 -- 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/20130604/f571f2b2/attachment.html>
[Bug 60879] [radeonsi] X11 can't start with acceleration enabled
https://bugs.freedesktop.org/show_bug.cgi?id=60879 --- Comment #35 from Hristo Venev --- OpenCL update: On floating point, addition, subtraction, multiplication, division and pow work. On integer, addition, subtraction and multiplication work. Division and modulo halt the GPU. If they are implemented the same way as in OpenGL, this might be the bug I'm facing. -- 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/20130604/85fb56bb/attachment.html>
[PATCH] drm: Add kernel-doc for plane functions
From: Ville Syrj?l?
Signed-off-by: Ville Syrj?l?
---
drivers/gpu/drm/drm_crtc.c | 31 +++
1 file changed, 31 insertions(+)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index f00ba75..f1f11e1 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -795,6 +795,21 @@ void drm_encoder_cleanup(struct drm_encoder *encoder)
}
EXPORT_SYMBOL(drm_encoder_cleanup);
+/**
+ * drm_plane_init - Initialise a new plane object
+ * @dev: DRM device
+ * @plane: plane object to init
+ * @possible_crtcs: bitmask of possible CRTCs
+ * @funcs: callbacks for the new plane
+ * @formats: array of supported formats (%DRM_FORMAT_*)
+ * @format_count: number of elements in @formats
+ * @priv: plane is private (hidden from userspace)?
+ *
+ * Inits a new object created as base part of an driver plane object.
+ *
+ * RETURNS:
+ * Zero on success, error code on failure.
+ */
int drm_plane_init(struct drm_device *dev, struct drm_plane *plane,
unsigned long possible_crtcs,
const struct drm_plane_funcs *funcs,
@@ -843,6 +858,13 @@ int drm_plane_init(struct drm_device *dev, struct
drm_plane *plane,
}
EXPORT_SYMBOL(drm_plane_init);
+/**
+ * drm_plane_cleanup - Cleans up the core plane usage.
+ * @plane: plane to cleanup
+ *
+ * Cleanup @plane. Removes from drm modesetting space
+ * does NOT free object, caller does that.
+ */
void drm_plane_cleanup(struct drm_plane *plane)
{
struct drm_device *dev = plane->dev;
@@ -859,6 +881,15 @@ void drm_plane_cleanup(struct drm_plane *plane)
}
EXPORT_SYMBOL(drm_plane_cleanup);
+/**
+ * drm_plane_force_disable - Forcibly disable a plane
+ * @plane: plane to disable
+ *
+ * Forces the plane to be disabled.
+ *
+ * Used when the plane's current framebuffer is destroyed,
+ * and when restoring fbdev mode.
+ */
void drm_plane_force_disable(struct drm_plane *plane)
{
int ret;
--
1.8.1.5
[PATCH 3/3] drm/fb-helper: Disable cursors and planes when restoring fbdev mode
On Mon, Jun 03, 2013 at 04:10:42PM +0300, ville.syrjala at linux.intel.com
wrote:
> From: Ville Syrj?l?
>
> Cursors and plane can obscure whatever fbdev wants to show the user.
> Disable them all in drm_fb_helper_restore_fbdev_mode.
>
> After the cursors and planes have been disabled, user space needs to
> explicitly re-enable them to make them visible again.
>
> Signed-off-by: Ville Syrj?l?
Yeah, I like that color ;-) For the series:
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_fb_helper.c | 18 --
> 1 file changed, 16 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index 0df0ebb..3d13ca6e2 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -287,13 +287,27 @@ EXPORT_SYMBOL(drm_fb_helper_debug_leave);
> */
> bool drm_fb_helper_restore_fbdev_mode(struct drm_fb_helper *fb_helper)
> {
> + struct drm_device *dev = fb_helper->dev;
> + struct drm_plane *plane;
> bool error = false;
> - int i, ret;
> + int i;
> +
> + drm_warn_on_modeset_not_all_locked(dev);
>
> - drm_warn_on_modeset_not_all_locked(fb_helper->dev);
> + list_for_each_entry(plane, &dev->mode_config.plane_list, head)
> + drm_plane_force_disable(plane);
>
> for (i = 0; i < fb_helper->crtc_count; i++) {
> struct drm_mode_set *mode_set =
> &fb_helper->crtc_info[i].mode_set;
> + struct drm_crtc *crtc = mode_set->crtc;
> + int ret;
> +
> + if (crtc->funcs->cursor_set) {
> + ret = crtc->funcs->cursor_set(crtc, NULL, 0, 0, 0);
> + if (ret)
> + error = true;
> + }
> +
> ret = drm_mode_set_config_internal(mode_set);
> if (ret)
> error = true;
> --
> 1.8.1.5
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
[Intel-gfx] [PATCH v2 2/2] drm: Remove some unused stuff from drm_plane
On Mon, Jun 03, 2013 at 04:11:42PM +0300, ville.syrjala at linux.intel.com
wrote:
> From: Ville Syrj?l?
>
> There's a bunch of unused members inside drm_plane, bloating the size of
> the structure needlessly. Eliminate them.
>
> v2: Remove all of it from kernel-doc too
>
> Reviewed-by: Laurent Pinchart
> Signed-off-by: Ville Syrj?l?
Yeah, makes sense to ditch this. We can think about this again when atomic
modeset and plane properties pop up again. For both patches:
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_crtc.c | 2 +-
> include/drm/drm_crtc.h | 11 ---
> 2 files changed, 1 insertion(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 865ebfe..f00ba75 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -1749,7 +1749,7 @@ int drm_mode_getplane(struct drm_device *dev, void
> *data,
>
> plane_resp->plane_id = plane->base.id;
> plane_resp->possible_crtcs = plane->possible_crtcs;
> - plane_resp->gamma_size = plane->gamma_size;
> + plane_resp->gamma_size = 0;
>
> /*
>* This ioctl is called twice, once to determine how much space is
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index db7a885..3c14b46 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -654,11 +654,7 @@ struct drm_plane_funcs {
> * @format_count: number of formats supported
> * @crtc: currently bound CRTC
> * @fb: currently bound fb
> - * @gamma_size: size of gamma table
> - * @gamma_store: gamma correction table
> - * @enabled: enabled flag
> * @funcs: helper functions
> - * @helper_private: storage for drver layer
> * @properties: property tracking for this plane
> */
> struct drm_plane {
> @@ -674,14 +670,7 @@ struct drm_plane {
> struct drm_crtc *crtc;
> struct drm_framebuffer *fb;
>
> - /* CRTC gamma size for reporting to userspace */
> - uint32_t gamma_size;
> - uint16_t *gamma_store;
> -
> - bool enabled;
> -
> const struct drm_plane_funcs *funcs;
> - void *helper_private;
>
> struct drm_object_properties properties;
> };
> --
> 1.8.1.5
>
> ___
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
[RFC][PATCH 0/2] dma-buf: add importer private data for reimporting
On 2013? 06? 01? 00:29, Daniel Vetter wrote: > On Fri, May 31, 2013 at 07:22:24PM +0900, ??? wrote: >> Hello Daniel, >> >> Thanks for your comment. >> >> On 2013? 05? 31? 18:14, Daniel Vetter wrote: >>> On Fri, May 31, 2013 at 10:54 AM, Seung-Woo Kim >>> wrote: importer private data in dma-buf attachment can be used by importer to reimport same dma-buf. Seung-Woo Kim (2): dma-buf: add importer private data to attachment drm/prime: find gem object from the reimported dma-buf >>> >>> Self-import should already work (at least with the latest refcount >>> fixes merged). At least the tests to check both re-import on the same >>> drm fd and on a different all work as expected now. >> >> Currently, prime works well for all case including self-importing, >> importing, and reimporting as you describe. Just, importing dma-buf from >> other driver twice with different drm_fd, each import create its own gem >> object even two import is done for same buffer because prime_priv is in >> struct drm_file. This means mapping to the device is done also twice. >> IMHO, these duplicated creations and maps are not necessary if drm can >> find previous import in different prime_priv. > > Well, that's imo a bug with the other driver. If it doesn't export > something really simple (e.g. contiguous memory which doesn't require any > mmio resources at all) it should have a cache of exported dma_buf fds so > that it hands out the same dma_buf every time. Hm, all existing dma-buf exporter including i915 driver implements its map_dma_buf callback as allocating scatter-gather table with pages in its buffer and calling dma_map_sg() with the sgt. With different drm_fds, importing one dma-buf *twice*, then importer calls dma_buf_attach() and dma_buf_map_attachment() twice at least in drm importer because re-importing case can only checked with prime_priv in drm_file as I described. > > Or it needs to be more clever in it's dma_buf_attachment_map functions and > lookup up a pre-existing iommu mapping. > > But dealing with this in the importer is just broken. > >>> Second, the dma_buf_attachment is _definitely_ the wrong place to do >>> this. If you need iommu mapping caching, that should happen at a lower >>> level (i.e. in the map_attachment callback somewhere of the exporter, >>> that's what the priv field in the attachment is for). Snatching away >>> the attachement from some random other import is certainly not the way >>> to go - attachements are _not_ refcounted! >> >> Yes, attachments do not have refcount, so importer should handle and drm >> case in my patch, importer private data is gem object and it has, of >> course, refcount. >> >> And at current, exporter can not classify map_dma_buf requests of same >> importer to same buffer with different attachment because dma_buf_attach >> always makes new attachments. To resolve this exporter should search all >> different attachment from same importer of dma-buf and it seems more >> complex than importer private data to me. >> >> If I misunderstood something, please let me know. > > Like I've said above, just fix this in the exporter. If an importer sees > two different dma_bufs it can very well presume that it those two indeed > point to different backing storage. Yes, my patch does not break this concept. I just fixed case importing _one_ dma-buf twice with different drm_fds. > > This will be even more important if we attach fences two dma_bufs. If your > broken exporter creates multiple dma_bufs each one of them will have their > own fences attached, leading to a complete disasters. Ok, strictly > speaking if you keep the same reservation pointer for each dma_buf it'll > work, but that's just a detail of how you solve this in the exporter. I can not understand about broken exporter you addressed. I don't mean exporter makes dma-bufs from one backing storage. While, my patch prevents not to create drm gem objects from one back storage by importing one dma-buf with different drm-fds. I do not believe the fix of importer is the best way, but at this moment, I have no idea how I can fix the exporter for this issue. Best Regards, - Seung-Woo Kim > > Cheers, Daniel > -- Seung-Woo Kim Samsung Software R&D Center --
[PATCH v2 1/5] drm/gem: Split drm_gem_mmap() into object search and object mapping
On Mon, Jun 3, 2013 at 10:20 PM, Laurent Pinchart
wrote:
> The drm_gem_mmap() function first finds the GEM object to be mapped
> based on the fake mmap offset and then maps the object. Split the object
> mapping code into a standalone drm_gem_mmap_obj() function that can be
> used to implement dma-buf mmap() operations.
>
> Signed-off-by: Laurent Pinchart
Cool, thanks.. this was an old TODO of mine that I apparently forgot about :-)
Reviewed-by: Rob Clark
> ---
> drivers/gpu/drm/drm_gem.c | 83
> +--
> include/drm/drmP.h| 2 ++
> 2 files changed, 54 insertions(+), 31 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
> index cf919e3..4321713 100644
> --- a/drivers/gpu/drm/drm_gem.c
> +++ b/drivers/gpu/drm/drm_gem.c
> @@ -644,6 +644,55 @@ void drm_gem_vm_close(struct vm_area_struct *vma)
> }
> EXPORT_SYMBOL(drm_gem_vm_close);
>
> +/**
> + * drm_gem_mmap_obj - memory map a GEM object
> + * @obj: the GEM object to map
> + * @obj_size: the object size to be mapped, in bytes
> + * @vma: VMA for the area to be mapped
> + *
> + * Set up the VMA to prepare mapping of the GEM object using the gem_vm_ops
> + * provided by the driver. Depending on their requirements, drivers can
> either
> + * provide a fault handler in their gem_vm_ops (in which case any accesses to
> + * the object will be trapped, to perform migration, GTT binding, surface
> + * register allocation, or performance monitoring), or mmap the buffer memory
> + * synchronously after calling drm_gem_mmap_obj.
> + *
> + * This function is mainly intended to implement the DMABUF mmap operation,
> when
> + * the GEM object is not looked up based on its fake offset. To implement the
> + * DRM mmap operation, drivers should use the drm_gem_mmap() function.
> + *
> + * Return 0 or success or -EINVAL if the object size is smaller than the VMA
> + * size, or if no gem_vm_ops are provided.
> + */
> +int drm_gem_mmap_obj(struct drm_gem_object *obj, unsigned long obj_size,
> +struct vm_area_struct *vma)
> +{
> + struct drm_device *dev = obj->dev;
> +
> + /* Check for valid size. */
> + if (obj_size < vma->vm_end - vma->vm_start)
> + return -EINVAL;
> +
> + if (!dev->driver->gem_vm_ops)
> + return -EINVAL;
> +
> + vma->vm_flags |= VM_IO | VM_PFNMAP | VM_DONTEXPAND | VM_DONTDUMP;
> + vma->vm_ops = dev->driver->gem_vm_ops;
> + vma->vm_private_data = obj;
> + vma->vm_page_prot =
> pgprot_writecombine(vm_get_page_prot(vma->vm_flags));
> +
> + /* Take a ref for this mapping of the object, so that the fault
> +* handler can dereference the mmap offset's pointer to the object.
> +* This reference is cleaned up by the corresponding vm_close
> +* (which should happen whether the vma was created by this call, or
> +* by a vm_open due to mremap or partial unmap or whatever).
> +*/
> + drm_gem_object_reference(obj);
> +
> + drm_vm_open_locked(dev, vma);
> + return 0;
> +}
> +EXPORT_SYMBOL(drm_gem_mmap_obj);
>
> /**
> * drm_gem_mmap - memory map routine for GEM objects
> @@ -653,11 +702,9 @@ EXPORT_SYMBOL(drm_gem_vm_close);
> * If a driver supports GEM object mapping, mmap calls on the DRM file
> * descriptor will end up here.
> *
> - * If we find the object based on the offset passed in (vma->vm_pgoff will
> + * Look up the GEM object based on the offset passed in (vma->vm_pgoff will
> * contain the fake offset we created when the GTT map ioctl was called on
> - * the object), we set up the driver fault handler so that any accesses
> - * to the object can be trapped, to perform migration, GTT binding, surface
> - * register allocation, or performance monitoring.
> + * the object) and map it with a call to drm_gem_mmap_obj().
> */
> int drm_gem_mmap(struct file *filp, struct vm_area_struct *vma)
> {
> @@ -665,7 +712,6 @@ int drm_gem_mmap(struct file *filp, struct vm_area_struct
> *vma)
> struct drm_device *dev = priv->minor->dev;
> struct drm_gem_mm *mm = dev->mm_private;
> struct drm_local_map *map = NULL;
> - struct drm_gem_object *obj;
> struct drm_hash_item *hash;
> int ret = 0;
>
> @@ -686,32 +732,7 @@ int drm_gem_mmap(struct file *filp, struct
> vm_area_struct *vma)
> goto out_unlock;
> }
>
> - /* Check for valid size. */
> - if (map->size < vma->vm_end - vma->vm_start) {
> - ret = -EINVAL;
> - goto out_unlock;
> - }
> -
> - obj = map->handle;
> - if (!obj->dev->driver->gem_vm_ops) {
> - ret = -EINVAL;
> - goto out_unlock;
> - }
> -
> - vma->vm_flags |= VM_IO | VM_PFNMAP | VM_DONTEXPAND | VM_DONTDUMP;
> - vma->vm_ops = obj->dev->driver->gem_vm_ops;
> - vma->vm_private_data = map->handle;
> - vma->vm_page_prot =
> pg
[PATCH v2 2/5] drm/omap: Use drm_gem_mmap_obj() to implement dma-buf mmap
On Mon, Jun 3, 2013 at 10:20 PM, Laurent Pinchart
wrote:
> The dma-buf mmap code was copied from the GEM mmap implementation.
> Replace it with the new drm_gem_mmap_obj() function.
>
> Signed-off-by: Laurent Pinchart
Reviewed-by: Rob Clark
> ---
> drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c | 32
> +++
> 1 file changed, 3 insertions(+), 29 deletions(-)
>
> diff --git a/drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c
> b/drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c
> index be7cd97..3256693 100644
> --- a/drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c
> +++ b/drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c
> @@ -136,10 +136,6 @@ static void omap_gem_dmabuf_kunmap(struct dma_buf
> *buffer,
> kunmap(pages[page_num]);
> }
>
> -/*
> - * TODO maybe we can split up drm_gem_mmap to avoid duplicating
> - * some here.. or at least have a drm_dmabuf_mmap helper.
> - */
> static int omap_gem_dmabuf_mmap(struct dma_buf *buffer,
> struct vm_area_struct *vma)
> {
> @@ -149,31 +145,9 @@ static int omap_gem_dmabuf_mmap(struct dma_buf *buffer,
> if (WARN_ON(!obj->filp))
> return -EINVAL;
>
> - /* Check for valid size. */
> - if (omap_gem_mmap_size(obj) < vma->vm_end - vma->vm_start) {
> - ret = -EINVAL;
> - goto out_unlock;
> - }
> -
> - if (!obj->dev->driver->gem_vm_ops) {
> - ret = -EINVAL;
> - goto out_unlock;
> - }
> -
> - vma->vm_flags |= VM_IO | VM_PFNMAP | VM_DONTEXPAND | VM_DONTDUMP;
> - vma->vm_ops = obj->dev->driver->gem_vm_ops;
> - vma->vm_private_data = obj;
> - vma->vm_page_prot =
> pgprot_writecombine(vm_get_page_prot(vma->vm_flags));
> -
> - /* Take a ref for this mapping of the object, so that the fault
> -* handler can dereference the mmap offset's pointer to the object.
> -* This reference is cleaned up by the corresponding vm_close
> -* (which should happen whether the vma was created by this call, or
> -* by a vm_open due to mremap or partial unmap or whatever).
> -*/
> - vma->vm_ops->open(vma);
> -
> -out_unlock:
> + ret = drm_gem_mmap_obj(obj, omap_gem_mmap_size(obj), vma);
> + if (ret < 0)
> + return ret;
>
> return omap_gem_mmap_obj(obj, vma);
> }
> --
> 1.8.1.5
>
[REGRESSION] system does not resume from ram due to commit "drm/nv50/fifo: prevent races between clients updating playlists"
On Mon, Jun 03, 2013 at 03:50:50PM +1000, Ben Skeggs wrote: > On Fri, May 31, 2013 at 11:05 PM, Konrad Rzeszutek Wilk < > konrad.wilk at oracle.com> wrote: > > > On Tue, May 28, 2013 at 08:55:29PM +0200, Sven Joachim wrote: > > > On 2013-05-26 23:09 +0200, Maarten Maathuis wrote: > > > > > > > My NV96 does not resume from suspend to ram (the screen stays black, > > magic > > > > sysrq keys do work) with the current linus git kernel, i bisected it > > to the > > > > following commit. > > > > > > > > drm/nv50/fifo: prevent races between clients updating playlists > > > > b5096566f6e1ee2b88324772f020ae9bc0cfa9a0 > > > > > > > > It's not obvious to me how this causes problems, but reverting this > > commit > > > > does solve my problem. > > > > > > Same here on my NV86. > > > > And as well on this: > > > > 01:00.0 VGA compatible controller: NVIDIA Corporation G84 [GeForce 8600 > > GT] (rev a1) > > > > > > Ben, any ideas? > > > > I've pushed a fix[1] to my git tree. Will pull it across to the "normal" > tree once I've hunted down another regression. You can also add (if you would like) Tested-by: Konrad Rzeszutek Wilk Thanks! > > Thanks, > Ben. > > [1] > http://cgit.freedesktop.org/~darktama/nouveau/commit/?id=d37687a562f0b55cc848cfcdbf8d473a6c692c2d > > > > > > Cheers, > > >Sven > > ___ > > dri-devel mailing list > > dri-devel at lists.freedesktop.org > > http://lists.freedesktop.org/mailman/listinfo/dri-devel > >
[RFC][PATCH 0/2] dma-buf: add importer private data for reimporting
On Tue, Jun 04, 2013 at 07:42:22PM +0900, ??? wrote: > > > On 2013? 06? 01? 00:29, Daniel Vetter wrote: > > On Fri, May 31, 2013 at 07:22:24PM +0900, ??? wrote: > >> Hello Daniel, > >> > >> Thanks for your comment. > >> > >> On 2013? 05? 31? 18:14, Daniel Vetter wrote: > >>> On Fri, May 31, 2013 at 10:54 AM, Seung-Woo Kim >>> samsung.com> wrote: > importer private data in dma-buf attachment can be used by importer to > reimport same dma-buf. > > Seung-Woo Kim (2): > dma-buf: add importer private data to attachment > drm/prime: find gem object from the reimported dma-buf > >>> > >>> Self-import should already work (at least with the latest refcount > >>> fixes merged). At least the tests to check both re-import on the same > >>> drm fd and on a different all work as expected now. > >> > >> Currently, prime works well for all case including self-importing, > >> importing, and reimporting as you describe. Just, importing dma-buf from > >> other driver twice with different drm_fd, each import create its own gem > >> object even two import is done for same buffer because prime_priv is in > >> struct drm_file. This means mapping to the device is done also twice. > >> IMHO, these duplicated creations and maps are not necessary if drm can > >> find previous import in different prime_priv. > > > > Well, that's imo a bug with the other driver. If it doesn't export > > something really simple (e.g. contiguous memory which doesn't require any > > mmio resources at all) it should have a cache of exported dma_buf fds so > > that it hands out the same dma_buf every time. > > Hm, all existing dma-buf exporter including i915 driver implements its > map_dma_buf callback as allocating scatter-gather table with pages in > its buffer and calling dma_map_sg() with the sgt. With different > drm_fds, importing one dma-buf *twice*, then importer calls > dma_buf_attach() and dma_buf_map_attachment() twice at least in drm > importer because re-importing case can only checked with prime_priv in > drm_file as I described. Well, but thanks to all the self-import and re-import checks, it's _impossible_ to import the same dma_buf twice without noticing (presuming both importer and exporter are drm devices). > > > > > Or it needs to be more clever in it's dma_buf_attachment_map functions and > > lookup up a pre-existing iommu mapping. > > > > But dealing with this in the importer is just broken. > > > >>> Second, the dma_buf_attachment is _definitely_ the wrong place to do > >>> this. If you need iommu mapping caching, that should happen at a lower > >>> level (i.e. in the map_attachment callback somewhere of the exporter, > >>> that's what the priv field in the attachment is for). Snatching away > >>> the attachement from some random other import is certainly not the way > >>> to go - attachements are _not_ refcounted! > >> > >> Yes, attachments do not have refcount, so importer should handle and drm > >> case in my patch, importer private data is gem object and it has, of > >> course, refcount. > >> > >> And at current, exporter can not classify map_dma_buf requests of same > >> importer to same buffer with different attachment because dma_buf_attach > >> always makes new attachments. To resolve this exporter should search all > >> different attachment from same importer of dma-buf and it seems more > >> complex than importer private data to me. > >> > >> If I misunderstood something, please let me know. > > > > Like I've said above, just fix this in the exporter. If an importer sees > > two different dma_bufs it can very well presume that it those two indeed > > point to different backing storage. > > Yes, my patch does not break this concept. I just fixed case importing > _one_ dma-buf twice with different drm_fds. See above, if you have two different struct file * for the same underlying buffer object something is wrong already. > > This will be even more important if we attach fences two dma_bufs. If your > > broken exporter creates multiple dma_bufs each one of them will have their > > own fences attached, leading to a complete disasters. Ok, strictly > > speaking if you keep the same reservation pointer for each dma_buf it'll > > work, but that's just a detail of how you solve this in the exporter. > > I can not understand about broken exporter you addressed. I don't mean > exporter makes dma-bufs from one backing storage. > While, my patch prevents not to create drm gem objects from one back > storage by importing one dma-buf with different drm-fds. Well, we also have code in drm prime for that case - if the same dma_buf object shows up multiple times, we'll only import it once. For the second import we'll return the already created drm_gem object from the first import, but with the refcount incremented. > I do not believe the fix of importer is the best way, but at this > moment, I have no idea how I can fix the exporter for this issue. I think if you have drm prime drivers bot
[PATCH v3] drm: Renesas R-Car Display Unit DRM driver
On Tue, Jun 04, 2013 at 04:53:40AM +0200, Laurent Pinchart wrote: > The R-Car Display Unit (DU) DRM driver supports both superposition > processors and all eight planes in RGB and YUV formats with alpha > blending. > > Only VGA and LVDS encoders and connectors are currently supported. > > Signed-off-by: Laurent Pinchart Ok, I've done a little review, and the driver looks rather nice. With a simpler driver like this the drm boilerplate sticks out more, so I've dropped a few grumblings about that. But I've also spotted 3 little things which imo should be fixed before merging. Comments inline below. Cheers, Daniel > --- > Hi Dave, > > There has been no comment on v2, so I'd like to get v3 in 3.11 is possible. > The driver depends on the GEM CMA DMA-BUF patches I've sent earlier. If those > can't make it to 3.11 I can sent a v4 with DRM PRIME support removed, and add > it back for 3.12. > > Changes since v1: > > - Use drm_encoder_cleanup() directly as .destroy handlers > - Enable alpha blending support > - Don't re-reserve hardware plane at each update > - Fix planes allocation for multiplanar formats > - Add DRM PRIME support > - Fix race condition between page flip request and handler > - Add configurable z-order support for planes > - Support configurable color keying for planes > - Update plane format after releasing hardware planes > - Fix register access for global registers > - Fix plane index wrap-around for multi-planar overlays > > Changes since v2: > > - Enable the DE signal > - Split hardware and KMS planes > - Add support for the second CRTC > - Name the encoder platform data union > - Fix crash when disabling an already disabled plane > - Prepare/unprepare clock > - Centralize DU device core resource management > - Reorganize CRTC start/stop and power management code > - Create common encoder and connector structures > - Add support for cloned mode on DU1 > - Add XRGB1555 format support > - Add plane property to set global alpha value > - Don't modify mode active size in encoder fixup > - Use the mode active size in mode set > - Take offsets into account in the mode_set_base handler > - Fix plane source position configuration > - Don't clean up mode setting if it hasn't been initialized > - Enable extended range for display timings > > drivers/gpu/drm/Kconfig | 2 + > drivers/gpu/drm/Makefile| 1 + > drivers/gpu/drm/rcar-du/Kconfig | 9 + > drivers/gpu/drm/rcar-du/Makefile| 8 + > drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 602 > > drivers/gpu/drm/rcar-du/rcar_du_crtc.h | 50 +++ > drivers/gpu/drm/rcar-du/rcar_du_drv.c | 325 + > drivers/gpu/drm/rcar-du/rcar_du_drv.h | 66 > drivers/gpu/drm/rcar-du/rcar_du_kms.c | 245 + > drivers/gpu/drm/rcar-du/rcar_du_kms.h | 59 > drivers/gpu/drm/rcar-du/rcar_du_lvds.c | 216 > drivers/gpu/drm/rcar-du/rcar_du_lvds.h | 24 ++ > drivers/gpu/drm/rcar-du/rcar_du_plane.c | 507 +++ > drivers/gpu/drm/rcar-du/rcar_du_plane.h | 67 > drivers/gpu/drm/rcar-du/rcar_du_regs.h | 445 +++ > drivers/gpu/drm/rcar-du/rcar_du_vga.c | 149 > drivers/gpu/drm/rcar-du/rcar_du_vga.h | 24 ++ > include/linux/platform_data/rcar-du.h | 54 +++ > 18 files changed, 2853 insertions(+) > create mode 100644 drivers/gpu/drm/rcar-du/Kconfig > create mode 100644 drivers/gpu/drm/rcar-du/Makefile > create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_crtc.c > create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_crtc.h > create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_drv.c > create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_drv.h > create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_kms.c > create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_kms.h > create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_lvds.c > create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_lvds.h > create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_plane.c > create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_plane.h > create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_regs.h > create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_vga.c > create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_vga.h > create mode 100644 include/linux/platform_data/rcar-du.h > > diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig > index b16c50e..71ca63b 100644 > --- a/drivers/gpu/drm/Kconfig > +++ b/drivers/gpu/drm/Kconfig > @@ -213,6 +213,8 @@ source "drivers/gpu/drm/mgag200/Kconfig" > > source "drivers/gpu/drm/cirrus/Kconfig" > > +source "drivers/gpu/drm/rcar-du/Kconfig" > + > source "drivers/gpu/drm/shmobile/Kconfig" > > source "drivers/gpu/drm/omapdrm/Kconfig" > diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile > index 1ecbe5b..801bcaf 100644 > --- a/drivers/gpu/drm/Makefile > +++ b/drivers/gpu/drm/Makefile > @@ -49,6 +49,7 @@ obj-$(CONFI
[PULL] drm-intel-fixes
Hi Dave, Three regression fixes and one no-lvds quirk update. The regression Egbert Eich tracked down goes back to 2.6.37 ... ugh. The other two are pretty minor: One bogus modeset state checker WARN and a patch to prevent X dying in a SIGBUS after a gpu hang with failed (or not implement as on gen2/3) gpu reset. Cheers, Daniel The following changes since commit d683b96b072dc4680fc74964eca77e6a23d1fa6e: Linux 3.10-rc4 (2013-06-02 17:11:17 +0900) are available in the git repository at: git://people.freedesktop.org/~danvet/drm-intel tags/drm-intel-fixes-2013-06-04 for you to fetch changes up to 53d3b4d7778daf15900867336c85d3f8dd70600c: drm/i915/sdvo: Use &intel_sdvo->ddc instead of intel_sdvo->i2c for DDC. (2013-06-04 17:48:43 +0200) Ben Mesman (1): drm/i915: no lvds quirk for hp t5740 Daniel Vetter (2): drm/i915: Fix spurious -EIO/SIGBUS on wedged gpus drm/i915: Quirk the pipe A quirk in the modeset state checker Egbert Eich (1): drm/i915/sdvo: Use &intel_sdvo->ddc instead of intel_sdvo->i2c for DDC. drivers/gpu/drm/i915/i915_gem.c |7 ++- drivers/gpu/drm/i915/intel_display.c |5 + drivers/gpu/drm/i915/intel_lvds.c|4 ++-- drivers/gpu/drm/i915/intel_sdvo.c|2 +- 4 files changed, 10 insertions(+), 8 deletions(-) -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[PATCH] drm/tegra: add support for runtime pm
On Tuesday 28 May 2013 02:40 PM, Thierry Reding wrote:
> * PGP Signed by an unknown key
>
> On Tue, May 28, 2013 at 08:45:03AM +0300, Terje Bergstr?m wrote:
>> On 27.05.2013 18:45, Thierry Reding wrote:
>>> On Mon, May 27, 2013 at 07:19:28PM +0530, Mayuresh Kulkarni wrote:
+#ifdef CONFIG_PM_RUNTIME
+static int host1x_runtime_suspend(struct device *dev)
+{
+ struct host1x *host;
+
+ host = dev_get_drvdata(dev);
+ if (IS_ERR_OR_NULL(host))
>>>
>>> I think a simple
>>>
>>> if (!host)
>>> return -EINVAL;
>>>
>>> would be enough here. The driver-data of the device should never be an
>>> ERR_PTR()-encoded value, but either a valid pointer to a host1x object
>>> or NULL.
>>
>> True, we should avoid IS_ERR_OR_NULL() like plague. We always know if
>> the called API returns a NULL on error or an error code. In case of
>> error code we should just propagate that.
>
> Yes, that's the case in general. In this specific case the value
> obtained by dev_get_drvdata() should either be a valid pointer or NULL,
> never an error code. We can easily make sure by only setting the data
> (using platform_set_drvdata()) when the pointer is valid.
>
> Thinking about it some more, I don't think we can ever get NULL here. A
> device's .runtime_suspend() cannot be called when the device has been
> removed, right? That's the only case where the value returned might be
> NULL. It would be NULL too if host1x wasn't initialized yet, but that's
> already dealt with by the proper ordering in .probe().
>
>>> Same comments apply here. Also I think it might be a good idea to split
>>> the host1x and gr2d changes into separate patches.
>>
>> That's a bit tricky, but doable. We just need to enable it for 2D first,
>> and then host1x to keep bisectability.
>
> Right, there's a dependency. But I'd still prefer to have them separate.
> Unless it gets really messy.
>
static void action_submit_complete(struct host1x_waitlist *waiter)
{
+ int completed = waiter->count;
struct host1x_channel *channel = waiter->data;
+ /* disable clocks for all the submits that got completed in this lot */
+ while (completed--)
+ pm_runtime_put(channel->dev);
+
host1x_cdma_update(&channel->cdma);
- /* Add nr_completed to trace */
+ /* Add nr_completed to trace */
trace_host1x_channel_submit_complete(dev_name(channel->dev),
waiter->count, waiter->thresh);
-
}
>>>
>>> This feels hackish. But I can't see any better place to do this. Terje,
>>> Arto: any ideas how we can do this in a cleaner way? If there's nothing
>>> better then maybe moving the code into a separate function, say
>>> host1x_waitlist_complete(), might make this less awkward?
>>
>> Yeah, it's a bit awkward. action_submit_complete() actually does handle
>> completion of multiple jobs, and we do one pm_runtime_get() per job.
>>
>> We could do pm_runtime_put() in host1x_cdma_update(). It anyway goes
>> through each job that is completed, so while freeing the job it could as
>> well call runtime PM. That way we could even remove the waiter->count
>> variable altogether as it's not needed anymore.
>
> That sounds a lot better. We could add a helper (host1x_job_finish()
> perhaps) with the following from update_cdma_locked():
>
> /* Unpin the memory */
> host1x_job_unpin(job);
>
> /* Pop push buffer slots */
> if (job->num_slots) {
> struct push_buffer *pb = &cdma->push_buffer;
> host1x_pushbuffer_pop(pb, job->num_slots);
> if (cdma->event == CDMA_EVENT_PUSH_BUFFER_SPACE)
> signal = true;
> }
>
> list_del(&job->list);
>
> And add pm_runtime_put() (as well as potentially other stuff) in there.
> That'll prevent update_cdma_unlocked() from growing too much. It isn't
> too bad right now, so maybe a helper isn't warranted yet, but I don't
> think it'll hurt.
>
>> The not-so-beautiful aspect is that we do pm_runtime_get() in
>> host1x_channel.c and pm_runtime_put() in host1x_cdma.c. For code
>> readability it's be great to have them in the same file. I actually get
>> questions every now and then because in downstream because of doing
>> these operations in different files.
>
> With the above helper in place, we could move host1x_job_submit() to
> job.c instead and have all the code in one file.
>
> Thierry
>
> * Unknown Key
> * 0x7F3EB3A1
>
In downstream, we have 2 APIs which are wrapper over runtime PM calls.
We call those from _submit and job complete.
I wonder if we should follow the same here?
[Bug 65192] [r600g] Screensavers lock up machine (screen goes blank, keyboard unresponsive, sound loops; sysrq/ssh possible)
https://bugs.freedesktop.org/show_bug.cgi?id=65192 --- Comment #8 from Michel D?nzer --- (In reply to comment #8) > [...] the bug (or regression, I think it used to work about 2 months ago) Can you try confirming that, e.g. by trying Mesa from the 9.1 branch or an older snapshot from master? -- 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/20130604/0de15371/attachment.html>
[Bug 60879] [radeonsi] X11 can't start with acceleration enabled
https://bugs.freedesktop.org/show_bug.cgi?id=60879 --- Comment #36 from Michel D?nzer --- For OpenCL with radeonsi, make sure your LLVM and Mesa SVN/Git snapshots are up to date as of today. However, I'm afraid your success with OpenCL doesn't necessarily mean anything for the graphics problem, as the latter involves much more complex hardware state setup. -- 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/20130604/461f85fc/attachment.html>
[Bug 65254] opengl flicker in xbmc / glxgears
https://bugs.freedesktop.org/show_bug.cgi?id=65254 --- Comment #8 from Vladi --- updated last night to 3.10.0-rc4 + mesa git + xf86-video-ati git and I am now seeing lockups during playback / navigating the UI in xbmc.. will try and track it down further. -- 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/20130604/a3fa39e7/attachment.html>
[PATCH v3] drm: Renesas R-Car Display Unit DRM driver
Hi Daniel,
On Tuesday 04 June 2013 16:12:36 Daniel Vetter wrote:
> On Tue, Jun 04, 2013 at 04:53:40AM +0200, Laurent Pinchart wrote:
> > The R-Car Display Unit (DU) DRM driver supports both superposition
> > processors and all eight planes in RGB and YUV formats with alpha
> > blending.
> >
> > Only VGA and LVDS encoders and connectors are currently supported.
> >
> > Signed-off-by: Laurent Pinchart
> >
>
> Ok, I've done a little review, and the driver looks rather nice.
Thank you.
> With a simpler driver like this the drm boilerplate sticks out more, so I've
> dropped a few grumblings about that. But I've also spotted 3 little things
> which imo should be fixed before merging. Comments inline below.
>
> Cheers, Daniel
[snip]
> > diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> > b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c new file mode 100644
> > index 000..c66fa4c
> > --- /dev/null
> > +++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
[snip]
> > +static void rcar_du_start_stop(struct rcar_du_device *rcdu, bool start)
> > +{
> > + /* Many of the configuration bits are only updated when the display
> > +* reset (DRES) bit in DSYSR is set to 1, disabling *both* CRTCs.
> > +* Some of those bits could be pre-configured, but others (especially
> > +* the bits related to plane assignment to display timing
> > +* controllers) need to be modified at runtime.
> > +*
> > +* Restart the display controller if a start is requested. Sorry for
> > +* the flicker. It should be possible to move most of the "DRES-
> > +* update" bits setup to driver initialization time and minimize the
> > +* number of cases when the display controller will have to be
> > +* restarted.
> > +*/
> > + if (start) {
> > + if (rcdu->used_crtcs++ != 0)
> > + __rcar_du_start_stop(rcdu, false);
> > + __rcar_du_start_stop(rcdu, true);
> > + } else {
> > + if (--rcdu->used_crtcs == 0)
> > + __rcar_du_start_stop(rcdu, false);
> > + }
> > +}
>
> You seem to be a prime user for atomic modeset stuff ;-) Have you looked
> already a bit into sensible additions for the crtc helpers to make that
> possible? Maybe a global modeset_prepare/commit hook?
Not yet. That's somewhere in my to-do list, but it's growing too long :-( I
need to finish CDF first.
[snip]
> > +static int rcar_du_crtc_mode_set(struct drm_crtc *crtc,
> > +struct drm_display_mode *mode,
> > +struct drm_display_mode *adjusted_mode,
> > +int x, int y,
> > +struct drm_framebuffer *old_fb)
> > +{
> > + struct rcar_du_device *rcdu = crtc->dev->dev_private;
> > + struct rcar_du_crtc *rcrtc = to_rcar_crtc(crtc);
> > + const struct rcar_du_format_info *format;
> > + int ret;
> > +
> > + format = rcar_du_format_info(crtc->fb->pixel_format);
> > + if (format == NULL) {
> > + dev_dbg(rcdu->dev, "mode_set: unsupported format %08x\n",
> > + crtc->fb->pixel_format);
> > + ret = -EINVAL;
> > + goto error;
> > + }
> > +
> > + ret = rcar_du_plane_reserve(rcrtc->plane, format);
> > + if (ret < 0)
> > + goto error;
> > +
> > + rcrtc->plane->format = format;
> > + rcrtc->plane->pitch = crtc->fb->pitches[0];
> > +
> > + rcrtc->plane->src_x = x;
> > + rcrtc->plane->src_y = y;
> > + rcrtc->plane->width = mode->hdisplay;
> > + rcrtc->plane->height = mode->vdisplay;
> > +
> > + rcar_du_plane_compute_base(rcrtc->plane, crtc->fb);
> > +
> > + rcrtc->outputs = 0;
> > +
> > + return 0;
> > +
> > +error:
> > + /* There's no rollback/abort operation to clean up in case of error.
> > +* We thus need to release the reference to the DU acquired in
> > +* prepare() here.
> > +*/
>
> Should we add that to crtc helpers, instead of the current "just try to
> smash the old config on top of the ill-defined hw state after a failed
> modeset"?
It would probably make sense to add a rollback operation to undo the prepare
operation, or maybe just a rollback/commit flag to the commit operation. We
would still need to smash the old config back though, as the rollback
operation shouldn't be expected to handle encoders and connectors.
While we're at it, shouldn't we make drivers report supported formats for the
main frame buffer, like we do for planes ? That would allow catching format
errors before calling the prepare operation.
> > + rcar_du_put(rcdu);
> > + return ret;
> > +}
[snip]
> > +static void rcar_du_crtc_finish_page_flip(struct rcar_du_crtc *rcrtc)
> > +{
> > + struct drm_pending_vblank_event *event;
> > + struct drm_device *dev = rcrtc->crtc.dev;
> > + struct timeval vblanktime;
> > + unsigned long flags;
> > +
> > + spin_lock_irqsave(&dev->event_lock, flags);
> > + event = rcrtc->event;
> > + rcrtc->event = NULL;
> > + spin_unlock_irqrestore(&de
[PATCH v2 2/5] drm/omap: Use drm_gem_mmap_obj() to implement dma-buf mmap
Hi Rob, On Tuesday 04 June 2013 07:33:42 Rob Clark wrote: > On Mon, Jun 3, 2013 at 10:20 PM, Laurent Pinchart wrote: > > The dma-buf mmap code was copied from the GEM mmap implementation. > > Replace it with the new drm_gem_mmap_obj() function. > > > > Signed-off-by: Laurent Pinchart > > > > Reviewed-by: Rob Clark Thanks. Any chance you would have time to review 3/5 to 5/5 ? :-) -- Regards, Laurent Pinchart
[PATCH v3] drm: Renesas R-Car Display Unit DRM driver
On Tue, Jun 4, 2013 at 8:03 PM, Laurent Pinchart
wrote:
> Hi Daniel,
>
> On Tuesday 04 June 2013 16:12:36 Daniel Vetter wrote:
>> On Tue, Jun 04, 2013 at 04:53:40AM +0200, Laurent Pinchart wrote:
[snip]
>> Should we add that to crtc helpers, instead of the current "just try to
>> smash the old config on top of the ill-defined hw state after a failed
>> modeset"?
>
> It would probably make sense to add a rollback operation to undo the prepare
> operation, or maybe just a rollback/commit flag to the commit operation. We
> would still need to smash the old config back though, as the rollback
> operation shouldn't be expected to handle encoders and connectors.
>
> While we're at it, shouldn't we make drivers report supported formats for the
> main frame buffer, like we do for planes ? That would allow catching format
> errors before calling the prepare operation.
Yeah, I've noticed that one, too. I guess we could tackle that as part
of an eventual "make the implicit primary plane a bit more explict"
project. For now I'm not too offended by the duplication of checks.
>> This should use the drm_send_vblank_event helper.
>
> What bothers me about drm_send_vblank_event() is that it calls
> drm_vblank_count_and_time() with the events lock unnecessarily held. I can
> live with that for now, I'll fix the driver to use the helper.
Most other drivers protect a bit of other state with that lock, so
makes sense to hold it outside already. So not sure whether we should
optimize this much ...
>> > + drm_vblank_put(dev, rcrtc->index);
>> > +}
>
> [snip]
>
>> > diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
>> > b/drivers/gpu/drm/rcar-du/rcar_du_drv.c new file mode 100644
>> > index 000..003b34e
>> > --- /dev/null
>> > +++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
>
> [snip]
>
>> > +static void rcar_du_disable_vblank(struct drm_device *dev, int crtc)
>> > +{
>> > + struct rcar_du_device *rcdu = dev->dev_private;
>> > +
>> > + rcar_du_crtc_enable_vblank(&rcdu->crtcs[crtc], false);
>> > +}
>>
>> Blergh, I hate our legacy vblank code which forces kms driver to jump
>> through int pipe -> struct drm_crtc * hoops.
>
> How would you like to fix it ? :-)
Haven't looked at the details, but the first step I have in mind is to
switch all drm core -> driver and driver -> vblank helper interfaces
from int pipe to struct drm_crtc * pointers for kms drivers. That
would allow us to implement at least sane locking for the vblank wait
ioctl (by grabbing the crtc mutex).
My plan was to split things by copy&pasting new kms functions and then
garbage-collecting all unnused features for the ums code (iirc no ums
driver ever supported more than 2 crtcs, vblank events or
high-precision timestamps).
Once that's in place we can look into more stuff. One of the things I
want to play with is support for hw timestamp and vblank counters
(also for pageflips). Then we don't have to enable the vblank
interrupt so often and more important should be able to turn it of
right away without loosing precision due to the potential vblank irq
vs. vblank irq off race.
>> where i counts encoders to say that you can clone itself (userspace might
>> get confused, haven't checked how throughout the modeset ddx is). But it
>> sounds like rcar can clone encoders pretty freely (as long as they're
>> using crtc 0), so maybe you want to use something like drm/i915 does?
>
> The device has two outputs, 0 and 1. Output 0 can be driven by CRTC 0 only,
> and output 1 can be driven by CRTC 0 or CRTC 1.
Ah, that explains it, I've missed the context that we only have 2
crtc/encoder pairs ;-)
>> We smash all cloneable encoders into one groub with a
>> intel_encoder->cloneable flag and then allow cloning any cloneable encoder
>> to any other cloneable encoder with intel_encoder_clones in
>> intel_display.c
>>
>> possible_clones is a bit a ill-defined part of the kms api, but I think we
>> still should strive for consistency. Maybe the modesetting ddx should also
>> grow a warning if the possible_clones mask doesn't make too much sense.
>
> I haven't been able to find an authoritative source of documentation regarding
> whether the possible_clones field should include the encoder itself. That
> should definitely be documented, I can fix the driver accordingly.
Yeah, sounds like something worth clarifying. I'd vote for the
self-clone bit to be set (I'm biased though, that's what i915 does). I
guess we could even enforce consistency by putting this into the drm
encoders.
Since the modesetting driver seems to not care too much I guess we can
fix that later on, imo not something to block merging rcar on.
[snip]
>> > +static int rcar_du_vga_connector_get_modes(struct drm_connector
>> > *connector)
>> > +{
>> > + return drm_add_modes_noedid(connector, 1280, 768);
>> > +}
>>
>> This (and the dummy detect function below) looks a bit funny, since it
>> essentially overrides the default behaviour already provided by the crtc
>> helpers. Until rcar has at least p
[PATCH] nouveau: Load firmware for BSP/VP engines on NV84-NV96, NVA0
On Mon, Jun 3, 2013 at 5:02 AM, Ilia Mirkin wrote:
> These chipsets include the VP2 engine which is composed of a bitstream
> processor (BSP) that decodes H.264 and a video processor (VP) which can
> do iDCT/mo-comp/etc for MPEG1/2, H.264, and VC-1. Both of these are
> driven by separate xtensa chips embedded in the hardware. This patch
> provides the mechanism to load the kernel for the xtensa chips and
> provide the necessary interactions to do the rest of the work.
>
> Signed-off-by: Ilia Mirkin
> ---
>
> This patch applies on top of nouveau/master (16a41bcc8).
>
> This seems to work for me. There was one boot where my userspace
> component didn't work right, but it could just as well be a bug
> there. Subsequent attempts seem to work fine. Note that I'm not
> particularly familiar with any of this stuff, so if something looks
> odd, I probably didn't know any better. I did try to faithfully
> reproduce whatever the blob did. A few questions/thoughts:
>
> 1. There's a LOT of similarity between BSP and VP setup/etc. Is it
>worth it to create a core/xtensa.c or some such, similar to
>falcon.c? Since it's only in two places, not that much code, and
>there _are_ differences, I decided to keep them separate.
>
> 2. Firmware naming. Maarten suggested to use the falcon naming style,
>which is nv$chipset_fuc$offset. However here, all the chips share
>the same firmware. Also the offset would be 103 vs 00f, and is a
>little arbitrary. (And fuc doesn't apply here... xt? xtensa?) I've
>left it the way I had it: nv84_bsp and nv84_vp.
>
> 3. Firmware load time. I chose to load the fw into memory in the ctor,
>and then copy it in in init, due to some potentially bogus
>suspend/resume concerns. Also e.g. mplayer likes to create/destroy
>decoders at startup a few times. The downside is that ~200KB of
>memory is gone. Let me know if I should change it to do the
>request_firmware in init.
>
> There's obviously a userspace piece to this, which I'm still working
> on. But right now I have it working within certain parameters
> (e.g. 1280x544 videos), and I'm relatively confident it can be
> completed without further kernel-side changes.
>
> There's also a hypothetical concern of "what if we create an open
> firmware with a different user API". Ideally there'd be some way to
> expose what kind of firmware is loaded, but I think that can be left
> for "later".
I also happened to notice that NV98, NVA1+ refer to these nv84 engines
(in drivers/gpu/drm/nouveau/core/engine/device/nv50.c). I assume that
means I should create a new nv98.c version of BSP/VP that resembles
the old versions of nv84.c, and point device/nv50.c at those for nv98
and nva1+?
>
> drivers/gpu/drm/nouveau/core/engine/bsp/nv84.c | 139 ++-
> drivers/gpu/drm/nouveau/core/engine/fifo/nv84.c | 4 +
> drivers/gpu/drm/nouveau/core/engine/vp/nv84.c | 140
> +++-
> drivers/gpu/drm/nouveau/core/subdev/mc/nv50.c | 1 +
> drivers/gpu/drm/nouveau/core/subdev/vm/nv50.c | 2 +
> 5 files changed, 278 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/core/engine/bsp/nv84.c
> b/drivers/gpu/drm/nouveau/core/engine/bsp/nv84.c
> index 1d9f614..04880d9 100644
> --- a/drivers/gpu/drm/nouveau/core/engine/bsp/nv84.c
> +++ b/drivers/gpu/drm/nouveau/core/engine/bsp/nv84.c
> @@ -29,6 +29,10 @@
>
> struct nv84_bsp_priv {
> struct nouveau_engine base;
> + u32 *fw;
> + long fw_size;
> + struct nouveau_gpuobj *gpu_fw;
> + void *vm_gpu_fw;
> };
>
>
> /***
> @@ -37,6 +41,7 @@ struct nv84_bsp_priv {
>
> static struct nouveau_oclass
> nv84_bsp_sclass[] = {
> + { 0x74b0, &nouveau_object_ofuncs },
> {},
> };
>
> @@ -44,11 +49,28 @@ nv84_bsp_sclass[] = {
> * BSP context
>
> **/
>
> +static int
> +nv84_bsp_engctx_ctor(struct nouveau_object *parent,
> +struct nouveau_object *engine,
> +struct nouveau_oclass *oclass, void *data, u32 size,
> +struct nouveau_object **pobject)
> +{
> + struct nouveau_engctx *engctx;
> + int ret;
> +
> + ret = nouveau_engctx_create(parent, engine, oclass, NULL,
> + 0x1, 0x1000,
> + NVOBJ_FLAG_ZERO_ALLOC, &engctx);
> + *pobject = nv_object(engctx);
> + return ret;
> +}
> +
> +
> static struct nouveau_oclass
> nv84_bsp_cclass = {
> .handle = NV_ENGCTX(BSP, 0x84),
> .ofuncs = &(struct nouveau_ofuncs) {
> - .ctor = _nouveau_engctx_ctor,
> + .ctor = nv84_bsp_engctx_ctor,
> .dtor = _nouveau_engctx_dtor,
> .init = _nouveau_engctx_init,
> .fini = _nouveau_engctx_fini,
> @@ -61,6 +83,24 @@ nv84_
[PATCH v2 3/5] drm: GEM CMA: Split object creation into object alloc and DMA memory alloc
On Mon, Jun 3, 2013 at 10:20 PM, Laurent Pinchart
wrote:
> This allows creating a GEM CMA object without an associated DMA memory
> buffer, and will be used to implement DRM PRIME support.
>
> Signed-off-by: Laurent Pinchart
Reviewed-by: Rob Clark
> ---
> drivers/gpu/drm/drm_gem_cma_helper.c | 83
> +---
> 1 file changed, 48 insertions(+), 35 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_gem_cma_helper.c
> b/drivers/gpu/drm/drm_gem_cma_helper.c
> index 0a7e011..8cce330 100644
> --- a/drivers/gpu/drm/drm_gem_cma_helper.c
> +++ b/drivers/gpu/drm/drm_gem_cma_helper.c
> @@ -32,62 +32,73 @@ static unsigned int get_gem_mmap_offset(struct
> drm_gem_object *obj)
> return (unsigned int)obj->map_list.hash.key << PAGE_SHIFT;
> }
>
> -static void drm_gem_cma_buf_destroy(struct drm_device *drm,
> - struct drm_gem_cma_object *cma_obj)
> -{
> - dma_free_writecombine(drm->dev, cma_obj->base.size, cma_obj->vaddr,
> - cma_obj->paddr);
> -}
> -
> /*
> - * drm_gem_cma_create - allocate an object with the given size
> + * __drm_gem_cma_create - Create a GEM CMA object without allocating memory
> + * @drm: The drm device
> + * @size: The GEM object size
> *
> - * returns a struct drm_gem_cma_object* on success or ERR_PTR values
> - * on failure.
> + * This function creates and initializes a GEM CMA object of the given size,
> but
> + * doesn't allocate any memory to back the object.
> + *
> + * Return a struct drm_gem_cma_object* on success or ERR_PTR values on
> failure.
> */
> -struct drm_gem_cma_object *drm_gem_cma_create(struct drm_device *drm,
> - unsigned int size)
> +static struct drm_gem_cma_object *
> +__drm_gem_cma_create(struct drm_device *drm, unsigned int size)
> {
> struct drm_gem_cma_object *cma_obj;
> struct drm_gem_object *gem_obj;
> int ret;
>
> - size = round_up(size, PAGE_SIZE);
> -
> cma_obj = kzalloc(sizeof(*cma_obj), GFP_KERNEL);
> if (!cma_obj)
> return ERR_PTR(-ENOMEM);
>
> - cma_obj->vaddr = dma_alloc_writecombine(drm->dev, size,
> - &cma_obj->paddr, GFP_KERNEL | __GFP_NOWARN);
> - if (!cma_obj->vaddr) {
> - dev_err(drm->dev, "failed to allocate buffer with size %d\n",
> size);
> - ret = -ENOMEM;
> - goto err_dma_alloc;
> - }
> -
> gem_obj = &cma_obj->base;
>
> ret = drm_gem_object_init(drm, gem_obj, size);
> if (ret)
> - goto err_obj_init;
> + goto error;
>
> ret = drm_gem_create_mmap_offset(gem_obj);
> - if (ret)
> - goto err_create_mmap_offset;
> + if (ret) {
> + drm_gem_object_release(gem_obj);
> + goto error;
> + }
>
> return cma_obj;
>
> -err_create_mmap_offset:
> - drm_gem_object_release(gem_obj);
> +error:
> + kfree(cma_obj);
> + return ERR_PTR(ret);
> +}
>
> -err_obj_init:
> - drm_gem_cma_buf_destroy(drm, cma_obj);
> +/*
> + * drm_gem_cma_create - allocate an object with the given size
> + *
> + * returns a struct drm_gem_cma_object* on success or ERR_PTR values
> + * on failure.
> + */
> +struct drm_gem_cma_object *drm_gem_cma_create(struct drm_device *drm,
> + unsigned int size)
> +{
> + struct drm_gem_cma_object *cma_obj;
>
> -err_dma_alloc:
> - kfree(cma_obj);
> + size = round_up(size, PAGE_SIZE);
>
> - return ERR_PTR(ret);
> + cma_obj = __drm_gem_cma_create(drm, size);
> + if (IS_ERR(cma_obj))
> + return cma_obj;
> +
> + cma_obj->vaddr = dma_alloc_writecombine(drm->dev, size,
> + &cma_obj->paddr, GFP_KERNEL | __GFP_NOWARN);
> + if (!cma_obj->vaddr) {
> + dev_err(drm->dev, "failed to allocate buffer with size %d\n",
> + size);
> + drm_gem_cma_free_object(&cma_obj->base);
> + return ERR_PTR(-ENOMEM);
> + }
> +
> + return cma_obj;
> }
> EXPORT_SYMBOL_GPL(drm_gem_cma_create);
>
> @@ -143,11 +154,13 @@ void drm_gem_cma_free_object(struct drm_gem_object
> *gem_obj)
> if (gem_obj->map_list.map)
> drm_gem_free_mmap_offset(gem_obj);
>
> - drm_gem_object_release(gem_obj);
> -
> cma_obj = to_drm_gem_cma_obj(gem_obj);
>
> - drm_gem_cma_buf_destroy(gem_obj->dev, cma_obj);
> + if (cma_obj->vaddr)
> + dma_free_writecombine(gem_obj->dev->dev, cma_obj->base.size,
> + cma_obj->vaddr, cma_obj->paddr);
> +
> + drm_gem_object_release(gem_obj);
>
> kfree(cma_obj);
> }
> --
> 1.8.1.5
>
[PATCH v2 4/5] drm: GEM CMA: Split object mapping into GEM mapping and CMA mapping
On Mon, Jun 3, 2013 at 10:20 PM, Laurent Pinchart
wrote:
> The CMA-specific mapping code will be used to implement dma-buf mmap
> support.
>
> Signed-off-by: Laurent Pinchart
Signed-off-by: Rob Clark
> ---
> drivers/gpu/drm/drm_gem_cma_helper.c | 22 +++---
> 1 file changed, 15 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_gem_cma_helper.c
> b/drivers/gpu/drm/drm_gem_cma_helper.c
> index 8cce330..7a4db4e 100644
> --- a/drivers/gpu/drm/drm_gem_cma_helper.c
> +++ b/drivers/gpu/drm/drm_gem_cma_helper.c
> @@ -228,13 +228,26 @@ const struct vm_operations_struct drm_gem_cma_vm_ops = {
> };
> EXPORT_SYMBOL_GPL(drm_gem_cma_vm_ops);
>
> +static int drm_gem_cma_mmap_obj(struct drm_gem_cma_object *cma_obj,
> + struct vm_area_struct *vma)
> +{
> + int ret;
> +
> + ret = remap_pfn_range(vma, vma->vm_start, cma_obj->paddr >>
> PAGE_SHIFT,
> + vma->vm_end - vma->vm_start, vma->vm_page_prot);
> + if (ret)
> + drm_gem_vm_close(vma);
> +
> + return ret;
> +}
> +
> /*
> * drm_gem_cma_mmap - (struct file_operation)->mmap callback function
> */
> int drm_gem_cma_mmap(struct file *filp, struct vm_area_struct *vma)
> {
> - struct drm_gem_object *gem_obj;
> struct drm_gem_cma_object *cma_obj;
> + struct drm_gem_object *gem_obj;
> int ret;
>
> ret = drm_gem_mmap(filp, vma);
> @@ -244,12 +257,7 @@ int drm_gem_cma_mmap(struct file *filp, struct
> vm_area_struct *vma)
> gem_obj = vma->vm_private_data;
> cma_obj = to_drm_gem_cma_obj(gem_obj);
>
> - ret = remap_pfn_range(vma, vma->vm_start, cma_obj->paddr >>
> PAGE_SHIFT,
> - vma->vm_end - vma->vm_start, vma->vm_page_prot);
> - if (ret)
> - drm_gem_vm_close(vma);
> -
> - return ret;
> + return drm_gem_cma_mmap_obj(cma_obj, vma);
> }
> EXPORT_SYMBOL_GPL(drm_gem_cma_mmap);
>
> --
> 1.8.1.5
>
[Bug 60879] [radeonsi] X11 can't start with acceleration enabled
https://bugs.freedesktop.org/show_bug.cgi?id=60879
--- Comment #37 from Hristo Venev ---
I updated llvm, clang and mesa. Division and modulo still don't work. Another
thing I noticed is that ifs which depend on memory loads cause llvm crash:
__kernel void add(__global const uint *a, __global const uint *b, __global
uint *c){
ulong id=get_global_id(0); // OK
if(id>10) return; // OK
if(b[id]==0) return; // crash
c[id]=a[id]/b[id]; // GPU hang
}
a[id] is id+1
b[id] is 2*id+2
Stack dump:
0.Running pass 'Function Pass Manager' on module 'radeon'.
1.Running pass 'AMDGPU DAG->DAG Pattern Instruction Selection' on function
'@add'
Segmentation fault
#0 0x7461c8a7 in ?? () from /usr/lib64/llvm/libLLVM-3.4svn.so
#1 0x73e36208 in llvm::SelectionDAGISel::DoInstructionSelection() ()
from /usr/lib64/llvm/libLLVM-3.4svn.so
#2 0x73e3c620 in llvm::SelectionDAGISel::CodeGenAndEmitDAG() () from
/usr/lib64/llvm/libLLVM-3.4svn.so
#3 0x73e3e0f2 in
llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&) () from
/usr/lib64/llvm/libLLVM-3.4svn.so
#4 0x73e3f421 in
llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) () from
/usr/lib64/llvm/libLLVM-3.4svn.so
#5 0x73acaeb2 in llvm::FPPassManager::runOnFunction(llvm::Function&)
() from /usr/lib64/llvm/libLLVM-3.4svn.so
#6 0x73acaf4b in llvm::FPPassManager::runOnModule(llvm::Module&) ()
from /usr/lib64/llvm/libLLVM-3.4svn.so
#7 0x73acb195 in llvm::MPPassManager::runOnModule(llvm::Module&) ()
from /usr/lib64/llvm/libLLVM-3.4svn.so
#8 0x73acd1dc in llvm::PassManagerImpl::run(llvm::Module&) () from
/usr/lib64/llvm/libLLVM-3.4svn.so
#9 0x7417c009 in ?? () from /usr/lib64/llvm/libLLVM-3.4svn.so
#10 0x7417c382 in LLVMTargetMachineEmitToMemoryBuffer () from
/usr/lib64/llvm/libLLVM-3.4svn.so
#11 0x72ae6ab1 in radeon_llvm_compile () from
/usr/lib64/gallium-pipe/pipe_radeonsi.so
#12 0x72adc65d in si_compile_llvm () from
/usr/lib64/gallium-pipe/pipe_radeonsi.so
#13 0x72adef79 in ?? () from /usr/lib64/gallium-pipe/pipe_radeonsi.so
#14 0x76d882a7 in _cl_kernel::exec_context::bind(_cl_command_queue*) ()
from /usr/lib64/libOpenCL.so.1
#15 0x76d88e46 in _cl_kernel::launch(_cl_command_queue&,
std::vector > const&,
std::vector > const&,
std::vector > const&) () from
/usr/lib64/libOpenCL.so.1
#16 0x76d847dc in _cl_event::trigger() () from
/usr/lib64/libOpenCL.so.1
#17 0x76d84e54 in clover::hard_event::hard_event(_cl_command_queue&,
unsigned int, std::vector<_cl_event*, std::allocator<_cl_event*> >,
std::function) ()
from /usr/lib64/libOpenCL.so.1
#18 0x76d9fad5 in clEnqueueNDRangeKernel () from
/usr/lib64/libOpenCL.so.1
--
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/20130604/e525d019/attachment.html>
[Bug 65377] New: Backlight control via /sys/class/backlight/radeon_bl0 not working
https://bugs.freedesktop.org/show_bug.cgi?id=65377 Priority: medium Bug ID: 65377 Assignee: dri-devel at lists.freedesktop.org Summary: Backlight control via /sys/class/backlight/radeon_bl0 not working Severity: normal Classification: Unclassified OS: Linux (All) Reporter: bastian.triller at gmail.com Hardware: x86-64 (AMD64) Status: NEW Version: XOrg CVS Component: DRM/Radeon Product: DRI This is a Macbook pro 8,2 with an Intel HD Graphics 3000 [8086:0116] and an AMD Radeon HD 6750M [1002:6741]. The backlight interface in /sys/class/backlight/radeon_bl0 does not work. Echoing to "brightness" does not change the brightness of the Monitor. There is also an apple_gmux interface, which works though. I've bound xbacklight to the brightness keys to control the brightness, but it looks like it's confused about which interface it should use: $ xbacklight -inc 5 No outputs have backlight property When I disable the Radeon card on boot and use the Intel card, xbacklight works. -- 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/20130604/f80e9d46/attachment.html>
[Bug 65377] Backlight control via /sys/class/backlight/radeon_bl0 not working
https://bugs.freedesktop.org/show_bug.cgi?id=65377 --- Comment #1 from Alex Deucher --- If you are booting in EFI mode, does it work if you boot in legacy bios mode? Since it's a mac, it probably requires some mac specific hack. -- 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/20130604/74bfcea7/attachment-0001.html>
[REGRESSION] nouveau: Resume hung after protecting against client races (MBA3,1)
Hi Ben, The new mutexes in nvc0/nv50 (fadb17190/b509656) break resume on my MBA3,1. A dead-lock somewhere, perhaps? Reverting fixes the problem. Thanks, Henrik
[REGRESSION] nouveau: Resume hung after protecting against client races (MBA3,1)
On Tue, Jun 4, 2013 at 4:48 PM, Henrik Rydberg wrote: > Hi Ben, > > The new mutexes in nvc0/nv50 (fadb17190/b509656) break resume on my > MBA3,1. A dead-lock somewhere, perhaps? Reverting fixes the problem. A bunch of people saw it earlier. Fixed for nv50 (which is what I assume you have) in http://cgit.freedesktop.org/nouveau/linux-2.6/commit/?id=e9de89adcecb7a1296f5bc4d0052f58e18edd0a8 I assume it's on its way to mainline. -ilia
[Bug 65377] Backlight control via /sys/class/backlight/radeon_bl0 not working
https://bugs.freedesktop.org/show_bug.cgi?id=65377 --- Comment #2 from Bastian Triller --- (In reply to comment #1) > If you are booting in EFI mode, does it work if you boot in legacy bios > mode? Since it's a mac, it probably requires some mac specific hack. I'm booting via EFI stub. I'm not sure how to boot the bios emulation mode. Is it possible to plug in a usb stick with a "normal" live system to boot in emulation mode? -- 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/20130604/945a2f78/attachment.html>
[Bug 65377] Backlight control via /sys/class/backlight/radeon_bl0 not working
https://bugs.freedesktop.org/show_bug.cgi?id=65377 --- Comment #3 from Alex Deucher --- (In reply to comment #2) > I'm booting via EFI stub. I'm not sure how to boot the bios emulation mode. > Is it possible to plug in a usb stick with a "normal" live system to boot in > emulation mode? I'm not sure. -- 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/20130604/dc2a87b3/attachment.html>
[Bug 60879] [radeonsi] X11 can't start with acceleration enabled
https://bugs.freedesktop.org/show_bug.cgi?id=60879 --- Comment #38 from Tom Stellard --- The OpenCL failures are unrelated to the original bug, so can you please file a separate bug for them. This bug has been outstanding for a while, and it seems like there are actually several "bugs". Could you please summarize the problems you are currently having and list the versions or git HEAD commits that you are using for glamor, xf86-video-ati, Xorg server, Linux kernel, Mesa, and LLVM. Thanks. -- 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/20130604/6d301fd6/attachment.html>
[PATCH v2 5/5] drm: GEM CMA: Add DRM PRIME support
couple small comments, other than those it looks ok
BR,
-R
On Mon, Jun 3, 2013 at 10:20 PM, Laurent Pinchart
wrote:
> Signed-off-by: Laurent Pinchart
> ---
> drivers/gpu/drm/drm_gem_cma_helper.c | 321
> ++-
> include/drm/drm_gem_cma_helper.h | 9 +
> 2 files changed, 327 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_gem_cma_helper.c
> b/drivers/gpu/drm/drm_gem_cma_helper.c
> index 7a4db4e..1dc2157 100644
> --- a/drivers/gpu/drm/drm_gem_cma_helper.c
> +++ b/drivers/gpu/drm/drm_gem_cma_helper.c
> @@ -21,6 +21,9 @@
> #include
> #include
> #include
> +#if CONFIG_DMA_SHARED_BUFFER
> +#include
> +#endif
I don't think we need the #if, since drm selects DMA_SHARED_BUFFER
and same for other spot below
> #include
>
> #include
> @@ -82,6 +85,8 @@ struct drm_gem_cma_object *drm_gem_cma_create(struct
> drm_device *drm,
> unsigned int size)
> {
> struct drm_gem_cma_object *cma_obj;
> + struct sg_table *sgt = NULL;
> + int ret;
>
> size = round_up(size, PAGE_SIZE);
>
> @@ -94,11 +99,29 @@ struct drm_gem_cma_object *drm_gem_cma_create(struct
> drm_device *drm,
> if (!cma_obj->vaddr) {
> dev_err(drm->dev, "failed to allocate buffer with size %d\n",
> size);
> - drm_gem_cma_free_object(&cma_obj->base);
> - return ERR_PTR(-ENOMEM);
> + ret = -ENOMEM;
> + goto error;
> }
>
> + sgt = kzalloc(sizeof(*cma_obj->sgt), GFP_KERNEL);
> + if (sgt == NULL) {
> + ret = -ENOMEM;
> + goto error;
> + }
> +
> + ret = dma_get_sgtable(drm->dev, sgt, cma_obj->vaddr,
> + cma_obj->paddr, size);
> + if (ret < 0)
> + goto error;
> +
> + cma_obj->sgt = sgt;
> +
> return cma_obj;
> +
> +error:
> + kfree(sgt);
> + drm_gem_cma_free_object(&cma_obj->base);
> + return ERR_PTR(ret);
> }
> EXPORT_SYMBOL_GPL(drm_gem_cma_create);
>
> @@ -156,9 +179,16 @@ void drm_gem_cma_free_object(struct drm_gem_object
> *gem_obj)
>
> cma_obj = to_drm_gem_cma_obj(gem_obj);
>
> - if (cma_obj->vaddr)
> + if (cma_obj->vaddr) {
> dma_free_writecombine(gem_obj->dev->dev, cma_obj->base.size,
> cma_obj->vaddr, cma_obj->paddr);
> + if (cma_obj->sgt) {
> + sg_free_table(cma_obj->sgt);
> + kfree(cma_obj->sgt);
> + }
> + } else if (gem_obj->import_attach) {
> + drm_prime_gem_destroy(gem_obj, cma_obj->sgt);
> + }
>
> drm_gem_object_release(gem_obj);
>
> @@ -291,3 +321,288 @@ void drm_gem_cma_describe(struct drm_gem_cma_object
> *cma_obj, struct seq_file *m
> }
> EXPORT_SYMBOL_GPL(drm_gem_cma_describe);
> #endif
> +
> +/*
> -
> + * DMA-BUF
> + */
> +
> +#if CONFIG_DMA_SHARED_BUFFER
> +struct drm_gem_cma_dmabuf_attachment {
> + struct sg_table sgt;
> + enum dma_data_direction dir;
> +};
> +
> +static int drm_gem_cma_dmabuf_attach(struct dma_buf *dmabuf, struct device
> *dev,
> +struct dma_buf_attachment *attach)
> +{
> + struct drm_gem_cma_dmabuf_attachment *cma_attach;
> +
> + cma_attach = kzalloc(sizeof(*cma_attach), GFP_KERNEL);
> + if (!cma_attach)
> + return -ENOMEM;
> +
> + cma_attach->dir = DMA_NONE;
> + attach->priv = cma_attach;
> +
> + return 0;
> +}
> +
> +static void drm_gem_cma_dmabuf_detach(struct dma_buf *dmabuf,
> + struct dma_buf_attachment *attach)
> +{
> + struct drm_gem_cma_dmabuf_attachment *cma_attach = attach->priv;
> + struct sg_table *sgt;
> +
> + if (cma_attach == NULL)
> + return;
> +
> + sgt = &cma_attach->sgt;
> +
> + if (cma_attach->dir != DMA_NONE)
> + dma_unmap_sg(attach->dev, sgt->sgl, sgt->nents,
> + cma_attach->dir);
> +
> + sg_free_table(sgt);
> + kfree(cma_attach);
> + attach->priv = NULL;
> +}
> +
> +static struct sg_table *
> +drm_gem_cma_dmabuf_map(struct dma_buf_attachment *attach,
> + enum dma_data_direction dir)
> +{
> + struct drm_gem_cma_dmabuf_attachment *cma_attach = attach->priv;
> + struct drm_gem_cma_object *cma_obj = attach->dmabuf->priv;
> + struct drm_device *drm = cma_obj->base.dev;
> + struct scatterlist *rd, *wr;
> + struct sg_table *sgt;
> + unsigned int i;
> + int nents, ret;
> +
> + DRM_DEBUG_PRIME("\n");
> +
> + if (WARN_ON(dir == DMA_NONE))
> + return ERR_PTR(-EINVAL);
> +
> + /* Return the cached mapping when possible. */
> + if (cma_attach->dir == dir)
> +
[pull] radeon drm-fixes-3.10
From: Alex Deucher Hi Dave, Just a few fixes for radeon. The big one is a fix for hangs on older asics due to the ordering of interrupt initialization. The following changes since commit 91f8f105f2b82b4a38dee2d74760bc39d40ec42c: drm/mgag200: Add missing write to index before accessing data register (2013-06-03 19:21:07 +1000) are available in the git repository at: git://people.freedesktop.org/~agd5f/linux drm-fixes-3.10 Adis Hamzi? (1): radeon: Fix system hang issue when using KMS with older cards Alex Deucher (1): drm/radeon: don't allow audio on DCE6 Samuel Li (1): drm/radeon: Use direct mapping for fast fb access on RS780/RS880 (v2) drivers/gpu/drm/radeon/atombios_encoders.c | 11 -- drivers/gpu/drm/radeon/evergreen.c | 10 +++-- drivers/gpu/drm/radeon/ni.c| 10 +++-- drivers/gpu/drm/radeon/r100.c |9 +++-- drivers/gpu/drm/radeon/r300.c |9 +++-- drivers/gpu/drm/radeon/r420.c | 10 +++-- drivers/gpu/drm/radeon/r520.c |9 +++-- drivers/gpu/drm/radeon/r600.c | 53 +-- drivers/gpu/drm/radeon/r600d.h |8 drivers/gpu/drm/radeon/radeon_asic.c |4 ++ drivers/gpu/drm/radeon/radeon_asic.h |2 + drivers/gpu/drm/radeon/rs400.c |9 +++-- drivers/gpu/drm/radeon/rs600.c |9 +++-- drivers/gpu/drm/radeon/rs690.c |9 +++-- drivers/gpu/drm/radeon/rv515.c |9 +++-- drivers/gpu/drm/radeon/rv770.c | 10 +++-- drivers/gpu/drm/radeon/si.c| 10 +++-- 17 files changed, 143 insertions(+), 48 deletions(-)
[Bug 65192] [r600g] Screensavers lock up machine (screen goes blank, keyboard unresponsive, sound loops; sysrq/ssh possible)
https://bugs.freedesktop.org/show_bug.cgi?id=65192 --- Comment #9 from Luzipher --- Unfortunately I couldn't confirm my thoughts. But I still am quite sure I did not have those problems earlier - I had screensavers and youtube last year and didn't notice regular crashes. I frequently use this linux installation, in fact it's my main os for several years now, so I really would have noticed. Maybe it's another package ? X, libdrm, radeon-ucode, xf86-video-ati come to mind. Maybe mostly radeon-ucode, as I have the feeling that the problems started at about the same time as the buzz on the uvd code drop. Well, tests done (I could reproduce the crash on every of these with directly started juggler3d on closing the window, mostly first or second try): mesa-9.0.3 (forgot to get glxinfo) mesa-9.0.1.ebuild, glxinfo: OpenGL renderer string: Gallium 0.4 on AMD RV770 OpenGL version string: 3.0 Mesa 9.0.1 OpenGL shading language version string: 1.30 mesa-8.0.4-r1.ebuild, glxinfo: OpenGL renderer string: Gallium 0.4 on AMD RV770 OpenGL version string: 2.1 Mesa 8.0.4 OpenGL shading language version string: 1.20 with 8.0.4, I got only garbage and a lot of these messages: radeon: The kernel rejected CS, see dmesg for more information. dmesg: [ 1580.805418] radeon :02:00.0: r600_cs_track_validate_cb invalid tiling 6 for 0 (0x08110668) [ 1580.805463] radeon :02:00.0: r600_packet3_check:1720 invalid cmd stream 573 [ 1580.805465] [drm:radeon_cs_ib_chunk] *ERROR* Invalid command stream ! I also tried the oldest kernel I have with 8.0.4, it's a vanilla 3.4.0-rc6. Even there I could get the same crash after closing the window with the garbage output. -- 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/20130604/848fab81/attachment.html>
[PATCH v2 5/5] drm: GEM CMA: Add DRM PRIME support
On Tue, Jun 4, 2013 at 9:22 PM, Laurent Pinchart
wrote:
> Hi Rob,
>
> On Tuesday 04 June 2013 17:56:36 Rob Clark wrote:
>> couple small comments, other than those it looks ok
>
> Thanks for the review.
>
>> On Mon, Jun 3, 2013 at 10:20 PM, Laurent Pinchart wrote:
>> > Signed-off-by: Laurent Pinchart
>> >
>> > ---
>> >
>> > drivers/gpu/drm/drm_gem_cma_helper.c | 321 +-
>> > include/drm/drm_gem_cma_helper.h | 9 +
>> > 2 files changed, 327 insertions(+), 3 deletions(-)
>> >
>> > diff --git a/drivers/gpu/drm/drm_gem_cma_helper.c
>> > b/drivers/gpu/drm/drm_gem_cma_helper.c index 7a4db4e..1dc2157 100644
>> > --- a/drivers/gpu/drm/drm_gem_cma_helper.c
>> > +++ b/drivers/gpu/drm/drm_gem_cma_helper.c
>> > @@ -21,6 +21,9 @@
>> > #include
>> > #include
>> > #include
>> > +#if CONFIG_DMA_SHARED_BUFFER
>> > +#include
>> > +#endif
>>
>> I don't think we need the #if, since drm selects DMA_SHARED_BUFFER
>>
>> and same for other spot below
>
> Indeed. Will be fixed in the next version.
>
>> > #include
>> >
>> > #include
>
> [snip]
>
>> > @@ -291,3 +321,288 @@ void drm_gem_cma_describe(struct drm_gem_cma_object
>> > *cma_obj, struct seq_file *m>
>> > }
>> > EXPORT_SYMBOL_GPL(drm_gem_cma_describe);
>> > #endif
>> >
>> > +
>> > +/*
>> > -
>> > + * DMA-BUF
>> > + */
>> > +
>> > +#if CONFIG_DMA_SHARED_BUFFER
>> > +struct drm_gem_cma_dmabuf_attachment {
>> > + struct sg_table sgt;
>> > + enum dma_data_direction dir;
>> > +};
>> > +
>> > +static int drm_gem_cma_dmabuf_attach(struct dma_buf *dmabuf, struct
>> > device *dev, +struct
>> > dma_buf_attachment *attach) +{
>> > + struct drm_gem_cma_dmabuf_attachment *cma_attach;
>> > +
>> > + cma_attach = kzalloc(sizeof(*cma_attach), GFP_KERNEL);
>> > + if (!cma_attach)
>> > + return -ENOMEM;
>> > +
>> > + cma_attach->dir = DMA_NONE;
>> > + attach->priv = cma_attach;
>> > +
>> > + return 0;
>> > +}
>> > +
>> > +static void drm_gem_cma_dmabuf_detach(struct dma_buf *dmabuf,
>> > + struct dma_buf_attachment *attach)
>> > +{
>> > + struct drm_gem_cma_dmabuf_attachment *cma_attach = attach->priv;
>> > + struct sg_table *sgt;
>> > +
>> > + if (cma_attach == NULL)
>> > + return;
>> > +
>> > + sgt = &cma_attach->sgt;
>> > +
>> > + if (cma_attach->dir != DMA_NONE)
>> > + dma_unmap_sg(attach->dev, sgt->sgl, sgt->nents,
>> > + cma_attach->dir);
>> > +
>> > + sg_free_table(sgt);
>> > + kfree(cma_attach);
>> > + attach->priv = NULL;
>> > +}
>> > +
>> > +static struct sg_table *
>> > +drm_gem_cma_dmabuf_map(struct dma_buf_attachment *attach,
>> > + enum dma_data_direction dir)
>> > +{
>> > + struct drm_gem_cma_dmabuf_attachment *cma_attach = attach->priv;
>> > + struct drm_gem_cma_object *cma_obj = attach->dmabuf->priv;
>> > + struct drm_device *drm = cma_obj->base.dev;
>> > + struct scatterlist *rd, *wr;
>> > + struct sg_table *sgt;
>> > + unsigned int i;
>> > + int nents, ret;
>> > +
>> > + DRM_DEBUG_PRIME("\n");
>> > +
>> > + if (WARN_ON(dir == DMA_NONE))
>> > + return ERR_PTR(-EINVAL);
>> > +
>> > + /* Return the cached mapping when possible. */
>> > + if (cma_attach->dir == dir)
>> > + return &cma_attach->sgt;
>> > +
>> > + /* Two mappings with different directions for the same attachment
>> > are +* not allowed.
>> > +*/
>> > + if (WARN_ON(cma_attach->dir != DMA_NONE))
>> > + return ERR_PTR(-EBUSY);
>> > +
>> > + sgt = &cma_attach->sgt;
>> > +
>> > + ret = sg_alloc_table(sgt, cma_obj->sgt->orig_nents, GFP_KERNEL);
>> > + if (ret) {
>> > + DRM_ERROR("failed to alloc sgt.\n");
>> > + return ERR_PTR(-ENOMEM);
>> > + }
>> > +
>> > + mutex_lock(&drm->struct_mutex);
>> > +
>> > + rd = cma_obj->sgt->sgl;
>> > + wr = sgt->sgl;
>> > + for (i = 0; i < sgt->orig_nents; ++i) {
>> > + sg_set_page(wr, sg_page(rd), rd->length, rd->offset);
>> > + rd = sg_next(rd);
>> > + wr = sg_next(wr);
>> > + }
>> > +
>> > + nents = dma_map_sg(attach->dev, sgt->sgl, sgt->orig_nents, dir);
>> > + if (!nents) {
>> > + DRM_ERROR("failed to map sgl with iommu.\n");
>> > + sg_free_table(sgt);
>> > + sgt = ERR_PTR(-EIO);
>> > + goto done;
>> > + }
>> > +
>> > + cma_attach->dir = dir;
>> > + attach->priv = cma_attach;
>> > +
>> > + DRM_DEBUG_PRIME("buffer size = %zu\n", cma_obj->base.size);
>> > +
>> > +done:
>> > + mutex_unlock(&drm->struct_mutex);
>> > + return sgt;
>> > +}
>> > +
>> >
