Re: [PATCH v3] drm: Renesas R-Car Display Unit DRM driver
On Thursday 06 June 2013 09:21:35 Alex Deucher wrote: > On Thu, Jun 6, 2013 at 9:12 AM, Daniel Vetter wrote: > > On Wed, Jun 5, 2013 at 3:10 PM, Alex Deucher wrote: > >> To me at least, it doesn't make sense that an encoder can clone > >> itself. If an encoder is already in use, trying to clone itself would > >> only lead to confusion and possible bugs (make sure some code path > >> doesn't try and reprogram the encoder again, etc.). > > > > For me the possible_clones mask is just the set of encoders which can > > together share a crtc (presuming that crtc is indeed in all of the > > possible_crtcs mask of each encoder). From that pov it makes imo sense > > that a given encoder itself can always be with itself on the same crtc > > ;-) > > > > Otoh setcrtc doesn't care one bit about encoders (the crtc helpers do > > internally use them, but it's not interface). And the possible_clones > > stuff is by far not enough to describe all hw restrictions. So tbh I > > don't care which way we go (or whether we indeed keep on using this > > much at all). > > Same. I can go either way. So what's the agreement ? :-) -- 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
Hi Daniel,
On Wednesday 05 June 2013 10:55:05 Daniel Vetter wrote:
> On Wed, Jun 05, 2013 at 03:51:53AM +0200, Laurent Pinchart wrote:
> > 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]
>
> > > >> > +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 proper detect support for
> > > >> VGA
> > > >
> > > > I would add that but the DDC signals are not connected on the boards I
> > > > have access to :-/
> > > >
> > > >> I'd just kill this and use the connector force support (and manually
> > > >> adding the right resolutions).
> > > >
> > > > Looks like that's a candidate for better documentation... How does
> > > > force support work ?
> > >
> > > Grep for DRM_FORCE_ON, iirc it can be set on the commandline, where you
> > > can also force a specific mode. The best I could find wrt docs is the
> > > kerneldoc for drm_mode_parse_command_line_for_connector. With a bit more
> > > reading it looks like it's intermingled with the fbdev helper code, but
> > > should be fairly easy to extract and used by your driver.
> >
> > It makes sense to force the connector state from command line, but I'm not
> > sure if the same mechanism is the best solution here. As the driver has no
> > way to know the connector state, the best we can do is guess what modes
> > are supported. I can just return 0 in the get_modes handler, but then the
> > core will not call drm_add_modes_noedid(), and modes will need to be
> > added manually.
> >
> > Is your point that for a board on which the VGA connector state can't be
> > detected, the user should always be responsible for adding all the modes
> > supported by the VGA monitor on the command line ?
>
> My point is that we already have both an established code for connected
> outputs without EDID to add fallback modes and means to force connectors to
> certain states. Your code here seems to reinvent that wheel, so I wonder
> what we should/need to improve in the common code to suit your needs.
The currently available code might suit my needs, it might just be that I fail
to see how to use it properly.
Regarding the "code for connected outputs without EDID to add fallback modes"
you're referring to, is that
if (count == 0 && connector->status == connector_status_connected)
count = drm_add_modes_noedid(connector, 1024, 768);
in drm_helper_probe_single_connector_modes() ? That function will only be
called if the connector status is connector_status_connected. There are two
ways to enforce that:
- returning connector_status_connected from the connector detect() operation,
which seems to defeat the purpose of having connector_status_unknown
completely.
- setting connector->force to DRM_FORCE_ON. Are drivers allowed to do so
themselves at initialization time ? Once again that seems to defeat the
purpose of connector_status_unknown.
> A few ideas:
> - Untangling the connector forcing code from the fbdev helper so that you
> can use it.
> - Exposing the connector state forcing through sysfs so that it's
> runtime-adjustable.
My main concern here is that fbcon won't be available if we delay setting
force mode until userspace is ready..
> - Adding fallback modes for connectors in the unknonw state (imo too much
> risk in breaking something else).
Could you please elaborate on what you thing it could break ?
> Thinking about this some more I'd vote for the new sysfs file to expose
> connector forcing at runtime. With that it'd boil down to 1024x756 vs.
> 1280x768 for the default fallback mode. And that could be fixed with the
> EDID quirk support. Although that looks like it would benefit from a
> per-connector sysfs file, too ;-)
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: New prototype computer problem with S3 suspend
2013-06-07 03:17 keltezéssel, Aaron Lu írta: On 06/07/2013 02:11 AM, Boszormenyi Zoltan wrote: Hi, we are working on an Intel Atom-based embedded PC and I have to make suspend-to-RAM work but I can't seem to succeed. The symptom is that quite often, the machine resumes immediately after pm-suspend. Sometimes more than 20 times out of 50 attempts. Can you please file a bug about this? https://bugzilla.kernel.org I have tried 3.7.10, 3.9.4, 3.10-rc[234] and the linux-next branch from the git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git repository. The attached dmesg is from today's linux-pm/linux-next plus the latest drm-fixes patchset posted by Dave Airlie. I have tried disabling wakeup devices via /proc/acpi/wakeup and via sysfs files. (/sys/devices/.../wakeup) >From the dmesg, the following three devices are still armed with wakeup capability and might be the cause: i8042 kbd 00:03: System wakeup enabled by ACPI PM: suspend of devices complete after 578.883 msecs PM: late suspend of devices complete after 0.279 msecs pcieport :00:1c.1: System wakeup enabled by ACPI ehci-pci :00:1d.7: System wakeup enabled by ACPI PM: noirq suspend of devices complete after 31.946 msecs Anyway, please file a bug there, thanks. For the suspend bug: https://bugzilla.kernel.org/show_bug.cgi?id=59401 For the warnings in i915: https://bugs.freedesktop.org/show_bug.cgi?id=65497 Best regards, Zoltán Böszörményi ___ 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 Fri, Jun 07, 2013 at 09:44:45AM +0200, Laurent Pinchart wrote:
> Hi Daniel,
>
> On Wednesday 05 June 2013 10:55:05 Daniel Vetter wrote:
> > On Wed, Jun 05, 2013 at 03:51:53AM +0200, Laurent Pinchart wrote:
> > > 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]
> >
> > > > >> > +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 proper detect support for
> > > > >> VGA
> > > > >
> > > > > I would add that but the DDC signals are not connected on the boards I
> > > > > have access to :-/
> > > > >
> > > > >> I'd just kill this and use the connector force support (and manually
> > > > >> adding the right resolutions).
> > > > >
> > > > > Looks like that's a candidate for better documentation... How does
> > > > > force support work ?
> > > >
> > > > Grep for DRM_FORCE_ON, iirc it can be set on the commandline, where you
> > > > can also force a specific mode. The best I could find wrt docs is the
> > > > kerneldoc for drm_mode_parse_command_line_for_connector. With a bit more
> > > > reading it looks like it's intermingled with the fbdev helper code, but
> > > > should be fairly easy to extract and used by your driver.
> > >
> > > It makes sense to force the connector state from command line, but I'm not
> > > sure if the same mechanism is the best solution here. As the driver has no
> > > way to know the connector state, the best we can do is guess what modes
> > > are supported. I can just return 0 in the get_modes handler, but then the
> > > core will not call drm_add_modes_noedid(), and modes will need to be
> > > added manually.
> > >
> > > Is your point that for a board on which the VGA connector state can't be
> > > detected, the user should always be responsible for adding all the modes
> > > supported by the VGA monitor on the command line ?
> >
> > My point is that we already have both an established code for connected
> > outputs without EDID to add fallback modes and means to force connectors to
> > certain states. Your code here seems to reinvent that wheel, so I wonder
> > what we should/need to improve in the common code to suit your needs.
>
> The currently available code might suit my needs, it might just be that I
> fail
> to see how to use it properly.
>
> Regarding the "code for connected outputs without EDID to add fallback modes"
> you're referring to, is that
>
> if (count == 0 && connector->status == connector_status_connected)
> count = drm_add_modes_noedid(connector, 1024, 768);
>
> in drm_helper_probe_single_connector_modes() ? That function will only be
> called if the connector status is connector_status_connected. There are two
> ways to enforce that:
>
> - returning connector_status_connected from the connector detect() operation,
> which seems to defeat the purpose of having connector_status_unknown
> completely.
We might want to add such a default mode also for unknown, I'm not sure.
Userspace policy is to first try to light up any connected outputs, and if
there's none try to light up any unknown outputs. Not sure whether
userspace (i.e. X) will automatically add a default mode. fbcon might also
handle this less gracefully.
Personally I'm ok with extending this to unknown, it shouldn't really
hurt (since we already try really hard not to leak unknown anywhere
visible).
> - setting connector->force to DRM_FORCE_ON. Are drivers allowed to do so
> themselves at initialization time ? Once again that seems to defeat the
> purpose of connector_status_unknown.
Atm you can set that with the kernel video= cmdline option, but only if
fbcon force this to be parsed. I think exposing ->force to userspace
somewhere in sysfs would make lots of sense. Drivers imo shouldn't ever
need to touch this. And there's a callback interface so that drivers can
intercept forced connector state, e.g. when they need to set up some stuff
which they otherwise would only do in their ->detect callback.
> > A few ideas:
> > - Untangling the connector forcing code from the fbdev helper so that you
> > can use it.
> > - Exposing the connector state forcing through sysfs so that it's
> > runtime-adjustable.
>
> My main concern here is that fbcon won't be available if we delay setting
> force mode until userspace is ready..
There's also a kernel option. Since we're talking about a VGA connector I
don't think we could do a hardwired quirk here.
> > - Adding fallback modes for connec
Re: [PATCH v3] drm: Renesas R-Car Display Unit DRM driver
On Fri, Jun 07, 2013 at 09:23:58AM +0200, Laurent Pinchart wrote: > On Thursday 06 June 2013 09:21:35 Alex Deucher wrote: > > On Thu, Jun 6, 2013 at 9:12 AM, Daniel Vetter wrote: > > > On Wed, Jun 5, 2013 at 3:10 PM, Alex Deucher wrote: > > >> To me at least, it doesn't make sense that an encoder can clone > > >> itself. If an encoder is already in use, trying to clone itself would > > >> only lead to confusion and possible bugs (make sure some code path > > >> doesn't try and reprogram the encoder again, etc.). > > > > > > For me the possible_clones mask is just the set of encoders which can > > > together share a crtc (presuming that crtc is indeed in all of the > > > possible_crtcs mask of each encoder). From that pov it makes imo sense > > > that a given encoder itself can always be with itself on the same crtc > > > ;-) > > > > > > Otoh setcrtc doesn't care one bit about encoders (the crtc helpers do > > > internally use them, but it's not interface). And the possible_clones > > > stuff is by far not enough to describe all hw restrictions. So tbh I > > > don't care which way we go (or whether we indeed keep on using this > > > much at all). > > > > Same. I can go either way. > > So what's the agreement ? :-) I think officially "meh". Keep your current code and we'll try to fix this once it blows up somewhere for real ;-) -Daniel -- 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
Introduce a dmabuf sync framework for buffer synchronization
Hi all,
Came back :)
Please, ignore previous fence helper. I have re-implemented buffer
synchronization mechanism, dmabuf sync, based on DMA BUF and wound/wait
style lock v5[1] and tested it with 2d gpu and drm kms drivers.
The below is dmabuf sync framework codes,
https://git.kernel.org/cgit/linux/kernel/git/daeinki/drm-exynos.git/commit/?
h=dmabuf-sync&id=ae6c5a0146ab72ea64d9fc91af4595aacf9a5139
And g2d driver with dmabuf sync framework,
https://git.kernel.org/cgit/linux/kernel/git/daeinki/drm-exynos.git/commit/?
h=dmabuf-sync&id=4030bdee9bab5841ad32faade528d04cc0c5fc94
And also exynos drm kms framework,
https://git.kernel.org/cgit/linux/kernel/git/daeinki/drm-exynos.git/commit/?
h=dmabuf-sync&id=6ca548e9ea9e865592719ef6b1cde58366af9f5c
[1] https://patchwork-mail1.kernel.org/patch/2625321/
The purpose of this framework is not only to couple synchronizing caches and
buffer access between CPU and CPU, CPU and DMA, and DMA and DMA but also to
provide easy-to-use interfaces for device drivers: we may need
user interfaces but there is no good way for exposing the interfaces to user
side yet.
Basically, the mechanism of this framework has the following steps,
Initialize dmabuf sync object - A task gets a new sync object allocated and
initialized by dmabuf_sync_init(). This work should be done when a context
or similar thing of device driver is created or before cpu access.
Add a dmabuf to the sync object - A task can add a dmabuf or more that this
task wants to access to its own sync object. This work should be done just
before setting up dma buffer relevant registers or buffer cpu access.
Lock a sync object - A task tries to lock all dmabufs added in the sync
object. And for this, ww-mutexes is used to resolve dead lock. This work
should be done before dma start or cpu access. The lock means DMA or CPU of
current task can access dmabufs so the other cannot access dmabufs.
Unlock a sync object - A task tries to unlock all dmabufs added in the sync
object. This work should be done when after the completion of dma operation
or CPU access. The unlock means DMA or CPU access of current task has been
completed so the other can access the dmabufs.
In addition, this framework includes the following two features,
Consider read and write lock - this feature is for more performance: we
don't need to take a lock in case that a buffer was accessed for read and
current task tries to access the buffer for read. So when current task tries
to take a lock, this feature checks previous access type and desired type to
a given buffer and then decides if it has to take a lock to the buffer or
not.
Consider lockup and resource management - this feature considers the case
that any task never unlocks a buffer after taking a lock to the buffer. In
this case, a timer handler to this task is called sometimes later and then
the buffer is unlocked by workqueue handler to avoid lockup and release the
buffer relevant resources.
Tutorial.
when allocating and initializing device context
struct dmabuf_sync *sync;
sync = dmabuf_sync_init(NULL, NULL);
when setting up dma buffer relevant registers
/* it can be called repeatly for multiple buffers. */
dmabuf_sync_get(sync, dmabuf);
just before dma start or cpu access
dmabuf_sync_lock(sync);
after the completion of dma operation or cpu access
dmabuf_sync_unlock(sync);
dmabuf_sync_put_all(sync);
dmabuf_sync_fini(sync);
Deadlock reproduction with dmabuf sync.
For deadlock test, I had tried to reproduce deadlock situation like below
and the below approach had been worked well,
(Please, presume that two tasks share two dmabufs together.)
[Task A]
struct dmabuf_sync *sync;
sync = dmabuf_sync_init(NULL, NULL);
dmabuf_sync_get(sync, dmabuf A);
dmabuf_sync_get(sync, dmabuf B);
while(1) {
dmabuf_sync_lock(sync);
sleep(1);
dmabuf_sync_unlock(sync);
sleep(1);
}
[Task B]
struct dmabuf_sync *sync;
sync = dmabuf_sync_init(NULL, NULL);
dmabuf_sync_get(sync, dmabuf C);
dmabuf_sync_get(sync, dmabuf A);
while(1) {
dmabuf_sync_lock(sync); <-- deadlock
sleep(1);
dmabuf_sync_unlock(sync);
sleep(1);
}
With the above example codes, deadlock occurs when Task B called
dmabuf_sync_lock function: internally, Task B takes a lock to dmabuf C and
then tries to take a lock to dmabuf A. But at this time, ww_mutex_lock()
returns -EDEADLK because ctx->acquired became 1 once taking a lock to dmabuf
C. And then task B unlocks dmabuf C and takes a slowpath lock to dmabuf A.
And then once Task A unlocks dmabuf A, Task B tries to take a lock to dmabu
[PATCH v3 0/5] GEM CMA DMA-BUF support
Hello, Here's the third version of the GEM CMA DMA-BUF support patches. Changes compared to the previous version are minimal, there will hopefully not be any need for a v4. 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. Rob, could you please ack 5/5 ? Dave, could we then get the patches in v3.11 ? Changes since v2: - Removed #if CONFIG_DMA_SHARED_BUFFER - Picked up Reviewed-by and Acked-by tags from the mailing list Changes since 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 | 404 +++--- 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, 434 insertions(+), 96 deletions(-) -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 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
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 =
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
[PATCH v3 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
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
[PATCH v3 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
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
[PATCH v3 5/5] drm: GEM CMA: Add DRM PRIME support
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/drm_gem_cma_helper.c | 317 ++-
include/drm/drm_gem_cma_helper.h | 9 +
2 files changed, 323 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..f94fcd7 100644
--- a/drivers/gpu/drm/drm_gem_cma_helper.c
+++ b/drivers/gpu/drm/drm_gem_cma_helper.c
@@ -21,6 +21,7 @@
#include
#include
#include
+#include
#include
#include
@@ -82,6 +83,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 +97,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 +177,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 +319,286 @@ 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
+ */
+
+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
[PATCH v3 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
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 65438] GTK apps crash X11 since last update of LLVMM
https://bugs.freedesktop.org/show_bug.cgi?id=65438 --- Comment #3 from Michel Dänzer --- (In reply to comment #2) > so can you provide me some help to do what you ask in gentoo? I'm not familiar with Gentoo, but I'm sure there are many tutorials on Git bisect on the 'net, there might even be one specific to Gentoo. > or howto debug the gpu properly? since gdb/valgrind/etc dont do anything > against llvm[i guess is cuz is getting loaded by mesa and the output goes to > the gpu] It should work just like for any other X server crash, see http://wiki.x.org/wiki/Development/Documentation/ServerDebugging . -- 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: [RFC][PATCH 1/2] dma-buf: add importer private data to attachment
Op 07-06-13 04:32, 김승우 schreef:
> Hello Maarten,
>
> On 2013년 06월 05일 22:23, Maarten Lankhorst wrote:
>> Op 31-05-13 10:54, Seung-Woo Kim schreef:
>>> dma-buf attachment has only exporter private data, but importer private data
>>> can be useful for importer especially to re-import the same dma-buf.
>>> To use importer private data in attachment of the device, the function to
>>> search attachment in the attachment list of dma-buf is also added.
>>>
>>> Signed-off-by: Seung-Woo Kim
>>> ---
>>> drivers/base/dma-buf.c | 31 +++
>>> include/linux/dma-buf.h |4
>>> 2 files changed, 35 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c
>>> index 08fe897..a1eaaf2 100644
>>> --- a/drivers/base/dma-buf.c
>>> +++ b/drivers/base/dma-buf.c
>>> @@ -259,6 +259,37 @@ err_attach:
>>> EXPORT_SYMBOL_GPL(dma_buf_attach);
>>>
>>> /**
>>> + * dma_buf_get_attachment - Get attachment with the device from dma_buf's
>>> + * attachments list
>>> + * @dmabuf:[in]buffer to find device from.
>>> + * @dev: [in]device to be found.
>>> + *
>>> + * Returns struct dma_buf_attachment * attaching the device; may return
>>> + * negative error codes.
>>> + *
>>> + */
>>> +struct dma_buf_attachment *dma_buf_get_attachment(struct dma_buf *dmabuf,
>>> + struct device *dev)
>>> +{
>>> + struct dma_buf_attachment *attach;
>>> +
>>> + if (WARN_ON(!dmabuf || !dev))
>>> + return ERR_PTR(-EINVAL);
>>> +
>>> + mutex_lock(&dmabuf->lock);
>>> + list_for_each_entry(attach, &dmabuf->attachments, node) {
>>> + if (attach->dev == dev) {
>>> + mutex_unlock(&dmabuf->lock);
>>> + return attach;
>>> + }
>>> + }
>>> + mutex_unlock(&dmabuf->lock);
>>> +
>>> + return ERR_PTR(-ENODEV);
>>> +}
>>> +EXPORT_SYMBOL_GPL(dma_buf_get_attachment);
>> NAK in any form..
>>
>> Spot the race condition between dma_buf_get_attachment and dma_buf_attach
> Both dma_buf_get_attachment and dma_buf_attach has mutet with
> dmabuf->lock, and dma_buf_get_attachment is used for get attachment from
> same device before calling dma_buf_attach.
hint: what happens if 2 threads do this:
if (IS_ERR(attach = dma_buf_get_attachment(buf, dev)))
attach = dma_buf_attach(buf, dev);
There really is no correct usecase for this kind of thing, so please don't do
it.
> While, dma_buf_detach can removes attachment because it does not have
> ref count. So importer should check ref count in its importer private
> data before calling dma_buf_detach if the importer want to use
> dma_buf_get_attachment.
>
> And dma_buf_get_attachment is for the importer, so exporter attach and
> detach callback operation should not call it as like exporter detach
> callback operation should not call dma_buf_attach if you mean this kind
> of race.
>
> If you have other considerations here, please describe more specifically.
>
> Thanks and Best Regards,
> - Seung-Woo Kim
>
>> ~Maarten
>>
>>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 5/5] drm: GEM CMA: Add DRM PRIME support
On Fri, Jun 7, 2013 at 5:44 AM, Laurent Pinchart
wrote:
> Signed-off-by: Laurent Pinchart
Reviewed-by: Rob Clark
> ---
> drivers/gpu/drm/drm_gem_cma_helper.c | 317
> ++-
> include/drm/drm_gem_cma_helper.h | 9 +
> 2 files changed, 323 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..f94fcd7 100644
> --- a/drivers/gpu/drm/drm_gem_cma_helper.c
> +++ b/drivers/gpu/drm/drm_gem_cma_helper.c
> @@ -21,6 +21,7 @@
> #include
> #include
> #include
> +#include
> #include
>
> #include
> @@ -82,6 +83,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 +97,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 +177,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 +319,286 @@ 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
> + */
> +
> +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))
> +
Re: [PATCH] drm/radeon: fix write back suspend regression with uvd
On Thu, Jun 6, 2013 at 5:55 PM, wrote:
> From: Jerome Glisse
>
> UVD ring can't use scratch thus it does need writeback buffer to keep
> a valid address or radeon_ring_backup will trigger a kernel fault.
>
> It's ok to not unpin the write back buffer on suspend as it leave in
> gtt and thus does not need eviction.
>
> Reported and tracked by Wojtek
>
> Signed-off-by: Jerome Glisse
Applied. thanks!
Alex
> ---
> drivers/gpu/drm/radeon/radeon_device.c | 15 +--
> 1 file changed, 5 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_device.c
> b/drivers/gpu/drm/radeon/radeon_device.c
> index 1899738..eb8068a 100644
> --- a/drivers/gpu/drm/radeon/radeon_device.c
> +++ b/drivers/gpu/drm/radeon/radeon_device.c
> @@ -244,16 +244,6 @@ void radeon_scratch_free(struct radeon_device *rdev,
> uint32_t reg)
> */
> void radeon_wb_disable(struct radeon_device *rdev)
> {
> - int r;
> -
> - if (rdev->wb.wb_obj) {
> - r = radeon_bo_reserve(rdev->wb.wb_obj, false);
> - if (unlikely(r != 0))
> - return;
> - radeon_bo_kunmap(rdev->wb.wb_obj);
> - radeon_bo_unpin(rdev->wb.wb_obj);
> - radeon_bo_unreserve(rdev->wb.wb_obj);
> - }
> rdev->wb.enabled = false;
> }
>
> @@ -269,6 +259,11 @@ void radeon_wb_fini(struct radeon_device *rdev)
> {
> radeon_wb_disable(rdev);
> if (rdev->wb.wb_obj) {
> + if (!radeon_bo_reserve(rdev->wb.wb_obj, false)) {
> + radeon_bo_kunmap(rdev->wb.wb_obj);
> + radeon_bo_unpin(rdev->wb.wb_obj);
> + radeon_bo_unreserve(rdev->wb.wb_obj);
> + }
> radeon_bo_unref(&rdev->wb.wb_obj);
> rdev->wb.wb = NULL;
> rdev->wb.wb_obj = NULL;
> --
> 1.7.11.7
>
> ___
> 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
[PATCH] drm/radeon: fix AVI infoframe generation
From: Alex Deucher - remove adding 2 to checksum, this breaks certain monitors - properly emit the AVI infoframe version, not emitting the version breaks some monitors. This should fix blank screen when HDMI audio is enabled on certain monitors. Signed-off-by: Alex Deucher Cc: Rafał Miłecki --- drivers/gpu/drm/radeon/evergreen_hdmi.c | 11 ++- drivers/gpu/drm/radeon/r600_hdmi.c | 11 ++- 2 files changed, 4 insertions(+), 18 deletions(-) diff --git a/drivers/gpu/drm/radeon/evergreen_hdmi.c b/drivers/gpu/drm/radeon/evergreen_hdmi.c index ed7c8a7..b9c6f76 100644 --- a/drivers/gpu/drm/radeon/evergreen_hdmi.c +++ b/drivers/gpu/drm/radeon/evergreen_hdmi.c @@ -128,14 +128,7 @@ static void evergreen_hdmi_update_avi_infoframe(struct drm_encoder *encoder, struct radeon_encoder_atom_dig *dig = radeon_encoder->enc_priv; uint32_t offset = dig->afmt->offset; uint8_t *frame = buffer + 3; - - /* Our header values (type, version, length) should be alright, Intel -* is using the same. Checksum function also seems to be OK, it works -* fine for audio infoframe. However calculated value is always lower -* by 2 in comparison to fglrx. It breaks displaying anything in case -* of TVs that strictly check the checksum. Hack it manually here to -* workaround this issue. */ - frame[0x0] += 2; + uint8_t *header = buffer; WREG32(AFMT_AVI_INFO0 + offset, frame[0x0] | (frame[0x1] << 8) | (frame[0x2] << 16) | (frame[0x3] << 24)); @@ -144,7 +137,7 @@ static void evergreen_hdmi_update_avi_infoframe(struct drm_encoder *encoder, WREG32(AFMT_AVI_INFO2 + offset, frame[0x8] | (frame[0x9] << 8) | (frame[0xA] << 16) | (frame[0xB] << 24)); WREG32(AFMT_AVI_INFO3 + offset, - frame[0xC] | (frame[0xD] << 8)); + frame[0xC] | (frame[0xD] << 8) | (header[1] << 24)); } static void evergreen_audio_set_dto(struct drm_encoder *encoder, u32 clock) diff --git a/drivers/gpu/drm/radeon/r600_hdmi.c b/drivers/gpu/drm/radeon/r600_hdmi.c index 456750a..e73b2a7 100644 --- a/drivers/gpu/drm/radeon/r600_hdmi.c +++ b/drivers/gpu/drm/radeon/r600_hdmi.c @@ -133,14 +133,7 @@ static void r600_hdmi_update_avi_infoframe(struct drm_encoder *encoder, struct radeon_encoder_atom_dig *dig = radeon_encoder->enc_priv; uint32_t offset = dig->afmt->offset; uint8_t *frame = buffer + 3; - - /* Our header values (type, version, length) should be alright, Intel -* is using the same. Checksum function also seems to be OK, it works -* fine for audio infoframe. However calculated value is always lower -* by 2 in comparison to fglrx. It breaks displaying anything in case -* of TVs that strictly check the checksum. Hack it manually here to -* workaround this issue. */ - frame[0x0] += 2; + uint8_t *header = buffer; WREG32(HDMI0_AVI_INFO0 + offset, frame[0x0] | (frame[0x1] << 8) | (frame[0x2] << 16) | (frame[0x3] << 24)); @@ -149,7 +142,7 @@ static void r600_hdmi_update_avi_infoframe(struct drm_encoder *encoder, WREG32(HDMI0_AVI_INFO2 + offset, frame[0x8] | (frame[0x9] << 8) | (frame[0xA] << 16) | (frame[0xB] << 24)); WREG32(HDMI0_AVI_INFO3 + offset, - frame[0xC] | (frame[0xD] << 8)); + frame[0xC] | (frame[0xD] << 8) | (header[1] << 24)); } /* -- 1.7.7.5 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/4] drm: Print pretty names for pixel formats
From: Foo Bar
Rather than just printing the pixel format as a hex number, decode the
fourcc into human readable form, and also decode the LE vs. BE flag.
Keep printing the raw hex number too in case it contains non-printable
characters.
Some examples what the new drm_get_format_name() produces:
DRM_FORMAT_XRGB: "XR24 little-endian (0x34325258)"
DRM_FORMAT_YUYV: "YUYV little-endian (0x56595559)"
DRM_FORMAT_RGB565|DRM_FORMAT_BIG_ENDIAN: "RG16 big-endian (0xb6314752)"
Unprintable characters: "D??? big-endian (0xff7f0244)"
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_crtc.c | 29 +++--
include/drm/drm_crtc.h | 1 +
2 files changed, 28 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index e7e9242..079996a 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -29,6 +29,7 @@
* Dave Airlie
* Jesse Barnes
*/
+#include
#include
#include
#include
@@ -252,6 +253,28 @@ char *drm_get_connector_status_name(enum
drm_connector_status status)
}
EXPORT_SYMBOL(drm_get_connector_status_name);
+static char printable_char(int c)
+{
+ return isascii(c) && isprint(c) ? c : '?';
+}
+
+char *drm_get_format_name(uint32_t format)
+{
+ static char buf[32];
+
+ snprintf(buf, sizeof(buf),
+"%c%c%c%c %s-endian (0x%08x)",
+printable_char(format & 0xff),
+printable_char((format >> 8) & 0xff),
+printable_char((format >> 16) & 0xff),
+printable_char((format >> 24) & 0x7f),
+format & DRM_FORMAT_BIG_ENDIAN ? "big" : "little",
+format);
+
+ return buf;
+}
+EXPORT_SYMBOL(drm_get_format_name);
+
/**
* drm_mode_object_get - allocate a new modeset identifier
* @dev: DRM device
@@ -1834,7 +1857,8 @@ int drm_mode_setplane(struct drm_device *dev, void *data,
if (fb->pixel_format == plane->format_types[i])
break;
if (i == plane->format_count) {
- DRM_DEBUG_KMS("Invalid pixel format 0x%08x\n",
fb->pixel_format);
+ DRM_DEBUG_KMS("Invalid pixel format %s\n",
+ drm_get_format_name(fb->pixel_format));
ret = -EINVAL;
goto out;
}
@@ -2312,7 +2336,8 @@ static int framebuffer_check(const struct
drm_mode_fb_cmd2 *r)
ret = format_check(r);
if (ret) {
- DRM_DEBUG_KMS("bad framebuffer format 0x%08x\n",
r->pixel_format);
+ DRM_DEBUG_KMS("bad framebuffer format %s\n",
+ drm_get_format_name(r->pixel_format));
return ret;
}
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index adb3f9b..2cbbfd4 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -1094,5 +1094,6 @@ extern int drm_format_num_planes(uint32_t format);
extern int drm_format_plane_cpp(uint32_t format, int plane);
extern int drm_format_horz_chroma_subsampling(uint32_t format);
extern int drm_format_vert_chroma_subsampling(uint32_t format);
+extern char *drm_get_format_name(uint32_t format);
#endif /* __DRM_CRTC_H__ */
--
1.8.1.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/4] fb: Make fb_get_options() 'name' parameter const
From: Ville Syrjälä
The string isn't modified so make it const.
Cc: Jean-Christophe Plagniol-Villard
Cc: Tomi Valkeinen
Cc: linux-fb...@vger.kernel.org
Signed-off-by: Ville Syrjälä
---
drivers/video/fbmem.c | 2 +-
include/linux/fb.h| 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/video/fbmem.c b/drivers/video/fbmem.c
index 098bfc6..d8d5779 100644
--- a/drivers/video/fbmem.c
+++ b/drivers/video/fbmem.c
@@ -1881,7 +1881,7 @@ static int ofonly __read_mostly;
*
* NOTE: Needed to maintain backwards compatibility
*/
-int fb_get_options(char *name, char **option)
+int fb_get_options(const char *name, char **option)
{
char *opt, *options = NULL;
int retval = 0;
diff --git a/include/linux/fb.h b/include/linux/fb.h
index d49c60f..ffac70a 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -624,7 +624,7 @@ extern void fb_pad_aligned_buffer(u8 *dst, u32 d_pitch, u8
*src, u32 s_pitch, u3
extern void fb_set_suspend(struct fb_info *info, int state);
extern int fb_get_color_depth(struct fb_var_screeninfo *var,
struct fb_fix_screeninfo *fix);
-extern int fb_get_options(char *name, char **option);
+extern int fb_get_options(const char *name, char **option);
extern int fb_new_modelist(struct fb_info *info);
extern struct fb_info *registered_fb[FB_MAX];
--
1.8.1.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/4] drm/i915: Print pretty names for pixel formats
From: Ville Syrjälä
Use drm_get_format_name to print more readable pixel format names
in debug output.
Also unify the debug messages to say "unsupported pixel format",
which better describes what is going on.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 92fd0d4..d4886dc 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -9030,7 +9030,8 @@ int intel_framebuffer_init(struct drm_device *dev,
case DRM_FORMAT_XRGB1555:
case DRM_FORMAT_ARGB1555:
if (INTEL_INFO(dev)->gen > 3) {
- DRM_DEBUG("invalid format: 0x%08x\n",
mode_cmd->pixel_format);
+ DRM_DEBUG("unsupported pixel format: %s\n",
+ drm_get_format_name(mode_cmd->pixel_format));
return -EINVAL;
}
break;
@@ -9041,7 +9042,8 @@ int intel_framebuffer_init(struct drm_device *dev,
case DRM_FORMAT_XBGR2101010:
case DRM_FORMAT_ABGR2101010:
if (INTEL_INFO(dev)->gen < 4) {
- DRM_DEBUG("invalid format: 0x%08x\n",
mode_cmd->pixel_format);
+ DRM_DEBUG("unsupported pixel format: %s\n",
+ drm_get_format_name(mode_cmd->pixel_format));
return -EINVAL;
}
break;
@@ -9050,12 +9052,14 @@ int intel_framebuffer_init(struct drm_device *dev,
case DRM_FORMAT_YVYU:
case DRM_FORMAT_VYUY:
if (INTEL_INFO(dev)->gen < 5) {
- DRM_DEBUG("invalid format: 0x%08x\n",
mode_cmd->pixel_format);
+ DRM_DEBUG("unsupported pixel format: %s\n",
+ drm_get_format_name(mode_cmd->pixel_format));
return -EINVAL;
}
break;
default:
- DRM_DEBUG("unsupported pixel format 0x%08x\n",
mode_cmd->pixel_format);
+ DRM_DEBUG("unsupported pixel format: %s\n",
+ drm_get_format_name(mode_cmd->pixel_format));
return -EINVAL;
}
--
1.8.1.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/4] drm: Constify the pretty-print functions
From: Ville Syrjälä
The structures and strings involved with various pretty-print functions
aren't meant to be modified, so make them all const. The exception is
drm_connector_enum_list which does get modified in drm_connector_init().
While at it move the drm_get_connector_status_name() prototype from
drmP.h to drm_crtc.h where it belongs.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_crtc.c | 30 +++---
include/drm/drmP.h | 1 -
include/drm/drm_crtc.h | 17 +
3 files changed, 24 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 079996a..44c3421 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -92,7 +92,7 @@ EXPORT_SYMBOL(drm_warn_on_modeset_not_all_locked);
/* Avoid boilerplate. I'm tired of typing. */
#define DRM_ENUM_NAME_FN(fnname, list) \
- char *fnname(int val) \
+ const char *fnname(int val) \
{ \
int i; \
for (i = 0; i < ARRAY_SIZE(list); i++) {\
@@ -105,7 +105,7 @@ EXPORT_SYMBOL(drm_warn_on_modeset_not_all_locked);
/*
* Global properties
*/
-static struct drm_prop_enum_list drm_dpms_enum_list[] =
+static const struct drm_prop_enum_list drm_dpms_enum_list[] =
{ { DRM_MODE_DPMS_ON, "On" },
{ DRM_MODE_DPMS_STANDBY, "Standby" },
{ DRM_MODE_DPMS_SUSPEND, "Suspend" },
@@ -117,7 +117,7 @@ DRM_ENUM_NAME_FN(drm_get_dpms_name, drm_dpms_enum_list)
/*
* Optional properties
*/
-static struct drm_prop_enum_list drm_scaling_mode_enum_list[] =
+static const struct drm_prop_enum_list drm_scaling_mode_enum_list[] =
{
{ DRM_MODE_SCALE_NONE, "None" },
{ DRM_MODE_SCALE_FULLSCREEN, "Full" },
@@ -125,7 +125,7 @@ static struct drm_prop_enum_list
drm_scaling_mode_enum_list[] =
{ DRM_MODE_SCALE_ASPECT, "Full aspect" },
};
-static struct drm_prop_enum_list drm_dithering_mode_enum_list[] =
+static const struct drm_prop_enum_list drm_dithering_mode_enum_list[] =
{
{ DRM_MODE_DITHERING_OFF, "Off" },
{ DRM_MODE_DITHERING_ON, "On" },
@@ -135,7 +135,7 @@ static struct drm_prop_enum_list
drm_dithering_mode_enum_list[] =
/*
* Non-global properties, but "required" for certain connectors.
*/
-static struct drm_prop_enum_list drm_dvi_i_select_enum_list[] =
+static const struct drm_prop_enum_list drm_dvi_i_select_enum_list[] =
{
{ DRM_MODE_SUBCONNECTOR_Automatic, "Automatic" }, /* DVI-I and TV-out */
{ DRM_MODE_SUBCONNECTOR_DVID, "DVI-D" }, /* DVI-I */
@@ -144,7 +144,7 @@ static struct drm_prop_enum_list
drm_dvi_i_select_enum_list[] =
DRM_ENUM_NAME_FN(drm_get_dvi_i_select_name, drm_dvi_i_select_enum_list)
-static struct drm_prop_enum_list drm_dvi_i_subconnector_enum_list[] =
+static const struct drm_prop_enum_list drm_dvi_i_subconnector_enum_list[] =
{
{ DRM_MODE_SUBCONNECTOR_Unknown, "Unknown" }, /* DVI-I and TV-out */
{ DRM_MODE_SUBCONNECTOR_DVID, "DVI-D" }, /* DVI-I */
@@ -154,7 +154,7 @@ static struct drm_prop_enum_list
drm_dvi_i_subconnector_enum_list[] =
DRM_ENUM_NAME_FN(drm_get_dvi_i_subconnector_name,
drm_dvi_i_subconnector_enum_list)
-static struct drm_prop_enum_list drm_tv_select_enum_list[] =
+static const struct drm_prop_enum_list drm_tv_select_enum_list[] =
{
{ DRM_MODE_SUBCONNECTOR_Automatic, "Automatic" }, /* DVI-I and TV-out */
{ DRM_MODE_SUBCONNECTOR_Composite, "Composite" }, /* TV-out */
@@ -165,7 +165,7 @@ static struct drm_prop_enum_list drm_tv_select_enum_list[] =
DRM_ENUM_NAME_FN(drm_get_tv_select_name, drm_tv_select_enum_list)
-static struct drm_prop_enum_list drm_tv_subconnector_enum_list[] =
+static const struct drm_prop_enum_list drm_tv_subconnector_enum_list[] =
{
{ DRM_MODE_SUBCONNECTOR_Unknown, "Unknown" }, /* DVI-I and TV-out */
{ DRM_MODE_SUBCONNECTOR_Composite, "Composite" }, /* TV-out */
@@ -177,7 +177,7 @@ static struct drm_prop_enum_list
drm_tv_subconnector_enum_list[] =
DRM_ENUM_NAME_FN(drm_get_tv_subconnector_name,
drm_tv_subconnector_enum_list)
-static struct drm_prop_enum_list drm_dirty_info_enum_list[] = {
+static const struct drm_prop_enum_list drm_dirty_info_enum_list[] = {
{ DRM_MODE_DIRTY_OFF, "Off" },
{ DRM_MODE_DIRTY_ON, "On" },
{ DRM_MODE_DIRTY_ANNOTATE, "Annotate" },
@@ -185,7 +185,7 @@ static struct drm_prop_enum_list drm_dirty_info_enum_list[]
= {
struct drm_conn_prop_enum_list {
int type;
- char *name;
+ const char *name;
int count;
};
@@ -211,7 +211,7 @@ static struct drm_conn_prop_enum_list
drm_connector_enum_list[] =
{ DRM_MODE_CONNECTOR_VIRTUAL, "Virtual", 0},
};
-static st
Re: [Intel-gfx] [PATCH 4/4] drm: Constify the pretty-print functions
On Fri, Jun 07, 2013 at 06:43:07PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> The structures and strings involved with various pretty-print functions
> aren't meant to be modified, so make them all const. The exception is
> drm_connector_enum_list which does get modified in drm_connector_init().
>
> While at it move the drm_get_connector_status_name() prototype from
> drmP.h to drm_crtc.h where it belongs.
>
> Signed-off-by: Ville Syrjälä
Looks good to me, and probably simplest if we merge everything (including
drm/i915 parts) through drm-next. On the series:
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_crtc.c | 30 +++---
> include/drm/drmP.h | 1 -
> include/drm/drm_crtc.h | 17 +
> 3 files changed, 24 insertions(+), 24 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 079996a..44c3421 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -92,7 +92,7 @@ EXPORT_SYMBOL(drm_warn_on_modeset_not_all_locked);
>
> /* Avoid boilerplate. I'm tired of typing. */
> #define DRM_ENUM_NAME_FN(fnname, list) \
> - char *fnname(int val) \
> + const char *fnname(int val) \
> { \
> int i; \
> for (i = 0; i < ARRAY_SIZE(list); i++) {\
> @@ -105,7 +105,7 @@ EXPORT_SYMBOL(drm_warn_on_modeset_not_all_locked);
> /*
> * Global properties
> */
> -static struct drm_prop_enum_list drm_dpms_enum_list[] =
> +static const struct drm_prop_enum_list drm_dpms_enum_list[] =
> {{ DRM_MODE_DPMS_ON, "On" },
> { DRM_MODE_DPMS_STANDBY, "Standby" },
> { DRM_MODE_DPMS_SUSPEND, "Suspend" },
> @@ -117,7 +117,7 @@ DRM_ENUM_NAME_FN(drm_get_dpms_name, drm_dpms_enum_list)
> /*
> * Optional properties
> */
> -static struct drm_prop_enum_list drm_scaling_mode_enum_list[] =
> +static const struct drm_prop_enum_list drm_scaling_mode_enum_list[] =
> {
> { DRM_MODE_SCALE_NONE, "None" },
> { DRM_MODE_SCALE_FULLSCREEN, "Full" },
> @@ -125,7 +125,7 @@ static struct drm_prop_enum_list
> drm_scaling_mode_enum_list[] =
> { DRM_MODE_SCALE_ASPECT, "Full aspect" },
> };
>
> -static struct drm_prop_enum_list drm_dithering_mode_enum_list[] =
> +static const struct drm_prop_enum_list drm_dithering_mode_enum_list[] =
> {
> { DRM_MODE_DITHERING_OFF, "Off" },
> { DRM_MODE_DITHERING_ON, "On" },
> @@ -135,7 +135,7 @@ static struct drm_prop_enum_list
> drm_dithering_mode_enum_list[] =
> /*
> * Non-global properties, but "required" for certain connectors.
> */
> -static struct drm_prop_enum_list drm_dvi_i_select_enum_list[] =
> +static const struct drm_prop_enum_list drm_dvi_i_select_enum_list[] =
> {
> { DRM_MODE_SUBCONNECTOR_Automatic, "Automatic" }, /* DVI-I and TV-out */
> { DRM_MODE_SUBCONNECTOR_DVID, "DVI-D" }, /* DVI-I */
> @@ -144,7 +144,7 @@ static struct drm_prop_enum_list
> drm_dvi_i_select_enum_list[] =
>
> DRM_ENUM_NAME_FN(drm_get_dvi_i_select_name, drm_dvi_i_select_enum_list)
>
> -static struct drm_prop_enum_list drm_dvi_i_subconnector_enum_list[] =
> +static const struct drm_prop_enum_list drm_dvi_i_subconnector_enum_list[] =
> {
> { DRM_MODE_SUBCONNECTOR_Unknown, "Unknown" }, /* DVI-I and TV-out */
> { DRM_MODE_SUBCONNECTOR_DVID, "DVI-D" }, /* DVI-I */
> @@ -154,7 +154,7 @@ static struct drm_prop_enum_list
> drm_dvi_i_subconnector_enum_list[] =
> DRM_ENUM_NAME_FN(drm_get_dvi_i_subconnector_name,
>drm_dvi_i_subconnector_enum_list)
>
> -static struct drm_prop_enum_list drm_tv_select_enum_list[] =
> +static const struct drm_prop_enum_list drm_tv_select_enum_list[] =
> {
> { DRM_MODE_SUBCONNECTOR_Automatic, "Automatic" }, /* DVI-I and TV-out */
> { DRM_MODE_SUBCONNECTOR_Composite, "Composite" }, /* TV-out */
> @@ -165,7 +165,7 @@ static struct drm_prop_enum_list
> drm_tv_select_enum_list[] =
>
> DRM_ENUM_NAME_FN(drm_get_tv_select_name, drm_tv_select_enum_list)
>
> -static struct drm_prop_enum_list drm_tv_subconnector_enum_list[] =
> +static const struct drm_prop_enum_list drm_tv_subconnector_enum_list[] =
> {
> { DRM_MODE_SUBCONNECTOR_Unknown, "Unknown" }, /* DVI-I and TV-out */
> { DRM_MODE_SUBCONNECTOR_Composite, "Composite" }, /* TV-out */
> @@ -177,7 +177,7 @@ static struct drm_prop_enum_list
> drm_tv_subconnector_enum_list[] =
> DRM_ENUM_NAME_FN(drm_get_tv_subconnector_name,
>drm_tv_subconnector_enum_list)
>
> -static struct drm_prop_enum_list drm_dirty_info_enum_list[] = {
> +static const struct drm_prop_enum_list drm_dirty_info_enum_list[] = {
> { DRM_MODE_DIRTY_OFF, "Off" },
> { DRM_MODE_DIRTY_ON, "On" },
> { DRM
[Bug 65514] New: Mesa can't render Google Maps WebGL preview in Firefox
https://bugs.freedesktop.org/show_bug.cgi?id=65514 Priority: medium Bug ID: 65514 Assignee: dri-devel@lists.freedesktop.org Summary: Mesa can't render Google Maps WebGL preview in Firefox Severity: normal Classification: Unclassified OS: All Reporter: nmi...@gmail.com Hardware: Other Status: NEW Version: unspecified Component: Drivers/Gallium/r600 Product: Mesa Both current git Mesa (8bc788ea9e73ef4c355dfea80ac5070c6f81ac1c) and current Fedora Mesa (mesa-libGL-9.2-0.7.20130528.fc18.x86_64) fail to render the preview version of the WebGL based Google Maps correctly in Firefox. The Google Maps preview renders correctly in Chrome using Mesa and in Firefox using Catalyst. The misrendering occurs with both RS880 (Radeon HD 4250) and JUNIPER (Radeon HD 6770) GPUs. After the initial map is rendered (when in Map mode), Firefox fails to update the map in response to user interaction (dragging the map around, searching for locations outside the current map view, zooming, etc.) unless the window is resized. If you switch to Earth mode (which uses aerial photography instead of line drawings), in addition to failures to redraw, forcing redraws using resizing often results in corrupted rendering. xorg-x11-server-Xorg-1.13.3-3.fc18.x86_64 kernel-3.9.4-200.fc18.x86_64 (Sign up for the Google Maps preview at http://maps.google.com/preview ). -- 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 63599] [r600][r600] GPU lockup CP stall (kernel 3.8, 3.9)
https://bugs.freedesktop.org/show_bug.cgi?id=63599 --- Comment #8 from wojtek --- Created attachment 80492 --> https://bugs.freedesktop.org/attachment.cgi?id=80492&action=edit reg_dump_radeon_kernel39 -- 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 63599] [r600][r600] GPU lockup CP stall (kernel 3.8, 3.9)
https://bugs.freedesktop.org/show_bug.cgi?id=63599 --- Comment #9 from wojtek --- Created attachment 80493 --> https://bugs.freedesktop.org/attachment.cgi?id=80493&action=edit reg_dump_fglrx_kernel39 -- 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 65091] power_profile not working for HD5650
https://bugs.freedesktop.org/show_bug.cgi?id=65091 --- Comment #1 from Kamil Bar --- Created attachment 80495 --> https://bugs.freedesktop.org/attachment.cgi?id=80495&action=edit dmesg | grep radeon after drm.debug=2 and some profile switching -- 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 65091] power_profile not working for HD5650
https://bugs.freedesktop.org/show_bug.cgi?id=65091 Kamil Bar changed: What|Removed |Added Version|unspecified |DRI CVS -- 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 65091] power_profile not working for HD5650
https://bugs.freedesktop.org/show_bug.cgi?id=65091 --- Comment #2 from Kamil Bar --- And I need to correct my first post, on auto/low/mid/default profiles voltage is 900 mV, but if I switch to high my screen flick, and it goes to 1000 mv. I cannot attach video bios, because my notebook has vbios built-in into notebook's bios, but if U propose how to get it, I could try ( note: on windows I cannot dump it too) but the notebook bios itself is here: http://h10025.www1.hp.com/ewfrf/wc/softwareDownloadIndex?softwareitem=ob-100446-1&cc=us&destPage=siteHome&dlc=en&lc=en&os=4063&product=4217144&query=dv6-3030ew&tool= -- 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
On Wednesday 05 June 2013 07:00:45 Rob Clark wrote:
> On Wed, Jun 5, 2013 at 4:44 AM, Daniel Vetter wrote:
> > On Tue, Jun 04, 2013 at 11:05:36PM -0400, Rob Clark wrote:
> >> On Tue, Jun 4, 2013 at 9:22 PM, Laurent Pinchart wrote:
> >> > 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);
> >> >> > + }
> >> >> > +
Re: [PATCH 1/4] drm: Print pretty names for pixel formats
On Sat, Jun 8, 2013 at 1:43 AM, wrote: > From: Foo Bar ^ ?? git config error? Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/4] drm: Print pretty names for pixel formats
On Sat, Jun 08, 2013 at 06:09:42AM +1000, Dave Airlie wrote: > On Sat, Jun 8, 2013 at 1:43 AM, wrote: > > From: Foo Bar > > ^ ?? > > git config error? Whoops. Sorry about that. I created the original patch on a test machine where I apparently had been too lazy to set up my git correctly. And then I used suppress-cc=author to avoid spamming myself too much, so I didn't notice it when sending the mail. Do you want a fixed patch, or will you take care of it on your end? -- Ville Syrjälä Intel OTC ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/4] drm: Print pretty names for pixel formats
On Sat, Jun 8, 2013 at 6:35 AM, Ville Syrjälä wrote: > On Sat, Jun 08, 2013 at 06:09:42AM +1000, Dave Airlie wrote: >> On Sat, Jun 8, 2013 at 1:43 AM, wrote: >> > From: Foo Bar >> >> ^ ?? >> >> git config error? > > Whoops. Sorry about that. I created the original patch on a test > machine where I apparently had been too lazy to set up my git > correctly. And then I used suppress-cc=author to avoid spamming > myself too much, so I didn't notice it when sending the mail. > > Do you want a fixed patch, or will you take care of it on your end? can you resend that one, otherwise i'll probably forget when I pick it up :-) Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Multiple issues with omapdrm
On Thu, Jun 6, 2013 at 9:25 PM, Rob Clark wrote:
> On Thu, Jun 6, 2013 at 3:\
Why do you "need" drmOpen("omap")? Is it just a convention to use that
kind of name, instead of "omapdrm" style name?
>>>
>>> all of the /dev/dri/cardN get opened, and then DRM_IOCTL_VERSION ioctl
>>> to get the driver name/version, which is compared against the name
>>> passed in to drmOpen(). So drmOpen("omapdrm") shouldn't really work
>>
>> Ok, so normally nobody will call drmOpen("omapdrm") explicitly, but
>> somebody (X?) will just do what you described to get the modules loaded?
>> If so, I guess it's unlikely that there would be an app with
>> drmOpen("omapdrm").
>>
These days X shouldn't be loading anything, that is DRI1 left overs.
The kernel/udev should be loading all the drivers well before X starts.
Dave.
[PATCH] drm/exynos: fimd: Get signal polarities from device tree
On 06/06/2013 06:47 PM, Tomasz Figa wrote: > Hi Joonyoung, > > On Thursday 06 of June 2013 13:30:49 Joonyoung Shim wrote: >> On 05/19/2013 08:32 PM, Tomasz Figa wrote: >>> Hi, >>> >>> On Wednesday 01 of May 2013 22:00:25 Daniel Vetter wrote: On Wed, May 01, 2013 at 09:06:09PM +0200, Tomasz Figa wrote: > This patch modifies the driver to perform two stage parsing of video > timings from device tree, to get timing information as struct > videomode, which contains more data than struct fb_videomode. > > Thanks to this change, information about polarity of control signals > (VSYNC, HSYNC, VDEN, VCLK) can be retrieved, in addition to standard > video timings. > > Signed-off-by: Tomasz Figa Since the drm mode struct also contains flags for sync polarity ... why is there no direct of -> drm_mode function? Going through an fb videomode in a kms drm driver looks _really_ backwards to me. Cc'in Dave for the fun of it ;-) >>> Struct fb_videomode is what exynos_drm_fimd driver uses internally. >>> Sure it should use drm_mode, but this is not really related to this >>> patch, because the code added in this patch only fills in the pdata >>> struct, which for compatibility reasons (the same structure is used >>> for both fbdev and drm drivers) contains struct fb_videomode. >>> >>> OK, now after having a bit of fun, could we merge this patch to at >>> least have usable support of parallel displays using this driver? >> I think it's better to use struct display_timings instead of struct >> fb_videomode in exynos_drm. > I agree that fb_videomode struct is a bit unfortunate here, but it seems > to be widely used in the exynos_drm_fimd driver. > > Actually, if I understood it properly, the correct struct to use in DRM > drivers is drm_display_mode, but there is no conversion function from > struct display_timing to it. It's easy to convert from struct display_timing to videomode and there is conversion function from struct videomode to drm_display_mode. Already it uses at drivers/gpu/drm/tilcdc/tilcdc_panel.c > > IMHO a separate patch introducing such conversion and then another one > which modifies the driver to use drm_display_mode everywhere would be the > best solution. OK, but the struct drm_display_mode doesn't include only timing information so we need also to use struct videomode or struct drm_timing properly.
[RFC][PATCH 1/2] dma-buf: add importer private data to attachment
Hello Maarten,
On 2013? 06? 05? 22:23, Maarten Lankhorst wrote:
> Op 31-05-13 10:54, Seung-Woo Kim schreef:
>> dma-buf attachment has only exporter private data, but importer private data
>> can be useful for importer especially to re-import the same dma-buf.
>> To use importer private data in attachment of the device, the function to
>> search attachment in the attachment list of dma-buf is also added.
>>
>> Signed-off-by: Seung-Woo Kim
>> ---
>> drivers/base/dma-buf.c | 31 +++
>> include/linux/dma-buf.h |4
>> 2 files changed, 35 insertions(+), 0 deletions(-)
>>
>> diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c
>> index 08fe897..a1eaaf2 100644
>> --- a/drivers/base/dma-buf.c
>> +++ b/drivers/base/dma-buf.c
>> @@ -259,6 +259,37 @@ err_attach:
>> EXPORT_SYMBOL_GPL(dma_buf_attach);
>>
>> /**
>> + * dma_buf_get_attachment - Get attachment with the device from dma_buf's
>> + * attachments list
>> + * @dmabuf: [in]buffer to find device from.
>> + * @dev:[in]device to be found.
>> + *
>> + * Returns struct dma_buf_attachment * attaching the device; may return
>> + * negative error codes.
>> + *
>> + */
>> +struct dma_buf_attachment *dma_buf_get_attachment(struct dma_buf *dmabuf,
>> + struct device *dev)
>> +{
>> +struct dma_buf_attachment *attach;
>> +
>> +if (WARN_ON(!dmabuf || !dev))
>> +return ERR_PTR(-EINVAL);
>> +
>> +mutex_lock(&dmabuf->lock);
>> +list_for_each_entry(attach, &dmabuf->attachments, node) {
>> +if (attach->dev == dev) {
>> +mutex_unlock(&dmabuf->lock);
>> +return attach;
>> +}
>> +}
>> +mutex_unlock(&dmabuf->lock);
>> +
>> +return ERR_PTR(-ENODEV);
>> +}
>> +EXPORT_SYMBOL_GPL(dma_buf_get_attachment);
> NAK in any form..
>
> Spot the race condition between dma_buf_get_attachment and dma_buf_attach
Both dma_buf_get_attachment and dma_buf_attach has mutet with
dmabuf->lock, and dma_buf_get_attachment is used for get attachment from
same device before calling dma_buf_attach.
While, dma_buf_detach can removes attachment because it does not have
ref count. So importer should check ref count in its importer private
data before calling dma_buf_detach if the importer want to use
dma_buf_get_attachment.
And dma_buf_get_attachment is for the importer, so exporter attach and
detach callback operation should not call it as like exporter detach
callback operation should not call dma_buf_attach if you mean this kind
of race.
If you have other considerations here, please describe more specifically.
Thanks and Best Regards,
- Seung-Woo Kim
>
> ~Maarten
>
>
--
Seung-Woo Kim
Samsung Software R&D Center
--
New prototype computer problem with S3 suspend
On 06/07/2013 02:11 AM, Boszormenyi Zoltan wrote: > Hi, > > we are working on an Intel Atom-based embedded PC and I have to > make suspend-to-RAM work but I can't seem to succeed. > > The symptom is that quite often, the machine resumes immediately > after pm-suspend. Sometimes more than 20 times out of 50 attempts. Can you please file a bug about this? https://bugzilla.kernel.org > > I have tried 3.7.10, 3.9.4, 3.10-rc[234] and the linux-next branch from the > git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git repository. > The attached dmesg is from today's linux-pm/linux-next plus the > latest drm-fixes patchset posted by Dave Airlie. > > I have tried disabling wakeup devices via /proc/acpi/wakeup and via sysfs > files. > (/sys/devices/.../wakeup) >From the dmesg, the following three devices are still armed with wakeup capability and might be the cause: i8042 kbd 00:03: System wakeup enabled by ACPI PM: suspend of devices complete after 578.883 msecs PM: late suspend of devices complete after 0.279 msecs pcieport :00:1c.1: System wakeup enabled by ACPI ehci-pci :00:1d.7: System wakeup enabled by ACPI PM: noirq suspend of devices complete after 31.946 msecs Anyway, please file a bug there, thanks. -Aaron
[Bug 65377] Backlight control via /sys/class/backlight/radeon_bl0 not working
https://bugs.freedesktop.org/show_bug.cgi?id=65377 --- Comment #6 from Bastian Triller --- Booting a dd'ed image did not work. I'll have to find a disc to test it. Looking into the xbacklight I saw that xbacklight tries to find a Backlught property on the output. xrandr lists this property on the intel output, but not on the radeon 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/20130607/f4bee827/attachment.html>
[PATCH v3] drm: Renesas R-Car Display Unit DRM driver
On Thursday 06 June 2013 09:21:35 Alex Deucher wrote: > On Thu, Jun 6, 2013 at 9:12 AM, Daniel Vetter wrote: > > On Wed, Jun 5, 2013 at 3:10 PM, Alex Deucher wrote: > >> To me at least, it doesn't make sense that an encoder can clone > >> itself. If an encoder is already in use, trying to clone itself would > >> only lead to confusion and possible bugs (make sure some code path > >> doesn't try and reprogram the encoder again, etc.). > > > > For me the possible_clones mask is just the set of encoders which can > > together share a crtc (presuming that crtc is indeed in all of the > > possible_crtcs mask of each encoder). From that pov it makes imo sense > > that a given encoder itself can always be with itself on the same crtc > > ;-) > > > > Otoh setcrtc doesn't care one bit about encoders (the crtc helpers do > > internally use them, but it's not interface). And the possible_clones > > stuff is by far not enough to describe all hw restrictions. So tbh I > > don't care which way we go (or whether we indeed keep on using this > > much at all). > > Same. I can go either way. So what's the agreement ? :-) -- Regards, Laurent Pinchart
[PATCH v3] drm: Renesas R-Car Display Unit DRM driver
Hi Daniel,
On Wednesday 05 June 2013 10:55:05 Daniel Vetter wrote:
> On Wed, Jun 05, 2013 at 03:51:53AM +0200, Laurent Pinchart wrote:
> > 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]
>
> > > >> > +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 proper detect support for
> > > >> VGA
> > > >
> > > > I would add that but the DDC signals are not connected on the boards I
> > > > have access to :-/
> > > >
> > > >> I'd just kill this and use the connector force support (and manually
> > > >> adding the right resolutions).
> > > >
> > > > Looks like that's a candidate for better documentation... How does
> > > > force support work ?
> > >
> > > Grep for DRM_FORCE_ON, iirc it can be set on the commandline, where you
> > > can also force a specific mode. The best I could find wrt docs is the
> > > kerneldoc for drm_mode_parse_command_line_for_connector. With a bit more
> > > reading it looks like it's intermingled with the fbdev helper code, but
> > > should be fairly easy to extract and used by your driver.
> >
> > It makes sense to force the connector state from command line, but I'm not
> > sure if the same mechanism is the best solution here. As the driver has no
> > way to know the connector state, the best we can do is guess what modes
> > are supported. I can just return 0 in the get_modes handler, but then the
> > core will not call drm_add_modes_noedid(), and modes will need to be
> > added manually.
> >
> > Is your point that for a board on which the VGA connector state can't be
> > detected, the user should always be responsible for adding all the modes
> > supported by the VGA monitor on the command line ?
>
> My point is that we already have both an established code for connected
> outputs without EDID to add fallback modes and means to force connectors to
> certain states. Your code here seems to reinvent that wheel, so I wonder
> what we should/need to improve in the common code to suit your needs.
The currently available code might suit my needs, it might just be that I fail
to see how to use it properly.
Regarding the "code for connected outputs without EDID to add fallback modes"
you're referring to, is that
if (count == 0 && connector->status == connector_status_connected)
count = drm_add_modes_noedid(connector, 1024, 768);
in drm_helper_probe_single_connector_modes() ? That function will only be
called if the connector status is connector_status_connected. There are two
ways to enforce that:
- returning connector_status_connected from the connector detect() operation,
which seems to defeat the purpose of having connector_status_unknown
completely.
- setting connector->force to DRM_FORCE_ON. Are drivers allowed to do so
themselves at initialization time ? Once again that seems to defeat the
purpose of connector_status_unknown.
> A few ideas:
> - Untangling the connector forcing code from the fbdev helper so that you
> can use it.
> - Exposing the connector state forcing through sysfs so that it's
> runtime-adjustable.
My main concern here is that fbcon won't be available if we delay setting
force mode until userspace is ready..
> - Adding fallback modes for connectors in the unknonw state (imo too much
> risk in breaking something else).
Could you please elaborate on what you thing it could break ?
> Thinking about this some more I'd vote for the new sysfs file to expose
> connector forcing at runtime. With that it'd boil down to 1024x756 vs.
> 1280x768 for the default fallback mode. And that could be fixed with the
> EDID quirk support. Although that looks like it would benefit from a
> per-connector sysfs file, too ;-)
--
Regards,
Laurent Pinchart
New prototype computer problem with S3 suspend
2013-06-07 03:17 keltez?ssel, Aaron Lu ?rta: > On 06/07/2013 02:11 AM, Boszormenyi Zoltan wrote: >> Hi, >> >> we are working on an Intel Atom-based embedded PC and I have to >> make suspend-to-RAM work but I can't seem to succeed. >> >> The symptom is that quite often, the machine resumes immediately >> after pm-suspend. Sometimes more than 20 times out of 50 attempts. > Can you please file a bug about this? > https://bugzilla.kernel.org > >> I have tried 3.7.10, 3.9.4, 3.10-rc[234] and the linux-next branch from the >> git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git repository. >> The attached dmesg is from today's linux-pm/linux-next plus the >> latest drm-fixes patchset posted by Dave Airlie. >> >> I have tried disabling wakeup devices via /proc/acpi/wakeup and via sysfs >> files. >> (/sys/devices/.../wakeup) > >From the dmesg, the following three devices are still armed with wakeup > capability and might be the cause: > > i8042 kbd 00:03: System wakeup enabled by ACPI > PM: suspend of devices complete after 578.883 msecs > PM: late suspend of devices complete after 0.279 msecs > pcieport :00:1c.1: System wakeup enabled by ACPI > ehci-pci :00:1d.7: System wakeup enabled by ACPI > PM: noirq suspend of devices complete after 31.946 msecs > > Anyway, please file a bug there, thanks. For the suspend bug: https://bugzilla.kernel.org/show_bug.cgi?id=59401 For the warnings in i915: https://bugs.freedesktop.org/show_bug.cgi?id=65497 Best regards, Zolt?n B?sz?rm?nyi
[PATCH v3] drm: Renesas R-Car Display Unit DRM driver
On Fri, Jun 07, 2013 at 09:44:45AM +0200, Laurent Pinchart wrote:
> Hi Daniel,
>
> On Wednesday 05 June 2013 10:55:05 Daniel Vetter wrote:
> > On Wed, Jun 05, 2013 at 03:51:53AM +0200, Laurent Pinchart wrote:
> > > 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]
> >
> > > > >> > +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 proper detect support for
> > > > >> VGA
> > > > >
> > > > > I would add that but the DDC signals are not connected on the boards I
> > > > > have access to :-/
> > > > >
> > > > >> I'd just kill this and use the connector force support (and manually
> > > > >> adding the right resolutions).
> > > > >
> > > > > Looks like that's a candidate for better documentation... How does
> > > > > force support work ?
> > > >
> > > > Grep for DRM_FORCE_ON, iirc it can be set on the commandline, where you
> > > > can also force a specific mode. The best I could find wrt docs is the
> > > > kerneldoc for drm_mode_parse_command_line_for_connector. With a bit more
> > > > reading it looks like it's intermingled with the fbdev helper code, but
> > > > should be fairly easy to extract and used by your driver.
> > >
> > > It makes sense to force the connector state from command line, but I'm not
> > > sure if the same mechanism is the best solution here. As the driver has no
> > > way to know the connector state, the best we can do is guess what modes
> > > are supported. I can just return 0 in the get_modes handler, but then the
> > > core will not call drm_add_modes_noedid(), and modes will need to be
> > > added manually.
> > >
> > > Is your point that for a board on which the VGA connector state can't be
> > > detected, the user should always be responsible for adding all the modes
> > > supported by the VGA monitor on the command line ?
> >
> > My point is that we already have both an established code for connected
> > outputs without EDID to add fallback modes and means to force connectors to
> > certain states. Your code here seems to reinvent that wheel, so I wonder
> > what we should/need to improve in the common code to suit your needs.
>
> The currently available code might suit my needs, it might just be that I
> fail
> to see how to use it properly.
>
> Regarding the "code for connected outputs without EDID to add fallback modes"
> you're referring to, is that
>
> if (count == 0 && connector->status == connector_status_connected)
> count = drm_add_modes_noedid(connector, 1024, 768);
>
> in drm_helper_probe_single_connector_modes() ? That function will only be
> called if the connector status is connector_status_connected. There are two
> ways to enforce that:
>
> - returning connector_status_connected from the connector detect() operation,
> which seems to defeat the purpose of having connector_status_unknown
> completely.
We might want to add such a default mode also for unknown, I'm not sure.
Userspace policy is to first try to light up any connected outputs, and if
there's none try to light up any unknown outputs. Not sure whether
userspace (i.e. X) will automatically add a default mode. fbcon might also
handle this less gracefully.
Personally I'm ok with extending this to unknown, it shouldn't really
hurt (since we already try really hard not to leak unknown anywhere
visible).
> - setting connector->force to DRM_FORCE_ON. Are drivers allowed to do so
> themselves at initialization time ? Once again that seems to defeat the
> purpose of connector_status_unknown.
Atm you can set that with the kernel video= cmdline option, but only if
fbcon force this to be parsed. I think exposing ->force to userspace
somewhere in sysfs would make lots of sense. Drivers imo shouldn't ever
need to touch this. And there's a callback interface so that drivers can
intercept forced connector state, e.g. when they need to set up some stuff
which they otherwise would only do in their ->detect callback.
> > A few ideas:
> > - Untangling the connector forcing code from the fbdev helper so that you
> > can use it.
> > - Exposing the connector state forcing through sysfs so that it's
> > runtime-adjustable.
>
> My main concern here is that fbcon won't be available if we delay setting
> force mode until userspace is ready..
There's also a kernel option. Since we're talking about a VGA connector I
don't think we could do a hardwired quirk here.
> > - Adding fallback modes for connec
[PATCH v3] drm: Renesas R-Car Display Unit DRM driver
On Fri, Jun 07, 2013 at 09:23:58AM +0200, Laurent Pinchart wrote: > On Thursday 06 June 2013 09:21:35 Alex Deucher wrote: > > On Thu, Jun 6, 2013 at 9:12 AM, Daniel Vetter wrote: > > > On Wed, Jun 5, 2013 at 3:10 PM, Alex Deucher wrote: > > >> To me at least, it doesn't make sense that an encoder can clone > > >> itself. If an encoder is already in use, trying to clone itself would > > >> only lead to confusion and possible bugs (make sure some code path > > >> doesn't try and reprogram the encoder again, etc.). > > > > > > For me the possible_clones mask is just the set of encoders which can > > > together share a crtc (presuming that crtc is indeed in all of the > > > possible_crtcs mask of each encoder). From that pov it makes imo sense > > > that a given encoder itself can always be with itself on the same crtc > > > ;-) > > > > > > Otoh setcrtc doesn't care one bit about encoders (the crtc helpers do > > > internally use them, but it's not interface). And the possible_clones > > > stuff is by far not enough to describe all hw restrictions. So tbh I > > > don't care which way we go (or whether we indeed keep on using this > > > much at all). > > > > Same. I can go either way. > > So what's the agreement ? :-) I think officially "meh". Keep your current code and we'll try to fix this once it blows up somewhere for real ;-) -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
Introduce a dmabuf sync framework for buffer synchronization
Hi all,
Came back :)
Please, ignore previous fence helper. I have re-implemented buffer
synchronization mechanism, dmabuf sync, based on DMA BUF and wound/wait
style lock v5[1] and tested it with 2d gpu and drm kms drivers.
The below is dmabuf sync framework codes,
https://git.kernel.org/cgit/linux/kernel/git/daeinki/drm-exynos.git/commit/?
h=dmabuf-sync&id=ae6c5a0146ab72ea64d9fc91af4595aacf9a5139
And g2d driver with dmabuf sync framework,
https://git.kernel.org/cgit/linux/kernel/git/daeinki/drm-exynos.git/commit/?
h=dmabuf-sync&id=4030bdee9bab5841ad32faade528d04cc0c5fc94
And also exynos drm kms framework,
https://git.kernel.org/cgit/linux/kernel/git/daeinki/drm-exynos.git/commit/?
h=dmabuf-sync&id=6ca548e9ea9e865592719ef6b1cde58366af9f5c
[1] https://patchwork-mail1.kernel.org/patch/2625321/
The purpose of this framework is not only to couple synchronizing caches and
buffer access between CPU and CPU, CPU and DMA, and DMA and DMA but also to
provide easy-to-use interfaces for device drivers: we may need
user interfaces but there is no good way for exposing the interfaces to user
side yet.
Basically, the mechanism of this framework has the following steps,
Initialize dmabuf sync object - A task gets a new sync object allocated and
initialized by dmabuf_sync_init(). This work should be done when a context
or similar thing of device driver is created or before cpu access.
Add a dmabuf to the sync object - A task can add a dmabuf or more that this
task wants to access to its own sync object. This work should be done just
before setting up dma buffer relevant registers or buffer cpu access.
Lock a sync object - A task tries to lock all dmabufs added in the sync
object. And for this, ww-mutexes is used to resolve dead lock. This work
should be done before dma start or cpu access. The lock means DMA or CPU of
current task can access dmabufs so the other cannot access dmabufs.
Unlock a sync object - A task tries to unlock all dmabufs added in the sync
object. This work should be done when after the completion of dma operation
or CPU access. The unlock means DMA or CPU access of current task has been
completed so the other can access the dmabufs.
In addition, this framework includes the following two features,
Consider read and write lock - this feature is for more performance: we
don't need to take a lock in case that a buffer was accessed for read and
current task tries to access the buffer for read. So when current task tries
to take a lock, this feature checks previous access type and desired type to
a given buffer and then decides if it has to take a lock to the buffer or
not.
Consider lockup and resource management - this feature considers the case
that any task never unlocks a buffer after taking a lock to the buffer. In
this case, a timer handler to this task is called sometimes later and then
the buffer is unlocked by workqueue handler to avoid lockup and release the
buffer relevant resources.
Tutorial.
when allocating and initializing device context
struct dmabuf_sync *sync;
sync = dmabuf_sync_init(NULL, NULL);
when setting up dma buffer relevant registers
/* it can be called repeatly for multiple buffers. */
dmabuf_sync_get(sync, dmabuf);
just before dma start or cpu access
dmabuf_sync_lock(sync);
after the completion of dma operation or cpu access
dmabuf_sync_unlock(sync);
dmabuf_sync_put_all(sync);
dmabuf_sync_fini(sync);
Deadlock reproduction with dmabuf sync.
For deadlock test, I had tried to reproduce deadlock situation like below
and the below approach had been worked well,
(Please, presume that two tasks share two dmabufs together.)
[Task A]
struct dmabuf_sync *sync;
sync = dmabuf_sync_init(NULL, NULL);
dmabuf_sync_get(sync, dmabuf A);
dmabuf_sync_get(sync, dmabuf B);
while(1) {
dmabuf_sync_lock(sync);
sleep(1);
dmabuf_sync_unlock(sync);
sleep(1);
}
[Task B]
struct dmabuf_sync *sync;
sync = dmabuf_sync_init(NULL, NULL);
dmabuf_sync_get(sync, dmabuf C);
dmabuf_sync_get(sync, dmabuf A);
while(1) {
dmabuf_sync_lock(sync); <-- deadlock
sleep(1);
dmabuf_sync_unlock(sync);
sleep(1);
}
With the above example codes, deadlock occurs when Task B called
dmabuf_sync_lock function: internally, Task B takes a lock to dmabuf C and
then tries to take a lock to dmabuf A. But at this time, ww_mutex_lock()
returns -EDEADLK because ctx->acquired became 1 once taking a lock to dmabuf
C. And then task B unlocks dmabuf C and takes a slowpath lock to dmabuf A.
And then once Task A unlocks dmabuf A, Task B tries to take a lock to dmabuf
C again.
And the below is my concerns and opinions,
A dma buf
[PATCH v3 0/5] GEM CMA DMA-BUF support
Hello, Here's the third version of the GEM CMA DMA-BUF support patches. Changes compared to the previous version are minimal, there will hopefully not be any need for a v4. 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. Rob, could you please ack 5/5 ? Dave, could we then get the patches in v3.11 ? Changes since v2: - Removed #if CONFIG_DMA_SHARED_BUFFER - Picked up Reviewed-by and Acked-by tags from the mailing list Changes since 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 | 404 +++--- 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, 434 insertions(+), 96 deletions(-) -- Regards, Laurent Pinchart
[PATCH v3 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
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 =
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
[PATCH v3 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
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 v3 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
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
[PATCH v3 5/5] drm: GEM CMA: Add DRM PRIME support
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/drm_gem_cma_helper.c | 317 ++-
include/drm/drm_gem_cma_helper.h | 9 +
2 files changed, 323 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..f94fcd7 100644
--- a/drivers/gpu/drm/drm_gem_cma_helper.c
+++ b/drivers/gpu/drm/drm_gem_cma_helper.c
@@ -21,6 +21,7 @@
#include
#include
#include
+#include
#include
#include
@@ -82,6 +83,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 +97,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 +177,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 +319,286 @@ 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
+ */
+
+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 <
[PATCH v3 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
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 65438] GTK apps crash X11 since last update of LLVMM
https://bugs.freedesktop.org/show_bug.cgi?id=65438 --- Comment #3 from Michel D?nzer --- (In reply to comment #2) > so can you provide me some help to do what you ask in gentoo? I'm not familiar with Gentoo, but I'm sure there are many tutorials on Git bisect on the 'net, there might even be one specific to Gentoo. > or howto debug the gpu properly? since gdb/valgrind/etc dont do anything > against llvm[i guess is cuz is getting loaded by mesa and the output goes to > the gpu] It should work just like for any other X server crash, see http://wiki.x.org/wiki/Development/Documentation/ServerDebugging . -- 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/20130607/99ceb9c8/attachment.html>
[RFC][PATCH 1/2] dma-buf: add importer private data to attachment
Op 07-06-13 04:32, ??? schreef:
> Hello Maarten,
>
> On 2013? 06? 05? 22:23, Maarten Lankhorst wrote:
>> Op 31-05-13 10:54, Seung-Woo Kim schreef:
>>> dma-buf attachment has only exporter private data, but importer private data
>>> can be useful for importer especially to re-import the same dma-buf.
>>> To use importer private data in attachment of the device, the function to
>>> search attachment in the attachment list of dma-buf is also added.
>>>
>>> Signed-off-by: Seung-Woo Kim
>>> ---
>>> drivers/base/dma-buf.c | 31 +++
>>> include/linux/dma-buf.h |4
>>> 2 files changed, 35 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c
>>> index 08fe897..a1eaaf2 100644
>>> --- a/drivers/base/dma-buf.c
>>> +++ b/drivers/base/dma-buf.c
>>> @@ -259,6 +259,37 @@ err_attach:
>>> EXPORT_SYMBOL_GPL(dma_buf_attach);
>>>
>>> /**
>>> + * dma_buf_get_attachment - Get attachment with the device from dma_buf's
>>> + * attachments list
>>> + * @dmabuf:[in]buffer to find device from.
>>> + * @dev: [in]device to be found.
>>> + *
>>> + * Returns struct dma_buf_attachment * attaching the device; may return
>>> + * negative error codes.
>>> + *
>>> + */
>>> +struct dma_buf_attachment *dma_buf_get_attachment(struct dma_buf *dmabuf,
>>> + struct device *dev)
>>> +{
>>> + struct dma_buf_attachment *attach;
>>> +
>>> + if (WARN_ON(!dmabuf || !dev))
>>> + return ERR_PTR(-EINVAL);
>>> +
>>> + mutex_lock(&dmabuf->lock);
>>> + list_for_each_entry(attach, &dmabuf->attachments, node) {
>>> + if (attach->dev == dev) {
>>> + mutex_unlock(&dmabuf->lock);
>>> + return attach;
>>> + }
>>> + }
>>> + mutex_unlock(&dmabuf->lock);
>>> +
>>> + return ERR_PTR(-ENODEV);
>>> +}
>>> +EXPORT_SYMBOL_GPL(dma_buf_get_attachment);
>> NAK in any form..
>>
>> Spot the race condition between dma_buf_get_attachment and dma_buf_attach
> Both dma_buf_get_attachment and dma_buf_attach has mutet with
> dmabuf->lock, and dma_buf_get_attachment is used for get attachment from
> same device before calling dma_buf_attach.
hint: what happens if 2 threads do this:
if (IS_ERR(attach = dma_buf_get_attachment(buf, dev)))
attach = dma_buf_attach(buf, dev);
There really is no correct usecase for this kind of thing, so please don't do
it.
> While, dma_buf_detach can removes attachment because it does not have
> ref count. So importer should check ref count in its importer private
> data before calling dma_buf_detach if the importer want to use
> dma_buf_get_attachment.
>
> And dma_buf_get_attachment is for the importer, so exporter attach and
> detach callback operation should not call it as like exporter detach
> callback operation should not call dma_buf_attach if you mean this kind
> of race.
>
> If you have other considerations here, please describe more specifically.
>
> Thanks and Best Regards,
> - Seung-Woo Kim
>
>> ~Maarten
>>
>>
[PATCH v3 5/5] drm: GEM CMA: Add DRM PRIME support
On Fri, Jun 7, 2013 at 5:44 AM, Laurent Pinchart
wrote:
> Signed-off-by: Laurent Pinchart
Reviewed-by: Rob Clark
> ---
> drivers/gpu/drm/drm_gem_cma_helper.c | 317
> ++-
> include/drm/drm_gem_cma_helper.h | 9 +
> 2 files changed, 323 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..f94fcd7 100644
> --- a/drivers/gpu/drm/drm_gem_cma_helper.c
> +++ b/drivers/gpu/drm/drm_gem_cma_helper.c
> @@ -21,6 +21,7 @@
> #include
> #include
> #include
> +#include
> #include
>
> #include
> @@ -82,6 +83,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 +97,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 +177,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 +319,286 @@ 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
> + */
> +
> +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))
> +
[PATCH] drm/radeon: fix write back suspend regression with uvd
On Thu, Jun 6, 2013 at 5:55 PM, wrote:
> From: Jerome Glisse
>
> UVD ring can't use scratch thus it does need writeback buffer to keep
> a valid address or radeon_ring_backup will trigger a kernel fault.
>
> It's ok to not unpin the write back buffer on suspend as it leave in
> gtt and thus does not need eviction.
>
> Reported and tracked by Wojtek
>
> Signed-off-by: Jerome Glisse
Applied. thanks!
Alex
> ---
> drivers/gpu/drm/radeon/radeon_device.c | 15 +--
> 1 file changed, 5 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_device.c
> b/drivers/gpu/drm/radeon/radeon_device.c
> index 1899738..eb8068a 100644
> --- a/drivers/gpu/drm/radeon/radeon_device.c
> +++ b/drivers/gpu/drm/radeon/radeon_device.c
> @@ -244,16 +244,6 @@ void radeon_scratch_free(struct radeon_device *rdev,
> uint32_t reg)
> */
> void radeon_wb_disable(struct radeon_device *rdev)
> {
> - int r;
> -
> - if (rdev->wb.wb_obj) {
> - r = radeon_bo_reserve(rdev->wb.wb_obj, false);
> - if (unlikely(r != 0))
> - return;
> - radeon_bo_kunmap(rdev->wb.wb_obj);
> - radeon_bo_unpin(rdev->wb.wb_obj);
> - radeon_bo_unreserve(rdev->wb.wb_obj);
> - }
> rdev->wb.enabled = false;
> }
>
> @@ -269,6 +259,11 @@ void radeon_wb_fini(struct radeon_device *rdev)
> {
> radeon_wb_disable(rdev);
> if (rdev->wb.wb_obj) {
> + if (!radeon_bo_reserve(rdev->wb.wb_obj, false)) {
> + radeon_bo_kunmap(rdev->wb.wb_obj);
> + radeon_bo_unpin(rdev->wb.wb_obj);
> + radeon_bo_unreserve(rdev->wb.wb_obj);
> + }
> radeon_bo_unref(&rdev->wb.wb_obj);
> rdev->wb.wb = NULL;
> rdev->wb.wb_obj = NULL;
> --
> 1.7.11.7
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/radeon: fix AVI infoframe generation
From: Alex Deucher - remove adding 2 to checksum, this breaks certain monitors - properly emit the AVI infoframe version, not emitting the version breaks some monitors. This should fix blank screen when HDMI audio is enabled on certain monitors. Signed-off-by: Alex Deucher Cc: Rafa? Mi?ecki --- drivers/gpu/drm/radeon/evergreen_hdmi.c | 11 ++- drivers/gpu/drm/radeon/r600_hdmi.c | 11 ++- 2 files changed, 4 insertions(+), 18 deletions(-) diff --git a/drivers/gpu/drm/radeon/evergreen_hdmi.c b/drivers/gpu/drm/radeon/evergreen_hdmi.c index ed7c8a7..b9c6f76 100644 --- a/drivers/gpu/drm/radeon/evergreen_hdmi.c +++ b/drivers/gpu/drm/radeon/evergreen_hdmi.c @@ -128,14 +128,7 @@ static void evergreen_hdmi_update_avi_infoframe(struct drm_encoder *encoder, struct radeon_encoder_atom_dig *dig = radeon_encoder->enc_priv; uint32_t offset = dig->afmt->offset; uint8_t *frame = buffer + 3; - - /* Our header values (type, version, length) should be alright, Intel -* is using the same. Checksum function also seems to be OK, it works -* fine for audio infoframe. However calculated value is always lower -* by 2 in comparison to fglrx. It breaks displaying anything in case -* of TVs that strictly check the checksum. Hack it manually here to -* workaround this issue. */ - frame[0x0] += 2; + uint8_t *header = buffer; WREG32(AFMT_AVI_INFO0 + offset, frame[0x0] | (frame[0x1] << 8) | (frame[0x2] << 16) | (frame[0x3] << 24)); @@ -144,7 +137,7 @@ static void evergreen_hdmi_update_avi_infoframe(struct drm_encoder *encoder, WREG32(AFMT_AVI_INFO2 + offset, frame[0x8] | (frame[0x9] << 8) | (frame[0xA] << 16) | (frame[0xB] << 24)); WREG32(AFMT_AVI_INFO3 + offset, - frame[0xC] | (frame[0xD] << 8)); + frame[0xC] | (frame[0xD] << 8) | (header[1] << 24)); } static void evergreen_audio_set_dto(struct drm_encoder *encoder, u32 clock) diff --git a/drivers/gpu/drm/radeon/r600_hdmi.c b/drivers/gpu/drm/radeon/r600_hdmi.c index 456750a..e73b2a7 100644 --- a/drivers/gpu/drm/radeon/r600_hdmi.c +++ b/drivers/gpu/drm/radeon/r600_hdmi.c @@ -133,14 +133,7 @@ static void r600_hdmi_update_avi_infoframe(struct drm_encoder *encoder, struct radeon_encoder_atom_dig *dig = radeon_encoder->enc_priv; uint32_t offset = dig->afmt->offset; uint8_t *frame = buffer + 3; - - /* Our header values (type, version, length) should be alright, Intel -* is using the same. Checksum function also seems to be OK, it works -* fine for audio infoframe. However calculated value is always lower -* by 2 in comparison to fglrx. It breaks displaying anything in case -* of TVs that strictly check the checksum. Hack it manually here to -* workaround this issue. */ - frame[0x0] += 2; + uint8_t *header = buffer; WREG32(HDMI0_AVI_INFO0 + offset, frame[0x0] | (frame[0x1] << 8) | (frame[0x2] << 16) | (frame[0x3] << 24)); @@ -149,7 +142,7 @@ static void r600_hdmi_update_avi_infoframe(struct drm_encoder *encoder, WREG32(HDMI0_AVI_INFO2 + offset, frame[0x8] | (frame[0x9] << 8) | (frame[0xA] << 16) | (frame[0xB] << 24)); WREG32(HDMI0_AVI_INFO3 + offset, - frame[0xC] | (frame[0xD] << 8)); + frame[0xC] | (frame[0xD] << 8) | (header[1] << 24)); } /* -- 1.7.7.5
[PATCH 1/4] drm: Print pretty names for pixel formats
From: Foo Bar
Rather than just printing the pixel format as a hex number, decode the
fourcc into human readable form, and also decode the LE vs. BE flag.
Keep printing the raw hex number too in case it contains non-printable
characters.
Some examples what the new drm_get_format_name() produces:
DRM_FORMAT_XRGB: "XR24 little-endian (0x34325258)"
DRM_FORMAT_YUYV: "YUYV little-endian (0x56595559)"
DRM_FORMAT_RGB565|DRM_FORMAT_BIG_ENDIAN: "RG16 big-endian (0xb6314752)"
Unprintable characters: "D??? big-endian (0xff7f0244)"
Signed-off-by: Ville Syrj?l?
---
drivers/gpu/drm/drm_crtc.c | 29 +++--
include/drm/drm_crtc.h | 1 +
2 files changed, 28 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index e7e9242..079996a 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -29,6 +29,7 @@
* Dave Airlie
* Jesse Barnes
*/
+#include
#include
#include
#include
@@ -252,6 +253,28 @@ char *drm_get_connector_status_name(enum
drm_connector_status status)
}
EXPORT_SYMBOL(drm_get_connector_status_name);
+static char printable_char(int c)
+{
+ return isascii(c) && isprint(c) ? c : '?';
+}
+
+char *drm_get_format_name(uint32_t format)
+{
+ static char buf[32];
+
+ snprintf(buf, sizeof(buf),
+"%c%c%c%c %s-endian (0x%08x)",
+printable_char(format & 0xff),
+printable_char((format >> 8) & 0xff),
+printable_char((format >> 16) & 0xff),
+printable_char((format >> 24) & 0x7f),
+format & DRM_FORMAT_BIG_ENDIAN ? "big" : "little",
+format);
+
+ return buf;
+}
+EXPORT_SYMBOL(drm_get_format_name);
+
/**
* drm_mode_object_get - allocate a new modeset identifier
* @dev: DRM device
@@ -1834,7 +1857,8 @@ int drm_mode_setplane(struct drm_device *dev, void *data,
if (fb->pixel_format == plane->format_types[i])
break;
if (i == plane->format_count) {
- DRM_DEBUG_KMS("Invalid pixel format 0x%08x\n",
fb->pixel_format);
+ DRM_DEBUG_KMS("Invalid pixel format %s\n",
+ drm_get_format_name(fb->pixel_format));
ret = -EINVAL;
goto out;
}
@@ -2312,7 +2336,8 @@ static int framebuffer_check(const struct
drm_mode_fb_cmd2 *r)
ret = format_check(r);
if (ret) {
- DRM_DEBUG_KMS("bad framebuffer format 0x%08x\n",
r->pixel_format);
+ DRM_DEBUG_KMS("bad framebuffer format %s\n",
+ drm_get_format_name(r->pixel_format));
return ret;
}
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index adb3f9b..2cbbfd4 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -1094,5 +1094,6 @@ extern int drm_format_num_planes(uint32_t format);
extern int drm_format_plane_cpp(uint32_t format, int plane);
extern int drm_format_horz_chroma_subsampling(uint32_t format);
extern int drm_format_vert_chroma_subsampling(uint32_t format);
+extern char *drm_get_format_name(uint32_t format);
#endif /* __DRM_CRTC_H__ */
--
1.8.1.5
[PATCH 3/4] fb: Make fb_get_options() 'name' parameter const
From: Ville Syrj?l?
The string isn't modified so make it const.
Cc: Jean-Christophe Plagniol-Villard
Cc: Tomi Valkeinen
Cc: linux-fbdev at vger.kernel.org
Signed-off-by: Ville Syrj?l?
---
drivers/video/fbmem.c | 2 +-
include/linux/fb.h| 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/video/fbmem.c b/drivers/video/fbmem.c
index 098bfc6..d8d5779 100644
--- a/drivers/video/fbmem.c
+++ b/drivers/video/fbmem.c
@@ -1881,7 +1881,7 @@ static int ofonly __read_mostly;
*
* NOTE: Needed to maintain backwards compatibility
*/
-int fb_get_options(char *name, char **option)
+int fb_get_options(const char *name, char **option)
{
char *opt, *options = NULL;
int retval = 0;
diff --git a/include/linux/fb.h b/include/linux/fb.h
index d49c60f..ffac70a 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -624,7 +624,7 @@ extern void fb_pad_aligned_buffer(u8 *dst, u32 d_pitch, u8
*src, u32 s_pitch, u3
extern void fb_set_suspend(struct fb_info *info, int state);
extern int fb_get_color_depth(struct fb_var_screeninfo *var,
struct fb_fix_screeninfo *fix);
-extern int fb_get_options(char *name, char **option);
+extern int fb_get_options(const char *name, char **option);
extern int fb_new_modelist(struct fb_info *info);
extern struct fb_info *registered_fb[FB_MAX];
--
1.8.1.5
[PATCH 2/4] drm/i915: Print pretty names for pixel formats
From: Ville Syrj?l?
Use drm_get_format_name to print more readable pixel format names
in debug output.
Also unify the debug messages to say "unsupported pixel format",
which better describes what is going on.
Signed-off-by: Ville Syrj?l?
---
drivers/gpu/drm/i915/intel_display.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 92fd0d4..d4886dc 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -9030,7 +9030,8 @@ int intel_framebuffer_init(struct drm_device *dev,
case DRM_FORMAT_XRGB1555:
case DRM_FORMAT_ARGB1555:
if (INTEL_INFO(dev)->gen > 3) {
- DRM_DEBUG("invalid format: 0x%08x\n",
mode_cmd->pixel_format);
+ DRM_DEBUG("unsupported pixel format: %s\n",
+ drm_get_format_name(mode_cmd->pixel_format));
return -EINVAL;
}
break;
@@ -9041,7 +9042,8 @@ int intel_framebuffer_init(struct drm_device *dev,
case DRM_FORMAT_XBGR2101010:
case DRM_FORMAT_ABGR2101010:
if (INTEL_INFO(dev)->gen < 4) {
- DRM_DEBUG("invalid format: 0x%08x\n",
mode_cmd->pixel_format);
+ DRM_DEBUG("unsupported pixel format: %s\n",
+ drm_get_format_name(mode_cmd->pixel_format));
return -EINVAL;
}
break;
@@ -9050,12 +9052,14 @@ int intel_framebuffer_init(struct drm_device *dev,
case DRM_FORMAT_YVYU:
case DRM_FORMAT_VYUY:
if (INTEL_INFO(dev)->gen < 5) {
- DRM_DEBUG("invalid format: 0x%08x\n",
mode_cmd->pixel_format);
+ DRM_DEBUG("unsupported pixel format: %s\n",
+ drm_get_format_name(mode_cmd->pixel_format));
return -EINVAL;
}
break;
default:
- DRM_DEBUG("unsupported pixel format 0x%08x\n",
mode_cmd->pixel_format);
+ DRM_DEBUG("unsupported pixel format: %s\n",
+ drm_get_format_name(mode_cmd->pixel_format));
return -EINVAL;
}
--
1.8.1.5
[PATCH 4/4] drm: Constify the pretty-print functions
From: Ville Syrj?l?
The structures and strings involved with various pretty-print functions
aren't meant to be modified, so make them all const. The exception is
drm_connector_enum_list which does get modified in drm_connector_init().
While at it move the drm_get_connector_status_name() prototype from
drmP.h to drm_crtc.h where it belongs.
Signed-off-by: Ville Syrj?l?
---
drivers/gpu/drm/drm_crtc.c | 30 +++---
include/drm/drmP.h | 1 -
include/drm/drm_crtc.h | 17 +
3 files changed, 24 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 079996a..44c3421 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -92,7 +92,7 @@ EXPORT_SYMBOL(drm_warn_on_modeset_not_all_locked);
/* Avoid boilerplate. I'm tired of typing. */
#define DRM_ENUM_NAME_FN(fnname, list) \
- char *fnname(int val) \
+ const char *fnname(int val) \
{ \
int i; \
for (i = 0; i < ARRAY_SIZE(list); i++) {\
@@ -105,7 +105,7 @@ EXPORT_SYMBOL(drm_warn_on_modeset_not_all_locked);
/*
* Global properties
*/
-static struct drm_prop_enum_list drm_dpms_enum_list[] =
+static const struct drm_prop_enum_list drm_dpms_enum_list[] =
{ { DRM_MODE_DPMS_ON, "On" },
{ DRM_MODE_DPMS_STANDBY, "Standby" },
{ DRM_MODE_DPMS_SUSPEND, "Suspend" },
@@ -117,7 +117,7 @@ DRM_ENUM_NAME_FN(drm_get_dpms_name, drm_dpms_enum_list)
/*
* Optional properties
*/
-static struct drm_prop_enum_list drm_scaling_mode_enum_list[] =
+static const struct drm_prop_enum_list drm_scaling_mode_enum_list[] =
{
{ DRM_MODE_SCALE_NONE, "None" },
{ DRM_MODE_SCALE_FULLSCREEN, "Full" },
@@ -125,7 +125,7 @@ static struct drm_prop_enum_list
drm_scaling_mode_enum_list[] =
{ DRM_MODE_SCALE_ASPECT, "Full aspect" },
};
-static struct drm_prop_enum_list drm_dithering_mode_enum_list[] =
+static const struct drm_prop_enum_list drm_dithering_mode_enum_list[] =
{
{ DRM_MODE_DITHERING_OFF, "Off" },
{ DRM_MODE_DITHERING_ON, "On" },
@@ -135,7 +135,7 @@ static struct drm_prop_enum_list
drm_dithering_mode_enum_list[] =
/*
* Non-global properties, but "required" for certain connectors.
*/
-static struct drm_prop_enum_list drm_dvi_i_select_enum_list[] =
+static const struct drm_prop_enum_list drm_dvi_i_select_enum_list[] =
{
{ DRM_MODE_SUBCONNECTOR_Automatic, "Automatic" }, /* DVI-I and TV-out */
{ DRM_MODE_SUBCONNECTOR_DVID, "DVI-D" }, /* DVI-I */
@@ -144,7 +144,7 @@ static struct drm_prop_enum_list
drm_dvi_i_select_enum_list[] =
DRM_ENUM_NAME_FN(drm_get_dvi_i_select_name, drm_dvi_i_select_enum_list)
-static struct drm_prop_enum_list drm_dvi_i_subconnector_enum_list[] =
+static const struct drm_prop_enum_list drm_dvi_i_subconnector_enum_list[] =
{
{ DRM_MODE_SUBCONNECTOR_Unknown, "Unknown" }, /* DVI-I and TV-out */
{ DRM_MODE_SUBCONNECTOR_DVID, "DVI-D" }, /* DVI-I */
@@ -154,7 +154,7 @@ static struct drm_prop_enum_list
drm_dvi_i_subconnector_enum_list[] =
DRM_ENUM_NAME_FN(drm_get_dvi_i_subconnector_name,
drm_dvi_i_subconnector_enum_list)
-static struct drm_prop_enum_list drm_tv_select_enum_list[] =
+static const struct drm_prop_enum_list drm_tv_select_enum_list[] =
{
{ DRM_MODE_SUBCONNECTOR_Automatic, "Automatic" }, /* DVI-I and TV-out */
{ DRM_MODE_SUBCONNECTOR_Composite, "Composite" }, /* TV-out */
@@ -165,7 +165,7 @@ static struct drm_prop_enum_list drm_tv_select_enum_list[] =
DRM_ENUM_NAME_FN(drm_get_tv_select_name, drm_tv_select_enum_list)
-static struct drm_prop_enum_list drm_tv_subconnector_enum_list[] =
+static const struct drm_prop_enum_list drm_tv_subconnector_enum_list[] =
{
{ DRM_MODE_SUBCONNECTOR_Unknown, "Unknown" }, /* DVI-I and TV-out */
{ DRM_MODE_SUBCONNECTOR_Composite, "Composite" }, /* TV-out */
@@ -177,7 +177,7 @@ static struct drm_prop_enum_list
drm_tv_subconnector_enum_list[] =
DRM_ENUM_NAME_FN(drm_get_tv_subconnector_name,
drm_tv_subconnector_enum_list)
-static struct drm_prop_enum_list drm_dirty_info_enum_list[] = {
+static const struct drm_prop_enum_list drm_dirty_info_enum_list[] = {
{ DRM_MODE_DIRTY_OFF, "Off" },
{ DRM_MODE_DIRTY_ON, "On" },
{ DRM_MODE_DIRTY_ANNOTATE, "Annotate" },
@@ -185,7 +185,7 @@ static struct drm_prop_enum_list drm_dirty_info_enum_list[]
= {
struct drm_conn_prop_enum_list {
int type;
- char *name;
+ const char *name;
int count;
};
@@ -211,7 +211,7 @@ static struct drm_conn_prop_enum_list
drm_connector_enum_list[] =
{ DRM_MODE_CONNECTOR_VIRTUAL, "Virtual", 0},
};
-static struct drm_pr
[Intel-gfx] [PATCH 4/4] drm: Constify the pretty-print functions
On Fri, Jun 07, 2013 at 06:43:07PM +0300, ville.syrjala at linux.intel.com
wrote:
> From: Ville Syrj?l?
>
> The structures and strings involved with various pretty-print functions
> aren't meant to be modified, so make them all const. The exception is
> drm_connector_enum_list which does get modified in drm_connector_init().
>
> While at it move the drm_get_connector_status_name() prototype from
> drmP.h to drm_crtc.h where it belongs.
>
> Signed-off-by: Ville Syrj?l?
Looks good to me, and probably simplest if we merge everything (including
drm/i915 parts) through drm-next. On the series:
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_crtc.c | 30 +++---
> include/drm/drmP.h | 1 -
> include/drm/drm_crtc.h | 17 +
> 3 files changed, 24 insertions(+), 24 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 079996a..44c3421 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -92,7 +92,7 @@ EXPORT_SYMBOL(drm_warn_on_modeset_not_all_locked);
>
> /* Avoid boilerplate. I'm tired of typing. */
> #define DRM_ENUM_NAME_FN(fnname, list) \
> - char *fnname(int val) \
> + const char *fnname(int val) \
> { \
> int i; \
> for (i = 0; i < ARRAY_SIZE(list); i++) {\
> @@ -105,7 +105,7 @@ EXPORT_SYMBOL(drm_warn_on_modeset_not_all_locked);
> /*
> * Global properties
> */
> -static struct drm_prop_enum_list drm_dpms_enum_list[] =
> +static const struct drm_prop_enum_list drm_dpms_enum_list[] =
> {{ DRM_MODE_DPMS_ON, "On" },
> { DRM_MODE_DPMS_STANDBY, "Standby" },
> { DRM_MODE_DPMS_SUSPEND, "Suspend" },
> @@ -117,7 +117,7 @@ DRM_ENUM_NAME_FN(drm_get_dpms_name, drm_dpms_enum_list)
> /*
> * Optional properties
> */
> -static struct drm_prop_enum_list drm_scaling_mode_enum_list[] =
> +static const struct drm_prop_enum_list drm_scaling_mode_enum_list[] =
> {
> { DRM_MODE_SCALE_NONE, "None" },
> { DRM_MODE_SCALE_FULLSCREEN, "Full" },
> @@ -125,7 +125,7 @@ static struct drm_prop_enum_list
> drm_scaling_mode_enum_list[] =
> { DRM_MODE_SCALE_ASPECT, "Full aspect" },
> };
>
> -static struct drm_prop_enum_list drm_dithering_mode_enum_list[] =
> +static const struct drm_prop_enum_list drm_dithering_mode_enum_list[] =
> {
> { DRM_MODE_DITHERING_OFF, "Off" },
> { DRM_MODE_DITHERING_ON, "On" },
> @@ -135,7 +135,7 @@ static struct drm_prop_enum_list
> drm_dithering_mode_enum_list[] =
> /*
> * Non-global properties, but "required" for certain connectors.
> */
> -static struct drm_prop_enum_list drm_dvi_i_select_enum_list[] =
> +static const struct drm_prop_enum_list drm_dvi_i_select_enum_list[] =
> {
> { DRM_MODE_SUBCONNECTOR_Automatic, "Automatic" }, /* DVI-I and TV-out */
> { DRM_MODE_SUBCONNECTOR_DVID, "DVI-D" }, /* DVI-I */
> @@ -144,7 +144,7 @@ static struct drm_prop_enum_list
> drm_dvi_i_select_enum_list[] =
>
> DRM_ENUM_NAME_FN(drm_get_dvi_i_select_name, drm_dvi_i_select_enum_list)
>
> -static struct drm_prop_enum_list drm_dvi_i_subconnector_enum_list[] =
> +static const struct drm_prop_enum_list drm_dvi_i_subconnector_enum_list[] =
> {
> { DRM_MODE_SUBCONNECTOR_Unknown, "Unknown" }, /* DVI-I and TV-out */
> { DRM_MODE_SUBCONNECTOR_DVID, "DVI-D" }, /* DVI-I */
> @@ -154,7 +154,7 @@ static struct drm_prop_enum_list
> drm_dvi_i_subconnector_enum_list[] =
> DRM_ENUM_NAME_FN(drm_get_dvi_i_subconnector_name,
>drm_dvi_i_subconnector_enum_list)
>
> -static struct drm_prop_enum_list drm_tv_select_enum_list[] =
> +static const struct drm_prop_enum_list drm_tv_select_enum_list[] =
> {
> { DRM_MODE_SUBCONNECTOR_Automatic, "Automatic" }, /* DVI-I and TV-out */
> { DRM_MODE_SUBCONNECTOR_Composite, "Composite" }, /* TV-out */
> @@ -165,7 +165,7 @@ static struct drm_prop_enum_list
> drm_tv_select_enum_list[] =
>
> DRM_ENUM_NAME_FN(drm_get_tv_select_name, drm_tv_select_enum_list)
>
> -static struct drm_prop_enum_list drm_tv_subconnector_enum_list[] =
> +static const struct drm_prop_enum_list drm_tv_subconnector_enum_list[] =
> {
> { DRM_MODE_SUBCONNECTOR_Unknown, "Unknown" }, /* DVI-I and TV-out */
> { DRM_MODE_SUBCONNECTOR_Composite, "Composite" }, /* TV-out */
> @@ -177,7 +177,7 @@ static struct drm_prop_enum_list
> drm_tv_subconnector_enum_list[] =
> DRM_ENUM_NAME_FN(drm_get_tv_subconnector_name,
>drm_tv_subconnector_enum_list)
>
> -static struct drm_prop_enum_list drm_dirty_info_enum_list[] = {
> +static const struct drm_prop_enum_list drm_dirty_info_enum_list[] = {
> { DRM_MODE_DIRTY_OFF, "Off" },
> { DRM_MODE_DIRTY_ON, "On" },
> {
[Bug 65514] New: Mesa can't render Google Maps WebGL preview in Firefox
https://bugs.freedesktop.org/show_bug.cgi?id=65514 Priority: medium Bug ID: 65514 Assignee: dri-devel at lists.freedesktop.org Summary: Mesa can't render Google Maps WebGL preview in Firefox Severity: normal Classification: Unclassified OS: All Reporter: nmiell at gmail.com Hardware: Other Status: NEW Version: unspecified Component: Drivers/Gallium/r600 Product: Mesa Both current git Mesa (8bc788ea9e73ef4c355dfea80ac5070c6f81ac1c) and current Fedora Mesa (mesa-libGL-9.2-0.7.20130528.fc18.x86_64) fail to render the preview version of the WebGL based Google Maps correctly in Firefox. The Google Maps preview renders correctly in Chrome using Mesa and in Firefox using Catalyst. The misrendering occurs with both RS880 (Radeon HD 4250) and JUNIPER (Radeon HD 6770) GPUs. After the initial map is rendered (when in Map mode), Firefox fails to update the map in response to user interaction (dragging the map around, searching for locations outside the current map view, zooming, etc.) unless the window is resized. If you switch to Earth mode (which uses aerial photography instead of line drawings), in addition to failures to redraw, forcing redraws using resizing often results in corrupted rendering. xorg-x11-server-Xorg-1.13.3-3.fc18.x86_64 kernel-3.9.4-200.fc18.x86_64 (Sign up for the Google Maps preview at http://maps.google.com/preview ). -- 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/20130607/7e37230e/attachment.html>
[Bug 63599] [r600][r600] GPU lockup CP stall (kernel 3.8, 3.9)
https://bugs.freedesktop.org/show_bug.cgi?id=63599 --- Comment #8 from wojtek --- Created attachment 80492 --> https://bugs.freedesktop.org/attachment.cgi?id=80492&action=edit reg_dump_radeon_kernel39 -- 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/20130607/b1e26a26/attachment.html>
[Bug 63599] [r600][r600] GPU lockup CP stall (kernel 3.8, 3.9)
https://bugs.freedesktop.org/show_bug.cgi?id=63599 --- Comment #9 from wojtek --- Created attachment 80493 --> https://bugs.freedesktop.org/attachment.cgi?id=80493&action=edit reg_dump_fglrx_kernel39 -- 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/20130607/34ecf470/attachment.html>
[Bug 65091] power_profile not working for HD5650
https://bugs.freedesktop.org/show_bug.cgi?id=65091 --- Comment #1 from Kamil Bar --- Created attachment 80495 --> https://bugs.freedesktop.org/attachment.cgi?id=80495&action=edit dmesg | grep radeon after drm.debug=2 and some profile switching -- 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/20130607/048f3464/attachment.html>
[Bug 65091] power_profile not working for HD5650
https://bugs.freedesktop.org/show_bug.cgi?id=65091 Kamil Bar changed: What|Removed |Added Version|unspecified |DRI CVS -- 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/20130607/d507d287/attachment.html>
[Bug 65091] power_profile not working for HD5650
https://bugs.freedesktop.org/show_bug.cgi?id=65091 --- Comment #2 from Kamil Bar --- And I need to correct my first post, on auto/low/mid/default profiles voltage is 900 mV, but if I switch to high my screen flick, and it goes to 1000 mv. I cannot attach video bios, because my notebook has vbios built-in into notebook's bios, but if U propose how to get it, I could try ( note: on windows I cannot dump it too) but the notebook bios itself is here: http://h10025.www1.hp.com/ewfrf/wc/softwareDownloadIndex?softwareitem=ob-100446-1&cc=us&destPage=siteHome&dlc=en&lc=en&os=4063&product=4217144&query=dv6-3030ew&tool= -- 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/20130607/3fd13938/attachment.html>
[PATCH v2 5/5] drm: GEM CMA: Add DRM PRIME support
On Wednesday 05 June 2013 07:00:45 Rob Clark wrote:
> On Wed, Jun 5, 2013 at 4:44 AM, Daniel Vetter wrote:
> > On Tue, Jun 04, 2013 at 11:05:36PM -0400, Rob Clark wrote:
> >> On Tue, Jun 4, 2013 at 9:22 PM, Laurent Pinchart wrote:
> >> > 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);
> >> >> > + }
> >> >> > +
[PATCH 1/4] drm: Print pretty names for pixel formats
On Sat, Jun 08, 2013 at 06:09:42AM +1000, Dave Airlie wrote: > On Sat, Jun 8, 2013 at 1:43 AM, wrote: > > From: Foo Bar > > ^ ?? > > git config error? Whoops. Sorry about that. I created the original patch on a test machine where I apparently had been too lazy to set up my git correctly. And then I used suppress-cc=author to avoid spamming myself too much, so I didn't notice it when sending the mail. Do you want a fixed patch, or will you take care of it on your end? -- Ville Syrj?l? Intel OTC
Quick question about status of bug 36602, "Hierarchical Z support for R600"
I was just clearing out some bookmarks in my browser and noticed that #36602 is still open. Seems like you've had HiZ in r600 for a while, so I was wondering if this bug can be closed? No new posts there since September. DW
