[PATCH] RFC: dma-buf: userspace mmap support

[Rob Clark]

From: Rob Clark 

Enable optional userspace access to dma-buf buffers via mmap() on the
dma-buf file descriptor.  Userspace access to the buffer should be
bracketed with DMA_BUF_IOCTL_{PREPARE,FINISH}_ACCESS ioctl calls to
give the exporting driver a chance to deal with cache synchronization
and such for cached userspace mappings without resorting to page
faulting tricks.  The reasoning behind this is that, while drm
drivers tend to have all the mechanisms in place for dealing with
page faulting tricks, other driver subsystems may not.  And in
addition, while page faulting tricks make userspace simpler, there
are some associated overheads.

In all cases, the mmap() call is allowed to fail, and the associated
dma_buf_ops are optional (mmap() will fail if at least the mmap()
op is not implemented by the exporter, but in either case the
{prepare,finish}_access() ops are optional).

For now the prepare/finish access ioctls are kept simple with no
argument, although there is possibility to add additional ioctls
(or simply change the existing ioctls from _IO() to _IOW()) later
to provide optimization to allow userspace to specify a region of
interest.

For a final patch, dma-buf.h would need to be split into what is
exported to userspace, and what is kernel private, but I wanted to
get feedback on the idea of requiring userspace to bracket access
first (vs. limiting this to coherent mappings or exporters who play
page faltings plus PTE shoot-down games) before I split the header
which would cause conflicts with other pending dma-buf patches.  So
flame-on!
---
 drivers/base/dma-buf.c  |   42 ++
 include/linux/dma-buf.h |   22 ++
 2 files changed, 64 insertions(+), 0 deletions(-)

diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c
index c9a945f..382b78a 100644
--- a/drivers/base/dma-buf.c
+++ b/drivers/base/dma-buf.c
@@ -30,6 +30,46 @@

 static inline int is_dma_buf_file(struct file *);

+static int dma_buf_mmap(struct file *file, struct vm_area_struct *vma)
+{
+   struct dma_buf *dmabuf;
+
+   if (!is_dma_buf_file(file))
+   return -EINVAL;
+
+   dmabuf = file->private_data;
+
+   if (dmabuf->ops->mmap)
+   return dmabuf->ops->mmap(dmabuf, file, vma);
+
+   return -ENODEV;
+}
+
+static long dma_buf_ioctl(struct file *file, unsigned int cmd,
+   unsigned long arg)
+{
+   struct dma_buf *dmabuf;
+
+   if (!is_dma_buf_file(file))
+   return -EINVAL;
+
+   dmabuf = file->private_data;
+
+   switch (_IOC_NR(cmd)) {
+   case _IOC_NR(DMA_BUF_IOCTL_PREPARE_ACCESS):
+   if (dmabuf->ops->prepare_access)
+   return dmabuf->ops->prepare_access(dmabuf);
+   return 0;
+   case _IOC_NR(DMA_BUF_IOCTL_FINISH_ACCESS):
+   if (dmabuf->ops->finish_access)
+   return dmabuf->ops->finish_access(dmabuf);
+   return 0;
+   default:
+   return -EINVAL;
+   }
+}
+
+
 static int dma_buf_release(struct inode *inode, struct file *file)
 {
struct dma_buf *dmabuf;
@@ -45,6 +85,8 @@ static int dma_buf_release(struct inode *inode, struct file 
*file)
 }

 static const struct file_operations dma_buf_fops = {
+   .mmap   = dma_buf_mmap,
+   .unlocked_ioctl = dma_buf_ioctl,
.release= dma_buf_release,
 };

diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
index a885b26..cbdff81 100644
--- a/include/linux/dma-buf.h
+++ b/include/linux/dma-buf.h
@@ -34,6 +34,17 @@
 struct dma_buf;
 struct dma_buf_attachment;

+/* TODO: dma-buf.h should be the userspace visible header, and dma-buf-priv.h 
(?)
+ * the kernel internal header.. for now just stuff these here to avoid 
conflicting
+ * with other patches..
+ *
+ * For now, no arg to keep things simple, but we could consider adding an
+ * optional region of interest later.
+ */
+#define DMA_BUF_IOCTL_PREPARE_ACCESS   _IO('Z', 0)
+#define DMA_BUF_IOCTL_FINISH_ACCESS_IO('Z', 1)
+
+
 /**
  * struct dma_buf_ops - operations possible on struct dma_buf
  * @attach: [optional] allows different devices to 'attach' themselves to the
@@ -49,6 +60,13 @@ struct dma_buf_attachment;
  * @unmap_dma_buf: decreases usecount of buffer, might deallocate scatter
  *pages.
  * @release: release this buffer; to be called after the last dma_buf_put.
+ * @mmap: [optional, allowed to fail] operation called if userspace calls
+ *  mmap() on the dmabuf fd.  Note that userspace should use the
+ *  DMA_BUF_PREPARE_ACCESS / DMA_BUF_FINISH_ACCESS ioctls 
before/after
+ *  sw access to the buffer, to give the exporter an opportunity to
+ *  deal with cache maintenance.
+ * @prepare_access: [optional] handler for PREPARE_ACCESS ioctl.
+ * @finish_access: [optional] handler for FINISH_ACCESS ioctl.
  */
 struct dma_buf_ops {
int 

[V2 PATCH 2/2] drivers-gpu-drm-i915-invert-backlight-brightness

[Keith Packard]

<#part sign=pgpmime>
On Thu, 15 Mar 2012 00:35:46 +0100, Carsten Emde  wrote:

> This patch adds a module parameter to invert the backlight brightness
> value before writing and after reading which makes the affected notebook
> usable again.

You should add a quirk for this and set things up so that your machine
automatically gets the right value; when we find more machines that do
this, we can add them so that more people will get a system that 'just
works'.

-- 
keith.packard at intel.com

[PATCH 2/2] drm/radeon: Restrict offset for legacy display engine.

[Michel Dänzer]

From: Michel D?nzer 

The hardware only takes 27 bits for the offset, so larger offsets are
truncated, and the display shows random bits other than the intended ones.

Signed-off-by: Michel D?nzer 
---
 drivers/gpu/drm/radeon/radeon_display.c |4 +++-
 drivers/gpu/drm/radeon/radeon_fb.c  |5 -
 drivers/gpu/drm/radeon/radeon_legacy_crtc.c |4 +++-
 3 files changed, 10 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_display.c 
b/drivers/gpu/drm/radeon/radeon_display.c
index d3ffc18..63386a4 100644
--- a/drivers/gpu/drm/radeon/radeon_display.c
+++ b/drivers/gpu/drm/radeon/radeon_display.c
@@ -393,7 +393,9 @@ static int radeon_crtc_page_flip(struct drm_crtc *crtc,
DRM_ERROR("failed to reserve new rbo buffer before flip\n");
goto pflip_cleanup;
}
-   r = radeon_bo_pin(rbo, RADEON_GEM_DOMAIN_VRAM, );
+   /* Only 27 bit offset for legacy CRTC */
+   r = radeon_bo_pin_restricted(rbo, RADEON_GEM_DOMAIN_VRAM,
+ASIC_IS_AVIVO(rdev) ? 0 : 1 << 27, );
if (unlikely(r != 0)) {
radeon_bo_unreserve(rbo);
r = -EINVAL;
diff --git a/drivers/gpu/drm/radeon/radeon_fb.c 
b/drivers/gpu/drm/radeon/radeon_fb.c
index cf2bf35..93bf920 100644
--- a/drivers/gpu/drm/radeon/radeon_fb.c
+++ b/drivers/gpu/drm/radeon/radeon_fb.c
@@ -164,7 +164,10 @@ static int radeonfb_create_pinned_object(struct 
radeon_fbdev *rfbdev,
ret = radeon_bo_reserve(rbo, false);
if (unlikely(ret != 0))
goto out_unref;
-   ret = radeon_bo_pin(rbo, RADEON_GEM_DOMAIN_VRAM, NULL);
+   /* Only 27 bit offset for legacy CRTC */
+   ret = radeon_bo_pin_restricted(rbo, RADEON_GEM_DOMAIN_VRAM,
+  ASIC_IS_AVIVO(rdev) ? 0 : 1 << 27,
+  NULL);
if (ret) {
radeon_bo_unreserve(rbo);
goto out_unref;
diff --git a/drivers/gpu/drm/radeon/radeon_legacy_crtc.c 
b/drivers/gpu/drm/radeon/radeon_legacy_crtc.c
index 25a19c4..210317c 100644
--- a/drivers/gpu/drm/radeon/radeon_legacy_crtc.c
+++ b/drivers/gpu/drm/radeon/radeon_legacy_crtc.c
@@ -419,7 +419,9 @@ int radeon_crtc_do_set_base(struct drm_crtc *crtc,
r = radeon_bo_reserve(rbo, false);
if (unlikely(r != 0))
return r;
-   r = radeon_bo_pin(rbo, RADEON_GEM_DOMAIN_VRAM, );
+   /* Only 27 bit offset for legacy CRTC */
+   r = radeon_bo_pin_restricted(rbo, RADEON_GEM_DOMAIN_VRAM, 1 << 27,
+);
if (unlikely(r != 0)) {
radeon_bo_unreserve(rbo);
return -EINVAL;
-- 
1.7.9.1

[PATCH v2 1/2] drm/radeon: Restrict offset for legacy hardware cursor.

[Michel Dänzer]

From: Michel D?nzer 

The hardware only takes 27 bits for the offset, so larger offsets are
truncated, and the hardware cursor shows random bits other than the intended
ones.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=46796

Cc: stable at vger.kernel.org
Signed-off-by: Michel D?nzer 
---

v2: Make sure bo->placement.lpfn isn't larger than the memory size, even if
radeon_bo_pin_restricted were to be called for the GTT domain.

 drivers/gpu/drm/radeon/radeon_cursor.c |   13 +++--
 drivers/gpu/drm/radeon/radeon_object.c |   18 +-
 drivers/gpu/drm/radeon/radeon_object.h |2 ++
 3 files changed, 30 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_cursor.c 
b/drivers/gpu/drm/radeon/radeon_cursor.c
index fde25c0..986d608 100644
--- a/drivers/gpu/drm/radeon/radeon_cursor.c
+++ b/drivers/gpu/drm/radeon/radeon_cursor.c
@@ -151,7 +151,9 @@ int radeon_crtc_cursor_set(struct drm_crtc *crtc,
   uint32_t height)
 {
struct radeon_crtc *radeon_crtc = to_radeon_crtc(crtc);
+   struct radeon_device *rdev = crtc->dev->dev_private;
struct drm_gem_object *obj;
+   struct radeon_bo *robj;
uint64_t gpu_addr;
int ret;

@@ -173,7 +175,15 @@ int radeon_crtc_cursor_set(struct drm_crtc *crtc,
return -ENOENT;
}

-   ret = radeon_gem_object_pin(obj, RADEON_GEM_DOMAIN_VRAM, _addr);
+   robj = gem_to_radeon_bo(obj);
+   ret = radeon_bo_reserve(robj, false);
+   if (unlikely(ret != 0))
+   goto fail;
+   /* Only 27 bit offset for legacy cursor */
+   ret = radeon_bo_pin_restricted(robj, RADEON_GEM_DOMAIN_VRAM,
+  ASIC_IS_AVIVO(rdev) ? 0 : 1 << 27,
+  _addr);
+   radeon_bo_unreserve(robj);
if (ret)
goto fail;

@@ -181,7 +191,6 @@ int radeon_crtc_cursor_set(struct drm_crtc *crtc,
radeon_crtc->cursor_height = height;

radeon_lock_cursor(crtc, true);
-   /* XXX only 27 bit offset for legacy cursor */
radeon_set_cursor(crtc, obj, gpu_addr);
radeon_show_cursor(crtc);
radeon_lock_cursor(crtc, false);
diff --git a/drivers/gpu/drm/radeon/radeon_object.c 
b/drivers/gpu/drm/radeon/radeon_object.c
index d45df17..fd2dc0e 100644
--- a/drivers/gpu/drm/radeon/radeon_object.c
+++ b/drivers/gpu/drm/radeon/radeon_object.c
@@ -224,7 +224,8 @@ void radeon_bo_unref(struct radeon_bo **bo)
*bo = NULL;
 }

-int radeon_bo_pin(struct radeon_bo *bo, u32 domain, u64 *gpu_addr)
+int radeon_bo_pin_restricted(struct radeon_bo *bo, u32 domain, u64 max_offset,
+u64 *gpu_addr)
 {
int r, i;

@@ -232,6 +233,7 @@ int radeon_bo_pin(struct radeon_bo *bo, u32 domain, u64 
*gpu_addr)
bo->pin_count++;
if (gpu_addr)
*gpu_addr = radeon_bo_gpu_offset(bo);
+   WARN_ON_ONCE(max_offset != 0);
return 0;
}
radeon_ttm_placement_from_domain(bo, domain);
@@ -239,6 +241,15 @@ int radeon_bo_pin(struct radeon_bo *bo, u32 domain, u64 
*gpu_addr)
/* force to pin into visible video ram */
bo->placement.lpfn = bo->rdev->mc.visible_vram_size >> 
PAGE_SHIFT;
}
+   if (max_offset) {
+   u64 lpfn = max_offset >> PAGE_SHIFT;
+
+   if (!bo->placement.lpfn)
+   bo->placement.lpfn = bo->rdev->mc.gtt_size >> 
PAGE_SHIFT;
+
+   if (lpfn < bo->placement.lpfn)
+   bo->placement.lpfn = lpfn;
+   }
for (i = 0; i < bo->placement.num_placement; i++)
bo->placements[i] |= TTM_PL_FLAG_NO_EVICT;
r = ttm_bo_validate(>tbo, >placement, false, false, false);
@@ -252,6 +263,11 @@ int radeon_bo_pin(struct radeon_bo *bo, u32 domain, u64 
*gpu_addr)
return r;
 }

+int radeon_bo_pin(struct radeon_bo *bo, u32 domain, u64 *gpu_addr)
+{
+   return radeon_bo_pin_restricted(bo, domain, 0, gpu_addr);
+}
+
 int radeon_bo_unpin(struct radeon_bo *bo)
 {
int r, i;
diff --git a/drivers/gpu/drm/radeon/radeon_object.h 
b/drivers/gpu/drm/radeon/radeon_object.h
index cde4303..f9104be 100644
--- a/drivers/gpu/drm/radeon/radeon_object.h
+++ b/drivers/gpu/drm/radeon/radeon_object.h
@@ -118,6 +118,8 @@ extern int radeon_bo_kmap(struct radeon_bo *bo, void **ptr);
 extern void radeon_bo_kunmap(struct radeon_bo *bo);
 extern void radeon_bo_unref(struct radeon_bo **bo);
 extern int radeon_bo_pin(struct radeon_bo *bo, u32 domain, u64 *gpu_addr);
+extern int radeon_bo_pin_restricted(struct radeon_bo *bo, u32 domain,
+   u64 max_offset, u64 *gpu_addr);
 extern int radeon_bo_unpin(struct radeon_bo *bo);
 extern int radeon_bo_evict_vram(struct radeon_device *rdev);
 extern void radeon_bo_force_delete(struct radeon_device *rdev);
-- 
1.7.9.1

[PATCH 1/2] drm/radeon: Restrict offset for legacy hardware cursor.

[Michel Dänzer]

On Mit, 2012-03-14 at 11:08 -0400, Alex Deucher wrote: 
> 2012/3/14 Michel D?nzer :
> > From: Michel D?nzer 
> >
> > The hardware only takes 27 bits for the offset, so larger offsets are
> > truncated, and the hardware cursor shows random bits other than the intended
> > ones.
> >
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=46796
> >
> > Cc: stable at vger.kernel.org
> > Signed-off-by: Michel D?nzer 
> 
> Reviewed-by: Alex Deucher 

Thanks. In the meantime, it occurred to me there might be a problem when
there's less than 128M of VRAM in the first place (so bo->placement.lpfn
ends up larger than rdev->mman.bdev.man[TTM_PL_VRAM].size). To be safe,
I'll send a v2 patch preventing that.


> FWIW, I think we may need a similar fix for the crtc base addresses.
> They are also limited to 27 bit offsets from the mc address specified
> in DISPLAY[2]_BASE_ADDR.

Hmm, good point.


-- 
Earthling Michel D?nzer   |   http://www.amd.com
Libre software enthusiast |  Debian, X and DRI developer

[Bug 42920] Radeon with KMS and UMA works only up to 128MB

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=42920





--- Comment #6 from j.fikar at gmail.com  2012-03-14 15:49:41 ---
vramlimit didn't work, it's in my first post;
but I'll verify that.

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

[PATCH] omap2+: add drm device

[Tomi Valkeinen]

On Wed, 2012-03-14 at 08:16 -0500, Rob Clark wrote:
> On Wed, Mar 14, 2012 at 8:07 AM, Tomi Valkeinen  
> wrote:
> > On Wed, 2012-03-14 at 07:55 -0500, Rob Clark wrote:
> >> On Wed, Mar 14, 2012 at 7:38 AM, Tomi Valkeinen  
> >> wrote:
> >> > Hi,
> >> >
> >> > On Tue, 2012-03-13 at 15:34 -0500, Rob Clark wrote:
> >> >> From: Andy Gross 
> >> >>
> >> >> Register OMAP DRM/KMS platform device, and reserve a CMA region for
> >> >> the device to use for buffer allocation.  DMM is split into a
> >> >> separate device using hwmod.
> >> >
> >> > What's the diff with this and the previous one?
> >>
> >> Moving drm.c to mach-omap2 (header could not move because
> >> omap_reserve() is in plat-omap.. but this seems to be the same as what
> >> is done for dspbridge).
> >>
> >> > I see you still have the platform data there. You didn't comment on
> >> > that. Where is it used after the board files are gone when we use DT?
> >>
> >> I was kind-of thinking that there would be some DT<->data-structure
> >> glue somewhere.. not sure if this goes in mach-omap2 or in the driver
> >> itself, but presumably it is needed somewhere.
> >>
> >> It is only really special cases where some board specific device-tree
> >> data is needed, so it seems like this is ok to handle later.
> >
> > Afaik DT data should only contain information about the hardware. This
> > is SW configuration, so I think DT people won't accept things like that.
> 
> hmm, then where *does* it go.. it is a bit too much for bootargs..

I have no idea =). And I may be wrong, but my understanding is the the
only thing DT data should have is information about the HW
configuration.

But is that kind of configuration needed at boot time? Why cannot the
userspace do the config? What configs are actually needed at boot time,
before userspace takes control? The only thing coming to my mind is to
define the display used for the console.

> >> > And how about the size of the contiguous memory area, it was left a bit
> >> > unclear to me why it cannot be dynamic.
> >>
> >> I don't think there is anything preventing adding a bootarg, but I
> >> think it is not essential so ok to add later
> >
> > Well, maybe not essential to you =). But you are reserving 32MB memory,
> > which is quite a big amount. Even if the reserved memory can be used for
> > some other purposes, it's still a big chunk of "special" memory being
> > reserved even if the user doesn't use or have a display at all.
> 
> If you didn't have display, and were tight on memory, wouldn't you
> just disable the display device in your kernel config?

Sure, if you want to modify your kernel. But you could as well use the
same kernel binary, and just say vram=0M which disables the vram
allocation. For DRM you would _have_ to modify your kernel.

Actually, I just realized vram=0M doesn't work, as the code checks for !
= 0, and just skips the vram argument when it's 0 =). So my code sucks
also...

> > Well, it's not an issue for me either, but I just feel that doing things
> > like that without allowing the user to avoid it is a bit bad thing.
> >
> > Btw, do you know why the dma_declare_contiguous() takes a dev pointer as
> > an argument, if the memory is not private to that device? (at least I
> > understood from you that the memory can be used for other purposes).
> 
> contiguous use of the memory is private to the device.  There is also
> a global CMA pool, from which all dma_alloc_xyz() which is not
> associated w/ a per-device pool comes from.. but the advantage of a
> per-device-pool is it puts an upper limit on how much dma memory that
> device can allocate so that it cannot starve other devices.

Ah, I see. So the 32MB you reserve there is not visible as contiguous
memory to anyone else than omapdrm, but userspace can still use the 32MB
area for pages that can be moved out as needed.

But then, if it's private, it's also rather bad. If I have a kernel with
omapfb and omapdrm enabled as modules, but I never use omapdrm, the 32MB
is still always reserver and away from other contiguous memory use.

Also, I just realized that besides the memory reservation being fixed,
it's also hidden. If I enable omapdrm in the kernel config, I get no
indication that 32MB of mem is being reserved. Perhaps a Kconfig option
for it, like with OMAP VRAM, and then a boot arg which will override the
Kconfig value.

Well, as I said, it's not an issue for me and from my side it can be
improved later.

 Tomi

[PATCH 2/2] drm/radeon: Restrict offset for legacy display engine.

[Alex Deucher]

2012/3/14 Michel D?nzer :
> From: Michel D?nzer 
>
> The hardware only takes 27 bits for the offset, so larger offsets are
> truncated, and the display shows random bits other than the intended ones.
>
> Signed-off-by: Michel D?nzer 

Reviewed-by: Alex Deucher 

This should probably go to stable as well.  I think it may also fix this bug:
https://bugzilla.kernel.org/show_bug.cgi?id=16515

Alex

> ---
> ?drivers/gpu/drm/radeon/radeon_display.c ? ? | ? ?4 +++-
> ?drivers/gpu/drm/radeon/radeon_fb.c ? ? ? ? ?| ? ?5 -
> ?drivers/gpu/drm/radeon/radeon_legacy_crtc.c | ? ?4 +++-
> ?3 files changed, 10 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_display.c 
> b/drivers/gpu/drm/radeon/radeon_display.c
> index d3ffc18..63386a4 100644
> --- a/drivers/gpu/drm/radeon/radeon_display.c
> +++ b/drivers/gpu/drm/radeon/radeon_display.c
> @@ -393,7 +393,9 @@ static int radeon_crtc_page_flip(struct drm_crtc *crtc,
> ? ? ? ? ? ? ? ?DRM_ERROR("failed to reserve new rbo buffer before flip\n");
> ? ? ? ? ? ? ? ?goto pflip_cleanup;
> ? ? ? ?}
> - ? ? ? r = radeon_bo_pin(rbo, RADEON_GEM_DOMAIN_VRAM, );
> + ? ? ? /* Only 27 bit offset for legacy CRTC */
> + ? ? ? r = radeon_bo_pin_restricted(rbo, RADEON_GEM_DOMAIN_VRAM,
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?ASIC_IS_AVIVO(rdev) ? 0 : 1 << 27, 
> );
> ? ? ? ?if (unlikely(r != 0)) {
> ? ? ? ? ? ? ? ?radeon_bo_unreserve(rbo);
> ? ? ? ? ? ? ? ?r = -EINVAL;
> diff --git a/drivers/gpu/drm/radeon/radeon_fb.c 
> b/drivers/gpu/drm/radeon/radeon_fb.c
> index cf2bf35..93bf920 100644
> --- a/drivers/gpu/drm/radeon/radeon_fb.c
> +++ b/drivers/gpu/drm/radeon/radeon_fb.c
> @@ -164,7 +164,10 @@ static int radeonfb_create_pinned_object(struct 
> radeon_fbdev *rfbdev,
> ? ? ? ?ret = radeon_bo_reserve(rbo, false);
> ? ? ? ?if (unlikely(ret != 0))
> ? ? ? ? ? ? ? ?goto out_unref;
> - ? ? ? ret = radeon_bo_pin(rbo, RADEON_GEM_DOMAIN_VRAM, NULL);
> + ? ? ? /* Only 27 bit offset for legacy CRTC */
> + ? ? ? ret = radeon_bo_pin_restricted(rbo, RADEON_GEM_DOMAIN_VRAM,
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?ASIC_IS_AVIVO(rdev) ? 0 : 1 << 27,
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?NULL);
> ? ? ? ?if (ret) {
> ? ? ? ? ? ? ? ?radeon_bo_unreserve(rbo);
> ? ? ? ? ? ? ? ?goto out_unref;
> diff --git a/drivers/gpu/drm/radeon/radeon_legacy_crtc.c 
> b/drivers/gpu/drm/radeon/radeon_legacy_crtc.c
> index 25a19c4..210317c 100644
> --- a/drivers/gpu/drm/radeon/radeon_legacy_crtc.c
> +++ b/drivers/gpu/drm/radeon/radeon_legacy_crtc.c
> @@ -419,7 +419,9 @@ int radeon_crtc_do_set_base(struct drm_crtc *crtc,
> ? ? ? ?r = radeon_bo_reserve(rbo, false);
> ? ? ? ?if (unlikely(r != 0))
> ? ? ? ? ? ? ? ?return r;
> - ? ? ? r = radeon_bo_pin(rbo, RADEON_GEM_DOMAIN_VRAM, );
> + ? ? ? /* Only 27 bit offset for legacy CRTC */
> + ? ? ? r = radeon_bo_pin_restricted(rbo, RADEON_GEM_DOMAIN_VRAM, 1 << 27,
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?);
> ? ? ? ?if (unlikely(r != 0)) {
> ? ? ? ? ? ? ? ?radeon_bo_unreserve(rbo);
> ? ? ? ? ? ? ? ?return -EINVAL;
> --
> 1.7.9.1
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 1/2] drm/radeon: Restrict offset for legacy hardware cursor.

[Alex Deucher]

2012/3/14 Michel D?nzer :
> From: Michel D?nzer 
>
> The hardware only takes 27 bits for the offset, so larger offsets are
> truncated, and the hardware cursor shows random bits other than the intended
> ones.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=46796
>
> Cc: stable at vger.kernel.org
> Signed-off-by: Michel D?nzer 

Reviewed-by: Alex Deucher 

> ---
>
> v2: Make sure bo->placement.lpfn isn't larger than the memory size, even if
> ? ?radeon_bo_pin_restricted were to be called for the GTT domain.
>
> ?drivers/gpu/drm/radeon/radeon_cursor.c | ? 13 +++--
> ?drivers/gpu/drm/radeon/radeon_object.c | ? 18 +-
> ?drivers/gpu/drm/radeon/radeon_object.h | ? ?2 ++
> ?3 files changed, 30 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_cursor.c 
> b/drivers/gpu/drm/radeon/radeon_cursor.c
> index fde25c0..986d608 100644
> --- a/drivers/gpu/drm/radeon/radeon_cursor.c
> +++ b/drivers/gpu/drm/radeon/radeon_cursor.c
> @@ -151,7 +151,9 @@ int radeon_crtc_cursor_set(struct drm_crtc *crtc,
> ? ? ? ? ? ? ? ? ? ? ? ? ? uint32_t height)
> ?{
> ? ? ? ?struct radeon_crtc *radeon_crtc = to_radeon_crtc(crtc);
> + ? ? ? struct radeon_device *rdev = crtc->dev->dev_private;
> ? ? ? ?struct drm_gem_object *obj;
> + ? ? ? struct radeon_bo *robj;
> ? ? ? ?uint64_t gpu_addr;
> ? ? ? ?int ret;
>
> @@ -173,7 +175,15 @@ int radeon_crtc_cursor_set(struct drm_crtc *crtc,
> ? ? ? ? ? ? ? ?return -ENOENT;
> ? ? ? ?}
>
> - ? ? ? ret = radeon_gem_object_pin(obj, RADEON_GEM_DOMAIN_VRAM, _addr);
> + ? ? ? robj = gem_to_radeon_bo(obj);
> + ? ? ? ret = radeon_bo_reserve(robj, false);
> + ? ? ? if (unlikely(ret != 0))
> + ? ? ? ? ? ? ? goto fail;
> + ? ? ? /* Only 27 bit offset for legacy cursor */
> + ? ? ? ret = radeon_bo_pin_restricted(robj, RADEON_GEM_DOMAIN_VRAM,
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?ASIC_IS_AVIVO(rdev) ? 0 : 1 << 27,
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?_addr);
> + ? ? ? radeon_bo_unreserve(robj);
> ? ? ? ?if (ret)
> ? ? ? ? ? ? ? ?goto fail;
>
> @@ -181,7 +191,6 @@ int radeon_crtc_cursor_set(struct drm_crtc *crtc,
> ? ? ? ?radeon_crtc->cursor_height = height;
>
> ? ? ? ?radeon_lock_cursor(crtc, true);
> - ? ? ? /* XXX only 27 bit offset for legacy cursor */
> ? ? ? ?radeon_set_cursor(crtc, obj, gpu_addr);
> ? ? ? ?radeon_show_cursor(crtc);
> ? ? ? ?radeon_lock_cursor(crtc, false);
> diff --git a/drivers/gpu/drm/radeon/radeon_object.c 
> b/drivers/gpu/drm/radeon/radeon_object.c
> index d45df17..fd2dc0e 100644
> --- a/drivers/gpu/drm/radeon/radeon_object.c
> +++ b/drivers/gpu/drm/radeon/radeon_object.c
> @@ -224,7 +224,8 @@ void radeon_bo_unref(struct radeon_bo **bo)
> ? ? ? ? ? ? ? ?*bo = NULL;
> ?}
>
> -int radeon_bo_pin(struct radeon_bo *bo, u32 domain, u64 *gpu_addr)
> +int radeon_bo_pin_restricted(struct radeon_bo *bo, u32 domain, u64 
> max_offset,
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ?u64 *gpu_addr)
> ?{
> ? ? ? ?int r, i;
>
> @@ -232,6 +233,7 @@ int radeon_bo_pin(struct radeon_bo *bo, u32 domain, u64 
> *gpu_addr)
> ? ? ? ? ? ? ? ?bo->pin_count++;
> ? ? ? ? ? ? ? ?if (gpu_addr)
> ? ? ? ? ? ? ? ? ? ? ? ?*gpu_addr = radeon_bo_gpu_offset(bo);
> + ? ? ? ? ? ? ? WARN_ON_ONCE(max_offset != 0);
> ? ? ? ? ? ? ? ?return 0;
> ? ? ? ?}
> ? ? ? ?radeon_ttm_placement_from_domain(bo, domain);
> @@ -239,6 +241,15 @@ int radeon_bo_pin(struct radeon_bo *bo, u32 domain, u64 
> *gpu_addr)
> ? ? ? ? ? ? ? ?/* force to pin into visible video ram */
> ? ? ? ? ? ? ? ?bo->placement.lpfn = bo->rdev->mc.visible_vram_size >> 
> PAGE_SHIFT;
> ? ? ? ?}
> + ? ? ? if (max_offset) {
> + ? ? ? ? ? ? ? u64 lpfn = max_offset >> PAGE_SHIFT;
> +
> + ? ? ? ? ? ? ? if (!bo->placement.lpfn)
> + ? ? ? ? ? ? ? ? ? ? ? bo->placement.lpfn = bo->rdev->mc.gtt_size >> 
> PAGE_SHIFT;
> +
> + ? ? ? ? ? ? ? if (lpfn < bo->placement.lpfn)
> + ? ? ? ? ? ? ? ? ? ? ? bo->placement.lpfn = lpfn;
> + ? ? ? }
> ? ? ? ?for (i = 0; i < bo->placement.num_placement; i++)
> ? ? ? ? ? ? ? ?bo->placements[i] |= TTM_PL_FLAG_NO_EVICT;
> ? ? ? ?r = ttm_bo_validate(>tbo, >placement, false, false, false);
> @@ -252,6 +263,11 @@ int radeon_bo_pin(struct radeon_bo *bo, u32 domain, u64 
> *gpu_addr)
> ? ? ? ?return r;
> ?}
>
> +int radeon_bo_pin(struct radeon_bo *bo, u32 domain, u64 *gpu_addr)
> +{
> + ? ? ? return radeon_bo_pin_restricted(bo, domain, 0, gpu_addr);
> +}
> +
> ?int radeon_bo_unpin(struct radeon_bo *bo)
> ?{
> ? ? ? ?int r, i;
> diff --git a/drivers/gpu/drm/radeon/radeon_object.h 
> b/drivers/gpu/drm/radeon/radeon_object.h
> index cde4303..f9104be 100644
> --- a/drivers/gpu/drm/radeon/radeon_object.h
> +++ b/drivers/gpu/drm/radeon/radeon_object.h
> @@ -118,6 +118,8 @@ extern int radeon_bo_kmap(struct radeon_bo *bo, void 
> **ptr);
> ?extern void radeon_bo_kunmap(struct radeon_bo *bo);
> ?extern void radeon_bo_unref(struct radeon_bo **bo);
> ?extern int radeon_bo_pin(struct radeon_bo *bo, u32 domain, u64 *gpu_addr);
> +extern int radeon_bo_pin_restricted(struct radeon_bo *bo, u32 domain,
> + ? ? ? ? ? ? ? ? 

[Bug 46713] HDMI audio played back at a wrong rate

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=46713

Christian K?nig  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||deathsimple at vodafone.de

--- Comment #18 from Christian K?nig  2012-03-14 
08:09:27 PDT ---
Ok, I will try to get you the documentation for the PLL regs, they are not DRM
or IP related. So there is a slightly chance that we can release them.

Christian.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[PATCH] omap2+: add drm device

[Tomi Valkeinen]

On Wed, 2012-03-14 at 07:55 -0500, Rob Clark wrote:
> On Wed, Mar 14, 2012 at 7:38 AM, Tomi Valkeinen  
> wrote:
> > Hi,
> >
> > On Tue, 2012-03-13 at 15:34 -0500, Rob Clark wrote:
> >> From: Andy Gross 
> >>
> >> Register OMAP DRM/KMS platform device, and reserve a CMA region for
> >> the device to use for buffer allocation.  DMM is split into a
> >> separate device using hwmod.
> >
> > What's the diff with this and the previous one?
> 
> Moving drm.c to mach-omap2 (header could not move because
> omap_reserve() is in plat-omap.. but this seems to be the same as what
> is done for dspbridge).
> 
> > I see you still have the platform data there. You didn't comment on
> > that. Where is it used after the board files are gone when we use DT?
> 
> I was kind-of thinking that there would be some DT<->data-structure
> glue somewhere.. not sure if this goes in mach-omap2 or in the driver
> itself, but presumably it is needed somewhere.
> 
> It is only really special cases where some board specific device-tree
> data is needed, so it seems like this is ok to handle later.

Afaik DT data should only contain information about the hardware. This
is SW configuration, so I think DT people won't accept things like that.

> > And how about the size of the contiguous memory area, it was left a bit
> > unclear to me why it cannot be dynamic.
> 
> I don't think there is anything preventing adding a bootarg, but I
> think it is not essential so ok to add later

Well, maybe not essential to you =). But you are reserving 32MB memory,
which is quite a big amount. Even if the reserved memory can be used for
some other purposes, it's still a big chunk of "special" memory being
reserved even if the user doesn't use or have a display at all.

Well, it's not an issue for me either, but I just feel that doing things
like that without allowing the user to avoid it is a bit bad thing.

Btw, do you know why the dma_declare_contiguous() takes a dev pointer as
an argument, if the memory is not private to that device? (at least I
understood from you that the memory can be used for other purposes).

 Tomi

[Bug 42920] Radeon with KMS and UMA works only up to 128MB

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=42920





--- Comment #5 from Alex Deucher   2012-03-14 
15:02:42 ---
(In reply to comment #4)
> for 256MB, 512MB and 1024MB I get
> 
> [6.301475] [drm] CONFIG_MEMSIZE: 0x
> 
> also I need a cold restart when changing UMA size in bios, otherwise it's not
> changed.
> 
> so is it a bios problem? should I try to complain to Asus? Is there an easy
> workaround? Like using manually vramlimit?

Looks like the bios is broken.  The vramlimit parameter should work.

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

[PATCH 2/2] drm/radeon: Drop radeon_gem_object_(un)pin.

[Michel Dänzer]

From: Michel D?nzer 

Only radeon_gem_object_unpin was used anymore, in only one place.

Signed-off-by: Michel D?nzer 
---
 drivers/gpu/drm/radeon/radeon.h|3 ---
 drivers/gpu/drm/radeon/radeon_cursor.c |7 ++-
 drivers/gpu/drm/radeon/radeon_gem.c|   26 --
 3 files changed, 6 insertions(+), 30 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index ec995ca..1414900 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -375,9 +375,6 @@ int radeon_gem_object_create(struct radeon_device *rdev, 
int size,
int alignment, int initial_domain,
bool discardable, bool kernel,
struct drm_gem_object **obj);
-int radeon_gem_object_pin(struct drm_gem_object *obj, uint32_t pin_domain,
- uint64_t *gpu_addr);
-void radeon_gem_object_unpin(struct drm_gem_object *obj);

 int radeon_mode_dumb_create(struct drm_file *file_priv,
struct drm_device *dev,
diff --git a/drivers/gpu/drm/radeon/radeon_cursor.c 
b/drivers/gpu/drm/radeon/radeon_cursor.c
index 986d608..42acc64 100644
--- a/drivers/gpu/drm/radeon/radeon_cursor.c
+++ b/drivers/gpu/drm/radeon/radeon_cursor.c
@@ -197,7 +197,12 @@ int radeon_crtc_cursor_set(struct drm_crtc *crtc,

 unpin:
if (radeon_crtc->cursor_bo) {
-   radeon_gem_object_unpin(radeon_crtc->cursor_bo);
+   robj = gem_to_radeon_bo(radeon_crtc->cursor_bo);
+   ret = radeon_bo_reserve(robj, false);
+   if (likely(ret == 0)) {
+   radeon_bo_unpin(robj);
+   radeon_bo_unreserve(robj);
+   }
drm_gem_object_unreference_unlocked(radeon_crtc->cursor_bo);
}

diff --git a/drivers/gpu/drm/radeon/radeon_gem.c 
b/drivers/gpu/drm/radeon/radeon_gem.c
index 003eeec..090da31 100644
--- a/drivers/gpu/drm/radeon/radeon_gem.c
+++ b/drivers/gpu/drm/radeon/radeon_gem.c
@@ -75,32 +75,6 @@ int radeon_gem_object_create(struct radeon_device *rdev, int 
size,
return 0;
 }

-int radeon_gem_object_pin(struct drm_gem_object *obj, uint32_t pin_domain,
- uint64_t *gpu_addr)
-{
-   struct radeon_bo *robj = gem_to_radeon_bo(obj);
-   int r;
-
-   r = radeon_bo_reserve(robj, false);
-   if (unlikely(r != 0))
-   return r;
-   r = radeon_bo_pin(robj, pin_domain, gpu_addr);
-   radeon_bo_unreserve(robj);
-   return r;
-}
-
-void radeon_gem_object_unpin(struct drm_gem_object *obj)
-{
-   struct radeon_bo *robj = gem_to_radeon_bo(obj);
-   int r;
-
-   r = radeon_bo_reserve(robj, false);
-   if (likely(r == 0)) {
-   radeon_bo_unpin(robj);
-   radeon_bo_unreserve(robj);
-   }
-}
-
 int radeon_gem_set_domain(struct drm_gem_object *gobj,
  uint32_t rdomain, uint32_t wdomain)
 {
-- 
1.7.9.1

[PATCH 1/2] drm/radeon: Restrict offset for legacy hardware cursor.

[Michel Dänzer]

From: Michel D?nzer 

The hardware only takes 27 bits for the offset, so larger offsets are
truncated, and the hardware cursor shows random bits other than the intended
ones.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=46796

Cc: stable at vger.kernel.org
Signed-off-by: Michel D?nzer 
---
 drivers/gpu/drm/radeon/radeon_cursor.c |   13 +++--
 drivers/gpu/drm/radeon/radeon_object.c |   18 +-
 drivers/gpu/drm/radeon/radeon_object.h |2 ++
 3 files changed, 30 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_cursor.c 
b/drivers/gpu/drm/radeon/radeon_cursor.c
index fde25c0..986d608 100644
--- a/drivers/gpu/drm/radeon/radeon_cursor.c
+++ b/drivers/gpu/drm/radeon/radeon_cursor.c
@@ -151,7 +151,9 @@ int radeon_crtc_cursor_set(struct drm_crtc *crtc,
   uint32_t height)
 {
struct radeon_crtc *radeon_crtc = to_radeon_crtc(crtc);
+   struct radeon_device *rdev = crtc->dev->dev_private;
struct drm_gem_object *obj;
+   struct radeon_bo *robj;
uint64_t gpu_addr;
int ret;

@@ -173,7 +175,15 @@ int radeon_crtc_cursor_set(struct drm_crtc *crtc,
return -ENOENT;
}

-   ret = radeon_gem_object_pin(obj, RADEON_GEM_DOMAIN_VRAM, _addr);
+   robj = gem_to_radeon_bo(obj);
+   ret = radeon_bo_reserve(robj, false);
+   if (unlikely(ret != 0))
+   goto fail;
+   /* Only 27 bit offset for legacy cursor */
+   ret = radeon_bo_pin_restricted(robj, RADEON_GEM_DOMAIN_VRAM,
+  ASIC_IS_AVIVO(rdev) ? 0 : 1 << 27,
+  _addr);
+   radeon_bo_unreserve(robj);
if (ret)
goto fail;

@@ -181,7 +191,6 @@ int radeon_crtc_cursor_set(struct drm_crtc *crtc,
radeon_crtc->cursor_height = height;

radeon_lock_cursor(crtc, true);
-   /* XXX only 27 bit offset for legacy cursor */
radeon_set_cursor(crtc, obj, gpu_addr);
radeon_show_cursor(crtc);
radeon_lock_cursor(crtc, false);
diff --git a/drivers/gpu/drm/radeon/radeon_object.c 
b/drivers/gpu/drm/radeon/radeon_object.c
index d45df17..388be34 100644
--- a/drivers/gpu/drm/radeon/radeon_object.c
+++ b/drivers/gpu/drm/radeon/radeon_object.c
@@ -224,7 +224,8 @@ void radeon_bo_unref(struct radeon_bo **bo)
*bo = NULL;
 }

-int radeon_bo_pin(struct radeon_bo *bo, u32 domain, u64 *gpu_addr)
+int radeon_bo_pin_restricted(struct radeon_bo *bo, u32 domain, u64 max_offset,
+u64 *gpu_addr)
 {
int r, i;

@@ -232,6 +233,7 @@ int radeon_bo_pin(struct radeon_bo *bo, u32 domain, u64 
*gpu_addr)
bo->pin_count++;
if (gpu_addr)
*gpu_addr = radeon_bo_gpu_offset(bo);
+   WARN_ON_ONCE(max_offset != 0);
return 0;
}
radeon_ttm_placement_from_domain(bo, domain);
@@ -239,6 +241,15 @@ int radeon_bo_pin(struct radeon_bo *bo, u32 domain, u64 
*gpu_addr)
/* force to pin into visible video ram */
bo->placement.lpfn = bo->rdev->mc.visible_vram_size >> 
PAGE_SHIFT;
}
+   if (max_offset) {
+   u64 lpfn = max_offset >> PAGE_SHIFT;
+
+   if (bo->placement.lpfn) {
+   if (lpfn < bo->placement.lpfn)
+   bo->placement.lpfn = lpfn;
+   } else
+   bo->placement.lpfn = lpfn;
+   }
for (i = 0; i < bo->placement.num_placement; i++)
bo->placements[i] |= TTM_PL_FLAG_NO_EVICT;
r = ttm_bo_validate(>tbo, >placement, false, false, false);
@@ -252,6 +263,11 @@ int radeon_bo_pin(struct radeon_bo *bo, u32 domain, u64 
*gpu_addr)
return r;
 }

+int radeon_bo_pin(struct radeon_bo *bo, u32 domain, u64 *gpu_addr)
+{
+   return radeon_bo_pin_restricted(bo, domain, 0, gpu_addr);
+}
+
 int radeon_bo_unpin(struct radeon_bo *bo)
 {
int r, i;
diff --git a/drivers/gpu/drm/radeon/radeon_object.h 
b/drivers/gpu/drm/radeon/radeon_object.h
index cde4303..f9104be 100644
--- a/drivers/gpu/drm/radeon/radeon_object.h
+++ b/drivers/gpu/drm/radeon/radeon_object.h
@@ -118,6 +118,8 @@ extern int radeon_bo_kmap(struct radeon_bo *bo, void **ptr);
 extern void radeon_bo_kunmap(struct radeon_bo *bo);
 extern void radeon_bo_unref(struct radeon_bo **bo);
 extern int radeon_bo_pin(struct radeon_bo *bo, u32 domain, u64 *gpu_addr);
+extern int radeon_bo_pin_restricted(struct radeon_bo *bo, u32 domain,
+   u64 max_offset, u64 *gpu_addr);
 extern int radeon_bo_unpin(struct radeon_bo *bo);
 extern int radeon_bo_evict_vram(struct radeon_device *rdev);
 extern void radeon_bo_force_delete(struct radeon_device *rdev);
-- 
1.7.9.1

[Bug 46796] [X800SE] Mouse cursor corruption when switching users

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=46796

Michel D?nzer  changed:

   What|Removed |Added

  Attachment #58312|0   |1
is obsolete||

--- Comment #12 from Michel D?nzer  2012-03-14 07:57:05 
PDT ---
Created attachment 58436
  --> https://bugs.freedesktop.org/attachment.cgi?id=58436
Submitted fix

(In reply to comment #11)
> [...] I haven't had the mouse corruption issue on this patched driver, and the
> message appears in dmesg:

Okay, so an unpatched driver probably would use too large offsets sometimes,
which would definitely explain the corrupted cursor. So the fix seems to be
working.


> I have to say that the log confuses me since 1 << 27 is not 0.

Indeed, but that's just a bug of the DRM_INFO call. :) (Type mismatch between
format string and values)


I'm attaching the fix as I submitted it for inclusion into the kernel.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 42920] Radeon with KMS and UMA works only up to 128MB

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=42920





--- Comment #4 from j.fikar at gmail.com  2012-03-14 14:46:30 ---
for 256MB, 512MB and 1024MB I get

[6.301475] [drm] CONFIG_MEMSIZE: 0x

also I need a cold restart when changing UMA size in bios, otherwise it's not
changed.

so is it a bios problem? should I try to complain to Asus? Is there an easy
workaround? Like using manually vramlimit?

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

[PATCH] omap2+: add drm device

[Tomi Valkeinen]

Hi,

On Tue, 2012-03-13 at 15:34 -0500, Rob Clark wrote:
> From: Andy Gross 
> 
> Register OMAP DRM/KMS platform device, and reserve a CMA region for
> the device to use for buffer allocation.  DMM is split into a
> separate device using hwmod.

What's the diff with this and the previous one?

I see you still have the platform data there. You didn't comment on
that. Where is it used after the board files are gone when we use DT?

And how about the size of the contiguous memory area, it was left a bit
unclear to me why it cannot be dynamic.

 Tomi

-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120314/cd13204f/attachment.pgp>

[Bug 42876] System doesn't boot with GTX 550 Ti

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=42876


legia  changed:

   What|Removed |Added

 CC||legia at klikni.cz




--- Comment #2 from legia   2012-03-14 12:31:58 ---
I have the same problem. No boot with 3.2.x kernel(Debian, Fedora).

C2D
Asus P5Q-E
GeForce 550 Ti

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

[PATCH 2/2] gma500: suspend/resume support for Cedartrail

[Alan Cox]

From: Alan Cox 

Update our tree to match the current driver head.

Signed-off-by: Alan Cox 
---

 drivers/gpu/drm/gma500/cdv_device.c|  169 
 drivers/gpu/drm/gma500/power.c |3 -
 drivers/gpu/drm/gma500/psb_drv.h   |   20 
 drivers/gpu/drm/gma500/psb_intel_reg.h |9 ++
 4 files changed, 181 insertions(+), 20 deletions(-)


diff --git a/drivers/gpu/drm/gma500/cdv_device.c 
b/drivers/gpu/drm/gma500/cdv_device.c
index 4a5b099..eefcef6 100644
--- a/drivers/gpu/drm/gma500/cdv_device.c
+++ b/drivers/gpu/drm/gma500/cdv_device.c
@@ -202,13 +202,12 @@ static inline void CDV_MSG_WRITE32(uint port, uint 
offset, u32 value)
pci_dev_put(pci_root);
 }

-#define PSB_APM_CMD0x0
-#define PSB_APM_STS0x04
 #define PSB_PM_SSC 0x20
 #define PSB_PM_SSS 0x30
-#define PSB_PWRGT_GFX_MASK 0x3
-#define CDV_PWRGT_DISPLAY_CNTR 0x000fc00c
-#define CDV_PWRGT_DISPLAY_STS  0x000fc00c
+#define PSB_PWRGT_GFX_ON   0x02
+#define PSB_PWRGT_GFX_OFF  0x01
+#define PSB_PWRGT_GFX_D0   0x00
+#define PSB_PWRGT_GFX_D3   0x03

 static void cdv_init_pm(struct drm_device *dev)
 {
@@ -221,26 +220,22 @@ static void cdv_init_pm(struct drm_device *dev)
dev_priv->ospm_base = CDV_MSG_READ32(PSB_PUNIT_PORT,
PSB_OSPMBA) & 0x;

-   /* Force power on for now */
+   /* Power status */
pwr_cnt = inl(dev_priv->apm_base + PSB_APM_CMD);
-   pwr_cnt &= ~PSB_PWRGT_GFX_MASK;

+   /* Enable the GPU */
+   pwr_cnt &= ~PSB_PWRGT_GFX_MASK;
+   pwr_cnt |= PSB_PWRGT_GFX_ON;
outl(pwr_cnt, dev_priv->apm_base + PSB_APM_CMD);
+
+   /* Wait for the GPU power */
for (i = 0; i < 5; i++) {
u32 pwr_sts = inl(dev_priv->apm_base + PSB_APM_STS);
if ((pwr_sts & PSB_PWRGT_GFX_MASK) == 0)
-   break;
-   udelay(10);
-   }
-   pwr_cnt = inl(dev_priv->ospm_base + PSB_PM_SSC);
-   pwr_cnt &= ~CDV_PWRGT_DISPLAY_CNTR;
-   outl(pwr_cnt, dev_priv->ospm_base + PSB_PM_SSC);
-   for (i = 0; i < 5; i++) {
-   u32 pwr_sts = inl(dev_priv->ospm_base + PSB_PM_SSS);
-   if ((pwr_sts & CDV_PWRGT_DISPLAY_STS) == 0)
-   break;
+   return;
udelay(10);
}
+   dev_err(dev->dev, "GPU: power management timed out.\n");
 }

 /**
@@ -249,11 +244,50 @@ static void cdv_init_pm(struct drm_device *dev)
  *
  * Save the state we need in order to be able to restore the interface
  * upon resume from suspend
- *
- * FIXME: review
  */
 static int cdv_save_display_registers(struct drm_device *dev)
 {
+   struct drm_psb_private *dev_priv = dev->dev_private;
+   struct psb_save_area *regs = _priv->regs;
+   struct drm_connector *connector;
+
+   dev_info(dev->dev, "Saving GPU registers.\n");
+
+   pci_read_config_byte(dev->pdev, 0xF4, >cdv.saveLBB);
+
+   regs->cdv.saveDSPCLK_GATE_D = REG_READ(DSPCLK_GATE_D);
+   regs->cdv.saveRAMCLK_GATE_D = REG_READ(RAMCLK_GATE_D);
+
+   regs->cdv.saveDSPARB = REG_READ(DSPARB);
+   regs->cdv.saveDSPFW[0] = REG_READ(DSPFW1);
+   regs->cdv.saveDSPFW[1] = REG_READ(DSPFW2);
+   regs->cdv.saveDSPFW[2] = REG_READ(DSPFW3);
+   regs->cdv.saveDSPFW[3] = REG_READ(DSPFW4);
+   regs->cdv.saveDSPFW[4] = REG_READ(DSPFW5);
+   regs->cdv.saveDSPFW[5] = REG_READ(DSPFW6);
+
+   regs->cdv.saveADPA = REG_READ(ADPA);
+
+   regs->cdv.savePP_CONTROL = REG_READ(PP_CONTROL);
+   regs->cdv.savePFIT_PGM_RATIOS = REG_READ(PFIT_PGM_RATIOS);
+   regs->saveBLC_PWM_CTL = REG_READ(BLC_PWM_CTL);
+   regs->saveBLC_PWM_CTL2 = REG_READ(BLC_PWM_CTL2);
+   regs->cdv.saveLVDS = REG_READ(LVDS);
+
+   regs->cdv.savePFIT_CONTROL = REG_READ(PFIT_CONTROL);
+
+   regs->cdv.savePP_ON_DELAYS = REG_READ(PP_ON_DELAYS);
+   regs->cdv.savePP_OFF_DELAYS = REG_READ(PP_OFF_DELAYS);
+   regs->cdv.savePP_CYCLE = REG_READ(PP_CYCLE);
+
+   regs->cdv.saveVGACNTRL = REG_READ(VGACNTRL);
+
+   regs->cdv.saveIER = REG_READ(PSB_INT_ENABLE_R);
+   regs->cdv.saveIMR = REG_READ(PSB_INT_MASK_R);
+
+   list_for_each_entry(connector, >mode_config.connector_list, head)
+   connector->funcs->dpms(connector, DRM_MODE_DPMS_OFF);
+
return 0;
 }

@@ -267,16 +301,113 @@ static int cdv_save_display_registers(struct drm_device 
*dev)
  */
 static int cdv_restore_display_registers(struct drm_device *dev)
 {
+   struct drm_psb_private *dev_priv = dev->dev_private;
+   struct psb_save_area *regs = _priv->regs;
+   struct drm_connector *connector;
+   u32 temp;
+
+   pci_write_config_byte(dev->pdev, 0xF4, regs->cdv.saveLBB);
+
+   REG_WRITE(DSPCLK_GATE_D, 

[PATCH 1/2] gma500: Fix resume paths

[Alan Cox]

From: Alan Cox 

We fall apart somewhat on resume because we don't invoke all the resume
methods as we should. Fix the silly error in the logic.

Signed-off-by: Alan Cox 
---

 drivers/gpu/drm/gma500/power.c |3 ---
 1 files changed, 0 insertions(+), 3 deletions(-)


diff --git a/drivers/gpu/drm/gma500/power.c b/drivers/gpu/drm/gma500/power.c
index 994f669..8d23c45 100644
--- a/drivers/gpu/drm/gma500/power.c
+++ b/drivers/gpu/drm/gma500/power.c
@@ -102,9 +102,6 @@ static void gma_resume_display(struct pci_dev *pdev)
struct drm_device *dev = pci_get_drvdata(pdev);
struct drm_psb_private *dev_priv = dev->dev_private;

-   if (dev_priv->suspended == false)
-   return;
-
/* turn on the display power island */
dev_priv->ops->power_up(dev);
dev_priv->suspended = false;

[PULL] drm-intel-fixes

[Keith Packard]

Jesse sent me a couple of trivial sprite plane fixes.

The following changes since commit 91982b58d35720b75b894c60e1e3133daa455b53:

  drm/gma500: Fix Cedarview boot failures in 3.3-rc (2012-03-05 14:08:31 +)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/keithp/linux drm-intel-fixes

for you to fetch changes up to b250da79a0c972ef7f6d58ebd1083cab066e6c82:

  drm/i915: support 32 bit BGR formats in sprite planes (2012-03-07 10:52:13 
-0800)


Jesse Barnes (2):
  drm/i915: fix color order for BGR formats on SNB
  drm/i915: support 32 bit BGR formats in sprite planes

 drivers/gpu/drm/i915/i915_reg.h  |2 +-
 drivers/gpu/drm/i915/intel_display.c |1 +
 drivers/gpu/drm/i915/intel_sprite.c  |6 +++---
 3 files changed, 5 insertions(+), 4 deletions(-)

-- 
keith.packard at intel.com
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120314/ee924489/attachment.pgp>

[PATCH 2/2] drm/radeon: Drop radeon_gem_object_(un)pin.

[Alex Deucher]

2012/3/14 Michel D?nzer :
> From: Michel D?nzer 
>
> Only radeon_gem_object_unpin was used anymore, in only one place.
>
> Signed-off-by: Michel D?nzer 

Reviewed-by: Alex Deucher 

> ---
> ?drivers/gpu/drm/radeon/radeon.h ? ? ? ?| ? ?3 ---
> ?drivers/gpu/drm/radeon/radeon_cursor.c | ? ?7 ++-
> ?drivers/gpu/drm/radeon/radeon_gem.c ? ?| ? 26 --
> ?3 files changed, 6 insertions(+), 30 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
> index ec995ca..1414900 100644
> --- a/drivers/gpu/drm/radeon/radeon.h
> +++ b/drivers/gpu/drm/radeon/radeon.h
> @@ -375,9 +375,6 @@ int radeon_gem_object_create(struct radeon_device *rdev, 
> int size,
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?int alignment, int initial_domain,
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?bool discardable, bool kernel,
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?struct drm_gem_object **obj);
> -int radeon_gem_object_pin(struct drm_gem_object *obj, uint32_t pin_domain,
> - ? ? ? ? ? ? ? ? ? ? ? ? uint64_t *gpu_addr);
> -void radeon_gem_object_unpin(struct drm_gem_object *obj);
>
> ?int radeon_mode_dumb_create(struct drm_file *file_priv,
> ? ? ? ? ? ? ? ? ? ? ? ? ? ?struct drm_device *dev,
> diff --git a/drivers/gpu/drm/radeon/radeon_cursor.c 
> b/drivers/gpu/drm/radeon/radeon_cursor.c
> index 986d608..42acc64 100644
> --- a/drivers/gpu/drm/radeon/radeon_cursor.c
> +++ b/drivers/gpu/drm/radeon/radeon_cursor.c
> @@ -197,7 +197,12 @@ int radeon_crtc_cursor_set(struct drm_crtc *crtc,
>
> ?unpin:
> ? ? ? ?if (radeon_crtc->cursor_bo) {
> - ? ? ? ? ? ? ? radeon_gem_object_unpin(radeon_crtc->cursor_bo);
> + ? ? ? ? ? ? ? robj = gem_to_radeon_bo(radeon_crtc->cursor_bo);
> + ? ? ? ? ? ? ? ret = radeon_bo_reserve(robj, false);
> + ? ? ? ? ? ? ? if (likely(ret == 0)) {
> + ? ? ? ? ? ? ? ? ? ? ? radeon_bo_unpin(robj);
> + ? ? ? ? ? ? ? ? ? ? ? radeon_bo_unreserve(robj);
> + ? ? ? ? ? ? ? }
> ? ? ? ? ? ? ? ?drm_gem_object_unreference_unlocked(radeon_crtc->cursor_bo);
> ? ? ? ?}
>
> diff --git a/drivers/gpu/drm/radeon/radeon_gem.c 
> b/drivers/gpu/drm/radeon/radeon_gem.c
> index 003eeec..090da31 100644
> --- a/drivers/gpu/drm/radeon/radeon_gem.c
> +++ b/drivers/gpu/drm/radeon/radeon_gem.c
> @@ -75,32 +75,6 @@ int radeon_gem_object_create(struct radeon_device *rdev, 
> int size,
> ? ? ? ?return 0;
> ?}
>
> -int radeon_gem_object_pin(struct drm_gem_object *obj, uint32_t pin_domain,
> - ? ? ? ? ? ? ? ? ? ? ? ? uint64_t *gpu_addr)
> -{
> - ? ? ? struct radeon_bo *robj = gem_to_radeon_bo(obj);
> - ? ? ? int r;
> -
> - ? ? ? r = radeon_bo_reserve(robj, false);
> - ? ? ? if (unlikely(r != 0))
> - ? ? ? ? ? ? ? return r;
> - ? ? ? r = radeon_bo_pin(robj, pin_domain, gpu_addr);
> - ? ? ? radeon_bo_unreserve(robj);
> - ? ? ? return r;
> -}
> -
> -void radeon_gem_object_unpin(struct drm_gem_object *obj)
> -{
> - ? ? ? struct radeon_bo *robj = gem_to_radeon_bo(obj);
> - ? ? ? int r;
> -
> - ? ? ? r = radeon_bo_reserve(robj, false);
> - ? ? ? if (likely(r == 0)) {
> - ? ? ? ? ? ? ? radeon_bo_unpin(robj);
> - ? ? ? ? ? ? ? radeon_bo_unreserve(robj);
> - ? ? ? }
> -}
> -
> ?int radeon_gem_set_domain(struct drm_gem_object *gobj,
> ? ? ? ? ? ? ? ? ? ? ? ? ?uint32_t rdomain, uint32_t wdomain)
> ?{
> --
> 1.7.9.1
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/2] drm/radeon: Restrict offset for legacy hardware cursor.

[Alex Deucher]

2012/3/14 Michel D?nzer :
> From: Michel D?nzer 
>
> The hardware only takes 27 bits for the offset, so larger offsets are
> truncated, and the hardware cursor shows random bits other than the intended
> ones.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=46796
>
> Cc: stable at vger.kernel.org
> Signed-off-by: Michel D?nzer 

Reviewed-by: Alex Deucher 

FWIW, I think we may need a similar fix for the crtc base addresses.
They are also limited to 27 bit offsets from the mc address specified
in DISPLAY[2]_BASE_ADDR.

> ---
> ?drivers/gpu/drm/radeon/radeon_cursor.c | ? 13 +++--
> ?drivers/gpu/drm/radeon/radeon_object.c | ? 18 +-
> ?drivers/gpu/drm/radeon/radeon_object.h | ? ?2 ++
> ?3 files changed, 30 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_cursor.c 
> b/drivers/gpu/drm/radeon/radeon_cursor.c
> index fde25c0..986d608 100644
> --- a/drivers/gpu/drm/radeon/radeon_cursor.c
> +++ b/drivers/gpu/drm/radeon/radeon_cursor.c
> @@ -151,7 +151,9 @@ int radeon_crtc_cursor_set(struct drm_crtc *crtc,
> ? ? ? ? ? ? ? ? ? ? ? ? ? uint32_t height)
> ?{
> ? ? ? ?struct radeon_crtc *radeon_crtc = to_radeon_crtc(crtc);
> + ? ? ? struct radeon_device *rdev = crtc->dev->dev_private;
> ? ? ? ?struct drm_gem_object *obj;
> + ? ? ? struct radeon_bo *robj;
> ? ? ? ?uint64_t gpu_addr;
> ? ? ? ?int ret;
>
> @@ -173,7 +175,15 @@ int radeon_crtc_cursor_set(struct drm_crtc *crtc,
> ? ? ? ? ? ? ? ?return -ENOENT;
> ? ? ? ?}
>
> - ? ? ? ret = radeon_gem_object_pin(obj, RADEON_GEM_DOMAIN_VRAM, _addr);
> + ? ? ? robj = gem_to_radeon_bo(obj);
> + ? ? ? ret = radeon_bo_reserve(robj, false);
> + ? ? ? if (unlikely(ret != 0))
> + ? ? ? ? ? ? ? goto fail;
> + ? ? ? /* Only 27 bit offset for legacy cursor */
> + ? ? ? ret = radeon_bo_pin_restricted(robj, RADEON_GEM_DOMAIN_VRAM,
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?ASIC_IS_AVIVO(rdev) ? 0 : 1 << 27,
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?_addr);
> + ? ? ? radeon_bo_unreserve(robj);
> ? ? ? ?if (ret)
> ? ? ? ? ? ? ? ?goto fail;
>
> @@ -181,7 +191,6 @@ int radeon_crtc_cursor_set(struct drm_crtc *crtc,
> ? ? ? ?radeon_crtc->cursor_height = height;
>
> ? ? ? ?radeon_lock_cursor(crtc, true);
> - ? ? ? /* XXX only 27 bit offset for legacy cursor */
> ? ? ? ?radeon_set_cursor(crtc, obj, gpu_addr);
> ? ? ? ?radeon_show_cursor(crtc);
> ? ? ? ?radeon_lock_cursor(crtc, false);
> diff --git a/drivers/gpu/drm/radeon/radeon_object.c 
> b/drivers/gpu/drm/radeon/radeon_object.c
> index d45df17..388be34 100644
> --- a/drivers/gpu/drm/radeon/radeon_object.c
> +++ b/drivers/gpu/drm/radeon/radeon_object.c
> @@ -224,7 +224,8 @@ void radeon_bo_unref(struct radeon_bo **bo)
> ? ? ? ? ? ? ? ?*bo = NULL;
> ?}
>
> -int radeon_bo_pin(struct radeon_bo *bo, u32 domain, u64 *gpu_addr)
> +int radeon_bo_pin_restricted(struct radeon_bo *bo, u32 domain, u64 
> max_offset,
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ?u64 *gpu_addr)
> ?{
> ? ? ? ?int r, i;
>
> @@ -232,6 +233,7 @@ int radeon_bo_pin(struct radeon_bo *bo, u32 domain, u64 
> *gpu_addr)
> ? ? ? ? ? ? ? ?bo->pin_count++;
> ? ? ? ? ? ? ? ?if (gpu_addr)
> ? ? ? ? ? ? ? ? ? ? ? ?*gpu_addr = radeon_bo_gpu_offset(bo);
> + ? ? ? ? ? ? ? WARN_ON_ONCE(max_offset != 0);
> ? ? ? ? ? ? ? ?return 0;
> ? ? ? ?}
> ? ? ? ?radeon_ttm_placement_from_domain(bo, domain);
> @@ -239,6 +241,15 @@ int radeon_bo_pin(struct radeon_bo *bo, u32 domain, u64 
> *gpu_addr)
> ? ? ? ? ? ? ? ?/* force to pin into visible video ram */
> ? ? ? ? ? ? ? ?bo->placement.lpfn = bo->rdev->mc.visible_vram_size >> 
> PAGE_SHIFT;
> ? ? ? ?}
> + ? ? ? if (max_offset) {
> + ? ? ? ? ? ? ? u64 lpfn = max_offset >> PAGE_SHIFT;
> +
> + ? ? ? ? ? ? ? if (bo->placement.lpfn) {
> + ? ? ? ? ? ? ? ? ? ? ? if (lpfn < bo->placement.lpfn)
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? bo->placement.lpfn = lpfn;
> + ? ? ? ? ? ? ? } else
> + ? ? ? ? ? ? ? ? ? ? ? bo->placement.lpfn = lpfn;
> + ? ? ? }
> ? ? ? ?for (i = 0; i < bo->placement.num_placement; i++)
> ? ? ? ? ? ? ? ?bo->placements[i] |= TTM_PL_FLAG_NO_EVICT;
> ? ? ? ?r = ttm_bo_validate(>tbo, >placement, false, false, false);
> @@ -252,6 +263,11 @@ int radeon_bo_pin(struct radeon_bo *bo, u32 domain, u64 
> *gpu_addr)
> ? ? ? ?return r;
> ?}
>
> +int radeon_bo_pin(struct radeon_bo *bo, u32 domain, u64 *gpu_addr)
> +{
> + ? ? ? return radeon_bo_pin_restricted(bo, domain, 0, gpu_addr);
> +}
> +
> ?int radeon_bo_unpin(struct radeon_bo *bo)
> ?{
> ? ? ? ?int r, i;
> diff --git a/drivers/gpu/drm/radeon/radeon_object.h 
> b/drivers/gpu/drm/radeon/radeon_object.h
> index cde4303..f9104be 100644
> --- a/drivers/gpu/drm/radeon/radeon_object.h
> +++ b/drivers/gpu/drm/radeon/radeon_object.h
> @@ -118,6 +118,8 @@ extern int radeon_bo_kmap(struct radeon_bo *bo, void 
> **ptr);
> ?extern void radeon_bo_kunmap(struct radeon_bo *bo);
> ?extern void radeon_bo_unref(struct radeon_bo **bo);
> ?extern int radeon_bo_pin(struct radeon_bo *bo, u32 domain, u64 *gpu_addr);
> +extern int radeon_bo_pin_restricted(struct radeon_bo *bo, u32 domain,

[DEBUG PATCH] Print a message when a spurious i2c SCL timeout occurs.

[Ville Syrjälä]

A quick hack to verify that the fix works as intended...

Do not apply.

---
 drivers/i2c/algos/i2c-algo-bit.c |6 ++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/drivers/i2c/algos/i2c-algo-bit.c b/drivers/i2c/algos/i2c-algo-bit.c
index d25112e..3f547b5 100644
--- a/drivers/i2c/algos/i2c-algo-bit.c
+++ b/drivers/i2c/algos/i2c-algo-bit.c
@@ -89,6 +89,7 @@ static inline void scllo(struct i2c_algo_bit_data *adap)
 static int sclhi(struct i2c_algo_bit_data *adap)
 {
unsigned long start;
+   bool timeout = false;

setscl(adap, 1);

@@ -104,11 +105,16 @@ static int sclhi(struct i2c_algo_bit_data *adap)
 * are processing data internally.
 */
if (time_after(jiffies, start + adap->timeout))
+   {
+   timeout = true;
break;
+   }
cond_resched();
}
if (!getscl(adap))
return -ETIMEDOUT;
+   if (timeout)
+   printk(KERN_CRIT "spurious i2c scl timeout\n");
 #ifdef DEBUG
if (jiffies != start && i2c_debug >= 3)
pr_debug("i2c-algo-bit: needed %ld jiffies for SCL to go "
-- 
1.7.3.4

[PATCH] i2c-algo-bit: Fix spurious SCL timeouts under heavy load

[Ville Syrjälä]

When the system is under heavy load, there can be a significant delay
between the getscl() and time_after() calls inside sclhi(). That delay
may cause the time_after() check to trigger after SCL has gone high,
causing sclhi() to return -ETIMEDOUT.

To fix the problem, double check that SCL is still low after the
timeout has been reached, before deciding to return -ETIMEDOUT.

Signed-off-by: Ville Syrj?l? 
---
I can easily reproduce these spurious timeouts on my HP-compaq nc6000
laptop with the radeon kms driver. It's enough to have a -j2 kernel
build running, and simultaneosly issue xrandr commands in a
terminal. Calling xrandr will cause the driver to re-read the EDID
from the display. A significant number of the EDID reads will fail.
With this fix I have yet to see any failed EDID reads.

 drivers/i2c/algos/i2c-algo-bit.c |4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/drivers/i2c/algos/i2c-algo-bit.c b/drivers/i2c/algos/i2c-algo-bit.c
index 525c734..d25112e 100644
--- a/drivers/i2c/algos/i2c-algo-bit.c
+++ b/drivers/i2c/algos/i2c-algo-bit.c
@@ -104,9 +104,11 @@ static int sclhi(struct i2c_algo_bit_data *adap)
 * are processing data internally.
 */
if (time_after(jiffies, start + adap->timeout))
-   return -ETIMEDOUT;
+   break;
cond_resched();
}
+   if (!getscl(adap))
+   return -ETIMEDOUT;
 #ifdef DEBUG
if (jiffies != start && i2c_debug >= 3)
pr_debug("i2c-algo-bit: needed %ld jiffies for SCL to go "
-- 
1.7.3.4

[PATCH] omap2+: add drm device

[Rob Clark]

On Wed, Mar 14, 2012 at 8:43 AM, Tomi Valkeinen  
wrote:
> On Wed, 2012-03-14 at 08:16 -0500, Rob Clark wrote:
>> On Wed, Mar 14, 2012 at 8:07 AM, Tomi Valkeinen  
>> wrote:
>> > On Wed, 2012-03-14 at 07:55 -0500, Rob Clark wrote:
>> >> On Wed, Mar 14, 2012 at 7:38 AM, Tomi Valkeinen > >> ti.com> wrote:
>> >> > Hi,
>> >> >
>> >> > On Tue, 2012-03-13 at 15:34 -0500, Rob Clark wrote:
>> >> >> From: Andy Gross 
>> >> >>
>> >> >> Register OMAP DRM/KMS platform device, and reserve a CMA region for
>> >> >> the device to use for buffer allocation. ?DMM is split into a
>> >> >> separate device using hwmod.
>> >> >
>> >> > What's the diff with this and the previous one?
>> >>
>> >> Moving drm.c to mach-omap2 (header could not move because
>> >> omap_reserve() is in plat-omap.. but this seems to be the same as what
>> >> is done for dspbridge).
>> >>
>> >> > I see you still have the platform data there. You didn't comment on
>> >> > that. Where is it used after the board files are gone when we use DT?
>> >>
>> >> I was kind-of thinking that there would be some DT<->data-structure
>> >> glue somewhere.. not sure if this goes in mach-omap2 or in the driver
>> >> itself, but presumably it is needed somewhere.
>> >>
>> >> It is only really special cases where some board specific device-tree
>> >> data is needed, so it seems like this is ok to handle later.
>> >
>> > Afaik DT data should only contain information about the hardware. This
>> > is SW configuration, so I think DT people won't accept things like that.
>>
>> hmm, then where *does* it go.. it is a bit too much for bootargs..
>
> I have no idea =). And I may be wrong, but my understanding is the the
> only thing DT data should have is information about the HW
> configuration.
>
> But is that kind of configuration needed at boot time? Why cannot the
> userspace do the config? What configs are actually needed at boot time,
> before userspace takes control? The only thing coming to my mind is to
> define the display used for the console.

drm builds up list of resources at startup, and attempts to light up
any connected displays at boot..  the decision about what resources to
use must be taken before userspace starts.

Anyways, if it is too controversial, maybe I just remove it.  It is
really only very special cases (possibly multi-seat setups) where you
might want to do something other than the default (which is for a
single omapdrm instance to use all dss video pipes).  It is just code
I had written previously for a certain product, and it seemed
potentially useful enough to not strip out of the upstream driver.

>> >> > And how about the size of the contiguous memory area, it was left a bit
>> >> > unclear to me why it cannot be dynamic.
>> >>
>> >> I don't think there is anything preventing adding a bootarg, but I
>> >> think it is not essential so ok to add later
>> >
>> > Well, maybe not essential to you =). But you are reserving 32MB memory,
>> > which is quite a big amount. Even if the reserved memory can be used for
>> > some other purposes, it's still a big chunk of "special" memory being
>> > reserved even if the user doesn't use or have a display at all.
>>
>> If you didn't have display, and were tight on memory, wouldn't you
>> just disable the display device in your kernel config?
>
> Sure, if you want to modify your kernel. But you could as well use the
> same kernel binary, and just say vram=0M which disables the vram
> allocation. For DRM you would _have_ to modify your kernel.
>
> Actually, I just realized vram=0M doesn't work, as the code checks for !
> = 0, and just skips the vram argument when it's 0 =). So my code sucks
> also...

well, I suppose there is always something somewhere to improve..

anyways, at this point omapdrm isn't enabled by default in
omap2plus_defconfig.. I just want to get the platform device
registration merged in some form so folks don't have to go poking
around to find some out of tree patch in order to enable it.

>> > Well, it's not an issue for me either, but I just feel that doing things
>> > like that without allowing the user to avoid it is a bit bad thing.
>> >
>> > Btw, do you know why the dma_declare_contiguous() takes a dev pointer as
>> > an argument, if the memory is not private to that device? (at least I
>> > understood from you that the memory can be used for other purposes).
>>
>> contiguous use of the memory is private to the device. ?There is also
>> a global CMA pool, from which all dma_alloc_xyz() which is not
>> associated w/ a per-device pool comes from.. but the advantage of a
>> per-device-pool is it puts an upper limit on how much dma memory that
>> device can allocate so that it cannot starve other devices.
>
> Ah, I see. So the 32MB you reserve there is not visible as contiguous
> memory to anyone else than omapdrm, but userspace can still use the 32MB
> area for pages that can be moved out as needed.
>
> But then, if it's private, it's also rather bad. If I have a kernel with
> omapfb and 

[PATCH] omap2+: add drm device

[Rob Clark]

On Wed, Mar 14, 2012 at 8:07 AM, Tomi Valkeinen  
wrote:
> On Wed, 2012-03-14 at 07:55 -0500, Rob Clark wrote:
>> On Wed, Mar 14, 2012 at 7:38 AM, Tomi Valkeinen  
>> wrote:
>> > Hi,
>> >
>> > On Tue, 2012-03-13 at 15:34 -0500, Rob Clark wrote:
>> >> From: Andy Gross 
>> >>
>> >> Register OMAP DRM/KMS platform device, and reserve a CMA region for
>> >> the device to use for buffer allocation. ?DMM is split into a
>> >> separate device using hwmod.
>> >
>> > What's the diff with this and the previous one?
>>
>> Moving drm.c to mach-omap2 (header could not move because
>> omap_reserve() is in plat-omap.. but this seems to be the same as what
>> is done for dspbridge).
>>
>> > I see you still have the platform data there. You didn't comment on
>> > that. Where is it used after the board files are gone when we use DT?
>>
>> I was kind-of thinking that there would be some DT<->data-structure
>> glue somewhere.. not sure if this goes in mach-omap2 or in the driver
>> itself, but presumably it is needed somewhere.
>>
>> It is only really special cases where some board specific device-tree
>> data is needed, so it seems like this is ok to handle later.
>
> Afaik DT data should only contain information about the hardware. This
> is SW configuration, so I think DT people won't accept things like that.

hmm, then where *does* it go.. it is a bit too much for bootargs..

>> > And how about the size of the contiguous memory area, it was left a bit
>> > unclear to me why it cannot be dynamic.
>>
>> I don't think there is anything preventing adding a bootarg, but I
>> think it is not essential so ok to add later
>
> Well, maybe not essential to you =). But you are reserving 32MB memory,
> which is quite a big amount. Even if the reserved memory can be used for
> some other purposes, it's still a big chunk of "special" memory being
> reserved even if the user doesn't use or have a display at all.

If you didn't have display, and were tight on memory, wouldn't you
just disable the display device in your kernel config?

> Well, it's not an issue for me either, but I just feel that doing things
> like that without allowing the user to avoid it is a bit bad thing.
>
> Btw, do you know why the dma_declare_contiguous() takes a dev pointer as
> an argument, if the memory is not private to that device? (at least I
> understood from you that the memory can be used for other purposes).

contiguous use of the memory is private to the device.  There is also
a global CMA pool, from which all dma_alloc_xyz() which is not
associated w/ a per-device pool comes from.. but the advantage of a
per-device-pool is it puts an upper limit on how much dma memory that
device can allocate so that it cannot starve other devices.

BR,
-R

> ?Tomi
>
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] omap2+: add drm device

[Rob Clark]

On Wed, Mar 14, 2012 at 7:38 AM, Tomi Valkeinen  
wrote:
> Hi,
>
> On Tue, 2012-03-13 at 15:34 -0500, Rob Clark wrote:
>> From: Andy Gross 
>>
>> Register OMAP DRM/KMS platform device, and reserve a CMA region for
>> the device to use for buffer allocation. ?DMM is split into a
>> separate device using hwmod.
>
> What's the diff with this and the previous one?

Moving drm.c to mach-omap2 (header could not move because
omap_reserve() is in plat-omap.. but this seems to be the same as what
is done for dspbridge).

> I see you still have the platform data there. You didn't comment on
> that. Where is it used after the board files are gone when we use DT?

I was kind-of thinking that there would be some DT<->data-structure
glue somewhere.. not sure if this goes in mach-omap2 or in the driver
itself, but presumably it is needed somewhere.

It is only really special cases where some board specific device-tree
data is needed, so it seems like this is ok to handle later.

> And how about the size of the contiguous memory area, it was left a bit
> unclear to me why it cannot be dynamic.

I don't think there is anything preventing adding a bootarg, but I
think it is not essential so ok to add later

BR,
-R

> ?Tomi
>

[RESEND][PATCH 09/10] drm/exynos: add G2D driver

[Inki Dae]

From: Joonyoung Shim 

G2D is a 2D graphic accelerator that supports Bit Block Transfer. This
G2D driver is exynos drm specific.

This adds below three exynos specific ioctl and one event for G2D.
 - DRM_EXYNOS_G2D_GET_VER
 - DRM_EXYNOS_G2D_SET_CMDLIST
 - DRM_EXYNOS_G2D_EXEC
 - DRM_EXYNOS_G2D_EVENT

Signed-off-by: Joonyoung Shim 
Signed-off-by: Inki Dae 
Signed-off-by: Kyungmin Park 
---
 drivers/gpu/drm/exynos/Kconfig  |6 +
 drivers/gpu/drm/exynos/Makefile |1 +
 drivers/gpu/drm/exynos/exynos_drm_drv.c |   31 ++
 drivers/gpu/drm/exynos/exynos_drm_drv.h |   13 +
 drivers/gpu/drm/exynos/exynos_drm_g2d.c |  885 +++
 drivers/gpu/drm/exynos/exynos_drm_g2d.h |   36 ++
 include/drm/exynos_drm.h|   56 ++
 7 files changed, 1028 insertions(+), 0 deletions(-)
 create mode 100644 drivers/gpu/drm/exynos/exynos_drm_g2d.c
 create mode 100644 drivers/gpu/drm/exynos/exynos_drm_g2d.h

diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
index 9a9850a..8493fe9 100644
--- a/drivers/gpu/drm/exynos/Kconfig
+++ b/drivers/gpu/drm/exynos/Kconfig
@@ -21,3 +21,9 @@ config DRM_EXYNOS_HDMI
depends on DRM_EXYNOS && !VIDEO_SAMSUNG_S5P_TV
help
  Choose this option if you want to use Exynos HDMI for DRM.
+
+config DRM_EXYNOS_G2D
+   bool "Exynos DRM G2D"
+   depends on DRM_EXYNOS
+   help
+ Choose this option if you want to use Exynos G2D for DRM.
diff --git a/drivers/gpu/drm/exynos/Makefile b/drivers/gpu/drm/exynos/Makefile
index 5331fa3..d6c1a3c 100644
--- a/drivers/gpu/drm/exynos/Makefile
+++ b/drivers/gpu/drm/exynos/Makefile
@@ -12,5 +12,6 @@ exynosdrm-$(CONFIG_DRM_EXYNOS_FIMD)   += exynos_drm_fimd.o
 exynosdrm-$(CONFIG_DRM_EXYNOS_HDMI)+= exynos_hdmi.o exynos_mixer.o \
   exynos_ddc.o exynos_hdmiphy.o \
   exynos_drm_hdmi.o
+exynosdrm-$(CONFIG_DRM_EXYNOS_G2D) += exynos_drm_g2d.o

 obj-$(CONFIG_DRM_EXYNOS)   += exynosdrm.o
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index b4e265f..2b72c5d 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -37,6 +37,7 @@
 #include "exynos_drm_fbdev.h"
 #include "exynos_drm_fb.h"
 #include "exynos_drm_gem.h"
+#include "exynos_drm_g2d.h"
 #include "exynos_drm_plane.h"

 #define DRIVER_NAME"exynos"
@@ -146,8 +147,16 @@ static int exynos_drm_unload(struct drm_device *dev)

 static int exynos_drm_open(struct drm_device *dev, struct drm_file *file)
 {
+   struct drm_exynos_file_private *file_priv;
+
DRM_DEBUG_DRIVER("%s\n", __FILE__);

+   file_priv = kzalloc(sizeof(*file_priv), GFP_KERNEL);
+   if (!file_priv)
+   return -ENOMEM;
+
+   file->driver_priv = file_priv;
+
return exynos_drm_subdrv_open(dev, file);
 }

@@ -208,6 +217,13 @@ static struct drm_ioctl_desc exynos_ioctls[] = {
exynos_drm_gem_mmap_ioctl, DRM_UNLOCKED | DRM_AUTH),
DRM_IOCTL_DEF_DRV(EXYNOS_PLANE_SET_ZPOS, exynos_plane_set_zpos_ioctl,
DRM_UNLOCKED | DRM_AUTH),
+
+   DRM_IOCTL_DEF_DRV(EXYNOS_G2D_GET_VER,
+   exynos_g2d_get_ver_ioctl, DRM_UNLOCKED | DRM_AUTH),
+   DRM_IOCTL_DEF_DRV(EXYNOS_G2D_SET_CMDLIST,
+   exynos_g2d_set_cmdlist_ioctl, DRM_UNLOCKED | DRM_AUTH),
+   DRM_IOCTL_DEF_DRV(EXYNOS_G2D_EXEC,
+   exynos_g2d_exec_ioctl, DRM_UNLOCKED | DRM_AUTH),
 };

 static const struct file_operations exynos_drm_driver_fops = {
@@ -298,6 +314,12 @@ static int __init exynos_drm_init(void)
goto out_common_hdmi;
 #endif

+#ifdef CONFIG_DRM_EXYNOS_G2D
+   ret = platform_driver_register(_driver);
+   if (ret < 0)
+   goto out_g2d;
+#endif
+
ret = platform_driver_register(_drm_platform_driver);
if (ret < 0)
goto out;
@@ -305,6 +327,11 @@ static int __init exynos_drm_init(void)
return 0;

 out:
+#ifdef CONFIG_DRM_EXYNOS_G2D
+   platform_driver_unregister(_driver);
+out_g2d:
+#endif
+
 #ifdef CONFIG_DRM_EXYNOS_HDMI
platform_driver_unregister(_drm_common_hdmi_driver);
 out_common_hdmi:
@@ -327,6 +354,10 @@ static void __exit exynos_drm_exit(void)

platform_driver_unregister(_drm_platform_driver);

+#ifdef CONFIG_DRM_EXYNOS_G2D
+   platform_driver_unregister(_driver);
+#endif
+
 #ifdef CONFIG_DRM_EXYNOS_HDMI
platform_driver_unregister(_drm_common_hdmi_driver);
platform_driver_unregister(_driver);
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index b26c2f4..750daa9 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -203,6 +203,18 @@ struct exynos_drm_manager {
struct exynos_drm_display_ops *display_ops;
 };

[RESEND][PATCH 01/10] drm/exynos: add HDMI version 1.4 support

[Inki Dae]

From: Joonyoung Shim 

Later Exynos series from Exynos4X12 support HDMI version 1.4. We will
distinguish to use which version via platform data.

Signed-off-by: Joonyoung Shim 
Signed-off-by: Inki Dae 
Signed-off-by: Kyungmin Park 
---
 drivers/gpu/drm/exynos/exynos_hdmi.c | 1152 +++---
 drivers/gpu/drm/exynos/exynos_hdmi.h |   10 +-
 drivers/gpu/drm/exynos/regs-hdmi.h   |  306 --
 include/drm/exynos_drm.h |2 +
 4 files changed, 1325 insertions(+), 145 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 3429d3f..1cfe86e 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -43,42 +43,43 @@
 #define HDMI_OVERLAY_NUMBER3
 #define get_hdmi_context(dev)  platform_get_drvdata(to_platform_device(dev))

-static const u8 hdmiphy_conf27[32] = {
+/* HDMI Version 1.3 */
+static const u8 hdmiphy_v13_conf27[32] = {
0x01, 0x05, 0x00, 0xD8, 0x10, 0x1C, 0x30, 0x40,
0x6B, 0x10, 0x02, 0x51, 0xDF, 0xF2, 0x54, 0x87,
0x84, 0x00, 0x30, 0x38, 0x00, 0x08, 0x10, 0xE0,
0x22, 0x40, 0xE3, 0x26, 0x00, 0x00, 0x00, 0x00,
 };

-static const u8 hdmiphy_conf27_027[32] = {
+static const u8 hdmiphy_v13_conf27_027[32] = {
0x01, 0x05, 0x00, 0xD4, 0x10, 0x9C, 0x09, 0x64,
0x6B, 0x10, 0x02, 0x51, 0xDF, 0xF2, 0x54, 0x87,
0x84, 0x00, 0x30, 0x38, 0x00, 0x08, 0x10, 0xE0,
0x22, 0x40, 0xE3, 0x26, 0x00, 0x00, 0x00, 0x00,
 };

-static const u8 hdmiphy_conf74_175[32] = {
+static const u8 hdmiphy_v13_conf74_175[32] = {
0x01, 0x05, 0x00, 0xD8, 0x10, 0x9C, 0xef, 0x5B,
0x6D, 0x10, 0x01, 0x51, 0xef, 0xF3, 0x54, 0xb9,
0x84, 0x00, 0x30, 0x38, 0x00, 0x08, 0x10, 0xE0,
0x22, 0x40, 0xa5, 0x26, 0x01, 0x00, 0x00, 0x00,
 };

-static const u8 hdmiphy_conf74_25[32] = {
+static const u8 hdmiphy_v13_conf74_25[32] = {
0x01, 0x05, 0x00, 0xd8, 0x10, 0x9c, 0xf8, 0x40,
0x6a, 0x10, 0x01, 0x51, 0xff, 0xf1, 0x54, 0xba,
0x84, 0x00, 0x10, 0x38, 0x00, 0x08, 0x10, 0xe0,
0x22, 0x40, 0xa4, 0x26, 0x01, 0x00, 0x00, 0x00,
 };

-static const u8 hdmiphy_conf148_5[32] = {
+static const u8 hdmiphy_v13_conf148_5[32] = {
0x01, 0x05, 0x00, 0xD8, 0x10, 0x9C, 0xf8, 0x40,
0x6A, 0x18, 0x00, 0x51, 0xff, 0xF1, 0x54, 0xba,
0x84, 0x00, 0x10, 0x38, 0x00, 0x08, 0x10, 0xE0,
0x22, 0x40, 0xa4, 0x26, 0x02, 0x00, 0x00, 0x00,
 };

-struct hdmi_tg_regs {
+struct hdmi_v13_tg_regs {
u8 cmd;
u8 h_fsz_l;
u8 h_fsz_h;
@@ -110,7 +111,7 @@ struct hdmi_tg_regs {
u8 field_bot_hdmi_h;
 };

-struct hdmi_core_regs {
+struct hdmi_v13_core_regs {
u8 h_blank[2];
u8 v_blank[3];
u8 h_v_line[3];
@@ -123,12 +124,21 @@ struct hdmi_core_regs {
u8 v_sync_gen3[3];
 };

-struct hdmi_preset_conf {
-   struct hdmi_core_regs core;
-   struct hdmi_tg_regs tg;
+struct hdmi_v13_preset_conf {
+   struct hdmi_v13_core_regs core;
+   struct hdmi_v13_tg_regs tg;
+};
+
+struct hdmi_v13_conf {
+   int width;
+   int height;
+   int vrefresh;
+   bool interlace;
+   const u8 *hdmiphy_data;
+   const struct hdmi_v13_preset_conf *conf;
 };

-static const struct hdmi_preset_conf hdmi_conf_480p = {
+static const struct hdmi_v13_preset_conf hdmi_v13_conf_480p = {
.core = {
.h_blank = {0x8a, 0x00},
.v_blank = {0x0d, 0x6a, 0x01},
@@ -154,7 +164,7 @@ static const struct hdmi_preset_conf hdmi_conf_480p = {
},
 };

-static const struct hdmi_preset_conf hdmi_conf_720p60 = {
+static const struct hdmi_v13_preset_conf hdmi_v13_conf_720p60 = {
.core = {
.h_blank = {0x72, 0x01},
.v_blank = {0xee, 0xf2, 0x00},
@@ -182,7 +192,7 @@ static const struct hdmi_preset_conf hdmi_conf_720p60 = {
},
 };

-static const struct hdmi_preset_conf hdmi_conf_1080i50 = {
+static const struct hdmi_v13_preset_conf hdmi_v13_conf_1080i50 = {
.core = {
.h_blank = {0xd0, 0x02},
.v_blank = {0x32, 0xB2, 0x00},
@@ -210,7 +220,7 @@ static const struct hdmi_preset_conf hdmi_conf_1080i50 = {
},
 };

-static const struct hdmi_preset_conf hdmi_conf_1080p50 = {
+static const struct hdmi_v13_preset_conf hdmi_v13_conf_1080p50 = {
.core = {
.h_blank = {0xd0, 0x02},
.v_blank = {0x65, 0x6c, 0x01},
@@ -238,7 +248,7 @@ static const struct hdmi_preset_conf hdmi_conf_1080p50 = {
},
 };

-static const struct hdmi_preset_conf hdmi_conf_1080i60 = {
+static const struct hdmi_v13_preset_conf hdmi_v13_conf_1080i60 = {
.core = {
.h_blank = {0x18, 0x01},
.v_blank = {0x32, 0xB2, 0x00},
@@ -266,7 +276,7 @@ static const struct hdmi_preset_conf hdmi_conf_1080i60 = {
},
 };

-static const struct hdmi_preset_conf hdmi_conf_1080p60 = {
+static const 

[PATCH 10/10] drm/exynos: added virtual display driver.

[Inki Dae]

this driver would be used for wireless display. virtual display
driver has independent crtc, encoder and connector and to use
this driver, user application should send edid data to this driver
from wireless display.

Signed-off-by: Inki Dae 
Signed-off-by: Kyungmin Park 
---
 drivers/gpu/drm/exynos/Kconfig|6 +
 drivers/gpu/drm/exynos/Makefile   |1 +
 drivers/gpu/drm/exynos/exynos_drm_connector.c |4 +
 drivers/gpu/drm/exynos/exynos_drm_drv.c   |   18 +
 drivers/gpu/drm/exynos/exynos_drm_drv.h   |7 +-
 drivers/gpu/drm/exynos/exynos_drm_encoder.c   |1 +
 drivers/gpu/drm/exynos/exynos_drm_vidi.c  |  677 +
 drivers/gpu/drm/exynos/exynos_drm_vidi.h  |   36 ++
 include/drm/exynos_drm.h  |   20 +
 9 files changed, 768 insertions(+), 2 deletions(-)
 create mode 100644 drivers/gpu/drm/exynos/exynos_drm_vidi.c
 create mode 100644 drivers/gpu/drm/exynos/exynos_drm_vidi.h

diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
index 8493fe9..76aed3a 100644
--- a/drivers/gpu/drm/exynos/Kconfig
+++ b/drivers/gpu/drm/exynos/Kconfig
@@ -22,6 +22,12 @@ config DRM_EXYNOS_HDMI
help
  Choose this option if you want to use Exynos HDMI for DRM.

+config DRM_EXYNOS_VIDI
+   bool "Samsung DRM Virtual Display"
+   depends on DRM_EXYNOS
+   help
+ Choose this option if you want to use Samsung VIDI for DRM.
+
 config DRM_EXYNOS_G2D
bool "Exynos DRM G2D"
depends on DRM_EXYNOS
diff --git a/drivers/gpu/drm/exynos/Makefile b/drivers/gpu/drm/exynos/Makefile
index d6c1a3c..8ee8fb4 100644
--- a/drivers/gpu/drm/exynos/Makefile
+++ b/drivers/gpu/drm/exynos/Makefile
@@ -12,6 +12,7 @@ exynosdrm-$(CONFIG_DRM_EXYNOS_FIMD)   += exynos_drm_fimd.o
 exynosdrm-$(CONFIG_DRM_EXYNOS_HDMI)+= exynos_hdmi.o exynos_mixer.o \
   exynos_ddc.o exynos_hdmiphy.o \
   exynos_drm_hdmi.o
+exynosdrm-$(CONFIG_DRM_EXYNOS_VIDI)+= exynos_drm_vidi.o
 exynosdrm-$(CONFIG_DRM_EXYNOS_G2D) += exynos_drm_g2d.o

 obj-$(CONFIG_DRM_EXYNOS)   += exynosdrm.o
diff --git a/drivers/gpu/drm/exynos/exynos_drm_connector.c 
b/drivers/gpu/drm/exynos/exynos_drm_connector.c
index 33893a9..bf791fa 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_connector.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_connector.c
@@ -315,6 +315,10 @@ struct drm_connector *exynos_drm_connector_create(struct 
drm_device *dev,
connector->interlace_allowed = true;
connector->polled = DRM_CONNECTOR_POLL_HPD;
break;
+   case EXYNOS_DISPLAY_TYPE_VIDI:
+   type = DRM_MODE_CONNECTOR_VIRTUAL;
+   connector->polled = DRM_CONNECTOR_POLL_HPD;
+   break;
default:
type = DRM_MODE_CONNECTOR_Unknown;
break;
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index 2b72c5d..76524f4 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -39,6 +39,7 @@
 #include "exynos_drm_gem.h"
 #include "exynos_drm_g2d.h"
 #include "exynos_drm_plane.h"
+#include "exynos_drm_vidi.h"

 #define DRIVER_NAME"exynos"
 #define DRIVER_DESC"Samsung SoC DRM"
@@ -217,6 +218,8 @@ static struct drm_ioctl_desc exynos_ioctls[] = {
exynos_drm_gem_mmap_ioctl, DRM_UNLOCKED | DRM_AUTH),
DRM_IOCTL_DEF_DRV(EXYNOS_PLANE_SET_ZPOS, exynos_plane_set_zpos_ioctl,
DRM_UNLOCKED | DRM_AUTH),
+   DRM_IOCTL_DEF_DRV(EXYNOS_VIDI_CONNECTION,
+   vidi_connection_ioctl, DRM_UNLOCKED | DRM_AUTH),

DRM_IOCTL_DEF_DRV(EXYNOS_G2D_GET_VER,
exynos_g2d_get_ver_ioctl, DRM_UNLOCKED | DRM_AUTH),
@@ -314,6 +317,12 @@ static int __init exynos_drm_init(void)
goto out_common_hdmi;
 #endif

+#ifdef CONFIG_DRM_EXYNOS_VIDI
+   ret = platform_driver_register(_driver);
+   if (ret < 0)
+   goto out_vidi;
+#endif
+
 #ifdef CONFIG_DRM_EXYNOS_G2D
ret = platform_driver_register(_driver);
if (ret < 0)
@@ -332,6 +341,11 @@ out:
 out_g2d:
 #endif

+#ifdef CONFIG_DRM_EXYNOS_VIDI
+   platform_driver_unregister(_driver);
+out_vidi:
+#endif
+
 #ifdef CONFIG_DRM_EXYNOS_HDMI
platform_driver_unregister(_drm_common_hdmi_driver);
 out_common_hdmi:
@@ -358,6 +372,10 @@ static void __exit exynos_drm_exit(void)
platform_driver_unregister(_driver);
 #endif

+#ifdef CONFIG_DRM_EXYNOS_VIDI
+   platform_driver_unregister(_driver);
+#endif
+
 #ifdef CONFIG_DRM_EXYNOS_HDMI
platform_driver_unregister(_drm_common_hdmi_driver);
platform_driver_unregister(_driver);
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index d7b50e5..943853a 100644
--- 

[PATCH 09/10] drm/exynos: add G2D driver

[Inki Dae]

From: Joonyoung Shim 

G2D is a 2D graphic accelerator that supports Bit Block Transfer. This
G2D driver is exynos drm specific and supports only exynos4x12 series.
user application fills command set in cmdlist and once dma start request
these cmdlists are parsed and performed by dma.

This adds below three exynos specific ioctl and one event for G2D.
 - DRM_EXYNOS_G2D_GET_VER
 - DRM_EXYNOS_G2D_SET_CMDLIST
 - DRM_EXYNOS_G2D_EXEC
 - DRM_EXYNOS_G2D_EVENT

Signed-off-by: Joonyoung Shim 
Signed-off-by: Inki Dae 
Signed-off-by: Kyungmin Park 
---
 drivers/gpu/drm/exynos/Kconfig  |6 +
 drivers/gpu/drm/exynos/Makefile |1 +
 drivers/gpu/drm/exynos/exynos_drm_drv.c |   31 ++
 drivers/gpu/drm/exynos/exynos_drm_drv.h |   11 +
 drivers/gpu/drm/exynos/exynos_drm_g2d.c |  864 +++
 drivers/gpu/drm/exynos/exynos_drm_g2d.h |   36 ++
 include/drm/exynos_drm.h|   56 ++
 7 files changed, 1005 insertions(+), 0 deletions(-)
 create mode 100644 drivers/gpu/drm/exynos/exynos_drm_g2d.c
 create mode 100644 drivers/gpu/drm/exynos/exynos_drm_g2d.h

diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
index 9a9850a..8493fe9 100644
--- a/drivers/gpu/drm/exynos/Kconfig
+++ b/drivers/gpu/drm/exynos/Kconfig
@@ -21,3 +21,9 @@ config DRM_EXYNOS_HDMI
depends on DRM_EXYNOS && !VIDEO_SAMSUNG_S5P_TV
help
  Choose this option if you want to use Exynos HDMI for DRM.
+
+config DRM_EXYNOS_G2D
+   bool "Exynos DRM G2D"
+   depends on DRM_EXYNOS
+   help
+ Choose this option if you want to use Exynos G2D for DRM.
diff --git a/drivers/gpu/drm/exynos/Makefile b/drivers/gpu/drm/exynos/Makefile
index 5331fa3..d6c1a3c 100644
--- a/drivers/gpu/drm/exynos/Makefile
+++ b/drivers/gpu/drm/exynos/Makefile
@@ -12,5 +12,6 @@ exynosdrm-$(CONFIG_DRM_EXYNOS_FIMD)   += exynos_drm_fimd.o
 exynosdrm-$(CONFIG_DRM_EXYNOS_HDMI)+= exynos_hdmi.o exynos_mixer.o \
   exynos_ddc.o exynos_hdmiphy.o \
   exynos_drm_hdmi.o
+exynosdrm-$(CONFIG_DRM_EXYNOS_G2D) += exynos_drm_g2d.o

 obj-$(CONFIG_DRM_EXYNOS)   += exynosdrm.o
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index b4e265f..2b72c5d 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -37,6 +37,7 @@
 #include "exynos_drm_fbdev.h"
 #include "exynos_drm_fb.h"
 #include "exynos_drm_gem.h"
+#include "exynos_drm_g2d.h"
 #include "exynos_drm_plane.h"

 #define DRIVER_NAME"exynos"
@@ -146,8 +147,16 @@ static int exynos_drm_unload(struct drm_device *dev)

 static int exynos_drm_open(struct drm_device *dev, struct drm_file *file)
 {
+   struct drm_exynos_file_private *file_priv;
+
DRM_DEBUG_DRIVER("%s\n", __FILE__);

+   file_priv = kzalloc(sizeof(*file_priv), GFP_KERNEL);
+   if (!file_priv)
+   return -ENOMEM;
+
+   file->driver_priv = file_priv;
+
return exynos_drm_subdrv_open(dev, file);
 }

@@ -208,6 +217,13 @@ static struct drm_ioctl_desc exynos_ioctls[] = {
exynos_drm_gem_mmap_ioctl, DRM_UNLOCKED | DRM_AUTH),
DRM_IOCTL_DEF_DRV(EXYNOS_PLANE_SET_ZPOS, exynos_plane_set_zpos_ioctl,
DRM_UNLOCKED | DRM_AUTH),
+
+   DRM_IOCTL_DEF_DRV(EXYNOS_G2D_GET_VER,
+   exynos_g2d_get_ver_ioctl, DRM_UNLOCKED | DRM_AUTH),
+   DRM_IOCTL_DEF_DRV(EXYNOS_G2D_SET_CMDLIST,
+   exynos_g2d_set_cmdlist_ioctl, DRM_UNLOCKED | DRM_AUTH),
+   DRM_IOCTL_DEF_DRV(EXYNOS_G2D_EXEC,
+   exynos_g2d_exec_ioctl, DRM_UNLOCKED | DRM_AUTH),
 };

 static const struct file_operations exynos_drm_driver_fops = {
@@ -298,6 +314,12 @@ static int __init exynos_drm_init(void)
goto out_common_hdmi;
 #endif

+#ifdef CONFIG_DRM_EXYNOS_G2D
+   ret = platform_driver_register(_driver);
+   if (ret < 0)
+   goto out_g2d;
+#endif
+
ret = platform_driver_register(_drm_platform_driver);
if (ret < 0)
goto out;
@@ -305,6 +327,11 @@ static int __init exynos_drm_init(void)
return 0;

 out:
+#ifdef CONFIG_DRM_EXYNOS_G2D
+   platform_driver_unregister(_driver);
+out_g2d:
+#endif
+
 #ifdef CONFIG_DRM_EXYNOS_HDMI
platform_driver_unregister(_drm_common_hdmi_driver);
 out_common_hdmi:
@@ -327,6 +354,10 @@ static void __exit exynos_drm_exit(void)

platform_driver_unregister(_drm_platform_driver);

+#ifdef CONFIG_DRM_EXYNOS_G2D
+   platform_driver_unregister(_driver);
+#endif
+
 #ifdef CONFIG_DRM_EXYNOS_HDMI
platform_driver_unregister(_drm_common_hdmi_driver);
platform_driver_unregister(_driver);
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index b26c2f4..d7b50e5 100644
--- 

[PATCH 08/10] drm/exynos: add is_local member in exynos_drm_subdrv struct

[Inki Dae]

From: Joonyoung Shim 

The is_local member indicates unused subdrv such connector and encoder
so doesn't make resources for them.

Signed-off-by: Joonyoung Shim 
Signed-off-by: Inki Dae 
Signed-off-by: Kyungmin Park 
---
 drivers/gpu/drm/exynos/exynos_drm_core.c |3 +++
 drivers/gpu/drm/exynos/exynos_drm_drv.h  |2 ++
 2 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_core.c 
b/drivers/gpu/drm/exynos/exynos_drm_core.c
index 4e29c71..411832e 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_core.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_core.c
@@ -59,6 +59,9 @@ static int exynos_drm_subdrv_probe(struct drm_device *dev,
return ret;
}

+   if (subdrv->is_local)
+   return 0;
+
/* create and initialize a encoder for this sub driver. */
encoder = exynos_drm_encoder_create(dev, >manager,
(1 << MAX_CRTC) - 1);
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index a412454..b26c2f4 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -225,6 +225,7 @@ struct exynos_drm_private {
  * @list: sub driver has its own list object to register to exynos drm driver.
  * @drm_dev: pointer to drm_device and this pointer would be set
  * when sub driver calls exynos_drm_subdrv_register().
+ * @is_local: appear encoder and connector disrelated device.
  * @probe: this callback would be called by exynos drm driver after
  * subdrv is registered to it.
  * @remove: this callback is used to release resources created
@@ -239,6 +240,7 @@ struct exynos_drm_private {
 struct exynos_drm_subdrv {
struct list_head list;
struct drm_device *drm_dev;
+   bool is_local;

int (*probe)(struct drm_device *drm_dev, struct device *dev);
void (*remove)(struct drm_device *dev);
-- 
1.7.4.1

[PATCH 07/10] drm/exynos: add subdrv open/close functions

[Inki Dae]

From: Joonyoung Shim 

Some subdrv need open and close functions call when open and close drm.

Signed-off-by: Joonyoung Shim 
Signed-off-by: Inki Dae 
Signed-off-by: Kyungmin Park 
---
 drivers/gpu/drm/exynos/exynos_drm_core.c |   35 ++
 drivers/gpu/drm/exynos/exynos_drm_drv.c  |   10 
 drivers/gpu/drm/exynos/exynos_drm_drv.h  |9 +++
 3 files changed, 54 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_core.c 
b/drivers/gpu/drm/exynos/exynos_drm_core.c
index 937b059..4e29c71 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_core.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_core.c
@@ -175,3 +175,38 @@ int exynos_drm_subdrv_unregister(struct exynos_drm_subdrv 
*subdrv)
return 0;
 }
 EXPORT_SYMBOL_GPL(exynos_drm_subdrv_unregister);
+
+int exynos_drm_subdrv_open(struct drm_device *dev, struct drm_file *file)
+{
+   struct exynos_drm_subdrv *subdrv;
+   int ret;
+
+   list_for_each_entry(subdrv, _drm_subdrv_list, list) {
+   if (subdrv->open) {
+   ret = subdrv->open(dev, subdrv->manager.dev, file);
+   if (ret)
+   goto err;
+   }
+   }
+
+   return 0;
+
+err:
+   list_for_each_entry_reverse(subdrv, >list, list) {
+   if (subdrv->close)
+   subdrv->close(dev, subdrv->manager.dev, file);
+   }
+   return ret;
+}
+EXPORT_SYMBOL_GPL(exynos_drm_subdrv_open);
+
+void exynos_drm_subdrv_close(struct drm_device *dev, struct drm_file *file)
+{
+   struct exynos_drm_subdrv *subdrv;
+
+   list_for_each_entry(subdrv, _drm_subdrv_list, list) {
+   if (subdrv->close)
+   subdrv->close(dev, subdrv->manager.dev, file);
+   }
+}
+EXPORT_SYMBOL_GPL(exynos_drm_subdrv_close);
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index a2f8fae..b4e265f 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -144,6 +144,13 @@ static int exynos_drm_unload(struct drm_device *dev)
return 0;
 }

+static int exynos_drm_open(struct drm_device *dev, struct drm_file *file)
+{
+   DRM_DEBUG_DRIVER("%s\n", __FILE__);
+
+   return exynos_drm_subdrv_open(dev, file);
+}
+
 static void exynos_drm_preclose(struct drm_device *dev,
struct drm_file *file)
 {
@@ -163,6 +170,8 @@ static void exynos_drm_preclose(struct drm_device *dev,
}
}
spin_unlock_irqrestore(>event_lock, flags);
+
+   exynos_drm_subdrv_close(dev, file);
 }

 static void exynos_drm_postclose(struct drm_device *dev, struct drm_file *file)
@@ -216,6 +225,7 @@ static struct drm_driver exynos_drm_driver = {
  DRIVER_MODESET | DRIVER_GEM,
.load   = exynos_drm_load,
.unload = exynos_drm_unload,
+   .open   = exynos_drm_open,
.preclose   = exynos_drm_preclose,
.lastclose  = exynos_drm_lastclose,
.postclose  = exynos_drm_postclose,
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index f8bac0e..a412454 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -229,6 +229,8 @@ struct exynos_drm_private {
  * subdrv is registered to it.
  * @remove: this callback is used to release resources created
  * by probe callback.
+ * @open: this would be called with drm device file open.
+ * @close: this would be called with drm device file close.
  * @manager: subdrv has its own manager to control a hardware appropriately
  * and we can access a hardware drawing on this manager.
  * @encoder: encoder object owned by this sub driver.
@@ -240,6 +242,10 @@ struct exynos_drm_subdrv {

int (*probe)(struct drm_device *drm_dev, struct device *dev);
void (*remove)(struct drm_device *dev);
+   int (*open)(struct drm_device *drm_dev, struct device *dev,
+   struct drm_file *file);
+   void (*close)(struct drm_device *drm_dev, struct device *dev,
+   struct drm_file *file);

struct exynos_drm_manager manager;
struct drm_encoder *encoder;
@@ -269,6 +275,9 @@ int exynos_drm_subdrv_register(struct exynos_drm_subdrv 
*drm_subdrv);
 /* this function removes subdrv list from exynos drm driver */
 int exynos_drm_subdrv_unregister(struct exynos_drm_subdrv *drm_subdrv);

+int exynos_drm_subdrv_open(struct drm_device *dev, struct drm_file *file);
+void exynos_drm_subdrv_close(struct drm_device *dev, struct drm_file *file);
+
 extern struct platform_driver fimd_driver;
 extern struct platform_driver hdmi_driver;
 extern struct platform_driver mixer_driver;
-- 
1.7.4.1

[PATCH 06/10] drm/exynos: remove module of exynos drm subdrv

[Inki Dae]

From: Joonyoung Shim 

The exynos drm driver has several subdrv. They each can be module but it
causes unfixed probe order of exynodr drm driver and each subdrv. It
also needs some weird codes such as exynos_drm_fbdev_reinit and
exynos_drm_mode_group_reinit. This patch can remove weird codes and
clear codes through we doesn't modularity each subdrv.

Also this removes unnecessary codes related module.

Signed-off-by: Joonyoung Shim 
Signed-off-by: Inki Dae 
Signed-off-by: Kyungmin Park 
---
 drivers/gpu/drm/exynos/Kconfig|8 +--
 drivers/gpu/drm/exynos/Makefile   |   10 ++-
 drivers/gpu/drm/exynos/exynos_ddc.c   |1 -
 drivers/gpu/drm/exynos/exynos_drm_buf.c   |4 -
 drivers/gpu/drm/exynos/exynos_drm_connector.c |6 --
 drivers/gpu/drm/exynos/exynos_drm_core.c  |  112 ++---
 drivers/gpu/drm/exynos/exynos_drm_crtc.c  |6 --
 drivers/gpu/drm/exynos/exynos_drm_drv.c   |   52 +++-
 drivers/gpu/drm/exynos/exynos_drm_drv.h   |   12 ++--
 drivers/gpu/drm/exynos/exynos_drm_encoder.c   |6 --
 drivers/gpu/drm/exynos/exynos_drm_fb.c|6 --
 drivers/gpu/drm/exynos/exynos_drm_fbdev.c |   86 ---
 drivers/gpu/drm/exynos/exynos_drm_fimd.c  |   20 +
 drivers/gpu/drm/exynos/exynos_drm_gem.c   |4 -
 drivers/gpu/drm/exynos/exynos_drm_hdmi.c  |   87 +--
 drivers/gpu/drm/exynos/exynos_hdmi.c  |9 --
 drivers/gpu/drm/exynos/exynos_mixer.c |7 --
 17 files changed, 77 insertions(+), 359 deletions(-)

diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
index b9e5266..9a9850a 100644
--- a/drivers/gpu/drm/exynos/Kconfig
+++ b/drivers/gpu/drm/exynos/Kconfig
@@ -1,7 +1,6 @@
 config DRM_EXYNOS
tristate "DRM Support for Samsung SoC EXYNOS Series"
depends on DRM && PLAT_SAMSUNG
-   default n
select DRM_KMS_HELPER
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
@@ -12,16 +11,13 @@ config DRM_EXYNOS
  If M is selected the module will be called exynosdrm.

 config DRM_EXYNOS_FIMD
-   tristate "Exynos DRM FIMD"
+   bool "Exynos DRM FIMD"
depends on DRM_EXYNOS && !FB_S3C
-   default n
help
  Choose this option if you want to use Exynos FIMD for DRM.
- If M is selected, the module will be called exynos_drm_fimd

 config DRM_EXYNOS_HDMI
-   tristate "Exynos DRM HDMI"
+   bool "Exynos DRM HDMI"
depends on DRM_EXYNOS && !VIDEO_SAMSUNG_S5P_TV
help
  Choose this option if you want to use Exynos HDMI for DRM.
- If M is selected, the module will be called exynos_drm_hdmi
diff --git a/drivers/gpu/drm/exynos/Makefile b/drivers/gpu/drm/exynos/Makefile
index 395e69c..5331fa3 100644
--- a/drivers/gpu/drm/exynos/Makefile
+++ b/drivers/gpu/drm/exynos/Makefile
@@ -8,7 +8,9 @@ exynosdrm-y := exynos_drm_drv.o exynos_drm_encoder.o 
exynos_drm_connector.o \
exynos_drm_buf.o exynos_drm_gem.o exynos_drm_core.o \
exynos_drm_plane.o

-obj-$(CONFIG_DRM_EXYNOS) += exynosdrm.o
-obj-$(CONFIG_DRM_EXYNOS_FIMD) += exynos_drm_fimd.o
-obj-$(CONFIG_DRM_EXYNOS_HDMI) += exynos_hdmi.o exynos_mixer.o exynos_ddc.o \
-exynos_hdmiphy.o exynos_drm_hdmi.o
+exynosdrm-$(CONFIG_DRM_EXYNOS_FIMD)+= exynos_drm_fimd.o
+exynosdrm-$(CONFIG_DRM_EXYNOS_HDMI)+= exynos_hdmi.o exynos_mixer.o \
+  exynos_ddc.o exynos_hdmiphy.o \
+  exynos_drm_hdmi.o
+
+obj-$(CONFIG_DRM_EXYNOS)   += exynosdrm.o
diff --git a/drivers/gpu/drm/exynos/exynos_ddc.c 
b/drivers/gpu/drm/exynos/exynos_ddc.c
index 84b614f..7e1051d 100644
--- a/drivers/gpu/drm/exynos/exynos_ddc.c
+++ b/drivers/gpu/drm/exynos/exynos_ddc.c
@@ -55,4 +55,3 @@ struct i2c_driver ddc_driver = {
.remove = __devexit_p(s5p_ddc_remove),
.command= NULL,
 };
-EXPORT_SYMBOL(ddc_driver);
diff --git a/drivers/gpu/drm/exynos/exynos_drm_buf.c 
b/drivers/gpu/drm/exynos/exynos_drm_buf.c
index 554f674..0fb5ceb 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_buf.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_buf.c
@@ -211,7 +211,3 @@ void exynos_drm_buf_destroy(struct drm_device *dev,
kfree(buffer);
buffer = NULL;
 }
-
-MODULE_AUTHOR("Inki Dae ");
-MODULE_DESCRIPTION("Samsung SoC DRM Buffer Management Module");
-MODULE_LICENSE("GPL");
diff --git a/drivers/gpu/drm/exynos/exynos_drm_connector.c 
b/drivers/gpu/drm/exynos/exynos_drm_connector.c
index 303af60..33893a9 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_connector.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_connector.c
@@ -348,9 +348,3 @@ err_connector:
kfree(exynos_connector);
return NULL;
 }
-
-MODULE_AUTHOR("Inki Dae ");
-MODULE_AUTHOR("Joonyoung Shim ");
-MODULE_AUTHOR("Seung-Woo Kim ");
-MODULE_DESCRIPTION("Samsung 

[PATCH 05/10] drm/exynos: release pending pageflip events when closed

[Inki Dae]

From: Joonyoung Shim 

We should release pending pageflip events when closed. If not, they will
be dangling events.

Signed-off-by: Joonyoung Shim 
Signed-off-by: Inki Dae 
Signed-off-by: Kyungmin Park 
---
 drivers/gpu/drm/exynos/exynos_drm_drv.c |   14 ++
 1 files changed, 14 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index 09cc13f..aaa1b40 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -147,8 +147,22 @@ static int exynos_drm_unload(struct drm_device *dev)
 static void exynos_drm_preclose(struct drm_device *dev,
struct drm_file *file)
 {
+   struct exynos_drm_private *private = dev->dev_private;
+   struct drm_pending_vblank_event *e, *t;
+   unsigned long flags;
+
DRM_DEBUG_DRIVER("%s\n", __FILE__);

+   /* release events of current file */
+   spin_lock_irqsave(>event_lock, flags);
+   list_for_each_entry_safe(e, t, >pageflip_event_list,
+   base.link) {
+   if (e->base.file_priv == file) {
+   list_del(>base.link);
+   e->base.destroy(>base);
+   }
+   }
+   spin_unlock_irqrestore(>event_lock, flags);
 }

 static void exynos_drm_postclose(struct drm_device *dev, struct drm_file *file)
-- 
1.7.4.1

[PATCH 04/10] drm/exynos: added new funtion to get/put dma address.

[Inki Dae]

this function would be used for drm based 2d acceleration driver
to get/put dma address through gem handle.
when exynos_drm_get_dma_address is called reference count of
gem object would be increased not to be released by gem close and
when exynos_drm_put_dma_address is called the reference count of
this gem object would be decreased to be released.

Signed-off-by: Inki Dae 
Signed-off-by: Kyungmin Park 
---
 drivers/gpu/drm/exynos/exynos_drm_gem.c |   58 +++
 drivers/gpu/drm/exynos/exynos_drm_gem.h |   18 +
 2 files changed, 76 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c 
b/drivers/gpu/drm/exynos/exynos_drm_gem.c
index 36d081d..ddcb7e3 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
@@ -377,6 +377,64 @@ int exynos_drm_gem_create_ioctl(struct drm_device *dev, 
void *data,
return 0;
 }

+void *exynos_drm_gem_get_dma_addr(struct drm_device *dev,
+   unsigned int gem_handle,
+   struct drm_file *file_priv)
+{
+   struct exynos_drm_gem_obj *exynos_gem_obj;
+   struct drm_gem_object *obj;
+
+   obj = drm_gem_object_lookup(dev, file_priv, gem_handle);
+   if (!obj) {
+   DRM_ERROR("failed to lookup gem object.\n");
+   return ERR_PTR(-EINVAL);
+   }
+
+   exynos_gem_obj = to_exynos_gem_obj(obj);
+
+   if (exynos_gem_obj->flags & EXYNOS_BO_NONCONTIG) {
+   DRM_DEBUG_KMS("not support NONCONTIG type.\n");
+   drm_gem_object_unreference_unlocked(obj);
+
+   /* TODO */
+   return ERR_PTR(-EINVAL);
+   }
+
+   return _gem_obj->buffer->dma_addr;
+}
+
+void exynos_drm_gem_put_dma_addr(struct drm_device *dev,
+   unsigned int gem_handle,
+   struct drm_file *file_priv)
+{
+   struct exynos_drm_gem_obj *exynos_gem_obj;
+   struct drm_gem_object *obj;
+
+   obj = drm_gem_object_lookup(dev, file_priv, gem_handle);
+   if (!obj) {
+   DRM_ERROR("failed to lookup gem object.\n");
+   return;
+   }
+
+   exynos_gem_obj = to_exynos_gem_obj(obj);
+
+   if (exynos_gem_obj->flags & EXYNOS_BO_NONCONTIG) {
+   DRM_DEBUG_KMS("not support NONCONTIG type.\n");
+   drm_gem_object_unreference_unlocked(obj);
+
+   /* TODO */
+   return;
+   }
+
+   drm_gem_object_unreference_unlocked(obj);
+
+   /*
+* decrease obj->refcount one more time because we has already
+* increased it at exynos_drm_gem_get_dma_addr().
+*/
+   drm_gem_object_unreference_unlocked(obj);
+}
+
 int exynos_drm_gem_map_offset_ioctl(struct drm_device *dev, void *data,
struct drm_file *file_priv)
 {
diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.h 
b/drivers/gpu/drm/exynos/exynos_drm_gem.h
index 096267d..e40fbad 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gem.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_gem.h
@@ -88,6 +88,24 @@ struct exynos_drm_gem_obj *exynos_drm_gem_create(struct 
drm_device *dev,
 int exynos_drm_gem_create_ioctl(struct drm_device *dev, void *data,
struct drm_file *file_priv);

+/*
+ * get dma address from gem handle and this function could be used for
+ * other drivers such as 2d/3d acceleration drivers.
+ * with this function call, gem object reference count would be increased.
+ */
+void *exynos_drm_gem_get_dma_addr(struct drm_device *dev,
+   unsigned int gem_handle,
+   struct drm_file *file_priv);
+
+/*
+ * put dma address from gem handle and this function could be used for
+ * other drivers such as 2d/3d acceleration drivers.
+ * with this function call, gem object reference count would be decreased.
+ */
+void exynos_drm_gem_put_dma_addr(struct drm_device *dev,
+   unsigned int gem_handle,
+   struct drm_file *file_priv);
+
 /* get buffer offset to map to user space. */
 int exynos_drm_gem_map_offset_ioctl(struct drm_device *dev, void *data,
struct drm_file *file_priv);
-- 
1.7.4.1

[PATCH 03/10] drm/exynos: added buffer allocation type.

[Inki Dae]

with this patch, we can allocate physically continuous or non-continuous
memory and also it creates scatterlist for iommu support so allocated
memory region can be mapped to iommu page table using scatterlist.

Signed-off-by: Inki Dae 
Signed-off-by: Kyungmin Park 
---
 drivers/gpu/drm/exynos/exynos_drm_buf.c   |  148 +--
 drivers/gpu/drm/exynos/exynos_drm_buf.h   |4 +-
 drivers/gpu/drm/exynos/exynos_drm_fbdev.c |4 +-
 drivers/gpu/drm/exynos/exynos_drm_gem.c   |  284 ++---
 drivers/gpu/drm/exynos/exynos_drm_gem.h   |   11 +-
 include/drm/exynos_drm.h  |6 +
 6 files changed, 407 insertions(+), 50 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_buf.c 
b/drivers/gpu/drm/exynos/exynos_drm_buf.c
index 3cf785c..554f674 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_buf.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_buf.c
@@ -25,45 +25,151 @@

 #include "drmP.h"
 #include "drm.h"
+#include "exynos_drm.h"

 #include "exynos_drm_drv.h"
 #include "exynos_drm_gem.h"
 #include "exynos_drm_buf.h"

 static int lowlevel_buffer_allocate(struct drm_device *dev,
-   struct exynos_drm_gem_buf *buffer)
+   unsigned int flags, struct exynos_drm_gem_buf *buf)
 {
+   int ret = 0;
+
DRM_DEBUG_KMS("%s\n", __FILE__);

-   buffer->kvaddr = dma_alloc_writecombine(dev->dev, buffer->size,
-   >dma_addr, GFP_KERNEL);
-   if (!buffer->kvaddr) {
-   DRM_ERROR("failed to allocate buffer.\n");
-   return -ENOMEM;
+   /*
+* allocate only physically continuous memory and
+* non-continuous memory would be allocated by exynos
+* gem framework.
+*/
+   if (!(flags & EXYNOS_BO_NONCONTIG)) {
+   dma_addr_t start_addr, end_addr;
+   unsigned int npages, page_size, i = 0;
+   struct scatterlist *sgl;
+
+   if (buf->dma_addr) {
+   DRM_DEBUG_KMS("already allocated.\n");
+   return -EINVAL;
+   }
+
+   /*
+* according to desired size, it sets page size
+* for performance with using iommu so physically
+* continuous memory could be mapped to iommu in
+* multiple page size.
+*/
+   if (buf->size >= SZ_1M) {
+   npages = (buf->size >> SECTION_SHIFT) + 1;
+   page_size = SECTION_SIZE;
+   } else if (buf->size >= SZ_64K) {
+   npages = (buf->size >> 16) + 1;
+   page_size = SZ_64K;
+   } else {
+   npages = (buf->size >> PAGE_SHIFT) + 1;
+   page_size = PAGE_SIZE;
+   }
+
+   buf->sgt = kzalloc(sizeof(struct sg_table), GFP_KERNEL);
+   if (!buf->sgt) {
+   DRM_ERROR("failed to allocate sg table.\n");
+   return -ENOMEM;
+   }
+
+   ret = sg_alloc_table(buf->sgt, npages, GFP_KERNEL);
+   if (ret < 0) {
+   DRM_ERROR("failed to initialize sg table.\n");
+   kfree(buf->sgt);
+   buf->sgt = NULL;
+   return -ENOMEM;
+   }
+
+   buf->kvaddr = dma_alloc_writecombine(dev->dev, buf->size,
+   >dma_addr, GFP_KERNEL);
+   if (!buf->kvaddr) {
+   DRM_ERROR("failed to allocate buffer.\n");
+   ret = -ENOMEM;
+   goto err1;
+   }
+
+   start_addr = buf->dma_addr;
+   end_addr = buf->dma_addr + buf->size;
+
+   buf->pages = kzalloc(sizeof(struct page) * npages, GFP_KERNEL);
+   if (!buf->pages) {
+   DRM_ERROR("failed to allocate pages.\n");
+   ret = -ENOMEM;
+   goto err2;
+   }
+
+   sgl = buf->sgt->sgl;
+
+   while (i < npages) {
+   buf->pages[i] = phys_to_page(start_addr);
+   sg_set_page(sgl, buf->pages[i], page_size, 0);
+   sg_dma_address(sgl) = start_addr;
+   start_addr += page_size;
+   if (end_addr - start_addr < page_size)
+   break;
+   sgl = sg_next(sgl);
+   i++;
+   }
+
+   buf->pages[i] = phys_to_page(start_addr);
+
+   sgl = sg_next(sgl);
+   sg_set_page(sgl, buf->pages[i+1], end_addr - start_addr, 0);
}

DRM_DEBUG_KMS("vaddr(0x%lx), dma_addr(0x%lx), size(0x%lx)\n",
-   (unsigned long)buffer->kvaddr,
-   (unsigned long)buffer->dma_addr,
-   buffer->size);
-
- 

[PATCH 02/10] drm/exynos: added mode_fixup feature and code clean.

[Inki Dae]

this patch adds mode_fixup feature for hdmi module that
specific driver changes current mode to driver desired mode
properly.

Signed-off-by: Inki Dae 
Signed-off-by: Kyungmin Park 
---
 drivers/gpu/drm/exynos/exynos_drm_connector.c |   25 +++-
 drivers/gpu/drm/exynos/exynos_drm_crtc.c  |6 ++-
 drivers/gpu/drm/exynos/exynos_drm_drv.h   |8 +++
 drivers/gpu/drm/exynos/exynos_drm_encoder.c   |   17 -
 drivers/gpu/drm/exynos/exynos_drm_hdmi.c  |   28 +
 drivers/gpu/drm/exynos/exynos_drm_hdmi.h  |5 ++
 drivers/gpu/drm/exynos/exynos_hdmi.c  |   81 ++--
 7 files changed, 157 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_connector.c 
b/drivers/gpu/drm/exynos/exynos_drm_connector.c
index 99d5527..303af60 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_connector.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_connector.c
@@ -225,6 +225,29 @@ static struct drm_connector_helper_funcs 
exynos_connector_helper_funcs = {
.best_encoder   = exynos_drm_best_encoder,
 };

+static int exynos_drm_connector_fill_modes(struct drm_connector *connector,
+   unsigned int max_width, unsigned int max_height)
+{
+   struct exynos_drm_connector *exynos_connector =
+   to_exynos_connector(connector);
+   struct exynos_drm_manager *manager = exynos_connector->manager;
+   struct exynos_drm_manager_ops *ops = manager->ops;
+   unsigned int width, height;
+
+   width = max_width;
+   height = max_height;
+
+   /*
+* if specific driver want to find desired_mode using maxmum
+* resolution then get max width and height from that driver.
+*/
+   if (ops && ops->get_max_resol)
+   ops->get_max_resol(manager->dev, , );
+
+   return drm_helper_probe_single_connector_modes(connector, width,
+   height);
+}
+
 /* get detection status of display device. */
 static enum drm_connector_status
 exynos_drm_connector_detect(struct drm_connector *connector, bool force)
@@ -262,7 +285,7 @@ static void exynos_drm_connector_destroy(struct 
drm_connector *connector)

 static struct drm_connector_funcs exynos_connector_funcs = {
.dpms   = drm_helper_connector_dpms,
-   .fill_modes = drm_helper_probe_single_connector_modes,
+   .fill_modes = exynos_drm_connector_fill_modes,
.detect = exynos_drm_connector_detect,
.destroy= exynos_drm_connector_destroy,
 };
diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c 
b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index de81883..2d9a0e6 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -249,7 +249,11 @@ exynos_drm_crtc_mode_set(struct drm_crtc *crtc, struct 
drm_display_mode *mode,
 {
DRM_DEBUG_KMS("%s\n", __FILE__);

-   mode = adjusted_mode;
+   /*
+* copy the mode data adjusted by mode_fixup() into crtc->mode
+* so that hardware can be seet to proper mode.
+*/
+   memcpy(>mode, adjusted_mode, sizeof(*adjusted_mode));

return exynos_drm_crtc_update(crtc);
 }
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index 13540de..4115a9f 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -155,8 +155,10 @@ struct exynos_drm_display_ops {
  *
  * @dpms: control device power.
  * @apply: set timing, vblank and overlay data to registers.
+ * @mode_fixup: fix mode data comparing to hw specific display mode.
  * @mode_set: convert drm_display_mode to hw specific display mode and
  *   would be called by encoder->mode_set().
+ * @get_max_resol: get maximum resolution to specific hardware.
  * @commit: set current hw specific display mode to hw.
  * @enable_vblank: specific driver callback for enabling vblank interrupt.
  * @disable_vblank: specific driver callback for disabling vblank interrupt.
@@ -164,7 +166,13 @@ struct exynos_drm_display_ops {
 struct exynos_drm_manager_ops {
void (*dpms)(struct device *subdrv_dev, int mode);
void (*apply)(struct device *subdrv_dev);
+   void (*mode_fixup)(struct device *subdrv_dev,
+   struct drm_connector *connector,
+   struct drm_display_mode *mode,
+   struct drm_display_mode *adjusted_mode);
void (*mode_set)(struct device *subdrv_dev, void *mode);
+   void (*get_max_resol)(struct device *subdrv_dev, unsigned int *width,
+   unsigned int *height);
void (*commit)(struct device *subdrv_dev);
int (*enable_vblank)(struct device *subdrv_dev);
void (*disable_vblank)(struct device *subdrv_dev);
diff --git a/drivers/gpu/drm/exynos/exynos_drm_encoder.c 

[PATCH 01/10] drm/exynos: add HDMI version 1.4 support

[Inki Dae]

Later Exynos series from Exynos4X12 support HDMI version 1.4. We will
distinguish to use which version via platform data.

Signed-off-by: Joonyoung Shim 
Signed-off-by: Inki Dae 
Signed-off-by: Kyungmin Park 
---
 drivers/gpu/drm/exynos/exynos_hdmi.c | 1152 +++---
 drivers/gpu/drm/exynos/exynos_hdmi.h |   10 +-
 drivers/gpu/drm/exynos/regs-hdmi.h   |  306 --
 include/drm/exynos_drm.h |2 +
 4 files changed, 1325 insertions(+), 145 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 3429d3f..1cfe86e 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -43,42 +43,43 @@
 #define HDMI_OVERLAY_NUMBER3
 #define get_hdmi_context(dev)  platform_get_drvdata(to_platform_device(dev))

-static const u8 hdmiphy_conf27[32] = {
+/* HDMI Version 1.3 */
+static const u8 hdmiphy_v13_conf27[32] = {
0x01, 0x05, 0x00, 0xD8, 0x10, 0x1C, 0x30, 0x40,
0x6B, 0x10, 0x02, 0x51, 0xDF, 0xF2, 0x54, 0x87,
0x84, 0x00, 0x30, 0x38, 0x00, 0x08, 0x10, 0xE0,
0x22, 0x40, 0xE3, 0x26, 0x00, 0x00, 0x00, 0x00,
 };

-static const u8 hdmiphy_conf27_027[32] = {
+static const u8 hdmiphy_v13_conf27_027[32] = {
0x01, 0x05, 0x00, 0xD4, 0x10, 0x9C, 0x09, 0x64,
0x6B, 0x10, 0x02, 0x51, 0xDF, 0xF2, 0x54, 0x87,
0x84, 0x00, 0x30, 0x38, 0x00, 0x08, 0x10, 0xE0,
0x22, 0x40, 0xE3, 0x26, 0x00, 0x00, 0x00, 0x00,
 };

-static const u8 hdmiphy_conf74_175[32] = {
+static const u8 hdmiphy_v13_conf74_175[32] = {
0x01, 0x05, 0x00, 0xD8, 0x10, 0x9C, 0xef, 0x5B,
0x6D, 0x10, 0x01, 0x51, 0xef, 0xF3, 0x54, 0xb9,
0x84, 0x00, 0x30, 0x38, 0x00, 0x08, 0x10, 0xE0,
0x22, 0x40, 0xa5, 0x26, 0x01, 0x00, 0x00, 0x00,
 };

-static const u8 hdmiphy_conf74_25[32] = {
+static const u8 hdmiphy_v13_conf74_25[32] = {
0x01, 0x05, 0x00, 0xd8, 0x10, 0x9c, 0xf8, 0x40,
0x6a, 0x10, 0x01, 0x51, 0xff, 0xf1, 0x54, 0xba,
0x84, 0x00, 0x10, 0x38, 0x00, 0x08, 0x10, 0xe0,
0x22, 0x40, 0xa4, 0x26, 0x01, 0x00, 0x00, 0x00,
 };

-static const u8 hdmiphy_conf148_5[32] = {
+static const u8 hdmiphy_v13_conf148_5[32] = {
0x01, 0x05, 0x00, 0xD8, 0x10, 0x9C, 0xf8, 0x40,
0x6A, 0x18, 0x00, 0x51, 0xff, 0xF1, 0x54, 0xba,
0x84, 0x00, 0x10, 0x38, 0x00, 0x08, 0x10, 0xE0,
0x22, 0x40, 0xa4, 0x26, 0x02, 0x00, 0x00, 0x00,
 };

-struct hdmi_tg_regs {
+struct hdmi_v13_tg_regs {
u8 cmd;
u8 h_fsz_l;
u8 h_fsz_h;
@@ -110,7 +111,7 @@ struct hdmi_tg_regs {
u8 field_bot_hdmi_h;
 };

-struct hdmi_core_regs {
+struct hdmi_v13_core_regs {
u8 h_blank[2];
u8 v_blank[3];
u8 h_v_line[3];
@@ -123,12 +124,21 @@ struct hdmi_core_regs {
u8 v_sync_gen3[3];
 };

-struct hdmi_preset_conf {
-   struct hdmi_core_regs core;
-   struct hdmi_tg_regs tg;
+struct hdmi_v13_preset_conf {
+   struct hdmi_v13_core_regs core;
+   struct hdmi_v13_tg_regs tg;
+};
+
+struct hdmi_v13_conf {
+   int width;
+   int height;
+   int vrefresh;
+   bool interlace;
+   const u8 *hdmiphy_data;
+   const struct hdmi_v13_preset_conf *conf;
 };

-static const struct hdmi_preset_conf hdmi_conf_480p = {
+static const struct hdmi_v13_preset_conf hdmi_v13_conf_480p = {
.core = {
.h_blank = {0x8a, 0x00},
.v_blank = {0x0d, 0x6a, 0x01},
@@ -154,7 +164,7 @@ static const struct hdmi_preset_conf hdmi_conf_480p = {
},
 };

-static const struct hdmi_preset_conf hdmi_conf_720p60 = {
+static const struct hdmi_v13_preset_conf hdmi_v13_conf_720p60 = {
.core = {
.h_blank = {0x72, 0x01},
.v_blank = {0xee, 0xf2, 0x00},
@@ -182,7 +192,7 @@ static const struct hdmi_preset_conf hdmi_conf_720p60 = {
},
 };

-static const struct hdmi_preset_conf hdmi_conf_1080i50 = {
+static const struct hdmi_v13_preset_conf hdmi_v13_conf_1080i50 = {
.core = {
.h_blank = {0xd0, 0x02},
.v_blank = {0x32, 0xB2, 0x00},
@@ -210,7 +220,7 @@ static const struct hdmi_preset_conf hdmi_conf_1080i50 = {
},
 };

-static const struct hdmi_preset_conf hdmi_conf_1080p50 = {
+static const struct hdmi_v13_preset_conf hdmi_v13_conf_1080p50 = {
.core = {
.h_blank = {0xd0, 0x02},
.v_blank = {0x65, 0x6c, 0x01},
@@ -238,7 +248,7 @@ static const struct hdmi_preset_conf hdmi_conf_1080p50 = {
},
 };

-static const struct hdmi_preset_conf hdmi_conf_1080i60 = {
+static const struct hdmi_v13_preset_conf hdmi_v13_conf_1080i60 = {
.core = {
.h_blank = {0x18, 0x01},
.v_blank = {0x32, 0xB2, 0x00},
@@ -266,7 +276,7 @@ static const struct hdmi_preset_conf hdmi_conf_1080i60 = {
},
 };

-static const struct hdmi_preset_conf hdmi_conf_1080p60 = {
+static const struct hdmi_v13_preset_conf 

[PATCH 00/10] updated exynos-drm-next

[Inki Dae]

Hi, Dave and all.

this patch set includes the following features.
- add HDMI version 1.4 support.
- add mode_fixup feature.
  . hdmi module would change current mode to driver desired mode properly.
- add buffer alloction type.
  . we can allocate physically continuous or non-continuous
memory and also it creates scatterlist for iommu support so allocated
memory region can be mapped to iommu page table using scatterlist.
- add dma address get/put interface.
  . this function would be used for drm based 2d acceleration driver
to get/put dma address through gem handle.
when exynos_drm_get_dma_address is called reference count of
gem object would be increased not to be released by gem close and
when exynos_drm_put_dma_address is called the reference count of
this gem object would be decreased to be released.
- add virtual display driver.
  . this driver would be used for wireless display.
- add direct rendering based 2d graphics acceleration module.
  . exynos SoC chip has fimg2d named 2d graphics accelerator and this driver
supports only exynos4x12 series.


this patch set is based on git repository below:
git://git.infradead.org/users/kmpark/linux-samsung exynos-drm-fixes
commit-id: f6d69d1e77509d71c29f2a7b119214b8fdf86ae2

and exynos-drm-fixes is based on git repository below:
git://people.freedesktop.org/~airlied/linux.git drm-fixes
commit-id: 38aa4a568ba4c3ccba83e862a01e3e60e3b811ee

P.S.
drm-next doesn't reflect updated latest codes of mainline so this patch set
should be merged to drm-next after latest mainline codes are merged to
drm-next. now is just for review and if latest codes are merged to drm-next
then I will merge this patch set to exynos-drm-next for git pull request.

Thanks.

Inki Dae (5):
  drm/exynos: add HDMI version 1.4 support
  drm/exynos: added mode_fixup feature and code clean.
  drm/exynos: added buffer allocation type.
  drm/exynos: added new funtion to get/put dma address.
  drm/exynos: added virtual display driver.

Joonyoung Shim (5):
  drm/exynos: release pending pageflip events when closed
  drm/exynos: remove module of exynos drm subdrv
  drm/exynos: add subdrv open/close functions
  drm/exynos: add is_local member in exynos_drm_subdrv struct
  drm/exynos: add G2D driver

 drivers/gpu/drm/exynos/Kconfig|   20 +-
 drivers/gpu/drm/exynos/Makefile   |   12 +-
 drivers/gpu/drm/exynos/exynos_ddc.c   |1 -
 drivers/gpu/drm/exynos/exynos_drm_buf.c   |  152 +++-
 drivers/gpu/drm/exynos/exynos_drm_buf.h   |4 +-
 drivers/gpu/drm/exynos/exynos_drm_connector.c |   35 +-
 drivers/gpu/drm/exynos/exynos_drm_core.c  |  140 +--
 drivers/gpu/drm/exynos/exynos_drm_crtc.c  |   12 +-
 drivers/gpu/drm/exynos/exynos_drm_drv.c   |  125 +++-
 drivers/gpu/drm/exynos/exynos_drm_drv.h   |   49 +-
 drivers/gpu/drm/exynos/exynos_drm_encoder.c   |   24 +-
 drivers/gpu/drm/exynos/exynos_drm_fb.c|6 -
 drivers/gpu/drm/exynos/exynos_drm_fbdev.c |   90 +--
 drivers/gpu/drm/exynos/exynos_drm_fimd.c  |   20 +-
 drivers/gpu/drm/exynos/exynos_drm_g2d.c   |  864 +
 drivers/gpu/drm/exynos/exynos_drm_g2d.h   |   36 +
 drivers/gpu/drm/exynos/exynos_drm_gem.c   |  346 +++-
 drivers/gpu/drm/exynos/exynos_drm_gem.h   |   29 +-
 drivers/gpu/drm/exynos/exynos_drm_hdmi.c  |  115 +--
 drivers/gpu/drm/exynos/exynos_drm_hdmi.h  |5 +
 drivers/gpu/drm/exynos/exynos_drm_vidi.c  |  677 ++
 drivers/gpu/drm/exynos/exynos_drm_vidi.h  |   36 +
 drivers/gpu/drm/exynos/exynos_hdmi.c  | 1234 ++---
 drivers/gpu/drm/exynos/exynos_hdmi.h  |   10 +-
 drivers/gpu/drm/exynos/exynos_mixer.c |7 -
 drivers/gpu/drm/exynos/regs-hdmi.h|  306 ++-
 include/drm/exynos_drm.h  |   84 ++
 27 files changed, 3879 insertions(+), 560 deletions(-)
 create mode 100644 drivers/gpu/drm/exynos/exynos_drm_g2d.c
 create mode 100644 drivers/gpu/drm/exynos/exynos_drm_g2d.h
 create mode 100644 drivers/gpu/drm/exynos/exynos_drm_vidi.c
 create mode 100644 drivers/gpu/drm/exynos/exynos_drm_vidi.h

-- 
1.7.4.1

[DEBUG PATCH] Print a message when a spurious i2c SCL timeout occurs.

[Ville Syrjälä]

A quick hack to verify that the fix works as intended...

Do not apply.

---
 drivers/i2c/algos/i2c-algo-bit.c |6 ++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/drivers/i2c/algos/i2c-algo-bit.c b/drivers/i2c/algos/i2c-algo-bit.c
index d25112e..3f547b5 100644
--- a/drivers/i2c/algos/i2c-algo-bit.c
+++ b/drivers/i2c/algos/i2c-algo-bit.c
@@ -89,6 +89,7 @@ static inline void scllo(struct i2c_algo_bit_data *adap)
 static int sclhi(struct i2c_algo_bit_data *adap)
 {
unsigned long start;
+   bool timeout = false;
 
setscl(adap, 1);
 
@@ -104,11 +105,16 @@ static int sclhi(struct i2c_algo_bit_data *adap)
 * are processing data internally.
 */
if (time_after(jiffies, start + adap-timeout))
+   {
+   timeout = true;
break;
+   }
cond_resched();
}
if (!getscl(adap))
return -ETIMEDOUT;
+   if (timeout)
+   printk(KERN_CRIT spurious i2c scl timeout\n);
 #ifdef DEBUG
if (jiffies != start  i2c_debug = 3)
pr_debug(i2c-algo-bit: needed %ld jiffies for SCL to go 
-- 
1.7.3.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] i2c-algo-bit: Fix spurious SCL timeouts under heavy load

[Ville Syrjälä]

When the system is under heavy load, there can be a significant delay
between the getscl() and time_after() calls inside sclhi(). That delay
may cause the time_after() check to trigger after SCL has gone high,
causing sclhi() to return -ETIMEDOUT.

To fix the problem, double check that SCL is still low after the
timeout has been reached, before deciding to return -ETIMEDOUT.

Signed-off-by: Ville Syrjälä syrj...@sci.fi
---
I can easily reproduce these spurious timeouts on my HP-compaq nc6000
laptop with the radeon kms driver. It's enough to have a -j2 kernel
build running, and simultaneosly issue xrandr commands in a
terminal. Calling xrandr will cause the driver to re-read the EDID
from the display. A significant number of the EDID reads will fail.
With this fix I have yet to see any failed EDID reads.

 drivers/i2c/algos/i2c-algo-bit.c |4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/drivers/i2c/algos/i2c-algo-bit.c b/drivers/i2c/algos/i2c-algo-bit.c
index 525c734..d25112e 100644
--- a/drivers/i2c/algos/i2c-algo-bit.c
+++ b/drivers/i2c/algos/i2c-algo-bit.c
@@ -104,9 +104,11 @@ static int sclhi(struct i2c_algo_bit_data *adap)
 * are processing data internally.
 */
if (time_after(jiffies, start + adap-timeout))
-   return -ETIMEDOUT;
+   break;
cond_resched();
}
+   if (!getscl(adap))
+   return -ETIMEDOUT;
 #ifdef DEBUG
if (jiffies != start  i2c_debug = 3)
pr_debug(i2c-algo-bit: needed %ld jiffies for SCL to go 
-- 
1.7.3.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/2] gma500: Fix resume paths

[Alan Cox]

From: Alan Cox a...@linux.intel.com

We fall apart somewhat on resume because we don't invoke all the resume
methods as we should. Fix the silly error in the logic.

Signed-off-by: Alan Cox a...@linux.intel.com
---

 drivers/gpu/drm/gma500/power.c |3 ---
 1 files changed, 0 insertions(+), 3 deletions(-)


diff --git a/drivers/gpu/drm/gma500/power.c b/drivers/gpu/drm/gma500/power.c
index 994f669..8d23c45 100644
--- a/drivers/gpu/drm/gma500/power.c
+++ b/drivers/gpu/drm/gma500/power.c
@@ -102,9 +102,6 @@ static void gma_resume_display(struct pci_dev *pdev)
struct drm_device *dev = pci_get_drvdata(pdev);
struct drm_psb_private *dev_priv = dev-dev_private;
 
-   if (dev_priv-suspended == false)
-   return;
-
/* turn on the display power island */
dev_priv-ops-power_up(dev);
dev_priv-suspended = false;

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/2] gma500: suspend/resume support for Cedartrail

[Alan Cox]

From: Alan Cox a...@linux.intel.com

Update our tree to match the current driver head.

Signed-off-by: Alan Cox a...@linux.intel.com
---

 drivers/gpu/drm/gma500/cdv_device.c|  169 
 drivers/gpu/drm/gma500/power.c |3 -
 drivers/gpu/drm/gma500/psb_drv.h   |   20 
 drivers/gpu/drm/gma500/psb_intel_reg.h |9 ++
 4 files changed, 181 insertions(+), 20 deletions(-)


diff --git a/drivers/gpu/drm/gma500/cdv_device.c 
b/drivers/gpu/drm/gma500/cdv_device.c
index 4a5b099..eefcef6 100644
--- a/drivers/gpu/drm/gma500/cdv_device.c
+++ b/drivers/gpu/drm/gma500/cdv_device.c
@@ -202,13 +202,12 @@ static inline void CDV_MSG_WRITE32(uint port, uint 
offset, u32 value)
pci_dev_put(pci_root);
 }
 
-#define PSB_APM_CMD0x0
-#define PSB_APM_STS0x04
 #define PSB_PM_SSC 0x20
 #define PSB_PM_SSS 0x30
-#define PSB_PWRGT_GFX_MASK 0x3
-#define CDV_PWRGT_DISPLAY_CNTR 0x000fc00c
-#define CDV_PWRGT_DISPLAY_STS  0x000fc00c
+#define PSB_PWRGT_GFX_ON   0x02
+#define PSB_PWRGT_GFX_OFF  0x01
+#define PSB_PWRGT_GFX_D0   0x00
+#define PSB_PWRGT_GFX_D3   0x03
 
 static void cdv_init_pm(struct drm_device *dev)
 {
@@ -221,26 +220,22 @@ static void cdv_init_pm(struct drm_device *dev)
dev_priv-ospm_base = CDV_MSG_READ32(PSB_PUNIT_PORT,
PSB_OSPMBA)  0x;
 
-   /* Force power on for now */
+   /* Power status */
pwr_cnt = inl(dev_priv-apm_base + PSB_APM_CMD);
-   pwr_cnt = ~PSB_PWRGT_GFX_MASK;
 
+   /* Enable the GPU */
+   pwr_cnt = ~PSB_PWRGT_GFX_MASK;
+   pwr_cnt |= PSB_PWRGT_GFX_ON;
outl(pwr_cnt, dev_priv-apm_base + PSB_APM_CMD);
+
+   /* Wait for the GPU power */
for (i = 0; i  5; i++) {
u32 pwr_sts = inl(dev_priv-apm_base + PSB_APM_STS);
if ((pwr_sts  PSB_PWRGT_GFX_MASK) == 0)
-   break;
-   udelay(10);
-   }
-   pwr_cnt = inl(dev_priv-ospm_base + PSB_PM_SSC);
-   pwr_cnt = ~CDV_PWRGT_DISPLAY_CNTR;
-   outl(pwr_cnt, dev_priv-ospm_base + PSB_PM_SSC);
-   for (i = 0; i  5; i++) {
-   u32 pwr_sts = inl(dev_priv-ospm_base + PSB_PM_SSS);
-   if ((pwr_sts  CDV_PWRGT_DISPLAY_STS) == 0)
-   break;
+   return;
udelay(10);
}
+   dev_err(dev-dev, GPU: power management timed out.\n);
 }
 
 /**
@@ -249,11 +244,50 @@ static void cdv_init_pm(struct drm_device *dev)
  *
  * Save the state we need in order to be able to restore the interface
  * upon resume from suspend
- *
- * FIXME: review
  */
 static int cdv_save_display_registers(struct drm_device *dev)
 {
+   struct drm_psb_private *dev_priv = dev-dev_private;
+   struct psb_save_area *regs = dev_priv-regs;
+   struct drm_connector *connector;
+
+   dev_info(dev-dev, Saving GPU registers.\n);
+
+   pci_read_config_byte(dev-pdev, 0xF4, regs-cdv.saveLBB);
+
+   regs-cdv.saveDSPCLK_GATE_D = REG_READ(DSPCLK_GATE_D);
+   regs-cdv.saveRAMCLK_GATE_D = REG_READ(RAMCLK_GATE_D);
+
+   regs-cdv.saveDSPARB = REG_READ(DSPARB);
+   regs-cdv.saveDSPFW[0] = REG_READ(DSPFW1);
+   regs-cdv.saveDSPFW[1] = REG_READ(DSPFW2);
+   regs-cdv.saveDSPFW[2] = REG_READ(DSPFW3);
+   regs-cdv.saveDSPFW[3] = REG_READ(DSPFW4);
+   regs-cdv.saveDSPFW[4] = REG_READ(DSPFW5);
+   regs-cdv.saveDSPFW[5] = REG_READ(DSPFW6);
+
+   regs-cdv.saveADPA = REG_READ(ADPA);
+
+   regs-cdv.savePP_CONTROL = REG_READ(PP_CONTROL);
+   regs-cdv.savePFIT_PGM_RATIOS = REG_READ(PFIT_PGM_RATIOS);
+   regs-saveBLC_PWM_CTL = REG_READ(BLC_PWM_CTL);
+   regs-saveBLC_PWM_CTL2 = REG_READ(BLC_PWM_CTL2);
+   regs-cdv.saveLVDS = REG_READ(LVDS);
+
+   regs-cdv.savePFIT_CONTROL = REG_READ(PFIT_CONTROL);
+
+   regs-cdv.savePP_ON_DELAYS = REG_READ(PP_ON_DELAYS);
+   regs-cdv.savePP_OFF_DELAYS = REG_READ(PP_OFF_DELAYS);
+   regs-cdv.savePP_CYCLE = REG_READ(PP_CYCLE);
+
+   regs-cdv.saveVGACNTRL = REG_READ(VGACNTRL);
+
+   regs-cdv.saveIER = REG_READ(PSB_INT_ENABLE_R);
+   regs-cdv.saveIMR = REG_READ(PSB_INT_MASK_R);
+
+   list_for_each_entry(connector, dev-mode_config.connector_list, head)
+   connector-funcs-dpms(connector, DRM_MODE_DPMS_OFF);
+
return 0;
 }
 
@@ -267,16 +301,113 @@ static int cdv_save_display_registers(struct drm_device 
*dev)
  */
 static int cdv_restore_display_registers(struct drm_device *dev)
 {
+   struct drm_psb_private *dev_priv = dev-dev_private;
+   struct psb_save_area *regs = dev_priv-regs;
+   struct drm_connector *connector;
+   u32 temp;
+
+   pci_write_config_byte(dev-pdev, 0xF4, regs-cdv.saveLBB);
+
+   REG_WRITE(DSPCLK_GATE_D, regs-cdv.saveDSPCLK_GATE_D);
+   

[Bug 42876] System doesn't boot with GTX 550 Ti

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=42876


legia le...@klikni.cz changed:

   What|Removed |Added

 CC||le...@klikni.cz




--- Comment #2 from legia le...@klikni.cz  2012-03-14 12:31:58 ---
I have the same problem. No boot with 3.2.x kernel(Debian, Fedora).

C2D
Asus P5Q-E
GeForce 550 Ti

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] omap2+: add drm device

[Tomi Valkeinen]

Hi,

On Tue, 2012-03-13 at 15:34 -0500, Rob Clark wrote:
 From: Andy Gross andy.gr...@ti.com
 
 Register OMAP DRM/KMS platform device, and reserve a CMA region for
 the device to use for buffer allocation.  DMM is split into a
 separate device using hwmod.

What's the diff with this and the previous one?

I see you still have the platform data there. You didn't comment on
that. Where is it used after the board files are gone when we use DT?

And how about the size of the contiguous memory area, it was left a bit
unclear to me why it cannot be dynamic.

 Tomi



signature.asc
Description: This is a digitally signed message part
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] omap2+: add drm device

[Rob Clark]

On Wed, Mar 14, 2012 at 7:38 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
 Hi,

 On Tue, 2012-03-13 at 15:34 -0500, Rob Clark wrote:
 From: Andy Gross andy.gr...@ti.com

 Register OMAP DRM/KMS platform device, and reserve a CMA region for
 the device to use for buffer allocation.  DMM is split into a
 separate device using hwmod.

 What's the diff with this and the previous one?

Moving drm.c to mach-omap2 (header could not move because
omap_reserve() is in plat-omap.. but this seems to be the same as what
is done for dspbridge).

 I see you still have the platform data there. You didn't comment on
 that. Where is it used after the board files are gone when we use DT?

I was kind-of thinking that there would be some DT-data-structure
glue somewhere.. not sure if this goes in mach-omap2 or in the driver
itself, but presumably it is needed somewhere.

It is only really special cases where some board specific device-tree
data is needed, so it seems like this is ok to handle later.

 And how about the size of the contiguous memory area, it was left a bit
 unclear to me why it cannot be dynamic.

I don't think there is anything preventing adding a bootarg, but I
think it is not essential so ok to add later

BR,
-R

  Tomi

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] omap2+: add drm device

[Tomi Valkeinen]

On Wed, 2012-03-14 at 07:55 -0500, Rob Clark wrote:
 On Wed, Mar 14, 2012 at 7:38 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
  Hi,
 
  On Tue, 2012-03-13 at 15:34 -0500, Rob Clark wrote:
  From: Andy Gross andy.gr...@ti.com
 
  Register OMAP DRM/KMS platform device, and reserve a CMA region for
  the device to use for buffer allocation.  DMM is split into a
  separate device using hwmod.
 
  What's the diff with this and the previous one?
 
 Moving drm.c to mach-omap2 (header could not move because
 omap_reserve() is in plat-omap.. but this seems to be the same as what
 is done for dspbridge).
 
  I see you still have the platform data there. You didn't comment on
  that. Where is it used after the board files are gone when we use DT?
 
 I was kind-of thinking that there would be some DT-data-structure
 glue somewhere.. not sure if this goes in mach-omap2 or in the driver
 itself, but presumably it is needed somewhere.
 
 It is only really special cases where some board specific device-tree
 data is needed, so it seems like this is ok to handle later.

Afaik DT data should only contain information about the hardware. This
is SW configuration, so I think DT people won't accept things like that.

  And how about the size of the contiguous memory area, it was left a bit
  unclear to me why it cannot be dynamic.
 
 I don't think there is anything preventing adding a bootarg, but I
 think it is not essential so ok to add later

Well, maybe not essential to you =). But you are reserving 32MB memory,
which is quite a big amount. Even if the reserved memory can be used for
some other purposes, it's still a big chunk of special memory being
reserved even if the user doesn't use or have a display at all.

Well, it's not an issue for me either, but I just feel that doing things
like that without allowing the user to avoid it is a bit bad thing.

Btw, do you know why the dma_declare_contiguous() takes a dev pointer as
an argument, if the memory is not private to that device? (at least I
understood from you that the memory can be used for other purposes).

 Tomi


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] omap2+: add drm device

[Rob Clark]

On Wed, Mar 14, 2012 at 8:07 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
 On Wed, 2012-03-14 at 07:55 -0500, Rob Clark wrote:
 On Wed, Mar 14, 2012 at 7:38 AM, Tomi Valkeinen tomi.valkei...@ti.com 
 wrote:
  Hi,
 
  On Tue, 2012-03-13 at 15:34 -0500, Rob Clark wrote:
  From: Andy Gross andy.gr...@ti.com
 
  Register OMAP DRM/KMS platform device, and reserve a CMA region for
  the device to use for buffer allocation.  DMM is split into a
  separate device using hwmod.
 
  What's the diff with this and the previous one?

 Moving drm.c to mach-omap2 (header could not move because
 omap_reserve() is in plat-omap.. but this seems to be the same as what
 is done for dspbridge).

  I see you still have the platform data there. You didn't comment on
  that. Where is it used after the board files are gone when we use DT?

 I was kind-of thinking that there would be some DT-data-structure
 glue somewhere.. not sure if this goes in mach-omap2 or in the driver
 itself, but presumably it is needed somewhere.

 It is only really special cases where some board specific device-tree
 data is needed, so it seems like this is ok to handle later.

 Afaik DT data should only contain information about the hardware. This
 is SW configuration, so I think DT people won't accept things like that.

hmm, then where *does* it go.. it is a bit too much for bootargs..

  And how about the size of the contiguous memory area, it was left a bit
  unclear to me why it cannot be dynamic.

 I don't think there is anything preventing adding a bootarg, but I
 think it is not essential so ok to add later

 Well, maybe not essential to you =). But you are reserving 32MB memory,
 which is quite a big amount. Even if the reserved memory can be used for
 some other purposes, it's still a big chunk of special memory being
 reserved even if the user doesn't use or have a display at all.

If you didn't have display, and were tight on memory, wouldn't you
just disable the display device in your kernel config?

 Well, it's not an issue for me either, but I just feel that doing things
 like that without allowing the user to avoid it is a bit bad thing.

 Btw, do you know why the dma_declare_contiguous() takes a dev pointer as
 an argument, if the memory is not private to that device? (at least I
 understood from you that the memory can be used for other purposes).

contiguous use of the memory is private to the device.  There is also
a global CMA pool, from which all dma_alloc_xyz() which is not
associated w/ a per-device pool comes from.. but the advantage of a
per-device-pool is it puts an upper limit on how much dma memory that
device can allocate so that it cannot starve other devices.

BR,
-R

  Tomi


 ___
 dri-devel mailing list
 dri-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] omap2+: add drm device

[Tomi Valkeinen]

On Wed, 2012-03-14 at 08:16 -0500, Rob Clark wrote:
 On Wed, Mar 14, 2012 at 8:07 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
  On Wed, 2012-03-14 at 07:55 -0500, Rob Clark wrote:
  On Wed, Mar 14, 2012 at 7:38 AM, Tomi Valkeinen tomi.valkei...@ti.com 
  wrote:
   Hi,
  
   On Tue, 2012-03-13 at 15:34 -0500, Rob Clark wrote:
   From: Andy Gross andy.gr...@ti.com
  
   Register OMAP DRM/KMS platform device, and reserve a CMA region for
   the device to use for buffer allocation.  DMM is split into a
   separate device using hwmod.
  
   What's the diff with this and the previous one?
 
  Moving drm.c to mach-omap2 (header could not move because
  omap_reserve() is in plat-omap.. but this seems to be the same as what
  is done for dspbridge).
 
   I see you still have the platform data there. You didn't comment on
   that. Where is it used after the board files are gone when we use DT?
 
  I was kind-of thinking that there would be some DT-data-structure
  glue somewhere.. not sure if this goes in mach-omap2 or in the driver
  itself, but presumably it is needed somewhere.
 
  It is only really special cases where some board specific device-tree
  data is needed, so it seems like this is ok to handle later.
 
  Afaik DT data should only contain information about the hardware. This
  is SW configuration, so I think DT people won't accept things like that.
 
 hmm, then where *does* it go.. it is a bit too much for bootargs..

I have no idea =). And I may be wrong, but my understanding is the the
only thing DT data should have is information about the HW
configuration.

But is that kind of configuration needed at boot time? Why cannot the
userspace do the config? What configs are actually needed at boot time,
before userspace takes control? The only thing coming to my mind is to
define the display used for the console.

   And how about the size of the contiguous memory area, it was left a bit
   unclear to me why it cannot be dynamic.
 
  I don't think there is anything preventing adding a bootarg, but I
  think it is not essential so ok to add later
 
  Well, maybe not essential to you =). But you are reserving 32MB memory,
  which is quite a big amount. Even if the reserved memory can be used for
  some other purposes, it's still a big chunk of special memory being
  reserved even if the user doesn't use or have a display at all.
 
 If you didn't have display, and were tight on memory, wouldn't you
 just disable the display device in your kernel config?

Sure, if you want to modify your kernel. But you could as well use the
same kernel binary, and just say vram=0M which disables the vram
allocation. For DRM you would _have_ to modify your kernel.

Actually, I just realized vram=0M doesn't work, as the code checks for !
= 0, and just skips the vram argument when it's 0 =). So my code sucks
also...

  Well, it's not an issue for me either, but I just feel that doing things
  like that without allowing the user to avoid it is a bit bad thing.
 
  Btw, do you know why the dma_declare_contiguous() takes a dev pointer as
  an argument, if the memory is not private to that device? (at least I
  understood from you that the memory can be used for other purposes).
 
 contiguous use of the memory is private to the device.  There is also
 a global CMA pool, from which all dma_alloc_xyz() which is not
 associated w/ a per-device pool comes from.. but the advantage of a
 per-device-pool is it puts an upper limit on how much dma memory that
 device can allocate so that it cannot starve other devices.

Ah, I see. So the 32MB you reserve there is not visible as contiguous
memory to anyone else than omapdrm, but userspace can still use the 32MB
area for pages that can be moved out as needed.

But then, if it's private, it's also rather bad. If I have a kernel with
omapfb and omapdrm enabled as modules, but I never use omapdrm, the 32MB
is still always reserver and away from other contiguous memory use.

Also, I just realized that besides the memory reservation being fixed,
it's also hidden. If I enable omapdrm in the kernel config, I get no
indication that 32MB of mem is being reserved. Perhaps a Kconfig option
for it, like with OMAP VRAM, and then a boot arg which will override the
Kconfig value.

Well, as I said, it's not an issue for me and from my side it can be
improved later.

 Tomi


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/2] drm/radeon: Drop radeon_gem_object_(un)pin.

[Michel Dänzer]

From: Michel Dänzer michel.daen...@amd.com

Only radeon_gem_object_unpin was used anymore, in only one place.

Signed-off-by: Michel Dänzer michel.daen...@amd.com
---
 drivers/gpu/drm/radeon/radeon.h|3 ---
 drivers/gpu/drm/radeon/radeon_cursor.c |7 ++-
 drivers/gpu/drm/radeon/radeon_gem.c|   26 --
 3 files changed, 6 insertions(+), 30 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index ec995ca..1414900 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -375,9 +375,6 @@ int radeon_gem_object_create(struct radeon_device *rdev, 
int size,
int alignment, int initial_domain,
bool discardable, bool kernel,
struct drm_gem_object **obj);
-int radeon_gem_object_pin(struct drm_gem_object *obj, uint32_t pin_domain,
- uint64_t *gpu_addr);
-void radeon_gem_object_unpin(struct drm_gem_object *obj);
 
 int radeon_mode_dumb_create(struct drm_file *file_priv,
struct drm_device *dev,
diff --git a/drivers/gpu/drm/radeon/radeon_cursor.c 
b/drivers/gpu/drm/radeon/radeon_cursor.c
index 986d608..42acc64 100644
--- a/drivers/gpu/drm/radeon/radeon_cursor.c
+++ b/drivers/gpu/drm/radeon/radeon_cursor.c
@@ -197,7 +197,12 @@ int radeon_crtc_cursor_set(struct drm_crtc *crtc,
 
 unpin:
if (radeon_crtc-cursor_bo) {
-   radeon_gem_object_unpin(radeon_crtc-cursor_bo);
+   robj = gem_to_radeon_bo(radeon_crtc-cursor_bo);
+   ret = radeon_bo_reserve(robj, false);
+   if (likely(ret == 0)) {
+   radeon_bo_unpin(robj);
+   radeon_bo_unreserve(robj);
+   }
drm_gem_object_unreference_unlocked(radeon_crtc-cursor_bo);
}
 
diff --git a/drivers/gpu/drm/radeon/radeon_gem.c 
b/drivers/gpu/drm/radeon/radeon_gem.c
index 003eeec..090da31 100644
--- a/drivers/gpu/drm/radeon/radeon_gem.c
+++ b/drivers/gpu/drm/radeon/radeon_gem.c
@@ -75,32 +75,6 @@ int radeon_gem_object_create(struct radeon_device *rdev, int 
size,
return 0;
 }
 
-int radeon_gem_object_pin(struct drm_gem_object *obj, uint32_t pin_domain,
- uint64_t *gpu_addr)
-{
-   struct radeon_bo *robj = gem_to_radeon_bo(obj);
-   int r;
-
-   r = radeon_bo_reserve(robj, false);
-   if (unlikely(r != 0))
-   return r;
-   r = radeon_bo_pin(robj, pin_domain, gpu_addr);
-   radeon_bo_unreserve(robj);
-   return r;
-}
-
-void radeon_gem_object_unpin(struct drm_gem_object *obj)
-{
-   struct radeon_bo *robj = gem_to_radeon_bo(obj);
-   int r;
-
-   r = radeon_bo_reserve(robj, false);
-   if (likely(r == 0)) {
-   radeon_bo_unpin(robj);
-   radeon_bo_unreserve(robj);
-   }
-}
-
 int radeon_gem_set_domain(struct drm_gem_object *gobj,
  uint32_t rdomain, uint32_t wdomain)
 {
-- 
1.7.9.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/2] drm/radeon: Restrict offset for legacy hardware cursor.

[Michel Dänzer]

From: Michel Dänzer michel.daen...@amd.com

The hardware only takes 27 bits for the offset, so larger offsets are
truncated, and the hardware cursor shows random bits other than the intended
ones.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=46796

Cc: sta...@vger.kernel.org
Signed-off-by: Michel Dänzer michel.daen...@amd.com
---
 drivers/gpu/drm/radeon/radeon_cursor.c |   13 +++--
 drivers/gpu/drm/radeon/radeon_object.c |   18 +-
 drivers/gpu/drm/radeon/radeon_object.h |2 ++
 3 files changed, 30 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_cursor.c 
b/drivers/gpu/drm/radeon/radeon_cursor.c
index fde25c0..986d608 100644
--- a/drivers/gpu/drm/radeon/radeon_cursor.c
+++ b/drivers/gpu/drm/radeon/radeon_cursor.c
@@ -151,7 +151,9 @@ int radeon_crtc_cursor_set(struct drm_crtc *crtc,
   uint32_t height)
 {
struct radeon_crtc *radeon_crtc = to_radeon_crtc(crtc);
+   struct radeon_device *rdev = crtc-dev-dev_private;
struct drm_gem_object *obj;
+   struct radeon_bo *robj;
uint64_t gpu_addr;
int ret;
 
@@ -173,7 +175,15 @@ int radeon_crtc_cursor_set(struct drm_crtc *crtc,
return -ENOENT;
}
 
-   ret = radeon_gem_object_pin(obj, RADEON_GEM_DOMAIN_VRAM, gpu_addr);
+   robj = gem_to_radeon_bo(obj);
+   ret = radeon_bo_reserve(robj, false);
+   if (unlikely(ret != 0))
+   goto fail;
+   /* Only 27 bit offset for legacy cursor */
+   ret = radeon_bo_pin_restricted(robj, RADEON_GEM_DOMAIN_VRAM,
+  ASIC_IS_AVIVO(rdev) ? 0 : 1  27,
+  gpu_addr);
+   radeon_bo_unreserve(robj);
if (ret)
goto fail;
 
@@ -181,7 +191,6 @@ int radeon_crtc_cursor_set(struct drm_crtc *crtc,
radeon_crtc-cursor_height = height;
 
radeon_lock_cursor(crtc, true);
-   /* XXX only 27 bit offset for legacy cursor */
radeon_set_cursor(crtc, obj, gpu_addr);
radeon_show_cursor(crtc);
radeon_lock_cursor(crtc, false);
diff --git a/drivers/gpu/drm/radeon/radeon_object.c 
b/drivers/gpu/drm/radeon/radeon_object.c
index d45df17..388be34 100644
--- a/drivers/gpu/drm/radeon/radeon_object.c
+++ b/drivers/gpu/drm/radeon/radeon_object.c
@@ -224,7 +224,8 @@ void radeon_bo_unref(struct radeon_bo **bo)
*bo = NULL;
 }
 
-int radeon_bo_pin(struct radeon_bo *bo, u32 domain, u64 *gpu_addr)
+int radeon_bo_pin_restricted(struct radeon_bo *bo, u32 domain, u64 max_offset,
+u64 *gpu_addr)
 {
int r, i;
 
@@ -232,6 +233,7 @@ int radeon_bo_pin(struct radeon_bo *bo, u32 domain, u64 
*gpu_addr)
bo-pin_count++;
if (gpu_addr)
*gpu_addr = radeon_bo_gpu_offset(bo);
+   WARN_ON_ONCE(max_offset != 0);
return 0;
}
radeon_ttm_placement_from_domain(bo, domain);
@@ -239,6 +241,15 @@ int radeon_bo_pin(struct radeon_bo *bo, u32 domain, u64 
*gpu_addr)
/* force to pin into visible video ram */
bo-placement.lpfn = bo-rdev-mc.visible_vram_size  
PAGE_SHIFT;
}
+   if (max_offset) {
+   u64 lpfn = max_offset  PAGE_SHIFT;
+
+   if (bo-placement.lpfn) {
+   if (lpfn  bo-placement.lpfn)
+   bo-placement.lpfn = lpfn;
+   } else
+   bo-placement.lpfn = lpfn;
+   }
for (i = 0; i  bo-placement.num_placement; i++)
bo-placements[i] |= TTM_PL_FLAG_NO_EVICT;
r = ttm_bo_validate(bo-tbo, bo-placement, false, false, false);
@@ -252,6 +263,11 @@ int radeon_bo_pin(struct radeon_bo *bo, u32 domain, u64 
*gpu_addr)
return r;
 }
 
+int radeon_bo_pin(struct radeon_bo *bo, u32 domain, u64 *gpu_addr)
+{
+   return radeon_bo_pin_restricted(bo, domain, 0, gpu_addr);
+}
+
 int radeon_bo_unpin(struct radeon_bo *bo)
 {
int r, i;
diff --git a/drivers/gpu/drm/radeon/radeon_object.h 
b/drivers/gpu/drm/radeon/radeon_object.h
index cde4303..f9104be 100644
--- a/drivers/gpu/drm/radeon/radeon_object.h
+++ b/drivers/gpu/drm/radeon/radeon_object.h
@@ -118,6 +118,8 @@ extern int radeon_bo_kmap(struct radeon_bo *bo, void **ptr);
 extern void radeon_bo_kunmap(struct radeon_bo *bo);
 extern void radeon_bo_unref(struct radeon_bo **bo);
 extern int radeon_bo_pin(struct radeon_bo *bo, u32 domain, u64 *gpu_addr);
+extern int radeon_bo_pin_restricted(struct radeon_bo *bo, u32 domain,
+   u64 max_offset, u64 *gpu_addr);
 extern int radeon_bo_unpin(struct radeon_bo *bo);
 extern int radeon_bo_evict_vram(struct radeon_device *rdev);
 extern void radeon_bo_force_delete(struct radeon_device *rdev);
-- 
1.7.9.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org

[Bug 42920] Radeon with KMS and UMA works only up to 128MB

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=42920





--- Comment #4 from j.fi...@gmail.com  2012-03-14 14:46:30 ---
for 256MB, 512MB and 1024MB I get

[6.301475] [drm] CONFIG_MEMSIZE: 0x

also I need a cold restart when changing UMA size in bios, otherwise it's not
changed.

so is it a bios problem? should I try to complain to Asus? Is there an easy
workaround? Like using manually vramlimit?

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 46796] [X800SE] Mouse cursor corruption when switching users

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=46796

Michel Dänzer mic...@daenzer.net changed:

   What|Removed |Added

  Attachment #58312|0   |1
is obsolete||

--- Comment #12 from Michel Dänzer mic...@daenzer.net 2012-03-14 07:57:05 PDT 
---
Created attachment 58436
  -- https://bugs.freedesktop.org/attachment.cgi?id=58436
Submitted fix

(In reply to comment #11)
 [...] I haven't had the mouse corruption issue on this patched driver, and the
 message appears in dmesg:

Okay, so an unpatched driver probably would use too large offsets sometimes,
which would definitely explain the corrupted cursor. So the fix seems to be
working.


 I have to say that the log confuses me since 1  27 is not 0.

Indeed, but that's just a bug of the DRM_INFO call. :) (Type mismatch between
format string and values)


I'm attaching the fix as I submitted it for inclusion into the kernel.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- 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 42920] Radeon with KMS and UMA works only up to 128MB

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=42920





--- Comment #5 from Alex Deucher alexdeuc...@gmail.com  2012-03-14 15:02:42 
---
(In reply to comment #4)
 for 256MB, 512MB and 1024MB I get
 
 [6.301475] [drm] CONFIG_MEMSIZE: 0x
 
 also I need a cold restart when changing UMA size in bios, otherwise it's not
 changed.
 
 so is it a bios problem? should I try to complain to Asus? Is there an easy
 workaround? Like using manually vramlimit?

Looks like the bios is broken.  The vramlimit parameter should work.

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] omap2+: add drm device

[Rob Clark]

On Wed, Mar 14, 2012 at 8:43 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
 On Wed, 2012-03-14 at 08:16 -0500, Rob Clark wrote:
 On Wed, Mar 14, 2012 at 8:07 AM, Tomi Valkeinen tomi.valkei...@ti.com 
 wrote:
  On Wed, 2012-03-14 at 07:55 -0500, Rob Clark wrote:
  On Wed, Mar 14, 2012 at 7:38 AM, Tomi Valkeinen tomi.valkei...@ti.com 
  wrote:
   Hi,
  
   On Tue, 2012-03-13 at 15:34 -0500, Rob Clark wrote:
   From: Andy Gross andy.gr...@ti.com
  
   Register OMAP DRM/KMS platform device, and reserve a CMA region for
   the device to use for buffer allocation.  DMM is split into a
   separate device using hwmod.
  
   What's the diff with this and the previous one?
 
  Moving drm.c to mach-omap2 (header could not move because
  omap_reserve() is in plat-omap.. but this seems to be the same as what
  is done for dspbridge).
 
   I see you still have the platform data there. You didn't comment on
   that. Where is it used after the board files are gone when we use DT?
 
  I was kind-of thinking that there would be some DT-data-structure
  glue somewhere.. not sure if this goes in mach-omap2 or in the driver
  itself, but presumably it is needed somewhere.
 
  It is only really special cases where some board specific device-tree
  data is needed, so it seems like this is ok to handle later.
 
  Afaik DT data should only contain information about the hardware. This
  is SW configuration, so I think DT people won't accept things like that.

 hmm, then where *does* it go.. it is a bit too much for bootargs..

 I have no idea =). And I may be wrong, but my understanding is the the
 only thing DT data should have is information about the HW
 configuration.

 But is that kind of configuration needed at boot time? Why cannot the
 userspace do the config? What configs are actually needed at boot time,
 before userspace takes control? The only thing coming to my mind is to
 define the display used for the console.

drm builds up list of resources at startup, and attempts to light up
any connected displays at boot..  the decision about what resources to
use must be taken before userspace starts.

Anyways, if it is too controversial, maybe I just remove it.  It is
really only very special cases (possibly multi-seat setups) where you
might want to do something other than the default (which is for a
single omapdrm instance to use all dss video pipes).  It is just code
I had written previously for a certain product, and it seemed
potentially useful enough to not strip out of the upstream driver.

   And how about the size of the contiguous memory area, it was left a bit
   unclear to me why it cannot be dynamic.
 
  I don't think there is anything preventing adding a bootarg, but I
  think it is not essential so ok to add later
 
  Well, maybe not essential to you =). But you are reserving 32MB memory,
  which is quite a big amount. Even if the reserved memory can be used for
  some other purposes, it's still a big chunk of special memory being
  reserved even if the user doesn't use or have a display at all.

 If you didn't have display, and were tight on memory, wouldn't you
 just disable the display device in your kernel config?

 Sure, if you want to modify your kernel. But you could as well use the
 same kernel binary, and just say vram=0M which disables the vram
 allocation. For DRM you would _have_ to modify your kernel.

 Actually, I just realized vram=0M doesn't work, as the code checks for !
 = 0, and just skips the vram argument when it's 0 =). So my code sucks
 also...

well, I suppose there is always something somewhere to improve..

anyways, at this point omapdrm isn't enabled by default in
omap2plus_defconfig.. I just want to get the platform device
registration merged in some form so folks don't have to go poking
around to find some out of tree patch in order to enable it.

  Well, it's not an issue for me either, but I just feel that doing things
  like that without allowing the user to avoid it is a bit bad thing.
 
  Btw, do you know why the dma_declare_contiguous() takes a dev pointer as
  an argument, if the memory is not private to that device? (at least I
  understood from you that the memory can be used for other purposes).

 contiguous use of the memory is private to the device.  There is also
 a global CMA pool, from which all dma_alloc_xyz() which is not
 associated w/ a per-device pool comes from.. but the advantage of a
 per-device-pool is it puts an upper limit on how much dma memory that
 device can allocate so that it cannot starve other devices.

 Ah, I see. So the 32MB you reserve there is not visible as contiguous
 memory to anyone else than omapdrm, but userspace can still use the 32MB
 area for pages that can be moved out as needed.

 But then, if it's private, it's also rather bad. If I have a kernel with
 omapfb and omapdrm enabled as modules, but I never use omapdrm, the 32MB
 is still always reserver and away from other contiguous memory use.

 Also, I just realized that besides 

Re: [PATCH 1/2] drm/radeon: Restrict offset for legacy hardware cursor.

[Alex Deucher]

2012/3/14 Michel Dänzer mic...@daenzer.net:
 From: Michel Dänzer michel.daen...@amd.com

 The hardware only takes 27 bits for the offset, so larger offsets are
 truncated, and the hardware cursor shows random bits other than the intended
 ones.

 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=46796

 Cc: sta...@vger.kernel.org
 Signed-off-by: Michel Dänzer michel.daen...@amd.com

Reviewed-by: Alex Deucher alexander.deuc...@amd.com

FWIW, I think we may need a similar fix for the crtc base addresses.
They are also limited to 27 bit offsets from the mc address specified
in DISPLAY[2]_BASE_ADDR.

 ---
  drivers/gpu/drm/radeon/radeon_cursor.c |   13 +++--
  drivers/gpu/drm/radeon/radeon_object.c |   18 +-
  drivers/gpu/drm/radeon/radeon_object.h |    2 ++
  3 files changed, 30 insertions(+), 3 deletions(-)

 diff --git a/drivers/gpu/drm/radeon/radeon_cursor.c 
 b/drivers/gpu/drm/radeon/radeon_cursor.c
 index fde25c0..986d608 100644
 --- a/drivers/gpu/drm/radeon/radeon_cursor.c
 +++ b/drivers/gpu/drm/radeon/radeon_cursor.c
 @@ -151,7 +151,9 @@ int radeon_crtc_cursor_set(struct drm_crtc *crtc,
                           uint32_t height)
  {
        struct radeon_crtc *radeon_crtc = to_radeon_crtc(crtc);
 +       struct radeon_device *rdev = crtc-dev-dev_private;
        struct drm_gem_object *obj;
 +       struct radeon_bo *robj;
        uint64_t gpu_addr;
        int ret;

 @@ -173,7 +175,15 @@ int radeon_crtc_cursor_set(struct drm_crtc *crtc,
                return -ENOENT;
        }

 -       ret = radeon_gem_object_pin(obj, RADEON_GEM_DOMAIN_VRAM, gpu_addr);
 +       robj = gem_to_radeon_bo(obj);
 +       ret = radeon_bo_reserve(robj, false);
 +       if (unlikely(ret != 0))
 +               goto fail;
 +       /* Only 27 bit offset for legacy cursor */
 +       ret = radeon_bo_pin_restricted(robj, RADEON_GEM_DOMAIN_VRAM,
 +                                      ASIC_IS_AVIVO(rdev) ? 0 : 1  27,
 +                                      gpu_addr);
 +       radeon_bo_unreserve(robj);
        if (ret)
                goto fail;

 @@ -181,7 +191,6 @@ int radeon_crtc_cursor_set(struct drm_crtc *crtc,
        radeon_crtc-cursor_height = height;

        radeon_lock_cursor(crtc, true);
 -       /* XXX only 27 bit offset for legacy cursor */
        radeon_set_cursor(crtc, obj, gpu_addr);
        radeon_show_cursor(crtc);
        radeon_lock_cursor(crtc, false);
 diff --git a/drivers/gpu/drm/radeon/radeon_object.c 
 b/drivers/gpu/drm/radeon/radeon_object.c
 index d45df17..388be34 100644
 --- a/drivers/gpu/drm/radeon/radeon_object.c
 +++ b/drivers/gpu/drm/radeon/radeon_object.c
 @@ -224,7 +224,8 @@ void radeon_bo_unref(struct radeon_bo **bo)
                *bo = NULL;
  }

 -int radeon_bo_pin(struct radeon_bo *bo, u32 domain, u64 *gpu_addr)
 +int radeon_bo_pin_restricted(struct radeon_bo *bo, u32 domain, u64 
 max_offset,
 +                            u64 *gpu_addr)
  {
        int r, i;

 @@ -232,6 +233,7 @@ int radeon_bo_pin(struct radeon_bo *bo, u32 domain, u64 
 *gpu_addr)
                bo-pin_count++;
                if (gpu_addr)
                        *gpu_addr = radeon_bo_gpu_offset(bo);
 +               WARN_ON_ONCE(max_offset != 0);
                return 0;
        }
        radeon_ttm_placement_from_domain(bo, domain);
 @@ -239,6 +241,15 @@ int radeon_bo_pin(struct radeon_bo *bo, u32 domain, u64 
 *gpu_addr)
                /* force to pin into visible video ram */
                bo-placement.lpfn = bo-rdev-mc.visible_vram_size  
 PAGE_SHIFT;
        }
 +       if (max_offset) {
 +               u64 lpfn = max_offset  PAGE_SHIFT;
 +
 +               if (bo-placement.lpfn) {
 +                       if (lpfn  bo-placement.lpfn)
 +                               bo-placement.lpfn = lpfn;
 +               } else
 +                       bo-placement.lpfn = lpfn;
 +       }
        for (i = 0; i  bo-placement.num_placement; i++)
                bo-placements[i] |= TTM_PL_FLAG_NO_EVICT;
        r = ttm_bo_validate(bo-tbo, bo-placement, false, false, false);
 @@ -252,6 +263,11 @@ int radeon_bo_pin(struct radeon_bo *bo, u32 domain, u64 
 *gpu_addr)
        return r;
  }

 +int radeon_bo_pin(struct radeon_bo *bo, u32 domain, u64 *gpu_addr)
 +{
 +       return radeon_bo_pin_restricted(bo, domain, 0, gpu_addr);
 +}
 +
  int radeon_bo_unpin(struct radeon_bo *bo)
  {
        int r, i;
 diff --git a/drivers/gpu/drm/radeon/radeon_object.h 
 b/drivers/gpu/drm/radeon/radeon_object.h
 index cde4303..f9104be 100644
 --- a/drivers/gpu/drm/radeon/radeon_object.h
 +++ b/drivers/gpu/drm/radeon/radeon_object.h
 @@ -118,6 +118,8 @@ extern int radeon_bo_kmap(struct radeon_bo *bo, void 
 **ptr);
  extern void radeon_bo_kunmap(struct radeon_bo *bo);
  extern void radeon_bo_unref(struct radeon_bo **bo);
  extern int radeon_bo_pin(struct radeon_bo *bo, u32 domain, u64 *gpu_addr);
 +extern int radeon_bo_pin_restricted(struct radeon_bo *bo, u32 domain,
 +                                   u64 

[Bug 46713] HDMI audio played back at a wrong rate

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=46713

Christian König deathsim...@vodafone.de changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||deathsim...@vodafone.de

--- Comment #18 from Christian König deathsim...@vodafone.de 2012-03-14 
08:09:27 PDT ---
Ok, I will try to get you the documentation for the PLL regs, they are not DRM
or IP related. So there is a slightly chance that we can release them.

Christian.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- 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 2/2] drm/radeon: Drop radeon_gem_object_(un)pin.

[Alex Deucher]

2012/3/14 Michel Dänzer mic...@daenzer.net:
 From: Michel Dänzer michel.daen...@amd.com

 Only radeon_gem_object_unpin was used anymore, in only one place.

 Signed-off-by: Michel Dänzer michel.daen...@amd.com

Reviewed-by: Alex Deucher alexander.deuc...@amd.com

 ---
  drivers/gpu/drm/radeon/radeon.h        |    3 ---
  drivers/gpu/drm/radeon/radeon_cursor.c |    7 ++-
  drivers/gpu/drm/radeon/radeon_gem.c    |   26 --
  3 files changed, 6 insertions(+), 30 deletions(-)

 diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
 index ec995ca..1414900 100644
 --- a/drivers/gpu/drm/radeon/radeon.h
 +++ b/drivers/gpu/drm/radeon/radeon.h
 @@ -375,9 +375,6 @@ int radeon_gem_object_create(struct radeon_device *rdev, 
 int size,
                                int alignment, int initial_domain,
                                bool discardable, bool kernel,
                                struct drm_gem_object **obj);
 -int radeon_gem_object_pin(struct drm_gem_object *obj, uint32_t pin_domain,
 -                         uint64_t *gpu_addr);
 -void radeon_gem_object_unpin(struct drm_gem_object *obj);

  int radeon_mode_dumb_create(struct drm_file *file_priv,
                            struct drm_device *dev,
 diff --git a/drivers/gpu/drm/radeon/radeon_cursor.c 
 b/drivers/gpu/drm/radeon/radeon_cursor.c
 index 986d608..42acc64 100644
 --- a/drivers/gpu/drm/radeon/radeon_cursor.c
 +++ b/drivers/gpu/drm/radeon/radeon_cursor.c
 @@ -197,7 +197,12 @@ int radeon_crtc_cursor_set(struct drm_crtc *crtc,

  unpin:
        if (radeon_crtc-cursor_bo) {
 -               radeon_gem_object_unpin(radeon_crtc-cursor_bo);
 +               robj = gem_to_radeon_bo(radeon_crtc-cursor_bo);
 +               ret = radeon_bo_reserve(robj, false);
 +               if (likely(ret == 0)) {
 +                       radeon_bo_unpin(robj);
 +                       radeon_bo_unreserve(robj);
 +               }
                drm_gem_object_unreference_unlocked(radeon_crtc-cursor_bo);
        }

 diff --git a/drivers/gpu/drm/radeon/radeon_gem.c 
 b/drivers/gpu/drm/radeon/radeon_gem.c
 index 003eeec..090da31 100644
 --- a/drivers/gpu/drm/radeon/radeon_gem.c
 +++ b/drivers/gpu/drm/radeon/radeon_gem.c
 @@ -75,32 +75,6 @@ int radeon_gem_object_create(struct radeon_device *rdev, 
 int size,
        return 0;
  }

 -int radeon_gem_object_pin(struct drm_gem_object *obj, uint32_t pin_domain,
 -                         uint64_t *gpu_addr)
 -{
 -       struct radeon_bo *robj = gem_to_radeon_bo(obj);
 -       int r;
 -
 -       r = radeon_bo_reserve(robj, false);
 -       if (unlikely(r != 0))
 -               return r;
 -       r = radeon_bo_pin(robj, pin_domain, gpu_addr);
 -       radeon_bo_unreserve(robj);
 -       return r;
 -}
 -
 -void radeon_gem_object_unpin(struct drm_gem_object *obj)
 -{
 -       struct radeon_bo *robj = gem_to_radeon_bo(obj);
 -       int r;
 -
 -       r = radeon_bo_reserve(robj, false);
 -       if (likely(r == 0)) {
 -               radeon_bo_unpin(robj);
 -               radeon_bo_unreserve(robj);
 -       }
 -}
 -
  int radeon_gem_set_domain(struct drm_gem_object *gobj,
                          uint32_t rdomain, uint32_t wdomain)
  {
 --
 1.7.9.1

 ___
 dri-devel mailing list
 dri-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/2] drm/radeon: Restrict offset for legacy hardware cursor.

[Michel Dänzer]

On Mit, 2012-03-14 at 11:08 -0400, Alex Deucher wrote: 
 2012/3/14 Michel Dänzer mic...@daenzer.net:
  From: Michel Dänzer michel.daen...@amd.com
 
  The hardware only takes 27 bits for the offset, so larger offsets are
  truncated, and the hardware cursor shows random bits other than the intended
  ones.
 
  Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=46796
 
  Cc: sta...@vger.kernel.org
  Signed-off-by: Michel Dänzer michel.daen...@amd.com
 
 Reviewed-by: Alex Deucher alexander.deuc...@amd.com

Thanks. In the meantime, it occurred to me there might be a problem when
there's less than 128M of VRAM in the first place (so bo-placement.lpfn
ends up larger than rdev-mman.bdev.man[TTM_PL_VRAM].size). To be safe,
I'll send a v2 patch preventing that.


 FWIW, I think we may need a similar fix for the crtc base addresses.
 They are also limited to 27 bit offsets from the mc address specified
 in DISPLAY[2]_BASE_ADDR.

Hmm, good point.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast |  Debian, X and DRI developer
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 42920] Radeon with KMS and UMA works only up to 128MB

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=42920





--- Comment #6 from j.fi...@gmail.com  2012-03-14 15:49:41 ---
vramlimit didn't work, it's in my first post;
but I'll verify that.

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 1/2] drm/radeon: Restrict offset for legacy hardware cursor.

[Michel Dänzer]

From: Michel Dänzer michel.daen...@amd.com

The hardware only takes 27 bits for the offset, so larger offsets are
truncated, and the hardware cursor shows random bits other than the intended
ones.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=46796

Cc: sta...@vger.kernel.org
Signed-off-by: Michel Dänzer michel.daen...@amd.com
---

v2: Make sure bo-placement.lpfn isn't larger than the memory size, even if
radeon_bo_pin_restricted were to be called for the GTT domain.

 drivers/gpu/drm/radeon/radeon_cursor.c |   13 +++--
 drivers/gpu/drm/radeon/radeon_object.c |   18 +-
 drivers/gpu/drm/radeon/radeon_object.h |2 ++
 3 files changed, 30 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_cursor.c 
b/drivers/gpu/drm/radeon/radeon_cursor.c
index fde25c0..986d608 100644
--- a/drivers/gpu/drm/radeon/radeon_cursor.c
+++ b/drivers/gpu/drm/radeon/radeon_cursor.c
@@ -151,7 +151,9 @@ int radeon_crtc_cursor_set(struct drm_crtc *crtc,
   uint32_t height)
 {
struct radeon_crtc *radeon_crtc = to_radeon_crtc(crtc);
+   struct radeon_device *rdev = crtc-dev-dev_private;
struct drm_gem_object *obj;
+   struct radeon_bo *robj;
uint64_t gpu_addr;
int ret;
 
@@ -173,7 +175,15 @@ int radeon_crtc_cursor_set(struct drm_crtc *crtc,
return -ENOENT;
}
 
-   ret = radeon_gem_object_pin(obj, RADEON_GEM_DOMAIN_VRAM, gpu_addr);
+   robj = gem_to_radeon_bo(obj);
+   ret = radeon_bo_reserve(robj, false);
+   if (unlikely(ret != 0))
+   goto fail;
+   /* Only 27 bit offset for legacy cursor */
+   ret = radeon_bo_pin_restricted(robj, RADEON_GEM_DOMAIN_VRAM,
+  ASIC_IS_AVIVO(rdev) ? 0 : 1  27,
+  gpu_addr);
+   radeon_bo_unreserve(robj);
if (ret)
goto fail;
 
@@ -181,7 +191,6 @@ int radeon_crtc_cursor_set(struct drm_crtc *crtc,
radeon_crtc-cursor_height = height;
 
radeon_lock_cursor(crtc, true);
-   /* XXX only 27 bit offset for legacy cursor */
radeon_set_cursor(crtc, obj, gpu_addr);
radeon_show_cursor(crtc);
radeon_lock_cursor(crtc, false);
diff --git a/drivers/gpu/drm/radeon/radeon_object.c 
b/drivers/gpu/drm/radeon/radeon_object.c
index d45df17..fd2dc0e 100644
--- a/drivers/gpu/drm/radeon/radeon_object.c
+++ b/drivers/gpu/drm/radeon/radeon_object.c
@@ -224,7 +224,8 @@ void radeon_bo_unref(struct radeon_bo **bo)
*bo = NULL;
 }
 
-int radeon_bo_pin(struct radeon_bo *bo, u32 domain, u64 *gpu_addr)
+int radeon_bo_pin_restricted(struct radeon_bo *bo, u32 domain, u64 max_offset,
+u64 *gpu_addr)
 {
int r, i;
 
@@ -232,6 +233,7 @@ int radeon_bo_pin(struct radeon_bo *bo, u32 domain, u64 
*gpu_addr)
bo-pin_count++;
if (gpu_addr)
*gpu_addr = radeon_bo_gpu_offset(bo);
+   WARN_ON_ONCE(max_offset != 0);
return 0;
}
radeon_ttm_placement_from_domain(bo, domain);
@@ -239,6 +241,15 @@ int radeon_bo_pin(struct radeon_bo *bo, u32 domain, u64 
*gpu_addr)
/* force to pin into visible video ram */
bo-placement.lpfn = bo-rdev-mc.visible_vram_size  
PAGE_SHIFT;
}
+   if (max_offset) {
+   u64 lpfn = max_offset  PAGE_SHIFT;
+
+   if (!bo-placement.lpfn)
+   bo-placement.lpfn = bo-rdev-mc.gtt_size  
PAGE_SHIFT;
+
+   if (lpfn  bo-placement.lpfn)
+   bo-placement.lpfn = lpfn;
+   }
for (i = 0; i  bo-placement.num_placement; i++)
bo-placements[i] |= TTM_PL_FLAG_NO_EVICT;
r = ttm_bo_validate(bo-tbo, bo-placement, false, false, false);
@@ -252,6 +263,11 @@ int radeon_bo_pin(struct radeon_bo *bo, u32 domain, u64 
*gpu_addr)
return r;
 }
 
+int radeon_bo_pin(struct radeon_bo *bo, u32 domain, u64 *gpu_addr)
+{
+   return radeon_bo_pin_restricted(bo, domain, 0, gpu_addr);
+}
+
 int radeon_bo_unpin(struct radeon_bo *bo)
 {
int r, i;
diff --git a/drivers/gpu/drm/radeon/radeon_object.h 
b/drivers/gpu/drm/radeon/radeon_object.h
index cde4303..f9104be 100644
--- a/drivers/gpu/drm/radeon/radeon_object.h
+++ b/drivers/gpu/drm/radeon/radeon_object.h
@@ -118,6 +118,8 @@ extern int radeon_bo_kmap(struct radeon_bo *bo, void **ptr);
 extern void radeon_bo_kunmap(struct radeon_bo *bo);
 extern void radeon_bo_unref(struct radeon_bo **bo);
 extern int radeon_bo_pin(struct radeon_bo *bo, u32 domain, u64 *gpu_addr);
+extern int radeon_bo_pin_restricted(struct radeon_bo *bo, u32 domain,
+   u64 max_offset, u64 *gpu_addr);
 extern int radeon_bo_unpin(struct radeon_bo *bo);
 extern int radeon_bo_evict_vram(struct radeon_device *rdev);
 extern void radeon_bo_force_delete(struct radeon_device *rdev);
-- 

[PATCH 2/2] drm/radeon: Restrict offset for legacy display engine.

[Michel Dänzer]

From: Michel Dänzer michel.daen...@amd.com

The hardware only takes 27 bits for the offset, so larger offsets are
truncated, and the display shows random bits other than the intended ones.

Signed-off-by: Michel Dänzer michel.daen...@amd.com
---
 drivers/gpu/drm/radeon/radeon_display.c |4 +++-
 drivers/gpu/drm/radeon/radeon_fb.c  |5 -
 drivers/gpu/drm/radeon/radeon_legacy_crtc.c |4 +++-
 3 files changed, 10 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_display.c 
b/drivers/gpu/drm/radeon/radeon_display.c
index d3ffc18..63386a4 100644
--- a/drivers/gpu/drm/radeon/radeon_display.c
+++ b/drivers/gpu/drm/radeon/radeon_display.c
@@ -393,7 +393,9 @@ static int radeon_crtc_page_flip(struct drm_crtc *crtc,
DRM_ERROR(failed to reserve new rbo buffer before flip\n);
goto pflip_cleanup;
}
-   r = radeon_bo_pin(rbo, RADEON_GEM_DOMAIN_VRAM, base);
+   /* Only 27 bit offset for legacy CRTC */
+   r = radeon_bo_pin_restricted(rbo, RADEON_GEM_DOMAIN_VRAM,
+ASIC_IS_AVIVO(rdev) ? 0 : 1  27, base);
if (unlikely(r != 0)) {
radeon_bo_unreserve(rbo);
r = -EINVAL;
diff --git a/drivers/gpu/drm/radeon/radeon_fb.c 
b/drivers/gpu/drm/radeon/radeon_fb.c
index cf2bf35..93bf920 100644
--- a/drivers/gpu/drm/radeon/radeon_fb.c
+++ b/drivers/gpu/drm/radeon/radeon_fb.c
@@ -164,7 +164,10 @@ static int radeonfb_create_pinned_object(struct 
radeon_fbdev *rfbdev,
ret = radeon_bo_reserve(rbo, false);
if (unlikely(ret != 0))
goto out_unref;
-   ret = radeon_bo_pin(rbo, RADEON_GEM_DOMAIN_VRAM, NULL);
+   /* Only 27 bit offset for legacy CRTC */
+   ret = radeon_bo_pin_restricted(rbo, RADEON_GEM_DOMAIN_VRAM,
+  ASIC_IS_AVIVO(rdev) ? 0 : 1  27,
+  NULL);
if (ret) {
radeon_bo_unreserve(rbo);
goto out_unref;
diff --git a/drivers/gpu/drm/radeon/radeon_legacy_crtc.c 
b/drivers/gpu/drm/radeon/radeon_legacy_crtc.c
index 25a19c4..210317c 100644
--- a/drivers/gpu/drm/radeon/radeon_legacy_crtc.c
+++ b/drivers/gpu/drm/radeon/radeon_legacy_crtc.c
@@ -419,7 +419,9 @@ int radeon_crtc_do_set_base(struct drm_crtc *crtc,
r = radeon_bo_reserve(rbo, false);
if (unlikely(r != 0))
return r;
-   r = radeon_bo_pin(rbo, RADEON_GEM_DOMAIN_VRAM, base);
+   /* Only 27 bit offset for legacy CRTC */
+   r = radeon_bo_pin_restricted(rbo, RADEON_GEM_DOMAIN_VRAM, 1  27,
+base);
if (unlikely(r != 0)) {
radeon_bo_unreserve(rbo);
return -EINVAL;
-- 
1.7.9.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PULL] drm-intel-fixes

[Keith Packard]

Jesse sent me a couple of trivial sprite plane fixes.

The following changes since commit 91982b58d35720b75b894c60e1e3133daa455b53:

  drm/gma500: Fix Cedarview boot failures in 3.3-rc (2012-03-05 14:08:31 +)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/keithp/linux drm-intel-fixes

for you to fetch changes up to b250da79a0c972ef7f6d58ebd1083cab066e6c82:

  drm/i915: support 32 bit BGR formats in sprite planes (2012-03-07 10:52:13 
-0800)


Jesse Barnes (2):
  drm/i915: fix color order for BGR formats on SNB
  drm/i915: support 32 bit BGR formats in sprite planes

 drivers/gpu/drm/i915/i915_reg.h  |2 +-
 drivers/gpu/drm/i915/intel_display.c |1 +
 drivers/gpu/drm/i915/intel_sprite.c  |6 +++---
 3 files changed, 5 insertions(+), 4 deletions(-)

-- 
keith.pack...@intel.com


pgpd5tt5Ov3Ir.pgp
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 1/2] drm/radeon: Restrict offset for legacy hardware cursor.

[Alex Deucher]

2012/3/14 Michel Dänzer mic...@daenzer.net:
 From: Michel Dänzer michel.daen...@amd.com

 The hardware only takes 27 bits for the offset, so larger offsets are
 truncated, and the hardware cursor shows random bits other than the intended
 ones.

 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=46796

 Cc: sta...@vger.kernel.org
 Signed-off-by: Michel Dänzer michel.daen...@amd.com

Reviewed-by: Alex Deucher alexander.deuc...@amd.com

 ---

 v2: Make sure bo-placement.lpfn isn't larger than the memory size, even if
    radeon_bo_pin_restricted were to be called for the GTT domain.

  drivers/gpu/drm/radeon/radeon_cursor.c |   13 +++--
  drivers/gpu/drm/radeon/radeon_object.c |   18 +-
  drivers/gpu/drm/radeon/radeon_object.h |    2 ++
  3 files changed, 30 insertions(+), 3 deletions(-)

 diff --git a/drivers/gpu/drm/radeon/radeon_cursor.c 
 b/drivers/gpu/drm/radeon/radeon_cursor.c
 index fde25c0..986d608 100644
 --- a/drivers/gpu/drm/radeon/radeon_cursor.c
 +++ b/drivers/gpu/drm/radeon/radeon_cursor.c
 @@ -151,7 +151,9 @@ int radeon_crtc_cursor_set(struct drm_crtc *crtc,
                           uint32_t height)
  {
        struct radeon_crtc *radeon_crtc = to_radeon_crtc(crtc);
 +       struct radeon_device *rdev = crtc-dev-dev_private;
        struct drm_gem_object *obj;
 +       struct radeon_bo *robj;
        uint64_t gpu_addr;
        int ret;

 @@ -173,7 +175,15 @@ int radeon_crtc_cursor_set(struct drm_crtc *crtc,
                return -ENOENT;
        }

 -       ret = radeon_gem_object_pin(obj, RADEON_GEM_DOMAIN_VRAM, gpu_addr);
 +       robj = gem_to_radeon_bo(obj);
 +       ret = radeon_bo_reserve(robj, false);
 +       if (unlikely(ret != 0))
 +               goto fail;
 +       /* Only 27 bit offset for legacy cursor */
 +       ret = radeon_bo_pin_restricted(robj, RADEON_GEM_DOMAIN_VRAM,
 +                                      ASIC_IS_AVIVO(rdev) ? 0 : 1  27,
 +                                      gpu_addr);
 +       radeon_bo_unreserve(robj);
        if (ret)
                goto fail;

 @@ -181,7 +191,6 @@ int radeon_crtc_cursor_set(struct drm_crtc *crtc,
        radeon_crtc-cursor_height = height;

        radeon_lock_cursor(crtc, true);
 -       /* XXX only 27 bit offset for legacy cursor */
        radeon_set_cursor(crtc, obj, gpu_addr);
        radeon_show_cursor(crtc);
        radeon_lock_cursor(crtc, false);
 diff --git a/drivers/gpu/drm/radeon/radeon_object.c 
 b/drivers/gpu/drm/radeon/radeon_object.c
 index d45df17..fd2dc0e 100644
 --- a/drivers/gpu/drm/radeon/radeon_object.c
 +++ b/drivers/gpu/drm/radeon/radeon_object.c
 @@ -224,7 +224,8 @@ void radeon_bo_unref(struct radeon_bo **bo)
                *bo = NULL;
  }

 -int radeon_bo_pin(struct radeon_bo *bo, u32 domain, u64 *gpu_addr)
 +int radeon_bo_pin_restricted(struct radeon_bo *bo, u32 domain, u64 
 max_offset,
 +                            u64 *gpu_addr)
  {
        int r, i;

 @@ -232,6 +233,7 @@ int radeon_bo_pin(struct radeon_bo *bo, u32 domain, u64 
 *gpu_addr)
                bo-pin_count++;
                if (gpu_addr)
                        *gpu_addr = radeon_bo_gpu_offset(bo);
 +               WARN_ON_ONCE(max_offset != 0);
                return 0;
        }
        radeon_ttm_placement_from_domain(bo, domain);
 @@ -239,6 +241,15 @@ int radeon_bo_pin(struct radeon_bo *bo, u32 domain, u64 
 *gpu_addr)
                /* force to pin into visible video ram */
                bo-placement.lpfn = bo-rdev-mc.visible_vram_size  
 PAGE_SHIFT;
        }
 +       if (max_offset) {
 +               u64 lpfn = max_offset  PAGE_SHIFT;
 +
 +               if (!bo-placement.lpfn)
 +                       bo-placement.lpfn = bo-rdev-mc.gtt_size  
 PAGE_SHIFT;
 +
 +               if (lpfn  bo-placement.lpfn)
 +                       bo-placement.lpfn = lpfn;
 +       }
        for (i = 0; i  bo-placement.num_placement; i++)
                bo-placements[i] |= TTM_PL_FLAG_NO_EVICT;
        r = ttm_bo_validate(bo-tbo, bo-placement, false, false, false);
 @@ -252,6 +263,11 @@ int radeon_bo_pin(struct radeon_bo *bo, u32 domain, u64 
 *gpu_addr)
        return r;
  }

 +int radeon_bo_pin(struct radeon_bo *bo, u32 domain, u64 *gpu_addr)
 +{
 +       return radeon_bo_pin_restricted(bo, domain, 0, gpu_addr);
 +}
 +
  int radeon_bo_unpin(struct radeon_bo *bo)
  {
        int r, i;
 diff --git a/drivers/gpu/drm/radeon/radeon_object.h 
 b/drivers/gpu/drm/radeon/radeon_object.h
 index cde4303..f9104be 100644
 --- a/drivers/gpu/drm/radeon/radeon_object.h
 +++ b/drivers/gpu/drm/radeon/radeon_object.h
 @@ -118,6 +118,8 @@ extern int radeon_bo_kmap(struct radeon_bo *bo, void 
 **ptr);
  extern void radeon_bo_kunmap(struct radeon_bo *bo);
  extern void radeon_bo_unref(struct radeon_bo **bo);
  extern int radeon_bo_pin(struct radeon_bo *bo, u32 domain, u64 *gpu_addr);
 +extern int radeon_bo_pin_restricted(struct radeon_bo *bo, u32 domain,
 +                                   u64 max_offset, u64 *gpu_addr);
  extern 

Re: [PATCH 2/2] drm/radeon: Restrict offset for legacy display engine.

[Alex Deucher]

2012/3/14 Michel Dänzer mic...@daenzer.net:
 From: Michel Dänzer michel.daen...@amd.com

 The hardware only takes 27 bits for the offset, so larger offsets are
 truncated, and the display shows random bits other than the intended ones.

 Signed-off-by: Michel Dänzer michel.daen...@amd.com

Reviewed-by: Alex Deucher alexander.deuc...@amd.com

This should probably go to stable as well.  I think it may also fix this bug:
https://bugzilla.kernel.org/show_bug.cgi?id=16515

Alex

 ---
  drivers/gpu/drm/radeon/radeon_display.c     |    4 +++-
  drivers/gpu/drm/radeon/radeon_fb.c          |    5 -
  drivers/gpu/drm/radeon/radeon_legacy_crtc.c |    4 +++-
  3 files changed, 10 insertions(+), 3 deletions(-)

 diff --git a/drivers/gpu/drm/radeon/radeon_display.c 
 b/drivers/gpu/drm/radeon/radeon_display.c
 index d3ffc18..63386a4 100644
 --- a/drivers/gpu/drm/radeon/radeon_display.c
 +++ b/drivers/gpu/drm/radeon/radeon_display.c
 @@ -393,7 +393,9 @@ static int radeon_crtc_page_flip(struct drm_crtc *crtc,
                DRM_ERROR(failed to reserve new rbo buffer before flip\n);
                goto pflip_cleanup;
        }
 -       r = radeon_bo_pin(rbo, RADEON_GEM_DOMAIN_VRAM, base);
 +       /* Only 27 bit offset for legacy CRTC */
 +       r = radeon_bo_pin_restricted(rbo, RADEON_GEM_DOMAIN_VRAM,
 +                                    ASIC_IS_AVIVO(rdev) ? 0 : 1  27, 
 base);
        if (unlikely(r != 0)) {
                radeon_bo_unreserve(rbo);
                r = -EINVAL;
 diff --git a/drivers/gpu/drm/radeon/radeon_fb.c 
 b/drivers/gpu/drm/radeon/radeon_fb.c
 index cf2bf35..93bf920 100644
 --- a/drivers/gpu/drm/radeon/radeon_fb.c
 +++ b/drivers/gpu/drm/radeon/radeon_fb.c
 @@ -164,7 +164,10 @@ static int radeonfb_create_pinned_object(struct 
 radeon_fbdev *rfbdev,
        ret = radeon_bo_reserve(rbo, false);
        if (unlikely(ret != 0))
                goto out_unref;
 -       ret = radeon_bo_pin(rbo, RADEON_GEM_DOMAIN_VRAM, NULL);
 +       /* Only 27 bit offset for legacy CRTC */
 +       ret = radeon_bo_pin_restricted(rbo, RADEON_GEM_DOMAIN_VRAM,
 +                                      ASIC_IS_AVIVO(rdev) ? 0 : 1  27,
 +                                      NULL);
        if (ret) {
                radeon_bo_unreserve(rbo);
                goto out_unref;
 diff --git a/drivers/gpu/drm/radeon/radeon_legacy_crtc.c 
 b/drivers/gpu/drm/radeon/radeon_legacy_crtc.c
 index 25a19c4..210317c 100644
 --- a/drivers/gpu/drm/radeon/radeon_legacy_crtc.c
 +++ b/drivers/gpu/drm/radeon/radeon_legacy_crtc.c
 @@ -419,7 +419,9 @@ int radeon_crtc_do_set_base(struct drm_crtc *crtc,
        r = radeon_bo_reserve(rbo, false);
        if (unlikely(r != 0))
                return r;
 -       r = radeon_bo_pin(rbo, RADEON_GEM_DOMAIN_VRAM, base);
 +       /* Only 27 bit offset for legacy CRTC */
 +       r = radeon_bo_pin_restricted(rbo, RADEON_GEM_DOMAIN_VRAM, 1  27,
 +                                    base);
        if (unlikely(r != 0)) {
                radeon_bo_unreserve(rbo);
                return -EINVAL;
 --
 1.7.9.1

 ___
 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] nouveau: kfree() gracefully handles NULL pointers, testing is redundant

[Jesper Juhl]

Remove redundant NULL checks before kfree() in
drivers/gpu/drm/nouveau/nvc0_graph.c

Signed-off-by: Jesper Juhl j...@chaosbits.net
---
 drivers/gpu/drm/nouveau/nvc0_graph.c |9 +++--
 1 file changed, 3 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nvc0_graph.c 
b/drivers/gpu/drm/nouveau/nvc0_graph.c
index 8ee3963..e9eca29 100644
--- a/drivers/gpu/drm/nouveau/nvc0_graph.c
+++ b/drivers/gpu/drm/nouveau/nvc0_graph.c
@@ -755,10 +755,8 @@ nvc0_graph_create_fw(struct drm_device *dev, const char 
*fwname,
 static void
 nvc0_graph_destroy_fw(struct nvc0_graph_fuc *fuc)
 {
-   if (fuc-data) {
-   kfree(fuc-data);
-   fuc-data = NULL;
-   }
+   kfree(fuc-data);
+   fuc-data = NULL;
 }
 
 static void
@@ -778,8 +776,7 @@ nvc0_graph_destroy(struct drm_device *dev, int engine)
nouveau_gpuobj_ref(NULL, priv-unk4188b8);
nouveau_gpuobj_ref(NULL, priv-unk4188b4);
 
-   if (priv-grctx_vals)
-   kfree(priv-grctx_vals);
+   kfree(priv-grctx_vals);
 
NVOBJ_ENGINE_DEL(dev, GR);
kfree(priv);
-- 
1.7.9.4


-- 
Jesper Juhl j...@chaosbits.net   http://www.chaosbits.net/
Don't top-post http://www.catb.org/jargon/html/T/top-post.html
Plain text mails only, please.

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[V2 PATCH 0/2] Provide workarounds to use DRM/KMS with broken graphics hardware

[Carsten Emde]

This is V2 of a patchset to use DRM/KMS with broken graphics hardware.

As a major change from V1, generic EDID data are now built-in into the
drm_kms_helper module as proposed by Alan. To help people building
their own EDID data and to understand how the binary EDID blobs in
drivers/gpu/drm/drm_edid_load.c have been created, the entire material
went into the Documentation tree as suggested by Valdis. Finally, David
showed a much better way to explicitly disable and enable a particular
connector, so patch 02/03 could go.

The two remaining patches
- introduce a mechanism to define or load EDID data instead of letting the
controller probe for it,
- add a parameter to the i915 module to invert the sense of the backlight
brightness variable for broken controllers that require this.

-Carsten.

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[V2 PATCH 2/2] drivers-gpu-drm-i915-invert-backlight-brightness

[Carsten Emde]

Following the documentation of the Legacy Backlight Brightness (LBB)
Register in the configuration space of some Intel PCI graphics adapters,
setting the LBB register with the value 0x0 causes the backlight to be
turned off, and 0xFF causes the backlight to be set to 100% intensity
(http://download.intel.com/embedded/processors/Whitepaper/324567.pdf).
At least one of our test systems, however, turns the backlight off at
0xFF and sets it to maximum intensity at 0. In consequence, the screen
of this systems becomes dark at an early boot stage which makes it
unusable. The same inversion applies to the BLC_PWM_CTL I915 register.
This problem was introduced in kernel version 2.6.38 when the PCI device
of this system was first supported by the i915 KMS module.

This patch adds a module parameter to invert the backlight brightness
value before writing and after reading which makes the affected notebook
usable again.

Signed-off-by: Carsten Emde c.e...@osadl.org

---
 Documentation/kernel-parameters.txt |9 +
 drivers/gpu/drm/i915/intel_panel.c  |   14 ++
 2 files changed, 23 insertions(+)

Index: linux-3.3-rc6/Documentation/kernel-parameters.txt
===
--- linux-3.3-rc6.orig/Documentation/kernel-parameters.txt
+++ linux-3.3-rc6/Documentation/kernel-parameters.txt
@@ -966,6 +966,15 @@ bytes respectively. Such letter suffixes
 
i810=   [HW,DRM]
 
+   i915.invert_brightness
+   [DRM] Invert the sense of the variable that is used to
+   set the brightness of the panel backlight. Normally a
+   value of 0 indicates backlight switched off, and the
+   maximum value sets the backlight to maximum brightness.
+   If this parameter is specified, a value of 0 sets the
+   backlight to maximum brightness, and the maximum value
+   switches the backlight off.
+
i8k.ignore_dmi  [HW] Continue probing hardware even if DMI data
indicates that the driver is running on unsupported
hardware.
Index: linux-3.3-rc6/drivers/gpu/drm/i915/intel_panel.c
===
--- linux-3.3-rc6.orig/drivers/gpu/drm/i915/intel_panel.c
+++ linux-3.3-rc6/drivers/gpu/drm/i915/intel_panel.c
@@ -28,6 +28,7 @@
  *  Chris Wilson ch...@chris-wilson.co.uk
  */
 
+#include linux/moduleparam.h
 #include intel_drv.h
 
 #define PCI_LBPC 0xf4 /* legacy/combination backlight modes */
@@ -191,6 +192,10 @@ u32 intel_panel_get_max_backlight(struct
return max;
 }
 
+static bool brightness_inverted;
+MODULE_PARM_DESC(brightness_inverted, Backlight brightness value is inverted 
+   (0 = max brightness, max value = dark));
+module_param_named(brightness_inverted, brightness_inverted, bool, 0600);
 u32 intel_panel_get_backlight(struct drm_device *dev)
 {
struct drm_i915_private *dev_priv = dev-dev_private;
@@ -212,6 +217,10 @@ u32 intel_panel_get_backlight(struct drm
}
 
DRM_DEBUG_DRIVER(get backlight PWM = %d\n, val);
+   if (brightness_inverted) {
+   u32 max = intel_panel_get_max_backlight(dev);
+   val = max - val;
+   }
return val;
 }
 
@@ -229,6 +238,11 @@ static void intel_panel_actually_set_bac
 
DRM_DEBUG_DRIVER(set backlight PWM = %d\n, level);
 
+   if (brightness_inverted) {
+   u32 max = intel_panel_get_max_backlight(dev);
+   level = max - level;
+   }
+
if (HAS_PCH_SPLIT(dev))
return intel_pch_panel_set_backlight(dev, level);
 

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[V2 PATCH 1/2] drivers-gpu-drm-allow-to-load-edid-firmware.patch

[Carsten Emde]

Broken monitors and/or broken graphic boards may send erroneous or no
EDID data. This also applies to broken KVM devices that are unable to
correctly forward the EDID data of the connected monitor but invent
their own fantasy data.

This patch allows to specify an EDID data set to be used instead of
probing the monitor for it. It contains built-in data sets of frequently
used screen resolutions. In addition, a particular EDID data set may be
provided in the /lib/firmware directory and loaded via the firmware
interface. The name is passed to the kernel as module parameter of the
drm_kms_helper module either when loaded
  options drm_kms_helper edid_firmware=edid/1280x1024.bin
or as kernel commandline parameter
  drm_kms_helper.edid_firmware=edid/1280x1024.bin  

The built-in data sets are
ResolutionName

1024x768  edid/1024x768.bin
1280x1024 edid/1280x1024.bin
1680x1050 edid/1680x1050.bin
1920x1080 edid/1920x1080.bin

They are ignored, if a file with the same name is available in the
/lib/firmware directory.

The built-in EDID data sets are based on standard timings that may not
apply to a particular monitor and even crash it. Ideally, EDID data of
the connected monitor should be used. They may be obtained through the 
drm/cardX/cardX-connector/edid entry in the /sys/devices PCI directory
of a correctly working graphics adapter.

It is also possible to specify the name of an EDID data set on-the-fly
via the /sys/module interface, e.g.
echo edid/myedid.bin /sys/module/drm_kms_helper/parameters/edid_firmware
The new screen mode is considered when the related kernel function is
called for the first time after the change. Such calls are made when the
X server is started or when the display settings dialog is opened in an
already running X server.

Signed-off-by: Carsten Emde c.e...@osadl.org

---
 Documentation/EDID/1024x768.S   |   44 ++
 Documentation/EDID/1280x1024.S  |   44 ++
 Documentation/EDID/1680x1050.S  |   44 ++
 Documentation/EDID/1920x1080.S  |   44 ++
 Documentation/EDID/HOWTO.txt|   39 +
 Documentation/EDID/Makefile |   25 +++
 Documentation/EDID/edid.S   |  261 
 Documentation/EDID/hex  |1 
 Documentation/kernel-parameters.txt |   10 +
 drivers/gpu/drm/Kconfig |   11 +
 drivers/gpu/drm/Makefile|3 
 drivers/gpu/drm/drm_crtc_helper.c   |8 -
 drivers/gpu/drm/drm_edid.c  |4 
 drivers/gpu/drm/drm_edid_load.c |  241 +
 include/drm/drm_crtc.h  |1 
 include/drm/drm_edid.h  |1 
 16 files changed, 778 insertions(+), 3 deletions(-)

Index: linux-3.3-rc6/Documentation/EDID/1024x768.S
===
--- /dev/null
+++ linux-3.3-rc6/Documentation/EDID/1024x768.S
@@ -0,0 +1,44 @@
+/*
+   1024x768.S: EDID data set for standard 1024x768 60 Hz monitor
+
+   Copyright (C) 2011 Carsten Emde c.e...@osadl.org
+
+   This program is free software; you can redistribute it and/or
+   modify it under the terms of the GNU General Public License
+   as published by the Free Software Foundation; either version 2
+   of the License, or (at your option) any later version.
+
+   This program is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+   GNU General Public License for more details.
+
+   You should have received a copy of the GNU General Public License
+   along with this program; if not, write to the Free Software
+   Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA.
+*/
+
+/* EDID */
+#define VERSION 1
+#define REVISION 3
+
+/* Display */
+#define CLOCK 65000 /* kHz */
+#define XPIX 1024
+#define YPIX 768
+#define XY_RATIO XY_RATIO_4_3
+#define XBLANK 320
+#define YBLANK 38
+#define XOFFSET 8
+#define XPULSE 144
+#define YOFFSET (63+3)
+#define YPULSE (63+6)
+#define DPI 72
+#define VFREQ 60 /* Hz */
+#define TIMING_NAME Linux XGA
+#define ESTABLISHED_TIMINGS_BITS 0x08 /* Bit 3 - 1024x768 @60 Hz */
+#define HSYNC_POL 0
+#define VSYNC_POL 0
+#define CRC 0x55
+
+#include edid.S
Index: linux-3.3-rc6/Documentation/EDID/1280x1024.S
===
--- /dev/null
+++ linux-3.3-rc6/Documentation/EDID/1280x1024.S
@@ -0,0 +1,44 @@
+/*
+   1280x1024.S: EDID data set for standard 1280x1024 60 Hz monitor
+
+   Copyright (C) 2011 Carsten Emde c.e...@osadl.org
+
+   This program is free software; you can redistribute it and/or
+   modify it under the terms of the GNU General Public License
+   as published by the Free Software Foundation; either version 2
+   of the License, or (at your option) any later version.
+
+   This program is distributed in the hope that it will be useful,
+   but WITHOUT ANY 

[PATCH] RFC: dma-buf: userspace mmap support

[Rob Clark]

From: Rob Clark r...@ti.com

Enable optional userspace access to dma-buf buffers via mmap() on the
dma-buf file descriptor.  Userspace access to the buffer should be
bracketed with DMA_BUF_IOCTL_{PREPARE,FINISH}_ACCESS ioctl calls to
give the exporting driver a chance to deal with cache synchronization
and such for cached userspace mappings without resorting to page
faulting tricks.  The reasoning behind this is that, while drm
drivers tend to have all the mechanisms in place for dealing with
page faulting tricks, other driver subsystems may not.  And in
addition, while page faulting tricks make userspace simpler, there
are some associated overheads.

In all cases, the mmap() call is allowed to fail, and the associated
dma_buf_ops are optional (mmap() will fail if at least the mmap()
op is not implemented by the exporter, but in either case the
{prepare,finish}_access() ops are optional).

For now the prepare/finish access ioctls are kept simple with no
argument, although there is possibility to add additional ioctls
(or simply change the existing ioctls from _IO() to _IOW()) later
to provide optimization to allow userspace to specify a region of
interest.

For a final patch, dma-buf.h would need to be split into what is
exported to userspace, and what is kernel private, but I wanted to
get feedback on the idea of requiring userspace to bracket access
first (vs. limiting this to coherent mappings or exporters who play
page faltings plus PTE shoot-down games) before I split the header
which would cause conflicts with other pending dma-buf patches.  So
flame-on!
---
 drivers/base/dma-buf.c  |   42 ++
 include/linux/dma-buf.h |   22 ++
 2 files changed, 64 insertions(+), 0 deletions(-)

diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c
index c9a945f..382b78a 100644
--- a/drivers/base/dma-buf.c
+++ b/drivers/base/dma-buf.c
@@ -30,6 +30,46 @@
 
 static inline int is_dma_buf_file(struct file *);
 
+static int dma_buf_mmap(struct file *file, struct vm_area_struct *vma)
+{
+   struct dma_buf *dmabuf;
+
+   if (!is_dma_buf_file(file))
+   return -EINVAL;
+
+   dmabuf = file-private_data;
+
+   if (dmabuf-ops-mmap)
+   return dmabuf-ops-mmap(dmabuf, file, vma);
+
+   return -ENODEV;
+}
+
+static long dma_buf_ioctl(struct file *file, unsigned int cmd,
+   unsigned long arg)
+{
+   struct dma_buf *dmabuf;
+
+   if (!is_dma_buf_file(file))
+   return -EINVAL;
+
+   dmabuf = file-private_data;
+
+   switch (_IOC_NR(cmd)) {
+   case _IOC_NR(DMA_BUF_IOCTL_PREPARE_ACCESS):
+   if (dmabuf-ops-prepare_access)
+   return dmabuf-ops-prepare_access(dmabuf);
+   return 0;
+   case _IOC_NR(DMA_BUF_IOCTL_FINISH_ACCESS):
+   if (dmabuf-ops-finish_access)
+   return dmabuf-ops-finish_access(dmabuf);
+   return 0;
+   default:
+   return -EINVAL;
+   }
+}
+
+
 static int dma_buf_release(struct inode *inode, struct file *file)
 {
struct dma_buf *dmabuf;
@@ -45,6 +85,8 @@ static int dma_buf_release(struct inode *inode, struct file 
*file)
 }
 
 static const struct file_operations dma_buf_fops = {
+   .mmap   = dma_buf_mmap,
+   .unlocked_ioctl = dma_buf_ioctl,
.release= dma_buf_release,
 };
 
diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
index a885b26..cbdff81 100644
--- a/include/linux/dma-buf.h
+++ b/include/linux/dma-buf.h
@@ -34,6 +34,17 @@
 struct dma_buf;
 struct dma_buf_attachment;
 
+/* TODO: dma-buf.h should be the userspace visible header, and dma-buf-priv.h 
(?)
+ * the kernel internal header.. for now just stuff these here to avoid 
conflicting
+ * with other patches..
+ *
+ * For now, no arg to keep things simple, but we could consider adding an
+ * optional region of interest later.
+ */
+#define DMA_BUF_IOCTL_PREPARE_ACCESS   _IO('Z', 0)
+#define DMA_BUF_IOCTL_FINISH_ACCESS_IO('Z', 1)
+
+
 /**
  * struct dma_buf_ops - operations possible on struct dma_buf
  * @attach: [optional] allows different devices to 'attach' themselves to the
@@ -49,6 +60,13 @@ struct dma_buf_attachment;
  * @unmap_dma_buf: decreases usecount of buffer, might deallocate scatter
  *pages.
  * @release: release this buffer; to be called after the last dma_buf_put.
+ * @mmap: [optional, allowed to fail] operation called if userspace calls
+ *  mmap() on the dmabuf fd.  Note that userspace should use the
+ *  DMA_BUF_PREPARE_ACCESS / DMA_BUF_FINISH_ACCESS ioctls 
before/after
+ *  sw access to the buffer, to give the exporter an opportunity to
+ *  deal with cache maintenance.
+ * @prepare_access: [optional] handler for PREPARE_ACCESS ioctl.
+ * @finish_access: [optional] handler for FINISH_ACCESS ioctl.
  */
 struct dma_buf_ops {
int (*attach)(struct 

Re: [V2 PATCH 2/2] drivers-gpu-drm-i915-invert-backlight-brightness

[Keith Packard]

#part sign=pgpmime
On Thu, 15 Mar 2012 00:35:46 +0100, Carsten Emde c.e...@osadl.org wrote:

 This patch adds a module parameter to invert the backlight brightness
 value before writing and after reading which makes the affected notebook
 usable again.

You should add a quirk for this and set things up so that your machine
automatically gets the right value; when we find more machines that do
this, we can add them so that more people will get a system that 'just
works'.

-- 
keith.pack...@intel.com
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[git pull] drm/exynos: updated exynos-drm-fixes

[Inki Dae]

Hi Dave.

Please pull from
git://git.infradead.org/users/kmpark/linux-samsung exynos-drm-fixes

this patch set is just miner fixes and had already been posted last week for 
review
and another one included in this patch set also already been posted by Sascha 
Hauer
last month. for this you can refer to this link:

http://www.mail-archive.com/dri-devel@lists.freedesktop.org/msg18370.html

this branch is based on git repository below:
git://people.freedesktop.org/~airlied/linux.git
branch name: drm-fixes
commit-id: 38aa4a568ba4c3ccba83e862a01e3e60e3b811ee

Please let me know if there is any problem.
Thanks.

Laurent Pinchart (1):
  drm/exynos: Fix fb_videomode - drm_mode_modeinfo conversion

Marek Szyprowski (2):
  drm/exynos: use correct 'exynos-drm' name for platform device
  drm/exynos: fix runtime_pm fimd device state on probe

Sascha Hauer (1):
  drm exynos: use drm_fb_helper_set_par directly

 drivers/gpu/drm/exynos/exynos_drm_connector.c |   16 +++---
 drivers/gpu/drm/exynos/exynos_drm_drv.c   |2 +-
 drivers/gpu/drm/exynos/exynos_drm_fbdev.c |   28 +
 drivers/gpu/drm/exynos/exynos_drm_fimd.c  |   17 +-
 4 files changed, 16 insertions(+), 47 deletions(-)

-- 
1.7.4.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel